From xen-devel-bounces@lists.xenproject.org Tue Sep 01 06:27:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 06:27:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404430.1638104 (Exim 4.92) (envelope-from ) id 1x1HxF-0007SF-Vc; Tue, 01 Sep 2026 06:26:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404430.1638104; Tue, 01 Sep 2026 06:26:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1HxF-0007S7-Qt; Tue, 01 Sep 2026 06:26:45 +0000 Received: by outflank-mailman (input) for mailman id 1404430; Tue, 01 Sep 2026 06:26:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1HxF-0007S1-3m for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 06:26:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1HxD-002aUM-Qk for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:26:43 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967012-2eae-0a2a0a5409dd-0a2a450ce872-34 for ; Tue, 01 Sep 2026 08:26:43 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a967023-f479-0a2a450c0019-d155802dbc47-3 for ; Tue, 01 Sep 2026 08:26:43 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so42108875e9.0 for ; Mon, 31 Aug 2026 23:26:43 -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 ffacd0b85a97d-48442d6eafesm2465684f8f.24.2026.08.31.23.26.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2026 23:26:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788244003; x=1788848803; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=mj6oJVsCPqNU+EK40dWQmbASDv4ZqpwZD7NjEyaNDUY=; b=IOd3pNOklDu934WC1hk7X7w3DfediJIOExD8Sgn57SOSlfsvNtxlZgoEBAhioQI0WZ ckilFlI2ap5Y4Kpuc3YCJgfNn//ZKMY8+m+SMib21BmW33nZGC2/ZX51DWTcp2cRJ/vO KKOr7wKqmifv9hqAowO0L2DCTGssCKDXMtTbbmDaW0yJXALhxyw3h/M7sfrFCDzR6upx H3uBlkeAf+OosVYP/X0yTsTB1HqjMil1BL1MNn/rd1pfOHzifI85vsg4nQcbvlNn4lm0 qSEI+94TVVnCZZTCOEZzluXocJJEyE1eJmz88XDwAD9a/gUaiT4H+yn7uM8MV+uNCXFx 7Tfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788244003; x=1788848803; h=content-transfer-encoding:content-type: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:content-type; bh=mj6oJVsCPqNU+EK40dWQmbASDv4ZqpwZD7NjEyaNDUY=; b=Z/UFv44qHBbUKhyQSVLINjjaELS8S1Y8xW/YULBPNj3Hoo2T9GBTwGtCnZiUMoxD2g BZ3GKEX3JSsd1emWwNaC5uqyAbwLfk2gugEW2Yls/TDX6fp5LF3jQ3UoFDz3qHBTNTmb rIlYDtGe0kDydP6r1icqImHNmieDr/PHyoBtQQUwBDvB7xxYMpPax84uEdoG8z3XsJu0 febzHo5yYmmwWzunRZgL+oN6rqqJL53M8AfNfqTqXKQA5mUlLZD8ccXPI2xkL3Fe89ck P9+LlgkKIQh2hO49UJsvxNHVrS9C7ucqxEfc9PcgHinBTczFIlTc46OJFDihYoq5b7UA IsOg== X-Forwarded-Encrypted: i=1; AHgh+RoRVhwEdRIQRjkS3ARi80qyL3eCNFr8wqKYYubtAc6/tPlekJuEyx+5/Q52sOsRuxtMy1B5xpVat9o=@lists.xenproject.org X-Gm-Message-State: AFuF++k5KWmolplep0+Kz73DMLUfYg6zixXEKXp73oSHBlPQTA2ln5Zw ASbsrrL7365u5SSfiB98YPXfwU7DrfBpM5e5CzhngUQcSqYp0RnJgfPlPCp4atrtyg== X-Gm-Gg: AR+sD11/SPfq3pMAcopOgdZ/0ZCCwCldKdn2HC/y3MZ8Ts/HKqHZkT6Zsr5h6I7PulR RRjYix6GuhRuYjBg6ZWWuvQNR0PuQkAcXz4N49zposswzIWTL+R+064y89ZzSVZe7KCisAhPSYj IRnvcfFKVcowLYTyVvA+PAy0Wlew969KUK8v9YIaBnRnUlgjep00C9T1FqB2n3Fbt3dAMUBBlhd /JsWpYg3O9WBOJ3Xyiflj34hrUMb52Ng3h2nlWRx9k+54ZTov3VVpQZH3cvptq2wVhpxs+ALN8u 8muw3iHG+dirabLU5N+98LQSWVrCpP2P8ONR0oy8ScVyHmXoOtFFEUeAhSNsSITRbGeHNlSJ7dG bTN9q8hxQmejSmyj8l+Fh6H2DpJdJ+f/RiY6d4b7ShNOCr01bTd9EkeiSdmOiamGX7KT/o3qLeP TwQd+a3dsPfHIyHAEXBsDLMUvIU3PAVV+KYOhw7aIpoZ/Xym329rL87DoxYnr8332nyIcVDI1z8 8mKV3cQeTixHSjvV9uZZ0TBsdET4Ud35X3PudAhTO7QdB8OgCEJ X-Received: by 2002:a05:600c:c113:b0:497:fecd:5b00 with SMTP id 5b1f17b1804b1-49cdc435d58mr97286375e9.9.1788244003021; Mon, 31 Aug 2026 23:26:43 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 08:26:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places To: Andrew Cooper , Nicola Vetrini Cc: Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.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: <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788244003-022C0A5B-B4BFB9E6/0/0 X-purgate-type: clean X-purgate-size: 2120 On 31.08.2026 21:13, Andrew Cooper wrote: > On 28/08/2026 8:01 am, Jan Beulich wrote: >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu >> case X86_ET_HW_EXC: >> switch ( vec ) >> { >> - case X86_EXC_DF: return do_double_fault(regs); >> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >> case X86_EXC_MC: return do_machine_check(regs); >> } >> break; >> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp >> case X86_ET_HW_EXC: >> switch ( regs->fred_ss.vector ) >> { >> - case X86_EXC_DF: return do_double_fault(regs); >> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >> case X86_EXC_MC: return do_machine_check(regs); >> } >> break; >> > > For starters you're missing a break, and the only reason this isn't a > compile error is the trailing comment. "break" there would again be unreachable, though. >  Second, it's a tailcall anyway.  > There really is nothing unreachable anywhere in this construct. Just that the concept of "tailcall" is an optimization, not something inherent to the language. > But by far the most important, it the singular noreturn attribute on > do_double_fault() (elsewhere, and not visible when reading these two > functions) which is preventing #DF falling into #MC.   This introduces > fragility which did not exist previously. I realized that when making the patch, yet what do you do when the rule is as it is? Hence why I added the comment, really. > do_double_fault() would conditionally return if we ever got around to > fixing espfix64. And hence would have to lose its "noreturn". At which point call sites would need inspecting. (As said - yes, I do realize the fragility.) > So no - I'm going to insist that Eclair is taught to accept "return > some_noreturn_fn();" as intentional.  It is objectively less fragile > than the MISRA-preferred option. Nicola, thoughts? Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 06:34:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 06:34:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404439.1638112 (Exim 4.92) (envelope-from ) id 1x1I4U-0000hX-Kf; Tue, 01 Sep 2026 06:34:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404439.1638112; Tue, 01 Sep 2026 06:34:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1I4U-0000hQ-Hi; Tue, 01 Sep 2026 06:34:14 +0000 Received: by outflank-mailman (input) for mailman id 1404439; Tue, 01 Sep 2026 06:34:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1I4T-0000hK-Hj for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 06:34:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1I4S-006y77-UJ for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:34:12 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9671d5-8faa-0a2a0a5109dd-0a2a4507b868-48 for ; Tue, 01 Sep 2026 08:34:12 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9671e4-b4ea-0a2a45070019-d1558034b864-3 for ; Tue, 01 Sep 2026 08:34:12 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49cdc81f40eso7364445e9.2 for ; Mon, 31 Aug 2026 23:34:12 -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-49b91c5790csm282912335e9.0.2026.08.31.23.34.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2026 23:34:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788244452; x=1788849252; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=im/4BG+MEJJe5UBdxNY4GApA4/zw8M0XrGC3NLnhOMM=; b=YH91TFH+h7RHOR8pARYw+TOSFb1duD5HEE7L0dXilr8mhkG+zwqFLObGbc1e/Th3o4 a7LCFTMlKPY8t2WVPJuCO5lPtFf2fk32mdj93agtoQE59w7mBCTD7mbMe753TAdDsLWk W9ZSh+JKGgfzKXWJHafWDe8E2L+PfQ5qQc0QQZMmXRt1tics6YJOC6j39akzC06IN3PO 6UOLS+Y2PsPxagekZaCnKmeYpdJeB0LWoWJwo796drqlCrVFFMdYN+kFjHXwnG3e9EMl +4Wyx6FpT9n57+/80OLgxtpqA6Y9AAkUFKVtYPa8gLwcTOhHfEDDpwIRwGgQy+jR390D 7ZDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788244452; x=1788849252; h=content-transfer-encoding:content-type: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:content-type; bh=im/4BG+MEJJe5UBdxNY4GApA4/zw8M0XrGC3NLnhOMM=; b=rmr+vk3w1xux95DScs7J0HyWys3xsVI2Hiq4yF9mB/++aAeEgy4JxzpJCS23AtwtkJ NKRmvas1O1AscfBHSxleewV6BSP5D7n3AYkYXP4xJMm5rVkN+D1oTD45EDSvHnish/Yr lnK305G7vMYCgcKKHXGeSyoxNiJc3cWYQaI4dVDP4SuSCldWqM/OdtK+H+KV8dbW4Ubn KfHH6W8IuatWfYubNw6zYh5uQa5AHoTexQzzcp/PRvRWPJBVUStlcy/JjVq2SG/g8MWU lvg2lyRXkywC6YDpXty9xTAByPNiPloEwRtmrMX5UVgU+iLFjxiYSPSSXIIOrrBUrMzz X6nQ== X-Gm-Message-State: AFuF++mLbgkrNSF3A0Ng0RQrB5kU9qpYIaLmfyRJEZOW1iEQqfemr3el WUv5akQjdHMZ8/wYCdWBMMjLhhx1mAg0MClPM8rpHpi668/3zDpemTLK0nFAdd/cCe2tZmeScHy QR6+uBw== X-Gm-Gg: AR+sD119CwtwGLucMj616dIp82uJ8V0KBmL8E4UepkPki++fMkll4Qh6FEwmtwWfBuT op8ZIr2do580E8wER22U1RUCAzaNOgGr1zVUR3UKa24sNwFb/JSjLA+QmLmc3Hw9WPL0oX1T1/T 76HWgB9uyjwPLeS1n7zCVL8cEWCWZwv/yZgrp4jhG8KCF2YVcYBpuku7ISGuCjhtaUzK1Mtavaq ka1B7vLqjX8+qKaswmu0SuuQmvdsOz4BH1lq+TQsJfIfxE7L4GyuWxRWfRlE09TH38q0WTFIiiS CEoUUpce7VoP7pmVEYNi95W1XF2Jkf/7fLRuye7+khysg+YGDW9B/3pEH1E2WuSzvHgsNERR44h hZT3OqsptfX7WK1We4x01M/NgtTRAXXzkto9SBnDqx699zlvwigWZ5XDfuESG8U1PS85N7ePuYh RK1SB216bBo+kgzEYlXbqaGLCDBxcBvJJuYKAGULzIwsTUTyHdrqT68645sIG0oKlkjzz91t68+ 7x8NU0Osvm4MJt0PIanGIBHV75vvnH52fofh7fmfIUyCYG/F6ez X-Received: by 2002:a05:600d:6402:20b0:499:a277:e8b5 with SMTP id 5b1f17b1804b1-49cdc42f448mr86087205e9.3.1788244452370; Mon, 31 Aug 2026 23:34:12 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 08:34:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] flask: add const qualifier to security_context_to_sid() To: Sergiy Kibrik Cc: "xen-devel@lists.xenproject.org" , "Daniel P. Smith" References: <1b680cd1-c086-4aa1-9a8c-f89d9743918e@suse.com> <5564a32f-31fa-4629-beb4-d87d19c2944d@epam.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: <5564a32f-31fa-4629-beb4-d87d19c2944d@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788244452-356C2AE4-99973909/0/0 X-purgate-type: clean X-purgate-size: 530 On 31.08.2026 12:01, Sergiy Kibrik wrote: > On 8/28/26 09:40, Jan Beulich wrote: >> - While touching code anyway, it would be nice if u was converted to >> uint_t (or else we'll never complete that conversion). >> I think I'll take the liberty of addressing all of these while committing. > > thank you, Jan. BTW, what's up with u? Are they expected to be > dropped/converted in Xen? Yes. If you go look, s were already dropped, as were __[su]. The use of u sadly is far more widespread. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 06:36:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 06:36:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404447.1638122 (Exim 4.92) (envelope-from ) id 1x1I6N-0001Bz-V1; Tue, 01 Sep 2026 06:36:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404447.1638122; Tue, 01 Sep 2026 06:36:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1I6N-0001Bs-SH; Tue, 01 Sep 2026 06:36:11 +0000 Received: by outflank-mailman (input) for mailman id 1404447; Tue, 01 Sep 2026 06:36:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1I6M-0001Bh-M5 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 06:36:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1I6M-00H4xo-2n for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:36:10 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967252-8faa-0a2a0a5109dd-0a2a4508bf9a-12 for ; Tue, 01 Sep 2026 08:36:10 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a967258-f659-0a2a45080019-d155802bc515-3 for ; Tue, 01 Sep 2026 08:36:08 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49b8ce9b733so29945385e9.1 for ; Mon, 31 Aug 2026 23:36:08 -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-49cdce1025asm42904865e9.6.2026.08.31.23.36.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2026 23:36:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788244568; x=1788849368; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=RqrJdKWIw6zoDRGWnhwZfLuJsTxCwJNCeEEC5eWASrI=; b=BjJ3s8nGWV2M66/dnUblK2SzlNVwkc0RqsA/KC2WyBf1JPUkdA0dquQ8etFuzShIBk BaKofPPLGXSSzc4veETytPNCKk+7FDJFxhmIM4l1Ltqq8Gc1smoge397KgVJjhCOz4vT bu2vohgeopbiOTBH1FwpJhLMs2CecLu22nEmdD/apNH+cK4gM+R3sEkVuThWWSNH/Qo8 8B8o3/jBrWvKb1paO0vCtVrazGWBQK4FjwGtdsl1R7XSQXhUFA1M9pUDFQCW4jPw2Enj 3JvcmKIvuSjl7ODkOne8zgTt9QOr9TF/PDQZtQZ5kcvkvUK9NPch220HsTIdAkD/ZL4W neTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788244568; x=1788849368; h=content-transfer-encoding:content-type: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:content-type; bh=RqrJdKWIw6zoDRGWnhwZfLuJsTxCwJNCeEEC5eWASrI=; b=XhA/+pcxesPlphIzjzeXT8sZsq4HPggsMvfL06x7A3Y88L8QCLG00HGXCE4PjcO/Ur 0FKQdkiTuHEZ8JfSTVc9k3eIkPE3llx7osn362o3ao7Bco1r35syd+PXwF58SxA12pmp vy1E8YMpuUVk9+nwKTAxEYbOM0ym4PPb9ixPkc22lXxMhoYoq3uaCWSvTFqBTjZKHTCl TZcoGp+vbhvpK5WkwbkM1I0459cawf5YWE8dhvBrQ0sTAL3UuDF5CtDOoX4/rY6xIxRf HDP+iwciXntpzydov1cCIJOrrgbT+ECSiFmgvT3HUezlWuGW+mSWQ++L6GTuoRex+QSA CoMA== X-Gm-Message-State: AFuF++lPoFATFVdC8A2V5OFoHhVSvhP1MMobew+qbbD0ScjU6/4JcaVM HDIHeB5N9gXoOapGi5lWUwUSz5znnf0Xjv6H/FgIZy8NJ+7AEcHeFYmRI5SVo+W2Vw== X-Gm-Gg: AR+sD13dZd75Qq2xVEaqJfZunSKgp2s6br70vBTiqM+tNTOQ5wJL5qIDN5RSz9JTPCi nUSD+eRkDmxuwLNgsNY/GKRLP5z2mIXo5bIAU350sfrZnnpWvjmBcOpmFhRSwogwoH3bUKqGl1g zqt3FZlwm+k/XbpxtjzTPk89pF1O6hoHlTTVxzCTSw3ax0Ax+pAf/M/EDNtCnVQAtZmn2X/mefc aeWfGZbsx+E0LFWBjgwZHT7JlpOJeT6vQyl8GvY+rETq3GKQaf52+RxHL+rpyVCENAREqA3FLnc GofCNN2n4nYcK31nNgQ8rixr7AXcTidhcBVP5pHdQUVRFVZByKLes1FXe94fzIrWjMjFzvXdHyq covXG/pY11kHFA8uY1nGEgeYvm//9Oa4aUp7yxzHWcV9hn+x0DH6L6M1tiRBG9f+awlkDzhz9t+ 6C7xTBa7FFX8RNZvWpBfSv2psXRsg/lQAOB/U14MH+Cowz0W/WNh/3+CjLH5IPgu+E4Il+Xp4Hr FdhcAR9Taxm71chM1ZmwhU74GEK66N7bx77WyOJkCTCoGTOYC4U X-Received: by 2002:a05:600c:1d0c:b0:499:484a:81d0 with SMTP id 5b1f17b1804b1-49b91c3e67fmr447976695e9.9.1788244568228; Mon, 31 Aug 2026 23:36:08 -0700 (PDT) Message-ID: <99c30685-549d-4118-87bc-41d441ffcc3d@suse.com> Date: Tue, 1 Sep 2026 08:36:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/12] Eclair: deviate BUILD_ERROR() wrt rule 2.1 and introduce variants To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <06c5efc0-e130-417f-8333-b8eacd1c6d77@suse.com> <99c8a63920c37dafdfeb2a2a4333df72@bugseng.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: <99c8a63920c37dafdfeb2a2a4333df72@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788244568-CC97287B-50A4FCE8/0/0 X-purgate-type: clean X-purgate-size: 1072 On 29.08.2026 16:04, Nicola Vetrini wrote: > On 2026-08-28 09:04, Jan Beulich wrote: >> BUILD_ERROR() is even stronger a guard than assertions in general, and >> ASSERT_UNREACHABLE() (or BUG()) in particular. Deviate it just like >> those >> to allow use for marking unreachable portions of code. >> >> In some cases code being unreachable is dependent upon configuration. >> Introduce two variants, as constructs like >> >> if ( IS_ENABLED(CONFIG_...) ) >> BUILD_ERROR("..."); >> >> results in the if() still being reported as unreachable. Sadly these >> two >> new macros introduce a new 20.12 violation each, which hence also needs >> deviating. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Nicola Vetrini Thanks. > Presumably you did not fold at least one of the following patches where > the construct is actually used into this one to separate concerns? Partly for that, partly to keep subsequent patches possible to go in independently, i.e. in any order. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 06:40:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 06:40:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404454.1638131 (Exim 4.92) (envelope-from ) id 1x1IAS-0002u5-FC; Tue, 01 Sep 2026 06:40:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404454.1638131; Tue, 01 Sep 2026 06:40:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IAS-0002ty-CK; Tue, 01 Sep 2026 06:40:24 +0000 Received: by outflank-mailman (input) for mailman id 1404454; Tue, 01 Sep 2026 06:40:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IAQ-0002ts-Gl for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 06:40:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1IAP-004wr1-Th for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:40:21 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967352-8faa-0a2a0a5109dd-0a2a450cce94-18 for ; Tue, 01 Sep 2026 08:40:21 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a967355-f479-0a2a450c0019-d155dd36ed2f-3 for ; Tue, 01 Sep 2026 08:40:21 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-47ddf7b09e5so494788f8f.1 for ; Mon, 31 Aug 2026 23:40:21 -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-49cdce171c3sm46925365e9.8.2026.08.31.23.31.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2026 23:31:16 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788244821; x=1788849621; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=OiPWX8IPpLtRRTCWw+Y69aOZxYBxv2bn93Gvyq1POyE=; b=IrYRuVtGJPlRa3SJa4lh/5q3uvH25TmSQFL+9T7KTS1mLLXS0d0HpG6f0CMVadDUI9 WCWGgDbFHUbQK0MDLV207cYKBo3B5SuFqzRNlPlFtKMfJ82iwwbkQE9gl3a7G+4K97za bBXRQsDCAbZct/Dd9MlTjiPYwZFmAe9FhQA+fKtMaeYi/F3miMk3FNOSYASSXrfm9E7O 8ZTydU9naENdw7i+YSyP9eEBiUpKNdK/cPTxxsbXMHD40nRZbcxENkOP5XIr1TyTZmem 3b37hzyudh8QfbmfLaI3IK2GwtKXADi44ce1P8Bc2Ha2GfNShoLV9eP3ma2aJfCO5cU1 JvaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788244821; x=1788849621; h=content-transfer-encoding:content-type: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:content-type; bh=OiPWX8IPpLtRRTCWw+Y69aOZxYBxv2bn93Gvyq1POyE=; b=LftOOWdo01jXaauvuuTEi51fV7uw/UEAbvYtHEXyoUf8mzPmRcQeSEMGYPfU/I0mt8 p6S+IfLjUSjEZ5m3u1URGoxa3bt1w/4Tioe8r2hO91irUrQHmG0uSNQnmLYh8dqMOrw6 +QCePXlfsscgPXAqWqwWYoQNQGCtERv6T85mNV2zIkQoqF0/1cmZB6gso4VguAOUYdSa KSK3ZS4+h8v7BQqX8xXh0xx+iwRXnvdr4oBlle/17WT9S/eCqRtJnWH7w3ysTgg3krPV xO+0ntzcBBNdq0kb9y9Fo6XQAA0FO0+7uAhKT+eq2ifdJNz7UrWoO9DuOjaZmk8LxboR cs1g== X-Forwarded-Encrypted: i=1; AKwUvBzTjK5UzoDT+3AsuA9PKLjiWu/1RmV7GjGbajklDR7mSNTlG5iEIhyr3dXVGNEutQiTMg39NUhzHvw=@lists.xenproject.org X-Gm-Message-State: AFuF++ktvxZknVxAC05ZZnFn8J7fxIaWlcgSFUUcVhOulkHq4o1XKfm5 ZmXpZlnujbHzyf+nXKdWQyvNo6Vx6b9Uwginkr+tAWS2V8wuU6ePZWVc8x9sXOs+HMfHbFXQ9/I 0fR8wWg== X-Gm-Gg: AYBFou1ArRmC4uErMlW1ttrkykZVMaMa9hyZdfRk9KXffT7tEWMxeOUp9ahDerbGSHO UUi656p1LjUHn4/0g9TImTvMx+r2/iS9MymWBn/czoW2SkHJx+/SEjkhGlOqStOQNL5u3VhbOlC +U41l5daFkCQmju3z/qCYTluYxMenteDBYXj8k/ZhpO7wCxxF2uFzvlEK2OkrU5vlQ4yY8FKZp4 cYzanc3mfJjjcm5OXqBTbis+WZJpXRm6sNQYtI7BfRe6tFNCYbQjTJw7YtEg3iyx72Sw3r2wQum M7TLVStPqeBwM+Y95OlVvLd0bGJ12Em+b3EJ1gd1r+m87wXElwUstN+Rjgb8NX93NEzQ9ivAFOI 25uwR55ZdFH3YCHY/9tQyMownsSBy25C+19GD9HCy6ybYD3OvewoN71QUiQ9P9COoAneNl57kGL mDarqQ0OGbIYhYOnX5DR+6lyDEnPJx36BnxH0Kb9AfSZ2zMFGT9mdyQiXFPvnQ2BlfSiT7wAfNE jGuzpYWsWRS14HiS6dVFW+zJA3X2Yoc8+FdrgxFhlRUIIic34UF X-Received: by 2002:a05:600c:1d1d:b0:49b:d45:703e with SMTP id 5b1f17b1804b1-49b91c2dfecmr475085015e9.8.1788244276473; Mon, 31 Aug 2026 23:31:16 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 08:31:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places To: Andrew Cooper Cc: Nicola Vetrini , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.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: <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788244821-00CCBA5B-32ACC2AF/0/0 X-purgate-type: clean X-purgate-size: 1841 On 31.08.2026 21:13, Andrew Cooper wrote: > On 28/08/2026 8:01 am, Jan Beulich wrote: >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu >> case X86_ET_HW_EXC: >> switch ( vec ) >> { >> - case X86_EXC_DF: return do_double_fault(regs); >> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >> case X86_EXC_MC: return do_machine_check(regs); >> } >> break; >> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp >> case X86_ET_HW_EXC: >> switch ( regs->fred_ss.vector ) >> { >> - case X86_EXC_DF: return do_double_fault(regs); >> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >> case X86_EXC_MC: return do_machine_check(regs); >> } >> break; > > For starters you're missing a break, and the only reason this isn't a > compile error is the trailing comment.  Second, it's a tailcall anyway.  > There really is nothing unreachable anywhere in this construct. > > But by far the most important, it the singular noreturn attribute on > do_double_fault() (elsewhere, and not visible when reading these two > functions) which is preventing #DF falling into #MC.   This introduces > fragility which did not exist previously. > > do_double_fault() would conditionally return if we ever got around to > fixing espfix64. > > So no - I'm going to insist that Eclair is taught to accept "return > some_noreturn_fn();" as intentional.  It is objectively less fragile > than the MISRA-preferred option. Oh, also: For a v2, how much of this change do you demand dropping / splitting off? Just the two hunks above, or also the one adding noreturn to do_double_fault()? Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 06:54:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 06:54:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404467.1638140 (Exim 4.92) (envelope-from ) id 1x1INm-0004mj-OO; Tue, 01 Sep 2026 06:54:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404467.1638140; Tue, 01 Sep 2026 06:54:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1INm-0004mc-Ko; Tue, 01 Sep 2026 06:54:10 +0000 Received: by outflank-mailman (input) for mailman id 1404467; Tue, 01 Sep 2026 06:54:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1INl-0004mW-8A for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 06:54:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1INk-002fBP-1B for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:54:08 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967679-2eae-0a2a0a5409dd-0a2a450cb1ba-42 for ; Tue, 01 Sep 2026 08:54:04 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96768c-f479-0a2a450c0019-d155802aa545-3 for ; Tue, 01 Sep 2026 08:54:04 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-495437bb891so5760955e9.1 for ; Mon, 31 Aug 2026 23:54:04 -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-49cdce1e1ebsm45971695e9.14.2026.08.31.23.54.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2026 23:54:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788245644; x=1788850444; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=E+EFq50Z4a1yAY4mxB84MNiXhZdCa+N60q2EwJ3mS84=; b=BrTN6WtN90VChy+NFtNhiY1Eba9Pck12jrQIzOxEuwoZaCr3MvbkAd/Tb/902t3Y9I qdJ5V9wPZFQ0XSt1EXq2qJqXhmzpi4i/+o/tGRdi8wi/9g7uJFIX0BhIfhpGjoBmJEJE KE9oF7GlgADUedE4zaLUM0ZJJmDyUKzmsyN+Sy3hXAybo5X2e71GY6ntQC2Hepuq+VNN lTV6pt9Scsh5hfFDdL0YJqULG7APWFnGejuEvIcVQ1+jMTPKgFIEGkUEminw8ExmB15h z6RwH7H0xT5TdvAHMxJJJIPGLDTfk/Q4Wlf0oiJUQBGrLibLU4bC1tsGYYY/MkeXItDL flow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788245644; x=1788850444; h=content-transfer-encoding:content-type: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:content-type; bh=E+EFq50Z4a1yAY4mxB84MNiXhZdCa+N60q2EwJ3mS84=; b=WTGytvs96yrIdgHiNlbvP3/aZRZ9/XmdylP3qE//HhyhIldmGO4BR6/wUPMkPut2B1 8Kc4ZjB95djVlChTA1LryTpIYtWtmyM2mAXNjFoT7jne6buNf5zWRPowocqW59aAEi3L gpizgCn3TUYEp1iYFupXJ6ox00rqGFxuImrmd71Euq5hrDtADyqFc3KgrCINav/I6HnU 77RxEq8TVbXJhVO8ksysIjg620UM0n1VJXNef8rm7U51Ra+qq6KN691iWDzmCLR0ZQNj sO6q3wKb6MYr7yxsa5P9SUKfHxubYBnctHA8MI0BclNBKXiso8tKt2Nu9JnBEoZE2gED KClg== X-Forwarded-Encrypted: i=1; AHgh+RrxKIWKnSp0AF6fnhZ9fA4+DeX8e7mEroSixjNFC5+OfzLF7xUtLESMzRjTFLifX1VpcU2/5Bp8bCg=@lists.xenproject.org X-Gm-Message-State: AFuF++l9Ig2D2Nq+uWjsfKRMp+VC2FvNmpRxPz6lJRu/f5xzrpuQe3ZU Uruw2SHrwZhBrPuvX8I01u6R2MhY/y0DPMDkuUNnYmiqusiIowoI9u0HAYlhFycq4w== X-Gm-Gg: AR+sD13MkczPm6uFoHq4ZKvlMylAQY6mucOvyTJt72CLbBn0GUiYD36xqANDfxauAcm bSB2S/0nfBvW+4yqVHetzdmcz+dyuI8JurZCl2QU1T2DLHNobszRKyVoT3zFSn2pFKHMu3gt7Y1 VuOHJ8BUgJIaSU2H13ipMOkMkgTwY79+rAc3v+U9rWSQ6zybxqCMvp3khnl8j6nbKpHRp26ziW8 ud34PipRSYaMgJRCEpjXl5C1cZUGe6u6tCjIsSeXA3gRYibHrnii/98G6OPbJIHUvE1UmXb99/Q 37LaLF3pGf8qEbzZLMvqJODM4HaQUx7iinmjzLG9oDwIfST+29gjJxna2kHWMzeKsWACyCtOwGN +oJQ8LLRD73GqSzhHRMpYG3VhvNwSRbxH9JCwK/VYeApirmgNVWq0LEVFUvU9IHFaTgxvu1K6dP VqJNClZVKQCYl/b3/UwwL7nmWs6rU9NvaCS4p6pc5uyAYHxRvnMywFSFiKXPJIRlaOS92n3CctL 265BjsRiubMLvJmzMAGJ6imrnFUGa+4SD1pAZNuKHOJZqUeZMoE X-Received: by 2002:a05:600c:468d:b0:49b:4eb6:6ffd with SMTP id 5b1f17b1804b1-49cdd418c7cmr39620025e9.5.1788245643640; Mon, 31 Aug 2026 23:54:03 -0700 (PDT) Message-ID: <885cb732-1814-4971-b554-9041c35c4347@suse.com> Date: Tue, 1 Sep 2026 08:54:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 02/20] xen/dom0less: turn max_init_domid into a common variable To: "Orzel, Michal" Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Oleksii Kurochko , xen-devel@lists.xenproject.org References: <5a74a964b763e8444579a3c0d455e23160be8893.1787836900.git.oleksii.kurochko@gmail.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 X-purgate-ID: tlsNG-d25034/1788245644-016C6A5B-1E3B4B3A/0/0 X-purgate-type: clean X-purgate-size: 690 On 31.08.2026 17:48, Orzel, Michal wrote: > On 27-Aug-26 17:18, Oleksii Kurochko wrote: >> --- a/xen/drivers/char/console.c >> +++ b/xen/drivers/char/console.c >> @@ -31,6 +31,7 @@ >> #include >> #include >> #include > NIT: This can be dropped - I don't see anything relying on it in this file. Did you mean to ask for asm/setup.h to be dropped here, when that's entirely unrelated? If not, the other change you are asking for could surely be done while committing (and I assume the patch here is independent of patch 1). Jan > Other than that: > Reviewed-by: Michal Orzel > > ~Michal > From xen-devel-bounces@lists.xenproject.org Tue Sep 01 06:58:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 06:58:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404474.1638148 (Exim 4.92) (envelope-from ) id 1x1IS6-0005WV-6Z; Tue, 01 Sep 2026 06:58:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404474.1638148; Tue, 01 Sep 2026 06:58:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IS6-0005WO-44; Tue, 01 Sep 2026 06:58:38 +0000 Received: by outflank-mailman (input) for mailman id 1404474; Tue, 01 Sep 2026 06:58:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1IS4-0005WI-VM for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 06:58:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1IS4-0072a1-88 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:58:36 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967790-bab6-0a2a0a5309dd-0a2a4504d2b8-20 for ; Tue, 01 Sep 2026 08:58:36 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96779c-b57f-0a2a45040019-d155dd2cac5d-3 for ; Tue, 01 Sep 2026 08:58:36 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48444ec4fe2so116746f8f.0 for ; Mon, 31 Aug 2026 23:58:36 -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-49cdce4a804sm51786135e9.15.2026.08.31.23.58.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Aug 2026 23:58:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788245915; x=1788850715; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=sXH9/Zicwqf/w37oLUncAUAq9SnbWuzie8/5/MKlMYE=; b=BMOnHexl5PMpQ5QUWMERFuHJjAvqrLiOymC+xV3zCGYkve5H5eadkAu2LY7LFxW6yI 9Y3RMrwWJIsN9AYWCInuw120RadN1ZWfBqXPr29lRAbrwZPZpwL7lK94x+dh0gmLCTBO H7uvFPmSTF0wq4k7szxDb3SrHmMF6MpU/jT6tJse9YEBSG9oCzkwk9PY3ZPlqtpi5zpi aYLvxb8NW2Kvt4JMjvSsztMswPL502qWEeuhG40R5TrJVfXIOUNSpmTU/uPJbLybGhuT xjYJpP6MI73LNBfhsniVXtRsZdrKTOgIscMMsCKKJ7+jOIcWsnZYDg4W/eVzj+IhB7DJ tz/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788245915; x=1788850715; h=content-transfer-encoding:content-type: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:content-type; bh=sXH9/Zicwqf/w37oLUncAUAq9SnbWuzie8/5/MKlMYE=; b=hHRoqMCtETrhNrSRJ4SyNttyxXwV6wUpSiFaOti6EYeG9hrQLkxKFoTGlbF9TU0OH5 v/eFwtY60Vw9LKp8C0vOCKZ4/nt/QepL+7YIAJarVQo55GkYLKUWoe2wsARFUFWy+ZNu 3MKyfeMNWWdFzC9lxKTCjRbZyZTVUE2w/D+HsMs+PqVTEdYOXAILctGBnrbrRSX/T58L 8rIBjIVfYmEHmvgJB+6zL5gXMwRDKCaaW4grV83dFO1fpekSMZht0Ct/pKaYuJYgESwk CyaQ14e9qZSsGlDt7xpvy+NFHKrchfqEq6xya/olx7Yh2xzJl0UBnyxjVsQ8m27LZGeM NYLA== X-Gm-Message-State: AFuF++nc+AbxZxNX2HbcLb2GIjdH6dVXyV/1uUQlVhHs75hhfkRnkHrZ b6j3USdtbvI6maNylfAYvVX65Gxy/aqPWgYUdbJs/PwOD9GHBaM4N+Bs04b/dHbFOg== X-Gm-Gg: AR+sD128R4LojJE9G9ElTrmLULTYVzuNDPYaHE97p8nnM2sL4JxDChMYhoiDiZD3Ga2 gHF0ztIIVUd/UOL0qt/f08xdOBrd4chxr2UxKyLapSAVPOg9zN4K9NlYqX5FeDu65nYcl+3dNGH ZJY9jozpWOTOmcOHjn/rza/sBDaM7uweg+hvw3Ok8ChZZJf6F+704epmWMoGxukd7HD3MGfPY6Z oOFjjqtvPz/V/pwBmgfjFpGZCd1tI85+RPsKhgcA4xj0aCodi6V+kts0prok+q8JbT3F9zyWXd+ b49C5vUzo/y+Q0j6B5QtEcYCqC75Mhu9gbEvHwxxDvSPOB5Hs4hY/i7Qsr96qVjgl69pWmJkH0h p2N/i9wqPXVlAsJ67oNBK5UifK8YHtpDn38qhKzCwP5ZJRfm5qc858SaN6x8vPrApmEXatt70B6 m0tql+8qd+9Bg/PpgL3N9HXpeiawhIyqA2uzfYGxOsqd/7olO5Vx+Td4K4vGy6GVQRpyUsNbVmA dX/8zY+zFp+zCOdwpuzVkhil3Vrje+BFyrl2ymTD9gDB8ybYVBY7zE1f7/e9hk= X-Received: by 2002:a05:600c:6215:b0:499:593b:a15b with SMTP id 5b1f17b1804b1-49cdc422c50mr117146625e9.1.1788245915682; Mon, 31 Aug 2026 23:58:35 -0700 (PDT) Message-ID: <779caf0f-e6aa-4076-b242-89bbb67a627f@suse.com> Date: Tue, 1 Sep 2026 08:58:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/39] xen/riscv: drop pregs from struct cpu_user_regs To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <0dc967fc4bba2dfd97a9c9ea6e60e4d5be3538ff.1787838835.git.oleksii.kurochko@gmail.com> <1788180503.8631fc262581453bbf619ec5b2062170.1a057dd1d04000c4f3@vates.tech> 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: <1788180503.8631fc262581453bbf619ec5b2062170.1a057dd1d04000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788245916-51AD0B50-34544628/10/73395122804 X-purgate-type: spam X-purgate-size: 411 On 31.08.2026 14:48, Baptiste Le Duc wrote: > On Thu, 27 Aug 2026 17:20:45 +0200, Oleksii Kurochko wrote: >> As nothing is using pregs in upstream or downstream ports of RISC-V drop >> it from struct cpu_user_regs. Once it will really be needed re-introduce >> it. > > Reviewed-by: Baptiste Le Duc Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Sep 01 07:02:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 07:02:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404480.1638158 (Exim 4.92) (envelope-from ) id 1x1IVE-00074e-Ki; Tue, 01 Sep 2026 07:01:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404480.1638158; Tue, 01 Sep 2026 07:01:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IVE-00074X-Gx; Tue, 01 Sep 2026 07:01:52 +0000 Received: by outflank-mailman (input) for mailman id 1404480; Tue, 01 Sep 2026 07:01:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1IVE-00074R-14 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 07:01:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1IVD-00Fsml-8l for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:01:51 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96785f-e002-0a2a0a5209dd-0a2a4501d422-0 for ; Tue, 01 Sep 2026 09:01:51 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96785e-5984-0a2a45010019-d1558030bc67-3 for ; Tue, 01 Sep 2026 09:01:51 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so42490845e9.0 for ; Tue, 01 Sep 2026 00:01:50 -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-49cdce1a3fesm46873915e9.12.2026.09.01.00.01.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 00:01:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788246110; x=1788850910; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=dWJvhunbu2wsQEy2Tx4KY7Dc3vJnkE4zsqOa7hH4Qik=; b=UeHzDyCN9GCaYepQD8TYzOez9FG816lUK/mz2xGkimqt7tBewa4J1d++SU0Fvcbd/q P092PBLRneRFnfeMbZ4xQYIkwSSGj+cegmn+H88LCp5/gZK1iJm7/JPn8qz6h9yPun5m 8KTwx/NZRysW2wcqE7DM1iMytJ0EGatoObdVeopvOjuymMaQyeXrsRP8BOsgZmrLOdw9 3O10YXLI9Hp/4lW+uLcjVNKiGipd1Ia8XzQdcx3wjojl600PsEyoPtbevLmYkpi7pzF9 q4LcqCK8XUkcrIfa5IqdC6oOgjUefoXRKno6goPlWHLX/spzXXTVJmv63W5FCN0aPt8N 12QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788246110; x=1788850910; h=content-transfer-encoding:content-type: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:content-type; bh=dWJvhunbu2wsQEy2Tx4KY7Dc3vJnkE4zsqOa7hH4Qik=; b=g4/lbNejf42Aq/tLkwf9W6jkHAJ+zFltm+gfnt/H2E2fwJu6WBDNDM9xZoJosTpWZx eT1d9E0iQtsfPIy8bWrFBlnn68p36ftOvWgzmz/1mDffrNGOprPiA0iOLthFHo5n4p+G oMP/CG30atST4qNzQ0qGiiyE6PxHBK+VJqrHQb0rnnsAdO9VfVSqBV+7DoZQrvEZTg0V mg4ajpPQYtkx38UKfJJxgZd9kAI1RdQM2rI1N6eGP1u9euC0Z6Qx1+MRdrtjBiO+oi8A wCkw7XCujtOWoIwzn3TUgYixs0dDu/TCowxit+E30RA5we42ChI6OT2IF7LhCuLcW39G as3g== X-Forwarded-Encrypted: i=1; AHgh+RoU33urFROYeXfqHsQMa4NtHZmxoINm/hXeHcr48DZjjyFRxFD/r0cuceq2NolbhQ/NZVRiorMl+Sk=@lists.xenproject.org X-Gm-Message-State: AFuF++kcGhuGeluPmV7nx7RR1RiVr8KDfz123bugC+v/8B/NOtIBF74s h6iB6V9OE7PjKfeqqO0SEnY8g/JyDKqqHr5zanlPJnmTYXVBrkjIiANzKacFYJBMYg== X-Gm-Gg: AR+sD12uDxLM+lOnt1OLyRMW2E/KJjq6dQUx/Vq6GeX7xM8U2z8XnIpsUiaT4QcHlop DPl6siCbOQclwkPatX0nzwOCpAkX283Npb2lgALp5y5QU4bzCXEu6WjLUwr1z6VreoCVnL22NFR vRIbaURBRQZybFxjGewsPnjWn2qK9tbBxjfdgBmlBc36CIDaxNAW/Sr+ntTAthTvW+FlUVJubum mHnHvqETXu018AMb6JwLZ9P2/ESBgyQg2ZfdfaW9vwEnQjTqHcX45SuKZOmWB5yV/nfndMqE7jd b4KrrEq9iBMrlOSVnNavOSj5K4V4mBidyOQFxuYV7dCrd/gMgpq4Eapk0Xugcxhjli6m8ZWfp5o XfXr0fx/eUvDd9NLRCim3P1JjtNcbeOQDEivdFbueZjkdNu9LAdcEK5oQ/g2KZU1h0GyZ824yIH lPKNen+w4iO33UU7zCMhpzuX7jY5sPQxMtkA1twLiOL+8LrVSyUN1P8kr9qL1ITC8EiiGP1IkAV uEFTD4cv1Z8DpJNJA8kXHAxNaJ68VR10jzpNvpupvnIaab+jgUh+A== X-Received: by 2002:a05:600c:5391:b0:49c:cedf:f870 with SMTP id 5b1f17b1804b1-49cdc555577mr113961735e9.16.1788246107503; Tue, 01 Sep 2026 00:01:47 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 09:01:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/39] xen/riscv: drop bug.h's duplicate instruction length helpers To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.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: <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1788246111-1E465757-21C22137/10/73395122804 X-purgate-type: spam X-purgate-size: 1375 On 27.08.2026 17:20, Oleksii Kurochko wrote: > asm/riscv_encoding.h already provides INSN_16BIT_MASK and INSN_LEN(), and > emulate.c uses them, so the tree carried two spellings of the same thing > which could drift apart. COMPRESSED_INSN_MASK never had a user. > > No functional change. > > Signed-off-by: Oleksii Kurochko As I'm happy to see the duplication go away: Acked-by: Jan Beulich However, ... > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -214,7 +214,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) > die(); > } > > - cpu_regs->sepc += GET_INSN_LENGTH(*(uint16_t *)pc); > + cpu_regs->sepc += INSN_LEN(*(uint16_t *)pc); ... for one I'd prefer if we took the opportunity and add "const" to the pointer target here. And then #define INSN_16BIT_MASK 0x3 #define INSN_32BIT_MASK 0x1c are really named backwards, seeing e.g. their use in #define INSN_IS_16BIT(insn) \ (((insn) & INSN_16BIT_MASK) != INSN_16BIT_MASK) #define INSN_IS_32BIT(insn) \ (((insn) & INSN_16BIT_MASK) == INSN_16BIT_MASK && \ ((insn) & INSN_32BIT_MASK) != INSN_32BIT_MASK) Furthermore, #define INSN_LEN(insn) (INSN_IS_16BIT(insn) ? 2 : 4) fails to use INSN_32BIT_MASK / INSN_IS_32BIT() altogether. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 07:03:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 07:03:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404486.1638168 (Exim 4.92) (envelope-from ) id 1x1IWi-0007Yc-V1; Tue, 01 Sep 2026 07:03:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404486.1638168; Tue, 01 Sep 2026 07:03:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IWi-0007YU-RB; Tue, 01 Sep 2026 07:03:24 +0000 Received: by outflank-mailman (input) for mailman id 1404486; Tue, 01 Sep 2026 07:03:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IWh-0007YM-By for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 07:03:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1IWg-00AeZd-Oj for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:03:22 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9678b3-e002-0a2a0a5209dd-0a2a4509a240-22 for ; Tue, 01 Sep 2026 09:03:22 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9678ba-be1a-0a2a45090019-d155dd35d94a-3 for ; Tue, 01 Sep 2026 09:03:22 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48444eff835so46217f8f.3 for ; Tue, 01 Sep 2026 00:03:22 -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 ffacd0b85a97d-48442d3d2eesm2952373f8f.15.2026.09.01.00.03.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 00:03:21 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788246202; x=1788851002; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=znwkxCkygaNyenpkhsNOCff62ZKqZHIiX1D6OEktD8k=; b=ZbMqbMm619o3FlGXW2FoeXG0stdNroZ0Ki2aAbOGQYa32nHEjvnAnF3PiOZsQvGo7S C06iBHVPBQDTCMue/Z1l2syOXZJzYs7ve5aqmbJ2y+peptQvcqL3jJBl/5/CPYlMhMYU 1bKpqEqikXHWK1eePFm17WfFngcEeqyfJuGKMuBwFYH4IiO2RPzhECDBgN7H4LdYAeMR MqGr7POJezx53AO7tq0PSW/U22BAYZrHCckKrWmdBjge/JcBI/c0wMPP53NF7j0lMgkJ AIJ0h+VU4Lkvn5+hjotochjr46dkR6FFUqS8lTmEWJMF4mI4SqofaH/wY/MrUjZdh16I xgHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788246202; x=1788851002; h=content-transfer-encoding:content-type: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:content-type; bh=znwkxCkygaNyenpkhsNOCff62ZKqZHIiX1D6OEktD8k=; b=ioosSjbM0vlW3q24y2ekspi6A0tQ5Pn/8TQULKDLcFHysJtgI0uhwO/edyx5taL3RK KfwM/ZzZBXSVBPXIxihRht7iv1qS9rpsOsnW+ZGtLaPxxIIlIRajNoLWBxYXNOSohJ2E HLw74CwrkpmJvoqWFfpUbq2HicgytJkz1/2357BxHvYJE+EV4mt0QQJUzJJSo7TCTCpY mXJO4SlDlUEO6AIZvm+jXQLo9lXjn+YjpgKQn2KmeSwQR7wTNbb4shlBiwXWnu3Rwjbv m3eT5ntkSG1tqdWdOjWDGa36apdwpXPd2LTrsDBlA8zU4dFajNg2hVFF4a9gKRGeC+Rk LByg== X-Gm-Message-State: AFuF++kSHHEDF+NBbHD0sm58i4Z8CGGOSlhhUiL2Yuw76Ed9EB0QLpcn FmmGPrISih25/37PExTaCgLrwmtLBXrQ/waqX8PlhDCfowCHzkEV+39AVEZ0wDTAAw== X-Gm-Gg: AYBFou0ttiCLvp76i1Du3zlWLdAvVUwBJgOK4tjHItv/YBPUo2CJz1hik4FXqzgfOmM qtiYpopzZDel9BidMFoZlP7Z9Rc5SaDNB6oUvTE8j0+m7dikKiZOKuK6IEM4Wdtnybv0uaNjCeL HeWaboHzS3EvJ87SJRWVoMFsNs6MDd/oP+JrIFJvrv7z03wbfmNXjK+igjbNXoX1sEYa0ja/WTc mKU0UnTVwWj9sApaCwdL7QMDcKETg1Fj8ZtMdEf0nJSJJEvQiEbCZULEWs4lEoZ18g7+BcW7Q0B QeooZ8aOIA6ekPLr6TYFLRyNtisQ+LfrZSLHDLPJ3YVnPNaULzFcJ1Q8EvomivFkzJMmOBsXQIV pSyWNc0kPKgX7B9M9cEvhjqQ4CEUfx+AGVZaaWCEjWZ4tH2U76lM7iK3WZ4gdPBvSywF6ONUUyR WX1iNgOum0YVCDgUnqsAwZ2ogvyqmYnAc55/0WMlJqNSBFVscAdKRnb1isM4tfshLINQzZJe5Vs LUV453v7GS1TFhy5T6ys2QrTA5VB4MTV7+UgX/YuNHMFkRAQOjp X-Received: by 2002:a5d:5e09:0:b0:481:3124:c71f with SMTP id ffacd0b85a97d-4843fcd85admr13917334f8f.17.1788246202117; Tue, 01 Sep 2026 00:03:22 -0700 (PDT) Message-ID: <0bbfe4f1-7cf5-4bc6-9583-367512e30a6a@suse.com> Date: Tue, 1 Sep 2026 09:03:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Baptiste Le Duc , Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@vates.tech> 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: <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788246202-3BED6034-29BD4E4C/0/0 X-purgate-type: clean X-purgate-size: 1148 On 31.08.2026 14:48, Baptiste Le Duc wrote: >> hstatus.VSXL is WARL, so its reset value is implementation-defined. Xen >> supports 64-bit guests only, so program it explicitly instead of relying >> on whatever the hardware happens to leave there. >> >> This matters beyond the guest's own view of itself: decoding a trapped >> instruction depends on the effective XLEN of the guest, as the encodings >> which exist for XLEN=64 only must not be recognized for a 32-bit one. >> > It's not clear which instruction "decoding a trapped instruction" refers > to without more context. I assume you mean decode_ldst_insn() in > emulate.c, but the patch introducing that function comes later in the > series, so this isn't obvious on a first read. > > Please reorder the series so this patch follows the one introducing > decode_ldst_insn(), or reference it explicitly in the commit message > (e.g. "load/store trap emulation, introduced later in this series in > emulate.c, needs..."). Just to remind you: No "later in this series" or alike in patch descriptions please. Such wording loses meaning when viewed in git history. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 07:07:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 07:07:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404495.1638176 (Exim 4.92) (envelope-from ) id 1x1Iaa-0008SP-FU; Tue, 01 Sep 2026 07:07:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404495.1638176; Tue, 01 Sep 2026 07:07:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Iaa-0008SI-Cn; Tue, 01 Sep 2026 07:07:24 +0000 Received: by outflank-mailman (input) for mailman id 1404495; Tue, 01 Sep 2026 07:07:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IaY-0008SC-KV for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 07:07:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1IaY-00FuRb-12 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:07:22 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967997-bab6-0a2a0a5309dd-0a2a450b95c8-26 for ; Tue, 01 Sep 2026 09:07:21 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9679a9-b7e8-0a2a450b0019-d1558035c1fe-3 for ; Tue, 01 Sep 2026 09:07:21 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49b8687630fso31729905e9.3 for ; Tue, 01 Sep 2026 00:07:21 -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 ffacd0b85a97d-48442d3b86dsm2881146f8f.11.2026.09.01.00.07.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 00:07:21 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788246441; x=1788851241; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=NUVnxOtBYA/RXn9VIRzQEU5svBiEc2AvDOpHnvcLEMM=; b=WS2zrQo4RMDC/npFjaHIJpuUd31fvAsoRaLqmZOYHjXTqqYLvlR1UqKXZJmrNqxeex I9SJM1GnCaC1OkTUGt7+K4vQZxPjVw8Dfy9PScUREDoWLmmK1NRYMSmFpk7SOyW3dF9X 3c1duARisL8tndvOnGXqyLz5fPMbY9NcPIAJsHAT60lKb0LrFz82i7+YCZ1CILSEofzJ UFJQb1JsqGzMNrkQGIePl371mHn8aIO76T5PlC7djRMqsBlRyOgo6xcPx1qzUv7NxvOr zpvUwQsxaPOXOZZfoBUhxoVKZtW1m6rVpwqpMZDoF/haEXZ9ViPfEP0L+kZsbphVPRnf n8XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788246441; x=1788851241; h=content-transfer-encoding:content-type: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:content-type; bh=NUVnxOtBYA/RXn9VIRzQEU5svBiEc2AvDOpHnvcLEMM=; b=okLBkQVA3s2KvPQetcr7PZfpZMmwfDj2soY0ZZ4TaGah4gUP6uwD014E2/C3A82RwC tkflO3dDnbkNgyntadv9CYiQARXN/Kqek4675gDv7AR3Iup41cYAkvFPBI/cqls2tqlu huAWsRckxK9IM2sH+hTfhQTjOAT2Dq8ljArmII5igWSUnOKy+qstN0kZtWdGtnMStJ+n +mEeVvaLm+UXw+WUyawZ5rErRkV5GXqR/9YPIRFydi9q9nFiBuStxJI+OuAdtfaMVMdJ iEnO/5KmwxJ7y16MhwYqXsY2B1qWcqBraJ2kZzy7vfAfz6fcwBVbBLx8XJhnagy8FXf5 cyFA== X-Forwarded-Encrypted: i=1; AHgh+RpIRi4B35GuPpsSZWt8EtMVIjTgqmZ6EmMb3w1tn6g4zmuqNmjUKDdI8fQFZ+5VW4jHEcVA/Nt7G0M=@lists.xenproject.org X-Gm-Message-State: AFuF++m/Cj8bv/6EVL6aG7FUGtMjXyfgecj74uXE4Cw2ozCz7lh+24ix c6gAMM7/keJ8QE0SdG/8mn7sHOhwMERvLCy+J/VjFCDtnmYRNbGExBGUguGYAL/BTQ== X-Gm-Gg: AR+sD111gJSy6lDJ0dwehOqhJK7kvelXfNheLZlR40RAj+JclKVZWMrh8bn72NstXgq KZU6CRgeEqHcOm/85IdOfXqrr11P8fkmlGufqdv1QxroTW9hEJIEX9rjFURVUHDTUCYFBVvaesG wmfodBtmoWt2TYDIrayViEZ/GpGzpjdWqYV6LwI7HUmQ1znqQ24tPrqk+xDfYSSIXBEZzuPE4qv V/ghFDvQBdut9gsquWGjGxsh8rYUKcPbqGccHhEhYAh84u7TWexQq4tGL2LX/6dOH7lyJgFqgLs 6lka8PQBLSehML3Yt4ilNrPA8yvXkxAhabNHKwIaNW6UNrWvWWaAJ+Yr7uZ40zDTQYs6fhdq30v rwqkBiVoXQLAiBmBh1NhrTErs7jFp0v5Gd1lCF8XTU+Dvs6BIRkUidO5Glc5F/l5cSNLIy6p4+Y x9h8KMnCY4+fcAERumzD8hw5pMjXKXYt1JgR39LeNMOD4ozQLl6UkMLPRWJurpdgECKjGCesyu+ bLjzco0hgMbwJMfojZSJV854dxRWhhCi3VlH5f7uonGfOx9Wm73 X-Received: by 2002:a05:600c:4e0b:b0:499:b65d:124f with SMTP id 5b1f17b1804b1-49ce00540f1mr38527795e9.11.1788246441413; Tue, 01 Sep 2026 00:07:21 -0700 (PDT) Message-ID: <0d04ad31-a733-4bb2-9e2c-50798de2b0f9@suse.com> Date: Tue, 1 Sep 2026 09:07:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/39] xen/riscv: introduce csr_read64() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Andrew Cooper , xen-devel@lists.xenproject.org References: <0f7080ea4dc86a8bb3dae39d94e5b03e95d010c0.1787838835.git.oleksii.kurochko@gmail.com> <91ffbf33-0b54-406f-b91f-1a96afc616d7@gmail.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: <91ffbf33-0b54-406f-b91f-1a96afc616d7@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1788246441-182F49EA-44D6AC19/0/0 X-purgate-type: clean X-purgate-size: 2752 On 31.08.2026 14:42, Oleksii Kurochko wrote: > > > On 8/27/26 5:36 PM, Andrew Cooper wrote: >> On 27/08/2026 4:20 pm, Oleksii Kurochko wrote: >>> diff --git a/xen/arch/riscv/include/asm/csr.h b/xen/arch/riscv/include/asm/csr.h >>> index 888d6a2a86d6..a5cdd6f99c8e 100644 >>> --- a/xen/arch/riscv/include/asm/csr.h >>> +++ b/xen/arch/riscv/include/asm/csr.h >>> @@ -39,12 +39,36 @@ >>> csr_write(csr, v_); \ >>> csr_write(csr ## H, v_ >> 32); \ >>> }) >>> + >>> +/* >>> + * The two halves are read by separate instructions, so a CSR which hardware >>> + * increments can carry from the low half into the high one in between, >>> + * yielding a value the CSR never held. Re-read the high half and retry the >>> + * sequence if it changed. >>> + */ >>> +#define csr_read64(csr) \ >>> +({ \ >>> + uint32_t hi_, lo_; \ >>> + \ >>> + do { \ >>> + hi_ = csr_read(csr ## H); \ >>> + lo_ = csr_read(csr); \ >>> + } while ( hi_ != csr_read(csr ## H) ); \ >>> + \ >>> + ((uint64_t)hi_ << 32) | lo_; \ >>> +}) >> >> This double reads H in the looping case.  You want something more like: >> >> hi = csr_read(); >> do { >>     old = hi; >>     lo = csr_read(); >> } while ( (hi = csr_read()) != old ); > > Good point. I'll apply that. > >> >> >> Still, this only matters for volatile CSRs, and is unnecessary in the >> general case.  I'd suggest naming it csr_volatile_read64(). > > Yes, that makes sense. I will rename it to csr_volatile_read64(). > >> Most CSRs >> can use a simple split access. > > I may have misunderstood you here, but wouldn't it still make sense to > have a macro covering the case where a register is 64-bit on RV32 yet > accessed through two CSRs? VSIE and VSIEH, for example. > > My plan was to use a single csr_read64() (but while loop then really > isn't needed in this case) call to abstract the access to VSIE, so that > the code looks the same on RV32 and RV64. > > Does that make sense, or would it be better to have separate vsie and > vsieh fields instead? For registers which can't change under your feet (or where both halves are independent of one another) the simpler accessor form may still be useful. And I really mean "change under your feet", i.e. "which hardware increments" (as you have it in the comment) is really only a subset of the cases where csr_volatile_read64() will need using. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 07:12:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 07:12:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404502.1638185 (Exim 4.92) (envelope-from ) id 1x1IfB-0001aZ-0a; Tue, 01 Sep 2026 07:12:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404502.1638185; Tue, 01 Sep 2026 07:12:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IfA-0001aS-U1; Tue, 01 Sep 2026 07:12:08 +0000 Received: by outflank-mailman (input) for mailman id 1404502; Tue, 01 Sep 2026 07:12:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1If9-0001aM-HK for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 07:12:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1If8-00Fvip-FB for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:12:06 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967ab0-e002-0a2a0a5209dd-0a2a4506eaa0-46 for ; Tue, 01 Sep 2026 09:12:06 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a967ac5-195a-0a2a45060019-d155dd2bec07-3 for ; Tue, 01 Sep 2026 09:12:06 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-484415c8bf2so358172f8f.0 for ; Tue, 01 Sep 2026 00:12:06 -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 ffacd0b85a97d-48442c42593sm3169210f8f.2.2026.09.01.00.12.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 00:12:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788246725; x=1788851525; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=whBHovxWbeQG0SPDHLaG/DLRFp5/TqHTN3XNJr1QyCg=; b=bkVGDC4BpW7ZvDgFTcv/ufZp7Rs86yZ5ma7SINXiJzRVHzbtNzYnhA/e4xcDO4+cgE QdXNgoIVK6DhJ57MdOp+ZPoZM5QEbMOpUmc/ghFVl3stFPvU/DwaMT1HtVQ1v8R/zQjT +n/xCWMboStw2ueOFzfHh+SZM9yrHRVNN5ohYBGpeNXgDkdlXFTZQ2cNERslkNj9Su7w EMcDIei1ka4X9TiWyRG2MNaL4f0mcYiDU+aD1qPLDoMWCBG0BNhC4fNa5TB6AM1BcZUF aRQ2Feh1XsNmYrZ/LPAUJhHZJ4GL7NV/el7qhpGdzBLcDFJPL5rgCie4jG5hPC72D43S CsgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788246725; x=1788851525; h=content-transfer-encoding:content-type: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:content-type; bh=whBHovxWbeQG0SPDHLaG/DLRFp5/TqHTN3XNJr1QyCg=; b=PQtJhVIHUz7gEP9hzNckulLsRyIbYE6s1P9muzVl7AE66j/RwhmM9geo6kb8iQ/e+M HyaG/qf2kIhcQsBE4efCimTh9yAsF//C6sHI/IaHtwjc7MGYAiGqGLGzM1O15tboH970 DJL5EfpJtCBUj/gIDFOqyBvYBjrqHqjdtALT6Axp8dESsOw0lRo4WE+zJn0IoUvzuKT2 LDGzA3RL+7yBBNGJTsMoPXUiHS0IdISFfhC3Zu8UGnz6wDgJOYFVwZ9+SWxkPZXaq48S 2qDu9hQzSWm3xIiX4AbTJALct1VjcfcVj1lz8PlCjPPqQN+dX5VjghUjameZOH9pgt7u t6zw== X-Forwarded-Encrypted: i=1; AKwUvBxFnjldCHE+8hBrVbQocjz2z+osf7q1yHsGN3WXlRI1iaSnVOv/iDd9N3mFipADaf91x/rCOsvmQ84=@lists.xenproject.org X-Gm-Message-State: AFuF++nXFycnVMfM9rAETygELyRSYjKKxrO1JjtX+DES+c6GkvcY1mwR 5hzHI5yOq0Kmne9luXmOkfTfHgLFEpvIdzT1g/0IWYKPvR7kweQSlEZocRveSV3lIg== X-Gm-Gg: AYBFou3qfh5kT+rkaVPjvETX+q5ED+CQKPN1l1YUxI9SriH0VoHtuWepaQ2k0dNEXRH hL0UJheN1owKdFrgPVdlwDGDHnWTgcvS24a/G+n7SGMLT79uPiJaNn+l7vrdyo3mTki12WsbEIx PrXncH0h1bkxaq/484NSaqBw7/XYSiKViziei2z0llDThZXh/iyy/rhYJ2DEPn6MolHHzNDOmLD FLOI/lDXp4mQa6XIu28qjv3ylLskK1hTkq6U2h12nuOziEAHzzISvDCLd+5DTDYrG7R3TIlovTn hnpaqcOEyoypDG+3JXtZqoq0WF0XoYLlEF/rqWKeO147K07zEnZK9T7wtvJ/53jlb/C1z9mFyN9 tsGOKjuYcfgH8T5UXLfX5MRz6ZRcpeJboefN8n++DUrf57pUbXdnmPcftj4UyrTN7TIW27gj/r3 YpT/qaGv24PfPZHkco0EalGN3t3XId6kLyMyNNeFE6FU1mif72KzLe5b8tTAAnN/5W8RFcpyuDs UILpWHz0ZNBHpgk5cDOaaJ6tSGl9wqDt0sIUubQ0pnEJDymKO4fQA== X-Received: by 2002:a05:6000:41dd:b0:484:3311:6f68 with SMTP id ffacd0b85a97d-4843311735emr31989123f8f.25.1788246725107; Tue, 01 Sep 2026 00:12:05 -0700 (PDT) Message-ID: <5ed7172d-24e7-4ace-964e-dad814c2dc6a@suse.com> Date: Tue, 1 Sep 2026 09:12:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 06/39] xen/riscv: use UINT64_MAX to disable the VS-timer To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <93829c39b080d288ea342c7375d5307f93ee9a29.1787838835.git.oleksii.kurochko@gmail.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: <93829c39b080d288ea342c7375d5307f93ee9a29.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788246726-1F2C677B-4D01AA2D/0/0 X-purgate-type: clean X-purgate-size: 908 On 27.08.2026 17:20, Oleksii Kurochko wrote: > vstimecmp is a 64-bit CSR independently of XLEN, which is why it is > written with csr_write64(). On RV32 that macro splits the value into > the vstimecmp/vstimecmph pair, so passing ULONG_MAX (0xffffffff there) > writes all ones to the low half and zero to the high half, leaving the > CSR at 0x00000000ffffffff rather than at its maximum. A VS-timer irq > would then become pending as soon as (time + htimedelta) reaches 2^32, > which is exactly what the code is trying to avoid. > > Use UINT64_MAX, which matches the width of the CSR. On RV64 it is equal > to ULONG_MAX, so no functional change there. Hmm. This again is an example where code (likely) will be silently wrong for RV128. Presumably the CSR would be XLEN bits wide there as well, and hence you'd need to write it with 128 bits of ones. Imo ~0 is what wants using here. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 07:14:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 07:14:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404510.1638193 (Exim 4.92) (envelope-from ) id 1x1Ihc-00026e-CR; Tue, 01 Sep 2026 07:14:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404510.1638193; Tue, 01 Sep 2026 07:14:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Ihc-00026X-9r; Tue, 01 Sep 2026 07:14:40 +0000 Received: by outflank-mailman (input) for mailman id 1404510; Tue, 01 Sep 2026 07:14:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Ihb-00026R-5B for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 07:14:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1Iha-0077jl-AP for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:14:38 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967b4c-2eae-0a2a0a5409dd-0a2a450a98ea-44 for ; Tue, 01 Sep 2026 09:14:37 +0200 Received: from [52.101.52.37] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a967b5c-f2d2-0a2a450a0019-34653425f758-3 for ; Tue, 01 Sep 2026 09:14:37 +0200 Received: from CH2PR08CA0016.namprd08.prod.outlook.com (2603:10b6:610:5a::26) by DM6PR12MB4268.namprd12.prod.outlook.com (2603:10b6:5:223::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Tue, 1 Sep 2026 07:14:31 +0000 Received: from CH2PEPF00000147.namprd02.prod.outlook.com (2603:10b6:610:5a:cafe::a6) by CH2PR08CA0016.outlook.office365.com (2603:10b6:610:5a::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.13 via Frontend Transport; Tue, 1 Sep 2026 07:14:31 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH2PEPF00000147.mail.protection.outlook.com (10.167.244.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Tue, 1 Sep 2026 07:14:31 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Tue, 1 Sep 2026 02:14:31 -0500 Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Tue, 1 Sep 2026 02:14:28 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZQBNNJwKY7uCAI77/3/Tg1hO389FjLsDNsYGHVV1Jir69lQ8sOm5iBdQ/0AQO+olYpHJOtMZTc9ExZ2tQ7b2FPDx2vQZNDQPZihSHmm7huts5JRtDJGhzXxfQnADKAK38wxwcWy4ELiKbrcqUBXMBvdwIpp3e8JWqtvo2FxM2dHOsccASYI4JZBOQbSww9beFFPtRD/+z0sF34wLFtrcqF2dgiMEQcoArUQOSzFfyf5mJmqTT31XTSNQcnbzifDArSUUK1rqRQ666mVShGqJhOCpAzWcCc58W2emNGMFSKe7Cz51CBAvFwTh6I2+kcJGeOW9RUMJUfIz4MxJdYcbEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OoN2vw3UDsC1Lz/MWTRdE/XcswW4onF/0rl1nUHfALM=; b=Pp1WknXrKAAbC8S8MSTWeJ9IGOTl5/mzXUx/eNhoNqFMhBuSE7wUxyWiEhXHlxbN+eDoSHZAAyHq8sKD+u3UXKNmocjbXl7vQo3uUhVi9cQiDoWrAb8XCIuUJ1XFs/hsh1rpcqeZWGK/Y1TlA8pNnW9acpj1YpBPtu5JptNZZ9MObnWPRog/pdEzu5/KjqWBzJtYGPDN735exvPSfkDumlczTuvaTYFIOxUaxXjfbMu38BuNLorxhGEg0beBICVyj874WsGvYhJPDvMyK5jVDA15aFik5To2FjVJzMrUlkPdqTBnrAI1EU8Yb0xRcAVt0funC/wILBBEh55WX2gD4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OoN2vw3UDsC1Lz/MWTRdE/XcswW4onF/0rl1nUHfALM=; b=B7nWixRbzxwpaBTvIL3gANQQTshSlVur+lR3yWq2B5QU2hfUK96t59+qssZcvmZaaHBr7J1w9mcWKMaZD/vUXURBkrELh/88oFXp8J4DbofeXQPI9il6G4+G36MCgsq3vuJXD9PwpZ0yvX9Jx6kiqKZCAqTagSmRClQW7Xxev8E= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <8737a6d8-cab7-4aab-9bbc-d5b155a4a076@amd.com> Date: Tue, 1 Sep 2026 09:14:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 02/20] xen/dom0less: turn max_init_domid into a common variable To: Jan Beulich CC: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Oleksii Kurochko , References: <5a74a964b763e8444579a3c0d455e23160be8893.1787836900.git.oleksii.kurochko@gmail.com> <885cb732-1814-4971-b554-9041c35c4347@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <885cb732-1814-4971-b554-9041c35c4347@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000147:EE_|DM6PR12MB4268:EE_ X-MS-Office365-Filtering-Correlation-Id: 547da5e9-e8ff-4146-d306-08df07f8ab34 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|1800799024|23010399003|376014|7416014|18002099003|22082099003|56012099006|11063799006|10067099003|4143699003; X-Microsoft-Antispam-Message-Info: r8yVAo6EnzsmaiyA685cd2XEu9pi3PoboeK6AGZlkESrACr4LQoz3gI8h/1eWfvVsDBCCkzOO5FJWfckfD8deI7Hq0AZF3KeHvR/AxIb88G2aKLfm0Tp/81qN154jaFDDwVRHOH4tYeWlXRHfbdwhYCDaeES0RRYvgg405KxgJwnx2/87wfHvTWyl3/TKfXQMVgs6DnApweDVcxQUIZgOZfZTCzhy0scFsUH8v8506UJnLMSdrcfC/wZGjZHDgCYdKt2F2bPgGztgQkiUglW1dtVGHBQDDNjXXrqqdsJ4mNbLx/bwlo0qkiptmqFujyz2TAhCPLWOMxrqfDYdM/NxhSMMZVpWJXP6WI6Gjv89casVTlkv/+F6A8uE7YX5haidDsFjsQ1F+zU2hO5SavzWcOAPdXrAt0mTgEwdHAUb0DzdOrZLRwmKDOBNotqOPyrT4xT778ljD73kfV5p23zn3yAQyABpeyXp7FF12mMDCkwq8oLsq6hBGOxOx3qo98R4Y9Q0am5xcO4vSp1Vy03YQB2wiBAJVfzyeNRSCPMOza9Xx1JAcAzV7xkwGC8S82EFZp22U/Hf58eDaqbWam4V27ZP2HmAQp5Xx33gr8DD8Q9CFv3t8nl8LzyL62UyjgtygYfZi166rTToUGOiZBePAzLj11vv0SJzTZZtJId5fBjwHPp/QH2hCY6c48VP0hT X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(1800799024)(23010399003)(376014)(7416014)(18002099003)(22082099003)(56012099006)(11063799006)(10067099003)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Jml8CdnC4ZN8V5wbOz++bJ9ctSv8/kVw+63o2VdBC6NsSelKYmzhL8Ov/i2e0WZNVc/vpDdfuLufSMhhPMukkX+QlY+5TiM9iBk1K8i3BgW97wMiPDe/SfjH8Zd8vL6GsIhvy6QwVYCK9ynNF/E1OwZLo2jJ89Wgkf/oyomndRSp837C10W0+T4AV0cIPPOFnR8wsMSCm4licGg1lznzgwL6P1Bx4a7Dsvzck6AztKmYEoEzrYAX9euI0S6g9NioZvykFybk0EZb+13mOGlJaT5mXrbPc5xgUPgwU+RmM2norAEvZMzqkdk3/qPuf8N7CArJIl18Yp/EBfDp2OqRjLd1Gvx4+Er/7CWU3ci75lK6KYy0U4fx3bZgiB5cDXgXAJco7LiJouimwNpDOz6UGo6Jy7+xQf7TFEcV1kclJDdv//AAoQqj6X9ZZMQkOiW3 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2026 07:14:31.4998 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 547da5e9-e8ff-4146-d306-08df07f8ab34 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000147.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4268 X-purgate-ID: tlsNG-4011c0/1788246877-528DDCFC-96E49128/0/0 X-purgate-type: clean X-purgate-size: 1134 On 01-Sep-26 08:54, Jan Beulich wrote: > On 31.08.2026 17:48, Orzel, Michal wrote: >> On 27-Aug-26 17:18, Oleksii Kurochko wrote: >>> --- a/xen/drivers/char/console.c >>> +++ b/xen/drivers/char/console.c >>> @@ -31,6 +31,7 @@ >>> #include >>> #include >>> #include >> NIT: This can be dropped - I don't see anything relying on it in this file. > > Did you mean to ask for asm/setup.h to be dropped here, when that's entirely > unrelated? If not, the other change you are asking for could surely be done Why are you saying that this is unrelated? Before this change `max_init_domid` declaration was in asm/setup.h and this was the reason for this header to be included here. With this patch, the declaration is moved to dom0less.h and therefore asm/setup.h is no longer needed to be included. I consider it very much related unless I'm missing something. ~Michal > while committing (and I assume the patch here is independent of patch 1). > > Jan > >> Other than that: >> Reviewed-by: Michal Orzel >> >> ~Michal >> > From xen-devel-bounces@lists.xenproject.org Tue Sep 01 07:22:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 07:22:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404520.1638203 (Exim 4.92) (envelope-from ) id 1x1IpG-0003i9-48; Tue, 01 Sep 2026 07:22:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404520.1638203; Tue, 01 Sep 2026 07:22:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IpG-0003i2-1E; Tue, 01 Sep 2026 07:22:34 +0000 Received: by outflank-mailman (input) for mailman id 1404520; Tue, 01 Sep 2026 07:22:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1IpF-0003hw-5h for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 07:22:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1IpE-00DPb2-8N for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:22:32 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967d34-2eae-0a2a0a5409dd-0a2a450bba62-18 for ; Tue, 01 Sep 2026 09:22:32 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a967d37-b7e8-0a2a450b0019-d155dd2fec3c-3 for ; Tue, 01 Sep 2026 09:22:31 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-484415c8bf2so364467f8f.0 for ; Tue, 01 Sep 2026 00:22:31 -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 ffacd0b85a97d-48442d7e34csm2878518f8f.33.2026.09.01.00.22.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 00:22:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788247351; x=1788852151; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=olYo8LaVbdFJy1HDb39WJ4XYsyGY8RXYwu6vx1NCMpQ=; b=SHZip8cxOBCz2qzhCSo89KODLkYgA+VJpHTWBaV84Hytv9WvFEotcvVInE4nR/0qEu TcqM8Y5wzNIsb3Vhu7w6/4sFUjFRV3Mwpz3jqQP1P8+uZ64kl7kS5F4PUO+JrI7wWOm2 nkRd1AIvPxDurs3Gb7H8SKBs6MQ5gOo1Ig6zHnQ3COlzXWNeM4CNZ3babB5C3m6EY2r7 9g6Vh/c5mFYqiKuLwXb/gLlf8xtP98sL/6G8x739+AyMfq1Idmqu8XlP8vO6RTUXvdNr zN0JwC0ySSqHpcGhyfzVcuSI1kXloSzCdcCMDtNSwGS+cfhV7DVJ8nqFnZ+qI0anUdua JKPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788247351; x=1788852151; h=content-transfer-encoding:content-type: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:content-type; bh=olYo8LaVbdFJy1HDb39WJ4XYsyGY8RXYwu6vx1NCMpQ=; b=I9Az5hnuRf+OJrdgojlTOimyhxXcGZ6MNrnzOS8ELwi9dDyaD4tafG1XSiBZaLtFdL kaf3m0mDOrNaU5hJTdfnD2WWp1y6J0uyfmhxtJBp08HQHT77v8tdFqtOHec5g6KH/iq6 a/gjrcMR7/Y7I6nFNwGyhDC8aO6HHOySiL6486NA9VEsb+TtjXimEiQvQ71mGWozxsHE Vy5LSBuqY4rMBW9QvCGC3+nF+NSup+ZUDxBOHwgA3hK2+MVQhPY8r5Yyca3HZa8eQZ2K sETx7l5UJvezdYARk723T5YYFpcHvTD5cXFizyJeKGQzp9m09TJz3KzLjwokwiEQ6ock KC9w== X-Forwarded-Encrypted: i=1; AKwUvByt/tIkJOkd7H/HQJyd21LtYBmYtRDZ5wY7byM5fPyn92s818iDK3MWcggzTUEsS4EXfjxUTJ969v4=@lists.xenproject.org X-Gm-Message-State: AFuF++nsi5wJmZyOXKWlbU6+mWS4DCUtWktAOeeXM9bUpg8j1A3djStB KSQTKKrnfWrbTTbucA+EXinkzLUioAM2qrhbHxMp+By2uMF/mQWmayG1cbMlPgF891lEU0SAsj+ PaW9zAw== X-Gm-Gg: AYBFou0bJQXMMioSNJIrC1r3qi2s4gShjmVh4vpmQd3c38vXFIVLdOQhaQUbrSAQLQp 60SYkayPEFnfIfNSoNM2Dru1S6+ar5kMdGC6b6HTiwvvF1OPIS6Ee+c+4ryuJ9TobrnjvpK6gL/ RNFGiYAUqeoJdJ/oky1jft934d6924oXqlEG67lBlq4WnkTUzb2scYO2ofquzVLJbDmySK6zms5 paej8A5WPhBsraJJR60798Rmtst+CTHN4Ekqpr9ArG43n+qxsGOMfw4F+4W4e4PCZT13Lhd9KKx 0cVedNYtBS4v7+AkTDZgS2p3V3kt64wh9baJxN0aSLaPohpCkqWMReOYk13Lr0fQefEbUlO6921 33PdQDjywEQiF07/f7YmJuIKTQOU8FBqGaTry3d9tp0tule11CwHLIDmGndImrDfEgLmxTn5vkQ Z0cE+AMAOyCok0H2Fn3UvSvh2967W/pBQAFgGoGGCR/9eAQ+doNyGQFmeL+cx9FOA/5OpBxlrHx fiZCskrtP7v8+2OSzhk6cz0Pck1MI98M+QlJkzUEbaZ47dyy6m7 X-Received: by 2002:a05:6000:18ab:b0:484:41cb:d5f0 with SMTP id ffacd0b85a97d-48441cbd742mr6715047f8f.17.1788247351183; Tue, 01 Sep 2026 00:22:31 -0700 (PDT) Message-ID: <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> Date: Tue, 1 Sep 2026 09:22:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Andrew Cooper , Furkan Caliskan , xen-devel@lists.xenproject.org References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@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: <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1788247351-1A4DB9EA-7687AA13/0/0 X-purgate-type: clean X-purgate-size: 2665 On 31.08.2026 14:59, Jürgen Groß wrote: > On 31.08.26 11:45, Andrew Cooper wrote: >> On 31/08/2026 6:16 am, Furkan Caliskan wrote: >>> Every vcpu_create() call site that builds more than one vcpu loops >>> over ids up to d->max_vcpus and stops on the first failure, but none >>> of them roll max_vcpus back to match. This leaves d->vcpu[i] == NULL >>> for ids below max_vcpus >> >> As I told you before, you must cope with this property in non-error >> scenarios. >> >>> , which anything walking d->vcpu[] can then >>> dereference. This is what caused the crash: sched_move_domain() >>> walks every vcpu slot up to max_vcpus without checking for empty >>> ones, so when a domain built in a non-default cpupool had vcpu >>> creation fail partway through, domain_kill() later moving it back >>> to the default cpupool handed one of its empty slots straight to >>> the new cpupool's scheduler, causing a NULL-pointer dereference >>> inside sched_alloc_udata(). >>> >>> Add vcpus_create(d): creates every vcpu of d up to max_vcpus and >>> rolls max_vcpus back to the failed id on error. This keeps >>> d->vcpu[i] is non-NULL for all i < d->max_vcpus >> >> No, it really doesn't. >> >>> , instead of guarding >>> every reader of d->vcpu[] agains holes individually. >>> >>> Convert every site that builds vcpus in a loop to call this function >>> instead. >>> >>> Fixes: 61649709421a ("xen/domain: Allocate d->vcpu[] in domain_create()") >>> Suggested-by: Juergen Gross >>> Signed-off-by: Furkan Caliskan >> >> For the avoidance of a long drawn-out argument, nack.  Under no >> circumstances are you editing d->max_cpus after it's put into the domain >> list. >> >> You've chosen to do so at a point where the domain object is live, >> visible in the system and able to be the target of other hypercalls. >> >> Furthermore you have not fixed what your commit message claims. >> d->vcpu[...] is still NULL for an arbitrary period of time, including >> being able to be the target of hypercalls, before vCPUs are created. >> >> All code MUST be able to cope with d->vcpu[...] being NULL.  It's how >> the object lifecycles must work, because creating vCPUs is not atomic >> with respect to creating domains. > > Would you be fine with me creating a patch series moving vcpu creation into > domain_create()? This was discussed before, and however nice it would be for the issue at hand, it would get in the way of us wanting to have CPU policy for domains put in place before vCPU-s are created, such that on x86 the XSAVE area can be sized once and for all. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 07:26:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 07:26:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404533.1638211 (Exim 4.92) (envelope-from ) id 1x1ItA-0004NO-Ln; Tue, 01 Sep 2026 07:26:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404533.1638211; Tue, 01 Sep 2026 07:26:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1ItA-0004NH-J5; Tue, 01 Sep 2026 07:26:36 +0000 Received: by outflank-mailman (input) for mailman id 1404533; Tue, 01 Sep 2026 07:26:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1It9-0004N9-9Y for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 07:26:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1It8-00HGN6-5t for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:26:34 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a967e1e-8faa-0a2a0a5109dd-0a2a45088454-22 for ; Tue, 01 Sep 2026 09:26:33 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a967e29-f659-0a2a45080019-d155802bc8e1-3 for ; Tue, 01 Sep 2026 09:26:33 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4956869750eso29465625e9.2 for ; Tue, 01 Sep 2026 00:26:33 -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-49cdce10148sm45772695e9.5.2026.09.01.00.26.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 00:26:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788247593; x=1788852393; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=nrnB7ehHghPyMBvV43bgAIx2p0LAhKrgbOKYigT7tLg=; b=MBrbJzBg8w/0J8kjO05F4Nxjx1ca1EcrmKxkX46H3zV5aQyum9wQHJiO2kTZiWAflE Cm7lf7H6yJTVfT2F7wIhXXuEP5y2RUJJCS8sa2ERJArwk57nTwmnkgmuYmkavOVGMO5t xpUDOnVZ5C7mlZQsVTV4456FIWhKOCACNS+VKn1tMDQ1XXJJxTAGa94YTic0WDrzE7hm APC0RDyeXy1fifIHpHeoRy3ed5GfsymXkNUfXZDjgxffhTW3XN8wov7JQ7779hw1zZN4 sHHkGe5FAYQyBHvv4nueWbDxx5fTMJ4cYLcOjHayKTFy2bSMDmLcOavu+mdou2tbQdB+ gBfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788247593; x=1788852393; h=content-transfer-encoding:content-type: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:content-type; bh=nrnB7ehHghPyMBvV43bgAIx2p0LAhKrgbOKYigT7tLg=; b=qtYvIgd+ckNrPnx6rnIFTRHoQzP6IqJa6Bkxehivw3RHAoLHmrzM3CsUc378R91xEh HmFlm8IZFQS36c3rBU7G2+A/f7ef3vWBx9yFbuYdLgy+z1SPFLxTZ+N1YMZjGJMp6VLU 8I2kHSC/DN0Cv6wINf4u0/ONimHFOtyhD6bjT3Ww2iBq7V2vPzZa3BeSRz0zXYVYZutK jfkTmD7N2fCmXDLybURYZU6u4iCs7Vu+c6cKxd/O1TU/ZEfJDmRBv6tt7bYfROXdGnlU wPmm/BS5E53oF3gR/zcvKwJ1MACfidIu+kaCcD11lVWizFdy74/6yHWI/Uho7Mytvztg Ikrw== X-Forwarded-Encrypted: i=1; AHgh+RpfPeku9o1xfBvd3mirjT3rhNhvJjeMKOrYv6nCy023o4G3qgk4kkeDxbFft1CnPRFiRc+XDbIWB78=@lists.xenproject.org X-Gm-Message-State: AFuF++niYKBOVrwpzG3cfnYdohaaLSsLvdA0jzOt87YK2BOfy66QBrjt P2yM3Aq5Gj1vjyk9UUC9igdFibfIdueu0vpMILebqcDmUwn+dWu5vSWMAJIAzTsw9A== X-Gm-Gg: AR+sD11ATVLrnuLjNYZMLdcjdofIYUKTKH4D0SMCvgrvEOCW574CAjDrT3/hSl0pPrz z3vHsV3r9DolWM+CUqd0oJ6ELVRfWIjTv2zB6se/G2ZBmSQdcjYIFx0FxjOsWSO4dg5FRPwTEjM JVEozi3kZoCy1+noFyXCiw89esgN4Awbf2FDbpbtx8dMXDbQXn+WVaiyTFCi+ysh+SzXtcAsYCy JrlYcrwaXMJ+rA7iQYO6gLwjH91urGRffq4q/lPSbQixxJy061XhAUHkyZTjr8Y34G9ZRTJWjlJ ovaCOLUSn5LnYtCfTHD6DuEOVvYYVM1akCf8iVG1tqwiDTwt4BeWBRlDM81wmdiOrkg1GrM49dS N3wpxN6BARXegwxLtchZLY0jMa1z4h6bipudmjd0qvEdC+5fTazmq9xTzcom5Mhy8WkfvLgkmRn i/eLRHev2dAp3PcfbT6c1B2Nzj04v+JHmj0kyptNDJRUKwhqnN/igbT6iFiBA7DZOQVuFvIe4Cp ut/kuzsR89by4IJal5mbbIGzk4Teu1h9NxnF77ErGotWqCbKaok X-Received: by 2002:a05:600c:4f92:b0:49b:90cc:3c87 with SMTP id 5b1f17b1804b1-49b91c487b2mr488324785e9.13.1788247592707; Tue, 01 Sep 2026 00:26:32 -0700 (PDT) Message-ID: <351a5219-16e2-4eb8-8cb0-0f5a3b0a3f2a@suse.com> Date: Tue, 1 Sep 2026 09:26:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 02/20] xen/dom0less: turn max_init_domid into a common variable To: "Orzel, Michal" Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Oleksii Kurochko , xen-devel@lists.xenproject.org References: <5a74a964b763e8444579a3c0d455e23160be8893.1787836900.git.oleksii.kurochko@gmail.com> <885cb732-1814-4971-b554-9041c35c4347@suse.com> <8737a6d8-cab7-4aab-9bbc-d5b155a4a076@amd.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: <8737a6d8-cab7-4aab-9bbc-d5b155a4a076@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788247593-D6F5F87B-36794E49/0/0 X-purgate-type: clean X-purgate-size: 1223 On 01.09.2026 09:14, Orzel, Michal wrote: > On 01-Sep-26 08:54, Jan Beulich wrote: >> On 31.08.2026 17:48, Orzel, Michal wrote: >>> On 27-Aug-26 17:18, Oleksii Kurochko wrote: >>>> --- a/xen/drivers/char/console.c >>>> +++ b/xen/drivers/char/console.c >>>> @@ -31,6 +31,7 @@ >>>> #include >>>> #include >>>> #include >>> NIT: This can be dropped - I don't see anything relying on it in this file. >> >> Did you mean to ask for asm/setup.h to be dropped here, when that's entirely >> unrelated? If not, the other change you are asking for could surely be done > Why are you saying that this is unrelated? Before this change `max_init_domid` > declaration was in asm/setup.h and this was the reason for this header to be > included here. With this patch, the declaration is moved to dom0less.h and > therefore asm/setup.h is no longer needed to be included. I consider it very > much related unless I'm missing something. Hmm, fair point. Yet I'm then still somewhat concerned that asm/setup.h may have supplied something else. IOW I'd thus rather leave it to Oleksii to make the adjustment in v9, once suitably verified to be correct to do. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 07:53:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 07:53:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404549.1638222 (Exim 4.92) (envelope-from ) id 1x1JIb-0000pO-Kd; Tue, 01 Sep 2026 07:52:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404549.1638222; Tue, 01 Sep 2026 07:52:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1JIb-0000pH-H9; Tue, 01 Sep 2026 07:52:53 +0000 Received: by outflank-mailman (input) for mailman id 1404549; Tue, 01 Sep 2026 07:52:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1JIZ-0000pB-Ma for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 07:52:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1JIX-007Duw-UF for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:52:49 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96844e-8faa-0a2a0a5109dd-0a2a4503bf38-6 for ; Tue, 01 Sep 2026 09:52:49 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a968451-fae8-0a2a45030019-d155dd2eac14-3 for ; Tue, 01 Sep 2026 09:52:49 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48444ec4fe2so147624f8f.0 for ; Tue, 01 Sep 2026 00:52:49 -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 ffacd0b85a97d-48442d6e826sm3117389f8f.19.2026.09.01.00.52.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 00:52:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788249169; x=1788853969; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=pVYNqUMt5NqrmKcdYt4k7AXKHi7zEjXkuK3vr+rlOhY=; b=ZJAqSkhDnBAOdBteFYleaY786pkf5csdsMpRLCcBcfqbPtgn8Fjf8DeduRjNjfo7Yr jvuz55mfRvXhgVifCZ8WjNq2UY2lZ8RECdjQ0ObGvX8dTJfl7Ejc9wnvQvIYT+eHxirs YQY53R1c4zlxhzAuYFtjSoea/SZPEKDVYc66o3X4j5/oP1U1Gq/eg5T7uhOX2hX2HZ3s 9zKik2MZQHZuB01lD5St6i714tiGXfqs16yGMHbuyorf7MjfvpIg/SSGqY1O7m7JB71t PHuIiqckL7vQ7UBVMn+MxcG9LqV/OTHL84zPmqW7uOH9i+a3iva4n4Z6JiwAC0aFbxa/ tiAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788249169; x=1788853969; h=content-transfer-encoding:content-type: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:content-type; bh=pVYNqUMt5NqrmKcdYt4k7AXKHi7zEjXkuK3vr+rlOhY=; b=HhweC9jOJqBrEKI0xnYJffyhG9/ZAwKmDZ/1CYtR62Y/gL9KmggB3Uqc9RMQ9L7T4C ofo/4wyBH2jyJ80YfTUlDpOVORVw6SGr/qkwGkINwiYXvWBUEbNt4wKwtemU+BmGp7Jn gjv1ZW2Hz8yXl806xbHMsVf2+fvwykP86RdtxY/DdOCKiimI06ZwxicFNokFPjai/1bx 1T6dZifWSz/CE8mIEc08nT6I0K7IfBJRwemd+9DS3xJ/r59Rc4IU7Oaqav/kEM8YLnwQ cNbwP6LRabVN2nsA8ZBjJOFcDCGkAWLJf6Jh+K8pNt0KkJVN0jUOsIlz+nQDedpMC+oE 3piA== X-Forwarded-Encrypted: i=1; AKwUvByo9GMLeIMwg2Qyxo1vWMyYxcbm3PdbEPKF7lxRFGooYK18+BggRj+pRMpyvdp7K17TIY5vhM+pJVM=@lists.xenproject.org X-Gm-Message-State: AFuF++mFw3g7sKn22wG/k9kX+wbRdcPm5fq8DcYT/NYrVBhFMJjMQGnG 3JXpvWP9nQI43LPKegLbeGwtJEK7WB+CXWbFdq9VtpvGLgQmb/Y31mnJUKDJO1AL+Q== X-Gm-Gg: AYBFou1jdJ0F37nTSu6fIQCRV1gAiJf6NUCUu4fTpJnSRYKtecnhUAlNKlVVsyXpaM6 tKsTELYyC02NlNFiCnV9cnk8ZcGdVeOdon3gXA2PBqzafuoNS3z01wvwejr2F9ZSE+rCHQ7C1zo CEtShDV/hU3hsYXJol+tKwnNEz51fbRIK6UFItyvgc8Pr8QjSDFdlN7CG7eSdsBMjHtAoMRVZf4 0+c50mnMFegW2x1tq5y7kb/5uvikiSg/hdmIBxb2u/m9hmLoTUzHV9JEMtYrAwORq9QgrYtQ4P0 XIw7+/gnwRnWJGbd2zFjwVFHLU+7n+RIzAi9leiNruTsl6RLIse3nHHpWiOUtqwvUur5CpcZmXy gsSUCjA1s/PyGKfjjk/QuGASz4cgMShNNDNjUqFViRprBLubJjabFombs23Wz+k8bSlXf32FDSe csUMyGE3g1mDowRivLnOwhyrEJb+35Cba7oUwPdX67Brqas8uoD5TzP0bEPP9cnkF1z6c6DaDqA QK4jsMy1lGQ6bcePyC104wKEkc+sudELXORzdq7BQnqiKdfbs+S X-Received: by 2002:a05:6000:104b:b0:484:3200:b7a1 with SMTP id ffacd0b85a97d-48440ff9366mr9577704f8f.13.1788249169278; Tue, 01 Sep 2026 00:52:49 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 09:52:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 7/7] RISC-V: place .sdata / .srodata / .riscv.attributes To: Oleksii Kurochko Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alistair Francis , Connor Davis , "xen-devel@lists.xenproject.org" References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com> <0d0c6a5b-94a5-49c6-a150-3bb6a0dc3b93@gmail.com> <8eebbdd6-d414-49eb-83e6-668f187e6f93@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 X-purgate-ID: tlsNG-33051d/1788249169-6F8C54E9-A10EB7F6/10/73395122804 X-purgate-type: spam X-purgate-size: 2336 On 27.08.2026 18:07, Oleksii Kurochko wrote: > On 8/27/26 5:56 PM, Jan Beulich wrote: >> On 27.08.2026 17:40, Oleksii Kurochko wrote: >>> On 8/26/26 2:04 PM, Jan Beulich wrote: >>>> --- a/xen/arch/riscv/xen.lds.S >>>> +++ b/xen/arch/riscv/xen.lds.S >>>> @@ -44,6 +44,8 @@ SECTIONS >>>> >>>> BUGFRAMES >>>> >>>> + *(.srodata) >>>> + *(.srodata.*) >>>> *(.rodata) >>>> *(.rodata.*) >>>> VPCI_ARRAY >>>> @@ -92,6 +94,7 @@ SECTIONS >>>> SCHEDULER_ARRAY >>>> HYPFS_PARAM >>>> >>>> + *(.sdata .sdata.*) >>>> *(.data .data.*) >>>> CONSTRUCTORS >>>> } :text >>>> @@ -162,6 +165,8 @@ SECTIONS >>>> /* Section for the device tree blob (if any). */ >>>> .dtb : { *(.dtb) } :text >>>> >>>> + .riscv.attributes : { *(.riscv.attributes) } :text >>>> + >>> >>> Nit: .riscv.attributes is SHT_RISCV_ATTRIBUTES, i.e. non-alloc. >>> :text on it is misleading, and without an explicit address it gets >>> sh_addr from .(location counter) after .dtb. Could we use matching the >>> idiom used for every other non-alloc section in xen.lds.h: >>> .riscv.attributes 0 : { *(.riscv.attributes) } >>> No functional difference either way (objcopy -O binary drops it, and I >>> verified a non-alloc output section doesn't advance dot, so nothing >>> downstream shifts), so purely consistency. >> >> Well, I compare attributes rather with notes, which we make part of a >> segment (on x86 at least). I can drop the :text if it's that what's >> needed to get this in, but I'm not fully convinced. But my knowledge >> on the purpose and use of attributes also is still somewhat limited. > > As I mentioned from functional point of view I don't think that it will > be an issue so generally you could keep :text here. > > That why I wrote "Nit:". > > Reviewed-by: Oleksii Kurochko Thanks. I decided to drop :text, after all. The linker actively ignores it, producing a PT_RISCV_ATTRIBUTES segment which the linker script doesn't even ask for. That likely is a linker quirk, yet at the same time the linker script likely means to actually spell out an attributes segment (to which this section then should be assigned). Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 08:07:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 08:07:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404566.1638229 (Exim 4.92) (envelope-from ) id 1x1JWY-0003Um-6f; Tue, 01 Sep 2026 08:07:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404566.1638229; Tue, 01 Sep 2026 08:07:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1JWY-0003Uf-3q; Tue, 01 Sep 2026 08:07:18 +0000 Received: by outflank-mailman (input) for mailman id 1404566; Tue, 01 Sep 2026 08:07:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1JWX-0003UY-9E for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:07:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1JWV-00G8Re-RD for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 10:07:15 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9687b0-2eae-0a2a0a5409dd-0a2a4504bc2c-20 for ; Tue, 01 Sep 2026 10:07:15 +0200 Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9687b3-b57f-0a2a45040019-d155da29cda5-3 for ; Tue, 01 Sep 2026 10:07:15 +0200 Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-c1677c91969so429467266b.1 for ; Tue, 01 Sep 2026 01:07:15 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c255f1b1fdasm555613666b.37.2026.09.01.01.07.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 01:07:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788250035; x=1788854835; darn=lists.xenproject.org; h=content-type: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:content-type; bh=yKng7plS+wfHNbRg40bNCxW0BINUIt1q4fUwO2gBYBY=; b=I+yApMdUG881/vhOzZEzo3MwtLKWVSO54O74N1h+4IQGyduyDqo8sP/bMNqJZIvtCA mRqBy3xhGvXh5fLif/Hozdazr36g45/gByFb+7BdI+8w39D4cV3tGZq24sH+vkbVGk+B uq7nVzcd9KMdcn4bLZLxkm/jBHrvw2ODm4wu8aLYSFBJeobLcfI1BimUDRCHT2YFwzyl gS8ljtJffxivOfRjkLt+BnYEvLbwM6psyBcs1TJobBesljoqxX21LCqpj1YCaaongw87 PIEA9itwdYD6lKTB7J5rn44n1WA5kTMsJ0/ASVYYWZdzcfQ5c9iE74JuKs0FhZ/F/5LQ NR1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788250035; x=1788854835; h=content-type: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 :content-type; bh=yKng7plS+wfHNbRg40bNCxW0BINUIt1q4fUwO2gBYBY=; b=HCN64tJLWf0P4r7bfR0ZjBRibSV+a+1XV752bRAkm9DR5xIRZqxNI3C3aaYi76VNhp mTCYvjVR4IJa/JwQPgExDN7CeSf8UKFpcf4JsS87DiReH99tMwh++bWyD0ICCvckcvEh fyQI4c/LzVI7xlpsIReaS5ihB73IK1GSZvM9MYOessJLX7fIfGys7AXHr/n8rDkV66n8 iKK6DCOjmYMnEDj0vOzrqInGJ1P/i8SI/jnikP14358ceWjnIROvANzDmTljEij+6Gjr nn4P87IfIjFkx5xHR5W94my+72rAmh4wDCf+AKP6dd7uymHGKO0RSLn4yZKEWLJG7Ew3 i52Q== X-Forwarded-Encrypted: i=1; AHgh+RrS+EQNLwa56bYAX3fI5vjApODu5gt+8Rbtt7iRaO/j8caKDnE0/+Ui9eZRbCmi00gn5bzZDD4+LNg=@lists.xenproject.org X-Gm-Message-State: AFuF++kmeHNB79o61cjKC43P+FA6cdnDAThB3gFlOV8N46Edg/4r7tAt vG4a/GgvprF3Ywy2qSrND+2cFkNEeo39PIKR9i0pNvtb0rH8owCVv0uwqNbFtzys8lQYSs1obKA TvNPqcCY= X-Gm-Gg: AR+sD13R3E+AyImjxoumlOAHu88Fxz5Dam2mNfFm/aWz/zvwYGqYf1Kw/EOXtFB5o5/ CHHd19XMiGhH5NEbjg+DR9iH+6XjAzl5o+3RyDnLNFBjnpSjDRmLTn2r/B87Y1xpL8bqQviQgq4 oxYX2Kgohda4ZQN1YC+eb/rrs6XQ+zEOdUuiEgrEtq7j9C39nEbmXmiElVZXZTngGE98DHgBJyH AhrWYYsypFVIYNIVGNeAhSKyiPQfyMzzJrscSj6haeXZWvJoGbNTtndGBkf5PZ5Xl0ACDzf1Mch iUV1e+2p268TYoncokPaRC1Zihcbtb89c2/Us7c2THRx8NMwX9HSSEEDlYG9ecZRGHivgUyXIeW nAXu0tV2hAqKY9NQTIBLdUIDMPPQi8Z7XvJjzxuYhTWawYKpSbPoLTGreFYo3w6JZoSMudVPXdj 85VeI2GqC/DyeLj4EhNTyEjaWEAlWujW1XwU7EmJmL5P9p9DLTrXl7xegO76Ocfo4m9kkWKkhRO sTCpragy+NIzUJpCcIkZd5mq4L+YmG9M2UX6+7I6OMO/Oh1RXhRs9rqhjUlYY74S8P1GeXqNzoA vL30v41Rk4MP/w== X-Received: by 2002:a17:907:6094:b0:c25:34c7:44d1 with SMTP id a640c23a62f3a-c255667bfc7mr1913252366b.0.1788250035030; Tue, 01 Sep 2026 01:07:15 -0700 (PDT) Message-ID: <258aa564-4856-4d28-8b90-aa858b25fdd2@suse.com> Date: Tue, 1 Sep 2026 10:07:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync To: Jan Beulich Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Andrew Cooper , Furkan Caliskan , xen-devel@lists.xenproject.org References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0tnotbH2Mecj0aVMudFcmloO" X-purgate-ID: tlsNG-ebf023/1788250035-C34C3B50-9B894D95/0/0 X-purgate-type: clean X-purgate-size: 12142 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0tnotbH2Mecj0aVMudFcmloO Content-Type: multipart/mixed; boundary="------------Ch3mKlZbr100lCOUF5CdLELp"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Andrew Cooper , Furkan Caliskan , xen-devel@lists.xenproject.org Message-ID: <258aa564-4856-4d28-8b90-aa858b25fdd2@suse.com> Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> In-Reply-To: <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------Ch3mKlZbr100lCOUF5CdLELp Content-Type: multipart/mixed; boundary="------------pJ5AhE12pSrlxrhgyBuQJdrZ" --------------pJ5AhE12pSrlxrhgyBuQJdrZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEuMDkuMjYgMDk6MjIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAzMS4wOC4yMDI2 IDE0OjU5LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMzEuMDguMjYgMTE6NDUsIEFu ZHJldyBDb29wZXIgd3JvdGU6DQo+Pj4gT24gMzEvMDgvMjAyNiA2OjE2IGFtLCBGdXJrYW4g Q2FsaXNrYW4gd3JvdGU6DQo+Pj4+IEV2ZXJ5IHZjcHVfY3JlYXRlKCkgY2FsbCBzaXRlIHRo YXQgYnVpbGRzIG1vcmUgdGhhbiBvbmUgdmNwdSBsb29wcw0KPj4+PiBvdmVyIGlkcyB1cCB0 byBkLT5tYXhfdmNwdXMgYW5kIHN0b3BzIG9uIHRoZSBmaXJzdCBmYWlsdXJlLCBidXQgbm9u ZQ0KPj4+PiBvZiB0aGVtIHJvbGwgbWF4X3ZjcHVzIGJhY2sgdG8gbWF0Y2guIFRoaXMgbGVh dmVzIGQtPnZjcHVbaV0gPT0gTlVMTA0KPj4+PiBmb3IgaWRzIGJlbG93IG1heF92Y3B1cw0K Pj4+DQo+Pj4gQXMgSSB0b2xkIHlvdSBiZWZvcmUsIHlvdSBtdXN0IGNvcGUgd2l0aCB0aGlz IHByb3BlcnR5IGluIG5vbi1lcnJvcg0KPj4+IHNjZW5hcmlvcy4NCj4+Pg0KPj4+PiAsIHdo aWNoIGFueXRoaW5nIHdhbGtpbmcgZC0+dmNwdVtdIGNhbiB0aGVuDQo+Pj4+IGRlcmVmZXJl bmNlLiBUaGlzIGlzIHdoYXQgY2F1c2VkIHRoZSBjcmFzaDogc2NoZWRfbW92ZV9kb21haW4o KQ0KPj4+PiB3YWxrcyBldmVyeSB2Y3B1IHNsb3QgdXAgdG8gbWF4X3ZjcHVzIHdpdGhvdXQg Y2hlY2tpbmcgZm9yIGVtcHR5DQo+Pj4+IG9uZXMsIHNvIHdoZW4gYSBkb21haW4gYnVpbHQg aW4gYSBub24tZGVmYXVsdCBjcHVwb29sIGhhZCB2Y3B1DQo+Pj4+IGNyZWF0aW9uIGZhaWwg cGFydHdheSB0aHJvdWdoLCBkb21haW5fa2lsbCgpIGxhdGVyIG1vdmluZyBpdCBiYWNrDQo+ Pj4+IHRvIHRoZSBkZWZhdWx0IGNwdXBvb2wgaGFuZGVkIG9uZSBvZiBpdHMgZW1wdHkgc2xv dHMgc3RyYWlnaHQgdG8NCj4+Pj4gdGhlIG5ldyBjcHVwb29sJ3Mgc2NoZWR1bGVyLCBjYXVz aW5nIGEgTlVMTC1wb2ludGVyIGRlcmVmZXJlbmNlDQo+Pj4+IGluc2lkZSBzY2hlZF9hbGxv Y191ZGF0YSgpLg0KPj4+Pg0KPj4+PiBBZGQgdmNwdXNfY3JlYXRlKGQpOiBjcmVhdGVzIGV2 ZXJ5IHZjcHUgb2YgZCB1cCB0byBtYXhfdmNwdXMgYW5kDQo+Pj4+IHJvbGxzIG1heF92Y3B1 cyBiYWNrIHRvIHRoZSBmYWlsZWQgaWQgb24gZXJyb3IuIFRoaXMga2VlcHMNCj4+Pj4gZC0+ dmNwdVtpXSBpcyBub24tTlVMTCBmb3IgYWxsIGkgPCBkLT5tYXhfdmNwdXMNCj4+Pg0KPj4+ IE5vLCBpdCByZWFsbHkgZG9lc24ndC4NCj4+Pg0KPj4+PiAsIGluc3RlYWQgb2YgZ3VhcmRp bmcNCj4+Pj4gZXZlcnkgcmVhZGVyIG9mIGQtPnZjcHVbXSBhZ2FpbnMgaG9sZXMgaW5kaXZp ZHVhbGx5Lg0KPj4+Pg0KPj4+PiBDb252ZXJ0IGV2ZXJ5IHNpdGUgdGhhdCBidWlsZHMgdmNw dXMgaW4gYSBsb29wIHRvIGNhbGwgdGhpcyBmdW5jdGlvbg0KPj4+PiBpbnN0ZWFkLg0KPj4+ Pg0KPj4+PiBGaXhlczogNjE2NDk3MDk0MjFhICgieGVuL2RvbWFpbjogQWxsb2NhdGUgZC0+ dmNwdVtdIGluIGRvbWFpbl9jcmVhdGUoKSIpDQo+Pj4+IFN1Z2dlc3RlZC1ieTogSnVlcmdl biBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KPj4+PiBTaWduZWQtb2ZmLWJ5OiBGdXJrYW4g Q2FsaXNrYW4gPGZybjFmdXJrYW4xMEBnbWFpbC5jb20+DQo+Pj4NCj4+PiBGb3IgdGhlIGF2 b2lkYW5jZSBvZiBhIGxvbmcgZHJhd24tb3V0IGFyZ3VtZW50LCBuYWNrLsKgIFVuZGVyIG5v DQo+Pj4gY2lyY3Vtc3RhbmNlcyBhcmUgeW91IGVkaXRpbmcgZC0+bWF4X2NwdXMgYWZ0ZXIg aXQncyBwdXQgaW50byB0aGUgZG9tYWluDQo+Pj4gbGlzdC4NCj4+Pg0KPj4+IFlvdSd2ZSBj aG9zZW4gdG8gZG8gc28gYXQgYSBwb2ludCB3aGVyZSB0aGUgZG9tYWluIG9iamVjdCBpcyBs aXZlLA0KPj4+IHZpc2libGUgaW4gdGhlIHN5c3RlbSBhbmQgYWJsZSB0byBiZSB0aGUgdGFy Z2V0IG9mIG90aGVyIGh5cGVyY2FsbHMuDQo+Pj4NCj4+PiBGdXJ0aGVybW9yZSB5b3UgaGF2 ZSBub3QgZml4ZWQgd2hhdCB5b3VyIGNvbW1pdCBtZXNzYWdlIGNsYWltcy4NCj4+PiBkLT52 Y3B1Wy4uLl0gaXMgc3RpbGwgTlVMTCBmb3IgYW4gYXJiaXRyYXJ5IHBlcmlvZCBvZiB0aW1l LCBpbmNsdWRpbmcNCj4+PiBiZWluZyBhYmxlIHRvIGJlIHRoZSB0YXJnZXQgb2YgaHlwZXJj YWxscywgYmVmb3JlIHZDUFVzIGFyZSBjcmVhdGVkLg0KPj4+DQo+Pj4gQWxsIGNvZGUgTVVT VCBiZSBhYmxlIHRvIGNvcGUgd2l0aCBkLT52Y3B1Wy4uLl0gYmVpbmcgTlVMTC7CoCBJdCdz IGhvdw0KPj4+IHRoZSBvYmplY3QgbGlmZWN5Y2xlcyBtdXN0IHdvcmssIGJlY2F1c2UgY3Jl YXRpbmcgdkNQVXMgaXMgbm90IGF0b21pYw0KPj4+IHdpdGggcmVzcGVjdCB0byBjcmVhdGlu ZyBkb21haW5zLg0KPj4NCj4+IFdvdWxkIHlvdSBiZSBmaW5lIHdpdGggbWUgY3JlYXRpbmcg YSBwYXRjaCBzZXJpZXMgbW92aW5nIHZjcHUgY3JlYXRpb24gaW50bw0KPj4gZG9tYWluX2Ny ZWF0ZSgpPw0KPiANCj4gVGhpcyB3YXMgZGlzY3Vzc2VkIGJlZm9yZSwgYW5kIGhvd2V2ZXIg bmljZSBpdCB3b3VsZCBiZSBmb3IgdGhlIGlzc3VlIGF0IGhhbmQsDQo+IGl0IHdvdWxkIGdl dCBpbiB0aGUgd2F5IG9mIHVzIHdhbnRpbmcgdG8gaGF2ZSBDUFUgcG9saWN5IGZvciBkb21h aW5zIHB1dCBpbg0KPiBwbGFjZSBiZWZvcmUgdkNQVS1zIGFyZSBjcmVhdGVkLCBzdWNoIHRo YXQgb24geDg2IHRoZSBYU0FWRSBhcmVhIGNhbiBiZSBzaXplZA0KPiBvbmNlIGFuZCBmb3Ig YWxsLg0KDQpUaGlzIGNvdWxkIGJlIGRvbmUgd2hlbiB1bnBhdXNpbmcgdGhlIGRvbWFpbiBp bml0aWFsbHkuDQoNCk9UT0ggSSBkb24ndCBzZWUgeHN0YXRlX2FsbG9jX3NhdmVfYXJlYSgp IGxvb2tpbmcgYXQgdGhlIGRvbWFpbidzIGNwdSBwb2xpY3kNCmF0IGFsbC4gSXMgdGhpcyBh IHBsYW4gZm9yIHRoZSBmdXR1cmU/DQoNCkFuZCBhZGRpdGlvbmFsbHkgdGhlcmUgaXMgbm8g Z3VhcmQgZm9yIGF2b2lkaW5nIHRoZSB2Y3B1cyBiZWluZyBjcmVhdGVkIGJlZm9yZQ0KdGhl IHBvbGljeSBpcyBiZWluZyBzZXQuDQoNCg0KSnVlcmdlbg0K --------------pJ5AhE12pSrlxrhgyBuQJdrZ Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------pJ5AhE12pSrlxrhgyBuQJdrZ-- --------------Ch3mKlZbr100lCOUF5CdLELp-- --------------0tnotbH2Mecj0aVMudFcmloO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqWh7IFAwAAAAAACgkQsN6d1ii/Ey93 3wf/UcBXGREpPNr0BE2U8RYQwJLYo+iP253CxF6/2uixXEdtLP+l6wvXLIULCKaGFgArDYqDnvvz PjFZiXDWhfYOgXUVQFzz6tNXd6niuDLDxeZdqjz+GqZOne8Vr+jbn7jdR4Ifi9/rm/FM0zub1pwP t+mjx+2CeH4Hse9C3m3+TKBVzZDO/kj2p32EXTPI/nCyMNVhzG8fh0zi08xmWDXWzgFlcgncvScu V+CfhKft796YWCj+D50bLXGTT/nNq66yyG6eHAlFs5qOndpZPHOvYnfv0EpIq8piin9yK8XKP+Pc g/DWaJepu1dMOq2NYnM5DoX3S+TVenj/HLtPp37R7w== =9a/z -----END PGP SIGNATURE----- --------------0tnotbH2Mecj0aVMudFcmloO-- From xen-devel-bounces@lists.xenproject.org Tue Sep 01 08:10:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 08:10:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404577.1638240 (Exim 4.92) (envelope-from ) id 1x1JZq-00059h-Pf; Tue, 01 Sep 2026 08:10:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404577.1638240; Tue, 01 Sep 2026 08:10: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 1x1JZq-00059a-Kc; Tue, 01 Sep 2026 08:10:42 +0000 Received: by outflank-mailman (input) for mailman id 1404577; Tue, 01 Sep 2026 08:10:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1JZp-00059U-LV for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:10:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1JZo-00HPmd-D7 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 10:10:40 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a968880-2eae-0a2a0a5409dd-0a2a4505eafe-2 for ; Tue, 01 Sep 2026 10:10:40 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a968880-4cb1-0a2a45050019-d1558035d0bb-3 for ; Tue, 01 Sep 2026 10:10:40 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49b392ccaacso62935035e9.2 for ; Tue, 01 Sep 2026 01:10:40 -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-49ccd1e19desm308903935e9.1.2026.09.01.01.10.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 01:10:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788250240; x=1788855040; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=W3jsO2bR9hs1KvDoKeA/BBleV0GOEQpLsogO19knpTQ=; b=REbJIzFZTsda3ZJ638590RSwQfQISRScUbkzFsm1ANclxlv7K/8Th/Yl6Ye+6MgxVU lGm9SSfmjRffwwlu2LCVEkEOlVMnXwWxqvY1NitLUaD3vuyqvz0YYGyxjYdcySLXK4vJ AxhIsmREXp2QTxD4Ze4Z9oKa0keefUbG7QziKAEYMCG9vu7EJBXPqlYxTtgjqz8uSpBk pEis/2euOVxMraQzJkr36ArKa8lQdMML6R1oH8SOUHBJ5hguDGAkXiHNXqgyj4h56sc7 S16Dw0KWTTH7lG4dbdArOwUQJbPaY6whDdOLOxy3B0retOHNfqygc4V8Fu+n3/rkMfCE Q8vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788250240; x=1788855040; h=content-transfer-encoding:content-type: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:content-type; bh=W3jsO2bR9hs1KvDoKeA/BBleV0GOEQpLsogO19knpTQ=; b=pCjshYhatsPYreajRf6MFwbyyhw4lJeRH8g31zV8zgTLwfk+AM/5hCSkKRBcGdXvwI JkwBOvaAntV9+cHoMYdQE0e/tLQin5R72zKXsg7Y3yzOV+4IC3WoGvGJ7dH7WAMl4WaT fDrp+fTzYVp+OjbzFH2dntii1Wt267CnvZdidrNDEFBasTcoTUjA/Z4nt4TeqGvzYA+P A15mS9CFcL5UQmzpnT874tnPxnxP/VBAUZM4i854jxsb6NMljD+gEl9SLOaIr7UZuoFc eStAFkVo5edstaRaDCt3YsG1CE23Q87YbIHeqoHxJtnomTP5u1FMPHvZ5QNE82qF0qqx 8xjg== X-Gm-Message-State: AFuF++m4xSbiA1pCMu1JYLf+L60UGY2NLo5rcVYl7yESpXPnET114rqx SXNl2fPOvsrctqruvW7oeebOA7UAkr43rzyz1wfJb39zvQFmG3VdvDgU4O2esaO1sg== X-Gm-Gg: AR+sD11d9Yx0SDB4RUcNTOmaOVzwGFDfM1hNiE4w7gTO83gFxkjtiLoWk/xfFiHX0n3 e6l/2Cp/26P6RWXnpEzMTM6DU7gSpH26NZ5mq7ocdqHXcQvvxDY36JkK+a5zVte6Ksz/O0OO6tW RvBx8vvPrC3qU0N5qV12TQ0Q2+2B9+bK/r1S+1TFTw+CVAMmlQO5LW7ByneFN3Hujq8XnaQry9J siLNdy8olDknoap5kLk02/zO1F9gvJZqL6Zmo6XLu1sgJPDynNaSAnwIbwsNNllmk5gMuuSBNlX ijz6dGMmBCWR6kOUWuFEcrqZVrtLwWG9u4IVHLm9dBzCiEWZ2dVgIcoQ8dXfR/jwRasXootp3qe ZpqmPxYX5oOoMaF+6wpsRg1WVoF1JTwGrSlwo3nMNriNomqxPGYIDiMLOiSHKxlmEHZVeuDKNdX oQVH+Si9m7Ogok6yPcnmz7Gsyuy6+KCyH3a2J1mx8HxMshRGOGiQKWcEMDUow16ljJN2IfRsCvL c1fnVNVreiwfUogHfdll4uTs9WPfIjfRcsITxF/5ANpACIfCUo8YPVs1Ka9qY4= X-Received: by 2002:a05:600c:3584:b0:49c:dada:30b7 with SMTP id 5b1f17b1804b1-49cdada30e1mr117199135e9.2.1788250239771; Tue, 01 Sep 2026 01:10:39 -0700 (PDT) Message-ID: <5ab3668e-ef38-42c1-b741-0322d7d62c93@suse.com> Date: Tue, 1 Sep 2026 10:10:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@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 X-purgate-ID: tlsNG-c201ff/1788250240-726B52A1-AFF49E5F/0/0 X-purgate-type: clean X-purgate-size: 2323 On 29.08.2026 15:21, Nicola Vetrini wrote: > On 2026-08-28 09:01, Jan Beulich wrote: >> start_secondary(), do_double_fault(), play_dead(), and tboot_s3_error() >> never return, so would better be annotated anyway. The >> do_double_fault() >> change needs accompanying by adjustments to entry_from_{pv,xen}(), as >> Eclair then deems the "return" there as unreachable. >> >> context_switch() and continue_running() are odd: We can't >> (unconditionally) add noreturn to their declarations, as Arm's variants >> do >> return. Put the attribute on x86'es definitions instead (the use of >> unreachable() in reset_stack_and_call_ind() allows the compiler to >> figure >> that out itself, but Eclair wants the annotation in addition). >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Nicola Vetrini Thanks, yet Andrew's objection will need dealing with. >> --- >> entry_from_pv() wants the annotation only when PV=n, yet once added gcc >> then warns about "return" being used in a "noreturn" function. Is there >> any other approach to address this besides adding #ifdef inside the >> function (i.e. replacing the !IS_ENABLED(CONFIG_PV) check that's >> there)? > > Besides GCC's warning, this would violate MISRA C's Rule 17.9 ("A > function declared with a _Noreturn function specifier shall not return > to its caller") > which is not (yet) adopted by Xen, as it comes with MISRA C:2012 > Amendment 3, whereas as you know Xen is based on MISRA C:2012 Amendment > 2 rules. > Besides this, perhaps an alternative could be something like this > (untested): > > #define __noreturn_0 > #define __noreturn_1 __attribute__((noreturn)) > > #define __noreturn_select(x) __noreturn_select_(x) > #define __noreturn_select_(x) __noreturn_ ## x > > #define noreturn(cond) __noreturn_select(cond) > > assuming use sites such as noreturn(IS_ENABLED(CONFIG_FOO)) But how is void asmlinkage noreturn(!IS_ENABLED(CONFIG_PV)) entry_from_pv(struct cpu_user_regs *regs) (besides of course not being correct to use this way) different from void asmlinkage #ifndef CONFIG_PV noreturn #endif entry_from_pv(struct cpu_user_regs *regs) ? We'd still end up with a "noreturn" function having "return" statements. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 08:15:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 08:15:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404583.1638247 (Exim 4.92) (envelope-from ) id 1x1JeA-0005qQ-6x; Tue, 01 Sep 2026 08:15:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404583.1638247; Tue, 01 Sep 2026 08:15:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1JeA-0005qJ-4H; Tue, 01 Sep 2026 08:15:10 +0000 Received: by outflank-mailman (input) for mailman id 1404583; Tue, 01 Sep 2026 08:15:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Je8-0005qB-DP for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:15:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1Je7-00DbXT-Jg for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 10:15:07 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a968983-bab6-0a2a0a5309dd-0a2a4507dc2c-42 for ; Tue, 01 Sep 2026 10:15:04 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a968988-b4ea-0a2a45070019-d1558034f0ad-3 for ; Tue, 01 Sep 2026 10:15:04 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4953e04ef16so5864755e9.2 for ; Tue, 01 Sep 2026 01:15:04 -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-49b91c5790csm288522395e9.0.2026.09.01.01.15.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 01:15:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788250504; x=1788855304; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=qII7isHxLo1LTv9iV/khAGBTlsyqwP8ZhM9Gj+yv/k8=; b=CwCEKP3ggF+QCc/tLXoWyu74Jt8+aTh4Px6MhTv7mEjC4wJFu48/6FNAw+3KhxyXDM yHuaSwEuddLJk6/z/yUyiBEyTVwdVL6ayzHkLJp+3t5xKqX0/trbPq2jgDYjTquUvWF1 xi1g5mOh85il6JgToPlRXIREkOkv8WczVq36qXBNRUvfsPvXI8KDQhXpNQ326gASwVlv ScSDDGQRjAd5GfYSgERHoNP7K4QRmR0fuyaqpiPIXxnNlZKC1ANwhiDhcAsimWmJ71ov PnfQGJuRTl1/ASPNYwhmrn0hcLtBVTeEjXG7Wylt9txh/mi3KYnfiMQoEGVNS1ftzuld i1Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788250504; x=1788855304; h=content-transfer-encoding:content-type: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:content-type; bh=qII7isHxLo1LTv9iV/khAGBTlsyqwP8ZhM9Gj+yv/k8=; b=EOLDgSOCpS3m2jEVNJ9xCd6AzRWUN5INi2rzKA0w8oxrgEJytaNTaE96D/DiY/8HPV SLNke+zTkU1pJoi1K2HzZhZybj4eTSpg9KMcYOmyp7tj40ygepxhhkHQ2TQ9B5Qe3deW 6fdmVDP4N0kMkFPVcgANJIFF+k4SncKSU8UNvXhigzQSGTWnSslIw71OvWqCkkF37Lf6 BFaYzjSjbTjRCaj4YQm6svVhw/iVPWl8rB8ZqjaQYKxD39xR/PITaT2OiwIf1+ywuTDQ jMtIYK7J/iX0XiMCDdTY6kTTzi8D4uYmt7hK/rEhYaOCSv05MyITBxyF8C65gdDR5mBs q4JA== X-Forwarded-Encrypted: i=1; AHgh+RpvPLTaf1KdU5L5piIAg7vvJxqwKLJqVzo1peHLJ70sOr1CXgDbV7TMfjh1pjwTlpgzUEsi0nlM7OE=@lists.xenproject.org X-Gm-Message-State: AFuF++npuTrfb/JThfw8zbrwU3PFVB3iZBuc+TNuhehnI7Y2M7G9qP9P 6rx3P4q9/4v/R+mlWiu9h/d+N7tRqhmY5g+zZWXASimQpZXUr4txcXXFRaTGi8gjEg== X-Gm-Gg: AR+sD10dsL3e8uh6Gkkj4iBdPt1JHDyZznkELIAWSk1HVPOH1oXt59HtIDCD9tjinJe cciQO6trcUv8cHdju4YbamqqKUpqXXKpjWUQM6BBp1WeMu9hkGoyYV/QX3z51yNFaf/0Fbxr67O qLBMJpzJ1ULlutp8V5DcmcU47K4A6aB1luRlrbNio+ImnASZtuH183AG130siMPaS1IzdfiQD0G dalN1KF3ST3syCeKQnmsKCc3yZBBuyQ0p2SstFW9YrhrSty9bZtv6TZEGZqAJ280jBg1Fl+/2NE f2K2WuU24CbsksVOFF4843w/v3qT0Fcpl2DcYYsPkrGgXb56f5sp0p1Et4nmiBBnN+dJNRQDQOE G8MXxnWu1dd07Rt8nXzwUEiqRwda85V1k7SH8kM/L2dN8rl+umNIBlflBIQiAAi0G57dLVu92NA 7CPmG6Sfg2frlCOj165T9zmJ8vZEcwSB+HYXFTzGKtNYIoFKpmbmKhN5Fsuou6PaZPJuG6LMvJg snMjoW+uyyB3Iqmy2CeWeVIpEN5M4aWnh7BiuxyeO20pSRGNkUU X-Received: by 2002:a05:600c:529a:b0:49c:cedc:3c36 with SMTP id 5b1f17b1804b1-49ccedc3cafmr331380675e9.16.1788250504064; Tue, 01 Sep 2026 01:15:04 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 10:15:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Andrew Cooper Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Furkan Caliskan , xen-devel@lists.xenproject.org References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> <258aa564-4856-4d28-8b90-aa858b25fdd2@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: <258aa564-4856-4d28-8b90-aa858b25fdd2@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788250504-34ECEAE4-3A98C70F/0/0 X-purgate-type: clean X-purgate-size: 3473 On 01.09.2026 10:07, Jürgen Groß wrote: > On 01.09.26 09:22, Jan Beulich wrote: >> On 31.08.2026 14:59, Jürgen Groß wrote: >>> On 31.08.26 11:45, Andrew Cooper wrote: >>>> On 31/08/2026 6:16 am, Furkan Caliskan wrote: >>>>> Every vcpu_create() call site that builds more than one vcpu loops >>>>> over ids up to d->max_vcpus and stops on the first failure, but none >>>>> of them roll max_vcpus back to match. This leaves d->vcpu[i] == NULL >>>>> for ids below max_vcpus >>>> >>>> As I told you before, you must cope with this property in non-error >>>> scenarios. >>>> >>>>> , which anything walking d->vcpu[] can then >>>>> dereference. This is what caused the crash: sched_move_domain() >>>>> walks every vcpu slot up to max_vcpus without checking for empty >>>>> ones, so when a domain built in a non-default cpupool had vcpu >>>>> creation fail partway through, domain_kill() later moving it back >>>>> to the default cpupool handed one of its empty slots straight to >>>>> the new cpupool's scheduler, causing a NULL-pointer dereference >>>>> inside sched_alloc_udata(). >>>>> >>>>> Add vcpus_create(d): creates every vcpu of d up to max_vcpus and >>>>> rolls max_vcpus back to the failed id on error. This keeps >>>>> d->vcpu[i] is non-NULL for all i < d->max_vcpus >>>> >>>> No, it really doesn't. >>>> >>>>> , instead of guarding >>>>> every reader of d->vcpu[] agains holes individually. >>>>> >>>>> Convert every site that builds vcpus in a loop to call this function >>>>> instead. >>>>> >>>>> Fixes: 61649709421a ("xen/domain: Allocate d->vcpu[] in domain_create()") >>>>> Suggested-by: Juergen Gross >>>>> Signed-off-by: Furkan Caliskan >>>> >>>> For the avoidance of a long drawn-out argument, nack.  Under no >>>> circumstances are you editing d->max_cpus after it's put into the domain >>>> list. >>>> >>>> You've chosen to do so at a point where the domain object is live, >>>> visible in the system and able to be the target of other hypercalls. >>>> >>>> Furthermore you have not fixed what your commit message claims. >>>> d->vcpu[...] is still NULL for an arbitrary period of time, including >>>> being able to be the target of hypercalls, before vCPUs are created. >>>> >>>> All code MUST be able to cope with d->vcpu[...] being NULL.  It's how >>>> the object lifecycles must work, because creating vCPUs is not atomic >>>> with respect to creating domains. >>> >>> Would you be fine with me creating a patch series moving vcpu creation into >>> domain_create()? >> >> This was discussed before, and however nice it would be for the issue at hand, >> it would get in the way of us wanting to have CPU policy for domains put in >> place before vCPU-s are created, such that on x86 the XSAVE area can be sized >> once and for all. > > This could be done when unpausing the domain initially. Imo unpausing shouldn't fail because of memory shortage. > OTOH I don't see xstate_alloc_save_area() looking at the domain's cpu policy > at all. Is this a plan for the future? This is to better accommodate the AMX series (which has been pending for years), and potentially also for architectural-LBR work (which has been posted once, but was apparently abandoned). > And additionally there is no guard for avoiding the vcpus being created before > the policy is being set. Addressing that is part of Andrew's plan, aiui. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 08:24:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 08:24:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404592.1638256 (Exim 4.92) (envelope-from ) id 1x1Jms-0007oX-0s; Tue, 01 Sep 2026 08:24:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404592.1638256; Tue, 01 Sep 2026 08:24:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Jmr-0007oQ-U3; Tue, 01 Sep 2026 08:24:09 +0000 Received: by outflank-mailman (input) for mailman id 1404592; Tue, 01 Sep 2026 08:24:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Jmq-0007oK-GT for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:24:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1Jmp-00CNmP-6e for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 10:24:07 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a968b98-e002-0a2a0a5209dd-0a2a4509d6c0-44 for ; Tue, 01 Sep 2026 10:24:07 +0200 Received: from [209.85.208.49] (helo=mail-ed1-f49.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a968ba6-be1a-0a2a45090019-d155d031c953-3 for ; Tue, 01 Sep 2026 10:24:06 +0200 Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-6a173ad7cf4so6949912a12.3 for ; Tue, 01 Sep 2026 01:24:06 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c255ee0b23esm523732666b.2.2026.09.01.01.24.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 01:24:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788251046; x=1788855846; darn=lists.xenproject.org; h=content-type: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:content-type; bh=0ZUBl2Xc+talOjo3mXwBhKTr6Sqay2tUGEBOsxDXBB0=; b=KcRBSEVHocBe0sXXVDwbbDwIrJiXnAXeTnv48xf1ERMtjrSY5xjnw3+pQd6YsG92WC uEf8FIAwDKKIeUkGIcOxphSXrlQj/r/rTeAbgS7fX2ozV9cBRdj/9YK603GiCt2KVk6S Ir4wRt+BFbxO/NGsLba62wbNKwwkOy9lRgVXhLGSAkzyvCqt/v1edNpiN7EWPwob9gc5 IzQERCNqE9nwiBgZValNGw9Q6N2GKPEkm4CwCqxReZsDs9GJfda9RbYV+yha7wX8hlH+ tLoCSsMFKPf5bI74YWdUhpNuVnQWA660CQb6CNivSxbcEAY28Lr5Txlz86Awt6oe1idM xcmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788251046; x=1788855846; h=content-type: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 :content-type; bh=0ZUBl2Xc+talOjo3mXwBhKTr6Sqay2tUGEBOsxDXBB0=; b=l6EspLM3GhuxSjhu67bbCyrBdM3ttS5OihoNJnMMpqYqti52TIDEWVrkPKYD2ctweU NMy4YW2tO3RKMG9Ed24zkzfOl9EoZJRfuu2sAbTFfQ4XxC4IaiHdXJmj4xP2QCAT6Tlw qS0terO8yBfqhuaNJ5T9YS+xTsXZuDcR5IG4c/dCQCh4c2G6wLfh5jDWCfZP3D2GQvI4 58nou23IEcmEj2rxKkvln2MwRaFjJyranp/1+jGr4WNvA48uclwyLcb04NN/gTSMCY+H oWTEVaASl+Y/0PkGU3/WfVRYtLA8RVD4+vGObFiQd9c7TJYB1yC/aE1TkDUtqG1bbdbK 7Y5A== X-Forwarded-Encrypted: i=1; AHgh+RqohSPf7RRh8KSEkCJkWWzgW90ZMHknKVG7pJIcxbZkAQDQ7w2D7iiDgaxutOk7dgA/M4UIaSK/OK0=@lists.xenproject.org X-Gm-Message-State: AFuF++npRTThQnogMCGqrKgRwC1jdOndm38LZfADTfdmrx4VxOcN1Zxn NaKKlYF7HktXlLt+v0HKNZfhZkzprTnjqjlM91PSYAkYon8AJYjH09LxVDLXIco+tYo= X-Gm-Gg: AR+sD114N7fUGGeXAGTviXe+E8MWHTauBwdMqifwDnDfiRDhebCDdyOiphaHs2vVasZ nR26NHWGjKyo1nQxmtqIJYS9QxrJN2zwYc/73L22Pp0UKMEBMRtIToLruhckdv45+LGtrkMIZm/ 8j22gzT5GSS6yBz6tNbV7V0HigyFmtTJ5Ke3aVXKziU6ep23ixqOxAeal/vuTwCZ4FrBgfBx+nf 15JBPc1XKjPc+mZrbMyPxuzUmKbij1tznnoj2OP5II3vG15MHLAnmHsF3+pfb5RJRL/tKQzCsx6 b0XAJRqLNyis2/gb7CbogUoYsGFxgDZCUQs0g56Dr7EPYRgreg0qt2xnw5kJVHcvSHwmphesixn QuypNWUico8Qx0+XHhg5UzCYHoSPf1GVUIVXzxtX/VXhlb4eYeEVSS7QnfaHpBZxLBI0zW5jvJW qe5W3g0JV8F+OOCKfqmX461058U0C7mo8dRmd0gp98ZTiR+fO32/2I3Lp4Zf0fMS42n92w1Sdyk MeGmgwjBWkRH/jvlNAR5V8VfRSq8US0u6Q0gxkbcu019SuwXp66nBv//V7E+j8+90REaYQBVKLT 6VI5lOa0MUQKWQ== X-Received: by 2002:a17:907:9453:b0:c25:68c2:7b94 with SMTP id a640c23a62f3a-c2568c27f5cmr1739979566b.8.1788251046384; Tue, 01 Sep 2026 01:24:06 -0700 (PDT) Message-ID: <06e18456-50ac-471d-8323-1560dd8b2a5c@suse.com> Date: Tue, 1 Sep 2026 10:24:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync To: Jan Beulich , Andrew Cooper Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Furkan Caliskan , xen-devel@lists.xenproject.org References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> <258aa564-4856-4d28-8b90-aa858b25fdd2@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FOpXR5AeOYQZznHbHNvuKcY4" X-purgate-ID: tlsNG-bad1c0/1788251047-3A0C5034-C8A09DE1/0/0 X-purgate-type: clean X-purgate-size: 12598 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FOpXR5AeOYQZznHbHNvuKcY4 Content-Type: multipart/mixed; boundary="------------ByWW06Shcw4ERjyJwrfNMYSp"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich , Andrew Cooper Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Furkan Caliskan , xen-devel@lists.xenproject.org Message-ID: <06e18456-50ac-471d-8323-1560dd8b2a5c@suse.com> Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> <258aa564-4856-4d28-8b90-aa858b25fdd2@suse.com> In-Reply-To: Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------ByWW06Shcw4ERjyJwrfNMYSp Content-Type: multipart/mixed; boundary="------------KsVYHFfYnEm42DHbauQwVP4L" --------------KsVYHFfYnEm42DHbauQwVP4L Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEuMDkuMjYgMTA6MTUsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwMS4wOS4yMDI2 IDEwOjA3LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMDEuMDkuMjYgMDk6MjIsIEph biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDMxLjA4LjIwMjYgMTQ6NTksIErDvHJnZW4gR3Jv w58gd3JvdGU6DQo+Pj4+IE9uIDMxLjA4LjI2IDExOjQ1LCBBbmRyZXcgQ29vcGVyIHdyb3Rl Og0KPj4+Pj4gT24gMzEvMDgvMjAyNiA2OjE2IGFtLCBGdXJrYW4gQ2FsaXNrYW4gd3JvdGU6 DQo+Pj4+Pj4gRXZlcnkgdmNwdV9jcmVhdGUoKSBjYWxsIHNpdGUgdGhhdCBidWlsZHMgbW9y ZSB0aGFuIG9uZSB2Y3B1IGxvb3BzDQo+Pj4+Pj4gb3ZlciBpZHMgdXAgdG8gZC0+bWF4X3Zj cHVzIGFuZCBzdG9wcyBvbiB0aGUgZmlyc3QgZmFpbHVyZSwgYnV0IG5vbmUNCj4+Pj4+PiBv ZiB0aGVtIHJvbGwgbWF4X3ZjcHVzIGJhY2sgdG8gbWF0Y2guIFRoaXMgbGVhdmVzIGQtPnZj cHVbaV0gPT0gTlVMTA0KPj4+Pj4+IGZvciBpZHMgYmVsb3cgbWF4X3ZjcHVzDQo+Pj4+Pg0K Pj4+Pj4gQXMgSSB0b2xkIHlvdSBiZWZvcmUsIHlvdSBtdXN0IGNvcGUgd2l0aCB0aGlzIHBy b3BlcnR5IGluIG5vbi1lcnJvcg0KPj4+Pj4gc2NlbmFyaW9zLg0KPj4+Pj4NCj4+Pj4+PiAs IHdoaWNoIGFueXRoaW5nIHdhbGtpbmcgZC0+dmNwdVtdIGNhbiB0aGVuDQo+Pj4+Pj4gZGVy ZWZlcmVuY2UuIFRoaXMgaXMgd2hhdCBjYXVzZWQgdGhlIGNyYXNoOiBzY2hlZF9tb3ZlX2Rv bWFpbigpDQo+Pj4+Pj4gd2Fsa3MgZXZlcnkgdmNwdSBzbG90IHVwIHRvIG1heF92Y3B1cyB3 aXRob3V0IGNoZWNraW5nIGZvciBlbXB0eQ0KPj4+Pj4+IG9uZXMsIHNvIHdoZW4gYSBkb21h aW4gYnVpbHQgaW4gYSBub24tZGVmYXVsdCBjcHVwb29sIGhhZCB2Y3B1DQo+Pj4+Pj4gY3Jl YXRpb24gZmFpbCBwYXJ0d2F5IHRocm91Z2gsIGRvbWFpbl9raWxsKCkgbGF0ZXIgbW92aW5n IGl0IGJhY2sNCj4+Pj4+PiB0byB0aGUgZGVmYXVsdCBjcHVwb29sIGhhbmRlZCBvbmUgb2Yg aXRzIGVtcHR5IHNsb3RzIHN0cmFpZ2h0IHRvDQo+Pj4+Pj4gdGhlIG5ldyBjcHVwb29sJ3Mg c2NoZWR1bGVyLCBjYXVzaW5nIGEgTlVMTC1wb2ludGVyIGRlcmVmZXJlbmNlDQo+Pj4+Pj4g aW5zaWRlIHNjaGVkX2FsbG9jX3VkYXRhKCkuDQo+Pj4+Pj4NCj4+Pj4+PiBBZGQgdmNwdXNf Y3JlYXRlKGQpOiBjcmVhdGVzIGV2ZXJ5IHZjcHUgb2YgZCB1cCB0byBtYXhfdmNwdXMgYW5k DQo+Pj4+Pj4gcm9sbHMgbWF4X3ZjcHVzIGJhY2sgdG8gdGhlIGZhaWxlZCBpZCBvbiBlcnJv ci4gVGhpcyBrZWVwcw0KPj4+Pj4+IGQtPnZjcHVbaV0gaXMgbm9uLU5VTEwgZm9yIGFsbCBp IDwgZC0+bWF4X3ZjcHVzDQo+Pj4+Pg0KPj4+Pj4gTm8sIGl0IHJlYWxseSBkb2Vzbid0Lg0K Pj4+Pj4NCj4+Pj4+PiAsIGluc3RlYWQgb2YgZ3VhcmRpbmcNCj4+Pj4+PiBldmVyeSByZWFk ZXIgb2YgZC0+dmNwdVtdIGFnYWlucyBob2xlcyBpbmRpdmlkdWFsbHkuDQo+Pj4+Pj4NCj4+ Pj4+PiBDb252ZXJ0IGV2ZXJ5IHNpdGUgdGhhdCBidWlsZHMgdmNwdXMgaW4gYSBsb29wIHRv IGNhbGwgdGhpcyBmdW5jdGlvbg0KPj4+Pj4+IGluc3RlYWQuDQo+Pj4+Pj4NCj4+Pj4+PiBG aXhlczogNjE2NDk3MDk0MjFhICgieGVuL2RvbWFpbjogQWxsb2NhdGUgZC0+dmNwdVtdIGlu IGRvbWFpbl9jcmVhdGUoKSIpDQo+Pj4+Pj4gU3VnZ2VzdGVkLWJ5OiBKdWVyZ2VuIEdyb3Nz IDxqZ3Jvc3NAc3VzZS5jb20+DQo+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogRnVya2FuIENhbGlz a2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29tPg0KPj4+Pj4NCj4+Pj4+IEZvciB0aGUgYXZv aWRhbmNlIG9mIGEgbG9uZyBkcmF3bi1vdXQgYXJndW1lbnQsIG5hY2suwqAgVW5kZXIgbm8N Cj4+Pj4+IGNpcmN1bXN0YW5jZXMgYXJlIHlvdSBlZGl0aW5nIGQtPm1heF9jcHVzIGFmdGVy IGl0J3MgcHV0IGludG8gdGhlIGRvbWFpbg0KPj4+Pj4gbGlzdC4NCj4+Pj4+DQo+Pj4+PiBZ b3UndmUgY2hvc2VuIHRvIGRvIHNvIGF0IGEgcG9pbnQgd2hlcmUgdGhlIGRvbWFpbiBvYmpl Y3QgaXMgbGl2ZSwNCj4+Pj4+IHZpc2libGUgaW4gdGhlIHN5c3RlbSBhbmQgYWJsZSB0byBi ZSB0aGUgdGFyZ2V0IG9mIG90aGVyIGh5cGVyY2FsbHMuDQo+Pj4+Pg0KPj4+Pj4gRnVydGhl cm1vcmUgeW91IGhhdmUgbm90IGZpeGVkIHdoYXQgeW91ciBjb21taXQgbWVzc2FnZSBjbGFp bXMuDQo+Pj4+PiBkLT52Y3B1Wy4uLl0gaXMgc3RpbGwgTlVMTCBmb3IgYW4gYXJiaXRyYXJ5 IHBlcmlvZCBvZiB0aW1lLCBpbmNsdWRpbmcNCj4+Pj4+IGJlaW5nIGFibGUgdG8gYmUgdGhl IHRhcmdldCBvZiBoeXBlcmNhbGxzLCBiZWZvcmUgdkNQVXMgYXJlIGNyZWF0ZWQuDQo+Pj4+ Pg0KPj4+Pj4gQWxsIGNvZGUgTVVTVCBiZSBhYmxlIHRvIGNvcGUgd2l0aCBkLT52Y3B1Wy4u Ll0gYmVpbmcgTlVMTC7CoCBJdCdzIGhvdw0KPj4+Pj4gdGhlIG9iamVjdCBsaWZlY3ljbGVz IG11c3Qgd29yaywgYmVjYXVzZSBjcmVhdGluZyB2Q1BVcyBpcyBub3QgYXRvbWljDQo+Pj4+ PiB3aXRoIHJlc3BlY3QgdG8gY3JlYXRpbmcgZG9tYWlucy4NCj4+Pj4NCj4+Pj4gV291bGQg eW91IGJlIGZpbmUgd2l0aCBtZSBjcmVhdGluZyBhIHBhdGNoIHNlcmllcyBtb3ZpbmcgdmNw dSBjcmVhdGlvbiBpbnRvDQo+Pj4+IGRvbWFpbl9jcmVhdGUoKT8NCj4+Pg0KPj4+IFRoaXMg d2FzIGRpc2N1c3NlZCBiZWZvcmUsIGFuZCBob3dldmVyIG5pY2UgaXQgd291bGQgYmUgZm9y IHRoZSBpc3N1ZSBhdCBoYW5kLA0KPj4+IGl0IHdvdWxkIGdldCBpbiB0aGUgd2F5IG9mIHVz IHdhbnRpbmcgdG8gaGF2ZSBDUFUgcG9saWN5IGZvciBkb21haW5zIHB1dCBpbg0KPj4+IHBs YWNlIGJlZm9yZSB2Q1BVLXMgYXJlIGNyZWF0ZWQsIHN1Y2ggdGhhdCBvbiB4ODYgdGhlIFhT QVZFIGFyZWEgY2FuIGJlIHNpemVkDQo+Pj4gb25jZSBhbmQgZm9yIGFsbC4NCj4+DQo+PiBU aGlzIGNvdWxkIGJlIGRvbmUgd2hlbiB1bnBhdXNpbmcgdGhlIGRvbWFpbiBpbml0aWFsbHku DQo+IA0KPiBJbW8gdW5wYXVzaW5nIHNob3VsZG4ndCBmYWlsIGJlY2F1c2Ugb2YgbWVtb3J5 IHNob3J0YWdlLg0KDQpBcyBsb25nIGFzIHRoZSBkb21haW4gaGFzbid0IHN0YXJ0ZWQgcnVu bmluZyBJIGRvbid0IHNlZSB3aHkgdGhpcyB3b3VsZCBiZQ0KZGlmZmVyZW50IHRvIHRoZSBj YXNlIHdoZXJlIG5vdCBhbGwgdmNwdXMgY291bGQgYmUgY3JlYXRlZC4NCg0KQlRXLCBJIHdp bGwgYWRkcmVzcyBzY2VuYXJpb3MgbGlrZSB0aGF0IGluIG15IFhlbiBzdW1taXQgcHJlc2Vu dGF0aW9uLiA6LSkNCg0KDQpKdWVyZ2VuDQo= --------------KsVYHFfYnEm42DHbauQwVP4L Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------KsVYHFfYnEm42DHbauQwVP4L-- --------------ByWW06Shcw4ERjyJwrfNMYSp-- --------------FOpXR5AeOYQZznHbHNvuKcY4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqWi6UFAwAAAAAACgkQsN6d1ii/Ey/B Fwf/cjrGJs91R6W+scxAe6iEVTQjgNLlPs51Bgp+94tI0lRBFwg7OkTPdUms4cikgWrYQZpnyqrI lWOy6/w8j9RJ79zwjNZNp8DSAt7LiriYEaOF999qjc55oXo/wJbyFLuFeWPmQT3scRikRsTNpmC8 2j9Y9ABLhn/znrPKaAY6zSQuKGiujXCCGdLQMML0JJ9/BNgQnwcQ8meV3lr/L5HqNlWdgvjJeFfg mqs6FHdBYBjYB/zPcfU5z9Mng4izfnWau8yse4dM3XXws0IYX3hYXfOljmDRZbt8bgYeRLCyYrLc uouO+Rwe03JgRDN33lJXx9HCqvTIfVWz2zkzNQMx2g== =XsQH -----END PGP SIGNATURE----- --------------FOpXR5AeOYQZznHbHNvuKcY4-- From xen-devel-bounces@lists.xenproject.org Tue Sep 01 08:36:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 08:36:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404609.1638265 (Exim 4.92) (envelope-from ) id 1x1Jyo-0001Pw-4c; Tue, 01 Sep 2026 08:36:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404609.1638265; Tue, 01 Sep 2026 08:36:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Jyo-0001Pp-1Z; Tue, 01 Sep 2026 08:36:30 +0000 Received: by outflank-mailman (input) for mailman id 1404609; Tue, 01 Sep 2026 08:36:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Jym-0001Oy-Ce for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:36:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1Jyl-005OYo-PZ for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 10:36:27 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a968e84-8faa-0a2a0a5109dd-0a2a450ac9b2-36 for ; Tue, 01 Sep 2026 10:36:27 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a968e8b-f2d2-0a2a450a0019-d1558033e597-3 for ; Tue, 01 Sep 2026 10:36:27 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4957eefd361so4764125e9.1 for ; Tue, 01 Sep 2026 01:36:27 -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-49cdce3e0desm53682995e9.11.2026.09.01.01.36.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 01:36:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788251787; x=1788856587; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=XMXNQJYTCIaTGcr9ERCkuVUJRLXuXnV7iGnZJBBF7dA=; b=eMri5doG7PAW8uFLG1nfvlM6lMnmXPoj5ZLvmxzNgxiI9m0A42Jbzx29jyUQXaGx+v yrmFlDdrceKY0t9YuKAESqrkW+L5o30j8B+cyaXXrlg/USl/bU/HyB5O2p+Lr5dUj0mD dCeCpzJQPoXZfFwCIxb1RuKLmq5ziXSxqyPfQ0gkfkENFV+zVBcB8eJXpGIwYhi0lEM1 5LNRIjLw5iQ2cJRUZiTdFuKNdY+y78D1ikHb+WQopMjtp8qYAqRRGtFjaI9wCnBE+hyJ Ak9peZ6L/09Q6XzMkCVsOg9qyaND4NvyQrBdLj4hVK0c5ezOABMKdoLD6hTRrTqDHKaY mWAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788251787; x=1788856587; h=content-transfer-encoding:content-type: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:content-type; bh=XMXNQJYTCIaTGcr9ERCkuVUJRLXuXnV7iGnZJBBF7dA=; b=P2xO/sxElCp3Egm17GTzlVXM9PjSm53ItnmI8iQobgOXAiPgyx2DC71ktS0/U+3AVz G1rAcmFVGnyXt7qZ6rW2/UaVdvaL/q7bb37FQJ/x29Y5X9BdJFifItinPBEo3816H3kF c9RgzpMerVek6ghCm+zjxv6uIpNu4GX01n+YEh+dMxmDdlC8XffptmAnOSGk1fGItmZn bZFo54pupS9w1jd32vmCFpbDHy2bS5fnhtvIJxz9gaGWPDkVv71ME5TeGOBClgnwHfxa yix4sHDFCCIYa1SF9DzDiEh4qLzsJ9pbjUa4j+8X0x1w4UPkJgl16DI7yUqLiB/am6z8 b0jg== X-Forwarded-Encrypted: i=1; AHgh+Rra9cP8x9MFDqQ7EnelJRTmEux5yAIpDF6lI9LbiD7qHt8bO+bQkJKf9pdhjgNOMCgp5XXsmUSumx4=@lists.xenproject.org X-Gm-Message-State: AFuF++n/YeokCDMjYyJitXHZvKRkpgu+Le+IhdsDXjdoKJfg2WrHxLQe NAfuuGbijEW9fadlixO9PtWUvhATyJTBqQl5I1mMi6kxS7DR9sRYXoiEMY91ctdCcg== X-Gm-Gg: AR+sD10XhiSuzBAkhzCNe2BfLwLnLKxlot8uJs49pk8zezF0g8S8eOEJmTt3Wn8oAOs dBnY8YM22UIC09pSi2Xt4x6pzqWjJz9KbaURVsnHvAaHYLuUUpQwNJlK0qjiRNARvCZdI8Kl7hO a3Wch3zV8hDZaHURh6LoSp/8y5kfEKVGST6tp3F+tzxUeQBrIBhOoa5YwwkAqxDMM++1nAw5rRh WmMVLu3tH71YbmX+hAsdedeKAJ2tFJpkkaDXORKXo2e+FsM1c2WSIRk1pHihKfilM4PLLhoG0uC nePXLryNWsLK+aSF/VgmVuqFu8EYyx014POFUannOJCT6lzmYbL3FWbX8LnNDt+YyLB6QTAmOHT 1CteKMPyfS8iEW3O/v505qwtcY1ZyjLkJYWkGUUcpEryH3zT7kWJpm3CwLWQpVG4U/NBdee3QL2 9yWZUxFc8d9hXDadaU6JA4LX7pb46PcvKMigyyXJ+nvOHTUBbILun0WhKJlp9kferMSI8M1EQrO 6/WEP8nhjXkyFY1MBlaYr3busNz5UFgAR9mmo+28UGQUIqm02Y0 X-Received: by 2002:a05:600c:4592:b0:495:5890:8f6c with SMTP id 5b1f17b1804b1-49b91c290c1mr379400725e9.7.1788251787040; Tue, 01 Sep 2026 01:36:27 -0700 (PDT) Message-ID: <844b82eb-5a8b-4e49-8a97-f1311120b61f@suse.com> Date: Tue, 1 Sep 2026 10:36:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Furkan Caliskan , xen-devel@lists.xenproject.org, Andrew Cooper References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> <258aa564-4856-4d28-8b90-aa858b25fdd2@suse.com> <06e18456-50ac-471d-8323-1560dd8b2a5c@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: <06e18456-50ac-471d-8323-1560dd8b2a5c@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1788251787-538D5CFC-3E7F54EF/0/0 X-purgate-type: clean X-purgate-size: 3539 On 01.09.2026 10:24, Jürgen Groß wrote: > On 01.09.26 10:15, Jan Beulich wrote: >> On 01.09.2026 10:07, Jürgen Groß wrote: >>> On 01.09.26 09:22, Jan Beulich wrote: >>>> On 31.08.2026 14:59, Jürgen Groß wrote: >>>>> On 31.08.26 11:45, Andrew Cooper wrote: >>>>>> On 31/08/2026 6:16 am, Furkan Caliskan wrote: >>>>>>> Every vcpu_create() call site that builds more than one vcpu loops >>>>>>> over ids up to d->max_vcpus and stops on the first failure, but none >>>>>>> of them roll max_vcpus back to match. This leaves d->vcpu[i] == NULL >>>>>>> for ids below max_vcpus >>>>>> >>>>>> As I told you before, you must cope with this property in non-error >>>>>> scenarios. >>>>>> >>>>>>> , which anything walking d->vcpu[] can then >>>>>>> dereference. This is what caused the crash: sched_move_domain() >>>>>>> walks every vcpu slot up to max_vcpus without checking for empty >>>>>>> ones, so when a domain built in a non-default cpupool had vcpu >>>>>>> creation fail partway through, domain_kill() later moving it back >>>>>>> to the default cpupool handed one of its empty slots straight to >>>>>>> the new cpupool's scheduler, causing a NULL-pointer dereference >>>>>>> inside sched_alloc_udata(). >>>>>>> >>>>>>> Add vcpus_create(d): creates every vcpu of d up to max_vcpus and >>>>>>> rolls max_vcpus back to the failed id on error. This keeps >>>>>>> d->vcpu[i] is non-NULL for all i < d->max_vcpus >>>>>> >>>>>> No, it really doesn't. >>>>>> >>>>>>> , instead of guarding >>>>>>> every reader of d->vcpu[] agains holes individually. >>>>>>> >>>>>>> Convert every site that builds vcpus in a loop to call this function >>>>>>> instead. >>>>>>> >>>>>>> Fixes: 61649709421a ("xen/domain: Allocate d->vcpu[] in domain_create()") >>>>>>> Suggested-by: Juergen Gross >>>>>>> Signed-off-by: Furkan Caliskan >>>>>> >>>>>> For the avoidance of a long drawn-out argument, nack.  Under no >>>>>> circumstances are you editing d->max_cpus after it's put into the domain >>>>>> list. >>>>>> >>>>>> You've chosen to do so at a point where the domain object is live, >>>>>> visible in the system and able to be the target of other hypercalls. >>>>>> >>>>>> Furthermore you have not fixed what your commit message claims. >>>>>> d->vcpu[...] is still NULL for an arbitrary period of time, including >>>>>> being able to be the target of hypercalls, before vCPUs are created. >>>>>> >>>>>> All code MUST be able to cope with d->vcpu[...] being NULL.  It's how >>>>>> the object lifecycles must work, because creating vCPUs is not atomic >>>>>> with respect to creating domains. >>>>> >>>>> Would you be fine with me creating a patch series moving vcpu creation into >>>>> domain_create()? >>>> >>>> This was discussed before, and however nice it would be for the issue at hand, >>>> it would get in the way of us wanting to have CPU policy for domains put in >>>> place before vCPU-s are created, such that on x86 the XSAVE area can be sized >>>> once and for all. >>> >>> This could be done when unpausing the domain initially. >> >> Imo unpausing shouldn't fail because of memory shortage. > > As long as the domain hasn't started running I don't see why this would be > different to the case where not all vcpus could be created. I do. One could create a domain ready to be unpaused, but being kept paused until whatever event triggers its launching. That better wouldn't fail, except in extraordinary situations. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 08:40:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 08:40:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404618.1638275 (Exim 4.92) (envelope-from ) id 1x1K2k-00034i-Jl; Tue, 01 Sep 2026 08:40:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404618.1638275; Tue, 01 Sep 2026 08:40:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1K2k-00034b-GI; Tue, 01 Sep 2026 08:40:34 +0000 Received: by outflank-mailman (input) for mailman id 1404618; Tue, 01 Sep 2026 08:40:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1K2j-00034U-CP for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:40:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1K2i-00345U-KQ for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 10:40:32 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a968f79-e002-0a2a0a5209dd-0a2a4502ea5e-20 for ; Tue, 01 Sep 2026 10:40:32 +0200 Received: from [209.85.208.41] (helo=mail-ed1-f41.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a968f80-6ca4-0a2a45020019-d155d029ade1-3 for ; Tue, 01 Sep 2026 10:40:32 +0200 Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-6a374bea882so276870a12.1 for ; Tue, 01 Sep 2026 01:40:32 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a674a188a9sm101195a12.14.2026.09.01.01.40.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 01:40:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788252032; x=1788856832; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=veJ9NDTcaU88Dl+3HnTxohs9tGQY8BP7EVcbMA2Q4RQ=; b=htl7JNmjV8L+rdLrg9IKRRVa5Aik/rQFzuTv45LUZOxkNnzPxFs1Cpq2kdpqnofPcO gmRX6f4R3PeblOrwSABaiQGum767TT8JZjduqU12A2VtWG0VkKc9nWgHXt7OxHPymIOK 85ah3GvvpkkHE+0UVgUFvQWv1KvNaflUrfZCKHff0fEoeS0si7wx8lJvVBdg/UhbNiQP gfnoGMPoRL8k0IEIQ5KdhDIq5xyYjYdHsEPZA+ULEmIvb7Can96u/JNM1lCtYPvYWLEd kb+LrWx/MHHkWwfR94WAz51D/hJOQGgFKLCtsk8bRyKR3H8mjf7aUYz41wnlz67/AesV G6RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788252032; x=1788856832; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=veJ9NDTcaU88Dl+3HnTxohs9tGQY8BP7EVcbMA2Q4RQ=; b=QrkF00vdCdZ5KTONFMI+JgocjJaHarS6YSoKSIpTdkIxieFR5IUJAGdt8cj4B3gNVe X0/3OwYeambzQHBy01nUU9OPLomJW/Z05Wou0GNCORQ35ZRSM39LNiimLRURBWr91Cv9 /wx6WCxnckSrdzlmB+OlMMxV5NrmQqPR4t0wz+HzzdD0ewcYHbZ8CIQgNCAemBe7D0cz Ga9uNSp9DZI91S7Jl+tWxGJ30+5Hf7T9sIow5F5N0go+WVUROY9GVcdxqrN21OmKcgIm X2eeNe3HEBLvk1fz5w/WvF+dkqAh6kPIGbQXnigNxAjrr4O72klEKW33Mhu6BQ1dmKPf xTeA== X-Gm-Message-State: AFuF++mGbKNL4koN7JKOtjorcoZkthgsT58ySmhKCe4UZX0YJPBtccX6 gPO7cGBxJFuT3x06IxYXnUpau0EXilv1nR8oUZREctNn81aHm7c5Rc9e X-Gm-Gg: AYBFou0Fn01sxKiRzRLCjAvYCW8mZl7knig4aAtCsvV1GayaZ5W5idCJ8dozljhXeTR pTTBxk9QgpQNfKAI14vFjDGlmw9tIyPQKtUlwo2xJaTX5GW39kXzSmyxUZ8P70zNDHMJ3Rl2vx2 tGoPds3yb3At33HMLQVGnTBCKqzghJhDhkGfBDfC08LcTQI1jtj3PCrsrCX9UV4CmNXnrO/1HB9 yf3vl+URGxb/T4oz243o3CcHTkrJV7MIa1khx+gduhBVKNGmejgrd6IcmkN5jRrKzNSVqpbdCbp PrMs96pIsywVlwWRHvfXtx+SR/G7IBikYVcX3wi4IZZwpKMDq9Dhr6dVw3ZMdYSxuf3TxFRuTC9 5x9CKc1xtE+ItnUA52sKqTlDiX9XwLsMtbcOM376i9t2vIfHpet5hL2S4URXeqBmOPtqwFwcnUp LJMyOtNI5TaUfCcDQ+Js4IToF5z/GqXl7P3uQj9MLOIFqKBRhHzbbFGcM+aeejpMozJ+h2zsFn3 elaXiah6BCHpSOotsq1SM86+oRXTCqvoOpkQ9YshicIv+iJVtzz X-Received: by 2002:a05:6402:3245:b0:6a5:f44e:a009 with SMTP id 4fb4d7f45d1cf-6a663a4a9dfmr3601664a12.7.1788252031604; Tue, 01 Sep 2026 01:40:31 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 10:40:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788252032-F34BE2AC-8D4F7832/10/73395122804 X-purgate-type: spam X-purgate-size: 1242 On 8/31/26 2:48 PM, Baptiste Le Duc wrote: >> hstatus.VSXL is WARL, so its reset value is implementation-defined. Xen >> supports 64-bit guests only, so program it explicitly instead of relying >> on whatever the hardware happens to leave there. >> >> This matters beyond the guest's own view of itself: decoding a trapped >> instruction depends on the effective XLEN of the guest, as the encodings >> which exist for XLEN=64 only must not be recognized for a 32-bit one. >> > It's not clear which instruction "decoding a trapped instruction" refers > to without more context. I assume you mean decode_ldst_insn() in > emulate.c, but the patch introducing that function comes later in the > series, so this isn't obvious on a first read. > > Please reorder the series so this patch follows the one introducing > decode_ldst_insn(), or reference it explicitly in the commit message > (e.g. "load/store trap emulation, introduced later in this series in > emulate.c, needs..."). > I think I can just drop this paragraph from commit message. Even without it considering that we are supporting only rv64 guest we should set hstatus.VSXL correspondingly and not rely on what hardware will put there. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 01 08:43:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 08:43:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404624.1638284 (Exim 4.92) (envelope-from ) id 1x1K5L-0003fJ-V6; Tue, 01 Sep 2026 08:43:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404624.1638284; Tue, 01 Sep 2026 08:43:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1K5L-0003fC-SH; Tue, 01 Sep 2026 08:43:15 +0000 Received: by outflank-mailman (input) for mailman id 1404624; Tue, 01 Sep 2026 08:43:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1K5K-0003f6-Fb for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:43:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1K5J-00GH3a-Se for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 10:43:13 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96901e-bab6-0a2a0a5309dd-0a2a450cdbd2-36 for ; Tue, 01 Sep 2026 10:43:13 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a969021-f479-0a2a450c0019-d1558034e99b-3 for ; Tue, 01 Sep 2026 10:43:13 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49cd77e0f95so6617905e9.3 for ; Tue, 01 Sep 2026 01:43:13 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cdce3e4e7sm49150395e9.9.2026.09.01.01.43.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 01:43:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788252193; x=1788856993; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/0USoLN8FVdd3lcOS3ojDFiLfFOLRJm00uoUVfJAOck=; b=AFaxUP2d93AhTlx0Cf2LiDTB+/l3Eh7PpNKB0fyKX8qyqzpfiXP2j/BOjRkk1SwUrA x1dNwcuslvhcUX9nkT/Gdfk+LFG+cC/IcClxzNkSRAu9zGa5nuTNVDxXM1YTZMddP5Wb /XEIqh9ba5QQ+tRDs5GPCtIMN7S809yIQFeWHjV7LU3+nCXsiraW9olNzQLk/AaBPnl4 ML2MFYsTv/StrNn8szCB5ZfXuf/TvZtb5mSTY+tuPXrth55rjQGtzFdtK8qTq6vj7Brk eCsmQNYa+7mLx8QTms5HxhHzPh5caH76PHwgTHZDjaaTvmtLSbc1JdYtW8MZkT2tYmqq qoXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788252193; x=1788856993; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=/0USoLN8FVdd3lcOS3ojDFiLfFOLRJm00uoUVfJAOck=; b=T+s0fOh0IPMQ5wmTH2iZfttOS7WPmX92HhvWGbeCPRPUBUVmGrecUvhqUN4yGLj4ML Bsghkby7lF+6suBvDVlbzZaSeqQvTa7ZM+AxNYo41rmpvPgH16WLuEqP3H50vwEG/XtY mdgsDiDPJnCc6QGqgJG6MFqjqNECxJJOn9QnNFDyFRgZfYNpyz8kgnTPI02VyDA5jJgh fVsnjxkDXGqWi9U8XmqRIJ1/T3KNk32MlDNLx5cwsxsoZLCcKbmG+oFXnPLKlN4SXfDn em/G9DZ8ZcgR0yZPY3VGHNANLNyjK4Fj6k6tHEKKVnjKnBi12LHnJqvCMvwACvx0Acj6 hOaw== X-Gm-Message-State: AFuF++m8ClGH+HIT5cRcpJnZ1KM8Lv4sVp+W/E4c3X1pANwpVdbvG80d RjES0iYr2CJh1SoX8LpExU1WE1nhjg30Mx58t7KF3ggdDvhCYv2aFWRi X-Gm-Gg: AR+sD1094xFTjPk41Mu9Alwb8HHzm2cYVg2hZEFrMuT179e1umYPza6cJfmT2PbjFU3 8tRa/iVi1JQMRrwJg1YkRMyIRm2oaiVCx8HeiipGALj+4TWPXabHTwrENRu1fQNZ3zzOyChCRkc MQxXSdjrTLFCIUqpCOIjJAOIKJWO8bstuaACfgHb6d9Xea+S0qtPHKMCVLiyFXHrIPzc5FL5bFX MdiGYnLFj6QgmlaJl02iT0Tqq2wmImvJZShv8D23bZ9AKXeCspV3DnIjjPfEk+IDJKy8rQPN1e3 M2Je27+HKL9gBGbDjh0LwVaiy78x7MBid/7YWdxMqxvJXgea9+zskdWlmHf5KJDCEVbREeHY+0G 6Roef1lgTp4gqgY8V9Ix/feyUU1w2bTw0ylUZ3CEL3OyqaFCS4ewJuPlZ4bj+DbGtIG5+NONblN UFHvE80J4lO9sWeBtJRiTm/yyrFL4Xx7r401QEqudaMeaon6ZSN1j/YS/mZthyiwI6+vthK3ysa wtq4MJSJbxOKtF1oNPi4ALvobivlmNNdA5tiV4owa/LuvS3kiPy X-Received: by 2002:a05:600c:870c:b0:499:dc34:bdc with SMTP id 5b1f17b1804b1-49b91c1c401mr577745495e9.1.1788252192846; Tue, 01 Sep 2026 01:43:12 -0700 (PDT) Message-ID: <26d9af52-8c02-44d9-b475-1cbdc451be5f@gmail.com> Date: Tue, 1 Sep 2026 10:43:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 05/39] xen/riscv: request a G-stage flush on vmenter when VMIDs are disabled To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <4274740481062ef92a76debd9c3f1e8371858735.1787838835.git.oleksii.kurochko@gmail.com> <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd2094000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd2094000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788252193-76ADCA5B-49D731DA/10/73395122804 X-purgate-type: spam X-purgate-size: 1450 On 8/31/26 2:48 PM, Baptiste Le Duc wrote: >> vmid_handle_vmenter() reports that no flush is needed when VMIDs are >> unavailable (vmid=off, or hardware with no more than one VMID bit). Every >> domain then runs under VMID 0 with nothing flushed in between, so as soon >> as a hart runs more than one domain, a domain entered there can use the >> G-stage translations left behind by the domain which ran before it. >> >> Adjust the comment in p2m_handle_vmenter() accordingly: skipping the >> VS-stage flush no longer relies on an old VMID not being reused, which >> doesn't hold when there are no VMIDs to begin with. >> >> While at it, spell the other early return as a bool literal. >> >> Fixes: bff3b9ea4696 ("xen/riscv: introduce VMID allocation and manegement") >> Signed-off-by: Oleksii Kurochko >> > > FWIW this comment and p2m_handle_vmenter() itself get dropped a few > patches later in "implement vCPU context switching", which folds the > VMID claim into p2m_ctxt_switch_to(). The fix survives there via the > need_flush check. Is this patch really needed? > I think yes as it is fixing current implementation of what we have in staging. We could back to this topic after the discussion of "implement vCPU context switching" in the case someone will suggest better way to handle p2m context switch (probably without dropping of p2m_handle_vmenter(). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 01 08:47:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 08:47:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404630.1638293 (Exim 4.92) (envelope-from ) id 1x1K9C-0004Bk-EE; Tue, 01 Sep 2026 08:47:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404630.1638293; Tue, 01 Sep 2026 08:47:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1K9C-0004Bd-BR; Tue, 01 Sep 2026 08:47:14 +0000 Received: by outflank-mailman (input) for mailman id 1404630; Tue, 01 Sep 2026 08:47:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1K9B-0004BX-Ae for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 08:47:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1K9A-007UL0-N7 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 10:47:12 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a969110-bab6-0a2a0a5309dd-0a2a4504cc50-4 for ; Tue, 01 Sep 2026 10:47:12 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a969110-b57f-0a2a45040019-d155dd2da5bf-3 for ; Tue, 01 Sep 2026 10:47:12 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-4843e397f74so692840f8f.1 for ; Tue, 01 Sep 2026 01:47:12 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48442c42492sm3965429f8f.1.2026.09.01.01.47.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 01:47:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788252432; x=1788857232; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=qCLTnqHsJEHNmB+nCX1lXvcUL5VDVX23XUPflETjZ1k=; b=FC0K3F4fY/FQfsvfgetiy5EFkkG6iqr/h0J2LA6X9LmRQMAFgg3Sxq/mXzHrsND+Go KoEjX/DHIOi2gZclbubgFabTJ4WrIPwBVFq6JOnHemjh1/OMSPhQapmAOw1l16poexG+ AJR2sdBB2ycVafUHtfkO55vKotn+jrNqSY+uaY783RQYbNANHgstfbGLbJMNFXrq8gv8 B/UVR2CsCYjdsvWA0YxpMQbvPf9MXqAA/R5UgqA9zTWFsaIngep3JS46T/5SfKXm0WbE /qlXvG2Ot8ZGbdrpsb6A8wmvC6iZtDqV3bsPL4Zlx3pL53+sRPiWLYptnxtqkvLY1DmW KJiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788252432; x=1788857232; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=qCLTnqHsJEHNmB+nCX1lXvcUL5VDVX23XUPflETjZ1k=; b=ZREWjowJFslaH3zol55YbZ01gnboc7TtRdskFq/GROB1Ht8hg/ZrMGIbPcy9TjMZEW 5Ik0I1EYb2V8JQacYP//NV7PwME7eM6eoKtmX9rSJ5JZFB5IyNoQcvHP0UZUEhp5eGQe 8Ud6IHxw5lmc3n7xnNldEQL7UMr2FwWWMHVSonR98Al1A2+puQlYHq1aNz41Egu3uNid 51QoZsXoTzQzO+iNn3vrcA3GcNWCwJ5Nt9XrmT8T6Ksn6hW3KYHbQQUgwora2vjlb/ID rJWkm3A1DImDAbLAlu489xiJPM8PwlcCeLZ3QeWQcd6JyhjjSa0CC6W0Rqzf0msMu+rB UU9Q== X-Forwarded-Encrypted: i=1; AKwUvBxRC3qqOM9hL6+AA82NVxp4M59YH+NSALgsOEFjq7Giv+Tv0cyuGs1m7RgCXX+F1zc9qhnhDKPMGPg=@lists.xenproject.org X-Gm-Message-State: AFuF++kLpoEUo4j3w/N3cF5CIVjRwmgq85MNukwLVMl4msoLxuS2QU+O DwMBerraFRH31ZywFymRCozyHNeGUlow2ub8q/CxJ0zrsw9Bs+MnEp4C X-Gm-Gg: AYBFou0qBhdtgb+th/JkYrnBCH679Exp3aEfp1B2btIECK3RnEstTcXsmVerMdXMSWA fpFIbLZnwnd+r65DzxuNgsLXJc+UuCUlIMMvmf49fklcGM43J1vNcQ0AHSEao4iRc22NET2C93J XXGNKq7tneHFxmUeWiODgxval1ud3oc/UsDcTCddxx7HiW0lLcC2l/ZO/Ot5H5xqERPNmieWFwp fmXA8e2YwyiuzoFtmSk+Hd2DCYYjNo742wFc7ZTn4CJA0VfCmQsXxZEfdOuWO7fs5xuHQs0JwJx QQxCJjAQ0/0bW7uMQzOuvHv1cfDFbfhmwIGTqQHS15152f32HG22m9Oujd4GJMnufTeHntvmyUW w9xl0dSaThP6VAsOPSE+ZBvIU6u0WdCSgkihRdfU418WfTLP5uGaSxnHavyOVdaCxpgZ9430gc8 WyhOcL3U7kNHITGi81lJ9Y/3AOF5fGykuGFrWIVPUQpgks4+eFEr+eRc1N7bgfxqC6+1kcf7bBG +YOtZsymkXqVOVVEvw798dtDz+XxSMNx3fxlpB3CydQbJVM+p5B X-Received: by 2002:a05:6000:46cf:b0:484:44ec:2c3a with SMTP id ffacd0b85a97d-48444ec2e31mr3471523f8f.0.1788252431895; Tue, 01 Sep 2026 01:47:11 -0700 (PDT) Message-ID: <2533f0eb-1816-459b-a3a8-365d8a72c11f@gmail.com> Date: Tue, 1 Sep 2026 10:47:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 06/39] xen/riscv: use UINT64_MAX to disable the VS-timer To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <93829c39b080d288ea342c7375d5307f93ee9a29.1787838835.git.oleksii.kurochko@gmail.com> <5ed7172d-24e7-4ace-964e-dad814c2dc6a@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <5ed7172d-24e7-4ace-964e-dad814c2dc6a@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788252432-C22D4B50-5D36220E/10/73395122804 X-purgate-type: spam X-purgate-size: 1062 On 9/1/26 9:12 AM, Jan Beulich wrote: > On 27.08.2026 17:20, Oleksii Kurochko wrote: >> vstimecmp is a 64-bit CSR independently of XLEN, which is why it is >> written with csr_write64(). On RV32 that macro splits the value into >> the vstimecmp/vstimecmph pair, so passing ULONG_MAX (0xffffffff there) >> writes all ones to the low half and zero to the high half, leaving the >> CSR at 0x00000000ffffffff rather than at its maximum. A VS-timer irq >> would then become pending as soon as (time + htimedelta) reaches 2^32, >> which is exactly what the code is trying to avoid. >> >> Use UINT64_MAX, which matches the width of the CSR. On RV64 it is equal >> to ULONG_MAX, so no functional change there. > > Hmm. This again is an example where code (likely) will be silently wrong > for RV128. Presumably the CSR would be XLEN bits wide there as well, and > hence you'd need to write it with 128 bits of ones. Imo ~0 is what wants > using here. > Agree, it makes would be better to have ~0 here. I will apply that. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 01 09:23:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 09:23:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404661.1638353 (Exim 4.92) (envelope-from ) id 1x1Khi-0004AJ-MC; Tue, 01 Sep 2026 09:22:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404661.1638353; Tue, 01 Sep 2026 09:22:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Khi-0004AC-JQ; Tue, 01 Sep 2026 09:22:54 +0000 Received: by outflank-mailman (input) for mailman id 1404661; Tue, 01 Sep 2026 09:22:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Khh-000491-DE for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 09:22:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1Khg-003CCt-9n for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 11:22:52 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96995d-8faa-0a2a0a5109dd-0a2a45018468-32 for ; Tue, 01 Sep 2026 11:22:52 +0200 Received: from [209.85.208.48] (helo=mail-ed1-f48.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9694f7-5984-0a2a45010019-d155d030a455-3 for ; Tue, 01 Sep 2026 11:03:51 +0200 Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-6a5f968ada7so1695011a12.0 for ; Tue, 01 Sep 2026 02:03:51 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a66ccda72bsm493177a12.9.2026.09.01.02.03.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 02:03:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788253431; x=1788858231; darn=lists.xenproject.org; h=content-type: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:content-type; bh=oD/Tfb1E4zLYaJUhultunEzBMFT48rArzR8BmH+9I8E=; b=UJ8Z/trxoUk2Og0Jy8hnL3+y4C6vH/scmktWVChuVsqJfM7bUF7eAZiyOzbn0ZOg3y MnSHOwEJ8qawVyuDjtze1qhMFZEjuE/6I4pntIL3LxN7IU9ugFTI0uoypks3rsr8RTod kdOb9ASaxWS6qyoAcJuvMJkxR3TYi9VZRsLmvnSO8EE+nY1CA7cTniPiQukphO+EQFka ifZ2N7YGlDdnGrZE/fDC+Mhawb1Iz6ulhe4fuys17KfRxtl8Yzf1BzYtNA7sBZrJ9Sma PxWfw0CNL5fENxC4MtQKAQEckqPCBxiOIhqfovpdz9ZeOAjfSmNYvHVUsMvbiabaNIjX j9zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788253431; x=1788858231; h=content-type: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 :content-type; bh=oD/Tfb1E4zLYaJUhultunEzBMFT48rArzR8BmH+9I8E=; b=Il9xGFJPCDDMfxd7Lsds9AKNUSdCbj+7qn80ooaVfjgi8TFcXJs1i9o/eh6DU9PWBs Mo4X09TXjpzObHCt8hZVJqSqaufKQZPmSZ9d6rTp4FmPb1BXmQDJtzwud4/OMNC19bNW rS30/K/G4Th8ubaA03xlXTyi2xyhMC+m3LkFKc7aIk04NVuRZK6VbkIV3t06vUQUZg6Y CsBorlo1hfIQmRTEHOBs05xPQZ59MbEW6lA6tt3HhXG3vFcfPuPsQPmPylaUtJt/Ss8+ 19H7meDTl1KWzFknwl19p8FWA/IJ9DWofw5suboFLvge/AnErHC+kZvrV9brbMe7dofL 2khA== X-Forwarded-Encrypted: i=1; AKwUvBxqjvHDFkFZKMmQ6tALWx0m0zrZZyqWI5kk20wG7N2tex4gmPsEgAs7anE3HykwRXzrokcDzHXYO0I=@lists.xenproject.org X-Gm-Message-State: AFuF++lp1OA3smZFkIN8bc65CUTgPLpACfRPh8tFDOuPGZRW/Ik+WGFt Fwpyc1uVpEExKfQLtQd8eqLcCxNoBcTSitScf/OFnCFpax0mgmnvVXcsHtWgOhMD7V8= X-Gm-Gg: AYBFou0ptqoCF5TaGheJ0QpCxgdk0Cf2fzMO0e8GHki36vBCwEvvKld6llGwqtg0E4O l01NvmDqTNsiohiu7seXWlRvY1f3SqDhr9DuL454zNex7Gen8VEIhvxGvmA5AUn3KDXETB8c8uO lv0yjojFxA9ac27lVZssPqUCD1ZUO5OM1pBxRoL0Ml25hR3QIblOeyERjzfXR0ACcm26hMBhLQx L1ITbgfrXJBnci5B3l66MmK7mFCwij9wLRSjfoA9lxMlKzelSnSunBu78NCAmIjjnHMiQc34ezo fv8wzpnQj8b6H214HfC05tqn7pb7Q/vRXOKbYRDgPqD1Tw8kVO2v4UdhHGMooFtfFXrAtwmAX/2 TpjHx7Pvj9qvmtqHMJyCxQnVBJQdHA8PdaSz+Ckly/ojdF3RyV69GVyonbEjMBAosqBLiZoYX9a 9hoEIBbo/PtzD7Ja+poReV+K/JGHArAeqGaVkAmFR01HLJ38hlI/D+XqAggepcjEdHFGFoINx4f 6r+wGf1zG8lWI8V1xD2qn9qDTXLtGPTvL4FnZ8Mojlo6jtW2tHEwi+HF8YEj8FhVshtrnx3G+wV 17Xa+fiLB5tM/w== X-Received: by 2002:a05:6402:21cb:b0:6a5:f4ef:7fae with SMTP id 4fb4d7f45d1cf-6a66a735633mr2559766a12.6.1788253430591; Tue, 01 Sep 2026 02:03:50 -0700 (PDT) Message-ID: <4a8c362a-9aac-4e0c-aea6-bc5841143ce6@suse.com> Date: Tue, 1 Sep 2026 11:03:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync To: Jan Beulich Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Furkan Caliskan , xen-devel@lists.xenproject.org, Andrew Cooper References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> <258aa564-4856-4d28-8b90-aa858b25fdd2@suse.com> <06e18456-50ac-471d-8323-1560dd8b2a5c@suse.com> <844b82eb-5a8b-4e49-8a97-f1311120b61f@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <844b82eb-5a8b-4e49-8a97-f1311120b61f@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------WT0gR00oQdO63Q0G5F6VN9z0" X-purgate-ID: tlsNG-d62444/1788253431-BDC79757-DB75A911/19/8849265665 X-purgate-type: clean X-purgate-size: 13612 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------WT0gR00oQdO63Q0G5F6VN9z0 Content-Type: multipart/mixed; boundary="------------CW4ogjS7zWmg5moZ9mFj4xNj"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich Cc: dfaggioli@suse.com, gwd@xenproject.org, roger@xenproject.org, anthony.perard@vates.tech, julien@xen.org, bertrand.marquis@arm.com, michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, teddy.astie@vates.tech, Furkan Caliskan , xen-devel@lists.xenproject.org, Andrew Cooper Message-ID: <4a8c362a-9aac-4e0c-aea6-bc5841143ce6@suse.com> Subject: Re: [PATCH v3 1/2] xen/common: add vcpus_create() and keep max_vcpus in sync References: <20260831051637.5029-1-frn1furkan10@gmail.com> <20260831051637.5029-2-frn1furkan10@gmail.com> <4a71e08b-b3c6-4f14-a4ae-cc0506659ae9@suse.com> <8a187b46-9ec2-4040-bd00-c71059dad952@suse.com> <258aa564-4856-4d28-8b90-aa858b25fdd2@suse.com> <06e18456-50ac-471d-8323-1560dd8b2a5c@suse.com> <844b82eb-5a8b-4e49-8a97-f1311120b61f@suse.com> In-Reply-To: <844b82eb-5a8b-4e49-8a97-f1311120b61f@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------CW4ogjS7zWmg5moZ9mFj4xNj Content-Type: multipart/mixed; boundary="------------PwyUcfJHW0oJhKVge5b0oTJr" --------------PwyUcfJHW0oJhKVge5b0oTJr Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEuMDkuMjYgMTA6MzYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwMS4wOS4yMDI2 IDEwOjI0LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMDEuMDkuMjYgMTA6MTUsIEph biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDAxLjA5LjIwMjYgMTA6MDcsIErDvHJnZW4gR3Jv w58gd3JvdGU6DQo+Pj4+IE9uIDAxLjA5LjI2IDA5OjIyLCBKYW4gQmV1bGljaCB3cm90ZToN Cj4+Pj4+IE9uIDMxLjA4LjIwMjYgMTQ6NTksIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+Pj4+ Pj4gT24gMzEuMDguMjYgMTE6NDUsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+Pj4+Pj4+IE9u IDMxLzA4LzIwMjYgNjoxNiBhbSwgRnVya2FuIENhbGlza2FuIHdyb3RlOg0KPj4+Pj4+Pj4g RXZlcnkgdmNwdV9jcmVhdGUoKSBjYWxsIHNpdGUgdGhhdCBidWlsZHMgbW9yZSB0aGFuIG9u ZSB2Y3B1IGxvb3BzDQo+Pj4+Pj4+PiBvdmVyIGlkcyB1cCB0byBkLT5tYXhfdmNwdXMgYW5k IHN0b3BzIG9uIHRoZSBmaXJzdCBmYWlsdXJlLCBidXQgbm9uZQ0KPj4+Pj4+Pj4gb2YgdGhl bSByb2xsIG1heF92Y3B1cyBiYWNrIHRvIG1hdGNoLiBUaGlzIGxlYXZlcyBkLT52Y3B1W2ld ID09IE5VTEwNCj4+Pj4+Pj4+IGZvciBpZHMgYmVsb3cgbWF4X3ZjcHVzDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IEFzIEkgdG9sZCB5b3UgYmVmb3JlLCB5b3UgbXVzdCBjb3BlIHdpdGggdGhpcyBw cm9wZXJ0eSBpbiBub24tZXJyb3INCj4+Pj4+Pj4gc2NlbmFyaW9zLg0KPj4+Pj4+Pg0KPj4+ Pj4+Pj4gLCB3aGljaCBhbnl0aGluZyB3YWxraW5nIGQtPnZjcHVbXSBjYW4gdGhlbg0KPj4+ Pj4+Pj4gZGVyZWZlcmVuY2UuIFRoaXMgaXMgd2hhdCBjYXVzZWQgdGhlIGNyYXNoOiBzY2hl ZF9tb3ZlX2RvbWFpbigpDQo+Pj4+Pj4+PiB3YWxrcyBldmVyeSB2Y3B1IHNsb3QgdXAgdG8g bWF4X3ZjcHVzIHdpdGhvdXQgY2hlY2tpbmcgZm9yIGVtcHR5DQo+Pj4+Pj4+PiBvbmVzLCBz byB3aGVuIGEgZG9tYWluIGJ1aWx0IGluIGEgbm9uLWRlZmF1bHQgY3B1cG9vbCBoYWQgdmNw dQ0KPj4+Pj4+Pj4gY3JlYXRpb24gZmFpbCBwYXJ0d2F5IHRocm91Z2gsIGRvbWFpbl9raWxs KCkgbGF0ZXIgbW92aW5nIGl0IGJhY2sNCj4+Pj4+Pj4+IHRvIHRoZSBkZWZhdWx0IGNwdXBv b2wgaGFuZGVkIG9uZSBvZiBpdHMgZW1wdHkgc2xvdHMgc3RyYWlnaHQgdG8NCj4+Pj4+Pj4+ IHRoZSBuZXcgY3B1cG9vbCdzIHNjaGVkdWxlciwgY2F1c2luZyBhIE5VTEwtcG9pbnRlciBk ZXJlZmVyZW5jZQ0KPj4+Pj4+Pj4gaW5zaWRlIHNjaGVkX2FsbG9jX3VkYXRhKCkuDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gQWRkIHZjcHVzX2NyZWF0ZShkKTogY3JlYXRlcyBldmVyeSB2Y3B1 IG9mIGQgdXAgdG8gbWF4X3ZjcHVzIGFuZA0KPj4+Pj4+Pj4gcm9sbHMgbWF4X3ZjcHVzIGJh Y2sgdG8gdGhlIGZhaWxlZCBpZCBvbiBlcnJvci4gVGhpcyBrZWVwcw0KPj4+Pj4+Pj4gZC0+ dmNwdVtpXSBpcyBub24tTlVMTCBmb3IgYWxsIGkgPCBkLT5tYXhfdmNwdXMNCj4+Pj4+Pj4N Cj4+Pj4+Pj4gTm8sIGl0IHJlYWxseSBkb2Vzbid0Lg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gLCBp bnN0ZWFkIG9mIGd1YXJkaW5nDQo+Pj4+Pj4+PiBldmVyeSByZWFkZXIgb2YgZC0+dmNwdVtd IGFnYWlucyBob2xlcyBpbmRpdmlkdWFsbHkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQ29udmVy dCBldmVyeSBzaXRlIHRoYXQgYnVpbGRzIHZjcHVzIGluIGEgbG9vcCB0byBjYWxsIHRoaXMg ZnVuY3Rpb24NCj4+Pj4+Pj4+IGluc3RlYWQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRml4ZXM6 IDYxNjQ5NzA5NDIxYSAoInhlbi9kb21haW46IEFsbG9jYXRlIGQtPnZjcHVbXSBpbiBkb21h aW5fY3JlYXRlKCkiKQ0KPj4+Pj4+Pj4gU3VnZ2VzdGVkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxq Z3Jvc3NAc3VzZS5jb20+DQo+Pj4+Pj4+PiBTaWduZWQtb2ZmLWJ5OiBGdXJrYW4gQ2FsaXNr YW4gPGZybjFmdXJrYW4xMEBnbWFpbC5jb20+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZvciB0aGUg YXZvaWRhbmNlIG9mIGEgbG9uZyBkcmF3bi1vdXQgYXJndW1lbnQsIG5hY2suwqAgVW5kZXIg bm8NCj4+Pj4+Pj4gY2lyY3Vtc3RhbmNlcyBhcmUgeW91IGVkaXRpbmcgZC0+bWF4X2NwdXMg YWZ0ZXIgaXQncyBwdXQgaW50byB0aGUgZG9tYWluDQo+Pj4+Pj4+IGxpc3QuDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IFlvdSd2ZSBjaG9zZW4gdG8gZG8gc28gYXQgYSBwb2ludCB3aGVyZSB0aGUg ZG9tYWluIG9iamVjdCBpcyBsaXZlLA0KPj4+Pj4+PiB2aXNpYmxlIGluIHRoZSBzeXN0ZW0g YW5kIGFibGUgdG8gYmUgdGhlIHRhcmdldCBvZiBvdGhlciBoeXBlcmNhbGxzLg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBGdXJ0aGVybW9yZSB5b3UgaGF2ZSBub3QgZml4ZWQgd2hhdCB5b3VyIGNv bW1pdCBtZXNzYWdlIGNsYWltcy4NCj4+Pj4+Pj4gZC0+dmNwdVsuLi5dIGlzIHN0aWxsIE5V TEwgZm9yIGFuIGFyYml0cmFyeSBwZXJpb2Qgb2YgdGltZSwgaW5jbHVkaW5nDQo+Pj4+Pj4+ IGJlaW5nIGFibGUgdG8gYmUgdGhlIHRhcmdldCBvZiBoeXBlcmNhbGxzLCBiZWZvcmUgdkNQ VXMgYXJlIGNyZWF0ZWQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFsbCBjb2RlIE1VU1QgYmUgYWJs ZSB0byBjb3BlIHdpdGggZC0+dmNwdVsuLi5dIGJlaW5nIE5VTEwuwqAgSXQncyBob3cNCj4+ Pj4+Pj4gdGhlIG9iamVjdCBsaWZlY3ljbGVzIG11c3Qgd29yaywgYmVjYXVzZSBjcmVhdGlu ZyB2Q1BVcyBpcyBub3QgYXRvbWljDQo+Pj4+Pj4+IHdpdGggcmVzcGVjdCB0byBjcmVhdGlu ZyBkb21haW5zLg0KPj4+Pj4+DQo+Pj4+Pj4gV291bGQgeW91IGJlIGZpbmUgd2l0aCBtZSBj cmVhdGluZyBhIHBhdGNoIHNlcmllcyBtb3ZpbmcgdmNwdSBjcmVhdGlvbiBpbnRvDQo+Pj4+ Pj4gZG9tYWluX2NyZWF0ZSgpPw0KPj4+Pj4NCj4+Pj4+IFRoaXMgd2FzIGRpc2N1c3NlZCBi ZWZvcmUsIGFuZCBob3dldmVyIG5pY2UgaXQgd291bGQgYmUgZm9yIHRoZSBpc3N1ZSBhdCBo YW5kLA0KPj4+Pj4gaXQgd291bGQgZ2V0IGluIHRoZSB3YXkgb2YgdXMgd2FudGluZyB0byBo YXZlIENQVSBwb2xpY3kgZm9yIGRvbWFpbnMgcHV0IGluDQo+Pj4+PiBwbGFjZSBiZWZvcmUg dkNQVS1zIGFyZSBjcmVhdGVkLCBzdWNoIHRoYXQgb24geDg2IHRoZSBYU0FWRSBhcmVhIGNh biBiZSBzaXplZA0KPj4+Pj4gb25jZSBhbmQgZm9yIGFsbC4NCj4+Pj4NCj4+Pj4gVGhpcyBj b3VsZCBiZSBkb25lIHdoZW4gdW5wYXVzaW5nIHRoZSBkb21haW4gaW5pdGlhbGx5Lg0KPj4+ DQo+Pj4gSW1vIHVucGF1c2luZyBzaG91bGRuJ3QgZmFpbCBiZWNhdXNlIG9mIG1lbW9yeSBz aG9ydGFnZS4NCj4+DQo+PiBBcyBsb25nIGFzIHRoZSBkb21haW4gaGFzbid0IHN0YXJ0ZWQg cnVubmluZyBJIGRvbid0IHNlZSB3aHkgdGhpcyB3b3VsZCBiZQ0KPj4gZGlmZmVyZW50IHRv IHRoZSBjYXNlIHdoZXJlIG5vdCBhbGwgdmNwdXMgY291bGQgYmUgY3JlYXRlZC4NCj4gDQo+ IEkgZG8uIE9uZSBjb3VsZCBjcmVhdGUgYSBkb21haW4gcmVhZHkgdG8gYmUgdW5wYXVzZWQs IGJ1dCBiZWluZyBrZXB0IHBhdXNlZA0KPiB1bnRpbCB3aGF0ZXZlciBldmVudCB0cmlnZ2Vy cyBpdHMgbGF1bmNoaW5nLiBUaGF0IGJldHRlciB3b3VsZG4ndCBmYWlsLCBleGNlcHQNCj4g aW4gZXh0cmFvcmRpbmFyeSBzaXR1YXRpb25zLg0KDQpPa2F5LCB0aGVuIHdlIGNvdWxkIGFk ZCBYRU5fRE9NQ1RMX2ZpbmFsaXplIGRvaW5nIHRoZSBmaW5hbCBhbGxvY2F0aW9ucyBBTkQN CmRvaW5nIHRoZSBjcmVhdGlvbl9maW5pc2hlZCBoYW5kbGluZy4gVGhpcyB3b3VsZCBldmVu IGNhdGNoIHRvZGF5J3MgZG9tYWluDQpjcmFzaGluZyBpbiB0aGUgVk1YIHNwZWNpZmljIGRv bWFpbl9jcmVhdGlvbl9maW5pc2hlZCgpIGNhbGxiYWNrLg0KDQpBdCB0aGUgc2FtZSB0aW1l IFhFTl9ET01DVExfbWF4X3ZjcHVzIHdvdWxkIGJlIGRyb3BwZWQsIHNvIHRoZXJlIGlzbid0 IG1vcmUNCndvcmsgZm9yIHRoZSB0b29sc3RhY2suDQoNCg0KSnVlcmdlbg0K --------------PwyUcfJHW0oJhKVge5b0oTJr Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------PwyUcfJHW0oJhKVge5b0oTJr-- --------------CW4ogjS7zWmg5moZ9mFj4xNj-- --------------WT0gR00oQdO63Q0G5F6VN9z0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqWlPUFAwAAAAAACgkQsN6d1ii/Ey+b NAf9FM2FeqlbKwCg4XEAaXSow6OBvuDu9ypz5S83KBI7NahDpFglJ9s2W7APdi/wTGnGP621V2/Q yerUcVVEBo8XHsdVn6NOhxBdItN4BuKIcLa7SrQyAO/jWWEzK171CN/2Q5UK0oqeYQZft2CFmIjh qOmTUHgkDFEjAbUjEtRrrcP+C7KzUJ5NDVzHVEyZKiRMZufzWxfYY625nOPXZENqHAOHH19jUfPR kB6CboFEwh8PScEpdBdrptrwtyiHLOYDvtUWVTMfjeMxYXsaQPJ3PQGddhF0867QywASiQBiOvar aFlFjlmXBBF+qlfx1BeSJ0nmBRL8pidxsmXJfZnpjw== =uZMb -----END PGP SIGNATURE----- --------------WT0gR00oQdO63Q0G5F6VN9z0-- From xen-devel-bounces@lists.xenproject.org Tue Sep 01 12:07:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 12:07:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404722.1638415 (Exim 4.92) (envelope-from ) id 1x1NHF-00012q-Nh; Tue, 01 Sep 2026 12:07:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404722.1638415; Tue, 01 Sep 2026 12:07:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1NHF-00012j-KK; Tue, 01 Sep 2026 12:07:45 +0000 Received: by outflank-mailman (input) for mailman id 1404722; Tue, 01 Sep 2026 12:07:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1NHE-00012d-Hx for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 12:07:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1NHD-008Aqp-4g for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 14:07:43 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96c00b-8faa-0a2a0a5109dd-0a2a4503c66c-4 for ; Tue, 01 Sep 2026 14:07:42 +0200 Received: from [209.85.216.47] (helo=mail-pj1-f47.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96c00d-fae8-0a2a45030019-d155d82faddb-3 for ; Tue, 01 Sep 2026 14:07:42 +0200 Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-3964dfb5a69so5539213a91.1 for ; Tue, 01 Sep 2026 05:07:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1788264459; cv=none; d=google.com; s=arc-20260327; b=hxEGPCqgTyRvEQu6tw/Z19mtIXGCfQNzzCbYE8TXMvTzmTEGxAhZV7LL/wkVWpCuZI KytjxTQC6QNK58ArMd5dXlbnfr40ozVc2O/tcjJfHpIQlL/Ov/Z7u3ewH0zL3mETTCay NxVILfn2MfCnc2LXLyokSG7flCt4BCCouFtKIdy9xBEi3bqAXLol/2AWKex3zRODD78h TakgPBapweCTt3DxpNY6y4ifj6V/tms7T3/kkLpHMG0Ei33I5sPuV9Wwk68cyikGZpO7 om9Yh3uDB6j4ay8w2eRf2wOcF3hNzsf5sbJBLa2Ate82z9gZ1/4JJo5JJ/4esAxcFZU/ UxQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xLtE8fa0CCYs8f89x0z6yjpC0T3F/CEkk97riHXdv2o=; fh=otpr6U4PuVZ9BZlj6EokwtOMbvR2IUSgfzEtVbeKrWM=; b=ArDWPs4E1bJzXJvuc6cnklrPf/d3V8Zg0nf9vWQZmzcEwHAkuxQGq+bfgtP73ZKkXA 8j5Z8quFiItOinpEc91UUQHHsgFzjPLRIDroFnmlsr0xgpWxhcVgAjk7Zb95TspuPZVk H+x3Jy7zSMtP8Tt5Wmj9NqHLEusRKAOc8UoXxFG3yUTQMuutpKi2VBy2qNpM6g1R5vCI iVcDwjZHj7RBFoIJSt1UBXTbAf6OZkmMCnbZu0d2NTE0SmpHPdNdkndkLjWmmas85U83 OT2lRda8kPX+b5VNmBAMmBP+dBO64aBMF2AEy01tJi1qnowU4mNOKzQgqjv0m6N+WY0P dSLg==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788264459; x=1788869259; darn=lists.xenproject.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=xLtE8fa0CCYs8f89x0z6yjpC0T3F/CEkk97riHXdv2o=; b=Kp3DqwLhnQ7uMRqMMVTIrsCxyMY+WXyLfhe8pURhPEcjBxLWXTrv7Hg58Zr0hU+gHY C3dcFvrH0E6HTXOV6RhmWNTrw114JfW+eRaZoexmiCXRApR1oCrR8yetLT/uo9Mg43Pq ZgafQGkwpc6xTM15d0dZO9PujCyLzRobhjedo6Kwpo7Ve9gwopXoCm3068gUD8LwalKt caj9JHZrCjbc4bXv1lzxs08/19j2O9RxbS6q8wqXz0ttIkN3a+F6mJIblNZxyZ+Tv/6q T6CG6GHu3bJmIdXmiDMfy0UYMn0/GcQOD7uzxoLTeh7VP2kEnZNXkpn0nAHddtpm3pr7 e7og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788264459; x=1788869259; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=xLtE8fa0CCYs8f89x0z6yjpC0T3F/CEkk97riHXdv2o=; b=Be/zTrps2T/w71eGcD09sIyvrgwbtptAwz/xztQBGB2/yzwiO97gkhuXYPrTDglujt r87iLZlDg8FMn//xbG5Mgv8/sg1c5wt0THz4h0TsmmYxscKDq+uFcwvmQrSKl/cbAL7e 7GDvfPxBY1mB9vuKg77jv4DQNvJ7l6jElHiS+q21VS+L38Af/lyc7Fa2ODvOZjEmvjth ZrLVnf6ZJfAKo2TSbpUA8nBpt54ciR13gnGr2cOveJ4MZw/ZPQ3+EBdRImHSVOY9LBsI p3waGcVOsfotxFxiCAoloTOT5IYfb4fDcvLp+n5P4EOi3HZPgtkUUe9HztAQo9ZQxJnJ hQIw== X-Forwarded-Encrypted: i=1; AKwUvBwFbszFW8yEi4t19+Q9p+aVyZ4xROZhs7bnPb/PXuxd7gsqmHW84m0laJ4nfc+mi8555ELoH/DDgAA=@lists.xenproject.org X-Gm-Message-State: AFuF++m7S6fh66/RwPAQfRYhFwIHPpHnFCYhhfGx1IAV48pv2CrQT1vV DX1AsYUTpRkgE2shoO1Tr6XYCdawIjfyueGd79ewkyDNj2YBcs8V5WBOcJnQjForEJLSm4w2fJW wijs0s7z9JtFmQDEQ0bmxFt54s+NOcHg= X-Gm-Gg: AYBFou0hIvkMEZADL7AbKI38w+ukhNsssUTyhcS3pyZIT7g2AM128ieIOWCOIOPHb5N JzYuJVLCZ78KKcWO03SQmLBJbcrA671D/jUkZSnf0WDJm4Q6GTdMPZ2l0Omz1cJU2cWbfCipIE1 KDgmbAJyfhfqHmYz3nJgNS9F/Lu1pMpaFKlIPbCB8GEEjlA5T2EM1s6FcZtIl6LStFcCtiuc7YS 7nS56YNDj17rUHVsmCy/8OkHNPrMq91a6OiBZdNTUajajyARldptUSU3ONCA+0R/znr+UST9AK9 5ojHNlnCJEtcDdvxOj+aLbAlcF2qXq3CS0kpuD/c2N8= X-Received: by 2002:a17:90b:3849:b0:398:9be8:ea64 with SMTP id 98e67ed59e1d1-39907e64255mr10696318a91.17.1788264458485; Tue, 01 Sep 2026 05:07:38 -0700 (PDT) MIME-Version: 1.0 References: <20260825184605.79318-1-andrewprecious388@gmail.com> <22091019-92ea-4de5-b470-2eb40d819dd1@suse.com> In-Reply-To: <22091019-92ea-4de5-b470-2eb40d819dd1@suse.com> From: Andrew Precious Date: Tue, 1 Sep 2026 15:07:26 +0300 X-Gm-Features: AcwNN1VdrC4l3ob9NTTImsBJPzmtP5J40m9j3_bpLKuCABpc8aoDBlS-3N4StVA Message-ID: Subject: Re: [PATCH] stubdom: Fix GCC 14 -Wmemset-elt-size compiler warnings in PolarSSL To: Jan Beulich Cc: jgross@suse.com, samuel.thibault@ens-lyon.org, xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d00357065a6ac394" X-purgate-ID: tlsNG-33051d/1788264462-6FEC24E9-62B77182/0/0 X-purgate-type: clean X-purgate-size: 6524 --000000000000d00357065a6ac394 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was at first deliberating whether to send further patches because the current successor of PolarSSL is MbedTLS. Polarssl is now legacy & not maintained(polarssl was acquired by ARM). Options: 1. Continual patching/maintaining a legacy library. 2. Upgrade to MbedTLS which will require alot of API changes. On Wed, Aug 26, 2026 at 9:33=E2=80=AFAM Jan Beulich wro= te: > On 25.08.2026 20:46, Andrew Mbugua wrote: > > When compiling Xen with GCC 14, I get a compiler warning originating > from the /polarssl-x86_64/library about a memset element size mismatch: > > > > ssl_tls.c: In function =E2=80=98ssl_session_reset=E2=80=99: > > ssl_tls.c:1778:5: warning: =E2=80=98memset=E2=80=99 used with length eq= ual to number of > elements without multiplication by element size [-Wmemset-elt-size] > > 1778 | memset( ssl->ctx_enc, 0, 128 ); > > | ^~~~~~ > > ssl_tls.c:1779:5: warning: =E2=80=98memset=E2=80=99 used with length eq= ual to number of > elements without multiplication by element size [-Wmemset-elt-size] > > 1779 | memset( ssl->ctx_dec, 0, 128 ); > > | ^~~~~~ > > > > This patch introduces a build-time patch to PolarSSL that replaces the > hardcoded 128 byte length with a dynamic sizeof(), thus allowing clean > compilation without warnings. > > First a formal note: Commit messages want limiting to 75 characters per > line (some even say 72). > > Then: You introduce a patch which isn't used anywhere. What use is such > a patch? You also ... > > > Signed-off-by: Andrew Mbugua > > --- > > stubdom/patches/polarssl-gcc14-memset.patch | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > create mode 100644 stubdom/patches/polarssl-gcc14-memset.patch > > ... introduce it in a new patches/ subdir, when all other patches live > right beneath stubdom/. > > > --- /dev/null > > +++ b/stubdom/patches/polarssl-gcc14-memset.patch > > @@ -0,0 +1,13 @@ > > +--- a/library/ssl_tls.c > > ++++ b/library/ssl_tls.c > > +@@ -1775,8 +1775,8 @@ > > + memset( ssl->iv_dec, 0, 16 ); > > + memset( ssl->mac_enc, 0, 32 ); > > + memset( ssl->mac_dec, 0, 32 ); > > +- memset( ssl->ctx_enc, 0, 128 ); > > +- memset( ssl->ctx_dec, 0, 128 ); > > ++ memset( ssl->ctx_enc, 0, sizeof( *ssl->ctx_enc) ); > > ++ memset( ssl->ctx_dec, 0, sizeof( *ssl->ctx_dec) ); > > Don't you mean sizeof(ssl->ctx_enc) and sizeof(ssl->ctx_dec) respectively= ? > Otherwise it looks like you're making a bad situation worse. > > Judging from surrounding style, there also looks to be a blank missing > each, > ahead of the new inner closing parenthesis. > > Jan > --000000000000d00357065a6ac394 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was at first deliberating whether to send further patche= s because the current successor of PolarSSL is MbedTLS. Polarssl is now leg= acy & not maintained(polarssl was acquired by ARM).
Options:
1. C= ontinual patching/maintaining a legacy library.
2. Upgrade to MbedTLS wh= ich will require alot of API changes.

On Wed, Aug = 26, 2026 at 9:33=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wrote:
On 25.08.2026 20:46, Andrew Mbugua wrote:
> When compiling Xen with GCC 14, I get a compiler warning originating f= rom the /polarssl-x86_64/library about a memset element size mismatch:
>
> ssl_tls.c: In function =E2=80=98ssl_session_reset=E2=80=99:
> ssl_tls.c:1778:5: warning: =E2=80=98memset=E2=80=99 used with length e= qual to number of elements without multiplication by element size [-Wmemset= -elt-size]
> 1778 |=C2=A0 =C2=A0 =C2=A0memset( ssl->ctx_enc, 0, 128 );
> |=C2=A0 =C2=A0 =C2=A0^~~~~~
> ssl_tls.c:1779:5: warning: =E2=80=98memset=E2=80=99 used with length e= qual to number of elements without multiplication by element size [-Wmemset= -elt-size]
> 1779 |=C2=A0 =C2=A0 =C2=A0memset( ssl->ctx_dec, 0, 128 );
> |=C2=A0 =C2=A0 =C2=A0^~~~~~
>
> This patch introduces a build-time patch to PolarSSL that replaces the= hardcoded 128 byte length with a dynamic sizeof(), thus allowing clean com= pilation without warnings.

First a formal note: Commit messages want limiting to 75 characters per
line (some even say 72).

Then: You introduce a patch which isn't used anywhere. What use is such=
a patch? You also ...

> Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
> ---
>=C2=A0 stubdom/patches/polarssl-gcc14-memset.patch | 13 +++++++++++++ >=C2=A0 1 file changed, 13 insertions(+)
>=C2=A0 create mode 100644 stubdom/patches/polarssl-gcc14-memset.patch
... introduce it in a new patches/ subdir, when all other patches live
right beneath stubdom/.

> --- /dev/null
> +++ b/stubdom/patches/polarssl-gcc14-memset.patch
> @@ -0,0 +1,13 @@
> +--- a/library/ssl_tls.c
> ++++ b/library/ssl_tls.c
> +@@ -1775,8 +1775,8 @@
> +=C2=A0 =C2=A0 =C2=A0memset( ssl->iv_dec, 0, 16 );
> +=C2=A0 =C2=A0 =C2=A0memset( ssl->mac_enc, 0, 32 );
> +=C2=A0 =C2=A0 =C2=A0memset( ssl->mac_dec, 0, 32 );
> +-=C2=A0 =C2=A0 memset( ssl->ctx_enc, 0, 128 );
> +-=C2=A0 =C2=A0 memset( ssl->ctx_dec, 0, 128 );
> ++=C2=A0 =C2=A0 memset( ssl->ctx_enc, 0, sizeof( *ssl->ctx_enc) = );
> ++=C2=A0 =C2=A0 memset( ssl->ctx_dec, 0, sizeof( *ssl->ctx_dec) = );

Don't you mean sizeof(ssl->ctx_enc) and sizeof(ssl->ctx_dec) resp= ectively?
Otherwise it looks like you're making a bad situation worse.

Judging from surrounding style, there also looks to be a blank missing each= ,
ahead of the new inner closing parenthesis.

Jan
--000000000000d00357065a6ac394-- From xen-devel-bounces@lists.xenproject.org Tue Sep 01 13:17:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 13:17:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404756.1638436 (Exim 4.92) (envelope-from ) id 1x1OML-0002jC-Na; Tue, 01 Sep 2026 13:17:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404756.1638436; Tue, 01 Sep 2026 13:17:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1OML-0002j5-Ka; Tue, 01 Sep 2026 13:17:05 +0000 Received: by outflank-mailman (input) for mailman id 1404756; Tue, 01 Sep 2026 13:17:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1OMJ-0002iz-TJ for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 13:17:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1OMH-008Opx-Tr for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 15:17:01 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96d048-8faa-0a2a0a5109dd-0a2a450cc086-14 for ; Tue, 01 Sep 2026 15:17:01 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96d04d-f479-0a2a450c0019-d155802cc9d3-3 for ; Tue, 01 Sep 2026 15:17:01 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49ccfbe062eso25308395e9.3 for ; Tue, 01 Sep 2026 06:17:01 -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-49cdce1a3fesm70718595e9.12.2026.09.01.06.16.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 06:17:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788268621; x=1788873421; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=UHcJZ7qe8EHcanx4NmTqt9bQxkl+VRDPvbq2agGEMR4=; b=SKrh5Xn0Y76UTgnH+RqvvXGSm/i49pQsfOSx6OH6BfTXNQvgypCxKGu4uslUPERI7q XpNHyWn3AMdByURzOLlZYs7oZdR8rJO4b5Blz9Nvp0UP1aecydWb3qTAQ1L/frb28rqE HnSZUjLrwJsYTqgkhtWycZ7x2Tc3K7Vfsn+GBari9U+UTXq6qDKI0rZ6di7lf5JXaKcT g1NCRaeE4UY02Ud8G6bhAw9sfEsG3GjpUk3k1nvLiC8iW46pFMS01v9YoBjXIVgKkpc9 E0u+I+CRcrw8ykJNi+DlEQ1Vs4yFHFIDkbqVBnU6rI9Bs0dCs0mTaRE0UgSafxkpPnp2 M1TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788268621; x=1788873421; h=content-transfer-encoding:content-type: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:content-type; bh=UHcJZ7qe8EHcanx4NmTqt9bQxkl+VRDPvbq2agGEMR4=; b=ptUbHRMoNeeSuIHfa00NWFwPYTsYWw40gRtj7nWuJ5FMDliDf1SfxjLRshRD7omkQG mDhfeeFxdcK65jYt1ZbWWstVi686M2OEd3byEkkF1De2137KdrLpYDtQgODzYR6tefBL OcGxiroTOV+97AfO+ILNLhdurDcdunUjfec1suxQk+EmgdaZfEKmbVeWyOkKZ/0PkO9A mKwiTrUg77H/U1TMigSUm4y8lzEt/eb+wIDNbRIMichFd8nhv8miVoHpwVj4Kq/n0xWL kfqiOK1LCVGa6mKZ9wBFN0F74DESYQH2j8TJOzlIcF21XbwFKIibVMJRVsE0WeVSWAfC IRNg== X-Forwarded-Encrypted: i=1; AHgh+RrqWcAGzwdZlQ1BMqgAEKJcm4KqzM7ylO2bTsSxtzyrUPHJpGLbCeD3YrFTsxBoIjmnzEqFpAD0+iA=@lists.xenproject.org X-Gm-Message-State: AFuF++kQqRlzhDfyPNul+tzs2Vl32P6dT3nRD8bzTkj2qXPJ61mwngS3 WMLzWw1+Eld2ebCr8OWybeGo99BxGSmfsF/V/VFH1v4NEqIoGK7J4Kpu/q58tlm64g== X-Gm-Gg: AR+sD129ISSRWTpaPHI5dqmx6l7oNNcr7JBPLIaG4AJ9sGeB4GsUPe51vd1Az5R7ekV KGiRN/JB59kYSm1Sl9ZdkDYlU9GUz7Zh8i/8lFrJrysB24X/tP3jRS06EJlOoPdyCm0+q4p7rMJ 1Z/kCkKUt/b71Gdmdp9q+SMa1ol51p8zQVr1JKo/6KVrIfZh95wguRgUn0gu6Bm/Vf/mLK6M4wk qoaLceuCULhq6VobNHx0+KFK85iSMW61XO1AcQFsDCfvgxFcbozP0vxdQlnS1urkUV2DQY+8/Gj kYmyB5ocyGaVLxM1aDEk61YTa3bV/zkwfQAeBuci2x4Aht4kPngSyl8pe3vovthNP34Z2Hn/wS9 Ztblp3L5OiAkliAzBr8PCaXuFc3oA0MJrPmPEisuAgA202Xe1eheonTvefIvCIqmHL1/QRUlgl8 J0Tro+zUl1ChRzDnShM92zSvEHW9dJM7pLl4QRdrakNYBFjGJjjRS+WXSXHurfftNiFbF4j7rql PLL2kFBniUtbyXzp0vBiiGuPFoiYjezzPT0wzPTQh8hckHos9r6 X-Received: by 2002:a05:600c:8b86:b0:493:f5bf:4dc6 with SMTP id 5b1f17b1804b1-49b91c2777emr603425715e9.7.1788268621206; Tue, 01 Sep 2026 06:17:01 -0700 (PDT) Message-ID: <16110ecc-fc0d-4b9d-a958-2a75ca60b69f@suse.com> Date: Tue, 1 Sep 2026 15:16:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() To: Mauricio Faria de Oliveira Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Brian Gerst References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.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: <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788268621-038D5A5B-96896E42/0/0 X-purgate-type: clean X-purgate-size: 1894 On 22.08.2026 20:33, Mauricio Faria de Oliveira wrote: > According to the GCC documentation, conditions in the flags register > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2]. > > Also, clobbers (e.g., "cc") may not overlap with an output operand [2]. > > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the > "=@ccnz" output operand. > > """ > 6.11.2.4 Flag Output Operands > > On some targets, a special form of output operand exists by which > conditions in the flags register may be outputs of the asm. [...] > > 6.11.2.6 Clobbers and Scratch Registers > > While the compiler is aware of changes to entries listed in the > output operands, [...] > > Clobber descriptions may not in any way overlap with an input or > output operand. [...] > """ > > Reported-by: "H. Peter Anvin" > Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/ > Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()") > Signed-off-by: Mauricio Faria de Oliveira > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands [1] > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 [2] Reviewed-by: Jan Beulich > --- a/arch/x86/boot/string.c > +++ b/arch/x86/boot/string.c > @@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len) > asm volatile("test %3, %3\n\t" > "repe cmpsb" > : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) > - : : "cc", "memory"); > + : : "memory"); In fact I'm using a modified gcc which properly rejects such conflicting uses of output and clobber. ("cc" clobbers are redundant on x86 anyway.) Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 15:17:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 15:17:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404786.1638444 (Exim 4.92) (envelope-from ) id 1x1QET-00049s-Te; Tue, 01 Sep 2026 15:17:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404786.1638444; Tue, 01 Sep 2026 15:17:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QET-00049l-R2; Tue, 01 Sep 2026 15:17:05 +0000 Received: by outflank-mailman (input) for mailman id 1404786; Tue, 01 Sep 2026 15:17:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QES-00049f-E6 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 15:17:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1QER-008eKZ-0y for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 17:17:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96ec5b-8faa-0a2a0a5109dd-0a2a4504aca0-46 for ; Tue, 01 Sep 2026 17:17:00 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96ec6b-b57f-0a2a45040019-d1558029e9fd-3 for ; Tue, 01 Sep 2026 17:17:00 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49cd77e0f95so11569725e9.3 for ; Tue, 01 Sep 2026 08:16:59 -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-49cdce10148sm71927545e9.5.2026.09.01.08.16.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 08:16:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788275819; x=1788880619; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Z3R+wRO++3lXh4fSwhf+1+RYEKwgen0aRJh0hWM/0A8=; b=T6U+VAIFtLKHAhQXVENgRphnQ3E28K34ZaFHEvg7s4tzuFezTbFbETWi7AW5LFm/t0 PpVtFzLuoPhVoMkzbk5JXPs5cSGa9m965rKDM3P0rRMm2codpfTF39QGKTqoDZJz6Cb8 hMeeRYl5n5wP+IXpCDxrGphg7QfqXIoJvwBoeKl0QQwc4gnT0AA+IafhSUlrDjODAhB8 qUKc71xyNZq9eY1SVe9byMnMlpsor5PQ9slTXOoQCPBZjMaN5SUhz5Ke59ZfLe+QVul5 G+Q7SIodg8G+hUeMqLVemnEsZO+r+v4OsbCiqr3f2pdoicOF+Lh2Iv9x9J3d9lYejEVA 79Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788275819; x=1788880619; h=content-transfer-encoding:content-type: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:content-type; bh=Z3R+wRO++3lXh4fSwhf+1+RYEKwgen0aRJh0hWM/0A8=; b=cHisTisrPK3aWpr/uLCUPrKTL6HVdh09QQT5rz3T77hnOmsEwGcZ1FyWYiLbtDErGF hiWo8CxIPKRqJeOlezZXFeGcIAwSz8hMQZygixv4OH76zYAb2QY/dqhUZWpvst+z1dLL jFNGDM7j9mlzlkKCgflnpAFGOnwd8kj3rDwKiOs1PINqkJTDxoC/aYFrWxrSqT7hWbZK La4sskTIygT7yBru6YLknRNmmsYedOGTZz7ai8YLAi4ULxRNu8v+fHlfY19TbnS+lBXv FVA+Y/T9Rxn/28/RCtXZoXWx1Cx/QwmvnCGLVGBO/1nN523E5ZWZzzzOJZ/3E5hC7tCb BM2Q== X-Gm-Message-State: AFuF++lYJAKCLf48XYtC7V3Zm/veZVsfgmcqbdQqrcFK02v9dd6jK97F mi9M+LluWuq0A7Ilj1q1NFFypMyXxLYe8qgTUCWCXVRtendUKXHg5voW4hvtX/FZwA== X-Gm-Gg: AR+sD13VFCad9umMOZocsWDO+04NxFjoRF2CogUpWQAGNixLVsdhnxE1MYcDRi4IUGc ebrJfjep7dmCCJGr3MFK1xO67mT4CbVv7NInii3sSw3+Br0IbdSN1nb8pOxD/R1TmyqsdWvVRHq WD0EuZ2WOwE67YCbEvaMAYecUZecXgo++mCtJhGkUpoX0Qzs/WwKdnVY7oXtqKKolUI/NXvuaaR D3/tu3XmbQyHBlxRxzF8eLzpXQBO/AG80AsF1Wr7lj/Zj+6Vpz6p6rPbgmhWjbX13FxbCDK9M7d j7UxjJuoPOlf1NUiWw+IET2DgJySZSMMs3Mc1CUlF+Oi8U5VisTEZ5bnj37gDl9GUw2rSvw8/YX fwIXLENvqmnSYhqENYUkkvWcMa5NuSN1VeBq7dbYS1uD+bHVbyQkBt1dVxqtiP3mfsZU2N5YDf+ 6eIUFSU6MuBlUSnttYbS1JB2JB7wSLWSNGlJbBhqa8zsmm8HXE2AJstsEDsmuBkrcX5RRFe4h+1 i7C7YBrgphQHDAjzlwa4+a6t7NRI7YMTfIUqh+f5UO2NS1aIvG2 X-Received: by 2002:a05:600c:5288:b0:499:84fe:5f3e with SMTP id 5b1f17b1804b1-49b91c41014mr614024015e9.9.1788275819388; Tue, 01 Sep 2026 08:16:59 -0700 (PDT) Message-ID: <4cc36c5e-a932-49b9-9e0c-ab8c0dc44e79@suse.com> Date: Tue, 1 Sep 2026 17:16:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Baptiste Le Duc , Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@vates.tech> 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: <1788180504.8631fc262581453bbf619ec5b2062170.1a057dd1f6a000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788275820-C12DCB50-FF03BF5A/0/0 X-purgate-type: clean X-purgate-size: 1118 On 31.08.2026 14:48, Baptiste Le Duc wrote: >> hstatus.VSXL is WARL, so its reset value is implementation-defined. Xen >> supports 64-bit guests only, so program it explicitly instead of relying >> on whatever the hardware happens to leave there. >> >> This matters beyond the guest's own view of itself: decoding a trapped >> instruction depends on the effective XLEN of the guest, as the encodings >> which exist for XLEN=64 only must not be recognized for a 32-bit one. >> > It's not clear which instruction "decoding a trapped instruction" refers > to without more context. Use "decoding of trapped instructions" instead? (I think I'd prefer the paragraph to remain here.) Jan > I assume you mean decode_ldst_insn() in > emulate.c, but the patch introducing that function comes later in the > series, so this isn't obvious on a first read. > > Please reorder the series so this patch follows the one introducing > decode_ldst_insn(), or reference it explicitly in the commit message > (e.g. "load/store trap emulation, introduced later in this series in > emulate.c, needs..."). > From xen-devel-bounces@lists.xenproject.org Tue Sep 01 15:20:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 15:20:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404796.1638454 (Exim 4.92) (envelope-from ) id 1x1QHj-0005pT-Ev; Tue, 01 Sep 2026 15:20:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404796.1638454; Tue, 01 Sep 2026 15:20:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QHj-0005pM-C4; Tue, 01 Sep 2026 15:20:27 +0000 Received: by outflank-mailman (input) for mailman id 1404796; Tue, 01 Sep 2026 15:20:26 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QHi-0005pG-3U for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 15:20:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1QHh-001HAa-GO for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 17:20:25 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96ed2f-e002-0a2a0a5209dd-0a2a4507bd2e-14 for ; Tue, 01 Sep 2026 17:20:25 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96ed30-b4ea-0a2a45070019-d155802dc16c-3 for ; Tue, 01 Sep 2026 17:20:16 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49b8687630fso35947465e9.3 for ; Tue, 01 Sep 2026 08:20:16 -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-49b9266be71sm782856105e9.2.2026.09.01.08.20.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 08:20:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788276016; x=1788880816; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=AP6ZxMTqU9edZIO7td9qL48Pd2+OlvlwdQotPq61V3Q=; b=G5v8iAEUtKkHACWBQ5urHlUnrUDzavpoS81MY8hkOy6SLSPUDFirMKHRJ2s82J4jQv xmtx8pY/gUmCIiNsM+IF54wfRi3FY5HaAAPiwdRTj2xj6N56CACJHeUkbfVLR5OlPVly 9t8AYfkveSjUHWwh6beywqcFP1vkKEt8F01iE21OzOIjRGQ1GzUoKOdllBzOSI72wU4Y mcOshy1ETUZQuYkveCOeo1xsgrhtANPXfz1rKnVN4cv5UHFbIU5Mn/Lyvuh4AzIM6PrY CvNavj+UGfaRrVzZSf0ph/3HVcbz/XYKg3lPQKNLGbAIjiwCbgVjD9vjb+CnBc0sKerB Qrrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788276016; x=1788880816; h=content-transfer-encoding:content-type: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:content-type; bh=AP6ZxMTqU9edZIO7td9qL48Pd2+OlvlwdQotPq61V3Q=; b=qtPDT/v2xJOH9JVH9HzdWhUPVqIRnrxIeUZL7QkM4+lkCP+CWe4wtMn5HfS5RuU1Zc AxuVSyrEBxHMQgotKB4OddZ6g7fO2I85BZIrWarhuMXS4XwSzQRVa2ucMuZ1tGCClCRb yX0+dC1K3N2tTrwCJWHrhlYIZBHwCJXXbfUw/OcGX4FzQinuE0e55FBOiBGvOOrkxtEo NfNc+si9dDL94K3x6ufRdeQbx1tzjABg5wBEv5MQWV+MrfqXoYU5qIi+7cuPOjKtgzN+ I0TUtYg1AKLGGPWS/sNyRBUf9sOu4L9WZY0TJSyNsCaZ5FOUzd8ZYrn6/acBAl4yatkK p3wg== X-Forwarded-Encrypted: i=1; AHgh+RreVTpz6BDDC9S8s3ADYhbKvmVa/Cw7jug6KTrimmYyVjRGqjos4W2rOyBnSKDQR/SGWKQRGBkbnxc=@lists.xenproject.org X-Gm-Message-State: AFuF++lFSb3gSp78EbogHD4cK+BskggIhN9XX3DYlqtAjSPVics601Ao NiOX5RDYP40w9Y/0S7zjhjEfG1LtmTj14DbQtMMA4z2fbIy+0ZQY9sYvy8WMiKQ81g== X-Gm-Gg: AR+sD13TW2abkVs4my43xmsrcicxgpCndzPYLU6xL6wb5hvgrz5C9P4W6DO0DpzaIp/ apjDNue04oEAgN1nv7ssIk7XLSqo8BrfKAu0sUpuRg8EJKKT2MIZCw5Ub3kJUhLQ0myBIh5o/7R Y9yqWs9MAEAueby6giQ1Ly+uHm8sQpOpjf16suGdZnVdTh9jbV0jedTH5QXW4Trie/xDOnStKEk Zzxu1Af+5g1XmuDRZv7eFedCsTchCYnal6pBi2/s1Li1x0mPB5b1y1vSiY76PnCo0aQiCkTUDd5 oaTiwKBXY0cXiok7agjXmUNJJWgWg/W3UTWKL+Xdy+4dIoV2zVYTosTLa84FuCs/00eAAz5w51z 3i03qcoMcn+6DnW+uUZwxwKPZtuVvw6ocofAj8MCXDTY9rg4N9zbtv1nDtmm6zJdyUhROToIDZu Hyo4LZfSA0gJbNHLZxsvLXLv6UBaQcSHFlBgviSyJ/svKoegTNpUmu8wHQFR2bWmIAzmkEFMDR2 cDxTMgKDHymEfY8bIqLEkxAt9xyidXyxULHQbV/KWbQjUBgPQIm X-Received: by 2002:a05:600c:c113:b0:497:fecd:5b00 with SMTP id 5b1f17b1804b1-49cdc435d58mr163998555e9.9.1788276015620; Tue, 01 Sep 2026 08:20:15 -0700 (PDT) Message-ID: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> Date: Tue, 1 Sep 2026 17:20:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-ef75cf/1788276016-34ECEAE4-CF75FF1D/0/0 X-purgate-type: clean X-purgate-size: 1368 On 27.08.2026 17:20, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -88,7 +88,13 @@ static void vcpu_csr_init(struct vcpu *v) > { > v->arch.hedeleg = HEDELEG_DEFAULT & csr_masks.hedeleg; > > - vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; > + /* > + * Xen supports 64-bit guests only, so set the guest's XLEN explicitly > + * rather than leaving it to the WARL behaviour of hstatus.VSXL, which the > + * decoding of a trapped instruction depends on. > + */ > + vcpu_guest_cpu_user_regs(v)->hstatus = > + HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(HSTATUS_VSXL_64, HSTATUS_VSXL); The comment is correct right now, but the situation better would change at some point. Can't you arrange for things to be correct here also for a future where 32- and 128-bit guests would also be supported? > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -68,6 +68,8 @@ > #if __riscv_xlen == 64 > #define HSTATUS_VSXL _UL(0x300000000) > #define HSTATUS_VSXL_SHIFT 32 > +#define HSTATUS_VSXL_64 _UL(2) > +#define HSTATUS_VSXL_32 _UL(1) > #endif While adding the two #define-s, would you mind considering to remove the unused (and supposed to remain so) HSTATUS_VSXL_SHIFT? Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 15:36:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 15:36:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404806.1638463 (Exim 4.92) (envelope-from ) id 1x1QWz-0007k9-NS; Tue, 01 Sep 2026 15:36:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404806.1638463; Tue, 01 Sep 2026 15:36:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QWz-0007k2-K7; Tue, 01 Sep 2026 15:36:13 +0000 Received: by outflank-mailman (input) for mailman id 1404806; Tue, 01 Sep 2026 15:36:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1QWz-0007jw-3E for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 15:36:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1QWy-001JKi-4V for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 17:36:12 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96f0d4-8faa-0a2a0a5109dd-0a2a450a9d7a-36 for ; Tue, 01 Sep 2026 17:36:11 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96f0eb-f2d2-0a2a450a0019-b9ff1c2283f9-3 for ; Tue, 01 Sep 2026 17:36:11 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a05d9d0d1d000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 01 Sep 2026 15:36:08 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id F27F783D14; Tue, 1 Sep 2026 17:36:07 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=jIYE1T6q6tRfGV5ARdEy2WRajQqMbeqlY4SEFHl62V8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=ZUTwLzYSqgtreAQeM3KZDA5TY3040XF/WfuFW/gfi1LZ/IO8bZuiQncYKapu/4+yNN3mIXy/5 5r8SnzphV1qN4JtvN5Zp5AISTGQZj4FLm3+pLGQA5eFtfr6nOLzl754gRl6XJs7ykAXb48nIB1b c25740EeHBadRrKN2FbXu7MDjI3uxrnY94n2RU3MjbvgBVJrbNbuWXLGjw+xns5tiwBWgamEJGX KLPFhanNJUyDxFSyEcX651yjwLNnKd095nBULjdDbW2IIrUyMPnDUj95i7+CQkjpR0x7/xKIHH3 chFW6VPfVAYVC0r7v9OqnMNT7wZOPvqdzvO8qUUE/RKQ== X-Zone-Loop: ff6c067449f603021a2de3d0b7dc7695049b272be0c8 x-campaign-type: default x-transaction-id: 1734222b-2101-4f30-9cd7-5c59bbfe0ba2 x-swg-uid: 01-cd44ca4e-d9bc-42f0-821b-bf2e69ba9a2f X-Mailer: Sweego Message-ID: <1788276968.8631fc262581453bbf619ec5b2062170.1a05d9d0d1d000c4f3@vates.tech> x-swg-bid: 1788276968.8631fc262581453bbf619ec5b2062170.1a05d9d0d1d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 07/39] xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Tue, 01 Sep 2026 17:36:01 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788276967; l=751; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=3bdn2DGU0nTeAfG1q/uUH5AqAOJYJQulCjTHSpOz+v8=; b=xd7lT11wWkYeIJ7AhaFsUsGcz6V1A4fPubbk+LS7teMMoVV6kzc5btS38mSmBI2mPTJ6Y8k2p 9l5Khb3xesTAVoT5uBWNUeBOOt5PQHG1f8M/Afd6yTUmr6iZAvDtpWe X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788276968198 X-purgate-ID: tlsNG-4011c0/1788276971-4B6D6CFC-D6089A41/10/73395122804 X-purgate-type: spam X-purgate-size: 751 On Thu, 27 Aug 2026 17:20:51 +0200, Oleksii Kurochko wrote: > These definitions are required for correct decoding of APLIC MMIO > accesses and target configuration, and will be used by both the > physical and virtual APLIC implementations. > > While adding them, rearrange the header in the style of x86's > asm/msr-index.h: a register's offset is immediately followed by the > definitions of that register's fields, with the blocks sorted by > offset. This makes the relation between a register and its fields > obvious from the layout alone, so no comment is needed to express it. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Sep 01 15:36:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 15:36:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404807.1638471 (Exim 4.92) (envelope-from ) id 1x1QX5-0007xH-Sw; Tue, 01 Sep 2026 15:36:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404807.1638471; Tue, 01 Sep 2026 15:36:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QX5-0007xA-QE; Tue, 01 Sep 2026 15:36:19 +0000 Received: by outflank-mailman (input) for mailman id 1404807; Tue, 01 Sep 2026 15:36:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1QX4-0007wx-OP for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 15:36:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1QX4-004MtB-4C for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 17:36:18 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96f0e8-bab6-0a2a0a5309dd-0a2a450b8b1c-18 for ; Tue, 01 Sep 2026 17:36:18 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96f0f1-b7e8-0a2a450b0019-b9ff1c128d75-3 for ; Tue, 01 Sep 2026 17:36:18 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a05d9d0e85000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 01 Sep 2026 15:36:09 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 520D283D4D; Tue, 1 Sep 2026 17:36:08 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=+nkYcL2VZ0h4H8BaaEIV2R9AqnQKCo3UZXrnidMYJcQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=uBcCexC4gO+NSXfGdzer3oPCUCpCgYcIWVMFS/8LcCm0udVRss3IrGs0MJqoT6nzlEQWL0uAa kSxJ+HfKyqJfo6upqM3ngX/u7JnerTSvr6yhwam2BYVZY3eqM/v7+Lqla9580UWlOJOX9L8P3B3 WEnQkkDjYagKVl6K73KG5lSVejba/9VRYn+5gxQqGXIyofK6vtjqPgLx03/Qxn/fQlg2I9zq4Qg vH1lcB3xHtZgCnEHiYdtvMWXIBKmZ+3EN9Kb86fzI4Zd25E+7IaQFCFW84z15GcanYECyAyCYfP QhpEOYxrf79+XvhOrkk/nmMG8Azf2I5oBFpUVGB4qrDQ== X-Zone-Loop: 9af3bc120ed1fb46a2ad133be28d61b0166f49c0d44d x-campaign-type: default x-transaction-id: 8ed672a8-1281-4b5a-a233-c6e942a1fb4e x-swg-uid: 01-ab0e654b-3c96-42c0-a914-ade1c077ef15 X-Mailer: Sweego Message-ID: <1788276969.8631fc262581453bbf619ec5b2062170.1a05d9d0e85000c4f3@vates.tech> x-swg-bid: 1788276969.8631fc262581453bbf619ec5b2062170.1a05d9d0e85000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 08/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Tue, 01 Sep 2026 17:36:01 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788276967; l=8672; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ih1vpbwXalYF59KB5ERVxms5sfakxHyR6Sqpt6uKN1k=; b=GhK5Yfau2vKxZNJOBYo20zhtNhl9+7mjYNwE++qND2bVdOEtZjGFZUOVxGnOVSo3pWuWTMZ/O x5woF4Wt7GAA5UNDASSvaXKOWZ4CEjmO9QyC8a5RbxwjlR8dUpRh/6h X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788276968547 X-purgate-ID: tlsNG-42698a/1788276978-AB8D19EA-0EF62459/10/73395122804 X-purgate-type: spam X-purgate-size: 8672 > RISC-V guests can expose several virtual interrupt controllers at > distinct GPA ranges: vPLIC (hasn't been introduced yet) for legacy machines, > vAPLIC and vIMSIC for AIA-compliant ones (are being introduced in the follow > up patches). As Jan said here [1], we shouldn't use "as later in this series" in commit message... [1]: https://lore.kernel.org/xen-devel/cover.1787838835.git.oleksii.kurochko@gmail.com/T/#m56fbac1ceb0642d5d868e9dcb2b5ed93ecbe5058 > Routing MMIO faults via a per-device is_access() check in the > trap handler would couple it to every device it must serve, requiring a > new conditional branch in the fault path each time a new emulated device is > added. > > Introduce a per-domain MMIO handler registration table, modeled > after the equivalent ARM framework, so that virtual devices > self-register their GPA ranges and read/write callbacks at domain > creation time. The MMIO fault path delegates to a single > try_handle_mmio() entry point and remains agnostic of which device > owns a particular address. > > A subsequent patch wires this into the MMIO fault path in traps.c. ...same here > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile > index 3b948c11dd..ce6410a299 100644 > --- a/xen/arch/riscv/Makefile > +++ b/xen/arch/riscv/Makefile > @@ -14,6 +14,7 @@ obj-y += intc.o > obj-y += irq.o > obj-y += kernel.init.o > obj-y += mm.o > +obj-y += mmio.o > obj-y += p2m.o > obj-y += paging.o > obj-y += pt.o > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index 57c37cb2df..ec327a5e8a 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -316,6 +317,8 @@ int arch_domain_create(struct domain *d, > if ( (rc = p2m_init(d, config)) != 0) > goto fail; > > + domain_io_init(d); > + > if ( (rc = domain_vintc_init(d)) ) > goto fail; > > diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h > index e035b33ddf..15e8fa1968 100644 > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -9,6 +9,7 @@ > > #include > #include > +#include > #include > #include > > @@ -101,6 +102,8 @@ struct arch_domain { > const unsigned long *isa; > > struct vintc *vintc; > + > + struct vmmio vmmio; > }; > > #include > diff --git a/xen/arch/riscv/include/asm/mmio.h b/xen/arch/riscv/include/asm/mmio.h > new file mode 100644 > index 0000000000..582969e535 > --- /dev/null > +++ b/xen/arch/riscv/include/asm/mmio.h > @@ -0,0 +1,63 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +#ifndef RISCV_MMIO_H > +#define RISCV_MMIO_H > + > +#include > +#include > + > +struct domain; > +struct vcpu; > + > +#define MAX_IO_HANDLER 16 > + > +typedef struct { > + paddr_t gpa; > + unsigned int len; /* access width in bytes (1, 2, 4, 8) */ > + bool is_write; > + /* store: value to write; load: value read (set by handler) */ > + register_t data; > +} mmio_info_t; > + > +enum io_state > +{ > + IO_ABORT, /* The IO was handled and led to an abort. */ > + IO_HANDLED, /* The IO was successfully handled. */ > + IO_UNHANDLED, /* No handler found for the IO. */ > +}; > + > +typedef enum io_state (mmio_read_t)(struct vcpu *v, mmio_info_t *info); > +typedef enum io_state (mmio_write_t)(struct vcpu *v, const mmio_info_t *info); > + > +struct mmio_handler_ops { > + mmio_read_t *read; > + mmio_write_t *write; > +}; > + > +struct mmio_handler { > + paddr_t addr; > + paddr_t size; > + const struct mmio_handler_ops *ops; > +}; > + > +struct vmmio { > + unsigned int num_entries; > + rwlock_t lock; > + struct mmio_handler handlers[MAX_IO_HANDLER]; > +}; > + > +int do_mmio(mmio_info_t *info, paddr_t fault_addr, unsigned int len); > +int register_mmio_handler(struct domain *d, > + const struct mmio_handler_ops *ops, > + paddr_t addr, paddr_t size); > +void domain_io_init(struct domain *d); > + > +#endif /* RISCV_MMIO_H */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/riscv/mmio.c b/xen/arch/riscv/mmio.c > new file mode 100644 > index 0000000000..d241ab5ea1 > --- /dev/null > +++ b/xen/arch/riscv/mmio.c > @@ -0,0 +1,176 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +/* > + * bsearch() comparator: @key holds the address to look up in its addr field, > + * @elem is an entry of vmmio->handlers. Relies on the regions not > + * overlapping, which register_mmio_handler() enforces. > + */ > +static int cmp_mmio_handler(const void *key, const void *elem) > +{ > + const struct mmio_handler *handler0 = key; > + const struct mmio_handler *handler1 = elem; > + > + if ( handler0->addr < handler1->addr ) > + return -1; > + > + if ( handler0->addr >= (handler1->addr + handler1->size) ) > + return 1; > + > + return 0; > +} > + > +/* > + * Return a copy of the matching handler rather than a pointer into > + * vmmio->handlers: a concurrent register_mmio_handler() shifts entries > + * up to keep the array sorted, so an escaped pointer could refer to a > + * different (or torn) entry once the lock is dropped. The copy stays > + * valid as the ops structures are never freed. > + */ > +static bool find_mmio_handler(struct domain *d, paddr_t gpa, > + struct mmio_handler *out) > +{ > + struct vmmio *vmmio = &d->arch.vmmio; > + struct mmio_handler key = { .addr = gpa }; > + const struct mmio_handler *handler; > + > + read_lock(&vmmio->lock); > + handler = bsearch(&key, vmmio->handlers, vmmio->num_entries, > + sizeof(*handler), cmp_mmio_handler); > + if ( handler ) > + *out = *handler; > + read_unlock(&vmmio->lock); > + > + return handler != NULL; > +} > + > +static enum io_state try_handle_mmio(mmio_info_t *info) > +{ > + struct vcpu *v = current; > + struct mmio_handler handler = {}; > + > + if ( !find_mmio_handler(v->domain, info->gpa, &handler) ) > + return IO_UNHANDLED; > + > + if ( info->is_write ) > + return handler.ops->write(v, info); > + else > + return handler.ops->read(v, info); > +} > + > +/* > + * Check alignment and dispatch a decoded MMIO access to a registered > + * handler. On success (0), info->data holds the read value for loads. > + * > + * There is no "retry" outcome to handle: find_mmio_handler() returns a > + * copy of the matching handler taken under vmmio->lock and the ops > + * structures are never freed, so the lookup result cannot go stale > + * between finding the handler and invoking it. > + */ > +int do_mmio(mmio_info_t *info, paddr_t fault_addr, unsigned int len) > +{ > + /* Fault address should be aligned to length of MMIO */ > + if ( fault_addr & (len - 1) ) > + return -EIO; > + > + info->gpa = fault_addr; > + info->len = len; > + > + switch ( try_handle_mmio(info) ) > + { > + case IO_HANDLED: > + return 0; > + > + case IO_ABORT: > + return -EIO; > + > + default: > + return -EOPNOTSUPP; > + } > +} > + > +int register_mmio_handler(struct domain *d, > + const struct mmio_handler_ops *ops, > + paddr_t addr, paddr_t size) > +{ > + struct vmmio *vmmio = &d->arch.vmmio; > + struct mmio_handler *handlers = vmmio->handlers; > + paddr_t end = addr + size; > + unsigned int i; > + int rc = 0; > + bool overlap; > + > + if ( !ops || !ops->read || !ops->write || !size || end < addr ) > + return -EINVAL; Just a question: is the aim of end < addr check to handle possible overflow of end? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Sep 01 15:50:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 15:50:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404818.1638482 (Exim 4.92) (envelope-from ) id 1x1Qkw-0002uq-3F; Tue, 01 Sep 2026 15:50:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404818.1638482; Tue, 01 Sep 2026 15:50:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Qkv-0002uj-VP; Tue, 01 Sep 2026 15:50:37 +0000 Received: by outflank-mailman (input) for mailman id 1404818; Tue, 01 Sep 2026 15:50:36 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1Qku-0002ud-CL for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 15:50:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1Qkt-006mSe-56 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 17:50:35 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96f448-bab6-0a2a0a5309dd-0a2a450cd70a-8 for ; Tue, 01 Sep 2026 17:50:35 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96f44a-f479-0a2a450c0019-d155802eadaa-3 for ; Tue, 01 Sep 2026 17:50:35 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49b0dd3c9a0so34536055e9.1 for ; Tue, 01 Sep 2026 08:50:35 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cdce10148sm73933495e9.5.2026.09.01.08.50.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Sep 2026 08:50:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788277834; x=1788882634; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=2jLmcDK1E+Gg/mpM2jH3Fh2/6vWMsyX9FlhdI9FX5Qc=; b=mWeZJkweTGFMldSkLVus5fr0ar7wPHa1FkX2Cs8d3/G1I+wAIB4nzYqqrDCdGGugPj 3KR5UeAqRi9Tz1JQo2aYZKrZu+++U4k5lbCk4h4ZlipKBaK5KqHvMx4AXH6txbmHKC/e O1RUynVDHe0R2EmVaRcJR+SHgBNemb/t6+8Z5kY9OeP4GARfXH9FEv5sM6DoAQUevppK Y9Mbc9npg5F36g+FrlCyjLAVkbXzCWJuEk9m080akxzwWUYDLoPMhmzGlWjvCiUgZ+fE nUDOJRmQNYxJ1EA/Pf1XR/E7ulbPFk6eDhDjjfTM2SXe2mYS4oTqtTI6ZwfDHQ7IURIz OxQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788277834; x=1788882634; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2jLmcDK1E+Gg/mpM2jH3Fh2/6vWMsyX9FlhdI9FX5Qc=; b=FGiSsNfgD6+J+AmGGj3146SN08pvbBZmDNMtUFjMUhPZJkj69pXFa7l5kHRi4ktkSb GguQV0FMQKP/Flh2yp0Mj351eHQf2pOT1LkClcw6oMJEqlJ+VS4gVp0jRApNkyhXfjFD 8d0Gutc95Baxzy0i94DgbXWvOviuKJDnQE0QAQH8bxKJP3ZkvINTX+c9Rankk/bt7/Ss Z4X4m7SEs0rWEtn/q+VDuFdR8dbBw2IM6f/DpKDXsHBUoNV2yPL82jc/8uda6wCV+zfN zKv7RkJOjqFZ0o5iV0zyJ5NEw8Ezj29j25naoNFFpkakuke8VB2g/6bSP+UcHWwfzjrh Br+A== X-Gm-Message-State: AFuF++mZkfU1GGEkVEAnXqT4CJU/phE6qqy56NCU+37FMP+JEHK2lwWM cjdfmCmN1EHarkpGwF6IFKXNANMWUDaLwivP+gLjtyJGicfHT+AIdgFMz5NYEw== X-Gm-Gg: AR+sD12+l/eSKBmtT7CeAnfIM9TuL1Y6dU6VrgYJoiuAsGdcRrIMKHxq8ON6czHv/H5 z/kJ/CF5RHufcg84pRsZCaaaZ4hSm319L7PeN6Lk6Iw8jW3uVk1ndwqpcHzv6l48idFDHOLeCl6 1LMkFlR9gdnNqy/k3lSnoHTGnhS08JTfFV85syDAKujDc7HERaCnOwzsPg99NzmXfB7gSI4ncMw neoRoLw6KfyNQVgxi58VZtsc6r2RFloHE9Vh1cAuPEKrFx45x1+4G2o40XMjl+oM1zTXBUNLXVX O/AzJj8xJ6h4IW52j+IXCxb5G88BbaUZoIxh+cYgXGFYSPzm9L4k2+P5UCiuO5YC51czUE5rHmc 8TvH5a55D75UULwdti4reh7RtzZppQadcIJb7fYerHoRX1iQWkNNZXqvSaEc9uPjuN/b8JWwBb2 KZiQGpGAhGp3BQRlU74BvlCGRreW/UurNG0Wbqk1FlA96OkuocrvEbe5jHZeaRbzmMn2qYiI+uh RWDgrk1kqLwRAdfMG0d43cVgQrpuitRtwwU200wPKk= X-Received: by 2002:a05:600c:1d99:b0:49c:cee0:e7c0 with SMTP id 5b1f17b1804b1-49cdc560282mr201403165e9.16.1788277834225; Tue, 01 Sep 2026 08:50:34 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array Date: Tue, 1 Sep 2026 17:50:23 +0200 Message-ID: <20260901155023.116381-1-oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788277835-770D9A5B-41ACEFD9/10/73395122804 X-purgate-type: spam X-purgate-size: 3032 imsic_init() indexes msi[] by the Xen CPU id hartid_to_cpuid() returns, but that array is allocated with one entry per parent IRQ of the IMSIC node, and the only range check compares the index against num_possible_cpus(). Neither matches the array, and the check comes after the first access: - hartid_to_cpuid() returns NR_CPUS when the hart isn't one Xen brought up, and msi[NR_CPUS].base_addr is read before that is noticed; - an IMSIC node listing fewer parents than Xen has CPUs makes every index past nr_parent_irqs go past the end of the allocation, which the num_possible_cpus() check lets through. Size the array by num_possible_cpus(), which is what it is indexed by, and move the range check ahead of the first msi[] access. Fixes: c9bd8b322ecb ("xen/riscv: imsic_init() implementation") Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/imsic.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index f7b70a8da09e..a32264518676 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -326,6 +326,8 @@ int __init imsic_init(const struct dt_device_node *node) unsigned int nr_parent_irqs, index, nr_handlers = 0; paddr_t base_addr; unsigned int nr_mmios; + /* imsic_cfg.msi[] is indexed by Xen CPU id, so size it accordingly. */ + unsigned int nr_msi = num_possible_cpus(); struct imsic_mmios *mmios; struct imsic_msi *msi = NULL; @@ -346,7 +348,7 @@ int __init imsic_init(const struct dt_device_node *node) goto imsic_init_err; } - msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs); + msi = xvzalloc_array(struct imsic_msi, nr_msi); if ( !msi ) { rc = -ENOMEM; @@ -405,7 +407,18 @@ int __init imsic_init(const struct dt_device_node *node) continue; } + /* + * hartid_to_cpuid() returns NR_CPUS for a hart Xen doesn't know, so + * the range has to be checked before msi[] is indexed at all. + */ cpu = hartid_to_cpuid(hartid); + if ( cpu >= nr_msi ) + { + printk(XENLOG_WARNING + "%s: unsupported hart ID=%#lx for parent irq%u\n", + node->name, hartid, i); + continue; + } /* * If .base_addr is not 0, it indicates that the CPU has already been @@ -421,13 +434,6 @@ int __init imsic_init(const struct dt_device_node *node) continue; } - if ( cpu >= num_possible_cpus() ) - { - printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent irq%u\n", - node->name, hartid, i); - continue; - } - /* Find MMIO location of MSI page */ reloff = i * IMSIC_HART_SIZE(imsic_cfg.guest_index_bits); for ( index = 0; index < nr_mmios; index++ ) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 01 15:54:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 15:54:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404825.1638489 (Exim 4.92) (envelope-from ) id 1x1QoD-0003Sv-Jd; Tue, 01 Sep 2026 15:54:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404825.1638489; Tue, 01 Sep 2026 15:54:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QoD-0003So-GR; Tue, 01 Sep 2026 15:54:01 +0000 Received: by outflank-mailman (input) for mailman id 1404825; Tue, 01 Sep 2026 15:54:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1QoC-0003Si-BL for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 15:54:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1QoB-001Llo-K9 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 17:53:59 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96f512-8faa-0a2a0a5109dd-0a2a4509b2c2-4 for ; Tue, 01 Sep 2026 17:53:59 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96f517-be1a-0a2a45090019-d155dd2cc0f4-3 for ; Tue, 01 Sep 2026 17:53:59 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-4843efcbdb2so25781f8f.2 for ; Tue, 01 Sep 2026 08:53:59 -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 ffacd0b85a97d-48442d37111sm5535180f8f.5.2026.09.01.08.53.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 08:53:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788278039; x=1788882839; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=N9j6qS2MxuGUe2+uOaxo/Cd4AZ7Q6lLcAWMKZFmGIag=; b=NOdmIXnajMl7eCc4xgPHVH31bYGjr6K3MmjK3ctXz3VlNA35/aVeYGkwn+PDF8cO/O GeyY2pJiEpvAUwp8I//pWdQsK/I71EFXFyHw2PsgdmU0JISexEiBTwAut69+O5fBY1k9 pi0YOi5CnVxLHVqdDDDK/nsDJLv0mist8rSeakjTIXOElmVaaFvXaQDPdZ7X7COuvARn k6B5CQveo6E8idrfN1WNXmC/b0SpYRGijFChTMKTyXCgSZLpUKsD8VkeprTClZoTMdqT ezIrMR5URdLV6uXt0tT8ztW9eK+EOx5nO5inatZeyrorv+VAGpi7+W2kOGksZGnvpLR+ cagw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788278039; x=1788882839; h=content-transfer-encoding:content-type: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:content-type; bh=N9j6qS2MxuGUe2+uOaxo/Cd4AZ7Q6lLcAWMKZFmGIag=; b=PdMrKeDnizAso7Bho8DOYalSPFN5NBl+kKpliZeTYwQ1ogmbrs0GhATqKvT5lU9Jru 75D0QPMuHp+7u7XgJecy8FPjZ8iy0ThHP3cmw2w4mTa+xuWm6p7jgkW/mJbTb8G+tXDU TbruUwuhZDDTYBr+Ey68+3ezvB6sS5KFG7GBFWU0Fpa7bGtrUCPf2GEnC273xXxFWcyh UyqJitNjwaXp5Tn+WZEsKlmbPDiMYSP54hV/mNHFYDiKND2EqDTUiYehr3gM3/5jup1g yFtSXOa9dtegXnyoB3UtuNi8snP9/2uEycnAHYpYexuU5Bgcnzmm1gr7LYhotKF/5GD9 xfzA== X-Gm-Message-State: AFuF++kEnIP3f5jn6t/eNXSWQ2CuT2ezyYhtbLws2meSfuGGMzJRSaGX nLByMZzm4RZ+WtpWyun0treTltJJT1bEtzzSQfdbJcA7KnkLBJ9TDjbhVphl7Ju/bg== X-Gm-Gg: AYBFou30NUWAc/fa+r5CIk/uK0hLxV0ksjZvdDdgsAJ1LRsIj+jOfxpJ5FyUZdUG5YF WB/LCmMEooLnJIn0FJZPpT2DQoPbxvSzuvkNJdGTrHhp1xigEVIqoxtVni3GcSC873r35eSyw0E JXVfnX15D+0fd88SsDC4kk8/EFPwjbNF6FVmKSBDc7Tu5MdclJrqGeciQiIbvboTFdSGZTyyNsX IMgZkHGYoC3i2TSnb39RrRPcRZufbIQnEPv4dHJPsY/Z8wAIRbtYegmVqfAM5esxRoLV8x3ye12 wO+NHk2ZNnD/RAh2qFdn0HqSGjBN+chz6EjDI8S22TaRXXnMBKnQEjYvoNfRi+woAiQsVTvSg5f Y+WdE7/DKZc/ort5W08AbXTSQkfiNcjd4NrO8zPizRUMYIjX3hq8olxK/707490Tgcm4Oe274er 4K738okBgW+OMv9UsD/D8zG6GAUH391UKsX3/jNEx7SumwXSEIcC6NI0LwmZEmdh3v5VFlpJzms RsVELubl9CRBKAcyHP3MplmUhEL8A2WJni7gICuSgs+HzuBxP1D X-Received: by 2002:a05:6000:1a54:b0:484:3310:f397 with SMTP id ffacd0b85a97d-4844103d08bmr14824109f8f.24.1788278038729; Tue, 01 Sep 2026 08:53:58 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 17:53:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/39] xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <1788276968.8631fc262581453bbf619ec5b2062170.1a05d9d0d1d000c4f3@vates.tech> 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: <1788276968.8631fc262581453bbf619ec5b2062170.1a05d9d0d1d000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788278039-FCC15034-C9830A94/10/73395122804 X-purgate-type: spam X-purgate-size: 979 On 01.09.2026 17:36, Baptiste Le Duc wrote: > On Thu, 27 Aug 2026 17:20:51 +0200, Oleksii Kurochko wrote: >> These definitions are required for correct decoding of APLIC MMIO >> accesses and target configuration, and will be used by both the >> physical and virtual APLIC implementations. >> >> While adding them, rearrange the header in the style of x86's >> asm/msr-index.h: a register's offset is immediately followed by the >> definitions of that register's fields, with the blocks sorted by >> offset. This makes the relation between a register and its fields >> obvious from the layout alone, so no comment is needed to express it. >> >> [...] > > Reviewed-by: Baptiste Le Duc Acked-by: Jan Beulich If there's no dependency on earlier patches (nor the prereq series), this could go in right away. Yet nothing is being said anywhere, unless I overlooked anything. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 15:59:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 15:59:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404831.1638499 (Exim 4.92) (envelope-from ) id 1x1QtL-0004Gh-5R; Tue, 01 Sep 2026 15:59:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404831.1638499; Tue, 01 Sep 2026 15:59:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QtL-0004Ga-1k; Tue, 01 Sep 2026 15:59:19 +0000 Received: by outflank-mailman (input) for mailman id 1404831; Tue, 01 Sep 2026 15:59:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QtJ-0004GU-Tr for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 15:59:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1QtI-00Dni4-NK for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 17:59:16 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96f651-8faa-0a2a0a5109dd-0a2a45058b96-6 for ; Tue, 01 Sep 2026 17:59:16 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96f654-4cb1-0a2a45050019-d155802ae81a-3 for ; Tue, 01 Sep 2026 17:59:16 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b8be0409fso8858275e9.2 for ; Tue, 01 Sep 2026 08:59:16 -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-49ccea87e1asm203555295e9.2.2026.09.01.08.59.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 08:59:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788278356; x=1788883156; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=3FTKcWvsg9ZmRsPfEQDE1JeKRUJhC6t8MmFGG+2Q1b4=; b=bo620GCgL32087doVw4Ot3goiCKdEwwuxdDjFZotjQ3zz8c8mcJ1hQjZno6jKuevhD H4V3aNTbArWnX0imlkK5eF5Xf4i8YUi1ZcY1aGVpHE6NaQkTREQBbYs0N7bDsrTXbUlR VybINiWLS7gWiHpu2vQZ570Sb0aO9CP9w8SJeIjxBG1qwEjTrYEqcU0WcSSmVIrrO64s 9uBSMQa4kBi2aUSs1Bm0YJuHJGWYZzSbxKmswNOFFKqYIzGZITqolkEGuhs+UwrkqCI2 aQwyU4HKDSQ0FZza+h0QbVgkJ0VLTjIYvYy3xYV9G1yVq6KAJ4zDRv9TN/8H4O/OgYPX cizg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788278356; x=1788883156; h=content-transfer-encoding:content-type: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:content-type; bh=3FTKcWvsg9ZmRsPfEQDE1JeKRUJhC6t8MmFGG+2Q1b4=; b=PTdjDyaIeJ1fRHGZf4WVJtBgttLNfeK5LNW5GrQIU/onuF5/r2S1eDf+z4yhhf6KWL kPV6V7Qf0qrmoTkNzbXo26FxRWZqrTM507cc9aqp7i2CHWohJZwPgzj1ZRYNaXt3eaON 6pxLik7oDD97bme1505GW63BZlFpnJOgUj6HiLMP5qDuHiR86mpRcSJD1MtyW8SXbXJ4 qFXg0flZ7pQ2+uZFhyBIHXYvP7bt4yJ0+UpedDSQ2yzobrr9QXpAcb54OA8IUpYO/C7Y mpAnU39uU8g/acQU7/CI/sUQ3TP8j6aEPvZELK3BmiX1hZr0v5zjqekEpEg5JWJSus15 A6IQ== X-Forwarded-Encrypted: i=1; AHgh+Rqu90SBq79GaZwUYai++L76KtgMUe0VSkD81Ss0/O6sje/W/5FsiVctuX6RR8U+Eizg2T4mHl0/TQQ=@lists.xenproject.org X-Gm-Message-State: AFuF++ljRqjoJbo3yz7PoOMdi3qRtvY66iTDHqSPxYS2DddlK4p7bKAT aPG9MVpCaSFGUvrcMpP4cvUtzzEbNMp6mz1o+gMwtt8VEWjXS2YUKUNyB/P8o3Ngkg== X-Gm-Gg: AR+sD13xnuFEMa3qBogvmQPmOvblJNpzgbCh1+QJV6E7AQWKCLgHvgCTurRyjv2swWV VVMvZq3lHdK+82X89KMGFAuxbI4hKCQyUbFLoTjab+scXeYwyHpLmcdtFo3hFm2IOK3mGrXhVFA kjQfKiWfEo7eOraik/hA/cBwVXOxE1MjjhAEYjYy2/lCbs2BfY+9nmuorpeSEymRfWzjo1n0pVP ktIaxi+VCzXmlO8pwXwQG0oPRpCYhOz2VHsOG4Yb7hzNgrR6LQzpXQnuErMNf9UoFuYFo+Vk+Py 9S0FeSLkGtdz8YZdy6ud2DNGKARtZobQT47/utCtYEQwtm9TF1sR0fqDGfTYJ1pq5QP8quzmT0Q 0hcsqPHaWYY3TPzSArSAl5iy6Ec0k0D2VLC0vHkVv5/4yZGovRMXqM3NmL3RZDrIiErAWxQk9Vo s9fG9PRrPOnjMfYMJq83nVOjpudq5SoR9jUeugFycu3LpKqSwyQisWtpAOkGvNQKGCRcXqJykvf NbMYJPSqQxnbe+LytjX+54bOXRdH+hEXRjT1DO2gH1bubLPn1Ar X-Received: by 2002:a05:600c:6088:b0:49b:2796:be30 with SMTP id 5b1f17b1804b1-49b91c433a4mr570456425e9.11.1788278356026; Tue, 01 Sep 2026 08:59:16 -0700 (PDT) Message-ID: <45fc41c1-7127-4e70-ba81-2a85d1bc7655@suse.com> Date: Tue, 1 Sep 2026 17:59:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260901155023.116381-1-oleksii.kurochko@gmail.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: <20260901155023.116381-1-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788278356-24F1F2A1-74F571FB/0/0 X-purgate-type: clean X-purgate-size: 672 On 01.09.2026 17:50, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -326,6 +326,8 @@ int __init imsic_init(const struct dt_device_node *node) > unsigned int nr_parent_irqs, index, nr_handlers = 0; > paddr_t base_addr; > unsigned int nr_mmios; > + /* imsic_cfg.msi[] is indexed by Xen CPU id, so size it accordingly. */ > + unsigned int nr_msi = num_possible_cpus(); The possible-CPUs-map may be sparse, so num_possible_cpus() may still yield too small a value to use here. The thing to use likely is nr_cpu_ids. I notice that variable is entirely unused so far by arch/riscv/*, though. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 01 16:01:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 16:01:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404838.1638508 (Exim 4.92) (envelope-from ) id 1x1QvJ-0006LD-G5; Tue, 01 Sep 2026 16:01:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404838.1638508; Tue, 01 Sep 2026 16:01:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QvJ-0006L6-CX; Tue, 01 Sep 2026 16:01:21 +0000 Received: by outflank-mailman (input) for mailman id 1404838; Tue, 01 Sep 2026 16:01:20 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1QvI-0006Kt-Nw for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 16:01:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1QvH-00F4kI-Pq for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 18:01:19 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96f6cf-8faa-0a2a0a5109dd-0a2a4502a60c-2 for ; Tue, 01 Sep 2026 18:01:19 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96f6cf-6ca4-0a2a45020019-d155dd33b0d9-3 for ; Tue, 01 Sep 2026 18:01:19 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-484415c8cb1so47376f8f.2 for ; Tue, 01 Sep 2026 09:01:19 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48442d6e9cfsm6093550f8f.22.2026.09.01.09.01.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 09:01:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788278479; x=1788883279; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Uxs4dwxHLDrtpiehWQZcP6/OkQeIFJi5v0FYqUxYdnc=; b=nB38xEYMcSjGlnTkv426FbLxZd3cM++3MZ5URx4z/gYfIWglW6LJJBeh9JsQb0FkpT jLPdIaGeDY66ZOe47uCDSZVE0T3tNBDWeSXbe+98twnquQmMW3fdcBFPozhCPUrnlju5 kc9fx2H7Dqa56jdECk/iaVS2KbtVGT84qWUsfcFR+HF4xNMENflMJbEStBLOW1Kc3jtg hmijjC0f6ElcQ2RUQAx1vSLPdex7lCf5zkYBu9HkzYWe4TcYKjO4B7cXK5NNCBhLEHgI xmT2IUo5H/gTjgVv7DjGHzTNS5zVuIZBAal2vv+U3ciODv1880rbaT4Oe3GBnlntj9CM gmTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788278479; x=1788883279; h=content-transfer-encoding:content-type:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Uxs4dwxHLDrtpiehWQZcP6/OkQeIFJi5v0FYqUxYdnc=; b=MWmiIo7M5hJnocagO5aHGonLXEUQB12FFnGAMlA/wA+80WW1MFpWZ/n+g2hfqJ1s89 3wXy01CIK1L9MOOQDV4luBEiU+sSQ/UihoKS+zTd9wTnSaJACPovyYaCbfXSifOYqUT5 dvcmfztDaD3N6c+AkYO7wMIcIw+43j9gMNJWmZwR3Mq7r3YCmzLl/ny7XdlsGCuI5EpK PA4IRTnH429F2kGXsoeJeJP1iKbAJGrhX5H6fJsA5PHPvTWXvpPdEsGI6jT6a+sh60H5 fxvKCNTAymaEvL5w0GDYF0fkwNhmBjElHz9y1GZBdfTsocVLC64XNgqPR5wmgwGCz2le WuQg== X-Gm-Message-State: AFuF++mx+ScJJ4ro2tno1sVaYRpi+hV6mQvawcPqZu62FALLRfQE9u3D dDCPvTEwzIPPHbe056eV/hg9z037KxdxAFb1XA76w37IOR+JrLE+kNylhdfdtg== X-Gm-Gg: AYBFou28gQATqc5wf0P6AS6hlPUGup+A1PEUEU8Gyj8yLKSc5a+XOMUvtupcwgogcan n5kk5L5nYhoFZZAEbT5oyZ4hAqhfBh3gTGMtNbLgzDiKgt6RE1NNkN3wZM1ec11QQ4lWqDwvXZJ cLQ6qwpOu/Y4GDDLX5KoIKBw5ABbyYcC1Tib8c93PzTP88AKLie/iuv8+Un5CVtpIhhjN+F4Xcr xKjzwqvdLjKaVf0vUYrM6L0819Hl6twpB3yS2lhxXL5zRn8+MsB5gfUItJwTH6SYbjGxMQYzfVG nr784kL1/yq4Seosx/D4J9eHx8KNfmjXroChep1cj/QxO8HZbsKl9z5VMWgnYHofi/knIEVbpyP iGxCg7gx3qQW0WMziNxNsLOMsfwe+dJyVP/dyI1Sh8GkCGDvt/V4VEImP7/3dWS/fKpYS+y2cp9 5IHovLLsK1F+ZI5yf1wC/GBTjB8QczHm1gDlnhdO2Ckg2oxPcJT6wJ6QA0lT+bmaxlR+u6HtAbU RZOPYTwC4nLayTJC0jRrX8YtlJFqnHujuJD4NCUNQ== X-Received: by 2002:a05:6000:27c6:b0:484:3310:710b with SMTP id ffacd0b85a97d-48441025c15mr13724662f8f.23.1788278478991; Tue, 01 Sep 2026 09:01:18 -0700 (PDT) Message-ID: <74fb7d16-7042-4311-a39b-d00e5a0560f8@gmail.com> Date: Tue, 1 Sep 2026 18:01:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Xen-devel Cc: xen-users@lists.xenproject.org, Community Manager , "committers@xenproject.org" From: Oleksii Kurochko Subject: Xen 4.23 release schedule proposal Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788278479-30DC12AC-4D8DEC12/10/73395122804 X-purgate-type: spam X-purgate-size: 2884 Hello everyone, Following the 8-month release cycle, and taking into account that Xen 4.22 was released on July 30, 2026, the next "good" month for a release should be March, according to: https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html I have two options in mind: Option A: Proposed release date: Wednesday, March 17, 2027 (~8 months after the Xen 4.22 release) Last posting date: Friday, December 25, 2026 (~16 weeks from now) Patches adding new features are expected to be posted to the mailing list by this date, although they do not necessarily need to be in their final version. Feature freeze: Friday, January 15, 2027 (+3 weeks from the Last posting date) Patches adding new features should be committed by this date. Straightforward bug fixes may continue to be accepted by maintainers. Code freeze: Friday, February 5, 2027 (+3 weeks from the Feature freeze) Bug fixes only. Hard code freeze: Friday, February 26, 2027 (+3 weeks from the Code freeze) Only bug fixes for serious bugs (including regressions) and low-risk fixes should be accepted. Final commits: Friday, March 12, 2027 (+2 weeks from the Hard code freeze) Branch off staging-4.23. Release: Wednesday, March 17, 2027 Considering that there are several holidays at the end of December and in January, I would also consider the following schedule: Option B: Proposed release date: Wednesday, March 24, 2027 (~8 months after the Xen 4.22 release) Last posting date: Friday, January 8, 2027 Patches adding new features are expected to be posted to the mailing list by this date, although they do not necessarily need to be in their final version. Feature freeze: Friday, January 22, 2027 (+2 weeks from the Last posting date) Patches adding new features should be committed by this date. Straightforward bug fixes may continue to be accepted by maintainers. Code freeze: Friday, February 12, 2027 (+3 weeks from the Feature freeze) Bug fixes only. Hard code freeze: Friday, March 5, 2027 (+3 weeks from the Code freeze) Only bug fixes for serious bugs (including regressions) and low-risk fixes should be accepted. Final commits: Friday, March 19, 2027 (+2 weeks from the Hard code freeze) Branch off staging-4.23. Release: Wednesday, March 24, 2027 I slightly prefer Option B. Please don't hesitate to provide your feedback. If there are no objections to Option B, I plan to update the Wiki page Xen_Project_X.YY_Release_Notes to make it easier to find our final schedule, especially for people who are not following the xen-devel mailing list. As an additional benefit, it will also be accessible via SUPPORT.md (in the Wiki at https://xenbits.xen.org/docs/unstable-staging/support-matrix.html). Thanks, and have a good weekend. Best regards, Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 01 16:01:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 16:01:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404841.1638516 (Exim 4.92) (envelope-from ) id 1x1Qvm-0006il-P2; Tue, 01 Sep 2026 16:01:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404841.1638516; Tue, 01 Sep 2026 16:01:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1Qvm-0006ie-Lm; Tue, 01 Sep 2026 16:01:50 +0000 Received: by outflank-mailman (input) for mailman id 1404841; Tue, 01 Sep 2026 16:01:49 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1Qvl-0006hG-DY for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 16:01:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1Qvk-001N3C-QQ for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 18:01:48 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96f6e5-bab6-0a2a0a5309dd-0a2a4507e316-28 for ; Tue, 01 Sep 2026 18:01:48 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96f6ec-b4ea-0a2a45070019-d155dd34f06f-3 for ; Tue, 01 Sep 2026 18:01:48 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-482fc2b44a7so60030f8f.2 for ; Tue, 01 Sep 2026 09:01:48 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448e13db0sm61769f8f.0.2026.09.01.09.01.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 09:01:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788278508; x=1788883308; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=xf85yesiKQUQie1aMQO7OcAiS04pkkycYfzDVlZGMZI=; b=h+cL0n/NXvJIIbK2qWYICcb1rQnWt18XQpzCwZzpkP+rufxW110QXau782VBML0cqE Xy2/R8YWNjDl/T5NPRCw2j46j7+fP9SABvLLyejLQlHEG1YMaikhy9kF5yPHFrbBahkj 1HMN0Q3AKLjKAmukV6mP0ewlvahrJvd14WBUlPq5uAdFKhyJHPCf1pe4KKeDSFaIsRoP tR38o24ftOtW/MpZZQN/pJYbmfsGEkAfVcjILWGmtg/4fw+ALzfDSDk1D/xQVzlP6LQ+ oAKxqegNku95GeBT38wXwbKH3fh5SoTBzLgjeQvHcwqXANKAVxA7bVCB9mIDJoipMYw4 SSRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788278508; x=1788883308; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=xf85yesiKQUQie1aMQO7OcAiS04pkkycYfzDVlZGMZI=; b=m1L5Ph8JfYxK3ii1T7MMxy3p/HyOMCkw/WVEF1RBAf6EI05Cx6qLAV3eRzAR6oFmK1 j2jZxPN/wZySk9P3cQaObO2YQBYzb6MqvQ4m7ZVfns1FGqSIj+1uCjmgaaG23HG3dEJO j8qNPwVacTuPLqoPMju5yqq1V8ChFZJt7wLp/Ng9iYHZUXyveMZQ4c+OO9LCunxhS4GS bz/u6HmBMXMIhR8cHqLm2XRXZVRVUsvURMvrM7rG/YbLndF53bG5vQUKDxw6mXDz0Qww DA+Bi7xWfqF9T486tHd1z/6qI6BIlWked/NwuCLtX4jo5YqojHIRPLAPgtLBLAakz3qx wN8A== X-Gm-Message-State: AFuF++m5FjALZmnIwjIEfDKwwvLeiKfMOjqVEJ3aZQbByiGu8OcEaLAj bumN0gg+NdM7MeqMgFhpFcsH60MDm4nQ0f2yM0u4CCNJ4mLQqTMn6h8W X-Gm-Gg: AYBFou0huOH2Wmd8QbQjqhQ5jQ31e6gj9PvUULPhxsXySBqgTTcBgkf+/VKJ5SWnHuG RYYrVYJ2npeYocgqf5HgdIA8VtYETdTPhutKDLxwVMdcY9zqWl5WVTLjglSDQfgYrxsvpaH89cY UF4zJCQcZ0MnAR2/VpFNnAl12cjsGX2PbqOFLSb42dBJhnGThR7LDgpmcvKOfV8diQroBCwqsic 8Xr4ZFDHmYy1LNxJq40h3Mn5Ge34+fPZJIDM9XJ5O5ph9z1xbGts1zkpVMCUDVvgdpQH9H33EV4 p3TMNvBw75elzIV1Du8rXba133GruKYFIxWHT6FCAN8QA1hR2EDxi6NmExmqDsC0OPlQL0zJ3x4 4mlmeiB9jVRHtFPw4/LJLxo6ZlXJIJOV2kMffGTTkRoXmI7P83PqvtQqb7kHvd2RllF6lPPyCLU BX52A8z2QTBJs9wQlGtasW7ueAaP4sdIhQoJCCRMdjinM4Cx+1BY4NwAEsRUokkHolyNTSEMyjj 4FJWfxwecWwH3OawYtzTcZpc9HjsiPLGDmB6iWAPA== X-Received: by 2002:adf:e005:0:10b0:484:40f5:da6a with SMTP id ffacd0b85a97d-48440f5dac4mr13730232f8f.15.1788278507963; Tue, 01 Sep 2026 09:01:47 -0700 (PDT) Message-ID: <3f6cd361-6349-433e-a7b7-8cc72b31b84e@gmail.com> Date: Tue, 1 Sep 2026 18:01:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH 3/5] xen/riscv: make Svpbmt no longer a required extension To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn, Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech> <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@vates.tech> <59555237-425d-47f0-80b6-b7273cc8d6ec@gmail.com> <1788168989.8631fc262581453bbf619ec5b2062170.1a0572d6c8c000c4f3@vates.tech> Content-Language: en-US In-Reply-To: <1788168989.8631fc262581453bbf619ec5b2062170.1a0572d6c8c000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788278508-A78D1AE4-A49D3CD5/10/73395122804 X-purgate-type: spam X-purgate-size: 3687 On 8/31/26 11:36 AM, Baptiste Le Duc wrote: > On 2026-08-28 17:58 +0200, Oleksii Kurochko wrote: >> >> >> On 8/27/26 5:33 PM, Baptiste Le Duc wrote: >>> required_extensions[] panics at boot if Svpbmt is missing, which is a >>> problem on hardware that doesn't implement it. >> >> Based only on this sentence it isn't clear why it is safe to have SvPBMT >> = n and what guarantees that if some memory for a device dma for example > > Sorry I'm not used to this kind of terminology, does Svpbmt = n means that MT > bits ([62:61]) are equal to 0 = PMA? Yes, exactly. Sorry for the confusion; by "Svpbmt = n" I meant that the Svpbmt extension is not available/implemented on the platform. > >> should be non-cachable and strongly ordered what will guarantee that. >> >> So basically something like that should be added to the commit message: >> ``` >> Without the Svpbmt extension, memory attributes (such as cacheability >> and ordering) are strictly tied to physical address ranges and enforced >> by the hardware's Physical Memory Attributes (PMA) checker. >> >> In this configuration, supervisor software relies on the platform's >> memory map: peripheral device registers (MMIO) are physically mapped >> into hardware-defined I/O regions (which are implicitly non-cacheable >> and strongly-ordered), while regular RAM is mapped as cacheable main >> memory. >> >> S-mode paging can safely map these physical ranges without specifying >> page-based memory types in the PTEs, as the hardware MMU and PMA >> pipeline will correctly bypass caches for MMIO accesses based on the >> target physical address. > I think this could go in the previous paragraph as it only concerns > of the configuration you mentionned. > >> Furthermore, on platforms that either feature >> fully hardware-coherent DMA or do not expose non-coherent DMA agents to >> the OS, page-level programmatic cache control via Svpbmt is not >> required, making it safe to boot and run when Svpbmt is absent. > If we have a platforms that doesn't have both of these feature, what > would happen? Regarding your question about what happens if a platform has non-coherent DMA and also lacks Svpbmt: In that scenario, we must rely on other standard RISC-V mechanisms to guarantee coherence. Typically, this is handled in one of two ways: 1. PMA-backed non-cacheable memory pools: The operating system or hypervisor must allocate DMA buffers from a specific physical address range that the hardware's Physical Memory Attributes (PMA) checker defines as implicitly non-cacheable. 2. Software-managed cache coherence (Zicbom): If we must allocate DMA buffers from regular cacheable RAM on a non-coherent platform, the platform must implement the Zicbom extension. Software (Xen/Linux) will then use Cache-Block Operations (CBOs) like `cbo.clean`, `cbo.flush`, and `cbo.inval` to manually flush and invalidate caches before and after DMA transactions. 3. Some platform specific solution... So indeed, there are several hardware design combinations, but compliant platforms without Svpbmt must either enforce coherence in hardware, provide dedicated non-cacheable physical memory via PMA, or implement Zicbom for software-managed coherence. > Do we need to add a check in Xen code? Good question. Generally, it would definitely be good to check this, but I’m not sure how we could do that at runtime. The best approach I have in mind is to require the user to explicitly set a RISCV_ISA_SVPBMT configuration option (which doesn’t exist yet and would need to be introduced) if the platform supports SvPBMT. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 01 16:05:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 01 Sep 2026 16:05:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1404854.1638526 (Exim 4.92) (envelope-from ) id 1x1QzM-0007oI-BB; Tue, 01 Sep 2026 16:05:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1404854.1638526; Tue, 01 Sep 2026 16:05:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1QzM-0007oB-8L; Tue, 01 Sep 2026 16:05:32 +0000 Received: by outflank-mailman (input) for mailman id 1404854; Tue, 01 Sep 2026 16:05:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1QzL-0007o5-Am for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 16:05:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1QzK-008kqP-IM for xen-devel@lists.xenproject.org; Tue, 01 Sep 2026 18:05:30 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a96f7c5-8faa-0a2a0a5109dd-0a2a4509bdfc-14 for ; Tue, 01 Sep 2026 18:05:30 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a96f7ca-be1a-0a2a45090019-d1558035ad41-3 for ; Tue, 01 Sep 2026 18:05:30 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49b0dd3c9a0so34650445e9.1 for ; Tue, 01 Sep 2026 09:05:30 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b9269f1b6sm273269135e9.4.2026.09.01.09.05.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 09:05:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788278730; x=1788883530; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=AbuICIoNGzBdRJXA7FCwp3jUZqBDb4bPalbg5kTERBI=; b=joPZWQ2O5RFerk56Rs1g/l0UHTvIZIM9jsYscl1+JaYQO8pN1yX19FnN4kk9XCg+TD DrJ4uHuwWQj6OZlwdTS8feA8Sp2MMGIq67HKl8dS+s4nxmv9Y6jUKnQCQb0v+xw9JIBN UL5NcaWfq4gcp4mzaoSn2tPkLRvv+pJ3HnAvtFX272rXyN5ND30nJS7KXPAnLKN+iEUi JfNr2Vi/05gQbpLKsarIvJUpDLXP2TGcoUT4Zxu0c1prVqwzLDIxkxpbvXXUNCyCWuEJ V37XAouD0B6wVvL46ucwZDr7lqslgaARzqRBG/tX+5U/7SwqMoxihdZZyakW49ysBjlT rWKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788278730; x=1788883530; h=content-transfer-encoding:content-type:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=AbuICIoNGzBdRJXA7FCwp3jUZqBDb4bPalbg5kTERBI=; b=lLuDsu6VYnNxIsibIhD5PxoF/97UzcH1quZ83J0sPYk5FcaJ+8OekJ4PaP1PJy5clh 5k3OyldU5hb5x2DC6M9gWhI+66f/jyB1KvpsfcyRn4/yNpRzCSOcm1A5lf5Yjjeq8elP R6X8mmGR/4my+9KDae0A6MQxKD+3tIalJrVgttyIkUMrhoycFFaQRi+LD+pVQbw9bW1M D8y/GDknSA6dMajnLdkqpNz+GqtHiHnCp4usY8JAsSAABVWTGEGLWeNW6Mdw2PSqtzyy l4UX4XF7lBeO4wV8R/s6oWMp09zaHSAoU45CFC5loaS7Sl+tuySCh4n3uRh0x3RIZdee j6lg== X-Gm-Message-State: AFuF++lmnglqsZevbJXEZUaKFTK1YngV3C/gKQAO4zg9i26dPK3Og+rG AeV9M6O8abMazwBVfhjQXyrxaIUNMwz2eZlZh+cF2IkLTJrkLJmrq1q8yhHL+Q== X-Gm-Gg: AR+sD13sdkB0DYen+9whvT7DLwZ1MAzPNMvZ0h+LgLldT6mNa26zN4LaxiK5lI6GgIJ RrNIjPCn0jqFJkruVctq9ZoBgkPUiyp9KbbRiJql7ZUKH5XKPfGe46991YaLPD8Tx2sHVRGTnSM giAYf8xyLpgoO5SAE2PmiyMqPXrNXzRNfsULgcqaxqfw53PB4lF6PviqoypbjU2J3l0PdZwPfXu ugRK9E0sCvtbiffj5dDa5FQWMRVYuYI2syZXOxJ8s8Qw0Z+WKqkOabwtSg2Um65/QpbS0LxFz1q B+ZpYcXSb6sf4RcmrvB+jPCQI3Dnvx5UTpgvcpWvOEaFajRoTfD8ESXq2CTL/7zM8V4wHFeyCLn gE5JGCgO6/sFnACybOfwtND3qLjZ6+C7h3ceebhLV1rH7SY/tBC70ubKiOxRg9qNVN/YAZT2Uu3 LxUA/37Ug9UN3OAk+1XhSOixzv1lHmOWrzul09QPbSX4OfijTpu3kSN1m1ENqhG120QvJtslq/K AJ+qZXNrIXMkLVAQJh7zU85UuPAYmOEUJJ32Br1+g== X-Received: by 2002:a05:600c:524c:b0:49b:9161:db26 with SMTP id 5b1f17b1804b1-49cdc55a9e5mr141652635e9.14.1788278721179; Tue, 01 Sep 2026 09:05:21 -0700 (PDT) Message-ID: Date: Tue, 1 Sep 2026 18:05:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Xen-devel Cc: Community Manager , "committers@xenproject.org" From: Oleksii Kurochko Subject: Xen 4.23 planning: items for the release Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788278730-BECDF034-99D55FE3/10/73395122804 X-purgate-type: spam X-purgate-size: 1333 Hi all, As we are starting to plan for Xen 4.23, what items are you planning to work on during this release? If there is an existing RFC, design discussion, or patch series, please include a link. Short descriptions are also welcome. I will try to use the gathered items to provide some kind of monthly update. As I am mainly working on RISC-V-related topics, here are some of the things we are planning to work on connected to RISC-V: - Dom0less guest domain creation: https://lore.kernel.org/xen-devel/cover.1787836900.git.oleksii.kurochko@gmail.com/T/#m2697fe1ca8d7c07eda0b11d4c5183a18e46d6f97 - AIA-related topics: https://lore.kernel.org/xen-devel/cover.1787838835.git.oleksii.kurochko@gmail.com/T/#mae53a50655abd12ef4851a328b68a182b23abcac - CI-related topics: https://lore.kernel.org/xen-devel/1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech/ - Support for real hardware (HiFive Premier P550) with a PLIC interrupt controller: [not fully connected yet, but some preparation work] https://lore.kernel.org/xen-devel/1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech/T/#t Other patches are going to be sent later. - Dom0less guest domain launch. [patch series planed to be sent] Thanks in advance. Have a good week. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 02:32:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 02:32:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405007.1638559 (Exim 4.92) (envelope-from ) id 1x1alg-000157-4Y; Wed, 02 Sep 2026 02:32:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405007.1638559; Wed, 02 Sep 2026 02:32:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1alf-00014z-Vu; Wed, 02 Sep 2026 02:32:03 +0000 Received: by outflank-mailman (input) for mailman id 1405007; Wed, 02 Sep 2026 02:32:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1ale-00014t-M7 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 02:32:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1ald-00GD2l-FA for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 04:32:01 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a978a85-e002-0a2a0a5209dd-0a2a4504c3ec-16 for ; Wed, 02 Sep 2026 04:32:01 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a978aa0-b57f-0a2a45040019-416d716cc5e4-3 for ; Wed, 02 Sep 2026 04:32:01 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 1841A40E027F; Wed, 2 Sep 2026 02:32:00 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id grKAqAkDQxBF; Wed, 2 Sep 2026 02:31:50 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id F350E40E02C2; Wed, 2 Sep 2026 02:31:31 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=fail header.s=alien8 header.d=alien8.de header.i="@alien8.de" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=fail (4096-bit key) reason="fail (body has been altered)" header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1788316308; bh=EwFLC8HpYmRJXjFrVbfRa0roHEFDXarZtMTpmdyIJIo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GeTACKuq4sfjSafQmtL/mNU2DMZXKongg2aWLsv445YZFwuPNMcN+3RYV3NEAuRTn Ocvt51Ehh163Yijix3A+3MFWpRBxGI8cuGfjtzNc5vA93trT/wR8flmDeQR9rSLd4j C48FS45t2RylDIHjK3HGbQrqshjQxmcRFjxrDy8tMYbMUVVrWzLu/pvkRddhCEQbJj 5+cX0AnpQIZtV+OekTI6CVjkjbsNxLrbFgJ2X1QkWcUchDFGTOra1fUG54M+Fiq2Nb IOUyQtwGnMyd5iyvbtGo4OxbbiZ2Atb0OgMN3bSILdSij1m/IG3cmWck7RxYNUJnrd 8cmsvDrlwyWHFOs90dB+12JWYp2kGKrz3arXahns0uS0wl7I4S6o+swbv36rMIu2O+ jiLBHQ2x3Z6hCcicGUyPSPWfx5AZu0yzptnrvgcIRGofB9w2U0iK6z1i1cQ10xthkt XPMwTm7/Ld7QLSlrLcQTdbNCDrxxdl54HVaoN+bi3L7T+6C4eQPws/IZoLLDBI+YZU AE2GZyfvie0is6REKzz249vK0NDF/oK6Hr311S9Gnvng8k705nwsOe5huyRNqIsZ9t Lc5GQh1/6AIQS+sqOt815w2sq4nN8dmuJLcXhU2uJ/twqG8fMFReBXh6LIcHgKOLJU T3i5k14MW/o20cT4ih1nIrlg= Date: Tue, 1 Sep 2026 19:31:29 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira , Michael Matz , Richard Biener Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() Message-ID: <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ebf023/1788316321-C12DCB50-C72FFCC3/0/0 X-purgate-type: clean X-purgate-size: 2652 On Sat, Aug 22, 2026 at 03:33:17PM -0300, Mauricio Faria de Oliveira wrot= e: > According to the GCC documentation, conditions in the flags register > (e.g., "=3D@ccnz") are output operands [1] and the compiler is aware [2= ]. >=20 > Also, clobbers (e.g., "cc") may not overlap with an output operand [2]. >=20 > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the > "=3D@ccnz" output operand. >=20 > """ > 6.11.2.4 Flag Output Operands >=20 > On some targets, a special form of output operand exists by whi= ch > conditions in the flags register may be outputs of the asm. [..= .] >=20 > 6.11.2.6 Clobbers and Scratch Registers >=20 > While the compiler is aware of changes to entries listed in the > output operands, [...] >=20 > Clobber descriptions may not in any way overlap with an input o= r > output operand. [...] > """ >=20 > Reported-by: "H. Peter Anvin" > Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@= zytor.com/ > Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length = test in memcmp()") > Signed-off-by: Mauricio Faria de Oliveira > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-= Operands [1] > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and= -Scratch-Registers-1 [2] > --- > arch/x86/boot/string.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c > index 1632d40e1f545ae0665597069b568ea6b6c263e5..03278b4393887cb71cb0638= 18d3378c4f52b06f8 100644 > --- a/arch/x86/boot/string.c > +++ b/arch/x86/boot/string.c > @@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len= ) > asm volatile("test %3, %3\n\t" > "repe cmpsb" > : "=3D@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) > - : : "cc", "memory"); > + : : "memory"); > return diff; > } So far, so good. But then I'd expect that gcc would enforce that. I know it can't have it = when the clobbers contain input or output regs: In function =E2=80=98__memcmp=E2=80=99, inlined from =E2=80=98main=E2=80=99 at memcmp.c:25:6: memcmp.c:11:9: error: =E2=80=98asm=E2=80=99 operand has impossible constr= aints or there are not enough registers 11 | asm volatile("test %3, %3\n\t" | ^~~ but with "cc" clobbers it works. That's gcc-16 btw. Micha, Richi? --=20 Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:29:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:29:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405030.1638568 (Exim 4.92) (envelope-from ) id 1x1eSx-00011p-VG; Wed, 02 Sep 2026 06:28:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405030.1638568; Wed, 02 Sep 2026 06:28:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eSx-00011h-RK; Wed, 02 Sep 2026 06:28:59 +0000 Received: by outflank-mailman (input) for mailman id 1405030; Wed, 02 Sep 2026 06:28:58 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eSw-00011b-A3 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:28:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eSu-00DyBi-Aa for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:28:56 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c21b-2eae-0a2a0a5409dd-0a2a4508cc08-32 for ; Wed, 02 Sep 2026 08:28:56 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c227-f659-0a2a45080019-d1558029c86b-3 for ; Wed, 02 Sep 2026 08:28:55 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4956869750eso3828675e9.2 for ; Tue, 01 Sep 2026 23:28:55 -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-49cdce164bcsm119281795e9.7.2026.09.01.23.28.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:28:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330535; x=1788935335; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=QWTSCgKvktISyZ71nmFfcqzhFxkY1BWGXzHWN/eaPww=; b=cS8oS2PSpe7wgcK+7inJVMJBJxq6LiqNEzLb5P8mKZYUBYAQ44daFqXA8ctIcPLoVX Oo+P2hCU550IynnUA48MWQv3iK8GvI0lFp4bz1ZPGiX5E9b3k8wZiX67sbyp5YiXCKuH Z+Etc4fvcaUZ/Su6gHxyuPwuNjE9Y9JJerZM1mo0EwDd1Y5U7cg8Lw0rZg3g7qsAuWDm 6s/KwhWLPPuL6VXEDnoKE/5hp2SD0dxOHC6lL63umV485VwVrvPXaE0GCOzZsRflNfXW fArXALHbRk3DTX2UQ97tGygl39v/MgE0TexzFWVhCe+CbcoH42jF3gBWmLC9sw6xThxy D1Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330535; x=1788935335; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=QWTSCgKvktISyZ71nmFfcqzhFxkY1BWGXzHWN/eaPww=; b=Zat3uTDo6rbaakjMgfK6gNRHfeUqC03z15UJj18YnVvqwxQUcfCXmRB6WxIkLUIhEM +p2Fr9QNBrBVr7IOKOdcJ846QqR0J2mwYYaKisEsAoxyaZ/hlJcdp90C4eWOTxr++Nna eo8IURRDAZTz9Q3BxgbpFur4MRAqdVTCpoVtrhKZKMgh0N4knIXI+/70Kuk6hQmsL+89 upC3D4+h76F3eVB2uHDHNiPVJh+3P2c8sZUKt8xPpqw1NmpoQlDNZF0gbvH3IaWhEz+Z f9pOebNqe2t/sVQQ2lZWmkvm8gkVfzKfsRp+0GybYvq6WbdSYXjJ414nzh43++M2TJPm f5gw== X-Gm-Message-State: AFuF++k+sgDp2f1QNEVS7CYXmwMIlgx/GTb0AtY7JIrI+kHY0mdgaPRD txM2+kYGwwtjXLGl29N38eKcS5q6NJ9DYS+SOo77HJqCy2IAPS0jMq+kS9SOSMwkbwXtVUIqc48 bZI7xeQ== X-Gm-Gg: AR+sD100w2woRQFlPqiKXrSDpFT+NJ4ot+xTEjaisjXIWy+151dWSr6px7tfq4rSEeP IsuXoQa7K1B9Ikp14H07G7+C3R9Tmdb+XW9U6nftCZYyknduczCxnVd59sTpJPujHSe+Ocz2OPH zw5ULivcka2xPMbQjskU02SFr4EIxRGzeuJ8SDtA6BvjLafw9ELEOC6Yz8yZ6DKHc9zAYakYx+W R30LAIc+7IS9On3jm8DuneMR0CBtJmi4VHqLBRI4Qu/l8+T4p5wy+JCJms1Dkt3MEzVyxgY4F6y NvvrVaEg4iHEUHKcACwDB2oxIDNVJH2T3Ylu/o7mGE//u8iqjzI4e3eX/nKL2kFnFeur5uv7d8e Yj1qUaNupZmYsWNISToMaTRkjtc55Or4Ypqtv8TafYatCv0xbgYJdv0wDCkQ2Er/Bz+P8cCYdgR Hmy9+87yu5kCpEyG2nmDPWg3qgb2dRnetHSd0+kHsF14SRjR5WNrqhDiGGhKTx+3Lte/EmBkBA2 aQhY9L/F7gjCbcImJHBxbDE9X9f6g0Jkx/69IdcmAYRU7C3kNFjO2oGSSBrjzg= X-Received: by 2002:a05:600c:4592:b0:49c:e1b5:b2bf with SMTP id 5b1f17b1804b1-49ce558ff08mr37209915e9.0.1788330535282; Tue, 01 Sep 2026 23:28:55 -0700 (PDT) Message-ID: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Date: Wed, 2 Sep 2026 08:28:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini From: Jan Beulich Subject: [PATCH 00/14] address half the remaining Misra rule 11.8 violations 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788330535-D6D4087B-57D658B6/0/0 X-purgate-type: clean X-purgate-size: 1498 Casting away const-ness (or volatile-ness) is generally bad practices, so this is perhaps one of the more important rules to get into clean state. Despite being bad practice in general, there are cases where doing so is pretty much unavoidable; in some cases even the library spec mandates doing so (without Misra having any provisions for that). How to deal with most of those cases is still up for discussion, only very few of them are actually dealt with here. As per [1] this addresses about half the remaining violations in all four analyze jobs we have in gitlab-CI (patch 06 wasn't included there, yet). 01: lib: obey to Misra rule 11.8 where possible 02: x86/bitops: don't cast away volatile-ness 03: x86: have cmpxchg16b() obey to Misra rule 11.8 04: x86/boot: don't cast away const-ness 05: x86/altcall: hide casting away of const 06: Arm/alternative: hide casting away of const 07: Arm64/GICv3: have gicv3_its_find_quirk() not cast away const-ness 08: Arm/guestcopy: deviate copy_guest() uses just like their x86 counterparts 09: ACPI: address a Misra rule 11.8 violation in Arm code 10: ELF/notes: use pointer-to-const by default in ELFNOTE_...() 11: crypto/vmac: don't cast away const-ness in aes_key_setup() 12: gnttab: don't cast away constness 13: passthrough/PCI: rework (s,b,d,f) init of struct pci_dev 14: xhci-dbc: don't cast away const-ness in xhci_find_dbc() Jan [1] https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2810122986 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:30:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:30:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405035.1638576 (Exim 4.92) (envelope-from ) id 1x1eU3-0002S0-64; Wed, 02 Sep 2026 06:30:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405035.1638576; Wed, 02 Sep 2026 06:30:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eU3-0002Rt-3Y; Wed, 02 Sep 2026 06:30:07 +0000 Received: by outflank-mailman (input) for mailman id 1405035; Wed, 02 Sep 2026 06:30:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eU1-0002DO-Ae for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:30:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eU0-00ANlB-NC for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:30:04 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c269-8faa-0a2a0a5109dd-0a2a4505b328-18 for ; Wed, 02 Sep 2026 08:30:04 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c26c-4cb1-0a2a45050019-d155dd30ad58-3 for ; Wed, 02 Sep 2026 08:30:04 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48433fad54aso418555f8f.1 for ; Tue, 01 Sep 2026 23:30:04 -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 ffacd0b85a97d-48448eeabbfsm3927968f8f.31.2026.09.01.23.30.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:30:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330604; x=1788935404; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=ZQgf6lhFc6DJzEwMjaZidYZkmvOwmEo5c6f5ck/LBtM=; b=HjFAPo0V5Cqc2z++ovb14Ozo+YwE0ebrDYC9x2AgeOSLB5y/dD8K0apw0VtpcRJJZl LOdw30iHopivlHFJflgojAVX9nUIgvtvyhrwR7kIT/HhIKK1joJMcWUP6XgILb+O0YCY XFSxUxz08cGjp9pTn+fas9KliZYvw2WUMrdsuD86yWNxhnCUyGhBjQL6MNTcYy1tECOf wzJDST0EmiXhkB3DX1BmssgxrSsgLkUSauW6GX/ROM7zOUzCC3vuw5YYmXjClxYMxNbB 3iatNPgPlbnn5/N+IMabVDIP/T9VvxWCC5beeMiCmx/pcKKJ6zU8EUqssNXjNvqptEQr lx+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330604; x=1788935404; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ZQgf6lhFc6DJzEwMjaZidYZkmvOwmEo5c6f5ck/LBtM=; b=p8X3RDUujGPH3IBKT72c4hF/9m4L/srJDNbC/Bq9u3qPo55Sb00bOUhxqC2GzO48qU HywKLM4wGaSkDxVYRlo5mvN703csBDPfs62c5jLVl24jNYHtNRTLhGXjApSyhVzzXqeR UVGGcXv78HIOwrXvTZS0ttnBr+REW8T/y31JLiPjyiRJ1wLz9XcMiyPrXaAKIu1QIKjt 03Pj9Hr7268yeaiGsNdqtCXkoxoV0N+2zjxLycL/Fb9C/J02sqlT1JjnWCu3Fx1FZig2 d/yYl+w+Gw9hYY/cmrNhSGjCd1X/+gdHMSzY8b68hnbEXRZrrxRwNDagjbA42OPuztrp qwTQ== X-Gm-Message-State: AFuF++nPvj1JOTF9IaTl2RrJJF5yA46ys2TQSKohGUtVP54+idil2bC8 aPo99u2bWVpF4K7wRt6W0LPw0gFrHKAKD1bqzH8pZF1R1vL8zezMtYkRiPiuAEFD9wELE3Q0cw9 dXbfYEg== X-Gm-Gg: AYBFou2pcEvVowXuNf7GeE4Ci86EeeJo7kKxbBGLHBxzsA29sUaM9IVcQolcpU5z1xD 5CCd3SCOTbx0403sS0hWCVxU6ZrK/Afhg2r/l9/sbOgE6jQUKVdwq9cKYYKTd/Nz5YgrOoXWSpS ldjS8Gfk3WZA6YcJbYLg9lRQX9rsljOPFv8pJpm4o8Uar8HSbIhx40FIjSQVIbO1ylry2oCsg6N QaWNHt+ALHiDfN1KhU4jrn16440udz1GXUf4RzSjos0namzBpFAHLGVKYKcUyPP65I5SNeuehm9 l+B5wW9c8cBe6CINr8ZDOu3MsGLookZZB+bpEjSdP/FVxzG4NYOBpncnDr0gC8AD7APkFwG7wI4 71dKaikpCwMk3oD9rGxkRh5byexdfiZxxirxXihthSx2AvF6gvMzFol1U7w8xYUfS8iUNhP3XRH SUMJMW4VrvbS+qlbdyiTqqoelu1CsZeovnYBdGl96bHkMBKGo8uP2J0JWCfOdce4Au9gOx0jNvB TbYeET1KKk0Lz8Rnj4TajceDubF1g/Q9EoAs8vBxa5jwhHrE8x5 X-Received: by 2002:a05:6000:2481:b0:484:3310:710b with SMTP id ffacd0b85a97d-484913bf064mr3621318f8f.23.1788330603979; Tue, 01 Sep 2026 23:30:03 -0700 (PDT) Message-ID: <12d3f4cc-e3c3-4f2a-a791-724271473fb9@suse.com> Date: Wed, 2 Sep 2026 08:30:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 01/14] lib: obey to Misra rule 11.8 where possible From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788330604-F7ABF2A1-2BB4FCD4/0/0 X-purgate-type: clean X-purgate-size: 2637 Casting away const-ness (or volatile-ness) is never a good idea, but some library functions (e.g. strchr()) require doing so. Where not required, remove / replace respective casts. While there convert touched functions to Xen style. No functional change intended. Signed-off-by: Jan Beulich --- a/xen/lib/memcpy.c +++ b/xen/lib/memcpy.c @@ -15,12 +15,13 @@ */ void *(memcpy)(void *dest, const void *src, size_t n) { - char *tmp = (char *) dest, *s = (char *) src; + char *tmp = dest; + const char *s = src; - while (n--) - *tmp++ = *s++; + while ( n-- ) + *tmp++ = *s++; - return dest; + return dest; } /* --- a/xen/lib/memmove.c +++ b/xen/lib/memmove.c @@ -14,21 +14,25 @@ */ void *(memmove)(void *dest, const void *src, size_t n) { - char *tmp, *s; + char *tmp; + const char *s; - if (dest <= src) { - tmp = (char *) dest; - s = (char *) src; - while (n--) - *tmp++ = *s++; - } else { - tmp = (char *) dest + n; - s = (char *) src + n; - while (n--) - *--tmp = *--s; - } + if ( dest <= src ) + { + tmp = dest; + s = src; + while ( n-- ) + *tmp++ = *s++; + } + else + { + tmp = dest + n; + s = src + n; + while ( n-- ) + *--tmp = *--s; + } - return dest; + return dest; } /* --- a/xen/lib/strcmp.c +++ b/xen/lib/strcmp.c @@ -11,16 +11,15 @@ */ int (strcmp)(const char *cs, const char *ct) { - unsigned char *csu = (unsigned char *)cs; - unsigned char *ctu = (unsigned char *)ct; - int res; + const unsigned char *csu = (const void *)cs; + const unsigned char *ctu = (const void *)ct; + int res; - while (1) { - if ((res = *csu - *ctu++) != 0 || !*csu++) - break; - } + for ( ; ; ) + if ( (res = *csu - *ctu++) != 0 || !*csu++ ) + break; - return res; + return res; } /* --- a/xen/lib/strncmp.c +++ b/xen/lib/strncmp.c @@ -12,17 +12,18 @@ */ int (strncmp)(const char *cs, const char *ct, size_t count) { - unsigned char *csu = (unsigned char *)cs; - unsigned char *ctu = (unsigned char *)ct; - int res = 0; + const unsigned char *csu = (const void *)cs; + const unsigned char *ctu = (const void *)ct; + int res = 0; - while (count) { - if ((res = *csu - *ctu++) != 0 || !*csu++) - break; - count--; - } + while ( count ) + { + if ( (res = *csu - *ctu++) != 0 || !*csu++ ) + break; + count--; + } - return res; + return res; } /* From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:30:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:30:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405043.1638586 (Exim 4.92) (envelope-from ) id 1x1eUo-0002w0-HC; Wed, 02 Sep 2026 06:30:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405043.1638586; Wed, 02 Sep 2026 06:30:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eUo-0002vt-E2; Wed, 02 Sep 2026 06:30:54 +0000 Received: by outflank-mailman (input) for mailman id 1405043; Wed, 02 Sep 2026 06:30:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eUm-0002vj-Bf for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:30:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eUl-00Ggy9-Fb for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:30:51 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c290-2eae-0a2a0a5409dd-0a2a450699c6-30 for ; Wed, 02 Sep 2026 08:30:51 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c29a-195a-0a2a45060019-d155802be072-3 for ; Wed, 02 Sep 2026 08:30:50 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49b8e527d63so7088265e9.2 for ; Tue, 01 Sep 2026 23:30:50 -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-49ce3c86a0asm52736995e9.9.2026.09.01.23.30.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:30:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330650; x=1788935450; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=qf1WHuiH8vY+yMHFbjVMhDzcKdeDFrIIHvK/5ttVZtM=; b=GgpnU+GOAc7XNBjE1/l3VujYHF/KfyE3DMnjUe5/M3LM2bsj3ap6JA+0cyP/JzThpE ChTXaoU+Ao68lxE7we7YkR6XkncXutHyQR3LDPXwNMMtAkMVzZ9MQd1BVBbqMhymCIEs lfNu1hUhb2widIkj5kvnCLg4d936fGKX4kw5X47alUaq3vZLx/+3ap1c9bAg7Xymxpbd 6alEEc+jKDa44fVyb7XIKwIKEMkY5Kao4HoKtXqqtJt6QBDPkFNOAqEBeljXKFeWGyDN 7hYdtEZHxfaK4fdO8Rtqp7oc9/FWMHjnbsSDpVYW7pQq7pEUzvZCr0729Xqc2/TkZkrC p0yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330650; x=1788935450; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=qf1WHuiH8vY+yMHFbjVMhDzcKdeDFrIIHvK/5ttVZtM=; b=fGBjn1DnLplY7I+WbaH0NWeiNSs6NbMVNmshWdOW4YhrurekFsmp9Rx+xSo5VqDHE5 LAKaR7Tft1UUpBlKX+MPjwWpEsWxWBYZaxckVR+pU+hWwrm4pIE1JqF+Ht6/3QRuSvA1 RUjI60nkT8bmd3k2tthNuaqdI3hvUpdgAwSdGgS0uC4the7h1BvD5SHqPcFl8MpQ+L4A o/Y13+Q352gEvM85O+C/v1Smxc3yjMux91nzaX98Fn4W0PiTgGPtiZMQZdFtXhl7gaBV 6qRnqiZmPOFggGhS1lHFSVAImDh3YVrc5/rAOUWNFUzk32CDHdolSUwLVASxz7esBlbh giCA== X-Gm-Message-State: AFuF++mG8/3p7N8p2j3b5Mn4ng8ErBn3faVKwygXR3CSl6FTKXX5+tcg Lnk2vH0rXZDdl0R6efSfXDNiVA9DBwDPXC39eBrRvkJXXWAcDzd3z0M3Yv7TqurDh2wGWlrIcQH iVLdJqQ== X-Gm-Gg: AR+sD10L3d+rnDnI2+OdGGKTr6kv6PriyN9R7+15eB8shiLBPH13wChJYtQ3g85fHy9 ObJcCNlB+NnY3xyL5U0iTqTb/TA1if968HdLRyv+Zw5J9MesiIAhEX2fcGrDLpP+rQKaPDGMj8B w6RqiN0MDH/6e67tm4aQXmcmFT9Q2Kw3bhsO/x52wH5XXKIc5gu+ZsFqe/oIf7qiyIg5TnE9EEs r2zhS5FvFdujfGoe5SL59wAfQy3UcmCTpnnZRFMIt5PQPSNXJBt1mPyakuWilMc/EfKeH3G2wbB suetf6hK3ndwJc7gdUUQIhgV8rt2NgMRHogaF2efm5RQaxTgfn+b7c2GMmcFDydAytiynQO6i5M 1YVx0/hhszF3j4raByv4ptP806OHx9TNkYEMO4VCv8lUCDkj2WHkUu1FQnj9YgGcuVX9dOYfF5v 3ZcGRFcvss2hQ9vr9tggdZyNbFJo+NOsOAd3k0wB1RTVj9rcDHSV9AIsCq9EQEqXqIH/dN19+pX 5JNTXTQbR4SD/Pv51W3vd3MVkTKRbA7w7q1z3mJn6WJT+k9YpJY X-Received: by 2002:a05:600c:3494:b0:49b:9202:6f80 with SMTP id 5b1f17b1804b1-49ce57ee273mr44721865e9.6.1788330650419; Tue, 01 Sep 2026 23:30:50 -0700 (PDT) Message-ID: <75bd486e-054d-45f4-93b7-800b0ddb21f1@suse.com> Date: Wed, 2 Sep 2026 08:30:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 02/14] x86/bitops: don't cast away volatile-ness From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Oleksii Kurochko References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788330650-F5E0E77B-1CCCFC9C/0/0 X-purgate-type: clean X-purgate-size: 1626 Doing so, besides being a bad idea in general, violates Misra rule 11.8. Use the helper macro we have available anyway. No functional change intended. Fixes: f1879b2c2584 ("xen: introduce generic non-atomic test_*bit()") Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/bitops.h +++ b/xen/arch/x86/include/asm/bitops.h @@ -188,7 +188,7 @@ static inline int arch__test_and_set_bit asm volatile ( "btsl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (*(int *)addr) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (ADDR) : [nr] "Ir" (nr) : "memory" ); return oldbit; } @@ -234,7 +234,7 @@ static inline int arch__test_and_clear_b asm volatile ( "btrl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (*(int *)addr) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (ADDR) : [nr] "Ir" (nr) : "memory" ); return oldbit; } @@ -248,7 +248,7 @@ static inline int arch__test_and_change_ asm volatile ( "btcl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (*(int *)addr) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (ADDR) : [nr] "Ir" (nr) : "memory" ); return oldbit; } From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:31:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:31:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405049.1638595 (Exim 4.92) (envelope-from ) id 1x1eVJ-0003NV-OF; Wed, 02 Sep 2026 06:31:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405049.1638595; Wed, 02 Sep 2026 06:31:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eVJ-0003NK-L4; Wed, 02 Sep 2026 06:31:25 +0000 Received: by outflank-mailman (input) for mailman id 1405049; Wed, 02 Sep 2026 06:31:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eVI-0003NA-Pj for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:31:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eVI-001cWT-6N for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:31:24 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c2bb-bab6-0a2a0a5309dd-0a2a4509c0ec-4 for ; Wed, 02 Sep 2026 08:31:24 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c2bb-be1a-0a2a45090019-d155802fe8b3-3 for ; Wed, 02 Sep 2026 08:31:24 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49b8be0409fso4122485e9.2 for ; Tue, 01 Sep 2026 23:31:24 -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-49ce58da3acsm62073415e9.0.2026.09.01.23.31.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:31:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330683; x=1788935483; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=AW5Js8HSLcZBr8DQXofVW/feqCltoKGq3ct/AKTu4nA=; b=OYwFPJtVTnD39CnaVinmfV0sE+tMZJgnBJrilCrdL/5a13vN7TQhgLY/+Rfl3dg+7e sIAK7Zclgw2buPEOAoGydo9B4BbIE2es8QAQBAyYHbXcskdX6FkyZxi+MPmNP5PoBQ9+ xZYiDGW/jsrigsfl/ZRmCxcflaiBXPvZwCOMEiFXNZ9yvqLdKiSeqz+5kuSW+qnaBcTG TfjCEs5w9/UM7VUjn/b8KsdxZV63FWewlFxBT15cbZOlzF9ctz3fOHXJsualqeUfmzBH +od510/RrccBGnGT167EMX+/NVp/X/B31atnoSGc9hGZfia4yOxy7RdQwEXnKNKmMf0D 9ZbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330683; x=1788935483; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=AW5Js8HSLcZBr8DQXofVW/feqCltoKGq3ct/AKTu4nA=; b=Wv5f2hvCyCFz9Xxb+dZNxTsqxtwCpz7KfQ+rgI/0r2VDps7V5+fiq43BOmOI7IkFjf mnnTCgVTWBybgHWABMmh959Hbz2AaPfhGdl5wjOYl9122LQIvNHQwDny9vEo/ANnOeAt quRhoPxNP6NnsxP3USuv8F0xVgwZx5bPhgdUXTrQOP9Sc815y43C1uP1NGEoF3xvlvoS JNx5XEhQ5KLYTge0oeC8As+vsQcxCO6E6arHfKzhWMxxVU6aXUn+cJq0pC9ObxK8nD3a 8ajdopanIbFAHHlaEG/NDXCdVCRirLUXDN1wA7v15/vnQXpU/TnkbGcea21orUCxuND/ ELkg== X-Gm-Message-State: AFuF++lWrT3+Gucw5UOlUy9BjYBNfTRzVAab6jskvKeWQZ7o9mOhO3Vk wWCe/rXKoTFzY8bM4JfUDqfvixGrso83Gf/uCDgnFq4a0rZNxy8LeEOqQHYTQRnvNYinDTCJvNK 605qwxg== X-Gm-Gg: AR+sD11Wj7e49vLeBj5qQ4Z3Xonog0n11/p9HMZ/PknUjPEU3wyIX5dl+4YwckUpGmH zW7+UFsCQo1zbTVMZXYJPPxiJcuI2VOdQo+bXLznfDzLjkQMxErvk3j+qxJ8tf3aQttUEKR32Pi H5RWO4y/NRlVaIe2VUZWgCwYF+r+bTA8qkSyWPhSVfNC4F5gQQzNpQBRg+tqMjqd5ypxkrmZKI4 U1Fr47vIT4OBPc7xO48KQszNV9xGxPEVYXBjNTUaVKQNWAOJSK/5JFIxhMCEXZE6a1oKLjl7pCB BQgEwoYWvaUFWau63g0prEiVuwCCP2Pl9aLcBos9sFPdzl+uN1C/G7qzRvQ5KEV0WUPyJ4kdgXQ EheEK6yuw88OuAzFOCAf9JBLef3efGHBxYpb4QT5UXTGNGal6zjcS/I0HaU7uNQ2/zJWTffePrU I17sOxOC9+xEZOX3gySIuWPEUQ67+9uLwVirE/YBdL8NeuKtIL/A3WRhJkCnKW2aD3m/pD14TfZ mdciCfbsgOY0rj9yRyvsOi65Hi5NtapR7alL0blrcbmd7aNV4YB X-Received: by 2002:a05:600c:4f0b:b0:493:bd2a:93be with SMTP id 5b1f17b1804b1-49ce581316dmr34390275e9.6.1788330683437; Tue, 01 Sep 2026 23:31:23 -0700 (PDT) Message-ID: <8ae3cc08-2011-4689-8530-f3b962ed4d72@suse.com> Date: Wed, 2 Sep 2026 08:31:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 03/14] x86: have cmpxchg16b() obey to Misra rule 11.8 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788330684-BFAD0034-4119CBBB/0/0 X-purgate-type: clean X-purgate-size: 762 Casting away const-ness (or volatile-ness) is never a good idea, and there's no need to in cmpxchg16b(). No functional change intended. Fixes: e0116acbbd0b ("x86: add cmpxchg16b support") Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/x86_64/system.h +++ b/xen/arch/x86/include/asm/x86_64/system.h @@ -56,7 +56,7 @@ static always_inline __uint128_t cmpxchg ASSERT(!((unsigned long)_p & 0xf)); \ BUILD_BUG_ON(sizeof(*(o)) != sizeof(__uint128_t)); \ BUILD_BUG_ON(sizeof(*(n)) != sizeof(__uint128_t)); \ - __cmpxchg16b(_p, (void *)(o), (void *)(n)); \ + __cmpxchg16b(_p, (const void *)(o), (const void *)(n));\ }) #endif /* __X86_64_SYSTEM_H__ */ From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:31:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:31:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405054.1638603 (Exim 4.92) (envelope-from ) id 1x1eVg-0003oo-VG; Wed, 02 Sep 2026 06:31:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405054.1638603; Wed, 02 Sep 2026 06:31:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eVg-0003oh-SS; Wed, 02 Sep 2026 06:31:48 +0000 Received: by outflank-mailman (input) for mailman id 1405054; Wed, 02 Sep 2026 06:31:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eVf-0003n2-GD for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:31:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eVe-00AIYQ-TA for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:31:46 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c2d2-8faa-0a2a0a5109dd-0a2a45069f90-0 for ; Wed, 02 Sep 2026 08:31:46 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c2d2-195a-0a2a45060019-d1558031b446-3 for ; Wed, 02 Sep 2026 08:31:46 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49b9320423cso6190745e9.0 for ; Tue, 01 Sep 2026 23:31:46 -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 ffacd0b85a97d-48448e72df2sm4531177f8f.1.2026.09.01.23.31.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:31:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330706; x=1788935506; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=SLQw4AZiW0xGo4eY+c2v6v3KWBjjDDtH8z6OZdHRa/4=; b=NPWsEPp9kIoikqvRgHzf3qgd3+AZd43HATQTrprd1mDHUGxxT/MBezdc5+YwNx+pmn FllsT9O+CYCOYjfpVvPBKf8RdjIw8BsOiKevObyNMbPxt3hpXCONF4m1/nh5N/QbOByt dLyZ8AcDoaeS3tcAELmIRqAgxgk8PtcPz6GSe8hIcDIZ0ZFlgaLsq6SAopteKxFirezK CeuJZC/fPDxJ9rO7oNu7po2OgrXjj5V7WSkBq1YdOUZ9xyt4OmqPhBa8zN01uo5Gq5Tf 0fiXe7pBFKavR535aNBvie+sgK27SM7IaLqZ7e4jAdWeSho2+nu07K/JJktESH6HPzof D5lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330706; x=1788935506; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=SLQw4AZiW0xGo4eY+c2v6v3KWBjjDDtH8z6OZdHRa/4=; b=Prt+3R/8Bs9oCBLWqMuWTXw5f3O5uEf6eT1hxD/GhAmJFsFee7w3+H/zAexaSQKWvl HvEEV1lyRmtpDZXfJcMepfI5ZHSxVeBYDFb8a+z9sYRxL9nnSIH1nOKVWrid5ql+6arG m/0W3jKyNR2ctGuYj967aJVAWPuWjfKrrYNq3T4axI64wz37nB7EpygE/E7/o9uA9PTf hoPlwNoqbIjvNyJgOvy4eZUpBDnj0vrOpHWSal4i+yiCRH8eSLfluW2yR//Dr07P7ZDA UwasxMV0stYyGoElj26/pI6otqkM0mrL0gz/PCuS9RHgu8BRMZSfnTTXD36QiEKAqYHi l3Zw== X-Gm-Message-State: AFuF++m6MGuBZWVOYtlMx8A0Nr+paHDI7FfHz2X5DZYEzIHx/1BUm6nv qs0db29/wOQmZnf3HdbyxXP6Dkqp3+VPWzLqU3NBW5EGsnG/eqjPmlv5YtRcAPybQwGzxB8oCaO /YFxLFg== X-Gm-Gg: AR+sD11uMm07MquNZ3Zb5dPPfUFaQSVor9mDwmuMEoiCbunLglvDnoxycLZ7G7r2xFC euklJYYuEbDTalSI05L8Do/W6uos6U48R4OBs3K1VmkpB+FfWtRectmyCUIE6hmqhwes4ZMl/fV 8sgTE70owWzT3we2H3Uc5vI/9YCney5izk/A58l41gBUU0Mtd71qnPCUZb8052PaRnRCogfgnQS PjIizIWdp0AC9CaoSKzU6qTABwaWh4gcQlmi6mOihvxKKNTWkt9IBm0VB5SwUSQ6XM9qYmHMErj +81Vzm0/YiDsCSD84nIzGPT7IJCkypPC+uTn3rP345EDv8YOjka40XjYWqeIrpmkuH8zWIdtgt3 MurfC5Q5qbcAT4AG2jIs9Flg7MVoxwd0gtPsZ305ZJTPgO+/CI/dCCWiuwM4ci5eZGtTML/d87v EFuB0LpST939jTH/7XO9Owww20n6a2b1HDm4QlKvZSkmbqnJzGU9izHQ7eYMsEwsRR9ejk7Ge3c VUVLPvffTpCvzfEGcePY4pKIBw1r7JfZ9ls8JJfuLTEuG/qXido X-Received: by 2002:a05:600c:8b05:b0:498:943:ccc0 with SMTP id 5b1f17b1804b1-49ce5817bfemr48720775e9.6.1788330706300; Tue, 01 Sep 2026 23:31:46 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 08:31:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 04/14] x86/boot: don't cast away const-ness From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788330706-F540B77B-DCC2F386/0/0 X-purgate-type: clean X-purgate-size: 636 While the general C library strchr() has to do so, the early boot cmdline parsing has no such requirement. No functional change. Signed-off-by: Jan Beulich --- a/xen/arch/x86/boot/cmdline.c +++ b/xen/arch/x86/boot/cmdline.c @@ -77,12 +77,12 @@ static int strncmp(const char *cs, const return 0; } -static char *strchr(const char *s, int c) +static const char *strchr(const char *s, int c) { for ( ; *s != (char)c; ++s ) if ( *s == '\0' ) return NULL; - return (char *)s; + return s; } static size_t strspn(const char *s, const char *accept) From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:32:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:32:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405061.1638614 (Exim 4.92) (envelope-from ) id 1x1eW5-0004H3-7a; Wed, 02 Sep 2026 06:32:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405061.1638614; Wed, 02 Sep 2026 06:32:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eW5-0004Gw-3j; Wed, 02 Sep 2026 06:32:13 +0000 Received: by outflank-mailman (input) for mailman id 1405061; Wed, 02 Sep 2026 06:32:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eW4-0004FT-4K for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:32:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eW3-00AInw-HT for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:32:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c2e0-e002-0a2a0a5209dd-0a2a4502cee8-32 for ; Wed, 02 Sep 2026 08:32:11 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c2eb-6ca4-0a2a45020019-d155dd30a9d2-3 for ; Wed, 02 Sep 2026 08:32:11 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48442ea8f59so1150042f8f.1 for ; Tue, 01 Sep 2026 23:32:11 -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-49ce465161esm42964185e9.7.2026.09.01.23.32.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:32:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330731; x=1788935531; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=FvD5+PYIvbWZ0qVpbaejKHF0dEio4ri6He7uleHAJAs=; b=cOrB3LDLIQKfNA1Si+o8g1wKNIur0lQGT4z6h5+wnI+g+a3+8IHyI9nylKTWK0IDlI 6ITfuEY+CiJ9muMtXlcgskcDuX1jviMgJS23H0oTBoHm7uvYn/BNN6IrTpduDQbxZZaN m1A95AstT4jdrhzyj+QBawJouVG61j2NGGl8uDhImoEM29ue0Xa/QdfPABb1P/2AO1Bu 24wYB34wmYwAhZW1F7y7PlvMif7Nai/noU6Ce4VOxUlXChYac9sV9+9E4mJxSc/tm07k ClDvLsjuo+FYs7Du2vVqy5NzC0Pdoi3SG0KmGYuwTMhSGwW0IbYu4VxUJtAq/nsnzPQb g4tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330731; x=1788935531; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=FvD5+PYIvbWZ0qVpbaejKHF0dEio4ri6He7uleHAJAs=; b=nl5wj9lWcygNCK6ES3J2nIKX5niozLVEZ7zrh/lcgwMefA3N5pR5F3eMjUJBkMDFz6 Bhjo1i70FW52/O5Ur0x+pVC5lNqvh4bBQQaLGAAA7M2vBJPc9LA1oRZXh73ijlngQQra mHMWMT9ReeDdhOgLHoSh7bo2n1B+Ra5u+dwkVjaeG+90V33B9d+Odc7HQVhda2N7Mzko Dm6aYVrAzBo77gJI/7vjFTI+PA6DDkP+LR3HlErU1ML9GfxxbInSUGQ+Gn4gMPbUvA7q ae6PSawodMF60c92DjQ5iG6sT2nuArGJDljjpJxzlBt28MQZynaRqxopvoOFR6rmtjMr yrNQ== X-Gm-Message-State: AFuF++kjZtjYVR5H0agv834UEpWfumanViYYIxzQGfVuhxIP7nZE4+Rn rWLMPpAefzi1bDmZoSReck648sUeiXJiG5+11X3Kff6RPhGfaKqjDp1WTSz33H0HHUKDkB+O+QG mtN5WOg== X-Gm-Gg: AR+sD120NmgWi/3/TL2bK26qrcdLTkuzd+WDZh44BH6UTih2xYWiOJo55Oz7VQsufgq 7Qi2lC3pqSeZg5ZnCh+0P/AHjTflzUvFmVH1Ll56L6HYZsUTmVDS8qkA8IPU4J6sPS1dwmcZbnY f5VXj9KoWxWB+8nhyGogZRi5KfvtMOyftiS5NX9HoqU9phjR5XrycRSUuovrhRuyWYyC7l7ONQO xbutGSwq6e4AI2HT5ytVuu2hx+UdWuQh8aaxXWIrSE0qKbrfS+iZPS9gVK4vc5L6FcscIUBXOB5 NB6KetYDpR6l7TGvSniY0NMEQnahPsHOOKlbwhZzn/7C90bwV3d1rMC65xGaQJttHOY+U507oqQ tFJKmf+8IVvT7ODHm/wG9Ghhzg/2z5Zmpv2a9r+x+4DAb3KRgSh2Tf1cm0+5OajqY3PWWpjMlbB aMA155n9ekSI8E41VO7unKs8g6uyhkpi2Yk8pvJI38oSvO2qMQQAl6W3STSRGW9bwOApLrCjy0h NKUWy/etWwWOc4psZD2RmJx/DJDCXubrrtL1PhwtFrSkGgof6UW0Ecm7OebZ+g= X-Received: by 2002:a05:600c:1553:b0:493:f783:c46a with SMTP id 5b1f17b1804b1-49ce7c27099mr9377965e9.6.1788330731001; Tue, 01 Sep 2026 23:32:11 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 08:32:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 05/14] x86/altcall: hide casting away of const From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788330731-F30B02AC-19CA4EFC/0/0 X-purgate-type: clean X-purgate-size: 665 ALT_CALL_PTR() really means to get rid of const (when necessary, i.e. when used from apply_alt_calls()): We want to patch the original call site, after all, and memory-wise that's unrelated to the struct alt_call * that we start from. No functional change intended. Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/alternative-call.h +++ b/xen/arch/x86/include/asm/alternative-call.h @@ -9,7 +9,7 @@ struct alt_call { int32_t offset; }; -#define ALT_CALL_PTR(a) ((void *)&(a)->offset + (a)->offset) +#define ALT_CALL_PTR(a) ((void *)((long)&(a)->offset + (a)->offset)) #define ALT_CALL_LEN(a) (6) /* From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:32:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:32:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405069.1638621 (Exim 4.92) (envelope-from ) id 1x1eWZ-0004qr-Gk; Wed, 02 Sep 2026 06:32:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405069.1638621; Wed, 02 Sep 2026 06:32:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eWZ-0004qk-Dt; Wed, 02 Sep 2026 06:32:43 +0000 Received: by outflank-mailman (input) for mailman id 1405069; Wed, 02 Sep 2026 06:32:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eWX-0004qP-QZ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:32:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eWX-002tla-7C for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:32:41 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c306-8faa-0a2a0a5109dd-0a2a4506a4e0-6 for ; Wed, 02 Sep 2026 08:32:41 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c309-195a-0a2a45060019-d1558035c902-3 for ; Wed, 02 Sep 2026 08:32:41 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49ccfbe062eso5068835e9.3 for ; Tue, 01 Sep 2026 23:32:41 -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-49cdce10153sm133662375e9.4.2026.09.01.23.32.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:32:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330761; x=1788935561; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=IXAvx/vGULUwovSlnrWpyko7JV6p7KauR+GTHkHN/Os=; b=AeQ0noWdemhT3u5hnP8uNsQmTRQNA0jvndZJUqa95uWoE0IKNkdkMkbrl8jap227Ec 4eNaHGlrwuvSgGcuNZjvV5o4koLAtf9nJwKJGtJTcrsAcNs2a7aZAQ8pFsfkefOJCngq 9+UudeC9Rx7mTzLaY03qofA/Rk5j7mkByiw6cDVpVZnfXV8zeD6BfeeMtH3EpKZZOexD gA5wG/Ye7ElhTyQlbyt4YQyCXetqCduf3uQF29zeNlY1c4fFnXR2/Vm87f+GeucQa3v9 RFhMaPA62di6CdzWxkdFC8JWmIusfEdjSj1l0Vzgzk7V0h7iJrP07dzJFNqEBRD2bJO9 SXVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330761; x=1788935561; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=IXAvx/vGULUwovSlnrWpyko7JV6p7KauR+GTHkHN/Os=; b=RVOM43Zg6jDF/UJgBCHXlRaCzFj7iny7BNmKmtWE1lho8s0xr3/UFy7NE+TimXHAU7 oHieXZ75P97+Q0u6VWhp8QKJIx4KhiIemYjBcDpz5MQruslLtQXJhBmzQfmXteur/urv B6+xcx14nWJ7LlPtjQJ/Cj9OoMOTid9eK9la0f3opzIiubdDvBycpMSLrrcKpacGUxNm LUgzwLp2vOLdX2RvRTfT7NBCZhYWJXC40cKszj7UyQnEs7HzLnQwpFAL9Ip3LyWIKMMl LmxtkRdOVti48QF6RgUAfUSpD23eGka6Q3ths7BefESzbtSZFPF0VZMtbFxhT5+Xcgbg q2zg== X-Gm-Message-State: AFuF++n/vBOSSTYeQRDUNATcWBmj0R+tOS1YmVtFhCPMejHqALGot+Yg sqbRXvT2EckiWdMgKSPOXYTc7cezOq4ONWVyzQYJ2PAOfTgD0Y3oI7d1DAx6SEDZyi0/v3RhLok MIsSBew== X-Gm-Gg: AR+sD13+n9qD1HRRS2zIEvrdnDWKn2lhJMkNRjJhiK/QNHhdlrFNTwdthGfGVW0jiJM 70dSXbmrJKSlqCgaACAOqzLbZxBRj8bnCNYf8oNuAGMrsNUfz2AgfVLj3x8mNTYZKcRTg0Nn7qL A0wg85wO2Dk2V2kM24RuN0vfKYRslULru8NBo4H94XJM/Xa4zO616kESLK+eIplDykyS5Z9HWRU 01iQucBY6/nLQadfmgOt/JY7gYS3LEdVphp+Ze1gKPluqDInWNBlJIYz0JAoa7qFt01e0ccABaT pSVuu0hNqyKhjWtYBcU7/WqNC4IW0S6nbMUDSpHWczYip5vbuFbcsMoqW6ASNErDPWzoHlVjBT3 iip5kR5qGh5FeHWl8vXtwxoJWO/TJXZT8Z4jfL2lhnQMq9vZ+gLMt3dy86EOYcJS1GszlG6YgqW 0ApX8QPPJA2pw7k8nqD3HEYZJNEZFOzpKrXXxAqPqMjIYj5uhEBfXQkG3dpUGZy3xn4+MAoUzdo VhbF0J+HqHNp31JY7w2psMpVhh5EzC8vBXJY+lpOkIr5HURiipG X-Received: by 2002:a05:600c:3496:b0:493:f5bf:4dc6 with SMTP id 5b1f17b1804b1-49ce57fb12cmr43745825e9.7.1788330760666; Tue, 01 Sep 2026 23:32:40 -0700 (PDT) Message-ID: <6b3a3849-304f-423b-a3c3-a614d83858c0@suse.com> Date: Wed, 2 Sep 2026 08:32:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 06/14] Arm/alternative: hide casting away of const From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788330761-F4A0477B-1DF2EDA4/0/0 X-purgate-type: clean X-purgate-size: 608 We want to patch the original call site, which memory-wise is unrelated to the struct alt_instr * that we start from. No functional change intended. Signed-off-by: Jan Beulich --- a/xen/arch/arm/alternative.c +++ b/xen/arch/arm/alternative.c @@ -134,7 +134,7 @@ static int __apply_alternatives(const st BUG_ON(alt->repl_len != alt->orig_len); origptr = ALT_ORIG_PTR(alt); - updptr = (void *)origptr + update_offset; + updptr = (void *)(long)origptr + update_offset; nr_inst = alt->orig_len / ARCH_PATCH_INSN_SIZE; From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:33:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:33:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405080.1638630 (Exim 4.92) (envelope-from ) id 1x1eXK-0005Ok-OQ; Wed, 02 Sep 2026 06:33:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405080.1638630; Wed, 02 Sep 2026 06:33:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eXK-0005Od-LY; Wed, 02 Sep 2026 06:33:30 +0000 Received: by outflank-mailman (input) for mailman id 1405080; Wed, 02 Sep 2026 06:33:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eXJ-0005OJ-8t for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:33:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eXI-00Dz70-Lt for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:33:28 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c32f-8faa-0a2a0a5109dd-0a2a4505b27c-40 for ; Wed, 02 Sep 2026 08:33:28 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c338-4cb1-0a2a45050019-d155dd2cc938-3 for ; Wed, 02 Sep 2026 08:33:28 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48441fa5c37so458406f8f.3 for ; Tue, 01 Sep 2026 23:33:28 -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 ffacd0b85a97d-48448ed3840sm4273883f8f.17.2026.09.01.23.33.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:33:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330808; x=1788935608; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=WsE0cG49Spb40SlFjalUjfTBIhzgLgv1Lpzf0EskD3A=; b=bncEFbrULAX+rhh1SgplJfQJL5Yi14V2s+AbU/sPS9KCcn7fRzoiDiUxgPSRAPtbEq IcHO+CL0OGYxn4QlDU5VySq0Fh6j8pVfxpc5CYV0Ao2tlIrAlSbNOag9grN6zeqC6YQy NPLGX1v/0owfqLAOJ6b2fezyre1BRnBHTwF0F+IbPIhJ4Tublx0eyMJZEEhnxV19QoVi bt90QvcJaIHFWf6/NQmtvmiD/6Q5yEXYUjaHA9TexufiymBSNq3Nxk+wX8iHqpDbwg79 If8sU2nNFNJ9gFZUuDog4Nh9yH5B/zEvHTGwOAL4UI8uTvGmzCTZAlMzjoxajA88bm1d K4NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330808; x=1788935608; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=WsE0cG49Spb40SlFjalUjfTBIhzgLgv1Lpzf0EskD3A=; b=rn1E15sG//lABz87voUoQecytkhIdocNQNOhejH/fQ5aVt9RbMdsNHpCR+MKIpGz5r e+wOjCFYhSakW8Qo5NKUINbKxywFG3MzI6qgUsMvzt/FBrtfTfAyTlYj6JIJK9kjp8+6 /iSvwQ8tIZhR3S3KxVAIzFvsc+K7L6byp4mHSsHmWJYUrXMNNhplL23oCEkkn7bG1jdM 3gy3EWdf1rkpZAeu5zUKNEevjaFYpcbh2XCaIJkHCq3zfNXrVGCI3z4umaCAoWIJ3n8q HRMXXDm2PKs9nhiuXwSj3FgvuQLC7MfpFFl5uYlzf12P3C+3Lojh/GGKXnMdKp2QOyYA 4MaA== X-Gm-Message-State: AFuF++l+gCaB+Uy8fEfeZ7qgvdL5TI8AkjRV1/rYS3jDtlwiXSHbdUum 4f7vtA1IMjzrDLql9RgfLoddyP00dc7tP8MvlMRw3jBuVECZ334J9hHWGVrL9XZwbo/DWI71x3u SKSN+OQ== X-Gm-Gg: AYBFou08LwOXqLuCaUjrJRWnUSu3++L1L7Iz/AGSLR6UrlFsVFe8j3iYyj2GH9oYz08 9wwpTUmwSzMzxMaUB02pMIrOIKiew/XEwBTShPW/AqeJdei68L81LrBFP3sAz5RKBDZ2+16h52o YWV3MZq4pE+73aDT+L7L6Y9wLMrLEBwlk+eNxyrKJRnuRUuSU2VjHjwBUSuHlgJw95gUpd353+/ B8XnUDHsJ02aHsw+uh9Uw+L1BbF5L67/XhB2vNUQli+XA1ZjvccWEouMOO0+YI+xb6hHSNzgSkZ KKGl3aV0IJyzO1sLmGjgBjY0NSMyb3XyR04t4vYjMI80SprD76qunA7CKLg0AVnvcWPZnYvcvHn 9UM7nYGe+nYULrro6aIBWQvAdll+PRH2lvo+nzH3ip2bz67+3PsqucWIgbgvBkpmuBrVGQJpP3W MoZxDLSxEr/xp4amgGgJbRoA0RokegXKqeU5eYNJgKQlU8xcMiI/3m3fktbz5GU+4zRawwmDKnB bSfzs8RLf0GpuuJuoFNGp/19LCRJbXmJ1Mc2jrTrzs+Rh9H/hmSFHIYFwX/pB0= X-Received: by 2002:adf:e18c:0:b0:484:41f5:5b0a with SMTP id ffacd0b85a97d-484914c1a64mr4079727f8f.28.1788330808052; Tue, 01 Sep 2026 23:33:28 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 08:33:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 08/14] Arm/guestcopy: deviate copy_guest() uses just like their x86 counterparts From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788330808-F56AD2A1-71FE91D4/0/0 X-purgate-type: clean X-purgate-size: 2262 Like x86/HVM's __hvm_copy(), Arm's copy_guest() is used for both to-guest and from-guest copying. Naturally in the latter case the hypervisor buffer needs writing to, hence the function parameter cannot be pointer-to-const. No functional change intended. Signed-off-by: Jan Beulich --- Of course for both the pre-existing x86 deviation and the new Arm one it might be more robust if the deviation was also limited to the respective source file. Can this be expressed together with the needed regex? --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -433,6 +433,12 @@ Fixing this violation would require to i -config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"} -doc_end +-doc_begin="Function copy_guest() in xen/arch/arm/guestcopy.c is a double-use +function, where the parameter needs to not be const because it can be set for +write or not" +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*copy_guest.*COPY_to_guest doesn't modify.*$)))"} +-doc_end + -doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use function, where the parameter needs to not be const because it can be set for write or not" --- a/xen/arch/arm/guestcopy.c +++ b/xen/arch/arm/guestcopy.c @@ -109,14 +109,16 @@ static unsigned long copy_guest(void *bu unsigned long raw_copy_to_guest(void *to, const void *from, unsigned int len) { - return copy_guest((void *)from, (vaddr_t)to, len, - GVA_INFO(current), COPY_to_guest | COPY_linear); + return copy_guest((void *)from, /* COPY_to_guest doesn't modify */ + (vaddr_t)to, len, GVA_INFO(current), + COPY_to_guest | COPY_linear); } unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from, unsigned int len) { - return copy_guest((void *)from, (vaddr_t)to, len, GVA_INFO(current), + return copy_guest((void *)from, /* COPY_to_guest doesn't modify */ + (vaddr_t)to, len, GVA_INFO(current), COPY_to_guest | COPY_flush_dcache | COPY_linear); } From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:34:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:34:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405086.1638639 (Exim 4.92) (envelope-from ) id 1x1eY1-0005sI-0Q; Wed, 02 Sep 2026 06:34:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405086.1638639; Wed, 02 Sep 2026 06:34:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eY0-0005sB-U9; Wed, 02 Sep 2026 06:34:12 +0000 Received: by outflank-mailman (input) for mailman id 1405086; Wed, 02 Sep 2026 06:34:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eXz-0005s1-Lp for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:34:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eXy-005yX5-Uv for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:34:10 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c35d-2eae-0a2a0a5409dd-0a2a45038600-26 for ; Wed, 02 Sep 2026 08:34:10 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c362-fae8-0a2a45030019-d1558031d141-3 for ; Wed, 02 Sep 2026 08:34:10 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4995b0343c1so6587415e9.3 for ; Tue, 01 Sep 2026 23:34:10 -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 ffacd0b85a97d-48448e72df2sm4547374f8f.1.2026.09.01.23.34.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:34:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330850; x=1788935650; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=24jTXd7IeCDXlRGfWEqjcNP/1rsnFx4k/2yK1e1bOdo=; b=XiNITGlNNMzwI9V4myjEXTeVytpYgVBGDf8wNIEA3MP9Q6G9oqV/xN0czzAQzw1279 5zKhXPOkygQpEEnLbiH9s6iPRsNW6g5e8doaMZwdkeTnAlXNhW4dgPcYQuIAI86/APEP BwFQ5lMgg4dCdTyk5r9MPTeCPFmTbz5N9c5zDdB+UsyFolJBf1OOoCMHZgLI/0lNN8XA ULyj7FuFmf90OSWCimahWPuqNlQ0u0hCwoSWta5EHv065+2//SWv3jU905fIkfKOQk+S +tmbBeA7LCYeQN6sUi/tMrvr0gd4MkW7CHeSR7ht3AdQh8ibtJy9ku2pFefvoaRImXTY /v2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330850; x=1788935650; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=24jTXd7IeCDXlRGfWEqjcNP/1rsnFx4k/2yK1e1bOdo=; b=jdbVrp3kotS7d0z+pGnkxxeFOsVdXI6SSEHJEtAZZ9kblRb9uYPf+BSlnBg6LXhd1f +3dMu5LnJcPIS+gKssvymT0sJ5/W1R2V47rZzgid+cvahYurL3L6+OSSIaR6+YFFIzlh 2z+ICqb3lEVVNN72v2xWIehfCuLL4Qi0AhA5emgoJ5cxxeiA4qcCix4AHXZMdO0zD0XN 8vgrTSdkftTLao9DWYr6kwez0ZTq1BicyM//tC0oXZj3e9xwnZ9Sz6znG8knceuYad1A 3svvFjFGMLcY2jva7jCX77qRkm+OSekLzUFxsJRBdcgOLzrqpbLyKFj06unarhDyFF7D 0dCQ== X-Gm-Message-State: AFuF++lU/U/dj417AUSAZsBcE3yzpwkAsPnlBlkPTTOSCaTLhWmaA+fD TXsXisCyf7N2bejLEFkLK8m1/vDQjgPA54wFBfrdpC/N9vY3J98bIyyonMcHAUEr8xiHmF1xEoY 2sA+RNw== X-Gm-Gg: AR+sD11RjT578q7FKMNbEt3FgJN4zY/S3QMZ6yWwHBub8IrD4AdGY67rO3rXMZM2f3m 97Opq7J41gG8gxbb1/gODbbGD96q4xnSOt11TjEOuNPrDQa77T4r3eFivjufCz7vKEWoca/LfAp x+NqXUE/9vVjAdDzLDkvcxgAlXcnJJmn8W30+G4te9Q8nj4w+EuQ1WkxLnsIPizeQR20FrzlhDw uIuyGNFyON9aqHmDEGBntCKElQA+aDPjj+8pGMR3C6mcKvrLrLtDFR4ph4LaZdvOu2Pl/Cira0A 9/ZMX6501VSxoQQhtAsTkQXHQgvGQCudPypXje2i//r3f5sSSlUnzqG0xBzC7giMdnbVSHeLca5 KbQT78n7BAoS//LzSoXHLKTULjiMYcTJgHOZhwuQZ5e4uS6CJ3z5vzRINDHfHtFa2tX6fXopXLv XJpWClYpehd+HfBN0DmnCcpfoPwNQAElSnCcxoQsDs32O8y/nMkP67bjSuY6BPVV+x5aHxpuyPI 0PscEqAu+an7Xjfe7N8/EPZqDCjNEwZIV9dou/MsioIjmBqVQBQlerQUUiEpcU= X-Received: by 2002:a05:600c:1da1:b0:499:9eb8:a1d7 with SMTP id 5b1f17b1804b1-49ce5842935mr48448965e9.9.1788330850372; Tue, 01 Sep 2026 23:34:10 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 08:34:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788330850-756834E9-659EB4D3/0/0 X-purgate-type: clean X-purgate-size: 1741 Outside of drivers/acpi/tables/ (which is excluded from Eclair reporting for dubious reasons), arch/arm/acpi/domain_build.c is the only user of ACPI_COMPARE_NAME(). Make the macro const correct, at the expense of introducing a "const" variant of ACPI_CAST_PTR(), and at the expense of altering an imported file. No functional change intended. Signed-off-by: Jan Beulich --- a/xen/include/acpi/acmacros.h +++ b/xen/include/acpi/acmacros.h @@ -103,6 +103,7 @@ * Pointer manipulation */ #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) +#define ACPI_CAST_CPTR(t, p) ((const t *) (const acpi_uintptr_t) (p)) #define ACPI_CAST_INDIRECT_PTR(t, p) ((t **) (acpi_uintptr_t) (p)) #define ACPI_ADD_PTR(t,a,b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8,(a)) + (acpi_native_uint)(b))) #define ACPI_PTR_DIFF(a,b) (acpi_native_uint) (ACPI_CAST_PTR (u8,(a)) - ACPI_CAST_PTR (u8,(b))) @@ -116,9 +117,12 @@ #define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i) #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED -#define ACPI_COMPARE_NAME(a,b) (*ACPI_CAST_PTR (u32,(a)) == *ACPI_CAST_PTR (u32,(b))) +#define ACPI_COMPARE_NAME(a, b) (*ACPI_CAST_CPTR (u32, a) == \ + *ACPI_CAST_CPTR (u32, b)) #else -#define ACPI_COMPARE_NAME(a,b) (!ACPI_STRNCMP (ACPI_CAST_PTR (char,(a)), ACPI_CAST_PTR (char,(b)), ACPI_NAME_SIZE)) +#define ACPI_COMPARE_NAME(a, b) (!ACPI_STRNCMP (ACPI_CAST_CPTR (char, a), \ + ACPI_CAST_CPTR (char, b), \ + ACPI_NAME_SIZE)) #endif /* From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:34:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:34:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405098.1638649 (Exim 4.92) (envelope-from ) id 1x1eYg-0006P6-9n; Wed, 02 Sep 2026 06:34:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405098.1638649; Wed, 02 Sep 2026 06:34:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eYg-0006Ox-6G; Wed, 02 Sep 2026 06:34:54 +0000 Received: by outflank-mailman (input) for mailman id 1405098; Wed, 02 Sep 2026 06:34:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eYf-0006OY-4V for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:34:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eYe-00AOt2-HT for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:34:52 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c386-8faa-0a2a0a5109dd-0a2a450388c4-10 for ; Wed, 02 Sep 2026 08:34:52 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c387-fae8-0a2a45030019-d155dd31b190-3 for ; Wed, 02 Sep 2026 08:34:47 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-484374f54d0so421653f8f.3 for ; Tue, 01 Sep 2026 23:34:47 -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 ffacd0b85a97d-48448ee9cf7sm4347259f8f.25.2026.09.01.23.34.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:34:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330887; x=1788935687; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=4M7ZO90BkV+o7MOoEhTcnL8On+MmsrDJefwVfmLqVG0=; b=Jcf5lt7I0pywFWTZTdwXoYzOtjUMNO9JOtue6Uj/wfwVzGAIkD7qWEIC2P5qQ9hnuf 2Lb1r7Nv6bFpORP2wvH98pPE3PH2XDmylv81O+XEPF0nAqr/hmle/cR0va2MoPQH7JCX KAYQeIY+0po4vl8nZifN9/I7u3sM29B1dpz1cR67s0BJc/JfztNEnc/qrhXiorg+A8+T Y/RheTPASV6rBrm3sJtm3ttm0dFhaew2csfo+mXfIdpz8JWM3n7dGgB2hUxW6/Jvt1JR saymcwhrwk65rSn/eM570tMy8ouVl7eKNOec94DnJaM7a/L8SLGEBw3NLtUHy6dI77RP Ve3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330887; x=1788935687; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=4M7ZO90BkV+o7MOoEhTcnL8On+MmsrDJefwVfmLqVG0=; b=tFWoaZoGw3CeJuULwFTwOv/LQVd0UNfKX1eeZZto+tJKH3x73ktx572NtxPjc35OE/ rpMQkbwpwQR0Y8GibCpH106XQ+2fZQlyrgmwbtVoLznOiYIePvjWLQO42v2MlJDDSjec DX44BwS78Xx7vq+pVHfl6M2G6dfKZO2xagDR2/bsYq7fPVIpdctFgsfo/OtkZVV4DgDd 9iRyJELDjEa/niv/fTJvak/TY20BqKrRuHxnM412vQLPyW6BittRKX8JWpuUKM3fKKsy g/h5ZNOwuaxZ8MLKFhbDE5eOtxIo1HT+uC6ruhrTlSL+NVisARw13VXMZau7zkeu3lXW bDzw== X-Gm-Message-State: AFuF++mEz4EQbHLo6MvvincoxnypCkhZFhaN2rnf4e241jPoizEmxe8K orRyykujefr34bdcuOgJQFJ5+M+CoDlx3CMOKsbcRzvzq9IsFzoFyFgKNW+iuq1WRLEnzULykNj TPGjvpQ== X-Gm-Gg: AYBFou2+jw0gbkybzaxmqdRJgR2mn60vKvEjknK62n6VHlnUrbzbOqOVVAVcZmt9hAh dQ6ttkh+RAW9/A/uqGEEMYhSSoUotRqDgzg3XyqbByuIW2DhTUmg//JEpAd8cviCcrAp6oa0rHU t4nZP8kBh4eBDP+p9dzNymTZR/kQCZIaEXah4x15rM0Hb7lhHTQYsHhQA5b+59eCVTwS17JSuAj 2ZEz5wTaLBpdQgSIaXHM+Jqxr9ankZ4TDfdCg0cEM4mg89OGOs+xakYbgD/+rzaH/2Lmd7Lm1ui q0dXTyztdXEO0OKWT9w8a6n0LSfHi/I2s55kyPXgrko57RDQnAICU5qBLtrIz1qlwXwU9un6RDq 6P+yi4HaetMQ0zDo+43UuW/QBxYaiJl0HBYX3yOmHKdU0FXnPWndVYNQyvMyfhPDH1AvoX7wKnS AxOLrYHlh1gpvIFbmsAV2GiLIsW8TeNQQ1yn2PJ10GUP2N5jCWvnScNbeedkvaGPaVdIQUw3nlD dId1bdpCOU0tGh6QoN5WYGWdtPkz/F0wYZXUUHKr7ErmqfxeFSL X-Received: by 2002:a5d:588f:0:b0:482:fbb5:8a74 with SMTP id ffacd0b85a97d-48488f032b6mr3872532f8f.11.1788330887011; Tue, 01 Sep 2026 23:34:47 -0700 (PDT) Message-ID: <8fe86787-7590-44f1-be4f-461b61d7669b@suse.com> Date: Wed, 2 Sep 2026 08:34:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 10/14] ELF/notes: use pointer-to-const by default in ELFNOTE_...() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788330887-758824E9-FA6350E7/0/0 X-purgate-type: clean X-purgate-size: 1311 Not doing so results in a number of Misra rule 11.8 (casting away of const-ness) violations. We need to allow kexec to use pointer to non- const though, so provide a means to override the default. For ELFNOTE_NEXT() we can do better and simply re-apply the type of the incoming pointer. Signed-off-by: Jan Beulich --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -6,6 +6,9 @@ * - Magnus Damm */ +/* We're producing ELF notes here. */ +#define ELFNOTE_CONST + #include #include #include --- a/xen/include/xen/elf.h +++ b/xen/include/xen/elf.h @@ -29,9 +29,14 @@ #include +#ifndef ELFNOTE_CONST +#define ELFNOTE_CONST const +#endif + #define ELFNOTE_ALIGN(_n_) (((_n_)+3)&~3) -#define ELFNOTE_NAME(_n_) ((char*)(_n_) + sizeof(*(_n_))) +#define ELFNOTE_NAME(_n_) ((ELFNOTE_CONST char *)(_n_) + sizeof(*(_n_))) #define ELFNOTE_DESC(_n_) (ELFNOTE_NAME(_n_) + ELFNOTE_ALIGN((_n_)->namesz)) -#define ELFNOTE_NEXT(_n_) ((Elf_Note *)(ELFNOTE_DESC(_n_) + ELFNOTE_ALIGN((_n_)->descsz))) +#define ELFNOTE_NEXT(_n_) ((typeof(_n_))(ELFNOTE_DESC(_n_) + \ + ELFNOTE_ALIGN((_n_)->descsz))) #endif /* __XEN_ELF_H__ */ From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:35:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:35:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405103.1638658 (Exim 4.92) (envelope-from ) id 1x1eZ0-0006s9-KL; Wed, 02 Sep 2026 06:35:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405103.1638658; Wed, 02 Sep 2026 06:35:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eZ0-0006s2-He; Wed, 02 Sep 2026 06:35:14 +0000 Received: by outflank-mailman (input) for mailman id 1405103; Wed, 02 Sep 2026 06:35:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eYz-0006nC-7i for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:35:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eYy-00AOxg-Ka for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:35:12 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c36c-8faa-0a2a0a5109dd-0a2a4502edac-34 for ; Wed, 02 Sep 2026 08:35:12 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c3a0-6ca4-0a2a45020019-d155dd29f1d0-3 for ; Wed, 02 Sep 2026 08:35:12 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-482dd6ee390so675660f8f.3 for ; Tue, 01 Sep 2026 23:35:12 -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 ffacd0b85a97d-48448ed30c0sm4313104f8f.24.2026.09.01.23.35.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:35:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330912; x=1788935712; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=boxk4p0eJVFYzZBGyHEQSWRcZFC+UVjv0HIaDcDz8xY=; b=CRqqb0fb89JAfPVPLS1KrLrdJRkATtJxDzN6/J0uhmkRy7qwWXFgwSw1ic5gumqSzZ IXrszCF3LbUZn3G+bTj7vO3sXKCJdTvo2zE4OCzN2psdQjSGk9HqSOLJQ6HqMhYhisW0 P+xjGMsQEB1FW9+C8oe4D+9RCELQBpvMd6n5h5wPPW7RVCEX7KtRhGIYgOerq6x3BtKb TZjbGcnyg37fMAJUimAWd7KqvLLOYNYpP7HWI3L78A9jyPSDTYdCk+8kJyfOlapSv+RO xIMAfZgKbqiLRTEo4Ufmty2u3ETjQhfykUbCitxXxLV9Pddiipr5+ton73wxq3C1x/lg 9lBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330912; x=1788935712; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=boxk4p0eJVFYzZBGyHEQSWRcZFC+UVjv0HIaDcDz8xY=; b=BTk7AEed7Cs1SS7rwQ7evqm630t3Pc0hgFEiEFBcgWVOf/9LrWyP1+nfRv+F4eW91h xBFj4k/IE3Rujc5pvAoDYuTxI5aEU3eVP47pF91g9on6IVJ4F1rHEJp3b/oe5Z5y1nBc O6md+Jx+Z3JtbRwbO+W5Nkgo5WVVYPv699kFc1uAlmw3VLPW3AvAJ1QthZSLtroCWD39 7j4iCfg8iQAcwkaPW/sRInsQaSEYVc8j68ixwg9ELh+lZDnF7uje4t0Eb11amBz6zzwT vc6JIGtiZITYONqEz777X+h82XqqG+k5H17ua1PoPIcFCry2XsPES8uws+slSpW+pVED RTGQ== X-Gm-Message-State: AFuF++kwBXPlitypD1oFyJfxtNPVgQjw0QvxcA4zQiAgXwlpWXWWA5r9 xUQnYbL2s2+UTaRpfRQlBspqhgXCDVfb4UXsffHlkOt5nv7oWn75cS4AZ0onuEKRXlG79S/ceTl SIdHvBA== X-Gm-Gg: AYBFou2dIIKLVU1Ldyqbg83MDfm/kNowTPpkRbIShtsJZU6RkwC+ldtyZFporLKS6Sn 7PnDmjb7SO1p29Y7yn10T3NVJF4uMRy+DMrXe4SQ/BDEgoVW70G/ECRM30dTiQVZOqK0Ik/0Pis fwP3GafMhstfLZeHhwCzVD30aQrEUgEUNXaY5b00QV1KnU9mTBPhcB8OLupSFZW+KlovXy30wwY 7ec3RA6UyqlNaYsv8rwcLCwP2daGAEH7KdLXsHEbWQlDHI9yEnGk/Gj04yY2iTZ7zwbuYQOHXVe OGMx1bqUtUkz5KUYsWRPR0ez3/PPY8NLOV2y9cEn/aCTGSk+Ve/VCTfoj+BfODFiNHjEqIXxxvA 39LDnyy23ITLV/FJd2BHcZHGYXw0TI5gFNMUjGy12YxUgHGgOZAZTaVBEpprXs8QGfrJC8ZLU45 KylCXZ/woRe5Iglqpb7hjvdjFg+csCDdhaNlaYJxyvyDT5brUjhmjgOl38pZzJcxU+JHNNlF4y3 U0aRKnJFithRSoZK37trxR0T5gHSkqJew2XuyImvw22dSQzURZw X-Received: by 2002:a05:6000:40cc:b0:484:4880:449d with SMTP id ffacd0b85a97d-48488dee57bmr3688988f8f.3.1788330911990; Tue, 01 Sep 2026 23:35:11 -0700 (PDT) Message-ID: <1faace7c-2425-4691-b23b-3ffe033e5bc2@suse.com> Date: Wed, 2 Sep 2026 08:35:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 11/14] crypto/vmac: don't cast away const-ness in aes_key_setup() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788330912-315CD2AC-90AEB312/0/0 X-purgate-type: clean X-purgate-size: 755 vmac_set_key() passes in a pointer-to-const, which has const-ness removed despite rijndaelKeySetupEnc() properly taking pointer-to-const. No functional change. Signed-off-by: Jan Beulich --- I was wondering whether I shouldn't adjust the adjacent aes_encryption() right away as well. --- a/xen/include/crypto/vmac.h +++ b/xen/include/crypto/vmac.h @@ -69,7 +69,7 @@ typedef u32 aes_int_key[4*(VMAC_KEY_LEN/ (u8 *)(in), (u8 *)(out)) #define aes_key_setup(user_key,int_key) \ rijndaelKeySetupEnc((u32 *)(int_key), \ - (u8 *)(user_key), \ + (const u8 *)(user_key), \ VMAC_KEY_LEN) #endif From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:35:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:35:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405117.1638667 (Exim 4.92) (envelope-from ) id 1x1eZb-0007S5-SI; Wed, 02 Sep 2026 06:35:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405117.1638667; Wed, 02 Sep 2026 06:35:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eZb-0007Rx-Oa; Wed, 02 Sep 2026 06:35:51 +0000 Received: by outflank-mailman (input) for mailman id 1405117; Wed, 02 Sep 2026 06:35:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eZa-0007RO-45 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:35:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eZZ-005yng-H0 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:35:49 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c3bb-8faa-0a2a0a5109dd-0a2a4501ba20-36 for ; Wed, 02 Sep 2026 08:35:49 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c3c5-5984-0a2a45010019-d1558030e195-3 for ; Wed, 02 Sep 2026 08:35:49 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49cd9add88aso3818395e9.3 for ; Tue, 01 Sep 2026 23:35:49 -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-49cdce3e0desm133583925e9.11.2026.09.01.23.35.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:35:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330949; x=1788935749; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=/ukptOfy7Urb2YHUd+l0+4nj0VI7QTd6I8HIWXBvIOE=; b=PPNFvwdz/X+dzzqQfrrr9SNTXTgOS0CznNcV71XIbPRwdf43B2q0rKJhRwogxv7NrV n9dzFk+OcXIJiotTXyFj331bSd38YUW9h1Rp586p+g6CTZM9bX9/SiUzptbIZMk45bXV KA23hAcDRoOP/y/Mz3u4I5LX5q+SvfhlPI0c257f16d++j5azGQqpHFRHi8So3DiH/ra 2kgmWWR7kLi03MODqOYeOaNVrOyuDnmmbo15qx86ggUDwRbwd/SfCNYdNW3RQKSXC6tp bReKZPJYYBTGmi8c9w7iQnMK+24R6pQykWHIXxiPFyPDXcdYyv6tUo49wvAtrQRKEuCz w53Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330949; x=1788935749; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=/ukptOfy7Urb2YHUd+l0+4nj0VI7QTd6I8HIWXBvIOE=; b=efCrVp2VHt4QFVnRgzEPSnpplLRAKuwcGLnpl2gpev8kf4P35NQ0/wwPWulx1+Ah9z W14DPRs5oHHVI+c9M5rroNcSazLc9KfGsNCWaU415tD/QYxWQ+S9MCNEA2i+OKAn8eco utsGEO6Y9msiR3pJSxYFLje6wCyF0vMEvhWHQJZVpuY149+1rWFfnKLmZm+6uMdEFwfv YtJSoxsTb28LIfbQFlYyfIAd7BTlDkkPkPnUc3a3rdJW7FX0aGVxWOInpw2qo96VevgJ eBhfgF7SnP1gQQcWIy7jF6kzwDR8evV42OgD7L3Zn77z2uoP8GE/c9MXBD2bYNG+TyDI aRog== X-Gm-Message-State: AFuF++mgZ5T1ugWoDQxBktP3zTUdm7ryahiv6n+Ndht0C78+pqeTVlP7 RTsAABux8SES/PFa/FDJiyrYXVHV998WHgM+TYvF0Ur5o2l7TsKTxW53N7DfuxGZj63ScYMR3aI 7nz0z9A== X-Gm-Gg: AR+sD13nykA1D3hmgzJaAGpVJlDy1H1DS0v+JodFvdvjp6JiXL8PiGCNPEpav5LYS2+ QSEIefYOgalaU2dvLpHEV9um75Gt8YJEESnSd3tqklvUtdU9brSexVTcUPQuQ+vt2KCngSeH3CY pzYQM6mzubdWo3ePNwfEWDTm2yMUqb1r1wZRyJgMjwOtM4Wip5OJ+t4VWAxG8C/QLni/V9+Notp rRcRSDpAVc8wu3/Zp9wDRJwgce36nqrmhndjEMkkTRLUGlT8080Ch/KzYA6xl49urOwESB+Evii QmTZgKK8bsJpeTj1uNpJ9PTdpuUqC8eqcWv8hMHfyG2Ca3MfMX7bsj0mIF+T1926z6v/Rf/NeR/ d6iXCGdvk5v4HMPg1AtRRDoSNJBpPukghOuRUEepxJltB412zOn3IUZdwFUQjOC8SoZZ13utayX 1wZ+wX5P3HczxEeVa56TSDxJ91rqymlIcboJAYZKOnugACWcFSfKOWKDUVA6hDMVFug1ULPINwM eIHBUl5wFirRonM4xWhc7KDTW7fKeZM9iW0h0AsV8gRs3RkDIU7 X-Received: by 2002:a05:600c:37ca:b0:49c:cf18:494e with SMTP id 5b1f17b1804b1-49ce5819a2fmr46114605e9.12.1788330948918; Tue, 01 Sep 2026 23:35:48 -0700 (PDT) Message-ID: <1f55b457-c8cc-4ef9-ba5a-96e52b95fbbe@suse.com> Date: Wed, 2 Sep 2026 08:35:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 12/14] gnttab: don't cast away constness From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1788330949-BF262757-518BC6AA/0/0 X-purgate-type: clean X-purgate-size: 1751 While _set_status_v2() indeed doesn't alter the grant_entry_header_t it is handed a pointer to, _set_status_v1() does. Drop the const from the parameter of the latter (and then necessarily also from _set_status()'s), while adding const to the local variable of the former. No functional change. Signed-off-by: Jan Beulich --- Really I think it would be best if we did away with the raw_shah local variables (which looks reasonably simple for at least _set_status_v2()). I'm unconvinced that we really need to use ACCESS_ONCE() here. Torn reads aren't a problem; what we require is that we look at a stable local copy, and that can be achieved by putting barrier() after the reads. --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -740,7 +740,7 @@ static unsigned int nr_grant_entries(str return 0; } -static int _set_status_v1(const grant_entry_header_t *shah, +static int _set_status_v1(grant_entry_header_t *shah, struct domain *rd, struct active_grant_entry *act, int readonly, @@ -832,7 +832,7 @@ static int _set_status_v2(const grant_en domid_t ldomid) { int rc = GNTST_okay; - uint32_t *raw_shah = (uint32_t *)shah; + const uint32_t *raw_shah = (const uint32_t *)shah; union grant_combo scombo; uint16_t mask = GTF_type_mask; @@ -909,7 +909,7 @@ done: } -static int _set_status(const grant_entry_header_t *shah, +static int _set_status(grant_entry_header_t *shah, grant_status_t *status, struct domain *rd, unsigned int rgt_version, From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:36:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:36:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405130.1638675 (Exim 4.92) (envelope-from ) id 1x1eaF-0007y4-2d; Wed, 02 Sep 2026 06:36:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405130.1638675; Wed, 02 Sep 2026 06:36:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eaE-0007xv-WD; Wed, 02 Sep 2026 06:36:31 +0000 Received: by outflank-mailman (input) for mailman id 1405130; Wed, 02 Sep 2026 06:36:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eaD-0007xg-F4 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:36:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eaC-008Nhm-Rr for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:36:28 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c3e0-2eae-0a2a0a5409dd-0a2a4509bb86-36 for ; Wed, 02 Sep 2026 08:36:28 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c3ec-be1a-0a2a45090019-d155802dd4f7-3 for ; Wed, 02 Sep 2026 08:36:28 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49954b88fffso4638525e9.0 for ; Tue, 01 Sep 2026 23:36:28 -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-49cdce3e04csm117687405e9.10.2026.09.01.23.36.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:36:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788330988; x=1788935788; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=McMHeBsvsP9+2Amzdovql9JHeO48zwLTMwqVky0FzsI=; b=UkuWBuVqIQqs4CK124QTWwtr+dxsefWKsXHCypBS0UgY+EXE26/KqcMOnUOO3X+DzY fz7rV5puIxoc4tFTYhBnh5FCKrdfcx44ZeyqJlul1EzeMrjWs845X7APxyamIj/Fe4Fm JQsElOFPTVm/Z0cxMCXRjziuLUfWQW+b+8gUopCf9qwP3stKw9dSmm6BhCGR5M6vfM44 mUuUOzvAhlzubbQ2Sd5fFmuFhldKLJ0zsjxPrynlQBzEjVvkryrjZXqBQGel6QgEHmdv FIdSgXDm6jRPC84umUVdtUSST11SvOBp0jol0MhUc4pdCdI+rGZGMieoVvHfSmURSbd6 tl/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788330988; x=1788935788; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=McMHeBsvsP9+2Amzdovql9JHeO48zwLTMwqVky0FzsI=; b=rIj7ZhdFQDkHvbaaNkA+LfmjdxHQSARMSueOg8bNJCgtSa2/uIbnDfywDad2BEo2TC Hj0m7loZvqJnW/n1NlTiQzF45FX/fBBuf9QE9aR5NQfsmWQn2j76Ge7loaQettIiM7qZ +Y6rvA82Bdl/KIOZt0r68D48Vdm5nTkyt3E42l8ZD19plR7EW0XaNfIFNvY1yIRHZMNO LXuUydESbrd2PCD1OhBi1soDSmZMVgZp2P6NzapC/TGaxLsM3F/DG+FdS3eDIDGbftK6 AVpnmeEDu6vmvnq9h9TTZMH5yyux95N0Fk1dgizdTg5jR6zNvP5r7689rwc7YgTmYZCF 2sEQ== X-Gm-Message-State: AFuF++kc99N17mWiWL3kOHesDfvsmcoGegydn3Ignl7npZ3Da8E3Pva1 0dCA+gxSF94IqJ18H8F3QBSJwDczMKzeET2oZJc40oDHsNA+tCO0yblO6BRSRRCDaOABr0D6LY7 vL6dIZQ== X-Gm-Gg: AR+sD10Glo5vBdi9dxnoRSXD5GNwvnFFtuI0W0Qnsgg4ZoflF6dnJln2X3v1J/9NYj3 JD+bP02n64jTUEHEOHGe3fgvDXrw4/MYn+44yQG5SAVUmqY17FhpTIpVTTMbaqwYLS8Gmuxu72T ARe4SKZSlmvNHSwqz5iB2k9Yq8ypA712uscUSfzKBdIUAAIGDtvVVZ7tIXR48y9EA4AQux133wr QHt+5zk8Nun0injZWt+izFvoBvZFicZSnyylR6n31W3cDTmSF5syb5UhpeeCMQy/3iouBJ2ti55 6/SxbVUSH4lxYGQS+ec9Td2BjYqXl0qFWngIejjt+83H5T43NxQ3pnXZ5tB7HuVeSwnIxw6PD/D mC7PIFwsw1T4b3biUahEMfiJVYNhp6/pfHmFRquOLdRt1gkSRxIkTBzIfKzFUPQx51IhwjKNGtf vHDj9nDTdif52raN+haMZGyXnyQw2zhihQlKBdvcvRs/fKQA3RUpWXiLuhVYM8TYgDUdywgSXwj O72UimGUxPznr2vXz0EPobnKXYsN85YiS82p7X1AFr+A1UhG5TT X-Received: by 2002:a05:600c:a086:b0:499:4892:d022 with SMTP id 5b1f17b1804b1-49ce580c170mr48931045e9.8.1788330988342; Tue, 01 Sep 2026 23:36:28 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 08:36:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 13/14] passthrough/PCI: rework (s,b,d,f) init of struct pci_dev From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788330988-3B0DD034-6F56138B/0/0 X-purgate-type: clean X-purgate-size: 2097 Right now we're casting away const-ness, to initialize the individual elements despite the field(s) being declared const. Eclair validly recognizes this as a Misra rule 11.8 violation. Hide this by switching to the use of memcpy(), deriving the destination address from the (mutable) struct pci_dev * which we hold in hands. No functional change intended. Signed-off-by: Jan Beulich --- Subsequently we may want to further leverage the sbdf local variable we now have in the function. Yet of course the primary question is: Is this an okay game to play in the first place? --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -318,6 +318,7 @@ static void apply_quirks(struct pci_dev static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn) { struct pci_dev *pdev; + pci_sbdf_t sbdf = { .seg = pseg->nr, .bus = bus, .devfn = devfn }; unsigned int pos; int rc; @@ -329,9 +330,15 @@ static struct pci_dev *alloc_pdev(struct if ( !pdev ) return NULL; - *(u16*) &pdev->seg = pseg->nr; - *((u8*) &pdev->bus) = bus; - *((u8*) &pdev->devfn) = devfn; + /* + * pdev->sbdf is deliberately const, i.e. it can't be written by structure + * or field assignment. Writing by memcpy() works, as long as it's not + * &pdev->sbdf which is passed. Since memcpy() isn't type-safe, have an + * explicit type check first. + */ + (void)(&pdev->sbdf != &sbdf); + memcpy((void *)pdev + offsetof(struct pci_dev, sbdf), &sbdf, sizeof(sbdf)); + pdev->domain = NULL; INIT_LIST_HEAD(&pdev->vf_list); @@ -390,7 +397,6 @@ static struct pci_dev *alloc_pdev(struct phantom_devs[i].slot == PCI_SLOT(devfn) && phantom_devs[i].stride > PCI_FUNC(devfn) ) { - pci_sbdf_t sbdf = pdev->sbdf; unsigned int stride = phantom_devs[i].stride; while ( (sbdf.fn += stride) > PCI_FUNC(devfn) ) From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:37:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:37:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405141.1638685 (Exim 4.92) (envelope-from ) id 1x1ebC-0008WT-Az; Wed, 02 Sep 2026 06:37:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405141.1638685; Wed, 02 Sep 2026 06:37:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1ebC-0008WM-8C; Wed, 02 Sep 2026 06:37:30 +0000 Received: by outflank-mailman (input) for mailman id 1405141; Wed, 02 Sep 2026 06:37:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1ebB-0008WC-1P for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:37:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1ebA-001del-Dv for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:37:28 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c41d-e002-0a2a0a5209dd-0a2a45079154-44 for ; Wed, 02 Sep 2026 08:37:28 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c428-b4ea-0a2a45070019-d1558030ec26-3 for ; Wed, 02 Sep 2026 08:37:28 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49b0d8bc2aaso5879815e9.0 for ; Tue, 01 Sep 2026 23:37:28 -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-49ce7ac52c3sm11548705e9.4.2026.09.01.23.37.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:37:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788331048; x=1788935848; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=VJtH51LzC3g8OlgK6LACaAIC7g20s+b/0wgQw5fmfdM=; b=f9I4i8IwZEKpAeg0nD7bfpLSye5SIzJ5aqlZwl8P2lpvfmWdc62M3F05IacotG7guS IT40Xxb7KNlRaSmgREiOpuKu/Y3GHiNp0UhjtERumdkJK6236AGNap1HDDsEhjFPqO5j YL29M2qO7vsQnPB/w5LJfV71p5H5ZX+zHyOOcd6J/5QJdc5pKRtJ01lIwroh+4eGUUmn P/+wZilUbzZjoEhfxFiKSgr5XuN8jVN86tmDIQqjWU1jTWgK7XNjo2P45y2DOZnzRTMY B409MD8PN+aqN5xr8i8/B1LYPBC0vO7iUe+rhiwTERTpb7iofjAyNF3RjCSyx41/hkp5 qj3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788331048; x=1788935848; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=VJtH51LzC3g8OlgK6LACaAIC7g20s+b/0wgQw5fmfdM=; b=TXvcNQWP+8jnVKltc98yC9p2qKMMz03vL7BmWA6PpPAcgHxsrWtKrUnklwzs0leSYe 26HXxd6NopDuXdBekJHLzVpB/0IomdsRclq3jdN48AuaRwOSLulpFIwghYWr2N+1srVw GEa1AVHi4dZmWeJLnb5cDbr5bDrP9Dq0na/PItwg0lj0dtTvzjtu8zYcgVRSZ0chKVm2 tjJI0K18p5/DxBqCQPbhdscaZF/r617A2zgJixaW4j/PyC+8A22Q3m0M3qrXMQT0+uwz m0EdZZw5c9NsRR9ThddlBBOkA09CVBT71SAcPjbDBrNCI+I9tAKzGaAa1MvNUnYcAlBo K5dg== X-Gm-Message-State: AFuF++mNsx3lIAGZEEa1tAqT/1vO2HoH2aZ9CyLqABmPD0lBYGYwXkr8 7B2PBYCqaTE/SDR8yxUoao7qyL5jOn+PWZDL4YWME5mddqBdlFH8HAu6B+ykQ9821rHI6LlvjuF P6ZfmJQ== X-Gm-Gg: AR+sD13g393kKgidTpD0ncQdA8GxYcHlTSb9rIKm3GcpDbgm/EOi6ky7yITHCO1/ijq t0+e0pj5cA6HXaJkI8hLGUnvRU7DxLF5eOTAxMdfc9WWJQHAim8STOo55vlvIJy2lSvYK5kquNQ /I0XZ9mvz/wmXBb6MFRalXHGh5oX/3YWL80Z3I4tVS41GTIvwrR8QBhZOtovxB9kZu9MJMaqRza S1Txwakoiouyvk4HZt+TDBqtgzdrj116Oc6TEOBE9wpsJMV1q2EcD69u52v+Np4iIgQGWBdmZEV VVXIQqyQLOXg2Y/yZlIdpfeu12lZcDzeY08gauKUD4OfBr+9J1iZeHeB9nlcmcrC3V+HecVhVYZ /HlStscsz2zYIjrWnqx/FdfjM9+j/Xsq0VMVeGlVcIQ3cPn3tu0Pkb9AIY/QmqnFX1dh/rTUPRu qIDVbefK6RwUj3AzgkbPupD16khWT11WImt4z6lE+ptq7njd34Da7xNrRFD2zPzSDX5yIAJLVsd qpASAJVq/SmwURKXh+C4Fy40g1VhbgbN8JnbL/dpTQpXNPN1OOF X-Received: by 2002:a05:600c:45c4:b0:499:79b9:e220 with SMTP id 5b1f17b1804b1-49ce5816186mr38862465e9.10.1788331047806; Tue, 01 Sep 2026 23:37:27 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 08:37:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 14/14] xhci-dbc: don't cast away const-ness in xhci_find_dbc() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788331048-35EC6AE4-BFE21905/0/0 X-purgate-type: clean X-purgate-size: 992 Doing so (at the return statement), besides being a bad idea anyway, is a violation of Misra rule 11.8. Make "xcap" have an initializer while adjusting the code anyway. No functional change intended. Signed-off-by: Jan Beulich --- a/xen/drivers/char/xhci-dbc.c +++ b/xen/drivers/char/xhci-dbc.c @@ -384,16 +384,15 @@ static bool __init dbc_init_xhc(struct d */ static struct dbc_reg __iomem *xhci_find_dbc(struct dbc *dbc) { - const uint32_t __iomem *xcap; uint32_t xcap_val; uint32_t next; uint32_t id = 0; - const void __iomem *mmio = dbc->xhc_mmio; + void __iomem *mmio = dbc->xhc_mmio; const uint32_t __iomem *hccp1 = mmio + 0x10; + uint32_t __iomem *xcap = mmio; const uint32_t DBC_ID = 0xA; int ttl = 48; - xcap = mmio; /* * This is initially an offset to the first capability. All the offsets * (both in HCCP1 and then next capability pointer) are dword-based. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:40:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:40:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405156.1638695 (Exim 4.92) (envelope-from ) id 1x1eeI-0002F9-SJ; Wed, 02 Sep 2026 06:40:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405156.1638695; Wed, 02 Sep 2026 06:40: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 1x1eeI-0002F2-Om; Wed, 02 Sep 2026 06:40:42 +0000 Received: by outflank-mailman (input) for mailman id 1405156; Wed, 02 Sep 2026 06:40:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1eeH-0002Ew-SR for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:40:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1eeG-00APjd-OX for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:40:40 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c4e8-e002-0a2a0a5209dd-0a2a45059dae-0 for ; Wed, 02 Sep 2026 08:40:40 +0200 Received: from [209.85.218.44] (helo=mail-ej1-f44.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c4e8-4cb1-0a2a45050019-d155da2cd407-3 for ; Wed, 02 Sep 2026 08:40:40 +0200 Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-c250f28f1cdso105502066b.0 for ; Tue, 01 Sep 2026 23:40:40 -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 ffacd0b85a97d-48448e7315bsm4318538f8f.7.2026.09.01.23.33.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:33:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788331240; x=1788936040; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=rdPRqA6wEiNszUQj/y51xazgnGzZmRfdZpGOrsJoxyM=; b=IPHWVm38xdol88QY5kHj2pwAn7Py2mTyXgqbii0nE31g5TCtONTbu0KQMiIpb/1gc4 EQtAH0QPvhEIot81+8mKIY0AiyqApKYYlOZ1mmc0UvRhho1/QEVJqjpZ8+wlDviXXCLQ uP0fn50RevlwgEzB56Km1ltZSV9On8t8FTl6nkk6iPccHp6ab5U+P6ETZwO3ZdrgT8Kt 8LreeScD8I6oe4Kw0+Jw+w5v3J92eYhbpXdOQKskqFSKJ0XSNGQfodC4FMfw/a2Km8eZ q7GYGdWV1cA2cR9FDYAz7qC4rpCnfeFQ0zi5Dpyq7Gt5Af6AFDztFiBjlhP0UJm7oNqb /Rmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788331240; x=1788936040; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=rdPRqA6wEiNszUQj/y51xazgnGzZmRfdZpGOrsJoxyM=; b=iz0iVx8wqiw9nbZhrJqifyV3/R4vu8tb3p6AiFQsUv/X5swYq35IRnC7tHNgXFrVUT 4XrRHti+88vX3H7dFTndEji0LEvHkEZyW9UM04If39IVImaEHDG8WMxNQvOZ9u+7tfFG 8eQWVbLUwehGZjun/x9TVRm+uvgxkpqDpyfpOuLVPfoIP2B6i2jb9JSV3vsQv6wX/b5W 0i2ytB9zZfZtpHJijAb0PG3gj+ILQATd7dMhQpwSxk0+HQ2uxcOgPIlyJKc08BExPkAr VtdTr/ljZxoUY4INZxgP5UzeAgcD+yJvqFcBvku2zaf1Jy06sn7y3fg7R4mTwFT36AwQ UA8g== X-Gm-Message-State: AFuF++n1OuD0W+CNYwYRcxUjftDy8r7W1eDrlZK+7VnBxzztdhC9D6n3 09yGeApYY+caRdbkVHVIZnj04/XkvVvnSCFAx2l0+PLBLaGqjYtQbGJPcRPtOVtwBS563Pckzjt XboYxqQ== X-Gm-Gg: AR+sD12lx4/BKKtLhE6Z73kwaqyNYuMOCQ+TVhghd/svfWlZpDEHmrsIwa5C+jZMc1h 0O7CABKa9149T/fUWO5VrhrfhVRZA6nHVT5haVzLC4xPBFmFtiKlW1fhNGWyDXkRBzAWJja+12h p5fe0dnd/1agXSqEzusNjES0p+jND/EnOnGD6c+Ynuqy9KGfOh0lI/COeWUEh3zEVMgzsp5fdRZ W2bEMpRoiuDEXGsseFBixB86vQUz+nKSWXrd7Dx8o/xW/YTW7Ev9j1C76NpeI5181QZFi9UTTTl 8Aw9dRqx33nPHen5uF94EX/nrAGi3nIiHTsGae0+jyRcK8H1QOzEqOya+afVcCNTv0XraMYwCcP Ru+fQfF35c+08eoORIh+K7W1pbrjaML6wcg/2FeohVHyfNTJVMUb2Dr2nCACbnLdAdH5HyYIKh5 aWtvQaUQLSoSyLCjCwUanHl1lHToWBwjcIX2kBpbxpD6TNAeMsSxLYDyZDkICNHFO8S/5kqAw44 bemllB4JqWtg4rbX2rTvP9172T7/UA8SfREeERPtDPYtxHr4NIr X-Received: by 2002:a05:6000:4901:b0:484:479f:4152 with SMTP id ffacd0b85a97d-484914bf9a2mr4793600f8f.23.1788330786845; Tue, 01 Sep 2026 23:33:06 -0700 (PDT) Message-ID: <9479d311-2449-441a-9855-66926dd8e0cd@suse.com> Date: Wed, 2 Sep 2026 08:33:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 07/14] Arm64/GICv3: have gicv3_its_find_quirk() not cast away const-ness From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Language: en-US 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: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788331240-732B32A1-185D5347/0/0 X-purgate-type: clean X-purgate-size: 773 Doing so violates Misra rule 11.8, while being entirely unnecessary here: All callers already store the return value in pointer-to-const variables. No functional change. Signed-off-by: Jan Beulich --- a/xen/arch/arm/gic-v3-its.c +++ b/xen/arch/arm/gic-v3-its.c @@ -84,14 +84,14 @@ static const struct its_quirk its_quirks } }; -static struct its_quirk* gicv3_its_find_quirk(uint32_t iidr) +static const struct its_quirk *gicv3_its_find_quirk(uint32_t iidr) { const struct its_quirk *quirks = its_quirks; for ( ; quirks->desc; quirks++ ) { if ( quirks->iidr == (quirks->mask & iidr) ) - return (struct its_quirk *)quirks; + return quirks; } return NULL; From xen-devel-bounces@lists.xenproject.org Wed Sep 02 06:51:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 06:51:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405168.1638702 (Exim 4.92) (envelope-from ) id 1x1ep8-0004Hy-P9; Wed, 02 Sep 2026 06:51:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405168.1638702; Wed, 02 Sep 2026 06:51:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1ep8-0004Hr-MN; Wed, 02 Sep 2026 06:51:54 +0000 Received: by outflank-mailman (input) for mailman id 1405168; Wed, 02 Sep 2026 06:51:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1ep7-0004Hj-Cn for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 06:51:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1ep6-001fpS-C3 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:51:52 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97c776-2eae-0a2a0a5409dd-0a2a4503c97c-40 for ; Wed, 02 Sep 2026 08:51:52 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97c788-fae8-0a2a45030019-d1558031bc05-3 for ; Wed, 02 Sep 2026 08:51:52 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so6015565e9.0 for ; Tue, 01 Sep 2026 23:51:52 -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-49ce464aa32sm55240765e9.5.2026.09.01.23.51.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Sep 2026 23:51:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788331912; x=1788936712; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=yTJTlH0jzIOL1WrqVMZ4jOPbf7aE0JO3fKyodOySVHo=; b=SOuRstLKncZqih9Dn8ZRkoR0pr9pd0L3AWLhCiRpVPi/vbT/WfXryr0wvyxzZmfcTr B10PlSMmNJL0l0fS/bZlbbpqSKv3yZZlT4SEgqJ1Ky3KlD+Z1FZlNUrTHTsolS04ouhY sM/xAW3jfrYIdOVe8CcUJ0ydsRnyPqgWEvdKsU8cvxU8rWMDasnVSIRytcf5UJSfCWoX zPBLKo7nG2MijSEMO+j8acxCz0y9mdIMXsoDTHbJ+VQ8LyTz3MJtsEL4bym8y3+Eqp38 laISClybrQ4fFzaT2tROQZ9d2rnSDq3qHqzgitHDa3ew/cRlh4jb1bwkC5xbOoz9mp3/ vRPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788331912; x=1788936712; h=content-transfer-encoding:content-type: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:content-type; bh=yTJTlH0jzIOL1WrqVMZ4jOPbf7aE0JO3fKyodOySVHo=; b=BijaH7Qg1YjnJ7xTvw7LYeIiQF7OgEI83/8dvyWZwUvIb2J3aYyL+Bm/vb7S/Uz6XL 5qR9ykQGFByHVjhqfmM8Jhid73DFawL7285BtNDyM7hAnAMzEueYgRx123uOIy5zC14C p37CS45GnNiJ4uG8cUF2FvTfI3a8lMlP4dffi57o1qmKb/kPPKGXTO1DwtpL28DaHTH2 M4vUdcWdpw/8NtKrb/l1JKkwK3t2p9kY85XR9DN36TJNElTXkt6S/tLgRVf/M8zdT7KH VBl2cRtuXLlw0ufFvHJ0KJjJURr7Ljran02dzR4y3KTU/XYoj1qkX6Hyy44J88HxqKwn Zu4g== X-Forwarded-Encrypted: i=1; AHgh+Rr5f/WE+7C1z/5lAXnp+b+Wh8Bo50MYMOPuzyyz/v/gdGFe8pqNzaN+Rvj6fIARGVxEfggr2EqExJM=@lists.xenproject.org X-Gm-Message-State: AFuF++n3KLCRj0n9ZB+c58JOQghWzDc1S0RevTMhBK+xGuUrQdCZ+aha x18tJgva78krv4DgbbxwXsnDg5IrQTM8NJ7vCunfyirTIEDbhT5OVFRD8JpIczlcCg== X-Gm-Gg: AR+sD10Si3l6Y24My2t06cfkoNHnlNSlB1Mgf5ISRpqlaUF1OZOv6T/KFhy9jL9F++1 XVpk7g6bAgY15mcZISnGkc6KzYbsyg8fpu1vLHhqIkJuJx0JU2qGbWr5HCMVf7Zd6JguQpClef5 jmtxnYi+n4qA8iRLwNnr0oCGnARibrW27lczQ7NYirhLxNqU6yCCYoVEW+yn3tClXpV8eZOJjPT Fy9V76D/njRUrC/sPDIghOauD9FeH4+98gc2G0wXHTFQdKL/87LbugCwJr8Kea6Lyke8wHeSYns 9Vvc6r4+i5RZIUjS+2gWVDrUwNdlGoLDAAlfvfYCrkWL8PNHbGNjTbLT8tRl/7zPcqoAR//1yZl womTUiiIZpadfdQYnWo//0hfXQ0DOxJysKPDOLsAU2GGYWSmBMKMLAEMNuY83k3NNYH1NvrH9na AoJYMdNCp4tytF4iLSK0zm9E3suhSXlYY79/eCaBpmSSODUVYRfeAxrtU1I8gSg6014ju7TRCPk 2GHTycTekElNgB3GwgameG5wsQfcDuCkKbcE/1yAsWS5qMXEhZC X-Received: by 2002:a05:600c:8a17:20b0:49c:d818:8771 with SMTP id 5b1f17b1804b1-49ce5808d4dmr31349525e9.7.1788331911631; Tue, 01 Sep 2026 23:51:51 -0700 (PDT) Message-ID: <579431f7-3df9-4a96-8a9f-1fc748a0aa4a@suse.com> Date: Wed, 2 Sep 2026 08:51:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.23 planning: items for the release To: Oleksii Kurochko Cc: Community Manager , "committers@xenproject.org" , Xen-devel References: 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 X-purgate-ID: tlsNG-33051d/1788331912-750864E9-9D5723C0/0/0 X-purgate-type: clean X-purgate-size: 848 On 01.09.2026 18:05, Oleksii Kurochko wrote: > As we are starting to plan for Xen 4.23, what items are you planning to > work on during this release? "Work on" isn't the right term there: Stuff which has been pending for, in part, several releases should really finally make it in. AVX10 support to give a concrete example, but there are many others (including things I couldn't sensibly post ahead of other things having progressed at least some). And I would strongly request that you or whoever else is going to be release manager actually start pushing for this to happen. It is imo an unbearable situation that work which has been done is getting pushed from release to release, just because reviews don't get done and, where necessary, supporting parts which were promised to be carried out aren't coming into existence. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 07:16:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 07:16:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405178.1638712 (Exim 4.92) (envelope-from ) id 1x1fCI-0000In-Ij; Wed, 02 Sep 2026 07:15:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405178.1638712; Wed, 02 Sep 2026 07:15:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fCI-0000Ig-F5; Wed, 02 Sep 2026 07:15:50 +0000 Received: by outflank-mailman (input) for mailman id 1405178; Wed, 02 Sep 2026 07:15:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fCH-0000Ia-NJ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 07:15:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1fCG-00Gpr1-Jo for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:15:48 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97cd23-2eae-0a2a0a5409dd-0a2a4503d3be-6 for ; Wed, 02 Sep 2026 09:15:48 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97cd24-fae8-0a2a45030019-d1558036e4f6-3 for ; Wed, 02 Sep 2026 09:15:48 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49cca4ffdcfso4503875e9.0 for ; Wed, 02 Sep 2026 00:15:48 -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 ffacd0b85a97d-48448ed3716sm4469216f8f.22.2026.09.02.00.15.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 00:15:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788333348; x=1788938148; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=IAYE0qJP8FYYzDWFxQ5So98S6+ES5em+3AjPMWTwRhM=; b=DtlHsuhy+6IUb+PibkSjtkkCqZuB9h9olWgQJjPJmo6Z1xyfp8EBReOhPtc4ieBgdm GKlbTIQhOn2muI947dmbznA7270yV2ggkHmw68f8madJq2EXaodkyJuEZlR5P6whmedD 2JD9W8dC600kuLgZfKYUhrXF4vWG4vom400DDbWI13d5YWfLBrZuUp4whDB5FKwENYSS 10tGiwWtr4k6Hcva7SHWQ6vWraI0ryit4gY5w2HgT6EpgOsnuvGpL4A3pqEAlnISo5Vf 9UOGpI1d3R17LujA35U3mIYMJhs/N1OYm/rmthFTYgNWD7BovrpO5o5zWUjqthhtiEzW 8vsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788333348; x=1788938148; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=IAYE0qJP8FYYzDWFxQ5So98S6+ES5em+3AjPMWTwRhM=; b=pszT7TZXCFaZlN6VWwySEqXtBlmFTBkFwfbiEg9+oSk3y39qS4n2cj6YMLVgBNNZBJ kiyxdsaKS0VxrBQymhdNFWn/89hoFzweDCgUPzV9VY/Bw8PNUWz9OMWH+DX7e7rvcslJ 6qa6vdbPVrEryUPCc+PCu2BNNtjIsrmijzLwRguNj1TvvdN5rL1fd2NOppT/68uvDITR hXcB+37AKzyhvSGbIC8coputSSoyMM9/Gju1DocWiXpJxm6+yfEb2sv2DIBtMrZGAI4B K51c1QCaG2/JNKGAWiN/RCb4vlGOG7HX9qix/1Zrga4xoEhdik04DceiymgvZzfX4rZB nW/w== X-Gm-Message-State: AFuF++laWap4eCiybeHWYzln1gyHWdUJq8nOY22sHzKDbH0OECo4Bnfv D7FGFMpRS7PA3b8AbJog9kYaTTL0IRH0ne+Eh1RqxSa9zhrNYkOp3cxDVJtqo00F08f98pbY+ws c6ltTyA== X-Gm-Gg: AR+sD11j/8+0/nQbzKka6u/eur3MYyK1Wr80deR44ugKuc5pOo/HtJy1nWgHx/EOHJC c+O3rRXc/yHvLx+vfKU1Rg6+hD8f0+nMoCzdpBTYqXtH3XuqiKkaCaf3T/0RHoGIjAArEzl0EoR pnM/zpPDqFxCUWMWaHij0YRxk94kgQn9NIrFXoOTNJtcPNNyXewZms2sTALEeLwnt6BuJA7z0Zg EjMX5N3zCsXPx6u20ZKdKAb4kIfOVJSf+hvn1f6YYhdSEM/MGpRFsgh9KXxOq7L0QukXjsGT3Tk a4IpyNuGuGF8aDILwcQyC/YjOUkTd0zhTd81PELLAbN16Q1ECPduLdEIFd3xhvpQE3Kveoupv6q PlJ3k2DptT6u14MhtH7/Nacasn9W8TLKBGTIWxpuN+iw7XjVbX0yAaTOM/gi+jXXX7COlpkwB/5 ISXznrW7jvuKfFaFv4nyUvp/b9bATtnhtqDAsOeYiVMnKaWQkKndvD2Kcx7LP4uvNaFbN4Z/X2J WBNzWuai1ATOpgYu/vnU9fMrRXdHnrwxtMghIUqG/N1TAnGwnfz4A== X-Received: by 2002:a05:600c:e558:10b0:49c:e906:ba16 with SMTP id 5b1f17b1804b1-49ce906bb7cmr1538195e9.15.1788333347853; Wed, 02 Sep 2026 00:15:47 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 09:15:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/alternatives: mark .altinstructions r/w 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788333348-766FB4E9-799702DF/0/0 X-purgate-type: clean X-purgate-size: 2901 Forever since the introduction of the .priv member it has been wrong to record the section as r/o. .alt_call_sites, otoh, is legitimately r/o, hence __alt_call_sites_{start,end}[] would better reflect that. Signed-off-by: Jan Beulich --- a/xen/arch/x86/alternative.c +++ b/xen/arch/x86/alternative.c @@ -464,7 +464,7 @@ static unsigned int __initdata alt_todo; static unsigned int __initdata alt_done; extern struct alt_instr __alt_instructions[], __alt_instructions_end[]; -extern struct alt_call __alt_call_sites_start[], __alt_call_sites_end[]; +extern const struct alt_call __alt_call_sites_start[], __alt_call_sites_end[]; /* * At boot time, we patch alternatives in NMI context. This means that the --- a/xen/arch/x86/include/asm/alternative-asm.h +++ b/xen/arch/x86/include/asm/alternative-asm.h @@ -59,7 +59,7 @@ .macro ALTERNATIVE oldinstr, newinstr, feature decl_orig(\oldinstr, repl_len(1) - orig_len) - .pushsection .altinstructions, "a", @progbits + .pushsection .altinstructions, "aw", @progbits altinstruction_entry .L\@_orig_s, .L\@_repl_s1, \feature, \ orig_len, repl_len(1), pad_len @@ -82,7 +82,7 @@ .macro ALTERNATIVE_2 oldinstr, newinstr1, feature1, newinstr2, feature2 decl_orig(\oldinstr, as_max(repl_len(1), repl_len(2)) - orig_len) - .pushsection .altinstructions, "a", @progbits + .pushsection .altinstructions, "aw", @progbits altinstruction_entry .L\@_orig_s, .L\@_repl_s1, \feature1, \ orig_len, repl_len(1), pad_len --- a/xen/arch/x86/include/asm/alternative.h +++ b/xen/arch/x86/include/asm/alternative.h @@ -90,7 +90,7 @@ extern void alternative_instructions(voi /* alternative assembly primitive: */ #define ALTERNATIVE(oldinstr, newinstr, feature) \ OLDINSTR_1(oldinstr, 1) \ - ".pushsection .altinstructions, \"a\", @progbits\n" \ + ".pushsection .altinstructions, \"aw\", @progbits\n" \ ALTINSTR_ENTRY(feature, 1) \ ".section .discard, \"a\", @progbits\n" \ ".byte " alt_total_len "\n" /* total_len <= 255 */ \ @@ -101,7 +101,7 @@ extern void alternative_instructions(voi #define ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \ OLDINSTR_2(oldinstr, 1, 2) \ - ".pushsection .altinstructions, \"a\", @progbits\n" \ + ".pushsection .altinstructions, \"aw\", @progbits\n" \ ALTINSTR_ENTRY(feature1, 1) \ ALTINSTR_ENTRY(feature2, 2) \ ".section .discard, \"a\", @progbits\n" \ From xen-devel-bounces@lists.xenproject.org Wed Sep 02 07:27:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 07:27:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405187.1638722 (Exim 4.92) (envelope-from ) id 1x1fNS-0002RF-I7; Wed, 02 Sep 2026 07:27:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405187.1638722; Wed, 02 Sep 2026 07:27:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fNS-0002R8-Dj; Wed, 02 Sep 2026 07:27:22 +0000 Received: by outflank-mailman (input) for mailman id 1405187; Wed, 02 Sep 2026 07:27:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fNR-0002R2-Is for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 07:27:21 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1fNR-001mxE-0a; Wed, 02 Sep 2026 07:27:20 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1fNQ-00EwVS-1n; Wed, 02 Sep 2026 07:27:20 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=cVKgxywC1O2zSO0F9vjmJuAEozgqi3gcnsXP3MlROuc=; b=1qksZ6gstlC5xBb2PauzSir3sj Claw11wj8EXIcnjKFiouuASmpux14HNwcbYemUtgqx2PzC5oFY/dzfl9RwNps2fT8czAow3rwY5l4 eUX1SL+nNqI7QGTMvmbP/UMQcfqaXMk80O0eGRMPYrhGLz+Vqtx6LhnepYzcGKO9YNPM=; Date: Wed, 2 Sep 2026 09:27:11 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH] x86/alternatives: mark .altinstructions r/w Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Sep 02, 2026 at 09:15:46AM +0200, Jan Beulich wrote: > Forever since the introduction of the .priv member it has been wrong to > record the section as r/o. > > .alt_call_sites, otoh, is legitimately r/o, hence > __alt_call_sites_{start,end}[] would better reflect that. Right, we don't however have a .init.rodata section, and hence it gets placed in the .init.data section which is r/w. No objection about the addition of const, it's the right thing. > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné I think you want: Fixes: 4008c71d7af2 ("x86/alt: Support for automatic padding calculations") Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 07:32:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 07:32:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405196.1638729 (Exim 4.92) (envelope-from ) id 1x1fS8-0004DI-0l; Wed, 02 Sep 2026 07:32:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405196.1638729; Wed, 02 Sep 2026 07:32:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fS7-0004DB-Tw; Wed, 02 Sep 2026 07:32:11 +0000 Received: by outflank-mailman (input) for mailman id 1405196; Wed, 02 Sep 2026 07:32:10 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fS6-0004D5-5j for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 07:32:10 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1fS6-001n2y-0F; Wed, 02 Sep 2026 07:32:09 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1fS5-00FQNO-1d; Wed, 02 Sep 2026 07:32:09 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=GH8pyiKnuTxeVi4Fbf/zbc4aL42fGhagOTPMBLWcPdA=; b=XPzVjxnSQhk72HQcaAjtyuEnES R6mZQgwL2dANGEzMVWTwxpdbe2ew7gKecrQ215kpSlwIXd1lSN7riH2WLxBw45UQzN12fUdyaC5kT I2YJhNuvRNGp5PWNolr9QDQN8nvaPDJmUrMxpfWw435jplDbWAnRnPoQJhUMMub0fmts=; Date: Wed, 2 Sep 2026 09:32:04 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v5 1/2] x86/CPU: re-arrange tail of early_cpu_init() Message-ID: References: <347cd6bc-e10e-4696-a1d2-1aaa84811370@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <347cd6bc-e10e-4696-a1d2-1aaa84811370@suse.com> On Wed, Aug 19, 2026 at 01:45:31PM +0200, Jan Beulich wrote: > Some early setup doesn't need re-doing after ucode load. Move the call to > initialize_cpu_data() slightly up and add a conditional return point. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > The parameter being named "verbose" may be a little irritating for this > use, yet renaming would incur extra churn. > > Clearly an alternative would be to split the function. I can't, however, > seem to be able to think of a good name for the part that would be invoked > post-ucode-loading. Maybe early_cpu_reinit(), except that calling that > from early_cpu_init() then still feel somewhat odd. No strong opinion. The code that doesn't need redoing seems so little that splitting this might not (yet?) be necessary. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 07:36:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 07:36:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405208.1638739 (Exim 4.92) (envelope-from ) id 1x1fW9-0004v5-KY; Wed, 02 Sep 2026 07:36:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405208.1638739; Wed, 02 Sep 2026 07:36:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fW9-0004uy-H7; Wed, 02 Sep 2026 07:36:21 +0000 Received: by outflank-mailman (input) for mailman id 1405208; Wed, 02 Sep 2026 07:36:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fW7-0004um-Dc for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 07:36:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1fW6-00AbPm-Q7 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:36:18 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97d1ef-2eae-0a2a0a5409dd-0a2a450bdc20-8 for ; Wed, 02 Sep 2026 09:36:18 +0200 Received: from [52.101.53.68] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97d1f0-b7e8-0a2a450b0019-34653544a429-4 for ; Wed, 02 Sep 2026 09:36:18 +0200 Received: from SJ0PR13CA0082.namprd13.prod.outlook.com (2603:10b6:a03:2c4::27) by CY8PR12MB7489.namprd12.prod.outlook.com (2603:10b6:930:90::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Wed, 2 Sep 2026 07:36:13 +0000 Received: from SJ1PEPF00002326.namprd03.prod.outlook.com (2603:10b6:a03:2c4:cafe::95) by SJ0PR13CA0082.outlook.office365.com (2603:10b6:a03:2c4::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.10 via Frontend Transport; Wed, 2 Sep 2026 07:36:13 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00002326.mail.protection.outlook.com (10.167.242.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Wed, 2 Sep 2026 07:36:12 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 02:36:12 -0500 Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 02:36:09 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zFh30hrSgjMlwmaZmFINW9ZQPKEmG0/wLJAcGR8hJ6O93IRWKZQX6vqWaJ4wPkMOkLS632onOf3f5OgyFh54vMn404v8unpjBtH5f9fvymCEGDJFe8+22T9MeySlw0oVPKKtROZcJICZZIzpvg+mi4mo8m7lGq1nvhzqVYoWO7fkB2K9JHRTlKLUq6YQdvxW2p4IhfAGaLI38lYvTg/nddA7A+ymrFVHbBGU1XE9ZkCrqQQMG1EdNLPfYH0/0oVZJCvH8TS1Lo0XAbtfsvLkpmhQ2PCcuFwpieV1LbtqtQrZhpGV76+KmQjkZT3stdZfchr3UH3lRJxxek59QCaIdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AMJG6YY/did3lw8VI5dydANsaKn6RmKRYMhQgxT+AHM=; b=tv2YYcJ9gdbyCt5bC7Luei8R9b1zF4E+jPYRAqhMNStB0M1dZRPiST43+njj3rpzFqpp1Pheqltw7KQIzUiMO+1C7cqw//w7kE7UakbPpqp5AWXLuMPQ9O+NWpiHRIpYE70Ug2xhjSLtvNYkh85Qmv7TqGTcqeqpflUOXJhj00vKi85/O/28DJERVW/1W3u9uvZXnE4WX8pF4zkn3D/EJryw/+5ozYfGTrmqbnrF2zaxnGK9rIFfH/vwoEcrbIl4ViCCC+mxoAJSKgSqBCtMSC/pSc0fg8CyxFF4tjShsxpn4L3cCguTp04S8cwbz53SExY5f2gaTXXGk35BSUlO4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AMJG6YY/did3lw8VI5dydANsaKn6RmKRYMhQgxT+AHM=; b=g6PSb2/yg84S0dn9Lk2oaKpzj/utO3enb7V+3NDPat3uFAC3P7fA/J0jyd8RydOOcvVuM3wUDkk2kIlF0xo3uFqfbKH7iSUZc+IPSl1/XZGVzoN1eZFsVIUdoP2He10KgNDlMfQJ5+aijEsWeLD7+/vizTgqfKuGGpvT6jlajN0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Andrew Cooper , Anthony PERARD , "Jan Beulich" , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano Stabellini" , Bertrand Marquis , Volodymyr Babchuk , Alistair Francis , Connor Davis , Oleksii Kurochko Subject: [PATCH 0/3] dtuart fixes Date: Wed, 2 Sep 2026 09:36:03 +0200 Message-ID: <20260902073606.61062-1-michal.orzel@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002326:EE_|CY8PR12MB7489:EE_ X-MS-Office365-Filtering-Correlation-Id: 80b781c0-39a0-4f2a-5edf-08df08c4dd11 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|23010399003|7416014|36860700016|376014|10067099003|18002099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: JqhBtzYFTbQeKrzzGGIwB01ZuY+PCAx+2xwnKv68eI0K+x938vrGNGt7OypRSN53U+g7uaqdAqNxlQozP7NH1WQ/byzXCM7aLs6g0s1AMNISUenWbXREkT/I7A9xnmWSHjy/QOOyEQJIII7CBbDdzOE6F0I5prqiY9xsgEtyJAijif3p1C28uDxB1KsRFuKnwmmuQS62/d8G5ocXp8oWZcXRcXo+l7eBUCbBj8eqNqpbwqjklds3pSEWQRMdJCol5nZ0UU3b0kW6/6OnbMAcNtOg6pVjRMU+M+AZiYNJPxmOsx2AnBQ+s83m0Ao7Om1Dr7BWTgird7k5nhMLouznN2LgADmv7/9R+MGZpEklKiG6RLqc15DUiKG7FM/XoLc0V4B30v2fbMIvgSd1Ea7LWAf/6iKkxXWlorOdD+BUO2yM0Haevr3Ovpb8va7KmPuIe/QMREWDbWkGrHgnBb2Sy/4R5tw4AG7VFnybhhpBuVqY7QaglRB4KLHS5HfGxBqzcuVnmEG16PneDtHIx2PXYU4A+ULHa7tOMVJbfIp8RTgVGFxQsbv1NzPveU3caBbbUQYHaoSxIPhvn9dhI0za20L20jq3SjBYWgtJHG/bRtKzbhXlG6vhXyEV4ZKxGetFCQtwMuw0wVohzVsvQA6F/a+9Dr7NBZgClol+18uz5jud7LcbD/hGPq0t77txuFLFv61n6mnXgZ7fdsE1X+Zqlg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(23010399003)(7416014)(36860700016)(376014)(10067099003)(18002099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Sp2d8ValGr5u4XQDOeFdqwW3HlHajRhQJMxp/qz/sQR64yEsfMbFcfQi047vKDrta5dIHqCpHshxaDfZ3lGsSKY1trCcixywmvwzkGDtlCgSPQU6ekyquHNaGFHv1I5AK2V1JX6DxsjizFl84FQ8K02sV3V8IMVfHcHSNA/P5LGhyVV0VFMoJ845z9b0ICEvegzyun2G1RaebOkZwCRJX3OxlacxeIiTbzjiOQR1oD+G6BqeYNLWSHMyvJu1yMy12zM4l2EM3x/gg3v8Ya0++1VEocwc/LpHJDo5pORsb2P2UhebkgWZPLowKVRP7kcKytko760B06YZzWAeI7nj90D/l0seqTSzQn7Gsu4uDKZg+rbKMEDCVCRlSgy9RTObvN9/sYvRgueW4SiObn/vf+HXOdoRb6I+5+a/dM2VxvXW2dIsaswi2MacRryYSr4A X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 07:36:12.4685 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 80b781c0-39a0-4f2a-5edf-08df08c4dd11 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00002326.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7489 X-purgate-ID: tlsNG-42698a/1788334578-AAAD89EA-3F566B4F/0/0 X-purgate-type: clean X-purgate-size: 531 Michal Orzel (3): cmdline: Document console=dtuart option drivers/char: Check if console=dtuart for ACPI SPCR serial bring up drivers/char: Panic when the requested UART fails to initialise docs/misc/xen-command-line.pandoc | 13 +++++-- xen/arch/arm/setup.c | 5 ++- xen/arch/riscv/setup.c | 6 +++- xen/drivers/char/uart-init.c | 56 ++++++++++++++++++------------- xen/include/xen/serial.h | 6 +++- 5 files changed, 56 insertions(+), 30 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 07:36:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 07:36:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405209.1638744 (Exim 4.92) (envelope-from ) id 1x1fW9-0004xi-Ry; Wed, 02 Sep 2026 07:36:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405209.1638744; Wed, 02 Sep 2026 07:36:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fW9-0004xU-Ou; Wed, 02 Sep 2026 07:36:21 +0000 Received: by outflank-mailman (input) for mailman id 1405209; Wed, 02 Sep 2026 07:36:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fW8-0004us-MJ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 07:36:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1fW8-006Bv5-2z for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:36:20 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97d1ea-8faa-0a2a0a5109dd-0a2a4505bca0-36 for ; Wed, 02 Sep 2026 09:36:19 +0200 Received: from [40.107.201.54] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97d1f2-4cb1-0a2a45050019-286bc9360c1b-3 for ; Wed, 02 Sep 2026 09:36:19 +0200 Received: from BY1P220CA0044.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59e::10) by PH9PR12MB995114.namprd12.prod.outlook.com (2603:10b6:510:426::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Wed, 2 Sep 2026 07:36:14 +0000 Received: from SJ1PEPF00002322.namprd03.prod.outlook.com (2603:10b6:a03:59e:cafe::a1) by BY1P220CA0044.outlook.office365.com (2603:10b6:a03:59e::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Wed, 2 Sep 2026 07:36:14 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00002322.mail.protection.outlook.com (10.167.242.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Wed, 2 Sep 2026 07:36:14 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 02:36:14 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 02:36:13 -0500 Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 02:36:12 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ffia8CDU6d0Vbp2q3VpONepV6pXgvCBR+kHtlKQUAXqgD9XgkkfzdIKoO0BKVmpjghuA80B77ZPB3Cp1cuF0XtavZOmxJv4go2Ikpy2QzPalEw7d2DPgSTXhrZjHapcz2VqLiVvKhkQw172FPq6ZdL13Nf7ydrEqA1V5ymLEmOEG6k52beoVclUqwNoU0M2pb+wfd3coiHDvFhfGMrwy0QOi31toV09GD8LdgAd8WpE+aRhX+3dms7J8H7zqtY6CNkKi6UygltAtEHtEHt24KyJZ/GXX2qiDUTQy11a0+RZf/+EXmiDV2crOZ6Dyng3BffHlhm7G6IeoeQP+Q6FoJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oHPYvwj3xZPuM6fAr56NZQu/gReDAWZUwAt7EEUP2/Y=; b=UoZG0bW0NIgJq1t4fCSFP0qgxEPhTwb345tAHLJo2Ghq3O1YK3d/4DyvpZlZhNV7eReZO/qWswCIM7HDRLP0/aIBZ9/17NS6gTcjDchEmY1u4/f/f5Fs+BH5p+3SyjmkBGtpT9VIF7AeLM908bSUEwSnudmej2d9XZJ7frp4CW74CLbVdP8419oDqaWcXQE37SSZNd8n7fWBRrEStsOC5HUenrgGZkrjVjAY/+H/ZLhvTGV98PrFQmcce7KFyTXZc9cYbvfH0Mwgr7x89z0vwVkvOdTUHLb9YAfTuKZs2RMD7Qx3uXzoPVekZrctBNbtidubVTWutkBhq5TiHejnLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oHPYvwj3xZPuM6fAr56NZQu/gReDAWZUwAt7EEUP2/Y=; b=h/FaoH9rAG4//TJWOb98rqw0bURm1CP+UPd6fwb9hHA+DgPPW381HiU2Q4BF5JrVjp7xqmc1XJzYadkFXEhqnmdezS5sGo7ywOZ9iZhZRptdIOCbC37uWyPXUMdbadMMjR1fb9njmDUKjAgjXSsxKY6qGEbefyh2HkIA9hr6KcA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Andrew Cooper , Anthony PERARD , "Jan Beulich" , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano Stabellini" Subject: [PATCH 1/3] cmdline: Document console=dtuart option Date: Wed, 2 Sep 2026 09:36:04 +0200 Message-ID: <20260902073606.61062-2-michal.orzel@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260902073606.61062-1-michal.orzel@amd.com> References: <20260902073606.61062-1-michal.orzel@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002322:EE_|PH9PR12MB995114:EE_ X-MS-Office365-Filtering-Correlation-Id: 3b67b044-ee8f-4be9-31d7-08df08c4de45 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|1800799024|376014|23010399003|10067099003|11063799006|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: ggNiMFDikYcJUCWNuA87/1e1LSPNa4WJdb/ZaRkA0CLWCk04BfbRFP87bj6DVlPURGVspdHMBwk0ncN8YKNTq1Wny24FOWn4lD6NxsrTF6sqOFbN4howbjbmHA3ErzCeyjnWKnADL4b0EiayX0x5PwfaX/WBXFZ28zbhkdBY77VSe1DU3SwfwmpNHJ+vyUenmX4Ct8K86IDCBN63cKzN+hG+SSWnjpJAE90z0aObzBsCeo0c0BHMrvhgJpFSfnTiCa5ZvQi6uR0bFXeZJpRwprVaKYR9oW/zLNC4N64Y+QXualnN5DL3V6DiiLSX3XyfpBy4GAZruTwTh40x8+nRobkmBrDiF/8PrNaIF8aTOUkprk98oW3wfsOCz9qxjhUh8jtbAq9OdBSWbb0ny650A0VzLtye05ToPFqbuVxiGajRu4/ULu+PuD6UaKnPT/+bRwsUB0g34odl4NYAsGR3jHkLC+x+BK2cgrcYbyNImoDoloorYD2++PQt6tHmsR9Zhj5CR9KAiP4cTwFI37nxNCA36T7PaPIs2liEYitjDXjHh9Hzdqojy2xfBE9ky61BdlRM/Nw+I0RVNqs8KVucal3Sjk9s/j+uxN02XjlO0itar5H+Xui2RF/ga3YlfEsh9sAHEZtrD99098eydd8DDfUvfM8pdTBn1f5rrovAYXyJhMbcc2Ln8f6+8XG1+/wuOQXjt/+Vwa6PnahDew6a8w== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(82310400026)(1800799024)(376014)(23010399003)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: JCT2R0RDJWSfLSKMm2og5i6hbSYE/spt0vyAUDXnzOS+gskgAG7E7KxAk8flBg3xk50UD7sWPw6qJlTm1UJt9Giq+9ooWYS8v30YlxssgHzkk70BX77rf0aNp2/LUS8ZEOO1AuM6lowDYs7fNGy7iv2x+Uhj6gE9utzEl8R6TGyixJs/OXRGME8C+rwimXhoGhscs+TnE5VvxURXAjjWYIwzwbRx9E601lauMipDl9jcopZYbf0Uiv/DkTXSTRyRObMiDXGt12s2vzSZaGwMxet1KfpUv6wZUMG7kZaARI4uMak80OMDQowBYHORiGLeV42Z7vCZQCxquDb1q7zDJ9Lb18A8PAcFy2cxLyVkm8qN59kb5sRVPY/vUwlhfT3KAFRD3vd91ItTgfeSD9hqWMsm7dKc2gYW43fgw67rrja+1CJ3bzIm4vYf1/vcsvJH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 07:36:14.4863 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3b67b044-ee8f-4be9-31d7-08df08c4de45 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00002322.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH9PR12MB995114 X-purgate-ID: tlsNG-c201ff/1788334579-73ABF2A1-4C74B2B8/0/0 X-purgate-type: clean X-purgate-size: 2214 Document the default console= option on Arm and RISC-V that is "dtuart" indicating a generic UART parsed from a device tree or ACPI SPCR table. This serial utilizes SERHND_DTUART handle. Take the opportunity to: - fix documented x86 default to vga to match OPT_CONSOLE_STR, - mark dtuart option as available on RISC-V, - document fall back to /chosen/stdout-path. Signed-off-by: Michal Orzel --- docs/misc/xen-command-line.pandoc | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 1c711fa98086..3a416a38b74c 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -430,9 +430,10 @@ The following are examples of correct specifications: Specify the size of the console ring buffer. ### console -> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]` +> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | dtuart | none ]` -> Default: `console=com1,vga` +> Default (x86): `console=vga` +> Default (Arm, RISC-V): `console=dtuart` Specify which console(s) Xen should use. @@ -454,6 +455,10 @@ compiled with `CONFIG_XEN_GUEST` enabled. `xhci` indicates that Xen should use a USB3 debug port. +`dtuart` indicates that Xen should use a generic UART (parsed from a device +tree or ACPI SPCR table). Only available if Xen was compiled with +`CONFIG_GENERIC_UART_INIT` enabled. + `none` indicates that Xen should not use a console. This option only makes sense on its own. @@ -1069,13 +1074,15 @@ affinities to prefer but be not limited to the specified node(s). Pin dom0 vcpus to their respective pcpus -### dtuart (ARM) +### dtuart (ARM, RISC-V) > `= path [:options]` > Default: `""` Specify the full path in the device tree for the UART. If the path doesn't start with `/`, it is assumed to be an alias. The options are device specific. +If the option is left empty, Xen will try to probe the device from the DT +property /chosen/stdout-path if present. ### e820-mtrr-clip (x86) > `= ` -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 07:36:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 07:36:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405210.1638757 (Exim 4.92) (envelope-from ) id 1x1fWF-0005Mm-3Q; Wed, 02 Sep 2026 07:36:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405210.1638757; Wed, 02 Sep 2026 07:36:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fWE-0005Md-Vl; Wed, 02 Sep 2026 07:36:26 +0000 Received: by outflank-mailman (input) for mailman id 1405210; Wed, 02 Sep 2026 07:36:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fWD-0005LZ-Vd for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 07:36:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1fWD-00AbTn-C2 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:36:25 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97d1ea-2eae-0a2a0a5409dd-0a2a4504ea94-44 for ; Wed, 02 Sep 2026 09:36:25 +0200 Received: from [40.93.196.2] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97d1f7-b57f-0a2a45040019-285dc402c94b-3 for ; Wed, 02 Sep 2026 09:36:24 +0200 Received: from BY1P220CA0014.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::9) by MW3PR12MB4378.namprd12.prod.outlook.com (2603:10b6:303:52::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Wed, 2 Sep 2026 07:36:19 +0000 Received: from SJ1PEPF00002327.namprd03.prod.outlook.com (2603:10b6:a03:59d:cafe::6a) by BY1P220CA0014.outlook.office365.com (2603:10b6:a03:59d::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Wed, 2 Sep 2026 07:36:19 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00002327.mail.protection.outlook.com (10.167.242.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Wed, 2 Sep 2026 07:36:18 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 02:36:16 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 02:36:16 -0500 Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 02:36:14 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ruiZ55ql3MHuqd4kyhExdrhBVftriaLYAD+O/sZi7YkSA9t5frXV92mABVBkvDW+JSqZUcuvvw9jYCuC1jE8aPQCeFLnhhLk2PSpiNx5FsAoUkiBBCEkxtWmxHH7ub3y93WbYqYppfycAowjsAT4CqGXQad8ZlV4U7fg7LjR761ZXXo0xkPIWFU4Oq4hsm4VJCmG13lY6ug/PItsh1vxJs+eknIuZiEqeEcZpkoIabLplrjYlPYy53+os+9X5XepsiG325kXiYL0EG6qecZXmr0s+x/oyrGXmgP23pp/Z9Hd5bQvTUTiEmCtsOan1+bWpSGBAYSiH+FE3bHtxRG1qA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T0Km7Tc1xeK6Y+oTde3bVSSHLb0d+PMC+KbuvBwG/aM=; b=HujfN4uzT9W7d0GdV/nXy9usB04kHIrD3uX5ZNQPdNPpKB0gk6JgML/lSfBftNZfIN6av93BYuTRSqRdpp3BcdzMLjr4vLkyxutxplLs/xlQVVtipfN4gT7htrpyMxQViN/FhYtpxsejVqI92tvF9lbSFHKbj8jnSzDuf9YSQ0uQML+EdyjD5jS1/oRPhsDMqqQIRMzuTn8mTEJ/ZJW/o9BORrL5WRCpHx3Lnodv35FZbsAVF7AINuDPj0fHoy1WaW2Ejx39ZnZ60NXQX6GdR2gp09Xtg6MKmX5CpgNHSJqMt/nzetHijKHX1rQVJVte2UKkJLtUBhJm8mdi1BQJTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T0Km7Tc1xeK6Y+oTde3bVSSHLb0d+PMC+KbuvBwG/aM=; b=I3c8IQ7KSO1LofH4zjhZliFbtI+dNawN3diSpQNmpHzCKej1DY278qabCB6uBB5oPt/vd6D3Wzv/qQAequPU0fckQW5LRp/4Tiu0URLmGuWIr5pAcXRPw3gp5Q0mibrU5a/H/vxSGGOxRA/tZkTesf7Xzrh+SVLlGn8xYfYZiNk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Andrew Cooper , Anthony PERARD , "Jan Beulich" , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano Stabellini" Subject: [PATCH 2/3] drivers/char: Check if console=dtuart for ACPI SPCR serial bring up Date: Wed, 2 Sep 2026 09:36:05 +0200 Message-ID: <20260902073606.61062-3-michal.orzel@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260902073606.61062-1-michal.orzel@amd.com> References: <20260902073606.61062-1-michal.orzel@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002327:EE_|MW3PR12MB4378:EE_ X-MS-Office365-Filtering-Correlation-Id: 3e1eebe0-8f56-4cf0-36a0-08df08c4e0f0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700016|376014|23010399003|10067099003|56012099006|5023799004|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: btRi+gCgVcVTQQ6LxvWDx1UoudHSu7iIaGZg63j3h2wXvVu+33S+JcYVLMl0xJLFO6852x/uPvkAAVfk5bHSuciI2NATt4qj5j45sb1/y2eEBwU91qgnRrSqHIOHywS/Aw5S4E6kEzF7QcDG8k0Iupnn3/V4CEGZayONddEU7OtULpjwHl/A/afbrKQ0vbpfOZ+vsm+SsX/0eOtbT5fPT9AKilJ8I5gkWdJWlamPZIFrJqRI+2FH8EIO0CGu1oUnn7iu9VJRjJ2/YbdevnBD6qTNfRttEWNV8413IICZxD8tNC1Gq6mCbyqEw7rI/0XgezMONI8osnsV4n9AvY1f3nFUm0c3m93bwb08049pxwIKtUi5ri5hIVtYYO5QOKlTfk4QuPOsUyX55pp6dvgyY/fjID0CSf7kPySXTaVxwga9CDeX8dic15dQBS3O2Qc2Ga745uKVuMHHonwofdvCQx+MTLUOCqzzDT1KpiyBAeG2IVtI1H7UFZMuM/4ne7+H9ajkpBYH1DNFUYqitSzuej5xZ44ty5kacmBkiGdI2kg7vo2n2+EbswFmz4zbqvjvoDTdp1qpLVzBW+4uHsE1PRuiY9oKPPMW2iZUzYucBn2VgtH0tdIaU+fMdJavzjcH2Kw4JOfl4GqUpBIwFzE+sZ3FXHieFlPc5JeJHKfgs7CKZLLvWw6SGNX0Xy9uCga9WuqvXik303SRsPeKGGUaxA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(376014)(23010399003)(10067099003)(56012099006)(5023799004)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: rvlXpI3B5D+dPkXML7sviu/KWyCWEs1w/Xn5xOGpnW2oWAbwrZXhvH7hdTrjpkDaqkS1fHSFTdbhMXUKesv/EP+NlT4WjKvCrAag+6KH4BCos1LBIPmoSMtl+XgpDen734sX0rtkc8R3L0FNKSD09KuT7mw+HevI0NTrmgrYX2ijmA3enZkt5uKniAG+j54BfSPdou4oBxVPJS3Y+N5FbZ/R71I4ITQJDxVABxanQKkJKN8LTPvceokYqoZXkFhz11BMVBrwMG63hd141wLX44KTrFNGwnjkjFtvD2ijwUsMu1Yt5kYsAZNMS7qY8P6s0qC9rpzwx9zvbC+yHILvhP+TxYMn2j2bw2zj3GsnEtasqK3HOt7yStgjH+TNN+mdFWjQVEh0f/aewtml/6YSzW605dgp867FNytmX98Gs82C75nEii14QucseBEcT79Y X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 07:36:18.9334 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3e1eebe0-8f56-4cf0-36a0-08df08c4e0f0 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00002327.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4378 X-purgate-ID: tlsNG-ebf023/1788334585-C1CD7B50-13E7476A/0/0 X-purgate-type: clean X-purgate-size: 1335 dtuart denotes a generic UART parsed from a device tree (back then it was the only method, hence dt prefix) or ACPI SPCR table (they all use the SERHND_DTUART serial handle). Currently we only check if console= is set to dtuart in the DT flow and not in the ACPI flow. This means that even if we set console=none we would still bring up ACPI parsed serial device for nothing. Move the check to uart_init() to cover both paths. Signed-off-by: Michal Orzel --- xen/drivers/char/uart-init.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/drivers/char/uart-init.c b/xen/drivers/char/uart-init.c index a2181399389f..eb7f85549593 100644 --- a/xen/drivers/char/uart-init.c +++ b/xen/drivers/char/uart-init.c @@ -38,9 +38,6 @@ static void __init dt_uart_init(void) const char *options; char *split; - if ( !console_has("dtuart") ) - return; /* Not for us */ - if ( !strcmp(opt_dtuart, "") ) { const struct dt_device_node *chosen = dt_find_node_by_path("/chosen"); @@ -121,6 +118,9 @@ static void __init acpi_uart_init(void) { } void __init uart_init(void) { + if ( !console_has("dtuart") ) + return; /* Not for us */ + if ( acpi_disabled ) dt_uart_init(); else -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 07:36:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 07:36:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405211.1638766 (Exim 4.92) (envelope-from ) id 1x1fWH-0005cK-Cm; Wed, 02 Sep 2026 07:36:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405211.1638766; Wed, 02 Sep 2026 07:36:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fWH-0005c8-9v; Wed, 02 Sep 2026 07:36:29 +0000 Received: by outflank-mailman (input) for mailman id 1405211; Wed, 02 Sep 2026 07:36:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fWG-0005Yd-7a for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 07:36:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1fWF-00AbTn-Kp for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:36:27 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97d1f9-2eae-0a2a0a5409dd-0a2a450489c4-14 for ; Wed, 02 Sep 2026 09:36:27 +0200 Received: from [52.101.56.28] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97d1f9-b57f-0a2a45040019-3465381cd0e9-3 for ; Wed, 02 Sep 2026 09:36:26 +0200 Received: from BY1P220CA0039.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59e::7) by DS0PR12MB999288.namprd12.prod.outlook.com (2603:10b6:8:424::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Wed, 2 Sep 2026 07:36:21 +0000 Received: from SJ1PEPF00002322.namprd03.prod.outlook.com (2603:10b6:a03:59e:cafe::18) by BY1P220CA0039.outlook.office365.com (2603:10b6:a03:59e::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Wed, 2 Sep 2026 07:36:20 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00002322.mail.protection.outlook.com (10.167.242.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Wed, 2 Sep 2026 07:36:20 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 02:36:18 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 02:36:18 -0500 Received: from APPOL-18KY0J4.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 02:36:16 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YEzISwQ84XgqB0ZzR1HbpBwRw+me3Pm80+4F6xlRKJhI6NXRTtSV4PxrT+74THsr11Et3WcIv8q3uRncc6FN5s5+stBlH7sE/9mOlkjsUq+djPzR+cipHZEvL6QirrbxtrqYWhc4j3zMFlhJSLx6d+jnNa6QJbRWDT8t1HtO3KpQGmVMz2JTIdn9ArF+ongc+KECMzJH3Z1y1Yv2mtw0ZDFnwBWVHLMt5hWYUCP6Acut2yK+lD1kjjceAATQOz904F5BrMRgeahIUmB2RlWBEAHTnPraOVVNYo6nd/kmd652cheIz5rjWuLGSRue+Qcv7y8gF+xVilFeTSjPGdd4+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yoClwoPRx+rVoH90jrgZnJbWUIYvOiLRrYE1TxOYvoM=; b=T/vfSFtavqWzoFZbDgXyBYju2y2P4tItG7FhM6FaTgjztusA8oVXEl4yNlZx5gk0VF9mlv5avoPqv73a2Y2YiCX727LtQRvT/AiC2ophep0DzpV0hYlXj6J88ly+qfvvjL8T0U153FzhV0cF2N080sRT+nZIwCnpS0h2noElyy+wes6uDIB8ZbaKhHZydy+DkmIRKnxLtFneGKt4D5uQsEV8hGpxGE19MsdEl9SIOCx/LYWTS/nZJVgI/TvzX60Zb5Vm8mRmVC6rY9FUH4N5TJXl0VwElWholBDbJaeKkrB9J2Ozv8skObY4XsLt25JJ2R0cHfDxtsBqVtlEuZ+8Qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoClwoPRx+rVoH90jrgZnJbWUIYvOiLRrYE1TxOYvoM=; b=EmUbQ9CX1BNWXRkVkEDtf6WxAN5IVgkgHxENnWLjPT3VoEORydAAiR4h6xV6ze9hQX0rxt3M6YvFUd1mjGQl3m0WUsvtcWIXs03ZNE6I+WPsQ9M47SGuCBAQ3l8XouLJPwWTLnN1T7d+jsOjXoHLz8p7Z1JXDywo77n+UmGuHbc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alistair Francis , Connor Davis , "Oleksii Kurochko" Subject: [PATCH 3/3] drivers/char: Panic when the requested UART fails to initialise Date: Wed, 2 Sep 2026 09:36:06 +0200 Message-ID: <20260902073606.61062-4-michal.orzel@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260902073606.61062-1-michal.orzel@amd.com> References: <20260902073606.61062-1-michal.orzel@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002322:EE_|DS0PR12MB999288:EE_ X-MS-Office365-Filtering-Correlation-Id: 10646f25-b374-42d9-bd4f-08df08c4e20c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|23010399003|7416014|36860700016|376014|10067099003|6133799003|3023799007|18002099003|22082099003|56012099006|5023799004|11063799006; X-Microsoft-Antispam-Message-Info: LYXTnWg8pzguaX9iGFTwT6p5KPwjpciyLG7VqkPx6xyd8VPMnE+ubyLfIxUoP3ejSc0PHi7tOGSPnW4OOVt2cwu9GdfT1aptwZwkpoucw8sljxUGAmJObCgCE4FF5XXnLbACiU73PK/Nd6lEmZ7Hwfu6+nWBgFv6fJmGKo5kTCEeXFjbXDcsWx9DZ/xJesXoBs6MPzcnhJ8lUCVEYwVXZWwpaeWWESz0b4r7LbLTUCg2Mf9YC4HlMBs7yRkpewc2PExOnZnYf9wLUp4+8lGo+LmbhrmPKERdwGMc+7FmTO3RZAi0CIfZTJUY46WHk4Htj/id/KrekgwhRBcTtKLW+/EQQ/84FDW5+8JAkEjlxvS30Dmh39IvUTmmoeEA8622BogqsFODlWwMo6UHvsHfoyJB96m1LgRQooknyfqybSpfpQouXypD7eX1Hw6Rdrhk5HLHqMByXB7xG5yY+NnyfUHsbK9KPRXvIWuyxDMXlTKOXfNoSBg5AqirZN4Hp7Db0Ssuwq31BzrGJdUpTFtbbIE4fRbBuakBw+V73PbArzcgMo3DdlehwqQVYbPrcqXxX20mSpKpcyF43Z1oHR/jW+i/PWSrxNmpiuuQMh4ZuvlCYtQPw1pKW/QO1/KuJ5NU/JwVpjCkZIDUQfpCfzq++UQW0L6pPd/xdKzv2HDby+eXs4D1iy6Xu+Veu2C985KbnvyFj+4q5JhBPdDcDs0TAA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(23010399003)(7416014)(36860700016)(376014)(10067099003)(6133799003)(3023799007)(18002099003)(22082099003)(56012099006)(5023799004)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: BwZrWZNkPynlZPPvZqrDT2AI9+Py690EvaCNAH0keNnP8DMMVwNYAUqFqDl/zLGEI9pqdKtGHWnfe7O5vx0egH6fJyu99dFPnQDENCIE35utYf5ZLpK3jl1IB/SIQLr5AnX5aTiJSRwZa/9bKp6eaoCzc/VJQKsnMEQq2pLdwPkaKpYMTuzxljR/YKtcJQiMEKZBPP3XCk7q6+q4DS36xfqiEez4j0pi0dbM0WDSfsZ4pwnIBtVnR53+2LL1SUHxlVkz/Jx9lnb/MPF11otp7mFLnDiD8xtJSlc4Z1q+d8JpCXh7qpjq3N36dLU1ZNeSHTPkW24b0a6cUAnXcBV0gyuXJW8Ywn2MM2vWq6UiYnHCyZdLydsdlMMMG7peb2mp0yxfxMEcWifVuA4T08zUFdQpo7UH5BvOwQ85/qNP6NLcVh1SQT7COIb0xNqpSWHA X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 07:36:20.8276 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 10646f25-b374-42d9-bd4f-08df08c4e20c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00002322.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB999288 X-purgate-ID: tlsNG-ebf023/1788334587-C08D9B50-FA0CC9A4/0/0 X-purgate-type: clean X-purgate-size: 6552 uart_init() cannot tell its caller that the UART the user asked for did not come up: every failure path only printks. Arm and RISC-V carry on into console_init_preirq() and boot without a console, rather than refusing to boot as they do elsewhere when a user request cannot be met. Return an error from dt_uart_init() and panic in start_xen(). An explicit request Xen cannot satisfy should stop the boot rather than silently degrade it, which is what start_xen() already does for the rest of the boot configuration. Only a path given on the command line counts as a request we have to satisfy. Falling back to /chosen/stdout-path or acpi_uart_init() therefore never fails. SPCR is firmware provided, the analogue of stdout-path, and there is no ACPI equivalent of dtuart= to make an explicit request with. While here, decide whether the SPCR table was found from the returned acpi_status rather than from the table pointer, which was only NULL because the caller initialised it - acpi_get_table() writes it solely on success. Signed-off-by: Michal Orzel --- With this change diagnosibility decreases only for a single scenario: when dom0 is reachable not via console (e.g. network) and you'd have used xl dmesg to read messages from the conring. On Arm (I suppose RISC-V is similar), given that safety becomes the major use-case and we need to satisfy all the user/guest-xen contracts, I think the patch moves us in a direction we already chose (i.e. we panic on every boot failure where we cannot meet the requests). --- xen/arch/arm/setup.c | 5 +++- xen/arch/riscv/setup.c | 6 ++++- xen/drivers/char/uart-init.c | 52 +++++++++++++++++++++--------------- xen/include/xen/serial.h | 6 ++++- 4 files changed, 44 insertions(+), 25 deletions(-) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 6310a47d68b6..d0066db42e7c 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -379,7 +379,10 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) gic_preinit(); - uart_init(); + rc = uart_init(); + if ( rc ) + panic("Failed to initialize the requested UART (%d)\n", rc); + console_init_preirq(); console_init_ring(); diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index 56a0907a855f..07f46ac3ce27 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -77,6 +77,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id, { const char *cmdline; size_t fdt_size; + int rc; remove_identity_mapping(); @@ -149,7 +150,10 @@ void __init noreturn start_xen(unsigned long bootcpu_id, intc_preinit(); - uart_init(); + rc = uart_init(); + if ( rc ) + panic("Failed to initialize the requested UART (%d)\n", rc); + console_init_preirq(); intc_init(); diff --git a/xen/drivers/char/uart-init.c b/xen/drivers/char/uart-init.c index eb7f85549593..b79135be9620 100644 --- a/xen/drivers/char/uart-init.c +++ b/xen/drivers/char/uart-init.c @@ -30,15 +30,17 @@ static char __initdata opt_dtuart[256] = ""; string_param("dtuart", opt_dtuart); -static void __init dt_uart_init(void) +static int __init dt_uart_init(void) { struct dt_device_node *dev; int ret; const char *devpath = opt_dtuart; const char *options; char *split; + /* Set on the command line, as opposed to inherited from /chosen */ + bool explicit_request = strcmp(opt_dtuart, "") != 0; - if ( !strcmp(opt_dtuart, "") ) + if ( !explicit_request ) { const struct dt_device_node *chosen = dt_find_node_by_path("/chosen"); @@ -62,7 +64,12 @@ static void __init dt_uart_init(void) if ( !strcmp(opt_dtuart, "") ) { printk("No dtuart path configured\n"); - return; + + /* + * console=dtuart is the compiled-in default, so an absent dtuart= is + * not a failed user request. + */ + return 0; } split = strchr(opt_dtuart, ':'); @@ -83,48 +90,49 @@ static void __init dt_uart_init(void) if ( !dev ) { printk("Unable to find device \"%s\"\n", devpath); - return; + return explicit_request ? -ENODEV : 0; } ret = device_init(dev, DEVICE_SERIAL, options); - if ( ret ) printk("Unable to initialize dtuart: %d\n", ret); + + return explicit_request ? ret : 0; } #ifdef CONFIG_ACPI -static void __init acpi_uart_init(void) +static int __init acpi_uart_init(void) { - struct acpi_table_spcr *spcr = NULL; + struct acpi_table_spcr *spcr; + acpi_status status; int ret; - acpi_get_table(ACPI_SIG_SPCR, 0, (struct acpi_table_header **)&spcr); + /* SPCR is firmware provided, so nothing here is a failed user request */ + status = acpi_get_table(ACPI_SIG_SPCR, 0, + (struct acpi_table_header **)&spcr); - if ( spcr == NULL ) + if ( ACPI_FAILURE(status) ) { printk("Unable to get spcr table\n"); + return 0; } - else - { - ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type); - if ( ret ) - printk("Unable to initialize acpi uart: %d\n", ret); - } + ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type); + if ( ret ) + printk("Unable to initialize acpi uart: %d\n", ret); + + return 0; } #else -static void __init acpi_uart_init(void) { } +static int __init acpi_uart_init(void) { return 0; } #endif -void __init uart_init(void) +int __init uart_init(void) { if ( !console_has("dtuart") ) - return; /* Not for us */ + return 0; /* Not for us */ - if ( acpi_disabled ) - dt_uart_init(); - else - acpi_uart_init(); + return acpi_disabled ? dt_uart_init() : acpi_uart_init(); } /* diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h index 8e1844555208..3a71da767dd7 100644 --- a/xen/include/xen/serial.h +++ b/xen/include/xen/serial.h @@ -170,7 +170,11 @@ void xhci_dbc_uart_init(void); static void inline xhci_dbc_uart_init(void) {} #endif -void uart_init(void); +/* + * Returns 0 unless a UART explicitly requested via dtuart= failed to + * initialise. + */ +int uart_init(void); struct physdev_dbgp_op; int dbgp_op(const struct physdev_dbgp_op *op); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 07:55:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 07:55:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405243.1638776 (Exim 4.92) (envelope-from ) id 1x1foJ-0001em-SB; Wed, 02 Sep 2026 07:55:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405243.1638776; Wed, 02 Sep 2026 07:55:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1foJ-0001ee-Nk; Wed, 02 Sep 2026 07:55:07 +0000 Received: by outflank-mailman (input) for mailman id 1405243; Wed, 02 Sep 2026 07:55:06 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1foI-0001eX-5b for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 07:55:06 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1foH-001nUu-2h; Wed, 02 Sep 2026 07:55:05 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1foH-000Bhn-0o; Wed, 02 Sep 2026 07:55:05 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=33bY+Pa+vCB3mUBZSbOk3D2VYDai91OBIYy5CuGPQ4I=; b=CtO4Qo0qqdndZOEmSxXz5JJJ8O tJhUG7K6RfXMq4y4WIpj979q/Xe0er05pPgFQlbF/rfdFBQxHtDV0C5y52pmAB/Np5gRTbv56Ovev Ia6EEo6SEc8N2scmjWhGWIXMkj9DkFj63UtC7bNLIzbAu2+JwTgy9MLFaSJNl9k56Mts=; Date: Wed, 2 Sep 2026 09:54:55 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v5 2/2] x86/time: avoid early uses of NOW() to return zero Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Aug 19, 2026 at 01:45:56PM +0200, Jan Beulich wrote: > Waiting loops like the one in flush_command_buffer() will degenerate to > infinite ones when used early enough for NOW() to still return constant > zero. Make sure the returned value at least monotonically increases. When > available, use nominal frequency values as initial approximation. > > Do this only in get_s_time(), as producing a sane value in > get_s_time_fixed() for non-zero inputs won't be reasonably possible. > Put an assertion there. > > Reported-by: Roger Pau Monné > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné One minor comment below. > --- > RFC: While generally the mentioned waiting loops will take longer to time > out, on a very fast CPU tight loops may time out too early. > > With "x86/time: set AP's TSC scale estimate earlier" the counter update > may not need to be atomic anymore, as then only the BSP can reasonably hit > that path. > > I don't think Fixes: tags should be put here. If we did, we'd have to > enumerate all introductions of early uses of NOW() (or get_s_time()), with > the exception of those dealing with getting back 0 (which I expect is only > printk_start_of_line()). Will want backporting nevertheless (unless deemed > too risky). I agree with backporting, current behavior of getting stuck in an infinite loop is worse than timing out earlier than expected (which is the worse outcome of this patch). > --- > v5: Move addition to early_cpu_init() down. Adjust commentary there. > v3: Use "high" / "max" freq if "nominal" isn't available. Set NOW_good. > v2: Add assertion to get_s_time_fixed(). Use nominal frequencies for very > early setting, if available. > > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > #include > > #include > @@ -444,6 +445,39 @@ void __init early_cpu_init(bool verbose) > > if (!(c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) > park_offline_cpus = opt_mce; > + > + /* > + * If nominal freq isn't available, use highest, thus causing NOW() > + * output to move more slowly. See preset_tsc_scale(). > + */ > + if (c->cpuid_level >= 0x15) { > + cpuid(0x15, &eax, &ebx, &ecx, &edx); > + > + if (ecx && ebx && eax) > + preset_tsc_scale(DIV_ROUND_UP(ecx * 1UL * ebx, eax)); > + else if (c->cpuid_level >= 0x16) { > + /* Assume CPU base freq ≈ TSC freq. */ > + cpuid(0x16, &eax, &ebx, &ecx, &edx); > + if (eax) > + preset_tsc_scale(eax * 1000000UL); > + else if (ebx) > + preset_tsc_scale(ebx * 1000000UL); > + } > + } else if (c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) { > + unsigned int nom_mhz = 0, hi_mhz = 0; > + > + amd_process_freq(c, NULL, &nom_mhz, &hi_mhz); > + if (nom_mhz) > + preset_tsc_scale(nom_mhz * 1000000UL); > + else if (hi_mhz) > + preset_tsc_scale(hi_mhz * 1000000UL); > + } else if (c->vendor & X86_VENDOR_INTEL) { > + unsigned int hi_mhz = 0; > + > + intel_process_freq(c, NULL, &hi_mhz); > + if (hi_mhz) > + preset_tsc_scale(hi_mhz * 1000000UL); > + } > } > > void reset_cpuinfo(struct cpuinfo_x86 *c, bool keep_basic) > --- a/xen/arch/x86/include/asm/time.h > +++ b/xen/arch/x86/include/asm/time.h > @@ -23,6 +23,7 @@ mktime (unsigned int year, unsigned int > int time_suspend(void); > int time_resume(void); > > +void preset_tsc_scale(unsigned long freq); > void init_percpu_time(void); > void time_latch_stamps(void); > > --- a/xen/arch/x86/cpu/intel.c > +++ b/xen/arch/x86/cpu/intel.c > @@ -476,8 +476,8 @@ static int num_cpu_cores(struct cpuinfo_ > return 1; > } > > -static void intel_process_freq(const struct cpuinfo_x86 *c, > - unsigned int *min_mhz, unsigned int *max_mhz) > +void intel_process_freq(const struct cpuinfo_x86 *c, > + unsigned int *min_mhz, unsigned int *max_mhz) > { > uint64_t msrval; > uint8_t max_ratio, min_ratio; > --- a/xen/arch/x86/include/asm/processor.h > +++ b/xen/arch/x86/include/asm/processor.h > @@ -417,6 +417,9 @@ static inline uint8_t get_cpu_family(uin > return fam; > } > > +void intel_process_freq(const struct cpuinfo_x86 *c, > + unsigned int *min_mhz, unsigned int *max_mhz); > + > #ifdef CONFIG_INTEL > extern int8_t opt_tsx; > extern bool rtm_disabled; > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -1664,6 +1664,9 @@ s_time_t get_s_time_fixed(uint64_t at_ts > const struct cpu_time *t = &this_cpu(cpu_time); > uint64_t tsc, delta; > > + /* scale_delta() degenerates when the scale wasn't set yet. */ > + ASSERT(t->tsc_scale.mul_frac); > + > if ( at_tsc ) > tsc = at_tsc; > else > @@ -1679,6 +1682,20 @@ s_time_t get_s_time_fixed(uint64_t at_ts > > s_time_t get_s_time(void) > { > + /* > + * Before the TSC scale is set, avoid returning constant 0 (or whatever > + * this_cpu(cpu_time).stamp.local_stime is set to). While the returned > + * value is in no way representing time, it at least increases > + * monotonically, thus avoiding e.g. waiting loops to degenerate to > + * entirely infinite ones. > + */ > + if ( unlikely(!this_cpu(cpu_time).tsc_scale.mul_frac) ) > + { > + static s_time_t counter; Not that it matters much, but counter can probably be __initdata? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:04:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:04:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405269.1638783 (Exim 4.92) (envelope-from ) id 1x1fx3-0004AQ-3r; Wed, 02 Sep 2026 08:04:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405269.1638783; Wed, 02 Sep 2026 08:04:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fx3-0004AJ-1G; Wed, 02 Sep 2026 08:04:09 +0000 Received: by outflank-mailman (input) for mailman id 1405269; Wed, 02 Sep 2026 08:04:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fx2-0004AD-CZ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:04:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1fx2-001oDa-03; Wed, 02 Sep 2026 08:04:07 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1fx1-000tGQ-18; Wed, 02 Sep 2026 08:04:07 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=xu9ngN8tiZtNisfkSFxQdvsw6kXB5uvDdipD3ImKbdA=; b=jaol1oNVlWY/Qu6UoWcJj2qPl3 1kMfZHJ3Ew7HDL+2kPLT3skdGXQYm7/1b9Z7ZiFJkFnOmt1kVYiOn5O1n7WM6ySvHsF0SVdQ8EgBM a6lBpbn/rwbqeA5ReOq9OLuJ9sYV/vsefd9iH//edA9doFGHaFix3bdei54xdeeXFTNs=; Date: Wed, 2 Sep 2026 10:04:01 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v2 1/4] x86/time: CMOS RTC may run in binary mode Message-ID: References: <79d50725-3892-4643-b854-bfec9c0c0d79@suse.com> <5945d8f4-aece-4572-8e89-60408dd7ac32@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Jul 02, 2026 at 11:29:11AM +0200, Jan Beulich wrote: > Indicating it would always use BCD mode is just wrong (and then the > comment there said the opposite). All halfway recent (and really all 64- > bit capable) systems having a CMOS RTC should properly indicate the mode > in control register B. > > Make use of the flag, but provide a fallback mechanism in case people run > into systems not matching the above assumption. Additionally, when binary > mode is indicated and when "cmos-rtc-probe" is in use (but "cmos-rtc-bcd" > isn't), probe whether the clock really runs in binary mode. (This probing, > sadly, can take up to 10 seconds.) > > Signed-off-by: Jan Beulich > --- > v2: New. > > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -339,6 +339,14 @@ parameter to "stable:socket". > Specify the event count threshold for raising Corrected Machine Check > Interrupts. Specifying zero disables CMCI handling. > > +### cmos-rtc-bcd (x86) > +> `= ` > + > +> Default: `false` > + > +Flag to indicate the CMOS Real Time Clock uses BCD mode irrespective of > +control register B indicating binary mode. > + Likely too late for it now, but I get the feeling we should have introduced a cmos option, with rtc-bcd and rtc-probe as boolean sub options: cmos = [ rtc-probe, rtc-bcd ] > ### cmos-rtc-probe (x86) > > `= ` > > --- a/xen/arch/x86/include/asm/mc146818rtc.h > +++ b/xen/arch/x86/include/asm/mc146818rtc.h > @@ -96,7 +96,6 @@ bool is_cmos_port(unsigned int port, uns > > #ifndef RTC_PORT > #define RTC_PORT(x) (0x70 + (x)) > -#define RTC_ALWAYS_BCD 1 /* RTC operates in binary mode */ > #endif > > /* > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -1250,6 +1250,9 @@ mktime (unsigned int year, unsigned int > )*60 + sec; /* finally seconds */ > } > > +static bool __ro_after_init opt_cmos_rtc_bcd; > +boolean_param("cmos-rtc-bcd", opt_cmos_rtc_bcd); > + > struct rtc_time { > unsigned int year, mon, day, hour, min, sec; > }; > @@ -1285,7 +1288,7 @@ static bool __get_cmos_time(struct rtc_t > if ( acpi_gbl_FADT.century && acpi_gbl_FADT.century < 0x80 ) > century = CMOS_READ(acpi_gbl_FADT.century); > > - bcd = RTC_ALWAYS_BCD || !(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY); > + bcd = opt_cmos_rtc_bcd || !(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY); > > spin_unlock_irqrestore(&rtc_lock, flags); > > @@ -1353,6 +1356,48 @@ static bool __init cmos_rtc_probe(void) > return false; > } > > +static inline bool __init attr_const is_bcd(unsigned int x) > +{ > + return (x & 0xf) < 10 && (x >> 4) < 10; > +} > + > +static void __init cmos_rtc_probe_bcd(void) > +{ > + bool bcd; > + unsigned long flags; > + > + if ( opt_cmos_rtc_bcd ) > + return; > + > + spin_lock_irqsave(&rtc_lock, flags); > + bcd = !(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY); > + spin_unlock_irqrestore(&rtc_lock, flags); > + > + if ( bcd ) > + return; > + > + for ( unsigned int seclo = 0; ; ) > + { > + struct rtc_time rtc; > + > + if ( !__get_cmos_time(&rtc) || > + !is_bcd(rtc.sec) || > + !is_bcd(rtc.min) || > + !is_bcd(rtc.hour) || > + !is_bcd(rtc.day) || > + !is_bcd(rtc.mon) ) > + return; > + > + if ( seclo > (rtc.sec & 0xf) ) > + break; > + > + seclo = rtc.sec & 0xf; Is there a risk of this loop triggering the watchdog, and hence we should process softirqs in the loop? (or otherwise have some kind of hard loop stop after certain iterations / time) Oh, I now see the mention in the commit message and also note this is done ahead of SMP and also ahead of the watchdog being enabled, hence it can't trigger the watchdog. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:05:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:05:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405277.1638794 (Exim 4.92) (envelope-from ) id 1x1fy4-0004fZ-DY; Wed, 02 Sep 2026 08:05:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405277.1638794; Wed, 02 Sep 2026 08:05:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fy4-0004fR-9k; Wed, 02 Sep 2026 08:05:12 +0000 Received: by outflank-mailman (input) for mailman id 1405277; Wed, 02 Sep 2026 08:05:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1fy2-0004fJ-T8 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:05:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1fy2-008j2y-6P for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 10:05:10 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97d8b0-8faa-0a2a0a5109dd-0a2a4507dc6e-34 for ; Wed, 02 Sep 2026 10:05:10 +0200 Received: from [209.85.208.53] (helo=mail-ed1-f53.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97d8b5-b4ea-0a2a45070019-d155d035bdad-3 for ; Wed, 02 Sep 2026 10:05:10 +0200 Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-6a38098734bso1430499a12.1 for ; Wed, 02 Sep 2026 01:05:10 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-484492cf550sm4502303f8f.37.2026.09.02.01.05.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 01:05:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788336309; x=1788941109; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=8R0epzX8cULzfAhI8BmCx2YiWbLoKCsOKiSssYsgme0=; b=BjvyBHnWmrBDGPxaZlSyPqTXpUW2vv5WexcTKOyDeIcITDRNj0pRfpMIBmoUfMauVi OUsukFEZ+lYgkjDq7gr1jCsjLtTjvu0sw+/9hXkvnQ0UBYOY+Vmak3KDWyl0o/NsjJ/o EJpa2bJlXQvf6P2dk42f7I1wuK95ptxSX6Lk3VqRO2bOwq78zxqMwgoYA1RPJ8N8eELF WgCwGnugnrd+H+ocgxKu3o/aikVil4F8ufkxpRBnbqVI/VmwrO77xXdQg2FdFcZbR6YO Vd+u2h79tKQN9u2qCjxn55E5unCsPU8o3Z0EK+bztG/vhPo93CW8V7s2dQlCu2L8WQMO IiIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788336309; x=1788941109; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=8R0epzX8cULzfAhI8BmCx2YiWbLoKCsOKiSssYsgme0=; b=kH2oHciwbFb2HNnvVMtT+A2FZTTxizyhrw8b/D99+JRU5HD1e9V5nZ6d0PWWPFV97J pCqBjnZFfMCqcFpLVn0UHa6w4TdDrIY2Kb3vchkgoJ1mr9WOqVVqnNJxmNwx7BZJnOTe AJCp7XEIzQFiGgxBYvMwF9noK67wEp9MDhiUx6t5pGOkh6SICl9l9LaXqaH8ZKlFiGzP kxwpuGxCkJySUoReocfH61wmC/6K1lp6DWLOGKhxcWsCY57TSOkrCglRDDxjf6+/EaKT czKAlZ6HRUWU82dxU1MWe9U/77qsLAvUgHIAmetyz6V+/L00AhIRCgNJQvb7jlgr+qUN ynsg== X-Forwarded-Encrypted: i=1; AKwUvBwDResh74oEOJK4uWl3cm2D+77oWyzjkPQGUZkAxc3z+eSb8ealfLjcLPtLzbN00LRjbPA8sk9CjM4=@lists.xenproject.org X-Gm-Message-State: AFuF++lWjiai+o21ui1T3wjKiGqu23E4lBXnW650PFruL58lbKuRUceU p+qHHiRAsPquDfvHdcffoxXtJK9nT7NJNh/ApwMXpXXzgXV0UHgh62qe X-Gm-Gg: AYBFou3yn5LNl8nK5xwlykz+lZd/bzW6CKQsD0rkxOXrKefsb0X6N8Bnq0usJQckTm6 H06OvbhRQiIZTorHWdkJjMRGpzH6+2Q1KkCzQH//d1mefSOTWW89FBvQd1W9n01T7Tnr8rLavQC m8MJy7VzeW9ZSX8qb/I6UA+eGAAjVrvW2ozD4xzdvM8Zp1aU7JBmrbydO5IcfD/Rb3dmz7kvflU mWnXljRmi42lnFx12HFHEE/hdDGfvU/fnsWgEpVKIlxADzBOgN8QcTbRwzGhw1TdZoCGzcboFja Ltcz4gqJubuv5GLCyJuk3+tsY4sN3cMUQFcra6ye69HITNTON5Qs8ihSAuOGb8w8pcbdDV8xmTs HjpAh2K2jX/4GaFclkMAnBRHnueCgtfV+p37iF8ffTo3QO/nS0xzOpqKqOfVMz+8ydzpZf75HRA yCOI7zacOtGGh0AlLBs0OPQqx6+XaaV5zM717eGfdCBix+Qt2+iMXgE8jYPYc4dqWwJIsHU1brV 8pXGXTMfCa1MEMPI2r/gmTtTZKiGnvb0N7kdwqstw== X-Received: by 2002:a05:6402:350c:b0:6a3:8652:a373 with SMTP id 4fb4d7f45d1cf-6a68234c4c8mr1943895a12.3.1788336309465; Wed, 02 Sep 2026 01:05:09 -0700 (PDT) Message-ID: <598246be-5a0c-4969-b9a1-266739910f84@gmail.com> Date: Wed, 2 Sep 2026 10:05:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260901155023.116381-1-oleksii.kurochko@gmail.com> <45fc41c1-7127-4e70-ba81-2a85d1bc7655@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <45fc41c1-7127-4e70-ba81-2a85d1bc7655@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788336310-356C2AE4-4AD51ABF/10/73395122804 X-purgate-type: spam X-purgate-size: 1662 On 9/1/26 5:59 PM, Jan Beulich wrote: > On 01.09.2026 17:50, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -326,6 +326,8 @@ int __init imsic_init(const struct dt_device_node *node) >> unsigned int nr_parent_irqs, index, nr_handlers = 0; >> paddr_t base_addr; >> unsigned int nr_mmios; >> + /* imsic_cfg.msi[] is indexed by Xen CPU id, so size it accordingly. */ >> + unsigned int nr_msi = num_possible_cpus(); > > The possible-CPUs-map may be sparse, so num_possible_cpus() may still yield > too small a value to use here. The thing to use likely is nr_cpu_ids. I notice > that variable is entirely unused so far by arch/riscv/*, though. > IIUC "sparse" means we could have three CPUs with IDs 0, 1 and 12, so bits 0, 1 and 12 would be set in cpu_possible_map. In that case num_possible_cpus() returns 3, which is the correct *number* of CPUs but msi[] is indexed by the Xen CPU ID, not by the CPU's ordinal position in the mask, so indexing it with ID 12 would need 13 entries. The two only coincide when the mask is dense, so you are right that num_possible_cpus() is the wrong bound in principle. That said, cpu_possible_map shouldn't be sparse by construction: the boot CPU is assigned ID 0 in smp_prepare_boot_cpu(), and the remaining IDs are handed out sequentially, so the bits are always 0..N-1 (for RISC-V it is done in such way in downstream). Arm, the other user of cpu_possible_map, fills it with Xen CPU IDs the same way. I agree it is better not to depend on that, so I will use nr_cpu_ids for nr_msi instead. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:05:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:05:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405278.1638802 (Exim 4.92) (envelope-from ) id 1x1fy6-0004t3-MR; Wed, 02 Sep 2026 08:05:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405278.1638802; Wed, 02 Sep 2026 08:05:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fy6-0004sw-Jf; Wed, 02 Sep 2026 08:05:14 +0000 Received: by outflank-mailman (input) for mailman id 1405278; Wed, 02 Sep 2026 08:05:13 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fy5-0004sQ-G8 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:05:13 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1fy4-001oEa-1a; Wed, 02 Sep 2026 08:05:12 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1fy3-000zVN-2w; Wed, 02 Sep 2026 08:05:12 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=8AxFR/Dq80dQVj014nchVr+oA3GHFCApYN4dOpMUvak=; b=IoUAgxK6IyW/9J9hHFU+vrx8B+ kFxEXm8gs/SoZx5CX9VjQeynChgmuYcHNstIoYdLzPN0ahlC82e4SpntF5DF91kDf6AKt8OCwmnLM iSRoWfxJzwyUy1vlqKz7jYsT2oGEXlEonERd6qpC1rb1USHkSADVaFF1hMO/o97SH+6E=; Date: Wed, 2 Sep 2026 10:05:03 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH v2 2/4] time: shorten year determination loop Message-ID: References: <79d50725-3892-4643-b854-bfec9c0c0d79@suse.com> <7bed7164-9a53-4e53-9fc1-7af68108bdf8@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Jul 02, 2026 at 11:30:11AM +0200, Jan Beulich wrote: > For dates very far into the future (the MC146818 RTC's century byte can go > up to the 99th century), the present year-wise loop would become somewhat > inefficient (taking perhaps several thousand iterations). Prefix that loop > with a 400-year granular calculation (somewhat like the earlier loop does > for dates in the past). > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:06:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:06:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405291.1638810 (Exim 4.92) (envelope-from ) id 1x1fyu-0005eo-US; Wed, 02 Sep 2026 08:06:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405291.1638810; Wed, 02 Sep 2026 08:06:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fyu-0005eh-Ro; Wed, 02 Sep 2026 08:06:04 +0000 Received: by outflank-mailman (input) for mailman id 1405291; Wed, 02 Sep 2026 08:06:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1fyt-0005eD-DF for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:06:03 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1fyt-001oFT-0f; Wed, 02 Sep 2026 08:06:02 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1fys-0016Gb-29; Wed, 02 Sep 2026 08:06:02 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=5Iv8qcbaMigfgrYoHiQAAMpbrvJwOscs+sTql6iwyoc=; b=Z3xdl1IoQ4ycffshEc66PkPeiO jN59XSUglqwC9gEz9wIg/EKrxwEimsNiaGQJEKKEVQPmLn8AGHznmrRbE8te6wfDusiCnudK03FKc vLMFFRxiW0+a4ndiULB569Y/EUlryoXxBHAmYfheScmcXL0f2NCPkkkT9L1rebnkA7Kw=; Date: Wed, 2 Sep 2026 10:05:57 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v2 3/4] x86/vRTC: the use_timer field is a boolean one Message-ID: References: <79d50725-3892-4643-b854-bfec9c0c0d79@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Jul 02, 2026 at 11:30:44AM +0200, Jan Beulich wrote: > ... and hence wants to be of bool type. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:07:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:07:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405301.1638820 (Exim 4.92) (envelope-from ) id 1x1g0W-0006Le-9l; Wed, 02 Sep 2026 08:07:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405301.1638820; Wed, 02 Sep 2026 08:07:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1g0W-0006LX-6G; Wed, 02 Sep 2026 08:07:44 +0000 Received: by outflank-mailman (input) for mailman id 1405301; Wed, 02 Sep 2026 08:07:43 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1g0V-0006LR-EX for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:07:43 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1g0V-001oGI-0t; Wed, 02 Sep 2026 08:07:43 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1g0U-001JdN-2J; Wed, 02 Sep 2026 08:07:42 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date; bh=oo7Y65nO5P8K4cvGvX1U2KVSr8ZinK3m5j+dGy0yC7w=; b=3YFGFGWCEwExDYYAHP9VzoFHl/ 96y4J6FcfSU96cTAmbYutVIcF3ZsZcuvX7ZmuoqH7I6gUCFJ2WLDkRrThjqIPUT9+cAmIMuuUWyAl 2bWAXzXZR2UQVoU/6/+arRPWfITPx0+DeU7/Pvc+auAVhiQoV6c0IdJMEI9gfLQh5RaA=; Date: Wed, 2 Sep 2026 10:07:37 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v2 4/4] x86/vRTC: support century field Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Jul 02, 2026 at 11:31:14AM +0200, Jan Beulich wrote: > Both ROMBIOS and SeaBIOS (with CONFIG_QEMU=y, as we build it) blindly > assume availability of this field (at its conventional index 0x32); OVMF > at least has code to inspect FADT. Hence we ought to have supported it > virtually forever. > > As the index is beyond RTC_CMOS_SIZE, leverage the padding field in > struct hvm_hw_rtc to hold its value. Update the field only when involved > values are valid BCD century specifiers. Otherwise (for VMs migrated in > from an older hypervisor) leave handling to the DM. > > This makes the Linux rtc-cmos driver report y3k compatibility. > > In the new rtc_check(), besides checking the new fields also check the > pre-existing pad0 field. > > While extending xen-hvmctx.c:dump_rtc() also add RTC offset there. > > Fixes: 4ca161214355 ("[HVM] Move RTC emulation into the hypervisor") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > Am I overly paranoid with the checking of the field, considering that > Xen 3.x post-dates year 2000 and hence all firmware nowadays usable guests > have ever run with should have been aware of the field? Or am I, quite the > opposite, still not strict enough? I think the checking is likely fine. > Now that we extend struct hvm_hw_rtc, should we perhaps save not only the > century, but also its index? Hm, possibly for correctness, albeit I think this is unlikely to cause issues. Likely better done in a separate patch? > > Likely more sanity checking could be added to rtc_check(), but that's for > a separate patch imo. > > Isn't day-of-week handling flawed? If the field is brought out of sync > with the other values, shouldn't it stay respectively out-of-sync? I don't know that much about the RTC TBH. > And > isn't it excessive overhead to go through rtc_set_time() when the field > is updated while SET is clear? I think this is done because we don't call rtc_set_time() when RTC_SET is activated in RTC_REG_B? We would need to change the logic a bit. Is there a reason to propagate the changes to the DM even when SET is not active? > Perhaps we ought to also support alarm day/month features? > --- > v2: Don't re-purpose pad0 field of struct hvm_hw_rtc. > > --- a/tools/libacpi/static_tables.c > +++ b/tools/libacpi/static_tables.c > @@ -33,6 +33,8 @@ struct acpi_20_facs Facs = { > #define ACPI_PM_TMR_BLK_BIT_WIDTH 0x20 > #define ACPI_PM_TMR_BLK_BIT_OFFSET 0x00 > > +#define CMOS_CENTURY 0x32 /* Conventional index used also without ACPI */ > + > struct acpi_fadt Fadt = { > .header = { > .signature = ACPI_FADT_SIGNATURE, > @@ -88,7 +90,9 @@ struct acpi_fadt Fadt = { > .register_bit_width = ACPI_PM_TMR_BLK_BIT_WIDTH, > .register_bit_offset = ACPI_PM_TMR_BLK_BIT_OFFSET, > .address = ACPI_PM_TMR_BLK_ADDRESS_V1, > - } > + }, > + > + .century = CMOS_CENTURY, > }; > > struct acpi_20_rsdt Rsdt = { > --- a/tools/misc/xen-hvmctx.c > +++ b/tools/misc/xen-hvmctx.c > @@ -311,7 +311,7 @@ static void dump_rtc(void) > printf(" 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x, index 0x%02x\n", > r.cmos_data[8], r.cmos_data[9], r.cmos_data[10], r.cmos_data[11], > r.cmos_data[12], r.cmos_data[13], r.cmos_index); > - > + printf(" century 0x%02x offset %"PRId64"\n", r.century, r.rtc_offset); > } > > static void dump_hpet(void) > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -482,16 +482,27 @@ static int rtc_ioport_write(void *opaque > data &= 0x7f; > s->hw.cmos_index = data; > spin_unlock(&s->lock); > - return (data < RTC_CMOS_SIZE); > + return data < RTC_CMOS_SIZE || (s->has_century && data == RTC_CENTURY); > } > > - if ( s->hw.cmos_index >= RTC_CMOS_SIZE ) > + switch ( s->hw.cmos_index ) > { > + case 0 ... RTC_CMOS_SIZE - 1: > + orig = s->hw.cmos_data[s->hw.cmos_index]; > + break; > + > + case RTC_CENTURY: > + if ( s->has_century ) > + { > + orig = s->hw.century; > + break; > + } > + fallthrough; > + default: > spin_unlock(&s->lock); > return 0; > } > > - orig = s->hw.cmos_data[s->hw.cmos_index]; > switch ( s->hw.cmos_index ) > { > case RTC_SECONDS_ALARM: > @@ -507,6 +518,7 @@ static int rtc_ioport_write(void *opaque > case RTC_DAY_OF_MONTH: > case RTC_MONTH: > case RTC_YEAR: > + case RTC_CENTURY: > /* if in set mode, just write the register */ > if ( (s->hw.cmos_data[RTC_REG_B] & RTC_SET) ) > s->hw.cmos_data[s->hw.cmos_index] = data; > @@ -515,7 +527,10 @@ static int rtc_ioport_write(void *opaque > /* Fetch the current time and update just this field. */ > s->current_tm = gmtime(get_localtime(d)); > rtc_copy_date(s); > - s->hw.cmos_data[s->hw.cmos_index] = data; > + if ( s->hw.cmos_index != RTC_CENTURY ) > + s->hw.cmos_data[s->hw.cmos_index] = data; > + else > + s->hw.century = data; > rtc_set_time(s); > } > alarm_timer_update(s); > @@ -591,7 +606,16 @@ static void rtc_set_time(RTCState *s) > tm->tm_wday = from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_WEEK]); > tm->tm_mday = from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_MONTH]); > tm->tm_mon = from_bcd(s, s->hw.cmos_data[RTC_MONTH]) - 1; > - tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]) + 100; > + tm->tm_year = from_bcd(s, s->hw.cmos_data[RTC_YEAR]); > + if ( s->has_century ) > + { > + unsigned int century = s->hw.century; > + > + BCD_TO_BIN(century); > + tm->tm_year += century * 100 - epoch_year; > + } > + else > + tm->tm_year += 100; > > after = mktime(get_year(tm->tm_year), tm->tm_mon + 1, tm->tm_mday, > tm->tm_hour, tm->tm_min, tm->tm_sec); > @@ -629,6 +653,12 @@ static void rtc_copy_date(RTCState *s) > s->hw.cmos_data[RTC_DAY_OF_MONTH] = to_bcd(s, tm->tm_mday); > s->hw.cmos_data[RTC_MONTH] = to_bcd(s, tm->tm_mon + 1); > s->hw.cmos_data[RTC_YEAR] = to_bcd(s, tm->tm_year % 100); > + > + if ( s->has_century ) > + { > + s->hw.century = get_year(tm->tm_year) / 100; > + BIN_TO_BCD(s->hw.century); > + } > } > > static int update_in_progress(RTCState *s) > @@ -663,13 +693,17 @@ static uint32_t rtc_ioport_read(RTCState > case RTC_DAY_OF_MONTH: > case RTC_MONTH: > case RTC_YEAR: > + case RTC_CENTURY: > /* if not in set mode, adjust cmos before reading*/ > if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET)) > { > s->current_tm = gmtime(get_localtime(d)); > rtc_copy_date(s); > } > - ret = s->hw.cmos_data[s->hw.cmos_index]; > + if ( s->hw.cmos_index != RTC_CENTURY ) > + ret = s->hw.cmos_data[s->hw.cmos_index]; > + else > + ret = s->hw.century; > break; > case RTC_REG_A: > ret = s->hw.cmos_data[s->hw.cmos_index]; > @@ -718,7 +752,8 @@ static int cf_check handle_rtc_io( > *val = 0xff; > return X86EMUL_OKAY; > } > - else if ( vrtc->hw.cmos_index < RTC_CMOS_SIZE ) > + else if ( vrtc->hw.cmos_index < RTC_CMOS_SIZE || > + (vrtc->has_century && vrtc->hw.cmos_index == RTC_CENTURY) ) > { > *val = rtc_ioport_read(vrtc); > return X86EMUL_OKAY; > @@ -760,6 +795,32 @@ static int cf_check rtc_save(struct vcpu > return rc; > } > > +static int cf_check rtc_check(const struct domain *d, hvm_domain_context_t *h) > +{ > + const struct hvm_save_descriptor *desc = > + (const struct hvm_save_descriptor *)&h->data[h->cur]; > + struct hvm_hw_rtc s; > + > + if ( !has_vrtc(d) ) > + return -ENODEV; > + > + if ( hvm_load_entry_zeroextend(RTC, h, &s) != 0 ) > + return -ENODATA; > + > + if ( s.pad0 ) > + return -EINVAL; > + > + for ( unsigned int i = 0; i < ARRAY_SIZE(s.pad1); ++i ) > + if ( s.pad1[i] ) > + return -EINVAL; > + > + if ( desc->length >= endof_field(struct hvm_hw_rtc, century) && > + ((s.century & 0xf) >= 10 || (s.century >> 4) >= 10) ) > + return -EINVAL; It would be nice to also set ->has_century here, but the s struct is a temporary stack allocation. > + > + return 0; > +} > + > /* Reload the hardware state from a saved domain */ > static int cf_check rtc_load(struct domain *d, hvm_domain_context_t *h) > { > @@ -793,12 +854,18 @@ static int cf_check rtc_load(struct doma > check_update_timer(s); > alarm_timer_update(s); > > + if ( !s->hw.century ) > + { > + s->has_century = false; > + s->hw.century = 0; Isn't this last line pointless? The if condition is !s->hw.century, and hence s->hw.century must be 0 here? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:32:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:32:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405325.1638828 (Exim 4.92) (envelope-from ) id 1x1gO0-0002oF-2t; Wed, 02 Sep 2026 08:32:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405325.1638828; Wed, 02 Sep 2026 08:32:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gO0-0002o8-0I; Wed, 02 Sep 2026 08:32:00 +0000 Received: by outflank-mailman (input) for mailman id 1405325; Wed, 02 Sep 2026 08:31:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gNz-0002o2-Ee for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:31:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1gNy-00Afxf-NS for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 10:31:58 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97dee3-bab6-0a2a0a5309dd-0a2a4506aaac-34 for ; Wed, 02 Sep 2026 10:31:58 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97defe-195a-0a2a45060019-d1558031bdc8-3 for ; Wed, 02 Sep 2026 10:31:58 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49556f97a9dso5534225e9.1 for ; Wed, 02 Sep 2026 01:31:58 -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-49cdce0b425sm130615495e9.1.2026.09.02.01.31.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 01:31:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788337918; x=1788942718; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=IINVuEzp4YLCCtb10Q6NLVvUfyFwcP6QDZL5igfiRmM=; b=YFUjqlJHgjCF+82GaBBASfQNn0MZt789U+XFU7XUVhspwD3VYBRpXOQJOEYjjqOzCm D/Rxy+oorTm0EpN0QtkixugiO0eK19KBejc4JpwLWvBIAKOx4zGtD1Id+kcXgLdwm5il mUkg9C1Z/ufOLVWq5JRyKIxNEPSvlVGTBKTWe6VWPR5CfOhYAXFCFeG33qKRIJ8S3ZFK EpsEoa21HVGKZfi3Y0MsSqEQsMcH/96vh82qo6U+dDZoU8mCuBzu26GZuSHLsewBXjyZ zWeIpocPm2Tdq7tWSIVE5ssVMxJmLkPGSN/WkXrYdVS8MwQOoKCILyt7CS1/tnjCrlT9 MsCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788337918; x=1788942718; h=content-transfer-encoding:content-type: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:content-type; bh=IINVuEzp4YLCCtb10Q6NLVvUfyFwcP6QDZL5igfiRmM=; b=ILbl7QA8JiB/4scYFKWzt2hG40QwtHvkZSLfYMoONHZ+XAuQCacbd7Jk+7Jwld8v+J KHO5i/Y45sFbrVdVdbqWHepgLmckQrUePYQgjCSJutZdrou4mH4/iRXT9hN4gdMrRpiI g+1/wCnkLgCAA4RmjfarJOxeLlDyft36NBXBvaQuz/rFGqezNJ4IgSyE0lfAw722fT9/ qSQERfr3XmAgnB5Fzo13Yj2n1JHnLabivbJjEDfWGUjwAqLzcqMt49vcYkbM2ZbQ1t7P v42SWmn4WxC8F+AgsW7/tDLDKEhNXHdtoNoElm/xXp+pI0POGaNOwvomFMwwT5GWIOQ2 Ypzg== X-Gm-Message-State: AFuF++mkF8YTVppww3JVdottko011fyJw4yXg0QBX5piBVYnnA1C5Ci6 l4tKQjg9th3swd4CUMSqOqOYeTm6kOhm6RtzWKjmvMp3LA86y3Z4LTCqvyJ7vR3vZQ== X-Gm-Gg: AR+sD13w9QJJsOqe2bQWI5Z1SVS5wq6t6tVCeoCi4/GqWxYFY7vk9KHty9zLJWt6AxW WLxLdpBDLpPvJL0KC7+uvkLTEgWUeCPYmxdHJ/q3Qm0OvALarzGG1MMy9xlrl4C7GkULH3jIf45 Yp4ibdE2rmjYqTuRbHlsvGFg3HA1hwtwezwNFBMiVdX9QcKgEYSSxJHRkWrHp7g4yxJnxKK0XZc 3HVOBovm70hNmTB6F9EdhtATAwHpYAsLVcZdZaib7eLKjVz2kT1Vh0RJ0Y6hzTZdw32qUglc0VS y//WxaiOgczBujToIvs32O+L8KwutGdsZmEf1zhjNYOC/ofS1yro9upckrPrfQAs/wWCFnX3pi1 WXIAFgv4VDUFqWgu4EXsiOOETJf2pImLXYy6RtBC77sJ0rF+WI6Y5kzOZ7lCq9oxjwEYLUhxNYa c4WZ0x8WLy/EhKrPK2aYR4sfDjklclf6UAAoSHVsFR5gyWX/sI/yPMZKZUHdS8YnR+Oo4CvSEsh U+8c2ZhkPOwhkiAjTvm7Yyipw5hlHw8POqb+UQ5T+PAQJbcefbB X-Received: by 2002:a05:600c:8705:b0:49c:cedf:f870 with SMTP id 5b1f17b1804b1-49ce58366f0mr53581555e9.16.1788337917466; Wed, 02 Sep 2026 01:31:57 -0700 (PDT) Message-ID: <89352ea0-7284-4f6f-bba4-5a6a334b1551@suse.com> Date: Wed, 2 Sep 2026 10:31:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/alternatives: mark .altinstructions r/w To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: 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: 8bit X-purgate-ID: tlsNG-16d1c6/1788337918-F72C677B-5C8972AA/0/0 X-purgate-type: clean X-purgate-size: 912 On 02.09.2026 09:27, Roger Pau Monné wrote: > On Wed, Sep 02, 2026 at 09:15:46AM +0200, Jan Beulich wrote: >> Forever since the introduction of the .priv member it has been wrong to >> record the section as r/o. >> >> .alt_call_sites, otoh, is legitimately r/o, hence >> __alt_call_sites_{start,end}[] would better reflect that. > > Right, we don't however have a .init.rodata section, and hence it gets > placed in the .init.data section which is r/w. No objection about the > addition of const, it's the right thing. > >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. > I think you want: > > Fixes: 4008c71d7af2 ("x86/alt: Support for automatic padding calculations") I was pondering to add this, but then decided against (it's an inconsistency, not really a bug). Since you ask for it, let me add it then. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:34:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:34:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405332.1638838 (Exim 4.92) (envelope-from ) id 1x1gPu-0003Li-Fr; Wed, 02 Sep 2026 08:33:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405332.1638838; Wed, 02 Sep 2026 08:33:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gPu-0003Lb-BT; Wed, 02 Sep 2026 08:33:58 +0000 Received: by outflank-mailman (input) for mailman id 1405332; Wed, 02 Sep 2026 08:33:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gPs-0003LT-UX for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:33:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1gPs-00Fp5T-BC for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 10:33:56 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97df6b-2eae-0a2a0a5409dd-0a2a4503cab2-36 for ; Wed, 02 Sep 2026 10:33:56 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97df74-fae8-0a2a45030019-d1558029b587-3 for ; Wed, 02 Sep 2026 10:33:56 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49557167508so7437265e9.1 for ; Wed, 02 Sep 2026 01:33:56 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce4642382sm54766395e9.3.2026.09.02.01.33.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 01:33:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788338036; x=1788942836; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=aCy9uizeEUcLaZCIpHKeiBs6su7LhtDrq+7wAuCLOHA=; b=I6gSJbTGUH+h4BPsDXclGah+6xtHt4/Q7a/4xnun5yFwfezgJHnNpNOwdTj4EXGfYW XtR9MhWoBJMDUNBkwvvzX5Ps3Hx/9Ft2X3pmp3X3mvfEoQ6YrymLi9FZlOXlGKhsaavO G+Byx+QxgBwdjb9u6eN6Jpu5kEp0qVtzLadRjj9qRvMf2Nj/7u0x+hR5gItl3h86nIck HpP0hcI1vbvYpl+/ZiR05mw4ixGco5gd26OYeg23X4wSpodkn85st55BT9sf3Ak7tW58 RW5a9gKxdnIVaRdKv+oquEYBmEUimrIeytQQZxGr7xXjv8nj76N7o+LhhKvE/mAM6NBl 0/6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788338036; x=1788942836; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=aCy9uizeEUcLaZCIpHKeiBs6su7LhtDrq+7wAuCLOHA=; b=l289kXLrPiaYg9+DgfPJPSNfsmEENf0VEWw18MkfzJbmRDjkawOo+AFYgLud8Hujwl INiOLT3dlNhduBwiUfTQZI7vxqOOuInHX/zwUgMnok8AuZ2acC0vuKQSZxFL+739RL94 VKwIg4T4FS560oOB+KbiHbsI5pirWzJWXq00TBCS6kCFP4HWGrk8oHY/8kdvaBDPw+sv EISzOsbo+UhN2cEKRi/oAFbezEhLCZ+7U9x/V03D2jbBE5IpYH0VFKP9+pXDUQFwYqb+ fkS6lkKWHoUKc+/OG/quclEjKsAXBNJ+AdMzPiG/Dp4qziCktgO272/AyAQr8dIoSMC4 WF1Q== X-Forwarded-Encrypted: i=1; AHgh+Rq3PSgLqS4v+sWYtO1HP3DA/Os9tOzG1LJfjkpCOZLJbisp/3sWImqJRn7c2Wxr+Md8xfsF8jQMfW0=@lists.xenproject.org X-Gm-Message-State: AFuF++nAc05BFIEgKcnC/T0ZJw9uj/2Dwjjf11ktwZrGKjfRZ6uXzgAA SG6xnpOT/1bcFFEw9AwlBjpVU8BTZFHguWX1vk4XkDlFG+3s83gx4wEa X-Gm-Gg: AR+sD11rtMGTRfgttPV4Rz981WBUhPB/GbQXRrtMQ46WBCcimXKxXemdultCDY1FBCY yPTxR3cZPHED/qXnPMFG2rvkN/i5YeZgsdLdCTsnyZg+V1sdOC5YmWVuVofHh3NG4gM1e5xj+WZ NK1OAOW4e7CfUtQglKr1GAsHH9++u6z9fsIt5Bga7ITzb76/WIynXsDPdk1pkgoDNcZzdh1QrL5 /McW455+flWyrnpkvDwB3dFbfyYAidO9zGOopUJJfqZ4ByTXDFEWjTG9UbMLADlXT7zNbnN2Lfv /KohpwuDjYwzi/gy24PI3aYKzu/qNJYKcf6/WbUFLg4BcJxm0sUpPjFoVgp/fdnQqLm7HbbqjcE tNaT6lmuH4EREw2v3ow9fzw1LA+YRA11FFV4CajyGmJ4+BKMI40EZQdbJHW8IDJU4fyDBFFRMwj mnh30+JcEbckTQ5mgpfeRKoLTZ6Sq5/6lSX856dbTvT2Qu/jIlM9rqyaxe4HmvMeuXov5X6gBws BChy8Ae2uNoiY0DOGTlj/dmLQ== X-Received: by 2002:a05:600c:1d14:b0:499:b65e:49c9 with SMTP id 5b1f17b1804b1-49ce583e94cmr44652095e9.10.1788338035485; Wed, 02 Sep 2026 01:33:55 -0700 (PDT) Date: Wed, 2 Sep 2026 09:33:54 +0100 From: David Laight To: Jan Beulich Cc: Mauricio Faria de Oliveira , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Brian Gerst Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() Message-ID: <20260902093354.582c2f07@pumpkin> In-Reply-To: <16110ecc-fc0d-4b9d-a958-2a75ca60b69f@suse.com> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <16110ecc-fc0d-4b9d-a958-2a75ca60b69f@suse.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788338036-6D0D94E9-83023E9B/0/0 X-purgate-type: clean X-purgate-size: 2206 On Tue, 1 Sep 2026 15:16:58 +0200 Jan Beulich wrote: > On 22.08.2026 20:33, Mauricio Faria de Oliveira wrote: > > According to the GCC documentation, conditions in the flags register > > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2]. > > > > Also, clobbers (e.g., "cc") may not overlap with an output operand [2]. > > > > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the > > "=@ccnz" output operand. > > > > """ > > 6.11.2.4 Flag Output Operands > > > > On some targets, a special form of output operand exists by which > > conditions in the flags register may be outputs of the asm. [...] > > > > 6.11.2.6 Clobbers and Scratch Registers > > > > While the compiler is aware of changes to entries listed in the > > output operands, [...] > > > > Clobber descriptions may not in any way overlap with an input or > > output operand. [...] > > """ > > > > Reported-by: "H. Peter Anvin" > > Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/ > > Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()") > > Signed-off-by: Mauricio Faria de Oliveira > > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands [1] > > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 [2] > > Reviewed-by: Jan Beulich > > > --- a/arch/x86/boot/string.c > > +++ b/arch/x86/boot/string.c > > @@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len) > > asm volatile("test %3, %3\n\t" > > "repe cmpsb" > > : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) > > - : : "cc", "memory"); > > + : : "memory"); > > In fact I'm using a modified gcc which properly rejects such conflicting > uses of output and clobber. ("cc" clobbers are redundant on x86 anyway.) And, if "cc" clobber wasn't redundant, you'd need clobbers for the cc flags that weren't being used as output values. David > > Jan > From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:35:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:35:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405344.1638846 (Exim 4.92) (envelope-from ) id 1x1gRX-0003xv-Td; Wed, 02 Sep 2026 08:35:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405344.1638846; Wed, 02 Sep 2026 08:35:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gRX-0003xo-Qq; Wed, 02 Sep 2026 08:35:39 +0000 Received: by outflank-mailman (input) for mailman id 1405344; Wed, 02 Sep 2026 08:35:38 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gRW-0003xf-4k for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:35:38 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1gRV-001onq-2k; Wed, 02 Sep 2026 08:35:37 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1gRV-003Q2B-0l; Wed, 02 Sep 2026 08:35:37 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=B2ZLczSkBh7ovVRgcn6NoJrswNl57crVurA5ZVl5Ob0=; b=PSLWhrqsG4Tv3dUAMJzofKb9M8 4Y0u8WojJtfXQxqpLq+lOqdbJvzmU/ySz/Vlz3YJD4iN0+Ou3ICaMFMgtbEuLO3GpCnUztVhoADME hMJy8cM7WQAobe7LL+HW6WbazPJ+VHfzTLCelNvG33aNpAe5jwt3by6NAII8ji2bXfMw=; Date: Wed, 2 Sep 2026 10:35:32 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH] x86/alternatives: mark .altinstructions r/w Message-ID: References: <89352ea0-7284-4f6f-bba4-5a6a334b1551@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <89352ea0-7284-4f6f-bba4-5a6a334b1551@suse.com> On Wed, Sep 02, 2026 at 10:31:56AM +0200, Jan Beulich wrote: > On 02.09.2026 09:27, Roger Pau Monné wrote: > > On Wed, Sep 02, 2026 at 09:15:46AM +0200, Jan Beulich wrote: > >> Forever since the introduction of the .priv member it has been wrong to > >> record the section as r/o. > >> > >> .alt_call_sites, otoh, is legitimately r/o, hence > >> __alt_call_sites_{start,end}[] would better reflect that. > > > > Right, we don't however have a .init.rodata section, and hence it gets > > placed in the .init.data section which is r/w. No objection about the > > addition of const, it's the right thing. > > > >> Signed-off-by: Jan Beulich > > > > Acked-by: Roger Pau Monné > > Thanks. > > > I think you want: > > > > Fixes: 4008c71d7af2 ("x86/alt: Support for automatic padding calculations") > > I was pondering to add this, but then decided against (it's an inconsistency, > not really a bug). Since you ask for it, let me add it then. I agree it's not a functional bug, but since the commit message mentions "it has been wrong", I was assuming we might want to signal when the inconsistency was introduced. No strong opinion really. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:40:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:40:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405354.1638856 (Exim 4.92) (envelope-from ) id 1x1gVt-0005fE-Ds; Wed, 02 Sep 2026 08:40:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405354.1638856; Wed, 02 Sep 2026 08:40:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gVt-0005f7-AF; Wed, 02 Sep 2026 08:40:09 +0000 Received: by outflank-mailman (input) for mailman id 1405354; Wed, 02 Sep 2026 08:40:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gVr-0005f0-Po for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:40:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1gVr-006PDl-6J for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 10:40:07 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97e0e6-e002-0a2a0a5209dd-0a2a4504df58-6 for ; Wed, 02 Sep 2026 10:40:07 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97e0e6-b57f-0a2a45040019-d155802bd1b1-3 for ; Wed, 02 Sep 2026 10:40:07 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4995b0343c1so7900885e9.3 for ; Wed, 02 Sep 2026 01:40:07 -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-49ce464aa32sm63331905e9.5.2026.09.02.01.40.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 01:40:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788338406; x=1788943206; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=lFeiGfwHFbNu+2NtxgAHyH+5BhpbpvplrOjaEEUWGBw=; b=X7AzC6arcegL4W15BhQHgudYzz3iOXKFSxAWYdB1huCV/0cg5YDz2il1O1GQ/dCFRg EAkIyyqskoKxC3LlqMQsKdGftZVfQx/ogI7oW0mN9KpkNX20DWY0/lHYyjUX6b4oogm0 67yatanJsVM/9X6XSGxadZ1mzoSs2kBxBf4jPqkCf7TkcVonzOGoPO051XOviBV+LRc+ xMnKoItWHwssLVZBAaxDeZOQpo1MIW1EdgWRX0Q7oD7BnaoRnlsbJ/Lk9tqUli2kvBuE rGHoMnCxhSsyGoimYYyX7kCcLwrB7bRds/W+YPN6niTpIx1SK8xBfi5ZELXvPvrmWy9E Q3fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788338406; x=1788943206; h=content-transfer-encoding:content-type: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:content-type; bh=lFeiGfwHFbNu+2NtxgAHyH+5BhpbpvplrOjaEEUWGBw=; b=oDOgI0hPAEUJM1TkWk5My+dsxN28fygwdgJK625C4LGNNVgdL3PscTeQzILkeGEJ2u 07wwXBRhlmKczydMQGW3Pd1DCHLBsPFesNu1n0uV8RXVcXcCEOYywwtoNCGR5jDF3z5E PaL3Wi1UYNsP0yQBLD5hVHNgc0UK2JO+qhr2uWQ+SmIisanm185RZp9wD/fEejwiu2OZ PGAjgRy43JXk/eDjshKCskq/7P9Bl9ZrlMQVjYO7ifrTZkCed1sumU1/vCGERNjYJHL0 MdzKBNS2gHVCFrrm5TUGKxaVbtJDAqCkBkRFqxbwnFgzLMoaWWIuW/iLfmSq0QKDRzSM LWbw== X-Gm-Message-State: AFuF++lY4o0dsVBxwjFNCceUUhv+iEDu38W4t7ddMAPOWfJws8d43XEi SEdMk2WOn5VQBMiEmSaBIoFUjdBxiaGXe/TMrlzx4zS8vI4CW8kxDw4jytNeeG3wyA== X-Gm-Gg: AR+sD10v6JlLYdl2Jgbj8iMinOMvzKnYz3xrxMafLfjWE52wd69CoQI0yO8rRSpM3Qk 9jlFOXZHze4aNo2JgybEjOf78paGbHLMgHx4n8IWgwK4AvJIBiyZNy/3gBNFhR7yWRhAfmBjJNY 1w/PhbDCsVYqyphVyzYebvgA1P5e1pl5+IVJu0IZBvVUnR/Px6U8I3nsvebHJapar/InFFxQLu3 Fm9eZWSbSr7j4yQC6P+Rwx17k6u8W4tQb6YShOwVujuxky6zGZUGgZ1HoqG8azGdIMEUY67V6cz uW10SmFIajSDRjAyBv4/I1ua25vonWuX79hOEOGLzG/PzPixsJlk6UCOwvPG68OXUBSlK2RLLzq u+w8W8+g9/N8Qyld9n6Q1/VXtj/UO2otzamddPMUoJFCIkigJOwhsblDSvPS2ZO0xDL+WutsWb7 6q4YlURUf0D4vZPeQ3gi6ztqoOqKXfMXvqSTaPdkFfv9n4gEvWg1F9FGTgMKjQNuoQqwLhfUHak wOCl9JTVHNXUM3OaQVlLqRI9625YU3+zRnoegTFLF95eJANX6hPAA== X-Received: by 2002:a05:600c:6296:b0:499:621a:2ec2 with SMTP id 5b1f17b1804b1-49ce581635bmr58290015e9.3.1788338406405; Wed, 02 Sep 2026 01:40:06 -0700 (PDT) Message-ID: <1047fb1f-87a3-46b9-ad91-904b05d8a637@suse.com> Date: Wed, 2 Sep 2026 10:40:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] x86/time: avoid early uses of NOW() to return zero To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: 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: 8bit X-purgate-ID: tlsNG-ebf023/1788338407-504DBB50-31705016/0/0 X-purgate-type: clean X-purgate-size: 2163 On 02.09.2026 09:54, Roger Pau Monné wrote: > On Wed, Aug 19, 2026 at 01:45:56PM +0200, Jan Beulich wrote: >> Waiting loops like the one in flush_command_buffer() will degenerate to >> infinite ones when used early enough for NOW() to still return constant >> zero. Make sure the returned value at least monotonically increases. When >> available, use nominal frequency values as initial approximation. >> >> Do this only in get_s_time(), as producing a sane value in >> get_s_time_fixed() for non-zero inputs won't be reasonably possible. >> Put an assertion there. >> >> Reported-by: Roger Pau Monné >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné I assume you won't mind if I correct the typo in the domain name. >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -1664,6 +1664,9 @@ s_time_t get_s_time_fixed(uint64_t at_ts >> const struct cpu_time *t = &this_cpu(cpu_time); >> uint64_t tsc, delta; >> >> + /* scale_delta() degenerates when the scale wasn't set yet. */ >> + ASSERT(t->tsc_scale.mul_frac); >> + >> if ( at_tsc ) >> tsc = at_tsc; >> else >> @@ -1679,6 +1682,20 @@ s_time_t get_s_time_fixed(uint64_t at_ts >> >> s_time_t get_s_time(void) >> { >> + /* >> + * Before the TSC scale is set, avoid returning constant 0 (or whatever >> + * this_cpu(cpu_time).stamp.local_stime is set to). While the returned >> + * value is in no way representing time, it at least increases >> + * monotonically, thus avoiding e.g. waiting loops to degenerate to >> + * entirely infinite ones. >> + */ >> + if ( unlikely(!this_cpu(cpu_time).tsc_scale.mul_frac) ) >> + { >> + static s_time_t counter; > > Not that it matters much, but counter can probably be __initdata? I wanted to play safe here: In get_s_time_fixed(), release builds won't crash if the assertion wasn't there, but would trigger in a corresponding debug build. In that (unexpected) situation, we'd crash here (when .init.* was unmapped) if __initdata was used. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:55:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:55:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405366.1638865 (Exim 4.92) (envelope-from ) id 1x1gke-0007mQ-Jy; Wed, 02 Sep 2026 08:55:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405366.1638865; Wed, 02 Sep 2026 08:55:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gke-0007mJ-GU; Wed, 02 Sep 2026 08:55:24 +0000 Received: by outflank-mailman (input) for mailman id 1405366; Wed, 02 Sep 2026 08:55:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gkd-0007mD-NJ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:55:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1gkb-00AqSt-9Q for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 10:55:21 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97e472-2eae-0a2a0a5409dd-0a2a450999c6-18 for ; Wed, 02 Sep 2026 10:55:21 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97e476-be1a-0a2a45090019-d1558029e1bf-3 for ; Wed, 02 Sep 2026 10:55:18 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49cd9add88aso4680395e9.3 for ; Wed, 02 Sep 2026 01:55:18 -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-49ce58da3acsm80590125e9.0.2026.09.02.01.55.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 01:55:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788339318; x=1788944118; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=nA2s6HuoziJ0Mqf7gcg+y4QLcc/T8IpHG9vT0Iw59h4=; b=Zyg81cTfr4uGJB0T1uULem0KhGD0CeoVJ2ecOvgkpfrMJCmpt/Gt2BdKS3SjvHaG7j tskRbNmnjNnKhTI4ZXEK2FQfr+RTYq9a2y1gl6zKCipdiopUTVagl2f8kKlf1d3zY9Q8 mwLPZ7vUNI2VjYj7HiTOTC7xc5M/1dudUoonnpyk8qggncjgm2PdM/MBzXKKwpgGhKKy NFNYFv9YQJxTp+sCbglyxkFJ0SRHo55DlBXvps6Us2JS3O7qc8jCJEZxXNf+qqu0BnU0 RI8C3TMNyk/8zWtV+XFA6Vr+lP65X3S13g+zkEuPDhMkjDCS8mSptk0VDG/4gPe8E6+q hqBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788339318; x=1788944118; h=content-transfer-encoding:content-type: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:content-type; bh=nA2s6HuoziJ0Mqf7gcg+y4QLcc/T8IpHG9vT0Iw59h4=; b=d/RYAxIEQpdMkv+0NVY1ITsN2tDs0iWsHsWINmWiJp6JRsZZWNp8xN+WVB92WLsQt+ 50acLPoUj5riATPIizHiMWReDKBVndYy61ieXvJwbiJhmvBDHohT8rBqCsmqrforGP3n 4kz0eW7PBQ8grEe7bsnIe3qtDlEDZNjrb2nlg5YSPR3WHg/WaAgM9H/nP2zjCBtvG+Ba 9AqZv65+fkwrHxm2HCOfoyjLZNG1XuWNJcICPQ53mVABw5lZw4iPKqkOMraXNXbXTSER MTy5TE0s62NtmAdM5LQMnGv8pVD8DnTzqvwkBqxqZRAaDBsc/8WIb7SX5/xJef4unhSD 6NcA== X-Forwarded-Encrypted: i=1; AHgh+Rpw5dd2NMhzaPDDRUWeekAAjMU3f0j1mKPSkTLw0SenxGvd/0EkcOONTvvj9ls+/4mUlce1vNWign8=@lists.xenproject.org X-Gm-Message-State: AFuF++k+7kw8HGkX4Aq6R4PRMrtaDU0anCDPR/J6fWmGoQS1mB+Ibwsy UUzfOxUOeXLT/aJY8OfmN+H9hwMwNXwpnMLfMWVSSxl3neLVY7nte8Q7nR+mPaOAcw== X-Gm-Gg: AR+sD10yiem5oOSF3F30+MPLPlX5XCWhQmtxtiTh3FudZ5xo0+5nmu/dhG91fXcublW KfiotErbb/oWT+ZTmyq31jEj48Dte58M/Ag7b1ySYenD3kI/DlC4pAO6750+y7BVsyVDlvyAEVD yzjPu3q6+eQnAa6VUkIELcxel8RSBi7OsD7lswMm1wlPyYzOYu5WviMuKcU/FCR/HWwDLqcHCf4 UhMCunPzsd/Uh+m4F0GOe8I6eUuxit3mLIxpD3NWjF5gvW6EcZcTXJWio5iZmJkY+ZCXG9QPbs9 nz+cxaRbadHMXDMZSNnq0z+pGgpRbE9pHu7cxdW9uMwy5Z0i0rN/ENe1OSugQk5ZWWfS7Wifc4r Iqd/Sdk8nDijb/QOs9m6SttjN5vkckAbfGlWz/iK4zn72nnG2xX4kynTtdsSvX8dwAEWL5Dq71b +I4EhY4LETHq1OAUT85SkCeCj6sGNJbLvpAxJ6Uttd0ME8wuIbqjCDQcbtOpdt49X+CbVRc9i1C jFH7BwtvBWmf2U4C2r5cUyq/WpB/9TRO5QoJhynHwbYH3pmnayz X-Received: by 2002:a05:600c:8b63:b0:49b:c8e:8e6 with SMTP id 5b1f17b1804b1-49ce558ebd8mr62707605e9.0.1788339317713; Wed, 02 Sep 2026 01:55:17 -0700 (PDT) Message-ID: <37872f45-8078-44ef-9db8-a9868c9b79aa@suse.com> Date: Wed, 2 Sep 2026 10:55:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] cmdline: Document console=dtuart option To: Michal Orzel Cc: Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260902073606.61062-1-michal.orzel@amd.com> <20260902073606.61062-2-michal.orzel@amd.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: <20260902073606.61062-2-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788339318-FCA16034-6078AA62/0/0 X-purgate-type: clean X-purgate-size: 1354 On 02.09.2026 09:36, Michal Orzel wrote: > Document the default console= option on Arm and RISC-V that is > "dtuart" indicating a generic UART parsed from a device tree or > ACPI SPCR table. This serial utilizes SERHND_DTUART handle. > > Take the opportunity to: > - fix documented x86 default to vga to match OPT_CONSOLE_STR, I first wanted to object to this part, as I was sure this used to be "com1,vga". Yet indeed it's been almost 19 years ago when this was changed (92877a1f9ab2 ["x86: Auto-probe the serial port baud rate if 'com1' or 'com2' is"]). > - mark dtuart option as available on RISC-V, > - document fall back to /chosen/stdout-path. > > Signed-off-by: Michal Orzel Acked-by: Jan Beulich > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -430,9 +430,10 @@ The following are examples of correct specifications: > Specify the size of the console ring buffer. > > ### console > -> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]` > +> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | dtuart | none ]` > > -> Default: `console=com1,vga` > +> Default (x86): `console=vga` > +> Default (Arm, RISC-V): `console=dtuart` Any reason to not also cover PPC here? Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 08:56:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 08:56:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405375.1638874 (Exim 4.92) (envelope-from ) id 1x1glm-0008Ho-T3; Wed, 02 Sep 2026 08:56:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405375.1638874; Wed, 02 Sep 2026 08:56:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1glm-0008Hh-QJ; Wed, 02 Sep 2026 08:56:34 +0000 Received: by outflank-mailman (input) for mailman id 1405375; Wed, 02 Sep 2026 08:56:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1gll-0008HS-W0 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 08:56:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1glk-00FtXH-TD for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 10:56:32 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97e4be-2eae-0a2a0a5409dd-0a2a450bce04-4 for ; Wed, 02 Sep 2026 10:56:32 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97e4bf-b7e8-0a2a450b0019-d1558029bc07-3 for ; Wed, 02 Sep 2026 10:56:31 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so6936825e9.0 for ; Wed, 02 Sep 2026 01:56:31 -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-49cdce10153sm142724845e9.4.2026.09.02.01.56.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 01:56:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788339391; x=1788944191; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=EkGNW96hwwDqWM0OQ1Pr+8RqFw6eRJES3MQo+mTzoGU=; b=VEVKMeNNS1gF2LiEKd5StZ5HYKkWgqKm6TiDkfvNx6byE2TFb5wvsIsluB37yOeywK Pn8WOiN/5PlleVvybJ/Pqfr9XD1mvinOhIE03JXsvv66hPhZXdPIpTDm2QvajKpGlOWC h2T3GvED9KLKGU32CCWD1HwC52JEo+UqXBZ75z5ui/M7U02IwcPLdoiFHT5IuMB54KDq ODQko35tp8PD1a03zS/FPCmHUpkPsoNI5XVoWJNS8//u2Ra87TjH0xEk6caIKBmjGt9w VvHBRjdpJzeDCqOWKyu1mOt4vMlZvfkWw82Fzyst51V731w9ma//pEaxheYjf2SqMGQ9 q/IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788339391; x=1788944191; h=content-transfer-encoding:content-type: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:content-type; bh=EkGNW96hwwDqWM0OQ1Pr+8RqFw6eRJES3MQo+mTzoGU=; b=Dqg78vUFy+y6IQYPuU+NrhwpL7xRNE/fy5bxn/fq6glme0fDxYffUjQRbgmDu2rOTt XnsA45sbcaWGeVmPz+cUcEGRI2ZAaNBc8/xWOoiPj3qXdD/fQyx1Q0UH84VeaIikQI8X QAqESTtb0TUb6U4etr0Zz3eCvrNn2A7Uj2J2wgihn+oKy7QKrUGf/zylwNRh3kzsQE7/ azfEeQ/WQOVNpINcXeeHtFJeogeIiz5QIl13CNnyNsGVykq+5QOrlnkpQVFOlzDcRQra 0E6FXG1+kKBc3m4nTMinP8hQXEYVWlXSk4Mcn/bXC80GywtDuPFR27SfYLF0tdYuG1Il ZYeg== X-Forwarded-Encrypted: i=1; AHgh+RoqpouD24uvtEDAqEbyGrtRDmmrKywLRpTJUaA86aLlfXJa3WIxQfJZdYse2ku6RuD0PCP/K7T612Y=@lists.xenproject.org X-Gm-Message-State: AFuF++l1RqASbBmNAasly0Mtz3x4LxqkAIDhFC6zNhdkaUMb21uPX8od i8wBYjyjjtQIwSuAmr2vQvWTtEMvjPCXimSBF5Sy6n8pDK8v7gtzradUBrbrSsal+Q== X-Gm-Gg: AR+sD11apiwyb24yZuVRZWRBwrfcCBS75NDlDXx2imZVM0uqQFbEW/faY5d445VBq9b PSa8o8VT41Zv8BVmoXF3msD334SsGZwgloarNU7Mc/9pLIarXrAytZ4u7yXeJI4y6zZP7vmVzai wg0jqgKxPcdhjxXd36haUwVugz7FXlgEGGesh/Cp/rlW2alSS+wYKk+lKN6qrFLTvptjEL+ben9 2XWwswjRtiQ/xNnKv8VhzKwb9Dwv6vEmjNcWt9MTuyoQB1mSOj13hEuqFbQhqkJJSDm9OGRCXw9 LL3WEM0hcie3jz92Bkl1A60pBQOEB0NxIrTObVdg3h8I/zIfZsJksHy27QBjYinsQsi75VGnTpO MC3VC/Z1C98ckIz5a3P+N4uZU/rzfvSGqv2MfR1T/yzm6u8VHrHGZp7VLAK1cn2dLsXPiZ7zN8E rU/fNcMzdO44OZDuI/tayrlxC6a/Z9z8BT7tJMvu8daoCIruy7mqpGmfbFZDm5yd20Wp62xtSN+ w6RtZbEXsnSKFgf8R2MrcPVbLB4s7JN7a9T77RtTOeTS/0/YCQR X-Received: by 2002:a05:600c:8b05:b0:499:b65d:124f with SMTP id 5b1f17b1804b1-49ce5823d9dmr66172685e9.11.1788339391259; Wed, 02 Sep 2026 01:56:31 -0700 (PDT) Message-ID: <8efb31c8-cb19-4cc7-b752-7786139afafa@suse.com> Date: Wed, 2 Sep 2026 10:56:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] drivers/char: Check if console=dtuart for ACPI SPCR serial bring up To: Michal Orzel Cc: Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260902073606.61062-1-michal.orzel@amd.com> <20260902073606.61062-3-michal.orzel@amd.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: <20260902073606.61062-3-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788339391-194C39EA-093942C1/0/0 X-purgate-type: clean X-purgate-size: 598 On 02.09.2026 09:36, Michal Orzel wrote: > dtuart denotes a generic UART parsed from a device tree (back then it > was the only method, hence dt prefix) or ACPI SPCR table (they all use > the SERHND_DTUART serial handle). Currently we only check if console= is > set to dtuart in the DT flow and not in the ACPI flow. This means that > even if we set console=none we would still bring up ACPI parsed > serial device for nothing. Move the check to uart_init() to cover both > paths. > > Signed-off-by: Michal Orzel Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:02:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:02:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405384.1638882 (Exim 4.92) (envelope-from ) id 1x1grn-0001hk-H4; Wed, 02 Sep 2026 09:02:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405384.1638882; Wed, 02 Sep 2026 09:02:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1grn-0001hc-Dc; Wed, 02 Sep 2026 09:02:47 +0000 Received: by outflank-mailman (input) for mailman id 1405384; Wed, 02 Sep 2026 09:02:46 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1grm-0001hV-Gu for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:02:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1grl-00EUJq-K0 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:02:45 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97e62e-2eae-0a2a0a5409dd-0a2a45039c26-40 for ; Wed, 02 Sep 2026 11:02:45 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97e635-fae8-0a2a45030019-d1558031e997-3 for ; Wed, 02 Sep 2026 11:02:45 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49cd77e0f95so8391575e9.3 for ; Wed, 02 Sep 2026 02:02:45 -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-49cdce44ea9sm127452685e9.14.2026.09.02.02.02.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 02:02:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788339765; x=1788944565; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=zW5oa0KHC7eTQ+QsWj8IgZyoVT8vrQRPdx9BJfewjZI=; b=YWXq4XQ6PaeBFnTv1SqbqMwrYUa1Fax7566HS0YNygI3hmAVfeAyGDhAQ04I+t7Zi4 q+mLMwFlf2++PWEfGGsFU7OKrI7drsRZnsNeq5EAoPg7TlJTe+rnuClp4fmstpQKDiBY LwEF7WB/WkKZleV0HXh0NYIAoEXXwQ7pFBTJUsazcK/gVLhnpsEIOW8jM/xXXkfe8iCu 4p+Z+jhW74pOrSCPg7+mvoJpSY/OKJU41Il3kcS4JUrfoR/h4ez5276xbUxiGxHjR/yc e7ssZM+SJ0C+EZtS09yYByDQCX8b3IwKaGjKpC8KmDJLvIpeO0RkCjrgyTEV/Sw62623 Zd4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788339765; x=1788944565; h=content-transfer-encoding:content-type: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:content-type; bh=zW5oa0KHC7eTQ+QsWj8IgZyoVT8vrQRPdx9BJfewjZI=; b=nrZgKmSq2z/1LsTMOSfroK4mFoWIXhnGorgViUQepZ04Xurg3QNiBzsbqEzwkL7oQH PN3uVdHD+OZDvwZwLobrkYAbg0cugp5jJ24HFBYuOn4GW8tBtdeXEaJbAcosHRGM6NGH QtRFoRgm65LRojkqNKdvK2/AIjHCXxfacQ9XyZywXSXrvPhSEproJzuoQJLlGESL5/h4 hdKdfsUr5pVyN99UalSPc3Ih2yA8ok+o6tBLC5LkcRQmoCe2c9wEBICb9oG1RWevEIuH CsnxZc/byBKeaD5wJH2VZq/4RQjUfh/fW/fcGVPf7QwJRjFjy8MTFUq3e9E6ZzXiYxpc JFqQ== X-Gm-Message-State: AFuF++mxYjobBb6kPEeKN15gGZ5RHwBVgA2U2l90oXyrKEtLZWwbnChY rvKsNjmY9v1tsOeOKYwK9RkvMGzcp8wuAs+Eod22M22ymCxil4zJiU495/pb+Ey8yA== X-Gm-Gg: AR+sD13m4EEBH/u95THBVIwlkX3X0Lc4lYazIQq0d77icxMgtbs+IMrzeFsWBr/bZ1i XjDDr4zagVQ/Z56+1zarDeaYjrNZc2dCsPr+xFHNHd/2y7dJLmlN2XI21ugLbeepj5zdnLQ1UV3 q1dcQ88Z7rgqGbk4pSOmPvLnMpFBR33A929c6YizKTgL0m6JWTugGLKsqg2atIH1bTuujBFImyR 4hPERENltrrxWgQZXkpypz7GExX7D3aIloSxOOnk7bWjpE2T6xlt4LDIORIvtN014Hdn5Nfm4NC omreDLywDhmFADKnaNnrKkdY4yep26uTXQNhHGr3YtglsLlO5hUEwppxvzPiRCatYxScoeoEvTu hknaEIUKA7VtWMLQitBOoeGULKDXELh/6134jyJaILrYiT2IbwPTVeDfQF1M7k8dkS+c0Otxdvo 9ZbDBRjS6B95Kp83hMaU+3sBDLDvg4e2Nx73G4oupxOUSfVrnxznHvXSj0dN7krJd4Pttsd2jlk D8PE+642LTnzXLa2C9vkgz0Wm8i1QUW8jz4aLn9WJdyyUXT1bnB X-Received: by 2002:a05:600c:4f0b:b0:493:bd2a:93be with SMTP id 5b1f17b1804b1-49ce581316dmr46207105e9.6.1788339764623; Wed, 02 Sep 2026 02:02:44 -0700 (PDT) Message-ID: <6dd4c596-aebd-4488-94da-35fb9d85d6ac@suse.com> Date: Wed, 2 Sep 2026 11:02:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] x86/time: CMOS RTC may run in binary mode To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <79d50725-3892-4643-b854-bfec9c0c0d79@suse.com> <5945d8f4-aece-4572-8e89-60408dd7ac32@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: 8bit X-purgate-ID: tlsNG-33051d/1788339765-774F44E9-491AD829/0/0 X-purgate-type: clean X-purgate-size: 2433 On 02.09.2026 10:04, Roger Pau Monné wrote: > On Thu, Jul 02, 2026 at 11:29:11AM +0200, Jan Beulich wrote: >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -339,6 +339,14 @@ parameter to "stable:socket". >> Specify the event count threshold for raising Corrected Machine Check >> Interrupts. Specifying zero disables CMCI handling. >> >> +### cmos-rtc-bcd (x86) >> +> `= ` >> + >> +> Default: `false` >> + >> +Flag to indicate the CMOS Real Time Clock uses BCD mode irrespective of >> +control register B indicating binary mode. >> + > > Likely too late for it now, but I get the feeling we should have > introduced a cmos option, with rtc-bcd and rtc-probe as boolean sub > options: > > cmos = [ rtc-probe, rtc-bcd ] I was thinking the same - would be nice, but here we are. >> @@ -1353,6 +1356,48 @@ static bool __init cmos_rtc_probe(void) >> return false; >> } >> >> +static inline bool __init attr_const is_bcd(unsigned int x) >> +{ >> + return (x & 0xf) < 10 && (x >> 4) < 10; >> +} >> + >> +static void __init cmos_rtc_probe_bcd(void) >> +{ >> + bool bcd; >> + unsigned long flags; >> + >> + if ( opt_cmos_rtc_bcd ) >> + return; >> + >> + spin_lock_irqsave(&rtc_lock, flags); >> + bcd = !(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY); >> + spin_unlock_irqrestore(&rtc_lock, flags); >> + >> + if ( bcd ) >> + return; >> + >> + for ( unsigned int seclo = 0; ; ) >> + { >> + struct rtc_time rtc; >> + >> + if ( !__get_cmos_time(&rtc) || >> + !is_bcd(rtc.sec) || >> + !is_bcd(rtc.min) || >> + !is_bcd(rtc.hour) || >> + !is_bcd(rtc.day) || >> + !is_bcd(rtc.mon) ) >> + return; >> + >> + if ( seclo > (rtc.sec & 0xf) ) >> + break; >> + >> + seclo = rtc.sec & 0xf; > > Is there a risk of this loop triggering the watchdog, and hence we > should process softirqs in the loop? (or otherwise have some kind of > hard loop stop after certain iterations / time) > > Oh, I now see the mention in the commit message and also note this is > done ahead of SMP and also ahead of the watchdog being enabled, hence > it can't trigger the watchdog. Right. I can't conclude whether you're asking for any change here, as there also was no ack. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:15:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:15:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405399.1638891 (Exim 4.92) (envelope-from ) id 1x1h3s-0003sM-Md; Wed, 02 Sep 2026 09:15:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405399.1638891; Wed, 02 Sep 2026 09:15:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1h3s-0003sF-K0; Wed, 02 Sep 2026 09:15:16 +0000 Received: by outflank-mailman (input) for mailman id 1405399; Wed, 02 Sep 2026 09:15:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1h3r-0003s9-15 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:15:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1h3q-001pbZ-2A; Wed, 02 Sep 2026 09:15:14 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1h3q-007IB8-0J; Wed, 02 Sep 2026 09:15:14 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=x/tOVHZzTOR6m14ACdUVe70763wiim5Cnk9IKbrQW1s=; b=er2cy9swi0sAX85LHlY4u+QH0W At+9kyCju9CQb8p2mrh+l8t6YFkNisgd8g88IGDohYYpwRdHtW+Rrm5r+K+tYjNWEo+TOM73YCeY1 kRUaw3i/Wr4Lnb3pYfY1UWvYkI3CHWaK8ZGMQtEtriOsgpKKaB8yMDAmK+yhNVrpEbEk=; Date: Wed, 2 Sep 2026 11:15:09 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v5 2/2] x86/time: avoid early uses of NOW() to return zero Message-ID: References: <1047fb1f-87a3-46b9-ad91-904b05d8a637@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1047fb1f-87a3-46b9-ad91-904b05d8a637@suse.com> On Wed, Sep 02, 2026 at 10:40:04AM +0200, Jan Beulich wrote: > On 02.09.2026 09:54, Roger Pau Monné wrote: > > On Wed, Aug 19, 2026 at 01:45:56PM +0200, Jan Beulich wrote: > >> Waiting loops like the one in flush_command_buffer() will degenerate to > >> infinite ones when used early enough for NOW() to still return constant > >> zero. Make sure the returned value at least monotonically increases. When > >> available, use nominal frequency values as initial approximation. > >> > >> Do this only in get_s_time(), as producing a sane value in > >> get_s_time_fixed() for non-zero inputs won't be reasonably possible. > >> Put an assertion there. > >> > >> Reported-by: Roger Pau Monné > >> Signed-off-by: Jan Beulich > > > > Acked-by: Roger Pau Monné > > I assume you won't mind if I correct the typo in the domain name. Sure, please do. > >> --- a/xen/arch/x86/time.c > >> +++ b/xen/arch/x86/time.c > >> @@ -1664,6 +1664,9 @@ s_time_t get_s_time_fixed(uint64_t at_ts > >> const struct cpu_time *t = &this_cpu(cpu_time); > >> uint64_t tsc, delta; > >> > >> + /* scale_delta() degenerates when the scale wasn't set yet. */ > >> + ASSERT(t->tsc_scale.mul_frac); > >> + > >> if ( at_tsc ) > >> tsc = at_tsc; > >> else > >> @@ -1679,6 +1682,20 @@ s_time_t get_s_time_fixed(uint64_t at_ts > >> > >> s_time_t get_s_time(void) > >> { > >> + /* > >> + * Before the TSC scale is set, avoid returning constant 0 (or whatever > >> + * this_cpu(cpu_time).stamp.local_stime is set to). While the returned > >> + * value is in no way representing time, it at least increases > >> + * monotonically, thus avoiding e.g. waiting loops to degenerate to > >> + * entirely infinite ones. > >> + */ > >> + if ( unlikely(!this_cpu(cpu_time).tsc_scale.mul_frac) ) > >> + { > >> + static s_time_t counter; > > > > Not that it matters much, but counter can probably be __initdata? > > I wanted to play safe here: In get_s_time_fixed(), release builds won't > crash if the assertion wasn't there, but would trigger in a > corresponding debug build. In that (unexpected) situation, we'd crash > here (when .init.* was unmapped) if __initdata was used. That's kind of what I was aiming at: we possibly do want to crash hard if Xen is still using the fake counter after initialization? Nothing good can come out of running guests without the TSC scaling being set, as the PV clock exposed won't be functional either. Likely resulting in guests relying on it also getting stuck because mul_frac == 0? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:17:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:17:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405407.1638902 (Exim 4.92) (envelope-from ) id 1x1h6L-0004Yb-42; Wed, 02 Sep 2026 09:17:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405407.1638902; Wed, 02 Sep 2026 09:17:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1h6L-0004YS-0C; Wed, 02 Sep 2026 09:17:49 +0000 Received: by outflank-mailman (input) for mailman id 1405407; Wed, 02 Sep 2026 09:17:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1h6J-0004YJ-64 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:17:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1h6J-001pdA-0X; Wed, 02 Sep 2026 09:17:46 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1h6I-007RMY-1l; Wed, 02 Sep 2026 09:17:46 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=lwX/OAtwnMJIo6cz8sHcIxIiEPCHKIsjDQsdlGOkZ3U=; b=pkstVnK54Ib+ArwAKJbvDzER5x HPDQ4gOtnCwo8dFneZre2uW0poO24IcWW2ieyoa7YgqoIRM3doXP91Fy/D5bfOLfN5S2j7zeL57Cs 1wWAKbfiZFFT8GfYYlkMUcbMSJkxgA9O7+E7YAQCvpxizEqIm0iu3oJCO9B53ZQmYzC4=; Date: Wed, 2 Sep 2026 11:17:36 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v2 1/4] x86/time: CMOS RTC may run in binary mode Message-ID: References: <79d50725-3892-4643-b854-bfec9c0c0d79@suse.com> <5945d8f4-aece-4572-8e89-60408dd7ac32@suse.com> <6dd4c596-aebd-4488-94da-35fb9d85d6ac@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6dd4c596-aebd-4488-94da-35fb9d85d6ac@suse.com> On Wed, Sep 02, 2026 at 11:02:43AM +0200, Jan Beulich wrote: > On 02.09.2026 10:04, Roger Pau Monné wrote: > > On Thu, Jul 02, 2026 at 11:29:11AM +0200, Jan Beulich wrote: > >> --- a/docs/misc/xen-command-line.pandoc > >> +++ b/docs/misc/xen-command-line.pandoc > >> @@ -339,6 +339,14 @@ parameter to "stable:socket". > >> Specify the event count threshold for raising Corrected Machine Check > >> Interrupts. Specifying zero disables CMCI handling. > >> > >> +### cmos-rtc-bcd (x86) > >> +> `= ` > >> + > >> +> Default: `false` > >> + > >> +Flag to indicate the CMOS Real Time Clock uses BCD mode irrespective of > >> +control register B indicating binary mode. > >> + > > > > Likely too late for it now, but I get the feeling we should have > > introduced a cmos option, with rtc-bcd and rtc-probe as boolean sub > > options: > > > > cmos = [ rtc-probe, rtc-bcd ] > > I was thinking the same - would be nice, but here we are. > > >> @@ -1353,6 +1356,48 @@ static bool __init cmos_rtc_probe(void) > >> return false; > >> } > >> > >> +static inline bool __init attr_const is_bcd(unsigned int x) > >> +{ > >> + return (x & 0xf) < 10 && (x >> 4) < 10; > >> +} > >> + > >> +static void __init cmos_rtc_probe_bcd(void) > >> +{ > >> + bool bcd; > >> + unsigned long flags; > >> + > >> + if ( opt_cmos_rtc_bcd ) > >> + return; > >> + > >> + spin_lock_irqsave(&rtc_lock, flags); > >> + bcd = !(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY); > >> + spin_unlock_irqrestore(&rtc_lock, flags); > >> + > >> + if ( bcd ) > >> + return; > >> + > >> + for ( unsigned int seclo = 0; ; ) > >> + { > >> + struct rtc_time rtc; > >> + > >> + if ( !__get_cmos_time(&rtc) || > >> + !is_bcd(rtc.sec) || > >> + !is_bcd(rtc.min) || > >> + !is_bcd(rtc.hour) || > >> + !is_bcd(rtc.day) || > >> + !is_bcd(rtc.mon) ) > >> + return; > >> + > >> + if ( seclo > (rtc.sec & 0xf) ) > >> + break; > >> + > >> + seclo = rtc.sec & 0xf; > > > > Is there a risk of this loop triggering the watchdog, and hence we > > should process softirqs in the loop? (or otherwise have some kind of > > hard loop stop after certain iterations / time) > > > > Oh, I now see the mention in the commit message and also note this is > > done ahead of SMP and also ahead of the watchdog being enabled, hence > > it can't trigger the watchdog. > > Right. I can't conclude whether you're asking for any change here, as > there also was no ack. Hehe, I guess I was probing whether you wanted to do anything about the proliferation of cmos related top-level options. Acked-by: Roger Pau Monné Albeit I think it would be nice to introduce a common cmos option in a future patch and deprecate the separate top-level ones. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:20:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:20:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405415.1638909 (Exim 4.92) (envelope-from ) id 1x1h8l-00063n-DE; Wed, 02 Sep 2026 09:20:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405415.1638909; Wed, 02 Sep 2026 09:20:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1h8l-00063g-Ai; Wed, 02 Sep 2026 09:20:19 +0000 Received: by outflank-mailman (input) for mailman id 1405415; Wed, 02 Sep 2026 09:20:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1h8k-00063a-AN for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:20:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1h8j-00FxsO-NN for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:20:17 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97ea49-8faa-0a2a0a5109dd-0a2a450aa3e2-28 for ; Wed, 02 Sep 2026 11:20:17 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97ea51-f2d2-0a2a450a0019-d155802abca9-3 for ; Wed, 02 Sep 2026 11:20:17 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so7111795e9.0 for ; Wed, 02 Sep 2026 02:20:17 -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-49ce4776131sm61402465e9.11.2026.09.02.02.20.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 02:20:16 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788340817; x=1788945617; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=BcSdzFWN5hy7t+0qz12q73oRPE9SgY3maDTcQf5uGqU=; b=JWPaSdRbWuQd+iEFbNgtO3GPoBtud7Zn1jwFqoVqenyB92L/NLJBsklcSpI27s7gqD +rbWEthwPLe9gKJJ3L+78BZxJzgUbT4nQa5TFhP5gVwbbHLEX674v6+f1/JXRAlxaWJz QDdtT73NJJmKeGgWIvBVeP1ymczHX790Mxqfz7R5fM6L/QrHxnxe3nx+y+EdkoqLYf3y HSpYY/ym+vePQpkIXwTZ8avOzVxTVVGlXpB64GqEBOwShjoaHf1sh2w9AzuV8cq2JVeI g4FmDN2UjC7hgSl5YzDo2GiGxWO3WofRKCBjHprWZMGv4Dzq2Zb9SWs7zPi7nmK186hq ROUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788340817; x=1788945617; h=content-transfer-encoding:content-type: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:content-type; bh=BcSdzFWN5hy7t+0qz12q73oRPE9SgY3maDTcQf5uGqU=; b=mD/mzKmNnwgXq7OwjTvgK9+4RiZ5/LsbU4DbiizB6r9WLV0K8TZe5w0ZHHNl8gPtfo N1+yqxVQc9z46FYdREHg7vCUt/YhAopVqGMa5Nwjadla8l7NOoSgRBRTsokmmWa1QPol X4qQrfCt/Kn9FTTW+QpxeZxW9MR28tSZQ9TT9VC+huzOeMgqT5hLsFgtebhtmSf2/5nz lzp+hfoxWWtPI7falU3YMXtp54H8WNDz7TYRNSy+n7rECo2dS6ysH4kdLMBogELssPUG P20sKSluRiCDzFz2YFMVX6qPg5PtRK5kQf9FWYglAjvxDXab43sNKd5ZcuhWN2/qXOQF FnHA== X-Gm-Message-State: AFuF++nRafpql8gQojRppYOJnDAwv5W0IhBG8UF5PCi3/Y23DL56deLj N/O8A3nJEs5FsI5ID6rQ/g6WsL1K1iif3s0ZwOkK2TYv+IGxygjF1dVDe1p1JeDRFEA+AZGwnbr +OOfKJQ== X-Gm-Gg: AR+sD11cjD1D2yoqx7V02Z2jgvnQpfZz6YJLQMggZSzgknq/qNZlfh3m8uvMEHvhL5R VE7PeSWuFUvi8vdUm6LPtSKdIoGoCnYEpontEgYuoxMFEcKz165T4MRTVr6+ub0D1PJY+awLLCM +AwNro75eNYtTJvIK5womxnzzcWC5zJ0iasXdedP+jDrVUfdEXCXtg71qrZtFDPt2EQpXc8glGO aQTuBaD4UcF9VylZ6oIRbgi+jGLVbSJURzwSGMlwEfgeyZYWc9G9pwkNJgWWJ0rTg5W4gf6tjuW KCyy0nU5zTs43VRnyE2SKulBMrq9ZGe1TmjoLFsy/WlowNipXd9OkQpgVq6ZlI//Dc87z1BveOA c8pCPskaE/FL4+DxwyVESE6O/WmRnCgBkmzbOwdRCSZWc1Es+vPMN91cHNNOtOvhnQvbi5qSNVw Y3cfAccWEffvt8n5DwnbIq/xjeoK7+um6YCrWpVkkyPM+Og//53OoYUrr4/vYETPc3xLe738slW iSfq5gcx7EWvl9Yb4ram84/6/gPg+KapVyJJkkT1+1lvLvq/Jdj X-Received: by 2002:a05:600c:45c4:b0:49c:e1df:79a4 with SMTP id 5b1f17b1804b1-49ce57fdd1emr58575165e9.5.1788340816846; Wed, 02 Sep 2026 02:20:16 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 11:20:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] x86/vRTC: support century field To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: 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: 8bit X-purgate-ID: tlsNG-4011c0/1788340817-587CACFC-1E6F2BDB/0/0 X-purgate-type: clean X-purgate-size: 4179 On 02.09.2026 10:07, Roger Pau Monné wrote: > On Thu, Jul 02, 2026 at 11:31:14AM +0200, Jan Beulich wrote: >> Both ROMBIOS and SeaBIOS (with CONFIG_QEMU=y, as we build it) blindly >> assume availability of this field (at its conventional index 0x32); OVMF >> at least has code to inspect FADT. Hence we ought to have supported it >> virtually forever. >> >> As the index is beyond RTC_CMOS_SIZE, leverage the padding field in >> struct hvm_hw_rtc to hold its value. Update the field only when involved >> values are valid BCD century specifiers. Otherwise (for VMs migrated in >> from an older hypervisor) leave handling to the DM. >> >> This makes the Linux rtc-cmos driver report y3k compatibility. >> >> In the new rtc_check(), besides checking the new fields also check the >> pre-existing pad0 field. >> >> While extending xen-hvmctx.c:dump_rtc() also add RTC offset there. >> >> Fixes: 4ca161214355 ("[HVM] Move RTC emulation into the hypervisor") >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. >> Now that we extend struct hvm_hw_rtc, should we perhaps save not only the >> century, but also its index? > > Hm, possibly for correctness, albeit I think this is unlikely to cause > issues. Likely better done in a separate patch? Possibly. Just that then we need to deal with two different cases of backwards compatibility. (Not that I think that doing so would be overly difficult, but still.) >> Likely more sanity checking could be added to rtc_check(), but that's for >> a separate patch imo. >> >> Isn't day-of-week handling flawed? If the field is brought out of sync >> with the other values, shouldn't it stay respectively out-of-sync? > > I don't know that much about the RTC TBH. > >> And >> isn't it excessive overhead to go through rtc_set_time() when the field >> is updated while SET is clear? > > I think this is done because we don't call rtc_set_time() when RTC_SET > is activated in RTC_REG_B? We would need to change the logic a bit. I think you may have overlooked that my question was just for the day-of- week field. When that field is changed, rtc_set_time() will call mktime(), update_domain_wallclock_time(), and send_timeoffset_req() despite the change not having any effect on the values used/calculated there. The only actual change in that case is to s->current_tm.tm_wday. > Is there a reason to propagate the changes to the DM even when SET is > not active? How does a DM come into play here? It's only accesses to non-time fields of the CMOS which we forward to the DM. >> @@ -760,6 +795,32 @@ static int cf_check rtc_save(struct vcpu >> return rc; >> } >> >> +static int cf_check rtc_check(const struct domain *d, hvm_domain_context_t *h) >> +{ >> + const struct hvm_save_descriptor *desc = >> + (const struct hvm_save_descriptor *)&h->data[h->cur]; >> + struct hvm_hw_rtc s; >> + >> + if ( !has_vrtc(d) ) >> + return -ENODEV; >> + >> + if ( hvm_load_entry_zeroextend(RTC, h, &s) != 0 ) >> + return -ENODATA; >> + >> + if ( s.pad0 ) >> + return -EINVAL; >> + >> + for ( unsigned int i = 0; i < ARRAY_SIZE(s.pad1); ++i ) >> + if ( s.pad1[i] ) >> + return -EINVAL; >> + >> + if ( desc->length >= endof_field(struct hvm_hw_rtc, century) && >> + ((s.century & 0xf) >= 10 || (s.century >> 4) >= 10) ) >> + return -EINVAL; > > It would be nice to also set ->has_century here, but the s struct is > a temporary stack allocation. And deliberately so, as .check() hooks shouldn't alter state. (Hence also why const struct domain * is passed in.) >> @@ -793,12 +854,18 @@ static int cf_check rtc_load(struct doma >> check_update_timer(s); >> alarm_timer_update(s); >> >> + if ( !s->hw.century ) >> + { >> + s->has_century = false; >> + s->hw.century = 0; > > Isn't this last line pointless? The if condition is !s->hw.century, > and hence s->hw.century must be 0 here? Oh, yes - insufficient pruning after the v2 adjustments. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:21:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:21:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405424.1638918 (Exim 4.92) (envelope-from ) id 1x1hA7-0006ZB-Lm; Wed, 02 Sep 2026 09:21:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405424.1638918; Wed, 02 Sep 2026 09:21:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hA7-0006Z4-J2; Wed, 02 Sep 2026 09:21:43 +0000 Received: by outflank-mailman (input) for mailman id 1405424; Wed, 02 Sep 2026 09:21:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1hA6-0006Yw-9F for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:21:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hA5-00AwsE-Lm for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:21:41 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97ea9f-e002-0a2a0a5209dd-0a2a450484a0-18 for ; Wed, 02 Sep 2026 11:21:41 +0200 Received: from [209.85.208.169] (helo=mail-lj1-f169.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97eaa4-b57f-0a2a45040019-d155d0a9c5d9-3 for ; Wed, 02 Sep 2026 11:21:41 +0200 Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-3a20c95e412so6427411fa.1 for ; Wed, 02 Sep 2026 02:21:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1788340900; cv=none; d=google.com; s=arc-20260327; b=pXjGMV1/RqlFgvmr51lBqifNyFvIoTK2vDmeXQ1Jujp7zgxxBSG5wxnxxJcyu1Lp5V ysUN+t9/I47D4fApqJiGpTWp06yOpnQsQu34er5XrBm5zYVqoSxFKj22NQhIVrefzmyD IESs7H2CxObLXsFhMJitv4EtjmGta0uQYSonQ001ymsd0KyChcE/pIlmkhZqEmAFAyFT Kj0CU3RURM6TYRVlTDoK7ywqJV8lP4hCmjQPcdOoQPbPiWpPSkYCaLJTAeKeQ53efObg Q4LdwROsZ0xkqoImSBl5y/q64npZzyqeyFTNz9hdXwqeMne3FABqsxxBg1MqLBQBJCW+ 1+JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Dhvza8kPq0AnEA5RvXgsB0bdJcKfrT+lnBY2gLJYn9k=; fh=LhgQUaOwSOLlXE5Y0oINkZGpKai4VDvBPfv+3S/YceQ=; b=NcNSpU8cIBKo4kjaVLrgvNrDUslZU7K2DkVug/oJCLH9sulGx+RoxDdpkh8quGniwe GNeULuPc6yLaCUrjtgk/njNAgELBJsN+0DjeTYd318uuZxDmOHHylmJe5Na2a87/UjW1 GCUX0G5N7Ter+DoxEpd2EzTNAW0ARXRoNAPQw/S/zRZ3LeYIA8VaVsarCs2iUZIV9yhj WBzMFOY4ZTbDNoN8gFLoUpynljgF8arOuXZU6WKrbdJEfsMaiMNMAlwFzdXBF0FHvNE9 oEG8hI4IWyMNjfutJ4pOHrF/UM/dVna6W6Pezj9FhhtjRuuabokiohi94MkHzQuuuOwU Sryg==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788340900; x=1788945700; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Dhvza8kPq0AnEA5RvXgsB0bdJcKfrT+lnBY2gLJYn9k=; b=MocR1tjUSVjefrUEdAOLBs4cDPPCwW2ti/6mv9alaqqFbsMzzvdWbLCib47SsKLWLV qNJ3SYSFk13J3fqVCjvTq+TYwzmYyC37qxLRyppGYWNNkx/h4/Is+oDpmq1WN5/lxCvc DOxOgL5eOHOZxWkfBgwSjpxvuZFVfvmuiM1c3WC87G2DvUNdfLJFaAmyXTbBvVut004q n0gKfntCEA0RYGV/t9EzjbWWYbCGfjEIi9YRRIYs5Y/G1EtNFPj17/CaZ967o5zfF8ie LBCP+zY/lAZvXyceWKNrWE6x9A+Imi5Y/q1gzywQzS7pT1oPh8ono6Y1pHXUjjoq/Cw4 PtNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788340900; x=1788945700; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Dhvza8kPq0AnEA5RvXgsB0bdJcKfrT+lnBY2gLJYn9k=; b=MyvwtLXFpAcZSnyETO3lew8EIKf4LYT1t5or6oyWLwjh0cuGAAIhMjIvp6IaDQsdr4 nY5vYgnKNt2/e1yUeqj97FfZ5Qhi4ZmV2I2tdLgR2vI/ftmtPEYXJy2kQRUBhetijmvp Je4BX+1/0MjoCPbXccrJXznjL5sHCbeRQ27MUXcERz+j0zWAHqpdtBZSfPRpy1oUH/Sk /egJdrrdQ7A/yAXTAPwiJ5Ttnrvxl8IWtKILqrtqPwgZ1thXAs0+Kpt/5mdDmECJj0+B DwWVnmlpeZ0lgG5ze6GXN8i3M61Vv7k2Od3B60SySnBB82dXjVOsnizQKCVZee5pQTk2 Y89Q== X-Gm-Message-State: AFuF++ngvnb8j6s7uKywetXzgEwn76Cno04pesLXRJnBz2+Iyc5aH/rs hfF69gRlUNt7jLQch0Lxtk/FzHelriL2daqJqPnwmLP+F/cMdNtR+9/lHOQ4PgJv+ErnLoDOI7g /5F9RzHI6p7BJzutE55f/JtwUk34TiPc= X-Gm-Gg: AYBFou3mqt2H8UrUb1C2lfoBKljPk17n/+MrcgA+jld6Oa0xsx17kd4QFwwQPXnRYQa 7Z1m9BxZZi0u1ACw1JEp3yFZoqrIU6SdjOkXm30vTIyrl71upnmCLSLVLq6gTQ8wrVTX2djuTzK 12i+clFi0CRwrOx+80A880TKWGatqKSPEyIqhlnmxanAiwfuTU9IN1wKYTLZZGat+LBIiDpjDcl 4OoUwNhYep6wrAdkasfG2ItdkcTksDuk3ccC3455/BWDVIkizVlgTCagcr239Fy6W+CrfHER+RE MLN6+MrGXog4MqnvmGDb0kqJlUdhLnbTviFQITG2 X-Received: by 2002:a2e:bc0d:0:b0:3a3:5bd:8b7c with SMTP id 38308e7fff4ca-3a350248896mr7199701fa.14.1788340900168; Wed, 02 Sep 2026 02:21:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mykola Kvach Date: Wed, 2 Sep 2026 12:21:29 +0300 X-Gm-Features: AcwNN1WNL3qgoEtWTARb9tQH--Fm_Z63l71Fu7m4-B85oYLYh1xWdBlujApJXcI Message-ID: Subject: Re: Xen 4.23 planning: items for the release To: Oleksii Kurochko Cc: Xen-devel , Community Manager , "committers@xenproject.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ebf023/1788340901-528C9B50-0430726D/10/73395122804 X-purgate-type: spam X-purgate-size: 511 Hi Oleksii, On Tue, Sep 1, 2026 at 7:06=E2=80=AFPM Oleksii Kurochko wrote: > > Hi all, > > As we are starting to plan for Xen 4.23, what items are you planning to > work on during this release? Please also add the following Arm item: Xen Suspend-to-RAM support on Arm64: https://lore.kernel.org/xen-devel/cover.1787838455.git.mykola_kvach@epam.co= m The plan is to continue the work on host Suspend-to-RAM support using PSCI SYSTEM_SUSPEND. Thanks, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:31:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:31:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405433.1638929 (Exim 4.92) (envelope-from ) id 1x1hJG-0008Md-H5; Wed, 02 Sep 2026 09:31:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405433.1638929; Wed, 02 Sep 2026 09:31:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hJG-0008MV-DH; Wed, 02 Sep 2026 09:31:10 +0000 Received: by outflank-mailman (input) for mailman id 1405433; Wed, 02 Sep 2026 09:31:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hJF-0008MP-DW for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:31:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hJE-003WvT-9v for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:31:08 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97ecd4-bab6-0a2a0a5309dd-0a2a450ab490-26 for ; Wed, 02 Sep 2026 11:31:08 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97ecdc-f2d2-0a2a450a0019-d155dd30c1e7-3 for ; Wed, 02 Sep 2026 11:31:08 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-47fe89fb333so516577f8f.3 for ; Wed, 02 Sep 2026 02:31:08 -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 ffacd0b85a97d-48448ee9cf7sm5369269f8f.25.2026.09.02.02.31.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 02:31:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788341467; x=1788946267; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=2TIbS1LnBwmiA0UE5OsQTmFbDfQo6/nTKpkl8KS1tRM=; b=B9GA3XaKXHunrAAuuLtkxdzPndF9G3H+iMlGmi95Bs6vG+QR+tYdKzzCp11FyPN/C6 zhtAXg4Y1F/hUXLLqfXcV3yQuY/03kbaXkm6X0fca+ONcn7jkL0GGevLnwUb6FJWow/m i4HOWS2BbxSRoKfKUzhjKgz7XcaZ55tnisM6rgfghQRZnOn92eMHEA335slqhwZ+r5+L otjOgPf5daY18p1KOpSk9wN2om1BhOXtlJ5lJaTjqmNr0O1vHbks1Fh2YKHO1dKwlEwH /xFa5cppXgNCbwhWqqNd82vmsEb8hIyr/JLlprS9RWUWNFEFC3RvpvdSI6+KfpqgRdW9 BptA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788341467; x=1788946267; h=content-transfer-encoding:content-type: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:content-type; bh=2TIbS1LnBwmiA0UE5OsQTmFbDfQo6/nTKpkl8KS1tRM=; b=eE2X8k5qL+Sdxg4Z2odRi5Pxaob/9P8TjcX4AZ+hFGO8uEhektzg97THpneiWUO3R9 sExFjwLq/STpxuePWCv2NDbzKlBeiaYOppkK0X3051j0eg1PcvxEd5HKivVyEPX6kqdM B9eWI90vn6a9TDpvEPlDbEPINAwWuL4MpxoAOJnYHvJpiD9uMYw1aKX9MKj7AJ19j3dn LfJMPylgoL0p44wN0S4KXpzx6DsGnqiWbHEQwbQHooaJ6lEiDHLxFvM5Ph2rpCYFc9h8 NqXregBeiMrQ8TYE7KaW73MDvzhb03wwXR2dSU/4kSVVIjRV11zBJM1/z5HQ4uTTaKuo XjEg== X-Gm-Message-State: AFuF++l3JdMTWKTPhWsp/trFUE+AbiXS/Ocefenp3cKqkUb6SXoeOijJ m0vtru4mRbJW/AbX97ZebUK1xUxt0+yTmcyhJZCDAfnIfHMrIuecg97arOt4u99rUgyl1OFzdXn Umg7RWA== X-Gm-Gg: AYBFou0Nz4DBUtyPBGK8w7rU+i3a5hKoj6c/EKx88hws0HjF9e4LjmsEo5pwIKr+lK6 HcsjWuBKOrUNtNxMvwMG8UhYpZ2GihQcVa3xq7C46IzckXJUQvUwLqMDusPPgNvbegVaDvLWZkq 25ArkVKZ5l3XizElRYXcwNLR33ofP/QSsrCu9ElG/0KkoYwpdtU6t1MGHYycETGyXnzKZv0tM2V vwVJdJM5ufMHB+XCTlefEouGhT2KPzHp6PJXakKCFLICh8x0+d/c7DPkrco2hwxJnb0kgRJE3g4 OCUY6+b2SsI4sg1nNJENFKnH1q3QW3wESYIJp3bNB5OY9xdztsz1YCICc/KA0u7fLRTrgFIbViX sxsuyMowwgH92oYQNEOliUbUxNpJPZPPZr23w+3BUkH9KOYBg9N2jpxYEEYoG0F48GNP/N5wl8L 6A+B+NbXcPl51ylBe9e6hlvSi6RYYFv3gyDm7yQtPmyNx58cPcM2hzrC8+Rs1/DFutO1TtAzy9J SyUdxgfwnHrHyfQ/lid6zBUgJRiHDpdXRzUGdtXb7SRFVWWxrIN X-Received: by 2002:a05:6000:4a0a:b0:484:39b4:5bc9 with SMTP id ffacd0b85a97d-484914cba9amr5683036f8f.26.1788341467515; Wed, 02 Sep 2026 02:31:07 -0700 (PDT) Message-ID: <35013b66-0886-4793-8cb6-3056f6f99a3a@suse.com> Date: Wed, 2 Sep 2026 11:31:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] x86/time: avoid early uses of NOW() to return zero To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <1047fb1f-87a3-46b9-ad91-904b05d8a637@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: 8bit X-purgate-ID: tlsNG-4011c0/1788341468-51AC4CFC-3A152B73/0/0 X-purgate-type: clean X-purgate-size: 2329 On 02.09.2026 11:15, Roger Pau Monné wrote: > On Wed, Sep 02, 2026 at 10:40:04AM +0200, Jan Beulich wrote: >> On 02.09.2026 09:54, Roger Pau Monné wrote: >>> On Wed, Aug 19, 2026 at 01:45:56PM +0200, Jan Beulich wrote: >>>> --- a/xen/arch/x86/time.c >>>> +++ b/xen/arch/x86/time.c >>>> @@ -1664,6 +1664,9 @@ s_time_t get_s_time_fixed(uint64_t at_ts >>>> const struct cpu_time *t = &this_cpu(cpu_time); >>>> uint64_t tsc, delta; >>>> >>>> + /* scale_delta() degenerates when the scale wasn't set yet. */ >>>> + ASSERT(t->tsc_scale.mul_frac); >>>> + >>>> if ( at_tsc ) >>>> tsc = at_tsc; >>>> else >>>> @@ -1679,6 +1682,20 @@ s_time_t get_s_time_fixed(uint64_t at_ts >>>> >>>> s_time_t get_s_time(void) >>>> { >>>> + /* >>>> + * Before the TSC scale is set, avoid returning constant 0 (or whatever >>>> + * this_cpu(cpu_time).stamp.local_stime is set to). While the returned >>>> + * value is in no way representing time, it at least increases >>>> + * monotonically, thus avoiding e.g. waiting loops to degenerate to >>>> + * entirely infinite ones. >>>> + */ >>>> + if ( unlikely(!this_cpu(cpu_time).tsc_scale.mul_frac) ) >>>> + { >>>> + static s_time_t counter; >>> >>> Not that it matters much, but counter can probably be __initdata? >> >> I wanted to play safe here: In get_s_time_fixed(), release builds won't >> crash if the assertion wasn't there, but would trigger in a >> corresponding debug build. In that (unexpected) situation, we'd crash >> here (when .init.* was unmapped) if __initdata was used. > > That's kind of what I was aiming at: we possibly do want to crash hard > if Xen is still using the fake counter after initialization? Nothing > good can come out of running guests without the TSC scaling being set, > as the PV clock exposed won't be functional either. Likely resulting > in guests relying on it also getting stuck because mul_frac == 0? Crashing because of too late an .init.data access may require more analysis than necessary though. I.e. if that was really the intention, I think it should be a BUG_ON(), and I further think I'd prefer to leave this to a separate patch (which I would likely ack, but which I'm not sure I would be willing to write). Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405457.1638971 (Exim 4.92) (envelope-from ) id 1x1hVq-0002oR-6A; Wed, 02 Sep 2026 09:44:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405457.1638971; Wed, 02 Sep 2026 09:44:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVq-0002mL-0K; Wed, 02 Sep 2026 09:44:10 +0000 Received: by outflank-mailman (input) for mailman id 1405457; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVn-0002GC-Nm for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hVm-00G2eL-JM for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97efd9-2eae-0a2a0a5409dd-0a2a45069e4a-38 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-195a-0a2a45060019-d99ba50cefa3-3 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 5715E36928EB; Wed, 2 Sep 2026 10:44:06 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Alejandro Vallejo , George Dunlap Subject: [PATCH v2 08/14] x86/mm: purge unneeded destroy_perdomain_mapping() Date: Wed, 2 Sep 2026 10:43:52 +0100 Message-ID: <20260901-asi-part2-8-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1788342246-FD60A77B-C10AA290/0/0 X-purgate-type: clean X-purgate-size: 2524 From: Roger Pau Monné We want to change per-domain mappings to be per-vCPU mappings. In preparation for that, we want to arrange that destroy_perdomain_mapping() work either with a single perdomain area, or with a per-vCPU perdomain area. There are two calls made from domain-scoped contexts; both calls turn out to be unnecessary: - destroy_perdomain_mapping() is not logically the undo of create_perdomain_mapping(), as the name and its use in hvm_domain_initialise() suggest. create_ allocates a per-domain L3, but destroy_ tears down mappings without freeing it; and since the call here passes nr == 0, it tears down nothing at all. The per-domain L3 page is actually freed by free_perdomain_mappings(), which hvm_domain_initialise()'s caller, arch_domain_create(), already invokes on its failure path. - The call in pv_domain_destroy() is redundant: arch_domain_destroy() unconditionally calls free_perdomain_mappings(), which tears down the same entries and additionally frees the page-table structures. Signed-off-by: Roger Pau Monné Reviewed-by: Alejandro Vallejo Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Changes in v2: - Added to the series Changes since the previously posted version: - Reworked the commit message to make it more clear how it fits in with the larger series. No functional change. --- xen/arch/x86/hvm/hvm.c | 1 - xen/arch/x86/pv/domain.c | 3 --- 2 files changed, 4 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index a6e0818468..cd425c3342 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -730,7 +730,6 @@ int hvm_domain_initialise(struct domain *d, XFREE(d->arch.hvm.irq); fail0: hvm_destroy_cacheattr_region_list(d); - destroy_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0); fail: hvm_domain_relinquish_resources(d); XFREE(d->arch.hvm.io_handler); diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index 15a8238aff..b936ca9b26 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -383,9 +383,6 @@ void pv_domain_destroy(struct domain *d) { pv_l1tf_domain_destroy(d); - destroy_perdomain_mapping(d, GDT_LDT_VIRT_START, - GDT_LDT_MBYTES << (20 - PAGE_SHIFT)); - XFREE(d->arch.pv.cpuidmasks); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405455.1638958 (Exim 4.92) (envelope-from ) id 1x1hVp-0002dC-Jf; Wed, 02 Sep 2026 09:44:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405455.1638958; Wed, 02 Sep 2026 09:44:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVp-0002c0-Dx; Wed, 02 Sep 2026 09:44:09 +0000 Received: by outflank-mailman (input) for mailman id 1405455; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVn-0002GD-FQ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hVm-00G2d4-Kq for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97efdb-bab6-0a2a0a5309dd-0a2a4508bd48-34 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-c1860d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe5-f659-0a2a45080019-d99ba50ce6fa-1 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 9FFCE36928DD; Wed, 2 Sep 2026 10:44:05 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 04/14] x86/pv: set/clear guest GDT mappings using populate_perdomain_mapping() Date: Wed, 2 Sep 2026 10:43:48 +0100 Message-ID: <20260901-asi-part2-4-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788342246-D674387B-B33CDC94/0/0 X-purgate-type: clean X-purgate-size: 6510 From: Roger Pau Monné Until the previous patch, update_xen_slot_in_full_gdt() used the stashed pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vCPU's page tables with Xen's GDT; this was previously necessary because map_domain_page() couldn't be called in a context switch. Having a handy pointer to an always-mapped version of the GDT/LDT L1 table, other sites which modify the table started using it for convenience, even if they weren't called from within a context switch. One example is pv_{set,destroy}_gdt(). The previous patch switched the main user of the stashed reference to use populate_perdomain_mapping() instead. Continue that process by switching both pv_{set,destroy}_gdt() to it as well. pv_destroy_gdt() currently loops over the L1 entries directly, extracting the MFN from each, dropping the type and reference unless it was the zero page, and replacing the entry with a read-only mapping of the zero page. Rather than reading from the stashed L1, drop the references using v->arch.pv.gdt_frames[] instead, and install the zero-page mappings with a single populate_perdomain_mapping() call. This makes gdt_frames[] consistently the source of truth for MFNs. Note that we must maintain the invariant introduced in cf6d39f819 ("x86/PV: properly populate descriptor tables"): pv_destroy_gdt() maps the zero page read-only in torn-down slots rather than unmapping them, so that LAR/LSL/VERR/VERW on a selector beyond the guest's limit clear ZF as on native rather than taking a #PF-converted #GP. (And since pv_set_gdt() tears down the old GDT before installing the new one, guests never see unmapped entries, only zero-page entries.) In the case of pv_set_gdt(), we have a slightly awkward situation with types. The ABI with the guest uses unsigned long[], but populate_perdomain_mapping() wants an array of mfn_t. v->arch.pv.gdt_frames being unsigned long means we can just copy from it across the guest ABI with no conversions. We could in theory convert it to mfn_t[] instead, and then pass v->arch.pv.gdt_frames into populate_perdomain_mapping(); but then we'd need to add a conversion on all the places where frames are copied out. We choose instead to copy frames into a temporary mfn_t array on the stack to pass into populate_perdomain_mapping(). Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Reword commit message Changes since the previously posted version: - Retain the gdt_ents zeroing when tearing down the GDT (its removal was queried by Jan). - Map torn-down slots read-only to the zero page (via the populate_perdomain_mapping() flags parameter) rather than removing the mappings with destroy_perdomain_mapping(): empty slots would be a guest-visible partial revert of cf6d39f819 (see the commit message). With the destroy call gone, its v->arch.cr3 guard -- also queried by Jan -- goes too: the zero-page rewrite runs unconditionally. - Keep gdt_frames[] as unsigned long[] rather than switching it to mfn_t[] as Jan suggested; the commit message explains the trade-off. - Retitle: destroy_perdomain_mapping() is no longer used here. --- xen/arch/x86/pv/descriptor-tables.c | 37 ++++++++++++++++++----------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c index 8a32b9ae5c..5dda5bffe3 100644 --- a/xen/arch/x86/pv/descriptor-tables.c +++ b/xen/arch/x86/pv/descriptor-tables.c @@ -49,33 +49,42 @@ bool pv_destroy_ldt(struct vcpu *v) void pv_destroy_gdt(struct vcpu *v) { - l1_pgentry_t *pl1e = pv_gdt_ptes(v); - mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page)); - l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO); + const mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page)); + mfn_t zero_mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)]; unsigned int i; ASSERT(v == current || !vcpu_cpu_dirty(v)); v->arch.pv.gdt_ents = 0; - for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ ) + + for ( i = 0; i < ARRAY_SIZE(zero_mfns); i++ ) { - mfn_t mfn = l1e_get_mfn(pl1e[i]); + zero_mfns[i] = zero_mfn; - if ( (l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) && - !mfn_eq(mfn, zero_mfn) ) - put_page_and_type(mfn_to_page(mfn)); + /* MFN 0 can never pass get_page_and_type(), so 0 marks unused slots. */ + if ( !v->arch.pv.gdt_frames[i] ) + continue; - l1e_write(&pl1e[i], zero_l1e); + put_page_and_type(mfn_to_page(_mfn(v->arch.pv.gdt_frames[i]))); v->arch.pv.gdt_frames[i] = 0; } + + /* + * Point every slot at the zero page, read-only: a descriptor fetch from + * the unused part of the GDT then finds a not-present descriptor rather + * than a missing mapping, so LAR/LSL/VERR/VERW on a selector beyond the + * guest's limit clear ZF as they do on native, instead of faulting. + */ + populate_perdomain_mapping(v, GDT_VIRT_START(v), zero_mfns, + ARRAY_SIZE(zero_mfns), __PAGE_HYPERVISOR_RO); } int pv_set_gdt(struct vcpu *v, const unsigned long frames[], unsigned int entries) { struct domain *d = v->domain; - l1_pgentry_t *pl1e; unsigned int i, nr_frames = DIV_ROUND_UP(entries, 512); + mfn_t mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)]; ASSERT(v == current || !vcpu_cpu_dirty(v)); @@ -90,6 +99,8 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[], if ( !mfn_valid(mfn) || !get_page_and_type(mfn_to_page(mfn), d, PGT_seg_desc_page) ) goto fail; + + mfns[i] = mfn; } /* Tear down the old GDT. */ @@ -97,12 +108,10 @@ int pv_set_gdt(struct vcpu *v, const unsigned long frames[], /* Install the new GDT. */ v->arch.pv.gdt_ents = entries; - pl1e = pv_gdt_ptes(v); for ( i = 0; i < nr_frames; i++ ) - { v->arch.pv.gdt_frames[i] = frames[i]; - l1e_write(&pl1e[i], l1e_from_pfn(frames[i], __PAGE_HYPERVISOR_RW)); - } + populate_perdomain_mapping(v, GDT_VIRT_START(v), mfns, nr_frames, + __PAGE_HYPERVISOR_RW); return 0; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405451.1638938 (Exim 4.92) (envelope-from ) id 1x1hVn-0002Gl-Qa; Wed, 02 Sep 2026 09:44:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405451.1638938; Wed, 02 Sep 2026 09:44:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVn-0002GZ-K8; Wed, 02 Sep 2026 09:44:07 +0000 Received: by outflank-mailman (input) for mailman id 1405451; Wed, 02 Sep 2026 09:44:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVm-0002G3-H2 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:44:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hVl-0093D7-Tt for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:44:05 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97efdf-8faa-0a2a0a5109dd-0a2a450abd98-22 for ; Wed, 02 Sep 2026 11:44:05 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-4011c0.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe5-f2d2-0a2a450a0019-d99ba50cf8dc-1 for ; Wed, 02 Sep 2026 11:44:05 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 6D33F36928D6; Wed, 2 Sep 2026 10:44:05 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: George Dunlap , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v2 00/14] x86: Address Space Isolation, part 2: asi= option and per-vCPU page tables Date: Wed, 2 Sep 2026 10:43:44 +0100 Message-ID: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1788342245-59DDFCFC-AC52A507/0/0 X-purgate-type: clean X-purgate-size: 6366 From: George Dunlap This is the second batch of the x86 Address Space Isolation (ASI) series, run as a rolling series as laid out in part 1 [3]: patches are posted from the front as they are ready, dropped once committed, and appended as they mature. None of part 1 has been committed yet, so this posting contains v2 of those seven patches, revised per review, followed by seven new ones. The original work was posted by Roger as "x86: adventures in Address Space Isolation" (v1 [1], v2 [2]). The map of the entire series -- grouped into logical chunks, with the dependencies between patches -- is maintained here: https://xenbits.xenproject.org/people/gdunlap/asi-series-deps.html Patches 1-14 of this posting are d03-d16 on that map. (d01 is Jan's independently posted "x86: always park offline CPUs", which nothing in this posting depends on; d02 is the design document, which isn't ready for publication yet.) What this batch does: - Patches 1-7 are the part 1 content: give the per-domain area a single central writer for installing caller-owned pages (populate_perdomain_mapping()), convert the PV GDT/LDT paths to it, and remove the stashed L1 aliases that bypassed the interface. The headline change since part 1, following Jan's review of the xenheap allocation patch: the per-domain page-tables stay in the domheap, and the contexts that must walk them with interrupts disabled get dedicated IRQs-off mapping variants (patch 1) rather than an always-mapped alias. Per-patch changes are noted below each patch's "---". - Patches 8-11 prepare the perdomain interfaces ({create,destroy}_perdomain_mapping() and their callers) to work with either a single domain-wide perdomain area or a per-vCPU one. - Patch 12 introduces the asi= command line option ahead of the functionality it enables, so the newly added code can be keyed on it from the start. All knobs default to off, and enabling any of them warns at boot that the feature is not functional and intended for development only. - Patch 13 pairs the maintenance of the XPTI per-domain slot in the per-CPU root page-table: installed on switch-in, now cleared on switch-out. - Patch 14 is the core of this phase: an optional per-vCPU L3 for the per-domain area, so that what a vCPU can reach through the per-domain slot is its own state rather than every vCPU's. With this patch HVM guests can run with per-vCPU page-tables; for PV guests the rest of the machinery (per-vCPU mapcache, root page-table handling, and a per-vCPU L4) follows in the next batch. Testing: - Applies cleanly to staging at the base commit below; each patch builds (x86_64, CONFIG_DEBUG=y). - arm64 build and tier-1 qemu boot at the tip (patch 1 touches the common domain_page.h). - x86 tier-1 qemu boots at the tip: default; asi=1 with a 1-vCPU dom0 (SMP PV vCPU-PT arrives later in the series); and xpti=1 forced, exercising the new switch-out clear on every context switch. - The series passes the Xen GitLab CI pipeline, including the hardware runners: https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2809749496 - On an Intel NUC (debug build), three configurations -- default, xpti=1 forced, and asi=1 with a 1-vCPU dom0 and UP guests: XTF pv64 + pv32pae suites (29 pass / 2 skip in each; pv32pae via cet=no-shstk,no-ibt pv=32), plus an LDT exerciser in a PV Linux guest, sequential, parallel, and under vcpu-pin churn -- no assertions, crashes, or "unable to map" reports. The xpti=1 run exercises patch 13's switch-out clear on every context switch; SMP PV guests were excluded from the asi=1 run (not expected to work until the per-vCPU L4 patch). [1] https://lore.kernel.org/xen-devel/20240726152206.28411-1-roger.pau@citrix.com/ [2] https://lore.kernel.org/xen-devel/20250108142659.99490-1-roger.pau@citrix.com/ [3] https://lore.kernel.org/xen-devel/20260820-asi-part1-0-f2dbd92b8459@xenproject.org/ George Dunlap (2): x86/domain_page: introduce IRQs-off variants of {,un}map_domain_page() x86/pv: clear the XPTI root_pgt per-domain slot on context-switch out Roger Pau Monné (12): x86/mm: introduce populate_perdomain_mapping() x86/pv: use populate_perdomain_mapping() to map the Xen GDT x86/pv: set/clear guest GDT mappings using populate_perdomain_mapping() x86/pv: update guest LDT mappings using {populate,destroy}_perdomain_mapping() x86/pv: remove stashing of GDT/LDT L1 page-tables x86/mm: simplify create_perdomain_mapping() interface x86/mm: purge unneeded destroy_perdomain_mapping() x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas x86/domain_page: drop redundant create_perdomain_mapping() call x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas x86/spec-ctrl: introduce Address Space Isolation command line option x86/mm: introduce per-vCPU L3 page-table docs/misc/xen-command-line.pandoc | 24 +++ xen/arch/x86/domain.c | 53 ++++- xen/arch/x86/domain_page.c | 72 +++++-- xen/arch/x86/hvm/hvm.c | 6 - xen/arch/x86/include/asm/desc.h | 2 - xen/arch/x86/include/asm/domain.h | 28 ++- xen/arch/x86/include/asm/mm.h | 16 +- xen/arch/x86/include/asm/spec_ctrl.h | 2 + xen/arch/x86/mm.c | 296 +++++++++++++++++++++------ xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/paging.c | 14 ++ xen/arch/x86/mm/shadow/common.c | 11 + xen/arch/x86/mm/shadow/hvm.c | 2 +- xen/arch/x86/mm/shadow/multi.c | 2 +- xen/arch/x86/pv/descriptor-tables.c | 57 +++--- xen/arch/x86/pv/dom0_build.c | 8 +- xen/arch/x86/pv/domain.c | 26 +-- xen/arch/x86/pv/mm.c | 16 +- xen/arch/x86/smpboot.c | 15 -- xen/arch/x86/spec_ctrl.c | 107 +++++++++- xen/arch/x86/traps.c | 2 - xen/arch/x86/x86_64/mm.c | 7 +- xen/include/xen/domain_page.h | 14 ++ 23 files changed, 594 insertions(+), 188 deletions(-) base-commit: 2565341135f88081535f6830a6256277e2834403 -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405456.1638968 (Exim 4.92) (envelope-from ) id 1x1hVq-0002jO-04; Wed, 02 Sep 2026 09:44:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405456.1638968; Wed, 02 Sep 2026 09:44:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVp-0002h2-ON; Wed, 02 Sep 2026 09:44:09 +0000 Received: by outflank-mailman (input) for mailman id 1405456; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVn-0002GM-JK for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hVm-00G2d4-QD for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97efe3-bab6-0a2a0a5309dd-0a2a450ba8c2-8 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-42698a.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe5-b7e8-0a2a450b0019-d99ba50cf2f6-1 for ; Wed, 02 Sep 2026 11:44:05 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 7CC1836928DB; Wed, 2 Sep 2026 10:44:05 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT Date: Wed, 2 Sep 2026 10:43:47 +0100 Message-ID: <20260901-asi-part2-3-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1788342245-ABAD09EA-76AC3068/0/0 X-purgate-type: clean X-purgate-size: 6038 From: Roger Pau Monné Currently, update_xen_slot_in_full_gdt() uses the stashed direct-map pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vcpu's page tables with Xen's GDT, by writing a stashed per-cpu copy of a pre-baked L1 entry (either 64-bit or compat version). Switch this to using populate_perdomain_mapping(), which doesn't rely on the stashed address of the l1 page in the direct map. Rather than also stashing a pre-baked value for the payload, compute the mfn from the per-cpu GDT pointer at use: the conversion is a handful of cycles on a path costing thousands, and computing at use removes the parallel {,compat_}gdt_l1e bookkeeping along with its boot-ordering constraint (the cached value could only be generated after Xen's physical relocation, and had to be in place before the first context switch; a use-time lookup is correct by construction). The flags on the final mapping are identical. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Drop the {,compat_}gdt_mfn caching entirely (suggested by Andrew Cooper): compute virt_to_mfn() from the per-cpu GDT pointer at use. The PDX lookup behind it measures ~5-10 cycles warm against a ~1,500-cycle context switch, and this removes the double bookkeeping and the after-relocation caching constraint. The cached-MFN assertion goes with the cache: a use-time computation from a live pointer needs no staleness check. Changes since the previously posted version: - populate_perdomain_mapping() introduction split into the previous patch; this patch is now just the Xen GDT conversion. - Retain the "GDT MFN cached" check as ASSERT(mfn_x(mfn)). --- xen/arch/x86/domain.c | 13 ++++++++----- xen/arch/x86/include/asm/desc.h | 2 -- xen/arch/x86/smpboot.c | 15 --------------- xen/arch/x86/traps.c | 2 -- 4 files changed, 8 insertions(+), 24 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 996b50af7a..d8af06e533 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2062,11 +2062,14 @@ static always_inline bool need_full_gdt(const struct domain *d) static void update_xen_slot_in_full_gdt(const struct vcpu *v, unsigned int cpu) { - ASSERT(per_cpu(gdt_l1e, cpu).l1); /* Confirm these have been cached. */ - - l1e_write(pv_gdt_ptes(v) + FIRST_RESERVED_GDT_PAGE, - !is_pv_32bit_vcpu(v) ? per_cpu(gdt_l1e, cpu) - : per_cpu(compat_gdt_l1e, cpu)); + mfn_t mfn = _mfn(virt_to_mfn(!is_pv_32bit_vcpu(v) + ? per_cpu(gdt, cpu) + : per_cpu(compat_gdt, cpu))); + + populate_perdomain_mapping(v, + GDT_VIRT_START(v) + + (FIRST_RESERVED_GDT_PAGE << PAGE_SHIFT), + &mfn, 1, __PAGE_HYPERVISOR_RW); } static void load_full_gdt(const struct vcpu *v, unsigned int cpu) diff --git a/xen/arch/x86/include/asm/desc.h b/xen/arch/x86/include/asm/desc.h index dcbdac3ff7..a860134211 100644 --- a/xen/arch/x86/include/asm/desc.h +++ b/xen/arch/x86/include/asm/desc.h @@ -136,10 +136,8 @@ struct __packed desc_ptr { extern seg_desc_t boot_gdt[]; DECLARE_PER_CPU(seg_desc_t *, gdt); -DECLARE_PER_CPU(l1_pgentry_t, gdt_l1e); extern seg_desc_t boot_compat_gdt[]; DECLARE_PER_CPU(seg_desc_t *, compat_gdt); -DECLARE_PER_CPU(l1_pgentry_t, compat_gdt_l1e); DECLARE_PER_CPU(bool, full_gdt_loaded); static inline void lgdt(const struct desc_ptr *gdtr) diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c index 84e9e4beed..9b837a1769 100644 --- a/xen/arch/x86/smpboot.c +++ b/xen/arch/x86/smpboot.c @@ -1085,8 +1085,6 @@ static int cpu_smpboot_alloc(unsigned int cpu) if ( gdt == NULL ) goto out; per_cpu(gdt, cpu) = gdt; - per_cpu(gdt_l1e, cpu) = - l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW); memcpy(gdt, boot_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE); BUILD_BUG_ON(NR_CPUS > 0x10000); gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a = cpu; @@ -1095,8 +1093,6 @@ static int cpu_smpboot_alloc(unsigned int cpu) per_cpu(compat_gdt, cpu) = gdt = alloc_xenheap_pages(0, memflags); if ( gdt == NULL ) goto out; - per_cpu(compat_gdt_l1e, cpu) = - l1e_from_pfn(virt_to_mfn(gdt), __PAGE_HYPERVISOR_RW); memcpy(gdt, boot_compat_gdt, NR_RESERVED_GDT_PAGES * PAGE_SIZE); gdt[PER_CPU_GDT_ENTRY - FIRST_RESERVED_GDT_ENTRY].a = cpu; #endif @@ -1173,17 +1169,6 @@ void __init smp_prepare_cpus(void) initialize_cpu_data(0); /* Final full version of the data */ print_cpu_info(0); - /* - * Cache {,compat_}gdt_l1e for the BSP now that physically relocation is - * done. It must be after physical relocation of Xen, and before the - * first context_switch(). - */ - this_cpu(gdt_l1e) = - l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW); - if ( IS_ENABLED(CONFIG_PV32) ) - this_cpu(compat_gdt_l1e) = - l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_RW); - boot_cpu_physical_apicid = get_apic_id(); x86_cpu_to_apicid[0] = boot_cpu_physical_apicid; diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 1774966305..2ab61db167 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -71,10 +71,8 @@ DEFINE_PER_CPU(uint64_t, efer); static DEFINE_PER_CPU(unsigned long, last_extable_addr); DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, gdt); -DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, gdt_l1e); #ifdef CONFIG_PV32 DEFINE_PER_CPU_READ_MOSTLY(seg_desc_t *, compat_gdt); -DEFINE_PER_CPU_READ_MOSTLY(l1_pgentry_t, compat_gdt_l1e); #endif /* -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405454.1638956 (Exim 4.92) (envelope-from ) id 1x1hVp-0002Xi-Hc; Wed, 02 Sep 2026 09:44:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405454.1638956; Wed, 02 Sep 2026 09:44:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVp-0002Wc-7P; Wed, 02 Sep 2026 09:44:09 +0000 Received: by outflank-mailman (input) for mailman id 1405454; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVn-0002G9-Dw for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hVm-00G2d4-AD for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97efdb-bab6-0a2a0a5309dd-0a2a4508bd48-32 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-c1860d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe5-f659-0a2a45080019-d99ba50cf561-1 for ; Wed, 02 Sep 2026 11:44:05 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 6DB8836928D7; Wed, 2 Sep 2026 10:44:05 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 02/14] x86/mm: introduce populate_perdomain_mapping() Date: Wed, 2 Sep 2026 10:43:46 +0100 Message-ID: <20260901-asi-part2-2-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788342245-CD74B87B-3EFE3426/0/0 X-purgate-type: clean X-purgate-size: 12066 From: Roger Pau Monné The per-domain area already has central machinery for building its page-tables and for managing the backing pages it owns itself: create_perdomain_mapping() / destroy_perdomain_mapping(), used by the mapcache bitmaps, the compat argument-translation area, and the GDT/LDT slots alike. What the interface lacks is a way to install a caller's own pages at a chosen address. The PV GDT and LDT code open-codes its own modifications to the per-domain area, capturing aliases of its L1 tables at creation time (create_perdomain_mapping()'s pl1tab argument) and stashing them in d->arch.pv.gdt_ldt_l1tab. Introduce populate_perdomain_mapping(v, va, mfn, nr, flags) to close this gap, giving the perdomain area's rules a single place to live. populate_perdomain_mapping writes the given MFNs, with the given page-table flags, into v's view of the per-domain area: through the recursive linear mappings when v's page-tables are loaded on the current pCPU, or by walking the per-domain page-table structures otherwise. Callers don't need to know where the page-tables live, how the area is structured, or whether it is per-domain or per-vcpu. The fast path is keyed off this_cpu(pgtable_vcpu) rather than current: following 622c9a5ba95d ("x86/mm: accurately track which vCPU page-tables are loaded") that's the accurate way to tell whether the linear mappings reach v's per-domain area, and it copes with the transient states where current doesn't match the loaded page-tables (e.g. the _toggle_guest_pt() error window, or mid context switch). It also removes any need to call sync_local_execstate(): when the vCPU's page-tables aren't loaded, the walk instead maps the per-domain page-table pages with the map_domain_page_irqoff() variants, holding interrupts off for its duration, and so is usable from any context -- including the context switch, before the incoming vcpu's page-tables are loaded. We require the range to already have been populated down to the L1 tables by create_perdomain_mapping(). TLB flushing is left to the caller. A present entry not owned by the area (!_PAGE_AVAIL0) is replaced. A present entry owned by the area (_PAGE_AVAIL0, installed by create_perdomain_mapping() itself) is freed and replaced: such a page is referenced only by the mapping, so displacing it without freeing it would leak it. Nothing in this series replaces area-owned backing, so the free is marked ASSERT_UNREACHABLE(); note that freeing requires a context where the allocator may be entered -- IRQs enabled, not in interrupt context (see ASSERT_ALLOC_CONTEXT()) -- so any future caller replacing area-owned backing must not do so from the context switch path, nor anywhere the slow-path walk (which holds IRQs off) can be taken. Missing page-table structure is a hypervisor bug and BUG_ON(): there is no safe continuation, least of all from the context switch, where the next descriptor fetch through an unmapped GDT slot would be fatal. Subsequent patches convert the users of the stashed L1 tables to this interface, starting with the Xen slots of the full GDT; the stash -- which could in any case not represent per-vcpu mappings without being replicated for every vcpu and slot -- is then removed, leaving create_perdomain_mapping() to manage only the page-table structure and the pages the area owns itself. Later parts of the series use the new interface for their own mappings rather than adding further mechanisms. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Drop the xenheap allocation of the per-domain page-tables (v1's patch 1); the walk instead maps the page-table pages with the new map_domain_page_irqoff() variants, holding interrupts off for the duration. - Re-introduce the linear-map fast path for when the target vCPU's page-tables are loaded on the current pCPU, now keyed off this_cpu(pgtable_vcpu). Changes since the previously posted version: - Split the introduction of populate_perdomain_mapping() from its first user (previously one patch: "x86/pv: introduce function to populate perdomain area and use it to map Xen GDT"). - Drop the linear-map fast path and the sync_local_execstate() call: with the per-domain page-tables in the xenheap (previous patch) the walk needs no mapping, so a single path serves all callers and contexts. - Keep the ASSERT_UNREACHABLE() + free_domheap_page() handling of a replaced area-owned entry, and document the allocation-context requirement it places on callers replacing such entries. BUG_ON() missing page-table structure, instead of domain_crash(). - Take the page-table flags as a parameter (the Xen GDT and guest GDT slots want RW mappings; the zero page backing torn-down GDT slots is mapped read-only, as today). - Document the contract in a header comment. - Make the mfn parameter const and nr unsigned int, matching {create,destroy}_perdomain_mapping(). - Drop the unused cr3_mfn() helper. Considered, but not done to limit churn against the previously posted version: splitting the interface into a "populate" variant (any present entry is a bug) and an "update" variant (replacement expected), so that call sites declare their intent and unexpected collisions become detectable. Of the eventual call sites in the wider series, roughly half are of each kind. Could be done as a follow-up if there is interest. --- xen/arch/x86/include/asm/mm.h | 3 + xen/arch/x86/mm.c | 124 ++++++++++++++++++++++++++++++++++ 2 files changed, 127 insertions(+) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 2254a7e3fe..1888807394 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -606,6 +606,9 @@ int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); int create_perdomain_mapping(struct domain *d, unsigned long va, unsigned int nr, l1_pgentry_t **pl1tab, struct page_info **ppg); +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, + const mfn_t *mfn, unsigned int nr, + unsigned int flags); void destroy_perdomain_mapping(struct domain *d, unsigned long va, unsigned int nr); void free_perdomain_mappings(struct domain *d); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index b158742408..552559ecf1 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6334,6 +6334,130 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, return rc; } +/* + * Map @nr pages, @mfn[0..nr-1], at consecutive pages from @va in v's view of + * the per-domain area, with page-table @flags. The range must lie within a + * single per-domain slot, and must already have been plumbed down to the L1 + * tables by create_perdomain_mapping(): missing structure is a bug. A + * present entry not owned by the area (no _PAGE_AVAIL0) is silently + * replaced, as that is how callers update their mappings; a present + * area-owned entry is freed and replaced, which constrains the calling + * context (see the comment in the body). No TLB flushing is done: the + * caller decides whether the old translations can still be cached + * anywhere. + * + * When v's page-tables are loaded on this pCPU the L1 entries are reached + * through the recursive linear mappings; otherwise the walk maps the + * per-domain page-table pages transiently with IRQs off, so it needs + * nothing from the current address space and is usable from any context -- + * including the context switch, before the incoming vcpu's page-tables are + * loaded. + */ +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, + const mfn_t *mfn, unsigned int nr, + unsigned int flags) +{ + l1_pgentry_t *l1tab = NULL, *pl1e; + const l3_pgentry_t *l3tab; + const l2_pgentry_t *l2tab; + struct domain *d = v->domain; + unsigned long irq_flags; + + ASSERT(va >= PERDOMAIN_VIRT_START && + va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); + ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1))); + /* Area-owned pages are installed by create_perdomain_mapping() only. */ + ASSERT(!(flags & _PAGE_AVAIL0)); + + if ( likely(this_cpu(pgtable_vcpu) == v) ) + { + unsigned int i; + + /* + * Fast path: v's page-tables are loaded on this pCPU, so the L1 + * entries can be reached using the recursive linear mappings. + */ + pl1e = &__linear_l1_table[l1_linear_offset(va)]; + + for ( i = 0; i < nr; i++, pl1e++ ) + { + /* + * An area-owned entry (installed by create_perdomain_mapping(), + * marked _PAGE_AVAIL0) holds the only reference to its page, so + * displacing it means freeing it. Nothing in this series + * replaces area-owned backing, hence the ASSERT_UNREACHABLE(); + * any future caller doing so must run where freeing is + * permitted -- IRQs enabled, not in interrupt context (see + * ASSERT_ALLOC_CONTEXT()) -- which the context switch path is + * not. + */ + if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) ) + { + ASSERT_UNREACHABLE(); + free_domheap_page(l1e_get_page(*pl1e)); + } + l1e_write(pl1e, l1e_from_mfn(mfn[i], flags)); + } + + return; + } + + BUG_ON(!d->arch.perdomain_l3_pg); + + /* + * Slow path: walk v's per-domain page-table pages. All mappings are + * local to this function, so disabling interrupts for the duration of + * the walk satisfies the map_domain_page_irqoff() contract. This in + * turn makes this function usable from the context switch path, where + * a plain map_domain_page() could recurse into __context_switch() via + * sync_local_execstate(). + */ + local_irq_save(irq_flags); + + l3tab = __map_domain_page_irqoff(d->arch.perdomain_l3_pg); + + /* + * Missing page-table structure is a hypervisor bug: there is no safe + * continuation, least of all from the context switch, where the next + * descriptor fetch through an unmapped GDT slot would be fatal. + */ + BUG_ON(!(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT)); + + l2tab = map_domain_page_irqoff(l3e_get_mfn(l3tab[l3_table_offset(va)])); + + for ( ; nr--; va += PAGE_SIZE, mfn++ ) + { + if ( !l1tab || !l1_table_offset(va) ) + { + const l2_pgentry_t *pl2e = l2tab + l2_table_offset(va); + + BUG_ON(!(l2e_get_flags(*pl2e) & _PAGE_PRESENT)); + + unmap_domain_page_irqoff(l1tab); + l1tab = map_domain_page_irqoff(l2e_get_mfn(*pl2e)); + } + + pl1e = &l1tab[l1_table_offset(va)]; + + /* + * As the fast path -- and the slow path holds IRQs off throughout, + * so replacing area-owned backing here is never permitted. + */ + if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) ) + { + ASSERT_UNREACHABLE(); + free_domheap_page(l1e_get_page(*pl1e)); + } + l1e_write(pl1e, l1e_from_mfn(*mfn, flags)); + } + + unmap_domain_page_irqoff(l1tab); + unmap_domain_page_irqoff(l2tab); + unmap_domain_page_irqoff(l3tab); + + local_irq_restore(irq_flags); +} + void destroy_perdomain_mapping(struct domain *d, unsigned long va, unsigned int nr) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405453.1638952 (Exim 4.92) (envelope-from ) id 1x1hVp-0002Vm-8G; Wed, 02 Sep 2026 09:44:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405453.1638952; Wed, 02 Sep 2026 09:44:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVp-0002VY-1d; Wed, 02 Sep 2026 09:44:09 +0000 Received: by outflank-mailman (input) for mailman id 1405453; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVm-0002G4-Vz for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hVl-00B1Tu-V3 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:44:05 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97efe1-e002-0a2a0a5209dd-0a2a4504ec92-22 for ; Wed, 02 Sep 2026 11:44:05 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-ebf023.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe5-b57f-0a2a45040019-d99ba50cef06-1 for ; Wed, 02 Sep 2026 11:44:05 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 698C936928D4; Wed, 2 Sep 2026 10:44:05 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: George Dunlap , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v2 01/14] x86/domain_page: introduce IRQs-off variants of {,un}map_domain_page() Date: Wed, 2 Sep 2026 10:43:45 +0100 Message-ID: <20260901-asi-part2-1-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788342245-C12DCB50-5B4BB83C/0/0 X-purgate-type: clean X-purgate-size: 10808 From: George Dunlap Currently, map_domain_page() cannot be called in the context switch path. However, Xen already needs to update the slot of an incoming PV vcpu's GDT during context switch; and when we soon switch to per-vCPU root pagetables, we'll have to modify two more places. Xen currently solves the problem by special-casing the GDT/LDT L1 tables to be allocated from the xenheap, and stashing a pointer to its address in the xenheap in the domain struct. Rather than add more Xen pagetable pages to the xenheap, introduce a version of map_domain_page which can be called from the context switch path. The reason map_domain_page() cannot be called from the context switch path is x86's lazy context-switch state. Mapcache mappings are created in the page-tables that are loaded on the pCPU. When Xen is in a lazy context-switch state, current is the idle vCPU while the previously-running vCPU's page-tables remain loaded. If in this state, another pcpu wants access to the lazily-swapped-out vcpu's state, it will send a FLUSH_VCPU_STATE IPI to the processor, which will call sync_local_execstate(). sync_local_execstate() is implemented internally by calling a full __context_switch(). In addition to copying the processor state into the vcpu structure, this also switches the loaded pagetables to the idle vcpu's, which would in turn cause mappings created before the IPI to disappear mid-use. Therefore, mappings cannot be held in the mapcache when a FLUSH_VCPU_STATE IPI may execute. To this end, map_domain_page() calls sync_local_execstate() itself proactively when it detects a lazy context-switch state. This guarantees that the pagetables will remain consistent at least until the next context switch. But of course, that synchronization must not be triggered from the context switch path itself: sync_local_execstate() ends up in __context_switch(), so a call made while a context switch is in progress would recurse, and the assertions along that path (current being the idle vCPU) don't hold there either. A full synchronization is sufficient to prevent a FLUSH_VCPU_STATE IPI from switching the pagetables; however, it is not necessary. It suffices to maintain interrupts disabled from before the page is mapped until after it is unmapped. This condition is satisfied for the mappings used on the context switch path. Introduce {,un}map_domain_page_irqoff() variants for callers which guarantee that interrupts remain disabled from the map until the matching unmap. Under that guarantee the synchronization is unnecessary rather than merely inconvenient: no IPI can be delivered while the mapping is in use, so the lazy state cannot change under the caller's feet, and this_cpu(pgtable_vcpu) accurately identifies the mapcache to use (see 622c9a5ba95d "x86/mm: accurately track which vCPU page-tables are loaded"). The variants assert that interrupts are disabled on entry; the rest of the contract remains the caller's responsibility. This will be used by the next patch, which introduces a function which will be used to modify the incoming vCPU's per-domain mappings from within __context_switch(); it will also be used in future ASI patches (tearing down and establishing per-CPU stack mappings during context switch). No functional change for existing callers. Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Changes in v2: - New in this version. Replaces "x86/mm: allocate the per-domain page-tables from the xenheap". NB an alternate approach would be to disable the lazy context switch entirely. This simplifies the Xen code in general, and makes a patch like this completely unnecessary, as then map_domain_page would itself be safe to call in a context switch. Tests show, however, that simply removing the lazy context switch measurably hurts wake-heavy workloads: on a wake-paced ping flood, throughput drops 22% (round-trip latency 13→17 µs) on my NUC. Another approach is to take up the GDT/LDT L1 technique instead. v1 of the series made all perdomain pagetables allocated out of the xenheap; but this was objected to due to the additional xenheap allocations. An alternate version would allocate from the domheap, and then make permanent mappings in the vmap instead. Another potential performance improvement would be stashing the exact pages we want to map, rather than needing to walk from the L3 each time. We leave both of these for future work. --- xen/arch/x86/domain_page.c | 53 ++++++++++++++++++++++++++++------- xen/include/xen/domain_page.h | 14 +++++++++ 2 files changed, 57 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 72c00194f3..1fc1580e62 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -18,7 +18,7 @@ #include #include -static inline struct vcpu *mapcache_current_vcpu(void) +static inline struct vcpu *mapcache_current_vcpu(bool irqs_off) { struct vcpu *v = this_cpu(pgtable_vcpu); struct vcpu *curr = current; @@ -36,8 +36,15 @@ static inline struct vcpu *mapcache_current_vcpu(void) * to the idle vCPU now, otherwise an incoming FLUSH_VCPU_STATE IPI would * change the page tables under our feet an invalidate any in-use mapcache * entries. + * + * Callers of the irqs_off variants instead guarantee that interrupts stay + * disabled until the matching unmap: no IPI can be delivered while the + * mapping is in use, so the lazy state cannot change under our feet and + * pgtable_vcpu identifies the right mapcache directly. This also makes + * those variants usable from the context switch path itself, where + * calling sync_local_execstate() would recurse into __context_switch(). */ - if ( unlikely(this_cpu(curr_vcpu) != curr) ) + if ( !irqs_off && unlikely(this_cpu(curr_vcpu) != curr) ) { ASSERT(curr == idle_vcpu[smp_processor_id()]); sync_local_execstate(); @@ -46,10 +53,12 @@ static inline struct vcpu *mapcache_current_vcpu(void) } /* - * At this point we can guarantee Xen is not in lazy context switch: either - * the code above will have synced the state, or an incoming - * FLUSH_VCPU_STATE IPI has done so behind our back. Use ACCESS_ONCE to - * ensure the compiler never returns the locally cached pgtable_vcpu value. + * At this point either Xen is not in a lazy context switch (the code + * above will have synced the state, or an incoming FLUSH_VCPU_STATE IPI + * has done so behind our back), or the caller holds interrupts disabled + * and the state cannot change until it re-enables them. Use ACCESS_ONCE + * to ensure the compiler never returns the locally cached pgtable_vcpu + * value. */ return ACCESS_ONCE(this_cpu(pgtable_vcpu)); } @@ -59,7 +68,7 @@ static inline struct vcpu *mapcache_current_vcpu(void) #define MAPCACHE_L1ENT(idx) \ __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + pfn_to_paddr(idx))] -void *map_domain_page(mfn_t mfn) +static void *do_map_domain_page(mfn_t mfn, bool irqs_off) { unsigned long flags; unsigned int idx, i; @@ -73,7 +82,7 @@ void *map_domain_page(mfn_t mfn) return mfn_to_virt(mfn_x(mfn)); #endif - v = mapcache_current_vcpu(); + v = mapcache_current_vcpu(irqs_off); if ( !v || !is_pv_vcpu(v) ) return mfn_to_virt(mfn_x(mfn)); @@ -165,7 +174,19 @@ void *map_domain_page(mfn_t mfn) return (void *)MAPCACHE_VIRT_START + pfn_to_paddr(idx); } -void unmap_domain_page(const void *ptr) +void *map_domain_page(mfn_t mfn) +{ + return do_map_domain_page(mfn, false); +} + +void *map_domain_page_irqoff(mfn_t mfn) +{ + ASSERT(!local_irq_is_enabled()); + + return do_map_domain_page(mfn, true); +} + +static void do_unmap_domain_page(const void *ptr, bool irqs_off) { unsigned int idx; struct vcpu *v; @@ -178,7 +199,7 @@ void unmap_domain_page(const void *ptr) ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END); - v = mapcache_current_vcpu(); + v = mapcache_current_vcpu(irqs_off); ASSERT(v && is_pv_vcpu(v)); dcache = &v->domain->arch.pv.mapcache; @@ -223,6 +244,18 @@ void unmap_domain_page(const void *ptr) local_irq_restore(flags); } +void unmap_domain_page(const void *ptr) +{ + do_unmap_domain_page(ptr, false); +} + +void unmap_domain_page_irqoff(const void *ptr) +{ + ASSERT(!local_irq_is_enabled()); + + do_unmap_domain_page(ptr, true); +} + int mapcache_domain_init(struct domain *d) { struct mapcache_domain *dcache = &d->arch.pv.mapcache; diff --git a/xen/include/xen/domain_page.h b/xen/include/xen/domain_page.h index c89b149e54..b72dffb4c7 100644 --- a/xen/include/xen/domain_page.h +++ b/xen/include/xen/domain_page.h @@ -31,6 +31,16 @@ void *map_domain_page(mfn_t mfn); */ void unmap_domain_page(const void *ptr); +/* + * Variants of the above for callers which guarantee that interrupts are + * kept disabled from map until the matching unmap. Under that guarantee + * no state synchronization is required to keep the mapping valid, so these + * are safe to use in contexts where such a synchronization must not be + * triggered, in particular from the context switch path itself. + */ +void *map_domain_page_irqoff(mfn_t mfn); +void unmap_domain_page_irqoff(const void *ptr); + /* * Given a VA from map_domain_page(), return its underlying MFN. */ @@ -45,6 +55,7 @@ void *map_domain_page_global(mfn_t mfn); void unmap_domain_page_global(const void *ptr); #define __map_domain_page(pg) map_domain_page(page_to_mfn(pg)) +#define __map_domain_page_irqoff(pg) map_domain_page_irqoff(page_to_mfn(pg)) static inline void *__map_domain_page_global(const struct page_info *pg) { @@ -54,8 +65,11 @@ static inline void *__map_domain_page_global(const struct page_info *pg) #else /* !CONFIG_ARCH_MAP_DOMAIN_PAGE */ #define map_domain_page(mfn) __mfn_to_virt(mfn_x(mfn)) +#define map_domain_page_irqoff(mfn) map_domain_page(mfn) #define __map_domain_page(pg) page_to_virt(pg) +#define __map_domain_page_irqoff(pg) __map_domain_page(pg) #define unmap_domain_page(ptr) ((void)(ptr)) +#define unmap_domain_page_irqoff(ptr) unmap_domain_page(ptr) #define domain_page_map_to_mfn(ptr) _mfn(__virt_to_mfn((unsigned long)(ptr))) static inline void *map_domain_page_global(mfn_t mfn) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405452.1638946 (Exim 4.92) (envelope-from ) id 1x1hVo-0002TD-UD; Wed, 02 Sep 2026 09:44:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405452.1638946; Wed, 02 Sep 2026 09:44:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVo-0002T6-RA; Wed, 02 Sep 2026 09:44:08 +0000 Received: by outflank-mailman (input) for mailman id 1405452; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hVn-0002GB-2H for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:44:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hVm-0093D7-F3 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97efe1-8faa-0a2a0a5109dd-0a2a4502e798-16 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-720697.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-6ca4-0a2a45020019-d99ba50ce8c0-1 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id F2A1036928E5; Wed, 2 Sep 2026 10:44:05 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 06/14] x86/pv: remove stashing of GDT/LDT L1 page-tables Date: Wed, 2 Sep 2026 10:43:50 +0100 Message-ID: <20260901-asi-part2-6-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788342246-F22A92AC-867215E0/0/0 X-purgate-type: clean X-purgate-size: 4378 From: Roger Pau Monné There are no remaining users of the stashed L1 page-tables in pv_domain.gdt_ldt_l1tab. Remove it, and all helpers. This removes a globally-mapped xenheap allocation, and sets the stage for per-vCPU root page tables. pv_create_gdt_ldt_l1tab() now passes NIL() rather than the stash array. This will cause create_perdomain_mapping() to still eagerly allocate the L1 tables covering the GDT/LDT range; but their addresses are no longer handed back. Doing this is necessary because populate_perdomain_mapping() only fills existing tables, and treats missing structure as a bug. Another side effect of passing NIL() rather than a pointer is that the L1 tables move from the xenheap to the domheap. Residing in the xenheap was only ever a requirement when the stashed pointer had to stay usable; with that requirement dropped, we can relax the allocation requirement as well. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Changes in v2: - With "x86/mm: allocate the per-domain page-tables from the xenheap" dropped from the series, passing NIL() now does move the GDT/LDT L1 tables to the domheap (upstream's allocation for non-capture mode); in v1 they stayed in the xenheap in all modes. Reword the commit message accordingly. Changes since the previously posted version: - Note the implications of changing from pointer to NIL() in pv_create_gdt_ldt_l1tab(). In v2 this also changed where new GDT/LDT L1 tables were allocated from: upstream's capture mode takes them from the xenheap (the stashed pointer has to stay usable), the NIL() mode from the domheap. Here they come from the xenheap in all modes ("x86/mm: allocate the per-domain page-tables from the xenheap"), so the switch only stops the addresses being handed back. --- xen/arch/x86/include/asm/domain.h | 9 --------- xen/arch/x86/pv/domain.c | 10 +--------- 2 files changed, 1 insertion(+), 18 deletions(-) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 61a9fe00f0..5c7fad26a6 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -287,8 +287,6 @@ struct time_scale { struct pv_domain { - l1_pgentry_t **gdt_ldt_l1tab; - atomic_t nr_l4_pages; /* Is a 32-bit PV guest? */ @@ -524,13 +522,6 @@ struct arch_domain #define has_pirq(d) (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ)) #define has_vpci(d) (!!((d)->arch.emulation_flags & X86_EMU_VPCI)) -#define gdt_ldt_pt_idx(v) \ - ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT)) -#define pv_gdt_ptes(v) \ - ((v)->domain->arch.pv.gdt_ldt_l1tab[gdt_ldt_pt_idx(v)] + \ - (((v)->vcpu_id << GDT_LDT_VCPU_SHIFT) & (L1_PAGETABLE_ENTRIES - 1))) -#define pv_ldt_ptes(v) (pv_gdt_ptes(v) + 16) - struct pv_vcpu { /* map_domain_page() mapping cache. */ diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index 7ddab1949f..35d1761c9c 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -315,7 +315,7 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v) { return create_perdomain_mapping(v->domain, GDT_VIRT_START(v), 1U << GDT_LDT_VCPU_SHIFT, - v->domain->arch.pv.gdt_ldt_l1tab, + NIL(l1_pgentry_t *), NULL); } @@ -389,8 +389,6 @@ void pv_domain_destroy(struct domain *d) GDT_LDT_MBYTES << (20 - PAGE_SHIFT)); XFREE(d->arch.pv.cpuidmasks); - - FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab); } void noreturn cf_check continue_pv_domain(void); @@ -406,12 +404,6 @@ int pv_domain_initialise(struct domain *d) pv_l1tf_domain_init(d); - d->arch.pv.gdt_ldt_l1tab = - alloc_xenheap_pages(0, MEMF_node(domain_to_node(d))); - if ( !d->arch.pv.gdt_ldt_l1tab ) - goto fail; - clear_page(d->arch.pv.gdt_ldt_l1tab); - if ( levelling_caps & ~LCAP_faulting && (d->arch.pv.cpuidmasks = xmemdup(&cpuidmask_defaults)) == NULL ) goto fail; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:45:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:45:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405495.1638999 (Exim 4.92) (envelope-from ) id 1x1hWp-0005RR-Ld; Wed, 02 Sep 2026 09:45:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405495.1638999; Wed, 02 Sep 2026 09:45:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hWp-0005RK-Il; Wed, 02 Sep 2026 09:45:11 +0000 Received: by outflank-mailman (input) for mailman id 1405495; Wed, 02 Sep 2026 09:45:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hWo-0005Pa-MD for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:45:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hWn-00B1lJ-Uw for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:45:10 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f025-8faa-0a2a0a5109dd-0a2a4508977a-0 for ; Wed, 02 Sep 2026 11:45:09 +0200 Received: from [52.101.53.59] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97f024-f659-0a2a45080019-3465353bd724-4 for ; Wed, 02 Sep 2026 11:45:09 +0200 Received: from SN7PR04CA0087.namprd04.prod.outlook.com (2603:10b6:806:121::32) by IA1PR12MB8555.namprd12.prod.outlook.com (2603:10b6:208:44f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Wed, 2 Sep 2026 09:45:02 +0000 Received: from SN1PEPF00036F42.namprd05.prod.outlook.com (2603:10b6:806:121:cafe::ac) by SN7PR04CA0087.outlook.office365.com (2603:10b6:806:121::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.10 via Frontend Transport; Wed, 2 Sep 2026 09:45:02 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SN1PEPF00036F42.mail.protection.outlook.com (10.167.248.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Wed, 2 Sep 2026 09:45:02 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 04:45:01 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 04:45:02 -0500 Received: from [10.71.198.170] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 04:44:59 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VaNaFkPxxuKAWjK+plyShAHfpb7UHbH8apYtwWlfqt0LUChEo92aVXQGoS3IQo/eZGvpI1pxUatWqlrIpzfF9AnN6+UrmwIb/OutSXLYWBebd5yY9rK+RYXrXbf0PTBcHi4SM8YJH3KLQ6q6szDMbxrJPL+rsoeDq03o8Z9jyiV2whOScmvARrZXM81X6RJoL4GzGWZeN6188gXixmurO9wc6Y6ivyp/U0Pn7fs4e7UnEXAxELHFbHsvPMpdOJYmtsmUtEZWwsi0+rZsnBm7BzwF/kwijgaOhzQcHLxphJ2mpfIJRIEbeMFs+IwgymcXW/TeeXr7HnTm5cC6nkyHLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9R2QEKRMjFQlZwrUsSGWRWGD22RJL6fva8FfRxAifWs=; b=uU5d62TdugIhQn4QndoC3jM03z8pJUpdOJBiWBcpWXlUvAk9jJsrt9VYSz/tqnKsyA2GHfHQAIx7BI9VC+kaquy7hb5RW0mH2jY//bdBJhya8CtZKblVNZZ+v7UdmPIMvyspsbOLgrgWv7VIn3T7v925Yjb1EAaXjdiyw8di4QP9l4oGLxl/Fmv/5t8yp96FPdvE9gwvU71v2kGJ61ZD7UcdJCm6OPTAhjorp3OTqQBCtcdKJq0TNbM3Fx/84cGn75DG7uYf/BtljGT52pW0Z76KLIiN7v5XLxgOLf9m67E1jPP71VW62GxWRqIi8Fm9QwVNMBTXxaDq6bZWPrAbYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9R2QEKRMjFQlZwrUsSGWRWGD22RJL6fva8FfRxAifWs=; b=ynBBusbrqaA51jgKzHAoa9j9rPfDywwXhbZ9OAvAijT0CG3Mpgp3dH8uhvpQAkmGdMl8uPeEiqIj2fqK/acjBlpn3fcU9n0IFvfn52m9i/peaoVRJ7pTM/BywFEfJiFYVnIVffn65J71QoZ7ygoT24B+um8fYMcBpCPeV6UMSUI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: <48a7a4a3-605a-4a22-a7ad-2a4041f65b77@amd.com> Date: Wed, 2 Sep 2026 10:44:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] drivers/char: Panic when the requested UART fails to initialise To: Michal Orzel , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alistair Francis , "Connor Davis" , Oleksii Kurochko , , Andrei Buzdugan , Simone Weiss , , References: <20260902073606.61062-1-michal.orzel@amd.com> <20260902073606.61062-4-michal.orzel@amd.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <20260902073606.61062-4-michal.orzel@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF00036F42:EE_|IA1PR12MB8555:EE_ X-MS-Office365-Filtering-Correlation-Id: 515725c5-a3b3-4da4-7b1b-08df08d6dc6d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|23010399003|36860700016|82310400026|1800799024|6133799003|10067099003|4143699003|5023799004|11063799006|18002099003|22082099003|56012099006|3023799007; X-Microsoft-Antispam-Message-Info: 7ceoMUCm+nuDrvlp6SKHwa8VceiLa2THAXEnBwLO/gY/hC4rKFaOaSkBYYfNqWY7hcTiZKmzP7pDpx0qifUBOWnYTPb+kvg/0yii5ren4va//QD3hJONPW/BkTt+xQNL9YF30m1lFJiImukaYDIOQKUYccdiwcFbByIAeFpnds13KrWc7xlhxcGIiN86V0nhdl0hCLft3OBVGQlFxZYUEONQZOQjx2MDCn35uP3U1wVwiDTPPg5JeOahxeUIN5/cJZpZjGBH/b5pfhBO/0B1/SW1VXd8olab7OaBOg99UteUcB48e2r5rALY6hSo+RDUnKrKkDZpZRBvpoYV8tJEMPabVrhCAJ5dubFr3MOJAEz7unjwhW9G+BH+ZrddmhjVrsStdko7tIJr2VsLy9ZTi0sIiW2bpkdcbveZUrwpO6YbbnRcsq8V1cJG7kXu9ded04f8YRdYc/Rm0mn1qE1alYGqmWlu9vpJyba9fNpKdaOhrQGS//YErXhb7Y6HlYC4mI5DYnlGpqcvWa2IcWlsJ8CSoOtdB/451ehSIBHsbtoqdsQ1eb51B32pYFNi6ceTAOr5Vcc7a69Z8RUr0I+9mlZLFFB+DWes29pUUgXioJEnKjxWRI+KhGFSlVqrMlXlkqahRvv4UA/W8xkzwNB6nDfyW+Rb4VXlr+h9CKYXX+/hI4gFdD1J9LshuBiIf8eO333r5Z+/P/rPx4qr0BcDJA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(23010399003)(36860700016)(82310400026)(1800799024)(6133799003)(10067099003)(4143699003)(5023799004)(11063799006)(18002099003)(22082099003)(56012099006)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: fMhOU3878vSw22WL8qE9NTNGedcBv7jPK72gHRAZAa4tCWdnbMt7reNRUjr/U2byWiZA+mjszvIwHDvs9Mk5jhLOCCJsEZIUrnxLNR7dZUOOn+Jv13kTHc/wH0rDXMNKOtsMaEdjdOAmiVAyw8mJ18W49Ok8JprIV7SMQxGupCUlHRYGJM7uPwqJK1aNd2O+bcTsQiz9taLeffyiLJNSLTCcoQgXlvFYzGTucMdxS0ZK8EtdIYGsUcmSMz2Fy+tdBu7TTQGiQloh2m/PSE0IsvW0uHpgYyKRiiIbtuwH3+MrNM63cl424sSZAXmCD2ZlmEVdZbke+hIXZnbGGSOYvTLCcLECvsfI6d+Qh9ffriEdfVQ4Aws7kxQdLRDg+F1IZvMFZAKDWIcRH15IcvZSdawgCOhDVkcTPor9PZamwj/9FShJVAHX6ivCuMNkecXh X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 09:45:02.3432 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 515725c5-a3b3-4da4-7b1b-08df08d6dc6d X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF00036F42.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8555 X-purgate-ID: tlsNG-c1860d/1788342309-CE54487B-F36AF1EC/0/0 X-purgate-type: clean X-purgate-size: 7631 Hi, On 02/09/2026 08:36, Michal Orzel wrote: > uart_init() cannot tell its caller that the UART the user asked for did > not come up: every failure path only printks. Arm and RISC-V carry on > into console_init_preirq() and boot without a console, rather than > refusing to boot as they do elsewhere when a user request cannot be met. I just want to emphasize that from functional safety perspective, this is the preferred approach. The user's request is given the priority and whenever it cannot be satisfied, Xen should panic. > > Return an error from dt_uart_init() and panic in start_xen(). An > explicit request Xen cannot satisfy should stop the boot rather than > silently degrade it, If there is a silent degradation, then we need to document this behavior somewhere. I am happy to keep this documented under docs/fusa. In the safety manual, we should mention all the instances when there is a silent degradation observed, the underlying reason and how the end user can detect it. Other FuSa experts can comment. > which is what start_xen() already does for the rest > of the boot configuration. > > Only a path given on the command line counts as a request we have to > satisfy. Falling back to /chosen/stdout-path or acpi_uart_init() > therefore never fails. SPCR is firmware provided, the analogue of > stdout-path, and there is no ACPI equivalent of dtuart= to make an > explicit request with. > > While here, decide whether the SPCR table was found from the returned > acpi_status rather than from the table pointer, which was only NULL > because the caller initialised it - acpi_get_table() writes it solely > on success. > > Signed-off-by: Michal Orzel > --- > With this change diagnosibility decreases only for a single scenario: > when dom0 is reachable not via console (e.g. network) and you'd have used xl > dmesg to read messages from the conring. > > On Arm (I suppose RISC-V is similar), given that safety becomes the major > use-case and we need to satisfy all the user/guest-xen contracts, I think the > patch moves us in a direction we already chose (i.e. we panic on every boot > failure where we cannot meet the requests). > --- > xen/arch/arm/setup.c | 5 +++- > xen/arch/riscv/setup.c | 6 ++++- > xen/drivers/char/uart-init.c | 52 +++++++++++++++++++++--------------- > xen/include/xen/serial.h | 6 ++++- > 4 files changed, 44 insertions(+), 25 deletions(-) > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 6310a47d68b6..d0066db42e7c 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -379,7 +379,10 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) > > gic_preinit(); > > - uart_init(); > + rc = uart_init(); > + if ( rc ) > + panic("Failed to initialize the requested UART (%d)\n", rc); > + > console_init_preirq(); > console_init_ring(); > > diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c > index 56a0907a855f..07f46ac3ce27 100644 > --- a/xen/arch/riscv/setup.c > +++ b/xen/arch/riscv/setup.c > @@ -77,6 +77,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id, > { > const char *cmdline; > size_t fdt_size; > + int rc; > > remove_identity_mapping(); > > @@ -149,7 +150,10 @@ void __init noreturn start_xen(unsigned long bootcpu_id, > > intc_preinit(); > > - uart_init(); > + rc = uart_init(); > + if ( rc ) > + panic("Failed to initialize the requested UART (%d)\n", rc); > + > console_init_preirq(); > > intc_init(); > diff --git a/xen/drivers/char/uart-init.c b/xen/drivers/char/uart-init.c > index eb7f85549593..b79135be9620 100644 > --- a/xen/drivers/char/uart-init.c > +++ b/xen/drivers/char/uart-init.c > @@ -30,15 +30,17 @@ > static char __initdata opt_dtuart[256] = ""; > string_param("dtuart", opt_dtuart); > > -static void __init dt_uart_init(void) > +static int __init dt_uart_init(void) > { > struct dt_device_node *dev; > int ret; > const char *devpath = opt_dtuart; > const char *options; > char *split; > + /* Set on the command line, as opposed to inherited from /chosen */ > + bool explicit_request = strcmp(opt_dtuart, "") != 0; > > - if ( !strcmp(opt_dtuart, "") ) > + if ( !explicit_request ) > { > const struct dt_device_node *chosen = dt_find_node_by_path("/chosen"); > > @@ -62,7 +64,12 @@ static void __init dt_uart_init(void) > if ( !strcmp(opt_dtuart, "") ) > { > printk("No dtuart path configured\n"); > - return; > + > + /* > + * console=dtuart is the compiled-in default, so an absent dtuart= is > + * not a failed user request. > + */ > + return 0; > } > > split = strchr(opt_dtuart, ':'); > @@ -83,48 +90,49 @@ static void __init dt_uart_init(void) > if ( !dev ) > { > printk("Unable to find device \"%s\"\n", devpath); > - return; > + return explicit_request ? -ENODEV : 0; > } > > ret = device_init(dev, DEVICE_SERIAL, options); > - > if ( ret ) > printk("Unable to initialize dtuart: %d\n", ret); > + > + return explicit_request ? ret : 0; > } > > #ifdef CONFIG_ACPI > -static void __init acpi_uart_init(void) > +static int __init acpi_uart_init(void) > { > - struct acpi_table_spcr *spcr = NULL; > + struct acpi_table_spcr *spcr; > + acpi_status status; > int ret; > > - acpi_get_table(ACPI_SIG_SPCR, 0, (struct acpi_table_header **)&spcr); > + /* SPCR is firmware provided, so nothing here is a failed user request */ > + status = acpi_get_table(ACPI_SIG_SPCR, 0, > + (struct acpi_table_header **)&spcr); > > - if ( spcr == NULL ) > + if ( ACPI_FAILURE(status) ) > { > printk("Unable to get spcr table\n"); > + return 0; > } > - else > - { > - ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type); > > - if ( ret ) > - printk("Unable to initialize acpi uart: %d\n", ret); > - } > + ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type); > + if ( ret ) > + printk("Unable to initialize acpi uart: %d\n", ret); > + > + return 0; > } > #else > -static void __init acpi_uart_init(void) { } > +static int __init acpi_uart_init(void) { return 0; } > #endif > > -void __init uart_init(void) > +int __init uart_init(void) > { > if ( !console_has("dtuart") ) > - return; /* Not for us */ > + return 0; /* Not for us */ > > - if ( acpi_disabled ) > - dt_uart_init(); > - else > - acpi_uart_init(); > + return acpi_disabled ? dt_uart_init() : acpi_uart_init(); > } > > /* > diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h > index 8e1844555208..3a71da767dd7 100644 > --- a/xen/include/xen/serial.h > +++ b/xen/include/xen/serial.h > @@ -170,7 +170,11 @@ void xhci_dbc_uart_init(void); > static void inline xhci_dbc_uart_init(void) {} > #endif > > -void uart_init(void); > +/* > + * Returns 0 unless a UART explicitly requested via dtuart= failed to > + * initialise. > + */ > +int uart_init(void); > > struct physdev_dbgp_op; > int dbgp_op(const struct physdev_dbgp_op *op); LGTM - Ayan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:46:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:46:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405508.1639008 (Exim 4.92) (envelope-from ) id 1x1hXm-0006BC-2B; Wed, 02 Sep 2026 09:46:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405508.1639008; Wed, 02 Sep 2026 09:46:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hXl-0006B0-Vp; Wed, 02 Sep 2026 09:46:09 +0000 Received: by outflank-mailman (input) for mailman id 1405508; Wed, 02 Sep 2026 09:46:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hXk-0006AZ-EU for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:46:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hXj-00HNId-RZ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:46:07 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f056-2eae-0a2a0a5409dd-0a2a4504b044-42 for ; Wed, 02 Sep 2026 11:46:07 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-ebf023.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-b57f-0a2a45040019-d99ba50cfba4-3 for ; Wed, 02 Sep 2026 11:44:07 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 532A23692902; Wed, 2 Sep 2026 10:44:07 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 14/14] x86/mm: introduce per-vCPU L3 page-table Date: Wed, 2 Sep 2026 10:43:58 +0100 Message-ID: <20260901-asi-part2-14-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788342247-C0CDFB50-70616C36/0/0 X-purgate-type: clean X-purgate-size: 25501 From: Roger Pau Monné The per-domain area is currently a single domain-wide structure: one L3, referenced from every root page-table associated with the domain, so every mapping in it is visible to every vCPU of the domain. Its contents are already laid out in per-vCPU slices (each vCPU's GDT/LDT window, COMPAT_ARG_XLAT pages, and mapcache entries), but the visibility is domain-wide. Meanwhile, much of the per-vCPU state Xen maintains -- the VMCB, the VMX MSR load/save areas, FPU/XSAVE state -- lives in always-mapped memory, and so do the pCPU stacks. Allow the "per-domain" area to be per-vCPU instead ("VCPU-PT"). This will immediately isolate the existing per-vCPU mappings from other running vCPUs on HVM domains (PV SMP for VCPU-PT requires further work; see below). We will later build on this, adding per-vCPU mapped areas (into which we can put vCPU state currently in the xenheap, mentioned above); per-vCPU mapcaches (which will eventually allow us to remove domheap pages from the direct map), and finally transient mappings of the pCPU stack on which the vCPU is currently running. Add pervcpu_l3_pg to the arch_vcpu struct, to correspond to the perdomain_l3_pg in the domain struct. (We retain both so that we can switch between per-domain and per-vCPU on a domain-by-domain basis.) In {create,populate,destroy}_perdomain_mapping(), if d->arch.vcpu_pt, use pervcpu_l3_pg as the per-domain L3 (allocating it for a vCPU if it's NULL, just as we allocate for a domain in !vcpu_pt mode); otherwise, use perdomain_l3_pg. Introduce a helper, perdomain_l3(), to consistently choose the correct one. Introduce free_pervcpu_mappings() to free this tree, called from arch_vcpu_destroy() on normal teardown. Since the vcpu structure holds the only reference to pervcpu_l3_pg, arch_vcpu_create() must also call it on its error paths: nothing else records the allocation once the vcpu struct is torn down. The domain-wide free_perdomain_mappings() is unchanged and keeps covering non-vCPU-PT domains. Modify init_xen_l4_slots() to take a vCPU, and use perdomain_l3() to select the value to install in slot 260. Most callers have the specific vCPU in hand (the HVM monitor tables, setup_compat_l4(), PV shadow L4s). Note that this includes dom0_construct(), since at that point we're actually building vCPU 0, so passing in d->vcpu[0] is exactly what we want. In promote_l4_table() we pass in d->vcpu[0]. This is correct without vCPU-PT, where every vCPU selects the same domain-wide L3. With vCPU-PT this is a temporary arrangement: the promoted L4 carries vCPU 0's L3 until the per-pCPU shadow L4 -- which supersedes promoted L4s as what the CPU actually runs on -- arrives in the series (see the SMP note below). Since slot 260 is now keyed off d->vcpu[0], promote_l4_table() refuses (-EINVAL) a domain that has no vCPUs yet, as can happen if a toolstack pins page tables before creating vCPUs. paravirt_ctxt_switch_to() now installs the XPTI root_pgt per-domain slot only when the domain has a domain-wide perdomain area to install. XPTI and vCPU-PT are mutually exclusive (xpti_init_default() disables vCPU-PT if both are explicitly requested, and each defaults off when the other is on) -- so the vCPU-PT slot stays empty, as paravirt_ctxt_switch_from() left it. vCPU-PT is not currently implemented for shadow paging. L4 shadows are currently per-domain objects shared by all vCPUs shadowing the same guest root, just as non-ASI non-shadow PV L4s are. Enabling vCPU-PT for PV shadow guests would require adding vCPU-PT functionality along all the shadow paths, which is outside the scope of the current work. This is guarded on every path that can turn shadow on for a PV domain: paging_domctl() refuses shadow/log-dirty ops (xl save/migrate) for such domains; dom0=shadow is ignored with a warning when dom0 uses vCPU-PT; and shadow_one_bit_enable() refuses the mode with -EOPNOTSUPP. The PV L1TF mitigation cannot be refused up front: it acts at runtime, when a guest installs a not-present PTE whose address is unsafe, by forcing the domain into shadow mode -- which is what a vCPU-PT domain cannot currently have. No special handling is needed, though: pv_l1tf_check_pte() refuses the PTE write and schedules the shadowing tasklet as usual; the tasklet's shadow_one_bit_enable() call fails with -EOPNOTSUPP like any other enable failure; and the tasklet's existing error handling crashes the domain. That is the right disposition -- the entry being installed is precisely what the mitigation exists to catch, so continuing unmitigated is not an option -- and it matches what a build without CONFIG_SHADOW_PAGING does for the same write, with a log trail showing the mitigation was attempted and could not be enabled. Hardware without the erratum is unaffected, the mitigation being off there by default. Note SMP vCPU-PT PV guests are not yet functional at this point in the series: promoted guest L4s embed vCPU#0's L3 in slot 260 for all vCPUs; the per-pCPU shadow L4 that gives each vCPU its own slot 260 arrives with the guest_root_pt and per-pCPU-L4 patches later in the series. HVM vCPU-PT guests are fully functional, SMP included: monitor tables are already per-vCPU, so every HVM vCPU's root carries its own L3 from creation. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Added to the series Changes since the previously posted version: - Expand the commit message with the motivation and the design rationale. - pv-l1tf: let the mitigation's shadowing request fail in shadow_one_bit_enable() and rely on the tasklet's existing failure handling to crash the domain, rather than special-casing vCPU-PT in pv_l1tf_check_pte() or forcing the mitigation off at boot (an earlier revision did the latter, silently withdrawing a protection that is on by default on affected hardware). - Keep domain-wide freeing intact and introduce a vCPU-scoped free_pervcpu_mappings() instead of re-scoping free_perdomain_mappings(); fix the arch_vcpu_create() error-path leaks of a partially built per-vCPU hierarchy. - Exclude PV shadow for vCPU-PT domains on all enable paths: refuse shadow/log-dirty paging_domctl() ops (gate moved here from the later per-pCPU-L4 patch so hazard and gate land together), ignore dom0=shadow with a warning, and refuse the mode (-EOPNOTSUPP) in shadow_one_bit_enable(). - Add a perdomain_l3() helper for the root selection, rather than open-coding the vcpu_pt choice (and testing both root pointers) at each site. - Guard promote_l4_table() against vCPU-less domains. - Install the XPTI root_pgt per-domain slot only when the domain has a perdomain L3; the posted version computed an L4E from the NULL pointer for vCPU-PT domains. (A new preparatory patch pairs the slot's maintenance with a switch-out clear.) - Do not log the refusal for XEN_DOMCTL_SHADOW_OP_OFF. Turning paging off is the de-facto "make sure it is off" interface: the save path issues it unconditionally as best-effort cleanup and discards the result, so every save of a PV domain otherwise printed a hypervisor error for an operation nothing was asking to succeed. --- xen/arch/x86/domain.c | 21 +++++--- xen/arch/x86/include/asm/domain.h | 12 +++++ xen/arch/x86/include/asm/mm.h | 3 +- xen/arch/x86/mm.c | 87 +++++++++++++++++++++++-------- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/paging.c | 14 +++++ xen/arch/x86/mm/shadow/common.c | 11 ++++ xen/arch/x86/mm/shadow/hvm.c | 2 +- xen/arch/x86/mm/shadow/multi.c | 2 +- xen/arch/x86/pv/dom0_build.c | 8 ++- xen/arch/x86/pv/domain.c | 2 +- 11 files changed, 126 insertions(+), 38 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 79555e6964..3e571272d8 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -513,7 +513,7 @@ int arch_vcpu_create(struct vcpu *v) rc = mapcache_vcpu_init(v); if ( rc ) - return rc; + goto fail_early; if ( !is_idle_domain(d) ) { @@ -525,12 +525,12 @@ int arch_vcpu_create(struct vcpu *v) */ rc = create_perdomain_mapping(v, PERDOMAIN_VIRT_START, 0, false); if ( rc ) - return rc; + goto fail_early; paging_vcpu_init(v); if ( (rc = vcpu_init_fpu(v)) != 0 ) - return rc; + goto fail_early; vmce_init_vcpu(v); @@ -578,6 +578,8 @@ int arch_vcpu_create(struct vcpu *v) vcpu_destroy_fpu(v); xfree(v->arch.msrs); v->arch.msrs = NULL; + fail_early: + free_pervcpu_mappings(v); return rc; } @@ -598,6 +600,8 @@ void arch_vcpu_destroy(struct vcpu *v) pv_vcpu_destroy(v); else ASSERT_UNREACHABLE(); + + free_pervcpu_mappings(v); } int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) @@ -2033,12 +2037,13 @@ void cf_check paravirt_ctxt_switch_to(struct vcpu *v) root_pgentry_t *root_pgt = this_cpu(root_pgt); /* - * If XPTI is active, install the incoming domain's per-domain area - * in the per-domain slot of the L4 we run on while in guest mode. - * The slot was cleared on the way out (see - * paravirt_ctxt_switch_from()). + * If XPTI is active and the domain has a domain-wide perdomain area, + * install it in the per-domain slot of the L4 we run on while in + * guest mode. vCPU-PT domains have none (they don't use the XPTI + * machinery); their slot stays as paravirt_ctxt_switch_from() left + * it: empty. */ - if ( root_pgt ) + if ( root_pgt && v->domain->arch.perdomain_l3_pg ) root_pgt[root_table_offset(PERDOMAIN_VIRT_START)] = l4e_from_page(v->domain->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index fdf7b205ea..5c90d7627f 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -330,6 +330,11 @@ struct monitor_write_data { struct arch_domain { + /* + * Domain-wide L3 page-table for the L4 per-domain slot, used when + * the domain does not use per-vCPU page-tables (!d->arch.vcpu_pt). + * NULL otherwise (see v->arch.pervcpu_l3_pg and perdomain_l3()). + */ struct page_info *perdomain_l3_pg; /* I/O-port admin-specified access capabilities. */ @@ -678,6 +683,13 @@ struct arch_vcpu struct vcpu_msrs *msrs; + /* + * Per-vCPU L3 page-table for the L4 per-domain slot, used when the + * domain uses per-vCPU page-tables (d->arch.vcpu_pt). NULL + * otherwise (see d->arch.perdomain_l3_pg and perdomain_l3()). + */ + struct page_info *pervcpu_l3_pg; + struct { bool next_interrupt_enabled; } monitor; diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 97924a639b..acb553df48 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -370,7 +370,7 @@ int devalidate_page(struct page_info *page, unsigned long type, void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d); void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, - const struct domain *d, mfn_t sl4mfn, bool ro_mpt); + const struct vcpu *v, mfn_t sl4mfn, bool ro_mpt); bool fill_ro_mpt(mfn_t mfn); void zap_ro_mpt(mfn_t mfn); @@ -608,6 +608,7 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int nr); void free_perdomain_mappings(struct domain *d); +void free_pervcpu_mappings(struct vcpu *v); void __iomem *ioremap_wc(paddr_t pa, size_t len); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 6dfd75475a..48266b1d27 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1638,20 +1638,32 @@ static int promote_l3_table(struct page_info *page) } #endif /* CONFIG_PV */ +/* + * The root of the per-domain area in use by @v: the vCPU's own L3 for a + * vCPU-PT domain, the domain-wide one otherwise. + */ +static struct page_info *perdomain_l3(const struct vcpu *v) +{ + const struct domain *d = v->domain; + + return d->arch.vcpu_pt ? v->arch.pervcpu_l3_pg : d->arch.perdomain_l3_pg; +} + /* * Fill an L4 with Xen entries. * * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any * values a guest may have left there from promote_l4_table(). * - * l4t, l4mfn, and d are mandatory, but l4mfn doesn't need to be the mfn under + * l4t, l4mfn, and v are mandatory, but l4mfn doesn't need to be the mfn under * *l4t. All other parameters are optional and will either fill or zero the * appropriate slots. Pagetables not shared with guests will gain the * extended directmap. */ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, - const struct domain *d, mfn_t sl4mfn, bool ro_mpt) + const struct vcpu *v, mfn_t sl4mfn, bool ro_mpt) { + const struct domain *d = v->domain; /* * PV vcpus need a shortened directmap. HVM and Idle vcpus get the full * directmap. @@ -1679,7 +1691,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, /* Slot 260: Per-domain mappings. */ l4t[l4_table_offset(PERDOMAIN_VIRT_START)] = - l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); + l4e_from_page(perdomain_l3(v), __PAGE_HYPERVISOR_RW); /* Slot 4: Per-domain mappings mirror. */ BUILD_BUG_ON(IS_ENABLED(CONFIG_PV32) && @@ -1755,11 +1767,17 @@ static int promote_l4_table(struct page_info *page) { struct domain *d = page_get_owner(page); mfn_t l4mfn = page_to_mfn(page); - l4_pgentry_t *pl4e = map_domain_page(l4mfn); + l4_pgentry_t *pl4e; unsigned int i; int rc = 0; unsigned int partial_flags = page->partial_flags; + /* init_xen_l4_slots() needs a vCPU to key the per-domain slot off. */ + if ( unlikely(!d->vcpu || !d->vcpu[0]) ) + return -EINVAL; + + pl4e = map_domain_page(l4mfn); + for ( i = page->nr_validated_ptes; i < L4_PAGETABLE_ENTRIES; i++, partial_flags = 0 ) { @@ -1834,8 +1852,15 @@ static int promote_l4_table(struct page_info *page) if ( !rc ) { + /* + * Use vCPU#0 unconditionally. When not running with ASI enabled the + * per-domain table is shared between all vCPUs, so it doesn't matter + * which vCPU gets passed to init_xen_l4_slots(). When running with + * ASI enabled this L4 will not be used, as a shadow per-vCPU L4 is + * used instead. + */ init_xen_l4_slots(pl4e, l4mfn, - d, INVALID_MFN, VM_ASSIST(d, m2p_strict)); + d->vcpu[0], INVALID_MFN, VM_ASSIST(d, m2p_strict)); atomic_inc(&d->arch.pv.nr_l4_pages); } unmap_domain_page(pl4e); @@ -6238,7 +6263,7 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, bool populate) { struct domain *d = v->domain; - struct page_info *pg; + struct page_info *pg, *l3_pg = perdomain_l3(v); l3_pgentry_t *l3tab; l2_pgentry_t *l2tab; l1_pgentry_t *l1tab; @@ -6247,14 +6272,17 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va, ASSERT(va >= PERDOMAIN_VIRT_START && va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); - if ( !d->arch.perdomain_l3_pg ) + if ( !l3_pg ) { pg = alloc_domheap_page(d, MEMF_no_owner); if ( !pg ) return -ENOMEM; l3tab = __map_domain_page(pg); clear_page(l3tab); - d->arch.perdomain_l3_pg = pg; + if ( d->arch.vcpu_pt ) + v->arch.pervcpu_l3_pg = pg; + else + d->arch.perdomain_l3_pg = pg; if ( !nr ) { unmap_domain_page(l3tab); @@ -6264,7 +6292,7 @@ int create_perdomain_mapping(struct vcpu *v, unsigned long va, else if ( !nr ) return 0; else - l3tab = __map_domain_page(d->arch.perdomain_l3_pg); + l3tab = __map_domain_page(l3_pg); ASSERT(!l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1))); @@ -6359,7 +6387,7 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, l1_pgentry_t *l1tab = NULL, *pl1e; const l3_pgentry_t *l3tab; const l2_pgentry_t *l2tab; - struct domain *d = v->domain; + struct page_info *l3_pg; unsigned long irq_flags; ASSERT(va >= PERDOMAIN_VIRT_START && @@ -6401,7 +6429,8 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, return; } - BUG_ON(!d->arch.perdomain_l3_pg); + l3_pg = perdomain_l3(v); + BUG_ON(!l3_pg); /* * Slow path: walk v's per-domain page-table pages. All mappings are @@ -6413,7 +6442,7 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, */ local_irq_save(irq_flags); - l3tab = __map_domain_page_irqoff(d->arch.perdomain_l3_pg); + l3tab = __map_domain_page_irqoff(l3_pg); /* * Missing page-table structure is a hypervisor bug: there is no safe @@ -6461,13 +6490,13 @@ void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int nr) { const l3_pgentry_t *l3tab, *pl3e; - const struct domain *d = v->domain; + struct page_info *l3_pg = perdomain_l3(v); ASSERT(va >= PERDOMAIN_VIRT_START && va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1))); - if ( !d->arch.perdomain_l3_pg ) + if ( !l3_pg ) return; if ( likely(this_cpu(pgtable_vcpu) == v) ) @@ -6490,7 +6519,7 @@ void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, return; } - l3tab = __map_domain_page(d->arch.perdomain_l3_pg); + l3tab = __map_domain_page(l3_pg); pl3e = l3tab + l3_table_offset(va); if ( l3e_get_flags(*pl3e) & _PAGE_PRESENT ) @@ -6529,16 +6558,11 @@ void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unmap_domain_page(l3tab); } -void free_perdomain_mappings(struct domain *d) +static void free_perdomain_l3(struct page_info *l3pg) { - l3_pgentry_t *l3tab; + l3_pgentry_t *l3tab = __map_domain_page(l3pg); unsigned int i; - if ( !d->arch.perdomain_l3_pg ) - return; - - l3tab = __map_domain_page(d->arch.perdomain_l3_pg); - for ( i = 0; i < PERDOMAIN_SLOTS; ++i) if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT ) { @@ -6571,10 +6595,27 @@ void free_perdomain_mappings(struct domain *d) } unmap_domain_page(l3tab); - free_domheap_page(d->arch.perdomain_l3_pg); + free_domheap_page(l3pg); +} + +void free_perdomain_mappings(struct domain *d) +{ + if ( !d->arch.perdomain_l3_pg ) + return; + + free_perdomain_l3(d->arch.perdomain_l3_pg); d->arch.perdomain_l3_pg = NULL; } +void free_pervcpu_mappings(struct vcpu *v) +{ + if ( !v->arch.pervcpu_l3_pg ) + return; + + free_perdomain_l3(v->arch.pervcpu_l3_pg); + v->arch.pervcpu_l3_pg = NULL; +} + static void write_sss_token(unsigned long *ptr) { /* diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c index 0ede4181a0..aba4f77df9 100644 --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -407,7 +407,7 @@ static mfn_t hap_make_monitor_table(struct vcpu *v) m4mfn = page_to_mfn(pg); l4e = map_domain_page(m4mfn); - init_xen_l4_slots(l4e, m4mfn, d, INVALID_MFN, false); + init_xen_l4_slots(l4e, m4mfn, v, INVALID_MFN, false); unmap_domain_page(l4e); return m4mfn; diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c index 14ab7defd8..ab68dfa415 100644 --- a/xen/arch/x86/mm/paging.c +++ b/xen/arch/x86/mm/paging.c @@ -675,6 +675,20 @@ int paging_domctl(struct domain *d, struct xen_domctl_shadow_op *sc, return -EINVAL; } + if ( is_pv_domain(d) && d->arch.vcpu_pt ) + { + /* + * Turning paging off is the de-facto "make sure it is off" + * interface: the save path issues it unconditionally as + * best-effort cleanup and discards the result, so logging an + * error for it is noise on every save of a PV domain. + */ + if ( sc->op != XEN_DOMCTL_SHADOW_OP_OFF ) + gprintk(XENLOG_ERR, + "Paging not supported on PV domains with ASI\n"); + return -EOPNOTSUPP; + } + if ( resuming ? (d->arch.paging.preempt.dom != current->domain || d->arch.paging.preempt.op != sc->op) diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c index e30c6c49e1..b559db84b1 100644 --- a/xen/arch/x86/mm/shadow/common.c +++ b/xen/arch/x86/mm/shadow/common.c @@ -2361,6 +2361,17 @@ static int shadow_one_bit_enable(struct domain *d, u32 mode) return -EINVAL; } + /* + * PV shadows embed the (per-vCPU) per-domain slot in L4 shadows shared + * by all vCPUs of the domain, so shadow modes are unavailable to + * domains using per-vCPU page-tables. Toolstack requests are refused + * in paging_domctl(); the pv-l1tf tasklet can still request + * PG_SH_forced at runtime, and crashes the domain when this refusal + * reaches it. + */ + if ( is_pv_domain(d) && d->arch.vcpu_pt ) + return -EOPNOTSUPP; + mode |= PG_SH_enable; if ( d->arch.paging.total_pages < sh_min_allocation(d) ) diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c index e6fb97c4b6..0b23326214 100644 --- a/xen/arch/x86/mm/shadow/hvm.c +++ b/xen/arch/x86/mm/shadow/hvm.c @@ -760,7 +760,7 @@ mfn_t sh_make_monitor_table(const struct vcpu *v, unsigned int shadow_levels) * shadow-linear mapping will either be inserted below when creating * lower level monitor tables, or later in sh_update_cr3(). */ - init_xen_l4_slots(l4e, m4mfn, d, INVALID_MFN, false); + init_xen_l4_slots(l4e, m4mfn, v, INVALID_MFN, false); if ( shadow_levels < 4 ) { diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c index 1ae1091acd..5b7dbc12dc 100644 --- a/xen/arch/x86/mm/shadow/multi.c +++ b/xen/arch/x86/mm/shadow/multi.c @@ -974,7 +974,7 @@ sh_make_shadow(struct vcpu *v, mfn_t gmfn, u32 shadow_type) BUILD_BUG_ON(sizeof(l4_pgentry_t) != sizeof(shadow_l4e_t)); - init_xen_l4_slots(l4t, gmfn, d, smfn, (!is_pv_32bit_domain(d) && + init_xen_l4_slots(l4t, gmfn, v, smfn, (!is_pv_32bit_domain(d) && VM_ASSIST(d, m2p_strict))); unmap_domain_page(l4t); } diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index ddeb144b06..52139cffb3 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -726,7 +726,7 @@ static int __init dom0_construct(const struct boot_domain *bd) l4start = l4tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE; clear_page(l4tab); init_xen_l4_slots(l4tab, _mfn(virt_to_mfn(l4start)), - d, INVALID_MFN, true); + d->vcpu[0], INVALID_MFN, true); v->arch.guest_table = pagetable_from_paddr(__pa(l4start)); } else @@ -1048,7 +1048,11 @@ static int __init dom0_construct(const struct boot_domain *bd) } /* Activate shadow mode, if requested. Reuse the pv_l1tf tasklet. */ - if ( opt_dom0_shadow ) + if ( opt_dom0_shadow && d->arch.vcpu_pt ) + /* Shadow paging is incompatible with per-vCPU page-tables (ASI). */ + printk(XENLOG_WARNING + "Ignoring dom0=shadow: incompatible with per-vCPU page-tables\n"); + else if ( opt_dom0_shadow ) { printk("Switching dom0 to using shadow paging\n"); tasklet_schedule(&d->arch.paging.shadow.pv_l1tf_tasklet); diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index 50f2d1284a..b1d57083f2 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -127,7 +127,7 @@ static int setup_compat_l4(struct vcpu *v) mfn = page_to_mfn(pg); l4tab = map_domain_page(mfn); clear_page(l4tab); - init_xen_l4_slots(l4tab, mfn, v->domain, INVALID_MFN, false); + init_xen_l4_slots(l4tab, mfn, v, INVALID_MFN, false); unmap_domain_page(l4tab); /* This page needs to look like a pagetable so that it can be shadowed */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:49:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:49:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405528.1639022 (Exim 4.92) (envelope-from ) id 1x1haf-00074f-Kh; Wed, 02 Sep 2026 09:49:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405528.1639022; Wed, 02 Sep 2026 09:49:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1haf-00074P-Hd; Wed, 02 Sep 2026 09:49:09 +0000 Received: by outflank-mailman (input) for mailman id 1405528; Wed, 02 Sep 2026 09:49:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1had-00071c-Qh for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:49:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1had-00HNoW-7e for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:49:07 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f109-2eae-0a2a0a5409dd-0a2a450c8ef0-38 for ; Wed, 02 Sep 2026 11:49:07 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-d25034.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-f479-0a2a450c0019-d99ba50cf8a1-3 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id A314F36928F3; Wed, 2 Sep 2026 10:44:06 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 10/14] x86/domain_page: drop redundant create_perdomain_mapping() call Date: Wed, 2 Sep 2026 10:43:54 +0100 Message-ID: <20260901-asi-part2-10-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788342246-008CDA5B-4A1DBDB3/0/0 X-purgate-type: clean X-purgate-size: 3821 From: Roger Pau Monné We want to change per-domain mappings to be per-vCPU mappings. In preparation for that, we want to arrange that create_perdomain_mapping() work either with a single perdomain area, or with a per-vCPU perdomain area. One of the current calls in a domain context turns out to be unnecessary: mapcache_domain_init() pre-plumbs L1 tables over the whole inuse/garbage bitmap range (sized for the full MAPCACHE_ENTRIES capacity), without populating any data pages. The plumbing is redundant: mapcache_vcpu_init() installs the bitmap pages the domain will actually use with populate=true calls, which allocate any missing page-table structure on demand -- and since d->max_vcpus is fixed before any vCPU is created, the range those calls cover never grows. The pre-plumbed tail beyond it backs virtual addresses that are never populated at all. Drop the call. With the only fallible operation gone, mapcache_domain_init() becomes void, and arch_domain_create()'s error handling for it goes away. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Added to the series (split out of the following patch). Changes since the previously posted version: - Split out of "x86/mm: switch {create,destroy}_perdomain_mapping() domain parameter to vCPU", where the removal was folded into the parameter switch without its own rationale. --- xen/arch/x86/domain.c | 3 +-- xen/arch/x86/domain_page.c | 7 ++----- xen/arch/x86/include/asm/domain.h | 2 +- 3 files changed, 4 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index d8af06e533..efa72cd2f1 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -908,8 +908,7 @@ int arch_domain_create(struct domain *d, } else if ( is_pv_domain(d) ) { - if ( (rc = mapcache_domain_init(d)) != 0 ) - goto fail; + mapcache_domain_init(d); if ( (rc = pv_domain_initialise(d)) != 0 ) goto fail; diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index b42cf1c8cf..449d4f2a7d 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -256,7 +256,7 @@ void unmap_domain_page_irqoff(const void *ptr) do_unmap_domain_page(ptr, true); } -int mapcache_domain_init(struct domain *d) +void mapcache_domain_init(struct domain *d) { struct mapcache_domain *dcache = &d->arch.pv.mapcache; unsigned int bitmap_pages; @@ -265,7 +265,7 @@ int mapcache_domain_init(struct domain *d) #ifdef NDEBUG if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) - return 0; + return; #endif BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 + @@ -277,9 +277,6 @@ int mapcache_domain_init(struct domain *d) (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); spin_lock_init(&dcache->lock); - - return create_perdomain_mapping(d, (unsigned long)dcache->inuse, - 2 * bitmap_pages + 1, false); } int mapcache_vcpu_init(struct vcpu *v) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 5c7fad26a6..38df5c376e 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -89,7 +89,7 @@ struct mapcache_domain { unsigned long *garbage; }; -int mapcache_domain_init(struct domain *d); +void mapcache_domain_init(struct domain *d); int mapcache_vcpu_init(struct vcpu *v); /* x86/64: toggle guest between kernel and user modes. */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:49:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:49:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405527.1639017 (Exim 4.92) (envelope-from ) id 1x1haf-000728-EO; Wed, 02 Sep 2026 09:49:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405527.1639017; Wed, 02 Sep 2026 09:49:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1haf-000721-Bn; Wed, 02 Sep 2026 09:49:09 +0000 Received: by outflank-mailman (input) for mailman id 1405527; Wed, 02 Sep 2026 09:49:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1had-00071X-HH for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:49:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hac-003afr-UC for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:49:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f10a-bab6-0a2a0a5309dd-0a2a45029afe-20 for ; Wed, 02 Sep 2026 11:49:06 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-720697.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-6ca4-0a2a45020019-d99ba50ce8c0-3 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 7AC9C36928EF; Wed, 2 Sep 2026 10:44:06 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 09/14] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas Date: Wed, 2 Sep 2026 10:43:53 +0100 Message-ID: <20260901-asi-part2-9-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788342246-F1CAA2AC-EC0435F5/0/0 X-purgate-type: clean X-purgate-size: 5444 From: Roger Pau Monné We want to change per-domain mappings to be per-vCPU mappings. In preparation for that, we want to arrange that destroy_perdomain_mapping() work either with a single perdomain area, or with a per-vCPU perdomain area. The remaining callers are already in a vCPU context, so we just need to change the parameter from a domain pointer to a vCPU pointer. Since we now have a specific vCPU in mind, we have the option of using the linear page table mapping rather than map-and-walk. As in populate_perdomain_mapping(), the linear page table fast path is keyed off this_cpu(pgtable_vcpu) matching the target vCPU, which is the conditional that implies "the linear mapping area points to v's per-domain area". Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Added to the series Changes since the previously posted version: - Key the fast path off pgtable_vcpu instead of current, matching populate_perdomain_mapping(), and drop the sync_local_execstate() call. - Also convert the pv_destroy_ldt() call, added by the stash-removal batch. - Reword and retitle for clarity (was: "x86/mm: switch destroy_perdomain_mapping() parameter from domain to vCPU"). --- xen/arch/x86/include/asm/mm.h | 2 +- xen/arch/x86/mm.c | 23 ++++++++++++++++++++++- xen/arch/x86/pv/descriptor-tables.c | 2 +- xen/arch/x86/pv/domain.c | 3 +-- xen/arch/x86/x86_64/mm.c | 2 +- 5 files changed, 26 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 30eaec9179..9a8fda782e 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -605,7 +605,7 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, const mfn_t *mfn, unsigned int nr, unsigned int flags); -void destroy_perdomain_mapping(struct domain *d, unsigned long va, +void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int nr); void free_perdomain_mappings(struct domain *d); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 48d1b427c5..fc524ef0c3 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6456,10 +6456,11 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, local_irq_restore(irq_flags); } -void destroy_perdomain_mapping(struct domain *d, unsigned long va, +void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, unsigned int nr) { const l3_pgentry_t *l3tab, *pl3e; + const struct domain *d = v->domain; ASSERT(va >= PERDOMAIN_VIRT_START && va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); @@ -6468,6 +6469,26 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va, if ( !d->arch.perdomain_l3_pg ) return; + if ( likely(this_cpu(pgtable_vcpu) == v) ) + { + l1_pgentry_t *pl1e; + + /* + * Fast path: v's page-tables are loaded on this pCPU, so the L1 + * entries can be zapped using the recursive linear mappings. + */ + pl1e = &__linear_l1_table[l1_linear_offset(va)]; + + for ( ; nr--; pl1e++ ) + { + if ( perdomain_l1e_needs_freeing(*pl1e) ) + free_domheap_page(l1e_get_page(*pl1e)); + l1e_write(pl1e, l1e_empty()); + } + + return; + } + l3tab = __map_domain_page(d->arch.perdomain_l3_pg); pl3e = l3tab + l3_table_offset(va); diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c index 261bf29c90..0c1ea4ce3a 100644 --- a/xen/arch/x86/pv/descriptor-tables.c +++ b/xen/arch/x86/pv/descriptor-tables.c @@ -27,7 +27,7 @@ bool pv_destroy_ldt(struct vcpu *v) ASSERT(v == current || !vcpu_cpu_dirty(v)); - destroy_perdomain_mapping(v->domain, LDT_VIRT_START(v), nr_frames); + destroy_perdomain_mapping(v, LDT_VIRT_START(v), nr_frames); for ( i = 0; i < nr_frames; i++ ) { diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index b936ca9b26..40b834e1a4 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -319,8 +319,7 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v) static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v) { - destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v), - 1U << GDT_LDT_VCPU_SHIFT); + destroy_perdomain_mapping(v, GDT_VIRT_START(v), 1U << GDT_LDT_VCPU_SHIFT); } void pv_vcpu_destroy(struct vcpu *v) diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index ffeda06e08..aa74acec82 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -738,7 +738,7 @@ int setup_compat_arg_xlat(struct vcpu *v) void free_compat_arg_xlat(struct vcpu *v) { - destroy_perdomain_mapping(v->domain, ARG_XLAT_START(v), + destroy_perdomain_mapping(v, ARG_XLAT_START(v), PFN_UP(COMPAT_ARG_XLAT_SIZE)); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:49:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:49:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405529.1639026 (Exim 4.92) (envelope-from ) id 1x1haf-00079g-Rn; Wed, 02 Sep 2026 09:49:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405529.1639026; Wed, 02 Sep 2026 09:49:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1haf-00078g-Ou; Wed, 02 Sep 2026 09:49:09 +0000 Received: by outflank-mailman (input) for mailman id 1405529; Wed, 02 Sep 2026 09:49:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1had-00071e-T4 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:49:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1had-00HNoW-9z for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:49:07 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f112-2eae-0a2a0a5409dd-0a2a4507ac00-8 for ; Wed, 02 Sep 2026 11:49:07 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-b4ea-0a2a45070019-d99ba50cedd2-1 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id CD25936928DF; Wed, 2 Sep 2026 10:44:05 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 05/14] x86/pv: update guest LDT mappings using {populate,destroy}_perdomain_mapping() Date: Wed, 2 Sep 2026 10:43:49 +0100 Message-ID: <20260901-asi-part2-5-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788342246-3C610AE4-9174E2E5/0/0 X-purgate-type: clean X-purgate-size: 7040 From: Roger Pau Monné Until two patches ago, update_xen_slot_in_full_gdt() used the stashed pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vCPU's page tables with Xen's GDT; this was previously necessary because map_domain_page() couldn't be called in a context switch. Having a handy pointer to an always-mapped version of the GDT/LDT L1 table, other sites which modify the table started using it for convenience, even if they weren't called from within a context switch. These include pv_map_ldt_shadow_page() and pv_destroy_ldt(). Continue the process of switching users of the stashed reference to use populate_perdomain_mapping() instead. pv_map_ldt_shadow_page() is, by definition, always modifying the currently-running vCPU: it runs from the #PF handler for a descriptor fetch on the guest's behalf, and running the guest implies its page tables are loaded. So it could simply write the linear recursive mappings directly. Go through populate_perdomain_mapping() anyway, to keep a single writer for the per-domain area. For pv_destroy_ldt(), use destroy_perdomain_mapping(). Previously, pv_destroy_ldt() used the L1 LDT entries themselves to determine which MFNs to drop type and count references to. Rather than reading from the stashed L1, keep the MFNs corresponding to L1 slots in an array in the vCPU structure, as we do in the GDT case. (Note that unlike the GDT case, these are not part of a public ABI, so can be mfn_t, avoiding a recast-and-copy.) Note that mappings_dropped (the return value of pv_destroy_ldt()) now reflects the *number of valid MFNs in this array*, not *the number of non-empty L1 entries*. This introduces an invariant we must maintain: pv_map_ldt_shadow_page() writes both the array entry and the mapping, and pv_destroy_ldt() clears both, so the two stay in lockstep. Also note that, unlike pv_destroy_gdt() from the previous patch, pv_destroy_ldt() doesn't fill in the values with zero_l1e (see 61031e64d3), so there's no change here. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Reword the commit message Changes since the previously posted version: - Initialise ldt_frames[] ahead of the first fail-able initialisation step. - Call destroy_perdomain_mapping() with its existing domain parameter; the switch to a vCPU parameter moves to a future patch. - Use populate_perdomain_mapping() in pv_map_ldt_shadow_page() rather than open-coding the linear-map write; retitle accordingly. - Comment the INVALID_MFN skip in pv_destroy_ldt(): the LDT is demand-faulted, so its pages may be sparsely mapped (Alejandro's question on v2). - Rewrite commit message (including describing the ldt_frames[] array's role directly, as Jan asked). --- xen/arch/x86/include/asm/domain.h | 2 ++ xen/arch/x86/pv/descriptor-tables.c | 20 +++++++++++--------- xen/arch/x86/pv/domain.c | 4 ++++ xen/arch/x86/pv/mm.c | 16 ++++++++++++---- 4 files changed, 29 insertions(+), 13 deletions(-) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 2d0a915410..61a9fe00f0 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -541,6 +541,8 @@ struct pv_vcpu struct trap_info *trap_ctxt; unsigned long gdt_frames[FIRST_RESERVED_GDT_PAGE]; + /* Max LDT entries is 8192, so 8192 * 8 = 64KiB (16 pages). */ + mfn_t ldt_frames[16]; unsigned long ldt_base; unsigned int gdt_ents, ldt_ents; diff --git a/xen/arch/x86/pv/descriptor-tables.c b/xen/arch/x86/pv/descriptor-tables.c index 5dda5bffe3..261bf29c90 100644 --- a/xen/arch/x86/pv/descriptor-tables.c +++ b/xen/arch/x86/pv/descriptor-tables.c @@ -20,28 +20,30 @@ */ bool pv_destroy_ldt(struct vcpu *v) { - l1_pgentry_t *pl1e; + const unsigned int nr_frames = ARRAY_SIZE(v->arch.pv.ldt_frames); unsigned int i, mappings_dropped = 0; - struct page_info *page; ASSERT(!in_irq()); ASSERT(v == current || !vcpu_cpu_dirty(v)); - pl1e = pv_ldt_ptes(v); + destroy_perdomain_mapping(v->domain, LDT_VIRT_START(v), nr_frames); - for ( i = 0; i < 16; i++ ) + for ( i = 0; i < nr_frames; i++ ) { - if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) ) - continue; + mfn_t mfn = v->arch.pv.ldt_frames[i]; + struct page_info *page; - page = l1e_get_page(pl1e[i]); - l1e_write(&pl1e[i], l1e_empty()); - mappings_dropped++; + /* The LDT is demand-faulted, so its pages may be sparsely mapped. */ + if ( mfn_eq(mfn, INVALID_MFN) ) + continue; + v->arch.pv.ldt_frames[i] = INVALID_MFN; + page = mfn_to_page(mfn); ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page); ASSERT_PAGE_IS_DOMAIN(page, v->domain); put_page_and_type(page); + mappings_dropped++; } return mappings_dropped; diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index 0c42ae58aa..7ddab1949f 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -340,10 +340,14 @@ void pv_vcpu_destroy(struct vcpu *v) int pv_vcpu_initialise(struct vcpu *v) { struct domain *d = v->domain; + unsigned int i; int rc; ASSERT(!is_idle_domain(d)); + for ( i = 0; i < ARRAY_SIZE(v->arch.pv.ldt_frames); i++ ) + v->arch.pv.ldt_frames[i] = INVALID_MFN; + rc = pv_create_gdt_ldt_l1tab(v); if ( rc ) return rc; diff --git a/xen/arch/x86/pv/mm.c b/xen/arch/x86/pv/mm.c index 5378299b8c..da280d7757 100644 --- a/xen/arch/x86/pv/mm.c +++ b/xen/arch/x86/pv/mm.c @@ -53,7 +53,8 @@ bool pv_map_ldt_shadow_page(unsigned int offset) struct vcpu *curr = current; struct domain *currd = curr->domain; struct page_info *page; - l1_pgentry_t gl1e, *pl1e, nl1e; + l1_pgentry_t gl1e; + mfn_t mfn; unsigned long linear = curr->arch.pv.ldt_base + offset; BUG_ON(in_irq()); @@ -87,10 +88,17 @@ bool pv_map_ldt_shadow_page(unsigned int offset) return false; } - pl1e = &pv_ldt_ptes(curr)[offset >> PAGE_SHIFT]; - nl1e = l1e_from_pfn(l1e_get_pfn(gl1e), __PAGE_HYPERVISOR_RW); + mfn = page_to_mfn(page); + curr->arch.pv.ldt_frames[offset >> PAGE_SHIFT] = mfn; - l1e_write(pl1e, nl1e); + /* + * Running the guest implies its page-tables are loaded, so the linear + * mappings would do; go through the interface anyway to keep a single + * writer for the per-domain area. + */ + populate_perdomain_mapping(curr, + LDT_VIRT_START(curr) + (offset & PAGE_MASK), + &mfn, 1, __PAGE_HYPERVISOR_RW); return true; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:49:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:49:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405531.1639040 (Exim 4.92) (envelope-from ) id 1x1hag-0007I6-F5; Wed, 02 Sep 2026 09:49:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405531.1639040; Wed, 02 Sep 2026 09:49:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hag-0007Fv-8N; Wed, 02 Sep 2026 09:49:10 +0000 Received: by outflank-mailman (input) for mailman id 1405531; Wed, 02 Sep 2026 09:49:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hae-00071v-Ip for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:49:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1had-00HNrp-Vs for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:49:07 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f112-2eae-0a2a0a5409dd-0a2a4507ac00-14 for ; Wed, 02 Sep 2026 11:49:07 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-b4ea-0a2a45070019-d99ba50cfdf1-3 for ; Wed, 02 Sep 2026 11:44:07 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id F407636928FC; Wed, 2 Sep 2026 10:44:06 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 12/14] x86/spec-ctrl: introduce Address Space Isolation command line option Date: Wed, 2 Sep 2026 10:43:56 +0100 Message-ID: <20260901-asi-part2-12-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788342247-A6EDEAE4-7BC14EE1/0/0 X-purgate-type: clean X-purgate-size: 10768 From: Roger Pau Monné Introduce the `asi=` command line option, and the opt_vcpu_pt_{pv,hwdom,hvm} knobs plus the per-domain d->arch.vcpu_pt setting it controls. The option is introduced ahead of the functionality it enables, so that the newly added code can be keyed on it from the start; all knobs currently default to off, and enabling any of them taints the boot with a "not functional, development purposes only" warning. XPTI and per-vCPU page-tables are mutually exclusive (they are different answers to the same problem, and the entry paths can only be built for one of them at a time), so an explicit XPTI request takes precedence over vCPU-PT, per axis: xpti=dom0 clears the hardware domain vCPU-PT knob (when dom0 is PV), and xpti=domu clears the PV domU one. When XPTI is left to default, it is turned off for those domain kinds that use vCPU-PT instead. The boot log gains "ASI features for ..." lines for Dom0, HVM and PV domains, so hardware-domain-only configurations remain visible, and the XPTI line is printed unconditionally: users expecting to assert the state of XPTI should not need to derive it from the ASI configuration. Further per-mechanism tokens arrive with their mechanisms in later patches. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Added to the series Changes since the previously posted version: - Make the XPTI exclusion per-axis: an explicit xpti=dom0 previously cleared only the PV domU vCPU-PT knob, leaving dom0 with both XPTI and vCPU-PT enabled. - Include the hardware domain in the development warning and the boot log summary. - Print the XPTI status line unconditionally. - Make the opt_vcpu_pt_* knobs plain booleans preinitialised to false, dropping the late -1 resolution. - Documentation: mention possible protection against unmitigated attacks, use {pv,hvm} notation in the synopsis, and state that pv=/hvm= do not affect the hardware domain. - Rewrite the commit message. --- docs/misc/xen-command-line.pandoc | 24 ++++++ xen/arch/x86/include/asm/domain.h | 3 + xen/arch/x86/include/asm/spec_ctrl.h | 2 + xen/arch/x86/spec_ctrl.c | 107 ++++++++++++++++++++++++++- 4 files changed, 134 insertions(+), 2 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 1c711fa980..834f6c57f2 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -202,6 +202,30 @@ to appropriate auditing by Xen. Argo is disabled by default. This option is disabled by default, to protect domains from a DoS by a buggy or malicious other domain spamming the ring. +### asi (x86) +> `= List of [ , pv=, hvm=, +> vcpu-pt= | vcpu-pt={pv,hvm}= ]` + +> Default: `false` + +Offers control over whether the hypervisor will engage in Address Space +Isolation, by not having potentially sensitive information permanently mapped +in the VMM page-tables. Using this option might avoid the need to apply +mitigations for certain speculative related attacks, at the cost of mapping +sensitive information on-demand. It might also offer some protection against +unmitigated speculation-related attacks. + +* `pv=` and `hvm=` sub-options allow enabling for specific guest types; they + do not affect the hardware domain, which follows the whole-feature forms + (the plain boolean, or an un-suffixed `vcpu-pt=`). + +**WARNING: manual de-selection of enabled options will invalidate any +protection offered by the feature. The fine grained options provided below +are meant to be used for debugging purposes only.** + +* `vcpu-pt` ensures each vCPU uses a unique top-level page-table and sets up + a virtual address space region to map memory on a per-vCPU basis. + ### asid (x86) > `= ` diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 38df5c376e..fdf7b205ea 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -472,6 +472,9 @@ struct arch_domain /* Don't unconditionally inject #GP for unhandled MSRs. */ bool msr_relaxed; + /* Use a per-vCPU root pt, and switch per-domain slot to per-vCPU. */ + bool vcpu_pt; + /* Emulated devices enabled bitmap. */ uint32_t emulation_flags; } __cacheline_aligned; diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h index 8f82533c41..770c24f6a0 100644 --- a/xen/arch/x86/include/asm/spec_ctrl.h +++ b/xen/arch/x86/include/asm/spec_ctrl.h @@ -87,6 +87,8 @@ extern uint8_t default_scf; extern int8_t opt_xpti_hwdom, opt_xpti_domu; +extern bool opt_vcpu_pt_pv, opt_vcpu_pt_hwdom, opt_vcpu_pt_hvm; + extern bool cpu_has_bug_l1tf; extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu; extern bool opt_bp_spec_reduce; diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index bc8538a56f..55a02212a9 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -86,6 +86,14 @@ bool __ro_after_init opt_bp_spec_reduce = true; static bool __initdata opt_ibpb_alt; +/* + * Use a per-vCPU root page-table and switch the per-domain slot to per-vCPU. + * Off by default until the feature is complete. + */ +bool __ro_after_init opt_vcpu_pt_hvm; +bool __ro_after_init opt_vcpu_pt_hwdom; +bool __ro_after_init opt_vcpu_pt_pv; + static int __init cf_check parse_spec_ctrl(const char *s) { const char *ss; @@ -383,6 +391,18 @@ int8_t __ro_after_init opt_xpti_domu = -1; static __init void xpti_init_default(void) { + if ( !opt_dom0_pvh && opt_xpti_hwdom == 1 && opt_vcpu_pt_hwdom ) + { + printk(XENLOG_ERR + "XPTI incompatible with per-vCPU page-tables, disabling Dom0 vCPU-PT\n"); + opt_vcpu_pt_hwdom = false; + } + if ( opt_xpti_domu == 1 && opt_vcpu_pt_pv ) + { + printk(XENLOG_ERR + "XPTI incompatible with per-vCPU page-tables, disabling PV DomU vCPU-PT\n"); + opt_vcpu_pt_pv = false; + } if ( (boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) || cpu_has_rdcl_no ) { @@ -394,9 +414,9 @@ static __init void xpti_init_default(void) else { if ( opt_xpti_hwdom < 0 ) - opt_xpti_hwdom = 1; + opt_xpti_hwdom = !opt_vcpu_pt_hwdom; if ( opt_xpti_domu < 0 ) - opt_xpti_domu = 1; + opt_xpti_domu = !opt_vcpu_pt_pv; } } @@ -487,6 +507,66 @@ static int __init cf_check parse_pv_l1tf(const char *s) } custom_param("pv-l1tf", parse_pv_l1tf); +static int __init cf_check parse_asi(const char *s) +{ + const char *ss; + int val, rc = 0; + + /* Interpret 'asi' alone in its positive boolean form. */ + if ( *s == '\0' ) + opt_vcpu_pt_pv = opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = true; + + do { + ss = strchr(s, ','); + if ( !ss ) + ss = strchr(s, '\0'); + + val = parse_bool(s, ss); + switch ( val ) + { + case 0: + case 1: + opt_vcpu_pt_pv = opt_vcpu_pt_hwdom = opt_vcpu_pt_hvm = val; + break; + + default: + if ( (val = parse_boolean("pv", s, ss)) >= 0 ) + opt_vcpu_pt_pv = val; + else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + opt_vcpu_pt_hvm = val; + else if ( (val = parse_boolean("vcpu-pt", s, ss)) != -1 ) + { + switch ( val ) + { + case 1: + case 0: + opt_vcpu_pt_pv = opt_vcpu_pt_hvm = opt_vcpu_pt_hwdom = val; + break; + + case -2: + s += strlen("vcpu-pt="); + if ( (val = parse_boolean("pv", s, ss)) >= 0 ) + opt_vcpu_pt_pv = val; + else if ( (val = parse_boolean("hvm", s, ss)) >= 0 ) + opt_vcpu_pt_hvm = val; + else + default: + rc = -EINVAL; + break; + } + } + else if ( *s ) + rc = -EINVAL; + break; + } + + s = ss + 1; + } while ( *ss ); + + return rc; +} +custom_param("asi", parse_asi); + static void __init print_details(enum ind_thunk thunk) { unsigned int _7d0 = 0, _7d2 = 0, e8b = 0, e21a = 0, e21c = 0, max = 0, tmp; @@ -680,6 +760,20 @@ static void __init print_details(enum ind_thunk thunk) opt_pv_l1tf_hwdom ? "enabled" : "disabled", opt_pv_l1tf_domu ? "enabled" : "disabled"); #endif + + printk(" ASI features for Dom0:%s%s\n", + opt_vcpu_pt_hwdom ? "" : " None", + opt_vcpu_pt_hwdom ? " vCPU-PT" : ""); +#ifdef CONFIG_HVM + printk(" ASI features for HVM VMs:%s%s\n", + opt_vcpu_pt_hvm ? "" : " None", + opt_vcpu_pt_hvm ? " vCPU-PT" : ""); +#endif +#ifdef CONFIG_PV + printk(" ASI features for PV VMs:%s%s\n", + opt_vcpu_pt_pv ? "" : " None", + opt_vcpu_pt_pv ? " vCPU-PT" : ""); +#endif } static bool __init check_smt_enabled(void) @@ -1866,6 +1960,10 @@ void spec_ctrl_init_domain(struct domain *d) if ( pv ) d->arch.pv.xpti = is_hardware_domain(d) ? opt_xpti_hwdom : opt_xpti_domu; + + d->arch.vcpu_pt = is_hardware_domain(d) ? opt_vcpu_pt_hwdom + : pv ? opt_vcpu_pt_pv + : opt_vcpu_pt_hvm; } void __init init_speculation_mitigations(void) @@ -2158,6 +2256,11 @@ void __init init_speculation_mitigations(void) hw_smt_enabled && default_xen_spec_ctrl ) setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE); + if ( opt_vcpu_pt_pv || opt_vcpu_pt_hwdom || opt_vcpu_pt_hvm ) + warning_add( + "Address Space Isolation is not functional, this option is\n" + "intended to be used only for development purposes.\n"); + xpti_init_default(); l1tf_calculations(); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:49:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:49:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405530.1639035 (Exim 4.92) (envelope-from ) id 1x1hag-0007D4-71; Wed, 02 Sep 2026 09:49:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405530.1639035; Wed, 02 Sep 2026 09:49:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1haf-0007BO-Vk; Wed, 02 Sep 2026 09:49:09 +0000 Received: by outflank-mailman (input) for mailman id 1405530; Wed, 02 Sep 2026 09:49:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1had-00071f-Ue for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:49:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1had-00HNoW-BK for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:49:07 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f112-2eae-0a2a0a5409dd-0a2a4507ac00-10 for ; Wed, 02 Sep 2026 11:49:07 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-b4ea-0a2a45070019-d99ba50cfdf1-1 for ; Wed, 02 Sep 2026 11:44:06 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 2B0F036928E9; Wed, 2 Sep 2026 10:44:06 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 07/14] x86/mm: simplify create_perdomain_mapping() interface Date: Wed, 2 Sep 2026 10:43:51 +0100 Message-ID: <20260901-asi-part2-7-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788342246-344CBAE4-F05E644D/0/0 X-purgate-type: clean X-purgate-size: 12132 From: Roger Pau Monné create_perdomain_mapping()'s interface is richer than any caller needs. The paging structure for the requested range is built to a depth selected by the pl1tab and ppg arguments, each of which distinguishes NULL from NIL() from a real pointer: - nr == 0: only ensure the per-domain L3 exists; nothing else is allocated, and the other arguments are ignored. - pl1tab == a pointer: allocate the L1 tables covering the range from the *xenheap*, and return their (stable, direct-map) addresses in the array -- the mode that existed to build the GDT/LDT stash. - pl1tab == NIL(): allocate the L1 tables from the domain heap, and return nothing. - pl1tab == NULL: do not plumb L1 tables for their own sake (they are still allocated on demand if data-page population requires them). - ppg == a pointer: allocate and install zeroed data pages across the range, and return their struct page_info pointers in the array. - ppg == NIL(): allocate and install the zeroed data pages, but hand nothing back; the pages are reachable only through the mapping. - ppg == NULL: do not allocate data pages. - both NULL, nr > 0: stop after the slot's L2; do not plumb L1 tables at all. Very few of these modes have users now. The last user of the pl1tab capture mode was removed when we removed the GDT/LDT stash. The ppg capture mode never had any users. Nothing uses the both-NULL L2-only mode with nr != 0. What remains is exactly one bit of information: whether the caller wants the range populated with zeroed, area-owned data pages, or merely plumbed down to the L1 tables, ready for populate_perdomain_mapping() to install caller-owned pages. Replace the two arguments with a boolean expressing that bit. With the stashing mode gone the NIL()/IS_NIL() macros lose their last user, so drop them as well; and document the resulting interface. No caller changes behaviour: every existing call maps onto the boolean exactly. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Changes in v2: - Describe, in the mode enumeration, which heap each pl1tab mode allocates the L1 tables from (capture mode: xenheap; NIL(): the domain heap). With "x86/mm: allocate the per-domain page-tables from the xenheap" dropped from the series, upstream's heap split is back in force at this point, and the previous patch's message refers to it. Changes since the previously posted version: - Drop the now-unused NIL()/IS_NIL() macros as requested during review - Describe the prior interface in the commit message and add a doc comment for the simplified one. --- xen/arch/x86/domain_page.c | 10 +++--- xen/arch/x86/hvm/hvm.c | 2 +- xen/arch/x86/include/asm/mm.h | 6 +--- xen/arch/x86/mm.c | 67 ++++++++++++++++------------------- xen/arch/x86/pv/domain.c | 4 +-- xen/arch/x86/x86_64/mm.c | 3 +- 6 files changed, 39 insertions(+), 53 deletions(-) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 1fc1580e62..b42cf1c8cf 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -279,8 +279,7 @@ int mapcache_domain_init(struct domain *d) spin_lock_init(&dcache->lock); return create_perdomain_mapping(d, (unsigned long)dcache->inuse, - 2 * bitmap_pages + 1, - NIL(l1_pgentry_t *), NULL); + 2 * bitmap_pages + 1, false); } int mapcache_vcpu_init(struct vcpu *v) @@ -297,16 +296,15 @@ int mapcache_vcpu_init(struct vcpu *v) if ( ents > dcache->entries ) { /* Populate page tables. */ - int rc = create_perdomain_mapping(d, MAPCACHE_VIRT_START, ents, - NIL(l1_pgentry_t *), NULL); + int rc = create_perdomain_mapping(d, MAPCACHE_VIRT_START, ents, false); /* Populate bit maps. */ if ( !rc ) rc = create_perdomain_mapping(d, (unsigned long)dcache->inuse, - nr, NULL, NIL(struct page_info *)); + nr, true); if ( !rc ) rc = create_perdomain_mapping(d, (unsigned long)dcache->garbage, - nr, NULL, NIL(struct page_info *)); + nr, true); if ( rc ) return rc; diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 9a4147b62e..a6e0818468 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -620,7 +620,7 @@ int hvm_domain_initialise(struct domain *d, INIT_LIST_HEAD(&d->arch.hvm.mmcfg_regions); INIT_LIST_HEAD(&d->arch.hvm.msix_tables); - rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL); + rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, false); if ( rc ) goto fail; diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 1888807394..30eaec9179 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -600,12 +600,8 @@ long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); -#define NIL(type) ((type *)-sizeof(type)) -#define IS_NIL(ptr) (!((uintptr_t)(ptr) + sizeof(*(ptr)))) - int create_perdomain_mapping(struct domain *d, unsigned long va, - unsigned int nr, l1_pgentry_t **pl1tab, - struct page_info **ppg); + unsigned int nr, bool populate); void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, const mfn_t *mfn, unsigned int nr, unsigned int flags); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 552559ecf1..48d1b427c5 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6211,9 +6211,31 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e) (_PAGE_PRESENT | _PAGE_AVAIL0); } +/* + * Ensure the paging structure for [va, va + nr * PAGE_SIZE) of d's + * per-domain area is in place, allocating whichever levels are missing: + * the (domain-wide) L3 root, the slot's L2, and all L1 tables covering + * the range. All allocations come from the domain heap. The range must + * lie within a single per-domain slot (one L3 entry), and already-present + * levels and entries are left untouched, so calls are idempotent over + * existing ranges. + * + * nr == 0: only ensure the per-domain L3 itself exists; populate is + * ignored. Used to set the area up before any sub-range is known. + * + * populate == false: stop once the L1 tables are in place. The range is + * then ready for caller-owned pages to be mapped and unmapped via + * populate_perdomain_mapping() / destroy_perdomain_mapping(), which only + * fill existing tables and treat missing structure as a bug. + * + * populate == true: additionally install a freshly allocated, zeroed page + * at every not-yet-present entry in the range. Such pages are marked + * _PAGE_AVAIL0, "owned by the per-domain area": teardown frees them (see + * perdomain_l1e_needs_freeing()), whereas caller-owned mappings are only + * ever unmapped. + */ int create_perdomain_mapping(struct domain *d, unsigned long va, - unsigned int nr, l1_pgentry_t **pl1tab, - struct page_info **ppg) + unsigned int nr, bool populate) { struct page_info *pg; l3_pgentry_t *l3tab; @@ -6262,55 +6284,32 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, unmap_domain_page(l3tab); - if ( !pl1tab && !ppg ) - { - unmap_domain_page(l2tab); - return 0; - } - for ( l1tab = NULL; !rc && nr--; ) { l2_pgentry_t *pl2e = l2tab + l2_table_offset(va); if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) ) { - if ( pl1tab && !IS_NIL(pl1tab) ) - { - l1tab = alloc_xenheap_pages(0, MEMF_node(domain_to_node(d))); - if ( !l1tab ) - { - rc = -ENOMEM; - break; - } - ASSERT(!pl1tab[l2_table_offset(va)]); - pl1tab[l2_table_offset(va)] = l1tab; - pg = virt_to_page(l1tab); - } - else + pg = alloc_domheap_page(d, MEMF_no_owner); + if ( !pg ) { - pg = alloc_domheap_page(d, MEMF_no_owner); - if ( !pg ) - { - rc = -ENOMEM; - break; - } - l1tab = __map_domain_page(pg); + rc = -ENOMEM; + break; } + l1tab = __map_domain_page(pg); clear_page(l1tab); *pl2e = l2e_from_page(pg, __PAGE_HYPERVISOR_RW); } else if ( !l1tab ) l1tab = map_l1t_from_l2e(*pl2e); - if ( ppg && + if ( populate && !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRESENT) ) { pg = alloc_domheap_page(d, MEMF_no_owner); if ( pg ) { clear_domain_page(page_to_mfn(pg)); - if ( !IS_NIL(ppg) ) - *ppg++ = pg; l1tab[l1_table_offset(va)] = l1e_from_page(pg, __PAGE_HYPERVISOR_RW | _PAGE_AVAIL0); l2e_add_flags(*pl2e, _PAGE_AVAIL0); @@ -6322,7 +6321,6 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, va += PAGE_SIZE; if ( rc || !nr || !l1_table_offset(va) ) { - /* Note that this is a no-op for the alloc_xenheap_page() case. */ unmap_domain_page(l1tab); l1tab = NULL; } @@ -6543,10 +6541,7 @@ void free_perdomain_mappings(struct domain *d) unmap_domain_page(l1tab); } - if ( is_xen_heap_page(l1pg) ) - free_xenheap_page(page_to_virt(l1pg)); - else - free_domheap_page(l1pg); + free_domheap_page(l1pg); } unmap_domain_page(l2tab); diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index 35d1761c9c..15a8238aff 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -314,9 +314,7 @@ int switch_compat(struct domain *d) static int pv_create_gdt_ldt_l1tab(struct vcpu *v) { return create_perdomain_mapping(v->domain, GDT_VIRT_START(v), - 1U << GDT_LDT_VCPU_SHIFT, - NIL(l1_pgentry_t *), - NULL); + 1U << GDT_LDT_VCPU_SHIFT, false); } static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v) diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 8eadab7933..ffeda06e08 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -733,8 +733,7 @@ void __init zap_low_mappings(void) int setup_compat_arg_xlat(struct vcpu *v) { return create_perdomain_mapping(v->domain, ARG_XLAT_START(v), - PFN_UP(COMPAT_ARG_XLAT_SIZE), - NULL, NIL(struct page_info *)); + PFN_UP(COMPAT_ARG_XLAT_SIZE), true); } void free_compat_arg_xlat(struct vcpu *v) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:49:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:49:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405532.1639062 (Exim 4.92) (envelope-from ) id 1x1haj-00088O-Vq; Wed, 02 Sep 2026 09:49:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405532.1639062; Wed, 02 Sep 2026 09:49:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1haj-00088C-S1; Wed, 02 Sep 2026 09:49:13 +0000 Received: by outflank-mailman (input) for mailman id 1405532; Wed, 02 Sep 2026 09:49:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hai-00085T-NF for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:49:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hai-003afr-3j for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:49:12 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f10a-bab6-0a2a0a5309dd-0a2a45029afe-34 for ; Wed, 02 Sep 2026 11:49:12 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-720697.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-6ca4-0a2a45020019-d99ba50ce8c0-7 for ; Wed, 02 Sep 2026 11:44:07 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id 2D56736928FE; Wed, 2 Sep 2026 10:44:07 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: George Dunlap , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v2 13/14] x86/pv: clear the XPTI root_pgt per-domain slot on context-switch out Date: Wed, 2 Sep 2026 10:43:57 +0100 Message-ID: <20260901-asi-part2-13-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788342247-313CC2AC-CB9C2D3F/0/0 X-purgate-type: clean X-purgate-size: 3045 From: George Dunlap XPTI maintains a per-pCPU root page table (root_pgt): a restricted L4, with Xen largely unmapped, that an XPTI domain's guest context actually runs on. Its guest mappings are copied in on the way back to guest context; its per-domain slot is written by paravirt_ctxt_switch_to(), so that it follows whichever domain is scheduled onto the pCPU. Nothing ever clears the slot, however. When the pCPU switches from an XPTI PV vCPU to one that does not refresh the slot -- an HVM vCPU, or the idle vCPU after a lazy state flush -- the last PV domain's per-domain L3 remains referenced from root_pgt. The reference isn't cleared on domain destruction, so could even point to an already freed page. In theory, that slot should never be walked in this state; but it's just generally safer not to leave dangling references around. Consider that cleanup_cpu_root_pgt() frees pagetables by walking root_pgt on CPU offline. Currently it correctly leaves slot 260 alone; but one could easily imagine a mistake in which slot 260 is walked erroneously. Clear the slot in paravirt_ctxt_switch_from(), making the maintenance a pair: cleared on the way out, installed on the way in. The slot is now populated only while the vCPU using it runs, and an erroneous walk in any other state faults cleanly. This change also makes robust behavior simpler when we add per-vCPU areas in a subsequent patch. Assisted-by: Claude Code:claude-fable-5 Signed-off-by: George Dunlap --- Changes in v2: - New patch. --- xen/arch/x86/domain.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 1f75d44fe0..79555e6964 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2006,8 +2006,18 @@ static void save_segments(struct vcpu *v) void cf_check paravirt_ctxt_switch_from(struct vcpu *v) { + root_pgentry_t *root_pgt = this_cpu(root_pgt); + save_segments(v); + /* + * Clear the XPTI per-domain slot: it is installed on the way in by + * paravirt_ctxt_switch_to(), and must not linger while another vCPU + * runs. + */ + if ( root_pgt ) + root_pgt[root_table_offset(PERDOMAIN_VIRT_START)] = l4e_empty(); + /* * Disable debug breakpoints. We do this aggressively because if we switch * to an HVM guest we may load DR0-DR3 with values that can cause #DE @@ -2022,6 +2032,12 @@ void cf_check paravirt_ctxt_switch_to(struct vcpu *v) { root_pgentry_t *root_pgt = this_cpu(root_pgt); + /* + * If XPTI is active, install the incoming domain's per-domain area + * in the per-domain slot of the L4 we run on while in guest mode. + * The slot was cleared on the way out (see + * paravirt_ctxt_switch_from()). + */ if ( root_pgt ) root_pgt[root_table_offset(PERDOMAIN_VIRT_START)] = l4e_from_page(v->domain->arch.perdomain_l3_pg, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:49:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:49:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405533.1639069 (Exim 4.92) (envelope-from ) id 1x1hak-0008Be-Dg; Wed, 02 Sep 2026 09:49:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405533.1639069; Wed, 02 Sep 2026 09:49:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hak-0008BL-6Y; Wed, 02 Sep 2026 09:49:14 +0000 Received: by outflank-mailman (input) for mailman id 1405533; Wed, 02 Sep 2026 09:49:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hai-000869-Vw for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:49:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hai-003afr-CK for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:49:12 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f10a-bab6-0a2a0a5309dd-0a2a45029afe-40 for ; Wed, 02 Sep 2026 11:49:12 +0200 Received: from [217.155.165.12] (helo=Georges-MacBook-Pro-2.fritz.box) by tlsNG-720697.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a97efe6-6ca4-0a2a45020019-d99ba50ce8c0-5 for ; Wed, 02 Sep 2026 11:44:07 +0200 Received: by Georges-MacBook-Pro-2.fritz.box (Postfix, from userid 501) id CF50036928F7; Wed, 2 Sep 2026 10:44:06 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: George Dunlap To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap Subject: [PATCH v2 11/14] x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas Date: Wed, 2 Sep 2026 10:43:55 +0100 Message-ID: <20260901-asi-part2-11-ecc269f268b7@xenproject.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788342247-F34BE2AC-9385394E/0/0 X-purgate-type: clean X-purgate-size: 9636 From: Roger Pau Monné We want to change per-domain mappings to be per-vCPU mappings. In preparation for that, we want to arrange that create_perdomain_mapping() work either with a single perdomain area, or with a per-vCPU perdomain area. Most of the remaining callers are already in a vCPU context. This is no accident: the perdomain area has always been laid out in per-vCPU slices -- each vCPU has its own GDT/LDT window, its own COMPAT_ARG_XLAT pages, its own window of mapcache entries -- and each vCPU's slice is set up as that vCPU is created. For these callers, we just need to change the parameter from a domain pointer to a vCPU pointer. Once the perdomain area itself becomes per-vCPU, the same calls will populate the owning vCPU's own area rather than slices of a shared one. One exception is the call in hvm_domain_initialise(). An HVM vCPU's monitor table is created during vCPU initialisation, and init_xen_l4_slots() stamps the perdomain slot into it at that point -- far earlier than for PV, where the Xen slots are written only once guest page tables are built. hvm_domain_initialise() therefore had an explicit create_perdomain_mapping() call just to make the perdomain root exist ahead of that. Move it to arch_vcpu_create(), covering HVM and PV alike. With a single shared area, the call allocates at most once per domain; but once each vCPU has its own perdomain area, this is the call that will allocate every vCPU's root -- PV included -- before any page tables referencing it are built. vCPU creation is where the call must end up; move it there directly. For PV guests nothing observable changes: the root was already being created during vCPU creation as a side effect (by mapcache_vcpu_init(), or failing that pv_create_gdt_ldt_l1tab()); it now merely becomes explicit. Note that we cannot yet do a parallel movement of free_perdomain_mappings(): the per-domain page-table hierarchy is still a single domain-wide structure shared by all vCPUs, so tearing it down from a per-vCPU path would pull the mappings out from under sibling vCPUs (e.g. on a partially failed, retryable XEN_DOMCTL_max_vcpus), and vCPU-create error paths can rely on domain destruction to free a partially set up hierarchy. Teardown will move to vCPU scope only once the structure itself becomes per-vCPU. Signed-off-by: Roger Pau Monné Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 Signed-off-by: George Dunlap --- Changes in v2: - Added to the series Changes since the previously posted version: - Keep free_perdomain_mappings() (and hence perdomain teardown) domain-scoped. - Keep the idle domain without a perdomain area. - Retitle (was: "x86/mm: switch {create,destroy}_perdomain_mapping() domain parameter to vCPU"); destroy_perdomain_mapping() was switched in a separate patch. - Split the removal of mapcache_domain_init()'s redundant create_perdomain_mapping() call into its own (preceding) patch. --- xen/arch/x86/domain.c | 10 ++++++++++ xen/arch/x86/domain_page.c | 6 +++--- xen/arch/x86/hvm/hvm.c | 5 ----- xen/arch/x86/include/asm/mm.h | 2 +- xen/arch/x86/mm.c | 17 +++++++++-------- xen/arch/x86/pv/domain.c | 2 +- xen/arch/x86/x86_64/mm.c | 2 +- 7 files changed, 25 insertions(+), 19 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index efa72cd2f1..1f75d44fe0 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -517,6 +517,16 @@ int arch_vcpu_create(struct vcpu *v) if ( !is_idle_domain(d) ) { + /* + * Make sure the per-domain L3 exists ahead of any consumer (e.g. + * init_xen_l4_slots() for the HVM monitor tables): with + * create_perdomain_mapping() taking a vCPU this can no longer be + * done when creating the domain. + */ + rc = create_perdomain_mapping(v, PERDOMAIN_VIRT_START, 0, false); + if ( rc ) + return rc; + paging_vcpu_init(v); if ( (rc = vcpu_init_fpu(v)) != 0 ) diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c index 449d4f2a7d..9b375e438a 100644 --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -293,14 +293,14 @@ int mapcache_vcpu_init(struct vcpu *v) if ( ents > dcache->entries ) { /* Populate page tables. */ - int rc = create_perdomain_mapping(d, MAPCACHE_VIRT_START, ents, false); + int rc = create_perdomain_mapping(v, MAPCACHE_VIRT_START, ents, false); /* Populate bit maps. */ if ( !rc ) - rc = create_perdomain_mapping(d, (unsigned long)dcache->inuse, + rc = create_perdomain_mapping(v, (unsigned long)dcache->inuse, nr, true); if ( !rc ) - rc = create_perdomain_mapping(d, (unsigned long)dcache->garbage, + rc = create_perdomain_mapping(v, (unsigned long)dcache->garbage, nr, true); if ( rc ) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index cd425c3342..a41ae35374 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -620,10 +620,6 @@ int hvm_domain_initialise(struct domain *d, INIT_LIST_HEAD(&d->arch.hvm.mmcfg_regions); INIT_LIST_HEAD(&d->arch.hvm.msix_tables); - rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, false); - if ( rc ) - goto fail; - hvm_init_cacheattr_region_list(d); rc = paging_enable(d, PG_refcounts|PG_translate|PG_external); @@ -730,7 +726,6 @@ int hvm_domain_initialise(struct domain *d, XFREE(d->arch.hvm.irq); fail0: hvm_destroy_cacheattr_region_list(d); - fail: hvm_domain_relinquish_resources(d); XFREE(d->arch.hvm.io_handler); XFREE(d->arch.hvm.pl_time); diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 9a8fda782e..97924a639b 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -600,7 +600,7 @@ long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); int compat_arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg); -int create_perdomain_mapping(struct domain *d, unsigned long va, +int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, bool populate); void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, const mfn_t *mfn, unsigned int nr, diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index fc524ef0c3..6dfd75475a 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -6212,13 +6212,13 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e) } /* - * Ensure the paging structure for [va, va + nr * PAGE_SIZE) of d's - * per-domain area is in place, allocating whichever levels are missing: - * the (domain-wide) L3 root, the slot's L2, and all L1 tables covering - * the range. All allocations come from the domain heap. The range must - * lie within a single per-domain slot (one L3 entry), and already-present - * levels and entries are left untouched, so calls are idempotent over - * existing ranges. + * Ensure the paging structure for [va, va + nr * PAGE_SIZE) of the + * per-domain area of v's domain is in place, allocating whichever levels + * are missing: the (domain-wide) L3 root, the slot's L2, and all L1 + * tables covering the range. All allocations come from the domain heap. + * The range must lie within a single per-domain slot (one L3 entry), and + * already-present levels and entries are left untouched, so calls are + * idempotent over existing ranges. * * nr == 0: only ensure the per-domain L3 itself exists; populate is * ignored. Used to set the area up before any sub-range is known. @@ -6234,9 +6234,10 @@ static bool perdomain_l1e_needs_freeing(l1_pgentry_t l1e) * perdomain_l1e_needs_freeing()), whereas caller-owned mappings are only * ever unmapped. */ -int create_perdomain_mapping(struct domain *d, unsigned long va, +int create_perdomain_mapping(struct vcpu *v, unsigned long va, unsigned int nr, bool populate) { + struct domain *d = v->domain; struct page_info *pg; l3_pgentry_t *l3tab; l2_pgentry_t *l2tab; diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index 40b834e1a4..50f2d1284a 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -313,7 +313,7 @@ int switch_compat(struct domain *d) static int pv_create_gdt_ldt_l1tab(struct vcpu *v) { - return create_perdomain_mapping(v->domain, GDT_VIRT_START(v), + return create_perdomain_mapping(v, GDT_VIRT_START(v), 1U << GDT_LDT_VCPU_SHIFT, false); } diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index aa74acec82..bc7e49f4de 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -732,7 +732,7 @@ void __init zap_low_mappings(void) int setup_compat_arg_xlat(struct vcpu *v) { - return create_perdomain_mapping(v->domain, ARG_XLAT_START(v), + return create_perdomain_mapping(v, ARG_XLAT_START(v), PFN_UP(COMPAT_ARG_XLAT_SIZE), true); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:56:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:56:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405601.1639081 (Exim 4.92) (envelope-from ) id 1x1hhh-0003Uw-7V; Wed, 02 Sep 2026 09:56:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405601.1639081; Wed, 02 Sep 2026 09:56:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hhh-0003Up-4g; Wed, 02 Sep 2026 09:56:25 +0000 Received: by outflank-mailman (input) for mailman id 1405601; Wed, 02 Sep 2026 09:56:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hhf-0003Ui-Aw for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:56:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hhd-00B3yq-FW for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:56:21 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f2b6-bab6-0a2a0a5309dd-0a2a450ae934-28 for ; Wed, 02 Sep 2026 11:56:21 +0200 Received: from [103.168.172.146] (helo=fout-a3-smtp.messagingengine.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97f2c4-f2d2-0a2a450a0019-67a8ac929a97-3 for ; Wed, 02 Sep 2026 11:56:20 +0200 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id D9710EC0174; Wed, 2 Sep 2026 05:56:19 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Wed, 02 Sep 2026 05:56:19 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 2 Sep 2026 05:56:17 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm3 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1788342979; x=1788429379; bh=xt6BTOetJ4DGyA8BYB5q7qZpM72Rp6oJyUrAUWCSVys=; b= b8Ln5iQy9osHA45BWKfSh1EBrbQE+W81eRNtdCdMIDCs1jO3rAcVWN987VAJUHbI C6GPIGxsfhQxk9I5fDhznYG8M1DzIVAlRec7245+pJXVlnrzgTBF84ZmdAQtvmCQ XvCjr6StzbieU/r1KYHmaMqsLZMWonZyLa5vTgH1lI32iWC1/qOgVh94NXON7LFX yl85kjtiAyxXDkFcWrBjGojeDtPcSsYSoIl98xK4KD+gt1UaXIHcBD+XjdK+wLPB mgDBkhPfx1wH1odPZPzLQde+ts/8VYzNH+KeK+isS0Apc/NLtP9vUnwD8inZ3Y0U waEGghIl+pXYuhLtsL1EEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1788342979; x=1788429379; bh=xt6BTOetJ4DGyA8BYB5q7qZpM72Rp6oJyUr AUWCSVys=; b=d7qWCBXcyC8vQuRk/n62/PcHQMayEkhsKA8S5fDhp1TLRIfdnHw EenFb3t6c3th7JGI4lAZsoDJ1KmVDEZC5X+IO86u84fuco4vLVG1ohMJwYNQx+ez OIGdPXgRhLl3R07ewe8qLqaqAMj9PzflWE4wk5OSS57LmH2AhEpPPFFcSK8cKQE8 s/+il/iMHxLMeTwA7dve5bTkzEEnVnVvz0qReC97TKRAxVsgG57XJ7Ib2q44KYRV jq+x1L6k1I4JYrVwP9n/On0lBvuTToyPVBRKeLb75g8FJpvJ7QFWIOEE0IMDG8xF 4bhQpJGQeQN/w9xPXSbWQz3H+uZ35dAVyGw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFNTJ9/4/XdMg/ewdtzVWxcV2nETdKbSDB1QE4uGyJ5YStxLLYuK2Vn6Nrpd65u6Q 4+hnRVBT35SY4WczieL0B96qTm5PwPhlSfrAbgmaOlZM6dEWh2LCPwjemzTMEMr1iUez61 5KGvNYjjH5gRJvopGnFDesxQsDs7Tp8wyZFTxlsi/7SvhGW06A1qRgobdiMTkuN5pUHJXt EkeVBfi0zLHzV8Mewx0DnUHEzYBBOeCgPS488DosUifOVkEu0A+4zFsmFN5q7dO7KBPCeS 9OSeMKEgNT7AxERSQKXna7um8wQKqBngl9lZx6OS6b2F5hburFiJtisg793+ICvNO/HMMg iPDwgYp/WXIn2SGXAH+lShkAgBUhd4g5/MZMCRvsCwMowJnRRNgkV+2uGmdk0Z1EBv3O6b iFK9If32nf8x44TDU4s2Fs3/9oH/qp/wbvdiqdQ9vABUXbP4Y9YpP+oWIxnbTgS2KLLCIK P/aTQ8GcixUu8pfERaEOzT6I85PGHuzN+eexkkz/OCGD/bTKwpRoOMI7W4XgNhPHbFmBSs m7c9Qqs3kKjM2stQyP91DpjdNtybH5VPbgp6556kIQTpMc500tKEIQBOgOC8j/+qnaiNOC wS9P5m/dVs8eMdZ+Or+qqXj1d3jMuDr12cK/llv3+dgRhJdw+1p9w//zI+ww X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Wed, 2 Sep 2026 11:56:15 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Re: [PATCH 14/14] xhci-dbc: don't cast away const-ness in xhci_find_dbc() Message-ID: References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="01QUMicPQRD8dsXa" Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-4011c0/1788342981-514C7CFC-D0F0DCB9/0/0 X-purgate-type: clean X-purgate-size: 2752 --01QUMicPQRD8dsXa Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Sep 2026 11:56:15 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Roger Pau =?utf-8?B?PT91dGYtOD9CP1RXOXVic09wPz0=?= Subject: Re: [PATCH 14/14] xhci-dbc: don't cast away const-ness in xhci_find_dbc() On Wed, Sep 02, 2026 at 08:37:26AM +0200, Jan Beulich wrote: > Doing so (at the return statement), besides being a bad idea anyway, is a > violation of Misra rule 11.8. >=20 > Make "xcap" have an initializer while adjusting the code anyway. >=20 > No functional change intended. >=20 > Signed-off-by: Jan Beulich Reviewed-by: Marek Marczykowski-G=C3=B3recki > --- a/xen/drivers/char/xhci-dbc.c > +++ b/xen/drivers/char/xhci-dbc.c > @@ -384,16 +384,15 @@ static bool __init dbc_init_xhc(struct d > */ > static struct dbc_reg __iomem *xhci_find_dbc(struct dbc *dbc) > { > - const uint32_t __iomem *xcap; > uint32_t xcap_val; > uint32_t next; > uint32_t id =3D 0; > - const void __iomem *mmio =3D dbc->xhc_mmio; > + void __iomem *mmio =3D dbc->xhc_mmio; > const uint32_t __iomem *hccp1 =3D mmio + 0x10; > + uint32_t __iomem *xcap =3D mmio; > const uint32_t DBC_ID =3D 0xA; > int ttl =3D 48; > =20 > - xcap =3D mmio; > /* > * This is initially an offset to the first capability. All the offs= ets > * (both in HCCP1 and then next capability pointer) are dword-based. >=20 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --01QUMicPQRD8dsXa Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqX8r8ACgkQ24/THMrX 1yzLswgAhCU5fonKS2Jn6BHxUzFVduQ+ZY/u/IFsTz/bumAAGQCEu8bnL1FRKQGz sS5zU4yv+OX3dnlazqVJyIZZ/JM0pBiDEvt4TTsGw9LOws9vF6dOxSMZ1/L+ep6L pa6xwS24J2k5M1k440JabcrI1/5AjVUsFcEF59V6nkk7FzYyA7Ji9rWVtKTFIO4s yHnafme+3Fqa8URCxt0C8kgoDsRlaJ0GhTSgLue+BEGCpwAWEqtyxmZJJ310EUdC oHxRP9xBZYMJO8osPd8MPSG7rtePZg6uZxiIUoU/3dCb9Go4aL0QnPAWFJOP54O0 AK7SrV9IDoCx5Vu29HXqr/nn8R5eSA== =NJdJ -----END PGP SIGNATURE----- --01QUMicPQRD8dsXa-- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 09:59:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 09:59:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405612.1639090 (Exim 4.92) (envelope-from ) id 1x1hkX-0004Dw-JT; Wed, 02 Sep 2026 09:59:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405612.1639090; Wed, 02 Sep 2026 09:59:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1hkX-0004Dp-Gm; Wed, 02 Sep 2026 09:59:21 +0000 Received: by outflank-mailman (input) for mailman id 1405612; Wed, 02 Sep 2026 09:59:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1hkW-0004Dj-7n for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 09:59:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1hkV-00Efam-9I for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:59:19 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97f373-bab6-0a2a0a5309dd-0a2a4508965a-18 for ; Wed, 02 Sep 2026 11:59:19 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97f377-f659-0a2a45080019-d155dd33e1a4-3 for ; Wed, 02 Sep 2026 11:59:19 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-47de0093c42so947811f8f.3 for ; Wed, 02 Sep 2026 02:59:19 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce4647472sm56240455e9.4.2026.09.02.02.59.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 02:59:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788343159; x=1788947959; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/vAwC3tefb7FbixkOGmHDnNrlLQ4fDMzrHWRVQCmXpk=; b=BJh1sqAnKbT+FAgtamx+G8z4NLx69uITk8R2tIFq+D8zCtUqO8MWSGOrSYb9XvWmR4 VofJjfA4fYCZNX11EoExYg1Da768uPeI2b3gKI6WEPVMZcrP+DcGjIoT0H0HzaZdSb+w rSp+mKzt0oxL91wHAQoF/yaNGj4Dj0/46eCB3tdf6ogu0kYQ5P26gHlfmnrUtkQLNILx JwzgVIOdouFq2SD3eMAZuQQmjMHwuRUL65ovLJmvmG+b3g+GYnoEiYq8DNXiubJe290j JCLK9kBwQituwFwHKY4aYoJyxue/BXafvMWD9ziiHa4wzpI3E0usVTROVij0jlum2YFN MsqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788343159; x=1788947959; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=/vAwC3tefb7FbixkOGmHDnNrlLQ4fDMzrHWRVQCmXpk=; b=YJK4mCJpyYKVOo46s1lNIAK4jVb+T5Z5T1GMLWdYXvSvUqGk6nDddTHNR/jHp4H+PW 5My0jgZ05nUtNir2BWjowgtx5Ry/N4JSkd8f66Ai9sQt8ewOWN83T5c+bq6w4Z63LY5v g/9at/KSx3DxIkV697AAC84kl64vsr8A6Ucb6gBYwk3MeFloNboeAA7pvnElMRnd81vr oIYWI6dXw1+qb4lbfGKyeJHJ6cLRsgL7iNjLQNcCSTlrWhK2n572jWp0dcmceX64FPIz heslHt2HSidc2x7unzHrpROPSr0xCf9+AeRrvchYnc5TIFO1ueC6cgRRmtDJtMZNSOix aPJA== X-Forwarded-Encrypted: i=1; AHgh+RoHXOhw6ppNZ9E0ezzZ7FdIMQaW898J6jnUe+/M2WNdUTEaFXS1rAuYKoy2q6nzlzgFhpD/WONwS38=@lists.xenproject.org X-Gm-Message-State: AFuF++mlSORBYwuphJwaybTMTUj4AYtfIIS1BCJw+cRlm0kHiQYDDiKF hmLoRsofxJfrRr86UMG8sNgbXG/pAKQjq9CgyKMp2GdRK7MzGq0BCJ/N X-Gm-Gg: AR+sD12qL5gCwM1OUgpjCuPEpaOhron7f2ntvjPa1Lv5pp3NGVbm2BQStkkef88vO+n thC64bFQeQE0GNkQfdl6H9ZI2rjPJZedVLaOJ2B3Xy/8JeFgPBaQ9KG6etqGGfqmHQCUcGwdoGT edeWDG8FHr0K7VqJBrTpdYvEsTFNVgKnqMiwVH0AW6+RWFn375bDK9q8T7QuY6HJU2jyUcK6+I4 tgORLloQAJ13KgJ04EO9OeM9Qu0F5CSG7et41UdzA548Vz01vOA5v8sio22W1q1MLsmT03p7pOt DLxyCuc3HTnOrvMe55W1Q8Xe0yo2SijQmpIhN629TNkHVrENjnYfomTzKQAqKuVq/yWjQUarsOM kb+/mAB6E7CrHk2+xrNDKJxlWzWTh2f7tt8Tqtc/rHoPDdxbPwiZ1weR+LR8LPhEzj3A0cfx8qF Mpgvan3O8UENklIxC/tOHdYnrYX1fx9Tjy9mxv43DOouq0OCDtMkashYGv4jlK1FQ2dWmtxbgyk pE/0f2jXtfxQQO1uk3KztZzodWVLB3pAw7Az3kabw== X-Received: by 2002:a7b:ca42:0:b0:49b:92df:87be with SMTP id 5b1f17b1804b1-49ce55fbdbemr41777805e9.4.1788343158476; Wed, 02 Sep 2026 02:59:18 -0700 (PDT) Message-ID: <69c29c07-c63f-433a-a7ad-85fa981c89b4@gmail.com> Date: Wed, 2 Sep 2026 11:59:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 02/20] xen/dom0less: turn max_init_domid into a common variable To: "Orzel, Michal" , xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie References: <5a74a964b763e8444579a3c0d455e23160be8893.1787836900.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788343159-D735D87B-110DFF47/10/73395122804 X-purgate-type: spam X-purgate-size: 6776 On 8/31/26 5:48 PM, Orzel, Michal wrote: > > > On 27-Aug-26 17:18, Oleksii Kurochko wrote: >> Until now every architecture carried its own notion of max_init_domid: >> Arm defined a real variable (declared in asm/setup.h, defined in >> setup.c), while ppc, riscv and x86 each provided a "#define >> max_init_domid (0)" stub in their asm/setup.h. This duplicated the same >> declaration across all arches and placed a purely dom0less concept in >> arch setup headers. >> >> Now that the dom0less build code lives in common (xen/common/ >> device-tree/dom0less-build.c sets max_init_domid, and the console >> serial-input switcher reads it), there is no reason for the symbol to be >> per-arch. Provide a single declaration in , with >> the !CONFIG_DOM0LESS_BOOT stub kept there as well, so there is one source >> of truth and the arch headers no longer need to mention it. Update >> console.c to include for the declaration instead >> of relying on asm/setup.h. >> >> Place the definition in xen/common/domid.c rather than in dom0less- >> build.c. The latter is built as dom0less-build.init.o, i.e. the whole >> object is relocated into the .init.* sections and freed after boot, >> whereas max_init_domid must outlive boot because it is read at runtime >> by the console serial-input switcher. domid.c is always linked (obj-y) >> and resides in regular (non-init) sections, so it is a correct home for >> the variable. It is marked __ro_after_init since it is only updated >> while creating boot-time domains and read-only afterwards, and guarded >> by CONFIG_DOM0LESS_BOOT as domid.c itself is unconditional. >> >> Signed-off-by: Oleksii Kurochko >> Reviewed-by: Jan Beulich >> --- >> Changes in v6-8: >> - Nothing changed. Only rebase. >> --- >> Changes in v5: >> - Add Reviewed-by: Jan Beulich >> --- >> Changes in v4: >> - New patch. >> --- >> --- >> xen/arch/arm/include/asm/setup.h | 2 -- >> xen/arch/arm/setup.c | 2 -- >> xen/arch/ppc/include/asm/setup.h | 2 -- >> xen/arch/riscv/include/asm/setup.h | 2 -- >> xen/arch/x86/include/asm/setup.h | 2 -- >> xen/common/domid.c | 5 +++++ >> xen/drivers/char/console.c | 1 + >> xen/include/xen/dom0less-build.h | 7 +++++++ >> 8 files changed, 13 insertions(+), 10 deletions(-) >> >> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h >> index 0adfa4993a8f..2af780512540 100644 >> --- a/xen/arch/arm/include/asm/setup.h >> +++ b/xen/arch/arm/include/asm/setup.h >> @@ -25,8 +25,6 @@ struct map_range_data >> struct rangeset *irq_ranges; >> }; >> >> -extern domid_t max_init_domid; >> - >> void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); >> >> size_t estimate_efi_size(unsigned int mem_nr_banks); >> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c >> index 6310a47d68b6..86532d0a35b6 100644 >> --- a/xen/arch/arm/setup.c >> +++ b/xen/arch/arm/setup.c >> @@ -62,8 +62,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo; >> bool __read_mostly acpi_disabled; >> #endif >> >> -domid_t __read_mostly max_init_domid; >> - >> static __used void noreturn init_done(void) >> { >> /* Must be done past setting system_state. */ >> diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h >> index e4f64879b68c..956fa6985adb 100644 >> --- a/xen/arch/ppc/include/asm/setup.h >> +++ b/xen/arch/ppc/include/asm/setup.h >> @@ -1,6 +1,4 @@ >> #ifndef __ASM_PPC_SETUP_H__ >> #define __ASM_PPC_SETUP_H__ >> >> -#define max_init_domid (0) >> - >> #endif /* __ASM_PPC_SETUP_H__ */ >> diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h >> index 2215894cfbb1..73ce2f293348 100644 >> --- a/xen/arch/riscv/include/asm/setup.h >> +++ b/xen/arch/riscv/include/asm/setup.h >> @@ -5,8 +5,6 @@ >> >> #include >> >> -#define max_init_domid (0) >> - >> void setup_mm(void); >> >> void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); >> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h >> index b01e83a8ed9f..5925c5f39cff 100644 >> --- a/xen/arch/x86/include/asm/setup.h >> +++ b/xen/arch/x86/include/asm/setup.h >> @@ -68,6 +68,4 @@ extern bool opt_dom0_verbose; >> extern bool opt_dom0_cpuid_faulting; >> extern bool opt_dom0_msr_relaxed; >> >> -#define max_init_domid (0) >> - >> #endif >> diff --git a/xen/common/domid.c b/xen/common/domid.c >> index b0258e477c1a..cd46cf952be6 100644 >> --- a/xen/common/domid.c >> +++ b/xen/common/domid.c >> @@ -9,6 +9,11 @@ >> */ >> >> #include >> +#include > NIT: "dom0less" comes before "domain" when it comes to alphabetical order I think. Agreed. With that re-ordering, also has to be added to , as the latter includes , which uses the fixed-width types defined in . Without it, the build fails with "unknown type name 'uint64_t'". I will re-order the includes and add to dom0less-build.h. I will also added the following to commit message: While at it, make self-contained: it includes , which uses the fixed-width types provided by , so include the latter explicitly rather than relying on the includer having pulled it in first. This becomes necessary as soon as comes first in an alphabetically sorted include list, as it now does in domid.c. > >> + >> +#ifdef CONFIG_DOM0LESS_BOOT >> +domid_t __ro_after_init max_init_domid; >> +#endif >> >> static DEFINE_SPINLOCK(domid_lock); >> static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED); >> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c >> index fcacf37c52f0..61e92491e40a 100644 >> --- a/xen/drivers/char/console.c >> +++ b/xen/drivers/char/console.c >> @@ -31,6 +31,7 @@ >> #include >> #include >> #include > NIT: This can be dropped - I don't see anything relying on it in this file. Checked that: nothing really depends on it + CI tests are passed. I will also then add the following to commit message: Update console.c to include for the declaration instead of relying on asm/setup.h, and drop the now unneeded include. > > Other than that: > Reviewed-by: Michal Orzel Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 10:48:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 10:48:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405636.1639100 (Exim 4.92) (envelope-from ) id 1x1iW6-0003dz-1h; Wed, 02 Sep 2026 10:48:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405636.1639100; Wed, 02 Sep 2026 10:48:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1iW5-0003ds-U7; Wed, 02 Sep 2026 10:48:29 +0000 Received: by outflank-mailman (input) for mailman id 1405636; Wed, 02 Sep 2026 10:48:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1iW4-0003dm-Aj for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 10:48:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1iW3-00BEup-FT for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:48:27 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a97feec-bab6-0a2a0a5309dd-0a2a450ca710-38 for ; Wed, 02 Sep 2026 12:48:27 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a97fefb-f479-0a2a450c0019-d155dd2ca5e4-3 for ; Wed, 02 Sep 2026 12:48:27 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-4843e397f74so1016270f8f.1 for ; Wed, 02 Sep 2026 03:48:27 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448eea5b4sm5671255f8f.27.2026.09.02.03.48.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 03:48:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788346107; x=1788950907; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=UrTdGaKXlidG9RJ8fjMxVtiHLx/JZHJeCLEosI7fpFk=; b=Tda/EHCyY5i52uoYLoaACUyzQm25nC5iGmujAMhpDbhzMDQkd6PZIGDlN6ThZ8ceFH +nGZ7c3xOstrIZJgp5EFBq2//cTEiE/AgsxDdmUwbNdS52xwwExTrMRPBXJbfchYPg+S FZC+CKCMPwnP1e3evvaWZooRh9hVEopijt/L1wvHeurLjEqmuK1udSm0yHZ4/PyCbhMY 0w/YyYc+kyMRY4VZDMmB3U8Av2BN2QGDunawJdvsB33OEJvnBWwQCaLYRNxPglZI/j8P MOmXoXxf1XCeEJDrGS73Wnw0ZI3wy0T7IfGSWF1wNBEerXX59eRYYamcY5UJCdQjW1+Y bj3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788346107; x=1788950907; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=UrTdGaKXlidG9RJ8fjMxVtiHLx/JZHJeCLEosI7fpFk=; b=aeKsBDc67kW7wKIboVtWMLZ+uoYicCGccwECSsrKn+MZROWIeM0wDfYbxKu2msWAcH BxfVZDMzoirtxHVMcSy/xQKFp76vgmz8uxm8UJKnXtMY8kU3D/suq0dOmdVpjQqsrjMe QY0LWb0ekJt9p6pd1jEzbVl9IgF0uqnwXqpXmNyuQxzk4ZnKfFC/k6Josr5BT572EKjk IBc63e0RT7Nq6jfOpxNpgo5bhT5qIYUN4zQ2klTwLF8B+xQjDQ0iQM6GIFOsLwLOoHS/ V9mleGACYsAxLagueL7hrI+NUK858WxGekk0RYW+pZJg4Xkq8JKVvhFoiuGpJL/y7qaA 76tg== X-Forwarded-Encrypted: i=1; AKwUvBwkTdzfL/Kx/MoNgSwgLY1kcRhYxrXg5LrSHBQ7Bn7xrI+zEeSCRK9d2LyzUJRfpHHk2olgshop43s=@lists.xenproject.org X-Gm-Message-State: AFuF++lTEKxi5jxUYRX5o+kfu/6jMkZMl3JtIo+mfAx7RXobQWKXl/hD zpxI0tz4nUOSStvGIKEy8y9ACpgfxR0YbBaTiRKlJh6zbnjFkgbD2G1k X-Gm-Gg: AYBFou3J7dzInwrj0F/JaN6odWevtxV9mF2eB8+tYz0Bym/uFmtbCkLcc3Ei7avdqu3 ygV6es+UYAowGqfnlTpJ5tx+ns558sE169lQ6Unxj+X5YJ+xLkLjdxZxeAzeL17BBgqPfOGKIFz DzpMRW/bI+Bit9ZvFrdYxB3USPIwNeFyCvUZ4Gd/XgaXP6tfTsvtTeQ6xyeyw1hCHpKRp3xzZ7q YMK2cnRo7P13REisMgnk1K54fEKVuyRAe4FfyAHCOMA1FC75zxZzQ6fqfeK/GZF438VIYGLzQN3 q40c6QVP0HODYSR6H1MPozS4CH/vBecW7iuV/D8gjA8y3qF8iD6fZyrqpttbbjZbqfsfpLedCYw g/P8C3l425ZS5Z5n2Tj6htQJpPM4h+BJTzyQC0iyXvGVVBp5R75eRqRWEdNV47WQ13LElr1n5Qe MujaTxkGa3KTUHLFM+O7WvZoL9gpg1I3NMIW28CrYLTtm5BNDWVlfdpBO9JKFxj1aFlT7qlzleZ kOTqDX6Q/CJVido6dPBOPpMo+OU0AV9MJqLb0LCmw== X-Received: by 2002:a05:6000:25f9:b0:484:4779:bcd6 with SMTP id ffacd0b85a97d-4857822e9e9mr4647429f8f.15.1788346106722; Wed, 02 Sep 2026 03:48:26 -0700 (PDT) Message-ID: <5d8888f1-d6f6-4f73-812b-8a79edceed95@gmail.com> Date: Wed, 2 Sep 2026 12:48:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/39] xen/riscv: drop bug.h's duplicate instruction length helpers To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788346107-038D5A5B-29E7D2C9/10/73395122804 X-purgate-type: spam X-purgate-size: 3636 On 9/1/26 9:01 AM, Jan Beulich wrote: > On 27.08.2026 17:20, Oleksii Kurochko wrote: >> asm/riscv_encoding.h already provides INSN_16BIT_MASK and INSN_LEN(), and >> emulate.c uses them, so the tree carried two spellings of the same thing >> which could drift apart. COMPRESSED_INSN_MASK never had a user. >> >> No functional change. >> >> Signed-off-by: Oleksii Kurochko > > As I'm happy to see the duplication go away: > Acked-by: Jan Beulich Thanks. > However, ... > >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -214,7 +214,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) >> die(); >> } >> >> - cpu_regs->sepc += GET_INSN_LENGTH(*(uint16_t *)pc); >> + cpu_regs->sepc += INSN_LEN(*(uint16_t *)pc); > > ... for one I'd prefer if we took the opportunity and add "const" to the > pointer target here. Thanks for adding 'const' during commit. > > And then > > #define INSN_16BIT_MASK 0x3 > #define INSN_32BIT_MASK 0x1c > > are really named backwards, seeing e.g. their use in It was derived from OpenSBI project and I haven't paid enough attention for these defines. Now looking at them again I fully agree that names here not really correct. It should be according to the spec: #define INSN_32BIT_MASK 0x3 #define INSN_48BIT_MASK 0x1c Then ... > > #define INSN_IS_16BIT(insn) \ > (((insn) & INSN_16BIT_MASK) != INSN_16BIT_MASK) > #define INSN_IS_32BIT(insn) \ > (((insn) & INSN_16BIT_MASK) == INSN_16BIT_MASK && \ > ((insn) & INSN_32BIT_MASK) != INSN_32BIT_MASK) ... #define INSN_IS_16BIT(insn) \ (((insn) & INSN_32BIT_MASK) != INSN_32BIT_MASK) #define INSN_IS_32BIT(insn) \ ((((insn) & INSN_32BIT_MASK) == INSN_32BIT_MASK) && \ (((insn) & INSN_48BIT_MASK) != INSN_48BIT_MASK)) > > Furthermore, > > #define INSN_LEN(insn) (INSN_IS_16BIT(insn) ? 2 : 4) > > fails to use INSN_32BIT_MASK / INSN_IS_32BIT() altogether. Then INSN_LEN will be redefined as: /* * Length in bytes of the instruction whose first parcel is @insn. Callers * must have established that the encoding is 16- or 32-bit wide; the ISA * defines no instruction wider than that, and the wider encodings are * reserved. */ #define INSN_LEN(insn) \ (INSN_IS_16BIT(insn) ? 2 : (INSN_IS_32BIT(insn) ? 4 : 0)) I am thinking if it makes sense to have here the generic way to calculate INSN_LEN. Something like: /* * Length in bytes of the instruction whose first 16-bit parcel is @insn, or * zero for the encoding reserved for instructions of 192 bits or more, whose * length the ISA leaves unspecified. See "Expanded Instruction-Length * Encoding" in the unprivileged spec; the first parcel holds all of the * information needed. */ static inline unsigned int INSN_LEN(uint16_t insn) { unsigned int nnn; if ( INSN_IS_16BIT(insn) ) return 2; if ( INSN_IS_32BIT(insn) ) return 4; if ( INSN_IS_48BIT(insn) ) return 6; if ( INSN_IS_64BIT(insn) ) return 8; /* xnnnxxxxx1111111 with nnn != 111 is (80 + 16 * nnn) bits wide. */ nnn = MASK_EXTR(insn, INSN_NNN_MASK); return (nnn == 7) ? 0 : 10 + 2 * nnn; } I think that for now it is enough to go without common implmenntation of INSN_LEN and just return 0 as suggested above. If you are okay with suggested changes I will send a separate patch for them. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:12:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:12:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405650.1639109 (Exim 4.92) (envelope-from ) id 1x1itI-0008Al-TN; Wed, 02 Sep 2026 11:12:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405650.1639109; Wed, 02 Sep 2026 11:12:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1itI-0008Ae-Pj; Wed, 02 Sep 2026 11:12:28 +0000 Received: by outflank-mailman (input) for mailman id 1405650; Wed, 02 Sep 2026 11:12:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1itH-0008AY-Ne for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:12:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1itH-009Im7-4A for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:12:27 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980493-e002-0a2a0a5209dd-0a2a450cc4b4-12 for ; Wed, 02 Sep 2026 13:12:26 +0200 Received: from [52.101.61.56] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980497-f479-0a2a450c0019-34653d38cb9b-3 for ; Wed, 02 Sep 2026 13:12:26 +0200 Received: from DS2PEPF0000455D.namprd21.prod.outlook.com (2603:10b6:f:fc00::515) by SN7PR12MB6959.namprd12.prod.outlook.com (2603:10b6:806:261::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.12; Wed, 2 Sep 2026 11:12:20 +0000 Received: from DS2PEPF000061C1.namprd02.prod.outlook.com (2603:10b6:f:fc00::214) by DS2PEPF0000455D.outlook.office365.com (2603:10b6:f:fc00::515) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.10 via Frontend Transport; Wed, 2 Sep 2026 11:12:20 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS2PEPF000061C1.mail.protection.outlook.com (10.167.23.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Wed, 2 Sep 2026 11:12:20 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 06:12:20 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 06:12:19 -0500 Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 06:12:18 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Qk6WeogNW+h+nayx9Iuuq0ZrDWgdrg1KWQr6GZpnu8kJIuYeo9yIWKOOIFwdoyQvmO4Tod/5rNrloSAtbmPnCjJ9+5rE2dICeSCJh3k7JOk7vi6lJWSwMbD0Dith6IvRfws0T3eRX8/S5JKYXqeCmPrqqBYQA+FngGvGudNhmGssQTe/u2x6QJ2faBHXo8zG8JbqFUdpvM7ifPuUZeJyjsuTziwPhOX0b7Xqq/myW6qBDcM447PMnkH2kJM+cFQVi02niaJ4yZn9pdvnEKMDtO5GzhPtpjH99eX5DaRTg7EfPijwAaW3sWXs234EvyKwMHdHOAKGtxoRsew3yIjHhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kZbdSDvhE8avk4BPKgNip2kR3pLCvmN2CAqV1gLtg6A=; b=uDaNloaL9Y9UCNd64lvTxA3E2VZjFfhWUYLnSfopEFcFz759Lfn9ulZYXexAGbH7M1U5j2UxIOyKCWogNF1i2pn8tFI6Ar8+k0iPEiPBOOhaRAbe3Q9dJDkPG6O4EQm75hygb4ksL37RGnzaffS/+Ynnnz+byzoA1lgo457tVzoJibH5AAmRzcEr5II26QW3PeOLpjyUaHVCPDNItolumJTWw9b+qhMkM1eMz04QFOSiScCWvUpaScakmtu4ReBZMSmLLA/6w0NGdP3IG2lzZXkknKFpkusLgPp8zri/B86yxbyrrCn7YbyEhGGG3OgcI87N12NE8R/2YViaXTnUsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kZbdSDvhE8avk4BPKgNip2kR3pLCvmN2CAqV1gLtg6A=; b=gQE6Uqa4i6UojUsZ8IvR+aQ0s7/YE3X0f5UzoPpn1+VTF15b300eLThgHTmgBeBXjBHaBG40+1WHGEZYp6Ixvl7jz0DFVs0KDNQTM52iT6tvcFRomFF46MT47MVJ6oEoaYpDg9OxWTCcLrpEFjoGD1/JMXBQUupo94Y5vBSjdtE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <37875a01-a4fd-4c2a-8ae0-df88c769b9f1@amd.com> Date: Wed, 2 Sep 2026 13:12:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] cmdline: Document console=dtuart option To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , References: <20260902073606.61062-1-michal.orzel@amd.com> <20260902073606.61062-2-michal.orzel@amd.com> <37872f45-8078-44ef-9db8-a9868c9b79aa@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <37872f45-8078-44ef-9db8-a9868c9b79aa@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF000061C1:EE_|SN7PR12MB6959:EE_ X-MS-Office365-Filtering-Correlation-Id: d34792b1-9972-4d80-7789-08df08e30e78 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|36860700016|82310400026|376014|10067099003|56012099006|22082099003|18002099003|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: hMWZFUnERi4Ph4GCfvOJLdVRLnPBNmOHtgo0tk/tsEJ97H9qzcOJNSv9zXHy1k8VElrBqhXBCUVALNg0tTxWIHr+VpmFc1YI11JsLDxQy4LI5hr8qRI4LAtM2UnpRIB+GaUCOSMlpa9erI/HnaA8kaMnqtBi6H7pZq6H5Yyn9L5kQfUZsaPi2iRuXfeLnSLWj25OZUmqqqdinvSwNWqFbRJZArK00eSCZh7NO6jt3JrRYDtzjgSxVNqvXJ6EmK1EB4f41+u8Yv+PGpoFR7JMBssdY0o14cH5Q5JBM7kSA09jpZYN7Ya6INT40pjldGxOVG8AtscPkh7gr1RcO3if4OqIDmOkcVwiqr+vYvbL6/4QqTYsRxuz+6PS7ZTMWQx1Q7OYLEML0Kj+7zgj0J1IErRNmZms1dotCalqkG8X1/Vr0v/BVTUFeTGRCpnVnk+HZRq10YYl4XUFPR8E3gA0wYYEd56kPqUS295ZfdtmSmglSfp8Xv1xggwOcXytXpaQVovchCkKekK03aCsEBFg3a3N6VFSIVUqSXEIBd+Adq+GfpgZV7OO1Qx5shRQfmePvooMhPR1HOAnmKLz5Mtj5LirFvGiCLwNv7C/2QGjYCeFBNfF2fJh/FA2lEJPaBlmSVwDq+NMc1kziZY2CGLWfpx28yP0MaErWakcF/dn4TjLs3LUGhSymL9fWbCgWoHo9BUmckDBP/zpKFemWUebpw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(36860700016)(82310400026)(376014)(10067099003)(56012099006)(22082099003)(18002099003)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: t0fyY8b12igT8U91W5tT5TnnwSGdmSbX0VZpM91qEVZ681EBzhhidwS0usgEvtUeWOuxiCG5KxjUUqCksVh9tIqdayV7eQ4lbIVeyx9zTS+Ag32bH3QWRP/3/B6JBFFpSYU3xBVhrSF2mpTpgHQfPH8UYaqyth89Db4KUyS5zV13U8do4lV4CHz9KPSeVKceFGMyl73Au+o6hmtCCPpvWYzXsNpZrIUkFWyoYNdEO3BAD7x5uMydc1UyTUqfhcN4BIAsuIfJwOGzVm/ps7E2d8Wkcyy80MGa7XDPaSgUiYa00aSElZ0Z61GET9zKmgLeJJkw2XYOOkpenvr+n9yn2y8X6gAicyNdXXB4yulS1L/jZ0k68WFCPDc+MKnXGVXwwELOHy4Ewj0Mihcm81SM4Vvs1sAmpHYnljqjZxreCHAdQIbJxgE7TfYDdWEJ3GzH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 11:12:20.2810 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d34792b1-9972-4d80-7789-08df08e30e78 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS2PEPF000061C1.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6959 X-purgate-ID: tlsNG-d25034/1788347546-030D9A5B-5CD740A6/0/0 X-purgate-type: clean X-purgate-size: 1647 On 02-Sep-26 10:55, Jan Beulich wrote: > On 02.09.2026 09:36, Michal Orzel wrote: >> Document the default console= option on Arm and RISC-V that is >> "dtuart" indicating a generic UART parsed from a device tree or >> ACPI SPCR table. This serial utilizes SERHND_DTUART handle. >> >> Take the opportunity to: >> - fix documented x86 default to vga to match OPT_CONSOLE_STR, > > I first wanted to object to this part, as I was sure this used to be > "com1,vga". Yet indeed it's been almost 19 years ago when this was > changed (92877a1f9ab2 ["x86: Auto-probe the serial port baud rate if > 'com1' or 'com2' is"]). > >> - mark dtuart option as available on RISC-V, >> - document fall back to /chosen/stdout-path. >> >> Signed-off-by: Michal Orzel > > Acked-by: Jan Beulich > >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -430,9 +430,10 @@ The following are examples of correct specifications: >> Specify the size of the console ring buffer. >> >> ### console >> -> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]` >> +> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | dtuart | none ]` >> >> -> Default: `console=com1,vga` >> +> Default (x86): `console=vga` >> +> Default (Arm, RISC-V): `console=dtuart` > > Any reason to not also cover PPC here? While PPC sets OPT_CONSOLE_STR to "dtuart", it does not select CONFIG_GENERIC_UART_INIT that compiles in the uart-init.c which is what really matters to decide whether dtuart is supported or not. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:22:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:22:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405662.1639116 (Exim 4.92) (envelope-from ) id 1x1j2l-0001c9-NP; Wed, 02 Sep 2026 11:22:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405662.1639116; Wed, 02 Sep 2026 11:22:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1j2l-0001c2-Kk; Wed, 02 Sep 2026 11:22:15 +0000 Received: by outflank-mailman (input) for mailman id 1405662; Wed, 02 Sep 2026 11:22:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1j2k-0001bw-OC for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:22:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1j2j-009KS6-K9 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:22:13 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9806e4-e002-0a2a0a5209dd-0a2a4501c5d0-2 for ; Wed, 02 Sep 2026 13:22:13 +0200 Received: from [40.93.195.61] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9806e4-5984-0a2a45010019-285dc33d9d4c-3 for ; Wed, 02 Sep 2026 13:22:13 +0200 Received: from CY8PR12CA0046.namprd12.prod.outlook.com (2603:10b6:930:49::24) by SA3PR12MB801393.namprd12.prod.outlook.com (2603:10b6:806:53c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Wed, 2 Sep 2026 11:22:09 +0000 Received: from CY4PEPF0000E9CE.namprd03.prod.outlook.com (2603:10b6:930:49:cafe::19) by CY8PR12CA0046.outlook.office365.com (2603:10b6:930:49::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Wed, 2 Sep 2026 11:22:09 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000E9CE.mail.protection.outlook.com (10.167.241.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Wed, 2 Sep 2026 11:22:09 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 06:22:08 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 06:22:08 -0500 Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 06:22:07 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lAxBAdiFPR+pqKAt1XDJuLFe+ins/C+CkwsswN2s21LxuQildNtOc9wKnfZ2hnUDWN3rPuYNnrWNyjPWg+n4a7LYNoSWICYzbCuoHPyJ0KvPOpw+fXLeOWLzD/MOpq1kyDEtrKHUGf1sTlXn9RcZZHrpb3MgBLNppQCWL3NDkg6i/1uA0jHBVrxC+e0moQrv7ljCysmUKOaMRNfzDu9z/F9A77Ve2PgCtK3FnXs653i7UPrkszu1q4UiEaxl/HN9rJn5qoHC9vLbi/YdTT/dCsTRLuquJfTbAm+EnoZmj8z0nX6/pUC+pgwFd8al0SvVNXyGJB1slAEvmZWBAxIK4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ksrp3V5g1xJJUK0jQHQdiQqzRlcVqhsml17jO+E2mSI=; b=N7KM4imyiVG4dPFUZ7byYmDynQz3mOhBK5pvhB9aZhyKSQ4N/8JFyE9iUp0g/dzpllNDvsfr2xtp1sq7wCmgzRC2/hJ+dPeoYv1a/AtnFi5CMMJ/uNcGF8dBBOB6U381EhRuy09e30AV+OeA3ltmSX3sQiY3WPo9JiiWLc82R4riB9NeoDzkLxTnKOAc6tKHd9xAlcEZ4XUZbcFJB6QLaxzuaeivGiL3/cPeM2t5zjv9e+DSZNiTH2e2ykig11kCU4pcK8OLB+Rb4Jy/jmVp/CpnuvNC49hTAvaxXvRRiumC9qVokx/7pPjCKhUljhKyTtfRp60rP/Bba1oGFIRUYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ksrp3V5g1xJJUK0jQHQdiQqzRlcVqhsml17jO+E2mSI=; b=JBHBBoB0unOlSvqoVJlaUgb1487r/5CzSHTSoJlmP1nsWQAY03XWRDwPbzCfQO/+jef6Luc58qjPK1/5iV4XkjaGrY+sap7gQJOiWPtBlIU3IU5jHCaBfG344e+zzMj7JCDHXJXRc6sPmkOyb67MCPOH3YPo8WWQ/ZK/ta5sH9I= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <0892a479-ae28-479d-983a-8932a57e040b@amd.com> Date: Wed, 2 Sep 2026 13:22:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 07/14] Arm64/GICv3: have gicv3_its_find_quirk() not cast away const-ness To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Nicola Vetrini , Julien Grall , Stefano Stabellini , "Volodymyr Babchuk" , Bertrand Marquis References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <9479d311-2449-441a-9855-66926dd8e0cd@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <9479d311-2449-441a-9855-66926dd8e0cd@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9CE:EE_|SA3PR12MB801393:EE_ X-MS-Office365-Filtering-Correlation-Id: b8331d73-be52-4f76-1a95-08df08e46da2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|82310400026|1800799024|376014|36860700016|10067099003|22082099003|4143699003|11063799006|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: 2NLd74iVUjZ1Fvmn4viuKo6AalHZ3K3YH7NwhNBXGry9cBRozR4ZGsECqzK2b/ZB1oLz4mSeivBl2CbFqlf0n0WIGxx6ee5h0gzkaMPJRB4fHp5aU+mup75QGxXb/GVDR/YWrBKdHUQ3kIdyWCedORBnoivLvdUSd0KXqrxaWlSCr6VUqfNPVAo4Qowy19vIaLvZmw0WN/5zMhr8jzi0qZhqfw96yhw/ren+wM5K/E1kO/1zOQsQGyMU8u+JcE039ioHZNPgpiwLkPIIEAPhiWxQqKK8vbdx6DZkn28F4SeeudqwxjM/K3PDPphM/yzq4RXdfxRMfOxzd4fO9N62QZBmWDBwV9wx7qjCyjnelhtFyVaAfSwBuHGdbkfKHAxB2l+jFoSzigEPY4fAR+AHTXkXJPzbe01g173O98R4p4SDrNtyy9GaxH8+kxjnHKSRYbFBqY+4bbFimZ/CJ79DwM5oJnNwVnXkwWJ0UXwVmCFqVm32iq8t2muKWyaIj+e21OhoxcAzuZ0kL1nkbl5eLXpiSI2eRxsQHVA818c94yDLiJ5NppuzAL/opCGfNbJp7Cq5UtG39cU1ggH8w7MytVtk63lJ4TFqj+YrKZz5JmVAy5TIVeku0RC2WChO1INbVkwzxtVdQftLP0mKDf8TUo2Uk1UrqJKiQeB2s4M8AO2aK7kswP0fFIMlGWTmj9LZXWm/lNQGmdk5BG1uwGKhtw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(82310400026)(1800799024)(376014)(36860700016)(10067099003)(22082099003)(4143699003)(11063799006)(18002099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: GYPwLkVg/LyzY7paR2X38FTSN4N6tLAm4yGmxyBu1WsxYO5DKfoGdsMIj/WhPf1wvv+e6qSPk6KurocetZw0VsfxMlXduGMYC9RTdxVfMxIj12FqbfPAMvsw9XMxY/PtnlmfeHeA2kygpsU4mje3Kzr0uGoR/RHmUQwPL6DF+ZWpGsC+Wx676v+BQhLncp3xFOoOyT7FTrbpqLr4zPu+neknsPQLeRPyvYQMayuLKvUQxfxc53Dk83j9TddEXMXBG/qfr8FS3bC5vDpGKCAl9lOEaURnX2HxUCv6YHDkeaxiD/l2bZDs42pSYZOzok7qSTnOEUWFhsx6m3WL2V9QJGGj3zqU4HePFiSEvAG1CKQpUqRkNPL7GmnbnO7QM2PULptnqTl5WmmpjNpJk8kQROiooxM0rt5pvcn7Rbjq9gB3vtcOAT2uBIfJO7X34OSv X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 11:22:09.3921 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b8331d73-be52-4f76-1a95-08df08e46da2 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9CE.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB801393 X-purgate-ID: tlsNG-d62444/1788348133-BFC69757-04BBA945/0/0 X-purgate-type: clean X-purgate-size: 344 On 02-Sep-26 08:33, Jan Beulich wrote: > Doing so violates Misra rule 11.8, while being entirely unnecessary here: > All callers already store the return value in pointer-to-const variables. > > No functional change. > > Signed-off-by: Jan Beulich Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:30:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:30:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405672.1639125 (Exim 4.92) (envelope-from ) id 1x1jAN-0003V0-EN; Wed, 02 Sep 2026 11:30:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405672.1639125; Wed, 02 Sep 2026 11:30:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jAN-0003Ut-BX; Wed, 02 Sep 2026 11:30:07 +0000 Received: by outflank-mailman (input) for mailman id 1405672; Wed, 02 Sep 2026 11:30:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jAM-0003Js-1P for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:30:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jAL-00EyNP-92 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:30:05 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9808ab-2eae-0a2a0a5409dd-0a2a4507c9aa-40 for ; Wed, 02 Sep 2026 13:30:05 +0200 Received: from [40.93.195.56] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9808b8-b4ea-0a2a45070019-285dc3387c73-3 for ; Wed, 02 Sep 2026 13:30:02 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM4PR03MB7015.namprd03.prod.outlook.com (2603:10b6:8:42::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Wed, 2 Sep 2026 11:29:58 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Wed, 2 Sep 2026 11:29:58 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=K8avEXm04Z7yZaM5Mylerec2uj5wtFYTF/JZ8pULXZ6mq7OW/7BJ9Vwc49v5K54OcypyX4cmJqhd5PY3j8MaqvtqASC4OjWpF6ays7a8PmYeCh2xhkbwqvZAjnJKn9vs7/qyT+2eZEv0FFsDXXPtNq6ydSxh02/603ZkyKIGWRbZ08OcHNj2ljZ6fsPuqSWud1y+r3v+YYH18P5RDRDjOCkWkrxjLmEl/kPpNGOADST/JdKdkOSNkFBtemoZJOqwBjCMURfOtwt4n4iRqefkM23NybGs3kF25rX0yurGlvQxvTCT/IZk+SsQ3F9z/2GqXmeRRO+k++ThyO1sltlsog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rknqFhoN9EyOuvKQ6pktIc4DwDN7Q5InRknRMXQXJUg=; b=XNNZLKc/yv7Fy/MsJ4GD3lG+5PGFHnEZY7DIkBVqCtVeXypdcnOQ4DbmYiA9XgOCS7BR+kiY9TubUmJeh0GJX7UWislHrtiNxA8bT5lrbYHWMbexzPjiFphgqWMGJao4V3YZVWA2Y2RSsgyTyfmcxisH0tFXZmIvrr8TLeTymtckH3xFmgrsCXsKyBAL7YbJRKA0SdpZDZRM3LfN4hL4XALQxEKZilsMygV+K+rfyBXWl/zFqvyN5CqU+po7Q7mganUgsUb5icOt9fsM4ULkI2rGJ8P1jHBnMGd/W8Xr39+gEtBcOHCZ5YzICsa3gDSSh/7dQWU4njApzmGTm6TcbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rknqFhoN9EyOuvKQ6pktIc4DwDN7Q5InRknRMXQXJUg=; b=uhAOomtqU/0fWP3qCp5iF7yLs3lH+HvAeG1JtA56Rl+aoIMkT8BSgoLMSTfuLRUtwRQCve7Q3+HtIRHhPQ00rGCLcY0RSO+o1+QOjbmXLYMXU9lLMMTv+Owa7+CgH3zxb2/8q6OW7S+EAPRYL6RpGzBgXrsw1+ZzmYI08TinB9c= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <11dac855-d2d2-4f28-8a53-de740a3ed5b5@citrix.com> Date: Wed, 2 Sep 2026 12:29:54 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Nicola Vetrini , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Oleksii Kurochko Subject: Re: [PATCH 02/14] x86/bitops: don't cast away volatile-ness To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <75bd486e-054d-45f4-93b7-800b0ddb21f1@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <75bd486e-054d-45f4-93b7-800b0ddb21f1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0141.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c4::11) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DM4PR03MB7015:EE_ X-MS-Office365-Filtering-Correlation-Id: d9bc5c29-8c3a-461f-96c9-08df08e584c2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|22082099003|18002099003|56012099006|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: kT8C/Nps1QKr3npN4dxkyj/0IYumcTqkCNEOJ81dT0276jhfe7nj19nAZjPpQskhb4zf79dRyb6NSw1f/JtkS/NUHvtj+FWtqUIF1CBZOpgAShg93sWuKxDy6HXQ5zRZ5Gf+3DQTWQQYJGdjum7ZGay9URQLBbbgRMFMzT5x0gxEKAUeMTc5R4YqiY70Sr73kVizbTJt9RyoCXF5nTli57PFuoRNrJTYfk7/YqZMb1qEvczJ47JKLldViaAjl1usqzLSGyHRvAgudXX3pOH4IaYYK1yC9SmCz0gThhRtEBjQFK/ZEJl9IIzh2lATPhfhrWw/Vv5cOQogy7tjhCmXwAZ5jPeMID7VSFy+y/akR3VyZwAJ+xtMXm+M/b4zDclRtZfkU7J/K5pqcDVtSY4gyhv1jMwsnv643Ps1/hbncK7doOelS0u45W+6veeImzOimRlLrW9UCzlJGTdxpVjHt9+ugnM+qnB3Dqdg2++O0+xIt+ndoecTl6HpwYPIMZXzg7VXhblJ90EtcRPsduO+P77a98XlzPcZFpW0RJHjHqGdzBorJjJ+OEtoC2+dPMQqjS9GnQBLDjbxTouBO7Cc4553TOnUX6aaPjYa+TMH7oxmMrfxVQIS7vUpf0lnrp5yFIGPHVhl1oCFIutZhCXRDX3ADxySJ+MtuxbX1xAB2io= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(22082099003)(18002099003)(56012099006)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TDNMZ0VOb3ZwaVJ4TVN2ODcxRjZ5Y3U1NVZqdVM3RUVhbjRYRSswbEg2Sk5z?= =?utf-8?B?NmJTd1pVdzM3WC9rMERTcUlndlZjeGY3TTJvYXRhckM4UkIvNWhXUVZuZXp5?= =?utf-8?B?TnFVTFFaNGtQOUhEU3ZDNVdkNWVmVnUwVVJrYTBhWFBPZmJWaTNDYTk1Mi85?= =?utf-8?B?M1NwcStVQ2IzaWdzWjlxL1RJK2grS1RRUUlPNjhYcnRXcGFQNlc5K3o5dVlP?= =?utf-8?B?dlRDWit1UDlna0Y1T1B5K2NBZzBYSFZpNXNCajhjcnN5bzJKZEJzR2dXTWFZ?= =?utf-8?B?T2I5bmlkOWppcXFjOHlOUW9nclBjQmd2eFgvdXBCM2M0Uy95eGZUMEllTi9J?= =?utf-8?B?cVRlL3RVVlRwZkdmRTJVSjVnb20vcVg1dWY5TjdmczFuZ2NFZnUvTWFjS0J0?= =?utf-8?B?elpkYmpVVXFuU0drSWpEbkl2bGpaUFl6TjVicUREUGMrcnh0TjRQSXp6TExE?= =?utf-8?B?OVF0VGFaUmlIK2Z5TUlaK3NBR0xaSSs5NFEvUHhIUGQrTkJqeC9yYW9xWFov?= =?utf-8?B?Q2pDTmJQRjQ2NkhDWUpyTEVhaCtFcXppZWZrazdmNkx5RXNWbTZLd1Y1Yjdu?= =?utf-8?B?b1JCNE12OGkwQ2hhRWNmT0VIL2wyMHNObU1LdXd0cmRIblp0WCtYbitpNU1R?= =?utf-8?B?UXROVmhnREpjK2lEQ3BYZjNpOWVxMWVwczk1VjlFTHcwUVNWNkFOaitMK3ow?= =?utf-8?B?OFg5RFFLRVVnL1djb2NHejBaWlU1aTQ5MDZvclVqcWdTamZpK0c5QWRiV0N0?= =?utf-8?B?VUp5dms1QkM1Q0M0ditLa3AwdTMwZjdFOHlRcnQrSURKblFHVlBRQk50NE5H?= =?utf-8?B?ajBHNTFVdCtHaWdXNHQwbEhJQm1GRGQ0VVhSeU9wQy9lM0lLOURhMzFKeUJU?= =?utf-8?B?YlYzNWJKUUM0M3JJSnVHRXluR1BKSy9NMmorNHd3UXZSN1M0SzJUTGtWZzVi?= =?utf-8?B?TEZrNnYrU3V2QUZBenhzY0JBdThkK1M2ZEZIYy9CaTQyclNPYVRQaW9BWTY4?= =?utf-8?B?WUMyWkVTRVV4ZSs3dGVoNWhDZ05qS3FNOTd2Q2lHSHVqd1R1c21jak85TjQr?= =?utf-8?B?c1FCOVU5VHF4VTVHNlVoZkFkRktIeTQ4Z1A4SHFxL3VYZ3VYTm1mbzB1V1lQ?= =?utf-8?B?R3JvMkFsNzh2RXZ4SC9RbmNjVzdwK0xyWGcvVHJJak84STJmN2U5R1VWbno3?= =?utf-8?B?aHZDejB2QWJva3drSlRoenhjckhhY1U0eXQ5OG9nbVVjOGhDdm1tT0JyS3Fz?= =?utf-8?B?aFBQWWViS3FUR2l4YzM5ZG9lekEzeGdtOHVmOGtvVGkzZi9jTjFCTU9iYWVG?= =?utf-8?B?UzIwellaKzV4Rmlmemc1WFdxNWZ5VllUTXVESGxjRVB2NFc5aDJ6azhzRGtC?= =?utf-8?B?UmZKbS90UHpOdXUvRUZzSWNGcFBiNW44WFhBbEZnUnVxZmNtUGhoZUo5enBH?= =?utf-8?B?K1QzTGtpbGc3cXVIeDU2NmU1eFZXazREejVlM3IrM0hVRS9PUE5wWThIVzJE?= =?utf-8?B?VG43SXZ4M1pPRDdsVXRYcFd3TFJUaFY1L1NQbzIvcHZxbEVQZ2JqOUVQVW5i?= =?utf-8?B?d1pxTzlsdTMyUGJqYzdHNzdpUVJYcDRrZkFCeDBpUTUyQk5LNytuWHAvci9V?= =?utf-8?B?TWJYNWUyKzdVcVNqclRUK3hkSVdpcUwxNk1ZU1JsQVBZVjVzUzd3UDJQQlBq?= =?utf-8?B?MHhMRld0NDBIOVkya1ZHaVRrUDdicmpPR3VINXdGbW1yRnhPYmIwWXBTVjNV?= =?utf-8?B?VHFOY2x1U2NjeC9FbkxNOU9yZDlvM28rdkNORVllNHBXUmRvMXF2dGZTd0JY?= =?utf-8?B?UXZYQ3ZLMHBEejRNa1VlR2hjWTVqNC9KZHZIL1A0QVE4c0RIR2ZaZTg3bFlL?= =?utf-8?B?WkVDOWlVbXNrLzVvMlRndjFZNDZ3OXlPNGVUTU5RNTlYLzdUNlMzRmlUMGli?= =?utf-8?B?QitzaHRTdHk4MkorMTJ0OThNdjZnWkNuSHdjSHd4Y2FhR0NveGk5b01WRCtN?= =?utf-8?B?eXVKTkZLQjY4ckw5VkZxZ1B6em1MalJlWStSNzJkTjFnNlVJYjdLUmg0YmF6?= =?utf-8?B?b0pPV21tbDAyRGVmOUxaOWpDOCtTcWhpYWlUSzU0b040LzNYRmNmblk4V3k4?= =?utf-8?B?S3pQRW95RlltMWF4QnVuV2E5QkxrcGR1YW9RVUdEVFQwYktNMXdUVnQySEdq?= =?utf-8?B?TTY4UCtFWTVadmdzVXRpZ09UcmdYbHVJTjkwOFk5ZkQwc3VBcTZVZldSSUVG?= =?utf-8?B?T1BBWkNuclNJcVRNajExMFZnSVI4L0ZYaGNvcW96WVpFbGxIb1RCbWtsUHpO?= =?utf-8?B?dDUxTDhTRTJqenhxMVFxYmh6T2V3NDFNaDB3NFVhakhaNkFqakRKUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d9bc5c29-8c3a-461f-96c9-08df08e584c2 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 11:29:57.9565 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ThIvg4INEe9SGaeyO3dCuXKCaeg2794g56xFvZfdPjo/qsHSR01qvSnZvbtfLfdyabUYENNFgNxZ/qdzHnK4VAAhGsrJl8r3sPQWthGjbHY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB7015 X-purgate-ID: tlsNG-ef75cf/1788348602-A68D9AE4-08FB35C6/0/0 X-purgate-type: clean X-purgate-size: 444 On 02/09/2026 7:30 am, Jan Beulich wrote: > Doing so, besides being a bad idea in general, violates Misra rule 11.8. > Use the helper macro we have available anyway. > > No functional change intended. > > Fixes: f1879b2c2584 ("xen: introduce generic non-atomic test_*bit()") > Signed-off-by: Jan Beulich I really want to kill ADDR, not expand it's use. I'll do a series and pull this patch into it. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:42:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:42:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405688.1639135 (Exim 4.92) (envelope-from ) id 1x1jML-0005gP-Hy; Wed, 02 Sep 2026 11:42:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405688.1639135; Wed, 02 Sep 2026 11:42:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jML-0005gI-FH; Wed, 02 Sep 2026 11:42:29 +0000 Received: by outflank-mailman (input) for mailman id 1405688; Wed, 02 Sep 2026 11:42:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1jMJ-0005gC-IY for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:42:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jMI-00GQke-Fb for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:42:26 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980b98-2eae-0a2a0a5409dd-0a2a450bcaa0-40 for ; Wed, 02 Sep 2026 13:42:26 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980ba2-b7e8-0a2a450b0019-d155dd30b8c1-3 for ; Wed, 02 Sep 2026 13:42:26 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-482dbe4d247so404826f8f.2 for ; Wed, 02 Sep 2026 04:42:26 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448e80798sm5596742f8f.13.2026.09.02.04.42.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 04:42:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788349346; x=1788954146; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0WowKxW3bbcijsWVk1Eln6Ny83EI/o2GQF6xiAhpT1s=; b=Gz05Y2LDu9x5+J/CmLL8jnpNvIck4MsMCDjqPGgZdYec9hIVYdGfDGdPyk662w1/MJ g57MRY1G/vkP9W4tSf1w2sU3oeWh6ZkPOvQDn2MtJEINBSQDFQp4tYt8KUg1GI9Xcb9T 1Vg+tkKCpZdU/aUzyQu7gFISyb9JpgQ0adwzm+rWZcZUZ+rhp9Mu50ZKI2Oo46D6g9Du k9suSogPW4CIVtjioB91CVDfOuDaBcKJTfcwHmuVdELUck343ipz6IGQKONS48BuQ/2l 2WBhCKdUN0KD4p605RupEhFC5gbTVsukA7KJJoimYTs4r3oPLkXM0NE0U/Ldq7Apyois vKZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788349346; x=1788954146; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=0WowKxW3bbcijsWVk1Eln6Ny83EI/o2GQF6xiAhpT1s=; b=gC0bW5AKn/E02/jmCgVzU2kODIXINDFwZkeL2gihRutZB8B/hd8mHLq9q/glvdr8hC i2cvHV0Z3Bg1FerJEnXQejhenMeojR2BuHnIUxOzVfoWfCuUOptSS1sAeiVpk6NtKlLP hdBFyVaGL0Rl5E7V1w+8Jjf616+yJmtbnn8KNR28YHxlhK7GLA+0DbUKf6g+Hi4SP6mO yVsMUPiE+6mIZF5DF/gUJBvaKc/IY0JPOgBAz4iW/dsDAqAGXaU5Qyx6alFa8kzcuSC5 +H6fZnDMeixkAyajbCTtbmaLWmlDtBj7oeDW7YtSSpUYu86Fs9ul/ApxC0HumBCvwaiR tGAQ== X-Forwarded-Encrypted: i=1; AKwUvByiM25oSjSfslUj9LNvaPRcXlK19UdBHNlDkJDB+IYvBlF8+NiFM/7A68QEh+HyBsVTyDTbOKqr3Bo=@lists.xenproject.org X-Gm-Message-State: AFuF++miUCVklQzW7QheoXc+cSPeg1N5XueWqANlPegdJH0yeomQeshF YxkRvSEljRbp0YnOLBXtyxtsY3wMMrOdmapJRHbIzS9sSGVQRp+Ni5Ge X-Gm-Gg: AYBFou31mGANGSgnRWxYkbNIC952cj1+/qvJfU7M63U97ZE3FSJq0GTRcz45C/bMj92 khmFfcT3USUObTZHKENxMPqZV2UWszwNasYFjK9rdv10X/+gRkmY6BsYAXJZASEvB4AyIysauCL LN13eJNP3o3RcdWmnqHfOhyNETHYJbO4D398AS4GApsxA9oDN6w0XyCOnQqv0ppjapZI+gl08cb ht4EWAKX20fwaOdfOxEimQdINYARf/0Z9BYq+AguTZNwlk/XoDFaRNY1kSg+0PaA704mzYnrHsM aOzj7Kk6SatM1DuiRHLDMq+t+Uk/ymKUurI3xcqQoAjTNh29ihng3YhA8Ik9mzjZLAzW099v2PY 01eR6u/GjNz+9EwPBnH99iN+hWY3T/zXJrPwOKB5wrXkuW90ZrXapENBflvbMaYmBpeRQuVQ+F4 zoZ89gUwNzdofd0uFK7ZbD+eY/StLTsnUk/URElCHLBrRGclYM5zhWaz3LZMJnNtY4grNy36Szk 2adREIQm1P4+HCAZywVmZV0CdNdyjrLOhkVJlyVSQ== X-Received: by 2002:a05:6000:250c:b0:484:3310:c4fc with SMTP id ffacd0b85a97d-48488f24193mr7778463f8f.23.1788349345634; Wed, 02 Sep 2026 04:42:25 -0700 (PDT) Message-ID: <127e8aea-4d65-492e-8bda-bffc75f02481@gmail.com> Date: Wed, 2 Sep 2026 13:42:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788349346-184CB9EA-4F42F88B/10/73395122804 X-purgate-type: spam X-purgate-size: 3269 On 9/1/26 5:20 PM, Jan Beulich wrote: > On 27.08.2026 17:20, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -88,7 +88,13 @@ static void vcpu_csr_init(struct vcpu *v) >> { >> v->arch.hedeleg = HEDELEG_DEFAULT & csr_masks.hedeleg; >> >> - vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; >> + /* >> + * Xen supports 64-bit guests only, so set the guest's XLEN explicitly >> + * rather than leaving it to the WARL behaviour of hstatus.VSXL, which the >> + * decoding of a trapped instruction depends on. >> + */ >> + vcpu_guest_cpu_user_regs(v)->hstatus = >> + HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(HSTATUS_VSXL_64, HSTATUS_VSXL); > > The comment is correct right now, but the situation better would change > at some point. Can't you arrange for things to be correct here also for > a future where 32- and 128-bit guests would also be supported? I am not sure about 128-bit guests as H extension is dependent on RV32 or RV64 but probably it will be changed: ``` The hypervisor extension depends on an "I" base integer ISA with 32 x registers (RV32I or RV64I), not RV32E or RV64E, which have only 16 x registers. ``` I will introduce the following (also it will be needed also to check if we could VSXL set at all as implmentation can make that field read-only and do VSXLLEN=HSXLEN): /* * Return the hstatus.VSXL value encoding the guest's XLEN. The switch() * deliberately has no default case, so that adding a new domain_type (a * 128-bit one, in particular) fails to build until this mapping is updated. */ static unsigned int domain_vsxl(const struct domain *d) { switch ( d->type ) { case DOMAIN_32BIT: return HSTATUS_VSXL_32; case DOMAIN_64BIT: return HSTATUS_VSXL_64; } ASSERT_UNREACHABLE(); return HSTATUS_VSXL_64; } It will also affect then common code as vcpu_csr_init() could be then called before domain type is set: +++ b/xen/common/device-tree/dom0less-build.c @@ -812,17 +812,18 @@ static int __init construct_domU(struct kernel_info *kinfo, else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) kinfo->dom0less_feature = DOM0LESS_ENHANCED_NO_XS; - if ( vcpu_create(d, 0) == NULL ) - return -ENOMEM; - d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; rc = kernel_probe(kinfo, node); if ( rc < 0 ) return rc; + /* The domain type needs to be known before the first vCPU is created. */ set_domain_type(d, kinfo); + if ( vcpu_create(d, 0) == NULL ) + return -ENOMEM; > >> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >> @@ -68,6 +68,8 @@ >> #if __riscv_xlen == 64 >> #define HSTATUS_VSXL _UL(0x300000000) >> #define HSTATUS_VSXL_SHIFT 32 >> +#define HSTATUS_VSXL_64 _UL(2) >> +#define HSTATUS_VSXL_32 _UL(1) >> #endif > > While adding the two #define-s, would you mind considering to remove the > unused (and supposed to remain so) HSTATUS_VSXL_SHIFT? Sure, I will drop that. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:43:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:43:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405696.1639150 (Exim 4.92) (envelope-from ) id 1x1jNa-0006Be-4k; Wed, 02 Sep 2026 11:43:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405696.1639150; Wed, 02 Sep 2026 11:43:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNZ-0006Al-Up; Wed, 02 Sep 2026 11:43:45 +0000 Received: by outflank-mailman (input) for mailman id 1405696; Wed, 02 Sep 2026 11:43:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNZ-00069Q-KF for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:43:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jNZ-002dmo-0z for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:43:45 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980beb-2eae-0a2a0a5409dd-0a2a4503ab4c-14 for ; Wed, 02 Sep 2026 13:43:45 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980bf0-fae8-0a2a45030019-d1558036cd0d-3 for ; Wed, 02 Sep 2026 13:43:44 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-498028b3d5eso9892545e9.1 for ; Wed, 02 Sep 2026 04:43:44 -0700 (PDT) Received: from andrew-laptop.. ([185.110.61.35]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce46422desm61190055e9.1.2026.09.02.04.43.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 04:43:43 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788349424; x=1788954224; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=WoMupA15p1j9FxYGosrZSTQl8rtEPyPBGX/n1/nILow=; b=ohB6gVGaTZvHaF+oH49vT6DipN7SqGCBy+eueKm9vYnm3VDAsabsN40bMdSTetWgGk hutr1tUdac6SwIpY6yK2RUsOLGauFm4PikPPPyvYn4jORPu4ctmz5RyIHDyve+XlZIRP P1105ArUUe2wrx9uSzXeJeuviuUVXDdm0nSsM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788349424; x=1788954224; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=WoMupA15p1j9FxYGosrZSTQl8rtEPyPBGX/n1/nILow=; b=PjdrHAdH6RYv1nn6KRqPJK6rGjDBInyX1ueea9sok6JF0noj+L6GSBwspHS1/VAEH8 RFVsy251o0lX4HWnRWp3ke1fYdlFILF/baHI855K/tY5TqH3HFr0u81C+l1eXlVNP2xG N6z/snEOouEUtvA2MpxER9LbcIhhtSN/HgJf8/pTIw13tbPQtYHvFoXwtzgGcNKHDIoe yZEqcyENGLoDfvRyGTwhz4HojdhO5VN3Et8s6XvjaT+OqYywRNSNkZwIQGDCw2DqoUrT OnQEps0nkJR5jG5ZmAnYUvN6jLM6UKMCwMqLc0CrVfam+42g1NmMHQgHegpIfL2O0a2H Ryig== X-Gm-Message-State: AFuF++kClMw8/lMGP32GZCQj4WOiRoLIfKzJvAel+VTmJyGYQuD72y9v MjdX+UwlY3m2q8EJ1C6uFKQTYVXVuLH1cRrr70ni3+1+XzsnneF5vVwzsFemRW+qVkeLccM066D PAv2hpyU= X-Gm-Gg: AR+sD12IvLMlwTDzNs7tah0dIVwgC45TdvV1VPIxyx65MTnjmO98NTs83shzh1ryzoS jPOpfxam6fKcH4axcoHx14Qiky4WpzWR75ak16otUqaDCZXlwFqkfAoPoqVgjdz3och5JBuw6Av UpKH97zgjj121Bk1P5TNTcw9E5P6A5GTfYlaibiazXJ7/W7Z45Kgev+vpj0UTG+GRjBbOpzFfAz s5CrV8Bcr9A97YXsBSkgaG4TFsPKi3KdBieenGOaJoXh3VuW/SwS0AehkNg6ZaGsvEcZOyGMOIx iJwXViZlq9o05UgPinI0rebrOPtbfPB8aQSXqkcx8FoVl4CtmwqBG84X7liFX+83rzC9TKT8hXn 84hj7gogrVQiksZkOAsS5q2Sdep+gKOHiDYuzQbYEPdTBTLomXt+eeJ5WC+hikuO25GLPMxPfes 2QXXeDeOIvsp9B+se7W4HT3aDJ5kFzOmhBTpFcmDHS5OGlyQM+X/kfv4lbZGNPshxPN6h9kJkAA gwBSenKIQ== X-Received: by 2002:a05:600c:8b88:b0:49c:e1cd:536 with SMTP id 5b1f17b1804b1-49ce584b899mr75422905e9.12.1788349424249; Wed, 02 Sep 2026 04:43:44 -0700 (PDT) From: Andrew Cooper To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 2/4] x86/bitops: Remove CONST_ADDR Date: Wed, 2 Sep 2026 12:43:37 +0100 Message-Id: <20260902114339.62043-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260902114339.62043-1-andrew.cooper3@citrix.com> References: <20260902114339.62043-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788349424-7488A4E9-A9FA11DC/0/0 X-purgate-type: clean X-purgate-size: 1467 All this does is obfuscate the usage sites. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie CC: Stefano Stabellini CC: Julien Grall CC: Bertrand Marquis CC: Michal Orzel CC: Volodymyr Babchuk --- xen/arch/x86/include/asm/bitops.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h index 69ffed510c0a..fbcab32fd239 100644 --- a/xen/arch/x86/include/asm/bitops.h +++ b/xen/arch/x86/include/asm/bitops.h @@ -18,7 +18,6 @@ */ #define ADDR (*(volatile int *) addr) -#define CONST_ADDR (*(const volatile int *) addr) /** * set_bit - Atomically set a bit in memory @@ -285,7 +284,9 @@ static inline int variable_test_bit(int nr, const volatile void *addr) asm volatile ( "btl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit) - : [addr] "m" (CONST_ADDR), [nr] "Ir" (nr) : "memory" ); + : [addr] "m" (*(const volatile int *)addr), + [nr] "Ir" (nr) + : "memory" ); return oldbit; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:43:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:43:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405695.1639145 (Exim 4.92) (envelope-from ) id 1x1jNZ-00069c-Ta; Wed, 02 Sep 2026 11:43:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405695.1639145; Wed, 02 Sep 2026 11:43:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNZ-00069V-O0; Wed, 02 Sep 2026 11:43:45 +0000 Received: by outflank-mailman (input) for mailman id 1405695; Wed, 02 Sep 2026 11:43:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNX-00069G-Qc for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:43:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jNX-00GR2t-7G for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:43:43 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980be4-8faa-0a2a0a5109dd-0a2a4501b802-28 for ; Wed, 02 Sep 2026 13:43:43 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980bef-5984-0a2a45010019-d1558033e5a3-3 for ; Wed, 02 Sep 2026 13:43:43 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4957eefd361so6257155e9.1 for ; Wed, 02 Sep 2026 04:43:43 -0700 (PDT) Received: from andrew-laptop.. ([185.110.61.35]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce46422desm61190055e9.1.2026.09.02.04.43.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 04:43:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788349422; x=1788954222; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=FNHNJ5oP6qc80904CbFCtBGISp3TOMtzo4M993nbReA=; b=ChjnjY8IQc5VNzdTrE8Qm9uD8gSfSXpWY+8uNVo2mr/Oy1RhzVGXTRJA8L4C9dSH/f ptec0qv+z8KLoKf4dZaW6N8yp70ni4E1CgoRPvDFLkvOK2CllvP/nNAgAkJ9b22qJ+oU crQicPd8hgPyyDfMAONgSTZE4W1PzEny1/cME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788349422; x=1788954222; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=FNHNJ5oP6qc80904CbFCtBGISp3TOMtzo4M993nbReA=; b=YnYXYP7mZeXR5Fc9k1Cd85GT7EYckgtPloIIvZCKYDNvDxyz84uYXY2Bxkvx3UC7gO M+hFFiDo2bRoz/I4JWn+7PBykL3mDKxQPJq4niIwPUmUgwIcUrhhJ8Plz4Zgy6sxVa/c xZcZRK2qIF4N67LcJF+4I8WejR3VSEOqosj4A0C6tMu5x1pY2DcuXq40kkub0eDtJMeE I1KLnk8d2Vv6ZF9bf08N2BBGXNLdgwO9ZZa9sZF3GVCzVKEOB5rGKgcYaFWFR0hLqipx jpEb/EOt6TliqVNGRUYwFYkZlvrgVkw/QCNwjSjT2N/TnLS7x4ZNW3Tq3rTZPHBrglFA Zcig== X-Gm-Message-State: AFuF++mgIxyFy7/6pWVBrg3FaFZKo73v4pvWFp9TzdA2GyXOWQikR0RQ I/bJbOmJcuzRtPT7dxEtYnQssvRQUBotiRPpaMGdt0zt5aex7ncJZ4Siwd6VAOvi5/02DoUY5Mb 8ERK3 X-Gm-Gg: AR+sD12av10pJaGFNnFlkNOREdjed0LXc0AEEfrTPKkbSiQQKAqlCbDF10+p1XZ9vRw 9eh6X8mW0G+9LQoAPh9zCminHLbI852b/vu2D85VHfQ+hVGgKQxAlRlbmcqwkWjfpZdct5L4lOR mvARaVgTFqW646nP1m8grnXzuTBgIieJnl9sJs5hs7euMkvNOa84YKjXmeMPY+3OBBVRG//QgW2 baZWUgu4m+TqWV++tX2SrfhmgtkVu+4aAjUMWcCNanUR0Kl/NbSwib9kO3rqr6k0393Qn9ynSFv +Y+qFAfqCVDE/n9VhpKgy9V9FtNk1QnN/+FuRjKW60Qx/LIzXk8ZlF58R6sPUBnxnYmG+LA/WXb 7g3T68pgNJKSzVRVC1bty/lxVHp2+eADIAT6tSakeiqu2DbPgwBL2OHDxSoKFm/z1qM91081w1e bQpI/nPUl1JjWgPOaMKgfjxs/kIbHCxR7Dl2Jk3WDZONjLTxu4tUZyYflqK1lgW1MWtVrB8Z0= X-Received: by 2002:a05:600c:3f08:b0:49c:e1ed:26b1 with SMTP id 5b1f17b1804b1-49ce5850cefmr78059665e9.16.1788349422028; Wed, 02 Sep 2026 04:43:42 -0700 (PDT) From: Andrew Cooper To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 0/4] xen/bitops: ADDR removal Date: Wed, 2 Sep 2026 12:43:35 +0100 Message-Id: <20260902114339.62043-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788349423-BF063757-78E4D738/0/0 X-purgate-type: clean X-purgate-size: 417 Andrew Cooper (3): arm/bitops: Drop unused ADDR macros x86/bitops: Remove CONST_ADDR x86/bitops: Remove ADDR Jan Beulich (1): x86/bitops: don't cast away volatile-ness docs/misra/rules.rst | 3 +- xen/arch/arm/include/asm/bitops.h | 3 -- xen/arch/x86/include/asm/bitops.h | 51 ++++++++++++++++++------------- 3 files changed, 32 insertions(+), 25 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:43:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:43:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405697.1639162 (Exim 4.92) (envelope-from ) id 1x1jNb-0006ZM-Av; Wed, 02 Sep 2026 11:43:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405697.1639162; Wed, 02 Sep 2026 11:43:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNb-0006Yj-5q; Wed, 02 Sep 2026 11:43:47 +0000 Received: by outflank-mailman (input) for mailman id 1405697; Wed, 02 Sep 2026 11:43:45 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNZ-00069P-T4 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:43:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jNY-009O8V-TU for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:43:44 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980bec-e002-0a2a0a5209dd-0a2a450ad538-22 for ; Wed, 02 Sep 2026 13:43:44 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980bf0-f2d2-0a2a450a0019-d155802cac44-3 for ; Wed, 02 Sep 2026 13:43:44 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-495590dde14so9372785e9.0 for ; Wed, 02 Sep 2026 04:43:44 -0700 (PDT) Received: from andrew-laptop.. ([185.110.61.35]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce46422desm61190055e9.1.2026.09.02.04.43.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 04:43:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788349424; x=1788954224; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9GFfQbIk/OgSpRvploWqTdOJSAjJQBjidS2m4ZMLgpE=; b=FUbQZ9kVMeSRf9hz+iOjy1HIp4jJks83SWl79NsJk4SGofm7fwaZUhRsaNqaeHG+SR MAIXJ/+AfrJWqfk7DWxzrG8w0D/gs6+QlgCk5d1DIZuFZGJLvdjvyiNU1YLlGWQ/EbGq 94p+LgkxqFd8CfU4Q462KRo4pCfhcUV21ai1w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788349424; x=1788954224; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9GFfQbIk/OgSpRvploWqTdOJSAjJQBjidS2m4ZMLgpE=; b=lZ469Awtf+6/XSwSTodoT/qbSQXMAP937OoRCa+NCFCHMSLiPtlfnK7PMwMuZJUJVk 4dyLaGur5zqAFGvKBXOwn1gVw4y6WjUGqBD/oC5MzqMzLTuJEORrBZZ9Xkihp6hoA8Zn 2k2LsL+sgBGMwYK24CZS/2dNpIJsffm8Sf0vuEM8j58N2fdzGHAcgdO2ZrBUl6cmClVt jwD4HhN21SAmz+8sd6WEr3NpGOgRN0ivHvZq0aYGGlV26AXUmaPa0W8QBYwaFzd+8kJN zqYg4lHjxKItA8NqghGLuBjzuH/rkyy9cTKvKXj/rHMhhyU/Mo5x+5hLajgtVBOHTJH1 DDvw== X-Gm-Message-State: AFuF++nvf3VP2XDxEKBejk5dss+zhatSPdfJ69/2rcu7HkkGmDjUHAYg 9H0KgLaPKKXpRAoEpv2bvrAoHtiweepSuHERc7D322FrV8UwAbWrzOgFSZ5/uMczsnPDMU1mL2c 7b7bFnMQ= X-Gm-Gg: AR+sD12hg5C8ZL343OUXEKwqSJZ/sT5wAXUARud889puV9hJZw3Ffvc/HBWhX8r/Jqx MKB6yBdIQPbNZH+aCy0n722kYRKpcMdFublgHyuIFF37Ya4rZFAAkIDMZ6pRRn6G4UntogRzt30 UOuIKNnXtNFQZyUM51HzDIx4jvlSv6LAIPjUngamrOyEdBnBpFmMFNza/5R/Zd7/E5xOZpOQtlD Cw5HB+v0dv6txId6f4DcIXUGvteH3xSRtaCr5fwxpVFsU35fG09EC4DGRV1IGurMkY5eUGuKOUT LIAf0qX6GQrJRk1gLrO8dWhHLNSpJwV9qCyuQnVivBkbzn9bF4HbB653+rlZdCbafJfWftzptxu AIEH6ACjf/dhBH23XUReRb6RRkfr70urJGGAZV4ZPBcsTBqdmgRBC1Pf3dyJrvZ0OW9Vqc/a62z atI9k7TzPDIfJdTcjw6NYIhh9Zc0/qIWl+VYaL/VyWDT6TqZF2qgthboQLiqdRTeXE4KkQ+8OHl YvWMLLyAw== X-Received: by 2002:a05:600c:524f:b0:49b:8c63:dfdf with SMTP id 5b1f17b1804b1-49ce584c87bmr71173625e9.15.1788349422844; Wed, 02 Sep 2026 04:43:42 -0700 (PDT) From: Andrew Cooper To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 1/4] arm/bitops: Drop unused ADDR macros Date: Wed, 2 Sep 2026 12:43:36 +0100 Message-Id: <20260902114339.62043-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260902114339.62043-1-andrew.cooper3@citrix.com> References: <20260902114339.62043-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1788349424-518C5CFC-7727E496/0/0 X-purgate-type: clean X-purgate-size: 1086 These are unused and do not want new users to appear. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie CC: Stefano Stabellini CC: Julien Grall CC: Bertrand Marquis CC: Michal Orzel CC: Volodymyr Babchuk --- xen/arch/arm/include/asm/bitops.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/xen/arch/arm/include/asm/bitops.h b/xen/arch/arm/include/asm/bitops.h index 60686a3a5503..52131892b1f1 100644 --- a/xen/arch/arm/include/asm/bitops.h +++ b/xen/arch/arm/include/asm/bitops.h @@ -22,9 +22,6 @@ #define __set_bit(n,p) set_bit(n,p) #define __clear_bit(n,p) clear_bit(n,p) -#define ADDR (*(volatile int *) addr) -#define CONST_ADDR (*(const volatile int *) addr) - #if defined(CONFIG_ARM_32) # include #elif defined(CONFIG_ARM_64) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:43:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:43:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405698.1639171 (Exim 4.92) (envelope-from ) id 1x1jNc-0006nT-IC; Wed, 02 Sep 2026 11:43:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405698.1639171; Wed, 02 Sep 2026 11:43:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNc-0006nK-Dg; Wed, 02 Sep 2026 11:43:48 +0000 Received: by outflank-mailman (input) for mailman id 1405698; Wed, 02 Sep 2026 11:43:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNa-0006M9-JD for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:43:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jNa-002dpt-01 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:43:46 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980bf1-2eae-0a2a0a5409dd-0a2a450c86b0-0 for ; Wed, 02 Sep 2026 13:43:45 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980bf1-f479-0a2a450c0019-d155802ad0e9-3 for ; Wed, 02 Sep 2026 13:43:45 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b392ccaacso13565075e9.2 for ; Wed, 02 Sep 2026 04:43:45 -0700 (PDT) Received: from andrew-laptop.. ([185.110.61.35]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce46422desm61190055e9.1.2026.09.02.04.43.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 04:43:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788349425; x=1788954225; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=V2J37vG8ht9VCq82ApqJLmvWX3G+XIBcAFjZqFJr6yg=; b=JA/2f/Fwp2hwdQ0X50xymNlO7nG/nx2b8guoL0RRHSoGf+ZqRNwXt7kFCwmbyr7N52 Q4kaWflS13d/t4IUsu9Gx8Mw84ONpGC+PiYfdmiwYT4K/Z3qHZ6ZSMs0rsXnunDRbTk7 QiMshU9TQCr7YbASV6WvmSdLeABRrXWQGcLdY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788349425; x=1788954225; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=V2J37vG8ht9VCq82ApqJLmvWX3G+XIBcAFjZqFJr6yg=; b=sGGRljf685u1zhquKViOT01vdKJ6bT7/nHlgWTdKAXlHLmR5uHKVSV30jhfjyEBENL RffPfKCUn4nbBAZnGCzSoJ09uBPPpt7PNyItkRzipjcPIwnRv3XL58H0YS8nKGo97lUv x6irLLU3eDdIirt85v37kgsn8Q6K17/FLczLLSeTJLhpOV1LkEnt70zpO+B8bZue/FRu oXk0r57Et1pfZ/CQDX6mADQwA4LJddQaTqVgFiTh/ujk6yHLF/yOA99uhdiiFXhSNbeJ 05msodqhXUqa467PNSwb6TaaCIh25VCT1DeEWkOOOMTOmjCRBmvlRd5yVyRpKAIcjQ85 jDxQ== X-Gm-Message-State: AFuF++kZd5kDtLxx/NVzKgOZn05WZJf8ETKuCSFMOj2yXiyeI8Fg6dS8 jP3u3J30tVRhOXpbBp/rBbPJjqLG5Ir31axHPvyPfzCrgECfTOJ6LeycxZoY9uFWKrRgIsrGhhi 7cLb2aZA= X-Gm-Gg: AR+sD12Hp38EI5556RLdPWRF9cF1jAGZ3fsiKtLQ9inie+iAb3XnUhy5s4dAmDkuC9S gdQJ3WWDfW7aGlmk9kngyz4MI2CQm+/ml/PwNk9RtdfW8ccrX3XQ8zAs1C2fTrZihP4qfAqxgnQ unPnHZaydy1DYrNA/zhgY1bnFDkG59TH6qyRfjfQrrvTtEfWheo+ufKVjGP7cXtG4I8VISj1KXP txax380oWH6VVQ3FqZqHQwW9nlucYwA/E840I5EuBXflmGAD5WZmuznNtb/pLmM5GdqSenCyFFz FGRRjbm104VgwYHM9GlS6mpTDej/XK7gmVb2GHi/wlXjF9U7SW7MxFmzA4qTwkK4yB1xu6FKkYW sLpAcBFDFEnyjKxcaBo/KVeUceqOn4JnKk5r7QORuUJ+NbPKJrgkRuuamUdY8keD6rhyWp9v92Z XWwBWxuKVVHkGRpHc/s5PxSfTBdvGCas3Nu2qwmYTIFjFTV846sUolPNQRCnHv/GMYkzZQNKQ= X-Received: by 2002:a05:600c:530e:b0:49c:d618:e341 with SMTP id 5b1f17b1804b1-49ce584bb4amr83885245e9.14.1788349425011; Wed, 02 Sep 2026 04:43:45 -0700 (PDT) From: Andrew Cooper To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 3/4] x86/bitops: Remove ADDR Date: Wed, 2 Sep 2026 12:43:38 +0100 Message-Id: <20260902114339.62043-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260902114339.62043-1-andrew.cooper3@citrix.com> References: <20260902114339.62043-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788349425-020C1A5B-99BEC875/0/0 X-purgate-type: clean X-purgate-size: 4833 All this does is obfuscate the usage sites. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie CC: Stefano Stabellini CC: Julien Grall CC: Bertrand Marquis CC: Michal Orzel CC: Volodymyr Babchuk --- docs/misra/rules.rst | 3 ++- xen/arch/x86/include/asm/bitops.h | 34 ++++++++++++++++--------------- 2 files changed, 20 insertions(+), 17 deletions(-) diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index b3e929307d51..d6be4b0c5d43 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -212,7 +212,8 @@ maintainers if you want to suggest a change. static inline void set_bit(int nr, volatile void *addr) { asm volatile ( "lock btsl %1,%0" - : "+m" (ADDR) : "Ir" (nr) : "memory"); + : "+m" (*(volatile int *)addr) + : "Ir" (nr) : "memory" ); } #define set_bit(nr, addr) ({ \ if ( bitop_bad_size(addr) ) __bitop_bad_size(); \ diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h index fbcab32fd239..45fc64474344 100644 --- a/xen/arch/x86/include/asm/bitops.h +++ b/xen/arch/x86/include/asm/bitops.h @@ -9,16 +9,6 @@ #include #include -/* - * We specify the memory operand as both input and output because the memory - * operand is both read from and written to. Since the operand is in fact a - * word array, we also specify "memory" in the clobbers list to indicate that - * words other than the one directly addressed by the memory operand may be - * modified. - */ - -#define ADDR (*(volatile int *) addr) - /** * set_bit - Atomically set a bit in memory * @nr: the bit to set @@ -32,7 +22,9 @@ static inline void set_bit(int nr, volatile void *addr) { asm volatile ( "lock btsl %1,%0" - : "+m" (ADDR) : "Ir" (nr) : "memory"); + : "+m" (*(volatile int *)addr) + : "Ir" (nr) + : "memory" ); } #define set_bit(nr, addr) ({ \ if ( bitop_bad_size(addr) ) __bitop_bad_size(); \ @@ -73,7 +65,9 @@ static inline void constant_set_bit(int nr, void *addr) static inline void clear_bit(int nr, volatile void *addr) { asm volatile ( "lock btrl %1,%0" - : "+m" (ADDR) : "Ir" (nr) : "memory"); + : "+m" (*(volatile int *)addr) + : "Ir" (nr) + : "memory" ); } #define clear_bit(nr, addr) ({ \ if ( bitop_bad_size(addr) ) __bitop_bad_size(); \ @@ -140,7 +134,9 @@ static inline void constant_change_bit(int nr, void *addr) static inline void change_bit(int nr, volatile void *addr) { asm volatile ( "lock btcl %1,%0" - : "+m" (ADDR) : "Ir" (nr) : "memory"); + : "+m" (*(volatile int *)addr) + : "Ir" (nr) + : "memory" ); } #define change_bit(nr, addr) ({ \ if ( bitop_bad_size(addr) ) __bitop_bad_size(); \ @@ -162,7 +158,9 @@ static inline int test_and_set_bit(int nr, volatile void *addr) asm volatile ( "lock btsl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (ADDR) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (*(volatile int *)addr) + : [nr] "Ir" (nr) + : "memory" ); return oldbit; } @@ -208,7 +206,9 @@ static inline int test_and_clear_bit(int nr, volatile void *addr) asm volatile ( "lock btrl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (ADDR) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (*(volatile int *)addr) + : [nr] "Ir" (nr) + : "memory" ); return oldbit; } @@ -268,7 +268,9 @@ static inline int test_and_change_bit(int nr, volatile void *addr) asm volatile ( "lock btcl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (ADDR) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (*(volatile int *)addr) + : [nr] "Ir" (nr) + : "memory" ); return oldbit; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:43:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:43:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405699.1639175 (Exim 4.92) (envelope-from ) id 1x1jNc-0006po-Ox; Wed, 02 Sep 2026 11:43:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405699.1639175; Wed, 02 Sep 2026 11:43:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNc-0006pE-LF; Wed, 02 Sep 2026 11:43:48 +0000 Received: by outflank-mailman (input) for mailman id 1405699; Wed, 02 Sep 2026 11:43:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jNb-0006XK-6f for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:43:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jNa-002dpt-JZ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:43:46 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980bf1-2eae-0a2a0a5409dd-0a2a450c86b0-4 for ; Wed, 02 Sep 2026 13:43:46 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980bf2-f479-0a2a450c0019-d155802ced19-3 for ; Wed, 02 Sep 2026 13:43:46 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so9470345e9.1 for ; Wed, 02 Sep 2026 04:43:46 -0700 (PDT) Received: from andrew-laptop.. ([185.110.61.35]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce46422desm61190055e9.1.2026.09.02.04.43.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 04:43:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788349426; x=1788954226; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=UPYy19A3VYnJ024xk3KSPpW7Iy5omW83P4l1qm8dQF8=; b=IO6uFrMWviobIVYavFcstMOKvicLVopc8qCNhnPgWraK5QuVGVB4jCehrAfbKY+o1I zoqVmyEGT3MgrZ47YgssqqCkZuA0p/+F4bwI8W14JjWonKpcdzfmiNRkX30sh8ymQ5ms lBVhYLtCFFe5NckXzMa9FI0qR0P2/Q0+BVdPc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788349426; x=1788954226; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=UPYy19A3VYnJ024xk3KSPpW7Iy5omW83P4l1qm8dQF8=; b=C9gRq8VrmS6oPi1nEguj4aUyQBX/oRzNmbIRp0kxQy6NsUhOmxdHzR0uBwyciWndhB drzvcgvD5rDIi0sTMi94LNHEgHEOBnw+ig8ARjWiRujBKz4GE5gRNszkz7VANlyCBEl1 a0XvuY8OMhVbRj+AxBVyC5uHp5ObFN7oWXByRdnWaFOXu0XcrgVnQVb9F4qC3T3OYmz0 J/o0TiIuLL1LRTiwn/5exDTFZ1CxN5QlJh/FI/Da5/7jcAmkmS0FiM3kX4idJQvlR8zr QpQ2P5XBbSqa+Z0ysElzfJAc1AQgLhg6GKIiMfM5SSwId3IiqUujr51fudEnXsLeuZRi dB2Q== X-Gm-Message-State: AFuF++lHNqHEeQREgQoIW+lkI6WyMY+Ro+sTWd/EQryvPt2U7wDH8Zk4 YmmvEF+tvuUG3sFw0vNIzK1g3uBloZT1IPRViV5vsuu34BeTUsqqA84qZ+9yUA64DJlrcnD2cD9 oRQbXMRg= X-Gm-Gg: AR+sD12ignx7cKVomi4oOlW5loU8HJEIsASsu+HBT35qqcqVnLIQV9xQOrZ8INujhJm Ggk53+ptOkgiPaJ3RWP3E5UrE0eqD7r4Wglh4yuTh9VJO+/be2njWWhkGyWbfSPXbHQ5wuq1ghv fTvemrzd5kQ/ON8P1C6aWV3a5VOZUloTnwzjv09W/rEqxT1A4NpU6IB4J5LzRwxe/6h1HWQyB+b sEq3BlgAiCFfTdzNeUw+t/lXEIECyaDG2psIiZxm5TVGC0Fspw8dfEddVMQcSMFTtk0bvHG3Xzw a31Y6vZ3P9Bb0vYjwBihj5nbFylzgGCPgUg11GWv+oxBNDnSQ6tRafq+PBeaq7fRQ7YqTmMAzIG lxJozXuLWqPnThY26f7G+nV63UJJYzsaN9CK4kAWMAYlK1E3PM2jvhiKRGVzHvy6hp1Yx+fsJhK 8y09xnD8wbyLs8Eu7qOj7AoT1w7zr0H/B2InoMhvuCOZe8aMss27i9NxtX+FdVOLeCLaI+M3Aj X-Received: by 2002:a05:600c:1906:b0:499:8b13:3a98 with SMTP id 5b1f17b1804b1-49ce57e7a9dmr68340755e9.4.1788349425726; Wed, 02 Sep 2026 04:43:45 -0700 (PDT) From: Andrew Cooper To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH 4/4] x86/bitops: don't cast away volatile-ness Date: Wed, 2 Sep 2026 12:43:39 +0100 Message-Id: <20260902114339.62043-5-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260902114339.62043-1-andrew.cooper3@citrix.com> References: <20260902114339.62043-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788349426-5270FA5B-662980E7/0/0 X-purgate-type: clean X-purgate-size: 2542 From: Jan Beulich Doing so, besides being a bad idea in general, violates Misra rule 11.8. Use the helper macro we have available anyway. No functional change intended. Fixes: f1879b2c2584 ("xen: introduce generic non-atomic test_*bit()") Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie CC: Stefano Stabellini CC: Julien Grall CC: Bertrand Marquis CC: Michal Orzel CC: Volodymyr Babchuk Rebase over removal of ADDR. --- xen/arch/x86/include/asm/bitops.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/bitops.h b/xen/arch/x86/include/asm/bitops.h index 45fc64474344..8f6bea388035 100644 --- a/xen/arch/x86/include/asm/bitops.h +++ b/xen/arch/x86/include/asm/bitops.h @@ -185,7 +185,9 @@ static inline int arch__test_and_set_bit(int nr, volatile void *addr) asm volatile ( "btsl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (*(int *)addr) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (*(volatile int *)addr) + : [nr] "Ir" (nr) + : "memory" ); return oldbit; } @@ -233,7 +235,9 @@ static inline int arch__test_and_clear_bit(int nr, volatile void *addr) asm volatile ( "btrl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (*(int *)addr) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (*(volatile int *)addr) + : [nr] "Ir" (nr) + : "memory" ); return oldbit; } @@ -247,7 +251,9 @@ static inline int arch__test_and_change_bit(int nr, volatile void *addr) asm volatile ( "btcl %[nr], %[addr]\n\t" ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit), - [addr] "+m" (*(int *)addr) : [nr] "Ir" (nr) : "memory" ); + [addr] "+m" (*(volatile int *)addr) + : [nr] "Ir" (nr) + : "memory" ); return oldbit; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:47:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:47:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405739.1639188 (Exim 4.92) (envelope-from ) id 1x1jRX-0000PS-En; Wed, 02 Sep 2026 11:47:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405739.1639188; Wed, 02 Sep 2026 11:47:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jRX-0000PL-C6; Wed, 02 Sep 2026 11:47:51 +0000 Received: by outflank-mailman (input) for mailman id 1405739; Wed, 02 Sep 2026 11:47:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jRW-0000PF-16 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:47:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jRV-00700f-9w for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:47:49 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980cd8-8faa-0a2a0a5109dd-0a2a450be758-34 for ; Wed, 02 Sep 2026 13:47:48 +0200 Received: from [52.101.56.38] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980ce3-b7e8-0a2a450b0019-346538269000-3 for ; Wed, 02 Sep 2026 13:47:48 +0200 Received: from BN0PR07CA0029.namprd07.prod.outlook.com (2603:10b6:408:141::11) by PH7PR12MB7967.namprd12.prod.outlook.com (2603:10b6:510:273::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Wed, 2 Sep 2026 11:47:44 +0000 Received: from BN2PEPF000055DD.namprd21.prod.outlook.com (2603:10b6:408:141:cafe::ae) by BN0PR07CA0029.outlook.office365.com (2603:10b6:408:141::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Wed, 2 Sep 2026 11:47:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF000055DD.mail.protection.outlook.com (10.167.245.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.0 via Frontend Transport; Wed, 2 Sep 2026 11:47:43 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 06:47:43 -0500 Received: from [10.252.145.116] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 06:47:42 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Vy7f98JuLC0MWazR3/XgjLzjPreqyu5j+Mjx0t56d0YcfcePM2kspj6b9hclQz+R6SMwn5o/CVbXAbVvAPi2xJE4MECZcKsL09Xk/6kvp+tztcivM2Hmy1ojwdX5/q+3XzIDxryBwEtnDkBkkAdYk+PrgNMHCaMwvSAXdKmEtRNwadFHM78d/v140Hz1voVunYNjm84XR4Gf78PnoMJmiYcPZs2w/+H/VPqL6gvg5NgJ6JTw7R+rz/MghzZztt46+w4CLUpe/Q61Zuudwk6y4XurnQ3CeofXcr46tXUD1k21TDEbkRvUReYXtMqhXefBNtwc0VmSTY19huOoNmFCCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yj0snSe6erq9pFcsQNTsOsWW4pZ2V4+nXZnGyipvatc=; b=kAEUoNbGdVXEYAKtBWELWA6jNQ2H4v/Px5Kc3rz4wGoTi1pZmuVZQ/TOmKqAu/zqqCOJ71m0XMrrxuCnOct0JBprW8TO/wvBQGU3Uwy4v0R2eDgaXsGpL7Sk+qdP4x7dLDWv3+9gwbr8+GAgGkE40jFYCGAbKNXDa206nVr6LfV5nbyhU3X25dEV7RFx32fFMjSUtMGFIiw3EyWpsHOaoKlpDsU3IuOtKxZjLb7WMuoC0MZ7V9pByq4gG0mTWsO2eEHUdZ5ghGfopMEv299PldBPpQpPZ4zYH9VGwk7zVN70ZamyaLddVgEkfYV+6XmQ5GUgHvgGw79V7UrbhVsWaQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yj0snSe6erq9pFcsQNTsOsWW4pZ2V4+nXZnGyipvatc=; b=Sr3Ssv1WFek+dxT114ukNA+5kXmYEm0U4DSmyw7HqfW/Ku/syZkJUc+QLA6OvIPxgDAQyNehhmowzk76bRWtWbWufzK4z2i+kt9KFWzQmfqKjD5dDrQ87cK5czcyHu2p+mmSSTibl/TecMHEHVt7X9LAvCtnOeOh4Sj38mpLfvg= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Wed, 2 Sep 2026 13:47:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/14] Arm/alternative: hide casting away of const To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Nicola Vetrini , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <6b3a3849-304f-423b-a3c3-a614d83858c0@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <6b3a3849-304f-423b-a3c3-a614d83858c0@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000055DD:EE_|PH7PR12MB7967:EE_ X-MS-Office365-Filtering-Correlation-Id: 3f99d0be-f9e6-49ee-66f7-08df08e8004c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|82310400026|36860700016|56012099006|10067099003|11063799006|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: ULsMwfIZy7fk4MPY+MtnEC9j1rRcc5vexijHReDxZrrL4OVcUHRKMMxbCY3df9CTxKitZpadfd6E5Y7orpl7qXAqDHuRsf8XmWo4ntYStHn7X8Hl84oP7FJ1V7sB8saBP0or3MNcO0T2jh6KTZjzhqoJP0KZjAM5h3r1exqQpwbeqhdfJDHvIWAtu/H16lwltZKsfq/Z0vP8Hoj/jK7DONmJe4yy3Xny/tvLGAQ0wsCIdTu/A67g0Kqcsbil4fuLoh1NsLE6D+Somq4J1O8p82pJn9xEwXbHLPJSZPb9haL67r6op/bnEIfDytzeFD4RNHsYzbMILWqrweCFZJGvFWI4rhjOLc3l+iZUxynK52FBKAEkklmSDZxozpfDSVk4LRUCnTNkUV0q3o1dU/Ava7glIprAjvfbpD/6yML8mjBt0bqNlvzFwx/QlC2Pbm3JNeUzUvQ6jDNsQ2XqQ4ld/ew+QkhMcsc7bDjjFVCtKwTrLBuI/WSd7LyKiZIwzYK4MDn2DrYwe59GD8r1SQN48Co5/xH51JkjciR7DWjXhjB9c208VBzfnPhUqxKkq4GNYTeaSxnKCWM8D6UjMbzggZUQttWKR0Ma61Ugrxi740b2S8+quvEifDB7O7C6ZbIQloUXOmNlyc9REtH2YtzFrmNWbj3zswiqyyWCf2J4kc8mWxv05qPMfReumVzW87PIxqUFrDZUOuRdyKwUKXC2yg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(82310400026)(36860700016)(56012099006)(10067099003)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Kjr729LZQ/sV5jBfWdw9urr6/vw5+kbQsjbXGH62ZtgXzlXdlYY0ZQJAwn345vAy8QZbpIMPtmKFDnxn+ncTtXWXDADFYs5WYZCT7Pk6Ucxrf6Ij7nhBiMUZDZ1ed2ZUMIdrPkZ0P37dEi8z5W8rDBni/8IeXoNRcitWoOUugKwYwUwUoreDNY55JOayaP2/5s3wH4FllyZdOKlM5GmedydpXgTWvcB0k/0I12f4llSw3+scXL8HyM3fEXHxKOmTI2XBX34pChpZBpMaSChySu+0GzOmTAMysKPN5MS6M6yq/U4NdGbE8wGgFkpQMFX4QQqqgerjdjtHh02zTkbwDNmm6NX0cRdRseYgdKG4wYJACXaBu04IkIY/gGZ1ZihnVfpGKAo6Y/p6B2/Os3IUR+lyKvlTak8GtJA7Yan0orKIHuj08GXhkDJ1fE1N7aIH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 11:47:43.9920 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3f99d0be-f9e6-49ee-66f7-08df08e8004c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF000055DD.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7967 X-purgate-ID: tlsNG-42698a/1788349668-19CC79EA-6E1CFFEE/0/0 X-purgate-type: clean X-purgate-size: 750 On 02-Sep-26 08:32, Jan Beulich wrote: > We want to patch the original call site, which memory-wise is unrelated > to the struct alt_instr * that we start from. > > No functional change intended. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/arm/alternative.c > +++ b/xen/arch/arm/alternative.c > @@ -134,7 +134,7 @@ static int __apply_alternatives(const st > BUG_ON(alt->repl_len != alt->orig_len); > > origptr = ALT_ORIG_PTR(alt); > - updptr = (void *)origptr + update_offset; > + updptr = (void *)(long)origptr + update_offset; NIT: Why long and not unsigned long like other places in this file? Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:51:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:51:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405747.1639198 (Exim 4.92) (envelope-from ) id 1x1jV2-000207-TD; Wed, 02 Sep 2026 11:51:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405747.1639198; Wed, 02 Sep 2026 11:51:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jV2-000200-Q3; Wed, 02 Sep 2026 11:51:28 +0000 Received: by outflank-mailman (input) for mailman id 1405747; Wed, 02 Sep 2026 11:51:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jV2-0001zu-4y for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:51:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jV0-003y8w-G8 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:51:26 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980db5-8faa-0a2a0a5109dd-0a2a450bb97e-34 for ; Wed, 02 Sep 2026 13:51:26 +0200 Received: from [52.101.62.2] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980dbc-b7e8-0a2a450b0019-34653e02ffd9-3 for ; Wed, 02 Sep 2026 13:51:25 +0200 Received: from CH2PR04CA0003.namprd04.prod.outlook.com (2603:10b6:610:52::13) by SA0PR12MB7089.namprd12.prod.outlook.com (2603:10b6:806:2d5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Wed, 2 Sep 2026 11:51:19 +0000 Received: from BL02EPF00029927.namprd02.prod.outlook.com (2603:10b6:610:52:cafe::58) by CH2PR04CA0003.outlook.office365.com (2603:10b6:610:52::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.10 via Frontend Transport; Wed, 2 Sep 2026 11:51:19 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL02EPF00029927.mail.protection.outlook.com (10.167.249.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Wed, 2 Sep 2026 11:51:19 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 06:51:19 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 2 Sep 2026 06:51:18 -0500 Received: from [10.252.145.116] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 2 Sep 2026 06:51:17 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lM58aMhmsHmJ1vDgauCEpwFa5nLe8jqJCrPK5B6p5+ixtjX8EhlBwpET9pOzuHlPVvWI8KeExxbbdU8TFoEBZKp9Pn6uiRw92K/FqaEQMKJ0YReK63R8c0F8axxBedyqXmmEgw9VYPH1BC4Gsdvd9QROVEfUuMDAIS5XQIf0eoZokkxVWn1N9Mwt/CVpGxfFeo0809G5gswkfgyT6DNx0QVyPFBLV3KtqF7kG08Jtot2nDgkrpI0KqOvmzlnegnQPSTOgqGSF/lE5VM6SUpNYGo6dL3RarI2S/RqSVrVUMwvzHwa3vC1ksrAi+o3Q8qGmTw3TQTtLy08UhvnK82GUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WGiXrcXZYO1zW8wBNQqXBAtHNViTp+1t2bPTUOtRa4A=; b=HLiEMeJVZMfanH0SXDFzoX+OQpAkDo+cgC1SgH6aQTZ9jEZ+YcGv0H9Ut2H4qg0P6LPEEqS5icHtpZqww7m4d74uc2h/7VH/PTsdTGNh5vSVmgTNeEB+cVpT27Qxhi5Vff7t85PxX4BShfIrdfPwuvJtJ5AHCLdePbb+ZEyP2R9Zg0iXvseutuPg/MVCdhnEHflO/fNtWIUV3SFH5KsyrAgCXPexK8KJW5u0Xe0MZqHRBQhTFg4hB6YHME/kdFzmk/614pCmVqKG0GFQwzEQP339bRn05ZVfyhhPXFrsLvXGj02ZG5M8+ph9p2jPUi9M4KW4ysqurtp4BF5XJlswJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WGiXrcXZYO1zW8wBNQqXBAtHNViTp+1t2bPTUOtRa4A=; b=ODHvZZqJERZiHcrimJJJN1m7Cqo0ynpz1n4MEBqE3Mwev++e29FlwZd4xaA6NJFOMUG9hM04tvYynIc2WAU8vMRqTj79wMUWdceUGVcYaCw+xOoVmR584BuqR0uINlSghkfqUu0QxmTUi9jdFdDsYC4K2CsjY816skZfucj7Rw4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <90239692-ba75-409f-8342-b3b0da7cd221@amd.com> Date: Wed, 2 Sep 2026 13:51:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] arm/bitops: Drop unused ADDR macros To: Andrew Cooper , CC: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-2-andrew.cooper3@citrix.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260902114339.62043-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF00029927:EE_|SA0PR12MB7089:EE_ X-MS-Office365-Filtering-Correlation-Id: 0977e0e0-d0b7-4278-9fac-08df08e880b2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|82310400026|1800799024|376014|56012099006|10067099003|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: diGNmy3MhZ7ZA+F1I0bAWaKjj2Lf7MmWNfXc4DUmL1+pB+lqRd1WlxtwSWtM5ilrhfqhGqiMApdGMwHN0YUutEOGSC+43I7UdX7QnBZdOhELJFc8l0eMDM12qTSDv1iDSCvNO/EpMAx6OrTxyg5ef/XAIYDHQcqlhhHM5g0XGvX2kh60r+MR3mJ0vyT8R2gF23EZMcEIstbL0ZN4Muv/ZyWmqGgwCveXiiNU3xOkr3IWnM/1iELKcOuPDKVWN03T6IgL0FaqiOoSRy+INSaEDCOhN7JwQvxogLDAPLiyOfyPQ7gzAww6Vol4mvaEbpHk3fnE2vZiAQhZ4OFjPp6BxH3UnWZJsZR2z7pa4rsy832TGqGURLD/NuWIlwM98qKLDo5WkRLlv+PRI/jq3mElTM71DV1MDexivxTpdtMzsyYno4DsCfrO3++N+IvUPWQxh8tKBszd6a2/MoNtGY4RD6DfhZm0Cn6G2wyaMoSCFDbC4a3JYmYuLMcxPP7DaniojuveildQFI7X/X7wDZXsHY+mMA60+mGijpWnQKqFb2jO6FiasttVF18E11kLVIb9ErBTI7Bc3whRtUUh/fuxQnHM08gYEwiQ+qvv+O7K1r9lSIPXOl24DZubFmvQBVJj3ac/RZa7scRZZhTUGGdtNRsDtYbDdRrRR0O2bYtvI3WCMmb4CC0sWSEIvcDiKOoIHQvOKv3THErVb+xDG7WUgw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(82310400026)(1800799024)(376014)(56012099006)(10067099003)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: UtMLDgeqKrNc9ab6olY2HhBklEPhOj6aCfZ6emNXpWMaczxFk3mjQB9e9ndOcGXOVMmqFkHFpiP08qA3PJkqbgA/YA7Xd4w61R/d7P6kS7D+HRnF378y4BMNgwAS0QHZwcTVl2ZXSW/agK7gbJDnRJkZK3lCr6OhabUJi2+9Z/uhWkWOyd42BYUlBpfpzy18VmamlWVt3JJHvlT/+nW/CliHdPL9ByS4zHTgpRs7xRuVdmjgWzSFQ+xdlUuP9ZU2A3SfD3imljyTTrUNrNK2UQiCZ27SBywH7EeS6IwiWNcrpfnPhRT4jXP+aULv+iuRDYW6jJkEiUmGirkGQ4xUK4US3EA1WFvGlLbw4TijoCtLZtNMVv/XrWAT5hZYcQJKV0/wBgurnmCw8v0+hYWceUaStIan6dwq16gQWZvJjChNBCuhQBciw6ZnOG32BJd6 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 11:51:19.4093 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0977e0e0-d0b7-4278-9fac-08df08e880b2 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF00029927.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB7089 X-purgate-ID: tlsNG-42698a/1788349886-A84CB9EA-F9326B50/0/0 X-purgate-type: clean X-purgate-size: 230 On 02-Sep-26 13:43, Andrew Cooper wrote: > These are unused and do not want new users to appear. > > Signed-off-by: Andrew Cooper Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Wed Sep 02 11:52:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 11:52:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405754.1639207 (Exim 4.92) (envelope-from ) id 1x1jVZ-0002QJ-4S; Wed, 02 Sep 2026 11:52:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405754.1639207; Wed, 02 Sep 2026 11:52:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jVZ-0002QC-1L; Wed, 02 Sep 2026 11:52:01 +0000 Received: by outflank-mailman (input) for mailman id 1405754; Wed, 02 Sep 2026 11:52:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1jVX-0002Om-Ex for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 11:52:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jVW-003yFK-Rx for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:51:58 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a980dce-8faa-0a2a0a5109dd-0a2a45048324-40 for ; Wed, 02 Sep 2026 13:51:58 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a980dde-b57f-0a2a45040019-b9ff1c12b00d-3 for ; Wed, 02 Sep 2026 13:51:58 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a061f620c5000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 11:51:55 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 6C04682029; Wed, 2 Sep 2026 13:51:54 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=4Rj/QjRwx9bZQal0N4deeVdgTUJTB5KU1MZwyQkK434=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=i4ZoD8Y6Dtfq6XHUyCy++yXdKZsDC6p3ZTxM2vIqqdOrYYde9GBPoI2oBBSz6dRoRL2BNWQMt r4eibkLvXLqZVG1AgI+Hb45EjEGtDHXYnQ+6b9ZPrvpG6BOzpDsS+lCUq/2+ERhfRwEVnQs8QGp Rj9FmaPFZcl4W751i67gl/HLNTc+oesGTDsqCNqqVzMtWkzUqK9Uzw1CRQsfFhWmAf+srnk0nyx e+1gVqJikRXgzSUsO1XO5SMxOGOqU9szovhe+GiyosG6ReJ5RZEJ4WC5PLiXbJCe/FndT6D9hjG X3UoJz/UUYxIRo3ZDYBNSB/838rqYWvIiuTqnSmqcXFQ== X-Zone-Loop: 0d93d65ffd8a62b4db03ce1c4c61c08cfca768ba6ade x-campaign-type: default x-transaction-id: 3170e725-6a0b-442f-bd3b-d269bf997006 x-swg-uid: 01-114702fe-973f-4847-8306-dfe08c47af98 X-Mailer: Sweego Message-ID: <1788349915.8631fc262581453bbf619ec5b2062170.1a061f620c5000c4f3@vates.tech> x-swg-bid: 1788349915.8631fc262581453bbf619ec5b2062170.1a061f620c5000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> Date: Wed, 02 Sep 2026 13:51:46 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788349914; l=22568; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=2NAlNX/nlpeYCLz4rfJXvamyJ4ZNBnU39utniyWgylg=; b=JmcTXyRw73D7FEedI8S34Lf5dTR3YpYKQP6KauERz3DZdfjCCF2DJUM47MIe5xFdD6JmiCE0n i2BqySgxGl4DE5FwmR0PJeqo7T8cx86+nee5AtRpu+KJ/P7l62F5O5X X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788349914662 X-purgate-ID: tlsNG-ebf023/1788349918-C24CBB50-6AE0616A/10/73395122804 X-purgate-type: spam X-purgate-size: 22568 > Guests running under Xen program interrupt routing by writing to APLIC > MMIO registers. Xen must intercept these accesses to enforce interrupt > isolation between domains and to translate guest routing intent into the > underlying physical MSI topology. > > Writes are gated by the domain's authorised interrupt bitmap so that a > guest cannot affect interrupts it does not own. TARGET register writes > additionally require translation of the hart and IMSIC guest-file > indices from virtual to physical, as the APLIC uses these fields > directly to compute the MSI delivery address. > > Delegation (APLIC_SOURCECFG_D) is not yet supported. > > Co-developed-by: Romain Caritey > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h > index 35100d3a64..b3a1f79c5b 100644 > --- a/xen/arch/riscv/aplic-priv.h > +++ b/xen/arch/riscv/aplic-priv.h > @@ -47,4 +47,7 @@ struct aplic_priv { > */ > extern unsigned int guest_aplic_num_sources; > > +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, > + uint32_t base_val); > + > #endif /* ASM_RISCV_APLIC_PRIV_H */ > diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c > index 3681f0669e..66ba4986a9 100644 > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -28,8 +29,6 @@ > #include > #include > > -#define APLIC_DEFAULT_PRIORITY 1 > - > static struct aplic_priv aplic = { > .lock = SPIN_LOCK_UNLOCKED, > }; > @@ -38,6 +37,127 @@ static struct intc_info __ro_after_init aplic_info = { > .hw_variant = INTC_APLIC, > }; > > +/* > + * The arrangement of IMSIC interrupt files in MMIO space follows a topology > + * defined by the RISC-V AIA specification. An IMSIC group is a set of > + * interrupt files (e.g., in a cluster or socket) co-located in memory. > + * > + * The physical address of an outgoing MSI is calculated by bitwise ORing a > + * Base Physical Page Number (Base PPN) with the Group Index (g), the Hart > + * Index (h) and, for a supervisor-level interrupt domain, the Guest Index: > + * > + * ( Base PPN | (g << (HHXS + 12)) | (h << LHXS) | guest ) << 12 Nit: it should be Guest Index (according to the spec) instead of `guest` wording: ( Base PPN | (g << (HHXS + 12)) | (h << LHXS) | Guest Index ) << 12 > + * > + * where Base PPN, HHXS, LHXS, HHXW and LHXW come from the {m,s}msiaddrcfg[h] > + * registers of the interrupt domain that sends the MSI: > + * > + * XLEN-1 HHXS+24 LHXS+12 12 0 > + * | | | | | > + * ------------------------------------------------------------ > + * |xxxx| g |xxxxxxxx| h |xxxx|Guest Index| 0 | > + * ------------------------------------------------------------ > + * > + * - g: group number. > + * - h: hart number relative to the group. > + * - xxxx: remaining Base PPN bits; each gap may be zero-width. > + * - Guest Index: selects one of the 4 KiB pages right above the hart's own > + * supervisor-level file, i.e. it starts at bit 12; LHXS must therefore be > + * at least as large as the number of guest index bits. > + * - Bits 11:0: always zero because IMSIC files are 4 KiB page-aligned. > + * > + * For wired interrupts in MSI delivery mode (domaincfg.DM = 1) the APLIC > + * builds that address itself from the "Hart Index" field (bits 31:18) of the > + * corresponding target[i] register. That field holds a hart index *number*, > + * in which both indices are packed adjacently: > + * > + * 13 lhxw+hhxw lhxw 0 > + * | | | | > + * ------------------------------------ > + * | 0 |Group Index|Hart Index| > + * ------------------------------------ > + * > + * - lhxw (Low Hart Index Width): the number of bits used for the hart number > + * within a group. > + * - hhxw (High Hart Index Width): the number of bits used for the group > + * number; the remaining bits of the field must be zero. > I think it's not very clear that the schema represents the "Hart Index" field i.e. target[i] bits 31:18. Moreover, the schema like that is wrong as it is not Group Index or Hart Index but `g` and `h`. I'd suggest something like this: * For wired interrupts in MSI delivery mode (domaincfg.DM = 1), the APLIC * computes the MSI target address itself from the "Hart Index" field * (bits 31:18) of the corresponding target[i] register. This 14-bit field * holds both g and h: * * 13 lhxw+hhxw lhxw 0 * | | | | * ------------------------------------ * | 0 | g | h | * ------------------------------------ * * - lhxw (Low Hart Index Width): the number of bits used for the hart number * within a group. * - hhxw (High Hart Index Width): the number of bits used for the group * number; the remaining bits of the field must be zero. > + * > + * The Guest Index isn't a part of it: for a supervisor-level interrupt domain > + * it has its own field (bits 17:12) in target[i]. > + * > + * Because there are "xxxx" gaps (Base PPN bits) between the indices in the > + * physical address (depending on HHXS and LHXS), software must extract the > + * group and hart components separately and pack them into the APLIC-defined > + * Hart Index format to ensure correct MSI targeting. > + */ > +static unsigned long aplic_hart_field(unsigned int cpu) I should have renamed this to aplic_hart_index() as it's formerly what the function returns. > +{ > + const struct imsic_config *imsic = imsic_get_config(); > + const struct imsic_msi *msi = &imsic->msi[cpu]; Nit: this could be const ... > + /* Low Hart Index Shift */ > + unsigned int lhxs = imsic->guest_index_bits; It seems incoherent with the diagram above as there is some xxxx between Guest Index bits and lhxs + 12. Therefore, it is not that obvious that lhxs is equal to guest_index_bits. > + /* Low Hart Index Width */ > + unsigned int lhxw = imsic->hart_index_bits; > + /* High Hart Index Width */ > + unsigned int hhxw = imsic->group_index_bits; > + /* High Hart Index Shift */ > + unsigned int hhxs = > + imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2; ... > + /* > + * msi->base_addr is the base of the MMIO regset this CPU's interrupt So if I understood correctly, msi->base_addr corresponds to the group terminology? Is it always the case? > + * files live in, and one regset can cover several harts; msi->offset > + * selects this CPU's block inside it. The hart index bits are part of > + * that offset, so both indexes have to be derived from the full address. > + */ > + paddr_t target_addr = msi->base_addr + msi->offset; > + unsigned long tppn = target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT; > + unsigned long g = > + (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) & > + APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw); > + unsigned long h = > + (tppn >> APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs)) & > + APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw); > + > + return (g << lhxw) | h; > +} > + > +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, > + uint32_t base_val) > +{ > + unsigned int guest_id = vcpu_guest_file_id(target_vcpu); > + unsigned long hart_field = aplic_hart_field(target_vcpu->processor); Nit: could be const Should be hart_index too, according to previous comment. > + > + base_val &= APLIC_TARGET_EIID; > + base_val |= MASK_INSR(guest_id, APLIC_TARGET_GUEST_IDX); > + base_val |= MASK_INSR(hart_field, APLIC_TARGET_HART_IDX); > + > + return base_val; > +} > + > +uint32_t aplic_hw_read_reg(unsigned int offset) > +{ > + unsigned long flags; > + uint32_t val; > + > + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); > + > + spin_lock_irqsave(&aplic.lock, flags); > + val = readl((volatile void __iomem *)aplic.regs + offset); > + spin_unlock_irqrestore(&aplic.lock, flags); > + > + return val; > +} > + > +void aplic_hw_write_reg(unsigned int offset, uint32_t value) > +{ > + unsigned long flags; > + > + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); > + > + spin_lock_irqsave(&aplic.lock, flags); > + writel(value, (volatile void __iomem *)aplic.regs + offset); > + spin_unlock_irqrestore(&aplic.lock, flags); > +} > + > static void __init aplic_init_hw_interrupts(void) > { > unsigned int i; > @@ -53,9 +173,9 @@ static void __init aplic_init_hw_interrupts(void) > /* > * Low bits of target register contains Interrupt Priority bits which > * can't be zero according to AIA spec. > - * Thereby they are initialized to APLIC_DEFAULT_PRIORITY. > + * Thereby they are initialized to APLIC_TARGET_IPRIO_DEFAULT. > */ > - writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]); > + writel(APLIC_TARGET_IPRIO_DEFAULT, &aplic.regs->target[i]); > } > > writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg); > diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h > index a2af55d54f..babba38607 100644 > --- a/xen/arch/riscv/include/asm/aplic.h > +++ b/xen/arch/riscv/include/asm/aplic.h > @@ -39,6 +39,13 @@ > #define APLIC_DOMAINCFG_IE BIT(8, U) > #define APLIC_DOMAINCFG_DM BIT(2, U) > #define APLIC_DOMAINCFG_BE BIT(0, U) > +/* > + * The bits a write may change. Everything else, including the read-only zero > + * bit 7 and the reserved bits, has to read back as zero, and BE is WARL and > + * hardwired to 0 as Xen is little-endian only. > + */ > +#define APLIC_DOMAINCFG_WMASK (APLIC_DOMAINCFG_IE | \ > + APLIC_DOMAINCFG_DM) > > #define APLIC_SOURCECFG_BASE 0x0004 > #define APLIC_SOURCECFG_LAST 0x0ffc > @@ -89,6 +96,9 @@ > #define APLIC_TARGET_GUEST_IDX GENMASK(17, 12) > /* Bit 11 is reserved and reads as zero */ > #define APLIC_TARGET_EIID GENMASK(10, 0) > +/* If target is in DM mode */ I think this comment is not clear; I expect, by reading it, to have domaincfg.DM = 1 which is MSI mode, but I think you were talking about direct delivery mode, right? If so, I would change this comment to /* If target is in direct delivery mode (domaincfg.DM = 0) */ > +#define APLIC_TARGET_IPRIO GENMASK(7, 0) > +#define APLIC_TARGET_IPRIO_DEFAULT 1U > > #define APLIC_IDC_SIZE 32 > > @@ -98,6 +108,27 @@ > #define APLIC_SIZE(nr_cpus) \ > (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus))) > > +/* > + * Using setip is fine here, as all SET* and CLR* register groups consist of 32 > + * registers and therefore have identical sizes. > + * > + * Lowest 2 bits are always zero for SET* and CLR* registers. > + */ > +#define APLIC_SETCLR_OFFSET_MASK \ > + (sizeof_field(struct aplic_regs, setip) - sizeof(uint32_t)) > + > +#define APLIC_xMSICFGADDR_PPN_SHIFT IMSIC_MMIO_PAGE_SHIFT > + > +#define APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw) \ > + (BIT(hhxw, UL) - 1) > +#define APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs) \ > + ((hhxs) + APLIC_xMSICFGADDR_PPN_SHIFT) > + > +#define APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw) \ > + (BIT(lhxw, UL) - 1) > +#define APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs) \ > + (lhxs) > + > struct aplic_regs { > uint32_t domaincfg; /* 0x0000 */ > uint32_t sourcecfg[1023]; /* 0x0004 */ > @@ -141,4 +172,7 @@ struct aplic_regs { > uint32_t target[1023]; /* 0x3004 */ > }; > > +uint32_t aplic_hw_read_reg(unsigned int offset); > +void aplic_hw_write_reg(unsigned int offset, uint32_t value); > + > #endif /* ASM_RISCV_APLIC_H */ > diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h > index 2425430ed1..93f9e44c7d 100644 > --- a/xen/arch/riscv/include/asm/imsic.h > +++ b/xen/arch/riscv/include/asm/imsic.h > @@ -40,6 +40,19 @@ struct imsic_config { > /* Base address */ > paddr_t base_addr; > > + /* > + * MSI Target Address Scheme > + * > + * XLEN-1 HHXS+24 LHXS+12 12 0 > + * | | | | | > + * ------------------------------------------------------------ > + * |xxxx| g |xxxxxxxx| h |xxxx|Guest Index| 0 | > + * ------------------------------------------------------------ > + * - g: group number. > + * - h: hart number relative to the group. > + * - xxxx: remaining Base PPN bits; each gap may be zero-width. > + */ > + Is this really needed as you already explain this above in aplic.c? Please choose one place between the two if not. > /* Bits representing Guest index, HART index, and Group index */ > unsigned int guest_index_bits; > unsigned int hart_index_bits; > diff --git a/xen/arch/riscv/include/asm/vaplic.h b/xen/arch/riscv/include/asm/vaplic.h > index 96080bfbc2..046c604915 100644 > --- a/xen/arch/riscv/include/asm/vaplic.h > +++ b/xen/arch/riscv/include/asm/vaplic.h > @@ -21,11 +21,16 @@ struct domain; > > struct vaplic_regs { > uint32_t domaincfg; > + > + uint32_t *target; > }; > > struct vaplic { > struct vintc vintc; > struct vaplic_regs regs; > + > + paddr_t regs_start; > + unsigned int regs_size; > }; > > int domain_vaplic_init(struct domain *d); > diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c > index 14f6e3164a..8726f7203d 100644 > --- a/xen/arch/riscv/vaplic.c > +++ b/xen/arch/riscv/vaplic.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > > #include "aplic-priv.h" > @@ -27,6 +28,279 @@ unsigned int __ro_after_init guest_aplic_num_sources; > > #define FDT_VAPLIC_INT_CELLS 2 > > +#define AUTH_IRQ_BIT(d, irqn) \ > + (((irqn) < (d)->arch.vintc->nr_virqs) && \ > + test_bit(irqn, (d)->arch.vintc->used_irqs)) > + > +/* > + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group) to > + * a 32-bit word index into the used_irqs bitmap. Each word covers 32 > + * interrupt sources. For SOURCECFG and TARGET groups the same division also > + * yields the interrupt number directly, because those arrays store one 32-bit > + * register per source. > + */ > +#define regoffset_to_word_idx(reg_val) ((reg_val) / sizeof(uint32_t)) > + > +static uint32_t vaplic_target_read(const struct domain *d, unsigned int irqn) > +{ > + const struct vaplic *vaplic = to_vaplic(d); > + > + /* target[0] doesn't exist so irqn == 0 should be impossible */ > + if ( !irqn || irqn >= vaplic->vintc.nr_virqs ) > + return 0; > + > + return read_atomic(&vaplic->regs.target[irqn]); > +} > + > +static inline uint32_t generate_auth_mask(const struct domain *currd, > + unsigned int word_idx) > +{ > + unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE; > + > + if ( word_idx >= DIV_ROUND_UP(currd->arch.vintc->nr_virqs, > + sizeof(uint32_t) * BITS_PER_BYTE) ) > + { > + gdprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx); > + > + return 0; > + } > + > + return currd->arch.vintc->used_irqs[first_bit / BITS_PER_LONG] >> > + (first_bit % BITS_PER_LONG); > +} > + > +static bool vaplic_emulate_load(const struct vcpu *curr, paddr_t addr, > + uint32_t *out) > +{ > + const struct domain *currd = curr->domain; > + const struct vaplic *vaplic = to_vaplic(currd); > + const unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK; > + uint32_t auth_mask; > + unsigned int i; > + > + ASSERT(curr == current); > + > + switch ( offset ) > + { > + case APLIC_DOMAINCFG: > + *out = vaplic->regs.domaincfg; > + > + return true; > + > + case APLIC_SETIPNUM: > + case APLIC_SETIPNUM_LE: > + case APLIC_CLRIPNUM: > + case APLIC_SETIENUM: > + case APLIC_CLRIENUM: > + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: > + /* > + * Based on the RISC-V AIA spec a read of these registers > + * always returns zero > + */ > + *out = 0; > + > + return true; > + > + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: > + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: > + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: > + i = regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); > + auth_mask = generate_auth_mask(currd, i); > + > + break; > + > + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: > + /* > + * As target registers start from 1: > + * 0x3000 genmsi > + * 0x3004 target[1] > + * 0x3008 target[2] > + * ... > + * 0x3FFC target[1023] > + * It is necessary to calculate an interrupt number by subtracting > + * APLIC_GENMSI instead of APLIC_TARGET_BASE. > + */ > + i = regoffset_to_word_idx(offset - APLIC_GENMSI); > + > + *out = AUTH_IRQ_BIT(currd, i) ? vaplic_target_read(currd, i) : 0; > + > + return true; > + > + default: > + gdprintk(XENLOG_WARNING, "Unhandled APLIC read at offset %#x\n", > + offset); > + > + return false; > + } > + > + *out = aplic_hw_read_reg(offset) & auth_mask; > + > + return true; > +} > + > +static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, > + uint32_t value) > +{ > + const struct domain *currd = curr->domain; > + unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK; > + > + ASSERT(curr == current); > + > + switch ( offset ) > + { > + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: > + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: > + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: > + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: > + { > + unsigned int word_idx = > + regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); > + > + value &= generate_auth_mask(currd, word_idx); > + > + break; > + } > + > + case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: > + if ( value & APLIC_SOURCECFG_D ) > + { > + dprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); > + > + goto fail; > + } > + > + /* > + * As sourcecfg register starts from 1: > + * 0x0000 domaincfg > + * 0x0004 sourcecfg[1] > + * 0x0008 sourcecfg[2] > + * ... > + * 0x0FFC sourcecfg[1023] > + * It is necessary to calculate an interrupt number by subtracting > + * APLIC_DOMAINCFG instead of APLIC_SOURCECFG_BASE. > + */ > + if ( !AUTH_IRQ_BIT(currd, > + regoffset_to_word_idx(offset - APLIC_DOMAINCFG)) ) > + /* Interrupt not enabled, ignore it */ > + return true; > + > + if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW ) > + { > + gdprintk(XENLOG_ERR, > + "value(%#x) is incorrect for sourcecfg register\n", > + value); > + > + return true; > + } > + > + break; > + > + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: > + { > + struct vaplic *vaplic = to_vaplic(currd); > + struct vcpu *target_vcpu; > + unsigned int guest_hart_idx = MASK_EXTR(value, APLIC_TARGET_HART_IDX); > + /* > + * Look at vaplic_emulate_load() for explanation why APLIC_GENMSI is > + * subtracted. > + */ > + unsigned int srcn = regoffset_to_word_idx(offset - APLIC_GENMSI); > + > + if ( !AUTH_IRQ_BIT(currd, srcn) ) > + /* Interrupt not enabled, ignore it */ > + return true; > + > + target_vcpu = domain_vcpu(currd, guest_hart_idx); > + > + if ( !target_vcpu ) > + { > + dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n"); > + > + /* Ignore such writings */ > + return true; > + } > + > + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) > + { > + /* > + * A non-zero guest index asks for delivery to an interrupt file of > + * nested guest. The vIMSIC node has no riscv,guest-index-bits > + * property, so a guest is told its harts have no guest interrupt > + * files and the field is read-only zero for them. The write isn't > + * rejected (that would throw away a valid hart index and EIID); > + * instead the field is dropped, which is also what > + * aplic_msi_target_gen() does with it when programming the h/w. > + */ > + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) > + { > + printk_once(XENLOG_WARNING > + "%pd: vAPLIC target guest index != 0 is unsupported\n", > + currd); > + > + /* Ignore such writes ... */ > + return true; > + } > Comment above this says "The write isn't rejected ... instead the field is dropped, which is also what aplic_msi_target_gen() does with it." But the code doesn't follow it as it returns true immediately here before the write occurred and without zeroing the guest index field. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:10:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:10:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405768.1639217 (Exim 4.92) (envelope-from ) id 1x1jn4-0005sL-P9; Wed, 02 Sep 2026 12:10:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405768.1639217; Wed, 02 Sep 2026 12:10:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jn4-0005sE-Kw; Wed, 02 Sep 2026 12:10:06 +0000 Received: by outflank-mailman (input) for mailman id 1405768; Wed, 02 Sep 2026 12:10:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jn3-0005at-Fh for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:10:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jn2-00BMsO-A1 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:10:04 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981214-2eae-0a2a0a5409dd-0a2a4502b592-26 for ; Wed, 02 Sep 2026 14:10:04 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98121b-6ca4-0a2a45020019-b9ff1c12b24f-3 for ; Wed, 02 Sep 2026 14:10:04 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06206aa7e000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 12:09:59 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 4678F83D2D; Wed, 2 Sep 2026 14:09:58 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=6+obXG72+0AJ7wQS1eI7bJrxbuu0Yvi+0uJx/DuW+ok=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=aFJrseRvur0gGHRu9UpPU50yuMyDYthDQ/S2L74Z92NzcemyqD/IRWUvjCn1HukOlSZn0WAW5 afSgBhTI/GSmWHeyjeGkO3nySSLM58dwcu70Bn1NxDTqkaJitZLLXofuUdTDSq8Qw1BlSJr4AlO gVfiOuiQgwmcAGyCSYt2yTfszdsOm7NItxACQMlsuSr2F+ozE+wAIzF4JeMOpOni4HrMP8wefpO ItNQkWeVkauUDl0ymeVP7iwN9AUrk4y15Kt02h/uOGACD9ZM30IlWCluNONHPXqJg70Yh/u/4HG 6R1cpH+jEwHwWytJ26o3920Rcz7CNhR03u5N9lw9cXVQ== X-Zone-Loop: b0658c9e2d8225e14b0e465c9603ad33a1aa7f627a9c x-campaign-type: default x-transaction-id: 0770e0e8-a1fa-44f2-ab15-31894b15a6be x-swg-uid: 01-93e61cd8-c209-4631-9819-996311b84a85 X-Mailer: Sweego Message-ID: <1788350999.8631fc262581453bbf619ec5b2062170.1a06206aa7e000c4f3@vates.tech> x-swg-bid: 1788350999.8631fc262581453bbf619ec5b2062170.1a06206aa7e000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 2 Sep 2026 14:09:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] arm/bitops: Drop unused ADDR macros To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-2-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902114339.62043-2-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------HHlPaK9UUWDjyp6g0uiNMBqo" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788350998521 X-purgate-ID: tlsNG-720697/1788351004-31FD62AC-1629779B/0/0 X-purgate-type: clean X-purgate-size: 6390 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------HHlPaK9UUWDjyp6g0uiNMBqo Content-Type: multipart/mixed; boundary="------------CwQbJGIW9dA6XCDawtivCEib"; protected-headers="v1"; hp="clear" Message-ID: <818c7617-c7e1-4dbc-b46f-9223eed0aaf5@vates.tech> Date: Wed, 2 Sep 2026 14:09:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] arm/bitops: Drop unused ADDR macros To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-2-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902114339.62043-2-andrew.cooper3@citrix.com> --------------CwQbJGIW9dA6XCDawtivCEib Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDIvMDkvMjAyNiDDoCAxMzo0MywgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBU aGVzZSBhcmUgdW51c2VkIGFuZCBkbyBub3Qgd2FudCBuZXcgdXNlcnMgdG8gYXBwZWFyLg0K PiANCj4gU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0 cml4LmNvbT4NCj4gLS0tDQo+IENDOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ DQo+IENDOiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlckB4ZW5wcm9qZWN0Lm9yZz4NCj4gQ0M6 IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0KPiBDQzogU3RlZmFubyBT dGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KPiBDQzogSnVsaWVuIEdyYWxs IDxqdWxpZW5AeGVuLm9yZz4NCj4gQ0M6IEJlcnRyYW5kIE1hcnF1aXMgPGJlcnRyYW5kLm1h cnF1aXNAYXJtLmNvbT4NCj4gQ0M6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFtZC5j b20+DQo+IENDOiBWb2xvZHlteXIgQmFiY2h1ayA8Vm9sb2R5bXlyX0JhYmNodWtAZXBhbS5j b20+DQo+IC0tLQ0KPiAgIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9iaXRvcHMuaCB8IDMg LS0tDQo+ICAgMSBmaWxlIGNoYW5nZWQsIDMgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0t Z2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2JpdG9wcy5oIGIveGVuL2FyY2gvYXJt L2luY2x1ZGUvYXNtL2JpdG9wcy5oDQo+IGluZGV4IDYwNjg2YTNhNTUwMy4uNTIxMzE4OTJi MWYxIDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vYml0b3BzLmgN Cj4gKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2JpdG9wcy5oDQo+IEBAIC0yMiw5 ICsyMiw2IEBADQo+ICAgI2RlZmluZSBfX3NldF9iaXQobixwKSAgICAgICAgICAgIHNldF9i aXQobixwKQ0KPiAgICNkZWZpbmUgX19jbGVhcl9iaXQobixwKSAgICAgICAgICBjbGVhcl9i aXQobixwKQ0KPiAgIA0KPiAtI2RlZmluZSBBRERSICgqKHZvbGF0aWxlIGludCAqKSBhZGRy KQ0KPiAtI2RlZmluZSBDT05TVF9BRERSICgqKGNvbnN0IHZvbGF0aWxlIGludCAqKSBhZGRy KQ0KPiAtDQo+ICAgI2lmIGRlZmluZWQoQ09ORklHX0FSTV8zMikNCj4gICAjIGluY2x1ZGUg PGFzbS9hcm0zMi9iaXRvcHMuaD4NCj4gICAjZWxpZiBkZWZpbmVkKENPTkZJR19BUk1fNjQp DQoNClJldmlld2VkLWJ5OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4N Cg== --------------CwQbJGIW9dA6XCDawtivCEib-- --------------HHlPaK9UUWDjyp6g0uiNMBqo Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqYEhUFAwAAAAAACgkQZg+p0QLLz9Cc TQwAodsWIXGkVEvPMhYBzqc5bw4Wd6wi+O6eX6qvdrDeFmxsX/sNWngt+b9M6IYGmkiAB3InXaad K8Mmb4B7RepdZMVaqulhUZaUv0wogOetIawTUf09gL8YQI+HhYpkvyorlcoUdblQfIacQ1TWkPTG Y85THzs4+fsQKrpoNxIkC8BL53ShBXZY1t0Vjw89mND1sSNdhcDFtTcXGLsuWMWzahiQ6gBSo15Y ffFxVdxK9+dVO2pLk/gciFC7hhC8ANadBsLumwpGh5t3J+9/B0Le1ZWoAO6jS02C18LkHGgWYVA7 zVgtKDc3vySoAdyN7vj91kCrV1vrIVWuYHQMjS5DZliDEegfimjA5g6Vhf6cq4bfEp9kXf/aIqJE 93smq7nMWOJGSwNORqTS4p2Cd8AUcg8SVHAOzCGquyVVDB4jP7zuhwjkaWEN7Wpzcpy49+15vmKl Tgo/ICGNuQYNZ4FU0SoxeifE8uUSpPYNbXeCfXUUiaCTB2uFor87d0xcdhgn =Ephs -----END PGP SIGNATURE----- --------------HHlPaK9UUWDjyp6g0uiNMBqo-- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:11:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:11:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405775.1639225 (Exim 4.92) (envelope-from ) id 1x1jnw-0006Ir-0I; Wed, 02 Sep 2026 12:11:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405775.1639225; Wed, 02 Sep 2026 12:10:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jnv-0006Ik-TI; Wed, 02 Sep 2026 12:10:59 +0000 Received: by outflank-mailman (input) for mailman id 1405775; Wed, 02 Sep 2026 12:10:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jnu-0006Ic-CA for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:10:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jnt-00GYN6-P8 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:10:57 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981250-e002-0a2a0a5209dd-0a2a4509e156-12 for ; Wed, 02 Sep 2026 14:10:57 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981251-be1a-0a2a45090019-b9ff1c129891-3 for ; Wed, 02 Sep 2026 14:10:57 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a062077462000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 12:10:50 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 2E5E682170; Wed, 2 Sep 2026 14:10:50 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=mky7CnlEcJGsmWLEstzMKkivu1t2UVpUflBhPOhqKAc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=dWUKl/KKTwGOKNBCfBoDXf24NiE/n6yTnY7Pu8LjXAYpq1WG1oqjQKcRqofMV0ls8WzRcTKeW +ERvSY7zh6XM2ceR1N2cfJLp3x+AB2G+Pkxux/9ZTSlLLueFvAhzRg2QOp6+j4uWniA+5bQw1ut h/bJ4Z7kt3wlgbvvE8QPz4BM4t8pMw2bDyQJotp8VHSWw1rrkbm5DrpcEVzoBYzys+pwSAFmtyU 5amHeLjrzf+hPbwDUZxQ59mH2z+eFv+Dj2LhIK96e044Hv1+XfndofUUqLTizfAYhQQbvpBy/Dk dwDCU9QjqIkgDR0LrahVSiP72B0rNayDuawCJ5RG+PjQ== X-Zone-Loop: bab569b70d2e938e159b954a7e2b568bf4a77fbecb9e x-campaign-type: default x-transaction-id: 7cd076b0-2348-4e72-bdd5-c267aaee86fb x-swg-uid: 01-ed3be001-20c6-4963-9c15-574537ad9738 X-Mailer: Sweego Message-ID: <1788351050.8631fc262581453bbf619ec5b2062170.1a062077462000c4f3@vates.tech> x-swg-bid: 1788351050.8631fc262581453bbf619ec5b2062170.1a062077462000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 2 Sep 2026 14:10:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] x86/bitops: Remove CONST_ADDR To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-3-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902114339.62043-3-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------q8kNZoFsIjgt90DRv92X0UpL" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788351050385 X-purgate-ID: tlsNG-bad1c0/1788351057-FC212034-5E538B3F/0/0 X-purgate-type: clean X-purgate-size: 6942 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------q8kNZoFsIjgt90DRv92X0UpL Content-Type: multipart/mixed; boundary="------------6qvz7YUD6xpoRybqB3xtVs0t"; protected-headers="v1"; hp="clear" Message-ID: Date: Wed, 2 Sep 2026 14:10:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] x86/bitops: Remove CONST_ADDR To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-3-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902114339.62043-3-andrew.cooper3@citrix.com> --------------6qvz7YUD6xpoRybqB3xtVs0t Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDIvMDkvMjAyNiDDoCAxMzo0MywgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBB bGwgdGhpcyBkb2VzIGlzIG9iZnVzY2F0ZSB0aGUgdXNhZ2Ugc2l0ZXMuDQo+IA0KPiBObyBm dW5jdGlvbmFsIGNoYW5nZS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIg PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQo+IC0tLQ0KPiBDQzogSmFuIEJldWxpY2gg PGpiZXVsaWNoQHN1c2UuY29tPg0KPiBDQzogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXJAeGVu cHJvamVjdC5vcmc+DQo+IENDOiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVj aD4NCj4gQ0M6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4N Cj4gQ0M6IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+DQo+IENDOiBCZXJ0cmFuZCBN YXJxdWlzIDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+DQo+IENDOiBNaWNoYWwgT3J6ZWwg PG1pY2hhbC5vcnplbEBhbWQuY29tPg0KPiBDQzogVm9sb2R5bXlyIEJhYmNodWsgPFZvbG9k eW15cl9CYWJjaHVrQGVwYW0uY29tPg0KPiAtLS0NCj4gICB4ZW4vYXJjaC94ODYvaW5jbHVk ZS9hc20vYml0b3BzLmggfCA1ICsrKy0tDQo+ICAgMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0 aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94 ODYvaW5jbHVkZS9hc20vYml0b3BzLmggYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vYml0 b3BzLmgNCj4gaW5kZXggNjlmZmVkNTEwYzBhLi5mYmNhYjMyZmQyMzkgMTAwNjQ0DQo+IC0t LSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9iaXRvcHMuaA0KPiArKysgYi94ZW4vYXJj aC94ODYvaW5jbHVkZS9hc20vYml0b3BzLmgNCj4gQEAgLTE4LDcgKzE4LDYgQEANCj4gICAg Ki8NCj4gICANCj4gICAjZGVmaW5lIEFERFIgKCoodm9sYXRpbGUgaW50ICopIGFkZHIpDQo+ IC0jZGVmaW5lIENPTlNUX0FERFIgKCooY29uc3Qgdm9sYXRpbGUgaW50ICopIGFkZHIpDQo+ ICAgDQo+ICAgLyoqDQo+ICAgICogc2V0X2JpdCAtIEF0b21pY2FsbHkgc2V0IGEgYml0IGlu IG1lbW9yeQ0KPiBAQCAtMjg1LDcgKzI4NCw5IEBAIHN0YXRpYyBpbmxpbmUgaW50IHZhcmlh YmxlX3Rlc3RfYml0KGludCBuciwgY29uc3Qgdm9sYXRpbGUgdm9pZCAqYWRkcikNCj4gICAg ICAgYXNtIHZvbGF0aWxlICggImJ0bCAlW25yXSwgJVthZGRyXVxuXHQiDQo+ICAgICAgICAg ICAgICAgICAgICAgIEFTTV9GTEFHX09VVCgsICJzYmJsICVbb2xkXSwgJVtvbGRdXG5cdCIp DQo+ICAgICAgICAgICAgICAgICAgICAgIDogW29sZF0gQVNNX0ZMQUdfT1VUKCI9QGNjYyIs ICI9ciIpIChvbGRiaXQpDQo+IC0gICAgICAgICAgICAgICAgICAgOiBbYWRkcl0gIm0iIChD T05TVF9BRERSKSwgW25yXSAiSXIiIChucikgOiAibWVtb3J5IiApOw0KPiArICAgICAgICAg ICAgICAgICAgIDogW2FkZHJdICJtIiAoKihjb25zdCB2b2xhdGlsZSBpbnQgKilhZGRyKSwN Cj4gKwkJICAgICBbbnJdICJJciIgKG5yKQ0KPiArCQkgICA6ICJtZW1vcnkiICk7DQo+ICAg DQo+ICAgICAgIHJldHVybiBvbGRiaXQ7DQo+ICAgfQ0KDQpSZXZpZXdlZC1ieTogVGVkZHkg QXN0aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+DQo= --------------6qvz7YUD6xpoRybqB3xtVs0t-- --------------q8kNZoFsIjgt90DRv92X0UpL Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqYEkkFAwAAAAAACgkQZg+p0QLLz9AR vwwAjVCXqVuu/7GdT3mg3SZCX8C3qlNp2zF6oyEXJnQCcjOCjA7nkNrG0gSWlCvtO40S4cDT57nM bWEktprRSTy937Xy7SBGMoiV8T3fkcfpHKym3RGflIr3shT/uvypVS/UKLWILLHY+xd73oloPaxF +ckSlFplhsk2BeQ98qDc+GE1SV6qRY7BG4PC7q9kDBNx0z3u0H1gwDW1a/arJrmrVZTQZp9SbawV yo9EA8dirmIIVpJeiCk11GRD1nyy0iJXarTFzC8h7m87ALL3oJYBpP2zkT7p5uqJGq4kOxAD/Pe9 IVTi8MQIq3GV3s1W1DDDZqDQs9UITy6fXxckP+Y0REPPC6d+AiZX5TY0tGA/OsLUuyR1aPZLN/PD /7sedsIe7MOkRNJQqPWOtUD+l+ffYeBy3Gk2PGFvbpq3Z1ZV6pYzmWrKbeoysdbBdWlDghiBbN29 fiPhalzz2UKvAGNbG4ajZ+EtRiT1ut99ybAo+q1uuo4g8MHkOfky6c08GELZ =Xyvi -----END PGP SIGNATURE----- --------------q8kNZoFsIjgt90DRv92X0UpL-- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:12:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:12:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405783.1639233 (Exim 4.92) (envelope-from ) id 1x1jpQ-0006oa-9D; Wed, 02 Sep 2026 12:12:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405783.1639233; Wed, 02 Sep 2026 12:12:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jpQ-0006oT-6c; Wed, 02 Sep 2026 12:12:32 +0000 Received: by outflank-mailman (input) for mailman id 1405783; Wed, 02 Sep 2026 12:12:31 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jpO-0006oN-Ua for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:12:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jpO-00BVaT-B0 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:12:30 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9812a4-2eae-0a2a0a5409dd-0a2a4506c596-10 for ; Wed, 02 Sep 2026 14:12:30 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9812ad-195a-0a2a45060019-b9ff1c238565-3 for ; Wed, 02 Sep 2026 14:12:30 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06208e4e8000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 12:12:25 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 787A081C01; Wed, 2 Sep 2026 14:12:24 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=RkeBYuMiPafFNPAMKaPBxyAm4rEMTlcO30tVyz8MUfs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=miZ8rphS68e0kOiFMJEOP8ikU7jV6tjiJm9DbN0MXxSkPzY07g2tT4UIxARLDi4wb2BHPOLQL G4BUVH10LtRvKSoZI6zb1P/QkS+7bRUEKW+THxKzi7NgsaQ1PhrrEpKNNJgOqN+f5fK6fFwcQwe ZbZ1QqtUU3nLojSAaev9CVOSEgl13BEPM8voubuUZYsQIO2AP4ZKAwkULdWFkB0nWZAdmchU9B7 5UqnDU4Uof1IhmR09/NQNV0SAbznlPL7oow8x2S9WYYvIgHJoki46/3Dq5B5enTPSXVj1rvDq+L LR5toUteVIZDglu71gQx9kY8jas6Flt4J11T5u/Iaa5g== X-Zone-Loop: c8f5b4ef1faf521d1fc13263af7abcd0c6d642cbd445 x-campaign-type: default x-transaction-id: 347dd57a-d1e6-445f-b4af-1ad7988c1fc1 x-swg-uid: 01-4d0a7909-9b25-4b14-ab00-9cb2354c8382 X-Mailer: Sweego Message-ID: <1788351145.8631fc262581453bbf619ec5b2062170.1a06208e4e8000c4f3@vates.tech> x-swg-bid: 1788351145.8631fc262581453bbf619ec5b2062170.1a06208e4e8000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 2 Sep 2026 14:12:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] x86/bitops: Remove ADDR To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-4-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902114339.62043-4-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------SSu2VODcuw7w0JUybC6kEutV" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788351144682 X-purgate-ID: tlsNG-16d1c6/1788351150-F667277B-432808DF/0/0 X-purgate-type: clean X-purgate-size: 5794 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------SSu2VODcuw7w0JUybC6kEutV Content-Type: multipart/mixed; boundary="------------dI1YtcXTv0sZyCSJ3NXHjbAJ"; protected-headers="v1"; hp="clear" Message-ID: <246e64d8-be0a-4d7e-9f8c-5fc6a48bcef9@vates.tech> Date: Wed, 2 Sep 2026 14:12:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] x86/bitops: Remove ADDR To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-4-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902114339.62043-4-andrew.cooper3@citrix.com> --------------dI1YtcXTv0sZyCSJ3NXHjbAJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDIvMDkvMjAyNiDDoCAxMzo0MywgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBB bGwgdGhpcyBkb2VzIGlzIG9iZnVzY2F0ZSB0aGUgdXNhZ2Ugc2l0ZXMuDQo+IA0KPiBObyBm dW5jdGlvbmFsIGNoYW5nZS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIg PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQo+IC0tLQ0KPiBDQzogSmFuIEJldWxpY2gg PGpiZXVsaWNoQHN1c2UuY29tPg0KPiBDQzogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXJAeGVu cHJvamVjdC5vcmc+DQo+IENDOiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVj aD4NCj4gQ0M6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4N Cj4gQ0M6IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+DQo+IENDOiBCZXJ0cmFuZCBN YXJxdWlzIDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+DQo+IENDOiBNaWNoYWwgT3J6ZWwg PG1pY2hhbC5vcnplbEBhbWQuY29tPg0KPiBDQzogVm9sb2R5bXlyIEJhYmNodWsgPFZvbG9k eW15cl9CYWJjaHVrQGVwYW0uY29tPg0KPiAtLS0NCj4gICBkb2NzL21pc3JhL3J1bGVzLnJz dCAgICAgICAgICAgICAgfCAgMyArKy0NCj4gICB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v Yml0b3BzLmggfCAzNCArKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tDQo+ICAgMiBm aWxlcyBjaGFuZ2VkLCAyMCBpbnNlcnRpb25zKCspLCAxNyBkZWxldGlvbnMoLSkNCj4gDQoN CiguLi4pDQoNClJldmlld2VkLWJ5OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMu dGVjaD4NCg== --------------dI1YtcXTv0sZyCSJ3NXHjbAJ-- --------------SSu2VODcuw7w0JUybC6kEutV Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqYEqgFAwAAAAAACgkQZg+p0QLLz9AO XAv/QabI87eGpS1PkvmKDM5/JekmW8oRVGIqTo37T6ZiDS0ielfaTCR6/C6jbcL/BVYYmI7ohKMb JatF7l+NBtJwB9MmrpYelYuzvp/IelNH2AmXy4RFLK4Qlz6aizMOlrRIawvIjN6cHsa3PqnU0g30 k0/zT7zCCXHqIznnK4xHo2fDRlccfvU0MtOn577IoPytl+jB7PxBHWIik0LhRO4rZfnKMfipRM8w NBnrN4a2RYvmHeoIdxDVYgI2S6Qz/CYouQPeAmrXb1rJoaetBlQIWRiGtLVdHpayUfriyR1yyno3 yGqos1P6OVdV1ASj+z20uUZ8sv1i26zPTP8jPJmr6jsStra793X5tKTtJKOWVjkmD/glWSam78Wz 0vJmPpqoPC0VS6GH5l36OAeo10dMGIDWGfozAyl3xqMEu5QP4W683fhQ0dgR/FRIZyU7qWvBs5M8 d7EzobrSw0dQWitV02GPOBUOSedFZJ5CnHHanvibPfdH6lqQPF+/nyyO0UaL =Sp7x -----END PGP SIGNATURE----- --------------SSu2VODcuw7w0JUybC6kEutV-- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:13:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:13:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405794.1639243 (Exim 4.92) (envelope-from ) id 1x1jqS-0007LF-MQ; Wed, 02 Sep 2026 12:13:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405794.1639243; Wed, 02 Sep 2026 12:13:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jqS-0007L8-JC; Wed, 02 Sep 2026 12:13:36 +0000 Received: by outflank-mailman (input) for mailman id 1405794; Wed, 02 Sep 2026 12:13:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1jqR-0007L0-I7 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:13:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1jqQ-00GZ5P-VJ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:13:34 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9812ed-e002-0a2a0a5209dd-0a2a4501cc0c-10 for ; Wed, 02 Sep 2026 14:13:34 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9812ee-5984-0a2a45010019-b9ff1c229ced-3 for ; Wed, 02 Sep 2026 14:13:34 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06209db4d000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 12:13:28 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 8A7BF81EFA; Wed, 2 Sep 2026 14:13:27 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=tiw4xPPRY8OYYdExoE26DtgALBte0vuzjt3z7+fU0yE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=kvEGR1xf1xJT/QTPsdr1JXA85TN5jVBFeWpjDlJoTfcTRIy2SS1uXqcy8Q1OreTCG3r8MMHcJ u3aflxIGIxs4qi2546++1HzJfWuPH/HzUwyYkiemARypr099baposckAtwBZkeuT5pVK5QOVLcX T1nVwXzE0p7GmNrvJG+b/laArGAyiEdh57ZFBcvvz4DqW/pM/HSUC6ExTjoROX+4937JSsrtfl3 4MVBALFFmxeV7xRWFgDfZ+igEZpmF9epEtYhplm2F36mAX13cuANjRFydNe1qlcLXVd71CoHEdM Uu6Ue7Wj/RAyb0fVpaM4QnXcrYAhndYrVSErq729Spzw== X-Zone-Loop: 24c76bb2e787d509aaab642504bbd02a117bae237540 x-campaign-type: default x-transaction-id: 788a6acb-c896-4466-bf1c-cfca7e641cfb x-swg-uid: 01-0c4fdd03-772b-4aa4-9717-56b2384abf85 X-Mailer: Sweego Message-ID: <1788351208.8631fc262581453bbf619ec5b2062170.1a06209db4d000c4f3@vates.tech> x-swg-bid: 1788351208.8631fc262581453bbf619ec5b2062170.1a06209db4d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 2 Sep 2026 14:13:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/4] x86/bitops: don't cast away volatile-ness To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-5-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902114339.62043-5-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------bWLQzgFU7KbT5AZK0ydMr007" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788351207761 X-purgate-ID: tlsNG-d62444/1788351214-BF063757-E701E59E/0/0 X-purgate-type: clean X-purgate-size: 5956 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------bWLQzgFU7KbT5AZK0ydMr007 Content-Type: multipart/mixed; boundary="------------uJq53P7HCO3LhMALVuti5xzR"; protected-headers="v1"; hp="clear" Message-ID: <71bdd891-f3c0-42f4-ba5c-485681dc6319@vates.tech> Date: Wed, 2 Sep 2026 14:13:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/4] x86/bitops: don't cast away volatile-ness To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-5-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902114339.62043-5-andrew.cooper3@citrix.com> --------------uJq53P7HCO3LhMALVuti5xzR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDIvMDkvMjAyNiDDoCAxMzo0MywgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBG cm9tOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IA0KPiBEb2luZyBzbywg YmVzaWRlcyBiZWluZyBhIGJhZCBpZGVhIGluIGdlbmVyYWwsIHZpb2xhdGVzIE1pc3JhIHJ1 bGUgMTEuOC4NCj4gVXNlIHRoZSBoZWxwZXIgbWFjcm8gd2UgaGF2ZSBhdmFpbGFibGUgYW55 d2F5Lg0KPiANCj4gTm8gZnVuY3Rpb25hbCBjaGFuZ2UgaW50ZW5kZWQuDQo+IA0KPiBGaXhl czogZjE4NzliMmMyNTg0ICgieGVuOiBpbnRyb2R1Y2UgZ2VuZXJpYyBub24tYXRvbWljIHRl c3RfKmJpdCgpIikNCj4gU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1 c2UuY29tPg0KPiBSZXZpZXdlZC1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNA Y2l0cml4LmNvbT4NCj4gLS0tDQo+IENDOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5j b20+DQo+IENDOiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlckB4ZW5wcm9qZWN0Lm9yZz4NCj4g Q0M6IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0KPiBDQzogU3RlZmFu byBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KPiBDQzogSnVsaWVuIEdy YWxsIDxqdWxpZW5AeGVuLm9yZz4NCj4gQ0M6IEJlcnRyYW5kIE1hcnF1aXMgPGJlcnRyYW5k Lm1hcnF1aXNAYXJtLmNvbT4NCj4gQ0M6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9yemVsQGFt ZC5jb20+DQo+IENDOiBWb2xvZHlteXIgQmFiY2h1ayA8Vm9sb2R5bXlyX0JhYmNodWtAZXBh bS5jb20+DQo+IA0KPiBSZWJhc2Ugb3ZlciByZW1vdmFsIG9mIEFERFIuDQo+IC0tLQ0KDQoo Li4uKQ0KDQpSZXZpZXdlZC1ieTogVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRl Y2g+DQo= --------------uJq53P7HCO3LhMALVuti5xzR-- --------------bWLQzgFU7KbT5AZK0ydMr007 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqYEucFAwAAAAAACgkQZg+p0QLLz9Br Mwv/Q+QgA7otHQT6q9xjw11q/f6HyLuN0S8P5YsY9q97GgXTvmTBTjpvsdCymB6dc9fbwJgjlGgY c6KiXGxtvGPcMWJSAaLjCpll7Hns2QL7rONjrPhU7pE6pOEtEUofjG0zuwuqi88a4IE2aKehHfC7 ahaGls0juotok7iFaPJGoJl2r9pfMvWOceH1ukOT0gkAIXIdWW2++Vj4dfT6Rsnc4ZrAPSEW2JJ9 DTlITZeI/qVkh6T7cWW8NZ8dGQK2ZPInQNo3zzH8H3NbilQRAW6jQ/h0vv3IcP4YXEdl3WllAE8A ZLC9lgJ459gsrkmHUM8w9e2VCL55sSCNWV1b0RRx2ePSaxMMqxL1pENGbong9ws2N/iR/U2/ENEa uELmxg74CcaxvwDS+AadnK1F4niDuPB2rmTqRfRm8Da4TCNJs5DJz0QzVYOgD1r5rZJjiAdLPbS3 xbjhcnL0pH1Gx+H2mi0S1wbDpqwUt8DRg0HlrNH1hDIMQCIJP+/LSIRNBaLO =Gbam -----END PGP SIGNATURE----- --------------bWLQzgFU7KbT5AZK0ydMr007-- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:31:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:31:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405805.1639253 (Exim 4.92) (envelope-from ) id 1x1k7g-00025p-46; Wed, 02 Sep 2026 12:31:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405805.1639253; Wed, 02 Sep 2026 12:31:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1k7g-00025i-0J; Wed, 02 Sep 2026 12:31:24 +0000 Received: by outflank-mailman (input) for mailman id 1405805; Wed, 02 Sep 2026 12:31:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1k7e-00025c-3S for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:31:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1k7d-000JKV-2b for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:31:21 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981713-8faa-0a2a0a5109dd-0a2a4502da7e-32 for ; Wed, 02 Sep 2026 14:31:20 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981718-6ca4-0a2a45020019-b9ff1c23a449-3 for ; Wed, 02 Sep 2026 14:31:20 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0621a2590000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 12:31:15 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id E3EF883EC5; Wed, 2 Sep 2026 14:31:14 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=1THMeUBAIrDeEun9uRoY4O/7eVbr5QQLu9G4t9DVyP8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=g1KPhYG7DL6289Jv5MmHfcigO19NSJKTGvWftIwp9Y7T+g4qzu0Mw2xYXfJoSexcDd/1uxB+Y itF0h2jsQIqekNzC6Sy1alVcz6Kk3hTGTpKRD96H1gBGAYOHILi+SJpf3RSruPuv03j/ZWGrhXZ kaz0BJF3maaL1ZhCE9DqC8y64PfPvQ7wE3EBA4l4fR7mexPk2luNIeaLtuWMiC/xTc/GSrLlU3B EOx95RCaMu7gnzJYamuyinOTvJyDkwkECL6Ovk4kk8UllIQvWcJoSTq0hggv8AFPzIL1nYLgj7j xfWH5RApjC3YYLoQU44L/4+t8+BqcCUzRliImLEKQ8eQ== X-Zone-Loop: fac5733e58b59dee18d11639511ec8f13838e7d29073 x-campaign-type: default x-transaction-id: 6507237c-a807-482a-bed1-a2a3ef1156b7 x-swg-uid: 01-ec864085-30df-44b4-bb8f-7811ea3ab810 X-Mailer: Sweego Message-ID: <1788352275.8631fc262581453bbf619ec5b2062170.1a0621a2590000c4f3@vates.tech> x-swg-bid: 1788352275.8631fc262581453bbf619ec5b2062170.1a0621a2590000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> Date: Wed, 02 Sep 2026 14:31:07 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788352274; l=22981; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ypu6EGnOWO8iKeh0Sw5dn0r+IAsxBSz5B1e49RuK/U0=; b=7PND8ycxYfluSujQqSlmJtBAEYSzw+AtBi34YOo3jDIFR4FzzT3kIlJ6b2KG/T8VTy5OVegwo wfbHMuDR5PQBmg8jSPthKH91c7BlphljEhhqALGbhuRomnni8i3izVK X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788352275146 X-purgate-ID: tlsNG-720697/1788352280-662A92AC-5F6600DD/10/73395122804 X-purgate-type: spam X-purgate-size: 22981 > Guests running under Xen program interrupt routing by writing to APLIC > MMIO registers. Xen must intercept these accesses to enforce interrupt > isolation between domains and to translate guest routing intent into the > underlying physical MSI topology. > > Writes are gated by the domain's authorised interrupt bitmap so that a > guest cannot affect interrupts it does not own. TARGET register writes > additionally require translation of the hart and IMSIC guest-file > indices from virtual to physical, as the APLIC uses these fields > directly to compute the MSI delivery address. > > Delegation (APLIC_SOURCECFG_D) is not yet supported. > > Co-developed-by: Romain Caritey > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h > index 35100d3a64..b3a1f79c5b 100644 > --- a/xen/arch/riscv/aplic-priv.h > +++ b/xen/arch/riscv/aplic-priv.h > @@ -47,4 +47,7 @@ struct aplic_priv { > */ > extern unsigned int guest_aplic_num_sources; > > +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, > + uint32_t base_val); > + > #endif /* ASM_RISCV_APLIC_PRIV_H */ > diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c > index 3681f0669e..66ba4986a9 100644 > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -28,8 +29,6 @@ > #include > #include > > -#define APLIC_DEFAULT_PRIORITY 1 > - > static struct aplic_priv aplic = { > .lock = SPIN_LOCK_UNLOCKED, > }; > @@ -38,6 +37,127 @@ static struct intc_info __ro_after_init aplic_info = { > .hw_variant = INTC_APLIC, > }; > > +/* > + * The arrangement of IMSIC interrupt files in MMIO space follows a topology > + * defined by the RISC-V AIA specification. An IMSIC group is a set of > + * interrupt files (e.g., in a cluster or socket) co-located in memory. > + * > + * The physical address of an outgoing MSI is calculated by bitwise ORing a > + * Base Physical Page Number (Base PPN) with the Group Index (g), the Hart > + * Index (h) and, for a supervisor-level interrupt domain, the Guest Index: > + * > + * ( Base PPN | (g << (HHXS + 12)) | (h << LHXS) | guest ) << 12 > + * > + * where Base PPN, HHXS, LHXS, HHXW and LHXW come from the {m,s}msiaddrcfg[h] > + * registers of the interrupt domain that sends the MSI: > + * > + * XLEN-1 HHXS+24 LHXS+12 12 0 > + * | | | | | > + * ------------------------------------------------------------ > + * |xxxx| g |xxxxxxxx| h |xxxx|Guest Index| 0 | > + * ------------------------------------------------------------ > + * > + * - g: group number. > + * - h: hart number relative to the group. > + * - xxxx: remaining Base PPN bits; each gap may be zero-width. > + * - Guest Index: selects one of the 4 KiB pages right above the hart's own > + * supervisor-level file, i.e. it starts at bit 12; LHXS must therefore be > + * at least as large as the number of guest index bits. > + * - Bits 11:0: always zero because IMSIC files are 4 KiB page-aligned. > + * > + * For wired interrupts in MSI delivery mode (domaincfg.DM = 1) the APLIC > + * builds that address itself from the "Hart Index" field (bits 31:18) of the > + * corresponding target[i] register. That field holds a hart index *number*, > + * in which both indices are packed adjacently: > + * > + * 13 lhxw+hhxw lhxw 0 > + * | | | | > + * ------------------------------------ > + * | 0 |Group Index|Hart Index| > + * ------------------------------------ > + * > + * - lhxw (Low Hart Index Width): the number of bits used for the hart number > + * within a group. > + * - hhxw (High Hart Index Width): the number of bits used for the group > + * number; the remaining bits of the field must be zero. > + * > + * The Guest Index isn't a part of it: for a supervisor-level interrupt domain > + * it has its own field (bits 17:12) in target[i]. > + * > + * Because there are "xxxx" gaps (Base PPN bits) between the indices in the > + * physical address (depending on HHXS and LHXS), software must extract the > + * group and hart components separately and pack them into the APLIC-defined > + * Hart Index format to ensure correct MSI targeting. > + */ > +static unsigned long aplic_hart_field(unsigned int cpu) > +{ > + const struct imsic_config *imsic = imsic_get_config(); > + const struct imsic_msi *msi = &imsic->msi[cpu]; > + /* Low Hart Index Shift */ > + unsigned int lhxs = imsic->guest_index_bits; > + /* Low Hart Index Width */ > + unsigned int lhxw = imsic->hart_index_bits; > + /* High Hart Index Width */ > + unsigned int hhxw = imsic->group_index_bits; > + /* High Hart Index Shift */ > + unsigned int hhxs = > + imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2; > + /* > + * msi->base_addr is the base of the MMIO regset this CPU's interrupt > + * files live in, and one regset can cover several harts; msi->offset > + * selects this CPU's block inside it. The hart index bits are part of > + * that offset, so both indexes have to be derived from the full address. > + */ > + paddr_t target_addr = msi->base_addr + msi->offset; > + unsigned long tppn = target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT; > + unsigned long g = > + (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) & > + APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw); > + unsigned long h = > + (tppn >> APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs)) & > + APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw); > + > + return (g << lhxw) | h; > +} > + > +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, > + uint32_t base_val) > +{ > + unsigned int guest_id = vcpu_guest_file_id(target_vcpu); > + unsigned long hart_field = aplic_hart_field(target_vcpu->processor); > + > + base_val &= APLIC_TARGET_EIID; > + base_val |= MASK_INSR(guest_id, APLIC_TARGET_GUEST_IDX); > + base_val |= MASK_INSR(hart_field, APLIC_TARGET_HART_IDX); > + > + return base_val; > +} > + > +uint32_t aplic_hw_read_reg(unsigned int offset) > +{ > + unsigned long flags; > + uint32_t val; > + > + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); > + > + spin_lock_irqsave(&aplic.lock, flags); > + val = readl((volatile void __iomem *)aplic.regs + offset); > + spin_unlock_irqrestore(&aplic.lock, flags); > + > + return val; > +} > + > +void aplic_hw_write_reg(unsigned int offset, uint32_t value) > +{ > + unsigned long flags; > + > + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); > + > + spin_lock_irqsave(&aplic.lock, flags); > + writel(value, (volatile void __iomem *)aplic.regs + offset); > + spin_unlock_irqrestore(&aplic.lock, flags); > +} > + > static void __init aplic_init_hw_interrupts(void) > { > unsigned int i; > @@ -53,9 +173,9 @@ static void __init aplic_init_hw_interrupts(void) > /* > * Low bits of target register contains Interrupt Priority bits which > * can't be zero according to AIA spec. > - * Thereby they are initialized to APLIC_DEFAULT_PRIORITY. > + * Thereby they are initialized to APLIC_TARGET_IPRIO_DEFAULT. > */ > - writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]); > + writel(APLIC_TARGET_IPRIO_DEFAULT, &aplic.regs->target[i]); > } > > writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg); > diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h > index a2af55d54f..babba38607 100644 > --- a/xen/arch/riscv/include/asm/aplic.h > +++ b/xen/arch/riscv/include/asm/aplic.h > @@ -39,6 +39,13 @@ > #define APLIC_DOMAINCFG_IE BIT(8, U) > #define APLIC_DOMAINCFG_DM BIT(2, U) > #define APLIC_DOMAINCFG_BE BIT(0, U) > +/* > + * The bits a write may change. Everything else, including the read-only zero > + * bit 7 and the reserved bits, has to read back as zero, and BE is WARL and > + * hardwired to 0 as Xen is little-endian only. > + */ > +#define APLIC_DOMAINCFG_WMASK (APLIC_DOMAINCFG_IE | \ > + APLIC_DOMAINCFG_DM) > > #define APLIC_SOURCECFG_BASE 0x0004 > #define APLIC_SOURCECFG_LAST 0x0ffc > @@ -89,6 +96,9 @@ > #define APLIC_TARGET_GUEST_IDX GENMASK(17, 12) > /* Bit 11 is reserved and reads as zero */ > #define APLIC_TARGET_EIID GENMASK(10, 0) > +/* If target is in DM mode */ > +#define APLIC_TARGET_IPRIO GENMASK(7, 0) > +#define APLIC_TARGET_IPRIO_DEFAULT 1U > > #define APLIC_IDC_SIZE 32 > > @@ -98,6 +108,27 @@ > #define APLIC_SIZE(nr_cpus) \ > (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus))) > > +/* > + * Using setip is fine here, as all SET* and CLR* register groups consist of 32 > + * registers and therefore have identical sizes. > + * > + * Lowest 2 bits are always zero for SET* and CLR* registers. > + */ > +#define APLIC_SETCLR_OFFSET_MASK \ > + (sizeof_field(struct aplic_regs, setip) - sizeof(uint32_t)) > + > +#define APLIC_xMSICFGADDR_PPN_SHIFT IMSIC_MMIO_PAGE_SHIFT > + > +#define APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw) \ > + (BIT(hhxw, UL) - 1) > +#define APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs) \ > + ((hhxs) + APLIC_xMSICFGADDR_PPN_SHIFT) > + > +#define APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw) \ > + (BIT(lhxw, UL) - 1) > +#define APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs) \ > + (lhxs) > + > struct aplic_regs { > uint32_t domaincfg; /* 0x0000 */ > uint32_t sourcecfg[1023]; /* 0x0004 */ > @@ -141,4 +172,7 @@ struct aplic_regs { > uint32_t target[1023]; /* 0x3004 */ > }; > > +uint32_t aplic_hw_read_reg(unsigned int offset); > +void aplic_hw_write_reg(unsigned int offset, uint32_t value); > + > #endif /* ASM_RISCV_APLIC_H */ > diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h > index 2425430ed1..93f9e44c7d 100644 > --- a/xen/arch/riscv/include/asm/imsic.h > +++ b/xen/arch/riscv/include/asm/imsic.h > @@ -40,6 +40,19 @@ struct imsic_config { > /* Base address */ > paddr_t base_addr; > > + /* > + * MSI Target Address Scheme > + * > + * XLEN-1 HHXS+24 LHXS+12 12 0 > + * | | | | | > + * ------------------------------------------------------------ > + * |xxxx| g |xxxxxxxx| h |xxxx|Guest Index| 0 | > + * ------------------------------------------------------------ > + * - g: group number. > + * - h: hart number relative to the group. > + * - xxxx: remaining Base PPN bits; each gap may be zero-width. > + */ > + > /* Bits representing Guest index, HART index, and Group index */ > unsigned int guest_index_bits; > unsigned int hart_index_bits; > diff --git a/xen/arch/riscv/include/asm/vaplic.h b/xen/arch/riscv/include/asm/vaplic.h > index 96080bfbc2..046c604915 100644 > --- a/xen/arch/riscv/include/asm/vaplic.h > +++ b/xen/arch/riscv/include/asm/vaplic.h > @@ -21,11 +21,16 @@ struct domain; > > struct vaplic_regs { > uint32_t domaincfg; > + > + uint32_t *target; > }; > > struct vaplic { > struct vintc vintc; > struct vaplic_regs regs; > + > + paddr_t regs_start; > + unsigned int regs_size; > }; > > int domain_vaplic_init(struct domain *d); > diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c > index 14f6e3164a..8726f7203d 100644 > --- a/xen/arch/riscv/vaplic.c > +++ b/xen/arch/riscv/vaplic.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > > #include "aplic-priv.h" > @@ -27,6 +28,279 @@ unsigned int __ro_after_init guest_aplic_num_sources; > > #define FDT_VAPLIC_INT_CELLS 2 > > +#define AUTH_IRQ_BIT(d, irqn) \ > + (((irqn) < (d)->arch.vintc->nr_virqs) && \ > + test_bit(irqn, (d)->arch.vintc->used_irqs)) > + > +/* > + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group) to > + * a 32-bit word index into the used_irqs bitmap. Each word covers 32 > + * interrupt sources. For SOURCECFG and TARGET groups the same division also > + * yields the interrupt number directly, because those arrays store one 32-bit > + * register per source. > + */ > +#define regoffset_to_word_idx(reg_val) ((reg_val) / sizeof(uint32_t)) > + > +static uint32_t vaplic_target_read(const struct domain *d, unsigned int irqn) > +{ > + const struct vaplic *vaplic = to_vaplic(d); > + > + /* target[0] doesn't exist so irqn == 0 should be impossible */ > + if ( !irqn || irqn >= vaplic->vintc.nr_virqs ) > + return 0; > + > + return read_atomic(&vaplic->regs.target[irqn]); > +} > + > +static inline uint32_t generate_auth_mask(const struct domain *currd, > + unsigned int word_idx) > +{ > + unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE; > + > + if ( word_idx >= DIV_ROUND_UP(currd->arch.vintc->nr_virqs, > + sizeof(uint32_t) * BITS_PER_BYTE) ) > + { > + gdprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx); > + > + return 0; > + } > + > + return currd->arch.vintc->used_irqs[first_bit / BITS_PER_LONG] >> > + (first_bit % BITS_PER_LONG); > +} > + > +static bool vaplic_emulate_load(const struct vcpu *curr, paddr_t addr, > + uint32_t *out) > +{ > + const struct domain *currd = curr->domain; > + const struct vaplic *vaplic = to_vaplic(currd); > + const unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK; > + uint32_t auth_mask; > + unsigned int i; > + > + ASSERT(curr == current); > + > + switch ( offset ) > + { > + case APLIC_DOMAINCFG: > + *out = vaplic->regs.domaincfg; > + > + return true; > + > + case APLIC_SETIPNUM: > + case APLIC_SETIPNUM_LE: > + case APLIC_CLRIPNUM: > + case APLIC_SETIENUM: > + case APLIC_CLRIENUM: > + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: > + /* > + * Based on the RISC-V AIA spec a read of these registers > + * always returns zero > + */ > + *out = 0; > + > + return true; > + > + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: > + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: > + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: > + i = regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); > + auth_mask = generate_auth_mask(currd, i); > + > + break; > + > + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: > + /* > + * As target registers start from 1: > + * 0x3000 genmsi > + * 0x3004 target[1] > + * 0x3008 target[2] > + * ... > + * 0x3FFC target[1023] > + * It is necessary to calculate an interrupt number by subtracting > + * APLIC_GENMSI instead of APLIC_TARGET_BASE. > + */ > + i = regoffset_to_word_idx(offset - APLIC_GENMSI); > + > + *out = AUTH_IRQ_BIT(currd, i) ? vaplic_target_read(currd, i) : 0; > + > + return true; > + > + default: > + gdprintk(XENLOG_WARNING, "Unhandled APLIC read at offset %#x\n", > + offset); > + > + return false; > + } > + > + *out = aplic_hw_read_reg(offset) & auth_mask; > + > + return true; > +} > + > +static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, > + uint32_t value) > +{ > + const struct domain *currd = curr->domain; > + unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK; > + > + ASSERT(curr == current); > + > + switch ( offset ) > + { > + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: > + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: > + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: > + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: > + { > + unsigned int word_idx = > + regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); > + > + value &= generate_auth_mask(currd, word_idx); > + > + break; > + } > + > + case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: > + if ( value & APLIC_SOURCECFG_D ) > + { > + dprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); > + > + goto fail; > + } > + > + /* > + * As sourcecfg register starts from 1: > + * 0x0000 domaincfg > + * 0x0004 sourcecfg[1] > + * 0x0008 sourcecfg[2] > + * ... > + * 0x0FFC sourcecfg[1023] > + * It is necessary to calculate an interrupt number by subtracting > + * APLIC_DOMAINCFG instead of APLIC_SOURCECFG_BASE. > + */ > + if ( !AUTH_IRQ_BIT(currd, > + regoffset_to_word_idx(offset - APLIC_DOMAINCFG)) ) > + /* Interrupt not enabled, ignore it */ > + return true; > + > + if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW ) This compares the whole value against 7, not the extracted SM field (bits [2:0]). A perfectly legal SM=0 write with any bit set in the reserved [9:3] range (e.g. value=8) gets rejected here even though the actual field is fine Should be MASK_EXTR(value, APLIC_SOURCECFG_SM) > APLIC_SOURCECFG_SM_LEVEL_LOW. SM is WARL. If SM invalid but other fields valid, shouldn't reject whole write. Instead override value.SM with current valid SM in this branch, so other valid fields still get written. > + { > + gdprintk(XENLOG_ERR, > + "value(%#x) is incorrect for sourcecfg register\n", > + value); > + > + return true; > + } > + > + break; > + > + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: > + { > + struct vaplic *vaplic = to_vaplic(currd); > + struct vcpu *target_vcpu; > + unsigned int guest_hart_idx = MASK_EXTR(value, APLIC_TARGET_HART_IDX); > + /* > + * Look at vaplic_emulate_load() for explanation why APLIC_GENMSI is > + * subtracted. > + */ > + unsigned int srcn = regoffset_to_word_idx(offset - APLIC_GENMSI); > + > + if ( !AUTH_IRQ_BIT(currd, srcn) ) > + /* Interrupt not enabled, ignore it */ > + return true; > + > + target_vcpu = domain_vcpu(currd, guest_hart_idx); > + > + if ( !target_vcpu ) > + { > + dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n"); > + > + /* Ignore such writings */ > + return true; > + } > + > + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) > + { > + /* > + * A non-zero guest index asks for delivery to an interrupt file of > + * nested guest. The vIMSIC node has no riscv,guest-index-bits > + * property, so a guest is told its harts have no guest interrupt > + * files and the field is read-only zero for them. The write isn't > + * rejected (that would throw away a valid hart index and EIID); > + * instead the field is dropped, which is also what > + * aplic_msi_target_gen() does with it when programming the h/w. > + */ > + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) > + { > + printk_once(XENLOG_WARNING > + "%pd: vAPLIC target guest index != 0 is unsupported\n", > + currd); > + > + /* Ignore such writes ... */ > + return true; > + } Comment above this says "The write isn't rejected ... instead the field is dropped, which is also what aplic_msi_target_gen() does with it." But the code doesn't follow it as it returns true immediately here before the write occurred and without zeroing the guest index field. > + > + write_atomic(&vaplic->regs.target[srcn], value); > + > + value = aplic_msi_target_gen(target_vcpu, value); > + } > + else > + { > + /* > + * IPRIO is WARL and zero isn't a legal value for it, so normalize > + * it once: the guest then reads back exactly what it gets. > + */ > + unsigned int iprio = MASK_EXTR(value, APLIC_TARGET_IPRIO) ?: > + APLIC_TARGET_IPRIO_DEFAULT; > + unsigned long h = cpuid_to_hartid(guest_hart_idx); > + > + value = MASK_INSR(guest_hart_idx, APLIC_TARGET_HART_IDX) | > + MASK_INSR(iprio, APLIC_TARGET_IPRIO); > + > + write_atomic(&vaplic->regs.target[srcn], value); > + > + value = MASK_INSR(h, APLIC_TARGET_HART_IDX) | > + MASK_INSR(iprio, APLIC_TARGET_IPRIO); > + } > + > + break; > + } > + > + case APLIC_SETIPNUM: > + case APLIC_SETIPNUM_LE: > + case APLIC_CLRIPNUM: > + case APLIC_SETIENUM: > + case APLIC_CLRIENUM: > + if ( !value || !AUTH_IRQ_BIT(currd, value) ) > + return true; > + > + break; > + > + case APLIC_DOMAINCFG: > + { > + struct vaplic *vaplic = to_vaplic(currd); > + > + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO | > + (value & APLIC_DOMAINCFG_WMASK); > + APLIC_DOMAINCFG_WMASK includes APLIC_DOMAINCFG_DM, so the guest can clear DM through this write. But aplic.c: aplic_init_hw_interrupts() sets the real hardware APLIC's domaincfg to IE|DM exactly once and never touches it again. Is this expected? Moreover, I saw that d8fbe0bbc7's commit message claims: "a guest's domaincfg.DM reads back as a fixed one, so is there situation where we would allow direct delivery mode? If not, the else branch should be dropped. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:35:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:35:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405813.1639261 (Exim 4.92) (envelope-from ) id 1x1kBn-0002hi-Lh; Wed, 02 Sep 2026 12:35:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405813.1639261; Wed, 02 Sep 2026 12:35:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kBn-0002hb-J4; Wed, 02 Sep 2026 12:35:39 +0000 Received: by outflank-mailman (input) for mailman id 1405813; Wed, 02 Sep 2026 12:35:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kBm-0002hU-2Y for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:35:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1kBl-00FB8g-Bk for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:35:37 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981815-e002-0a2a0a5209dd-0a2a4505ea34-10 for ; Wed, 02 Sep 2026 14:35:37 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981819-4cb1-0a2a45050019-d155802ce110-3 for ; Wed, 02 Sep 2026 14:35:37 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49cd9add88aso6191785e9.3 for ; Wed, 02 Sep 2026 05:35:37 -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 ffacd0b85a97d-48448e7315bsm6326896f8f.7.2026.09.02.05.35.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 05:35:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788352536; x=1788957336; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=0ulDrxF237n8zka1LHEyq3hqJNDaanyFzVSvEb6TOjc=; b=YCFcdhIb5D+a7bZjEfAfgMU2dQUIcIpEdjXfYItUycB1RNjPv/kYMzXAczuczuid7p KF4MzYmWhwmB2INpqrqt9oBLEOT3kx+bPTIltHE3e4lqBL94gJhjtR5GAjTVZo/HOr5I XpeB0djt3Fg1G+6P2DCXfNvdrMyHtbAeWWs9n1pIRVBoXNMbgkQ7cmqCxaED/9c3fBCw QM0BXXwdYf1jUeG+OkBCpxwfiXkwzsgWlHM7zAOCrmHEHtdLP4IIp1TwYgIqj7vSMfxd Alp3UApMr/E1An3x17F25QxGX9hHXOIZojddHRUCs5MAaaMgXZpUO5vcWrcVpC/tjw6c Wfog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788352536; x=1788957336; h=content-transfer-encoding:content-type: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:content-type; bh=0ulDrxF237n8zka1LHEyq3hqJNDaanyFzVSvEb6TOjc=; b=soZ0sMnf23BFlI1/74Lu9y2DX+lA7jrL3LcfSZz5RFsBypEYgGHewZpiF5DdlygHNu mqoBt7ZZH+5UsndkNqYhGSrFHtMkDZeQxTXOVcJUGwfNVh5JhegGf7W9L3iBpj4qmVOQ u/W7SNEZAfLxoWMxvYArf9iSR5UIDtpjFzaUZN8EgLiduITuL1KkGX/Xafzj7kueD9ad wHlyXr7+S3z4u1of03jG3+mfM4CxfpnKHywcJT8L9IFrPmTJ51+V24/N4l5pj9SEXU68 JAQpA9iMHyXcIjqqYxVmoFo3FK2W78Fu4Sf9ZQ/rKy+4QU3Yj3PKuaXxkrj79fgj3huJ 8n6Q== X-Forwarded-Encrypted: i=1; AHgh+Rob8IlfdhR6aMapwS4UhQo/ueheuOMVqGmO2/z8fp7ANVVDwRszKxa8FyIEYNBa2wImgaJTFFlfmzY=@lists.xenproject.org X-Gm-Message-State: AFuF++nW7jziuO1kZ3OH36EuzUXDq3fwHbxQ7JkwWoxAYiK5MXJBNTKS p+bId6TA/EWeCU8jCb7T9ZlZvUnhoHcZZtle3NcqbdBR47Nvd3nNdMzV2XMddoLzC5dDqd6DM34 +QLTV7A== X-Gm-Gg: AR+sD11m+xDaaTxePrSIpiy7wjfKmckHengJG2v6inT+R7uok71AVKN8P+cjjW1N7iu MkSqYj5uUyeFKwYxJ2X6viVW0SckXryI79n/EzjkNT/91RQp7EmTTu4gBfJ5lnF5b+hx6aCLEk8 q7eNkd27SdI16cgWaGLGwFPcMUjX17ENqmwjMUDyCCrnlSd3S/dOSFKhbd+LSLDN44ZuB2v1U9u f24ZwhxjaQkNy17dy2vXu1n9Tdc9FqI0XR2qUKAgn/wypTfjeEU8uzsvXz3OPQXqvotB7uSIsL3 s7SQ56cep7avvUeiX0dTgod83zg7X9oc8nvzXOQJ2RCwzDAkjvWtAZZyAH4MJQwf0u42kuDYzGq DVV3Xd1zvdJgIAsdwUJCaLIig4Akc2JUTp05oITbd6sfcsSNL/7zVhSRElivOlOlWIpktCpp6fn Ar4CR0OMMBVhMIn8KqQoZVSpwY08E8Z1KiY8t65ScAzLiTXVLfbevJga6Fyc4a8xSmSi2st27Fw 4LHcNSPkAujk38qsC+AV3IMRRKXIn4/yqx8XYKTdsUEy+x+OVqV X-Received: by 2002:a7b:ca42:0:b0:49b:92df:87be with SMTP id 5b1f17b1804b1-49ce55fbdbemr54857245e9.4.1788352536571; Wed, 02 Sep 2026 05:35:36 -0700 (PDT) Message-ID: <3269b251-f5ae-4ee5-88fc-642c93ae5170@suse.com> Date: Wed, 2 Sep 2026 14:35:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/14] Arm/alternative: hide casting away of const To: "Orzel, Michal" Cc: Nicola Vetrini , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , "xen-devel@lists.xenproject.org" References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <6b3a3849-304f-423b-a3c3-a614d83858c0@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 X-purgate-ID: tlsNG-c201ff/1788352537-251182A1-DADF08C2/0/0 X-purgate-type: clean X-purgate-size: 979 On 02.09.2026 13:47, Orzel, Michal wrote: > On 02-Sep-26 08:32, Jan Beulich wrote: >> We want to patch the original call site, which memory-wise is unrelated >> to the struct alt_instr * that we start from. >> >> No functional change intended. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/arm/alternative.c >> +++ b/xen/arch/arm/alternative.c >> @@ -134,7 +134,7 @@ static int __apply_alternatives(const st >> BUG_ON(alt->repl_len != alt->orig_len); >> >> origptr = ALT_ORIG_PTR(alt); >> - updptr = (void *)origptr + update_offset; >> + updptr = (void *)(long)origptr + update_offset; > NIT: Why long and not unsigned long like other places in this file? Hmm, that was inherited from "x86/altcall: hide casting away of const", yet apparently wrongly so: update_offset is of unsigned type here. I've switched locally. > Reviewed-by: Michal Orzel Thanks. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:44:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:44:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405826.1639270 (Exim 4.92) (envelope-from ) id 1x1kJu-0004Uw-D3; Wed, 02 Sep 2026 12:44:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405826.1639270; Wed, 02 Sep 2026 12:44:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kJu-0004Uo-AB; Wed, 02 Sep 2026 12:44:02 +0000 Received: by outflank-mailman (input) for mailman id 1405826; Wed, 02 Sep 2026 12:44:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kJt-0004Ui-0d for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:44:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1kJr-00BU0u-U4 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:43:59 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981a03-bab6-0a2a0a5309dd-0a2a450c91b0-18 for ; Wed, 02 Sep 2026 14:43:59 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981a0f-f479-0a2a450c0019-d155802cc08d-3 for ; Wed, 02 Sep 2026 14:43:59 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49b8eeb3ff2so8623285e9.2 for ; Wed, 02 Sep 2026 05:43:59 -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-49ce4647472sm66865865e9.4.2026.09.02.05.43.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 05:43:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788353039; x=1788957839; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=kMXvHvoGB4+o6jAx8+NK0OjVKzstwY06/ccSn6nLBc8=; b=GF9+PblKNWAgJrp8cGeXj3lSvmsYkkqfHevRpIwaUA1F/KStBjVs+N5eabjEl6mlN/ Ndx/VfuOB9HHaszW9Py/r9YwSHI8WFNNJKfkq3L3MUOlKI6wMmHKkuTDDwpPECdHDy5D arZlqjOFVqgBRsTvy9T51Sl6r3cGu5g8XiIqBSCtCjWmnBiufijWqRUXOO0+OcMG9ia8 QvpUrzOZfO609gSr2wd0d4tqAE+VZmRWWABcXkzb1pRK/9RJRCGZyTP75dM55E9iQYTU D/eF3ydtyOrs04Yvgz2y3qb2QDD0vz2zYp3OZXkwiZ0cW5cmJH2szMV9bu0m8sVMiFu8 TNFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788353039; x=1788957839; h=content-transfer-encoding:content-type: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:content-type; bh=kMXvHvoGB4+o6jAx8+NK0OjVKzstwY06/ccSn6nLBc8=; b=ZrR7z2HFQeR1vPqmchaxdXrw0lQKT0HtuVd7SW/JVR3ZqiKY2aTwfgPrdQ06N33H97 CvwpMBpm+p+LqcSikj1MDxOGBLywfZ5t1O2FbTEDbuv72Z1pEnIlSIhvN0PUXfYXFOE6 pIDnhLjsEJ9OJC+943LwTjUmBTvwPnEGcw7M4SNDnLhSGNN9bLlzDPn/9XXUq328sGEH O3bEH2cL/nD4jwUruHfChljHKQp4y+ougLy2QBj1jPs9xogEQ6mTlMnD/ke2ehH6+Dpm ToIO1NNdKYkjnkExIIGYguO24xZ2EN8N/NsSHvSDOaEkFNPEI0VNtM1WZTC/NjNu7im9 8PIw== X-Forwarded-Encrypted: i=1; AHgh+Rqq25gNY05aLXCYoRIumx0KhbU4NgaqmgZtD3t3/3QPbkLpJc6wxfr7NeDWhUBFZbfmutUyK+PWaWU=@lists.xenproject.org X-Gm-Message-State: AFuF++mNaynIEPvHxAKYVhlnoZXc+tJ+z0nt3LGKxXK5jQwx6VvGJab8 fWaidIvSLD4dMZ/p2D7Spx2RVvHfjB8UL55CkqU5mR8lWutasDGNmGR+MS3XmAFmjg== X-Gm-Gg: AR+sD11rgPCpyhDc/WAmVh3fmVftSn3u9XhfDfwTEIZPkADGVDDNeczBmnRJ+zPwWBH tAJmyTIxahpbFCIwdjxbSoweCoHyTRuUC6QhClLX+vD6EEpXqrn/AuEZko+MoSUDb6jV+MHIiA1 zBBDLKVXfyYEy27mX46drn/oSduQSMZpDNIBZoONG3UeCtskM/jrbxE5USjo82K37AG9VkAL7HC alS7g58lkG/3fI9c43hkGwC4DVjl4/YHFj4OIsbANzrH31WXBHb0lzW+Dsv9XGGsr9ftDQ46NM3 5mY5qX9/naPfZYQd2YZ70AuwtbROYjEbstuUm3gOuLHCz3ksY95IKIj7j5S8dw2UPLygeMejKBv +ihgajqfrXFJGjjXWqjCSy+0MgEfqmZdkQ5so4JyR0nAUkXLZB2tZ6JSxx6vX3wOeO6Xk/kRvgT +9Msxnb9ZRWvHjwymL9YISfOd0pObv9Q05diHZT+PLEChbfwMvmdXUsUHxXCnfO8m+ELvCssCoZ BxDybqt8XEz79PLgrlNksjUE5O+i3DVNiG894reu8M1DwZaSb0G X-Received: by 2002:a05:600c:45c4:b0:49c:e1df:79a4 with SMTP id 5b1f17b1804b1-49ce57fdd1emr84013155e9.5.1788353039317; Wed, 02 Sep 2026 05:43:59 -0700 (PDT) Message-ID: <7515d6cf-4f5c-4390-abc7-45cf72b053b4@suse.com> Date: Wed, 2 Sep 2026 14:43:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] x86/bitops: Remove CONST_ADDR To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-3-andrew.cooper3@citrix.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: <20260902114339.62043-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788353039-772D8A5B-73B9C2D7/0/0 X-purgate-type: clean X-purgate-size: 578 On 02.09.2026 13:43, Andrew Cooper wrote: > @@ -285,7 +284,9 @@ static inline int variable_test_bit(int nr, const volatile void *addr) > asm volatile ( "btl %[nr], %[addr]\n\t" > ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") > : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit) > - : [addr] "m" (CONST_ADDR), [nr] "Ir" (nr) : "memory" ); > + : [addr] "m" (*(const volatile int *)addr), > + [nr] "Ir" (nr) > + : "memory" ); Hard tabs look to have slipped in here and in patch 3. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:44:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:44:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405830.1639278 (Exim 4.92) (envelope-from ) id 1x1kKP-0004uk-KB; Wed, 02 Sep 2026 12:44:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405830.1639278; Wed, 02 Sep 2026 12:44:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kKP-0004ud-HX; Wed, 02 Sep 2026 12:44:33 +0000 Received: by outflank-mailman (input) for mailman id 1405830; Wed, 02 Sep 2026 12:44:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kKO-0004tW-9U for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:44:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1kKM-001tdk-2W; Wed, 02 Sep 2026 12:44:30 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1kKM-00EnmR-07; Wed, 02 Sep 2026 12:44:30 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=4RoCr/ElA62rsXRLeawXNvGDM03CtcjBTsrhIohHtyk=; b=AQEzP9gjbHtovUoeNWAhT/Lh8/ zzPrbwm4gO00ES/FwT5Q65yqK+42l6DPFpHPAOuiCmnfgrK8CZ0Rld14YwlJs3Mo21NyCy4R1gKQQ QTyAcNFCaAzEjV0ANksCF+K8h1+THWe3KuKFIqeWsGo6e9vpYd7I19ykOo0Iup5RQL/E=; Date: Wed, 2 Sep 2026 14:44:22 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH 13/14] passthrough/PCI: rework (s,b,d,f) init of struct pci_dev Message-ID: References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Wed, Sep 02, 2026 at 08:36:27AM +0200, Jan Beulich wrote: > Right now we're casting away const-ness, to initialize the individual > elements despite the field(s) being declared const. Eclair validly > recognizes this as a Misra rule 11.8 violation. Hide this by switching to > the use of memcpy(), deriving the destination address from the (mutable) > struct pci_dev * which we hold in hands. > > No functional change intended. > > Signed-off-by: Jan Beulich > --- > Subsequently we may want to further leverage the sbdf local variable we > now have in the function. Yet of course the primary question is: Is this > an okay game to play in the first place? I've wondered the same, while this might be obfuscated enough for Eclair to complain, aren't we still violating the spirit of the rule? Regards, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:50:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:50:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405843.1639287 (Exim 4.92) (envelope-from ) id 1x1kQT-0006ir-79; Wed, 02 Sep 2026 12:50:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405843.1639287; Wed, 02 Sep 2026 12:50:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kQT-0006ik-4Z; Wed, 02 Sep 2026 12:50:49 +0000 Received: by outflank-mailman (input) for mailman id 1405843; Wed, 02 Sep 2026 12:50:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kQS-0006ie-Gk for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:50:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1kQR-000N2g-Mp for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:50:47 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981b95-8faa-0a2a0a5109dd-0a2a45028fa4-42 for ; Wed, 02 Sep 2026 14:50:42 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981ba2-6ca4-0a2a45020019-d155802dd5b6-3 for ; Wed, 02 Sep 2026 14:50:42 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-490cf322ed0so11208565e9.1 for ; Wed, 02 Sep 2026 05:50:42 -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-49ce4774a43sm66476615e9.9.2026.09.02.05.50.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 05:50:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788353442; x=1788958242; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=HK+l3p+avUXjjwOI+ZT2zYOCoW2HY3hG653O7Mmhfuk=; b=ImdBQL477HfDgil5Rr7owatKDMwhhrBrMx5bOLeRQ575r6gi3YESTnwnctwKKKXxVn A26LWaHZtER3Cb7zUb6iLgyWxOkGkOMOt/G6bgEOFJZ4rgGDmv9rDXVxsoQeICvGYCY4 xCXuyHRQyahz8TMdQNnX6FLta4AWTgrkwCDOTYsYqjcFg2YlIZt70CQzaWz/F3WkS6qQ 6I18Vv1v7/jVhjE/JaGdyJabqqPLcDt096ClVFQ/69sx4vbSAUxmzR4tKlJQwcTohQRE XJm6PxEv2P9KVyjwW045oNqPwwPJxyYTTDABC7/B22HNxAzn4jvTq4EsZk6WHSuAmz/2 6JEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788353442; x=1788958242; h=content-transfer-encoding:content-type: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:content-type; bh=HK+l3p+avUXjjwOI+ZT2zYOCoW2HY3hG653O7Mmhfuk=; b=FXuVYGisTcSNQLxylvHxtUEEELoh8ITquet4FO4Wfc9X2VicFw+16d0pm0a9ShJ+VS ua5Jn6pf1uOF/cNZUTg+d8uiVIrY5P4PEn8zfkx2s+uP0KqkuDGJt9CgioB9GIrCNatD ppyElR9Fp9m+vdbC5q4Rr4oaVApZPGo1Xh89A5I48rN6EGy4VGoKjKyPPHSi6LCO/1md dnMcrZQ0jWJqVrDPc66ExzuVWE626AFoXhhG2swmAp51Jp5VwhFr1Ww7d9eJT6nCLW4X spGfn7qTOFx+PVfUFy5a13GZLa8FQRXoM3QD8IvER0jGRZ8Zk6a5tFlkFlqm3GdgrBj1 STmw== X-Forwarded-Encrypted: i=1; AHgh+RoWS2j2tbIFswyWcCJ4bDzu1vtSzYUbpq9xhyJDO6CT4oiht+I93y7sp82yE0tWzKSJNgAK1VrpS4k=@lists.xenproject.org X-Gm-Message-State: AFuF++mwND3rtrH4gV5PlmK6M0Rt/UYkcHDwbVRp5fYS3njhD4RcGxdH 4fOplBotc8rusaAELwQOkwyof0+qdPe8+gsWR/xu4JqaULPj82L6Wk9pxrbHZhmJSA== X-Gm-Gg: AR+sD10Bt63oIekqEoCeZ0WOS+r5RfuWhHMDWdniFLph1oHC9Wrt5W0wCTfkZLIRNQ1 iE2f9dvzvoZoISoH3Es86c5HTP0UgLP04ckVj8QXlByDvXQNRH1yCNtYbpsxJny7Dl51lvDYLbG w1y/A3o4S0n8Ip4wgJt11/zfCz1+fIs4EjtJQgjBwl2zue4s/ChPTfnd5gHLlflUfA5EwlZgNEG VCvCrR7vcnrQsX3Z9BCIMynoDt4vedfc7AyGVg5tdsSfalUHuXsxL8pK5Cy9v0M5q/4wH8q2N8o 0O1VtI1MkoPBgBIfis014B4zOIbxZoXdPCAsm2F5ebGLdl9l/7e+mzy74/tPdZZWIwo2r0FR43W NMqjgaj4jOMDPH86kgMWse+SQP4OIyvXH+zVlzXJzlpiXDvPAtfoaG2b8A7Kz691zVqAgCqf4mj 8aI3X+8QvQ+Vfzw9F8tGujQ6HTaJhWf4RJ82jkWWCDLOVnQc4668EnwPzRegJ1Zhme+1y2cJLX5 i7PhHtF0alH6whAZT/mxtmkm58628Qs0MmHdVTkF2noWyvKaIJ5 X-Received: by 2002:a05:600c:e557:10b0:49c:e42b:a4ac with SMTP id 5b1f17b1804b1-49ce5822582mr62873975e9.11.1788353442111; Wed, 02 Sep 2026 05:50:42 -0700 (PDT) Message-ID: <0c43989b-2d7c-4411-8715-eab7390c14d8@suse.com> Date: Wed, 2 Sep 2026 14:50:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] x86/bitops: Remove ADDR To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-4-andrew.cooper3@citrix.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: <20260902114339.62043-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788353442-F36BF2AC-7C205966/0/0 X-purgate-type: clean X-purgate-size: 1034 On 02.09.2026 13:43, Andrew Cooper wrote: > All this does is obfuscate the usage sites. I don't mind these changes, yet I'd like to express that as so often there are multiple ways of looking at things. The benefit of the macros was that the use sites were textually shorter, and hence easier to process (assuming you know what ADDR stands for). > --- a/xen/arch/x86/include/asm/bitops.h > +++ b/xen/arch/x86/include/asm/bitops.h > @@ -9,16 +9,6 @@ > #include > #include > > -/* > - * We specify the memory operand as both input and output because the memory > - * operand is both read from and written to. Since the operand is in fact a > - * word array, we also specify "memory" in the clobbers list to indicate that > - * words other than the one directly addressed by the memory operand may be > - * modified. > - */ Might we not better keep this justification for the seemingly odd memory clobbers? (The first sentence, otoh, I agree can be dropped.) Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:54:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:54:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405854.1639296 (Exim 4.92) (envelope-from ) id 1x1kTf-0007J9-Ky; Wed, 02 Sep 2026 12:54:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405854.1639296; Wed, 02 Sep 2026 12:54:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kTf-0007J2-IQ; Wed, 02 Sep 2026 12:54:07 +0000 Received: by outflank-mailman (input) for mailman id 1405854; Wed, 02 Sep 2026 12:54:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kTe-0007Iw-3V for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:54:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1kTc-00Ggng-Vx for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:54:04 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981c67-2eae-0a2a0a5409dd-0a2a4506dbde-4 for ; Wed, 02 Sep 2026 14:54:00 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981c68-195a-0a2a45060019-d155dd2aad2e-3 for ; Wed, 02 Sep 2026 14:54:00 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48433fad54aso663079f8f.1 for ; Wed, 02 Sep 2026 05:54:00 -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 ffacd0b85a97d-48448e7fddbsm5953519f8f.11.2026.09.02.05.53.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 05:53:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788353640; x=1788958440; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=EVzIvntrdBachigCrXs5hhwAmXuepUUkG1cNV9+9DUA=; b=WVoRlSVEe7zEy3cB/3t6RrEWyzoR0Fi5+THRVCcWq7rK1ZOWIVmBV2Wj0EwtC6YSFi esuzoQQDG5ENvUhWE0w82i3LZl22sFhcbx7e3Mslg6iV6zpTEYDKYmBK03zZQwcd6KaI ijrgv1+9Kw28UBa7Ckg/KxWx8YT/7QD/pV2OtVRAdkOk3Niad8bN1laBumKb7kG5xNxI 0TjAt2DRuFZH5i//I4OaJLdDatQZ0Af7dsoEF2pf6AtfhT0NtdHSxOb6PclF9zh1oI3k LVnaWtNjHIGONiakPlUazYyr99+oR5GzEb7zJsLp8BVWSWQtEn6lhpauC1OJTMX5cwrz Uhsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788353640; x=1788958440; h=content-transfer-encoding:content-type: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:content-type; bh=EVzIvntrdBachigCrXs5hhwAmXuepUUkG1cNV9+9DUA=; b=Bs3E50eq6QkEV6N9EeM++qCyKnrIRQSEUQUm2rT24KnEnXhZtGJUuXao7IaDHseWOM KWGuxKWXBmdDDAeyfXt3PTRZOhfvAP52WO8s2z0U6ZA3EX5z113ms40aG1kC/A23ce8X kV2C9WIPxtEyRzI88EuS6SFIAeekpgSJHJTck4Sp4Kn4nosVhhSEVvMMEW5mbWeFi5pu +/nvzMag7VJ3VVULjC0/ucbexjY+2obj1AcWTD0lRmrtysr2Bkn8fyKguOdY8Gm/C8R5 OVTj9sk0biTarL6ppG3tlHQmGZDBECUCtBNNkQt617C4AD5uBPVzN13Yn0zrvggkzfsZ 95kQ== X-Gm-Message-State: AFuF++kN9985rqBEG32HWyhfgF3C4tBfLYF9X0arQwK8AZJuyqFwpoaE eBQ9b9BHsz57WJb56nzccDOW9nGlMDkTCD6i4mj6EE/GlBtf6JCccHyFn4uV/Lehrg== X-Gm-Gg: AYBFou0mwBmaJsxtCL3Bxnzh8EOEA8Y8k3LiTmeOsFYyHUOnyOx1ws4OQ2tD/s6cnqu QP/fYUBVGLlOce1bQxPMtyrnqSAlDLWDujb0o+f08GpelWOPYOfaBjNE0Lv3BQrq5FvxNhOLbzj NZ0i2mch+T8F9ddslAZYTs8ia45pGM+jWN5+492FDNEo/iyVKvkQWVSs3tGj3u2gPdtpZ3D9ys3 HFGyqsxC3p3WvW5l5lZGcy+N5TH5ZHrW7kp6xktKHAginlNl/nKnyBeaU9F22MVOPCVWvSwFgUQ zaQnlmAQmohoZ4XjUKOT+eGzoGf9EOxNWgS05WKG9C2TCOxGx9HsTvllQK3I1rj/5aSyCRh2JXk O9xlENkQmr3Cpkww6yCMJf/vOLr5g+bAiCvblqX2TD+ddp4WOr5Gf+3BxGi6GxQxsf1XPX90rgY DuKsCrzDtCR65uOlfWMh/d7IclABzGqdDD2pX0/S1koE4p0c7szylUhamKYxFkBoRHWH6dPIc3f tUBoVgVVMWys+jSaejeb3Pk5egDZZpxKC6ldg9NJ9HGE9qYmQPRgQ== X-Received: by 2002:a05:6000:2607:b0:484:3310:7110 with SMTP id ffacd0b85a97d-484914c272emr8008399f8f.28.1788353640244; Wed, 02 Sep 2026 05:54:00 -0700 (PDT) Message-ID: <52dcd7cd-52db-4b59-90ef-f7cde79cf5bc@suse.com> Date: Wed, 2 Sep 2026 14:53:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 13/14] passthrough/PCI: rework (s,b,d,f) init of struct pci_dev To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@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: 8bit X-purgate-ID: tlsNG-16d1c6/1788353640-1F0C777B-919E8FC9/0/0 X-purgate-type: clean X-purgate-size: 1045 On 02.09.2026 14:44, Roger Pau Monné wrote: > On Wed, Sep 02, 2026 at 08:36:27AM +0200, Jan Beulich wrote: >> Right now we're casting away const-ness, to initialize the individual >> elements despite the field(s) being declared const. Eclair validly >> recognizes this as a Misra rule 11.8 violation. Hide this by switching to >> the use of memcpy(), deriving the destination address from the (mutable) >> struct pci_dev * which we hold in hands. >> >> No functional change intended. >> >> Signed-off-by: Jan Beulich >> --- >> Subsequently we may want to further leverage the sbdf local variable we >> now have in the function. Yet of course the primary question is: Is this >> an okay game to play in the first place? > > I've wondered the same, while this might be obfuscated enough for > Eclair to complain, aren't we still violating the spirit of the rule? We do, but what do you do without dropping that "const" (which I'd really like to keep), and without C++ concepts of initialization? Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 12:55:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 12:55:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405864.1639305 (Exim 4.92) (envelope-from ) id 1x1kV8-0007qj-1X; Wed, 02 Sep 2026 12:55:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405864.1639305; Wed, 02 Sep 2026 12:55:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kV7-0007qc-Up; Wed, 02 Sep 2026 12:55:37 +0000 Received: by outflank-mailman (input) for mailman id 1405864; Wed, 02 Sep 2026 12:55:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kV6-0007qU-5B for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 12:55:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1kV5-004BsM-Hp for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:55:35 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981cba-8faa-0a2a0a5109dd-0a2a450a8ba4-14 for ; Wed, 02 Sep 2026 14:55:35 +0200 Received: from [40.107.208.18] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981cc5-f2d2-0a2a450a0019-286bd012c2cc-3 for ; Wed, 02 Sep 2026 14:55:35 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB989393.namprd03.prod.outlook.com (2603:10b6:a03:40c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Wed, 2 Sep 2026 12:55:31 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Wed, 2 Sep 2026 12:55:31 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fiAUCmxgfLVgd89j8XpF2jXYqlO5PhIdVp9cHyuB/rO7yyykBW6CJx/whOR5nWbvD5RGOb6j/dZEKyQLbqEyhKMBB+ugSoPsmCL91g2mjFljiK+YveOKLnjn7yB09bpttPjzfWHpdmIcyNSyWo//MFxi9fTOoOZ5OAZDwn84cVFiwgkXdUzZASfWIPEKaL9+Vy0NtXN9NurfQd1P8MM9RF+OFeeO2ny+qE5QU5/qhAHd5y43t6XdPaRHAsS4wdH1pJZe1l4OKC2xNCpO6qBc5lwW+s7V2wJLxWl30c846EXBBsD8zclfBUaCzyCIqsfoAAh0WYEGX7Yqm1yuHyX4+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pnGhNjvRLAqGuN352sznOHCf+WWTc3/shtTpWm6XGDQ=; b=VftP7rP0xHW9q00aN8T5UJGuG/tL1+SxGnKg5OETzyR/ALJEnltw44pMvg1wcgrisUBXG9CLK4k59B1ul1HoZ3oHXwXGOGtCMbv/FzRF0UUb9AVz7gbghqQXscEa9EOQmGlkRF6Hv7FTeWegKKsi+q2Pa2VXeMEyJb2CGQycAw9je0ST2c7Deum33jlNoZDnM38Gy02w36s12cTfxSOodB558rNBS4VRkgNUEpvE2vryu58ET5qMpCBhnkC7mODmuAkpMvpmM+lTQRuM2Y0SFiFtXiC4ZIc+D0RLxoD3OBarCmOAi9KgOoeEvwoEi0uo9rEaAtkHnOZ2ND34IaqQ/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pnGhNjvRLAqGuN352sznOHCf+WWTc3/shtTpWm6XGDQ=; b=izVISoFXwcgrSVaOp1yg6I5uppkj2ydeXiilz/VhTryohCutaB3al7IdNysBCiqUGYQLubkY02dy8ojNmOke2+xvDLJcgVuN8N0WoVApw1m/U/wxwxEN8AMbHtASO4uFMc/GDVyi1iIyTHBvSh36SgvZ0MsWTE+5C9muAgNTd1k= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 2 Sep 2026 13:55:27 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org Subject: Re: [PATCH 2/4] x86/bitops: Remove CONST_ADDR To: Jan Beulich References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-3-andrew.cooper3@citrix.com> <7515d6cf-4f5c-4390-abc7-45cf72b053b4@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <7515d6cf-4f5c-4390-abc7-45cf72b053b4@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0625.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:294::23) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB989393:EE_ X-MS-Office365-Filtering-Correlation-Id: 363cea3f-6d11-4184-4b4c-08df08f1786f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|56012099006|10067099003|11063799006|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: fvCGifQICZ3r8D7v8kEyw/MOzLLxR7TDlLyqXpwT52/srDC98684tOcTvCt+B4mW54L4YN4Fzg8d1mNq2r9eC3pC9JJyBepQeWPb99URWBRqijVm82jnkuNMtBo0Gp0B00OOwh7T/mm9SOcnhSqUpDhfnLwhB/fJaGXC632L4HX7dNEVKf/gbqlTzIZPw7S1efP7ojRdi1xaW8wd6elqFLXU+uHFMiIU2mU+LTmurQMhehRKdjgaw//oOSgWdutSoFdVFe+KGWLOInO9ynKLihxlGCmO9HMKUqATnzkfv7iwykZivmZ+W6co3E+OdWqZw9UD7S8buXROqwfuIkrOU7+AwdBQxckdIK/j15YBVLjU6y54uRydoYanIhn78Q8C51OT8FpqFj+9O9B9AWWTHqaSTgViQpK61iowvoKrypy+nrgIHm4Q+Os35fjmlM3fXxcidN3EeyBbR71+hIbQstxlyjl0WamdJgS1D5b88WAkDR8TJUxBhmL0cykeME6YD0d5TvxONEFKMYz2DPFbAXcn6sGk1a+l+zHAyOv9sacLTbnP148mP+86G2IG9QjPuDiYnJGRLo0Omf1Azp0CiIj6pSwA5aSySt9qanjgnOmGhWVYgzy51LhwBstLiyK6HN9PC+xTLM/RHlsoMlr7gGEsYHnukslQnQe6q43BxFY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(56012099006)(10067099003)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TVpzWEVPc1M0VEVhbDFrTmpiR3RWR2d2OENaUDk5WmZJQmRxTUxOV2Z2VFlz?= =?utf-8?B?dXJFNGQrVUJNSnVyTUczUnFmRFB1Tjdic2pWWW1WWlBJS21GdWV5STdIeXE5?= =?utf-8?B?UE5wSTJqdmxSZFQxdmtub3BhS3hRR3Zhd09OSk9sRFREc09nYkhob2MxWGtL?= =?utf-8?B?TkRGZEphbXBtQU9iNG8vTkx1b0NyNkVkaC9lM1BVekkxazh6VkRrZFc3RFI5?= =?utf-8?B?YUpKQ0xweU91RzlHWnZidFMxYTlhWW81VjB2d0J4cXpMSmZHdVBOejZmbFVq?= =?utf-8?B?bHQ4T3I0VGVEMDRRbUhKa0FubUNEV0hURjlEWFI1RDB5K2NRb1B3SmVnYVcx?= =?utf-8?B?aHgvR2Y5SVA1WXZyMUxlV3JsekR2OWh0NEo0NXVVWW43YTIxRi92R0tTWVVG?= =?utf-8?B?Szd5cTR3WWRTS1BqN3Btd0RxOWdaK0IvaXQyb2lCNkZtZnhJd2FUb0RJaC9n?= =?utf-8?B?blRVcHFOMWVJc0N1dGN2MDJXTkdTd3JGb3JrS3kzT0pOTVo0QUN6V3RHc0hw?= =?utf-8?B?bUpHcGhiZllZRUZ5UkZlVkwySmUva0llQkZBWXErN25LTG9oSFlqRHJWdGN2?= =?utf-8?B?M0dPZU5rVUZMMlY4enVxVjBGeUt6MUs2QXVLcjRIejJDU0ptek5TTmJmQ0pj?= =?utf-8?B?YVlUMnBDZnBCeHdnNStnOEo5bEdwYXlyOWF3OVRXR1F6bUpwY1A4aTlMRnpW?= =?utf-8?B?cXFzZEpiSWU5TDhQY0haOE9EWUdlbldsQ3NNK2c1bWN0a3VjNlB1dGZvbzNU?= =?utf-8?B?R1ZrTVU0bEo4UXljMEZIOVpXbzVqMk0xWUxhMk05K2JFZWs5Y01YMExodWZD?= =?utf-8?B?RXRDVEYzMFAxdlAxcTN4V0hGL0FvOWdqTXFYMEpycEZRemJ1Tk9lNUVpVnRL?= =?utf-8?B?MG1jUjFQa2RVSWErV3pjZEErZjg5eWZMUHpsR29aQWRyKzhITi9uZnZMRjVH?= =?utf-8?B?dDBMVHJKZlo1TUhKa0l1Z2tZT1pwcERqdHlDem9aQmdyNm5aQXR4dG52TCtG?= =?utf-8?B?U2p5T004RVZUZElrcW9acFR5VW5OYkkwZnYrWnZFVmxxL3hqcTZCVVk2cmFE?= =?utf-8?B?bW5XQ0NPTDFiTU96NzJORmdxekRYRXZYbjI0VE9ET2xySlZ2bE1aT0tQcVlk?= =?utf-8?B?Mi9JUkdTWDhPM2hQNkgwK2FQVGRCZTZwU2ljcFZiRWdnSVAraVYzTWFpVVBa?= =?utf-8?B?V2FnRVRDVzdmYzhVbDFZbW14em9mK0wwdWM3YkZkK0JCemN2WS84ekhzTk5X?= =?utf-8?B?UThnYW1OSktoK1BEUlBrdXY5TkpqQUZkZWxCVHVuSklaWFhyek5DVzdWVE1U?= =?utf-8?B?ZUNpTTRvRGdITjY0RnJPTDcrVzBhY0k4eWFUWUxzN1lUbTV6T2JscWNtZEJN?= =?utf-8?B?aWRHRnp1THowZWxXN0xIQnJ4cmF5WmhkSjAwQTNWdVdJVFVhQitaSjR4bjJ1?= =?utf-8?B?aGMrcDBuUXllMmRjczhyRm1BNHpYV3YrS3A5SDR6Y2hYSExzRzdCWmx0ZnNn?= =?utf-8?B?cEZ6Qkt6YjVOdkZ5VWlDNmNtcDVBM2RGbWw3ZTZ4WnJCYlF1bHhCQVBZT0ov?= =?utf-8?B?d1JqdHhwWU1WSmhTdE0yVHlsL1B4dHhKbWI1cmJmY2thdGN3Vjd5SGZwNFAx?= =?utf-8?B?YS93bmY2OXN6VXBCZVBTUEZ6M2JDOXF5dERDYnpuRW9XVW9rMlRsZ2JSbVRj?= =?utf-8?B?cmZMQlppU2tPdTBNNDdaZE1ta2FGVWowaGR4S3BXbjhTWWhwZ3VzWnlvSHJQ?= =?utf-8?B?aGYwY2VERXNDQTlmUHpZeUE4NmFQNDVwZFpzZEdtbEhDb05meE9zV2E4YzBS?= =?utf-8?B?bTB3clp5ZDI5eGdvTHRnbjlOWTBXeUZPaXJxamJ1aWx6aUplRUY5eW9IRERt?= =?utf-8?B?SjBBZnpYT1p0eFpObEdyV28rdFhRRG5tdmpxT3hEQjhUQWdxM3RQbms0OEFy?= =?utf-8?B?VHNycThxOVV1aFN5NC9FUUN3QjRjWWRJck5HT04xb1hkWmFWZ0xNbzFHMXdp?= =?utf-8?B?SFRSVHpIUnQxeCtsRUlnbjIwbGhjNGpQeFZRcERvYVc1cG4wTVZpaGFwNVl4?= =?utf-8?B?RnZDWGl2M3doM3lwM2N5aVgyRkhyUkZsUytyNy9HMEgvbmxkQkJBeVpOL3JS?= =?utf-8?B?emZSazlYUDVXYjZrYUhNRGpISGFobWo2QmRXK0krcWQ2V2NieWF3a1Ivai9z?= =?utf-8?B?YzR0NjhpMFkrTmNnRmZOdFBmM0lqMS9tdEtkQVBNUk1vWjNOa01zdG55NEZ4?= =?utf-8?B?cTZSc2I1MXBIOGw4OXo1b2hMQk1UQWN0R3pMN20xQzQraG83VmpDWWxWem9u?= =?utf-8?B?ZGxtWEUyOVByK2kxMk5zZVZoMGVPME5PcEpJd1dMUWtySzZqVFVMZm5LMEo0?= =?utf-8?Q?wi+n+E/qzeaXoo0s=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 363cea3f-6d11-4184-4b4c-08df08f1786f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 12:55:31.2336 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EayQstI4mxa9ETDEAAwt3j5dVBk1alabVRL9TS3XXDehhHMT8FUQp01ALq8h3ogiFXS60H8wMjmGFmOSznhYmaAZif93jJEBCr7MzKHmobM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB989393 X-purgate-ID: tlsNG-4011c0/1788353735-524DFCFC-527FD4CE/0/0 X-purgate-type: clean X-purgate-size: 709 On 02/09/2026 1:43 pm, Jan Beulich wrote: > On 02.09.2026 13:43, Andrew Cooper wrote: >> @@ -285,7 +284,9 @@ static inline int variable_test_bit(int nr, const volatile void *addr) >> asm volatile ( "btl %[nr], %[addr]\n\t" >> ASM_FLAG_OUT(, "sbbl %[old], %[old]\n\t") >> : [old] ASM_FLAG_OUT("=@ccc", "=r") (oldbit) >> - : [addr] "m" (CONST_ADDR), [nr] "Ir" (nr) : "memory" ); >> + : [addr] "m" (*(const volatile int *)addr), >> + [nr] "Ir" (nr) >> + : "memory" ); > Hard tabs look to have slipped in here and in patch 3. Yes, sorry.  I only noticed after emailing out, and fixed up locally. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Sep 02 13:02:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 13:02:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405875.1639316 (Exim 4.92) (envelope-from ) id 1x1kbl-0001Kt-OR; Wed, 02 Sep 2026 13:02:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405875.1639316; Wed, 02 Sep 2026 13:02:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kbl-0001Km-JJ; Wed, 02 Sep 2026 13:02:29 +0000 Received: by outflank-mailman (input) for mailman id 1405875; Wed, 02 Sep 2026 13:02:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kbk-0001Ka-5V for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:02:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1kbj-00BgUE-IL for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:02:27 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981e60-e002-0a2a0a5209dd-0a2a4505973e-16 for ; Wed, 02 Sep 2026 15:02:27 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981e63-4cb1-0a2a45050019-d155dd2bc10e-3 for ; Wed, 02 Sep 2026 15:02:27 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-47fe89fb333so656201f8f.3 for ; Wed, 02 Sep 2026 06:02:27 -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 ffacd0b85a97d-484492cdc37sm6820642f8f.34.2026.09.02.06.02.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 06:02:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788354147; x=1788958947; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=ag0JmfDwxevGBw5kL139Z/6F+5N/7/FNh63AC6xHi7M=; b=grKq9ebw6fza1NEyA4vR0bOzIMHHlPhIcQpKoM4mVBXTonuJBr/uNlaX5mxqEhpAun x5mlU/1XRF9p5kIYjZz4cxANLCmBPkcjQK4CzThb81eUaHFNF17OlIGDviBquGqw5pRu Mq20/4utQFHRMhxZJxGQLxzaO3oeh4B/X/lQ/b3LL8L2XrlpLC1YXiNW5LgJSSosq4gR XbB0GOO/hi1lALHjZmPFPC6KUFYOQdjatKP07rOnohGdvv2w7LOmdPJVovLky49bIXVG a6DYx8KezgcwHYhn90/IfCqr5E95XFS+JQuo01zHlO/dB5yIx4kjdgHoJqk74SqMbt9t p91A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788354147; x=1788958947; h=content-transfer-encoding:content-type: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:content-type; bh=ag0JmfDwxevGBw5kL139Z/6F+5N/7/FNh63AC6xHi7M=; b=a/goiUW+7sqo7tNhWmQEwJf0jGgkknCtUV7Xo38JqKrvHT1HEzKxTUFwPTksnLcQvF mxTsKyeecBdUBo4OVZ7Mxy042vmvuIlopNtrf4v8F4QMknTjeqa10UvW2viPoLD6rL+X PL883JmLj1grXIwZ+32imWVNhx2y8+wbPL+/c998H2KjFR921xELdAXMydFXAZsrlRD5 0La+u5MkmeipsiQRopGqVhpHOhggAEOugubBWaT8P6H6qtW4Og5UYO14OO6EsHLfa9Ba MESMVekuRVzzCMTa95upAUlY4da/eytIBkXk+1oKmhgs9K2keucbsRTqn4HFkI/GlPbv eACg== X-Forwarded-Encrypted: i=1; AKwUvBw5MHNhH6AxiInkJ93Yaf4bYxl66Kl97n2segRQY2FAnMQC9Ib1c4CXRExiU4x7nVzNJnCKM9eiBf0=@lists.xenproject.org X-Gm-Message-State: AFuF++n5JCJZaNsNxUwS9nNfjiXgAVZSbvafUiwEvuZti15koru4Euyq ZK0aot4g5K5K1cSFrlfWXvQ2IGGV+dCvKasITuPRg6S/UYFr8EpyQ4qpG5KsluoN5Q== X-Gm-Gg: AYBFou3XR1OkD4nlH+lM5iX1Fe+e56NMRzoL3A8NYT7dQjqD7CUfzr7jIhwFV8WFUGr NOVmX2FqNJQdxr99X9T31TZEF230DBJc+ZGq3tFG8YlLlROijLugBGhT/Ed1Dp+GQncnw+eBhOo 2DJIhiDGaCgB0s4tAa0yVBeSWuGPZXOXR7DGYBzkgQuHCqQa8+wzCbTzUoTzsft5NuhkGoaL+Bg h1fDDwmurF5HibalOgp8vkY0Ei/WK2E7417+nI7NL2DjSdLlxNUwYgI7EUsokyz6yUyVGNeZLOR g3dErx2Cg+VsMqS6cp1QzIDVNW8maj82kCrNnWmGGqfNABznkznUT0E7Pr+fsQbXHZLMDtCdKqe 4v9ttimQwSS5JmvqffuTd8VFaFdqljT8AhWY0OUQqODov04kUeAtdDFOwy1PZ+X3H6nFfXH78G6 XmkyZr6xwtVmTcMIfJJuG8zqFaN/sA/Sl5ZL/EpOyisSq9QlqNPZD7nQXfn3REN63Mszdo/LTai UAz9uFYxy3LgENTIAYcopyJ8mHBLxrcrJpdI9w= X-Received: by 2002:a05:6000:2282:b0:482:e62e:a528 with SMTP id ffacd0b85a97d-48488f0e579mr9711622f8f.12.1788354146362; Wed, 02 Sep 2026 06:02:26 -0700 (PDT) Message-ID: <3b07e1c6-eee0-4b54-8bd5-fce8db4ef726@suse.com> Date: Wed, 2 Sep 2026 15:02:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/39] xen/riscv: drop bug.h's duplicate instruction length helpers To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.com> <5d8888f1-d6f6-4f73-812b-8a79edceed95@gmail.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: <5d8888f1-d6f6-4f73-812b-8a79edceed95@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788354147-24F1F2A1-F2848AA4/0/0 X-purgate-type: clean X-purgate-size: 1217 On 02.09.2026 12:48, Oleksii Kurochko wrote: > On 9/1/26 9:01 AM, Jan Beulich wrote: >> And then >> >> #define INSN_16BIT_MASK 0x3 >> #define INSN_32BIT_MASK 0x1c >> >> are really named backwards, seeing e.g. their use in > > It was derived from OpenSBI project and I haven't paid enough attention > for these defines. > > Now looking at them again I fully agree that names here not really > correct. It should be according to the spec: > #define INSN_32BIT_MASK 0x3 > #define INSN_48BIT_MASK 0x1c Especially the latter would then still be misnamed, as the mask merely identifies insns >= 48 bits. Even for the former I'd still question the name to some degree ("mask" doesn't mean all of the bits need to be set). In how many places are you going to need these constants? If, by suitably using helpers, it's just one - maybe better to get away without any named constants in this case (i.e. when suitable names are apparently difficult to come up with)? > I think that for now it is enough to go without common implmenntation of > INSN_LEN and just return 0 as suggested above. Suitably commented upon that would certainly be okay with me. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 13:07:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 13:07:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405885.1639323 (Exim 4.92) (envelope-from ) id 1x1kge-0001yF-5q; Wed, 02 Sep 2026 13:07:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405885.1639323; Wed, 02 Sep 2026 13:07:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kge-0001y8-3A; Wed, 02 Sep 2026 13:07:32 +0000 Received: by outflank-mailman (input) for mailman id 1405885; Wed, 02 Sep 2026 13:07:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kgc-0001y2-Q9 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:07:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1kgc-002urN-2f for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:07:30 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a981f8a-2eae-0a2a0a5409dd-0a2a450986e6-28 for ; Wed, 02 Sep 2026 15:07:29 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a981f91-be1a-0a2a45090019-d155dd2ab4f0-3 for ; Wed, 02 Sep 2026 15:07:29 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48436251906so1140222f8f.0 for ; Wed, 02 Sep 2026 06:07:29 -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 ffacd0b85a97d-48448eea961sm6440559f8f.28.2026.09.02.06.07.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 06:07:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788354449; x=1788959249; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=vb02FW8tGEf13a7CalRORKHZMMVH1pipaK/Lpcv4Tnw=; b=RGeYOdKJubIjjccSXIv3PF/k08GKIoBZMO+Y+4EB+63jqS8gtSiiqE4elrFBseuULg nYhorKH8yHVycgvz03VmiK6HFL616kd/a1JWAmmZosTej3p7iVqG5W4NUhP7rixPZ5oY BEbOCS8/cIP4WuElc5MHczyRBL0XX33gxE0I06+Ngb4wPFnvqL9GpvZetQj4uintxybM 0zcVgouHyMGvh54EMVYJuSrteJuFtOrjfOMS3P/fR+pk09AnUBoWf6JYQRdmuG5SXGaL TDkmDKNE1cv1AdljrbDsaV8gjhKXYkfmQhJ/o0aZMxWDwcucwjclf/EIlkg/5MyclG3p aHCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788354449; x=1788959249; h=content-transfer-encoding:content-type: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:content-type; bh=vb02FW8tGEf13a7CalRORKHZMMVH1pipaK/Lpcv4Tnw=; b=eAZ6hjhexGGQn8iQQWvRCvmATV552P44fmgX0Na3kUAQVj+XaP/yAo2Oo03TgWawIj bklA1K0nnh8p6evfzUoq08c/2DMii+HNA3XQ5yaBANOvNAz11tbHEFxFmeFnZNlSqBdd 2V3DEOQfl4+I4vjBZSJEUcJL2puDaH/5s/phwX+YewDy/6GPgiocEbmSAepH4QmUa6gN rHLINjsLOqFsIdwmQ2kZAjDkPk1tBf08XHNTkAxDFutMMNET/6lmSnyurIzpaLmE41Cy PZ1JjEdrRDHkZDbl7Z1OU5IgrKG667h09uLI4iHcLoVZnSAnkru4b0bEg6i+Zb2e1YxP Hi8w== X-Forwarded-Encrypted: i=1; AKwUvBxVWbrKCeNaYJQX+r88Ryz+QEWmwbQXbNQcDVhAewISTJqoUkEJut4nRYBroKeskrESXIbUDZ9wDMY=@lists.xenproject.org X-Gm-Message-State: AFuF++nopdu+Kf9cFr6I+KTAyoKwYd8zkt9+HOvjh3tAFqdyPOtouJGg IjIhk8QWKpCC5sQ7syRRprQoiLGAP/I+XJRnhmID/cRo17Io4IEENjZ4fkRXQruzog== X-Gm-Gg: AYBFou0mtLjwU6JXZFyJOgmUJ0YJcwRz5n4pccYeqkO1mlA2tgtB6fnmRgTeqQeOzF3 KWEgOG/AS9TZx8N53Lbto0h/2182klR8j2mnaFPweGRSe+9sdd6svmxSLQWvC5BRRY5qMtCmh6R 0VGawNGo1QVrH9vM1uUeiyKMwdigqUE7LwwzZcyY/E4T53jE966OifZ0YzbZsO+/EIrvfm+A86t /Ijv7ZwzDMO2XBpjxvRCpXNYx+bOD1ard/JdDX+Ax2v7GET4lJk54T2ZKC0Pe9+JzPR3JlwYmZ9 zWjcCMabpom/GTWy8MX3w+b2hyjYRDY6eUP/KZbWLTuBpF+CO9jmhhBNeC2pZ0M8G2Sc7dXHIX4 xdtAXHue0nFt6o5bBC8Gv4LqHeemfYKsu3KWBV+m2BfR8wfOSoVHodNM9Lw5gJalc4vdWVRIWbr 7yfAw0QrM1pz6JPuy1DgMUg3DmuRlYFIp+g+QxkPtkNzIrmChUvIOD6k5HInUTwwz2hUHh32XP6 DVb+5Dl8a6i7W/gqylBxuf6ofNBjaIhQyBOSsyLIlOHxdneS4Jg X-Received: by 2002:a05:6000:18a8:b0:47e:81aa:3832 with SMTP id ffacd0b85a97d-48488f1b1f1mr7860742f8f.16.1788354449128; Wed, 02 Sep 2026 06:07:29 -0700 (PDT) Message-ID: <071c5b4f-1d57-4223-94bd-9f8ae8d80366@suse.com> Date: Wed, 2 Sep 2026 15:07:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> <127e8aea-4d65-492e-8bda-bffc75f02481@gmail.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: <127e8aea-4d65-492e-8bda-bffc75f02481@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788354449-39EC6034-1277DF2A/0/0 X-purgate-type: clean X-purgate-size: 3223 On 02.09.2026 13:42, Oleksii Kurochko wrote: > On 9/1/26 5:20 PM, Jan Beulich wrote: >> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/domain.c >>> +++ b/xen/arch/riscv/domain.c >>> @@ -88,7 +88,13 @@ static void vcpu_csr_init(struct vcpu *v) >>> { >>> v->arch.hedeleg = HEDELEG_DEFAULT & csr_masks.hedeleg; >>> >>> - vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; >>> + /* >>> + * Xen supports 64-bit guests only, so set the guest's XLEN explicitly >>> + * rather than leaving it to the WARL behaviour of hstatus.VSXL, which the >>> + * decoding of a trapped instruction depends on. >>> + */ >>> + vcpu_guest_cpu_user_regs(v)->hstatus = >>> + HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(HSTATUS_VSXL_64, HSTATUS_VSXL); >> >> The comment is correct right now, but the situation better would change >> at some point. Can't you arrange for things to be correct here also for >> a future where 32- and 128-bit guests would also be supported? > > I am not sure about 128-bit guests as H extension is dependent on RV32 > or RV64 but probably it will be changed: > ``` > The hypervisor extension depends on an "I" base integer ISA with 32 x > registers (RV32I or RV64I), not RV32E or RV64E, which have only 16 x > registers. > ``` Lots of updates like this likely will be needed for RV128 to actually become a thing. > I will introduce the following (also it will be needed also to check if > we could VSXL set at all as implmentation can make that field read-only > and do VSXLLEN=HSXLEN): > > /* > * Return the hstatus.VSXL value encoding the guest's XLEN. The switch() > * deliberately has no default case, so that adding a new domain_type (a > * 128-bit one, in particular) fails to build until this mapping is > updated. > */ > static unsigned int domain_vsxl(const struct domain *d) > { > switch ( d->type ) > { > case DOMAIN_32BIT: > return HSTATUS_VSXL_32; > > case DOMAIN_64BIT: > return HSTATUS_VSXL_64; > } > > ASSERT_UNREACHABLE(); > > return HSTATUS_VSXL_64; Why not simply return 0 here? You genuinely don't know the size. > } > > It will also affect then common code as vcpu_csr_init() could be then > called before domain type is set: > > +++ b/xen/common/device-tree/dom0less-build.c > @@ -812,17 +812,18 @@ static int __init construct_domU(struct > kernel_info *kinfo, > else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) > kinfo->dom0less_feature = DOM0LESS_ENHANCED_NO_XS; > > - if ( vcpu_create(d, 0) == NULL ) > - return -ENOMEM; > - > d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; > > rc = kernel_probe(kinfo, node); > if ( rc < 0 ) > return rc; > > + /* The domain type needs to be known before the first vCPU is > created. */ > set_domain_type(d, kinfo); > > + if ( vcpu_create(d, 0) == NULL ) > + return -ENOMEM; I don't understand the need for this, likely because I don't see why domain_vsxl() would need calling from underneath vcpu_create(). Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 13:22:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 13:22:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405901.1639333 (Exim 4.92) (envelope-from ) id 1x1kvM-0005Hx-EH; Wed, 02 Sep 2026 13:22:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405901.1639333; Wed, 02 Sep 2026 13:22:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1kvM-0005Hq-BS; Wed, 02 Sep 2026 13:22:44 +0000 Received: by outflank-mailman (input) for mailman id 1405901; Wed, 02 Sep 2026 13:22:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1kvL-0005Hk-Gl for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:22:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1kvK-004Gjw-PK for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:22:42 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98231e-8faa-0a2a0a5109dd-0a2a4501a452-6 for ; Wed, 02 Sep 2026 15:22:42 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a982322-5984-0a2a45010019-d155dd36a52b-3 for ; Wed, 02 Sep 2026 15:22:42 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-4843e397f74so1224224f8f.1 for ; Wed, 02 Sep 2026 06:22:42 -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 ffacd0b85a97d-48448e13db0sm6863597f8f.0.2026.09.02.06.22.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 06:22:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788355362; x=1788960162; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=YeCoXADY6GWlM/05snJqFynnYRKMSUFqnC/3xpOQfPY=; b=Y+lZ3Ivl14n0Ejk33x4Y9tIcpoF3B5LF+IuDHsQ4fELolyIwUSFDpG2mjb4bzvW6Av I5liz/4p91Q1hfqNaHitGUWNDqH7McwX86tiHf2CgugHBqAVgOEKZ+rlPYfQ9rA4iTZF CgwBt8u4l5XnPDLnPJ+zXL9/BtT/rrHv1a8kwaSVbBoTIMY7E438ZDyH6h03ZX6cF4zq 02Wk0ViYFGAesYh4vPEP+ouqVyuP5A3WEL2kzE5r7TlkGT7ZXWTjK6vABrLTf3SZgG9s 5MR8TOOUcAchW807NsBxKQ25kQ/zNuqZHHtgHPqYxdWAqzaqH8y3G2dbw7UXzzN3D4qt YXEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788355362; x=1788960162; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=YeCoXADY6GWlM/05snJqFynnYRKMSUFqnC/3xpOQfPY=; b=a84CJPY7Tw/kd3P2p+5J3yQFhSXOXZAKexqChFbUllA1sJmfYLzw0ZA/GvgGNSiDUk 6fXpEFc0LkdjAD29ilnqmnaP4WwkegqNdgm2C3IWgOWGb+TFOA26OLc7ZwITWtWC2omk 6tELkvGr+WnF2mlG1/pPq7I08R/H0cZASa061x+XhI2+FcJZwAeWfCqvgBUyooG9bTfR NjXZEewK5FLxI3J8R3r+MP4WBsHg4OgZ6J4YRLres5dRHjfLDEUZJKZTGa5eJs41GQcz vZNpm0z7DWGc1ZqXHGHzyx1XxLu7jYp1tAzhtb0oDy9Wmm/ogoLrAWd55/MtIiznlojH JVug== X-Gm-Message-State: AFuF++myotmkiGwDcx3TBy00OR+Q/VrzrKBpNrtK3e6shmrYlz56MvW7 ST/RBOjngPaBV2YGc/ZP+V+Q7KK79zTwXXi4PURPxgmkf3ssqv6T3BNvxJskoNj9gQ== X-Gm-Gg: AYBFou13fEuI8pqThUmUkGfbplI2GWuZaf8DevFSZUC4JnLY6GZQwiwGXesaWyVgvf4 JnzEOIbLPzFv42rn9QCg0Z4QYR6oNOwFzpfoHpGB84EIv7ponDtUvZTZ0I4Q2dKVJTVcla4USJc OHnk2WzhtO8hYTy2jcRMYj5yZEsq9s8aFmuM/vsupnBEn4KCBVoKpzuMhoKTE5/v3Ts85VBGrKp pnvUp6QMt3Y1l92VeJSUK4vBJGCwfEhvLcuQJ4eBtqIH8YDTIqqDwh6sgaXTmpKM1tlm0PnXEmf pAaN/bMRKYFdujeHTH6vojCeIkU1XuiGw08gkIR1kNi7ioYfsBYVtxiM2xi0uM3InmHxZ5TAV+w RzCO2OKVOE0m+7mzYWfXLtOOxC7UrT2oRmDQwDjA7sJKKJXk7aZl6PSMN4r8Ac32FMioRuaFYpI e3YdLqzCr08RSrwPJ048A7sf2b7k85UvvLaoC00dEOgBh8lyRT4v7+ZAHCGrsbiqy10/tEh5k2N gFpJLk2RQ9fNQ4Q6M+8CmImBZxdvlUw8inUQgTkiMBSrSbro0bc X-Received: by 2002:a05:6000:18a3:b0:47f:71a0:c060 with SMTP id ffacd0b85a97d-485781d2fd6mr6586060f8f.2.1788355361924; Wed, 02 Sep 2026 06:22:41 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 15:22:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/39] xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h From: Jan Beulich To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <1788276968.8631fc262581453bbf619ec5b2062170.1a05d9d0d1d000c4f3@vates.tech> Content-Language: en-US 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 X-purgate-ID: tlsNG-d62444/1788355362-1F86F757-EF07C715/10/73395122804 X-purgate-type: spam X-purgate-size: 1124 On 01.09.2026 17:53, Jan Beulich wrote: > On 01.09.2026 17:36, Baptiste Le Duc wrote: >> On Thu, 27 Aug 2026 17:20:51 +0200, Oleksii Kurochko wrote: >>> These definitions are required for correct decoding of APLIC MMIO >>> accesses and target configuration, and will be used by both the >>> physical and virtual APLIC implementations. >>> >>> While adding them, rearrange the header in the style of x86's >>> asm/msr-index.h: a register's offset is immediately followed by the >>> definitions of that register's fields, with the blocks sorted by >>> offset. This makes the relation between a register and its fields >>> obvious from the layout alone, so no comment is needed to express it. >>> >>> [...] >> >> Reviewed-by: Baptiste Le Duc > > Acked-by: Jan Beulich > > If there's no dependency on earlier patches (nor the prereq series), this > could go in right away. Yet nothing is being said anywhere, unless I > overlooked anything. Doesn't apply cleanly to current staging, so left out for the time being. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 13:29:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 13:29:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405910.1639342 (Exim 4.92) (envelope-from ) id 1x1l1k-0005yn-2u; Wed, 02 Sep 2026 13:29:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405910.1639342; Wed, 02 Sep 2026 13:29:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1l1k-0005yg-0E; Wed, 02 Sep 2026 13:29:20 +0000 Received: by outflank-mailman (input) for mailman id 1405910; Wed, 02 Sep 2026 13:29:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1l1i-0005ya-6w for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:29:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1l1h-004I26-G1 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:29:17 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9824a8-8faa-0a2a0a5109dd-0a2a4505bf60-20 for ; Wed, 02 Sep 2026 15:29:17 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9824ad-4cb1-0a2a45050019-d155802fdd9a-3 for ; Wed, 02 Sep 2026 15:29:17 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-499ac87c92bso10362775e9.1 for ; Wed, 02 Sep 2026 06:29:17 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448e6f604sm6482517f8f.2.2026.09.02.06.29.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 06:29:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788355757; x=1788960557; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tAlUjlmyv4q1cod1GTkTt95vKxYmRGexBK1P5HXBrXk=; b=qogptg/dNu7NZQIaXKugfdqsjrce7Rg/VX+PLKJbeVL4IKJe1xBR7Hd4R4OAST8EEc kP+RiUFM0PeKZlAkt+Z0R1uhV33sSF379tW6CS8kwFEh0uj5BM3+mzCqwxcqfmrYn/Kf PYvhvauAF9ttWX177c2pBCkKr2eiEAkV+VENr2lzcGQmzIZslRtLFb3BT/SJI7c07ejx 0DOBatkspQGptcNTdcW8Vk2GPeNVF+zjDwYsxMmATlTN9L83cvsZzCyIxGVHbSGkX200 r84zTnOaStUDnI3EI3Mlh8mZI53Ggd6hnFMDEg1hq+lpuDbvE4WcD9JIYdPYyNHoNOyp aURQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788355757; x=1788960557; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=tAlUjlmyv4q1cod1GTkTt95vKxYmRGexBK1P5HXBrXk=; b=hvOaTyUh03wtF8XiOd8xWmE+lfho7l97xAlLg5WZsRAUV0AfBn4m6qJ5Q3IGJdwmzH sfh54Cn8UyAY4RVBV4kTM2d3vfkjzDVwaDQvG2cxeSFQuLY8cgDBtD86InlOpVYiSAlc KnTOMBU8fNpwEUWkEQnEzfp1cqeHjl+xNzUv1H8RAKxcTkv/+bcSNibaK55YINXnIE/2 Vhap0350kU5c14CBHq1GvD0m4jNMVbxno58Cnt//oIb/8ymBGp5wk4WNqHU0v82/LPeD Gzwz5gm4Xc8J5ugK0tFEvNoqjtFSS4aLcM/j5kE0QdKkPxYUwj3TzOh2Xo+LwFAP0Mfo pgDw== X-Forwarded-Encrypted: i=1; AHgh+Rpb99KrvHVyBpeZuh9GpOhd4ogAwCGUsI1guCC787gB4qhxv5E4rVz4nnm5ImPJy5ACrd7YFLRSMjo=@lists.xenproject.org X-Gm-Message-State: AFuF++lL/ucZ+7LGAf3/xhX/IfoqYKYQ80QlCYbu+oUwZ0t0vMqKuKoM CvY7HCkgYryZCbT0cR3I7+SGOBvjGaUOT56LCYqCuusDgqas8FXcuBZA X-Gm-Gg: AR+sD13BJlvxGyTyWy0035fExlcXdFNuKz+ImQ9IFdEKUdxVwzQjM0yJbGHJGGMZtlA mr7MMo9tc1qkktED+RRVhMb6Y0+CFp6rreOc20sg0Vu/ZGm1XNKnaq3ZSvfpTztUnMrvi2OGEkS Q0wVXM6kGrDnTcrOsfCD4IP5KClUQhG/lKHN/9htSiEjJjrpQtoZgR+Qmmj5ZwGlqHBIpkU2jyd PNTdEGpicYg5nFGOC/Jbvek2twW48KItCyB7IT8ZLcOfgDsCHnocuQzp2/jOd49SPa7zbLDhijP njaE8omBOsbKCJfPnoz6ZZPe1QUZW4OsFyExia5pKQ7dwGtu8msB6NPgyiNpqCR+BIvO4/Erpz/ NdAvnil13Zj+5HMeE8r6hGuMIti9pdYVnwpI8abfkfo6tieOyifaN6ZWvFfUqLyuLZm8RS3Dm5B QCSpysez+M5PYrTzTggcnB03lYHYU0xLQfyfFgk6fADzSg1em3IkWghAdlhmEhuq5M9/yehuft4 MnC2Iwq7nqvh/D+PAvCbQaAOVWALhA2bBk8IsL4og== X-Received: by 2002:a05:600c:37ca:b0:49c:cf18:494e with SMTP id 5b1f17b1804b1-49ce5819a2fmr94675505e9.12.1788355756355; Wed, 02 Sep 2026 06:29:16 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 15:29:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> <127e8aea-4d65-492e-8bda-bffc75f02481@gmail.com> <071c5b4f-1d57-4223-94bd-9f8ae8d80366@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <071c5b4f-1d57-4223-94bd-9f8ae8d80366@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788355757-72EB12A1-EA8EDF1F/10/73395122804 X-purgate-type: spam X-purgate-size: 4061 On 9/2/26 3:07 PM, Jan Beulich wrote: > On 02.09.2026 13:42, Oleksii Kurochko wrote: >> On 9/1/26 5:20 PM, Jan Beulich wrote: >>> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>>> --- a/xen/arch/riscv/domain.c >>>> +++ b/xen/arch/riscv/domain.c >>>> @@ -88,7 +88,13 @@ static void vcpu_csr_init(struct vcpu *v) >>>> { >>>> v->arch.hedeleg = HEDELEG_DEFAULT & csr_masks.hedeleg; >>>> >>>> - vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; >>>> + /* >>>> + * Xen supports 64-bit guests only, so set the guest's XLEN explicitly >>>> + * rather than leaving it to the WARL behaviour of hstatus.VSXL, which the >>>> + * decoding of a trapped instruction depends on. >>>> + */ >>>> + vcpu_guest_cpu_user_regs(v)->hstatus = >>>> + HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(HSTATUS_VSXL_64, HSTATUS_VSXL); >>> >>> The comment is correct right now, but the situation better would change >>> at some point. Can't you arrange for things to be correct here also for >>> a future where 32- and 128-bit guests would also be supported? >> >> I am not sure about 128-bit guests as H extension is dependent on RV32 >> or RV64 but probably it will be changed: >> ``` >> The hypervisor extension depends on an "I" base integer ISA with 32 x >> registers (RV32I or RV64I), not RV32E or RV64E, which have only 16 x >> registers. >> ``` > > Lots of updates like this likely will be needed for RV128 to actually become > a thing. > >> I will introduce the following (also it will be needed also to check if >> we could VSXL set at all as implmentation can make that field read-only >> and do VSXLLEN=HSXLEN): >> >> /* >> * Return the hstatus.VSXL value encoding the guest's XLEN. The switch() >> * deliberately has no default case, so that adding a new domain_type (a >> * 128-bit one, in particular) fails to build until this mapping is >> updated. >> */ >> static unsigned int domain_vsxl(const struct domain *d) >> { >> switch ( d->type ) >> { >> case DOMAIN_32BIT: >> return HSTATUS_VSXL_32; >> >> case DOMAIN_64BIT: >> return HSTATUS_VSXL_64; >> } >> >> ASSERT_UNREACHABLE(); >> >> return HSTATUS_VSXL_64; > > Why not simply return 0 here? You genuinely don't know the size. Agree, just 0 will be better. > >> } >> >> It will also affect then common code as vcpu_csr_init() could be then >> called before domain type is set: >> >> +++ b/xen/common/device-tree/dom0less-build.c >> @@ -812,17 +812,18 @@ static int __init construct_domU(struct >> kernel_info *kinfo, >> else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) >> kinfo->dom0less_feature = DOM0LESS_ENHANCED_NO_XS; >> >> - if ( vcpu_create(d, 0) == NULL ) >> - return -ENOMEM; >> - >> d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; >> >> rc = kernel_probe(kinfo, node); >> if ( rc < 0 ) >> return rc; >> >> + /* The domain type needs to be known before the first vCPU is >> created. */ >> set_domain_type(d, kinfo); >> >> + if ( vcpu_create(d, 0) == NULL ) >> + return -ENOMEM; > > I don't understand the need for this, likely because I don't see why > domain_vsxl() would need calling from underneath vcpu_create(). The call trace will be the following: vcpu_create() -> arch_vcpu_create() -> vcpu_csr_init() -> domain_vsxldomain_vsxl() unsigned int vsxl = domain_vsxl(v->domain); ... vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(vsxl, HSTATUS_VSXL); Without moving vcpu_create(d, 0) after set_domain_type(), domain_vsxl() will return something wrong. I also thought about updating of VSXL for each vCPU in construct_domain() where d->type is already known and then no changes in common code are needed. But I think it is a little bit better just have a change in common code. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 13:29:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 13:29:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405915.1639351 (Exim 4.92) (envelope-from ) id 1x1l2K-0006Rw-AP; Wed, 02 Sep 2026 13:29:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405915.1639351; Wed, 02 Sep 2026 13:29:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1l2K-0006Rp-7i; Wed, 02 Sep 2026 13:29:56 +0000 Received: by outflank-mailman (input) for mailman id 1405915; Wed, 02 Sep 2026 13:29:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1l2I-0006Ra-DL for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:29:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1l2H-00Bmp3-5u for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:29:53 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9824cf-bab6-0a2a0a5309dd-0a2a4502ecac-8 for ; Wed, 02 Sep 2026 15:29:53 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9824d0-6ca4-0a2a45020019-c387df82ebc0-3 for ; Wed, 02 Sep 2026 15:29:53 +0200 Received: from knuth.suse.de (unknown [10.168.5.16]) by smtp-out1.suse.de (Postfix) with ESMTP id 754DF21D30; Wed, 2 Sep 2026 13:29:44 +0000 (UTC) Received: by knuth.suse.de (Postfix, from userid 10510) id 5CB02AE779A; Wed, 02 Sep 2026 15:29:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by knuth.suse.de (Postfix) with ESMTP id 42B67AE7799; Wed, 02 Sep 2026 15:29:44 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:cc:MIME-Version:Content-Type:In-Reply-To:References"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de"; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:cc:MIME-Version:Content-Type:In-Reply-To:References"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1788355788; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JcrhHoLi9Dgkir2K1kU+9E3wacEKvPTtR3HgxM8VLPk=; b=a8qp2g9ZcT+rpjEdsDS39IubTtS+x2ehbhsLidZAJXr+4+HmM3pQqBtLXRgX7Bk0ZiY4tL XnkZ+ydbYZuR2Z3UdebjTUU0qK4f+6CMccMuAK/PTRyAmfCyGeCPNCNo5w5fhrtGhi40AW UxRby67B5SKQlN4d9RHy9LDfKlvwW0w= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1788355788; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JcrhHoLi9Dgkir2K1kU+9E3wacEKvPTtR3HgxM8VLPk=; b=zVXkWdr3892abkdxjA3uQDAyi8x9VDk4LdnUSScyt1O1zDizow7cB63aVuLj2AWm3QHMJz gaoe0eis6F1alCBg== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1788355784; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JcrhHoLi9Dgkir2K1kU+9E3wacEKvPTtR3HgxM8VLPk=; b=i7CNFpdCs5BKknGndwVSsiI9wy6UC5Z3CECMp2CtHvl8WEUPK/85+b4Ma8LVnoB7n1z9U5 wZ3cjwZNYf8H8zBAJakVmwdOSJqCUMnHfsQnFv1C1Wx2uy+M5IWh8XYDQHN3REaPOHxAqC 8hR4bBORuR88qnCTKDgYCdeDS+i81DA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1788355784; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JcrhHoLi9Dgkir2K1kU+9E3wacEKvPTtR3HgxM8VLPk=; b=M8vN8FpQm6FeTa5KX0O9PlTFreGfmKqz4y59LKN5KjQkyjyE4gRaydbLsENxQ16hBIyiCs FEnfwrP2rUy5vvDA== Date: Wed, 2 Sep 2026 15:29:44 +0200 (CEST) From: Michael Matz To: Borislav Petkov cc: Mauricio Faria de Oliveira , Richard Biener , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() In-Reply-To: <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> Message-ID: <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-669869079-1788355784=:4446" X-Spam-Level: X-Spam-Score: -3.20 X-Spam-Flag: NO X-Spamd-Result: default: False [-3.20 / 50.00]; BAYES_HAM(-3.00)[99.99%]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_CC(0.00)[igalia.com,suse.de,kernel.org,redhat.com,linux.intel.com,zytor.com,suse.com,gmail.com,oracle.com,vger.kernel.org,lists.xenproject.org]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; TO_DN_SOME(0.00)[]; RCPT_COUNT_TWELVE(0.00)[16]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RECEIVED_HELO_LOCALHOST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FREEMAIL_ENVRCPT(0.00)[gmail.com] X-purgate-ID: tlsNG-720697/1788355793-66CB22AC-89040DD3/0/0 X-purgate-type: clean X-purgate-size: 2294 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-669869079-1788355784=:4446 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Hello, On Tue, 1 Sep 2026, Borislav Petkov wrote: > On Sat, Aug 22, 2026 at 03:33:17PM -0300, Mauricio Faria de Oliveira wrote: > > According to the GCC documentation, conditions in the flags register > > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2]. > > > > Also, clobbers (e.g., "cc") may not overlap with an output operand [2]. > > > > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the > > "=@ccnz" output operand. Strictly speaking, on x86, the '=@ccXY' constraints are register outputs into normal random integer registers (though they are of course initialized in a funny way), while the 'cc' clobber is not a register at all, but rather a fuzzy idea of "state" in old cc0-based compilers (which the x86 backend isn't anymore since, ... well, about forever, 1999). As such they both really don't conflict and ... > But then I'd expect that gcc would enforce that. I know it can't have it > when the clobbers contain input or output regs: > > In function ‘__memcmp’, > inlined from ‘main’ at memcmp.c:25:6: > memcmp.c:11:9: error: ‘asm’ operand has impossible constraints or there are not enough registers > 11 | asm volatile("test %3, %3\n\t" > | ^~~ > > but with "cc" clobbers it works. ... hence there's nothing to report. In fact what an explicit 'cc' clobber once meant in cc0 backends (that indiscriminated flag "state") is manufactured by the non-cc0 backends (all of them now) automatically whenever an asm has no flag output constraints at all. (On x86 that means it adds the "flags" register (internal name for the collection of flag status bits) to the clobber set automatically when there are no =@ccXY constraints). You can regard all 'cc' clobbers as pure source compatibility, they have no meaning anymore. But as they are so ubiquitous (even in our own docu), they remain recognized. Ciao, Michael. --8323328-669869079-1788355784=:4446-- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 13:45:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 13:45:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405941.1639360 (Exim 4.92) (envelope-from ) id 1x1lHQ-000172-IQ; Wed, 02 Sep 2026 13:45:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405941.1639360; Wed, 02 Sep 2026 13:45:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lHQ-00016u-FI; Wed, 02 Sep 2026 13:45:32 +0000 Received: by outflank-mailman (input) for mailman id 1405941; Wed, 02 Sep 2026 13:45:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1lHO-00016o-I6 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:45:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1lHN-000YRO-Ud for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:45:29 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a982879-2eae-0a2a0a5409dd-0a2a4507a052-0 for ; Wed, 02 Sep 2026 15:45:29 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a982879-b4ea-0a2a45070019-d155802ac9d0-3 for ; Wed, 02 Sep 2026 15:45:29 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49ccfbe062eso8478365e9.3 for ; Wed, 02 Sep 2026 06:45:29 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce47b9817sm52937825e9.1.2026.09.02.06.45.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 06:45:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788356729; x=1788961529; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9V3PTU1WYvGw5DNhBIzSyKAFbZj366QeU6iOoA5sIno=; b=tLgexUqaNprzkiroXhRNhTv5bKpRZbDfCthTb4g4OmhvkpZha4DOEp9fiZjfl/6zbB Z6Jac/mllSZj+qB4iSkWPBW2y5BVa4fFX0ZnI/JUP4hn5RTvAscvx6XdVMlvGceWzrFX moT6wYqmK5LBYUyGVWKx2WSRzd2w4SMgwHBgz9NSfn8ibbD/vQ7ACPc8Y54/MAdLPZk/ cqHSQ/ZwwPup8KomHqfZtzXtDCEOR6cW7iH+dGwdlGSBfmaw+EAiHe8CXAOQyHap43yA eFV0j2lfrFm40quK8yum1smeFk4SVifBR/c3WkIeKY5b5j6q7DHLZNB0+ImupDwOUKy/ UMLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788356729; x=1788961529; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=9V3PTU1WYvGw5DNhBIzSyKAFbZj366QeU6iOoA5sIno=; b=c8L0eCDoVPNnRikjDMfyaggQARH2hkrhNtQ8iJcGLwdao9yjmrMHf3rgsTSubjsavE Uy0+6wXTa/cTawGrA7qsKRR34vJHggwHNI5nTWlvhYEQ5ABBtRpjuWOF+r5Oru8NKTjH sSPQwGkPFhlt2gd1mOlIu6qLn79BTwXIykxe/k8V8NZzfOlbSxWKnF1CYcVPlja5W+16 ZDX1qoVla4Z6N2dgiJR7qVGwJUTeCxpSQHB/unj/hNzDcmqOheQpdZ31FD41bANH68Sp VlxI1oB47C+8RlFbGINx5SCOFzz6MJ0+9Q5gaMKt9fNSPmwQnfIbt0Ef6E+zajM0R++t dJ1w== X-Forwarded-Encrypted: i=1; AHgh+Rq8vgrs7vq41SkMELEsxa9302R+GzuKbUk72ugtc7fd9R+3r0bnMWeDvxIZxXovq37r2wSemCBTfp0=@lists.xenproject.org X-Gm-Message-State: AFuF++n6pDxl4yFKu+nrlv/bkPHtIbxsM1l8HYaCNd9IR8vSO4o4lZkG O+1/fawAAqe16SgzleFB6LUy1Orxf4R9iK+NiGf0Au1NuNsxP95fJiYf X-Gm-Gg: AR+sD13HQTm/P142YmiS4CYU6Flr/9HOOQ/uK8rQpEIOkOtMiyMidoN+NHiTFeMtN39 I6a+OuGh3dWmSK6KBPnAdWRdL4CbHHg3YQmFzy1S7+mLHGWfncCKtZhVS7qbqsTKslSWzX74uNx HGg81tpznlmae1nd2NA26z7+9Z7OvMu+TlvYasQxXILUYEaxWTpyv7O6gwnOIqpwtQASNoUDXym fW02rE8mdNaR7Bqkw4ltFHKmbPnOd/M5jpHAJNJZ2fbo6HQh0mzpRQOpn/T4Ikt/sIN43dJhwzI PPi2YG0o0oszgax9BRFR8tx9WIVeG1NBZNJKco1rctr07R6hFQfMhIJc23NFzP/A95a5vEoZjBL tJG9q/SUBprDQ0OUejqQjfsROyCf6agsBpk2b353pcw9k9jCJiMjqELd639goqkwTCkeBoPg0Hb QsRfnL2EKAP4BheAVTVvIjWsHR5rapYvGrtxwJ7A129Yv6RN2ggvaQZ1TutL9646qSTko8Mecic Yonfn7CjlIJZ1fhRzgVFHLpeP8tXawyeSZXnMc3aQ== X-Received: by 2002:a05:600c:530f:b0:499:bdf1:7578 with SMTP id 5b1f17b1804b1-49ce55ecdf2mr99415825e9.3.1788356728981; Wed, 02 Sep 2026 06:45:28 -0700 (PDT) Message-ID: <21e80092-5abf-427d-87d8-cdbe58874a10@gmail.com> Date: Wed, 2 Sep 2026 15:45:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/39] xen/riscv: drop bug.h's duplicate instruction length helpers To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.com> <5d8888f1-d6f6-4f73-812b-8a79edceed95@gmail.com> <3b07e1c6-eee0-4b54-8bd5-fce8db4ef726@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <3b07e1c6-eee0-4b54-8bd5-fce8db4ef726@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788356729-A58C1AE4-3004F6C0/10/73395122804 X-purgate-type: spam X-purgate-size: 3263 On 9/2/26 3:02 PM, Jan Beulich wrote: > On 02.09.2026 12:48, Oleksii Kurochko wrote: >> On 9/1/26 9:01 AM, Jan Beulich wrote: >>> And then >>> >>> #define INSN_16BIT_MASK 0x3 >>> #define INSN_32BIT_MASK 0x1c >>> >>> are really named backwards, seeing e.g. their use in >> >> It was derived from OpenSBI project and I haven't paid enough attention >> for these defines. >> >> Now looking at them again I fully agree that names here not really >> correct. It should be according to the spec: >> #define INSN_32BIT_MASK 0x3 >> #define INSN_48BIT_MASK 0x1c > > Especially the latter would then still be misnamed, as the mask merely > identifies insns >= 48 bits. Even for the former I'd still question the > name to some degree ("mask" doesn't mean all of the bits need to be set). > > In how many places are you going to need these constants? If, by suitably > using helpers, it's just one - maybe better to get away without any named > constants in this case (i.e. when suitable names are apparently difficult > to come up with)? INSN_16BIT_MASK - will be used only once (except INSN_IS_32BIT() and INSN_IS_16BIT()) in insn_fetch_faulted() introduced later in this patch series: di->insn = htinst | INSN_16BIT_MASK; INSN_32BIT_MASK - is used only inside INSN_IS_32BIT(). And INSN_IS_32BIT() and INSN_IS_16BIT() are using in several places. I am okay to drop these masks and then just have a comment: /* * Instruction length encoding helpers (see RISC-V Unprivileged ISA, * Section "Base Instruction-Length Encoding"). * * - Instructions with bits [1:0] != 11 are 16-bit (compressed). * - Instructions with bits [1:0] == 11 and bits [4:2] != 111 are 32-bit. */ #define INSN_IS_16BIT(insn) (((insn) & 0x3) != 0x3) #define INSN_IS_32BIT(insn) (((insn) & 0x3) == 0x3 && ((insn) & 0x1c) != 0x1c) As an option we could come up with the following names: /* Bitmasks for instruction length encoding fields */ #define INSN_LEN_1_0_MASK 0x3 /* Bits [1:0] for 16-bit vs >=32-bit */ #define INSN_LEN_4_2_MASK 0x1c /* Bits [4:2] for 32-bit vs >=48-bit */ #define INSN_IS_16BIT(insn) (((insn) & INSN_LEN_1_0_MASK) != INSN_LEN_1_0_MASK) #define INSN_IS_32BIT(insn) \ (((insn) & INSN_LEN_1_0_MASK) == INSN_LEN_1_0_MASK && \ ((insn) & INSN_LEN_4_2_MASK) != INSN_LEN_4_2_MASK) But it seems the first option still looks better. Would you also prefer Option 1? > >> I think that for now it is enough to go without common implmenntation of >> INSN_LEN and just return 0 as suggested above. > > Suitably commented upon that would certainly be okay with me. The the following comment looks good enough for me: /* * Length in bytes of the instruction whose first parcel is @insn: 2 or 4, or * 0 when the encoding is 48 bits or wider. No ratified extension defines an * instruction of such a length, so rather than open-coding a decoder for * encodings which cannot legitimately occur, leave it to the caller to treat * the 0 as an illegal instruction. */ #define INSN_LEN(insn) \ (INSN_IS_16BIT(insn) ? 2 : (INSN_IS_32BIT(insn) ? 4 : 0)) ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 13:48:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 13:48:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405950.1639370 (Exim 4.92) (envelope-from ) id 1x1lKY-0001ta-3Z; Wed, 02 Sep 2026 13:48:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405950.1639370; Wed, 02 Sep 2026 13:48:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lKY-0001tT-04; Wed, 02 Sep 2026 13:48:46 +0000 Received: by outflank-mailman (input) for mailman id 1405950; Wed, 02 Sep 2026 13:48:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lKU-0001tN-Mj for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:48:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1lKU-00FP57-38 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:48:42 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98292f-2eae-0a2a0a5409dd-0a2a4507b37a-38 for ; Wed, 02 Sep 2026 15:48:41 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a982938-b4ea-0a2a45070019-d561b338eb64-3 for ; Wed, 02 Sep 2026 15:48:40 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x1lK3-00DcvD-D4; Wed, 02 Sep 2026 15:48:15 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x1lK2-00Fbfl-Gp; Wed, 02 Sep 2026 15:48:15 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x1lK2-00000005efq-1wbk; Wed, 02 Sep 2026 15:48:14 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=58qqfjMVhvSKBno1pG7rNumItbKcnzJgJLj9UyPe5Ps=; b=nZO8BEvTrlQGU9RSC1Gs15aClM IN49e3tBEdMvbHrZybWANDpjiyQoNHg8BocuJU8sWkwPtbEWUweHYLWNHi91jzzkwdZ713XX6iikj jSkNT4Jkam0pPU2zqpYMIaDVk8C7L6dxfAcRSKBZTXwEvQ868fxOg1OZTPkFeejsdFRj3aBQn17Qj EkF2csedkHmH9FGypd2mADsZoD0GfUl5OOQfRiNrmoxPGGMw2E69asm8DhvHnJ4GU5ZU8xdM1WloH OFRy1EB1XCk5KyHR3I492GsqyVP4Mvle3KkjxFIeERi3EketeAIQeQZ3Iwp/OBAetJiinLbJlpF1o dYXUtpfg==; MIME-Version: 1.0 Date: Wed, 02 Sep 2026 10:48:14 -0300 From: Mauricio Faria de Oliveira To: Michael Matz , Borislav Petkov Cc: Richard Biener , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() In-Reply-To: <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> Message-ID: <05896397667d66a2969259298bcebb7f@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-ef75cf/1788356921-37CD7AE4-0966C813/0/0 X-purgate-type: clean X-purgate-size: 2325 On 2026-09-02 10:29, Michael Matz wrote: > Hello, > > On Tue, 1 Sep 2026, Borislav Petkov wrote: > >> On Sat, Aug 22, 2026 at 03:33:17PM -0300, Mauricio Faria de Oliveira wrote: >> > According to the GCC documentation, conditions in the flags register >> > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2]. >> > >> > Also, clobbers (e.g., "cc") may not overlap with an output operand [2]. >> > >> > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the >> > "=@ccnz" output operand. > > Strictly speaking, on x86, the '=@ccXY' constraints are register outputs > into normal random integer registers (though they are of course > initialized in a funny way), while the 'cc' clobber is not a register at > all, but rather a fuzzy idea of "state" in old cc0-based compilers (which > the x86 backend isn't anymore since, ... well, about forever, 1999). As > such they both really don't conflict and ... > >> But then I'd expect that gcc would enforce that. I know it can't have it >> when the clobbers contain input or output regs: >> >> In function ‘__memcmp’, >> inlined from ‘main’ at memcmp.c:25:6: >> memcmp.c:11:9: error: ‘asm’ operand has impossible constraints or there are not enough registers >> 11 | asm volatile("test %3, %3\n\t" >> | ^~~ >> >> but with "cc" clobbers it works. > > ... hence there's nothing to report. In fact what an explicit 'cc' > clobber once meant in cc0 backends (that indiscriminated flag "state") is > manufactured by the non-cc0 backends (all of them now) automatically > whenever an asm has no flag output constraints at all. (On x86 that means > it adds the "flags" register (internal name for the collection of flag > status bits) to the clobber set automatically when there are no =@ccXY > constraints). > > You can regard all 'cc' clobbers as pure source compatibility, they have > no meaning anymore. But as they are so ubiquitous (even in our own docu), > they remain recognized. Michael, thanks for the detailed explanation; that's very nice to know. Boris, I guess this may be added as clarification in the commit message. Would you prefer another version with it? Thanks, > > > Ciao, > Michael. -- Mauricio From xen-devel-bounces@lists.xenproject.org Wed Sep 02 13:52:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 13:52:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405958.1639377 (Exim 4.92) (envelope-from ) id 1x1lNt-0003OB-G2; Wed, 02 Sep 2026 13:52:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405958.1639377; Wed, 02 Sep 2026 13:52:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lNt-0003O4-DU; Wed, 02 Sep 2026 13:52:13 +0000 Received: by outflank-mailman (input) for mailman id 1405958; Wed, 02 Sep 2026 13:52:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1lNs-0003Ny-OF for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 13:52:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1lNs-000ZZh-16 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:52:12 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a982a04-8faa-0a2a0a5109dd-0a2a450b989c-26 for ; Wed, 02 Sep 2026 15:52:11 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a982a0b-b7e8-0a2a450b0019-d1558029d104-3 for ; Wed, 02 Sep 2026 15:52:11 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4995b0343c1so11305995e9.3 for ; Wed, 02 Sep 2026 06:52:11 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448ed37c4sm5694464f8f.21.2026.09.02.06.52.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 06:52:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788357131; x=1788961931; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=R/xXvT5t0uTjdWwesbEAdJ3uJsGubB1tB6H8T4RJtRk=; b=gFJ/A3RqLlgaSbo8E/WmBhaYcSkNr2Gk0jWp0NPJeYgfyTPzFOVkcbD+60+o8hNsYn AxBLMA56no4Kql1XsN3od+yfpe6LoO9YGGnmiWSSXvOqRu26vrn6s9OGP+h32XldpK3i xKtVs4c3tYGyE5Nvye/+Kz+36cn33Cd0ODiN/R/fYEPgfr3mIlLquQ0DIZDoi13frSaS XQHlca09HLorQQHMAF/hWd4/JBWqz9zHNbMannalO3hWfuftutSZ8j1qmcoYC7lez4Dj EqlcZGTpKJ1efdcS48Dl6wf33PmRQcNTQj1zitcl59WSLNsgSrUHdVTOT5GXHyZSMTcr 15Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788357131; x=1788961931; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=R/xXvT5t0uTjdWwesbEAdJ3uJsGubB1tB6H8T4RJtRk=; b=ZNnKuAxNONwADIvVeemjOpnG6peC0lR5IstRw82T0ej6jOmzcoUlaJ7ifncJC/My0H FCebC9chUuCYwyIm9bkztmWPdy6nGQe27GRYR4z+xtwc4YwIu+CamTgj0++IUFq4ue/1 FsscZ0nk1lIjLa7N0q7W0a0AaS2jk7dKxb+Pwmp/zK4kQqbF2al/CzinKdK7O8HfKLpq dZt5Z1m0WtR7PLxJ/0vxwJPLCmZ9lQaVJKhjZ3j6vTbmCp5/OuFB7XX5pNZB0uD9Xwpb h4rJ0vYZQIup73IU6rCJth9kfZ41R3SxngXgxceFlWp4D38gvAeyyM3k1TtvuwFmKexL MRXQ== X-Gm-Message-State: AFuF++kDfDRb9p+D5V/P7sCQ7oo8DuiKupDfIlUUl46J2kF5zT6wUOIZ 3+umca5+OKgsgtlynV8By72SteKSxLzynn7PlAUvwNb2lksQKbgL7HBxqnglnQ== X-Gm-Gg: AR+sD12mbPpSpnVfDoooZSmoqBxLIkriJtzXHH3uvcMgeBsFKYl6c7q1Cy1eUH9ZedU G8B1V2y/dH/gyH6fRDaC+dxdsYg24jnEaNtS0u4nbh0Yj91BN6elxn61pa5WaaaxjU828cdIfvD nvZA560gAY2IE0/CeBM2ManJtvLC2UCfLSGBGj6eoab9phzduwc/ZUzfY3xb0hAMzLlaGCQ5RwW U4Y8n5nk/69a00xghTma7nGMzJz4Zg5QPbY2I0qVZciv8iG10lB/3mlW2at5IUsOzz/U7rHMHMn LmRffrpNaq+3M8VikgdsFVHmNMxMj2sFKjaP98P/C+4YS7poAKPyTlOLMIIjozeLlG7itcC/CIe OiKDc3YbNFnsm9U0M+sJnhvAwCrwPTE0QKgbp5fHRsPkz0pV3f2qL03h0CCTwA+aEPY75ozOp0q 6J4Cib0gchU/oKZUKQbdn9IXBOVoReenKTB3Zu9UIpGYuv6/WT1eZWOrMKT/jz7ORLQT3hSWKKz kz6Qn75NGC+v87tJ3W9ahX6b8CgIvr988bO0r5sTw== X-Received: by 2002:a05:600c:3113:b0:49b:924e:9a28 with SMTP id 5b1f17b1804b1-49ce58163aemr75492025e9.1.1788357130735; Wed, 02 Sep 2026 06:52:10 -0700 (PDT) Message-ID: <94a091d5-779d-454e-9ac6-0e565588db9e@gmail.com> Date: Wed, 2 Sep 2026 15:52:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/39] xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <1788276968.8631fc262581453bbf619ec5b2062170.1a05d9d0d1d000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788357131-A98C19EA-9275FA5D/10/73395122804 X-purgate-type: spam X-purgate-size: 1337 On 9/2/26 3:22 PM, Jan Beulich wrote: > On 01.09.2026 17:53, Jan Beulich wrote: >> On 01.09.2026 17:36, Baptiste Le Duc wrote: >>> On Thu, 27 Aug 2026 17:20:51 +0200, Oleksii Kurochko wrote: >>>> These definitions are required for correct decoding of APLIC MMIO >>>> accesses and target configuration, and will be used by both the >>>> physical and virtual APLIC implementations. >>>> >>>> While adding them, rearrange the header in the style of x86's >>>> asm/msr-index.h: a register's offset is immediately followed by the >>>> definitions of that register's fields, with the blocks sorted by >>>> offset. This makes the relation between a register and its fields >>>> obvious from the layout alone, so no comment is needed to express it. >>>> >>>> [...] >>> >>> Reviewed-by: Baptiste Le Duc >> >> Acked-by: Jan Beulich Thanks. >> >> If there's no dependency on earlier patches (nor the prereq series), this >> could go in right away. Yet nothing is being said anywhere, unless I >> overlooked anything. > > Doesn't apply cleanly to current staging, so left out for the time being. Yes, it isn't applied because of: [PATCH v8 12/20] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:16:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:16:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405970.1639386 (Exim 4.92) (envelope-from ) id 1x1llD-0006wQ-7g; Wed, 02 Sep 2026 14:16:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405970.1639386; Wed, 02 Sep 2026 14:16:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1llD-0006wJ-55; Wed, 02 Sep 2026 14:16:19 +0000 Received: by outflank-mailman (input) for mailman id 1405970; Wed, 02 Sep 2026 14:16:17 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1llB-0006wD-SQ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:16:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1llA-00FV6K-Ge for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:16:16 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a982faf-bab6-0a2a0a5309dd-0a2a4505de10-8 for ; Wed, 02 Sep 2026 16:16:16 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a982fb0-4cb1-0a2a45050019-d155802ca4bd-3 for ; Wed, 02 Sep 2026 16:16:16 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49b0eab380eso10478345e9.0 for ; Wed, 02 Sep 2026 07:16:16 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce5533ffbsm43550395e9.3.2026.09.02.07.16.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 07:16:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788358576; x=1788963376; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=lS5Jt5Zsbat0B1Cf88rX8Gj9YZoVhCThztwHEOEzvNQ=; b=Q/vxnN57niTqpvw0oEzrPlAJhlVt2cpT5NBcpBwd/tbEsmM4U5tAbq4aJG3gH1KJTG lifaKa74A5SgwCmk5cY+L7yAEdx1a8lHcYGzVAwwix7hpw63scyejH0ay06DCTbmxGyc cV1p7SEH/+gSPZdZLtWWkpn4+Fj+XmrwZIQUpj31W/gQDVjvyuW1HkkiwTH9TIcPZBOQ idAm+jqLHTWb4S+hmwCvQXm6a+2W7+QuniPuEJ2OSWED13bj38ivn0OVJ6VrEV1Y4RJF /tQHySAooZC3kus+uv57/r5fPdgBRIG4+Qrw8E+YDtYvanDE7xryRL5wC4vqbrPn+sXZ yCpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788358576; x=1788963376; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=lS5Jt5Zsbat0B1Cf88rX8Gj9YZoVhCThztwHEOEzvNQ=; b=HuRHr3Aw/pi0XD2OEZ8txeZE9DZacel6IM2L/v3sExz2+tPyliRhs7gNPkev9qo+7F vMhaAHnUuPps2DI7uRzCBxeYBzlP+a7shM0BlI7TYgNRY8yJH+nnPyjq9QJAj8O8Sv9m WSmB9+VmHqKGJGuvF1A8zWlkerm2b7yQ4JQfo3wvoZ4LWhSXTrcmBIY3PjQSxldzDYUE FhDKzHmkzgThhWL65yllW35vMAQi5v6gCVrv+FMCJCo0WflJ4HmYhR6hUh9VXM5Rb/hY S/wbH9WMANeD2jS7HeA20DzPKZi3PDlxoFvPDcnJYTA38NrwjPwIAL5Ka/wUg2T2NTq8 m4TA== X-Gm-Message-State: AFuF++n2DdbyvFYvGGVWHc6xDk0EKEkJ7UVrsF/bX2U/OU3PA018WMVC VrF4bc0PIj12yzSfScBzjYaMI5Y9Yu6zfTBtO5AmkOISmoveEc07KyKI54Ol1A== X-Gm-Gg: AR+sD13TQoMFmIVkYcPeVzdgbe6SsjnDlhM9KBllTo7Mx61uiHAqwRWnUx3HDmj0paC v81VtxfQRo6HgfquqHvL8aM/GTzHZJ8MrpVrhMpuSDp223jNfDBQK3wdRaiSKGv3mS5fRkGxmsa vBn/7OTbRrsgvmQuJIMz4rpWobDW6MU4IaXw2sO/NUKVqaQ0cF9kk6hTQjK5bi5yugAN8fCVJIl qZKB0cwkMDRRkdqNfTCzlxLv8ofhoT++tQ2lRT3lsarWwKYNBulm7R77t251n5Ip+ZgIqw34vGi D49sjZW5oEVizv2j+L39gx3wNf2b3Le5yfgCGHhav2IYjbkWGbXi9KKB9hYxtJK7X4VaCEEDa7G 5BLGaP6ykCINTys75C0f1HP3gnPDdwqnQMFW00g2+rTMfg7vvMVsspu8Zchrb5QHGLEaReSg708 pswmkXvNNG7zkDDyWmk6QwSH3kB+6M1KruV4m9/YN4z+DmdwqU0187HDe3bSM9KqUkQfZG352fC QF2h7qfQc8OXPpXXQEVgiMdq96Il2sI X-Received: by 2002:a05:600c:3b07:b0:49c:799a:177b with SMTP id 5b1f17b1804b1-49ce7bb7a75mr24872415e9.2.1788358575650; Wed, 02 Sep 2026 07:16:15 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array Date: Wed, 2 Sep 2026 16:16:07 +0200 Message-ID: <20260902141607.24390-1-oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1788358576-F5CA82A1-707DA15F/10/73395122804 X-purgate-type: spam X-purgate-size: 3156 imsic_init() indexes msi[] by the Xen CPU id hartid_to_cpuid() returns, but that array is allocated with one entry per parent IRQ of the IMSIC node, and the only range check compares the index against num_possible_cpus(). Neither matches the array, and the check comes after the first access: - hartid_to_cpuid() returns NR_CPUS when the hart isn't one Xen brought up, and msi[NR_CPUS].base_addr is read before that is noticed; - an IMSIC node listing fewer parents than Xen has CPUs makes every index past nr_parent_irqs go past the end of the allocation, which the num_possible_cpus() check lets through. Size the array by nr_cpu_ids, which is what it is indexed by, and move the range check ahead of the first msi[] access. Fixes: c9bd8b322ecb ("xen/riscv: imsic_init() implementation") Signed-off-by: Oleksii Kurochko --- Changes in v2: - Use nr_cpu_ids instead of num_possible_cpus() to not be dependent on if cpu_possible_map is sparsed or not. --- --- xen/arch/riscv/imsic.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index f7b70a8da09e..44eb7abf76fd 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -326,6 +326,8 @@ int __init imsic_init(const struct dt_device_node *node) unsigned int nr_parent_irqs, index, nr_handlers = 0; paddr_t base_addr; unsigned int nr_mmios; + /* imsic_cfg.msi[] is indexed by Xen CPU id, so size it accordingly. */ + unsigned int nr_msi = nr_cpu_ids; struct imsic_mmios *mmios; struct imsic_msi *msi = NULL; @@ -346,7 +348,7 @@ int __init imsic_init(const struct dt_device_node *node) goto imsic_init_err; } - msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs); + msi = xvzalloc_array(struct imsic_msi, nr_msi); if ( !msi ) { rc = -ENOMEM; @@ -405,7 +407,18 @@ int __init imsic_init(const struct dt_device_node *node) continue; } + /* + * hartid_to_cpuid() returns NR_CPUS for a hart Xen doesn't know, so + * the range has to be checked before msi[] is indexed at all. + */ cpu = hartid_to_cpuid(hartid); + if ( cpu >= nr_msi ) + { + printk(XENLOG_WARNING + "%s: unsupported hart ID=%#lx for parent irq%u\n", + node->name, hartid, i); + continue; + } /* * If .base_addr is not 0, it indicates that the CPU has already been @@ -421,13 +434,6 @@ int __init imsic_init(const struct dt_device_node *node) continue; } - if ( cpu >= num_possible_cpus() ) - { - printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent irq%u\n", - node->name, hartid, i); - continue; - } - /* Find MMIO location of MSI page */ reloff = i * IMSIC_HART_SIZE(imsic_cfg.guest_index_bits); for ( index = 0; index < nr_mmios; index++ ) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:19:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:19:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405976.1639396 (Exim 4.92) (envelope-from ) id 1x1loN-0007ZB-Lc; Wed, 02 Sep 2026 14:19:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405976.1639396; Wed, 02 Sep 2026 14:19:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1loN-0007Z4-Im; Wed, 02 Sep 2026 14:19:35 +0000 Received: by outflank-mailman (input) for mailman id 1405976; Wed, 02 Sep 2026 14:19:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1loL-0007Yy-Ss for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:19:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1loK-007Ty8-RV for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:19:33 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a983073-e002-0a2a0a5209dd-0a2a450bd63e-10 for ; Wed, 02 Sep 2026 16:19:32 +0200 Received: from [198.137.202.136] (helo=mail.zytor.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a983072-b7e8-0a2a450b0019-c689ca88edd8-3 for ; Wed, 02 Sep 2026 16:19:32 +0200 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 682EIqnL3615183 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 2 Sep 2026 07:18:53 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=2026082801 header.d=zytor.com header.i="@zytor.com" header.h="Date:From:To:CC:Subject:In-Reply-To:References" DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 682EIqnL3615183 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026082801; t=1788358734; bh=9+cci75UmAKXSNYbyFNOPFn1zAmcIFOxmoM0RCeSqSw=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=i6t+zDazNQW/PHul8N3EVpOl+Ov5fNuUkBVtoSR96j4zTguKq+uvxrLMleTcAGviV 3Mtu+gx5FV9r4Arst1+QPkPDetNgvsmYxLWSxtCNdND7H7i4l4TN8AbEVPdHHvwWT9 C83QjPihUd+f+E4Aazn/xY1ByIB5tHu6SwqqYDUy4PwsYog4+PEE1hp99z1s/4uqRd 8PCWy8im7IQZbugf0CQXdn9qdoSi5XV+lT6rsstlfcHgOOmKE4J4jHuXCVDGRZ6GWj 2MzmIbyciLU6ilAXSQ/ZqZDfHKSxtge7HiWQ/3m1dbrBOntoRybH212bSXMjouFGJv r9tXB1rf68wdg== Date: Wed, 02 Sep 2026 07:18:47 -0700 From: "H. Peter Anvin" To: David Laight , Jan Beulich CC: Mauricio Faria de Oliveira , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Brian Gerst Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() User-Agent: K-9 Mail for Android In-Reply-To: <20260902093354.582c2f07@pumpkin> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <16110ecc-fc0d-4b9d-a958-2a75ca60b69f@suse.com> <20260902093354.582c2f07@pumpkin> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1788358772-ABED69EA-FAF552FE/0/0 X-purgate-type: clean X-purgate-size: 2751 On September 2, 2026 1:33:54 AM PDT, David Laight wrote: >On Tue, 1 Sep 2026 15:16:58 +0200 >Jan Beulich wrote: > >> On 22=2E08=2E2026 20:33, Mauricio Faria de Oliveira wrote: >> > According to the GCC documentation, conditions in the flags register >> > (e=2Eg=2E, "=3D@ccnz") are output operands [1] and the compiler is aw= are [2]=2E >> >=20 >> > Also, clobbers (e=2Eg=2E, "cc") may not overlap with an output operan= d [2]=2E >> >=20 >> > Thus, remove the "cc" clobber as it is redudant, and overlaps with, t= he >> > "=3D@ccnz" output operand=2E >> >=20 >> > """ >> > 6=2E11=2E2=2E4 Flag Output Operands >> >=20 >> > On some targets, a special form of output operand exists by w= hich >> > conditions in the flags register may be outputs of the asm=2E= [=2E=2E=2E] >> >=20 >> > 6=2E11=2E2=2E6 Clobbers and Scratch Registers >> >=20 >> > While the compiler is aware of changes to entries listed in t= he >> > output operands, [=2E=2E=2E] >> >=20 >> > Clobber descriptions may not in any way overlap with an input= or >> > output operand=2E [=2E=2E=2E] >> > """ >> >=20 >> > Reported-by: "H=2E Peter Anvin" >> > Link: https://lore=2Ekernel=2Eorg/all/5e19b195-0ca2-4510-81cb-497b40e= 4aaf5@zytor=2Ecom/ >> > Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-lengt= h test in memcmp()") >> > Signed-off-by: Mauricio Faria de Oliveira >> > Link: https://gcc=2Egnu=2Eorg/onlinedocs/gcc/Extended-Asm=2Ehtml#Flag= -Output-Operands [1] >> > Link: https://gcc=2Egnu=2Eorg/onlinedocs/gcc/Extended-Asm=2Ehtml#Clob= bers-and-Scratch-Registers-1 [2] =20 >>=20 >> Reviewed-by: Jan Beulich >>=20 >> > --- a/arch/x86/boot/string=2Ec >> > +++ b/arch/x86/boot/string=2Ec >> > @@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t l= en) >> > asm volatile("test %3, %3\n\t" >> > "repe cmpsb" >> > : "=3D@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) >> > - : : "cc", "memory"); >> > + : : "memory"); =20 >>=20 >> In fact I'm using a modified gcc which properly rejects such conflictin= g >> uses of output and clobber=2E ("cc" clobbers are redundant on x86 anywa= y=2E) > >And, if "cc" clobber wasn't redundant, you'd need clobbers for the cc fla= gs >that weren't being used as output values=2E > >David > >>=20 >> Jan >>=20 > No=2E The condition codes aren't orthogonal like that=2E There is only one= flags register=2E=20 (On x86 I believe asm statements are assumed to clobber the flags uncondit= ionally, because it is so common=2E) From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:20:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:20:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1405982.1639406 (Exim 4.92) (envelope-from ) id 1x1lpJ-0000Ys-Vn; Wed, 02 Sep 2026 14:20:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1405982.1639406; Wed, 02 Sep 2026 14:20:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lpJ-0000Yf-Qj; Wed, 02 Sep 2026 14:20:33 +0000 Received: by outflank-mailman (input) for mailman id 1405982; Wed, 02 Sep 2026 14:20:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lpI-0000YX-21 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:20:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1lpH-00BlOF-Ev for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:20:31 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9830ab-bab6-0a2a0a5309dd-0a2a4509bd38-32 for ; Wed, 02 Sep 2026 16:20:31 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9830af-be1a-0a2a45090019-d155dd35f13d-3 for ; Wed, 02 Sep 2026 16:20:31 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-482dd6ee390so1122069f8f.3 for ; Wed, 02 Sep 2026 07:20:31 -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 ffacd0b85a97d-484492ce236sm7656029f8f.35.2026.09.02.07.20.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 07:20:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788358831; x=1788963631; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Cnu+UhoY+TS0Wa2oSi2rdmrxyRsoa3I4M2hLDEA1cAU=; b=LuDeVItOLfgLOWcmguuDKVzKhr0cmLg955/GcsLTDuXTenD9L/JSM5mIvLghfTdcEe fLdjk/kOUQ1qNL3B03BDEDMSo9EzHIdsC1ezPQzgRH+IPQaMWuCo4ypE4jfyQea/1XjH QqkXPBfBBvEO+55omiWYFL7D/p0O/YN0qMvEG1ijrcWtNd3UoTZfHT5wPHk4Ryp49Y+1 X5DkdtUhi0gXYukZCC+MDglwZAJZQ3lKAcoaDBZnM4A0wzF1Ektyl9s+d8/26pzQxuka OZ2qgKOuLM8yp/l6go1h01HDsww7w9cE3+8J9OPkWLrJ7jxp6n7be3SuYVweJLdItHPD 9Gyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788358831; x=1788963631; h=content-transfer-encoding:content-type: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:content-type; bh=Cnu+UhoY+TS0Wa2oSi2rdmrxyRsoa3I4M2hLDEA1cAU=; b=GzkwfqwkYcIDn+Enlkhueo4+bVnP2BwELrzKH094dX8PnD/R7KDasIFCNgCBWBNDmf T7ItEsZq5nSG80tunirDd4UlZcZ1rCTundaXu9Ug4mJ/nR06ntsGKJ/Yl4z08OE+hRo1 auw+DwyjLg0v2syQ/lK8/+iPWCvGTjGxz6JjoFJVm/r/zOqXMVjIsmcQtmv6zsqDE6vo GsTytS0sIKkxRaa/Cw/yGfdbG4bxlJeQUMPkqojcXISSNxKqWsdUSUqfZKjX/Eb6ZeAR /RxtloBxfXV6SpBctT7sdyPpTRNisak1rRFh7VgnqBku+9lsLXRreEHNyJFagXDUnLZa 0ZWg== X-Gm-Message-State: AFuF++kadkrJQ8n9hVbAq/Ubp0ISY+/5y4fdeXV7NgdeFvwHwWcVZ3hW K1qO2PnUk3ZdCOZzmlXwH5q+/hb7ByR1JC2etGoU0Opl12kRR5kTh0aFPq0oygQgw8wEA6c23Vi CEDvrGQ== X-Gm-Gg: AYBFou0tjxQA2V0Msha6ivFzeM0PA40OknbwH2UFAL+0u3EnJqTFdF18Sd8M1YSA4GT oe32YpAKkramDE/gMQrMDVvMSDJihFlkXXR8cqoFqQZEJefJNWArDEzc9v/ErnpoD0gCu2OicGZ FWaCAfJ40MiQbkfNnuXU1nSL26fpnSW5sK3tlT1dqmRfoO48Bwsexpl4gnaUmNMzFFCzT1mvgTc o2/KZ7P4D9/XS0OXEdOk4dqL81z5hAIVpNXPVPzQRCppo1/d8mD66VlAA51acACH9fzfcvtpZD6 RRfldrkEXDZ4ORT3G8cA41ZPRSyZ6Sc98inFQve72//MmCDoLUEWx7TNL02JIpfQTR6oF8M7pc9 pOcCBNOyXrBVRm3eSSLedUTz1peLsJbhF57lgvgJO6/ey83/MPOEYog87W7m0rnvnPDIq+6OfFS ivkJ99lCiMJIvai2h3sFLkMIW3pafFbdOOa3OmYHZO3HwLjaO0i/pWp4rTIHxOUs6fpMOoJKxRO tlM4nw3dUhcXcOr3Q1sCxSMzKkWzKdeOGmLqs0vXoNh0Ftrav7vGmWG+8+LbNk= X-Received: by 2002:a5d:5985:0:b0:484:40f5:da6a with SMTP id ffacd0b85a97d-48488f103ccmr10742556f8f.15.1788358830737; Wed, 02 Sep 2026 07:20:30 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 16:20:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] x86/time: avoid early uses of NOW() to return zero To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: 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: 8bit X-purgate-ID: tlsNG-bad1c0/1788358831-BD8C1034-B927236F/0/0 X-purgate-type: clean X-purgate-size: 817 On 02.09.2026 09:54, Roger Pau Monné wrote: > On Wed, Aug 19, 2026 at 01:45:56PM +0200, Jan Beulich wrote: >> I don't think Fixes: tags should be put here. If we did, we'd have to >> enumerate all introductions of early uses of NOW() (or get_s_time()), with >> the exception of those dealing with getting back 0 (which I expect is only >> printk_start_of_line()). Will want backporting nevertheless (unless deemed >> too risky). > > I agree with backporting, current behavior of getting stuck in an > infinite loop is worse than timing out earlier than expected (which is > the worse outcome of this patch). Question is how to find a good balance between pulling in prereqs (there are quite a few, I think) vs sacrificing some functionality. Or whether to make it an all-or-nothing decision. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:27:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:27:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406001.1639437 (Exim 4.92) (envelope-from ) id 1x1lvg-0001PX-Te; Wed, 02 Sep 2026 14:27:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406001.1639437; Wed, 02 Sep 2026 14:27:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lvg-0001PQ-Qg; Wed, 02 Sep 2026 14:27:08 +0000 Received: by outflank-mailman (input) for mailman id 1406001; Wed, 02 Sep 2026 14:27:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lvf-0001PK-Dd for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:27:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1lve-00BmMc-AU for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:27:06 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a983235-bab6-0a2a0a5309dd-0a2a45039bb4-10 for ; Wed, 02 Sep 2026 16:27:06 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a983239-fae8-0a2a45030019-d155dd2aed71-3 for ; Wed, 02 Sep 2026 16:27:06 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-47ddf7b09e5so1110275f8f.1 for ; Wed, 02 Sep 2026 07:27:06 -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-49cee08e0dcsm3125585e9.5.2026.09.02.07.27.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 07:27:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788359225; x=1788964025; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=2uUZg+nGoOHw5M9J4hVqatta8vcUweqR+Ea7r4gWW5U=; b=O1Zc1TFNcw1UC4emTY8VmzyK7eEobJYqMhOVVa+nvoMoS5KAOgIoXoRhn/5L1YSSnD eEqu46h3mZp5akIItEAVpul3eB9b7zVMv1vrkEtfFIFhUfp8YVvXEscPpqAK4hOF4shR wb+S/c2TO3mNbtG4jal2jcRn5di91odXqrKfvFSOXjIEO6d3F1jzgUqfWLPN2tfX8ZrR rnRNN7ol7KUyiiGHbBdOlJbBockaMpYPjsypK+Xo56EhqkMNjH8/JLhGbJS4cDgQcU3H snVQvrEl1sIdiMcNT2HX8Hdx0i8AcJPFPGc6fGzMbl57K0h7aacmrE3fO5VlRUv2kAHb LsSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788359225; x=1788964025; h=content-transfer-encoding:content-type: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:content-type; bh=2uUZg+nGoOHw5M9J4hVqatta8vcUweqR+Ea7r4gWW5U=; b=mKjIvicM+epntkQmDKx5ulFdpFjyKOL8KoEYBkdqY5ulXGvQ1LOfBHCq+sAJAKF0l6 FEmsH5ydbXd17EbrFErDEPJl0xiADpk9kclz2ScjCJBSKJJ32p3qtgBRc99d0JAfzemS CE8uNYjiLADHHJhKpdIKhe0SMtYmxGYudUAkZKsXhLzIAbhjkRNFl1NwI85uXTB16ttS V+e2pgXm4wBqf6MtftfRjxQm1ngp5s61SgRWGmeKko/2QCawRKZ/b84YhCCfZE3IuOLT EuEfUJOCMExptzFs9hHPZMVu9OeSkzVs+p1cFOmohx5pZd1dTtU6fKZOx8vSk/DvP54K Lx+w== X-Forwarded-Encrypted: i=1; AHgh+RolZgtm3TSb8By/Q0DcxXdSatRvi0LQKNC6aaze0d2ImU3LkN68eym3PJJa7s9UqEniraZCPTIAyjE=@lists.xenproject.org X-Gm-Message-State: AFuF++lX1MTdoDhltOv8Wm6pJAKxtf1inGq2eZs44eeYJa+VtBJ79ReF nKqlUXvF+r7lVXPPyqFsmyrDlJ4VkT/uUO1c5SKkimjoxlONO2BpuuLGk1I/nRAguQ== X-Gm-Gg: AR+sD13PncCTBQCOJVr9bMhwN91Sr4tex13fvpEgYFzRnPTNmRPj2N67S6MU9yVSox/ Eu4hybelDBYKGkpJsLbWIGgXzYlbglDa2bCnpdnYt3OJTuGh/RTCafvDLcbuBh6uWbIhewRdEd8 2wc0FIhx7+khaxZIa388Ejc4YjZpMRV9LngR/t/1+naznGQ9NpgHKuZFmYvc+vyMA4XMEuuo6bM OrL/u32K0TUywlJH/5ds2ZpRG5keTGZVXSFV1thI0qVtyeyW+hEQqnF8jrWlxqQXXQKGX5uWxWK XBHqz6SNdJeuIytzeB19TO8ZjvHvdfd/CQLO3vIcev36GKiro5KLuOM+BpFKwmkdT5OY/32quEd ajQYNH2uIBIT2vDTnh8ygxwXE7UrTBlQbug8QiQ/pRnhsfQvK1ZH1gPJVEZIlaTEU8F/3WrHGeu cha8LnkzZvogMfXmykrfYT8d4I9J+bpvYnkLCQglTbDaDbLepmlfVoetcbZnXIXLMHDEYUeQOkj rd3ep8usd7jBaqnTdv2+3XhPo2R0t/lrCZ1mLz/hJBXMl1J902Q X-Received: by 2002:a05:600c:c170:b0:49b:d45:703e with SMTP id 5b1f17b1804b1-49ce57f072fmr117230545e9.8.1788359225436; Wed, 02 Sep 2026 07:27:05 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 16:27:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/39] xen/riscv: drop bug.h's duplicate instruction length helpers To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.com> <5d8888f1-d6f6-4f73-812b-8a79edceed95@gmail.com> <3b07e1c6-eee0-4b54-8bd5-fce8db4ef726@suse.com> <21e80092-5abf-427d-87d8-cdbe58874a10@gmail.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: <21e80092-5abf-427d-87d8-cdbe58874a10@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788359226-74A894E9-89DDC8B3/0/0 X-purgate-type: clean X-purgate-size: 3642 On 02.09.2026 15:45, Oleksii Kurochko wrote: > On 9/2/26 3:02 PM, Jan Beulich wrote: >> On 02.09.2026 12:48, Oleksii Kurochko wrote: >>> On 9/1/26 9:01 AM, Jan Beulich wrote: >>>> And then >>>> >>>> #define INSN_16BIT_MASK 0x3 >>>> #define INSN_32BIT_MASK 0x1c >>>> >>>> are really named backwards, seeing e.g. their use in >>> >>> It was derived from OpenSBI project and I haven't paid enough attention >>> for these defines. >>> >>> Now looking at them again I fully agree that names here not really >>> correct. It should be according to the spec: >>> #define INSN_32BIT_MASK 0x3 >>> #define INSN_48BIT_MASK 0x1c >> >> Especially the latter would then still be misnamed, as the mask merely >> identifies insns >= 48 bits. Even for the former I'd still question the >> name to some degree ("mask" doesn't mean all of the bits need to be set). >> >> In how many places are you going to need these constants? If, by suitably >> using helpers, it's just one - maybe better to get away without any named >> constants in this case (i.e. when suitable names are apparently difficult >> to come up with)? > > INSN_16BIT_MASK - will be used only once (except INSN_IS_32BIT() and > INSN_IS_16BIT()) in insn_fetch_faulted() introduced later in this patch > series: > di->insn = htinst | INSN_16BIT_MASK; > > INSN_32BIT_MASK - is used only inside INSN_IS_32BIT(). > > And INSN_IS_32BIT() and INSN_IS_16BIT() are using in several places. > > I am okay to drop these masks and then just have a comment: > > /* > * Instruction length encoding helpers (see RISC-V Unprivileged ISA, > * Section "Base Instruction-Length Encoding"). > * > * - Instructions with bits [1:0] != 11 are 16-bit (compressed). > * - Instructions with bits [1:0] == 11 and bits [4:2] != 111 are 32-bit. > */ > #define INSN_IS_16BIT(insn) (((insn) & 0x3) != 0x3) > #define INSN_IS_32BIT(insn) (((insn) & 0x3) == 0x3 && ((insn) & > 0x1c) != 0x1c) Largely okay; I'd still prefer #define INSN_IS_16BIT(insn) (((insn) & 3) != 3) #define INSN_IS_32BIT(insn) (!INSN_IS_16BIT(insn) && ((insn) & 0x1c) != 0x1c) > As an option we could come up with the following names: > > /* Bitmasks for instruction length encoding fields */ > #define INSN_LEN_1_0_MASK 0x3 /* Bits [1:0] for 16-bit vs > >=32-bit */ > #define INSN_LEN_4_2_MASK 0x1c /* Bits [4:2] for 32-bit vs > >=48-bit */ > > #define INSN_IS_16BIT(insn) (((insn) & INSN_LEN_1_0_MASK) != > INSN_LEN_1_0_MASK) > #define INSN_IS_32BIT(insn) \ > (((insn) & INSN_LEN_1_0_MASK) == INSN_LEN_1_0_MASK && \ > ((insn) & INSN_LEN_4_2_MASK) != INSN_LEN_4_2_MASK) > > But it seems the first option still looks better. > > Would you also prefer Option 1? I do, yes. >>> I think that for now it is enough to go without common implmenntation of >>> INSN_LEN and just return 0 as suggested above. >> >> Suitably commented upon that would certainly be okay with me. > > The the following comment looks good enough for me: > > /* > * Length in bytes of the instruction whose first parcel is @insn: 2 or > 4, or > * 0 when the encoding is 48 bits or wider. No ratified extension > defines an > * instruction of such a length, so rather than open-coding a decoder for > * encodings which cannot legitimately occur, leave it to the caller to > treat > * the 0 as an illegal instruction. > */ > #define INSN_LEN(insn) \ > (INSN_IS_16BIT(insn) ? 2 : (INSN_IS_32BIT(insn) ? 4 : 0)) Reads okay, thanks. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:31:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:31:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406008.1639447 (Exim 4.92) (envelope-from ) id 1x1lzd-00036G-BV; Wed, 02 Sep 2026 14:31:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406008.1639447; Wed, 02 Sep 2026 14:31:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lzd-000369-8L; Wed, 02 Sep 2026 14:31:13 +0000 Received: by outflank-mailman (input) for mailman id 1406008; Wed, 02 Sep 2026 14:31:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1lzb-000363-Rq for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:31:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1lzb-003DBV-4T for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:31:11 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a983316-8faa-0a2a0a5109dd-0a2a4506b3ee-48 for ; Wed, 02 Sep 2026 16:31:10 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98332e-195a-0a2a45060019-d1558029d9fd-3 for ; Wed, 02 Sep 2026 16:31:10 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49b96837ca3so7814035e9.3 for ; Wed, 02 Sep 2026 07:31:10 -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 ffacd0b85a97d-48448eeae34sm7061120f8f.32.2026.09.02.07.31.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 07:31:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788359470; x=1788964270; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=gNzFIavnz0vpng0Fh09bkIGFXdQ2PuAzOQRjwuIM5R0=; b=HMzoVXpaHxACbM8bBzpoZmGCoyek1Kn8eiPTO4HFusgoysdoRmp5Hzwo/Mzh6JJh4S iNehEJSswyHRkwSHoivZI2nxvngXRgrAenN4rrF4P6cnl48911PGWRZopnA/Eho39DEB OWXQ/97HHglkmYfKFRhw8AbeOJ0zU3hjYjXBlnsLh7mauHX1WJH/r4L/yOC0RKG8oQ7P 6c5B8CELEsM3dcSun2FOAuoAvygC6n1ID76wRJqN/3be9IGSJ9pfLSGykgCK/MUKSl0D w5EykH5EpkSIVqj2PCsRwjA9In6HhmEwFhw9Bg2EMRymMrWI6SibtYoZ/DNSSbLUdxRR FZ4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788359470; x=1788964270; h=content-transfer-encoding:content-type: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:content-type; bh=gNzFIavnz0vpng0Fh09bkIGFXdQ2PuAzOQRjwuIM5R0=; b=Vbwo2vO8xPjd0t3kCTpM25vYpb3qOz/k7qPTZtfMSzL2ebY7OBlDMriCiLqyoHKuUR Y99Ids5cFbfcytm0jt41TkXwbdgR5/jIh1PfSmQXdrpDVt/0uTbEOrVdl4wdUe/pmi1p SaeHTehaoHipuzIUsZQVi/ZfIBvEWebQ/QjFhE3i021jYA4iloaq6s30Zx7xOKk/pDja E75CWi8ZokbakzLkWfFF5TnGrT97pzOjlZjjlMLsvlNfNxho/cPv+I+fmjUvMRR7XmB7 5Q19oC0pE6fcNlfR591JDdobABkByzXg5nY26bv7VtUuUXqXf6zQgG6DvPLh3N90pqN0 +Erw== X-Forwarded-Encrypted: i=1; AHgh+RrzEvVPAGTbG4RhPKOpegjJo/PK03myucKGGEgGYC9ykznwSq+EaScE4kjpt3Le3oG7hlGoFZJXKfU=@lists.xenproject.org X-Gm-Message-State: AFuF++nbQdD2NmMOfaayIa83jthD3yFPBawMnl+1iSomA885EZvd8nC2 CKEHnitFiTxWIa1dvxqr/2dMLp9xtX0TimH51PBhJ+zlTgeQnsHeO9ORAHTxqMup4A== X-Gm-Gg: AR+sD10DyPJeElKaaxXZJHxz5os7hQORMoCONU09ywYGpVt3iYs4LrUB3/8nY83bOcu KT+RrQqtBsUQGSJgavjw4FHQyYeGve1Io8n2bJGUddai0wj5OJr99H+HQf6oo4t5MzE2t0Gycix kN5CSzQee2/Yupp+AlppwYVlv69LTuq+8akrVU6kz+CMm2uXQ2ewe9j1ELhyCpibstcUuq4DZTL /OXDtFph/YJokuiuljFHuJkm8eadDZcnH+d0CUVrEeZhTgsSBBXElb312SNm/+H8PPgzaP4jUsE dsHGuURpi16FCFb+s4t91OterYeG3WzsxJ0zBFkxO4XPh+joOflodt+whiWRRHfVBGlKMemDO3T 8A9f/Nq2m1iq44EPLtyZXdF3bA7mbbrI6NIoLlPy78L9gevSFZ36Mzsjqz/e/gDC1hNNvukt9ib 1A/lAiug2MQsgz7wYPf7WjF426hZLklcJY295s7lWqh/qPXDNWGsgye8sZsCGBDS1w9NDbj6OF2 9IvFcwtPFSoh4ezF4M99vxoF7hd6g6GMMuBtI10ByPk96r4UHA2 X-Received: by 2002:a05:600c:4f42:b0:49c:dada:f581 with SMTP id 5b1f17b1804b1-49ce558e89amr95454445e9.0.1788359470043; Wed, 02 Sep 2026 07:31:10 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 16:31:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> <127e8aea-4d65-492e-8bda-bffc75f02481@gmail.com> <071c5b4f-1d57-4223-94bd-9f8ae8d80366@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 X-purgate-ID: tlsNG-16d1c6/1788359470-F74C977B-61D0061D/0/0 X-purgate-type: clean X-purgate-size: 1982 On 02.09.2026 15:29, Oleksii Kurochko wrote: > On 9/2/26 3:07 PM, Jan Beulich wrote: >> On 02.09.2026 13:42, Oleksii Kurochko wrote: >>> It will also affect then common code as vcpu_csr_init() could be then >>> called before domain type is set: >>> >>> +++ b/xen/common/device-tree/dom0less-build.c >>> @@ -812,17 +812,18 @@ static int __init construct_domU(struct >>> kernel_info *kinfo, >>> else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) >>> kinfo->dom0less_feature = DOM0LESS_ENHANCED_NO_XS; >>> >>> - if ( vcpu_create(d, 0) == NULL ) >>> - return -ENOMEM; >>> - >>> d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; >>> >>> rc = kernel_probe(kinfo, node); >>> if ( rc < 0 ) >>> return rc; >>> >>> + /* The domain type needs to be known before the first vCPU is >>> created. */ >>> set_domain_type(d, kinfo); >>> >>> + if ( vcpu_create(d, 0) == NULL ) >>> + return -ENOMEM; >> >> I don't understand the need for this, likely because I don't see why >> domain_vsxl() would need calling from underneath vcpu_create(). > > The call trace will be the following: > vcpu_create() -> arch_vcpu_create() -> vcpu_csr_init() -> > domain_vsxldomain_vsxl() > > unsigned int vsxl = domain_vsxl(v->domain); > > ... > > vcpu_guest_cpu_user_regs(v)->hstatus = > HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(vsxl, HSTATUS_VSXL); > > Without moving vcpu_create(d, 0) after set_domain_type(), domain_vsxl() > will return something wrong. Question is - do you need to set ->hstatus this early? > I also thought about updating of VSXL for each vCPU in > construct_domain() where d->type is already known and then no changes in > common code are needed. But I think it is a little bit better just have > a change in common code. If the maintainers accept that change, it certainly may end up being easier. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:43:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:43:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406018.1639457 (Exim 4.92) (envelope-from ) id 1x1mB8-0004y4-BT; Wed, 02 Sep 2026 14:43:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406018.1639457; Wed, 02 Sep 2026 14:43:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mB8-0004xx-6i; Wed, 02 Sep 2026 14:43:06 +0000 Received: by outflank-mailman (input) for mailman id 1406018; Wed, 02 Sep 2026 14:43:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1mB6-0004xo-UN for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:43:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1mB5-00H12L-3i for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:43:03 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9835e5-2eae-0a2a0a5409dd-0a2a4508a2e8-32 for ; Wed, 02 Sep 2026 16:43:03 +0200 Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9835f6-f659-0a2a45080019-d155da2fec95-3 for ; Wed, 02 Sep 2026 16:43:03 +0200 Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-c25b661d37dso173330766b.0 for ; Wed, 02 Sep 2026 07:43:03 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c25cffc5cd9sm152327366b.6.2026.09.02.07.43.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 07:43:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788360182; x=1788964982; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=AnS0O81H1ol9JvrVgUlqr/z68wE3I+O0ZA3sQWlSm+Y=; b=dfRcensXg180Hdcxt3zA1O5l+MY2QpU3/0Z6DqJUr6Pf5Oyg1sGzUp0wXUfaeonJiv swZ+ze0Ed97GnvXVk71VyaisEa9wB8XHGmgybMdUb7w/HtWpbcHKOryjIvn1FW0fAzWe g3rXlXRPx9H4UboRTXuimnWo99jFSCMFLKlcr5zmBo2HyKFlRfAaahha8qwqUy3YXwPj ncg258rQT3NiTuqBJ/QS1vNTQUhT3s14mMpF2K3b3eUHVOp8Oht7uCZY+aOzNqy130Rv 3et9PGdcdnGUa27+zaBOk/rwkG4KjA3Q0dAQ9Mt7rScJ11l5nEVKJSIhMUUPoirunhfI 2b0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788360182; x=1788964982; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=AnS0O81H1ol9JvrVgUlqr/z68wE3I+O0ZA3sQWlSm+Y=; b=E655d6WAFkh8sN1aecC2HgC+zeBCv0fJnQPR4T/Zc6H9jcPueRuclNu1zmBDvFJfDa Wft+MBloepkDtdw1lH9QwKXv5OmSRGsKktZhTR57MjuWSye0T5O9vLpyzes8PbQe2+zQ cVVVVOWjXamr7MUA64gGq088Yl96k12AbrRz3AogbOpHQc7jxtBhmfoTUVNgPjoerL4n GYxk10GBWn7c2ULNctWMhbB9pN+Y5vm/0fsTVca+mjz1b1vh0XE5nxpSnHCy3EAuA3zv VjdUA/dMy6W3pmwCJVacj8wR4BEh4G6DZegM5DPwJcYSBZiAbqkTZbiJK4vCrsnuul0W 119w== X-Gm-Message-State: AFuF++mYB3TkRQtoTDUDeKfTvsI4eKDIaIcgx/nhIjhZr96BzUvuv1aZ 5bmYdd4Ka7/htF06AtRD96gle+/s1rTuVIYwB8NnFwJSRFICR0S9uepoXexFVg== X-Gm-Gg: AYBFou0yMdxL1VQIpewhi1vcJ8oUOfivjcqxajdwLHwM1YIazgJ/1wSnJtWlgrR/YKK CMXPZ5oF3JUegPI2hrkoi3bfHKUAWPqnR2Nj5qa93zxPN30zc55Xhq1q6u1UgWBY97Jmo275zK5 tStxbnAXU+c81yimK10NKvitZtt0CjsdBvcOPFOe1j+xElAfXopbY20aEa1GTijZZEyrCsWGnZt cdjulDAyEjxBBytlmuJIB65RKCri9LNb723avp+ykc/IhaY/JU7jci6/ZTcyU+QdZe9NU/jNgIh j8SNxsRsaTZLgVvezzHkpNJuyx51caoByeRyy9NYxtwHKHYRKBcgky8G+S79jgj6aAP2YUJy5Fh se5hU/xNUqgCqt3GuU/pJ5UmOvpn6XVhv8JraS5lYcwzjpY3RMF8Fc6kNpqAflK1HBAH4c3qBw7 sSv4Lh+I7mDh7xN4f5NuSlzaBR5XyoWzr+Wr2xTuZnaFgDjoGLY6izifG5FaqIAwwPmS6LRw4hJ /NI/CY4MalNNLxlIKEWAK9aDYsgx0oFS03JX+d0MA== X-Received: by 2002:a17:906:6a05:b0:c16:6a42:c7d6 with SMTP id a640c23a62f3a-c25d52b8474mr393398466b.9.1788360182507; Wed, 02 Sep 2026 07:43:02 -0700 (PDT) Message-ID: <1fb1593e-b192-40ad-878c-6e53d44066f5@gmail.com> Date: Wed, 2 Sep 2026 16:42:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788360183-CC57487B-69C26CBF/10/73395122804 X-purgate-type: spam X-purgate-size: 3580 On 8/27/26 5:20 PM, Oleksii Kurochko wrote: > } > > +static void save_csr_regs(struct vcpu *vcpu) > +{ > + /* > + * There is no need to save these CSRs as only hypervisor writes them in > + * restore_csr_regs() and guest can't access them so they shouldn't be > + * stored here. Keep them commented here just for symmetry with the > + * restore CSRs register part. > + * > + * vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); > + * vcpu->arch.hideleg = csr_read(CSR_HIDELEG); > + * vcpu->arch.henvcfg = csr_read64(CSR_HENVCFG); > + * vcpu->arch.hcounteren = csr_read(CSR_HCOUNTEREN); > + * vcpu->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); > + * > + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + * vcpu->arch.hstateen0 = csr_read(CSR_HSTATEEN0); > + */ > + > + vcpu->arch.hvip = csr_read(CSR_HVIP); > + > + vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS); > + vcpu->arch.vsie = csr_read(CSR_VSIE); It should be heere csr_read64() (accidentally this changed moved to the next patch). > + vcpu->arch.vstvec = csr_read(CSR_VSTVEC); > + vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH); > + vcpu->arch.vscause = csr_read(CSR_VSCAUSE); > + vcpu->arch.vstval = csr_read(CSR_VSTVAL); > + vcpu->arch.vsepc = csr_read(CSR_VSEPC); > +} > + > +static void restore_csr_regs(struct vcpu *vcpu) > +{ > + csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); > + csr_write(CSR_HIDELEG, vcpu->arch.hideleg); > + csr_write(CSR_HVIP, vcpu->arch.hvip); > + csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); > + csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); > + csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); > + > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); > + > + csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); > + csr_write(CSR_VSIE, vcpu->arch.vsie); It should be heere csr_write64() (accidentally this changed moved to the next patch). > + csr_write(CSR_VSTVEC, vcpu->arch.vstvec); > + csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); > + csr_write(CSR_VSCAUSE, vcpu->arch.vscause); > + csr_write(CSR_VSTVAL, vcpu->arch.vstval); > + csr_write(CSR_VSEPC, vcpu->arch.vsepc); > +} > + [...] > diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h > index 15e8fa19685e..90ed584bb844 100644 > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -29,6 +29,12 @@ struct arch_vcpu_io { > struct arch_vcpu { > struct vcpu_vmid vmid; > > + /* > + * The last CPU this vCPU ran on. Initialised to NR_CPUS > + * (never ran). > + */ > + unsigned int last_cpu; > + > /* > * Callee saved registers for Xen's state used to switch from > * prev's stack to the next's stack during context switch. > @@ -60,11 +66,19 @@ struct arch_vcpu { > register_t hcounteren; > register_t hedeleg; > register_t hideleg; > - register_t henvcfg; > + uint64_t henvcfg; > register_t hstateen0; > + uint64_t htimedelta; > register_t hvip; > > register_t vsatp; > + register_t vscause; > + register_t vsepc; > + register_t vsie; It should be uint64_t. > + register_t vsscratch; > + register_t vsstatus; > + register_t vstval; > + register_t vstvec; > Sorry for inconvenience. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:50:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:50:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406028.1639466 (Exim 4.92) (envelope-from ) id 1x1mHt-0006XN-4u; Wed, 02 Sep 2026 14:50:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406028.1639466; Wed, 02 Sep 2026 14:50:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mHt-0006We-05; Wed, 02 Sep 2026 14:50:05 +0000 Received: by outflank-mailman (input) for mailman id 1406028; Wed, 02 Sep 2026 14:50:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mHr-00065A-IJ for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:50:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1mHq-004WNh-CV for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:50:02 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a983797-e002-0a2a0a5209dd-0a2a450adfc6-10 for ; Wed, 02 Sep 2026 16:50:02 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98379a-f2d2-0a2a450a0019-d155dd34a9aa-3 for ; Wed, 02 Sep 2026 16:50:02 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48442ea8f59so1454590f8f.1 for ; Wed, 02 Sep 2026 07:50:02 -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-49cdce171c3sm167141915e9.8.2026.09.02.07.50.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 07:50:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788360601; x=1788965401; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=mrMrp2/0XgtFxWE8yBRtd1gRIBgJgvHlEFcT9A/imFM=; b=OxZfRhbe4ZHf4FodCLo/vbeL12D0gqbRct8nXu5H/WIkUlG58MKQBfJ0Hdg9IoiMXo DqAj90DtNd9lUmGrwCr0TtEzC71u3keY9OcNnZZ4u5nV1RPW0cuHRIaHXrteCa9+1XF9 6dNr55WS+L+I52PCT8UctARIz4wicdz42EhF2MwoibOKBlO5RdCtcdLQ8QQUEl5/dDsD jLzYw/sqdaYHQn4Liri7fCylJUDuX2+32Nppd9L7EujWLj0HayNaUn4iN5GFjJlLBPg0 c3fKSpschii0HPgDrykL4/xhkPqPQRglBVMTJZlSBMaPIJo6xaYZwJSVLngzep3frLYp xQ7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788360601; x=1788965401; h=content-transfer-encoding:content-type: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:content-type; bh=mrMrp2/0XgtFxWE8yBRtd1gRIBgJgvHlEFcT9A/imFM=; b=LTqtVlqrMVYP3LcxUFo+5+F/NGECl9JPdEFZk9MNcd8jtGw5KUV/hYChn6M3EhXF06 sty0mndx3Udrclh49tlSnjmHfLxZ7w4y7lMpkhqa5zxy12ZCD4lB0dCUUCtDILvWOxYI +KU97U68iRhT8ZWVhuXa9ZogWyJGKnYXpqBAfV8O72pbkCwBi6kohU31wfA7qcuhx/u7 WrMzAwWURKqtPwZr3i/I4uLL0wvNwS7uB9BbFpTCdJrXwKfodej+ynx2e8HUqHPAPTDI a4kT5f9azhH69pKWc281SUQP/S9Buo24qI2zidTuzw4Hb7go2QnW6Cjt0kVJjQf+riBb gc4A== X-Forwarded-Encrypted: i=1; AHgh+Rph204joKMDTNj7FoRwbpZS0HQSmyezRAe5JbF5/GbIc/ChDvrX8k09u5t/y2Zveo3YzpkswxgdY8U=@lists.xenproject.org X-Gm-Message-State: AFuF++k+qikMe6BdsMU2al/c8oEnPNOfQ/IYnwd2WvrCqfuHczjcpf7h NN9OKm+qX/YjAFE0iP7GPgXKJbnYyoEF1DmhwDtGx3EzQgprAKM4OfnXb5v1gZwDYA== X-Gm-Gg: AR+sD10g/laU1vMGemqblXsHnvrRQOktSiNSZZ9SMiOMikxt4vgRKiuwatxCSv77UNv 72QNKE7gdYIdQ+7a336uhEwTDT9B+ag1+mPYvKjJ7mD2EcTaX8a604cipKNaoopH1ew53Fn8vIo knj5QDX/ezi6rJTJTGUNSqDqA4XZu+VsOTKeb95xyNymg5pnJlqLYN3rL5q5V7Mf1ArqIwZLdvd XsMnLkdbozVa9SBows+Flq8vnJCggC80LxRg7VXbo7D3+VfxsDdwgwkUVL6yo6xjwu4ourRN1EW J/0H+9HmcOKNNHqqtl2eap/OFI0U6o4sGQ2Sngi4Af48s315zXTRrycTYsQsb3SHyTUoji/js9f qBsvb0BrGkBPBtIeBnLajHCQga1tGBb9Ra7512sbz5QyXXXIbUypOnDd99zKClk/wDGZ65Bxofg kaMvVm5GOqLCClkqPQh1p7Lg4TnKcGiwlU3MVr4QcNFDqk6MrrveiJDYH5bHfiA7fOWmcCleMbE +KBMp7ai5kdXtmrvH/LuqKioUK1eheLV/qW5F0QFRsevmVwsIJk X-Received: by 2002:a05:600c:5951:b0:49c:e795:9e73 with SMTP id 5b1f17b1804b1-49ce7becffemr62540625e9.6.1788360601337; Wed, 02 Sep 2026 07:50:01 -0700 (PDT) Message-ID: <833452db-58bb-4619-bff8-d78deacff7b3@suse.com> Date: Wed, 2 Sep 2026 16:49:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260902141607.24390-1-oleksii.kurochko@gmail.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: <20260902141607.24390-1-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788360602-538D5CFC-A1EA54FC/0/0 X-purgate-type: clean X-purgate-size: 1012 On 02.09.2026 16:16, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -326,6 +326,8 @@ int __init imsic_init(const struct dt_device_node *node) > unsigned int nr_parent_irqs, index, nr_handlers = 0; > paddr_t base_addr; > unsigned int nr_mmios; > + /* imsic_cfg.msi[] is indexed by Xen CPU id, so size it accordingly. */ > + unsigned int nr_msi = nr_cpu_ids; Since there's no calculation involved anymore, is there a reason this new variable is still needed? With it dropped, ... > @@ -405,7 +407,18 @@ int __init imsic_init(const struct dt_device_node *node) > continue; > } > > + /* > + * hartid_to_cpuid() returns NR_CPUS for a hart Xen doesn't know, so > + * the range has to be checked before msi[] is indexed at all. > + */ > cpu = hartid_to_cpuid(hartid); > + if ( cpu >= nr_msi ) ... this comparison also will end up looking less odd. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:52:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:52:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406035.1639474 (Exim 4.92) (envelope-from ) id 1x1mKI-0007Gz-Fk; Wed, 02 Sep 2026 14:52:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406035.1639474; Wed, 02 Sep 2026 14:52:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mKI-0007Gs-D8; Wed, 02 Sep 2026 14:52:34 +0000 Received: by outflank-mailman (input) for mailman id 1406035; Wed, 02 Sep 2026 14:52:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mKG-0007Gm-52 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:52:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1mKF-007a3c-HW for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:52:31 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98382c-2eae-0a2a0a5409dd-0a2a45018f16-16 for ; Wed, 02 Sep 2026 16:52:31 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98382f-5984-0a2a45010019-b9ff1c23ac87-3 for ; Wed, 02 Sep 2026 16:52:31 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0629b6e88000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 14:52:28 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id CB7E083EE7; Wed, 2 Sep 2026 16:52:27 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=CL2hReGaaWaj54CytTnQ6YJZFUNcFx53xEE3LaY8KZY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=sDCYh9DCS0lpnQ/yUdxa9P4/MetZJC7ZcElb6T3p4SOKcKRh9tp8qVrUqQtgK0xlOhD3bq1LM Yp0Um9YrI3ta8AcKf1TMyiwJW/LkF7j6slSvO+p5bb948pHSKluZ9G2c8/ZC4qSN2QxVeJjZiJ8 9CqTuxyed6OQUioa4fRaTGw0k6GWXJ+CRqWJe62mJRok0n0Av8Laz/4HWL01MsPRsxFQ8P13cZm i/L3yNdhCTfOXxonoDsXd4PYleaaSMT1vdM/xFXZQP96wzACsH24auJ5R5JqQ1ZRPfQ2EPIDFxU h3Vef6DcFXoFUAd7q+SEDCiL6m8LWwwyx7p4lyLWzisw== X-Zone-Loop: f7ad57ef7186d705eceaf2d322db7318785eafcdb9f9 x-campaign-type: default x-transaction-id: 7967a60f-09b5-4882-a012-f9a6c425ed90 x-swg-uid: 01-0adbc4c7-733b-4b7c-8f8c-fbb6e6b7c5ac X-Mailer: Sweego Message-ID: <1788360748.8631fc262581453bbf619ec5b2062170.1a0629b6e88000c4f3@vates.tech> x-swg-bid: 1788360748.8631fc262581453bbf619ec5b2062170.1a0629b6e88000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 2 Sep 2026 16:52:27 +0200 From: Anthony PERARD To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Michal Orzel , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Teddy Astie Subject: Re: [PATCH v2 1/7] x86: split xen-syms/xen.efi linking rules References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com> <8e1b4212-ddb6-424a-91cf-ed80d985825c@suse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8e1b4212-ddb6-424a-91cf-ed80d985825c@suse.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3472.b97dd43ba83536cf.1a0629b6c5c.5c134587c0e420a3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788360748124 X-purgate-ID: tlsNG-d62444/1788360751-1D272757-487E35B3/0/0 X-purgate-type: clean X-purgate-size: 7342 ---=Part.3472.b97dd43ba83536cf.1a0629b6c5c.5c134587c0e420a3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2026 at 02:00:22PM +0200, Jan Beulich wrote: > Doing so, besides (hopefully) adding clarity (not the least by way of > using pattern rules where possible), also avoids explicit recursive > $(MAKE) invocations=2E For xen-syms move re-usable helper rules to a new > scripts/Makefile=2Elink=2E >=20 > While doing so, re-order =2Emap file creation (which can in principle fa= il) > and check-endbr=2Esh invocation ahead of putting in place the final imag= e > (which is now the result of a simple rename)=2E >=20 > Also drop --source-name=3D from the tools/symbols invocation which has > --empty passed, for being meaningless there=2E >=20 > Note that the original "rm" at the end of the rule needs limiting: > Removing intermediate files (which $(MAKE) doesn't itself remove) would > cause re-linking even when installing as root (when common/version=2Eo i= s > left unaltered, and hence an incremental build should do nothing as long > as nothing else changed in the source tree)=2E But as far as I can tell, both `rm` command are still the same, unaltered=2E And both command do removes file mark as intermediate via =2EINTERMEDIATE, before make would do so=2E Without the `rm` commands, mak= e would leave alone "=2Exen*=2E*=2Eo=2Esym" and "=2E=2Exen*=2E*=2Eo=2Ed"=2E > Signed-off-by: Jan Beulich > --- > I'd like to keep the "beautification" part, i=2Ee=2E transforming to mor= e use > of Kbuild=2Einclude machinery, separate=2E Sounds good to me=2E One step at a time=2E > The check-endbr=2Esh invocation doesn't fit neatly into this model=2E I = was > considering to move it into $(TARGET)'s rule, but that's not very nice > either (both because it'd be odd [strictly speaking: wrong] for xen=2Eef= i, > and because it would reduce parallelism)=2E > --- > v2: Mark intermediate files as such=2E Don't use $(if_changed =2E=2E=2E)= =2E >=20 > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -102,12 +102,6 @@ notes_phdrs =3D --notes > +LAST_LINKING_PASS :=3D 2 > + > +final-image-check-$(CONFIG_XEN_IBT) =3D $(SHELL) $(srctree)/tools/check= -endbr=2Esh $< How about removing $< from this macro, and letting the users of $(final-image-check-y) decide which argument to use? > + > +include scripts/Makefile=2Elink > =20 > $(obj)/note=2Eo: $(TARGET)-syms > $(OBJCOPY) -O binary --only-section=3D=2Enote=2Egnu=2Ebuild-id $< $@= =2Ebin > @@ -191,51 +165,69 @@ note_file_option ?=3D $(note_file) > =20 > extra-$(XEN_BUILD_PE) +=3D efi=2Elds > ifeq ($(XEN_BUILD_PE),y) > -$(TARGET)=2Eefi: $(obj)/efi/relocs-dummy=2Eo $(obj)/efi/relocs-empty=2E= o $(obj)/efi/mkreloc > -$(TARGET)=2Eefi: $(objtree)/prelink=2Eo $(note_file) $(obj)/efi=2Elds > + > +=2EINTERMEDIATE: $(addprefix =2E$(TARGET)=2Eefi=2E, \ > + $(foreach n, 0 1 2, \ > + $(n) alt=2E$(n) $(n)r=2Eo $(n)s=2E= o $(n)r=2ES $(n)s=2ES)) > + > +=2E$(TARGET)=2Eefi=2E%=2Eo: =2E$(TARGET)=2Eefi=2E%=2ES FORCE Left over "FORCE" from v1=2E Without if_changed we should let make decide to execute the recipe or not=2E > + $(call cmd,cc_o_S) > + > +=2E$(TARGET)=2Eefi=2E1r=2ES: =2E$(TARGET)=2Eefi=2E0 $(if $(relocs-dummy= ),=2E$(TARGET)=2Eefi=2Ealt=2E0) > +=2E$(TARGET)=2Eefi=2E2r=2ES: =2E$(TARGET)=2Eefi=2E1 $(if $(relocs-dummy= ),=2E$(TARGET)=2Eefi=2Ealt=2E1) > + > +=2E$(TARGET)=2Eefi=2E0r=2Eo: $(obj)/efi/relocs-dummy=2Eo $(obj)/efi/mkr= eloc > + ln -sf $< $@ Why mkreloc is a prerequisite of this rule? It's not use here=2E It could be move to the next rule, where it is actually used, and we could use order-only prerequisite, so $^ won't be altered=2E I've check, order-only prereq where introduced in make 3=2E80 according to the changelog of 3=2E81=2E And they are not part of the $^ variable=2E But the target won't get rebuilt if mkreloc is changed=2E So order-only might not be the right type of prerequisite=2E > + > +=2E$(TARGET)=2Eefi=2E%r=2ES: > + $(MKRELOC) $^ > $@ > + > +=2E$(TARGET)=2Eefi=2E0s=2ES: > + $(objtree)/tools/symbols $(all_symbols) --empty > $@ > + > +=2E$(TARGET)=2Eefi=2E1s=2ES: =2E$(TARGET)=2Eefi=2E0 > +=2E$(TARGET)=2Eefi=2E2s=2ES: =2E$(TARGET)=2Eefi=2E1 > + > +=2E$(TARGET)=2Eefi=2E%s=2ES: > + $(NM) -pa --format=3Dsysv $< \ > + | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > + --source-name=3D$(TARGET)=2Eefi=2ES \ > + > $@ > + > +# See above for why $(note_file) needs removing here=2E > +efi-objs =3D $(filter-out $(note_file),$(filter %=2Eo,$^)) > + > +=2E$(TARGET)=2Eefi=2E%: $(objtree)/prelink=2Eo =2E$(TARGET)=2Eefi=2E%r= =2Eo \ > + =2E$(TARGET)=2Eefi=2E%s=2Eo $(note_file) $(obj)/efi= =2Elds > + $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi=2Elds $(efi-objs)= \ > + --strip-debug $(note_file_option) -o $@ This command have changed compared to what we have currently, for the step "=2Exen=2Eefi=2E0"=2E In the case where $(relocs-dummy) is empty, thi= s command doesn't have relocs-dummy=2Eo on the command line=2E With this pat= ch, the object is added, via =2Exen=2Eefi=2E1r=2Eo=2E Is this fine? > + > +=2E$(TARGET)=2Eefi=2Ealt=2E%: $(objtree)/prelink=2Eo =2E$(TARGET)=2Eefi= =2E%r=2Eo \ > + =2E$(TARGET)=2Eefi=2E%s=2Eo $(note_file) $(obj)/e= fi=2Elds > + $(LD) $(call EFI_LDFLAGS,$(ALT_BASE)) -T $(obj)/efi=2Elds $(efi-objs) = \ > + --strip-debug $(note_file_option) -o $@ > + > --- /dev/null > +++ b/xen/scripts/Makefile=2Elink > @@ -0,0 +1,51 @@ > +# SPDX-License-Identifier: GPL-2=2E0 > +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > +# Helper rules for linking xen-syms > +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > + > +syms-warn-dup-y :=3D --warn-dup > +syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) :=3D > +syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) :=3D --error-dup > + > +orphan-handling-$(call ld-option,--orphan-handling=3Dwarn) :=3D --orpha= n-handling=3Dwarn > + > +final-image-check-y ?=3D true > + > +=2EINTERMEDIATE: $(addprefix =2E$(TARGET)-syms=2E,$(foreach n,0 1 2 3,$= (n) $(n)=2Eo $(n)=2ES)) > + > +=2E$(TARGET)-syms=2E%=2Eo: =2E$(TARGET)-syms=2E%=2ES > + $(call cmd,cc_o_S) That recipe change slight we what's currently in tree, there's now "-DXEN_BUILD_EFI -DBUILD_ID_EFI", but that's probably fine, CFLAGS-y from xen/arch/x86/Makefile are now taken into account=2E (That's likely the case also for =2Exen=2Eefi=2E%=2Eo but I haven't checked=2E) Overall, the changes looks good to me=2E Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.3472.b97dd43ba83536cf.1a0629b6c5c.5c134587c0e420a3=--- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 14:58:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 14:58:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406047.1639483 (Exim 4.92) (envelope-from ) id 1x1mPg-000827-0w; Wed, 02 Sep 2026 14:58:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406047.1639483; Wed, 02 Sep 2026 14:58:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mPf-000820-UZ; Wed, 02 Sep 2026 14:58:07 +0000 Received: by outflank-mailman (input) for mailman id 1406047; Wed, 02 Sep 2026 14:58:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1mPe-00081u-SN for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 14:58:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1mPe-00C3p2-92 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:58:06 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a983955-8faa-0a2a0a5109dd-0a2a45069bac-46 for ; Wed, 02 Sep 2026 16:58:06 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98397d-195a-0a2a45060019-d155802ec486-3 for ; Wed, 02 Sep 2026 16:58:06 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49a97714f5dso8513305e9.0 for ; Wed, 02 Sep 2026 07:58:06 -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-49cdce0b456sm177152935e9.2.2026.09.02.07.58.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 07:58:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788361085; x=1788965885; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=vmuvBDjWYJHnqA0vMM7pZs59UdG/idKMXME5CHSaBio=; b=D7X1lZQ8XCBQM4mn3qksswRDEG+sEhcj0NArtdkcilEQM7P/n2qGFPKabxbcWthZlM Hv5Q2BZpq/GyCKKsooOftY/uaREM9d7YnGDhJ9Y/6U+HulP4Mf73xmFAXlAXo6GoXhvh Wzews+FUidYPWXO+zwlblK/QrwcfcEarPS+adDMUgvpRbLzfTW9p4xPt7pZKUvypdWy6 CJa5DXWkKS3/TbrCXWhHtszB11dVFusFDUmBafoTGBh4HxOO7vupwdZjKr6V5UzFotWm V43j7hFphjf5PPZ5Am9AukpKMmPeBmLtn+UbPV3E+tXkDxjMQvDlxomtITkJ6NZnk3GM 4HRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788361085; x=1788965885; h=content-transfer-encoding:content-type: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:content-type; bh=vmuvBDjWYJHnqA0vMM7pZs59UdG/idKMXME5CHSaBio=; b=E46CEY6wtx1CeAyFagT/JmMbQ1ZuEaUeNRymJ1JEyx7ILhmUMc1bw8+A59t2FSR5qh NZfQcQjxFsN/7QAE70gc0lLrL2Huu8Q/IvPc6DrYQS1S7lOszR7aG5smcACy9RINtsNP +QLjZMldiB5E/Uwiiq+48wIiKQAk7kTSqaC3rrJ9le6cfhg3vfkOgd7iGGH94x3xKf4W Ihx0s/DqSXujT5BZw7/Az1ap/X74H7L7rgopkdpdqRdh8N6q5nUeq9XFzBhKbRwc45s5 Jogo8lJJrkJhHVclSF+Xv7EmqIkUw01aqg3XJvnwOM2P63ksWSvxa5qB3vc8D6X3VkFK xAeQ== X-Forwarded-Encrypted: i=1; AHgh+RpT02fC29rEcSXdyHtySAzKmsoU1iNgGukGK7hpkJQtr9AL9p9MKxtDcThnJb6DfRzV5d76L+Ppr/E=@lists.xenproject.org X-Gm-Message-State: AFuF++l0pzQ3RBH4GMFOijC4OCDJ5FljLTjwPSgFTvaJKvWlpEjZ+HxN i+zJa113RsiT5Oh/0V1GH7lWGWjLWOezrymyMlguJEB9X6stuVxVtyqxiwWmoeoWkw== X-Gm-Gg: AR+sD11l9ZeQZyx3KeSsx79dCgOuxPaHPEcA4TkFwZG0YBzaHdsnxagqXbbLgAcqFrB 4srrtuhEkYjJNRlth/dDBeDd4oBRfwXv7p9E5ChKALw3O3CFjhxODvHujjIvjuV7zhZlAf3YPyh j52MCN8xh1Y6G/J4YjuRQFmLPLY++eyQQZsT8D78AZOfOFiRE5orsnGM6J2vSpeMVJU+fo8f73p iZpq0o1xdL3AkhhOaKEbU3/mK3ttILCTmi8k+rfaff7uVzwzRyqGRjH1b543gXYde0di3OxK0M0 s/oX02RumT/W65HXC6ympSH7rx4Tz27ExWYLVJWmoM2hV/AjkU4w+UvoZADriIBa0huGllcvMDJ 40CZa5CJZKYY8hw5oA+jJ8gYxj8MINcoQtiMWjmigliKSxnm7pZbBn0+XnoAM2CJQUFyeEZK1/j BF70zE01nKLTWc/ghmm6usG2TfGZD175Bt869K/TfVZ4CmFNSOwGdftgg3gMhACsP9rg/eme/Rn Ba9sMEPwW3OJe8n3JRynCWRFysD6EyBRFFXrfo+pqiB6wZ3jvyM X-Received: by 2002:a05:600c:4e4a:b0:49b:9113:e04a with SMTP id 5b1f17b1804b1-49ce55ecde6mr98125635e9.1.1788361084286; Wed, 02 Sep 2026 07:58:04 -0700 (PDT) Message-ID: <8520ca5b-d7d6-4e5c-a6f3-2969762fadd3@suse.com> Date: Wed, 2 Sep 2026 16:58:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 04/20] xen/riscv: introduce guest riscv,isa string To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <2eb660bd05c6bf5946a7eae09406266db0c5108f.1787836900.git.oleksii.kurochko@gmail.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: <2eb660bd05c6bf5946a7eae09406266db0c5108f.1787836900.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788361086-1FACA77B-7DB1F857/10/73395122804 X-purgate-type: spam X-purgate-size: 3464 On 27.08.2026 17:18, Oleksii Kurochko wrote: > Introduce build_guest_isa_str() to generate the riscv,isa string to be > passed to the guest via the Device Tree riscv,isa property. > > Introduce the per-domain guest ISA bitmap, populated during domain > creation by calling init_guest_isa(). > > Introduce struct riscv_isa_ext_entry with a new guest_flags field > to filter out ISA extensions that should not be exposed to guests: > > - f/d/q/v: FPU and vector context save/restore are not yet implemented > for guests. > - Z*inx are not exposed either: they aren't in riscv_isa_ext[], so they > can never be set in riscv_isa and thus never reach a guest, and no > current hardware/guest-OS advertises or expects them. Supporting them > would be cheaper than F/D/Q (FP values stay in integer registers Xen > already context-switches), but is left as future work. > - h: Nested virtualisation is not supported. > - sstc: Xen owns the supervisor timer; guests must use SBI. > - svade: Xen manages hardware A/D bit updates in stage-2 page tables. > - svpbmt: Page-based memory types are not yet wired up in stage-2 code. > > Signed-off-by: Oleksii Kurochko In principle Acked-by: Jan Beulich Nevertheless I again have something for you to further consider: > @@ -34,9 +36,64 @@ struct riscv_isa_ext_data { > .name = #ext_name, \ > } > > +/* > + * Which guests an extension may be handed out to, by guest XLEN. > + * > + * These flags express Xen's policy, not the ISA's rules: extensions which > + * are architecturally tied to one XLEN (Zilsd on RV32, say) need no special > + * treatment here, as they can only ever appear in the "riscv,isa" of a host > + * of that XLEN, and guest_isa is masked against the host ISA bitmap anyway. > + * They are only of use for extensions Xen chooses not to expose to guests of > + * a given width despite the hardware implementing them. > + */ > +#define RISCV_ISA_EXT_GUEST_NONE 0 > +#define RISCV_ISA_EXT_GUEST_RV32 (1U << 0) > +#define RISCV_ISA_EXT_GUEST_RV64 (1U << 1) > +#define RISCV_ISA_EXT_GUEST_ANY (RISCV_ISA_EXT_GUEST_RV32 | \ > + RISCV_ISA_EXT_GUEST_RV64) > + > +/* > + * Guests are of the same width as Xen itself for the time being; once guest > + * XLEN can differ from host XLEN (hstatus.VSXL), this becomes a per-domain > + * property, just as guest_isa below does. > + */ > +#if defined(CONFIG_RISCV_32) > +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV32 > +#elif defined(CONFIG_RISCV_64) > +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV64 > +#else > +# error "Unsupported RISC-V bitness" > +#endif > + > +struct riscv_isa_ext_entry { > + unsigned int id; > + const char *name; > + unsigned int guest_flags; > +}; > + > +#define RISCV_ISA_EXT_ENTRY(ext_name, guest_flgs) \ > +{ \ > + .id = RISCV_ISA_EXT_ ## ext_name, \ > + .name = #ext_name, \ > + .guest_flags = guest_flgs, \ As you're using token concatenation here already anyway, why not .guest_flags = RISCV_ISA_EXT_GUEST_ ## guest_flgs, \ helping the use sites quite a bit? (Whether guest_flgs [then] is a good parameter name is a separate question.) Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 02 15:07:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 15:07:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406091.1639507 (Exim 4.92) (envelope-from ) id 1x1mYg-0002P8-7k; Wed, 02 Sep 2026 15:07:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406091.1639507; Wed, 02 Sep 2026 15:07:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mYg-0002P1-4v; Wed, 02 Sep 2026 15:07:26 +0000 Received: by outflank-mailman (input) for mailman id 1406091; Wed, 02 Sep 2026 15:07:24 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mYe-0002Ok-FX for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:07:24 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x1mYc-001wTX-0I; Wed, 02 Sep 2026 15:07:21 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1mYb-00HXXU-1d; Wed, 02 Sep 2026 15:07:21 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=7uwt6EZj2ufEAQ5KMI1zSwIM5I80XSBcrup2qjUBGzM=; b=4S1XARDoDs5iVViRDhS2Xj4Ahi bDTV8PllfX8z+JCY3XNpNF81L1LGKydYbJotpYrngA1Br/8A8fea3P3ZgRo+cDcMDIQ5gAse9H/zp TJ20iuGIXV1TGYyGox6W3z/s0Wahrs6JExHKvMEywGgaTH94o87wM6mKQyKa0cAhxH74=; Date: Wed, 2 Sep 2026 17:07:16 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH 13/14] passthrough/PCI: rework (s,b,d,f) init of struct pci_dev Message-ID: References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <52dcd7cd-52db-4b59-90ef-f7cde79cf5bc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52dcd7cd-52db-4b59-90ef-f7cde79cf5bc@suse.com> On Wed, Sep 02, 2026 at 02:53:58PM +0200, Jan Beulich wrote: > On 02.09.2026 14:44, Roger Pau Monné wrote: > > On Wed, Sep 02, 2026 at 08:36:27AM +0200, Jan Beulich wrote: > >> Right now we're casting away const-ness, to initialize the individual > >> elements despite the field(s) being declared const. Eclair validly > >> recognizes this as a Misra rule 11.8 violation. Hide this by switching to > >> the use of memcpy(), deriving the destination address from the (mutable) > >> struct pci_dev * which we hold in hands. > >> > >> No functional change intended. > >> > >> Signed-off-by: Jan Beulich > >> --- > >> Subsequently we may want to further leverage the sbdf local variable we > >> now have in the function. Yet of course the primary question is: Is this > >> an okay game to play in the first place? > > > > I've wondered the same, while this might be obfuscated enough for > > Eclair to complain, aren't we still violating the spirit of the rule? > > We do, but what do you do without dropping that "const" (which I'd really > like to keep), and without C++ concepts of initialization? Is it possible to "tag" this with a comment? Noting we are aware of the MISRA violation, but the result of the field being const outweigh the violation. At the end the memcpy() is also a violation, and hence is likely to also be flagged by Eclair in the future - it might be best to simply come clean and accept we have an intentional violation here. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 02 15:18:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 15:18:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406114.1639541 (Exim 4.92) (envelope-from ) id 1x1mig-0004We-CS; Wed, 02 Sep 2026 15:17:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406114.1639541; Wed, 02 Sep 2026 15:17:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mig-0004WX-8q; Wed, 02 Sep 2026 15:17:46 +0000 Received: by outflank-mailman (input) for mailman id 1406114; Wed, 02 Sep 2026 15:17:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1mie-0004WR-5t for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:17:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1mic-00BuK5-PG for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 17:17:42 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a983dd5-2eae-0a2a0a5409dd-0a2a4503d0a4-48 for ; Wed, 02 Sep 2026 17:17:42 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a983e16-fae8-0a2a45030019-d155dd36bc8d-3 for ; Wed, 02 Sep 2026 17:17:42 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-47f96c5b722so885112f8f.0 for ; Wed, 02 Sep 2026 08:17:42 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448e80388sm8352989f8f.14.2026.09.02.08.17.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 08:17:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788362262; x=1788967062; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zB+wempCEfJecIINGEx0c90FbBFCI2ATDoBIjd67oT4=; b=O5QtjkC6FyI110L7nknOI0sUAZoj0GWX1QLYSq4GjLk5mgF1eWojJE5j7KAQbW9tzy vDntjrw85zPrnbHwy3GSV3+OiWg7lwS4NICnA+uJe9B5vqhJCfWWhKdf7SBGm/0QqpTW WOIQ521LinZT3YX+dbnTC4+icFA57S0E6V2/NVDCW2dBdrbKvoDJx1wt8Om1wdgSSBYh voBYPthf7gqUh3yOLn0s/Xx7okgcZyFaLGm4fyn8YThcCUG4KmMJ/DLWv5DWiBtdBLT/ Iji6L73qVJgnRmbsq82KyTvnM0G/Tsh68Lg8j+4IiJxUjQvg7tw5s/upOPFskyUZWeIn yhHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788362262; x=1788967062; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=zB+wempCEfJecIINGEx0c90FbBFCI2ATDoBIjd67oT4=; b=q6vBhiEXK163OL0+u3rVsDFsiHN72Tr4H0MsAd935yudHDJSG2D77hBBcLkmj7mp89 nOB9rQ0E+x0L8xixF/ZAeebQsGMRS7qs7S+4gLt4J7VFVvXfZt8y7wZVDtqGBX4HBOdS MybLM1gKDLwL8MFIb3AFB7pWKeUen3AkCCQ9IhsnMMkz4yZ3ZLT5ngmi4AnHGxng8ozY cfzPGt3rmiJy06aGyBQce+TiRkYK3q5KBodo4WlCEeWH+tg/Ca3KJMVEZg2JmLkum6WV tQJb4F0nOSAN1iUzj6X15jAiLyaY5Cu5TaPr712pDJ6NocjhZSVlQxQc1p42cl2oeRWd NFxQ== X-Forwarded-Encrypted: i=1; AKwUvBzbvTT/gwNZhTtkonUT7ktS65sOmLYCYXKqA+M+2A8I6DPQ2maoK0toAQQ6ep71hKkjakNpwAForjA=@lists.xenproject.org X-Gm-Message-State: AFuF++nBIlZQ6AB7UDRexYBCl8U/SaunOfxht3DD/CxSOfNEMoDcg+h5 xAWN/Sn6cgeBK2oVUHeHlD4SoYwjiYikPVH3iBQqddJL2u33Hib1nkkU X-Gm-Gg: AYBFou2QRb8nw10ieVLeTl1l2rgmIBjEsulQPGg8rmiqorJe2eWDRW4/9/4Fa4hvXf6 OCzMUDHfyFFvc1v7e+7dvxgzX/kXclN0exTDf3MuLNBeci1btrgeid3BI8t0XbGmBq36gV2/ZZ2 u4TFigWTMf7eBzcuexmhfA8mqFrnnWp5GRi/SaQAsAwlAzr2p5j7cyJigBVxnkJqUjfEH1MH46P EgsWH1bcks+1YkX7uUAXmvP5EF7RA5PdwB3xBmOW16pDyeuy6lnHk3Bd7tsVjEerwZ3hQuO7Qh+ Pvbx4trRKklLKyk5ezxsiIdMMNuPM5HPoyoDS7XIoX1E8t5iP7UUz8sZWpW8IP7I5WVayg4LJc0 25pdzEej77bAgIHk9HkO2sGEjdcfIqTuN0Jhb4uiF0rB7WF6IznvmyLVK78Bdfk1MJsaVECGl5W jmui7bbX9Lh0SP7Pr1NdyUgm+y22QPDFr0dLI34/TYwu6heo0b5+c/y9488FAk4Eu31+o7jNM9J iyMWT8i/G7KUrwT2Tptx1+Za8hU/YuN+Y2sX6JR+A== X-Received: by 2002:a05:6000:188f:b0:484:3310:f39b with SMTP id ffacd0b85a97d-484914d7010mr10994137f8f.28.1788362261968; Wed, 02 Sep 2026 08:17:41 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 17:17:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> <127e8aea-4d65-492e-8bda-bffc75f02481@gmail.com> <071c5b4f-1d57-4223-94bd-9f8ae8d80366@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788362262-6F4C74E9-47CEBB39/10/73395122804 X-purgate-type: spam X-purgate-size: 1926 On 9/2/26 4:31 PM, Jan Beulich wrote: > On 02.09.2026 15:29, Oleksii Kurochko wrote: >> On 9/2/26 3:07 PM, Jan Beulich wrote: >>> On 02.09.2026 13:42, Oleksii Kurochko wrote: >>>> It will also affect then common code as vcpu_csr_init() could be then >>>> called before domain type is set: >>>> >>>> +++ b/xen/common/device-tree/dom0less-build.c >>>> @@ -812,17 +812,18 @@ static int __init construct_domU(struct >>>> kernel_info *kinfo, >>>> else if ( rc == 0 && !strcmp(dom0less_enhanced, "no-xenstore") ) >>>> kinfo->dom0less_feature = DOM0LESS_ENHANCED_NO_XS; >>>> >>>> - if ( vcpu_create(d, 0) == NULL ) >>>> - return -ENOMEM; >>>> - >>>> d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; >>>> >>>> rc = kernel_probe(kinfo, node); >>>> if ( rc < 0 ) >>>> return rc; >>>> >>>> + /* The domain type needs to be known before the first vCPU is >>>> created. */ >>>> set_domain_type(d, kinfo); >>>> >>>> + if ( vcpu_create(d, 0) == NULL ) >>>> + return -ENOMEM; >>> >>> I don't understand the need for this, likely because I don't see why >>> domain_vsxl() would need calling from underneath vcpu_create(). >> >> The call trace will be the following: >> vcpu_create() -> arch_vcpu_create() -> vcpu_csr_init() -> >> domain_vsxldomain_vsxl() >> >> unsigned int vsxl = domain_vsxl(v->domain); >> >> ... >> >> vcpu_guest_cpu_user_regs(v)->hstatus = >> HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(vsxl, HSTATUS_VSXL); >> >> Without moving vcpu_create(d, 0) after set_domain_type(), domain_vsxl() >> will return something wrong. > > Question is - do you need to set ->hstatus this early? Good point. I think that there is no really such need. It could be set (at least, VSXL) just before jumping to new vCPU where we know domain type for sure. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 15:21:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 15:21:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406121.1639551 (Exim 4.92) (envelope-from ) id 1x1mm2-00069b-Pj; Wed, 02 Sep 2026 15:21:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406121.1639551; Wed, 02 Sep 2026 15:21:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1mm2-00069U-MQ; Wed, 02 Sep 2026 15:21:14 +0000 Received: by outflank-mailman (input) for mailman id 1406121; Wed, 02 Sep 2026 15:21:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1mm2-00069O-6e for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:21:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1mm1-004bkQ-JG for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 17:21:13 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a983ee4-bab6-0a2a0a5309dd-0a2a4502b23e-22 for ; Wed, 02 Sep 2026 17:21:13 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a983ee9-6ca4-0a2a45020019-d1558032b467-3 for ; Wed, 02 Sep 2026 17:21:13 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49b9320423cso11925445e9.0 for ; Wed, 02 Sep 2026 08:21:13 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cdce10153sm168831755e9.4.2026.09.02.08.21.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 08:21:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788362473; x=1788967273; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9b99N2OUAp1o6mzY52ctUJa0+3WZ2qFKCyn/I4aeoC4=; b=X0Gj3nOq/N2ZpTxT9qYtCIm0nWNBfTitPQe8qFZk4gvGtR1PM/i8DudT4+/ezOdZm0 jjQwOV/pLGk0/2wSNKUyTS7KOK2Y2wf8cFffsZoNVbJagYJPpjaMA4AIBQyn6TUXrw6k dw2pk83XiI6Wq3Yyvl1ac1MyKdZEg9fU8HTMfA3KNaPgSxcI1va0URF2jefRFq61t3wX j2BDNXVnXPQI+qt6vNtsHhSC33TsgcNeWBJU1ZJDzX+vkGHNmNr/vBT7DgoVnUBCQP1b /a6YlAzAzmuVi3wsDM9pOmAYTwM0cM10kc3gWNfzJx90P1TzJuS5lRWzGYKpgdgfoRLT sTZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788362473; x=1788967273; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=9b99N2OUAp1o6mzY52ctUJa0+3WZ2qFKCyn/I4aeoC4=; b=qazIqWBhSdBt8C+Qp3TNtDvJJSJTJ8C63llEDLQ2tcqFa1j04V1m3YE7VMVB1pdhUj Pkzao6qPr/K//O4EoNpIHqyiCr3p1Q3aADK54hx4Wp17/OrJFu9uZgFwTqKL5oXylSqB oWxWMH4s6TpMEUFH5mM8eiU7K++eLKHjCKEWet8QQlWT3tLMPzQ8/UAW3FD7sZhSCJaJ 3S6saffOQu54OIr48IXwta8E3C4h0nHVMzwT0txf8ArCLmmgzA8glOyDySKc2Lmn8gH1 aaB/DGkq31VKvbppXVqHvCZyfZkQybkNwBndLW9zHsaA9Dv7Zr497sJT00jfydiGgJqS j4Hg== X-Forwarded-Encrypted: i=1; AHgh+RpjJtpkVq4IuwX67AV1wqc9Q8aaEjvlLIYfgH83Nwz5XKWg0cXWFTR7MMlQvbjKFE5lMj5wy4NVP9E=@lists.xenproject.org X-Gm-Message-State: AFuF++kvqAnCMalZ9lSkJC2V5rxpq8Zd2HYG10arKj7Ml1HI1SwPCzXo ZkT7RzVofBeJazbX3HQQ87vj/DF9cbq0YQdqdvM6IreaLOu//BlaVKVG X-Gm-Gg: AR+sD10ceqHil+B68wvI/FmZX4VmKesEFOaUhSxzVSxl7kvQAWft3fuY5532uadVjEX KmrPFtbEJ9Ul52EPE8L6djHs9KP3RSnpGf4Pxs6UYnsYiX5fx1oCj/RL5hGIv115rcavMYMZfjY W2GKS2/sFhl98AONWiaqBH1RxXpw16uuG2endzdyeYLG0zuZ6dMgwRkfb/CKIHke4KIscd5Xccy FLTroNE9Alx1GjfAwdpKeyIIC6VLWjWprbdH8c+tp70N3HosNCHAMqBySUblwKEVUD5X4C08Wd2 trljlKRsMghFQjYHWh1m9JHObkiGkvJbKKCjr+HV3muZInS+O5qocJNHPyumYXxl0Fd7n5RJWqJ y4c1RZspZf3dhAPZLuvQaRLUF2CVMPqIMJ87drXW6Yh453Pf3M1itbl8QDyk+OksHGO3/tluKdq GJc7VifnbVqbie1NOOT+vO/1xtxHlMUz1N4RhopbSqxmjkM1znZGL2xWFGq2u8ZkNN2DfQkyFEG e+dme4MPL5FoJ75liU6qSsu+NBAH4iNkUhPNB+xcw== X-Received: by 2002:a05:600c:1c29:b0:49c:cee0:e7c1 with SMTP id 5b1f17b1804b1-49ce584c93amr99614505e9.16.1788362472727; Wed, 02 Sep 2026 08:21:12 -0700 (PDT) Message-ID: <12197240-1e1c-4d97-8321-1b4208141582@gmail.com> Date: Wed, 2 Sep 2026 17:21:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260902141607.24390-1-oleksii.kurochko@gmail.com> <833452db-58bb-4619-bff8-d78deacff7b3@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <833452db-58bb-4619-bff8-d78deacff7b3@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788362473-F12A12AC-6D05823E/10/73395122804 X-purgate-type: spam X-purgate-size: 1230 On 9/2/26 4:49 PM, Jan Beulich wrote: > On 02.09.2026 16:16, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -326,6 +326,8 @@ int __init imsic_init(const struct dt_device_node *node) >> unsigned int nr_parent_irqs, index, nr_handlers = 0; >> paddr_t base_addr; >> unsigned int nr_mmios; >> + /* imsic_cfg.msi[] is indexed by Xen CPU id, so size it accordingly. */ >> + unsigned int nr_msi = nr_cpu_ids; > > Since there's no calculation involved anymore, is there a reason this > new variable is still needed? With it dropped, ... I just thought that nr_msi will be more clear nr_cpu_ids but ... > >> @@ -405,7 +407,18 @@ int __init imsic_init(const struct dt_device_node *node) >> continue; >> } >> >> + /* >> + * hartid_to_cpuid() returns NR_CPUS for a hart Xen doesn't know, so >> + * the range has to be checked before msi[] is indexed at all. >> + */ >> cpu = hartid_to_cpuid(hartid); >> + if ( cpu >= nr_msi ) > > ... this comparison also will end up looking less odd. ... I was wrong. Will use nr_cpu_ids instead. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 15:56:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 15:56:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406140.1639558 (Exim 4.92) (envelope-from ) id 1x1nJo-0002Ck-9X; Wed, 02 Sep 2026 15:56:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406140.1639558; Wed, 02 Sep 2026 15:56:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1nJo-0002Cd-6z; Wed, 02 Sep 2026 15:56:08 +0000 Received: by outflank-mailman (input) for mailman id 1406140; Wed, 02 Sep 2026 15:56:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1nJn-0002CV-DX for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 15:56:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1nJm-003Qce-4e for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 17:56:06 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a984716-8faa-0a2a0a5109dd-0a2a45079318-2 for ; Wed, 02 Sep 2026 17:56:06 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a984715-b4ea-0a2a45070019-d155dd2bc550-3 for ; Wed, 02 Sep 2026 17:56:05 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-4843f205a5bso931675f8f.1 for ; Wed, 02 Sep 2026 08:56:05 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448e800cfsm6919332f8f.12.2026.09.02.08.56.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 08:56:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788364565; x=1788969365; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=CcrEXnIwy36amc4izOGe3Zf1k6Xo3Vi0qqPL9Xy8XiA=; b=TiRFhE3eJ8BX0G396s79qjaJl1Md0KPlEOYKaCcGZ2GWL/+3QRNdv/CalGe6ooUGaW VV+v+x0xVWsUYPTTJ4onYbqSXHWWZcfM7qfa72lfMdew8mBuwENFB7rnA4gmh6eBo01U K2KcJPJy60ugjl3k+mvlGDFPyq1zA8z1ZHxytRwvKz1AmxplyMipRE3gKDph2eaWgIrn X4Ia2iP3FF1Pxt4+C3o/3snUnnEIfXmQ710PfCocPnSTSNAgo7bk8J0Yu5zS8v8GNeI+ 4uloDCxqeQg0PtSPywtc5Vmo8G3ig7I5B0ee7RLAk93/GSDMAEy3DQfe1WJ1nZdGlVGd F2QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788364565; x=1788969365; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=CcrEXnIwy36amc4izOGe3Zf1k6Xo3Vi0qqPL9Xy8XiA=; b=EYBJlkg02wctxYx7DwDiOy7pt2/cW0ruIZOkkQ0fjQ1RAVQeYWxuwOBSTb08tuE0/e TGQygjb1XRYR6DpbgV81LkFwlsvcrekufY5kggUnAL8EVHfGEhYoNXMPgEWdRUO3aAML i5dV/T/KcCYryJfVXSDAaR/RSc6L4o/iY45LAZ0U8UasboWtHzGDX05ibXoi5TnbkjbG ohSIp5ceL25ySQcdzTB7Q8cOtygaCrcbr5TOeRyFfTPQgHw6ARPL6RE0oQJAR1vIXfjh 8tdg6tjhdSIcnPGeVt233CpualSvvisG8xZSkQIWK87X9m0jr1SOPh2EaHRlrPCVfUGq t0gQ== X-Forwarded-Encrypted: i=1; AHgh+RqLqa8zVsTUlBGAxAQRlnqvuAzEr4kIAaeAipLfX5oMxjQrJTp+pGWthzBOZ6mfBgdKC6dO9fy2LZk=@lists.xenproject.org X-Gm-Message-State: AFuF++kymUv/1IGufmOZMAjDa0tCtLiEGs2KK+UkK0uOolqmmZG/C+6S vdnSQWb5dKj1lpwzRw5ccmMjnEaBz5G0GiV4UFIJ8JChmMrAmdD7Am+X X-Gm-Gg: AR+sD13rMEqjn+b+b/AISt+Qphwt6YLDZBKyAIFoCEkrfVDWw1aKdfm28AvqLZG3pb5 aS2VME3xAvyRdIPJZnM92bpcuVjR4v7ihtcQQTFEDr1JfQnoiJLTm/4vEDd9QLLd6whCpA5bOcJ sJpULP0TDyQQb5wHYtq1L3cEi3n5looXmjLgbp1veXzxrtyUwnQ2+2Xvyvt8w9ppVH0XSS3GKj4 gf9EhKxTSmYadq8u/CyUURefree89tdrJs6E6cFVkdYAcCtyErA7xRdvIeurhnUWlZzA8ZytrIK OeL48vptPIR48MNhBPW0A7p+ets8UEHJNmU1I0RmnYQSrYIiuNhoLSTOkU6Qh4+XbsRWTO/GH6p roHxyc77va22/9xyXSEIE+Dz3Q1VPfjFHB17xXXRYU28jalG+3cwovXXLVpVWJAvu1Va6Vy40NH 9Ha+uaK9K4ZvOCW3wHkLY46GCD15RubZirrYt19RjqY2g8QWh+l/etOVmZGRQPjO0UwH/AOu0aq lC91XbLdR44FFF8TdBYZyVfqJ6CKsq3PMrl0gJscg== X-Received: by 2002:a05:600c:3f19:b0:499:93b3:91ea with SMTP id 5b1f17b1804b1-49ce582959cmr121773695e9.15.1788364565165; Wed, 02 Sep 2026 08:56:05 -0700 (PDT) Message-ID: Date: Wed, 2 Sep 2026 17:56:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL From: Oleksii Kurochko To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> <127e8aea-4d65-492e-8bda-bffc75f02481@gmail.com> <071c5b4f-1d57-4223-94bd-9f8ae8d80366@suse.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788364566-A7ED6AE4-8678E7EC/10/73395122804 X-purgate-type: spam X-purgate-size: 2764 On 9/2/26 5:17 PM, Oleksii Kurochko wrote: > > > On 9/2/26 4:31 PM, Jan Beulich wrote: >> On 02.09.2026 15:29, Oleksii Kurochko wrote: >>> On 9/2/26 3:07 PM, Jan Beulich wrote: >>>> On 02.09.2026 13:42, Oleksii Kurochko wrote: >>>>> It will also affect then common code as vcpu_csr_init() could be then >>>>> called before domain type is set: >>>>> >>>>> +++ b/xen/common/device-tree/dom0less-build.c >>>>> @@ -812,17 +812,18 @@ static int __init construct_domU(struct >>>>> kernel_info *kinfo, >>>>>         else if ( rc == 0 && !strcmp(dom0less_enhanced, "no- >>>>> xenstore") ) >>>>>             kinfo->dom0less_feature = DOM0LESS_ENHANCED_NO_XS; >>>>> >>>>> -    if ( vcpu_create(d, 0) == NULL ) >>>>> -        return -ENOMEM; >>>>> - >>>>>         d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; >>>>> >>>>>         rc = kernel_probe(kinfo, node); >>>>>         if ( rc < 0 ) >>>>>             return rc; >>>>> >>>>> +    /* The domain type needs to be known before the first vCPU is >>>>> created. */ >>>>>         set_domain_type(d, kinfo); >>>>> >>>>> +    if ( vcpu_create(d, 0) == NULL ) >>>>> +        return -ENOMEM; >>>> >>>> I don't understand the need for this, likely because I don't see why >>>> domain_vsxl() would need calling from underneath vcpu_create(). >>> >>> The call trace will be the following: >>>     vcpu_create() -> arch_vcpu_create() -> vcpu_csr_init() -> >>> domain_vsxldomain_vsxl() >>> >>>       unsigned int vsxl = domain_vsxl(v->domain); >>> >>>       ... >>> >>>       vcpu_guest_cpu_user_regs(v)->hstatus = >>>           HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(vsxl, HSTATUS_VSXL); >>> >>> Without moving vcpu_create(d, 0) after set_domain_type(), domain_vsxl() >>> will return something wrong. >> >> Question is - do you need to set ->hstatus this early? > > Good point. I think that there is no really such need. It could be set > (at least, VSXL) just before jumping to new vCPU where we know domain > type for sure. I planned to set VSXL bits here: https://lore.kernel.org/xen-devel/cover.1787838835.git.oleksii.kurochko@gmail.com/T/#m4144ea90815b48f2d281a2267cd28f50bd4cd54c But it seems that I can't do that there as considering that platform can do VSXLEN == HSXLEN == 64 but someone will try do run vCPU in 32bit mode we can't just crash domain in continue_new_vcpu(). Then still to set it in arch_vcpu_create() will be better (or in the construct_domain() if we want to avoid to change dom0less common code). At this stage it is easier to reject to create such vCPU which violates platform implementation. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 16:32:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 16:32:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406158.1639568 (Exim 4.92) (envelope-from ) id 1x1nsu-00005G-VA; Wed, 02 Sep 2026 16:32:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406158.1639568; Wed, 02 Sep 2026 16:32:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1nsu-000054-Rg; Wed, 02 Sep 2026 16:32:24 +0000 Received: by outflank-mailman (input) for mailman id 1406158; Wed, 02 Sep 2026 16:32:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1nss-00004x-SW for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 16:32:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1nsr-00AE0E-Qn for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 18:32:21 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a984f88-2eae-0a2a0a5409dd-0a2a450bc9c8-20 for ; Wed, 02 Sep 2026 18:32:21 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a984f95-b7e8-0a2a450b0019-b9ff1c129129-3 for ; Wed, 02 Sep 2026 18:32:21 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a062f6c8bd000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 16:32:15 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 40D1381D64; Wed, 2 Sep 2026 18:32:14 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=nNQVaPZ53cy3SQN2iIVBQJOp/DE1cX6lnXjPRbVtl58=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=JtZ/FDtAHv79NyKqrVaqFpABiGNgetMrH8+Ritfl3uxlxE9yi7QyBOJMlc6wyWcS0BnPEGdLp ACZuuvQjLs5EJyU0Z+cnrCFrsJvw4BMnOXypW/FASZOivi3s0lWSa5sR2o8dCmGO9JNvRIftlTX QaEsuPszypzNefql+g0OL3Zzd+h3/pXxI9xtSatjTcqs32Ye6HHdrJ/emWpTZ44gRJ48XoG8RyV +2vIsRt7ZTJ5bdkLQwhw8htXf0n2KiWZH6zS/p73U2NRonGXdWj6EKVQj4YMQdYE44mEqkNc6wJ ePiQZM59EfV8yFR/6MBXZGxItXMKXPiv49GV1Z90C+UQ== X-Zone-Loop: dfdf6fbde1843ed5a1164cbc8f1fcfd69c0983bc46de x-campaign-type: default x-transaction-id: ed90e130-2c7a-47fc-9e44-0632fc5aa11d x-swg-uid: 01-8e635302-73ae-4b2e-be67-b1f44ba2c1a1 X-Mailer: Sweego Message-ID: <1788366735.8631fc262581453bbf619ec5b2062170.1a062f6c8bd000c4f3@vates.tech> x-swg-bid: 1788366735.8631fc262581453bbf619ec5b2062170.1a062f6c8bd000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 2 Sep 2026 18:32:13 +0200 From: Anthony PERARD To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Michal Orzel , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH v2 2/7] Arm: split xen-syms linking rule References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com> <483052d4-b70e-4005-8b10-4ecf509bf40a@suse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <483052d4-b70e-4005-8b10-4ecf509bf40a@suse.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3485.2d18154cb0a3e86e.1a062f6c4cb.9be7a3910a02cb0f=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788366734539 X-purgate-ID: tlsNG-42698a/1788366741-194C39EA-E539A174/0/0 X-purgate-type: clean X-purgate-size: 1931 ---=Part.3485.2d18154cb0a3e86e.1a062f6c4cb.9be7a3910a02cb0f=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2026 at 02:00:55PM +0200, Jan Beulich wrote: > Doing so, besides (hopefully) adding clarity (not the least by way of > [re-]using pattern rules where possible), also avoids explicit recursive > $(MAKE) invocations=2E >=20 > By re-using the generic rules introduced when the respective x86 rule wa= s > split, > - the =2Emap file now isn't created after the final binary anymore, > - --strip-debug is passed to $(LD) during early linking passes (for > consistency the option is also explicitly added to the optional linkin= g > pass rule), > - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are > now properly respected=2E > Orphan section checking, otoh, is getting suppressed for now, until the > about a dozen warnings which would result have been taken care of=2E >=20 > While the 4th linking step continues to be avoided when possible, a > redundant invocation of $(NM) and tools/symbols (plus the assembling of > the resulting =2ES file) is hopefully deemed acceptable=2E So with this patch, if =2Exen-syms=2E1=2Eo and =2Exen-syms=2E2=2Eo are the= same (compare-symbols-tables), we through away =2Exen-syms=2E2=2Eo, and build =2Exen-syms=2E3=2Eo from =2Exen-syms=2E1 (nm|symbols + as)=2E I guess the = resulting =2Exen-syms=2E3=2Eo would be the same as =2Exen-syms=2E2=2Eo, so it's prob= ably fine=2E I think this patch is fine, I didn't find other difference in command executed beside the one described in the patch description: Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.3485.2d18154cb0a3e86e.1a062f6c4cb.9be7a3910a02cb0f=--- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 17:46:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 17:46:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406186.1639578 (Exim 4.92) (envelope-from ) id 1x1p1s-0001G6-Vh; Wed, 02 Sep 2026 17:45:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406186.1639578; Wed, 02 Sep 2026 17:45:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1p1s-0001Fy-S0; Wed, 02 Sep 2026 17:45:44 +0000 Received: by outflank-mailman (input) for mailman id 1406186; Wed, 02 Sep 2026 17:45:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x1p1r-0001FZ-E1 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 17:45:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1p1q-004u9N-Id for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 19:45:42 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9860c6-2eae-0a2a0a5409dd-0a2a4508d23a-0 for ; Wed, 02 Sep 2026 19:45:42 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9860c6-f659-0a2a45080019-d1558032c554-3 for ; Wed, 02 Sep 2026 19:45:42 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49b8ce9b733so10286035e9.1 for ; Wed, 02 Sep 2026 10:45:42 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cee131fcfsm8015575e9.4.2026.09.02.10.45.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 10:45:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788371142; x=1788975942; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=C4hC2ak8MCTuw31DASucD4rpAMtdKfOi0W+HFIbM/Qw=; b=cFP9CiL9G+E+W1B9EyusW/s/cy3xTT822ywwdm6ETW1h6Ozh2q2jRIXK95nOpDx9N/ kRWP8d39m48YWyWBswqv5FD2yRpz0cq0nKtJAwLFkNU6wfFhAvayYPAV3SYKO8KT86xj A00N0SUEYlCoOsuntF8bI7NK8RPtCt3DvhknvQmOdsMZGbAfPiG34t3HMMA4wuNqTe6u a0pXtnMhVEmssGsX6BcH5+L8U0TxZ1GDv0YV72/S9SX4621y8te0dGMomRf86GRCaF68 W0RWP7WpUeX3CVJzhfNHsGQaJGrz2S8y1/MiLcSoDl4sv1Pj62qAEfYz1bWNu6HdnbMp OncA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788371142; x=1788975942; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=C4hC2ak8MCTuw31DASucD4rpAMtdKfOi0W+HFIbM/Qw=; b=DvgXSCV2D77LMg3HhSh30Fc5M9I6M2CqYvQXak9APM28AGNI0Cq6cIXDGv37UJ50Q9 s3lBtoHyb3KLUmQy4SD6uaOArfo/AIKusQStzNYVSvta3Fn99fdSYiqlXWkBBB4YwMjL lL8mxIJOo8HGIkMg9jtQiifHt0ebWSnuy6feP3gNCZ5ZfThNHP9HOJSy0oUhzDq95Xrq 4g+WXwW7U/XKTJW+NOZtwa6JjWYkIjdjGKdzhQ0vRazQL9O4lTPC3RoFYtcJFLO0OzXF Rj/rjhvD1JQ4nUqNvCMpVnWNe8WXpgAg6y7Z9z05CPzS2XtQd8XCVEHxVkpBPyCc/bLW Y3ng== X-Forwarded-Encrypted: i=1; AHgh+RrsLgM9iTwPU3PT8hX4rqgoWEOVgPsDpVP9I6YtnuTGiYrLuB7DgplvNWb0Z81tjNOJdqlFm3wS2uY=@lists.xenproject.org X-Gm-Message-State: AFuF++mL14bRtOH2HYy29TbAwdjJZg+3LnJmiiQy85tdiJHvbutUj1G9 sYQWb/e9VuMeC5Nz+X/JRVR88eaITZQyo6hTNTzcyQW5B5hsCP6uPXV4 X-Gm-Gg: AR+sD11nJ4dVn7Ou11QTiJx+cyOaLcZxepIZzZIGcQqKF2+crdZEUVusWOx1h55PnA0 rA9K4ykQIPSXL+8IHY1htpaf41PV5zfBzM6q8jEH2HuuRJgARyywx/Pgxyc+thcYtgaBffhGc7B 1I7gJ5dIfDiujl2sbk7NXkXIxHmDxd/GQshO6ryqDfNlawIMnWkk5f66DjCO+XdRKTXucN59sGr HSj1NlGHwheM8xeSahVyylVZpHRUyst/czbWYvcqSwLpJs0ddeOOOJkSnyM3CrgoS279bTxBFfN fH+5ptVidz1izhSDmPtPU24dqFa9I6A7X3xlzwxVVtA9vcy0DxgrVgXDsSCQrtWyFoHIre3cyDD 2WVCOsgpyjtPt5toZF27JMYr0YLawchngycaKLSnlF6aJCuv3eiAOIdVnXcPuHBA+GDlRf6L27X HhDNSknljryezhHXiwTy+rVKNLjZ71RJlZDiSJTv4sXJkcxaw/0kG415z09/Wmyo9miNJQexQMU MXakMqoXAuEMRkZ3Pg7tWCb+XYOOD/6DIGfV8LHIlC4DtI4bWjT X-Received: by 2002:a05:600c:3f19:b0:499:93b3:91ea with SMTP id 5b1f17b1804b1-49ce582959cmr137704985e9.15.1788371141568; Wed, 02 Sep 2026 10:45:41 -0700 (PDT) Message-ID: <52c99fc1-7b25-42be-938b-dc9bb38b45c9@gmail.com> Date: Wed, 2 Sep 2026 19:45:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL From: Oleksii Kurochko To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <825ea854-5778-4cb6-a9a9-0ff97fa7bee5@suse.com> <127e8aea-4d65-492e-8bda-bffc75f02481@gmail.com> <071c5b4f-1d57-4223-94bd-9f8ae8d80366@suse.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788371142-D654487B-C277297F/10/73395122804 X-purgate-type: spam X-purgate-size: 3524 On 9/2/26 5:56 PM, Oleksii Kurochko wrote: > > > On 9/2/26 5:17 PM, Oleksii Kurochko wrote: >> >> >> On 9/2/26 4:31 PM, Jan Beulich wrote: >>> On 02.09.2026 15:29, Oleksii Kurochko wrote: >>>> On 9/2/26 3:07 PM, Jan Beulich wrote: >>>>> On 02.09.2026 13:42, Oleksii Kurochko wrote: >>>>>> It will also affect then common code as vcpu_csr_init() could be then >>>>>> called before domain type is set: >>>>>> >>>>>> +++ b/xen/common/device-tree/dom0less-build.c >>>>>> @@ -812,17 +812,18 @@ static int __init construct_domU(struct >>>>>> kernel_info *kinfo, >>>>>>         else if ( rc == 0 && !strcmp(dom0less_enhanced, "no- >>>>>> xenstore") ) >>>>>>             kinfo->dom0less_feature = DOM0LESS_ENHANCED_NO_XS; >>>>>> >>>>>> -    if ( vcpu_create(d, 0) == NULL ) >>>>>> -        return -ENOMEM; >>>>>> - >>>>>>         d->max_pages = ((paddr_t)mem * SZ_1K) >> PAGE_SHIFT; >>>>>> >>>>>>         rc = kernel_probe(kinfo, node); >>>>>>         if ( rc < 0 ) >>>>>>             return rc; >>>>>> >>>>>> +    /* The domain type needs to be known before the first vCPU is >>>>>> created. */ >>>>>>         set_domain_type(d, kinfo); >>>>>> >>>>>> +    if ( vcpu_create(d, 0) == NULL ) >>>>>> +        return -ENOMEM; >>>>> >>>>> I don't understand the need for this, likely because I don't see why >>>>> domain_vsxl() would need calling from underneath vcpu_create(). >>>> >>>> The call trace will be the following: >>>>     vcpu_create() -> arch_vcpu_create() -> vcpu_csr_init() -> >>>> domain_vsxldomain_vsxl() >>>> >>>>       unsigned int vsxl = domain_vsxl(v->domain); >>>> >>>>       ... >>>> >>>>       vcpu_guest_cpu_user_regs(v)->hstatus = >>>>           HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(vsxl, HSTATUS_VSXL); >>>> >>>> Without moving vcpu_create(d, 0) after set_domain_type(), domain_vsxl() >>>> will return something wrong. >>> >>> Question is - do you need to set ->hstatus this early? >> >> Good point. I think that there is no really such need. It could be set >> (at least, VSXL) just before jumping to new vCPU where we know domain >> type for sure. > > I planned to set VSXL bits here: https://lore.kernel.org/xen-devel/ > cover.1787838835.git.oleksii.kurochko@gmail.com/T/ > #m4144ea90815b48f2d281a2267cd28f50bd4cd54c > > But it seems that I can't do that there as considering that platform can > do VSXLEN == HSXLEN == 64 but someone will try do run > vCPU in 32bit mode we can't just crash domain in continue_new_vcpu(). I think that I can have a check that platform supports VSXLEN guest requested based on d->type in construct_domain() where d->type will be for sure properly set and reject construction of a domain VSXLEN of which isn't supported by a platform. And it looks a proper place for such check in general. Then in continue_new_vcpu() just set hstatus.VSXLEN without any issue as at that moment we will for sure now that requested VSXLEN is correct. Doing in such way will continue to follow your suggestion (not ->hstatus so early in vcpu_csr_init()) and also ... > > Then still to set it in arch_vcpu_create() will be better (or in the > construct_domain() if we want to avoid to change dom0less common code). > At this stage it is easier to reject to create such vCPU which violates > platform implementation. ... help to void changing of common code. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 02 20:40:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 20:40:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406221.1639589 (Exim 4.92) (envelope-from ) id 1x1rkn-00029I-Gg; Wed, 02 Sep 2026 20:40:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406221.1639589; Wed, 02 Sep 2026 20:40:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1rkn-00029A-Da; Wed, 02 Sep 2026 20:40:17 +0000 Received: by outflank-mailman (input) for mailman id 1406221; Wed, 02 Sep 2026 20:40:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1rkl-000294-Dt for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 20:40:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1rkj-00CkKU-VA for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 22:40:14 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98896a-8faa-0a2a0a5109dd-0a2a4507d9be-46 for ; Wed, 02 Sep 2026 22:40:13 +0200 Received: from [52.101.56.52] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9889ac-b4ea-0a2a45070019-34653834575a-3 for ; Wed, 02 Sep 2026 22:40:13 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH9PR03MB554594.namprd03.prod.outlook.com (2603:10b6:510:427::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Wed, 2 Sep 2026 20:40:10 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Wed, 2 Sep 2026 20:40:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=U9trhTennRbW/omLgmTDJ/td+pDsQOUOMTzlzQZo0cYy+PA0vssRgzqgk+baBnHJjjk7k0NTjgJNWeu2Y36T4rZk/CKKt2U3ExK32tnn7iXChp2N7DE8WoEy5/qou+QY7t0vmmYY59mPU0zFf5ed7uRzKlGD4+BCYENFjyF6a6eJkSRo/TRVL4boCUATjRKj8nJkDONWcIewaBUhL0MIIueiiSvGZ8BBqz4a3zAhq7E796GNygNYm7/d4VEyLu5Xfuezo6ehHnR1krmMffFNUriZ6rYwZYCZodIPovzbs3DE8GoU0k6LKdMhoo56rfQGoLG1UoUtQBYemdBiFPu8Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ku9poZ+OXv8pHs5ajNmfPbXButIpFhwZBavMU6aWfkM=; b=Eeg4HzIX26VCNUX4d/L4/ndy471engzOqXMvYIozi6zIlhwUsWJxeGHvxzmceJcMHT1ghglLlIMJrA1sXVCQfWsKOUrSA87aHaCaU+RNlwUzSYOwPOl0CSxj/kdfpUDM+fhUirRBctU18wCl5mKpeL7bQK9Csl24E847mnGjspIBgqm0Z3WHh7r37iLkyjAOqeLgsc8BJkwC/Rp9msjTqIhq4hgzv8F5/aciVIywuM0Rw2r7Cy8VDrmdXwScQTzdhL41pey6G8IlL5iUMU4zYqv0W9pykHQwmyWwwCRuAUb1jSltqntxFF0sH1HgyryfiblPn6i0VrHm/hmyoPgJSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ku9poZ+OXv8pHs5ajNmfPbXButIpFhwZBavMU6aWfkM=; b=UbpceBkHRnlrNR2uUuxT8v0n4Lr1kpb94uPJfYyWounwGKkHY/Qc/d3oBYsRz8v0wvNgXekFcY4jOUVVmoNtzExi0lmc8GiavUSQAt4SjXrpKJy6ks4wqza7nfDpSh1StCBfTWxa7Youlee8znsKb+BIqXDsywU1Gok8Vs5oqTI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4c834442-5a31-4814-984e-6398a6bb3602@citrix.com> Date: Wed, 2 Sep 2026 21:40:06 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org Subject: Re: [PATCH 3/4] x86/bitops: Remove ADDR To: Jan Beulich References: <20260902114339.62043-1-andrew.cooper3@citrix.com> <20260902114339.62043-4-andrew.cooper3@citrix.com> <0c43989b-2d7c-4411-8715-eab7390c14d8@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <0c43989b-2d7c-4411-8715-eab7390c14d8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0430.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18b::21) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH9PR03MB554594:EE_ X-MS-Office365-Filtering-Correlation-Id: 821c72ce-cf09-449c-5f10-08df093261ab X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|22082099003|18002099003|56012099006|11063799006|4143699003|10067099003|3023799007; X-Microsoft-Antispam-Message-Info: lcFo0VN1kKo1ZTw1a4kfrCj+RNNcbSEIwTMlXH+m3trd1l5pR//ooph29lLGIvKexYhmTjKZdFQ7b2da0jDib4xG/evbkLnTmmdE/mEQ0Qy1urlfgxBoepTQf0F4DAnmcmX/SR0Q7sIOKkhTDM1i998o+JYOnvsLnvvpH9SjmsexsylUH9x1ETM5ckWWgaj9BgX9BoDLg5XBEgrIqPdOer9qMJEq0adY445Rwl9neALojwbHU53xRRU3jzhAWNAypx/3+ZDK5611iE8emrdYsTuvAJPdYebcf/36+GGQ0zZXodGdXrUzrZ0beDOuZ5SCuBYZNJl8Rb42zvBWAqrCzf0xMX3oDr9KPebG8Q4O1SYwwPSIyCKtnqLk1nTpIX7D+E7+1k1vIlkTszE1LsFMFUQwoU8bHricR9tBsrMqjQ4dOentmWU4HBf4yr/jGIpvcpEhLULtpo/x7VrjXtpZac8ljpxDf2sCQgCgG5Mj6LljEFnrp6b96E28ePPR+uIV/VYOz2NOxRD8uJrCfMw8pV59n0SEh4aIBT2pHt32XQhtwhmq7/k2Ihdw1WpyIN5mve6JfDFjaJ73sF/cDFy17g34qGn/zF7F5Sj2Qh+nrL489KdUTor/W1EpVpf/oCALcoCVFjS9H4KBixj7GqTjnm7nOp4+VTXlWz5vqy+lsXE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(22082099003)(18002099003)(56012099006)(11063799006)(4143699003)(10067099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MktxL1FrT2wrZVhid05xWTFQM3M5bi9NcEMycnViYmJiMGJiazBvVU95Tmtx?= =?utf-8?B?aFVXMGR2N25GejR4dy9mYnkyRzRFbjU2SlcxUDAvQ1JPcDJ3UFhVclhhZzVR?= =?utf-8?B?V25YVFpwMWh0blNwZ0RTa1BFNlMyalJUa3NZSWpCZSsrNGtLaFR1dXBudVVB?= =?utf-8?B?TTdkRldpeGpVWTVEWEZCcCtnVHBScld1cWJiUFpDSThIQ2lmc2pqUXBpc3Uz?= =?utf-8?B?Y2dqYWNXRnhIZEkzb2NSbk82N2dlc0t0SEp6cndFZ09Ld0c2cDBERjlTUkdN?= =?utf-8?B?YlNtbUl3UFpRSEVEMHpJcTBOMi9WMDIxRklaMGJuaGRkTWtzL09TdnJ2ZHFI?= =?utf-8?B?TGt6c0tmMTczSFl2M0ZJL3p2elZNWWI3MnFlRlIvcDBaVHd4R2pBbFVnSTJI?= =?utf-8?B?QXNORHc0a1FLZEFlTnBZbFh1Z1hHa1dmcXRpaG1pZWNpMHppbHR0V2pDd2dX?= =?utf-8?B?Uk9vekNaNmxnYVJWRkt4UExReEpWQzNEaE5xVkhMMFY0K3JsNGU0YnlXNFFR?= =?utf-8?B?TVlBRHR1UlFnUXVvdUFyRWFqcVJCVmpaNmo1NHlwb1NJdm9VYXpHblFSY0NN?= =?utf-8?B?aGNleGgrTHRoK1VOWXRZeGdPT2NrVDhucUtoei9nNXVXaWdCV1pOQ0w1WTF6?= =?utf-8?B?SEpKUlEvNDZLd2taTG96KzVlS0Yyb0JTc1Jld2hxOEZXMW1vcDBWYUNKZGhw?= =?utf-8?B?RlR0WG8rZm4rTTc4WVlGRm41TGhNYjlwNU8yYXZ5TlJDVmZSdHk4aEtTaUpx?= =?utf-8?B?dnRsOXlKOHVTYXl6b2tXOHlpOW5KWTNVK1dmTVJaN0FKYlRYR0tMNTI5OFdl?= =?utf-8?B?RjN2SFRvVjRLd1BzMTJHZXNxR0t4MmF5WHRYVXR3WkxkWFBBM1FhUE9HZlRQ?= =?utf-8?B?ZlRvMHdWTUl1eVhNOVRpQXlwNGFhSVRjeXo3bXpWQ1diYlRXTTB0NHRndXp5?= =?utf-8?B?Z3djR05rQ2ZXRFcxaTYrRlFFM3lqMExtdlJnbjMxWXBsSTBvN2NWekZEOEs4?= =?utf-8?B?Q1JxZEYyN2RwSVo5bkJ1VlVmTVlSMG9ndVQzNlBmaXdkb3paMGsxWWhEUVRM?= =?utf-8?B?Rys3Y29EeTgzM0JScm9XR0FGZDdReHR1U2RiK1FaQXZVNHlnUlBQZVpKK3hK?= =?utf-8?B?eEgxdnd3bEFKeHNGV3BVbmwzaW5UMU1xb08wSTJ1dzFPM0huLzFFOXQ1eDBQ?= =?utf-8?B?QW93WGVuUlZxZkFLazgzOHJ4Z2l6ZWpDYkVBT1hzaWhBdk1BdjZuQzY1bUVt?= =?utf-8?B?dkRWVlhOOHhvNlhkZFpBTHpweExRVnV6ZWRVR3U2OER2U0kvR0g4NHlubVd0?= =?utf-8?B?bGt1OVVyQ0kwVFlrd05EREF6VEVZVDV4SDF2Z1FDT0xGeXVlemc1T0szeWdJ?= =?utf-8?B?Zm9jUlNmNmxnV0Q4d1pBTUJiQ3NLM0xuWENoSGJwcU9uaVpMRE40bm1SeUY2?= =?utf-8?B?aHkzZVJBZW9pWVdHM242dVVmMi9mU3RLWE9wZnN2TG5vbVRpSVlsbS83WWFT?= =?utf-8?B?UW53QzlFalFLYnlqV2xvVDYxa0U0T3hsamN6cDUyczNOb2NHOXVxMW5nNWp6?= =?utf-8?B?RjE4SmpMMWFXejRHT0hKVGJML28xZWJUcGo0ZFZxTXVOTzJsazVkcXRwQjZH?= =?utf-8?B?N0ZrbGUvZ2QvSTYrOXh4KytGVC9DL3kvQjJFU2h2aVpjUVh1Y3pvM2FNYi8z?= =?utf-8?B?YVJsWlJ5ZnYreERoeHJ2K0tPWmlqUlY4UkV0dXNFZkZrY05XK1pob3A5clhM?= =?utf-8?B?MFIrNzVxL0xPU0ZlWWV1dysvQWVJaEQ5ZDZPL051VWNad3NZV0oyNHJwMWpw?= =?utf-8?B?MGZ2U0JyYUZLVzJWalFLNXV3L3FWQ0VNbFoyQ0l2VmE3aU9MZU50S1VKeGEr?= =?utf-8?B?V0VkMHFuckNDUUFvTldBeFhocUxOY3BWOGdiRVZhWTNzSkxwOHZHVDhhWGlW?= =?utf-8?B?NkU3T3hkdmhITGd2REdVN0RIQnArSlVEU0JURHJ4OFZCWjZMaHdQWSt2a0dn?= =?utf-8?B?d1krY2QwdnBZWXUwS2ZlRFh4KzB5a0VKRVRJOWNGNHR3US96Zml3TWNTSmx3?= =?utf-8?B?a2NrWTkxOFdiQnlBZDFoU1cyM2FCWGt1ZkZVUnlYUGI3WDZTczQ2dmZPY2FW?= =?utf-8?B?RDE3UjErVW1Ld1FLdkI3YWZKSjRhbFdCOUp6RnFFSG4yUVZOWmwwY2N2QWFO?= =?utf-8?B?dFdUZlM5UlNYVDgzeHVXT1lLblVOM3pMWE5HalUwMjdTSG9pUEl2U0NoQldE?= =?utf-8?B?NkdNajRJdGxuSVEzMkJPS1V3OU5HMUkrK3BmRkZOQmZ4UG9wSXhFUjJ5VkNH?= =?utf-8?B?WTdmNDY0dkVScEhYM0w1VUNRV25oa1U0VGdkR1ZJSHdINjJENUpXdGNpVG5z?= =?utf-8?Q?jTVcuwRSp+f9s5Uo=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 821c72ce-cf09-449c-5f10-08df093261ab X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2026 20:40:10.2448 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Fo0/DIeMCP3h4LjQZg070u3NjwdYSMSd8dhFZxqwRwHwQOmbgCHyxDjRvYwLbgQBO0X+DsiVoHxWphv5mcfiFfvrbX6bDHoRMRrUCibMIm0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH9PR03MB554594 X-purgate-ID: tlsNG-ef75cf/1788381613-3C817AE4-D290463B/0/0 X-purgate-type: clean X-purgate-size: 1590 On 02/09/2026 1:50 pm, Jan Beulich wrote: > On 02.09.2026 13:43, Andrew Cooper wrote: >> All this does is obfuscate the usage sites. > I don't mind these changes, yet I'd like to express that as so often there > are multiple ways of looking at things. The benefit of the macros was that > the use sites were textually shorter, and hence easier to process (assuming > you know what ADDR stands for). "assuming" is the whole problem, and what makes this obfuscation.  If it were a pattern we used everywhere, it would be fine, but it's unique to this header. It hides the width and volatility of the access, which variable is being referenced, and the indirection. The only thing it has going for it is that it is recognisable as "probably a macro", but you're still forced to look elsewhere to identify how it works. > >> --- a/xen/arch/x86/include/asm/bitops.h >> +++ b/xen/arch/x86/include/asm/bitops.h >> @@ -9,16 +9,6 @@ >> #include >> #include >> >> -/* >> - * We specify the memory operand as both input and output because the memory >> - * operand is both read from and written to. Since the operand is in fact a >> - * word array, we also specify "memory" in the clobbers list to indicate that >> - * words other than the one directly addressed by the memory operand may be >> - * modified. >> - */ > Might we not better keep this justification for the seemingly odd memory > clobbers? (The first sentence, otoh, I agree can be dropped.) I don't think it's useful to keep, but fine... ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Sep 02 22:10:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 22:10:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406253.1639614 (Exim 4.92) (envelope-from ) id 1x1t9i-000734-1L; Wed, 02 Sep 2026 22:10:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406253.1639614; Wed, 02 Sep 2026 22:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1t9h-00072v-S6; Wed, 02 Sep 2026 22:10:05 +0000 Received: by outflank-mailman (input) for mailman id 1406253; Wed, 02 Sep 2026 22:10:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1t9g-0006mx-Oy for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 22:10:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1t9g-00AohW-1Z for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 00:10:04 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a989e97-2eae-0a2a0a5409dd-0a2a450cc034-36 for ; Thu, 03 Sep 2026 00:10:03 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a989ebb-f479-0a2a450c0019-d155dd35e81d-3 for ; Thu, 03 Sep 2026 00:10:03 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-482e4998d28so1246626f8f.2 for ; Wed, 02 Sep 2026 15:10:03 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448e81718sm9019892f8f.16.2026.09.02.15.10.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 15:10:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788387003; x=1788991803; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=nKrZBUjvpE2EoYngFcru125MCNl+vKUvD8ycwT7RELk=; b=Illa36Dyermv+bbLRqCGfIJGYADDu0T118AVT/F4aufxIhLytJHKSBNVkf7b325dkl cYy7zGpQnksET5pHEoAKq4ESdjZms8G9XIcllywujJUeRWSou+Q5GyDTqUNlFLxUCD5W G3RTNJeEqp8IYraDbAEDXHTiZmw1bataitaMc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788387003; x=1788991803; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=nKrZBUjvpE2EoYngFcru125MCNl+vKUvD8ycwT7RELk=; b=ixz93bZbOOFWRC1vD8ZXpGIjyLZtpihuPud5dMItnj7GNwGaiH2oVFGkfKRLBognG1 DWbxm9G/BamQg3qTU2JVLtv4td2rf556dwekVja5pHzZAqaMEWIuveOYDx6gJb4J5fQI A3QC+UMRl1CEADjScykXdW2JFRz446XuPokWUxzxmSsX4CgmNXiPT3RAkR97lTI+zR00 SDBeWL5Jh9puyrp87pnjpQcu+VtmXfdgdn1ZFaQtMIMgOXpszJCiCvk27vRUSxCPP9Kg qlX+7oa8sKZ3GpPv/MdlqXLP0zEenzlHq9IK00ZovJQkk13E6xQy9XNuD2wYglFHOohl Ha8Q== X-Gm-Message-State: AFuF++mD3YthK28A5Nxi7P4cGBtV/zswg2bXi1lgOB8brVp7e9BLNJ+q vuUXcMHAjUeXvI4GCp922HOeOp4jV2w4p2l96yrppSfkw8FGQOkTQViT9r9XKGMouMf0kaL/L0r aY+pkzvw= X-Gm-Gg: AYBFou1ceVvXVyESIaUxNXz4YifDZ4B4600Np4riKBB1bjA4RmMziJusvLygZQnncB8 7zU9cH0FHPvvSdNQrbaBD+vBv/vqfN8+qZEHLxyIDd1OCRw9EggnTVjY9B9f3YyarTeFmI7zd/X CL3cLqasYn3CioRyoTQmwhysrrmG5sSJSrLpLrJy3V8bnCtM7TWnTXhkLDYGRreHsRN5i/28NbN sTsBnJQfufHTTYndvNwoUElF5rNGcDxDqhqlmyUYUsUjcNNzFEBeWprCi+qBGuKt3VHUH9Buzet OtScRjodv7P0kuPZs5jak54TFeD2g8A39FMpH7gw1R9pkHVtnApeMFnMd/o7QIOLnOndjs/qf29 kx32PKflKVOv4pNVUYdnUIQbp4I+Qq+WGxofIlIfEyc+HiOOXkls2a+6+S4wA6InMf/zo1r/EnK R93YjWW8sWlW9sVCd/psbDmE9M8z6igJ+rY4HF3wmOuOnYkmEkwATU4Q1nX6ufd3JKMyBG7YSpx Cy98YT8XtJc/vv3hdzGNcII+xYUmaZRlvjy35c= X-Received: by 2002:a05:6000:603:b0:484:3326:983b with SMTP id ffacd0b85a97d-48488f225d7mr12389571f8f.26.1788387003176; Wed, 02 Sep 2026 15:10:03 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98 Date: Wed, 2 Sep 2026 23:10:00 +0100 Message-Id: <20260902221000.2967167-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788387003-026DEA5B-4E3AF17D/0/0 X-purgate-type: clean X-purgate-size: 2415 Block loads which are known to hang the system. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie A more complete solution is in the works, but it's taken 4 months to get this much published... --- xen/arch/x86/cpu/microcode/intel.c | 31 ++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c index c45b00c6b033..2160befd3197 100644 --- a/xen/arch/x86/cpu/microcode/intel.c +++ b/xen/arch/x86/cpu/microcode/intel.c @@ -27,6 +27,7 @@ #include #include +#include #include #include #include @@ -273,6 +274,35 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) return false; } +static bool microcode_safe_to_load(const struct microcode_patch *mc) +{ + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); + + /* + * Treat pre-production as always safe - anyone using pre-production + * microcode knows what they are doing, and can keep any resulting pieces. + */ + if ( cpu_sig->rev < 0 || mc->rev < 0 ) + return true; + + /* + * GNR98. Granite Rapids systems hang when loading new ucode on + * sufficiently old firmware. + */ + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && + cpu_sig->rev < 0x01000405 && + mc->rev > 0x01000405 ) + { + printk_once(XENLOG_WARNING + "microcode: Granite Rapids erratum GNR98 detected. Skipping ucode 0x%08x\n" + "microcode: Firmware update recommended\n", mc->rev); + return false; + } + + return true; +} + static int cf_check intel_compare( const struct microcode_patch *old, const struct microcode_patch *new) { @@ -365,6 +395,7 @@ static struct microcode_patch *cf_check intel_ucode_parse( * one with higher revision. */ if ( microcode_fits_cpu(mc) && + microcode_safe_to_load(mc) && (!saved || compare_revisions(saved->rev, mc->rev) == NEW_UCODE) ) saved = mc; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 22:11:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 22:11:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406249.1639623 (Exim 4.92) (envelope-from ) id 1x1tBH-0007l6-Bk; Wed, 02 Sep 2026 22:11:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406249.1639623; Wed, 02 Sep 2026 22:11:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1tBH-0007ky-8j; Wed, 02 Sep 2026 22:11:43 +0000 Received: by outflank-mailman (input) for mailman id 1406249; Wed, 02 Sep 2026 22:01:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1t1h-0005fV-Tr for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 22:01:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1t1f-001aL0-3V for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 00:01:47 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a989cbc-bab6-0a2a0a5309dd-0a2a4508873c-24 for ; Thu, 03 Sep 2026 00:01:46 +0200 Received: from [178.154.239.136] (helo=forwardcorp1b.mail.yandex.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a989cc9-f659-0a2a45080019-b29aef88a604-3 for ; Thu, 03 Sep 2026 00:01:46 +0200 Received: from mail-nwsmtp-smtp-corp-main-34.sas.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-34.sas.yp-c.yandex.net [IPv6:2a02:6b8:c24:fa2:0:640:41ee:0]) by forwardcorp1b.mail.yandex.net (postfix) with ESMTPS id 6ECC882A58; Thu, 03 Sep 2026 01:01:45 +0300 (MSK) Received: from i101646577.yandex-team.ru (unknown [2a02:6bf:8080:b7b::1:1e]) by mail-nwsmtp-smtp-corp-main-34.sas.yp-c.yandex.net (smtpcorp) with ESMTPSA id f1tkLusaZGk0-kej65A7h; Thu, 03 Sep 2026 01:01:44 +0300 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=default header.d=yandex-team.ru header.i="@yandex-team.ru" header.h="Message-ID:Date:Cc:Subject:To:From" X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1788386504; bh=A+W/ldisppAArTMWvfAGcpzZiNRw0eu+MP0v6kAy3u0=; h=Message-ID:Date:Cc:Subject:To:From; b=Wi6gm59NEzp2vo7igIP4wMGOBA5JDhwbMgbrmCQJcm26eEPACPo8Ww+MQx0O2ajUo GNZaCnfFFBbXfipCVNPREbtQ0fB6sFs6QMzMRxoQ20BCDqYmxyGuO14q0wj8glRV3b yu3tGBD3zLmwI2yXUfey2ftjyUMIWWOnnEoEuHxs= Authentication-Results: mail-nwsmtp-smtp-corp-main-34.sas.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Daniil Tatianin To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: Daniil Tatianin <99danilt@gmail.com>, "H. Peter Anvin" , Steve Wahl , Justin Ernst , Kyle Meyer , Dimitri Sivanich , Russ Anderson , Juergen Gross , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Daniil Tatianin Subject: [PATCH] x86/apic: Remove dead disable_esr machinery Date: Thu, 3 Sep 2026 01:01:23 +0300 Message-ID: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788386506-D6F5F87B-67039CC5/0/0 X-purgate-type: clean X-purgate-size: 7462 From: Daniil Tatianin <99danilt@gmail.com> apic::disable_esr was a quirk for the 32-bit NUMA-Q, Summit, ES7000 and bigsmp platforms, which left the local APIC error status register alone because "something untraceable" produced bad interrupts on those machines. NUMA-Q, Summit and ES7000 went away in 2014 with commit b5660ba76b41 ("x86, platforms: Remove NUMAQ"), commit 7cf6c94591bb ("x86, apic: Remove support for IBM Summit/EXA chipset") and commit 58f5d2d44883 ("x86, apic: Remove support for ia32-based Unisys ES7000"), and the last setter went with commit 0abf508675c0 ("x86/smp: Drop 32-bit "bigsmp" machine support"). Every remaining APIC driver initializes the flag to zero. Remove the flag, the ESR setup bypass keyed on it and the 32-bit only ESR clearing hammer in setup_local_APIC(), which was gated on the same flag and therefore equally dead. No functional changes. Signed-off-by: Daniil Tatianin --- arch/x86/include/asm/apic.h | 3 +-- arch/x86/kernel/apic/apic.c | 20 -------------------- arch/x86/kernel/apic/apic_flat_64.c | 2 -- arch/x86/kernel/apic/apic_noop.c | 2 -- arch/x86/kernel/apic/apic_numachip.c | 4 ---- arch/x86/kernel/apic/probe_32.c | 2 -- arch/x86/kernel/apic/x2apic_cluster.c | 2 -- arch/x86/kernel/apic/x2apic_phys.c | 2 -- arch/x86/kernel/apic/x2apic_savic.c | 2 -- arch/x86/kernel/apic/x2apic_uv_x.c | 2 -- arch/x86/xen/apic.c | 2 -- 11 files changed, 1 insertion(+), 42 deletions(-) diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h index 9cd493d467d4..5025b8413799 100644 --- a/arch/x86/include/asm/apic.h +++ b/arch/x86/include/asm/apic.h @@ -285,8 +285,7 @@ struct apic { void (*send_IPI_all)(int vector); void (*send_IPI_self)(int vector); - u32 disable_esr : 1, - dest_mode_logical : 1, + u32 dest_mode_logical : 1, x2apic_set_max_apicid : 1, nmi_to_offline_cpu : 1; diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 90025451ace2..2b2a3d2d166e 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1402,17 +1402,6 @@ static void lapic_setup_esr(void) return; } - if (apic->disable_esr) { - /* - * Something untraceable is creating bad interrupts on - * secondary quads ... for the moment, just leave the - * ESR disabled - we can't do anything useful with the - * errors anyway - mbligh - */ - pr_info("Leaving ESR disabled.\n"); - return; - } - maxlvt = lapic_get_maxlvt(); if (maxlvt > 3) /* Due to the Pentium erratum 3AP. */ apic_write(APIC_ESR, 0); @@ -1527,15 +1516,6 @@ static void setup_local_APIC(void) value &= ~APIC_SPIV_APIC_ENABLED; apic_write(APIC_SPIV, value); -#ifdef CONFIG_X86_32 - /* Pound the ESR really hard over the head with a big hammer - mbligh */ - if (lapic_is_integrated() && apic->disable_esr) { - apic_write(APIC_ESR, 0); - apic_write(APIC_ESR, 0); - apic_write(APIC_ESR, 0); - apic_write(APIC_ESR, 0); - } -#endif /* * Intel recommends to set DFR, LDR and TPR before enabling * an APIC. See e.g. "AP-388 82489DX User's Manual" (Intel diff --git a/arch/x86/kernel/apic/apic_flat_64.c b/arch/x86/kernel/apic/apic_flat_64.c index e0308d8c4e6c..f65e82c6e750 100644 --- a/arch/x86/kernel/apic/apic_flat_64.c +++ b/arch/x86/kernel/apic/apic_flat_64.c @@ -37,8 +37,6 @@ static struct apic apic_physflat __ro_after_init = { .dest_mode_logical = false, - .disable_esr = 0, - .cpu_present_to_apicid = default_cpu_present_to_apicid, .max_apic_id = 0xFE, diff --git a/arch/x86/kernel/apic/apic_noop.c b/arch/x86/kernel/apic/apic_noop.c index 58abb941c45b..0661cb008459 100644 --- a/arch/x86/kernel/apic/apic_noop.c +++ b/arch/x86/kernel/apic/apic_noop.c @@ -54,8 +54,6 @@ struct apic apic_noop __ro_after_init = { .dest_mode_logical = true, - .disable_esr = 0, - .cpu_present_to_apicid = default_cpu_present_to_apicid, .max_apic_id = 0xFE, diff --git a/arch/x86/kernel/apic/apic_numachip.c b/arch/x86/kernel/apic/apic_numachip.c index a60c8960bbfd..27a9a5b33f63 100644 --- a/arch/x86/kernel/apic/apic_numachip.c +++ b/arch/x86/kernel/apic/apic_numachip.c @@ -210,8 +210,6 @@ static const struct apic apic_numachip1 __refconst = { .dest_mode_logical = false, - .disable_esr = 0, - .cpu_present_to_apicid = default_cpu_present_to_apicid, .max_apic_id = UINT_MAX, @@ -244,8 +242,6 @@ static const struct apic apic_numachip2 __refconst = { .dest_mode_logical = false, - .disable_esr = 0, - .cpu_present_to_apicid = default_cpu_present_to_apicid, .max_apic_id = UINT_MAX, diff --git a/arch/x86/kernel/apic/probe_32.c b/arch/x86/kernel/apic/probe_32.c index 87bc9e7ca5d6..00ee033ede14 100644 --- a/arch/x86/kernel/apic/probe_32.c +++ b/arch/x86/kernel/apic/probe_32.c @@ -41,8 +41,6 @@ static struct apic apic_default __ro_after_init = { .dest_mode_logical = true, - .disable_esr = 0, - .init_apic_ldr = default_init_apic_ldr, .cpu_present_to_apicid = default_cpu_present_to_apicid, diff --git a/arch/x86/kernel/apic/x2apic_cluster.c b/arch/x86/kernel/apic/x2apic_cluster.c index 7db83212effb..0c8257cfa3fa 100644 --- a/arch/x86/kernel/apic/x2apic_cluster.c +++ b/arch/x86/kernel/apic/x2apic_cluster.c @@ -232,8 +232,6 @@ static struct apic apic_x2apic_cluster __ro_after_init = { .dest_mode_logical = true, - .disable_esr = 0, - .init_apic_ldr = init_x2apic_ldr, .cpu_present_to_apicid = default_cpu_present_to_apicid, diff --git a/arch/x86/kernel/apic/x2apic_phys.c b/arch/x86/kernel/apic/x2apic_phys.c index 090647cc5a78..653ef67b42eb 100644 --- a/arch/x86/kernel/apic/x2apic_phys.c +++ b/arch/x86/kernel/apic/x2apic_phys.c @@ -129,8 +129,6 @@ static struct apic apic_x2apic_phys __ro_after_init = { .dest_mode_logical = false, - .disable_esr = 0, - .cpu_present_to_apicid = default_cpu_present_to_apicid, .max_apic_id = UINT_MAX, diff --git a/arch/x86/kernel/apic/x2apic_savic.c b/arch/x86/kernel/apic/x2apic_savic.c index 4bc6d7e018a5..f116dc7ecb01 100644 --- a/arch/x86/kernel/apic/x2apic_savic.c +++ b/arch/x86/kernel/apic/x2apic_savic.c @@ -394,8 +394,6 @@ static struct apic apic_x2apic_savic __ro_after_init = { .dest_mode_logical = false, - .disable_esr = 0, - .cpu_present_to_apicid = default_cpu_present_to_apicid, .max_apic_id = UINT_MAX, diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c b/arch/x86/kernel/apic/x2apic_uv_x.c index 42568ceec481..bc8709893676 100644 --- a/arch/x86/kernel/apic/x2apic_uv_x.c +++ b/arch/x86/kernel/apic/x2apic_uv_x.c @@ -758,8 +758,6 @@ static struct apic apic_x2apic_uv_x __ro_after_init = { .dest_mode_logical = false, - .disable_esr = 0, - .cpu_present_to_apicid = default_cpu_present_to_apicid, .max_apic_id = UINT_MAX, diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c index bb0f3f368446..23db95dd3411 100644 --- a/arch/x86/xen/apic.c +++ b/arch/x86/xen/apic.c @@ -117,8 +117,6 @@ static struct apic xen_pv_apic __ro_after_init = { /* .delivery_mode and .dest_mode_logical not used by XENPV */ - .disable_esr = 0, - .cpu_present_to_apicid = xen_cpu_present_to_apicid, .max_apic_id = UINT_MAX, -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 22:28:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 22:28:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406267.1639632 (Exim 4.92) (envelope-from ) id 1x1tRr-0001UD-Mw; Wed, 02 Sep 2026 22:28:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406267.1639632; Wed, 02 Sep 2026 22:28:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1tRr-0001U6-Ji; Wed, 02 Sep 2026 22:28:51 +0000 Received: by outflank-mailman (input) for mailman id 1406267; Wed, 02 Sep 2026 22:28:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1tRp-0001U0-UO for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 22:28:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1tRo-00AqoI-Kj for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 00:28:48 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98a2bb-2eae-0a2a0a5409dd-0a2a4507ee08-46 for ; Thu, 03 Sep 2026 00:28:48 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98a320-b4ea-0a2a45070019-d155802aec65-3 for ; Thu, 03 Sep 2026 00:28:48 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b0d8bc2aaso16068615e9.0 for ; Wed, 02 Sep 2026 15:28:48 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448e7315bsm9334035f8f.7.2026.09.02.15.28.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 15:28:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788388128; x=1788992928; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=h0F6Rl0EOuBQYSoHJasSlb1LYIqAoUFOni1obqAu3rw=; b=g/TDcFV7gHF37+Exm8Yn6ZvetLkPw/ILfK3nLMsstlv8jYlydYjoWi690TNAEtVG6n eTu8rmf1Efoech066sTw59VFVifg7OKWqnrYmXkhAH1Y3JdAXaE6Rkt1XK5SQSKkCd9O TX0BxnlfHgmvHmLRcmXc4yFPf1pswHNSQ8X00= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788388128; x=1788992928; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=h0F6Rl0EOuBQYSoHJasSlb1LYIqAoUFOni1obqAu3rw=; b=pSlHZNGYM0UG+frtv6O8OmmRAGqhkRDP0gdTmIIC+PWf29140hR5S2zx/7tUk4Lji+ CX8mQwtHl9fHdFa1omNBNKMVoeFS3bmv75rVMe6IGAayzVC6ChY+1/syVE6z/nYXPCp1 x2h/LQbOPYwYZHno8sDQSBJ4jzvrTm/dPm/w4+M77B2whpYMlnQMNS3LCbf8+4w2XNAP YHhrOB1ruz8J5Yvy4hTCurGIX/KUvGNVTRwhA58XneR1FxOT7AjSEU0Bhc61kYnL+Km1 JKYxH8toDguWzIYtXdhnUiSGl/eMG/a/nKSRUxWArkOs8TezZFsyug22EJEgJK+TUckr ZV3w== X-Gm-Message-State: AFuF++kfYMicrB7v87VaxjtoktoKe2KlAs1WN+Ct54QuPz6E1c2DUZrc /Sgd72NHoAYUPq5qop4bQkEPAw+++1icLtSej1zOKvnpB2bwoQiQj4gBcvnMzQb8eCcHpuiX6go 5TjkEla4= X-Gm-Gg: AYBFou0GXSrunhO/B/GI2EkFFDUHXDxCuVkllEFmAj1DRpXkPWQnOf0yf31bsmXixJM Rj/Ibgdof3flxScsRjv4iY+pO35euXt1yi8VAviWDEA6k03Mn4iXKEfD11k21pXFhqi5uuer15y sl3SbRKLNh79MVNVH9t0G8gr4i/Q02Mq3qxoX8b4wxRojAFR3/JNOWkNW2omhtQDwYYjkmO0zet r68wqX8xz+AWFEjVbngcNixIg9+jWJirbMjNW43w8/AED4ikUQXq3hajZ69tqMHSGO6NMRxgPex LU6tWiU0LYS2wFztXAElsp31DsMdvlbyVa+k76gY4gfWDjPc6IHY3HV72dAeXC4aOOdQqnyDDRy 2c82k3KzDC0+dZBBeSe1zFsI5AVXXEAarhyQva96tHEDbSQxAzRGifpCaDsLbn/6mCn3USLQ13a /qaKy4UyHdj3wLe4k+re/F8eauzf4eGEhuKXSjXG2R0zebaIKdohpcWkJsrQ/flv8OVhhXKK2k9 GFkBJg8kkD2jdcSxeAHvDB5h6yAFdKTRUB7Qxc= X-Received: by 2002:a05:600c:c490:b0:499:60bf:c6f7 with SMTP id 5b1f17b1804b1-49ce581f1ccmr116425215e9.13.1788388127890; Wed, 02 Sep 2026 15:28:47 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/pci: Perform XSM checks on the correct device in pci_conf_write_intercept() Date: Wed, 2 Sep 2026 23:28:46 +0100 Message-Id: <20260902222846.2977800-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788388128-A76D2AE4-251DB5BF/0/0 X-purgate-type: clean X-purgate-size: 1966 The requested PCI segment needs including in the call to xsm_pci_config_permission(). Otherwise in a multi-segment system we can check the perimssions on one device but operate on a different one. This is only not a vulnerability because pci_conf_write_intercept() is only reachable by the hardware domain. Fixes: 300bb048ca31 ("x86/PCI: make all config space writes subject to XSM checking") Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Daniel P. Smith --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie CC: Daniel P. Smith This was going to be an XSA before realising that the scope was limited to the hardware domain. --- xen/arch/x86/pci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c index 1aefeab66301..4c279875517b 100644 --- a/xen/arch/x86/pci.c +++ b/xen/arch/x86/pci.c @@ -76,8 +76,9 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf, unsigned int reg, unsigned int size, uint32_t *data) { + pci_sbdf_t sbdf = PCI_SBDF(seg, bdf); struct pci_dev *pdev; - int rc = xsm_pci_config_permission(XSM_HOOK, current->domain, bdf, + int rc = xsm_pci_config_permission(XSM_HOOK, current->domain, sbdf.sbdf, reg, reg + size - 1, true); if ( rc < 0 ) @@ -93,7 +94,7 @@ int pci_conf_write_intercept(unsigned int seg, unsigned int bdf, pcidevs_lock(); - pdev = pci_get_pdev(NULL, PCI_SBDF(seg, bdf)); + pdev = pci_get_pdev(NULL, sbdf); if ( pdev ) rc = pci_msi_conf_write_intercept(pdev, reg, size, data); base-commit: d5d126a225e78071fbb5db126744bc2a36d511df -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Sep 02 22:52:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 22:52:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406277.1639640 (Exim 4.92) (envelope-from ) id 1x1toX-0005sh-Dt; Wed, 02 Sep 2026 22:52:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406277.1639640; Wed, 02 Sep 2026 22:52:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1toX-0005sa-Aw; Wed, 02 Sep 2026 22:52:17 +0000 Received: by outflank-mailman (input) for mailman id 1406277; Wed, 02 Sep 2026 22:52:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1toV-0005sT-C1 for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 22:52:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1toU-000LwR-4Y for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 00:52:14 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98a897-e002-0a2a0a5209dd-0a2a4508cebc-4 for ; Thu, 03 Sep 2026 00:52:09 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98a893-f659-0a2a45080019-b9ff1c22904b-3 for ; Thu, 03 Sep 2026 00:52:04 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a064527434000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 02 Sep 2026 22:52:00 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 58DB885EC7; Thu, 3 Sep 2026 00:51:59 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=CK3C5Y/18iCVBZZ2hyVX1QpYXrpr0vXywX4Tj/6spNA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=AqTvYXEXmpkZPXF8XlTSxFUNJwZFj+rz5ZdFizLzV97UzCAWmxaJKsIpcsKhYmbQZi/yQguo/ Zgrv9CkYtOwoGWL5X8qWmfRsB8NLgM1mae+e40hMwlh2gQVc0V1s1Xbx3kzMx13SHiR7fIQ3ka/ x9TS374YeK8Wx9o2qMHF6mHTdaHH4mNcYSBSpuRSfnAWLKbZ6JGzbJCSlE/TO6wJvttgZT3M2j8 KPaCNTD0Do7fpDd39IImIdaD6Pc2v/S6IVYTcVlyPYWp5NR1BOsIGXM0mD5soTf/ZupYgerrp6v GOxlsNI8DDS9lxKaMsUdcIIgmrqhsCIw+xOzhu6Z2Q1Q== X-Zone-Loop: a9b0216049483c9c8b228e1296ce4d931935d9cd03a6 x-campaign-type: default x-transaction-id: d23813cd-44b0-4b8e-80bf-3b2bbeedd875 x-swg-uid: 01-b2dc0ef8-bc52-46df-ad58-43f01a3e51ab X-Mailer: Sweego Message-ID: <1788389520.8631fc262581453bbf619ec5b2062170.1a064527434000c4f3@vates.tech> x-swg-bid: 1788389520.8631fc262581453bbf619ec5b2062170.1a064527434000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 3 Sep 2026 00:51:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper , Xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260902221000.2967167-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902221000.2967167-1-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6H4PmcArdL9dnUggMSTVkPNg" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788389519471 X-purgate-ID: tlsNG-c1860d/1788389529-CE94287B-481F807C/0/0 X-purgate-type: clean X-purgate-size: 8696 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6H4PmcArdL9dnUggMSTVkPNg Content-Type: multipart/mixed; boundary="------------djJmaOhfXGhknmtRNdhkEBtR"; protected-headers="v1"; hp="clear" Message-ID: <2c2c2043-82be-458d-99cc-102f78b93c61@vates.tech> Date: Thu, 3 Sep 2026 00:51:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper , Xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260902221000.2967167-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260902221000.2967167-1-andrew.cooper3@citrix.com> --------------djJmaOhfXGhknmtRNdhkEBtR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDMvMDkvMjAyNiDDoCAwMDoxNCwgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBC bG9jayBsb2FkcyB3aGljaCBhcmUga25vd24gdG8gaGFuZyB0aGUgc3lzdGVtLg0KPiANCj4g U2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4NCj4gLS0tDQo+IENDOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IEND OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlckB4ZW5wcm9qZWN0Lm9yZz4NCj4gQ0M6IFRlZGR5 IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0KPiANCj4gQSBtb3JlIGNvbXBsZXRl IHNvbHV0aW9uIGlzIGluIHRoZSB3b3JrcywgYnV0IGl0J3MgdGFrZW4gNCBtb250aHMgdG8g Z2V0IHRoaXMNCj4gbXVjaCBwdWJsaXNoZWQuLi4NCj4gLS0tDQo+ICAgeGVuL2FyY2gveDg2 L2NwdS9taWNyb2NvZGUvaW50ZWwuYyB8IDMxICsrKysrKysrKysrKysrKysrKysrKysrKysr KysrKw0KPiAgIDEgZmlsZSBjaGFuZ2VkLCAzMSBpbnNlcnRpb25zKCspDQo+IA0KPiBkaWZm IC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdS9taWNyb2NvZGUvaW50ZWwuYyBiL3hlbi9hcmNo L3g4Ni9jcHUvbWljcm9jb2RlL2ludGVsLmMNCj4gaW5kZXggYzQ1YjAwYzZiMDMzLi4yMTYw YmVmZDMxOTcgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWljcm9jb2RlL2lu dGVsLmMNCj4gKysrIGIveGVuL2FyY2gveDg2L2NwdS9taWNyb2NvZGUvaW50ZWwuYw0KPiBA QCAtMjcsNiArMjcsNyBAQA0KPiAgICNpbmNsdWRlIDx4ZW4vc3RyaW5nLmg+DQo+ICAgI2lu Y2x1ZGUgPHhlbi94bWFsbG9jLmg+DQo+ICAgDQo+ICsjaW5jbHVkZSA8YXNtL2ludGVsLWZh bWlseS5oPg0KPiAgICNpbmNsdWRlIDxhc20vbXNyLmg+DQo+ICAgI2luY2x1ZGUgPGFzbS9w cm9jZXNzb3IuaD4NCj4gICAjaW5jbHVkZSA8YXNtL3N5c3RlbS5oPg0KPiBAQCAtMjczLDYg KzI3NCwzNSBAQCBzdGF0aWMgYm9vbCBtaWNyb2NvZGVfZml0c19jcHUoY29uc3Qgc3RydWN0 IG1pY3JvY29kZV9wYXRjaCAqbWMpDQo+ICAgICAgIHJldHVybiBmYWxzZTsNCj4gICB9DQo+ ICAgDQo+ICtzdGF0aWMgYm9vbCBtaWNyb2NvZGVfc2FmZV90b19sb2FkKGNvbnN0IHN0cnVj dCBtaWNyb2NvZGVfcGF0Y2ggKm1jKQ0KPiArew0KPiArICAgIHN0cnVjdCBjcHVfc2lnbmF0 dXJlICpjcHVfc2lnID0gJnRoaXNfY3B1KGNwdV9zaWcpOw0KPiArDQo+ICsgICAgLyoNCj4g KyAgICAgKiBUcmVhdCBwcmUtcHJvZHVjdGlvbiBhcyBhbHdheXMgc2FmZSAtIGFueW9uZSB1 c2luZyBwcmUtcHJvZHVjdGlvbg0KPiArICAgICAqIG1pY3JvY29kZSBrbm93cyB3aGF0IHRo ZXkgYXJlIGRvaW5nLCBhbmQgY2FuIGtlZXAgYW55IHJlc3VsdGluZyBwaWVjZXMuDQo+ICsg ICAgICovDQo+ICsgICAgaWYgKCBjcHVfc2lnLT5yZXYgPCAwIHx8IG1jLT5yZXYgPCAwICkN Cg0KY3B1X3NpZy0+cmV2IGNhbid0IGJlIG5lZ2F0aXZlIGFzIGl0J3MgdW5zaWduZWQgaW50 Lg0KSSBndWVzcyB0aGF0J3Mgc29tZXRoaW5nIHRvIGZpeCBpbiBvdXIgc3RydWN0IGNwdV9z aWduYXR1cmUgYW5kIGhvdyB3ZSANCmdldCBpdC4gVGhvdWdoIHRoZSBzdHJ1Y3R1cmUgaXMg c2hhcmVkIHdpdGggQU1ELCBhbmQgSSBkb24ndCBrbm93IGlmIGl0IA0KYWxzbyB1c2VzICJu ZWdhdGl2ZSIgcmV2aXNpb25zIGZvciBub24tcHJvZHVjdGlvbiB1Y29kZSAoUFBSIGRvZXNu J3QgDQp0ZWxsIGFueXRoaW5nIGluIHRoYXQgcmVnYXJkKS4NCg0KPiArICAgICAgICByZXR1 cm4gdHJ1ZTsNCj4gKw0KPiArICAgIC8qDQo+ICsgICAgICogR05SOTguICBHcmFuaXRlIFJh cGlkcyBzeXN0ZW1zIGhhbmcgd2hlbiBsb2FkaW5nIG5ldyB1Y29kZSBvbg0KPiArICAgICAq IHN1ZmZpY2llbnRseSBvbGQgZmlybXdhcmUuDQo+ICsgICAgICovDQo+ICsgICAgaWYgKCBi b290X2NwdV9kYXRhLnZmbSA9PSBJTlRFTF9HUkFOSVRFUkFQSURTX1ggJiYNCj4gKyAgICAg ICAgIGJvb3RfY3B1X2RhdGEuc3RlcHBpbmcgPT0gMSAmJiAoY3B1X3NpZy0+cGYgJiAweDk1 KSAmJg0KPiArICAgICAgICAgY3B1X3NpZy0+cmV2IDwgMHgwMTAwMDQwNSAmJg0KPiArICAg ICAgICAgbWMtPnJldiAgICAgID4gMHgwMTAwMDQwNSApDQo+ICsgICAgew0KPiArICAgICAg ICBwcmludGtfb25jZShYRU5MT0dfV0FSTklORw0KPiArICAgICAgICAgICAgICAgICAgICAi bWljcm9jb2RlOiBHcmFuaXRlIFJhcGlkcyBlcnJhdHVtIEdOUjk4IGRldGVjdGVkLiAgU2tp cHBpbmcgdWNvZGUgMHglMDh4XG4iDQo+ICsgICAgICAgICAgICAgICAgICAgICJtaWNyb2Nv ZGU6IEZpcm13YXJlIHVwZGF0ZSByZWNvbW1lbmRlZFxuIiwgbWMtPnJldik7DQo+ICsgICAg ICAgIHJldHVybiBmYWxzZTsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICByZXR1cm4gdHJ1ZTsN Cj4gK30NCj4gKw0KPiAgIHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW50ZWxfY29tcGFyZSgNCj4g ICAgICAgY29uc3Qgc3RydWN0IG1pY3JvY29kZV9wYXRjaCAqb2xkLCBjb25zdCBzdHJ1Y3Qg bWljcm9jb2RlX3BhdGNoICpuZXcpDQo+ICAgew0KPiBAQCAtMzY1LDYgKzM5NSw3IEBAIHN0 YXRpYyBzdHJ1Y3QgbWljcm9jb2RlX3BhdGNoICpjZl9jaGVjayBpbnRlbF91Y29kZV9wYXJz ZSgNCj4gICAgICAgICAgICAqIG9uZSB3aXRoIGhpZ2hlciByZXZpc2lvbi4NCj4gICAgICAg ICAgICAqLw0KPiAgICAgICAgICAgaWYgKCBtaWNyb2NvZGVfZml0c19jcHUobWMpICYmDQo+ ICsgICAgICAgICAgICAgbWljcm9jb2RlX3NhZmVfdG9fbG9hZChtYykgJiYNCj4gICAgICAg ICAgICAgICAgKCFzYXZlZCB8fCBjb21wYXJlX3JldmlzaW9ucyhzYXZlZC0+cmV2LCBtYy0+ cmV2KSA9PSBORVdfVUNPREUpICkNCj4gICAgICAgICAgICAgICBzYXZlZCA9IG1jOw0KPiAg IA0KDQpUaGUgcmVzdCBsb29rcyBnb29kIHRvIG1lOyBhcyBteSBjb25jZXJuIGlzIHVucmVs YXRlZCB0byBjaGFuZ2UgaXRzZWxmIA0KKGFuZCBkb2Vzbid0IGFmZmVjdCBwcm9kdWN0aW9u IG1pY3JvY29kZSBhbnl3YXkpLg0KDQpSZXZpZXdlZC1ieTogVGVkZHkgQXN0aWUgPHRlZGR5 LmFzdGllQHZhdGVzLnRlY2g+DQo= --------------djJmaOhfXGhknmtRNdhkEBtR-- --------------6H4PmcArdL9dnUggMSTVkPNg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqYqI4FAwAAAAAACgkQZg+p0QLLz9AZ NQv9GFZMFc2AqqtktECnLNJb0D4mSMPyfhlpXITLNC3RUixrkOgjeAD41J5gNn3SfbEsBXKtdEoS b5BAb1oieWyoXOIBFF+vg0NYT2Zw7QKekPwF3jVzuIfctpGogvGC5fGM89R9hH0J60RwU8SX9j5g p7m13XaOUAMkjZ4lP6Jzz2qCFjc8kUDNgtqfU7hoCpFfayrfRMkhHL1JeuS4BNULE7F9vH1hzTrv VODVTnXSLU6dlUSUdPt9KXIMw0NRinMMGDekHq+6HsonVHNAnYU6flWsfgz49Reg1BLVM3F+gwSF qEcy9IKW7nOGm6dFvj3SapgRc448rs5hil8hSrt0ETslr4H/k2cI594pq3CNtWSqMqJuQemG9//g BLD0SSr5XJrsElX/Oq9ZIFY39xI81ISFoxTm40XeO61YOoyaAEu3GHWbafqYMSLrneVfrG3nj8My mXN2ABW/RD/0t6V3N5a8/+9IQpy5qHzjHGS0r7RNl4z9jvtiq63oWHjYmkSx =9Sy2 -----END PGP SIGNATURE----- --------------6H4PmcArdL9dnUggMSTVkPNg-- From xen-devel-bounces@lists.xenproject.org Wed Sep 02 23:59:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 02 Sep 2026 23:59:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406297.1639650 (Exim 4.92) (envelope-from ) id 1x1ur4-0005ud-7q; Wed, 02 Sep 2026 23:58:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406297.1639650; Wed, 02 Sep 2026 23:58:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1ur4-0005uW-4R; Wed, 02 Sep 2026 23:58:58 +0000 Received: by outflank-mailman (input) for mailman id 1406297; Wed, 02 Sep 2026 23:58:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1ur3-0005uQ-Lj for xen-devel@lists.xenproject.org; Wed, 02 Sep 2026 23:58:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1ur2-004I79-2V for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 01:58:56 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98b814-bab6-0a2a0a5309dd-0a2a450ce478-8 for ; Thu, 03 Sep 2026 01:58:56 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98b83f-f479-0a2a450c0019-416d716c8af4-3 for ; Thu, 03 Sep 2026 01:58:55 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id D19CE40E02C2; Wed, 2 Sep 2026 23:58:54 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jG-GqP5vWJ92; Wed, 2 Sep 2026 23:58:44 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id EDC6240E027F; Wed, 2 Sep 2026 23:58:27 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=fail header.s=alien8 header.d=alien8.de header.i="@alien8.de" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=fail (4096-bit key) reason="fail (body has been altered)" header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1788393524; bh=+jWmLQ4BfUUKZhN5+qVeHxA0IEBsmEBT9F0I2pHfjyk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d4bG1cCB94QPj0niyzXG8MNmgx3y3WOEuXe9C3t69kjXgtKUnMe6Hey+5Hk48TPVY MmaaTKTEhZK7KZZJeP53hr24rIYJVuS9qYLSvkcyLBiw/XMFuXZl20ErnXEMYp2zLZ NnqHeREW9WsvHr9BgMrSDSewEXHykF92bpAlOCF53fB5bGlfME2wZ4ynQf/tZJ+8Fe kvVhBBbL6woidJziqW8+YT28wcVvcA95GVDQUywbs54huukI2vLQ1vufc0OQPbm0un +yFvEA9bknSj/+bvRL7+ZLiFH9M7p6UQCSWTzq3GyGUxSB32i0durPFqQ4Cq86yiwZ sTxhnWDkVzaOLuzTTdc6Tt5/gyzk9TO0k4obCOvZFNpn4P5y5wA7FI8eobqYVPTMBM EyvxibscDFmhmLWDgAk/jd9jvhkOZXvmZh4bJVsJVRrsm52k2/GqmlT5YgrERwLUiy 76roRpxt1xTRzBZpOeOfWKGtUXRD/jPhPzx5uEVsBTnnmKo+2sg7meOvfSfFm2imxP hlRh9Gpg5cSepG0d1NkOIHoCrzJuoh4ifzQcVoFqFyMGG2b/PWKEMCDKDn2is3Svrx 84IV3lzud+919ADjMiLvWVeo44N7+oCnf+xUfhsWFS5yRvk+UrbD7sv1S4taWDRDLs JkBMFI46WOwdIoMhyKJrRm2A= Date: Wed, 2 Sep 2026 16:58:24 -0700 From: Borislav Petkov To: Michael Matz Cc: Mauricio Faria de Oliveira , Richard Biener , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() Message-ID: <20260902235824.GFapi4ICSFCUiPSWVG@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1788393535-766DEA5B-EA041612/0/0 X-purgate-type: clean X-purgate-size: 1922 On Wed, Sep 02, 2026 at 03:29:44PM +0200, Michael Matz wrote: > Strictly speaking, on x86, the '=3D@ccXY' constraints are register outp= uts=20 > into normal random integer registers (though they are of course=20 > initialized in a funny way), while the 'cc' clobber is not a register a= t=20 > all, but rather a fuzzy idea of "state" in old cc0-based compilers (whi= ch=20 > the x86 backend isn't anymore since, ... well, about forever, 1999). A= s=20 > such they both really don't conflict and ... >=20 > > But then I'd expect that gcc would enforce that. I know it can't have= it=20 > > when the clobbers contain input or output regs: > >=20 > > In function =E2=80=98__memcmp=E2=80=99, > > inlined from =E2=80=98main=E2=80=99 at memcmp.c:25:6: > > memcmp.c:11:9: error: =E2=80=98asm=E2=80=99 operand has impossible co= nstraints or there are not enough registers > > 11 | asm volatile("test %3, %3\n\t" > > | ^~~ > >=20 > > but with "cc" clobbers it works. >=20 > ... hence there's nothing to report.=20 Aaaha, so the enforcement is solely documentation-based. :-) > In fact what an explicit 'cc' clobber once meant in cc0 backends (that > indiscriminated flag "state") is manufactured by the non-cc0 backends (= all > of them now) automatically whenever an asm has no flag output constrain= ts at > all. (On x86 that means it adds the "flags" register (internal name fo= r the > collection of flag status bits) to the clobber set automatically when t= here > are no =3D@ccXY constraints). >=20 > You can regard all 'cc' clobbers as pure source compatibility, they hav= e=20 > no meaning anymore. But as they are so ubiquitous (even in our own doc= u),=20 > they remain recognized. Ah ok, I see. so we'll simply forget them. Thanks Micha! --=20 Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Thu Sep 03 00:02:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 00:02:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406306.1639658 (Exim 4.92) (envelope-from ) id 1x1uu6-000890-7P; Thu, 03 Sep 2026 00:02:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406306.1639658; Thu, 03 Sep 2026 00:02:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1uu6-00088t-4C; Thu, 03 Sep 2026 00:02:06 +0000 Received: by outflank-mailman (input) for mailman id 1406306; Thu, 03 Sep 2026 00:02:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1uu3-00088Z-G5 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 00:02:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1uu2-005Vj6-Or for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 02:02:02 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98b8ea-8faa-0a2a0a5109dd-0a2a4503b54c-14 for ; Thu, 03 Sep 2026 02:02:02 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98b8fa-fae8-0a2a45030019-416d716c9ed6-3 for ; Thu, 03 Sep 2026 02:02:02 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id EEE2340E027F; Thu, 3 Sep 2026 00:02:01 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zOm-ALuwUT36; Thu, 3 Sep 2026 00:01:52 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 38A5740E016C; Thu, 3 Sep 2026 00:01:35 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1788393712; bh=4IXlQHsFzyYYmBoAO8JkyrUh/FaLtn8cSNtt98cWPCs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=D4ycekOh9nFddyT3xYovjLl+9n/5GpQAwZAaLHsBu2LdD/ckNO6uvomUTXRhSfDot g50QK8yvxH+hzcEZES9PIf9B/cGuSpXMxmYGK+/fAut2ZMC5il0LuFbE1TvQGTPUUZ a2ZmDg3mZzjAbZX2ygOLxIQG6tLRCTNAO93O3PgFHoeH8gcYnzsvi8l6I/VyblxpTe oMvckUCteRmBNHvCNL3r2x0oAMFrWTHuLctsilE90m2s97cYEInPCIOBwzcznJeQ8K bN+aWumHgEAh0iJZxmEJJQM5I6FXrz+nkk8S8BZqkBq5APu+24YV20LgF7lOp+kkQl HjiiMhfbRBjfCRhbKaoiidwb0lUZAcIGR1NCqbxmQfMYrfw3p/8evU0Qze+OH2eXqC y3tVRX9WREXjYxl4QtLzSiDA/4yO1eVDiB3RwgLqHiKBuVAIwBU2eynDmsiM+YMNBE 9wfKiIfScHM+GnDuF4/c/G75DrBHAUAC4R+fD7QLtux7yfL32rtKBqoqYQz3NtiFoe xrTs2HYgALrpp/QISUMuRgHdLsMDkNQ1LcXV/nQvwwEKQHD/K6JSxgwA5sFK1G0F7z yeKWOc2WVRWAPVDTzMKuGfgs+OylP9NdrFXeVNxOHe3aJgn52ySIg6k/aSwOBYyGoW Dfb4ubLZb6GOtdVx+CvgclsA= Date: Wed, 2 Sep 2026 17:01:32 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Michael Matz , Richard Biener , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() Message-ID: <20260903000132.GGapi43JjGh-8sj65Q@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> <05896397667d66a2969259298bcebb7f@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <05896397667d66a2969259298bcebb7f@igalia.com> X-purgate-ID: tlsNG-33051d/1788393722-766FB4E9-313FD626/0/0 X-purgate-type: clean X-purgate-size: 638 On Wed, Sep 02, 2026 at 10:48:14AM -0300, Mauricio Faria de Oliveira wrote: > Boris, I guess this may be added as clarification in the commit message. > Would you prefer another version with it? Yeah, I'd actually prefer it in the code itself so that we can find it easier. This file is as good as any. Something like this: /* * Summarized explanation that "cc" clobbers don't have a meaning * */ and leave the "cc" clobber there but commented out: /* "cc" ... */ so that we can grep for it easier later. Thanks! -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Thu Sep 03 00:07:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 00:07:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406316.1639668 (Exim 4.92) (envelope-from ) id 1x1uzX-0000UD-Qk; Thu, 03 Sep 2026 00:07:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406316.1639668; Thu, 03 Sep 2026 00:07:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1uzX-0000U6-MN; Thu, 03 Sep 2026 00:07:43 +0000 Received: by outflank-mailman (input) for mailman id 1406316; Thu, 03 Sep 2026 00:07:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1uzV-0000U0-Jt for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 00:07:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1uzV-00GcxU-0f for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 02:07:41 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98ba4a-2eae-0a2a0a5409dd-0a2a4506cebe-2 for ; Thu, 03 Sep 2026 02:07:39 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98ba4a-195a-0a2a45060019-d561b3388a56-3 for ; Thu, 03 Sep 2026 02:07:39 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x1uyy-00E6IP-4K; Thu, 03 Sep 2026 02:07:08 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x1uyx-00GOWm-B9; Thu, 03 Sep 2026 02:07:07 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x1uyx-00000005maZ-18xr; Thu, 03 Sep 2026 02:07:07 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=cmQEOzLtOK6G3QHIoxlsUO75VfltJ8r34O3qt0LsBwY=; b=Lu3R+Nwe9xNhYiSqjlmIy8VM9n xs/JIFHFwMmogdq8SHa/t4oYuVLRDGBgqGYD3CQZAwTMLrDJ50qyUhwkYM/DZ65eoGb2l2LsBHkM0 dzwK/TXD62oc9glyRER/Q+xxq94qpiLXRNYPSdrYZrmTjQJqCUd0M7DfgkuQLm7aujBmYjaRpGq8z eoNAu9gyzQyZ3Jve18b1Ro9whdIdsjptohjZDExoYwt26cC7D+a8qkW9YQby5hynDWRbtvSzxJ93I 6+dPTx4cxi3Yyajjto+3pJFXeYB9RjyDxolksiSMZO83tKSP7+V0PBomwu0DTaCP+na2cib84j3Qx QvlH8vFw==; MIME-Version: 1.0 Date: Wed, 02 Sep 2026 21:07:07 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Michael Matz , Richard Biener , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() In-Reply-To: <20260903000132.GGapi43JjGh-8sj65Q@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> <05896397667d66a2969259298bcebb7f@igalia.com> <20260903000132.GGapi43JjGh-8sj65Q@fat_crate.local> Message-ID: X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-16d1c6/1788394059-FCC0777B-40B7EAF7/0/0 X-purgate-type: clean X-purgate-size: 804 On 2026-09-02 21:01, Borislav Petkov wrote: > On Wed, Sep 02, 2026 at 10:48:14AM -0300, Mauricio Faria de Oliveira wrote: >> Boris, I guess this may be added as clarification in the commit message. >> Would you prefer another version with it? > > Yeah, I'd actually prefer it in the code itself so that we can find it easier. > This file is as good as any. > > Something like this: > > /* > * Summarized explanation that "cc" clobbers don't have a meaning > * > */ > > and leave the "cc" clobber there but commented out: > > /* "cc" ... */ > > so that we can grep for it easier later. > > Thanks! Sure, will do in the next version. The rest of this series is OK to you? I can wait for further feedback and combine it with this change. Thanks! -- Mauricio From xen-devel-bounces@lists.xenproject.org Thu Sep 03 00:39:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 00:39:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406328.1639677 (Exim 4.92) (envelope-from ) id 1x1vUQ-0005E4-3u; Thu, 03 Sep 2026 00:39:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406328.1639677; Thu, 03 Sep 2026 00:39:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1vUQ-0005Dx-1H; Thu, 03 Sep 2026 00:39:38 +0000 Received: by outflank-mailman (input) for mailman id 1406328; Thu, 03 Sep 2026 00:39:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x1vUO-0005Dr-Fw for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 00:39:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x1vUN-00CxA3-Ow for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 02:39:35 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a98c1c7-8faa-0a2a0a5109dd-0a2a450ac9c8-0 for ; Thu, 03 Sep 2026 02:39:35 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a98c1c7-f2d2-0a2a450a0019-416d716ce296-3 for ; Thu, 03 Sep 2026 02:39:35 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id B698040E02C2; Thu, 3 Sep 2026 00:39:34 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id udQ5OzAl84YC; Thu, 3 Sep 2026 00:39:25 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 0E48440E016C; Thu, 3 Sep 2026 00:39:07 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1788395964; bh=kdWp3DhJemViBu8ZFWfs12pKAz2JlnXNo53LRyH7ixI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FZhqPAQem8gqk0sXhssM2CHkBmYkNbRfO8skWN2H+rthvuEP6NciEwyl9kdedT6ac 4VQ7xyjE+FHpW9sSJom3uHv/j0u6LIJsZTsKxibCAljMQmQvYbyw4wcOcLCicgMplw NqfdSt2v/+tL/P+6rDaKJjRjxmR+GCXrnEsSH10zkmjuolrtPYFBl9YJkI0EBc7AFa j5bRPPcArDsDdRL3C3j3/HUcK8JF0SILGIMzGNqydpx0Khuz4IL6O3qkFkKDMqfGuK 8mjdzFW9YQ7XAsRrcVPTd3HAyRS/CgxqKGxpdgIt58Ni4CCYVCmrlrNOgPjxX7X62a 1mr9PEw1irlaHIXdNx5Y1KSSC2dOp5lfq5qvAeFumZhpytpDyKuQpkulgh6nrOpvzi BS7wQFdJlo8tLuiHDGxEBmbn5MElWBivNonTDmI8pXUkPLyoMHLxNjI7+x8BFRR9pj ffkR7uYezf5lh4/DeHcXH99eggRPRmTaWrZTDoZmIZIkVDG7w6pBn2E4jt0SKj3zvY sg5MiMBW1qAbVWipTDS9gJo5IcbgBdUWPzP6dBUahLx/uGfCnTCKwadDdG6KNsngaR k5oZ+U9+EHcjnelTbKJFgFtDwDgOJXlnM9Bs5DZwYTVkNOvfRHB14Z6CK7Om07DQm+ iOIMxNUOGjiys4M1+sddXZJE= Date: Wed, 2 Sep 2026 17:39:04 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Michael Matz , Richard Biener , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() Message-ID: <20260903003904.GIapjBqOSCSrg1e_tY@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> <05896397667d66a2969259298bcebb7f@igalia.com> <20260903000132.GGapi43JjGh-8sj65Q@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-4011c0/1788395975-4A9D9CFC-10B847B7/0/0 X-purgate-type: clean X-purgate-size: 336 On Wed, Sep 02, 2026 at 09:07:07PM -0300, Mauricio Faria de Oliveira wrote: > The rest of this series is OK to you? > I can wait for further feedback and combine it with this change. Please wait - I haven't gone through the rest. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Thu Sep 03 06:06:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 06:06:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406394.1639702 (Exim 4.92) (envelope-from ) id 1x20aG-0000oW-5y; Thu, 03 Sep 2026 06:06:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406394.1639702; Thu, 03 Sep 2026 06:06:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x20aG-0000oL-1b; Thu, 03 Sep 2026 06:06:00 +0000 Received: by outflank-mailman (input) for mailman id 1406394; Thu, 03 Sep 2026 06:05:59 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x20aF-0000oF-Cx for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 06:05:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x20aE-004w65-MF for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 08:05:58 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a990e2b-e002-0a2a0a5209dd-0a2a4508c4b6-44 for ; Thu, 03 Sep 2026 08:05:58 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a990e46-f659-0a2a45080019-d155802ee556-3 for ; Thu, 03 Sep 2026 08:05:58 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4957eefd361so13395945e9.1 for ; Wed, 02 Sep 2026 23:05:58 -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-49ce58da3acsm207632905e9.0.2026.09.02.23.05.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 23:05:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788415558; x=1789020358; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=G7fGb8I7IseYzuo6BTFI8ud86YzLworwvgMhQm/zQd8=; b=HwgH1qXn4TSSimPjlqsTNghdYeiifInSgJR/Mpx7fL0hSWirD/vcV/oG315kaQAzD8 JQwfYWUYPnYU6a/4rFjPJr/JoO1cUpYQLqB9RELceX9vy6kaXVVmfhUa2fx/PJX25Cby ZD1ZAbh+CVRIBm8GLcC5GanGzJ353Y5SGteQXRnQdAYKrmC3mFOlZ/G9yIpexX88sF0Q 2diNUCzyyKATslHtGMzeLwe+ALhuy91THbeBlpmaTTsrsqTHHhd6tExoeANOtnSna6Ii ljKl1y5mudTUr6jiZDAPUSnA60KaXo26GnsLttFvBXGLnXiI/nIjL9mUfOpgm9kRsILV PNEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788415558; x=1789020358; h=content-transfer-encoding:content-type: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:content-type; bh=G7fGb8I7IseYzuo6BTFI8ud86YzLworwvgMhQm/zQd8=; b=AHToZChS+XF01Eoy1+zre4zYHhouUKew90ZcaHFiHDVZvVob85BSPOgZlsVfbpBr7B UxESR4wo1zPDwaoBhVG0DzKQhyYV4Wt7nReqKRgW2lJOBZdwTUVtEW1N5JWgNHxGKENN zB87rGNx9ieTlJZqxydEyoQWt0ZZFSn3Xi3nhc06rI34JUumx4u6NvJmhGV9Exhg9Hmw 9/UFp65tw90mbNIgP4lGA4ghE3Wf+d0dDUwmiS/DfrXmSpN7HVE4UTU9qLizU61ystV8 2rs2qBAzjOwCpjKoTTBimz15bn55HzcNXbJkmOiWsOrTzAnm7OGnN0DTrz/z3Z3azVg5 aC8w== X-Gm-Message-State: AFuF++mjpUSLsQwkepeKCDevVajb/kmlyM+ZsLnLJfyErICsMOto/FYw ltnGvcEqXHyUjgNYjQbiD13NpnJXMCPvQevjzRxIurbmg2yckVAdm7V7QZQRlZ7WVg== X-Gm-Gg: AYBFou2YbZTUWaVbBtSwOvi0mnGf5PwWWaouEIohSX/Zyu5ej3CIuMcmnY0lwJsJNK+ 7T3eGoDEMVrmXKjRDctvkUyKWyMi1JlJSrAAC5h2YDPHkXVSvh3nEY8zLkbQbhG8WtoZX1qocDm gqrMPWIt8oQZDdQmJTp1X14ekkbkhTuxzmg9r2gfYhcnAwF/BJDvyx162REnjADqZTqcS1gEiGI XM+gEVed82TkeGB90siOLmi2FnvtUwb2wk1YJRQwFmn99Bm1HS24SFEx8ipT+OR7AkZgmg743s/ lVxMoTizKqTQ35/qH2SUTYH76uJ5gjkdBlJUwQz9O0qDW9E+TFb8jgSVVkGmYgubsH4l/6A15s+ C5oO59C9pA4jmXDfWD4vB1tCjdrvKvgse6vqOIVLKuzAsd+J98JN7aIA6oKZ07oMAM1ZBkct59Y vA/9+QHJ9VDa/XKixRybKNaKI5jGshGJbNJtSxIhTylVtOWVCI5ascCeZi+DxtCA+W42DdTBuFE vMFh95U/D3tDRA6hUuK/OJpsSOvjtUnDGGNmCDTxCjGcIt0M3AS2arqisOeQ3o= X-Received: by 2002:a05:600c:1914:b0:49c:d294:41e5 with SMTP id 5b1f17b1804b1-49ce581acaamr146419415e9.8.1788415557929; Wed, 02 Sep 2026 23:05:57 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 08:05:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 13/14] passthrough/PCI: rework (s,b,d,f) init of struct pci_dev To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <52dcd7cd-52db-4b59-90ef-f7cde79cf5bc@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: 8bit X-purgate-ID: tlsNG-c1860d/1788415558-D715E87B-627D8DAB/0/0 X-purgate-type: clean X-purgate-size: 1532 On 02.09.2026 17:07, Roger Pau Monné wrote: > On Wed, Sep 02, 2026 at 02:53:58PM +0200, Jan Beulich wrote: >> On 02.09.2026 14:44, Roger Pau Monné wrote: >>> On Wed, Sep 02, 2026 at 08:36:27AM +0200, Jan Beulich wrote: >>>> Right now we're casting away const-ness, to initialize the individual >>>> elements despite the field(s) being declared const. Eclair validly >>>> recognizes this as a Misra rule 11.8 violation. Hide this by switching to >>>> the use of memcpy(), deriving the destination address from the (mutable) >>>> struct pci_dev * which we hold in hands. >>>> >>>> No functional change intended. >>>> >>>> Signed-off-by: Jan Beulich >>>> --- >>>> Subsequently we may want to further leverage the sbdf local variable we >>>> now have in the function. Yet of course the primary question is: Is this >>>> an okay game to play in the first place? >>> >>> I've wondered the same, while this might be obfuscated enough for >>> Eclair to complain, aren't we still violating the spirit of the rule? >> >> We do, but what do you do without dropping that "const" (which I'd really >> like to keep), and without C++ concepts of initialization? > > Is it possible to "tag" this with a comment? Noting we are aware of > the MISRA violation, but the result of the field being const outweigh > the violation. Surely we could make up a SAF comment for this, just that SAF comments aren't liked by everyone either (personally I consider them ugly, but kind of tolerable). Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 06:28:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 06:28:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406407.1639710 (Exim 4.92) (envelope-from ) id 1x20vd-00047f-R9; Thu, 03 Sep 2026 06:28:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406407.1639710; Thu, 03 Sep 2026 06:28:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x20vd-00047Y-OM; Thu, 03 Sep 2026 06:28:05 +0000 Received: by outflank-mailman (input) for mailman id 1406407; Thu, 03 Sep 2026 06:28:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x20vd-00047P-57 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 06:28:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x20vc-006DtT-8x for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 08:28:04 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a991372-e002-0a2a0a5209dd-0a2a4501a192-4 for ; Thu, 03 Sep 2026 08:28:04 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a991373-5984-0a2a45010019-d155dd2fcd17-3 for ; Thu, 03 Sep 2026 08:28:04 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48441a2ba14so1784810f8f.1 for ; Wed, 02 Sep 2026 23:28:04 -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 ffacd0b85a97d-48448ed3840sm12120684f8f.17.2026.09.02.23.28.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 23:28:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788416883; x=1789021683; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=yTxpRBqDWMda19Nr+SUufVl8lNCypyYsmgFMvGkBNRU=; b=bmleMGj31QGq+hDHUq5skq9igrWDsoAFX/tIm68RSedncc5nBWIQHpEL7evHtAHNJI baDy4PhxgL/lQ9/lmgHAAproe4tGKnA9XAeQr0vAns+d+d70OAu133WtojDR/kruxziw X5tejHko7jEY/lUZOZoq4RQLR9z3ktuvb1C7gFqym1nf3krrZuo6EO253Sbc91w3YvAk vjkISdOl6EqPLw2aG96zeew6BUEL0UMKBmF+0GhjsHJ/cWRzQ8kIusueRyMQguHqNNuw 7o12TvFJk2iL9t/OAzf06QpSYWaX0YHebBu+ER7Y/qRPnxVM1ADUB8f8lWo76gnkuu9a b1KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788416883; x=1789021683; h=content-transfer-encoding:content-type: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:content-type; bh=yTxpRBqDWMda19Nr+SUufVl8lNCypyYsmgFMvGkBNRU=; b=mZRZf4bFsph+lii/ZwhnRGqBBH/3pd5E2uHaxEGe+YQvQwFB2ZcoUY9QEkH8LqUUeZ v12IDQl3mM2EQM1y8JOxSmaG/t4MBUMZiq43GPREOTSKUa904Nz/GQW21lC6ZoboNsVv jrqeKTkbDWvNdSbmvjH5q7btlyuVkBUtLNAIa51MhugUPs/dI0wcaOwYVI5oEFaEq1Sr yUlel3c1fSLcORM6B61iH5n6ruKyes66d1JUeH0EGhBuM5BodKQnz6aJqFiL9hy53jXF Z1zPj5GknI8+W6B45E2Wia0yKmzdaDhUZIpgpoxuwa2n/EOnB81UdoH9RUDLGSisP6hU Owig== X-Forwarded-Encrypted: i=1; AKwUvBxYZnZWSS2eBDTZnqPi9JFZUaD9wwuBaEUjGTQ0TYv6P5E+MdE9zwRF8jMQFa1n8v92oUvxVvxvTkQ=@lists.xenproject.org X-Gm-Message-State: AFuF++kWM2hBVqmnvQmtx7DW2sN512wBPiiU40ML0WvCbLMOk0V4esxX Vtb4ZuhgLr2gbJxMce/0X5gR5fooINsTUFxnc6vn4xdQHYL/tbd8zABdlQInB7MZGA== X-Gm-Gg: AYBFou2JYc6I4/Gtn/T8IGOpDHBEI6vojYn3BGXcYjlB3kdUeKulMIEX+G5bEV3bG+7 /gIFslEWmLL5kWGojPXiVHkFcYkR6voAKBy7iXwOl21/o7CcaFYh5iThU+qj37t2WIYjUL3qVYF jT738P++Wg/rxyrQN1x8++fbiQe5EA5NHG/zsJZhH7cYjspepnHzWJRv+YL4sg2ltRQPrgTlK0W ddMn9VIONyN9rjW1H0LKQo8rOM+b3KR4J1vi+XA1iZIoplGaVMlA/l1aeapE3ZhUOU+VQLygnjq sUieDXG/k67kEv1yuBlsz7xgugJcRVwg9SQKN7duAgkzjn/tlqz7tN+DNNRtgNviLgC+jydKJSA nxdmxcV/Ko0QVLUqCTIzjZTkduyiO8yQ0QEHaY6VKIqSS6sS5Ufo0/9OjHItXVf4ni3nh1CL1t0 c+6AMfJwiQccvvp0X5vOihl47bFKkF2siumNUq1LuAdKrKpTnNMEvtKnhYMUm6zxiRWuaJfj4DF SfckXsoaLHq9ShILbEOqq4ElgLzux6bNMlr0zLGXraAPCr7vmfM4SiEjBRDSM4= X-Received: by 2002:adf:e196:0:b0:484:3311:3703 with SMTP id ffacd0b85a97d-48488f222d6mr20416915f8f.26.1788416883587; Wed, 02 Sep 2026 23:28:03 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 08:28:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Teddy Astie , Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260902221000.2967167-1-andrew.cooper3@citrix.com> <1788389520.8631fc262581453bbf619ec5b2062170.1a064527434000c4f3@vates.tech> 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: <1788389520.8631fc262581453bbf619ec5b2062170.1a064527434000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788416884-1E07B757-13EDACF4/0/0 X-purgate-type: clean X-purgate-size: 817 On 03.09.2026 00:51, Teddy Astie wrote: > Le 03/09/2026 à 00:14, Andrew Cooper a écrit : >> @@ -273,6 +274,35 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) >> return false; >> } >> >> +static bool microcode_safe_to_load(const struct microcode_patch *mc) >> +{ >> + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); >> + >> + /* >> + * Treat pre-production as always safe - anyone using pre-production >> + * microcode knows what they are doing, and can keep any resulting pieces. >> + */ >> + if ( cpu_sig->rev < 0 || mc->rev < 0 ) > > cpu_sig->rev can't be negative as it's unsigned int. With that I'm surprised the compiler doesn't flag this as "condition is always false" or alike. Surely Misra isn't going to like it either. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 06:42:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 06:42:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406418.1639719 (Exim 4.92) (envelope-from ) id 1x2190-000711-Vr; Thu, 03 Sep 2026 06:41:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406418.1639719; Thu, 03 Sep 2026 06:41:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2190-00070u-T9; Thu, 03 Sep 2026 06:41:54 +0000 Received: by outflank-mailman (input) for mailman id 1406418; Thu, 03 Sep 2026 06:41:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x218z-00070o-Cy for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 06:41:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x218y-00BlJk-PY for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 08:41:52 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9916a3-2eae-0a2a0a5409dd-0a2a45039c4e-24 for ; Thu, 03 Sep 2026 08:41:52 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9916b0-fae8-0a2a45030019-d155802cc5eb-3 for ; Thu, 03 Sep 2026 08:41:52 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49b8ce9b733so14222305e9.1 for ; Wed, 02 Sep 2026 23:41:52 -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-49cf2531232sm18597005e9.7.2026.09.02.23.41.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 23:41:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788417712; x=1789022512; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=opHFwBmqlMiUcGGwdL5PLV8yTv+ErZ+I9vGrfTm88+4=; b=GCOPy7kZQVvI6xM/F0Igcyj3ZrKVDq9kZEX/hJ1VVOmmOE5bVcHHfDyz/ZNs/6U+l3 i31a8VL/l48nRoP4PkR+oWWwNRKOjcKOFEuwuwXng2JIVQQb3psArHmWoWO8UUebyGHI G4C4Mw9vU5WM9w+KW+gWo7gpqLCj2Sb/kTjMR/8SZo0tZepbVD+m+gBu8fxTJVDrq7fz BuTsL5Px65dfAomACT8ljOb1tHDw7+PH5zPccw+SbsmIoHtiww7Itya0CWWCtLbMGziQ n6w8bG3QvjyBZN5LlNA8SX8J7sQo/oC1wpoFQyMIFpzVNJA2XowEWVrw+hyiy7XJoxkB C8XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788417712; x=1789022512; h=content-transfer-encoding:content-type: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:content-type; bh=opHFwBmqlMiUcGGwdL5PLV8yTv+ErZ+I9vGrfTm88+4=; b=UYRmFHaCPhfYKTfteN/UfZWFTzVWz5aQ90UgrcqclyQUm/HFecSTpse4pZ9isf/OCL y7r8gCuL11zSULuGBLjZFXAegc23BJf3RK55pPnCOIxeho10NP4wLq9KJZDAG2zBLkSR 44fAQSoXI+mRkWgT98A/hEobcONmcFOrU3/GC7dGA3r5vW7umiASrKEg9eB4W7U8h6+D rlvh6cG2Pp/XqpmSg6gKDC3GleYwRMDyHaPnn7WNEErpJ4QpKKeyz0ZpoSkMXXFdE54G xFQ77phtJBSK7QP79mA6kO9pzvOrAg+clcpZ4UzazxPmUwxGAChOl3dssVPNYDST0LCW F19w== X-Forwarded-Encrypted: i=1; AKwUvBzS1amd78VOMqtWb0yUZDbL/uGmT1crIQZV9vn1vOvJ9LCvnN5liDlz/mGAtoaiJuniJ2pbdoX/WPE=@lists.xenproject.org X-Gm-Message-State: AFuF++kuWEei74KRvzlxArZMq1ngfwyYylq02x+QTep4XjYjgjk+W4dM 7o4guv/xgRGJO/3kZ1uyum/MuPPanRZ3E9ssK7z4aXerOBuLqR4HwL+WxWYY2Zj+3w== X-Gm-Gg: AYBFou0/D6RQ86EfwzCSh/fb644OCMTCLZv5InIAYTQXg2jVt25V1rtNuVlmco92RY9 tlcSyVsEnda/ggQIKkNYs35WdJBJPUUwUNywVBK1laujBEgoANpuOZtp7OHxjdyEfZffbmfdGF6 2HGFVjWwx6oej/iwGrA62IRJhEVyVmFbgJURlg7tuy8HDzMOqGgZzsr9KVJJy//fAX7edxvqRB+ 34mtZJ983yS0wRJ+Ckmr5nW+AQqEJ/gJVUhZaQkwGxK5mybWQvD3L99jTi1oiCzA0Wc84/+yy1i eN7cMoSUqOCM/cDZAJpxBtcomhFTbrDRQo/VAOmeaRz76NxqWaKMo+QUMvvqyil7dMjdnNWscJc Y/Z93aQq4I48nQ40WdkOxaas2loDuTWw6d52pfS4Mp7Z7htnwm1TuaX9YZ5kDXqIvTRrwkNK2p5 q/ALiEH6/aEGnztNn3GF7W2Bhvjja2KPyxvv2I0Ah4u2bUvy1u/ocdwx7sdybRCnuuf1ADlBL6C ka1jFKtduSwdD+40GoMRCXZCAq4GYG35r+2JgpG0swpINwPPZUp X-Received: by 2002:a05:600c:a417:b0:49c:eb04:1c49 with SMTP id 5b1f17b1804b1-49ceb041c7bmr159708215e9.13.1788417712087; Wed, 02 Sep 2026 23:41:52 -0700 (PDT) Message-ID: <624b7832-873b-46a7-b1a8-9e7c20f45c07@suse.com> Date: Thu, 3 Sep 2026 08:41:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260902221000.2967167-1-andrew.cooper3@citrix.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: <20260902221000.2967167-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788417712-754844E9-FB521220/0/0 X-purgate-type: clean X-purgate-size: 1429 On 03.09.2026 00:10, Andrew Cooper wrote: > @@ -273,6 +274,35 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) > return false; > } > > +static bool microcode_safe_to_load(const struct microcode_patch *mc) > +{ > + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); > + > + /* > + * Treat pre-production as always safe - anyone using pre-production > + * microcode knows what they are doing, and can keep any resulting pieces. > + */ > + if ( cpu_sig->rev < 0 || mc->rev < 0 ) > + return true; > + > + /* > + * GNR98. Granite Rapids systems hang when loading new ucode on > + * sufficiently old firmware. > + */ > + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && > + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && > + cpu_sig->rev < 0x01000405 && > + mc->rev > 0x01000405 ) The erratum text says "to 0x1000405 or later". Question is whether that's correct, as it would mean that it's impossible to update from earlier than 0x1000405. Then the workaround text says exactly this. > + { > + printk_once(XENLOG_WARNING > + "microcode: Granite Rapids erratum GNR98 detected. Skipping ucode 0x%08x\n" > + "microcode: Firmware update recommended\n", mc->rev); > + return false; Should we additionally taint the system? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 07:27:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 07:27:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406448.1639729 (Exim 4.92) (envelope-from ) id 1x21qV-000516-6u; Thu, 03 Sep 2026 07:26:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406448.1639729; Thu, 03 Sep 2026 07:26:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21qV-00050z-3J; Thu, 03 Sep 2026 07:26:51 +0000 Received: by outflank-mailman (input) for mailman id 1406448; Thu, 03 Sep 2026 07:26:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21qT-00050t-LN for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 07:26:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x21qS-009SVb-KH for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:26:48 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a992133-8faa-0a2a0a5109dd-0a2a4503d1d6-8 for ; Thu, 03 Sep 2026 09:26:48 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a992138-fae8-0a2a45030019-d1558032ec3b-3 for ; Thu, 03 Sep 2026 09:26:48 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49b0d8bc2aaso20077715e9.0 for ; Thu, 03 Sep 2026 00:26:48 -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-49cee5e6115sm50534175e9.14.2026.09.03.00.26.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 00:26:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788420408; x=1789025208; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=gMgYKh0m7rnTkLfMiw7d299pQwwLFiN2OpMCSWYK+FY=; b=WI5MnojJAPQKmHHcTyf9DialP1evyoYO6GhlY/ThWTeNUivvxBTJ6qcAslr2bZuVP7 1EC+NfdBFETNtat0qxAnLg2jD/583teMDOBWbyujg1skkie6ngoSeLxZIfyeBc9GA9AS +etcb7OlSbdQabQqxdhn9ZISelP7t7f5NXHPQ5qBsmRkphLuLcnHIKbZTFUb3hZGB9hZ LsnqWqE2reAXIWkKtRYL+9x21/a00VjZOS5gdLhqnRCLi0Y24dSr1yHqinM+3fKBw1hk L2UaQCiYL3RbrvcrihPXh2NPRI9t2xKwbr+mKn9H2wWG/WsUjMaDNuKnwh3km7EX/0+J 7PAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788420408; x=1789025208; h=content-transfer-encoding:content-type: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:content-type; bh=gMgYKh0m7rnTkLfMiw7d299pQwwLFiN2OpMCSWYK+FY=; b=IiDzt3vfiCJiO3wFQyc4FPwmpGpYMJ9+MGQSVae0NbnZtMKjyJrbpe+dPrdQv9e7ML lY5TPBX3gD+czEoRE1mprRdAa0kVrzXjfYjghSlyek3wDTn2LtQYE9e9vaKVe+pss0JT DxmkrRyPIBaB7jzosUCz/Gzs8ZJLaYftzvxxX/NxrvM01VEWoLHmaj6qzRDAWslDZ79K Ow8IFJl8DslK5UFb1mxL0rul+we36CTcclzTAAQiL+2oBtdebmLChmcXcdvLvGAAAjtS /s74TSSX6g4g5Id96XzJIPfC9s4tsChbTRCIGY8UGuWAsmQ1yzNT+vV98qJaqJ+aykJv cXrA== X-Gm-Message-State: AFuF++m22gIsQXIaHbgTtoK3Tk+rksDeiF62Y13fWZtPmftRL9gMUiJ4 IPUGWmJFZfR3K+AchHWM/rwduj1nm8lguDcUJ7hDfcgwDqEy6d4Mci9o8zqWZ/xTZA== X-Gm-Gg: AYBFou1bidHAgOdkjIZexqk9CaGLragsTlcSqAWxbcn4Zk/MFFnb3rbKaca9sak/Stq Sufu3UieSrqo/egpqKmixjtUcakzMoFzgPzAKMnVj1wGp9ZOsv4iWY+sLPMS7pG8sFjOMHKqZ07 RpfCfuEV/E4S3R+YVejl3DHC5iX82f7DOXAVJpGzZel2IIgJ8X6KC1mR3K6kC7SS7Ez8P6GE8tK OKfCanrk33pvfTicsgDApxCPHLwMNQWodFnCvTVaztvkMyBUD9+y5SvJB6ZSMvWL5leI51An7Y0 rogXY0+LXf4MzaG77jRFmKW/oUown7CMbxSSCoJuxl7YFiMqT45gEF2NUjrc95Zchh/YMe8Sx5w MW3PKN8zDWFPN7vQyt5QMhrCNEbYti4gB/bh93JhVwCj+aNrwxFaeapaDkeY4x88kihOjaczwwk 4YTTYFA9ye03ERWeTBmP80pMZ/xEpuB8pacgumf55E1eG25Lvg8C5Pk2ql33oAHcLapmaHH8rPK QX1QE6pVcXOrZBiB9mHUxwrtrdXEzGkcpuDDU/pbZutwbEKQ2ha X-Received: by 2002:a05:600c:354b:b0:499:51f0:a9b2 with SMTP id 5b1f17b1804b1-49ce55f051dmr143628385e9.1.1788420407728; Thu, 03 Sep 2026 00:26:47 -0700 (PDT) Message-ID: <4f99f95c-dadd-4f6e-b444-67f2eaa3fe47@suse.com> Date: Thu, 3 Sep 2026 09:26:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/7] x86: split xen-syms/xen.efi linking rules To: Anthony PERARD Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com> <8e1b4212-ddb6-424a-91cf-ed80d985825c@suse.com> <1788360748.8631fc262581453bbf619ec5b2062170.1a0629b6e88000c4f3@vates.tech> 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: <1788360748.8631fc262581453bbf619ec5b2062170.1a0629b6e88000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788420408-6D0D94E9-57072FCB/0/0 X-purgate-type: clean X-purgate-size: 6586 On 02.09.2026 16:52, Anthony PERARD wrote: > On Wed, Aug 26, 2026 at 02:00:22PM +0200, Jan Beulich wrote: >> Doing so, besides (hopefully) adding clarity (not the least by way of >> using pattern rules where possible), also avoids explicit recursive >> $(MAKE) invocations. For xen-syms move re-usable helper rules to a new >> scripts/Makefile.link. >> >> While doing so, re-order .map file creation (which can in principle fail) >> and check-endbr.sh invocation ahead of putting in place the final image >> (which is now the result of a simple rename). >> >> Also drop --source-name= from the tools/symbols invocation which has >> --empty passed, for being meaningless there. >> >> Note that the original "rm" at the end of the rule needs limiting: >> Removing intermediate files (which $(MAKE) doesn't itself remove) would >> cause re-linking even when installing as root (when common/version.o is >> left unaltered, and hence an incremental build should do nothing as long >> as nothing else changed in the source tree). > > But as far as I can tell, both `rm` command are still the same, > unaltered. And both command do removes file mark as intermediate via > .INTERMEDIATE, before make would do so. Without the `rm` commands, make > would leave alone ".xen*.*.o.sym" and "..xen*.*.o.d". Oh, I'm sorry - this paragraph is stale from v1. I've now dropped it. >> --- a/xen/arch/x86/Makefile >> +++ b/xen/arch/x86/Makefile >> @@ -102,12 +102,6 @@ notes_phdrs = --notes >> +LAST_LINKING_PASS := 2 >> + >> +final-image-check-$(CONFIG_XEN_IBT) = $(SHELL) $(srctree)/tools/check-endbr.sh $< > > How about removing $< from this macro, and letting the users of > $(final-image-check-y) decide which argument to use? I did consider doing so, but decided against: The placement of the argument within the command may (in principle) matter. Now that you also mention this, I think I'll switch to final-image-check-$(CONFIG_XEN_IBT) = $(SHELL) $(srctree)/tools/check-endbr.sh $(1) using $(call final-image-check-y, $<) at the use sites. >> @@ -191,51 +165,69 @@ note_file_option ?= $(note_file) >> >> extra-$(XEN_BUILD_PE) += efi.lds >> ifeq ($(XEN_BUILD_PE),y) >> -$(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o $(obj)/efi/mkreloc >> -$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds >> + >> +.INTERMEDIATE: $(addprefix .$(TARGET).efi., \ >> + $(foreach n, 0 1 2, \ >> + $(n) alt.$(n) $(n)r.o $(n)s.o $(n)r.S $(n)s.S)) >> + >> +.$(TARGET).efi.%.o: .$(TARGET).efi.%.S FORCE > > Left over "FORCE" from v1. Without if_changed we should let make decide > to execute the recipe or not. Oh, indeed. The adjustments to the xen.efi machinery were done merely to mirror the xen-syms ones; they weren't strictly necessary to do (and hence this went unnoticed). >> + $(call cmd,cc_o_S) >> + >> +.$(TARGET).efi.1r.S: .$(TARGET).efi.0 $(if $(relocs-dummy),.$(TARGET).efi.alt.0) >> +.$(TARGET).efi.2r.S: .$(TARGET).efi.1 $(if $(relocs-dummy),.$(TARGET).efi.alt.1) >> + >> +.$(TARGET).efi.0r.o: $(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc >> + ln -sf $< $@ > > Why mkreloc is a prerequisite of this rule? It's not use here. > > It could be move to the next rule, where it is actually used, and we > could use order-only prerequisite, so $^ won't be altered. I've check, > order-only prereq where introduced in make 3.80 according to the > changelog of 3.81. And they are not part of the $^ variable. > > But the target won't get rebuilt if mkreloc is changed. So order-only > might not be the right type of prerequisite. Indeed, it wants to be a real prereq. And rather than ... >> +.$(TARGET).efi.%r.S: >> + $(MKRELOC) $^ > $@ ... filtering it out of $^ I think it's easier the way it is. I can add a comment, unless you think I need to move it here and do the filtering. But wait - it really needs to move here, as the tool having been rebuilt needs to cause rebuilding of these .S files (while .$(TARGET).efi.0r.o wouldn't change at all). >> +.$(TARGET).efi.0s.S: >> + $(objtree)/tools/symbols $(all_symbols) --empty > $@ >> + >> +.$(TARGET).efi.1s.S: .$(TARGET).efi.0 >> +.$(TARGET).efi.2s.S: .$(TARGET).efi.1 >> + >> +.$(TARGET).efi.%s.S: >> + $(NM) -pa --format=sysv $< \ >> + | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ >> + --source-name=$(TARGET).efi.S \ >> + > $@ >> + >> +# See above for why $(note_file) needs removing here. >> +efi-objs = $(filter-out $(note_file),$(filter %.o,$^)) >> + >> +.$(TARGET).efi.%: $(objtree)/prelink.o .$(TARGET).efi.%r.o \ >> + .$(TARGET).efi.%s.o $(note_file) $(obj)/efi.lds >> + $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $(efi-objs) \ >> + --strip-debug $(note_file_option) -o $@ > > This command have changed compared to what we have currently, for the > step ".xen.efi.0". In the case where $(relocs-dummy) is empty, this > command doesn't have relocs-dummy.o on the command line. With this patch, > the object is added, via .xen.efi.1r.o. Is this fine? For .xen.efi.0 it's .xen.efi.0r.o, and the rule for the latter is making a symlink to relocs-dummy.o. >> --- /dev/null >> +++ b/xen/scripts/Makefile.link >> @@ -0,0 +1,51 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> +# ========================================================================== >> +# Helper rules for linking xen-syms >> +# ========================================================================== >> + >> +syms-warn-dup-y := --warn-dup >> +syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) := >> +syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup >> + >> +orphan-handling-$(call ld-option,--orphan-handling=warn) := --orphan-handling=warn >> + >> +final-image-check-y ?= true >> + >> +.INTERMEDIATE: $(addprefix .$(TARGET)-syms.,$(foreach n,0 1 2 3,$(n) $(n).o $(n).S)) >> + >> +.$(TARGET)-syms.%.o: .$(TARGET)-syms.%.S >> + $(call cmd,cc_o_S) > > That recipe change slight we what's currently in tree, there's now > "-DXEN_BUILD_EFI -DBUILD_ID_EFI", but that's probably fine, CFLAGS-y > from xen/arch/x86/Makefile are now taken into account. (That's > likely the case also for .xen.efi.%.o but I haven't checked.) Yes, the same applies there, and yes, the two extra -D are entirely benign (and strictly speaking more correct, if either would matter for these .S files; right now xen.lds.S is their only consumer). Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 07:27:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 07:27:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406456.1639739 (Exim 4.92) (envelope-from ) id 1x21rF-0005VM-IN; Thu, 03 Sep 2026 07:27:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406456.1639739; Thu, 03 Sep 2026 07:27:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21rF-0005VF-Er; Thu, 03 Sep 2026 07:27:37 +0000 Received: by outflank-mailman (input) for mailman id 1406456; Thu, 03 Sep 2026 07:27:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x21rD-0005Uv-4i for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 07:27:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x21rC-001NP4-Hf for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:27:34 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99215e-8faa-0a2a0a5109dd-0a2a450ae2c0-40 for ; Thu, 03 Sep 2026 09:27:34 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a992166-f2d2-0a2a450a0019-d155802ce9ad-3 for ; Thu, 03 Sep 2026 09:27:34 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49cd77e0f95so20260895e9.3 for ; Thu, 03 Sep 2026 00:27:34 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cee5f912esm48581415e9.4.2026.09.03.00.27.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 00:27:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788420454; x=1789025254; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zBzWT83iUB/mf/uHu+DdqAJYHl0MdlxSCdvYVjop80o=; b=nqmqxkgCSKgQkUUzqrQNtoW7dDfNzCF3/QrWF+LbnT6NIsTl8FBQafHztI+xPyi12r ToyUWDy6zzBZ8ZaaDDa7zXvf1jXRmqaadG4craz6wF3JhOXxwyxjWjirrswEVzqA5fYa afow0ex8QL/u5IbkpBbpM3v5ZJ7dRAmHlaYxhe2hd0sSyNmRZA4TOzn9F7IS+YlVfTY1 0Qn6p6EMNzF2hS6ov5IPbapytOYFa6Rm4J0siJc3TcAr7duwqj7x3iXBupxtP6RkQfId XWSZxfWfMQVWMckQBrk8B6QDxt89TmOcp9njS4i8BpdpSC/nZ1fcFY7fQZekckNsLDrI mG9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788420454; x=1789025254; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=zBzWT83iUB/mf/uHu+DdqAJYHl0MdlxSCdvYVjop80o=; b=qxqFjXhFBUwTbxvsqgCbrtEN+nMe52DCtV4nwF8SDdJnyUSaXGKRa1DeUYlLlC+MVi xCLhiQxPgJ/pIm4KCKJ3+nTZAnVDAjMdCCMSd1QlBTsHJE8WV6BfxJb5drV23r6dVbFy rRj2/TIKn8Bz6zjw3gR5eJXDY0MsIAjM+IXcks86BfUr/9wSp7SGZ6ec2YUBYXZkVGRc btYzoxQgCVcBATWn6LyrVdTYyUtGCbVsOX6FxI3s7IWas+3A2KxiS6w50oQOzXbSjIoX 7A0M3NpLbmmGDdQrp5fL+KYGwGF8gSWgSW6Ne9VVLij3O4qLOt6S705GEtwtx5bBbhy5 i70Q== X-Forwarded-Encrypted: i=1; AKwUvBxuNUg6MF1KovG/3Jg2iaXqHswn4HX7uyRss4EYb+eRHOBmtOl+tga37L0XgFwBQ0v/15CJyqrLPjc=@lists.xenproject.org X-Gm-Message-State: AFuF++mxjRnYqZlWRk3QaI63qxiIZTs+3SatQ/H0bpEugLzoJehlY+ZU YttmhRjqX43snow6Zryb6XtbaeA9NT/bNw7GOCQSCWTR8iHBh6lDxe7H X-Gm-Gg: AYBFou3EyoLiSXWsVue9rIj9Cn97WIEsqcOFBy+hEOw2VAVO4//RCAaZHmyovW7fb4T GfV15+qzEwSBjQJ4S1JpneuBwrDhwgTyN9cLu1h03Tfi5268BNLpfiKw7cX9/VwVBPj/nXSpJ39 D8yERJ+4TD7fAqaGOkzXfS7t/1Jdc1k8k+nU/vo6HtVYdnO3QzxuZfCaAYmSsEeDk4U+okJK1Qr 067JGHtkNG5hkQvA1LuzEFPCEKyavo3S5D74s4sMJkWkQlOZhUCZCPqyHfDY1xeSLO5Etkgt5te plr2QlrWWAzklOUqhLxj3UW861r0Bzp+HZ9hSfTxtMXiO29QhN4MUDXgYkwqa9NlfzdMiIBUb8P D2jIAXSZ7MQK9fbt1/0D11agaJxQFl/49hXRbqnHCAaHHAkubBHTAZsQjlgW3T5KwALsXtMxXp0 W83vQGdFT5akANWotUCah/rIFG8uYj4yp5DJA6GfMUYwmCA4hCcM6nz3xPZwvJ4GoeFP5L6ltWp GLHiR37B4vNVScq8BkmRP4DHlDbilrD9FmgzRhuloVyerKe4FBN X-Received: by 2002:a05:600c:3485:b0:49b:96a0:5c00 with SMTP id 5b1f17b1804b1-49ce5842b7bmr228116275e9.13.1788420453732; Thu, 03 Sep 2026 00:27:33 -0700 (PDT) Message-ID: <01616191-99a5-48cd-9c3b-e6c00301ec67@gmail.com> Date: Thu, 3 Sep 2026 09:27:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 04/20] xen/riscv: introduce guest riscv,isa string To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <2eb660bd05c6bf5946a7eae09406266db0c5108f.1787836900.git.oleksii.kurochko@gmail.com> <8520ca5b-d7d6-4e5c-a6f3-2969762fadd3@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8520ca5b-d7d6-4e5c-a6f3-2969762fadd3@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788420454-5A7DACFC-525C252F/10/73395122804 X-purgate-type: spam X-purgate-size: 3852 On 9/2/26 4:58 PM, Jan Beulich wrote: > On 27.08.2026 17:18, Oleksii Kurochko wrote: >> Introduce build_guest_isa_str() to generate the riscv,isa string to be >> passed to the guest via the Device Tree riscv,isa property. >> >> Introduce the per-domain guest ISA bitmap, populated during domain >> creation by calling init_guest_isa(). >> >> Introduce struct riscv_isa_ext_entry with a new guest_flags field >> to filter out ISA extensions that should not be exposed to guests: >> >> - f/d/q/v: FPU and vector context save/restore are not yet implemented >> for guests. >> - Z*inx are not exposed either: they aren't in riscv_isa_ext[], so they >> can never be set in riscv_isa and thus never reach a guest, and no >> current hardware/guest-OS advertises or expects them. Supporting them >> would be cheaper than F/D/Q (FP values stay in integer registers Xen >> already context-switches), but is left as future work. >> - h: Nested virtualisation is not supported. >> - sstc: Xen owns the supervisor timer; guests must use SBI. >> - svade: Xen manages hardware A/D bit updates in stage-2 page tables. >> - svpbmt: Page-based memory types are not yet wired up in stage-2 code. >> >> Signed-off-by: Oleksii Kurochko > > In principle > Acked-by: Jan Beulich Thanks. > Nevertheless I again have something for you to further consider: > >> @@ -34,9 +36,64 @@ struct riscv_isa_ext_data { >> .name = #ext_name, \ >> } >> >> +/* >> + * Which guests an extension may be handed out to, by guest XLEN. >> + * >> + * These flags express Xen's policy, not the ISA's rules: extensions which >> + * are architecturally tied to one XLEN (Zilsd on RV32, say) need no special >> + * treatment here, as they can only ever appear in the "riscv,isa" of a host >> + * of that XLEN, and guest_isa is masked against the host ISA bitmap anyway. >> + * They are only of use for extensions Xen chooses not to expose to guests of >> + * a given width despite the hardware implementing them. >> + */ >> +#define RISCV_ISA_EXT_GUEST_NONE 0 >> +#define RISCV_ISA_EXT_GUEST_RV32 (1U << 0) >> +#define RISCV_ISA_EXT_GUEST_RV64 (1U << 1) >> +#define RISCV_ISA_EXT_GUEST_ANY (RISCV_ISA_EXT_GUEST_RV32 | \ >> + RISCV_ISA_EXT_GUEST_RV64) >> + >> +/* >> + * Guests are of the same width as Xen itself for the time being; once guest >> + * XLEN can differ from host XLEN (hstatus.VSXL), this becomes a per-domain >> + * property, just as guest_isa below does. >> + */ >> +#if defined(CONFIG_RISCV_32) >> +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV32 >> +#elif defined(CONFIG_RISCV_64) >> +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV64 >> +#else >> +# error "Unsupported RISC-V bitness" >> +#endif >> + >> +struct riscv_isa_ext_entry { >> + unsigned int id; >> + const char *name; >> + unsigned int guest_flags; >> +}; >> + >> +#define RISCV_ISA_EXT_ENTRY(ext_name, guest_flgs) \ >> +{ \ >> + .id = RISCV_ISA_EXT_ ## ext_name, \ >> + .name = #ext_name, \ >> + .guest_flags = guest_flgs, \ > > As you're using token concatenation here already anyway, why not > > .guest_flags = RISCV_ISA_EXT_GUEST_ ## guest_flgs, \ > > helping the use sites quite a bit? (Whether guest_flgs [then] is > a good parameter name is a separate question.) Good point. I will use token concatenation. Regarding parameter name I have several options in mind: guests or guest_xlens. I prefer 'guests' at the moment but I am open to adjust to better naming before sending v9. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 03 07:33:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 07:33:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406468.1639746 (Exim 4.92) (envelope-from ) id 1x21wi-0007Hf-3I; Thu, 03 Sep 2026 07:33:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406468.1639746; Thu, 03 Sep 2026 07:33:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21wi-0007HY-0h; Thu, 03 Sep 2026 07:33:16 +0000 Received: by outflank-mailman (input) for mailman id 1406468; Thu, 03 Sep 2026 07:33:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21wh-0007HS-G3 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 07:33:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x21wg-002gb3-M3 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:33:14 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9922b6-8faa-0a2a0a5109dd-0a2a450cd6d4-34 for ; Thu, 03 Sep 2026 09:33:14 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9922ba-f479-0a2a450c0019-d155802ced3e-3 for ; Thu, 03 Sep 2026 09:33:14 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so20138525e9.1 for ; Thu, 03 Sep 2026 00:33:14 -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 ffacd0b85a97d-48448e800cfsm11558595f8f.12.2026.09.03.00.33.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 00:33:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788420794; x=1789025594; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=NgXbwmnkoCwVx0ngQYojLIrjhrK77yejae5KALSPGE4=; b=PrJfjxaXLpqr0Wp2+ZgfgKLEBvSb0MaIwbeZqikwCNhBs+97uMM0/BhlYpAd+UcQ2c reWepdsvqP4Gj2DhUI8ix+HJGeLSIBxg7fzFoJZvhQsT1uE6dYcaKxv+4s0/Rm9SWR4a cO31NX7v6abjzJ53xxP32D3jgmluJ4CgIL/wvkRHNx+4qlKX9/LMk0gW/C0GQp69R+ek nqeouG4osCEDJsWO5z82b58gJsBhizP1cv94UIxoigskCKopT9AtTbm6ewa5z5VCdIQB 11KmlqxLP49wY2fjWbgaY2eDKfgvFkb/pbtGm14r2dA/4W74RzpZcVpXBrJJL1QrSOl9 aMsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788420794; x=1789025594; h=content-transfer-encoding:content-type: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:content-type; bh=NgXbwmnkoCwVx0ngQYojLIrjhrK77yejae5KALSPGE4=; b=IHXkHs8mlWBagSW8OONhvuwihQnYfQBrwGzqfZw3J72Y/h6A/DGqIGN4RYKfwEiFcL z/6ETaWsYz9cFPw3AAO4izDgq/NAVxXxlWOo08SIDyT3oHlgYfdAqb1Dhm7Xw8pJxC7M MUow4dJU1EWSQ89XoDyLgwyVXP4UHnhEkl+vGcXRGJ8gu9U/rJSTFfp2sBU1ymR5Z1QM JKS6+pvCwj4qWrRLm4dxc3pREc999alNXlvA3unjBCrleHswf2da+GW9xLM/RhUkcrCA 0AFXadqXQTt+vIEDGz9LzXjnmNtmy6u1x0aEcgVMNJKso85T2MqI4ZyU8k+rE4VXVeNB uZgw== X-Forwarded-Encrypted: i=1; AKwUvByb0ZHcM9uY/2bXJglBOVbGE/Iuq9u43kDmaO1bcp7HfrQ8cq/Fm2h2rp/TMcNxfQPnDGBBjcdElxQ=@lists.xenproject.org X-Gm-Message-State: AFuF++m57iPOJ3o6O+MWEiOt7d83vVDgGBS7FIE2LX11Iqm1YvS1Ek9Y QcBbQCJ+MC2VhQ5H7q7qP0Q+UH4BTm4YTKhWd0syfYuRnYbl+XI8ujI2Xoam01tC8Q== X-Gm-Gg: AYBFou2En92G6wu/QXupIC8co4BN9WBI3RTN+WuBRkw+YoyvmmJuebqucVHYiFJdsc8 goUjn0cU2yBQ4teiaee/EC8o5oWCLAlBZKdgvHqANLdiK3ltktDHgg1xYpPmqPqJH/pr1fDY62N F6gjN6S6NS4aRe/OyxiMqBC3E8dbf4DpJyN3eUK9k2Urj0SeIxYoQJ4ciIWNiY33QnDAHMgTCi1 bKHf08E7nvpQ+Xtg5e2MQhBftovwvPeb5VCEQLY7xNQi0c6MMJufE89+Ki55fRWquPvfzDt5Fpj XdM9ABzxjH//AyCCMRbVLDqiKCno0j1tdODRFGAUkqUvDOPT0NUXx+4B95mts0aoR/N5mvKWb6G 8hB6tHrcQeY6rwrQ1PBdtBUhqSV6zrZxbs2s+6pqBIKG9GgWXCUjEmB1lVUUMJYvLnzng6NGl8F hDsrAM+iBTzEEsmrxSGfrXSmntGSBZDNTK2CO1aom5GwEtxEO1O+xiVQ2SF4+vdZCFznAbs5JzI vQHAC4e+HKNGak7L9iPJh7JuzCf2vD9SMsFDEeGiAR1MHgEPk5b X-Received: by 2002:a05:600d:19:b0:49c:edd8:ba35 with SMTP id 5b1f17b1804b1-49cedd8ba5emr98467085e9.6.1788420793884; Thu, 03 Sep 2026 00:33:13 -0700 (PDT) Message-ID: <578cefd9-de8d-4a2f-8fb9-778cc5d422b4@suse.com> Date: Thu, 3 Sep 2026 09:33:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 04/20] xen/riscv: introduce guest riscv,isa string To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <2eb660bd05c6bf5946a7eae09406266db0c5108f.1787836900.git.oleksii.kurochko@gmail.com> <8520ca5b-d7d6-4e5c-a6f3-2969762fadd3@suse.com> <01616191-99a5-48cd-9c3b-e6c00301ec67@gmail.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: <01616191-99a5-48cd-9c3b-e6c00301ec67@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788420794-51538A5B-A3B8D020/0/0 X-purgate-type: clean X-purgate-size: 2678 On 03.09.2026 09:27, Oleksii Kurochko wrote: > On 9/2/26 4:58 PM, Jan Beulich wrote: >> On 27.08.2026 17:18, Oleksii Kurochko wrote: >>> @@ -34,9 +36,64 @@ struct riscv_isa_ext_data { >>> .name = #ext_name, \ >>> } >>> >>> +/* >>> + * Which guests an extension may be handed out to, by guest XLEN. >>> + * >>> + * These flags express Xen's policy, not the ISA's rules: extensions which >>> + * are architecturally tied to one XLEN (Zilsd on RV32, say) need no special >>> + * treatment here, as they can only ever appear in the "riscv,isa" of a host >>> + * of that XLEN, and guest_isa is masked against the host ISA bitmap anyway. >>> + * They are only of use for extensions Xen chooses not to expose to guests of >>> + * a given width despite the hardware implementing them. >>> + */ >>> +#define RISCV_ISA_EXT_GUEST_NONE 0 >>> +#define RISCV_ISA_EXT_GUEST_RV32 (1U << 0) >>> +#define RISCV_ISA_EXT_GUEST_RV64 (1U << 1) >>> +#define RISCV_ISA_EXT_GUEST_ANY (RISCV_ISA_EXT_GUEST_RV32 | \ >>> + RISCV_ISA_EXT_GUEST_RV64) >>> + >>> +/* >>> + * Guests are of the same width as Xen itself for the time being; once guest >>> + * XLEN can differ from host XLEN (hstatus.VSXL), this becomes a per-domain >>> + * property, just as guest_isa below does. >>> + */ >>> +#if defined(CONFIG_RISCV_32) >>> +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV32 >>> +#elif defined(CONFIG_RISCV_64) >>> +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV64 >>> +#else >>> +# error "Unsupported RISC-V bitness" >>> +#endif >>> + >>> +struct riscv_isa_ext_entry { >>> + unsigned int id; >>> + const char *name; >>> + unsigned int guest_flags; >>> +}; >>> + >>> +#define RISCV_ISA_EXT_ENTRY(ext_name, guest_flgs) \ >>> +{ \ >>> + .id = RISCV_ISA_EXT_ ## ext_name, \ >>> + .name = #ext_name, \ >>> + .guest_flags = guest_flgs, \ >> >> As you're using token concatenation here already anyway, why not >> >> .guest_flags = RISCV_ISA_EXT_GUEST_ ## guest_flgs, \ >> >> helping the use sites quite a bit? (Whether guest_flgs [then] is >> a good parameter name is a separate question.) > > Good point. I will use token concatenation. > > Regarding parameter name I have several options in mind: guests or > guest_xlens. > > I prefer 'guests' at the moment but I am open to adjust to better naming > before sending v9. I'd suggest singular ("guest"), but I don't mind the plural form. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 07:34:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 07:34:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406473.1639756 (Exim 4.92) (envelope-from ) id 1x21xY-0007ip-Bo; Thu, 03 Sep 2026 07:34:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406473.1639756; Thu, 03 Sep 2026 07:34:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21xY-0007ii-8g; Thu, 03 Sep 2026 07:34:08 +0000 Received: by outflank-mailman (input) for mailman id 1406473; Thu, 03 Sep 2026 07:34:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21xW-0007iU-UY for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 07:34:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x21xW-002gsC-AS for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:34:06 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9922e9-2eae-0a2a0a5409dd-0a2a45038de4-24 for ; Thu, 03 Sep 2026 09:34:06 +0200 Received: from [40.93.195.55] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9922e8-fae8-0a2a45030019-285dc33734df-3 for ; Thu, 03 Sep 2026 09:34:05 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA1PR03MB7148.namprd03.prod.outlook.com (2603:10b6:806:33f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Thu, 3 Sep 2026 07:33:56 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 3 Sep 2026 07:33:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lZ9GJF6uwQyVmONvdO3KV+jdFVxy+QymO/83cy+N11SRVh8a5qMuJqO8WhNynbTruOskelrXYtwhdDiysJUSUROirizRZl6ups3jWFEyVklG1Y13n9+PiIbWNNUzrPELJgHV/LoXhyA+0Rdxz1dmrcwNQeNdJwXIz85QpDVI69TqZWTw5rg28c9N51Qlgcih+SyoAxt+jduQ7p8Nyoha8/SyrCxTmPRem9qVfBr7KV2oB0crXh8/1FkbYv5TL/9B4fka0PxpR4DBJUkxMxe9n/DVVnoqFc0avLngJBhROoZJUDBGPSG6SUR3x7kqQsqqnkad6WfoOjcpj1+cLJ4wUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mDqhLnYaZATcSn7LLUG63PvjBhjopPL1L8K2aL7Jl3k=; b=XNHPuKPXrOqeaT/F02PXmlgf679g8/tY6fCM+HKO40FZ8QbSsPPsfVuCIZmk9kVZxAFOlpZPH1sHslDJ7AUedNPQdblF7sMHwibPwZqw5IhdXSt5N6pRYQdt5i8P9KSUzVhVlbZlKinYzmSc7/q+upWlWxgzNbP1EiNlV6ASWAxRoea0y3pNC3jXelwkJBWYBMlFY1AFmsXWD7YaHWiGJHs+wuUdyyuNMtKROSTibiR1O5lBWVe9veD5OzvVn24E8gm+Ph8QBye5Km0IZjE7haAg4YqL1lpEB789B9yo1LzlqUNUuFYL5D2p0awmHpc2g1/6qEErSRVNJJItIoKD1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mDqhLnYaZATcSn7LLUG63PvjBhjopPL1L8K2aL7Jl3k=; b=Q4YvIoUYLk6Jos/2u92q9IWc0SgadbkucYzf3keyMclZkZNAaypIcQqUYODLlhkJNk7fAASwzNbKRtOUb61zD1XpJcsQq0TLB2isbF74VlRrZov3HHd0+LRTHSx8Rvlk4E4HbTJdTukuNcvBKe13FpQRc6yOQXv2R3seKbMe7cU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <6eb4e647-d737-458f-b91b-41d5915814f1@citrix.com> Date: Thu, 3 Sep 2026 08:33:53 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Teddy Astie , Xen-devel References: <20260902221000.2967167-1-andrew.cooper3@citrix.com> <1788389520.8631fc262581453bbf619ec5b2062170.1a064527434000c4f3@vates.tech> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <1788389520.8631fc262581453bbf619ec5b2062170.1a064527434000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0168.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:312::11) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA1PR03MB7148:EE_ X-MS-Office365-Filtering-Correlation-Id: 3bef4352-6bae-4796-4a1e-08df098db663 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|56012099006|10067099003|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 5Gr/i9+jxlxxDf0M3i5+HJt/fWLZsr8yl9r4/jQZbOwQtSmVcbXeo+EOPKGak+JHz26bivt1I5oXNg1v8NGFb92lkGjtni3NTbn5h2YyFCPACKWZ6Q/RsmicBeaswhCFjgXNjkmIy+n58RNr9kSwub2ZV1iEnB52kP23hTGlA5FDiRVe1rcHdMDBiM3lqSqD9/G9X51/+6TNLcTzWZZ/dGs/oKNGFt+odNz9Hd8fabW6egYcvG0WEWn+Q37KAS7jChFg/kAvnMBx4KZXPsd/LiTTtjgU9G2mIGLrhCgT56aR/nHAVHJFd5ZQVzGGUiP3iERc9FsCz0r+1Nxbqii0KtwfxIyGge60gZYPUCaQIQCQAnITIFRbjoEmkS44qHMLvP8IrELr70iqLZ2ZcMb5aVDDWmN5ab99NQyWuoLmAGonlY1L8akt9CPK6lgVqbMCOLLO6ITyvjth1P7HspMxdJA6lWxt+blfhD40Mp3ElQV+YHCD+66ZxOLCQNzKlxReGCCG+CNrcD6a749e/XQqARq/xBbeEyIxxHmviaWRibr2geNHSN6UH1lrEsSDk8TZD3j3+IHuzUetd5CklrWb/pdKfxIZS1zBoSTrYPzkG/TuIcTMrAeTKmrYojerl8n5pVhKifqpCdPmTIIryv6H8MLz7oL6MWADtwZxcsA4EG4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(56012099006)(10067099003)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MlFIbWFyUUs2cGhtbmVOcW5SKzRYNVdTV3JFalVzNW1kNG9RNERTYWpJZkdY?= =?utf-8?B?b3prWmE3TTNSMUZsa2NmMU1MVnhCRTZJcktCSjVpWk40bytRQlVIKysxSkRG?= =?utf-8?B?WE9xQWtEMEhENXhaRGx0a2p6QnFnN1dJQnlFRXpVY2NCMmVRNURHOWJWZ09j?= =?utf-8?B?NC84cDRoNUx6WDBHWFJjbkk3aWVFUUNlZEpGQld6K050cEdITzhzZVNaaWVt?= =?utf-8?B?TG5XWGFFdDhQRE9UYloxSmNvRVo4Q2ZXSzljTS9vZWZlVTNibWMrb3p1UEV0?= =?utf-8?B?NTdnand2ZlVESE1jWDIxdzYrdDRqZ1hFNE92ODN4RGNEeEhwNlNST3VxQzF4?= =?utf-8?B?eUw4M1lUSDVJdjVnaFdhNHU3aVRNaHVhRWNERForT0g3T3BDdTY2TWtBaEtp?= =?utf-8?B?U3RpVU1NZHQ3dTFsNWhjODhXL1kyVWJUVmczYi9lZlA5V1dlWjliV3A5Mi9i?= =?utf-8?B?Wm9nN2xzcUhjb05rYnF0MnJOY1BZenVnY1JERmNvVC9XdW1mQXo3NEdmR2I0?= =?utf-8?B?SDVzbVZjeHQ2MHluRWdoQ2Jpakg5aXQ1TGlxUGxyamNTVjhIQXh0TzFFYU1T?= =?utf-8?B?cnB5RE1HMVVpMHYzOWxMdlRaWTlnY1gyTG15T2JuWmdoV3l5NUZmVWZ2M1Fv?= =?utf-8?B?ck1lRmY0L2U4K3pSUXp3V1pmVUxldjBuRlZvSlVOQ0N1THdNcVN5ZXYrUnVZ?= =?utf-8?B?MUpxMm1UaHozRDNlM1hBbVMrdi9Vck9DZTNoYUcxT0RHWEN6dm5WaWJBNjlG?= =?utf-8?B?MUpxQWprdzB0eUw1NzhQcmJYTWgyY2J5TVhPdjN0bmQzVHVGS2Myb2ROQWZu?= =?utf-8?B?Q3VnQ3lEdVcxdXFzK3lISUNodC9PTWF1cVg1R3dGckxjeVh2N2NlSUxQNnBs?= =?utf-8?B?ZGg4blJoTFdBbzR4TW83bG1RSlRNOVFRS3FUT3VndWRvbXdETDJOeFZ4UlAz?= =?utf-8?B?ZHpaV2E4VVJocFVKT0dLeXRzdWpNcUU1bVB0eDVrVUNST2hlWHp2MXEwNVlj?= =?utf-8?B?OEdMUUthTyszaHdSZ2R6cEg0SHpCY2QxN1cxSHJ3dVY0dzk5T1ZxM1VPekpZ?= =?utf-8?B?KzV0TzZDcGpYNE9qb1pIUXZXaXVTcVJzNmpmQmFSdVFqOG5RZ09jaXhYZ2Qx?= =?utf-8?B?MTV4MEpNU0FtdTNqaFZITkNqc3FRc0JWaHBlMUk2Rm5lOEgvVVUxcS92N3FT?= =?utf-8?B?dFhJQm9oRjltODJOM3N4VWU5Tnh3a3pRK3FVaWJzMXU1bFR6UXgvZUt4cHZN?= =?utf-8?B?a1BROXpDbHlhTnBsMnVwU1ZySmtyczdGdnMrT2dKUGJtTEEzNEVibXR5bi9i?= =?utf-8?B?bWwwM3p5VzBNV3pabVErNnNqdW5VWlZ5bkNzWmZNcElpME5qYndDS3RIRTdI?= =?utf-8?B?bloxVWNSdGQyWDE2LzVYUTdUWkFQUEFxU2d2TDFrVDR4aWRpOE96R2E1TFl6?= =?utf-8?B?enJCemo2b09ncTNkZUE0SFJzZXZCenhaQUdVNVI4dEpCUVBEaVBoSVZiZVA2?= =?utf-8?B?WjdtUnF6c0NmakFTNXk5ZHl0dW42R0xQdjREZ2FIM2dqNkxUZDVsZ3pRakVH?= =?utf-8?B?TEJHYXRRdjdCbTMyWWxhRi81Z2tOelR6SGJLSWtIajIwRVNWMCt1V1NqS25s?= =?utf-8?B?OEZIdGtoQ21iVjRrZmduOWo1WnBpL3U0RGt6Y2dKSGtNS0NIamxGZlNWd0dk?= =?utf-8?B?RnFCOUZNVzBOY3J4eXd5SktaNXBWOG44RlhldXZ3VHdDbEQ5dXFldUoxSmlP?= =?utf-8?B?ajgwV1c4T1dGWFZZTWQrM3d2QzBUVFQ1ckY2QVQxWlQ1TDN0RmFmR0Y1Mld2?= =?utf-8?B?R3NoY2RnSUwweU1SVXRqMVVvb0l0dHVSNlJGZWFISzY0d3VXdkdiN0RpM0hS?= =?utf-8?B?S1NJeS9ZYXEveUFzQkNsRm0vOEExNFVqekZiQzBLZTdlYmlsUTYvMnRwTG9n?= =?utf-8?B?dGtyalVrRDVoejVrMXJacXh0RTlBaHFLS3ZlZHE0V2JFYUc5b3MvaVdPMVF0?= =?utf-8?B?TktqNVJRV21aalhGT1VURVJZYUpScDc4aGFXSDlMVFNETXdXaXEwTGE2c240?= =?utf-8?B?d3NSMUhVbjRvVVN3R240SWVVUkl2N2FXck9ZYUZiWUw1cE5nbTk5WGtTT1da?= =?utf-8?B?UHM4YU5GdkJCWXJLZ3ByNTdqRm12NldHTDZRc3VkR040VEZ3Nzhyc25rSmlL?= =?utf-8?B?RUJuY2RTV2tCSC9iR01jVHBhS3RobUNHMWtqTng1S25KVUNLMWVVQnhGeEF1?= =?utf-8?B?d1U2NzlEUFFMSmJWOVl2cmhHNERTSEY0ajViaVNEajd0NENUbU9aZFVtRnVH?= =?utf-8?B?MFdyVG5EdDlUNEJjVE11RWN5YkdWc041SXlHZ081VVp5dHllU0hKUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3bef4352-6bae-4796-4a1e-08df098db663 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 07:33:56.6738 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fWCnZpAAWCCojYwGGl9LdDoUFlg5w+DWO2ROcnDccSOURQLmhq1sLmIY4qkVBCnWuCzgO9NZ3L5pp3KgNWicQPW8cJPzfPjF7syvx04LDnA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB7148 X-purgate-ID: tlsNG-33051d/1788420846-764FC4E9-0EA224AE/0/0 X-purgate-type: clean X-purgate-size: 3785 On 02/09/2026 11:51 pm, Teddy Astie wrote: > Le 03/09/2026 à 00:14, Andrew Cooper a écrit : >> Block loads which are known to hang the system. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> CC: Teddy Astie >> >> A more complete solution is in the works, but it's taken 4 months to >> get this >> much published... >> --- >>   xen/arch/x86/cpu/microcode/intel.c | 31 ++++++++++++++++++++++++++++++ >>   1 file changed, 31 insertions(+) >> >> diff --git a/xen/arch/x86/cpu/microcode/intel.c >> b/xen/arch/x86/cpu/microcode/intel.c >> index c45b00c6b033..2160befd3197 100644 >> --- a/xen/arch/x86/cpu/microcode/intel.c >> +++ b/xen/arch/x86/cpu/microcode/intel.c >> @@ -27,6 +27,7 @@ >>   #include >>   #include >>   +#include >>   #include >>   #include >>   #include >> @@ -273,6 +274,35 @@ static bool microcode_fits_cpu(const struct >> microcode_patch *mc) >>       return false; >>   } >>   +static bool microcode_safe_to_load(const struct microcode_patch *mc) >> +{ >> +    struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); >> + >> +    /* >> +     * Treat pre-production as always safe - anyone using >> pre-production >> +     * microcode knows what they are doing, and can keep any >> resulting pieces. >> +     */ >> +    if ( cpu_sig->rev < 0 || mc->rev < 0 ) > > cpu_sig->rev can't be negative as it's unsigned int. > I guess that's something to fix in our struct cpu_signature and how we > get it. Though the structure is shared with AMD, and I don't know if > it also uses "negative" revisions for non-production ucode (PPR > doesn't tell anything in that regard). Oops, yes.  To answer Jan's question, GCC was perfectly happy with the logic in this form. The field needs casting locally.  It's officially unsigned according to both Intel and AMD, despite Intel actually using it as a sign-magnitude number indicating debugness. > >> +        return true; >> + >> +    /* >> +     * GNR98.  Granite Rapids systems hang when loading new ucode on >> +     * sufficiently old firmware. >> +     */ >> +    if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && >> +         boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && >> +         cpu_sig->rev < 0x01000405 && >> +         mc->rev      > 0x01000405 ) >> +    { >> +        printk_once(XENLOG_WARNING >> +                    "microcode: Granite Rapids erratum GNR98 >> detected.  Skipping ucode 0x%08x\n" >> +                    "microcode: Firmware update recommended\n", >> mc->rev); >> +        return false; >> +    } >> + >> +    return true; >> +} >> + >>   static int cf_check intel_compare( >>       const struct microcode_patch *old, const struct microcode_patch >> *new) >>   { >> @@ -365,6 +395,7 @@ static struct microcode_patch *cf_check >> intel_ucode_parse( >>            * one with higher revision. >>            */ >>           if ( microcode_fits_cpu(mc) && >> +             microcode_safe_to_load(mc) && >>                (!saved || compare_revisions(saved->rev, mc->rev) == >> NEW_UCODE) ) >>               saved = mc; >>   > > The rest looks good to me; as my concern is unrelated to change itself > (and doesn't affect production microcode anyway). > > Reviewed-by: Teddy Astie Thanks. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Sep 03 07:36:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 07:36:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406487.1639765 (Exim 4.92) (envelope-from ) id 1x21zN-0008Jh-P0; Thu, 03 Sep 2026 07:36:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406487.1639765; Thu, 03 Sep 2026 07:36:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21zN-0008Ja-M3; Thu, 03 Sep 2026 07:36:01 +0000 Received: by outflank-mailman (input) for mailman id 1406487; Thu, 03 Sep 2026 07:36:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x21zM-0008JS-7A for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 07:36:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x21zL-001Oi7-K5 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:35:59 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99235a-2eae-0a2a0a5409dd-0a2a4503dbfe-10 for ; Thu, 03 Sep 2026 09:35:59 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99235f-fae8-0a2a45030019-d155dd2eb91b-3 for ; Thu, 03 Sep 2026 09:35:59 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-484362f5c4aso2064535f8f.3 for ; Thu, 03 Sep 2026 00:35:59 -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-49cee3b0af8sm50660085e9.0.2026.09.03.00.35.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 00:35:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788420959; x=1789025759; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=/AU8SzDIvkFSshla1OxAULChwrjiUZCrKjwpmU7v8hM=; b=NntvTifWgWVGbBHNePPZuXzt8okGt7jQr/mbArVisjTldvUaQ6TZyXl85m2hA7j31n G9kcf6hPEaRd5/VV2x0jHTKDuyPjSSF4l+aHvoWZi7uhAPrp+Sw0X1l82ZoCut00imjS 8+Bk34RCdvQJFGnYIMm3l5/3m9WRXpXsiju5JuNRUaeE2mH9cdkbe4UioGn2CfQBmhY7 X//PuXFqzAybZ1yuQKIbiP7V4OKMAxm3akXMTdQ5VntjUIDWNZ8UE8sPZtQ5Yh5Murm2 9DY/GVGAJCvBEQtkxRPhtJHky5j4DvaYDcia9DWJgy/AzL3ahYrTZY90c/BoxdDgS+hg c9pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788420959; x=1789025759; h=content-transfer-encoding:content-type: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:content-type; bh=/AU8SzDIvkFSshla1OxAULChwrjiUZCrKjwpmU7v8hM=; b=rO5TU47n4rrbxSlCml2ls/vX3lDttCtNdJoAswDA4Y+LaEixOt9IJI2mBUzvJY7/ur 9jJmhxZ2Q9mfxQXURL6RDEmjN2rgln1H/IEgZqmiTAHBlIcaCPGTNAnhhrLdJOcZ64Un T+Dao7NGxulQxR3wFOwsWkpjLz0FV3t2JPQArbA0/dA8njmwwg5sVSbREradaCd1gxOR iv65SHG0/cC1Nb54KksseT1EZh8fb17leDrkq742l/X9repvHdDq8cdlWwCkVKR26rvQ u2irEI5yICu5Lm5aUD4Ei3D3ruNO/JiWAFEhqLwtkctnvvmjYPLU4PkQqXDsWEDpVLzp 1AQA== X-Gm-Message-State: AFuF++lt28IeW+Fhn/jh7Xvo9XE07IuUcxem2RQVLeLyU2g3tUxvySot ClAbs4Hb1xCxNtFR4dP+L8+J9KYXcmfNUQpGLNAoltMeUyDV/Va71CVZUefKShGWYOVEaXTYQWm jPmhp7w== X-Gm-Gg: AYBFou1CYTkmFg1pEgkZ7QazZy3MJ2u6mLvU/bGL04nDIJsb8Z3URFN06AoQiCITUYC EN0j+TtEyyeJ16lamv5HSsF5ZBBoDQ9FmKApfrHamEGjWUKa8JXbquyIF1JFFJdpeSn2PqCMLk/ gROoVtseA2LR7c3jjByXDj4lQHxM9MDODaNW0HXh7bgmBGE1M4iRG5ni0EUvyl9rk2SKmZTUWrC 3+T9VLQfxQla9OrgnNMDt3OAPJzYX63UpN6RhuN9PbEbRgu/S2ogItkQ+L6L/xj3N1R6q7T74OM ZyagdfoSw5fH8mhytGxqQ0GwXWUY5vLLzZwb4sBzeusId59GgTa1zb3CE2TwHt4amm8/b9U/h2V 93MvjgYDnFzcwjcUEO71zhRrAO68L7DO3sDw/j1q6xO48jRAZW43tso0/w2ouPoe1jAoUeEhg8k 2L6gbdHdCIBeYvnT1Tq06l1exmTRwJLxMqhpN8K+lIr4ZTA22JMSpkqgZkN/UV19M3Dg677yA9Z y9I7qRAewluVgeVFrksBcC6NFpsmbRT+DfkjBV2UjaAKXeTo/wAi1Ln3OQOwm9V X-Received: by 2002:a05:600c:1d14:b0:499:b65e:49c9 with SMTP id 5b1f17b1804b1-49ce583e94cmr165699845e9.10.1788420958966; Thu, 03 Sep 2026 00:35:58 -0700 (PDT) Message-ID: <0dffbc71-1822-4db7-a340-b7b9d0df6c6d@suse.com> Date: Thu, 3 Sep 2026 09:35:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/7] Arm: split xen-syms linking rule To: Anthony PERARD Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com> <483052d4-b70e-4005-8b10-4ecf509bf40a@suse.com> <1788366735.8631fc262581453bbf619ec5b2062170.1a062f6c8bd000c4f3@vates.tech> 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: <1788366735.8631fc262581453bbf619ec5b2062170.1a062f6c8bd000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788420959-76CF84E9-A679DFFC/0/0 X-purgate-type: clean X-purgate-size: 1741 On 02.09.2026 18:32, Anthony PERARD wrote: > On Wed, Aug 26, 2026 at 02:00:55PM +0200, Jan Beulich wrote: >> Doing so, besides (hopefully) adding clarity (not the least by way of >> [re-]using pattern rules where possible), also avoids explicit recursive >> $(MAKE) invocations. >> >> By re-using the generic rules introduced when the respective x86 rule was >> split, >> - the .map file now isn't created after the final binary anymore, >> - --strip-debug is passed to $(LD) during early linking passes (for >> consistency the option is also explicitly added to the optional linking >> pass rule), >> - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are >> now properly respected. >> Orphan section checking, otoh, is getting suppressed for now, until the >> about a dozen warnings which would result have been taken care of. >> >> While the 4th linking step continues to be avoided when possible, a >> redundant invocation of $(NM) and tools/symbols (plus the assembling of >> the resulting .S file) is hopefully deemed acceptable. > > So with this patch, if .xen-syms.1.o and .xen-syms.2.o are the same > (compare-symbols-tables), we through away .xen-syms.2.o, and build > .xen-syms.3.o from .xen-syms.1 (nm|symbols + as). I guess the resulting > .xen-syms.3.o would be the same as .xen-syms.2.o, Anything else would be a significant problem: nm, tools/symbols, and gas would better produce the same output from the same input. > so it's probably fine. > > > I think this patch is fine, I didn't find other difference in command > executed beside the one described in the patch description: > > Reviewed-by: Anthony PERARD Thanks. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 07:51:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 07:51:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406498.1639773 (Exim 4.92) (envelope-from ) id 1x22EP-000335-0S; Thu, 03 Sep 2026 07:51:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406498.1639773; Thu, 03 Sep 2026 07:51:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x22EO-00032y-Ts; Thu, 03 Sep 2026 07:51:32 +0000 Received: by outflank-mailman (input) for mailman id 1406498; Thu, 03 Sep 2026 07:51:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x22EM-00032s-Qo for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 07:51:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x22EL-0000j7-O2 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:51:29 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9926f5-bab6-0a2a0a5309dd-0a2a4506ee08-36 for ; Thu, 03 Sep 2026 09:51:29 +0200 Received: from [52.101.56.63] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a992700-195a-0a2a45060019-3465383f6efa-3 for ; Thu, 03 Sep 2026 09:51:29 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by IA3PR03MB8382.namprd03.prod.outlook.com (2603:10b6:208:543::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Thu, 3 Sep 2026 07:51:21 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 3 Sep 2026 07:51:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=o2F90/QDjJkSAhdFfghd9rpeY5JyacYXDcdft4UZeC8SmuYoQdvvEYfC1kx790EfvTelhlBrDY4Mt587s911cvG6npRTQS6w6QPXrlPa3JlvMTQ7OZ/WDSljTWv/l1BlP2z2QOWIv8k23pI87EjYYMMn9r8+JiM9n4y1zyt1ClPt0mVX8iG51h3SQJs8ZmsD3gDXul8nLM9DKcV0+gvQxxUJ6VTc4FpeRz3ekW/+wNegz7ieCJTx9fKRSjGloiRT9jnTNJbZcmWcD9GkVZJj5TKfcM7666ZTQvNUbSpczOcPps6XfDnhioDUhxuwRwsv9NOxJHrWlFptuew8gUxtlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=j6GLLnjFy57QuSNuF7gsV5nIdnnh7ky4B6dEbMdTEDg=; b=p5O/thwTYVIL2dsntsvIAMLjJkQEoBd2Vx0Xb2PUTojnQDvFiNPKA4R/WVCxsoYVXQExInKAKU5ELbRsiNkZnLoAF29l7IGExbetCTV2U5VTnZYrKLMKWn18GmaMorAeO94f8tL+SZjMrMVhkL7Sp145+NQdkoQuaPjqWXoqOiFHK8cJcYD2iOJCCYbKmIUi18tfR4M/qndz3zcMv3oQTYNTQ5QB1xRXR7M69X4oUF7+hognM5hu/Y4d4GivQqiRUL5TU6xhlB/2OTdeRHSZEOhV/XqWM3Em2niY6nzYBzeOeW6cuINKCkFkofp1WYCe/VzAYxA/6NhE7oBH5EeYuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j6GLLnjFy57QuSNuF7gsV5nIdnnh7ky4B6dEbMdTEDg=; b=tVSNk+kRMVdTx7/P1IQA/Tf6Dy/k2eS9UHlNxZrSHMgCsV8AKTe1bywjO+4O9k/L7tLmNOGTi8zQZzIw4sZHZcdFG5/gVclOd+vBfJhqRVfXNl0V2xx/neLo4QbBhqc6cg72dXTKo0cHv2QXPmRim4maQfyXZeUokaZPOFPoxYg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <76f8b54c-1e1c-4ea4-baeb-43d7b7996746@citrix.com> Date: Thu, 3 Sep 2026 08:51:18 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel Subject: Re: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Jan Beulich References: <20260902221000.2967167-1-andrew.cooper3@citrix.com> <624b7832-873b-46a7-b1a8-9e7c20f45c07@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <624b7832-873b-46a7-b1a8-9e7c20f45c07@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO3P123CA0005.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::10) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|IA3PR03MB8382:EE_ X-MS-Office365-Filtering-Correlation-Id: 8677eeb9-8342-4748-f5c9-08df099024f7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|3023799007|56012099006|4143699003|5023799004|10067099003|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: UsldZzWx2gbL1VCv4BXPpOPrNApKkz9hOq3jjE4dv7xm9EIpSFBVYYOUsf8aJXRRy7cTenO9s7Eeicunygc5l+ccdpVK6g6d+e3x6ygj/AiHk5WW0jCxWLWIX3vjnad+5tOM9udPGO4Iz/2o8ZndF0njsGlXesPRsTaPLNoYE/IdibutHL92oTtRLG+nMJfDsaQaC7etCpTHttmlLEeHksBemRFCHYfFkMidJK72dPst3wQ1VTGh3ppUPq06pybNpcGTTNdx22cBq5K4t5Hyf+ocLUNcYA2I5lD0CQjS8VlwD+pCod/PHfS9y70HOTf3ReaWyky8xVBvO3lpMwIFRwzLji6yLzPhUc9YSYnP3nJBhKPxMeWee8SplBzqdIoQyuX1yOasyyGAoqZGMl0Tosm6jGwrfrydsF/bzP4tO0e1m+cGw4t2NYf1paxup4g+COi/W8cDSpqEWPR0NjnjYoTh59oJIuKE/5B9CWuAYu1HSZYZqw+DTIYmunyGgCnli/Zr8VUtrOu8R2cpfNgBADzKBfGmUY+2kHpiFmdshI2IjPG84VzG+MW35jx621GgAHioVYKMPaLrHl5ro7TAAY1jYgLIvTj757i6NS4pkniQgFaxBzzjB/+2LOS7VdZoU2oS20Stg8LBKeQOHAOSt4Nt6+7WvRojhmexZBaiRIU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(3023799007)(56012099006)(4143699003)(5023799004)(10067099003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V1kxdUM2bEdrUlpka1Y1VDViU2NReGtWWVRmY1FYQkdZNUFkZzBhTmNvMkxJ?= =?utf-8?B?MTdMclRIKzVmeGJUczliOGlsS0FlWm44UElJM3QzbzdqZHp6MitkbTVpbVJF?= =?utf-8?B?M3JzNkpRYjdXajZKcEVWVkF5c2hzUGJtdUk4VHdxdGpLNXErWUhHK2FJZ2Q1?= =?utf-8?B?dmZ3cWlVZ1hqc2pjVVpvQ3dsN2ZZb0JiY1d5b25BZStsMWgrMHNXK20xNmtp?= =?utf-8?B?alY0TTV6REkxWkttT2pRVmFJL2h4UldBS0MxWjFPckNWakdZN0RhR1BWTGVR?= =?utf-8?B?andOZVZJdkpiUWtOVVYxU3haTEtxRG5Tck45YUdXNUZVY1NhZU82cGtGREpq?= =?utf-8?B?YmpOS0FwcDJ6djBqZkRjY0J5a2JreWRueVcvd3pMUllLWTFWK25TSDhHNTF4?= =?utf-8?B?WmVGUmZpbGxselZkUE92UERKSTFVUVpmL0VQdE5RUW5QTXZiWUZmNG0zYWxX?= =?utf-8?B?czV6TkFPMmhvL0dKVTh3RUR5MnYwRGN6Q2hpUzBzWXpJWlpNZHViczRtQkU5?= =?utf-8?B?OTJCelBnNXRRb3MzWFZUUzFoTGFqT0NoVkRTK3A0aFZuZUQ1emJ0MkxNcCtS?= =?utf-8?B?Sm83Qzkyd2Z3OHZ4bDJvS1Q1WVVmU1JBeHNNNGxzWTBSbzUxSlY1SytFeTVN?= =?utf-8?B?clZlaFZmaituYW8ybzFpUkt5a0hmTzRiMFVCU05FK1cxZzZlbFpQNGMwRjVt?= =?utf-8?B?M3kxTTVGU1czTi9RN0FSMmJMOVczYUIwQzNuOVlPMUZ1ZVBEWWYvQ2dpSkx5?= =?utf-8?B?OVp3ZkUrV3dwR2JvY1hDc0c0a2ovVXVmSUFxb0lJYWJ5eCtLQW5PeDB2d003?= =?utf-8?B?QzZRYjNSdXJ1V2tRMUs4U251SE5COXlzVjBOUkRuMGVrdWNDRVRyeGg0WnZX?= =?utf-8?B?TVAxUldPM0tlR3VKRzBsWDVWWTZwbVVDM0p1UGVYdGJHWFZZdVVPczcrV2tL?= =?utf-8?B?THdML09ZZnQvejZtLzRwZlFWclYzakJHa0NIWTJnbGx2SUV0dkN6YjZvamJP?= =?utf-8?B?MFpxa3JYYUxVNzJ1cUVUcXBHNzR3QXBNS2lXWkhSM1FjcG1KYnFJc1dkSlVE?= =?utf-8?B?dmhWcG90bG1FNWpxVHpYaFZWaWVmWTZCM1hUOExOYXdxU3pDMG9nb3F1bGEy?= =?utf-8?B?ek80UUVRRTE2RGZ6bnEySXBFSGZqTmF3WDJJZFV1SmdFeldNMUZxNExvSUVY?= =?utf-8?B?K1p6ZVQ5MzhhR3lRUWRtSHpMeVlZZGtKSlNMeVd1MnhEZ2d2Q2lUOTBiZW9Q?= =?utf-8?B?bWhCQzI5VVFEUXlFWjBzS2tZNXpFVlRMODBRUTE0YlNhVkNrNlRtNzQrcHdw?= =?utf-8?B?VkE5T2w1Qm1wMnNKcnRUbWtTek00dERNVEFyc0hEVU9BVnNMOW5OaGJUZHU2?= =?utf-8?B?T25lb1J3UStCWkF2QWRRR25kQ0ZnaS9WV3N0RzB5YW0wRGo1TFlYNFg5QjNp?= =?utf-8?B?ZjA1UkdadjVpQ0IrN2Q1eko2OVpXS3NpY1luWld6djI1MVFPZGFJc0duL09S?= =?utf-8?B?SkZjL2xoMkhrMC84R2NDcWsvMitldkZFUjZqeGM4dFhDQnJpSS9TWUVQWFZH?= =?utf-8?B?YURNTjhaNkxKaEFmL2o0ak1SZGJsMjRtVkkxZ25KQTFWazhobWpaTmNFT2dV?= =?utf-8?B?akdtY0ZCUnArMGRFNHUzM1Rpd0RCMFRHeVFDRlZKVEdoTUR0ZWdLNURMeDk4?= =?utf-8?B?R0lDaHUrdFZqN3hsZFBUckdXV0xnV0dCTVR1aGo3dU5VaUtkK05sSWx1Wmc4?= =?utf-8?B?OXlBZ1hUOVV0aHlCbThUQzJVUDFMdzRUMVFHaHlMamd4ZUR4SzJJWncvU2x0?= =?utf-8?B?Tkt4ZHF3RDhSRy81K3FJQnNsMFlWTCs0MThEdVdpWHIxNnpXTEhBYlM5aUw2?= =?utf-8?B?MjhEdm44Mnc0WVgyMWFPR05Ka0YyanBQZmp6VFNqS1JxcXBoeGJPQkxvZjhq?= =?utf-8?B?UDhJd1lleG5qdCtyOWpwcER2dEJzYjJKRS9PNEw3VklSckcrWVdna3R0N1lS?= =?utf-8?B?UEt6ZWdRb2ErNWFiR2lVa1IvcUVvZEtIamF5SlBtSFZrOWUwaG9qdVpqQnZ4?= =?utf-8?B?QWhMRUprams4OTJYVjU5U2pGRVIrV2h0VTBoZHFwMnRKazBNWWhxYStrRFYr?= =?utf-8?B?VTgyamlXZ2pabmlpWUN5NlN1VkljUE1JRXZiYXcvVXBac243SGZRZWxtbjAr?= =?utf-8?B?bHFaKy9lMjdOb2tRMXkxcFE2cS9xaDYvN0E2d0NpRG81aTJGS2QwaXZ3ZjU4?= =?utf-8?B?Qlo3SC9Rbnc0MFdpK2xjeEFmMDZHYmxRaGZDZmFMcUNEQWYydlZINnNvZnBM?= =?utf-8?B?Z3VKUDA1SUNwemVKM0ErZWV4Z2ZJUllJZlkzK3hxUHNoTk93Yjhkdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8677eeb9-8342-4748-f5c9-08df099024f7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 07:51:21.1476 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: kR8DlRcuNZLP/k+Ov8nf+MEUd8rsSQzOV5XxhRO+Dn3znUHSGjDQ3v4dIyYFT4pN99hetU58Dx3ZafKrAZOpDoE9o+pTJeLuEMMczo0B94c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB8382 X-purgate-ID: tlsNG-16d1c6/1788421889-FE47377B-EDD0B86A/0/0 X-purgate-type: clean X-purgate-size: 2137 On 03/09/2026 7:41 am, Jan Beulich wrote: > On 03.09.2026 00:10, Andrew Cooper wrote: >> @@ -273,6 +274,35 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) >> return false; >> } >> >> +static bool microcode_safe_to_load(const struct microcode_patch *mc) >> +{ >> + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); >> + >> + /* >> + * Treat pre-production as always safe - anyone using pre-production >> + * microcode knows what they are doing, and can keep any resulting pieces. >> + */ >> + if ( cpu_sig->rev < 0 || mc->rev < 0 ) >> + return true; >> + >> + /* >> + * GNR98. Granite Rapids systems hang when loading new ucode on >> + * sufficiently old firmware. >> + */ >> + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && >> + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && >> + cpu_sig->rev < 0x01000405 && >> + mc->rev > 0x01000405 ) > The erratum text says "to 0x1000405 or later". Question is whether that's correct, > as it would mean that it's impossible to update from earlier than 0x1000405. Then > the workaround text says exactly this. "Correct" is complicated. The text is technically correct when considering all pre-production microcode that Intel had during development.  It is not correct for production systems where OEMs followed instruction about which first version to use.  Specifically, 0x01000405 does load safely on the first production-certified firmware. Critically, >= breaks the aforementioned "more complete solution" (which can safely load up to latest even on old firmware) where I'm still waiting on Intel to adjust the blobs in the ucode repository. >> + { >> + printk_once(XENLOG_WARNING >> + "microcode: Granite Rapids erratum GNR98 detected. Skipping ucode 0x%08x\n" >> + "microcode: Firmware update recommended\n", mc->rev); >> + return false; > Should we additionally taint the system? Why?  We've done nothing to make it potentially unstable/problematic. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Sep 03 07:57:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 07:57:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406508.1639783 (Exim 4.92) (envelope-from ) id 1x22Jk-0003fC-J2; Thu, 03 Sep 2026 07:57:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406508.1639783; Thu, 03 Sep 2026 07:57:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x22Jk-0003f4-Fl; Thu, 03 Sep 2026 07:57:04 +0000 Received: by outflank-mailman (input) for mailman id 1406508; Thu, 03 Sep 2026 07:57:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x22Ji-0003ey-SH for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 07:57:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x22Ji-0001cr-8i for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:57:02 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99283d-bab6-0a2a0a5309dd-0a2a4503e436-48 for ; Thu, 03 Sep 2026 09:57:02 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99284d-fae8-0a2a45030019-d155dd35d16d-3 for ; Thu, 03 Sep 2026 09:57:01 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48433e9562bso430916f8f.3 for ; Thu, 03 Sep 2026 00:57:01 -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 ffacd0b85a97d-48448eeacbbsm11480338f8f.30.2026.09.03.00.57.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 00:57:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788422221; x=1789027021; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=zwVC0s7RgBYPakJyb8PmnZCruLYy2tXNZIysC6TdEIM=; b=WQAGKHHLcjsVnfxlOYOWPM/oaQJHlNMGORCI2yA/r2XTwbc2fn98dtZJxQEODyJXD6 NvmEAy5YRkgyJE82LZ4kcOYFIx+R8X+xOfv+yMrmgl5ApX7CTDlhqADCdqOJmekYQ4dX uEQGzl0UEtgjmsoUOJvhxVT7zXJJgSbm2SFO69OtMtmj9SbAjSkuOjwvrQbnj6Pb16UF orVSBpsqWreFsdkWqXvxtu4E5/zAwdyX9Ql0sIloMuTgRpe/c9DnCp+d0dCe7JRK7laM DFwOpviZscOJzntAnmOcSYV4M42bMF+JBagZUmd944UdW65vkSFjOmL5HYoegOwP0lkG 9l/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788422221; x=1789027021; h=content-transfer-encoding:content-type: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:content-type; bh=zwVC0s7RgBYPakJyb8PmnZCruLYy2tXNZIysC6TdEIM=; b=rYvOd9lpepun5sT0BGnTfwJcFKICcXx41SfkU2+oaJ9O1Zyw34xJm2l51YTUupqLbN UdQ8Qw6Zjg5zSx8Gj8svnuE9goEaKgHAi6vDYP0RsMyQkjpQFRftTgjO2KwTYvGTrtYg OEZ0O04a9BHW/Ucr+zWO0+tHKKnsAlAoAdWXAgNYEzAeCv+CYKTXwDFXv1Oxu0H2cql5 h1oxbwrGPgcU5hRbqg4PiMto2S2BTipSirAD6Fec5+AHyaSSNYTn8/SkinrhE7g29xwp Q4zke4COIulgw5GUalSv5qjdCfln+2PU2/VpTsqpwEsvpZH4ggLMzyXeTFFTKb4qj3V/ lhGg== X-Forwarded-Encrypted: i=1; AKwUvBxZ5uwubczKOGQYJWf2MHkpvb/99cRtk4JJ2V+22GHD52vGR4nBFyf3oYvkQ7xOaaf+2GdjcAmSc4k=@lists.xenproject.org X-Gm-Message-State: AFuF++k5udth/r0alw2Ug19m5yHrfQaTP+vh26hJ11kH61Myzuu6e0jE pyvZKl2mUvSxYwjfxX/7dN0Q+QlCIaZH4bT4AX/z40eE/CsooyGMuol5MFYGodczXQ== X-Gm-Gg: AYBFou2cXz0BPZD0UFi8hGi0OPWl3GFRuDC+h49oosnGEPkU4Y7qDe1HNx/SiXcnuSL c7/9zUeAzBoY8wP2/O992T4r5dlCgtt6A/nrm6irDSTMxafVZNY8pkfZLiAGRUP3uBKj+eYxIJh OL/75n5NfvwmQ65OfLNRTjF6A+gJ0oRWa1T5RUfSRmc3oAChUZeJBp0xqteUKVfSKtTIb/w9W78 8fEie/Y9ccTS34bxmtXeSfxA11XVi3/NpiVYKKZwFhq/9Bf3XfS3u5GaoiwFht9P1tGcQ/Bofel pmh3pTwCJuj2ZvcFz6T1JmNUHORE/3J8+RgQcto+5z9mRNVhlGWxP+K4Bb8KRey6FTVZGmzteV4 AqFGR3QCPAXDMZ41AELps0muc/ufwMETbAhW+LjIpR7VqaPw5U5b8LZJtsQQlQ4xF4TNlw0ghMx pWVyypyWVpNfOop7nOc6uMk9nxnZ/qRybBENZU51L82cq3E1UKweuQAKLN2o0PvgQsH6ZAlMMxY M7hj8k8zZRVO+hoIP5Nu/tgmv481WEtx9w/yAXSFpGm0Q0OMc6+ X-Received: by 2002:a05:6000:22c8:b0:484:4779:bcdb with SMTP id ffacd0b85a97d-48488deb822mr19125762f8f.6.1788422221346; Thu, 03 Sep 2026 00:57:01 -0700 (PDT) Message-ID: <2dc4bd75-f57d-432a-8d09-6d0bf7345fae@suse.com> Date: Thu, 3 Sep 2026 09:56:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260902221000.2967167-1-andrew.cooper3@citrix.com> <624b7832-873b-46a7-b1a8-9e7c20f45c07@suse.com> <76f8b54c-1e1c-4ea4-baeb-43d7b7996746@citrix.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: <76f8b54c-1e1c-4ea4-baeb-43d7b7996746@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788422221-778C54E9-41EC3069/0/0 X-purgate-type: clean X-purgate-size: 2507 On 03.09.2026 09:51, Andrew Cooper wrote: > On 03/09/2026 7:41 am, Jan Beulich wrote: >> On 03.09.2026 00:10, Andrew Cooper wrote: >>> @@ -273,6 +274,35 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) >>> return false; >>> } >>> >>> +static bool microcode_safe_to_load(const struct microcode_patch *mc) >>> +{ >>> + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); >>> + >>> + /* >>> + * Treat pre-production as always safe - anyone using pre-production >>> + * microcode knows what they are doing, and can keep any resulting pieces. >>> + */ >>> + if ( cpu_sig->rev < 0 || mc->rev < 0 ) >>> + return true; >>> + >>> + /* >>> + * GNR98. Granite Rapids systems hang when loading new ucode on >>> + * sufficiently old firmware. >>> + */ >>> + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && >>> + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && >>> + cpu_sig->rev < 0x01000405 && >>> + mc->rev > 0x01000405 ) >> The erratum text says "to 0x1000405 or later". Question is whether that's correct, >> as it would mean that it's impossible to update from earlier than 0x1000405. Then >> the workaround text says exactly this. > > "Correct" is complicated. > > The text is technically correct when considering all pre-production > microcode that Intel had during development.  It is not correct for > production systems where OEMs followed instruction about which first > version to use.  Specifically, 0x01000405 does load safely on the first > production-certified firmware. > > Critically, >= breaks the aforementioned "more complete solution" (which > can safely load up to latest even on old firmware) where I'm still > waiting on Intel to adjust the blobs in the ucode repository. Can this difference to the erratum text then please be mentioned in the description (or even a code comment)? >>> + { >>> + printk_once(XENLOG_WARNING >>> + "microcode: Granite Rapids erratum GNR98 detected. Skipping ucode 0x%08x\n" >>> + "microcode: Firmware update recommended\n", mc->rev); >>> + return false; >> Should we additionally taint the system? > > Why?  We've done nothing to make it potentially unstable/problematic. We've done nothing, literally. That leaves the system in potentially problematic state (newer ucode available, which likely addresses known issues). Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 08:40:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 08:40:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406560.1639792 (Exim 4.92) (envelope-from ) id 1x22zu-0003Rf-35; Thu, 03 Sep 2026 08:40:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406560.1639792; Thu, 03 Sep 2026 08:40:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x22zu-0003RY-0Q; Thu, 03 Sep 2026 08:40:38 +0000 Received: by outflank-mailman (input) for mailman id 1406560; Thu, 03 Sep 2026 08:40:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x22zt-0003RS-1q for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 08:40:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x22zs-000Cyr-Ed for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:40:36 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99327a-2eae-0a2a0a5409dd-0a2a4506a3d0-22 for ; Thu, 03 Sep 2026 10:40:36 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a993284-195a-0a2a45060019-d155802ccdb1-3 for ; Thu, 03 Sep 2026 10:40:36 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-498028b3d5eso22115185e9.1 for ; Thu, 03 Sep 2026 01:40:36 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce47b9817sm99477295e9.1.2026.09.03.01.40.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Sep 2026 01:40:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788424836; x=1789029636; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=z2kd8yy098YwLOhAkPABv3/vm8TT/oYlA03PQA2FRSg=; b=f2mqoD+CwbOq/Iq+kwAiymqHxihp4Z06sxWw5wmfw+IGgxVwrJGQ6fEsJMMNmLxytX ciQX/GrIn9ZluZR3oYdl2dkGt/THYu47LgSel9AgG1OHKxS7fduXNry83Nh2084hwoS1 M4pG3IkOvNX8y3biws0Se74l0u+DboZMFtll3Pnb/Jz1BlqfUDQQQIyoyU6PK+X++sXC /uAgSlWVv6g9jdMkm2UL4jaOirgqEsTvqhLei9+kyN/vvwwX6ermCktILuIKmhrvGv6x X0dB2C8z1b9uwdtrBWejalI4vf5u4/cSqjh0kXQCI3ywSRf179exmYe4RNjgiaADl1dA P8Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788424836; x=1789029636; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=z2kd8yy098YwLOhAkPABv3/vm8TT/oYlA03PQA2FRSg=; b=k0dJHTLfWeqlqXAzCsEloJ13d1U2E4EQOgs5ONfa8u8hacESyGEihGvvc0ptrd/GVY tt45+PiKOSVQmDMig7AnGlbC1P+D4KaH7raZpzl2j9/BC51gjmqJ4Ix6XpNJmqhGwhvF w9jwGm67wvQ0AYk/VrM4fyMFxbgpdq/W152/iXx3XgquDMlxgSkNoX61VdIrHDV/NhJE +poMlQbAKmh1N6dTPD9nNasRHRmT1QTCd6yrMA+OfxsqulXsqoQiFNI/lqNRnhvXyy9j H3q0JLP0CV5OvXKIXuvlFQvbHAVo9DvwQ8IgLRTKphVkwqBjAGiTSekITBme+Kaij8yg gFDw== X-Forwarded-Encrypted: i=1; AKwUvBwzaGocc/6TDqXMM5yYgpHCv/2ig84FKzzZYBSA3tzWGCTAWgiRrhGhgljr1NsPp+39Ewv8uWE7s4o=@lists.xenproject.org X-Gm-Message-State: AFuF++nbPYBGWMw6Wy12GcN3WcWACWdTV3aNQS9rB6D1i8QM1iXGulij wxjpqWOcDnd0Fme6koN4y6MDM4UiZEoihPPgfPeCCKnGcflcLxL+NqjY X-Gm-Gg: AYBFou0I+TqXJDlce62KpFKrJAWYeHLceKr6lES0xRWXxClt/1SXaPnPm7oUQDF0QUX kwUv387CJznXgyh41240JiXEF2YPZYsImmQpZMbVLFw6v4u8PF8tTnDBW+zJvOauzdruHB5G/Sx 44Odmt9uuU9g5u5ej7Dh/bpke0bzMof+gNc+Nkx88kJ+AblIBWSMcpiL5Hy7lhn8gADLYUJ4eVj 8/Lu+5xdiNKhJEZ51k0WoVVVxdZDNWJNVsG8mCOtswqWR/Q8TH7WIagbR9Skb3pXXPGoRAv5PG0 72i32jkGXQ4pkRFdf60q74Jr29jX5OVBHp6gW/0Vq1KSS4FyLuckdn1pyTWIOgGWaR6Yn6BHlnT Ur3ECTyyYr2tLDCNJ49RYCsjq9hbW4wMOluMBtPHKeTQgMunkqcDT7lvcdd49sC91FYoNE+PC6g fNcWIN6remnpTzICJfEhq/MwVNfC7ckHYHCsHftHUsfOeyMZT6CJ/L2lKyMWrEYmc5j6ZZUQky2 Sja7lkv9Ee/BY6Bih64YmG1f5JQ5zs59Yjf X-Received: by 2002:a05:600c:1da1:b0:499:9eb8:a1d7 with SMTP id 5b1f17b1804b1-49ce5842935mr226059755e9.9.1788424835605; Thu, 03 Sep 2026 01:40:35 -0700 (PDT) Date: Thu, 3 Sep 2026 09:40:34 +0100 From: David Laight To: Borislav Petkov Cc: Mauricio Faria de Oliveira , Michael Matz , Richard Biener , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() Message-ID: <20260903094034.489b64bb@pumpkin> In-Reply-To: <20260903000132.GGapi43JjGh-8sj65Q@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-1-e70ef3b75b6a@igalia.com> <20260902023129.GGapeKgVlL2WgHcJcb@fat_crate.local> <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de> <05896397667d66a2969259298bcebb7f@igalia.com> <20260903000132.GGapi43JjGh-8sj65Q@fat_crate.local> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788424836-F500977B-326D1C26/0/0 X-purgate-type: clean X-purgate-size: 755 On Wed, 2 Sep 2026 17:01:32 -0700 Borislav Petkov wrote: > On Wed, Sep 02, 2026 at 10:48:14AM -0300, Mauricio Faria de Oliveira wrote: > > Boris, I guess this may be added as clarification in the commit message. > > Would you prefer another version with it? > > Yeah, I'd actually prefer it in the code itself so that we can find it easier. > This file is as good as any. > > Something like this: > > /* > * Summarized explanation that "cc" clobbers don't have a meaning > * > */ > > and leave the "cc" clobber there but commented out: > > /* "cc" ... */ > > so that we can grep for it easier later. Why would you need to? Apart from a scan to just remove them all... David > > Thanks! > From xen-devel-bounces@lists.xenproject.org Thu Sep 03 09:20:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 09:20:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406598.1639814 (Exim 4.92) (envelope-from ) id 1x23cp-0001DW-8K; Thu, 03 Sep 2026 09:20:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406598.1639814; Thu, 03 Sep 2026 09:20:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x23cp-0001DP-5c; Thu, 03 Sep 2026 09:20:51 +0000 Received: by outflank-mailman (input) for mailman id 1406598; Thu, 03 Sep 2026 09:20:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x23cn-0001D5-8e for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:20:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x23cm-005cJw-LY for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:20:48 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a993be6-8faa-0a2a0a5109dd-0a2a4504e442-46 for ; Thu, 03 Sep 2026 11:20:48 +0200 Received: from [52.101.84.33] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a993bef-b57f-0a2a45040019-3465542180bb-3 for ; Thu, 03 Sep 2026 11:20:47 +0200 Received: from PAZP264CA0120.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1ef::19) by DU2PR08MB10158.eurprd08.prod.outlook.com (2603:10a6:10:46d::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 09:20:44 +0000 Received: from MAD0EPF000008AA.eurprd04.prod.outlook.com (2603:10a6:102:1ef:cafe::5f) by PAZP264CA0120.outlook.office365.com (2603:10a6:102:1ef::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Thu, 3 Sep 2026 09:20:44 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by MAD0EPF000008AA.mail.protection.outlook.com (10.167.241.182) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Thu, 3 Sep 2026 09:20:43 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DU4PR08MB11030.eurprd08.prod.outlook.com (2603:10a6:10:576::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 09:20:10 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 09:20:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=Fxtfd1xABnQdOirXxSQtzmz5mmyEgKMu9Fg6y0n2zyeIqx+D/S8EZkH5o4tom+3NSfDiwxSR9ZuJAkyMIoHEQxgx6fnboVi40HfImla9uniuTeokAGVnm0GonGNQsrAxfRjQPRZ4rV8ZXdrsFlLr+bS42Jd/lh+hNpikuRLC9/HMtGbruGARTe0kvEhEv3ZsVRIQ7+v2lfN/NNZ8AhdSGtwDuVhLJOD2EATotMeleZrP8REtnuo8UtruBZhLmCWADU9O/rryD3tOm+oceioNvIuehb+vrIWujtWXQXvRuAxu2umif0crjwhu/gRXASc5eCulpFcX7Z4sMPB4yDBpNg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3hHuL4I2oFm8NvTfq0T2CtO+nJ4iac649hs93dOGMrY=; b=umIGJNP15wpWQvvTsf7hmznX3q0vrgeosGaFPTrZKpjFssvSDwiKFaQ+ewZu/GpWktjnsG0Xek4LxFTNmfMmDEYp/H1kFjq69CHfVSEuC4LKYYyd1QelEQ2Y1k+pMKuHFPfVThiZR/NzV/KRB/ftN5n0TgclFFgJVa/mSVnOCMBbXR3HEv790ycuWoZNXcnysUD4st2TI7xX8LTwvaxzpOoe6TwruDDCXq6H22PhZHCA5XtYDuhVkOqjGQwf5ytFW+Qz88SGoBXXUwRoZkz0rdaOL1tMAAvoWApa7DMroKLRhh3eIOGor6WtWEZ7LeJ0C0Ot3K7vRf0YT0msteOh4w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3hHuL4I2oFm8NvTfq0T2CtO+nJ4iac649hs93dOGMrY=; b=GoCH1di3DLfm5JIDhxeW4GPqKAn1+vO2uZHeYe/rWSlZhIqgnklMqm92gbpTbhypQPtBN6MsWVWDN/n2xID2KJWjRWF9jRWTuD1dgYZ6l1/EzL+S/IGQJTuT3JwQpyfhcXoED0dEv72Tjf9kARRZrbZKtYSnGyCxwSNCaH6qgv0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ok9ioLAQbeLQX7SbXtnpGYSGVg8GsquRl3it6/4OJdQPK7sypdMKvBYRnW7MKIutvsMYUEC/Yc6C/Hv9fMsxxW7WQyXGkQIfoBPq4kLIq74iaXtmyuB55PLP58cqWqEnFPgrRQ6xnLnsnDx/P3lbc3R1mR7KPuIGQDT/DAAsRHhYYQXDNjGVBPJb6YjxdXhamM5TA08kSnTOO6iRKHBrXtwOJSkEPrrA5b9vEYFGT3PSodRsIrzQ7Ymtg2n18UOO2FFU7R6AYbCKOB6jHKfCEYAnu1aYMpZQKxUx/hJhe+4w+cPa8isyMA7H00O1c6slEJORmFs6Fe1INkfB8mNk3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3hHuL4I2oFm8NvTfq0T2CtO+nJ4iac649hs93dOGMrY=; b=WY+Y22XLq4hQF4rGKjuoWfEqOZ98dFL8/4GEa/W2MHO0xlCmKA0gsknLuDsbCD5FYNkgUY0E5GhU+eDpn19fGwVeydf3fQqPGjfhYWNPSBY6s4qjGrB2T5TVfkuZt2p3Dq1EYxZ/bIE3yWCFqNFXqKSw+hz8ZZXhMedAd4+pp93OQVml4tOrRWL2eNxY7bqZyQ7JGaWCRiFAqN5qbEpCw7+dx04NHnH2aD0B8Ky4K3oj5ry6CulkonGlFcSGtlyrvg+4tTvG8OAZkq+wk3Nxah5pHfOZTh7RJ1pGdisQC9NShb3cpYnhXycqXf+lUuy+FZeCbYG8Yio19xykBfUVzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3hHuL4I2oFm8NvTfq0T2CtO+nJ4iac649hs93dOGMrY=; b=GoCH1di3DLfm5JIDhxeW4GPqKAn1+vO2uZHeYe/rWSlZhIqgnklMqm92gbpTbhypQPtBN6MsWVWDN/n2xID2KJWjRWF9jRWTuD1dgYZ6l1/EzL+S/IGQJTuT3JwQpyfhcXoED0dEv72Tjf9kARRZrbZKtYSnGyCxwSNCaH6qgv0= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH 0/5] xen/arm: Fixes and improvements to SMCCC Thread-Topic: [PATCH 0/5] xen/arm: Fixes and improvements to SMCCC Thread-Index: AQHdOUMI/reoS+h4I0eq7LCk/pFqt7a8mEKA Date: Thu, 3 Sep 2026 09:20:10 +0000 Message-ID: <646DE9C5-6708-47B9-A4EE-9111E101A038@arm.com> References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> In-Reply-To: <20260831121944.2908139-1-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DU4PR08MB11030:EE_|MAD0EPF000008AA:EE_|DU2PR08MB10158:EE_ X-MS-Office365-Filtering-Correlation-Id: ccc16853-0a11-49d4-01c4-08df099ca179 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|3023799007|10067099003|22082099003|18002099003|11063799006|56012099006|38070700021; X-Microsoft-Antispam-Message-Info-Original: pffjMcBtOlpxsIQeNUXXB1TBrgOj0uWHjH+npfC6NdReAcr66A0IJ1sUKSNAGrZW7M56QEIxzjgs0UWGB1iAinkEDrfELDft3BkKfDo+o3QtGpjAqiHn7opMlhv955lRKd0LbNoxBheEx9CGwgUlX9OBJ3CmynnjqJ7tHiYzwn4Dw70KwdB9cAHoNqs2p3XW9KyQ9t98ur7KCnqkYQNg+8+MiVkTW+Sxuz8fhkFHO9ua/K3TEcnukwjOtrNokremzHQATwh3rT6FZOIL2wyK1KJwBiIDHssmGnEHjI2M1WK93xTsALvYmeMCTJj32Mole7VP7vqGijXAL3XmYy+ck1bIjT6odZ9PFuVh9WDQi8bfuUvNS0hzCJrg//lWmB+0ZiOp5pWn8Rw2oI8/m3H4Vghm895z8xAEXoruzl9SwjZN/r/XGFqlAMWztgYG74KwQNtdpXRLDS5ad+uo+8F4tF5rQZWwOQoJN5JUFPmPiKFeHdpJqfKTfJ//MOa5CZ57vrLg/rGSlyx4sUper3c8a6QhVYXoTuNKMn8eSDxeBURJAOZnjKDvmMp8Ovi876nMc33ikJi+WQuw3AWKPEQ7UowH+0xgkTQYwDUZ/tWSWFsdFWkix4OVgw2i9EKuL9elIqZFJdK00KneUL3BQwAWcX/YT6ZVS/6efgy5DhcT3pSzv4/KMs2YENaikTcEXCFgrW4rf1O2qJZZr6NgpzcrTAazht06Kj5McdJw6nRr2sE= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(3023799007)(10067099003)(22082099003)(18002099003)(11063799006)(56012099006)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: L84xysjth/eGKeZSuNhfbdu/O2Np5mlZNNAUZHUlDCvYLg5xUuOcHXHntJONycQE9ZIt9qJf+CLS1LiZTuIXThD6+D5mREpuVNfxEjitdh3nH3HswqZgrWQiWO3MhSpA0LzW4mIaYSWL6/vVb1ayLNVtcQOGlu84XQsrAhwYHZVgOsEJ5nBVY5lRWhdOtgTpI1SFhZ2HLkzcdPP8aJLoL2YoV4G5hjwsyKSapF+YrDmQVx05RopjE0CnhRJGioaazlvUVUDQga6kmHVebGBFSNLqVv34rA2g//mBwTAyAy3Ls94vG8F+VKrVwi0vu1DQ3s3e5pvcnTUg3RxQDjpddQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR08MB11030 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: MAD0EPF000008AA.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 4e9bc255-b1d8-491a-1298-08df099c8d64 X-Microsoft-Antispam: BCL:0;ARA:13230040|14060799003|23010399003|1800799024|35042699022|82310400026|36860700016|376014|13003099007|22082099003|18002099003|11063799006|56012099006|3023799007|10067099003; X-Microsoft-Antispam-Message-Info: JySbLsGICJI1pPTVSZ3WQDfaI8/38d7NqENKY7oekuQIHet/6eeHAfWOJgiQtI0YUpn8Stk2T4mKc4Ie24fBb/+K+5KLKsIJDfZK/m80reAjw3QjUfLzqWCDeiH45OE5kI0igcTbK0A/6odaqEns5h4XOYUgqD3I3UOrYESmVDIerC7wSvTTqb/b6FHPrJ3d9TaJov1YMYdn7GJ0C1yuwyBoXNXdxesUFaDwFrGp3AboKYJksUZNbGMsmNPq5JupuVIFC3w1oK52ylLEZvvkPsxX25SsnbtdiaG6b18d3gIchwkK68YQSiRvlNn9xxwvyVu/ZS1k/J83f757BGoxqlzIMINhjCMZcXPkdpx9VON+vDT2nhoafy0+P1NDntFDb1XsXWigtmXaYmHxwQSHinp9tY4iaLOg+QEGrj7nomt9+8MX+HUcj+O2o69fLhhzV5lWpIZsDmO/PIerctk3Nu8Tg8/c/jBNKoLAW4/SCiWs5RTZxZGJLHpSd39UizBKZFUgtzgVHxSJin5biWdyn5n2N36TVzma2XjYgx71quB3A47O45EftzUZtl0iEm86/a1huBYpLdkfvrfv++5cBntrOeYR/Bqe+jvhfqMILESQe8+kXh6G1bvWJzYDOnCy+zA1zEvHDXMwQUFsOlrLZkjDqO9Ejwfi3Pab9ggvTg4= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(23010399003)(1800799024)(35042699022)(82310400026)(36860700016)(376014)(13003099007)(22082099003)(18002099003)(11063799006)(56012099006)(3023799007)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: JFYBHOtIKbcVqCHVtWuPuqAnPfOBpGw+BjMS8E8x9W+91B4vhUxodbqwNF0gYZ5Q7geGDIFT/1TL/z2PF7SSEotwxWXTZsYs6H+Df+d6mVY/wNN7Rd4hcSojjx2SvQ9TmAX0VTm7am1LVu0pn02w7lHOElhybSgDYDUpzwFPZvfgcvaWpAT6oSOgfzyergBXSYzIuPjZuP1d4NNODWvSwa3WdjUxxwgAlZdzJ1xDju8ZtURzQ5uqAFKWKOit1drunuM9He+8CyNqq5mZMg2Qz5XKtET/CsZ3RlF/qEYjwIW8iy6T0ajIuUjlDa9ss8rGS+0pk2xNzHQqZZxhvRi29rsY1anyC2xN1+YN7nj+1Hy3H9CVuTeOP7/5Sx1LAkvirMMiNynBSpoiJOC71+brM9CHFmwprzoOIWZ9C+t6Ti38gLdV3PUBhFzWTIxZFfjF X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 09:20:43.6911 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ccc16853-0a11-49d4-01c4-08df099ca179 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008AA.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR08MB10158 X-purgate-ID: tlsNG-ebf023/1788427247-528C9B50-9187EE0E/0/0 X-purgate-type: clean X-purgate-size: 1686 Hi Andrew, While reviewing those patches i found out that cover letter is saying that = the serie has 5 patches but then the patches are number out of 6. Is there a patch missing or something went wrong in the numbering and there= is actually on 5 patches ? Regards Bertrand > On 31 Aug 2026, at 14:19, Andrew Cooper wrote= : >=20 > Patch 1 is a bugfix for the issue reported by Jan Setje-Eilers. It needs > backporting to Xen 4.22. >=20 > Everything else is because I couldn't bear to leave the code generation i= n > such a bad state. >=20 > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/280540979= 0 >=20 > Andrew Cooper (5): > xen/arm: Fix evaluation of parameters for SMCCC calls > xen/arm: Introduce arm_smccc_guest_smc() > xen/arm: Clean up 32bit arm_smccc_1_1_smc() > xen/arm: Rewrite arm_smccc_smc() for arm64 > xen/arm: Rewrite arm_smccc_*() to return by value >=20 > xen/arch/arm/arm64/smc.S | 16 -- > xen/arch/arm/cpuerrata.c | 18 +- > xen/arch/arm/firmware/scmi-smc.c | 16 +- > xen/arch/arm/include/asm/smccc.h | 241 +++++++++++--------- > xen/arch/arm/platforms/exynos5.c | 2 +- > xen/arch/arm/platforms/imx8m.c | 16 +- > xen/arch/arm/platforms/imx8qm.c | 16 +- > xen/arch/arm/platforms/seattle.c | 4 +- > xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 17 +- > xen/arch/arm/psci.c | 17 +- > xen/arch/arm/traps.c | 4 +- > 11 files changed, 165 insertions(+), 202 deletions(-) >=20 > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 09:20:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 09:20:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406597.1639804 (Exim 4.92) (envelope-from ) id 1x23ck-0000zU-1r; Thu, 03 Sep 2026 09:20:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406597.1639804; Thu, 03 Sep 2026 09:20:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x23cj-0000zN-VU; Thu, 03 Sep 2026 09:20:45 +0000 Received: by outflank-mailman (input) for mailman id 1406597; Thu, 03 Sep 2026 09:20:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x23ch-0000zH-VN for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:20:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x23ch-00CKRo-4p for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:20:43 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a993bdc-2eae-0a2a0a5409dd-0a2a4505cc2e-46 for ; Thu, 03 Sep 2026 11:20:43 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a993bea-4cb1-0a2a45050019-d155802fb97a-3 for ; Thu, 03 Sep 2026 11:20:43 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-499b2981a7bso22316345e9.3 for ; Thu, 03 Sep 2026 02:20:42 -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-49cee5dec54sm66723905e9.12.2026.09.03.02.20.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 02:20:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788427242; x=1789032042; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=VPnZU8Fk7i1glkEtaHqrSSe4depEmhgbzuFlNVw/JT8=; b=MpEVZMaAcGDQhnuixUAR7En2mA1+Nrggg+lXLlTZHLcJbi9Rinr9NIHpEMCYiEVNti IDs1y5MwMKf+VSjAzl0aM0X5ljz7HIuG1G75x0x+OnzsydSjw+nNLDRL2V/ZWewOBr1t x6pYdTo4lMppAqKwvSKS8BrOJkQ6vFyetkMz7r1vt3/e2adL7PIKYSF9BTHrjJJvUMu/ jRru5agjPlf9m64CIDLoN0lfe8J1of9EYymDw/hTANsDfWaJB+XaGaEYrPn38nW0NkTf P/1K6mmvQWv1yyYEL1P4v3kE+Qgrm988t+g90qKOq6ldiJ1UN2+JxQeGCyBkXewdnfZg Rufg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788427242; x=1789032042; h=content-transfer-encoding:content-type: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:content-type; bh=VPnZU8Fk7i1glkEtaHqrSSe4depEmhgbzuFlNVw/JT8=; b=hqrtwEPem0GBkSMZ+qQnTGHW0siR2lxJUqxC4rl0E0HwdUDbKbQVxriKD2Ecbcc5k1 jr8a/66lFubn6S0S7Yt1h9/iYTeLEhaUj/FMn53LrpEatI+7y81KtHcWLrrbvn6yQ2/1 8CVyUsQusUhCdWWGU1O27cZjT7D4lXyYRmdwD71dz/K4gTDHWw7XGxpY1J9NKtRtSn7x TjcBqm3+ek9cGR29P6tvSt3079eoRCFCE6BNeS8TFqDpX8H6LbjmsX8c6fjqS9w6NOgr p9ROu05oDxsHll6xOMJofxde4HbIpgJszqdNnVSF4WeOu2DySKdNvF7++FBK6KjIIoAC 1XCg== X-Forwarded-Encrypted: i=1; AKwUvBwv9+EaGLWhXFgtiI5coGJjR4U5Um4QfxFEfLlZdmjpZdfci5T+IIZHHQTOjmgSd+X++ArgAhDFSHw=@lists.xenproject.org X-Gm-Message-State: AFuF++lqVL+HYbkZnlvB9E02vfWGxWSWuOjPIr8FdPNnt0/6AX9bv/Se QJsISew3ovgRkAluTIxpG9M82ReJZpbuZq8gx983hiOvVcZNWzuQNZCX3wZiSCpepg== X-Gm-Gg: AYBFou2sUjHkeCi1/Tmb8CrsjQ4oSLI4N9/1RKToCfknkNfqImkhl4YN5RIrTzYlP9z JOAjv7di+KBN8vcrVOMmBevISHl6R8cnSg0pUQAWhE0PdSUcoak0mNEqkEWaEYvM5JzaDVKqllD B+NhcVvqw5shcI0vH8eOO+ePRmabuNPK1Yrtm5ZEUIhg5PZkC5iYlKcPBcvIJtaM3rR6/ESl/Rc fGr34H+Ji9T0IGZppMwZyAgUkRT9P/P8+1Adcy3kGPpBLfNuxp+wDwUzP/62uQ86gHN15x/l+It LqWdAErk+WRH/dDeKsvBoiB1Z5U7IKNXBCgyoNEItSU/mi32nI9ePtnrn6nTOuWDNnsya91nHDU J6eL6yGdBEZSHN5eFu0Ykl4NBxVQRHAZWvMsHqlQhQJtMNEnFPwXsXIz6Zed6DB2nBC5QJQjAm6 WockCrGx/HSclsq0gRUW9PzbRpRN76BCnxi+Tf0AK62T2wnkuAmJT9H5A5iNwcTz9lpN+mkI/6M oCzdCFFkjfo+b/vqhysSXS/8+36xEqPq5PnWDnO9KnPG0aJGQQA X-Received: by 2002:a05:600c:1385:b0:499:83f1:398 with SMTP id 5b1f17b1804b1-49ce583e8c8mr177678425e9.9.1788427242320; Thu, 03 Sep 2026 02:20:42 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 11:20:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 13/20] xen/riscv: introduce (de)initialization helpers for vINTC To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <688352e340872a50af99a51082966669787b1f72.1787836900.git.oleksii.kurochko@gmail.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: <688352e340872a50af99a51082966669787b1f72.1787836900.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788427243-24B1D2A1-6CCF2F7F/10/73395122804 X-purgate-type: spam X-purgate-size: 1172 On 27.08.2026 17:19, Oleksii Kurochko wrote: > Add common helpers domain_vintc_init() and domain_vintc_deinit() to > allocate and deallocate a virtual interrupt controller (vINTC) > structure and initialize basic virtual interrupt controller registers. > > domain_vintc_deinit() isn't called at the moment as arch_domain_destroy() > is implemented as stub at the moment. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v8: > - Add call of domain_vintc_deinit() to arch_domain_destroy(). Why only there? With ... > @@ -308,6 +310,9 @@ int arch_domain_create(struct domain *d, > if ( (rc = p2m_init(d, config)) != 0) > goto fail; > > + if ( (rc = domain_vintc_init(d)) ) > + goto fail; > + > return rc; ... anything added between the newly added code and the return, ... > fail: ... you will also need to call it here. Since it is (supposed to remain) idempotent, I think you'd better add that call right away (as long as domain_create() calls arch_domain_destroy() only when arch_domain_create() succeeded). Then: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 09:36:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 09:36:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406630.1639823 (Exim 4.92) (envelope-from ) id 1x23rj-0003ZZ-Js; Thu, 03 Sep 2026 09:36:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406630.1639823; Thu, 03 Sep 2026 09:36:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x23rj-0003ZS-HE; Thu, 03 Sep 2026 09:36:15 +0000 Received: by outflank-mailman (input) for mailman id 1406630; Thu, 03 Sep 2026 09:36:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x23ri-0003ZM-EQ for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 09:36:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x23rh-00CNyi-I5 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:36:13 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a993f87-e002-0a2a0a5209dd-0a2a4506918a-16 for ; Thu, 03 Sep 2026 11:36:13 +0200 Received: from [40.93.196.28] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a993f8b-195a-0a2a45060019-285dc41c7018-4 for ; Thu, 03 Sep 2026 11:36:13 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN6PR03MB7765.namprd03.prod.outlook.com (2603:10b6:208:4f4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Thu, 3 Sep 2026 09:36:07 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 3 Sep 2026 09:36:07 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bn1HONFxVDLeDcRszV3W/D8PA4GDA14ustwYDfzje7sLm2TjBEH4bACnpV4jTBK5xVoNUQVbaIzdIknvpmJLu2WJQTIV9pVSXy+VnlaWX6YL6PkLldmxY0age9N0xHsaDVhbu3Br1UqKcPYZ6FNsD/xw67Kib0dUTJsZaIzPCJ9QlCTIVc3BO4DJVgl3gA94PbP55nwqZYoTjK00/3NHBxxFtdNl/1RPWkmfYrphWJ0lCR0JFDhlCLOZ1KTABCv/Y7pKgmZTks1xgmdaLy36NWSmEHbpoCRui1zD670dfP79IYTYIpHf9Ln8wUy2MuAfgyQ+xPWFevR268duPJ+F8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nGpjHWPGW6tkt+WCWcxyIvIVJukJxQD+XnWoThcmq/Y=; b=EUyHoOMdMpJYbtsI7YTslatj+iY3C1s73d/tidK+J1QeR40O3upyeOX/nRq43o+R2ciJDUvU6sps4akYyjOlJdY48f+AKAStt3FnSG/g0CH6jNtKevZQgY47FCzUACHkIwxJpayONWLVF3uIrzeKfLbidWXp9w0xE8abbv+032/bywzcm9ENvSSEjWGxo8tzrt8gt7fFte2MJsrrKg6vq60XmFqC6qgDjfeixI2RH2Smu80eXV4qOGimr+1Sk/cUTQbCOw/qqoOxsthOYgULOwIUoV2xAgPTNVam1KQDPyaB9K7iLuyHHY9sf1IswUHVq34p24UhPNT9Spl1vNDp3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nGpjHWPGW6tkt+WCWcxyIvIVJukJxQD+XnWoThcmq/Y=; b=pDpYSmaO5jvrbTFiabCkE2Nv7TxEgkw/v5OacMiwFlFO2Z5+TkObMqBDhnbBhu407uENLltFvhZ4jBBW/EIby5fkBo1NyAfXYjFSH6FIj0APyndYho1Hsp24GyTW0Imw+Asn18BL756eeSQP28snyz0cLhT8Wid17NQP6iBkizw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 3 Sep 2026 10:35:57 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH 0/5] xen/arm: Fixes and improvements to SMCCC To: Bertrand Marquis References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> <646DE9C5-6708-47B9-A4EE-9111E101A038@arm.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <646DE9C5-6708-47B9-A4EE-9111E101A038@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0374.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::19) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN6PR03MB7765:EE_ X-MS-Office365-Filtering-Correlation-Id: 4b5c0449-f5c4-4c91-a416-08df099ec822 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|10067099003|11063799006|4143699003|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: mtbsy/oWpti0J6L0K9P7/B9uS/hUCI7l/5zgHLkl5hAU5dNey/jaQ3SbDoIzx+JaS87FAMmbM5pE9mOpGLaebu5Hw1SLLPpYLShaf56+pqLaun5gFxMmMAEDknGYZPUm9DCUqqknx9t5zvF2M6Dt3ZnQHOHZVetRxJRVvpxnUfzjt+FstRgKXfv6CeaUdOb90a+gsLSr3Rsk/ySNQaMqy1N7oOW4OKi/o1r3tqGIVoGj81Hua4e/fNPQbyojAnDI/mTB144JfE6yRqlkOTA4vbPN5nGXL3Y90WlQiZfbb48hRxujebv58l/eMgLIKH1FHLGJIr4pKWfX6lD8jy4XjbHpePHVNNwAmGon/TiEAIQu9sd8Zb3S0uFjK7oKo9plJq4oGLnNyMja41PpYSj8Yduk34JEuGc8WEikkOM2XnwqOxl4Eo2VJJaBAWWPkDfghTwCJKiKaVcYa56r2BWiigeFcPmxjXNKyVC3P/+9HIk8PSbr11/INnhoDjcMuUfWSZTOgZrapXnGpigHdJq8MDukjfM4TU9vadDnefWPMXodzaCuEl2nJB6LGNjbqENMOGU00rcUNXD7EOxdkBn5UD3aq2iVTP8VhJ+ngZvkYmY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(10067099003)(11063799006)(4143699003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R040OXRieVdVR0QrbC9HaDk1bHBnTEtFbEhvNmF6WGloR2tGOVVTR0tocVZK?= =?utf-8?B?anh4QkhielpQM3lIMUh6MkFMVVAzWmdWUU9aSU9qcUVrVE1hVzVZcUpCUHd0?= =?utf-8?B?NnlINURGM3N3VndOQk5mbnlmbkZBdFU3UWk1R3lCaUhVcUNrR0pwU1BoNE8y?= =?utf-8?B?YVBzenZMNytaOUZzdXp1THd6azlkRGppcU9rVnVnWm80SC9vZFFQSm9kT2Iz?= =?utf-8?B?NkxIUUJETXhwbC9NZXRsTHdLSElSK0dNRE44OUtSMTBqQ1NaYldMSXk1NzhI?= =?utf-8?B?RUM3RlpyNXFCQnYxV2lKekN0SkE1Ti9IR05LdExNVzc0b01RSXBhYnpGUzMy?= =?utf-8?B?Y1k0U0F4cE05S1BhaFo2N0pFbFZGYkdhb3djQW9zSThGWkswQ3hRQ2VIa2k2?= =?utf-8?B?Q2FoeW53VGJhSEpOcXM1OC9iRkRYNm55ZlFSTGNDd1FLNGxSOXRJTVM0Mng3?= =?utf-8?B?REVXeGM5OGRHZ1ZCQWZ1REFENEE1THllVWFYV2lyUWdTVTJZYnNWT3Y3Ykxk?= =?utf-8?B?N3o5Z2RNaDZHTFV2N2JvSGVWekRISm84cXNjTUZFSThXcUlSeDRkRGgzeE9S?= =?utf-8?B?dndxc0xwaTNxaEhtRUFoaTlxL0VVQWRuV3RJbENWWEwveGNwRGRJbUtTZysy?= =?utf-8?B?Q2lnbWdQbmUwTEpuN1VVeFg5cXpPdnhhZ3VYU29UZ2c2OGJFc2pvNHJzQVRp?= =?utf-8?B?aVY2OUV0VTR4ZkZPS3lsVXZQQlIyOWdnN0JGbU5ySFpwMzB6bnJxaWZEZVoz?= =?utf-8?B?bWI4b1FOQ3ZpQ1VUeFNQL3NVbVh0UXEwQnViRTdxalpNS2ZFb1U5MDh0bzRi?= =?utf-8?B?YVArNmNpKzFPWnhBdVUxWGViQ2Zqbk5UOEdUY21rWFIzNFJieG1HeE9sWENx?= =?utf-8?B?SUpVTUFHRGF4dWorM1JMY0VZSGZ3U2l1b0d1UC91MmMxYmZ0am4wemVicVdi?= =?utf-8?B?OS9tWjZxYXlvdTVPMmIwc3NLdElYY1FRNDZ4dGFQakxpT0R1UUswNUVlcE1X?= =?utf-8?B?TWhMNEwrdEY5TUNJK2p3ZFhWZFdPU0Mwbm9MQkpLdm1idk1wWGt3TGdjVm1E?= =?utf-8?B?ajJJVG9oOUpLVnk0eHd2VjRRQWcwTlk4dGlaK0hwV1loTGUzNE41cVcwcWsx?= =?utf-8?B?Yk9sMVM1b0lvWnYvTkhObjhTN1hmRVNIMTBMOUZweTdlcVU2TzVFSXkvWENS?= =?utf-8?B?eTIvWTZtMnl6OGpqU1ZURzNtbUgxVEwybUxvbXM0em5vbmJNK1BqR2pxRFUz?= =?utf-8?B?YU55d20xVjd5eUVkVmNlUjhtRzRiZkVpaHhTbklyQXNwYUJGbS9OL1pOd1JZ?= =?utf-8?B?NlZKT0NoMDBsNW9TTDFiZEZEc25rTWNQcEQ1cXhDQjNvbTB4Y1g3cFlpSnpT?= =?utf-8?B?cE4raUQzUFdidkUxazE3Wm5tbXhlYkNvYkdtYUFib3JGbmJueFh4K0FBOFVt?= =?utf-8?B?MG9zeEhMUTdyN3JIaWd6bXVSM3BYd1BYYlVFbmdSTFF3b1BvRlorRS8zeGpT?= =?utf-8?B?WmdsQ1AzN1R6TVdwTU9BSWhzSTQ5RVhIUWtYSVNXR0x2VWxzRkRMVlRZdjRl?= =?utf-8?B?N0xaWi9UUFZlMU8wNURSNWtFZW9ZZXlXZ2lHQlkzeXpmV3AxZHdNVThWQjhM?= =?utf-8?B?alFjV1NkQTYrYml5MGNBbDNjZlV1NzFmNHo5T085alIzY0VSbTYxdkJTVGJG?= =?utf-8?B?eXhBbUFXUy92dVdpMFUyWUhTakNjTHByMnRacEdlYjhzcmJVTGtDbGxRQVBM?= =?utf-8?B?M0pJc0hpQ3gyOGFrOEN1cW1iSlMvQVpwK1I4L2hoU0dqd0pJYjR3bzRUOW9E?= =?utf-8?B?YUZXNTJsa3p4aGoxZGVYWTRaYmRWYzAyVXM4d3luSTJRWlB1WkdsQkE5ZkVB?= =?utf-8?B?bXgvTWJPVUhzc3ByeFFsRFVRQVBLcXVpM1JjU1ZwdUVFVmVWc3RwT0VYTkQv?= =?utf-8?B?Y2RlWGQwRmNhNHlKTkxQNnpiUFl0dnBMRTBmQWtBMEFaZmluRU1RNldiU3My?= =?utf-8?B?TjJDTEkrVFd5ZFlJTFgyNG5EbVZYeFRheGNMMUtja3ZPUEUwNjhhMllxUkM2?= =?utf-8?B?aGZzYzJLUGk4Z3ZCNXBpMGNDZDlpdXJlUDhSYmxqRVFwOGhqVHFEZXFnZ0Ju?= =?utf-8?B?UURMdEtrZU52Wlc5Mld3NlNMb0JUSDc0eTI2NlV0LzlMNnB0L2Vzd3oxUmtK?= =?utf-8?B?N2xEVE81eWR3N3d2MnYwbE83aUMxcXhkR1MvOFBvN3RhYUFSaHR1U0c4aXRT?= =?utf-8?B?UXFoWGhGNGFrRjdNZTRud3pVMjRLQUxYeG5lNzU0LzhJL3BnUFUreUtwT2dS?= =?utf-8?B?cHVDcHhVSFBhQ0FFQnVicm9aMUVxTjZSaTg0eW1VZm5pc3UrZm9xQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b5c0449-f5c4-4c91-a416-08df099ec822 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 09:36:07.8700 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +hmH0EaUc0bXwczAvgASLBtqt8LnVbYw5a9qSz5j1603VC6CKcHpagv501CVMCQDrNoP/SlgwFNmZ1KJJcqJty1KjRIhcSHi8v8Mtye4KUY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7765 X-purgate-ID: tlsNG-16d1c6/1788428173-FD80D77B-2A026225/0/0 X-purgate-type: clean X-purgate-size: 565 On 03/09/2026 10:20 am, Bertrand Marquis wrote: > Hi Andrew, > > While reviewing those patches i found out that cover letter is saying that the serie has 5 patches but then the patches are number out of 6. > Is there a patch missing or something went wrong in the numbering and there is actually on 5 patches ? Oops, that was a mistake with git-format-patch, I expect. The 6th patch in this series was https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=5504b16eea5e661b67d4fba3cf9283d85b9dd3dc but I ended up submitting it separately. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:00:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:00:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406657.1639849 (Exim 4.92) (envelope-from ) id 1x24FE-00080P-Mh; Thu, 03 Sep 2026 10:00:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406657.1639849; Thu, 03 Sep 2026 10:00:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24FE-00080I-H4; Thu, 03 Sep 2026 10:00:32 +0000 Received: by outflank-mailman (input) for mailman id 1406657; Thu, 03 Sep 2026 10:00:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24FC-00080C-OP for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:00:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24FB-005kUh-Hg for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:00:29 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994535-e002-0a2a0a5209dd-0a2a45078efc-28 for ; Thu, 03 Sep 2026 12:00:29 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99453d-b4ea-0a2a45070019-d155dd29c1e7-3 for ; Thu, 03 Sep 2026 12:00:29 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-47fe89fb333so1393816f8f.3 for ; Thu, 03 Sep 2026 03:00:29 -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-49ce554d52esm77963235e9.3.2026.09.03.03.00.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 03:00:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788429629; x=1789034429; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=h2NziDJMKrul72aQFgBtOreRtl8idoWHlsvdnsWBq4A=; b=VRjaINMKUL+AkzkgLjiGBOhuYKHnef5aStNig+/R+J40kD7pS4g75moiHRjZz8U4QR iFBdUxpf54hIvOkJQlz8gDQgHoZczo06FE0XRJ494Y2bOrd/lLf+84kF3cT7hIjz9ArY 9l+y/Fefn43DrwKCXnzg83lDE/l39PbhbiZlTCOsTt4Xo8RXWxt69LZM8QkTU/Ecp8Ay duZV5si8BrcuKLqH6n8x43iwwfj5zd6UL3ZHiiDq+sKQmwEKeJ1TI2ezmalydo9WTvcE /rt1VSYQcH9buSzzg0e/duLnT85y/XGNsmBPGd6vNtnYD6VnQ0srnDDVbMfuve6+nV/o XXGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788429629; x=1789034429; h=content-transfer-encoding:content-type: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:content-type; bh=h2NziDJMKrul72aQFgBtOreRtl8idoWHlsvdnsWBq4A=; b=kJPYUzsiOV7yeg3oUEstYt8a+lFuo1xrSGFss5r85MFtn5x92U7NladXv3VXip1BcW QtwwLj6ZDO0N4m//1BcWasZNNPIblZzb72Olneu2ssyjpvIsPyrTJ6nVJj+XfDuEuYrB CEFd3N8/Ci+wqf9nOQrK4hARD7N8PK4d9MkHazaom7L4U7gq2nr7Q3VWvo+fQu8VRgMI M58NpuMNFTsLRz2/RnWNDkKOD2bLfWU+motyg1s7XgnCingv/zyIDyQ39Hv6vP+2OieR cSLoons+jTBQzPKpipJc4y2GgoXkd4Mgb4nUNzSQdo2+2oyWvmSbp4F/ZCXrAB1qgn62 0n7Q== X-Forwarded-Encrypted: i=1; AKwUvByuQ9V45jNJes72ybmpA/H/RWVAvDFRvYqJ6jsd6Hle2C1t/wRR7Tzarg3i6Jw3CkWlc7G+P7339hI=@lists.xenproject.org X-Gm-Message-State: AFuF++kJQv2HCqU0HAC1w+NjToZ4OqoN3LqWjYnHXMIr/k/jzBN6i0o0 smMXKcTI2zwHzkhnPcXMdpbk2sZme/Sic6zg5lyBErQYdEujZULHqHu5iNC+RmwMaQ== X-Gm-Gg: AYBFou3dtjocwyu6aeF2f1+JNEK8Ci6LJZ/I6A9L68swtm8IHCoPdkRB7HzGdjbyoUP 1cDCxf8iwiIGB6zuOmJSPWXymTYYlNPebTjlP1PepAeE19YafEfuK1hUshC3gqfByLYZeqeLppr 9fJOXFAV08g9CQ2uEyMoeXytnkPGgJfmmsiavFZPrTT6dXJOen0owd3pIS0iiZpdkO0WJ2Xi5H9 kQnGmnLs4fRDcNgRZMrv8ZJTRAwEU6ukMJ/MIXTXKhgGTZUHMGYOhgWUxQH4bybVWuyEf4AXeHs Mswi/cn6cfI28mlmJI1l7M8ijznzNLENCRh4gFaoh/PgIvD45py6p7qa3jfxFxYpbIV98mUOxKk 5y5R6cqngBfAIFtB0x7aTXmweX0ZMDL+axsnVgN3y5xk8KWwW0Q24SE3x1VkDZWO5L/SiBoZVkg ZHmZeWeebuUzgeI/hlMg22KbYArTEkjAYuYgdZ+SS0FPX2YBMIvRg3jgbUOLBEjMmZOdWP8+xS4 WxWF8H+NssxgzvnxVVAjc7/Q62PYco52UJizLhezJ6KGmZCmM5D X-Received: by 2002:a05:600c:45c4:b0:49c:e1df:79a4 with SMTP id 5b1f17b1804b1-49ce57fdd1emr197297165e9.5.1788429628101; Thu, 03 Sep 2026 03:00:28 -0700 (PDT) Message-ID: <0cf2c9f6-5fba-4d1e-a9cd-e2a409730efa@suse.com> Date: Thu, 3 Sep 2026 12:00:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 16/20] xen/riscv: implement IRQ routing for device passthrough To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-ef75cf/1788429629-A64DBAE4-0A20115B/0/0 X-purgate-type: clean X-purgate-size: 9249 On 27.08.2026 17:19, Oleksii Kurochko wrote: > dom0less device passthrough requires granting guest domains access to > device interrupts. Introduce map_device_irqs_to_domain() to enumerate > a DT node's interrupt properties, skipping those not owned by > the primary interrupt controller (as at the moment I haven't seen usages > of it), and map_irq_to_domain() to grant domain access and configure > Xen's interrupt descriptor accordingly. Sharing IRQ between domains is > rejected. > > Both map_irq_to_domain() and map_device_irqs_to_domain() are marked > __overlay_init, mirroring Arm: without CONFIG_OVERLAY_DTB this expands to > __init, so the functions are init-only and need no XSM check; with > CONFIG_OVERLAY_DTB they become runtime-callable, but the only runtime > entry point is dt_overlay_domctl(), which performs the XSM checks at the > domctl layer. RISC-V does not wire up DT overlay yet, so today these are > strictly __init; if/when overlay support is added, the domctl-level XSM > gating must be added together with it, as on Arm. > > route_irq_to_guest() and release_irq() manage irq_desc ownership for > guest-assigned interrupts. Each assignment carries a small irq_guest > structure as irqaction::dev_id, recording the owning domain and virtual > IRQ number which is 1:1 mapped to physical IRQ number. A per-domain > vIRQ allocation bitmap (used_irqs in struct vintc), managed by > vintc_reserve_virq(), prevents the same vIRQ being claimed twice. > > Host and guest interrupts may differ in some operations (EOI timing in > particular, possibly others): a host IRQ is completed once Xen's handler > runs, whereas a passthrough IRQ must defer the physical completion until > the guest issues its own EOI, otherwise a still-asserted level line would > immediately retrigger and storm. This affects only the .end callback; > the rest of hw_interrupt_type is shared, hence the separate host and > guest hw_interrupt_type instances. Irrespective of there not being any .end() hook yet, I think the two would better be split properly right away. aplic_guest_irq_type's .name could then also properly point to e.g. "aplic-guest". > --- a/xen/arch/riscv/irq.c > +++ b/xen/arch/riscv/irq.c > @@ -12,11 +12,26 @@ > #include > #include > #include > +#include > #include > +#include > > #include > #include > > +/* Describe an IRQ assigned to a guest */ > +struct irq_guest > +{ > + struct domain *d; > + unsigned int virq; > + /* > + * The action of a guest IRQ has the same lifetime as this structure, so > + * embed it here to have both covered by a single allocation. Consequently > + * it must not be freed by release_irq() (see free_on_release below). > + */ > + struct irqaction action; Why the mention of release_irq(), when release_guest_irq() doesn't use that function? (In fact release_irq() looks to be unused altogether.) > @@ -227,3 +250,235 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq) > spin_unlock(&desc->lock); > irq_exit(); > } > + > +static struct irq_guest *irq_get_guest_info(struct irq_desc *desc) > +{ > + ASSERT(spin_is_locked(&desc->lock)); > + ASSERT(test_bit(_IRQ_GUEST, &desc->status)); Nit: I don't quite see why this cannot be the simpler ASSERT(desc->status & IRQ_GUEST); > +static struct irqaction *irq_detach_action(struct irq_desc *desc, > + const void *dev_id) > +{ > + struct irqaction *action, **action_ptr = &desc->action; > + > + ASSERT(spin_is_locked(&desc->lock)); > + > +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION > + for ( ;; ) > + { > + action = *action_ptr; > + if ( !action || (action->dev_id == dev_id) ) > + break; > + > + action_ptr = &action->next; > + } > +#else > + action = *action_ptr; > +#endif > + > + if ( !action ) > + { > + printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n", > + desc->irq); > + return NULL; > + } > + > + /* Found it - remove it from the action list */ > +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION > + *action_ptr = action->next; > +#else > + *action_ptr = NULL; > +#endif > + > + /* If this was the last action, shut down the IRQ */ > + if ( !desc->action ) > + { > + desc->handler->shutdown(desc); > + __clear_bit(_IRQ_GUEST, &desc->status); Similarly desc->status &= ~IRQ_GUEST; here then. > +/* > + * Complete the release of an action detached by irq_detach_action(). > + * > + * To be called with desc->lock dropped: the lock cannot be held all the way > + * through, as waiting for a handler still running on another CPU to complete > + * requires do_IRQ() to be able to acquire the very same lock. > + * > + * Once this function has returned, the action (and hence any object embedding > + * it) is no longer referenced by anyone and may be freed by the caller. > + */ > +static void irq_release_action(const struct irq_desc *desc, > + struct irqaction *action) > +{ > + /* > + * Wait to make sure it's not being used on another CPU. > + * > + * The read barrier pairs with the spin_unlock() in do_IRQ(): once we > + * observe _IRQ_INPROGRESS cleared, we are guaranteed to also see the > + * writes do_IRQ() made to desc (e.g. desc->action) before releasing the > + * lock, so it is safe to free the action below. > + */ I fear I don't understand this: What writes to desc->action would do_IRQ() ever want to do? I could see if you gave desc->status as example here; really I don't think any other field (apart from perhaps statistics) would ever want modifying there. > + do { smp_rmb(); } while ( test_bit(_IRQ_INPROGRESS, &desc->status) ); Please split this across three lines, to conform to style. (Also same nit as above.) > + if ( action->free_on_release ) > + xvfree(action); How does this being done here fit with the last paragraph of the comment ahead of the function? > +int release_guest_irq(struct domain *d, unsigned int virq) > +{ > + struct irq_desc *desc = irq_to_desc(virq); > + struct irqaction *action; > + struct irq_guest *info; > + unsigned long flags; > + int ret = -EINVAL; > + > + spin_lock_irqsave(&desc->lock, flags); > + > + if ( !test_bit(_IRQ_GUEST, &desc->status) ) > + goto unlock_err; > + > + info = irq_get_guest_info(desc); > + if ( d != info->d ) This looks to be the only use of "d" - any reason the function parameter cannot be pointer-to-const? > + goto unlock_err; > + > + /* > + * Detaching the action happens with desc->lock still held, so that a > + * concurrent release_guest_irq() for the same IRQ sees _IRQ_GUEST already I think "sees" is misleading here, as it suggests that a racing check can occur. With the lock held, that's impossible. Hence imo better "will see" (i.e. only after having got hold of the lock). > +/* Route an IRQ to a specific guest */ > +int route_irq_to_guest(struct domain *d, unsigned int virq, > + unsigned int irq, const char *devname) > +{ > + struct irq_guest *info; > + struct irq_desc *desc = irq_to_desc(irq); > + unsigned long flags; > + int retval = 0; > + > + if ( d->is_dying ) > + return -EINVAL; > + > + info = xvzalloc(struct irq_guest); With zeroing used here, ... > + if ( !info ) > + return -ENOMEM; > + > + info->d = d; > + info->virq = virq; > + > + info->action.dev_id = info; > + info->action.name = devname; > + /* The action is part of 'info', thus it is freed together with it. */ > + info->action.free_on_release = false; ... this is dead code. > + spin_lock_irqsave(&desc->lock, flags); > + > + /* > + * If the IRQ is already used by someone > + * - If it's the same domain -> Xen doesn't need to update the IRQ desc. > + * For safety check if we are not trying to assign the IRQ to a > + * different vIRQ. > + * - Otherwise -> For now, don't allow the IRQ to be shared between > + * Xen and domains. > + */ > + if ( desc->action != NULL ) > + { > + if ( test_bit(_IRQ_GUEST, &desc->status) ) > + { > + struct domain *ad = irq_get_guest_info(desc)->d; > + > + if ( d != ad ) > + { > + printk(XENLOG_G_ERR "IRQ %u is already used by %pd\n", > + irq, ad); Perhaps best to also have %pd: at the start of this message, just like ... > + retval = -EBUSY; > + } > + else if ( irq_get_guest_info(desc)->virq != virq ) > + { > + printk(XENLOG_G_ERR > + "%pd: IRQ %u is already assigned to vIRQ %u\n", > + d, irq, irq_get_guest_info(desc)->virq); ... you have it here? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:27:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:27:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406691.1639858 (Exim 4.92) (envelope-from ) id 1x24f1-00037r-P5; Thu, 03 Sep 2026 10:27:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406691.1639858; Thu, 03 Sep 2026 10:27:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24f1-00037k-LA; Thu, 03 Sep 2026 10:27:11 +0000 Received: by outflank-mailman (input) for mailman id 1406691; Thu, 03 Sep 2026 10:27:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24ez-00037d-R8 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:27:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24ez-001xje-7v for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:27:09 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994b65-2eae-0a2a0a5409dd-0a2a4509988e-40 for ; Thu, 03 Sep 2026 12:27:08 +0200 Received: from [52.101.83.27] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a994b7b-be1a-0a2a45090019-3465531b798d-3 for ; Thu, 03 Sep 2026 12:27:08 +0200 Received: from AS4P190CA0043.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:5d1::14) by PA6PR08MB10624.eurprd08.prod.outlook.com (2603:10a6:102:3d2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 10:27:04 +0000 Received: from CPH1EPF0000051B.eurprd04.prod.outlook.com (2603:10a6:20b:5d1:cafe::66) by AS4P190CA0043.outlook.office365.com (2603:10a6:20b:5d1::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Thu, 3 Sep 2026 10:27:04 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by CPH1EPF0000051B.mail.protection.outlook.com (10.167.241.230) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Thu, 3 Sep 2026 10:27:03 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by GVXPR08MB11495.eurprd08.prod.outlook.com (2603:10a6:150:2e2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 10:26:30 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 10:26:29 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=kDq1RG7KDA7RYX9+81s2PEsWFIZCrMcwW27R59H5qYwhmmq8Q1Bdf6n/kJvd5GFd2/5tgUtIqL/zAAU7UCodwrdolUFPzLfhmdlfiZ4I8xYWzo6p4bRRokvwXezJuoNcD19BfZXbVw45aEuLQ89+KeP6cY1Kd49IyOuLPqkqRzYLSu1twVS2AJAroZVZDhfzpKuHLyOVX9yJNbcryXtCk7KYrhY+6Ewl9Akac18V99v+uZGkpwR8+qxn40HaUOZMmOCfIFYfvlm//MSzA+rWUX1mVUeI8o/CjzBQtJe+eSs2T54DWS3KSsB1g2ABjZKQuR5dtigpriPamZnnOwn7cQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BCcZVbHCGvMx16VOmquTT6JQ1l4wBT3+WxQqwWRIYa8=; b=umXa05lxjaznk1lH+wQG8Qn+KvHqewQ455cSocDP802pdkPVGsJulzEQyMK/jK7A6L1WeaN0GCUQcMGqaOM17JozCwUG30fnQY4TuYd2uv/slWmV+1nlSWdXIk9/h+aE1/LoF3uTBe9v0U96Kw4KD0Oy6uFAXnMyM5f0ZjEoFfQWtldgwGBvn/Ol3bKlT5625Fv3/uAXZNkR4TeZYNuvOwQsW1lD25Adnu/F8TaYIHeMb2R3Xl+f9NdfciA+w/1WSp9QRRCUCPXNRb11+T/cJ6rxworULl4s1JZm4Zn7VQ8rwwk3CNDaW/9mTiYZp1Qs1rkjeHHFgo/W7PGj6I2ozA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BCcZVbHCGvMx16VOmquTT6JQ1l4wBT3+WxQqwWRIYa8=; b=fPTT2pYt+XKHvsCLLZjZ3Sn6j4Lsa+yRmYPKM9AfZMyKy3HfMyu+8OwZoWa48ecOg9gi2MPG2DUUIXxsmL0oHyzjc24LrJhXFGq8/+P7axvTqbVlFVDHT47lTq6Ljf+n2CX7Pq9NWAKwA5cx6Tr62G3khQ154q50m6zZHJHqKYI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YYPhpGJ+A5g6Ob6susJuQDINQj+yD7ZU2ZIBdK3g2hlLISsRCx6kd1rLM3PBw2PpD2DPmFrL0f8GpDdWpxb9Nzn+LnjjKTTTe12E8v/dBcIAQF41/q6IgvsS/xWe6lRuOvvVHuQBFWFgyWFS21nERZoEi6dFfS2WeezpcaDz2/tus9kIGW1pEAeTrHDmIcLqScPW8rQGxb10zM/oMHuBfXe61Rv32n5+F8IXHwk7RgTzEJRVkNXbjXDp/k7z9leT1YjWe1X7+kgow4HrhNyCcHSlMejcisQDlLvkSBVoFnMNarOwfRsFZcyjWyTS9Jw8q28XmTLAKEErjThqvsk1Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BCcZVbHCGvMx16VOmquTT6JQ1l4wBT3+WxQqwWRIYa8=; b=u8QRXuzeVfVpMwsW4dOzYLCUqJGK9N4TUWHCgICfTJRu91X8HAs8oGuchvh+dCHN6D6GQPKHDWxusyfUBxB4lqGAsrHDszraLHf+p5xZIu8ERxVX+LDADph6KDHGuvZ9x0YehNYjIiyesv67ih2ob9O8Z6izz/DtdszRdlLfIC5Utq6TZx13z9LwUdgx7cni5ASD62my9d1Lu8gycj7zsy7HxbsW4u2b7Yvsund7p5GQad4ZEJURWSYZ+XqL16yqNcA1KEFFmeGb3jeo/6HbePvEw6YIe1CihK35MCcf30gXxmilMsZCPwWvyrMuiqwJUC5Iz+l1bin2zY8DQKlGYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BCcZVbHCGvMx16VOmquTT6JQ1l4wBT3+WxQqwWRIYa8=; b=fPTT2pYt+XKHvsCLLZjZ3Sn6j4Lsa+yRmYPKM9AfZMyKy3HfMyu+8OwZoWa48ecOg9gi2MPG2DUUIXxsmL0oHyzjc24LrJhXFGq8/+P7axvTqbVlFVDHT47lTq6Ljf+n2CX7Pq9NWAKwA5cx6Tr62G3khQ154q50m6zZHJHqKYI= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH 0/5] xen/arm: Fixes and improvements to SMCCC Thread-Topic: [PATCH 0/5] xen/arm: Fixes and improvements to SMCCC Thread-Index: AQHdOUMI/reoS+h4I0eq7LCk/pFqt7a8mEKAgAAEdoCAAA4RAA== Date: Thu, 3 Sep 2026 10:26:29 +0000 Message-ID: <1EC30A21-2C04-487E-982A-5A404E86AA3F@arm.com> References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> <646DE9C5-6708-47B9-A4EE-9111E101A038@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|GVXPR08MB11495:EE_|CPH1EPF0000051B:EE_|PA6PR08MB10624:EE_ X-MS-Office365-Filtering-Correlation-Id: 5b3b43d1-d63c-4ed9-f459-08df09a5e56e x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|10067099003|18002099003|22082099003|56012099006|11063799006|4143699003|38070700021; X-Microsoft-Antispam-Message-Info-Original: dMFY8KTvXV238q94svyuD6k95YC3h1Dz0hTlmc4SL4iMjJ4Qe002wxL7ZXGeYiCPvfx0YjojNULOZP8YZ/H16vw2YShJ3mWLeC4l2qj/XcZ1nbQniWtMjHscbD7/oNwtzvppZ1usxPbLsqDxNvFe3GZlVmzLBC//0Lwj/Jx/JX7Wkv60AE8w/7HTCtiwbTuNlhKEVb+CQxABN/jrs8Gzv1YpqldZ944q/qbrJRBJZEXGxYh6y5/al+JaUTxmu17Xg5DizYoUgvhl3cDPBd3+zqJAfh06YNWThGhS08dABvpnhbyUaGNkrABAh92h+UspceEqYqWlDJx4BJ7eRwZcEoEYPkHsBM/iETfgqXPITM8D32pe8tbi+U4tKkp9iIDaFf2VQzfs021FEBgflLkwauhlnGtNyx+RWMUO+igTnLoPsu0eT0jZ5HBd+p1Boy6lpDJu8KkcPaoVdEhYtFqA+2FfkdPO2mPsaFQQQ6XoDFOl+8XehAJbMSbI982jZPvvvmolLImLBiYA3ALxNHRZGJl9XAtOxx4bKvbopOE04g2Tv1PtBK2lIGEFZB5qBw5eSYRODy38+E6Q/NF5xGZq7BL8nNoLnBUGgrIo/zikgp2HiKe831g8sXETqapwynGfvbPD472o3t4aoS/hMAhn5t9K79oTPBz6h49SB77yOMM= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(10067099003)(18002099003)(22082099003)(56012099006)(11063799006)(4143699003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: kU2lQtMBO1kHzDaYwi0pqGvNjZczGHAumonhUFdR6EHNPrDwR38raOGlVQNRipJbvfDLaSEpAM5rNyt5oEnztkMEXwrKCAvt22tT69ec2/dKGIIsMQ2j7oh4HTa6u8p/gwDJNFHnyWR4F23TiyZolN9M24xOcUV+xrk52z4lgXHVnbpyUTqSQlpe8NS5SH5jDnG/hoBK1lFJ4/gmykSYm0fr6M+d5/X+fk4pe1b0EiGptJxPty1DKhuXt3dhKTBKdJmUFV/hf3CSXkbUJMREctAs4cJ+kwewostadCXk0RSca06I7RqO671LX1rfh7ZMiwrDshCqUn0PgTu23JSfcg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB11495 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: CPH1EPF0000051B.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ff6c9548-151f-40b2-6ee4-08df09a5d131 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|82310400026|35042699022|1800799024|14060799003|23010399003|10067099003|11063799006|56012099006|4143699003|13003099007|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: /N8jKi3fH2Ls7xPLPcDMlTGDnSd+XDyAD6CyYAufMgxl1s6Cy8RmZ3j7UymDkwkkcf38IznQg04MYshwCvJTJQ3MAd6m1pxp7LhfNVQTTkKYpDO0IjWRGLB1LFXnbheVNxyHa4NIzP/vXTYTVX/k+JB5e9U1rOaWZQ/UfpTlQpnRIWpuGyUzi0ebt3JRg4Rj8MMqr1z5wUbmYYTf1D6HxJiib6vutxAJSuwtx7293jslYdEEBUJWQIRqzHmvGZRPyE5Chv1kzGImF9DQu7tJAWPqtxGU/PUyVDACoLoIUxjyeKBZOgrGzSCfIbsQSgUdqHzgzMRwNg+Kefb3FNYeyBswV0LBFuiWz/+g+tHXAiD+qD56rpx4Eezsh0IRO2qfc8dUMhMeui/tBRbol4bf8z0Dfb0RqYPlnfFPfb5qt66HRE9JL3cseKqlHpVuoZb+9wouvMhwyYcCFCwCQZXf3tI96CjoJzPEso7x6+A3ftgEO5F7rD3SfAiNxtloLguMJBeeM522ZdmortBlZbtdn1cHpCH16xw8IxN17Oor8nL0QuOcfCsXVe6CCM+60lBaPFykJEhvRQVBOPhSuNdgbGgS/3CQWh63uIb1n8ZmSEIln30HRCzFDIhv+iHW6GJe X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(82310400026)(35042699022)(1800799024)(14060799003)(23010399003)(10067099003)(11063799006)(56012099006)(4143699003)(13003099007)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 9ACfyQgxWivHPN12tSAwN+ocG0iuDVScRRWwM2kLp/0rzgrAza3pbHAPhI8xyzWeXNAq+DXWljIDOrSf7YtGYfr0ETWy+5JLRs73TMmDlHq91B8Pnwl7VZs5bfMNvArl2stQHlb4XTYMKRHd2EGtwNi1rUrOWQzL6iAqRou+klchq5UsjmKj1M2WWCARCGSpsdr+DHCN3hrtunWURT9RCIkoU3zZwMelheQe+Q8cI412BNRdkKOr5T68lTxNrpc5lCiQB2a7i2EXSgMIrOODXfdhl7CjnekKrnEbKM4CsM281ML//xHq36t9hUcspyNjFc8OU3y3MjiBlwADPg8b48PeEwpjEgMbQWneqGCnwab6yMhGvCbO87xjN3zaftpXsdwhlQLycYyQFKfrJCtGqZydu5cc557PI9svgUdtMtj3E3F6liRX3nlojVcTFXqU X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 10:27:03.1994 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5b3b43d1-d63c-4ed9-f459-08df09a5e56e X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: CPH1EPF0000051B.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR08MB10624 X-purgate-ID: tlsNG-bad1c0/1788431228-BEEDE034-DB14505D/0/0 X-purgate-type: clean X-purgate-size: 753 > On 3 Sep 2026, at 11:35, Andrew Cooper wrote: >=20 > On 03/09/2026 10:20 am, Bertrand Marquis wrote: >> Hi Andrew, >>=20 >> While reviewing those patches i found out that cover letter is saying th= at the serie has 5 patches but then the patches are number out of 6. >> Is there a patch missing or something went wrong in the numbering and th= ere is actually on 5 patches ? >=20 > Oops, that was a mistake with git-format-patch, I expect. >=20 > The 6th patch in this series was > https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D5504b16eea= 5e661b67d4fba3cf9283d85b9dd3dc > but I ended up submitting it separately. Ok then 5 patches it is :-) Cheers Bertrand >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:28:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:28:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406696.1639866 (Exim 4.92) (envelope-from ) id 1x24gC-0003da-0o; Thu, 03 Sep 2026 10:28:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406696.1639866; Thu, 03 Sep 2026 10:28:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24gB-0003dT-UX; Thu, 03 Sep 2026 10:28:23 +0000 Received: by outflank-mailman (input) for mailman id 1406696; Thu, 03 Sep 2026 10:28:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x24gB-0003dN-9l for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:28:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24gA-0072G1-J8 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:28:22 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994bc2-8faa-0a2a0a5109dd-0a2a45098762-12 for ; Thu, 03 Sep 2026 12:28:22 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a994bc6-be1a-0a2a45090019-d1558033a93a-3 for ; Thu, 03 Sep 2026 12:28:22 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4954a9e8490so4833955e9.1 for ; Thu, 03 Sep 2026 03:28:22 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce47b9817sm104235925e9.1.2026.09.03.03.28.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 03:28:21 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788431302; x=1789036102; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=YznnKZXf6PyR49qfiMZ5c2JghO0VNvR3jH2UdEDmKuo=; b=DIEUZUGN1HkQEySStPyLvO6xVDzCzhyC2VuYdR/qjtvUenJSyDgPaL3whQeRs0HIMS vQVkWzkR2wfpfK88xy84Y6s0vJUdXOQjaM0zQKZsxOAxgUhsgQH5+IhSP6cqMTXBySEt HuRKiRbwGQ6jyZF2hIgecFekdtKxLIiqgnrTA8dn8wKjpLvgWscqm4YUqApccgXEQkzx 8BtlUx4xoQfCBA+bp+xHRgU5A+ja5JisC9Issc3WJlB0dVJupyjlJjoePo0Hn3rr3L7e eQ1ahed/XCMIts1KCDndKFRld90jh5FwXiyzB6x8z23vZkPYB666Mmg7+ueTs5r88iDN T1jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788431302; x=1789036102; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=YznnKZXf6PyR49qfiMZ5c2JghO0VNvR3jH2UdEDmKuo=; b=H/IrzYi7A8qi9zjs6n7N4MtlvjK5gsb5XngZbg6dTGbDspd3c+9JcxmbmDKZhC62rB geJv7CJpHDWo+jYuId0EzTDFUHg4lODKORjnOim0nCqV7EO2IwIxjqcs+6xNKlku6Jqx t+GqLSUeyk9FeNEl04tqazJoEpjOhLGAy9bC5EoX5cHnw1uU5a/4yhvkvhnPvYsmW1S/ 7HdGWrED7uZusWZhps7vDJPicSCo+OLFYvxsdYrrlw57XLKRVGMVYd/8Wr3OftLh+igl tfAUVIplHg/LeRAFgtxNfhH/sb+cIRQ3ixx+ANzJzT2sab3xP/6xBw4tRK65/1PTVZzc OR8g== X-Gm-Message-State: AFuF++nXm81HUSpZmQyl1+nkZMBppUGb2Ccja//M3EwyX3ughKuvVxZb guhT/Zt3ke/B06jGRJDjKUt1RQTP1UR3PDmZXzg0rSZycNQ4yagpge8/ X-Gm-Gg: AYBFou3k9jm1yaaMw60kAOZ81DQ9nI4d+AI8t6sD4E6tk8T3kd4pDbtGKjnyhBXMWV6 rflmdiaYV0XKcJ0oyOOtQFfTmfTk5rg6wkkXnbzkvO1uUh05V3JPdg8LO4kpdH10A3s9fkgbmuI 20YvVv6mgzRVNcdyt4CgSz5P6W+DD0dIqBhdhUo4dVPjDmE8z/5fPATu0+WLCAu0KJ+7ofHcTKn fs8p3GQohxgsbsoluMr1luZCVwP2AjDGlv4bpCsaSnQs3CPXsDG/X+J4dxoDsbx5pF1OVS9O73s QaJf2PXmTudGlWqG3ApKXplPl2HB46iBx3q7sUVYOHVQA4mb5MHalXbOlWlgBrBrDry7qeRs3AV d7q0WvvXEJo5hF3x+p1I2zlEaA0we5yoyXvdXEQxXFddfiM8Pj+nkYpjcJkNZ+H6sl2O5Uwqg+M Xg/lphFRh4H/+lyz7+5giHpnI+AR9+jYc1D0xLCPfVq3QoBGqgyRyr5McjmL1dPn8u8KtHBPXjr yxxty8kKF1mCi30+NU9wuoJAQ/MoFrJFu0IDUmyUQ== X-Received: by 2002:a05:600c:a085:b0:49c:f13e:e4e with SMTP id 5b1f17b1804b1-49cf15ab3c1mr28366845e9.11.1788431301802; Thu, 03 Sep 2026 03:28:21 -0700 (PDT) Message-ID: <0c06c3d4-067d-4cd5-91e5-0fa16f2894f6@gmail.com> Date: Thu, 3 Sep 2026 12:28:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v2 08/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1788276969.8631fc262581453bbf619ec5b2062170.1a05d9d0e85000c4f3@vates.tech> Content-Language: en-US In-Reply-To: <1788276969.8631fc262581453bbf619ec5b2062170.1a05d9d0e85000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788431302-FC610034-98B001B6/10/73395122804 X-purgate-type: spam X-purgate-size: 2683 On 9/1/26 5:36 PM, Baptiste Le Duc wrote: >> RISC-V guests can expose several virtual interrupt controllers at >> distinct GPA ranges: vPLIC (hasn't been introduced yet) for legacy machines, >> vAPLIC and vIMSIC for AIA-compliant ones (are being introduced in the follow >> up patches). > As Jan said here [1], we shouldn't use "as later in this series" in > commit message... I will reword this paragraph to: ``` A RISC-V guest can be given several emulated devices at distinct GPA ranges; the virtual interrupt controllers alone account for vPLIC on legacy machines and vAPLIC together with vIMSIC on AIA-compliant ones. Routing MMIO faults via a per-device is_access() check in the trap handler would couple that handler to every device it must serve, requiring a new conditional branch in the fault path for each emulated device added. ``` > > [1]: https://lore.kernel.org/xen-devel/cover.1787838835.git.oleksii.kurochko@gmail.com/T/#m56fbac1ceb0642d5d868e9dcb2b5ed93ecbe5058 >> Routing MMIO faults via a per-device is_access() check in the >> trap handler would couple it to every device it must serve, requiring a >> new conditional branch in the fault path each time a new emulated device is >> added. >> >> Introduce a per-domain MMIO handler registration table, modeled >> after the equivalent ARM framework, so that virtual devices >> self-register their GPA ranges and read/write callbacks at domain >> creation time. The MMIO fault path delegates to a single >> try_handle_mmio() entry point and remains agnostic of which device >> owns a particular address. >> >> A subsequent patch wires this into the MMIO fault path in traps.c. > ...same here I'll reword this to: ``` Nothing registers a handler and try_handle_mmio() has no callers yet, so this patch is a no-op; the trap handler is left untouched. ``` + I will add after Signed-off-by: ``` --- Wiring this into the MMIO fault path in traps.c is done in this patch series later. ``` [...] >> + >> +int register_mmio_handler(struct domain *d, >> + const struct mmio_handler_ops *ops, >> + paddr_t addr, paddr_t size) >> +{ >> + struct vmmio *vmmio = &d->arch.vmmio; >> + struct mmio_handler *handlers = vmmio->handlers; >> + paddr_t end = addr + size; >> + unsigned int i; >> + int rc = 0; >> + bool overlap; >> + >> + if ( !ops || !ops->read || !ops->write || !size || end < addr ) >> + return -EINVAL; > Just a question: is the aim of end < addr check to handle possible overflow of end? > Yes, your understanding is correct. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:30:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:30:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406705.1639875 (Exim 4.92) (envelope-from ) id 1x24iY-0005AA-EG; Thu, 03 Sep 2026 10:30:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406705.1639875; Thu, 03 Sep 2026 10:30:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24iY-0005A3-Ad; Thu, 03 Sep 2026 10:30:50 +0000 Received: by outflank-mailman (input) for mailman id 1406705; Thu, 03 Sep 2026 10:30:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24iX-00059x-8P for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:30:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24iW-00ENbS-LM for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:30:48 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c44-bab6-0a2a0a5309dd-0a2a45028a5c-48 for ; Thu, 03 Sep 2026 12:30:48 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-720697.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994c57-6ca4-0a2a45020019-d98c6eac9cfa-1 for ; Thu, 03 Sep 2026 12:30:47 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 22CFD1596; Thu, 3 Sep 2026 03:30:43 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B56423F673; Thu, 3 Sep 2026 03:30: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431446; bh=aIJuznfc9+x+T9t6CWjU8riug4jWFHnV2Y3X1zCinUQ=; h=From:To:Cc:Subject:Date:From; b=HcD41GFnI7IENNpaP3GqDjy6DF37NZr132PK5kJfK9CtOM3S1qk9y+fcKN3SUV7fv CcM7MKiGKbgjlj33bjiNiW6EInEK8eNPJw+PJmDcxUdsa3kYv2xrBMuqJaCxXVXbPK 8bCqsp/QujWMcuoR0Bd78MRtwtmH8W61WUnmuzNQ= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values Date: Thu, 3 Sep 2026 11:29:52 +0100 Message-ID: <20260903103002.1091859-1-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788431448-311CF2AC-7607B878/0/0 X-purgate-type: clean X-purgate-size: 12833 Hi, pte_t currently describes both a software PTE value and an element stored in a PTE table. Consequently, pte_t * can point either to a software PTE value, often a stack copy, or to a PTE-table slot. The compiler cannot distinguish these cases. A value pointer can therefore be passed to an interface that expects table storage, while table storage can be read by direct dereference instead of the architecture accessor. This series begins a staged conversion at the PTE level. It introduces hw_pte_t as the element type for PTE-table storage and converts generic MM to use hw_pte_t *. Software PTE values remain pte_t. Interfaces that intentionally return a value through pte_t *, such as install_pte, remain value interfaces; the relevant parameters are named ptentp to make that distinction explicit. The generic definition aliases hw_pte_t to pte_t unless an architecture selects ARCH_HAS_HW_PTE_T, which enables a distinct generic wrapper named __hw_pte_t. Some architectures define pgtable_t in headers parsed before the generic hw_pte_t typedef is visible. The structure tag allows those headers to define pgtable_t as struct __hw_pte_t * without creating an include-order dependency. This is required when converting s390, m68k, powerpc and sparc. No architecture selects ARCH_HAS_HW_PTE_T in this series, so the representation and behavior of every architecture are preserved. ptep_get() keeps its existing READ_ONCE() semantics and converts the stored element through __pte_from_hw(). An architecture can later select the option and convert its PTE interfaces to make the distinction compiler-enforced. Architecture PTE implementations and most architecture code are deliberately left for those later opt-in conversions. Here, hw_pte_t identifies PTE-table storage rather than table lifetime: complete PTE tables use hw_pte_t whether or not they are currently linked into a page-table hierarchy, while software PTE values use pte_t. The distinction between complete but unlinked tables and hardware-reachable tables was raised during discussion and remains an important point for review. PMD, PUD, P4D and PGD storage are deliberately out of scope. They can be converted in later series after the PTE boundary is agreed, avoiding the PMD-specific cases that made an all-level conversion difficult to review. Most mechanical pointer conversions were generated with the Coccinelle script included below, then audited and fixed by hand. This series does not add a second ptep_get_once() accessor and does not remove or replace STRICT_MM_TYPECHECKS. The design discussion is available at [1]; while the original idea came from [2]. I've the patches here [3] for arm64 conversion which I used to find usages in generic code which I missed during development. These would be sent separately. [1] https://lore.kernel.org/all/6110202c-057b-4701-8c04-1a76ee7bb9ab@arm.com/ [2] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com [3] https://gitlab.arm.com/linux-arm/linux-us/-/commits/pte0_arm Thanks, Usama --- Changes since v1: - Name the generic wrapper structure __hw_pte_t so architectures can forward-declare it before the generic typedef is visible. - Use software PTE value terminology consistently - Fold the prerequisite header includes into the generic storage conversion - Explain why the NOMMU stub converts the stored entry without ptep_get(). - Rebase onto mm-new and rerun the Coccinelle conversion. Changes since RFC v1: - Add ARCH_HAS_HW_PTE_T so architectures can opt in to a distinct PTE-table storage type. - Define the distinct hw_pte_t wrapper and its conversion helpers in generic code instead of requiring each architecture to define them. - Read hw_pte_t through READ_ONCE() before converting it to pte_t. - Drop the previous mremap patch in favour of [a]. Apply [a] first if it is not already present. - Drop the previous two dead-code conversion patches; the affected code was cleaned up separately in [b] and [c]. [a] https://lore.kernel.org/linux-mm/20260720141633.501799-1-agordeev@linux.ibm.com/ [b] https://lore.kernel.org/all/20260730111316.3672672-1-usama.anjum@arm.com [c] https://lore.kernel.org/all/20260730094501.3002718-1-usama.anjum@arm.com --- // SPDX-License-Identifier: GPL-2.0-only /// /// Rename raw PTE pointer types to hardware PTE pointer types. /// /// This is a mechanical type rename. It converts common declarations, /// function parameters, prototypes, return types and casts from "pte_t *" /// to "hw_pte_t *". Plain "pte_t" objects are intentionally left unchanged. /// Pointers named "ptentp" refer to temporary software PTE values and are /// intentionally ignored in all modes. /// Re-run in context mode afterwards to audit remaining raw pte_t pointers /// and cases that need hand conversion, such as trace macros and mixed /// declarations. /// /// Confidence: Moderate // Options: --no-includes --include-headers virtual patch virtual report virtual context @local_decl depends on patch@ identifier x != ptentp; @@ - pte_t *x; + hw_pte_t *x; @local_decl_init depends on patch@ identifier x != ptentp; expression e; @@ - pte_t *x = e; + hw_pte_t *x = e; @param_proto depends on patch@ identifier f; identifier x != ptentp; type R; @@ R f(..., - pte_t *x + hw_pte_t *x ,...); @param_proto_unnamed depends on patch@ identifier f; type R; @@ R f(..., - pte_t * + hw_pte_t * ,...); @param_def depends on patch@ identifier f; identifier x != ptentp; type R; @@ R f(..., - pte_t *x + hw_pte_t *x ,...) { ... } @ret_proto depends on patch@ identifier f; parameter list ps; @@ - pte_t * + hw_pte_t * f(ps); @ret_def depends on patch@ identifier f; parameter list ps; @@ - pte_t * + hw_pte_t * f(ps) { ... } @struct_member depends on patch@ identifier S; identifier x != ptentp; @@ struct S { ... - pte_t *x; + hw_pte_t *x; ... }; @union_member depends on patch@ identifier x != ptentp; @@ union { ... - pte_t *x; + hw_pte_t *x; ... }; @union_member_in_struct depends on patch@ identifier S; identifier x != ptentp; @@ struct S { ... union { ... - pte_t *x; + hw_pte_t *x; ... }; ... }; @fnptr_struct_member depends on patch@ identifier S,f; identifier x != ptentp; type R; @@ struct S { ... R (*f)(..., - pte_t *x + hw_pte_t *x ,...); ... }; @fnptr_typedef_pte_fn_t depends on patch@ identifier x != ptentp; @@ typedef int (*pte_fn_t)(..., - pte_t *x + hw_pte_t *x ,...); @cast depends on patch@ expression e; @@ - (pte_t *)e + (hw_pte_t *)e @remaining_decl depends on context || report@ identifier x != ptentp; position p; @@ * pte_t *x@p; @remaining_decl_init depends on context || report@ identifier x != ptentp; expression e; position p; @@ * pte_t *x@p = e; @remaining_param_proto depends on context || report@ identifier f; identifier x != ptentp; type R; position p; @@ R f(..., * pte_t *x@p ,...); @remaining_param_proto_unnamed depends on context || report@ identifier f; type R; position p; @@ R f(..., * pte_t *@p ,...); @remaining_param_def depends on context || report@ identifier f; identifier x != ptentp; type R; position p; @@ R f(..., * pte_t *x@p ,...) { ... } @remaining_ret_proto depends on context || report@ identifier f; parameter list ps; position p; @@ * pte_t *f@p(ps); @remaining_ret_def depends on context || report@ identifier f; parameter list ps; position p; @@ * pte_t *f@p(ps) { ... } @remaining_struct_member depends on context || report@ identifier S; identifier x != ptentp; position p; @@ struct S { ... * pte_t *x@p; ... }; @remaining_union_member depends on context || report@ identifier x != ptentp; position p; @@ union { ... * pte_t *x@p; ... }; @remaining_union_member_in_struct depends on context || report@ identifier S; identifier x != ptentp; position p; @@ struct S { ... union { ... * pte_t *x@p; ... }; ... }; @remaining_fnptr_struct_member depends on context || report@ identifier S,f; identifier x != ptentp; type R; position p; @@ struct S { ... R (*f)(..., * pte_t *x@p ,...); ... }; @remaining_fnptr_typedef_pte_fn_t depends on context || report@ identifier x != ptentp; position p; @@ typedef int (*pte_fn_t)(..., * pte_t *x@p ,...); Muhammad Usama Anjum (8): mm: introduce hw_pte_t for PTE table storage mm: rename pointers to software PTE values as ptentp mm: use hw_pte_t for generic PTE table storage mm: convert PTE table entries in ptep_get() mm: convert PTE table entry to pte mm/kasan: use hw_pte_t for the early shadow PTE table drm/i915: use hw_pte_t for PTE range callbacks xen: use hw_pte_t for PTE range callbacks MAINTAINERS | 1 + .../drm/i915/gem/selftests/i915_gem_mman.c | 4 +- drivers/gpu/drm/i915/i915_mm.c | 4 +- drivers/xen/gntdev.c | 2 +- drivers/xen/privcmd.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 2 +- drivers/xen/xlate_mmu.c | 4 +- fs/hugetlbfs/inode.c | 3 +- fs/proc/task_mmu.c | 33 ++++---- include/asm-generic/hugetlb.h | 15 ++-- include/asm-generic/pgalloc.h | 6 +- include/asm-generic/tlb.h | 5 +- include/linux/hugetlb.h | 53 ++++++------ include/linux/kasan.h | 2 +- include/linux/mm.h | 26 +++--- include/linux/page_table_check.h | 10 ++- include/linux/pagewalk.h | 10 +-- include/linux/pgtable.h | 81 ++++++++++--------- include/linux/pgtable_types.h | 19 +++++ include/linux/rmap.h | 2 +- include/linux/swapops.h | 6 +- include/linux/vmalloc.h | 4 +- include/trace/events/xen.h | 10 +-- kernel/bpf/arena.c | 9 ++- kernel/events/core.c | 3 +- mm/Kconfig | 3 + mm/damon/ops-common.c | 2 +- mm/damon/ops-common.h | 2 +- mm/damon/vaddr.c | 20 ++--- mm/debug_vm_pgtable.c | 2 +- mm/filemap.c | 4 +- mm/gup.c | 9 ++- mm/highmem.c | 15 ++-- mm/hmm.c | 6 +- mm/huge_memory.c | 4 +- mm/hugetlb.c | 60 +++++++------- mm/hugetlb_vmemmap.c | 13 +-- mm/internal.h | 16 ++-- mm/kasan/init.c | 14 ++-- mm/kasan/shadow.c | 6 +- mm/khugepaged.c | 50 +++++++----- mm/ksm.c | 11 +-- mm/madvise.c | 18 +++-- mm/mapping_dirty_helpers.c | 4 +- mm/memory-failure.c | 6 +- mm/memory.c | 78 +++++++++--------- mm/mempolicy.c | 4 +- mm/migrate.c | 4 +- mm/migrate_device.c | 4 +- mm/mincore.c | 4 +- mm/mlock.c | 4 +- mm/mprotect.c | 19 ++--- mm/mremap.c | 4 +- mm/page_table_check.c | 4 +- mm/pagewalk.c | 9 ++- mm/percpu.c | 2 +- mm/pgtable-generic.c | 20 ++--- mm/ptdump.c | 4 +- mm/rmap.c | 6 +- mm/sparse-vmemmap.c | 22 ++--- mm/swap_state.c | 3 +- mm/swapfile.c | 5 +- mm/userfaultfd.c | 32 ++++---- mm/util.c | 2 +- mm/vmalloc.c | 11 +-- mm/vmscan.c | 6 +- 66 files changed, 453 insertions(+), 375 deletions(-) create mode 100644 include/linux/pgtable_types.h -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:31:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:31:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406707.1639884 (Exim 4.92) (envelope-from ) id 1x24ii-0005Ql-Mu; Thu, 03 Sep 2026 10:31:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406707.1639884; Thu, 03 Sep 2026 10:31:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24ii-0005Qc-K8; Thu, 03 Sep 2026 10:31:00 +0000 Received: by outflank-mailman (input) for mailman id 1406707; Thu, 03 Sep 2026 10:30:59 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24ih-0005Q9-GE for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:30:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24ig-00EatS-NY for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:30:58 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c51-e002-0a2a0a5209dd-0a2a4504a890-44 for ; Thu, 03 Sep 2026 12:30:58 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994c60-b57f-0a2a45040019-d98c6eac887e-1 for ; Thu, 03 Sep 2026 12:30:57 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 993991F02; Thu, 3 Sep 2026 03:30:52 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 3AE423F673; Thu, 3 Sep 2026 03:30:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431456; bh=DEt3KlUchGpFfzI7cFYM3vauHOwXVIVRP1eSVCB1rgM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OCqN0IM73DlVeIFEnlcCIuqR18FAoouHSGHhXNucYr8rONtG/PWo24UoFAmagMzIb 8r48Ezf7p4wr9UIjQ4++anmaFeiCydvVPqtUevaAhHfgY9il6/+hvRvy7PKAcpAA/e wapcW/7pqB0l6aY7tSwko5ZNforUusnJFwU24SHs= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 1/8] mm: introduce hw_pte_t for PTE table storage Date: Thu, 3 Sep 2026 11:29:53 +0100 Message-ID: <20260903103002.1091859-2-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788431457-C06DAB50-18E923D2/0/0 X-purgate-type: clean X-purgate-size: 3024 pte_t is used both for software PTE values and for entries stored in a PTE table, so pte_t * does not distinguish a pointer to a software PTE value from a pointer to table storage. Introduce hw_pte_t as the generic name for a PTE table element. Define it as a macro alias of pte_t by default. When an architecture selects ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead. This preserves the representation while allowing converted architectures to enforce the distinction at compile time. Name the generic wrapper structure __hw_pte_t so architectures can forward-declare it when pgtable_t must be defined before the generic hw_pte_t typedef is visible. This avoids header-order dependencies. Keep the C type definitions behind an __ASSEMBLY__ check because architecture assembly sources can include this header indirectly. Include asm/page.h so consumers such as linux/vmalloc.h retain the page definitions they previously obtained from that header. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Name the generic wrapper structure __hw_pte_t so architectures can forward-declare it, and explain why this is required. - Use software PTE value terminology. Changes since RFC v1: - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition. - Exclude the C type definitions from assembly sources. - Update the description for the new opt-in model. --- MAINTAINERS | 1 + include/linux/pgtable_types.h | 17 +++++++++++++++++ mm/Kconfig | 3 +++ 3 files changed, 21 insertions(+) create mode 100644 include/linux/pgtable_types.h diff --git a/MAINTAINERS b/MAINTAINERS index 2133aec4a2004..da60a8bdcddb5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17140,6 +17140,7 @@ F: include/linux/mmu_notifier.h F: include/linux/pagewalk.h F: include/linux/pgalloc.h F: include/linux/pgtable.h +F: include/linux/pgtable_types.h F: include/linux/ptdump.h F: include/linux/vmpressure.h F: include/linux/vmstat.h diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h new file mode 100644 index 0000000000000..07da05d375c2c --- /dev/null +++ b/include/linux/pgtable_types.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_PGTABLE_TYPES_H +#define _LINUX_PGTABLE_TYPES_H + +#include + +#ifndef __ASSEMBLY__ + +#ifdef CONFIG_ARCH_HAS_HW_PTE_T +typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t; +#else +#define hw_pte_t pte_t +#endif + +#endif /* !__ASSEMBLY__ */ + +#endif /* _LINUX_PGTABLE_TYPES_H */ diff --git a/mm/Kconfig b/mm/Kconfig index c1ddf59c0d71a..5f462ec6fa5e5 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1312,6 +1312,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled" config GUP_GET_PXX_LOW_HIGH bool +config ARCH_HAS_HW_PTE_T + bool + config DMAPOOL_TEST tristate "Enable a module to run time tests on dma_pool" depends on HAS_DMA -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:31:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:31:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406708.1639893 (Exim 4.92) (envelope-from ) id 1x24iq-0005j4-UT; Thu, 03 Sep 2026 10:31:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406708.1639893; Thu, 03 Sep 2026 10:31:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24iq-0005iu-Qz; Thu, 03 Sep 2026 10:31:08 +0000 Received: by outflank-mailman (input) for mailman id 1406708; Thu, 03 Sep 2026 10:31:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24ip-0005hI-NC for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:31:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24ip-005pOg-38 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:31:07 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c60-8faa-0a2a0a5109dd-0a2a4508b8e8-40 for ; Thu, 03 Sep 2026 12:31:07 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994c6a-f659-0a2a45080019-d98c6eacd578-1 for ; Thu, 03 Sep 2026 12:31:06 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 22B9C1F37; Thu, 3 Sep 2026 03:31:02 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B04F83F673; Thu, 3 Sep 2026 03:30:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431465; bh=iZ0UxDW+PGfZPY4n2x5quNoQFlhhWYff8wQolJj8CQc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aEI5eI1ZDdVq2m64EA9ImU65GZFhZiL0ZK/lLsHlinaxtNpnT2nFBXA1JkEFJ2dA5 GAImWCHFC6p4QBtqqRBlk66RPeHRj2Ei0OGOPqGAPPTqssaugxDn76YWiAfBhwdKz2 oxnCSs2C9wVP4R71Kj0L4+hylcBhUUG7uFZhGTMI= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 2/8] mm: rename pointers to software PTE values as ptentp Date: Thu, 3 Sep 2026 11:29:54 +0100 Message-ID: <20260903103002.1091859-3-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788431467-D534D87B-374B347B/0/0 X-purgate-type: clean X-purgate-size: 2926 Some interfaces use pte_t * for a software PTE value rather than for an entry stored in a PTE table. These pointers must remain pte_t * when pointers to PTE table storage are converted to hw_pte_t *. Rename these parameters in the install_pte callback, write_protect_page(), and guard_install_set_pte() to ptentp. The later Coccinelle conversion skips pointers named ptentp, allowing it to convert the remaining PTE table pointers without changing these interfaces. Some functions already use ptentp for such pointers, including: - madvise_folio_pte_batch() - folio_pte_batch_flags() No need to rename them. This patch only renames parameters and makes no functional change. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Rewrite the subject and description to distinguish software PTE values from PTE table storage. Changes since RFC v1: - Update the description for the architecture opt-in conversion. --- include/linux/pagewalk.h | 2 +- mm/ksm.c | 4 ++-- mm/madvise.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h index b41d7265c01bc..c34d826c5e4a2 100644 --- a/include/linux/pagewalk.h +++ b/include/linux/pagewalk.h @@ -89,7 +89,7 @@ struct mm_walk_ops { struct mm_walk *walk); void (*post_vma)(struct mm_walk *walk); int (*install_pte)(unsigned long addr, unsigned long next, - pte_t *ptep, struct mm_walk *walk); + pte_t *ptentp, struct mm_walk *walk); enum page_walk_lock walk_lock; }; diff --git a/mm/ksm.c b/mm/ksm.c index 624f37975e129..2a4f19fe0f696 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -1292,7 +1292,7 @@ static u32 calc_checksum(struct page *page) } static int write_protect_page(struct vm_area_struct *vma, struct folio *folio, - pte_t *orig_pte) + pte_t *ptentp) { struct mm_struct *mm = vma->vm_mm; DEFINE_FOLIO_VMA_WALK(pvmw, folio, vma, 0, 0); @@ -1371,7 +1371,7 @@ static int write_protect_page(struct vm_area_struct *vma, struct folio *folio, set_pte_at(mm, pvmw.address, pvmw.pte, entry); } - *orig_pte = entry; + *ptentp = entry; err = 0; out_unlock: diff --git a/mm/madvise.c b/mm/madvise.c index 73c2901b9adbf..dd75a673e108f 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -1113,12 +1113,12 @@ static int guard_install_pte_entry(pte_t *pte, unsigned long addr, } static int guard_install_set_pte(unsigned long addr, unsigned long next, - pte_t *ptep, struct mm_walk *walk) + pte_t *ptentp, struct mm_walk *walk) { unsigned long *nr_pages = (unsigned long *)walk->private; /* Simply install a PTE marker, this causes segfault on access. */ - *ptep = make_pte_marker(PTE_MARKER_GUARD); + *ptentp = make_pte_marker(PTE_MARKER_GUARD); (*nr_pages)++; return 0; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:31:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:31:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406714.1639902 (Exim 4.92) (envelope-from ) id 1x24j2-00067S-5m; Thu, 03 Sep 2026 10:31:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406714.1639902; Thu, 03 Sep 2026 10:31:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24j2-00067G-2C; Thu, 03 Sep 2026 10:31:20 +0000 Received: by outflank-mailman (input) for mailman id 1406714; Thu, 03 Sep 2026 10:31:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24iz-00065r-TB for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:31:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24iz-00CYpL-9r for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:31:17 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c6c-2eae-0a2a0a5409dd-0a2a4509e9fe-26 for ; Thu, 03 Sep 2026 12:31:17 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994c74-be1a-0a2a45090019-d98c6eaca5bc-1 for ; Thu, 03 Sep 2026 12:31:16 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D8889165C; Thu, 3 Sep 2026 03:31:11 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 3D0453F673; Thu, 3 Sep 2026 03:31:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431475; bh=7qC7iNKkzxNEtpK9Q2MV+phaO3bZYc73/BPlpgmNzfw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OsIvfUJVbVPbzeY0tDHksboLntLCGlWGkOZGmoXBohgisNVcQ2BttfG4GkstEY4Z0 ze9kRz20kuOtz9fG19lg3wPIg5dOg/yiBdIi+TAMa1RYDv1QT57fwyqWsy/JEmQTWx EUHvgSwkum1uSKc0w6xB2YK7fYWegf0dylqSPcFQ= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 3/8] mm: use hw_pte_t for generic PTE table storage Date: Thu, 3 Sep 2026 11:29:55 +0100 Message-ID: <20260903103002.1091859-4-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1788431477-BE2C4394-7872198C/0/0 X-purgate-type: clean X-purgate-size: 124092 Generic page-table interfaces use pte_t * for both pointers to PTE table storage and pointers to software PTE values. Convert the generic declarations and their MM, fs, and kernel users together so parameters, return types, callbacks, and local pointers that designate table storage use hw_pte_t *. Include linux/pgtable_types.h from headers that expose the converted interfaces. It continues to provide pgprot_t to vmalloc.h through asm/page.h. Keep software PTE values as pte_t and retain pte_t * for value interfaces. No architecture selects ARCH_HAS_HW_PTE_T at this point, so hw_pte_t remains an alias of pte_t and this changes the interface vocabulary without changing representation or behavior. Most of this mechanical conversion was generated with the Coccinelle script included in the cover letter. The script deliberately ignores pte_t * pointers named ptentp because they designate software PTE values. The result was then audited, and sites the script could not convert were updated by hand. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Fold the header includes into their first user instead of keeping a stand-alone preparation patch. - Rebase onto mm-new and rerun the Coccinelle script. - Use software PTE value terminology. Changes since RFC v1: - Clarify that linux/pgtable_types.h provides both generic hw_pte_t definitions. - Clarify that the distinct generic definition is activated by an architecture opt-in. --- fs/hugetlbfs/inode.c | 3 +- fs/proc/task_mmu.c | 33 ++++++------- include/asm-generic/hugetlb.h | 15 +++--- include/asm-generic/pgalloc.h | 6 +-- include/asm-generic/tlb.h | 5 +- include/linux/hugetlb.h | 50 +++++++++++--------- include/linux/mm.h | 26 +++++------ include/linux/page_table_check.h | 10 ++-- include/linux/pagewalk.h | 8 ++-- include/linux/pgtable.h | 79 +++++++++++++++++--------------- include/linux/rmap.h | 2 +- include/linux/swapops.h | 6 ++- include/linux/vmalloc.h | 4 +- include/trace/events/xen.h | 10 ++-- kernel/bpf/arena.c | 9 ++-- kernel/events/core.c | 3 +- mm/damon/ops-common.c | 2 +- mm/damon/ops-common.h | 2 +- mm/damon/vaddr.c | 20 ++++---- mm/debug_vm_pgtable.c | 2 +- mm/filemap.c | 4 +- mm/gup.c | 9 ++-- mm/highmem.c | 15 +++--- mm/hmm.c | 6 +-- mm/huge_memory.c | 4 +- mm/hugetlb.c | 60 ++++++++++++------------ mm/hugetlb_vmemmap.c | 13 +++--- mm/internal.h | 16 +++---- mm/kasan/init.c | 12 ++--- mm/kasan/shadow.c | 6 +-- mm/khugepaged.c | 50 ++++++++++++-------- mm/ksm.c | 7 +-- mm/madvise.c | 14 +++--- mm/mapping_dirty_helpers.c | 4 +- mm/memory-failure.c | 6 +-- mm/memory.c | 78 ++++++++++++++++--------------- mm/mempolicy.c | 4 +- mm/migrate.c | 4 +- mm/migrate_device.c | 4 +- mm/mincore.c | 4 +- mm/mlock.c | 4 +- mm/mprotect.c | 19 ++++---- mm/mremap.c | 4 +- mm/page_table_check.c | 4 +- mm/pagewalk.c | 9 ++-- mm/percpu.c | 2 +- mm/pgtable-generic.c | 20 ++++---- mm/ptdump.c | 2 +- mm/rmap.c | 6 +-- mm/sparse-vmemmap.c | 22 ++++----- mm/swap_state.c | 3 +- mm/swapfile.c | 5 +- mm/userfaultfd.c | 32 +++++++------ mm/util.c | 2 +- mm/vmalloc.c | 11 +++-- mm/vmscan.c | 6 +-- 56 files changed, 410 insertions(+), 356 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 7611a8470ea26..ddaab714c3e02 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -328,7 +328,8 @@ static void hugetlb_delete_from_page_cache(struct folio *folio) static bool hugetlb_vma_maps_pfn(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn) { - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; ptep = hugetlb_walk(vma, addr, huge_page_size(hstate_vma(vma))); if (!ptep) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index e671b4fd8dedd..4211c33b06491 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -982,7 +982,7 @@ static void smaps_pte_hole_lookup(unsigned long addr, struct mm_walk *walk) #endif } -static void smaps_pte_entry(pte_t *pte, unsigned long addr, +static void smaps_pte_entry(hw_pte_t *pte, unsigned long addr, struct mm_walk *walk) { struct mem_size_stats *mss = walk->private; @@ -1076,7 +1076,7 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, struct mm_walk *walk) { struct vm_area_struct *vma = walk->vma; - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; ptl = pmd_trans_huge_lock(pmd, vma); @@ -1199,7 +1199,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) } #ifdef CONFIG_HUGETLB_PAGE -static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask, +static int smaps_hugetlb_range(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { @@ -1622,7 +1622,7 @@ static inline bool pte_is_pinned(struct vm_area_struct *vma, unsigned long addr, } static inline void clear_soft_dirty(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte) + unsigned long addr, hw_pte_t *pte) { if (!pgtable_supports_soft_dirty()) return; @@ -1690,7 +1690,8 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr, { struct clear_refs_private *cp = walk->private; struct vm_area_struct *vma = walk->vma; - pte_t *pte, ptent; + hw_pte_t *pte; + pte_t ptent; spinlock_t *ptl; struct folio *folio; @@ -2090,7 +2091,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long addr, unsigned long end, struct vm_area_struct *vma = walk->vma; struct pagemapread *pm = walk->private; spinlock_t *ptl; - pte_t *pte, *orig_pte; + hw_pte_t *pte, *orig_pte; int err = 0; #ifdef CONFIG_TRANSPARENT_HUGEPAGE @@ -2128,7 +2129,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long addr, unsigned long end, #ifdef CONFIG_HUGETLB_PAGE /* This function walks within one hugetlb entry in the single call */ -static int pagemap_hugetlb_range(pte_t *ptep, unsigned long hmask, +static int pagemap_hugetlb_range(hw_pte_t *ptep, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { @@ -2419,7 +2420,7 @@ static unsigned long pagemap_page_category(struct pagemap_scan_private *p, } static void make_uffd_wp_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte, pte_t ptent) + unsigned long addr, hw_pte_t *pte, pte_t ptent) { if (pte_present(ptent)) { pte_t old_pte; @@ -2552,7 +2553,7 @@ static unsigned long pagemap_hugetlb_category(struct vm_area_struct *vma, } static void make_uffd_wp_huge_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, + unsigned long addr, hw_pte_t *ptep, pte_t ptent) { const unsigned long psize = huge_page_size(hstate_vma(vma)); @@ -2786,7 +2787,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start, struct pagemap_scan_private *p = walk->private; struct vm_area_struct *vma = walk->vma; unsigned long addr, flush_end = 0; - pte_t *pte, *start_pte; + hw_pte_t *pte, *start_pte; spinlock_t *ptl; int ret; @@ -2880,7 +2881,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start, } #ifdef CONFIG_HUGETLB_PAGE -static int pagemap_scan_hugetlb_entry(pte_t *ptep, unsigned long hmask, +static int pagemap_scan_hugetlb_entry(hw_pte_t *ptep, unsigned long hmask, unsigned long start, unsigned long end, struct mm_walk *walk) { @@ -2961,7 +2962,7 @@ static int pagemap_scan_hugetlb_hole_wp(struct vm_area_struct *vma, unsigned long psize = huge_page_size(h); struct mm_struct *mm = vma->vm_mm; spinlock_t *ptl; - pte_t *ptep; + hw_pte_t *ptep; pte_t pte; for (addr = ALIGN_DOWN(addr, psize); addr < end; addr += psize) { @@ -3345,8 +3346,8 @@ static int gather_pte_stats(pmd_t *pmd, unsigned long addr, struct numa_maps *md = walk->private; struct vm_area_struct *vma = walk->vma; spinlock_t *ptl; - pte_t *orig_pte; - pte_t *pte; + hw_pte_t *orig_pte; + hw_pte_t *pte; #ifdef CONFIG_TRANSPARENT_HUGEPAGE ptl = pmd_trans_huge_lock(pmd, vma); @@ -3379,7 +3380,7 @@ static int gather_pte_stats(pmd_t *pmd, unsigned long addr, return 0; } #ifdef CONFIG_HUGETLB_PAGE -static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask, +static int gather_hugetlb_stats(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { pte_t huge_pte; @@ -3402,7 +3403,7 @@ static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask, } #else -static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask, +static int gather_hugetlb_stats(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { return 0; diff --git a/include/asm-generic/hugetlb.h b/include/asm-generic/hugetlb.h index 635c41cc34797..3bfad4a99b64d 100644 --- a/include/asm-generic/hugetlb.h +++ b/include/asm-generic/hugetlb.h @@ -60,7 +60,7 @@ static inline int huge_pte_uffd(pte_t pte) #ifndef __HAVE_ARCH_HUGE_PTE_CLEAR static inline void huge_pte_clear(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned long sz) + hw_pte_t *ptep, unsigned long sz) { pte_clear(mm, addr, ptep); } @@ -68,7 +68,7 @@ static inline void huge_pte_clear(struct mm_struct *mm, unsigned long addr, #ifndef __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned long sz) + hw_pte_t *ptep, pte_t pte, unsigned long sz) { set_pte_at(mm, addr, ptep, pte); } @@ -76,7 +76,7 @@ static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, #ifndef __HAVE_ARCH_HUGE_PTEP_GET_AND_CLEAR static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, unsigned long sz) + unsigned long addr, hw_pte_t *ptep, unsigned long sz) { return ptep_get_and_clear(mm, addr, ptep); } @@ -84,7 +84,7 @@ static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm, #ifndef __HAVE_ARCH_HUGE_PTEP_CLEAR_FLUSH static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { return ptep_clear_flush(vma, addr, ptep); } @@ -99,7 +99,7 @@ static inline int huge_pte_none(pte_t pte) #ifndef __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT static inline void huge_ptep_set_wrprotect(struct mm_struct *mm, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { ptep_set_wrprotect(mm, addr, ptep); } @@ -107,7 +107,7 @@ static inline void huge_ptep_set_wrprotect(struct mm_struct *mm, #ifndef __HAVE_ARCH_HUGE_PTEP_SET_ACCESS_FLAGS static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, + unsigned long addr, hw_pte_t *ptep, pte_t pte, int dirty) { return ptep_set_access_flags(vma, addr, ptep, pte, dirty); @@ -115,7 +115,8 @@ static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma, #endif #ifndef __HAVE_ARCH_HUGE_PTEP_GET -static inline pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep) +static inline pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, + hw_pte_t *ptep) { return ptep_get(ptep); } diff --git a/include/asm-generic/pgalloc.h b/include/asm-generic/pgalloc.h index 051aa1331051c..b35e5a2158ada 100644 --- a/include/asm-generic/pgalloc.h +++ b/include/asm-generic/pgalloc.h @@ -16,7 +16,7 @@ * * Return: pointer to the allocated memory or %NULL on error */ -static inline pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm) +static inline hw_pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm) { struct ptdesc *ptdesc = pagetable_alloc_noprof(GFP_PGTABLE_KERNEL, 0); @@ -40,7 +40,7 @@ static inline pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm) * * Return: pointer to the allocated memory or %NULL on error */ -static inline pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm) +static inline hw_pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm) { return __pte_alloc_one_kernel_noprof(mm); } @@ -52,7 +52,7 @@ static inline pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm) * @mm: the mm_struct of the current context * @pte: pointer to the memory containing the page table */ -static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte) +static inline void pte_free_kernel(struct mm_struct *mm, hw_pte_t *pte) { pagetable_dtor_free(virt_to_ptdesc(pte)); } diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h index bdcc2778ac64f..2c3517800a9a8 100644 --- a/include/asm-generic/tlb.h +++ b/include/asm-generic/tlb.h @@ -644,7 +644,8 @@ static inline void tlb_flush_p4d_range(struct mmu_gather *tlb, } #ifndef __tlb_remove_tlb_entry -static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep, unsigned long address) +static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, + hw_pte_t *ptep, unsigned long address) { } #endif @@ -670,7 +671,7 @@ static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep, u * consecutive ptes instead of only a single one. */ static inline void tlb_remove_tlb_entries(struct mmu_gather *tlb, - pte_t *ptep, unsigned int nr, unsigned long address) + hw_pte_t *ptep, unsigned int nr, unsigned long address) { tlb_flush_pte_range(tlb, address, PAGE_SIZE * nr); for (;;) { diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 900c95e346b2e..0d2101facaa50 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -141,7 +141,7 @@ unsigned long hugetlb_total_pages(void); vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long address, unsigned int flags); #ifdef CONFIG_USERFAULTFD -int hugetlb_mfill_atomic_pte(pte_t *dst_pte, +int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte, struct vm_area_struct *dst_vma, unsigned long dst_addr, unsigned long src_addr, @@ -161,7 +161,7 @@ void hugetlb_fix_reserve_counts(struct inode *inode); extern struct mutex *hugetlb_fault_mutex_table; u32 hugetlb_fault_mutex_hash(struct address_space *mapping, pgoff_t idx); -pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, pud_t *pud); bool hugetlbfs_pagecache_present(struct hstate *h, struct vm_area_struct *vma, @@ -185,22 +185,22 @@ void hugetlb_bootmem_set_nodes(void); * which may go down to the lowest PTE level in their huge_pte_offset() and * huge_pte_alloc(): to avoid reliance on pte_offset_map() without pte_unmap(). */ -static inline pte_t *pte_offset_huge(pmd_t *pmd, unsigned long address) +static inline hw_pte_t *pte_offset_huge(pmd_t *pmd, unsigned long address) { return pte_offset_kernel(pmd, address); } -static inline pte_t *pte_alloc_huge(struct mm_struct *mm, pmd_t *pmd, +static inline hw_pte_t *pte_alloc_huge(struct mm_struct *mm, pmd_t *pmd, unsigned long address) { return pte_alloc(mm, pmd) ? NULL : pte_offset_huge(pmd, address); } #endif -pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, unsigned long sz); /* * huge_pte_offset(): Walk the hugetlb pgtable until the last level PTE. - * Returns the pte_t* if found, or NULL if the address is not mapped. + * Returns the hw_pte_t* if found, or NULL if the address is not mapped. * * IMPORTANT: we should normally not directly call this function, instead * this is only a common interface to implement arch-specific @@ -235,11 +235,11 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, * a concurrent pmd unshare, but it makes sure the pgtable page is safe to * access. */ -pte_t *huge_pte_offset(struct mm_struct *mm, +hw_pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz); unsigned long hugetlb_mask_last_page(struct hstate *h); int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep); + unsigned long addr, hw_pte_t *ptep); void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma); void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, unsigned long *start, unsigned long *end); @@ -301,7 +301,8 @@ static inline struct address_space *hugetlb_folio_mapping_lock_write( } static inline int huge_pmd_unshare(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep) + struct vm_area_struct *vma, unsigned long addr, + hw_pte_t *ptep) { return 0; } @@ -393,7 +394,7 @@ static inline int is_hugepage_only_range(struct mm_struct *mm, } #ifdef CONFIG_USERFAULTFD -static inline int hugetlb_mfill_atomic_pte(pte_t *dst_pte, +static inline int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte, struct vm_area_struct *dst_vma, unsigned long dst_addr, unsigned long src_addr, @@ -405,7 +406,7 @@ static inline int hugetlb_mfill_atomic_pte(pte_t *dst_pte, } #endif /* CONFIG_USERFAULTFD */ -static inline pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, +static inline hw_pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz) { return NULL; @@ -984,7 +985,8 @@ static inline bool htlb_allow_alloc_fallback(enum migrate_reason reason) } static inline spinlock_t *huge_pte_lockptr(struct hstate *h, - struct mm_struct *mm, pte_t *pte) + struct mm_struct *mm, + hw_pte_t *pte) { const unsigned long size = huge_page_size(h); @@ -1048,7 +1050,8 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm) #ifndef huge_ptep_modify_prot_start #define huge_ptep_modify_prot_start huge_ptep_modify_prot_start static inline pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, + hw_pte_t *ptep) { unsigned long psize = huge_page_size(hstate_vma(vma)); @@ -1059,7 +1062,8 @@ static inline pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma, #ifndef huge_ptep_modify_prot_commit #define huge_ptep_modify_prot_commit huge_ptep_modify_prot_commit static inline void huge_ptep_modify_prot_commit(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, + unsigned long addr, + hw_pte_t *ptep, pte_t old_pte, pte_t pte) { unsigned long psize = huge_page_size(hstate_vma(vma)); @@ -1247,7 +1251,8 @@ static inline bool htlb_allow_alloc_fallback(enum migrate_reason reason) } static inline spinlock_t *huge_pte_lockptr(struct hstate *h, - struct mm_struct *mm, pte_t *pte) + struct mm_struct *mm, + hw_pte_t *pte) { return &mm->page_table_lock; } @@ -1264,11 +1269,11 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm) { } -pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep); +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, hw_pte_t *ptep); unsigned long huge_pte_dirty(pte_t pte); static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { #ifdef CONFIG_MMU return ptep_get(ptep); @@ -1278,7 +1283,8 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, } static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned long sz) + hw_pte_t *ptep, pte_t pte, + unsigned long sz) { } @@ -1306,7 +1312,7 @@ static inline void hugetlb_bootmem_struct_page_init(void) #endif /* CONFIG_HUGETLB_PAGE */ static inline spinlock_t *huge_pte_lock(struct hstate *h, - struct mm_struct *mm, pte_t *pte) + struct mm_struct *mm, hw_pte_t *pte) { spinlock_t *ptl; @@ -1324,12 +1330,12 @@ static inline __init void hugetlb_cma_reserve(void) #endif #ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING -static inline bool hugetlb_pmd_shared(pte_t *pte) +static inline bool hugetlb_pmd_shared(hw_pte_t *pte) { return ptdesc_pmd_is_shared(virt_to_ptdesc(pte)); } #else -static inline bool hugetlb_pmd_shared(pte_t *pte) +static inline bool hugetlb_pmd_shared(hw_pte_t *pte) { return false; } @@ -1356,7 +1362,7 @@ bool __vma_private_lock(struct vm_area_struct *vma); * Safe version of huge_pte_offset() to check the locks. See comments * above huge_pte_offset(). */ -static inline pte_t * +static inline hw_pte_t * hugetlb_walk(struct vm_area_struct *vma, unsigned long addr, unsigned long sz) { #if defined(CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING) && defined(CONFIG_LOCKDEP) diff --git a/include/linux/mm.h b/include/linux/mm.h index 1b28e6fc8d5dd..7d7344b9dbe19 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -779,7 +779,7 @@ struct vm_fault { * VM_FAULT_ERROR). */ /* These three entries are valid only while holding ptl lock */ - pte_t *pte; /* Pointer to pte entry matching + hw_pte_t *pte; /* Pointer to pte entry matching * the 'address'. NULL if the page * table hasn't been allocated. */ @@ -3246,7 +3246,7 @@ struct follow_pfnmap_args { * The caller shouldn't touch any of these. */ spinlock_t *lock; - pte_t *ptep; + hw_pte_t *ptep; /** * Outputs: * @@ -3583,7 +3583,7 @@ static inline pud_t pud_mkspecial(pud_t pud) } #endif /* CONFIG_ARCH_SUPPORTS_PUD_PFNMAP */ -extern pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr, +extern hw_pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr, spinlock_t **ptl); #ifdef __PAGETABLE_P4D_FOLDED @@ -3861,7 +3861,7 @@ static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pmd_t *pmd) return ptlock_ptr(page_ptdesc(pmd_page(*pmd))); } -static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte) +static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, hw_pte_t *pte) { BUILD_BUG_ON(IS_ENABLED(CONFIG_HIGHPTE)); BUILD_BUG_ON(MAX_PTRS_PER_PTE * sizeof(pte_t) > PAGE_SIZE); @@ -3892,7 +3892,7 @@ static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pmd_t *pmd) { return &mm->page_table_lock; } -static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte) +static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, hw_pte_t *pte) { return &mm->page_table_lock; } @@ -3933,19 +3933,19 @@ static inline bool pagetable_pte_ctor(struct mm_struct *mm, return true; } -pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp); +hw_pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp); -static inline pte_t *pte_offset_map(pmd_t *pmd, unsigned long addr) +static inline hw_pte_t *pte_offset_map(pmd_t *pmd, unsigned long addr) { return __pte_offset_map(pmd, addr, NULL); } -pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, spinlock_t **ptlp); -pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, spinlock_t **ptlp); -pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp, spinlock_t **ptlp); @@ -4895,7 +4895,7 @@ static inline bool gup_can_follow_protnone(const struct vm_area_struct *vma, return !vma_is_accessible(vma); } -typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr, void *data); +typedef int (*pte_fn_t)(hw_pte_t *pte, unsigned long addr, void *data); extern int apply_to_page_range(struct mm_struct *mm, unsigned long address, unsigned long size, pte_fn_t fn, void *data); extern int apply_to_existing_page_range(struct mm_struct *mm, @@ -5144,7 +5144,7 @@ void *vmemmap_alloc_block(unsigned long size, int node); struct vmem_altmap; void *vmemmap_alloc_block_buf(unsigned long size, int node, struct vmem_altmap *altmap); -void vmemmap_verify(pte_t *, int, unsigned long, unsigned long); +void vmemmap_verify(hw_pte_t *, int, unsigned long, unsigned long); void vmemmap_set_pmd(pmd_t *pmd, void *p, int node, unsigned long addr, unsigned long next); int vmemmap_check_pmd(pmd_t *pmd, int node, @@ -5509,7 +5509,7 @@ static inline bool snapshot_page_is_faithful(const struct page_snapshot *ps) void snapshot_page(struct page_snapshot *ps, const struct page *page); -void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte, +void map_anon_folio_pte_nopf(struct folio *folio, hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr, bool uffd_wp); diff --git a/include/linux/page_table_check.h b/include/linux/page_table_check.h index 12268a32e8be1..933c1028c2232 100644 --- a/include/linux/page_table_check.h +++ b/include/linux/page_table_check.h @@ -7,6 +7,8 @@ #ifndef __LINUX_PAGE_TABLE_CHECK_H #define __LINUX_PAGE_TABLE_CHECK_H +#include + #ifdef CONFIG_PAGE_TABLE_CHECK #include @@ -21,7 +23,7 @@ void __page_table_check_pmd_clear(struct mm_struct *mm, unsigned long addr, void __page_table_check_pud_clear(struct mm_struct *mm, unsigned long addr, pud_t pud); void __page_table_check_ptes_set(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned int nr); + hw_pte_t *ptep, pte_t pte, unsigned int nr); void __page_table_check_pmds_set(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp, pmd_t pmd, unsigned int nr); void __page_table_check_puds_set(struct mm_struct *mm, unsigned long addr, @@ -74,7 +76,8 @@ static inline void page_table_check_pud_clear(struct mm_struct *mm, } static inline void page_table_check_ptes_set(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, + unsigned long addr, + hw_pte_t *ptep, pte_t pte, unsigned int nr) { if (static_branch_likely(&page_table_check_disabled)) @@ -137,7 +140,8 @@ static inline void page_table_check_pud_clear(struct mm_struct *mm, } static inline void page_table_check_ptes_set(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, + unsigned long addr, + hw_pte_t *ptep, pte_t pte, unsigned int nr) { } diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h index c34d826c5e4a2..7ab2eb39e02c0 100644 --- a/include/linux/pagewalk.h +++ b/include/linux/pagewalk.h @@ -38,7 +38,7 @@ enum page_walk_lock { * not trigger for any populated ranges. * @hugetlb_entry: if set, called for each hugetlb entry. This hook * function is called with the vma lock held, in order to - * protect against a concurrent freeing of the pte_t* or + * protect against a concurrent freeing of the hw_pte_t* or * the ptl. In some cases, the hook function needs to drop * and retake the vma lock in order to avoid deadlocks * while calling other functions. In such cases the hook @@ -76,11 +76,11 @@ struct mm_walk_ops { unsigned long next, struct mm_walk *walk); int (*pmd_entry)(pmd_t *pmd, unsigned long addr, unsigned long next, struct mm_walk *walk); - int (*pte_entry)(pte_t *pte, unsigned long addr, + int (*pte_entry)(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk); int (*pte_hole)(unsigned long addr, unsigned long next, int depth, struct mm_walk *walk); - int (*hugetlb_entry)(pte_t *pte, unsigned long hmask, + int (*hugetlb_entry)(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long next, struct mm_walk *walk); int (*test_walk)(unsigned long addr, unsigned long next, @@ -173,7 +173,7 @@ struct folio_walk { struct page *page; enum folio_walk_level level; union { - pte_t *ptep; + hw_pte_t *ptep; pud_t *pudp; pmd_t *pmdp; }; diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index e3c8ab96941c5..19098e302b75a 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -4,6 +4,7 @@ #include #include +#include #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT) #define PUD_ORDER (PUD_SHIFT - PAGE_SHIFT) @@ -93,26 +94,26 @@ static inline void pud_init(void *addr) #endif #ifndef pte_offset_kernel -static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address) +static inline hw_pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address) { - return (pte_t *)pmd_page_vaddr(*pmd) + pte_index(address); + return (hw_pte_t *)pmd_page_vaddr(*pmd) + pte_index(address); } #define pte_offset_kernel pte_offset_kernel #endif #ifdef CONFIG_HIGHPTE #define __pte_map(pmd, address) \ - ((pte_t *)kmap_local_page(pmd_page(*(pmd))) + pte_index((address))) + ((hw_pte_t *)kmap_local_page(pmd_page(*(pmd))) + pte_index((address))) #define pte_unmap(pte) do { \ kunmap_local((pte)); \ rcu_read_unlock(); \ } while (0) #else -static inline pte_t *__pte_map(pmd_t *pmd, unsigned long address) +static inline hw_pte_t *__pte_map(pmd_t *pmd, unsigned long address) { return pte_offset_kernel(pmd, address); } -static inline void pte_unmap(pte_t *pte) +static inline void pte_unmap(hw_pte_t *pte) { rcu_read_unlock(); } @@ -172,7 +173,7 @@ static inline pmd_t *pmd_off_k(unsigned long va) return pmd_offset(pud_offset(p4d_offset(pgd_offset_k(va), va), va), va); } -static inline pte_t *virt_to_kpte(unsigned long vaddr) +static inline hw_pte_t *virt_to_kpte(unsigned long vaddr) { pmd_t *pmd = pmd_off_k(vaddr); @@ -407,7 +408,7 @@ static inline void lazy_mmu_mode_resume(void) {} * * May be overridden by the architecture, else pte_batch_hint is always 1. */ -static inline unsigned int pte_batch_hint(pte_t *ptep, pte_t pte) +static inline unsigned int pte_batch_hint(hw_pte_t *ptep, pte_t pte) { return 1; } @@ -442,7 +443,7 @@ static inline pte_t pte_advance_pfn(pte_t pte, unsigned long nr) * to the same folio. The PTEs are all in the same PMD. */ static inline void set_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned int nr) + hw_pte_t *ptep, pte_t pte, unsigned int nr) { page_table_check_ptes_set(mm, addr, ptep, pte, nr); @@ -459,7 +460,7 @@ static inline void set_ptes(struct mm_struct *mm, unsigned long addr, #ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS extern int ptep_set_access_flags(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep, + unsigned long address, hw_pte_t *ptep, pte_t entry, int dirty); #endif @@ -490,7 +491,7 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma, #endif #ifndef ptep_get -static inline pte_t ptep_get(pte_t *ptep) +static inline pte_t ptep_get(hw_pte_t *ptep) { return READ_ONCE(*ptep); } @@ -526,7 +527,7 @@ static inline pgd_t pgdp_get(pgd_t *pgdp) #ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG static inline bool ptep_test_and_clear_young(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { pte_t pte = ptep_get(ptep); bool young = true; @@ -565,7 +566,7 @@ static inline bool pmdp_test_and_clear_young(struct vm_area_struct *vma, #ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH bool ptep_clear_flush_young(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep); + unsigned long address, hw_pte_t *ptep); #endif #ifndef __HAVE_ARCH_PMDP_CLEAR_YOUNG_FLUSH @@ -644,7 +645,7 @@ static inline void arch_check_zapped_pud(struct vm_area_struct *vma, pud_t pud) #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long address, - pte_t *ptep) + hw_pte_t *ptep) { pte_t pte = ptep_get(ptep); pte_clear(mm, address, ptep); @@ -673,7 +674,7 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline void clear_young_dirty_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, + unsigned long addr, hw_pte_t *ptep, unsigned int nr, cydp_t flags) { pte_t pte; @@ -698,7 +699,7 @@ static inline void clear_young_dirty_ptes(struct vm_area_struct *vma, #endif static inline void ptep_clear(struct mm_struct *mm, unsigned long addr, - pte_t *ptep) + hw_pte_t *ptep) { pte_t pte = ptep_get(ptep); @@ -739,7 +740,7 @@ static inline void ptep_clear(struct mm_struct *mm, unsigned long addr, * present bit set *unless* it is 'l'. Because get_user_pages_fast() only * operates on present ptes we're safe. */ -static inline pte_t ptep_get_lockless(pte_t *ptep) +static inline pte_t ptep_get_lockless(hw_pte_t *ptep) { pte_t pte; @@ -777,7 +778,7 @@ static inline pmd_t pmdp_get_lockless(pmd_t *pmdp) * We require that the PTE can be read atomically. */ #ifndef ptep_get_lockless -static inline pte_t ptep_get_lockless(pte_t *ptep) +static inline pte_t ptep_get_lockless(hw_pte_t *ptep) { return ptep_get(ptep); } @@ -844,7 +845,8 @@ static inline pud_t pudp_huge_get_and_clear_full(struct vm_area_struct *vma, #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, - unsigned long address, pte_t *ptep, + unsigned long address, + hw_pte_t *ptep, int full) { return ptep_get_and_clear(mm, address, ptep); @@ -872,7 +874,7 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, unsigned int nr, int full) + unsigned long addr, hw_pte_t *ptep, unsigned int nr, int full) { pte_t pte, tmp_pte; @@ -908,7 +910,7 @@ static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline pte_t get_and_clear_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned int nr) + hw_pte_t *ptep, unsigned int nr) { return get_and_clear_full_ptes(mm, addr, ptep, nr, 0); } @@ -933,7 +935,7 @@ static inline pte_t get_and_clear_ptes(struct mm_struct *mm, unsigned long addr, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline void clear_full_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned int nr, int full) + hw_pte_t *ptep, unsigned int nr, int full) { for (;;) { ptep_get_and_clear_full(mm, addr, ptep, full); @@ -962,7 +964,7 @@ static inline void clear_full_ptes(struct mm_struct *mm, unsigned long addr, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline void clear_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned int nr) + hw_pte_t *ptep, unsigned int nr) { clear_full_ptes(mm, addr, ptep, nr, 0); } @@ -977,13 +979,14 @@ static inline void clear_ptes(struct mm_struct *mm, unsigned long addr, */ #ifndef update_mmu_tlb_range static inline void update_mmu_tlb_range(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep, unsigned int nr) + unsigned long address, hw_pte_t *ptep, + unsigned int nr) { } #endif static inline void update_mmu_tlb(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { update_mmu_tlb_range(vma, address, ptep, 1); } @@ -1000,7 +1003,7 @@ static inline void update_mmu_tlb(struct vm_area_struct *vma, * The PTEs are all in the same PMD. */ static inline void clear_nonpresent_ptes(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { (void)addr; @@ -1016,7 +1019,7 @@ static inline void clear_nonpresent_ptes(struct mm_struct *mm, #ifndef __HAVE_ARCH_PTEP_CLEAR_FLUSH extern pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address, - pte_t *ptep); + hw_pte_t *ptep); #endif #ifndef __HAVE_ARCH_PMDP_HUGE_CLEAR_FLUSH @@ -1044,7 +1047,8 @@ static inline pmd_t pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma) #ifndef __HAVE_ARCH_PTEP_SET_WRPROTECT struct mm_struct; -static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep) +static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, + hw_pte_t *ptep) { pte_t old_pte = ptep_get(ptep); set_pte_at(mm, address, ptep, pte_wrprotect(old_pte)); @@ -1070,7 +1074,7 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres * ptep_try_set as an identity macro. The generic stub returns false, which is * correct for callers that fall through to oops on failure. */ -static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte) +static inline bool ptep_try_set(hw_pte_t *ptep, pte_t new_pte) { return false; } @@ -1113,7 +1117,7 @@ static inline void flush_tlb_before_set(unsigned long addr) * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned int nr) + hw_pte_t *ptep, unsigned int nr) { for (;;) { ptep_set_wrprotect(mm, addr, ptep); @@ -1144,7 +1148,7 @@ static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline bool clear_flush_young_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { bool young = false; @@ -1181,7 +1185,7 @@ static inline bool clear_flush_young_ptes(struct vm_area_struct *vma, * Returns: whether any PTE was young. */ static inline bool test_and_clear_young_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { bool young = false; @@ -1585,7 +1589,7 @@ static inline int pmd_none_or_clear_bad(pmd_t *pmd) static inline pte_t __ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep) + hw_pte_t *ptep) { /* * Get the current pte state, but zero it out to make it @@ -1597,7 +1601,7 @@ static inline pte_t __ptep_modify_prot_start(struct vm_area_struct *vma, static inline void __ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pte_t pte) + hw_pte_t *ptep, pte_t pte) { /* * The pte is non-present, so there's no hardware state to @@ -1623,7 +1627,7 @@ static inline void __ptep_modify_prot_commit(struct vm_area_struct *vma, */ static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep) + hw_pte_t *ptep) { return __ptep_modify_prot_start(vma, addr, ptep); } @@ -1636,7 +1640,8 @@ static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma, */ static inline void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pte_t old_pte, pte_t pte) + hw_pte_t *ptep, pte_t old_pte, + pte_t pte) { __ptep_modify_prot_commit(vma, addr, ptep, pte); } @@ -1667,7 +1672,7 @@ static inline void ptep_modify_prot_commit(struct vm_area_struct *vma, */ #ifndef modify_prot_start_ptes static inline pte_t modify_prot_start_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { pte_t pte, tmp_pte; @@ -1707,7 +1712,7 @@ static inline pte_t modify_prot_start_ptes(struct vm_area_struct *vma, */ #ifndef modify_prot_commit_ptes static inline void modify_prot_commit_ptes(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pte_t old_pte, pte_t pte, unsigned int nr) + hw_pte_t *ptep, pte_t old_pte, pte_t pte, unsigned int nr) { int i; diff --git a/include/linux/rmap.h b/include/linux/rmap.h index 0b332770abeed..d28a7fb6f2c0e 100644 --- a/include/linux/rmap.h +++ b/include/linux/rmap.h @@ -868,7 +868,7 @@ struct page_vma_mapped_walk { struct vm_area_struct *vma; unsigned long address; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; unsigned int flags; bool pgoff_is_anon : 1; diff --git a/include/linux/swapops.h b/include/linux/swapops.h index e7d0d529f3e0f..40d2fd920558f 100644 --- a/include/linux/swapops.h +++ b/include/linux/swapops.h @@ -216,7 +216,8 @@ static inline swp_entry_t make_migration_entry_dirty(swp_entry_t entry) extern void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd, unsigned long address); -extern void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, pte_t *pte); +extern void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, + hw_pte_t *pte); #else /* CONFIG_MIGRATION */ static inline swp_entry_t make_readable_migration_entry(pgoff_t offset) { @@ -236,7 +237,8 @@ static inline swp_entry_t make_writable_migration_entry(pgoff_t offset) static inline void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd, unsigned long address) { } static inline void migration_entry_wait_huge(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte) { } + unsigned long addr, + hw_pte_t *pte) { } static inline swp_entry_t make_migration_entry_young(swp_entry_t entry) { diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index aed121d729b01..666ff2b3741da 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -8,7 +8,7 @@ #include #include #include -#include /* pgprot_t */ +#include /* pgprot_t, hw_pte_t */ #include #include @@ -120,7 +120,7 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr, uns #ifndef arch_vmap_pte_range_unmap_size static inline unsigned long arch_vmap_pte_range_unmap_size(unsigned long addr, - pte_t *ptep) + hw_pte_t *ptep) { return PAGE_SIZE; } diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h index ad384969e2cb2..1972d50b043a5 100644 --- a/include/trace/events/xen.h +++ b/include/trace/events/xen.h @@ -138,10 +138,10 @@ TRACE_EVENT(xen_mc_extend_args, TRACE_DEFINE_SIZEOF(pteval_t); TRACE_EVENT(xen_mmu_set_pte, - TP_PROTO(pte_t *ptep, pte_t pteval), + TP_PROTO(hw_pte_t *ptep, pte_t pteval), TP_ARGS(ptep, pteval), TP_STRUCT__entry( - __field(pte_t *, ptep) + __field(hw_pte_t *, ptep) __field(pteval_t, pteval) ), TP_fast_assign(__entry->ptep = ptep; @@ -207,12 +207,12 @@ TRACE_EVENT(xen_mmu_set_p4d, DECLARE_EVENT_CLASS(xen_mmu_ptep_modify_prot, TP_PROTO(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pteval), + hw_pte_t *ptep, pte_t pteval), TP_ARGS(mm, addr, ptep, pteval), TP_STRUCT__entry( __field(struct mm_struct *, mm) __field(unsigned long, addr) - __field(pte_t *, ptep) + __field(hw_pte_t *, ptep) __field(pteval_t, pteval) ), TP_fast_assign(__entry->mm = mm; @@ -227,7 +227,7 @@ DECLARE_EVENT_CLASS(xen_mmu_ptep_modify_prot, #define DEFINE_XEN_MMU_PTEP_MODIFY_PROT(name) \ DEFINE_EVENT(xen_mmu_ptep_modify_prot, name, \ TP_PROTO(struct mm_struct *mm, unsigned long addr, \ - pte_t *ptep, pte_t pteval), \ + hw_pte_t *ptep, pte_t pteval), \ TP_ARGS(mm, addr, ptep, pteval)) DEFINE_XEN_MMU_PTEP_MODIFY_PROT(xen_mmu_ptep_modify_prot_start); diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c index 7b6847200b431..62005229b2e94 100644 --- a/kernel/bpf/arena.c +++ b/kernel/bpf/arena.c @@ -155,7 +155,7 @@ struct clear_range_data { struct llist_head *free_pages; }; -static int apply_range_set_cb(pte_t *pte, unsigned long addr, void *data) +static int apply_range_set_cb(hw_pte_t *pte, unsigned long addr, void *data) { struct apply_range_data *d = data; struct page *page; @@ -207,7 +207,7 @@ static void flush_vmap_cache(unsigned long start, unsigned long size) flush_cache_vmap(start, start + size); } -static int apply_range_clear_cb(pte_t *pte, unsigned long addr, void *data) +static int apply_range_clear_cb(hw_pte_t *pte, unsigned long addr, void *data) { struct clear_range_data *d = data; pte_t old_pte; @@ -238,7 +238,8 @@ static int apply_range_clear_cb(pte_t *pte, unsigned long addr, void *data) return 0; } -static int apply_range_set_scratch_cb(pte_t *pte, unsigned long addr, void *data) +static int apply_range_set_scratch_cb(hw_pte_t *pte, unsigned long addr, + void *data) { struct page *scratch_page = data; @@ -340,7 +341,7 @@ static struct bpf_map *arena_map_alloc(union bpf_attr *attr) return ERR_PTR(err); } -static int existing_page_cb(pte_t *ptep, unsigned long addr, void *data) +static int existing_page_cb(hw_pte_t *ptep, unsigned long addr, void *data) { struct bpf_arena *arena = data; struct page *page; diff --git a/kernel/events/core.c b/kernel/events/core.c index a6c8e38a31104..0369f6c95ba7d 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -8517,7 +8517,8 @@ static u64 perf_get_pgtable_size(struct mm_struct *mm, unsigned long addr) p4d_t *p4dp, p4d; pud_t *pudp, pud; pmd_t *pmdp, pmd; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; pgdp = pgd_offset(mm, addr); pgd = pgdp_get(pgdp); diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c index 7a2e40bc7baed..f844a44752a81 100644 --- a/mm/damon/ops-common.c +++ b/mm/damon/ops-common.c @@ -39,7 +39,7 @@ struct folio *damon_get_folio(unsigned long pfn) return folio; } -void damon_ptep_mkold(pte_t *pte, struct vm_area_struct *vma, unsigned long addr) +void damon_ptep_mkold(hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr) { pte_t pteval = ptep_get(pte); struct folio *folio; diff --git a/mm/damon/ops-common.h b/mm/damon/ops-common.h index 38d295488fa18..34b7e5715fcf9 100644 --- a/mm/damon/ops-common.h +++ b/mm/damon/ops-common.h @@ -7,7 +7,7 @@ struct folio *damon_get_folio(unsigned long pfn); -void damon_ptep_mkold(pte_t *pte, struct vm_area_struct *vma, unsigned long addr); +void damon_ptep_mkold(hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr); void damon_pmdp_mkold(pmd_t *pmd, struct vm_area_struct *vma, unsigned long addr); void damon_folio_mkold(struct folio *folio); bool damon_folio_young(struct folio *folio); diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c index 0648400b2d65b..e32b914720d5c 100644 --- a/mm/damon/vaddr.c +++ b/mm/damon/vaddr.c @@ -268,7 +268,7 @@ static void damon_va_walk_page_range(struct mm_struct *mm, unsigned long start, static int damon_mkold_pmd_entry(pmd_t *pmd, unsigned long addr, unsigned long next, struct mm_walk *walk) { - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; ptl = pmd_trans_huge_lock(pmd, walk->vma); @@ -293,7 +293,7 @@ static int damon_mkold_pmd_entry(pmd_t *pmd, unsigned long addr, } #ifdef CONFIG_HUGETLB_PAGE -static void damon_hugetlb_mkold(pte_t *pte, struct mm_struct *mm, +static void damon_hugetlb_mkold(hw_pte_t *pte, struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr) { bool referenced = false; @@ -320,7 +320,7 @@ static void damon_hugetlb_mkold(pte_t *pte, struct mm_struct *mm, folio_put(folio); } -static int damon_mkold_hugetlb_entry(pte_t *pte, unsigned long hmask, +static int damon_mkold_hugetlb_entry(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { @@ -389,7 +389,7 @@ struct damon_young_walk_private { static int damon_young_pmd_entry(pmd_t *pmd, unsigned long addr, unsigned long next, struct mm_walk *walk) { - pte_t *pte; + hw_pte_t *pte; pte_t ptent; spinlock_t *ptl; struct folio *folio; @@ -433,7 +433,7 @@ static int damon_young_pmd_entry(pmd_t *pmd, unsigned long addr, } #ifdef CONFIG_HUGETLB_PAGE -static int damon_young_hugetlb_entry(pte_t *pte, unsigned long hmask, +static int damon_young_hugetlb_entry(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { @@ -522,7 +522,7 @@ static unsigned int damon_va_check_accesses(struct damon_ctx *ctx) static bool damos_va_filter_young_match(struct damos_filter *filter, struct folio *folio, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pmd_t *pmdp) + unsigned long addr, hw_pte_t *ptep, pmd_t *pmdp) { bool young = false; @@ -544,7 +544,7 @@ static bool damos_va_filter_young_match(struct damos_filter *filter, static bool damos_va_filter_out(struct damos *scheme, struct folio *folio, struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pmd_t *pmdp) + hw_pte_t *ptep, pmd_t *pmdp) { struct damos_filter *filter; bool matched; @@ -641,7 +641,8 @@ static int damos_va_migrate_pmd_entry(pmd_t *pmd, unsigned long addr, struct damos_migrate_dests *dests = &s->migrate_dests; struct folio *folio; spinlock_t *ptl; - pte_t *start_pte, *pte, ptent; + hw_pte_t *start_pte, *pte; + pte_t ptent; int nr; #ifdef CONFIG_TRANSPARENT_HUGEPAGE @@ -801,7 +802,8 @@ static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned long addr, struct vm_area_struct *vma = walk->vma; struct folio *folio; spinlock_t *ptl; - pte_t *start_pte, *pte, ptent; + hw_pte_t *start_pte, *pte; + pte_t ptent; int nr; #ifdef CONFIG_TRANSPARENT_HUGEPAGE diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c index 2875fd22d7bb0..54e194d2a5854 100644 --- a/mm/debug_vm_pgtable.c +++ b/mm/debug_vm_pgtable.c @@ -50,7 +50,7 @@ struct pgtable_debug_args { p4d_t *p4dp; pud_t *pudp; pmd_t *pmdp; - pte_t *ptep; + hw_pte_t *ptep; p4d_t *start_p4dp; pud_t *start_pudp; diff --git a/mm/filemap.c b/mm/filemap.c index 00fd89cf6f550..98f89dcc55603 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3490,7 +3490,7 @@ static vm_fault_t filemap_fault_recheck_pte_none(struct vm_fault *vmf) { struct vm_area_struct *vma = vmf->vma; vm_fault_t ret = 0; - pte_t *ptep; + hw_pte_t *ptep; /* * We might have COW'ed a pagecache folio and might now have an mlocked @@ -3796,7 +3796,7 @@ static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf, vm_fault_t ret = 0; struct page *page = folio_page(folio, start); unsigned int count = 0; - pte_t *old_ptep = vmf->pte; + hw_pte_t *old_ptep = vmf->pte; unsigned long addr0; /* diff --git a/mm/gup.c b/mm/gup.c index d1ba59da94e9a..549f462a23b2f 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -761,7 +761,7 @@ static struct page *follow_huge_pmd(struct vm_area_struct *vma, #endif /* CONFIG_PGTABLE_HAS_HUGE_LEAVES */ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address, - pte_t *pte, unsigned int flags) + hw_pte_t *pte, unsigned int flags) { if (flags & FOLL_TOUCH) { pte_t orig_entry = ptep_get(pte); @@ -806,7 +806,8 @@ static struct page *follow_page_pte(struct vm_area_struct *vma, struct folio *folio; struct page *page; spinlock_t *ptl; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; int ret; ptep = pte_offset_map_lock(mm, pmd, address, &ptl); @@ -1035,7 +1036,7 @@ static int get_gate_page(struct mm_struct *mm, unsigned long address, p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; pte_t entry; int ret = -EFAULT; @@ -2838,7 +2839,7 @@ static unsigned long gup_fast_pte_range(pmd_t pmd, pmd_t *pmdp, unsigned int flags, struct page **pages) { unsigned long nr_pages = 0; - pte_t *ptep, *ptem; + hw_pte_t *ptep, *ptem; ptem = ptep = pte_offset_map(&pmd, addr); if (!ptep) diff --git a/mm/highmem.c b/mm/highmem.c index a33e411839517..87f94cac6106b 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -141,7 +141,7 @@ EXPORT_SYMBOL(__totalhigh_pages); static int pkmap_count[LAST_PKMAP]; static __cacheline_aligned_in_smp DEFINE_SPINLOCK(kmap_lock); -pte_t *pkmap_page_table; +hw_pte_t *pkmap_page_table; /* * Most architectures have no use for kmap_high_get(), so let's abstract @@ -532,9 +532,9 @@ static inline bool kmap_high_unmap_local(unsigned long vaddr) return false; } -static pte_t *__kmap_pte; +static hw_pte_t *__kmap_pte; -static pte_t *kmap_get_pte(unsigned long vaddr, int idx) +static hw_pte_t *kmap_get_pte(unsigned long vaddr, int idx) { if (IS_ENABLED(CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY)) /* @@ -549,8 +549,9 @@ static pte_t *kmap_get_pte(unsigned long vaddr, int idx) void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) { - pte_t pteval, *kmap_pte; unsigned long vaddr; + hw_pte_t *kmap_pte; + pte_t pteval; int idx; /* @@ -597,7 +598,7 @@ EXPORT_SYMBOL(__kmap_local_page_prot); void kunmap_local_indexed(const void *vaddr) { unsigned long addr = (unsigned long) vaddr & PAGE_MASK; - pte_t *kmap_pte; + hw_pte_t *kmap_pte; int idx; if (addr < __fix_to_virt(FIX_KMAP_END) || @@ -646,7 +647,7 @@ EXPORT_SYMBOL(kunmap_local_indexed); void __kmap_local_sched_out(void) { struct task_struct *tsk = current; - pte_t *kmap_pte; + hw_pte_t *kmap_pte; int i; /* Clear kmaps */ @@ -683,7 +684,7 @@ void __kmap_local_sched_out(void) void __kmap_local_sched_in(void) { struct task_struct *tsk = current; - pte_t *kmap_pte; + hw_pte_t *kmap_pte; int i; /* Restore kmaps */ diff --git a/mm/hmm.c b/mm/hmm.c index 2f1e98c6b6440..0c959611eda01 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -240,7 +240,7 @@ static inline unsigned long pte_to_hmm_pfn_flags(struct hmm_range *range, } static int hmm_vma_handle_pte(struct mm_walk *walk, unsigned long addr, - unsigned long end, pmd_t *pmdp, pte_t *ptep, + unsigned long end, pmd_t *pmdp, hw_pte_t *ptep, unsigned long *hmm_pfn) { struct hmm_vma_walk *hmm_vma_walk = walk->private; @@ -411,7 +411,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp, &range->hmm_pfns[(start - range->start) >> PAGE_SHIFT]; unsigned long npages = (end - start) >> PAGE_SHIFT; unsigned long addr = start; - pte_t *ptep; + hw_pte_t *ptep; pmd_t pmd; again: @@ -547,7 +547,7 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long start, unsigned long end, #endif #ifdef CONFIG_HUGETLB_PAGE -static int hmm_vma_walk_hugetlb_entry(pte_t *pte, unsigned long hmask, +static int hmm_vma_walk_hugetlb_entry(hw_pte_t *pte, unsigned long hmask, unsigned long start, unsigned long end, struct mm_walk *walk) { diff --git a/mm/huge_memory.c b/mm/huge_memory.c index c5d11147b69ae..8466a52381991 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3146,7 +3146,7 @@ static void __split_huge_zero_page_pmd(struct vm_area_struct *vma, pgtable_t pgtable; pmd_t _pmd, old_pmd; unsigned long addr; - pte_t *pte; + hw_pte_t *pte; int i; /* @@ -3196,7 +3196,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, bool soft_dirty, uffd_wp = false, young = false, write = false; bool anon_exclusive = false, dirty = false; unsigned long addr; - pte_t *pte; + hw_pte_t *pte; int i; VM_BUG_ON(haddr & ~HPAGE_PMD_MASK); diff --git a/mm/hugetlb.c b/mm/hugetlb.c index bfc0184ed95c7..c30e7584f1a5c 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -129,7 +129,7 @@ static void hugetlb_vma_lock_free(struct vm_area_struct *vma); static void hugetlb_vma_lock_alloc(struct vm_area_struct *vma); static void __hugetlb_vma_unlock_write_free(struct vm_area_struct *vma); static int __huge_pmd_unshare(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, + struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep, bool check_locks); static void hugetlb_unshare_pmds(struct vm_area_struct *vma, unsigned long start, unsigned long end, bool take_locks); @@ -4878,7 +4878,7 @@ static pte_t make_huge_pte(struct vm_area_struct *vma, struct folio *folio, } static void set_huge_ptep_writable(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { pte_t entry; @@ -4888,14 +4888,14 @@ static void set_huge_ptep_writable(struct vm_area_struct *vma, } static void set_huge_ptep_maybe_writable(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { if (vma->vm_flags & VM_WRITE) set_huge_ptep_writable(vma, address, ptep); } static void -hugetlb_install_folio(struct vm_area_struct *vma, pte_t *ptep, unsigned long addr, +hugetlb_install_folio(struct vm_area_struct *vma, hw_pte_t *ptep, unsigned long addr, struct folio *new_folio, pte_t old, unsigned long sz) { pte_t newpte = make_huge_pte(vma, new_folio, true); @@ -4921,7 +4921,8 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma) { - pte_t *src_pte, *dst_pte, entry; + hw_pte_t *src_pte, *dst_pte; + pte_t entry; struct folio *pte_folio; unsigned long addr; bool cow = vma_is_cow_mapping(src_vma); @@ -5113,7 +5114,8 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, } static void move_huge_pte(struct vm_area_struct *vma, unsigned long old_addr, - unsigned long new_addr, pte_t *src_pte, pte_t *dst_pte, + unsigned long new_addr, hw_pte_t *src_pte, + hw_pte_t *dst_pte, unsigned long sz) { bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma); @@ -5175,7 +5177,7 @@ int move_hugetlb_page_tables(struct vm_area_struct *vma, struct mm_struct *mm = vma->vm_mm; unsigned long old_end = old_addr + len; unsigned long last_addr_mask; - pte_t *src_pte, *dst_pte; + hw_pte_t *src_pte, *dst_pte; struct mmu_notifier_range range; struct mmu_gather tlb; @@ -5236,7 +5238,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma, struct mm_struct *mm = vma->vm_mm; const bool folio_provided = !!folio; unsigned long address; - pte_t *ptep; + hw_pte_t *ptep; pte_t pte; spinlock_t *ptl; struct hstate *h = hstate_vma(vma); @@ -5770,7 +5772,7 @@ static inline vm_fault_t hugetlb_handle_userfault(struct vm_fault *vmf, * false if pte changed or is changing. */ static bool hugetlb_pte_stable(struct hstate *h, struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t old_pte) + hw_pte_t *ptep, pte_t old_pte) { spinlock_t *ptl; bool same; @@ -6295,7 +6297,7 @@ static struct folio *alloc_hugetlb_folio_vma(struct hstate *h, * Used by userfaultfd UFFDIO_* ioctls. Based on userfaultfd's mfill_atomic_pte * with modifications for hugetlb pages. */ -int hugetlb_mfill_atomic_pte(pte_t *dst_pte, +int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte, struct vm_area_struct *dst_vma, unsigned long dst_addr, unsigned long src_addr, @@ -6354,7 +6356,7 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte, folio = alloc_hugetlb_folio(dst_vma, dst_addr, false); if (IS_ERR(folio)) { - pte_t *actual_pte = hugetlb_walk(dst_vma, dst_addr, PMD_SIZE); + hw_pte_t *actual_pte = hugetlb_walk(dst_vma, dst_addr, PMD_SIZE); if (actual_pte) { ret = -EEXIST; goto out; @@ -6522,7 +6524,7 @@ long hugetlb_change_protection(struct vm_area_struct *vma, { struct mm_struct *mm = vma->vm_mm; unsigned long start = address; - pte_t *ptep; + hw_pte_t *ptep; pte_t pte; struct hstate *h = hstate_vma(vma); long pages = 0, psize = huge_page_size(h); @@ -7007,15 +7009,15 @@ void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, * racing tasks could either miss the sharing (see huge_pte_offset) or select a * bad pmd for sharing. */ -pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, pud_t *pud) { struct address_space *mapping = vma->vm_file->f_mapping; const pgoff_t idx = linear_page_index(vma, addr); struct vm_area_struct *svma; unsigned long saddr; - pte_t *spte = NULL; - pte_t *pte; + hw_pte_t *spte = NULL; + hw_pte_t *pte; i_mmap_lock_read(mapping); mapping_rmap_tree_foreach(svma, mapping, idx, idx) { @@ -7046,13 +7048,13 @@ pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, } spin_unlock(&mm->page_table_lock); out: - pte = (pte_t *)pmd_alloc(mm, pud, addr); + pte = (hw_pte_t *)pmd_alloc(mm, pud, addr); i_mmap_unlock_read(mapping); return pte; } static int __huge_pmd_unshare(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, + struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep, bool check_locks) { unsigned long sz = huge_page_size(hstate_vma(vma)); @@ -7093,7 +7095,7 @@ static int __huge_pmd_unshare(struct mmu_gather *tlb, * was not a shared PMD table. */ int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { return __huge_pmd_unshare(tlb, vma, addr, ptep, /*check_locks=*/true); } @@ -7123,21 +7125,21 @@ void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma) #else /* !CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING */ -pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, pud_t *pud) { return NULL; } static int __huge_pmd_unshare(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, + struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep, bool check_locks) { return 0; } int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { return 0; } @@ -7158,13 +7160,13 @@ bool want_pmd_share(struct vm_area_struct *vma, unsigned long addr) #endif /* CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING */ #ifdef CONFIG_ARCH_WANT_GENERAL_HUGETLB -pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, unsigned long sz) { pgd_t *pgd; p4d_t *p4d; pud_t *pud; - pte_t *pte = NULL; + hw_pte_t *pte = NULL; pgd = pgd_offset(mm, addr); p4d = p4d_alloc(mm, pgd, addr); @@ -7173,13 +7175,13 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, pud = pud_alloc(mm, p4d, addr); if (pud) { if (sz == PUD_SIZE) { - pte = (pte_t *)pud; + pte = (hw_pte_t *)pud; } else { BUG_ON(sz != PMD_SIZE); if (want_pmd_share(vma, addr) && pud_none(*pud)) pte = huge_pmd_share(mm, vma, addr, pud); else - pte = (pte_t *)pmd_alloc(mm, pud, addr); + pte = (hw_pte_t *)pmd_alloc(mm, pud, addr); } } @@ -7201,7 +7203,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, * size @sz doesn't match the hugepage size at this level of the page * table. */ -pte_t *huge_pte_offset(struct mm_struct *mm, +hw_pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz) { pgd_t *pgd; @@ -7219,14 +7221,14 @@ pte_t *huge_pte_offset(struct mm_struct *mm, pud = pud_offset(p4d, addr); if (sz == PUD_SIZE) /* must be pud huge, non-present or none */ - return (pte_t *)pud; + return (hw_pte_t *)pud; if (!pud_present(*pud)) return NULL; /* must have a valid entry and size to go further */ pmd = pmd_offset(pud, addr); /* must be pmd huge, non-present or none */ - return (pte_t *)pmd; + return (hw_pte_t *)pmd; } /* @@ -7405,7 +7407,7 @@ static void hugetlb_unshare_pmds(struct vm_area_struct *vma, struct mmu_gather tlb; unsigned long address; spinlock_t *ptl; - pte_t *ptep; + hw_pte_t *ptep; if (!(vma->vm_flags & VM_MAYSHARE)) return; diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c index eb339c4a71f40..bf85d82c29b96 100644 --- a/mm/hugetlb_vmemmap.c +++ b/mm/hugetlb_vmemmap.c @@ -34,7 +34,7 @@ * operations. */ struct vmemmap_remap_walk { - void (*remap_pte)(pte_t *pte, unsigned long addr, + void (*remap_pte)(hw_pte_t *pte, unsigned long addr, struct vmemmap_remap_walk *walk); unsigned long nr_walked; @@ -56,7 +56,7 @@ static int vmemmap_split_pmd(pmd_t *pmd, struct page *head, unsigned long start, pmd_t __pmd; int i; unsigned long addr = start; - pte_t *pgtable; + hw_pte_t *pgtable; pgtable = pte_alloc_one_kernel(&init_mm); if (!pgtable) @@ -65,7 +65,8 @@ static int vmemmap_split_pmd(pmd_t *pmd, struct page *head, unsigned long start, pmd_populate_kernel(&init_mm, &__pmd, pgtable); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { - pte_t entry, *pte; + pte_t entry; + hw_pte_t *pte; pgprot_t pgprot = PAGE_KERNEL; entry = mk_pte(head + i, pgprot); @@ -137,7 +138,7 @@ static int vmemmap_pmd_entry(pmd_t *pmd, unsigned long addr, return vmemmap_split_pmd(pmd, head, addr & PMD_MASK, vmemmap_walk); } -static int vmemmap_pte_entry(pte_t *pte, unsigned long addr, +static int vmemmap_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { struct vmemmap_remap_walk *vmemmap_walk = walk->private; @@ -199,7 +200,7 @@ static void free_vmemmap_page_list(struct list_head *list) free_vmemmap_page(page); } -static void vmemmap_remap_pte(pte_t *pte, unsigned long addr, +static void vmemmap_remap_pte(hw_pte_t *pte, unsigned long addr, struct vmemmap_remap_walk *walk) { struct page *page = pte_page(ptep_get(pte)); @@ -233,7 +234,7 @@ static void vmemmap_remap_pte(pte_t *pte, unsigned long addr, set_pte_at(&init_mm, addr, pte, entry); } -static void vmemmap_restore_pte(pte_t *pte, unsigned long addr, +static void vmemmap_restore_pte(hw_pte_t *pte, unsigned long addr, struct vmemmap_remap_walk *walk) { struct page *src = pte_page(ptep_get(pte)), *dst; diff --git a/mm/internal.h b/mm/internal.h index e16f1250b25c8..54efddc4536f4 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -263,7 +263,7 @@ void unmap_vmas(struct mmu_gather *tlb, struct unmap_desc *unmap); #ifdef CONFIG_MMU bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pte_t pte, + unsigned long addr, hw_pte_t *ptep, pte_t pte, unsigned long nr_ptes); static inline void get_anon_vma(struct anon_vma *anon_vma) @@ -394,7 +394,7 @@ static inline pte_t __pte_batch_clear_ignored(pte_t pte, fpb_t flags) * Return: the number of table entries in the batch. */ static inline unsigned int folio_pte_batch_flags(struct folio *folio, - struct vm_area_struct *vma, pte_t *ptep, pte_t *ptentp, + struct vm_area_struct *vma, hw_pte_t *ptep, pte_t *ptentp, unsigned int max_nr, fpb_t flags) { bool any_writable = false, any_young = false, any_dirty = false; @@ -448,7 +448,7 @@ static inline unsigned int folio_pte_batch_flags(struct folio *folio, return min(nr, max_nr); } -unsigned int folio_pte_batch(struct folio *folio, pte_t *ptep, pte_t pte, +unsigned int folio_pte_batch(struct folio *folio, hw_pte_t *ptep, pte_t pte, unsigned int max_nr); /** @@ -505,11 +505,11 @@ static inline pte_t pte_next_swp_offset(pte_t pte) * * Return: the number of table entries in the batch. */ -static inline int swap_pte_batch(pte_t *start_ptep, int max_nr, pte_t pte) +static inline int swap_pte_batch(hw_pte_t *start_ptep, int max_nr, pte_t pte) { pte_t expected_pte = pte_next_swp_offset(pte); - const pte_t *end_ptep = start_ptep + max_nr; - pte_t *ptep = start_ptep + 1; + const hw_pte_t *end_ptep = start_ptep + max_nr; + hw_pte_t *ptep = start_ptep + 1; VM_WARN_ON(max_nr < 1); VM_WARN_ON(!softleaf_is_swap(softleaf_from_pte(pte))); @@ -1547,7 +1547,7 @@ static inline void maybe_rmap_unlock_action(struct vm_area_struct *vma, #ifdef CONFIG_MMU_NOTIFIER static inline bool clear_flush_young_ptes_notify(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { bool young; @@ -1568,7 +1568,7 @@ static inline bool pmdp_clear_flush_young_notify(struct vm_area_struct *vma, } static inline bool test_and_clear_young_ptes_notify(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { bool young; diff --git a/mm/kasan/init.c b/mm/kasan/init.c index 66a8838879876..30c5266eaf37e 100644 --- a/mm/kasan/init.c +++ b/mm/kasan/init.c @@ -92,7 +92,7 @@ static __init void *early_alloc(size_t size, int node) static void __ref zero_pte_populate(pmd_t *pmd, unsigned long addr, unsigned long end) { - pte_t *pte = pte_offset_kernel(pmd, addr); + hw_pte_t *pte = pte_offset_kernel(pmd, addr); pte_t zero_pte; zero_pte = pfn_pte(PFN_DOWN(__pa_symbol(kasan_early_shadow_page)), @@ -122,7 +122,7 @@ static int __ref zero_pmd_populate(pud_t *pud, unsigned long addr, } if (pmd_none(*pmd)) { - pte_t *p; + hw_pte_t *p; if (slab_is_available()) p = pte_alloc_one_kernel(&init_mm); @@ -281,9 +281,9 @@ int __ref kasan_populate_early_shadow(const void *shadow_start, return 0; } -static void kasan_free_pte(pte_t *pte_start, pmd_t *pmd) +static void kasan_free_pte(hw_pte_t *pte_start, pmd_t *pmd) { - pte_t *pte; + hw_pte_t *pte; int i; for (i = 0; i < PTRS_PER_PTE; i++) { @@ -341,7 +341,7 @@ static void kasan_free_p4d(p4d_t *p4d_start, pgd_t *pgd) pgd_clear(pgd); } -static void kasan_remove_pte_table(pte_t *pte, unsigned long addr, +static void kasan_remove_pte_table(hw_pte_t *pte, unsigned long addr, unsigned long end) { unsigned long next; @@ -369,7 +369,7 @@ static void kasan_remove_pmd_table(pmd_t *pmd, unsigned long addr, unsigned long next; for (; addr < end; addr = next, pmd++) { - pte_t *pte; + hw_pte_t *pte; next = pmd_addr_end(addr, end); diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c index d286e0a045437..86fc7ed45dcd0 100644 --- a/mm/kasan/shadow.c +++ b/mm/kasan/shadow.c @@ -189,7 +189,7 @@ static bool shadow_mapped(unsigned long addr) p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; if (pgd_none(*pgd)) return false; @@ -297,7 +297,7 @@ struct vmalloc_populate_data { struct page **pages; }; -static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr, +static int kasan_populate_vmalloc_pte(hw_pte_t *ptep, unsigned long addr, void *_data) { struct vmalloc_populate_data *data = _data; @@ -465,7 +465,7 @@ int __kasan_populate_vmalloc(unsigned long addr, unsigned long size, gfp_t gfp_m return 0; } -static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr, +static int kasan_depopulate_vmalloc_pte(hw_pte_t *ptep, unsigned long addr, void *unused) { pte_t pte; diff --git a/mm/khugepaged.c b/mm/khugepaged.c index f49a6710933b1..4a7074f58b55d 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -639,8 +639,8 @@ static void release_pte_folio(struct folio *folio) folio_putback_lru(folio); } -static void release_pte_pages(pte_t *pte, pte_t *_pte, - struct list_head *compound_pagelist) +static void release_pte_pages(hw_pte_t *pte, hw_pte_t *_pte, + struct list_head *compound_pagelist) { struct folio *folio, *tmp; @@ -685,7 +685,8 @@ static void count_collapse_event(unsigned int order, enum vm_event_item vm_event } static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma, - unsigned long start_addr, pte_t *pte, struct collapse_control *cc, + unsigned long start_addr, hw_pte_t *pte, + struct collapse_control *cc, unsigned int order, struct list_head *compound_pagelist) { const unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, order); @@ -694,7 +695,7 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma, struct page *page = NULL; struct folio *folio = NULL; unsigned long addr = start_addr; - pte_t *_pte; + hw_pte_t *_pte; int none_or_zero = 0, shared = 0, referenced = 0; enum scan_result result = SCAN_FAIL; @@ -840,16 +841,18 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma, return result; } -static void __collapse_huge_page_copy_succeeded(pte_t *pte, - struct vm_area_struct *vma, unsigned long address, - spinlock_t *ptl, unsigned int order, - struct list_head *compound_pagelist) +static void __collapse_huge_page_copy_succeeded(hw_pte_t *pte, + struct vm_area_struct *vma, + unsigned long address, + spinlock_t *ptl, + unsigned int order, + struct list_head *compound_pagelist) { const unsigned long nr_pages = 1UL << order; unsigned long end = address + (PAGE_SIZE * nr_pages); struct folio *src, *tmp; pte_t pteval; - pte_t *_pte; + hw_pte_t *_pte; unsigned int nr_ptes; for (_pte = pte; _pte < pte + nr_pages; _pte += nr_ptes, @@ -904,9 +907,11 @@ static void __collapse_huge_page_copy_succeeded(pte_t *pte, } } -static void __collapse_huge_page_copy_failed(pte_t *pte, - pmd_t *pmd, pmd_t orig_pmd, struct vm_area_struct *vma, - unsigned int order, struct list_head *compound_pagelist) +static void __collapse_huge_page_copy_failed(hw_pte_t *pte, + pmd_t *pmd, pmd_t orig_pmd, + struct vm_area_struct *vma, + unsigned int order, + struct list_head *compound_pagelist) { const unsigned long nr_pages = 1UL << order; spinlock_t *pmd_ptl; @@ -942,10 +947,14 @@ static void __collapse_huge_page_copy_failed(pte_t *pte, * @ptl: lock on raw pages' PTEs * @compound_pagelist: list that stores compound pages */ -static enum scan_result __collapse_huge_page_copy(pte_t *pte, struct folio *folio, - pmd_t *pmd, pmd_t orig_pmd, struct vm_area_struct *vma, - unsigned long address, spinlock_t *ptl, unsigned int order, - struct list_head *compound_pagelist) +static enum scan_result __collapse_huge_page_copy(hw_pte_t *pte, + struct folio *folio, + pmd_t *pmd, pmd_t orig_pmd, + struct vm_area_struct *vma, + unsigned long address, + spinlock_t *ptl, + unsigned int order, + struct list_head *compound_pagelist) { const unsigned long nr_pages = 1UL << order; unsigned int i; @@ -1164,7 +1173,7 @@ static enum scan_result __collapse_huge_page_swapin(struct mm_struct *mm, vm_fault_t ret = 0; unsigned long addr, end = start_addr + (PAGE_SIZE << order); enum scan_result result; - pte_t *pte = NULL; + hw_pte_t *pte = NULL; spinlock_t *ptl; for (addr = start_addr; addr < end; addr += PAGE_SIZE) { @@ -1292,7 +1301,7 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s const unsigned long end_addr = start_addr + (PAGE_SIZE << order); LIST_HEAD(compound_pagelist); pmd_t *pmd, _pmd; - pte_t *pte = NULL; + hw_pte_t *pte = NULL; pgtable_t pgtable; struct folio *folio; spinlock_t *pmd_ptl, *pte_ptl; @@ -1606,7 +1615,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm, unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER); enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE; pmd_t *pmd; - pte_t *pte, *_pte, pteval; + hw_pte_t *pte, *_pte; + pte_t pteval; int i; int none_or_zero = 0, shared = 0, referenced = 0; enum scan_result result = SCAN_FAIL; @@ -1871,7 +1881,7 @@ static enum scan_result try_collapse_pte_mapped_thp(struct mm_struct *mm, unsign unsigned long end = haddr + HPAGE_PMD_SIZE; struct vm_area_struct *vma = vma_lookup(mm, haddr); struct folio *folio; - pte_t *start_pte, *pte; + hw_pte_t *start_pte, *pte; pmd_t *pmd, pgt_pmd; spinlock_t *pml = NULL, *ptl; int i; diff --git a/mm/ksm.c b/mm/ksm.c index 2a4f19fe0f696..3882d8916efa4 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -618,7 +618,7 @@ static int break_ksm_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned long en { unsigned long *found_addr = (unsigned long *) walk->private; struct mm_struct *mm = walk->mm; - pte_t *start_ptep, *ptep; + hw_pte_t *start_ptep, *ptep; spinlock_t *ptl; int found = 0; @@ -1399,7 +1399,7 @@ static int replace_page(struct vm_area_struct *vma, struct page *page, struct folio *folio = page_folio(page); pmd_t *pmd; pmd_t pmde; - pte_t *ptep; + hw_pte_t *ptep; pte_t newpte; spinlock_t *ptl; unsigned long addr; @@ -2530,7 +2530,8 @@ static int ksm_next_page_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned lon { struct ksm_next_page_arg *private = walk->private; struct vm_area_struct *vma = walk->vma; - pte_t *start_ptep = NULL, *ptep, pte; + hw_pte_t *start_ptep = NULL, *ptep; + pte_t pte; struct mm_struct *mm = walk->mm; struct folio *folio; struct page *page; diff --git a/mm/madvise.c b/mm/madvise.c index dd75a673e108f..a08270c9f7610 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -198,7 +198,7 @@ static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start, { struct vm_area_struct *vma = walk->private; struct swap_io_ctx ctx = {}; - pte_t *ptep = NULL; + hw_pte_t *ptep = NULL; spinlock_t *ptl; unsigned long addr; @@ -350,7 +350,7 @@ static inline bool can_do_file_pageout(struct vm_area_struct *vma) } static inline int madvise_folio_pte_batch(unsigned long addr, unsigned long end, - struct folio *folio, pte_t *ptep, + struct folio *folio, hw_pte_t *ptep, pte_t *ptentp) { int max_nr = (end - addr) / PAGE_SIZE; @@ -368,7 +368,8 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, bool pageout = private->pageout; struct mm_struct *mm = tlb->mm; struct vm_area_struct *vma = walk->vma; - pte_t *start_pte, *pte, ptent; + hw_pte_t *start_pte, *pte; + pte_t ptent; spinlock_t *ptl; struct folio *folio = NULL; LIST_HEAD(folio_list); @@ -670,7 +671,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, struct mm_struct *mm = tlb->mm; struct vm_area_struct *vma = walk->vma; spinlock_t *ptl; - pte_t *start_pte, *pte, ptent; + hw_pte_t *start_pte, *pte; + pte_t ptent; struct folio *folio; int nr_swap = 0; unsigned long next; @@ -1095,7 +1097,7 @@ static int guard_install_pmd_entry(pmd_t *pmd, unsigned long addr, return pmd_trans_huge(pmdval); } -static int guard_install_pte_entry(pte_t *pte, unsigned long addr, +static int guard_install_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { pte_t pteval = ptep_get(pte); @@ -1238,7 +1240,7 @@ static int guard_remove_pmd_entry(pmd_t *pmd, unsigned long addr, return 0; } -static int guard_remove_pte_entry(pte_t *pte, unsigned long addr, +static int guard_remove_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { pte_t ptent = ptep_get(pte); diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c index e0efa36e0a076..dcbd39912f819 100644 --- a/mm/mapping_dirty_helpers.c +++ b/mm/mapping_dirty_helpers.c @@ -31,7 +31,7 @@ struct wp_walk { * The function write-protects a pte and records the range in * virtual address space of touched ptes for efficient range TLB flushes. */ -static int wp_pte(pte_t *pte, unsigned long addr, unsigned long end, +static int wp_pte(hw_pte_t *pte, unsigned long addr, unsigned long end, struct mm_walk *walk) { struct wp_walk *wpwalk = walk->private; @@ -86,7 +86,7 @@ struct clean_walk { * in the address_space, as well as the first and last of the bits * touched. */ -static int clean_record_pte(pte_t *pte, unsigned long addr, +static int clean_record_pte(hw_pte_t *pte, unsigned long addr, unsigned long end, struct mm_walk *walk) { struct wp_walk *wpwalk = walk->private; diff --git a/mm/memory-failure.c b/mm/memory-failure.c index a8b03e2920ba8..a89f3fde47a5d 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -342,7 +342,7 @@ static unsigned long dev_pagemap_mapping_shift(struct vm_area_struct *vma, p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; pte_t ptent; VM_BUG_ON_VMA(address == -EFAULT, vma); @@ -742,7 +742,7 @@ static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr, { struct hwpoison_walk *hwp = walk->private; int ret = 0; - pte_t *ptep, *mapped_pte; + hw_pte_t *ptep, *mapped_pte; spinlock_t *ptl; ptl = pmd_trans_huge_lock(pmdp, walk->vma); @@ -770,7 +770,7 @@ static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr, } #ifdef CONFIG_HUGETLB_PAGE -static int hwpoison_hugetlb_range(pte_t *ptep, unsigned long hmask, +static int hwpoison_hugetlb_range(hw_pte_t *ptep, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { diff --git a/mm/memory.c b/mm/memory.c index ec63dd6212ac5..7fc8ce10503c3 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -462,7 +462,7 @@ int __pte_alloc(struct mm_struct *mm, pmd_t *pmd) int __pte_alloc_kernel(pmd_t *pmd) { - pte_t *new = pte_alloc_one_kernel(&init_mm); + hw_pte_t *new = pte_alloc_one_kernel(&init_mm); if (!new) return -ENOMEM; @@ -909,7 +909,7 @@ struct page *vm_normal_page_pud(struct vm_area_struct *vma, */ static void restore_exclusive_pte(struct vm_area_struct *vma, struct folio *folio, struct page *page, unsigned long address, - pte_t *ptep, pte_t orig_pte) + hw_pte_t *ptep, pte_t orig_pte) { pte_t pte; @@ -946,7 +946,7 @@ static void restore_exclusive_pte(struct vm_area_struct *vma, * sleeping. */ static int try_restore_exclusive_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pte_t orig_pte) + unsigned long addr, hw_pte_t *ptep, pte_t orig_pte) { const softleaf_t entry = softleaf_from_pte(orig_pte); struct page *page = softleaf_to_page(entry); @@ -969,7 +969,7 @@ static int try_restore_exclusive_pte(struct vm_area_struct *vma, static unsigned long copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, - pte_t *dst_pte, pte_t *src_pte, struct vm_area_struct *dst_vma, + hw_pte_t *dst_pte, hw_pte_t *src_pte, struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, unsigned long addr, int *rss) { pte_t orig_pte = ptep_get(src_pte); @@ -1083,7 +1083,7 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, */ static inline int copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, - pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss, + hw_pte_t *dst_pte, hw_pte_t *src_pte, unsigned long addr, int *rss, struct folio **prealloc, struct page *page) { struct folio *new_folio; @@ -1122,7 +1122,7 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma } static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma, - struct vm_area_struct *src_vma, pte_t *dst_pte, pte_t *src_pte, + struct vm_area_struct *src_vma, hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t pte, unsigned long addr, int nr) { struct mm_struct *src_mm = src_vma->vm_mm; @@ -1172,7 +1172,7 @@ static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma, */ static inline int copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, - pte_t *dst_pte, pte_t *src_pte, pte_t pte, unsigned long addr, + hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t pte, unsigned long addr, int max_nr, int *rss, struct folio **prealloc) { fpb_t flags = FPB_MERGE_WRITE; @@ -1272,8 +1272,8 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, { struct mm_struct *dst_mm = dst_vma->vm_mm; struct mm_struct *src_mm = src_vma->vm_mm; - pte_t *orig_src_pte, *orig_dst_pte; - pte_t *src_pte, *dst_pte; + hw_pte_t *orig_src_pte, *orig_dst_pte; + hw_pte_t *src_pte, *dst_pte; pmd_t dummy_pmdval; pte_t ptent; spinlock_t *src_ptl, *dst_ptl; @@ -1666,7 +1666,7 @@ static inline bool zap_drop_markers(struct zap_details *details) * Returns true if uffd-wp PTEs were installed, false otherwise. */ bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pte_t pte, + unsigned long addr, hw_pte_t *ptep, pte_t pte, unsigned long nr_ptes) { bool arm_uffd_pte = false; @@ -1720,7 +1720,7 @@ bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma, */ static inline bool zap_install_uffd_wp_if_needed(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte, int nr, + unsigned long addr, hw_pte_t *pte, int nr, struct zap_details *details, pte_t pteval) { if (zap_drop_markers(details)) @@ -1731,7 +1731,7 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma, static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb, struct vm_area_struct *vma, struct folio *folio, - struct page *page, pte_t *pte, pte_t ptent, unsigned int nr, + struct page *page, hw_pte_t *pte, pte_t ptent, unsigned int nr, unsigned long addr, struct zap_details *details, int *rss, bool *force_flush, bool *force_break, bool *any_skipped) { @@ -1781,7 +1781,7 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb, * Returns the number of processed (skipped or zapped) PTEs (at least 1). */ static inline int zap_present_ptes(struct mmu_gather *tlb, - struct vm_area_struct *vma, pte_t *pte, pte_t ptent, + struct vm_area_struct *vma, hw_pte_t *pte, pte_t ptent, unsigned int max_nr, unsigned long addr, struct zap_details *details, int *rss, bool *force_flush, bool *force_break, bool *any_skipped) @@ -1827,7 +1827,7 @@ static inline int zap_present_ptes(struct mmu_gather *tlb, } static inline int zap_nonpresent_ptes(struct mmu_gather *tlb, - struct vm_area_struct *vma, pte_t *pte, pte_t ptent, + struct vm_area_struct *vma, hw_pte_t *pte, pte_t ptent, unsigned int max_nr, unsigned long addr, struct zap_details *details, int *rss, bool *any_skipped) { @@ -1898,7 +1898,7 @@ static inline int zap_nonpresent_ptes(struct mmu_gather *tlb, } static inline int do_zap_pte_range(struct mmu_gather *tlb, - struct vm_area_struct *vma, pte_t *pte, + struct vm_area_struct *vma, hw_pte_t *pte, unsigned long addr, unsigned long end, struct zap_details *details, int *rss, bool *force_flush, bool *force_break, @@ -1961,7 +1961,7 @@ static bool zap_pte_table_if_empty(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, pmd_t *pmdval) { spinlock_t *pml, *ptl = NULL; - pte_t *start_pte, *pte; + hw_pte_t *start_pte, *pte; int i; pml = pmd_lock(mm, pmd); @@ -2001,8 +2001,8 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb, struct mm_struct *mm = tlb->mm; int rss[NR_MM_COUNTERS]; spinlock_t *ptl; - pte_t *start_pte; - pte_t *pte; + hw_pte_t *start_pte; + hw_pte_t *pte; pmd_t pmdval; unsigned long start = addr; bool direct_reclaim = true; @@ -2384,7 +2384,7 @@ static pmd_t *walk_to_pmd(struct mm_struct *mm, unsigned long addr) return pmd; } -pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr, +hw_pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr, spinlock_t **ptl) { pmd_t *pmd = walk_to_pmd(mm, addr); @@ -2442,7 +2442,7 @@ static int validate_page_before_insert(struct vm_area_struct *vma, return 0; } -static int insert_page_into_pte_locked(struct vm_area_struct *vma, pte_t *pte, +static int insert_page_into_pte_locked(struct vm_area_struct *vma, hw_pte_t *pte, unsigned long addr, struct page *page, pgprot_t prot, bool mkwrite) { @@ -2487,7 +2487,7 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr, struct page *page, pgprot_t prot, bool mkwrite) { int retval; - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; retval = validate_page_before_insert(vma, page); @@ -2504,7 +2504,7 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr, return retval; } -static int insert_page_in_batch_locked(struct vm_area_struct *vma, pte_t *pte, +static int insert_page_in_batch_locked(struct vm_area_struct *vma, hw_pte_t *pte, unsigned long addr, struct page *page, pgprot_t prot) { int err; @@ -2522,7 +2522,7 @@ static int insert_pages(struct vm_area_struct *vma, unsigned long addr, struct page **pages, unsigned long *num, pgprot_t prot) { pmd_t *pmd = NULL; - pte_t *start_pte, *pte; + hw_pte_t *start_pte, *pte; spinlock_t *pte_lock; struct mm_struct *const mm = vma->vm_mm; unsigned long curr_page_idx = 0; @@ -2765,7 +2765,8 @@ static vm_fault_t insert_pfn(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn, pgprot_t prot, bool mkwrite) { struct mm_struct *mm = vma->vm_mm; - pte_t *pte, entry; + hw_pte_t *pte; + pte_t entry; spinlock_t *ptl; pte = get_locked_pte(mm, addr, &ptl); @@ -3006,7 +3007,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, unsigned long end, unsigned long pfn, pgprot_t prot) { - pte_t *pte, *mapped_pte; + hw_pte_t *pte, *mapped_pte; spinlock_t *ptl; int err = 0; @@ -3407,7 +3408,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, pte_fn_t fn, void *data, bool create, pgtbl_mod_mask *mask) { - pte_t *pte, *mapped_pte; + hw_pte_t *pte, *mapped_pte; int err = 0; spinlock_t *ptl; @@ -4710,7 +4711,7 @@ static vm_fault_t handle_pte_marker(struct vm_fault *vmf) /* * Check if the PTEs within a range are contiguous swap entries. */ -static bool can_swapin_thp(struct vm_fault *vmf, pte_t *ptep, int nr_pages) +static bool can_swapin_thp(struct vm_fault *vmf, hw_pte_t *ptep, int nr_pages) { unsigned long addr; int idx; @@ -4762,7 +4763,7 @@ static unsigned long thp_swapin_suitable_orders(struct vm_fault *vmf) unsigned long addr; softleaf_t entry; spinlock_t *ptl; - pte_t *pte; + hw_pte_t *pte; int order; /* @@ -4856,7 +4857,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) int nr_pages; unsigned long page_idx; unsigned long address; - pte_t *ptep; + hw_pte_t *ptep; if (!pte_unmap_same(vmf)) goto out; @@ -5025,7 +5026,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) unsigned long idx = folio_page_idx(folio, page); unsigned long folio_start = address - idx * PAGE_SIZE; unsigned long folio_end = folio_start + nr * PAGE_SIZE; - pte_t *folio_ptep; + hw_pte_t *folio_ptep; pte_t folio_pte; if (unlikely(folio_start < max(address & PMD_MASK, vma->vm_start))) @@ -5255,7 +5256,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) return ret; } -static bool pte_range_none(pte_t *pte, int nr_pages) +static bool pte_range_none(hw_pte_t *pte, int nr_pages) { int i; @@ -5274,7 +5275,7 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf) unsigned long orders; struct folio *folio; unsigned long addr; - pte_t *pte; + hw_pte_t *pte; gfp_t gfp; int order; @@ -5356,7 +5357,7 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf) return folio_prealloc(vma->vm_mm, vma, vmf->address, true); } -void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte, +void map_anon_folio_pte_nopf(struct folio *folio, hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr, bool uffd_wp) { @@ -5377,7 +5378,7 @@ void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte, update_mmu_cache_range(NULL, vma, addr, pte, nr_pages); } -static void map_anon_folio_pte_pf(struct folio *folio, pte_t *pte, +static void map_anon_folio_pte_pf(struct folio *folio, hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr, bool uffd_wp) { const unsigned int order = folio_order(folio); @@ -6162,7 +6163,7 @@ int numa_migrate_check(struct folio *folio, struct vm_fault *vmf, } static void numa_rebuild_single_mapping(struct vm_fault *vmf, struct vm_area_struct *vma, - unsigned long fault_addr, pte_t *fault_pte, + unsigned long fault_addr, hw_pte_t *fault_pte, bool writable) { pte_t pte, old_pte; @@ -6184,7 +6185,7 @@ static void numa_rebuild_large_mapping(struct vm_fault *vmf, struct vm_area_stru unsigned long start, end, addr = vmf->address; unsigned long addr_start = addr - (nr << PAGE_SHIFT); unsigned long pt_start = ALIGN_DOWN(addr, PMD_SIZE); - pte_t *start_ptep; + hw_pte_t *start_ptep; /* Stay within the VMA and within the page table. */ start = max3(addr_start, pt_start, vma->vm_start); @@ -6944,7 +6945,7 @@ int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address) #endif /* __PAGETABLE_PMD_FOLDED */ static inline void pfnmap_args_setup(struct follow_pfnmap_args *args, - spinlock_t *lock, pte_t *ptep, + spinlock_t *lock, hw_pte_t *ptep, pgprot_t pgprot, unsigned long pfn_base, unsigned long addr_mask, bool writable, bool special) @@ -7013,7 +7014,8 @@ int follow_pfnmap_start(struct follow_pfnmap_args *args) p4d_t *p4dp, p4d; pud_t *pudp, pud; pmd_t *pmdp, pmd; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; pfnmap_lockdep_assert(vma); diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 2ad0a5f18280a..51ab12fa4cb61 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -710,7 +710,7 @@ static int queue_folios_pte_range(pmd_t *pmd, unsigned long addr, struct folio *folio; struct queue_pages *qp = walk->private; unsigned long flags = qp->flags; - pte_t *pte, *mapped_pte; + hw_pte_t *pte, *mapped_pte; pte_t ptent; spinlock_t *ptl; int max_nr, nr; @@ -790,7 +790,7 @@ static int queue_folios_pte_range(pmd_t *pmd, unsigned long addr, return 0; } -static int queue_folios_hugetlb(pte_t *pte, unsigned long hmask, +static int queue_folios_hugetlb(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { diff --git a/mm/migrate.c b/mm/migrate.c index a369d0c95c386..75b4b637290c2 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -494,7 +494,7 @@ void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd, unsigned long address) { spinlock_t *ptl; - pte_t *ptep; + hw_pte_t *ptep; pte_t pte; softleaf_t entry; @@ -525,7 +525,7 @@ void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd, * * This function will release the vma lock before returning. */ -void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep) +void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep) { spinlock_t *ptl = huge_pte_lockptr(hstate_vma(vma), vma->vm_mm, ptep); softleaf_t entry; diff --git a/mm/migrate_device.c b/mm/migrate_device.c index 009bfa8b212d5..6138833fa902b 100644 --- a/mm/migrate_device.c +++ b/mm/migrate_device.c @@ -254,7 +254,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp, spinlock_t *ptl; struct folio *fault_folio = migrate->fault_page ? page_folio(migrate->fault_page) : NULL; - pte_t *ptep; + hw_pte_t *ptep; again: if (pmd_trans_huge(*pmdp) || !pmd_present(*pmdp)) { @@ -989,7 +989,7 @@ static void migrate_vma_insert_page(struct migrate_vma *migrate, p4d_t *p4dp; pud_t *pudp; pmd_t *pmdp; - pte_t *ptep; + hw_pte_t *ptep; pte_t orig_pte; /* Only allow populating anonymous memory */ diff --git a/mm/mincore.c b/mm/mincore.c index c086836bc4bcc..65cc43c85d03f 100644 --- a/mm/mincore.c +++ b/mm/mincore.c @@ -24,7 +24,7 @@ #include "swap.h" #include "internal.h" -static int mincore_hugetlb(pte_t *pte, unsigned long hmask, unsigned long addr, +static int mincore_hugetlb(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { #ifdef CONFIG_HUGETLB_PAGE @@ -164,7 +164,7 @@ static int mincore_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, { spinlock_t *ptl; struct vm_area_struct *vma = walk->vma; - pte_t *ptep; + hw_pte_t *ptep; unsigned char *vec = walk->private; int nr = (end - addr) >> PAGE_SHIFT; int step, i; diff --git a/mm/mlock.c b/mm/mlock.c index efa6716e4dfbd..36002b80382a9 100644 --- a/mm/mlock.c +++ b/mm/mlock.c @@ -305,7 +305,7 @@ void munlock_folio(struct folio *folio) } static inline unsigned int folio_mlock_step(struct folio *folio, - pte_t *pte, unsigned long addr, unsigned long end) + hw_pte_t *pte, unsigned long addr, unsigned long end) { unsigned int count = (end - addr) >> PAGE_SHIFT; pte_t ptent = ptep_get(pte); @@ -353,7 +353,7 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr, { struct vm_area_struct *vma = walk->vma; spinlock_t *ptl; - pte_t *start_pte, *pte; + hw_pte_t *start_pte, *pte; pte_t ptent; struct folio *folio; unsigned int step = 1; diff --git a/mm/mprotect.c b/mm/mprotect.c index 2888ee638d872..1d23475e0bb76 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -103,7 +103,7 @@ bool can_change_pte_writable(struct vm_area_struct *vma, unsigned long addr, return can_change_shared_pte_writable(vma, pte); } -static int mprotect_folio_pte_batch(struct folio *folio, pte_t *ptep, +static int mprotect_folio_pte_batch(struct folio *folio, hw_pte_t *ptep, pte_t pte, int max_nr_ptes, fpb_t flags) { /* No underlying folio, so cannot batch */ @@ -118,7 +118,7 @@ static int mprotect_folio_pte_batch(struct folio *folio, pte_t *ptep, /* Set nr_ptes number of ptes, starting from idx */ static __always_inline void prot_commit_flush_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pte_t oldpte, pte_t ptent, + unsigned long addr, hw_pte_t *ptep, pte_t oldpte, pte_t ptent, int nr_ptes, int idx, bool set_write, struct mmu_gather *tlb) { /* @@ -170,7 +170,7 @@ static __always_inline int page_anon_exclusive_batch(int start_idx, int max_len, * retrieve sub-batches. */ static __always_inline void commit_anon_folio_batch(struct vm_area_struct *vma, - struct folio *folio, struct page *first_page, unsigned long addr, pte_t *ptep, + struct folio *folio, struct page *first_page, unsigned long addr, hw_pte_t *ptep, pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb) { bool expected_anon_exclusive; @@ -189,7 +189,7 @@ static __always_inline void commit_anon_folio_batch(struct vm_area_struct *vma, } static __always_inline void set_write_prot_commit_flush_ptes(struct vm_area_struct *vma, - struct folio *folio, struct page *page, unsigned long addr, pte_t *ptep, + struct folio *folio, struct page *page, unsigned long addr, hw_pte_t *ptep, pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb) { bool set_write; @@ -212,7 +212,7 @@ static __always_inline void set_write_prot_commit_flush_ptes(struct vm_area_stru } static long change_softleaf_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte, pte_t oldpte, unsigned long cp_flags) + unsigned long addr, hw_pte_t *pte, pte_t oldpte, unsigned long cp_flags) { const bool uffd_prot = cp_flags & (MM_CP_UFFD_WP | MM_CP_UFFD_RWP); const bool uffd_prot_resolve = cp_flags & @@ -279,7 +279,7 @@ static long change_softleaf_pte(struct vm_area_struct *vma, } static __always_inline void change_present_ptes(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, + struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep, int nr_ptes, unsigned long end, pgprot_t newprot, struct folio *folio, struct page *page, unsigned long cp_flags) { @@ -332,7 +332,8 @@ static long change_pte_range(struct mmu_gather *tlb, struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr, unsigned long end, pgprot_t newprot, unsigned long cp_flags) { - pte_t *pte, oldpte; + hw_pte_t *pte; + pte_t oldpte; spinlock_t *ptl; long pages = 0; bool is_private_single_threaded; @@ -727,7 +728,7 @@ long change_protection(struct mmu_gather *tlb, return pages; } -static int prot_none_pte_entry(pte_t *pte, unsigned long addr, +static int prot_none_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { return pfn_modify_allowed(pte_pfn(ptep_get(pte)), @@ -736,7 +737,7 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr, } #ifdef CONFIG_HUGETLB_PAGE -static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask, +static int prot_none_hugetlb_entry(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long next, struct mm_walk *walk) { diff --git a/mm/mremap.c b/mm/mremap.c index 7c368440fafe2..5272cea12f80e 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -176,7 +176,7 @@ static pte_t move_soft_dirty_pte(pte_t pte) } static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pte_t pte, int max_nr) + hw_pte_t *ptep, pte_t pte, int max_nr) { struct folio *folio; @@ -200,7 +200,7 @@ static int move_ptes(struct pagetable_move_control *pmc, struct vm_area_struct *vma = pmc->old; bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma); struct mm_struct *mm = vma->vm_mm; - pte_t *old_ptep, *new_ptep; + hw_pte_t *old_ptep, *new_ptep; pte_t old_pte, pte; pmd_t dummy_pmdval; spinlock_t *old_ptl, *new_ptl; diff --git a/mm/page_table_check.c b/mm/page_table_check.c index 143a918c0bde2..705794a817bad 100644 --- a/mm/page_table_check.c +++ b/mm/page_table_check.c @@ -208,7 +208,7 @@ static void page_table_check_pte_flags(pte_t pte) } void __page_table_check_ptes_set(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned int nr) + hw_pte_t *ptep, pte_t pte, unsigned int nr) { unsigned int i; @@ -279,7 +279,7 @@ void __page_table_check_pte_clear_range(struct mm_struct *mm, return; if (!pmd_none(pmd) && !pmd_bad(pmd) && !pmd_leaf(pmd)) { - pte_t *ptep = pte_offset_map(&pmd, addr); + hw_pte_t *ptep = pte_offset_map(&pmd, addr); unsigned long i; if (WARN_ON(!ptep)) diff --git a/mm/pagewalk.c b/mm/pagewalk.c index 7411702a37f58..b6a29a06a19bc 100644 --- a/mm/pagewalk.c +++ b/mm/pagewalk.c @@ -26,7 +26,7 @@ static int real_depth(int depth) return depth; } -static int walk_pte_range_inner(pte_t *pte, unsigned long addr, +static int walk_pte_range_inner(hw_pte_t *pte, unsigned long addr, unsigned long end, struct mm_walk *walk) { const struct mm_walk_ops *ops = walk->ops; @@ -61,7 +61,7 @@ static int walk_pte_range_inner(pte_t *pte, unsigned long addr, static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, struct mm_walk *walk) { - pte_t *pte; + hw_pte_t *pte; int err = 0; spinlock_t *ptl; @@ -341,7 +341,7 @@ static int walk_hugetlb_range(unsigned long addr, unsigned long end, unsigned long next; unsigned long hmask = huge_page_mask(h); unsigned long sz = huge_page_size(h); - pte_t *pte; + hw_pte_t *pte; const struct mm_walk_ops *ops = walk->ops; int err = 0; @@ -905,7 +905,8 @@ struct folio *folio_walk_start(struct folio_walk *fw, struct page *page; pud_t *pudp, pud; pmd_t *pmdp, pmd; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; spinlock_t *ptl; pgd_t *pgdp; p4d_t *p4dp; diff --git a/mm/percpu.c b/mm/percpu.c index 47a903fe3b512..197a786e1c5cf 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -3176,7 +3176,7 @@ void __init __weak pcpu_populate_pte(unsigned long addr) pmd = pmd_offset(pud, addr); if (!pmd_present(*pmd)) { - pte_t *new; + hw_pte_t *new; new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE); pmd_populate_kernel(&init_mm, pmd, new); diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c index 224c444cf45d9..df548ad3d9a54 100644 --- a/mm/pgtable-generic.c +++ b/mm/pgtable-generic.c @@ -80,7 +80,7 @@ void pmd_clear_bad(pmd_t *pmd) * force that call on sun4c so we changed this macro slightly */ int ptep_set_access_flags(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep, + unsigned long address, hw_pte_t *ptep, pte_t entry, int dirty) { int changed = !pte_same(ptep_get(ptep), entry); @@ -94,7 +94,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma, #ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH bool ptep_clear_flush_young(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { bool young; @@ -107,7 +107,7 @@ bool ptep_clear_flush_young(struct vm_area_struct *vma, #ifndef __HAVE_ARCH_PTEP_CLEAR_FLUSH pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address, - pte_t *ptep) + hw_pte_t *ptep) { struct mm_struct *mm = (vma)->vm_mm; pte_t pte; @@ -294,7 +294,7 @@ static unsigned long pmdp_get_lockless_start(void) { return 0; } static void pmdp_get_lockless_end(unsigned long irqflags) { } #endif -pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) +hw_pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) { unsigned long irqflags; pmd_t pmdval; @@ -320,11 +320,11 @@ pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) return NULL; } -pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, spinlock_t **ptlp) { pmd_t pmdval; - pte_t *pte; + hw_pte_t *pte; pte = __pte_offset_map(pmd, addr, &pmdval); if (likely(pte)) @@ -332,11 +332,11 @@ pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, return pte; } -pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp, spinlock_t **ptlp) { - pte_t *pte; + hw_pte_t *pte; VM_WARN_ON_ONCE(!pmdvalp); pte = __pte_offset_map(pmd, addr, pmdvalp); @@ -402,12 +402,12 @@ pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, * table, and may not use RCU at all: "outsiders" like khugepaged should avoid * pte_offset_map() and co once the vma is detached from mm or mm_users is zero. */ -pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, spinlock_t **ptlp) { spinlock_t *ptl; pmd_t pmdval; - pte_t *pte; + hw_pte_t *pte; again: pte = __pte_offset_map(pmd, addr, &pmdval); if (unlikely(!pte)) diff --git a/mm/ptdump.c b/mm/ptdump.c index 5851096e6f656..376880071ca2a 100644 --- a/mm/ptdump.c +++ b/mm/ptdump.c @@ -117,7 +117,7 @@ static int ptdump_pmd_entry(pmd_t *pmd, unsigned long addr, return 0; } -static int ptdump_pte_entry(pte_t *pte, unsigned long addr, +static int ptdump_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { struct ptdump_state *st = walk->private; diff --git a/mm/rmap.c b/mm/rmap.c index b5cc9273fe5a4..0223c4ab0b361 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1122,7 +1122,7 @@ static int page_vma_mkclean_one(struct page_vma_mapped_walk *pvmw) address = pvmw->address; if (pvmw->pte) { - pte_t *pte = pvmw->pte; + hw_pte_t *pte = pvmw->pte; pte_t entry = ptep_get(pte); /* @@ -2139,7 +2139,7 @@ static pte_t swp_pte_prepare(swp_entry_t entry, pte_t old_pte, static bool ttu_anon_swapbacked_folio(struct vm_area_struct *vma, struct folio *folio, struct page *page, unsigned long address, - pte_t *ptep, pte_t pteval) + hw_pte_t *ptep, pte_t pteval) { const bool anon_exclusive = folio_test_anon(folio) && PageAnonExclusive(page); @@ -2174,7 +2174,7 @@ static bool ttu_anon_swapbacked_folio(struct vm_area_struct *vma, } static bool ttu_anon_folio(struct vm_area_struct *vma, struct folio *folio, - struct page *page, unsigned long address, pte_t *ptep, + struct page *page, unsigned long address, hw_pte_t *ptep, pte_t pteval, unsigned long nr_pages) { /* diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index e62e6aa07f126..77eb1749e123f 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -135,7 +135,7 @@ static void * __meminit altmap_alloc_block_buf(unsigned long size, return __va(__pfn_to_phys(pfn)); } -void __meminit vmemmap_verify(pte_t *pte, int node, +void __meminit vmemmap_verify(hw_pte_t *pte, int node, unsigned long start, unsigned long end) { unsigned long pfn = pte_pfn(ptep_get(pte)); @@ -236,11 +236,11 @@ static __meminit void *vmemmap_alloc_pte(unsigned long pfn, int node, return page_address(page); } -static pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node, +static hw_pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node, struct vmem_altmap *altmap, unsigned long ptpfn, unsigned long flags) { - pte_t *pte = pte_offset_kernel(pmd, addr); + hw_pte_t *pte = pte_offset_kernel(pmd, addr); unsigned long pfn = page_to_pfn((struct page *)addr); if (pte_none(ptep_get(pte))) { @@ -323,7 +323,7 @@ static pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node) return pgd; } -static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, +static hw_pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, struct vmem_altmap *altmap, unsigned long ptpfn, unsigned long flags) @@ -332,7 +332,7 @@ static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; pgd = vmemmap_pgd_populate(addr, node); if (!pgd) @@ -361,7 +361,7 @@ static int __meminit vmemmap_populate_range(unsigned long start, unsigned long flags) { unsigned long addr = start; - pte_t *pte; + hw_pte_t *pte; for (; addr < end; addr += PAGE_SIZE) { pte = vmemmap_populate_address(addr, node, altmap, @@ -394,7 +394,7 @@ void vmemmap_wrprotect_hvo(unsigned long addr, unsigned long end, int node, unsigned long headsize) { unsigned long maddr; - pte_t *pte; + hw_pte_t *pte; for (maddr = addr + headsize; maddr < end; maddr += PAGE_SIZE) { pte = virt_to_kpte(maddr); @@ -413,7 +413,7 @@ int __weak __meminit vmemmap_check_pmd(pmd_t *pmd, int node, { if (!pmd_leaf(pmdp_get(pmd))) return 0; - vmemmap_verify((pte_t *)pmd, node, addr, next); + vmemmap_verify((hw_pte_t *)pmd, node, addr, next); return 1; } @@ -497,9 +497,9 @@ static bool __meminit reuse_compound_section(unsigned long start_pfn, return !IS_ALIGNED(offset, nr_pages) && nr_pages > PAGES_PER_SUBSECTION; } -static pte_t * __meminit compound_section_tail_page(unsigned long addr) +static hw_pte_t * __meminit compound_section_tail_page(unsigned long addr) { - pte_t *pte; + hw_pte_t *pte; addr -= PAGE_SIZE; @@ -520,7 +520,7 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn, struct dev_pagemap *pgmap) { unsigned long size, addr; - pte_t *pte; + hw_pte_t *pte; int rc; if (reuse_compound_section(start_pfn, pgmap)) { diff --git a/mm/swap_state.c b/mm/swap_state.c index 305877e1f4d7b..d654449f393e8 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -918,7 +918,8 @@ static struct folio *swap_vma_readahead(swp_entry_t targ_entry, gfp_t gfp_mask, struct swap_io_ctx ctx = {}; struct blk_plug plug; struct folio *folio; - pte_t *pte = NULL, pentry; + hw_pte_t *pte = NULL; + pte_t pentry; int win; unsigned long start, end, addr; pgoff_t ilx = targ_ilx; diff --git a/mm/swapfile.c b/mm/swapfile.c index 869a918b18e8e..2f6aa8dc2f5bb 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -2500,7 +2500,8 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, struct page *page; struct folio *swapcache; spinlock_t *ptl; - pte_t *pte, new_pte, old_pte; + hw_pte_t *pte; + pte_t new_pte, old_pte; bool hwpoisoned = false; int ret = 1; @@ -2611,7 +2612,7 @@ static int unuse_pte_range(struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr, unsigned long end, unsigned int type) { - pte_t *pte = NULL; + hw_pte_t *pte = NULL; do { struct folio *folio; diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 79cc7b546f130..8281796638c0a 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -334,13 +334,13 @@ static int mfill_atomic_install_pte(pmd_t *dst_pmd, { int ret; struct mm_struct *dst_mm = dst_vma->vm_mm; - pte_t _dst_pte, *dst_pte; + hw_pte_t *dst_pte; bool writable = dst_vma->vm_flags & VM_WRITE; bool vm_shared = dst_vma->vm_flags & VM_SHARED; spinlock_t *ptl; struct folio *folio = page_folio(page); bool page_in_cache = folio_mapping(folio); - pte_t dst_ptep; + pte_t _dst_pte, dst_ptep; _dst_pte = mk_pte(page, dst_vma->vm_page_prot); _dst_pte = pte_mkdirty(_dst_pte); @@ -629,7 +629,8 @@ static int mfill_atomic_pte_zeropage(struct mfill_state *state) struct vm_area_struct *dst_vma = state->vma; unsigned long dst_addr = state->dst_addr; pmd_t *dst_pmd = state->pmd; - pte_t _dst_pte, *dst_pte; + hw_pte_t *dst_pte; + pte_t _dst_pte; spinlock_t *ptl; int ret; @@ -710,7 +711,8 @@ static int mfill_atomic_pte_poison(struct mfill_state *state) struct mm_struct *dst_mm = dst_vma->vm_mm; unsigned long dst_addr = state->dst_addr; pmd_t *dst_pmd = state->pmd; - pte_t _dst_pte, *dst_pte; + hw_pte_t *dst_pte; + pte_t _dst_pte; spinlock_t *ptl; int ret; @@ -757,7 +759,7 @@ static __always_inline ssize_t mfill_atomic_hugetlb( { struct mm_struct *dst_mm = dst_vma->vm_mm; ssize_t err; - pte_t *dst_pte; + hw_pte_t *dst_pte; unsigned long src_addr, dst_addr; long copied; struct folio *folio; @@ -1234,7 +1236,7 @@ void double_pt_unlock(spinlock_t *ptl1, __release(ptl2); } -static inline bool is_pte_pages_stable(pte_t *dst_pte, pte_t *src_pte, +static inline bool is_pte_pages_stable(hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval) { @@ -1252,7 +1254,8 @@ static inline bool is_pte_pages_stable(pte_t *dst_pte, pte_t *src_pte, */ static struct folio *check_ptes_for_batched_move(struct vm_area_struct *src_vma, unsigned long src_addr, - pte_t *src_pte, pte_t *dst_pte) + hw_pte_t *src_pte, + hw_pte_t *dst_pte) { pte_t orig_dst_pte, orig_src_pte; struct folio *folio; @@ -1283,7 +1286,7 @@ static long move_present_ptes(struct mm_struct *mm, struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, unsigned long dst_addr, unsigned long src_addr, - pte_t *dst_pte, pte_t *src_pte, + hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl, @@ -1370,7 +1373,7 @@ static long move_present_ptes(struct mm_struct *mm, static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, unsigned long dst_addr, unsigned long src_addr, - pte_t *dst_pte, pte_t *src_pte, + hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl, @@ -1435,7 +1438,7 @@ static int move_zeropage_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, unsigned long dst_addr, unsigned long src_addr, - pte_t *dst_pte, pte_t *src_pte, + hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl) @@ -1481,8 +1484,8 @@ static long move_pages_ptes(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd pte_t orig_src_pte, orig_dst_pte; pte_t src_folio_pte; spinlock_t *src_ptl, *dst_ptl; - pte_t *src_pte = NULL; - pte_t *dst_pte = NULL; + hw_pte_t *src_pte = NULL; + hw_pte_t *dst_pte = NULL; pmd_t dummy_pmdval; pmd_t dst_pmdval; struct folio *src_folio = NULL; @@ -2597,7 +2600,8 @@ static inline bool userfaultfd_huge_must_wait(struct userfaultfd_ctx *ctx, unsigned long reason) { struct vm_area_struct *vma = vmf->vma; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; assert_fault_locked(vmf); @@ -2670,7 +2674,7 @@ static inline bool userfaultfd_must_wait(struct userfaultfd_ctx *ctx, p4d_t *p4d; pud_t *pud; pmd_t *pmd, _pmd; - pte_t *pte; + hw_pte_t *pte; pte_t ptent; bool ret; diff --git a/mm/util.c b/mm/util.c index bf0513d1d3d08..cc253050f6892 100644 --- a/mm/util.c +++ b/mm/util.c @@ -1564,7 +1564,7 @@ EXPORT_SYMBOL(mmap_action_complete); * * Return: the number of table entries in the batch. */ -unsigned int folio_pte_batch(struct folio *folio, pte_t *ptep, pte_t pte, +unsigned int folio_pte_batch(struct folio *folio, hw_pte_t *ptep, pte_t pte, unsigned int max_nr) { return folio_pte_batch_flags(folio, NULL, ptep, &pte, max_nr, 0); diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 6ed6c160abed7..60ba46838bbeb 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -97,7 +97,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, phys_addr_t phys_addr, pgprot_t prot, unsigned int max_page_shift, pgtbl_mod_mask *mask) { - pte_t *pte; + hw_pte_t *pte; u64 pfn; struct page *page; unsigned long size = PAGE_SIZE; @@ -389,7 +389,7 @@ int ioremap_page_range(unsigned long addr, unsigned long end, static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, pgtbl_mod_mask *mask) { - pte_t *pte; + hw_pte_t *pte; pte_t ptent; unsigned long size = PAGE_SIZE; @@ -550,7 +550,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr, pgtbl_mod_mask *mask) { int err = 0; - pte_t *pte; + hw_pte_t *pte; /* * nr is a running index into the array which helps higher level @@ -827,7 +827,8 @@ struct page *vmalloc_to_page(const void *vmalloc_addr) p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; /* * XXX we might need to change this if we add VIRTUAL_BUG_ON for @@ -3615,7 +3616,7 @@ struct vmap_pfn_data { unsigned int idx; }; -static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) +static int vmap_pfn_apply(hw_pte_t *pte, unsigned long addr, void *private) { struct vmap_pfn_data *data = private; unsigned long pfn = data->pfns[data->idx]; diff --git a/mm/vmscan.c b/mm/vmscan.c index 07ba86634b840..5f0ac5f647425 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3553,7 +3553,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end, { int i; bool dirty; - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; unsigned long addr; int total = 0; @@ -3584,7 +3584,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end, for (i = pte_index(start), addr = start; addr != end; i += nr, addr += nr * PAGE_SIZE) { unsigned long pfn; struct folio *folio; - pte_t *cur_pte = pte + i; + hw_pte_t *cur_pte = pte + i; pte_t ptent = ptep_get(cur_pte); nr = 1; @@ -4271,7 +4271,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr) struct lru_gen_mm_walk *walk; struct folio *last = NULL; int young = nr; - pte_t *pte = pvmw->pte; + hw_pte_t *pte = pvmw->pte; unsigned long addr = pvmw->address; struct vm_area_struct *vma = pvmw->vma; struct folio *folio = pfn_folio(pvmw->pfn); -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:31:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:31:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406724.1639911 (Exim 4.92) (envelope-from ) id 1x24jA-0006eK-Ji; Thu, 03 Sep 2026 10:31:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406724.1639911; Thu, 03 Sep 2026 10:31:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jA-0006eC-Gs; Thu, 03 Sep 2026 10:31:28 +0000 Received: by outflank-mailman (input) for mailman id 1406724; Thu, 03 Sep 2026 10:31:27 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24j9-0006bg-4s for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:31:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24j8-0072vo-Hj for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:31:26 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c75-bab6-0a2a0a5309dd-0a2a450ccee6-44 for ; Thu, 03 Sep 2026 12:31:26 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994c7d-f479-0a2a450c0019-d98c6eacccac-1 for ; Thu, 03 Sep 2026 12:31:26 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5BA421596; Thu, 3 Sep 2026 03:31:21 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F28AE3F673; Thu, 3 Sep 2026 03:31:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431485; bh=wa6kw8wVjvVd2W8nAbhMf4/QKJIqMNke43dTRJ3tbuU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QvHhv94lVGWx7TmcPQBRk7OR/PvY0hnXRhX9xVN5Y4qN+GDaWN+Xshh7VTAkVLSnY Jdi6olRL94sQmWoyHi9kc6yp4HLF2iZAObXc9xsiPZr5FAVO73li6Y/Q2PlXwZuEJi tFBQkMsde8wyKBlpx9nCFXxKYf2kd54KRIoPFYKU= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 4/8] mm: convert PTE table entries in ptep_get() Date: Thu, 3 Sep 2026 11:29:56 +0100 Message-ID: <20260903103002.1091859-5-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788431486-02CDBA5B-197D5FCA/0/0 X-purgate-type: clean X-purgate-size: 1529 ptep_get() now accepts a pointer to hw_pte_t storage but must continue to return a software PTE value. Add __pte_from_hw for both generic hw_pte_t definitions. Read the hw_pte_t table element atomically before converting it to pte_t. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Use software PTE value terminology. Changes since RFC v1: - Define __pte_from_hw for the opted-in generic wrapper. - Apply READ_ONCE() to hw_pte_t before converting it to pte_t. --- include/linux/pgtable.h | 2 +- include/linux/pgtable_types.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index 19098e302b75a..41337da0d65aa 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -493,7 +493,7 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma, #ifndef ptep_get static inline pte_t ptep_get(hw_pte_t *ptep) { - return READ_ONCE(*ptep); + return __pte_from_hw(READ_ONCE(*ptep)); } #endif diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h index 07da05d375c2c..d6c5a7548550b 100644 --- a/include/linux/pgtable_types.h +++ b/include/linux/pgtable_types.h @@ -8,8 +8,10 @@ #ifdef CONFIG_ARCH_HAS_HW_PTE_T typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t; +#define __pte_from_hw(pte) ((pte).__pte) #else #define hw_pte_t pte_t +#define __pte_from_hw(pte) (pte) #endif #endif /* !__ASSEMBLY__ */ -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:31:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:31:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406731.1639920 (Exim 4.92) (envelope-from ) id 1x24jL-00076B-TR; Thu, 03 Sep 2026 10:31:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406731.1639920; Thu, 03 Sep 2026 10:31:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jL-000762-Pp; Thu, 03 Sep 2026 10:31:39 +0000 Received: by outflank-mailman (input) for mailman id 1406731; Thu, 03 Sep 2026 10:31:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jK-00073S-A9 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:31:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24jJ-003GIr-Mr for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:31:37 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c73-2eae-0a2a0a5409dd-0a2a4508d218-44 for ; Thu, 03 Sep 2026 12:31:37 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994c87-f659-0a2a45080019-d98c6eaccc0a-1 for ; Thu, 03 Sep 2026 12:31:35 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D6C8A1F37; Thu, 3 Sep 2026 03:31:30 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 75F4A3F673; Thu, 3 Sep 2026 03:31:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431494; bh=8uqvVZKecvI6tof0d601k1uUFNGK7TSPrxBJrkWSFMs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sXvoBVq6thF4MC66REFWIycWWSSZel6llh2rEnxk29YVxzxeqTuvKzkLPQExpL5vP VIAxdYcA409XP5txGxWv7JlB54zBOpxe/Awbpe8nex8QVvSi/N1WKiqaShe9lPoTL+ u61Zttng6oGMuIVLrzcTlmYO3afTqLY+B5XmFwf0= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 5/8] mm: convert PTE table entry to pte Date: Thu, 3 Sep 2026 11:29:57 +0100 Message-ID: <20260903103002.1091859-6-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788431496-CF55C87B-4EAAE030/0/0 X-purgate-type: clean X-purgate-size: 895 The non-MMU stub receives hw_pte_t but returns a software PTE value. It has no attached PTE that requires ptep_get(), so convert only the stored entry through __pte_from_hw(). Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Explain why the NOMMU stub does not use ptep_get(). - Use software PTE value terminology. --- include/linux/hugetlb.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 0d2101facaa50..637fc863d3687 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -1278,7 +1278,8 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, #ifdef CONFIG_MMU return ptep_get(ptep); #else - return *ptep; + /* No attached PTE that requires ptep_get(). */ + return __pte_from_hw(*ptep); #endif } -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:31:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:31:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406734.1639930 (Exim 4.92) (envelope-from ) id 1x24jT-0007VS-5Y; Thu, 03 Sep 2026 10:31:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406734.1639930; Thu, 03 Sep 2026 10:31:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jT-0007VK-15; Thu, 03 Sep 2026 10:31:47 +0000 Received: by outflank-mailman (input) for mailman id 1406734; Thu, 03 Sep 2026 10:31:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jR-0007Sc-UD for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:31:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24jR-005pZQ-At for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:31:45 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c8a-8faa-0a2a0a5109dd-0a2a4505c092-18 for ; Thu, 03 Sep 2026 12:31:45 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994c90-4cb1-0a2a45050019-d98c6eaccd44-1 for ; Thu, 03 Sep 2026 12:31:45 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 58601165C; Thu, 3 Sep 2026 03:31:40 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F0A0D3FA32; Thu, 3 Sep 2026 03:31:34 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431504; bh=O0VT6PN+p0N3DcZl+XBb/wJGiZ2FVgkE19Nq8WoZJ14=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y8F0VVCcChrrr0cBI7rnp1ARVvTx43edXevEN/zoEI2YC9Lg5GDUugXXY8YrKUaWq mS2JoUgkevK0SvLmnzRR1s/ldifBo+JMMM6Stx9f8CX/7MBduutu1Yt6rEe96u8Les jesuyKP7q9hVikqD+dnvZSKkHFrkiw4AZKWdyg3U= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 6/8] mm/kasan: use hw_pte_t for the early shadow PTE table Date: Thu, 3 Sep 2026 11:29:58 +0100 Message-ID: <20260903103002.1091859-7-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1788431505-F66B52A1-72CC4080/0/0 X-purgate-type: clean X-purgate-size: 2369 kasan_early_shadow_pte is a complete PTE table rather than a software PTE value. Declare and define its elements as hw_pte_t so the object uses the PTE table storage type. Read the first element through ptep_get(), which returns the software PTE value expected by note_page_pte(), instead of accessing hw_pte_t storage directly. This also uses the accessor selected by the architecture. No architecture selects ARCH_HAS_HW_PTE_T at this point, so the storage representation remains unchanged. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Use software PTE value terminology. Changes since RFC v1: - Update the description for the architecture opt-in model. --- include/linux/kasan.h | 2 +- mm/kasan/init.c | 2 +- mm/ptdump.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index bf233bde68c7e..ff41949c0ac08 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -51,7 +51,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t; #endif extern unsigned char kasan_early_shadow_page[PAGE_SIZE]; -extern pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS]; +extern hw_pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS]; extern pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD]; extern pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD]; extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D]; diff --git a/mm/kasan/init.c b/mm/kasan/init.c index 30c5266eaf37e..9bbc2a41d23f0 100644 --- a/mm/kasan/init.c +++ b/mm/kasan/init.c @@ -64,7 +64,7 @@ static inline bool kasan_pmd_table(pud_t pud) return false; } #endif -pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS] +hw_pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS] __bss_pgtbl; static inline bool kasan_pte_table(pmd_t pmd) diff --git a/mm/ptdump.c b/mm/ptdump.c index 376880071ca2a..8f19f20be3c44 100644 --- a/mm/ptdump.c +++ b/mm/ptdump.c @@ -19,7 +19,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk, { struct ptdump_state *st = walk->private; - st->note_page_pte(st, addr, kasan_early_shadow_pte[0]); + st->note_page_pte(st, addr, ptep_get(kasan_early_shadow_pte)); walk->action = ACTION_CONTINUE; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:31:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:31:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406747.1639939 (Exim 4.92) (envelope-from ) id 1x24jd-0007y3-DQ; Thu, 03 Sep 2026 10:31:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406747.1639939; Thu, 03 Sep 2026 10:31:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jd-0007xw-8d; Thu, 03 Sep 2026 10:31:57 +0000 Received: by outflank-mailman (input) for mailman id 1406747; Thu, 03 Sep 2026 10:31:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jb-0007wB-Bq for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:31:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24ja-000Zu4-P6 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:31:54 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c9a-bab6-0a2a0a5309dd-0a2a4506e1e0-0 for ; Thu, 03 Sep 2026 12:31:54 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994c99-195a-0a2a45060019-d98c6eac9654-1 for ; Thu, 03 Sep 2026 12:31:54 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CD4A21EDB; Thu, 3 Sep 2026 03:31:49 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 72E5A3F673; Thu, 3 Sep 2026 03:31:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431513; bh=w5U+egOeicWr0JE6SxpCSEkSHT/w8+Jal3XqpPBc6p0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fCi9FIbOxN1jAWaeu8417km2w3h5m6j38WVFLaXWNwK9oAUqbXpEZ0Y0M46SfnfHU is2CQLtW+RScu0xIwHD95QlemNucqa3eQLNLFkarQYw2QAH7o1yuYnaYCycw3vrZRL 6/l1lRwWzVc9APR0jQ4tBwoWuIBVD/rN/qIPAsKg= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 7/8] drm/i915: use hw_pte_t for PTE range callbacks Date: Thu, 3 Sep 2026 11:29:59 +0100 Message-ID: <20260903103002.1091859-8-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1788431514-FC40377B-9AC612D6/0/0 X-purgate-type: clean X-purgate-size: 2445 apply_to_page_range() now passes PTE table storage to its callback as hw_pte_t *. Update the i915 remap and selftest callbacks to match the new type. Continue to use ptep_get() for software PTE values and set_pte_at() for updates. The type remains an alias of pte_t on x86 until that architecture opts in. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Use software PTE value terminology. Changes since RFC v1: - Clarify the effect on architectures that have not opted in. --- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 4 ++-- drivers/gpu/drm/i915/i915_mm.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c index d01acfb7d93d0..056faf4a3618b 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c @@ -1690,7 +1690,7 @@ static int igt_mmap_gpu(void *arg) return 0; } -static int check_present_pte(pte_t *pte, unsigned long addr, void *data) +static int check_present_pte(hw_pte_t *pte, unsigned long addr, void *data) { pte_t ptent = ptep_get(pte); @@ -1703,7 +1703,7 @@ static int check_present_pte(pte_t *pte, unsigned long addr, void *data) return 0; } -static int check_absent_pte(pte_t *pte, unsigned long addr, void *data) +static int check_absent_pte(hw_pte_t *pte, unsigned long addr, void *data) { pte_t ptent = ptep_get(pte); diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c index fd89e7c7d8d6f..aab88e8edf946 100644 --- a/drivers/gpu/drm/i915/i915_mm.c +++ b/drivers/gpu/drm/i915/i915_mm.c @@ -48,7 +48,7 @@ static inline unsigned long sgt_pfn(const struct remap_pfn *r) return r->sgt.pfn + (r->sgt.curr >> PAGE_SHIFT); } -static int remap_sg(pte_t *pte, unsigned long addr, void *data) +static int remap_sg(hw_pte_t *pte, unsigned long addr, void *data) { struct remap_pfn *r = data; @@ -70,7 +70,7 @@ static int remap_sg(pte_t *pte, unsigned long addr, void *data) #define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP) #if IS_ENABLED(CONFIG_X86) -static int remap_pfn(pte_t *pte, unsigned long addr, void *data) +static int remap_pfn(hw_pte_t *pte, unsigned long addr, void *data) { struct remap_pfn *r = data; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:32:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:32:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406752.1639948 (Exim 4.92) (envelope-from ) id 1x24jm-0008Sl-Li; Thu, 03 Sep 2026 10:32:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406752.1639948; Thu, 03 Sep 2026 10:32:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jm-0008Sa-Gs; Thu, 03 Sep 2026 10:32:06 +0000 Received: by outflank-mailman (input) for mailman id 1406752; Thu, 03 Sep 2026 10:32:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24jl-0008QY-3v for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:32:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24jk-003GSp-GB for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:32:04 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994c9a-2eae-0a2a0a5409dd-0a2a4504d3ec-10 for ; Thu, 03 Sep 2026 12:32:04 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a994ca3-b57f-0a2a45040019-d98c6eaca2a4-1 for ; Thu, 03 Sep 2026 12:32:04 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5621D165C; Thu, 3 Sep 2026 03:31:59 -0700 (PDT) Received: from e142334-100.cambridge.arm.com (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id E7E333F673; Thu, 3 Sep 2026 03:31:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788431523; bh=jnhKOvqXNxavrVkvy1TrIz2ZFbREXQCKHvvjfSTHsrk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TqdJTvjSMBL/Fecpzq69xnSc8TtbMviOhHJH0tSUQhuwn0beTUse/c0M5IvEcZQBk ZWuuBe3peOseXoJxaSyHvNwu+SsvzmYsY5yXAGPVWpK8KMU1ZQ4B3t4mAKW1iUi0QH u2Yb1Uhkv1kKR+XFEs06dtpTzXB1MMV4rnuygP5E= From: Muhammad Usama Anjum To: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: Muhammad Usama Anjum , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: [PATCH v2 8/8] xen: use hw_pte_t for PTE range callbacks Date: Thu, 3 Sep 2026 11:30:00 +0100 Message-ID: <20260903103002.1091859-9-usama.anjum@arm.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788431524-C36C2B50-6F9FEE36/0/0 X-purgate-type: clean X-purgate-size: 3394 Generic PTE range and remapping helpers now pass pointers to PTE table storage as hw_pte_t *. Update the Xen callbacks to match those interfaces. Keep software PTE values as pte_t and continue to access them through the existing PTE helpers. This is required when Xen is built for an architecture that selects the distinct hw_pte_t wrapper. Reviewed-by: Juergen Gross Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Use software PTE value terminology. Changes since RFC v1: - Clarify why the callback conversion is required after architecture opt-in. --- drivers/xen/gntdev.c | 2 +- drivers/xen/privcmd.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 2 +- drivers/xen/xlate_mmu.c | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 1dcc4675580ed..b013bcad99b5b 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -301,7 +301,7 @@ void gntdev_put_map(struct gntdev_priv *priv, struct gntdev_grant_map *map) /* ------------------------------------------------------------------ */ -static int find_grant_ptes(pte_t *pte, unsigned long addr, void *data) +static int find_grant_ptes(hw_pte_t *pte, unsigned long addr, void *data) { struct gntdev_grant_map *map = data; unsigned int pgnr = (addr - map->pages_vm_start) >> PAGE_SHIFT; diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 7cfc28f1bb86f..e724cc053e264 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -1658,7 +1658,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma) * on a per pfn/pte basis. Mapping calls that fail with ENOENT * can be then retried until success. */ -static int is_mapped_fn(pte_t *pte, unsigned long addr, void *data) +static int is_mapped_fn(hw_pte_t *pte, unsigned long addr, void *data) { return pte_none(ptep_get(pte)) ? 0 : -EBUSY; } diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index 27682cb5e58ab..387f97a555594 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -749,7 +749,7 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree); #ifdef CONFIG_XEN_PV -static int map_ring_apply(pte_t *pte, unsigned long addr, void *data) +static int map_ring_apply(hw_pte_t *pte, unsigned long addr, void *data) { struct map_ring_valloc *info = data; diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c index 8efd7b55223fb..d7244f9f9a545 100644 --- a/drivers/xen/xlate_mmu.c +++ b/drivers/xen/xlate_mmu.c @@ -93,7 +93,7 @@ static void setup_hparams(unsigned long gfn, void *data) info->fgfn++; } -static int remap_pte_fn(pte_t *ptep, unsigned long addr, void *data) +static int remap_pte_fn(hw_pte_t *ptep, unsigned long addr, void *data) { struct remap_data *info = data; struct page *page = info->pages[info->index++]; @@ -269,7 +269,7 @@ struct remap_pfn { unsigned long i; }; -static int remap_pfn_fn(pte_t *ptep, unsigned long addr, void *data) +static int remap_pfn_fn(hw_pte_t *ptep, unsigned long addr, void *data) { struct remap_pfn *r = data; struct page *page = r->pages[r->i]; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:44:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:44:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406792.1639968 (Exim 4.92) (envelope-from ) id 1x24vj-00038e-W7; Thu, 03 Sep 2026 10:44:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406792.1639968; Thu, 03 Sep 2026 10:44:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24vj-00038Q-Sf; Thu, 03 Sep 2026 10:44:27 +0000 Received: by outflank-mailman (input) for mailman id 1406792; Thu, 03 Sep 2026 10:44:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x24vi-00036x-R8 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:44:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x24vi-003JKH-7s for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:44:26 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a994f89-8faa-0a2a0a5109dd-0a2a4509db92-2 for ; Thu, 03 Sep 2026 12:44:26 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a994f89-be1a-0a2a45090019-d1558029e14d-3 for ; Thu, 03 Sep 2026 12:44:26 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49cd9add88aso13986755e9.3 for ; Thu, 03 Sep 2026 03:44:26 -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-49cee5d1fa6sm66226815e9.1.2026.09.03.03.44.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 03:44:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788432265; x=1789037065; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=jIzas/uL2P8BgJezkOhhFdgxAtmFD3oqSyOce2VVsK0=; b=O8v4grZb+Dc0ZbN8rfdXFf6eMX5BKMESs3kOqJWeJ2WXY0dQrOKZqd1HTLo7Zk4hnN lqzAktIvAjXVUczf9SM9Bqra0E9NEnGyYHIlV7i4EgDk0F2GA8DVk87zT34KlVhvi1ud e+FfqXI5KmNXQbPbZeBiR/4n6zUsbhDzc8gIXMKBBEetidgkqzfkhanwZifMk/jKJiPz OvKVDUXfmYHS1vN5A7yOpyq5XocNOQVvjUD6V9f5yXYXkWI5rDsuWGLp6QjTe/x+W0Mz IYFDi4G7qjzfHwqcWY7PPCM79IlZfOSzo4PyzdOTyHzvOs2yN+3rpV9IEY24EXBZuV6O Xy0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788432265; x=1789037065; h=content-transfer-encoding:content-type: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:content-type; bh=jIzas/uL2P8BgJezkOhhFdgxAtmFD3oqSyOce2VVsK0=; b=YYj4u2A0CmMgzjRo5uMYuXlMh6AeblvuuQazBlr/neOdrwAm6nwaz7Pyr+cmHa+U7c UDlRoqrLGrqesZIXTWz/FauSoIKbRSyhUnPQfNS4E8NAyJELKbOyM44hNUsnQUJMQtvD pf/RqzP9MWE5OhK0DFovckFnqIK7DcHnRx+fo+M3/pBYVL9OK/rt5Gk7E8DIZ0SgL02O JRsEPxi3VGKqK3sKe5vkVizSFa7CM7bBnqiKJJmOln/DdyLXRxHc2bYdxvhvWzEflSt4 IOBwkTuizKXf4urrsji/RM1/FcQrWjFSsrge23ScqwgibhxF8k7r2sT9imdR0SHeBC9N t1+w== X-Forwarded-Encrypted: i=1; AKwUvBwAtG1auDLNA6rrpmDkrZze5I5d+a7KuYjaosIjmUUVp429oyXJ0hBVQVaBjP6W5usqpYqF7v7uQ6w=@lists.xenproject.org X-Gm-Message-State: AFuF++lBYlahYppJ4XkGTqS9+b9v12QK4DEa7x953jwyOsToK/KNsAuR BlthKjhaYcoEgYl9Sd8UD9uFRpBwUMfAU6fDUJFXfb4zC/mGsUMeSMtfqHuUIG89bg== X-Gm-Gg: AYBFou2dFrloeYwBEwS4PjS9VZkZVzfBYtFdyXJmfssiv9Oi4bl+LPKOUnUzJ9DoHay vAIMdtuLO8rDN+3JSl4yafCd7tK4P2ZiVIWHaW7siTTmQW57yYrasL//9o1E2Jlpuni8nbpo0F4 G0fJ7TKh9bo5ImU11j5NWA0sv1rZK/aImPmIEC2uAlpYAbonwJ7Mo3V0Ctugw7rKj3QbmcWF4Z0 oiS3fIOqQV0t6qkiqUicMZR8bUuhje4O6uVhHf5DN+0mX4ktptnvqYpjkASi/4VTf0gFGgBkZYb srYuzzhGB5wFXaqpA3Bn/LuUJ0BbaIExMZBJw/NhfBTTLgfbAoEiOw8fichSFzfHuYo2dpurUoi Dt/KooVNIBa0phhQTr4YyIVynN+JmdT0M/pmLRVc9bKUYIHgXih+A5vp+oZqI/nurZveMvS44Xp Pa5uUVy4hlg2TT92OregKa/QyKcZiy+OCM6iRh5Evk7fDv2xVgN/pwGIO6JZRTY/6NN/aWe8Lyf MYrXkCkT8Tj6FcYy3EYG9XmXSKbv4ugN/4istQbzwhHuiXjQSXY X-Received: by 2002:a05:600c:8b10:b0:49b:12c2:104f with SMTP id 5b1f17b1804b1-49ce55ecddamr238217505e9.1.1788432265579; Thu, 03 Sep 2026 03:44:25 -0700 (PDT) Message-ID: <39ccc2f5-7b3e-4c5f-a98c-b526f12bb1c7@suse.com> Date: Thu, 3 Sep 2026 12:44:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] x86/viridian: Workaround Hyper-V GP fault writing to MSR To: Ross Lagerwall Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828131142.3986110-1-ross.lagerwall@citrix.com> <20260828131142.3986110-2-ross.lagerwall@citrix.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: <20260828131142.3986110-2-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788432266-3A0C5034-C6AC0A4E/0/0 X-purgate-type: clean X-purgate-size: 679 On 28.08.2026 15:11, Ross Lagerwall wrote: > The Viridian spec requires the vector to be >= 0x10 when writing to the > SINTx MSR, otherwise it should #GP fault. > The spec-defined initial value is 0x0000000000010000, i.e. the vector is > 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to > the spec-defined initial value and since the vector is 0, it GP faults. > To workaround this, treat the write as a no-op if the value is > unchanged. > > Signed-off-by: Ross Lagerwall Acked-by: Jan Beulich I expect that despite the (valid) absence of a Fixes: tag this will want backporting. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:49:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:49:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406805.1639986 (Exim 4.92) (envelope-from ) id 1x250S-0004GK-IJ; Thu, 03 Sep 2026 10:49:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406805.1639986; Thu, 03 Sep 2026 10:49:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x250S-0004GD-Ew; Thu, 03 Sep 2026 10:49:20 +0000 Received: by outflank-mailman (input) for mailman id 1406805; Thu, 03 Sep 2026 10:49:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x250R-0004Et-5K for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:49:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x250Q-003LH4-IP for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:49:18 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9950a4-bab6-0a2a0a5309dd-0a2a4504bf34-38 for ; Thu, 03 Sep 2026 12:49:18 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9950ae-b57f-0a2a45040019-d155dd29d904-3 for ; Thu, 03 Sep 2026 12:49:18 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-485850cf499so91938f8f.3 for ; Thu, 03 Sep 2026 03:49:18 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448ed37c4sm11241379f8f.21.2026.09.03.03.49.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 03:49:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788432558; x=1789037358; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=NMtNZcdWrUtlpyEBaadTCPw6C9NxehkQhCnEcPOOYOM=; b=ooXKSAFFQ9IcLmxJur+zGEGiH/YZm9dC6CK9uF35OiKQUvAZ3t1b1tRD8cbZA2O1ZI JCRHkW/c5OsDkPoO8rEGod4WMhcDLztkB+WgITsU8xgyWUs/PK4ce3n08VO1FlDWFPoK tAQxvUgu5qcZNWObvnX4zkSdp4ewj35YbxM9tbXEeIiELuokWDRH7YSRl2mVZImsVhjD K0rU5PLLZCfuv3x6Itmwk1jEKgiHKcrTp/NI/VJGWacgSbaKAzwqKJV1pBgWQKgiEvKV wudcGWr1RrTkYOibUzX5DSCiC8DHg5ef2PafHxiOcaR8skkrRiM/ohwKyIwy09R71bsS uCag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788432558; x=1789037358; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=NMtNZcdWrUtlpyEBaadTCPw6C9NxehkQhCnEcPOOYOM=; b=ZZwzICZkwzqOkFLygbi01pjVyq5imZ+ZlPiS1MddREq26PuWXaJeLTsJsKbnD19DbA T4sI2b646GnaKZ1ohbIb68Sr4bV+ryK/WL6PkIhErTtOXVAppddJV5DdKqcDq2jZJ3SA QcfTohhalyZuEt7i/pmCJUeqFsf90JzDw1UJtsCVOnIeVoCSJ6BzdgVwwRMHMYWeAo98 zSoomyADu2z97oDsSqWMINClOAnjLloc4ZtCCKA7Xjh/q4ih0+EN81jXrJJdmHNX7QHM P7GS1O3IuCCrA8wqEuibw6EypU1gCEEp3Awsccu57N0b+2iuXicmnzD02Ey17FZ6+kPk 754A== X-Forwarded-Encrypted: i=1; AKwUvBzvnF/mfUqqc2grJIRHBsYE0Wwa9x+qlAPCkZscbaOi5Wys69l4GZ/G+LI6RVinnS4w/yO5tf1ovM0=@lists.xenproject.org X-Gm-Message-State: AFuF++mTuDyfI5k5+Vyv/+rBtZvxy4Zj6+kbj33sey5NFpDP/txX2Nyo ouQX/NEmUp3pLH5VFyqDu/xOmup+HasfDorITJT7VXcosVMt0bLgsbtN X-Gm-Gg: AYBFou1F0UPDvnEc9aluC30/74Zx7RulCWNSb8jt4WkJuzdGLkD7hZWjS5eD2B2BtIF jbZW7/Zc1VqGJOU2DtkureM8fK9GaBrLDHftIR8678sgWA0/GQDG4JOKF3iG/DQojRj2NiGPEjP r4P4Fpq8QW5j5oyqCDeyQSDocgEP0hrYV96lxTxo9FIMCR9s2ZYhh/NHCkIxy+O7LHlLyiML+xH aeSrew9Hed4AoEuy7T8jOP8qwesyqG24O15UA/RsRZH4Znfn5QErNaOj47IbjJQk8NyLeJalNHX kYan8Kypq57WtXkjcaUdZDzbqKHJ/ImvytZX4PNEOQLQCm3qGueW5gTzFUrgIx6V+V7sfvqVNhu kVoKSoJvvNbvpumu6YyEmOHKXKEdnLFSt0MDwpauwUcrm1lUFTzStiOvppiMH8TdltFgKpfBBFP rAtSpoo5W/DHaNqPpHjFRsHsolZcRShnTQYxtoFQVBoAvgHb8KNXWEJOXihvGUIVL/XS6PLvq0h g00yIicJ4BfhG8nCV44ToqErIZyz/dsGB4Yfj/BHQ== X-Received: by 2002:a05:6000:491d:b0:47f:80d1:be0a with SMTP id ffacd0b85a97d-484913b985fmr21602074f8f.14.1788432557828; Thu, 03 Sep 2026 03:49:17 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 12:49:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 13/20] xen/riscv: introduce (de)initialization helpers for vINTC To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <688352e340872a50af99a51082966669787b1f72.1787836900.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788432558-C20D5B50-49C6BB7F/10/73395122804 X-purgate-type: spam X-purgate-size: 1493 On 9/3/26 11:20 AM, Jan Beulich wrote: > On 27.08.2026 17:19, Oleksii Kurochko wrote: >> Add common helpers domain_vintc_init() and domain_vintc_deinit() to >> allocate and deallocate a virtual interrupt controller (vINTC) >> structure and initialize basic virtual interrupt controller registers. >> >> domain_vintc_deinit() isn't called at the moment as arch_domain_destroy() >> is implemented as stub at the moment. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v8: >> - Add call of domain_vintc_deinit() to arch_domain_destroy(). > > Why only there? With ... > >> @@ -308,6 +310,9 @@ int arch_domain_create(struct domain *d, >> if ( (rc = p2m_init(d, config)) != 0) >> goto fail; >> >> + if ( (rc = domain_vintc_init(d)) ) >> + goto fail; >> + >> return rc; > > ... anything added between the newly added code and the return, ... > >> fail: > > ... you will also need to call it here. Since it is (supposed to remain) > idempotent, I think you'd better add that call right away (as long as > domain_create() calls arch_domain_destroy() only when > arch_domain_create() succeeded). arch_domain_destroy() (where domain_vintc_deinit() is called) is invoked from arch_domain_create() if arch_domain_create() fails. So, the mentioned case is already covered. Am I missing something? > Then: > Acked-by: Jan Beulich Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:51:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:51:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406812.1639995 (Exim 4.92) (envelope-from ) id 1x2526-0005r1-TN; Thu, 03 Sep 2026 10:51:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406812.1639995; Thu, 03 Sep 2026 10:51:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2526-0005qt-OW; Thu, 03 Sep 2026 10:51:02 +0000 Received: by outflank-mailman (input) for mailman id 1406812; Thu, 03 Sep 2026 10:51:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2524-0005qj-Nq for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:51:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2524-000cui-4g for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:51:00 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99510b-bab6-0a2a0a5309dd-0a2a450a8dd6-18 for ; Thu, 03 Sep 2026 12:51:00 +0200 Received: from [52.101.48.18] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995112-f2d2-0a2a450a0019-346530123c57-3 for ; Thu, 03 Sep 2026 12:50:59 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 10:50:54 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 3 Sep 2026 10:50:54 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=x3StNk+sUR1XlNPO9JsktuKZtbDy2CRzSVBnGVIxtk9WBTu9b4F+fFutRwzoyogO6RR1QeRUF0TFCTDMk+KCIXXLYH+5WJVkV5dOeX5w9K6ZS9s1ILQLk0mNJ1h/xi0mEz80YLKPEn49vlEU9k1X648vkdx8MH9PNgam2RXYUQSLbHIletVuUqfdjMI2tNMpXQp49rpKy2JTQ94eXB3ck6GsPT5mQpSX8Qsia5b+dzMpokb6aendccTJDFS7wjNIJxYHCL+ncYzpEI5TvXyla7bHE0/A148UzM7iMzVD5OGme2qfZh/vsYgN7+qwSuDXp5/akrj7h4RylbXKnYcUnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kch8qOkHEkPc/Ww5+vdCouBnQFTkyN0e4Zof0B5mfYE=; b=vbC7yJqCx1k2qwNiv7wnWT+mvMmVBRmBwcFN1RmLBxBnO8bXa0Sl2Wrlw7f1JUIWrdQoLFQUqYJot2I8U0CqT/AnuEtUrSyK7dCZlzikIYPiXyZUy0D9CZiWOOYZM2GnhzPnf+rU6TPBpAHMlOqJHfst0x7lSIA5DDHwEeCOZNnHJm+bxUQe/H4pxG73MXlr3XSvq4NLzT9J1XqX5mKQa3veUzfBEPFVNXI5EZ67guzrSKbBgOyXc45NPwIBsVftChF9n6AWC+z4zNLIFRPqpjKRDLtTNqYkj4dZbadziUTjEK+WakJ9gttKY9M/otSEkmAShgKlM/h/bxuNYlIW1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kch8qOkHEkPc/Ww5+vdCouBnQFTkyN0e4Zof0B5mfYE=; b=KSz9+WwaeaEe8I27ELpIP6n12diuiAh0rUnLfhucuxBrUEXdOC+cFU7THog7AeQkAPrHRZxltk2ekIXiqtB9Q1ES1UgGdiUAsByNIbOKjwcxxdQcoAzh2t91ftcGymWvnGQ3r2Aswa1bafVf4J8S+YlBhjDoRDUZhXHydy9+ZFo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 3 Sep 2026 11:50:50 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Paul Durrant , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH v1 1/2] x86/viridian: Workaround Hyper-V GP fault writing to MSR To: Ross Lagerwall , xen-devel@lists.xenproject.org References: <20260828131142.3986110-1-ross.lagerwall@citrix.com> <20260828131142.3986110-2-ross.lagerwall@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260828131142.3986110-2-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0040.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ac::9) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH8PR03MB8274:EE_ X-MS-Office365-Filtering-Correlation-Id: b8a40422-3b8b-40c8-94fc-08df09a93a15 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|10067099003|18002099003|22082099003|56012099006|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: YRcJHF+ZoX75Be/lEKn7IQjxxZ9aAqML7VOeJ1LkOm1EKbcq3Lj69ZO3VAr3S1dtejOdJ7LEwhe4zMmfuJTEvMi8YDcWDiC5fEQM79WNBpRdzRBALM4CtoVM1pud8wXcHaToi7KpdfPJrQkxufMNUS4rDDNfBMSQ6VDCXKib1k8hK8TNcpK3I3CBdO0F+n+QCj8Et09mIUZWWcZvG06o5hTbz2ewdMYWDgrgZwLZvKWsyRNSs5PedBlY7KkoIWbwA17PKkoCowt7UroL03twg9X7zrRacnSUKtY4rNdHy/uvKNAmTEbvCckShd4mzmjHjeOUxsGFqs9MbZ9l2OVpoU6LsPWYMpoIUKdqRp4YURAMp2JAWAeuCEcK7idrnx0Zh8P6KzY12OzN/GC2KM+V+YQVJhhvHHXwTNrkTwWk4H44e8qS8ckKSJo72crz1pdGta+V/r5pzCLxCSr/W5yfTMh1tZkM0pDWFa8P+r1/xtwcoO6GXLH2+Tb6/bunl63NhulyKE1M6R3Mgf2GzciE4IdKWFxMrdTs8ssXKovsKmSHPubJWgeGi7Mbi4C9rswx5eYgBn28g+4gQggqoTjftzeQn2cLicWMRzMc33r5WdcTUgWGYRZGxh28C9SG4gspAQ0SPhzD76TUaS/OSqGYxQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(10067099003)(18002099003)(22082099003)(56012099006)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Tlk2NTRZRXFpUGFSVjVqWU5kV3BidGlWQUZLS1dzYmlZeVF3elRJd1NVbzlv?= =?utf-8?B?UmgzdlpQM3dtck9QNzVQRFUvdmhkdGdUWG5MalBnOGRCUCs4Z2Z1TVdlaTY4?= =?utf-8?B?SkFNQUg2RUpDNCsrcEpQc05FSUFFeWo1S2V6dHlWZEhsbk03UXM4aXFNbXpn?= =?utf-8?B?cFFCOFBsU2VQcWFBUk0rY2hXZXgxZUdVWWlVN21ZaVFEaU5DQ21BU25Ka0F0?= =?utf-8?B?ZGFuNHVFcm5VV3ZGTWRxS3FwVmJMVmN4UWZLYmk5SzRwcmZBUUpyVklCcDg3?= =?utf-8?B?VnA2Ym5yM2dtbzNiUE9nM2NWdWQzZDNiRkVsdStCM2tHdDVKeGUyZjRlN054?= =?utf-8?B?TWVuZmhwK3F2S0dxaTZEWDNqUElRTWVwVVNPdjBQUUtFTkFzMjFXUUw3Z2Vs?= =?utf-8?B?QlJabEVIVjZwbE43OVFVMlExS0ZZUk9Ja2tlQjEvR2pqaDl1WCtwMFVEUjA0?= =?utf-8?B?cVF2c2ZvQ1ZyaFRUQVBVTnZ2c2NmcVEwSUtnQ1JLYlFySkY4b0ZjWUZ5Wnhy?= =?utf-8?B?VnhHZXFMQ2l3SmJEdkg0Mml0Y2ZNUTA0WXR3eGZrUFA1VzRJYVljSnRlSFM2?= =?utf-8?B?MWg3T1lxS1BWemVzVXhZeWowdVcwYjJDYzBmRG9rYndIY2wxTVZVOG5iVkhK?= =?utf-8?B?bEFWbTBYd01YcTEyeUd2WlVKeVZiWTU5dTJybDd1M08xejZqdXIweDAxeFRa?= =?utf-8?B?Wk92TDBuNFlZQmlMaTlhNnF3aWgxbHVNcWRqbHBFaGRpUW5KSG5tWFZEYUFJ?= =?utf-8?B?SDZhdFZCQ3ZNL1FWM1lkK0VFMVIrUzlmSThQRWtUblNEZEZ0MmdrL2kzbU1F?= =?utf-8?B?Rmx6R0JJRGRiME5nK0E0dHBZUjlnTlhNZVRWUnNXL3UrU3A5WTFwYzFGMUpj?= =?utf-8?B?cFRsSE1Wak4rcDlKVTIwdUtrWkxBUFVwbXBlZUdtTWJaSXErYVpqbUlxeDh2?= =?utf-8?B?b3pyS2hrSGhwd0VCQWo4SGR5Ly9MTGc4d1FSTFlRUEZLVTYwaXI2bTJHd2w0?= =?utf-8?B?WWF1U1FHQ3dxUTV3cjAxVEtoNElLQmxFaDFqdHJXTW5COU52d1ZUOTlXUmhK?= =?utf-8?B?d01ORzRLbVFSOHJ6YXdGaHlhZ1hLd3ExN09oZVNuekhsS3l6a0tQOVJNRGRr?= =?utf-8?B?OFhNeEhiK1A1MmkrRTA4bnp6SVY0RXhwbHI5UWxDZ1lUeHozQVRQcmNPTGJi?= =?utf-8?B?Q1NwZSt2MmF0T3B5bk9VelFIc1B1b3BiTE44NlAvMGZTR0gvdDVla0pMbUIw?= =?utf-8?B?WkdtSkhQQ0p6aE80SEk4dEljVEhqV0hxQzVXcTdNM0dYZ2JTK0xFWGpZbDV0?= =?utf-8?B?QllZSUIzNHdqanB3MFh3ZVcrMHVRMHhLMHpNUGxSZDY5R0pNRk92WHlmd2xE?= =?utf-8?B?M1lZaldQL21Lb0tOd0dmNGYySytPbEZzR0h3S09CT0R0WEl1ZkUwdkdMZWJY?= =?utf-8?B?NG85Yk9EK3c5dUV5dGhRbG40U0VycWtwZzA4OTJQSzJzUnF1UlI4T2hGcjVQ?= =?utf-8?B?WW9QRWsvN3ZFd0x4TE51VGdFSzZnMkQ0N3lHVlh6MWp4c2NtOGdTbEZubllM?= =?utf-8?B?VVZ6R0RDS0hubE52cHJkZXBOcnoxVlN3S1pxVFJ6U0NuSHJUVmRIOWJVOTdq?= =?utf-8?B?N3NRL1Q5ZVJBRVhPSjlDbmFXNVVScTNZYXErQnd2ak4yN3FNeHY0Q3J1UFZj?= =?utf-8?B?YWhMR0JYQThHbldQSEVqNzNHTm42Y2R3cTdvcVZJdkZvQmVCa1o0NmpGcDdH?= =?utf-8?B?WjRWS1RXV1lRMmNNd3JDdSs4enBKQkVsMTFoUTdvQzBYS1dLV0VxNVhlNWZJ?= =?utf-8?B?d2pDSVdSR2l3czFKMTFkVVN2bnlmbHFGbzNjT2VZODRTOHBQV0ZCdVh0YVBn?= =?utf-8?B?TnpnaTNXRW5zSnMxVXJ4Vm9LdlJQZ05nbll5dm9LbXZXTmRrS2NxbWFiT3gx?= =?utf-8?B?TkRqcmZZZ0xMbk9meTVHNGNLaEt4ckVKS3RTZUJzaHBoMHU3R2hjbVFHTjhN?= =?utf-8?B?ZWVTdFJLQ1VmYzRieUF6RXVCd00wclpHbDJGMG55SXlocWt5UzV2WmNYalh1?= =?utf-8?B?QndnNmhMdDFORm12V0gvbHI5cnpLVTNWamhTRkZQRVRMdzFZY1RINHBMYlE5?= =?utf-8?B?VFFtbDZBZE0xYU9ORFNja0dFaVBsQXA0cWNLazloWFM3NmE4SEMva0hVRjJl?= =?utf-8?B?dWhEVlJyanVQdFlHSkpXaW5aSUgrK2NFdEI0LzV4SUQ3eXhxUUI1Z0xnbHpC?= =?utf-8?B?ek8zMk53ZFdra3ZUa2pQY2hMN0VJdjY3d1VzYUdkM2sxWXorNDNZYWhaZ1dK?= =?utf-8?B?YnVkaGZRNTkzUGswZzhELys5UVBmM3F3Ujgyb0dFNjhIN3VXOTRLZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8a40422-3b8b-40c8-94fc-08df09a93a15 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 10:50:54.0026 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: X5E2Qp6B6Z7IKtc/u1pxW45FUqsREpfbeu7CcKUg8Z82NxeC9QJ+sWmRNViweer+JSx/S1xCIQNeaXwVOPD+GWI+G/8gLJJC2Qg5qzcPMug= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR03MB8274 X-purgate-ID: tlsNG-4011c0/1788432660-4BED2CFC-475AEAF1/0/0 X-purgate-type: clean X-purgate-size: 1439 On 28/08/2026 2:11 pm, Ross Lagerwall wrote: > The Viridian spec requires the vector to be >= 0x10 when writing to the > SINTx MSR, otherwise it should #GP fault. > The spec-defined initial value is 0x0000000000010000, i.e. the vector is > 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to > the spec-defined initial value and since the vector is 0, it GP faults. > To workaround this, treat the write as a no-op if the value is > unchanged. > > Signed-off-by: Ross Lagerwall > --- > xen/arch/x86/hvm/viridian/synic.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/xen/arch/x86/hvm/viridian/synic.c b/xen/arch/x86/hvm/viridian/synic.c > index e6cba7548f1b..37ddff201a6b 100644 > --- a/xen/arch/x86/hvm/viridian/synic.c > +++ b/xen/arch/x86/hvm/viridian/synic.c > @@ -157,6 +157,9 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) > if ( !(viridian_feature_mask(d) & HVMPV_synic) ) > return X86EMUL_EXCEPTION; > > + if ( val == vs->as_uint64 ) > + break; This needs a code comment, or it's something which will be deleted in a few years time when someone wonders why it's present. /* Windows 11 Hyper-V (Summer 2026) has been seen to write this MSR to it's default value, despite not being a spec compliant value.  Tolerate writes which have no change in value. */ ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Sep 03 10:56:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 10:56:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406820.1640004 (Exim 4.92) (envelope-from ) id 1x256y-0006Qc-DO; Thu, 03 Sep 2026 10:56:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406820.1640004; Thu, 03 Sep 2026 10:56:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x256y-0006QV-9Y; Thu, 03 Sep 2026 10:56:04 +0000 Received: by outflank-mailman (input) for mailman id 1406820; Thu, 03 Sep 2026 10:56:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x256w-0006QP-SA for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 10:56:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x256v-0076d3-Qp for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:56:01 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99522f-2eae-0a2a0a5409dd-0a2a450ab12c-38 for ; Thu, 03 Sep 2026 12:56:01 +0200 Received: from [52.101.46.63] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99523f-f2d2-0a2a450a0019-34652e3fa112-4 for ; Thu, 03 Sep 2026 12:56:01 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by BY1PR03MB7189.namprd03.prod.outlook.com (2603:10b6:a03:523::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Thu, 3 Sep 2026 10:55:57 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 10:55:55 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DxasIE8sYbZEka0dBH3enj30RHdi2Wb+A5+nQfEnjrOTkC2x0/6mc0k4COKTMctKWkhxLTB84MBxWQtrcI4fc4K+s8b1kfPfLi2p8zRniGbXh0czgz+JKolS8w5tsdYAphcqfPQimJD46fi0sR1DFlG5FV+5Fe+K9Fz0MZ0Aw1y1HpaVe3PidLdbvU2I0xEtxWs48yKRwBsIedtixcTTkTGfmvgxByRKMembbjbDdzVD74W99alULaA6MhoCUhuNrYEJumyLtIlm2bTj/o2nnpQzVkgKa9L6GLge5wMpkpEietnJ7H0u7pSXI5MKQGye4gmbKy3GUJIgmAmGdKFf/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IgdSTHhGOXN6NHcc5q3jDwnh6tsUFiTXaHjBqXLZ37E=; b=fM37zn3dkomPNmNqYvmXSbjeFhpHXdx8ThXOgbFQNF5uH4PyO9HyuXPS5FCd4Fid07Z1f0zfpcGUvXlFLiYs3lsfxO8/jyAkDcqt50r9lUVeOeIjkmbk5Mu35b34dVwlAbB5Q6Oz8AaCWCVuPGxUwwuLBvy+fncbnlC/SKyQoDfx13rL1B4oOEllGLukBNscIoWwrmbJXpuTypO3jbJSTbcyue2ztcy9rcMBjZWF4Yb1lSDIXux8Jv+dH+MeHOIzjmp6O6EahpdZlNFN0GsFKn+BduLLSSOsIdiXrVqJMbn5dJL7rl8bEaz8pW0tZ6OGMBjnXDefjobvNYOPpCmnNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IgdSTHhGOXN6NHcc5q3jDwnh6tsUFiTXaHjBqXLZ37E=; b=GUGh/wZG9rCYBT0Vr9nJ0P3pi14jMeHRCK/j5cNm0hC2a2LuYBBifqIaQ8yoNRZjerJzSUXJ9mNEtIMi1YeEUSVZoBQRNZOIC9ayJKJ2wypDYcmkd5a71tRxViMc4bv8p8KmLZ+21G0Dh/GtUcj7H7SbbYNB5f8sDs3IMGsjWgk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <12a277aa-2d67-436a-8afa-3a68ad6f6ae1@citrix.com> Date: Thu, 3 Sep 2026 11:55:48 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] x86/viridian: Workaround Hyper-V GP fault writing to MSR To: Jan Beulich Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828131142.3986110-1-ross.lagerwall@citrix.com> <20260828131142.3986110-2-ross.lagerwall@citrix.com> <39ccc2f5-7b3e-4c5f-a98c-b526f12bb1c7@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <39ccc2f5-7b3e-4c5f-a98c-b526f12bb1c7@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0102.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bc::17) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|BY1PR03MB7189:EE_ X-MS-Office365-Filtering-Correlation-Id: a33280a5-6c05-406c-d9c7-08df09a9edab X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|10067099003|56012099006|11063799006|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: RCzLHOvKVhvVNXSpVcEx5zQ7kT1QDaM9CPwoMquWdF8wy8p63E15a5vb0i3FcIHadkDwD0JOoDa67ihkUmHx3YDlPDVFrrgOeJLf3xawy6+4O5qLCAjD8aBOS3EKvjqoItZmQ1b8TX/vfx7K9cccwTAlGqb0ggOp2AtTVgFcbt9kkcRajF9Za1UAT23k2gRJl1vr4CdNMrja41vKopHF+abB3CgovoYDh/rS8dpDVCzMPu7nQHCQozwEC+J8l8PNv1DuvP5Oil+itocP/dKGv9C8aPdml4V9n0ONVvsaEshozesPWwzJKPil/8m+G9DwQ4yDeiz8LN+GNXWj3zk0TXsiOzNBxyDAONevVU5z5aLY6SAr5TNhZ2k7pqQwMJJwbzt8SDtxCsar8X31gFuzj3M9RNgRCwYTpKGfJSEmqfnLvYMWU5mN+YZpu+ibIHEMYZoomUZs4nFQUO8MssQeRI/+mMXUpprJvGi+gSi1phkyvQxVKq7EluBq6wJJ0rLE/Km1e18QOmvfjMwRlTdSjkJN7lBYg4ni50fY04eLXID6zbO7c4On2O1i92sgzsguShIb+d8up7DiCpqyvV1hocP21S1oJueiNOsnPL4rIScxG5YQkOQxrVAqXJEQunrxISS1E5qm/QY8FfsD8OE2ZCqmFqKKnpxU8x2/lsXzTd4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(10067099003)(56012099006)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TjU1MGk5M0xzcllEdmVlQ2RyME1iR0RNV2tpYTZwOWZTT0UyYS9iejZleGg4?= =?utf-8?B?em9JK1N2azVRcEJKdGNZS0dBbW5nbmNkQTY0Wno2U3NZUW9BMDJXdG1iVGtM?= =?utf-8?B?NjRRcDY5Qm1KaXVudGRHNnQ5RFJZMS9pTXJGU2RlTGlnV0FYQkYybEVSQWtx?= =?utf-8?B?b2dsMUJsZ28rZUdzUnBRajhXUXI1WDROWWU4ZjBZUTdCNitrRDVjU2R1S2oz?= =?utf-8?B?Rk9oaVNmZ0owMVpVY3NyaGcvQjVpSWpLNlN6K1VkWHpMZFVCaHp2TjdwNGxi?= =?utf-8?B?WTEzSTNtd1lqZEFqWDJMTjVBKzFOWjlyUnBQUnZSZ2ROWXNicEhyN2hETGVB?= =?utf-8?B?cjJ2OG5iMDZ2eHFnb1VuQVpBakQ3UmhibEtXekZ0aGVzNy9kMnlhckV3dzVl?= =?utf-8?B?Tnh2VXJFWkd6Zkh0cFptaTNHYWdhOTQxNnRzNWIxZVJiVkNldmFldExxMFpm?= =?utf-8?B?Mmdqa21KMzFneFFnTGVrSmtpUWZrU2JycGRVcEZGOUdWTExPaUNlV3JZdGtE?= =?utf-8?B?V0FhbWRreUUwSFFSNUVBVENMQ3M4M2pmck1oUWhNVmJtS29aRm9LcXJ0RHNz?= =?utf-8?B?cXhJa20zYTRSWDJTdXJINzZTbmo0ZjlCeFcvcklKWDAzWFZwYnBpUjByK0kv?= =?utf-8?B?bCthd25lV0piZnJWL1h5WXZ2aUNZUEpjbE9oa0pVYXU2Qm93VTJRQVBDaEZB?= =?utf-8?B?ZDk1YWJnbFl1dkpPNEpEU0UxenNXY3VoRThnc2RZVkpoemwrNHNwNVlHNVBp?= =?utf-8?B?Rm5wVm9FZ3lGZFYxSytnVk0wRTMwVVFEREJBaE1oOGx2eGJTRkt1Rk8xSGll?= =?utf-8?B?VmcrSFlLTTI4YnFOTUFMYzVTa2RsMFRpaXVMNWRROTdaKzBhdGxDVzJSQVVK?= =?utf-8?B?Yk5pUTUvOHpWTVJ4T1VwWU5OYTlDMkpwb0JlUm5lSTVSaHF4RDVadE9yaXpI?= =?utf-8?B?MGdpQklMMG83RzR1NGx0cXJ2ZXdrVHhWYktHT1dRdVpzckJzejN0NkE0R1R1?= =?utf-8?B?RHVxMEQ4d2lPZGxQdFQ4WlFWTGx6NTFFbldZTXlUYVk0MmpQNjBVKy92SFZQ?= =?utf-8?B?OG1pd2t3Q0RtdTNPeGxHTmxpQ3VMK1oyYndobTRMcVA4eFZ2dzFNd0hqYktW?= =?utf-8?B?cXlMb241Q25VNjBLZFRRSENIbHRKVW1LdlNTSDFpMmFwYVZ6QjVzZXRTVkwv?= =?utf-8?B?UGU5ZEd5WlkyYlhjRHF1RDJpd05wQ3ZXY3l6N2w5dzVHTWhIZmhNbXFJMDZQ?= =?utf-8?B?c3RYc3NCd1Z2d0tzb1Zka1ZtWmU1RTZMVGlxbHk4WTNGSTdGTlZzaXF2VkpJ?= =?utf-8?B?NEhlRGROSEpTK3BBSmdHcnJQOWNFdmx3QUFKcHkyU29oNXlVeXQzbVhBbHU3?= =?utf-8?B?MHdTZ2ZhUEZvS1RQeEp4RkVwMVR4czQvV2ZqVVdpeE9vaEFHd1JqSmxUS2Zy?= =?utf-8?B?Ny9veFB4eDZDZ3QwTU5nM1o5Rm5WK29PdmgyYjRvOHcwRC9UVDBKNTlxR0la?= =?utf-8?B?ZTZFclNTTHh3NGdjRWZGQ3cyUG9MdGRaazVJM3grYUtCNlYwZWV4aXBYZ1ZZ?= =?utf-8?B?WEc2cXRRcG1HenNGNDl5dWJBQzE0U3NiR2RJMG5ZUUtUV3NxS0VCaWk4OHVO?= =?utf-8?B?eFNKK1FaMFgyMnkrRjJrMG5ZYmtQNFFCcjZBcUdla1JPaDlGZ0Z3b3pWSTFq?= =?utf-8?B?bVpZUFlza0JQMGFaamhuZ2F3RllKaHlkWU5PVktQRXNZWnRkTkd4SGtRd0ZR?= =?utf-8?B?Mnk0ZTFCdmphYTNpWTF2bHdjUE51Yllic2pWN1k2TVErTDFPdngvVmNmRjFa?= =?utf-8?B?VEdlbTcrWkF3SFkyblRlNU42d0R5cmpoaGtPSm1xSjBrWDRLY1cyMDJCeGRC?= =?utf-8?B?OWRCRW1SRE1VOFhMVUJlbUJMZStGaEdpVWJ0Rkl3ekhuOHp6QUV1L0Z5dHJh?= =?utf-8?B?OE5Gd25vZGlkeGdzOXpZcnBFcGhWNHcxdnhNaWpzdU1yekRFSVZXV3B5U1VZ?= =?utf-8?B?YjhYSDhiNk90VmVhSTRvOVgyY0N3UHJ6NkVJRFFuZnI2RHhuVFBxUFRLYmw2?= =?utf-8?B?V0x3RWxNek9SSlFkRVZRMHlzbWFOa2c0eW9VZWxWNDhoUm55cFZHSHQ2VnJq?= =?utf-8?B?TmQ5d0xLdmlabEZzNG9tajZ0dWxOMGdXVSsyR0dNUEI5WkVBSDhEODRzcG9L?= =?utf-8?B?OTV2UlJHT3IzSEJSL05IVEE4aHQwSjI3RlB3QkRld2wwOW1FTlQvaGlnU2Vt?= =?utf-8?B?YUJkQUJMTmNUU3ZHcHhwaVYzeXpmamFTYjc0N2pJSkp3U1BmQ3k2bTA1MUVU?= =?utf-8?B?Y0JGVitFMWdVd3VMSTRHeFJ3b2ZUZUgrS1BUNGxWelVDSmJSL2VZQ3JwV2xQ?= =?utf-8?Q?muHB6Wl1KM0d6BQY=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a33280a5-6c05-406c-d9c7-08df09a9edab X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 10:55:55.3115 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: whwI68CUwLq1h+wrThcXI4xmzhS24PMsyIIdKw0RoqI/W/Yte2reJHhMGvaBh3p1dUSE+CynCekeltqKz2sD8FFIGsIEi15ZPareUd7w+f8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB7189 X-purgate-ID: tlsNG-4011c0/1788432961-593C4CFC-BA07A55D/0/0 X-purgate-type: clean X-purgate-size: 957 On 9/3/26 11:44 AM, Jan Beulich wrote: > On 28.08.2026 15:11, Ross Lagerwall wrote: >> The Viridian spec requires the vector to be >= 0x10 when writing to the >> SINTx MSR, otherwise it should #GP fault. >> The spec-defined initial value is 0x0000000000010000, i.e. the vector is >> 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to >> the spec-defined initial value and since the vector is 0, it GP faults. >> To workaround this, treat the write as a no-op if the value is >> unchanged. >> >> Signed-off-by: Ross Lagerwall > > Acked-by: Jan Beulich > > I expect that despite the (valid) absence of a Fixes: tag this will want > backporting. It should be fine to backport, though in general I think backporting nested virt fixes at this point is not needed as there will be too many changes to go into the stable releases for it to reach a usable state. Ross From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:12:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:12:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406841.1640011 (Exim 4.92) (envelope-from ) id 1x25Mz-0002EY-Pm; Thu, 03 Sep 2026 11:12:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406841.1640011; Thu, 03 Sep 2026 11:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25Mz-0002ER-N9; Thu, 03 Sep 2026 11:12:37 +0000 Received: by outflank-mailman (input) for mailman id 1406841; Thu, 03 Sep 2026 11:12:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25Mz-0002EL-58 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:12:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25My-000goj-Hn for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:12:36 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995621-e002-0a2a0a5209dd-0a2a450793ca-22 for ; Thu, 03 Sep 2026 13:12:36 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995623-b4ea-0a2a45070019-d155dd32e870-3 for ; Thu, 03 Sep 2026 13:12:35 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-482e4998d28so1656144f8f.2 for ; Thu, 03 Sep 2026 04:12:35 -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 ffacd0b85a97d-48448ed38cfsm12106231f8f.19.2026.09.03.04.12.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:12:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788433955; x=1789038755; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=0qCUUi+FntCFG0Q637oYFQ47kE/fJ7XBuQuatck5QEI=; b=VO0Sxr/7gYurdi7A/wUbhvbao8carFHpt7yIyDJ+AfSlGbI3svAhcqc34NRciApLn1 Neqk/vU9LesfGtq3ndgmVkuMSgj8upWMhcKeZJtsKQxaHvAs+ImKKYdLxXvPQXlYRq/m QIThUTihsg57QhDw/h6A6f8GL1fStNKos3mk084N6OMh1hjkq65hE+AmdFm/Cldt9Nap Qbr185esh6I2Ordd11OtVNhVtYHefUShPVlsPXNFyvVNq5iTkMK/HYvYULTaFlyNx1qA NCd5JyVS+S7XUGVqDv2BxERQrU7jNOmXgZZMAOyp+NlBn/wb/cGE3RqafvOzKgOQs3Oz ghwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788433955; x=1789038755; h=content-transfer-encoding:content-type: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:content-type; bh=0qCUUi+FntCFG0Q637oYFQ47kE/fJ7XBuQuatck5QEI=; b=HVRR0JEsJE8pVtztUE3UabMUvKJbr/YjI+EG0jgwpqIG7LGYEjYbB/FUV+OoGSW9TB 0OvGQUeFLYdSbl8t+8dpxUoYm05CT/BHx7AGnm3TjZZKY8ySK160CT+ABVU5jfBh4cj+ iuiiIVPPzaaLZ7mcMS7lCn8Mw5A8zZIzp4Z2Ocvi0mntrdaIm1QKO3IXnC9WRuiapUY2 EHQeSk9Es4gudB7XGSosLLiB8dWLTCJ9uSCKsc9Zu6d0QUAbMBvtJEipO8zsWMFc5a9O +RSypPqgcp6U2HqUUcSUhJ2QtTSDx7pzb3cGsh3bCvM+EUNmbzXFLq67NwojaB79WGhp 8v+w== X-Forwarded-Encrypted: i=1; AKwUvBwLz190QdwbqCOEQWZ/7LDTEIzqtEMaNyvz5FKIg+4fjqes5i+VfC1WOBuW1/slyxSDcT8NthGGVHM=@lists.xenproject.org X-Gm-Message-State: AFuF++nJPOuJBHlFCvpFNnuQ5ecUsgKHEFf0Sdg5p8DIMLnzRlhMC1CB ub0LEuGDVf3cLYUCgwnbrzMVhcwneeFj/0NUy4m8fDXYLQbX0kLNIoBoRUIfb+vn5IerqxE9IGP SYkrICg== X-Gm-Gg: AYBFou1jMsdCfGVH9TJZcgfVvlTtNGhRxK1eYn8NBRF5Se5uBKocypFKeXuDyvv1E3l finYGWAU4RdBwGDSM7HIphqlHTb4B2sVb6dFsC1Lifp3eql3Ar3hW2hCPVMeutqO+8c5c5vENXH 5ie8yjloRHuvNFGAkF8JbEjgUlnb7EjEmuyiUox+YT7xsiV6WZayXfOgTgSYG0o/lfA1fBSm8KP N1wYbY5GR4QEYhR/PyukH/PJDjCOSHhVuA6PE/0SGaAPDc11462p2NsB/nFL904SevQnhKKA31I 9nRRw5bGzMg+HpGq7aQivXJqgAs5PCiztfMZu9kjJr48fUijOOAK8SOOPNiVbSK6CA3aEiEkae1 sfQZA14SldKsfZS2PHDMTkvZunpzo+IUOR4KvM6PVRXAkbQeJxOa+sC4ONjLUZyZzAravsCAFQq A31AbRbcN0bFRyhsY9b/te5ExxtddYh8Y/ko8kgKHtii2CxzixF14UB4YwoIfXBcsvtqjml+mQO edIwfF4gtPXB75DIh04DW3dz6ar9Yad7lo1LVNcM453JXgnLhrf X-Received: by 2002:a05:6000:41cb:b0:484:44ec:2c14 with SMTP id ffacd0b85a97d-48488dece71mr21460350f8f.1.1788433943137; Thu, 03 Sep 2026 04:12:23 -0700 (PDT) Message-ID: <1279a949-6b18-4943-9d7f-046dec98e681@suse.com> Date: Thu, 3 Sep 2026 13:12:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/2] x86/viridian: Implement synthetic timer direct mode To: Ross Lagerwall Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828131142.3986110-1-ross.lagerwall@citrix.com> <20260828131142.3986110-3-ross.lagerwall@citrix.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: <20260828131142.3986110-3-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788433955-37AD0AE4-D1FAA1DD/0/0 X-purgate-type: clean X-purgate-size: 2947 On 28.08.2026 15:11, Ross Lagerwall wrote: > In direct mode, the timer asserts an interrupt on expiration rather than > using a SynIC message. It is useful to implement this since Windows 11's > Hyper-V can only use synthetic timers in direct mode. > > Signed-off-by: Ross Lagerwall > --- > > Should this use a new Viridian feature bit or is it OK to use the > existing stimer bit? Not sure there. What you need to deal with though are migration related aspects: - A migrating-in guest should not suddenly see the CPUID bit set when it was clear before. - As so far we don't even reject the .direct_mode bit to be set, it being set in any of the MSRs of an incoming, unaware guest needs to be taken care of (the guest must not suddenly get interrupts at the encoded .apic_vector). Dealing with this may actually be easier with a new feature bit added. > --- a/xen/arch/x86/hvm/viridian/time.c > +++ b/xen/arch/x86/hvm/viridian/time.c > @@ -223,6 +223,14 @@ static void start_stimer(struct viridian_stimer *vs) > set_timer(&vs->timer, timeout + NOW()); > } > > +static void stimer_deliver_direct(struct vcpu *v, struct viridian_stimer *vs) Second parameter can be pointer-to-const. > +{ > + struct vlapic *vlapic = vcpu_vlapic(v); > + > + if ( vlapic_enabled(vlapic) ) > + vlapic_set_irq(vcpu_vlapic(v), vs->config.apic_vector, 0); Before you use the vector, you will want to check its validity (along the lines of the check that patch 1 aims to avoid in a special case). Whether that needs doing at the time the MSR is written by the guest or at the call site I don't know: The (oldish) spec I'm looking at doesn't talk about validation of values written at all. Also please don't re-invoke vcpu_vlapic() when you have already latched its result in a local variable. > @@ -372,7 +382,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) > > vs->config.as_uint64 = val; > > - if ( !vs->config.sintx || !vs->count ) > + if ( (!vs->config.direct_mode && !vs->config.sintx) || !vs->count ) > vs->config.enable = 0; > > if ( vs->config.enable ) > @@ -583,8 +593,11 @@ void viridian_time_load_vcpu_ctxt( > > vs->config.as_uint64 = ctxt->stimer_config_msr[i]; > vs->count = ctxt->stimer_count_msr[i]; > - if ( !vs->config.sintx || !vs->count ) > - /* Reject enabling with a zero sintx or count fields. */ > + if ( (!vs->config.direct_mode && !vs->config.sintx) || !vs->count ) > + /* > + * Reject enabling with a zero sintx (if not using direct mode) or > + * zero count field. > + */ > vs->config.enable = 0; > } > } Related to possible validation needs: Is it perhaps also required that .sintx be clear when .direct_mode is set? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:14:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:14:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406848.1640021 (Exim 4.92) (envelope-from ) id 1x25Om-0002iF-4V; Thu, 03 Sep 2026 11:14:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406848.1640021; Thu, 03 Sep 2026 11:14:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25Om-0002i7-16; Thu, 03 Sep 2026 11:14:28 +0000 Received: by outflank-mailman (input) for mailman id 1406848; Thu, 03 Sep 2026 11:14:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25Ok-0002gN-Os for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:14:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25Oj-005xHf-F0 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:14:25 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99568c-2eae-0a2a0a5409dd-0a2a4505e472-14 for ; Thu, 03 Sep 2026 13:14:25 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995691-4cb1-0a2a45050019-d155dd2ec847-3 for ; Thu, 03 Sep 2026 13:14:25 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-482e2fdf5abso1101348f8f.2 for ; Thu, 03 Sep 2026 04:14:25 -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 ffacd0b85a97d-48448eea468sm13811027f8f.26.2026.09.03.04.14.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:14:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788434065; x=1789038865; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=CZ2OTDTCvOgHyrNppdWw4VatHH0Z8Omk3UUzL8zKRDQ=; b=NYBRYRtztLUa8+KewhOXlWC1CTyoZ+LCsZz99LXYHYqqFEeLWJlW3j+fTVqYM9gsFH MUKriLF8oXxfWZ4zC09MYD7Vs2LfFNOlDK6DHS1AY1lYoNm+Zkc+0OIXsKw9Jn3NTI1/ +b8w8wG494VKSQSw0/k8WKB2xBViKDiwVzv+J5fZ/duHMrMUl9JsN+B2S8Wd68nsvID0 AJ0G7ayTbNtJGMSKrWgsedp256wSd4dpG5/VtJ+R1cCDxySmR8isqw0oEa2Ae3n061Oy HIbKpBOVscb4pJg8QmdmtW3ZbQkOrEbScnimhuvnNLCpwfOFuZGKL75wD9W75qLRLyLU ALOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788434065; x=1789038865; h=content-transfer-encoding:content-type: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:content-type; bh=CZ2OTDTCvOgHyrNppdWw4VatHH0Z8Omk3UUzL8zKRDQ=; b=pwaXQ39HUYNm01ZGqLcyeqJ0XDd4VEcXYj8RxHBBpuiqBP4aF4MXOBugUKNH96w4Uz N5HFkHxdZWpeqBDTj8LcytY3V6SRddvY6dPdBbVj5KPYay40TsLim4x8zcOPQvtmB7m6 GRV5uQy8uNLEk6u9ABgR4J4kJE4eMazuDgGVPXHoxyeQb1P2MQIH1Qy0VU05E1KEtoSH r2SRz2kasriEiQeKsRHQHVCzPHhDazpOA8nRXN91qllqGCwV0rhX7d8Z9FixacyONzwu tfm2kIzJDIvQ76N1vZIVRM+GOPsma09l3wxBHsD4C79vwsM4fVVJBOOOmUj/5f8La0zT gX1A== X-Forwarded-Encrypted: i=1; AKwUvByK1ZDgc4HQac69lQWxaC4LdSr0NlpmKZTO26IrgXxlQm020IqLHFpw0gp5U+3ttfPOFklpn8nvTm8=@lists.xenproject.org X-Gm-Message-State: AFuF++lgfz+aBc8WuEJXmabacQV2oeHtkgPwPMlBlea3kmlXMjxc3lX3 ZAYc3zAtIYSDNhZPqnu2F6SXQ6qFabVFTKJwVyjdOaHA4a4w8K0rPxXtaM+FzG2C5Q== X-Gm-Gg: AYBFou0dS74y3ks2kJLkRaUh5ZVCz5j5etQHbBsYY19N37dZHx7SzZKDRxmBDyfUdPJ SkOPsk6pEpGSmyEInCnUrjyl577DUhd+AOlexOvrEZpuJH33k9uMG18r7tmGg9CH6kdjazbYaru 2vV+sZpQvZnZFpz/N3VsuC5NTMzigekTLw4sjP7V+l2EYmudLRn2YFwI25bhTKg/BKe9LEVvTMK 92DRxJ13m51gsJ5Ws2+hb3WsYMvN/JHeTlfX6GemaR/U6boTnNz+W5fCb8veRRoEcE9Ex5cCU1v nsQIjowazGrTF+G7Tg22Y2XqoufG0vd34uetAZ68XEqjRTUIrxUeiLqE5ARVrslzATTQrzfDsQZ AFAi2Cunihr0Ul+Cn8QFCwwkN849cvQazLmU+v2u2SIrpsebAsZub0/hbcsntTIxIhTcl/rnx/K 93MpBkDX3IejIapXYlsQUbbWzzqWnleXjGzGAViLYV6pd5rz1KJL5OG+j6nzy4raFvhBmxp3gwq bI89CKza6xptAqjR9bRrQaQ4R9l+hpBc1O7LLqoyELJs1mME6yy X-Received: by 2002:a05:6000:993:b0:484:3f88:b10d with SMTP id ffacd0b85a97d-48488f24640mr16633890f8f.18.1788434064845; Thu, 03 Sep 2026 04:14:24 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 13:14:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] x86/viridian: Workaround Hyper-V GP fault writing to MSR To: Ross Lagerwall Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828131142.3986110-1-ross.lagerwall@citrix.com> <20260828131142.3986110-2-ross.lagerwall@citrix.com> <39ccc2f5-7b3e-4c5f-a98c-b526f12bb1c7@suse.com> <12a277aa-2d67-436a-8afa-3a68ad6f6ae1@citrix.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: <12a277aa-2d67-436a-8afa-3a68ad6f6ae1@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788434065-F6CB02A1-43CADB04/0/0 X-purgate-type: clean X-purgate-size: 1114 On 03.09.2026 12:55, Ross Lagerwall wrote: > On 9/3/26 11:44 AM, Jan Beulich wrote: >> On 28.08.2026 15:11, Ross Lagerwall wrote: >>> The Viridian spec requires the vector to be >= 0x10 when writing to the >>> SINTx MSR, otherwise it should #GP fault. >>> The spec-defined initial value is 0x0000000000010000, i.e. the vector is >>> 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to >>> the spec-defined initial value and since the vector is 0, it GP faults. >>> To workaround this, treat the write as a no-op if the value is >>> unchanged. >>> >>> Signed-off-by: Ross Lagerwall >> >> Acked-by: Jan Beulich >> >> I expect that despite the (valid) absence of a Fixes: tag this will want >> backporting. > > It should be fine to backport, though in general I think backporting nested > virt fixes at this point is not needed as there will be too many changes to go > into the stable releases for it to reach a usable state. How is this nested-virt related? It looks to affect Win11 when run on bare- metal Xen? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:16:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:16:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406857.1640030 (Exim 4.92) (envelope-from ) id 1x25R9-0003EN-F1; Thu, 03 Sep 2026 11:16:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406857.1640030; Thu, 03 Sep 2026 11:16:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25R9-0003EG-C8; Thu, 03 Sep 2026 11:16:55 +0000 Received: by outflank-mailman (input) for mailman id 1406857; Thu, 03 Sep 2026 11:16:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x25R7-0003Du-Mp for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:16:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25R7-005xcK-2w for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:16:53 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995724-2eae-0a2a0a5409dd-0a2a45049168-2 for ; Thu, 03 Sep 2026 13:16:53 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995724-b57f-0a2a45040019-d155dd29a5d9-3 for ; Thu, 03 Sep 2026 13:16:52 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-4843e397f74so1272964f8f.1 for ; Thu, 03 Sep 2026 04:16:52 -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 ffacd0b85a97d-48448e80020sm13488309f8f.10.2026.09.03.04.16.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:16:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788434212; x=1789039012; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=F/5sLZ+lEb+ymYx9Ze2ITygxwf4YMxk0A3rsQUdNBG4=; b=NfrNatvOcDzwf4L8UVE9E05xvdUQy+HjVkAJ3zUUe8a8D4930RjMW933KP5qXON+fY PA41SqxBnKui7ZjpBQGUVFk9KdknSJS+epWfIhYMxSBxxNgksbEjWPHXdMMGUdPDnVOW C6Yr6UJK6Ccsmy1V1o5/XSfXJD6dyGpFFRUBhI6YftojC4Kx6kg3Et3Vo9CxfjoLSUh/ 9Gi7FexJWYcb6TvZwpoLO5QbiGzWNwFXmAT8o6aXQpeQVI+fkNw1C4ukXlw47zQmpYo3 nEfQqMYnXuOFrC5IF6cQzeoyippACegSnHaqTD0vb7ekp9n83nzb5B4dIJhOi0wuWbZo jh0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788434212; x=1789039012; h=content-transfer-encoding:content-type: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:content-type; bh=F/5sLZ+lEb+ymYx9Ze2ITygxwf4YMxk0A3rsQUdNBG4=; b=pYiOmuGrJUEkGkta6ZxerWVjjAf2ZDlcprrR/mM9EJ1Vft7M2EwqAf2He+yCjIYchb Ax44FdZv0iXpARWRitzHDZylNMgZw/sIycYPXMwVSX1rqvlCa+wHkbQy/P1Qi+h+Ut/w oh5Pm6GhN0sl7PiTDeWtcA4PHkH2JT9qIWS4SxA6YxVTypx/9QKTFZHBwFwZpJCbHIuq iJE6jVmwqTRJHA1Sp/pvfRY5K9goV06HuDpzB/s797kPzT8nNExj9grTdv4DbOBGkheT TvXDWHWkukJYzL9ykPIIqIixYKLjztmRuoosRb0c9qCgyo79OpQCE0vzLv5paUpDEGNU Lumw== X-Forwarded-Encrypted: i=1; AKwUvBynOHcwwgFOtIR2Bn7sJCfdLVFLlYA4wNdA1Qrwmz4mkP8wMhTEyfDoHho3qZWLY5DfIbX3ivkM5xY=@lists.xenproject.org X-Gm-Message-State: AFuF++nYd34PPFZ5rzjDsi/8uw8cuRFUSc03xlDMB5fUYQkCGj4mLNHC oY7SQtcwdvdwqADQFdS57FGqoUf3DBEsKxs9YKW3rTvI0aeQWN4682Cm+3owvFdbZg== X-Gm-Gg: AYBFou2gdPeS+wNWKYg5BsCAT/1dgZTSOblcJqANObLr3Yj1d6xjXBMXM6P2CJkPBA3 6cAXbFBv9MGkZ9tavbw4KGQW5bU+Y7jNInHg+mYSVRyfEQcEIHMckL4L1Lu4rKqdZLNoTCOIfgK PPb4CowYkSvQmtOctD4WNC5zgV/mKHzLiza8YyKoTIKmKCPHa7LcV7wBm4gVe//pKxywq0al1Mz wKViOv1agMz21oUbBIY5hVtGClooHT8JxZHc1M0ZKrQ5njzQXWx38fXAyg94cUF6cdUTBV0Bpkf hTU1ddZeAfNmLEP7vmj6hJM6bsqUVo8b2jZceIHGOnNZHbTq/E7sxXy2UUfCDfssjTq+oGNKfcP 5ZAil1RcGidYXOlLGIlE37d7awEgzCuz7/YtVRPGqyt+rhOnwLjen29AJbeU1d/i4iwRcEYfwAh bhmbjNZTk51RPUpZUh9wOe3PmqgWn/2KHGQu+gmSimrxrg0PstnZ2jmBYSpxxtuCibfeBlR0Hc8 OBk36Q+9l0IQ9C5h+7cSMDLd3KC2iYRwHpVyfjkLrIdVxHRkcSv X-Received: by 2002:a05:6000:611:b0:47f:71a0:c060 with SMTP id ffacd0b85a97d-4857e3cdcaemr7340101f8f.2.1788434210685; Thu, 03 Sep 2026 04:16:50 -0700 (PDT) Message-ID: <37af0051-69ef-4f9f-857a-8db76bf047e2@suse.com> Date: Thu, 3 Sep 2026 13:16:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 13/20] xen/riscv: introduce (de)initialization helpers for vINTC To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <688352e340872a50af99a51082966669787b1f72.1787836900.git.oleksii.kurochko@gmail.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 X-purgate-ID: tlsNG-ebf023/1788434212-C26CAB50-5460BCB9/10/73395122804 X-purgate-type: spam X-purgate-size: 1554 On 03.09.2026 12:49, Oleksii Kurochko wrote: > On 9/3/26 11:20 AM, Jan Beulich wrote: >> On 27.08.2026 17:19, Oleksii Kurochko wrote: >>> Add common helpers domain_vintc_init() and domain_vintc_deinit() to >>> allocate and deallocate a virtual interrupt controller (vINTC) >>> structure and initialize basic virtual interrupt controller registers. >>> >>> domain_vintc_deinit() isn't called at the moment as arch_domain_destroy() >>> is implemented as stub at the moment. >>> >>> Signed-off-by: Oleksii Kurochko >>> --- >>> Changes in v8: >>> - Add call of domain_vintc_deinit() to arch_domain_destroy(). >> >> Why only there? With ... >> >>> @@ -308,6 +310,9 @@ int arch_domain_create(struct domain *d, >>> if ( (rc = p2m_init(d, config)) != 0) >>> goto fail; >>> >>> + if ( (rc = domain_vintc_init(d)) ) >>> + goto fail; >>> + >>> return rc; >> >> ... anything added between the newly added code and the return, ... >> >>> fail: >> >> ... you will also need to call it here. Since it is (supposed to remain) >> idempotent, I think you'd better add that call right away (as long as >> domain_create() calls arch_domain_destroy() only when >> arch_domain_create() succeeded). > > arch_domain_destroy() (where domain_vintc_deinit() is called) is invoked > from arch_domain_create() if arch_domain_create() fails. Ah yes, so ... > So, the mentioned case is already covered. Am I missing something? ... no, you aren't. I was; sorry. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:26:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:26:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406872.1640039 (Exim 4.92) (envelope-from ) id 1x25al-0005Gl-AW; Thu, 03 Sep 2026 11:26:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406872.1640039; Thu, 03 Sep 2026 11:26:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25al-0005Gd-75; Thu, 03 Sep 2026 11:26:51 +0000 Received: by outflank-mailman (input) for mailman id 1406872; Thu, 03 Sep 2026 11:26:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25ak-0005GW-6E for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:26:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25aj-0029CQ-I1 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:26:49 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995976-e002-0a2a0a5209dd-0a2a45089f8c-24 for ; Thu, 03 Sep 2026 13:26:49 +0200 Received: from [52.101.46.33] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995977-f659-0a2a45080019-34652e217209-3 for ; Thu, 03 Sep 2026 13:26:49 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CH2PR03MB5319.namprd03.prod.outlook.com (2603:10b6:610:93::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Thu, 3 Sep 2026 11:26:44 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 11:26:44 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UuawMFK1YXaT7S8LitRKXURhxET9yKyZEG6na+YF+aqFM13NYMLH97l2c2i/kjG0QT4uoONXQPLyDcK/PX03PzZLUVwrrJ8E7QeISowe4MnSWNe2F6Y94jI0VH+QxpqlmHnRzNDua2pi4qrhvtOAq1iR1Qj2iGBYzJqAbasQIEOLnjh6S5xQaLUIlt6V+X2yCxaFNyh4hQO1TFRiYmrZlSMQg81HE3AAvTHhnBRQKHRkKIrniS3s29O29kHFpp2WaP+LUJ5ZrPteioCAvUth2aS0HXsY7HwXUJl3pPlfdWbV8axBBnNOBjC7eVvaFjtefauqqmYu+wnw1PlFfPq8NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Hf34BtU4NNagwBS8fBXREcIw1YPqhlc5/2yGbByNCZE=; b=Du7UqTxwdE+/CQHcggpAv7g8ts9DFB9RNX+lU5lKcrp5ah1eFgoTyhN3zmNnQHiPbSZQuN42i75m1DydmDDGQSRcj4TZMPLxjUdUPmoRr/ABUp8aB1FpdJHcO7ktpDPjR7zedpwdM94d71hM0OqlrntGnn5t1knIgU/WBLD6U+zOl16NR+1JMCCRibcVnk6FE2uYssMdpAN9TSDpqHQ5lzubklTIKny+5kqW1OvTyGfdUWU7I80I5z3qKDdLJddRXyu8R80lmuU03yT6Z37WCK61ZINZuKsZH9ub2LQGM1YX290oFo36aJdD4RdFw5XsZITe46ithg10DcUAOOpSuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hf34BtU4NNagwBS8fBXREcIw1YPqhlc5/2yGbByNCZE=; b=yD2cdWIm/UUv8y2WO14r+fd5+yUy3NEUYMEIw5P3u+6j3GskvUsZXjQvi7wahoibXEKNIELIDDik6LcPKNTmIuxNyMLFabs6bkEI+AiDtnPNgv5Z4q76Dp6MHqkIv+rjOK2i11oTxDM+PqmOnN1qj9t2HMsuOhxJ2ZcQL2s9Cow= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 3 Sep 2026 12:26:40 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] x86/viridian: Workaround Hyper-V GP fault writing to MSR To: Jan Beulich Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828131142.3986110-1-ross.lagerwall@citrix.com> <20260828131142.3986110-2-ross.lagerwall@citrix.com> <39ccc2f5-7b3e-4c5f-a98c-b526f12bb1c7@suse.com> <12a277aa-2d67-436a-8afa-3a68ad6f6ae1@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0174.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:312::19) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|CH2PR03MB5319:EE_ X-MS-Office365-Filtering-Correlation-Id: 2a3b9dfd-99b5-4330-ef06-08df09ae3bef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: v41YT6+j+EPxGwYstn2rjg++/uri8Vu6y11yl901nPXAd0vqV7cJdawvY7i3VYaodU4Rtlv31uyNBXPTUnfU8J52vjYHELJfKwtX9oVJGceJYHUoa4Y92PHleApm+hx8L+zz0+egFGfMUN8fw3dq2i1HEAFdO3Zpjg2TIpLlS/+CkJio3JkKIK/x020wRQtKf4sADE+HFnqcGEVzw43ls/H3FUJqjSRKnIytV3DtBPkQ9eSdrEPH8j5vQhceen7n9k8Jd3t8XWVzQUp7mVFXEzDchXXdmrMHP2NyrtuPRPOE4SHhCsE0YhlRnjZkDjBeG/w+bLpg8gdyWRORdngmPVqUgmvXqUfi7FOuUsfNNKYZi3kbX6jqsg1bFVZqVeX4JVi9LuxxWBhmbHONIjIiLPca0An3nFJJugS5aJIc+4s0mNUOEG6pJCi5m/3ol2oVTI57Rl4XAKgn7gw1sx09P9EILgwihsigYiwwl1n2BAZFGQsmpeUYLS0U0IKNPv29W06Rv9WagcOiHf8TE9Yiy8P6ACoSWWyN+RnLyLp/N6t+RRvjuWDaSHBwbgYb5KVn4V6jb/yjRRujJkvyPY5J8QjYRDOfD8CcCmfzh7YpY25lzWjfj8lqyZcLqefbiA1tH3X9ww6bmke88139bpmOFkmmbcRnYmt0AqcQt85xoQk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RlRsdHZSYk1id1BJY3FTRU9sWExnOU5pdVM5Q2ZYK2xtbEd3dW5mczRMQmRq?= =?utf-8?B?OUZnK3hwWGxsRHhXV2Vxdzl6UTBtTjEwenZCbnJhZUJ3NzhNK1cwcGxUQlRY?= =?utf-8?B?ZjFGZXlMcjIwOTZPQ3htUmpVUkY1eXpmblREbkYzT0c4Z1RHTnhHcEIxUld4?= =?utf-8?B?TktzL0FnNFl0LzQvMHJXOStHdW41NmJPMWJWUVJuUXh2UFB1bGFnamk3NFFR?= =?utf-8?B?cjdrZGw0d0VkSFRnSzJJRkNLaXZsRXJsZXlhUEhhLzA2bzE2bTFOSk5qNWdJ?= =?utf-8?B?MUZpbWtqcnlpcTBWcWwrZHJHZDZja2Y4Z1RtWjdTbU5acURoYlh5Tlp0TW0y?= =?utf-8?B?dktKNFd5a1k1ZTZCbk9oYWJHQmtIaWdGSSsvTGUxU1FPeHZoR2JiVlgzeE9W?= =?utf-8?B?b05tMFBsUUxWYmFDditIZEJSUnRMZnNyMmFnYVJuWmd5bzNlVzBGWXBITWt6?= =?utf-8?B?NTIvTmpYM1NKRjEyZkdqQVdBbUxxK2QxajBZWFVHMlBYUWdOQUgxYmJjS0dx?= =?utf-8?B?SzNlN2E5andSNHY3SE4xSllnSmFKREJPVGZsdkRRcElKN3V1SWw2YUhXUDNk?= =?utf-8?B?Z205LytZMUZVRWp2QlkvNWdleUpiem1rWW1xT3lwYzI0RnJqRzlvdi9jdldE?= =?utf-8?B?aWFndU1mVEFxcVFnL2R1YXI2MzQ1cE1GcVZYWFdiYlN2WDdJellYV3JlV3NQ?= =?utf-8?B?Y3hsMThxWDJ1ZGVVaFp2Q0QveTFqUUsvU3BqQ3g2RWZGcmNvTG9QQjNKN1Jj?= =?utf-8?B?Lzg0Z2JKQVQrb0gvVFhCc1BNeHdFNUluK3lMdmozZEF3TlRsNGs0VDY1Skta?= =?utf-8?B?cmtyZngxUnJaVFdsMFlsRWZyVTc2S0M3dWhoby9jUEtLN3djMXRGNlZmUVNN?= =?utf-8?B?VWsyemxpS3Y4M05BdWFYKy8xV2R3bThHNFVwa2lobFEvWEJTUG5qTGVUTWlw?= =?utf-8?B?Mkt2bDZPYTUzVnltQjU0cEZUaFJSMEk2OWFSeFpWN0tNc1oyd0N4VXNOT0lM?= =?utf-8?B?ajBRajRFSFVDa0pQTzhVSjRudUpUZHZaekZoK1N4OUV2V3RlYjZRMWFrSVB4?= =?utf-8?B?SnArWjBmRllkaG55andvYUZKd3pybi83bmh2UnNmZEVEK2RYcDVFUmYxQjNO?= =?utf-8?B?d1lmNnNVaXdaNytPUy9qWjVqb1hwWFdLamlFS29tVW1NQi94cEd2UDFQN09p?= =?utf-8?B?Q3FRRnhHcDJLQzBLV3hXNyt6ZVZhNUZudmpFVmRyNWYwUlNDckk0MTZEY1o0?= =?utf-8?B?K1VxdnhGQWZyOXJVc2VqdTJmYjgxTFNIRU9FWHJiMFIyUXg1ckxtNzFPS05Z?= =?utf-8?B?SzJxaDBpRTFNekZRbjRhTG5uVnFPQlI5VXhxMURvdlFrZkh3dUNoblFMQVF6?= =?utf-8?B?WU5Odm8rRzI3UUo3S000bm5xSTJVd2pOTG9YVEJNaktwd0lhZG8yZHROcGR6?= =?utf-8?B?aEF3dDZFWDN0ZkVmVGFucmlveTFISXlGUkIwdmxEWUpGYk9ZWS80MEd0VnR5?= =?utf-8?B?N3kzQlJWUTRuU0VBdm01Q2VJQTZOd2Nnb3d2L283a3ExR3NGREFnOFo5QjBs?= =?utf-8?B?a1kzS2RaKytQVXl2MWpsclNuSjVjSW5LbFNKa1BUNlBaWXRwNlF1QUd5bHdH?= =?utf-8?B?QTE3bDNKMy94OEsvWUJUYzhhbFlybXI1WnVtRUNYbXZmTFRtaDY0aWhxbk8z?= =?utf-8?B?NkdYaTRzQUIvbkJ4Z293UWQvbFpNQUc1V2F3Y0xkc3pOVWE0MXdrZzdCNXB1?= =?utf-8?B?U1V3Szh0a002bXBtVURFMDVoczAvWTdqQ0VyUTMxU2JmaXBYbVZ1SzVxYVFO?= =?utf-8?B?Mm0yUHFMVmZXbG9aRHZvRldsdXE0YWlqQmxxR29oc0k5YXVIUU1VK3J2aGVJ?= =?utf-8?B?NlVXTFp6aU8zYkxBRzJ3QUp5WnRrZVRJWG5IVURWSUJ4OVVmZ2h3akY4L2xO?= =?utf-8?B?dFB5WHgxQmxkTkQyanNScmxCNTBjYlUrL3VuWEROVmlkRHdOWk5qY0oweURz?= =?utf-8?B?NFNhd05naVlUR3F3WXRGTWxmUlQ1TkJqOUFhNEZEZi9xUmVUaTlQM3VBbEo1?= =?utf-8?B?UlZ0dERWVlBCdzRmYzdDbCt2bkZLaThlaWgvall0TUZqRkZzdXlXanZWY2FO?= =?utf-8?B?azJyMFFoQnp2eUdqbG91dzdUYUZPNFlsRlBmbndGWEdvQllCeVgvY0tQZEhB?= =?utf-8?B?R2lZa3daRjRzOW1GWWRhWlFGOUlSdVRiUzFnQ2Z4bCtWWlcwZStlcWdXRTlZ?= =?utf-8?B?NFZ0bVhwWWRGdnBpQklJalZoNGxTdy9YWGhvVnNiQlFuMTNsVlZvQjhvQXNa?= =?utf-8?B?eHRQQk4wc2RmUlVrUFIxWTZIM25zYitEQ0RQcnhBWVNtMVZIM3VCMW5YU2hi?= =?utf-8?Q?OXR1Yg+/QC9sSUqM=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a3b9dfd-99b5-4330-ef06-08df09ae3bef X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 11:26:44.6061 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: m72wzUpOc5+XG9zKPesFAczAZuxGGE4wzyPdCvv6E9Q/oqH7XIKyRhUoj7dEviLCSui4xCGcjA1pwN/r9DnrV2RRimmFvKYc41Sz7PSLhzA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5319 X-purgate-ID: tlsNG-c1860d/1788434809-CCF4F87B-AA960376/0/0 X-purgate-type: clean X-purgate-size: 1401 On 9/3/26 12:14 PM, Jan Beulich wrote: > On 03.09.2026 12:55, Ross Lagerwall wrote: >> On 9/3/26 11:44 AM, Jan Beulich wrote: >>> On 28.08.2026 15:11, Ross Lagerwall wrote: >>>> The Viridian spec requires the vector to be >= 0x10 when writing to the >>>> SINTx MSR, otherwise it should #GP fault. >>>> The spec-defined initial value is 0x0000000000010000, i.e. the vector is >>>> 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to >>>> the spec-defined initial value and since the vector is 0, it GP faults. >>>> To workaround this, treat the write as a no-op if the value is >>>> unchanged. >>>> >>>> Signed-off-by: Ross Lagerwall >>> >>> Acked-by: Jan Beulich >>> >>> I expect that despite the (valid) absence of a Fixes: tag this will want >>> backporting. >> >> It should be fine to backport, though in general I think backporting nested >> virt fixes at this point is not needed as there will be too many changes to go >> into the stable releases for it to reach a usable state. > > How is this nested-virt related? It looks to affect Win11 when run on bare- > metal Xen? The regular Windows 11 kernel doesn't have this behaviour on startup, only the Windows 11 Hyper-V kernel (and possibly other Windows versions too) so you wouldn't encounter this behaviour unless using nested-virt. Ross From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:29:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:29:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406886.1640048 (Exim 4.92) (envelope-from ) id 1x25cv-0006FN-PO; Thu, 03 Sep 2026 11:29:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406886.1640048; Thu, 03 Sep 2026 11:29:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25cv-0006FF-Ld; Thu, 03 Sep 2026 11:29:05 +0000 Received: by outflank-mailman (input) for mailman id 1406886; Thu, 03 Sep 2026 11:29:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25ct-0006F9-RB for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:29:03 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x25ct-003XNA-1r for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:29:03 +0000 Received: from mail-lj1-f174.google.com ([209.85.208.174]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1x25ct-0005ZS-0u for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:29:03 +0000 Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-3a1eb6fa0f4so19511881fa.2 for ; Thu, 03 Sep 2026 04:29:03 -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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Type:To:Subject:Message-ID:Date: From:MIME-Version; bh=lBpr1dHsh1/83EeGe2tnLAXLfvBy8CNmurnZ+bsrkX0=; b=0DvFVd+ jb2R1ZZNmR9/y0afItpJIV5UDl4do1uKG+hHFdWAxrsiIoA0pjGn/h3kxA+lPJmCl+j0k3OiRRcbE jn1srf0AwEBWEHGc+9Afh6urUTklxn3r0tLvnITHbrLOb3aBn8D+620sGgM7NjIb2zdlbIofLmxWG LcfW/zsK5g=; X-Gm-Message-State: AFuF++kKh/oBAqEOXHDMv5I2jyEMjJiSel6XjkUwv7PuLucMPilO4zLy HqyXJYJbBULq2yTPbbI4N32AyQabxpAeIyW4KpUk+YURdsr9D9pfHLj6RLj6QO2dPc815L+HiPf xdhGvnHQWVQ3JA2QxQxK27DwRqbx/ZIE= X-Received: by 2002:a05:651c:4181:b0:3a2:6bdf:336 with SMTP id 38308e7fff4ca-3a34fdec142mr25686861fa.14.1788434942138; Thu, 03 Sep 2026 04:29:02 -0700 (PDT) MIME-Version: 1.0 From: Cody Zuschlag Date: Thu, 3 Sep 2026 13:28:51 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1WpsvuPq-6Y0YPo2qHrACFCqqLamwjdJuQPYSXNCbdbJzrsQlSOarIIN-w Message-ID: Subject: [ANNOUNCE] Community Call Today (and call for agenda items) To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000006e1c7d065a92754c" --0000000000006e1c7d065a92754c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, It's time for the September Xen Project Community Call, happening today (sorry for the short notice), Thursday, 3 September at 15:00 UTC. Whether you have updates to share or just want to listen in, we'd love to have you join. It's a great opportunity to hear what the community has been working on, discuss ongoing project activities, and catch up on recent developments. *Preparation* =F0=9F=91=89 Please take a few minutes to review and update the agenda befo= re the call: https://cryptpad.fr/pad/#/2/pad/edit/RSWQntS-oB8CBZImS8YfxAgj/ Feel free to: - Add topics or project updates - Suggest anything we can drop or defer - Include links to patches, mailing list threads, or documentation where helpful The agenda also includes the meeting link and a link to find your local meeting time. *Call Details* Date: Thursday, 6 August 2026 Time: 15:00 UTC (agenda starts at 15:05 UTC) Join: https://meet.jit.si/XenProjectCommunityCall We'll open the room at 15:00 UTC and begin the agenda at 15:05 UTC to give everyone a few minutes to join. Want to be CC'd on future community call announcements? Add or remove yourself from our sign-up sheet: https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ See you on in a few hours! Cody Zuschlag Xen Project - Community Manager --0000000000006e1c7d065a92754c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,
=
It's time for the September Xen Project Community Call, happening t= oday (sorry for the short notice), Thursday, 3 September at 15:00 UTC.
<= br>Whether you have updates to share or just want to listen in, we'd lo= ve to have you join. It's a great opportunity to hear what the communit= y has been working on, discuss ongoing project activities, and catch up on = recent developments.

Preparation
=F0=9F=91=89 Please take a few minutes to review and update the agenda bef= ore the call:


Feel free to:
- Add= topics or project updates
- Suggest anything we can drop or defer
- = Include links to patches, mailing list threads, or documentation where help= ful

The agenda also includes the meeting link and a link to find you= r local meeting time.

Call Details
<= br>
Date: Thursday, 6 August 2026
Time: 15:00 = UTC (agenda starts at 15:05 UTC)
Join:=C2=A0https://meet.jit.si/XenProjectCommunityCall

We'll open th= e room at 15:00 UTC and begin the agenda at 15:05 UTC to give everyone a fe= w minutes to join.

Want to be CC'd on future community call anno= uncements?

Add or remove yourself from our sign-up sheet:
https://cryptpad.fr/pad/#/2/pa= d/edit/D9vGzihPxxAOe6RFPz0sRCf+/

See you on in a few hours!



Cody Zuschla= g
Xen Project - Community Manager
--0000000000006e1c7d065a92754c-- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:42:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:42:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406897.1640058 (Exim 4.92) (envelope-from ) id 1x25pg-0000mQ-SF; Thu, 03 Sep 2026 11:42:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406897.1640058; Thu, 03 Sep 2026 11:42:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25pg-0000mJ-O2; Thu, 03 Sep 2026 11:42:16 +0000 Received: by outflank-mailman (input) for mailman id 1406897; Thu, 03 Sep 2026 11:42:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25pf-0000mD-Uu for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:42:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25pe-007F76-3j for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:42:14 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995d04-2eae-0a2a0a5409dd-0a2a450c9990-44 for ; Thu, 03 Sep 2026 13:42:13 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995d15-f479-0a2a450c0019-d155802bb0f2-3 for ; Thu, 03 Sep 2026 13:42:13 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49b0dbfbf7bso15419765e9.2 for ; Thu, 03 Sep 2026 04:42:13 -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-49cee80eda4sm64236985e9.15.2026.09.03.04.42.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:42:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788435733; x=1789040533; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=npp0ub55aNlc3rwTuV4j9Tb9YtvYLeH4AVh1wcRfluk=; b=ebBu9BYOdNtF/sQHSrFqIlPzg5laSMBZ8OCLwbPjcflHkxY8mCRyz3R2YAGPOaFY/L yj/WQsE510Ud1gMMISXExT3FR0mTMFZ743UyoQMnpoU0n4cFVxmpnoQMF9Uur57Dif0m qBPZl7dijAX56CQtp6I6cXXpKQ6e8czY08YNwgq+88CZtU1AffceA3amnDUr6Rh27DY+ 2VxnhJBPhZKamfZWKneYxmQuw6L+dO5Kl0s4E5IxuKgkerZHdn/191TzZZan12Wnq7ym ZIUXUqiZRllCfbOe4tIJuVKJy0HhFzkwGD3YYhvTZ9HvldgzltePWVa9YYrzG93ptdbB e/Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788435733; x=1789040533; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=npp0ub55aNlc3rwTuV4j9Tb9YtvYLeH4AVh1wcRfluk=; b=Iy2p+3jJwL8MZzSX2zbUICqm6j29mEHtcJkZEBD+bra1drllXOuSMEnK+OUKluUHOq tv45h7RweZ7bS3PJgdsErextxGUqTBqcYsnmdr36wm1w5Xjxci+SHA6+u2+02BtxB1iT bkJ/gvsDr+KRFS8IiGmxptBoTA4EuCXCvE2fOJlXeF93o4/gRw7DWglhE2wpeAK5/DNH 1URM3O3dBW6XSLO1Nfgt9B8bc76IibMwcJZyGpXBIILAEshO1DV5V5oXTiGH20P3SpE4 LhhiPqiiGJx0k6VKxGrI8SLbt6Ikgw1D7ifdyGo8FNMXs9dv2aOJ1CtLiCR7dkRBv8ex QUSg== X-Gm-Message-State: AFuF++nbCego4a4taOdUCWDy0s/TO852LMT1INdDisCi/cYH3CjsFfOy Pcg0AnvjCPG4i4iQz8cGMw0pSDr2+7z3KN180+T3lwCyR1TIDQzEJrwurHtazHw5tRNy153WDFQ d6Vv4Jw== X-Gm-Gg: AYBFou0c52DUAa5FbpQqpGXsQlKwfvJC4LxvEjf22Gg59/n33ZLhSjLb4kigsEowOED 4q5emcRALd5AvPq2/hb5uN8rHW+7KGzgkGT0nKDnikHU2NOEIjOF9KIXH4/Mx9a/ZUnYTa3dYoS G70gs78ua9604j5mk9HBLLyuNv1fgSaGqFj7LgdDCMjEvGPUEyc41qlrt6HLpoJ+73i58DtVcIM tll6lF13qxmy1gkCtaaKms1V5vyLPkdHidO0IliyTFAmLzqyrllQr/lx6MaOW+ZiJm8pjWGrAQL KRS9zNoobGqLjksDSR23TDmU8UIDToR1C/tjtc0KKGRX5iRvyzZSdnlEl68CDR2xO72buNo14Th GnBu5J0H4IBx2onxmz+DXevbb/xVWuQ4jYTHwp1uvEwVGAeeLD4NKq9VHqxiHxbGBSpiDsiyR3P JtG3/b6HkGTSm/0DhQWYpKG07KXjuVOs/9mD5e0r5ZIQQ3mdxc8QrlSzuEH0uxtsJiGz8KgHsuq x33Jzdq1ihkqBizWZdWOc2aDmBE7DdgJ8o732dhOZI8OII6fFGi X-Received: by 2002:a05:600c:524f:b0:49b:8c63:dfdf with SMTP id 5b1f17b1804b1-49ce584c87bmr179613625e9.15.1788435732844; Thu, 03 Sep 2026 04:42:12 -0700 (PDT) Message-ID: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Date: Thu, 3 Sep 2026 13:42:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini From: Jan Beulich Subject: [PATCH 0/4] address most remaining rule 11.1 violations 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788435733-00ECAA5B-65F4F93C/0/0 X-purgate-type: clean X-purgate-size: 535 "Conversions shall not be performed between a pointer to a function and any other type" The few ones left (x86_64-allcode:1, x86_64-amd:1, ARM64-allcode:2, ARM64-amd:0) likely need dealing with by tweaking patch 3; see remarks there. 1: x86/domain: address Misra rule 11.1 violation in reset_stack_and_call_ind() 2: Eclair: relax long <-> function-pointer conversion deviation 3: Eclair: relax "noreturn" function-pointer conversion deviation 4: x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:43:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:43:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406906.1640065 (Exim 4.92) (envelope-from ) id 1x25qk-0001FY-3Z; Thu, 03 Sep 2026 11:43:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406906.1640065; Thu, 03 Sep 2026 11:43:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25qk-0001FR-0p; Thu, 03 Sep 2026 11:43:22 +0000 Received: by outflank-mailman (input) for mailman id 1406906; Thu, 03 Sep 2026 11:43:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25qi-0001FD-Lf for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:43:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25qi-00Epyw-25 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:43:20 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995d3d-bab6-0a2a0a5309dd-0a2a45028086-40 for ; Thu, 03 Sep 2026 13:43:20 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995d57-6ca4-0a2a45020019-d1558031d88c-3 for ; Thu, 03 Sep 2026 13:43:19 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49b0d78a801so18839705e9.2 for ; Thu, 03 Sep 2026 04:43:19 -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 ffacd0b85a97d-48448eea5b4sm13613689f8f.27.2026.09.03.04.43.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:43:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788435799; x=1789040599; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=dRoVP6mPAAUzl0+K2OfWrG9TPv2kIzR6dwNYvx6VPj8=; b=WdyKuzsbR6Q66zSVK8NAad+jmb1XIhEOImsDSq5NvC49yM49xPDQnWi1W0k7e9cNfi czwr6FicZWR0bZQ7PI5pDg+Nx+AOw2MPZCpCvfRcOz08MI5rG6b8zR4UOghne0fR9tjl NLp2P+lkyWv1MdygPzU75ZD88Rt8X84qsq07FXBNqUOj3tJV+AH35PJNmTjd3YxoUiyr ZpVbwPI/spHLqGvxUFXbKn1VFErdJI43PNwfZZQSTQ3oL5SAATZjMhgTDtaidvdDmHuf sDSp0OOPolgLtn7z/JA3rq5AxZUWrdwCWReGVfZvLIPuTPsTmayfugbevgAl2K3OzfT9 vT6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788435799; x=1789040599; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=dRoVP6mPAAUzl0+K2OfWrG9TPv2kIzR6dwNYvx6VPj8=; b=dQSR66fsy0A501hLXAocZw+4jYp1SaZld88SCLSneAjI8fkMeyDg8keyWSkAaGpYXi YLFxw+Me9Zf42zXpuYExvhdDP8268GL36qQEnJC6PnrbJi1Xn/TVEsmUv2UUfuw0WkD/ LZpCQKigSYpg66wB/D3K/eeRuPwNJsVafAz9507v0cX1n+cSCniqv1nVSorXZBg2Zg46 sJfVente7jxWiMVDCIUff74iFS6EWzcGffUStHIqylqDmZ/a83mvFSAVmQTKUMxj9PvU LEIhXIIvtAeZxsW8rptY0MsuV0VuPX27U03mNmX3Lgxq1ZsmIPrxQJ/4jaPLum3pamv2 kGqA== X-Gm-Message-State: AFuF++lcL9c9Hanfu5zcFBW8fGvCKXcD0jqjEbPsfnlFkTct/H0jGon4 sYc6FWCnwkD8R2jHXr9gsc4u9F36a2hRNyC61U9K0Vgc46IH/uiE4yjwSY+AMlC1x+sr/QH4zzK 6bYBv3g== X-Gm-Gg: AYBFou02mMmjRwt8Gx1s9mvkpAZrmY11Zs2chmX/ZufLKpf371HDN4jNLOtgODtBPGp UudTxfiV6XOK5vMG5ZmyTmEakU0H0A6mDfrdqevVQvasOQzHmTFeIAxfyFz0rdoIGdtNlC38I4m eMyudhOXLCDLgNQYn7Hszo6mYl8GrRoi98I61vsRnBA1vtJOO74JxVD2ld90Sth76hi9rGpfcD9 UJo2UMG7MTpjBtC5hUalF9rnYT8DPSL1UQm9ElehggXGnU2wKUowu2dtHrlOvdpZKyg8UlTnYuk /C75HBrOuNnIsvmt8/wfBfRKWhk0CEJbVk3MACw3JqdTlqrUl904jdCduKFOxLlSyqSvbQYVYy3 bWok78u6nrM+EjrkRJDSBs0oKCYN8LptC2d5+9IsbOTtkyHMEjVdO0xjb1IY3b/TeVYAQlWk/Me Xf/ZCi4TXcdeoqGg7JnBP1hKUstuKQPPD17O0RDQdP2EX0tC5MBHERRVaEsbKture+s4eMbnOlo C+KexygvgDarrytcknY2LqFJpKv1siHsfz+UPiVWNYv8LSxk7ZZHdAKqW/uFTJu X-Received: by 2002:a05:600c:a00a:b0:49c:f4e1:3135 with SMTP id 5b1f17b1804b1-49cf4e13cb7mr25162065e9.14.1788435799469; Thu, 03 Sep 2026 04:43:19 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 13:43:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/4] x86/domain: address Misra rule 11.1 violation in reset_stack_and_call_ind() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Language: en-US 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: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788435799-674BE2AC-3AB31209/0/0 X-purgate-type: clean X-purgate-size: 1364 Eclair dislikes both sides of the comparison to differ in noreturn attributes, thus deeming this a violation of "Conversions shall not be performed between a pointer to a function and any other type". Since gcc doesn't permit use of "noreturn" types used in a typecast, resort to typeof(). No functional change intended. Signed-off-by: Jan Beulich --- Really Eclair's diagnosis is misleading here, and not only because of the missing "noreturn" there, making both sides be identical: There are no implicit conversions performed on this kind of pointer operands of an equality expression. A diagnosis of "comparison of pointers to different types", along the lines of what compilers use, would be more to the point. --- a/xen/arch/x86/include/asm/current.h +++ b/xen/arch/x86/include/asm/current.h @@ -208,7 +208,7 @@ unsigned long get_stack_dump_bottom (uns /* The constraint may only specify non-call-clobbered registers. */ #define reset_stack_and_call_ind(fn) \ ({ \ - (void)((fn) == (void (*)(void))NULL); \ + (void)((fn) == (typeof(dom_xen->arch.ctxt_switch->tail))NULL); \ switch_stack_and_jump(fn, "INDIRECT_CALL %", "b"); \ }) From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:43:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:43:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406909.1640075 (Exim 4.92) (envelope-from ) id 1x25rB-0001ZN-CF; Thu, 03 Sep 2026 11:43:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406909.1640075; Thu, 03 Sep 2026 11:43:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25rB-0001ZG-8c; Thu, 03 Sep 2026 11:43:49 +0000 Received: by outflank-mailman (input) for mailman id 1406909; Thu, 03 Sep 2026 11:43:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25r9-0001Ye-JR for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:43:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25r9-00EqCc-00 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:43:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995d56-bab6-0a2a0a5309dd-0a2a45049c9e-42 for ; Thu, 03 Sep 2026 13:43:46 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995d72-b57f-0a2a45040019-d155dd34b4e4-3 for ; Thu, 03 Sep 2026 13:43:46 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-48436251906so2351218f8f.0 for ; Thu, 03 Sep 2026 04:43:46 -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 ffacd0b85a97d-484492ce5e5sm13018385f8f.36.2026.09.03.04.43.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:43:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788435826; x=1789040626; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=0ZyhfUsdFRoR5FzsVA7Ej7gYdWCaH0EjObTUL4EJH3c=; b=FrIDBKz70aUmAGrLEoHBW5SSwQcocZ1xE1xY2RJ4m7QnyQ9oDgWTZ8GWkiDsDg1jur ENKDAJEBG+Ch7N4+Il8Cbly7nd9EBYBAuTl1Dm4pSeRWCownGYvsgc1jLwelrAc88UNN 1pOE0TbGzr8JlPn/v7ULaz8Ijv8A6J+oQ54P5+ddo2cFX16492ZzXY2dj/NnEQ3EdQLx 0KpLhII2Yb5FWJJUFqlOhJuS7UpE7UD4282mnmdtfULR3eJroFqdID4CNd5DBktxm2Qb 87FcKInSycxIsoviN4lsSj2QHMu21LXp1gnzJnRgy7/Yb/kKVtraVtrbeGLP3GwYIXUi rLzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788435826; x=1789040626; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=0ZyhfUsdFRoR5FzsVA7Ej7gYdWCaH0EjObTUL4EJH3c=; b=AjxxQk3IhCrAj+mJXl20ZUDts3bgS6zBoukA7uzhE91+8QW/kU/H9o7SHx/ayuQIz1 5H9Swbh1f2JqS4cyOYfuU4GkfWzJH8FO4yvuSLe2Y6nnFn+oa6SqKJ5nNDrNw44LzixC 3F5qUgQvLV4dubeqDTEbqdBBwyhIJBBRZsVuEFXV9mjWzCs3IeTD27f6no7Y1cKo+KMt 2fC0VK59w1qDEjWtOx5OPqMCUUh+VDa/gYVaKComDduUhxXQaQxZ6lMK3Lsl+bvCNtrc 2F5OS3qy2ifAOEkR2HS5JdV4QQWuess2dj8O2i68ilgPcgxb9RXvFdD2EkwQ+5Xx3s7b UN8A== X-Gm-Message-State: AFuF++lvbD5FVOwhVJEsmOUIOnv0Zk1z+Nm9Cx4HpiWduQXWJm9/VtAk Ir5LxTZaXaGNtNY90SwdS5nFRONxGRP8cD/gUeWT4fgw+WpxWxBeMIItbpqLViMapUaj/yETZZu 3SbAXRA== X-Gm-Gg: AYBFou2i9eFPNaw8grsYHd8aYms/bYHacnyS4H+NsBnPL82h8T5fD01Svhx4vqvLLwk lHreTqgxFN1vTk1xqaqyVpV9j+qxno3KtCSukjQSFZL8uc3mSEacLTJHcICRcsmDp3WV42kf6TN KxU9bLtLubFskv4mVtIZDhOoGk949qIw0K605/J1URuyphKyvpZjILP5uufBTadAWR2h6JCGn5C FiqfnMuDIwxCl6xbRyHuVDwknOVCcXdtasDaLEPPbfvkGjg+mPsO9epAKNH20LQ1DOHImRyFbv9 E/fNOYAo3iyJrAaWVNvv28Ek6nZg0Zj/Cp7g6JXoNHma63QG5SLpzMV5NMjpq9BVjLgaBLXE7aM xlV91+pRgRLHNAfZg7ayTs33p7qAUHYpvE52rSxbKCBdO8VTB//YbY3YHy6hhkxKTEAjPjxrviF naoaRyrU5wd6QlxoXxrn0nMInFyo87O7cMWAQ1s0fsEx+2xxkSp0pCILF3o6qj6OXcNxrh3Q9e/ gfdtnnnljweC1ImnJHnBY6X68V9YjSnE1VN4XtfXsGLJJ56MYjE X-Received: by 2002:adf:e008:0:10b0:485:847f:fd9b with SMTP id ffacd0b85a97d-48584800180mr2730636f8f.6.1788435826319; Thu, 03 Sep 2026 04:43:46 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 13:43:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/4] Eclair: relax long <-> function-pointer conversion deviation From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Language: en-US 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: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788435826-512DCB50-BF442150/0/0 X-purgate-type: clean X-purgate-size: 2418 What is true for unsigned long is also true for plain/signed long, thus also taking care of two instances of __x86_return_thunk() being cast to long. Signed-off-by: Jan Beulich --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -368,17 +368,17 @@ constant expressions are required.\"" # Series 11 # --doc_begin="The conversion from a function pointer to unsigned long or (void *) does not lose any information, provided that the target type has enough bits to store it." +-doc_begin="The conversion from a function pointer to [unsigned] long or (void *) does not lose any information, provided that the target type has enough bits to store it." -config=MC3A2.R11.1,casts+={safe, "from(type(canonical(__function_pointer_types))) - &&to(type(canonical(builtin(unsigned long)||pointer(builtin(void))))) + &&to(type(canonical(builtin(long)||builtin(unsigned long)||pointer(builtin(void))))) &&relation(definitely_preserves_value)" } -doc_end --doc_begin="Conversion from unsigned long or (void *) to a function pointer can restore full information, provided that the source type has enough bits to restore it." +-doc_begin="Conversion from [unsigned] long or (void *) to a function pointer can restore full information, provided that the source type has enough bits to restore it." -config=MC3A2.R11.1,casts+={safe, - "from(type(canonical(builtin(unsigned long)||pointer(builtin(void))))) + "from(type(canonical(builtin(long)||builtin(unsigned long)||pointer(builtin(void))))) &&to(type(canonical(__function_pointer_types))) &&relation(definitely_preserves_value)" } --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -432,8 +432,8 @@ maintainers if you want to suggest a cha - All conversions to integer types are permitted if the destination type has enough bits to hold the entire value. Conversions to bool and void* are permitted. Conversions from 'void noreturn (*)(...)' - to 'void (*)(...)' are permitted. Conversions from unsigned long or - '(void *)' to a function pointer are permitted. + to 'void (*)(...)' are permitted. Conversions from [unsigned] long + or '(void *)' to a function pointer are permitted. Example:: unsigned long func_addr = (unsigned long)&some_function; From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:44:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:44:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406915.1640084 (Exim 4.92) (envelope-from ) id 1x25rW-00025v-MX; Thu, 03 Sep 2026 11:44:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406915.1640084; Thu, 03 Sep 2026 11:44:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25rW-00025o-JC; Thu, 03 Sep 2026 11:44:10 +0000 Received: by outflank-mailman (input) for mailman id 1406915; Thu, 03 Sep 2026 11:44:09 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25rU-00022w-Ry for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:44:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25rU-00EqIn-8t for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:44:08 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995d7d-bab6-0a2a0a5309dd-0a2a4502cf56-34 for ; Thu, 03 Sep 2026 13:44:08 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995d88-6ca4-0a2a45020019-d155dd36a92a-3 for ; Thu, 03 Sep 2026 13:44:08 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-48442ea8f59so677983f8f.1 for ; Thu, 03 Sep 2026 04:44:08 -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 ffacd0b85a97d-48448eea5b4sm13617612f8f.27.2026.09.03.04.44.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:44:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788435848; x=1789040648; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=17ue7Vld/bnWjJ/A94iqMxMtWI0yvKdE4RVC/9sdtiw=; b=LfgGPTQQZ3+NY2yBvd2Ivz7Q2XgLDklUWzLkZMQlhsxUTNw6Msz3pMYlUun4YNVbCZ ctNLLn78t0uUYFyCXrmleawslLcTMN/ZObJDIUgFCFEwSSNPbliJqwLbnMYF8cYCdGFF BgD7MjO4TCe4g7geX3CUKwjO+nhR4OCzzZskP8sTnuczar5Hxi9dI3JdFFKxPHKgJVnO fH8ESk/8LggcyL7ZPGAxNd+zMAmbLdPcdGB+H0fL19yMgYqGuV4ud+fmUHXVzcPqDRTA P8Yrkidj2VCxCSVhcNgVg+lsOlWX1gVZ/UCeVzQycoOCJySouj06hia2U1OjEkYBOuGO qiAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788435848; x=1789040648; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=17ue7Vld/bnWjJ/A94iqMxMtWI0yvKdE4RVC/9sdtiw=; b=qd8jVPICEwNgWqVFWuYBUJnWqezgkqa1FvAuGYTOeBM/DeXKCw6srPbDKE+SzP6WcV 0G+/2WkPxTslBcqZ6ZDy0RRztT5GBDjtEgkc1y+AF1Fub4X+csq4XyZ4td5sZt30EDs4 Fp4pFKbnFXlK2FvVS+irOahvgzf2kgz3JPYSm5RZIG+r/bInV1kIU7JhIs+ZN92lyKWc u4B7YPMAhPUPJcTE3rk+dHhXZTo2mRvhue+VYcQ1cdXrG9VPDRElPlPcN6d9cjPosjsu hl8IJDggGVFnJv8iynkZwY+AcPhxXblvyPQY9+27zp8bmhBwL7rsSY5xWQMsNS82M9oO /Skw== X-Gm-Message-State: AFuF++lRdRR+JhCY4yZ7akaaCvg2crPsdnV8TDwqaPukhDs44RrOKofy P2zGb0kklRtQblqEqEcubdrdsbrRScN30OtLnt75jsSpTwaIdgbmwVdKNiFhLFepr2xf6Fjd+X1 dLcqUUA== X-Gm-Gg: AYBFou1rUkEsV///YFg+iVVuGc8Qe0yjMoyJ77rHWuDybV77/SMxPvu0PxaoK4BF76a e9Ttlwjr8URa9ZUmBbElPwrjAZgHN8vM5lV42ixRDAvV0mkw4M9xa2aDx0pNrNpxI2lIPvgE+7H kL8YIeIinEXwunvgk8Hjlvv2ASCxqe1f54TANIOheAIJryxCl0hT+WVXP5tevqPMa/5OQoud6zD NoBPKH3aU5hk/ZmsjhF6sGdvHLdcmQdvgEGYO3ZxffmSFF1eH8Ej991SyYveXbLshUukbgzDJW9 Nern5iBoaHfjO/Yp+o0i6kGA7aXK8XhHvPfaN93eW9AegljbEAs/bURusA1yu3dFf5N7VPbHvho MIXWJmtkIyhXTTGVDA8+K7m6xZ0GpfAC5VAC/dzvy0i9CzA0D8poy9WQsV1gv8kR1od6T+jN44P CkKQEF2s0/IC6MBmvmc9BvtacZIDIgme/nbTMSHlQxbCWxC2dz3irY6EZ7YDalh6SkwvOpuFBCW k/O3hHQqvkSs8vPYj0by4WjA1/i8oJQGigDWSBnebQUD9oR9S8J X-Received: by 2002:a05:6000:64e:b0:485:8226:c69c with SMTP id ffacd0b85a97d-4858226cab5mr4184583f8f.27.1788435847594; Thu, 03 Sep 2026 04:44:07 -0700 (PDT) Message-ID: <4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com> Date: Thu, 3 Sep 2026 13:44:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 3/4] Eclair: relax "noreturn" function-pointer conversion deviation From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Language: en-US 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: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788435848-F34BE2AC-0915C079/0/0 X-purgate-type: clean X-purgate-size: 1720 Like misra/rules.rst says, function arguments other than "void *" are okay as well. Signed-off-by: Jan Beulich --- I can't explain why this covers the violation in mce.c:mce_callbacks'es initializer, but not the one in mce.c:default_handler's. As a result of 6852334f8416 ("Arm/GIC: add noreturn in a few more places"), vgic_v2_lpi_to_pending() and vgic_v2_lpi_get_priority() (both returning non-void) would also need covering. (As said in a remark there, non-void together with noreturn is somewhat odd.) Really before and after this change there's no checking that parameter and return types actually match. I have no clue how one would express such checks. --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -391,11 +391,11 @@ constant expressions are required.\"" } -doc_end --doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void (*)(void *)' is safe +-doc_begin="The conversion from 'void noreturn (*)(...)' to 'void (*)(...)' is safe because the semantics of the 'noreturn' attribute do not alter the calling convention or behavior of the resulting code." -config=MC3A2.R11.1,casts+={safe, - "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1, pointer(builtin(void)))))))&&from(expr(skip(!syntactic(), - ref(property(noreturn)))))"} + "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))))))&&from(expr(skip(!syntactic(),ref(property(noreturn)))))" +} -doc_end -doc_begin="The conversion from a pointer to an incomplete type to unsigned long does not lose any information, provided that the target type has enough bits to store it." From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:44:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:44:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406928.1640092 (Exim 4.92) (envelope-from ) id 1x25s4-0002gg-V2; Thu, 03 Sep 2026 11:44:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406928.1640092; Thu, 03 Sep 2026 11:44:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25s4-0002gZ-S4; Thu, 03 Sep 2026 11:44:44 +0000 Received: by outflank-mailman (input) for mailman id 1406928; Thu, 03 Sep 2026 11:44:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25s3-0002f9-Kq for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:44:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25s3-003Vvs-1Z for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:44:43 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995da9-2eae-0a2a0a5409dd-0a2a450bb5a6-4 for ; Thu, 03 Sep 2026 13:44:43 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995daa-b7e8-0a2a450b0019-d155dd29ec07-3 for ; Thu, 03 Sep 2026 13:44:42 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-485852d03a4so187534f8f.0 for ; Thu, 03 Sep 2026 04:44:42 -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 ffacd0b85a97d-48448ed38cfsm12304727f8f.19.2026.09.03.04.44.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:44:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788435882; x=1789040682; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=LNHaJDjHDuXLop4BrVnZCh2hHHrrJbmdQU3tdMOSodc=; b=g6+z6USB6VLySk4myYqhu5VhvXGI8JQDGplkYodx8h33hZXdQejYNNF1eSNZymNjrF xbX0OgXhXVjzY+Uhq5tkjr5dj1bbaLfKiNY6wc6/3CgcCFnxBffxUf9raYUbFGzQol5a 3oip/cOpye00nf0ruQydGwagEJ8ey2ehsZmN66dN48+B5ukxvBZnrY6kRv+x3gbOrb9o dRbN4TX7thrOIRhDpgSGZv4DZ9hDm6GmtblNK+eg4w5bxc2sDBMXagS56ue05QPKNdKQ nsEfdvmiAl3ga4iT4irY/b/GLoegRHdGM54OXg1brbIYVid7JRJVzCpYR+CiJAZukkix Ly8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788435882; x=1789040682; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=LNHaJDjHDuXLop4BrVnZCh2hHHrrJbmdQU3tdMOSodc=; b=KktlRRIukIswDDLdTdm1IpQI40D7oqy6QlATNimNZVcejDpLxnBQq5RFTyQb3KjxS9 7cpDhvnb4dX5sAvd6wZWmDa0bRBzo+UsZYc3KDGRkG3ACi3cqBdbozfVVG4fPXC0kmqo ZpQFHsQJF349bQT2vrQ//7Z59D2jrGfm5TgIGlwaylFYvuAZKXfR7r8ObUTOzhJklCWC 0DRpz13rkSDUHI/6+nknuGj9NDa+hubsv/eSYXWUKSfrqm4H6QxacucnnqNr7/x1ObNx 05ss+H3n4zw3xw0SYlCRL0sD52PENiEgoJeEslmY93OxTxhvfIbUAGln+u+K3P6KPWYK Q47Q== X-Gm-Message-State: AFuF++kLdqJ4+S0oTha4cVk+zfvJGY2XYz26w+6ZiEUpV8KSA/X0lPOP 7Y/V/4Yybt7717bpm/4xhTzci+GD6w81ALChxLCJiVvwZcYt3gHptZxf2q8YNuOFoB5sNu8gMKd qwJ2BhQ== X-Gm-Gg: AYBFou3DW3vrTmOseMhmqjUq+UQi/J1TnLgUHmv5loE96nDQKcXL5xOQVl8OYqRn0DW /1fpli6ij/r287y2fhpCzsoyMFZb5A/dzWQBm+l3idJt0MoyLlZaffoGT8aJl7WqPbasuZINVbi +2Z9JY8siIcrA/jNYX655pIcz7X/Bg+OAx4BHNIGYHuS7HlaTtbZhhIssCj5ODOmEzOZ/2nv9n7 yREjcwFNXdZfKzC7qP8OCzaN98zfQ2l4wCfzBSUhukYZxODy7oNDMkDdH6HDGYx65vkkeQro9Zh UG0xqIkgoe3n6+SegiIICOISJIQPpdGxQSpnxfa0xxQqc8N/f+W1tbfR1IXXD8EhM4ZlRX5WVjn naU3SXbSIFjp+SI0UvhrMzbChwov2XPmgrqK3FUjCYlF2VZ94tC2k85BWi2rm0zxQIhbOmrD6M7 8EG8C3ZeoP3FMjhW9nPF2neBhDtOPIC5H8LBAvAlyM3jnoAlEwsrvKaXoK8naqI5HBuYf0rAGfN Dz+1fBvgPmZaIIyRhsQv4nPf4bF3FaWE++y1dX3H5QJNXe2RAvy0KH2rblnqN8= X-Received: by 2002:a05:6000:2285:b0:485:847f:fd82 with SMTP id ffacd0b85a97d-4858480004dmr2911222f8f.8.1788435882459; Thu, 03 Sep 2026 04:44:42 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 13:44:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/4] x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Language: en-US 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: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788435883-18CCF9EA-02260BBC/0/0 X-purgate-type: clean X-purgate-size: 698 Misra rule 11.1 demands no conversion to different types at all. We deviate conversions to long, unsigned long, and void *, though - leverage that deviation here. No functional change intended. Signed-off-by: Jan Beulich --- a/xen/arch/x86/machine_kexec.c +++ b/xen/arch/x86/machine_kexec.c @@ -121,7 +121,8 @@ int machine_kexec_load(struct kexec_imag } code_page = __map_domain_page(image->control_code_page); - memcpy(code_page, kexec_reloc, kexec_reloc_end - (char *)kexec_reloc); + memcpy(code_page, kexec_reloc, + kexec_reloc_end - (const char *)(unsigned long)kexec_reloc); unmap_domain_page(code_page); /* From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:46:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:46:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406937.1640102 (Exim 4.92) (envelope-from ) id 1x25tI-0003E5-7z; Thu, 03 Sep 2026 11:46:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406937.1640102; Thu, 03 Sep 2026 11:46:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25tI-0003Dy-5F; Thu, 03 Sep 2026 11:46:00 +0000 Received: by outflank-mailman (input) for mailman id 1406937; Thu, 03 Sep 2026 11:45:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25tG-0003Dq-U4 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:45:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25tG-00EbSO-AR for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:45:58 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995dd3-bab6-0a2a0a5309dd-0a2a450ba486-40 for ; Thu, 03 Sep 2026 13:45:58 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995df6-b7e8-0a2a450b0019-d155dd2fc1f8-3 for ; Thu, 03 Sep 2026 13:45:58 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-47fe89fb333so1468861f8f.3 for ; Thu, 03 Sep 2026 04:45:58 -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-49ce5941cb4sm53273345e9.4.2026.09.03.04.45.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:45:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788435957; x=1789040757; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=FTmFJ/wHpKzSqbg/irj1Tfv5FuutXJr2ik6F9XpbNRM=; b=IUJxkmray5QWLpjTNntlVbSL0LmEvl4Z3+mDhrovAw26/NHTLt64rOYrYW7Q2eJ33Z vAuAjHrZeN5R36hJeH4/Np7Ljzym28OrGxLXCrOjg+cxo9jk9mjwYjaqP6Cf4w2rmxxT 5YHQf5iG5fwxAwsrzxFZU94pdVNQPDeIML00yOh9RcAVR/dDqcoimY2rz8PD0QZsaAlJ yszch/desc3x9K7CtPnYlLEVdFHYJCyRAj7l1dZG+cMUPOx2yJXKPBQrzIh6P0V6nw3+ LeYRgNxvWVIkHlUNlA6RpiXqsxJ+q82lmKIm9YqLEBfOANjiDsiaF0AGmjPeX/TsfUjD WKJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788435957; x=1789040757; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=FTmFJ/wHpKzSqbg/irj1Tfv5FuutXJr2ik6F9XpbNRM=; b=kDJbZAU1UPmIyCKG3iHSD06or099TmHJH2eabWtLtdB5tZtcN+FQSEw3WBkuev0LXK TJbP0LVWdyF6gcYIo9NwEO2XvnWG2RazRXIfd7V90cgV/f7zEe8Za9NBH/0wYEA8G5RB 2yaGMgAW0jds9uCZ8Sg48NUXkV14TJGtkEpsvWhnIp7ofuoIiyseaFl9+Atrh2E8yME4 G7qIxW1YqbQHEMf1Ngh+9n5LY/hNHc2vBlo0U7t/FCMce6SY9zyj98WVvsW7oHCejtuD V6b0RrdUPPHYGwuQmnAg8llPuym60BXnvfgHvRfr7pvb3zVFnBNac6CTA99YaScjh2o8 gqMA== X-Gm-Message-State: AFuF++mFHCANJrBQnjBi9DGA4OKhk5olJUQsluqYIeA6rLBFSnZfhTyC PmtbpDqluZQXChYXa22e6jQNzwA9mBuNKbJBTt8vVXzFU0sYzNpkH6vuirXRl/U8cssofRcpbWx Ou08lww== X-Gm-Gg: AYBFou1+SLdA97e2supKKW/vBkIWeCNw1HUacOSWe/8ZIDAsoiQ/9k2oXGqOkXqOdFU TiImbYNJXukIc3NC2BfeYH++gOR6oYd0ELFa2GE4NAWV76fLL+t0S2Q3qBYr+1T3PaTexSt8yxn IyfsoAIaG3rQ+B+FDIYFNVoZacWpz/7nWgpD9n52oJ+VDEqzVR8OaIe/fW/AYmHDWfUwNvI+JFQ eEboCuEV+u5cjDbzVBJK7DuhSNZfvj5lQml6aWhLZ1z24qgeOSQlQ3mDg0s39TD6vk6hR4Kxarq XWKWQwUh/4Hxh5tnSxdPf2XiypdLi6FiuHZfjJWammRLqJj1P/VU911JjFTsNSgZQWHGypO7n0B ngNM3tLRb4mHDI3+eif+IE5vxqZb6MSDhDZfdR20mgrob+l1MlrMw/Hi1xXPeGtN20lGJEvjU2A jlthVwfUuxqs/eHIGKKNhrYso3ILqSte0/aWwI27aflD9XlIiqkEejthgu96e3ydnmEiMdPxxyN zywbjR/Gs7oPzmYeXlDkjB/pAcmMEDOl7wGX57JI1+BTs4uM0Xg X-Received: by 2002:a05:600c:45c4:b0:49c:e1df:79a4 with SMTP id 5b1f17b1804b1-49ce57fdd1emr211511515e9.5.1788435957706; Thu, 03 Sep 2026 04:45:57 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 13:45:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] address most remaining rule 11.1 violations From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Language: en-US 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: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788435958-A84CB9EA-D825E62A/0/0 X-purgate-type: clean X-purgate-size: 407 On 03.09.2026 13:42, Jan Beulich wrote: > "Conversions shall not be performed between a pointer to a function and > any other type" > > The few ones left (x86_64-allcode:1, x86_64-amd:1, ARM64-allcode:2, > ARM64-amd:0) likely need dealing with by tweaking patch 3; see remarks > there. As per [1], that is. Jan [1] https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2816360844 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:47:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:47:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406946.1640111 (Exim 4.92) (envelope-from ) id 1x25ua-0003iV-Gr; Thu, 03 Sep 2026 11:47:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406946.1640111; Thu, 03 Sep 2026 11:47:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25ua-0003iN-Du; Thu, 03 Sep 2026 11:47:20 +0000 Received: by outflank-mailman (input) for mailman id 1406946; Thu, 03 Sep 2026 11:47:19 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25uY-0003iF-Nn for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:47:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25uY-007G3V-4P for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:47:18 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995e43-2eae-0a2a0a5409dd-0a2a4507df56-4 for ; Thu, 03 Sep 2026 13:47:17 +0200 Received: from [52.101.66.62] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995e44-b4ea-0a2a45070019-3465423e7fd2-4 for ; Thu, 03 Sep 2026 13:47:17 +0200 Received: from VIVP296CA0096.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:35b::19) by AM8PR08MB6577.eurprd08.prod.outlook.com (2603:10a6:20b:355::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 11:47:11 +0000 Received: from WA1PEPF00009B3D.eurprd05.prod.outlook.com (2603:10a6:800:35b:cafe::b) by VIVP296CA0096.outlook.office365.com (2603:10a6:800:35b::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Thu, 3 Sep 2026 11:47:11 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by WA1PEPF00009B3D.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Thu, 3 Sep 2026 11:47:11 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DB9PR08MB7469.eurprd08.prod.outlook.com (2603:10a6:10:36f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 11:46:36 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 11:46:36 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=PkrnKjbCFQSqDNOM7hGIjyH+wRjoGm6c6oGI+0Zhw83fC1sWiiwnoVlunt/ZEvuYTckl/Tr8moicTPMr9G7VAlyxAMF0/aJ+jY7RtVd5NtXmC7weO9d7TTybAt3FuQYB01o6APi7vLhIbMhG9pL8klTlOhQ4YjAhRgEvtDYeqnR/qORjbLYCSluNe2LqdAG/7Bn8Xq3d4V4MJt6ELyLzn1uHKVRjeU1b+wtQPutdP+/COasJ41Y1UqT+YQSZykowzlmsQMpOjXLlQBtorqWc3uoZd/0edIEHIuOnZoAxBQgp7uw5gW0YE70CFh2T8+j4NP3g6O65iP2o8qkcL65i/A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sl6yVmaKVIb44L0qweWx8iaEMz7lkk7f+fpOFw6IP8E=; b=VELctVyBd0rxGAh8+5xMrozk25RERm3qVfiBJlemptUi2RGz4b0js0jlnfM3PobQQvzvUhonCBnfQ6tAP7A7iozuHgu8mlFJhJoWBISUgLlZEtfQiRCUbLsrgCRA3DfoTe9ad1SxFKGVO4Q0d+TnphTpHeohXFGDz1X0emCNdirj23eQQ/LWBwHIcXnQFnrsrxG8/snYI1Nb3Cq3D2fz9oJGayz6XZ2NL5UV7Y2XlzSgLlEYWf5H+1J+zHJKH1401tmXpvLH5amc2aW2wlaxR5Mueyh4EurxsUfjQnosEIhBn4bYxSvrYBqAUF10EmVZjI+CtDiDcySRce3QaLquoA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sl6yVmaKVIb44L0qweWx8iaEMz7lkk7f+fpOFw6IP8E=; b=l1VzbgnyWCdylMBpAGx8nbxBMAD9vSKtMXBSIKdYCZZiJDJpQxToH2rn7X5Wl3db8VbHC3929jEUOdsk7PU/mm+9DNCeiyuveD0/BNRSxrqA809XSWIXa8689n9zjhj83oR0wJUkHPQX3Sol3lIQ4YBMY4twsFG1mrVOFK64l4c= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QLkcymhwSdH87flWDGZEME62JM8rrFB/Ed8roHyUetedhSqJIsARwKtPGpsf9Q91D/UTuCC2hRdy//ICl9luHtwuatXp3pGLpPHVyrnUZbwmMlOgXlVYyevyI+/jObt23ccE+d6xWmNfnacZW+AvxIzjbkq+NPLvfeDSvXpBgruMXHZ4pN6NbDoxdUb9Fo1eJ6i/YHHMLuplGO8LKiOxXfJg3tj/L81wJQmi1uVrXR9wAQ4ZDT2abzZ4qBjk8gq0eGjplH/xdQ5vdK3qzBJ8Pkn/HaUUnzzlIYnZbKMHPQfpatjXOX70bEjEJBPx7KumINESyKONRMGWm9RvfS5ohw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sl6yVmaKVIb44L0qweWx8iaEMz7lkk7f+fpOFw6IP8E=; b=LXwH5/h7FNOm+WymXu5q66hi8VOpR7l/U48VwLgrqUnj+SDcWJDeLMiMYlrTNFYYIKkrI9ga+3RmWjO2ebXpVvIa+/HKCEn1bbcn8mBVfl2YsqNJwE8vj+XwyDqIy2rsPBohiEW8xYTOcIA+9ucwIKjK9SOAjUUnPaqwnT2TZmaG4w8yGzzI8iwgLVvenGquCQTB3L7VS6BxF7/Cn3bUh1tCLwetMBpq/sh+VqpHcg9rqxZwoMIavmU+wyDmlgHhlGzJmRTrPe7U9H9jChTUgsw5SVqEnLuMKJpwG4vArZ+oaIYeU7NEJkYHg6tl/aTtZZu5VmfTyNjJpGwG/u/vqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sl6yVmaKVIb44L0qweWx8iaEMz7lkk7f+fpOFw6IP8E=; b=l1VzbgnyWCdylMBpAGx8nbxBMAD9vSKtMXBSIKdYCZZiJDJpQxToH2rn7X5Wl3db8VbHC3929jEUOdsk7PU/mm+9DNCeiyuveD0/BNRSxrqA809XSWIXa8689n9zjhj83oR0wJUkHPQX3Sol3lIQ4YBMY4twsFG1mrVOFK64l4c= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Jan Setje-Eilers , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel Subject: Re: [PATCH 1/6] xen/arm: Fix evaluation of parameters for SMCCC calls Thread-Topic: [PATCH 1/6] xen/arm: Fix evaluation of parameters for SMCCC calls Thread-Index: AQHdOUMNOJRbm+SGnk+cDdOr9aCdbLa8wS0A Date: Thu, 3 Sep 2026 11:46:36 +0000 Message-ID: References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> <20260831121944.2908139-2-andrew.cooper3@citrix.com> In-Reply-To: <20260831121944.2908139-2-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DB9PR08MB7469:EE_|WA1PEPF00009B3D:EE_|AM8PR08MB6577:EE_ X-MS-Office365-Filtering-Correlation-Id: bca28aad-71a0-4dc2-81a8-08df09b11748 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|10067099003|11063799006|56012099006|4143699003|22082099003|18002099003|38070700021; X-Microsoft-Antispam-Message-Info-Original: eQzTLnGTUNnLqYqoBuXzciFoFnnhczcuVcv2UUcr4DhTqFW32nmmEsMVNlhGG6NocFi1d9Iy42BPyGS/N7bXWMFU+pcuBJ7WAoenO1EAOZJcTft9QOQUu3JR9kRW1tnR6FKj5pXX82kaykOqwGQHbu9c90vCKWziApVYFgpeJnHuF6B1haCOY4lfjPilXOyYzGW368jhCHCBU0dE8PJ4jZ/61rR3l5LwWXibEoBQ3uNBlWf05yricHLOyKIz27XHQq352qlNMAJp0/VML6XcG4xDcV0wcCtT/hcLhtFN9PDcxKXm/DaZFeSd6RgOLdyduSSwPe6mYAsU1YRjEj4gjw0c6N1aZ2IJBOu7HuyrKnegjB5r0CJnl3sLvo+zM1IJVRLMEKK2AlAi46zhxMPnRSP8xRjg6ksmjZbq21gNF6HMa1YR49zPyYapu5muDonT76QGrq6k1dwxystUjC4dR/mLKODGEHLMbC6Fq8XUFsEHpZfkfiFsFIILZ+YUl7nDcmkLaHMVQcKk2SijZv62qc6V/Ee/X4GKSRoYiYfLvGEXICmzPEeOpSCOaQ9zXTTLYD7b+eEcTmwi/jvpTDRhpndfV1fTCgWnFyo8kxbqmGaJL9Es6HoVZdSWPat6h3EH28hdFNC0WaMGdYWMWNkOB8lde+3M3hl3TWwdclIhpL/n1DsQVXaYAaP5iRjOHW1gsl8JbrGkvxruddcg3/EygMvE8JAg7tVGCnZk6AdJrOY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(10067099003)(11063799006)(56012099006)(4143699003)(22082099003)(18002099003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: Au3vfKpQEdcfKnxt0fS1aAvQpfvvfz4fabLnbPnkCCA75PbXOy0y2VUT14NeZuf0IZ5MJt2UiLTVjJI7Bq4UGYM1YXxkNOkFmpSNcUWFKik66uo6CzEWpn/3wlizUAVmDOiEccKyPw2H5UdGJABSNRGkz30ggNKzUHDEls36aeXdyF1RJmFDcmFii5VJiUkCjphVwrrN1B25T6UpiehZAO2/R0zgCvYm84fDzUWKSk1VyCPTBgpbajTpsNugZC6/zDLoX9WOgiUy3GS07VgZkkBrU0XtYLme7EM4VW+MUlr/aw1D5efsTtU/w1b5qUaeeD4kkLZlvj6R442ZJENcwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7469 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: WA1PEPF00009B3D.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 4377f0d3-b800-472e-8f98-08df09b1027a X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|35042699022|82310400026|14060799003|36860700016|1800799024|11063799006|10067099003|4143699003|22082099003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: DiDgG9IGnHif2iNTimg9iKahuPuI6AIdleEZlof7YtQwxwjZBdYxCXKgTM0HiNKQKJ6xzKymPV7xvXGEhnnUIz7mtDYLv/irYGyiQbLWzPQz3lasqv5rGpQhVLlM2wOhk1tLWzUtLBto8AxN9U5iVvOyMQS/X2H84nCMw4vh4yhcZjgugQKUyNAjtGtrcovMzLeX5Gk00qORsFUVOv2uncxzKiReKqMqcEudAmyvGDJOQQUNHgqoKC9xx+qFNgyv6xLzGy/HzvHMI3JaCt65WDB3Z1nJcwH1H8H7adPw/taLDl5ZofXGlV7oDtzL/UtkhTvLIXFVj8o9ELLvQz9v+Xcw4kqZ4OyxMEJJ2CU/3GBpR4r5w8B4HndeueVaZFiECPtI2Hd/Sfkzc/lGF0TFvgNkaroRVUqu8dNsqSYcLxqlwRGc8/cIueVEiojw7dNPeBl8RCi34V+PAlEJoVpcP64CRY/UWUkl4AMOb+wkLCEpoCAs9d2szRPNKmJTjrjNlcn4z/NE10JvFpztYrMKojaiZYF3Q8GK0oio0gFNJmh4TFlddDthGNddD1JoNkjaXtV7HFYsYHFgqMSvk8RgA0PgrTcA8iXCnrShz5tDz7b/cbz6kauVB2wJQGYHOnAGybJ9fxiWtkBMIRjTaPKdUauG8EAyT5SI+FVWUaWXNiQ= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(23010399003)(35042699022)(82310400026)(14060799003)(36860700016)(1800799024)(11063799006)(10067099003)(4143699003)(22082099003)(18002099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: AhJtW3O1IMA6kcDP+L4uhjTLVNJW9wmuHkibHd4AlByVjZ3AQ4dsG2WSWVWkwowCNUgZmeBU7KXbLMVoz+f2WD7XDVu+8K0N0Kkxh6aVBCcE8fj5aU483qZnYe7n6Q/qNpxHWWDU7YIF4/PkqdxWsrdeLhNmTjWQ7FsYkwN5+FPKqmeKVjVgeD6POAIf/roznjfAjRiZJB/GlU557XmbfSzPn0Rr8tDUGcoA9TXjxOKfP2Pc9O9eX80HjwtGTllpyDpewV/5qFoehJ8egTc3svX2ykZe8laxOeKcXWWonE/dRI8BvswgC5LbtmAe/Za4uWxpizIoMQ3FgmOgDQNrkmp29dl8siYvE+xULfaarkyNyU0K844aLIVVISnGRT3tC8E8MSNF6QgXb+I19ZEi2dQk7l3Sse1pw7fPNHGXiUt5VbeRvnzGtSq5DllCLTRX X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 11:47:11.2255 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bca28aad-71a0-4dc2-81a8-08df09b11748 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: WA1PEPF00009B3D.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6577 X-purgate-ID: tlsNG-ef75cf/1788436037-A46CAAE4-475EED09/0/0 X-purgate-type: clean X-purgate-size: 5146 Hi Andrew, > On 31 Aug 2026, at 14:19, Andrew Cooper wrote= : >=20 > Contrary to what was claimed in commit 67bcf5eae709 ("xen/arm: Simplify t= ype > handling for SMCCC declarations"), there is an important reason to retain= the > intermediate variable. It is unsafe to have any logic between the assign= ment > of the register variabes and the asm() block they're used in. >=20 > This logically reverts commit 67bcf5eae709 ("xen/arm: Simplify type handl= ing > for SMCCC declarations") while retaining the conversions from commit > 7f15d5d13221 ("xen/treewide: More typeof() -> auto conversions"). >=20 > Adjust __declare_arg_0() to match. It happens to be safe because it's th= e > first register expression once all macros are expanded, but it really sho= uld > be consistent with the others. >=20 > Leave a comment explaining why they must be written like this. >=20 > Fixes: 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarati= ons") > Reported-by: Jan Setje-Eilers > Signed-off-by: Andrew Cooper Code looks good and my tests are passing: Reviewed-by: Bertrand Marquis Cheers Bertrand > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers > --- > xen/arch/arm/include/asm/smccc.h | 31 +++++++++++++++++++++++-------- > 1 file changed, 23 insertions(+), 8 deletions(-) >=20 > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 62c6985e7315..53cdddb690b7 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -108,37 +108,52 @@ struct arm_smccc_res { > #define __constraint_read_6 __constraint_read_5, "r" (arg6) > #define __constraint_read_7 __constraint_read_6, "r" (arg7) >=20 > +/* > + * Macro arguments MUST be evaluated before being assigned to a register > + * variable. > + * > + * This is manual register scheduling for the asm() statement, and any o= ther > + * logic to evaluate may clobber the already-scheduled registers. > + */ > #define __declare_arg_0(a0, res) \ > + auto __a0 =3D (uint32_t)(a0); \ > struct arm_smccc_res *___res =3D (res); \ > - register unsigned long arg0 ASM_REG(0) =3D (uint32_t)(a0) > + register unsigned long arg0 ASM_REG(0) =3D __a0 >=20 > #define __declare_arg_1(a0, a1, res) \ > + auto __a1 =3D (a1); \ > __declare_arg_0(a0, res); \ > - register auto arg1 ASM_REG(1) =3D (a1) > + register auto arg1 ASM_REG(1) =3D __a1 >=20 > #define __declare_arg_2(a0, a1, a2, res) \ > + auto __a2 =3D (a2); \ > __declare_arg_1(a0, a1, res); \ > - register auto arg2 ASM_REG(2) =3D (a2) > + register auto arg2 ASM_REG(2) =3D __a2 >=20 > #define __declare_arg_3(a0, a1, a2, a3, res) \ > + auto __a3 =3D (a3); \ > __declare_arg_2(a0, a1, a2, res); \ > - register auto arg3 ASM_REG(3) =3D (a3) > + register auto arg3 ASM_REG(3) =3D __a3 >=20 > #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ > + auto __a4 =3D (a4); \ > __declare_arg_3(a0, a1, a2, a3, res); \ > - register auto arg4 ASM_REG(4) =3D (a4) > + register auto arg4 ASM_REG(4) =3D __a4 >=20 > #define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ > + auto __a5 =3D (a5); \ > __declare_arg_4(a0, a1, a2, a3, a4, res); \ > - register auto arg5 ASM_REG(5) =3D (a5) > + register auto arg5 ASM_REG(5) =3D __a5 >=20 > #define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ > + auto __a6 =3D (a6); \ > __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ > - register auto arg6 ASM_REG(6) =3D (a6) > + register auto arg6 ASM_REG(6) =3D __a6 >=20 > #define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ > + auto __a7 =3D (a7); \ > __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ > - register auto arg7 ASM_REG(7) =3D (a7) > + register auto arg7 ASM_REG(7) =3D __a7 >=20 > #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) > #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) >=20 > base-commit: 79225a0c77e13b693b4d2b903a88289704b79db6 > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:50:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:50:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406957.1640120 (Exim 4.92) (envelope-from ) id 1x25xE-00056l-2K; Thu, 03 Sep 2026 11:50:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406957.1640120; Thu, 03 Sep 2026 11:50:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25xD-000568-UU; Thu, 03 Sep 2026 11:50:03 +0000 Received: by outflank-mailman (input) for mailman id 1406957; Thu, 03 Sep 2026 11:50:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25xC-0004mF-Ki for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:50:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25xC-000oCa-1S for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:50:02 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995ed5-e002-0a2a0a5209dd-0a2a4501b102-42 for ; Thu, 03 Sep 2026 13:50:02 +0200 Received: from [40.107.162.6] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995ee9-5984-0a2a45010019-286ba2067687-3 for ; Thu, 03 Sep 2026 13:50:01 +0200 Received: from AS4P251CA0007.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:5d2::11) by VI0PR08MB11326.eurprd08.prod.outlook.com (2603:10a6:800:300::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 11:49:57 +0000 Received: from AMS0EPF0000056A.eurprd02.prod.outlook.com (2603:10a6:20b:5d2:cafe::98) by AS4P251CA0007.outlook.office365.com (2603:10a6:20b:5d2::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Thu, 3 Sep 2026 11:49:57 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AMS0EPF0000056A.mail.protection.outlook.com (10.167.242.120) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Thu, 3 Sep 2026 11:49:56 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by PA4PR08MB5888.eurprd08.prod.outlook.com (2603:10a6:102:e8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 11:49:24 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 11:49:24 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=coJgUUaB/fl2XxXZNDOgZngk5dU0HLOZc3+m79F1yQBiUxEEOZjnC4EHmVjJBoZtgGmpcA4GgEfjc/eh7tli/c9QbhYMGQYI2NMsHNKFfRGfoZN7/t/9vewIkalHGMmuQjLknLsT2RxvJMGtMPIqnoBtAAY015lG7T1K+jeaLGgTppTGDHQugpj3hrEuFEpVcPvItSbo1/XuDM1znzs10JpMnlHujd4CtBbR+sww1Hv92Pl/loY0/QGft5ecxyNkWVM+dna+vSv4UbClPlE1HYt02ZqdTdbwwG4jDjQlkkNLO106Ne4APgvXW51tU2EXmPDEeGAcvYEtCIMzivfnvw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2xpmOnyFDbq9RXvXSHv9f63mxmbv160i/LJZm6JCLyg=; b=WvownICTyH5iRWHgLiIqWvXMYt7htp+XK5ER1aQyAhZ5Ktg16Ch5f0Wk6VhBityfYDydW5AN928+n/ANuRxEFn27A9F0ixscoMQloIFAVCF+esnUpXqcasbpOoqyYgYweduIm32X2aV+ilaUYdX74pX4zqWciIhD52HWzgG2vxtstXF8Ofjf6N3DEz1I/w4769xsid/TB7DdvQ/qpBH30UBbxsd4HGHZA/QzjtQChhy/Bu7ECPV5WUZnZUWS1b2yZTFH5uTkilb6yGJZQ/3cTt+It6pB7FT9a2A04HslPYZxgmPt0PdJ4iff4kO6t6ckOVDEX9es63PRQqU64TBgWQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2xpmOnyFDbq9RXvXSHv9f63mxmbv160i/LJZm6JCLyg=; b=RDNFH59C1hE22Ec4Ec02sqR49i7/daVZxwpH1n7JUu1+BfAmhxfT/+PHS/FOffgfoKNmS897FhCU4e7+HCy6/UZbXN6pTQgMpyo91/5ikm2b/IPq4Y4zG+hs9QLgExiWhiEJ05whA0OUOWx2ksnsasKSqK5EMvsCrPqvp+jbTMA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TqfSflDcvCCj0Hr7Na2WFYpapgEB65bLPDAg0Utt5RDB5frXze0yJ0zhWVT7FNUKQuTsFKUu2+v5YRHXHZA6MSEEmX2dZvDURexcE1gtbEe0QN382U1he05LfIBtyqyopESscMRd5eNo7v1R3bzvHOIskpMuaCi+Cd1JHqCtvt3Y1zJJwTWGt2q1ksuEK2rixijBZ2qyemwGDSEMsZcJs0ctnw0lRlNr9xkgpmaFx9wLJU3GGmFbUm6vU5eFQiKFTcJqYr3Fr6W3LzCm0YDOMGMann7IAam6t3UQvHXJ3hu5dO5L8Sz49/WKWzv/xCnRKD2wYtyxqODcJkrP4WHxEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2xpmOnyFDbq9RXvXSHv9f63mxmbv160i/LJZm6JCLyg=; b=m8v3roQMf6F4uC/qxhBl1a0EgFgGzru3iCxJ3hVk07eNl+ZT5J0QEygZkL00jO6/yo6blsvEuiQ+3ZJp8srghp1oQYsedMgjnB2/hNr9bRJCZ9ULtUiywfhIklNxaemiAEIk00OpLK8/gW0coLW2v2YGq2KauiRkC8A9w2uwmULb1fUUah1qWSeR0EIGJqGq9y5L426HhwDFFWRbSMvB9GHQ9jZmrKe8bN+6DAyF19FD1xREk6lXrGCcwff7SX0tCIQMKT4PXEoQHB1NdYwJmb0lgcTzqeKqorgWAxYFkiTLk0ewgDDO3ZMaT/r1IaF2KRJSuK49JnLEYyx9vI1M8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2xpmOnyFDbq9RXvXSHv9f63mxmbv160i/LJZm6JCLyg=; b=RDNFH59C1hE22Ec4Ec02sqR49i7/daVZxwpH1n7JUu1+BfAmhxfT/+PHS/FOffgfoKNmS897FhCU4e7+HCy6/UZbXN6pTQgMpyo91/5ikm2b/IPq4Y4zG+hs9QLgExiWhiEJ05whA0OUOWx2ksnsasKSqK5EMvsCrPqvp+jbTMA= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH 2/6] xen/arm: Introduce arm_smccc_guest_smc() Thread-Topic: [PATCH 2/6] xen/arm: Introduce arm_smccc_guest_smc() Thread-Index: AQHdOUMMzhvvHg/ZrU2g327RhKMYgLa8wfSA Date: Thu, 3 Sep 2026 11:49:24 +0000 Message-ID: <3AB8A50A-7BEC-4B70-8EB9-5BD2AD31D1DF@arm.com> References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> <20260831121944.2908139-3-andrew.cooper3@citrix.com> In-Reply-To: <20260831121944.2908139-3-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|PA4PR08MB5888:EE_|AMS0EPF0000056A:EE_|VI0PR08MB11326:EE_ X-MS-Office365-Filtering-Correlation-Id: 8dd932a6-3a5b-4f12-a36e-08df09b179eb x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|38070700021|56012099006|4143699003|10067099003|11063799006|6133799003|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info-Original: LcAaEzIwsvBRgaZH8RTVJXyFj9uYk4tOeelENuVn/gB364uvOvghidl3ZFr+cz3X5nlhCCVIFKLAfe/TrQQezFKUrprssHC7guZNIn6+MzDJfOMFcY/kt1Z1CxlhytvZIDC7bkE9aK+WIuUb5SVdsGxLdjvlfPnwt2dOrtoiE+msDirpS6k6wBakWSNd6yQp5hjjkSl95cZc6xXqaj2MpUMJwI+1ZOx7v8vDxJQyg3PccNG7CMmVrw0h7vWTUzIGsOhCxpmC2opMfr+h1ku+Pqhbj+eJD6KgdifsfEww7D5p+VGBvPxJx48X4vTKT17IgingFwpUm5coQGoAaC3MUs+2OyEEm/Fd7AfZDoT1FU7DKWf/hGF8ogC52p7qjT+StYMHCpjS/8pz0c0Qf1q9cJtLvNQ3ER924rVjB/p4z11yQhUHv2Fy5rODlHh5WwMeR5EvRrInpzMM1v1vkevBB5NxLIQyf7kTeipKb5snRZCkK5Wb1JH3GOWNnNFUPD48qK0GkJLLerqPjl3zXl76MpQn69rrXYNqO4dKL5j7W5sRDkh+5ETMwlc/Tvb/AOzFUFt8DwHoWG6r+94F70zZ+Tq87FX22+Wao6xBq2rXu5xdHWJKIOggsR3oaS1Ywmxp0kpuHZIamnQLFd0x+7HDCBmiCrc4vkZoj2LSGdQkxK7nJ+oTOHrJmHJ+0JwXzff2u8RTXar9g1au4M2E8NtSVej+GbmQn6oRJQVcEVEJpKU= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(38070700021)(56012099006)(4143699003)(10067099003)(11063799006)(6133799003)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: zoJmok7RicK1vat/5EEPz+EgedWVQNMHvjGwrUW5nkCQRpQh0FaIsGL76NWgJmPMnQDu8la2sUXwK6okQzJdJcetrFUehGuZt2YnAnvzcp/myfl97irUU++LrGBTCN4T7v+yd416y8CdZyvf+NZZG/yaJ1EeFrDpWaX5N6p///a58qtMiDgDqZTb8+JR+XfWwbIwiCWfpy6Oq+cj5E/+ZDxBPGupG6l0Od/KocfFlYAOiLL6HF2S/u0iCtaj3nKpbz/Zk5cPvUiuN3UOcbFxxp9zF46oWGXLDXG/cWv7JeyaNK3bkPOgqtqTvefrbEFtP9iiBRhkTEi2h/viGa2rMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB5888 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF0000056A.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 383686ac-c281-41ea-3ef6-08df09b16666 X-Microsoft-Antispam: BCL:0;ARA:13230040|14060799003|23010399003|1800799024|35042699022|82310400026|36860700016|376014|6133799003|18002099003|22082099003|10067099003|4143699003|3023799007|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: ZqFwDAUzETfkYxPksHPXA6oO3l3CFa0+hn7mE1QgjWjbD9MNSCrAGj4ybsN7y19aeO1y/JdWJ4YE7jFJwpPitXsdjG/3iQnNWeFoNzlq/33KFM7iddPto6ezw349SRq5CyoilZKVXrg5KKjkQM6eFi9hNnEFc3wZVVosQRAJhhRxtpLOQ6hGc9OF4K3/0Bk/F+Jele9RY4vbg/wF4d4SP3laY7WRsKQU1PCIjatzCUjY0UhTB6sUkHhZKJoOV/1PYt/quavdV53mmHE58rUufHj9YUDTbJ1gu9fscecweIkHWjgS6AcQHivBdXOC2Z2JFbP4u5x8p0BU9Y+XKXXFmwxm+NV56hqn40K2LuBwEp2cba/YF0xpXesa6EaVkzew+C14I+G64ZGqLjy5bUQt+3Amv2qAgJJKJM2s9AIv3bcC9UXqoGlK+YL1EiH1/1kzRNDStRJGNlu2CoU/ZukKiTfjW40s9aZss70qrLK/TAz/Zeh0YbxXi+nzVRTS5XQ+VsM9KeY0bpmrtWZPSbRBtYaDSl2KgdVePEGZMMSeRnzENDvmO3cBPu8AF+m6u3FzSwr7P0ldZj2oivG3ZGyC4gNIR1SAGGXW1DLUL9+8jfAhvE4IVfl/2k57m/TCdd9c/YdCsXuJ6DcVBM5LryEe4bHl3RQZqFeggP1Yn53dDQM= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(23010399003)(1800799024)(35042699022)(82310400026)(36860700016)(376014)(6133799003)(18002099003)(22082099003)(10067099003)(4143699003)(3023799007)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Ll4R3LzbcHpbxK1BnnUQG1G/GHKSasBksg2S6YzaGbgWG8FBPftOgthrAv9ZJ8DinINSPe4BZZIB1/znrkcuav6I/9u/Z+VKNGSeqNcnBSyN6XgeWjKdd796K1GeQd+hMeWhaVgTcgxcsREIbqBk9z9grcedgvH27rSYCe3jWyWy/ijq4GI6coONbijSnpMeQGbFYUpkRNdWRhgTuIz9PDIeS0WyFuB+lnPZ1i5wi4Y6ctV0ByQHjmnUHuhRWB45fzGcW/L08+8GTLcMzVX3ZoiT5AriJK+/Qh1AxaIyEe+NMXmNu2auoX/ORBOe8LI8XF48CxpsYL86EIu1AX+GFauYeWHN8m9mgcYsy1RfroTE0OsFrd2OFkS77WdaE5USyht5KeA/ECoJC7ojwIxOaqy69j28CBvE1fJV3UYMPfI8qiG9O1rUCNnK5MTTSbNL X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 11:49:56.8137 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8dd932a6-3a5b-4f12-a36e-08df09b179eb X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: AMS0EPF0000056A.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB11326 X-purgate-ID: tlsNG-d62444/1788436201-1D272757-654379B6/0/0 X-purgate-type: clean X-purgate-size: 8978 Hi Andrew, > On 31 Aug 2026, at 14:19, Andrew Cooper wrote= : >=20 > Both {get,set}_user_reg() are out-of-line functions, leading to awful cod= e > generation. >=20 > Introduce arm_smccc_guest_smc() to operate directly on guest registers. >=20 > No functional change. >=20 > Signed-off-by: Andrew Cooper Looks good to me. Reviewed-by: Bertrand Marquis Cheers Bertrand > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers >=20 > For arm64: >=20 > add/remove: 0/0 grow/shrink: 2/4 up/down: 27/-864 (-837) > Function old new delta > symbols_addresses 35096 35120 +24 > symbols_names 42958 42961 +3 > imx8qm_smc 544 348 -196 > scmi_handle_smc 372 152 -220 > imx8m_smc 576 356 -220 > zynqmp_eemi 864 636 -228 >=20 > For arm32: >=20 > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-160 (-160) > Function old new delta > scmi_handle_smc 392 232 -160 > --- > xen/arch/arm/firmware/scmi-smc.c | 16 +----------- > xen/arch/arm/include/asm/smccc.h | 29 +++++++++++++++++++++ > xen/arch/arm/platforms/imx8m.c | 16 +----------- > xen/arch/arm/platforms/imx8qm.c | 16 +----------- > xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 17 ++---------- > 5 files changed, 34 insertions(+), 60 deletions(-) >=20 > diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scm= i-smc.c > index 0835ddeeeccc..a0cc6c6192f8 100644 > --- a/xen/arch/arm/firmware/scmi-smc.c > +++ b/xen/arch/arm/firmware/scmi-smc.c > @@ -50,7 +50,6 @@ static bool scmi_is_valid_smc_id(uint32_t fid) > static bool scmi_handle_smc(struct cpu_user_regs *regs) > { > uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); > - struct arm_smccc_res res; >=20 > if ( !scmi_is_valid_smc_id(fid) ) > return false; > @@ -63,20 +62,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs= ) > } >=20 > /* For the moment, forward the SCMI Request to FW running at EL3 */ > - arm_smccc_1_1_smc(fid, > - get_user_reg(regs, 1), > - get_user_reg(regs, 2), > - get_user_reg(regs, 3), > - get_user_reg(regs, 4), > - get_user_reg(regs, 5), > - get_user_reg(regs, 6), > - get_user_reg(regs, 7), > - &res); > - > - set_user_reg(regs, 0, res.a0); > - set_user_reg(regs, 1, res.a1); > - set_user_reg(regs, 2, res.a2); > - set_user_reg(regs, 3, res.a3); > + arm_smccc_guest_smc(regs); >=20 > return true; > } > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 53cdddb690b7..832157f43734 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -202,6 +202,21 @@ struct arm_smccc_res { > #ifdef CONFIG_ARM_32 > #define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) > #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) > + > +/* Make an SMCCC v1.1 compliant SMC call with guest register state. */ > +static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) > +{ > + struct arm_smccc_res res; > + > + arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3, > + regs->r4, regs->r5, regs->r6, regs->r7, &res); > + > + regs->r0 =3D res.a0; > + regs->r1 =3D res.a1; > + regs->r2 =3D res.a2; > + regs->r3 =3D res.a3; > +} > + > #else >=20 > void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, > @@ -251,6 +266,20 @@ void __arm_smccc_1_0_smc(register_t a0, register_t a= 1, register_t a2, > arm_smccc_1_0_smc(__VA_ARGS__); \ > } while ( 0 ) >=20 > +/* Make an SMCCC v1.1 compliant SMC call with guest register state. */ > +static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) > +{ > + struct arm_smccc_res res; > + > + arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3, > + regs->x4, regs->x5, regs->x6, regs->x7, &res); > + > + regs->x0 =3D res.a0; > + regs->x1 =3D res.a1; > + regs->x2 =3D res.a2; > + regs->x3 =3D res.a3; > +} > + > /* > * struct arm_smccc_1_2_regs - Arguments for or Results from SMC call > * @a0-a17 argument values from registers 0 to 17 > diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8= m.c > index 669dd517e057..efb0ad20d6e8 100644 > --- a/xen/arch/arm/platforms/imx8m.c > +++ b/xen/arch/arm/platforms/imx8m.c > @@ -50,7 +50,6 @@ static bool imx8m_smc(struct cpu_user_regs *regs) > { > uint32_t function_id =3D get_user_reg(regs, 0); > uint32_t subfunction_id =3D get_user_reg(regs, 1); > - struct arm_smccc_res res; >=20 > if ( !cpus_have_const_cap(ARM_SMCCC_1_1) ) > { > @@ -122,20 +121,7 @@ static bool imx8m_smc(struct cpu_user_regs *regs) > return false; > } >=20 > - arm_smccc_1_1_smc(function_id, > - subfunction_id, > - get_user_reg(regs, 2), > - get_user_reg(regs, 3), > - get_user_reg(regs, 4), > - get_user_reg(regs, 5), > - get_user_reg(regs, 6), > - get_user_reg(regs, 7), > - &res); > - > - set_user_reg(regs, 0, res.a0); > - set_user_reg(regs, 1, res.a1); > - set_user_reg(regs, 2, res.a2); > - set_user_reg(regs, 3, res.a3); > + arm_smccc_guest_smc(regs); >=20 > return true; > } > diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx= 8qm.c > index 3600a073e8ba..7249e14ab640 100644 > --- a/xen/arch/arm/platforms/imx8qm.c > +++ b/xen/arch/arm/platforms/imx8qm.c > @@ -67,7 +67,6 @@ static bool imx8qm_smc(struct cpu_user_regs *regs) > { > uint32_t function_id =3D get_user_reg(regs, 0); > uint32_t subfunction_id =3D get_user_reg(regs, 1); > - struct arm_smccc_res res; >=20 > if ( !cpus_have_const_cap(ARM_SMCCC_1_1) ) > { > @@ -106,20 +105,7 @@ static bool imx8qm_smc(struct cpu_user_regs *regs) > } >=20 > allow_call: > - arm_smccc_1_1_smc(function_id, > - subfunction_id, > - get_user_reg(regs, 2), > - get_user_reg(regs, 3), > - get_user_reg(regs, 4), > - get_user_reg(regs, 5), > - get_user_reg(regs, 6), > - get_user_reg(regs, 7), > - &res); > - > - set_user_reg(regs, 0, res.a0); > - set_user_reg(regs, 1, res.a1); > - set_user_reg(regs, 2, res.a2); > - set_user_reg(regs, 3, res.a3); > + arm_smccc_guest_smc(regs); >=20 > return true; > } > diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c b/xen/arch/arm/p= latforms/xilinx-zynqmp-eemi.c > index 2053ed7ac5f6..326c8a1ba6e5 100644 > --- a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c > +++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c > @@ -51,7 +51,6 @@ static inline bool domain_has_reset_access(struct domai= n *d, uint32_t rst) >=20 > bool zynqmp_eemi(struct cpu_user_regs *regs) > { > - struct arm_smccc_res res; > uint32_t fid =3D get_user_reg(regs, 0); > uint32_t nodeid =3D get_user_reg(regs, 1); > unsigned int pm_fn =3D fid & 0xFFFF; > @@ -187,20 +186,8 @@ bool zynqmp_eemi(struct cpu_user_regs *regs) > * can forward the whole command to firmware without additional > * parameters checks. > */ > - arm_smccc_1_1_smc(get_user_reg(regs, 0), > - get_user_reg(regs, 1), > - get_user_reg(regs, 2), > - get_user_reg(regs, 3), > - get_user_reg(regs, 4), > - get_user_reg(regs, 5), > - get_user_reg(regs, 6), > - get_user_reg(regs, 7), > - &res); > - > - set_user_reg(regs, 0, res.a0); > - set_user_reg(regs, 1, res.a1); > - set_user_reg(regs, 2, res.a2); > - set_user_reg(regs, 3, res.a3); > + arm_smccc_guest_smc(regs); > + > return true; >=20 > done: > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:50:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:50:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406964.1640130 (Exim 4.92) (envelope-from ) id 1x25xh-00063p-9B; Thu, 03 Sep 2026 11:50:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406964.1640130; Thu, 03 Sep 2026 11:50:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25xh-00063i-5Y; Thu, 03 Sep 2026 11:50:33 +0000 Received: by outflank-mailman (input) for mailman id 1406964; Thu, 03 Sep 2026 11:50:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25xf-00063W-Ix for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:50:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25xe-003X5g-Vo for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:50:30 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995f01-8faa-0a2a0a5109dd-0a2a45088776-22 for ; Thu, 03 Sep 2026 13:50:30 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995f06-f659-0a2a45080019-d155802acc25-3 for ; Thu, 03 Sep 2026 13:50:30 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b8f86c6deso14395385e9.0 for ; Thu, 03 Sep 2026 04:50:30 -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-49cee5e589bsm60672885e9.13.2026.09.03.04.50.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:50:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788436230; x=1789041030; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=k9h9oHU+S36j2cjWBvNjUlTULYo/gLK7sSNoA04XtJY=; b=djmyUrJ5HVEerDzRtSNQL4wClG2motAz9K+7EDYl9Rjv6GjWScHqMM6hPAyrs7n/2I 7ry1uViP5guu6w9yMUnlEU3TxnV8qdbQKUO5feWoVPzHxi/EZbkvN3eav8H0utCF96dc emCpCej+IyfzSPSKTIG7771s20MTCiJP5oO6CbCsQiqppPHXzvg9Srj/G1Fexqmk8UM4 LnRdkN2gEfKNWDsbQuWgFeBApvT/h/eo8ARhGCjCfvwjdPgkRb5JboLYjjJ0paYT23ts saN3vyfLZHr+mmcpQE7Zrm3bbuzvQLDhXhDf4JKyl5L3L2eqmiSqNhk8joZKkPu6uXYW FLBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788436230; x=1789041030; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=k9h9oHU+S36j2cjWBvNjUlTULYo/gLK7sSNoA04XtJY=; b=koNX/q4ySnlXIdvQYOICRW3/AEeMnhhsFMkMqQEPpqHzb7yxASf6kF6iHLKLLkIgGJ IVT7GB8fhY8znO9vAU3cCvhvArPn0v5bo9bvJr83N7dHmYc7G1fFTM/8IfRdYx4gDY7C AjxKXOQH9HewxcyRk0x5wynAfoJYNrGAGaa3/pWrUrWaAucgX9gHlxJ/7OaVIWLO6pP8 eXPBi9y9Q8ppaKX6Nm2dnNVdg9zqrWeUoUwwyburgie3Rnkp0dkwbI9E0zK8wuwQ4qqr Afqr7LnPUej6MmpDxitOxQc/omVUOXanHppE0JQCvQbWezUng/KVCJI52wPifbW3d6mE Y69w== X-Gm-Message-State: AFuF++lQvEFDcoyD5Js+qx24z9Zv+ijZRGFttmUoUCVf3gzddVMlzv6B TyJfuI8Sk4LGPJzhmxDvidlT4NXOluxCXJ+gBF8x/knhW5fHaL/xrf550VLVzN6EzQjvpdE+uw4 3VGa62A== X-Gm-Gg: AYBFou2KBH04oE7vEjRupROYlhScwBdS17/1R4cc9WYdNazZeJPxFcJwPWe1VadCja6 Z8GF0xT+Ru77qc9mNkzNHTDcFr2i51kOmd4KgvlZMJdpoIiCSL/MtVEe+s6NduHAYMpjFG7bzkU Sfyk4Eg/Lp7dEfv1gKQSxJIGdMWkU7e6YGPRuM26fGP9zmstxmakm1uCMZMNazMxEWkbrpLi/cB DbeZkp/WfFzcbttB3pQgRL+DYKIw4Imtpayl5y0ZXXs0CTSbmNpQYto9Y6ed474cGFY/0ymgMaM NwV6g2Crm+/QIms62dbpz/Gq0i7+FMJFmLvkW2u11RfyFqcGEMteAtJ+ZWdWopw3ePv7x4jVCeJ 130tUkdPJHXq0XI85uwc9/+N9edtRtXiiY5A38+2hrrh06wwQlfQARADZE+1PPRvvxSNhBbH11C lM2oYvGvb4k9pbGTcdoUGyNQKXGdnb4MfPeYtT2YjW0AtFt9p7NRqnzg7JKz8Tl4UxG1l9VlyZc weYSflswrW7dW5ByFx68foVYlsI247q9JUt9dGg74ZfN0HFnzxy X-Received: by 2002:a05:600c:530e:b0:49c:d618:e341 with SMTP id 5b1f17b1804b1-49ce584bb4amr232397715e9.14.1788436230391; Thu, 03 Sep 2026 04:50:30 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 13:50:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini From: Jan Beulich Subject: [PATCH 0/4] address remaining rule 13.1 violations; mark clean 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788436230-CEB4187B-B298C9AE/0/0 X-purgate-type: clean X-purgate-size: 300 "Initializer lists shall not contain persistent side effects" 1: x86/pagewalk: avoid ACCESS_ONCE() in compound literals 2: Arm/guestcopy: avoid use of "current" in compound literals 3: sched/core: avoid use of "current" in initializer lists 4: automation/Eclair: tag rule 13.1 as clean Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:50:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:50:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406968.1640138 (Exim 4.92) (envelope-from ) id 1x25y5-0006WK-GO; Thu, 03 Sep 2026 11:50:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406968.1640138; Thu, 03 Sep 2026 11:50:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25y5-0006WC-DJ; Thu, 03 Sep 2026 11:50:57 +0000 Received: by outflank-mailman (input) for mailman id 1406968; Thu, 03 Sep 2026 11:50:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25y3-0006Vy-TD for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:50:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25y3-003XFz-5z for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:50:55 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995f15-bab6-0a2a0a5309dd-0a2a4506bb10-20 for ; Thu, 03 Sep 2026 13:50:55 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995f1e-195a-0a2a45060019-b9ff1c238999-3 for ; Thu, 03 Sep 2026 13:50:55 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0671b7c5b000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 11:50:49 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id C1B9881F95; Thu, 3 Sep 2026 13:50:48 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=+RQ/XWmthdLmQkPy9HZTwrVmSXS++68tbHRKsHJNkLg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=bGgWaiQeb4kkLfpddLMu8979iFc4nBp4lgTRfIeW35g3gtbfEJjOI5hBvNOlI51iC4vj+X725 +EluBu/9AYBcflDATaJ8viAg4G8Y1PZeHI3XwQlwypNCQU7747apGGhMspaHDaWS9j8q1cEuXTF 6/QRo3f+Kl1MDwrFKbj8fGfkiIyli4vYrUrTxDVq08ttz0AjLPF1kjZYVOuDyliaBygNtH0sYZM R17Bq3WVGVWR1Pl9nHl95MUrpoxCyh+6Mp1N2ZG1a6koHoZzT6N4pJUT6rKaiidHpsKvqmIUZdq fjFgSLwx0pjGxVEDha03tuvVcPTHdzlMr49yPvD8AGIg== X-Zone-Loop: 378df82f4bba589732e22afe7e9644d78d308dcf7369 x-campaign-type: default x-transaction-id: 919448ec-66e9-4ede-85d4-f82837a12386 x-swg-uid: 01-c3ac608e-5daa-49d1-b384-7e1dbd6496b4 X-Mailer: Sweego Message-ID: <1788436249.8631fc262581453bbf619ec5b2062170.1a0671b7c5b000c4f3@vates.tech> x-swg-bid: 1788436249.8631fc262581453bbf619ec5b2062170.1a0671b7c5b000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 3 Sep 2026 13:50:48 +0200 From: Anthony PERARD To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Michal Orzel , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Timothy Pearson Subject: Re: [PATCH v2 4/7] PPC: split xen-syms linking rule References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com> <85bc5cc5-285e-481f-bacd-8421abae169c@suse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <85bc5cc5-285e-481f-bacd-8421abae169c@suse.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.34ff.14f69d624b772142.1a0671b795e.b275bbe9bf250f14=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788436248927 X-purgate-ID: tlsNG-16d1c6/1788436255-F580D77B-BFD0852F/0/0 X-purgate-type: clean X-purgate-size: 1300 ---=Part.34ff.14f69d624b772142.1a0671b795e.b275bbe9bf250f14=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2026 at 02:01:57PM +0200, Jan Beulich wrote: > Doing so, besides (hopefully) adding clarity (not the least by way of > [re-]using pattern rules where possible), also avoids explicit recursive > $(MAKE) invocations=2E >=20 > By re-using the generic rules introduced when the respective x86 rule wa= s > split, > - the =2Emap file now isn't created after the final binary anymore, > - --strip-debug is passed to $(LD) during early linking passes (for > consistency the option is also explicitly added to the optional linkin= g > pass rule), > - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are > now properly respected=2E > Orphan section checking, otoh, is getting suppressed for now, until the > about a dozen warnings which would result have been taken care of=2E >=20 > Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.34ff.14f69d624b772142.1a0671b795e.b275bbe9bf250f14=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:51:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:51:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406980.1640146 (Exim 4.92) (envelope-from ) id 1x25ye-00074H-SA; Thu, 03 Sep 2026 11:51:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406980.1640146; Thu, 03 Sep 2026 11:51:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25ye-00074A-PA; Thu, 03 Sep 2026 11:51:32 +0000 Received: by outflank-mailman (input) for mailman id 1406980; Thu, 03 Sep 2026 11:51:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25ye-00073w-2r for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:51:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25yd-00AJ5A-Ec for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:51:31 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995f3f-2eae-0a2a0a5409dd-0a2a4502a6a6-14 for ; Thu, 03 Sep 2026 13:51:31 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995f42-6ca4-0a2a45020019-d1558029c1f6-3 for ; Thu, 03 Sep 2026 13:51:31 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49b8687630fso19214885e9.3 for ; Thu, 03 Sep 2026 04:51:30 -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-49cee60d9c6sm67076335e9.11.2026.09.03.04.51.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:51:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788436290; x=1789041090; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=zhIYR/oqHKXSjiZI2vs1xRVSb8E3/e1gFl+5UoCDK/g=; b=gZQ0InSQIIgnf/QN+fnhYNxM7L1ncmzMWz7WeaAIKm5wQa4UyMPQihbwStcWPqBOcN Ho5LefdzW923u1fKOiM3Xtutn71w8qP+NVV/16nQ/awD4MTLUga6FSLz/H4j50te8yDy aYOafifyTu509z8qUWDnztoFVy9D9Fm5iTCATN1JE4EOP7rSoxrJJIqI6fV1JmaRRtcq IWONGmWU6gFF1knuYo8WSWbxrzvNUreIQ77JA0kjtuvtkcjq7pakmOt1avOYX52djPYQ QdBWZwRJqUB5dU9/zNitJTkkmJW0SlzQoyghZjJz9+LabbRzLrOzxpwkY6L/JrktBAQ5 NCWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788436290; x=1789041090; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=zhIYR/oqHKXSjiZI2vs1xRVSb8E3/e1gFl+5UoCDK/g=; b=IrvnAUgSG/ZqoprsAFyrWXvtsFgpbXG5GCUt6vxTPYE/5/y1yfSGYCbO4JNCV8cTq/ Tf/RBHXj2JWIx18va3ilsnUn4JT9nb6ZY7vausKcMtz5m7DLOsmFjVCZS+8wojoxChZR vMMKCtsiGOqBJODrvUDQDtoC4tFTK41q7FI1J1b8srj6/WwENypuDQUV2Zs/AS0423Zk HKuGqMcQtWa8gzSgfAS7YWVENTVsec3LN4PO0RlnK4PFCmbOPV3jih6j8SNgybMRclu6 CG3OjOwlrEsYpEsPjQJgjWvY1V6LyNxSB2HiXV7h3tzD3acCclJNDJN0PBgUyelIPFgb NZlA== X-Gm-Message-State: AFuF++nmnDAvbYU60ig1ngTIS7SJeBuQKvgqgpRQ75funH/QbFwKP2iB EgBF1dj6bW3RtJQ511DUcABpwJX/AqjJEOljubCr8YY/4VVkSByG9ewZYhN+g7fRQBgSmBiQPDk +5fE2EA== X-Gm-Gg: AYBFou2lCXX6Y+MdwceoAga1hA2MM8oT4e0Q4/3tu5JD9Vhzf0RoHnJnIkQ957j+8qI LjotFu6dBwz7c2z0DbtuvhKo+zPJN5nTdYtX25NqVNS0m/P44MePdeQBhNUi3vqp6g+39z4SkzZ L0PCGn/2u5LdqBUN+prjqvfwktsYyvYpGy0KJWBpnhNjmhrGsD0Xvuh1tbKuG8Am46RmQxHjJIS kZ1AAvq6rpS2qw38AZ1qybc82o5EgbsLIMMK5zs3r1WFftYwKRtLe6Ok/v4Qi6DeG98ZiuWRxWL R5OIw1+SUQRAAlzs18r6j3m/J+w7giUWnKKMrFlFgYnHuBpsFn8EjjQf8Rj8tbZXAs1O2e3ACUT Vl1gKv5YlOVlBcyA+GtpZ0mEVowC8uHu7u6P87oZvVnYGTvU9T5o6zaXr6Plzm48rPn4BEL7+ZO 08lFCh5LAZtOS+vbjrQFII4tHKDpyuHVpLdnpjxraN0QSn4fii6yvVIy00V4GwOzxqx2jisV2VP Ba+GVBSdKoxlnj2o6FeUOqCeXIK7WhmOnVPq121ff2g53KLwXkG X-Received: by 2002:a05:600c:470d:b0:499:9240:9a1c with SMTP id 5b1f17b1804b1-49ce58363f8mr171708855e9.15.1788436289991; Thu, 03 Sep 2026 04:51:29 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 13:51:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/4] x86/pagewalk: avoid ACCESS_ONCE() in compound literals From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US 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 X-purgate-ID: tlsNG-720697/1788436291-F20A82AC-376B41CF/0/0 X-purgate-type: clean X-purgate-size: 2636 Compound literals are also covered by Misra C:2012 rule 13.1 ("Initializer lists shall not contain persistent side effects"), and (sadly?) that rule also applies to lists with just a single element, or more generally with just a single side effect. Use intermediate variables to overcome this as well as ACCESS_ONCE()'s restriction to be usable on scalar types only. No functional change intended. Fixes: 0345b835dc97 ("x86/pagewalk: Read guest PTEs with ACCESS_ONCE()") Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/guest_walk.c +++ b/xen/arch/x86/mm/guest_walk.c @@ -129,7 +129,9 @@ guest_walk_tables(const struct vcpu *v, guest_l4_table_offset(va) * sizeof(gw->l4e); if ( !hvmemul_read_cache(v, l4gpa, &gw->l4e, sizeof(gw->l4e)) ) { - gw->l4e = (guest_l4e_t){ ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4) }; + guest_intpte_t l4e = ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4); + + gw->l4e = (guest_l4e_t){ l4e }; hvmemul_write_cache(v, l4gpa, &gw->l4e, sizeof(gw->l4e)); } gflags = guest_l4e_get_flags(gw->l4e); @@ -164,7 +166,9 @@ guest_walk_tables(const struct vcpu *v, guest_l3_table_offset(va) * sizeof(gw->l3e); if ( !hvmemul_read_cache(v, l3gpa, &gw->l3e, sizeof(gw->l3e)) ) { - gw->l3e = (guest_l3e_t){ ACCESS_ONCE(l3p[guest_l3_table_offset(va)].l3) }; + guest_intpte_t l3e = ACCESS_ONCE(l3p[guest_l3_table_offset(va)].l3); + + gw->l3e = (guest_l3e_t){ l3e }; hvmemul_write_cache(v, l3gpa, &gw->l3e, sizeof(gw->l3e)); } gflags = guest_l3e_get_flags(gw->l3e); @@ -264,7 +268,9 @@ guest_walk_tables(const struct vcpu *v, l2gpa += guest_l2_table_offset(va) * sizeof(gw->l2e); if ( !hvmemul_read_cache(v, l2gpa, &gw->l2e, sizeof(gw->l2e)) ) { - gw->l2e = (guest_l2e_t){ ACCESS_ONCE(l2p[guest_l2_table_offset(va)].l2) }; + guest_intpte_t l2e = ACCESS_ONCE(l2p[guest_l2_table_offset(va)].l2); + + gw->l2e = (guest_l2e_t){ l2e }; hvmemul_write_cache(v, l2gpa, &gw->l2e, sizeof(gw->l2e)); } @@ -353,7 +359,9 @@ guest_walk_tables(const struct vcpu *v, guest_l1_table_offset(va) * sizeof(gw->l1e); if ( !hvmemul_read_cache(v, l1gpa, &gw->l1e, sizeof(gw->l1e)) ) { - gw->l1e = (guest_l1e_t){ ACCESS_ONCE(l1p[guest_l1_table_offset(va)].l1) }; + guest_intpte_t l1e = ACCESS_ONCE(l1p[guest_l1_table_offset(va)].l1); + + gw->l1e = (guest_l1e_t){ l1e }; hvmemul_write_cache(v, l1gpa, &gw->l1e, sizeof(gw->l1e)); } From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:52:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:52:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406986.1640155 (Exim 4.92) (envelope-from ) id 1x25zC-0007X4-2y; Thu, 03 Sep 2026 11:52:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406986.1640155; Thu, 03 Sep 2026 11:52:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25zC-0007Wx-0G; Thu, 03 Sep 2026 11:52:06 +0000 Received: by outflank-mailman (input) for mailman id 1406986; Thu, 03 Sep 2026 11:52:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x25zA-0007Wc-QL for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:52:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x25zA-007Gry-6v for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:52:04 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995f5f-8faa-0a2a0a5109dd-0a2a450bcbca-10 for ; Thu, 03 Sep 2026 13:52:04 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995f63-b7e8-0a2a450b0019-d155802ac04d-3 for ; Thu, 03 Sep 2026 13:52:04 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b8eeb3ff2so20476955e9.2 for ; Thu, 03 Sep 2026 04:52:04 -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-49cee5d1fa6sm71126955e9.1.2026.09.03.04.52.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:52:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788436323; x=1789041123; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=Tdr/Gmp1cERSIVeOl3/iaDcbwecc4l4TxDPSodIgybQ=; b=DXY8sqcxV/GDAJDDH0Es6YoZcCm72JwauTXxi1LWLeRwinS6Dc5f/KFTLXoP/+EQR9 4ArwFXAQeDnwGjMkl6S01VoahY0FwvZjjF5u99ekvMqAXoXZvHGS3TD7cvDRCqo2+3Oe E5CSq5eI2CsJ6TX4gBIboq+VdTWaWxXXj9mLJ1zp98LORqeA2cZKif23qk4FHH+yNYg8 txLri98ac85ncuhMi/y9ueHazHwd+8+xy8ev0qAe3inRUQtVifC3cx5f7TVCNqGBzXnP LYPpCOTsLt1FKtQuh6zJ5rK7pLihj3iwl03owVKuHRW3dhO7tmWdXKAaT/slEjFloQxi QK8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788436323; x=1789041123; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Tdr/Gmp1cERSIVeOl3/iaDcbwecc4l4TxDPSodIgybQ=; b=lJxhHr8Y74bxKJoeZTXyd5+n5lVUJX1TTLGXn9VRXqd3KzqpqsxLZZd2HEXmn1ZSZS sIDCqVdmKwuUT+NddaEG8E2YG+NxuYTMdfqH+U0IOJFsFKe/ClRPCCtmkFVNcltaSK53 D3TlPiZfGidvDVnsX9BltWIR87jclDi/CHyKSEXj7cdfpwvQNbORoT4jMgSxGkRksy0C uyw0e09eICqGXRevq1ePblhotBzSoenvJk/phBA3aYEcthlmppEHXf+bP/WLbfuWOUjL aRWHnJeGjFMmiFkgMwfMIn4CzWD59+MvwzbMdrsKTG9XEs7zUC1l5NmGwFZAZsgbx6JP mawA== X-Gm-Message-State: AFuF++n0SgfaUP+rhKL1a91Xyp8Q4UpmzapWQjLNgPtGLvNs3TA7KP6V zEnjuD3rdc9+3ZmouHFIWB1N3sk07bhlg+rAAJolYH3kFSj1DKglsGiFExqZrafOpaDWt/DhHLo 6ruMJ7g== X-Gm-Gg: AYBFou0GtnubWLulT4Cf0zbCO7qo2bYwqkgyIhUjobJjjfBu3JoBrp0ITsw4GbdmXKt N+11+bROjIdNFgiSZ3Sn1oPBK22OpnHNnX9LRU8fwlOazpthFkrWq+u4mNBxTbtvKiNNVINRwBT QLfVfM92gNPRYyhOdw+Y/jHw+SPh639X0IZ2n+52dfzkNPrbJ+xbA7v5AlGPIpVdcRUq4o54qeQ s+dll2oHxZB3GCdveidxlklWjI6YvVJxhJefVkNilaXPVx03OU6ztZX24+8OlNfsE1GLWyTz/1Q l5VFmq5mEZ7k+hkaidykRBXvtN7BqHyfuGosW3nG+HTqJYa4RRNFYRGE7l6PCLJhwRM3/+/bLS+ dU+MTp9bgbQhHuPz77HgtqWcKryCmwiBujCPVUQ0xPxV9pUPBmj8bbfOywWXlGaOfLf1tTOzy5/ 7fNgflCWlhW/ZUi/HuIXbh8iRvRdUtiLJNOEZX7wicVxj4Ni20S6IRwcuKBYXAv6Ou9j6E/AKrH SFVn9vnGChtdXJXYOq9cLbxs/X3+eD7OXV8jwcDGzkXUC+gJ1j6 X-Received: by 2002:a05:600c:4e16:b0:49c:ee06:9c58 with SMTP id 5b1f17b1804b1-49cee069c79mr130970735e9.4.1788436323591; Thu, 03 Sep 2026 04:52:03 -0700 (PDT) Message-ID: <7424be87-9a97-4b83-b920-a8ccf4c1a889@suse.com> Date: Thu, 3 Sep 2026 13:52:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/4] Arm/guestcopy: avoid use of "current" in compound literals From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel References: Content-Language: en-US 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 X-purgate-ID: tlsNG-42698a/1788436324-A9EC69EA-E371F59A/0/0 X-purgate-type: clean X-purgate-size: 2167 Compound literals are also covered by Misra C:2012 rule 13.1 ("Initializer lists shall not contain persistent side effects"), and (sadly?) that rule also applies to lists with just a single element, or more generally with just a single side effect. Use intermediate variables to overcome this. No functional change intended. Signed-off-by: Jan Beulich --- This is assumed to go on top of "Arm/guestcopy: deviate copy_guest() uses just like their x86 counterparts", conflicting contextually but not functionally. --- a/xen/arch/arm/guestcopy.c +++ b/xen/arch/arm/guestcopy.c @@ -109,29 +109,37 @@ static unsigned long copy_guest(void *bu unsigned long raw_copy_to_guest(void *to, const void *from, unsigned int len) { + struct vcpu *curr = current; + return copy_guest((void *)from, /* COPY_to_guest doesn't modify */ - (vaddr_t)to, len, GVA_INFO(current), + (vaddr_t)to, len, GVA_INFO(curr), COPY_to_guest | COPY_linear); } unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from, unsigned int len) { + struct vcpu *curr = current; + return copy_guest((void *)from, /* COPY_to_guest doesn't modify */ - (vaddr_t)to, len, GVA_INFO(current), + (vaddr_t)to, len, GVA_INFO(curr), COPY_to_guest | COPY_flush_dcache | COPY_linear); } unsigned long raw_clear_guest(void *to, unsigned int len) { - return copy_guest(NULL, (vaddr_t)to, len, GVA_INFO(current), + struct vcpu *curr = current; + + return copy_guest(NULL, (vaddr_t)to, len, GVA_INFO(curr), COPY_to_guest | COPY_linear); } unsigned long raw_copy_from_guest(void *to, const void __user *from, unsigned int len) { - return copy_guest(to, (vaddr_t)from, len, GVA_INFO(current), + struct vcpu *curr = current; + + return copy_guest(to, (vaddr_t)from, len, GVA_INFO(curr), COPY_from_guest | COPY_linear); } From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:53:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:53:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1406995.1640164 (Exim 4.92) (envelope-from ) id 1x260D-00086a-B5; Thu, 03 Sep 2026 11:53:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1406995.1640164; Thu, 03 Sep 2026 11:53:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x260D-00086T-8S; Thu, 03 Sep 2026 11:53:09 +0000 Received: by outflank-mailman (input) for mailman id 1406995; Thu, 03 Sep 2026 11:53:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x260B-00086H-Om for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:53:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x260B-00AJMm-5U for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:53:07 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995f9f-8faa-0a2a0a5109dd-0a2a4503a208-14 for ; Thu, 03 Sep 2026 13:53:06 +0200 Received: from [52.101.70.47] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995fa2-fae8-0a2a45030019-3465462ffc9b-3 for ; Thu, 03 Sep 2026 13:53:06 +0200 Received: from OS6P279CA0139.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:3a::9) by DU5PR08MB10438.eurprd08.prod.outlook.com (2603:10a6:10:521::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 11:53:04 +0000 Received: from CPH1EPF0000051B.eurprd04.prod.outlook.com (2603:10a6:e10:3a:cafe::1f) by OS6P279CA0139.outlook.office365.com (2603:10a6:e10:3a::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Thu, 3 Sep 2026 11:53:04 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by CPH1EPF0000051B.mail.protection.outlook.com (10.167.241.230) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Thu, 3 Sep 2026 11:53:03 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by PAVPR08MB9818.eurprd08.prod.outlook.com (2603:10a6:102:31e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 11:52:25 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 11:52:25 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=HjZxQVk5tRBv75h+wmygC93YsCdAgD27So1KGkkhSspPyen7iGt8K2vfRKE/ZHQ0SfzSmrW3gpUh3z/3MfDAuA4tp3XCCHNWE24qEGNfDs1K8oPrMzI+uRq7Mmew/NLlz4LOO825pc6TnhcX3TzezdQDCLpqdtuRoS9ofHIk+kXN2nad8B5hoXB0H9henuZMhocIPCramJe9uEqPp8k7+DxSHX+9KfWXXu+JWIGQUdt3EPqERLYNL2KI2BgD15izN7Fp5SWmA3+4QmRMwxmkkIPiyqotbzT7cMp89zSF9ajsha7xQWzUPlNqk61qrkKQ+pPeT4y1iaX/tBNTGkR5Hw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZlHvx6LzBPucMI3DdfND5m53grain8pP6uaUnLyPbs4=; b=rUoyu5hywcAFeUBhtTXglIN6LT/QzJhjgbDUcuLJI2KOMUFjdVoY71csWk8lXggF6h2zxKwWS6zHdRzhEqNbPghwkQ0gW1YOt8lpAb0gYq+iQ9vgOIZIKnEVJfOpZ2GSDFNBmxZZLr56Uoiggtr6uw/fdW0S9A/HAfUlBvPx6bZX7tqAhY6+8viYbDyQl9U+HuUu5oTcOHgpWgraJCV/HUjjY8+mAZ46DqFklvzIeY/dlvn8/OQflvGLUoxwq9c434518T2gH9MC/h4LH8gk9HAaYMr6c6h/AB/ZXGjEwborKi4qT3J197o0bDEn8n1JAT2Jp6cFC8v6oIpDwGGCVQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZlHvx6LzBPucMI3DdfND5m53grain8pP6uaUnLyPbs4=; b=NZYGgdxR1zg/y3MyaFxSrR/HeH0QpVHvWQ5/NJXYDHK4GHy58aSbVqoPMNLRRphxygqhsqS++Ok8l1waNRXbEWJDha1D3v9jBFA50Xzrt2LZ0IR7FDg6IsICfLsytrSobr/phruK7CjkC1KSGsoy2ToYycFUk3/2UXB0yfMzOCM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fbOqakLNJ8UHNPE77Wj2nI2bYc0J8bcA+k8VculRNaPCOwh4nTpFEAXJU6Kt/3leRXsDZpX0GGLlXHX/aLSUt+DoQX45evTy6zYorJQ2tvxtoKyZO9VOh9Ntsv7V3e5TfwDb1Bw/H7DPE392/fUoNK2ELkax7NsywmbwAxvgJ3xcC8wZ9O+E1jrVnfbU83zfkoorLeknt5IYnzSnSHqA6Sm3lGRcaUAAcZowwoLx+VciLBc8GoLElz9LWxvkdxbZdILVwEKf2L6My3efSjf29jnBMeC8xY32or0PBPpQkDa0hapMT++G8yzpE+CrsHtMhM13DfXTsZVhMccBaSpcIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZlHvx6LzBPucMI3DdfND5m53grain8pP6uaUnLyPbs4=; b=aQFs0e6Z9Ta6LXRyRx9keTlBoEiccKtd0dcUcBvIasCgxKAERJTDnrBiYCUdkrsJ+LwPbvh+rnXY4xScQGH0Q+aMG7lKTVqsawyR6yuCUnUPuLMEO1g4Y2RfvEcrkHWrhBXErDIwB6xq0WE+o99/VB5JQXoKD3Hb7xc7voCb6TLnVL3cfZHG1h1JfetuTdiBatRsoYNM5eLcO4dr6pkDKfuCTKpwrukiaVk798y7LCTEPidOwr4G1C7xdwMt13TV8vavcSfnr66bCOUeexH5J3ve39wMB7MQfcez7tAZN/cWQMT2DZD5ZDIqjHJhy3h5rDdfdIIKEnNxjs7HrJcW8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZlHvx6LzBPucMI3DdfND5m53grain8pP6uaUnLyPbs4=; b=NZYGgdxR1zg/y3MyaFxSrR/HeH0QpVHvWQ5/NJXYDHK4GHy58aSbVqoPMNLRRphxygqhsqS++Ok8l1waNRXbEWJDha1D3v9jBFA50Xzrt2LZ0IR7FDg6IsICfLsytrSobr/phruK7CjkC1KSGsoy2ToYycFUk3/2UXB0yfMzOCM= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH 3/6] xen/arm: Clean up 32bit arm_smccc_1_1_smc() Thread-Topic: [PATCH 3/6] xen/arm: Clean up 32bit arm_smccc_1_1_smc() Thread-Index: AQHdOUMPTd/l4DNdekW/1tH97277xLa8ws2A Date: Thu, 3 Sep 2026 11:52:25 +0000 Message-ID: <3F12E6F4-8F79-4E6C-8835-178BB6BB29BA@arm.com> References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> <20260831121944.2908139-4-andrew.cooper3@citrix.com> In-Reply-To: <20260831121944.2908139-4-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|PAVPR08MB9818:EE_|CPH1EPF0000051B:EE_|DU5PR08MB10438:EE_ X-MS-Office365-Filtering-Correlation-Id: 3075aa32-777a-4eb6-e7db-08df09b1e943 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|38070700021|56012099006|10067099003|22082099003|4143699003|11063799006|3023799007|18002099003; X-Microsoft-Antispam-Message-Info-Original: oeXoD0CCin7P/hY+im0rcAI8Ex1zrotbBgCsPeuebFdZGSmZVuN4EW9GoCv73lPT6LoU74gOwOYwVRENC+s5rom1EU2mz5whJApMRHXxbuk3Eg7ZgopKSRNo9mqzuFG5llTiL8U+HQ1DBpkb+OqB/X86I01xJuR2QXJIzyrks0WytzQG7itfCsASTX7SS6I4h1zZLggL6RNP9BeBIEYId8iyZwPO9Fkls6SFfhjE3A5Ewue76odOgeaqSIKvRnS5A3H+AnXkx9zNUInl1CxkZrSWarN0R3fIiWeOwMkqxh6ionlRSFCFp7kvI8NcWqLrKAsFs4yYi1IHBACOXNOMzaDw1pwi27YiV+nXMtVD9cGuO54Jpsrgmtgc7MUc5B17BRr1QR6V+iObQCU/RtEOqqm/GQ4Z5Vp1YSerNDKjPw20Imx5YMC16SNSDH+0jXNqYFevxCfe7dPh6Qc07Jh+rHHu2um4bWIKhvWg15tmR2mGLbEaJ8LyaU/6cFbqbmoMTP9Ks+Vk+04pbA7IbwRZxVziMSyLB8kisY4xSA7Bn+ayy+nLt69Tx+f/So55LV/0HuEUJ2sokZ19A+tu6D9+nMvG+xPESvVaSnjp0taSGWXjAxO1du9moJMI7LmSDhFHrjCFP9a//SEOw7XtM3tTWtESkvxUCIrXWjXAmYDaReOwrrb+aX8uZA9gRp1YNmQ/8dK0nGvGXSCE/OW1Dk6zcmzsZoDb1X4bPbHpoLukcvY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(38070700021)(56012099006)(10067099003)(22082099003)(4143699003)(11063799006)(3023799007)(18002099003);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: L2gwejTEr1qYQmMsv03I2ju57J2Wr0MsRYhHo+kGilZMNjOQyAPKSVLRlWhd7SAEhgEejCmxp0vyVcESrNWG1objQLXQWBoZy2Wl7jUOY7Pyl8z5Gp/lB+afV2NYyP9MzdP2YOvd2qBtKt0jCZ3Id5y6pTE+KAPJTB5h0MFwkg7eSCHcFJ7sVTdXtoyUpCr/5jbM/hfnUZN3Ew8c7+7VPfK80D0F/9Lr3SADYgBOgY7qaxlFUP8xzbpHnotZsLb5bvmxzALETI6+MgklAV5+GwCi0xSb0QHg7PkuXLBxo2BPIaRBBxDU6bdhnKps3BXtGAzrnTsTSyPo8hoUUJ4pMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9818 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: CPH1EPF0000051B.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 866f1804-026b-4e21-7858-08df09b1d2ad X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|35042699022|23010399003|82310400026|14060799003|36860700016|1800799024|10067099003|11063799006|4143699003|3023799007|18002099003|22082099003|56012099006; X-Microsoft-Antispam-Message-Info: o5WC/aG6TJS15aoxUsuMVFFBsuhQpzdmZxsis5mO6SBIs7sAgVDcQ60RobgW24APBgMS5KxZbG2QIdtCcYDUEA6PaSkkMsgFWKklYIZWm9Rh8NJn+WpC7ZQF1iDEohE+k7Bh+0UnZtPk1/AbhYca3pCT6fiq2oJUGjKKzPzi6zQE+5SOci7r80NdA0Klyf/IdqtukxE9Uw8HkY05Dm21tI2lfuDZfkY4KMFKZNzuSAF3h3uG/GwizcCVhRehUD8dAOCabOT5h/ZW/YcZtTC3aDc68OcoVdBRqWLdUt8ivVV/bhTkPjklG33lJW316J8iNESPWMqgHvC3kMvG2WaEfFg4HODlwXdSXAXaIWNv/F0k1sWsAwBpIZh4JkcsAJKe85Tvbj7iVrzafNdgi8M8hXlqOIWJmSPoJw9aEix5kXIkugSPpvWWJaemwQMRRshxHgDqF0UM5PvLCP4GB1ii4cRHvOH2wilXwalRpflDEqWtySeJl3aLoOBD1YcK7LoPMxM7nudNjdhoDNqpYQhPfGCxzE3S6vzYE0qfVS3DPkQqfgZI0TgFdccVmu9IgcXR+sWkQs+fjjv0mbgJ6Yu/6DYvQGQmN6p8VBbzN+mOBTzFwGcxSbFE/pvomQEhbf/l3Hq8WotU5OUfcRPJVVJfsA6eaABeArNglqwpMK4jnEg= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(35042699022)(23010399003)(82310400026)(14060799003)(36860700016)(1800799024)(10067099003)(11063799006)(4143699003)(3023799007)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: mDeQKzbkCTCtJVlAoKxdY67QMa8GMVzUy4UGTADZa9W4IReupKeK7uq9wUv10q6AsDlg1H+gVF8hRflS7kr/2IiiXq3sHTkZWj+faYm9nrLO62s/191Acfa3Kf7TAUmnM69mXlpqir0U/fv34LYZ2ZJw2zdbWL+TuCrSU0d/o6ACw4rMCOgBliOQVmu80G1z0nZn0oIX6UYn9qkqyDMxASNPBHQtN1l92YU5xLfui5Pk7Wto8lcEP1nX3VGG4jGaXoPBKi3C0qcSB27r4prjRDu9unDDtnqjz7y8aartpgWcX74jDmd5n5+4m58hg2Mh7Rs7KeZqXGwvFttdBU8VR+0z05hPE3XLFuCoK5EADw7MCq36hfKTx4X3caG7lbagxA36Nr9A/RM3jDMZD1uDPx1r9eMNbih6SkDCBzuoSy2cT7a8Gdmm9qrXGCmKc7s0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 11:53:03.5704 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3075aa32-777a-4eb6-e7db-08df09b1e943 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: CPH1EPF0000051B.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR08MB10438 X-purgate-ID: tlsNG-33051d/1788436386-768FA4E9-1E2AE786/0/0 X-purgate-type: clean X-purgate-size: 6002 Hi Andrew, > On 31 Aug 2026, at 14:19, Andrew Cooper wrote= : >=20 > ... before making a related copy of it. >=20 > * Drop __constraints() so the output parameters are visible in the same b= lock > as they're defined. Use PASTE() rather than opencoding it. > * Adust the indentation of trailing \'s for consistency. > * Drop the newline at the end of the instruction. > * Indent the if condition correctly. ___res is always of type > arm_smccc_res (declared in __declare_arg_0()), so drop the typeof(). > * Drop arm_smccc_1_0_smc() as it has no users. >=20 > No functional change. >=20 > Signed-off-by: Andrew Cooper Looks good and i was not aware of this PASTE, result looks nit. Reviewed-by: Bertrand Marquis Cheers Bertrand > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers > --- > xen/arch/arm/include/asm/smccc.h | 45 ++++++++++++++++---------------- > 1 file changed, 22 insertions(+), 23 deletions(-) >=20 > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 832157f43734..5fe54013ac83 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -56,6 +56,8 @@ >=20 > #ifndef __ASSEMBLER__ >=20 > +#include > + > extern uint32_t smccc_ver; >=20 > /* Check if this is fast call. */ > @@ -115,24 +117,24 @@ struct arm_smccc_res { > * This is manual register scheduling for the asm() statement, and any ot= her > * logic to evaluate may clobber the already-scheduled registers. > */ > -#define __declare_arg_0(a0, res) \ > - auto __a0 =3D (uint32_t)(a0); \ > - struct arm_smccc_res *___res =3D (res); \ > +#define __declare_arg_0(a0, res) \ > + auto __a0 =3D (uint32_t)(a0); \ > + struct arm_smccc_res *___res =3D (res); \ > register unsigned long arg0 ASM_REG(0) =3D __a0 >=20 > -#define __declare_arg_1(a0, a1, res) \ > - auto __a1 =3D (a1); \ > - __declare_arg_0(a0, res); \ > +#define __declare_arg_1(a0, a1, res) \ > + auto __a1 =3D (a1); \ > + __declare_arg_0(a0, res); \ > register auto arg1 ASM_REG(1) =3D __a1 >=20 > -#define __declare_arg_2(a0, a1, a2, res) \ > - auto __a2 =3D (a2); \ > - __declare_arg_1(a0, a1, res); \ > +#define __declare_arg_2(a0, a1, a2, res) \ > + auto __a2 =3D (a2); \ > + __declare_arg_1(a0, a1, res); \ > register auto arg2 ASM_REG(2) =3D __a2 >=20 > -#define __declare_arg_3(a0, a1, a2, a3, res) \ > - auto __a3 =3D (a3); \ > - __declare_arg_2(a0, a1, a2, res); \ > +#define __declare_arg_3(a0, a1, a2, a3, res) \ > + auto __a3 =3D (a3); \ > + __declare_arg_2(a0, a1, a2, res); \ > register auto arg3 ASM_REG(3) =3D __a3 >=20 > #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ > @@ -158,12 +160,6 @@ struct arm_smccc_res { > #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) > #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) >=20 > -#define ___constraints(count) \ > - : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3) \ > - : __constraint_read_ ## count \ > - : "memory" > -#define __constraints(count) ___constraints(count) > - > /* > * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call > * > @@ -189,10 +185,14 @@ struct arm_smccc_res { > register unsigned long r2 ASM_REG(2); \ > register unsigned long r3 ASM_REG(3); \ > __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > - asm volatile("smc #0\n" \ > - __constraints(__count_args(__VA_ARGS__))); \ > + asm volatile ( \ > + "smc #0" \ > + : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3) = \ > + : PASTE(__constraint_read_, \ > + __count_args(__VA_ARGS__)) \ > + : "memory" ); \ > if ( ___res ) \ > - *___res =3D (typeof(*___res)){r0, r1, r2, r3}; \ > + *___res =3D (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > } while ( 0 ) >=20 > /* > @@ -200,7 +200,6 @@ struct arm_smccc_res { > * v1.1. > */ > #ifdef CONFIG_ARM_32 > -#define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) > #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) >=20 > /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ > @@ -217,7 +216,7 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > regs->r3 =3D res.a3; > } >=20 > -#else > +#else /* CONFIG_ARM_64 */ >=20 > void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, > register_t a3, register_t a4, register_t a5, > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:53:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:53:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407002.1640173 (Exim 4.92) (envelope-from ) id 1x260w-0000AZ-MH; Thu, 03 Sep 2026 11:53:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407002.1640173; Thu, 03 Sep 2026 11:53:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x260w-0000AS-Jg; Thu, 03 Sep 2026 11:53:54 +0000 Received: by outflank-mailman (input) for mailman id 1407002; Thu, 03 Sep 2026 11:53:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x260v-0000AD-C2 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:53:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x260u-003Y8T-Ou for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:53:52 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995fb9-bab6-0a2a0a5309dd-0a2a450abcaa-48 for ; Thu, 03 Sep 2026 13:53:52 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995fd0-f2d2-0a2a450a0019-d155802dc9f2-3 for ; Thu, 03 Sep 2026 13:53:52 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49ccfbe062eso18297455e9.3 for ; Thu, 03 Sep 2026 04:53:52 -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-49cee7febb4sm70596455e9.14.2026.09.03.04.53.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:53:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788436432; x=1789041232; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=lmUEz1BSQEnPvhNy1tvkOzeOlVh/J2cVvdziF4BKMjs=; b=Ih9vcgnhfcT2+mbykv0H8lESbARexyDsrzxiCQ3TT1xV/ItZXrkP1+4c/6u/ZUTv6V ktJuiLlbFbFa3HDuOui3GaRusR8T29bZVpOXqbAvDxRueQZyF5qoyQ/z4x+PvHIIbEpI H6UO3iqAE8PESTWaXNevnIzbtelLfaqKyuVbdBd31hf8NO/8SzDYb65Q3r19Bi2PQ8jY jKUk0U3fcIoA5+a8ZJDyfGuE+bkgWOMsaY4Z+A3GbE5E02zdiqxHJn8/kaIpvZiDzgVM P5eJN6isg7JqdpYJUsv/Ge8qR06o8GQ/qt2LYdjzY2ofJaMBfv2qJ23Gw1et0MbjITrY JiFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788436432; x=1789041232; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=lmUEz1BSQEnPvhNy1tvkOzeOlVh/J2cVvdziF4BKMjs=; b=fCPci9uj1dZZGVlqNO8xH+1xvmcitWXKrE5DOfxoDugTgzGhU6yC9NNFKZjMgFaOvp 3+jDXqD1RrVYRLMFO9up2SGi+ODJm9g9g1JJsqMCjhKcAMVA3vojN/G8abo9K+HuNq6b FSBZL6/RpRapfQn8Q+p2sWRiWmUKvmPb38NWEm1gwtd3KY+Z5VtOmAQ4KytQ/n88LZKR laKxLuYMsLoDYkLAgZb3bnlb9Pk0W64nDxwjofSacah/BXTUCBrCvISjHwf71zftZk5e 3BJUY+nPqMnTIM+KIc7IR75Pt2TJY4ZxZYDhiLkj4XR5HFBdY1W2QzacFCX0FKOI08ks 161Q== X-Gm-Message-State: AFuF++nLZXbNnvCFh6E8hAmQW4ia00EmWtF+qWZi+8m558Rany5muiLI cqxS+VtP16Ajonvv8gxIhdxbuQxz3OCsJJG2zik5pwN/Fw3oFPqhrHO0hQ1DjgAXURq6ZHsfnmF LiM/IFA== X-Gm-Gg: AYBFou0ib8vvIqkCSUTljC0KSYYBNLXWPxQ8r0HHliOL56JdAQDkixIz5KCqfBT4yRZ lXFJ9yomnvRMxExh2CvKz4xDQSrTEY0KGPvEjjs7p2k1eALir1sY/1zD0bbUFgM6e01fpwwzC+q 8cem3EFWnuNkzoDvrM7Py5SIsghOxrOQylXU8Pss5Mx2weumF+GJsMQhcfjmnp+ItLBk4UuYRc4 RanJ8mH4qWzBXVh9C1s4UVXcqcdYwdgZww5G2HT7Ytcl2o/tt5OyArAz0uYBVC36kUAArVAwDly ZWHICItmOyS4EPGYgCxRm353duLPMcg15o+6GX0FWc6nx/zLXrMMeBcgIhy+qOUFA43T7RAwD5J /wQvL1LQmRklVK+EQt0VwgRrPchinmvBFYwujzN6/m6y0WfmjphrLW5tsh0QYpsxFueTHz4Goym gUggmQJNHPsma1B7QJs6KZhOumqxmbf/E8btQb4h9FQvf10e7dZAeulSrHr2HDFUiTrlrUuu9U4 btbNPq9cyDvUy0M0ehniwQoacIsQ8DqdumhCfaTP5RjR2JnucOp X-Received: by 2002:a05:600c:3f19:b0:499:93b3:91ea with SMTP id 5b1f17b1804b1-49ce582959cmr243680975e9.15.1788436432199; Thu, 03 Sep 2026 04:53:52 -0700 (PDT) Message-ID: <4eaf8244-25ec-45d4-844d-3d8f6720f57b@suse.com> Date: Thu, 3 Sep 2026 13:53:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 3/4] sched/core: avoid use of "current" in initializer lists From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Juergen Gross , Dario Faggioli , George Dunlap References: Content-Language: en-US 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 X-purgate-ID: tlsNG-4011c0/1788436432-59FDECFC-B9F8711E/0/0 X-purgate-type: clean X-purgate-size: 3501 TRACE_TIME() uses an initializer list and hence is covered by Misra C:2012 rule 13.1 ("Initializer lists shall not contain persistent side effects"). Use intermediate variables to address this. In vcpu_yield() take the opportunity to rename the existing variable which better would have been used already before. In do_sched_op() extend the scope of and rename an existing variable. Also drop a pointless (and slightly malformed, style-wise) cast there, and adjust to other one to by style conformant. No functional change intended. Signed-off-by: Jan Beulich --- Note that the violations presently are reported only for Arm. Similar issues would exist on x86 in Clang builds, afaict. --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -1531,20 +1531,20 @@ static long do_poll(const struct sched_p /* Voluntarily yield the processor for this allocation. */ long vcpu_yield(void) { - struct vcpu * v=current; + struct vcpu *curr = current; spinlock_t *lock; rcu_read_lock(&sched_res_rculock); - lock = unit_schedule_lock_irq(v->sched_unit); - sched_yield(vcpu_scheduler(v), v->sched_unit); - unit_schedule_unlock_irq(lock, v->sched_unit); + lock = unit_schedule_lock_irq(curr->sched_unit); + sched_yield(vcpu_scheduler(curr), curr->sched_unit); + unit_schedule_unlock_irq(lock, curr->sched_unit); rcu_read_unlock(&sched_res_rculock); SCHED_STAT_CRANK(vcpu_yield); - TRACE_TIME(TRC_SCHED_YIELD, current->domain->domain_id, current->vcpu_id); + TRACE_TIME(TRC_SCHED_YIELD, curr->domain->domain_id, curr->vcpu_id); raise_softirq(SCHEDULE_SOFTIRQ); return 0; } @@ -1914,6 +1914,8 @@ typedef long ret_t; ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { + const struct vcpu *curr = current; + struct domain *currd = curr->domain; ret_t ret = 0; switch ( cmd ) @@ -1938,9 +1940,9 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN if ( copy_from_guest(&sched_shutdown, arg, 1) ) break; - TRACE_TIME(TRC_SCHED_SHUTDOWN, current->domain->domain_id, - current->vcpu_id, sched_shutdown.reason); - ret = domain_shutdown(current->domain, (u8)sched_shutdown.reason); + TRACE_TIME(TRC_SCHED_SHUTDOWN, currd->domain_id, curr->vcpu_id, + sched_shutdown.reason); + ret = domain_shutdown(currd, sched_shutdown.reason); break; } @@ -1948,19 +1950,18 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN case SCHEDOP_shutdown_code: { struct sched_shutdown sched_shutdown; - struct domain *d = current->domain; ret = -EFAULT; if ( copy_from_guest(&sched_shutdown, arg, 1) ) break; - TRACE_TIME(TRC_SCHED_SHUTDOWN_CODE, d->domain_id, current->vcpu_id, + TRACE_TIME(TRC_SCHED_SHUTDOWN_CODE, currd->domain_id, curr->vcpu_id, sched_shutdown.reason); - spin_lock(&d->shutdown_lock); - if ( d->shutdown_code == SHUTDOWN_CODE_INVALID ) - d->shutdown_code = (u8)sched_shutdown.reason; - spin_unlock(&d->shutdown_lock); + spin_lock(&currd->shutdown_lock); + if ( currd->shutdown_code == SHUTDOWN_CODE_INVALID ) + currd->shutdown_code = (uint8_t)sched_shutdown.reason; + spin_unlock(&currd->shutdown_lock); ret = 0; break; From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:54:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:54:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407008.1640183 (Exim 4.92) (envelope-from ) id 1x261O-0000bt-Tj; Thu, 03 Sep 2026 11:54:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407008.1640183; Thu, 03 Sep 2026 11:54:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x261O-0000bm-Ql; Thu, 03 Sep 2026 11:54:22 +0000 Received: by outflank-mailman (input) for mailman id 1407008; Thu, 03 Sep 2026 11:54:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x261M-0000aF-Uc for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:54:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x261L-003YQI-T8 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:54:19 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995fe2-e002-0a2a0a5209dd-0a2a450cc452-28 for ; Thu, 03 Sep 2026 13:54:19 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995feb-f479-0a2a450c0019-d155dd2ea927-3 for ; Thu, 03 Sep 2026 13:54:19 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48442ea8f59so684489f8f.1 for ; Thu, 03 Sep 2026 04:54:19 -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-49cf5135353sm9405235e9.2.2026.09.03.04.54.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:54:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788436459; x=1789041259; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=l2RayKkAWwog2AMYT8SbLHsD8Cx1SeVefikMrauC6CU=; b=TxOMqNHwCvvIzrBjBCNoqMlQPp8iABIo0C+Wahuo+H9mBrKLoYXYLRq9txu6g+ckrQ kk1VXfvKoI/251cZThUBAjpH9a5cntjlsYBl0GfM5eNCUzwV11IH9McXqRbPrdSjUgP5 BQx9BN1rguVVqlzPMJix0DipWCSNXVnqCs3mdbDHDIe1lpO05rxzOIkrq37BW6q2GsQ4 xyCfid2tpJelxvZ7kYDXmc7w3IaIL8yf4xJEpEJMt68tx1PHi5t7a3teKANPJ0M4FAWK PQwfqj6L24PH1v9x1jj0Xw6e8H13u+634p5hZhYdIhkhTc/tV/TJ7zv3SiFehi3XFPm5 ew9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788436459; x=1789041259; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=l2RayKkAWwog2AMYT8SbLHsD8Cx1SeVefikMrauC6CU=; b=gyT5Et8YWMNl84bJC0KU2h4fm08ZY3mKCJDSF8RrcACuP34nd6qenhU3T76POLan1L 6lbEj9fsvTqC2/E2YFdO3hDPBy864y6indaoE1Wlj+jWbkC+QjErnjpWoPUzvV+MZ1oh m6SSllSlAXjvhYEzhWgZUOFJno9FY1hoDdNcUDpd3f1tB/EYIwAnkg4x/SY+bib6uwrY XyVbSI4Ld9KK3BzswvF02HPcVkwkL5B3M3neP/LBalECYwXvJ7Jsbt9ikndkGmzeUzim AvjmPiS51TzrKoQWC3d0m07g5dlBMU4ogpHQ9rBNk3m0T3LDGYhIZw7zdedF+yyrHjuO NWrQ== X-Gm-Message-State: AFuF++nmUeMJwAc0MpAYtB9mcuOKgz7iMJaW5BQw3gmglKdOfGfAH6ft L5+nVECaciIoJEia5hKHcf/j9xoSoTJ2kxtVgt3kjurxIpm6eGQH9MlYH0hJVMQUuPWeqf0uft6 HOUoKng== X-Gm-Gg: AYBFou3I61E581Y6+F9s4/j4Jm6scet7aqAGDjr4xiFkS6Gs0Cd+dzWLsF9oNBaAA4C qSf7Wb6kBQVusfVtaUn+U56qpGXkWfL+F4HmRSibjSyrfFQmWv3PAEsk9ab/RLlhgQHXoENWdIm 7YeuAH9vNaRkytVr4g39bJoGyAPxsgrzKodX8DsiQcxoXANgVcF2e6Y1mmFPCkrSk8NdR+o2jHC hCokuvfC+5CNv5W32aUGoQAIFQe4dh7G4LTTHv07mro0RSZ4D3R6yqYQI/r5kQQFyh5/348wOb4 /Ot07hBjvRBApTMVZQtXoryL9VTI3Fdsc3KqhQeh4xQnqmrWJ/8PzTheL3n5kG7F5DlTSHFhZcp 5bXBFFJYP3VJHtTj7LPknNavO8Q3VlNo10NyOZBzS/5SC4BeQiJ86v/vg6iaLxO1J6GqDhrigvU jGZ+kumvOyFX6B1bCyfJYiCT+irSw8qNy0zEvMEZ008QpX2nIomo8WOuWyhkjcpzNefBPMriiaS BAoVl4yX2pzJ33zMYi9b4yPwxJNEoKGLS4W4FL96br0SpgsEm1b X-Received: by 2002:a05:600d:4445:20b0:499:59fd:dbfc with SMTP id 5b1f17b1804b1-49cf1577d23mr25009095e9.1.1788436459066; Thu, 03 Sep 2026 04:54:19 -0700 (PDT) Message-ID: <4952eacf-06ad-433e-8d0a-14b704888d21@suse.com> Date: Thu, 3 Sep 2026 13:54:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/4] automation/Eclair: tag rule 13.1 as clean From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US 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 X-purgate-ID: tlsNG-d25034/1788436459-03AD4A5B-2D375781/0/0 X-purgate-type: clean X-purgate-size: 343 Remaining violations were addressed. Signed-off-by: Jan Beulich --- a/automation/eclair_analysis/ECLAIR/tagging.ecl +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl @@ -66,6 +66,7 @@ MC3A2.R11.7|| MC3A2.R11.9|| MC3A2.R12.2|| MC3A2.R12.5|| +MC3A2.R13.1|| MC3A2.R13.2|| MC3A2.R13.6|| MC3A2.R14.1|| From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:54:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:54:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407013.1640193 (Exim 4.92) (envelope-from ) id 1x261h-00012Q-5b; Thu, 03 Sep 2026 11:54:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407013.1640193; Thu, 03 Sep 2026 11:54:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x261h-00012J-1i; Thu, 03 Sep 2026 11:54:41 +0000 Received: by outflank-mailman (input) for mailman id 1407013; Thu, 03 Sep 2026 11:54:39 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x261f-0000zc-Kw for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:54:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x261f-003YVd-1k for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:54:39 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a995ffe-e002-0a2a0a5209dd-0a2a45019da2-0 for ; Thu, 03 Sep 2026 13:54:38 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a995ffe-5984-0a2a45010019-b9ff1c238c8f-3 for ; Thu, 03 Sep 2026 13:54:38 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0671eea1c000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 11:54:34 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id BBE4683201; Thu, 3 Sep 2026 13:54:33 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=PTTe91P5vC5tyBRcoyF+Vov74RZqp+9k0MML3LUnyY0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=qJjj4pFRjgMMsMKG6gtfr7VxhC0fJQE7OngNsF0/I+YJbkf/RmoFFju794GfpQz6Az08a1HJ7 wggxkB1MgKRNN/YEFYO+eaaOcC4bp6RdG6nimtDENNo6qR32MaII8v/C3WL29C2BaPh7xiq5Ftc 0DFeHueY4TG4RZ8AMio7su1Sw+MPksXZy1VkQ91JM4RlrPGXZsnN0RalpqynYZNng4V88or1pry toIi7/2a/zhCQ6waUQNkDK5lBcMOMUg+9Rwh1BgXM7kFs0Kk6HEx3DHpYcE7RESSaovTLUfxR+C 5eEipMWsAq7KidaGqY4qqjoHz5poLjJtAg3hMc0Uz7sA== X-Zone-Loop: 638599f3dd12429a482c9d37adf9d919c9a4c3f84fd9 x-campaign-type: default x-transaction-id: eb933437-0805-41b9-b060-e532b1d7d7b6 x-swg-uid: 01-1fc55639-b01d-4c01-8a0c-616f91a1f206 X-Mailer: Sweego Message-ID: <1788436474.8631fc262581453bbf619ec5b2062170.1a0671eea1c000c4f3@vates.tech> x-swg-bid: 1788436474.8631fc262581453bbf619ec5b2062170.1a0671eea1c000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 3 Sep 2026 13:54:33 +0200 From: Anthony PERARD To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Michal Orzel , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Teddy Astie Subject: Re: [PATCH v2 5/7] build: move $(all-symbols-*) References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3501.25240ac73f40bfb0.1a0671ee82b.d239f7e1bdcf7930=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788436473899 X-purgate-ID: tlsNG-d62444/1788436478-BD87F757-684E84F9/0/0 X-purgate-type: clean X-purgate-size: 726 ---=Part.3501.25240ac73f40bfb0.1a0671ee82b.d239f7e1bdcf7930=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2026 at 02:02:57PM +0200, Jan Beulich wrote: > With the final linking logic now consolidated in scripts/Makefile=2Elink= , > $(all-symbols-*) also doesn't need setting anymore in (and passing down > from) the top level Makefile=2E >=20 > Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.3501.25240ac73f40bfb0.1a0671ee82b.d239f7e1bdcf7930=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:55:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:55:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407024.1640200 (Exim 4.92) (envelope-from ) id 1x262g-0001cw-Dq; Thu, 03 Sep 2026 11:55:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407024.1640200; Thu, 03 Sep 2026 11:55: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 1x262g-0001cp-B6; Thu, 03 Sep 2026 11:55:42 +0000 Received: by outflank-mailman (input) for mailman id 1407024; Thu, 03 Sep 2026 11:55:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x262f-0001cd-HV for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:55:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x262e-00Ecnd-UW for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:55:40 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99602f-e002-0a2a0a5209dd-0a2a4503a1fa-36 for ; Thu, 03 Sep 2026 13:55:40 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99603c-fae8-0a2a45030019-b9ff1c238fc3-3 for ; Thu, 03 Sep 2026 13:55:40 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0671fd55a000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 11:55:34 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id B197F8215D; Thu, 3 Sep 2026 13:55:33 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=fj77rrklpv28SnTWnT75XZ81Gv89/dYHDb4FdexKTGo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=ItnmyiRx6NpAtF30V8psL/GvubOCNjV9AvvqTxrHXXz/YQ8C9QCP9JC3HkF304d1vjF0rf1/D D5y0h0WI09TM0M/kJQob8Lya0TuS8hSn4xo/ecHgkCXz1pIGvLF6bD6SE2CAraeRPdY7lxT15tu 5DfSxrQ01U2Ud8hB4Ob/gCRqD414roh1RvMwc1MWS2a0x4wFDsll/9EWHboFoD+gkhmo0pJMplB t2WQL4zNUTe50w4ikEe8byjmgEMebrSdXGWiNxYgPze1z/0oWBM0c89+sOUOgjT2sab87YklY/Z CUSAQrrYq2gzNramktoSqM2yYMD6My4u2jxq68r9dJjQ== X-Zone-Loop: 38f5ba981f6bec0a06eb3fffe7071c02b1c282c46293 x-campaign-type: default x-transaction-id: 3b3246e3-9428-467a-b88e-0aaf0abd0031 x-swg-uid: 01-64519f47-0aee-4619-8577-5a81aae277e5 X-Mailer: Sweego Message-ID: <1788436534.8631fc262581453bbf619ec5b2062170.1a0671fd55a000c4f3@vates.tech> x-swg-bid: 1788436534.8631fc262581453bbf619ec5b2062170.1a0671fd55a000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Thu, 3 Sep 2026 13:55:33 +0200 From: Anthony PERARD To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Michal Orzel , Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: [PATCH v2 6/7] build: move $(compare-symbol-tables) References: <9a78fdea-08ba-4e04-bfa1-ba09730a300b@suse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3502.9bd76891818bfad8.1a0671fd24f.8b2b4ca9f404d1c2=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788436533839 X-purgate-ID: tlsNG-33051d/1788436540-6DAD44E9-17671A7C/0/0 X-purgate-type: clean X-purgate-size: 704 ---=Part.3502.9bd76891818bfad8.1a0671fd24f.8b2b4ca9f404d1c2=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2026 at 02:03:26PM +0200, Jan Beulich wrote: > With the final linking logic now consolidated in scripts/Makefile=2Elink= , > $(compare-symbol-tables) also doesn't need setting anymore in > Kbuild=2Einclude=2E >=20 > Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.3502.9bd76891818bfad8.1a0671fd24f.8b2b4ca9f404d1c2=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 11:56:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 11:56:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407035.1640209 (Exim 4.92) (envelope-from ) id 1x263a-00027h-Mo; Thu, 03 Sep 2026 11:56:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407035.1640209; Thu, 03 Sep 2026 11:56:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x263a-00027a-Jt; Thu, 03 Sep 2026 11:56:38 +0000 Received: by outflank-mailman (input) for mailman id 1407035; Thu, 03 Sep 2026 11:56:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x263Z-00027F-Cf for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 11:56:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x263Y-003Z1k-PI for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:56:36 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a996070-e002-0a2a0a5209dd-0a2a4501cb4c-14 for ; Thu, 03 Sep 2026 13:56:36 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a996074-5984-0a2a45010019-d155802ca9cf-3 for ; Thu, 03 Sep 2026 13:56:36 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4954a9e8490so5279335e9.1 for ; Thu, 03 Sep 2026 04:56:36 -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-49cf2abe1basm35065685e9.10.2026.09.03.04.56.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 04:56:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788436596; x=1789041396; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=waRvMqfy27r7nbt42a8Xce+90OERlZt5ATTotMJWspY=; b=C7qxoelaUzl7vtI5RxKZgOj049Q6aLH/jdBHkTyRY/uLrORcAyBWb9C8vjB/kxHnhn ZPPCPUFyVJrTEYreWGoFpsCdb3x6mTltiEPo4dcxyAhdQNx6EpH7D0Fn1voalc5rF7h4 3J70ifktd57gVshsOpfFpO5BzhCaVCf9CtietrvmgxJn2fhdk0SuoYLhKCSZ23hsF2Op ZjPvN/gOkob5fPv8dSmciKEbbNeF0DD5c4vlC4QZz2UfYTPQZ9tI+DHIWrkN/WAl22IE SaqRcU6dQiEmpv2z5RZPFICZaGshIfogrC6TiNTelJ13sUtxwfr/torf0H5OaATPLNL2 HSug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788436596; x=1789041396; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=waRvMqfy27r7nbt42a8Xce+90OERlZt5ATTotMJWspY=; b=rwkhRK0X1ml0kKeKIkHH7U31PTjAFmkAJ8MmUg4Sm+nnEhqm0y557NfWsNmHmUqD53 VuBiunbY3eKMEdw9UDClr4sHGjQnmzvOKa3LM4QgG3Q9qRqo2ac4PhlicLRE27z6tq/I ZNfVpk0Bqjy7/0VHFP3o5tCIyEohwBCS35RRMrYgougUnIKOIX7ZfByRC5KE4jsT040O nZhD6fb4BqlbSDN7eiETSkW/qNcANt4RvAtRZ6MQ3B9bJsXG3Tkb1VdCRyusLF5h/ke/ 0C7Cb0OIU6oMY1LKwCkaI81jkBn8xreFKqX3IpEbSMHrvRO6UzHLTM1gGkKuHlHuw47t GTBg== X-Gm-Message-State: AFuF++nHmQIAFDwwSRetkeK49ahcpwk05P66rSISXqgxVq3+nGOoLHEk atkJ4BoOTXTUXXbD62eW68snJwOP22xiZpoTqawb6rnzakI0Yh0p5Rrfw5hfPIwfv6dcefWs66t JiuK8Xg== X-Gm-Gg: AYBFou2nC2aBIxo6TfR5oC+CuD4kE6okDO1QFQxMo3vIAXj6hBHJDzwg+C7dx/Ys46j lJ3eBmu2b9n6TRmOUD2o2j1nczXHuk7RPy7YdEg//X3b8Kksb2k4AoUTKsveRd57B0MRcS9Cmue nOgRTGqBRiISZKeAGJOJWuRROEXf4NVyxY11xeyPJDix9yIQ12ReM+3/bXu0JkplcCWAuysWD12 9G1X6Pg5XL/qF9VxL056AqshLL4EUdmz1zPUkOwC7S24y0Ba2VGRgdoZH6nachV8MhlxSIBJIUm VLjyBf3ZpvshB5KRwOSgQsexgG4qcrRa/JfRgc8ueo3BefSTLUJQplJms+08MnJGCOwom4tg3Ph Yo5nNBhsOXe36Y7oIi85c8k0rfAfSXO1PZKjipsw2yvRz9CIrK9kIPSJH4TfyuDaXXdvIjSk1Bp FtB4A82kbRqnnJErnWABfNb+33cZMRF+FNLB2xhRJa04r0mZZVxzG3qHhOzisilssOYm6vLyuZN JWfaRpYd65oT95LMvxnKiFovzIN7QuOca1w/8IodhrN7V8XlNM3 X-Received: by 2002:a05:600c:a085:b0:49c:f13e:e4e with SMTP id 5b1f17b1804b1-49cf15ab3c1mr33592555e9.11.1788436596107; Thu, 03 Sep 2026 04:56:36 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 13:56:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86emul: adjust file comments 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1788436596-BF86F757-F487A29F/0/0 X-purgate-type: clean X-purgate-size: 1052 With the split-off of decoding into a separate file, both files' top comments should have been adjusted accordingly. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/decode.c +++ b/xen/arch/x86/x86_emulate/decode.c @@ -2,7 +2,7 @@ /****************************************************************************** * decode.c - helper for x86_emulate.c * - * Generic x86 (32-bit and 64-bit) instruction decoder and emulator. + * Generic x86 (32-bit and 64-bit) instruction decoder. * * Copyright (c) 2005-2007 Keir Fraser * Copyright (c) 2005-2007 XenSource Inc. --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -2,7 +2,7 @@ /****************************************************************************** * x86_emulate.c * - * Generic x86 (32-bit and 64-bit) instruction decoder and emulator. + * Generic x86 (32-bit and 64-bit) instruction emulator. * * Copyright (c) 2005-2007 Keir Fraser * Copyright (c) 2005-2007 XenSource Inc. From xen-devel-bounces@lists.xenproject.org Thu Sep 03 12:13:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 12:13:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407075.1640220 (Exim 4.92) (envelope-from ) id 1x26K0-0006hj-B1; Thu, 03 Sep 2026 12:13:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407075.1640220; Thu, 03 Sep 2026 12:13:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x26K0-0006hc-7H; Thu, 03 Sep 2026 12:13:36 +0000 Received: by outflank-mailman (input) for mailman id 1407075; Thu, 03 Sep 2026 12:13:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x26Jy-0006hV-Qf for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:13:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x26Jy-000tMa-7J for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:13:34 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a996468-e002-0a2a0a5209dd-0a2a4502aee8-16 for ; Thu, 03 Sep 2026 14:13:34 +0200 Received: from [52.101.43.37] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99646c-6ca4-0a2a45020019-34652b25db6e-3 for ; Thu, 03 Sep 2026 14:13:33 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB8195.namprd03.prod.outlook.com (2603:10b6:8:261::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Thu, 3 Sep 2026 12:13:30 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 3 Sep 2026 12:13:30 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CzvmpWYWj2vY3gA35a+AU07TSuCvov5ejGljwzYg1PUuhxo8yezz8QJdlpHphdwzHMi/KEsPdLo6oLvZh9C0qXe0wehIupV+D0g0ER5AR7Apy+DOnIqS8XTc3nhAkTjAGpnZTTJfghHFNVM91nU8Xqykv3naFke1LkbYSGFbbn4G0f8aluLjJfrQpnhEcCsQrOuRZVYwHaiMtXk3x9sYH1LLBxgfxaSbMj51ASgEKj3ROzWjtnRA6XvSC8Dd+Lu6lYTb9n8ROYzRIQv7o5GLhewiAOhQGzx3SjVkJfSxOnPQr3VuCnOjVc9Sg+yYu4j1lEqYX25wft5/Bsi0VyiArQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iyqvG3i8EX0ls0rhCyfDc5DGh7QE7Yy6JnrwEKDtFXg=; b=CaJuNYkreKs24ixir0eQ7+Ji8J2h/h5sTg2SNqwAz8pBE9gAhVJb5vkDyduJ2EoX8tkZocJB1kOBsEHgLTSDmdKv6B/iZHhAi6lcE6z4zh6gjN7AWQBD5WjvlQT0JbyZN7A34G9c1Hd/U+gLTqI8U+L47m01xFjCGz5tc7qEZ+2sQSogEQziNeH7Umro2SGpK0fCCnmG2+o17h8ghd1PTQm9fkT4BDp/w8Zf2cpqWx2FtUk0EBk8KrdOgwZ/dNDU94QxpP62JENtunXoiy6eMQXD9ab8tKQbneuevyIZncDCmkDxu4umRUkrX76cXfARKjGImlGkTRUxRtoE09OW7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iyqvG3i8EX0ls0rhCyfDc5DGh7QE7Yy6JnrwEKDtFXg=; b=pmQXbfvVkUIeJSn4jUEc/uo1QBnblDfkTXqreA4Zr5F4uBFPA0LVi4gfKsn4fzTZ34dkEnLuJ6IINoyY7LEeqM9Yj5Ts9jfe3xGXMBCoLj/culpPVpDXIZt/+18oeqA8b/l+14s68qJqyGSqzzTYVkV0yKYh3ti5ydDnwpFe/bk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <64a1aa96-75c4-41aa-b656-f42a68647dbd@citrix.com> Date: Thu, 3 Sep 2026 13:13:27 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86emul: adjust file comments To: Jan Beulich , "xen-devel@lists.xenproject.org" References: Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0291.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:196::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB8195:EE_ X-MS-Office365-Filtering-Correlation-Id: 75b99242-73f2-44e8-f1bf-08df09b4c440 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|18002099003|22082099003|56012099006|10067099003|11063799006; X-Microsoft-Antispam-Message-Info: DMcyYvElw1/CbwPEAbWhnsC4oPXQcfv+FYSs3AvlQTJ62Ti7mqqHQBGUMwSKbbN3tbmz5qHbJ7VDrasARsn8YxLRei7uo6Jg8papiiXDoNQhCiZQ1CE716afawnbIMker/cscAheNsc6ZvCUjqfWOG6vn3gFGW7ewMC6yKTczu1qNjR8QUMjcQLceC5OrMZWIhZP7gz/o4SJEytViQDFxHphU3iU5Dxqa443MEH3U6hUGMu7Iskz5C4CrUVZZbTUyBXuBlbqwPL8ejE7wUbfI78bWHBPMhD3a9kj4/oyb1ZXspkaS/zjM0Zb80xY6H56g73TyXjwHMfS+eljxxmAJed3XLaWTmEFqQ3uxv/y1DvazLDVN3QOwliYRY7e3jYHDOAZYD2jECXmGTxVC7C0Aibi78GwZTS/vsg48S8/xt0WoBbVk/5lHTuUdYuj5Rh4SXdaUxTI3vQuMXU5EL6k9YEuekaviptn7+LRArIjrU0LIxmD4NZhiGfOtTeR6bcDWUqkH1gLh2LgTwABwHVpd6BCtTZb0COqQlI6O0At0pUgQO+ZOxIHnNuDrCeKPCps5ldtL0geNr6ZN3sy4PeeDDLFlFO5E6/xF/qMJiDjnqApg39bfhHU/hHz81hfm12K98OAlhbk9VTa67RVbIKQj/uc5QYTdOWS9hEf0kKRqCc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(18002099003)(22082099003)(56012099006)(10067099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZkUxWi9WeVA3RzJlam55dTVqK1NWZnRCWXVQUVdKRG85R01VNzBxZS9aajRM?= =?utf-8?B?WTl1OXVoSUE5RmQzU2tTRWtxVnpqQzdKd3VmZDVXRGp3TzVtd2sybDRYakd3?= =?utf-8?B?Y2FCamE4c3N3aUo5TG9SdHIyZHZObFNPcUV2TmxOcnBNNFBMRTR3b1JIeDUv?= =?utf-8?B?YkJaWDhQNnJjeWlmbHYxVmVRR2N1S0VoMndOdnhmVWxHRWxiUi9PM0V0Z1R5?= =?utf-8?B?WlBybEJiN1NxR0MzYklRQWxJQU5VdEJIMG1odmQ3cEpYOVlYcTduV2dmY2hG?= =?utf-8?B?NXRyekVZeVZXbGIyRWg2MW9TeXJhbHRha09XRWpEUjQ1SHBZR0ZMR1JIYW84?= =?utf-8?B?aFhER3hNYllsV1QyZUcrU2JGM0p2NzIvSmUyV28yMmpzWjYrTE9md1JvVkxP?= =?utf-8?B?bTVtMUJheWhaa3NLeFRycWFKaEc0TGNCOW9KRmluYVRoV3doa3l5aWNQanlJ?= =?utf-8?B?akJRNFdoK3owN2VNZXlGVGV1elZjU1pLYWpNTmN6YWJLZDVuUnFYRHVGbkRy?= =?utf-8?B?cGcxVVYybU9EM0YvdGxTRElBMmJXcHJDeWM2RlFvcWg4ZElUTGNkb05xQ21C?= =?utf-8?B?S2pYRE1Ud1lDeVVINGd1U01pa0FZNitJZ3EyRERLZTBaZEVycWdXckZUUTgv?= =?utf-8?B?RWhGVUZrV2J6cjlxZXM5SHBuUDRzZlVTY2FBVE8yTHMvT0VEOTIyaGtEVTNG?= =?utf-8?B?QjVoekFGMFp6Ui9ISW53WGlqUkZ5TGprOUZuajcyN3lzTnF0ZXAyRHExaUFP?= =?utf-8?B?TU91bHo2aUphcUJ6V2c0VzBsSmZxdThiMWlRVmRva0VxYnlRZUhyUzFUMUo5?= =?utf-8?B?WU0vSCtQYlpsZGhwNzRYWGNGNXNmM0lmWW53NTIyVDNDRGE0RXlyb0d2VFdI?= =?utf-8?B?QnZORzhXeXZpTjlSM1RpTndhWHZZZUJJTVZqWW1QOEF5U1UwWG1mVXlsRHpj?= =?utf-8?B?TjZHVjlIUFBvdndMblFEYmt1M2d1c05OemxzTkdvem1oRlo5aXIvVTJGeTF5?= =?utf-8?B?amdSZkZPa1BPc0gvWE00NEkwVy9LZ1lPQVVqS3RkbUVnN2tpTjVjSmppajhQ?= =?utf-8?B?eFdoNk1aczdwTTlQQWFTYmxoUE5QK2lzZkttbTV0U3pibzhOem03V2tVUjEv?= =?utf-8?B?KzdwRnMxNDZNQjZHZG9UUk1MeEdTNUk4RVhlZ3ZUNHRUY0lyNW83a3BxYmJn?= =?utf-8?B?WHlWNEJIQThyN0hxaEkxYTlZMFBkb2RRYjZVNFcwdkdzU0ZIdTJ0ckxTelJy?= =?utf-8?B?N0Qva0N4aWhMbXp0bFc3NnNGWVhVbVc5Ni96NjNidXVQZm93YndBOUNNQjhj?= =?utf-8?B?SjB6WUNZWHBoZnBUekYyVkowNzhvU1VLTHA3VjNaMmNLSkViUDRRdHpkeHRz?= =?utf-8?B?dGJnTUtkcURnbURqb2g1TFRDOS9yQVRydnhOY2xidnpIMHJjb282SkdGMlU3?= =?utf-8?B?L090eFpmcWhJK3UxT1pWMG5ybGhIVW5Pb3hCOEZqVWJZR0hIc3g2cXZJRG5m?= =?utf-8?B?SWNRdjgzK1UrU1Z6MnZaOUNNTkVadlV6bVBqUHUxU0tvbUsvQUtWTnhQRkg5?= =?utf-8?B?NmZhU3VlYnIwRUZMNWZIU0FGSU53UlhZQ2NNdEpyS2hZNnJPVVEzL2k2OGFy?= =?utf-8?B?RHRCQUhIQXZkVlR2cVByeUZtOFpPY1dZWTBac25LQmdaZmQ3NXlCUlVsZDJj?= =?utf-8?B?RTE5NXUrVzNucDUvcEdrV0prbjNOSUVHZkdDOStrKzZxaStYbG0yOFJDR1Nh?= =?utf-8?B?ZExSVmUwWGVqQ09hVGJwZk1UcFZiOXV2ajhRN3BmYXQ1YmJZSDI5K08rRVcy?= =?utf-8?B?SS9zZ2IrRGo5YVJXTlJlQkFtcGU3ZFJHOU0yQ1pCcFpyWG9IUndib1IvYlVS?= =?utf-8?B?R0l2aFU0c2NSa1pDWW9ncW9hbVQ2N3FabFdEMmphQkpRNFIydVZUd2RRelVH?= =?utf-8?B?Ylh0dExIU2wvRjRBT0I3Yk1saWZYZjkyckVwZkgwTjZoVmM0Q293UVRtOUpo?= =?utf-8?B?bklsV1hiSHVhNGxkMWU1aUE3TTNXK0NxSGl6Znl6Q1RiWHVRVU9FSTJZWkx5?= =?utf-8?B?VUI1RXZsYXgzb2lmazlXMUdkYnR3eWp6NmV2b0dPUEI3ekp1RTVMMW0wS1Zv?= =?utf-8?B?QWlpMVRXL3B4N1UvaTNaY1dGMEo2TFBldmVRSkw5WGNLZzNPbU93TURxUmQ4?= =?utf-8?B?SmFlZXl1SzdsODR3R3YrdlVyYkkxS2J6MTNTa2lrblZPNWl6aEZjakhzOVlO?= =?utf-8?B?OWJkWTNmVGdLM3Y4NVFCbVNDWFNqUVdOZThWV0tyaURyMHVSaytPS2xXazVM?= =?utf-8?B?UGM1dDR5TWk0em1MM3l2UW9WVlpKYmdQYmJpS3h6cUtYK1dGcDJ4dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75b99242-73f2-44e8-f1bf-08df09b4c440 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 12:13:30.2960 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ll0lVXJvXzBRT3OMpHgsuYrgZ4aRvLYwyWjWRJMiQYo0kJgVmxVhX6/qD5kCbQcbtqDiH6956RityqaDkRyv46XpR+sobgumAbbTsngV+zQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB8195 X-purgate-ID: tlsNG-720697/1788437614-305C52AC-21422C14/0/0 X-purgate-type: clean X-purgate-size: 275 On 03/09/2026 12:56 pm, Jan Beulich wrote: > With the split-off of decoding into a separate file, both files' top > comments should have been adjusted accordingly. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Thu Sep 03 12:17:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 12:17:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407084.1640227 (Exim 4.92) (envelope-from ) id 1x26Nl-0007Il-OW; Thu, 03 Sep 2026 12:17:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407084.1640227; Thu, 03 Sep 2026 12:17:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x26Nl-0007Ie-Lm; Thu, 03 Sep 2026 12:17:29 +0000 Received: by outflank-mailman (input) for mailman id 1407084; Thu, 03 Sep 2026 12:17:27 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x26Nj-0007IU-Ku for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:17:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x26Ni-007NE7-Ol for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:17:26 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99653c-8faa-0a2a0a5109dd-0a2a4506e008-38 for ; Thu, 03 Sep 2026 14:17:26 +0200 Received: from [52.101.84.41] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a996556-195a-0a2a45060019-34655429737a-3 for ; Thu, 03 Sep 2026 14:17:26 +0200 Received: from DU2PR04CA0156.eurprd04.prod.outlook.com (2603:10a6:10:2b0::11) by PAWPR08MB10238.eurprd08.prod.outlook.com (2603:10a6:102:365::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 12:17:17 +0000 Received: from DB1PEPF00050A00.eurprd03.prod.outlook.com (2603:10a6:10:2b0:cafe::5f) by DU2PR04CA0156.outlook.office365.com (2603:10a6:10:2b0::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Thu, 3 Sep 2026 12:17:17 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB1PEPF00050A00.mail.protection.outlook.com (10.167.242.42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Thu, 3 Sep 2026 12:17:17 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by VI3PR08MB503919.eurprd08.prod.outlook.com (2603:10a6:800:374::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.10; Thu, 3 Sep 2026 12:16:43 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 12:16:43 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=B131Em2Q/20YS852OiAxwcLEBD1X/aqqFEZ5flcbTCgE5yWZ1pl/YKHjT0dheTWgvOqMIE5I/HaCtK6AgBWOVvxqFDAQ7SyM2DxMRbskSspsgWPp9fTkORUiMh1+wpgv1PmMEx/OS+DG2c/JcBXGZZs+DVDGUFVPLQlGm523cisCxoJwSD+3T3ljPL/0LKkjJSVSxb8/nmau3CNKWE4kWJZQFW79KK10RBCTzbjRLfnVYku+ck7p0JrZqr62i0eouHhG8z4v3cN1JUVvkReEopfsXsm91fbbmruK6yuYek0Y32GGhfWRob2+vY/RcVXVwVHcXFFlIlnJQWE/HR8aaA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=almdTduugfhJxPUhUsAMBuCWjKuuztE0KCai7PylSxI=; b=H0nG+cqiqonuzsbrvtCgA1Uc8/bHFr4IRo3RahTmgLXcbvnAZbp0jS1kDvUNDZJNu4TITRpGs1af0iQs0Gt5bauVHtcraGdv7sBwYfT9+t8GqiGJDC+utanaicpc94iuiRAgiqJWYtXAUhYC7nTNyNiNcXNLldTjf9OrcJAFFwUOwUCsDC81Zwi5Y4T8rkpdZ0ha57u0aUCYq6YshguF+EHuGqiDx0d70RMYgMkkcNqCAHQSmT8GB5miatXEVUcnCaUIuTlnSv3z8NflZMtVRSW91OxrBPBwaFdYl/e1HU/3gnUaxI8A0PM/0rKHnQavu1/B7utAbHcJSU2orHAA/g== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=almdTduugfhJxPUhUsAMBuCWjKuuztE0KCai7PylSxI=; b=gAsNGRj4R3Qafa9Z+LDr7YHTOOIx1TMXOyhGcOJ4tLjtVs+wOOwshmBZLHq1M4Mb3vgkM6/cTZ/9xZI4H24Y7XbpbOiQi7OnoH3rvC+FBen7SsNKVF6UgnV/KhBDCv0oIEbGIb0Ku7wcz13WKUzq1ehqxUZBzjzxqw5c7x5SlHY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JAllUQ0tprERnA2uOXwj+y2w4DnTSlHJRyYytwqjL52kxy3zOWuIvAe2ahgKiwKBNl4kizbJ/WHDVA4Nd/q4kQZsCcKf6U2tvIEqYL3YR65WO61QZJTeFKb4OIXVAJr+FHKftNEzYeMjDaoYm4fDX+Js+kAo04IsUVXjKASVF3jIL56GIpOIH8xu3wjhBVud+R+q8C21sOyzRrMbzMZ6gFAcuzJ0ZvWVoifn+9hI3l2zB/ilhAqc1XJ2zOSYfBEHCZBrh/0XIwtSer+yG8L5PbnZA1vSfrGoyWDRWefTjmezb6byWujpRNByeTuCjqmdf0Yjxf/FyR5vnqkOGox//A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=almdTduugfhJxPUhUsAMBuCWjKuuztE0KCai7PylSxI=; b=u7x6S9JixaR6copODYPmDsHcfnOpYzi1RPC7PdM2nOXFSYZsw11bXSEZ3zLqY0JIb3nldVjxOTySmTdm5s1MQd3LfuGHkt0XzODlfCslkizbs6jTkaT8FT27XW9ROQxXgZpZhp8GCagp/2bbyTcMq0TwNOfdFk7MflkuqErHYFszqTztHejV7tbz/VaZPgWScyfPSbkxftRvK1tUWsL8OqaA4gfwpJIYAjSFpef6e4UFxzsspLmoJsSAOtsv0tVT/d89lcBp+MVpvyMmwlRD3LDxKAh+pzvkcdgSB5TNjrzh5nUlqSRNJIjmPoE69HhdoOwjB1/b36zTh5dueaPOHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=almdTduugfhJxPUhUsAMBuCWjKuuztE0KCai7PylSxI=; b=gAsNGRj4R3Qafa9Z+LDr7YHTOOIx1TMXOyhGcOJ4tLjtVs+wOOwshmBZLHq1M4Mb3vgkM6/cTZ/9xZI4H24Y7XbpbOiQi7OnoH3rvC+FBen7SsNKVF6UgnV/KhBDCv0oIEbGIb0Ku7wcz13WKUzq1ehqxUZBzjzxqw5c7x5SlHY= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH 4/6] xen/arm: Rewrite arm_smccc_smc() for arm64 Thread-Topic: [PATCH 4/6] xen/arm: Rewrite arm_smccc_smc() for arm64 Thread-Index: AQHdOUMQZh82tXnNpUyZDf50Fke+A7a8yZeA Date: Thu, 3 Sep 2026 12:16:43 +0000 Message-ID: References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> <20260831121944.2908139-5-andrew.cooper3@citrix.com> In-Reply-To: <20260831121944.2908139-5-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|VI3PR08MB503919:EE_|DB1PEPF00050A00:EE_|PAWPR08MB10238:EE_ X-MS-Office365-Filtering-Correlation-Id: 57b68ae3-c412-4713-136f-08df09b54bcf x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|10067099003|3023799007|22082099003|18002099003|56012099006|4143699003|11063799006|38070700021; X-Microsoft-Antispam-Message-Info-Original: eepBfxcGTqoiUvMPlg79uoS84YWsK+cD0kkd38Cutkw/i6jCVvuO2yk8YPFL/eGL/2w2Xf4CjLT1Rxq4eoPsQuUbmTdJVcrjI8qrTMPtJQ+msuyNZYYeKWNUhfFcokEh6mYQVxxI07XsDLYWelUIc4vAVJlhihNqnJm9oDjwegAlUYFpWIwZKQJR43zrfhnSvDDl3aa8Rj9dT+2MDlCJhGoiTVHMnJidFmkFqg+aHDUaHf4WXyhGa59lGhoc3TAjBNDDDAHGw1wxTsEBS87q96sCOQcoy+Acd9qyaxJxNakQC3137bdH0vsq4dJALl83BrRcJki5aQQvCUSn9VvBohhVjp2dN+LatsktqQj6UewMohFszXIGbICuBLjKrjUM7uLeCYB8DEoPETUddiC4QnREjKfrl2Q83VR13AovqwcvlYzLJWfKFWLiancd99NU17bgi8gWoKo3kVU2SVjlIKZxyKbrE8uRsqrpiPq3oLIahhA7nR6OVsFxBF1yvvyTasoqpwENlptTEo0FV22nr/DklAp1zESZDMEz0ewSBGz+zh/rgYNIVJSSTvtUodUeVcjSAvWVt2B7rQuIkZvPnnQpjiLWAf+LuXgvL7oOq+vMWWV6BebjjsVZnvY5gyvsyY1B4y2AvQxyCS5rwYKCv9DFs2/LVh4IeB1crUw/eIvcyPWO9BAKx/ODay5yyxJUuKKRN5W/1rMB1KYPBTyyNLfAziCkeFjXlICjf/qbsOY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(10067099003)(3023799007)(22082099003)(18002099003)(56012099006)(4143699003)(11063799006)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <1A8FD8E2C3248948A60C4CD3FECCB6A9@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: BdgqUmpwEibNgQAb9xHTTUwOGOuX/k+zJ5gLvTncjtYE15JgYgtRe0GotXTVGYej7ppDy98fZcyv5qvkanRRTVah5FJivNjDYYXdpiLjkoZ4CKUCN5h+/IFWQfWMbCYOJY7toXtI0hgHaBXeigP/skeNExTZb+yvM9taQpr8WAgd2xRiY280cxmjD40pybLRdNG2BPUZFecXKuvfqpo8+Li5Le2y2rJb7h5Z145nDKMEmq0n31EurnpVZc9rLXp6EaTtL+U/0n6R5SEVTrWEiObj7gW9aRZiYhaRgsYFdmWY1kwpLWI8968cn2O5D5uEJqOMDoGnEjoBtR3q36nNBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI3PR08MB503919 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF00050A00.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 327f6cf8-ce72-4639-77e9-08df09b537a4 X-Microsoft-Antispam: BCL:0;ARA:13230040|14060799003|23010399003|1800799024|35042699022|82310400026|36860700016|376014|22082099003|18002099003|11063799006|56012099006|3023799007|4143699003|10067099003; X-Microsoft-Antispam-Message-Info: WVXdvqWVlBFg0juuiuSLRnuY/w99HoL5X4CUhUDKHeX7t1iILVmhkClyKkKPs4AiDcW5GAuCf7IB6d5gMAOHErGhd0pZDdU9fSaVP1XuNtabajnc7zvR7d9uA9z8SFrPw+myFWFqVfz3Rz7uKRXhEqhCWoBRLPdHKpFLFvVcO+RJFwOUVwcY6GVivP34ssLPlV7FXQWQbZeElw5QpkVfaxW2LZQwPNMpPmrV/q5aVgUGKa7QysIUdVLBf6PB263rJG4VFJrTKhwhj6Mzmjeo9rnzfk++c3AzJNSUltN+oBGUzV7U03H6d0NXGxDmzlSTGu8+Ajpd2TyTs/6W29JkiMd3jGO5X/WF4/TN1V0+73jgAGM0NvbOUgeAKcrl06CI63PhrY29QOGQO7cCblusphFm0WZ83ICoqaYVS4qsN0s2FmMo46X5IIp2SzFZ8G7m+O+ReX/e4EvwPYr96A2JljXWF1aqjrmlc+D5fzLuTkZneoddrZDNXLSEO48LKE+W3UXx1giVUBYvtsBTkGK2lVTiHDttrMls7qRpphUSERJbnntGUr3ZAnPMizadiUggbAwdInmOYZlJ5gPWVlZl7c2rWCvbhlUICPTtd2fwfzg9prklrYV8aVOi671vvYtia8DI5PNvlXJLfgkhNUg/6uUODO3Pf23NBtzKkzfXDpg= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(23010399003)(1800799024)(35042699022)(82310400026)(36860700016)(376014)(22082099003)(18002099003)(11063799006)(56012099006)(3023799007)(4143699003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: nLRWohvkHqpsRiVEzxoI54ZyeARfzGkrbNYdtPhYtzBBWYhHgAmLmgij5m2GlOJp95MnLtUWDNDpSpEPZdth/5zeFwIG3YdSYnWEv2EpIaE9RIYLH5AtBSS6Dgx/Rjs2ZO3vv43vDb1rauFP7ShhWgxYyiuSwd3qLT342rkDnYVITWWMnVMSkPItWvs7ERYbURXk1dU5EbmueoLnHMqpN2PyRrcaUKyw+JnRE5ChgV2udpfrOfuvhs16eLuWQ0bGrjoReF7zou+0wG2Iwb5rbzwegC7Yi9nBv6zY7EPMq1fcs8BU2FHwGveXXxT2NabeP7VZ0kloUvtKNtOset+0L0rXyfXQG7vlAk3N7PGN16UxRexoSaxH5ky1amK7nbPs8qgi7tcUExX8sKyEaQCs22qJ+R0N6LHq20mgI0fzOjDrChLTuB3lg7jW9P3nCmYW X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 12:17:17.4417 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 57b68ae3-c412-4713-136f-08df09b54bcf X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DB1PEPF00050A00.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10238 X-purgate-ID: tlsNG-16d1c6/1788437846-1F8CB77B-6FAF18F5/0/0 X-purgate-type: clean X-purgate-size: 11088 Hi Andrew, > On 31 Aug 2026, at 14:19, Andrew Cooper wrote= : >=20 > PSCI v1.0 says that x4 thru x17 may be clobbered. PSCI v1.1 says they ar= e > strictly preserved unless they contain return values. I think the PSCI reference here and in the rest of the commit message and t= he patch should not be used and should be SMCCC references instead (which would also= be more coherent with the fact that this code is not PSCI but SMCCC and is use= d by=20 others than PSCI). PSCI does not define the preservation rules, this is defined in SMCCC spec = and we have a way to detect the SMCCC version. SMCCC defines the following rules: - 1.0: x4-x17 have an unpredictable return state. - 1.1: x4-x17 must be preserved. - 1.2: x4-x17 may additionally be defined as result registers, otherwise th= ey remain preserved. So the commit message and comments should consistently say SMCCC instead of= PSCI. Other than this the code is right i think. Cheers Bertrand >=20 > Xen deals with this by having __arm_smccc_1_0_smc() as an out-of-line > function, but this causes awful code generation in arm_smccc_smc(). > cpus_have_const_cap() is opaque to the optimiser, so we end up with one b= asic > block doing the reasonably-ok arm_smccc_1_1_smc() code generation and a s= econd > basic block setting up all 8 input registers even when they're not needed= , > spilling or discarding x8 thru x17, and calling an out-of-line function. >=20 > Remove __arm_smccc_1_0_smc() entirely, and rewrite arm_smccc_smc() to dec= lare > x4 thru x17 as clobbered. >=20 > This fully inlines the SMC, is a single basic block which instructs the > compiler to spill or discard the potentially clobbered registers, and onl= y > sets up the necessary number of arguments for the call. >=20 > No functional change. >=20 > Signed-off-by: Andrew Cooper > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers >=20 > Bloat-o-meter reports: >=20 > add/remove: 0/1 grow/shrink: 0/10 up/down: 0/-795 (-795) > Function old new delta > symbols_sorted_offsets 23832 23824 -8 > symbols_names 42962 42943 -19 > symbols_addresses 35128 35104 -24 > __arm_smccc_1_0_smc 32 - -32 > call_psci_cpu_off 144 76 -68 > seattle_system_reset 92 16 -76 > seattle_system_off 92 16 -76 > call_psci_system_reset 112 32 -80 > call_psci_system_off 112 32 -80 > call_psci_cpu_on 252 124 -128 > psci_init 628 424 -204 >=20 > An alternative way to do this would be to have x8 thru x17 in the clobber= list > rather than the output list which would reduce the source size, but this = form > is more amenable to having PSCI v1.2 worked into it too. > --- > xen/arch/arm/arm64/smc.S | 16 ------ > xen/arch/arm/include/asm/smccc.h | 95 ++++++++++++++++---------------- > 2 files changed, 48 insertions(+), 63 deletions(-) >=20 > diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S > index 68b05e8ddd12..65b4eabe4f87 100644 > --- a/xen/arch/arm/arm64/smc.S > +++ b/xen/arch/arm/arm64/smc.S > @@ -13,22 +13,6 @@ > * GNU General Public License for more details. > */ >=20 > -/* > - * void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, > - * register_t a3, register_t a4, register_t a5, > - * register_t a6, register_t a7, > - * struct arm_smccc_res *res) > - */ > -FUNC(__arm_smccc_1_0_smc) > - smc #0 > - ldr x4, [sp] > - cbz x4, 1f /* No need to store the result */ > - stp x0, x1, [x4, #SMCCC_RES_a0] > - stp x2, x3, [x4, #SMCCC_RES_a2] > -1: > - ret > -END(__arm_smccc_1_0_smc) > - > /* > * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, > * struct arm_smccc_1_2_regs *res) > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 5fe54013ac83..8920c54b09a6 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -16,9 +16,6 @@ > #ifndef __ASM_ARM_SMCCC_H__ > #define __ASM_ARM_SMCCC_H__ >=20 > -#include > -#include > - > #define SMCCC_VERSION_MAJOR_SHIFT 16 > #define SMCCC_VERSION_MINOR_MASK \ > ((1U << SMCCC_VERSION_MAJOR_SHIFT) - 1) > @@ -57,6 +54,9 @@ > #ifndef __ASSEMBLER__ >=20 > #include > +#include > + > +#include >=20 > extern uint32_t smccc_ver; >=20 > @@ -160,6 +160,8 @@ struct arm_smccc_res { > #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) > #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) >=20 > +#ifdef CONFIG_ARM_32 > + > /* > * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call > * > @@ -199,7 +201,6 @@ struct arm_smccc_res { > * The calling convention for arm32 is the same for both SMCCC v1.0 and > * v1.1. > */ > -#ifdef CONFIG_ARM_32 > #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) >=20 > /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ > @@ -218,53 +219,53 @@ static inline void arm_smccc_guest_smc(struct cpu_u= ser_regs *regs) >=20 > #else /* CONFIG_ARM_64 */ >=20 > -void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, > - register_t a3, register_t a4, register_t a5, > - register_t a6, register_t a7, > - struct arm_smccc_res *res); > - > -/* Macros to handle variadic parameter for SMCCC v1.0 helper */ > -#define __arm_smccc_1_0_smc_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ > - __arm_smccc_1_0_smc(a0, a1, a2, a3, a4, a5, a6, a7, res) > - > -#define __arm_smccc_1_0_smc_6(a0, a1, a2, a3, a4, a5, a6, res) \ > - __arm_smccc_1_0_smc_7(a0, a1, a2, a3, a4, a5, a6, 0, res) > - > -#define __arm_smccc_1_0_smc_5(a0, a1, a2, a3, a4, a5, res) \ > - __arm_smccc_1_0_smc_6(a0, a1, a2, a3, a4, a5, 0, res) > - > -#define __arm_smccc_1_0_smc_4(a0, a1, a2, a3, a4, res) \ > - __arm_smccc_1_0_smc_5(a0, a1, a2, a3, a4, 0, res) > - > -#define __arm_smccc_1_0_smc_3(a0, a1, a2, a3, res) \ > - __arm_smccc_1_0_smc_4(a0, a1, a2, a3, 0, res) > - > -#define __arm_smccc_1_0_smc_2(a0, a1, a2, res) \ > - __arm_smccc_1_0_smc_3(a0, a1, a2, 0, res) > - > -#define __arm_smccc_1_0_smc_1(a0, a1, res) \ > - __arm_smccc_1_0_smc_2(a0, a1, 0, res) > - > -#define __arm_smccc_1_0_smc_0(a0, res) \ > - __arm_smccc_1_0_smc_1(a0, 0, res) > - > -#define ___arm_smccc_1_0_smc_count(count, ...) \ > - __arm_smccc_1_0_smc_ ## count(__VA_ARGS__) > - > -#define __arm_smccc_1_0_smc_count(count, ...) \ > - ___arm_smccc_1_0_smc_count(count, __VA_ARGS__) > - > -#define arm_smccc_1_0_smc(...) = \ > - __arm_smccc_1_0_smc_count(__count_args(__VA_ARGS__), __VA_ARGS__= ) > - > +/* > + * Make an SMCCC call compatible with both PSCI v1.1 and v1.0. > + * > + * PSCI v1.1 says that x4 through x17 are strictly preserved unless they > + * contain return data. PSCI v1.0 says they clobbered. > + * > + * Xen doesn't make PSCI v1.1 calls which expect more than 4 return regi= sters, > + * so imply list x4 through x17 as clobbered. > + */ > #define arm_smccc_smc(...) \ > do { \ > - if ( cpus_have_const_cap(ARM_SMCCC_1_1) ) \ > - arm_smccc_1_1_smc(__VA_ARGS__); \ > - else \ > - arm_smccc_1_0_smc(__VA_ARGS__); \ > + register unsigned long r0 ASM_REG(0); \ > + register unsigned long r1 ASM_REG(1); \ > + register unsigned long r2 ASM_REG(2); \ > + register unsigned long r3 ASM_REG(3); \ > + /* Potentially clobbered in PSCI 1.0 */ \ > + register unsigned long c4 ASM_REG(4); \ > + register unsigned long c5 ASM_REG(5); \ > + register unsigned long c6 ASM_REG(6); \ > + register unsigned long c7 ASM_REG(7); \ > + register unsigned long c8 ASM_REG(8); \ > + register unsigned long c9 ASM_REG(9); \ > + register unsigned long c10 ASM_REG(10); \ > + register unsigned long c11 ASM_REG(11); \ > + register unsigned long c12 ASM_REG(12); \ > + register unsigned long c13 ASM_REG(13); \ > + register unsigned long c14 ASM_REG(14); \ > + register unsigned long c15 ASM_REG(15); \ > + register unsigned long c16 ASM_REG(16); \ > + register unsigned long c17 ASM_REG(17); \ > + __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > + asm volatile ( \ > + "smc #0" \ > + : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3), = \ > + "=3Dr" (c4), "=3Dr" (c5), "=3Dr" (c6), "=3Dr" (c7), = \ > + "=3Dr" (c8), "=3Dr" (c9), "=3Dr" (c10), "=3Dr" (c11), = \ > + "=3Dr" (c12), "=3Dr" (c13), "=3Dr" (c14), "=3Dr" (c15), = \ > + "=3Dr" (c16), "=3Dr" (c17) \ > + : PASTE(__constraint_read_, \ > + __count_args(__VA_ARGS__)) \ > + : "memory" ); \ > + if ( ___res ) \ > + *___res =3D (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > } while ( 0 ) >=20 > +#define arm_smccc_1_1_smc(...) arm_smccc_smc(__VA_ARGS__) > + > /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ > static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) > { > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 12:22:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 12:22:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407096.1640236 (Exim 4.92) (envelope-from ) id 1x26Ss-0000vp-Fc; Thu, 03 Sep 2026 12:22:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407096.1640236; Thu, 03 Sep 2026 12:22:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x26Ss-0000vi-Cb; Thu, 03 Sep 2026 12:22:46 +0000 Received: by outflank-mailman (input) for mailman id 1407096; Thu, 03 Sep 2026 12:22:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x26Sr-0000vc-3o for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 12:22:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x26Sq-00Eitr-DW for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:22:44 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a996684-bab6-0a2a0a5309dd-0a2a4504e83a-38 for ; Thu, 03 Sep 2026 14:22:41 +0200 Received: from [52.101.84.34] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a996690-b57f-0a2a45040019-346554224a37-3 for ; Thu, 03 Sep 2026 14:22:40 +0200 Received: from AS4P191CA0047.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:657::22) by VI0PR08MB11599.eurprd08.prod.outlook.com (2603:10a6:800:2eb::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 12:22:35 +0000 Received: from AM4PEPF00027A66.eurprd04.prod.outlook.com (2603:10a6:20b:657:cafe::9e) by AS4P191CA0047.outlook.office365.com (2603:10a6:20b:657::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Thu, 3 Sep 2026 12:22:35 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AM4PEPF00027A66.mail.protection.outlook.com (10.167.16.91) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Thu, 3 Sep 2026 12:22:34 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by GV1PR08MB10855.eurprd08.prod.outlook.com (2603:10a6:150:161::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Thu, 3 Sep 2026 12:21:56 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 12:21:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=LtAFHuF6joQ2lWeC0obXBTM+h+FqWu6Msrst3T8D4ELoYhku4czSJrLaO6tgV98zZiONjdXOdj5fOCGibUsxK1wqET6p6YRwoUYNz6vqh0QuC6Obn22qtizmxKu7rPfIkY9QKoBCheV8A3irWLB0T8OJFmoEWUhYx0qkXvS9GCdzEWD9ycf4stB8j/0FFQs3w6Dw4rZgouSJGwxAW55wdZN9mNZx9Dko9c4LAzPT0GMlKXmru3HPhUc2L26aLF4dvQEhfJo2nDeAQlK7seHrXKedKLL2/uWLjCGYRbDosnEvoiyiljMtVpWTWHUm2ei1y9GCK8ckSXuvNt803Z5kmg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uJDhisrPT7KRkn9ZUrUZvS4F5Oue3c+POnHTH3QxaO8=; b=UY7OvaPLUmrg6nmvduyYTb7EH/8LCI7Ga7ZiR5tQ4D1yoi1NETO8a97054+8/+UK5wuDqoDH6p/lubz1BCdA3wKVjhqbF3OsAKTJ2mojjebVfbRi2ljnxRjswQGUeervGguUfHyChAkaUXZfRaqdS7lKdfI94MN/mhZjA64IhriS6EfooByJcR3ZWsYXmXbCSntzMpmbcS7Nmdn6frIbBHpK3mFNZzb61li80zQUl1eoQrYhbewFVCAKDvFGgvxntDpIOEXhtfvT/mw9aKybP5+4efojgs/ldNEAqDrnxTzb5NCAxQFsEb7ezm8PtMxQ4Aui+wNX74kLQd+FkFmgvw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uJDhisrPT7KRkn9ZUrUZvS4F5Oue3c+POnHTH3QxaO8=; b=JAxv+fUBlUq/SpHwZrg8Ee/ZTLLe7aOi4dVy5SQZ2Zk+fuP/kKj82WLof7TcuZ5GXbsHrCqi6OIhmqY1B+5SuPIM+jQd9t62ttDRVOAmHixLWWv+mn30OQmhti3PoJRTlt2rcgjQswYSXmlftRahgljVZz67XqhnRbimCYQZwag= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b+sJb+Z599MfNjlJ8scUGxZNoI0ymEZhrOsB9u1jCVVgKM1jo0Bjg/J8Qc1EvO9Nex/sVMNqAuMkv5fe8vgj9b97LaC027iNvN/MYt78Gpw6FSvpBq2JoKDmdmjkspgSDehcWAZVT7FtZbziSAzJhuuBSm+RuDN5TITZz7WzLjjvQy9D99TQXH6ROFRZiRsgIaRDFqtzcReVpUomrgm0Etj0AYskkZqkll4AmO9M1pUgjS8hoj1iQYL16t+zZjrTCh2aVSjKDGvauBDg0ZjyfcNAK9JdcjvSFh0Z355YyCpxn48sHRJt0oimNgOMahVfclfC0jSQu11sLyeJ+BG+QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uJDhisrPT7KRkn9ZUrUZvS4F5Oue3c+POnHTH3QxaO8=; b=KEhJx/QkdmDxDF7jguEfEJHaUVmTL5ql4oe2GeIJRlm9+ItL/JPhWsFMKuUit5d8uXnoIJ0KjukP10qu9Wm7GkrIGzk+ufxYf+C4KcAz/pSgZFGO4TkVWJq1DThoM/myaO0AGoWRkGKPrZCXqc63fX9QJgTw076PGC+LmI/SemvlN2uY/Jo7SmqYkopR4Jq2vfeREsO4nCVucxYhc6b0I0uUnB+ULiqobKEzajv5WoywCXM7CG1mAFbJNFfA3zmU25zJEF5iO85bdlFZEelc0McceE8MUVLA1cRTT3HShCPNE2caJgNx7ILUPbe8dYW16g0t0iZtPnSR7hM11rnAMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uJDhisrPT7KRkn9ZUrUZvS4F5Oue3c+POnHTH3QxaO8=; b=JAxv+fUBlUq/SpHwZrg8Ee/ZTLLe7aOi4dVy5SQZ2Zk+fuP/kKj82WLof7TcuZ5GXbsHrCqi6OIhmqY1B+5SuPIM+jQd9t62ttDRVOAmHixLWWv+mn30OQmhti3PoJRTlt2rcgjQswYSXmlftRahgljVZz67XqhnRbimCYQZwag= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH 5/6] xen/arm: Rewrite arm_smccc_*() to return by value Thread-Topic: [PATCH 5/6] xen/arm: Rewrite arm_smccc_*() to return by value Thread-Index: AQHdOUMMdGYQSoUTg06DeJ9wBORtlLa8ywwA Date: Thu, 3 Sep 2026 12:21:56 +0000 Message-ID: <3357C375-C5A5-4D93-AE86-86F27B0655DF@arm.com> References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> <20260831121944.2908139-6-andrew.cooper3@citrix.com> In-Reply-To: <20260831121944.2908139-6-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|GV1PR08MB10855:EE_|AM4PEPF00027A66:EE_|VI0PR08MB11599:EE_ X-MS-Office365-Filtering-Correlation-Id: afc51428-823a-4a5b-a9ce-08df09b60911 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|6133799003|18002099003|22082099003|38070700021|10067099003|4143699003|3023799007|11063799006|56012099006; X-Microsoft-Antispam-Message-Info-Original: Mec+LJhWlcBt1MsWZSXwiE7jAAdl1bvcKxEDoh1iK2SKY90NZAk/AzhkDmVuxgylVIS4PT4d8vQiSbn7RTgeJ5HDV8FGtMDqhV+tmRb+b82ivFoEks5R+OmrEWEAYnI73if+5qGM7DT3t4Wip0dZtyL+Hqx8wc/O8tc7OhhMxADe2263Z5VurXJBYb3Mc+l++AeUzTazPLVjAElDeVsaW2PB5nhwSaQkI2fE9xvrgM0Dw+QNRknZkgIKb6PzzA8DyDpVyeJoIkxi291XJKl3rK+czYcH57Nugbk8YS7JqwRJAbwEzoOGG0BLPbMyFoQY00x+FQfozTthfkBFmZieG5ggA/vlkpeh+N69nP323fpKrAr5jHO9xZhZFwUIosdABQka98HhDDbUF2dfoMhfQqNTEbnYb+zbzXt3MERaAQltxOj/+hStokHkMShPVIi3lpDJ51+ZDLMiziUlTvLcDrWOkGQNx5GCnFpvrK8uaqfqzIKDd9lAMKwpSggh3j7SckVt3LjPYM/Zdq1Niphbrx7QHpB/li53HW985L7E+pixkB4YB2fowsa1YbzO1Z7Gcmv1WYhaH1Pdz06uAZuqNgZ7yMOlxL9SIC04KKjB9kplRQ/w6CDfk1y0ZwRxLVxS2tiyl15b4RGXoad1q1kayQb4pgMXSqY3vYbeKevtiY4xKnItlmjcQVFBwa+O7QGg/PGYPp6BquwgKYn54kdzQ5ulGlKJ+ooTTftSvLZ7ULE= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(6133799003)(18002099003)(22082099003)(38070700021)(10067099003)(4143699003)(3023799007)(11063799006)(56012099006);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <04CDB87BB48DA844BC34FEC52AC5CF70@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: pcwyDEPcbGlbbibEYhfXqF4RsolJ59NvAEF6yd1QTKyJWNBdHgvonu+rzktFd6XFntUyu0vpfnSvlOqFIa+PHXTkKjoZIsT5+XLyPRVI/1BnQdcb3ao2uvYiwyxl/Sk4e7eHPuWWHmBOOJRGZ3cNkn9eWHljyrD+L/fDuZr5l66UeFiwS3Gsu1qx4RRhtd1YpBhPBLQfrs9eoZrJQwgsINCvVDyrgG98KIdBBiueX2O0jBSVehaWCUGcKmqMikxxUeB7y1bmLsnrdeGV5agv90qhjAuuSIlKrQUuj6wvR6aGgrcbTjcnYy8Tx9LG0igtLN2FLU9XyO1OQ7Rv+M2QFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB10855 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM4PEPF00027A66.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 411d25d8-0b2d-4dbc-b1f7-08df09b5f219 X-Microsoft-Antispam: BCL:0;ARA:13230040|14060799003|23010399003|1800799024|35042699022|82310400026|36860700016|376014|6133799003|18002099003|22082099003|10067099003|4143699003|3023799007|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: C0y+XwqmoNAOmOFZ5AUgebZDkEh4UDAYbpfL+RgRVbTn7ObBab9NEfE9ekG1aHkMVrW8Lym+bD8hgLeGDUYNM28D33woHNze/Zeifd3vlSgnfoRx8iZnkRv0ZHcLqYVu3VyL8U7QeR+9QuIMqZ5omW94qeSCVW2q/tWLmIkzo3Lq7Olxmgf0Qrj1eRY8CfHuSVp8ZsIpqQu1Ib8zkPePgIaU3Yk0WOv6xXxSbQ6s+b0u2P8nb6MD05ZicbhLzasFXky0Ody/155eKU8JyQBybX5vFWOUsbErrwhg2cltecUQnTdNtLwUmZJlhfGCY/zfYk3e3WaEW4wQjG7knaRDXdfz39lEemAf2rEb2KxkQ0R6g29srqcdVTqI3fm7gVnYzYpRsuqA5HsCsz8JzNuvNWnRZ9vk5Ql4bG+fPaP1wST+gtKH2iw7YorYip8kpfEzKv1XszHcFsNhJhAySq9MWWVP+BJF90j+yGtQQBK0f7NyPx2otDYmJFFo0dxm+HJfGBbctU6gL1WRDqshwa3VamNceky3Pdmn8l1Nve1a9me3Cg/g8y0tZcCMhP1RqkBgqSR2iRhBvHKp0avSw49P3OgtxXqucGss6TisdX1jeX6nNMXU3R5OyWNYyqvL9tugQxiZtzd58QEEs9rJoXu3du0TVBlnBGntM0WvHpgWuiQ= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(23010399003)(1800799024)(35042699022)(82310400026)(36860700016)(376014)(6133799003)(18002099003)(22082099003)(10067099003)(4143699003)(3023799007)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: jgTleyGTQDYNDASXkToBPjT+7ngFXF4pWCcGTtQczmfsbyqsxUsYLpFZpdZv4ZPNrjSlB3O5kdOzWqiBzM+mfZ2xrQZk5i0Umdlfbxmt/sToPaD8uqNFDYsZ5OgiPSg8zdUA3L7M8GFFZ+HZPG2rgi4X+j5/EXAf92q2hbDvGgJ484rufx1BNjPMSJg4vbBXTLenGPxzFGjlmDM0EbnfhlzmAt2k4CzMTApjV4GhIEsh7zFtwLsiYrTScLF4fPg/gQXkqp/dzOjscdnGgv3uvYjsRINoA20iH7RRWnIlmPQgUerne6i2CyrUGbsUjZnQ+9JleHF4Oc2cQirM0nwjm4tKgNgaHPDN4g0CwhhBkhmeiiN0g7vhPD5lNwrOyNl1MTkZScbkQc7DbcJHwIfTM32npdmiELqJjWGdLaHA9fdUnitr2/MVcfVSVI0nypd7 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 12:22:34.9697 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: afc51428-823a-4a5b-a9ce-08df09b60911 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: AM4PEPF00027A66.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB11599 X-purgate-ID: tlsNG-ebf023/1788438160-C06DAB50-2073A522/0/0 X-purgate-type: clean X-purgate-size: 25190 Hi Andrew, > On 31 Aug 2026, at 14:19, Andrew Cooper wrote= : >=20 > Use statement expressions to return struct arm_smccc_res which makes the = code > read a lot more normally, and avoids needing to pass in NULL in order to = skip > return information. >=20 > More importantly, it removes the local implementation of __count_args() w= hich > is off by two and deeply confusing to try and follow. >=20 > No functional change. >=20 > Signed-off-by: Andrew Cooper > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers >=20 > Xen compiles identically before and after this change, for both arm32 and= arm64. > --- > xen/arch/arm/cpuerrata.c | 18 +++---- > xen/arch/arm/include/asm/smccc.h | 87 ++++++++++++++------------------ > xen/arch/arm/platforms/exynos5.c | 2 +- > xen/arch/arm/platforms/seattle.c | 4 +- > xen/arch/arm/psci.c | 17 +++---- > xen/arch/arm/tee/optee.c | 47 +++++++++-------- > xen/arch/arm/traps.c | 4 +- > 7 files changed, 84 insertions(+), 95 deletions(-) >=20 > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c > index 3a32183618dc..35ad98d29d14 100644 > --- a/xen/arch/arm/cpuerrata.c > +++ b/xen/arch/arm/cpuerrata.c > @@ -179,8 +179,8 @@ static int enable_smccc_arch_workaround_1(void *data) > if ( smccc_ver < SMCCC_VERSION(1, 1) ) > goto warn; >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > - ARM_SMCCC_ARCH_WORKAROUND_1_FID, &res); > + res =3D arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > + ARM_SMCCC_ARCH_WORKAROUND_1_FID); > /* The return value is in the lower 32-bits. */ > if ( (int)res.a0 < 0 ) > goto warn; > @@ -256,8 +256,8 @@ static int enable_spectre_bhb_workaround(void *data) > if ( smccc_ver < SMCCC_VERSION(1, 1) ) > goto warn; >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > - ARM_SMCCC_ARCH_WORKAROUND_3_FID, &res); > + res =3D arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > + ARM_SMCCC_ARCH_WORKAROUND_3_FID); > /* The return value is in the lower 32-bits. */ > if ( (int)res.a0 < 0 ) > { > @@ -398,8 +398,8 @@ static bool has_ssbd_mitigation(const struct arm_cpu_= capabilities *entry) > if ( smccc_ver < SMCCC_VERSION(1, 1) ) > return false; >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > - ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res); > + res =3D arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > + ARM_SMCCC_ARCH_WORKAROUND_2_FID); >=20 > switch ( (int)res.a0 ) > { > @@ -429,7 +429,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_= capabilities *entry) > case ARM_SSBD_FORCE_DISABLE: > printk_once("%s disabled from command-line\n", entry->desc); >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0); > required =3D false; > break; >=20 > @@ -437,7 +437,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_= capabilities *entry) > if ( required ) > { > this_cpu(ssbd_callback_required) =3D 1; > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); > } >=20 > break; > @@ -445,7 +445,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_= capabilities *entry) > case ARM_SSBD_FORCE_ENABLE: > printk_once("%s forced from command-line\n", entry->desc); >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); > required =3D true; > break; >=20 > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 8920c54b09a6..ebed2ff7c7d2 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -95,20 +95,14 @@ struct arm_smccc_res { > unsigned long a3; > }; >=20 > -/* SMCCC v1.1 implementation madness follows */ > -#define ___count_args(_0, _1, _2, _3, _4, _5, _6, _7, _8, x, ...) x > - > -#define __count_args(...) \ > - ___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0) > - > -#define __constraint_read_0 "r" (arg0) > -#define __constraint_read_1 __constraint_read_0, "r" (arg1) > -#define __constraint_read_2 __constraint_read_1, "r" (arg2) > -#define __constraint_read_3 __constraint_read_2, "r" (arg3) > -#define __constraint_read_4 __constraint_read_3, "r" (arg4) > -#define __constraint_read_5 __constraint_read_4, "r" (arg5) > -#define __constraint_read_6 __constraint_read_5, "r" (arg6) > -#define __constraint_read_7 __constraint_read_6, "r" (arg7) > +#define __constraint_read_1 "r" (arg0) > +#define __constraint_read_2 __constraint_read_1, "r" (arg1) > +#define __constraint_read_3 __constraint_read_2, "r" (arg2) > +#define __constraint_read_4 __constraint_read_3, "r" (arg3) > +#define __constraint_read_5 __constraint_read_4, "r" (arg4) > +#define __constraint_read_6 __constraint_read_5, "r" (arg5) > +#define __constraint_read_7 __constraint_read_6, "r" (arg6) > +#define __constraint_read_8 __constraint_read_7, "r" (arg7) >=20 > /* > * Macro arguments MUST be evaluated before being assigned to a register > @@ -117,44 +111,43 @@ struct arm_smccc_res { > * This is manual register scheduling for the asm() statement, and any ot= her > * logic to evaluate may clobber the already-scheduled registers. > */ > -#define __declare_arg_0(a0, res) \ > +#define __declare_arg_1(a0) \ > auto __a0 =3D (uint32_t)(a0); \ > - struct arm_smccc_res *___res =3D (res); \ > register unsigned long arg0 ASM_REG(0) =3D __a0 >=20 > -#define __declare_arg_1(a0, a1, res) \ > +#define __declare_arg_2(a0, a1) \ > auto __a1 =3D (a1); \ > - __declare_arg_0(a0, res); \ > + __declare_arg_1(a0); \ > register auto arg1 ASM_REG(1) =3D __a1 >=20 > -#define __declare_arg_2(a0, a1, a2, res) \ > +#define __declare_arg_3(a0, a1, a2) \ > auto __a2 =3D (a2); \ > - __declare_arg_1(a0, a1, res); \ > + __declare_arg_2(a0, a1); \ > register auto arg2 ASM_REG(2) =3D __a2 >=20 > -#define __declare_arg_3(a0, a1, a2, a3, res) \ > +#define __declare_arg_4(a0, a1, a2, a3) \ > auto __a3 =3D (a3); \ > - __declare_arg_2(a0, a1, a2, res); \ > + __declare_arg_3(a0, a1, a2); \ > register auto arg3 ASM_REG(3) =3D __a3 >=20 > -#define __declare_arg_4(a0, a1, a2, a3, a4, res) \ > +#define __declare_arg_5(a0, a1, a2, a3, a4) \ > auto __a4 =3D (a4); \ > - __declare_arg_3(a0, a1, a2, a3, res); \ > + __declare_arg_4(a0, a1, a2, a3); \ > register auto arg4 ASM_REG(4) =3D __a4 >=20 > -#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ > +#define __declare_arg_6(a0, a1, a2, a3, a4, a5) \ > auto __a5 =3D (a5); \ > - __declare_arg_4(a0, a1, a2, a3, a4, res); \ > + __declare_arg_5(a0, a1, a2, a3, a4); \ > register auto arg5 ASM_REG(5) =3D __a5 >=20 > -#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ > - auto __a6 =3D (a6); \ > - __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ > +#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6) \ > + auto __a6 =3D (a6); \ > + __declare_arg_6(a0, a1, a2, a3, a4, a5); \ > register auto arg6 ASM_REG(6) =3D __a6 >=20 > -#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ > - auto __a7 =3D (a7); \ > - __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ > +#define __declare_arg_8(a0, a1, a2, a3, a4, a5, a6, a7) \ > + auto __a7 =3D (a7); \ > + __declare_arg_7(a0, a1, a2, a3, a4, a5, a6); \ > register auto arg7 ASM_REG(7) =3D __a7 >=20 > #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) > @@ -181,21 +174,20 @@ struct arm_smccc_res { > * makes it stick. > */ > #define arm_smccc_1_1_smc(...) \ > - do { \ > + ({ \ > register unsigned long r0 ASM_REG(0); \ > register unsigned long r1 ASM_REG(1); \ > register unsigned long r2 ASM_REG(2); \ > register unsigned long r3 ASM_REG(3); \ > - __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > + __declare_args(count_args(__VA_ARGS__), __VA_ARGS__); \ > asm volatile ( \ > "smc #0" \ > : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3) \ > : PASTE(__constraint_read_, \ > - __count_args(__VA_ARGS__)) \ > + count_args(__VA_ARGS__)) \ > : "memory" ); \ > - if ( ___res ) \ > - *___res =3D (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > - } while ( 0 ) > + (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > + }) >=20 > /* > * The calling convention for arm32 is the same for both SMCCC v1.0 and > @@ -208,8 +200,8 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > { > struct arm_smccc_res res; >=20 > - arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3, > - regs->r4, regs->r5, regs->r6, regs->r7, &res); > + res =3D arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3, > + regs->r4, regs->r5, regs->r6, regs->r7); >=20 > regs->r0 =3D res.a0; > regs->r1 =3D res.a1; > @@ -229,7 +221,7 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > * so imply list x4 through x17 as clobbered. > */ > #define arm_smccc_smc(...) \ > - do { \ > + ({ \ > register unsigned long r0 ASM_REG(0); \ > register unsigned long r1 ASM_REG(1); \ > register unsigned long r2 ASM_REG(2); \ > @@ -249,7 +241,7 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > register unsigned long c15 ASM_REG(15); \ > register unsigned long c16 ASM_REG(16); \ > register unsigned long c17 ASM_REG(17); \ > - __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > + __declare_args(count_args(__VA_ARGS__), __VA_ARGS__); \ > asm volatile ( \ > "smc #0" \ > : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3), \ > @@ -258,11 +250,10 @@ static inline void arm_smccc_guest_smc(struct cpu_u= ser_regs *regs) > "=3Dr" (c12), "=3Dr" (c13), "=3Dr" (c14), "=3Dr" (c15), \ > "=3Dr" (c16), "=3Dr" (c17) \ > : PASTE(__constraint_read_, \ > - __count_args(__VA_ARGS__)) \ > + count_args(__VA_ARGS__)) \ > : "memory" ); \ > - if ( ___res ) \ > - *___res =3D (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > - } while ( 0 ) > + (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > + }) >=20 > #define arm_smccc_1_1_smc(...) arm_smccc_smc(__VA_ARGS__) >=20 > @@ -271,8 +262,8 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > { > struct arm_smccc_res res; >=20 > - arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3, > - regs->x4, regs->x5, regs->x6, regs->x7, &res); > + res =3D arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3, > + regs->x4, regs->x5, regs->x6, regs->x7); >=20 > regs->x0 =3D res.a0; > regs->x1 =3D res.a1; > diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/ex= ynos5.c > index f7c09520675e..f08d50c1fe38 100644 > --- a/xen/arch/arm/platforms/exynos5.c > +++ b/xen/arch/arm/platforms/exynos5.c > @@ -249,7 +249,7 @@ static int exynos5_cpu_up(int cpu) > iounmap(power); >=20 > if ( secure_firmware ) > - arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu, NULL); > + arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu); >=20 > return cpu_up_send_sgi(cpu); > } > diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/se= attle.c > index 64cc1868c24b..dfa5cf4265c0 100644 > --- a/xen/arch/arm/platforms/seattle.c > +++ b/xen/arch/arm/platforms/seattle.c > @@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initc= onst =3D > */ > static void seattle_system_reset(void) > { > - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL); > + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET); > } >=20 > static void seattle_system_off(void) > { > - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL); > + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF); > } >=20 > PLATFORM_START(seattle, "SEATTLE") > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c > index b6860a776031..634d0d7467cf 100644 > --- a/xen/arch/arm/psci.c > +++ b/xen/arch/arm/psci.c > @@ -41,8 +41,8 @@ int call_psci_cpu_on(int cpu) > { > struct arm_smccc_res res; >=20 > - arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), __pa(init_second= ary), > - &res); > + res =3D arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), > + __pa(init_secondary)); >=20 > return PSCI_RET(res); > } > @@ -54,7 +54,7 @@ void call_psci_cpu_off(void) > struct arm_smccc_res res; >=20 > /* If successfull the PSCI cpu_off call doesn't return */ > - arm_smccc_smc(PSCI_0_2_FN32_CPU_OFF, &res); > + res =3D arm_smccc_smc(PSCI_0_2_FN32_CPU_OFF); > panic("PSCI cpu off failed for CPU%d err=3D%d\n", smp_processor_i= d(), > PSCI_RET(res)); > } > @@ -63,13 +63,13 @@ void call_psci_cpu_off(void) > void call_psci_system_off(void) > { > if ( psci_ver > PSCI_VERSION(0, 1) ) > - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL); > + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF); > } >=20 > void call_psci_system_reset(void) > { > if ( psci_ver > PSCI_VERSION(0, 1) ) > - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL); > + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET); > } >=20 > static int __init psci_features(uint32_t psci_func_id) > @@ -79,7 +79,7 @@ static int __init psci_features(uint32_t psci_func_id) > if ( psci_ver < PSCI_VERSION(1, 0) ) > return PSCI_NOT_SUPPORTED; >=20 > - arm_smccc_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, &res); > + res =3D arm_smccc_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id); >=20 > return PSCI_RET(res); > } > @@ -116,9 +116,8 @@ static void __init psci_init_smccc(void) >=20 > if ( psci_features(ARM_SMCCC_VERSION_FID) !=3D PSCI_NOT_SUPPORTED ) > { > - struct arm_smccc_res res; > + struct arm_smccc_res res =3D arm_smccc_smc(ARM_SMCCC_VERSION_FID= ); >=20 > - arm_smccc_smc(ARM_SMCCC_VERSION_FID, &res); > if ( PSCI_RET(res) !=3D ARM_SMCCC_NOT_SUPPORTED ) > smccc_ver =3D PSCI_RET(res); > } > @@ -191,7 +190,7 @@ static int __init psci_init_0_2(void) > } > } >=20 > - arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION, &res); > + res =3D arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION); > psci_ver =3D PSCI_RET(res); >=20 > /* For the moment, we only support PSCI 0.2 and PSCI 1.x */ > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > index 3d2633237074..e38223d49801 100644 > --- a/xen/arch/arm/tee/optee.c > +++ b/xen/arch/arm/tee/optee.c > @@ -178,7 +178,7 @@ static bool optee_probe(void) > return false; >=20 > /* Check UID */ > - arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), &resp); > + resp =3D arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END)); >=20 > if ( (uint32_t)resp.a0 !=3D OPTEE_MSG_UID_0 || > (uint32_t)resp.a1 !=3D OPTEE_MSG_UID_1 || You missed one conversion just after this (line 190): arm_smccc_smc(OPTEE_SMC_GET_THREAD_COUNT, &resp); It also needs to be converted. > @@ -209,7 +209,7 @@ static bool optee_probe(void) > * call. It will return OPTEE_SMC_RETURN_UNKNOWN_FUNCTION if > * OP-TEE have no virtualization support enabled. > */ > - arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, 0, 0, 0, 0, 0, 0, 0, &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, 0, 0, 0, 0, 0, 0, 0); > if ( resp.a0 =3D=3D OPTEE_SMC_RETURN_UNKNOWN_FUNCTION ) > return false; >=20 > @@ -243,8 +243,8 @@ static int optee_domain_init(struct domain *d) > * > * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_sm= c() > */ > - arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, = 0, 0, > - &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), > + 0, 0, 0, 0, 0, 0); > if ( resp.a0 !=3D OPTEE_SMC_RETURN_OK ) > { > printk(XENLOG_WARNING "%pd: Unable to create OPTEE client: rc =3D= 0x%X\n", > @@ -681,8 +681,8 @@ static int optee_relinquish_resources(struct domain *= d) > * > * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_sm= c() > */ > - arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0= , 0, 0, > - &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), > + 0, 0, 0, 0, 0, 0); >=20 > ASSERT(!spin_is_locked(&ctx->lock)); > ASSERT(!atomic_read(&ctx->call_count)); > @@ -1171,15 +1171,14 @@ static void do_call_with_arg(struct optee_domain = *ctx, > { > struct arm_smccc_res res; >=20 > - arm_smccc_smc(a0, a1, a2, a3, a4, a5, 0, OPTEE_CLIENT_ID(current->do= main), > - &res); > + res =3D arm_smccc_smc(a0, a1, a2, a3, a4, a5, 0, OPTEE_CLIENT_ID(cur= rent->domain)); This needs wrapping as it is over 80 chars. >=20 > if ( OPTEE_SMC_RETURN_IS_RPC(res.a0) ) > { > while ( handle_rpc_return(ctx, &res, regs, call) =3D=3D -ERESTAR= T ) > { > - arm_smccc_smc(res.a0, res.a1, res.a2, res.a3, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &res); > + res =3D arm_smccc_smc(res.a0, res.a1, res.a2, res.a3, 0, 0, = 0, > + OPTEE_CLIENT_ID(current->domain)); >=20 > if ( !OPTEE_SMC_RETURN_IS_RPC(res.a0) ) > break; > @@ -1619,8 +1618,8 @@ static void handle_exchange_capabilities(struct cpu= _user_regs *regs) > caps =3D get_user_reg(regs, 1); > caps &=3D OPTEE_KNOWN_NSEC_CAPS; >=20 > - arm_smccc_smc(OPTEE_SMC_EXCHANGE_CAPABILITIES, caps, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_EXCHANGE_CAPABILITIES, caps, 0, 0, = 0, 0, 0, > + OPTEE_CLIENT_ID(current->domain)); > if ( resp.a0 !=3D OPTEE_SMC_RETURN_OK ) { > set_user_reg(regs, 0, resp.a0); > return; > @@ -1664,8 +1663,8 @@ static bool optee_handle_call(struct cpu_user_regs = *regs) > return true; >=20 > case OPTEE_SMC_CALLS_UID: > - arm_smccc_smc(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > set_user_reg(regs, 1, resp.a1); > set_user_reg(regs, 2, resp.a2); > @@ -1673,15 +1672,15 @@ static bool optee_handle_call(struct cpu_user_reg= s *regs) > return true; >=20 > case OPTEE_SMC_CALLS_REVISION: > - arm_smccc_smc(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, = 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > set_user_reg(regs, 1, resp.a1); > return true; >=20 > case OPTEE_SMC_CALL_GET_OS_UUID: > - arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_UUID, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain),&resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_UUID, 0, 0, 0, 0, 0= , 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > set_user_reg(regs, 1, resp.a1); > set_user_reg(regs, 2, resp.a2); > @@ -1689,21 +1688,21 @@ static bool optee_handle_call(struct cpu_user_reg= s *regs) > return true; >=20 > case OPTEE_SMC_CALL_GET_OS_REVISION: > - arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_REVISION, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_REVISION, 0, 0, 0, = 0, 0, 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > set_user_reg(regs, 1, resp.a1); > return true; >=20 > case OPTEE_SMC_ENABLE_SHM_CACHE: > - arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0= , 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > return true; >=20 > case OPTEE_SMC_DISABLE_SHM_CACHE: > - arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, = 0, 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > if ( resp.a0 =3D=3D OPTEE_SMC_RETURN_OK ) { > free_shm_rpc(ctx, regpair_to_uint64(resp.a1, resp.a2)); > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c > index 625d229396bb..6a5dcef2aa87 100644 > --- a/xen/arch/arm/traps.c > +++ b/xen/arch/arm/traps.c > @@ -1991,7 +1991,7 @@ void asmlinkage enter_hypervisor_from_guest_preirq(= void) >=20 > /* If the guest has disabled the workaround, bring it back on. */ > if ( needs_ssbd_flip(v) ) > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); > } >=20 > /* > @@ -2334,7 +2334,7 @@ void asmlinkage leave_hypervisor_to_guest(void) > * If the guest wants it disabled, so be it... > */ > if ( needs_ssbd_flip(current) ) > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0); > } >=20 > /* > --=20 > 2.39.5 >=20 Cheers Bertrand From xen-devel-bounces@lists.xenproject.org Thu Sep 03 13:02:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 13:02:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407125.1640246 (Exim 4.92) (envelope-from ) id 1x275S-00071A-DS; Thu, 03 Sep 2026 13:02:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407125.1640246; Thu, 03 Sep 2026 13:02:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x275S-000713-AI; Thu, 03 Sep 2026 13:02:38 +0000 Received: by outflank-mailman (input) for mailman id 1407125; Thu, 03 Sep 2026 13:02:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x275R-00070w-8f for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:02:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x275Q-007WDM-0p for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:02:36 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a996fe2-2eae-0a2a0a5409dd-0a2a4502c792-22 for ; Thu, 03 Sep 2026 15:02:35 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a996feb-6ca4-0a2a45020019-d1558036b4b1-3 for ; Thu, 03 Sep 2026 15:02:35 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49b9320423cso23547695e9.0 for ; Thu, 03 Sep 2026 06:02:35 -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-49cee5d476esm78160895e9.1.2026.09.03.06.02.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 06:02:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788440555; x=1789045355; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Fr9c2bcVH3YZkNHK8y6Ezrb7ww0KyfIezCyd8AC+rh4=; b=ZA3RJSGGb/OF0tpM4QwLCK9Mc4QAmHKdlS8Ed5vbOVQZFU5LvNdUuozjzC3oRA4sm9 5w/ums5JZB5EvtgEtChFCsIEdbC4ogfw6t+tDU54nvFOS5Vs4ttHQzCDqtFAlTEdKOIp ywFSWbuDICJJotg1EG/RuXuFRyXeyqYJpZvNv9+HHEepNyGST/VKxSFYqfaWRxmrkPD4 O8eHQyR5hv7hSc1aNjo9Npd7YFCfAU72zm4YmVXj6ZYs7qEnfA8+cUb30qbtFKSar2tj HGu29SAyS3RiWhFQDuwuI3/gk1/06VP/Vby8KYYkniSVMo5eSRRhOmsqLOADsInMRwGu zyyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788440555; x=1789045355; h=content-transfer-encoding:content-type: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:content-type; bh=Fr9c2bcVH3YZkNHK8y6Ezrb7ww0KyfIezCyd8AC+rh4=; b=Mt98pqNTsAGjMVRPWH6FOot/Kg16+PyKNuiwEzr8LACtvVTjf1JfTm3kvxk6WBlSlh DwnqW3jlU2xVfUxrFaMMa/0SqQqxs31d9LWaI+6+RSXFF9PSHeUNdOtFYA+k8dEOTffa 2CBSStj9uzE0lrh2Rd+YUjGtBq2Rj8mcXPMBqItQfJ+FJ0U8RGiP41e6V07WAQqyjObG B8rjauLuNTQjp/i3DmC1MvniUwc5jJ0PB1ENR5rLrIpQAsTpDEpeky2DaQhQZtQVk7zL BCysqKxxoa2CfAvOeA81ojHSxyC5ootTdxyFV65SamzotsfnaHfSAzSWBromN41JzGBB otCw== X-Forwarded-Encrypted: i=1; AKwUvBwTUXPqgM3vtp57RinIqvo0d0zNJ+ktH0HONJn9r7PjcZmCISwHjgOLzoEMKffrnIxyFtUSKO1pbuQ=@lists.xenproject.org X-Gm-Message-State: AFuF++nK8UwRoWH7yf4TZf/HsMzbgBMdqm7ppFHlBXPjbGdkyvPW73lc 8m1RoMVJ1D5B40m3lc9qhOyEvl1V5SOskeY+ZB3ESJilpx8GdYdikATOloqZpSIXLw== X-Gm-Gg: AYBFou3zb8gqCspGfZ2P86g4N1OBqmAJTs/CkbkESiRYaEyB41tpCcN1IphX/2She5s hZT25VwOhlCKXu4G0CoAYlTjGTEHwMZx5kBrd1TjbN0V3Eicv0bVIMctp21+/7NgsORP4T3eI67 bpwhjaNVmL0ChHmdEqnExvZW/FF2aS4IXQNyTo3qRdH5BufLz1xYimRX+29ntjDk44BanmP/2Y/ A8vGlqeztVqpXEW4tNhwoBLJuSz7o3onBm/dpbijlnE6/fcfJA17My53Vp6LEr/7e8BiS9C60Mt eXJRQxn+xGzwX9I81u0X08cUngf1g8ixEV7+2ooygyrBB+VUdVEYiBF44Gg8ZdTJbpFOa7NrNDb UI7ITPa+o42sVOnPc0+60d72tyUPa/7c446MxelKKAvnsk+h4erqSHe4fpfakn7rwWBRXX18e1P vdlwVtY0RKASQYn41yham1IRnnhuPgFEzId0d8kOh8wxSxqdzhzJbRXhLKqc2wPrCHdz7cqURAv 5PpprrRkYm458vogvyO75Y7N+N4A8Vg6HI7TDBhzSib7JyYaMcI X-Received: by 2002:a05:600c:4693:b0:499:dbba:9859 with SMTP id 5b1f17b1804b1-49ce5817c57mr198966205e9.5.1788440553759; Thu, 03 Sep 2026 06:02:33 -0700 (PDT) Message-ID: <514b9ad4-912c-45fa-9450-3c85adaef483@suse.com> Date: Thu, 3 Sep 2026 15:02:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/svm: Intercept CR0 writes selectively To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828141955.4009939-1-ross.lagerwall@citrix.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: <20260828141955.4009939-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788440555-31BC82AC-ADF1AC3E/0/0 X-purgate-type: clean X-purgate-size: 2828 On 28.08.2026 16:19, Ross Lagerwall wrote: > Xen does not need to track when the TS or MP bits change so opt to > intercept CR0 writes selectively. Not anymore, which may want expressing here (or else it looks as if this would have been possible from the start). > Aside from potentially reducing a few > VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE > and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so > L1 never sees any CR0 writes. Yet if L1 sets CR0_WRITE, since intercept masks are ORed together (if I'm not mistaken), ... > @@ -2882,7 +2884,8 @@ void asmlinkage svm_vmexit_handler(void) > break; > > case VMEXIT_CR0_READ ... VMEXIT_CR15_READ: > - case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE: > + case VMEXIT_CR1_WRITE ... VMEXIT_CR15_WRITE: > + case VMEXIT_CR0_SEL_WRITE: > if ( cpu_has_svm_decode && vmcb->ei.mov_cr.mov_insn ) > svm_vmexit_do_cr_access(vmcb, regs); > else if ( !hvm_emulate_one_insn(x86_insn_is_cr_access, "CR access") ) ... we may still see VMEXIT_CR0_WRITE here (i.e. its handling cannot be removed). > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -56,7 +56,7 @@ static int construct_vmcb(struct vcpu *v) > GENERAL1_INTERCEPT_HLT | GENERAL1_INTERCEPT_INVLPG | > GENERAL1_INTERCEPT_INVLPGA | GENERAL1_INTERCEPT_IOIO_PROT | > GENERAL1_INTERCEPT_MSR_PROT | GENERAL1_INTERCEPT_SHUTDOWN_EVT| > - GENERAL1_INTERCEPT_TASK_SWITCH; > + GENERAL1_INTERCEPT_TASK_SWITCH | GENERAL1_INTERCEPT_CR0_SEL_WRITE; I understand GENERAL1_INTERCEPT_SHUTDOWN_EVT is an existing outlier here, but can we please not add more? This expression is sorted by bit position, with said exception. (Yes, that'll be more churn, but I think that's acceptable here.) > @@ -76,11 +76,13 @@ static int construct_vmcb(struct vcpu *v) > /* Intercept all debug-register writes. */ > vmcb->_dr_intercepts = ~0u; > > - /* Intercept all control-register accesses except for CR2 and CR8. */ > + /* Intercept all control-register accesses except for CR2, CR8 and > + * CR0 (covered by selective write). */ > vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR2_READ | > CR_INTERCEPT_CR2_WRITE | > CR_INTERCEPT_CR8_READ | > - CR_INTERCEPT_CR8_WRITE); > + CR_INTERCEPT_CR8_WRITE | > + CR_INTERCEPT_CR0_WRITE); In both comment and code I think it would be nice if numeric sorting was retained. In the comment you also want to mirror what the code does (it only excludes writes, not reads). Finally - nit: Comment style. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 13:11:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 13:11:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407139.1640256 (Exim 4.92) (envelope-from ) id 1x27EF-0000f1-6r; Thu, 03 Sep 2026 13:11:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407139.1640256; Thu, 03 Sep 2026 13:11:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27EF-0000eu-2U; Thu, 03 Sep 2026 13:11:43 +0000 Received: by outflank-mailman (input) for mailman id 1407139; Thu, 03 Sep 2026 13:11:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27ED-0000ei-9d for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:11:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x27EC-00F810-JQ for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:11:40 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a997206-bab6-0a2a0a5309dd-0a2a45019eee-22 for ; Thu, 03 Sep 2026 15:11:40 +0200 Received: from [209.85.208.46] (helo=mail-ed1-f46.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99720c-5984-0a2a45010019-d155d02ea800-3 for ; Thu, 03 Sep 2026 15:11:40 +0200 Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-6a5e971c970so1781382a12.0 for ; Thu, 03 Sep 2026 06:11:40 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c25f41e07d0sm97710366b.36.2026.09.03.06.11.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 06:11:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788441100; x=1789045900; darn=lists.xenproject.org; h=content-type: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:content-type; bh=N6LpzJY8rVfGucvA7nIzbo2qU5XfqKxWkmV7WNb0D0k=; b=EMWZdyX/9s6oy0aN3JnNe7Kvd0kq8W2qskmcgVdUdh+WIjJWd8AGLb5c5c21fqbIq+ FmvOVNKDph9zve+a13Ydhc1W9vOPTsx4e/AbU1Nb+nozQzXCIzoBMjE5NBzEiTp5sYlq rFD53Yh3p+vgfGO0bz6E4sO3lvogT14hv4qyGzGogwTNTT0zcVdyDN1ciT6tQ4oLZISF 0KCmyUBerZNX2ZhXXiNG0STOfwEr+GOv26S+Q5bui9qv1gFuj9L0JEoQl24zeqI3RGDE eWyXf3tFfM5TE0MnaVXBYXbQn6P7BiA3vtysvm9kwbFfnga850WDQebie6Q3cxEqicG1 8g3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788441100; x=1789045900; h=content-type: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 :content-type; bh=N6LpzJY8rVfGucvA7nIzbo2qU5XfqKxWkmV7WNb0D0k=; b=Li9aHsjZeIUVVk0ugDmK6TwMI5WAWdguMxLBr3aGXn8C5oRv42fNMjeERoEPCuQ7jh 681DWEbLV6EWKLzSYA2z3hh2+RQf3sfz/xE46KXB/e/FDm/cPnKwmLnyKb4hTy74Hf+B TFAJK+f5plCWeqNQIwvxUGt7QptL1c3WfnJAJwhWJhDV9W2f+SEA2TImJjpB3VUtn0y8 Y9P0UFW8WAjqmUk9gaNzb3Aa3xl5hsPB3GcEJZKZItFZltk1U+yEKKIDF29E0vYm8OVN oFh3YDCXAqmk1j1yVag0iZfMSe9Vv6M9mQgYpoWwvBGSJ4ggYKIsm1wWSxhBv41UVP7V juGw== X-Forwarded-Encrypted: i=1; AKwUvBxW2xwza19ubpXFfhj1f88n1OrUjnwylVJVQ8daXo7eFaOrUn0WO2SonZ/XvaNFO66LcK0y9anWvwo=@lists.xenproject.org X-Gm-Message-State: AFuF++lPTgKgmpO/I3psGcBRIn23hGxPhZ+tVO90MkScuOAcLJhN2XZk FPc/EFCRjVKX4qjvWr9Iui14cV/sYb2nsfkwfmZmaeu0V0+EyE8OAAHG5qxQj/p7qfI= X-Gm-Gg: AYBFou1IFb//eASkL3hk8ggcqHhuBxdVuJzQtGrUyfxqsZTzoEPDmUgpLxRy69yMRws EigDJRhMDjWXA1xb9No3QivvWvJrM/vVi6p9+mnA7gkfT7dwb6SzgC4b6FkENfrucCPZfUtwkOS bLNxTjOFhmRSNafMHxm3qlnMbwBdUjuVAVYbmeXmh+fY0E4wszgX1VXSuI66Gg8rwlamMC5ZJ4m mXod2O7bHvpiINVvmyGKRlyiEK4FIiDEVbXKjIe5puKgSWCJoDw9VBXkIYF7gYMNiTON1dEQKMb IlHYM/h15dRLyfEnqakKR3AUx7nQQcPxKzMx10O4bQE3vWaXxxmcP54d7PCy7zD7zpSUu6vQtpF XqMqXm2qbjeexw+VkQ1sAbIMNCk7YVKHgdrB8HEUeiHMSoZJs17wBb4/NDHSdEH9ltLXDW/iMwZ nSbAmKwcuqK6NxuHmzC5diWg1taq/C+x8LTq9jfYWRuV7p+Msy3b/2pWJnWh173Iy/P4XoNiKVK Leka2YOmKu7ZiEJGzYyutC/ji0NzTi/rsGswAc/tTn9nMdNuCEyjGlvnN7LbzNu6WbVc+MzGh0= X-Received: by 2002:a17:907:a28d:b0:c25:cb79:e4b5 with SMTP id a640c23a62f3a-c25f7ff486bmr138281266b.3.1788441099796; Thu, 03 Sep 2026 06:11:39 -0700 (PDT) Message-ID: <37902bbd-1ab9-4b49-8f94-4b788b3620d9@suse.com> Date: Thu, 3 Sep 2026 15:11:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] stubdom: Fix GCC 14 -Wmemset-elt-size compiler warnings in PolarSSL To: Andrew Precious , Jan Beulich Cc: samuel.thibault@ens-lyon.org, xen-devel@lists.xenproject.org References: <20260825184605.79318-1-andrewprecious388@gmail.com> <22091019-92ea-4de5-b470-2eb40d819dd1@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------hdHkxS7GqQwa4CQTwITTeZgh" X-purgate-ID: tlsNG-d62444/1788441100-C475B757-60EABA23/0/0 X-purgate-type: clean X-purgate-size: 8341 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hdHkxS7GqQwa4CQTwITTeZgh Content-Type: multipart/mixed; boundary="------------GhzrVlNgbDYClm3av51405Ep"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Andrew Precious , Jan Beulich Cc: samuel.thibault@ens-lyon.org, xen-devel@lists.xenproject.org Message-ID: <37902bbd-1ab9-4b49-8f94-4b788b3620d9@suse.com> Subject: Re: [PATCH] stubdom: Fix GCC 14 -Wmemset-elt-size compiler warnings in PolarSSL References: <20260825184605.79318-1-andrewprecious388@gmail.com> <22091019-92ea-4de5-b470-2eb40d819dd1@suse.com> In-Reply-To: Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------GhzrVlNgbDYClm3av51405Ep Content-Type: multipart/mixed; boundary="------------NCHsmzCt30iiGg11cIe9ZAxX" --------------NCHsmzCt30iiGg11cIe9ZAxX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEuMDkuMjYgMTQ6MDcsIEFuZHJldyBQcmVjaW91cyB3cm90ZToNCj4gSSB3YXMgYXQg Zmlyc3QgZGVsaWJlcmF0aW5nIHdoZXRoZXIgdG8gc2VuZCBmdXJ0aGVyIHBhdGNoZXMgYmVj YXVzZSB0aGUgY3VycmVudCANCj4gc3VjY2Vzc29yIG9mIFBvbGFyU1NMIGlzIE1iZWRUTFMu IFBvbGFyc3NsIGlzIG5vdyBsZWdhY3kgJiBub3QgDQo+IG1haW50YWluZWQocG9sYXJzc2wg d2FzIGFjcXVpcmVkIGJ5IEFSTSkuDQo+IE9wdGlvbnM6DQo+IDEuIENvbnRpbnVhbCBwYXRj aGluZy9tYWludGFpbmluZyBhIGxlZ2FjeSBsaWJyYXJ5Lg0KDQpUaGlzIG9uZS4NCg0KTWFp biByZWFzb24gaXMgdGhhdCB0aGVyZSBhcmUgbW9yZSBtb2Rlcm4gYWx0ZXJuYXRpdmVzIHRv IE1pbmktT1MsIGUuZy4NClVOSUtSQUZULiBXZSBkb24ndCB3YW50IHRvIGRvIGEgYmlnIHJl d29yayBvZiB0aGUgWGVuIHN0dWJkb20gZW52aXJvbm1lbnQuDQoNCg0KSnVlcmdlbg0K --------------NCHsmzCt30iiGg11cIe9ZAxX Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------NCHsmzCt30iiGg11cIe9ZAxX-- --------------GhzrVlNgbDYClm3av51405Ep-- --------------hdHkxS7GqQwa4CQTwITTeZgh Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqZcgsFAwAAAAAACgkQsN6d1ii/Ey84 XAf+J6Gta+lRCUXM1oGesAgOT6S9ejsthXlrokAFUxb4O4RTSBuJ6SFD+yp4hfpU68cgmDEnL7/f WRgvjBpGUqaJ5Pu3RzvHpqluKje4+iR0983qg7p1z48Fvk1ToXN0Z0iV9oh/ZB4HKLlKVbqtuKNS Wwt/6v5HW1lc9QXe6nbhlRoAnS2VQwF5I6JUGhW9dQcppWsGid5NHMRbdziSgIikhH3vbLbz9FMH O2Q7GrHtBJdFRag3ecwdOKwBs9IqRitEAXypVY7iDPfntKsLLRaaCEsehVSRIhkpLHTDWo74jVcN zi/nExjEbQBPyMpRZ/PfaI0lyx0nJFjEWXzshHsIMw== =bDQI -----END PGP SIGNATURE----- --------------hdHkxS7GqQwa4CQTwITTeZgh-- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 13:21:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 13:21:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407155.1640264 (Exim 4.92) (envelope-from ) id 1x27Ny-0002OD-11; Thu, 03 Sep 2026 13:21:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407155.1640264; Thu, 03 Sep 2026 13:21:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27Nx-0002O6-UH; Thu, 03 Sep 2026 13:21:45 +0000 Received: by outflank-mailman (input) for mailman id 1407155; Thu, 03 Sep 2026 13:21:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27Nw-0002O0-8V for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:21:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x27Nv-00Aaaz-LJ for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:21:43 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a997461-bab6-0a2a0a5309dd-0a2a450285dc-24 for ; Thu, 03 Sep 2026 15:21:43 +0200 Received: from [209.85.208.46] (helo=mail-ed1-f46.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a997467-6ca4-0a2a45020019-d155d02ed550-3 for ; Thu, 03 Sep 2026 15:21:43 +0200 Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-6a18e24ad25so3266812a12.1 for ; Thu, 03 Sep 2026 06:21:43 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a67f932c41sm2427240a12.15.2026.09.03.06.21.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 06:21:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788441703; x=1789046503; darn=lists.xenproject.org; h=content-type: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:content-type; bh=PQkLytTZT4SN++4srG0hVAU5DCBgVADto5HoLyxq0DU=; b=THnx2mydRjnf8eaJi3023RT2i0KfeVeaLVMB2fH1faa+Hnh+AcfDr+DN6FKkZFmwvD G9MvMsvDgP2Gq/ug4SKR4exCU5jHnmzNt+4D7IjZhv5H8e7qlkKP7ue+oj7ZpkV7S1Qn n3Za185Hm/rzM6CNBlYiGqiWTIGHzn+xpd5zcqwbaSwMIBBBQZLIyySWhZX+b4/8todo Yb4YPl2etLJWRxRaGJ3WQ54/4RltC0oM0TJXdnzs+yHvCMjljv0oFPUNv0SqxiQ53+15 6AFg8k/yyrv27NVKKOLkt2wK3ijwXymj2YGW81kCLBJVNBiAvGSvCjQwTE9VUOcHPGel 3BcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788441703; x=1789046503; h=content-type: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 :content-type; bh=PQkLytTZT4SN++4srG0hVAU5DCBgVADto5HoLyxq0DU=; b=Zk8+5g/kUqzpD+xmF570SjnBni1JRh+u9Vz0jBEJCd374KndvMtNUWfLJnelRuQAf5 jyAsGBWP56ho8d3dBky7HcTvCUGcfLy5FP481n25Uc8Gm3vUtaiAVqIY3ejaPQOxeN2y SN0nE/WfaSsqI1zfgv7VN+0EVGfOIdYyrhL2sYScbB6T/ZjKGzmB+Vk9IUQGIcFye7ht GLn8mCDE7p25v2c/uxBtGvF0/ySzaGdni3GKhIp/KcchpvW92P/tGejb4x1l6ptQbLOY tygivnxiD3nvtSNsBx9+ICYmVuogFX4it1ThFPVcVwSmZj50JZz132wRVa5uP47w8w9Z eAPw== X-Forwarded-Encrypted: i=1; AKwUvByTw1gJCQEmw8FHO7KdQE5kezIZXk8VpKc+THSUltRQnLVrJOQyyeS8lwdycrwrC7rmIyZYbHr0WqY=@lists.xenproject.org X-Gm-Message-State: AFuF++kq/n/6wUwd70rNNloTNLpOnZtm6JK+c8mM11eGoPGkNSO0JpnQ tZxcbE5FCV3096XaD5nRUnXBrvP5YdzY8K2euFcSMRuV7qnECjpI4/oQ1rJGKYsL8gw= X-Gm-Gg: AYBFou3QnIMujx1um3MOW2or+/9bOgQaH4VjUiP0h69Haa2kt74eufpcgCyKcauMyDf /4jVprJpAC19cisjtE9WpVDN6ljtlr1/VjmZVsG0Xjat9Ih4Xw2I8F3w+OnI98Cxtwu7qmYIb6E Wf+VxZtHA86k6K93YOx7f9IfNkVNaoYDscZcXc7mVtifvpXh8tJyqjWCoehQcsdMM5kRyb+T3fz YR5gguGWbP8+tjAXOjepvuR4Hmlsgj9xVJrDFT/TyXE330eLYtD+aj0O7xqk4wnBAzVFwVwgFIQ 0clRB+WfMxvvLapiegbzHjLBGuIkfUmb3egFNi+MqrEWjaTJiyA54KC9TQ5ZIjMKTefZgSG3T53 +yRfxziIOQ0ROPXRgSPYILqYfk/epnenF0Mthk6HU9aD92uOKYlNxga13tZlEPZA9dAc7SAszwS vwud5UrYQkv6is/Vby5CtBuOPEprG///rhT4D+dtHG5WLRjDSYt3j9vZH5h2p91P7JPMOHf2Ayg cGSS4O7XswnWJ/2zNMUx04FE5uVtPaSW49uFEMH8NWNC+sS1NYBo9Wqes0GTLyume8PQ67dZ9dz YM5aDIye+03sDp9uMM9zHsLB X-Received: by 2002:a05:6402:3815:b0:6a6:774e:8a56 with SMTP id 4fb4d7f45d1cf-6a682567105mr9270695a12.4.1788441702626; Thu, 03 Sep 2026 06:21:42 -0700 (PDT) Message-ID: <4c41443a-e856-4e97-bd24-8fb67bb391e3@suse.com> Date: Thu, 3 Sep 2026 15:21:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/apic: Remove dead disable_esr machinery To: Daniil Tatianin , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: Daniil Tatianin <99danilt@gmail.com>, "H. Peter Anvin" , Steve Wahl , Justin Ernst , Kyle Meyer , Dimitri Sivanich , Russ Anderson , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------iWbHXbpzPo1Jfvy0R7j2BLDb" X-purgate-ID: tlsNG-720697/1788441703-F2CB22AC-C54CCF75/0/0 X-purgate-type: clean X-purgate-size: 7802 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------iWbHXbpzPo1Jfvy0R7j2BLDb Content-Type: multipart/mixed; boundary="------------tIP3VVuqkhqbdXkmZAyfita6"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Daniil Tatianin , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: Daniil Tatianin <99danilt@gmail.com>, "H. Peter Anvin" , Steve Wahl , Justin Ernst , Kyle Meyer , Dimitri Sivanich , Russ Anderson , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Message-ID: <4c41443a-e856-4e97-bd24-8fb67bb391e3@suse.com> Subject: Re: [PATCH] x86/apic: Remove dead disable_esr machinery References: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> In-Reply-To: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> --------------tIP3VVuqkhqbdXkmZAyfita6 Content-Type: multipart/mixed; boundary="------------1aIsTFF7uTwgzFFWi4jmvaGy" --------------1aIsTFF7uTwgzFFWi4jmvaGy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDMuMDkuMjYgMDA6MDEsIERhbmlpbCBUYXRpYW5pbiB3cm90ZToNCj4gRnJvbTogRGFu aWlsIFRhdGlhbmluIDw5OWRhbmlsdEBnbWFpbC5jb20+DQo+IA0KPiBhcGljOjpkaXNhYmxl X2VzciB3YXMgYSBxdWlyayBmb3IgdGhlIDMyLWJpdCBOVU1BLVEsIFN1bW1pdCwgRVM3MDAw IGFuZA0KPiBiaWdzbXAgcGxhdGZvcm1zLCB3aGljaCBsZWZ0IHRoZSBsb2NhbCBBUElDIGVy cm9yIHN0YXR1cyByZWdpc3RlciBhbG9uZQ0KPiBiZWNhdXNlICJzb21ldGhpbmcgdW50cmFj ZWFibGUiIHByb2R1Y2VkIGJhZCBpbnRlcnJ1cHRzIG9uIHRob3NlDQo+IG1hY2hpbmVzLiBO VU1BLVEsIFN1bW1pdCBhbmQgRVM3MDAwIHdlbnQgYXdheSBpbiAyMDE0IHdpdGggY29tbWl0 DQo+IGI1NjYwYmE3NmI0MSAoIng4NiwgcGxhdGZvcm1zOiBSZW1vdmUgTlVNQVEiKSwgY29t bWl0IDdjZjZjOTQ1OTFiYg0KPiAoIng4NiwgYXBpYzogUmVtb3ZlIHN1cHBvcnQgZm9yIElC TSBTdW1taXQvRVhBIGNoaXBzZXQiKSBhbmQgY29tbWl0DQo+IDU4ZjVkMmQ0NDg4MyAoIng4 NiwgYXBpYzogUmVtb3ZlIHN1cHBvcnQgZm9yIGlhMzItYmFzZWQgVW5pc3lzIEVTNzAwMCIp LA0KPiBhbmQgdGhlIGxhc3Qgc2V0dGVyIHdlbnQgd2l0aCBjb21taXQgMGFiZjUwODY3NWMw ICgieDg2L3NtcDogRHJvcA0KPiAzMi1iaXQgImJpZ3NtcCIgbWFjaGluZSBzdXBwb3J0Iiku IEV2ZXJ5IHJlbWFpbmluZyBBUElDIGRyaXZlcg0KPiBpbml0aWFsaXplcyB0aGUgZmxhZyB0 byB6ZXJvLg0KPiANCj4gUmVtb3ZlIHRoZSBmbGFnLCB0aGUgRVNSIHNldHVwIGJ5cGFzcyBr ZXllZCBvbiBpdCBhbmQgdGhlIDMyLWJpdCBvbmx5DQo+IEVTUiBjbGVhcmluZyBoYW1tZXIg aW4gc2V0dXBfbG9jYWxfQVBJQygpLCB3aGljaCB3YXMgZ2F0ZWQgb24gdGhlIHNhbWUNCj4g ZmxhZyBhbmQgdGhlcmVmb3JlIGVxdWFsbHkgZGVhZC4NCj4gDQo+IE5vIGZ1bmN0aW9uYWwg Y2hhbmdlcy4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IERhbmlpbCBUYXRpYW5pbiA8ZC10YXRp YW5pbkB5YW5kZXgtdGVhbS5ydT4NCg0KQWNrZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9z c0BzdXNlLmNvbT4gIyBYZW4gcGFydA0KDQoNCkp1ZXJnZW4NCg== --------------1aIsTFF7uTwgzFFWi4jmvaGy Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------1aIsTFF7uTwgzFFWi4jmvaGy-- --------------tIP3VVuqkhqbdXkmZAyfita6-- --------------iWbHXbpzPo1Jfvy0R7j2BLDb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqZdGUFAwAAAAAACgkQsN6d1ii/Ey82 gAf8DsUJTn4oLgaXK8vEf9d3s6Ux3cSyhOC83QycarbB9fCeHEwJkJba/DO8+L+jvYcwDa7AsC1v ybzCvUrXwuYUBQK/odBzbRIMQuxLL5wct+e2HYEbLw/t/7gayJCiKdzXqQO/XLzlJrcPMXn5Fr2e mS6kc5dwlStPDVEkyFiXAL5YT1q0FChAJJC2xOy91Xs5wEnOhPee4ZPYNaPX95rN2x6of23o76Gr S0Jk04w3Jdq8WAt6P3Yx953IV9e8ljWx3yLMlGnMwXeAgNR3yXk0DHdVAcV7tBU8TfeBg2R9JpIi zNfsJn1HboyPCDz/wLc8L2ji2JA2oDrp1FTbQL4kKg== =SqeV -----END PGP SIGNATURE----- --------------iWbHXbpzPo1Jfvy0R7j2BLDb-- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 13:26:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 13:26:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407168.1640273 (Exim 4.92) (envelope-from ) id 1x27SL-0002zp-JT; Thu, 03 Sep 2026 13:26:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407168.1640273; Thu, 03 Sep 2026 13:26:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27SL-0002zi-Gq; Thu, 03 Sep 2026 13:26:17 +0000 Received: by outflank-mailman (input) for mailman id 1407168; Thu, 03 Sep 2026 13:26:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27SK-0002zc-64 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:26:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x27SJ-00FAeG-4i for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:26:15 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a997569-8faa-0a2a0a5109dd-0a2a4504ecc8-24 for ; Thu, 03 Sep 2026 15:26:15 +0200 Received: from [209.85.218.48] (helo=mail-ej1-f48.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a997576-b57f-0a2a45040019-d155da30a9c7-3 for ; Thu, 03 Sep 2026 15:26:15 +0200 Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-c169ae1cb26so187541466b.1 for ; Thu, 03 Sep 2026 06:26:15 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c25f41ebab0sm102888866b.47.2026.09.03.06.26.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 06:26:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788441974; x=1789046774; darn=lists.xenproject.org; h=content-type: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:content-type; bh=7BrbMtXhaTTrPbAHQ/5eQD6nXEyZDrBEvHrkx9jVTU4=; b=Va9gN3+K7b0EMkATV4cZifG8zIKs26qlvHJ8RwwdJAM1hibR8ZxlBBH3NrOIjW6Mby R13Muin6fir/2vJ2zgXDzYwr6yEhX0JNKZKpbx1+m542gnKgi+NZ6CXOOfspyl8K3IJp KIEcZZ045hMhmnyiL7LE9Kd64DCR0ePWYmOMISbc3CDZMZkGfr3PVJoebCSA4fdwvBlJ ovWmfLA92EkuSYZW7m5p0p630yPom7nM9gPlYmMxYprv6ANClUqc6gWyRnQPs1fNA2+v Q31613ZFtdg26643gSjEnVAnft1yFv1e4kCyg77TVRSufEmlCFHoszyAGMwj+z5SqJNq D/KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788441974; x=1789046774; h=content-type: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 :content-type; bh=7BrbMtXhaTTrPbAHQ/5eQD6nXEyZDrBEvHrkx9jVTU4=; b=skp8/L9oTKEKoDRAfZ1GSqRlCIpX/cl24DPEpVC8DTCp0bnW9F/s198DhLKb8Gj5GX J+EUFlSrIws/SEpLO8GI1/YES1G1aBkkmP6TVdER6Qw3LyOkrDOWRlQyXM85KFo+xSXq 5vAlXgOvmE9QD0wlQWaaj4js5e0/Oe4S8F4DCoNYsT3g6EqZGFus5PsQm8gyc9EemXJ1 sKDTM7RHN4aiIZIwa9hWYbGjubfd1vblDDmNvyTLS3aQcac+93u70mqhjPww1K4BloDC DI3yi3ICB0DTwT/+I8046ftKb/Hd+lKmtR8xY4/BkFjRtO9D/M84Ra+hbgUp4VkQZ3sU 0+4g== X-Forwarded-Encrypted: i=1; AKwUvBw5Ov68cT3Tyv9z/GnERvaWev0EufzI20Thv0lZP9pjEaASXUOstXtpSM4es6dMWEkSeAVgcloxLvE=@lists.xenproject.org X-Gm-Message-State: AFuF++nZ95eJfTB9xuEh7IOAK1Whk7DZLF/PW9YP/8kS9lNJvyuK0rxS 6phakqY6FB9PmYNelVlKdCmXk5OQkmJZ2BS455ATZ9ZCxQe5sGxAhn6IMClvPx8LN2OhuSeUEvs VpKoOG2A= X-Gm-Gg: AYBFou32P/YefBQQAc2V93z5+azjumlhtbRYdoaluZ9aM6XXhdLgAcP3qppmAcHKbq2 Kd5Wxv/gFjl/GgOvuPiCvp+74tsC+fbIWRm/LCSipwPStJ1jwBx4YxmdNLQ05PzffrkMyudj1LM OJZ5WKsCZdseiny1WMIaTcDZI+MwCqZuJvqkLuWQwlXE6e5bApJ9IvNYQBQtqAm71ix8yhhyDA7 KyifPBNu9q5b6F3texNxqzFGlQ1DJk0onvdZOKM4AHgaZppniEUf5RgW5g6zVkoiPLqHShrX77X 2XbyG4kSZUHs2J1DJPq84dtE5g4xOPS1gFZK9Df9oeHnuwh9szgMBZvU5uoSLgHTnjreKSzkSxC DbWqytFr62Wnk0Iw4Aiz/qNKp11VDmOJMb7iJK4FhB1dtkIbW8AF/gQgJ+fNYQMGZOhoLdQw/tP yYFbkshwaDSm/9yM063aEaLsvEnjSLDtBiVJtiknewGjzgx1rCCqod5i6hUgQ82/ohXG3YUKPjp EsEySjGkgUvowuLJUfn3Bkp69tAp3GtQP+Zwj7M1R8Gu0c+WM+zI9uFzMm8qk7LhfksKL/ZLBiO mdpf1GgGfQ== X-Received: by 2002:a17:906:f58c:b0:c25:f7db:4bec with SMTP id a640c23a62f3a-c25f8158bd1mr179749166b.18.1788441974392; Thu, 03 Sep 2026 06:26:14 -0700 (PDT) Message-ID: <873b8735-e425-4f4f-bfb3-851a6c52f9f1@suse.com> Date: Thu, 3 Sep 2026 15:26:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] sched/core: avoid use of "current" in initializer lists To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Dario Faggioli , George Dunlap References: <4eaf8244-25ec-45d4-844d-3d8f6720f57b@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <4eaf8244-25ec-45d4-844d-3d8f6720f57b@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------XXNbN5WEj2u055dOVKi9tNzY" X-purgate-ID: tlsNG-ebf023/1788441975-C06DAB50-E291E8C4/0/0 X-purgate-type: clean X-purgate-size: 12956 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------XXNbN5WEj2u055dOVKi9tNzY Content-Type: multipart/mixed; boundary="------------wWCgCj4xFw0GLjlcL4lVtL3f"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Dario Faggioli , George Dunlap Message-ID: <873b8735-e425-4f4f-bfb3-851a6c52f9f1@suse.com> Subject: Re: [PATCH 3/4] sched/core: avoid use of "current" in initializer lists References: <4eaf8244-25ec-45d4-844d-3d8f6720f57b@suse.com> In-Reply-To: <4eaf8244-25ec-45d4-844d-3d8f6720f57b@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------wWCgCj4xFw0GLjlcL4lVtL3f Content-Type: multipart/mixed; boundary="------------MGeXDCz6XsrCoSPcdhIfnAF0" --------------MGeXDCz6XsrCoSPcdhIfnAF0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDMuMDkuMjYgMTM6NTMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBUUkFDRV9USU1FKCkg dXNlcyBhbiBpbml0aWFsaXplciBsaXN0IGFuZCBoZW5jZSBpcyBjb3ZlcmVkIGJ5IE1pc3Jh IEM6MjAxMg0KPiBydWxlIDEzLjEgKCJJbml0aWFsaXplciBsaXN0cyBzaGFsbCBub3QgY29u dGFpbiBwZXJzaXN0ZW50IHNpZGUgZWZmZWN0cyIpLg0KPiBVc2UgaW50ZXJtZWRpYXRlIHZh cmlhYmxlcyB0byBhZGRyZXNzIHRoaXMuDQo+IA0KPiBJbiB2Y3B1X3lpZWxkKCkgdGFrZSB0 aGUgb3Bwb3J0dW5pdHkgdG8gcmVuYW1lIHRoZSBleGlzdGluZyB2YXJpYWJsZSB3aGljaA0K PiBiZXR0ZXIgd291bGQgaGF2ZSBiZWVuIHVzZWQgYWxyZWFkeSBiZWZvcmUuDQo+IA0KPiBJ biBkb19zY2hlZF9vcCgpIGV4dGVuZCB0aGUgc2NvcGUgb2YgYW5kIHJlbmFtZSBhbiBleGlz dGluZyB2YXJpYWJsZS4gQWxzbw0KPiBkcm9wIGEgcG9pbnRsZXNzIChhbmQgc2xpZ2h0bHkg bWFsZm9ybWVkLCBzdHlsZS13aXNlKSBjYXN0IHRoZXJlLCBhbmQNCj4gYWRqdXN0IHRvIG90 aGVyIG9uZSB0byBieSBzdHlsZSBjb25mb3JtYW50Lg0KPiANCj4gTm8gZnVuY3Rpb25hbCBj aGFuZ2UgaW50ZW5kZWQuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJl dWxpY2hAc3VzZS5jb20+DQo+IC0tLQ0KPiBOb3RlIHRoYXQgdGhlIHZpb2xhdGlvbnMgcHJl c2VudGx5IGFyZSByZXBvcnRlZCBvbmx5IGZvciBBcm0uIFNpbWlsYXINCj4gaXNzdWVzIHdv dWxkIGV4aXN0IG9uIHg4NiBpbiBDbGFuZyBidWlsZHMsIGFmYWljdC4NCj4gDQo+IC0tLSBh L3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+ICsrKyBiL3hlbi9jb21tb24vc2NoZWQvY29y ZS5jDQo+IEBAIC0xNTMxLDIwICsxNTMxLDIwIEBAIHN0YXRpYyBsb25nIGRvX3BvbGwoY29u c3Qgc3RydWN0IHNjaGVkX3ANCj4gICAvKiBWb2x1bnRhcmlseSB5aWVsZCB0aGUgcHJvY2Vz c29yIGZvciB0aGlzIGFsbG9jYXRpb24uICovDQo+ICAgbG9uZyB2Y3B1X3lpZWxkKHZvaWQp DQo+ICAgew0KPiAtICAgIHN0cnVjdCB2Y3B1ICogdj1jdXJyZW50Ow0KPiArICAgIHN0cnVj dCB2Y3B1ICpjdXJyID0gY3VycmVudDsNCj4gICAgICAgc3BpbmxvY2tfdCAqbG9jazsNCj4g ICANCj4gICAgICAgcmN1X3JlYWRfbG9jaygmc2NoZWRfcmVzX3JjdWxvY2spOw0KPiAgIA0K PiAtICAgIGxvY2sgPSB1bml0X3NjaGVkdWxlX2xvY2tfaXJxKHYtPnNjaGVkX3VuaXQpOw0K PiAtICAgIHNjaGVkX3lpZWxkKHZjcHVfc2NoZWR1bGVyKHYpLCB2LT5zY2hlZF91bml0KTsN Cj4gLSAgICB1bml0X3NjaGVkdWxlX3VubG9ja19pcnEobG9jaywgdi0+c2NoZWRfdW5pdCk7 DQo+ICsgICAgbG9jayA9IHVuaXRfc2NoZWR1bGVfbG9ja19pcnEoY3Vyci0+c2NoZWRfdW5p dCk7DQo+ICsgICAgc2NoZWRfeWllbGQodmNwdV9zY2hlZHVsZXIoY3VyciksIGN1cnItPnNj aGVkX3VuaXQpOw0KPiArICAgIHVuaXRfc2NoZWR1bGVfdW5sb2NrX2lycShsb2NrLCBjdXJy LT5zY2hlZF91bml0KTsNCj4gICANCj4gICAgICAgcmN1X3JlYWRfdW5sb2NrKCZzY2hlZF9y ZXNfcmN1bG9jayk7DQo+ICAgDQo+ICAgICAgIFNDSEVEX1NUQVRfQ1JBTksodmNwdV95aWVs ZCk7DQo+ICAgDQo+IC0gICAgVFJBQ0VfVElNRShUUkNfU0NIRURfWUlFTEQsIGN1cnJlbnQt PmRvbWFpbi0+ZG9tYWluX2lkLCBjdXJyZW50LT52Y3B1X2lkKTsNCj4gKyAgICBUUkFDRV9U SU1FKFRSQ19TQ0hFRF9ZSUVMRCwgY3Vyci0+ZG9tYWluLT5kb21haW5faWQsIGN1cnItPnZj cHVfaWQpOw0KPiAgICAgICByYWlzZV9zb2Z0aXJxKFNDSEVEVUxFX1NPRlRJUlEpOw0KPiAg ICAgICByZXR1cm4gMDsNCj4gICB9DQo+IEBAIC0xOTE0LDYgKzE5MTQsOCBAQCB0eXBlZGVm IGxvbmcgcmV0X3Q7DQo+ICAgDQo+ICAgcmV0X3QgZG9fc2NoZWRfb3AoaW50IGNtZCwgWEVO X0dVRVNUX0hBTkRMRV9QQVJBTSh2b2lkKSBhcmcpDQo+ICAgew0KPiArICAgIGNvbnN0IHN0 cnVjdCB2Y3B1ICpjdXJyID0gY3VycmVudDsNCj4gKyAgICBzdHJ1Y3QgZG9tYWluICpjdXJy ZCA9IGN1cnItPmRvbWFpbjsNCj4gICAgICAgcmV0X3QgcmV0ID0gMDsNCj4gICANCj4gICAg ICAgc3dpdGNoICggY21kICkNCj4gQEAgLTE5MzgsOSArMTk0MCw5IEBAIHJldF90IGRvX3Nj aGVkX29wKGludCBjbWQsIFhFTl9HVUVTVF9IQU4NCj4gICAgICAgICAgIGlmICggY29weV9m cm9tX2d1ZXN0KCZzY2hlZF9zaHV0ZG93biwgYXJnLCAxKSApDQo+ICAgICAgICAgICAgICAg YnJlYWs7DQo+ICAgDQo+IC0gICAgICAgIFRSQUNFX1RJTUUoVFJDX1NDSEVEX1NIVVRET1dO LCBjdXJyZW50LT5kb21haW4tPmRvbWFpbl9pZCwNCj4gLSAgICAgICAgICAgICAgICAgICBj dXJyZW50LT52Y3B1X2lkLCBzY2hlZF9zaHV0ZG93bi5yZWFzb24pOw0KPiAtICAgICAgICBy ZXQgPSBkb21haW5fc2h1dGRvd24oY3VycmVudC0+ZG9tYWluLCAodTgpc2NoZWRfc2h1dGRv d24ucmVhc29uKTsNCj4gKyAgICAgICAgVFJBQ0VfVElNRShUUkNfU0NIRURfU0hVVERPV04s IGN1cnJkLT5kb21haW5faWQsIGN1cnItPnZjcHVfaWQsDQo+ICsgICAgICAgICAgICAgICAg ICAgc2NoZWRfc2h1dGRvd24ucmVhc29uKTsNCj4gKyAgICAgICAgcmV0ID0gZG9tYWluX3No dXRkb3duKGN1cnJkLCBzY2hlZF9zaHV0ZG93bi5yZWFzb24pOw0KPiAgIA0KPiAgICAgICAg ICAgYnJlYWs7DQo+ICAgICAgIH0NCj4gQEAgLTE5NDgsMTkgKzE5NTAsMTggQEAgcmV0X3Qg ZG9fc2NoZWRfb3AoaW50IGNtZCwgWEVOX0dVRVNUX0hBTg0KPiAgICAgICBjYXNlIFNDSEVE T1Bfc2h1dGRvd25fY29kZToNCj4gICAgICAgew0KPiAgICAgICAgICAgc3RydWN0IHNjaGVk X3NodXRkb3duIHNjaGVkX3NodXRkb3duOw0KPiAtICAgICAgICBzdHJ1Y3QgZG9tYWluICpk ID0gY3VycmVudC0+ZG9tYWluOw0KPiAgIA0KPiAgICAgICAgICAgcmV0ID0gLUVGQVVMVDsN Cj4gICAgICAgICAgIGlmICggY29weV9mcm9tX2d1ZXN0KCZzY2hlZF9zaHV0ZG93biwgYXJn LCAxKSApDQo+ICAgICAgICAgICAgICAgYnJlYWs7DQo+ICAgDQo+IC0gICAgICAgIFRSQUNF X1RJTUUoVFJDX1NDSEVEX1NIVVRET1dOX0NPREUsIGQtPmRvbWFpbl9pZCwgY3VycmVudC0+ dmNwdV9pZCwNCj4gKyAgICAgICAgVFJBQ0VfVElNRShUUkNfU0NIRURfU0hVVERPV05fQ09E RSwgY3VycmQtPmRvbWFpbl9pZCwgY3Vyci0+dmNwdV9pZCwNCj4gICAgICAgICAgICAgICAg ICAgICAgc2NoZWRfc2h1dGRvd24ucmVhc29uKTsNCj4gICANCj4gLSAgICAgICAgc3Bpbl9s b2NrKCZkLT5zaHV0ZG93bl9sb2NrKTsNCj4gLSAgICAgICAgaWYgKCBkLT5zaHV0ZG93bl9j b2RlID09IFNIVVRET1dOX0NPREVfSU5WQUxJRCApDQo+IC0gICAgICAgICAgICBkLT5zaHV0 ZG93bl9jb2RlID0gKHU4KXNjaGVkX3NodXRkb3duLnJlYXNvbjsNCj4gLSAgICAgICAgc3Bp bl91bmxvY2soJmQtPnNodXRkb3duX2xvY2spOw0KPiArICAgICAgICBzcGluX2xvY2soJmN1 cnJkLT5zaHV0ZG93bl9sb2NrKTsNCj4gKyAgICAgICAgaWYgKCBjdXJyZC0+c2h1dGRvd25f Y29kZSA9PSBTSFVURE9XTl9DT0RFX0lOVkFMSUQgKQ0KPiArICAgICAgICAgICAgY3VycmQt PnNodXRkb3duX2NvZGUgPSAodWludDhfdClzY2hlZF9zaHV0ZG93bi5yZWFzb247DQo+ICsg ICAgICAgIHNwaW5fdW5sb2NrKCZjdXJyZC0+c2h1dGRvd25fbG9jayk7DQo+ICAgDQo+ICAg ICAgICAgICByZXQgPSAwOw0KPiAgICAgICAgICAgYnJlYWs7DQo+IA0KDQpXaGF0IGFib3V0 IHRoZSB1c2Ugb2YgY3VycmVudCBpbiBTQ0hFRE9QX3dhdGNoZG9nIGFuZCBTQ0hFRE9QX3Bp bl9vdmVycmlkZQ0KaGFuZGxpbmc/DQoNCg0KSnVlcmdlbg0K --------------MGeXDCz6XsrCoSPcdhIfnAF0 Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------MGeXDCz6XsrCoSPcdhIfnAF0-- --------------wWCgCj4xFw0GLjlcL4lVtL3f-- --------------XXNbN5WEj2u055dOVKi9tNzY Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqZdXUFAwAAAAAACgkQsN6d1ii/Ey/C xwf/X+uJJ78c58anrU3RN0ygOVJYvomJvrGUZ33hS8ap3r0iuXqB4CH+IAIB7Qtu7tRYZjuMdDCH eOfJWiTQJtstph7IE2hjFuxQsrzkd84G5yJCU1yAfowsYLb40cL/mWkV0DdKP8Kne3FHMcvnaFnL L8m0CsuIQjuzHW3X6vbtLXLEUSyqC6ZpGFkwKcJMlXUi7Mqr8G1yyJwvecq8dIWN6VAqR7bFZlJT UhMw0ZL3kvbksX41Ag8kG2CgLkR0dHIqnGgnrmYr7gjQ0ukJ3yMJmJJZaK9SU2Ht4udvIzKhcpMQ yUy2E2Ml3HPqkVmBc4YF67fRYEkU9K0bjGZWza2KwA== =eNl/ -----END PGP SIGNATURE----- --------------XXNbN5WEj2u055dOVKi9tNzY-- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 13:35:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 13:35:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407186.1640281 (Exim 4.92) (envelope-from ) id 1x27bX-0004l6-Eu; Thu, 03 Sep 2026 13:35:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407186.1640281; Thu, 03 Sep 2026 13:35:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27bX-0004kz-C2; Thu, 03 Sep 2026 13:35:47 +0000 Received: by outflank-mailman (input) for mailman id 1407186; Thu, 03 Sep 2026 13:35:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27bW-0004kt-8i for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:35:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x27bV-00Ad7F-Kg for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:35:45 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9977b1-2eae-0a2a0a5409dd-0a2a45058140-2 for ; Thu, 03 Sep 2026 15:35:45 +0200 Received: from [40.107.209.64] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9977af-4cb1-0a2a45050019-286bd140c5ef-3 for ; Thu, 03 Sep 2026 15:35:45 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by IA1PR03MB8062.namprd03.prod.outlook.com (2603:10b6:208:595::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Thu, 3 Sep 2026 13:35:40 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Thu, 3 Sep 2026 13:35:40 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FzKMWBY2ROvImy8RsNbZDqrnj6VV3x21Q6PP2A7Jcw/z08oGGAf6CRTPn5JaxYLRkptT1YNmhzOJPBuidanZsYVKZrKtydle/TYpUbqCZKArhegDdj4iFQ1FdONsib9VGYzKLpMQ/12uSJGPKiKK1SDhn1WB9/dAFa0/xkc8EKP7Ln9UpyiocJEVZX+1+hWkjD4KLACGYXmbifVcJ4afXYjUCZUbQ2+dQO8qqf9ngkBe9EGgNefU3f7AT3gyiTYlzycMDOtuphtqXrPTD+2sxmsy+8AnbXRHWgRqqWdlkmY7kTev08/nmKdIRcowA7q3Gjs8/nD+INZMXYF2kKdR5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=o1ndxIMHm+9Fc252ktH03lLK6XaDXQ6ekAlPo8ysQZI=; b=e8jIgvu/ucn+Tb0Z4+oTOHX1y/C8DHZ5EIqnInObHRyRSU5w7+uHbV4IyLwTd+EFIjSoMye76yHUgAqNKkP9ArHN2m+UugTdtlNcFBxYyu1bBdkkOtcguDu2kyiLkUcwN45uBUQzXCkc9fBWISaEGZMWlGb1QC+pVt0SVaw4IlzVuOA7e4Ta/qXADvj0KEGQ1cpKeMFAdkaO4fuGujYOX42tQPBDFAgGGepkXQ36+L07p8RAHI0wUNLyUz5LyFSDEdMinjz5uYkKYarWwSinfaqKdb8lFhAPCtJ5ssTgERhyJRV4wE8H95nnKNLvZmX3wOzVx7+nKkBeW1SS4oJp7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o1ndxIMHm+9Fc252ktH03lLK6XaDXQ6ekAlPo8ysQZI=; b=kq8aLX2un+o187JdOCCzJxiK8Tymy8koV9U8SZTIQJnVwPVECibYZ1UTlcfRscEk/J5S7MITJM1YYVLxk6yaDIx8tY3X1isMERf2pAzx5AZiAtK0qXKSawTnd2uudtZCWHNqUUC/4EMEc+OxF+525XPfN9wFOnoW6app55u0eNo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 3 Sep 2026 14:35:36 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/svm: Intercept CR0 writes selectively To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828141955.4009939-1-ross.lagerwall@citrix.com> <514b9ad4-912c-45fa-9450-3c85adaef483@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <514b9ad4-912c-45fa-9450-3c85adaef483@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0389.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18f::16) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|IA1PR03MB8062:EE_ X-MS-Office365-Filtering-Correlation-Id: 20493461-ee20-4fc4-c15c-08df09c03f0a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|18002099003|22082099003|11063799006|56012099006|4143699003|10067099003; X-Microsoft-Antispam-Message-Info: O3Yb9zPwchWM7nG3yj3SHUt5PpmM+0g84ZAYd5idPAaigGQKLKIf8lPSvFafIdtU0l6MvkJnfcR3t6ByhmDM7lfbMX6fnZ8zzIhf7VWwfWLKDTKbpk5Pwvi8GHYxA+sxJh3+EGVdx+nc+neM3jHQWhfx0Eh5Uvyf/ziQYeK8Ep0fACcjrxY59UMo/Z9ffls/xQyD9NvDEHDXIVYmIUGuMJJ4lbqpm6cgLe7mjNd0Il8fcX8JIlqbaYbBwwnarT2bpWlHfv6Hp5KIZRJDRsuKfTFK4lYMiOjVOlnwHTZo23vnfKJoS9SqyA+BiQ8aJp6iQuX5jG/myLAWunRgGIK6x3EQ6JQKscAfLlxMJa/BRjeIUKGzP2VfgmYhKrxO3Q5uVgkIVjWUf4vZVQxDBS3eBZbj7ATTC/wtdAMptdAcdQxFHvsnbCRzQ8jYRh8/Fez18SnD5CZbbIE5X/aUmhj4D9v3G+xLV3nygz2dnPcty2gxCrZnnVwLcQjzSBof2MRmnY2mIZWnrW41rwR9aeKzhGlN5Aym4WivGUzexmIggwAclpZmHzmLMihvA1FlYnVc/mDgM3Zx+nJbxdORb/ZsufqN7wzZHBYVgu5X3yWm2Subwfgqq31Z+AU9xx7LEMk63eq0nv11FgKpMrKZJB+N3IQCnUHR2HoDnzf8w3Xu6ok= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(18002099003)(22082099003)(11063799006)(56012099006)(4143699003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OTRuRXA5QURCVEs3dWVtTmtmS3I4N0tqSjVyZUlUMVZrcTZWUGR5ZXc0Sjd5?= =?utf-8?B?ZVg3S0NteFFmZnprNTJvaUl2M0plVVo1LzNPVTZ0Q0Jxd056V3hUU0VuUjFW?= =?utf-8?B?eXRBaHg3S0pqekJ2c2pMMzVKandzMy9wWU02cVBZc2RjNjdVVjB3L3RDTUFK?= =?utf-8?B?cW54M1I2L2ZDWXB5STdGVUpwMUxTVkVFZ2x1ektJVmh0ZndsMC9ZSk1CM0JC?= =?utf-8?B?cFhoYlpsOW5GdFB5UFVaWjdOZVpaTXNqY3pVTU5qc2ZlNWo4K0ZjNUgvMGxU?= =?utf-8?B?WExsWGh1UGRwRFZZbGhmMGRrdmRlRDZVcnJTTWs5Y0RFSDEwTGg0T21nMlBR?= =?utf-8?B?dU5IdnY2bnllNERZRGF0ZG4xWUNuOWFBTlh2L0JZMis1NUp6cVk4WWpqSVRo?= =?utf-8?B?d1dieEE4VjBzd1pVb09hNWZyWUZuWDVEcldxMXFoZ0J6TFV2OHNha215Y3F2?= =?utf-8?B?UDIvSHl1YU02ajV1b3V4RlpzeDY3c2Q1ZERXNGdIR0xJQW11dUQ1Y0dVY25m?= =?utf-8?B?SDExejRoSmQ5c0JqQVZpbFROTmpUUW5PS3ZwREhzYnRVK3FqKzRwY1VtS2JT?= =?utf-8?B?MjF2dzdVTTB6b05tZ3kyTU5zb2doNUZ2WXJJS0MzV1BMSDlwSENCdXhUMCt1?= =?utf-8?B?aGJlRG5kK2lYVnkyY3BSUUxJelBQWTFjdmJYUG5mNWJCcGZvSWZCQUtYL0pZ?= =?utf-8?B?SGxaNEYvQ09IYjFTZ1VTb2x0N2hnM2J6RURjTjdLSDFpN2tMY21RSy9pQzAv?= =?utf-8?B?V0NVTTcwdzdVK2duK0IwSHlyN0pNREtQdlRzb0FTM1VYNThSSnBjeWlGaEVI?= =?utf-8?B?MEh2UXM2ZHhxNXBrdGZxY1VvSk1EcVB1UjczNXVxd1QwL292T1hTd01mS0hJ?= =?utf-8?B?TnFzVlU4WXFmNmRNdUx4RW1BNW8vSXIrWHhkWWR2dmhxMkIrRkE1ZitpQ3pM?= =?utf-8?B?ZXNKSDBEUFYxUUQzazl2MEt0Nmx3SUUrdVR1R2c2SGswRldPa0JjMUVJbzZL?= =?utf-8?B?bnpVRWh1MUFKUnFPdWc1UFd2dnZZVkQvMVBJMktueXBXblU4RFFNaWI4R1Fs?= =?utf-8?B?NzN3T1Q4MUpzMTIzTjQwTnl5QVFHS2NkZWNDdkhtSmpnYWFJWGNWOWZUN0dI?= =?utf-8?B?YjM0ZXp1WXFlMU1FUFAwbW9YVHgxVzZqQWxNU000WmFGQ3F4QVdyMVRJQkly?= =?utf-8?B?TTZyTHp6ZFFHUHB1WE5nVUxOVC9YdmgyMmZNNUVsZ3lzNGUxMjJkVXlMRTBj?= =?utf-8?B?TGlUaGhOYzJad3NWWUU5RkRod2FDMkhkZ3ZGRDhyVUVDclo1T2J4ZFozM09S?= =?utf-8?B?NWRTWi9EVklMK2NoVGtvOCtZYkR0VEU4YVkyb3BReWtxamQ2UEpiY254bTlX?= =?utf-8?B?NFI4STFjdFJIcDRRbmNYZFd5MGt5TU1KaHJZQWtYbUUya283ZDR3cTBFMWU4?= =?utf-8?B?bXNDTjdkNFVIY3E2VFliWmMxWU9BWWJPeHNGVVN2SUk1YjgxVjBNUTJ3WkI4?= =?utf-8?B?ODFsejBXZ2IvNlg4ZHhFTjg0ZDZXRzZNckh6TkVOOGdHUFdrdXFERG14UFYx?= =?utf-8?B?ZlZURHkxazR3djB1N0daWDJNL3V5OUxVa1ZrdFJ1QlY1cXVFcjVyUmdmcWxk?= =?utf-8?B?V0V2MmxLdVR4Y0dhRlNheGIrV0lIeTJmWWg4UUovR3dtRlN4VllQeTRVSGJj?= =?utf-8?B?bHJGdXdQN3R6ZW9maTFGVHkzc2dkYXhIdmZ4SDI3OHVQTjkrSDhSb0JuMDNK?= =?utf-8?B?NFpFeCtaNHYzdHRieVYvTmloaGhIRGZhQVR6MXQ3cUxJQW85eGRMUXAwbFhz?= =?utf-8?B?bzBVMStpL25KQm5tZ2J1ZzF4aEF5bFoxenk1YzZ0TUdXbTFhSU9yNkVWUFRR?= =?utf-8?B?cUxxZWk3VUJGZDFZc0dyV0JhVnJOOVhWSEptSjJYRHFpSlVhNTlFUGVaVDBI?= =?utf-8?B?TWNpTTZUbXFyS05LZFV0NisyRnV6ZnNmaGxrZmV6ZEY5Z1p4d3V3NHF2bnJY?= =?utf-8?B?TVRQYlBjOVJDZGFGQUh0SGMwdUZGVk4yTVZyRG43cW9aT1RGQTc1ZC9KUXNK?= =?utf-8?B?VDVLanJ1bkRrMzlpYWZHWGNoSlhENUJQdUg2cnFSVzdHOXM5Vm90Q2h3eHNQ?= =?utf-8?B?cC9kMzVRSlhRNFB3SW9mNkNUREc3Z3dudFIxcy91VDFZZ2c5K2llL0VrSUlh?= =?utf-8?B?ckR0K29GRGtVbXQ4aHVIaS81V2EyN3NqeTVXaUNqR1ExcFlQSHRyd2JxTU1U?= =?utf-8?B?WUVaTzRmbkpNakRtVDBnaVJaWC95ODNWVmR3REtMcTgyLzJzblp6aVYybXNM?= =?utf-8?B?bm5oWFdwM0hSNVIxMU1ieWNqdXFNbDhaUHhRVVErZ3FYV0ptdW9DN3RSOU4v?= =?utf-8?Q?9BKV736ExMZMt4g8=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20493461-ee20-4fc4-c15c-08df09c03f0a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 13:35:40.7748 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hO53ro/ycPgxhpyPIFsQB6h77UfPxQ8bMFFvB9lBba1HiKU9r1c3Kza58C889l5XJu5SN03yKaJb62HZ05MIqabhDOSypGpobDjJuSUcALs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR03MB8062 X-purgate-ID: tlsNG-c201ff/1788442545-251182A1-A0FD2D7F/0/0 X-purgate-type: clean X-purgate-size: 1416 On 9/3/26 2:02 PM, Jan Beulich wrote: > On 28.08.2026 16:19, Ross Lagerwall wrote: >> Xen does not need to track when the TS or MP bits change so opt to >> intercept CR0 writes selectively. > > Not anymore, which may want expressing here (or else it looks as if this > would have been possible from the start). > >> Aside from potentially reducing a few >> VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE >> and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so >> L1 never sees any CR0 writes. > > Yet if L1 sets CR0_WRITE, since intercept masks are ORed together (if > I'm not mistaken), ... > >> @@ -2882,7 +2884,8 @@ void asmlinkage svm_vmexit_handler(void) >> break; >> >> case VMEXIT_CR0_READ ... VMEXIT_CR15_READ: >> - case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE: >> + case VMEXIT_CR1_WRITE ... VMEXIT_CR15_WRITE: >> + case VMEXIT_CR0_SEL_WRITE: >> if ( cpu_has_svm_decode && vmcb->ei.mov_cr.mov_insn ) >> svm_vmexit_do_cr_access(vmcb, regs); >> else if ( !hvm_emulate_one_insn(x86_insn_is_cr_access, "CR access") ) > > ... we may still see VMEXIT_CR0_WRITE here (i.e. its handling cannot be > removed). > No, it shouldn't get here in that case. If L1 sets CR0_WRITE, it will enter nestedsvm_check_intercepts() and then hit the NESTEDHVM_VMEXIT_INJECT case. Ross From xen-devel-bounces@lists.xenproject.org Thu Sep 03 13:48:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 13:48:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407201.1640290 (Exim 4.92) (envelope-from ) id 1x27nq-0006qw-JZ; Thu, 03 Sep 2026 13:48:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407201.1640290; Thu, 03 Sep 2026 13:48:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27nq-0006qp-GV; Thu, 03 Sep 2026 13:48:30 +0000 Received: by outflank-mailman (input) for mailman id 1407201; Thu, 03 Sep 2026 13:48:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27np-0006qj-3f for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:48:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x27no-00AfEe-93 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:48:28 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a997aac-8faa-0a2a0a5109dd-0a2a4509a5ac-0 for ; Thu, 03 Sep 2026 15:48:28 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a997aab-be1a-0a2a45090019-d155dd32a416-3 for ; Thu, 03 Sep 2026 15:48:28 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-485853f8800so247929f8f.0 for ; Thu, 03 Sep 2026 06:48:28 -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 ffacd0b85a97d-48448e80388sm15726191f8f.14.2026.09.03.06.48.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 06:48:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788443307; x=1789048107; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=IpiK7G9MkktIrCD+VTkTCj37snNS+NfQ2NLD1aivW/A=; b=Skd8icHcuXTVeXDr6X9aGyMtdXj3boRBL9r8kPr76K80TxP5UTLLxWDZSsqzUfpBb1 vtyjzHFcicO6ziCEdxSX0aOTWtw0BIr3tOTkbR0MBzTOFA66qs9uuqJFguN4AYPzliyY +FARWMpjSxYO67o2qM1qGJRny8gjtSG/SFmUEII0XCe/imMeTUzwY+sE7mXY+iX5LkdC cgHpi8KDfVQNuXML3+vbQYRlROtKxXVhZyJd5qzIziafbIP5I7JtnV+Q93PeEOHn4Ygj c1JHOjRdsrjdxBi/H+Gv7uHWFSjbQvgZTj3q8kqjU6q2kNRybBr3lCA6SExHwEsy7QKq T+rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788443307; x=1789048107; h=content-transfer-encoding:content-type: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:content-type; bh=IpiK7G9MkktIrCD+VTkTCj37snNS+NfQ2NLD1aivW/A=; b=jogE7yEG8suaAuR5YUw8VD/OWqi/HFK207rWs40KXL9Zhkmniw1pYQBDMid8OSF1am QWD5ENMH2qVKtTIso78udNd7J4M4NCBVoindSIk9bMGA9o9nU7+los1cZq7OUry/Yj6U 4WWHYHXHi9wyHBvqycYQESHQzQkOQainqyMDGdcuBM8KxWdCWx2AUgqj2VuS94wpwC3N P8TEN2Svjqe0KXjalwPb2esGWMxBKbn6edvHCJW2j3rwcTY0VjZC6ejhP6pUzS7jXdrD dSaD0J1nwZfCAZskNQ/3hegipKCGMB5ccanaozeqBY1cGSZxfg5uF+l8VS/v2p0RptDU 5MTg== X-Forwarded-Encrypted: i=1; AKwUvBzXGLOdeoPwlPIlE1XCx98LcwrHDyy2QWVcxw0enbVTgj0OZiV6OKyFIAa2Y2bCpniELJwYELKshKc=@lists.xenproject.org X-Gm-Message-State: AFuF++mqoxI98bTwUokAxCNIXA7iSTds7ojVkx7s23i1I2qVTdn/VHlg Zf23lWClBLdS6cGFIKIoqLG/K1giJvm/tc4uOQ9cXyM7EsV0jV8v3ydrw/vVpgBUYg== X-Gm-Gg: AYBFou1Zm7t4Q/GPrOO4I7WTU/9JY6sRDJdjqTFM8GXoJX23pP3ZeZjUIIllZl/+2/5 pz9eMexbkzvFq5nXUZH4GdrkSOm/jrjB+7r87N2xSy5x2AmDBNeOXkjlU0r89/glm6QODMCyATm rlkEsMfTsscB/pr9flHMdfkmjAcVwV4ffFWEywLPHq9hSRQUQt5xYpla7lfFViMYkvj5+c3JJzp mr8u4ePv+Rf0NmJ8ztyn7V4mMtiffh30NdnTNh8JSLG5TJj9Pxf5yA/s31LOYpCT+0+ZdJzxFMN BSsf4IdbDT3cGM9hX7GoYLQBZ89h0b25XGUzbylzZVcEP/QCmyWH4zVsn1wMS+IebbyeuzmIoqy wnDD+DBRwxY1xFgNa+wV+ROwlDG9e3FScKIL/Qt3OOo+jhn4h0MkG+I5/UARiZgK1znk4b6fteT PDttuaUvL9OMRfMyCMj7QrWPja+X9o0W9u14A9rrtQwLZe89fneZ4ErTfa6Ce8XLDpo6espmgLg MROFgD21u1ps9axOzxtWz+EkxgTwcHUi0wKcSiG/SJwb1BE1AuB X-Received: by 2002:a5d:64c4:0:b0:485:7d6d:e0e0 with SMTP id ffacd0b85a97d-48582315f07mr4466480f8f.3.1788443307581; Thu, 03 Sep 2026 06:48:27 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 15:48:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/svm: Intercept CR0 writes selectively To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828141955.4009939-1-ross.lagerwall@citrix.com> <514b9ad4-912c-45fa-9450-3c85adaef483@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 X-purgate-ID: tlsNG-bad1c0/1788443308-3A6DA034-18FBB66A/0/0 X-purgate-type: clean X-purgate-size: 1619 On 03.09.2026 15:35, Ross Lagerwall wrote: > On 9/3/26 2:02 PM, Jan Beulich wrote: >> On 28.08.2026 16:19, Ross Lagerwall wrote: >>> Xen does not need to track when the TS or MP bits change so opt to >>> intercept CR0 writes selectively. >> >> Not anymore, which may want expressing here (or else it looks as if this >> would have been possible from the start). >> >>> Aside from potentially reducing a few >>> VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE >>> and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so >>> L1 never sees any CR0 writes. >> >> Yet if L1 sets CR0_WRITE, since intercept masks are ORed together (if >> I'm not mistaken), ... >> >>> @@ -2882,7 +2884,8 @@ void asmlinkage svm_vmexit_handler(void) >>> break; >>> >>> case VMEXIT_CR0_READ ... VMEXIT_CR15_READ: >>> - case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE: >>> + case VMEXIT_CR1_WRITE ... VMEXIT_CR15_WRITE: >>> + case VMEXIT_CR0_SEL_WRITE: >>> if ( cpu_has_svm_decode && vmcb->ei.mov_cr.mov_insn ) >>> svm_vmexit_do_cr_access(vmcb, regs); >>> else if ( !hvm_emulate_one_insn(x86_insn_is_cr_access, "CR access") ) >> >> ... we may still see VMEXIT_CR0_WRITE here (i.e. its handling cannot be >> removed). > > No, it shouldn't get here in that case. If L1 sets CR0_WRITE, it will enter > nestedsvm_check_intercepts() and then hit the NESTEDHVM_VMEXIT_INJECT case. Hmm, okay. Yet then I still think the original case label shouldn't be removed, as we don't exclude the CR2 or CR8 cases either. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 13:55:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 13:55:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407213.1640300 (Exim 4.92) (envelope-from ) id 1x27uZ-00009i-9M; Thu, 03 Sep 2026 13:55:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407213.1640300; Thu, 03 Sep 2026 13:55:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27uZ-00009b-5v; Thu, 03 Sep 2026 13:55:27 +0000 Received: by outflank-mailman (input) for mailman id 1407213; Thu, 03 Sep 2026 13:55:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27uX-00009V-EN for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:55:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x27uV-00Agpq-RN for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:55:23 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a997c3f-bab6-0a2a0a5309dd-0a2a4503b43e-34 for ; Thu, 03 Sep 2026 15:55:23 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a997c4b-fae8-0a2a45030019-d1558034c123-3 for ; Thu, 03 Sep 2026 15:55:23 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49b8687630fso20600765e9.3 for ; Thu, 03 Sep 2026 06:55:23 -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-49cee5d1fa6sm79987925e9.1.2026.09.03.06.55.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 06:55:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788443723; x=1789048523; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=pHW9BugFvNnKKVSOEAljgyt4yTwgoN/IIrw7Q1qpSF0=; b=MFshK0jswR0ZA5Stup3ovBFnlijlSp6ySs1ROylp6/ICFOdTdCnqEFPjNaqvDHPXqS gEQnbntPhgiFmbeBMDYrmvjbxR9r1Znwan9hMsMyM357TVNNF6cnqx55U+XrAkPuUQRi /rNh5KpnYbCClJD9vApYW6E2+LlqTQlAU5cQiHrSqBrO8NYCaUfZvae/psnYnykTQIPG b/+IX7qriuMJP0J9euOmM0wfJEl2JZ6F4LhFrQ9JQFBH0CsNl2HCv0aAgCtIm6YjuDHM 1o0V+0Hb0TgyrYBqU+UlQWGiJHsahaYxwbZS/rZ0PJaqdVOdxJsAOpGQ7iPPsmf2Q8KW pbDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788443723; x=1789048523; h=content-transfer-encoding:content-type: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:content-type; bh=pHW9BugFvNnKKVSOEAljgyt4yTwgoN/IIrw7Q1qpSF0=; b=rtdRlRdBc2hZXqXfkUXsQJv68g3vXUbgAp0+OdfHSr/AuJo8zgl99ZV+lvIzhKNSYL yTwsEraryeZvCphVqolcHtyqMZrHACpA0+I+G/m9OYweHUqWjjdEc0WNNKTgzEMjBDzu cjuUYKDeETWucsKpph8EaiOKUkSI9g8vtMdFFIlKcITpiLyZti0SpVawP334KN71ZLbx 1snIRcwwnK/NQYq9nQ5ZXeP4+MZ3ZpQDtduXUQZdQk3XhLMkLs375/SJ1Ar49uPeQvsF ErweKVJRloTamM0YVSSg5GAVamwN1HkpSnEDwI2iBs85ojPBXKHGekzwZz2s5TVak9fw FhRA== X-Forwarded-Encrypted: i=1; AKwUvBxhEsTdneVZYZlTTVXyB5kd30r0ijs8M/01vqrMEbnUFYhTty1NZXEcc8/u/85nIX5r9EJlO2xYc+U=@lists.xenproject.org X-Gm-Message-State: AFuF++n1ZN34x2PUjlmnt8EGArHjohrNhnebc1AUOfq/lIkizDrsjPJX wc7smViqKRg0ETPGh0NqX9VNZ0Fk08p5lUTee3fSXsccgwzT2K/t3YCrIq+rMpIp8g== X-Gm-Gg: AYBFou0joWXQV8ft8pXdy/o447rqJXts92hWJbdD6wnU5qHx7eqju9FT9pGQNpUX+Yb wqEcWPlRZxVVcYslv7/PU34xVOH6NkSdAMuNyatxNpoHFrarfC+U4L1HYMIOctPrEOTlAHVPOSD dTso2mCMye3AYGeMJOjV8tP29IE67M3VG89lmkVKyJr2IksloSo3m8t8e5hiT5g8PEtuCZ1v3s7 nip4KhTjnCaBQsLXZObtdJeo2kzhyhpilERfbql7c+LPPtfEGtolI4J3RJi5zv29sfuWKus1m5k nKKHZ8qwZth6nCtZGgXOnnEagji+6zWwK+tc1jJDMRkXt8bMFMwY8Cub8Fcu1M04CKyHUGLiZ8g Y7TSgSe9ehOsrtUSKonehr4zMeZGdAKacaRgZyYeyuyNwqp0bsk1jzLFDvdzv1DD/EJ5c6BfVZu fpsFRABR1ynOKNR3Wo+Prq19H5s9g6pH9hTdvP5xbP+ejg476ADbl75IbNSLpsAMv8hkeZHhkkX V8gMeEU6NMHuT1wN8p5mukLWcqrKb9lD7q4UQ== X-Received: by 2002:a05:600c:310e:b0:49c:e3ad:41d3 with SMTP id 5b1f17b1804b1-49ce55906cfmr188451565e9.0.1788443722861; Thu, 03 Sep 2026 06:55:22 -0700 (PDT) Message-ID: <8860838a-464a-438f-be40-86dde6908c91@suse.com> Date: Thu, 3 Sep 2026 15:55:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] sched/core: avoid use of "current" in initializer lists To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Nicola Vetrini , Dario Faggioli , George Dunlap , "xen-devel@lists.xenproject.org" References: <4eaf8244-25ec-45d4-844d-3d8f6720f57b@suse.com> <873b8735-e425-4f4f-bfb3-851a6c52f9f1@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: <873b8735-e425-4f4f-bfb3-851a6c52f9f1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788443723-77CC34E9-F40B5697/0/0 X-purgate-type: clean X-purgate-size: 2238 On 03.09.2026 15:26, Jürgen Groß wrote: > On 03.09.26 13:53, Jan Beulich wrote: >> @@ -1914,6 +1914,8 @@ typedef long ret_t; >> >> ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) >> { >> + const struct vcpu *curr = current; >> + struct domain *currd = curr->domain; >> ret_t ret = 0; >> >> switch ( cmd ) >> @@ -1938,9 +1940,9 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN >> if ( copy_from_guest(&sched_shutdown, arg, 1) ) >> break; >> >> - TRACE_TIME(TRC_SCHED_SHUTDOWN, current->domain->domain_id, >> - current->vcpu_id, sched_shutdown.reason); >> - ret = domain_shutdown(current->domain, (u8)sched_shutdown.reason); >> + TRACE_TIME(TRC_SCHED_SHUTDOWN, currd->domain_id, curr->vcpu_id, >> + sched_shutdown.reason); >> + ret = domain_shutdown(currd, sched_shutdown.reason); >> >> break; >> } >> @@ -1948,19 +1950,18 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN >> case SCHEDOP_shutdown_code: >> { >> struct sched_shutdown sched_shutdown; >> - struct domain *d = current->domain; >> >> ret = -EFAULT; >> if ( copy_from_guest(&sched_shutdown, arg, 1) ) >> break; >> >> - TRACE_TIME(TRC_SCHED_SHUTDOWN_CODE, d->domain_id, current->vcpu_id, >> + TRACE_TIME(TRC_SCHED_SHUTDOWN_CODE, currd->domain_id, curr->vcpu_id, >> sched_shutdown.reason); >> >> - spin_lock(&d->shutdown_lock); >> - if ( d->shutdown_code == SHUTDOWN_CODE_INVALID ) >> - d->shutdown_code = (u8)sched_shutdown.reason; >> - spin_unlock(&d->shutdown_lock); >> + spin_lock(&currd->shutdown_lock); >> + if ( currd->shutdown_code == SHUTDOWN_CODE_INVALID ) >> + currd->shutdown_code = (uint8_t)sched_shutdown.reason; >> + spin_unlock(&currd->shutdown_lock); >> >> ret = 0; >> break; > > What about the use of current in SCHEDOP_watchdog and SCHEDOP_pin_override > handling? I can change those too if that's wanted, also the one in SCHEDOP_remote_shutdown handling then. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 13:57:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 13:57:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407220.1640309 (Exim 4.92) (envelope-from ) id 1x27wt-0000r2-LU; Thu, 03 Sep 2026 13:57:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407220.1640309; Thu, 03 Sep 2026 13:57:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27wt-0000qv-Hk; Thu, 03 Sep 2026 13:57:51 +0000 Received: by outflank-mailman (input) for mailman id 1407220; Thu, 03 Sep 2026 13:57:49 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x27wr-0000qo-Oz for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 13:57:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x27wr-007hNK-5s for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:57:49 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a997cd8-8faa-0a2a0a5109dd-0a2a450bcaba-16 for ; Thu, 03 Sep 2026 15:57:49 +0200 Received: from [209.85.208.54] (helo=mail-ed1-f54.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a997cdd-b7e8-0a2a450b0019-d155d036ec1a-3 for ; Thu, 03 Sep 2026 15:57:49 +0200 Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-69fab5a852cso3819345a12.0 for ; Thu, 03 Sep 2026 06:57:49 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a67f8becc5sm2525840a12.12.2026.09.03.06.57.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 06:57:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788443869; x=1789048669; darn=lists.xenproject.org; h=content-type: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:content-type; bh=8XdoND+SGbUOjjzkIc0os+FYw+5/1OImD36eeBD+emE=; b=MIom76zKW5wmpe9S17elF1oHveSTedwC70JcrwUG3bFIOdLa7dI9wJVrh+2usxwH3d i3pXBvtuVCR1TTFGJDFuR5bUy8U92c5dCEMeR+UZDNJz7qqv7MS+bSYmCye711jOj0LE YsoIYYONvNPDTIz+j2cgV34nPm8ukChvUoBUBhQG7OE3ziyfV/LWefhkKd/U9Ca7Fb7U Gb4429+FsUQLJQj0slFgx0L9BtFi8CiAxqzLftb2vSQmyyMIvyBvcJD7A7V/d//SHdAu splCOSijiSHv5M6gzddzUEah0gIqirKb63C1OHrpm+urMEQAM+r+KolWktsNEXrY9o9Z irRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788443869; x=1789048669; h=content-type: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 :content-type; bh=8XdoND+SGbUOjjzkIc0os+FYw+5/1OImD36eeBD+emE=; b=FvvQhvzwPFprbCb9woogRIzM4dWrcmT/q+DaMSx+T9/z5sjPQ/on20kymE/v5KpLVg WwqUdr5v7XTlo/VoOYYHXVfDvTImVdyNN8u4mSgN3B4/H4RClU3HliqhU/hEGcsMaiKz GfywyB8JaYIkCwcjpl83NlBnEOlxclHSpxe387XXLL8OV1YXC50daFdCwTFQVEjwzSvG T417HsEwwGt9A/PAGXbQBLkXz/F6ILXw8AHE0ukMiJrpLxopiWyauvd1ud0z/qJHCrZu 31GleKpnV9DKh0VMx/lDE+yjsTe9kBAdkGw92VLQOkMsXa0lYOaG7zEekrZQN+6JAEE6 /wNA== X-Forwarded-Encrypted: i=1; AKwUvBzi7MQmmIHi2P0/VAPHXSnEwG1PxAy23pVnWo26Evdjk+fceDFxT+HFI7ZyAjo498aAm/jfmrBJmUI=@lists.xenproject.org X-Gm-Message-State: AFuF++lr0SBcwCQWpqVgaRkSpuVfF15FKMCYyMOvxhLe06tbk7kMPkag fxw6XVPeceFPR786tMPx7hSzgqUmTg5ujl+1/96oMLrY57ENNs3YtvDgFE030x3YauQ= X-Gm-Gg: AYBFou0etF0u0wXVyRh1tZ+rPweJqZ/eIJKyRIBEb6Y6jYRNgt3HRfvn2kumjpjuSt7 XaOQ5zt82FMTnvVwJvcN8W0Y6dM1DTowGCNW/beOhDv7flbGT7KL+t3C5xzyHdMMeADrjS/cZxX l2cGx5KCDmta91279C2+J/NWWM1Ht+3a6eZFcFIZrV4G74Cx8/k17lVplqlV0E69licxO7P8Je7 GZi8baFl7bSVNlaSUrIRK19Jqf4vJpwJjzc03SYqM5sDpfmv30A5HcQHg83LD8eWShfJP5c8Ixj kv0tRbOfZ37MEmWIB5ZlozncH7OZ8QpR5h3sakjthA6FDNFOgyVHrNsRvjzEFOY0Ui9LUkv1iIB +hBHjREGESlKwVdSHQd4NMwaQzs6uAwRiqeQcK2qARwJoz9u6gUH2Ovdb7QZIp3M8U4/3ee39It 9+JmW1yT2ipJW8b5ME2FKB19/zsDM0oASDY3fsypJn3F7XVF2P4SmUX/1jplK8XgtXcqj+Q22Gw TRehXWq0i1p3hHBdp9jRgAE0JH5ItDSHvQUIKeMp++Ic8+Td5/srrTHMYwM2tT1yl3WRe9Oy/BQ +0cQqFJlQhRTZw== X-Received: by 2002:a05:6402:3218:b0:6a1:2400:baea with SMTP id 4fb4d7f45d1cf-6a6829af69bmr9690773a12.10.1788443868423; Thu, 03 Sep 2026 06:57:48 -0700 (PDT) Message-ID: <0faf5aa7-5e4e-4b50-b1d7-1d27896c2b2b@suse.com> Date: Thu, 3 Sep 2026 15:57:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] sched/core: avoid use of "current" in initializer lists To: Jan Beulich Cc: Nicola Vetrini , Dario Faggioli , George Dunlap , "xen-devel@lists.xenproject.org" References: <4eaf8244-25ec-45d4-844d-3d8f6720f57b@suse.com> <873b8735-e425-4f4f-bfb3-851a6c52f9f1@suse.com> <8860838a-464a-438f-be40-86dde6908c91@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <8860838a-464a-438f-be40-86dde6908c91@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------wx3AHn0WTa5qsqnkrXSKebzo" X-purgate-ID: tlsNG-42698a/1788443869-A94C39EA-79AA97B3/0/0 X-purgate-type: clean X-purgate-size: 11026 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------wx3AHn0WTa5qsqnkrXSKebzo Content-Type: multipart/mixed; boundary="------------LrI1AHfmQ0lAH0MryBvkKpAg"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich Cc: Nicola Vetrini , Dario Faggioli , George Dunlap , "xen-devel@lists.xenproject.org" Message-ID: <0faf5aa7-5e4e-4b50-b1d7-1d27896c2b2b@suse.com> Subject: Re: [PATCH 3/4] sched/core: avoid use of "current" in initializer lists References: <4eaf8244-25ec-45d4-844d-3d8f6720f57b@suse.com> <873b8735-e425-4f4f-bfb3-851a6c52f9f1@suse.com> <8860838a-464a-438f-be40-86dde6908c91@suse.com> In-Reply-To: <8860838a-464a-438f-be40-86dde6908c91@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------LrI1AHfmQ0lAH0MryBvkKpAg Content-Type: multipart/mixed; boundary="------------BkzxtpuMdZ3x5ZK0y55pNylE" --------------BkzxtpuMdZ3x5ZK0y55pNylE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDMuMDkuMjYgMTU6NTUsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwMy4wOS4yMDI2 IDE1OjI2LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMDMuMDkuMjYgMTM6NTMsIEph biBCZXVsaWNoIHdyb3RlOg0KPj4+IEBAIC0xOTE0LDYgKzE5MTQsOCBAQCB0eXBlZGVmIGxv bmcgcmV0X3Q7DQo+Pj4gICAgDQo+Pj4gICAgcmV0X3QgZG9fc2NoZWRfb3AoaW50IGNtZCwg WEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh2b2lkKSBhcmcpDQo+Pj4gICAgew0KPj4+ICsgICAg Y29uc3Qgc3RydWN0IHZjcHUgKmN1cnIgPSBjdXJyZW50Ow0KPj4+ICsgICAgc3RydWN0IGRv bWFpbiAqY3VycmQgPSBjdXJyLT5kb21haW47DQo+Pj4gICAgICAgIHJldF90IHJldCA9IDA7 DQo+Pj4gICAgDQo+Pj4gICAgICAgIHN3aXRjaCAoIGNtZCApDQo+Pj4gQEAgLTE5MzgsOSAr MTk0MCw5IEBAIHJldF90IGRvX3NjaGVkX29wKGludCBjbWQsIFhFTl9HVUVTVF9IQU4NCj4+ PiAgICAgICAgICAgIGlmICggY29weV9mcm9tX2d1ZXN0KCZzY2hlZF9zaHV0ZG93biwgYXJn LCAxKSApDQo+Pj4gICAgICAgICAgICAgICAgYnJlYWs7DQo+Pj4gICAgDQo+Pj4gLSAgICAg ICAgVFJBQ0VfVElNRShUUkNfU0NIRURfU0hVVERPV04sIGN1cnJlbnQtPmRvbWFpbi0+ZG9t YWluX2lkLA0KPj4+IC0gICAgICAgICAgICAgICAgICAgY3VycmVudC0+dmNwdV9pZCwgc2No ZWRfc2h1dGRvd24ucmVhc29uKTsNCj4+PiAtICAgICAgICByZXQgPSBkb21haW5fc2h1dGRv d24oY3VycmVudC0+ZG9tYWluLCAodTgpc2NoZWRfc2h1dGRvd24ucmVhc29uKTsNCj4+PiAr ICAgICAgICBUUkFDRV9USU1FKFRSQ19TQ0hFRF9TSFVURE9XTiwgY3VycmQtPmRvbWFpbl9p ZCwgY3Vyci0+dmNwdV9pZCwNCj4+PiArICAgICAgICAgICAgICAgICAgIHNjaGVkX3NodXRk b3duLnJlYXNvbik7DQo+Pj4gKyAgICAgICAgcmV0ID0gZG9tYWluX3NodXRkb3duKGN1cnJk LCBzY2hlZF9zaHV0ZG93bi5yZWFzb24pOw0KPj4+ICAgIA0KPj4+ICAgICAgICAgICAgYnJl YWs7DQo+Pj4gICAgICAgIH0NCj4+PiBAQCAtMTk0OCwxOSArMTk1MCwxOCBAQCByZXRfdCBk b19zY2hlZF9vcChpbnQgY21kLCBYRU5fR1VFU1RfSEFODQo+Pj4gICAgICAgIGNhc2UgU0NI RURPUF9zaHV0ZG93bl9jb2RlOg0KPj4+ICAgICAgICB7DQo+Pj4gICAgICAgICAgICBzdHJ1 Y3Qgc2NoZWRfc2h1dGRvd24gc2NoZWRfc2h1dGRvd247DQo+Pj4gLSAgICAgICAgc3RydWN0 IGRvbWFpbiAqZCA9IGN1cnJlbnQtPmRvbWFpbjsNCj4+PiAgICANCj4+PiAgICAgICAgICAg IHJldCA9IC1FRkFVTFQ7DQo+Pj4gICAgICAgICAgICBpZiAoIGNvcHlfZnJvbV9ndWVzdCgm c2NoZWRfc2h1dGRvd24sIGFyZywgMSkgKQ0KPj4+ICAgICAgICAgICAgICAgIGJyZWFrOw0K Pj4+ICAgIA0KPj4+IC0gICAgICAgIFRSQUNFX1RJTUUoVFJDX1NDSEVEX1NIVVRET1dOX0NP REUsIGQtPmRvbWFpbl9pZCwgY3VycmVudC0+dmNwdV9pZCwNCj4+PiArICAgICAgICBUUkFD RV9USU1FKFRSQ19TQ0hFRF9TSFVURE9XTl9DT0RFLCBjdXJyZC0+ZG9tYWluX2lkLCBjdXJy LT52Y3B1X2lkLA0KPj4+ICAgICAgICAgICAgICAgICAgICAgICBzY2hlZF9zaHV0ZG93bi5y ZWFzb24pOw0KPj4+ICAgIA0KPj4+IC0gICAgICAgIHNwaW5fbG9jaygmZC0+c2h1dGRvd25f bG9jayk7DQo+Pj4gLSAgICAgICAgaWYgKCBkLT5zaHV0ZG93bl9jb2RlID09IFNIVVRET1dO X0NPREVfSU5WQUxJRCApDQo+Pj4gLSAgICAgICAgICAgIGQtPnNodXRkb3duX2NvZGUgPSAo dTgpc2NoZWRfc2h1dGRvd24ucmVhc29uOw0KPj4+IC0gICAgICAgIHNwaW5fdW5sb2NrKCZk LT5zaHV0ZG93bl9sb2NrKTsNCj4+PiArICAgICAgICBzcGluX2xvY2soJmN1cnJkLT5zaHV0 ZG93bl9sb2NrKTsNCj4+PiArICAgICAgICBpZiAoIGN1cnJkLT5zaHV0ZG93bl9jb2RlID09 IFNIVVRET1dOX0NPREVfSU5WQUxJRCApDQo+Pj4gKyAgICAgICAgICAgIGN1cnJkLT5zaHV0 ZG93bl9jb2RlID0gKHVpbnQ4X3Qpc2NoZWRfc2h1dGRvd24ucmVhc29uOw0KPj4+ICsgICAg ICAgIHNwaW5fdW5sb2NrKCZjdXJyZC0+c2h1dGRvd25fbG9jayk7DQo+Pj4gICAgDQo+Pj4g ICAgICAgICAgICByZXQgPSAwOw0KPj4+ICAgICAgICAgICAgYnJlYWs7DQo+Pg0KPj4gV2hh dCBhYm91dCB0aGUgdXNlIG9mIGN1cnJlbnQgaW4gU0NIRURPUF93YXRjaGRvZyBhbmQgU0NI RURPUF9waW5fb3ZlcnJpZGUNCj4+IGhhbmRsaW5nPw0KPiANCj4gSSBjYW4gY2hhbmdlIHRo b3NlIHRvbyBpZiB0aGF0J3Mgd2FudGVkLCBhbHNvIHRoZSBvbmUgaW4gU0NIRURPUF9yZW1v dGVfc2h1dGRvd24NCj4gaGFuZGxpbmcgdGhlbi4NCg0KSSdkIHByZWZlciB0aGF0Lg0KDQoN Ckp1ZXJnZW4NCg== --------------BkzxtpuMdZ3x5ZK0y55pNylE Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------BkzxtpuMdZ3x5ZK0y55pNylE-- --------------LrI1AHfmQ0lAH0MryBvkKpAg-- --------------wx3AHn0WTa5qsqnkrXSKebzo Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqZfNsFAwAAAAAACgkQsN6d1ii/Ey+/ mQgAnhcgT5AdGD2K+ZlJFzGHzRZyyeQJ1B+JbBPp2eXjbZw07a+rN3jaGY/EtsyNfEkdzoc+zdgU HFHORNUc7LXbyoIWYl6bEkG4xJUWABTceFtOrt7BkKL6EtPEMs7J/3e6u7Ww4NSDtvqh9YHtIOjl QEoDnwzWnDEFHpToV4LQ4vdY4tKYacC7ZL/HGLAJ5Pznk8yyY4TjaeaqJ6BHy79rkOKQEIIdMv+p 6ECMfcoWnPzgC6NhA3dE0vl1OSPsXJ+rnn9gq/sFuW2MgspMVZyoc8BTf86SOwbFkG1xdp+xsTPE tTOdi68Jm32Zve+lBlKGolyBx0MOrfFl+fM0/oJlEA== =K1d8 -----END PGP SIGNATURE----- --------------wx3AHn0WTa5qsqnkrXSKebzo-- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:07:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:07:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407241.1640318 (Exim 4.92) (envelope-from ) id 1x286M-0002gI-KZ; Thu, 03 Sep 2026 14:07:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407241.1640318; Thu, 03 Sep 2026 14:07:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x286M-0002gB-HW; Thu, 03 Sep 2026 14:07:38 +0000 Received: by outflank-mailman (input) for mailman id 1407241; Thu, 03 Sep 2026 14:07:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x286L-0002g5-TQ for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:07:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x286L-00DG2V-62 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:07:37 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a997f22-bab6-0a2a0a5309dd-0a2a45078df8-22 for ; Thu, 03 Sep 2026 16:07:37 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a997f28-b4ea-0a2a45070019-d1558036e0ca-3 for ; Thu, 03 Sep 2026 16:07:37 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49b8e527d63so28021425e9.2 for ; Thu, 03 Sep 2026 07:07:37 -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-49cee60d9c6sm75787505e9.11.2026.09.03.07.07.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 07:07:34 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788444456; x=1789049256; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=0YmDbX/3sWw3eSQ2aEyIQQaWSLPoFgJEsBjsN3OV+4o=; b=NPM24fnx7xDOnZcSSscuUvdFnnaFymSrWzFCZqMKECcAw4qxvF4Ko19NygWpo5GTtJ IKTa+k2ySgCq3BGs0kW+dITAoDeKOXrhe050W1w0xyxeaabFytA58nxviK2mnKkBTqX1 XZWhVwMpL83QhnbYVTbCAVszW8b4wUyAwoqMukUbsSzPWqAWis5D5tnq7/G+oh3sl6yb o+sfKQNVxYwYKlJ+rUUqHMkpytB98s/Q+v/rWPtpKkAgdAUIKORXs3vm+x8CW5Mh++9P lnajmDX4XCIuD6Fos3YtneVmsarwk3wiO504AiPn27QJ4mRtTZIvFTtoJVSVOWlSg3Ey ZLtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788444456; x=1789049256; h=content-transfer-encoding:content-type: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:content-type; bh=0YmDbX/3sWw3eSQ2aEyIQQaWSLPoFgJEsBjsN3OV+4o=; b=if5WCeDxD35i4FkgDKPDdBl4C7nVAO8gVGdUWtw3QgL9cJSInLlWTRBhiGPY4XxYQ0 jb3j/QDkvpJyPAdGUkJDihMzxCm7P207z5kpWV+CWamFCTXR1WvER8aP1nMCzC9PBeT5 RO2IRf8DHxaWdP2223MsBUPKBkjg1qOIxhYG2wrgJZJofGhvaNsL1cdEDXKocdmJu065 3wwVqBZG7RxJWxb9fedk2XDv5PvkmPhww1PhhyMYWhK9dGzPBZsVqErChsIhVEb7r5IP bQzGDOqLhZqy3Xsg5D6s17iJo+WTwuuxtR9ZHxTBziWOr9POBEPGYtlWpNis56eu2AYz lJEg== X-Forwarded-Encrypted: i=1; AKwUvByx7cl4ucVG222TKrZxNKmdXT/P4v6IkWlFbJmwBWfsGPWvYvn7EqIBVe0v2NpObaYnx6MqngyXtA8=@lists.xenproject.org X-Gm-Message-State: AFuF++nwNKgl/zPs6TquSxxxwiF8Qio5gbq6lYxQa6muih1H6b4T/eZm yFV31weVnpwT7Z/3RVQ9Y7T1yOs4NPWc75wyAQLkks7ihg6UCn4kLZ/QN86ci8EsOQ== X-Gm-Gg: AYBFou1ChBHsv9T0oUaG3O8BVD2dCWXpKd/+uDvgKbfmUGxLH++dzEOs4hfIxxHUWtR qBz16NZ02Vgm4B0mcIv5d/MxGYPFfuEblqhziYvq4AAJHpkLFVB3CusWiVyXIpi8uUQRgf1rEUC nBx6KgxaeB9/9nLkymYIUBCv1YcKLk3ALH9Bq8uCbm1jtU8lp5yHzDfOtw1PbML/fNdnSTXey1v TL6U/qxCee8j67MKVrW9Pbtz93/np29Ze4qWHBlbR9+A2cjQWACro94Q++uEbmU7pausbI/IeJB 650qInKL/jGQYTeYa/MrXLWmpip8/nSTa/IzYDV+UIfKm2UNCLHgDEWua2EU+MNbm7tCLJTn0Ad oyh9uBp+xYqXC9EkBjTETf/voDTtoFVAUSnFfeItpCqnITrVxXQwAFe2fMA0ddCaZE9j2gyi61J DRxj6p4HmPfV59xaxcOA/Vp+uyU6a2yANV1SbrTDEXXROZll8dwN1Em37cLbFJh1croVFERF99K 8G4Kku9hbMa54OHjIKLbXT7v/7ZmKuRYjxAqA== X-Received: by 2002:a05:600c:34c5:b0:499:cd34:100d with SMTP id 5b1f17b1804b1-49cf5b7935cmr5702775e9.7.1788444455450; Thu, 03 Sep 2026 07:07:35 -0700 (PDT) Message-ID: <918e1522-3028-4d8c-9ba3-1c679b61861a@suse.com> Date: Thu, 3 Sep 2026 16:07:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/14] x86/domain_page: introduce IRQs-off variants of {,un}map_domain_page() To: George Dunlap Cc: George Dunlap , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-1-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-1-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788444457-A7CD7AE4-E181A958/0/0 X-purgate-type: clean X-purgate-size: 4894 On 02.09.2026 11:43, George Dunlap wrote: > From: George Dunlap > > Currently, map_domain_page() cannot be called in the context switch > path. However, Xen already needs to update the slot of an incoming PV > vcpu's GDT during context switch; and when we soon switch to per-vCPU > root pagetables, we'll have to modify two more places. > > Xen currently solves the problem by special-casing the GDT/LDT L1 > tables to be allocated from the xenheap, and stashing a pointer to its > address in the xenheap in the domain struct. Rather than add more Xen > pagetable pages to the xenheap, introduce a version of map_domain_page > which can be called from the context switch path. > > The reason map_domain_page() cannot be called from the context switch > path is x86's lazy context-switch state. Mapcache mappings are > created in the page-tables that are loaded on the pCPU. When Xen is > in a lazy context-switch state, current is the idle vCPU while the > previously-running vCPU's page-tables remain loaded. If in this > state, another pcpu wants access to the lazily-swapped-out vcpu's > state, it will send a FLUSH_VCPU_STATE IPI to the processor, which > will call sync_local_execstate(). > > sync_local_execstate() is implemented internally by calling a full > __context_switch(). In addition to copying the processor state into > the vcpu structure, this also switches the loaded pagetables to the > idle vcpu's, which would in turn cause mappings created before the IPI > to disappear mid-use. Therefore, mappings cannot be held in the > mapcache when a FLUSH_VCPU_STATE IPI may execute. To this end, > map_domain_page() calls sync_local_execstate() itself proactively when > it detects a lazy context-switch state. This guarantees that the > pagetables will remain consistent at least until the next context > switch. > > But of course, that synchronization must not be triggered from the > context switch path itself: sync_local_execstate() ends up in > __context_switch(), so a call made while a context switch is in > progress would recurse, and the assertions along that path (current > being the idle vCPU) don't hold there either. > > A full synchronization is sufficient to prevent a FLUSH_VCPU_STATE IPI > from switching the pagetables; however, it is not necessary. It > suffices to maintain interrupts disabled from before the page is > mapped until after it is unmapped. This condition is satisfied for > the mappings used on the context switch path. > > Introduce {,un}map_domain_page_irqoff() variants for callers which > guarantee that interrupts remain disabled from the map until the > matching unmap. Under that guarantee the synchronization is > unnecessary rather than merely inconvenient: no IPI can be delivered > while the mapping is in use, so the lazy state cannot change under the > caller's feet, and this_cpu(pgtable_vcpu) accurately identifies the > mapcache to use (see 622c9a5ba95d "x86/mm: accurately track which vCPU > page-tables are loaded"). The variants assert that interrupts are > disabled on entry; the rest of the contract remains the caller's > responsibility. > > This will be used by the next patch, which introduces a function which > will be used to modify the incoming vCPU's per-domain mappings from > within __context_switch(); it will also be used in future ASI > patches (tearing down and establishing per-CPU stack mappings during > context switch). > > No functional change for existing callers. > > Assisted-by: Claude Code:claude-fable-5 > Signed-off-by: George Dunlap Reviewed-by: Jan Beulich with one aspect for further consideration: > @@ -59,7 +68,7 @@ static inline struct vcpu *mapcache_current_vcpu(void) > #define MAPCACHE_L1ENT(idx) \ > __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + pfn_to_paddr(idx))] > > -void *map_domain_page(mfn_t mfn) > +static void *do_map_domain_page(mfn_t mfn, bool irqs_off) > { do_...() commonly (but sadly not consistently) mark top-level hypercall handlers. Personally I'd prefer if the "do" (but not the underscore) were dropped here and ... > @@ -165,7 +174,19 @@ void *map_domain_page(mfn_t mfn) > return (void *)MAPCACHE_VIRT_START + pfn_to_paddr(idx); > } > > -void unmap_domain_page(const void *ptr) > +void *map_domain_page(mfn_t mfn) > +{ > + return do_map_domain_page(mfn, false); > +} > + > +void *map_domain_page_irqoff(mfn_t mfn) > +{ > + ASSERT(!local_irq_is_enabled()); > + > + return do_map_domain_page(mfn, true); > +} > + > +static void do_unmap_domain_page(const void *ptr, bool irqs_off) ... here. Identifiers with a single leading underscore (and no following upper-case letter) are designated for use by static functions, after all. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:10:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:10:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407249.1640327 (Exim 4.92) (envelope-from ) id 1x288p-0004Pp-VU; Thu, 03 Sep 2026 14:10:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407249.1640327; Thu, 03 Sep 2026 14:10:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x288p-0004Pi-Sj; Thu, 03 Sep 2026 14:10:11 +0000 Received: by outflank-mailman (input) for mailman id 1407249; Thu, 03 Sep 2026 14:10:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x288p-0004O8-39 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:10:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x288o-001Fy7-Br for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:10:10 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a997fba-e002-0a2a0a5209dd-0a2a450ae676-36 for ; Thu, 03 Sep 2026 16:10:10 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a997fc1-f2d2-0a2a450a0019-b9ff1c22b52b-3 for ; Thu, 03 Sep 2026 16:10:10 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679afc0d000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:10:05 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 505C180F82; Thu, 3 Sep 2026 16:10:04 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=bs7jvPMFI3pd3P8FsMzJgn8tGXG26d0b6D7BLNmVifc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=WFsI+IzfECYBafEq3ZaAGAjoUUJsX/reMxNcYT2cwa0KMJYL2MH5Sz6HfbMjENQ/iNUYAxw3i IbTP6FQ0zRI5hNHGKYqYVuZsjibiVL/WL2XTxFtkpXP/dd4zRD2GngrwlSyFxmfKRRm90sqrwaK hvns3NSg9Pe1W8gxHA6prt8TXtv2EoIY1DTpko4ObBBI0B2NeNKdv4KdMxrLj833MtlV6lz9xiq 10Qwn8tsAXiWUnwT+y81zOVyzLgDg45MPWyJ4KARd/sv2QqNEVCOs42tWwZHXbtu/BXApi8x0IM ethdOHOpiFkLMECvW2GQGF5b8OrSx5yP96Xkz1Yav85w== X-Zone-Loop: a5141be8ea305617ea39ca29801c57f8cc586623a0c1 x-campaign-type: default x-transaction-id: a25a2874-d280-4151-8865-bb89925a7961 x-swg-uid: 01-e681f7da-1ed3-418c-82e4-b6ba181c8a56 X-Mailer: Sweego Message-ID: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> x-swg-bid: 1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 00/11] x86/hvm: Add Extended MSI destination ID support Date: Thu, 3 Sep 2026 16:09:59 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.359e.6926871dec21afe8.1a0679af91a.a27d7a411bf599d4=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444604699 X-purgate-ID: tlsNG-4011c0/1788444610-526DECFC-A4F0F090/0/0 X-purgate-type: clean X-purgate-size: 8308 ---=Part.359e.6926871dec21afe8.1a0679af91a.a27d7a411bf599d4=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Teddy and Jan for the detailed review on v4! Jan you're right, When recently asking I didn't understand the issue with only having a ENABLED/DISABLED for the ext_dest_id flag=2E Now it's clear why we need a tri-state, but also why a tri-state is sufficient=2E I have converted it to UNSET, DISABLED, or ENABLED=2E So, after a migration we know that if it's still UNSET the domain is unaware of the feature and we will not announce it no matter how many ioreq servers have opt'ed in on the new host=2E I have also split the parts that "just" move code around with no functional changes into smaller chunks so each of them is easier to diff: Patch 1 x86/vioapic: check of the IOAPIC save record=2E Path 2-6 Refactor pt_irq_create_bind(): brace the retry block, turn "goto restart" into a loop, extract pt_irq_dpci_setup(), extract the PT_IRQ_TYPE_MSI body into pt_irq_bind_msi() as just a code move, then re-indent=2E No functional change=2E Patch 7 Switch pt_irq_bind_msi() and struct hvm_gmsi_info to the raw MSI address/data words, add MSI_ADDR_DEST(), reject a stored address that is not in 0xfeexxxxx MSI format=2E domctl callers keep working via a gflags -> message rebuild=2E No functional change for existing 8-bit-destination guests=2E Patch 8 Add the tri-state d->arch=2Ehvm=2Eext_dest_id and fold the extend= ed bits into every call site, guarded by hvmext_dest_id_active()=2E Still never enabled, so still no functional change=2E Patch 9 Add XEN_DMOP_{,un}bind_pt_msi_irq (raw address/data) and remove PT_IRQ_TYPE_MSI from XEN_DOMCTL_{,un}bind_pt_irq=2E This is an incompatible hypercall-ABI change, recorded in CHANGELOG=2Emd and public/domctl=2Eh=2E Patch 10 Negotiate the feature per ioreq server (a flags byte on XEN_DMOP_create_ioreq_server), level it across all servers, latch it at arch_domain_creation_finished(), and migrate it in a new HVM_SAVE_TYPE(EXT_DEST_ID) record=2E Patch 11 Advertise XEN_HVM_CPUID_EXT_DEST_ID from the latched value=2E I only have two remaining questions: - As pointed out by Jan: The new DM ops now only relies on xsm_dm_op() for access control=2E Daniel Smith can you comment on, whether a xsm_bind_pt_irq hook is also wanted here? - In dm=2Ec we still use the read_lock(&d->pci_lock) around the bind/unbind calls, as was the case in v4=2E Jan you suspected no lock is needed there, but for now I left it as-is=2E Signed-off-by: Julian Vetter --- Changes in v5: - The domctl MSI path is no longer rejected (that broke older DMs and left dead code)=2E PT_IRQ_TYPE_MSI keeps working until patch 9 removes it alltogether, with the now-dead pt_irq_create_bind() case deleted in the same step=2E - pt_irq_bind_msi() rejects an address not in MSI format (0xfeexxxxx), so every caller storing into gmsi=2Eaddr is guaranteed a well-formed message=2E - The ext_dest_id "bool" state is now a tri-state (UNSET / DISABLED / ENABLED)=2E Every decode site folds in the extended bits only when the feature is active and treats them as reserved otherwise, rather than rejecting a guest that left values there=2E Removed the ioapic_check() extended-bit rejection loop=2E - The creation_finished latch only fires while the state is UNSET, so a migrated value wins=2E - hvm_load() resolves a record-less stream (from an "old" Xen) to DISABLED=2E - v4's single "extract pt_irq_bind_msi()" patch is split into - The goto -> loop conversion is its own patch (Patch 3) and does a "for ( ; ; )" instead of do/while - A code move (Patch 4) - A re-indent (Patches 5, 6) - Moved hvm_ext_dest_id_enabled() into common/ioreq=2Ec as a function that iterates over ARRAY_SIZE(d->ioreq_server=2Eserver)=2E Flag-bit validatio= n is now arch specific=2E The Arm stub rejects any non-zero flag=2E Added = a check handler for the EXT_DEST_ID save record=2E - Fixed a bug in _hvm_dpci_msi_eoi()=2E Function tested XEN_DOMCTL_VMSI_X86_DM_MASK against a raw address and not against MSI_ADDR_DESTMODE_MASK=2E - Added the missing libxendevicemodel=2Emap VERS_1=2E5 entry and Makefile MINOR bump=2E The new parameter for xendevicemodel_create_ioreq_server() is a compatibility break for DMs, now mentioned in CHANGELOG=2Emd=2E - ioapic_check() validates base_address alignment, hap_paddr_bits and bounds the APIC ID by the IO_APIC_reg_02 field and the ioregsel check is gone, since vioapic_write() has no such restriction=2E - Addressed general feedback from Jan: - machine_irq / gflags and the flags parameters are unsigned int - MSI_ADDR_DEST() derives its shift from a new MSI_ADDR_DEST_ID_WIDTH and leaves the existing MSI_ADDR_DEST_ID_* lines alone - Removed the "Intel convention" in a comment - MASK_EXTR / MASK_INSR used consistently - Removed redundant nr_pirqs check and "!!" - DM op debug print shortened to "%pd: fn() failed: %ld" - DM op struct fields are pirq / msg_addr / msg_data, the flag is XEN_DMOP_MSI_BIND_UNMASKED - gtable is documented as a guest-physical address - x86-specific wording is out of the public header - needless typedefs / blank line removed - The unbind op no longer requires current-domain IRQ permission=2E --- Julian Vetter (11): x86/vioapic: Add ioapic_check() to validate IO-APIC state before restore x86/passthrough: Wrap pt_irq_create_bind() restart block in braces x86/passthrough: Replace pt_irq_create_bind() goto restart with a loop x86/passthrough: Extract pt_irq_dpci_setup() from pt_irq_create_bind() x86/passthrough: Extract PT_IRQ_TYPE_MSI body into pt_irq_bind_msi() x86/passthrough: Re-indent pt_irq_bind_msi() body x86/passthrough: Switch pt_irq_bind_msi() to raw MSI address/data x86/hvm: Decode extended MSI / IO-APIC destination IDs when opted in x86/dmop: Add XEN_DMOP_{,un}bind_pt_msi_irq hvm/ioreq: Negotiate extended destination ID support per ioreq server x86/cpuid: Advertise XEN_HVM_CPUID_EXT_DEST_ID CHANGELOG=2Emd | 6 + tools/include/xendevicemodel=2Eh | 33 +- tools/libs/ctrl/xc_devicemodel_compat=2Ec | 2 +- tools/libs/ctrl/xc_domain=2Ec | 51 ++- tools/libs/devicemodel/Makefile | 2 +- tools/libs/devicemodel/core=2Ec | 41 ++- tools/libs/devicemodel/libxendevicemodel=2Emap | 6 + xen/arch/arm/ioreq=2Ec | 6 + xen/arch/x86/cpuid=2Ec | 8 + xen/arch/x86/domain=2Ec | 13 + xen/arch/x86/domctl=2Ec | 11 +- xen/arch/x86/hvm/dm=2Ec | 66 ++++ xen/arch/x86/hvm/ioreq=2Ec | 57 +++ xen/arch/x86/hvm/irq=2Ec | 6 +- xen/arch/x86/hvm/save=2Ec | 9 + xen/arch/x86/hvm/vioapic=2Ec | 49 ++- xen/arch/x86/hvm/vmsi=2Ec | 59 ++- xen/arch/x86/include/asm/hvm/domain=2Eh | 13 + xen/arch/x86/include/asm/hvm/hvm=2Eh | 12 +- xen/arch/x86/include/asm/hvm/irq=2Eh | 4 +- xen/arch/x86/include/asm/hvm/vioapic=2Eh | 10 + xen/arch/x86/include/asm/msi=2Eh | 19 + xen/common/ioreq=2Ec | 31 +- xen/drivers/passthrough/x86/hvm=2Ec | 366 +++++++++++-------- xen/include/public/arch-x86/hvm/save=2Eh | 20 +- xen/include/public/hvm/dm_op=2Eh | 51 ++- xen/include/xen/iommu=2Eh | 3 + xen/include/xen/ioreq=2Eh | 11 + xen/include/xlat=2Elst | 2 + 29 files changed, 723 insertions(+), 244 deletions(-) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.359e.6926871dec21afe8.1a0679af91a.a27d7a411bf599d4=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407255.1640336 (Exim 4.92) (envelope-from ) id 1x28Cr-0005EJ-E0; Thu, 03 Sep 2026 14:14:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407255.1640336; Thu, 03 Sep 2026 14:14:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28Cr-0005EC-BC; Thu, 03 Sep 2026 14:14:21 +0000 Received: by outflank-mailman (input) for mailman id 1407255; Thu, 03 Sep 2026 14:14:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28Cq-0005E6-8q for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28Cp-007l5G-Fy for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:19 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980bb-e002-0a2a0a5209dd-0a2a4502ed04-4 for ; Thu, 03 Sep 2026 16:14:19 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980bb-6ca4-0a2a45020019-b9ff1c22a33f-3 for ; Thu, 03 Sep 2026 16:14:19 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ecc95000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:15 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id CA78F83FF2; Thu, 3 Sep 2026 16:14:14 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=AZvC+bc7Rv16uKzN3ihkV/oSvkk6tH0QJHksWVaFqwg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=nfBm8a2r+v8k2jTuP+btTUtJmr6JGra3XeGqzxYuVwWGZB2qDAwJzL3223h7XTzshP64V71DW o/KpL5QyBcCEeKeZ53Y1/DCV6mc/HL3ss3f0tKYH4qgKBSp0LE4PPSs1+Or7SBt02bzmNJSB8mL 0hgGNv1h8DruoKtIphBWe5IvmOwoaEF6UVItCA3AvgOn6FmLYFm/ZkPi54xpJM7pIR8DNo+fup7 cdrUCtt9yrMFDR4kHj5ldBEQhrZHVpr1Hau8lEXiBHtX4tz+7LsxIhbJobmT8XP8CWUgSMMTsp3 OU5toNukl9813kaYIEUYZiJ1I55xqGuYgGb4gdGlKuWQ== X-Zone-Loop: c7255c66a8cde000f0d3f03de70656fe9edd765119b3 x-campaign-type: default x-transaction-id: 299ef29c-5d39-4dd9-8576-84dec8e8c7a6 x-swg-uid: 01-699fc82e-4a5d-4ca2-a927-a03bfb769b8d X-Mailer: Sweego Message-ID: <1788444855.8631fc262581453bbf619ec5b2062170.1a0679ecc95000c4f3@vates.tech> x-swg-bid: 1788444855.8631fc262581453bbf619ec5b2062170.1a0679ecc95000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 01/11] x86/vioapic: Add ioapic_check() to validate IO-APIC state before restore Date: Thu, 3 Sep 2026 16:13:59 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35a4.21631d333167ec9d.1a0679ecb06.d028971a7c8c5bc6=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444855046 X-purgate-ID: tlsNG-720697/1788444859-319CB2AC-9CC873AE/0/0 X-purgate-type: clean X-purgate-size: 4379 ---=Part.35a4.21631d333167ec9d.1a0679ecb06.d028971a7c8c5bc6=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Register a check callback for the IOAPIC HVM save/restore entry, following the pattern established by vpic_check() for the virtual PIC=2E The function first verifies the target domain actually has a virtual IO-APIC, returning -ENODEV otherwise=2E It then validates individual fields of the saved state: base_address must be non-zero, page-aligned, and leave room for the MMIO window below the domain's physical address limit=2E The APIC ID must fit the 4-bit field vioapic_write_indirect() stores and no redirection table entry may carry a delivery_status bit, which is read-only and always cleared on a guest write=2E Signed-off-by: Julian Vetter --- Changes in v5: - The check now verifies base_address is page-alignment and hap_paddr_bits and not just "!=3D 0"=2E - The APIC ID is bounded by the IO_APIC_reg_02 field and not a hard-coded 0xf (added comment)=2E - Replaced the ioregsel check with a loop rejecting any entry that has delivery_status set=2E - Commit message rewritten=2E Signed-off-by: Julian Vetter --- xen/arch/x86/hvm/vioapic=2Ec | 44 +++++++++++++++++++++++++++++++++++++- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vioapic=2Ec b/xen/arch/x86/hvm/vioapic=2Ec index 222e59e2c2=2E=2E80dc9148a9 100644 --- a/xen/arch/x86/hvm/vioapic=2Ec +++ b/xen/arch/x86/hvm/vioapic=2Ec @@ -323,6 +323,7 @@ static void vioapic_write_indirect( * Presumably because we emulate an Intel IOAPIC which only has a * 4 bit ID field (compared to 8 for AMD), using union IO_APIC_re= g_02 * for the ID register (union IO_APIC_reg_00's ID field is 8 bits= )=2E + * ioapic_check() validates the saved id field accordingly=2E */ vioapic->id =3D ((union IO_APIC_reg_02){ =2Eraw =3D val })=2Ebits= =2Earbitration; break; @@ -595,6 +596,47 @@ int vioapic_get_trigger_mode(const struct domain *d, = unsigned int gsi) return vioapic->redirtbl[pin]=2Efields=2Etrig_mode; } =20 +static int cf_check ioapic_check(const struct domain *d, hvm_domain_conte= xt_t *h) +{ + const HVM_SAVE_TYPE(IOAPIC) *s; + + if ( !has_vioapic(d) ) + return -ENODEV; + + s =3D hvm_get_entry(IOAPIC, h); + if ( !s ) + return -ENODATA; + + /* + * base_address must be non-zero, page-aligned (hardware constraint),= and + * within the guest's physical address space (with room for the full = MMIO + * window)=2E + */ + if ( !s->base_address || + !IS_ALIGNED(s->base_address, PAGE_SIZE) || + s->base_address > (1ULL << hap_paddr_bits) - VIOAPIC_MEM_LENGTH = ) + return -EINVAL; + + /* + * vioapic_write_indirect() stores only the 4-bit arbitration field o= f + * IO_APIC_reg_02 as the APIC ID=2E See that function's comment for w= hy + * IO_APIC_reg_02 is used rather than IO_APIC_reg_00=2E + */ + if ( s->id > ((union IO_APIC_reg_02){ =2Eraw =3D ~0U })=2Ebits=2Earbi= tration ) + return -EINVAL; + + /* + * Reject redirection table entries carrying bits that + * vioapic_write_redirent() would never store: delivery_status is rea= d-only + * and always cleared on a guest write=2E + */ + for ( unsigned int i =3D 0; i < ARRAY_SIZE(s->redirtbl); i++ ) + if ( s->redirtbl[i]=2Efields=2Edelivery_status ) + return -EINVAL; + + return 0; +} + static int cf_check ioapic_save(struct vcpu *v, hvm_domain_context_t *h) { const struct domain *d =3D v->domain; @@ -631,7 +673,7 @@ static int cf_check ioapic_load(struct domain *d, hvm_= domain_context_t *h) return 0; } =20 -HVM_REGISTER_SAVE_RESTORE(IOAPIC, ioapic_save, NULL, ioapic_load, 1, +HVM_REGISTER_SAVE_RESTORE(IOAPIC, ioapic_save, ioapic_check, ioapic_load,= 1, HVMSR_PER_DOM); =20 void vioapic_reset(struct domain *d) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35a4.21631d333167ec9d.1a0679ecb06.d028971a7c8c5bc6=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407256.1640345 (Exim 4.92) (envelope-from ) id 1x28Cx-0005Uo-QC; Thu, 03 Sep 2026 14:14:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407256.1640345; Thu, 03 Sep 2026 14:14:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28Cx-0005Uf-LY; Thu, 03 Sep 2026 14:14:27 +0000 Received: by outflank-mailman (input) for mailman id 1407256; Thu, 03 Sep 2026 14:14:25 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28Cv-0005Re-Qd for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28Cu-006VeY-UU for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:24 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980a0-bab6-0a2a0a5309dd-0a2a4506deb4-38 for ; Thu, 03 Sep 2026 16:14:24 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980c0-195a-0a2a45060019-b9ff1c238775-3 for ; Thu, 03 Sep 2026 16:14:24 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ed206000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:16 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 34BFC83FF2; Thu, 3 Sep 2026 16:14:16 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=r+KqnF8bmZ4P6mM47X2d2/6/TckhTEd5k85Fqf1f/Kw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=KIKtkYRM4wkHG3Sp+annclTs9TFxeAUHROUaO+uybfcMNAfpc99qNwhwrTIFo0eGh3TFtJ+ao M3nfpBHA/bOWAvPuvFAcwigagCwYaZtmaFGSA4eJ9IdwwxU5gHFmuEtQsUmamTMnSlKjankguOC 16u+7EAURaQh04TUGf42k9gCZ2TIsIeOFsXbbiF9Ny8J7t+tJT6QxunSElDASB97UztOZ1sIYd6 kEgWWDQ2jTOBTKDGsG4q/xfxucE26XFXNwQg8D2JweVcjQSxUX4I77a7Rb59UZB83bQXNzEI87y 9NH+/PgX1kAd9uqaAe8CWBPnBth5VIGvyP1At24342/w== X-Zone-Loop: ba365be1de0d39ba773c754a122acf6dbd1f56c3b1a4 x-campaign-type: default x-transaction-id: c242f644-79e9-4583-b5e2-1a90ae0c0f8d x-swg-uid: 01-0e9fb388-982f-4dd0-bc14-bc6d134075c2 X-Mailer: Sweego Message-ID: <1788444856.8631fc262581453bbf619ec5b2062170.1a0679ed206000c4f3@vates.tech> x-swg-bid: 1788444856.8631fc262581453bbf619ec5b2062170.1a0679ed206000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 02/11] x86/passthrough: Wrap pt_irq_create_bind() restart block in braces Date: Thu, 3 Sep 2026 16:14:00 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35a5.d06bb82c97bcd973.1a0679ed066.5d48df588f90c8dd=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444856422 X-purgate-ID: tlsNG-16d1c6/1788444864-FC40377B-BB071CD8/0/0 X-purgate-type: clean X-purgate-size: 4918 ---=Part.35a5.d06bb82c97bcd973.1a0679ed066.5d48df588f90c8dd=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Enclose the restart/retry block in pt_irq_create_bind() in an explicit compound statement to prepare for its extraction into a helper function ("x86/passthrough: Extract pt_irq_dpci_setup() from pt_irq_create_bind()")=2E Reflow the two comments inside the block that no longer fit in 80 columns at the increased indentation, and fix an unbalanced parenthesis in the second one=2E No functional change=2E Signed-off-by: Julian Vetter --- Changes in v5: - Fixed two comments to fit 80-columns (and fixed unbalanced-parenthesis in comment) - Commit message now names the follow-up patch correctly=2E Signed-off-by: Julian Vetter --- xen/drivers/passthrough/x86/hvm=2Ec | 81 ++++++++++++++++--------------- 1 file changed, 42 insertions(+), 39 deletions(-) diff --git a/xen/drivers/passthrough/x86/hvm=2Ec b/xen/drivers/passthrough= /x86/hvm=2Ec index b73bb55055=2E=2E1d5b1fb0f8 100644 --- a/xen/drivers/passthrough/x86/hvm=2Ec +++ b/xen/drivers/passthrough/x86/hvm=2Ec @@ -229,52 +229,55 @@ int pt_irq_create_bind( return -EINVAL; =20 restart: - write_lock(&d->event_lock); - - hvm_irq_dpci =3D domain_get_irq_dpci(d); - if ( !hvm_irq_dpci && !is_hardware_domain(d) ) { - unsigned int i; + write_lock(&d->event_lock); =20 - /* - * NB: the hardware domain doesn't use a hvm_irq_dpci struct beca= use - * it's only allowed to identity map GSIs, and so the data contai= ned in - * that struct (used to map guest GSIs into machine GSIs and perf= orm - * interrupt routing) is completely useless to it=2E - */ - hvm_irq_dpci =3D xzalloc(struct hvm_irq_dpci); - if ( hvm_irq_dpci =3D=3D NULL ) + hvm_irq_dpci =3D domain_get_irq_dpci(d); + if ( !hvm_irq_dpci && !is_hardware_domain(d) ) + { + unsigned int i; + + /* + * NB: the hardware domain doesn't use a hvm_irq_dpci struct + * because it's only allowed to identity map GSIs, and so the + * data contained in that struct (used to map guest GSIs into + * machine GSIs and perform interrupt routing) is completely + * useless to it=2E + */ + hvm_irq_dpci =3D xzalloc(struct hvm_irq_dpci); + if ( hvm_irq_dpci =3D=3D NULL ) + { + write_unlock(&d->event_lock); + return -ENOMEM; + } + for ( i =3D 0; i < NR_HVM_DOMU_IRQS; i++ ) + INIT_LIST_HEAD(&hvm_irq_dpci->girq[i]); + + hvm_domain_irq(d)->dpci =3D hvm_irq_dpci; + } + + info =3D pirq_get_info(d, pirq); + if ( !info ) { write_unlock(&d->event_lock); return -ENOMEM; } - for ( i =3D 0; i < NR_HVM_DOMU_IRQS; i++ ) - INIT_LIST_HEAD(&hvm_irq_dpci->girq[i]); - - hvm_domain_irq(d)->dpci =3D hvm_irq_dpci; - } - - info =3D pirq_get_info(d, pirq); - if ( !info ) - { - write_unlock(&d->event_lock); - return -ENOMEM; - } - pirq_dpci =3D pirq_dpci(info); + pirq_dpci =3D pirq_dpci(info); =20 - /* - * A crude 'while' loop with us dropping the spinlock and giving - * the softirq_dpci a chance to run=2E - * We MUST check for this condition as the softirq could be scheduled - * and hasn't run yet=2E Note that this code replaced tasklet_kill wh= ich - * would have spun forever and would do the same thing (wait to flush= out - * outstanding hvm_dirq_assist calls=2E - */ - if ( pt_pirq_softirq_active(pirq_dpci) ) - { - write_unlock(&d->event_lock); - cpu_relax(); - goto restart; + /* + * A crude 'while' loop with us dropping the spinlock and giving + * the softirq_dpci a chance to run=2E + * We MUST check for this condition as the softirq could be sched= uled + * and hasn't run yet=2E Note that this code replaced tasklet_kil= l + * which would have spun forever and would do the same thing (wai= t + * to flush out outstanding hvm_dirq_assist calls)=2E + */ + if ( pt_pirq_softirq_active(pirq_dpci) ) + { + write_unlock(&d->event_lock); + cpu_relax(); + goto restart; + } } =20 switch ( pt_irq_bind->irq_type ) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35a5.d06bb82c97bcd973.1a0679ed066.5d48df588f90c8dd=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407257.1640354 (Exim 4.92) (envelope-from ) id 1x28Cy-0005ik-VA; Thu, 03 Sep 2026 14:14:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407257.1640354; Thu, 03 Sep 2026 14:14:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28Cy-0005iZ-SB; Thu, 03 Sep 2026 14:14:28 +0000 Received: by outflank-mailman (input) for mailman id 1407257; Thu, 03 Sep 2026 14:14:27 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28Cx-0005UD-JW for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28Cx-006VeY-05 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:27 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980a0-bab6-0a2a0a5309dd-0a2a4506deb4-44 for ; Thu, 03 Sep 2026 16:14:26 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980c0-195a-0a2a45060019-b9ff1c238775-4 for ; Thu, 03 Sep 2026 16:14:26 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ed358000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:17 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 8310284007; Thu, 3 Sep 2026 16:14:16 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=h3ZP4W9g2bPX9SP7yYh6igBoYL0cy5yX8xSLc9mKgjs=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=pc3tqOqL+2ALS7GtUGitfMGPn+lgB2hMuVe0+XIbMQ0eQ+8xYp193La6bSgmV+qWDHt5GGsT8 rTqckfJXiYK1wdRdcK3488NORCO3E0og2JLHKmIEOGp++O/IAjw9fLUhfmgmGdukiT8fGi6zOYM Xxf0ONj8AVCKWstPgpzn5GuuqTUcQsUsZU3GvD5rfth6ZFsDCrz1Jb5E4HOPwCEzFSnH0VyONTO ewzMjyn4vyS5UgScTIfSpIcMAb1+DHhtz7swEQRfMiA7izC/zmCaOpPU4Od8zprkY4SjAPoDIM6 fzGLNTd0CkaHStc5fCiXFDhjXBHO7EUtKpu+gSL5MLcA== X-Zone-Loop: f15ddafbb473f4cd2d2f3b01ccba6975d4de71124084 x-campaign-type: default x-transaction-id: 306bf369-c149-4751-98d5-927e2ae20227 x-swg-uid: 01-f1e1b78d-ce97-44a8-9869-e35e8147fb31 X-Mailer: Sweego Message-ID: <1788444857.8631fc262581453bbf619ec5b2062170.1a0679ed358000c4f3@vates.tech> x-swg-bid: 1788444857.8631fc262581453bbf619ec5b2062170.1a0679ed358000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 03/11] x86/passthrough: Replace pt_irq_create_bind() goto restart with a loop Date: Thu, 3 Sep 2026 16:14:01 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35a6.f864c585202bbc2b.1a0679ed1a8.584221bc86a559c0=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444856744 X-purgate-ID: tlsNG-16d1c6/1788444866-F607177B-E1B4D181/0/0 X-purgate-type: clean X-purgate-size: 1883 ---=Part.35a6.f864c585202bbc2b.1a0679ed1a8.584221bc86a559c0=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Change "goto restart" retry in pt_irq_create_bind() into a "for ( ; ;)" loop with continue/break, so that the following patch extracting the block into a helper is only a code move without a label crossing a function boundary=2E No functional change=2E Signed-off-by: Julian Vetter --- Changes in v5: - New patch, split out of v4's "Extract pt_irq_dpci_setup()"=2E It only converts the "goto restart" retry into a "for ( ; ; )" loop, so the following commit's extraction is only a code move with no label crossing a function boundary=2E - Use "for ( ; ; )" rather than v4's "do { } while ( true )"=2E Signed-off-by: Julian Vetter --- xen/drivers/passthrough/x86/hvm=2Ec | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/drivers/passthrough/x86/hvm=2Ec b/xen/drivers/passthrough= /x86/hvm=2Ec index 1d5b1fb0f8=2E=2Ea74521fb57 100644 --- a/xen/drivers/passthrough/x86/hvm=2Ec +++ b/xen/drivers/passthrough/x86/hvm=2Ec @@ -228,7 +228,7 @@ int pt_irq_create_bind( if ( pirq < 0 || pirq >=3D d->nr_pirqs ) return -EINVAL; =20 - restart: + for ( ; ; ) { write_lock(&d->event_lock); =20 @@ -276,8 +276,10 @@ int pt_irq_create_bind( { write_unlock(&d->event_lock); cpu_relax(); - goto restart; + continue; } + + break; } =20 switch ( pt_irq_bind->irq_type ) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35a6.f864c585202bbc2b.1a0679ed1a8.584221bc86a559c0=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407258.1640363 (Exim 4.92) (envelope-from ) id 1x28D0-0005we-6Z; Thu, 03 Sep 2026 14:14:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407258.1640363; Thu, 03 Sep 2026 14:14:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D0-0005wU-2Y; Thu, 03 Sep 2026 14:14:30 +0000 Received: by outflank-mailman (input) for mailman id 1407258; Thu, 03 Sep 2026 14:14:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28Cz-0005p7-Hg for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28Cy-001H4c-Uh for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:28 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980c3-2eae-0a2a0a5409dd-0a2a4506ae08-8 for ; Thu, 03 Sep 2026 16:14:28 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980c0-195a-0a2a45060019-b9ff1c238775-5 for ; Thu, 03 Sep 2026 16:14:28 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ed4c6000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:17 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id D21A384009; Thu, 3 Sep 2026 16:14:16 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=+6GkMIp/1eeu/JYU7MqSA0Jg0HqhrlFBR87a2YshFkM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=iBocxmf2ySsOM/kuCSrJW50/IJxqr68w2FA1zILstYiuIRYahHRcntJXrekr6DDoIOn5foko0 2EoCpgNC+nES1mV09YIAhvyGybjHB3A+dvdsYq1pIi2QSKoCfOVVZ1EC2foi9SqM5vjQRJs19og yg1dLPKscntAh9uvzloVQUxJdX7jq0t2QZw+aSk0gytQW9MIvvxjUPQYJjQ5MKSzNHeX5PMPSc3 wY1KlZ2jLL16GUbySlI5Wcig9OyyKd7gZDbyqWmrdaD0XH0qfwLDWuNhGkgs1ed2i6YZPmAhT7D s0IIhwWfbAWRm8dHuqXtVTo7a/G1Dsmf1Fby+QD5JnQQ== X-Zone-Loop: 1ff00ec3e46e6bd6b9f1e9af5dbd4868d064be86c2ad x-campaign-type: default x-transaction-id: db0da7ba-05bb-42ec-9404-4b1c1434aef6 x-swg-uid: 01-14015135-ea07-494e-a639-aea863dc84cb X-Mailer: Sweego Message-ID: <1788444857.8631fc262581453bbf619ec5b2062170.1a0679ed4c6000c4f3@vates.tech> x-swg-bid: 1788444857.8631fc262581453bbf619ec5b2062170.1a0679ed4c6000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 04/11] x86/passthrough: Extract pt_irq_dpci_setup() from pt_irq_create_bind() Date: Thu, 3 Sep 2026 16:14:02 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35a7.ad47fc3b5f677688.1a0679ed2ed.de73df203679ce07=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444857069 X-purgate-ID: tlsNG-16d1c6/1788444868-F70C777B-49ABC3EE/0/0 X-purgate-type: clean X-purgate-size: 2904 ---=Part.35a7.ad47fc3b5f677688.1a0679ed2ed.de73df203679ce07=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The setup preamble in pt_irq_create_bind() (lazily allocating hvm_irq_dpci, looking up the struct pirq, and spinning until any pending hvm_dirq_assist softirq has drained) is needed by the MSI bind path as well=2E Move it into a static helper pt_irq_dpci_setup() that returns with d->event_lock write-locked on success and hands the three looked-up pointers back through out parameters=2E No functional change=2E Signed-off-by: Julian Vetter --- Changes in v5: - The goto-to-loop conversion is now in the preceding patch, so this one just moves code around=2E - Commit message reworded=2E Signed-off-by: Julian Vetter --- xen/drivers/passthrough/x86/hvm=2Ec | 32 +++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/xen/drivers/passthrough/x86/hvm=2Ec b/xen/drivers/passthrough= /x86/hvm=2Ec index a74521fb57=2E=2E7fcd3cc046 100644 --- a/xen/drivers/passthrough/x86/hvm=2Ec +++ b/xen/drivers/passthrough/x86/hvm=2Ec @@ -217,16 +217,14 @@ static struct vcpu *vector_hashing_dest(const struct= domain *d, return dest; } =20 -int pt_irq_create_bind( - struct domain *d, const struct xen_domctl_bind_pt_irq *pt_irq_bind) +static int pt_irq_dpci_setup(struct domain *d, unsigned int pirq, + struct hvm_irq_dpci **hvm_irq_dpci_out, + struct hvm_pirq_dpci **pirq_dpci_out, + struct pirq **info_out) { struct hvm_irq_dpci *hvm_irq_dpci; struct hvm_pirq_dpci *pirq_dpci; struct pirq *info; - int rc, pirq =3D pt_irq_bind->machine_irq; - - if ( pirq < 0 || pirq >=3D d->nr_pirqs ) - return -EINVAL; =20 for ( ; ; ) { @@ -282,6 +280,28 @@ int pt_irq_create_bind( break; } =20 + *hvm_irq_dpci_out =3D hvm_irq_dpci; + *pirq_dpci_out =3D pirq_dpci; + *info_out =3D info; + + return 0; +} + +int pt_irq_create_bind( + struct domain *d, const struct xen_domctl_bind_pt_irq *pt_irq_bind) +{ + struct hvm_irq_dpci *hvm_irq_dpci; + struct hvm_pirq_dpci *pirq_dpci; + struct pirq *info; + int rc, pirq =3D pt_irq_bind->machine_irq; + + if ( pirq < 0 || pirq >=3D d->nr_pirqs ) + return -EINVAL; + + rc =3D pt_irq_dpci_setup(d, pirq, &hvm_irq_dpci, &pirq_dpci, &info); + if ( rc ) + return rc; + switch ( pt_irq_bind->irq_type ) { case PT_IRQ_TYPE_MSI: --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35a7.ad47fc3b5f677688.1a0679ed2ed.de73df203679ce07=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407259.1640372 (Exim 4.92) (envelope-from ) id 1x28D2-0006C9-DU; Thu, 03 Sep 2026 14:14:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407259.1640372; Thu, 03 Sep 2026 14:14:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D2-0006C0-AI; Thu, 03 Sep 2026 14:14:32 +0000 Received: by outflank-mailman (input) for mailman id 1407259; Thu, 03 Sep 2026 14:14:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D0-00063Q-Pr for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28D0-001H4c-6J for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:30 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980c3-2eae-0a2a0a5409dd-0a2a4506ae08-12 for ; Thu, 03 Sep 2026 16:14:30 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980c0-195a-0a2a45060019-b9ff1c238775-6 for ; Thu, 03 Sep 2026 16:14:30 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ed5cb000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:17 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 2D2D48400B; Thu, 3 Sep 2026 16:14:17 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=EMoj4d2wG+b14N1m0v4nZI3dq2ElOe1px6bJBfqEcts=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=P10K10XmOLF2zVa2SU1jN2trI4UVwJKX2I8yxbmXoGIAsnBK0k1pcfMWQVCZ5KOYXbs5XAqKR vAQ5dbf2c2weugGRqy/zY8L29sWpfTCAa0dE7cC6GacDBzkEe4wwAF9bVO6FWlY24PHzWQnipEm Pgi7NhRUFR/x7baiMbaAoxWGox1GdeBJjEEB2gafJih7q3d3uFj7NedWSzNuBqNrmvG5UnampvU Nxxf+qApFtJ92AE1bUuEWHFY6C21n1iIcbZpH9RhVHNS2ODyuQGhlCicWNpFt21Yh1c/g7O2iqt GA7PA+qPAf6NvcMnJ2T4qGUFVtg4JvsZNnYxKi59iE1A== X-Zone-Loop: 805b0bc169318dc6ad4260f732d926418730b83fe513 x-campaign-type: default x-transaction-id: 17d51502-7c92-47e6-910f-5c7f0c7b0138 x-swg-uid: 01-d46563e3-3bd1-49f0-8f7c-35efecd22d89 X-Mailer: Sweego Message-ID: <1788444857.8631fc262581453bbf619ec5b2062170.1a0679ed5cb000c4f3@vates.tech> x-swg-bid: 1788444857.8631fc262581453bbf619ec5b2062170.1a0679ed5cb000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 05/11] x86/passthrough: Extract PT_IRQ_TYPE_MSI body into pt_irq_bind_msi() Date: Thu, 3 Sep 2026 16:14:03 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35a8.4b933214084d2238.1a0679ed436.e3f9f62c71b5f07a=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444857399 X-purgate-ID: tlsNG-16d1c6/1788444870-1EEC477B-A58899A3/0/0 X-purgate-type: clean X-purgate-size: 8979 ---=Part.35a8.4b933214084d2238.1a0679ed436.e3f9f62c71b5f07a=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Move the PT_IRQ_TYPE_MSI case of pt_irq_create_bind() into a new static helper pt_irq_bind_msi(d, machine_irq, gvec, gflags, gtable, unmasked)=2E The helper calls pt_irq_dpci_setup() itself, so pt_irq_create_bind() now invokes the setup helper separately in the PCI / MSI_TRANSLATE case and the 'default' case no longer needs to drop d->event_lock=2E To keep this step "just" a code move, the extracted body is left at its original (switch/case) indentation inside a compound block=2E The next commit re-indents it=2E References to pt_irq_bind->u=2Emsi=2E* are replace= d by the corresponding parameters, and the two pt_irq_destroy_bind() error paths build a local xen_domctl_bind_pt_irq instead=2E No functional change=2E Signed-off-by: Julian Vetter --- Changes in v5: - New patch: this is the first half of v4's single "Extract PT_IRQ_TYPE_MSI body" patch, now split into "extract as-is, keeping the switch/case indentation inside a bare block" plus a re-indent (next patch), so each step reviews cleanly=2E - machine_irq / gflags parameters are now unsigned int=2E - The redundant nr_pirqs bound check inside the helper was dropped=2E - The "!!" on the unmasked argument was removed=2E - pt_irq_dpci_setup() is now called per-case=2E - The "default" case no longer double-unlocks d->event_lock=2E - The two pt_irq_destroy_bind() error paths build a local xen_domctl_bind_pt_irq=2E - Comment capitalisation fixed=2E Signed-off-by: Julian Vetter --- xen/drivers/passthrough/x86/hvm=2Ec | 81 +++++++++++++++++++++---------- 1 file changed, 55 insertions(+), 26 deletions(-) diff --git a/xen/drivers/passthrough/x86/hvm=2Ec b/xen/drivers/passthrough= /x86/hvm=2Ec index 7fcd3cc046=2E=2Eed368a7fdb 100644 --- a/xen/drivers/passthrough/x86/hvm=2Ec +++ b/xen/drivers/passthrough/x86/hvm=2Ec @@ -287,40 +287,33 @@ static int pt_irq_dpci_setup(struct domain *d, unsig= ned int pirq, return 0; } =20 -int pt_irq_create_bind( - struct domain *d, const struct xen_domctl_bind_pt_irq *pt_irq_bind) +static int pt_irq_bind_msi(struct domain *d, unsigned int machine_irq, + uint8_t gvec, unsigned int gflags, uint64_t gt= able, + bool unmasked) { struct hvm_irq_dpci *hvm_irq_dpci; struct hvm_pirq_dpci *pirq_dpci; struct pirq *info; - int rc, pirq =3D pt_irq_bind->machine_irq; - - if ( pirq < 0 || pirq >=3D d->nr_pirqs ) - return -EINVAL; + int rc; =20 - rc =3D pt_irq_dpci_setup(d, pirq, &hvm_irq_dpci, &pirq_dpci, &info); + rc =3D pt_irq_dpci_setup(d, machine_irq, &hvm_irq_dpci, &pirq_dpci, &= info); if ( rc ) return rc; =20 - switch ( pt_irq_bind->irq_type ) - { - case PT_IRQ_TYPE_MSI: { uint8_t dest, delivery_mode; bool dest_mode; int dest_vcpu_id; const struct vcpu *vcpu; - uint32_t gflags =3D pt_irq_bind->u=2Emsi=2Egflags & - ~XEN_DOMCTL_VMSI_X86_UNMASKED; =20 if ( !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) ) { pirq_dpci->flags =3D HVM_IRQ_DPCI_MAPPED | HVM_IRQ_DPCI_MACH_= MSI | HVM_IRQ_DPCI_GUEST_MSI; - pirq_dpci->gmsi=2Egvec =3D pt_irq_bind->u=2Emsi=2Egvec; + pirq_dpci->gmsi=2Egvec =3D gvec; pirq_dpci->gmsi=2Egflags =3D gflags; /* - * 'pt_irq_create_bind' can be called after 'pt_irq_destroy_b= ind'=2E + * 'pt_irq_bind_msi' can be called after 'pt_irq_destroy_bind= '=2E * The 'pirq_cleanup_check' which would free the structure is= only * called if the event channel for the PIRQ is active=2E Howe= ver * OS-es that use event channels usually bind PIRQs to eventd= s @@ -328,14 +321,14 @@ int pt_irq_create_bind( * result that we re-use the 'dpci' structure=2E This can be * reproduced with unloading and loading the driver for a dev= ice=2E * - * As such on every 'pt_irq_create_bind' call we MUST set it= =2E + * As such on every 'pt_irq_bind_msi' call we MUST set it=2E */ pirq_dpci->dom =3D d; - /* bind after hvm_irq_dpci is setup to avoid race with irq ha= ndler*/ + /* Bind after hvm_irq_dpci is setup to avoid race with irq ha= ndler=2E */ rc =3D pirq_guest_bind(d->vcpu[0], info, 0); - if ( rc =3D=3D 0 && pt_irq_bind->u=2Emsi=2Egtable ) + if ( rc =3D=3D 0 && gtable ) { - rc =3D msixtbl_pt_register(d, info, pt_irq_bind->u=2Emsi= =2Egtable); + rc =3D msixtbl_pt_register(d, info, gtable); if ( unlikely(rc) ) { pirq_guest_unbind(d, info); @@ -371,13 +364,13 @@ int pt_irq_create_bind( } =20 /* If pirq is already mapped as vmsi, update guest data/addr= =2E */ - if ( pirq_dpci->gmsi=2Egvec !=3D pt_irq_bind->u=2Emsi=2Egvec = || + if ( pirq_dpci->gmsi=2Egvec !=3D gvec || pirq_dpci->gmsi=2Egflags !=3D gflags ) { /* Directly clear pending EOIs before enabling new MSI in= fo=2E */ pirq_guest_eoi(info); =20 - pirq_dpci->gmsi=2Egvec =3D pt_irq_bind->u=2Emsi=2Egvec; + pirq_dpci->gmsi=2Egvec =3D gvec; pirq_dpci->gmsi=2Egflags =3D gflags; } } @@ -408,23 +401,31 @@ int pt_irq_create_bind( /* Use interrupt posting if it is supported=2E */ if ( iommu_intpost ) { - rc =3D hvm_pi_update_irte(vcpu, info, pirq_dpci->gmsi=2Egvec)= ; + struct xen_domctl_bind_pt_irq pt_irq_bind =3D { + =2Emachine_irq =3D machine_irq, + =2Eirq_type =3D PT_IRQ_TYPE_MSI, + }; =20 + rc =3D hvm_pi_update_irte(vcpu, info, pirq_dpci->gmsi=2Egvec)= ; if ( rc ) { - pt_irq_destroy_bind(d, pt_irq_bind); + pt_irq_destroy_bind(d, &pt_irq_bind); return rc; } } =20 - if ( pt_irq_bind->u=2Emsi=2Egflags & XEN_DOMCTL_VMSI_X86_UNMASKED= ) + if ( unmasked ) { + struct xen_domctl_bind_pt_irq pt_irq_bind =3D { + =2Emachine_irq =3D machine_irq, + =2Eirq_type =3D PT_IRQ_TYPE_MSI, + }; unsigned long flags; struct irq_desc *desc =3D pirq_spin_lock_irq_desc(info, &flag= s); =20 if ( !desc ) { - pt_irq_destroy_bind(d, pt_irq_bind); + pt_irq_destroy_bind(d, &pt_irq_bind); return -EINVAL; } =20 @@ -432,15 +433,44 @@ int pt_irq_create_bind( spin_unlock_irqrestore(&desc->lock, flags); } =20 - break; + return 0; + } +} + +int pt_irq_create_bind( + struct domain *d, const struct xen_domctl_bind_pt_irq *pt_irq_bind) +{ + int pirq =3D pt_irq_bind->machine_irq; + + if ( pirq < 0 || pirq >=3D d->nr_pirqs ) + return -EINVAL; + + switch ( pt_irq_bind->irq_type ) + { + case PT_IRQ_TYPE_MSI: + { + unsigned int gflags =3D pt_irq_bind->u=2Emsi=2Egflags; + + return pt_irq_bind_msi(d, pirq, pt_irq_bind->u=2Emsi=2Egvec, + gflags & ~XEN_DOMCTL_VMSI_X86_UNMASKED, + pt_irq_bind->u=2Emsi=2Egtable, + gflags & XEN_DOMCTL_VMSI_X86_UNMASKED); } =20 case PT_IRQ_TYPE_PCI: case PT_IRQ_TYPE_MSI_TRANSLATE: { + struct hvm_irq_dpci *hvm_irq_dpci; + struct hvm_pirq_dpci *pirq_dpci; + struct pirq *info; struct dev_intx_gsi_link *digl =3D NULL; struct hvm_girq_dpci_mapping *girq =3D NULL; unsigned int guest_gsi; + int rc; + + rc =3D pt_irq_dpci_setup(d, pirq, &hvm_irq_dpci, &pirq_dpci, &inf= o); + if ( rc ) + return rc; =20 /* * Mapping GSIs for the hardware domain is different than doing i= t for @@ -589,7 +619,6 @@ int pt_irq_create_bind( } =20 default: - write_unlock(&d->event_lock); return -EOPNOTSUPP; } =20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35a8.4b933214084d2238.1a0679ed436.e3f9f62c71b5f07a=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407260.1640381 (Exim 4.92) (envelope-from ) id 1x28D4-0006T4-Qv; Thu, 03 Sep 2026 14:14:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407260.1640381; Thu, 03 Sep 2026 14:14:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D4-0006St-N9; Thu, 03 Sep 2026 14:14:34 +0000 Received: by outflank-mailman (input) for mailman id 1407260; Thu, 03 Sep 2026 14:14:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D2-0006FP-Rm for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28D2-001H4c-7x for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:32 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980c3-2eae-0a2a0a5409dd-0a2a4506ae08-18 for ; Thu, 03 Sep 2026 16:14:32 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980c0-195a-0a2a45060019-b9ff1c238775-7 for ; Thu, 03 Sep 2026 16:14:32 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ed728000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:18 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 7D6AB8400D; Thu, 3 Sep 2026 16:14:17 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=XlXn7+U7AhcVnIuq8LehatGTdH1rv7CZg+DUPNdYgUU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Gkq0stmJhwqiGy80JiK+VixgmmbCoI+NQAlTG5W+JcewQXs3cQaJgQVRXgKAqAz1WmiWI8EqL 8NgoxORM4GPgGHyWesiwuQnPDi4oyd6MSKdRa4UwZQI3P1r2y/EE9umwfZy1Qa+3A7/alS3F6oJ om9Ytno/CdkMbDPVi/fH1w95VoVTu4l+qx1+JZjmXFlbVuIMIHoIZUR0HROkP3hvh/t+L5+V82T vzyt1TEpauRVWCoj3MlYq+Pqz7dxFXkaLuR9c57kjiyMpXsY+7kxLaNhSQuLtQ9oYzKHXUFHD3L 9+eNk6llGkn2ZWNT2jFkdpQU5IjKKSs95p0eKl2g0z2Q== X-Zone-Loop: 70ef9b24403594f9905bebe9f916eb79cba80da7c1eb x-campaign-type: default x-transaction-id: 11323503-91e7-43da-b618-24919b35d4cb x-swg-uid: 01-301f6409-08d7-4cbb-8e44-63148d780951 X-Mailer: Sweego Message-ID: <1788444858.8631fc262581453bbf619ec5b2062170.1a0679ed728000c4f3@vates.tech> x-swg-bid: 1788444858.8631fc262581453bbf619ec5b2062170.1a0679ed728000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 06/11] x86/passthrough: Re-indent pt_irq_bind_msi() body Date: Thu, 3 Sep 2026 16:14:04 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35a9.39c8d9bf421e1e25.1a0679ed57e.33cdc81cbace567b=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444857726 X-purgate-ID: tlsNG-16d1c6/1788444872-FD80D77B-5DB27F4F/0/0 X-purgate-type: clean X-purgate-size: 12064 ---=Part.35a9.39c8d9bf421e1e25.1a0679ed57e.33cdc81cbace567b=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Purely mechanical follow-up to the previous patch: drop the compound block that preserved the original switch/case indentation, shift the body one level left, move the block-local declarations to the top of the function, and add the missing blank line before the dest_vcpu_id calculation=2E No functional change=2E 'git show --ignore-all-space' is empty apart from the declaration move and the removed brackets=2E Signed-off-by: Julian Vetter --- Changes in v5: - New patch: the re-indent half of the v4 extraction=2E Drops the compound block, shifts the body one level left, move the block-local declarations and adds the missing blank line=2E Signed-off-by: Julian Vetter --- xen/drivers/passthrough/x86/hvm=2Ec | 224 +++++++++++++++--------------- 1 file changed, 111 insertions(+), 113 deletions(-) diff --git a/xen/drivers/passthrough/x86/hvm=2Ec b/xen/drivers/passthrough= /x86/hvm=2Ec index ed368a7fdb=2E=2E5fdb885311 100644 --- a/xen/drivers/passthrough/x86/hvm=2Ec +++ b/xen/drivers/passthrough/x86/hvm=2Ec @@ -295,146 +295,144 @@ static int pt_irq_bind_msi(struct domain *d, unsig= ned int machine_irq, struct hvm_pirq_dpci *pirq_dpci; struct pirq *info; int rc; + uint8_t dest, delivery_mode; + bool dest_mode; + int dest_vcpu_id; + const struct vcpu *vcpu; =20 rc =3D pt_irq_dpci_setup(d, machine_irq, &hvm_irq_dpci, &pirq_dpci, &= info); if ( rc ) return rc; =20 + if ( !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) ) { - uint8_t dest, delivery_mode; - bool dest_mode; - int dest_vcpu_id; - const struct vcpu *vcpu; - - if ( !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) ) + pirq_dpci->flags =3D HVM_IRQ_DPCI_MAPPED | HVM_IRQ_DPCI_MACH_MSI = | + HVM_IRQ_DPCI_GUEST_MSI; + pirq_dpci->gmsi=2Egvec =3D gvec; + pirq_dpci->gmsi=2Egflags =3D gflags; + /* + * 'pt_irq_bind_msi' can be called after 'pt_irq_destroy_bind'=2E + * The 'pirq_cleanup_check' which would free the structure is onl= y + * called if the event channel for the PIRQ is active=2E However + * OS-es that use event channels usually bind PIRQs to eventds + * and unbind them before calling 'pt_irq_destroy_bind' - with th= e + * result that we re-use the 'dpci' structure=2E This can be + * reproduced with unloading and loading the driver for a device= =2E + * + * As such on every 'pt_irq_bind_msi' call we MUST set it=2E + */ + pirq_dpci->dom =3D d; + /* Bind after hvm_irq_dpci is setup to avoid race with irq handle= r=2E */ + rc =3D pirq_guest_bind(d->vcpu[0], info, 0); + if ( rc =3D=3D 0 && gtable ) { - pirq_dpci->flags =3D HVM_IRQ_DPCI_MAPPED | HVM_IRQ_DPCI_MACH_= MSI | - HVM_IRQ_DPCI_GUEST_MSI; - pirq_dpci->gmsi=2Egvec =3D gvec; - pirq_dpci->gmsi=2Egflags =3D gflags; - /* - * 'pt_irq_bind_msi' can be called after 'pt_irq_destroy_bind= '=2E - * The 'pirq_cleanup_check' which would free the structure is= only - * called if the event channel for the PIRQ is active=2E Howe= ver - * OS-es that use event channels usually bind PIRQs to eventd= s - * and unbind them before calling 'pt_irq_destroy_bind' - wit= h the - * result that we re-use the 'dpci' structure=2E This can be - * reproduced with unloading and loading the driver for a dev= ice=2E - * - * As such on every 'pt_irq_bind_msi' call we MUST set it=2E - */ - pirq_dpci->dom =3D d; - /* Bind after hvm_irq_dpci is setup to avoid race with irq ha= ndler=2E */ - rc =3D pirq_guest_bind(d->vcpu[0], info, 0); - if ( rc =3D=3D 0 && gtable ) - { - rc =3D msixtbl_pt_register(d, info, gtable); - if ( unlikely(rc) ) - { - pirq_guest_unbind(d, info); - /* - * Between 'pirq_guest_bind' and before 'pirq_guest_u= nbind' - * an interrupt can be scheduled=2E No more of them a= re going - * to be scheduled but we must deal with the one that= may be - * in the queue=2E - */ - pt_pirq_softirq_reset(pirq_dpci); - } - } + rc =3D msixtbl_pt_register(d, info, gtable); if ( unlikely(rc) ) { - pirq_dpci->gmsi=2Egflags =3D 0; - pirq_dpci->gmsi=2Egvec =3D 0; - pirq_dpci->dom =3D NULL; - pirq_dpci->flags =3D 0; - if ( !info->evtchn ) - pirq_cleanup_check(info, d); - write_unlock(&d->event_lock); - return rc; + pirq_guest_unbind(d, info); + /* + * Between 'pirq_guest_bind' and before 'pirq_guest_unbin= d' + * an interrupt can be scheduled=2E No more of them are g= oing + * to be scheduled but we must deal with the one that may= be + * in the queue=2E + */ + pt_pirq_softirq_reset(pirq_dpci); } } - else + if ( unlikely(rc) ) { - uint32_t mask =3D HVM_IRQ_DPCI_MACH_MSI | HVM_IRQ_DPCI_GUEST_= MSI; - - if ( (pirq_dpci->flags & mask) !=3D mask ) - { - write_unlock(&d->event_lock); - return -EBUSY; - } - - /* If pirq is already mapped as vmsi, update guest data/addr= =2E */ - if ( pirq_dpci->gmsi=2Egvec !=3D gvec || - pirq_dpci->gmsi=2Egflags !=3D gflags ) - { - /* Directly clear pending EOIs before enabling new MSI in= fo=2E */ - pirq_guest_eoi(info); - - pirq_dpci->gmsi=2Egvec =3D gvec; - pirq_dpci->gmsi=2Egflags =3D gflags; - } + pirq_dpci->gmsi=2Egflags =3D 0; + pirq_dpci->gmsi=2Egvec =3D 0; + pirq_dpci->dom =3D NULL; + pirq_dpci->flags =3D 0; + if ( !info->evtchn ) + pirq_cleanup_check(info, d); + write_unlock(&d->event_lock); + return rc; } - /* Calculate dest_vcpu_id for MSI-type pirq migration=2E */ - dest =3D MASK_EXTR(pirq_dpci->gmsi=2Egflags, - XEN_DOMCTL_VMSI_X86_DEST_ID_MASK); - dest_mode =3D pirq_dpci->gmsi=2Egflags & XEN_DOMCTL_VMSI_X86_DM_M= ASK; - delivery_mode =3D MASK_EXTR(pirq_dpci->gmsi=2Egflags, - XEN_DOMCTL_VMSI_X86_DELIV_MASK); - - dest_vcpu_id =3D hvm_girq_dest_2_vcpu_id(d, dest, dest_mode); - pirq_dpci->gmsi=2Edest_vcpu_id =3D dest_vcpu_id; - write_unlock(&d->event_lock); + } + else + { + uint32_t mask =3D HVM_IRQ_DPCI_MACH_MSI | HVM_IRQ_DPCI_GUEST_MSI; =20 - pirq_dpci->gmsi=2Eposted =3D false; - vcpu =3D (dest_vcpu_id >=3D 0) ? d->vcpu[dest_vcpu_id] : NULL; - if ( iommu_intpost ) + if ( (pirq_dpci->flags & mask) !=3D mask ) { - if ( delivery_mode =3D=3D dest_LowestPrio ) - vcpu =3D vector_hashing_dest(d, dest, dest_mode, - pirq_dpci->gmsi=2Egvec); - if ( vcpu ) - pirq_dpci->gmsi=2Eposted =3D true; + write_unlock(&d->event_lock); + return -EBUSY; } - if ( vcpu && is_iommu_enabled(d) ) - hvm_migrate_pirq(pirq_dpci, vcpu); =20 - /* Use interrupt posting if it is supported=2E */ - if ( iommu_intpost ) + /* If pirq is already mapped as vmsi, update guest data/addr=2E *= / + if ( pirq_dpci->gmsi=2Egvec !=3D gvec || + pirq_dpci->gmsi=2Egflags !=3D gflags ) { - struct xen_domctl_bind_pt_irq pt_irq_bind =3D { - =2Emachine_irq =3D machine_irq, - =2Eirq_type =3D PT_IRQ_TYPE_MSI, - }; + /* Directly clear pending EOIs before enabling new MSI info= =2E */ + pirq_guest_eoi(info); =20 - rc =3D hvm_pi_update_irte(vcpu, info, pirq_dpci->gmsi=2Egvec)= ; - if ( rc ) - { - pt_irq_destroy_bind(d, &pt_irq_bind); - return rc; - } + pirq_dpci->gmsi=2Egvec =3D gvec; + pirq_dpci->gmsi=2Egflags =3D gflags; } + } + + /* Calculate dest_vcpu_id for MSI-type pirq migration=2E */ + dest =3D MASK_EXTR(pirq_dpci->gmsi=2Egflags, + XEN_DOMCTL_VMSI_X86_DEST_ID_MASK); + dest_mode =3D pirq_dpci->gmsi=2Egflags & XEN_DOMCTL_VMSI_X86_DM_MASK; + delivery_mode =3D MASK_EXTR(pirq_dpci->gmsi=2Egflags, + XEN_DOMCTL_VMSI_X86_DELIV_MASK); + + dest_vcpu_id =3D hvm_girq_dest_2_vcpu_id(d, dest, dest_mode); + pirq_dpci->gmsi=2Edest_vcpu_id =3D dest_vcpu_id; + write_unlock(&d->event_lock); + + pirq_dpci->gmsi=2Eposted =3D false; + vcpu =3D (dest_vcpu_id >=3D 0) ? d->vcpu[dest_vcpu_id] : NULL; + if ( iommu_intpost ) + { + if ( delivery_mode =3D=3D dest_LowestPrio ) + vcpu =3D vector_hashing_dest(d, dest, dest_mode, + pirq_dpci->gmsi=2Egvec); + if ( vcpu ) + pirq_dpci->gmsi=2Eposted =3D true; + } + if ( vcpu && is_iommu_enabled(d) ) + hvm_migrate_pirq(pirq_dpci, vcpu); + + /* Use interrupt posting if it is supported=2E */ + if ( iommu_intpost ) + { + struct xen_domctl_bind_pt_irq pt_irq_bind =3D { + =2Emachine_irq =3D machine_irq, + =2Eirq_type =3D PT_IRQ_TYPE_MSI, + }; =20 - if ( unmasked ) + rc =3D hvm_pi_update_irte(vcpu, info, pirq_dpci->gmsi=2Egvec); + if ( rc ) { - struct xen_domctl_bind_pt_irq pt_irq_bind =3D { - =2Emachine_irq =3D machine_irq, - =2Eirq_type =3D PT_IRQ_TYPE_MSI, - }; - unsigned long flags; - struct irq_desc *desc =3D pirq_spin_lock_irq_desc(info, &flag= s); + pt_irq_destroy_bind(d, &pt_irq_bind); + return rc; + } + } =20 - if ( !desc ) - { - pt_irq_destroy_bind(d, &pt_irq_bind); - return -EINVAL; - } + if ( unmasked ) + { + struct xen_domctl_bind_pt_irq pt_irq_bind =3D { + =2Emachine_irq =3D machine_irq, + =2Eirq_type =3D PT_IRQ_TYPE_MSI, + }; + unsigned long flags; + struct irq_desc *desc =3D pirq_spin_lock_irq_desc(info, &flags); =20 - guest_mask_msi_irq(desc, false); - spin_unlock_irqrestore(&desc->lock, flags); + if ( !desc ) + { + pt_irq_destroy_bind(d, &pt_irq_bind); + return -EINVAL; } =20 - return 0; + guest_mask_msi_irq(desc, false); + spin_unlock_irqrestore(&desc->lock, flags); } + + return 0; } =20 int pt_irq_create_bind( --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35a9.39c8d9bf421e1e25.1a0679ed57e.33cdc81cbace567b=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407261.1640390 (Exim 4.92) (envelope-from ) id 1x28D6-0006i3-5b; Thu, 03 Sep 2026 14:14:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407261.1640390; Thu, 03 Sep 2026 14:14:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D6-0006hK-0o; Thu, 03 Sep 2026 14:14:36 +0000 Received: by outflank-mailman (input) for mailman id 1407261; Thu, 03 Sep 2026 14:14:34 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D3-0006R8-Tz for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28D3-001H4c-AX for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:33 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980c3-2eae-0a2a0a5409dd-0a2a4506ae08-20 for ; Thu, 03 Sep 2026 16:14:33 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980c0-195a-0a2a45060019-b9ff1c238775-8 for ; Thu, 03 Sep 2026 16:14:33 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ed87d000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:18 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id CF48B8400F; Thu, 3 Sep 2026 16:14:17 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=9x3EXxYPO7WpUDT21fZIhOifLMj2tjMarh2jBk7e3DU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=AeGq01d8R+kU3cs6YUzPsJKWAuirprXqvRt+LyGVvWjb4l6mvOPxQ9l6RXsRf8ML5WFtOhFiE k3F64rXkCqM52PeggiU8KCsuMIA4CVf5pbDLeGJOpOB7kJ5BFz7OjakikHFB4hdjMPLViecOXKn j8mFKQt6N2Mwrbu/pgcpkYqw0g47UzIIVG8RPKvERoFfbfvgij1k+8HvW9YyAnOFVr6Un4iA/1x pyFpzSDhggZDJmTqjkc0ja7Rp19HGFKwwPjd0Djd0DV9mApUFQK8Dn0WJDz1ULOsbXsL8KbXpCN Q/acgedcn5WbXGVzb3gTaOPABzJ4bj+Wkm5PFrQiKmjw== X-Zone-Loop: e2860f3bf6f5c88daf4c29b74384454ffc27abbcc75f x-campaign-type: default x-transaction-id: 87ba8cff-7c68-402f-8f6a-a1082e0cd86e x-swg-uid: 01-480ed2de-1b84-429f-93f3-a1548f6fd399 X-Mailer: Sweego Message-ID: <1788444858.8631fc262581453bbf619ec5b2062170.1a0679ed87d000c4f3@vates.tech> x-swg-bid: 1788444858.8631fc262581453bbf619ec5b2062170.1a0679ed87d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 07/11] x86/passthrough: Switch pt_irq_bind_msi() to raw MSI address/data Date: Thu, 3 Sep 2026 16:14:05 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35aa.daf7bf3a43bd1d0b.1a0679ed6ce.2c4e65cada2122c3=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444858062 X-purgate-ID: tlsNG-16d1c6/1788444873-1ECC577B-49595DC8/0/0 X-purgate-type: clean X-purgate-size: 18045 ---=Part.35aa.daf7bf3a43bd1d0b.1a0679ed6ce.2c4e65cada2122c3=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Some hypervisors let a guest use the "Extended Destination ID" field of the MSI address (and the IO-APIC RTE) to reach APIC IDs beyond the architectural 8-bit destination field, extending the range from 8 to 15 bits (as supported by Linux since commit ab0f59c6f135)=2E This way an HVM guest with APIC IDs above 254 can target an MSI or IO-APIC interrupt=2E This series adds support for it, gated on the guest's device model opting in=2E Change pt_irq_bind_msi() (and struct hvm_gmsi_info) to store and operate on the raw MSI address and data words instead of the pre-decoded gvec/gflags pair=2E A new MSI_ADDR_DEST() helper extracts the combined destination ID from an address, including the extended bits (address 11:5)=2E The extended part is always zero for the messages built here and is only acted upon once the guest opts in=2E pt_irq_bind_msi() now also rejects (-EINVAL) an address that isn't in MSI format (0xfeexxxxx), so that every path storing into gmsi=2Eaddr, in particular the raw-address device-model op, is guaranteed a well-formed message=2E The function vpci_msi_update() already performed this check=2E pt_irq_create_bind() keeps working for domctl callers by rebuilding a raw MSI message from the gflags it is handed=2E vpci_msi_update() now calls pt_irq_bind_msi() directly and msi_gflags() goes away=2E The "already mapped" fast path now compares the full stored address and data rather than just gvec/gflags=2E This is not a behavioural change: the previous gvec/gflags pair was a loss-free re-encoding of exactly the destination, delivery-mode, trigger-mode and vector bits that address/data carry, so any message that would have compared equal before still does, and messages differing only in bits that were previously dropped now correctly trigger a re-program=2E No functional change for existing (8-bit destination ID) guests=2E Signed-off-by: Julian Vetter --- Changes in v5: - Retitled: "Switch pt_irq_bind_msi() to raw MSI address/data" - struct hvm_gmsi_info stores addr/data, so msi_gflags() is gone and vpci_msi_update() calls pt_irq_bind_msi() directly=2E - MSI_ADDR_DEST() derives its shift from a new MSI_ADDR_DEST_ID_WIDTH=2E The original MSI_ADDR_DEST_ID_* lines are left untouched=2E - Removed the "Intel convention" wording in the comment=2E - pt_irq_bind_msi() rejects an address that isn't in MSI format (0xfeexxxxx) with -EINVAL, so every caller storing into gmsi=2Eaddr is guaranteed a well-formed message=2E Per Jan's comment: "cope with existing code passing rubbish there =2E=2E=2E e=2Eg=2E in vpci_msi_updat= e()"=2E - _hvm_dpci_msi_eoi() dest-mode bug fixed: it tested XEN_DOMCTL_VMSI_X86_DM_MASK against a raw address, now uses MSI_ADDR_DESTMODE_MASK=2E - vmsi_deliver_pirq() reads gmsi=2Eaddr/gmsi=2Edata with the standard MSI masks (v4 kept XEN_DOMCTL_VMSI_X86_FULL_DEST())=2E - pt_irq_create_bind()'s PT_IRQ_TYPE_MSI case keeps working here by rebuilding a raw message from gflags (v4 rejected it with -EOPNOTSUPP)= =2E - Commit message explains why the "already mapped" comparison widened to full addr/data=2E - Use MASK_EXTR/MASK_INSR throughout=2E Signed-off-by: Julian Vetter --- xen/arch/x86/hvm/vmsi=2Ec | 53 +++++++-------------- xen/arch/x86/include/asm/hvm/irq=2Eh | 4 +- xen/arch/x86/include/asm/msi=2Eh | 19 ++++++++ xen/drivers/passthrough/x86/hvm=2Ec | 75 +++++++++++++++++++----------- xen/include/xen/iommu=2Eh | 3 ++ 5 files changed, 91 insertions(+), 63 deletions(-) diff --git a/xen/arch/x86/hvm/vmsi=2Ec b/xen/arch/x86/hvm/vmsi=2Ec index 27b1f089e2=2E=2E6966cabfa7 100644 --- a/xen/arch/x86/hvm/vmsi=2Ec +++ b/xen/arch/x86/hvm/vmsi=2Ec @@ -43,6 +43,7 @@ #include #include #include +#include =20 static void vmsi_inj_irq( struct vlapic *target, @@ -107,12 +108,13 @@ int vmsi_deliver( =20 void vmsi_deliver_pirq(struct domain *d, const struct hvm_pirq_dpci *pirq= _dpci) { - uint32_t flags =3D pirq_dpci->gmsi=2Egflags; - int vector =3D pirq_dpci->gmsi=2Egvec; - uint8_t dest =3D (uint8_t)flags; - bool dest_mode =3D flags & XEN_DOMCTL_VMSI_X86_DM_MASK; - uint8_t delivery_mode =3D MASK_EXTR(flags, XEN_DOMCTL_VMSI_X86_DELIV_= MASK); - bool trig_mode =3D flags & XEN_DOMCTL_VMSI_X86_TRIG_MASK; + uint64_t addr =3D pirq_dpci->gmsi=2Eaddr; + uint32_t data =3D pirq_dpci->gmsi=2Edata; + unsigned int vector =3D MASK_EXTR(data, MSI_DATA_VECTOR_MASK); + uint32_t dest =3D MSI_ADDR_DEST(addr); + bool dest_mode =3D addr & MSI_ADDR_DESTMODE_MASK; + unsigned int delivery_mode =3D MASK_EXTR(data, MSI_DATA_DELIVERY_MODE= _MASK); + bool trig_mode =3D data & MSI_DATA_TRIGGER_MASK; =20 HVM_DBG_LOG(DBG_LEVEL_IOAPIC, "msi: dest=3D%x dest_mode=3D%x delivery_mode=3D%x " @@ -793,27 +795,6 @@ void msix_write_completion(struct vcpu *v) } =20 #ifdef CONFIG_HAS_VPCI -static unsigned int msi_gflags(uint16_t data, uint64_t addr, bool masked) -{ - /* - * We need to use the DOMCTL constants here because the output of thi= s - * function is used as input to pt_irq_create_bind, which also takes = the - * input from the DOMCTL itself=2E - */ - return MASK_INSR(MASK_EXTR(addr, MSI_ADDR_DEST_ID_MASK), - XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) | - MASK_INSR(MASK_EXTR(addr, MSI_ADDR_REDIRECTION_MASK), - XEN_DOMCTL_VMSI_X86_RH_MASK) | - MASK_INSR(MASK_EXTR(addr, MSI_ADDR_DESTMODE_MASK), - XEN_DOMCTL_VMSI_X86_DM_MASK) | - MASK_INSR(MASK_EXTR(data, MSI_DATA_DELIVERY_MODE_MASK), - XEN_DOMCTL_VMSI_X86_DELIV_MASK) | - MASK_INSR(MASK_EXTR(data, MSI_DATA_TRIGGER_MASK), - XEN_DOMCTL_VMSI_X86_TRIG_MASK) | - /* NB: by default MSI vectors are bound masked=2E */ - (masked ? 0 : XEN_DOMCTL_VMSI_X86_UNMASKED); -} - static void vpci_mask_pirq(struct domain *d, int pirq, bool mask) { unsigned long flags; @@ -850,17 +831,19 @@ static int vpci_msi_update(const struct pci_dev *pde= v, uint32_t data, { uint8_t vector =3D MASK_EXTR(data, MSI_DATA_VECTOR_MASK); uint8_t vector_mask =3D 0xff >> (8 - fls(vectors) + 1); - struct xen_domctl_bind_pt_irq bind =3D { - =2Emachine_irq =3D pirq + i, - =2Eirq_type =3D PT_IRQ_TYPE_MSI, - =2Eu=2Emsi=2Egvec =3D (vector & ~vector_mask) | - ((vector + i) & vector_mask), - =2Eu=2Emsi=2Egflags =3D msi_gflags(data, address, (mask >> i)= & 1), - }; - int rc =3D pt_irq_create_bind(pdev->domain, &bind); + uint8_t gvec =3D (vector & ~vector_mask) | ((vector + i) & vector= _mask); + uint32_t msi_data =3D (data & ~MSI_DATA_VECTOR_MASK) | + MASK_INSR(gvec, MSI_DATA_VECTOR_MASK); + int rc =3D pt_irq_bind_msi(pdev->domain, pirq + i, address, msi_d= ata, + 0 /* gtable */, !((mask >> i) & 1)); =20 if ( rc ) { + struct xen_domctl_bind_pt_irq bind =3D { + =2Eirq_type =3D PT_IRQ_TYPE_MSI, + =2Emachine_irq =3D pirq + i, + }; + gdprintk(XENLOG_ERR, "%pp: failed to bind PIRQ %u: %d\n", &pdev->sbdf, pirq + i, rc); while ( bind=2Emachine_irq-- > pirq ) diff --git a/xen/arch/x86/include/asm/hvm/irq=2Eh b/xen/arch/x86/include/a= sm/hvm/irq=2Eh index 77595fb3f4=2E=2Ee79e2e3fed 100644 --- a/xen/arch/x86/include/asm/hvm/irq=2Eh +++ b/xen/arch/x86/include/asm/hvm/irq=2Eh @@ -120,8 +120,8 @@ struct dev_intx_gsi_link { #define HVM_IRQ_DPCI_TRANSLATE (1u << _HVM_IRQ_DPCI_TRANSLATE_SHIFT= ) =20 struct hvm_gmsi_info { - uint32_t gvec; - uint32_t gflags; + uint64_t addr; /* raw MSI address (0xfeexxxxx) */ + uint32_t data; /* raw MSI data (vector, delivery mode, trigger mode) = */ int dest_vcpu_id; /* -1 :multi-dest, non-negative: dest_vcpu_id */ bool posted; /* directly deliver to guest via VT-d PI? */ }; diff --git a/xen/arch/x86/include/asm/msi=2Eh b/xen/arch/x86/include/asm/m= si=2Eh index 6fb663b2e7=2E=2Ea553922853 100644 --- a/xen/arch/x86/include/asm/msi=2Eh +++ b/xen/arch/x86/include/asm/msi=2Eh @@ -54,6 +54,25 @@ #define MSI_ADDR_DEST_ID_MASK 0x00ff000 #define MSI_ADDR_DEST_ID(dest) (((dest) << MSI_ADDR_DEST_ID_SHIFT) & MS= I_ADDR_DEST_ID_MASK) =20 +/* Width of the architectural destination ID field (MSI address bits 19:1= 2)=2E */ +#define MSI_ADDR_DEST_ID_WIDTH 8 + +/* + * "Extended Destination ID": MSI address bits 11:5 carry the top 7 bits = of a + * 15-bit APIC ID, extending the reachable destination range from 8 to 15= bits=2E + * A guest is told this is available via XEN_HVM_CPUID_EXT_DEST_ID=2E The= Linux + * guest side is x86_msi_msg_get_destid() in arch/x86/kernel/apic/apic=2E= c=2E + * + * Only interpret these bits this way for a guest that has opted in=2E Ot= herwise + * treat them as reserved and ignore them=2E + */ +#define MSI_ADDR_EXT_DEST_ID_MASK 0x0000fe0 + +/* Combine the architectural and extended destination bits of an MSI addr= ess=2E */ +#define MSI_ADDR_DEST(addr) \ + (MASK_EXTR(addr, MSI_ADDR_DEST_ID_MASK) | \ + (MASK_EXTR(addr, MSI_ADDR_EXT_DEST_ID_MASK) << MSI_ADDR_DEST_ID_WIDT= H)) + /* MAX fixed pages reserved for mapping MSIX tables=2E */ #define FIX_MSIX_MAX_PAGES 512 =20 diff --git a/xen/drivers/passthrough/x86/hvm=2Ec b/xen/drivers/passthrough= /x86/hvm=2Ec index 5fdb885311=2E=2Ebdab065eb7 100644 --- a/xen/drivers/passthrough/x86/hvm=2Ec +++ b/xen/drivers/passthrough/x86/hvm=2Ec @@ -287,19 +287,24 @@ static int pt_irq_dpci_setup(struct domain *d, unsig= ned int pirq, return 0; } =20 -static int pt_irq_bind_msi(struct domain *d, unsigned int machine_irq, - uint8_t gvec, unsigned int gflags, uint64_t gt= able, - bool unmasked) +int pt_irq_bind_msi(struct domain *d, unsigned int machine_irq, + uint64_t msi_addr, uint32_t msi_data, + uint64_t gtable, bool unmasked) { struct hvm_irq_dpci *hvm_irq_dpci; struct hvm_pirq_dpci *pirq_dpci; struct pirq *info; int rc; - uint8_t dest, delivery_mode; + uint8_t gvec; + uint32_t dest; bool dest_mode; int dest_vcpu_id; const struct vcpu *vcpu; =20 + /* A passthrough MSI must carry an MSI-format address (0xfeexxxxx)=2E= */ + if ( (msi_addr & MSI_ADDR_BASE_MASK) !=3D MSI_ADDR_HEADER ) + return -EINVAL; + rc =3D pt_irq_dpci_setup(d, machine_irq, &hvm_irq_dpci, &pirq_dpci, &= info); if ( rc ) return rc; @@ -308,8 +313,8 @@ static int pt_irq_bind_msi(struct domain *d, unsigned = int machine_irq, { pirq_dpci->flags =3D HVM_IRQ_DPCI_MAPPED | HVM_IRQ_DPCI_MACH_MSI = | HVM_IRQ_DPCI_GUEST_MSI; - pirq_dpci->gmsi=2Egvec =3D gvec; - pirq_dpci->gmsi=2Egflags =3D gflags; + pirq_dpci->gmsi=2Eaddr =3D msi_addr; + pirq_dpci->gmsi=2Edata =3D msi_data; /* * 'pt_irq_bind_msi' can be called after 'pt_irq_destroy_bind'=2E * The 'pirq_cleanup_check' which would free the structure is onl= y @@ -341,8 +346,8 @@ static int pt_irq_bind_msi(struct domain *d, unsigned = int machine_irq, } if ( unlikely(rc) ) { - pirq_dpci->gmsi=2Egflags =3D 0; - pirq_dpci->gmsi=2Egvec =3D 0; + pirq_dpci->gmsi=2Eaddr =3D 0; + pirq_dpci->gmsi=2Edata =3D 0; pirq_dpci->dom =3D NULL; pirq_dpci->flags =3D 0; if ( !info->evtchn ) @@ -362,23 +367,22 @@ static int pt_irq_bind_msi(struct domain *d, unsigne= d int machine_irq, } =20 /* If pirq is already mapped as vmsi, update guest data/addr=2E *= / - if ( pirq_dpci->gmsi=2Egvec !=3D gvec || - pirq_dpci->gmsi=2Egflags !=3D gflags ) + if ( pirq_dpci->gmsi=2Eaddr !=3D msi_addr || + pirq_dpci->gmsi=2Edata !=3D msi_data ) { /* Directly clear pending EOIs before enabling new MSI info= =2E */ pirq_guest_eoi(info); =20 - pirq_dpci->gmsi=2Egvec =3D gvec; - pirq_dpci->gmsi=2Egflags =3D gflags; + pirq_dpci->gmsi=2Eaddr =3D msi_addr; + pirq_dpci->gmsi=2Edata =3D msi_data; } } =20 /* Calculate dest_vcpu_id for MSI-type pirq migration=2E */ - dest =3D MASK_EXTR(pirq_dpci->gmsi=2Egflags, - XEN_DOMCTL_VMSI_X86_DEST_ID_MASK); - dest_mode =3D pirq_dpci->gmsi=2Egflags & XEN_DOMCTL_VMSI_X86_DM_MASK; - delivery_mode =3D MASK_EXTR(pirq_dpci->gmsi=2Egflags, - XEN_DOMCTL_VMSI_X86_DELIV_MASK); + gvec =3D MASK_EXTR(msi_data, MSI_DATA_VECTOR_MASK); + dest =3D MSI_ADDR_DEST(msi_addr); + dest_mode =3D msi_addr & MSI_ADDR_DESTMODE_MASK; + delivery_mode =3D MASK_EXTR(msi_data, MSI_DATA_DELIVERY_MODE_MASK); =20 dest_vcpu_id =3D hvm_girq_dest_2_vcpu_id(d, dest, dest_mode); pirq_dpci->gmsi=2Edest_vcpu_id =3D dest_vcpu_id; @@ -389,8 +393,7 @@ static int pt_irq_bind_msi(struct domain *d, unsigned = int machine_irq, if ( iommu_intpost ) { if ( delivery_mode =3D=3D dest_LowestPrio ) - vcpu =3D vector_hashing_dest(d, dest, dest_mode, - pirq_dpci->gmsi=2Egvec); + vcpu =3D vector_hashing_dest(d, dest, dest_mode, gvec); if ( vcpu ) pirq_dpci->gmsi=2Eposted =3D true; } @@ -405,7 +408,7 @@ static int pt_irq_bind_msi(struct domain *d, unsigned = int machine_irq, =2Eirq_type =3D PT_IRQ_TYPE_MSI, }; =20 - rc =3D hvm_pi_update_irte(vcpu, info, pirq_dpci->gmsi=2Egvec); + rc =3D hvm_pi_update_irte(vcpu, info, gvec); if ( rc ) { pt_irq_destroy_bind(d, &pt_irq_bind); @@ -448,9 +451,30 @@ int pt_irq_create_bind( case PT_IRQ_TYPE_MSI: { unsigned int gflags =3D pt_irq_bind->u=2Emsi=2Egflags; + uint64_t msi_addr; + uint32_t msi_data; =20 - return pt_irq_bind_msi(d, pirq, pt_irq_bind->u=2Emsi=2Egvec, - gflags & ~XEN_DOMCTL_VMSI_X86_UNMASKED, + /* + * Rebuild a raw MSI message from the pre-decoded domctl gflags s= o the + * canonical bind path can decode it uniformly=2E This legacy pat= h never + * carries extended destination ID bits=2E + */ + msi_addr =3D MSI_ADDR_HEADER | + MASK_INSR(MASK_EXTR(gflags, XEN_DOMCTL_VMSI_X86_DEST_I= D_MASK), + MSI_ADDR_DEST_ID_MASK) | + (gflags & XEN_DOMCTL_VMSI_X86_RH_MASK + ? MSI_ADDR_REDIRECTION_LOWPRI + : MSI_ADDR_REDIRECTION_CPU) | + (gflags & XEN_DOMCTL_VMSI_X86_DM_MASK + ? MSI_ADDR_DESTMODE_LOGIC + : MSI_ADDR_DESTMODE_PHYS); + msi_data =3D MASK_INSR(pt_irq_bind->u=2Emsi=2Egvec, MSI_DATA_VECT= OR_MASK) | + MASK_INSR(MASK_EXTR(gflags, XEN_DOMCTL_VMSI_X86_DELIV_= MASK), + MSI_DATA_DELIVERY_MODE_MASK) | + (gflags & XEN_DOMCTL_VMSI_X86_TRIG_MASK + ? MSI_DATA_TRIGGER_LEVEL : 0); + + return pt_irq_bind_msi(d, pt_irq_bind->machine_irq, msi_addr, msi= _data, pt_irq_bind->u=2Emsi=2Egtable, gflags & XEN_DOMCTL_VMSI_X86_UNMASKED); } @@ -857,11 +881,10 @@ static int cf_check _hvm_dpci_msi_eoi( int vector =3D (long)arg; =20 if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) && - (pirq_dpci->gmsi=2Egvec =3D=3D vector) ) + MASK_EXTR(pirq_dpci->gmsi=2Edata, MSI_DATA_VECTOR_MASK) =3D=3D v= ector ) { - unsigned int dest =3D MASK_EXTR(pirq_dpci->gmsi=2Egflags, - XEN_DOMCTL_VMSI_X86_DEST_ID_MASK); - bool dest_mode =3D pirq_dpci->gmsi=2Egflags & XEN_DOMCTL_VMSI_X86= _DM_MASK; + unsigned int dest =3D MSI_ADDR_DEST(pirq_dpci->gmsi=2Eaddr); + bool dest_mode =3D pirq_dpci->gmsi=2Eaddr & MSI_ADDR_DESTMODE_MAS= K; =20 if ( vlapic_match_dest(vcpu_vlapic(current), NULL, 0, dest, dest_mode) ) diff --git a/xen/include/xen/iommu=2Eh b/xen/include/xen/iommu=2Eh index 37c4a1dc82=2E=2Ed68d9ca6ec 100644 --- a/xen/include/xen/iommu=2Eh +++ b/xen/include/xen/iommu=2Eh @@ -222,6 +222,9 @@ int pt_irq_create_bind(struct domain *d, const struct xen_domctl_bind_pt_irq *pt_irq_bind); int pt_irq_destroy_bind(struct domain *d, const struct xen_domctl_bind_pt_irq *pt_irq_bind)= ; +int pt_irq_bind_msi(struct domain *d, unsigned int machine_irq, + uint64_t msi_addr, uint32_t msi_data, + uint64_t gtable, bool unmasked); =20 struct hvm_irq_dpci *domain_get_irq_dpci(const struct domain *d); void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci); --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35aa.daf7bf3a43bd1d0b.1a0679ed6ce.2c4e65cada2122c3=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407263.1640399 (Exim 4.92) (envelope-from ) id 1x28D7-0006yY-J4; Thu, 03 Sep 2026 14:14:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407263.1640399; Thu, 03 Sep 2026 14:14:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D7-0006xz-F5; Thu, 03 Sep 2026 14:14:37 +0000 Received: by outflank-mailman (input) for mailman id 1407263; Thu, 03 Sep 2026 14:14:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D6-0006kV-GH for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28D5-001H4c-SG for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:35 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980bd-2eae-0a2a0a5409dd-0a2a4505c668-28 for ; Thu, 03 Sep 2026 16:14:35 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980cb-4cb1-0a2a45050019-b9ff1c228579-3 for ; Thu, 03 Sep 2026 16:14:35 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ed9b9000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:18 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 2C59784011; Thu, 3 Sep 2026 16:14:18 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=TFc5nplCWpPWb6TL9VVLyQHid2vUkbZ6H31MHV3pWe0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=Qp7WExPsUYQbCeHcj9T3b90YMy2Y1LVopsrlS0Fqk5ae8aJdDC5TZZn8NzqdpcMl6XM3YMdUC wqmM89twND3GP1h+LjbpIK/xQfq77SKbdvLWAbPMc3w0Se9yGIjzDcb0v0Yp58PPFuixq152qEn v73FMgK2G2oymjkIuMaak4H9c/OzgbnZ80NTfPW1+D2XdDJPPWSX2YX4JhM5nSdvYtQDihIdfrW n2K6kwe15kZ/usQtzoayZYaPS90lZz9jcfQPGznMzzyz20JPOOBN+o1GQqNaYHDLDve3R71pfmo hvZIy8cN3yHhdH0EoCD/tsMzPHI+Ol06eaTHt+eQkD9Q== X-Zone-Loop: f743ef71d49e150dfec641ea08342951af9fe89bf7a2 x-campaign-type: default x-transaction-id: 071547b2-5152-4e0e-b954-168722a7635b x-swg-uid: 01-2e75de1e-8a2a-4c83-9194-d44ac0952cc7 X-Mailer: Sweego Message-ID: <1788444858.8631fc262581453bbf619ec5b2062170.1a0679ed9b9000c4f3@vates.tech> x-swg-bid: 1788444858.8631fc262581453bbf619ec5b2062170.1a0679ed9b9000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 08/11] x86/hvm: Decode extended MSI / IO-APIC destination IDs when opted in Date: Thu, 3 Sep 2026 16:14:06 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35ab.e5d7a6729895094a.1a0679ed81d.65b008e6a50fbf51=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444858397 X-purgate-ID: tlsNG-c201ff/1788444875-F6CB02A1-8B16E8B3/0/0 X-purgate-type: clean X-purgate-size: 11092 ---=Part.35ab.e5d7a6729895094a.1a0679ed81d.65b008e6a50fbf51=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Add the plumbing to allow for 15-bit destination IDs: - struct hvm_domain gains a tri-state ext_dest_id (UNSET / DISABLED / ENABLED)=2E hvm_ext_dest_id_active() is the single point to guard every extended decode=2E - The vIO-APIC RTE save record grows an ext_dest_id:7 field (the top 7 bits of a 15-bit APIC ID) and VIOAPIC_RTE_DEST() combines it with dest_id=2E - vmsi_deliver() / hvm_girq_dest_2_vcpu_id() take a uint32_t dest=2E - hvm_inject_msi(), vioapic_deliver(), vmsi_deliver_pirq(), pt_irq_bind_msi() and _hvm_dpci_msi_eoi() fold in the extended bits only when hvm_ext_dest_id_active(), otherwise an unaware guest that left non-zero values in those bits would have its interrupts misrouted=2E Since ext_dest_id is never ENABLED yet, there is no functional change=2E Signed-off-by: Julian Vetter --- Changes in v5: - Rewritten to use a tri-state d->arch=2Ehvm=2Eext_dest_id (UNSET / DISABL= ED / ENABLED)=2E - Addressed Jan's comment about "wrong way round": every decode site folds in the extended bits only when active and ignores them otherwise, rather than rejecting a guest that left values there=2E - VIOAPIC_RTE_DEST() takes a union vioapic_redir_entry and uses =2Edest_id / =2Eext_dest_id=2E - Replaced comments and added one central explanation=2E Signed-off-by: Julian Vetter --- xen/arch/x86/hvm/irq=2Ec | 6 ++++-- xen/arch/x86/hvm/vioapic=2Ec | 5 ++++- xen/arch/x86/hvm/vmsi=2Ec | 8 +++++--- xen/arch/x86/include/asm/hvm/domain=2Eh | 13 +++++++++++++ xen/arch/x86/include/asm/hvm/hvm=2Eh | 12 ++++++++++-- xen/arch/x86/include/asm/hvm/vioapic=2Eh | 10 ++++++++++ xen/drivers/passthrough/x86/hvm=2Ec | 8 ++++++-- xen/include/public/arch-x86/hvm/save=2Eh | 4 +++- 8 files changed, 55 insertions(+), 11 deletions(-) diff --git a/xen/arch/x86/hvm/irq=2Ec b/xen/arch/x86/hvm/irq=2Ec index 5f64361113=2E=2Eaa5926529a 100644 --- a/xen/arch/x86/hvm/irq=2Ec +++ b/xen/arch/x86/hvm/irq=2Ec @@ -374,7 +374,8 @@ int hvm_set_pci_link_route(struct domain *d, u8 link, = u8 isa_irq) int hvm_inject_msi(struct domain *d, uint64_t addr, uint32_t data) { uint32_t tmp =3D (uint32_t) addr; - uint8_t dest =3D (tmp & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_S= HIFT; + uint8_t dest =3D MASK_EXTR(tmp, MSI_ADDR_DEST_ID_MASK); + uint32_t full_dest =3D hvm_ext_dest_id_active(d) ? MSI_ADDR_DEST(tmp)= : dest; uint8_t dest_mode =3D !!(tmp & MSI_ADDR_DESTMODE_MASK); uint8_t delivery_mode =3D (data & MSI_DATA_DELIVERY_MODE_MASK) >> MSI_DATA_DELIVERY_MODE_SHIFT; @@ -412,7 +413,8 @@ int hvm_inject_msi(struct domain *d, uint64_t addr, ui= nt32_t data) return -ERANGE; } =20 - return vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_m= ode); + return vmsi_deliver(d, vector, full_dest, dest_mode, delivery_mode, + trig_mode); } =20 void hvm_set_callback_via(struct domain *d, uint64_t via) diff --git a/xen/arch/x86/hvm/vioapic=2Ec b/xen/arch/x86/hvm/vioapic=2Ec index 80dc9148a9=2E=2Eca9b34d3ea 100644 --- a/xen/arch/x86/hvm/vioapic=2Ec +++ b/xen/arch/x86/hvm/vioapic=2Ec @@ -39,6 +39,7 @@ #include #include #include +#include =20 /* HACK: Route IRQ0 only to VCPU0 to prevent time jumps=2E */ #define IRQ0_SPECIAL_ROUTING 1 @@ -413,7 +414,9 @@ static void ioapic_inj_irq( =20 static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin= ) { - uint16_t dest =3D vioapic->redirtbl[pin]=2Efields=2Edest_id; + union vioapic_redir_entry rte =3D vioapic->redirtbl[pin]; + uint32_t dest =3D hvm_ext_dest_id_active(vioapic_domain(vioapic)) + ? VIOAPIC_RTE_DEST(rte) : rte=2Efields=2Edest_id; uint8_t dest_mode =3D vioapic->redirtbl[pin]=2Efields=2Edest_mode; uint8_t delivery_mode =3D vioapic->redirtbl[pin]=2Efields=2Edelivery_= mode; uint8_t vector =3D vioapic->redirtbl[pin]=2Efields=2Evector; diff --git a/xen/arch/x86/hvm/vmsi=2Ec b/xen/arch/x86/hvm/vmsi=2Ec index 6966cabfa7=2E=2Eeede42a202 100644 --- a/xen/arch/x86/hvm/vmsi=2Ec +++ b/xen/arch/x86/hvm/vmsi=2Ec @@ -67,7 +67,7 @@ static void vmsi_inj_irq( =20 int vmsi_deliver( struct domain *d, int vector, - uint8_t dest, uint8_t dest_mode, + uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, uint8_t trig_mode) { struct vlapic *target; @@ -111,7 +111,9 @@ void vmsi_deliver_pirq(struct domain *d, const struct = hvm_pirq_dpci *pirq_dpci) uint64_t addr =3D pirq_dpci->gmsi=2Eaddr; uint32_t data =3D pirq_dpci->gmsi=2Edata; unsigned int vector =3D MASK_EXTR(data, MSI_DATA_VECTOR_MASK); - uint32_t dest =3D MSI_ADDR_DEST(addr); + uint32_t dest =3D hvm_ext_dest_id_active(d) + ? MSI_ADDR_DEST(addr) + : MASK_EXTR(addr, MSI_ADDR_DEST_ID_MASK); bool dest_mode =3D addr & MSI_ADDR_DESTMODE_MASK; unsigned int delivery_mode =3D MASK_EXTR(data, MSI_DATA_DELIVERY_MODE= _MASK); bool trig_mode =3D data & MSI_DATA_TRIGGER_MASK; @@ -127,7 +129,7 @@ void vmsi_deliver_pirq(struct domain *d, const struct = hvm_pirq_dpci *pirq_dpci) } =20 /* Return value, -1 : multi-dests, non-negative value: dest_vcpu_id */ -int hvm_girq_dest_2_vcpu_id(struct domain *d, uint8_t dest, uint8_t dest_= mode) +int hvm_girq_dest_2_vcpu_id(struct domain *d, uint32_t dest, uint8_t dest= _mode) { int dest_vcpu_id =3D -1, w =3D 0; struct vcpu *v; diff --git a/xen/arch/x86/include/asm/hvm/domain=2Eh b/xen/arch/x86/includ= e/asm/hvm/domain=2Eh index dd7fa96aad=2E=2E16f0586907 100644 --- a/xen/arch/x86/include/asm/hvm/domain=2Eh +++ b/xen/arch/x86/include/asm/hvm/domain=2Eh @@ -102,6 +102,19 @@ struct hvm_domain { =20 bool is_s3_suspended; =20 + /* + * Whether extended (15-bit) MSI / IO-APIC destination IDs are honour= ed for + * this domain=2E Tri-state: EXT_DEST_ID_UNSET until the value is loc= ked (at + * creation_finished, or restored from a migration stream)=2E Afterwa= rds it + * is a stable, guest-visible property advertised through + * XEN_HVM_CPUID_EXT_DEST_ID=2E + */ + enum { + EXT_DEST_ID_UNSET =3D 0, + EXT_DEST_ID_DISABLED, + EXT_DEST_ID_ENABLED, + } ext_dest_id; + /* Compatibility setting for a bug in x2APIC LDR */ bool bug_x2apic_ldr_vcpu_id; =20 diff --git a/xen/arch/x86/include/asm/hvm/hvm=2Eh b/xen/arch/x86/include/a= sm/hvm/hvm=2Eh index 16383e1084=2E=2Ecedaa28820 100644 --- a/xen/arch/x86/include/asm/hvm/hvm=2Eh +++ b/xen/arch/x86/include/asm/hvm/hvm=2Eh @@ -296,11 +296,19 @@ uint64_t hvm_get_guest_time_fixed(const struct vcpu = *v, uint64_t at_tsc); =20 int vmsi_deliver( struct domain *d, int vector, - uint8_t dest, uint8_t dest_mode, + uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, uint8_t trig_mode); struct hvm_pirq_dpci; void vmsi_deliver_pirq(struct domain *d, const struct hvm_pirq_dpci *pirq= _dpci); -int hvm_girq_dest_2_vcpu_id(struct domain *d, uint8_t dest, uint8_t dest_= mode); +int hvm_girq_dest_2_vcpu_id(struct domain *d, uint32_t dest, uint8_t dest= _mode); + +/* + * True when this domain has extended (15-bit) MSI / IO-APIC destination = IDs + * enabled=2E Only then may address[11:5] / RTE[55:49] be folded into the + * destination ID=2E + */ +#define hvm_ext_dest_id_active(d) \ + ((d)->arch=2Ehvm=2Eext_dest_id =3D=3D EXT_DEST_ID_ENABLED) =20 enum hvm_intblk hvm_interrupt_blocked(struct vcpu *v, struct hvm_intack intack); diff --git a/xen/arch/x86/include/asm/hvm/vioapic=2Eh b/xen/arch/x86/inclu= de/asm/hvm/vioapic=2Eh index 68af6dce79=2E=2E3df2aa7fe5 100644 --- a/xen/arch/x86/include/asm/hvm/vioapic=2Eh +++ b/xen/arch/x86/include/asm/hvm/vioapic=2Eh @@ -32,6 +32,16 @@ #define VIOAPIC_EDGE_TRIG 0 #define VIOAPIC_LEVEL_TRIG 1 =20 +/* + * Combined 15-bit destination ID of an IO-APIC redirection table entry: = the + * architectural dest_id byte plus the 7 "Extended Destination ID" bits= =2E The + * caller is responsible for only using the extended part when the guest = has + * opted in (hvm_ext_dest_id_active())=2E + */ +#define VIOAPIC_RTE_DEST(rte) \ + ((rte)=2Efields=2Edest_id | \ + ((uint32_t)(rte)=2Efields=2Eext_dest_id << MSI_ADDR_DEST_ID_WIDTH)) + #define VIOAPIC_DEFAULT_BASE_ADDRESS 0xfec00000U #define VIOAPIC_MEM_LENGTH 0x100 =20 diff --git a/xen/drivers/passthrough/x86/hvm=2Ec b/xen/drivers/passthrough= /x86/hvm=2Ec index bdab065eb7=2E=2Ea13dd86610 100644 --- a/xen/drivers/passthrough/x86/hvm=2Ec +++ b/xen/drivers/passthrough/x86/hvm=2Ec @@ -380,7 +380,8 @@ int pt_irq_bind_msi(struct domain *d, unsigned int mac= hine_irq, =20 /* Calculate dest_vcpu_id for MSI-type pirq migration=2E */ gvec =3D MASK_EXTR(msi_data, MSI_DATA_VECTOR_MASK); - dest =3D MSI_ADDR_DEST(msi_addr); + dest =3D hvm_ext_dest_id_active(d) ? MSI_ADDR_DEST(msi_addr) + : MASK_EXTR(msi_addr, MSI_ADDR_DEST_= ID_MASK); dest_mode =3D msi_addr & MSI_ADDR_DESTMODE_MASK; delivery_mode =3D MASK_EXTR(msi_data, MSI_DATA_DELIVERY_MODE_MASK); =20 @@ -883,7 +884,10 @@ static int cf_check _hvm_dpci_msi_eoi( if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) && MASK_EXTR(pirq_dpci->gmsi=2Edata, MSI_DATA_VECTOR_MASK) =3D=3D v= ector ) { - unsigned int dest =3D MSI_ADDR_DEST(pirq_dpci->gmsi=2Eaddr); + unsigned int dest =3D hvm_ext_dest_id_active(d) + ? MSI_ADDR_DEST(pirq_dpci->gmsi=2Eaddr) + : MASK_EXTR(pirq_dpci->gmsi=2Eaddr, + MSI_ADDR_DEST_ID_MASK); bool dest_mode =3D pirq_dpci->gmsi=2Eaddr & MSI_ADDR_DESTMODE_MAS= K; =20 if ( vlapic_match_dest(vcpu_vlapic(current), NULL, 0, dest, diff --git a/xen/include/public/arch-x86/hvm/save=2Eh b/xen/include/public= /arch-x86/hvm/save=2Eh index 44d7924777=2E=2Eff73b83d65 100644 --- a/xen/include/public/arch-x86/hvm/save=2Eh +++ b/xen/include/public/arch-x86/hvm/save=2Eh @@ -359,7 +359,9 @@ union vioapic_redir_entry uint8_t trig_mode:1; uint8_t mask:1; uint8_t reserve:7; - uint8_t reserved[4]; + uint8_t reserved[3]; + uint8_t reserved2:1; + uint8_t ext_dest_id:7; uint8_t dest_id; } fields; }; --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35ab.e5d7a6729895094a.1a0679ed81d.65b008e6a50fbf51=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407264.1640408 (Exim 4.92) (envelope-from ) id 1x28D9-0007I9-Qf; Thu, 03 Sep 2026 14:14:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407264.1640408; Thu, 03 Sep 2026 14:14:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D9-0007Hp-MJ; Thu, 03 Sep 2026 14:14:39 +0000 Received: by outflank-mailman (input) for mailman id 1407264; Thu, 03 Sep 2026 14:14:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28D8-00078B-Dn for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28D7-001HAI-Qu for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:37 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980bd-2eae-0a2a0a5409dd-0a2a4505c668-36 for ; Thu, 03 Sep 2026 16:14:37 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980cb-4cb1-0a2a45050019-b9ff1c228579-4 for ; Thu, 03 Sep 2026 16:14:37 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679edb8f000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:19 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 7E94984012; Thu, 3 Sep 2026 16:14:18 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=wLovsWfA/SxNUKrf8umHetWd6JDKT68QQwT/Ms2jeAk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=nP/sr+vGFFJkyZ1VAg1SeINQH707ziL54maQHXOn7GQMnHAqtoCFWamVjGWkxEOkPvj+TVt0R KRD7haz3aps6W8Cb2b7pSCTD47WerHMg1zja7TAedeDxKAM/nb6cFCNW672KW/PfFqZuzoZH5D+ ruI6L2h3485vn9z++x6LYq5V9FEMgaX+cZB1e5QxumEUuxAYWRfJyUDhk89+LlnXgE1ErgR1RyT 7rDBcJOkjXbQ/aJhab8N2BJgDJKlcp1xOIe2fX1AsS05iJ8O+rYmv7Fwec3Zcur7B41Vf4C4YSW yNwGmHK+VRDACtBNYmzxwaKjSR5M13AHdAneSFqROsHA== X-Zone-Loop: 7533775c6bc53995e4466ee2d95ddc3d244e45d80323 x-campaign-type: default x-transaction-id: 7c40deaf-f49d-44da-93ee-702d62ae6c1e x-swg-uid: 01-58aa0035-e02e-4b8b-aaaa-cff792b813e4 X-Mailer: Sweego Message-ID: <1788444859.8631fc262581453bbf619ec5b2062170.1a0679edb8f000c4f3@vates.tech> x-swg-bid: 1788444859.8631fc262581453bbf619ec5b2062170.1a0679edb8f000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 09/11] x86/dmop: Add XEN_DMOP_{,un}bind_pt_msi_irq Date: Thu, 3 Sep 2026 16:14:07 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35ac.4cbeb03216e9d1fc.1a0679ed967.91135d8424a5c29e=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444858727 X-purgate-ID: tlsNG-c201ff/1788444877-730B22A1-2246DCEF/0/0 X-purgate-type: clean X-purgate-size: 21254 ---=Part.35ac.4cbeb03216e9d1fc.1a0679ed967.91135d8424a5c29e=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Add two device-model ops that bind / unbind a passthrough interrupt to a guest MSI from the raw MSI message (address + data) the guest programmed=2E Xen decodes the message itself via pt_irq_bind_msi(), so the emulator needs no knowledge of the MSI layout and, in particular, extended (15-bit) destination IDs are handled without emulator changes=2E The MSI-X table base is passed as a guest-physical address=2E Fields are named msg_addr / msg_data / pirq, and the flag is XEN_DMOP_MSI_BIND_UNMASKED=2E The unbind op only requires a valid pirq mapping, not current IRQ permission, so an emulator can remove a binding even after the device has been deassigned=2E With this in place, PT_IRQ_TYPE_MSI is removed from XEN_DOMCTL_{,un}bind_pt_irq (returns -EINVAL) and from pt_irq_create_bind()=2E libxc's xc_domain_{update,unbind}_msi_irq() and vPCI already funnel through pt_irq_bind_msi()=2E This is an incompatible change for device models still using the domctl sub-case (noted in CHANGELOG=2Emd and public/domctl=2Eh)=2E libxendevicemodel gains xendevicemodel_{,un}bind_pt_msi_irq() (map version VERS_1=2E5)=2E Signed-off-by: Julian Vetter --- Changes in v5: - Retitled to "{,un}bind_pt_msi_irq"=2E - Struct/flag renamed: pirq (was machine_irq), msg_addr / msg_data (was addr / data), XEN_DMOP_MSI_BIND_UNMASKED (was XEN_DMOP_MSI_FLAG_UNMASKED)=2E - Documented gtable as a guest-physical address=2E - Diagnostics shortened to "%pd: fn() failed: %ld"=2E - The unbind op drops the current-domain IRQ-permission check, so an emulator can unbind after the device has been deassigned=2E - Comment added noting access is gated by xsm_dm_op()=2E - This patch now also removes PT_IRQ_TYPE_MSI: a hard -EINVAL from XEN_DOMCTL_{,un}bind_pt_irq (not -EOPNOTSUPP) and deletion of the now-dead case from pt_irq_create_bind() - Incompatible changes are recorded in CHANGELOG=2Emd and public/domctl=2E= h=2E - Added the missing libxendevicemodel=2Emap VERS_1=2E5 entry and Makefile MINOR bump=2E v4 never exported the new symbols=2E - Stale XEN_DMOP_enable_ext_dest_id #define and a stray blank line before a typedef removed=2E Signed-off-by: Julian Vetter --- CHANGELOG=2Emd | 6 ++ tools/include/xendevicemodel=2Eh | 30 +++++++++ tools/libs/ctrl/xc_domain=2Ec | 51 +++++++-------- tools/libs/devicemodel/Makefile | 2 +- tools/libs/devicemodel/core=2Ec | 38 +++++++++++ tools/libs/devicemodel/libxendevicemodel=2Emap | 6 ++ xen/arch/x86/domctl=2Ec | 11 +++- xen/arch/x86/hvm/dm=2Ec | 66 ++++++++++++++++++++ xen/drivers/passthrough/x86/hvm=2Ec | 35 +---------- xen/include/public/hvm/dm_op=2Eh | 38 +++++++++++ xen/include/xlat=2Elst | 2 + 11 files changed, 221 insertions(+), 64 deletions(-) diff --git a/CHANGELOG=2Emd b/CHANGELOG=2Emd index aa1a777dd4=2E=2E76f5d06c91 100644 --- a/CHANGELOG=2Emd +++ b/CHANGELOG=2Emd @@ -34,6 +34,9 @@ The format is based on [Keep a Changelog](https://keepac= hangelog=2Ecom/en/1=2E0=2E0/) - On x86: - Enable pf-fixup option by default for PVH dom0=2E - The libxenguest bzImage loader now uses the system liblz4 library=2E + - XEN_DOMCTL_{,un}bind_pt_irq no longer accept PT_IRQ_TYPE_MSI, device + models must bind passthrough MSIs via the new + XEN_DMOP_{,un}bind_pt_msi_irq, which carry the raw MSI message=2E =20 ### Added - Support for per-domain Xenstore quota in C xenstored (includes @@ -47,6 +50,9 @@ The format is based on [Keep a Changelog](https://keepac= hangelog=2Ecom/en/1=2E0=2E0/) - Support for CPIO microcode in discrete multiboot modules=2E - Introduce get-core-temp command to xenpm to query CPU temperatures o= n Intel platforms=2E + - XEN_DMOP_{,un}bind_pt_msi_irq for binding passthrough MSIs from the = raw + guest MSI message, enabling extended (15-bit) destination IDs for HV= M + guests whose device models opt in=2E =20 - On Arm: - Support for guest suspend and resume to/from RAM via vPSCI=2E diff --git a/tools/include/xendevicemodel=2Eh b/tools/include/xendevicemod= el=2Eh index 227e7fd810=2E=2E698d719119 100644 --- a/tools/include/xendevicemodel=2Eh +++ b/tools/include/xendevicemodel=2Eh @@ -375,6 +375,36 @@ int xendevicemodel_nr_vcpus( */ int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid); =20 +/** + * This function binds a passthrough interrupt to a guest MSI, described = by the + * raw MSI message (address and data) the guest programmed=2E Xen decodes= the + * message itself, so the caller does not need to interpret it=2E + * + * @parm dmod a handle to an open devicemodel interface=2E + * @parm domid the domain id to be serviced=2E + * @parm pirq the pass-through IRQ (pirq)=2E + * @parm msg_addr the MSI message address, as programmed by the guest=2E + * @parm msg_data the MSI message data, as programmed by the guest=2E + * @parm gtable the MSI-X table base guest-physical address, or 0 for pla= in MSI=2E + * @parm unmasked if non-zero, leave the IRQ unmasked after binding=2E + * @return 0 on success, -1 on failure=2E + */ +int xendevicemodel_bind_pt_msi_irq( + xendevicemodel_handle *dmod, domid_t domid, uint32_t pirq, + uint64_t msg_addr, uint32_t msg_data, uint64_t gtable, int unmasked); + +/** + * This function unbinds a passthrough interrupt previously bound with + * xendevicemodel_bind_pt_msi_irq=2E + * + * @parm dmod a handle to an open devicemodel interface=2E + * @parm domid the domain id to be serviced=2E + * @parm pirq the pass-through IRQ (pirq)=2E + * @return 0 on success, -1 on failure=2E + */ +int xendevicemodel_unbind_pt_msi_irq( + xendevicemodel_handle *dmod, domid_t domid, uint32_t pirq); + #endif /* XENDEVICEMODEL_H */ =20 /* diff --git a/tools/libs/ctrl/xc_domain=2Ec b/tools/libs/ctrl/xc_domain=2Ec index 94cfab0fa1=2E=2Eb4eed42f97 100644 --- a/tools/libs/ctrl/xc_domain=2Ec +++ b/tools/libs/ctrl/xc_domain=2Ec @@ -1677,6 +1677,21 @@ int xc_deassign_dt_device( =20 =20 =20 +static void xc_msi_gflags_to_addr_data(uint32_t gvec, uint32_t gflags, + uint64_t *msi_addr, uint32_t *msi= _data) +{ + *msi_addr =3D 0xfee00000U | + ((uint64_t)((gflags & XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) << 12)) | + (gflags & XEN_DOMCTL_VMSI_X86_RH_MASK ? (1U << 3) : 0) | + (gflags & XEN_DOMCTL_VMSI_X86_DM_MASK ? (1U << 2) : 0); + + *msi_data =3D (gvec & 0xff) | + (uint32_t)(((gflags & XEN_DOMCTL_VMSI_X86_DELIV_MASK) >> + (/* shift of XEN_DOMCTL_VMSI_X86_DELIV_MASK */ 12 - + /* MSI data delivery shift */ 8))) | + (gflags & XEN_DOMCTL_VMSI_X86_TRIG_MASK ? (1U << 15) : 0); +} + int xc_domain_update_msi_irq( xc_interface *xch, uint32_t domid, @@ -1685,22 +1700,14 @@ int xc_domain_update_msi_irq( uint32_t gflags, uint64_t gtable) { - int rc; - struct xen_domctl_bind_pt_irq *bind; - struct xen_domctl domctl =3D {}; - - domctl=2Ecmd =3D XEN_DOMCTL_bind_pt_irq; - domctl=2Edomain =3D domid; + uint64_t msi_addr; + uint32_t msi_data; =20 - bind =3D &(domctl=2Eu=2Ebind_pt_irq); - bind->irq_type =3D PT_IRQ_TYPE_MSI; - bind->machine_irq =3D pirq; - bind->u=2Emsi=2Egvec =3D gvec; - bind->u=2Emsi=2Egflags =3D gflags; - bind->u=2Emsi=2Egtable =3D gtable; + xc_msi_gflags_to_addr_data(gvec, gflags, &msi_addr, &msi_data); =20 - rc =3D do_domctl(xch, &domctl); - return rc; + return xendevicemodel_bind_pt_msi_irq(xch->dmod, domid, pirq, + msi_addr, msi_data, gtable, + gflags & XEN_DOMCTL_VMSI_X86_UN= MASKED); } =20 int xc_domain_unbind_msi_irq( @@ -1710,21 +1717,7 @@ int xc_domain_unbind_msi_irq( uint32_t pirq, uint32_t gflags) { - int rc; - struct xen_domctl_bind_pt_irq *bind; - struct xen_domctl domctl =3D {}; - - domctl=2Ecmd =3D XEN_DOMCTL_unbind_pt_irq; - domctl=2Edomain =3D domid; - - bind =3D &(domctl=2Eu=2Ebind_pt_irq); - bind->irq_type =3D PT_IRQ_TYPE_MSI; - bind->machine_irq =3D pirq; - bind->u=2Emsi=2Egvec =3D gvec; - bind->u=2Emsi=2Egflags =3D gflags; - - rc =3D do_domctl(xch, &domctl); - return rc; + return xendevicemodel_unbind_pt_msi_irq(xch->dmod, domid, pirq); } =20 /* Pass-through: binds machine irq to guests irq */ diff --git a/tools/libs/devicemodel/Makefile b/tools/libs/devicemodel/Make= file index 20d1d112e7=2E=2E270bb6c89f 100644 --- a/tools/libs/devicemodel/Makefile +++ b/tools/libs/devicemodel/Makefile @@ -2,7 +2,7 @@ XEN_ROOT =3D $(CURDIR)/=2E=2E/=2E=2E/=2E=2E include $(XEN_ROOT)/tools/Rules=2Emk =20 MAJOR =3D 1 -MINOR =3D 4 +MINOR =3D 5 version-script :=3D libxendevicemodel=2Emap =20 include Makefile=2Ecommon diff --git a/tools/libs/devicemodel/core=2Ec b/tools/libs/devicemodel/core= =2Ec index 8e619eeb0a=2E=2E274a8eb28b 100644 --- a/tools/libs/devicemodel/core=2Ec +++ b/tools/libs/devicemodel/core=2Ec @@ -645,6 +645,44 @@ int xendevicemodel_nr_vcpus( return 0; } =20 +int xendevicemodel_bind_pt_msi_irq( + xendevicemodel_handle *dmod, domid_t domid, uint32_t pirq, + uint64_t msg_addr, uint32_t msg_data, uint64_t gtable, int unmasked) +{ + struct xen_dm_op op; + struct xen_dm_op_bind_pt_msi_irq *data; + + memset(&op, 0, sizeof(op)); + + op=2Eop =3D XEN_DMOP_bind_pt_msi_irq; + data =3D &op=2Eu=2Ebind_pt_msi_irq; + + data->pirq =3D pirq; + data->msg_data =3D msg_data; + data->msg_addr =3D msg_addr; + data->gtable =3D gtable; + if ( unmasked ) + data->flags |=3D XEN_DMOP_MSI_BIND_UNMASKED; + + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); +} + +int xendevicemodel_unbind_pt_msi_irq( + xendevicemodel_handle *dmod, domid_t domid, uint32_t pirq) +{ + struct xen_dm_op op; + struct xen_dm_op_unbind_pt_msi_irq *data; + + memset(&op, 0, sizeof(op)); + + op=2Eop =3D XEN_DMOP_unbind_pt_msi_irq; + data =3D &op=2Eu=2Eunbind_pt_msi_irq; + + data->pirq =3D pirq; + + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); +} + int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid) { return osdep_xendevicemodel_restrict(dmod, domid); diff --git a/tools/libs/devicemodel/libxendevicemodel=2Emap b/tools/libs/d= evicemodel/libxendevicemodel=2Emap index f7f9e3d932=2E=2Ec34b66004e 100644 --- a/tools/libs/devicemodel/libxendevicemodel=2Emap +++ b/tools/libs/devicemodel/libxendevicemodel=2Emap @@ -44,3 +44,9 @@ VERS_1=2E4 { xendevicemodel_set_irq_level; xendevicemodel_nr_vcpus; } VERS_1=2E3; + +VERS_1=2E5 { + global: + xendevicemodel_bind_pt_msi_irq; + xendevicemodel_unbind_pt_msi_irq; +} VERS_1=2E4; diff --git a/xen/arch/x86/domctl=2Ec b/xen/arch/x86/domctl=2Ec index 51d62617bb=2E=2E9846df4f88 100644 --- a/xen/arch/x86/domctl=2Ec +++ b/xen/arch/x86/domctl=2Ec @@ -622,6 +622,15 @@ long arch_do_domctl( if ( !is_hvm_domain(d) ) break; =20 + /* + * PT_IRQ_TYPE_MSI is no longer supported here: it can only conve= y an + * 8-bit destination ID=2E Emulators must use XEN_DMOP_bind_pt_ms= i_irq, + * which passes the raw MSI message so Xen can decode it (extende= d + * destination IDs included)=2E + */ + if ( bind->irq_type =3D=3D PT_IRQ_TYPE_MSI ) + break; + ret =3D xsm_bind_pt_irq(XSM_DM_PRIV, d, bind); if ( ret ) break; @@ -657,7 +666,7 @@ long arch_do_domctl( int irq =3D domain_pirq_to_irq(d, bind->machine_irq); =20 ret =3D -EINVAL; - if ( !is_hvm_domain(d) ) + if ( !is_hvm_domain(d) || bind->irq_type =3D=3D PT_IRQ_TYPE_MSI ) break; =20 ret =3D xsm_unbind_pt_irq(XSM_DM_PRIV, d, bind); diff --git a/xen/arch/x86/hvm/dm=2Ec b/xen/arch/x86/hvm/dm=2Ec index 91f6ca669b=2E=2E9a6347e873 100644 --- a/xen/arch/x86/hvm/dm=2Ec +++ b/xen/arch/x86/hvm/dm=2Ec @@ -7,6 +7,8 @@ #include #include #include +#include +#include #include #include #include @@ -350,6 +352,8 @@ int dm_op(const struct dmop_args *op_args) [XEN_DMOP_relocate_memory] =3D sizeof(struct xen= _dm_op_relocate_memory), [XEN_DMOP_pin_memory_cacheattr] =3D sizeof(struct xen= _dm_op_pin_memory_cacheattr), [XEN_DMOP_nr_vcpus] =3D sizeof(struct xen= _dm_op_nr_vcpus), + [XEN_DMOP_bind_pt_msi_irq] =3D sizeof(struct xen= _dm_op_bind_pt_msi_irq), + [XEN_DMOP_unbind_pt_msi_irq] =3D sizeof(struct xen= _dm_op_unbind_pt_msi_irq), }; =20 rc =3D rcu_lock_remote_domain_by_id(op_args->domid, &d); @@ -617,6 +621,66 @@ int dm_op(const struct dmop_args *op_args) break; } =20 + case XEN_DMOP_bind_pt_msi_irq: + { + const struct xen_dm_op_bind_pt_msi_irq *data =3D &op=2Eu=2Ebind_p= t_msi_irq; + int irq =3D domain_pirq_to_irq(d, data->pirq); + + rc =3D -EINVAL; + if ( data->pad || (data->flags & ~XEN_DMOP_MSI_BIND_UNMASKED) ) + break; + + /* Access is otherwise gated by xsm_dm_op() at the top of dm_op()= =2E */ + rc =3D -EPERM; + if ( irq <=3D 0 || !irq_access_permitted(current->domain, irq) ) + break; + + rc =3D -ESRCH; + if ( is_iommu_enabled(d) ) + { + read_lock(&d->pci_lock); + rc =3D pt_irq_bind_msi(d, data->pirq, data->msg_addr, data->m= sg_data, + data->gtable, + data->flags & XEN_DMOP_MSI_BIND_UNMASKED= ); + read_unlock(&d->pci_lock); + } + if ( rc < 0 ) + printk(XENLOG_G_ERR "%pd: pt_irq_bind_msi() failed: %ld\n", d= , rc); + break; + } + + case XEN_DMOP_unbind_pt_msi_irq: + { + const struct xen_dm_op_unbind_pt_msi_irq *data =3D + &op=2Eu=2Eunbind_pt_msi_irq; + struct xen_domctl_bind_pt_irq bind =3D { + =2Emachine_irq =3D data->pirq, + =2Eirq_type =3D PT_IRQ_TYPE_MSI, + }; + int irq =3D domain_pirq_to_irq(d, data->pirq); + + /* + * Only require a valid pirq mapping, not current permission over= it: + * the emulator must be able to tear the binding down even after = the + * device (and its IRQ) has been deassigned=2E + */ + rc =3D -EPERM; + if ( irq <=3D 0 ) + break; + + rc =3D -ESRCH; + if ( is_iommu_enabled(d) ) + { + read_lock(&d->pci_lock); + rc =3D pt_irq_destroy_bind(d, &bind); + read_unlock(&d->pci_lock); + } + if ( rc < 0 ) + printk(XENLOG_G_ERR "%pd: pt_irq_destroy_bind() failed: %ld\n= ", + d, rc); + break; + } + default: rc =3D ioreq_server_dm_op(&op, d, &const_op); break; @@ -653,6 +717,8 @@ CHECK_dm_op_remote_shutdown; CHECK_dm_op_relocate_memory; CHECK_dm_op_pin_memory_cacheattr; CHECK_dm_op_nr_vcpus; +CHECK_dm_op_bind_pt_msi_irq; +CHECK_dm_op_unbind_pt_msi_irq; =20 int compat_dm_op( domid_t domid, unsigned int nr_bufs, XEN_GUEST_HANDLE_PARAM(void) buf= s) diff --git a/xen/drivers/passthrough/x86/hvm=2Ec b/xen/drivers/passthrough= /x86/hvm=2Ec index a13dd86610=2E=2Ec5d74fcebf 100644 --- a/xen/drivers/passthrough/x86/hvm=2Ec +++ b/xen/drivers/passthrough/x86/hvm=2Ec @@ -449,37 +449,6 @@ int pt_irq_create_bind( =20 switch ( pt_irq_bind->irq_type ) { - case PT_IRQ_TYPE_MSI: - { - unsigned int gflags =3D pt_irq_bind->u=2Emsi=2Egflags; - uint64_t msi_addr; - uint32_t msi_data; - - /* - * Rebuild a raw MSI message from the pre-decoded domctl gflags s= o the - * canonical bind path can decode it uniformly=2E This legacy pat= h never - * carries extended destination ID bits=2E - */ - msi_addr =3D MSI_ADDR_HEADER | - MASK_INSR(MASK_EXTR(gflags, XEN_DOMCTL_VMSI_X86_DEST_I= D_MASK), - MSI_ADDR_DEST_ID_MASK) | - (gflags & XEN_DOMCTL_VMSI_X86_RH_MASK - ? MSI_ADDR_REDIRECTION_LOWPRI - : MSI_ADDR_REDIRECTION_CPU) | - (gflags & XEN_DOMCTL_VMSI_X86_DM_MASK - ? MSI_ADDR_DESTMODE_LOGIC - : MSI_ADDR_DESTMODE_PHYS); - msi_data =3D MASK_INSR(pt_irq_bind->u=2Emsi=2Egvec, MSI_DATA_VECT= OR_MASK) | - MASK_INSR(MASK_EXTR(gflags, XEN_DOMCTL_VMSI_X86_DELIV_= MASK), - MSI_DATA_DELIVERY_MODE_MASK) | - (gflags & XEN_DOMCTL_VMSI_X86_TRIG_MASK - ? MSI_DATA_TRIGGER_LEVEL : 0); - - return pt_irq_bind_msi(d, pt_irq_bind->machine_irq, msi_addr, msi= _data, - pt_irq_bind->u=2Emsi=2Egtable, - gflags & XEN_DOMCTL_VMSI_X86_UNMASKED); - } - case PT_IRQ_TYPE_PCI: case PT_IRQ_TYPE_MSI_TRANSLATE: { @@ -767,8 +736,8 @@ int pt_irq_destroy_bind( msixtbl_pt_unregister(d, pirq); pirq_dpci->flags =3D 0; /* - * See comment in pt_irq_create_bind's PT_IRQ_TYPE_MSI before the - * call to pt_pirq_softirq_reset=2E + * See the comment in pt_irq_bind_msi() before its call to + * pt_pirq_softirq_reset=2E */ pt_pirq_softirq_reset(pirq_dpci); =20 diff --git a/xen/include/public/hvm/dm_op=2Eh b/xen/include/public/hvm/dm_= op=2Eh index 2bf0fdc1ae=2E=2Ed76777f71f 100644 --- a/xen/include/public/hvm/dm_op=2Eh +++ b/xen/include/public/hvm/dm_op=2Eh @@ -444,6 +444,42 @@ struct xen_dm_op_nr_vcpus { }; typedef struct xen_dm_op_nr_vcpus xen_dm_op_nr_vcpus_t; =20 +/* + * XEN_DMOP_bind_pt_msi_irq: bind a passthrough interrupt to a guest MSI, + * described by the raw MSI message (address and data) the guest programm= ed=2E + * Xen decodes the message itself, so the emulator does not need to know = the + * MSI layout and, in particular, extended destination IDs are handled + * transparently=2E + */ +#define XEN_DMOP_bind_pt_msi_irq 21 + +struct xen_dm_op_bind_pt_msi_irq { + /* IN - pirq */ + uint32_t pirq; + /* IN - MSI message data word */ + uint32_t msg_data; + /* IN - bind flags */ + uint32_t flags; +#define XEN_DMOP_MSI_BIND_UNMASKED (1u << 0) + uint32_t pad; + /* IN - MSI message address */ + uint64_aligned_t msg_addr; + /* IN - MSI-X table base address (guest physical), 0 for plain MSI */ + uint64_aligned_t gtable; +}; +typedef struct xen_dm_op_bind_pt_msi_irq xen_dm_op_bind_pt_msi_irq_t; + +/* + * XEN_DMOP_unbind_pt_msi_irq: undo a previous XEN_DMOP_bind_pt_msi_irq= =2E + */ +#define XEN_DMOP_unbind_pt_msi_irq 22 + +struct xen_dm_op_unbind_pt_msi_irq { + /* IN - pirq */ + uint32_t pirq; +}; +typedef struct xen_dm_op_unbind_pt_msi_irq xen_dm_op_unbind_pt_msi_irq_t; + struct xen_dm_op { uint32_t op; uint32_t pad; @@ -468,6 +504,8 @@ struct xen_dm_op { xen_dm_op_relocate_memory_t relocate_memory; xen_dm_op_pin_memory_cacheattr_t pin_memory_cacheattr; xen_dm_op_nr_vcpus_t nr_vcpus; + xen_dm_op_bind_pt_msi_irq_t bind_pt_msi_irq; + xen_dm_op_unbind_pt_msi_irq_t unbind_pt_msi_irq; } u; }; =20 diff --git a/xen/include/xlat=2Elst b/xen/include/xlat=2Elst index 33dc8e2b2a=2E=2E7255f4c65d 100644 --- a/xen/include/xlat=2Elst +++ b/xen/include/xlat=2Elst @@ -98,6 +98,7 @@ ? grant_entry_v2 grant_table=2Eh =20 ! dm_op_buf hvm/dm_op=2Eh +? dm_op_bind_pt_msi_irq hvm/dm_op=2Eh ? dm_op_create_ioreq_server hvm/dm_op=2Eh ? dm_op_destroy_ioreq_server hvm/dm_op=2Eh ? dm_op_get_ioreq_server_info hvm/dm_op=2Eh @@ -116,6 +117,7 @@ ? dm_op_set_pci_intx_level hvm/dm_op=2Eh ? dm_op_set_pci_link_route hvm/dm_op=2Eh ? dm_op_track_dirty_vram hvm/dm_op=2Eh +? dm_op_unbind_pt_msi_irq hvm/dm_op=2Eh =20 ! hvm_altp2m_set_mem_access_multi hvm/hvm_op=2Eh =20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35ac.4cbeb03216e9d1fc.1a0679ed967.91135d8424a5c29e=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407267.1640417 (Exim 4.92) (envelope-from ) id 1x28DC-0007e6-Cu; Thu, 03 Sep 2026 14:14:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407267.1640417; Thu, 03 Sep 2026 14:14: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 1x28DC-0007dj-7W; Thu, 03 Sep 2026 14:14:42 +0000 Received: by outflank-mailman (input) for mailman id 1407267; Thu, 03 Sep 2026 14:14:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28DA-0007Ru-PS for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28DA-001HAI-65 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:40 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980bd-2eae-0a2a0a5409dd-0a2a4505c668-38 for ; Thu, 03 Sep 2026 16:14:40 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980cb-4cb1-0a2a45050019-b9ff1c228579-5 for ; Thu, 03 Sep 2026 16:14:40 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679edcb9000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:19 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id E7C2284011; Thu, 3 Sep 2026 16:14:18 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=X+GMiNwPDnM2Yn/cscWUSLUInDV4hAIUbO0QY9cSEz4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=n6A6v6OJRPpxsRHL71sjEiq/CHSlVnz+nKDoDsIiz3MqZ/jhYsSQlnu6A5caPcT/OvpVeVDOu USNAnUvh6GH8PSJmeS7vOrBOfbJnuwk8kYwFj3or4ew6W/bX1g9EgXJ5XSvCOoYDj6/ece+Ywu9 2pYOVatCAxEn6lCBrwNEVuDjKYPf3XMfeZLG5kX00pmNA4avO0dzEfqxOFoUtDK2A9br4vhjudJ l//JdSFanSu2I3TFqz1v2pLKxws+Z4k/h4Z2vhSRGRgILYtJ/ePp9jurvsVNYPmaVvDTwI1cOnX YWjzGEPrs5sTx0eeu7Dh5kgAXM4XVtC8ntCNZbAEdgag== X-Zone-Loop: 88865dbdf5dde7b16d5315d2b90afe816912eb9d03fb x-campaign-type: default x-transaction-id: 8fb334c3-3549-45f1-89da-701e101f6a05 x-swg-uid: 01-c0bad502-9462-4659-a18c-743f20f32cb6 X-Mailer: Sweego Message-ID: <1788444859.8631fc262581453bbf619ec5b2062170.1a0679edcb9000c4f3@vates.tech> x-swg-bid: 1788444859.8631fc262581453bbf619ec5b2062170.1a0679edcb9000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 10/11] hvm/ioreq: Negotiate extended destination ID support per ioreq server Date: Thu, 3 Sep 2026 16:14:08 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35ad.88da934c2c0754a.1a0679edb1d.ec095fd8a6ac7414=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444859165 X-purgate-ID: tlsNG-c201ff/1788444880-F66B52A1-5C04D7D4/0/0 X-purgate-type: clean X-purgate-size: 16762 ---=Part.35ad.88da934c2c0754a.1a0679edb1d.ec095fd8a6ac7414=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Extended (15-bit) MSI / IO-APIC destination IDs need Xen to decode the raw MSI message for every passthrough MSI, which in turn requires every device model to use XEN_DMOP_bind_pt_msi_irq=2E Let each ioreq server advertise that it does so: - XEN_DMOP_create_ioreq_server gains a flags byte (reusing pad[0]) with XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID=2E arch_ioreq_server_create_check() validates the flags (rejecting unknown bits, and the whole flag on non-x86) and, once the feature is locked, refuses a server that lacks it=2E - hvm_ext_dest_id_enabled() is true if at least one server exists and all of them opted in=2E arch_domain_creation_finished() latches the result into the tri-state d->arch=2Ehvm=2Eext_dest_id, unless a migratio= n stream already fixed it=2E - A new HVM_SAVE_TYPE(EXT_DEST_ID) record (with save/check/load) migrates the latched value, so the destination host behaves identically regardless of when its device model re-registers ioreq servers=2E A stream from a Xen predating the feature carries no such record=2E hvm_load() then resolves the still-UNSET state to DISABLED so arch_domain_creation_finished() does not mistake the restored domain for a fresh one and enable the feature behind an unaware guest=2E libxendevicemodel's xendevicemodel_create_ioreq_server() grows the flags argument (0 for existing callers)=2E Signed-off-by: Julian Vetter --- Changes in v5: - Commit message rewritten as a bulleted summary=2E - As discussed with Jan: The creation_finished latch only fires while it is still UNSET, so a value restored from the migration stream wins=2E v4 OR-ed hvm_ext_dest_id_enabled() onto a bool, which flipped an unaware migrated guest to ENABLED=2E - hvm_ext_dest_id_enabled() moved out of the header into common/ioreq=2Ec as a function with a locking note=2E It iterates via ARRAY_SIZE(d->ioreq_server=2Eserver), not MAX_NR_IOREQ_SERVERS=2E - Flags are unsigned int now=2E Flag-bit validation is arch-specific arch_ioreq_server_create_check() rejects unknown bits and the Arm stub rejects any non-zero flag=2E The is_hvm_domain() check is dropped from the x86 hook=2E The post-lock rejection tests EXT_DEST_ID_ENABLED explicitly=2E - The save record gains a check handler (ext_dest_id_check)=2E Load validates the enum range and returns -ENODATA on a truncated record=2E - Save-record comment de-x86-ified=2E - A stream from a Xen predating the feature carries no EXT_DEST_ID record, so hvm_load() resolves the UNSET state to DISABLED at end-of-stream=2E - Removed the vIO-APIC ioapic_check() extended-bit rejection loop=2E - Added parentheses around the bitwise logic=2E Signed-off-by: Julian Vetter --- tools/include/xendevicemodel=2Eh | 3 +- tools/libs/ctrl/xc_devicemodel_compat=2Ec | 2 +- tools/libs/devicemodel/core=2Ec | 3 +- xen/arch/arm/ioreq=2Ec | 6 +++ xen/arch/x86/domain=2Ec | 13 ++++++ xen/arch/x86/hvm/ioreq=2Ec | 57 +++++++++++++++++++++++++ xen/arch/x86/hvm/save=2Ec | 9 ++++ xen/common/ioreq=2Ec | 31 ++++++++++++-- xen/include/public/arch-x86/hvm/save=2Eh | 16 ++++++- xen/include/public/hvm/dm_op=2Eh | 13 +++++- xen/include/xen/ioreq=2Eh | 11 +++++ 11 files changed, 156 insertions(+), 8 deletions(-) diff --git a/tools/include/xendevicemodel=2Eh b/tools/include/xendevicemod= el=2Eh index 698d719119=2E=2E72994d1313 100644 --- a/tools/include/xendevicemodel=2Eh +++ b/tools/include/xendevicemodel=2Eh @@ -44,12 +44,13 @@ int xendevicemodel_close(xendevicemodel_handle *dmod); * @parm domid the domain id to be serviced * @parm handle_bufioreq how should the IOREQ Server handle buffered * requests (HVM_IOREQSRV_BUFIOREQ_*)? + * @parm flags bitmask of XEN_DMOP_IOREQ_SERVER_* capability flags (0 if = none)=2E * @parm id pointer to an ioservid_t to receive the IOREQ Server id=2E * @return 0 on success, -1 on failure=2E */ int xendevicemodel_create_ioreq_server( xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq, - ioservid_t *id); + uint8_t flags, ioservid_t *id); =20 /** * This function retrieves the necessary information to allow an diff --git a/tools/libs/ctrl/xc_devicemodel_compat=2Ec b/tools/libs/ctrl/x= c_devicemodel_compat=2Ec index a46011cd17=2E=2E91366e250c 100644 --- a/tools/libs/ctrl/xc_devicemodel_compat=2Ec +++ b/tools/libs/ctrl/xc_devicemodel_compat=2Ec @@ -11,7 +11,7 @@ int xc_hvm_create_ioreq_server( ioservid_t *id) { return xendevicemodel_create_ioreq_server(xch->dmod, domid, - handle_bufioreq, id); + handle_bufioreq, 0, id); } =20 int xc_hvm_get_ioreq_server_info( diff --git a/tools/libs/devicemodel/core=2Ec b/tools/libs/devicemodel/core= =2Ec index 274a8eb28b=2E=2E5b2acb1869 100644 --- a/tools/libs/devicemodel/core=2Ec +++ b/tools/libs/devicemodel/core=2Ec @@ -167,7 +167,7 @@ static int xendevicemodel_op( =20 int xendevicemodel_create_ioreq_server( xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq, - ioservid_t *id) + uint8_t flags, ioservid_t *id) { struct xen_dm_op op; struct xen_dm_op_create_ioreq_server *data; @@ -179,6 +179,7 @@ int xendevicemodel_create_ioreq_server( data =3D &op=2Eu=2Ecreate_ioreq_server; =20 data->handle_bufioreq =3D handle_bufioreq; + data->flags =3D flags; =20 rc =3D xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); if (rc) diff --git a/xen/arch/arm/ioreq=2Ec b/xen/arch/arm/ioreq=2Ec index b4211f0159=2E=2E7d26180926 100644 --- a/xen/arch/arm/ioreq=2Ec +++ b/xen/arch/arm/ioreq=2Ec @@ -201,6 +201,12 @@ void arch_ioreq_domain_init(struct domain *d) { } =20 +int arch_ioreq_server_create_check(const struct domain *d, unsigned int f= lags) +{ + /* No XEN_DMOP_IOREQ_SERVER_* capability flags are defined for Arm=2E= */ + return flags ? -EINVAL : 0; +} + /* * Local variables: * mode: C diff --git a/xen/arch/x86/domain=2Ec b/xen/arch/x86/domain=2Ec index 996b50af7a=2E=2E69c9093e06 100644 --- a/xen/arch/x86/domain=2Ec +++ b/xen/arch/x86/domain=2Ec @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -1106,7 +1107,19 @@ int arch_domain_soft_reset(struct domain *d) void arch_domain_creation_finished(struct domain *d) { if ( is_hvm_domain(d) ) + { + /* + * Latch the extended destination ID decision now that all boot-t= ime + * ioreq servers are registered=2E A value restored from a migrat= ion + * stream (EXT_DEST_ID save record) already fixes it and wins=2E + */ + if ( d->arch=2Ehvm=2Eext_dest_id =3D=3D EXT_DEST_ID_UNSET ) + d->arch=2Ehvm=2Eext_dest_id =3D hvm_ext_dest_id_enabled(d) + ? EXT_DEST_ID_ENABLED + : EXT_DEST_ID_DISABLED; + hvm_domain_creation_finished(d); + } } =20 #ifdef CONFIG_COMPAT diff --git a/xen/arch/x86/hvm/ioreq=2Ec b/xen/arch/x86/hvm/ioreq=2Ec index a5fa97e149=2E=2E63d22f6738 100644 --- a/xen/arch/x86/hvm/ioreq=2Ec +++ b/xen/arch/x86/hvm/ioreq=2Ec @@ -19,6 +19,7 @@ =20 #include #include +#include #include #include =20 @@ -325,6 +326,62 @@ void arch_ioreq_domain_init(struct domain *d) register_portio_handler(d, 0xcf8, 4, hvm_access_cf8); } =20 +int arch_ioreq_server_create_check(const struct domain *d, unsigned int f= lags) +{ + if ( flags & ~XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID ) + return -EINVAL; + + /* + * Once the domain is running with extended destination IDs advertise= d, + * every ioreq server it gains must be able to bind MSIs the new way= =2E + * (Before that point d->arch=2Ehvm=2Eext_dest_id is still UNSET and = servers + * are levelled at arch_domain_creation_finished()=2E) + */ + if ( d->arch=2Ehvm=2Eext_dest_id =3D=3D EXT_DEST_ID_ENABLED && + !(flags & XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID) ) + return -EPERM; + + return 0; +} + +static int cf_check ext_dest_id_save(struct vcpu *v, hvm_domain_context_t= *h) +{ + struct hvm_hw_ext_dest_id s =3D { + =2Eenabled =3D v->domain->arch=2Ehvm=2Eext_dest_id, + }; + + return hvm_save_entry(EXT_DEST_ID, 0, h, &s); +} + +static int cf_check ext_dest_id_check(const struct domain *d, + hvm_domain_context_t *h) +{ + const struct hvm_hw_ext_dest_id *s =3D hvm_get_entry(EXT_DEST_ID, h); + + if ( !s ) + return -ENODATA; + + return s->enabled > EXT_DEST_ID_ENABLED ? -EINVAL : 0; +} + +static int cf_check ext_dest_id_load(struct domain *d, hvm_domain_context= _t *h) +{ + struct hvm_hw_ext_dest_id s; + + if ( hvm_load_entry(EXT_DEST_ID, h, &s) ) + return -ENODATA; + + if ( s=2Eenabled > EXT_DEST_ID_ENABLED ) + return -EINVAL; + + d->arch=2Ehvm=2Eext_dest_id =3D s=2Eenabled; + + return 0; +} + +HVM_REGISTER_SAVE_RESTORE(EXT_DEST_ID, ext_dest_id_save, ext_dest_id_chec= k, + ext_dest_id_load, 1, HVMSR_PER_DOM); + /* * Local variables: * mode: C diff --git a/xen/arch/x86/hvm/save=2Ec b/xen/arch/x86/hvm/save=2Ec index 8ab6405706=2E=2Eaac8498049 100644 --- a/xen/arch/x86/hvm/save=2Ec +++ b/xen/arch/x86/hvm/save=2Ec @@ -341,6 +341,15 @@ int hvm_load(struct domain *d, bool real, hvm_domain_= context_t *h) /* Reset cursor for hvm_load(, true, )=2E */ if ( !real ) h->cur =3D 0; + + /* + * A migration stream from a Xen predating extended destinati= on IDs + * carries no EXT_DEST_ID record, leaving ext_dest_id UNSET h= ere=2E + * Set it to DISABLED then, because the domain has no knowled= ge + * about EXT_DEST_IDs=2E + */ + else if ( d->arch=2Ehvm=2Eext_dest_id =3D=3D EXT_DEST_ID_UNSE= T ) + d->arch=2Ehvm=2Eext_dest_id =3D EXT_DEST_ID_DISABLED; return 0; } =20 diff --git a/xen/common/ioreq=2Ec b/xen/common/ioreq=2Ec index f5fd30ce12=2E=2E53003286c4 100644 --- a/xen/common/ioreq=2Ec +++ b/xen/common/ioreq=2Ec @@ -79,6 +79,25 @@ static struct ioreq_server *get_ioreq_server(const stru= ct domain *d, return GET_IOREQ_SERVER(d, id); } =20 +bool hvm_ext_dest_id_enabled(const struct domain *d) +{ + unsigned int id; + bool any =3D false; + + for ( id =3D 0; id < ARRAY_SIZE(d->ioreq_server=2Eserver); id++ ) + { + const struct ioreq_server *s =3D GET_IOREQ_SERVER(d, id); + + if ( !s ) + continue; + if ( !s->ext_dest_id ) + return false; + any =3D true; + } + + return any; +} + /* * Iterate over all possible ioreq servers=2E * @@ -641,7 +660,7 @@ static void ioreq_server_deinit(struct ioreq_server *s= ) } =20 static int ioreq_server_create(struct domain *d, int bufioreq_handling, - ioservid_t *id) + unsigned int flags, ioservid_t *id) { struct ioreq_server *s; unsigned int i; @@ -683,6 +702,8 @@ static int ioreq_server_create(struct domain *d, int b= ufioreq_handling, goto fail; } =20 + s->ext_dest_id =3D flags & XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID; + if ( id ) *id =3D i; =20 @@ -1350,10 +1371,14 @@ int ioreq_server_dm_op(struct xen_dm_op *op, struc= t domain *d, bool *const_op) *const_op =3D false; =20 rc =3D -EINVAL; - if ( data->pad[0] || data->pad[1] || data->pad[2] ) + if ( data->pad[0] || data->pad[1] ) + break; + + rc =3D arch_ioreq_server_create_check(d, data->flags); + if ( rc ) break; =20 - rc =3D ioreq_server_create(d, data->handle_bufioreq, + rc =3D ioreq_server_create(d, data->handle_bufioreq, data->flags, &data->id); break; } diff --git a/xen/include/public/arch-x86/hvm/save=2Eh b/xen/include/public= /arch-x86/hvm/save=2Eh index ff73b83d65=2E=2E58d301512e 100644 --- a/xen/include/public/arch-x86/hvm/save=2Eh +++ b/xen/include/public/arch-x86/hvm/save=2Eh @@ -629,12 +629,26 @@ struct hvm_msr { =20 #define CPU_MSR_CODE 20 =20 +/* + * Extended (15-bit) MSI / IO-APIC destination ID support, as negotiated = with + * the domain's ioreq servers and latched when the domain starts running= =2E + * + * 'enabled' takes the values of enum in struct hvm_domain: 0 =3D undecid= ed, + * 1 =3D off, 2 =3D on=2E + */ +struct hvm_hw_ext_dest_id { + uint8_t enabled; + uint8_t pad[7]; +}; + +DECLARE_HVM_SAVE_TYPE(EXT_DEST_ID, 21, struct hvm_hw_ext_dest_id); + /* Range 22 - 34 (inclusive) reserved for Amazon */ =20 /* * Largest type-code in use */ -#define HVM_SAVE_CODE_MAX 20 +#define HVM_SAVE_CODE_MAX 21 =20 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */ =20 diff --git a/xen/include/public/hvm/dm_op=2Eh b/xen/include/public/hvm/dm_= op=2Eh index d76777f71f=2E=2E0e1774b1d3 100644 --- a/xen/include/public/hvm/dm_op=2Eh +++ b/xen/include/public/hvm/dm_op=2Eh @@ -44,13 +44,24 @@ typedef uint16_t ioservid_t; * hvm_op=2Eh=2E If the value is HVM_IOREQSRV_BUFIOREQ_OFF then the buff= ered * ioreq ring will not be allocated and hence all emulation requests to * this server will be synchronous=2E + * + * x86 HVM only: a server that sets XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID in + * promises to bind every passthrough MSI via XEN_DMOP_bind_pt_ms= i_irq + * (which carries the raw MSI message)=2E Extended (15-bit) MSI / IO-APIC + * destination IDs are enabled for the domain, and advertised via + * XEN_HVM_CPUID_EXT_DEST_ID, only if *every* ioreq server registered bef= ore + * the domain starts running sets this flag=2E Once the feature is locked= in, + * later servers that lack the flag are rejected=2E */ #define XEN_DMOP_create_ioreq_server 1 =20 struct xen_dm_op_create_ioreq_server { /* IN - should server handle buffered ioreqs */ uint8_t handle_bufioreq; - uint8_t pad[3]; + /* IN - XEN_DMOP_IOREQ_SERVER_* */ + uint8_t flags; +#define XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID (1u << 0) + uint8_t pad[2]; /* OUT - server id */ ioservid_t id; }; diff --git a/xen/include/xen/ioreq=2Eh b/xen/include/xen/ioreq=2Eh index e86f0869fa=2E=2Ea75bd04b97 100644 --- a/xen/include/xen/ioreq=2Eh +++ b/xen/include/xen/ioreq=2Eh @@ -54,9 +54,19 @@ struct ioreq_server { evtchn_port_t bufioreq_evtchn; struct rangeset *range[NR_IO_RANGE_TYPES]; bool enabled; + bool ext_dest_id; uint8_t bufioreq_handling; }; =20 +/* + * True if at least one ioreq server is registered and every registered s= erver + * set XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID=2E Only meaningful before the do= main + * starts running (called from arch_domain_creation_finished(), when no + * concurrent ioreq server (de)registration can occur)=2E The result is l= atched + * into d->arch=2Ehvm=2Eext_dest_id there=2E + */ +bool hvm_ext_dest_id_enabled(const struct domain *d); + static inline paddr_t ioreq_mmio_first_byte(const ioreq_t *p) { return unlikely(p->df) ? @@ -137,6 +147,7 @@ bool arch_ioreq_server_destroy_all(struct domain *d); bool arch_ioreq_server_get_type_addr(const struct domain *d, const ioreq_= t *p, uint8_t *type, uint64_t *addr); void arch_ioreq_domain_init(struct domain *d); +int arch_ioreq_server_create_check(const struct domain *d, unsigned int f= lags); =20 #endif /* __XEN_IOREQ_H__ */ =20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35ad.88da934c2c0754a.1a0679edb1d.ec095fd8a6ac7414=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:14:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:14:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407269.1640426 (Exim 4.92) (envelope-from ) id 1x28DE-0007yF-Ol; Thu, 03 Sep 2026 14:14:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407269.1640426; Thu, 03 Sep 2026 14:14:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28DE-0007y2-KH; Thu, 03 Sep 2026 14:14:44 +0000 Received: by outflank-mailman (input) for mailman id 1407269; Thu, 03 Sep 2026 14:14:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28DE-0007wI-3d for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:14:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28DD-001HAI-GD for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:14:43 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9980bd-2eae-0a2a0a5409dd-0a2a4505c668-46 for ; Thu, 03 Sep 2026 16:14:43 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9980cb-4cb1-0a2a45050019-b9ff1c228579-6 for ; Thu, 03 Sep 2026 16:14:43 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0679ede0d000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 03 Sep 2026 14:14:19 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 462F684017; Thu, 3 Sep 2026 16:14:19 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=oWieLxc234k5uH169K+pisoqXQICUG6e/oesPGrXHLk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=DZ0uyy0jO63ngUNEYoK2Dh2QPQrjgBPyMLXupjtf2AITZcUkxhYdJ07dwrpvEIv2zOmPfW/3t 06O/Pz9U3J4YnwlFladbJhiF1sMONN9+XMPjTPhDmuEERa86wW4CMvsQ6MROo1yKcL1GYN14xUu 2eCIWYQ8+FItbHVxKMnVarw5BCJvfH82PPb96v+1kO8kEvGWrj2QGl1cU2TFzNCcKC+IkwybyWH AVGml618nrTTTcT+kxG9Vd9JeNPqPFfoMSyxOcZqs8Eu/arNmha0TD0hiH//xQARhJLL5PV9eRp fMSx7xqS5i8SVjOWi2GEgg8Uyh3SAKcn/O6Bg8Ya3tRQ== X-Zone-Loop: c9557038a1ecc87329f44ca244c39a867c93183a5dac x-campaign-type: default x-transaction-id: ae0a429b-35e3-4a3a-9c93-10ddf3fcd485 x-swg-uid: 01-855ebf8e-114e-4bcb-b2a7-08b977133bec X-Mailer: Sweego Message-ID: <1788444859.8631fc262581453bbf619ec5b2062170.1a0679ede0d000c4f3@vates.tech> x-swg-bid: 1788444859.8631fc262581453bbf619ec5b2062170.1a0679ede0d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" , Julian Vetter Subject: [PATCH v5 11/11] x86/cpuid: Advertise XEN_HVM_CPUID_EXT_DEST_ID Date: Thu, 3 Sep 2026 16:14:09 +0200 In-Reply-To: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.35ae.99efa79bcd8cdbfb.1a0679edc75.1550d244ce0da3c1=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788444859509 X-purgate-ID: tlsNG-c201ff/1788444883-F70B22A1-C8EB1064/0/0 X-purgate-type: clean X-purgate-size: 2203 ---=Part.35ae.99efa79bcd8cdbfb.1a0679edc75.1550d244ce0da3c1=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Expose the extended-destination-ID feature bit in the HVM hypervisor CPUID leaf when d->arch=2Ehvm=2Eext_dest_id is EXT_DEST_ID_ENABLED, i=2Ee= =2E the domain's ioreq servers all opted in and the value was latched at creation_finished (or restored from migration)=2E An older device model that never sets XEN_DMOP_IOREQ_SERVER_EXT_DEST_ID leaves the bit clear and the guest keeps 8-bit APIC destination IDs=2E Signed-off-by: Julian Vetter --- Changes in v5: - Retitled (dropped "when device model opts in")=2E - Removed the dynamic pre-creation_finished path: guest_cpuid() only ever runs for "current", so the value is always latched by the time the leaf is read=2E The check is now just hvm_ext_dest_id_active(d)=2E - Commit message rewritten to match the new logic=2E Signed-off-by: Julian Vetter --- xen/arch/x86/cpuid=2Ec | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xen/arch/x86/cpuid=2Ec b/xen/arch/x86/cpuid=2Ec index a9aeb2d268=2E=2E1e8dbf8a15 100644 --- a/xen/arch/x86/cpuid=2Ec +++ b/xen/arch/x86/cpuid=2Ec @@ -148,6 +148,14 @@ static void cpuid_hypervisor_leaves(const struct vcpu= *v, uint32_t leaf, res->a |=3D XEN_HVM_CPUID_DOMID_PRESENT; res->c =3D d->domain_id; =20 + /* + * Advertise extended (15-bit) MSI / IO-APIC destination IDs when= the + * feature was negotiated with the domain's device model(s) and l= atched + * at creation_finished (see hvm_ext_dest_id_enabled())=2E + */ + if ( hvm_ext_dest_id_active(d) ) + res->a |=3D XEN_HVM_CPUID_EXT_DEST_ID; + /* * Per-vCPU event channel upcalls are implemented and work * correctly with PIRQs routed over event channels=2E --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.35ae.99efa79bcd8cdbfb.1a0679edc75.1550d244ce0da3c1=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:31:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:31:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407334.1640434 (Exim 4.92) (envelope-from ) id 1x28TM-0005S6-7N; Thu, 03 Sep 2026 14:31:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407334.1640434; Thu, 03 Sep 2026 14:31:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28TM-0005Rz-4F; Thu, 03 Sep 2026 14:31:24 +0000 Received: by outflank-mailman (input) for mailman id 1407334; Thu, 03 Sep 2026 14:31:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28TK-0005Rt-UD for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:31:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28TK-002hVC-6e for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:31:22 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9984ab-2eae-0a2a0a5409dd-0a2a4506d942-48 for ; Thu, 03 Sep 2026 16:31:22 +0200 Received: from [52.101.57.56] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9984b9-195a-0a2a45060019-346539389962-3 for ; Thu, 03 Sep 2026 16:31:21 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH2PR03MB5269.namprd03.prod.outlook.com (2603:10b6:610:90::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Thu, 3 Sep 2026 14:31:18 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 3 Sep 2026 14:31:18 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EIwK+qkECACliE9/s5uez1N129RhZ3AzKMh9/wBN8VAfSLkS3H+yR60pOt96Ovuo49CuTjVZ1d/zz3XdcGRlZ2A3QfcTbjDLXELsAdtZBNTnyaynK9PeALcBEpCebEcMOMvFsw4IXQLu14Wkr+FmZmCqt9KGlTDnRCjomasbC8EVjjmiz5lxLaNePFY+FC8eqk8RSpd5GRRoydK98bxf4PoDBKrEKPZdWcmmIsLTlKuW86jdPJMjsc+LB/If43N/czDN5fWjb0Z92MLwmGM7c12AoKaMB2i0LN0dkE+a3E898+PPDF1aX0lMhmYXun59Y5B+lX/Z3tznBDsHg/X0cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oPVIOCwunf0gq3nutFG/6p+uX3ybf9cx2QlWCmeoesw=; b=UB6qxCJf6nLXcDcVqCl8K/p5CfJQtDBIP2PZNF4JMdG539P4ymi0yxVPfopg8Yh2hAAESidxPpPH9QGzNfzdTz1JUjIChxjSx02re0dXoYQ8YZFfK4d0Vge9Cqu0R/rjXUa97Z+0P6nfwrnb/LBUiYpCZQjWlIbdiiRnKKhkK/1zPcCFTuBKezwVCWdLWP6ZNPIDqDuxZkmJ+yU/gPiCCWWTGYr6ToR+K7LUfG2tC4DZUuRp2Vr+NZ92hF+Uayyg4pDD1GC0zNAVX7d47OPP9gz/gpp+uLXBIETrpyvHAMxKFqjvIq+iOawKMSXhDozR23aiScleXYPes8coxlHkYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oPVIOCwunf0gq3nutFG/6p+uX3ybf9cx2QlWCmeoesw=; b=rrxNcFp/rEkdhDwCS1sl9KeG4vHT5YMTRlCazlzW3JFCXhlCSQvl8VupH2XT1bMNX4Pj2EThHKXoy1kY86vykb/ms8QhGxTA2Gl8yeQFvv/0cEJDi7U4ntWbF9gg6ZgHYg4Mfgy+1uarp7rrPV3MPzEoPWlhlENXWNjoIG2SJN4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <6ecdf1d1-784e-4cc0-b840-f8970a295ed5@citrix.com> Date: Thu, 3 Sep 2026 15:31:14 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH v1] x86/svm: Intercept CR0 writes selectively To: Jan Beulich , Ross Lagerwall References: <20260828141955.4009939-1-ross.lagerwall@citrix.com> <514b9ad4-912c-45fa-9450-3c85adaef483@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <514b9ad4-912c-45fa-9450-3c85adaef483@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0025.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH2PR03MB5269:EE_ X-MS-Office365-Filtering-Correlation-Id: 04ee6489-dd3d-43cf-69bb-08df09c80467 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|10067099003|11063799006|4143699003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: +2HoLOBgBrkzu40mzkSV1LUC8kn+dCQ5wySR+yCp3cqBXAA05glCrUxVO0Gn7szvMGG6WqyASh9LsoXgauMDYvyg7kdVtyqkgJ+27keEMdpXs4quu6F+8dWvY3ANxAKlHzsXjnWV7ZLnUhcyAOUifT68UPSohA08Sp6hfbgEDqcojlXwqXReoNT+Y9f9FQq5E5jvR8tZide2ngL/POJYf0y0hv9NAZ67lmYwycfJG24id8RppGtttdiGu2YUTufcs4qwwYZC/AHxbopc2Oi0lPS8buXj+/spMwENOACBIXEQj/xKNXY5B6DKpydTh3CvO8LfmgrvgCpugH1q6rZyqkEQLC9gjPjfKjwu2AIGhyINS8v3LHJ3hkbG4piLcwSXMO1x6JHg6Mr0fQoFnsrNA0D9FGP2Zsc5pzkT9YMCwV98wxSPFuhxK0AjLwHynuLFYk+ljwRCqok0lhQLzCzsqiqw6v0bNkDCYKgfMqyDdpLNxXwijBPzhl/iHwz6DqLEG9751FdwPKY/Rc/frsDkRKmHxEVvKHpp58PnuVO2So7bK2aT0bW6ezxnU+hbNUhxyTmDHWwFLhoctoeCkOCtHAP8FoYOGtukcFljkZrTHlLElicsylu1B1pw8i4J9AUsj0u4Bf70Fu9efgbFDGxuTi3MthNdu3uoflVkL1OsPMA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(10067099003)(11063799006)(4143699003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SSswWVZMUnI2SlNiMStobGVmNlRnOXZzZ0NLb0JkK1J1d2xrTjJ1K3p4aFZm?= =?utf-8?B?NkpzdGNMOTc1VVY1SmNHK2s5a09tdCs5OWMvVXlxWnNOZHFQeS9MODRocE42?= =?utf-8?B?cFY0d281ZzZtUGdYU1c0ampwMnU5RnVOeG1peDVGYXNjOFp6a0IrcW5rV0hY?= =?utf-8?B?VFJ5U2UzVFk0QktyRnhyc3U2QUdwTkN4bGFtYWRaMDR3UlZOVjNNMkllckVi?= =?utf-8?B?anN6YUJJVGpHTmxLTzl3Y3NUeGpxWFBrSHkrVUJOTnV1d2J6alhTN3ZVZk5i?= =?utf-8?B?ZUtDL2RnUG1MSytxaDhjRnlqMlk5TXlFS201S3FwaURIOWFvNXpab2lpLzVx?= =?utf-8?B?YzZBMHM3SC9OcElaNW82bUs0cmo0MmJ1bSttMUlhdXdyQTVHMmNsRExJNUNt?= =?utf-8?B?eUJubWFmVXA3UzNidTB2TUdMMzhEV05teUZmOThmT05OWTBZcDNWMlNBcU1p?= =?utf-8?B?ZHBsMks3OCtYQXNZYkVHM0xZWGN0cUdVTlhzT0laWVVIcUtpSi94MVgrbCtK?= =?utf-8?B?N1BxRnFnR1d3K3hTVFl2UmFGY3pzL3gyVFNHc05UZWdqY2kySWhZMzhQM05G?= =?utf-8?B?NGk5Ylg3UGo4OE1FdE0yVlR1SUYrWUdldDVXb0hmTCtkUzJzZGtPMDQxdGwr?= =?utf-8?B?M1hjQXVwbkU2Y3ZSNkhHYmorT1k2NkVYelN0YjhkV1RmTStPbm5mcXpMN0VS?= =?utf-8?B?eVVONUU5Tkp1QWt2ZWV4L1NtYnNYcktBZlZ6RFd6cGIxY25Rc1hqdDFZaDFM?= =?utf-8?B?SUVKU2tkVFZ4YnBnc0pMYytmcmRzYmhUQVd6WVVrdWFHN21xSHE1QndKZkVJ?= =?utf-8?B?NHZENG1SZUpkUndyOCtaMm9oOG05Tm9FRnA3U0hzUEhlc3JYcXoyd3M0S2sx?= =?utf-8?B?VGpoci9ONGRHbS9WN1NlVnhYeGdQT0Rabmk5UUVQbjVFeGx3dTliM2RvQ3lV?= =?utf-8?B?SUYxTFk0NU5kZkVlQ05UZllKaXpvOWdPWHhvSUdvdUkxOVpVZ1hiSTJ5TnV2?= =?utf-8?B?bU5TaWxKbEJIZmFKVmxjMzZ1SldXN2xjU3crTk9BTWQvM3g1R0VuN2lJemhw?= =?utf-8?B?dW1wRm9HQUhOcVZMcTg3Ry9nVEh6VG5xeXhFOWFROVU5M3ArVWhERE1ZVWF2?= =?utf-8?B?WjY5WUtmSWNXVVdEbXVEMXpkWWhmVjNVOWYzdkFFRWFiNWhkUTl4RUlpaTVz?= =?utf-8?B?RVM0ZFczS3VLcG5YUmcyUjhxcUFtZjJUY2w0VE05YmZOQkhONWl1OEw1b2Ri?= =?utf-8?B?eEFqV2tBRUZWQ3laTmFhOVIwZkNXME1vSHJxVjJJeEFYMm9LN20zd0Z3VDdi?= =?utf-8?B?Y3R2UVhYMUMvY01qVmw5TnJ5VHZYWjI4U0phdThFMEZQS0dORkVWQXRPdytn?= =?utf-8?B?aDdUNjhLNUZZWkdoTEE4akd0b3ZLdEdrS004c0g0RzRpU056QWJLaS9Iends?= =?utf-8?B?ZEJVdHJ5SUd3emNSenI1UVVEU0xRWk9GSkxHSFV4d1BNSmh5SUx2RTFlRm51?= =?utf-8?B?R2lEWldxVGhxWjI2aWJ1V2R1YXB5YXljcy92S3B2SnFMNXAzQkttekNJWTl4?= =?utf-8?B?dDVuVWdpTkxWemJwcDE1QnE3ZGoxRzRaRHJNUGttdFdtcG0xNWpBYjdKTThB?= =?utf-8?B?OFptTlkvQUtqaXM2U2NCK0UyVVp4KzFQUWRKK3hFQzFEWDgvT0V3SUYwTVg3?= =?utf-8?B?MUxSK2NlUlpsT2dnMFBlWW0wYVhRQUxTTTlQZk1vL3dxS0hQd0kvSHFRNDF3?= =?utf-8?B?cjE0bml1Rm05ZWNNMS80THAxbEJlVVcxZjdLYXpiN2p5QVMxQmRZT1Z3Nld1?= =?utf-8?B?SHVTdk00d0cyWWF0RzBuWlVOVDhtSWtudm4rcGZsYlpjM0xvd1Rzd2c0ekQ0?= =?utf-8?B?alVxWVI3Z1IyNHZQME5KSDcxemhpNGR6cWdyMzBEWGdIUHFwMjBSRVJpSDkr?= =?utf-8?B?OXFFd0Z2ZUQyVEFwOFBGeG1YRWdXelFLUzBBN2xZZzVRYUpiVlRtYVdQQWpJ?= =?utf-8?B?dHlJdWlaRS9hckRuVTVocWJxZzdrdUlQUjlQYzRWdkp1L2lEQTRYVDdsUktT?= =?utf-8?B?UXBlZkM5bTFNbmhTaE9LRDZXaDdndEJWaGo0UVJPcDJ3amJRdTBaY1V6TW9s?= =?utf-8?B?SGprc1AwWWEzZGRabEZkZ3kxSzJ4YnhtQ0lwTE5LVlVpZkE4bk14RXRBSUlD?= =?utf-8?B?OHllK3ZHQ3NhNzFPa1JYNzhiNGQxVEhqenhMNkJGMmVrS0prTThuWGZrQURQ?= =?utf-8?B?SXZFbHRKRGZkMkZPVmdjZld1YTVFejlsaXJ3Y2J1dmN2cEk4OUhUdy9ISXpO?= =?utf-8?B?Ty9hd3ZaTlZmeG1nK2pmRTk0NjJySndvVlJmeGwrZEtJZUJJVTJHUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 04ee6489-dd3d-43cf-69bb-08df09c80467 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 14:31:18.3645 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7k5rr8LoSEnsip/ZEHCkVdH5lbEBL6By2cQUPdZxnRDBiQCerp90/arUUwx8AlSS2zlc7LCrvIA8ki4BxrLchMLvmzBFQUmK6zyB2cHUbz0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5269 X-purgate-ID: tlsNG-16d1c6/1788445882-FDC0F77B-31987012/0/0 X-purgate-type: clean X-purgate-size: 573 On 03/09/2026 2:02 pm, Jan Beulich wrote: >> Aside from potentially reducing a few >> VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE >> and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so >> L1 never sees any CR0 writes. > Yet if L1 sets CR0_WRITE, since intercept masks are ORed together (if > I'm not mistaken), L0's choice of intercepts needs combining with L1's choice of intercepts. Mostly this is OR-ing/unioning, but not exclusively, just like levelling for migrate isn't a straight interception. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:32:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:32:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407343.1640445 (Exim 4.92) (envelope-from ) id 1x28U0-0005uI-N9; Thu, 03 Sep 2026 14:32:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407343.1640445; Thu, 03 Sep 2026 14:32:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28U0-0005uB-IV; Thu, 03 Sep 2026 14:32:04 +0000 Received: by outflank-mailman (input) for mailman id 1407343; Thu, 03 Sep 2026 14:32:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28Tz-0005ss-CX for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:32:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28Ty-00An5l-Ov for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:32:02 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9984d7-bab6-0a2a0a5309dd-0a2a4503939c-20 for ; Thu, 03 Sep 2026 16:32:02 +0200 Received: from [52.101.48.12] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9984e0-fae8-0a2a45030019-3465300c7f52-3 for ; Thu, 03 Sep 2026 16:32:01 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH2PR03MB5269.namprd03.prod.outlook.com (2603:10b6:610:90::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Thu, 3 Sep 2026 14:31:57 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Thu, 3 Sep 2026 14:31:57 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DNBBuEMRcuHzVNXeYGQPHI+63E0RErmngbmPkhUVHVY4+HktHNkGsnuHE2jxZ/59EDQSkX6Uzofb2lM9pMtulKe50G7su/pH/MOGVP7awmnrpFAoy+q1SRqA83iDMfpW+ZA9/eDe3OdORw1RX96DcuSmTnMu4+m8qHWMGajT37Xke+xidmA9dcGQtFCFUFdFRqQdlqrhgZKHV8mpffOPmw3Gwkz8FM/itIwb6XKhNvj0TApifCeydAaMGNRyjuqCI0pnsq+ZF2kB0KCVLCexF/EEeTdQC0s8TTXqLZxR1r+UVhRNxZRaaLYfwiVpfgPnw0rjnz7GgMWCk7WUQTsHwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O8JqueNGQIyNX+s8aWi3F1MkZNe4nUGn2KTfR2Oxn9o=; b=fU+4d0QEtVBkWSPzbtstKD+EAalMJ7yQ3OLoAXP3Ws+nxeFKO/dfy9x0l9xtyoO1dF4lZRGd6l5OAnIVAR8crH7xIvb8sReZe5Y5Uq2ZWdJtpr7Ohyhbr1fdH7YiLFCrrbR3hgaULGN6FNDXsZ61cgh+PK64UGG65Xtd7uAnbcAXjl7xokBeKQd0eqzVQLHYM7MmEeOboHDomGIEHkX55ZPBwoLyhoGdOiWT0EIY87i8/FsI9Mo7u6xD1du6fJgxY+NPCnlZXF9DUKOn1YC855m/Dxsk/7FC8s1qhPLzrQYvSn2MPXrTq9CchJTi7BRxPttfxESN9pTsJ3VfwRz+Nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O8JqueNGQIyNX+s8aWi3F1MkZNe4nUGn2KTfR2Oxn9o=; b=m95wjObidK0pgiMSr20iEJseeaI7WK3VhPUnlnhMxngdeqYMSGr2uOy+RzFDOLOkqGgY/yjyNHFAcIjlrpOmezdkpAslafpatTTHjePhevPJ/irMWLFItjPwzAn0edKUGdwexLIouqI8big0VKHvUXV6QYR2HOi8vD48hU9Oj30= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1acb3901-c159-49c5-bd59-aa7be58c67cb@citrix.com> Date: Thu, 3 Sep 2026 15:31:53 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH v1] x86/svm: Intercept CR0 writes selectively To: Jan Beulich , Ross Lagerwall References: <20260828141955.4009939-1-ross.lagerwall@citrix.com> <514b9ad4-912c-45fa-9450-3c85adaef483@suse.com> <6ecdf1d1-784e-4cc0-b840-f8970a295ed5@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <6ecdf1d1-784e-4cc0-b840-f8970a295ed5@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0029.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH2PR03MB5269:EE_ X-MS-Office365-Filtering-Correlation-Id: 6a749461-90b8-4650-2c9e-08df09c81b4b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|10067099003|11063799006|4143699003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: YSHmPm7D2Njo2SN9u3ivjFe3HQtFnA61AMRslJL33+9FGIUzvMUfCrdQaLhX28OpQetB1SAGrxnx1n92g7waOSMTXT6Izq5n6zpVn4vtIvINMEg0yCwFOkuzROCZio7l/rpfua/bO4PWppoGkfNeG4o+88Ev03ftmtTjftBxMUiaXcU0RPVNnpkEieQt7/LvZvjFPOiKOQnFopSQC1eX8gnCRIcXCC+cHM77bo1kHu2duUJPQ4YpebO3wCrtXJEj/uyQ5BcIuMMDshy+ezkKHT/YzKp25nYvMpaKros1U4BPr1hgfSpEoVdzK4uw+cW3+EgsMt/IXmIABCjZfsh9f1Fk55MyqKw//+CMUkIi+0x41nw1rfEVE44Y+sQbEFYU8tQbf+3bmcJj+6ukzXbrLmAvcdv/66heg4fTV1FRYfiyM71mom6IxsYCZ18M0v0O8LvmPCP0PMBQCJygs4jsUO9QZ7c8yxqHBchjxjFQrUS/jU1gMoj327JZt20zlK9NP0iCzJlElyfVkP9O/4kSz9EwzVbs9r1Tnml0N8zsNwOvq+3U4XT+exVjiJUM1fneL4l+j002toSneAo3XKtXSTElssm4yqUhJrgVXmhX33n3GPypBvG0eRkj3WBnv/OtKhP3DDAwXuyfrYsmZZOh4FjLOOWLXfgRTR4SscuYL0o= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(10067099003)(11063799006)(4143699003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VVpZUm1vQnVnTmZTTHJlUjRtY3NxemtCZHZNL1NSZ3VqTVpWcUNOV3ZLRG5S?= =?utf-8?B?QmRJQkVPWTQwTW00a2ZzWGZCNXNtSXlxN2pSRzg0WFNUdy9PeE43QmJpY3hW?= =?utf-8?B?YkJzaU8yU250ay9DWjZOc1l1MjV3SHliSTVCcTFBT084d3RhNzdSUStxL0Vl?= =?utf-8?B?a3F0NFMvZVBVdUpjaCtGbTczbm0zWXpyTm9oK1hFOW9NdUloSWllSlJ0cUZ1?= =?utf-8?B?RTMvQlhKWElXSkNZVmgxVzIzVytyMEpHVy9pbHVqZGp3eTNKeWp2SmJoUXA1?= =?utf-8?B?MWJ0TWxZR2ZTMG55U0tpUEdxdk1sZDErcDZ0LzMyNjE3TzJDdVRYaytHdXZU?= =?utf-8?B?Nnc0c2Q0UEhSem0zL095SGtBcFR0Yy93R2t5TWNJdlM0dTJxV2J2Z25Gd1Ez?= =?utf-8?B?ei92S3dqSyt6bUZycUhWd0RKdFVMVHNYV2NCZUtDMzZTNlhLa1JrVm55M2ZL?= =?utf-8?B?RXgyclFxaGtPNmtEMEFHTjZMamc2bEpyd1FKUjdBWmxBL1ZwKzNuY0R3ZDlS?= =?utf-8?B?WlFWemhTYnBDTjlwUTBUNlFYMnRiSnBLamNCbUc0MWIvVzhERlhXZzlxT0xH?= =?utf-8?B?SURGVGpDSGZ2Z1g5TGVWay9ldFI0UENLTmszMGxjRWRhNlRCTnVyOVRKYkRH?= =?utf-8?B?blhNYXJtbEt4UlZrVHBtdUVVWlNlVktnYkt2cmdQbk90dWYvMHFza01TTSt6?= =?utf-8?B?NkRNR25IdXpDSGlxZnZMV0x3akJjRG9xYmZqbjNRWWtvS2psSWRDbkhpMGxl?= =?utf-8?B?eHV2N3h1eFZDekpJS0o4NjJ3cW5sR1FpeCtTVTBoMFJVbE1Jd3FON1BUVnhj?= =?utf-8?B?UE9BWUlHVklpQVBob0RGbFZCalFEdlltdTNiVFVZRmtjeFQrbDZtN0FXQTQy?= =?utf-8?B?aE1nd1oyZmVEaVd1WEpyaisvSmo0R3BYckxWUnkzblBJR3FCSDliY0N1cWVm?= =?utf-8?B?dXU4V0tTNysrZzBNUFFJeTZGRHJ1VU8wNk8zdDJheUJyRlNDcUpTZ0o1c1hT?= =?utf-8?B?QnM3cHNKdHhDbStudTd4NStVVmhmQVg3bG5oYXBBM2YyOHpsZjFra2tnK24y?= =?utf-8?B?bFFlcUZGSHgzeGhudHpGaXpZbTlhUUk1MUZoNXBKSWM3UG5TakM2akFUa3hT?= =?utf-8?B?QkQraGppcWlSMUdRd1JjSngxaEQwY2xObFVOWWVuU3RMbEpvSHVpVWV3WUFM?= =?utf-8?B?Y2J2ajIvNXpZYjQ1c3pVdnhLYVduYlo5SnptSk9zTUhvNXdiLzllUnRlZWhk?= =?utf-8?B?ell2Rjg2djROWG1vNmF0cEJHNUdBdjRqb25zWjZDdGt6dVRQMVg1L2UvY1hW?= =?utf-8?B?OXgxNm9PM1FQK25UenlMNmVPRlQ2UEJKdS9sM0cya1orMndhbGR2L1lzQWlF?= =?utf-8?B?ckRudGY2UmQvNEJFcG9TSHRWNnp2Y3hBR2taTWJudkpvck5hNUU3eXhManJk?= =?utf-8?B?ankxVGFjZ1lhYWNQaW5DaUc0NXhSWTJyZ3RvWXp3Qit4NWNLdVVQbTdTNGR2?= =?utf-8?B?TUFNMlVDN2ZLcTA3SW5ta3l1cTZIZWF4dEh5QWZPcjN5SFVNL3RSWDZ0OWw5?= =?utf-8?B?T0hJSVJROHN3N0tHUDVIM3VYUEIreDRBay9Ucm13YzdVMzYyK1J3K0NQZXdK?= =?utf-8?B?Ykt0VVNaaDhObkpNdldjS2tCNlA2cHJSK0lHV1RHcFJiU1pxRDNVRERnRUNo?= =?utf-8?B?eWMvL3I3SGJSY0c1ZndrNDlJWG90TUdKbGNmb09HcXVZUlRTOVZMSXZrOXFi?= =?utf-8?B?dTNSbXpwTER3NjNFY29zV2YrbW5iZjR6MXJTVzFMMUpUeXZrZEJOSUJhR0lh?= =?utf-8?B?ckJ4ZzVuRWtIN2d0TCtwRk13dE1QdElKY1BYQVIwMXdzWUI5TTZpektlOUFY?= =?utf-8?B?WTk2ajdJQnRUTVI0ck9GN1I2R2FGeklxMy90QTcvTmIzWWppbkQxcHE0bTVj?= =?utf-8?B?VkxNcUtxU2UrRUhuY2JIeUV1K1pQRVlwYnYycGt0RkpoMjYvdmZsVjJvaTZj?= =?utf-8?B?K2gzM1F6UHRrZHNIT0NxN29heUI0OVFtaVBYOExpTnN6aEpmTDF2b3NHV3pj?= =?utf-8?B?TWdxZmd6SmhWd01zODNQM2tsdmZUMGxyNTBlTDR1dFJXRGlYM2dabHZ5a1Y3?= =?utf-8?B?VEFBWjF1Z1R2UXF4anFYZkNOR0VXYkpBdFhKTnhkZHJWWW9VVSs3V0pXM3lB?= =?utf-8?B?S0hvSzg1M0xXMWdJWVV1SmFBYmlLbFZFY25kcHpKOHI1Tm1WYmx3Mnh3QUpH?= =?utf-8?B?cmZheFhLbTlVcndIYmtmQWQzalhOWkNLRitWbmo0eThiWFRDd0doZHBzazVV?= =?utf-8?B?OGRXYkhwYXpHOEpsY2E0QmtNYzdhZ08xZWZHSEd5Y1Z2NmVydUs2dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a749461-90b8-4650-2c9e-08df09c81b4b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2026 14:31:56.8275 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0jLkLNDmFHaIxPX7VZ30H7JT9kP4rVm/lqct6TQblJl8aws1jYA1FRfyROa9GTv1M03RhvjNim6++ka+mBsyI6O1acFBoianCO7fu5CljjU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5269 X-purgate-ID: tlsNG-33051d/1788445922-6C2E04E9-CF52B0D1/0/0 X-purgate-type: clean X-purgate-size: 655 On 03/09/2026 3:31 pm, Andrew Cooper wrote: > On 03/09/2026 2:02 pm, Jan Beulich wrote: >>> Aside from potentially reducing a few >>> VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE >>> and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so >>> L1 never sees any CR0 writes. >> Yet if L1 sets CR0_WRITE, since intercept masks are ORed together (if >> I'm not mistaken), > L0's choice of intercepts needs combining with L1's choice of intercepts. > > Mostly this is OR-ing/unioning, but not exclusively, just like levelling > for migrate isn't a straight interception. Sorry, intersection. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:40:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:40:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407360.1640454 (Exim 4.92) (envelope-from ) id 1x28bh-00073h-EN; Thu, 03 Sep 2026 14:40:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407360.1640454; Thu, 03 Sep 2026 14:40:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28bh-00073a-9g; Thu, 03 Sep 2026 14:40:01 +0000 Received: by outflank-mailman (input) for mailman id 1407360; Thu, 03 Sep 2026 14:40:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x28bg-00073U-4j for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:40:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28bf-006ZQQ-1N for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:39:59 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9986ad-2eae-0a2a0a5409dd-0a2a4507ea1a-20 for ; Thu, 03 Sep 2026 16:39:59 +0200 Received: from [209.85.167.53] (helo=mail-lf1-f53.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9986be-b4ea-0a2a45070019-d155a735c078-3 for ; Thu, 03 Sep 2026 16:39:58 +0200 Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-5b5e18f0439so2404336e87.2 for ; Thu, 03 Sep 2026 07:39:58 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b606b94655sm1427658e87.41.2026.09.03.07.39.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 07:39:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788446398; x=1789051198; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=42+uphfCCLRvNwxaRgHxqMYnP9Bgc+IH+RL7USpLoVM=; b=VS2Xz2BcXGCY5HO+d8i2Gc5W70FVwSy187AfrXgjxo8MOtiRB4m3OA5uEPc4Kji2aq gNQdlL648WppQXzevrs5iFKz4MVEXJd10YPotuLsLc8cnNpoShjt3yaS1gtMpTD0igD9 KerwdJSzfLrTBej1Ara9n/HT91cwf3CSBYlwrOAvbg2faR8WH3izrb4mVlKBxAPXvt+3 PLlKt+1FmFyc0Pszc5tvr6wAarNl9J41KGirwexI1Q5OpImugRBpXIiywfu7W/yrlsxm RwCN/rwF0LbgALJFs1A1CL2OUx27O00sNHoePtw0cJlTFzKtIhgW/KmhO9nMptATHDZH Zoaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788446398; x=1789051198; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=42+uphfCCLRvNwxaRgHxqMYnP9Bgc+IH+RL7USpLoVM=; b=dK7oFntboEcIgN3gWShhOEhcjDoYWi08j6mKF3OtCbU1DBkVVJ6oiDcXXTTLeGNbin scSYPSWurtLIDOj21Kkt3Yp9aErsEg93x5h8NLX/oa2ZhuDVLxPIGcaHtFt/tUFnYQqa AQJgeMxUmLl5yVDv0SGwZ/JCLmDkKpLdXbiXBfQcGf4NH74nF6o2UHn4b4Oc3mvkYojg QgaqbwAijnE70iPKEBaUJ+sV7Tkynvzu3sOApXwPHJlQboYNaVGFnQch6+mgrkINM3BS Bzj4QAcxTRJcJTXEyxBk7I+U2cxIeTvTZayWEdYt+fT+RRjIz7TGmSVJB8zW2jD2rNIH LlSg== X-Forwarded-Encrypted: i=1; AKwUvBwNYF3cj2YyP0TEjo1VXVmdBzcSr6QYmpkvqSbnabtMjDqm0SnjAfQMbMxPv90CBBgRQWYg/yWU534=@lists.xenproject.org X-Gm-Message-State: AFuF++m1zdz+17HveIY8GfLHJduAJVa+NwDr1D9HSQLsW0M821R9+OZU G1VwaCvE64YnG9ttBI2bwNp9EOaIQp7I/zT1w7zSdckl0J4uR2/eTBW4 X-Gm-Gg: AYBFou3F1nDddRLqTAzKig+/Nym2F5NOxArdwgPvbHbDhECZFs5tw/xuujeLg8+cpjU sy+JLCHhcK4TMmjfeYRctH3Z+3XkvHjtBn1wmKJXQjO10UYKgDoE5l6NepHE7FH6ZWMh2HmVzVP H/87+eX5d4vg7YnGoxhcpn7lB3IcZWlZyCbk/OtmCORAlfPsKIcPMFDC+oWeTJe/DDdi3eo6zUs CmahkWzVCe3ImeM4bFcTdCq9c4UOzNdyIkh76tCAR5oCWZQrge48lqyc+d3nXqaEElR+LHYyog9 yYODd0/ikDey+uG+H228/tVEl63VUJ36QprFh/8ayG20J+n5x22AI5Xd4FfFaVuySmfndmxOEnm rAM0UW+tV52I4YTnQnUF2nFv071LHkri3pAiEe/LBgsGu6n7oAtDL48nYTbHSdAxrnkgC0wbKUm m9J3ZomKLB+58+34iDybvcQbQi1hKQpadj7deTplvIzflKQDTqsw4fATHAthBOazYnI33WGWmrt L5FFOTzVgCeMaSCE3NdxcK658630hmbrYgQdKx/9g== X-Received: by 2002:a05:6512:1252:b0:5b2:958f:8cdc with SMTP id 2adb3069b0e04-5b608344615mr4753675e87.11.1788446397861; Thu, 03 Sep 2026 07:39:57 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 16:39:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v8 16/20] xen/riscv: implement IRQ routing for device passthrough To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: <0cf2c9f6-5fba-4d1e-a9cd-e2a409730efa@suse.com> Content-Language: en-US In-Reply-To: <0cf2c9f6-5fba-4d1e-a9cd-e2a409730efa@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788446399-A72DCAE4-0FDE81D7/10/73395122804 X-purgate-type: spam X-purgate-size: 15101 On 9/3/26 12:00 PM, Jan Beulich wrote: > On 27.08.2026 17:19, Oleksii Kurochko wrote: >> dom0less device passthrough requires granting guest domains access to >> device interrupts. Introduce map_device_irqs_to_domain() to enumerate >> a DT node's interrupt properties, skipping those not owned by >> the primary interrupt controller (as at the moment I haven't seen usages >> of it), and map_irq_to_domain() to grant domain access and configure >> Xen's interrupt descriptor accordingly. Sharing IRQ between domains is >> rejected. >> >> Both map_irq_to_domain() and map_device_irqs_to_domain() are marked >> __overlay_init, mirroring Arm: without CONFIG_OVERLAY_DTB this expands to >> __init, so the functions are init-only and need no XSM check; with >> CONFIG_OVERLAY_DTB they become runtime-callable, but the only runtime >> entry point is dt_overlay_domctl(), which performs the XSM checks at the >> domctl layer. RISC-V does not wire up DT overlay yet, so today these are >> strictly __init; if/when overlay support is added, the domctl-level XSM >> gating must be added together with it, as on Arm. >> >> route_irq_to_guest() and release_irq() manage irq_desc ownership for >> guest-assigned interrupts. Each assignment carries a small irq_guest >> structure as irqaction::dev_id, recording the owning domain and virtual >> IRQ number which is 1:1 mapped to physical IRQ number. A per-domain >> vIRQ allocation bitmap (used_irqs in struct vintc), managed by >> vintc_reserve_virq(), prevents the same vIRQ being claimed twice. >> >> Host and guest interrupts may differ in some operations (EOI timing in >> particular, possibly others): a host IRQ is completed once Xen's handler >> runs, whereas a passthrough IRQ must defer the physical completion until >> the guest issues its own EOI, otherwise a still-asserted level line would >> immediately retrigger and storm. This affects only the .end callback; >> the rest of hw_interrupt_type is shared, hence the separate host and >> guest hw_interrupt_type instances. > > Irrespective of there not being any .end() hook yet, I think the two would > better be split properly right away. aplic_guest_irq_type's .name could > then also properly point to e.g. "aplic-guest". I agree with renaming and I will do that now. Regarding splitting I can split now but they will look the same for AIA case as we supports only a vAPLIC which works in MSI mode (vAPLIC+vIMSIC) and it will be true until we will introduce only vAPLIC support w/o vIMSIC. And in case of absence of vIMSIC we will really need a separate .end() for a guest. And .end() for guest will be definitely also needed in the case of vPLIC. So for now I can suggest to do the following: diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index 3681f0669efb..422c65ece4f7 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -325,13 +325,40 @@ static const hw_irq_controller aplic_xen_irq_type = { .set_affinity = aplic_set_irq_affinity, }; -/* At the moment there is no difference between guest and Xen ops */ -#define aplic_guest_irq_type aplic_xen_irq_type +static unsigned int cf_check aplic_guest_irq_startup(struct irq_desc *desc) +{ + BUG_ON("unimplemented"); +} + +/* + * Shared by ->shutdown(), ->enable(), ->disable() and ->end(), which have + * no state. + */ +static void cf_check aplic_guest_irq_stub(struct irq_desc *desc) +{ + BUG_ON("unimplemented"); +} + +static void cf_check aplic_guest_set_irq_affinity(struct irq_desc *desc, + const cpumask_t *mask) +{ + BUG_ON("unimplemented"); +} + +static const hw_irq_controller aplic_guest = { + .typename = "aplic", + .startup = aplic_guest_irq_startup, + .shutdown = aplic_guest_irq_stub, + .enable = aplic_guest_irq_stub, + .disable = aplic_guest_irq_stub, + .end = aplic_guest_irq_stub, + .set_affinity = aplic_guest_set_irq_affinity, +}; static const struct intc_hw_operations aplic_ops = { .info = &aplic_info, .host_irq_type = &aplic_xen_irq_type, - .guest_irq_type = &aplic_guest_irq_type, + .guest_irq_type = &aplic_guest, .handle_interrupt = aplic_handle_interrupt, .set_irq_type = aplic_set_irq_type, }; > >> --- a/xen/arch/riscv/irq.c >> +++ b/xen/arch/riscv/irq.c >> @@ -12,11 +12,26 @@ >> #include >> #include >> #include >> +#include >> #include >> +#include >> >> #include >> #include >> >> +/* Describe an IRQ assigned to a guest */ >> +struct irq_guest >> +{ >> + struct domain *d; >> + unsigned int virq; >> + /* >> + * The action of a guest IRQ has the same lifetime as this structure, so >> + * embed it here to have both covered by a single allocation. Consequently >> + * it must not be freed by release_irq() (see free_on_release below). >> + */ >> + struct irqaction action; > > Why the mention of release_irq(), when release_guest_irq() doesn't use that > function? (In fact release_irq() looks to be unused altogether.) > Right, the reference is wrong. release_guest_irq() detaches the action itself and then calls irq_release_action(), which is what actually honours free_on_release. It should be: - * it must not be freed by release_irq() (see free_on_release below). + * it must not be freed on its own, which is why free_on_release is left + * false for it (see irq_release_action()). >> @@ -227,3 +250,235 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq) >> spin_unlock(&desc->lock); >> irq_exit(); >> } >> + >> +static struct irq_guest *irq_get_guest_info(struct irq_desc *desc) >> +{ >> + ASSERT(spin_is_locked(&desc->lock)); >> + ASSERT(test_bit(_IRQ_GUEST, &desc->status)); > > Nit: I don't quite see why this cannot be the simpler > > ASSERT(desc->status & IRQ_GUEST); It could. I will apply that. > >> +static struct irqaction *irq_detach_action(struct irq_desc *desc, >> + const void *dev_id) >> +{ >> + struct irqaction *action, **action_ptr = &desc->action; >> + >> + ASSERT(spin_is_locked(&desc->lock)); >> + >> +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION >> + for ( ;; ) >> + { >> + action = *action_ptr; >> + if ( !action || (action->dev_id == dev_id) ) >> + break; >> + >> + action_ptr = &action->next; >> + } >> +#else >> + action = *action_ptr; >> +#endif >> + >> + if ( !action ) >> + { >> + printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n", >> + desc->irq); >> + return NULL; >> + } >> + >> + /* Found it - remove it from the action list */ >> +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION >> + *action_ptr = action->next; >> +#else >> + *action_ptr = NULL; >> +#endif >> + >> + /* If this was the last action, shut down the IRQ */ >> + if ( !desc->action ) >> + { >> + desc->handler->shutdown(desc); >> + __clear_bit(_IRQ_GUEST, &desc->status); > > Similarly > > desc->status &= ~IRQ_GUEST; > > here then. I will apply that. It could be really done in this way as we are under lock here. > >> +/* >> + * Complete the release of an action detached by irq_detach_action(). >> + * >> + * To be called with desc->lock dropped: the lock cannot be held all the way >> + * through, as waiting for a handler still running on another CPU to complete >> + * requires do_IRQ() to be able to acquire the very same lock. >> + * >> + * Once this function has returned, the action (and hence any object embedding >> + * it) is no longer referenced by anyone and may be freed by the caller. >> + */ >> +static void irq_release_action(const struct irq_desc *desc, >> + struct irqaction *action) >> +{ >> + /* >> + * Wait to make sure it's not being used on another CPU. >> + * >> + * The read barrier pairs with the spin_unlock() in do_IRQ(): once we >> + * observe _IRQ_INPROGRESS cleared, we are guaranteed to also see the >> + * writes do_IRQ() made to desc (e.g. desc->action) before releasing the >> + * lock, so it is safe to free the action below. >> + */ > > I fear I don't understand this: What writes to desc->action would do_IRQ() > ever want to do? I could see if you gave desc->status as example here; > really I don't think any other field (apart from perhaps statistics) would > ever want modifying there. I will reword: * The read barrier pairs with the spin_unlock() in do_IRQ(): once we - * observe _IRQ_INPROGRESS cleared, we are guaranteed to also see the - * writes do_IRQ() made to desc (e.g. desc->action) before releasing the - * lock, so it is safe to free the action below. + * observe _IRQ_INPROGRESS cleared in desc->status, we are guaranteed to + * also see whatever the handler did on that CPU before the bit was + * cleared, so it is safe to free the action below. > >> + do { smp_rmb(); } while ( test_bit(_IRQ_INPROGRESS, &desc->status) ); I am thinking if a barrier is in correct place or needed at all. Considering that desc->status is updated under spinlock() which uses full barrier the result here should be already observable without smp_rmb() inside do {} while (). Probably we want to have load->load between test_bit() and a read of action->free_on_release in if () below but I don't see what could go wrong if this read will happen before do {} while (). xvfree() (stores inside it) can't be executed ealier because of control dependency [Rule 11: b (xfree) is a (action->free_on_release) store, and b has a syntactic control dependency on a] so again it looks like a barrier isn't needed here. So considering what kind of barrier is used inside spinlock + Rule 11 we can just move smp_rmb() after the cycle (just in case) and it looks like smp_rmb() is only here just to force compiler not to order the things considering how action->free_on_release is used: static void irq_release_action(const struct irq_desc *desc, struct irqaction *action) { /* * Wait to make sure it's not being used on another CPU. * * desc->status is cleared in do_IRQ() under desc->lock, whose * acquire/release barriers are a full smp_mb() on this arch, so the * handler's writes are already ordered before the clear is visible. * On this side, xvfree() is control-dependent on the final test_bit() * load, so Rule 11 (RVWMO) already orders it after the wait with no * barrier. smp_rmb() below adds real read->read ordering, but nothing * after the loop depends on it (action->free_on_release isn't racy); * it's kept as a guard against the compiler breaking the control * dependency the ordering actually relies on. */ while ( test_bit(_IRQ_INPROGRESS, &desc->status) ) cpu_relax(); smp_rmb(); if ( action->free_on_release ) xvfree(action); Am I missing something? > > Please split this across three lines, to conform to style. (Also same nit > as above.) > >> + if ( action->free_on_release ) >> + xvfree(action); > > How does this being done here fit with the last paragraph of the comment > ahead of the function? The comment is inaccurate. I will drop "... by the caller." > >> +int release_guest_irq(struct domain *d, unsigned int virq) >> +{ >> + struct irq_desc *desc = irq_to_desc(virq); >> + struct irqaction *action; >> + struct irq_guest *info; >> + unsigned long flags; >> + int ret = -EINVAL; >> + >> + spin_lock_irqsave(&desc->lock, flags); >> + >> + if ( !test_bit(_IRQ_GUEST, &desc->status) ) >> + goto unlock_err; >> + >> + info = irq_get_guest_info(desc); >> + if ( d != info->d ) > > This looks to be the only use of "d" - any reason the function parameter cannot > be pointer-to-const? Missed that. It looks like it could be really const. > >> + goto unlock_err; >> + >> + /* >> + * Detaching the action happens with desc->lock still held, so that a >> + * concurrent release_guest_irq() for the same IRQ sees _IRQ_GUEST already > > I think "sees" is misleading here, as it suggests that a racing check can occur. > With the lock held, that's impossible. Hence imo better "will see" (i.e. only > after having got hold of the lock). I will correct the comment in suggested way. > >> +/* Route an IRQ to a specific guest */ >> +int route_irq_to_guest(struct domain *d, unsigned int virq, >> + unsigned int irq, const char *devname) >> +{ >> + struct irq_guest *info; >> + struct irq_desc *desc = irq_to_desc(irq); >> + unsigned long flags; >> + int retval = 0; >> + >> + if ( d->is_dying ) >> + return -EINVAL; >> + >> + info = xvzalloc(struct irq_guest); > > With zeroing used here, ... > >> + if ( !info ) >> + return -ENOMEM; >> + >> + info->d = d; >> + info->virq = virq; >> + >> + info->action.dev_id = info; >> + info->action.name = devname; >> + /* The action is part of 'info', thus it is freed together with it. */ >> + info->action.free_on_release = false; > > ... this is dead code. I will drop init. with false here. > >> + spin_lock_irqsave(&desc->lock, flags); >> + >> + /* >> + * If the IRQ is already used by someone >> + * - If it's the same domain -> Xen doesn't need to update the IRQ desc. >> + * For safety check if we are not trying to assign the IRQ to a >> + * different vIRQ. >> + * - Otherwise -> For now, don't allow the IRQ to be shared between >> + * Xen and domains. >> + */ >> + if ( desc->action != NULL ) >> + { >> + if ( test_bit(_IRQ_GUEST, &desc->status) ) >> + { >> + struct domain *ad = irq_get_guest_info(desc)->d; >> + >> + if ( d != ad ) >> + { >> + printk(XENLOG_G_ERR "IRQ %u is already used by %pd\n", >> + irq, ad); > > Perhaps best to also have %pd: at the start of this message, just like ... > >> + retval = -EBUSY; >> + } >> + else if ( irq_get_guest_info(desc)->virq != virq ) >> + { >> + printk(XENLOG_G_ERR >> + "%pd: IRQ %u is already assigned to vIRQ %u\n", >> + d, irq, irq_get_guest_info(desc)->virq); > > ... you have it here? Sure, I will aligh the comments. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:43:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:43:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407371.1640471 (Exim 4.92) (envelope-from ) id 1x28fL-0000WE-7U; Thu, 03 Sep 2026 14:43:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407371.1640471; Thu, 03 Sep 2026 14:43:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fL-0000W2-33; Thu, 03 Sep 2026 14:43:47 +0000 Received: by outflank-mailman (input) for mailman id 1407371; Thu, 03 Sep 2026 14:43:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fK-0000JR-5X for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:43:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28fJ-0045Cl-Ii for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:43:45 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a998799-bab6-0a2a0a5309dd-0a2a4508ed7e-24 for ; Thu, 03 Sep 2026 16:43:45 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a9987a0-f659-0a2a45080019-d98c6eacc8ea-1 for ; Thu, 03 Sep 2026 16:43:45 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 927F41596; Thu, 3 Sep 2026 07:43:40 -0700 (PDT) Received: from C3HXLD123V.arm.com (unknown [10.57.7.135]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0EE593F673; Thu, 3 Sep 2026 07:43:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788446624; bh=sExkGKD2p+tZsm+iivyfrVTc3F00OPetQljT4c3dyFA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lMcGCeFd7vQgkbkyPQr0YNxNKPZbjqbpViXvFqfydaBwJoaJWf0H10lan6sAXx9DI UGl9ZJ15dAUBqKhLTxhn+0M2YUyxS9OClykoytWExH+FDaT5u3noPrl35uhZLbJp9/ LYXCWvh4snqp5Nm+dAitouAG/l0a1p2CNCsHLtHg= From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel , Jens Wiklander Subject: [PATCH v3 1/6] xen/arm: ffa: Fix NPI injection when vcpu0 is offline Date: Thu, 3 Sep 2026 16:43:26 +0200 Message-ID: <5c332672f58b0f2280d28a1682d53e91f576df17.1788268510.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788446625-CD34D87B-10FC8884/0/0 X-purgate-type: clean X-purgate-size: 3431 RX-buffer-full notifications currently inject the notification pending interrupt through vcpu0 only. Secure notification delivery already walks the domain's online vCPUs, but the RX-buffer-full path does not. When vcpu0 is offline, the notification remains pending and the guest never receives it. Extract the common notification injection path and reuse it from ffa_raise_rx_buffer_full(). The shared helper delivers the global notification to the first online vCPU and keeps the existing ratelimited debug message when none are online. Functional impact: RX-buffer-full notifications are delivered even when vcpu0 is offline. Fixes: 3935c705688e ("xen/arm: ffa: Add buffer full notification support") Signed-off-by: Bertrand Marquis Reviewed-by: Jens Wiklander --- Changes since v2: - none Changes since v1: - add R-b from Jens --- xen/arch/arm/tee/ffa_notif.c | 45 ++++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index 186e72641237..07bc5cb3a430 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -19,6 +19,29 @@ static bool __ro_after_init fw_notif_enabled; static unsigned int __ro_after_init notif_sri_irq; +static void inject_notif_pending(struct domain *d) +{ + struct vcpu *v; + + /* + * Since we're only delivering global notification, always + * deliver to the first online vCPU. It doesn't matter + * which we chose, as long as it's available. + */ + for_each_vcpu(d, v) + { + if ( is_vcpu_online(v) ) + { + vgic_inject_irq(d, v, GUEST_FFA_NOTIF_PEND_INTR_ID, true); + return; + } + } + + if ( printk_ratelimit() ) + printk(XENLOG_G_DEBUG "%pd: ffa: can't inject NPI, all vCPUs offline\n", + d); +} + int32_t ffa_handle_notification_bind(struct cpu_user_regs *regs) { struct domain *d = current->domain; @@ -190,7 +213,7 @@ void ffa_raise_rx_buffer_full(struct domain *d) ACCESS_ONCE(ctx->notif.buff_full_pending) = true; if ( !test_and_set_bool(ctx->notif.vm_pending) ) - vgic_inject_irq(d, d->vcpu[0], GUEST_FFA_NOTIF_PEND_INTR_ID, true); + inject_notif_pending(d); } #endif @@ -238,7 +261,6 @@ static void notif_vm_pend_intr(uint16_t vm_id) { struct ffa_ctx *ctx; struct domain *d; - struct vcpu *v; /* * vm_id == 0 means a notifications pending for Xen itself, but @@ -277,24 +299,7 @@ static void notif_vm_pend_intr(uint16_t vm_id) * it. */ ACCESS_ONCE(ctx->notif.secure_pending) = true; - - /* - * Since we're only delivering global notification, always - * deliver to the first online vCPU. It doesn't matter - * which we chose, as long as it's available. - */ - for_each_vcpu(d, v) - { - if ( is_vcpu_online(v) ) - { - vgic_inject_irq(d, v, GUEST_FFA_NOTIF_PEND_INTR_ID, - true); - break; - } - } - if ( !v && printk_ratelimit() ) - printk(XENLOG_G_DEBUG "%pd: ffa: can't inject NPI, all vCPUs offline\n", - d); + inject_notif_pending(d); out_unlock: rcu_unlock_domain(d); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:43:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:43:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407370.1640462 (Exim 4.92) (envelope-from ) id 1x28fK-0000JM-0k; Thu, 03 Sep 2026 14:43:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407370.1640462; Thu, 03 Sep 2026 14:43:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fJ-0000JE-TP; Thu, 03 Sep 2026 14:43:45 +0000 Received: by outflank-mailman (input) for mailman id 1407370; Thu, 03 Sep 2026 14:43:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fI-0000J8-Qu for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:43:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28fH-00FAg5-U5 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:43:44 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a998795-2eae-0a2a0a5409dd-0a2a4501bfc8-22 for ; Thu, 03 Sep 2026 16:43:43 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a99879a-5984-0a2a45010019-d98c6eac890e-1 for ; Thu, 03 Sep 2026 16:43:38 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D1AF01596; Thu, 3 Sep 2026 07:43:33 -0700 (PDT) Received: from C3HXLD123V.arm.com (unknown [10.57.7.135]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 73EFA3F673; Thu, 3 Sep 2026 07:43:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788446617; bh=mxmqrcsBVhcdTQFKurB+Zs99Ktsao9E8vsivza3IAQs=; h=From:To:Cc:Subject:Date:From; b=XSJv8EqRzP68UGIK7MEVv8vHAVIXY9LG1hb5N93r/f9GkWo0iaVk6uu+bDVL8vgz4 lMCGxZ6cDvAXgBBl+dE4x3+v6TqKoiHpTZhjoQS3N/ZFVDifxQf9G20TiC+hBENcew OtpM4Xz6rUfkGgf6+NAJbnnbcydrHD3keDo40N10= From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel Subject: [PATCH v3 0/6] xen/arm: ffa: Harden notifications and enable VM-to-VM delivery Date: Thu, 3 Sep 2026 16:43:25 +0200 Message-ID: X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788446623-BE867757-B72EAF58/0/0 X-purgate-type: clean X-purgate-size: 2840 This series hardens FF-A notification handling in the Arm FF-A mediator and completes local delivery for non-secure VM-to-VM notifications. The serie was pushed and almost completely reviewed before 4.22 release except for the last patch. Hardening and state handling (Patches 1-4): 1) Fix notification pending interrupt delivery when vcpu0 is offline by reusing a common global NPI injection helper. 2) Replace the single hypervisor notification boolean with a protected HYP bitmap and keep bitmap lifecycle tied to the cached endpoint ID. 3) Tighten notification parameter validation so malformed BIND, UNBIND, GET, and SET requests are rejected consistently before reaching cached state or the SPMC. 4) Preserve the secure pending indication until secure notifications are retrieved, protect the secure pending latch with notif_lock, serialize SPMC INFO_GET polling, and keep INFO_GET return width consistent with the caller. Local VM notification delivery (Patches 5-6): 1) Track non-secure VM notification bindings locally, promote pending state to a per-bit bitmap, and validate BIND/UNBIND requests against that state. 2) Deliver non-secure VM-to-VM notifications locally, track whether a local NPI is already armed, and only advertise notification support when firmware capabilities or CONFIG_FFA_VM_TO_VM actually provide it. Backward compatibility: v1.0/v1.1 guests remain compatible. Valid guest-visible notification behavior is preserved; the series only tightens malformed-request handling and enables local non-secure VM-to-VM delivery when CONFIG_FFA_VM_TO_VM is enabled. Gitlab branch with patches: https://gitlab.com/xen-project/people/bmarquis/xen-ffa/-/tree/vm-notif/v3?ref_type=heads CI pass result (fail on both macos jobs, runner unavailable): https://gitlab.com/xen-project/people/bmarquis/xen-ffa/-/pipelines/2816768212 Changes since 2: - remove redundant irq raised cleanup in patch 6 - add R-b from Jens Changes since v1: - Keep pending notification state stable across failed local NPI injection. - Tighten local NPI armed-state tracking for Hypervisor and VM notifications. - Details in each commit message. Bertrand Marquis (6): xen/arm: ffa: Fix NPI injection when vcpu0 is offline xen/arm: ffa: Track hypervisor notifications in a bitmap xen/arm: ffa: Tighten notification parameter validation xen/arm: ffa: Preserve secure notification state when polling SPMC xen/arm: ffa: Track VM notification bindings locally xen/arm: ffa: Deliver VM-to-VM notifications locally xen/arch/arm/tee/ffa.c | 24 ++- xen/arch/arm/tee/ffa_notif.c | 369 +++++++++++++++++++++++++++------ xen/arch/arm/tee/ffa_private.h | 25 ++- 3 files changed, 343 insertions(+), 75 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:43:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:43:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407372.1640480 (Exim 4.92) (envelope-from ) id 1x28fN-0000kG-DS; Thu, 03 Sep 2026 14:43:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407372.1640480; Thu, 03 Sep 2026 14:43:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fN-0000k6-A6; Thu, 03 Sep 2026 14:43:49 +0000 Received: by outflank-mailman (input) for mailman id 1407372; Thu, 03 Sep 2026 14:43:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fL-0000eb-UI for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:43:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28fL-0045Cl-B3 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:43:47 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a998796-bab6-0a2a0a5309dd-0a2a45079d14-36 for ; Thu, 03 Sep 2026 16:43:47 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a9987a2-b4ea-0a2a45070019-d98c6eacd0ba-1 for ; Thu, 03 Sep 2026 16:43:47 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 440971650; Thu, 3 Sep 2026 07:43:42 -0700 (PDT) Received: from C3HXLD123V.arm.com (unknown [10.57.7.135]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A96A53F673; Thu, 3 Sep 2026 07:43:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788446626; bh=lKLze3b1RPc7u9ZAKqZaTJVfvYpzgKeUhZbYUNQQYiM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AUeLYaPCjKSvTIt75pPwHa8YZA8K0g0aqJpGoYnsSvfkamHmqY128/ioVj/1bWeGf batT3UNsLVcW9JdQxCVCNrV5sl0t+HeNHxwgwmwNxpGXfjH5LXeaimd91XXcFJyMsY GhvdEpMQhz95BhIwfIBBdBuHMDmBq7x/pwRjkSPA= From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel , Jens Wiklander Subject: [PATCH v3 2/6] xen/arm: ffa: Track hypervisor notifications in a bitmap Date: Thu, 3 Sep 2026 16:43:27 +0200 Message-ID: <39cce5e806b7070da7d4a627bd739b7de711db4b.1788268510.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788446627-35CC7AE4-A5EC4A42/0/0 X-purgate-type: clean X-purgate-size: 6900 Hypervisor notifications are currently tracked with a dedicated buff_full_pending boolean. The old RX-buffer-full path also exposed a pending indication indirectly via vm_pending, so FFA_NOTIFICATION_INFO_GET could clear that summary before the guest retrieved the Hypervisor notification bitmap with FFA_NOTIFICATION_GET. Replace the single boolean with a Hypervisor notification bitmap protected by notif_lock. INFO_GET reports pending when hyp_pending is non-zero, GET returns and clears the HYP bitmap under the lock, and RX-buffer-full now keeps notif_lock held across the local NPI decision. notif_irq_raised is only set when an NPI is actually injected, and is cleared once the local pending state is consumed. Initialize and clear the bitmap during domain lifecycle handling, and use ctx->ffa_id for bitmap create and destroy so the notification state stays tied to the cached FF-A endpoint ID. If the local injection attempt fails because no vCPU is online, hyp_pending remains set and notif_irq_raised remains clear. This keeps the RX-buffer-full notification pending until the guest retrieves it, without publishing a successful local IRQ state too early. Functional impact: RX-buffer-full remains pending in hyp_pending until FFA_NOTIFICATION_GET, and failed local NPI injection no longer leaves Xen thinking the interrupt was already raised. Signed-off-by: Bertrand Marquis Reviewed-by: Jens Wiklander --- Changes since v2: - add Jens R-b Changes since v1: - clarify that v1 exposed RX-buffer-full indirectly via vm_pending - document that v2 keeps the HYP pending indication until FFA_NOTIFICATION_GET - keep RX-buffer-full pending state stable across failed local NPI injection attempts --- xen/arch/arm/tee/ffa_notif.c | 56 ++++++++++++++++++++++++++-------- xen/arch/arm/tee/ffa_private.h | 15 +++++++-- 2 files changed, 56 insertions(+), 15 deletions(-) diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index 07bc5cb3a430..a631481e3815 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -19,7 +19,7 @@ static bool __ro_after_init fw_notif_enabled; static unsigned int __ro_after_init notif_sri_irq; -static void inject_notif_pending(struct domain *d) +static bool inject_notif_pending(struct domain *d) { struct vcpu *v; @@ -33,13 +33,15 @@ static void inject_notif_pending(struct domain *d) if ( is_vcpu_online(v) ) { vgic_inject_irq(d, v, GUEST_FFA_NOTIF_PEND_INTR_ID, true); - return; + return true; } } if ( printk_ratelimit() ) printk(XENLOG_G_DEBUG "%pd: ffa: can't inject NPI, all vCPUs offline\n", d); + + return false; } int32_t ffa_handle_notification_bind(struct cpu_user_regs *regs) @@ -94,8 +96,15 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs) notif_pending = test_and_clear_bool(ctx->notif.secure_pending); if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) + { notif_pending |= test_and_clear_bool(ctx->notif.vm_pending); + spin_lock(&ctx->notif.notif_lock); + if ( ctx->notif.hyp_pending ) + notif_pending = true; + spin_unlock(&ctx->notif.notif_lock); + } + if ( notif_pending ) { /* A pending global notification for the guest */ @@ -174,12 +183,19 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs) w6 = resp.a6; } - if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && - flags & FFA_NOTIF_FLAG_BITMAP_HYP && - test_and_clear_bool(ctx->notif.buff_full_pending) ) + if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) { - ACCESS_ONCE(ctx->notif.vm_pending) = false; - w7 = FFA_NOTIF_RX_BUFFER_FULL; + spin_lock(&ctx->notif.notif_lock); + + if ( (flags & FFA_NOTIF_FLAG_BITMAP_HYP) && ctx->notif.hyp_pending ) + { + w7 = ctx->notif.hyp_pending; + ctx->notif.hyp_pending = 0; + if ( !ctx->notif.vm_pending ) + ctx->notif.notif_irq_raised = false; + } + + spin_unlock(&ctx->notif.notif_lock); } ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, w4, w5, w6, w7); @@ -211,9 +227,12 @@ void ffa_raise_rx_buffer_full(struct domain *d) if ( !ctx ) return; - ACCESS_ONCE(ctx->notif.buff_full_pending) = true; - if ( !test_and_set_bool(ctx->notif.vm_pending) ) - inject_notif_pending(d); + spin_lock(&ctx->notif.notif_lock); + ctx->notif.hyp_pending |= FFA_NOTIF_RX_BUFFER_FULL; + if ( !ctx->notif.notif_irq_raised && + inject_notif_pending(d) ) + ctx->notif.notif_irq_raised = true; + spin_unlock(&ctx->notif.notif_lock); } #endif @@ -426,12 +445,16 @@ void ffa_notif_init(void) int ffa_notif_domain_init(struct domain *d) { + struct ffa_ctx *ctx = d->arch.tee; int32_t res; + spin_lock_init(&ctx->notif.notif_lock); + ctx->notif.notif_irq_raised = false; + ctx->notif.hyp_pending = 0; + if ( fw_notif_enabled ) { - - res = ffa_notification_bitmap_create(ffa_get_vm_id(d), d->max_vcpus); + res = ffa_notification_bitmap_create(ctx->ffa_id, d->max_vcpus); if ( res ) return -ENOMEM; } @@ -441,10 +464,17 @@ int ffa_notif_domain_init(struct domain *d) void ffa_notif_domain_destroy(struct domain *d) { + struct ffa_ctx *ctx = d->arch.tee; + + spin_lock(&ctx->notif.notif_lock); + ctx->notif.notif_irq_raised = false; + ctx->notif.hyp_pending = 0; + spin_unlock(&ctx->notif.notif_lock); + /* * Call bitmap_destroy even if bitmap create failed as the SPMC will * return a DENIED error that we will ignore. */ if ( fw_notif_enabled ) - ffa_notification_bitmap_destroy(ffa_get_vm_id(d)); + ffa_notification_bitmap_destroy(ctx->ffa_id); } diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h index e16bc0d83df3..025dfe6fed7b 100644 --- a/xen/arch/arm/tee/ffa_private.h +++ b/xen/arch/arm/tee/ffa_private.h @@ -340,9 +340,20 @@ struct ffa_ctx_notif { bool vm_pending; /* - * True if domain has buffer full notification pending + * Lock protecting the hypervisor-managed notification state. */ - bool buff_full_pending; + spinlock_t notif_lock; + + /* + * Tracks whether a local notification pending interrupt was raised. + * Protected by notif_lock. + */ + bool notif_irq_raised; + + /* + * Bitmap of pending hypervisor notifications (for HYP bitmap queries). + */ + uint32_t hyp_pending; }; struct ffa_ctx { -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:43:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:43:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407374.1640489 (Exim 4.92) (envelope-from ) id 1x28fP-0000z5-Ku; Thu, 03 Sep 2026 14:43:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407374.1640489; Thu, 03 Sep 2026 14:43:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fP-0000yr-H5; Thu, 03 Sep 2026 14:43:51 +0000 Received: by outflank-mailman (input) for mailman id 1407374; Thu, 03 Sep 2026 14:43:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fN-0000kY-Js for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:43:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28fN-0045Cl-0K for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:43:49 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a998799-bab6-0a2a0a5309dd-0a2a4508ed7e-32 for ; Thu, 03 Sep 2026 16:43:48 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a9987a4-f659-0a2a45080019-d98c6eacd0c0-1 for ; Thu, 03 Sep 2026 16:43:48 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EA32E1596; Thu, 3 Sep 2026 07:43:43 -0700 (PDT) Received: from C3HXLD123V.arm.com (unknown [10.57.7.135]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6269A3F673; Thu, 3 Sep 2026 07:43:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788446627; bh=1qC+KeWmCIuBxYNLKqeIe9W9yoXmdFcEs5sm74Rmt9Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CA6AvtqkAIE0H3PwHE+KDhP0lxFY63e/bqCYni+vjHqXGjOhHqO2/KE+eho2nOh5Z Gu4ZLmaxiVFWUReZZkehpC1/bFL2n6lcdD4bM6wV9apiT14j3t1pqZVATM1/kk8ZtY rsPekRlWrlFaohTbP6Rk6RVEvoaguYMOcBGt1K+I= From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel , Jens Wiklander Subject: [PATCH v3 3/6] xen/arm: ffa: Tighten notification parameter validation Date: Thu, 3 Sep 2026 16:43:28 +0200 Message-ID: <980875f99fe01ea85f2e453ea447fd14f07c5f5a.1788268510.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788446628-D4B7187B-4489A60F/0/0 X-purgate-type: clean X-purgate-size: 6058 The notification handlers still validate overlapping subsets of their inputs. BIND, UNBIND, and SET each decode caller and destination IDs locally, GET still accepts a non-zero receiver vCPU ID and reserved flag bits, and SET still accepts non-zero NS-virtual flags. BIND also treats unsupported non-zero flag encodings as a supported-feature failure instead of as malformed input. Add ffa_notif_validate_params() and use it to centralize the common caller/destination and non-zero bitmap checks for BIND, UNBIND, and SET. Also reject malformed GET and SET requests locally before touching cached state or forwarding anything to the SPMC. Keep BIND limited to global notifications and reject unsupported non-zero flag encodings with INVALID_PARAMETERS. - add a shared parameter validator for notification caller/destination checks - wire BIND and UNBIND through the shared helper and reject unsupported bind flag encodings with INVALID_PARAMETERS - reject non-zero receiver vCPU and reserved flag bits in FFA_NOTIFICATION_GET - reject non-zero flags in the NS-virtual FFA_NOTIFICATION_SET path Functional impact: malformed notification requests are rejected consistently earlier in the mediator. Signed-off-by: Bertrand Marquis Reviewed-by: Jens Wiklander --- Changes since v2: - none Changes since v1: - rename helper to ffa_notif_validate_params() - add R-b from Jens --- xen/arch/arm/tee/ffa_notif.c | 61 +++++++++++++++++++++++++++++------- 1 file changed, 50 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index a631481e3815..1260f98a77e9 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -44,21 +44,40 @@ static bool inject_notif_pending(struct domain *d) return false; } +static int32_t ffa_notif_validate_params(uint16_t dom_id, uint16_t caller_id, + uint16_t dest_id, uint32_t bitmap_lo, + uint32_t bitmap_hi) +{ + if ( caller_id != dom_id || dest_id == dom_id || !dest_id ) + return FFA_RET_INVALID_PARAMETERS; + + if ( !bitmap_lo && !bitmap_hi ) + return FFA_RET_INVALID_PARAMETERS; + + return FFA_RET_OK; +} + int32_t ffa_handle_notification_bind(struct cpu_user_regs *regs) { struct domain *d = current->domain; + struct ffa_ctx *ctx = d->arch.tee; + int32_t ret; uint32_t src_dst = get_user_reg(regs, 1); uint32_t flags = get_user_reg(regs, 2); uint32_t bitmap_lo = get_user_reg(regs, 3); uint32_t bitmap_hi = get_user_reg(regs, 4); + uint16_t caller_id = src_dst & GENMASK(15, 0); + uint16_t dest_id = src_dst >> 16; - if ( (src_dst & GENMASK(15, 0)) != ffa_get_vm_id(d) ) + if ( flags ) /* Only global notifications are supported */ return FFA_RET_INVALID_PARAMETERS; - if ( flags ) /* Only global notifications are supported */ - return FFA_RET_DENIED; + ret = ffa_notif_validate_params(ctx->ffa_id, caller_id, dest_id, + bitmap_lo, bitmap_hi); + if ( ret ) + return ret; - if ( FFA_ID_IS_SECURE(src_dst >> 16) && fw_notif_enabled ) + if ( FFA_ID_IS_SECURE(dest_id) && fw_notif_enabled ) return ffa_simple_call(FFA_NOTIFICATION_BIND, src_dst, flags, bitmap_lo, bitmap_hi); @@ -68,16 +87,22 @@ int32_t ffa_handle_notification_bind(struct cpu_user_regs *regs) int32_t ffa_handle_notification_unbind(struct cpu_user_regs *regs) { struct domain *d = current->domain; + struct ffa_ctx *ctx = d->arch.tee; + int32_t ret; uint32_t src_dst = get_user_reg(regs, 1); uint32_t bitmap_lo = get_user_reg(regs, 3); uint32_t bitmap_hi = get_user_reg(regs, 4); + uint16_t caller_id = src_dst & GENMASK(15, 0); + uint16_t dest_id = src_dst >> 16; - if ( (src_dst & GENMASK(15, 0)) != ffa_get_vm_id(d) ) - return FFA_RET_INVALID_PARAMETERS; + ret = ffa_notif_validate_params(ctx->ffa_id, caller_id, dest_id, + bitmap_lo, bitmap_hi); + if ( ret ) + return ret; - if ( FFA_ID_IS_SECURE(src_dst >> 16) && fw_notif_enabled ) - return ffa_simple_call(FFA_NOTIFICATION_UNBIND, src_dst, 0, bitmap_lo, - bitmap_hi); + if ( FFA_ID_IS_SECURE(dest_id) && fw_notif_enabled ) + return ffa_simple_call(FFA_NOTIFICATION_UNBIND, src_dst, 0, bitmap_lo, + bitmap_hi); return FFA_RET_NOT_SUPPORTED; } @@ -144,6 +169,12 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs) return; } + if ( recv >> 16 || (flags & GENMASK(31, 4)) ) + { + ffa_set_regs_error(regs, FFA_RET_INVALID_PARAMETERS); + return; + } + if ( fw_notif_enabled && (flags & ( FFA_NOTIF_FLAG_BITMAP_SP | FFA_NOTIF_FLAG_BITMAP_SPM )) ) { @@ -208,11 +239,19 @@ int32_t ffa_handle_notification_set(struct cpu_user_regs *regs) uint32_t flags = get_user_reg(regs, 2); uint32_t bitmap_lo = get_user_reg(regs, 3); uint32_t bitmap_hi = get_user_reg(regs, 4); + uint16_t caller_id = src_dst >> 16; + uint16_t dest_id = src_dst & GENMASK(15, 0); + int32_t ret; + + ret = ffa_notif_validate_params(ffa_get_vm_id(d), caller_id, dest_id, + bitmap_lo, bitmap_hi); + if ( ret ) + return ret; - if ( (src_dst >> 16) != ffa_get_vm_id(d) ) + if ( flags ) return FFA_RET_INVALID_PARAMETERS; - if ( FFA_ID_IS_SECURE(src_dst & GENMASK(15, 0)) && fw_notif_enabled ) + if ( FFA_ID_IS_SECURE(dest_id) && fw_notif_enabled ) return ffa_simple_call(FFA_NOTIFICATION_SET, src_dst, flags, bitmap_lo, bitmap_hi); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:43:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:43:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407375.1640499 (Exim 4.92) (envelope-from ) id 1x28fR-0001Dj-36; Thu, 03 Sep 2026 14:43:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407375.1640499; Thu, 03 Sep 2026 14:43:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fQ-0001Db-UJ; Thu, 03 Sep 2026 14:43:52 +0000 Received: by outflank-mailman (input) for mailman id 1407375; Thu, 03 Sep 2026 14:43:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fP-0000yY-Eg for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:43:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28fO-007phI-Rd for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:43:50 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9987a0-8faa-0a2a0a5109dd-0a2a4509a978-22 for ; Thu, 03 Sep 2026 16:43:50 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a9987a6-be1a-0a2a45090019-d98c6eac8944-1 for ; Thu, 03 Sep 2026 16:43:50 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E6D0E1D34; Thu, 3 Sep 2026 07:43:45 -0700 (PDT) Received: from C3HXLD123V.arm.com (unknown [10.57.7.135]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 335423F673; Thu, 3 Sep 2026 07:43:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788446629; bh=FIdh3x8TqhKm9Ak6XoWn7O6Wy2XrLZyhKI2PMzdoAio=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uc+XZYDJwzwQGdV5IBfpRcERfG2NYapspe9NV0I8nwm1avk1dMod5rLGJii06yXfl mwmv/U6vMu3lMK0xwZExilbPTVubydshkQGPchAWXgfq4K4AfZA5CoJsrlsgsjtyBP OvfshOMOKM2JiMxxnHH1IBdDp91zkBVqPqa9hqNA= From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel , Jens Wiklander Subject: [PATCH v3 4/6] xen/arm: ffa: Preserve secure notification state when polling SPMC Date: Thu, 3 Sep 2026 16:43:29 +0200 Message-ID: <55fcc151f60b749e167e7cf4488bd315a22e5944.1788268510.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1788446630-39EC6034-5813DE16/0/0 X-purgate-type: clean X-purgate-size: 7293 Secure pending state is latched when the SPMC raises the schedule receiver interrupt, but Xen currently clears that latch too aggressively. Guest FFA_NOTIFICATION_INFO_GET consumes secure_pending even though it only reports pending state, and secure FFA_NOTIFICATION_GET only clears the latch when both SP and SPM bitmaps are requested together. This can drop a pending indication before the receiver retrieves secure notifications, or keep INFO_GET reporting stale secure pending state after a successful GET. Keep secure_pending as a latched indication until secure notifications are actually retrieved. Guest FFA_NOTIFICATION_INFO_GET now reports the latched state without clearing it, while a successful secure FFA_NOTIFICATION_GET clears the latch regardless of which secure bitmap flags were requested. Also protect secure_pending with notif_lock, serialize SPMC INFO_GET polling behind notif_info_lock, and preserve the caller-visible INFO_GET success width. Functional impact: guest INFO_GET preserves the secure pending indication until secure notifications are retrieved, and successful secure GET clears the guest-visible pending latch. Signed-off-by: Bertrand Marquis Reviewed-by: Jens Wiklander --- Changes since v2: - add Jens R-b Changes since v1: - drop the defensive fw_notif_enabled guard in notif_sri_action() --- xen/arch/arm/tee/ffa_notif.c | 51 ++++++++++++++++++++++-------------- 1 file changed, 32 insertions(+), 19 deletions(-) diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index 1260f98a77e9..e1cd852d1c53 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -18,6 +18,7 @@ static bool __ro_after_init fw_notif_enabled; static unsigned int __ro_after_init notif_sri_irq; +static DEFINE_SPINLOCK(notif_info_lock); static bool inject_notif_pending(struct domain *d) { @@ -111,6 +112,7 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs) { struct domain *d = current->domain; struct ffa_ctx *ctx = d->arch.tee; + uint32_t fid = get_user_reg(regs, 0); bool notif_pending; if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !fw_notif_enabled ) @@ -119,7 +121,10 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs) return; } - notif_pending = test_and_clear_bool(ctx->notif.secure_pending); + spin_lock(&ctx->notif.notif_lock); + notif_pending = ctx->notif.secure_pending; + spin_unlock(&ctx->notif.notif_lock); + if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) { notif_pending |= test_and_clear_bool(ctx->notif.vm_pending); @@ -133,7 +138,9 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs) if ( notif_pending ) { /* A pending global notification for the guest */ - ffa_set_regs(regs, FFA_SUCCESS_64, 0, + ffa_set_regs(regs, + smccc_is_conv_64(fid) ? FFA_SUCCESS_64 : FFA_SUCCESS_32, + 0, 1U << FFA_NOTIF_INFO_GET_ID_COUNT_SHIFT, ffa_get_vm_id(d), 0, 0, 0, 0); } @@ -156,6 +163,8 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs) uint32_t w5 = 0; uint32_t w6 = 0; uint32_t w7 = 0; + uint32_t secure_flags = flags & ( FFA_NOTIF_FLAG_BITMAP_SP | + FFA_NOTIF_FLAG_BITMAP_SPM ); if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !fw_notif_enabled ) { @@ -175,27 +184,16 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs) return; } - if ( fw_notif_enabled && (flags & ( FFA_NOTIF_FLAG_BITMAP_SP | - FFA_NOTIF_FLAG_BITMAP_SPM )) ) + if ( fw_notif_enabled && secure_flags ) { struct arm_smccc_1_2_regs arg = { .a0 = FFA_NOTIFICATION_GET, .a1 = recv, - .a2 = flags & ( FFA_NOTIF_FLAG_BITMAP_SP | - FFA_NOTIF_FLAG_BITMAP_SPM ), + .a2 = secure_flags, }; struct arm_smccc_1_2_regs resp; int32_t e; - /* - * Clear secure pending if both FFA_NOTIF_FLAG_BITMAP_SP and - * FFA_NOTIF_FLAG_BITMAP_SPM are set since secure world can't have - * any more pending notifications. - */ - if ( ( flags & FFA_NOTIF_FLAG_BITMAP_SP ) && - ( flags & FFA_NOTIF_FLAG_BITMAP_SPM ) ) - ACCESS_ONCE(ctx->notif.secure_pending) = false; - arm_smccc_1_2_smc(&arg, &resp); e = ffa_get_ret_code(&resp); if ( e ) @@ -212,6 +210,10 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs) if ( flags & FFA_NOTIF_FLAG_BITMAP_SPM ) w6 = resp.a6; + + spin_lock(&ctx->notif.notif_lock); + ctx->notif.secure_pending = false; + spin_unlock(&ctx->notif.notif_lock); } if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) @@ -356,7 +358,10 @@ static void notif_vm_pend_intr(uint16_t vm_id) * guarantees that the data structure isn't freed while we're accessing * it. */ - ACCESS_ONCE(ctx->notif.secure_pending) = true; + spin_lock(&ctx->notif.notif_lock); + ctx->notif.secure_pending = true; + spin_unlock(&ctx->notif.notif_lock); + inject_notif_pending(d); out_unlock: @@ -375,11 +380,15 @@ static void notif_sri_action(void *unused) unsigned int n; int32_t res; - do { + spin_lock(¬if_info_lock); + + do + { arm_smccc_1_2_smc(&arg, &resp); res = ffa_get_ret_code(&resp); if ( res ) { + spin_unlock(¬if_info_lock); if ( res != FFA_RET_NO_DATA && printk_ratelimit() ) printk(XENLOG_WARNING "ffa: notification info get failed: error %d\n", res); @@ -393,7 +402,7 @@ static void notif_sri_action(void *unused) id_pos = 0; for ( n = 0; n < list_count; n++ ) { - unsigned int count = ((ids_count >> 2 * n) & 0x3) + 1; + unsigned int count = ((ids_count >> (2 * n)) & 0x3) + 1; uint16_t vm_id = get_id_from_resp(&resp, id_pos); notif_vm_pend_intr(vm_id); @@ -401,7 +410,9 @@ static void notif_sri_action(void *unused) id_pos += count; } - } while (resp.a2 & FFA_NOTIF_INFO_GET_MORE_FLAG); + } while ( resp.a2 & FFA_NOTIF_INFO_GET_MORE_FLAG ); + + spin_unlock(¬if_info_lock); } static DECLARE_TASKLET(notif_sri_tasklet, notif_sri_action, NULL); @@ -489,6 +500,7 @@ int ffa_notif_domain_init(struct domain *d) spin_lock_init(&ctx->notif.notif_lock); ctx->notif.notif_irq_raised = false; + ctx->notif.secure_pending = false; ctx->notif.hyp_pending = 0; if ( fw_notif_enabled ) @@ -507,6 +519,7 @@ void ffa_notif_domain_destroy(struct domain *d) spin_lock(&ctx->notif.notif_lock); ctx->notif.notif_irq_raised = false; + ctx->notif.secure_pending = false; ctx->notif.hyp_pending = 0; spin_unlock(&ctx->notif.notif_lock); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:43:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:43:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407376.1640507 (Exim 4.92) (envelope-from ) id 1x28fS-0001TD-AP; Thu, 03 Sep 2026 14:43:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407376.1640507; Thu, 03 Sep 2026 14:43:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fS-0001SI-6S; Thu, 03 Sep 2026 14:43:54 +0000 Received: by outflank-mailman (input) for mailman id 1407376; Thu, 03 Sep 2026 14:43:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fR-0001De-4Y for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:43:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28fQ-00Ap6r-HT for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:43:52 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a998797-e002-0a2a0a5209dd-0a2a4504af4a-32 for ; Thu, 03 Sep 2026 16:43:52 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a9987a7-b57f-0a2a45040019-d98c6eac884c-1 for ; Thu, 03 Sep 2026 16:43:52 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A1BE01650; Thu, 3 Sep 2026 07:43:47 -0700 (PDT) Received: from C3HXLD123V.arm.com (unknown [10.57.7.135]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 123683F673; Thu, 3 Sep 2026 07:43:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788446631; bh=pa6oZ8m/24AdXnyLzD3DBAmh8KUG2PzE4sIQhu9ry14=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OGyb6v0ZeL6+rEj4lNyQK7K8LIkgDb74qkB/mDgcShYXm7n1ZdWBM1aTRxbC7hraq nDrvbQFoLIb07t6/c9MzbfaJ+m6aO7iO+tBOusMSh26oLb+1mUp7rMjDL4iKL6OHKR BrvH3LLDdMWYVmSvdGI2O9locGZAG4PAIsrplCjY= From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel , Jens Wiklander Subject: [PATCH v3 5/6] xen/arm: ffa: Track VM notification bindings locally Date: Thu, 3 Sep 2026 16:43:30 +0200 Message-ID: <3b679d45c4a3fda4763112bc8570fa53129f3883.1788268510.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788446632-C26CAB50-5F136E49/0/0 X-purgate-type: clean X-purgate-size: 7651 VM-to-VM notifications need receiver-side bind state so Xen can validate which sender owns each notification bit. Non-secure BIND and UNBIND requests currently have no local state and cannot enforce that contract. Add per-bit VM notification binding state to struct ffa_ctx_notif and use it to handle non-secure BIND and UNBIND requests when CONFIG_FFA_VM_TO_VM is enabled. The update helper validates the whole request under notif_lock before mutating anything, denies bind or unbind when a bit is pending, rejects rebinding to a different sender, and keeps rebinding to the same sender idempotent. Promote vm_pending to a bitmap so the bind logic can reason per notification ID, use that bitmap directly when reporting pending state, and initialize and clear the new VM notification state during domain init and teardown. Functional impact: when CONFIG_FFA_VM_TO_VM is enabled, Xen tracks VM notification bindings locally and validates non-secure bind and unbind requests against that state. Signed-off-by: Bertrand Marquis Reviewed-by: Jens Wiklander --- Changes since v2: - add Jens R-b Changes since v1: - use memset() to clear vm_bind[] in init/destroy - replace the file-scope #error check with BUILD_BUG_ON() --- xen/arch/arm/tee/ffa_notif.c | 96 ++++++++++++++++++++++++++++++---- xen/arch/arm/tee/ffa_private.h | 11 ++-- 2 files changed, 94 insertions(+), 13 deletions(-) diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index e1cd852d1c53..a841c8f8d747 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include @@ -58,6 +59,54 @@ static int32_t ffa_notif_validate_params(uint16_t dom_id, uint16_t caller_id, return FFA_RET_OK; } +static int32_t ffa_notif_update_vm_binding(struct ffa_ctx *ctx, + uint16_t dest_id, uint64_t bitmap, + bool bind) +{ + unsigned int id; + int32_t ret = FFA_RET_OK; + + spin_lock(&ctx->notif.notif_lock); + + for ( id = 0; id < FFA_NUM_VM_NOTIF; id++ ) + { + if ( !(bitmap & BIT(id, ULL)) ) + continue; + + if ( ctx->notif.vm_pending & BIT(id, ULL) ) + { + ret = FFA_RET_DENIED; + goto out_unlock; + } + + if ( bind ) + { + if ( ctx->notif.vm_bind[id] != 0 && + ctx->notif.vm_bind[id] != dest_id ) + { + ret = FFA_RET_DENIED; + goto out_unlock; + } + } + else if ( ctx->notif.vm_bind[id] != dest_id ) + { + ret = FFA_RET_DENIED; + goto out_unlock; + } + } + + for ( id = 0; id < FFA_NUM_VM_NOTIF; id++ ) + { + if ( bitmap & BIT(id, ULL) ) + ctx->notif.vm_bind[id] = bind ? dest_id : 0; + } + +out_unlock: + spin_unlock(&ctx->notif.notif_lock); + + return ret; +} + int32_t ffa_handle_notification_bind(struct cpu_user_regs *regs) { struct domain *d = current->domain; @@ -78,11 +127,21 @@ int32_t ffa_handle_notification_bind(struct cpu_user_regs *regs) if ( ret ) return ret; - if ( FFA_ID_IS_SECURE(dest_id) && fw_notif_enabled ) - return ffa_simple_call(FFA_NOTIFICATION_BIND, src_dst, flags, - bitmap_lo, bitmap_hi); + if ( FFA_ID_IS_SECURE(dest_id) ) + { + if ( fw_notif_enabled ) + return ffa_simple_call(FFA_NOTIFICATION_BIND, src_dst, flags, + bitmap_lo, bitmap_hi); - return FFA_RET_NOT_SUPPORTED; + return FFA_RET_NOT_SUPPORTED; + } + + if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) + return FFA_RET_NOT_SUPPORTED; + + return ffa_notif_update_vm_binding(ctx, dest_id, + ((uint64_t)bitmap_hi << 32) | bitmap_lo, + true); } int32_t ffa_handle_notification_unbind(struct cpu_user_regs *regs) @@ -101,11 +160,21 @@ int32_t ffa_handle_notification_unbind(struct cpu_user_regs *regs) if ( ret ) return ret; - if ( FFA_ID_IS_SECURE(dest_id) && fw_notif_enabled ) - return ffa_simple_call(FFA_NOTIFICATION_UNBIND, src_dst, 0, bitmap_lo, - bitmap_hi); + if ( FFA_ID_IS_SECURE(dest_id) ) + { + if ( fw_notif_enabled ) + return ffa_simple_call(FFA_NOTIFICATION_UNBIND, src_dst, 0, + bitmap_lo, bitmap_hi); - return FFA_RET_NOT_SUPPORTED; + return FFA_RET_NOT_SUPPORTED; + } + + if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) + return FFA_RET_NOT_SUPPORTED; + + return ffa_notif_update_vm_binding(ctx, dest_id, + ((uint64_t)bitmap_hi << 32) | bitmap_lo, + false); } void ffa_handle_notification_info_get(struct cpu_user_regs *regs) @@ -127,9 +196,10 @@ void ffa_handle_notification_info_get(struct cpu_user_regs *regs) if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) { - notif_pending |= test_and_clear_bool(ctx->notif.vm_pending); - spin_lock(&ctx->notif.notif_lock); + if ( ctx->notif.vm_pending ) + notif_pending = true; + if ( ctx->notif.hyp_pending ) notif_pending = true; spin_unlock(&ctx->notif.notif_lock); @@ -498,9 +568,13 @@ int ffa_notif_domain_init(struct domain *d) struct ffa_ctx *ctx = d->arch.tee; int32_t res; + BUILD_BUG_ON(FFA_NUM_VM_NOTIF > 64); + spin_lock_init(&ctx->notif.notif_lock); ctx->notif.notif_irq_raised = false; ctx->notif.secure_pending = false; + ctx->notif.vm_pending = 0; + memset(ctx->notif.vm_bind, 0, sizeof(ctx->notif.vm_bind)); ctx->notif.hyp_pending = 0; if ( fw_notif_enabled ) @@ -520,6 +594,8 @@ void ffa_notif_domain_destroy(struct domain *d) spin_lock(&ctx->notif.notif_lock); ctx->notif.notif_irq_raised = false; ctx->notif.secure_pending = false; + ctx->notif.vm_pending = 0; + memset(ctx->notif.vm_bind, 0, sizeof(ctx->notif.vm_bind)); ctx->notif.hyp_pending = 0; spin_unlock(&ctx->notif.notif_lock); diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h index 025dfe6fed7b..30c064e2dc30 100644 --- a/xen/arch/arm/tee/ffa_private.h +++ b/xen/arch/arm/tee/ffa_private.h @@ -236,6 +236,7 @@ #define FFA_NOTIF_INFO_GET_ID_COUNT_MASK 0x1F #define FFA_NOTIF_RX_BUFFER_FULL BIT(0, U) +#define FFA_NUM_VM_NOTIF 64U /* Feature IDs used with FFA_FEATURES */ #define FFA_FEATURE_NOTIF_PEND_INTR 0x1U @@ -334,10 +335,14 @@ struct ffa_ctx_notif { bool secure_pending; /* - * True if domain is reported by FFA_NOTIFICATION_INFO_GET to have - * pending notifications from VMs (including framework ones). + * Bitmap of pending notifications from VMs (including framework ones). + */ + uint64_t vm_pending; + + /* + * Source endpoint bound to each VM notification ID (0 means unbound). */ - bool vm_pending; + uint16_t vm_bind[FFA_NUM_VM_NOTIF]; /* * Lock protecting the hypervisor-managed notification state. -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 14:43:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 14:43:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407378.1640516 (Exim 4.92) (envelope-from ) id 1x28fU-0001kc-LY; Thu, 03 Sep 2026 14:43:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407378.1640516; Thu, 03 Sep 2026 14:43:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fU-0001kV-GP; Thu, 03 Sep 2026 14:43:56 +0000 Received: by outflank-mailman (input) for mailman id 1407378; Thu, 03 Sep 2026 14:43:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28fS-0001Wj-Op for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 14:43:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28fS-00Ap6r-5U for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:43:54 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9987a6-e002-0a2a0a5209dd-0a2a4503a126-8 for ; Thu, 03 Sep 2026 16:43:54 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6a9987a9-fae8-0a2a45030019-d98c6eacc06c-1 for ; Thu, 03 Sep 2026 16:43:53 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3CE5E1596; Thu, 3 Sep 2026 07:43:49 -0700 (PDT) Received: from C3HXLD123V.arm.com (unknown [10.57.7.135]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DA9213F673; Thu, 3 Sep 2026 07:43:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1788446633; bh=2RiwZlyuUPZr3BL6OvfCnly9DXHp8ba50e2fDBTUIes=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qUyqMKitmr54/ha23EVQ7gzVumVCjg9/UqtgVxkMlMyEFBP+egP62l2+taWCE/6fO dQlOaK+vGHPJJXq4JD23x4YuEZ4hE5ERmGlG7grsWFE6zyaOVuC7xmL5aig7AS1nKX vb3jNSdbTbj+MCnNduVxF6UryG0hN+7lsKLR/Njo= From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel Subject: [PATCH v3 6/6] xen/arm: ffa: Deliver VM-to-VM notifications locally Date: Thu, 3 Sep 2026 16:43:31 +0200 Message-ID: <24033eeb87446cda8c91f27a453317417328fd5f.1788268510.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788446634-74E874E9-6A154D21/0/0 X-purgate-type: clean X-purgate-size: 9857 VM notification binding and pending tracking exist for non-secure endpoints, but FFA_NOTIFICATION_SET still only forwards secure destinations to the SPMC. Non-secure VMs therefore cannot receive notifications from other VMs. Local NPI delivery also needs explicit re-arm tracking so repeated raises are not lost while the interrupt is already pending. Add a local VM notification delivery path for non-secure destinations. notification_set_vm() resolves the destination endpoint, verifies that every requested bit is bound to the sender, sets the receiver's vm_pending bitmap under notif_lock, and raises an NPI only when local pending state is not already armed. Track whether a local NPI is already armed with notif_irq_raised, clear that state once both VM and hypervisor pending bitmaps are drained, and keep notif_lock held across the VM notification injection attempt. If no destination vCPU is online, leave the pending bits set and keep notif_irq_raised clear so delivery can be retried later. Also expose firmware notification availability so FFA_FEATURES only advertises notification support when it is actually provided by the firmware or by CONFIG_FFA_VM_TO_VM. Functional impact: when CONFIG_FFA_VM_TO_VM is enabled, non-secure FFA_NOTIFICATION_SET delivers VM-to-VM notifications locally and keeps NPI delivery reliable across repeated raises. Signed-off-by: Bertrand Marquis --- Changes since v2: - remove redundant irq raised cleanup (Jens) Changes since v1: - serialize notification_set_vm() state updates with the NPI attempt - keep pending VM notifications set when local injection fails --- xen/arch/arm/tee/ffa.c | 24 ++++++++-- xen/arch/arm/tee/ffa_notif.c | 84 ++++++++++++++++++++++++++++++++-- xen/arch/arm/tee/ffa_private.h | 17 ++++--- 3 files changed, 107 insertions(+), 18 deletions(-) diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c index 1fe33f26454a..7fe021049cba 100644 --- a/xen/arch/arm/tee/ffa.c +++ b/xen/arch/arm/tee/ffa.c @@ -39,8 +39,13 @@ * o FFA_MSG_SEND_DIRECT_REQ: * - only supported from a VM to an SP * o FFA_NOTIFICATION_*: + * - only supported when firmware notifications are enabled or VM-to-VM + * support is built in * - only supports global notifications, that is, per vCPU notifications - * are not supported + * are not supported and secure per-vCPU notification information is + * not forwarded + * - the source endpoint ID reported for a notification may no longer + * exist by the time the receiver consumes it * - doesn't support signalling the secondary scheduler of pending * notification for secure partitions * - doesn't support notifications for Xen itself @@ -245,6 +250,8 @@ static void handle_features(struct cpu_user_regs *regs) uint32_t a1 = get_user_reg(regs, 1); struct domain *d = current->domain; struct ffa_ctx *ctx = d->arch.tee; + bool notif_supported = IS_ENABLED(CONFIG_FFA_VM_TO_VM) || + ffa_notif_fw_enabled(); /* * FFA_FEATURES defines w2 as input properties only for specific @@ -343,10 +350,16 @@ static void handle_features(struct cpu_user_regs *regs) break; case FFA_FEATURE_NOTIF_PEND_INTR: - ffa_set_regs_success(regs, GUEST_FFA_NOTIF_PEND_INTR_ID, 0); + if ( notif_supported ) + ffa_set_regs_success(regs, GUEST_FFA_NOTIF_PEND_INTR_ID, 0); + else + ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); break; case FFA_FEATURE_SCHEDULE_RECV_INTR: - ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, 0); + if ( notif_supported ) + ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, 0); + else + ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); break; case FFA_PARTITION_INFO_GET_REGS: if ( ACCESS_ONCE(ctx->guest_vers) >= FFA_VERSION_1_2 ) @@ -361,7 +374,10 @@ static void handle_features(struct cpu_user_regs *regs) case FFA_NOTIFICATION_SET: case FFA_NOTIFICATION_INFO_GET_32: case FFA_NOTIFICATION_INFO_GET_64: - ffa_set_regs_success(regs, 0, 0); + if ( notif_supported ) + ffa_set_regs_success(regs, 0, 0); + else + ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); break; default: ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index a841c8f8d747..4ca2f75605bb 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -21,6 +21,11 @@ static bool __ro_after_init fw_notif_enabled; static unsigned int __ro_after_init notif_sri_irq; static DEFINE_SPINLOCK(notif_info_lock); +bool ffa_notif_fw_enabled(void) +{ + return fw_notif_enabled; +} + static bool inject_notif_pending(struct domain *d) { struct vcpu *v; @@ -107,6 +112,55 @@ out_unlock: return ret; } +/* + * Deliver a VM-to-VM notification. ctx->notif.notif_lock protects + * vm_bind/vm_pending so callers must not hold it already. + */ +static int32_t notification_set_vm(uint16_t dst_id, uint16_t src_id, + uint32_t flags, uint64_t bitmap) +{ + struct domain *dst_d; + struct ffa_ctx *dst_ctx; + unsigned int id; + int32_t ret; + + if ( flags ) + return FFA_RET_INVALID_PARAMETERS; + + ret = ffa_endpoint_domain_lookup(dst_id, &dst_d, &dst_ctx); + if ( ret ) + return ret; + + ret = FFA_RET_OK; + + spin_lock(&dst_ctx->notif.notif_lock); + + for ( id = 0; id < FFA_NUM_VM_NOTIF; id++ ) + { + if ( !(bitmap & BIT(id, ULL)) ) + continue; + + if ( dst_ctx->notif.vm_bind[id] != src_id ) + { + ret = FFA_RET_DENIED; + goto out_unlock; + } + } + + dst_ctx->notif.vm_pending |= bitmap; + if ( !dst_ctx->notif.notif_irq_raised && + (dst_ctx->notif.vm_pending || dst_ctx->notif.hyp_pending) && + inject_notif_pending(dst_d) ) + dst_ctx->notif.notif_irq_raised = true; + +out_unlock: + spin_unlock(&dst_ctx->notif.notif_lock); + + rcu_unlock_domain(dst_d); + + return ret; +} + int32_t ffa_handle_notification_bind(struct cpu_user_regs *regs) { struct domain *d = current->domain; @@ -288,16 +342,28 @@ void ffa_handle_notification_get(struct cpu_user_regs *regs) if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) { + bool pending; + spin_lock(&ctx->notif.notif_lock); if ( (flags & FFA_NOTIF_FLAG_BITMAP_HYP) && ctx->notif.hyp_pending ) { w7 = ctx->notif.hyp_pending; ctx->notif.hyp_pending = 0; - if ( !ctx->notif.vm_pending ) - ctx->notif.notif_irq_raised = false; } + if ( (flags & FFA_NOTIF_FLAG_BITMAP_VM) && ctx->notif.vm_pending ) + { + w4 = (uint32_t)(ctx->notif.vm_pending & GENMASK(31, 0)); + w5 = (uint32_t)((ctx->notif.vm_pending >> 32) & GENMASK(31, 0)); + ctx->notif.vm_pending = 0; + } + + pending = (ctx->notif.hyp_pending != 0) || + (ctx->notif.vm_pending != 0); + if ( !pending ) + ctx->notif.notif_irq_raised = false; + spin_unlock(&ctx->notif.notif_lock); } @@ -323,9 +389,17 @@ int32_t ffa_handle_notification_set(struct cpu_user_regs *regs) if ( flags ) return FFA_RET_INVALID_PARAMETERS; - if ( FFA_ID_IS_SECURE(dest_id) && fw_notif_enabled ) - return ffa_simple_call(FFA_NOTIFICATION_SET, src_dst, flags, bitmap_lo, - bitmap_hi); + if ( FFA_ID_IS_SECURE(dest_id) ) + { + if ( fw_notif_enabled ) + return ffa_simple_call(FFA_NOTIFICATION_SET, src_dst, flags, + bitmap_lo, bitmap_hi); + } + else if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) + { + return notification_set_vm(dest_id, caller_id, flags, + ((uint64_t)bitmap_hi << 32) | bitmap_lo); + } return FFA_RET_NOT_SUPPORTED; } diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h index 30c064e2dc30..7096207b0528 100644 --- a/xen/arch/arm/tee/ffa_private.h +++ b/xen/arch/arm/tee/ffa_private.h @@ -340,20 +340,18 @@ struct ffa_ctx_notif { uint64_t vm_pending; /* - * Source endpoint bound to each VM notification ID (0 means unbound). + * Tracks whether an NPI has been raised for local pending notifications. + * Protected by notif_lock. */ - uint16_t vm_bind[FFA_NUM_VM_NOTIF]; + bool notif_irq_raised; /* - * Lock protecting the hypervisor-managed notification state. + * Source endpoint bound to each VM notification ID (0 means unbound). */ - spinlock_t notif_lock; + uint16_t vm_bind[FFA_NUM_VM_NOTIF]; - /* - * Tracks whether a local notification pending interrupt was raised. - * Protected by notif_lock. - */ - bool notif_irq_raised; + /* Lock protecting local notification state. */ + spinlock_t notif_lock; /* * Bitmap of pending hypervisor notifications (for HYP bitmap queries). @@ -495,6 +493,7 @@ void ffa_notif_init(void); void ffa_notif_init_interrupt(void); int ffa_notif_domain_init(struct domain *d); void ffa_notif_domain_destroy(struct domain *d); +bool ffa_notif_fw_enabled(void); int32_t ffa_handle_notification_bind(struct cpu_user_regs *regs); int32_t ffa_handle_notification_unbind(struct cpu_user_regs *regs); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 15:03:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 15:03:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407436.1640524 (Exim 4.92) (envelope-from ) id 1x28yI-00079H-9m; Thu, 03 Sep 2026 15:03:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407436.1640524; Thu, 03 Sep 2026 15:03:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28yI-00079A-6x; Thu, 03 Sep 2026 15:03:22 +0000 Received: by outflank-mailman (input) for mailman id 1407436; Thu, 03 Sep 2026 15:03:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x28yE-000794-U0 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:03:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x28yD-0048ez-TX for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 17:03:17 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a998c25-2eae-0a2a0a5409dd-0a2a4503c6f0-44 for ; Thu, 03 Sep 2026 17:03:12 +0200 Received: from [148.163.147.86] (helo=mx0a-002e3701.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a998c2e-fae8-0a2a45030019-94a39356b20e-3 for ; Thu, 03 Sep 2026 17:03:11 +0200 Received: from pps.filterd (m0134421.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 683DC2CB2638187; Thu, 3 Sep 2026 15:02:42 GMT Received: from p1lg14881.it.hpe.com (p1lg14881.it.hpe.com [16.230.97.202]) by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 4gf9easqk8-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 03 Sep 2026 15:02:42 +0000 (GMT) Received: from p1lg14885.dc01.its.hpecorp.net (unknown [10.119.18.236]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by p1lg14881.it.hpe.com (Postfix) with ESMTPS id 1DE43806B11; Thu, 3 Sep 2026 15:02:30 +0000 (UTC) Received: from swahl-home.5wahls.com (unknown [16.231.227.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by p1lg14885.dc01.its.hpecorp.net (Postfix) with ESMTPS id 947A6804D13; Thu, 3 Sep 2026 15:02:26 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pps0720 header.d=hpe.com header.i="@hpe.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pps0720; bh=6TAteaV3/Nh3xyO8rweCVU4LF2 M9k1ERu5CdY2OPHF8=; b=RkG3JGUfihRR+cJ8YXXVtmF8EDz0rk9vtdI0qkgnCr KByWQ6Yn7es8zEketN67z6HcIOjrf2T+CYij5Wl1x2Evl64YQgUwLrbOxZKnCV4j UaD10sRn/DmuE48xTbmoT9Z1GXcNv9S5/KDDCCU7tcEMJA2RTntWnZFIdF80LJT4 vYw7KmAvZ9kqYxf+S4WxJZSFr5nh8OVggqljNUc9JW1+5ZpUDbv7Bx0fqOApM+fL yM2hwQPT9lq6WSvo9VzcKVaRtWECxTCdZe4vTuWcKqu6M1DdoCxPIB661BQ0tjDa nfcoubf9v8JItVmqbnQIOy/Ys5jrgSU8rUk/tcIyfPAQ== Date: Thu, 3 Sep 2026 10:02:24 -0500 From: Steve Wahl To: Daniil Tatianin Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Daniil Tatianin <99danilt@gmail.com>, "H. Peter Anvin" , Steve Wahl , Justin Ernst , Kyle Meyer , Dimitri Sivanich , Russ Anderson , Juergen Gross , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/apic: Remove dead disable_esr machinery Message-ID: References: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTAzMDEzMSBTYWx0ZWRfXzl0gP59njn+0 O+jTJY1gjEqhGkSbF5NnrvLif0btpqRDfsySduIvfoTlLTLoYfZ7lI0bjFDDeo2t265Hxt/y+Yk 82IvK34GeTEXpTjeWTiZpKWpye0Y66LUzILkICdCsWW4GW0ewSTRDgS5Me5SxT4WGZ0KQJL/3KX YCSV3BP/wZsTpy9ERf51YovIRaKYXcov/L06M4UDAcFByPLOa7iR/NINkTESdxuW9z4Lp687Or2 703YATDyRl5tK3sZkZ7UKZFJ/x7Qny+vreovcX20T/GQ3xQfXss6VzvaFdSmuJmrig7M5PZedtt ka1BSn1iN5DvHMZISr8egkMTyNwpzhvG5eSj+t2RjCNUMqay0nlOCyggflAy5DQslkyVB9GQ+HR 8gcwsVD/raOGpwYR0pgF7atSje01laawPLedOCHK72SGfQwdVzz1FM6bij+goSmND+i+hlRXPg+ PtlHGBENFImzXggN+hA== X-Proofpoint-GUID: KRbW7X3Xe2iRh7ECSVMrgjSsOhtLl8wD X-Authority-Analysis: v=2.4 cv=Ws8b99fv c=1 sm=1 tr=0 ts=6a998c12 cx=c_pps a=FAnPgvRYq/vnBSvlTDCQOQ==:117 a=FAnPgvRYq/vnBSvlTDCQOQ==:17 a=kj9zAlcOel0A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=gQcMVamqm3wCPoSYhaRC:22 a=ay80y3fxfMS_JZZz1qJy:22 a=pGLkceISAAAA:8 a=6R7veym_AAAA:8 a=MvuuwTCpAAAA:8 a=NplOCkrURqmMbNQE9EIA:9 a=CjuIK1q_8ugA:10 a=ILCOIF4F_8SzUMnO7jNM:22 X-Proofpoint-ORIG-GUID: KRbW7X3Xe2iRh7ECSVMrgjSsOhtLl8wD X-Proofpoint-Spam-Info: AW1haW4tMjYwOTAzMDEzMSBTYWx0ZWRfXz2ORE9b1HUyF lz4pQx+2MQY25VsJoPkhml4i1XtXcF2mMwlFlByyBlDylHNtfbOJ/ymuM0jnE2QlqTjC07OLI7z BGQ/mmLPi1+sv2xbrAfivFTHh1HMlA0= X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-03_04,2026-09-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 bulkscore=0 priorityscore=1501 clxscore=1011 suspectscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2609030131 X-purgate-ID: tlsNG-33051d/1788447792-76EF74E9-86362B09/0/0 X-purgate-type: clean X-purgate-size: 1165 On Thu, Sep 03, 2026 at 01:01:23AM +0300, Daniil Tatianin wrote: > From: Daniil Tatianin <99danilt@gmail.com> > > apic::disable_esr was a quirk for the 32-bit NUMA-Q, Summit, ES7000 and > bigsmp platforms, which left the local APIC error status register alone > because "something untraceable" produced bad interrupts on those > machines. NUMA-Q, Summit and ES7000 went away in 2014 with commit > b5660ba76b41 ("x86, platforms: Remove NUMAQ"), commit 7cf6c94591bb > ("x86, apic: Remove support for IBM Summit/EXA chipset") and commit > 58f5d2d44883 ("x86, apic: Remove support for ia32-based Unisys ES7000"), > and the last setter went with commit 0abf508675c0 ("x86/smp: Drop > 32-bit "bigsmp" machine support"). Every remaining APIC driver > initializes the flag to zero. > > Remove the flag, the ESR setup bypass keyed on it and the 32-bit only > ESR clearing hammer in setup_local_APIC(), which was gated on the same > flag and therefore equally dead. > > No functional changes. > > Signed-off-by: Daniil Tatianin Acked-by: Steve Wahl -- Steve Wahl, Hewlett Packard Enterprise From xen-devel-bounces@lists.xenproject.org Thu Sep 03 15:05:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 15:05:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407442.1640533 (Exim 4.92) (envelope-from ) id 1x290O-0007ic-L1; Thu, 03 Sep 2026 15:05:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407442.1640533; Thu, 03 Sep 2026 15:05:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x290O-0007iV-IT; Thu, 03 Sep 2026 15:05:32 +0000 Received: by outflank-mailman (input) for mailman id 1407442; Thu, 03 Sep 2026 15:05:31 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x290N-0007iH-SO for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:05:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x290M-00FSzv-NS for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 17:05:30 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a998cb6-e002-0a2a0a5209dd-0a2a4508b616-12 for ; Thu, 03 Sep 2026 17:05:30 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a998cba-f659-0a2a45080019-d1558034d047-3 for ; Thu, 03 Sep 2026 17:05:30 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49b392ccaacso37083575e9.2 for ; Thu, 03 Sep 2026 08:05:30 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cee5f912esm78154695e9.4.2026.09.03.08.05.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Sep 2026 08:05:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788447930; x=1789052730; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=mANjaLxbTBRxPJI3nJCkis86IS9gaBZ1y1v/6VoNZTY=; b=rOoQbHR2ao60KApSDeajnTLQ2ijCf6xgKLNMANbLZh5T2Zghc4Xi7StPbe3qdLkLVI GbPxh07BRcW86MccPAWD3ravBcAPMjLBvGtkQJmzGioQGyGtPycah4xlKJMEnFlvswSu X1M7A+g2dC1NCpIEL0UNTqSpqD2ZnVDuweREKwrU2tElBqSTNXlsE2D9y+MtSZ8ZImFv llt0B1N980fnrJ1x+uRgB7Ct5iAc9Nrsgv4r0HFhjaJUhWTuFQwW/05DIQYfx0TRERw3 ilQE5FWqV0kJxU78chbado5qpkOP6TOdFkDKis1EfOtftGtewicWkeY7OmGa6IV/EddJ nwPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788447930; x=1789052730; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=mANjaLxbTBRxPJI3nJCkis86IS9gaBZ1y1v/6VoNZTY=; b=muL6pCuXJ5UVJD21D6CQ1K74NuC5GmD6+KyN5AWjhULLmpy4X4mqjjp2xdefEEI0Mo +3jePCvM1R/jAL+/NTaosoE0hCZy+lycJY2Y3zLRVv4HW2vC9/8PMPMcRHdPssPLJcav B8+WBUz1Fq6YwfMNQkYcYmnWxTDlMjH50sR/QEgjj2AOB/QumTb2lmKILJB1ZkdY9C33 Jf1+dK9TKHoDUWNe13Yv/KqaNzNyQxeEMIV47qKj3bzgA0yqnKTWUmWvC65Y/HzcYJ17 pwpyMmhFCS+cijWP/6unTI/virSyqMXwkduyByIV6SUSCcaNNt1HJ68Ex/Z0VPX+GHg4 PbLw== X-Gm-Message-State: AFuF++mNYeWw+/+O1vuI2gZEcFKlk3U+CKQ7+C4Oj1jhLgv8KqWmBrFX 8NC97isk2K0/HfMoL/7Ty3y1XZWGWe1rG73UW5ZPiHM7Gsrti01yFv+Zpg/lcQ== X-Gm-Gg: AYBFou2bKotfyXskP/Od2ANIy8S7U0mUSRxX/jOTsosrCu7dk21Dd62KYZpOg7U0GIa JGkdNazAKCJRJYZeiD1f440eQ8y6PpePKstO3YKyzarFZLktDVx/mBvErkA4BlJgBu/m+zADMYq Vm1FK0goYjH+P3a1i7o5c/stJzvLEZM1EHes0V9qSPntWJpvz9CZuQntWkf4cfuslDNOINBa1B9 pkl9vybkojjanM8tQf4oCn0tobW9OJbbDf+wIZJrhxX/1N3gmMywsl1iTKbJi2y4q37cexpGlIx 0eCwgc0kg0KWD6lEmIyQrzwJuJ7g4BTUOOOzUktslO8cGoEXmg0vNczW15aZchhxkgZw6mQTwxF v5UZvwtkO7i8lwqqIqJN8193HbMT6t0eCBwVmIj6IiXSDQcgXCsZOTKwg7LDO+cHKU/62pCRXQ8 Ru19g1tS+MG4b+UvZ9rXuucAtfnVSY4Tbqc7+D8rzGpmZ4Abzkfqp0B61nCT4xLYxy120ziwpg6 yrZmIeNM1JPedDsJdVxtas31fUNAguyJ9oFJ7jTALw= X-Received: by 2002:a05:600c:1da1:b0:499:9eb8:a1d7 with SMTP id 5b1f17b1804b1-49ce5842935mr283797955e9.9.1788447929879; Thu, 03 Sep 2026 08:05:29 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v3] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array Date: Thu, 3 Sep 2026 17:05:21 +0200 Message-ID: <20260903150521.29804-1-oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788447930-D614687B-F128AF34/10/73395122804 X-purgate-type: spam X-purgate-size: 2865 imsic_init() indexes msi[] by the Xen CPU id hartid_to_cpuid() returns, but that array is allocated with one entry per parent IRQ of the IMSIC node, and the only range check compares the index against num_possible_cpus(). Neither matches the array, and the check comes after the first access: - hartid_to_cpuid() returns NR_CPUS when the hart isn't one Xen brought up, and msi[NR_CPUS].base_addr is read before that is noticed; - an IMSIC node listing fewer parents than Xen has CPUs makes every index past nr_parent_irqs go past the end of the allocation, which the num_possible_cpus() check lets through. Size the array by nr_cpu_ids, which is what it is indexed by, and move the range check ahead of the first msi[] access. Fixes: c9bd8b322ecb ("xen/riscv: imsic_init() implementation") Signed-off-by: Oleksii Kurochko --- Changes in v3: - Drop local variable nr_msis and use nr_cpu_ids explicitly. --- Changes in v2: - Use nr_cpu_ids instead of num_possible_cpus() to not be dependent on if cpu_possible_map is sparsed or not. --- --- xen/arch/riscv/imsic.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index f7b70a8da09e..8da72c007225 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -346,7 +346,7 @@ int __init imsic_init(const struct dt_device_node *node) goto imsic_init_err; } - msi = xvzalloc_array(struct imsic_msi, nr_parent_irqs); + msi = xvzalloc_array(struct imsic_msi, nr_cpu_ids); if ( !msi ) { rc = -ENOMEM; @@ -405,7 +405,18 @@ int __init imsic_init(const struct dt_device_node *node) continue; } + /* + * hartid_to_cpuid() returns NR_CPUS for a hart Xen doesn't know, so + * the range has to be checked before msi[] is indexed at all. + */ cpu = hartid_to_cpuid(hartid); + if ( cpu >= nr_cpu_ids ) + { + printk(XENLOG_WARNING + "%s: unsupported hart ID=%#lx for parent irq%u\n", + node->name, hartid, i); + continue; + } /* * If .base_addr is not 0, it indicates that the CPU has already been @@ -421,13 +432,6 @@ int __init imsic_init(const struct dt_device_node *node) continue; } - if ( cpu >= num_possible_cpus() ) - { - printk(XENLOG_WARNING "%s: unsupported hart ID=%#lx for parent irq%u\n", - node->name, hartid, i); - continue; - } - /* Find MMIO location of MSI page */ reloff = i * IMSIC_HART_SIZE(imsic_cfg.guest_index_bits); for ( index = 0; index < nr_mmios; index++ ) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 15:28:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 15:28:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407467.1640542 (Exim 4.92) (envelope-from ) id 1x29Ms-0003cg-8V; Thu, 03 Sep 2026 15:28:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407467.1640542; Thu, 03 Sep 2026 15:28:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x29Ms-0003cZ-5i; Thu, 03 Sep 2026 15:28:46 +0000 Received: by outflank-mailman (input) for mailman id 1407467; Thu, 03 Sep 2026 15:28:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x29Mq-0003cT-Ni for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:28:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x29Mq-00AwBe-44 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 17:28:44 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9991f5-8faa-0a2a0a5109dd-0a2a4504a9e2-44 for ; Thu, 03 Sep 2026 17:28:43 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99922a-b57f-0a2a45040019-aa0a817c79f5-3 for ; Thu, 03 Sep 2026 17:28:43 +0200 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-659-fVqUXbuQNIil-MQnG6u7yw-1; Thu, 03 Sep 2026 11:28:41 -0400 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-496bbcf7d1eso36475e9.0 for ; Thu, 03 Sep 2026 08:28:40 -0700 (PDT) Received: from imammedo ([213.175.37.14]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cee5f9114sm76185195e9.5.2026.09.03.08.28.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Sep 2026 08:28:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788449322; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0ztegjQ1POBwSGppr2l4gUAmCFrMM6q1VpOdlFUL088=; b=b/sDAEPVf0uefwEp/SVroNz0zUBQVs8w9zkIPOLO8togYDTGVt4FYjOTIBz9vDLtp6Viwj pclyKzXXBX5xnyD13e913aexS6QD1N3MVtxN9kvTlYR2uf3hoLsiShpPOU5z++qgop6j2q R2uLq9LCF1667d90yqHu7rliGMydpH8= X-MC-Unique: fVqUXbuQNIil-MQnG6u7yw-1 X-Mimecast-MFC-AGG-ID: fVqUXbuQNIil-MQnG6u7yw_1788449320 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788449320; x=1789054120; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zZlgcpyErJlCEJFwxXWLl2G2MJ6RenYBs5jbw6Dpw5Q=; b=LBI40bttvsxgoPXsBwcnIw9Dlau1+jDcaNpoI94agoOxCYV/VFJh7dyPM4bsE9O6Pf JtWG+sZlxsbqmhDsUkPMchl42sE/M8j7suwww+jsHzzZwnnKwjfWhPbvm6Qh9M8ZGZ7k 0PamDY9hcfeeXUN1a4Tc2cH9+XQ3n5M3lFljx4nWjpTXHBe8ovTm2gllHZE3lKA+b/Xx YMv/nMKTYAoK5bnf92cj5lxyA04RKzzk9IerPYFlJYeSkknea3MMGXyKFI0qB56in2nG w8BA62gqjiQ54fp44wn8cBd/RoomKx8Y4c/q28n+Q9nq+QYQBXrQ7Ob0Yco0nOxOdAIR oFvA== X-Forwarded-Encrypted: i=1; AKwUvBxrfAMOAo2i/fuU5B71mJ3dbediYRSSYDounoxDENCksXVBsek/4+kbtF7yIrPQU1WQmpsBIKp3hKU=@lists.xenproject.org X-Gm-Message-State: AFuF++lBLLovVjCG/w5GwQcns9K4su+wkYLHopRJPnkRu+KB+4N33Z3T VM4URQnIEFdGfd0o0xSeNyQxSZbCjdgSOWjCkP7FF408S5SV4Bd9IlHq5gog+uTIp+ua3hG2xpF Ag5GLlod4wJ3Q32ZNhHQhMC1qzI3gmtAck2c/+dafRnPxd0kUt1KMCXKZxRCdTG0NGxk4S/fC+3 AJ X-Gm-Gg: AYBFou3bnREqMRI2dWbVeZ7SUczVPVBz6r3/RBP6rc4QujjI8B/VE0knnlV/jj8hqQJ YLGBcxlROe7VxXtvPzCOOfX+8mWneR7W/xKQSqwO9fwmx/6qgJCqASdXMFMwcl2JS4rvs80+uf0 bfd2Am3p5F1Tlzci1RBkLTtrkmMwIgYLfCely7cWaZEjc+30AufjHKHogcUarARixaMvQbC/DsA n2HvmiCAtaZF3SYXg9vnmr1AogBC5fLr2idWazov4JIn75+LLlfQZDvrQ6hbc47t8795ZYGAQ+9 8jk1of/R413Ys0Y91/mmSj572JA0YuJ792T2AKRZosMi X-Received: by 2002:a05:600c:81c9:b0:49c:df2b:15fc with SMTP id 5b1f17b1804b1-49cf5b79c84mr17210205e9.8.1788449319984; Thu, 03 Sep 2026 08:28:39 -0700 (PDT) X-Received: by 2002:a05:600c:81c9:b0:49c:df2b:15fc with SMTP id 5b1f17b1804b1-49cf5b79c84mr17209195e9.8.1788449319587; Thu, 03 Sep 2026 08:28:39 -0700 (PDT) Date: Thu, 3 Sep 2026 17:28:35 +0200 From: Igor Mammedov To: Dongli Zhang Cc: "Daniel P. =?UTF-8?B?QmVycmFuZ8Op?=" , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, mst@redhat.com, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug Message-ID: <20260903172835.0e253a25@imammedo> In-Reply-To: <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: BvBP7bAlVza0ri1EfJZlH_Jan3Gbj_-4GQP_VVq2Ahg_1788449320 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ebf023/1788449323-C3AC0B50-0B122C6C/0/0 X-purgate-type: clean X-purgate-size: 4919 On Wed, 26 Aug 2026 09:15:47 -0700 Dongli Zhang wrote: > On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrang=C3=A9 wrote: > > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: =20 > >> Hot-unplugging a PCI device can require cooperation from the guest. Fo= r > >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest > >> eventually writes the ACPI PCI eject register. For PCIe native hotplug= , > >> QEMU notifies the guest through the PCIe hotplug mechanism and waits f= or > >> the slot unplug flow to complete. Only after that completion does QEMU > >> unrealize the device and emit DEVICE_DELETED. > >>=20 > >> This can leave a device stuck in the unplug pending state when the gue= st > >> does not cooperate. Examples include: > >>=20 > >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is > >> unavailable. > >>=20 > >> 2. The guest is stalled and cannot handle the hot-unplug event. For > >> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce t= his > >> for ACPI-based hot-unplug. > >>=20 > >> 3. The device was attached to a slot that the guest cannot use. For > >> example, a pcie-root-port only supports slot 0. If a device is added t= o a > >> non-zero slot below a pcie-root-port, the guest may never discover the > >> device and therefore may never complete the unplug request. all of above is actually expected, no (functioning) driver =3D> no hotplug/= unplug. it's the guest problem. Once device it exposed to guest its life-cycle not longer owned by QEMU. That's what one would see in real hw as well, you press eject button but it will not do anything if OS doesn't process it. also see comment at the end. > >>=20 > >> The non-zero slot case has also been discussed in: > >>=20 > >> hw/pci: warn when PCIe device is plugged into non-zero slot of downstr= eam port > >> https://gitlab.com/qemu-project/qemu/-/commit/ =20 > > ca92eb5defcf9d1c2106341744a73a03cf26e824 =20 > >>=20 > >> hw/pci: add comment to explain checking for available function 0 in pc= i hotplug > >> https://gitlab.com/qemu-project/qemu/-/ =20 > > commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5 =20 > >>=20 > >> pci: don't skip function 0 occupancy verification for devfn auto assig= n > >> https://gitlab.com/qemu-project/qemu/-/commit/ =20 > > e228d62b4af29bca698ec57efdceb46f392f5444 =20 > >>=20 > >> For example, if root-port.1 is a pcie-root-port, the following command= adds > >> a vhost-scsi-pci device to an invalid slot: > >>=20 > >> (qemu) device_add vhost-scsi-pci,id=3Dscsi01,wwpn=3Dnaa.5001405324af09= 85,bus=3Droot-port.1,addr=3D01.0 > >> warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent device on= ly allows plugging into slot 0. =20 > >=20 > > This rather looks like it should be a fatal error, not a mere warning. > >=20 > > If I follow the commit ca92eb5def it links to https://bugzilla.redhat.c= om/show_bug.cgi?id=3D2128929 > > which states that this configuration is going to lead to a crash in > > QEMU on guest OS shutdown. IMHO that crash is sufficient to justify > > making this a fatal error. > >=20 > > If we actually wanted this to remain a warning, then that shutdown > > crash would need to be fixed. > > =20 >=20 > Thank you very much! >=20 > I see that the issue has been fixed. The ticket mentions the following. >=20 > "What I am observing is that it seems when the slot ID !=3D 0, the guest = OS seems > to ignore this and we never seem to hit ich9_pm_device_unplug_cb()." >=20 > Based on my experience and evaluation, ACPI-based hotplug is more likely = to > encounter an issue where the guest VM does not respond to an unplug opera= tion. I'm not sure it's a good idea to delete device when guest still thinks it's= there (you can make guesses on QEMU side if it's in use, how useful those are is = questionable). as far as I know, ACPI hotplug has no notion of surprise removal (pls educa= te me if it's not the case), so I wouldn't do what you are proposing here at all, it's basically asking = for disaster to happen. And all this is basically for dealing with abused qemu flexibility. Please (re)formulate usecase and make it more clear as what is eludes me no matter how many times i've read this cover letter. On positive note: What you can try to implement is native PCI-E support for surprise removal. How hard that would be I don't know. And I would well expect if one deviate= s from real hw expectations/configs (such as not 0 slot/partial func removal), one would quickly stumble upon issues as that's not what what vendors writ= e/test drivers for. Even if it's not likely to be used in practice (guest still might not suppo= rt it), it may serve as test-bed for guest drivers. > Thank you very much! >=20 > Dongli Zhang >=20 From xen-devel-bounces@lists.xenproject.org Thu Sep 03 15:57:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 15:57:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407496.1640551 (Exim 4.92) (envelope-from ) id 1x29oV-0007jp-Ai; Thu, 03 Sep 2026 15:57:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407496.1640551; Thu, 03 Sep 2026 15:57:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x29oV-0007ji-81; Thu, 03 Sep 2026 15:57:19 +0000 Received: by outflank-mailman (input) for mailman id 1407496; Thu, 03 Sep 2026 15:57:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x29oT-0007jc-F2 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:57:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x29oS-00DWrr-CB for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 17:57:16 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9998b8-2eae-0a2a0a5409dd-0a2a4504e2f4-40 for ; Thu, 03 Sep 2026 17:57:16 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9998dc-b57f-0a2a45040019-d1558035c582-3 for ; Thu, 03 Sep 2026 17:57:16 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49b8ce9b733so294355e9.1 for ; Thu, 03 Sep 2026 08:57:16 -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-49ce5927b68sm138640565e9.1.2026.09.03.08.57.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 08:57:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788451036; x=1789055836; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=86tnfSkcdQw+bE0XkJ0AIcxoaoMOJ7N3xnqPAtL6Zek=; b=gnI/CVz3qr1z66p5Oz8Vj2q5K559CxDqvOpxBxmMYadraaLFq+4lH2hlt05ga3oEGg OXZ13wyDUbzohaCtBJkla7zK+Bz4einNvjBoEVaOFGRt7aDmaeUoPgYlRYEubbhlVq4g s6rXZpAtkPPYKhbAHsG0hEjbYBu7DpaysRHPzm7fJeyWKzEuC8wpb/4XzB1r+Uf/sEvl 2P3C36WhAPeQNXAkLxPMlmYeF+wao8vIi8GcPwhCo1gGwFkRd4E1n2IvIgRLtBYPeC9+ 3qtl/c7zq5kRvVpd9lDGUK9L1/fELII1RGzstNckkMEjAAPdSL0u6PTHleAJjcLeKbLI GGwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788451036; x=1789055836; h=content-transfer-encoding:content-type: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:content-type; bh=86tnfSkcdQw+bE0XkJ0AIcxoaoMOJ7N3xnqPAtL6Zek=; b=J3TF3aIgnSd+VW9VHxFj2BDvC8TS0wQSr1v6YHWCKJ5JOT2vs1pLLOej9XLBbKNN4j YH4t92OV9RR+uvSgKp0P/vdijzbAGrpqnIfbmtTSwjYgd+2QrttkeBPzjtPoUgoPOYlC m8zXYNiJNZRfJZqN97ARBYQe8kFVy6ZYW9DPZ03zcoRo5k8jmLv7XrgPJAMDCwQzklZo dTNjWysdDgurx3mBMtbmNOVzcWUe/I4WZuHLEe/7I7Iz3smDhSLUi6DWQ+gtb7dTkHKx WdlPzrGv9ZM+7WoIGILMnzgI1u5ZhAo8mlr4g+GQaDxCo6OSFASqsyDpYgk8nfj8wSO9 XDRw== X-Forwarded-Encrypted: i=1; AKwUvBzmhGDnyJqvX5uKXqG1lZkZUUH0YYWMjeNNdqyQrBMmxk8bwe/ZHymRlUv4KGUlOs5ax9pYFdarR6s=@lists.xenproject.org X-Gm-Message-State: AFuF++kGBcsxwLwIgFmqS3V4o/90qc89WsGq+DWA+tKHJzKyo2fJGyhQ Ufeyt+vEIiHN4WZccmZLQN2sQU8u14J/K3C7kXnR++mV/A0awS32LrrqZ3Nw9TIzhQ== X-Gm-Gg: AYBFou3QU5l1RporldTljCmEmpuOVrpYcUbYOkxcbBfV/OytGYCgK0/yg+osfUZ/yo4 Q3v2BElZ12vrl+5GpFwCJJsDZQVYyGtQkwucNXuyf2VLckcaibZaQFw9TxBqAVOGR4eGL+iYNuS kxKgOK7J7u/Nu3gFAC5JhWneLaitsBJ8ss3vtBTnujtx+Er6X9H2ob5vgbQvi8q4UNRWuMrdN/S x1+GxpJQsVcB1nsk2WLFSp6JkApPmV5vbhIVxzviPqUrktPhXgoqiUEIlqanh380a1CWcnp2l+v 2VYfFr0n1xiRXK5OjLJl44rdQRJhcpHu2ayWOtHPIjXepAqWjKx93OhKm5krrwzeUs+ZWKoOJZ8 UgtMmC4d0L+BDVNOdWS5/UijqedCwOwBeg6qiDXLlYzSod4nt3mKvE+eePP9pvk+VeKhBK1ScpZ triM8uufvDs164mnS9liInOYJWMcYAv0QKUmDUgDVt0wQapfKeGfHkogeVCTvRqz7M6OxyJBIH8 z5rV+UjbsHvg6vDgVPxiwvYmTh8MmEys7SnVTGKXmW32qammyx2noMxdPHyAJ0= X-Received: by 2002:a05:600c:474a:b0:493:aa0a:45ad with SMTP id 5b1f17b1804b1-49ce55ecebemr192717875e9.2.1788451035542; Thu, 03 Sep 2026 08:57:15 -0700 (PDT) Message-ID: <5071d4da-d9b1-45cd-8e9b-778df417ee7b@suse.com> Date: Thu, 3 Sep 2026 17:57:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/14] x86/mm: introduce populate_perdomain_mapping() To: George Dunlap Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-2-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-2-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788451036-534C3B50-3B24B7A7/0/0 X-purgate-type: clean X-purgate-size: 5801 On 02.09.2026 11:43, George Dunlap wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -6334,6 +6334,130 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, > return rc; > } > > +/* > + * Map @nr pages, @mfn[0..nr-1], at consecutive pages from @va in v's view of > + * the per-domain area, with page-table @flags. The range must lie within a > + * single per-domain slot, and must already have been plumbed down to the L1 > + * tables by create_perdomain_mapping(): missing structure is a bug. A > + * present entry not owned by the area (no _PAGE_AVAIL0) is silently > + * replaced, as that is how callers update their mappings; a present > + * area-owned entry is freed and replaced, which constrains the calling > + * context (see the comment in the body). No TLB flushing is done: the > + * caller decides whether the old translations can still be cached > + * anywhere. > + * > + * When v's page-tables are loaded on this pCPU the L1 entries are reached > + * through the recursive linear mappings; otherwise the walk maps the > + * per-domain page-table pages transiently with IRQs off, so it needs > + * nothing from the current address space and is usable from any context -- > + * including the context switch, before the incoming vcpu's page-tables are > + * loaded. > + */ > +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, > + const mfn_t *mfn, unsigned int nr, > + unsigned int flags) > +{ > + l1_pgentry_t *l1tab = NULL, *pl1e; > + const l3_pgentry_t *l3tab; > + const l2_pgentry_t *l2tab; > + struct domain *d = v->domain; > + unsigned long irq_flags; > + > + ASSERT(va >= PERDOMAIN_VIRT_START && > + va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); > + ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1))); > + /* Area-owned pages are installed by create_perdomain_mapping() only. */ > + ASSERT(!(flags & _PAGE_AVAIL0)); > + > + if ( likely(this_cpu(pgtable_vcpu) == v) ) > + { > + unsigned int i; > + > + /* > + * Fast path: v's page-tables are loaded on this pCPU, so the L1 > + * entries can be reached using the recursive linear mappings. > + */ > + pl1e = &__linear_l1_table[l1_linear_offset(va)]; As mentioned elsewhere, I'm concerned of this (or really any) new use of the linear page tables. (Which, ftaod, isn't an objection.) > + for ( i = 0; i < nr; i++, pl1e++ ) > + { > + /* > + * An area-owned entry (installed by create_perdomain_mapping(), > + * marked _PAGE_AVAIL0) holds the only reference to its page, so > + * displacing it means freeing it. Nothing in this series > + * replaces area-owned backing, hence the ASSERT_UNREACHABLE(); > + * any future caller doing so must run where freeing is > + * permitted -- IRQs enabled, not in interrupt context (see > + * ASSERT_ALLOC_CONTEXT()) -- which the context switch path is > + * not. > + */ > + if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) ) > + { > + ASSERT_UNREACHABLE(); > + free_domheap_page(l1e_get_page(*pl1e)); > + } > + l1e_write(pl1e, l1e_from_mfn(mfn[i], flags)); > + } > + > + return; > + } > + > + BUG_ON(!d->arch.perdomain_l3_pg); > + > + /* > + * Slow path: walk v's per-domain page-table pages. All mappings are > + * local to this function, so disabling interrupts for the duration of > + * the walk satisfies the map_domain_page_irqoff() contract. This in > + * turn makes this function usable from the context switch path, where > + * a plain map_domain_page() could recurse into __context_switch() via > + * sync_local_execstate(). > + */ > + local_irq_save(irq_flags); > + > + l3tab = __map_domain_page_irqoff(d->arch.perdomain_l3_pg); > + > + /* > + * Missing page-table structure is a hypervisor bug: there is no safe > + * continuation, least of all from the context switch, where the next > + * descriptor fetch through an unmapped GDT slot would be fatal. > + */ > + BUG_ON(!(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT)); > + > + l2tab = map_domain_page_irqoff(l3e_get_mfn(l3tab[l3_table_offset(va)])); l3tab[] isn't used any further, so I think it wants unmapping right away. No need to have undue pressure on the number of active mappings. > + for ( ; nr--; va += PAGE_SIZE, mfn++ ) > + { > + if ( !l1tab || !l1_table_offset(va) ) > + { > + const l2_pgentry_t *pl2e = l2tab + l2_table_offset(va); > + > + BUG_ON(!(l2e_get_flags(*pl2e) & _PAGE_PRESENT)); > + > + unmap_domain_page_irqoff(l1tab); > + l1tab = map_domain_page_irqoff(l2e_get_mfn(*pl2e)); > + } > + > + pl1e = &l1tab[l1_table_offset(va)]; > + > + /* > + * As the fast path -- and the slow path holds IRQs off throughout, > + * so replacing area-owned backing here is never permitted. > + */ With this comment I think ... > + if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) ) > + { > + ASSERT_UNREACHABLE(); > + free_domheap_page(l1e_get_page(*pl1e)); ... this call should be removed from here (I would have suggested to comment it out, but Misra dislikes that iirc). Otherwise it would in principle be reachable in release builds. Maybe instead of ASSERT_UNREACHABLE() it should really be BUG() here. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 15:58:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 15:58:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407502.1640561 (Exim 4.92) (envelope-from ) id 1x29pU-0008JG-NA; Thu, 03 Sep 2026 15:58:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407502.1640561; Thu, 03 Sep 2026 15:58:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x29pU-0008J9-KO; Thu, 03 Sep 2026 15:58:20 +0000 Received: by outflank-mailman (input) for mailman id 1407502; Thu, 03 Sep 2026 15:58:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x29pT-0008Im-FI for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 15:58:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x29pS-00FLIa-S3 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 17:58:18 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a999918-e002-0a2a0a5209dd-0a2a4506db6e-2 for ; Thu, 03 Sep 2026 17:58:18 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99991a-195a-0a2a45060019-d155dd31a55f-3 for ; Thu, 03 Sep 2026 17:58:18 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-4843e397f74so1751720f8f.1 for ; Thu, 03 Sep 2026 08:58:18 -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 ffacd0b85a97d-48448e13db0sm14850892f8f.0.2026.09.03.08.58.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 08:58:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788451098; x=1789055898; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=zT+lnRImIClZY0CrauXo1P1azhwsOPz9dB84sG3Ivg4=; b=DF/9RMM9G7+JfOd/DOJMztRY5htQ+h0598d4kqzhXg7dpBNMP5J2OPk8oDRMvgHW6p lfo/uz14lNd5D/DRQzA3u1u8Ypm82YvZZwbYYejErBlO1ycjFQWeVWdeTZYNxHIQIdIu KQg0Sr88OmhFE+r71Gxpy3oWkkAQEAOd/KkM589yKmxzaqO9kc+dTzuA0F0jkD6FwrpB bex9rX9ftXgY+eoifdlmJteOVrj0+z9/0PcQSpu+T/F0sXWggzFmXjuBWZD1qQLoKHb+ mJ5KJgjKBguwdm72C3m1Z3enYo8FrwZpRK7pjNIB+p22ShXsknvdo7nfcZytw8QLZImG r8ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788451098; x=1789055898; h=content-transfer-encoding:content-type: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:content-type; bh=zT+lnRImIClZY0CrauXo1P1azhwsOPz9dB84sG3Ivg4=; b=dCjHGiiWX48Bg8ndv5MeV2aadkCnXRknC6yFOZFge5VkBQ7ScXu5ci+5XZQRwM6wKe tO72SzzLSvNGueJaWf1NHu9gAnXc+87CWCsufoXmB0YATNiDQ54W+MquWC7LyvpsWLvj bldhnOIg+PqHRmkgEJmx3iOR+xzSlfFEz2zUwtGQrSzqtq/CXL8ho3E9xdWIRtxG7Uvh 5LC08nbRLlYnzCO4AyhWGauKHWb8joLxsvQupC3Va1jnD0sn/XwYVZ0XDkQa+yMfQAn9 EVFOKsXsgUXnb5KVI5SHCULn2qkYrBzD8SDmOYwPaz/ia0hY3NW0MrpF1fhe993OiazW krag== X-Forwarded-Encrypted: i=1; AKwUvBzfcFwd2/vdcMIjB6/vtyfMQrWfcwM3LgQkvgLT0D0k96HS0FDkArGkU+udfe2D+MDsVs1gn9Z4Dmw=@lists.xenproject.org X-Gm-Message-State: AFuF++mgotRaOo9hrjiKBdIUOel/olozbhIRxd6l03PfzUsr3hzNEFRM E2Ys4RMVE77zrc7L2dkUdwlNgTrzhDTCbnhiD5jV8bScqaK40ggWnXHJt6YMGgxzIQ== X-Gm-Gg: AYBFou18PJ6v5MpGdsvP3WguUCWBDI+EArKoRWRWy1wTrDKdEqKT2PXFF6GXGaYvjo1 qoDS+F8PTN4Gq/EuXc77/VMX6QGl5ngPyVcv6OlH4Z1i2pGf5GjbXxdpnIn6+/cKe8zZ9y4iK1b zjE1XieR3wEz5hJw8tz+StSbXSLw4X1QCLVF/RfuNnL10EbMlfn8/5Xw9oqdbWdFKY/LiA+MZU1 GLC8hTwHYwO8aIxVksDOGenP39c6yyPw4hmLVuhmK0nwnETkYNYYPl2ALqj80KxnrD6RlD0oSit ZZ32Og1Uw8MBJQENjgnKKb35YJQ5BTabuPGNN3L3dZz4JZ+XCPo3yen7NIDwrgzrWHCp5ExtFNH KyOZbj24EFbjH/LdUJdE/n1rKdVffCFok79dVyB4oYJclAKX8AuLvgAeYyRgN9f0+H4clxX81Nb 53Gc6Wm2lm4BnGRFqCQFgAlMX+g1J2z+vr3njy7sHnKYQtytyH6JJV5lCBmouMk5yABLCFMYwlQ c+4TIvem0Ar+De8Yz85pUJ9tfjO12hZwaTz0cIRTChs5BsQMft3 X-Received: by 2002:a05:6000:64e:b0:485:8226:c69c with SMTP id ffacd0b85a97d-4858226cab5mr6427693f8f.27.1788451098172; Thu, 03 Sep 2026 08:58:18 -0700 (PDT) Message-ID: Date: Thu, 3 Sep 2026 17:58:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/riscv: fix out-of-range indexing of the IMSIC per-CPU MSI array To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260903150521.29804-1-oleksii.kurochko@gmail.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: <20260903150521.29804-1-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788451098-F540B77B-3F457781/10/73395122804 X-purgate-type: spam X-purgate-size: 1007 On 03.09.2026 17:05, Oleksii Kurochko wrote: > imsic_init() indexes msi[] by the Xen CPU id hartid_to_cpuid() returns, > but that array is allocated with one entry per parent IRQ of the IMSIC > node, and the only range check compares the index against > num_possible_cpus(). Neither matches the array, and the check comes > after the first access: > > - hartid_to_cpuid() returns NR_CPUS when the hart isn't one Xen brought > up, and msi[NR_CPUS].base_addr is read before that is noticed; > - an IMSIC node listing fewer parents than Xen has CPUs makes every > index past nr_parent_irqs go past the end of the allocation, which the > num_possible_cpus() check lets through. > > Size the array by nr_cpu_ids, which is what it is indexed by, > and move the range check ahead of the first msi[] access. > > Fixes: c9bd8b322ecb ("xen/riscv: imsic_init() implementation") > Signed-off-by: Oleksii Kurochko Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Sep 03 16:11:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 16:11:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407514.1640570 (Exim 4.92) (envelope-from ) id 1x2A1q-0003Q6-Ok; Thu, 03 Sep 2026 16:11:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407514.1640570; Thu, 03 Sep 2026 16:11:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2A1q-0003Pz-Lt; Thu, 03 Sep 2026 16:11:06 +0000 Received: by outflank-mailman (input) for mailman id 1407514; Thu, 03 Sep 2026 16:11:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2A1p-0003Po-8p for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:11:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2A1o-00FNBn-2m for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 18:11:04 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a999bf9-2eae-0a2a0a5409dd-0a2a4508c6c2-48 for ; Thu, 03 Sep 2026 18:11:04 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a999c17-f659-0a2a45080019-d155dd30a405-3 for ; Thu, 03 Sep 2026 18:11:03 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48586861639so1359f8f.0 for ; Thu, 03 Sep 2026 09:11:03 -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 ffacd0b85a97d-48448ed3716sm15980462f8f.22.2026.09.03.09.11.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 09:11:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788451863; x=1789056663; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=clKMydZ7WjR5FV27BAvQbyuJnT+lNT7hRz9cPF4o8F0=; b=Hgzjob+bKkLFe6fKVO7xzitNh2iZM2SmHV34NJ3+gKlXG7ShbePzjBvbra7UqB9ZgB FGwmeJ0ISZQOdFU8F+o8VJWCBemqHor8nRyOa0cBNv9hMVKa+WCdPpDfyhZbUDnvx8Hy qYrME+9tPMJ8kIf8TDlkW0EntakCIkyx+GOmCTq1Dchi+JkkI2j1cXzMr8UztgAVepz5 pBbUivKiCR7H8t2S+g0anATwFvnx9PlqnkWtkRrJY+JE18KJndFLQ4DFwGJJFGqKg+Lb 8Y7OGki3c/RIr2RHpbqj1yiGx9cL3gYlepI2Gu0Yzyki0j5xBdufVoZlGHUvvmZlMY+O vwjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788451863; x=1789056663; h=content-transfer-encoding:content-type: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:content-type; bh=clKMydZ7WjR5FV27BAvQbyuJnT+lNT7hRz9cPF4o8F0=; b=ILDBPyhpKlA70+vW899ALwC7knbHFjPi3acNd/FhLXWJofKZZh6E5qzZQb4/D8vSgO yeUa/9aGHIK9R24Ok1QX/G5LBwHMfwNzg+mqX36/7EPoiVy02HMRO8x2L5jePioBO3H1 nKYcLGGTfuCzOQv5YHnRehAJ+XoV8+KeavURI2+RzC9B6ZAkc1DY/j7SVVAbdaH8PI4w mmzpzbDjV3sUUnb4F2HKeoIpXYy3PK5UF4oFIZBD7epqBJOxgtO8rkl7QP27Wz8fIeNZ Fwr+QTAa3VgzpxkMZcsutG04EOwPfA+q4GYa3gsqzJN1bQIqh9lycq7QP2arWD+e0ebS JJhw== X-Forwarded-Encrypted: i=1; AKwUvBzjYk1n2a4eSo/4DbBgk48umsNy+rf3nZH48xbMMI2vc9NfWwmQv7xBT6ZqNPgYsc4qjf31M8r6tzA=@lists.xenproject.org X-Gm-Message-State: AFuF++mJIbfwpOlnfr+c4CQaoXCkocl48mheNXxosNyYiTM9n5CzzPWt w6irOeJWuzNn/8CaKDuAZWb3KYkUxGz04IQCStTKdaEQaonwQGIZymGNuRa02yo21w== X-Gm-Gg: AYBFou1CknyT59iIfo47fal11RgyPS4mjI4UAGoDhGrxcPlhVHqOrFig1at9DMuc/7f QntgVahG516rEbaxPIX3JahRFkfYuZK/r3T+gopvo6fs/l/ccW+hlukM3MMQwDI4B05V2zRLCHK C0BYbsQlTQqB2IOig4lDR6AS30tC04G71MVcuJG9cX2KeTETZ2yMbCkDpblKqnXy8iJUj0nCODn H/wUTHX++ZUO5s1Oc+sgLiHBZOHjS+jw4QeTZh6oxiTe0edD0CfLJhKGjAkCJDWbACv+2A0ucfO EnSepcj1W7PmAWY6dTEclSxRh6raBwktYVQB4R6shJ66eE4YQgkH6QiXBHy4HkeE8hz1wVyZ/GD yCv9iXCfyg3ooM6k8A0/lHEFr6Zymf21jLstcJ5Zlfxw2KyNLVtKJwQ84im5hkh/fkPloOMqg6W ZmkDWroGSZ2NZ0NB6hIlBtIgtU95g5yTR0Ax/bNoh7LCvG0ziDeVHQF3seLT67l3yxixgKx4LhD VX/AzwABv/j1pzV2yLPfDIcls6F+UnL82MA8fuWnCNbj5YxYtuZz1AsuScJR6sj X-Received: by 2002:a05:6000:2310:b0:484:42d7:50fe with SMTP id ffacd0b85a97d-485823163d4mr4977325f8f.4.1788451863316; Thu, 03 Sep 2026 09:11:03 -0700 (PDT) Message-ID: <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> Date: Thu, 3 Sep 2026 18:11:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org, Juergen Gross References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-3-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788451864-DFAD487B-D1DE0C07/0/0 X-purgate-type: clean X-purgate-size: 2142 On 02.09.2026 11:43, George Dunlap wrote: > From: Roger Pau Monné > > Currently, update_xen_slot_in_full_gdt() uses the stashed direct-map > pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vcpu's > page tables with Xen's GDT, by writing a stashed per-cpu copy of a > pre-baked L1 entry (either 64-bit or compat version). > > Switch this to using populate_perdomain_mapping(), which doesn't rely > on the stashed address of the l1 page in the direct map. Rather than > also stashing a pre-baked value for the payload, compute the mfn from > the per-cpu GDT pointer at use: the conversion is a handful of cycles > on a path costing thousands, and computing at use removes the > parallel {,compat_}gdt_l1e bookkeeping along with its boot-ordering > constraint (the cached value could only be generated after Xen's > physical relocation, and had to be in place before the first context > switch; a use-time lookup is correct by construction). The flags on > the final mapping are identical. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 > Signed-off-by: George Dunlap > --- > Changes in v2: > - Drop the {,compat_}gdt_mfn caching entirely (suggested by Andrew > Cooper): compute virt_to_mfn() from the per-cpu GDT pointer at use. > The PDX lookup behind it measures ~5-10 cycles warm against a > ~1,500-cycle context switch, and this removes the double > bookkeeping and the after-relocation caching constraint. The > cached-MFN assertion goes with the cache: a use-time computation > from a live pointer needs no staleness check. This looks to contradict what 564d261687c0 ("x86/ctxt-switch: Document and improve GDT handling") used as justification to put in place the caching. Also Cc-ing Jürgen, who also was involved there, for possible further insight. Functionally the change looks okay to me, but the above will need sorting, at the very least by specifically discussing why effectively undoing that earlier change is okay. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 03 18:46:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 18:46:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407516.1640583 (Exim 4.92) (envelope-from ) id 1x2CSD-00061J-KK; Thu, 03 Sep 2026 18:46:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407516.1640583; Thu, 03 Sep 2026 18:46:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2CSD-000607-GZ; Thu, 03 Sep 2026 18:46:29 +0000 Received: by outflank-mailman (input) for mailman id 1407516; Thu, 03 Sep 2026 16:11:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2A1s-0003cQ-Tf for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:11:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2A1s-006nB7-AE for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 18:11:08 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a999c17-e002-0a2a0a5209dd-0a2a450ae13c-8 for ; Thu, 03 Sep 2026 18:11:08 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a999c1a-f2d2-0a2a450a0019-ac6904fe8a04-3 for ; Thu, 03 Sep 2026 18:11:07 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 60E6F60A5B; Thu, 3 Sep 2026 16:11:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 119AE1F00A3E; Thu, 3 Sep 2026 16:11:06 +0000 (UTC) Received: from [10.30.226.235] (localhost [IPv6:::1]) by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id 9386938119CB; Thu, 3 Sep 2026 16:10:08 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:Date:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788451866; bh=wQC/B3FS4e5cPaDkFUi05H5/4Cpx4sxh25n+vGHWmYc=; h=Subject:From:Date:References:In-Reply-To:To:Cc; b=cX5S97uavmnQ1oACZHN9HgQC0w4BW6l7gd3KhLLv7D3CEwvQqVkkISIabPe6cAz15 lWkG+FcJx8T5bL8zvHYmPd7BTeb+q0xV22oPkTs+7zHVI76huUqtzlAazKHgiijpXC fPayLcChJfd8lQhKnDDxnDwCYBYoono4GRg6E8M/XmWnKu3w06nB/6JtY5EZEZ4JTc Ls6Rs/u56x5sozaE9TxltbKV3YH5hTFABAAIOg6efQ6qc4ZyXelz1bMHFgK7aaDnWZ 9Y02WV5P78L1/Fs/n5/fmLT+8/kOHgOC2mjZC6o6yNFynXnGH6uYX4iYf9Gpt3FU4F Kd4tFkH7OtvQA== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [f2fs-dev] [PATCH v2 00/14] Remove PG_private by using page/folio->private checks instead From: patchwork-bot+f2fs@kernel.org Message-Id: <178845180715.3423963.14220073137991024856.git-patchwork-notify@kernel.org> Date: Thu, 03 Sep 2026 16:10:07 +0000 References: <20260831-remove-pg_private-v2-0-3668159cd9e8@nvidia.com> In-Reply-To: <20260831-remove-pg_private-v2-0-3668159cd9e8@nvidia.com> To: Zi Yan Cc: david@kernel.org, willy@infradead.org, akpm@linux-foundation.org, muchun.song@linux.dev, ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, baolin.wang@linux.alibaba.com, nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, hannes@cmpxchg.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, kasong@tencent.com, mark.rutland@arm.com, irogers@google.com, jack@suse.cz, linux-doc@vger.kernel.org, amarkuze@redhat.com, peterz@infradead.org, kexec@lists.infradead.org, dave.hansen@linux.intel.com, ruirui.yang@linux.dev, adrian.hunter@intel.com, linux-mm@kvack.org, hongbohbli@tencent.com, hpa@zytor.com, guochunhai@vivo.com, skhan@linuxfoundation.org, ceph-devel@vger.kernel.org, baoquan.he@linux.dev, matthew.brost@intel.com, anna@kernel.org, sstabellini@kernel.org, zbestahu@gmail.com, rakie.kim@sk.com, minchan@kernel.org, richard@nod.at, x86@kernel.org, ebiggers@kernel.org, alexander.shishkin@linux.intel.com, mingo@redhat.com, slava@dubeyko.com, weixugc@google.com, yukuai@fygo.io, xen-devel@lists.xenproject.org, xiang@kernel.org, magiclinan@didiglobal.com, mhiramat@kernel.org, joshua.hahnjy@gmail.com, xiao@kernel.org, byungchul@sk.com, james.clark@linaro.org, acme@kernel.org, linux-raid@vger.kernel.org, linux-fscrypt@vger.kernel.org, bp@alien8.de, rostedt@goodmis.org, linux-mtd@lists.infradead.org, axelrasmussen@google.com, jefflexu@linux.alibaba.com, namhyung@kernel.org, jaegeuk@kernel.org, yuanchu@google.com, idryomov@gmail.com, osalvador@suse.de, jgross@suse.com, pratyush@kernel.org, linux-nfs@vger.kernel.org, tytso@mit.edu, oleksandr_tyshchenko@epam.com, song@kernel.org, corbet@lwn.net, pasha.tatashin@soleen.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-perf-users@vger.kernel.org, senozhatsky@chromium.org, tglx@kernel.org, jolsa@kernel.org, linux-fsdevel@vger.kernel.org, mathieu.desnoyers@efficios.com, linux-trace-kernel@vger.kernel.org, linux-erofs@lists.ozlabs.org, trondmy@kernel.org X-purgate-ID: tlsNG-4011c0/1788451868-5A5DBCFC-31A78567/0/0 X-purgate-type: clean X-purgate-size: 707 Hello: This patch was applied to jaegeuk/f2fs.git (dev) by Jaegeuk Kim : On Mon, 31 Aug 2026 15:25:23 -0400 you wrote: > Hi all, > > This patchset removes PG_private to make space for upcoming PG_folio > (reserved as __PG_folio) for identifying pages from a folio (more details > in Note below). Instead of checking PG_private, all code is changed to > check page/folio->private != NULL instead. > > [...] Here is the summary with links: - [f2fs-dev,v2,06/14] f2fs: stop using PG_private https://git.kernel.org/jaegeuk/f2fs/c/5ad9409a9533 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html From xen-devel-bounces@lists.xenproject.org Thu Sep 03 18:46:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 18:46:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407515.1640578 (Exim 4.92) (envelope-from ) id 1x2CSD-0005ym-Cc; Thu, 03 Sep 2026 18:46:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407515.1640578; Thu, 03 Sep 2026 18:46:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2CSD-0005yf-9t; Thu, 03 Sep 2026 18:46:29 +0000 Received: by outflank-mailman (input) for mailman id 1407515; Thu, 03 Sep 2026 16:11:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2A1s-0003cK-8c for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 16:11:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2A1r-004IFD-7k for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 18:11:07 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a999c16-bab6-0a2a0a5309dd-0a2a450cbbe0-12 for ; Thu, 03 Sep 2026 18:11:06 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a999c19-f479-0a2a450c0019-aceafc1fd664-3 for ; Thu, 03 Sep 2026 18:11:06 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id B2F9E42AD7; Thu, 3 Sep 2026 16:11:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 929241F00A3D; Thu, 3 Sep 2026 16:11:04 +0000 (UTC) Received: from [10.30.226.235] (localhost [IPv6:::1]) by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id 1986738119CB; Thu, 3 Sep 2026 16:10:07 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:Date:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788451864; bh=0GGJyshhlAlKfjOpgr7j97Mh0m1+5qav5ykVgFpFUIA=; h=Subject:From:Date:References:In-Reply-To:To:Cc; b=JxlK65jBcGgrsk9TAjqXxFnNxMSr2EUzOMWx942qjPBc2ybpTNX4WvsfPUiPxOaFl CvaTGDSQ1oizIiQKMXWYE2OVnwqIcGg5ydGC/+fP1+mqJ1GuK69hXukg6W16b7JT1r w2aaHejOOmNUZBUXMT7w7PrSbcyV2uNkwH9yBFLEDwdRzAceRy7X++SL5zY6FEYsfi FKkGMEhCG0T0FcIFQ+7naHWPwvlEPmk672vo9ZWS+QDqA+Td4EZLGZ+BJGrxKQ67ij TyZdI3BpB9bpqUcAWwS6PSI4Q7NaBwZ/Wa6AfOhrb223ZyOEtRQ2bZ96TF514AV+At BAPEfyocjj+3A== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [f2fs-dev] [PATCH RFC 00/14] Remove PG_private by using page/folio->private checks instead From: patchwork-bot+f2fs@kernel.org Message-Id: <178845180590.3423963.571905514968785918.git-patchwork-notify@kernel.org> Date: Thu, 03 Sep 2026 16:10:05 +0000 References: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com> In-Reply-To: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com> To: Zi Yan Cc: david@kernel.org, willy@infradead.org, akpm@linux-foundation.org, muchun.song@linux.dev, ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, baolin.wang@linux.alibaba.com, nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, hannes@cmpxchg.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, kasong@tencent.com, mark.rutland@arm.com, irogers@google.com, jack@suse.cz, linux-doc@vger.kernel.org, amarkuze@redhat.com, peterz@infradead.org, kexec@lists.infradead.org, dave.hansen@linux.intel.com, ruirui.yang@linux.dev, adrian.hunter@intel.com, linux-mm@kvack.org, hongbohbli@tencent.com, hpa@zytor.com, guochunhai@vivo.com, skhan@linuxfoundation.org, ceph-devel@vger.kernel.org, baoquan.he@linux.dev, matthew.brost@intel.com, anna@kernel.org, sstabellini@kernel.org, zbestahu@gmail.com, rakie.kim@sk.com, minchan@kernel.org, richard@nod.at, x86@kernel.org, ebiggers@kernel.org, alexander.shishkin@linux.intel.com, mingo@redhat.com, slava@dubeyko.com, weixugc@google.com, yukuai@fygo.io, xen-devel@lists.xenproject.org, xiang@kernel.org, magiclinan@didiglobal.com, mhiramat@kernel.org, joshua.hahnjy@gmail.com, xiao@kernel.org, byungchul@sk.com, james.clark@linaro.org, acme@kernel.org, linux-raid@vger.kernel.org, linux-fscrypt@vger.kernel.org, bp@alien8.de, rostedt@goodmis.org, linux-mtd@lists.infradead.org, axelrasmussen@google.com, jefflexu@linux.alibaba.com, namhyung@kernel.org, jaegeuk@kernel.org, yuanchu@google.com, idryomov@gmail.com, osalvador@suse.de, jgross@suse.com, pratyush@kernel.org, linux-nfs@vger.kernel.org, tytso@mit.edu, oleksandr_tyshchenko@epam.com, song@kernel.org, corbet@lwn.net, pasha.tatashin@soleen.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-perf-users@vger.kernel.org, senozhatsky@chromium.org, tglx@kernel.org, jolsa@kernel.org, linux-fsdevel@vger.kernel.org, mathieu.desnoyers@efficios.com, linux-trace-kernel@vger.kernel.org, linux-erofs@lists.ozlabs.org, trondmy@kernel.org X-purgate-ID: tlsNG-d25034/1788451866-51D34A5B-1E994AB6/0/0 X-purgate-type: clean X-purgate-size: 711 Hello: This patch was applied to jaegeuk/f2fs.git (dev) by Jaegeuk Kim : On Fri, 31 Jul 2026 22:13:23 -0400 you wrote: > Hi all, > > This patchset removes PG_private to make space for upcoming PG_folio > (reserved as __PG_folio) for identifying pages from a folio (more details > in Note below). Instead of checking PG_private, all code is changed to > check page/folio->private != NULL instead. > > [...] Here is the summary with links: - [f2fs-dev,RFC,06/14] fs/f2fs: stop using PG_private https://git.kernel.org/jaegeuk/f2fs/c/5ad9409a9533 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html From xen-devel-bounces@lists.xenproject.org Thu Sep 03 19:09:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 19:09:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407625.1640597 (Exim 4.92) (envelope-from ) id 1x2CoZ-0001C6-Et; Thu, 03 Sep 2026 19:09:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407625.1640597; Thu, 03 Sep 2026 19:09:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2CoZ-0001Bz-C4; Thu, 03 Sep 2026 19:09:35 +0000 Received: by outflank-mailman (input) for mailman id 1407625; Thu, 03 Sep 2026 19:09:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2CoX-0001Ao-B2 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 19:09:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2CoW-001vzs-Bi for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 21:09:32 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99c5d8-2eae-0a2a0a5409dd-0a2a4509bf9e-28 for ; Thu, 03 Sep 2026 21:09:32 +0200 Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99c5ea-be1a-0a2a45090019-94a39c01c8a2-3 for ; Thu, 03 Sep 2026 21:09:31 +0200 Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 683G36et1552022; Thu, 3 Sep 2026 19:09:11 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gbq3rpmag-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Sep 2026 19:09:10 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 683IuFJp019025; Thu, 3 Sep 2026 19:09:09 GMT Received: from smtprelay03.wdc07v.mail.ibm.com ([172.16.1.70]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4gecjasgkn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Sep 2026 19:09:09 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay03.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 683J8QNv28377652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 Sep 2026 19:08:27 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A9E2658051; Thu, 3 Sep 2026 19:09:07 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2712C5805E; Thu, 3 Sep 2026 19:09:04 +0000 (GMT) Received: from [9.61.21.65] (unknown [9.61.21.65]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTP; Thu, 3 Sep 2026 19:09:04 +0000 (GMT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=Mxbos8 yLoUG5l05cktSa/eE5AZRlKkT5dnJabdMoKZM=; b=OpgYyJ3sqPF3icuS6iTwbn FOHlBKUKR6wHmG2jdtMQBw4E6g75uWShqPfqjE4eJo1AbZhL0VK4Gl0LpD86w7Si rLSJTKqXe0yr6BgUOXttE496jfWlv7FFLcQmdJ4ksWR75asESR/DdAJP99xWXgwt fFqEH9UtkzxHmOZImWm0FrM7f56IhNTVZ3Q+luONSgBe/oMWCUwFM1k6+rDgFENM HWO8JxCIc9jzpIQJqRpSxT4lSItnf13WyMqj/OHb2L99jz40CLznrhzNPxyjEFAP vIbTXcogz/KRD+5/AjpAuQYp55sazeTMlchtWevqwwZbhZPRJSAytGIw11KkgpKg == Message-ID: <11d6e889-80f1-47ee-9335-4bf267195246@linux.ibm.com> Date: Thu, 3 Sep 2026 08:38:30 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 36/49] monitor: tighten monitor_printf*() To: =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= , qemu-devel@nongnu.org Cc: dave@treblig.org, =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Markus Armbruster , Gerd Hoffmann , "Gonglei (Arei)" , zhenwei pi , Kevin Wolf , Hanna Reitz , Paolo Bonzini , =?UTF-8?Q?Alex_Benn=C3=A9e?= , Pierrick Bouvier , Ani Sinha , "Michael S. Tsirkin" , Laurent Vivier , Amit Shah , Brian Cain , David Woodhouse , Paul Durrant , Richard Henderson , Marcelo Tosatti , Mark Cave-Ayland , Jiri Pirko , Jason Wang , Halil Pasic , Christian Borntraeger , Eric Farman , Matthew Rosato , Ilya Leoshkevich , David Hildenbrand , Cornelia Huck , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Hyman Huang , Peter Xu , Fabiano Rosas , Samuel Thibault , Stefan Berger , Zhao Liu , Nicholas Piggin , Chinmay Rath , Glenn Miles , Harsh Prateek Bora , Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , Yoshinori Sato , Artyom Tarasenko , Max Filippov , Stefan Hajnoczi , qemu-block@nongnu.org, kvm@vger.kernel.org, qemu-ppc@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org References: <20260825-qemu-no-hmp-v4-0-af60857c2fbe@redhat.com> <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com> Content-Language: en-US From: "Jason J. Herne" In-Reply-To: <20260825-qemu-no-hmp-v4-36-af60857c2fbe@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=EIc2FVZC c=1 sm=1 tr=0 ts=6a99c5d7 cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=20KFwNOVAAAA:8 a=VnNF1IyMAAAA:8 a=mY-fmJR8b8s-Z9VvxFgA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTAzMDE2NiBTYWx0ZWRfXw2J+kTXJGfn1 WcWhJsEEKsprqlfsqYgONRC4tPrPl/KW2YAz+ydFFPqURQAQrEhHyaP1NbTccY3EX4bWXK+6Wfh PZPoupQ6vroqMPTRxYPXyvIlo9Pde8cY9PZtrRMd1WLBLcNgNkdxGXUjOf1al1kQlCaT/fgUheP SextymGwkZ+1EyES9LOZGAeq2zltAJg0fzgcv3jDIXME72pp30Fxe/iDyhp5UgQ9hakCCokkZFY +cPalHfuleHacrmfeiI5UMMqjUbkCq4OA51vdlSvSxxi9ZhQ5TTNEKTDu7BMXTZlaEhpS/8mZ2a kKpHFgwFEH89wGxyzHwgozJygrwONovF7HchBWxVz8ofB3EgcOTZxt19MgnlkyljD038D89HabF IuV64srRATcXIQUfjgW2xI7R6EWyQiXukBD4SrphNm8Aaxd7V3oevIPqBqTzL0NaZKvUSsm0X5J UfHxa3svtK4RJvpmOTw== X-Proofpoint-GUID: EDEel76a6KP7UXpBN4hYy29pTPMb3EXw X-Proofpoint-ORIG-GUID: D_tguMhPXt_pKc1lezcNMaHsq0mH3uUL X-Proofpoint-Spam-Info: AW1haW4tMjYwOTAzMDE2NiBTYWx0ZWRfX/J2dzAAJu03S g1YtSBdlCCJIE7nHnAUiSZ725psmXf0F20KoIOuW/wWMyvfzAGxXFvNMLfWO3M7cJsxQ023Xw5v v10N19VuKtRa4pfcSVV9QCnTqUVG/vI= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-03_05,2026-09-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 impostorscore=0 suspectscore=0 priorityscore=1501 clxscore=1015 phishscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2609030166 X-purgate-ID: tlsNG-bad1c0/1788462572-BD2CC034-BE5CEC81/0/0 X-purgate-type: clean X-purgate-size: 832 On 8/25/26 3:09 PM, Marc-André Lureau wrote: > Rename monitor_printf->monitor_hmp_printf, monitor_vprintf-> > monitor_hmp_vprintf, and monitor_printc->monitor_hmp_printc, changing > the first parameter from Monitor * to MonitorHMP * to enforce type > safety. The implementation is also simplified: monitor_hmp_vprintf now > directly calls g_strdup_vprintf + monitor_puts, removing the virtual > dispatch via moncls->vprintf. > > The dev_print() callbacks are temporarily using the MONITOR_HMP(mon) > cast, they are fixed in the following commits. > > Signed-off-by: Marc-André Lureau > --- > ... > hw/s390x/s390-skeys.c | 9 +- > hw/s390x/s390-stattrib.c | 20 +-- The s390 pieces, Reviewed-by: Jason J. Herne From xen-devel-bounces@lists.xenproject.org Thu Sep 03 19:56:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 19:56:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407651.1640606 (Exim 4.92) (envelope-from ) id 1x2DYB-0007rG-Oe; Thu, 03 Sep 2026 19:56:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407651.1640606; Thu, 03 Sep 2026 19:56:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2DYB-0007r9-M1; Thu, 03 Sep 2026 19:56:43 +0000 Received: by outflank-mailman (input) for mailman id 1407651; Thu, 03 Sep 2026 19:56:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2DYA-0007r3-Db for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 19:56:42 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2DY9-003hzb-27 for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 19:56:41 +0000 Received: from mail-lj1-f177.google.com ([209.85.208.177]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1x2DY9-00615B-0h for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 19:56:41 +0000 Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-3a20367cf82so3321761fa.1 for ; Thu, 03 Sep 2026 12:56:41 -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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:Cc :To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version; bh=k3fzGiQmhZgakTGVWQn2DOnO/F5mnt6iQk1mulph9Ks=; b=YwPacC3QlyoKPw+cCAcq+ec0kv ouxrScx73oBE4J4XPA7LG7SQC08Ybyfsf+rv4n0zxZE2Ix2IBMQE92LNEWgolHVTt5pxASrHTacIx AHan/9Ur1jdhHMlEnRCVA4BHrW/dkbZhjkGmbrYWTVI/M8T7uDuyiagBIypCN/y68SNg=; X-Forwarded-Encrypted: i=1; AKwUvBzbToFpSTGv4E/QZ0xc+JgFlsFM6Dv+TnOJMiG3DwANnbb/zrO7VKXkaGq7gLgt2dtsuVX50Zkxpqs=@lists.xenproject.org X-Gm-Message-State: AFuF++lJwg0sCsoH1WmVkcK3VFXaLzvf6i6/6NRPMNp42JMhNab8aU5w m/cZEBmgqxIuE4tAosZQ7xnxe3l+fK0Qw+ZSd/IFFwcVkVVaXpDzft3OfBbreeJ9dSor1Q+Bykv 1i3u3k+I7NtmiypVmgMOZvp1o4G3lpM0= X-Received: by 2002:a2e:9fca:0:b0:3a3:44e4:f87b with SMTP id 38308e7fff4ca-3a371bd3a06mr1507331fa.14.1788465400056; Thu, 03 Sep 2026 12:56:40 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-1-ecc269f268b7@xenproject.org> <918e1522-3028-4d8c-9ba3-1c679b61861a@suse.com> In-Reply-To: <918e1522-3028-4d8c-9ba3-1c679b61861a@suse.com> From: George Dunlap Date: Thu, 3 Sep 2026 20:56:26 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1WrsThbObpBWNiooPdl6g5GD4KdV0uZywqrtZ9G6CAMJ0ViSUysDPUQ9IU Message-ID: Subject: Re: [PATCH v2 01/14] x86/domain_page: introduce IRQs-off variants of {,un}map_domain_page() To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 3, 2026 at 3:07=E2=80=AFPM Jan Beulich wrot= e: > > On 02.09.2026 11:43, George Dunlap wrote: > > From: George Dunlap > > > > Currently, map_domain_page() cannot be called in the context switch > > path. However, Xen already needs to update the slot of an incoming PV > > vcpu's GDT during context switch; and when we soon switch to per-vCPU > > root pagetables, we'll have to modify two more places. > > > > Xen currently solves the problem by special-casing the GDT/LDT L1 > > tables to be allocated from the xenheap, and stashing a pointer to its > > address in the xenheap in the domain struct. Rather than add more Xen > > pagetable pages to the xenheap, introduce a version of map_domain_page > > which can be called from the context switch path. > > > > The reason map_domain_page() cannot be called from the context switch > > path is x86's lazy context-switch state. Mapcache mappings are > > created in the page-tables that are loaded on the pCPU. When Xen is > > in a lazy context-switch state, current is the idle vCPU while the > > previously-running vCPU's page-tables remain loaded. If in this > > state, another pcpu wants access to the lazily-swapped-out vcpu's > > state, it will send a FLUSH_VCPU_STATE IPI to the processor, which > > will call sync_local_execstate(). > > > > sync_local_execstate() is implemented internally by calling a full > > __context_switch(). In addition to copying the processor state into > > the vcpu structure, this also switches the loaded pagetables to the > > idle vcpu's, which would in turn cause mappings created before the IPI > > to disappear mid-use. Therefore, mappings cannot be held in the > > mapcache when a FLUSH_VCPU_STATE IPI may execute. To this end, > > map_domain_page() calls sync_local_execstate() itself proactively when > > it detects a lazy context-switch state. This guarantees that the > > pagetables will remain consistent at least until the next context > > switch. > > > > But of course, that synchronization must not be triggered from the > > context switch path itself: sync_local_execstate() ends up in > > __context_switch(), so a call made while a context switch is in > > progress would recurse, and the assertions along that path (current > > being the idle vCPU) don't hold there either. > > > > A full synchronization is sufficient to prevent a FLUSH_VCPU_STATE IPI > > from switching the pagetables; however, it is not necessary. It > > suffices to maintain interrupts disabled from before the page is > > mapped until after it is unmapped. This condition is satisfied for > > the mappings used on the context switch path. > > > > Introduce {,un}map_domain_page_irqoff() variants for callers which > > guarantee that interrupts remain disabled from the map until the > > matching unmap. Under that guarantee the synchronization is > > unnecessary rather than merely inconvenient: no IPI can be delivered > > while the mapping is in use, so the lazy state cannot change under the > > caller's feet, and this_cpu(pgtable_vcpu) accurately identifies the > > mapcache to use (see 622c9a5ba95d "x86/mm: accurately track which vCPU > > page-tables are loaded"). The variants assert that interrupts are > > disabled on entry; the rest of the contract remains the caller's > > responsibility. > > > > This will be used by the next patch, which introduces a function which > > will be used to modify the incoming vCPU's per-domain mappings from > > within __context_switch(); it will also be used in future ASI > > patches (tearing down and establishing per-CPU stack mappings during > > context switch). > > > > No functional change for existing callers. > > > > Assisted-by: Claude Code:claude-fable-5 > > Signed-off-by: George Dunlap > > Reviewed-by: Jan Beulich > with one aspect for further consideration: > > > @@ -59,7 +68,7 @@ static inline struct vcpu *mapcache_current_vcpu(void= ) > > #define MAPCACHE_L1ENT(idx) \ > > __linear_l1_table[l1_linear_offset(MAPCACHE_VIRT_START + pfn_to_pa= ddr(idx))] > > > > -void *map_domain_page(mfn_t mfn) > > +static void *do_map_domain_page(mfn_t mfn, bool irqs_off) > > { > > do_...() commonly (but sadly not consistently) mark top-level hypercall > handlers. Personally I'd prefer if the "do" (but not the underscore) were > dropped here and ... > > > @@ -165,7 +174,19 @@ void *map_domain_page(mfn_t mfn) > > return (void *)MAPCACHE_VIRT_START + pfn_to_paddr(idx); > > } > > > > -void unmap_domain_page(const void *ptr) > > +void *map_domain_page(mfn_t mfn) > > +{ > > + return do_map_domain_page(mfn, false); > > +} > > + > > +void *map_domain_page_irqoff(mfn_t mfn) > > +{ > > + ASSERT(!local_irq_is_enabled()); > > + > > + return do_map_domain_page(mfn, true); > > +} > > + > > +static void do_unmap_domain_page(const void *ptr, bool irqs_off) > > ... here. Identifiers with a single leading underscore (and no following > upper-case letter) are designated for use by static functions, after all. Thanks -- I'll make that change for v3 if nobody objects. -George From xen-devel-bounces@lists.xenproject.org Thu Sep 03 20:17:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 20:17:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407665.1640615 (Exim 4.92) (envelope-from ) id 1x2DsM-0002bU-BN; Thu, 03 Sep 2026 20:17:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407665.1640615; Thu, 03 Sep 2026 20:17:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2DsM-0002bN-7y; Thu, 03 Sep 2026 20:17:34 +0000 Received: by outflank-mailman (input) for mailman id 1407665; Thu, 03 Sep 2026 20:17:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2DsK-0002b8-ML for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 20:17:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2DsI-008TeF-QV for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 22:17:30 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99d5b6-8faa-0a2a0a5109dd-0a2a450498c4-42 for ; Thu, 03 Sep 2026 22:17:30 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99d5d9-b57f-0a2a45040019-aa0a857c5b9b-3 for ; Thu, 03 Sep 2026 22:17:30 +0200 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-290-8pBVAKiHPSeoYsmz6NBrmA-1; Thu, 03 Sep 2026 16:17:27 -0400 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-49b7c1dc61eso2585915e9.3 for ; Thu, 03 Sep 2026 13:17:27 -0700 (PDT) Received: from redhat.com (IGLD-80-230-79-236.inter.net.il. [80.230.79.236]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cee6158e9sm96154145e9.12.2026.09.03.13.17.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Sep 2026 13:17:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788466649; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D24gK67PaiLCP7h+ayMzbPrsYL1do2o4/gKLggEB7CE=; b=As7kjHAC4f0S4qAOu7zTIlkij9l2NjoOc0M/d1dQDeVqo05zIxtR6rinY7o41eZfXbMN8h Qc1Lz8Qf5bwOiL3RgBZyxHPmlxORnfaSqlpZTsNzJgSX2vGbFO/3H5Ac9srlw0JNL3YuUI Khr1C7CEPqu5VYAwa1i7nYlOr6tKZIM= X-MC-Unique: 8pBVAKiHPSeoYsmz6NBrmA-1 X-Mimecast-MFC-AGG-ID: 8pBVAKiHPSeoYsmz6NBrmA_1788466646 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788466646; x=1789071446; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=D24gK67PaiLCP7h+ayMzbPrsYL1do2o4/gKLggEB7CE=; b=KydcuZkt7lpAZl8SBUb/qwMoxb6WATe+RgvAX1iXI940jLaCXYhkcLlL6HiHra/034 yXTAlXRhkBXDQDUi4+TcmEv6DwpE6iN6Gr52Xcn2FyYkoDEm8GOCrFQTNjZPLh3o4wEW z7ZG32QyrIUVRZdCgCv99ffcvDdkhpODq3nIPXYiFMxGYtuozylDpuYZ/kwn8K0C618b GwYRJH2nUGC9FzI7H7Ll+eF2SZUvrgXeidn0SLe9XqssWb81Frplt1SSpyi0KU50VHX9 qObHrwDQx8510K1L/gRIx7AdBdSIWu06bBrkvWQ1El43sEEYhBtxev956wwurmoOlQP5 41og== X-Forwarded-Encrypted: i=1; AKwUvBwSxyZh5dUSeFP8NKoAvsvL4DqMbLa1r5fhGAcV3F/aaWwkCJ+Xu+B1RJ49f+Oh6/wFLojyqtkqlfE=@lists.xenproject.org X-Gm-Message-State: AFuF++mp+VY7mN+oxfPsT/yk6bOoI2UX3giyV+N4PMhuje+iWVX4WoLr sXJ3pCMOaBG2HjB1m07kgPOQiHa48X92ChsToC/wCXEB5DDuMnmMDqQNUcok9d33ctpAERptbXu ZY6AaOmzMBeyN5wkrI1l65VfnwzlmqzlckJZoFmHPvWdMbcnzfKd3Die3grzvXpOVU8Bu X-Gm-Gg: AYBFou3pQhvr0OGBhtyMqlOe1KP8e5Qw0KrRXlW6lYkr0peCNbfnbqjHbhTGBKw162L 78J3cPPD5u8PFY1/emvpkunrJw6VJxqxtq+0N4Ad4Hb8mVFlky8YFY5bNPzbPxpo6qVLF32zXC8 FIMIiGkwbiweF42CLWGIO1JzYf0oaq5wnVFyv4VcsaiaHrm1KTxGlyA4lPsL1JgSTO4eBVaQkjX 1sOQoqrQsc3wICoHj4G6Wk7wajg9pXAZP85Lm8JZLng6NvRdVmZ0GdCvj6E7Y1H5F5OhSFmiNj3 i5Ab727KGoL66+8ftiSGLmTi3Ouv1ArWKg1mOZie55AIwCvDrCUOCvKV3xwqQtkJNmfiFFGsPld Zz2o47+7p1i9juPeeFVp0gCU= X-Received: by 2002:a05:600c:8b05:b0:499:9240:9a1c with SMTP id 5b1f17b1804b1-49cf82787camr7856025e9.15.1788466646251; Thu, 03 Sep 2026 13:17:26 -0700 (PDT) X-Received: by 2002:a05:600c:8b05:b0:499:9240:9a1c with SMTP id 5b1f17b1804b1-49cf82787camr7855325e9.15.1788466645715; Thu, 03 Sep 2026 13:17:25 -0700 (PDT) Date: Thu, 3 Sep 2026 16:17:20 -0400 From: "Michael S. Tsirkin" To: Igor Mammedov Cc: Dongli Zhang , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug Message-ID: <20260903160401-mutt-send-email-mst@kernel.org> References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> MIME-Version: 1.0 In-Reply-To: <20260903172835.0e253a25@imammedo> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EAh02STIwY8mYAYNjkdh-89iPgDAiRh1oc3sXZI54ZU_1788466646 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788466650-585C7B50-598268B2/0/0 X-purgate-type: clean X-purgate-size: 6661 On Thu, Sep 03, 2026 at 05:28:35PM +0200, Igor Mammedov wrote: > On Wed, 26 Aug 2026 09:15:47 -0700 > Dongli Zhang wrote: > > > On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrang wrote: > > > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: > > >> Hot-unplugging a PCI device can require cooperation from the guest. For > > >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest > > >> eventually writes the ACPI PCI eject register. For PCIe native hotplug, > > >> QEMU notifies the guest through the PCIe hotplug mechanism and waits for > > >> the slot unplug flow to complete. Only after that completion does QEMU > > >> unrealize the device and emit DEVICE_DELETED. > > >> > > >> This can leave a device stuck in the unplug pending state when the guest > > >> does not cooperate. Examples include: > > >> > > >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is > > >> unavailable. > > >> > > >> 2. The guest is stalled and cannot handle the hot-unplug event. For > > >> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this > > >> for ACPI-based hot-unplug. > > >> > > >> 3. The device was attached to a slot that the guest cannot use. For > > >> example, a pcie-root-port only supports slot 0. If a device is added to a > > >> non-zero slot below a pcie-root-port, the guest may never discover the > > >> device and therefore may never complete the unplug request. > > all of above is actually expected, no (functioning) driver => no hotplug/unplug. > it's the guest problem. Once device it exposed to guest its life-cycle > not longer owned by QEMU. > > That's what one would see in real hw as well, you press eject button > but it will not do anything if OS doesn't process it. > also see comment at the end. > > > >> > > >> The non-zero slot case has also been discussed in: > > >> > > >> hw/pci: warn when PCIe device is plugged into non-zero slot of downstream port > > >> https://gitlab.com/qemu-project/qemu/-/commit/ > > > ca92eb5defcf9d1c2106341744a73a03cf26e824 > > >> > > >> hw/pci: add comment to explain checking for available function 0 in pci hotplug > > >> https://gitlab.com/qemu-project/qemu/-/ > > > commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5 > > >> > > >> pci: don't skip function 0 occupancy verification for devfn auto assign > > >> https://gitlab.com/qemu-project/qemu/-/commit/ > > > e228d62b4af29bca698ec57efdceb46f392f5444 > > >> > > >> For example, if root-port.1 is a pcie-root-port, the following command adds > > >> a vhost-scsi-pci device to an invalid slot: > > >> > > >> (qemu) device_add vhost-scsi-pci,id=scsi01,wwpn=naa.5001405324af0985,bus=root-port.1,addr=01.0 > > >> warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent device only allows plugging into slot 0. > > > > > > This rather looks like it should be a fatal error, not a mere warning. > > > > > > If I follow the commit ca92eb5def it links to https://bugzilla.redhat.com/show_bug.cgi?id=2128929 > > > which states that this configuration is going to lead to a crash in > > > QEMU on guest OS shutdown. IMHO that crash is sufficient to justify > > > making this a fatal error. > > > > > > If we actually wanted this to remain a warning, then that shutdown > > > crash would need to be fixed. > > > > > > > Thank you very much! > > > > I see that the issue has been fixed. The ticket mentions the following. > > > > "What I am observing is that it seems when the slot ID != 0, the guest OS seems > > to ignore this and we never seem to hit ich9_pm_device_unplug_cb()." > > > > Based on my experience and evaluation, ACPI-based hotplug is more likely to > > encounter an issue where the guest VM does not respond to an unplug operation. > > I'm not sure it's a good idea to delete device when guest still thinks it's there > (you can make guesses on QEMU side if it's in use, how useful those are is questionable). > > as far as I know, ACPI hotplug has no notion of surprise removal (pls educate me if it's not the case), why would it not? how do you think you can pull a laptop out of a dock? I expect bus check + _STA and config space saying it is gone will do exactly that. Here's linux code: static void acpiphp_check_bridge(struct acpiphp_bridge *bridge) { struct acpiphp_slot *slot; /* Bail out if the bridge is going away. */ if (bridge->is_going_away) return; if (bridge->pci_dev) pm_runtime_get_sync(&bridge->pci_dev->dev); list_for_each_entry(slot, &bridge->slots, node) { struct pci_bus *bus = slot->bus; struct pci_dev *dev, *tmp; if (slot_no_hotplug(slot)) { ; /* do nothing */ } else if (device_status_valid(get_slot_status(slot))) { /* remove stale devices if any */ list_for_each_entry_safe_reverse(dev, tmp, &bus->devices, bus_list) if (PCI_SLOT(dev->devfn) == slot->device) trim_stale_devices(dev); /* configure all functions */ enable_slot(slot, true); } else { disable_slot(slot); } } if (bridge->pci_dev) pm_runtime_put(&bridge->pci_dev->dev); } so weirdly it wants bus check on a parent bus, otherwise it will not trim devices? probably a bug, but easy to work around. > so I wouldn't do what you are proposing here at all, it's basically asking for disaster to happen. > And all this is basically for dealing with abused qemu flexibility. > > Please (re)formulate usecase and make it more clear as what is eludes me > no matter how many times i've read this cover letter. > > On positive note: > > What you can try to implement is native PCI-E support for surprise removal. > How hard that would be I don't know. And I would well expect if one deviates from > real hw expectations/configs (such as not 0 slot/partial func removal), > one would quickly stumble upon issues as that's not what what vendors write/test > drivers for. > > Even if it's not likely to be used in practice (guest still might not support it), > it may serve as test-bed for guest drivers. > > > Thank you very much! > > > > Dongli Zhang > > From xen-devel-bounces@lists.xenproject.org Thu Sep 03 20:20:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 20:20:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407675.1640625 (Exim 4.92) (envelope-from ) id 1x2DvY-0004Cl-Th; Thu, 03 Sep 2026 20:20:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407675.1640625; Thu, 03 Sep 2026 20:20:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2DvY-0004Cd-PE; Thu, 03 Sep 2026 20:20:52 +0000 Received: by outflank-mailman (input) for mailman id 1407675; Thu, 03 Sep 2026 20:20:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2DvX-0004CX-Ll for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 20:20:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2DvW-004kUU-HW for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 22:20:50 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99d690-bab6-0a2a0a5309dd-0a2a4504d712-18 for ; Thu, 03 Sep 2026 22:20:50 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99d6a0-b57f-0a2a45040019-aceafc1fb2ae-3 for ; Thu, 03 Sep 2026 22:20:50 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 3C2A740E20; Thu, 3 Sep 2026 20:20:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 564641F000E9; Thu, 3 Sep 2026 20:20:47 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="From:To:Cc:Subject:In-Reply-To:References:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788466848; bh=2p+gZUX1lywqlPgIj4po3j9VmppV3CjsC0U+DQIfxj8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=nQO5w9M8u/O0h/rNT81unSxjiltu3uhgADJgzfQJmDKoL7io3aqNaZtffq2vbjc7I q2UtZlhWSdBVQQEMGNCbRru5irWASsLl+Ko9DJvHMUgAcZtEpg9/gnfDd7nhpwWTSg SFRomvsXXqfy2hx/yIiHkUMB+GMBw92T43tk4V8JFP0ajhIGm/9fpmXwZ1sFNlcqJB kryC25dRb1rtpj1utmwn8LWv95iRM+XaFQ7xGKPUMizOmk/aSnWEZ9WvZCo4BvPhr7 Bx7fCrGhNz+ObSNjjir0c7/XphKv+8j4ewACBpXHQl5QgRsKJSadaFsove9+nu3aKI hcgaWF48Ao6fw== From: Thomas Gleixner To: Daniil Tatianin , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: Daniil Tatianin <99danilt@gmail.com>, "H. Peter Anvin" , Steve Wahl , Justin Ernst , Kyle Meyer , Dimitri Sivanich , Russ Anderson , Juergen Gross , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Daniil Tatianin Subject: Re: [PATCH] x86/apic: Remove dead disable_esr machinery In-Reply-To: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> References: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> Date: Thu, 03 Sep 2026 22:20:45 +0200 Message-ID: <87tso69jdu.ffs@fw13> MIME-Version: 1.0 Content-Type: text/plain X-purgate-ID: tlsNG-ebf023/1788466850-524CBB50-572E7F4A/0/0 X-purgate-type: clean X-purgate-size: 263 On Thu, Sep 03 2026 at 01:01, Daniil Tatianin wrote: > From: Daniil Tatianin <99danilt@gmail.com> ... > Signed-off-by: Daniil Tatianin Seems you can't decide which of your alter egos is author and signing off on the patch. From xen-devel-bounces@lists.xenproject.org Thu Sep 03 20:34:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 20:34:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407684.1640632 (Exim 4.92) (envelope-from ) id 1x2E8t-0005xZ-TJ; Thu, 03 Sep 2026 20:34:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407684.1640632; Thu, 03 Sep 2026 20:34:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2E8t-0005xS-Qk; Thu, 03 Sep 2026 20:34:39 +0000 Received: by outflank-mailman (input) for mailman id 1407684; Thu, 03 Sep 2026 20:34:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2E8s-0005xK-EC for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 20:34:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2E8q-00FqXT-9i for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 22:34:36 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99d9d7-e002-0a2a0a5209dd-0a2a4508dd76-4 for ; Thu, 03 Sep 2026 22:34:35 +0200 Received: from [178.154.239.136] (helo=forwardcorp1b.mail.yandex.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99d9db-f659-0a2a45080019-b29aef888f42-3 for ; Thu, 03 Sep 2026 22:34:35 +0200 Received: from mail-nwsmtp-smtp-corp-main-34.sas.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-34.sas.yp-c.yandex.net [IPv6:2a02:6b8:c24:fa2:0:640:41ee:0]) by forwardcorp1b.mail.yandex.net (postfix) with ESMTPS id A69A280AD8; Thu, 03 Sep 2026 23:34:34 +0300 (MSK) Received: from [IPV6:2a02:6bf:8080:d5c::1:3a] (unknown [2a02:6bf:8080:d5c::1:3a]) by mail-nwsmtp-smtp-corp-main-34.sas.yp-c.yandex.net (smtpcorp) with ESMTPSA id WYsZl6waMuQ0-SJOJ4uIE; Thu, 03 Sep 2026 23:34:34 +0300 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=default header.d=yandex-team.ru header.i="@yandex-team.ru" header.h="From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID" X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1788467674; bh=HBcAjfpMlA7r60pPF6BOpwXqiGeqg7IHcYn4i21hws0=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=uAk54gbjsyrsqbPeh6xGMu3IEHk2AqRIhGR7cPeS7Iz080EYc6Imz/NalWxaQFfh+ i5WFVpaRYiWhNNiMlnfZbErjpTFgOUMR10/FW+fvBHryw1OYrhCwq4Kuh82VePsBsh QLQZ5HQsv+ebLZ8VVF3NsT64Jw7etZxOLC6BEbl8= Authentication-Results: mail-nwsmtp-smtp-corp-main-34.sas.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <5c57eb31-3548-4e0a-8b02-315057d029b8@yandex-team.ru> Date: Thu, 3 Sep 2026 23:34:32 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/apic: Remove dead disable_esr machinery To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: Daniil Tatianin <99danilt@gmail.com>, "H. Peter Anvin" , Steve Wahl , Justin Ernst , Kyle Meyer , Dimitri Sivanich , Russ Anderson , Juergen Gross , Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20260902220124.2931854-1-d-tatianin@yandex-team.ru> <87tso69jdu.ffs@fw13> Content-Language: en-US From: Daniil Tatianin In-Reply-To: <87tso69jdu.ffs@fw13> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788467675-D4D7087B-2A4F938D/0/0 X-purgate-type: clean X-purgate-size: 462 On 9/3/26 11:20 PM, Thomas Gleixner wrote: > On Thu, Sep 03 2026 at 01:01, Daniil Tatianin wrote: > >> From: Daniil Tatianin <99danilt@gmail.com> > ... >> Signed-off-by: Daniil Tatianin > Seems you can't decide which of your alter egos is author and signing > off on the patch. Yeah, sorry about that. Originally had my git email configured incorrectly. The right one is in the S-o-b (the one I sent the patch from). From xen-devel-bounces@lists.xenproject.org Thu Sep 03 21:28:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 21:28:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407708.1640643 (Exim 4.92) (envelope-from ) id 1x2EyL-000497-Lb; Thu, 03 Sep 2026 21:27:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407708.1640643; Thu, 03 Sep 2026 21:27:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2EyL-000490-IA; Thu, 03 Sep 2026 21:27:49 +0000 Received: by outflank-mailman (input) for mailman id 1407708; Thu, 03 Sep 2026 21:27:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2EyK-00048r-0n for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 21:27:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2EyI-00BaQ5-JN for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 23:27:46 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99e651-2eae-0a2a0a5409dd-0a2a45028d88-0 for ; Thu, 03 Sep 2026 23:27:45 +0200 Received: from [13.59.128.245] (helo=basilisk.relay-egress.a.mail.umich.edu) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99e64f-6ca4-0a2a45020019-0d3b80f5da54-3 for ; Thu, 03 Sep 2026 23:27:44 +0200 Received: from top-brounie.authn-relay.a.mail.umich.edu (ip-10-0-74-245.us-east-2.compute.internal [10.0.74.245]) by basilisk.relay-egress.a.mail.umich.edu with ESMTPS id 6A99E64E.31EFB142.263FAEC8.3181220; Thu, 03 Sep 2026 17:27:42 -0400 Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by top-brounie.authn-relay.a.mail.umich.edu with ESMTPSA id 6A99E64D.392E2C5E.6AB0DE6D.1021951; Thu, 03 Sep 2026 17:27:42 -0400 Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-3a1eb6fa0f4so4763221fa.2 for ; Thu, 03 Sep 2026 14:27:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-2 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1788470862; bh=sFTnKPd4I05xSc/JFvWg12Da0qJ8iucIwim/WK0YEwk=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=N3AqY28yPjaCWeEKdqW0vx6TcruI9hrRLLNptdEQNYvGweAH9KhyATKz6McelQHhY sVRCb6lHKNNI6gnNm6zzNSp96xY7ekDbyCtdS6QV/EFfzisiwPdOJ/L5MM/yzBfGm8 FLbmhNcJr8iIwIVxdKs/haagXMnI//ASEiNnlRODjmaElxbyf9TmyFZeokVHgKoPL9 2TNErkEjinzO11B7IkQn0JOqy0yR4xqaNJ/Y/ngu6WyrCWO0gCj/3kHY9C2B5RZ2TU OEjYEgSgPwtNL8c8pkm0k6VGJVDap3j5KmDo1flM00mFliOey28NbDV+U/HNH+qEjT wI/WD9f44APow== Authentication-Results: top-brounie.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.208.175 (mail-lj1-f175.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvBwopSdPmS3oDYC71hNRRFqvlkdu6+GlggRWHxTEE6XDkDKp5dWWl9cR0lwlkAFfCkS2Jv2o9anvYas=@lists.xenproject.org X-Gm-Message-State: AFuF++lMJncKOvAZYFiIGpeZjHZ/X+cBCCuj3akJ2k5zLhmolSCib/rp HfEhYVzcax4/GqyCvRBFli49ufuA2RLiwGK7WQ7MfKsjlJp4oLXl7QE/xc5u+MijmW2upcjGEst 4xRP2mTY5gBL+8TGDDd9ZfyYo8doiaM0= X-Received: by 2002:a05:651c:15c1:10b0:3a3:5a01:a759 with SMTP id 38308e7fff4ca-3a371f0d685mr1890871fa.10.1788470860002; Thu, 03 Sep 2026 14:27:40 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-2-ecc269f268b7@xenproject.org> <5071d4da-d9b1-45cd-8e9b-778df417ee7b@suse.com> In-Reply-To: <5071d4da-d9b1-45cd-8e9b-778df417ee7b@suse.com> From: George Dunlap Date: Thu, 3 Sep 2026 22:27:27 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1VZKV3g83wsokELPxfkJQdeAisT9ktpksCxMBY7cjLbVjBLuOPAhzrSgNs Message-ID: Subject: Re: [PATCH v2 02/14] x86/mm: introduce populate_perdomain_mapping() To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1788470865-67CBA2AC-53A14287/0/0 X-purgate-type: clean X-purgate-size: 2616 On Thu, Sep 3, 2026 at 4:57=E2=80=AFPM Jan Beulich wrot= e: > > + if ( likely(this_cpu(pgtable_vcpu) =3D=3D v) ) > > + { > > + unsigned int i; > > + > > + /* > > + * Fast path: v's page-tables are loaded on this pCPU, so the = L1 > > + * entries can be reached using the recursive linear mappings. > > + */ > > + pl1e =3D &__linear_l1_table[l1_linear_offset(va)]; > > As mentioned elsewhere, I'm concerned of this (or really any) new use of > the linear page tables. (Which, ftaod, isn't an objection.) FWIW here we can drop this fast path at any time, and we get exactly the same result as if we drop it from the patch now. > > + l2tab =3D map_domain_page_irqoff(l3e_get_mfn(l3tab[l3_table_offset= (va)])); > > l3tab[] isn't used any further, so I think it wants unmapping right away.= No > need to have undue pressure on the number of active mappings. Ack > > + /* > > + * As the fast path -- and the slow path holds IRQs off throug= hout, > > + * so replacing area-owned backing here is never permitted. > > + */ > > With this comment I think ... > > > + if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) ) > > + { > > + ASSERT_UNREACHABLE(); > > + free_domheap_page(l1e_get_page(*pl1e)); > > ... this call should be removed from here (I would have suggested to comm= ent > it out, but Misra dislikes that iirc). Otherwise it would in principle be > reachable in release builds. Ah, right -- sorry, this was safe in v1's "xenheap-walk" approach which doesn't need to disable interrupts; with the "mapcache-walk" approach we can't do this any more. > Maybe instead of ASSERT_UNREACHABLE() it should really be BUG() here. Hrm, docs/misc/xen-error-handling.txt used to have guidelines about *which* error handling to use. Basically, BUG() is an immediate hypervisor crash DoS in production, and should only be used when there's no way to continue without doing something worse. Leaking memory is a lower-grade DoS, and so would be preferable in production (though in this case probably with a printk, so there's some hope of figuring out what's wrong). In theory we could allow callers who knew they'd take the fast path to do the free; but then we couldn't just rip out the fast path without doing more surgery. So I'd propose: In both fast and slow paths, replace the free with a printk (keeping the ASSERT_UNREACHABLE), with a comment explaining why leaking is preferable to BUG. -George From xen-devel-bounces@lists.xenproject.org Thu Sep 03 22:36:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 03 Sep 2026 22:36:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407736.1640652 (Exim 4.92) (envelope-from ) id 1x2G2b-0004UF-Cv; Thu, 03 Sep 2026 22:36:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407736.1640652; Thu, 03 Sep 2026 22:36:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2G2b-0004U8-98; Thu, 03 Sep 2026 22:36:17 +0000 Received: by outflank-mailman (input) for mailman id 1407736; Thu, 03 Sep 2026 22:36:16 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2G2Z-0004U1-SQ for xen-devel@lists.xenproject.org; Thu, 03 Sep 2026 22:36:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2G2W-00EFWR-Cr for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 00:36:12 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a99f61a-2eae-0a2a0a5409dd-0a2a4509e210-20 for ; Fri, 04 Sep 2026 00:36:12 +0200 Received: from [13.59.128.245] (helo=basilisk.relay-egress.a.mail.umich.edu) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a99f656-be1a-0a2a45090019-0d3b80f5a572-3 for ; Fri, 04 Sep 2026 00:36:07 +0200 Received: from osmium-kasha.authn-relay.a.mail.umich.edu (ip-10-0-72-125.us-east-2.compute.internal [10.0.72.125]) by basilisk.relay-egress.a.mail.umich.edu with ESMTPS id 6A99F655.35E88EAF.104FA6D8.3696080; Thu, 03 Sep 2026 18:36:05 -0400 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by osmium-kasha.authn-relay.a.mail.umich.edu with ESMTPSA id 6A99F655.ACD85A0.EDFC2CE.3709069; Thu, 03 Sep 2026 18:36:05 -0400 Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-3a1f628b0afso3783911fa.3 for ; Thu, 03 Sep 2026 15:36:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-2 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1788474965; bh=mPuE8rUN7rOnYnvpdzetJVflsaBSjwbeBijnVpJKcWg=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=QD2G4Rhb6krGdCVQn5qjLGrnqeJmhS8/Q7Ueti1aqp5DYLJB5wX2qj+dIxCMSfCIt kFYSeAuuQ2eGk+VqvphbelAUozXMV+Dek2YdaZm2ZzFuCwJqShZ9f+u6ZNC4Cc/Kms VBiWDvrO8+0+nLQAHqtci+tWf7ZLcCdRe/kSpH+B6/4CQQPs/bua2X9p1mLQ8HSn/h dgToZxo+kwnGVsnz1Q0cHSzOgF9olgX8IkY4DHogiqzdqln6SXd6Wo/TcoZa3HsPw4 YbBx0iKF0R0Pt9QuVS4naBGQ5KizSLu6qqeBh1ZP9kr/F3ON8wY2o35mSDq7PbNrFL HqjWNlqhhzGSg== Authentication-Results: osmium-kasha.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.208.180 (mail-lj1-f180.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvBz/e1sAsJtwO4WVvtHOLZs4g8oq/sNdlPQ+Z4K+qK4p7PIXJ3B/jkxMWaxtjFVGpmBcWYhyICcodBE=@lists.xenproject.org X-Gm-Message-State: AFuF++lHQAan1Ogvs6fj3j9cs7fqQg4ah1eDIP8uh5px4fMMGXVFdvPx dGi+56T8T8xeL/M6c4dsFR3EUIZf5JZLOIQcTL0nLgOYWiEO9u+0x2rORiBT0WNpBgoyB9LdzvC G3eLhvrvWdLulIxsrPBw25afxCFDkPBA= X-Received: by 2002:a2e:be1e:0:b0:3a3:314d:1169 with SMTP id 38308e7fff4ca-3a371b39b13mr3814611fa.1.1788474962891; Thu, 03 Sep 2026 15:36:02 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> In-Reply-To: <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> From: George Dunlap Date: Thu, 3 Sep 2026 23:35:50 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1Ux-fqmiJBw6Gd1JaGXq2Ucd8MmSQK7SXPTQ6y9BWb_d6N2XmKCzwxdsUE Message-ID: Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, Juergen Gross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1788474972-FCA16034-F6BEEB70/0/0 X-purgate-type: clean X-purgate-size: 3530 On Thu, Sep 3, 2026 at 5:11=E2=80=AFPM Jan Beulich wrot= e: > > On 02.09.2026 11:43, George Dunlap wrote: > > From: Roger Pau Monn=C3=A9 > > > > Currently, update_xen_slot_in_full_gdt() uses the stashed direct-map > > pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vcpu's > > page tables with Xen's GDT, by writing a stashed per-cpu copy of a > > pre-baked L1 entry (either 64-bit or compat version). > > > > Switch this to using populate_perdomain_mapping(), which doesn't rely > > on the stashed address of the l1 page in the direct map. Rather than > > also stashing a pre-baked value for the payload, compute the mfn from > > the per-cpu GDT pointer at use: the conversion is a handful of cycles > > on a path costing thousands, and computing at use removes the > > parallel {,compat_}gdt_l1e bookkeeping along with its boot-ordering > > constraint (the cached value could only be generated after Xen's > > physical relocation, and had to be in place before the first context > > switch; a use-time lookup is correct by construction). The flags on > > the final mapping are identical. > > > > Signed-off-by: Roger Pau Monn=C3=A9 > > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 > > Signed-off-by: George Dunlap > > --- > > Changes in v2: > > - Drop the {,compat_}gdt_mfn caching entirely (suggested by Andrew > > Cooper): compute virt_to_mfn() from the per-cpu GDT pointer at use. > > The PDX lookup behind it measures ~5-10 cycles warm against a > > ~1,500-cycle context switch, and this removes the double > > bookkeeping and the after-relocation caching constraint. The > > cached-MFN assertion goes with the cache: a use-time computation > > from a live pointer needs no staleness check. > > This looks to contradict what 564d261687c0 ("x86/ctxt-switch: Document > and improve GDT handling") used as justification to put in place the > caching. Also Cc-ing J=C3=BCrgen, who also was involved there, for possib= le > further insight. > > Functionally the change looks okay to me, but the above will need > sorting, at the very least by specifically discussing why effectively > undoing that earlier change is okay. So looking back at the thread, J=C3=BCrgen measured a 14% improvement for something that might be described as a microbenchmark before and after the patch (a benchmark purposely trying to set up an unusual scenario to maximize the effect of context switch overhead, not one to represent a typical workflow). But are the numbers really plausible? Even at an implausible 100k switches/s across the box, saving 100 cycles per switch is about 0.04% of eight 3 GHz cores. At any rate, we're already adding several map/unmap operations, and about to add several more. Keeping the PTE caching would require adding a separate path that can write just PTEs, which then will potentially further complication future paths where we need to make sure we handle both domain-wide perdomain areas and per-vcpu areas. If it were easy I would already have been keeping it. I'd be inclined to say: Since we're going to be adding more populate_perdomain_mapping() calls anyway, let's do it the simple correct way first; and then explore the idea of stashing mfns of frequently-mapped L1s (rather than having to walk L3 -> L2 -> L1); and at that time look into stashing baked l1es to avoid conversions. -George From xen-devel-bounces@lists.xenproject.org Fri Sep 04 05:47:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 05:47:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407844.1640660 (Exim 4.92) (envelope-from ) id 1x2Mln-0002Hn-UV; Fri, 04 Sep 2026 05:47:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407844.1640660; Fri, 04 Sep 2026 05:47:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Mln-0002Hf-Pc; Fri, 04 Sep 2026 05:47:23 +0000 Received: by outflank-mailman (input) for mailman id 1407844; Fri, 04 Sep 2026 05:47:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Mln-0002HZ-7e for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 05:47:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Mll-00Evvm-Pr for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 07:47:21 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a5b67-8faa-0a2a0a5109dd-0a2a450c85c8-12 for ; Fri, 04 Sep 2026 07:47:21 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a5b69-f479-0a2a450c0019-d155802ddc7e-3 for ; Fri, 04 Sep 2026 07:47:21 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49b965570d7so6680045e9.0 for ; Thu, 03 Sep 2026 22:47:21 -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-49cf7710aa5sm41744705e9.7.2026.09.03.22.47.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 22:47:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788500841; x=1789105641; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=49xhD3ztLT/F9jM3xzEFoV+axbupICEp6pC99szlEjA=; b=VMNggHhZk8ODPm50SAzPzoKFBw0HUer4tYd6V2pj+dR7MloKzrvTHSQqTvGGr8JU8Z UtXF2jOOaV/ps++HlSgs8+De6v8z7tAz0CzJL6Am6reRpblN3QBvklSR4IiEIlzhANtN aUIXk4YImgB5b2bjetCwWs1sc2z9C+Rw9QqOH8DYkU/HKFN1k4F8vhi3ygaX3glTFUDA YM/YMmJbRpANuPbd/RFyZFNOxA4lop/STymTYHt6Qm80xsKY2ho5M6udiY2XhZvk5Ik8 CsH+ZZg6zsbynnVGiFdDnayk5t/RLtO6vndk7wFrnfVuKs7Np0sYQJVrjvDkzuej18az GEmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788500841; x=1789105641; h=content-transfer-encoding:content-type: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:content-type; bh=49xhD3ztLT/F9jM3xzEFoV+axbupICEp6pC99szlEjA=; b=eJMWAaype2g/r53PPm3VZqsRHDmwK3vCAUigHWk0rjsSri6FBO1vEA8W5ChBgo0QiO HmdnNqvQs3tXPXEfqQOoCTPRKs09dzPnWqbmnQFiVyXznDUEvJZplZ45R5h6FO21aXnQ rPlnodVy/9Kap8Sy0swqwRowfX1A3amX3xW5qUnZp0PIXrq8vJRiI76mPwt/FPz/GnxA R7uQxY2Mw1cqdLXzzBaHhcnTDJHQv/YbZslYcySQW4PSWi2BjQ44jEAu7gZKK5JoJSyd Y8q41BXC6jc0RLiQxtw78uifOaIXynmDLLB5UiBaPQMrV3RhhaSbHnB6behWw20icBeP K/Ig== X-Forwarded-Encrypted: i=1; AKwUvBwkcm0wrjnm5XXArhkKy+0tW8rWKlezkgKcr6ZLBxkFto13fLmiMAEz/uiyPJOeneAqCZ9pRfy7ino=@lists.xenproject.org X-Gm-Message-State: AFuF++m2lr6HTfS063SLyX39Gg367ELC75X3uH3osKtuOHcKMJG85Jh8 aPVyu9Kk0VeUBjFPgxt0FApOXPF7Un4aKdLqWGw+wkocCqKer+BzB8CTXJX0KAy5xw== X-Gm-Gg: AYBFou2z6wtZumaFK4vPVP2ptElQ65Z8H98YVv4HFBfPzUPJtNgC3Dpa4VGT/z9o/z6 QoH+CfZWdnk7wZPYQBIey4y6LN94P8ChobNoMTlJkOSOykIOYhsYnb8ckS4G5Iqj+e1huTS8cPq 97iygxHCIfT+hqVWN1jNBhOFjl5ymBB+MCh/rqmWZXEcS4P8bbHzdKJm/zmL6CfE2gTfvzB1lXy 1mBYkS8FwMrnjUe8uNui1Uq8JcL51W8XKoIjfhfp33KJ1A1qrJtg9ul0ZQN+G7QVtFT+zrXZ91H OCZbeLDbf9tji8iSD+OwfLVVGJ/b4Vc64fC+aHAnsMR+EyWkwO/HF7JdHHvRsotGVWn2Xf+Hk/+ BgP0uXklyAaiGDtmnYMDTLW/47go3fnKwyrkAwThniJoPbIBBId0TYCRSmKQNPfV8pUaXlZvRQn EUYsmqeZH1s1S6O/M+gbQJKRXieFMK+7j6OaQFTlKXvtU64YO321O+EgY6jXE9vHCwSRlG9Pbkw Np7P8AL2kvfNuHPrGwJ4l2lsJaMyvw6LeBISFNL5MRB0Xbs9ZD3 X-Received: by 2002:a05:600c:138a:b0:49c:fc6e:8cba with SMTP id 5b1f17b1804b1-49cfc6e8e34mr7095385e9.30.1788500840961; Thu, 03 Sep 2026 22:47:20 -0700 (PDT) Message-ID: <5d942345-e804-400d-ad4e-e9671d8e9062@suse.com> Date: Fri, 4 Sep 2026 07:47:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/14] x86/mm: introduce populate_perdomain_mapping() To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-2-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-2-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788500841-50D3CA5B-93E4B1CA/0/0 X-purgate-type: clean X-purgate-size: 5819 On 02.09.2026 11:43, George Dunlap wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -6334,6 +6334,130 @@ int create_perdomain_mapping(struct domain *d, unsigned long va, > return rc; > } > > +/* > + * Map @nr pages, @mfn[0..nr-1], at consecutive pages from @va in v's view of > + * the per-domain area, with page-table @flags. The range must lie within a > + * single per-domain slot, and must already have been plumbed down to the L1 > + * tables by create_perdomain_mapping(): missing structure is a bug. A > + * present entry not owned by the area (no _PAGE_AVAIL0) is silently > + * replaced, as that is how callers update their mappings; a present > + * area-owned entry is freed and replaced, which constrains the calling > + * context (see the comment in the body). No TLB flushing is done: the > + * caller decides whether the old translations can still be cached > + * anywhere. > + * > + * When v's page-tables are loaded on this pCPU the L1 entries are reached > + * through the recursive linear mappings; otherwise the walk maps the > + * per-domain page-table pages transiently with IRQs off, so it needs > + * nothing from the current address space and is usable from any context -- > + * including the context switch, before the incoming vcpu's page-tables are > + * loaded. > + */ > +void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, > + const mfn_t *mfn, unsigned int nr, > + unsigned int flags) > +{ > + l1_pgentry_t *l1tab = NULL, *pl1e; > + const l3_pgentry_t *l3tab; > + const l2_pgentry_t *l2tab; > + struct domain *d = v->domain; > + unsigned long irq_flags; > + > + ASSERT(va >= PERDOMAIN_VIRT_START && > + va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); > + ASSERT(!nr || !l3_table_offset(va ^ (va + nr * PAGE_SIZE - 1))); > + /* Area-owned pages are installed by create_perdomain_mapping() only. */ > + ASSERT(!(flags & _PAGE_AVAIL0)); > + > + if ( likely(this_cpu(pgtable_vcpu) == v) ) > + { > + unsigned int i; > + > + /* > + * Fast path: v's page-tables are loaded on this pCPU, so the L1 > + * entries can be reached using the recursive linear mappings. > + */ > + pl1e = &__linear_l1_table[l1_linear_offset(va)]; > + > + for ( i = 0; i < nr; i++, pl1e++ ) > + { > + /* > + * An area-owned entry (installed by create_perdomain_mapping(), > + * marked _PAGE_AVAIL0) holds the only reference to its page, so > + * displacing it means freeing it. Nothing in this series > + * replaces area-owned backing, hence the ASSERT_UNREACHABLE(); > + * any future caller doing so must run where freeing is > + * permitted -- IRQs enabled, not in interrupt context (see > + * ASSERT_ALLOC_CONTEXT()) -- which the context switch path is > + * not. > + */ > + if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) ) > + { > + ASSERT_UNREACHABLE(); > + free_domheap_page(l1e_get_page(*pl1e)); > + } > + l1e_write(pl1e, l1e_from_mfn(mfn[i], flags)); > + } > + > + return; > + } > + > + BUG_ON(!d->arch.perdomain_l3_pg); > + > + /* > + * Slow path: walk v's per-domain page-table pages. All mappings are > + * local to this function, so disabling interrupts for the duration of > + * the walk satisfies the map_domain_page_irqoff() contract. This in > + * turn makes this function usable from the context switch path, where > + * a plain map_domain_page() could recurse into __context_switch() via > + * sync_local_execstate(). > + */ > + local_irq_save(irq_flags); > + > + l3tab = __map_domain_page_irqoff(d->arch.perdomain_l3_pg); > + > + /* > + * Missing page-table structure is a hypervisor bug: there is no safe > + * continuation, least of all from the context switch, where the next > + * descriptor fetch through an unmapped GDT slot would be fatal. > + */ > + BUG_ON(!(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT)); > + > + l2tab = map_domain_page_irqoff(l3e_get_mfn(l3tab[l3_table_offset(va)])); > + > + for ( ; nr--; va += PAGE_SIZE, mfn++ ) > + { > + if ( !l1tab || !l1_table_offset(va) ) > + { > + const l2_pgentry_t *pl2e = l2tab + l2_table_offset(va); > + > + BUG_ON(!(l2e_get_flags(*pl2e) & _PAGE_PRESENT)); > + > + unmap_domain_page_irqoff(l1tab); > + l1tab = map_domain_page_irqoff(l2e_get_mfn(*pl2e)); > + } > + > + pl1e = &l1tab[l1_table_offset(va)]; > + > + /* > + * As the fast path -- and the slow path holds IRQs off throughout, > + * so replacing area-owned backing here is never permitted. > + */ > + if ( unlikely(perdomain_l1e_needs_freeing(*pl1e)) ) > + { > + ASSERT_UNREACHABLE(); > + free_domheap_page(l1e_get_page(*pl1e)); > + } Just for the possible case of freeing here really becoming necessary: This could be deferred until ... > + l1e_write(pl1e, l1e_from_mfn(*mfn, flags)); > + } > + > + unmap_domain_page_irqoff(l1tab); > + unmap_domain_page_irqoff(l2tab); > + unmap_domain_page_irqoff(l3tab); > + > + local_irq_restore(irq_flags); ... here. Easily for the nr == 1 case (just requires a local variable to hold MFN or struct page_info *), and with a slight change to the contract with the caller (allowing mfn[] to be altered) also in the general case. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 04 05:58:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 05:58:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407853.1640670 (Exim 4.92) (envelope-from ) id 1x2MwT-00048b-Vj; Fri, 04 Sep 2026 05:58:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407853.1640670; Fri, 04 Sep 2026 05:58:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2MwT-00048U-RA; Fri, 04 Sep 2026 05:58:25 +0000 Received: by outflank-mailman (input) for mailman id 1407853; Fri, 04 Sep 2026 05:58:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2MwS-00048O-B7 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 05:58:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2MwR-00GkUB-2x for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 07:58:23 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a5df3-e002-0a2a0a5209dd-0a2a4506ca76-18 for ; Fri, 04 Sep 2026 07:58:22 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a5dfe-195a-0a2a45060019-d1558031b1ba-3 for ; Fri, 04 Sep 2026 07:58:22 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-499ae1c6471so4931735e9.3 for ; Thu, 03 Sep 2026 22:58:22 -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-49cfbdacc45sm16518645e9.11.2026.09.03.22.58.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 22:58:21 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788501502; x=1789106302; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=MN8uVxAs2vhm8m1hxerJDE9AVNv1ciMaFiYvOkc+Eqw=; b=UqC5D7bP8w+qtIElIv2oV60Ozyq6fbZxf137NdV0oWRiHIllGTxFyw2au1wB5JLJd8 c2CK8CWnpGI91WSp4j5w/EcNTD4UWiMiGMi3GfoRfR6r3PKGbVkNbkh266Rkk0RTzxTe Jm999RupZw5Vax7xrkwS6H+O3w8b+Th7LMLgIf3w53VItkatWQnicHBctrHFx9WRrHhH B+GF/CrxUK6MAbzotSl9pRwz0u7P89nCSa4awBtBQHvi9089OVfCrLeEKmn+LDLw+z0l akufHafskca9IHuy10Cwbu+7NiumC/s6EOx7+nFIe77ONob4gaK68vBG9hWUAzgLfUhZ 9WjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788501502; x=1789106302; h=content-transfer-encoding:content-type: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:content-type; bh=MN8uVxAs2vhm8m1hxerJDE9AVNv1ciMaFiYvOkc+Eqw=; b=kfmVEGP2WtRLVMNkedaKAUMpmdd+nc1cdzcBw2ux0h37DQQiK/hlHE2cLJaH1It1Oj RgtRcBzp7O0ODnWYhzbOfRRlFHsGsN3q+zA4J5sLq/1UMZJPuuVLW4Qtx+H/oQDq8yLD cLZQ/HEMbpwZq+2E53+V2/429gYUR1LLQJEae7KMZG9s54UBs1eboYmfzLn/DiqcphLT TLdANx9xxzHDZUiL1r2BaxB0tChv2DPyI7qqZq/ApshcnJSqQh80GNF1qYMs2bWABuEC 17zXookNZSq8Iq1umJ9SaMNCq00398J23PBjQGibUczNjp+SmFfqbUf4P4dzbfUkEZtl 7GsQ== X-Forwarded-Encrypted: i=1; AKwUvBzQUhTYZbsXM//lKZlDWKAhPPaesQ1Xb8Krj+yT8PMxw7A3oe9z7TBO2caMUu9qMBeW2q/MKzvOsPo=@lists.xenproject.org X-Gm-Message-State: AFuF++nYgpSJQzIezfIpIj3faL38Fj+vDGJR4Euk5wRq3AI+c1R7OTig 4r2G8IHrq0GEMFejAAGsNNokRg5USGpslDaPtStUz5H5rriu+J9O0ovLDuNEMozY4Q== X-Gm-Gg: AYBFou0DGi6t0ifaHqi6XYONyQ1+LHvBaY70EMT8Eb+gY/yNumunJHpN/O0DBveisGY lbhyAmj2PYDSgFSsyfd2d4oixoTkquz8B2SsM4NL5B66eZ1NxMEiXqMC/qYhpqJ/EvwAtc7PwLN POI0U+LsGXK7vr40HY+id6eoCGnO/mULEJUOHA059w6crJChPkqna/btqLWETS6Usm6wX6AIcTb jr/uQ0SgUDoM182k6OxMwyaZAQZEMil9WsYOlT7hq29ahgeGfINUkCguqWAYG02YAsDr1EB4+Yg qxuS16wt+q4OfmwR9k2fXxouotvXZwmns7O00EPrFyXAxljnMvWb6ywRtRqpYuMHRR7wdEUpeMM ZObFmaj6SHnatqs05APLh5yHWgTjxo20kyMCGrIOo9H+gjF3HUd9+aQWLm8E2tMnz7LfKcJQrQG FtKGAHWVbAE3cgz8dpchgDXNLWVS0SOLQYLb7VONLXOQfQgVNfA5SbnWbRafdE1yV8xuHp1m2qZ PiAzjkOU/qfF3p16zbBiIS+WyPx+RElj0cdj18lf0DWLFZbyYV4 X-Received: by 2002:a05:600c:4515:b0:49a:252d:52f5 with SMTP id 5b1f17b1804b1-49cf8241ab8mr45185865e9.11.1788501502396; Thu, 03 Sep 2026 22:58:22 -0700 (PDT) Message-ID: Date: Fri, 4 Sep 2026 07:58:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/14] x86/mm: introduce populate_perdomain_mapping() To: George Dunlap Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-2-ecc269f268b7@xenproject.org> <5071d4da-d9b1-45cd-8e9b-778df417ee7b@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 X-purgate-ID: tlsNG-16d1c6/1788501502-FE27077B-8524740A/0/0 X-purgate-type: clean X-purgate-size: 344 On 03.09.2026 23:27, George Dunlap wrote: > So I'd propose: In both fast and slow paths, replace the free with a > printk (keeping the ASSERT_UNREACHABLE), with a comment explaining why > leaking is preferable to BUG. Fine with me. With this and the l3tab[] unmapping moved earlier: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 04 06:00:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 06:00:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407863.1640677 (Exim 4.92) (envelope-from ) id 1x2MyO-0005hC-63; Fri, 04 Sep 2026 06:00:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407863.1640677; Fri, 04 Sep 2026 06:00:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2MyO-0005h5-3K; Fri, 04 Sep 2026 06:00:24 +0000 Received: by outflank-mailman (input) for mailman id 1407863; Fri, 04 Sep 2026 06:00:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2MyM-0005gz-Dg for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 06:00:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2MyL-00Gkv2-QJ for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:00:21 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a5e75-e002-0a2a0a5209dd-0a2a4502a8e6-2 for ; Fri, 04 Sep 2026 08:00:21 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a5e74-6ca4-0a2a45020019-d155802cd8e9-3 for ; Fri, 04 Sep 2026 08:00:20 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49b0d78a801so5529155e9.2 for ; Thu, 03 Sep 2026 23:00:20 -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-49cf75ce49esm77590115e9.1.2026.09.03.23.00.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 23:00:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788501620; x=1789106420; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=DXrPMhrbWpbmDOXTRXiHtULtJkGQYTDdglvtg7g8E5c=; b=Wt0Q7XAkfZKk9Tj0KjU8Ee3oHTbvl20U9YIpKTYSMNs/lurxsdttAKb2afpA+mODV3 /Ge7hw8WNZQZs+rry98suTRHTqdlubfHVjKhNsYmrn16jUJM2KpRC5v191T0urzvRTM3 Th4HYGQ/EQzfWua9fSMLWhn2MCeVHdrYSLD80HdK/JdR3EA2mrbY1QU8Dgu5uZ7Lw88F hB2H93PtrB4ziMlLvcbwlBV6QuKIuXyEaSJpv2iga37nGSvzlLoLElIT6UlW4259iu9M KcQy4mxnpZLJA1cZ/VMFkKYB2txKHN8IKWvL2TE35bJtahqzRkecA6VC9JaAPt3Ogy22 gsqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788501620; x=1789106420; h=content-transfer-encoding:content-type: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:content-type; bh=DXrPMhrbWpbmDOXTRXiHtULtJkGQYTDdglvtg7g8E5c=; b=p9dTnuUjcKJfBUqwtuMVfwwSH0I5Uft4W7SG1CZ7XtZmbRd5vfY4DaJTTawVe5pbpz FkiaZyTTinOFw02GAIeMDTxNkgFNQd9Q31Nz5b5hpEwIy94gsSIHmxdoIWeMTpZSyqRB /SPP/HcSMbPSMfGU2A9qFIuG5qVnbJ8Gv9WIBWN+mFT4MDO0eoSED7OFN71vBRSqFr5S iGUmLc8iK8WQkl5xK/mel3Kmg5/UmbPmBGmgMbKi9YV3Nk/n8eyQcjRQIvU4z18QCWLv sYRU12Gck6djJsUdxyS0dAlV9tOY4l03W1/zs0Hu0BzAXY4oKieFTJjT5OOR2oLIqVR0 YNPg== X-Forwarded-Encrypted: i=1; AKwUvBwmB4EzFKwEaNt7RXCif8AnOs6AUCtZVdwDc6G8somJMFwDL9ZS9OabW/eaHBfSQRS13a87Ur1pu6A=@lists.xenproject.org X-Gm-Message-State: AFuF++lOXf29eQPiOlJ4lve4uhUHxxpk+S6JjBhfUU0bktzO18n2YMwu UEkkp9n9NThnmZVuU2jC0q8ryNmTBk/+rjOyWTOQ6CkLJU0pY7WbAFSYF7AZv9dn6A== X-Gm-Gg: AYBFou0QoBb/nmeDxB5f1JLCV7V/EQVYCX0cJ5SJxVNLL48BEj3hCkFkfqTmqb9ydiH NsURVbNq96iH7BizHUMDoazG+C+U3vS/0kRSS5lgW2yBfhK1kMbQhrWy3Gc/1FWnuUxiI0hF1io nuj4ltcC6WnTtQofkw4nv4Slo7Pb7Qrlft+VzfUiLL7noimgL9sdnZPxIow9DcBGFGZymqp5RX5 cONAzNfEf+SZwfe6CjGkPebhJJ2gKrLP0brpJFzCef84cKuCDWh1r6FCnr4Pv1pzXOd0Ft6aZJo JMXjdYtZLIuQdCj+eMOPtj3PQKYV0m9bo8NzDJXUDj9fZQGQx3dvmo9uAz20Je8+wk07JaQ5LYm BfCFnQKtEpzhkY3MmZtxeQQgmKcbqzs56beBonGVYykAAu68nyRvPGiwfJTaIfMvuhAk2K3VOco RNMszShb6oMmMAaqHThPcgfHqVE8YQA++98yE4EElRoMnkOK5N13FMMVesIOC2h04eGjQa630zY kw9NTczxTy8m2H3dPwAqfrMEp8Wk69LTXUFGMzJljqoJ1vGI2a8 X-Received: by 2002:a05:600c:3ba5:b0:49c:dada:f581 with SMTP id 5b1f17b1804b1-49cf7f39c8bmr44433615e9.0.1788501620048; Thu, 03 Sep 2026 23:00:20 -0700 (PDT) Message-ID: <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> Date: Fri, 4 Sep 2026 08:00:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, Juergen Gross References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@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: 8bit X-purgate-ID: tlsNG-720697/1788501620-F20A82AC-1F735644/0/0 X-purgate-type: clean X-purgate-size: 3670 On 04.09.2026 00:35, George Dunlap wrote: > On Thu, Sep 3, 2026 at 5:11 PM Jan Beulich wrote: >> >> On 02.09.2026 11:43, George Dunlap wrote: >>> From: Roger Pau Monné >>> >>> Currently, update_xen_slot_in_full_gdt() uses the stashed direct-map >>> pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vcpu's >>> page tables with Xen's GDT, by writing a stashed per-cpu copy of a >>> pre-baked L1 entry (either 64-bit or compat version). >>> >>> Switch this to using populate_perdomain_mapping(), which doesn't rely >>> on the stashed address of the l1 page in the direct map. Rather than >>> also stashing a pre-baked value for the payload, compute the mfn from >>> the per-cpu GDT pointer at use: the conversion is a handful of cycles >>> on a path costing thousands, and computing at use removes the >>> parallel {,compat_}gdt_l1e bookkeeping along with its boot-ordering >>> constraint (the cached value could only be generated after Xen's >>> physical relocation, and had to be in place before the first context >>> switch; a use-time lookup is correct by construction). The flags on >>> the final mapping are identical. >>> >>> Signed-off-by: Roger Pau Monné >>> Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 >>> Signed-off-by: George Dunlap >>> --- >>> Changes in v2: >>> - Drop the {,compat_}gdt_mfn caching entirely (suggested by Andrew >>> Cooper): compute virt_to_mfn() from the per-cpu GDT pointer at use. >>> The PDX lookup behind it measures ~5-10 cycles warm against a >>> ~1,500-cycle context switch, and this removes the double >>> bookkeeping and the after-relocation caching constraint. The >>> cached-MFN assertion goes with the cache: a use-time computation >>> from a live pointer needs no staleness check. >> >> This looks to contradict what 564d261687c0 ("x86/ctxt-switch: Document >> and improve GDT handling") used as justification to put in place the >> caching. Also Cc-ing Jürgen, who also was involved there, for possible >> further insight. >> >> Functionally the change looks okay to me, but the above will need >> sorting, at the very least by specifically discussing why effectively >> undoing that earlier change is okay. > > So looking back at the thread, Jürgen measured a 14% improvement for > something that might be described as a microbenchmark before and after > the patch (a benchmark purposely trying to set up an unusual scenario > to maximize the effect of context switch overhead, not one to > represent a typical workflow). But are the numbers really plausible? > Even at an implausible 100k switches/s across the box, saving 100 > cycles per switch is about 0.04% of eight 3 GHz cores. > > At any rate, we're already adding several map/unmap operations, and > about to add several more. Keeping the PTE caching would require > adding a separate path that can write just PTEs, which then will > potentially further complication future paths where we need to make > sure we handle both domain-wide perdomain areas and per-vcpu areas. > If it were easy I would already have been keeping it. > > I'd be inclined to say: Since we're going to be adding more > populate_perdomain_mapping() calls anyway, let's do it the simple > correct way first; and then explore the idea of stashing mfns of > frequently-mapped L1s (rather than having to walk L3 -> L2 -> L1); and > at that time look into stashing baked l1es to avoid conversions. Perhaps; I'd like to have Jürgen's and/or Andrew's input here, though. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 04 06:54:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 06:54:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407889.1640687 (Exim 4.92) (envelope-from ) id 1x2NoW-0004eS-0j; Fri, 04 Sep 2026 06:54:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407889.1640687; Fri, 04 Sep 2026 06:54:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2NoV-0004eE-T2; Fri, 04 Sep 2026 06:54:15 +0000 Received: by outflank-mailman (input) for mailman id 1407889; Fri, 04 Sep 2026 06:54:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2NoT-0004e6-UX for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 06:54:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2NoT-00HCA8-BC for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:54:13 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a6af5-2eae-0a2a0a5409dd-0a2a4509e4a6-32 for ; Fri, 04 Sep 2026 08:54:13 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a6b14-be1a-0a2a45090019-d155dd34c11a-3 for ; Fri, 04 Sep 2026 08:54:13 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-47fe89fb333so375971f8f.3 for ; Thu, 03 Sep 2026 23:54:13 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885b405fsm4051633f8f.28.2026.09.03.23.54.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Sep 2026 23:54:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788504852; x=1789109652; darn=lists.xenproject.org; h=content-type: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:content-type; bh=JsNsCWHJbO8Mm+cYY3Miajoe3vfNXIcRTok2WECHH1o=; b=P/FOuo/vPkBrLfw13+hujzys9O2unj7rw9iuRK2X+hvmRFiiYU11mGJT4VrYm1wzW/ msEXY1qesVRDK2oX3faXRK7wBKaK10o17G/A6CLQKT53kCI+fC3EHo/kAUuaAHFGViEx fb3vGx0AAZ2X6YtAIqF3zvATXIaCy/Fc1DCnYqNMTeos+UmBlxLjYnTIO6OKZi5u40Mf jl06EmWyIeUYrdL3VbiXBG8UhQWdeK4AODXJXHveoa4Fif41KfjAk75VQQm7lrR+xAbl /rXiuIawhscoyNm5S/L7kwgLD2lwGI6lv0baBHmOT1diwJvAN5bhHOuT24yScGKrwEM+ EqMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788504852; x=1789109652; h=content-type: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 :content-type; bh=JsNsCWHJbO8Mm+cYY3Miajoe3vfNXIcRTok2WECHH1o=; b=dTvfavKIukja7c2gJoAkGvq+mAxIKq3aRI+iP4+fFnyzqSGjXEQbRT28Y7qkFaB6wy 9AoO78c4vSm8o3BWGfLTiSxemWxXhnR7CbYATrVV+mnRZ2TufD5axh74Ti5Cgenlt7EP U6GyMsdV/okdTU9Cfj0YXcnoahOjVpKoE/fKrjl4GcyIatd8dEd8SnFJENIvqWYP+ojb 8uAsPyV7xVqe0BpnZJgy/10x2iKI/FVPU/RIzeF1nHH/st+X+RP5WFeBOrdQOmrhA6Xf U3Xf8dQwDwgpq0ArOaTREOMGAIyn2PX3DDmsNGjiu1/UhVfNofI2Ly01cQekXNvuwvGs +lyg== X-Forwarded-Encrypted: i=1; AKwUvByb0IkeGHGW6FOAC6G0VLGQ2Ce6SQGWoQWRLLLNsHurAlAwXYpplWgsr9JXiSfnZxnaEpqOJHj1ac0=@lists.xenproject.org X-Gm-Message-State: AFuF++kfOVUscLUFCVqFSU9X/RQT1ca3IZQujFyIFkugjiWx3oF65P2n W/PK/Q6DOxQtuKLimmY+HBFjAv6dDWjOJiMq10kFCF8rN6G0fjJB30imUjtv5GyjKE8= X-Gm-Gg: AYBFou0s8PE7IgYUQdvMHL25HammPBhDJJcPCIb84RtlCkyMGul08EAXo7hTw92qxiP DXaqYJfCKyxSpHaSuagPBsrXaEgtSeETd1ZgLyR6Zt7M9DCo1Hh30O6ultouZKOdRSE4K+CXveL z73rCbv7gvj5N6NltLOhFXqYW1iqteWeUBAAcilMtT9M0cmm6b2L3pK6ouyIZEuNehM8lrHlrd0 Bt4yhdzpO8iWJGI4gcqwJgzA2GVGgERXLGp8aSgwf56Qht+MZs9HWrCQdy8usoyUzm8dNRSBOM1 YSL6q3f2s989cPMl1e5NMMm599eVW0c7oj0zQq/QD5iNfOOwCd2dIxvmn4UFGOE1DcfYBzpBdmX /D7NYepF+OzLKRjM3X92M3xAQGM+dQOFJPGyeGMiSligkwBqABjaUWqHeBWNz2DSpgu7LEX8es/ nkp5EeNCnF0q92/yJ5xtaMvn/GDwm37z6e26oDDoDmCTX8Wd0TsV+EPIDpcumUrt2wKhqbzy/lq Of76eVb5T2jaQzGUR/bYO3cDTp3QM06wFSsAgC1fuxASQhqkiDQ4vACQshUrYmtp2kvVW4cCvnr JEUrj51bKVJbrg== X-Received: by 2002:a5d:5f47:0:b0:484:3a16:cc58 with SMTP id ffacd0b85a97d-4858707f11fmr5051536f8f.2.1788504852398; Thu, 03 Sep 2026 23:54:12 -0700 (PDT) Message-ID: <050f44ec-47e5-4754-b73b-1173458736b0@suse.com> Date: Fri, 4 Sep 2026 08:54:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: Jan Beulich , George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------c8xz0CP6dvxU0eGMx6iKhJMi" X-purgate-ID: tlsNG-bad1c0/1788504853-FC212034-F1426F9A/0/0 X-purgate-type: clean X-purgate-size: 13955 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------c8xz0CP6dvxU0eGMx6iKhJMi Content-Type: multipart/mixed; boundary="------------qRpM8NKCVLpROhh30HFCOzTk"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich , George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Message-ID: <050f44ec-47e5-4754-b73b-1173458736b0@suse.com> Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> In-Reply-To: <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------qRpM8NKCVLpROhh30HFCOzTk Content-Type: multipart/mixed; boundary="------------5ayzHQqzWdEiCqQXkI0hB6w2" --------------5ayzHQqzWdEiCqQXkI0hB6w2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDQuMDkuMjYgMDg6MDAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNC4wOS4yMDI2 IDAwOjM1LCBHZW9yZ2UgRHVubGFwIHdyb3RlOg0KPj4gT24gVGh1LCBTZXAgMywgMjAyNiBh dCA1OjEx4oCvUE0gSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPiB3cm90ZToNCj4+ Pg0KPj4+IE9uIDAyLjA5LjIwMjYgMTE6NDMsIEdlb3JnZSBEdW5sYXAgd3JvdGU6DQo+Pj4+ IEZyb206IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPj4+Pg0K Pj4+PiBDdXJyZW50bHksIHVwZGF0ZV94ZW5fc2xvdF9pbl9mdWxsX2dkdCgpIHVzZXMgdGhl IHN0YXNoZWQgZGlyZWN0LW1hcA0KPj4+PiBwb2ludGVyIGluIGQtPmFyY2gucHYuZ2R0X2xk dF9sMXRhYiB0byB1cGRhdGUgdGhlIGluY29taW5nIHZjcHUncw0KPj4+PiBwYWdlIHRhYmxl cyB3aXRoIFhlbidzIEdEVCwgYnkgd3JpdGluZyBhIHN0YXNoZWQgcGVyLWNwdSBjb3B5IG9m IGENCj4+Pj4gcHJlLWJha2VkIEwxIGVudHJ5IChlaXRoZXIgNjQtYml0IG9yIGNvbXBhdCB2 ZXJzaW9uKS4NCj4+Pj4NCj4+Pj4gU3dpdGNoIHRoaXMgdG8gdXNpbmcgcG9wdWxhdGVfcGVy ZG9tYWluX21hcHBpbmcoKSwgd2hpY2ggZG9lc24ndCByZWx5DQo+Pj4+IG9uIHRoZSBzdGFz aGVkIGFkZHJlc3Mgb2YgdGhlIGwxIHBhZ2UgaW4gdGhlIGRpcmVjdCBtYXAuICBSYXRoZXIg dGhhbg0KPj4+PiBhbHNvIHN0YXNoaW5nIGEgcHJlLWJha2VkIHZhbHVlIGZvciB0aGUgcGF5 bG9hZCwgY29tcHV0ZSB0aGUgbWZuIGZyb20NCj4+Pj4gdGhlIHBlci1jcHUgR0RUIHBvaW50 ZXIgYXQgdXNlOiB0aGUgY29udmVyc2lvbiBpcyBhIGhhbmRmdWwgb2YgY3ljbGVzDQo+Pj4+ IG9uIGEgcGF0aCBjb3N0aW5nIHRob3VzYW5kcywgYW5kIGNvbXB1dGluZyBhdCB1c2UgcmVt b3ZlcyB0aGUNCj4+Pj4gcGFyYWxsZWwgeyxjb21wYXRffWdkdF9sMWUgYm9va2tlZXBpbmcg YWxvbmcgd2l0aCBpdHMgYm9vdC1vcmRlcmluZw0KPj4+PiBjb25zdHJhaW50ICh0aGUgY2Fj aGVkIHZhbHVlIGNvdWxkIG9ubHkgYmUgZ2VuZXJhdGVkIGFmdGVyIFhlbidzDQo+Pj4+IHBo eXNpY2FsIHJlbG9jYXRpb24sIGFuZCBoYWQgdG8gYmUgaW4gcGxhY2UgYmVmb3JlIHRoZSBm aXJzdCBjb250ZXh0DQo+Pj4+IHN3aXRjaDsgYSB1c2UtdGltZSBsb29rdXAgaXMgY29ycmVj dCBieSBjb25zdHJ1Y3Rpb24pLiAgVGhlIGZsYWdzIG9uDQo+Pj4+IHRoZSBmaW5hbCBtYXBw aW5nIGFyZSBpZGVudGljYWwuDQo+Pj4+DQo+Pj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBh dSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPj4+PiBBc3Npc3RlZC1ieTogQ2xh dWRlIENvZGU6Y2xhdWRlLWZhYmxlLTUsIENsYXVkZSBDb2RlOmNsYXVkZS1vcHVzLTQtOA0K Pj4+PiBTaWduZWQtb2ZmLWJ5OiBHZW9yZ2UgRHVubGFwIDxnd2RAeGVucHJvamVjdC5vcmc+ DQo+Pj4+IC0tLQ0KPj4+PiBDaGFuZ2VzIGluIHYyOg0KPj4+PiAtIERyb3AgdGhlIHssY29t cGF0X31nZHRfbWZuIGNhY2hpbmcgZW50aXJlbHkgKHN1Z2dlc3RlZCBieSBBbmRyZXcNCj4+ Pj4gICAgIENvb3Blcik6IGNvbXB1dGUgdmlydF90b19tZm4oKSBmcm9tIHRoZSBwZXItY3B1 IEdEVCBwb2ludGVyIGF0IHVzZS4NCj4+Pj4gICAgIFRoZSBQRFggbG9va3VwIGJlaGluZCBp dCBtZWFzdXJlcyB+NS0xMCBjeWNsZXMgd2FybSBhZ2FpbnN0IGENCj4+Pj4gICAgIH4xLDUw MC1jeWNsZSBjb250ZXh0IHN3aXRjaCwgYW5kIHRoaXMgcmVtb3ZlcyB0aGUgZG91YmxlDQo+ Pj4+ICAgICBib29ra2VlcGluZyBhbmQgdGhlIGFmdGVyLXJlbG9jYXRpb24gY2FjaGluZyBj b25zdHJhaW50LiAgVGhlDQo+Pj4+ICAgICBjYWNoZWQtTUZOIGFzc2VydGlvbiBnb2VzIHdp dGggdGhlIGNhY2hlOiBhIHVzZS10aW1lIGNvbXB1dGF0aW9uDQo+Pj4+ICAgICBmcm9tIGEg bGl2ZSBwb2ludGVyIG5lZWRzIG5vIHN0YWxlbmVzcyBjaGVjay4NCj4+Pg0KPj4+IFRoaXMg bG9va3MgdG8gY29udHJhZGljdCB3aGF0IDU2NGQyNjE2ODdjMCAoIng4Ni9jdHh0LXN3aXRj aDogRG9jdW1lbnQNCj4+PiBhbmQgaW1wcm92ZSBHRFQgaGFuZGxpbmciKSB1c2VkIGFzIGp1 c3RpZmljYXRpb24gdG8gcHV0IGluIHBsYWNlIHRoZQ0KPj4+IGNhY2hpbmcuIEFsc28gQ2Mt aW5nIErDvHJnZW4sIHdobyBhbHNvIHdhcyBpbnZvbHZlZCB0aGVyZSwgZm9yIHBvc3NpYmxl DQo+Pj4gZnVydGhlciBpbnNpZ2h0Lg0KPj4+DQo+Pj4gRnVuY3Rpb25hbGx5IHRoZSBjaGFu Z2UgbG9va3Mgb2theSB0byBtZSwgYnV0IHRoZSBhYm92ZSB3aWxsIG5lZWQNCj4+PiBzb3J0 aW5nLCBhdCB0aGUgdmVyeSBsZWFzdCBieSBzcGVjaWZpY2FsbHkgZGlzY3Vzc2luZyB3aHkg ZWZmZWN0aXZlbHkNCj4+PiB1bmRvaW5nIHRoYXQgZWFybGllciBjaGFuZ2UgaXMgb2theS4N Cj4+DQo+PiBTbyBsb29raW5nIGJhY2sgYXQgdGhlIHRocmVhZCwgSsO8cmdlbiBtZWFzdXJl ZCBhIDE0JSBpbXByb3ZlbWVudCBmb3INCj4+IHNvbWV0aGluZyB0aGF0IG1pZ2h0IGJlIGRl c2NyaWJlZCBhcyBhIG1pY3JvYmVuY2htYXJrIGJlZm9yZSBhbmQgYWZ0ZXINCj4+IHRoZSBw YXRjaCAoYSBiZW5jaG1hcmsgcHVycG9zZWx5IHRyeWluZyB0byBzZXQgdXAgYW4gdW51c3Vh bCBzY2VuYXJpbw0KPj4gdG8gbWF4aW1pemUgdGhlIGVmZmVjdCBvZiBjb250ZXh0IHN3aXRj aCBvdmVyaGVhZCwgbm90IG9uZSB0bw0KPj4gcmVwcmVzZW50IGEgdHlwaWNhbCB3b3JrZmxv dykuICBCdXQgYXJlIHRoZSBudW1iZXJzIHJlYWxseSBwbGF1c2libGU/DQo+PiBFdmVuIGF0 IGFuIGltcGxhdXNpYmxlIDEwMGsgc3dpdGNoZXMvcyBhY3Jvc3MgdGhlIGJveCwgc2F2aW5n IDEwMA0KPj4gY3ljbGVzIHBlciBzd2l0Y2ggaXMgYWJvdXQgMC4wNCUgb2YgZWlnaHQgMyBH SHogY29yZXMuDQo+Pg0KPj4gQXQgYW55IHJhdGUsIHdlJ3JlIGFscmVhZHkgYWRkaW5nIHNl dmVyYWwgbWFwL3VubWFwIG9wZXJhdGlvbnMsIGFuZA0KPj4gYWJvdXQgdG8gYWRkIHNldmVy YWwgbW9yZS4gIEtlZXBpbmcgdGhlIFBURSBjYWNoaW5nIHdvdWxkIHJlcXVpcmUNCj4+IGFk ZGluZyBhIHNlcGFyYXRlIHBhdGggdGhhdCBjYW4gd3JpdGUganVzdCBQVEVzLCB3aGljaCB0 aGVuIHdpbGwNCj4+IHBvdGVudGlhbGx5IGZ1cnRoZXIgY29tcGxpY2F0aW9uIGZ1dHVyZSBw YXRocyB3aGVyZSB3ZSBuZWVkIHRvIG1ha2UNCj4+IHN1cmUgd2UgaGFuZGxlIGJvdGggZG9t YWluLXdpZGUgcGVyZG9tYWluIGFyZWFzIGFuZCBwZXItdmNwdSBhcmVhcy4NCj4+IElmIGl0 IHdlcmUgZWFzeSBJIHdvdWxkIGFscmVhZHkgaGF2ZSBiZWVuIGtlZXBpbmcgaXQuDQo+Pg0K Pj4gSSdkIGJlIGluY2xpbmVkIHRvIHNheTogU2luY2Ugd2UncmUgZ29pbmcgdG8gYmUgYWRk aW5nIG1vcmUNCj4+IHBvcHVsYXRlX3BlcmRvbWFpbl9tYXBwaW5nKCkgY2FsbHMgYW55d2F5 LCBsZXQncyBkbyBpdCB0aGUgc2ltcGxlDQo+PiBjb3JyZWN0IHdheSBmaXJzdDsgYW5kIHRo ZW4gZXhwbG9yZSB0aGUgaWRlYSBvZiBzdGFzaGluZyBtZm5zIG9mDQo+PiBmcmVxdWVudGx5 LW1hcHBlZCBMMXMgKHJhdGhlciB0aGFuIGhhdmluZyB0byB3YWxrIEwzIC0+IEwyIC0+IEwx KTsgYW5kDQo+PiBhdCB0aGF0IHRpbWUgbG9vayBpbnRvIHN0YXNoaW5nIGJha2VkIGwxZXMg dG8gYXZvaWQgY29udmVyc2lvbnMuDQo+IA0KPiBQZXJoYXBzOyBJJ2QgbGlrZSB0byBoYXZl IErDvHJnZW4ncyBhbmQvb3IgQW5kcmV3J3MgaW5wdXQgaGVyZSwgdGhvdWdoLg0KDQpBdCB0 aGF0IHRpbWUgSSBpbXBsZW1lbnRlZCBjb3JlIHNjaGVkdWxpbmcgaW4gWGVuLiBJIG5vdGlj ZWQgdGhhdCB2ZXJ5DQpzdWJ0bGUgY2hhbmdlcyBpbiB0aGUgY29udGV4dCBzd2l0Y2ggcGF0 aCBjb3VsZCByZXN1bHQgaW4gdW5leHBlY3RlZCBsYXJnZQ0KcGVyZm9ybWFuY2UgZGlmZmVy ZW5jZXMuIEFzIEkgaGFkIHRoZSBwZXJmb3JtYW5jZSB0ZXN0IGZvciBteSBwdXJwb3NlDQph bHJlYWR5IHNldCB1cCwgSSB1c2VkIGl0IGZvciBBbmRyZXcncyBwYXRjaCAod2hpY2ggd2Fz IGEgcmVzdWx0IG9mIG15DQpjb250ZXh0IHN3aXRjaCBwYXRoIHBlcmZvcm1hbmNlIGZpbmRp bmdzKSBhbmQgcmVhbGx5IGRpZCBtZWFzdXJlIHRoZQ0KaW1wcmVzc2l2ZSBlZmZlY3Qgb2Yg aXQuDQoNCk5vdGUgdGhhdCB5b3UgY2FuJ3Qgb25seSBjb3VudCBpbnN0cnVjdGlvbnMsIG9m dGVuIGNhY2hlIGVmZmVjdHMgYW5kDQpicmFuY2ggcHJlZGljdGlvbnMgYXJlIGRvbWluYXRp bmcgdGhlIHBlcmZvcm1hbmNlLg0KDQoNCkp1ZXJnZW4NCg== --------------5ayzHQqzWdEiCqQXkI0hB6w2 Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------5ayzHQqzWdEiCqQXkI0hB6w2-- --------------qRpM8NKCVLpROhh30HFCOzTk-- --------------c8xz0CP6dvxU0eGMx6iKhJMi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqaaxMFAwAAAAAACgkQsN6d1ii/Ey92 mwf/bLCwEUDyWwT7cGDfnkrDVy1UC5bBPNToUf2PltO48pdZNfqlgXEnLY8gGzW7SYTrOPEVCrDH 5jw4B7xB0Wq7ZbfhiVMGx2rTUYSNGPXXS7hNSGj5Df5ffdGGMds6a48Ot0FXkkokJwv43c9aS7Ap xxG0uKX01hGr/GxNLPgV0yd2ZbMFOgf9Ba9cQGXeCprzSZu8ZUCfcfnTW/pi9zqJA3yClI0MnayM TXAh3oOD2JdniXwNVajIYL64MOeEjFv0MaNxyUZEtBWNuWI5y435v/AA/TqKjoE8wE7/PiDz4nhC oVmqnU7HWcQ1pSR/o9YICJVjh1xt6JLzzq0wAhJBIw== =NUt+ -----END PGP SIGNATURE----- --------------c8xz0CP6dvxU0eGMx6iKhJMi-- From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:07:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:07:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407940.1640696 (Exim 4.92) (envelope-from ) id 1x2Ox1-0006cb-Ct; Fri, 04 Sep 2026 08:07:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407940.1640696; Fri, 04 Sep 2026 08:07:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Ox1-0006cU-9z; Fri, 04 Sep 2026 08:07:07 +0000 Received: by outflank-mailman (input) for mailman id 1407940; Fri, 04 Sep 2026 08:07:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Ox0-0006cM-2J for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:07:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Owz-0065iV-F1 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:07:05 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a7c1d-e002-0a2a0a5209dd-0a2a4502dcf6-40 for ; Fri, 04 Sep 2026 10:07:04 +0200 Received: from [18.217.159.240] (helo=ghoul.relay-egress.a.mail.umich.edu) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a7c26-6ca4-0a2a45020019-12d99ff09478-3 for ; Fri, 04 Sep 2026 10:07:02 +0200 Received: from top-brounie.authn-relay.a.mail.umich.edu (ip-10-0-74-245.us-east-2.compute.internal [10.0.74.245]) by ghoul.relay-egress.a.mail.umich.edu with ESMTPS id 6A9A7C25.2762C025.198CDE89.30540; Fri, 04 Sep 2026 04:07:01 -0400 Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by top-brounie.authn-relay.a.mail.umich.edu with ESMTPSA id 6A9A7C24.31D04528.71D4968.1389580; Fri, 04 Sep 2026 04:07:01 -0400 Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-39c7ed5410bso5535231fa.0 for ; Fri, 04 Sep 2026 01:07:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-2 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1788509221; bh=uOLmBmalDx11mFYzo84GxFwO0G+W0jshabbbDFOR/I4=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=T5CHeY51BA5T4/aLeeBcRY2HUf3IX2PeKCkXWTk7GLgE/RFKS4HgVq0UOLToWOJwe RFIfJqOhjO/scDsWqB85hj7iBQVsGk5ClbiKrDtl+nnLajUbJRaceVR/knyuDezsAa VZoGrL/qNrHOIaR3BtOE/XnPuEFz+Lii+O0+Wguht3SO5e9HmD/gZriOTPek0d+QpQ TD7THwurCb8X//1DpJhPWBVDBOe4psgkMNbIoBvaFzuyGEPQeZJwraZjSd77JV5u5S j5q7JL4Hn4JnKaGkx1GyoytZEV/ixUh0LMF33AT0AsjLGkcYACSZGBlJf/Yp/0zCku X7T4hYqjjpwoA== Authentication-Results: top-brounie.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.208.171 (mail-lj1-f171.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvByCQNECovKPtlexaXPpgf+nwc3qKgLFwPBWQuAqpkCOaZGBj80MHdHVomtZdwk8KrfCHI1f3AN7bqQ=@lists.xenproject.org X-Gm-Message-State: AFuF++m+IVE5ow+ydGJkuC6KJ4qbcgYebCWC6YpPzk9nsVBz52L1hZNN szWIOlk8vP5XSzKMZ0IF6RRy3C5/5xd9E0+rBsYnefJMr1U/6cUYkbFDIsb0hSvdZ84Lva/XcDM smVjTZD2QLEiQVSSmWNa57SLOyRtxVv0= X-Received: by 2002:a05:651c:15c1:20b0:3a3:476:2e37 with SMTP id 38308e7fff4ca-3a371b2d735mr3598501fa.6.1788509218697; Fri, 04 Sep 2026 01:06:58 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> <050f44ec-47e5-4754-b73b-1173458736b0@suse.com> In-Reply-To: <050f44ec-47e5-4754-b73b-1173458736b0@suse.com> From: George Dunlap Date: Fri, 4 Sep 2026 09:06:45 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1VO9I1SRc0pAKiewtIDJfNIVNMGpWUrRbmHBGtw0t5nCfdsx0gazpaPtLw Message-ID: Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1788509224-F2CB22AC-632F8039/0/0 X-purgate-type: clean X-purgate-size: 6049 On Fri, Sep 4, 2026 at 7:54=E2=80=AFAM J=C3=BCrgen Gro=C3=9F wrote: > > On 04.09.26 08:00, Jan Beulich wrote: > > On 04.09.2026 00:35, George Dunlap wrote: > >> On Thu, Sep 3, 2026 at 5:11=E2=80=AFPM Jan Beulich = wrote: > >>> > >>> On 02.09.2026 11:43, George Dunlap wrote: > >>>> From: Roger Pau Monn=C3=A9 > >>>> > >>>> Currently, update_xen_slot_in_full_gdt() uses the stashed direct-map > >>>> pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vcpu's > >>>> page tables with Xen's GDT, by writing a stashed per-cpu copy of a > >>>> pre-baked L1 entry (either 64-bit or compat version). > >>>> > >>>> Switch this to using populate_perdomain_mapping(), which doesn't rel= y > >>>> on the stashed address of the l1 page in the direct map. Rather tha= n > >>>> also stashing a pre-baked value for the payload, compute the mfn fro= m > >>>> the per-cpu GDT pointer at use: the conversion is a handful of cycle= s > >>>> on a path costing thousands, and computing at use removes the > >>>> parallel {,compat_}gdt_l1e bookkeeping along with its boot-ordering > >>>> constraint (the cached value could only be generated after Xen's > >>>> physical relocation, and had to be in place before the first context > >>>> switch; a use-time lookup is correct by construction). The flags on > >>>> the final mapping are identical. > >>>> > >>>> Signed-off-by: Roger Pau Monn=C3=A9 > >>>> Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 > >>>> Signed-off-by: George Dunlap > >>>> --- > >>>> Changes in v2: > >>>> - Drop the {,compat_}gdt_mfn caching entirely (suggested by Andrew > >>>> Cooper): compute virt_to_mfn() from the per-cpu GDT pointer at u= se. > >>>> The PDX lookup behind it measures ~5-10 cycles warm against a > >>>> ~1,500-cycle context switch, and this removes the double > >>>> bookkeeping and the after-relocation caching constraint. The > >>>> cached-MFN assertion goes with the cache: a use-time computation > >>>> from a live pointer needs no staleness check. > >>> > >>> This looks to contradict what 564d261687c0 ("x86/ctxt-switch: Documen= t > >>> and improve GDT handling") used as justification to put in place the > >>> caching. Also Cc-ing J=C3=BCrgen, who also was involved there, for po= ssible > >>> further insight. > >>> > >>> Functionally the change looks okay to me, but the above will need > >>> sorting, at the very least by specifically discussing why effectively > >>> undoing that earlier change is okay. > >> > >> So looking back at the thread, J=C3=BCrgen measured a 14% improvement = for > >> something that might be described as a microbenchmark before and after > >> the patch (a benchmark purposely trying to set up an unusual scenario > >> to maximize the effect of context switch overhead, not one to > >> represent a typical workflow). But are the numbers really plausible? > >> Even at an implausible 100k switches/s across the box, saving 100 > >> cycles per switch is about 0.04% of eight 3 GHz cores. > >> > >> At any rate, we're already adding several map/unmap operations, and > >> about to add several more. Keeping the PTE caching would require > >> adding a separate path that can write just PTEs, which then will > >> potentially further complication future paths where we need to make > >> sure we handle both domain-wide perdomain areas and per-vcpu areas. > >> If it were easy I would already have been keeping it. > >> > >> I'd be inclined to say: Since we're going to be adding more > >> populate_perdomain_mapping() calls anyway, let's do it the simple > >> correct way first; and then explore the idea of stashing mfns of > >> frequently-mapped L1s (rather than having to walk L3 -> L2 -> L1); and > >> at that time look into stashing baked l1es to avoid conversions. > > > > Perhaps; I'd like to have J=C3=BCrgen's and/or Andrew's input here, tho= ugh. > > At that time I implemented core scheduling in Xen. I noticed that very > subtle changes in the context switch path could result in unexpected larg= e > performance differences. As I had the performance test for my purpose > already set up, I used it for Andrew's patch (which was a result of my > context switch path performance findings) and really did measure the > impressive effect of it. > > Note that you can't only count instructions, often cache effects and > branch predictions are dominating the performance. Right, but: 1. That's going to be very much hardware- and workload- dependent. Even on the same hardware, if you'd made a slight change in the workload, you might have seen a very different result; and on different hardware you're going to see something different again 2. As I said, we're now adding two extra map / unmaps, which is going to perturb everything again. If anything, your argument says we should wait until we've stopped modifying the context switch path (which won't happen until patch 49 at least, guessing from the patch titles), and then measure things again to see what's actually slow. I'm sorry Jan, your position here is really inconsistent: You wave away a partial pagetable walk with three map/unmap operations on the context switch path as something we'll have to do in the interim, and can optimize later, but are now threatening to make me add in special-case codepaths and run tests to save a few memory reads and shifts. I could put back the mfn caching that was present in v1 of the series (which Andy said was probably not sufficient, on balance, to make the duplication involved worth it). Even that I think isn't really sensible, but it's not too difficult to do. To isolate the PTE caching effect I'd have to write an entire duplicate codepath anyway, and then try to duplicate J=C3=BCrgen's test. I don't think that's really a reasonable ask at this point in the series. -George From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:09:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:09:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407952.1640706 (Exim 4.92) (envelope-from ) id 1x2Oz8-00076l-Q4; Fri, 04 Sep 2026 08:09:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407952.1640706; Fri, 04 Sep 2026 08:09:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Oz8-00076e-M2; Fri, 04 Sep 2026 08:09:18 +0000 Received: by outflank-mailman (input) for mailman id 1407952; Fri, 04 Sep 2026 08:09:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Oz7-00076V-91 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:09:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Oz6-00HSXd-M0 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:09:16 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a7c9e-2eae-0a2a0a5409dd-0a2a4503bbc6-38 for ; Fri, 04 Sep 2026 10:09:16 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a7ca9-fae8-0a2a45030019-b9ff1c229b93-3 for ; Fri, 04 Sep 2026 10:09:14 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06b76f0aa000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 08:09:12 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 0DBF483FC0; Fri, 4 Sep 2026 10:09:11 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=jKRKce0KmhEE7sBIsGCdl1IED/VNP6GSP40lFG3f/lw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=ZicUvekmoiwaVfhXs4yj2clSN5/zlHS4KW8jAsqriKaAro4FcarMd5XJfFj8bNqOxplCbDRAy VoKUo5GeNkJI1gLebGv8xK4sohJweHpwgiYXLdvDOKlIceL9D54z5verrdCRAdpABP7dBiQ0gUj sjVZwKgKzWr4S0UfNOhQcw5WGsB8r3oPVLDVXRKJjdSdvM46HYrDN+1AFPVhdDJfFbhEonmxTOV i/9YDglNjBYbI9X93SrelXrd39eEKmoUy74/mKvDrxY2VgQ4bGm298isRPqHOlZxGWCnk0s4ub4 wD5JjXGyvaH5x0ZqotX6VWELHtPWP7D8rQBTN0uQn7/Q== X-Zone-Loop: b4b217ff4d28e4cd900785f4e8b765abc86099ff08e6 x-campaign-type: default x-transaction-id: e66fff89-107a-4b19-b3a7-9f65906298cb x-swg-uid: 01-3f1b8d54-ee53-4252-81a4-e9700ea89848 X-Mailer: Sweego Message-ID: <1788509352.8631fc262581453bbf619ec5b2062170.1a06b76f0aa000c4f3@vates.tech> x-swg-bid: 1788509352.8631fc262581453bbf619ec5b2062170.1a06b76f0aa000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 4 Sep 2026 10:09:10 +0200 From: Anthony PERARD To: Jan Beulich Cc: Julian Vetter , Andrew Cooper , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v6 0/3] Support multiple ioreq pages References: <20260420093820.825969-1-julian.vetter@vates.tech> <23816f6d-57eb-4567-b6da-93269e6a1c23@suse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <23816f6d-57eb-4567-b6da-93269e6a1c23@suse.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3628.50d989936137e3e1.1a06b76ed1b.d0178a230859bc74=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788509351195 X-purgate-ID: tlsNG-33051d/1788509354-774F44E9-72AFE369/0/0 X-purgate-type: clean X-purgate-size: 2790 ---=Part.3628.50d989936137e3e1.1a06b76ed1b.d0178a230859bc74=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2026 at 04:08:04PM +0200, Jan Beulich wrote: > On 20=2E04=2E2026 11:38, Julian Vetter wrote: > > Julian Vetter (3): > > ioreq: switch ioreq page allocation to vmap > > ioreq: Indent ioreq_server_alloc_mfn() body one level deeper > > x86/ioreq: Extend ioreq server to support multiple ioreq pages > >=20 > > xen/arch/x86/hvm/ioreq=2Ec | 63 ++++++++++++++++--- > > xen/common/ioreq=2Ec | 127 ++++++++++++++++++++++++++----------= --- > > xen/include/xen/ioreq=2Eh | 13 +++- > > 3 files changed, 151 insertions(+), 52 deletions(-) >=20 > For (future) reference, in case it wasn't said earlier: >=20 > To be able to test this, at least the last patch here will want to wait > until the apic_id =3D=3D vcpu_id * 2 issue was addressed=2E Andrew said = he'd pick > up Alejandro's work there, thus - once finished - permitting up to 255 > vCPU-s (i=2Ee=2E requiring 2 IOREQ pages)=2E >=20 > Once (really: before) we grow the number of vCPU-s for HVM, we need to > revisit the amount of VA space set aside for vmap()=2E For many years we= 've > been adding new uses of vmap() without making sure its reserved range is > still adequately sized=2E >=20 > Since multi-page functionality added here will also need qemu changes, a= nd > since we did determine (elsewhere) that ioreq_t needs to grow as well, i= t > remains to be decided whether the two changes wouldn't better be done > together, to keep the qemu backwards compatibility logic somewhat limite= d > in size / complexity=2E Anthony (in particular) - thoughts? Put like that, how can I say "no" to merge both changes together :-) It will certainly be simpler to maintain if having one feature mean also having the other=2E But it kind of depends on whether both changes are ready to go in at around the same time=2E I don't really know how the changes in QEMU will look like, and how QEMU will choose or have a choice of which feature to use, and it might be one that can be negotiated as runtime and the other one been a compile time change (as I think QEMU still depends on unstable ABI)=2E But it looks like both changes in QEMU are for having more vCPU, so having both at the same time might be better=2E So yes, I'm all for less complexity, but I can't ask for this to be a blocker, especially if the other change might takes years=2E So far, I don't think I've seen any patches for QEMU=2E Cheers, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.3628.50d989936137e3e1.1a06b76ed1b.d0178a230859bc74=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:24:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:24:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407974.1640715 (Exim 4.92) (envelope-from ) id 1x2PE3-0001nT-Un; Fri, 04 Sep 2026 08:24:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407974.1640715; Fri, 04 Sep 2026 08:24:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PE3-0001nM-RG; Fri, 04 Sep 2026 08:24:43 +0000 Received: by outflank-mailman (input) for mailman id 1407974; Fri, 04 Sep 2026 08:24:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PE2-0001nG-84 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:24:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2PE1-0068X9-L8 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:24:41 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a8044-8faa-0a2a0a5109dd-0a2a4509a50e-20 for ; Fri, 04 Sep 2026 10:24:41 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a8049-be1a-0a2a45090019-d1558033adcd-3 for ; Fri, 04 Sep 2026 10:24:41 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-49b0dd3c9a0so6224305e9.1 for ; Fri, 04 Sep 2026 01:24:41 -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-49cee60bae6sm166982965e9.9.2026.09.04.01.24.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 01:24:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788510281; x=1789115081; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=9mxqBxYsPuVY5Ues6Y+FJ04DO4eGszOkGdL/EPudWdE=; b=fJE2DB939nXsCYT6LX05agSb90bpPrDTANkEhVkEmtuJLJnJI5WT0tvxJxUTsG6AMU Larh+xheaZH3QnspbcQRpwBHAJOkpGlDApvebPXfgeAFbyERcqimKOE33O49pyuywxiy gHcms2y/irPXEFEfizvrtAEfnH3y+74AXM4YmleVL+jPIOIHaNigghRnt9LS+N+6fY10 ptVEy8X9IMUBrsuhRov7FsxPAkIMINXCikR2WntmrcOxWl+zlOjw+qznx+YeZZ4Udhnw iZDW58LU6uEEdsWTMak8tAFIhB3H70nTpNgP1DWhd94UfLigIKnLssNYB991jJPBa0Em FLig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788510281; x=1789115081; h=content-transfer-encoding:content-type: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:content-type; bh=9mxqBxYsPuVY5Ues6Y+FJ04DO4eGszOkGdL/EPudWdE=; b=nzO6YyHFy5gOkqMq90C2UOzB2Wv2O2Mb3ww9T2dDEArhFWRVjKm1zPgCTFJlK2KcOn aqhnBzdxBsKZLdhrXWUfoCbzd1TdUSpePxcC9bR/IrxnjIVvP2H9z/SZaqy/QYQMVUjg F66j/jOepjTmqM3xwqRJJI7avox4q5NLONnXbEL1PhQoXFM3kYPJw415wfQZz1RwJsT0 +xMfmzVIvHNSUef2rIhfB3EJwT4KALLb/tIVVdXKuh7GnwCuWMf8blayCx/oQJ9Z+3EE zT05q5Mhmu7lsVen4fJwHFxJOcmvJDhk5Wf8+F3+kX/Ahl/NouKRFK5wLON+DdbcjDbe cwlg== X-Forwarded-Encrypted: i=1; AKwUvBx/dlZlP1WMSP2xxkwsGyodFafY+TlkftIMl6jmZi+AWKxBZvvwOUXYfSc7SUGchFHCBDTWrX+JwY0=@lists.xenproject.org X-Gm-Message-State: AFuF++mg3ulQutroQrN0MPHJ/Zdxsc98ieaqNy26PiAHg0BV/ae+MK0h uz2Sn165LDmZnH/4Q2dRX7hF4n1KDa9LfSiqtLdfKmtm2YoY/PhZvRmRaXEZcLysgg== X-Gm-Gg: AYBFou29V1PCfvcEkfEUiv/RkOrqoJLefAHmOgMj0ir4bq74XE+Hhc89IU7hV0MdxHI kAih4w87twlS3fb9r9ATnt3XAhEe6dUl9bWlR1IKpHd206Ng1ZyUhf21w52hOSbE49jwBJpWXk7 lK+e8s31rAV00NcLvdfUYqz9Nn+NkjezFh3bBtv1aBUrkkVPuerfwUR8NgoPHlfsdzFtV2TN4gp 7y4+5zpSZFMrwXRHs9ztO2bGNCt0MLohHO+YuUSUkAtwuVKWQo5D0EwjHizoQPT1X+5uHAave8l wYKQGdXuL39Sq2MwhYMnIvY1CaAci9bRMDPhAIpWInY1PnepksS3LvNwRsHgo2q9r+iJ/R3oWvE 2paADtpa4iSQthFVFclA/NiToAcWFV4m8n4nHnIxDJOnl63hNrFTkGK0N0KKX3hVcE9tHPhzGNM LtBWrqK5QYa0C/CHlZmmJ+/kZaKUTyjLoIZ1JrXUfa7oSVAa3VAoS0sJJVwHTczCi2O5YpsIqDl CUMHnEy+zoZSQVUMGhWRKgN23Vc6vYC5blMdUP3vCHFVGgTs12d X-Received: by 2002:a05:600c:3b11:b0:49c:f7c4:dc54 with SMTP id 5b1f17b1804b1-49cf82512b9mr58363415e9.14.1788510280948; Fri, 04 Sep 2026 01:24:40 -0700 (PDT) Message-ID: <98ea7e14-4787-43a2-81ef-a65493e3cd92@suse.com> Date: Fri, 4 Sep 2026 10:24:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 0/3] Support multiple ioreq pages To: Anthony PERARD Cc: Julian Vetter , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260420093820.825969-1-julian.vetter@vates.tech> <23816f6d-57eb-4567-b6da-93269e6a1c23@suse.com> <1788509352.8631fc262581453bbf619ec5b2062170.1a06b76f0aa000c4f3@vates.tech> 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: <1788509352.8631fc262581453bbf619ec5b2062170.1a06b76f0aa000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788510281-3A0C5034-1613B71D/0/0 X-purgate-type: clean X-purgate-size: 2934 On 04.09.2026 10:09, Anthony PERARD wrote: > On Tue, Aug 18, 2026 at 04:08:04PM +0200, Jan Beulich wrote: >> On 20.04.2026 11:38, Julian Vetter wrote: >>> Julian Vetter (3): >>> ioreq: switch ioreq page allocation to vmap >>> ioreq: Indent ioreq_server_alloc_mfn() body one level deeper >>> x86/ioreq: Extend ioreq server to support multiple ioreq pages >>> >>> xen/arch/x86/hvm/ioreq.c | 63 ++++++++++++++++--- >>> xen/common/ioreq.c | 127 ++++++++++++++++++++++++++------------- >>> xen/include/xen/ioreq.h | 13 +++- >>> 3 files changed, 151 insertions(+), 52 deletions(-) >> >> For (future) reference, in case it wasn't said earlier: >> >> To be able to test this, at least the last patch here will want to wait >> until the apic_id == vcpu_id * 2 issue was addressed. Andrew said he'd pick >> up Alejandro's work there, thus - once finished - permitting up to 255 >> vCPU-s (i.e. requiring 2 IOREQ pages). >> >> Once (really: before) we grow the number of vCPU-s for HVM, we need to >> revisit the amount of VA space set aside for vmap(). For many years we've >> been adding new uses of vmap() without making sure its reserved range is >> still adequately sized. >> >> Since multi-page functionality added here will also need qemu changes, and >> since we did determine (elsewhere) that ioreq_t needs to grow as well, it >> remains to be decided whether the two changes wouldn't better be done >> together, to keep the qemu backwards compatibility logic somewhat limited >> in size / complexity. Anthony (in particular) - thoughts? > > Put like that, how can I say "no" to merge both changes together :-) > > It will certainly be simpler to maintain if having one feature mean also > having the other. But it kind of depends on whether both changes are > ready to go in at around the same time. I don't really know how the > changes in QEMU will look like, and how QEMU will choose or have a > choice of which feature to use, and it might be one that can be > negotiated as runtime and the other one been a compile time change (as I > think QEMU still depends on unstable ABI). > > But it looks like both changes in QEMU are for having more vCPU, so > having both at the same time might be better. Growing ioreq_t (in particular the data size it can hold) doesn't have anything to do with increased vCPU count, I think. > So yes, I'm all for less complexity, but I can't ask for this to be a > blocker, especially if the other change might takes years. So far, I > don't think I've seen any patches for QEMU. How exactly a new ioreq_t would want to look like remains to be discussed. Perhaps we could go an intermediate route here: Add provisions (e.g. a full page per vCPU, plus a format identifier at the start of that page), allowing the enlarged ioreq_t to be put on top, yet without needing any (further) changes to the map/unmap logic? Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:26:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:26:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407981.1640723 (Exim 4.92) (envelope-from ) id 1x2PFi-0002Jb-7r; Fri, 04 Sep 2026 08:26:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407981.1640723; Fri, 04 Sep 2026 08:26:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PFi-0002JT-4c; Fri, 04 Sep 2026 08:26:26 +0000 Received: by outflank-mailman (input) for mailman id 1407981; Fri, 04 Sep 2026 08:26:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2PFg-0002JL-Ea for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:26:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2PFf-00CrcH-DC for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:26:23 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a80a5-2eae-0a2a0a5409dd-0a2a4509cdb4-48 for ; Fri, 04 Sep 2026 10:26:23 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a80af-be1a-0a2a45090019-b9ff1c22a197-3 for ; Fri, 04 Sep 2026 10:26:23 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06b869ff7000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 08:26:20 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 485F0802F6; Fri, 4 Sep 2026 10:26:19 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=LkwtOW0c6kSr+rEb1RtiU4SlzBO+PyodhuqzUo+tvnc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=dZWfsl62iM+XFfyAbIhKyl4ZGx3s8QFlljS9XjDI7Hh5En0iCKqYnoR/2OgBi2Tlzb2zyjXgk ZvnHpWw0fKz3DLFtcVCXsMCPN4czYHXAtXn2ay5M0LEelxnZXNw0PaWRcBy1EbT6cYHfMU4Vicu qOjTROXYlP3XrL2fi5j8Tk7Lg3XjOjgy5J/egZyi8fpkc30O14UtU7rglOTSz8osAz2U0rxxbeb mKsXVfzxCb9Lgf0eOqJWE4KC97Liv+wV4M+UNJ/EbB3PB+tn3XV53OWTPwNC4JD0k7K0MloxoR4 40YQRpLhOJrTgmzOTFx8sCILv2FNdiSK2SbVNeLNbCHA== X-Zone-Loop: c489e59f79928406ccfe3b0ee381818edc8715e685ad x-campaign-type: default x-transaction-id: 8b5ca3b0-dd43-408d-916d-616c69673c84 x-swg-uid: 01-d0ce9b2d-c48e-429b-9331-87b242d64cb4 X-Mailer: Sweego Message-ID: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b869ff7000c4f3@vates.tech> x-swg-bid: 1788510380.8631fc262581453bbf619ec5b2062170.1a06b869ff7000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 04 Sep 2026 10:26:10 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788510379; l=612; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=VVl73hF2qvOuLJ9fA3IIcYG1Ix//l3ET1E6wYzLa6Go=; b=0RWtrZhJYlEJNyjtvDiGOqGhycQO+ovox/4RSI3g5lQ9K2pdEhUeOjJya8OwQxvurZAhwUjuU 9IzuDhiRpctD8WkeVR0tLrfn4COZUvrriSOOEKyv61CyIkaLDhSiJZq X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788510379509 X-purgate-ID: tlsNG-bad1c0/1788510383-FDC6D034-55A78C4A/10/73395122804 X-purgate-type: spam X-purgate-size: 612 On Thu, 27 Aug 2026 17:20:54 +0200, Oleksii Kurochko wrote: > aplic_set_irq_affinity() open-coded the packing of the group and hart > indices into the target register, and got two things wrong along the > way: > > - imsic_config.msi[] is indexed by logical CPU id, but the index was > run through cpuid_to_hartid() first. On any platform where the two > spaces differ this picks another CPU's interrupt file, or reads past > the array; > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:26:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:26:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407982.1640732 (Exim 4.92) (envelope-from ) id 1x2PFk-0002Wn-H8; Fri, 04 Sep 2026 08:26:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407982.1640732; Fri, 04 Sep 2026 08:26:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PFk-0002Wg-Dj; Fri, 04 Sep 2026 08:26:28 +0000 Received: by outflank-mailman (input) for mailman id 1407982; Fri, 04 Sep 2026 08:26:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2PFk-0002WQ-0L for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:26:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2PFj-00CrZn-DK for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:26:27 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a80af-e002-0a2a0a5209dd-0a2a4509e954-22 for ; Fri, 04 Sep 2026 10:26:27 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a80af-be1a-0a2a45090019-b9ff1c22a197-4 for ; Fri, 04 Sep 2026 10:26:27 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06b86a1b8000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 08:26:20 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id AE42083EF6; Fri, 4 Sep 2026 10:26:19 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=uK5ssj6GpBmwGJQocmA+QQydMx24xNl2C3C29UcyLJw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=BIaVidTGEp22bsV0ujXKn5aF2pLkrHwPO3j3jq0qp3QaBC8rDTOPfvR4KFncu1ey35WzHuiOT xELLwAlTz/lsomqbn6ykbIc6j/NmnhjGDoA51hfaROMSVlkTx76lcIZ3wCy3ITnfMm930qvZmkA Vs/RI+rJ0OnVjf+ncOcHA6cmYFBtN0/JgLtGUyvoYQEKHYCow3Ccy8zHVA1IpP7V8acX+PebCpu hJGZPI0euw7/Ub5bRaoMcLGamtNzNfgX80VjUccBGLX+QvjOEZDf0l70OBXexOVljS3SCVBw6ef VCJJ+6dCpu2EZDgs2SM9Q6YCOo7sPWFRg5gV9+RMV0Xg== X-Zone-Loop: 18daa6696dff19677b713ab9a44279c7ded1d8d12852 x-campaign-type: default x-transaction-id: d0309d52-d650-46a8-bd5d-dd829adf7c19 x-swg-uid: 01-ad0e47da-da9e-46e0-857d-3debd6d9e305 X-Mailer: Sweego Message-ID: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a1b8000c4f3@vates.tech> x-swg-bid: 1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a1b8000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 11/39] xen/riscv: add helper to check APLIC MSI mode From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Fri, 04 Sep 2026 10:26:10 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788510379; l=262; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=dT3s7B8xtuYVtvd7ntSCK0uqqprh/09O2WPOIyXe3Ms=; b=tpDz1fSTZmduBK8X4S7IjAucgJaHEMa79Nl5wRycJuB5PffoFDAZb/1376jXWcwD9J7OgA4V4 MbbJZcjwPEKCuoRYqtwxhc7vqbtmERcowgQI2w4o1KlDhjjGYbRZRnp X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788510379912 X-purgate-ID: tlsNG-bad1c0/1788510387-FD06B034-1DFE4EBB/10/73395122804 X-purgate-type: spam X-purgate-size: 262 On Thu, 27 Aug 2026 17:20:55 +0200, Oleksii Kurochko wrote: > Use convient helper instead of open-coding the things. Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:26:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:26:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407983.1640741 (Exim 4.92) (envelope-from ) id 1x2PFo-0002lq-NE; Fri, 04 Sep 2026 08:26:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407983.1640741; Fri, 04 Sep 2026 08:26:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PFo-0002lf-KF; Fri, 04 Sep 2026 08:26:32 +0000 Received: by outflank-mailman (input) for mailman id 1407983; Fri, 04 Sep 2026 08:26:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2PFn-0002ki-6i for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:26:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2PFm-00CrgA-JY for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:26:30 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a80af-e002-0a2a0a5209dd-0a2a4509e954-40 for ; Fri, 04 Sep 2026 10:26:30 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a80af-be1a-0a2a45090019-b9ff1c22a197-5 for ; Fri, 04 Sep 2026 10:26:30 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06b86a349000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 08:26:20 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 1E2CA802F6; Fri, 4 Sep 2026 10:26:20 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=Di0Hawg+axQGrdxpJjlorhfH9iHXCw0a3L3zGg16D5M=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=j7pVqSthkSsKyAbyaeL/BzNxnJy2406IhTvqAvOuewgEVQ7ma82g0yXIJ1AK6PRynpZvcmQ4Y m7enuhMtLMp/9Vv1+hgos9vYj7HiZRJLqvDHVdknK8VW5e7Gvm/KfqPr5umSGfZm1eBLuXLMIao dUt0FR5PsbJevm/FT1FpFM0Nr4LEXk5+LwCG1zlWE5vQfJ4H29SGTFF7d7y4AM0onYqWGMcqvPk aCmJFEXltg2FsiJlTa/x+NmbE684l40JhFVp4woe423piSQaJhSc3iYTf+BghF/WBWeVPYJXLh+ RHJ+UvSiBrE8/VwWBa4C4abyMhRSOyCI2NDCqDWX1+zw== X-Zone-Loop: 0af76f2ff1590b9067b226c1d5a1b4b8664331a4a767 x-campaign-type: default x-transaction-id: 4b26a73b-cc9d-42a5-afd9-5d597bfbaf58 x-swg-uid: 01-349004eb-7d2f-44b1-988d-01703f3dd11e X-Mailer: Sweego Message-ID: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3@vates.tech> x-swg-bid: 1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 04 Sep 2026 10:26:10 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788510379; l=7001; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=xED3kTXU4/307Oa7PqWkBMB5xhiN8U/7lWdPmOMMBf8=; b=hCzdKGJnKwSAAsO81lcMz+VMEnw6CVK/0VdSvehLiZp9ZSfnjqXExVKOkJgt7Tx2OufEO9SRy 2h1rxW3EXqVDjo3X7iKOa6+vcU7pKEc9ZwbbketV4NcWOHzuvygvSqF X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788510380325 X-purgate-ID: tlsNG-bad1c0/1788510390-FDA6E034-9F1AA250/10/73395122804 X-purgate-type: spam X-purgate-size: 7001 As I understand it, a generation wrap doesn't retire a single VMID, it resets next_vmid to 1, which makes every VMID in 1..max_vmid reusable again in the new generation. We do a full (local) flush at that point to avoid two different vCPUs ending up with the same VMID valid at once, across generations. If this is correct, doing a full flush there also throws away entries for the current vCPU that a local HFENCE.GVMA(vmid) per retired VMID could have preserved. A local-flush-per-VMID approach could also reduce how often we need a full flush at all. Is there a reason we don't do local flushing instead? I see x86 and KVM use the same flush-all design on wrap, so I assume there's a reason I'm missing, I'd like to understand it. Thanks in advance. > H/VS CSRs, virtual timer and P2M context, and __context_switch() in assembly, > which switches Xen's own callee-saved state (and thereby the stack) from > prev to next. Virtual interrupt controller context switch will be > introduced later. > > Add offsets of struct arch_vcpu's xen_saved_context to asm-offsets.c for > use by __context_switch(). > > henvcfg and htimedelta are 64-bit on both RV32 and RV64, so store them as > uint64_t and use csr_{read,write}64() instead of open-coding accesses to > the high halves. > > A hart which drops out of a domain's dirty_cpumask stops being a target > of p2m_tlb_flush() while its TLB may still hold G-stage translations of > that domain, and neither the vCPU which just ran nor any other vCPU of > that domain which ran there earlier has had its VMID invalidated. Move > the hart to a new VMID generation at that point: a VMID number is never > re-used until a full local flush has happened, hence none of those > translations can be reached again. > > Claim the VMID in p2m_ctxt_switch_to() rather than at the next guest > entry. VMIDs are a per-hart resource, so the (generation, vmid) pair a > migrating vCPU brings from another hart is meaningless here and may even > match this hart's current generation, leaving the vCPU under a VMID owned > by another domain. ctxt_switch_to() invalidates that pair, but claiming a > replacement only on guest entry is too late: p2m_ctxt_switch_to() has by > then already made HGATP live, and speculation can populate G-stage entries > of the incoming domain under the stale VMID. The local flush for a wrapped > generation moves along with the claim. > > That leaves p2m_handle_vmenter() with nothing to do, so drop it together > with its call from check_for_pcpu_work(). A VMID can only be invalidated > while its vCPU isn't running: vmid_flush_vcpu() is called for the vCPU > being switched in, and vmid_flush_hart() runs either from schedule_tail(), > ahead of ctxt_switch_to(), or from the wrap path of vmid_handle_vmenter() > itself. A P2M change on another hart doesn't invalidate it either, as > p2m_tlb_flush() drops the stale entries directly with > sbi_remote_hfence_gvma() instead of retiring the VMIDs which tag them. A > guest therefore always runs under the VMID claimed on its way in, and > there is nothing left for a guest entry hook to notice. > > p2m_handle_vmenter() also skipped the HGATP write when the VMID it claimed > was unchanged. That isn't carried over: HGATP holds the G-stage root as > well, and skipping the write is only correct where that root is already > the incoming domain's. On the guest entry path it is, on the context > switch path it is not. > > While at it, fix the inclusion order of headers in asm-offsets.c: Xen's > headers go first, then arch specific ones. This could have a dedicated patch no? > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index ec327a5e8a..91a46d630f 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -11,9 +11,11 @@ > #include > #include > #include > +#include > #include > #include > #include > +#include > #include > > struct csr_masks { > @@ -158,6 +160,8 @@ int arch_vcpu_create(struct vcpu *v) > if ( is_idle_vcpu(v) ) > return 0; > > + v->arch.last_cpu = NR_CPUS; > + > vcpu_csr_init(v); > > if ( (rc = vcpu_vtimer_init(v)) ) > @@ -329,6 +333,169 @@ int arch_domain_create(struct domain *d, > return rc; > } > > +static void save_csr_regs(struct vcpu *vcpu) > +{ > + /* > + * There is no need to save these CSRs as only hypervisor writes them in > + * restore_csr_regs() and guest can't access them so they shouldn't be > + * stored here. Keep them commented here just for symmetry with the > + * restore CSRs register part. > + * > + * vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); > + * vcpu->arch.hideleg = csr_read(CSR_HIDELEG); > + * vcpu->arch.henvcfg = csr_read64(CSR_HENVCFG); > + * vcpu->arch.hcounteren = csr_read(CSR_HCOUNTEREN); > + * vcpu->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); > + * > + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + * vcpu->arch.hstateen0 = csr_read(CSR_HSTATEEN0); > + */ > + > + vcpu->arch.hvip = csr_read(CSR_HVIP); > + > + vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS); > + vcpu->arch.vsie = csr_read(CSR_VSIE); > + vcpu->arch.vstvec = csr_read(CSR_VSTVEC); > + vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH); > + vcpu->arch.vscause = csr_read(CSR_VSCAUSE); > + vcpu->arch.vstval = csr_read(CSR_VSTVAL); > + vcpu->arch.vsepc = csr_read(CSR_VSEPC); > +} > + > +static void restore_csr_regs(struct vcpu *vcpu) > +{ > + csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); > + csr_write(CSR_HIDELEG, vcpu->arch.hideleg); > + csr_write(CSR_HVIP, vcpu->arch.hvip); > + csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); > + csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); > + csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); > + > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); > + > + csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); > + csr_write(CSR_VSIE, vcpu->arch.vsie); > + csr_write(CSR_VSTVEC, vcpu->arch.vstvec); > + csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); > + csr_write(CSR_VSCAUSE, vcpu->arch.vscause); > + csr_write(CSR_VSTVAL, vcpu->arch.vstval); > + csr_write(CSR_VSEPC, vcpu->arch.vsepc); > +} > + > +static void ctxt_switch_from(struct vcpu *p) Is it expected to have diverse names for the vcpu arg? Above it's vcpu, here it's p (I assume it's for `previous` but I think the _from alone is enough to understand) and below it's n. Shouldn't be better to keep the same name? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:29:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:29:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1407999.1640749 (Exim 4.92) (envelope-from ) id 1x2PIN-0003pj-3q; Fri, 04 Sep 2026 08:29:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1407999.1640749; Fri, 04 Sep 2026 08:29:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PIN-0003pc-0w; Fri, 04 Sep 2026 08:29:11 +0000 Received: by outflank-mailman (input) for mailman id 1407999; Fri, 04 Sep 2026 08:29:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PIL-0003pU-EY for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:29:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2PIK-00HC8J-RZ for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:29:08 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a8153-e002-0a2a0a5209dd-0a2a450c871a-6 for ; Fri, 04 Sep 2026 10:29:08 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a8154-f479-0a2a450c0019-d155dd32cd40-3 for ; Fri, 04 Sep 2026 10:29:08 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48441a2ba14so632948f8f.1 for ; Fri, 04 Sep 2026 01:29:08 -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 ffacd0b85a97d-485883acd33sm4696290f8f.18.2026.09.04.01.29.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 01:29:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788510548; x=1789115348; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=fv1Hle5ICcjsbv9RdoU1hWsZEcqlLyhQcR0STYSRl+Q=; b=Gz7XOSv5FXoyXJeClB9QFhNzwvrdawBjYINGAaSIxd9YTKxUrPbGV46lDJCkU7rb7z gmOCSsmojNBbCvlBGZzJBghhnCpXw2zGIJQs1dKKs4brA6H3VTbXeM7eBmQn4ksOeWkP 4FkqE+csJG93zu6DtsbKg3S7buRVRvjGdFSdfRL1qNtOwOy7fyKz84Qt0TTSciGyYd3m qoaNi0HnQSfdRqmqxhYKkIZ0waZzCkEy+a5Wa1uJU0epJcwIDEtMrCMh8W+vWTNDBRMf eUeJXzdhkGXYrfoyWWvQG8BREZ9XDz/OS7gJNO2aTcHtyHyv1gshhPn1Bb5xLM75Xyjb dnDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788510548; x=1789115348; h=content-transfer-encoding:content-type: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:content-type; bh=fv1Hle5ICcjsbv9RdoU1hWsZEcqlLyhQcR0STYSRl+Q=; b=AlOgZOvZi2hvwxE1mgovJB3Ld3ZDDOw5/vlpWHwlDbEtYShNZucaAuFC3i5xLx5rjn QCcRG/AAVVxKFfYfq2Yuxx2zJVMdCZ5EXSwdz48iz8UOUAS5WgFymPGIgg25MD1qFz/z xnvEO334CHStOgMioTRSeJSV1t/DLiAyEckBy3Ize+4+u7yuW7geedSA5oz9rm1IzqPG FX7WxR2ip7GTNDXyrbbiQg02Ra1rCTZR84uRJlctmbD15CaSWDGkoEllMf/ImtwC48SH dfzCG5ezs4AN7JHIYObPFpmvkgtiBYQaibZUJ6FWVIgJ52/75wLspwfrMyixU0XSNdaG mFqQ== X-Forwarded-Encrypted: i=1; AKwUvBzFQQX3x2HAj+07scpeHscR6XWBmgmWdq7Dq9SaP1aqc/lgecYvw+j77rVRcXgWoVVxPjJaT0kLDQQ=@lists.xenproject.org X-Gm-Message-State: AFuF++mkvwQFnUywUfBUvrli4CtDj6WDVa7ckZBVJdS/MwtArwwsEd9i ZIsKHF/cRXm9No6YCkpUhJZffKlTWwtd+nwTwCjmpgwqEk1Q4kGE+ZDAikFNSjWOrl7Lbct4oG3 SLXmt2w== X-Gm-Gg: AYBFou0mktg4HCtXYyMiHZZuFTVwP/B3eIJwji23xgkrDzZ2AWzCkBAo52OZEc6t52L m1SyLlkNZh4J8MoxZfxZDFVRpjKHMzggbKXYdQduLuuA0Hm5yj7T3fukflJteeIg+gVriOmk6AK utmZTeO0cgjnFpXuD57wbe39qE8T69kmHz0ajPQ/sLdnvhfSjxit9svONu2q4QiBvTb1aKwIeYX dnlh9rqQAInPDJmOaA8SXyXBVIjTKOoSkYKe3TMxEb02M/FsOk/rnEXoc8M7cg/TJ3rmZ1FD1ty YOoCV6ckv7WHyGIGv1FgDPYmmlEbD4uAwSjKGqFgA1a4vCedxOuc06HZG/SeokrC7od+roCJAua /SQExB9NBBiRflVDkmtbc06Xss9yFnUoQKQSHiFDphcDLbPq2iLpWNpu7oxkNlu236OUm04eI27 Uf6dwLkQdMEAG55XCZdpM2celJGsKiODS+ZFGm1kbJOWynWzcKPLEFLip/6vZLqZ+MnpbRZvU5D PxGRq4KUYA+d8pDVJtuoYImQ5ExIXPgb0s6v/bEEz4z5hNXDFSc X-Received: by 2002:a05:6000:2f88:b0:485:8a46:704e with SMTP id ffacd0b85a97d-4858a4671cemr2714258f8f.32.1788510548107; Fri, 04 Sep 2026 01:29:08 -0700 (PDT) Message-ID: Date: Fri, 4 Sep 2026 10:29:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> <050f44ec-47e5-4754-b73b-1173458736b0@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: 8bit X-purgate-ID: tlsNG-d25034/1788510548-50D3CA5B-518E7308/0/0 X-purgate-type: clean X-purgate-size: 6371 On 04.09.2026 10:06, George Dunlap wrote: > On Fri, Sep 4, 2026 at 7:54 AM Jürgen Groß wrote: >> >> On 04.09.26 08:00, Jan Beulich wrote: >>> On 04.09.2026 00:35, George Dunlap wrote: >>>> On Thu, Sep 3, 2026 at 5:11 PM Jan Beulich wrote: >>>>> >>>>> On 02.09.2026 11:43, George Dunlap wrote: >>>>>> From: Roger Pau Monné >>>>>> >>>>>> Currently, update_xen_slot_in_full_gdt() uses the stashed direct-map >>>>>> pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vcpu's >>>>>> page tables with Xen's GDT, by writing a stashed per-cpu copy of a >>>>>> pre-baked L1 entry (either 64-bit or compat version). >>>>>> >>>>>> Switch this to using populate_perdomain_mapping(), which doesn't rely >>>>>> on the stashed address of the l1 page in the direct map. Rather than >>>>>> also stashing a pre-baked value for the payload, compute the mfn from >>>>>> the per-cpu GDT pointer at use: the conversion is a handful of cycles >>>>>> on a path costing thousands, and computing at use removes the >>>>>> parallel {,compat_}gdt_l1e bookkeeping along with its boot-ordering >>>>>> constraint (the cached value could only be generated after Xen's >>>>>> physical relocation, and had to be in place before the first context >>>>>> switch; a use-time lookup is correct by construction). The flags on >>>>>> the final mapping are identical. >>>>>> >>>>>> Signed-off-by: Roger Pau Monné >>>>>> Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 >>>>>> Signed-off-by: George Dunlap >>>>>> --- >>>>>> Changes in v2: >>>>>> - Drop the {,compat_}gdt_mfn caching entirely (suggested by Andrew >>>>>> Cooper): compute virt_to_mfn() from the per-cpu GDT pointer at use. >>>>>> The PDX lookup behind it measures ~5-10 cycles warm against a >>>>>> ~1,500-cycle context switch, and this removes the double >>>>>> bookkeeping and the after-relocation caching constraint. The >>>>>> cached-MFN assertion goes with the cache: a use-time computation >>>>>> from a live pointer needs no staleness check. >>>>> >>>>> This looks to contradict what 564d261687c0 ("x86/ctxt-switch: Document >>>>> and improve GDT handling") used as justification to put in place the >>>>> caching. Also Cc-ing Jürgen, who also was involved there, for possible >>>>> further insight. >>>>> >>>>> Functionally the change looks okay to me, but the above will need >>>>> sorting, at the very least by specifically discussing why effectively >>>>> undoing that earlier change is okay. >>>> >>>> So looking back at the thread, Jürgen measured a 14% improvement for >>>> something that might be described as a microbenchmark before and after >>>> the patch (a benchmark purposely trying to set up an unusual scenario >>>> to maximize the effect of context switch overhead, not one to >>>> represent a typical workflow). But are the numbers really plausible? >>>> Even at an implausible 100k switches/s across the box, saving 100 >>>> cycles per switch is about 0.04% of eight 3 GHz cores. >>>> >>>> At any rate, we're already adding several map/unmap operations, and >>>> about to add several more. Keeping the PTE caching would require >>>> adding a separate path that can write just PTEs, which then will >>>> potentially further complication future paths where we need to make >>>> sure we handle both domain-wide perdomain areas and per-vcpu areas. >>>> If it were easy I would already have been keeping it. >>>> >>>> I'd be inclined to say: Since we're going to be adding more >>>> populate_perdomain_mapping() calls anyway, let's do it the simple >>>> correct way first; and then explore the idea of stashing mfns of >>>> frequently-mapped L1s (rather than having to walk L3 -> L2 -> L1); and >>>> at that time look into stashing baked l1es to avoid conversions. >>> >>> Perhaps; I'd like to have Jürgen's and/or Andrew's input here, though. >> >> At that time I implemented core scheduling in Xen. I noticed that very >> subtle changes in the context switch path could result in unexpected large >> performance differences. As I had the performance test for my purpose >> already set up, I used it for Andrew's patch (which was a result of my >> context switch path performance findings) and really did measure the >> impressive effect of it. >> >> Note that you can't only count instructions, often cache effects and >> branch predictions are dominating the performance. > > Right, but: > > 1. That's going to be very much hardware- and workload- dependent. > Even on the same hardware, if you'd made a slight change in the > workload, you might have seen a very different result; and on > different hardware you're going to see something different again > > 2. As I said, we're now adding two extra map / unmaps, which is going > to perturb everything again. > > If anything, your argument says we should wait until we've stopped > modifying the context switch path (which won't happen until patch 49 > at least, guessing from the patch titles), and then measure things > again to see what's actually slow. > > I'm sorry Jan, You were replying to Jürgen, though. > your position here is really inconsistent: You wave > away a partial pagetable walk with three map/unmap operations on the > context switch path as something we'll have to do in the interim, and > can optimize later, but are now threatening to make me add in > special-case codepaths and run tests to save a few memory reads and > shifts. I think you misunderstood. There was a concern raised already on v1, and that concern wasn't covered by the patch description. In my initial reply I said "Functionally the change looks okay to me" for a reason, after all. Jan > I could put back the mfn caching that was present in v1 of the series > (which Andy said was probably not sufficient, on balance, to make the > duplication involved worth it). Even that I think isn't really > sensible, but it's not too difficult to do. To isolate the PTE > caching effect I'd have to write an entire duplicate codepath anyway, > and then try to duplicate Jürgen's test. I don't think that's really > a reasonable ask at this point in the series. > > -George From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:33:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:33:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408010.1640760 (Exim 4.92) (envelope-from ) id 1x2PMh-0005W1-Ms; Fri, 04 Sep 2026 08:33:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408010.1640760; Fri, 04 Sep 2026 08:33:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PMh-0005Vu-J3; Fri, 04 Sep 2026 08:33:39 +0000 Received: by outflank-mailman (input) for mailman id 1408010; Fri, 04 Sep 2026 08:33:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2PMg-0005Vo-KX for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:33:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2PMf-006AFq-J3 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:33:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a8260-bab6-0a2a0a5309dd-0a2a45018810-4 for ; Fri, 04 Sep 2026 10:33:37 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a8261-5984-0a2a45010019-d155802be5c5-3 for ; Fri, 04 Sep 2026 10:33:37 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4957eefd361so5714755e9.1 for ; Fri, 04 Sep 2026 01:33:37 -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-49cf771e9absm53885825e9.9.2026.09.04.01.33.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 01:33:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788510817; x=1789115617; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=IL1TvCibeZNO0FvOp0VvoyE7y7mH5z6llQijmjUIlsE=; b=B/EZAwJMyKZqea7Omlo+ISyVVGF+f5cgr/qNxk7tljCgIy4PjzEadAXB9lVUyfD7gH RdD4YBgbND5KrH56ARkuuUY6NXC3h/lYrcxNOoO5GDty/HR/8bxO0Fi1uuG9bUWakDL4 q3lsrwFM+mrbGuTPBROKdUTXgdFR0VvNftGYF4L8sRoEO8+1wc4Is2vKqquELVu1KlK/ I4VYW7Ub0frubV1Gov9Vxfmg/EZf8w/IgkimZ15u4SmutlkN84SEhHAc8fW9I2HKzMmW ZHwSPeltOkXUU+sszyh8O/s0a4MPCjBB0vEbMspvdruhEIYTQ/ANtxLn2HeiG/IjBCMC N4Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788510817; x=1789115617; h=content-transfer-encoding:content-type: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:content-type; bh=IL1TvCibeZNO0FvOp0VvoyE7y7mH5z6llQijmjUIlsE=; b=Dsj/N9bNQeLrRmT8xTs7pizAlhTujw60JHpWyngRhsgh20jC/47n/ILBtNlV1E6huc 3jr3KzkTlFechOxqVPVphJuGBSMlfjhvoBBazaETcSjpy662d1lNJnScFpTbLw6fCWZz cHb4B3qNOWhtBob7PDNPZOFnNYiKYM1SspUqbgKdF37QuZL2LzVwiu8TA2AzlMHUVCpn 0LKNd1CBuK/h26C6B8slpT21A/gOiw0lvgKjuBXidQZWIOgNBI/kxcVhm0s/fun1JcDi 2WUusH/DxZpeD4Rl4xR/psQvZ6KB8oVQAE0Tq8UjqotL0rT+ZoxA7Nnho5j622XC46kA xpUg== X-Gm-Message-State: AFuF++lt9V4lA8fPbXtF68+WnnUeKmvpuDlwOHURwkA0tNxk+IAPFgTH B6NWV107WschRCVadVADvLegvTanUY1lvz7eLvJl9oGphd+uqPyUPAVP0MAQrzkPOA== X-Gm-Gg: AYBFou30LdQ8f/3EIrlFtPK4EQ+IsnkKfjxVcXnrn/L04qu/a59ipyxChoT7quH6qXl CDw0AQMygIYUhM+8U36CkWGEy4yvDjao4laGMCENkFL3Ys/pzfW6U2POYb51p6xORK1r8q0BaBJ 34KDkQzorRfrqG/IbBUjkUMlpbQVM8Nx5NXJcsRlwfHO+nxZHsFg0SIEm4ue9cRwpCPvNbD2FHZ JNiw45T3t83VgwMlB2WUQ6vIushewkGelqnMDaZwhbWn5HZjO3OvvCQ01YOZh0nl6owUEg/Vr7j gLPtdXJQS22LBeJdplcNOlnN6MKKwBQbJhV/vKLe9zuAcWxNrXxe/XEzrdIvJM/sHHNy2ZZwtXB UutxlAjVEbVfur4/FmupxeTI9WCKBCLie4PTdDFnY6KYFwqIXdpzyH48a0Ltgu/HZKKKMy6qI/B WP+cMiawhjAMvqI4115eTtnIrae7TIJGPgSdQ9PeE37O9e8lSi33zjgNumJlSmIMXj1dhhRGbT2 S9S01rk70dP5YqKIcjpWs7y/mCy7kXZ1ZZSGSto1fAGV0ZJJyiO X-Received: by 2002:a05:600c:8b29:b0:49c:ee22:364c with SMTP id 5b1f17b1804b1-49cf824743cmr48972775e9.9.1788510816744; Fri, 04 Sep 2026 01:33:36 -0700 (PDT) Message-ID: <879f5184-351e-4f12-947b-d66eef5fee77@suse.com> Date: Fri, 4 Sep 2026 10:33:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3@vates.tech> 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: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1788510817-BE07B757-C627DF4F/0/0 X-purgate-type: clean X-purgate-size: 2872 On 04.09.2026 10:26, Baptiste Le Duc wrote: >> @@ -329,6 +333,169 @@ int arch_domain_create(struct domain *d, >> return rc; >> } >> >> +static void save_csr_regs(struct vcpu *vcpu) >> +{ >> + /* >> + * There is no need to save these CSRs as only hypervisor writes them in >> + * restore_csr_regs() and guest can't access them so they shouldn't be >> + * stored here. Keep them commented here just for symmetry with the >> + * restore CSRs register part. >> + * >> + * vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); >> + * vcpu->arch.hideleg = csr_read(CSR_HIDELEG); >> + * vcpu->arch.henvcfg = csr_read64(CSR_HENVCFG); >> + * vcpu->arch.hcounteren = csr_read(CSR_HCOUNTEREN); >> + * vcpu->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); >> + * >> + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + * vcpu->arch.hstateen0 = csr_read(CSR_HSTATEEN0); >> + */ >> + >> + vcpu->arch.hvip = csr_read(CSR_HVIP); >> + >> + vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS); >> + vcpu->arch.vsie = csr_read(CSR_VSIE); > > >> + vcpu->arch.vstvec = csr_read(CSR_VSTVEC); >> + vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH); >> + vcpu->arch.vscause = csr_read(CSR_VSCAUSE); >> + vcpu->arch.vstval = csr_read(CSR_VSTVAL); >> + vcpu->arch.vsepc = csr_read(CSR_VSEPC); >> +} >> + >> +static void restore_csr_regs(struct vcpu *vcpu) >> +{ >> + csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); >> + csr_write(CSR_HIDELEG, vcpu->arch.hideleg); >> + csr_write(CSR_HVIP, vcpu->arch.hvip); >> + csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); >> + csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); >> + csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); >> + >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); >> + >> + csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); >> + csr_write(CSR_VSIE, vcpu->arch.vsie); > > >> + csr_write(CSR_VSTVEC, vcpu->arch.vstvec); >> + csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); >> + csr_write(CSR_VSCAUSE, vcpu->arch.vscause); >> + csr_write(CSR_VSTVAL, vcpu->arch.vstval); >> + csr_write(CSR_VSEPC, vcpu->arch.vsepc); >> +} >> + >> +static void ctxt_switch_from(struct vcpu *p) > Is it expected to have diverse names for the vcpu arg? Above it's vcpu, > here it's p (I assume it's for `previous` but I think the _from alone is > enough to understand) and below it's n. Shouldn't be better to keep the same name? Context switch code is special, and using p and n can be warranted there. Everywhere else it should be v, nothing else (and I said so to Oleksii more than once before). Unless, of course, multiple vCPU-s come into play at the same time. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 04 08:50:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 08:50:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408034.1640768 (Exim 4.92) (envelope-from ) id 1x2Pcy-0000Z4-0t; Fri, 04 Sep 2026 08:50:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408034.1640768; Fri, 04 Sep 2026 08:50:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Pcx-0000Yx-Ts; Fri, 04 Sep 2026 08:50:27 +0000 Received: by outflank-mailman (input) for mailman id 1408034; Fri, 04 Sep 2026 08:50:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Pcw-0000Yn-Id for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 08:50:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Pcv-004rRH-V2 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:50:25 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a863b-2eae-0a2a0a5409dd-0a2a4507ec8c-44 for ; Fri, 04 Sep 2026 10:50:25 +0200 Received: from [13.59.128.245] (helo=basilisk.relay-egress.a.mail.umich.edu) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a864a-b4ea-0a2a45070019-0d3b80f5e6a8-3 for ; Fri, 04 Sep 2026 10:50:19 +0200 Received: from suasive-ogre.authn-relay.a.mail.umich.edu (ip-10-0-74-242.us-east-2.compute.internal [10.0.74.242]) by basilisk.relay-egress.a.mail.umich.edu with ESMTPS id 6A9A864A.816EEAA.1B782D84.689335; Fri, 04 Sep 2026 04:50:18 -0400 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by suasive-ogre.authn-relay.a.mail.umich.edu with ESMTPSA id 6A9A8649.16713475.6C8EB235.144331; Fri, 04 Sep 2026 04:50:17 -0400 Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-3a305310ddaso8010501fa.0 for ; Fri, 04 Sep 2026 01:50:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=fail header.s=relay-0 header.d=umich.edu header.i="@umich.edu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-0; t=1788511817; bh=RpTRgDXJK5Wxk10Gj6RuFNHrhmtCcKQUHfCBSm7zYiw=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=icRyUrLNdMuNv4bEHcmvNsLJPVRxdvT/D+8QrKSlYO9zWFPWGXKbEsyieHr4ttvko A2+3CkQlnWPbtkhhDmUQgA6WDZZDq5HNmZUkg1/Z8Zcq46iCnzbjXorIrdNo730aO0 ljKqWe3HVpaoxai2QYa28oaQh60e2K3tQ1W9cvho2EsM0DdVS3neLbRihO9K7AUc/h Equ8Ga4zRr6VklRArZYFolmvBe/iBCen1bwUwk+HYslfNFqvanhjxyyDEAYJgHxVLO K5ortZ8lh6nGZoNJWTof0K3mA/ppRoz1+9WNmHGJ/o1LQTQnv55lFavD/nNNnv+1vY EJCCyWvJSS72Q== Authentication-Results: suasive-ogre.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.208.170 (mail-lj1-f170.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvBw4MQTpokQZx2FPwLWfdGxxFCabqnysq4Ebyedur/D+os/f/WkmvCdCsemq8KeWU2tC68719QyUEiM=@lists.xenproject.org X-Gm-Message-State: AFuF++nRopGMQTmL48hYWT21bmkeUu25ItGdYkrUOVtmERcZiuByrsiM 7yA5zYL9yA2q5L2IdjG7OsyuI/ISTw8RWwI34XLdTvbLSZyV6Iy+58Mgzkcbzxpo8IPnWZT4OSn 5ddd/Vk2JeM5pZ65IFwo1nzFxTD5OR2k= X-Received: by 2002:a05:651c:1544:b0:3a3:10f:5a28 with SMTP id 38308e7fff4ca-3a371baa417mr5412661fa.11.1788511815101; Fri, 04 Sep 2026 01:50:15 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> <050f44ec-47e5-4754-b73b-1173458736b0@suse.com> In-Reply-To: From: George Dunlap Date: Fri, 4 Sep 2026 09:50:02 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1WJwUt15jj3yGFul9RfemX7H3C7yaQ4RBKWFTPr8e04EwtEBb5Tc-aR3b8 Message-ID: Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1788511824-378D1AE4-C8EF93AE/0/0 X-purgate-type: clean X-purgate-size: 2409 On Fri, Sep 4, 2026 at 9:29=E2=80=AFAM Jan Beulich wrot= e: > > your position here is really inconsistent: You wave > > away a partial pagetable walk with three map/unmap operations on the > > context switch path as something we'll have to do in the interim, and > > can optimize later, but are now threatening to make me add in > > special-case codepaths and run tests to save a few memory reads and > > shifts. > > I think you misunderstood. There was a concern raised already on v1, > and that concern wasn't covered by the patch description. In my initial > reply I said "Functionally the change looks okay to me" for a reason, > after all. To quote Andy's mail: <<< So what this patch is doing is still keeping the double copy (the fragility) but reintroducing the expensive part of the operation into the context switch path. If you can't keep it being L1e, there's probably no point keeping the optimisation at all. >>> Basically what I took from this is; - Andy thinks stashing any intermediate form (whether L1E or MFN) has a technical cost (two copies that could potentially go out of sync, thus "fragility") - Andy thinks that the expensive part of the conversion is the MFN -> L1E conversion, not the vaddr -> MFN conversion - So, stashing the L1E might be a win, but stashing the MFN is unlikely to = be. - If we're not going to special-case this path, we have to pass an MFN; and if we're going to pass an MFN, it's probably better to just to get rid of the stashing; the extra fragility introduced doesn't pay for itself in terms of potential performance improvement. Note also that by the end of the series, we add two more populate_perdomain_mapping() calls to the context switch path, at least for ASI domains, which means another two of the "expensive" MFN -> L1E conversions. So v2 is doing what I understood Andy to have suggested. I agree the meaning isn't 100% clear, though, so I may have misunderstood him. As I've said, I'm not opposed to optimizing this path once we have the final form functional and have measured it. Mapping the three tables we need to modify in vmap, and stashing both the addresses and pre-baked l1es, sounds like a perfectly reasonable thing to do, *after* we get things functional and have had a chance to measure the new context switch in its entirety. -George From xen-devel-bounces@lists.xenproject.org Fri Sep 04 09:34:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 09:34:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408061.1640777 (Exim 4.92) (envelope-from ) id 1x2QJJ-0007p0-4W; Fri, 04 Sep 2026 09:34:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408061.1640777; Fri, 04 Sep 2026 09:34:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2QJJ-0007ot-1k; Fri, 04 Sep 2026 09:34:13 +0000 Received: by outflank-mailman (input) for mailman id 1408061; Fri, 04 Sep 2026 09:34:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2QJH-0007on-Gt for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 09:34:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2QJG-00FgcY-Pg for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:34:10 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a9084-8faa-0a2a0a5109dd-0a2a450298a0-44 for ; Fri, 04 Sep 2026 11:34:10 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a9092-6ca4-0a2a45020019-b9ff1c23af71-3 for ; Fri, 04 Sep 2026 11:34:10 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06bc4a637000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 09:34:04 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 08E2F839EC; Fri, 4 Sep 2026 11:34:04 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=ZhX4EDNIARcb8Zbx+r+dJ/oX+jhrQpz7grwjIaOmJ6I=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=rcp+M/lOv3UklJupfHaP51ZgUKgoxy53lk+0nSuFMnBvikWBBf8/wcqsO4xmRLyjTwhYFwREc 9sZvrx7fOh6NnQ8MG8YjueU9DwLX+xUKFUUGomwNHnhqX2BR1UyPOtjrJlNNAERcezXpXvdcGIG Mg8dF5V0uNDTZU/XhHNoAJezdLRNp4Qjk5UduBsHACndVen+BG/i1w3n4thJvJJ07xQm3vhLwRp LPufJV8awBQMKHU2GDDvs9H5GdDA0yGAP9+HDzMi5hQcrSH/GOFVBmaawP4kIr/PWc9wGVrTP89 mai9b6zthSYIHNhoUPuJnitGvoyEJlTkSaDqENVBuTFg== X-Zone-Loop: 5a9a9e85e6eaf96390b19eeefac478a68e8c99480998 x-campaign-type: default x-transaction-id: 9f619beb-d758-4c96-b549-7f1b729655df x-swg-uid: 01-3ce68425-65b8-4ac0-88f4-743cc9e7b5ed X-Mailer: Sweego Message-ID: <1788514444.8631fc262581453bbf619ec5b2062170.1a06bc4a637000c4f3@vates.tech> x-swg-bid: 1788514444.8631fc262581453bbf619ec5b2062170.1a06bc4a637000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 4 Sep 2026 11:34:03 +0200 From: Anthony PERARD To: Julian Vetter Cc: xen-devel@lists.xenproject.org, Oleksii Kurochko , Community Manager , Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" Subject: Re: [PATCH v5 09/11] x86/dmop: Add XEN_DMOP_{,un}bind_pt_msi_irq References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> <1788444859.8631fc262581453bbf619ec5b2062170.1a0679edb8f000c4f3@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1788444859.8631fc262581453bbf619ec5b2062170.1a0679edb8f000c4f3@vates.tech> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3656.11dda1aec1cb4d89.1a06bc4a3c6.89ab1ff4e9f21543=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788514444230 X-purgate-ID: tlsNG-720697/1788514450-F14AE2AC-B8522344/0/0 X-purgate-type: clean X-purgate-size: 8118 ---=Part.3656.11dda1aec1cb4d89.1a06bc4a3c6.89ab1ff4e9f21543=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2026 at 04:14:07PM +0200, Julian Vetter wrote: > Add two device-model ops that bind / unbind a passthrough interrupt to a > guest MSI from the raw MSI message (address + data) the guest > programmed=2E Xen decodes the message itself via pt_irq_bind_msi(), so t= he > emulator needs no knowledge of the MSI layout and, in particular, > extended (15-bit) destination IDs are handled without emulator changes= =2E >=20 > The MSI-X table base is passed as a guest-physical address=2E Fields are > named msg_addr / msg_data / pirq, and the flag is > XEN_DMOP_MSI_BIND_UNMASKED=2E The unbind op only requires a valid pirq > mapping, not current IRQ permission, so an emulator can remove a binding > even after the device has been deassigned=2E >=20 > With this in place, PT_IRQ_TYPE_MSI is removed from > XEN_DOMCTL_{,un}bind_pt_irq (returns -EINVAL) and from > pt_irq_create_bind()=2E libxc's xc_domain_{update,unbind}_msi_irq() and > vPCI already funnel through pt_irq_bind_msi()=2E This is an incompatible > change for device models still using the domctl sub-case (noted in > CHANGELOG=2Emd and public/domctl=2Eh)=2E "Incompatible" you say? Is there any patch for QEMU that I missed? > libxendevicemodel gains xendevicemodel_{,un}bind_pt_msi_irq() (map > version VERS_1=2E5)=2E >=20 > Signed-off-by: Julian Vetter > --- > diff --git a/CHANGELOG=2Emd b/CHANGELOG=2Emd > index aa1a777dd4=2E=2E76f5d06c91 100644 > --- a/CHANGELOG=2Emd > +++ b/CHANGELOG=2Emd > @@ -34,6 +34,9 @@ The format is based on [Keep a Changelog](https://keep= achangelog=2Ecom/en/1=2E0=2E0/) > - On x86: > - Enable pf-fixup option by default for PVH dom0=2E > - The libxenguest bzImage loader now uses the system liblz4 library= =2E > + - XEN_DOMCTL_{,un}bind_pt_irq no longer accept PT_IRQ_TYPE_MSI, devi= ce > + models must bind passthrough MSIs via the new > + XEN_DMOP_{,un}bind_pt_msi_irq, which carry the raw MSI message=2E > =20 > ### Added > - Support for per-domain Xenstore quota in C xenstored (includes > @@ -47,6 +50,9 @@ The format is based on [Keep a Changelog](https://keep= achangelog=2Ecom/en/1=2E0=2E0/) > - Support for CPIO microcode in discrete multiboot modules=2E > - Introduce get-core-temp command to xenpm to query CPU temperatures= on > Intel platforms=2E > + - XEN_DMOP_{,un}bind_pt_msi_irq for binding passthrough MSIs from th= e raw > + guest MSI message, enabling extended (15-bit) destination IDs for = HVM > + guests whose device models opt in=2E Also: - Introduce xendevicemodel_{,un}bind_pt_msi_irq() stable ABI as replacement of the unstable xc_domain_{update,unbind}_msi_irq()=2E ? > - On Arm: > - Support for guest suspend and resume to/from RAM via vPSCI=2E > diff --git a/tools/include/xendevicemodel=2Eh b/tools/include/xendevicem= odel=2Eh > index 227e7fd810=2E=2E698d719119 100644 > --- a/tools/include/xendevicemodel=2Eh > +++ b/tools/include/xendevicemodel=2Eh > @@ -375,6 +375,36 @@ int xendevicemodel_nr_vcpus( > */ > int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid)= ; > =20 > +/** > + * This function binds a passthrough interrupt to a guest MSI, describe= d by the > + * raw MSI message (address and data) the guest programmed=2E Xen decod= es the > + * message itself, so the caller does not need to interpret it=2E > + * > + * @parm dmod a handle to an open devicemodel interface=2E > + * @parm domid the domain id to be serviced=2E > + * @parm pirq the pass-through IRQ (pirq)=2E > + * @parm msg_addr the MSI message address, as programmed by the guest= =2E > + * @parm msg_data the MSI message data, as programmed by the guest=2E > + * @parm gtable the MSI-X table base guest-physical address, or 0 for p= lain MSI=2E > + * @parm unmasked if non-zero, leave the IRQ unmasked after binding=2E > + * @return 0 on success, -1 on failure=2E > + */ > +int xendevicemodel_bind_pt_msi_irq( > + xendevicemodel_handle *dmod, domid_t domid, uint32_t pirq, > + uint64_t msg_addr, uint32_t msg_data, uint64_t gtable, int unmasked= ); "gtable" I fell like it could have a better name=2E "guest table" feels a bit generic and not really describing what the parameter is about=2E So is a name like "msix_table" or "msix_base" or maybe "table_addr" since we are in the context of msi or something a bit more descriptive? I'm not completely sure what the MSI-X table is, so there's maybe another name that would better described what the value is=2E If you still think "gtable" is good enough, so be it=2E Next, "unmasked", this one sound like it should be a `bool`, not an `int`= =2E > + > +/** > + * This function unbinds a passthrough interrupt previously bound with > + * xendevicemodel_bind_pt_msi_irq=2E > + * > + * @parm dmod a handle to an open devicemodel interface=2E > + * @parm domid the domain id to be serviced=2E > + * @parm pirq the pass-through IRQ (pirq)=2E > + * @return 0 on success, -1 on failure=2E > + */ > +int xendevicemodel_unbind_pt_msi_irq( > + xendevicemodel_handle *dmod, domid_t domid, uint32_t pirq); One last think on the header, could you move both prototype to just after "xendevicemodel_inject_msi()" ? It feels like that would be a slightly better placement within the header=2E > #endif /* XENDEVICEMODEL_H */ > =20 > /* > diff --git a/tools/libs/devicemodel/core=2Ec b/tools/libs/devicemodel/co= re=2Ec > index 8e619eeb0a=2E=2E274a8eb28b 100644 > --- a/tools/libs/devicemodel/core=2Ec > +++ b/tools/libs/devicemodel/core=2Ec > @@ -645,6 +645,44 @@ int xendevicemodel_nr_vcpus( > return 0; > } > =20 > +int xendevicemodel_bind_pt_msi_irq( > + xendevicemodel_handle *dmod, domid_t domid, uint32_t pirq, > + uint64_t msg_addr, uint32_t msg_data, uint64_t gtable, int unmasked= ) > +{ > + struct xen_dm_op op; > + struct xen_dm_op_bind_pt_msi_irq *data; > + > + memset(&op, 0, sizeof(op)); > + > + op=2Eop =3D XEN_DMOP_bind_pt_msi_irq; This memset and first assignment can be replaced by: struct xen_dm_op op =3D { =2Eop =3D XEN_DMOP_bind_pt_msi_irq, }; ;-) > + data =3D &op=2Eu=2Ebind_pt_msi_irq; > + > + data->pirq =3D pirq; > + data->msg_data =3D msg_data; > + data->msg_addr =3D msg_addr; > + data->gtable =3D gtable; > + if ( unmasked ) > + data->flags |=3D XEN_DMOP_MSI_BIND_UNMASKED; That "data" variable feel a bit useless, and badly name (arguments or parameters would have been a more descriptive)=2E I know that how the rest of the file is styled, but I'd like to propose something a bit cleaner and initialise the struct with all the values: struct xen_dm_op op =3D { =2Eop =3D XEN_DMOP_bind_pt_msi_irq, =2Eu=2Ebind_pt_msi_irq =3D { =2Epirq =3D pirq, =2Emsg_data =3D msg_data, =2Emsg_addr =3D msg_addr, =2Egtable =3D gtable, =2Eflags =3D unmasked ? XEN_DMOP_MSI_BIND_UNMASKED : 0, } }; There's already quite a few use of this way of initialising the parameters of an hypercall in the different libraries=2E > + > + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); > +} > + > +int xendevicemodel_unbind_pt_msi_irq( > + xendevicemodel_handle *dmod, domid_t domid, uint32_t pirq) > +{ > + struct xen_dm_op op; > + struct xen_dm_op_unbind_pt_msi_irq *data; > + > + memset(&op, 0, sizeof(op)); > + > + op=2Eop =3D XEN_DMOP_unbind_pt_msi_irq; > + data =3D &op=2Eu=2Eunbind_pt_msi_irq; > + > + data->pirq =3D pirq; > + > + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); > +} Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.3656.11dda1aec1cb4d89.1a06bc4a3c6.89ab1ff4e9f21543=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 04 09:52:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 09:52:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408081.1640786 (Exim 4.92) (envelope-from ) id 1x2QbI-0002tR-MQ; Fri, 04 Sep 2026 09:52:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408081.1640786; Fri, 04 Sep 2026 09:52:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2QbI-0002tK-Je; Fri, 04 Sep 2026 09:52:48 +0000 Received: by outflank-mailman (input) for mailman id 1408081; Fri, 04 Sep 2026 09:52:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2QbH-0002t2-5X for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 09:52:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2QbG-000Gro-IY for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:52:46 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a94e5-2eae-0a2a0a5409dd-0a2a4501eb44-22 for ; Fri, 04 Sep 2026 11:52:46 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a94ee-5984-0a2a45010019-b9ff1c12ab33-3 for ; Fri, 04 Sep 2026 11:52:46 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06bd5af1a000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 09:52:41 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 6082681E3D; Fri, 4 Sep 2026 11:52:40 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=oh0Pic75LjmuMBRY5biuLPlwwJnSlqaRYHrkWEjVNhc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=QKihKJvtPGI3dZp1oxHr+iaZgTSgFor/CpM9eLxq2aZU3YSJe9L5kkYDGQhA3VWoKm44h34/9 TO3bbbpHi9HHykVUAwzLkdlsthecCcvoMKXB1FYxTZdBHYBGM2rQLmDOEt+aU3bCqyXn60J9498 Vje5Eu6rHZXKa5HR+sZhEJXlmsSqyTQaCwcD9m5NMuz07OIeGykj83aEs6luYmMsd4SFmrxus5T Qdj3rMR+FV4vJMvZXo+X7a9FlRPgxl05qGtcUZ2eqx/7M4uQO9+eJHWLp2bqPkl6d9W8ttKFI8L 5As9zpZT7Tom+rveSHHxCNeOP8xCHiVCxrJDrc2RINFw== X-Zone-Loop: 0f46c0819f053f1bbe06fc4eefee6dc1131ef80c9cfa x-campaign-type: default x-transaction-id: 0ef9cccf-d8bb-4d1f-ae69-56b1e2f1a5b3 x-swg-uid: 01-d34b1307-53de-4127-b984-65510d0b9bc4 X-Mailer: Sweego Message-ID: <1788515561.8631fc262581453bbf619ec5b2062170.1a06bd5af1a000c4f3@vates.tech> x-swg-bid: 1788515561.8631fc262581453bbf619ec5b2062170.1a06bd5af1a000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 13/39] xen/riscv: save and restore AIA state on vCPU context switch From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <32e8b81fd276498cfd339defd2720bce1745c1cf.1787838835.git.oleksii.kurochko@gmail.com> References: <32e8b81fd276498cfd339defd2720bce1745c1cf.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 04 Sep 2026 11:52:33 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788515560; l=1870; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=jVdEJA7XxA1Zo1E7Jkr6lOMuDxyXkrIMYrhpKXqJGE8=; b=U0yulPbVMBLOTWTI0Tnlkk/11lNf8cDV3RAziJsc5zWmHipoh3i+nWo4T4fnRnaCiWsfDplCp ywHNZl3AlFpDaVY3H88vfSv7SKwMhtBZlXE22gAtS06Wkdu5PDrHa5K X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788515560599 X-purgate-ID: tlsNG-d62444/1788515566-1DE78757-73FD793A/0/0 X-purgate-type: clean X-purgate-size: 1870 > vsiselect and hviprio{1,2} are per-hart CSRs which a guest can change, so > they have to be part of the vCPU context: Where in the spec did you see that? Because in AIA spec section 6.3.1, it is written that "When vsiselect has a value in the range 0x30-0x3F, an attempt from VS-mode to access sireg (really vsireg) causes a virtual instruction exception" and this even when hstateen0.CSRIND is set as hstateen0 just control whether a guest/S-mode is allowed to access a CSR (exactly as you described below). Therefore, the hypervisor has two options to modify the priority of a major irq: - emulate the iprio array in software. - Use hviprio1/hviprio2 (only 10 irqs configurable). But the guest shouldn't be able to modify h CSRs at all, in any case, or I may have misunderstood a part of the spec. For the moment I don't see any catch of possible instruction exception in do_trap(). > - vsiselect is written directly by VS-mode through siselect; > - hviprio1 and hviprio2 hold the priorities of the local interrupts which > VS-mode reaches through the iprio array of vsiselect/vsireg, so writes > the guest performs there land in these CSRs. hviprio1 and hviprio2 hold priorities for interrupts 1 (SSI), 5 (STI), 13 (counter overflow), and 14-23 (local) so calling all of them "local" is wrong. > Without saving them, one vCPU's selector leaks into another vCPU's vsireg > accesses and one guest's interrupt priorities apply to the next guest which > runs on the same hart. > > Whether the CSRs may be touched at all is gated by hstateen0 when Smstateen > is implemented: SVSLCT for vsiselect/vsireg and AIA for the rest of the AIA I couldn't find any reference to SVSLCT in the spec. I assume you wanted to refer to CSRIND and SVSLCT is an OpenSBI's own nickname. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 04 09:54:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 09:54:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408087.1640795 (Exim 4.92) (envelope-from ) id 1x2Qcv-0003VC-Vt; Fri, 04 Sep 2026 09:54:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408087.1640795; Fri, 04 Sep 2026 09:54:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Qcv-0003V5-Sq; Fri, 04 Sep 2026 09:54:29 +0000 Received: by outflank-mailman (input) for mailman id 1408087; Fri, 04 Sep 2026 09:54:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Qcu-0003Ur-Py for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 09:54:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Qcu-0092Ov-6d for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:54:28 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a954d-8faa-0a2a0a5109dd-0a2a450ab106-22 for ; Fri, 04 Sep 2026 11:54:28 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a9553-f2d2-0a2a450a0019-b9ff1c128dbd-3 for ; Fri, 04 Sep 2026 11:54:28 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06bd7377a000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 09:54:21 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 118EB81EB6; Fri, 4 Sep 2026 11:54:21 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=uZD6jJUcLoY+mEEZW5wJpobOUMsM9W/orYnzbQB9pGA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=LY+f5ytmquDM501jpoACTM9p0pesthwiegjiUDDTHrzC2fAt/vxTWnqWDqgIPVKPqUK6dQFQX XC245nUKIHfDtBP8sJhr/9ex31YqMqGF2ehNzFbpSCd/Cnx8s9Icdp69POKzzqsV/vt95ynMcNS f41bExHS1N2NdLLawRBwtuOUr/2CZnnPHG5crDlHdyqMK1FF0lwJ2nW2V37cPCrG8E4kP3lL9QU k2061TPota4L4/41Qosrs2JkEcypb9nOEKCai4G7OM0aikgAtwiKl4JpIbegSeUG77n5+jV9NJ/ r7QPxIjKVza9JBlGJLNuqYveqozb1hblMexDOMmNN+Zg== X-Zone-Loop: 14f1b4d8c55f5ebc9f2e112a1f4219ec9097393cb9a1 x-campaign-type: default x-transaction-id: 904923c1-51b9-4678-8e45-08dda6e60329 x-swg-uid: 01-71ceb5c2-3b67-4765-ac14-4cabadabbe9c X-Mailer: Sweego Message-ID: <1788515661.8631fc262581453bbf619ec5b2062170.1a06bd7377a000c4f3@vates.tech> x-swg-bid: 1788515661.8631fc262581453bbf619ec5b2062170.1a06bd7377a000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko In-Reply-To: <879f5184-351e-4f12-947b-d66eef5fee77@suse.com> References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3@vates.tech> <879f5184-351e-4f12-947b-d66eef5fee77@suse.com> Date: Fri, 04 Sep 2026 11:54:15 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788515661; l=3112; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=K50ozWfZ0P41kpUGQt1K6dV1u1eFyXN7s/k/WlXl3bk=; b=YCMXznEfqWTzs7gv1S0wTDYMreUyTNYn1BUFxEqaZYGFklLZnK0WpHrbb6BhtF+rEpGZrMC9T g7Ti5r/z7//Bi18HdYpg14t/B9Rz2soV4Rnxd86/03I8n/qie2iU05A X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788515661260 X-purgate-ID: tlsNG-4011c0/1788515668-5ABD8CFC-81469E43/0/0 X-purgate-type: clean X-purgate-size: 3116 On 2026-09-04 10:33 +0200, Jan Beulich wrote: > On 04.09.2026 10:26, Baptiste Le Duc wrote: > >> @@ -329,6 +333,169 @@ int arch_domain_create(struct domain *d, > >> return rc; > >> } > >> > >> +static void save_csr_regs(struct vcpu *vcpu) > >> +{ > >> + /* > >> + * There is no need to save these CSRs as only hypervisor writes them in > >> + * restore_csr_regs() and guest can't access them so they shouldn't be > >> + * stored here. Keep them commented here just for symmetry with the > >> + * restore CSRs register part. > >> + * > >> + * vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); > >> + * vcpu->arch.hideleg = csr_read(CSR_HIDELEG); > >> + * vcpu->arch.henvcfg = csr_read64(CSR_HENVCFG); > >> + * vcpu->arch.hcounteren = csr_read(CSR_HCOUNTEREN); > >> + * vcpu->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); > >> + * > >> + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > >> + * vcpu->arch.hstateen0 = csr_read(CSR_HSTATEEN0); > >> + */ > >> + > >> + vcpu->arch.hvip = csr_read(CSR_HVIP); > >> + > >> + vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS); > >> + vcpu->arch.vsie = csr_read(CSR_VSIE); > > > > > >> + vcpu->arch.vstvec = csr_read(CSR_VSTVEC); > >> + vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH); > >> + vcpu->arch.vscause = csr_read(CSR_VSCAUSE); > >> + vcpu->arch.vstval = csr_read(CSR_VSTVAL); > >> + vcpu->arch.vsepc = csr_read(CSR_VSEPC); > >> +} > >> + > >> +static void restore_csr_regs(struct vcpu *vcpu) > >> +{ > >> + csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); > >> + csr_write(CSR_HIDELEG, vcpu->arch.hideleg); > >> + csr_write(CSR_HVIP, vcpu->arch.hvip); > >> + csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); > >> + csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); > >> + csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); > >> + > >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > >> + csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); > >> + > >> + csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); > >> + csr_write(CSR_VSIE, vcpu->arch.vsie); > > > > > >> + csr_write(CSR_VSTVEC, vcpu->arch.vstvec); > >> + csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); > >> + csr_write(CSR_VSCAUSE, vcpu->arch.vscause); > >> + csr_write(CSR_VSTVAL, vcpu->arch.vstval); > >> + csr_write(CSR_VSEPC, vcpu->arch.vsepc); > >> +} > >> + > >> +static void ctxt_switch_from(struct vcpu *p) > > Is it expected to have diverse names for the vcpu arg? Above it's vcpu, > > here it's p (I assume it's for `previous` but I think the _from alone is > > enough to understand) and below it's n. Shouldn't be better to keep the same name? > > Context switch code is special, and using p and n can be warranted there. > Everywhere else it should be v, nothing else (and I said so to Oleksii > more than once before). Unless, of course, multiple vCPU-s come into play > at the same time. > Ok noted, thanks for clarifying that. > Jan > > > From xen-devel-bounces@lists.xenproject.org Fri Sep 04 10:02:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 10:02:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408096.1640804 (Exim 4.92) (envelope-from ) id 1x2QkI-0005NP-N9; Fri, 04 Sep 2026 10:02:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408096.1640804; Fri, 04 Sep 2026 10:02:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2QkI-0005NI-Jd; Fri, 04 Sep 2026 10:02:06 +0000 Received: by outflank-mailman (input) for mailman id 1408096; Fri, 04 Sep 2026 10:02:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2QkH-0005N4-Bg for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:02:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2QkG-003qXy-KM for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:02:04 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a9712-e002-0a2a0a5209dd-0a2a4504c95c-42 for ; Fri, 04 Sep 2026 12:02:04 +0200 Received: from [40.107.130.92] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a9719-b57f-0a2a45040019-286b825cfccb-3 for ; Fri, 04 Sep 2026 12:02:01 +0200 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11) by DB9PR03MB7626.eurprd03.prod.outlook.com (2603:10a6:10:2bd::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 10:01:58 +0000 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292%7]) with mapi id 15.21.0360.008; Fri, 4 Sep 2026 10:01:58 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BDFFr5AYkEVn5UZY4BCRZ/oUEdAPWByXtDmlIA0y1jo3hzr0SjDS+D2ZIIVYdtAHTZkNklTBIL6+x6O307VXslOVhFFKAXfRVtYUbU8Ob0Sw0baQ5b3k09etmv07p5kGzOkBQTiLMFQBqWwj4rkS9UiR7sgB4JKvv9OBi+BYOs/8CjKN0uOoIbRyxwBpwnUDPqZ489QSRc5LfachVomfss9sqMkX/GtF9dGzH5TS/gDDEwOfi4bE/AO/TGuhGfiu4fZeFLFgMPSErpxNwdu/pVpghwY/g/Zp9Bk0bHx1+np8e587Sref1JoFSGnuwslTUikSPp5PubZ3HhnLOUyr6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gWH369CGsQvS0nR81kZ/CVOnsZJb88aK0T8wC501PWA=; b=kxuXJ6Y/sad5a5hkBA0k24qCHaEtjDdwvyb6whZ4r8Dnw/NtKsuv9ugy0RZAO2fJlG3fIZ7pm8qL9OAJDPQgdYT/L4X7/PCFqnwYa9HjWKOs/7NrbWRYqC8LIXRQBv888aJxWrm3u03h/+ZpspinjcAEvRK/ZCPrY+TkPGCtM7lH+B0Gj4kWs9eE51HO+L5zPAhX2SNnKwjD56/RAH9TUgo0mGLToB8fIm/W6jhCMiIvB5F3k9y4Yb6UwItQ7cDrZCz+jFyTgWDihXHzD4aiUuITHLCFmwfLXtrKuHl2ytrenZ0dwqyYdbKEXqBPuRc6fC2fKTIXBM945rTcLMBo/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gWH369CGsQvS0nR81kZ/CVOnsZJb88aK0T8wC501PWA=; b=R2jiT5i6sEC+D1IVWLWghYjtw6oSPRkIwSmZVMLkJeO8B6tW/xQ9k3rXAWdCj3OOEe92Qz6G80E/qZGCdYqJAys4lqj+WzhQg2Bik7o4dz/2p2GmZxMsqL21ox7U46qZ/7jE7vV2+AV0iu0RqHOJELAdOs4bIT1AcHqtjGz0Xf5B1K/hIZLiAS/zNpJtMpGYxrvytZ+NtcNY3QcHQu54HSD2ZsF5OIihR9+323a4q31LdoF+FaI0tqeQ/eMmp0UjZM53VqkBnlegNMewiupeyztDd13u9XYxwr2SsClld5H8zVEQ34Zu+Qz5OiHGMaaR4v3S7oO3uslrI5OsqocsGw== From: Sergiy Kibrik To: Andrew Cooper , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , "Daniel P. Smith" Subject: Re: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels Thread-Topic: [PATCH v1 2/2] common: dom0less-bindings: introduce XSM labels Thread-Index: AQHdNgfAHPmcI5IBhUGZU0o2oDVW1La3+D2AgAZEiwA= Date: Fri, 4 Sep 2026 10:01:58 +0000 Message-ID: <4839ad1a-f75d-4fc2-90fc-6feea58e7ef6@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS8PR03MB9192:EE_|DB9PR03MB7626:EE_ x-ms-office365-filtering-correlation-id: 82614880-3af5-43b9-aa50-08df0a6b8f07 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|22082099003|18002099003|56012099006|38070700021|6133799003|11063799006|4143699003|10067099003; x-microsoft-antispam-message-info: P99fDfVDaMe4gMFul3mDr81M0iSMuq0+7r8XQsZvi2a/pXc9RuE2v+qDE171NfB+WK5q3mSivOMA2CAugRNPbw6/cuySDvrPIiIbiPNY9t9AqtgVfyU2rA3SZJLfvxHgsmxkuNxMlOQWT8Dpk9TEGGlD9wZJ45tAT1VdEmaFbn/Ejlu2t0tJvWnurRMe5YTx0eIAW5zKn0jPvft5kSIYD8j6mafEZ2avBf0Yv+dyqfkrF/zeEHtp1F00jKLzMZf9uFugS9BMv2p7EFBQfLNayP1NFc1h7KHPsqe1+RnrugSmKywi99Y0LHBYtm98b8GP41YN8oojQuC28kA6XjPfvURdDa+QMS6zLQkoleimeH2/YA2Vw7J3p82ZNidmXXL0OkPdOl4s3ivI+PEq4Amk4Y+Ia4FBTnVRW/G21qznb69KQE+L2Gw/eWOkcaeor60OWYmiBqrJtDlVgU7zvN49/9ox1H5uNy3a6ZlBqmSYjGgg1IvBBB1Cvjdo0huBR22jfULB/PHl4VbHq/pmXa1IX579m1lzWrJN5rZL0bXpthr0ZXyVEVEPR4tHqGUoKYFS7AqjEVYQW3Ika8Sb8CBXff2pPfpYMtqhhR2vPa7KA0T88UQiWcjjChRHkvPwP2wO7FmSdcJuNs0Ss5ooL/FlMSpKeV+DdVumslMTQuNYIjruII/5qLDhYtn6bAtEGm7mFQCMOyud3kPnjigtzYBAm4HzgKeTmzu+KSjsX4ScpTE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(22082099003)(18002099003)(56012099006)(38070700021)(6133799003)(11063799006)(4143699003)(10067099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RS90cGppdDlCa3Q3bXI4NkhpL3FtbFB1NCtzcXVlY1hXTmQ1cWpxS1FFcTNw?= =?utf-8?B?ek5HVlU0emtmYjhqS3lKUkJWdFRyQ3o3WGtGcVhzZnU3V1Y2YUxPem5DMTMz?= =?utf-8?B?ZVE4NUdIRXg4OEhkcXdTUEg5cThzMC9LMC95QnBuQ3FOTy9UVE9uOTM1R0lr?= =?utf-8?B?MCtIbkZDSThncWRmR0lvOEZlcEd4Y2NYNTdhR0NjOGg0WlJVVlNLanBrZmsr?= =?utf-8?B?Rll1NXVXaDJVWWRjaUl3WCtoU2NsVGh6M3NvdUY5QnFvblFXTGt4UmxyYVBo?= =?utf-8?B?bTZUK3djN2IvNXQrM1lXc1RSdEVQd3hHSm9NaWlZL0R5NjFHNmJoNUhFRysw?= =?utf-8?B?c2JyZEwveTU5WFhVVy91b2FYaVBMRnViNHkyQ3NFeitWbVg2dWpKQWRmUVJp?= =?utf-8?B?dDF1d1FPL1hQNXdzM1VqUWQrSG1pdDRkWVJERzJOMUNpUUVHOWdXNmpKcDBT?= =?utf-8?B?S0kwVjBPdlN4Yi9LeFEyRFVwS3FNaE4zR1VtekdxUUZoUHY0ZlhtNjdKQm1Z?= =?utf-8?B?K09NTk5lRUlCdDZZQVd1RHVVNTZTbXM0NFNHMGg5Zk9MTWxOQit1Nzd5OU5q?= =?utf-8?B?VGs3ZEY4MGJqQWk4UmtOdEtIWFo5dlptS29ydmt6VUZoajZvZ0FsbUlUVmZh?= =?utf-8?B?dFRLRHVJSWVkVW93cWFBbVI1Vnc5Wnp3Z2I2OHhhdW44V1dZK2VmZE9FU1NL?= =?utf-8?B?WlZGckJXTzdZM05Dc0wyRmJGTzQ3cnYyR0o3OTh1WDk1S0U5UjE3VDVoc0xK?= =?utf-8?B?M2ZaOUpRcWljWDNGS0treFRmTG1QV3FybEQ3ZE00WDNsMTIrbnpGc0l0d01l?= =?utf-8?B?MHRUaTF0VWNMKzJ0UGRzRG43NmN6N3l5SjZvVkdmaHQ3bUJraCtUOUZOR3Ax?= =?utf-8?B?T2I3NEVFNmVWanV1eEFCQ0kyOTR3NjJ6NVdzMTVubWRraW93STlrZnRYeUVR?= =?utf-8?B?Y1l6NXUybGxYWXlRV0VvRFc3a0NPZEhCUnFsRDRidXM3UytFeG5iM3dHYmFN?= =?utf-8?B?dXRqY0R3cXQ2TmxRZk9iK2VPdHZaN3YybVdTcmxMbGlxRHN5a3J0M2dKSUp2?= =?utf-8?B?dUVidVNGT0lWT2p4bFF3eGJWaU9CUDIxQ0p6d1RORFpTUk5lMUVFWFl2bFda?= =?utf-8?B?Y2x6cFV5bm9RQU50cDY4QUQ0ZE5IRjZZc0dQZGt4eUZ2NVRWUGcxeDVDcGEx?= =?utf-8?B?bEowWGlTaTg1L1Z0cEczK3VkdzM1K1ZXT3ZmYUNvdHFMSGpZUzVlNkFoMVpm?= =?utf-8?B?SHgyamx1S1MreDNXWTR6TndyakN1T2hvL0w4UHVVZ0l1NVZwbUF3aEJKTWNu?= =?utf-8?B?N29FdWw5NmM1V3dRWEdBWlMzQ2REVkFPZVZwMVpldkF0azhTM2RxdE5kLzBs?= =?utf-8?B?Nk1pQ0dqZ2E2VWRxUG5ja3dLYnBWYWpmVVM1eThsZWNDc1hmSko0dlczdkZ1?= =?utf-8?B?cjZkZDVzeU8zeTFKcUJEa0J4YVl4WDRVdXBkOGU0L2svNkJISmJyTElXaUFJ?= =?utf-8?B?ZG1oeTdoVUF3anByWnp2S3BRS3BxRXNwQXYvbU96R2hjODRjT3gvK2wrZDlm?= =?utf-8?B?eWtDZmhVaUtySENvK1NBMGMxeGNqa2FTOU9vN0cwbzNSMGlSTjZkZVJCSFhx?= =?utf-8?B?QWxJVGVuRUJiRkZ0U0x4K1dZVUlwbitPM0NaWm9XcmlQU2dlUkpWUUlnT2lG?= =?utf-8?B?ZWx2aHoxSHBKYysyc3NaOGw0NFJRTTJ6b2JYTGhFbTh3RUlEd0VPS1RnS2xR?= =?utf-8?B?MTlReThtd1ROU01WWDYxZnlKcnNNVVdRNUJKdHNDOGhtQXRmNzVrVSt5Zm9U?= =?utf-8?B?Uk16aTlaQXBjcUkyeitEM2UxL0U0UzNSQnZrRlZtbjBwZ2ZXanNodGdtUVJk?= =?utf-8?B?Nmp1UXh6VzlXQVJHcG1JRmR6TlhhWjlSSExDWFpRbkFhNlRDM0Z2UVZwVE9X?= =?utf-8?B?ZEpoUGlsb2k3KzBEUm9IV3dENnBjMDkzUWZHTmVsVzhxanJZeGFLZmRKd2ZY?= =?utf-8?B?dXQvYVROY1ZDa3RNTGY1RzRCb3pNMU5kVjc5U2NwdlFheWdxem5Od0pyaWcy?= =?utf-8?B?SUxFN2JaK3E0NTF6d3VqS1JxZVY0aWxUR0VyUUpldEtaSTI1ZHkwTkVNdU9B?= =?utf-8?B?UkZtbS80dFBDZzhlcGcxcFNkWndYYVMxOWE5V21YVFpEaWFXYU5xL1NuVGIr?= =?utf-8?B?QVVmZnNKM1VDdnhwQmdiU2ZMUCtTUHpjWVdjMmxEaHI2Nk1kZko3Q1k2b1FO?= =?utf-8?B?NWZwT0E3OFNCaDFZWXdZTEM5RGJ1dDBiQVBxTVZvTUR3MGtaRXlBUWJ2VFhr?= =?utf-8?B?L3BRQWlRS0VkOVZCZWtBM090aDdGSDNUVE5keWFIczR6MkJrdWxQWmUzeGdh?= =?utf-8?Q?Dc1XCLKKFFD/5RcI=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <3B51CFA91BC2DF49BCC147FED3F01B92@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82614880-3af5-43b9-aa50-08df0a6b8f07 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2026 10:01:58.7254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eH8MoPvKJAlD8YKHuR7mfZ+hfYZ1bEaqDjIl7lZeRnqJete1BCt3hZUHvv8nnz+1uQlqfH5IN1iygcM/esFjzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7626 X-purgate-ID: tlsNG-ebf023/1788516123-C36C2B50-6DD0866B/0/0 X-purgate-type: clean X-purgate-size: 768 T24gOC8zMS8yNiAxMzoxOSwgQW5kcmV3IENvb3BlciB3cm90ZToNCj4gVG8gdGhpcyBzcGVjaWZp Y2FsbHksIEknbSBub3Qgc3VyZSBzZWN1cml0eV9jb250ZXh0X3RvX3NpZCgpIGhhbmRpbmcgb3V0 DQo+IFNFQ0lOSVRTSURfWEVOIGlmIHlvdSBoYXBwZW4gdG8gY2FsbCBpdCB0b28gZWFybHkgaXMg dGhlIHdpc2VzdA0KPiBiZWhhdmlvdXIuwqAgSXQncyBjdXJyZW50IGNhbGwtY2hhaW4gaGFzIGFu IGVhcmxpZXIgY2hlY2sgd2hpY2ggSSB0aGluaw0KPiBleGNsdWRlcyB0aGlzIGZyb20gb2NjdXJy aW5nLg0KDQpJdCdzIG9ubHkgY2FsbC1jaGFpbiBpcyBpbiBGTEFTS19DT05URVhUX1RPX1NJRCB4 c21fb3AgaGFuZGxpbmcsIGFuZCBpdCANCmRvZXMgcmV0dXJuIFNFQ0lOSVRTSURfWEVOIHRvIHRv b2xzdGFjayBpZiBjYWxsZWQgYmVmb3JlIHBvbGljeSBpcyANCmxvYWRlZCAoSSd2ZSB0cmllZCBi b290aW5nIHdpdGggZmxhc2s9bGF0ZSkuDQoNCkJ1dCB3aGF0J3MgdGhlIHBvaW50IG9mIGZhbGxp bmcgYmFjayB0byBTRUNJTklUU0lEX1hFTiBhbnl3YXk/DQoNCiAgLVNlcmdpeQ== From xen-devel-bounces@lists.xenproject.org Fri Sep 04 10:12:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 10:12:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408118.1640813 (Exim 4.92) (envelope-from ) id 1x2Qta-0007cr-Jd; Fri, 04 Sep 2026 10:11:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408118.1640813; Fri, 04 Sep 2026 10:11: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 1x2Qta-0007ci-Fj; Fri, 04 Sep 2026 10:11:42 +0000 Received: by outflank-mailman (input) for mailman id 1408118; Fri, 04 Sep 2026 10:11:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2QtY-0007cU-F9 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:11:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2QtX-0097Qv-6L for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:11:39 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9a9948-bab6-0a2a0a5309dd-0a2a4505e76c-44 for ; Fri, 04 Sep 2026 12:11:39 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9a995a-4cb1-0a2a45050019-d155dd31f050-3 for ; Fri, 04 Sep 2026 12:11:39 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-4858303de5dso1025403f8f.2 for ; Fri, 04 Sep 2026 03:11:38 -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 ffacd0b85a97d-485885c5bbdsm4911880f8f.36.2026.09.04.03.11.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 03:11:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788516698; x=1789121498; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Tm/ie6BzhM/m68G6nNkLdfn5xrpN4kaLJzeUG30OYRM=; b=cWwxkVerjGRvLTjnhypxPOQkZz5hHl4cfjt8lQQl+IjVXar6jWXxxKAmoOZkOuHtkL f6B3e2qB4rgTDq8GbViDa2uHh2O7iMnA1zqIRT0NcFKSUSUjp99KZ0NGB6xTjPIS4I81 0P+/z4fSCPftcpqamsD39NIlq7LcSpbr/sxyA4mWZ5+XXd76HCktqBUeZ0AH3TPU06iv WHiehabS7HQWYAP7gBZtJFxJ0OLJkA/vNXX/o0vFPylEI/To48q9MTj3nhW0MTTJ5Lg2 53ctAM8HjycPA15j9At2tsbElvu0r6Xj4Hiy7oMGxG3E+w+1faCUA2QXSxRxoXjxj/kH VYyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788516698; x=1789121498; h=content-transfer-encoding:content-type: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:content-type; bh=Tm/ie6BzhM/m68G6nNkLdfn5xrpN4kaLJzeUG30OYRM=; b=AcnSXwGEUYOWChUNTowYTlYVl3oKfe+rli+XAER7tAoww6yvLHUkiRxUMY6AF/9L4x ccYRdBb6cGCDMg9VUvmLdToCAThVUQIiPCyXAw88jDijEEzYS6nINMm82rWjm3eRDrm6 q/zmACt7eb8FtlswCptXk0dRjhgGWCwQYyoeS0/MKSdPx/ftp9JO8zu8ixlcrmclY346 TiIQC6wTAZFH5pve6Hguysu+zILafaSFjLcUwJTlWa1zbWKlc5FYLwUlQNSQqOrlzjUm tUzrgTeuTZuAMhr8cqllwzu9EkJk9jexB4L03Ao4W/i6injQjJan8iT3mKd3boEgEbf1 ie4Q== X-Forwarded-Encrypted: i=1; AKwUvByg1nd86OQSWcNZIoF/rA5Tooq9t5bWa9o1tK2vOJAzo6wjaDQ2+VhsNsTsMBp9vwTqA0Cx6GorG1M=@lists.xenproject.org X-Gm-Message-State: AFuF++nKRK8yAv3zVxLC8il8I74cWYMY8XPwpPMwU42kj0DWAfIzva1h EMwYyx/4nR34e1ZV75KsklCK95mn5yfC0TmKLp+1r684u4UI9vUdC7JMdsyZEJP11w== X-Gm-Gg: AYBFou1rbj8Nrasu40yJQjtO547yTjwWcGmeV7FRNrZeOagDh5wZ3XGM2hsmrWMMUSu JB8i0sHxTSEerzt4XSUFQOfyrwpC31vJ/UCiWeh2GdctcDYFOQxjVpcDySzqEEne4EMTh+pSMvA 6WfDnH0M9eBQEbwNTlLQhHVHGgaDmyI1GsZVgT09DZQg4jiR3d4mVUVwtZnr7Nuxzx2HbSLdxml wm1a5qTrZAOSZLkX1V7Xmp+ovnbBClGb2KFjr6UhJ1q0whrKuXV68mc60cFEDrvEMpG777gkNi1 2pmvAX+aIIX6ta2U/uIhGo0Dv93oH+bcPOHgKcRgEfUDRQ/Jlr0VzYH2tsUOxWTvYeRkG+rQbdX C92PMGIi/0+ook/SMok9rW7fM51nNxdizoNPazrQwgeX3yyU1q0mNUbfy962c7wCT8wELaoO7Zh ZpaimcFCma19jhCMQ9FyUNTJa8CQYDVTaF2nQ3yZbyybXSyBegf9bMbwMOfeHbbNSQ8an9IjBNT 9yPEUeEvLB+5i1BaYqdmPa4o6yOYIXhuF1tkYSFYQVDz/Gipi2o X-Received: by 2002:a05:6000:1a86:b0:485:8c16:a332 with SMTP id ffacd0b85a97d-4858c16a74cmr2175953f8f.39.1788516698432; Fri, 04 Sep 2026 03:11:38 -0700 (PDT) Message-ID: Date: Fri, 4 Sep 2026 12:11:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> <050f44ec-47e5-4754-b73b-1173458736b0@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: 8bit X-purgate-ID: tlsNG-c201ff/1788516699-F76BD2A1-1F9F4119/0/0 X-purgate-type: clean X-purgate-size: 2898 On 04.09.2026 10:50, George Dunlap wrote: > On Fri, Sep 4, 2026 at 9:29 AM Jan Beulich wrote: >>> your position here is really inconsistent: You wave >>> away a partial pagetable walk with three map/unmap operations on the >>> context switch path as something we'll have to do in the interim, and >>> can optimize later, but are now threatening to make me add in >>> special-case codepaths and run tests to save a few memory reads and >>> shifts. >> >> I think you misunderstood. There was a concern raised already on v1, >> and that concern wasn't covered by the patch description. In my initial >> reply I said "Functionally the change looks okay to me" for a reason, >> after all. > > To quote Andy's mail: > > <<< > > So what this patch is doing is still keeping the double copy (the > fragility) but reintroducing the expensive part of the operation into > the context switch path. If you can't keep it being L1e, there's > probably no point keeping the optimisation at all. > >>>> > > Basically what I took from this is; > > - Andy thinks stashing any intermediate form (whether L1E or MFN) has > a technical cost (two copies that could potentially go out of sync, > thus "fragility") > > - Andy thinks that the expensive part of the conversion is the MFN -> > L1E conversion, not the vaddr -> MFN conversion Iirc later, when discussing with me and Roger, this was somewhat adjusted. Unfortunately the outcome of that discussion wasn't put in a reply there. > - So, stashing the L1E might be a win, but stashing the MFN is unlikely to be. > > - If we're not going to special-case this path, we have to pass an > MFN; and if we're going to pass an MFN, it's probably better to just > to get rid of the stashing; the extra fragility introduced doesn't pay > for itself in terms of potential performance improvement. > > Note also that by the end of the series, we add two more > populate_perdomain_mapping() calls to the context switch path, at > least for ASI domains, which means another two of the "expensive" MFN > -> L1E conversions. > > So v2 is doing what I understood Andy to have suggested. I agree the > meaning isn't 100% clear, though, so I may have misunderstood him. > > As I've said, I'm not opposed to optimizing this path once we have the > final form functional and have measured it. Mapping the three tables > we need to modify in vmap, and stashing both the addresses and > pre-baked l1es, sounds like a perfectly reasonable thing to do, > *after* we get things functional and have had a chance to measure the > new context switch in its entirety. And I (largely) agree. What I'm asking for (beyond feedback from those who were involved in putting in the optimization) is that the removal of that optimization be justified against the original commit's reasoning. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 04 10:35:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 10:35:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408144.1640822 (Exim 4.92) (envelope-from ) id 1x2RFv-0003ak-Bo; Fri, 04 Sep 2026 10:34:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408144.1640822; Fri, 04 Sep 2026 10:34:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RFv-0003ad-8x; Fri, 04 Sep 2026 10:34:47 +0000 Received: by outflank-mailman (input) for mailman id 1408144; Fri, 04 Sep 2026 10:34:46 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RFu-0003aX-FG for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:34:46 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2RFp-005Byc-1n; Fri, 04 Sep 2026 10:34:41 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2RFn-00691q-2j; Fri, 04 Sep 2026 10:34:40 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=+WrzhoduP1bP6kQ8Lwg20f+ZXsuoOWUee0/yquDukw0=; b=40UD1XPxdhaAjx4kZTNkJrRbOb eQ6r1NVU88MzVRaUoCPx0Pqh+4bcLnA0IPb9SW09wHTEg/B8VvhTtVa3RTTCvtq+c7sw+36jUEWu+ UcsM9HNWcMVNag+efU3TGNdzJIULtHCoC8slqEp0TeHI7gx1rOJqfimtRA6RAaL+amTg=; Date: Fri, 4 Sep 2026 12:34:37 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: George Dunlap Cc: Jan Beulich , Andrew Cooper , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT Message-ID: References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> <050f44ec-47e5-4754-b73b-1173458736b0@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Sep 04, 2026 at 09:50:02AM +0100, George Dunlap wrote: > On Fri, Sep 4, 2026 at 9:29 AM Jan Beulich wrote: > > > your position here is really inconsistent: You wave > > > away a partial pagetable walk with three map/unmap operations on the > > > context switch path as something we'll have to do in the interim, and > > > can optimize later, but are now threatening to make me add in > > > special-case codepaths and run tests to save a few memory reads and > > > shifts. > > > > I think you misunderstood. There was a concern raised already on v1, > > and that concern wasn't covered by the patch description. In my initial > > reply I said "Functionally the change looks okay to me" for a reason, > > after all. > > To quote Andy's mail: > > <<< > > So what this patch is doing is still keeping the double copy (the > fragility) but reintroducing the expensive part of the operation into > the context switch path. If you can't keep it being L1e, there's > probably no point keeping the optimisation at all. > > >>> > > Basically what I took from this is; > > - Andy thinks stashing any intermediate form (whether L1E or MFN) has > a technical cost (two copies that could potentially go out of sync, > thus "fragility") > > - Andy thinks that the expensive part of the conversion is the MFN -> > L1E conversion, not the vaddr -> MFN conversion We later discussed this, and the assumption was that the expensive part was the vaddr -> MFN translation, as that's where PDX is involved. I expect crafting a PTE shouldn't be expensive at all, but maybe there's something I'm missing here. The original patch cached the MFN in an attempt to not remove the optimization, because my understanding was that the possible expensive part was the PDX translation. Then again I don't have real measurements to back up any of the claims above, and hence it might all be plain wrong. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Fri Sep 04 10:50:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 10:50:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408184.1640831 (Exim 4.92) (envelope-from ) id 1x2RV9-0007Qw-LG; Fri, 04 Sep 2026 10:50:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408184.1640831; Fri, 04 Sep 2026 10:50:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RV9-0007Qp-Ig; Fri, 04 Sep 2026 10:50:31 +0000 Received: by outflank-mailman (input) for mailman id 1408184; Fri, 04 Sep 2026 10:50:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RV8-0007Qh-Bx for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:50:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RV7-000Wyd-MZ for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:50:29 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa262-8faa-0a2a0a5109dd-0a2a45048648-34 for ; Fri, 04 Sep 2026 12:50:29 +0200 Received: from [52.101.48.17] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa273-b57f-0a2a45040019-34653011e6fa-3 for ; Fri, 04 Sep 2026 12:50:28 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5284.namprd03.prod.outlook.com (2603:10b6:a03:223::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 10:50:24 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Fri, 4 Sep 2026 10:50:24 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wE/a2HEsqmz4r07Esf0V3v4D8Uf2nKKwNgkqAF11tKReRu3bpbMImZ+c5Y+KmDpFBxGtbqv1YiSMvyhYOVYOiTbSlwxwk/5r1OMHD4L/A3Pb5pw3G2ut5ONxkVwbBKT6nB6DhCLFnMuQXkZO36gI4w0vTYq2QghkE4r2Z+y/SgWCrbS9Dj8svJdnZY9dLuDxbh/ud0HWNSWKXZ81d5YDjcnLuniLBCoeYTsumHxSU/bLpu+I1Ybc+n3e99RilXx1jW1oNyg/getXnrtN8eJsc2x53vdjHhpxHMX2GKS7+87zM8J+ICUtT0BBiTpjr99D3UeCsjnDdpuAF5TzZK7ANQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bZy08fihcHui52eWaPycF6G1OtxD4ooUz9UDdrNVDOg=; b=VsYzo7GSdZyKSlyKPgxOrgYqRfdSD/XdmgeJTl3uHZoII/GGG8DABoOmL0cMNcHoiPxmLkAj/DsaoSDZ+/YgPDHBOl3OhUH20Pkf38rh0SG6nFKddcTIukpS+x2bufpQrfUnQe06Lm4hwxbKcjBxGMUS9wJPYRv0Y7FL0MwNqYA1zzgHVz9rwALnOBWSeC8pWYFKdBvHSbdkzH4K8prBx5QGy2oUqP+hQp9waSUFaxjO41NLDObvZe1VwCLTNDi8aNFp1TPbbk32ofOBKJ4utBJ7pPp08nxte1KmL7n52gKvEXQHCq4r1xjj75yq/wBNEi5961w0eSQiKM5mHFz2Yg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bZy08fihcHui52eWaPycF6G1OtxD4ooUz9UDdrNVDOg=; b=ygc4yNGikCBZAUG065YSIqxz/WGSWJiFuRl0HEPbtqG6KzmAmLrcC7PmFVaflc57lfQcRFUEbydH0z/3u2ckEDdx0EJkdeXgtxxcQouak2JDB5yzhfuzoGufHWAOhd6/OCw5+9nlMUjKjIERSbhoxqzTQNTva+Nab5larNAWGJ8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <85b0b35b-b790-4c06-a61b-330f5e913adc@citrix.com> Date: Fri, 4 Sep 2026 11:50:20 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH 4/6] xen/arm: Rewrite arm_smccc_smc() for arm64 To: Bertrand Marquis References: <20260831121944.2908139-1-andrew.cooper3@citrix.com> <20260831121944.2908139-5-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P123CA0106.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:139::21) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY5PR03MB5284:EE_ X-MS-Office365-Filtering-Correlation-Id: e40d9aa5-fde0-4777-3036-08df0a7252ee X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|11063799006|56012099006|4143699003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: tVPwqhhnWrxIWI0EQYXZpfnOoXmuUJ+g78IKFatDp0UNi6yXC3kEZldneL7ZAXdDaX9drRMub7uogVE0Yw8aQcbRf0dYQ5K6VdIhFrVBzwjFt9Vqs27GwYe51n90TV6WsoS2siUKPN6pNwvLwKlYANwo+ke5tXD7uKAUBlJ4FBinKgMQnCqVM8YO9pU9JFe74s8G/4dO9pHDjvxxyGsZzDQgY8z61LX8PgXqVmTRBocqUX4ES4YPrjryUDsQSWV7ofri+4M87tDB7mf2whP7M/UDPSfCuLW3U/tG/uLqSJ4HrqnbDa/z662wcZA8tN+F7x+Qyf8uCKQMKqTTizybDVMnNL3QQGpjQltX1T4TDk7PuWgUIr6dQj/3S4pXMfuW/vTwmQIgtSvMx5MJ5XnppngWaREoJhnZtOGxMvqkErX0FBdY9UFz8ZWfduUuxMzw1lypotxrgQ1EKMWEX17kQzfs8+cMgUfNMU6siS0bxEWzAGJzKMRa+Sb1FYKb/hf65a9a6825cU4yq6Rq+HFaivTJcq4ugtKEhG+Xutnh25aUtkbNzt9iNkvh5udrL99Y1a7e4SFaLhJ1G9tc5UUoQ3K+a63SvuJlMKLrs4yUiWncu1gtS1qdYJHUE5o7h4MMgl0my+B+GaO3VKtNklHLzg43TnKw6WZp2GtKNhX2/ik= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(11063799006)(56012099006)(4143699003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SEdoMk13MHZ5Uzgxemo2Q3ozaDRyWUVUTXJMZmo1d2hORjFGSVJmQUM2RGIz?= =?utf-8?B?ekp3NjlObXdwODhpaEVPWi9lcGFZSTA4QXYrZ1pQMzcyc1VJY1NzenBqeDAx?= =?utf-8?B?RzFjN3RibUFDZ3BGc2dUVXRrS0h6YmV0bFdsTWp0ZU40VjFlNWI2NnZVdjJ1?= =?utf-8?B?MVB4eHZmZnd2U1drbUtLQWlBaEgxK2FoaDROKzhxRHZGZFVaMlFJejVNT0ZY?= =?utf-8?B?V3JsdDMzaWdJc2Z6UmhiLzRibnNKYnd6N2s1S1o5MXpNSnZiNzVBaytTenNU?= =?utf-8?B?bUJ2UHE3d0l3ZXY2SFF1V3o2RkNIRnQwRFhZYitTRE5IM0F1VVl1QlVrKzhZ?= =?utf-8?B?RjJkMmVGQnBNV0lLTDZpaERvVnBCOWdORVlIVVNUa3RyWEtTM0kwUytYcy9h?= =?utf-8?B?K2taVGhrVzUvSnhkVHZCV01RbHYxVEthd25ydEgraFRPVDF2RHk3OE0yazFw?= =?utf-8?B?ZTM3cGRKRTNUSThwMEcvZkNpYUxuVFFHNnZCbnNEek9YSE51Nktja0g1ajJo?= =?utf-8?B?TzhUMXI5dUYya1lZVkgyTy9XZ0IwUzl0WE96ZTQ5Y1NLYTRLeHNtL0FFSXdj?= =?utf-8?B?c1loaHNTSHkwYTBTMEJzZ08xZmNtS2x5bzUwY01wR0VOSXUvZW9qaTJCMTB2?= =?utf-8?B?MDcxYUNSTFhwUUx5VFhZcjczbHd4YXNlVFV5cUpZRGVVR0JoWGtIelFNY2ZR?= =?utf-8?B?d1ZkU1VjdzdZV0wyYm90ZlFkdjBhSERvdlpNaU9ycVBVbE5JOUtpci80dU9q?= =?utf-8?B?eUpQZ3hpWWRpQVYxSVplSTNNaU14ckk4ZW81MDFuRWpwdGdQMTNERDVuR2pF?= =?utf-8?B?UDZZWGdQa1kwSnk4QjRHYnlmZFliNXJyZUtNQ0l2L2E4TnNJdnNxeksyNXYz?= =?utf-8?B?NEpRNFpBQytqR0lOcXNkZnZmNlZjVUZ6MmZZMGZrV2FZMnVpZGhZTGhJRHBm?= =?utf-8?B?SXRaNnlnMGk2dDVBRE1HaXlobGJWVEY3UmFWV25DVlZxUzh2UUlsMjVwRDdp?= =?utf-8?B?WEtnME10VlE4bTQyWUFVdU9aOCtEMGp2SGJOV3pTYU90TUh4R2hqOWsvWnEx?= =?utf-8?B?QytmeDQzUVlTSDBRcjhLY3dWQXZGMFJKZ2NGcVBiRmUyRkNORUxLcldBMnV2?= =?utf-8?B?OWRNc3FoTDR2T0JUeWxwWGFEMW1Td29MRVRBM1JSR2tQK0lhSExtZGE0R3Yz?= =?utf-8?B?WUlsdTA3MHUvUmRUVWZMZ2wwWWJIUXVIQTVvSzNHd0IwcHgrdEMvdElBaHlF?= =?utf-8?B?bU9MR0dYbmpXaDlrSWxCempCMVIwU2lHYzhKM2huRlVoMldvR2NtZTFQQm05?= =?utf-8?B?aVhFSk1CNWJGejl4OGNwM2ZSeHpsYUkvd1ZGRmloWDhFcUlxZ2ZHYTU5NmYv?= =?utf-8?B?QTFubnlSSkRNby9hRVorRS96ZUFyM3hXSkplbFZMMmdremI5VHhzclp6VDFH?= =?utf-8?B?THNHTmIyWGltZGdSVi9ZUER1akNJUXpORDhsSm1SVktDdjU3TnFqSlh5cXZQ?= =?utf-8?B?dkF3Z0JwWElMZTRUVHFlWkdsVkNzb0k4RzRFMU0yQ3NVWGJCSTNLaGlhOXpu?= =?utf-8?B?eGRJUVNDR1k3ZEFSUGIvQ2F0eWZKUVNYeWVKNmE1cER0RmhxcU0vNGRLVWp4?= =?utf-8?B?Z0pmSXl6UEpPSXdXK3Q3RC94YmlEYzlTNTlrYVNrN2c4SzFkVWdlekcyTlhj?= =?utf-8?B?MjlsSllJRXM2TnViN09SUlFtaUtXMWhCLy9tSkY5UjgybU5qWkhiUlBMb3lV?= =?utf-8?B?eEdSREVVSWtuZnZBTUgrbFREbC9UdnY1Rkc1bmZxcVp1WnpjNU55dlVTSFZa?= =?utf-8?B?bjhqam9BSWYyclFsWnhnWDZsdzVBNVpkU1Z5YTlCMUtTcXprYnMydnZBTG44?= =?utf-8?B?YmJ1ZFVZTVF4ZGRHa2l1OTIrSGZvbUFMTEdXV25qVU4yNDhZdWRIaHJ3TXNV?= =?utf-8?B?UkRwYnBxcXlxeG1TOXgwT3RHUzAweW1XT0dKaWpCV09ZNWJUdjZWRk1WL0lp?= =?utf-8?B?SGNtSU1JSTR1UEVCU0p5aFlLcUNjL2o4TmFpUjUvdXp6d0owY0o1ZG9XTHZn?= =?utf-8?B?ZjdKcS9UVFZIMjlSUWdsZFlFQVpvYlluWCt5QXdmalJZZm0rTWhPb3h5Qm1D?= =?utf-8?B?Z1pyclJLRS9LUDAyTHB5ekNLQVMzVHVucEtUQUF0K2xBNHpHbGZoMlp4S3U5?= =?utf-8?B?akZPNmpWdjBXWjhFaFp3UjZOK3hQMUM2ZDVqUlNJNS9zaW9sOUxNeTZta3JN?= =?utf-8?B?eFdNMUJ4Mkc1U2o3RmxTVjNlbDh5LzhpT29sQXdtVlRDaEZ6SXppWVd3RzEv?= =?utf-8?B?d0R6TjJJN2JaTFMzcUhiMk01RWl2Mmhhc3NRYXhGTVRKRjFaR1hGdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e40d9aa5-fde0-4777-3036-08df0a7252ee X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 10:50:24.4627 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WygajGKEu6BboiAXz3cc4lvtOTK/xTx9eCFl19o1+ePqu8ZSw2Ifwlg6jezIOs2SmJYdn4Vd9DgtMBtn9NbjHN1hWnGiZkolp67kPH/aWU4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5284 X-purgate-ID: tlsNG-ebf023/1788519028-532CCB50-CF2EBEBA/0/0 X-purgate-type: clean X-purgate-size: 1199 On 03/09/2026 1:16 pm, Bertrand Marquis wrote: > Hi Andrew, > >> On 31 Aug 2026, at 14:19, Andrew Cooper wrote: >> >> PSCI v1.0 says that x4 thru x17 may be clobbered. PSCI v1.1 says they are >> strictly preserved unless they contain return values. > I think the PSCI reference here and in the rest of the commit message and the patch > should not be used and should be SMCCC references instead (which would also be > more coherent with the fact that this code is not PSCI but SMCCC and is used by > others than PSCI). > > PSCI does not define the preservation rules, this is defined in SMCCC spec and we > have a way to detect the SMCCC version. > > SMCCC defines the following rules: > - 1.0: x4-x17 have an unpredictable return state. > - 1.1: x4-x17 must be preserved. > - 1.2: x4-x17 may additionally be defined as result registers, otherwise they remain preserved. > > So the commit message and comments should consistently say SMCCC instead of PSCI. > > Other than this the code is right i think. My apologies, I've clearly got confused somewhere.  (This is the first time I've ever looked at the SMCCC spec.) I'll adjust. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 04 10:58:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 10:58:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408194.1640840 (Exim 4.92) (envelope-from ) id 1x2Rcx-0000Kb-DS; Fri, 04 Sep 2026 10:58:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408194.1640840; Fri, 04 Sep 2026 10:58:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Rcx-0000KU-Af; Fri, 04 Sep 2026 10:58:35 +0000 Received: by outflank-mailman (input) for mailman id 1408194; Fri, 04 Sep 2026 10:58:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2Rcw-0000KN-9T for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 10:58:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Rcv-009KnI-Ig for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:58:33 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa447-e002-0a2a0a5209dd-0a2a4506d45c-48 for ; Fri, 04 Sep 2026 12:58:33 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa459-195a-0a2a45060019-d1558036bd48-3 for ; Fri, 04 Sep 2026 12:58:33 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49556f97a9dso7521675e9.1 for ; Fri, 04 Sep 2026 03:58:33 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cf5135353sm75680345e9.2.2026.09.04.03.58.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 03:58:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788519513; x=1789124313; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=i57gQ4hHTz9nn2etSSfO8Ur/ahMB8XJeGd2KMq8acjY=; b=ZqQWVTT4MJLFApEm5Ct6moLihM/xwJ82DWWoNozSe6WBGdcomko4CZfjOIOJK/Exsa 8YU8KGegQWihpjv0vo0ctRU9yQyXdo7oxznX/f0jRKI8ciHdfE5bgKp8BYABEJDzkFcY vnZ+61XXp3i961NaWgRjPyjbPJ670RBOhA71Et8Loq0GeAWg82N3ouRrJLX98F9b/Uy4 7y1qachccMsGXQoIdQAsDM6k4Gg8j+DQ1Nvsc6ZB8v918rL+sPFrZXm4fV/Cg/HWtKQu J62mA7jxIHaUwMRWd4pMMIgCdmk0+fFBOoSpMl+OMkDsidCv5eSozpPhyhxtBuC5GzuQ wwUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788519513; x=1789124313; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=i57gQ4hHTz9nn2etSSfO8Ur/ahMB8XJeGd2KMq8acjY=; b=aTByl+cDWQqL5zzizYbetFY0LI2bzTWxLB7eXFmNVyM3MizBl8S+4M9OC2AI5FCQ5Z nUCcdPwwyvo2ijEvZrrkyFqBMzZAU3DIi2wPZveprro5KkZimqT+0S8YHI7XmD+q4UaI yawHaE3XwJNKWYQoa63HamPh74L5FhYz72Bh2jAXHCPYWU9tpUnYzJuyqBAEvHl7NUyp l8tLMvGK+73nF/hmSilY5P+Tu4o7PWbtB6Pe2ESn3T/123cDntdITULIlERTHVDtcLmI qg9f2Yic9GV8kCRGwg66un/JFAACRVr9+H+fjaM6tQHa8iFKN3j9nrSP3IttAOY8a5a2 0fyg== X-Forwarded-Encrypted: i=1; AKwUvBxmT3iJcBJvZBrn7U+xAG77a4sYI8I8b3PMtO7iSHM4oPUsrSVuNceIhmiiJGL7EgVeT2Zk6yzmxTY=@lists.xenproject.org X-Gm-Message-State: AFuF++lKrmXgQaazipAYhloU2pXfq57iFKiCOaXQ2c9xES/jJ4eqS0za 6pZFshdWLbZ6W4bRUxZfQA7zdCn636fKYEIiPQ2p6sDAJhm3M0f4QbKe X-Gm-Gg: AYBFou1G6Sqoo9HWg8icWcF8fZubp1GghudSKpZ1aNuK30kvDhHzwmX29fhh1hS8t+l 3fDniXQd8F7ai/ALcTcMhkHa5W2KaqVlFibVflwsfAM8MMch5381V/znG/Mg6xk4pJC5YWA7EvR vlzVXG5qnM2NgTl/HaGNXO2dwe5mXyhc3dfwoj76f4v24lnRK+OzMqFd1igFLR4p5hrqJd2rBZB Mnfv1cFQDRULLMwthD8DmERxOuMh2GY26TcUaLAU5zxJ7b2pxTCSRNyZffp9QdWRItoa3ZXhdx1 6Q469mWIlJ56ZsK7El1kCJdojh7PSgVWUPpfsdk4h9ZYk2qhAHZNIjagpJSUlzm8tWpGZIuz540 6D6DMdZcjQep3qDG76aC6zcFF6SYnCPFgS4XrKdF4Ta3YhlJ1eZaHXpmR0RNu6xuL4Jk5+Uj4vu Elk+X7ZG9NfNl+EvLzg1TD7UsRF8eB0KWjlBa9VVXY1x9bM1S/4JvchqBzThijUujUL05Q001P7 wwSlnCQWIFfkdBMpArYxgWlLEcd1PEeQJis1pA= X-Received: by 2002:a05:600c:a4b:b0:499:4e47:eaf2 with SMTP id 5b1f17b1804b1-49cf824020amr45273535e9.6.1788519512736; Fri, 04 Sep 2026 03:58:32 -0700 (PDT) Message-ID: <6e807532-4cd5-410f-b073-99b58a40733e@gmail.com> Date: Fri, 4 Sep 2026 12:58:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 16/20] xen/riscv: implement IRQ routing for device passthrough From: Oleksii Kurochko To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: <0cf2c9f6-5fba-4d1e-a9cd-e2a409730efa@suse.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1788519513-FD80D77B-1F1578F9/10/73395122804 X-purgate-type: spam X-purgate-size: 3512 On 9/3/26 4:39 PM, Oleksii Kurochko wrote: >>> +    do { smp_rmb(); } while ( test_bit(_IRQ_INPROGRESS, &desc- >>> >status) ); > > I am thinking if a barrier is in correct place or needed at all. > > Considering that desc->status is updated under spinlock() which uses > full barrier the result here should be already observable without > smp_rmb() inside do {} while (). > > Probably we want to have load->load between test_bit() and a read of > action->free_on_release in if () below but I don't see what could go > wrong if this read will happen before do {} while (). > > xvfree() (stores inside it) can't be executed ealier because of control > dependency [Rule 11: b (xfree) is a (action->free_on_release) store, and > b has a syntactic control dependency on a] so again it looks like a > barrier isn't needed here. > > So considering what kind of barrier is used inside spinlock + Rule 11 we > can just move smp_rmb() after the cycle (just in case) and it looks like > smp_rmb() is only here just to force compiler not to order the things > considering how action->free_on_release is used: > > static void irq_release_action(const struct irq_desc *desc, >                                struct irqaction *action) > { >     /* >      * Wait to make sure it's not being used on another CPU. >      * >      * desc->status is cleared in do_IRQ() under desc->lock, whose >      * acquire/release barriers are a full smp_mb() on this arch, so the >      * handler's writes are already ordered before the clear is visible. >      * On this side, xvfree() is control-dependent on the final test_bit() >      * load, so Rule 11 (RVWMO) already orders it after the wait with no >      * barrier. smp_rmb() below adds real read->read ordering, but nothing >      * after the loop depends on it (action->free_on_release isn't racy); >      * it's kept as a guard against the compiler breaking the control >      * dependency the ordering actually relies on. >      */ >     while ( test_bit(_IRQ_INPROGRESS, &desc->status) ) >         cpu_relax(); >     smp_rmb(); > >     if ( action->free_on_release ) >         xvfree(action); > > Am I missing something? It could be option just to skip smp_rmb() here at all: /* * Wait for a handler still running on another CPU to complete: do_IRQ() * clears IRQ_INPROGRESS only after the handler has returned. * * No barrier is needed here: nothing below reads data written by the * handler (action->free_on_release is set up once, before the action is * ever registered), and the stores done by xvfree() are ordered after * the loop's load of desc->status by the control dependency alone * (RVWMO ppo rule 11). */ while ( test_bit(_IRQ_INPROGRESS, &desc->status) ) cpu_relax(); if ( action->free_on_release ) xvfree(action); But probably just to be sure that if ->free_on_release will one day somewhere else set except the mentioned case it makes sense to have smp_rmb() or even smp_mb() (depsite of the fact smp_rmb() looks more then enough). Does it make sense? > >> >> Please split this across three lines, to conform to style. (Also same nit >> as above.) >> >>> +    if ( action->free_on_release ) >>> +        xvfree(action); From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:07:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:07:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408206.1640848 (Exim 4.92) (envelope-from ) id 1x2RlQ-0002f1-5w; Fri, 04 Sep 2026 11:07:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408206.1640848; Fri, 04 Sep 2026 11:07:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RlQ-0002eu-2p; Fri, 04 Sep 2026 11:07:20 +0000 Received: by outflank-mailman (input) for mailman id 1408206; Fri, 04 Sep 2026 11:07:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RlO-0002ek-SD for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:07:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RlN-000cgN-1i for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:07:17 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa664-2eae-0a2a0a5409dd-0a2a45038b72-6 for ; Fri, 04 Sep 2026 13:07:16 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa663-fae8-0a2a45030019-aa0a817c59b9-3 for ; Fri, 04 Sep 2026 13:07:16 +0200 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-259-oKXwv1ynOZiCKZGWew2UnA-1; Fri, 04 Sep 2026 07:07:14 -0400 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-49b8c651ac0so15387955e9.2 for ; Fri, 04 Sep 2026 04:07:13 -0700 (PDT) Received: from imammedo ([213.175.37.14]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cf755c22esm62275895e9.0.2026.09.04.04.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:07:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788520035; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=COwhqAov+nLJAVa8MRbosYqYAf0VB6LVyz5Coc61zuI=; b=J93HoMYEea9DaUk8MolKIdsdpsijHAhjzWnYLYBTMaauoAGq7LDh/euTy7iuG2H5apsuQa v99gfyfpBJ7fayGdMFFMfGbf0NDxNUCHl9udNTO07nH94TWhARrq/L3IZkprOU7+Spby8N 53g20eFXY34IXXRrNYRxQEdqm5iwHJo= X-MC-Unique: oKXwv1ynOZiCKZGWew2UnA-1 X-Mimecast-MFC-AGG-ID: oKXwv1ynOZiCKZGWew2UnA_1788520033 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788520033; x=1789124833; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Rma0vtMwq9+HEP9ZApTJBKj1zxbRdaELT3NPMRD9Df8=; b=V/Xh2+bwruGAp8t+zChcGYBgvRtwsfii+FiHwjjuDKdsBt6MmImAcC3XfMi8yMGxk6 5ojB3VBnGXCnYD7b4lRmMpRXhTxY65gD8ziqdFsNBR05rf26k1uNRIXXrF3mJgxfi8+5 8nabjbEW6pmDWBCn2GEErDXvOpr0Stgw2DCZ0psaWWwt5Bou9rnrT27hdl9hTPEupDZT 4LOXL1jaAkV2JpUxGXQU98aig2279cFIPU0XpAsS0rmLWRr2P4bbOG7z4DhkvoKzbAqY Sb+BrdSRWubyUSElPeZyA4Kk8HF6UNAZEGxkullgDe9pTkKteS1pVCO36o28vtwQe/Jt ZcOA== X-Forwarded-Encrypted: i=1; AKwUvBz+WNST9Sc1SjGY4wZ5lqSnDUFg2PzxClnmC0MlNq7D3RulRtN9KWRwb9jfJv8dho77YoUAPDngoHY=@lists.xenproject.org X-Gm-Message-State: AFuF++nfUabxlWAwQdnjDmxl0lbzBrwTo/CHAiTXDj9JuUW6aL7UdL+4 ve2VNe5DtTYtc10BemA6Le1je5i0olq4SAMLKG6I9s2VGCcUcptWKwMIkMQ54HyCOo+yrd7TzsY WDyKtuPdyg/l4xvsVK88a6QgwRZRXFngtP6hV+pQgzBL6iAfp1yzMYpY6obyNqZrBlAev X-Gm-Gg: AYBFou0clf9vaIvFNo8rdW/B2CfvJUbK6hZVKahEScnBeOIiUXdN69AMMmxMCuH9iRV XmjX3QIsZqSy772D1a0+XdkrCcuhVyfkNe0sMg9ZQmGy4BlTr9ZVjb0ivO8h5xQil8/bfucB3+t MHofCZvO1S1ACBg5+1kCgyvcD61TB9NOdR9dvcqo7zpChs7xNDhY11sa6B4dxgewIx+pSFPiXG+ hajZXwO0ChZ63zQ9C1Lyo0crU69fxnndrWxfDpKaMQxtrLwIdppr5wE5IUmO+y3hh6cQ+lECCy8 GyanGPYuH/iMX/yKAmmNaS+ypFr1VFtjoSKkAqrXIXPg2gb2uFOzyWe9kIs= X-Received: by 2002:a05:600c:8b05:b0:499:be2d:c290 with SMTP id 5b1f17b1804b1-49cf824e751mr61823175e9.9.1788520032852; Fri, 04 Sep 2026 04:07:12 -0700 (PDT) X-Received: by 2002:a05:600c:8b05:b0:499:be2d:c290 with SMTP id 5b1f17b1804b1-49cf824e751mr61822205e9.9.1788520032319; Fri, 04 Sep 2026 04:07:12 -0700 (PDT) Date: Fri, 4 Sep 2026 13:07:09 +0200 From: Igor Mammedov To: "Michael S. Tsirkin" Cc: Dongli Zhang , "Daniel P. =?UTF-8?B?QmVycmFu?= =?UTF-8?B?Z8Op?=" , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug Message-ID: <20260904130709.6769caee@imammedo> In-Reply-To: <20260903160401-mutt-send-email-mst@kernel.org> References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> <20260903160401-mutt-send-email-mst@kernel.org> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: v16B5CGhdqHcmcnUk69wu-5GOlaexUtywqsZPk7VUi8_1788520033 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-33051d/1788520036-6F4C74E9-54AC7336/0/0 X-purgate-type: clean X-purgate-size: 8591 On Thu, 3 Sep 2026 16:17:20 -0400 "Michael S. Tsirkin" wrote: > On Thu, Sep 03, 2026 at 05:28:35PM +0200, Igor Mammedov wrote: > > On Wed, 26 Aug 2026 09:15:47 -0700 > > Dongli Zhang wrote: > > =20 > > > On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrang=C3=A9 wrote: = =20 > > > > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: =20 > > > >> Hot-unplugging a PCI device can require cooperation from the guest= . For > > > >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the gue= st > > > >> eventually writes the ACPI PCI eject register. For PCIe native hot= plug, > > > >> QEMU notifies the guest through the PCIe hotplug mechanism and wai= ts for > > > >> the slot unplug flow to complete. Only after that completion does = QEMU > > > >> unrealize the device and emit DEVICE_DELETED. > > > >>=20 > > > >> This can leave a device stuck in the unplug pending state when the= guest > > > >> does not cooperate. Examples include: > > > >>=20 > > > >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver= is > > > >> unavailable. > > > >>=20 > > > >> 2. The guest is stalled and cannot handle the hot-unplug event. Fo= r > > > >> example, stalling the Linux [irq/9-acpi] kernel thread can reprodu= ce this > > > >> for ACPI-based hot-unplug. > > > >>=20 > > > >> 3. The device was attached to a slot that the guest cannot use. Fo= r > > > >> example, a pcie-root-port only supports slot 0. If a device is add= ed to a > > > >> non-zero slot below a pcie-root-port, the guest may never discover= the > > > >> device and therefore may never complete the unplug request. =20 > >=20 > > all of above is actually expected, no (functioning) driver =3D> no hotp= lug/unplug. > > it's the guest problem. Once device it exposed to guest its life-cycle > > not longer owned by QEMU. > >=20 > > That's what one would see in real hw as well, you press eject button > > but it will not do anything if OS doesn't process it. > > also see comment at the end. > > =20 > > > >>=20 > > > >> The non-zero slot case has also been discussed in: > > > >>=20 > > > >> hw/pci: warn when PCIe device is plugged into non-zero slot of dow= nstream port > > > >> https://gitlab.com/qemu-project/qemu/-/commit/ =20 > > > > ca92eb5defcf9d1c2106341744a73a03cf26e824 =20 > > > >>=20 > > > >> hw/pci: add comment to explain checking for available function 0 i= n pci hotplug > > > >> https://gitlab.com/qemu-project/qemu/-/ =20 > > > > commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5 =20 > > > >>=20 > > > >> pci: don't skip function 0 occupancy verification for devfn auto a= ssign > > > >> https://gitlab.com/qemu-project/qemu/-/commit/ =20 > > > > e228d62b4af29bca698ec57efdceb46f392f5444 =20 > > > >>=20 > > > >> For example, if root-port.1 is a pcie-root-port, the following com= mand adds > > > >> a vhost-scsi-pci device to an invalid slot: > > > >>=20 > > > >> (qemu) device_add vhost-scsi-pci,id=3Dscsi01,wwpn=3Dnaa.5001405324= af0985,bus=3Droot-port.1,addr=3D01.0 > > > >> warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent devic= e only allows plugging into slot 0. =20 > > > >=20 > > > > This rather looks like it should be a fatal error, not a mere warni= ng. > > > >=20 > > > > If I follow the commit ca92eb5def it links to https://bugzilla.redh= at.com/show_bug.cgi?id=3D2128929 > > > > which states that this configuration is going to lead to a crash in > > > > QEMU on guest OS shutdown. IMHO that crash is sufficient to justify > > > > making this a fatal error. > > > >=20 > > > > If we actually wanted this to remain a warning, then that shutdown > > > > crash would need to be fixed. > > > > =20 > > >=20 > > > Thank you very much! > > >=20 > > > I see that the issue has been fixed. The ticket mentions the followin= g. > > >=20 > > > "What I am observing is that it seems when the slot ID !=3D 0, the gu= est OS seems > > > to ignore this and we never seem to hit ich9_pm_device_unplug_cb()." > > >=20 > > > Based on my experience and evaluation, ACPI-based hotplug is more lik= ely to > > > encounter an issue where the guest VM does not respond to an unplug o= peration. =20 > >=20 > > I'm not sure it's a good idea to delete device when guest still thinks = it's there > > (you can make guesses on QEMU side if it's in use, how useful those are= is questionable). > >=20 > > as far as I know, ACPI hotplug has no notion of surprise removal (pls e= ducate me if it's not the case), =20 >=20 > why would it not? >=20 > how do you think you can pull a laptop out of a dock? > I expect bus check + _STA and config space saying it is gone > will do exactly that. >=20 >=20 > Here's linux code: > static void acpiphp_check_bridge(struct acpiphp_bridge *bridge) > { =20 > struct acpiphp_slot *slot; >=20 > /* Bail out if the bridge is going away. */ > if (bridge->is_going_away) > return; >=20 > if (bridge->pci_dev) > pm_runtime_get_sync(&bridge->pci_dev->dev); > =20 > list_for_each_entry(slot, &bridge->slots, node) { > struct pci_bus *bus =3D slot->bus; > struct pci_dev *dev, *tmp; >=20 > if (slot_no_hotplug(slot)) { > ; /* do nothing */ > } else if (device_status_valid(get_slot_status(slot))) { > /* remove stale devices if any */ > list_for_each_entry_safe_reverse(dev, tmp, > &bus->devices, b= us_list) > if (PCI_SLOT(dev->devfn) =3D=3D slot->dev= ice) > trim_stale_devices(dev); >=20 > /* configure all functions */ > enable_slot(slot, true); > } else { > disable_slot(slot); > } > } >=20 > if (bridge->pci_dev) > pm_runtime_put(&bridge->pci_dev->dev); > } >=20 >=20 > so weirdly it wants bus check on a parent bus, otherwise it will > not trim devices? probably a bug, but easy to work around. Modern docks would use native pcie surprise removal path. As for ACPI, my old laptop, had an unlock button =3D> _LCK and that relied on OS processing ACPI events, not so surprise. There might have been ACPI/hybrid docks that did surprise removal, but then one need to find one and model after that instead of=20 just blanket force removal. (likely out come would a doc device support only, not an arbitrary device removal) (not the case described in this series, though. hence my request to clarify= usecase) from what I see in spec there is _RMV method that says that device supports surprise removal that can be used for devices that support it. However I would hesitate very much to blank apply it to every PCI device. (it's not even realistic to ask for proving safe tear down across various drivers and OSes/versions) Rather than a knee jerk treatment of misconfig consequences, I'd rather see patches to prevent misconfig in the 1st place (subj to deprecation but doable). As for the cases where OS mis-behaves (apcihp thread starvation,...), fixing guest to follow hotplug contract is a proper place to do it. On QEMU side we have it covered as well. If unplug was not processed, mgmt is free to repeat action. =20 > > so I wouldn't do what you are proposing here at all, it's basically ask= ing for disaster to happen. > > And all this is basically for dealing with abused qemu flexibility. > >=20 > > Please (re)formulate usecase and make it more clear as what is eludes m= e > > no matter how many times i've read this cover letter. > >=20 > > On positive note: > >=20 > > What you can try to implement is native PCI-E support for surprise remo= val. > > How hard that would be I don't know. And I would well expect if one dev= iates from > > real hw expectations/configs (such as not 0 slot/partial func removal), > > one would quickly stumble upon issues as that's not what what vendors = write/test > > drivers for. > >=20 > > Even if it's not likely to be used in practice (guest still might not s= upport it), > > it may serve as test-bed for guest drivers. > > =20 > > > Thank you very much! > > >=20 > > > Dongli Zhang > > > =20 >=20 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:12:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:12:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408220.1640857 (Exim 4.92) (envelope-from ) id 1x2RqW-0004qf-Q0; Fri, 04 Sep 2026 11:12:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408220.1640857; Fri, 04 Sep 2026 11:12:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqW-0004qY-Mp; Fri, 04 Sep 2026 11:12:36 +0000 Received: by outflank-mailman (input) for mailman id 1408220; Fri, 04 Sep 2026 11:12:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqU-0004qD-NW for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:12:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RqU-006qSV-3g for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:12:34 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa79b-8faa-0a2a0a5109dd-0a2a4501e67a-28 for ; Fri, 04 Sep 2026 13:12:34 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa7a1-5984-0a2a45010019-d155dd29e8df-3 for ; Fri, 04 Sep 2026 13:12:34 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-482e4998d28so623414f8f.2 for ; Fri, 04 Sep 2026 04:12:33 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885be1c1sm5501729f8f.32.2026.09.04.04.12.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:12:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788520353; x=1789125153; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=hmkZM9Mm73S645jnJBU1at3N10v0ENSyY/CU3V99DxM=; b=oMQ05KIEyLbV2jea+jiwj246+Y0CjROtCG43lZDMwS6RG75wFN1YJqs5eR30uRMsT/ Sti9uxIW7zlp+u9P/OS0DmR4dVq6grbLkHUY9AbjEPWgQ2JMx0822wsSsVmLxTKIzEOP LbgJIinSmcSmx3nz2MWXSH7yzfItDxnWEB1TE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788520353; x=1789125153; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=hmkZM9Mm73S645jnJBU1at3N10v0ENSyY/CU3V99DxM=; b=m5rKo0Bi8JvM2GeOvIWFmXla6lX58VUlSsxnpYtyCy2JcyzAzDPae/RRIKx8zJ+GEh 9Y/3xWaxcK+nAVf+xv6UDoHavPTzeiMtDk61OvPXu6SUBYVOqZxoaj8BhPbyjK/4wTlp GLPcaqe+atfsjmloqIFTY5u6GFEygocCj0EpIedR7obRFwaBeSoj5tdUWU0HHjF/ndGi TEMSI8rbtBTaeJgS+xYvJxw7nXQvycTtbpe8hn+XQohbtrUEued/PHu+OCiiv0CBH/l7 hqQiEzRXFAe17hyilUY5w9Pi9V04v4YQUB5ZISoILfhHL/nvtdjmjoC8SCC8pEUYTCj3 pUug== X-Gm-Message-State: AFuF++kI1boN2I0V2EopwQzZ9UiQENQT+32/tyLTJp22I3TLwYIsKkCy P7PPK2lcV3abBEuNyp8b4/I8nhbZIbKzig4fqEf3WJIyPm68i6HN54m/L0PC5OrEsB48WntAe5Y VkESo X-Gm-Gg: AYBFou0DV3IKn3kKpYhy/vjyb9GqkLgN3DtNZcc2Mmjb/9MldaVHWSpFBC2lHrigpMx /n3Uj4Xx+hZdU9Ppxu2g+ty6tRA0iI3r4aoehIBORP/r0aURMGY/2V3pHLiC0TW7GgfB3XhPWXp aP0nQlQQkYI4aslhg0w6teI7AZcdzhSePEabEINoOIXLqspJ/hrMl4kHnB/uT1tajtm3BMFljTm zOv9gPOjmj53al4o4kShR0BasbGF5t0bgazvUA+JrlLwcEHYOZTWvn84iUp4RQRFhF+8xH1YI2Q WpLlw0oep7C0Elo+H6Y5+gECyhLGKMJOSHTAUZvl3auyVHEu7ck73umk23XazBCQ84na1AneRw7 OrTWbNlanayGUqa93OsfpKzrNJDnrns21YKP1KKBCRVg+jkbS/aCjJjC+Yeq6hjjOR8AZlTVkVv cIydSrfEK7PKWdscRc2ToZoCM6b0HPhKiI4gTYEInvs/RA3qaC9M2gJyvH9vvHNBlCSQ7UO+d+5 PKs2S4zMgQX8CQ78EizhGtlqhn/twh1mJpzOcs= X-Received: by 2002:a05:6000:25fe:b0:485:8cb8:b838 with SMTP id ffacd0b85a97d-4858cb8b900mr1701754f8f.7.1788520352907; Fri, 04 Sep 2026 04:12:32 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Jan Setje-Eilers Subject: [PATCH v2 0/5] xen/arm: Fixes and improvements to SMCCC Date: Fri, 4 Sep 2026 12:12:23 +0100 Message-Id: <20260904111228.3022634-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788520354-C4B45757-EE6EE7FA/0/0 X-purgate-type: clean X-purgate-size: 1331 Patch 1 is a bugfix for the issue reported by Jan Setje-Eilers. It needs backporting to Xen 4.22. Everything else is because I couldn't bear to leave the code generation in such a bad state. Only minor changes since v1, in patches 4 and 5. Andrew Cooper (5): xen/arm: Fix evaluation of parameters for SMCCC calls xen/arm: Introduce arm_smccc_guest_smc() xen/arm: Clean up 32bit arm_smccc_1_1_smc() xen/arm: Rewrite arm_smccc_smc() for arm64 xen/arm: Rewrite arm_smccc_*() to return by value xen/arch/arm/arm64/smc.S | 16 -- xen/arch/arm/cpuerrata.c | 18 +- xen/arch/arm/firmware/scmi-smc.c | 16 +- xen/arch/arm/include/asm/smccc.h | 238 +++++++++++--------- xen/arch/arm/platforms/exynos5.c | 2 +- xen/arch/arm/platforms/imx8m.c | 16 +- xen/arch/arm/platforms/imx8qm.c | 16 +- xen/arch/arm/platforms/seattle.c | 4 +- xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 17 +- xen/arch/arm/psci.c | 17 +- xen/arch/arm/tee/optee.c | 50 ++-- xen/arch/arm/traps.c | 4 +- 12 files changed, 187 insertions(+), 227 deletions(-) base-commit: 48728c33e43329c8037575320ce681a65cc13eb7 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:12:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:12:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408221.1640866 (Exim 4.92) (envelope-from ) id 1x2RqX-00053Q-Vn; Fri, 04 Sep 2026 11:12:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408221.1640866; Fri, 04 Sep 2026 11:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqX-00053G-Sj; Fri, 04 Sep 2026 11:12:37 +0000 Received: by outflank-mailman (input) for mailman id 1408221; Fri, 04 Sep 2026 11:12:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqV-0004qM-Pd for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:12:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RqU-00DcP9-IQ for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:12:34 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa7a1-2eae-0a2a0a5409dd-0a2a450ac29c-6 for ; Fri, 04 Sep 2026 13:12:34 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa7a2-f2d2-0a2a450a0019-d155dd2adc54-3 for ; Fri, 04 Sep 2026 13:12:34 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-4843e9c5960so884856f8f.0 for ; Fri, 04 Sep 2026 04:12:34 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885be1c1sm5501729f8f.32.2026.09.04.04.12.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:12:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788520354; x=1789125154; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=IAj5V/bmI918usNj6g2EqlOZB06ZEviH3X3JOCZBsg0=; b=X3nN+PPaimN6A+z7e+wvnsF+kpa4GdbmWawPypI4A9jDfc95SwzpsDShaZdLbrgs6A GGZllrRxWCfWgryRbKwOqiloIMcOPndz9K6UxM+UOPAjV8R5VUuPWx65Hc6nd4yCWMKl 7luTdMEtAPW63qqbi04aDGtcUihH8ghR02TL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788520354; x=1789125154; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=IAj5V/bmI918usNj6g2EqlOZB06ZEviH3X3JOCZBsg0=; b=I/riddpCBaYpDJETHfguTPLqp9OcTi7rXBRLQ/Czx9MwThCLnYEtuqjbIND4Lv9oFC k5GbrQdV/3O1s72Pi+jQmamWBFifiSpCJoP0x2ibg83l/itvFyZQp0odF6iE7XGs7RsE nEohQijtMhWlEkiYiAf7bDF+mU4ZNX7KvsyUwGnpuIVw0Eb22pysj5cLDhmztDsLhzA6 Vr1q3FH6X5Lec7w1G1Z+Ep/yIJ7u8Kzooqus7rCmbHEm+gBqqHhCx8rzpia61gBFJbJ7 J5KpTFwZRICXpGT6IwFcVV4/lVzhFh6Ok6wjEAUBDBWzZMHDglYCqHo4KGqmnmfBBaLR ZpKg== X-Gm-Message-State: AFuF++kgWpub0wCngpb1UoVwssXotul2nWoLS9BxxR0Jv5xfSWoByxoU nvvOD8QaqGR05Z8Nt/+s9TLvnA+fIWVozuUtx9jtCmA2ziyv8WyefEGmQ15BVfmSUHAEfa9NS/u adPAB9C0= X-Gm-Gg: AYBFou0oxxdYeDV+dArx5+9kZD2M3al5N/IdHB4BKuEe6d8wwLdpn0/RAuSluG79X43 Z63xGAs+bYhTB/g5V1gdlqjFa6YfkhbqPPwQKUY6iOlQvQKonQndBgtm2Ed+CYNahuy2nXvIBST HYC5HdR0GlFgnBrzJRCdaDiF3PiZUxQjwaCdJs+S2JpvmZCa2qLpGiG5hC4BTxpPG98gs6MAw4m WbnJafa6MhSB5RWrEIxIQRI4wcYJkOZPskFEoBscDtdHrm6gYe5Em0Qlv2kdIaDoifBIWvS9isj AOni7DSNsftGM+5yBPAmHY/8l1LL3ZHgeWrCBQ16DJKbUS8cDjtqVbFWQKpWAegOIzCOOM8g6qN XIRHGy/7XmCyycrtFe+hR6Dq2HqXqL0Xr2adJKvLNEnghlUMbDShoYZdMD4wIJSFsaZRNuzycsa CUJXgaol7DN5IegrG+3xt6z1U5+bnum8G41qT4Et4JOVhCuNpsjC5DNffn5fehzln/ueKns0v/W lbx7M06NKFk+eTojXjgIn02fEEB3HQFkvPktfZJVElCOj5PrA== X-Received: by 2002:a05:600c:154f:b0:49c:fc6e:8cb5 with SMTP id 5b1f17b1804b1-49cfc6e8ee3mr27356755e9.25.1788520353571; Fri, 04 Sep 2026 04:12:33 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Setje-Eilers , Bertrand Marquis , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel Subject: [PATCH v2 1/5] xen/arm: Fix evaluation of parameters for SMCCC calls Date: Fri, 4 Sep 2026 12:12:24 +0100 Message-Id: <20260904111228.3022634-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260904111228.3022634-1-andrew.cooper3@citrix.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1788520354-4B4D7CFC-79B07C3E/0/0 X-purgate-type: clean X-purgate-size: 4639 Contrary to what was claimed in commit 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations"), there is an important reason to retain the intermediate variable. It is unsafe to have any logic between the assignment of the register variabes and the asm() block they're used in. This logically reverts commit 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations") while retaining the conversions from commit 7f15d5d13221 ("xen/treewide: More typeof() -> auto conversions"). Adjust __declare_arg_0() to match. It happens to be safe because it's the first register expression once all macros are expanded, but it really should be consistent with the others. Leave a comment explaining why they must be written like this. Fixes: 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarations") Reported-by: Jan Setje-Eilers Signed-off-by: Andrew Cooper Reviewed-by: Bertrand Marquis --- CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Jan Setje-Eilers --- xen/arch/arm/include/asm/smccc.h | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h index 62c6985e7315..53cdddb690b7 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -108,37 +108,52 @@ struct arm_smccc_res { #define __constraint_read_6 __constraint_read_5, "r" (arg6) #define __constraint_read_7 __constraint_read_6, "r" (arg7) +/* + * Macro arguments MUST be evaluated before being assigned to a register + * variable. + * + * This is manual register scheduling for the asm() statement, and any other + * logic to evaluate may clobber the already-scheduled registers. + */ #define __declare_arg_0(a0, res) \ + auto __a0 = (uint32_t)(a0); \ struct arm_smccc_res *___res = (res); \ - register unsigned long arg0 ASM_REG(0) = (uint32_t)(a0) + register unsigned long arg0 ASM_REG(0) = __a0 #define __declare_arg_1(a0, a1, res) \ + auto __a1 = (a1); \ __declare_arg_0(a0, res); \ - register auto arg1 ASM_REG(1) = (a1) + register auto arg1 ASM_REG(1) = __a1 #define __declare_arg_2(a0, a1, a2, res) \ + auto __a2 = (a2); \ __declare_arg_1(a0, a1, res); \ - register auto arg2 ASM_REG(2) = (a2) + register auto arg2 ASM_REG(2) = __a2 #define __declare_arg_3(a0, a1, a2, a3, res) \ + auto __a3 = (a3); \ __declare_arg_2(a0, a1, a2, res); \ - register auto arg3 ASM_REG(3) = (a3) + register auto arg3 ASM_REG(3) = __a3 #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ + auto __a4 = (a4); \ __declare_arg_3(a0, a1, a2, a3, res); \ - register auto arg4 ASM_REG(4) = (a4) + register auto arg4 ASM_REG(4) = __a4 #define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ + auto __a5 = (a5); \ __declare_arg_4(a0, a1, a2, a3, a4, res); \ - register auto arg5 ASM_REG(5) = (a5) + register auto arg5 ASM_REG(5) = __a5 #define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ + auto __a6 = (a6); \ __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ - register auto arg6 ASM_REG(6) = (a6) + register auto arg6 ASM_REG(6) = __a6 #define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ + auto __a7 = (a7); \ __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ - register auto arg7 ASM_REG(7) = (a7) + register auto arg7 ASM_REG(7) = __a7 #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:12:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:12:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408223.1640874 (Exim 4.92) (envelope-from ) id 1x2RqY-0005A0-FI; Fri, 04 Sep 2026 11:12:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408223.1640874; Fri, 04 Sep 2026 11:12:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqY-00058B-Bj; Fri, 04 Sep 2026 11:12:38 +0000 Received: by outflank-mailman (input) for mailman id 1408223; Fri, 04 Sep 2026 11:12:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqX-0004wG-7x for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:12:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RqW-00DcPh-L8 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:12:36 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa79f-e002-0a2a0a5209dd-0a2a450292f6-26 for ; Fri, 04 Sep 2026 13:12:36 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa7a4-6ca4-0a2a45020019-d155dd36b945-3 for ; Fri, 04 Sep 2026 13:12:36 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-484362f5c4aso1049816f8f.3 for ; Fri, 04 Sep 2026 04:12:36 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885be1c1sm5501729f8f.32.2026.09.04.04.12.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:12:34 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788520356; x=1789125156; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=OKNHZdlEt0x1ge8w8zMMA0euhweC/5SXf88v2qkE/1s=; b=FFvZSbAx+ad8M+G4vQ+lQ0ZJW1yKISbGM+51Axr8M4q1mIdiSYlT3ftg/Un51Lim60 UPWekGrSrNBXCQ6bnSgt9e2vRb9REwAZ+FwUpMPpNXMWkycVNGOOT292hm4aUsxNvUwl NuzQzFXemW5F36TdHp9YK48he1PqlyfiBOruw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788520356; x=1789125156; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=OKNHZdlEt0x1ge8w8zMMA0euhweC/5SXf88v2qkE/1s=; b=FkOujCbm9xuSyRekJMr3+ZEW9GFhd6zcRmPH2CK3mW9WOyrJyqb1Q8jzxuTV3c9gWO GfhRAj9HjabgE4TRpkU8ok/Ho7lOGTXzZtJzwjHZ0P5ckh2kQKhJU+0Z2WN1NPLgXz4R xAbdqQWGc/e8wqRbdS1uCK8LQxoKAg/eL86I7h2HNllO/6d3g6G/lAIDB+2b+RdeEyBB T1L/ddskY0LwZDGIn2Bfa3R8CcnS77V56JA9BUzZAd+oTP2r4jc0+ZyUmUp8n+XnoxF/ d42An+44OTpGuuEUscL2nAEvsCUOeE0QY0fiiNOvK6ogQue9vErJtkMVhF6h+jV4nXlp yjfw== X-Gm-Message-State: AFuF++nilzSre5ZcGoo89hiwCYseP4s7K5Hdc/9IPhmY0cenJHYanqWX Y6H3IlqFiyjkazgPIe4GBOutlOfXOgILTbWbJt3H5s1rniW27scZ8oNWFiTUHO0IPgQ7bAKkeOW DOjwkYKI= X-Gm-Gg: AYBFou1ywGctguzqn+d5XnpqbaW8EhaBRvG1N0VFLBy7cbFkjaXW6K4WSC/O7UoVxPY sptoxiNLyTfMXYZItf1qqfo1POClfw3KM8gM//j5d68ua1KR/9VS10YQRCp66C6gyqpfEqh8lxd lVryzaep86ZihAbPRI1fULqoxxncXqCWRQnaktvsQFozYJA/R25x+fNSR89/lk2vWBhgKyiy8Jh e87J8xhLxrmYJO0F6qBlvLgK/Prx4ectadBlOmdUaq71NeXT6wRhCJmynJmgfU/8jzNhucdIcrX 6G+649mlJyJeuxwRxWUtNmWrq6M5I3jKTn8cWPDR+mP5RkP0hOLlqfSsKBw9k2kGhlQTilNwFG8 nej9Jl5gdfyEWKi3ZHxkrntvJvvrv/GhOBUetfdDmTSbFziLb9lD5/OvOLn1zhcNeE10LSF5+7y mXeOc9klfiCRRpkvowJv6v0sR7t0u0oVeKEuQc87L41NS3eyIPEQBioJgmmUm3hkGFL9b01++0v nBWylhUqT1BSORyKwZmWOvZMVila0VK9qP+R6c= X-Received: by 2002:a05:6000:4796:b0:484:3312:f127 with SMTP id ffacd0b85a97d-4858709b371mr8520454f8f.27.1788520355821; Fri, 04 Sep 2026 04:12:35 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Bertrand Marquis , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: [PATCH v2 3/5] xen/arm: Clean up 32bit arm_smccc_1_1_smc() Date: Fri, 4 Sep 2026 12:12:26 +0100 Message-Id: <20260904111228.3022634-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260904111228.3022634-1-andrew.cooper3@citrix.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788520356-F30B02AC-56B4610A/0/0 X-purgate-type: clean X-purgate-size: 5507 ... before making a related copy of it. * Drop __constraints() so the output parameters are visible in the same block as they're defined. Use PASTE() rather than opencoding it. * Adust the indentation of trailing \'s for consistency. * Drop the newline at the end of the instruction. * Indent the if condition correctly. ___res is always of type arm_smccc_res (declared in __declare_arg_0()), so drop the typeof(). * Drop arm_smccc_1_0_smc() as it has no users. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Bertrand Marquis --- CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Jan Setje-Eilers --- xen/arch/arm/include/asm/smccc.h | 45 ++++++++++++++++---------------- 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h index 832157f43734..5fe54013ac83 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -56,6 +56,8 @@ #ifndef __ASSEMBLER__ +#include + extern uint32_t smccc_ver; /* Check if this is fast call. */ @@ -115,24 +117,24 @@ struct arm_smccc_res { * This is manual register scheduling for the asm() statement, and any other * logic to evaluate may clobber the already-scheduled registers. */ -#define __declare_arg_0(a0, res) \ - auto __a0 = (uint32_t)(a0); \ - struct arm_smccc_res *___res = (res); \ +#define __declare_arg_0(a0, res) \ + auto __a0 = (uint32_t)(a0); \ + struct arm_smccc_res *___res = (res); \ register unsigned long arg0 ASM_REG(0) = __a0 -#define __declare_arg_1(a0, a1, res) \ - auto __a1 = (a1); \ - __declare_arg_0(a0, res); \ +#define __declare_arg_1(a0, a1, res) \ + auto __a1 = (a1); \ + __declare_arg_0(a0, res); \ register auto arg1 ASM_REG(1) = __a1 -#define __declare_arg_2(a0, a1, a2, res) \ - auto __a2 = (a2); \ - __declare_arg_1(a0, a1, res); \ +#define __declare_arg_2(a0, a1, a2, res) \ + auto __a2 = (a2); \ + __declare_arg_1(a0, a1, res); \ register auto arg2 ASM_REG(2) = __a2 -#define __declare_arg_3(a0, a1, a2, a3, res) \ - auto __a3 = (a3); \ - __declare_arg_2(a0, a1, a2, res); \ +#define __declare_arg_3(a0, a1, a2, a3, res) \ + auto __a3 = (a3); \ + __declare_arg_2(a0, a1, a2, res); \ register auto arg3 ASM_REG(3) = __a3 #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ @@ -158,12 +160,6 @@ struct arm_smccc_res { #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) -#define ___constraints(count) \ - : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3) \ - : __constraint_read_ ## count \ - : "memory" -#define __constraints(count) ___constraints(count) - /* * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call * @@ -189,10 +185,14 @@ struct arm_smccc_res { register unsigned long r2 ASM_REG(2); \ register unsigned long r3 ASM_REG(3); \ __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ - asm volatile("smc #0\n" \ - __constraints(__count_args(__VA_ARGS__))); \ + asm volatile ( \ + "smc #0" \ + : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3) \ + : PASTE(__constraint_read_, \ + __count_args(__VA_ARGS__)) \ + : "memory" ); \ if ( ___res ) \ - *___res = (typeof(*___res)){r0, r1, r2, r3}; \ + *___res = (struct arm_smccc_res){ r0, r1, r2, r3 }; \ } while ( 0 ) /* @@ -200,7 +200,6 @@ struct arm_smccc_res { * v1.1. */ #ifdef CONFIG_ARM_32 -#define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ @@ -217,7 +216,7 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) regs->r3 = res.a3; } -#else +#else /* CONFIG_ARM_64 */ void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, register_t a3, register_t a4, register_t a5, -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:12:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:12:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408222.1640872 (Exim 4.92) (envelope-from ) id 1x2RqY-00055U-8B; Fri, 04 Sep 2026 11:12:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408222.1640872; Fri, 04 Sep 2026 11:12:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqY-00054W-2w; Fri, 04 Sep 2026 11:12:38 +0000 Received: by outflank-mailman (input) for mailman id 1408222; Fri, 04 Sep 2026 11:12:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqV-0004qN-QX for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:12:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RqV-00DcPh-70 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:12:35 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa79f-e002-0a2a0a5209dd-0a2a450292f6-18 for ; Fri, 04 Sep 2026 13:12:35 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa7a2-6ca4-0a2a45020019-d155dd32b183-3 for ; Fri, 04 Sep 2026 13:12:35 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-484374f54d0so519938f8f.3 for ; Fri, 04 Sep 2026 04:12:35 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885be1c1sm5501729f8f.32.2026.09.04.04.12.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:12:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788520354; x=1789125154; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Ppy5o97De8trlM8n4YR2jLYgSbac3XUfe4LKYxgPMgw=; b=KnFkU5zEsshsz0eFEDQ5VQx3BdvkrSQqudzhEQbMjapwrptxNkMdmVEiuQB+EXe4cS MNyYdnKtP4UsABLLIhMdU0Xtdw8R35GcJwN6oaWxt71cUu3x/7WbVcuvvm23mPWnkbTl ja0OcMLHk7LHXYjXYc9YIRRTJE9Y/34tqSDsE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788520354; x=1789125154; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Ppy5o97De8trlM8n4YR2jLYgSbac3XUfe4LKYxgPMgw=; b=bFT/Zpe1AOhW9kFMCabyrVHgIouqMg4E/B8zB4e72XEv784bUebay55Z1wSKX/oKJ5 dWEA62D4trpQa7rCO18Nu6ZpHgBJRcIjtwtD7GdYiDPyS2u9fXF+5SqD96yiZcD62b7U 32HVFvEPlqPOewdND/uais6jo3J2bfvHBaV8bxTzdMVVjQ0nq4TaDUMlLM6PXznGgt3k lYw3hUQs8DTl+wwtejwiAyUREfWVPZg5NCYHiHPRbbfjyB4vnxZ5CSHvKr3Ys3UAoGXB 1WWzwZZ6bH432g9xZBerS9sLLmPp4EAsXjFAu39AoT/nPbTx3F2OHDN7kvjVC2BVGixX UfGw== X-Gm-Message-State: AFuF++l2bOGlO9Kz/IjYP0LimuCvYHys5z5ECRmj2sVbFGET1b4kOqj4 N5MpDHWSOu+quyCybZE69ImDQeUQ9Bk29JY2IHjq1aozK8okCDq17zPUvfzgCjpwr7BrxbZ7kd9 Om90LDYs= X-Gm-Gg: AYBFou0R98gNdImlg5Cdi0HpaEWpvxPU75MsHwq9ZDO3cEDLvdPT2aDMpllCWtM60D+ 4Kl86SSRqwEkvz8g45byAfwM+lit5kuTnBhXpi2KzIWeRMdMcQO8E+hAFG4cwmcbCJHVK3Blw6y bgPLZOrvQ+/6uZ2KPNAd4UCwdcald8sC/mkQFf0zYCuHXchVyj13OlvUH/DQeVH6TBvuu3N75rU 3VZLUOnBmf7D6UuXZr8EV/N94cIuwnRXaL5/wOu/IHIfo0LrpbcFoCryQclPOUDVFh5WMgSGRkZ o8ADn3p/I4B8dySjbDzJhaF5QqN6xvQfQJ5iZ1RJ5W3UdD4iOQcF4KUIliRnpyO6qYDKOuYhG+x A+3B3qm+/DBjfATR0Br4Gl7CI5lH9ig/XLrVeP5lMQkSZ8g9fkreGJ0WfuFG75zVUBJbSmyus4N C7fp9/NolJUoIjg2+RP0vn7vBh8e4B4GUBimAwC8XMrd8HIIreUX+H04yWXc7IHbSr4yXIozuHx 4yIBN/Zh+VrV2Psm8zeiuZ0aW2ozB7x54QjP4Y= X-Received: by 2002:a05:6000:2084:b0:482:f0ee:1390 with SMTP id ffacd0b85a97d-48587289c5bmr10690519f8f.22.1788520354233; Fri, 04 Sep 2026 04:12:34 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Bertrand Marquis , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: [PATCH v2 2/5] xen/arm: Introduce arm_smccc_guest_smc() Date: Fri, 4 Sep 2026 12:12:25 +0100 Message-Id: <20260904111228.3022634-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260904111228.3022634-1-andrew.cooper3@citrix.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788520355-660A82AC-E334D494/0/0 X-purgate-type: clean X-purgate-size: 8348 Both {get,set}_user_reg() are out-of-line functions, leading to awful code generation. Introduce arm_smccc_guest_smc() to operate directly on guest registers. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Bertrand Marquis --- CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Jan Setje-Eilers For arm64: add/remove: 0/0 grow/shrink: 2/4 up/down: 27/-864 (-837) Function old new delta symbols_addresses 35096 35120 +24 symbols_names 42958 42961 +3 imx8qm_smc 544 348 -196 scmi_handle_smc 372 152 -220 imx8m_smc 576 356 -220 zynqmp_eemi 864 636 -228 For arm32: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-160 (-160) Function old new delta scmi_handle_smc 392 232 -160 --- xen/arch/arm/firmware/scmi-smc.c | 16 +----------- xen/arch/arm/include/asm/smccc.h | 29 +++++++++++++++++++++ xen/arch/arm/platforms/imx8m.c | 16 +----------- xen/arch/arm/platforms/imx8qm.c | 16 +----------- xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 17 ++---------- 5 files changed, 34 insertions(+), 60 deletions(-) diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c index 0835ddeeeccc..a0cc6c6192f8 100644 --- a/xen/arch/arm/firmware/scmi-smc.c +++ b/xen/arch/arm/firmware/scmi-smc.c @@ -50,7 +50,6 @@ static bool scmi_is_valid_smc_id(uint32_t fid) static bool scmi_handle_smc(struct cpu_user_regs *regs) { uint32_t fid = (uint32_t)get_user_reg(regs, 0); - struct arm_smccc_res res; if ( !scmi_is_valid_smc_id(fid) ) return false; @@ -63,20 +62,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs) } /* For the moment, forward the SCMI Request to FW running at EL3 */ - arm_smccc_1_1_smc(fid, - get_user_reg(regs, 1), - get_user_reg(regs, 2), - get_user_reg(regs, 3), - get_user_reg(regs, 4), - get_user_reg(regs, 5), - get_user_reg(regs, 6), - get_user_reg(regs, 7), - &res); - - set_user_reg(regs, 0, res.a0); - set_user_reg(regs, 1, res.a1); - set_user_reg(regs, 2, res.a2); - set_user_reg(regs, 3, res.a3); + arm_smccc_guest_smc(regs); return true; } diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h index 53cdddb690b7..832157f43734 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -202,6 +202,21 @@ struct arm_smccc_res { #ifdef CONFIG_ARM_32 #define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) + +/* Make an SMCCC v1.1 compliant SMC call with guest register state. */ +static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) +{ + struct arm_smccc_res res; + + arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3, + regs->r4, regs->r5, regs->r6, regs->r7, &res); + + regs->r0 = res.a0; + regs->r1 = res.a1; + regs->r2 = res.a2; + regs->r3 = res.a3; +} + #else void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, @@ -251,6 +266,20 @@ void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, arm_smccc_1_0_smc(__VA_ARGS__); \ } while ( 0 ) +/* Make an SMCCC v1.1 compliant SMC call with guest register state. */ +static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) +{ + struct arm_smccc_res res; + + arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3, + regs->x4, regs->x5, regs->x6, regs->x7, &res); + + regs->x0 = res.a0; + regs->x1 = res.a1; + regs->x2 = res.a2; + regs->x3 = res.a3; +} + /* * struct arm_smccc_1_2_regs - Arguments for or Results from SMC call * @a0-a17 argument values from registers 0 to 17 diff --git a/xen/arch/arm/platforms/imx8m.c b/xen/arch/arm/platforms/imx8m.c index 669dd517e057..efb0ad20d6e8 100644 --- a/xen/arch/arm/platforms/imx8m.c +++ b/xen/arch/arm/platforms/imx8m.c @@ -50,7 +50,6 @@ static bool imx8m_smc(struct cpu_user_regs *regs) { uint32_t function_id = get_user_reg(regs, 0); uint32_t subfunction_id = get_user_reg(regs, 1); - struct arm_smccc_res res; if ( !cpus_have_const_cap(ARM_SMCCC_1_1) ) { @@ -122,20 +121,7 @@ static bool imx8m_smc(struct cpu_user_regs *regs) return false; } - arm_smccc_1_1_smc(function_id, - subfunction_id, - get_user_reg(regs, 2), - get_user_reg(regs, 3), - get_user_reg(regs, 4), - get_user_reg(regs, 5), - get_user_reg(regs, 6), - get_user_reg(regs, 7), - &res); - - set_user_reg(regs, 0, res.a0); - set_user_reg(regs, 1, res.a1); - set_user_reg(regs, 2, res.a2); - set_user_reg(regs, 3, res.a3); + arm_smccc_guest_smc(regs); return true; } diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c index 3600a073e8ba..7249e14ab640 100644 --- a/xen/arch/arm/platforms/imx8qm.c +++ b/xen/arch/arm/platforms/imx8qm.c @@ -67,7 +67,6 @@ static bool imx8qm_smc(struct cpu_user_regs *regs) { uint32_t function_id = get_user_reg(regs, 0); uint32_t subfunction_id = get_user_reg(regs, 1); - struct arm_smccc_res res; if ( !cpus_have_const_cap(ARM_SMCCC_1_1) ) { @@ -106,20 +105,7 @@ static bool imx8qm_smc(struct cpu_user_regs *regs) } allow_call: - arm_smccc_1_1_smc(function_id, - subfunction_id, - get_user_reg(regs, 2), - get_user_reg(regs, 3), - get_user_reg(regs, 4), - get_user_reg(regs, 5), - get_user_reg(regs, 6), - get_user_reg(regs, 7), - &res); - - set_user_reg(regs, 0, res.a0); - set_user_reg(regs, 1, res.a1); - set_user_reg(regs, 2, res.a2); - set_user_reg(regs, 3, res.a3); + arm_smccc_guest_smc(regs); return true; } diff --git a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c index 2053ed7ac5f6..326c8a1ba6e5 100644 --- a/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c +++ b/xen/arch/arm/platforms/xilinx-zynqmp-eemi.c @@ -51,7 +51,6 @@ static inline bool domain_has_reset_access(struct domain *d, uint32_t rst) bool zynqmp_eemi(struct cpu_user_regs *regs) { - struct arm_smccc_res res; uint32_t fid = get_user_reg(regs, 0); uint32_t nodeid = get_user_reg(regs, 1); unsigned int pm_fn = fid & 0xFFFF; @@ -187,20 +186,8 @@ bool zynqmp_eemi(struct cpu_user_regs *regs) * can forward the whole command to firmware without additional * parameters checks. */ - arm_smccc_1_1_smc(get_user_reg(regs, 0), - get_user_reg(regs, 1), - get_user_reg(regs, 2), - get_user_reg(regs, 3), - get_user_reg(regs, 4), - get_user_reg(regs, 5), - get_user_reg(regs, 6), - get_user_reg(regs, 7), - &res); - - set_user_reg(regs, 0, res.a0); - set_user_reg(regs, 1, res.a1); - set_user_reg(regs, 2, res.a2); - set_user_reg(regs, 3, res.a3); + arm_smccc_guest_smc(regs); + return true; done: -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:12:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:12:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408224.1640893 (Exim 4.92) (envelope-from ) id 1x2RqZ-0005gd-V6; Fri, 04 Sep 2026 11:12:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408224.1640893; Fri, 04 Sep 2026 11:12:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqZ-0005fX-PX; Fri, 04 Sep 2026 11:12:39 +0000 Received: by outflank-mailman (input) for mailman id 1408224; Fri, 04 Sep 2026 11:12:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqY-00059N-Iu for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:12:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RqX-006qSV-VG for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:12:37 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa79c-8faa-0a2a0a5109dd-0a2a4503b272-26 for ; Fri, 04 Sep 2026 13:12:37 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa7a5-fae8-0a2a45030019-d1558031f1e3-3 for ; Fri, 04 Sep 2026 13:12:37 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49ccfae359fso6877575e9.3 for ; Fri, 04 Sep 2026 04:12:37 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885be1c1sm5501729f8f.32.2026.09.04.04.12.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:12:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788520357; x=1789125157; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=gQNZV3/Wwp2qSBWtwYPdoz/wcPd4hlfIxvJUtY/sSz4=; b=erjHWhRIjbMv3Np6Gy060tckZwPnDImNH/xbvlnuCMAUvYCMbMUmO99hSgwaxBHCxa dkUon0pvd/nfcX+ptOQyL+9gj8XUOTbIsDCGAIigyc1Z0r6sQYkGa94mJjEbtpvh2fPM fIgBzS703RP7zy5VJzzNTncfpDae0AQrMrv88= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788520357; x=1789125157; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=gQNZV3/Wwp2qSBWtwYPdoz/wcPd4hlfIxvJUtY/sSz4=; b=EHfvuJQf8e53V9K8LUT7fsKG+C/U7jmpkXeyigoSkCHK4Ebk7LZqVcHznNw33wIPTm crtK7c2V8tZ/HYmoGS57low6JKYeBn6ZS0GaG0DePxRfEmzb5568WoB72OWnLCpzRVp2 +sL2+g8JqAqrbu65sJtAq0cohr86jT+TOcdDlvM+gflnMRuQtKjy28JqE/AFcNgtShii sNHyQFztAu2WtQvUbYUqhNNbxnVBUmaSDR1PTyS1x860B5Ynaza5rLMOpr4wqprlTZ83 zVo3GcB3T3BBbCDmpC4+hpPu8DMW/+Pg7pMZp4HsKrg0HyPt3lk6pgxnPFT7kyzxFem9 bbCQ== X-Gm-Message-State: AFuF++ldUJ4WR0mso2CgxdSDuUphUR67OgKCevX3Ag57e4/sKiuYcLpy ETNnmL5bSPYaeg6XDA3yU8GBdYo2TLuZ+Dwtd1fBGgkiJjtdrUNxfrN3ywfQqsKOGnatU9wWwT5 Q4W4Ac2g= X-Gm-Gg: AYBFou3dXkrp5QYRJWDk6YPbHJ4yMVTod0an82n65yNK0/hf47vXFMfrFqXb4OaOuvD JmmyrAVlZLil0lwKszegp7XnnYq/JYGK0CBJUv82L9Qulu24vmz4n+ADMTlotwv/w6Dk0x+Lh6Q DYHwHTgwlT9rN825EKtkBfLltlEX9oH3tcTAclRx0QAOuY7+tRUMR/0M3DYiY7heUCHKOxC8n/y lEa3sfsMB4nZNNah618flpV+VRHHJZsVcLb+1n33joAhnEVF3kg/hKtDqpFUPdW6cU9t3+dxK/7 BaT3/n9X0f3sYpwEEc7WyLNYC34t+aUs9ZS3fuZkpQGXmYlrnoCyovGAdrZ7lnt1io4fbNp7fja QUWmaYpgAOvsOJXM6T5ScqliF3DTrj4PwMvjOA5/nAaCYd2z2TiaHD2kUbTY+SjxMmF34nQZCCS GEP05zfRUGB4b7aKx/4xUc6lWGApTVWjOuu/HjxYtH51R1qUT0dljcoIKw73sxNrDAxhoM1Cq5y tj9OQOr96gpaRhIMIMEizF/Tko2VS9yBtQPOu8= X-Received: by 2002:a05:600c:190b:b0:49c:fc6c:be12 with SMTP id 5b1f17b1804b1-49cfc6cc0acmr22537745e9.24.1788520356605; Fri, 04 Sep 2026 04:12:36 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Jan Setje-Eilers Subject: [PATCH v2 4/5] xen/arm: Rewrite arm_smccc_smc() for arm64 Date: Fri, 4 Sep 2026 12:12:27 +0100 Message-Id: <20260904111228.3022634-5-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260904111228.3022634-1-andrew.cooper3@citrix.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788520357-75EFF4E9-7DA99E5D/0/0 X-purgate-type: clean X-purgate-size: 9681 SMCCC v1.0 says that x4 through x17 may be clobbered. SMCCC v1.1 says they are strictly preserved, and SMCCC v1.2 permits them to contain extra return values. Xen deals with this by having __arm_smccc_1_0_smc() as an out-of-line function, but this causes awful code generation in arm_smccc_smc(). cpus_have_const_cap() is opaque to the optimiser, so we end up with one basic block doing the reasonably-ok arm_smccc_1_1_smc() code generation and a second basic block setting up all 8 input registers even when they're not needed, spilling or discarding x8 through x17, and calling an out-of-line function. Remove __arm_smccc_1_0_smc() entirely, and rewrite arm_smccc_smc() to declare x4 through x17 as clobbered. This fully inlines the SMC, is a single basic block which instructs the compiler to spill or discard the potentially clobbered registers, and only sets up the necessary number of arguments for the call. No functional change. Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Jan Setje-Eilers v2: * s/PSCI/SMCCC/g * Rewrite the comment for the new arm_smccc_smc(). Bloat-o-meter reports: add/remove: 0/1 grow/shrink: 0/10 up/down: 0/-795 (-795) Function old new delta symbols_sorted_offsets 23832 23824 -8 symbols_names 42962 42943 -19 symbols_addresses 35128 35104 -24 __arm_smccc_1_0_smc 32 - -32 call_psci_cpu_off 144 76 -68 seattle_system_reset 92 16 -76 seattle_system_off 92 16 -76 call_psci_system_reset 112 32 -80 call_psci_system_off 112 32 -80 call_psci_cpu_on 252 124 -128 psci_init 628 424 -204 An alternative way to do this would be to have x8 thru x17 in the clobber list rather than the output list which would reduce the source size, but this form is more amenable to having SMCCC v1.2 worked into it too. --- xen/arch/arm/arm64/smc.S | 16 ------ xen/arch/arm/include/asm/smccc.h | 92 ++++++++++++++++---------------- 2 files changed, 45 insertions(+), 63 deletions(-) diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S index 68b05e8ddd12..65b4eabe4f87 100644 --- a/xen/arch/arm/arm64/smc.S +++ b/xen/arch/arm/arm64/smc.S @@ -13,22 +13,6 @@ * GNU General Public License for more details. */ -/* - * void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, - * register_t a3, register_t a4, register_t a5, - * register_t a6, register_t a7, - * struct arm_smccc_res *res) - */ -FUNC(__arm_smccc_1_0_smc) - smc #0 - ldr x4, [sp] - cbz x4, 1f /* No need to store the result */ - stp x0, x1, [x4, #SMCCC_RES_a0] - stp x2, x3, [x4, #SMCCC_RES_a2] -1: - ret -END(__arm_smccc_1_0_smc) - /* * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, * struct arm_smccc_1_2_regs *res) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h index 5fe54013ac83..4ed2a40ed0ac 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -16,9 +16,6 @@ #ifndef __ASM_ARM_SMCCC_H__ #define __ASM_ARM_SMCCC_H__ -#include -#include - #define SMCCC_VERSION_MAJOR_SHIFT 16 #define SMCCC_VERSION_MINOR_MASK \ ((1U << SMCCC_VERSION_MAJOR_SHIFT) - 1) @@ -57,6 +54,9 @@ #ifndef __ASSEMBLER__ #include +#include + +#include extern uint32_t smccc_ver; @@ -160,6 +160,8 @@ struct arm_smccc_res { #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) +#ifdef CONFIG_ARM_32 + /* * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call * @@ -199,7 +201,6 @@ struct arm_smccc_res { * The calling convention for arm32 is the same for both SMCCC v1.0 and * v1.1. */ -#ifdef CONFIG_ARM_32 #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ @@ -218,53 +219,50 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) #else /* CONFIG_ARM_64 */ -void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, - register_t a3, register_t a4, register_t a5, - register_t a6, register_t a7, - struct arm_smccc_res *res); - -/* Macros to handle variadic parameter for SMCCC v1.0 helper */ -#define __arm_smccc_1_0_smc_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ - __arm_smccc_1_0_smc(a0, a1, a2, a3, a4, a5, a6, a7, res) - -#define __arm_smccc_1_0_smc_6(a0, a1, a2, a3, a4, a5, a6, res) \ - __arm_smccc_1_0_smc_7(a0, a1, a2, a3, a4, a5, a6, 0, res) - -#define __arm_smccc_1_0_smc_5(a0, a1, a2, a3, a4, a5, res) \ - __arm_smccc_1_0_smc_6(a0, a1, a2, a3, a4, a5, 0, res) - -#define __arm_smccc_1_0_smc_4(a0, a1, a2, a3, a4, res) \ - __arm_smccc_1_0_smc_5(a0, a1, a2, a3, a4, 0, res) - -#define __arm_smccc_1_0_smc_3(a0, a1, a2, a3, res) \ - __arm_smccc_1_0_smc_4(a0, a1, a2, a3, 0, res) - -#define __arm_smccc_1_0_smc_2(a0, a1, a2, res) \ - __arm_smccc_1_0_smc_3(a0, a1, a2, 0, res) - -#define __arm_smccc_1_0_smc_1(a0, a1, res) \ - __arm_smccc_1_0_smc_2(a0, a1, 0, res) - -#define __arm_smccc_1_0_smc_0(a0, res) \ - __arm_smccc_1_0_smc_1(a0, 0, res) - -#define ___arm_smccc_1_0_smc_count(count, ...) \ - __arm_smccc_1_0_smc_ ## count(__VA_ARGS__) - -#define __arm_smccc_1_0_smc_count(count, ...) \ - ___arm_smccc_1_0_smc_count(count, __VA_ARGS__) - -#define arm_smccc_1_0_smc(...) \ - __arm_smccc_1_0_smc_count(__count_args(__VA_ARGS__), __VA_ARGS__) - +/* + * Make an SMC call compatible with both SMCCC v1.1 and v1.0. + * + * SMCCC v1.0 says that x4 through x17 are clobbered. SMCCC v1.1 says they + * are strictly preserved. Always mark x4 through x17 as clobbered. + */ #define arm_smccc_smc(...) \ do { \ - if ( cpus_have_const_cap(ARM_SMCCC_1_1) ) \ - arm_smccc_1_1_smc(__VA_ARGS__); \ - else \ - arm_smccc_1_0_smc(__VA_ARGS__); \ + register unsigned long r0 ASM_REG(0); \ + register unsigned long r1 ASM_REG(1); \ + register unsigned long r2 ASM_REG(2); \ + register unsigned long r3 ASM_REG(3); \ + /* Potentially clobbered in SMCCC v1.0 */ \ + register unsigned long c4 ASM_REG(4); \ + register unsigned long c5 ASM_REG(5); \ + register unsigned long c6 ASM_REG(6); \ + register unsigned long c7 ASM_REG(7); \ + register unsigned long c8 ASM_REG(8); \ + register unsigned long c9 ASM_REG(9); \ + register unsigned long c10 ASM_REG(10); \ + register unsigned long c11 ASM_REG(11); \ + register unsigned long c12 ASM_REG(12); \ + register unsigned long c13 ASM_REG(13); \ + register unsigned long c14 ASM_REG(14); \ + register unsigned long c15 ASM_REG(15); \ + register unsigned long c16 ASM_REG(16); \ + register unsigned long c17 ASM_REG(17); \ + __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ + asm volatile ( \ + "smc #0" \ + : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3), \ + "=r" (c4), "=r" (c5), "=r" (c6), "=r" (c7), \ + "=r" (c8), "=r" (c9), "=r" (c10), "=r" (c11), \ + "=r" (c12), "=r" (c13), "=r" (c14), "=r" (c15), \ + "=r" (c16), "=r" (c17) \ + : PASTE(__constraint_read_, \ + __count_args(__VA_ARGS__)) \ + : "memory" ); \ + if ( ___res ) \ + *___res = (struct arm_smccc_res){ r0, r1, r2, r3 }; \ } while ( 0 ) +#define arm_smccc_1_1_smc(...) arm_smccc_smc(__VA_ARGS__) + /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) { -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:12:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:12:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408225.1640903 (Exim 4.92) (envelope-from ) id 1x2Rqb-0005vw-7z; Fri, 04 Sep 2026 11:12:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408225.1640903; Fri, 04 Sep 2026 11:12:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Rqb-0005vQ-3s; Fri, 04 Sep 2026 11:12:41 +0000 Received: by outflank-mailman (input) for mailman id 1408225; Fri, 04 Sep 2026 11:12:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RqZ-0005LI-1p for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:12:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RqY-00DcP9-ET for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:12:38 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa79b-2eae-0a2a0a5409dd-0a2a450ce3d8-34 for ; Fri, 04 Sep 2026 13:12:38 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa7a6-f479-0a2a450c0019-d155dd2fc059-3 for ; Fri, 04 Sep 2026 13:12:38 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-4843efcbdb2so513462f8f.2 for ; Fri, 04 Sep 2026 04:12:38 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885be1c1sm5501729f8f.32.2026.09.04.04.12.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:12:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788520358; x=1789125158; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=04LSpSbvGT7DUfjS/h4Xju9eXZbdvvnkNdn9duYaZ48=; b=dOsg4CycfVClRRmAg419hlxRUS99DLzE6QWlaPcRQtu+OfkRcE+eIWEqHUwRSRURRS vy2i2xFBqWOIal4PPxNX0ev/Z7Hv7b85RIWvHzeH3SEAk3qQ3YH1uU1Pt0jvX4n2c0cG eXPXLrFtFmK7byyBFjiT4O2CAvEQLqR12JdPY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788520358; x=1789125158; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=04LSpSbvGT7DUfjS/h4Xju9eXZbdvvnkNdn9duYaZ48=; b=VUXQV6coVWA54MinkS37SA0qJg6oYGMdpeMKFz/ObJFTIy2blMTJRtyD4hp1EVSPuG +bhlGlJdrGgXcx7HZp+/AdAEYKc6xtVtSz2KC78+G82JB52YXVzDTu4PBJ2ZSA0QiFHU 2NTLHtfbDpWpUaWxShpsR/hMXaX7bIYepPA6somlCOT5A09hNy0VT/m8NTZ/v7hqZdJ5 aSM2DOiSX9aobpiBw69P6iMrUQrEUS0scQE/I/20hnCwGGeWrW+x3viF7udPuYoK4mWG IIhdtP3I923mE9S3nUgRE/Fd49cNC5PTwjBqtQifa4lgI6glAm7m/JCD3RRHTRuLec1i dQ6Q== X-Gm-Message-State: AFuF++nJsNQBxm+ljsVghaSv1xtKvniHTs8ZIGs1ej50W8CGkreWaK4r 3GRdFSUB1099/Fr3BGZMZRUGALMKkrZDZfulTKQQc+A/vMdR25novlFqXz6EEPlfFaOsLg18nrN at8UBalk= X-Gm-Gg: AYBFou3K70uU6v8xSCFOmKLhLXpvkSO1EnyOwc08y2dP1CGf5E7BNnR5eBsDN/4JCBr soetPMJZ5SeuO1porTq4dVTv3dkAzii2qF5R42HWzfejJu+BBcivIt+VYQzKK5y4CG8WJIBbDVr qSlcQVVlrxT5d2aPjfWotyadYoo9MNgtJ9EXzjHW3bPFeAmdjl+SmEkb7HdHElP3jgs4+zCPkXf boGjAk8bmcsnfGeOwmZp7yFru/X8MRoRpXiYxI7XNnM4hIZvMJr2mt+nD4+k/S2sZwuJld9swfT feGX5YWI0bbDyze1bW/hmxoIZQPaiiubEYe3L7M/9Pyttmcx0DUsJIcnFlniXTxT7wZuelWyxT9 odbb6PXN1/kccdLIcTdK+Ihrq1dVndAPicJWY1JcZB0RWM+sp7R2/LxJbc60CUgloO1b/5b0yn9 JpJ6iMClyjbhmMVDPBdunfzYPBJ0NwOU1qnzsG8EjHcBh9c6cG4tlg9WnGF278sDsdui4ySC8Hf w9DFeYPXdCbNH+KWsy6X5eykv+i8fK2qjMN1As= X-Received: by 2002:a05:6000:4610:b0:485:8a47:5b86 with SMTP id ffacd0b85a97d-4858a475c82mr3512586f8f.35.1788520357493; Fri, 04 Sep 2026 04:12:37 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Jan Setje-Eilers Subject: [PATCH v2 5/5] xen/arm: Rewrite arm_smccc_*() to return by value Date: Fri, 4 Sep 2026 12:12:28 +0100 Message-Id: <20260904111228.3022634-6-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260904111228.3022634-1-andrew.cooper3@citrix.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788520358-00ACCA5B-99FB727D/0/0 X-purgate-type: clean X-purgate-size: 24069 Use statement expressions to return struct arm_smccc_res which makes the code read a lot more normally, and avoids needing to pass in NULL in order to skip return information. More importantly, it removes the local implementation of __count_args() which is off by two and deeply confusing to try and follow. No functional change. Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Jan Setje-Eilers v2: * Transform extra call in optee_probe() Xen compiles identically before and after this change, for both arm32 and arm64. --- xen/arch/arm/cpuerrata.c | 18 +++---- xen/arch/arm/include/asm/smccc.h | 87 ++++++++++++++------------------ xen/arch/arm/platforms/exynos5.c | 2 +- xen/arch/arm/platforms/seattle.c | 4 +- xen/arch/arm/psci.c | 17 +++---- xen/arch/arm/tee/optee.c | 50 +++++++++--------- xen/arch/arm/traps.c | 4 +- 7 files changed, 86 insertions(+), 96 deletions(-) diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c index 3a32183618dc..35ad98d29d14 100644 --- a/xen/arch/arm/cpuerrata.c +++ b/xen/arch/arm/cpuerrata.c @@ -179,8 +179,8 @@ static int enable_smccc_arch_workaround_1(void *data) if ( smccc_ver < SMCCC_VERSION(1, 1) ) goto warn; - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, - ARM_SMCCC_ARCH_WORKAROUND_1_FID, &res); + res = arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, + ARM_SMCCC_ARCH_WORKAROUND_1_FID); /* The return value is in the lower 32-bits. */ if ( (int)res.a0 < 0 ) goto warn; @@ -256,8 +256,8 @@ static int enable_spectre_bhb_workaround(void *data) if ( smccc_ver < SMCCC_VERSION(1, 1) ) goto warn; - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, - ARM_SMCCC_ARCH_WORKAROUND_3_FID, &res); + res = arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, + ARM_SMCCC_ARCH_WORKAROUND_3_FID); /* The return value is in the lower 32-bits. */ if ( (int)res.a0 < 0 ) { @@ -398,8 +398,8 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry) if ( smccc_ver < SMCCC_VERSION(1, 1) ) return false; - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, - ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res); + res = arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, + ARM_SMCCC_ARCH_WORKAROUND_2_FID); switch ( (int)res.a0 ) { @@ -429,7 +429,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry) case ARM_SSBD_FORCE_DISABLE: printk_once("%s disabled from command-line\n", entry->desc); - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL); + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0); required = false; break; @@ -437,7 +437,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry) if ( required ) { this_cpu(ssbd_callback_required) = 1; - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); } break; @@ -445,7 +445,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry) case ARM_SSBD_FORCE_ENABLE: printk_once("%s forced from command-line\n", entry->desc); - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); required = true; break; diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h index 4ed2a40ed0ac..2d0f2db0b256 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -95,20 +95,14 @@ struct arm_smccc_res { unsigned long a3; }; -/* SMCCC v1.1 implementation madness follows */ -#define ___count_args(_0, _1, _2, _3, _4, _5, _6, _7, _8, x, ...) x - -#define __count_args(...) \ - ___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0) - -#define __constraint_read_0 "r" (arg0) -#define __constraint_read_1 __constraint_read_0, "r" (arg1) -#define __constraint_read_2 __constraint_read_1, "r" (arg2) -#define __constraint_read_3 __constraint_read_2, "r" (arg3) -#define __constraint_read_4 __constraint_read_3, "r" (arg4) -#define __constraint_read_5 __constraint_read_4, "r" (arg5) -#define __constraint_read_6 __constraint_read_5, "r" (arg6) -#define __constraint_read_7 __constraint_read_6, "r" (arg7) +#define __constraint_read_1 "r" (arg0) +#define __constraint_read_2 __constraint_read_1, "r" (arg1) +#define __constraint_read_3 __constraint_read_2, "r" (arg2) +#define __constraint_read_4 __constraint_read_3, "r" (arg3) +#define __constraint_read_5 __constraint_read_4, "r" (arg4) +#define __constraint_read_6 __constraint_read_5, "r" (arg5) +#define __constraint_read_7 __constraint_read_6, "r" (arg6) +#define __constraint_read_8 __constraint_read_7, "r" (arg7) /* * Macro arguments MUST be evaluated before being assigned to a register @@ -117,44 +111,43 @@ struct arm_smccc_res { * This is manual register scheduling for the asm() statement, and any other * logic to evaluate may clobber the already-scheduled registers. */ -#define __declare_arg_0(a0, res) \ +#define __declare_arg_1(a0) \ auto __a0 = (uint32_t)(a0); \ - struct arm_smccc_res *___res = (res); \ register unsigned long arg0 ASM_REG(0) = __a0 -#define __declare_arg_1(a0, a1, res) \ +#define __declare_arg_2(a0, a1) \ auto __a1 = (a1); \ - __declare_arg_0(a0, res); \ + __declare_arg_1(a0); \ register auto arg1 ASM_REG(1) = __a1 -#define __declare_arg_2(a0, a1, a2, res) \ +#define __declare_arg_3(a0, a1, a2) \ auto __a2 = (a2); \ - __declare_arg_1(a0, a1, res); \ + __declare_arg_2(a0, a1); \ register auto arg2 ASM_REG(2) = __a2 -#define __declare_arg_3(a0, a1, a2, a3, res) \ +#define __declare_arg_4(a0, a1, a2, a3) \ auto __a3 = (a3); \ - __declare_arg_2(a0, a1, a2, res); \ + __declare_arg_3(a0, a1, a2); \ register auto arg3 ASM_REG(3) = __a3 -#define __declare_arg_4(a0, a1, a2, a3, a4, res) \ +#define __declare_arg_5(a0, a1, a2, a3, a4) \ auto __a4 = (a4); \ - __declare_arg_3(a0, a1, a2, a3, res); \ + __declare_arg_4(a0, a1, a2, a3); \ register auto arg4 ASM_REG(4) = __a4 -#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ +#define __declare_arg_6(a0, a1, a2, a3, a4, a5) \ auto __a5 = (a5); \ - __declare_arg_4(a0, a1, a2, a3, a4, res); \ + __declare_arg_5(a0, a1, a2, a3, a4); \ register auto arg5 ASM_REG(5) = __a5 -#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ - auto __a6 = (a6); \ - __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ +#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6) \ + auto __a6 = (a6); \ + __declare_arg_6(a0, a1, a2, a3, a4, a5); \ register auto arg6 ASM_REG(6) = __a6 -#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ - auto __a7 = (a7); \ - __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ +#define __declare_arg_8(a0, a1, a2, a3, a4, a5, a6, a7) \ + auto __a7 = (a7); \ + __declare_arg_7(a0, a1, a2, a3, a4, a5, a6); \ register auto arg7 ASM_REG(7) = __a7 #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) @@ -181,21 +174,20 @@ struct arm_smccc_res { * makes it stick. */ #define arm_smccc_1_1_smc(...) \ - do { \ + ({ \ register unsigned long r0 ASM_REG(0); \ register unsigned long r1 ASM_REG(1); \ register unsigned long r2 ASM_REG(2); \ register unsigned long r3 ASM_REG(3); \ - __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ + __declare_args(count_args(__VA_ARGS__), __VA_ARGS__); \ asm volatile ( \ "smc #0" \ : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3) \ : PASTE(__constraint_read_, \ - __count_args(__VA_ARGS__)) \ + count_args(__VA_ARGS__)) \ : "memory" ); \ - if ( ___res ) \ - *___res = (struct arm_smccc_res){ r0, r1, r2, r3 }; \ - } while ( 0 ) + (struct arm_smccc_res){ r0, r1, r2, r3 }; \ + }) /* * The calling convention for arm32 is the same for both SMCCC v1.0 and @@ -208,8 +200,8 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) { struct arm_smccc_res res; - arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3, - regs->r4, regs->r5, regs->r6, regs->r7, &res); + res = arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3, + regs->r4, regs->r5, regs->r6, regs->r7); regs->r0 = res.a0; regs->r1 = res.a1; @@ -226,7 +218,7 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) * are strictly preserved. Always mark x4 through x17 as clobbered. */ #define arm_smccc_smc(...) \ - do { \ + ({ \ register unsigned long r0 ASM_REG(0); \ register unsigned long r1 ASM_REG(1); \ register unsigned long r2 ASM_REG(2); \ @@ -246,7 +238,7 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) register unsigned long c15 ASM_REG(15); \ register unsigned long c16 ASM_REG(16); \ register unsigned long c17 ASM_REG(17); \ - __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ + __declare_args(count_args(__VA_ARGS__), __VA_ARGS__); \ asm volatile ( \ "smc #0" \ : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3), \ @@ -255,11 +247,10 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) "=r" (c12), "=r" (c13), "=r" (c14), "=r" (c15), \ "=r" (c16), "=r" (c17) \ : PASTE(__constraint_read_, \ - __count_args(__VA_ARGS__)) \ + count_args(__VA_ARGS__)) \ : "memory" ); \ - if ( ___res ) \ - *___res = (struct arm_smccc_res){ r0, r1, r2, r3 }; \ - } while ( 0 ) + (struct arm_smccc_res){ r0, r1, r2, r3 }; \ + }) #define arm_smccc_1_1_smc(...) arm_smccc_smc(__VA_ARGS__) @@ -268,8 +259,8 @@ static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) { struct arm_smccc_res res; - arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3, - regs->x4, regs->x5, regs->x6, regs->x7, &res); + res = arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3, + regs->x4, regs->x5, regs->x6, regs->x7); regs->x0 = res.a0; regs->x1 = res.a1; diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c index f7c09520675e..f08d50c1fe38 100644 --- a/xen/arch/arm/platforms/exynos5.c +++ b/xen/arch/arm/platforms/exynos5.c @@ -249,7 +249,7 @@ static int exynos5_cpu_up(int cpu) iounmap(power); if ( secure_firmware ) - arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu, NULL); + arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu); return cpu_up_send_sgi(cpu); } diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/seattle.c index 64cc1868c24b..dfa5cf4265c0 100644 --- a/xen/arch/arm/platforms/seattle.c +++ b/xen/arch/arm/platforms/seattle.c @@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst = */ static void seattle_system_reset(void) { - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL); + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET); } static void seattle_system_off(void) { - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL); + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF); } PLATFORM_START(seattle, "SEATTLE") diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c index b6860a776031..634d0d7467cf 100644 --- a/xen/arch/arm/psci.c +++ b/xen/arch/arm/psci.c @@ -41,8 +41,8 @@ int call_psci_cpu_on(int cpu) { struct arm_smccc_res res; - arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), __pa(init_secondary), - &res); + res = arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), + __pa(init_secondary)); return PSCI_RET(res); } @@ -54,7 +54,7 @@ void call_psci_cpu_off(void) struct arm_smccc_res res; /* If successfull the PSCI cpu_off call doesn't return */ - arm_smccc_smc(PSCI_0_2_FN32_CPU_OFF, &res); + res = arm_smccc_smc(PSCI_0_2_FN32_CPU_OFF); panic("PSCI cpu off failed for CPU%d err=%d\n", smp_processor_id(), PSCI_RET(res)); } @@ -63,13 +63,13 @@ void call_psci_cpu_off(void) void call_psci_system_off(void) { if ( psci_ver > PSCI_VERSION(0, 1) ) - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL); + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF); } void call_psci_system_reset(void) { if ( psci_ver > PSCI_VERSION(0, 1) ) - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL); + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET); } static int __init psci_features(uint32_t psci_func_id) @@ -79,7 +79,7 @@ static int __init psci_features(uint32_t psci_func_id) if ( psci_ver < PSCI_VERSION(1, 0) ) return PSCI_NOT_SUPPORTED; - arm_smccc_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, &res); + res = arm_smccc_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id); return PSCI_RET(res); } @@ -116,9 +116,8 @@ static void __init psci_init_smccc(void) if ( psci_features(ARM_SMCCC_VERSION_FID) != PSCI_NOT_SUPPORTED ) { - struct arm_smccc_res res; + struct arm_smccc_res res = arm_smccc_smc(ARM_SMCCC_VERSION_FID); - arm_smccc_smc(ARM_SMCCC_VERSION_FID, &res); if ( PSCI_RET(res) != ARM_SMCCC_NOT_SUPPORTED ) smccc_ver = PSCI_RET(res); } @@ -191,7 +190,7 @@ static int __init psci_init_0_2(void) } } - arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION, &res); + res = arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION); psci_ver = PSCI_RET(res); /* For the moment, we only support PSCI 0.2 and PSCI 1.x */ diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index 3d2633237074..5e94daee0686 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -178,7 +178,7 @@ static bool optee_probe(void) return false; /* Check UID */ - arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), &resp); + resp = arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END)); if ( (uint32_t)resp.a0 != OPTEE_MSG_UID_0 || (uint32_t)resp.a1 != OPTEE_MSG_UID_1 || @@ -187,7 +187,7 @@ static bool optee_probe(void) return false; /* Read number of threads */ - arm_smccc_smc(OPTEE_SMC_GET_THREAD_COUNT, &resp); + resp = arm_smccc_smc(OPTEE_SMC_GET_THREAD_COUNT); if ( resp.a0 == OPTEE_SMC_RETURN_OK ) { max_optee_threads = resp.a1; @@ -209,7 +209,7 @@ static bool optee_probe(void) * call. It will return OPTEE_SMC_RETURN_UNKNOWN_FUNCTION if * OP-TEE have no virtualization support enabled. */ - arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, 0, 0, 0, 0, 0, 0, 0, &resp); + resp = arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, 0, 0, 0, 0, 0, 0, 0); if ( resp.a0 == OPTEE_SMC_RETURN_UNKNOWN_FUNCTION ) return false; @@ -243,8 +243,8 @@ static int optee_domain_init(struct domain *d) * * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_smc() */ - arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0, 0, - &resp); + resp = arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), + 0, 0, 0, 0, 0, 0); if ( resp.a0 != OPTEE_SMC_RETURN_OK ) { printk(XENLOG_WARNING "%pd: Unable to create OPTEE client: rc = 0x%X\n", @@ -681,8 +681,8 @@ static int optee_relinquish_resources(struct domain *d) * * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_smc() */ - arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0, 0, - &resp); + resp = arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), + 0, 0, 0, 0, 0, 0); ASSERT(!spin_is_locked(&ctx->lock)); ASSERT(!atomic_read(&ctx->call_count)); @@ -1171,15 +1171,15 @@ static void do_call_with_arg(struct optee_domain *ctx, { struct arm_smccc_res res; - arm_smccc_smc(a0, a1, a2, a3, a4, a5, 0, OPTEE_CLIENT_ID(current->domain), - &res); + res = arm_smccc_smc(a0, a1, a2, a3, a4, a5, 0, + OPTEE_CLIENT_ID(current->domain)); if ( OPTEE_SMC_RETURN_IS_RPC(res.a0) ) { while ( handle_rpc_return(ctx, &res, regs, call) == -ERESTART ) { - arm_smccc_smc(res.a0, res.a1, res.a2, res.a3, 0, 0, 0, - OPTEE_CLIENT_ID(current->domain), &res); + res = arm_smccc_smc(res.a0, res.a1, res.a2, res.a3, 0, 0, 0, + OPTEE_CLIENT_ID(current->domain)); if ( !OPTEE_SMC_RETURN_IS_RPC(res.a0) ) break; @@ -1619,8 +1619,8 @@ static void handle_exchange_capabilities(struct cpu_user_regs *regs) caps = get_user_reg(regs, 1); caps &= OPTEE_KNOWN_NSEC_CAPS; - arm_smccc_smc(OPTEE_SMC_EXCHANGE_CAPABILITIES, caps, 0, 0, 0, 0, 0, - OPTEE_CLIENT_ID(current->domain), &resp); + resp = arm_smccc_smc(OPTEE_SMC_EXCHANGE_CAPABILITIES, caps, 0, 0, 0, 0, 0, + OPTEE_CLIENT_ID(current->domain)); if ( resp.a0 != OPTEE_SMC_RETURN_OK ) { set_user_reg(regs, 0, resp.a0); return; @@ -1664,8 +1664,8 @@ static bool optee_handle_call(struct cpu_user_regs *regs) return true; case OPTEE_SMC_CALLS_UID: - arm_smccc_smc(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, - OPTEE_CLIENT_ID(current->domain), &resp); + resp = arm_smccc_smc(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, + OPTEE_CLIENT_ID(current->domain)); set_user_reg(regs, 0, resp.a0); set_user_reg(regs, 1, resp.a1); set_user_reg(regs, 2, resp.a2); @@ -1673,15 +1673,15 @@ static bool optee_handle_call(struct cpu_user_regs *regs) return true; case OPTEE_SMC_CALLS_REVISION: - arm_smccc_smc(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, 0, - OPTEE_CLIENT_ID(current->domain), &resp); + resp = arm_smccc_smc(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, 0, + OPTEE_CLIENT_ID(current->domain)); set_user_reg(regs, 0, resp.a0); set_user_reg(regs, 1, resp.a1); return true; case OPTEE_SMC_CALL_GET_OS_UUID: - arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_UUID, 0, 0, 0, 0, 0, 0, - OPTEE_CLIENT_ID(current->domain),&resp); + resp = arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_UUID, 0, 0, 0, 0, 0, 0, + OPTEE_CLIENT_ID(current->domain)); set_user_reg(regs, 0, resp.a0); set_user_reg(regs, 1, resp.a1); set_user_reg(regs, 2, resp.a2); @@ -1689,21 +1689,21 @@ static bool optee_handle_call(struct cpu_user_regs *regs) return true; case OPTEE_SMC_CALL_GET_OS_REVISION: - arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_REVISION, 0, 0, 0, 0, 0, 0, - OPTEE_CLIENT_ID(current->domain), &resp); + resp = arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_REVISION, 0, 0, 0, 0, 0, 0, + OPTEE_CLIENT_ID(current->domain)); set_user_reg(regs, 0, resp.a0); set_user_reg(regs, 1, resp.a1); return true; case OPTEE_SMC_ENABLE_SHM_CACHE: - arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, - OPTEE_CLIENT_ID(current->domain), &resp); + resp = arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, + OPTEE_CLIENT_ID(current->domain)); set_user_reg(regs, 0, resp.a0); return true; case OPTEE_SMC_DISABLE_SHM_CACHE: - arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, - OPTEE_CLIENT_ID(current->domain), &resp); + resp = arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, + OPTEE_CLIENT_ID(current->domain)); set_user_reg(regs, 0, resp.a0); if ( resp.a0 == OPTEE_SMC_RETURN_OK ) { free_shm_rpc(ctx, regpair_to_uint64(resp.a1, resp.a2)); diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 625d229396bb..6a5dcef2aa87 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1991,7 +1991,7 @@ void asmlinkage enter_hypervisor_from_guest_preirq(void) /* If the guest has disabled the workaround, bring it back on. */ if ( needs_ssbd_flip(v) ) - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); } /* @@ -2334,7 +2334,7 @@ void asmlinkage leave_hypervisor_to_guest(void) * If the guest wants it disabled, so be it... */ if ( needs_ssbd_flip(current) ) - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL); + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0); } /* -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:22:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:22:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408277.1640911 (Exim 4.92) (envelope-from ) id 1x2RzX-0000wb-EF; Fri, 04 Sep 2026 11:21:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408277.1640911; Fri, 04 Sep 2026 11:21:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RzX-0000wT-BK; Fri, 04 Sep 2026 11:21:55 +0000 Received: by outflank-mailman (input) for mailman id 1408277; Fri, 04 Sep 2026 11:21:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2RzW-0000wM-0h for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:21:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2RzV-005TRd-7W for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:21:53 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa9c6-8faa-0a2a0a5109dd-0a2a4504ba36-20 for ; Fri, 04 Sep 2026 13:21:53 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa9d0-b57f-0a2a45040019-b9ff1c2280f9-3 for ; Fri, 04 Sep 2026 13:21:53 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06c27448d000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 11:21:47 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 16EC781EB6; Fri, 4 Sep 2026 13:21:47 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=ex+LLQWjh+o/Lj8IoMloIXbAquyBJWjayQlF3PobzhI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=pF/Kz0NbQ26c8szqn9Mv4qbK55srubm/fhWYHlozirnSAfltMuqxxk7jZ86oZ2SvWTidh1pPI AaNADRRgby6AXvSJxCE60MbAVraA1+R2g1xEzEHLu1wHoFbi+GcFWJte5Wecj8fr7MBkVUjeCQu /+T29Jzh1xIasvQbRsjZU3znmN7ljZVpdb5Wmm1CNY9fey2hDbcWm5WLCItG4OC/fnc/SBiyxbs COwU06aXczzUS4W57iE2F48W5uxZ/uoanHwk8uZjJgbbGHQrdONj7Kw3qj9LRIGc94str/hQkKX bWEAc2QbSZKSs6KIi/WIiyM0c0EB0/I0fa3vHnLG6aPw== X-Zone-Loop: 3cfa604e0028f6eb007d8766b94f03a96dce402f3533 x-campaign-type: default x-transaction-id: 4a3bd6b0-86d5-4b70-b7a4-7a47cc5e63a8 x-swg-uid: 01-8614883e-b248-4cd1-b057-3b1f2222cf6a X-Mailer: Sweego Message-ID: <1788520907.8631fc262581453bbf619ec5b2062170.1a06c27448d000c4f3@vates.tech> x-swg-bid: 1788520907.8631fc262581453bbf619ec5b2062170.1a06c27448d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 4 Sep 2026 13:21:46 +0200 From: Anthony PERARD To: Julian Vetter Cc: xen-devel@lists.xenproject.org, Oleksii Kurochko , Community Manager , Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Stefano Stabellini , Juergen Gross , Teddy Astie , "Daniel P. Smith" Subject: Re: [PATCH v5 10/11] hvm/ioreq: Negotiate extended destination ID support per ioreq server References: <1788444605.8631fc262581453bbf619ec5b2062170.1a0679afc0d000c4f3@vates.tech> <1788444859.8631fc262581453bbf619ec5b2062170.1a0679edcb9000c4f3@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1788444859.8631fc262581453bbf619ec5b2062170.1a0679edcb9000c4f3@vates.tech> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.367a.437e12dfad5d5ca4.1a06c274222.6f0667637e7e1364=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788520907298 X-purgate-ID: tlsNG-ebf023/1788520913-C38C1B50-283442CE/0/0 X-purgate-type: clean X-purgate-size: 1692 ---=Part.367a.437e12dfad5d5ca4.1a06c274222.6f0667637e7e1364=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2026 at 04:14:08PM +0200, Julian Vetter wrote: > diff --git a/tools/include/xendevicemodel=2Eh b/tools/include/xendevicem= odel=2Eh > index 698d719119=2E=2E72994d1313 100644 > --- a/tools/include/xendevicemodel=2Eh > +++ b/tools/include/xendevicemodel=2Eh > @@ -44,12 +44,13 @@ int xendevicemodel_close(xendevicemodel_handle *dmod= ); > * @parm domid the domain id to be serviced > * @parm handle_bufioreq how should the IOREQ Server handle buffered > * requests (HVM_IOREQSRV_BUFIOREQ_*)? > + * @parm flags bitmask of XEN_DMOP_IOREQ_SERVER_* capability flags (0 i= f none)=2E > * @parm id pointer to an ioservid_t to receive the IOREQ Server id=2E > * @return 0 on success, -1 on failure=2E > */ > int xendevicemodel_create_ioreq_server( > xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq, > - ioservid_t *id); > + uint8_t flags, ioservid_t *id); You can't do that=2E libxendevicemodel is supposed to have a stable ABI so we can't change the prototype of existing functions=2E I think this will need a new function, with suffix "_v2", or any other different name=2E Then, why limit "flags" to 8bits ? Just change that to 64bits at no cost (maybe a little to check that all flags exist) and we won't need to look back, hopefully=2E Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.367a.437e12dfad5d5ca4.1a06c274222.6f0667637e7e1364=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:22:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:22:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408280.1640922 (Exim 4.92) (envelope-from ) id 1x2Rzz-0001Fg-Le; Fri, 04 Sep 2026 11:22:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408280.1640922; Fri, 04 Sep 2026 11:22:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Rzz-0001FZ-II; Fri, 04 Sep 2026 11:22:23 +0000 Received: by outflank-mailman (input) for mailman id 1408280; Fri, 04 Sep 2026 11:22:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Rzx-0001FD-Si for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:22:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Rzw-00AahF-S9 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:22:20 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aa9db-2eae-0a2a0a5409dd-0a2a45078164-34 for ; Fri, 04 Sep 2026 13:22:20 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aa9ea-b4ea-0a2a45070019-aa0a857cac51-3 for ; Fri, 04 Sep 2026 13:22:20 +0200 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-22-7HRuqFJcPhu4xQfw7Gujvw-1; Fri, 04 Sep 2026 07:22:17 -0400 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-48437090e74so586460f8f.2 for ; Fri, 04 Sep 2026 04:22:17 -0700 (PDT) Received: from redhat.com (IGLD-80-230-79-236.inter.net.il. [80.230.79.236]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485885bfe14sm5761659f8f.35.2026.09.04.04.22.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:22:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788520938; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DZtNHj4dJNQM8XNol7kcuN6tcN2rtdw5KbaZPWFxkZ8=; b=AIr/gL6OFTp1xK/r9Pgnw9sM2YdxfnZamYnlwwbTWSQpPGGIdP8fa+A7wISCxZoZRkil7N wFsveyohXqtYtKeLcPWTT7YmuTx5vOGMU1yIunG/Qn/3Cw4ctOT0EK0ZnxjQmbTw5/IXci oz5QTz6Z2PIGzHhmJ5BczirySKiAYno= X-MC-Unique: 7HRuqFJcPhu4xQfw7Gujvw-1 X-Mimecast-MFC-AGG-ID: 7HRuqFJcPhu4xQfw7Gujvw_1788520936 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788520936; x=1789125736; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=DZtNHj4dJNQM8XNol7kcuN6tcN2rtdw5KbaZPWFxkZ8=; b=CWEoxjxx/MEX9qWxFoxepyTLr62E+jdcEf20T0e1CdP5BJsWQG9XjSY5MlmEP75OPw mZdOJK0Wq4af778VuBIpjUIj/JNAR60tTuqmZDiwUKfNqq6TruitX0NKBp5mFSP9knHl T2fJonc7Zzowob0CJRayrXEdZokbQWXqlhrvcUtjpHKyH3Wc0fMUqDH9jtm/NnYWsdRX XPKD+SxoOC3jBTdyeQ8aFdw9Iu5V/QQUtzkbiLe2l239e5o3ihvDmgjj0NIhW7xre1Lz DvkaoH2PtRY81ZCm5+QcEnZksynTFxVtoaTF55xhKZesTyWNToMB17CszlY+jxGOxDqP S4RQ== X-Forwarded-Encrypted: i=1; AKwUvBxB8gyXEKznVN+4BmjDtSGHq8aGJOJigueAE7dO9vVKQ+ujN48YrSkZN9EzB2iA1h3cgZHUEPnNIwY=@lists.xenproject.org X-Gm-Message-State: AFuF++kWbiI2ogWgNl2jPq6ulDeFBR4L3vHPvH98xR8S5k/Iw2Liyx0U IwBCM7ei4Ddg7z8B3XI+irHjtjDenj9y3RkhE12rtuPugo1RYm7G+00/unepWZMliYGcU2o9s7p gSf32HTOKDPh00bs13IkzbU0ntIptgf26DoU/t7oXIwNLOXdyaD3okBecFB3EebHDxMMW X-Gm-Gg: AYBFou2aa4F6wzyN5JcwR9M1ebp/qipOcFoVGxHgglGd3S7r8G1EyjJbxYIC9sT3R6Q V1uCSXq7tCoJpOTS26xqlRk2YMvX/oX7jdIvpb7uE/G2MPnvi7VT0a70qtdx42Zx0WRy9isrsNm SdxgVMJHfBtUSu+R/uB35IOv8JODrX9cHaMhwjoxp2Eo3h8ZCbFwiYGzhDgV+4CyjUL4U2QfGKn OiWklan1U3+Q2Rqsowt6VVOV5ymL1nsslYjLieMgou0F+R5feVvUscp0NfOkA4Ru01hrc+x5Meq TOx5ZY2Dy8CAYx33OO5TIMPXUhYKhNoZrkdxLPeCZTdU6LswICpirTPBAn3pm8ethwklCT9BHFg IKiMe30GpJevxFmHOytZWDis= X-Received: by 2002:a05:6000:38c:b0:484:3fce:6ad2 with SMTP id ffacd0b85a97d-485872cd602mr9297372f8f.15.1788520935758; Fri, 04 Sep 2026 04:22:15 -0700 (PDT) X-Received: by 2002:a05:6000:38c:b0:484:3fce:6ad2 with SMTP id ffacd0b85a97d-485872cd602mr9297283f8f.15.1788520935123; Fri, 04 Sep 2026 04:22:15 -0700 (PDT) Date: Fri, 4 Sep 2026 07:22:10 -0400 From: "Michael S. Tsirkin" To: Igor Mammedov Cc: Dongli Zhang , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug Message-ID: <20260904072052-mutt-send-email-mst@kernel.org> References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> <20260903160401-mutt-send-email-mst@kernel.org> <20260904130709.6769caee@imammedo> MIME-Version: 1.0 In-Reply-To: <20260904130709.6769caee@imammedo> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: yozmuIOw72V5BfXifyuFKjwEZac17kosBAdrafa-GaM_1788520936 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788520940-A72DCAE4-D74C530F/0/0 X-purgate-type: clean X-purgate-size: 8918 On Fri, Sep 04, 2026 at 01:07:09PM +0200, Igor Mammedov wrote: > On Thu, 3 Sep 2026 16:17:20 -0400 > "Michael S. Tsirkin" wrote: > > > On Thu, Sep 03, 2026 at 05:28:35PM +0200, Igor Mammedov wrote: > > > On Wed, 26 Aug 2026 09:15:47 -0700 > > > Dongli Zhang wrote: > > > > > > > On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrang wrote: > > > > > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: > > > > >> Hot-unplugging a PCI device can require cooperation from the guest. For > > > > >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest > > > > >> eventually writes the ACPI PCI eject register. For PCIe native hotplug, > > > > >> QEMU notifies the guest through the PCIe hotplug mechanism and waits for > > > > >> the slot unplug flow to complete. Only after that completion does QEMU > > > > >> unrealize the device and emit DEVICE_DELETED. > > > > >> > > > > >> This can leave a device stuck in the unplug pending state when the guest > > > > >> does not cooperate. Examples include: > > > > >> > > > > >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is > > > > >> unavailable. > > > > >> > > > > >> 2. The guest is stalled and cannot handle the hot-unplug event. For > > > > >> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this > > > > >> for ACPI-based hot-unplug. > > > > >> > > > > >> 3. The device was attached to a slot that the guest cannot use. For > > > > >> example, a pcie-root-port only supports slot 0. If a device is added to a > > > > >> non-zero slot below a pcie-root-port, the guest may never discover the > > > > >> device and therefore may never complete the unplug request. > > > > > > all of above is actually expected, no (functioning) driver => no hotplug/unplug. > > > it's the guest problem. Once device it exposed to guest its life-cycle > > > not longer owned by QEMU. > > > > > > That's what one would see in real hw as well, you press eject button > > > but it will not do anything if OS doesn't process it. > > > also see comment at the end. > > > > > > > >> > > > > >> The non-zero slot case has also been discussed in: > > > > >> > > > > >> hw/pci: warn when PCIe device is plugged into non-zero slot of downstream port > > > > >> https://gitlab.com/qemu-project/qemu/-/commit/ > > > > > ca92eb5defcf9d1c2106341744a73a03cf26e824 > > > > >> > > > > >> hw/pci: add comment to explain checking for available function 0 in pci hotplug > > > > >> https://gitlab.com/qemu-project/qemu/-/ > > > > > commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5 > > > > >> > > > > >> pci: don't skip function 0 occupancy verification for devfn auto assign > > > > >> https://gitlab.com/qemu-project/qemu/-/commit/ > > > > > e228d62b4af29bca698ec57efdceb46f392f5444 > > > > >> > > > > >> For example, if root-port.1 is a pcie-root-port, the following command adds > > > > >> a vhost-scsi-pci device to an invalid slot: > > > > >> > > > > >> (qemu) device_add vhost-scsi-pci,id=scsi01,wwpn=naa.5001405324af0985,bus=root-port.1,addr=01.0 > > > > >> warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent device only allows plugging into slot 0. > > > > > > > > > > This rather looks like it should be a fatal error, not a mere warning. > > > > > > > > > > If I follow the commit ca92eb5def it links to https://bugzilla.redhat.com/show_bug.cgi?id=2128929 > > > > > which states that this configuration is going to lead to a crash in > > > > > QEMU on guest OS shutdown. IMHO that crash is sufficient to justify > > > > > making this a fatal error. > > > > > > > > > > If we actually wanted this to remain a warning, then that shutdown > > > > > crash would need to be fixed. > > > > > > > > > > > > > Thank you very much! > > > > > > > > I see that the issue has been fixed. The ticket mentions the following. > > > > > > > > "What I am observing is that it seems when the slot ID != 0, the guest OS seems > > > > to ignore this and we never seem to hit ich9_pm_device_unplug_cb()." > > > > > > > > Based on my experience and evaluation, ACPI-based hotplug is more likely to > > > > encounter an issue where the guest VM does not respond to an unplug operation. > > > > > > I'm not sure it's a good idea to delete device when guest still thinks it's there > > > (you can make guesses on QEMU side if it's in use, how useful those are is questionable). > > > > > > as far as I know, ACPI hotplug has no notion of surprise removal (pls educate me if it's not the case), > > > > why would it not? > > > > how do you think you can pull a laptop out of a dock? > > I expect bus check + _STA and config space saying it is gone > > will do exactly that. > > > > > > Here's linux code: > > static void acpiphp_check_bridge(struct acpiphp_bridge *bridge) > > { > > struct acpiphp_slot *slot; > > > > /* Bail out if the bridge is going away. */ > > if (bridge->is_going_away) > > return; > > > > if (bridge->pci_dev) > > pm_runtime_get_sync(&bridge->pci_dev->dev); > > > > list_for_each_entry(slot, &bridge->slots, node) { > > struct pci_bus *bus = slot->bus; > > struct pci_dev *dev, *tmp; > > > > if (slot_no_hotplug(slot)) { > > ; /* do nothing */ > > } else if (device_status_valid(get_slot_status(slot))) { > > /* remove stale devices if any */ > > list_for_each_entry_safe_reverse(dev, tmp, > > &bus->devices, bus_list) > > if (PCI_SLOT(dev->devfn) == slot->device) > > trim_stale_devices(dev); > > > > /* configure all functions */ > > enable_slot(slot, true); > > } else { > > disable_slot(slot); > > } > > } > > > > if (bridge->pci_dev) > > pm_runtime_put(&bridge->pci_dev->dev); > > } > > > > > > so weirdly it wants bus check on a parent bus, otherwise it will > > not trim devices? probably a bug, but easy to work around. > > Modern docks would use native pcie surprise removal path. > > As for ACPI, my old laptop, had an unlock button => _LCK > and that relied on OS processing ACPI events, not so surprise. > > There might have been ACPI/hybrid docks that did surprise removal, > but then one need to find one and model after that instead of > just blanket force removal. (likely out come would a doc device > support only, not an arbitrary device removal) > > (not the case described in this series, though. hence my request to clarify usecase) > > from what I see in spec there is _RMV method that says that device > supports surprise removal that can be used for devices that support it. > However I would hesitate very much to blank apply it to every PCI device. > (it's not even realistic to ask for proving safe tear down across various > drivers and OSes/versions) > > Rather than a knee jerk treatment of misconfig consequences, > I'd rather see patches to prevent misconfig in the 1st place > (subj to deprecation but doable). > > As for the cases where OS mis-behaves (apcihp thread starvation,...), > fixing guest to follow hotplug contract is a proper place to do it. > > On QEMU side we have it covered as well. If unplug was not processed, > mgmt is free to repeat action. Sorry if I am unclear. I just meant that it looks like we can support surprise removal with ACPI just by reporting bus check events on the parent. > > > > so I wouldn't do what you are proposing here at all, it's basically asking for disaster to happen. > > > And all this is basically for dealing with abused qemu flexibility. > > > > > > Please (re)formulate usecase and make it more clear as what is eludes me > > > no matter how many times i've read this cover letter. > > > > > > On positive note: > > > > > > What you can try to implement is native PCI-E support for surprise removal. > > > How hard that would be I don't know. And I would well expect if one deviates from > > > real hw expectations/configs (such as not 0 slot/partial func removal), > > > one would quickly stumble upon issues as that's not what what vendors write/test > > > drivers for. > > > > > > Even if it's not likely to be used in practice (guest still might not support it), > > > it may serve as test-bed for guest drivers. > > > > > > > Thank you very much! > > > > > > > > Dongli Zhang > > > > > > From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:25:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:25:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408294.1640931 (Exim 4.92) (envelope-from ) id 1x2S2q-0002Bt-2N; Fri, 04 Sep 2026 11:25:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408294.1640931; Fri, 04 Sep 2026 11:25:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2S2p-0002Bm-VE; Fri, 04 Sep 2026 11:25:19 +0000 Received: by outflank-mailman (input) for mailman id 1408294; Fri, 04 Sep 2026 11:25:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2S2o-0002Ba-EW for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:25:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2S2n-009Sh8-Qo for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:25:17 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aaa86-8faa-0a2a0a5109dd-0a2a4505e84e-36 for ; Fri, 04 Sep 2026 13:25:17 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aaa9d-4cb1-0a2a45050019-b9ff1c22a131-3 for ; Fri, 04 Sep 2026 13:25:17 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06c2a6d8f000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 11:25:15 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 605EF81C9E; Fri, 4 Sep 2026 13:25:14 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=aZ5tMyDuKyvQOmdQm90h6A495RKd0PTPyeo/OaaEC4w=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=mHlyRraUohNdzpcWSPwjxfIq18hPCX+IXom65A//duTKdr6EsOtuYTYTK0G2AHyo6czsdZAgS X/mge+PC3EKB7Gt41uu7DzWhqkb3KNfc1bNyp/Cq0SXmx1GFwn4IW7hHS515MrsW7zYGMvba4bp 39m0nKT82x/R2wl3oUn2AdNf/pCSFPdPzgoTfmQiGEpJ2nWwz0cq3eooIoZf2S9BVk9U5kaZLTI CqUAcJiOXoYwXNsCuK2o4wEoUNKlzDfX+IkqRg2gQ1Lsfy9m42d6kfn1sapwbcuoXmbnfnYlCX+ 0sozMKSKQ9IgwfOhv28qFBqucrNUKh6WobaAJxvk4vqQ== X-Zone-Loop: 972f0256f832ead3680236e38d977a5665b872abc86c x-campaign-type: default x-transaction-id: 0433590e-9dd6-4a5f-8683-e8391a126cec x-swg-uid: 01-7e0903f7-d3e7-4bbe-8b93-3244d29af3e8 X-Mailer: Sweego Message-ID: <1788521115.8631fc262581453bbf619ec5b2062170.1a06c2a6d8f000c4f3@vates.tech> x-swg-bid: 1788521115.8631fc262581453bbf619ec5b2062170.1a06c2a6d8f000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 14/39] xen/riscv: introduce vintc_ctxt_switch_{from,to}() From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <678236568970b18a1924a76588c4c50f9bf0c659.1787838835.git.oleksii.kurochko@gmail.com> References: <678236568970b18a1924a76588c4c50f9bf0c659.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 04 Sep 2026 13:25:07 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788521114; l=915; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=+PSoSQsMfJf1UsZgvzap2TWt7h1iD76VWcmF0+vMSBY=; b=tWQW40yZpiCTdeZGOGsMpR8USsIyXyevHl6r3DY+dRTW6Y4TkdueBrI+k9X7wYjsw1y0KjVc1 TO61tOpNWElDSJt9KCGn3EUcLKjCg8LjkXqF7dx/Gfa7/9UzkSqEovP X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788521114591 X-purgate-ID: tlsNG-c201ff/1788521117-F44A42A1-531B777C/0/0 X-purgate-type: clean X-purgate-size: 915 > Virtual interrupt controller state must be preserved across vCPU context > switches. > > Introduce vintc_ctxt_switch_{from,to}() wrappers around new > ctxt_switch_{from,to}() hooks in struct vintc_ops, and call them from the > context switch path, so that this state can be saved/restored without > knowing which vINTC variant a domain uses. > > No vINTC variant implements the hooks yet: the vAPLIC implementation is > added separately. So this patch couldn't be applied alone as, at the time of this commit, you only set in vaplic.c: static const struct vintc_ops vintc_ops = { .vcpu_init = vcpu_imsic_init, .vcpu_deinit = vcpu_imsic_deinit, }; So ops->ctxt_switch_from(v) or ops->ctxt_switch_to(v) will try to deference NULL pointer causing segfault. I don't know if it's matter but worth to mention somewhere. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:33:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:33:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408307.1640938 (Exim 4.92) (envelope-from ) id 1x2SAa-0004hv-SI; Fri, 04 Sep 2026 11:33:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408307.1640938; Fri, 04 Sep 2026 11:33:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2SAa-0004ho-PG; Fri, 04 Sep 2026 11:33:20 +0000 Received: by outflank-mailman (input) for mailman id 1408307; Fri, 04 Sep 2026 11:33:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2SAZ-0004gi-3M for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:33:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2SAX-000O2A-Ux for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:33:17 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aac71-bab6-0a2a0a5309dd-0a2a450cade0-18 for ; Fri, 04 Sep 2026 13:33:17 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aac7d-f479-0a2a450c0019-b9ff1c22847f-3 for ; Fri, 04 Sep 2026 13:33:17 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06c31b828000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 11:33:12 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id E952981E01; Fri, 4 Sep 2026 13:33:11 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=t9BuHE8obK9dSOMYNjEQsWnEnAKXBhY9xAbIFVOW7EE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=XHWY6VqyM9PPyHiriRoCwyz0id/59azo44BfxwPELGijo5j4wO+gI4kOhic7JUj30JytzgJqh pepErlmG+12BLeefAH9SIi63o0GmQhxTmXqMC5XzZ+JYKMch9gFEh3QUNWC7l3+UKgHKeGzXegg u3ctK6cwKu7WT9SS8EjWBeeUaE+tbQiGLhzaEc9gXCnAS6YJ+ANykCblzn7RBQkeni2JBLXBT+M oM8EHEdXnbx/LXDB1VscO2R56wC+SpOm1PsN3oCK3izOMEsgfL/2cCtvc+4czaQBxbLNYMhCHvx pnJu3Qz1m9co0QL/PYHc85IFarZ7qB6mehsaVZZxQr7g== X-Zone-Loop: c1421a106663301ef218a06aa98c82b90cb2cf80646d x-campaign-type: default x-transaction-id: 2983af79-6a5d-445e-b1cd-36e3e0178a06 x-swg-uid: 01-db399680-487d-4c54-a8b2-3034c74d0bbb X-Mailer: Sweego Message-ID: <1788521592.8631fc262581453bbf619ec5b2062170.1a06c31b828000c4f3@vates.tech> x-swg-bid: 1788521592.8631fc262581453bbf619ec5b2062170.1a06c31b828000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 15/39] xen/riscv: add IMSIC vCPU context switch handlers From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <867af892784c295296cdf63e0371fa1b7ed7a1e7.1787838835.git.oleksii.kurochko@gmail.com> References: <867af892784c295296cdf63e0371fa1b7ed7a1e7.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 04 Sep 2026 13:33:04 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788521591; l=4122; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=kJkOyO+syx8smwQKel0X8vGDqkIGhKnScfznNqOrnns=; b=cQTPSKltBQ8XHFtji/AdOP22wZZUkOJnnb1KWruFfYoDMVbnZW0z5j7kDwQDYyIJZ1m6CD/NN UBwJI6X/qpEAe80isJdspzpB5sRhfQSGIzyplBxpbDzS9uUJEtlTt3k X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788521592154 X-purgate-ID: tlsNG-d25034/1788521597-50B3DA5B-3F773B20/10/73395122804 X-purgate-type: spam X-purgate-size: 4122 > IMSIC state currently needs to track only which physical CPU owns a vCPU's > IMSIC guest interrupt file, as the CPU id is part of the physical address > the file is mapped at. > > Add imsic_ctxt_switch_from() to record that CPU when a vCPU is switched > out. A vCPU running on the s/w VS-file has no h/w file bound to a CPU, so > there is nothing to record for it. The recorded value stays unused until > vCPU migration support, which needs it to find the file to move away from, > is added later. > > imsic_ctxt_switch_to() has nothing to do: by the time a vCPU is switched > in, VGEIN is already assigned to it and its guest interrupt file is already > mapped. Work is only required once a vCPU can move to a different CPU, > which means recalculating VGEIN and remapping the file; that is handled > separately by the vCPU migration patches. > > Install both as the ctxt_switch_{from,to} hooks of struct vintc_ops. MSI > delivery is the only mode Xen supports ( aplic_init() panics on an APLIC > without an "msi-parent" property, and a guest's domaincfg.DM reads back as > a fixed one) so the vAPLIC state to save and restore is always the IMSIC > one and no vAPLIC-level forwarder is needed. Being indirect call targets, > both handlers get cf_check. > > Co-developed-by: Romain Caritey > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index ad0a220eda..3787f270d8 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -342,6 +343,28 @@ static int __init imsic_parse_node(const struct dt_device_node *node, > return 0; > } > > +void cf_check imsic_ctxt_switch_from(struct vcpu *v) > +{ > + struct vimsic_state *imsic_state = v->arch.vimsic_state; > + unsigned long flags; > + > + /* > + * A vCPU using the s/w IMSIC VS-file (guest_file_id == 0) has no h/w > + * VS-file bound to a physical CPU, so there is no location to record. > + */ > + if ( !vcpu_guest_file_id(v) ) > + return; > + > + write_lock_irqsave(&imsic_state->vsfile_lock, flags); > + imsic_state->vsfile_cpu = v->processor; > + write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > +} > + > +void cf_check imsic_ctxt_switch_to(struct vcpu *v) > +{ > + /* Nothing to do */ > +} > + > int cf_check vcpu_imsic_init(struct vcpu *v) > { > struct vimsic_state *imsic_state; > diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h > index 93f9e44c7d..73129c3c9e 100644 > --- a/xen/arch/riscv/include/asm/imsic.h > +++ b/xen/arch/riscv/include/asm/imsic.h > @@ -109,4 +109,7 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v); > > int vimsic_make_domu_dt_node(struct kernel_info *kinfo, unsigned int *phandle); > > +void imsic_ctxt_switch_from(struct vcpu *v); > +void imsic_ctxt_switch_to(struct vcpu *v); > + > #endif /* ASM_RISCV_IMSIC_H */ > diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c > index 8726f7203d..6c60fe2baf 100644 > --- a/xen/arch/riscv/vaplic.c > +++ b/xen/arch/riscv/vaplic.c > @@ -422,6 +422,13 @@ static const struct mmio_handler_ops vaplic_mmio_ops = { > static const struct vintc_ops vintc_ops = { > .vcpu_init = vcpu_imsic_init, > .vcpu_deinit = vcpu_imsic_deinit, > + /* > + * MSI delivery is the only supported mode: aplic_init() panics on an > + * APLIC without an "msi-parent", so the vAPLIC state to save and restore > + * is always the IMSIC one. > + */ > + .ctxt_switch_from = imsic_ctxt_switch_from, > + .ctxt_switch_to = imsic_ctxt_switch_to, Maybe this patch could be merged with previous one: patch 50fe9554e1c0 ("xen/riscv: introduce vintc_ctxt_switch_{from,to}()") -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:40:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:40:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408296.1640948 (Exim 4.92) (envelope-from ) id 1x2SH9-000710-LG; Fri, 04 Sep 2026 11:40:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408296.1640948; Fri, 04 Sep 2026 11:40:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2SH9-00070t-IJ; Fri, 04 Sep 2026 11:40:07 +0000 Received: by outflank-mailman (input) for mailman id 1408296; Fri, 04 Sep 2026 11:25:33 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2S33-0002TS-FV for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:25:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2S32-009Sod-Qy for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:25:32 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9aaa96-8faa-0a2a0a5109dd-0a2a45068016-38 for ; Fri, 04 Sep 2026 13:25:32 +0200 Received: from [209.85.216.43] (helo=mail-pj1-f43.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9aaaab-195a-0a2a45060019-d155d82bb0ae-3 for ; Fri, 04 Sep 2026 13:25:32 +0200 Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-398a4dcf289so1030679a91.2 for ; Fri, 04 Sep 2026 04:25:32 -0700 (PDT) Received: from volcano9f6e-hostos.amd.com ([165.204.217.251]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3339ac24d7esm8970969eec.15.2026.09.04.04.25.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 04:25:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788521131; x=1789125931; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=545O0WDL5qNzN0FtnQz+2XQixX5ANxvieXurE5YLToc=; b=V8mnPLnIBndK1ZsdrmWe+sN2cqMZZq6A4T1xIQv9M1NT7a/DQQzIefD+7oAJPvlbxQ UA2HIUPj7dpNxDzLT2jUwF5IfBMEAT/dmLuhNluPPOmCD5L1d7R2bbhxfmztzWunH6xN 5AtquoIWi6Ga5LxCrZ61E0HDvQhx+N74IQz4cH7UGuE7ywp3eJd0G7PtLoXv1B1ElaWB +bSNGyAOD6ddLuOFt4TYRFXrl4TcZjmEpfU8HsIVaWjERovAY9oJ3lSHxD3bhnmefASY zrnjUq/7nfCM3XWhF3ymK2weiXNG9S8CAt1ZMJY/ASSm33J5Vxs1RxV20EHCU/pzGBwr 4gqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788521131; x=1789125931; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=545O0WDL5qNzN0FtnQz+2XQixX5ANxvieXurE5YLToc=; b=TOZPaPwb+8QEwhHDr+1ZPaxi1Yll3Kah7mjfO8xa83+UzAXPFMOOQO5oBcEoMbqeKO pU1huIlR5NHA41fK5q0YaeSORfBMUpgNcnYx24wmhbwTiN4TVvM1Oo+7kCL1mztJ9TI1 EPFr5iVobaj/JrX6p0dmZn8ZCkADJflf6h+p02a/DPFaSVrOIDqJXvfMGBPdTy6bArL5 8CFAncqgSUtBzn2x9nVL4wExzdSrQ+52keQIofg7AAUejw80DPflpNxzDSSa09+JC+VU ysGbvpniwidIAkcPJd3otOzO1iP5/l+lc6mGAteVnc6x/r6Gt1XM6nAEYHdGPV37vbKT xipg== X-Forwarded-Encrypted: i=1; AKwUvBxQXQPyXtJ7QDPuUOnvF5zt+YQembMI8lsCIJRR3epS1qqzniWj1hWIPu2GonTrNCRaWqZWySekaQA=@lists.xenproject.org X-Gm-Message-State: AFuF++kLx5hcjhiTmtAUhvCD2CUcrqqaLzGJ6OpgetKWRbp15iTl2A8y LAzQPQaT+1SzUaCL9IPNahgj2shLSV42QSjzJ7DtL4TmvTn3unvWS8nDvxPLcvA8 X-Gm-Gg: AYBFou0SDnTFydPnqu0fGJ4+1RA5aU/8uEIWh7VDgRsaxn46k7tppVTDzkpLZEPM6vV ziUUO8mIE1o5SWUT8K3Nd59PU98SDJPV3sbhdvUehMuc5Xyxk/5HFFz2qlICp2UpTZNKFR/Zqbu riOjycrWK4248lsDm42TSUtok8XQTvlkw4ZTtBEv9uZZRFWZz4HUzeiy7qbdwOxSXLJejx3Khcz URRJRNxggCqQ0Eu6UNDbUfn+BO3FTIYn6PyefCQIO8WKF7W68o+gZhbu4+MBsMO2Y8pC75eHMBN DwWIKKtctRvtsEZakldW1JBiC085JZIzQ1yMLuKPgjfU+tsH9axbBfINgrnCu+A9smjr4HjePuO o+oagWvb/nej2TBUPaI6dtQREiclFWENI4dVR6VaMmnbiMMzeBeBVK82V1OSjXMmposW7gAVA0u HgCHcHD1xV3AtLfIvHM1pa9AxIEvGtm5KZ5OwmioDmj8GAI5+RfuAmHmNsHbwWLW3dt5s//buc6 g2+TyVTtBVNocE= X-Received: by 2002:a17:90b:2b43:b0:38e:c7b0:84ad with SMTP id 98e67ed59e1d1-39b25ed34f3mr9759398a91.0.1788521130565; Fri, 04 Sep 2026 04:25:30 -0700 (PDT) From: Hemanth Selam To: Russell King , Stefano Stabellini Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: [PATCH 1/2] ARM: fix typos in comments Date: Fri, 4 Sep 2026 16:55:17 +0530 Message-ID: <20260904112522.1426-2-hemanth.selam@gmail.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20260904112522.1426-1-hemanth.selam@gmail.com> References: <20260904112522.1426-1-hemanth.selam@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1788521132-F460277B-BA1FCDD2/0/0 X-purgate-type: clean X-purgate-size: 6846 Fix typos in comments, reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam --- arch/arm/boot/compressed/head.S | 2 +- arch/arm/include/asm/uaccess.h | 2 +- arch/arm/kernel/cpuidle.c | 2 +- arch/arm/mm/cache-l2x0.c | 2 +- arch/arm/mm/context.c | 4 ++-- arch/arm/probes/decode.h | 2 +- arch/arm/probes/kprobes/opt-arm.c | 4 ++-- arch/arm/probes/kprobes/test-core.c | 2 +- arch/arm/xen/hypercall.S | 4 ++-- 9 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 9f406e9c0ea6..e117f2b4dea9 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -955,7 +955,7 @@ call_cache_fn: adr r12, proc_types /* * On v7-M the processor id is located in the V7M_SCB_CPUID * register, but as cache handling is IMPLEMENTATION DEFINED on - * v7-M (if existant at all) we just return early here. + * v7-M (if existent at all) we just return early here. * If V7M_SCB_CPUID were used the cpu ID functions (i.e. * __armv7_mmu_cache_{on,off,flush}) would be selected which * use cp15 registers that are not implemented on v7-M. diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h index 1593cf3b9800..9805001f9d72 100644 --- a/arch/arm/include/asm/uaccess.h +++ b/arch/arm/include/asm/uaccess.h @@ -24,7 +24,7 @@ * These two functions allow hooking accesses to userspace to increase * system integrity by ensuring that the kernel can not inadvertantly * perform such accesses (eg, via list poison values) which could then - * be exploited for priviledge escalation. + * be exploited for privilege escalation. */ #if defined(CONFIG_CPU_SW_DOMAIN_PAN) diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c index fba1f8bb03b5..784457ac7b2b 100644 --- a/arch/arm/kernel/cpuidle.c +++ b/arch/arm/kernel/cpuidle.c @@ -79,7 +79,7 @@ static const struct cpuidle_ops *__init arm_cpuidle_get_ops(const char *method) * cpuidle_ops are tagged __initconst and will be unloaded after the init * process. * - * Return 0 on sucess, -ENOENT if no 'enable-method' is defined, -EOPNOTSUPP if + * Return 0 on success, -ENOENT if no 'enable-method' is defined, -EOPNOTSUPP if * no cpuidle_ops is registered for the 'enable-method', or if either init or * suspend callback isn't defined. */ diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index 470867160076..0eaaf99d3d11 100644 --- a/arch/arm/mm/cache-l2x0.c +++ b/arch/arm/mm/cache-l2x0.c @@ -1381,7 +1381,7 @@ static void aurora_pa_range(unsigned long start, unsigned long end, unsigned long flags; /* - * round start and end adresses up to cache line size + * round start and end addresses up to cache line size */ start &= ~(CACHE_LINE_SIZE - 1); end = ALIGN(end, CACHE_LINE_SIZE); diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c index 4204ffa2d104..95d477cab0f5 100644 --- a/arch/arm/mm/context.c +++ b/arch/arm/mm/context.c @@ -76,7 +76,7 @@ void a15_erratum_get_cpumask(int this_cpu, struct mm_struct *mm, #ifdef CONFIG_ARM_LPAE /* - * With LPAE, the ASID and page tables are updated atomicly, so there is + * With LPAE, the ASID and page tables are updated atomically, so there is * no need for a reserved set of tables (the active ASID tracking prevents * any issues across a rollover). */ @@ -243,7 +243,7 @@ void check_and_switch_context(struct mm_struct *mm, struct task_struct *tsk) check_vmalloc_seq(mm); /* - * We cannot update the pgd and the ASID atomicly with classic + * We cannot update the pgd and the ASID atomically with classic * MMU, so switch exclusively to global mappings to avoid * speculative page table walking with the wrong TTBR. */ diff --git a/arch/arm/probes/decode.h b/arch/arm/probes/decode.h index facc889d05ee..b09c44ba1030 100644 --- a/arch/arm/probes/decode.h +++ b/arch/arm/probes/decode.h @@ -250,7 +250,7 @@ enum decode_reg_type { REG_TYPE_NOPCWB, /* No PC if load/store write-back flag also set */ /* The following types are used when the encoding for PC indicates - * another instruction form. This distiction only matters for test + * another instruction form. This distinction only matters for test * case coverage checks. */ REG_TYPE_NOPCX, /* Register must not be PC */ diff --git a/arch/arm/probes/kprobes/opt-arm.c b/arch/arm/probes/kprobes/opt-arm.c index 966c6042c5ad..a3aed8c01c98 100644 --- a/arch/arm/probes/kprobes/opt-arm.c +++ b/arch/arm/probes/kprobes/opt-arm.c @@ -210,11 +210,11 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op, struct kprobe *or * * So the maximum forward branch should be: * (0x007fffff << 2) = 0x01fffffc = 0x1fffffc - * The maximum backword branch should be: + * The maximum backward branch should be: * (0xff800000 << 2) = 0xfe000000 = -0x2000000 * * We can simply check (rel & 0xfe000003): - * if rel is positive, (rel & 0xfe000000) shoule be 0 + * if rel is positive, (rel & 0xfe000000) should be 0 * if rel is negitive, (rel & 0xfe000000) should be 0xfe000000 * the last '3' is used for alignment checking. */ diff --git a/arch/arm/probes/kprobes/test-core.c b/arch/arm/probes/kprobes/test-core.c index 2de28088dac8..531fec3621b8 100644 --- a/arch/arm/probes/kprobes/test-core.c +++ b/arch/arm/probes/kprobes/test-core.c @@ -125,7 +125,7 @@ * .byte ARG_TYPE_END * .byte TEST_ISA @ flags, including ISA being tested * .short 50f-0f @ offset of 'test_before' - * .short 2f-0f @ offset of 'test_after2' (if relevent) + * .short 2f-0f @ offset of 'test_after2' (if relevant) * .short 99f-0f @ offset of 'test_done' * @ start of test case code... * 0: diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S index f794dac9859a..b8b6192e310e 100644 --- a/arch/arm/xen/hypercall.S +++ b/arch/arm/xen/hypercall.S @@ -32,9 +32,9 @@ /* * The Xen hypercall calling convention is very similar to the ARM - * procedure calling convention: the first paramter is passed in r0, the + * procedure calling convention: the first parameter is passed in r0, the * second in r1, the third in r2 and the fourth in r3. Considering that - * Xen hypercalls have 5 arguments at most, the fifth paramter is passed + * Xen hypercalls have 5 arguments at most, the fifth parameter is passed * in r4, differently from the procedure calling convention of using the * stack for that case. * -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 11:58:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 11:58:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408344.1640956 (Exim 4.92) (envelope-from ) id 1x2SYh-0002dh-2K; Fri, 04 Sep 2026 11:58:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408344.1640956; Fri, 04 Sep 2026 11:58:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2SYg-0002da-W3; Fri, 04 Sep 2026 11:58:14 +0000 Received: by outflank-mailman (input) for mailman id 1408344; Fri, 04 Sep 2026 11:58:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2SYg-0002dI-76 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 11:58:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2SYf-009eI3-Jh for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 13:58:13 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ab24d-bab6-0a2a0a5309dd-0a2a4509ec98-14 for ; Fri, 04 Sep 2026 13:58:13 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ab255-be1a-0a2a45090019-d155dd30ccef-3 for ; Fri, 04 Sep 2026 13:58:13 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-48584dc164fso870137f8f.0 for ; Fri, 04 Sep 2026 04:58:13 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883c074asm5693592f8f.23.2026.09.04.04.58.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 04:58:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788523093; x=1789127893; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=MLRioPwh51wHlSBOpnQVXFjNOS94GBkjggIBfjVcKiI=; b=armHqpDmogp8dcui31cbjJ2br/B2DJzBspO9BLUpJuDewCxxik3R75RrO812IVwxn5 heDRry0gMhc9Q008QNf5pbRprnw7x02Nwmn1cG6f4ggZlKfFvaTwv0n39EFWR9znEe2b VrOMdBX/pY2tO4NqZzGN1m0QbCytBnXCZH5EYJdVn7f48rcKufI3gh2/sM4JGFi1IIOY IaZuZcIolbBW4zFIx2XFjsJe5CBzyZM5qSR8g3pH161soG6vEUrz1CokI9Wf0JZ9WCEh 8WtdRwYp5N7jANzS0m6x05/3hYLrQ1QQ6rPMUPfbWH+0VLT2siLjAObLAHdvcDTq7PZg NbbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788523093; x=1789127893; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=MLRioPwh51wHlSBOpnQVXFjNOS94GBkjggIBfjVcKiI=; b=gYryd4xSUOQtCF6eVfhC5sXpap2Mg4R3deHTDC0bsNOKSdcjHZ76Ni4goZecKSp229 t6iHtxPqllD5sPD+750tPLY2UpwcuO8yt9EBG2xpfvWKhjd+Ln+ilUvdNIVi/kpgGLx0 FaVi4iorPR4yQx+5nSU4aWWqwRl2gj0HowGfvSWtPNlVgfp75Tff28iimOkgkiqQhmds kEkyStKSKmHYHEbaDwi37sUHuit648dDTJwYzPIPYHG9sIJh4daUk09NKA4Guedf41bu 9ogJ7eVYI5u+OVfxxBll45nSO3Y9iL0iq2V0l+wDyD0ex8gsXTlnZYoVPqoHFXLQYaX4 jqRg== X-Gm-Message-State: AFuF++mhymhxfxfSAXqiPPa04oWBBjw1j7cYtWjqVcDkyPRnn3wrKMrm qOFT5asmWDWE2FCp6mBqoZaTya8EN1Mu1ugjNy6ieQq4PpqO6BF4hfgl X-Gm-Gg: AYBFou0KDcSgPvDaDrgvpkNmW3+2L1EJ+oZCL8pA7DngL92++sj/4PbzZdNBImatoV7 EV+Z6KScc1sqpWSqRb/QkDweEhwHWXCFyoAUnh7+AjMT2jKaqosw/X27OrP+/5DCelYEojXbbEV OZ83Q6yr1OSqMz8l/u6INiFy4xy0Sq3XMSJfIo+qkKdBYgojq3EgN1144U9Dpybts45bxoBhJyh oU+/EXmSkORk7g/h2dImGn9+59WuMcsTQHMLuFw+eLLJgLAfQYhOG9ytS1l+GDf3MCelBRprhEG OVKwnCEAieFieGBWYMRHKXgMcN3mMJmOxYuQKPX66mlqmsKbZS0ekiAcZljh9AUMAmjjiSbvlrB y9n4IUrZv2lxHkchEbvGMQh6qzWmxE2ors7+jMFMLIrsT5LC8n4OK5KbGUHHO5/lFfu0fA0NvYL Fe38fN1sT4FtMXslALv2J9Seu/NYntGO+UJdpCd51xivMOHtu1+KXGFCU8gvXsIU3j0xVcjzdW7 sJgE+mri8ktOICAr7LEfocPYG7uE9drr66vq0dxMmSN6HIHPw== X-Received: by 2002:a05:6000:26d0:b0:485:8a46:7056 with SMTP id ffacd0b85a97d-4858a4671a9mr3864421f8f.40.1788523092633; Fri, 04 Sep 2026 04:58:12 -0700 (PDT) Message-ID: <957e4e19-5349-437b-9ec0-ea661292eaf5@gmail.com> Date: Fri, 4 Sep 2026 13:58:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> <1788349915.8631fc262581453bbf619ec5b2062170.1a061f620c5000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788349915.8631fc262581453bbf619ec5b2062170.1a061f620c5000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788523093-3BCD7034-069304B3/10/73395122804 X-purgate-type: spam X-purgate-size: 18406 On 9/2/26 1:51 PM, Baptiste Le Duc wrote: >> >> +/* >> + * The arrangement of IMSIC interrupt files in MMIO space follows a topology >> + * defined by the RISC-V AIA specification. An IMSIC group is a set of >> + * interrupt files (e.g., in a cluster or socket) co-located in memory. >> + * >> + * The physical address of an outgoing MSI is calculated by bitwise ORing a >> + * Base Physical Page Number (Base PPN) with the Group Index (g), the Hart >> + * Index (h) and, for a supervisor-level interrupt domain, the Guest Index: >> + * >> + * ( Base PPN | (g << (HHXS + 12)) | (h << LHXS) | guest ) << 12 > Nit: it should be Guest Index (according to the spec) instead of `guest` > wording: > ( Base PPN | (g << (HHXS + 12)) | (h << LHXS) | Guest Index ) << 12 Applied. >> + * >> + * where Base PPN, HHXS, LHXS, HHXW and LHXW come from the {m,s}msiaddrcfg[h] >> + * registers of the interrupt domain that sends the MSI: >> + * >> + * XLEN-1 HHXS+24 LHXS+12 12 0 >> + * | | | | | >> + * ------------------------------------------------------------ >> + * |xxxx| g |xxxxxxxx| h |xxxx|Guest Index| 0 | >> + * ------------------------------------------------------------ >> + * >> + * - g: group number. >> + * - h: hart number relative to the group. >> + * - xxxx: remaining Base PPN bits; each gap may be zero-width. >> + * - Guest Index: selects one of the 4 KiB pages right above the hart's own >> + * supervisor-level file, i.e. it starts at bit 12; LHXS must therefore be >> + * at least as large as the number of guest index bits. >> + * - Bits 11:0: always zero because IMSIC files are 4 KiB page-aligned. >> + * >> + * For wired interrupts in MSI delivery mode (domaincfg.DM = 1) the APLIC >> + * builds that address itself from the "Hart Index" field (bits 31:18) of the >> + * corresponding target[i] register. That field holds a hart index *number*, >> + * in which both indices are packed adjacently: >> + * >> + * 13 lhxw+hhxw lhxw 0 >> + * | | | | >> + * ------------------------------------ >> + * | 0 |Group Index|Hart Index| >> + * ------------------------------------ >> + * >> + * - lhxw (Low Hart Index Width): the number of bits used for the hart number >> + * within a group. >> + * - hhxw (High Hart Index Width): the number of bits used for the group >> + * number; the remaining bits of the field must be zero. >> > I think it's not very clear that the schema represents the "Hart Index" field > i.e. target[i] bits 31:18. Moreover, the schema like that is wrong as it is > not Group Index or Hart Index but `g` and `h`. > > I'd suggest something like this: > > * For wired interrupts in MSI delivery mode (domaincfg.DM = 1), the APLIC > * computes the MSI target address itself from the "Hart Index" field > * (bits 31:18) of the corresponding target[i] register. This 14-bit field > * holds both g and h: > * > * 13 lhxw+hhxw lhxw 0 > * | | | | > * ------------------------------------ > * | 0 | g | h | > * ------------------------------------ > * > * - lhxw (Low Hart Index Width): the number of bits used for the hart number > * within a group. > * - hhxw (High Hart Index Width): the number of bits used for the group > * number; the remaining bits of the field must be zero. Applied. > >> + * >> + * The Guest Index isn't a part of it: for a supervisor-level interrupt domain >> + * it has its own field (bits 17:12) in target[i]. >> + * >> + * Because there are "xxxx" gaps (Base PPN bits) between the indices in the >> + * physical address (depending on HHXS and LHXS), software must extract the >> + * group and hart components separately and pack them into the APLIC-defined >> + * Hart Index format to ensure correct MSI targeting. >> + */ >> +static unsigned long aplic_hart_field(unsigned int cpu) > I should have renamed this to aplic_hart_index() as it's formerly what > the function returns. Applied. >> +{ >> + const struct imsic_config *imsic = imsic_get_config(); >> + const struct imsic_msi *msi = &imsic->msi[cpu]; > Nit: this could be const ... Sorry, I am not understand what do you expect from me to do with 'const' here. At the moment we don't chnage anything in this function connected to msi variable, just a reading. >> + /* Low Hart Index Shift */ >> + unsigned int lhxs = imsic->guest_index_bits; > It seems incoherent with the diagram above as there is some xxxx > between Guest Index bits and lhxs + 12. Therefore, it is not that obvious > that lhxs is equal to guest_index_bits. >> + /* Low Hart Index Width */ >> + unsigned int lhxw = imsic->hart_index_bits; >> + /* High Hart Index Width */ >> + unsigned int hhxw = imsic->group_index_bits; >> + /* High Hart Index Shift */ >> + unsigned int hhxs = >> + imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2; > ... >> + /* >> + * msi->base_addr is the base of the MMIO regset this CPU's interrupt > So if I understood correctly, msi->base_addr corresponds to the group > terminology? Is it always the case? I think - yes. This value is taken from DTS which and is used to describe IMSIC group. >> + * files live in, and one regset can cover several harts; msi->offset >> + * selects this CPU's block inside it. The hart index bits are part of >> + * that offset, so both indexes have to be derived from the full address. >> + */ >> + paddr_t target_addr = msi->base_addr + msi->offset; >> + unsigned long tppn = target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT; >> + unsigned long g = >> + (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) & >> + APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw); >> + unsigned long h = >> + (tppn >> APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs)) & >> + APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw); >> + >> + return (g << lhxw) | h; >> +} >> + >> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, >> + uint32_t base_val) >> +{ >> + unsigned int guest_id = vcpu_guest_file_id(target_vcpu); >> + unsigned long hart_field = aplic_hart_field(target_vcpu->processor); > Nit: could be const Techically I agree. Then for guest_id it should const too, right? But it seems like Xen in such cases don't use const. Have you found a rule that we have to use const in such cases? I don't mind to put const here but then it would be nice if someone will tell me some kind of rule... > Should be hart_index too, according to previous comment. Applied. >> + >> + base_val &= APLIC_TARGET_EIID; >> + base_val |= MASK_INSR(guest_id, APLIC_TARGET_GUEST_IDX); >> + base_val |= MASK_INSR(hart_field, APLIC_TARGET_HART_IDX); >> + >> + return base_val; >> +} >> + >> +uint32_t aplic_hw_read_reg(unsigned int offset) >> +{ >> + unsigned long flags; >> + uint32_t val; >> + >> + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); >> + >> + spin_lock_irqsave(&aplic.lock, flags); >> + val = readl((volatile void __iomem *)aplic.regs + offset); >> + spin_unlock_irqrestore(&aplic.lock, flags); >> + >> + return val; >> +} >> + >> +void aplic_hw_write_reg(unsigned int offset, uint32_t value) >> +{ >> + unsigned long flags; >> + >> + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); >> + >> + spin_lock_irqsave(&aplic.lock, flags); >> + writel(value, (volatile void __iomem *)aplic.regs + offset); >> + spin_unlock_irqrestore(&aplic.lock, flags); >> +} >> + >> static void __init aplic_init_hw_interrupts(void) >> { >> unsigned int i; >> @@ -53,9 +173,9 @@ static void __init aplic_init_hw_interrupts(void) >> /* >> * Low bits of target register contains Interrupt Priority bits which >> * can't be zero according to AIA spec. >> - * Thereby they are initialized to APLIC_DEFAULT_PRIORITY. >> + * Thereby they are initialized to APLIC_TARGET_IPRIO_DEFAULT. >> */ >> - writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]); >> + writel(APLIC_TARGET_IPRIO_DEFAULT, &aplic.regs->target[i]); >> } >> >> writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg); >> diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h >> index a2af55d54f..babba38607 100644 >> --- a/xen/arch/riscv/include/asm/aplic.h >> +++ b/xen/arch/riscv/include/asm/aplic.h >> @@ -39,6 +39,13 @@ >> #define APLIC_DOMAINCFG_IE BIT(8, U) >> #define APLIC_DOMAINCFG_DM BIT(2, U) >> #define APLIC_DOMAINCFG_BE BIT(0, U) >> +/* >> + * The bits a write may change. Everything else, including the read-only zero >> + * bit 7 and the reserved bits, has to read back as zero, and BE is WARL and >> + * hardwired to 0 as Xen is little-endian only. >> + */ >> +#define APLIC_DOMAINCFG_WMASK (APLIC_DOMAINCFG_IE | \ >> + APLIC_DOMAINCFG_DM) >> >> #define APLIC_SOURCECFG_BASE 0x0004 >> #define APLIC_SOURCECFG_LAST 0x0ffc >> @@ -89,6 +96,9 @@ >> #define APLIC_TARGET_GUEST_IDX GENMASK(17, 12) >> /* Bit 11 is reserved and reads as zero */ >> #define APLIC_TARGET_EIID GENMASK(10, 0) >> +/* If target is in DM mode */ > I think this comment is not clear; I expect, by reading it, to have > domaincfg.DM = 1 which is MSI mode, but I think you were talking about > direct delivery mode, right? If so, I would change this comment to > > /* If target is in direct delivery mode (domaincfg.DM = 0) */ Yes, my comment is incorrect, it should be yours. Applied. >> +#define APLIC_TARGET_IPRIO GENMASK(7, 0) >> +#define APLIC_TARGET_IPRIO_DEFAULT 1U >> >> #define APLIC_IDC_SIZE 32 >> >> @@ -98,6 +108,27 @@ >> #define APLIC_SIZE(nr_cpus) \ >> (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus))) >> >> +/* >> + * Using setip is fine here, as all SET* and CLR* register groups consist of 32 >> + * registers and therefore have identical sizes. >> + * >> + * Lowest 2 bits are always zero for SET* and CLR* registers. >> + */ >> +#define APLIC_SETCLR_OFFSET_MASK \ >> + (sizeof_field(struct aplic_regs, setip) - sizeof(uint32_t)) >> + >> +#define APLIC_xMSICFGADDR_PPN_SHIFT IMSIC_MMIO_PAGE_SHIFT >> + >> +#define APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw) \ >> + (BIT(hhxw, UL) - 1) >> +#define APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs) \ >> + ((hhxs) + APLIC_xMSICFGADDR_PPN_SHIFT) >> + >> +#define APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw) \ >> + (BIT(lhxw, UL) - 1) >> +#define APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs) \ >> + (lhxs) >> + >> struct aplic_regs { >> uint32_t domaincfg; /* 0x0000 */ >> uint32_t sourcecfg[1023]; /* 0x0004 */ >> @@ -141,4 +172,7 @@ struct aplic_regs { >> uint32_t target[1023]; /* 0x3004 */ >> }; >> >> +uint32_t aplic_hw_read_reg(unsigned int offset); >> +void aplic_hw_write_reg(unsigned int offset, uint32_t value); >> + >> #endif /* ASM_RISCV_APLIC_H */ >> diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h >> index 2425430ed1..93f9e44c7d 100644 >> --- a/xen/arch/riscv/include/asm/imsic.h >> +++ b/xen/arch/riscv/include/asm/imsic.h >> @@ -40,6 +40,19 @@ struct imsic_config { >> /* Base address */ >> paddr_t base_addr; >> >> + /* >> + * MSI Target Address Scheme >> + * >> + * XLEN-1 HHXS+24 LHXS+12 12 0 >> + * | | | | | >> + * ------------------------------------------------------------ >> + * |xxxx| g |xxxxxxxx| h |xxxx|Guest Index| 0 | >> + * ------------------------------------------------------------ >> + * - g: group number. >> + * - h: hart number relative to the group. >> + * - xxxx: remaining Base PPN bits; each gap may be zero-width. >> + */ >> + > Is this really needed as you already explain this above in aplic.c? > Please choose one place between the two if not. No, I don't think so. For me, it is also enough to have in one place. I will drop it here and keep only in aplic.c. [...] >> + >> +static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, >> + uint32_t value) >> +{ >> + const struct domain *currd = curr->domain; >> + unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK; >> + >> + ASSERT(curr == current); >> + >> + switch ( offset ) >> + { >> + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: >> + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: >> + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: >> + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: >> + { >> + unsigned int word_idx = >> + regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); >> + >> + value &= generate_auth_mask(currd, word_idx); >> + >> + break; >> + } >> + >> + case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: >> + if ( value & APLIC_SOURCECFG_D ) >> + { >> + dprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); >> + >> + goto fail; >> + } >> + >> + /* >> + * As sourcecfg register starts from 1: >> + * 0x0000 domaincfg >> + * 0x0004 sourcecfg[1] >> + * 0x0008 sourcecfg[2] >> + * ... >> + * 0x0FFC sourcecfg[1023] >> + * It is necessary to calculate an interrupt number by subtracting >> + * APLIC_DOMAINCFG instead of APLIC_SOURCECFG_BASE. >> + */ >> + if ( !AUTH_IRQ_BIT(currd, >> + regoffset_to_word_idx(offset - APLIC_DOMAINCFG)) ) >> + /* Interrupt not enabled, ignore it */ >> + return true; >> + >> + if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW ) >> + { >> + gdprintk(XENLOG_ERR, >> + "value(%#x) is incorrect for sourcecfg register\n", >> + value); >> + >> + return true; >> + } >> + >> + break; >> + >> + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); >> + struct vcpu *target_vcpu; >> + unsigned int guest_hart_idx = MASK_EXTR(value, APLIC_TARGET_HART_IDX); >> + /* >> + * Look at vaplic_emulate_load() for explanation why APLIC_GENMSI is >> + * subtracted. >> + */ >> + unsigned int srcn = regoffset_to_word_idx(offset - APLIC_GENMSI); >> + >> + if ( !AUTH_IRQ_BIT(currd, srcn) ) >> + /* Interrupt not enabled, ignore it */ >> + return true; >> + >> + target_vcpu = domain_vcpu(currd, guest_hart_idx); >> + >> + if ( !target_vcpu ) >> + { >> + dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n"); >> + >> + /* Ignore such writings */ >> + return true; >> + } >> + >> + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) >> + { >> + /* >> + * A non-zero guest index asks for delivery to an interrupt file of >> + * nested guest. The vIMSIC node has no riscv,guest-index-bits >> + * property, so a guest is told its harts have no guest interrupt >> + * files and the field is read-only zero for them. The write isn't >> + * rejected (that would throw away a valid hart index and EIID); >> + * instead the field is dropped, which is also what >> + * aplic_msi_target_gen() does with it when programming the h/w. >> + */ >> + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) >> + { >> + printk_once(XENLOG_WARNING >> + "%pd: vAPLIC target guest index != 0 is unsupported\n", >> + currd); >> + >> + /* Ignore such writes ... */ >> + return true; >> + } >> > Comment above this says "The write isn't rejected ... instead the field > is dropped, which is also what aplic_msi_target_gen() does with it." But > the code doesn't follow it as it returns true immediately here before > the write occurred and without zeroing the guest index field. > You're right that the comment doesn't match the code, but the fix is in the comment rather than in the code. vaplic->regs.target[] comes from xvzalloc_array(), so the guest index field starts as zero, and every write carrying a non-zero guest index is rejected here, the field can therefore never become non-zero and there is nothing to mask out. Rejecting the whole write is deliberate: a non-zero guest index is illegal for a guest whose vIMSIC advertises no guest interrupt files. The second half of the comment was wrong too: aplic_msi_target_gen() doesn't drop the field, it overwrites it with vcpu_guest_file_id() of the target vCPU, which is non-zero when that vCPU owns a h/w VS-file. I'll reword the comment in v3 accordingly: /* * A non-zero guest index asks for delivery to an interrupt file * of a nested guest. The vIMSIC node has no riscv,guest-index-bits * property, so a guest is told its harts have no guest interrupt * files and the field reads as zero for them. Such a write is * illegal and is therefore ignored as a whole: the stored copy * keeps the zero it was allocated with, so the field never needs * to be masked out here. * What ends up in the h/w register is Xen's own value anyway: * aplic_msi_target_gen() overwrites the field with * vcpu_guest_file_id() of the target vCPU. */ Are you okay with that? Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 04 12:03:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 12:03:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408358.1640966 (Exim 4.92) (envelope-from ) id 1x2SdV-0004t8-QV; Fri, 04 Sep 2026 12:03:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408358.1640966; Fri, 04 Sep 2026 12:03:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2SdV-0004t1-NN; Fri, 04 Sep 2026 12:03:13 +0000 Received: by outflank-mailman (input) for mailman id 1408358; Fri, 04 Sep 2026 12:03:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2SdU-0004sk-6m for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:03:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2SdT-00GOgH-Jm for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:03:11 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ab36f-2eae-0a2a0a5409dd-0a2a4501c1b0-42 for ; Fri, 04 Sep 2026 14:03:11 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ab37f-5984-0a2a45010019-d155dd2be176-3 for ; Fri, 04 Sep 2026 14:03:11 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-47de0093c42so792459f8f.3 for ; Fri, 04 Sep 2026 05:03:11 -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-49ce58da3acsm394796045e9.0.2026.09.04.05.03.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 05:03:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788523391; x=1789128191; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=HHi0410SQaXfTp/+4Wcu9ZXeoJ1qz1SOw0DK4y6zNMQ=; b=EMIjDxpxskdiq4rp0fBT+1MxuDL7+6gHcWp74Cthcm6lLQYbUKOc5yKCJ0Tv5vAzX/ 0cadzWtix2zGuQFI9O8iP96LRnxbm+xp6JMOx8AnwCybAvHm8xAtRM7bHinQWvkWkOna H6Bt98+pNiIMXkRmSEKA4qozqDUsFahww8SIu0LevlJ0lIvPqVWoyuV46L10kLBRY+dK I8XXE6H4Wf8YWPbGo9FYnOBLDEokdXUhcgDjBT86EvrJKVIlKAB2J3RNfaNIzlaaX7k3 +nuv4URsTMIgJexQ7OEtx5mFVG9xg5xmG/bPIjFeHJHLZXBcL3iQixXWlBc9aODOaNDH TlWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788523391; x=1789128191; h=content-transfer-encoding:content-type: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:content-type; bh=HHi0410SQaXfTp/+4Wcu9ZXeoJ1qz1SOw0DK4y6zNMQ=; b=MiUTi6bbQeZHetiROF3LxuI/6la5G+r7YPLT9qA11UQhG/58N2fhHJGA+VQrQsCsBU YjLfBPtDgYo72b5DMdqsXqHiL+mgfspj7lpSSR4M6KXN9lcZuVTD1ovD3fP2cT9zRIQ4 RPfh4BFNT3/J8kUJH5I8yqlYw40LZwGuV8r4d/u0alMLn26D5Ge96HO8O88o1EAkMhfs Rh0RavUek5P/HFiA7LcfpzA9ylpY9+V2do+XwKB5zHuYdbRjW9CzaTRhClTEVZz6NfRZ NIWzJfbR8zVgYqRHR5opi2gKVuCodrraCFgXYpXZzyv606T1oZl69p+uoRwzkZX6GJKh CLDQ== X-Gm-Message-State: AFuF++nVv0eYztvWNtuL8asRewbe/PIha3m9cnUOzGH964Ra0BH+lH/v 2KdZ9LbJl5w6z0VmhDB3gP9CoUcQgeLs0DSIIYJHfV3IzSpnHXAt53YJCS3wefDx2g== X-Gm-Gg: AYBFou3pS0heSCQDw3u46VMeo0MBvGZaWBEvbBIHYmqxOAgADkUe8ALBi6/JeKV4UqA 1mKyERDM26bewKz/FP1xuDWVI21TzAoWpBizG9xoqRAeA8WFZGjUsL7tF+EJ+7fhM34xfh40Gj6 I2DazY4E3ydw6HF0fWz68XIud1EmKZRrJLmc+4PJrcZUwm2TXOp1mwS2+mmRGAGt6qrt6aeE/6z PdF02hwv1/C7R+k+wmkhI3Leh2gnA2y/oio058moyg5Aj6a95G73CWG1S+CDnGLHkE0GnF4TVET J5npkmNQpgzuZ/BPhpDOS6nlMOvjS3am5zS3ePlIApJigFrBeUzltdH5Nj3zQdhKjLEqIujhbZk dpJjApkjvKOk/tw6XCFAfDgreD+xPnA1pvZBwkttXpnuU3Es+Dpy3teV0TYbaapo9bGi/L/KkAI RCt1wQ2uQJgcbFksOpMGJvlv126eNiy2yya4dn6q+gpmeb1rHkEYtxnDJTT/UmsUoh/1/cNQAf4 WPyEV2dfe9yEEvQCu3UoqEf3LOsHSQniHZUzw== X-Received: by 2002:a05:600d:848e:20b0:495:4d88:e630 with SMTP id 5b1f17b1804b1-49cf824f697mr43311415e9.10.1788523390789; Fri, 04 Sep 2026 05:03:10 -0700 (PDT) Message-ID: <02cb695f-c827-4623-8f65-530bd7b740d6@suse.com> Date: Fri, 4 Sep 2026 14:03:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation To: Oleksii Kurochko , Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> <1788349915.8631fc262581453bbf619ec5b2062170.1a061f620c5000c4f3@vates.tech> <957e4e19-5349-437b-9ec0-ea661292eaf5@gmail.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: <957e4e19-5349-437b-9ec0-ea661292eaf5@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1788523391-1E465757-E9555FA4/0/0 X-purgate-type: clean X-purgate-size: 910 On 04.09.2026 13:58, Oleksii Kurochko wrote: > On 9/2/26 1:51 PM, Baptiste Le Duc wrote: >>> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, >>> + uint32_t base_val) >>> +{ >>> + unsigned int guest_id = vcpu_guest_file_id(target_vcpu); >>> + unsigned long hart_field = aplic_hart_field(target_vcpu->processor); >> Nit: could be const > > Techically I agree. Then for guest_id it should const too, right? > > But it seems like Xen in such cases don't use const. Have you found a > rule that we have to use const in such cases? > > I don't mind to put const here but then it would be nice if someone will > tell me some kind of rule... We want const on pointer targets whenever possible. We don't normally want const on plain variables, unless it needs emphasizing that a variable is to change value (which should be very rare). Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 04 12:07:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 12:07:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408369.1640974 (Exim 4.92) (envelope-from ) id 1x2Shw-0005yB-9W; Fri, 04 Sep 2026 12:07:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408369.1640974; Fri, 04 Sep 2026 12:07:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Shw-0005y4-6w; Fri, 04 Sep 2026 12:07:48 +0000 Received: by outflank-mailman (input) for mailman id 1408369; Fri, 04 Sep 2026 12:07:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Shu-0005xm-8o for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:07:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Sht-005ilj-Kp for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:07:45 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ab483-8faa-0a2a0a5109dd-0a2a450c9b4e-20 for ; Fri, 04 Sep 2026 14:07:45 +0200 Received: from [52.101.83.68] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ab48b-f479-0a2a450c0019-34655344bc18-4 for ; Fri, 04 Sep 2026 14:07:40 +0200 Received: from AS4P251CA0023.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:5d3::20) by VI0PR08MB10894.eurprd08.prod.outlook.com (2603:10a6:800:258::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 12:07:31 +0000 Received: from DU6PEPF00009528.eurprd02.prod.outlook.com (2603:10a6:20b:5d3:cafe::6e) by AS4P251CA0023.outlook.office365.com (2603:10a6:20b:5d3::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Fri, 4 Sep 2026 12:07:31 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU6PEPF00009528.mail.protection.outlook.com (10.167.8.9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Fri, 4 Sep 2026 12:07:30 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DU0PR08MB9050.eurprd08.prod.outlook.com (2603:10a6:10:47a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 12:06:56 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 12:06:55 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=dU0+ivHTChEgqqUah5TBhKwZCNxZXR/O2ycmJaV4EoPkl9gi3lb4r1hMlQ1N3bl/ENxTxwmZlaJOnPzEgtctbUo8/48sammMScG3UVVY1eADQ3SVzixpY5lB/L4BgMekNd6UNN7fLBhVFnA0jbE5cElXeYlr2/EVg3fVodWxaJthITkrbQUtbaijgaYjZDivvF0YHNNyE2/lbYUjQLcluxVt34EnKlg639nTuk3qCw5Y0yWvoFzFfVL7gAuEGxXvMz9PZJWWrgAH4fpG6Izg2dSd9T9b+IEUVJEOdtN2f+Oul/7ngiTK7kwCjyg1V/Hntl6Z89CtDwQmYnxBqbiOQg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iHH2LJGq2s9bmE7lTon0qixFJJZHEon2hXaujTVIQss=; b=NqFohXAkv9b1YiaclXT8JzJ0knx0FSWvsnckikyAFiRLi+6VxpKl4ZQDEEAPmwIS8bIUII0WvsmvqKo6TamgRaiqtqgZHzMfD9tKDoEX7zDOlTjY+47WVufRNKDUhL+Bh1BO50beTMqyHfIbt9rZfZO8amlM27YbDDEid1lf3LxYgLcp+E4X6KJA1Dz/4q7AeLV1iDswx5VmCeHjhA1vmP7eY1uzUVW9Cn1W3OH1bKiE7U310O85GTY+TcH2Zwc7MjPlaTs++Ww4gcsC1+xploR8g/NTDCO5ATWnioL7L8rXFGypkADpuScoQ/jRaf8xgDTImmQAoag+JADz/m77cA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iHH2LJGq2s9bmE7lTon0qixFJJZHEon2hXaujTVIQss=; b=AdUQ2J9mOHXlB/WvLeBwq/D/UGC+CDnJeuds9f4vVX1P8RNMPTeUiOTXoj2380O0hCzPYY6Yl/e/SB+g7mz1HpktSITPLlD55u7Z6K+pRcY+p7PNh9ZvXIiM4ed/e7QkoBlMRp4T1Ijpcqz454EM2Wlj3E3os7vgiMNdzYRzjRw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bDS9om4Plii9H4WdKEmQ0kFuGyD6SGSCbISnvggmvtsxipG+W0ukRYEKu7OUpis45jplj9wxKS3xa6D7IsznN5grc8/Q1ie5bCtoOzOUds6ImU3jftYrQVx0dCP5m3soIWCJhGyh4X5WO45e/VY2y9u8T+7UsWwoaryRxs5YsPFAIDbl3IwBD6mf5BE3xUxFzgluv/Ddd0F5vaBelVYxXLdSSed0GiG10lNhNZykLiiYhtOsSNgCdkuriVkqOU/PMiWhUop0r7FElHuodl5diStMYiQFAX12Y+b1AJVlT+H/m89u3UYLDn/6jHNlxTZeQtlZEehAO2r0LPIOYgYDYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iHH2LJGq2s9bmE7lTon0qixFJJZHEon2hXaujTVIQss=; b=b5a3cEW3bNny6L+rJgFWsZLGW1n512E4oa5tjZarFO7Bi12Qpcm4y3fS4xfBf9b0Kuth929rczfn7o+f5Osp2mbd4WrEvYK0i8r0BxIk9x1uvwNjiCsKOsxEghsYZoIv3EBGCOy1+2732xvZ6Eu0Ihv1Raruiz4d3q8jP3/jRdovAgu3ftGlxKIwOrNGavdXh/4rnN8yJTEE/mI7N5GiFxNaZXizvLSplxCj3J4yvPrVgYyDVodJFsz3/af19XBcJiJsXsZM3B86xqeNqarE1+WqafNlTJ8uRBVOP2kNEL7A8Yug6Urn23aZQL0BjDayWFUqnrZ85svx7g4k5Ahckw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iHH2LJGq2s9bmE7lTon0qixFJJZHEon2hXaujTVIQss=; b=AdUQ2J9mOHXlB/WvLeBwq/D/UGC+CDnJeuds9f4vVX1P8RNMPTeUiOTXoj2380O0hCzPYY6Yl/e/SB+g7mz1HpktSITPLlD55u7Z6K+pRcY+p7PNh9ZvXIiM4ed/e7QkoBlMRp4T1Ijpcqz454EM2Wlj3E3os7vgiMNdzYRzjRw= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Jan Setje-Eilers , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel Subject: Re: [PATCH v2 1/5] xen/arm: Fix evaluation of parameters for SMCCC calls Thread-Topic: [PATCH v2 1/5] xen/arm: Fix evaluation of parameters for SMCCC calls Thread-Index: AQHdPF5LioCdLX4zMEeYNEbpyTgPEba+UviA Date: Fri, 4 Sep 2026 12:06:55 +0000 Message-ID: <0F45E34D-1828-43C7-9386-3339DC4E0E93@arm.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> <20260904111228.3022634-2-andrew.cooper3@citrix.com> In-Reply-To: <20260904111228.3022634-2-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DU0PR08MB9050:EE_|DU6PEPF00009528:EE_|VI0PR08MB10894:EE_ X-MS-Office365-Filtering-Correlation-Id: 210b40d8-595c-434b-648b-08df0a7d1846 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|10067099003|11063799006|4143699003|18002099003|22082099003|38070700021; X-Microsoft-Antispam-Message-Info-Original: eMvvweTv0D9bQTHgC4qo/VmzprAQOhqnLx4Tlb13/CzlzyWhsyqLu7saKwL2nrrE2mqUHODXQB/5d+g8XDCgpLEs1eoapMlXliRLKfFGtN6vgF6Q6WYIhASSCB8Cs4bxvQVW4/71hKascqWFMywdHi6dtZv2juTrucxv8MFBHIL7ggF/YtUCxwfIsrAiYoEEtnrl9MMVAjG1FuliNqWEkpPvpYkam6MSq/XMmSnQD2JBwVqW5B7d1Ur/Bo+jn+Jrh8AA7W+bkycc/p6I+/gPySWau0lMnYFlyFmNfMWzCWnjxm67L9b8Uo6nJRQWjUCoKElTc6gd10pt7pJgL/nbehOtzNVaTzaGYKMU6M+HGs3YBr2cMeApeVLhQuGflLD0lTZklzjyPk7swokRZj/eCQuSO0xiF0ngqWu4dVdXSIBKP5XYEE2eqqZ5n67AEmijQHu7kl6jD1WVOvUbZCEXA9h37/iWTRSbvkBN/y4TSQ6d0Bihjdfv96k2+/yIZb+ET6DFR/IJDjextW8ZZ1mfCe4UsxCKUmTYapJRpDd89j4nZwJ4FD9ZFt94WoPmdRccXtVFVnPohprbNX49rLy6tHXNA5jI5CYyP0bFbX/ljQ5IqK23GJ4+27xiHmmuZ1mDyJ/PIcAoRbQaczQ3b6uIQ336zvXsb5CR79JXdqNUoYAqO+LN03QyUcNoW97nWq7zDE8AXGTpzcr1CqbySDhqPEAUHQKeYoYE0i3PagBr6FY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(56012099006)(10067099003)(11063799006)(4143699003)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: HU/lcOyw1XakJt5ATmUoGTA97zSqSFlKpxzbg2AYw8jPpWGdTFiMpCsrk76aCDiLsCGnHcRFn3eynFlTZ1JRJNrTZBZjM0XUGv9lYaDr74zehZJPQrQYsbq01MM0oissh/Exq0wrMYoBzw+Iv1KWeR6PpMJCafe8aTi9P4XjHRICxdf0/5ohVaxuj9XpFRq9QhngKLAQU+TzqDAthJX4E1FmYd9wniJ/3Al52/SW7IfKBvJd/s7LGIoYUgsypLuOorvbJWrkh0Jj7reMvHnVB2qMyBCyeqD6NHDJb/9kxh7joOKTx3VWqi8DeDcDxo8gcuxlHhIHQ5WkXQ30otmGJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9050 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU6PEPF00009528.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 8febf785-2bad-444c-1f75-08df0a7d03b2 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|14060799003|23010399003|36860700016|82310400026|35042699022|10067099003|11063799006|56012099006|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: LiKLAoB/F9+zc/f+4VGnXiNrW94GeXgyoHe+fsGQDPqM4KqfsATQMlvGsNON9SM9YONFKcrL395aHNXFtH7KkuJ1lv/0ZHQ8phCommEa84KDKVF1lyw5qBAwXxOwp9b7lJ7Zt9/4BfD80A7QjgtETrJb9FOpBFo9ouLFFuYOG9PpHBhdzCD8hnI9A85m5SuHqfxRwFZMWLMSrVldscmOnFTWyQrS3Aeq8nowhtzd8aaAn4OfJtgw4ZI8j8aX16OY4IASS/iwPnJzK5gFcLlVLwGpwIm1Sx6Ts/kjZtBWybg5RO2uva8NqngmZj41dhsm+PFU0D+GOdTY3gkvlY5z5aY1FhC7FbiH2AZ/ihZk9aBHny3OuU5MGm53pvTlt4vRFs/UNi7rDznB2LsqyMkU/7vtYQ1BEPaP91aWQzPvJfxmlUW0ipciQBqIZkNBE+tIoUTXefSimGnuAkszZXeTjS50gZqttsjxHeD9ydyMWooVH0ysy6aVz9Mn0dFtuS9B28de1PcxzKlUV+8V038NIzBAld2Z7LtG3HOhl2la/UNJnasB37TR1oBCxYJYTgYcfbKJHsQXd9lg7HmKAnn5zZQnB51+GhAxnSn59wn8X3uxfM1/WnhHDQ+hWSygXnfmz1RH05vrW8t6dHYMklXi+lZyhp8LfWXq3D90x1OlNT4= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(14060799003)(23010399003)(36860700016)(82310400026)(35042699022)(10067099003)(11063799006)(56012099006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Wi3dUCDuEOSAalSgPBZIe746YTis1gZNcYsPzaLK/ncKHNuClJUeV7iaza0tficFE97GdcH+rTVY/iLylwW2bG3g9PRWwgHui+Up7sp/PyyF6tKxlxRnmLeT0HrvDoHNDv/00Nbytrss5W5H5VG2W83Kyy9Bnz8xjh0b9k3+WskgdvD1555VGuIL7AT9aLmWwyYfBsQDDczgHN2xH61cBojmSvo72NsZFENoFykbFiutvwnhOruBve+bg9WmEwLnkSqtyBKjZbmEjMKo+iMubTKDhFhdbz60OZ6Efa4yoz49KGYX/98L6SvR7X1qeAlaMb2zn8TKMP5LvPmBqY2x/lOJ0xXubDWZJLBnDMA1LGe5rJz/S/25iPn7tke9M2o6e8jlusUeG4TjP0LbTp9yUQT+Exfb1aq6BybxRzti+tSMzQrcTRyCjN1Aln7H4mqp X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 12:07:30.3243 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 210b40d8-595c-434b-648b-08df0a7d1846 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DU6PEPF00009528.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10894 X-purgate-ID: tlsNG-d25034/1788523665-5290EA5B-4A7CE097/0/0 X-purgate-type: clean X-purgate-size: 5122 Hi Andrew, > On 4 Sep 2026, at 13:12, Andrew Cooper wrote: >=20 > Contrary to what was claimed in commit 67bcf5eae709 ("xen/arm: Simplify t= ype > handling for SMCCC declarations"), there is an important reason to retain= the > intermediate variable. It is unsafe to have any logic between the assign= ment > of the register variabes and the asm() block they're used in. One small typo here s/variabes/variables/ You can fix on commit and retain my R-b Cheers Bertrand >=20 > This logically reverts commit 67bcf5eae709 ("xen/arm: Simplify type handl= ing > for SMCCC declarations") while retaining the conversions from commit > 7f15d5d13221 ("xen/treewide: More typeof() -> auto conversions"). >=20 > Adjust __declare_arg_0() to match. It happens to be safe because it's th= e > first register expression once all macros are expanded, but it really sho= uld > be consistent with the others. >=20 > Leave a comment explaining why they must be written like this. >=20 > Fixes: 67bcf5eae709 ("xen/arm: Simplify type handling for SMCCC declarati= ons") > Reported-by: Jan Setje-Eilers > Signed-off-by: Andrew Cooper > Reviewed-by: Bertrand Marquis > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers > --- > xen/arch/arm/include/asm/smccc.h | 31 +++++++++++++++++++++++-------- > 1 file changed, 23 insertions(+), 8 deletions(-) >=20 > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 62c6985e7315..53cdddb690b7 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -108,37 +108,52 @@ struct arm_smccc_res { > #define __constraint_read_6 __constraint_read_5, "r" (arg6) > #define __constraint_read_7 __constraint_read_6, "r" (arg7) >=20 > +/* > + * Macro arguments MUST be evaluated before being assigned to a register > + * variable. > + * > + * This is manual register scheduling for the asm() statement, and any o= ther > + * logic to evaluate may clobber the already-scheduled registers. > + */ > #define __declare_arg_0(a0, res) \ > + auto __a0 =3D (uint32_t)(a0); \ > struct arm_smccc_res *___res =3D (res); \ > - register unsigned long arg0 ASM_REG(0) =3D (uint32_t)(a0) > + register unsigned long arg0 ASM_REG(0) =3D __a0 >=20 > #define __declare_arg_1(a0, a1, res) \ > + auto __a1 =3D (a1); \ > __declare_arg_0(a0, res); \ > - register auto arg1 ASM_REG(1) =3D (a1) > + register auto arg1 ASM_REG(1) =3D __a1 >=20 > #define __declare_arg_2(a0, a1, a2, res) \ > + auto __a2 =3D (a2); \ > __declare_arg_1(a0, a1, res); \ > - register auto arg2 ASM_REG(2) =3D (a2) > + register auto arg2 ASM_REG(2) =3D __a2 >=20 > #define __declare_arg_3(a0, a1, a2, a3, res) \ > + auto __a3 =3D (a3); \ > __declare_arg_2(a0, a1, a2, res); \ > - register auto arg3 ASM_REG(3) =3D (a3) > + register auto arg3 ASM_REG(3) =3D __a3 >=20 > #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ > + auto __a4 =3D (a4); \ > __declare_arg_3(a0, a1, a2, a3, res); \ > - register auto arg4 ASM_REG(4) =3D (a4) > + register auto arg4 ASM_REG(4) =3D __a4 >=20 > #define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ > + auto __a5 =3D (a5); \ > __declare_arg_4(a0, a1, a2, a3, a4, res); \ > - register auto arg5 ASM_REG(5) =3D (a5) > + register auto arg5 ASM_REG(5) =3D __a5 >=20 > #define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ > + auto __a6 =3D (a6); \ > __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ > - register auto arg6 ASM_REG(6) =3D (a6) > + register auto arg6 ASM_REG(6) =3D __a6 >=20 > #define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ > + auto __a7 =3D (a7); \ > __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ > - register auto arg7 ASM_REG(7) =3D (a7) > + register auto arg7 ASM_REG(7) =3D __a7 >=20 > #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) > #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 12:08:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 12:08:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408373.1640985 (Exim 4.92) (envelope-from ) id 1x2Sij-0006WC-Io; Fri, 04 Sep 2026 12:08:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408373.1640985; Fri, 04 Sep 2026 12:08:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Sij-0006W5-FC; Fri, 04 Sep 2026 12:08:37 +0000 Received: by outflank-mailman (input) for mailman id 1408373; Fri, 04 Sep 2026 12:08:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Sih-0006UH-E8 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:08:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Sif-009hoY-EO for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:08:33 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ab4b5-2eae-0a2a0a5409dd-0a2a450abcc0-28 for ; Fri, 04 Sep 2026 14:08:33 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ab4bf-f2d2-0a2a450a0019-aa0a817ca5f5-3 for ; Fri, 04 Sep 2026 14:08:33 +0200 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-631-6iCtdctEP_6asNWKVLSgMA-1; Fri, 04 Sep 2026 08:08:30 -0400 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-49ccfad90f1so6533275e9.0 for ; Fri, 04 Sep 2026 05:08:30 -0700 (PDT) Received: from imammedo ([213.175.37.14]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce831af89sm120170135e9.1.2026.09.04.05.08.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 05:08:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788523711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uiO1euU//keMnRJ/+D7RSwnTPu9S3MPbCCFcroBKMjc=; b=SSEHdeKi6/pRJkZGYmFGALqwHAAbD16v16gam/BpZ67XDCzd5UFy6cIBlgUl2wVmrvL3jZ 9aMB64aZ8Qn0MyYGBTnq5lXQI+zCXGcC8VHNHFPm6VLZI1AbLY7eI30i4nuhc2wbq3UKTC FKaTsu+Ol9g/cM+P8TnIetpSeqh5Di4= X-MC-Unique: 6iCtdctEP_6asNWKVLSgMA-1 X-Mimecast-MFC-AGG-ID: 6iCtdctEP_6asNWKVLSgMA_1788523709 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788523709; x=1789128509; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Exst7EJqJQoSBYryil+QQ12+6GqWDbDrhmxI8WakeCY=; b=Gft0o2ucOqc+k4HWq5pI65Zx5sIz29inhy8gwrDUmiojyqHn/YgMRH74j+QVz++3M3 OGWtaTKfDdc8ucGEcboVCOPtqyWlM6+LigHjsqj5iLcSB3iKCIHhg8NVezAOg3i42Sak AFWNI5cmBd+BhaqJMqJvHxMYUCp9o3I0gZTba8J1XNGynMFNchrnSKFTi6fsgAzD+C/0 iyEV9m9tgwLCieZ95S+VdL79RiWguZ+Ld/ZduzBdnX8/cc3rmcmQvlpfusFGafbLtjj9 Rj+qDH0BBYDVbVAOWOwT0DcHB/LObnbpqcP/fJfzModbiEw/IRDPPuC5qsjGisRiavvQ 8rog== X-Forwarded-Encrypted: i=1; AKwUvBzGhF2X82aK3Vz7RKtoV+xGrGTpYPxiuNPIrKg7mxnM1Zn5+qd5CpIA9f1eaN+0VupyMvCPTgLKbU8=@lists.xenproject.org X-Gm-Message-State: AFuF++kqNLQEUNWuaGGnBOtnrUh8AJnB4f9OLS8Gh617nuBqNRZK3Yu1 yxgLXshjUYOXBZyMQ+5dqf1Et/kSRiusHd15Sb1aGfnrmn1MnshZ01b6V9I+LTnAYs/LKAB1TvP OfkVd65fzxLBu4I2HzHgEiBFhAEyWzWXqjPckMDzeXnejNR8bQG+4Y2fsamOA1WqXnLso X-Gm-Gg: AYBFou1IA/GwUslrGpOz4qLVEv02yZ+EGcA1AIXOxQqBVEJUviGaVW4+hHfB1TnoD0X D+/+rYCaANMo1H3Mo3ehl23EddrqOWsvdZbOTznzN50EBjstyH+3vWWXjLreEYmini6ozcxO60T L4buqTlavj/kNakYtlP5uw3HxcKyR2CF/ts+bpJUD1jdYwOyh/5DeMhUlE3IxZXSNNkDeHPB35Q bkkPQrIErtEcqkr6GcOxaP22otiohDIpka0pCxOy0HMkH1S8z9mIvRmq/7d8AtXDzcZR8UoAF1j S5bNukZluFcjXZuSruWTg7XkW9oR/ifc6sW053wrxWCbidIH46UPVFQwW1w= X-Received: by 2002:a05:600d:864b:20b0:49c:fea3:8633 with SMTP id 5b1f17b1804b1-49cfea38642mr11745465e9.24.1788523709278; Fri, 04 Sep 2026 05:08:29 -0700 (PDT) X-Received: by 2002:a05:600d:864b:20b0:49c:fea3:8633 with SMTP id 5b1f17b1804b1-49cfea38642mr11745025e9.24.1788523708810; Fri, 04 Sep 2026 05:08:28 -0700 (PDT) Date: Fri, 4 Sep 2026 14:08:24 +0200 From: Igor Mammedov To: "Michael S. Tsirkin" Cc: Dongli Zhang , "Daniel P. =?UTF-8?B?QmVycmFu?= =?UTF-8?B?Z8Op?=" , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug Message-ID: <20260904140824.177711f8@imammedo> In-Reply-To: <20260904072052-mutt-send-email-mst@kernel.org> References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> <20260903160401-mutt-send-email-mst@kernel.org> <20260904130709.6769caee@imammedo> <20260904072052-mutt-send-email-mst@kernel.org> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: zUpocuwcSh1UufAzlEg4gTnmulrO6lGfw216fi_wUMg_1788523709 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1788523713-532D8CFC-BC561BD9/0/0 X-purgate-type: clean X-purgate-size: 10073 On Fri, 4 Sep 2026 07:22:10 -0400 "Michael S. Tsirkin" wrote: > On Fri, Sep 04, 2026 at 01:07:09PM +0200, Igor Mammedov wrote: > > On Thu, 3 Sep 2026 16:17:20 -0400 > > "Michael S. Tsirkin" wrote: > > =20 > > > On Thu, Sep 03, 2026 at 05:28:35PM +0200, Igor Mammedov wrote: =20 > > > > On Wed, 26 Aug 2026 09:15:47 -0700 > > > > Dongli Zhang wrote: > > > > =20 > > > > > On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrang=C3=A9 wro= te: =20 > > > > > > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: = =20 > > > > > >> Hot-unplugging a PCI device can require cooperation from the g= uest. For > > > > > >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the= guest > > > > > >> eventually writes the ACPI PCI eject register. For PCIe native= hotplug, > > > > > >> QEMU notifies the guest through the PCIe hotplug mechanism and= waits for > > > > > >> the slot unplug flow to complete. Only after that completion d= oes QEMU > > > > > >> unrealize the device and emit DEVICE_DELETED. > > > > > >>=20 > > > > > >> This can leave a device stuck in the unplug pending state when= the guest > > > > > >> does not cooperate. Examples include: > > > > > >>=20 > > > > > >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug dr= iver is > > > > > >> unavailable. > > > > > >>=20 > > > > > >> 2. The guest is stalled and cannot handle the hot-unplug event= . For > > > > > >> example, stalling the Linux [irq/9-acpi] kernel thread can rep= roduce this > > > > > >> for ACPI-based hot-unplug. > > > > > >>=20 > > > > > >> 3. The device was attached to a slot that the guest cannot use= . For > > > > > >> example, a pcie-root-port only supports slot 0. If a device is= added to a > > > > > >> non-zero slot below a pcie-root-port, the guest may never disc= over the > > > > > >> device and therefore may never complete the unplug request. = =20 > > > >=20 > > > > all of above is actually expected, no (functioning) driver =3D> no = hotplug/unplug. > > > > it's the guest problem. Once device it exposed to guest its life-cy= cle > > > > not longer owned by QEMU. > > > >=20 > > > > That's what one would see in real hw as well, you press eject butto= n > > > > but it will not do anything if OS doesn't process it. > > > > also see comment at the end. > > > > =20 > > > > > >>=20 > > > > > >> The non-zero slot case has also been discussed in: > > > > > >>=20 > > > > > >> hw/pci: warn when PCIe device is plugged into non-zero slot of= downstream port > > > > > >> https://gitlab.com/qemu-project/qemu/-/commit/ =20 > > > > > > ca92eb5defcf9d1c2106341744a73a03cf26e824 =20 > > > > > >>=20 > > > > > >> hw/pci: add comment to explain checking for available function= 0 in pci hotplug > > > > > >> https://gitlab.com/qemu-project/qemu/-/ =20 > > > > > > commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5 =20 > > > > > >>=20 > > > > > >> pci: don't skip function 0 occupancy verification for devfn au= to assign > > > > > >> https://gitlab.com/qemu-project/qemu/-/commit/ =20 > > > > > > e228d62b4af29bca698ec57efdceb46f392f5444 =20 > > > > > >>=20 > > > > > >> For example, if root-port.1 is a pcie-root-port, the following= command adds > > > > > >> a vhost-scsi-pci device to an invalid slot: > > > > > >>=20 > > > > > >> (qemu) device_add vhost-scsi-pci,id=3Dscsi01,wwpn=3Dnaa.500140= 5324af0985,bus=3Droot-port.1,addr=3D01.0 > > > > > >> warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent d= evice only allows plugging into slot 0. =20 > > > > > >=20 > > > > > > This rather looks like it should be a fatal error, not a mere w= arning. > > > > > >=20 > > > > > > If I follow the commit ca92eb5def it links to https://bugzilla.= redhat.com/show_bug.cgi?id=3D2128929 > > > > > > which states that this configuration is going to lead to a cras= h in > > > > > > QEMU on guest OS shutdown. IMHO that crash is sufficient to jus= tify > > > > > > making this a fatal error. > > > > > >=20 > > > > > > If we actually wanted this to remain a warning, then that shutd= own > > > > > > crash would need to be fixed. > > > > > > =20 > > > > >=20 > > > > > Thank you very much! > > > > >=20 > > > > > I see that the issue has been fixed. The ticket mentions the foll= owing. > > > > >=20 > > > > > "What I am observing is that it seems when the slot ID !=3D 0, th= e guest OS seems > > > > > to ignore this and we never seem to hit ich9_pm_device_unplug_cb(= )." > > > > >=20 > > > > > Based on my experience and evaluation, ACPI-based hotplug is more= likely to > > > > > encounter an issue where the guest VM does not respond to an unpl= ug operation. =20 > > > >=20 > > > > I'm not sure it's a good idea to delete device when guest still thi= nks it's there > > > > (you can make guesses on QEMU side if it's in use, how useful those= are is questionable). > > > >=20 > > > > as far as I know, ACPI hotplug has no notion of surprise removal (p= ls educate me if it's not the case), =20 > > >=20 > > > why would it not? > > >=20 > > > how do you think you can pull a laptop out of a dock? > > > I expect bus check + _STA and config space saying it is gone > > > will do exactly that. > > >=20 > > >=20 > > > Here's linux code: > > > static void acpiphp_check_bridge(struct acpiphp_bridge *bridge) > > > { =20 > > > struct acpiphp_slot *slot; > > >=20 > > > /* Bail out if the bridge is going away. */ > > > if (bridge->is_going_away) > > > return; > > >=20 > > > if (bridge->pci_dev) > > > pm_runtime_get_sync(&bridge->pci_dev->dev); > > > =20 > > > list_for_each_entry(slot, &bridge->slots, node) { > > > struct pci_bus *bus =3D slot->bus; > > > struct pci_dev *dev, *tmp; > > >=20 > > > if (slot_no_hotplug(slot)) { > > > ; /* do nothing */ > > > } else if (device_status_valid(get_slot_status(slot))= ) { > > > /* remove stale devices if any */ > > > list_for_each_entry_safe_reverse(dev, tmp, > > > &bus->device= s, bus_list) > > > if (PCI_SLOT(dev->devfn) =3D=3D slot-= >device) > > > trim_stale_devices(dev); > > >=20 > > > /* configure all functions */ > > > enable_slot(slot, true); > > > } else { > > > disable_slot(slot); > > > } > > > } > > >=20 > > > if (bridge->pci_dev) > > > pm_runtime_put(&bridge->pci_dev->dev); > > > } > > >=20 > > >=20 > > > so weirdly it wants bus check on a parent bus, otherwise it will > > > not trim devices? probably a bug, but easy to work around. =20 > >=20 > > Modern docks would use native pcie surprise removal path. > >=20 > > As for ACPI, my old laptop, had an unlock button =3D> _LCK > > and that relied on OS processing ACPI events, not so surprise. > >=20 > > There might have been ACPI/hybrid docks that did surprise removal, > > but then one need to find one and model after that instead of=20 > > just blanket force removal. (likely out come would a doc device > > support only, not an arbitrary device removal) > >=20 > > (not the case described in this series, though. hence my request to cla= rify usecase) > >=20 > > from what I see in spec there is _RMV method that says that device > > supports surprise removal that can be used for devices that support it. > > However I would hesitate very much to blank apply it to every PCI devic= e. > > (it's not even realistic to ask for proving safe tear down across vario= us > > drivers and OSes/versions) > >=20 > > Rather than a knee jerk treatment of misconfig consequences, > > I'd rather see patches to prevent misconfig in the 1st place > > (subj to deprecation but doable). > >=20 > > As for the cases where OS mis-behaves (apcihp thread starvation,...), > > fixing guest to follow hotplug contract is a proper place to do it. > >=20 > > On QEMU side we have it covered as well. If unplug was not processed, > > mgmt is free to repeat action. =20 >=20 >=20 > Sorry if I am unclear. I just meant that it looks like we > can support surprise removal with ACPI just by reporting > bus check events on the parent. maybe, but that ain't SPECed and might be OS specific. The way I've read the cover letter, that won't work for mentioned mis-confi= g cases. Also what would happen on bus-check 'cleanup' would be a lottery. hence I'm for being safe here. It's better to implement native PCIE surprise removal if that's really need= ed. > > > > so I wouldn't do what you are proposing here at all, it's basically= asking for disaster to happen. > > > > And all this is basically for dealing with abused qemu flexibility. > > > >=20 > > > > Please (re)formulate usecase and make it more clear as what is elud= es me > > > > no matter how many times i've read this cover letter. > > > >=20 > > > > On positive note: > > > >=20 > > > > What you can try to implement is native PCI-E support for surprise = removal. > > > > How hard that would be I don't know. And I would well expect if one= deviates from > > > > real hw expectations/configs (such as not 0 slot/partial func remov= al), > > > > one would quickly stumble upon issues as that's not what what vend= ors write/test > > > > drivers for. > > > >=20 > > > > Even if it's not likely to be used in practice (guest still might n= ot support it), > > > > it may serve as test-bed for guest drivers. > > > > =20 > > > > > Thank you very much! > > > > >=20 > > > > > Dongli Zhang > > > > > =20 > > > =20 >=20 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 12:08:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 12:08:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408375.1640993 (Exim 4.92) (envelope-from ) id 1x2Sj0-0006si-T2; Fri, 04 Sep 2026 12:08:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408375.1640993; Fri, 04 Sep 2026 12:08:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Sj0-0006sb-Pw; Fri, 04 Sep 2026 12:08:54 +0000 Received: by outflank-mailman (input) for mailman id 1408375; Fri, 04 Sep 2026 12:08:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Siz-0006rr-Il for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:08:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Siy-00GQOE-Uv for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:08:52 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ab4bf-bab6-0a2a0a5309dd-0a2a4504b17e-30 for ; Fri, 04 Sep 2026 14:08:52 +0200 Received: from [40.107.162.8] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ab4d4-b57f-0a2a45040019-286ba2088e79-4 for ; Fri, 04 Sep 2026 14:08:52 +0200 Received: from AS4P195CA0046.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:65a::27) by AM8PR08MB5555.eurprd08.prod.outlook.com (2603:10a6:20b:1d3::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.4; Fri, 4 Sep 2026 12:08:49 +0000 Received: from AMS0EPF0000056A.eurprd02.prod.outlook.com (2603:10a6:20b:65a:cafe::8a) by AS4P195CA0046.outlook.office365.com (2603:10a6:20b:65a::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.13 via Frontend Transport; Fri, 4 Sep 2026 12:08:49 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AMS0EPF0000056A.mail.protection.outlook.com (10.167.242.120) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Fri, 4 Sep 2026 12:08:48 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DU0PR08MB9050.eurprd08.prod.outlook.com (2603:10a6:10:47a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 12:08:14 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 12:08:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=TdURaDGFh93m/rHFZy22EfCifIPOmomEpZxXo0yKCxCHL7/l59TPUZOX9WY98gpGVZuOfofVdBHF9DUGI68si3Kc6Kmnx9BfzRrBE/tVp1KMuQls6oHGcNyCsjtw1od3CHYT9yZmWRB5cHc8J6bicu8zDw9VatKln+1ptPYT0/GjY1L6DFqyoi0vb9y2L/HkaZLBCoBtKeJ5OQkgKM55X7JA70F5tzOhBusVL4acOHaNqldsuJk22cLYkyvzu6wi/BY7bU/c7mK39TPbBqpAn75/Y0/sjDrhmWQwGkD1YqoLlDIUMvB1S2PqOkW35lGZf2wj4S1skhc2QxpN0r1JwA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SxLwEAMhmo17uxWlJyGZKHqeeRrXoOvc5qWiUbbbdSg=; b=ybCSS4mFtQAq2Lu86VRLsWx0EbbL0sXXvNQuEYEpH/uw4o6/ZPS1TYoD+KmthuKdTfbNdhMFtUQ3pOwRC281fjgbT54pvKh93auaYbmvF/L+XYWHV9JU4l0WAgGCvyNFEzhcWDyLQYB9qVS13wsAcDCnfC0NQ3wBjhlc4WH3lAqzATUp0tU5rqkOR+EtxvWwsZDvoMdPl0WH0ldJN94gvUHADjmPA/orABQ3baWXu0VNE8fLwpD7opz/12DVgkltexrEY7k5Y9LtAFCYMl8H22Fcsytx/s1m3hxFf0gYrVxR3rxsp/tmHKe5ZbIT7A/5xIREZeqRuyL7XeH2/RIj0g== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SxLwEAMhmo17uxWlJyGZKHqeeRrXoOvc5qWiUbbbdSg=; b=MDdcWRo6Fhgkci/ATh7n/WVXgLHyHitV4mFp46JxPwjNrxbQLA4oP7J/QMrQFYmmL4DPS2jBKVGaWxoQh2tFzI+UWWMHc+NblpG4dRCc3usjqCSONBan84on+95A1cwjgmrIvJbqNN6oxSpY3a9vmMT1YhxSYuaf2/6y36Fqvk8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UPFjYjsbs6Ko8IuJk4t7IB1Lb57hI5FLQ5tyYl/iOokfm6QYIAI7G//5T84QYAuGBDQkU39Zxl/ny0WR0+wDQ+7Ui5+4WBkQaKG3TAIyLGNOJZRItngtlUUAzjvnZldqo/+PDjAnqGOe8v/gb1gX+y3Zx9ie7yfqPndff8V8eZgIGciugomajoZ2Mtl4RoGsxQH48EAUWRi8pCdQl1bCXs022KRW8casRbsJ4RnHh4PyYoOkmn0IGnnt2mYUkcU+u8PvpCfDGFW6mdPjpU3JbrGkOJjWYQ1m1l7jGO/WBguEsfMs7kpP708Nmx6wlTaq9vq1QkdjhKiV73G92RP8Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SxLwEAMhmo17uxWlJyGZKHqeeRrXoOvc5qWiUbbbdSg=; b=RyEZN8duB/GKM3CBYkNiDa0HVe3KsX+7bpXOvm8OVKWqP+JdPGAN3a4GjxuJVF6wzF7ssR8bRk1IcpwlghxqnMYn2a7Ww+Pq525myZu1KYbmcL91OVj8UDAkk1460SgnZ+FHqkT5YoMD8wqpsasSOdrNFyl+8iLi0yH1b1JzJUvYl8RlcmVLPiio5HyvJ45Yx3/dXBuyuiES/voCGk/rvWWkHMHDMIw6AqEpoPeoEVp4fcv7ptLMjVklQMHhyPUJ7r6osbBeSwVBjwp1VyEojPG32gN770PyNdzO43Vd0+YL4X/qtaEUe7K8Mhrkh794l5Y98fZBsxr2/YvAbUsSAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SxLwEAMhmo17uxWlJyGZKHqeeRrXoOvc5qWiUbbbdSg=; b=MDdcWRo6Fhgkci/ATh7n/WVXgLHyHitV4mFp46JxPwjNrxbQLA4oP7J/QMrQFYmmL4DPS2jBKVGaWxoQh2tFzI+UWWMHc+NblpG4dRCc3usjqCSONBan84on+95A1cwjgmrIvJbqNN6oxSpY3a9vmMT1YhxSYuaf2/6y36Fqvk8= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH v2 3/5] xen/arm: Clean up 32bit arm_smccc_1_1_smc() Thread-Topic: [PATCH v2 3/5] xen/arm: Clean up 32bit arm_smccc_1_1_smc() Thread-Index: AQHdPF5MaImMoDplI0uGAg1xhuIeaLa+U1WA Date: Fri, 4 Sep 2026 12:08:14 +0000 Message-ID: References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> <20260904111228.3022634-4-andrew.cooper3@citrix.com> In-Reply-To: <20260904111228.3022634-4-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DU0PR08MB9050:EE_|AMS0EPF0000056A:EE_|AM8PR08MB5555:EE_ X-MS-Office365-Filtering-Correlation-Id: cdf815f8-0f1a-4bb9-9d54-08df0a7d46d6 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|10067099003|11063799006|4143699003|3023799007|18002099003|22082099003|38070700021; X-Microsoft-Antispam-Message-Info-Original: z67eRCPy+qPY39U3EcYddm0L/OW8cIqbu9ZX2NfiLWotvP2mMBGvEmPie440yfU99wsyItzZOZuc5SBYF4p97sgSsSLiN4BvfyfwkIWRsEmYS+BT4r3G8ysjuDuHRGu710qc1GxED/0Xo3BHGfsxqy6XQkSJk3OeOe5qUeWVrTAVhgZSWsAL8bd80cuA1+uT2bhWARmV0kjrXD+xDVsyXvlbxw0kfnJMoO2TF5cqLoj8Th+jHHZOl01rUDAbohQPOExzFEpOvbpYkdnv4RSDSPyExtwIEBb9U5A+O3MVkE/aUdk5bKmeOfoCUYVhYVV4Hei/uPaCaPchBTMf8r1XjJNJRssuyRVEpg10sOtIdVrETmUGZWjDrPjK1m6GsLdDCE5HU5oksLRTepPyY+zBuEetzyd2DRbRnZPV3865R74hz/mDe2pvkvW8uxdwYF5fWWh+4/e9nVYNya028nrAfKvYWiY2Mj4zY0x7+3K1NNeCqlBJN/hIvo+aOvaoVANJmweuEFSWk+OV0qhKQEjSHxViMgMLshmdxZxBXk7x1w/CpLo5uyoAQYolBLR6BcBcY9D//8HZsvOT89fTcu3lqXkqX68Egl4oG/pPU1V3DS6sIqTQ91NGwGEHVL0cGlV2YfcAbHXPCQHqRkOdYgFtsSWu/Ftw5GAS/M34BgwcGi4XMNFBNW3/uO22ME+kXR6MRaoDTkWGWiNfrn9e/r5bO4X942OlTAyQOklrp0N3w7M= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(56012099006)(10067099003)(11063799006)(4143699003)(3023799007)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <537AAFB8F8EB9F4996DE2836601A1DEB@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: pSej11UB/OSC0lXSs3u/zVdQLImirEHlOaW8lvPDhq5o1ghE26IKmGukQim0F1hWPt+1rXjEQ3ZwnI+/tzb4UHg09kaSUxYTcD79eHDZCfnz10/Fg5DmKlFLEelm3bUAo+xGt84AFgUbd9o2JmizyzCT1e4VkrhgIxOkheWJiEM2zqY8u92DTkpVTtz3gNEerGPuLrbHoNJaUcmFGZ5eYUIIBkGSbBvphCutbuiZLH6HyLoJit9ris/gnG+cKk9IG5/H2WeAqTlKCul4VjVPpiSzqguXzLdHH2BlVg9nHHJu7F2l5hOGSO2+ZWmLXWcirevmGaCOcdPgnSr1Bnn0Gw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9050 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF0000056A.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 6c892eac-5730-4eb8-b0fb-08df0a7d3261 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|35042699022|1800799024|82310400026|36860700016|14060799003|22082099003|18002099003|3023799007|11063799006|56012099006|10067099003|4143699003; X-Microsoft-Antispam-Message-Info: H3x2vc4VJ5IfR0jWFqJjjtXhNve2/zJ9cGd7Y8rXjYGaNva5RApygJY/HrUG7nG6GaZhsv71l3nxg4p6Uj4Ng1SDhYDfv4/ywT87s40Ly/W3dHU+N+uiY5TELaUb2vV6xcHpS9G0hh1Iqz9Lf2xDrhJpchvQtS+VvxuQDxoz7/eXW+UlZ2iEYDAQqt5RGmIShNjtGAZxWR6x7CE/dDsWNKIKpbAHPvdcI9uoi7RiSt7NHu1KTXiDdyKhsCwaxIvuJsQ77kBjbaRnmImo/8tUX0+OMgkJY+E/KYypM+APRdLO9IqwEv9KWNeVRiJ+E3g0wQKm2Ha9EzAFX8nFVjqqcO3lwAoIV173FrmSfyCD0X0fuIU0wyFznKqlf9XpIc7XD3hFoa3ty9SDJaMNOudX/GfVCYrZHo9zQ4dAmpEBzEQGpHkS+h3SFD2k1C+QU7pa19/teYEqqCSUdZA31C/IHo/73SFi2UZ8a276WS9ImMaXLuKEJDyh3yYeWRyRPup52XIw/F7IERQXXPvtYPVMH/mSzRcDhnL2IQyZM211LBPmtkQOIv6tiuBYSw5rD5Bl5dEUd04Gk5vDBuOOXgi7rZbPk55oHYJs736lxLSKSJ4weoMp2tsHyjpjmIgMTU14zxsDNBBXrOOisW5yQ6EeNDGzi3AhSW/MCs6zCIhTeJs= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(23010399003)(35042699022)(1800799024)(82310400026)(36860700016)(14060799003)(22082099003)(18002099003)(3023799007)(11063799006)(56012099006)(10067099003)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: UpBUh/HUwW7/NJclk3Xh4vMi8uQYqQKKG8T+eAvRBidd4RMMYYqdPf95ioRl2JFGVG2MWbOtzBDZyt6g+2qKEK9h5+34c3hgTLtq32TcObi4hq/ZAS3Xmy1/UYgWC4IOpDdi3UZmntngVNM8mx7lO4RNM9nhDVzsJU4wE8rtOqfy6LDohGE4k2QUENuBVCdGjhAv4Es8CH0velAOCOLoyYJG7ktYDjOGLRg67SSiUI1sqFATRv9dQ5hvYkGJjAl7hVAT1meJxkJ5Rn7I1GWiJTdk9apoktUTfRkTY1lkaGk5prO+ANC91tYqf2Sl+07z8v5v4RsEzsM2d6EynpbUyDQW5pdyZFAgkWLk5izvDGfzK6wsuZuPtJvT7iVUZWfqpVW/k6qDaSTsD3mdBdNtD7fr6KXtZmn4Y9rKGaiIwvnVBPIm2fKBQjwNfIOZj9wa X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 12:08:48.4560 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cdf815f8-0f1a-4bb9-9d54-08df0a7d46d6 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: AMS0EPF0000056A.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5555 X-purgate-ID: tlsNG-ebf023/1788523732-502E4B50-5192CCAF/0/0 X-purgate-type: clean X-purgate-size: 6009 Hi Andrew, > On 4 Sep 2026, at 13:12, Andrew Cooper wrote: >=20 > ... before making a related copy of it. >=20 > * Drop __constraints() so the output parameters are visible in the same b= lock > as they're defined. Use PASTE() rather than opencoding it. > * Adust the indentation of trailing \'s for consistency. Small typo to fix s/Adust/Adjust/ Can be done on commit and retain my R-b Cheers Bertrand > * Drop the newline at the end of the instruction. > * Indent the if condition correctly. ___res is always of type > arm_smccc_res (declared in __declare_arg_0()), so drop the typeof(). > * Drop arm_smccc_1_0_smc() as it has no users. >=20 > No functional change. >=20 > Signed-off-by: Andrew Cooper > Reviewed-by: Bertrand Marquis > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers > --- > xen/arch/arm/include/asm/smccc.h | 45 ++++++++++++++++---------------- > 1 file changed, 22 insertions(+), 23 deletions(-) >=20 > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 832157f43734..5fe54013ac83 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -56,6 +56,8 @@ >=20 > #ifndef __ASSEMBLER__ >=20 > +#include > + > extern uint32_t smccc_ver; >=20 > /* Check if this is fast call. */ > @@ -115,24 +117,24 @@ struct arm_smccc_res { > * This is manual register scheduling for the asm() statement, and any ot= her > * logic to evaluate may clobber the already-scheduled registers. > */ > -#define __declare_arg_0(a0, res) \ > - auto __a0 =3D (uint32_t)(a0); \ > - struct arm_smccc_res *___res =3D (res); \ > +#define __declare_arg_0(a0, res) \ > + auto __a0 =3D (uint32_t)(a0); \ > + struct arm_smccc_res *___res =3D (res); \ > register unsigned long arg0 ASM_REG(0) =3D __a0 >=20 > -#define __declare_arg_1(a0, a1, res) \ > - auto __a1 =3D (a1); \ > - __declare_arg_0(a0, res); \ > +#define __declare_arg_1(a0, a1, res) \ > + auto __a1 =3D (a1); \ > + __declare_arg_0(a0, res); \ > register auto arg1 ASM_REG(1) =3D __a1 >=20 > -#define __declare_arg_2(a0, a1, a2, res) \ > - auto __a2 =3D (a2); \ > - __declare_arg_1(a0, a1, res); \ > +#define __declare_arg_2(a0, a1, a2, res) \ > + auto __a2 =3D (a2); \ > + __declare_arg_1(a0, a1, res); \ > register auto arg2 ASM_REG(2) =3D __a2 >=20 > -#define __declare_arg_3(a0, a1, a2, a3, res) \ > - auto __a3 =3D (a3); \ > - __declare_arg_2(a0, a1, a2, res); \ > +#define __declare_arg_3(a0, a1, a2, a3, res) \ > + auto __a3 =3D (a3); \ > + __declare_arg_2(a0, a1, a2, res); \ > register auto arg3 ASM_REG(3) =3D __a3 >=20 > #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ > @@ -158,12 +160,6 @@ struct arm_smccc_res { > #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) > #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) >=20 > -#define ___constraints(count) \ > - : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3) \ > - : __constraint_read_ ## count \ > - : "memory" > -#define __constraints(count) ___constraints(count) > - > /* > * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call > * > @@ -189,10 +185,14 @@ struct arm_smccc_res { > register unsigned long r2 ASM_REG(2); \ > register unsigned long r3 ASM_REG(3); \ > __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > - asm volatile("smc #0\n" \ > - __constraints(__count_args(__VA_ARGS__))); \ > + asm volatile ( \ > + "smc #0" \ > + : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3) = \ > + : PASTE(__constraint_read_, \ > + __count_args(__VA_ARGS__)) \ > + : "memory" ); \ > if ( ___res ) \ > - *___res =3D (typeof(*___res)){r0, r1, r2, r3}; \ > + *___res =3D (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > } while ( 0 ) >=20 > /* > @@ -200,7 +200,6 @@ struct arm_smccc_res { > * v1.1. > */ > #ifdef CONFIG_ARM_32 > -#define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) > #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) >=20 > /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ > @@ -217,7 +216,7 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > regs->r3 =3D res.a3; > } >=20 > -#else > +#else /* CONFIG_ARM_64 */ >=20 > void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, > register_t a3, register_t a4, register_t a5, > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 12:09:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 12:09:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408391.1641002 (Exim 4.92) (envelope-from ) id 1x2Sjt-0007nm-5W; Fri, 04 Sep 2026 12:09:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408391.1641002; Fri, 04 Sep 2026 12:09:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Sjt-0007nd-2H; Fri, 04 Sep 2026 12:09:49 +0000 Received: by outflank-mailman (input) for mailman id 1408391; Fri, 04 Sep 2026 12:09:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Sjr-0007nL-Fp for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:09:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Sjq-004SOL-SV for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:09:46 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ab502-bab6-0a2a0a5309dd-0a2a450c9f2e-4 for ; Fri, 04 Sep 2026 14:09:42 +0200 Received: from [52.101.70.41] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ab505-f479-0a2a450c0019-346546292b1c-3 for ; Fri, 04 Sep 2026 14:09:42 +0200 Received: from PAYP264CA0035.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:11f::22) by GV2PR08MB8413.eurprd08.prod.outlook.com (2603:10a6:150:c3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 12:09:33 +0000 Received: from MI3PEPF00008550.eurprd05.prod.outlook.com (2603:10a6:102:11f:cafe::45) by PAYP264CA0035.outlook.office365.com (2603:10a6:102:11f::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Fri, 4 Sep 2026 12:09:33 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by MI3PEPF00008550.mail.protection.outlook.com (10.167.240.4) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.8 via Frontend Transport; Fri, 4 Sep 2026 12:09:32 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DU0PR08MB9050.eurprd08.prod.outlook.com (2603:10a6:10:47a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 12:08:59 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 12:08:59 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=RBvhPrRj563kcxqA5bEEBOdifPB3g71mnUdbkTqPKOBAZyNtRH1jRB1KHTdytHwvjjDKf0xmqgU/slx4SahR0dxIiIfBQ995ZSZitYdpk0Hbcrw27wFG6y4qad+AeMZvqCL2A1BJ019PFdeRlmSe1W+rYRoAh5CWxQSsbCK5240pZDt5NJwwFh926ZTemkxLIZQ/VQLgwZUJXWkJX5j4EBx+5yq9o/OZuw0RxeKZ8gCV7gZ+/WZoGn9L7ZHXkA2wc5ELcB634JStRm5PFpobMRP/AOi5JZFMq1rg7kXJRB0uqGrKyn0ZExLR9cjSM1nJpEroTe/Y2RFAIIaXR1jRFw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QOytzZh/5HlhwJyTF14TzukEBwFY6/0ffjgYTXdK2YQ=; b=q/akePR8BPdK5kE3jYZj2QMJ6RKVK8VuwlJCnhKAlW/Km1G17yIfgJRjw75ghk7mXCej1vUrhvkBXjk96trKNvLUNQRRDJiyrEy20U8+FPOH1pZ+qC4flEzbU3S5b2+LQWWuGc+DJzMt3odDWqjW5PjRPIYw8mlmfh2P8Qt0cprW51Y69fbWe3d4i20mZkIP1/XgVkJLJLqtM1XYsZ5nIQ3wrw+nny17emLoz58x6SKknr1XajVEh7tIiZfNwsh7KpYcu3Lpc9grqmN+F9olN1UqWCK9NRCEmBYzmf2nQpjK2sNBitsVsH8gm26d0YPHmBsQ1VqCk5qv0qvsY6SKZQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QOytzZh/5HlhwJyTF14TzukEBwFY6/0ffjgYTXdK2YQ=; b=f1RQ3OO6JwSBwbedjbKMmy6hNtlikxfSC3/JJKL5zpOfiR3QNQxQMMiRkSAUL3aEq8Meza5jqaBEr049xfIJwQmETr90wW/ju4B+XMdysO077R6A5/P5nedfyrDwJnaIpVTG/y5Djj+q5IqPNf8SgfxcK5QmEmQMOYlPru1ddDI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FfVihgfT6o+4lbI5eA4cIoGbWylFBENVEtPe8wSpdLkLgRR5POnuO17649bP7nDaKbIm1fwbZYUuSaqXvtVfJvfm0hk46kOVuzd+YRPwdK4E/+HTXfh7kghjAu6a+hiQVmOBCCgkuBlMExxHd0cI94RSUBOsnh0BS2z72PWTgfEmdFwSDE5k9gKFTWWxKbf0ojy9wmPsiJDMHOEfwCSLzW72yHcxEGFJEPUbA4gbhiA5LEweC0gAK0MezUtxW6DgaAi8fkDjrKfv3Gem2LdWhLSWHuO0mhDfahMPoajrHJ8gunyfbipjMbIp45mK9qZFPKbTjpHLX4xChz6C32e+Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QOytzZh/5HlhwJyTF14TzukEBwFY6/0ffjgYTXdK2YQ=; b=xYtpAMw+dTwaoasmv7Mp4C5GTlj8JRhkoUeOcD1PBclooxZXjpiwrV2omcNRRRN5cEAsE4PsI+9Bwl37NubdWwYMJrFS59/psYNN2zbzmANGwAIyS+U7MSf/ghzzP3O+MWJJDtcto0TkeEVVMI4CGscGUlxS2MMO5HfEyzT/SWD0WlLktzrRTE6pWJV55h3GNSFc+Q3i0dlDltOxFmfNu1XYrXtpNEH3vJGjnyu47UMeNG1gufjkL+SZ3snuSXpzpmouM/th24Y3u2rWUgmX8FBg6j8Au1pMKXmGpZ+KLMNp9RUZWSK/S7GJym8lqg3w3oseTdqVTzrUBJmonmwD+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QOytzZh/5HlhwJyTF14TzukEBwFY6/0ffjgYTXdK2YQ=; b=f1RQ3OO6JwSBwbedjbKMmy6hNtlikxfSC3/JJKL5zpOfiR3QNQxQMMiRkSAUL3aEq8Meza5jqaBEr049xfIJwQmETr90wW/ju4B+XMdysO077R6A5/P5nedfyrDwJnaIpVTG/y5Djj+q5IqPNf8SgfxcK5QmEmQMOYlPru1ddDI= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH v2 4/5] xen/arm: Rewrite arm_smccc_smc() for arm64 Thread-Topic: [PATCH v2 4/5] xen/arm: Rewrite arm_smccc_smc() for arm64 Thread-Index: AQHdPF5OKtIIWDItQUCAcbYOebdKZ7a+U4sA Date: Fri, 4 Sep 2026 12:08:59 +0000 Message-ID: <28333BBC-9E6C-4F87-B70E-2A6EA427462B@arm.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> <20260904111228.3022634-5-andrew.cooper3@citrix.com> In-Reply-To: <20260904111228.3022634-5-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DU0PR08MB9050:EE_|MI3PEPF00008550:EE_|GV2PR08MB8413:EE_ X-MS-Office365-Filtering-Correlation-Id: 36bc6f5e-4e24-4cdf-bce3-08df0a7d6139 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|56012099006|10067099003|11063799006|4143699003|3023799007|18002099003|22082099003|38070700021; X-Microsoft-Antispam-Message-Info-Original: IJRbty9F8dgpwye+5C2l+TQUpZBX0a5DR/IOzttcCsJbGifqcjVsnQWuhAlW4/Fl5ojReM20SrXErN8vJLXpzFDMN4a0x1gBOF4TZ9ElToWAiuTtJjP3Z7C4ltWz0ZLmks3AIwatjttDh1YBF5qOA8bOCB8fNulWVprcbjipz4Z1Yi8wE6gFz0chAnW9ub00sfAFu5Pnk0cfNUJ3sbNwdzGcBP0ThE3vYNKzsuzxZSQWSqTfQ55nP3hVotvpdRShSZzIHFXLEf+TE0oRTksSjPaSqMwt8QDO1cQrb2S1MwGIVPldpYCSshIxzcC2yiZhXEvnAZhDpxWu4ASXbsAHiMBob0HexRa/VGA3BW4vW8PqqEl5Kj9GgxFFsXNcRG8igNBudGzp8ZrYB1CKM4Acrwo+CwPi3grQvncT+d2t8wnnpCev4dgKBogJ+RFbYg8G02xMf4xUHFnC+jPliERUDHVp2hWmmiraqOHpppgyR9LyYWecU42fUDTWOM3mJuTNxziK6vqgKC5zAP+zwHukoA9Lc3df2NaiDZuNuB3oySBA0l7E3lYP06oCPEuLiWT/BEbKqMicRI3wY0zVA87xjSlzv53BYjp4AXlzHAvLSaqAGo63/ydie7jzIN+24IsT4YTMJmtKJa9F/8LK67Am75gnUrvWEZLbhsfFdMte/LYlImMlKDHg8B+RJGqNl6nEeURSsfuy/Nam/IIio6oIDElK/MTZxEZNEEgGTErXHNs= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(56012099006)(10067099003)(11063799006)(4143699003)(3023799007)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: bvCm1VmdL/a3r3z5K6oFy2TQPYQBqSlGYtWkiNpLhCNgbDyHqxUF8B0DjBrezIdLToNMauuJVul8Y2T8PWjXpU4nZ5E5GGoUO/c65sykMY5sCiY15STFB0fL7drwUhpgGKX1czYcIDIWflc2k/7lh1AhLDC5FTrbvoXzjtJaKFNzzgTurudaeIdSeeDaNL47TiTUt4oVKmKB6tqZmWyuJdnz7t95mikWtsbkDL0KGmk11YQDZc20GQRmxO+WycP3Yh0+yqeskivhgEeb4ER1IUExuJSuh8BiO6/cVcftVoNir6NOtOQQmgSoEn3CMidTKJqOpfPJz1o2y2yma9Gt7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9050 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: MI3PEPF00008550.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ed03a81b-b600-4220-ca3d-08df0a7d4d2a X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|35042699022|23010399003|14060799003|36860700016|82310400026|1800799024|11063799006|10067099003|4143699003|56012099006|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: JUAFPGyHFO7yZtjujOqq8p7HMN3CiuEEn6uVN2KF6D7UZ7+NoYxKg2CBg2f7yqChGv4Y00QMnWKkVWIt4qvBcWgb0NJlvLa1UE2ZMeAYU5RsPjUXYpwVJWyz2n9fLPPjHVzURD4KKieU9SunQr0AmyO5R/Q70DXbAlbcrZ9Venf8Rz9wxaeM5IFf6PUVhDvebgzis4u/G2e+XxKTBvmxMEGBjzXWYwo7gYLqEZTUpUeatW2jf5t+nvVVZdwQVRaRMJLDRUtU112ZvwQTMyR7aVOolBqaQ5qiRCHG0/NJHet6yRtohgptVORaPVbLl8hd7SZDTCs2+zOP9NGnWRP/QumB6dqtcWVGPlzkwoA6b0sXeOuUTsj3IS3s203UzSXWZBelzYGZ+3/p0oqoROo6F7z+z1ptzTpgzlSdmR/OW0QKkpbBhd3lkGjZa8MoNjOgbO8zed/M4P14foOnb+lPGG/jFWYZ27BnYOHE+lt/TRe+bN6TruHgqCSojBbFvBdyji/5+lLKRsxRepsQ1QHRRKnnsf624MWv4MBFcfqOXlHB+P++YzhuE+ivlkMGsJ6RH30Eboy/wteudiJflfsDHFh4ukK1gOb6MRuXYC15AveLgqobDSQQ3fT0yCLQh+anI1zYQdviISr8X8+BEA3QoSgfwv2T5jEIozsganq62uM= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(35042699022)(23010399003)(14060799003)(36860700016)(82310400026)(1800799024)(11063799006)(10067099003)(4143699003)(56012099006)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 9w+ztd038/dL4l5Lo4rbUTeJ5uk6CxzinsgxbKherzbdzdhLMAlNmd6T5fVnhzByZEZ6+vPoHLH3OUMnvKL/gYzMw9aRZTh8MemuwpYE7+yyI/er5eM9iNkY/LrcvHJ+3IRBb7TpLvIJB0n34TBIQKf7o3Ponbi4/rqLluAfZQhT7ex9zgofeGk4A5fHGiyF2wKYi4PnbVPYcVUQadtBsjb/aSGaDVZDMXu2LqUg2pucdRpmNTIZDMJcxqub4LjPr7YI9ZuCYBzucFvtych+nHPlmvZKtGajNOxr72Ktj/Cqbo7FX5L9r2zcMlpY3MxAAR3ydX0wRSgYMuIQyiq3yVS7OSq6pccSN9h9p7CJ8tH2SbXhXkVzMXUmvqLwxHrrEw4HkaQZGsfCPbMhvkQTOM/dhuvojLhmAr4QGDaNH02l5CDHKWnJfs3wmUnwv7Nu X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 12:09:32.6289 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 36bc6f5e-4e24-4cdf-bce3-08df0a7d6139 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF00008550.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB8413 X-purgate-ID: tlsNG-d25034/1788523782-77AD4A5B-B0D5E2FE/0/0 X-purgate-type: clean X-purgate-size: 10423 Hi Andrew, > On 4 Sep 2026, at 13:12, Andrew Cooper wrote: >=20 > SMCCC v1.0 says that x4 through x17 may be clobbered. SMCCC v1.1 says th= ey > are strictly preserved, and SMCCC v1.2 permits them to contain extra retu= rn > values. >=20 > Xen deals with this by having __arm_smccc_1_0_smc() as an out-of-line > function, but this causes awful code generation in arm_smccc_smc(). > cpus_have_const_cap() is opaque to the optimiser, so we end up with one b= asic > block doing the reasonably-ok arm_smccc_1_1_smc() code generation and a s= econd > basic block setting up all 8 input registers even when they're not needed= , > spilling or discarding x8 through x17, and calling an out-of-line functio= n. >=20 > Remove __arm_smccc_1_0_smc() entirely, and rewrite arm_smccc_smc() to dec= lare > x4 through x17 as clobbered. >=20 > This fully inlines the SMC, is a single basic block which instructs the > compiler to spill or discard the potentially clobbered registers, and onl= y > sets up the necessary number of arguments for the call. >=20 > No functional change. >=20 > Signed-off-by: Andrew Cooper Lot better thanks for the fixes. Reviewed-by: Bertrand Marquis Cheers Bertrand > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers >=20 > v2: > * s/PSCI/SMCCC/g > * Rewrite the comment for the new arm_smccc_smc(). >=20 > Bloat-o-meter reports: >=20 > add/remove: 0/1 grow/shrink: 0/10 up/down: 0/-795 (-795) > Function old new delta > symbols_sorted_offsets 23832 23824 -8 > symbols_names 42962 42943 -19 > symbols_addresses 35128 35104 -24 > __arm_smccc_1_0_smc 32 - -32 > call_psci_cpu_off 144 76 -68 > seattle_system_reset 92 16 -76 > seattle_system_off 92 16 -76 > call_psci_system_reset 112 32 -80 > call_psci_system_off 112 32 -80 > call_psci_cpu_on 252 124 -128 > psci_init 628 424 -204 >=20 > An alternative way to do this would be to have x8 thru x17 in the clobber= list > rather than the output list which would reduce the source size, but this = form > is more amenable to having SMCCC v1.2 worked into it too. > --- > xen/arch/arm/arm64/smc.S | 16 ------ > xen/arch/arm/include/asm/smccc.h | 92 ++++++++++++++++---------------- > 2 files changed, 45 insertions(+), 63 deletions(-) >=20 > diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S > index 68b05e8ddd12..65b4eabe4f87 100644 > --- a/xen/arch/arm/arm64/smc.S > +++ b/xen/arch/arm/arm64/smc.S > @@ -13,22 +13,6 @@ > * GNU General Public License for more details. > */ >=20 > -/* > - * void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, > - * register_t a3, register_t a4, register_t a5, > - * register_t a6, register_t a7, > - * struct arm_smccc_res *res) > - */ > -FUNC(__arm_smccc_1_0_smc) > - smc #0 > - ldr x4, [sp] > - cbz x4, 1f /* No need to store the result */ > - stp x0, x1, [x4, #SMCCC_RES_a0] > - stp x2, x3, [x4, #SMCCC_RES_a2] > -1: > - ret > -END(__arm_smccc_1_0_smc) > - > /* > * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, > * struct arm_smccc_1_2_regs *res) > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 5fe54013ac83..4ed2a40ed0ac 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -16,9 +16,6 @@ > #ifndef __ASM_ARM_SMCCC_H__ > #define __ASM_ARM_SMCCC_H__ >=20 > -#include > -#include > - > #define SMCCC_VERSION_MAJOR_SHIFT 16 > #define SMCCC_VERSION_MINOR_MASK \ > ((1U << SMCCC_VERSION_MAJOR_SHIFT) - 1) > @@ -57,6 +54,9 @@ > #ifndef __ASSEMBLER__ >=20 > #include > +#include > + > +#include >=20 > extern uint32_t smccc_ver; >=20 > @@ -160,6 +160,8 @@ struct arm_smccc_res { > #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) > #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) >=20 > +#ifdef CONFIG_ARM_32 > + > /* > * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call > * > @@ -199,7 +201,6 @@ struct arm_smccc_res { > * The calling convention for arm32 is the same for both SMCCC v1.0 and > * v1.1. > */ > -#ifdef CONFIG_ARM_32 > #define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__) >=20 > /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ > @@ -218,53 +219,50 @@ static inline void arm_smccc_guest_smc(struct cpu_u= ser_regs *regs) >=20 > #else /* CONFIG_ARM_64 */ >=20 > -void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, > - register_t a3, register_t a4, register_t a5, > - register_t a6, register_t a7, > - struct arm_smccc_res *res); > - > -/* Macros to handle variadic parameter for SMCCC v1.0 helper */ > -#define __arm_smccc_1_0_smc_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ > - __arm_smccc_1_0_smc(a0, a1, a2, a3, a4, a5, a6, a7, res) > - > -#define __arm_smccc_1_0_smc_6(a0, a1, a2, a3, a4, a5, a6, res) \ > - __arm_smccc_1_0_smc_7(a0, a1, a2, a3, a4, a5, a6, 0, res) > - > -#define __arm_smccc_1_0_smc_5(a0, a1, a2, a3, a4, a5, res) \ > - __arm_smccc_1_0_smc_6(a0, a1, a2, a3, a4, a5, 0, res) > - > -#define __arm_smccc_1_0_smc_4(a0, a1, a2, a3, a4, res) \ > - __arm_smccc_1_0_smc_5(a0, a1, a2, a3, a4, 0, res) > - > -#define __arm_smccc_1_0_smc_3(a0, a1, a2, a3, res) \ > - __arm_smccc_1_0_smc_4(a0, a1, a2, a3, 0, res) > - > -#define __arm_smccc_1_0_smc_2(a0, a1, a2, res) \ > - __arm_smccc_1_0_smc_3(a0, a1, a2, 0, res) > - > -#define __arm_smccc_1_0_smc_1(a0, a1, res) \ > - __arm_smccc_1_0_smc_2(a0, a1, 0, res) > - > -#define __arm_smccc_1_0_smc_0(a0, res) \ > - __arm_smccc_1_0_smc_1(a0, 0, res) > - > -#define ___arm_smccc_1_0_smc_count(count, ...) \ > - __arm_smccc_1_0_smc_ ## count(__VA_ARGS__) > - > -#define __arm_smccc_1_0_smc_count(count, ...) \ > - ___arm_smccc_1_0_smc_count(count, __VA_ARGS__) > - > -#define arm_smccc_1_0_smc(...) = \ > - __arm_smccc_1_0_smc_count(__count_args(__VA_ARGS__), __VA_ARGS__= ) > - > +/* > + * Make an SMC call compatible with both SMCCC v1.1 and v1.0. > + * > + * SMCCC v1.0 says that x4 through x17 are clobbered. SMCCC v1.1 says t= hey > + * are strictly preserved. Always mark x4 through x17 as clobbered. > + */ > #define arm_smccc_smc(...) \ > do { \ > - if ( cpus_have_const_cap(ARM_SMCCC_1_1) ) \ > - arm_smccc_1_1_smc(__VA_ARGS__); \ > - else \ > - arm_smccc_1_0_smc(__VA_ARGS__); \ > + register unsigned long r0 ASM_REG(0); \ > + register unsigned long r1 ASM_REG(1); \ > + register unsigned long r2 ASM_REG(2); \ > + register unsigned long r3 ASM_REG(3); \ > + /* Potentially clobbered in SMCCC v1.0 */ \ > + register unsigned long c4 ASM_REG(4); \ > + register unsigned long c5 ASM_REG(5); \ > + register unsigned long c6 ASM_REG(6); \ > + register unsigned long c7 ASM_REG(7); \ > + register unsigned long c8 ASM_REG(8); \ > + register unsigned long c9 ASM_REG(9); \ > + register unsigned long c10 ASM_REG(10); \ > + register unsigned long c11 ASM_REG(11); \ > + register unsigned long c12 ASM_REG(12); \ > + register unsigned long c13 ASM_REG(13); \ > + register unsigned long c14 ASM_REG(14); \ > + register unsigned long c15 ASM_REG(15); \ > + register unsigned long c16 ASM_REG(16); \ > + register unsigned long c17 ASM_REG(17); \ > + __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > + asm volatile ( \ > + "smc #0" \ > + : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3), = \ > + "=3Dr" (c4), "=3Dr" (c5), "=3Dr" (c6), "=3Dr" (c7), = \ > + "=3Dr" (c8), "=3Dr" (c9), "=3Dr" (c10), "=3Dr" (c11), = \ > + "=3Dr" (c12), "=3Dr" (c13), "=3Dr" (c14), "=3Dr" (c15), = \ > + "=3Dr" (c16), "=3Dr" (c17) \ > + : PASTE(__constraint_read_, \ > + __count_args(__VA_ARGS__)) \ > + : "memory" ); \ > + if ( ___res ) \ > + *___res =3D (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > } while ( 0 ) >=20 > +#define arm_smccc_1_1_smc(...) arm_smccc_smc(__VA_ARGS__) > + > /* Make an SMCCC v1.1 compliant SMC call with guest register state. */ > static inline void arm_smccc_guest_smc(struct cpu_user_regs *regs) > { > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 12:13:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 12:13:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408403.1641012 (Exim 4.92) (envelope-from ) id 1x2Sni-0001VE-RH; Fri, 04 Sep 2026 12:13:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408403.1641012; Fri, 04 Sep 2026 12:13:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Sni-0001V7-MV; Fri, 04 Sep 2026 12:13:46 +0000 Received: by outflank-mailman (input) for mailman id 1408403; Fri, 04 Sep 2026 12:13:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Snh-0001Ts-5n for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:13:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Sng-00DwB5-IM for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:13:44 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ab5ea-e002-0a2a0a5209dd-0a2a450390b4-28 for ; Fri, 04 Sep 2026 14:13:44 +0200 Received: from [52.101.84.49] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ab5f8-fae8-0a2a45030019-34655431eb49-3 for ; Fri, 04 Sep 2026 14:13:44 +0200 Received: from DB9PR06CA0006.eurprd06.prod.outlook.com (2603:10a6:10:1db::11) by PA1PR08MB11671.eurprd08.prod.outlook.com (2603:10a6:102:556::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 12:13:38 +0000 Received: from DU2PEPF00028D11.eurprd03.prod.outlook.com (2603:10a6:10:1db:cafe::67) by DB9PR06CA0006.outlook.office365.com (2603:10a6:10:1db::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Fri, 4 Sep 2026 12:13:38 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU2PEPF00028D11.mail.protection.outlook.com (10.167.242.25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.3 via Frontend Transport; Fri, 4 Sep 2026 12:13:38 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by AS8PR08MB9887.eurprd08.prod.outlook.com (2603:10a6:20b:5c0::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 12:13:04 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 12:13:04 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=Of5uoNHA4ZTIaWMREks/1XKVWKnVcJ2/QFxcVwFADN6/Wo6LBFD3VDEOksLTqhayixM/mu+bhqO2TMJ4niHKoYX6g8b/fLtU3P0hIxMfJtAPCjWzRhf6IG1YMS2sXgayVOQtsAhs/JHsOQNx9MetV1hczwbhDZImtn+sRmRwYLsICFZuSIz7+GZVtxz6OHrnlmzwIUcqunI9DECZeHDFDZfPnfqpctbJz57pSsh1+mG9yPxHV7r038/frQj2p2vWeG3E7jzO6AFCLhRUvb/e8M3LqJqggiIe0GBSExmZ/uUgYZOipcXjYOwYKe7XkE4g3Qgoy15xGl/l3orjNcuP5g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LJfAhDgLLfDizIY7/DfdMx74cpgQEW3B+/+1OlgZR+M=; b=F0PuiJcvl6kcvfFPSUlvKQ9RqCzZOTV8yFEqfdqRWnVmG6cK5aA3i2w2SNy8cuyLoxckVcLq9o1Q0gSag1LPncjfWxJ8N508jRy3Xd96i8PrWrxnhxb5K8bs3V1HQEM8B4EZLYQwci6/5rTCzcvm5UjK2H8eNoFYMvNQGb8Sx4uDNK5FYrYw07SEhity8x42sZzuuH4lleU4VoyCM7NV9RmO4hi+u7/z+5BQ7Awz5Gp1LR97YeUWsBibE5/1TQOKx2Stvf8PwYcU6igdgSXZGmQa2mEyxWyNyOSfbcBlXTQF0OWKyA7Ev5X/PwIOQM+/DgdEBwZIC8kf0dG+kfauAw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LJfAhDgLLfDizIY7/DfdMx74cpgQEW3B+/+1OlgZR+M=; b=aY8tDzRqyLfyotdxyRjIL56r0xgZrhU5DvNVJ9jjN3eM5tDs0eu5pU+YOgmxBxbHzLkapUTfSOrQqugTPJ0bywVs+9rMwvtPep0pdhhJJTe30ph8tr6kua9RTw6PRIehEIzwZnej23tYbbssCQpgXzOaBax4Ji77jaP7qmcXqbY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Hn10f3efGTpQWgfim2uNXFgqhokPbGbeoSwjf8jAHLdY28cMgsoZgW9cPxDun8WzAoxYncCjBafxxAD19JBFsKyvQjyDv58sbMhiyoEjTr97TwdfcQ6vvR2VCzG/8LhAgFcq4W9J1PHkIscdpFzSdPUOAavtRNqPjGKKxo7FHWztgG1kCDo8sZCk8KI9ycQFIeg8BK+UlOQOZ/0LuLpRKdOVwahKDX+svL3GU9tdKuxV1CYsBq+u7TYinMddMTEfvM1J1Ge82V+7nx1n2JleZ9ARvbIBMKaErHa2jRT3luKT4keKZfVMgczWlBiqVQLekH4Zy8kMSr91X70SRX+T2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LJfAhDgLLfDizIY7/DfdMx74cpgQEW3B+/+1OlgZR+M=; b=pVSDIGUUrbka0UHG2ugCPhMI2jeyaHIG3+CnaTeDpurEOdhCPM1bRhU8kZ4h5lF18esOroibcKx1fX9TeWgyPQEL2sXd8Lf1I7qvyTMN2uGb+x3S/DPOqp0lHqCIDZQzLLj13FVInIk2QYpNuaRZZFc15znJbX0j5oL1N1MCSLua51zoWFOxJbmOmW0xMQnT/YoE2EOrN2qaRqxObLzoNbS4V3944jLucUnehF62psAVk6kKu/edr4gus7whnIzwa57TINQRCDnIp9lYmOUK4/d6DPSWUNJSPYSkfpl543sAYwh33vgZ+MCKdDrfYMNHeTar00KiqDNyyOtdXWETYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LJfAhDgLLfDizIY7/DfdMx74cpgQEW3B+/+1OlgZR+M=; b=aY8tDzRqyLfyotdxyRjIL56r0xgZrhU5DvNVJ9jjN3eM5tDs0eu5pU+YOgmxBxbHzLkapUTfSOrQqugTPJ0bywVs+9rMwvtPep0pdhhJJTe30ph8tr6kua9RTw6PRIehEIzwZnej23tYbbssCQpgXzOaBax4Ji77jaP7qmcXqbY= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH v2 5/5] xen/arm: Rewrite arm_smccc_*() to return by value Thread-Topic: [PATCH v2 5/5] xen/arm: Rewrite arm_smccc_*() to return by value Thread-Index: AQHdPF5PySaNy6Ey5EKldcmUqkyt+ba+VLAA Date: Fri, 4 Sep 2026 12:13:04 +0000 Message-ID: <9301544B-8F8D-4E27-9BFA-B7244633B41F@arm.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> <20260904111228.3022634-6-andrew.cooper3@citrix.com> In-Reply-To: <20260904111228.3022634-6-andrew.cooper3@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|AS8PR08MB9887:EE_|DU2PEPF00028D11:EE_|PA1PR08MB11671:EE_ X-MS-Office365-Filtering-Correlation-Id: 205aac83-793d-4296-333a-08df0a7df39e x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|6133799003|3023799007|4143699003|18002099003|22082099003|56012099006|11063799006|38070700021; X-Microsoft-Antispam-Message-Info-Original: WQzUhLCfLutEwi6zTNt/4FFGJcR/rUoNByrZ/9WZTyPJHo0NZRoVjU7oAzAeOYE3hW0ip7GC3aU7dMjglAw39gof4BhEvGzw+wowUEMzh/p8AiLV/DLF9MGqgzz76y1wxoFytbeAs7Ry4o6hlFLZicvoXuYY5a/YDb9CSpvGj++/kXzCCRzCVmfD9ZxAfpQsiHRATux6SOGR3xufiKfT2vUhSJu1XJ2WAE5mLCRSpJgqIU8o2k8mb+JoCgNwGVln50jyLfkNX0NpUFFLaTLxncgz9T2H0wRLkPBhXxvY6IrpSkxMJbIgXBB3GHhux9PjPyT0XUdm+7g74R9tPh2TdcMyAsDVqsZf4DVgp0BpvQEwX9FliRG0KD8tp2MMR3lbpR0uKv25Px9nc1VAsmiVgu4pAItS48QB1Eo2T0krbIjspzQdvZUBEmmfgno8G7s2BgHpjzn1fIjp/iLl3V8ez+dNSO+k6XUgRfJyecRRe0CJdIUi70uRJ9shfMNGJ2QlfzGz0MwrqoNbuwA5H0MPSrTSCWHRK4AfK4KmfPxKkiuuttBjatKpEjWoNrY5/0VRmYYO+xpGChGsu87INGQzYCyI7/lZEwacz6MTi6xVLyOfSP/6/THiVnnq0odp1GKhvFfgE0vbTbgyvStt4XpqYujW9M49EUkjnn0pNOXrlSa7M0urdQHTf2YYhnsTiH3MNTg2DPg50Bg3R6MNOIIOwHSxozOR2g65KX/7b5DkHjM= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(6133799003)(3023799007)(4143699003)(18002099003)(22082099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <27F9824EECC06A4EB14DDE182F34F31F@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: S6F3kA/T2G0PbQaqMAOpPRaGkQtLMEglZL5NO0UQjyklvn3wC58AbXGwAdf+0bp7znVlLDUbxx2cHVenVHUitaHlgSX/I3o5HoK8OHcIx+5CrDVDT55BWDXsE/2jUnke55sE0NEBHhk6OY7TO/o44RsH6Veg8Ce+HoJeYAQr62zrjlG6Ty+qXmPYrZv17UIe/Vw4nXegFCYT3uofmmh+1DMfebbNVAAP3Av6Z0O1YQmJkAXAMPTNkhZcSKETWo1gJBMGxpCfzW0Hj4MYiAyhXTl6rZVkhSgcShFKZUzfAnyZt3QIoSusLMRvqWjF4xkoHN79221pLPXOkHm+UHX8Ow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9887 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF00028D11.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: e7f9bbc0-bd7f-447e-ed3a-08df0a7ddf62 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|14060799003|36860700016|1800799024|23010399003|35042699022|376014|18002099003|22082099003|3023799007|56012099006|6133799003|4143699003|10067099003|11063799006; X-Microsoft-Antispam-Message-Info: W4UcGOV5Q3Eumsu6B3DrpaUON+Wr8CBXGpqG5giKlhHE8atx9lQ6Ywr6r0wium5hDSpdl8erOs+xaxBiM0QHsEkB1Lo2noRuipxheVD/hCvBx5ycuszYCxI0sLKSyIaHhv86snZNLTLMqIr7sjVMF0pjVdweZgRZSy45mkRsSb4f/x83CLG1Q1nZDplE0D97knVNrKt7NEWq0DlqHuiM0wZdGjr9ENoLZWWCb4Fs+T9q5BDIT3+IX/EMCI3LRfRwaOb+4BsWJ0jB3J4kq9gD67io3gZ2Xdb77Gsfna6D3212BPf+XLQIHQ45n8GZG/m3jYTGrtBRWqAHnKexnFmUS1R+zj9KoxiUq+lD4aLmglgY+haHmhNwMvygJWQFPn9BvBorFnprKNnp/L/kUHwCPVgOmAGO+SkM6KmkE7Y5Vn/ftD39q7F8D1fuSR2fk6JiGduZceu/0BFBACNdXYAjF9HoVF6/YTRLkSpLKm/UxONx9okFb2q3bQH84zPlD/NgQ60lZsOsG4BCzzbJt52w5YCsVec6LmPs4ROjzlmpAObFN8V+BzT/KE9hy4B9n0BAwUs6xjjiWiL9/r07L/wCwToFB2NI/H9zMTfvChLfJvpqon4duDyi/gxS5wjS9k2cVP1trSW8GHHBQCc3x5nSJQzLauHrZM7UQmHZoZwttHs= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(14060799003)(36860700016)(1800799024)(23010399003)(35042699022)(376014)(18002099003)(22082099003)(3023799007)(56012099006)(6133799003)(4143699003)(10067099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: QkelyHSRGha6UhFPxQpfTfHgYkyAghGSjGEO8BcadYdF0RijWq4o4mCyLijSmY0NvXMYY16tOEC5e3weB5T3yZ/TAyB/3Q6EdndnepZ7Mu2D73jD4AT5GrwnPoAdVMiXMzHkH50Mv1x67sT/ibV9LS8JMaHXQZTmk6kYpM7928cGHVBVSMpykYLhyeRvQGrXKkQBjkThCYjwsA80Z5LYTq2ggeglqcv4fR+TxzMDiF3HVvXIyIZcUO/VBKnqRlr8vrplGnzkA0Pfrm2sz7kTIdHvZNx6Ft0AbbfMoJ+oGEjOLoYugjMpYPrfeKr6eFjb3OdfOrkeZEgtxMC1GHBJXYOVf0qtmn5W7nBWR4nOaucR+XQEem9RWiaaQmGhBLsOl4SyGF2iN9sltzRKH3pHwid9yLJ7xn/OXyCQUu/V4XJxbPsvg1eDBciWSaE+KyxA X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 12:13:38.3214 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 205aac83-793d-4296-333a-08df0a7df39e X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF00028D11.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR08MB11671 X-purgate-ID: tlsNG-33051d/1788524024-6E2D04E9-F04B5D3E/0/0 X-purgate-type: clean X-purgate-size: 25633 Hi Andrew, > On 4 Sep 2026, at 13:12, Andrew Cooper wrote: >=20 > Use statement expressions to return struct arm_smccc_res which makes the = code > read a lot more normally, and avoids needing to pass in NULL in order to = skip > return information. >=20 > More importantly, it removes the local implementation of __count_args() w= hich > is off by two and deeply confusing to try and follow. >=20 > No functional change. >=20 > Signed-off-by: Andrew Cooper > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Setje-Eilers >=20 > v2: > * Transform extra call in optee_probe() >=20 > Xen compiles identically before and after this change, for both arm32 and= arm64. > --- > xen/arch/arm/cpuerrata.c | 18 +++---- > xen/arch/arm/include/asm/smccc.h | 87 ++++++++++++++------------------ > xen/arch/arm/platforms/exynos5.c | 2 +- > xen/arch/arm/platforms/seattle.c | 4 +- > xen/arch/arm/psci.c | 17 +++---- > xen/arch/arm/tee/optee.c | 50 +++++++++--------- > xen/arch/arm/traps.c | 4 +- > 7 files changed, 86 insertions(+), 96 deletions(-) >=20 > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c > index 3a32183618dc..35ad98d29d14 100644 > --- a/xen/arch/arm/cpuerrata.c > +++ b/xen/arch/arm/cpuerrata.c > @@ -179,8 +179,8 @@ static int enable_smccc_arch_workaround_1(void *data) > if ( smccc_ver < SMCCC_VERSION(1, 1) ) > goto warn; >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > - ARM_SMCCC_ARCH_WORKAROUND_1_FID, &res); > + res =3D arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > + ARM_SMCCC_ARCH_WORKAROUND_1_FID); > /* The return value is in the lower 32-bits. */ > if ( (int)res.a0 < 0 ) > goto warn; > @@ -256,8 +256,8 @@ static int enable_spectre_bhb_workaround(void *data) > if ( smccc_ver < SMCCC_VERSION(1, 1) ) > goto warn; >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > - ARM_SMCCC_ARCH_WORKAROUND_3_FID, &res); > + res =3D arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > + ARM_SMCCC_ARCH_WORKAROUND_3_FID); > /* The return value is in the lower 32-bits. */ > if ( (int)res.a0 < 0 ) > { > @@ -398,8 +398,8 @@ static bool has_ssbd_mitigation(const struct arm_cpu_= capabilities *entry) > if ( smccc_ver < SMCCC_VERSION(1, 1) ) > return false; >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > - ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res); > + res =3D arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID, > + ARM_SMCCC_ARCH_WORKAROUND_2_FID); >=20 > switch ( (int)res.a0 ) > { > @@ -429,7 +429,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_= capabilities *entry) > case ARM_SSBD_FORCE_DISABLE: > printk_once("%s disabled from command-line\n", entry->desc); >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0); > required =3D false; > break; >=20 > @@ -437,7 +437,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_= capabilities *entry) > if ( required ) > { > this_cpu(ssbd_callback_required) =3D 1; > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); > } >=20 > break; > @@ -445,7 +445,7 @@ static bool has_ssbd_mitigation(const struct arm_cpu_= capabilities *entry) > case ARM_SSBD_FORCE_ENABLE: > printk_once("%s forced from command-line\n", entry->desc); >=20 > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); > required =3D true; > break; >=20 > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/= smccc.h > index 4ed2a40ed0ac..2d0f2db0b256 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -95,20 +95,14 @@ struct arm_smccc_res { > unsigned long a3; > }; >=20 > -/* SMCCC v1.1 implementation madness follows */ > -#define ___count_args(_0, _1, _2, _3, _4, _5, _6, _7, _8, x, ...) x > - > -#define __count_args(...) \ > - ___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0) > - > -#define __constraint_read_0 "r" (arg0) > -#define __constraint_read_1 __constraint_read_0, "r" (arg1) > -#define __constraint_read_2 __constraint_read_1, "r" (arg2) > -#define __constraint_read_3 __constraint_read_2, "r" (arg3) > -#define __constraint_read_4 __constraint_read_3, "r" (arg4) > -#define __constraint_read_5 __constraint_read_4, "r" (arg5) > -#define __constraint_read_6 __constraint_read_5, "r" (arg6) > -#define __constraint_read_7 __constraint_read_6, "r" (arg7) > +#define __constraint_read_1 "r" (arg0) > +#define __constraint_read_2 __constraint_read_1, "r" (arg1) > +#define __constraint_read_3 __constraint_read_2, "r" (arg2) > +#define __constraint_read_4 __constraint_read_3, "r" (arg3) > +#define __constraint_read_5 __constraint_read_4, "r" (arg4) > +#define __constraint_read_6 __constraint_read_5, "r" (arg5) > +#define __constraint_read_7 __constraint_read_6, "r" (arg6) > +#define __constraint_read_8 __constraint_read_7, "r" (arg7) >=20 > /* > * Macro arguments MUST be evaluated before being assigned to a register > @@ -117,44 +111,43 @@ struct arm_smccc_res { > * This is manual register scheduling for the asm() statement, and any ot= her > * logic to evaluate may clobber the already-scheduled registers. > */ > -#define __declare_arg_0(a0, res) \ > +#define __declare_arg_1(a0) \ > auto __a0 =3D (uint32_t)(a0); \ > - struct arm_smccc_res *___res =3D (res); \ > register unsigned long arg0 ASM_REG(0) =3D __a0 >=20 > -#define __declare_arg_1(a0, a1, res) \ > +#define __declare_arg_2(a0, a1) \ > auto __a1 =3D (a1); \ > - __declare_arg_0(a0, res); \ > + __declare_arg_1(a0); \ > register auto arg1 ASM_REG(1) =3D __a1 >=20 > -#define __declare_arg_2(a0, a1, a2, res) \ > +#define __declare_arg_3(a0, a1, a2) \ > auto __a2 =3D (a2); \ > - __declare_arg_1(a0, a1, res); \ > + __declare_arg_2(a0, a1); \ > register auto arg2 ASM_REG(2) =3D __a2 >=20 > -#define __declare_arg_3(a0, a1, a2, a3, res) \ > +#define __declare_arg_4(a0, a1, a2, a3) \ > auto __a3 =3D (a3); \ > - __declare_arg_2(a0, a1, a2, res); \ > + __declare_arg_3(a0, a1, a2); \ > register auto arg3 ASM_REG(3) =3D __a3 >=20 > -#define __declare_arg_4(a0, a1, a2, a3, a4, res) \ > +#define __declare_arg_5(a0, a1, a2, a3, a4) \ > auto __a4 =3D (a4); \ > - __declare_arg_3(a0, a1, a2, a3, res); \ > + __declare_arg_4(a0, a1, a2, a3); \ > register auto arg4 ASM_REG(4) =3D __a4 >=20 > -#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ > +#define __declare_arg_6(a0, a1, a2, a3, a4, a5) \ > auto __a5 =3D (a5); \ > - __declare_arg_4(a0, a1, a2, a3, a4, res); \ > + __declare_arg_5(a0, a1, a2, a3, a4); \ > register auto arg5 ASM_REG(5) =3D __a5 >=20 > -#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ > - auto __a6 =3D (a6); \ > - __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ > +#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6) \ > + auto __a6 =3D (a6); \ > + __declare_arg_6(a0, a1, a2, a3, a4, a5); \ > register auto arg6 ASM_REG(6) =3D __a6 >=20 > -#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ > - auto __a7 =3D (a7); \ > - __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ > +#define __declare_arg_8(a0, a1, a2, a3, a4, a5, a6, a7) \ > + auto __a7 =3D (a7); \ > + __declare_arg_7(a0, a1, a2, a3, a4, a5, a6); \ > register auto arg7 ASM_REG(7) =3D __a7 >=20 > #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) > @@ -181,21 +174,20 @@ struct arm_smccc_res { > * makes it stick. > */ > #define arm_smccc_1_1_smc(...) \ The comment would need fixing on top of this as current one still describes the optional @res argument while now=20 we only take a0 to a7 as arguments and return the structure=20 instead. Cheers Bertrand > - do { \ > + ({ \ > register unsigned long r0 ASM_REG(0); \ > register unsigned long r1 ASM_REG(1); \ > register unsigned long r2 ASM_REG(2); \ > register unsigned long r3 ASM_REG(3); \ > - __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > + __declare_args(count_args(__VA_ARGS__), __VA_ARGS__); \ > asm volatile ( \ > "smc #0" \ > : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3) \ > : PASTE(__constraint_read_, \ > - __count_args(__VA_ARGS__)) \ > + count_args(__VA_ARGS__)) \ > : "memory" ); \ > - if ( ___res ) \ > - *___res =3D (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > - } while ( 0 ) > + (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > + }) >=20 > /* > * The calling convention for arm32 is the same for both SMCCC v1.0 and > @@ -208,8 +200,8 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > { > struct arm_smccc_res res; >=20 > - arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3, > - regs->r4, regs->r5, regs->r6, regs->r7, &res); > + res =3D arm_smccc_1_1_smc(regs->r0, regs->r1, regs->r2, regs->r3, > + regs->r4, regs->r5, regs->r6, regs->r7); >=20 > regs->r0 =3D res.a0; > regs->r1 =3D res.a1; > @@ -226,7 +218,7 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > * are strictly preserved. Always mark x4 through x17 as clobbered. > */ > #define arm_smccc_smc(...) \ > - do { \ > + ({ \ > register unsigned long r0 ASM_REG(0); \ > register unsigned long r1 ASM_REG(1); \ > register unsigned long r2 ASM_REG(2); \ > @@ -246,7 +238,7 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > register unsigned long c15 ASM_REG(15); \ > register unsigned long c16 ASM_REG(16); \ > register unsigned long c17 ASM_REG(17); \ > - __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > + __declare_args(count_args(__VA_ARGS__), __VA_ARGS__); \ > asm volatile ( \ > "smc #0" \ > : "=3Dr" (r0), "=3Dr" (r1), "=3Dr" (r2), "=3Dr" (r3), \ > @@ -255,11 +247,10 @@ static inline void arm_smccc_guest_smc(struct cpu_u= ser_regs *regs) > "=3Dr" (c12), "=3Dr" (c13), "=3Dr" (c14), "=3Dr" (c15), \ > "=3Dr" (c16), "=3Dr" (c17) \ > : PASTE(__constraint_read_, \ > - __count_args(__VA_ARGS__)) \ > + count_args(__VA_ARGS__)) \ > : "memory" ); \ > - if ( ___res ) \ > - *___res =3D (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > - } while ( 0 ) > + (struct arm_smccc_res){ r0, r1, r2, r3 }; \ > + }) >=20 > #define arm_smccc_1_1_smc(...) arm_smccc_smc(__VA_ARGS__) >=20 > @@ -268,8 +259,8 @@ static inline void arm_smccc_guest_smc(struct cpu_use= r_regs *regs) > { > struct arm_smccc_res res; >=20 > - arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3, > - regs->x4, regs->x5, regs->x6, regs->x7, &res); > + res =3D arm_smccc_1_1_smc(regs->x0, regs->x1, regs->x2, regs->x3, > + regs->x4, regs->x5, regs->x6, regs->x7); >=20 > regs->x0 =3D res.a0; > regs->x1 =3D res.a1; > diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/ex= ynos5.c > index f7c09520675e..f08d50c1fe38 100644 > --- a/xen/arch/arm/platforms/exynos5.c > +++ b/xen/arch/arm/platforms/exynos5.c > @@ -249,7 +249,7 @@ static int exynos5_cpu_up(int cpu) > iounmap(power); >=20 > if ( secure_firmware ) > - arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu, NULL); > + arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu); >=20 > return cpu_up_send_sgi(cpu); > } > diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/se= attle.c > index 64cc1868c24b..dfa5cf4265c0 100644 > --- a/xen/arch/arm/platforms/seattle.c > +++ b/xen/arch/arm/platforms/seattle.c > @@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initc= onst =3D > */ > static void seattle_system_reset(void) > { > - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL); > + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET); > } >=20 > static void seattle_system_off(void) > { > - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL); > + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF); > } >=20 > PLATFORM_START(seattle, "SEATTLE") > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c > index b6860a776031..634d0d7467cf 100644 > --- a/xen/arch/arm/psci.c > +++ b/xen/arch/arm/psci.c > @@ -41,8 +41,8 @@ int call_psci_cpu_on(int cpu) > { > struct arm_smccc_res res; >=20 > - arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), __pa(init_second= ary), > - &res); > + res =3D arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), > + __pa(init_secondary)); >=20 > return PSCI_RET(res); > } > @@ -54,7 +54,7 @@ void call_psci_cpu_off(void) > struct arm_smccc_res res; >=20 > /* If successfull the PSCI cpu_off call doesn't return */ > - arm_smccc_smc(PSCI_0_2_FN32_CPU_OFF, &res); > + res =3D arm_smccc_smc(PSCI_0_2_FN32_CPU_OFF); > panic("PSCI cpu off failed for CPU%d err=3D%d\n", smp_processor_i= d(), > PSCI_RET(res)); > } > @@ -63,13 +63,13 @@ void call_psci_cpu_off(void) > void call_psci_system_off(void) > { > if ( psci_ver > PSCI_VERSION(0, 1) ) > - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL); > + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF); > } >=20 > void call_psci_system_reset(void) > { > if ( psci_ver > PSCI_VERSION(0, 1) ) > - arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL); > + arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET); > } >=20 > static int __init psci_features(uint32_t psci_func_id) > @@ -79,7 +79,7 @@ static int __init psci_features(uint32_t psci_func_id) > if ( psci_ver < PSCI_VERSION(1, 0) ) > return PSCI_NOT_SUPPORTED; >=20 > - arm_smccc_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, &res); > + res =3D arm_smccc_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id); >=20 > return PSCI_RET(res); > } > @@ -116,9 +116,8 @@ static void __init psci_init_smccc(void) >=20 > if ( psci_features(ARM_SMCCC_VERSION_FID) !=3D PSCI_NOT_SUPPORTED ) > { > - struct arm_smccc_res res; > + struct arm_smccc_res res =3D arm_smccc_smc(ARM_SMCCC_VERSION_FID= ); >=20 > - arm_smccc_smc(ARM_SMCCC_VERSION_FID, &res); > if ( PSCI_RET(res) !=3D ARM_SMCCC_NOT_SUPPORTED ) > smccc_ver =3D PSCI_RET(res); > } > @@ -191,7 +190,7 @@ static int __init psci_init_0_2(void) > } > } >=20 > - arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION, &res); > + res =3D arm_smccc_smc(PSCI_0_2_FN32_PSCI_VERSION); > psci_ver =3D PSCI_RET(res); >=20 > /* For the moment, we only support PSCI 0.2 and PSCI 1.x */ > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > index 3d2633237074..5e94daee0686 100644 > --- a/xen/arch/arm/tee/optee.c > +++ b/xen/arch/arm/tee/optee.c > @@ -178,7 +178,7 @@ static bool optee_probe(void) > return false; >=20 > /* Check UID */ > - arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), &resp); > + resp =3D arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END)); >=20 > if ( (uint32_t)resp.a0 !=3D OPTEE_MSG_UID_0 || > (uint32_t)resp.a1 !=3D OPTEE_MSG_UID_1 || > @@ -187,7 +187,7 @@ static bool optee_probe(void) > return false; >=20 > /* Read number of threads */ > - arm_smccc_smc(OPTEE_SMC_GET_THREAD_COUNT, &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_GET_THREAD_COUNT); > if ( resp.a0 =3D=3D OPTEE_SMC_RETURN_OK ) > { > max_optee_threads =3D resp.a1; > @@ -209,7 +209,7 @@ static bool optee_probe(void) > * call. It will return OPTEE_SMC_RETURN_UNKNOWN_FUNCTION if > * OP-TEE have no virtualization support enabled. > */ > - arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, 0, 0, 0, 0, 0, 0, 0, &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, 0, 0, 0, 0, 0, 0, 0); > if ( resp.a0 =3D=3D OPTEE_SMC_RETURN_UNKNOWN_FUNCTION ) > return false; >=20 > @@ -243,8 +243,8 @@ static int optee_domain_init(struct domain *d) > * > * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_sm= c() > */ > - arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, = 0, 0, > - &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), > + 0, 0, 0, 0, 0, 0); > if ( resp.a0 !=3D OPTEE_SMC_RETURN_OK ) > { > printk(XENLOG_WARNING "%pd: Unable to create OPTEE client: rc =3D= 0x%X\n", > @@ -681,8 +681,8 @@ static int optee_relinquish_resources(struct domain *= d) > * > * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_sm= c() > */ > - arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0= , 0, 0, > - &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), > + 0, 0, 0, 0, 0, 0); >=20 > ASSERT(!spin_is_locked(&ctx->lock)); > ASSERT(!atomic_read(&ctx->call_count)); > @@ -1171,15 +1171,15 @@ static void do_call_with_arg(struct optee_domain = *ctx, > { > struct arm_smccc_res res; >=20 > - arm_smccc_smc(a0, a1, a2, a3, a4, a5, 0, OPTEE_CLIENT_ID(current->do= main), > - &res); > + res =3D arm_smccc_smc(a0, a1, a2, a3, a4, a5, 0, > + OPTEE_CLIENT_ID(current->domain)); >=20 > if ( OPTEE_SMC_RETURN_IS_RPC(res.a0) ) > { > while ( handle_rpc_return(ctx, &res, regs, call) =3D=3D -ERESTAR= T ) > { > - arm_smccc_smc(res.a0, res.a1, res.a2, res.a3, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &res); > + res =3D arm_smccc_smc(res.a0, res.a1, res.a2, res.a3, 0, 0, = 0, > + OPTEE_CLIENT_ID(current->domain)); >=20 > if ( !OPTEE_SMC_RETURN_IS_RPC(res.a0) ) > break; > @@ -1619,8 +1619,8 @@ static void handle_exchange_capabilities(struct cpu= _user_regs *regs) > caps =3D get_user_reg(regs, 1); > caps &=3D OPTEE_KNOWN_NSEC_CAPS; >=20 > - arm_smccc_smc(OPTEE_SMC_EXCHANGE_CAPABILITIES, caps, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_EXCHANGE_CAPABILITIES, caps, 0, 0, = 0, 0, 0, > + OPTEE_CLIENT_ID(current->domain)); > if ( resp.a0 !=3D OPTEE_SMC_RETURN_OK ) { > set_user_reg(regs, 0, resp.a0); > return; > @@ -1664,8 +1664,8 @@ static bool optee_handle_call(struct cpu_user_regs = *regs) > return true; >=20 > case OPTEE_SMC_CALLS_UID: > - arm_smccc_smc(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > set_user_reg(regs, 1, resp.a1); > set_user_reg(regs, 2, resp.a2); > @@ -1673,15 +1673,15 @@ static bool optee_handle_call(struct cpu_user_reg= s *regs) > return true; >=20 > case OPTEE_SMC_CALLS_REVISION: > - arm_smccc_smc(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, = 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > set_user_reg(regs, 1, resp.a1); > return true; >=20 > case OPTEE_SMC_CALL_GET_OS_UUID: > - arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_UUID, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain),&resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_UUID, 0, 0, 0, 0, 0= , 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > set_user_reg(regs, 1, resp.a1); > set_user_reg(regs, 2, resp.a2); > @@ -1689,21 +1689,21 @@ static bool optee_handle_call(struct cpu_user_reg= s *regs) > return true; >=20 > case OPTEE_SMC_CALL_GET_OS_REVISION: > - arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_REVISION, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_CALL_GET_OS_REVISION, 0, 0, 0, = 0, 0, 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > set_user_reg(regs, 1, resp.a1); > return true; >=20 > case OPTEE_SMC_ENABLE_SHM_CACHE: > - arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0= , 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > return true; >=20 > case OPTEE_SMC_DISABLE_SHM_CACHE: > - arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0, > - OPTEE_CLIENT_ID(current->domain), &resp); > + resp =3D arm_smccc_smc(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, = 0, 0, > + OPTEE_CLIENT_ID(current->domain)); > set_user_reg(regs, 0, resp.a0); > if ( resp.a0 =3D=3D OPTEE_SMC_RETURN_OK ) { > free_shm_rpc(ctx, regpair_to_uint64(resp.a1, resp.a2)); > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c > index 625d229396bb..6a5dcef2aa87 100644 > --- a/xen/arch/arm/traps.c > +++ b/xen/arch/arm/traps.c > @@ -1991,7 +1991,7 @@ void asmlinkage enter_hypervisor_from_guest_preirq(= void) >=20 > /* If the guest has disabled the workaround, bring it back on. */ > if ( needs_ssbd_flip(v) ) > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1); > } >=20 > /* > @@ -2334,7 +2334,7 @@ void asmlinkage leave_hypervisor_to_guest(void) > * If the guest wants it disabled, so be it... > */ > if ( needs_ssbd_flip(current) ) > - arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL); > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0); > } >=20 > /* > --=20 > 2.39.5 >=20 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 12:23:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 12:23:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408428.1641019 (Exim 4.92) (envelope-from ) id 1x2SxJ-0004V3-QB; Fri, 04 Sep 2026 12:23:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408428.1641019; Fri, 04 Sep 2026 12:23:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2SxJ-0004Uw-NY; Fri, 04 Sep 2026 12:23:41 +0000 Received: by outflank-mailman (input) for mailman id 1408428; Fri, 04 Sep 2026 12:23:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2SxI-0004Uk-E8 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:23:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2SxH-005oUu-Qv for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:23:39 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ab847-bab6-0a2a0a5309dd-0a2a4502a944-10 for ; Fri, 04 Sep 2026 14:23:39 +0200 Received: from [52.101.57.4] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ab84a-6ca4-0a2a45020019-34653904b760-3 for ; Fri, 04 Sep 2026 14:23:39 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CH0PR03MB6132.namprd03.prod.outlook.com (2603:10b6:610:bb::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 12:23:36 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 12:23:36 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eAEyNIF36GAao7yiNM5UBaR9BNUlcS0+YrlkWpaE+2caj9pB10pG+1rxNKacvpCY7wy9pwsfkFLhk1BqLqD6ycdsfrWsMz9WS+qVjjd+k5dhxF7Hn6WUvt9sB9ohr+Ihx1UNwR5sMexc/jmoMpX2mOmV3jDd4+aiJ08LUs1cfN6XdbVEKAS+uaDnEFAWietCwLgB9Vq+TH4KZKK9nr3DNEW7/n8cFyOmS5h+kclNw6fWAYWyu1FCdrgqFowji1za1XjcyeX7jDbZTBaKidu/IqSe9gffFLQVbHnnNwlbl2NNIpCca56dVO4V9Drk74C502bofrzsS/Ju/Zi2+M6uFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4y200znicxFhtMBf6+UXpmow9OhWujlHMUqpd7k5kz0=; b=D1oX7EYwjGOlUEeMNnX2yu8MpwkYkznWdRvwjjlJ2C4cbb9uWK52O/gOBw5q+pCREie9d7LqVml6ImfKxbFrCCNcb+bTQFptL1spSD0dFB3Rgc+b/H9BxBVaPLk2lTqTTuikuyALI1lHAV1gP8KmH9r2d+hXYcSrv1xhxV+84k/lK7zwNt37cfIri30G6kkcEyaXTkv869iLi6TTFRBkq7McGlQbF7BZIfxKR8AmHQjgTOA+rG7c2u46f4VjkVQZnlNImwedhFKCDlCZcfY5nQeeLSJqOmel/Zp06Q38vTzc26HIwS5ENsBykFCWUChAkOQy9X622HImptbsc1L9OQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4y200znicxFhtMBf6+UXpmow9OhWujlHMUqpd7k5kz0=; b=wpGA3YLvjnsPUYBPLArmKTM18McBCBQHymAhIiAErNh9YjVEIoNABb2MeaOjLwgV8sEZeXLJ731Rv2LIdu6sjpnidQ9+8V93Qs3AkxlUTR78TpHYsSLsh5P39kNT/iqDJFDuvtKyPClDmnOKv/TJRo2AMk1t2HRJ8jCd0kLC0fw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v2] x86/svm: Intercept CR0 writes selectively Date: Fri, 4 Sep 2026 13:23:30 +0100 Message-ID: <20260904122330.306936-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0080.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bd::10) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|CH0PR03MB6132:EE_ X-MS-Office365-Filtering-Correlation-Id: b39606a7-1045-46e5-0034-08df0a7f582e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|11063799006|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: vJI5ym4ODozw1dwXlczsu+yoHM9c2B2qLCyL2/sAxLEJbEUV4BPXmZraNocB1lQCzcaGwI7xZ3eoHN5YJeEUbqXfo7EwgC0hnjqFxb6ZFlvDO7b6zD0Ex30nyqFD7FkGCDxpF4biuRaRKSjBkB17X6bq6DoaDqpTMgN+pYJheGSRy/nvNdKFFoJmMwvfeHOV9XZ8ESkUcCZDJxDXgMK9mI9hWVNjyGzIA3GTEegItIdADNPAzV2s85zq0FBENS84PCqiZRLlObNhM7kutoZKiE7pUrAKH8Zai9v5eekoS7YG7QcRS0JjC+S+ZyoKkEgJvSPhNrYWztljpJwDcUNzkGjxfr1WVGtOR5bZRMGfb/IbDwb8oIAlswbOEmQDuNH3K8d/ev1ajM3eqMXLPnwUU98QH8gGo+DdwlpjDxUMG2RXCrIKKDwCxZmlGUUIqBw2eqifpcV1k0oeT3vCnx6arpiS+XSpX8N2b/DBOEEQN6I/lsXhi2f5S26ad/iQAvzraOwVy8KL3HiuHk+EdKqNf7NaMl/gT3+QBIWGuuaKxhruRJ/ark5xUY1R/92DnkRmSh57qdOR3ELuoPQMDOAxpYIFS1WY1PMa1/GxsiTJex1tIraWiQP/d324w6ouOJ+FrFZz4dzt/nMqxxnZ8kICSc5deX/Am15T4UebQ7hKO1Q= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(11063799006)(56012099006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?sV0psjFrkhi21v0VxXa98LE7miQzS1ybiGB43gdnYjDTw1y9krQK2+DCb3+b?= =?us-ascii?Q?JD9WJJFb3+syWxdtL2hpWBqGw2sx5Pr3wzWJMWbryuWQiI9aNNLRRFV7BkRA?= =?us-ascii?Q?lM0xv0g+I64DJtZkw44yogsbaIn8jZoqKu/EpP9hFfsyuKNzIyqqABkWaP9i?= =?us-ascii?Q?x2ux3WqwFvVoor53ZXvPzHsx06nIpM20e+0Z7Ct84teqkQDNxsNjcJV5DWAH?= =?us-ascii?Q?FyR1sGo3XxDz2NHWh6tMEN8aq0YT8zbHgGWeeyrJI7fnDHNILQkMO+GYxzj/?= =?us-ascii?Q?l76v9MvNe1rQjKPle/2wd4Y7PboqNhWSqmErtl2wZvcEfTV+fjBXowluga80?= =?us-ascii?Q?Mx22ss8i49JWOTf3Pn+lJZ8K97jFAbuKLpUJMtn21bFPNFL87JOfp+zcZAgh?= =?us-ascii?Q?9Y9Xbi38fVodo2WGQ2iN+ARQvEYgbWJLjKSFNpiqTeHA9f7MkW1HMemftxBz?= =?us-ascii?Q?FHyCpxOcaMh5tcAu4M2P98gcki57KCPngiHGt+WRcAlp3+sfwoEIlF64UlLu?= =?us-ascii?Q?TYlGaAnURerx9ySd4zy7AL4HtoO1Mk92d5ztuktMZmb3bb9kOV55wHeEeS90?= =?us-ascii?Q?MylNF/KfAlml/y6jyk/Z7puntaNK8tm5nFdLIyY+WHFN/w1EEVNfPQaK1Mi9?= =?us-ascii?Q?KxEg3ZU5jhEIU9zTD4dLYp4jO0BrJRMEMPofTeX0dJgy+2hLOp5a4z2Byn2r?= =?us-ascii?Q?aSm6BjHF6xvV0A1SNKIia0l9t63zNCKVeXMlvrZlAEtOHuXFJiQKJlt5caZ9?= =?us-ascii?Q?ZGBOrOGHhT7eSMi10911tlyVlWIoqXKxGV/UNmgw6OcOtq9yEFtcCCRiBxyc?= =?us-ascii?Q?cbiDBDZ3cX8+fK2hN7m1VZ01FmQA0i5FcDjEqbP2W/i4Iy3mhyPkseOknzKx?= =?us-ascii?Q?ArhNuRDlAZEAkEtj1VlvK4y38+45qLoH/on1z+6/wTq3kD+AlsnysfNirMVv?= =?us-ascii?Q?5Gtqay2BNvdRJXte0IGkYbegykihEhA0ESDlaDOcE0AYUD1CWzEPgXUob40Z?= =?us-ascii?Q?cKZUL/hhow45Y+hs4kit7Voxv+P3otz4cYqwRSjhTxDXMQ8wK1FUbyIpEGMx?= =?us-ascii?Q?0WXt6bX4rH8v31LdEQJM8rgT/Jk9GFGAMM4dTnFoQirA/GPu7BG3KGmbLeRw?= =?us-ascii?Q?MacTrb01GggQl+TE71LV1k4qUSHaonm0P2PhcBWzt5+jW7AjMkSFVad7Zaix?= =?us-ascii?Q?zU+itnBXX7jlwu4xOHi0pDd9+Y95rfnqrvFiM/PCXg5j3ZTvWeWwjxuJPdI3?= =?us-ascii?Q?7p8QMIzzw4JRQC2GXdkOcO9ZkJwrQLtlS7cWSB5ddGsTs39PaiMPTW4ZCDKU?= =?us-ascii?Q?EYoyIh2u5Q1IXcRZxrrfzLicX5uvWIAO2oeW+RlnsQ3CZ+M1Z7ysSrwcyGT9?= =?us-ascii?Q?MSUoCbG4YWdBgLLAdbOFksVdusItHZPhHJ/JP2v2+4RC88indqeBqiA4odRn?= =?us-ascii?Q?wI25TnkkLpYJ3YF8GiJ4p//wiIgGREdFqW3wW6hqm//HW/K2Cq2Ca+UxGz9O?= =?us-ascii?Q?DpqmwwbbMXqHomWSfxRhvThw/6xS8W+oLnZo3qG3i5swZOOCdlESUe6EBNcj?= =?us-ascii?Q?AICbJMMaVnjI8dk3aIJJX8vaexyiyQPztRsi9gI0expprnzQGG15MWsnEY2m?= =?us-ascii?Q?xSs7gu5ekYPIWutT3cbb0tdRbgFBbhpO1QUL6rWLmI4EJZkbsEQi9i1RNiHo?= =?us-ascii?Q?Fj3afqiyBoHmHIsrCPPk69i9iesApkCQRJ1oy+dYp/o1RsyE2KN3MNivO9zp?= =?us-ascii?Q?YnwhmvoXsyquhB4tUPYyrNmvriHx9Z4=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b39606a7-1045-46e5-0034-08df0a7f582e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 12:23:36.7416 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: woaGYtEbb+gcjOEY3p2cEAUPLvM6t8ncqxzTz6HEJHGIYoujHJW3jHk+pNl6vXZCB0qhWVnMbhdFlUI4fO9yaszvkZMaCuKUOG2c0dCQPYA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR03MB6132 X-purgate-ID: tlsNG-720697/1788524619-67CBA2AC-C72A0A28/0/0 X-purgate-type: clean X-purgate-size: 4443 Since 3356d685dbda ("x86/svm: Remove lazy FPU support"), Xen does not need to track when the TS or MP bits change so opt to intercept CR0 writes selectively. Aside from potentially reducing a few VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so L1 never sees any CR0 writes. Since CR0 may now change behind Xen's back, sync it on VMEXIT so that the emulator sees the correct value. Signed-off-by: Ross Lagerwall --- In v2: * Keep case VMEXIT_CR0_WRITE for consistency with other not-intercepted CRx VMEXITs. * Tweak commit message, comments, and formatting. xen/arch/x86/hvm/svm/svm.c | 5 ++++- xen/arch/x86/hvm/svm/vmcb.c | 22 +++++++++++++--------- 2 files changed, 17 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 5f5d903d872d..ddc35e31506e 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1640,7 +1640,8 @@ static void svm_vmexit_do_cr_access( { int gp, cr, dir, rc; - cr = vmcb->exitcode - VMEXIT_CR0_READ; + cr = (vmcb->exitcode == VMEXIT_CR0_SEL_WRITE) + ? 16 : (vmcb->exitcode - VMEXIT_CR0_READ); dir = (cr > 15); cr &= 0xf; gp = vmcb->ei.mov_cr.gpr; @@ -2517,6 +2518,7 @@ void asmlinkage svm_vmexit_handler(void) hvm_sanitize_regs_fields( regs, !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l)); + v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb); v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb); if ( paging_mode_hap(v->domain) ) v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb); @@ -2883,6 +2885,7 @@ void asmlinkage svm_vmexit_handler(void) case VMEXIT_CR0_READ ... VMEXIT_CR15_READ: case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE: + case VMEXIT_CR0_SEL_WRITE: if ( cpu_has_svm_decode && vmcb->ei.mov_cr.mov_insn ) svm_vmexit_do_cr_access(vmcb, regs); else if ( !hvm_emulate_one_insn(x86_insn_is_cr_access, "CR access") ) diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 975a1eaef806..f7e86c68b521 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -50,13 +50,13 @@ static int construct_vmcb(struct vcpu *v) struct vmcb_struct *vmcb = svm->vmcb; vmcb->_general1_intercepts = - GENERAL1_INTERCEPT_INTR | GENERAL1_INTERCEPT_NMI | - GENERAL1_INTERCEPT_SMI | GENERAL1_INTERCEPT_INIT | - GENERAL1_INTERCEPT_CPUID | GENERAL1_INTERCEPT_INVD | - GENERAL1_INTERCEPT_HLT | GENERAL1_INTERCEPT_INVLPG | - GENERAL1_INTERCEPT_INVLPGA | GENERAL1_INTERCEPT_IOIO_PROT | - GENERAL1_INTERCEPT_MSR_PROT | GENERAL1_INTERCEPT_SHUTDOWN_EVT| - GENERAL1_INTERCEPT_TASK_SWITCH; + GENERAL1_INTERCEPT_INTR | GENERAL1_INTERCEPT_NMI | + GENERAL1_INTERCEPT_SMI | GENERAL1_INTERCEPT_INIT | + GENERAL1_INTERCEPT_CR0_SEL_WRITE | GENERAL1_INTERCEPT_CPUID | + GENERAL1_INTERCEPT_INVD | GENERAL1_INTERCEPT_HLT | + GENERAL1_INTERCEPT_INVLPG | GENERAL1_INTERCEPT_INVLPGA | + GENERAL1_INTERCEPT_IOIO_PROT | GENERAL1_INTERCEPT_MSR_PROT | + GENERAL1_INTERCEPT_TASK_SWITCH | GENERAL1_INTERCEPT_SHUTDOWN_EVT; vmcb->_general2_intercepts = GENERAL2_INTERCEPT_VMRUN | GENERAL2_INTERCEPT_VMMCALL | GENERAL2_INTERCEPT_VMLOAD | GENERAL2_INTERCEPT_VMSAVE | @@ -76,8 +76,12 @@ static int construct_vmcb(struct vcpu *v) /* Intercept all debug-register writes. */ vmcb->_dr_intercepts = ~0u; - /* Intercept all control-register accesses except for CR2 and CR8. */ - vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR2_READ | + /* + * Intercept all control-register accesses except for CR0 writes (use + * selective write instead), and CR2 and CR8 reads/writes. + */ + vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR0_WRITE | + CR_INTERCEPT_CR2_READ | CR_INTERCEPT_CR2_WRITE | CR_INTERCEPT_CR8_READ | CR_INTERCEPT_CR8_WRITE); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 12:41:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 12:41:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408469.1641029 (Exim 4.92) (envelope-from ) id 1x2TE1-0001GQ-4Y; Fri, 04 Sep 2026 12:40:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408469.1641029; Fri, 04 Sep 2026 12:40:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2TE1-0001GJ-1j; Fri, 04 Sep 2026 12:40:57 +0000 Received: by outflank-mailman (input) for mailman id 1408469; Fri, 04 Sep 2026 12:40:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2TDz-0001Ft-Ok for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 12:40:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2TDz-00E9iw-56 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:40:55 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9abc56-e002-0a2a0a5209dd-0a2a450cc620-8 for ; Fri, 04 Sep 2026 14:40:55 +0200 Received: from [52.101.85.44] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9abc51-f479-0a2a450c0019-3465552ca32b-3 for ; Fri, 04 Sep 2026 14:40:53 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SJ0PR03MB6616.namprd03.prod.outlook.com (2603:10b6:a03:389::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 12:40:44 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 12:40:42 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L1/sHFfD0dFVDIsc/0+z5kgENWb3b43gM7hldhRgAqrUKeG2j81RW1YPx7y71MWsVwGJe7bqVRPL2CEzuURQ59/cZoQmV5xeyI7znvHm02I7NV98CfO0zGxKtCGvSACRIqK4Llnw6X55TT74Y9CrTPzv1GcnUBuREpIe62tYaUwP1zae5TFrGWdErtRCt11k2SB4UZof7c36pb7C1bQXUDekAMla/8UI4OQmd7PyNOVoIaANFNr9bpvO/qXO/DceUzlmRS1oabHgb0KFCKDx67Vge2SFMkDpVNAV5E8c/HUqaVurcZwoh+YqbmERjszqadjJrIq59R3ExR9dmSqAxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FTyGvNtPrZrovxMyhWZqvh1nAydJSiP93/UkRdaZr4A=; b=Dnk6zXgjyHo5f+UkPJ3jWaW1JAITyd9KpsPcB9sWxWxCfvTI47ZwlWmgFBGQ0kSLScoDeUZgEIviMa0t5y6pAgMhuzYvREJZC+boLlWHpYGDPMhn1L2cd9uMCOzCbJlNRqCHtV0y592nb6/XSX1IjF6OwYQOUUbLJiG7kryPFCRH46b0a2/M0iDPcrNOp8gi91FSB4qLzx/rGibw95iSQhxKGe0YRkU38INy2T6DkCWFaCWxX+Ruz/z6UvJU73nXNyS+571ENFNwS0lDILUfHrTP7FCDOUoW2RKHaXDkhaMA0sAc62tUngnifo9KVU69igxw9D515HHfmYfvoiAWow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FTyGvNtPrZrovxMyhWZqvh1nAydJSiP93/UkRdaZr4A=; b=WXIVl9tNc7Ih2NgrryQysiPFCOrp+jkTi+H25eVPIjpbRxJhd03YXc9As00wvzmLvWJ1m+zzxYv2TT6gFNKwzk4Ueee0f9x3o8MXxfiBRVUcJLAgX+Fk7gizg1K7SRdsgtQ0xMhc5Q8wHS1GEMp6Qt/Di25GAbbKmuFlbF+TCvs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <2d73442b-481d-44d1-b195-41da0efc23b8@citrix.com> Date: Fri, 4 Sep 2026 13:40:38 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/2] x86/viridian: Implement synthetic timer direct mode To: Jan Beulich Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260828131142.3986110-1-ross.lagerwall@citrix.com> <20260828131142.3986110-3-ross.lagerwall@citrix.com> <1279a949-6b18-4943-9d7f-046dec98e681@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <1279a949-6b18-4943-9d7f-046dec98e681@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0227.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:315::13) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SJ0PR03MB6616:EE_ X-MS-Office365-Filtering-Correlation-Id: 3b3b9476-a10e-470b-c675-08df0a81bbbd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|10067099003|56012099006|11063799006|5023799004|4143699003|6133799003|3023799007|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: MuxxDDNxOZ6ak24y334aTHqQh3S88I2u8WoeZX2TneOAPE/b2KtTAnvnJcwzvHM6r3vOGF8uchBCeTHyoZDKS/F3+1y2KtrjtQ0NNAx1WtLoyqFQc4k6ml9a1FfSgTTKdks+UHzYqcPbkngz7xYmLwSSw+vZciBbyy60hRQv69uLmbsmXRSJ0nYRc72zufvXKk365uKcFtTy9JMnEd8KdH1csCTeOQl/BR3Goo0ODfhziEFDK3qW28ZW6t/78qNHQCiVjWkNPSC6g35TUXWbXXXNkd2uZZZisocoZ+ltA9UZBup0CoUht06hkPlrDYp4/Qozg4HyuDLkkamimVS1yp9P0obxYCOIvtSyXKd2HYt9LdjnfB6BpSYfapj269i/mo8aVunAEYy2+Wj6xPRUcCmzp0CM2kStqC242Ahdq40HUFp5ZKyBZesywC1lAtkyFeeeUaRI7pEzJ91Hv2t3VqLIfSV89oQ4fSVlQrS/qQjk2vaPgT0eeyv8Yx6rOjKQbP9u8WStkJuKud8hl503gq1hqtginpRHNd9mq5MSHAFi7eEMnKYboKdb7BuYCsN0h42dA8l67Z+oML3EpgYDj6oqIZFf2qfI7EN1xfi2d5x2x8/psNbgTyJ4BBEf1Qcr4w/gjDejj7G8nTImfjZe64CoPmo0IGYMAsSSD07ZHYY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(10067099003)(56012099006)(11063799006)(5023799004)(4143699003)(6133799003)(3023799007)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NnJadXdXejRKWHVhS2g0aWJoWkIvR3lwVzdxUEVCMGhXODZDdG5ZR0pmMjlo?= =?utf-8?B?TDJYSXJNcDNWZ1QyZFY0OVhUbzJZYVVYQ0dLKzkvL1NNZVdPN2xHYndDOTlo?= =?utf-8?B?dzhmVUg3SmpuYzlEOEZNeE0vTHVQU3BRTVhiWTRnaUgvTUozNFEyamtMVzhw?= =?utf-8?B?TXowZVVURTRVdmIrRnBPV1I2U3dWQzFEbm44ZkkyWnQxYmw3RENUTlkvOE9O?= =?utf-8?B?NkpTTW1MeW43ZWcxK1FGR3g0ZHQxOGU0NWU4d1ErdGxzYi9USnozRjNpVXN2?= =?utf-8?B?QmZ5TndYUkI3NGNLRnhjR0k1d3dOSXJRZkVaamZvMSs2M25vNjVRMDlLY3RJ?= =?utf-8?B?YXFCaGpXOW14Q0V1cmxnWElZcHpCVGp2Tm1YYzlYZkZJTE5uZ3dScklNb25B?= =?utf-8?B?bmtxczFqRjJtOHRDdDlWS0ZuMnJYYnZScUx4MldHWG1Ra0ZTVys5Q2JoQThM?= =?utf-8?B?ckEwRVRZejQ0OUZ2RkQvcG5EK1crRWJjN3BSSDFaK3pQQXdrUDYyeUIxTmZF?= =?utf-8?B?RzNmdkN6aWF5K1NSYjJKSUp4VjEyNmhpM2dCVERjbjdId3l2WGxYUm5iRm5X?= =?utf-8?B?YkFyWmhBbnQ1akhsS0lVRUl6ODJYa2t1d1Z4QnRLc2JoMTJxRVJaMnpwTVNB?= =?utf-8?B?dXNTaXQyMEROSzlVU08xS2pIREx2UXg4Ky84MGdVTHJ6QUVBdlZ2OWpURnBv?= =?utf-8?B?YzRzdXZHNEU5KzlNbE1sbG51VWhVeEJZRlNLQVNGU3lkakVoUVI2STIxU2N3?= =?utf-8?B?MGI3Q0hGUG5HeDBjcEYwVWlnRFN3d3poQ2dKYlREdEcwNDVsOVdnb0JRWENs?= =?utf-8?B?a2ZsUUdCQlQyZHN1TEpMWFZZTjdFbmFROEFNQmgwQ1V2clpnOXNOa2RiOFNI?= =?utf-8?B?Nkp0cmNBK2YwZlBvRFdFMndCSWxnRUFISkNOTllWMWUxcy83UTZ0b2dKSDdy?= =?utf-8?B?dE5Vc2NCSU9odnptV2tLeFVOanJ3RWlISSs5KzBIUFJhMjJHNmtDZ2Q2a2p0?= =?utf-8?B?elJoVlFHT2pxaTI0NGlBelFIeGZUYk5wbUppWjZlc2FFbVBabWZFY1BXaU9h?= =?utf-8?B?clR2b1B3S0lHTHRaWmlva2hzQ21MMDMzTjdPNWVKbUwvTjAvbEU3NDFOdUFx?= =?utf-8?B?NVhJYTZnMjRwNHlONmRweXNyWlBhd3oydEh5MVJsd1FyUTlVeTNCa0l2b0ZK?= =?utf-8?B?cU8yL2REVklPMjNiYVY3QWRyWXhFYy8zMVdVckQvWlZIWHRoOThSaldjMWpt?= =?utf-8?B?QUxHWTB2b3kvTFU4MjhUbkI5RmlOU1Z1bXEwb1F2QWhkS1VCaEEwQ1VBdmZw?= =?utf-8?B?Q3hhUDVDOGZ6ZTV4dFlDMm54MFpFL0xJUk40K25xQ0FhNmczdTlkTDhScUVV?= =?utf-8?B?aXhFNGgyaVpWREU3MThtUDJ0ZThwRndESlROQ0E4ODZ4ckdPQXRGcFZFemFh?= =?utf-8?B?QmpvMERoL3BkeDQwaHFFYmVsd3Z1Z3B0aW9oaGlzVHR6cGFaSWtFRnAzMWh6?= =?utf-8?B?blp5eHlVRHg3SVBoc0Fkc1J3MFVxYVRMV0NrZlk1T0loalhSQzZoeDhwS1JL?= =?utf-8?B?eVFiQ3hoQXFhem9JWU1QOTJQbm95NmlNT1o1Sm5PTk12Rjlpa3F2dkFiU09o?= =?utf-8?B?Z3phMlVqQWJuKzVPOXo0eGw0clFTK3FNNDViME4yR29FRlROOGVEdGZXR05E?= =?utf-8?B?bjJGdkhDUkNoMkQ5bGgvUklBZlBNTEpob3NHck9DZ2hLdGwya1FEY1IrUUV4?= =?utf-8?B?TGpQSExFQmRvOWoxZ3MyMml2SmNHSjFCemN1Uno3WVEyVmtRVmtBb3pocmV4?= =?utf-8?B?ZEZvWlhiUkI0QzNjVmFTZHlwK05wc2Y0NFh4MnBUZEs3RmNnMEQ0NUNKSXhJ?= =?utf-8?B?cUhvQWJFWmIvRXJWQ2x6SlNMSkx2ZndWUkg1N3VwelozNm5ycjRJcGZpd1By?= =?utf-8?B?SlA0Uzg5cVBZeW1OQjR2U2dEZWtINEVvalc3Ry82Zm0wU2pqRFNzQU5ZQktV?= =?utf-8?B?MmxDUlk1ZDlJZmRYaG9pekhLcytyNVBnZTZaZWVIZnVtVDJyTXRnTUc0Z2wx?= =?utf-8?B?N1E0QVpGa2VZUkJpSzhqSFVPcFBLaVRsdnF2NVhncDBrUGdSdGk5dUFWdEY3?= =?utf-8?B?RVd1QzIvZnJ4ZjJJR0lNWHpYcDJjUnNmcnlrQXN4SEw1Y2dzazBLQ3hQQnFr?= =?utf-8?B?VklwaEQxM200djFTNW1JVFBISmxRU3lxN3pKM2N0QlhPNmlPanNMeHFFdVF3?= =?utf-8?B?bUVvZmtPS093NXlwUnQrWEIyMTZiNXZtNkJZOERvNGVtbXl0cEF0cGlWanBX?= =?utf-8?B?emRvMTV4WDZzeUFvK2tLcGpGZmpORHE1SzlSM2dvRlpvaEFjK2ZSKzBLMXpS?= =?utf-8?Q?b0WN8diSBAwkBiXg=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b3b9476-a10e-470b-c675-08df0a81bbbd X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 12:40:42.8211 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TIP3oRtQb2BfqQHj3YKbnDW2d27C5Yb7yx/82CYyKRj9wlgsptX0ryun2879BTLeCL9vbTmMjc1k6vDGjkpBHTfPRlPW1ydjaEB2PslBthc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6616 X-purgate-ID: tlsNG-d25034/1788525653-02EDAA5B-F1A57703/0/0 X-purgate-type: clean X-purgate-size: 3742 On 9/3/26 12:12 PM, Jan Beulich wrote: > On 28.08.2026 15:11, Ross Lagerwall wrote: >> In direct mode, the timer asserts an interrupt on expiration rather than >> using a SynIC message. It is useful to implement this since Windows 11's >> Hyper-V can only use synthetic timers in direct mode. >> >> Signed-off-by: Ross Lagerwall >> --- >> >> Should this use a new Viridian feature bit or is it OK to use the >> existing stimer bit? > > Not sure there. What you need to deal with though are migration related > aspects: > - A migrating-in guest should not suddenly see the CPUID bit set when it was > clear before. > - As so far we don't even reject the .direct_mode bit to be set, it being set > in any of the MSRs of an incoming, unaware guest needs to be taken care of > (the guest must not suddenly get interrupts at the encoded .apic_vector). > Dealing with this may actually be easier with a new feature bit added. OK, I'll add a new feature bit to handle this. > >> --- a/xen/arch/x86/hvm/viridian/time.c >> +++ b/xen/arch/x86/hvm/viridian/time.c >> @@ -223,6 +223,14 @@ static void start_stimer(struct viridian_stimer *vs) >> set_timer(&vs->timer, timeout + NOW()); >> } >> >> +static void stimer_deliver_direct(struct vcpu *v, struct viridian_stimer *vs) > > Second parameter can be pointer-to-const. > >> +{ >> + struct vlapic *vlapic = vcpu_vlapic(v); >> + >> + if ( vlapic_enabled(vlapic) ) >> + vlapic_set_irq(vcpu_vlapic(v), vs->config.apic_vector, 0); > > Before you use the vector, you will want to check its validity (along the lines > of the check that patch 1 aims to avoid in a special case). Whether that needs > doing at the time the MSR is written by the guest or at the call site I don't > know: The (oldish) spec I'm looking at doesn't talk about validation of values > written at all. > > Also please don't re-invoke vcpu_vlapic() when you have already latched its > result in a local variable. > >> @@ -372,7 +382,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) >> >> vs->config.as_uint64 = val; >> >> - if ( !vs->config.sintx || !vs->count ) >> + if ( (!vs->config.direct_mode && !vs->config.sintx) || !vs->count ) >> vs->config.enable = 0; >> >> if ( vs->config.enable ) >> @@ -583,8 +593,11 @@ void viridian_time_load_vcpu_ctxt( >> >> vs->config.as_uint64 = ctxt->stimer_config_msr[i]; >> vs->count = ctxt->stimer_count_msr[i]; >> - if ( !vs->config.sintx || !vs->count ) >> - /* Reject enabling with a zero sintx or count fields. */ >> + if ( (!vs->config.direct_mode && !vs->config.sintx) || !vs->count ) >> + /* >> + * Reject enabling with a zero sintx (if not using direct mode) or >> + * zero count field. >> + */ >> vs->config.enable = 0; >> } >> } > Related to possible validation needs: Is it perhaps also required that .sintx > be clear when .direct_mode is set? > The relevant part from the most recent published version of the spec [1] says: """ It is not permitted to set the SINTx field to zero for an enabled timer (that is not in direct mode). If attempted, the timer will be marked disabled (that is, bit 0 cleared) immediately. """ It doesn't say anything about validating the APIC vector or disallowing other combinations of input. However, it seems sensible to do that so I will, with the same behaviour of disabling the timer on failure. [1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/timers Ross From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:02:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:02:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408544.1641037 (Exim 4.92) (envelope-from ) id 1x2UUj-0007vi-SX; Fri, 04 Sep 2026 14:02:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408544.1641037; Fri, 04 Sep 2026 14:02:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2UUj-0007vb-Pt; Fri, 04 Sep 2026 14:02:17 +0000 Received: by outflank-mailman (input) for mailman id 1408544; Fri, 04 Sep 2026 14:02:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2UUi-0007vV-3A for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:02:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2UUh-001GCJ-G1 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:02:15 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9acf62-bab6-0a2a0a5309dd-0a2a4508d1d6-16 for ; Fri, 04 Sep 2026 16:02:15 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9acf67-f659-0a2a45080019-d155dd2be833-3 for ; Fri, 04 Sep 2026 16:02:15 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-482e4998d28so765105f8f.2 for ; Fri, 04 Sep 2026 07:02:15 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cff8195ffsm11907345e9.14.2026.09.04.07.02.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 07:02:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788530535; x=1789135335; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BvZf0BuB+g+rEOo7VkNwWxDHWLRnLLzXnbrgge1f0og=; b=K/fxFgIb5oDnBfHE4NIdyz/R0G79tta4Czr+fdmjR02V3gzjjMalHw0g2RLTiLJY7Z mHOGdEbEh4nSy3r+4MdW12bnG17ev4/14VwV4VQ8s9ycdqhFZy0hs75wHBvFtIuhAWai ahyxChPWAxO5QmTMwREfVeyJWPizgjYgfQjolNu81YgryIRKeCyC77YVVqulQyFTaeSv bjeLY4y0J3But+mK8N1rwGYaGPAXVanFJjXyn46Dy0M+wlz3UFuo5G29Q5BPP3G+6aYa jDvJJ8XeygQdvfKxuLo2hZBTARwztI7TgAYLLnq2HKR3uFeqSZZRgwwnYPatnEj342n4 XdVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788530535; x=1789135335; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=BvZf0BuB+g+rEOo7VkNwWxDHWLRnLLzXnbrgge1f0og=; b=B+e6tPXEj3bdznzLlUVCBm7C8S+UGSR9zmq+W4oPQ3/WttEghPPy4adMztXYvuFDD0 7vu5XkbEymSfeBT5+SfX93UGOP7Scl+pVmdiZ/X6JFzmLKPF13IXGVysl35QLMl45g76 WxZHlkYCUgqXYvT7r8+8BuYEixfHvTX0P9Yim1r9pFHaq6VHuHM0dP3nnLwlBJ+uqEox MbBeWCRua8bhO83ZZ64ijx+WGAa/hISToYrNI1CISlQpSVhufUu3UgwHNy3jzT4SzAuJ thno20bs+KUjtHPBD0hCCsQVBQk5PnfSTekfKBdfRJ3ntV/A22CBI+boMcVQ6FOViVi1 HlXw== X-Gm-Message-State: AFuF++kpFFID2dMdoJgoosfCWi/SihivAMJJxEHg+w3lkFLG9Y5Zqzfq 2ox8PyhjAe5n80JG5laGXiSA9mJK1YCR5beognQ4eLAnM5TC5Jh2yYcn X-Gm-Gg: AYBFou35zmpV6flncNjpqIjmAQT3s0xCtyNba5GwnxuWjnQRS9jdEH7fAmYhvvEWLGv IM5ZMnv6eGboIb1vTj7t9A3Hfb5jKoP5Kz+TYiQQpTxffFsEkcxKGIVJ8bjc+BkUyImhj7xcOWM qzv5qQYbHWs0kH/h4hsIRP+cDRkEvMP2/uBhg/r/jA//WeTxsNCqEBKc2/BoGp2OScwwT4T+kIi IA7fMKnpFtefeoMkISegTa2IIgbJc7y63c4fYpFjYrigSPW/+Of1xc1OG2f2DnZAgDibY1gFVWE 1QKaAALFdekNom2f/xe/fXacZO2sIbZTkDXiI1c74+UT3+YnIfqZvtS1ri50ndl5deveagi4Ngg 7UQ4yp/ja+33inh8FK96MLrQWJzIK4Po8Iuylu5hzD6/Cfz9KQLASgARJCiINytDH6wb6gmcv4q 2eeF2ewMCiWHI41R1yqNKehgaDRSLHKlR56BK2cDZVpSrnwCYKRwAB34T8iDXD4NZIBY8l1K3sr /hUGnab1HRgIsUlLZe23MbYwK544illODcz/DI= X-Received: by 2002:a05:600c:1d08:b0:49b:96a0:5c00 with SMTP id 5b1f17b1804b1-49cf825168cmr70126585e9.13.1788530533061; Fri, 04 Sep 2026 07:02:13 -0700 (PDT) Message-ID: <66c96742-3ee2-4e76-948c-92ed6efaaac9@gmail.com> Date: Fri, 4 Sep 2026 16:02:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> <1788352275.8631fc262581453bbf619ec5b2062170.1a0621a2590000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788352275.8631fc262581453bbf619ec5b2062170.1a0621a2590000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788530535-DFED287B-A2171963/10/73395122804 X-purgate-type: spam X-purgate-size: 11857 On 9/2/26 2:31 PM, Baptiste Le Duc wrote: >> + >> +static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, >> + uint32_t value) >> +{ >> + const struct domain *currd = curr->domain; >> + unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK; >> + >> + ASSERT(curr == current); >> + >> + switch ( offset ) >> + { >> + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: >> + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: >> + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: >> + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: >> + { >> + unsigned int word_idx = >> + regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); >> + >> + value &= generate_auth_mask(currd, word_idx); >> + >> + break; >> + } >> + >> + case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: >> + if ( value & APLIC_SOURCECFG_D ) >> + { >> + dprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); >> + >> + goto fail; >> + } >> + >> + /* >> + * As sourcecfg register starts from 1: >> + * 0x0000 domaincfg >> + * 0x0004 sourcecfg[1] >> + * 0x0008 sourcecfg[2] >> + * ... >> + * 0x0FFC sourcecfg[1023] >> + * It is necessary to calculate an interrupt number by subtracting >> + * APLIC_DOMAINCFG instead of APLIC_SOURCECFG_BASE. >> + */ >> + if ( !AUTH_IRQ_BIT(currd, >> + regoffset_to_word_idx(offset - APLIC_DOMAINCFG)) ) >> + /* Interrupt not enabled, ignore it */ >> + return true; >> + >> + if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW ) > This compares the whole value against 7, not the extracted SM field > (bits [2:0]). A perfectly legal SM=0 write with any bit set in the > reserved [9:3] range (e.g. value=8) gets rejected here even though the > actual field is fine Should be MASK_EXTR(value, APLIC_SOURCECFG_SM) > > APLIC_SOURCECFG_SM_LEVEL_LOW. Agree, if() written in this way is incorrect in the way what is going before this if(). I think that we don't need it at all and what we want instead is ignoring write to others bits then D (bit10) and SM(bits 2:0) as they are reserved and read as zeros. /* * Only D (bit 10) and SM (bits 2:0) are implemented, the rest of the * bits are reserved and read as zero, so ignore what a guest writes * to them. */ value &= (APLIC_SOURCECFG_D | APLIC_SOURCECFG_SM); Probably it make sense to introduce and use it above: /* * All other bits of sourcecfg[] are reserved and read as zero, so drop them on a write. */ #define APLIC_SOURCECFG_WMASK (APLIC_SOURCECFG_D | APLIC_SOURCECFG_SM) And ... > > SM is WARL. If SM invalid but other fields valid, shouldn't reject whole > write. Instead override value.SM with current valid SM in this branch, > so other valid fields still get written. ... considering that SM is WARL it means that technically any value could be written to this field but read of this register should be return always something valid. So considering that in the case of SOURCECFG we don't have a shadow copy for vAPLIC and use just real h/w we could ignore fully the value it is trying to write to SM field as even it is something illegal h/w will choose something legal instead. If one day we will need a copy of SOURCECFG for vAPLIC we will need to do something like this to emulate behavior of real SOURCECFG: /* * SM is a WARL field. If the guest wrote reserved values (2 or 3), * optionally coerce them to a supported default (e.g., Inactive/0). */ if ( value == 2 || value == 3 ) value = APLIC_SOURCECFG_SM_INACTIVE; For now we can do nothing. I can put TODO: /* * SM is WARL, so the reserved values 0x2 and 0x3 need no handling * here: vAPLIC keeps no shadow copy of sourcecfg[], the value is * written straight to the h/w register and is read back from it, so * it is the h/w which substitutes a legal value for an illegal one. * * TODO: when vAPLIC starts to shadow sourcecfg[], the WARL behaviour * will have to be emulated here instead, e.g.: * if ( value == 0x2 || value == 0x3 ) * value = APLIC_SOURCECFG_SM_INACTIVE; */ Note that here it is okay not to use MASK_EXTR as we have always D=0 so sourcecfg[i] value is basically SM field (as other bits are reserved and are read only) So my final suggestion is: case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: + /* + * Only D (bit 10) and SM (bits 2:0) are implemented, the rest of the + * bits are reserved and read as zero, so ignore what a guest writes + * to them. + */ + value &= APLIC_SOURCECFG_WMASK; + if ( value & APLIC_SOURCECFG_D ) { dprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); @@ -169,6 +176,18 @@ static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, goto fail; } + /* + * SM is WARL, so the reserved values 0x2 and 0x3 need no handling + * here: vAPLIC keeps no shadow copy of sourcecfg[], the value is + * written straight to the h/w register and is read back from it, so + * it is the h/w which substitutes a legal value for an illegal one. + * + * TODO: when vAPLIC starts to shadow sourcecfg[], the WARL behaviour + * will have to be emulated here instead, e.g.: + * if ( value == 0x2 || value == 0x3 ) + * value = APLIC_SOURCECFG_SM_INACTIVE; + */ + /* * As sourcecfg register starts from 1: * 0x0000 domaincfg @@ -184,15 +203,6 @@ static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, /* Interrupt not enabled, ignore it */ return true; - if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW ) - { - gdprintk(XENLOG_ERR, - "value(%#x) is incorrect for sourcecfg register\n", - value); - - return true; - } - break; Does it make sense? Or I still missing something. >> + { >> + gdprintk(XENLOG_ERR, >> + "value(%#x) is incorrect for sourcecfg register\n", >> + value); >> + >> + return true; >> + } >> + >> + break; >> + >> + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); >> + struct vcpu *target_vcpu; >> + unsigned int guest_hart_idx = MASK_EXTR(value, APLIC_TARGET_HART_IDX); >> + /* >> + * Look at vaplic_emulate_load() for explanation why APLIC_GENMSI is >> + * subtracted. >> + */ >> + unsigned int srcn = regoffset_to_word_idx(offset - APLIC_GENMSI); >> + >> + if ( !AUTH_IRQ_BIT(currd, srcn) ) >> + /* Interrupt not enabled, ignore it */ >> + return true; >> + >> + target_vcpu = domain_vcpu(currd, guest_hart_idx); >> + >> + if ( !target_vcpu ) >> + { >> + dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n"); >> + >> + /* Ignore such writings */ >> + return true; >> + } >> + >> + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) >> + { >> + /* >> + * A non-zero guest index asks for delivery to an interrupt file of >> + * nested guest. The vIMSIC node has no riscv,guest-index-bits >> + * property, so a guest is told its harts have no guest interrupt >> + * files and the field is read-only zero for them. The write isn't >> + * rejected (that would throw away a valid hart index and EIID); >> + * instead the field is dropped, which is also what >> + * aplic_msi_target_gen() does with it when programming the h/w. >> + */ >> + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) >> + { >> + printk_once(XENLOG_WARNING >> + "%pd: vAPLIC target guest index != 0 is unsupported\n", >> + currd); >> + >> + /* Ignore such writes ... */ >> + return true; >> + } > Comment above this says "The write isn't rejected ... instead the field > is dropped, which is also what aplic_msi_target_gen() does with it." But > the code doesn't follow it as it returns true immediately here before > the write occurred and without zeroing the guest index field. It looks like the same question in the other thread [1] at the end. If you don't mind lets continue discussion there. I responded there. [1] https://lore.kernel.org/xen-devel/cover.1787838835.git.oleksii.kurochko@gmail.com/T/#m0de75013bd31481a2f6abd6f36ccccb8ede87a20 >> + >> + write_atomic(&vaplic->regs.target[srcn], value); >> + >> + value = aplic_msi_target_gen(target_vcpu, value); >> + } >> + else >> + { >> + /* >> + * IPRIO is WARL and zero isn't a legal value for it, so normalize >> + * it once: the guest then reads back exactly what it gets. >> + */ >> + unsigned int iprio = MASK_EXTR(value, APLIC_TARGET_IPRIO) ?: >> + APLIC_TARGET_IPRIO_DEFAULT; >> + unsigned long h = cpuid_to_hartid(guest_hart_idx); >> + >> + value = MASK_INSR(guest_hart_idx, APLIC_TARGET_HART_IDX) | >> + MASK_INSR(iprio, APLIC_TARGET_IPRIO); >> + >> + write_atomic(&vaplic->regs.target[srcn], value); >> + >> + value = MASK_INSR(h, APLIC_TARGET_HART_IDX) | >> + MASK_INSR(iprio, APLIC_TARGET_IPRIO); >> + } >> + >> + break; >> + } >> + >> + case APLIC_SETIPNUM: >> + case APLIC_SETIPNUM_LE: >> + case APLIC_CLRIPNUM: >> + case APLIC_SETIENUM: >> + case APLIC_CLRIENUM: >> + if ( !value || !AUTH_IRQ_BIT(currd, value) ) >> + return true; >> + >> + break; >> + >> + case APLIC_DOMAINCFG: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); >> + >> + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO | >> + (value & APLIC_DOMAINCFG_WMASK); >> + > APLIC_DOMAINCFG_WMASK includes APLIC_DOMAINCFG_DM, so > the guest can clear DM through this write. But aplic.c: > aplic_init_hw_interrupts() sets the real hardware APLIC's domaincfg to IE|DM > exactly once and never touches it again. Is this expected? Yes, it is expected as we are supporting now only APLIC+IMSIC in Xen and it is the reason why we here started to provided a shadow copy of domaincfg register for vAPLIC instead of using real APLIC domaincfg register. > > Moreover, I saw that d8fbe0bbc7's commit message claims: "a guest's > domaincfg.DM reads back as a fixed one, so is there situation where we would > allow direct delivery mode? If not, the else branch should be dropped. > At the moment, we started with a support only when we are working in MSI mode but commonly it is possible that IMSIC will be absent and we don't have any other choice as started to support delivery mode. Thanks for review! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:15:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:15:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408561.1641056 (Exim 4.92) (envelope-from ) id 1x2Uhc-0001vp-AA; Fri, 04 Sep 2026 14:15:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408561.1641056; Fri, 04 Sep 2026 14:15:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uhc-0001vi-6l; Fri, 04 Sep 2026 14:15:36 +0000 Received: by outflank-mailman (input) for mailman id 1408561; Fri, 04 Sep 2026 14:15:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uhb-0001vO-5X for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:15:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Uha-00Ehtu-IU for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:15:34 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ad276-e002-0a2a0a5209dd-0a2a4501d956-48 for ; Fri, 04 Sep 2026 16:15:34 +0200 Received: from [40.107.208.31] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ad284-5984-0a2a45010019-286bd01fbc01-3 for ; Fri, 04 Sep 2026 16:15:34 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by MW5PR03MB6957.namprd03.prod.outlook.com (2603:10b6:303:1a8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 14:15:31 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 14:15:31 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KoUugHMxOf6kIbWoNQFPCSvhopmfSpF7maR+rCot5xxSMWR/LxhEKDDr/19352ACE9TA/y2MRIunoflOELasi2YGaD0/3YwwAbDPhmeCoOw0gR3Na/54Gk6dz7zPFoHEEka4DQV4ZiapzU1BA1th/HItvzO9ykipPvw7/YRjwOl2UIuHisKXbNEO8ZdKxsnanTl+7fed+9rzV7ZOxyD9RWaCeV1HuvsDgKA7N1oyigWT3PzAEceV+xR1EJGssaOT+5nwZzK7+owV1w0LfS1vVpZZtomOSJz6ZALJMKJy5nZwn9o4ytApV1s48i+Q+nKuu6lUii0EAikoHClQ1KyBcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oAWojgnc1PX0meqiqPkIfh9aSER1BfswxCr1QfPRO50=; b=XWRbd8I9we6rpB0G8VsRD4ULdf5jX7k6RSDRYc+ld6AA6ET3jHLxE6ayk2qye0cv0PLluJWESFDRfAifqpFs6/iue/Ow8CDgLddQeIGHgoX6oDsNPYTUo1C9OV2GYUtXVb+4AqijVHhqwH7nVqzOTea3bKkeGB3pw8SmfZsp+NaM091sY2ohDFa96GXbjEfB8qWLoIXKzlOIHiMq37LL+Ovba6dLFUBCmHDDE+BwSNfEJVaobOnCFLjqJSFfRuH+1isPuxA1mL2LGXuBD9OoeqTU1ziZTNiBqyPqU9cKW9omdZ32JNjZEuhM4jXb9D3rmReEqKgWkwwMu462/cKQaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oAWojgnc1PX0meqiqPkIfh9aSER1BfswxCr1QfPRO50=; b=kh9iNkr3Vr8EPpuu+svjHH9U/0okjVD4EUZTipV2PKymqWPVUTEulmBCoOccq3cejn2Pwl24Uh2OZ9BJ+yKjTZRZ0devOgMKV10q2mYdrRHR6T+WgTAUUOrZ5AsbXmNYxJzN2f0eaCCWBMi2C9agokJIE1uigZ/K08PJG89wkHc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Paul Durrant , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v2 1/3] x86/viridian: Workaround Hyper-V GP fault writing to MSR Date: Fri, 4 Sep 2026 15:15:14 +0100 Message-ID: <20260904141516.367862-2-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904141516.367862-1-ross.lagerwall@citrix.com> References: <20260904141516.367862-1-ross.lagerwall@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0242.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:350::16) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|MW5PR03MB6957:EE_ X-MS-Office365-Filtering-Correlation-Id: 4d7638cc-e6ea-4c72-0b85-08df0a8efa57 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|10067099003|11063799006|18002099003|22082099003|56012099006; X-Microsoft-Antispam-Message-Info: Wp56Qn7AXtTqcy3g/hppy2hwg8RH+qoyD55zbnsybpVPXd8q0+vR3osIgJLu8bTUr4itkRtFJSePTAWSYj0O71b6ljrV16FnG+9n2AD5fkNcPr05G/kmRsfGXf7pc4gwbSwU99tH1eKzlpwt8KC9bg55ZN2CPnAz8E5XEwDgkEoPK7fH7sUuJ5HTPQSG0PWiTakCBK9wXV92mvIJWSFzalMy0mmHxYQJdVtTZQnwb3huUAI/W0n8EfH0P7Fv+r/xI+jblyjSdVgvF+wrUH98vLvIQEdn7TaG6GHai4+kG7PNZyX+u+dqadynEcA6M8lOnfOiNTHdUzBhtc4W+t5jcXQ1nev7JJXaZoYXQa8ZpYd52UOfE3DZHpBLOLC1ZoGg0TbnUGuPtcXO+OlzYWD6fDR+LG9ydZmtqkEjIoWO0zNjp1Xl1VRXOGvOc4yIDA4WqzAC5P4ujzF7mwu2fdOLtWeJjZkkyD4eEjLgMqFxrBHHXtWL8lIZgAVKhxHsP7hzYuwol49KT/oGE48lvrRnS9Z7a9e5I/5Bn6I9J5Yu8sDW8mszco6AHMQW32M9Gy1PcQ6TygxhhIGuT6BONeZ6jbKTOW/N242PVia0t54Zmud/Q+XLPlsVlsOunVEcIkvBHxVWTE2EUIhNugVc7/EAKg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(10067099003)(11063799006)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zybOA+dlOxhx7Qfak18Li3Sd2IsL2Jg09Q5S/E+J9uQbCSfRkIC9ZgOkbxti?= =?us-ascii?Q?OTNw2zhFhX4ehxGGYLqz2YbTFVj7787UiLtyve0KXDIYZZDbPg1waDuR6cLr?= =?us-ascii?Q?2BJYCf3gENXF+daWXbUbYW1o+HcGt5Jti1Rk29yJQr351cSwLmRLxC+iZ7ts?= =?us-ascii?Q?wowFj6GxbMra/SNufthEKWZPs05AHclV+ITti24/9nV3q89INgN+3rc5taMr?= =?us-ascii?Q?2e4St4ApIlrqv3hQU+kTeTiZ2ftpaGjN5QRYu6ElTWMThGKQvs9vmbMU24fD?= =?us-ascii?Q?RbweZj70nfGztkr6UL9pVHfGfmS8KoEJMqpszuegp2KjnnnEBfYI/tYDcviF?= =?us-ascii?Q?h5zxUSE5A+a1MjUEkmgNxRFsaWqd0C6G7gWxhTwJFTXg05t2e8Pt3jZZW1Id?= =?us-ascii?Q?505aPXO0rPo7NsDZ7PtTVBsrxXww3wgXfXqqTZ783UBHqSb6H8M7Q8U8vyJw?= =?us-ascii?Q?kgQxz68t89Atio5ZH1cNe9SNCkz0t1U/5u5mAa6pwN+SXThETAiA3q2GSJ+L?= =?us-ascii?Q?XF7wZQReuRl52AAdFGNDdiCGCqxwLVXbn9dbVqOxGEvamAKA9JWbb6YpE4Tq?= =?us-ascii?Q?yre7FDdWxWpPmJzaNvWH2Bj8AGsBDj7eMHghf/EnNbTSQRSBmnvhQDP+qKBT?= =?us-ascii?Q?tzmc4iaJQBI9HjV9s7PbuhUqGQkal0nb+OyKiXerIrSocJyFCjapPUNatyCA?= =?us-ascii?Q?HaiRAdb3OMqcZWmPdGN1TY5cubfra/tq390rq7JRPb63vyjKZ4rAfQn0m4gD?= =?us-ascii?Q?3DWrFf3JOSZaeNNxPx9Tjil06LMOXpILKCT7BK6gwHNxJitPi6vt+UfptE5T?= =?us-ascii?Q?22SlhrlcMEtc6AcF7Mn8/eZhnwpwX0tGfSEMN/jWjSCklFhDJxHyHybyzHoU?= =?us-ascii?Q?FOu5eGduVZtE1A+wnIgwnRwcnvUkwiiUzaR6UfSGu2KWDmVxTUXDsw9ULiOT?= =?us-ascii?Q?gzxXENs6dga78g8Y5+h05SVTijVFi7M2jdGpeqwfQsjDYvUVuB3/2qEkY1Iq?= =?us-ascii?Q?Rki12QFt8+Ifu1TYz/m8uBcqdg4UI3rbLmHISv1dFT5DM0zbwJpfgmZAs/qj?= =?us-ascii?Q?JG4tzFQ9+PJKP4awsc54o/KaOxhPgdI14YILopzzBZQOz11kDfEfyc1dCI13?= =?us-ascii?Q?pzDTbQXLKo2u9jhP31xsfiqPPppNdxURMJ9hkShbkA8jhwxYbdCQPyRpH3ue?= =?us-ascii?Q?dMNT8nji9ZNqreU5B48XOqJ7l0I+/LK9tspCO3G8N+SrRSIuBmIWmvBePvS1?= =?us-ascii?Q?jgiwa0lJcMpJcOXs2uBio8CEAOlrbUnOHrE7Wy9W2vDhp7NfOfmc59aIQzxx?= =?us-ascii?Q?a3pDN4iQZIh2FWhxI142aAUkIo1BVnmn/M0zZdwcICJThOROCE+3u6m0yfPq?= =?us-ascii?Q?FS7+cjfk9BMCvfkqeXjDMTF5FNEuGbeWnW1Qb28s2RR8yRsX2sp3tLuKMWlJ?= =?us-ascii?Q?GTOiWv9W7GjN50ElWB/Iz8hGa5opFBuv4Iz3yL9gp2rQRPRv23DpNnUFWC7y?= =?us-ascii?Q?NiyBEnHrDs+8jBQfBBcGYCeqRAlZHPhcekAMQsARaLZTcs301/nt1ZmTPHav?= =?us-ascii?Q?j7YHDExjk7i6eoPPVXwWyxCjZr1oh9BgErEF75Mtrjk7vJP07HfDP13MJa/G?= =?us-ascii?Q?0tL6LxZ+gOMCCqQQYrjtOPugJF4RN5+Zblg9pFq97kkd5ZOSJzK4WNeMA6HD?= =?us-ascii?Q?dGhCMdX0rmHZkewncsLhXvEvvWcskIBjo31MHLGsL2MfPjUdCS+nZocLY5xr?= =?us-ascii?Q?f8aUtjvmtfHaaFH1nCJcnyMXVe+cmmc=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d7638cc-e6ea-4c72-0b85-08df0a8efa57 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 14:15:31.2111 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DKYq1HfChJAnnYtW8FHf5mStycObAPL9nCMEXdjgYE8Ka2AyuKs4DBAYBbZzJE6QhfOClg1yxKRnBeGawUerUjt3sGsWjb/yxouikLMJFzI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR03MB6957 X-purgate-ID: tlsNG-d62444/1788531334-1D87F757-12D9F311/0/0 X-purgate-type: clean X-purgate-size: 1490 The Viridian spec requires the vector to be >= 0x10 when writing to the SINTx MSR, otherwise it should #GP fault. The spec-defined initial value is 0x0000000000010000, i.e. the vector is 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to the spec-defined initial value and since the vector is 0, it GP faults. To workaround this, treat the write as a no-op if the value is unchanged. Signed-off-by: Ross Lagerwall Acked-by: Jan Beulich --- In v2: Added a comment to clarify xen/arch/x86/hvm/viridian/synic.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xen/arch/x86/hvm/viridian/synic.c b/xen/arch/x86/hvm/viridian/synic.c index e6cba7548f1b..75b004440e58 100644 --- a/xen/arch/x86/hvm/viridian/synic.c +++ b/xen/arch/x86/hvm/viridian/synic.c @@ -157,6 +157,14 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) if ( !(viridian_feature_mask(d) & HVMPV_synic) ) return X86EMUL_EXCEPTION; + /* + * Windows 11 Hyper-V (26H1) has been seen to write this MSR to + * its default value, despite not being a spec compliant value. + * Tolerate writes which have no change in value. + */ + if ( val == vs->as_uint64 ) + break; + /* Vectors must be in the range 0x10-0xff inclusive */ new.as_uint64 = val; if ( new.vector < 0x10 ) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:15:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:15:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408560.1641048 (Exim 4.92) (envelope-from ) id 1x2Uha-0001j9-4d; Fri, 04 Sep 2026 14:15:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408560.1641048; Fri, 04 Sep 2026 14:15:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uha-0001j2-06; Fri, 04 Sep 2026 14:15:34 +0000 Received: by outflank-mailman (input) for mailman id 1408560; Fri, 04 Sep 2026 14:15:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2UhX-0001iw-Q1 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:15:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2UhX-00Ehtu-2E for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:15:31 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ad276-e002-0a2a0a5209dd-0a2a4501d956-40 for ; Fri, 04 Sep 2026 16:15:31 +0200 Received: from [52.101.43.70] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ad281-5984-0a2a45010019-34652b4675ef-3 for ; Fri, 04 Sep 2026 16:15:30 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by MW5PR03MB6957.namprd03.prod.outlook.com (2603:10b6:303:1a8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 14:15:26 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 14:15:26 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JF+7HbKqVQZWJQL2EMFPwnxBRb9bWVISHJqn6QT5HBZLhoGF/NyeFr3q5cFbREINEh7sj8MPQpFfLHhYIrjj+Bz+Ts50cw8pV+VWx5Hb2p/OmRz+sDC+TJ2E+QWz83UEsnfxgYUW+/z1KiJRiXgMksidhjNRECQv77etvsLy9rZvUD5tnQPddx7ACJeXjajdSOpckNDofkdktcknm5mtm1qaToqPwpWASYolWPgGcZ/LBigwq3ilpQRF+Kq+g/ml/ZX0QKPBsDSIy0oOJ17+DZvXlI+I9/t6AAtjwfR8s9IWJARHHcSpnmdMAZFUGhb0XweLySc+nmg/mEHfhYbZ1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KFN/o5VE3ASj1PHdpDqZMv4WW+RsDbrGJ+q/M/PgUBo=; b=WEFfXco2apsrgxt/vjzINKvv3LBWvatq3iva5ClFrrq5HxDNwYehdqX7QJyNnkNg7q98SWx+SqACM4rUv3QfZAVh9jBvqJk2i8wpOXP/kH5hqJhMPNLHtADWn+pd251UifZVRKjowudxgZKSCUeAYK6WaneZwxSllg6GAecfc1dYCW+bR0wfzpCxUJ0YRx/QclOLm7BBh80DzEkP8p7eTLbtxkNGWn02bgU+bwp4bmQBIOXtPleEYKrs/o0fosPEKslqPZ1AQViKgwQ04Gi6o0yBZ6F2H9vygWe/R2sxTEjNncwzWHUE4Pk8UQtZvrYAv0+06ZpcL7hgznngC2xggg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KFN/o5VE3ASj1PHdpDqZMv4WW+RsDbrGJ+q/M/PgUBo=; b=H3AofG4cp53DwmDhNu00mUl8mJEpqihx1fMDqdfjrfT957YOuNCh8UZLwBRhM80HITvg0wqx9Eowe+9JVaI/cXAIYEkAofnAWQIdjpH0BvqYYEyasrnZR/Ror3MqZQKXr6PVHhr9HobdKkvX3VFzW0DNYuNf8K0m3aX26AkUdLg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Paul Durrant , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Juergen Gross Subject: [PATCH v2 0/3] Viridian changes for Hyper-V as a guest Date: Fri, 4 Sep 2026 15:15:13 +0100 Message-ID: <20260904141516.367862-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0245.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:350::17) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|MW5PR03MB6957:EE_ X-MS-Office365-Filtering-Correlation-Id: 76509b20-aef5-48f8-920f-08df0a8ef76d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|23010399003|1800799024|366016|6133799003|10067099003|11063799006|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: j/Of0XsPlDEjIJXS9rsG35T0P2NylEY4w64vXa0/8nrHia+BC3oycz2o4PDWcH5BYqWjkZ2sbdaNc5yBfaux0IoKAA+hAIdhuniwTzzEFA7iWfk10PmkjlS2aiDF8JrQjvpi+P4QynKWcQ+Sd9LB1ub48i3KMwnKuev2i8GNECXAZ7HSxVI5HnLPRq9WfJeguoFtbAsvPsNhJctquVkryewGNVdT5Km0hIbeer35QEQCul1DVHSC8CgS3s0Jpr6eHqYAJrPU2Hlj9kwHpsJ+bTQbm94GAwiQHsIbMGIHY8klYEk72c9pO98faMHRX/LXMDNOWVvf6pIc1lc80aezI/r89t4fe4c/nDSGbAw7RbM6x8PAO+2HSjz/iMxsy4z+Z3joE5PQrpA2W5I2FNnGU6wF94mV8xx+axiIeJm9kmORZGbi0m3aMGGzhEZLlKUtUcN3yxRZvornwgaVtcnKDvAhOJVXV6HTms4/OjR9wcLmLJ4ArdYXbuy/ApwiRvIxIZn752Ni3GRasSR80rt3xRvaGSJoc4o61IJ5nUVOKQZFhiBtoTRQQk5izEunwJNeVfd4EPP6+BMrgN+RYovnfRahNDKV6bGR16D7xX+dil0VTyVnUe88f2N1ihtzZc4f6I/8fpsgwsUQpzip1e10YU9YreEZeE5orwdaHwxckKE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(23010399003)(1800799024)(366016)(6133799003)(10067099003)(11063799006)(18002099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+ySIWXjnfQB0TuYKnzBfr+ZQLlA29E34fYMeY8LxoMfOMdi+mOeHFeJH11UO?= =?us-ascii?Q?V+XTNSktlI98L5jYXzwlzFQGPNriu5DUrfb4Rq+ZDaELKIKqiYxKOZeFyaM8?= =?us-ascii?Q?Xywmp+tTeaz9bn85dyD1MmJZ3ECG42BY34URVm8ZC/455wCPIrFxPp8vlgEc?= =?us-ascii?Q?0E5xCAKW3J6eSyLcEZ6kkckVU8AJOYgUmEDv46022+nnCt2u9ShS8h8f8AYE?= =?us-ascii?Q?U7z7befuviWoOFF1S5pG6FsqOBf7fiZECMTn+wVtaJoTb+mWOX5LQRe4DIvS?= =?us-ascii?Q?rdC3ygT74DpkdHxHQiQaUbEzt1e5BvYsgB4RvTHd9U2XEwJBf71B1g14foOO?= =?us-ascii?Q?vc/pksxSjipbQHgeIkA7LJ/f2pHiouKwcKoQq3GcXxv7W2yzsFrf/c/1G51a?= =?us-ascii?Q?eH03aEz8PNnQflrrnKK5vOX33K2v+V7UOH54haqRRpzoYgJ05OjThQPabLYn?= =?us-ascii?Q?O7t0bzv0cTbm5+th72hxSdN+ck3lGUvUaC0gmd/DNOT9Up99jpcR0NMGTrit?= =?us-ascii?Q?oQTzScfM+7HO2u17Bdx3jwQRpAQf6eKvQ5NOnrl6vAS8WcO+Pfzyxx2ZmXop?= =?us-ascii?Q?K2jEfJYVdXZJBk8DD1DeDz4lFH23gG+drxb+GGf2XI164GQU7ubJoAd7r3Ul?= =?us-ascii?Q?BGlzqcYI1IH6Iyhlz1zt1cQ4k/9rr2GCWqD+XPM7EKNhcnDAtFGCS9Rg1ek3?= =?us-ascii?Q?T5xzV/xNBlea8Lg4vSL17bvyavlFhxR1zzbHVGy7POKDEKo/Qsd9He7DNP1z?= =?us-ascii?Q?9w5DYWlXkd/1p1JXQXydLocpLM2wPWlZvLzyEhy+hIsY+fJZVBXuInY3IHpM?= =?us-ascii?Q?ZcQWgOkHqWPIqE5QWz9pG4tc4vappv5QVwSrjAIHV+H+eixwtfGj1tRT8AM2?= =?us-ascii?Q?paiJa3yAKM4jKPNtoIyZMvZPSV6GqqTrCFzJ/VLcfNNtBNB8bSoohW8HJGs+?= =?us-ascii?Q?iww1mF56XlH8hT2F/SG/es1DJk/le/uEL1sHVEvSzbkqrNLAdVTxlGKJjDwO?= =?us-ascii?Q?qCo8dMGBZmCPfgAnXtNizL+svmFGKuxpUXoXB76fRMAYv4oHGFZS1IuCxs0R?= =?us-ascii?Q?h7HlDUYaG7y0tDd+06DgfWLORbQjHZXlKQtSc0azodbbmXhayA3CB6iAyLwC?= =?us-ascii?Q?VBhbMMBPb4tPYm1RmyOlsW4cDUV2zEz8soTPdnF76VyZBIVJkct53KmQppCz?= =?us-ascii?Q?YxLBWnX0fdVbdL3l810ZHVGurzbxM/vsyY2W6v8jLefsqMmsaG6UUf13uI/E?= =?us-ascii?Q?XXi4pYqpm5V9BwZ0QDuO7yaPrgqi3UPrMRU5kWrQ7UHAsDVd05vpZLlupjMD?= =?us-ascii?Q?mB8jrA0pn51VcEweYdG9BcN9g8OpcXlRVL4wpuUJV5T2dU/pS6GkQMIK3B9c?= =?us-ascii?Q?y016C+cUbp1ZOmoLzdK2oSsjIpUoH0NpqN8k4YL30fECbNAUfrGh1SXwn84S?= =?us-ascii?Q?QKexa72G45q/2FQu5WQXUremdw9HQnVM5DDUXNQLbG9QFJICgv24HOginrPk?= =?us-ascii?Q?7jxaHv2b1tuApZoTpj8j7wzjZWuZnqoPxj2vlh5QE/6iX+xDNNdT7fKyyG2A?= =?us-ascii?Q?nr2Cl0jY7AeV49VuXuNjBxEiQbf8L/ZB2f0ht3frxV99ZvWvxnk6necq5/Zg?= =?us-ascii?Q?I068oUdmXgp0tRqnWiG7pnKLYLa8G1SIWxEb48LkUEmnFS8vy5F7h0ASGeQ3?= =?us-ascii?Q?zZlME+w7x6nxs3H+a9HlWPYsdB5PjKY+kVe5vJPJYniP6Vfqh8d3DO45Zf8H?= =?us-ascii?Q?d/d1OF0qgk1n0cA7ZScsr8qXE6fOaWQ=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 76509b20-aef5-48f8-920f-08df0a8ef76d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 14:15:26.3404 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UCuFuEpc0Kk83b22rjk1GcRpWjc2C9i60HsRe3cQIBmQ+VGAoH11fd5GwLbP+1NoZ9GA/zNq3w2bYDIeOD3EqC0eDWna358JfBBUD1JEZps= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR03MB6957 X-purgate-ID: tlsNG-d62444/1788531330-BF66C757-98895844/0/0 X-purgate-type: clean X-purgate-size: 942 Hi, Here are some changes to get the existing Virdian enlightenments working when running a Windows 11 guest with Hyper-V enabled Hyper-V also depends on some unimplemented MSRs to boot, but that will be addressed in a separate series. Thanks, Ross Ross Lagerwall (3): x86/viridian: Workaround Hyper-V GP fault writing to MSR x86/viridian: Implement synthetic timer direct mode tools/libxl: Add support for Viridian stimer direct mode docs/man/xl.cfg.5.pod.in | 5 +++ tools/include/libxl.h | 6 ++++ tools/libs/light/libxl_types.idl | 1 + tools/libs/light/libxl_x86.c | 5 +++ xen/arch/x86/hvm/viridian/synic.c | 8 +++++ xen/arch/x86/hvm/viridian/time.c | 46 ++++++++++++++++++++++++---- xen/arch/x86/hvm/viridian/viridian.c | 3 ++ xen/include/public/hvm/params.h | 7 ++++- 8 files changed, 74 insertions(+), 7 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:15:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:15:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408562.1641065 (Exim 4.92) (envelope-from ) id 1x2Uhh-0002At-Fu; Fri, 04 Sep 2026 14:15:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408562.1641065; Fri, 04 Sep 2026 14:15:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uhh-0002Ak-Cv; Fri, 04 Sep 2026 14:15:41 +0000 Received: by outflank-mailman (input) for mailman id 1408562; Fri, 04 Sep 2026 14:15:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uhg-0002A2-MB for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:15:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Uhf-007o1s-IL for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:15:39 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ad26f-8faa-0a2a0a5109dd-0a2a4502a8ce-36 for ; Fri, 04 Sep 2026 16:15:39 +0200 Received: from [40.93.198.8] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ad289-6ca4-0a2a45020019-285dc6083325-3 for ; Fri, 04 Sep 2026 16:15:39 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by MW5PR03MB6957.namprd03.prod.outlook.com (2603:10b6:303:1a8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 14:15:36 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 14:15:36 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EHP6iTHLSpa/GUYjC8ITUSgVZVEaBFcEWHjtqCh+oLluXuZ30sBxcyDA+UR17d9wZ9lQJziTNxMKOddo7lPcHYn33QcPGpWb+xp39u4PheYKlNsD5u1rFous72L0I5sw40iG8eq3Q1bVICJHY4vcJm8eV3P6l83PQP6rGQObxliOxS1pT/Z8UCuEkaS4hNfQ6GjcZr2MFZduqX1aZuJSZiuM/7GignXmSaslHhAtf4c0zUD9m4wOfzmx/t/OEDlk2pJNny1dncpGb/k6cyGIvaDiPtR1PS0x8OJMc8JcWfvkSUEA9TSctsxcwnCv9cAG/fmmMYDgI9z6U9YnruqGuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QpE4bVBGUwH9EvsjPyq1mD2BzEXMSLIFuK5hnOBmzlQ=; b=L4UpoAMrtQFstWtHJlUyZ0L5hmcCjZ/yguXEa7Do8+mEY+GJUyBBvl2NsWY6+AFxe0UfstjoCsEuU9ItXswK+vE3mc6O5OayEvBzfi9YgnxA+CTe1rttGJBqwSzE85MfZtrKxlU2xTk3rFwBZX2C84TrtqsagB4prAkrUmuzB+BeFO6wBUTRU5K6hyOaymZ/tD3d4h8jq0azu+6gi2yGWV/Nel8/vu0AqRsv6oRGIdDMV9jtnOkArTohLjK3UW28f8jWKkxOhLkG9FCfD36MbSPlPnq9gxKxrDRvzRcCEDGLhCTfdJ5Kp8dWmezD752pKXyeOCEuxkQh/f5TXkYT3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QpE4bVBGUwH9EvsjPyq1mD2BzEXMSLIFuK5hnOBmzlQ=; b=rOCzQkeF+1vFsAKBFjdoiG94Ez8CMDKpLPb+9ncD26OBkiilnHdATvgTV+67yEC6k7PV+kykmXtFN3CpSkpfeKrsQuNC/qp2N8FkTBe1JikKo5dDwZlhUPGd6ET/jYi0raoL9C4BJyHzTbeq3/aX1J/cSEvbi0RQxcmCPX5dMbU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Paul Durrant , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v2 2/3] x86/viridian: Implement synthetic timer direct mode Date: Fri, 4 Sep 2026 15:15:15 +0100 Message-ID: <20260904141516.367862-3-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904141516.367862-1-ross.lagerwall@citrix.com> References: <20260904141516.367862-1-ross.lagerwall@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0264.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37c::15) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|MW5PR03MB6957:EE_ X-MS-Office365-Filtering-Correlation-Id: 8e50b48f-50d6-4e26-1945-08df0a8efd3d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|10067099003|11063799006|18002099003|22082099003|56012099006; X-Microsoft-Antispam-Message-Info: m7L83IGCFDBdciGKZuhbUMb/N9RJn2LkqD+exi7m9DcQS3GqvTugc96+E+ecP9QOajz8hpF+VBTWHQIMcMSxvVO3FDJWWxTEezBpteNa5WLubN8dhJ/1KbajeWki5W2sHqkU0C1Icei+WJ9TvLrfm9jLCsvQeKmPxEr7KZ/U3F+zFHhTq8wRW5xwovIySq0z4NShamgva9AznZYzP6EUDVJ6InWtSUIaXXYMWA0YO0h1w7RTPzlpI19D3BTcZ9IFgUuc01jgUCPeqHjb3XAN4c/OXNaDfQAxWAZUzRYmNm/VeBN054UhQYF5MIR44ltU8oV/pXKc1/WAVCTxgFhqkhqwxIP6adz5LBbUrcongSpbpiD8APK1Dw1kPUnutp9+kktSz6oCSsdNMD3DpFjdEWaDtzEOFtnJVVqUOK1Wd57onc3UAxziJ9xUMZiw7d+rhXGShICFHR+7VGrELUgg6Z6tJlL19pbYM73Z5xTgsui0ck8/tk3Ljq2qMROqbsjCxaZfsN2t667UggcP3ZwSYALwzuYRt/krfwBoOM72gqYvdkkbq5PlRHqf4y2PBkJIebv/gpiFBavfzDCRBVPt5ciapW9e7B7yFvrmetdmI6Ard9dU7tu/C5Vf53cL3F/5Bii7FfUTJ283fTsLc7rrJPgmbzCHT/JuXpRCw8AV1Xg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(10067099003)(11063799006)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?qMIHD4By5LdO63PXG8lUMvIISTvmSqmv1hVNASblns+Ci+Cmdekh0mORl6a6?= =?us-ascii?Q?MUrZMlBapyUhR2NoNzVElVWur+d9TqQZYCcDF9/OF9aCXVc37whPwnHPMZXq?= =?us-ascii?Q?dn6XDNY1pexmvRKX92gwPPWMioaUL7jXVzBEFOuORb95fcvqG084UFgZ0cO/?= =?us-ascii?Q?TLMH7AUhzJufUnxrXKoECW/HiCvAWiJPvAiD/J9skVXZJs/4pV/aijzkRpzn?= =?us-ascii?Q?Ljzor0SU2ZoUlZsF5rK5WQTQDiGpQ0aD1pi9R3ErF1tiDnijLHWdz96618qw?= =?us-ascii?Q?RXqtq6LPxiydeifp4w1NIvs8r8k1qweyFvHudNkgPv5MgYVuRARIxcalOutp?= =?us-ascii?Q?/9Z32V39Yp5Bi0AdjxoyPB/pNqqHuKl+tkHD3wtzRL7zcTO5DLG6+GVsRfAp?= =?us-ascii?Q?zXknUzv8jsiUwAC0Pt1iUzBxyUPqNKOjd7MvzglJofW/N+QTSVUorbdnQd+/?= =?us-ascii?Q?yqqeR1NWQ0BiWRWJnMhbf/HBA3f+piR+fxkqeFrXBthzCU/vAcOz+3Ya5zCe?= =?us-ascii?Q?lVWWIU+CD0vQim36K+DwtoIVpKjfT5fcaZ8mlL9XoB1trGOdOD1+jrkVbepl?= =?us-ascii?Q?mYuInNYg6UI0shPRl3lly0kLYrUh6BBPxdGpn5nTa1iV9Wd4kV2dtJCvyFTd?= =?us-ascii?Q?Bre/w6LyeX2hSJowZG7VDYJFEa6bc/Vec4qT832jQxOEsm+Lp7dglGUWDpRG?= =?us-ascii?Q?h1O/hWLw3t0cR49LifTcpNYFcoetGfBm/Zr0hxFvq8q3vUtFqHyVCSkxVQCl?= =?us-ascii?Q?KsPX15auBxTlWC3Se5Ql5nCXOnxpaQevu91hTSgJ3PXN27KSaHsY5t3bbLie?= =?us-ascii?Q?XEdyO3PwYiSHUxEDSJ4uTYWu4/mvFPJyQNzRCpPZdoMsl4QN6J4ggTw7ndJX?= =?us-ascii?Q?KkqXCrCqimPWVvAzSyaWRrhKG1eRGbTNWGH1TeNhFa6Gd5PSLg7ciwytuW+x?= =?us-ascii?Q?9v+jY6Yv7ea++dfY9VWgnUowDS38NPfXGQxStZFMliERusJHvxzhNN7NgfLp?= =?us-ascii?Q?6yGqYmP5yia6Lvkpl/oa27zCjMppHF1UMv5YfC06G4P57KjL+vHButryLq2/?= =?us-ascii?Q?lvkLjX6h43KgPN6RVGlqfn8II0FOep7sNUW6OtnPd52up6fT5U66knaWsOm4?= =?us-ascii?Q?KJYzW3cwnAbd/vWrSUxqge8H8TxVepGJuJL4QYK7zqZ2e/RQWa5lEvTN0L1q?= =?us-ascii?Q?8kIwHIu070m8lKhzsPTtslNkQ0bXFJFWXf9sKqnLJOEZ+O4wEtA1seqNLoAl?= =?us-ascii?Q?gUiHgtQ9m637uH2C4PgGC/Ok976O6Vv1qGhxtx5mpxz61RlRg4ENGVbSbAwr?= =?us-ascii?Q?b+xjw/2sm3t9KUWzLZzfQUXUq53fd5oITYhz5CiN0fNqysGgAQoM0Y7o3scz?= =?us-ascii?Q?Wy5eQHC6WMe5m1lkqWGZ7herjbRtIYbVUyQCvZPLKlVGrjyFhWbxbwoBz6jU?= =?us-ascii?Q?k39zgyx4FwhUnc3qQKYRmrzscL+NvMaUHAIGJ4M4kUrrVohVXJAG7Aj7IvjC?= =?us-ascii?Q?cpAyYoz0PmBtPneb4+k6f0ImLXFKWsdTCCKhfpPeojLumUQTGjysf7A3vMz0?= =?us-ascii?Q?0FG94BjN/k2dYmX59T3h7qx+fq2Pt/MrFocOTKZqHBy916ktAFLz6TYmR6v/?= =?us-ascii?Q?hvWKTBVLecyzYWTaff9SJwcKYbTb+/FCsNzktn78TpGi3aRG3INuUgFt9Xxc?= =?us-ascii?Q?YNfBHi2Tdi7epb07ZnNOjQvvGpTIb8XLKI6KVIxvfp8C2J1g/Ulxhc9xtJrR?= =?us-ascii?Q?z+oyDGqRAK/ze9UTsYHKW6RXbS7k69M=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e50b48f-50d6-4e26-1945-08df0a8efd3d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 14:15:36.0961 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ovSZuJWg+JJX0/U9OrMQuOS24Wc4cWh+nqVkH+JcFOrBbUAKarustAGU+6PX6o8notXIzH8cTCoPsYuJHiN5X6HAD5uHvEmHH8x9F+cs0T4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR03MB6957 X-purgate-ID: tlsNG-720697/1788531339-F3CBA2AC-7EF75AB7/0/0 X-purgate-type: clean X-purgate-size: 6017 In direct mode, the timer asserts an interrupt on expiration rather than using a SynIC message. It is useful to implement this since Windows 11's Hyper-V can only use synthetic timers in direct mode. Signed-off-by: Ross Lagerwall --- In v2: * Handle migration from older Xen by introducing a new Viridian flag. * Added more sanity checks during MSR write and vCPU context load. xen/arch/x86/hvm/viridian/time.c | 46 ++++++++++++++++++++++++---- xen/arch/x86/hvm/viridian/viridian.c | 3 ++ xen/include/public/hvm/params.h | 7 ++++- 3 files changed, 49 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c index 082528dc9416..4c8352612b19 100644 --- a/xen/arch/x86/hvm/viridian/time.c +++ b/xen/arch/x86/hvm/viridian/time.c @@ -223,6 +223,14 @@ static void start_stimer(struct viridian_stimer *vs) set_timer(&vs->timer, timeout + NOW()); } +static void stimer_deliver_direct(struct vcpu *v, const struct viridian_stimer *vs) +{ + struct vlapic *vlapic = vcpu_vlapic(v); + + if ( vlapic_enabled(vlapic) ) + vlapic_set_irq(vlapic, vs->config.apic_vector, 0); +} + static void poll_stimer(struct vcpu *v, unsigned int stimerx) { struct viridian_vcpu *vv = v->arch.hvm.viridian; @@ -242,9 +250,11 @@ static void poll_stimer(struct vcpu *v, unsigned int stimerx) if ( !test_bit(stimerx, &vv->stimer_pending) ) return; - if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx, - stimerx, vs->expiration, - time_ref_count(v->domain)) ) + if ( vs->config.direct_mode ) + stimer_deliver_direct(v, vs); + else if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx, + stimerx, vs->expiration, + time_ref_count(v->domain)) ) return; clear_bit(stimerx, &vv->stimer_pending); @@ -361,6 +371,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) case HV_X64_MSR_STIMER2_CONFIG: case HV_X64_MSR_STIMER3_CONFIG: { + union hv_stimer_config new; unsigned int stimerx = (idx - HV_X64_MSR_STIMER0_CONFIG) / 2; struct viridian_stimer *vs = &array_access_nospec(vv->stimer, stimerx); @@ -368,11 +379,18 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) if ( !(viridian_feature_mask(d) & HVMPV_stimer) ) return X86EMUL_EXCEPTION; + new.as_uint64 = val; + if ( new.direct_mode && + !(viridian_feature_mask(d) & HVMPV_stimer_direct) ) + return X86EMUL_EXCEPTION; + stop_stimer(vs); vs->config.as_uint64 = val; - if ( !vs->config.sintx || !vs->count ) + if ( (vs->config.direct_mode && + (vs->config.sintx || vs->config.apic_vector < 0x10)) || + (!vs->config.direct_mode && !vs->config.sintx) || !vs->count ) vs->config.enable = 0; if ( vs->config.enable ) @@ -583,8 +601,24 @@ void viridian_time_load_vcpu_ctxt( vs->config.as_uint64 = ctxt->stimer_config_msr[i]; vs->count = ctxt->stimer_count_msr[i]; - if ( !vs->config.sintx || !vs->count ) - /* Reject enabling with a zero sintx or count fields. */ + + if ( vs->config.direct_mode && + !(viridian_feature_mask(v->domain) & HVMPV_stimer_direct) ) + { + /* + * Old Xen didn't support direct mode but it could still be enabled + * in the MSR. Disable it now to avoid unexpected behaviour. + */ + vs->config.direct_mode = 0; + } + + if ( (vs->config.direct_mode && + (vs->config.sintx || vs->config.apic_vector < 0x10)) || + (!vs->config.direct_mode && !vs->config.sintx) || !vs->count ) + /* + * Disable if sanity checking direct mode / sintx / APIC vector + * fails, or if the count is zero. + */ vs->config.enable = 0; } } diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridian/viridian.c index 90e749ceb581..90be5842b995 100644 --- a/xen/arch/x86/hvm/viridian/viridian.c +++ b/xen/arch/x86/hvm/viridian/viridian.c @@ -78,6 +78,7 @@ typedef union _HV_CRASH_CTL_REG_CONTENTS #define CPUID3D_CPU_DYNAMIC_PARTITIONING (1 << 3) #define CPUID3D_CRASH_MSRS (1 << 10) #define CPUID3D_SINT_POLLING (1 << 17) +#define CPUID3D_STIMER_DIRECT_MODE (1 << 19) /* Viridian CPUID leaf 4: Implementation Recommendations. */ #define CPUID4A_HCALL_REMOTE_TLB_FLUSH (1 << 2) @@ -185,6 +186,8 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t leaf, res->d |= CPUID3D_CRASH_MSRS; if ( viridian_feature_mask(d) & HVMPV_synic ) res->d |= CPUID3D_SINT_POLLING; + if ( viridian_feature_mask(d) & HVMPV_stimer_direct ) + res->d |= CPUID3D_STIMER_DIRECT_MODE; break; } diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h index 99c40b4287f1..4db5142970c2 100644 --- a/xen/include/public/hvm/params.h +++ b/xen/include/public/hvm/params.h @@ -159,6 +159,10 @@ #define _HVMPV_cpu_hotplug 12 #define HVMPV_cpu_hotplug (1 << _HVMPV_cpu_hotplug) +/* Enable STIMER direct mode */ +#define _HVMPV_stimer_direct 13 +#define HVMPV_stimer_direct (1 << _HVMPV_stimer_direct) + #define HVMPV_feature_mask \ (HVMPV_base_freq | \ HVMPV_no_freq | \ @@ -172,7 +176,8 @@ HVMPV_hcall_ipi | \ HVMPV_ex_processor_masks | \ HVMPV_no_vp_limit | \ - HVMPV_cpu_hotplug) + HVMPV_cpu_hotplug | \ + HVMPV_stimer_direct) #endif -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:15:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:15:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408566.1641075 (Exim 4.92) (envelope-from ) id 1x2Uhv-0002f9-Ra; Fri, 04 Sep 2026 14:15:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408566.1641075; Fri, 04 Sep 2026 14:15:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uhv-0002f1-N2; Fri, 04 Sep 2026 14:15:55 +0000 Received: by outflank-mailman (input) for mailman id 1408566; Fri, 04 Sep 2026 14:15:54 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uhu-0002bb-MT for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:15:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Uhu-00H9Wx-39 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:15:54 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ad299-2eae-0a2a0a5409dd-0a2a450aba1e-2 for ; Fri, 04 Sep 2026 16:15:53 +0200 Received: from [52.101.62.35] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ad28e-f2d2-0a2a450a0019-34653e23f6ab-3 for ; Fri, 04 Sep 2026 16:15:43 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by MW5PR03MB6957.namprd03.prod.outlook.com (2603:10b6:303:1a8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 14:15:39 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 14:15:39 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=N4MibUNStijVAbBl3lEuyqWbio0M2eadhCXsILbfy3VYdItVWB9fba8pDJW3rUiPmmEs8SyXzANMJ+3DLkIxKPHAUoKkbSYxiVlN9EUrk5u9n7RNOzbf9pM8xji7b7Fb+mU9tP6vJuwbA7R507QzBRZ77qA1Dn9YUYeZZmmDjp+Q/Ag8bxAa7yOtOgiNjvi8UPXDZEpI+XKbJVXjxQTFtAOUVxxyQorajGCjY4331xmFYwBbuw4QTDNkk1iznELbGvX40uGqpWn5XlulpzwYM92gi7BjoeOma6ZSRPi0R79oj23Hv+tkLapf6TijaM85/yRHFwBrS2JGa5BXksNhYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GciZW9ECljd9rNpwA8gaFSi7EI+SgMi2NmfDY0Gfoqg=; b=DScnDJa407pDB0vR8dHRrVrPmmjuasx5btNEZMlpPOsi+MIF+NWldv1Vhnb1HVpoUhxX02i2xXa71S6/vwfKhOfabES+GH0DRY3B+7WukRQmpRpTXH3J5kO7We86R6ya3lN22l/fNZpuw+ZOFYdh9jZwh7MQHZIE2zxt9TeEkGB+kDzaJPqHqH/nbVxHu/jU6TaVYWHVdsdfdYsViw4/fYAn6ozVohqDFJEAZJOXiEQ2K5KfiG9PSJs1V33d5mmGVy1wRsgYZzmhhWLppt11V5OVDC1jN7igy9FZ/71JSJW+04ZSBtxPzMhQau/Qly66pBUYTc/GjFFHCKLN4ApmAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GciZW9ECljd9rNpwA8gaFSi7EI+SgMi2NmfDY0Gfoqg=; b=rTpKYcjfodEl3YU0RQPCd5nD4tMQRs41JlXkWxTikULsjto3m0iXcRFd0+2zjI4P1Df3IwH/1uC0dPwSxskrdPzr58LZ7ddOgBBG0w9dMeoqDE9/nNU0+3fQLdHReFYMJyNUaC19fH/deec0H5cUtwZPQDc/C6799jmmHSuGVO4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Anthony PERARD , Juergen Gross Subject: [PATCH v2 3/3] tools/libxl: Add support for Viridian stimer direct mode Date: Fri, 4 Sep 2026 15:15:16 +0100 Message-ID: <20260904141516.367862-4-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904141516.367862-1-ross.lagerwall@citrix.com> References: <20260904141516.367862-1-ross.lagerwall@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0267.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37c::7) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|MW5PR03MB6957:EE_ X-MS-Office365-Filtering-Correlation-Id: 0d69cbc8-9a61-4394-ad48-08df0a8eff13 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|6133799003|10067099003|11063799006|18002099003|22082099003|56012099006; X-Microsoft-Antispam-Message-Info: I6suOUyqFOknWpI3ZlKXQoMp3ZcVewiVLvSW/7goqnIwbwSraP8s2+JR0sI1YFOpzvb0nuKcUIkzfzG6+bkvPo/lmphmKKeQtzOTNCqLBK+VuCtlyMe+Wn7Hw4IoqjxacP+BMLBsH/U0kUcsnvx1SKOrAmvX3qWSnyJUCT+jTaUuvRrrF5SHASPhIkpQz7I5mN0gt2oNlJ0InqbknbRj/+m1/Jt5brq6MfF2y2QU12eSi1qt62nRI+5wRLsiKnbCcjU2RjN8wfZYa2/gxA+hnq1+ivUnA5vBukBuF7iPvRLkxjUjaZZV1lcl3gcCOpOPt/0UZQkE8Nb5HOIajRB7C+DF1tmL1z+pdckQcJdAhUin/h+6UAzOMAauCbCQg5SmPozvGsW1NVH4aSpZyaTt8p6+W2RC/rQqJ5C9XCfuuqxw37JSdLJ9UicdHWEhW36/t38w4zZ8kGHlZOAWPRX9eSV+S7oGxSl069bngiwbURZZM6Q3kEpr4vLknFS5OQY9HTcljtgVAQNexAyQ0aQSf9cTATgCulsEVSWoZvV4QEMvEPn3KLdJhSf6o5iCT89QvcYuliM7xtA8Qg4gzaLEVJ1AGuhmocrZ6K+PFJppfu3jLoqaS6n5OW6TCSp02KhkwWwdvpC/Kj/FfovM/21i3MspQDIazkkkQLfNcCmuZRg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(6133799003)(10067099003)(11063799006)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?sY4ZbLdxQX8y5zbqxrX+9gWg2qK3l2UNxkzrEwtn6keUSMpHJeNA7mHwsEjf?= =?us-ascii?Q?fBi5Rpdr5FUi4WMkBxxeN2tsUk2VtFKzkz6UOuRRlyO/QgkseoJC7EQIwZh2?= =?us-ascii?Q?XlfzX/+K+HM7AWczy8XC7StYYlYXcpYTMATCJJ3CELeb1HddFOBUgZFu/Cs1?= =?us-ascii?Q?Cg11mq4C2V1HUg+jOeVjo65dZpiQ/tJ9eJAE3ex4rHPiB7kTvSO7Hi/xru2I?= =?us-ascii?Q?cn1edphUXKS/6NuGB3V5d1ETmpL57QaTn2purqQ2xBeMpEz5YEh4oE5y97QX?= =?us-ascii?Q?SQh01wxnseIaKszgipV1G8TAX8q9gquRkxwRGCr38hP4L/wIzour1ZX17PGH?= =?us-ascii?Q?AEeZba5PQ4QrsobHNpN3q7mt26mblaunOhwLlq0lYVNNzunRZD91G4rqEs0R?= =?us-ascii?Q?OvLxIq3l1M47f9LqPH4l5lbIGLpGTDExdG54pqOaF/HdrUPqo5AOQ7qNBvr1?= =?us-ascii?Q?VT9fSeiaigWWZQCvkQ3XeUIBd5wEUG0snztm2cu3RZ2e3mwOe0VIXjype/AF?= =?us-ascii?Q?X0S0FYwMEqolMDIP6bRHg+5p4EseJ5qqlJfJI9/SCIpz5wg6qiyLXqOyNagA?= =?us-ascii?Q?uNzrRmHcStgN8tflM82m/q1s6FSf1imPtZ4o7eMBvBgETjN5LCJK4cdo+FfE?= =?us-ascii?Q?MCiEVEHTSAc3OMQz1liLLk5/KC9s1w+4O2XAK6/4ixsDiLhtzQCmWa53Wfy6?= =?us-ascii?Q?N+I7+gJGbXhueJdSF0fVPiJmmxu8Wpu4e0vLRVXkVPN/q7JSgzT4e0FwkyWd?= =?us-ascii?Q?YJJoHBbNN0EgacGtdxlLkWkrV7kx4WlaospdnLhAgooMyBF0NwcnOn2FNOa+?= =?us-ascii?Q?orqWQlckyu0C4fH4w/szEI8FkNdb9u8981n6q0DKKT+E6cYnWZjPDnTkznao?= =?us-ascii?Q?bXkPSthttGvEwKQ5TK8vXn5Ux3ghgQLMJU6ldLtuytek7reyHFmPYHy2eUDq?= =?us-ascii?Q?5gfGM4XpUVNQMPij1BN0R5qm6dCRf2GxID1DwTcHl6yoxhf8rWjbdCwF2PAt?= =?us-ascii?Q?3nSQ1gw/asvskr8ojqm77P8Jev22qm8zCypa9E7KaHVrn+Dxt0o11SGbMN+R?= =?us-ascii?Q?TupbeYBU57sg2GJ8lfgGPATzDBDXD0UoDygFes9yv0eFj2yrnOYhW34CsQXM?= =?us-ascii?Q?j7fyoh5WGfvMUMggamt9Eb7Px2YdfZUg+Q6/6fBgdpPhVT6tWaQt79+GkLv0?= =?us-ascii?Q?sNSWaFTLHR1RIqpAsOUwh83zJduCrk8yFebbSV3ykHrhwuAxigvrHg3QQZ01?= =?us-ascii?Q?3sRLrXXBDmDNfeu+sPKM2T/fAK6l+bUelEEXh2AE59MdszRxKlMIrxhFh3bM?= =?us-ascii?Q?DdZvj6EgjGzf6j5igqhKPv8gVv/RDYzvi/R75e7ZnxeM/+7Ps5XwGrB//fh8?= =?us-ascii?Q?todO1y3IiTfGIIstcmcTSUZ7bNmhZy1D1qQG1hGplGfWJadnKEgoEwaSqdNt?= =?us-ascii?Q?Ib9l8lVL6UAFKjrTZrac73+pIdpJNFsp4hrI5m4GrrC9qtjF1O7xkoBV6BzN?= =?us-ascii?Q?F3C1P80jujJZDNow6RLytVS5T6IXj09M32rhazYdSyBs1kX62ELFnlmjOEXP?= =?us-ascii?Q?o85FgQmUXiiLtI8AGDWV5M9qWqFEIqCqvzFbz0UXdrhdzXuVYXH7F+E/epDQ?= =?us-ascii?Q?4SF1sHm0Qm/X9lORsGeQ/zQqolAlabgrOIOp6uFJZed9SgNkbbyRvKN33V1i?= =?us-ascii?Q?VHeQWcQOxDilL86O24R7hBufVTKXUFjz/CtNKZZFGKQT3Wnp2XDFMSzd/WWS?= =?us-ascii?Q?UvVrzhar46C63a41mhkKdIRPHqqDyQA=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d69cbc8-9a61-4394-ad48-08df0a8eff13 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 14:15:39.1659 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: KnX0NFx4INzq+0W5qC7bVJhHN1u41UBzmY8kttV7SVTqpMS/REkJohNxexk0Tvt5iEYoYcXqje9FuEE7nQ7wORy2hErncyAJWyeV9vIY0b4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR03MB6957 X-purgate-ID: tlsNG-4011c0/1788531346-58FC6CFC-D793F6DE/0/0 X-purgate-type: clean X-purgate-size: 2779 Add support to libxl for using the stimer enlightenments in direct mode. Signed-off-by: Ross Lagerwall --- New in v2, since the new Viridian flag was added. docs/man/xl.cfg.5.pod.in | 5 +++++ tools/include/libxl.h | 6 ++++++ tools/libs/light/libxl_types.idl | 1 + tools/libs/light/libxl_x86.c | 5 +++++ 4 files changed, 17 insertions(+) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index d34951edb98d..784e926c9990 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -2496,6 +2496,11 @@ ticks and hence enabling this group will ensure that ticks will be consistent with use of an enlightened time source (B or B). +=item B + +This set is the same as the B set but additionally supports +using synthetic timers in direct mode. + =item B This set incorporates use of a hypercall for interprocessor interrupts. diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 7c098edab663..5475530a5002 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -381,6 +381,12 @@ */ #define LIBXL_HAVE_VIRIDIAN_HCALL_IPI 1 +/* + * LIBXL_HAVE_VIRIDIAN_STIMER_DIRECT indicates that the 'stimer_direct' value + * is present in the viridian enlightenment enumeration. + */ +#define LIBXL_HAVE_VIRIDIAN_STIMER_DIRECT 1 + /* * LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that * libxl_domain_build_info has the u.hvm.acpi_laptop_slate field. diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index a7893460f013..95075f04fe45 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -260,6 +260,7 @@ libxl_viridian_enlightenment = Enumeration("viridian_enlightenment", [ (10, "ex_processor_masks"), (11, "no_vp_limit"), (12, "cpu_hotplug"), + (13, "stimer_direct"), ]) libxl_hdtype = Enumeration("hdtype", [ diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c index 60d4e8661c93..9e8b48372d63 100644 --- a/tools/libs/light/libxl_x86.c +++ b/tools/libs/light/libxl_x86.c @@ -389,6 +389,11 @@ static int hvm_set_viridian_features(libxl__gc *gc, uint32_t domid, if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_CPU_HOTPLUG)) mask |= HVMPV_cpu_hotplug; + if (libxl_bitmap_test(&enlightenments, + LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER_DIRECT)) + mask |= HVMPV_time_ref_count | HVMPV_synic | HVMPV_stimer | + HVMPV_stimer_direct; + if (mask != 0 && xc_hvm_param_set(CTX->xch, domid, -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:28:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:28:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408624.1641084 (Exim 4.92) (envelope-from ) id 1x2Utq-0005pF-S6; Fri, 04 Sep 2026 14:28:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408624.1641084; Fri, 04 Sep 2026 14:28:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Utq-0005p8-Nl; Fri, 04 Sep 2026 14:28:14 +0000 Received: by outflank-mailman (input) for mailman id 1408624; Fri, 04 Sep 2026 14:28:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uto-0005p1-Sm for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:28:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Uto-006Txf-80 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:28:12 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ad56c-e002-0a2a0a5209dd-0a2a45048042-30 for ; Fri, 04 Sep 2026 16:28:12 +0200 Received: from [52.101.43.66] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ad57a-b57f-0a2a45040019-34652b4229ec-3 for ; Fri, 04 Sep 2026 16:28:11 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SJ0PR03MB5744.namprd03.prod.outlook.com (2603:10b6:a03:2df::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 14:28:08 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 14:28:08 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PvFNtMGZklJ052V3U8+H2sCrRAhL+mqdZ8SWpba/WzDyySwnhl0jpbh0gp3BAUmeslYHTGrbzYATX1TEu6k+rMUg+sJJbkb6RFa8QhvNWU+ufyW1lzv3qdk1snwNnyw/bLMDoYVNGFeMaEXaeyboLhVrTcRd5UzAozL7DuuwrKGObhmK3Z4+VoFmj3+8u7ajFfs1bORgnnk+1+lFQU1G7WkOuOUzA1tdVcyRoKdJik5aMYuZvpwAe+Q90nmdYyLj62sNkbU9SqlyN6sQ0MflxwKrT5183dEQK4VqcKru+evC9cE7PDSy2VU4E3Wq+t+iGoQ109JWDdntAcU4Yp50wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WG3EHvt5kN23gToKWT482W/P12w4LccgJjBIvavAw6A=; b=zNnd1M6340bdWGKxi18s4/RGnf+MxPYi51wboiDeP25+l/+zWDp8WrShy89t59YVRf7t/+MO0r00tA97DAZyVDuiE3Av5kjLheZg+i6mWamzdDHmZfvtzN72y/AQzg1rbj+NESDAan7CpI6oy/Dodqr95LvWb6q4XuQ70ufwlh+SUhaXoI55wSJSpg1reAMenm3EEXDV9ePol8agENn+sOw0v+xcUpNH85c0L2A3mxDraY6l4fX5RC/97MMGnZSgwjK/ajfclaB38DA3Gxi2QYUbKkjB508Ub5b3HxJWIyH5SCCpjRY7PXTL/0Qp5AbyTFWLtq/BJ66mDN4w25l3EA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WG3EHvt5kN23gToKWT482W/P12w4LccgJjBIvavAw6A=; b=jNMKJkoicfyLKq+5t658fRur2mL/nlfX36X5stVHuERx8JVxRa246Qyxfl5W2v4vqlaqcAlCQQEax47TGdUKOtGaX7e5pQ4UjJ2K+Kqkk2JUCblphPOwhlFzGORbAcUUa6t5E+JPgKRCCyopautiO1QAOGWuc0pCjoykMUfnl2E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH] nestedsvm: Crash domain rather than Xen on unexpected VMEXIT Date: Fri, 4 Sep 2026 15:27:57 +0100 Message-ID: <20260904142757.375773-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0489.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::8) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SJ0PR03MB5744:EE_ X-MS-Office365-Filtering-Correlation-Id: 820d19fd-2db2-459d-2ff6-08df0a90bda7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|56012099006|10067099003|11063799006|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: t4OPSOpVFSTJ+45CnrX24uyKkXg4NO3/qx7xK0ks7cqOiJoRRyLacMtU1Z0y9dUn+jwPccDY1aClDCc2IWrOC/Jxgbo0OMHUA10OXX00frHNqv4hKbC0SNBr7C6JlycUOw1jpM/vE25cR2cGXC9ToC0Jvb4/qS4NCORQd0HOE0tZudiKdlYYgwvrK3txA/b9JtBb2/06motmahNVHAdoC6CrNqqnK8Xzz8zVzn8lF6wNoRj0CX2pLcBTeJcZGaYYmdFTUhMKeoPDM/qkMyuEXQIXO/W6ilIMZKc0d9MkJTfGP1wFISDOJMB8DMFCjezCc363QL+YpxT25mdV4FDWHSrfMBuV747lDL8XlrY0U1Wqe+k65YPzPpEvjSHoyB3tBGYlU2S7ppCJb7r3dIbKH1xnGP+BJI2aYQghN96yMqvqCpMGQt4LAF93GYNWsqIQ2D0iHW3DCRaDz0zrix5Q89KJQzDQIX9//Ve2n8r8Olcp2HY3rmVtYLY2Ra3i0/gYsqwI6r3t+7Jxk3rUPkkq+MwPpGczeackwD029mbtOBlJOKqYb/vch0rRMP9OhKBVySsd700YrDyuBv8e9gXiuJ4Z8OPrX8ZHqsysUy7gwqMXdiGf7WHu9fiN/y1u3x+oKkg0B1W5efRnd3e3UXRJvmeqKKg9ClvRrt9UjafGusc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(56012099006)(10067099003)(11063799006)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2ghKWrCYlriupcO3e8KGu76qi/P+WxkNtGtWIf4gOats7bT61RWxE93gtP/K?= =?us-ascii?Q?tMbbE3bgp43zPsTyU1WaXFKCgQTzqJaVdbL0N3GklFBPp+CK3pJ3L1wZ+YVC?= =?us-ascii?Q?DZyADF36yeURvp3k/ojhZVmhhF0cHaPu0Ycl9mtCLmFX6wWg9Srm2+h6fWxX?= =?us-ascii?Q?IYtrycCiiE9Pbl7mKWTG1Yxh3udp8b5/6QalU1DqGPOQpdpBUhJgimuXmVuQ?= =?us-ascii?Q?5jEafMmhywUWu9ws1c56+Vzt69kJ8kCYx0DKJR75UmhW6PZe3LAS5KAt/eMQ?= =?us-ascii?Q?gdkRqapkT366ChTmLiMqLtEDktZYcKDBjJEbAdkaMfzNyjypB0fxMvJ64kh7?= =?us-ascii?Q?YhNbyXnVTBHkuHUgA+Rb9WwiEAynXSo3cCqu8YtOsZ82f1b9aRFfKDa4L9L+?= =?us-ascii?Q?yMTT2iDLkDoXQ+r87y21/oS2REvc89HCqFpLyBJHYWXclX981WOoskZMM6QA?= =?us-ascii?Q?dlXg16hjIiIdzVLhTQabBKZaUFDzAXM1az9/gROlU7OhGu7YgwNdzuA0ZeWq?= =?us-ascii?Q?7xQIXY0cU0iFittX4vazPhvvdYIujU7iU7enT3P02vKJk8uXIhz71WNuyRrM?= =?us-ascii?Q?yNaP1i0652rHUSNdlEQTx0K6MZ9CZT8BYr7J2RdN0Gh6r7o8sJwziIj4f8lJ?= =?us-ascii?Q?R7dzU99/X4Ak3npoq1eWOkGRnBtQ7FQ6fSGQJ7WWoB/PXkLhJBYUuC5fPOJr?= =?us-ascii?Q?c+zdZDo+E+rRQxJzh4SxDPH1ufFn4DyMU02c0c6UTq4Yuqd47U9LvyhmHP+9?= =?us-ascii?Q?wRou2UvlMX//j8A4pGPUfvqcqvGiqZbAbDEl6QeoLIqe2LRNNMrbmxLtCeKb?= =?us-ascii?Q?3FgtRItnqdOljWVxhrPSM0m48Ooe81ThFEfYoSrLiG0KyIF9Vll70fr9Fm7k?= =?us-ascii?Q?zFrC7sIj78SP09neGJzUADGnRQgMbDwn3QladTP/jUBBgbY7ScH8W1SAaTh7?= =?us-ascii?Q?m1LG9OUJmjPWBpup6mo4uFDxPmoqZ9F6U4tvMPHeEaKqpnesRJLSubbqswzo?= =?us-ascii?Q?nMEH64ZR2yCGY503dVu9MgOPe67z62/26CjtY/RcqeRTyRtN7qHzjsY0qgjK?= =?us-ascii?Q?RS0dmm01VBQzSGLgigDet161O4Pjhq6jRnRq0hwH/8ddnDIFoacOEacOb+hF?= =?us-ascii?Q?H6tmeAN1GsArag1AGWylycrnXOsfoFWZvJYuYpbC79RJsQ6AKq+60YbUg3OX?= =?us-ascii?Q?pmwHEq8ReyS6aJBx/mgvBXvIHdMucvvOMPAoedDy2jN0sm8qKuwI0d2vtsyK?= =?us-ascii?Q?B1QQp5Dwjga8v4JgmtFOwQCYUiCIqCKb3QwX5N0l/cKbdIuq9ZUWwlkBmwLg?= =?us-ascii?Q?ApYXKQgKsCyRnOS+plyhB3uo6WSK7pgb9ehfnTst0WNiwyWRUbgdc66eEAIk?= =?us-ascii?Q?sWEvS+yvyas5asyajl3A7u4omQ8c899O0siO8Y8YtI7ewOH+/eIT1yfkLHpx?= =?us-ascii?Q?02fFaV2fOqOiSbPZJ08JjMLmD3KPRMGFmNWdRz+DU+781LHdda2JVsC2xsKV?= =?us-ascii?Q?RRgB8VxZ8co7bDrLmgzz1FaC5dBByteMySVNihmfGNjOFzEWayfXk93eRdJ5?= =?us-ascii?Q?Yt4xnfgt8arP7vONDZxOwF3AnQS+GigVZc2juQOeOILgXDT5JLasdu2vcz4E?= =?us-ascii?Q?tYbTOJKBQr6RVIEryLu9AZNZhRkxixJk565eiwvX5YFV7ZJhoZjcWX4rqwiQ?= =?us-ascii?Q?eUQZqndqROlrcg6sOZBQIBZfm43tIWOMF8SN5LSVcvORNzv6NjDRVfJK6p+v?= =?us-ascii?Q?yPIxgRI+cQxlK3ALz2McEprkW/RjSqU=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 820d19fd-2db2-459d-2ff6-08df0a90bda7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 14:28:08.4280 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: LEhKldhhP0uxHodl41qCz1+Mgl11nUvwNlva2WxxGJhXnGFwG/btsEa3a5Xwlhjfa5RIwoghrr1X1PaWWZVuOTK6zw8ieH/+SDo/Lt4ZyU8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5744 X-purgate-ID: tlsNG-ebf023/1788532092-516D2B50-A8ABE61B/0/0 X-purgate-type: clean X-purgate-size: 1013 On encountering an unexpected VMEXIT (e.g. because L1 has used an intercept that L0 Xen doesn't know about), crash the domain rather than the hypervisor. Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") Signed-off-by: Ross Lagerwall --- This can be triggered running kvm-unit-tests in L1. Xen undoubtedly needs to handle the intercepts properly but as a first step it shouldn't BUG(). xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 3d0e77f5eb24..5adb1bd72c4d 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -923,7 +923,7 @@ nsvm_vmcb_guest_intercepts_exitcode(struct vcpu *v, default: gdprintk(XENLOG_ERR, "Illegal exitcode %#"PRIx64"\n", exitcode); - BUG(); + domain_crash(v->domain); break; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:28:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:28:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408626.1641093 (Exim 4.92) (envelope-from ) id 1x2Uu9-00067b-31; Fri, 04 Sep 2026 14:28:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408626.1641093; Fri, 04 Sep 2026 14:28:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Uu8-00067U-V2; Fri, 04 Sep 2026 14:28:32 +0000 Received: by outflank-mailman (input) for mailman id 1408626; Fri, 04 Sep 2026 14:28:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2Uu7-00066r-Gl for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:28:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Uu6-006U27-Td for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:28:30 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ad574-e002-0a2a0a5209dd-0a2a450bea5a-48 for ; Fri, 04 Sep 2026 16:28:30 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ad58e-b7e8-0a2a450b0019-d155802dc45f-3 for ; Fri, 04 Sep 2026 16:28:30 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49a97714f5dso8954065e9.0 for ; Fri, 04 Sep 2026 07:28:30 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce5533ffbsm157930585e9.3.2026.09.04.07.28.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 07:28:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788532110; x=1789136910; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=pD7OeTsKlgp5Zou4D+LlQhgrAakl+ESpDfDKraMHwT8=; b=JhcA+DOf+43Bru8FKKnKT2CwQ8TH8/VfHgyIZvwuzF7AMnkgAYKA8ZyrfHRXJQFdkD 9oAi5CWDYiV/LOPyIKIkFPOya9hq4MHVCgIEJscRAbcm5zGCQ+2G/JPSCuwktnVFUdVP yFfNXluZGVxPjUdGzT3uxFIUoZqWSWmvj78dkHK50KD9cSnqsJyf9/02fS0y5ZRKiiA3 bHtauT8Fj9WN524OTiCJLRlnAbtHOMwQofXQgeZuCsr2/pvBxYMzVxGOWP68jEi2IXsd hlExsFE+dxZMPT/yDioFLJYeAQL1Kshf89YkdBy047vobkAuPBOHswIbioQR245JgUqv nP6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788532110; x=1789136910; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=pD7OeTsKlgp5Zou4D+LlQhgrAakl+ESpDfDKraMHwT8=; b=aMcWV5c7/qfIIMqXrseK2sFgi28fC4AkIx2ECNfE7Q6JeGxYK/u04/97js+pHxrp4/ RP+IiZKCrIv3vmZNG7r0c62wkiHScPdatzoQQ8jZfYbsegtDzoJaiQaXOHLQO+XlyEdf 2CIvb61ExWGe723cSOMWmIuxw0F12wAoo1sYTuWVIuHu4i4++YsvMKHG5HRvfJGdXiK8 9y6USm1nBmEXD3Dl3CQiEs4H2PDXPOYwwGPy8HqUUWr51nDmuCovCWFbyCYF4VOkxLRc kZSDuqkyqQEDLLnbH5wtFl72JOmFQBjrDnlMUTJHfLjyrCN8LCEmlI9F4jFQqnOn0GXB vLqg== X-Gm-Message-State: AFuF++nEQzUhk4TCFejnFKRIA5yjvMsz2Y2fnwFOgpjp0RbmRX/qg34C m2bEbUH+x2qzd33W09RXsdoOil3rDNT8+VGYkrJAppZkgjouNa8+/6fO X-Gm-Gg: AYBFou3agCPtkU+VKEzfH8LsUQtM5YR7igFcM3EdZBK1i/EhZtwz/I0nIO214A80wgf 2fTrJLAtLBXQ6Mm+o4ukfWSRcjnMphG1dL3gM+8/PNET9fYVdlpyGFihhIcj6Cq4emOKW6MV2oX IZ8KfXep/DUVZlWzHqkFYqNP19FFNsv5KzUWxuusgOwbLxL5ufk9H6gtY7CvVkoVRmxeVj7hecR HECZ5xqS/GuaIXalRmOb8uyH4RUQ8XgFdgj6cdiWL2B0+y8Y6j5V7IWq3nZRbN5YtD+OkSM7lAT WkCJFzt+6/WQxjK6c6MOPwjvH8vWVRDsCyfqphHcB7lQ05RVFTKjjr3L+UN9eZVMGtfFQag9RcF l24mgnp2x9fxpa5gFYaC2w7w9+ZCcJqhfOMzByPT0+rMruUxk+PUB+MTHR12UFrFxjSeGYdae5u xTM63/btOx2fKI+OWW55VNhfA2gtlE7aYF5BJkZpcIMhHHT9NWKrXOduDTGhJjuFYkmmGC/JJDG OsH/wyBtTSMfbim2v/L0QgkVsRiW8fNfqJ1vB8= X-Received: by 2002:a05:600c:8b8a:b0:49c:ee08:6ed1 with SMTP id 5b1f17b1804b1-49cf81eafe6mr68388215e9.5.1788532109780; Fri, 04 Sep 2026 07:28:29 -0700 (PDT) Message-ID: Date: Fri, 4 Sep 2026 16:28:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> <1788510380.8631fc262581453bbf619ec5b2062170.1a06b869ff7000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b869ff7000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788532110-A8ECE9EA-C39BD17D/10/73395122804 X-purgate-type: spam X-purgate-size: 1087 On 9/4/26 10:26 AM, Baptiste Le Duc wrote: > On Thu, 27 Aug 2026 17:20:54 +0200, Oleksii Kurochko wrote: >> aplic_set_irq_affinity() open-coded the packing of the group and hart >> indices into the target register, and got two things wrong along the >> way: >> >> - imsic_config.msi[] is indexed by logical CPU id, but the index was >> run through cpuid_to_hartid() first. On any platform where the two >> spaces differ this picks another CPU's interrupt file, or reads past >> the array; >> >> [...] > > Reviewed-by: Baptiste Le Duc > Thanks. Considering your suggestion regarding renaming of the function aplic_hart_field() in the prev. patches. I will also do here: @ -344 +344 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask - value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | + value = MASK_INSR(aplic_hart_index(cpu), APLIC_TARGET_HART_IDX) | + Update the functions name in the commit message. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:53:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:53:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408682.1641100 (Exim 4.92) (envelope-from ) id 1x2VIL-0003ex-RT; Fri, 04 Sep 2026 14:53:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408682.1641100; Fri, 04 Sep 2026 14:53:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2VIL-0003eq-Ou; Fri, 04 Sep 2026 14:53:33 +0000 Received: by outflank-mailman (input) for mailman id 1408682; Fri, 04 Sep 2026 14:53:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2VIK-0003ek-GQ for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:53:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2VIJ-005HUh-2i; Fri, 04 Sep 2026 14:53:31 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2VIJ-00DU3E-0o; Fri, 04 Sep 2026 14:53:31 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=VjPIlWJ5xUTg8SyViWsT4d84P1/WzUYuP9dRMf7/n3c=; b=D5c3PZpSSdyEV1AwDvgBTcijjk EhvsXu3JJOgF3KZRDVH2RwGVX0Su8315UT0BstwAjrH3/lIa/NTtlughdS2VWNGuGdLHY755SX1EL x/IDg/tX/ch4IGEzoH2x7iIZkqrVAgmKoVKmi5QNrGI/nG7M6zgITigqos4ZmYkc1CAI=; Date: Fri, 4 Sep 2026 16:53:29 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Ross Lagerwall Cc: xen-devel@lists.xenproject.org, Paul Durrant , Jan Beulich , Andrew Cooper , Teddy Astie Subject: Re: [PATCH v2 1/3] x86/viridian: Workaround Hyper-V GP fault writing to MSR Message-ID: References: <20260904141516.367862-1-ross.lagerwall@citrix.com> <20260904141516.367862-2-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260904141516.367862-2-ross.lagerwall@citrix.com> On Fri, Sep 04, 2026 at 03:15:14PM +0100, Ross Lagerwall wrote: > The Viridian spec requires the vector to be >= 0x10 when writing to the > SINTx MSR, otherwise it should #GP fault. > The spec-defined initial value is 0x0000000000010000, i.e. the vector is > 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to > the spec-defined initial value and since the vector is 0, it GP faults. > To workaround this, treat the write as a no-op if the value is > unchanged. > > Signed-off-by: Ross Lagerwall > Acked-by: Jan Beulich > --- > > In v2: Added a comment to clarify > > xen/arch/x86/hvm/viridian/synic.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/xen/arch/x86/hvm/viridian/synic.c b/xen/arch/x86/hvm/viridian/synic.c > index e6cba7548f1b..75b004440e58 100644 > --- a/xen/arch/x86/hvm/viridian/synic.c > +++ b/xen/arch/x86/hvm/viridian/synic.c > @@ -157,6 +157,14 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) > if ( !(viridian_feature_mask(d) & HVMPV_synic) ) > return X86EMUL_EXCEPTION; > > + /* > + * Windows 11 Hyper-V (26H1) has been seen to write this MSR to > + * its default value, despite not being a spec compliant value. > + * Tolerate writes which have no change in value. > + */ > + if ( val == vs->as_uint64 ) > + break; To make this a bit less workaround like, could we ignore the vector if the SINT is masked (bit 16 set)? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Sep 04 14:55:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 14:55:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408693.1641111 (Exim 4.92) (envelope-from ) id 1x2VJt-0004H8-As; Fri, 04 Sep 2026 14:55:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408693.1641111; Fri, 04 Sep 2026 14:55:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2VJt-0004H1-6N; Fri, 04 Sep 2026 14:55:09 +0000 Received: by outflank-mailman (input) for mailman id 1408693; Fri, 04 Sep 2026 14:55:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2VJs-0004Gt-DL for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 14:55:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2VJr-006aIt-QZ for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:55:07 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9adbae-bab6-0a2a0a5309dd-0a2a4503bd40-32 for ; Fri, 04 Sep 2026 16:55:07 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9adbcb-fae8-0a2a45030019-d1558029c10c-3 for ; Fri, 04 Sep 2026 16:55:07 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49b8687630fso10087395e9.3 for ; Fri, 04 Sep 2026 07:55:07 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cf772692dsm88625085e9.10.2026.09.04.07.55.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 07:55:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788533707; x=1789138507; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=XuwzGyb+HHz8yRp5cMVQaFYdTbTINKBzSYHX1XH4Jo4=; b=b/3KhM56aI4lK0ZirckYTQ1wsR4KRlVcWWqxKxBD7kZBPgwjIdiZYgofqVbWbIUgU9 jfUzm8JaYOVwj/gIGhsMLpLJGVWSEJrESaUa8Z9Xv8khKAtj0J4NPgqs1t0rV5sBZ36L z8UYEOolzMglJrhnmpLUH6U1x/GYhYl2eAIzhHGsJQEVxJWO5b0wXZxPM49Ns0teDPGr iZ8u8w+E52gbyhd+wvoGzwpXSk7oPDDuTOMj9K3lftjjhPGxYMfvWyAzLDmebO+9w9gV Nv+8ht1VBUr03lsEG7PPcEzDS4U3DD7UG0lQLBZdkMoLS9e6Vq2VZeV6AkkHy+JdgHsZ gyfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788533707; x=1789138507; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=XuwzGyb+HHz8yRp5cMVQaFYdTbTINKBzSYHX1XH4Jo4=; b=FTk2OZdORVl7ge2m7vH0qauOPMIBnhyc1x7Dx5ZvUmudoDlUqMLlnxd9PSeHe7mTLn BTlOIfwO4IxHMqDWvunOl+8UAQ6OQ7WlgLzO+5LsfltFNKiSVpOua8RBFnXO1sQOTvpL xTSK1t7oJ78JzgmzQJysBNGDqosDdz3Y3MTSNe7KoH7XqhhvPbVDQDIGIdvDYWr7AH8+ rPUAjNwGWI4QllfJIZZ9/OMrfgCM0yPPH+c9jcEX8SGd6Q7hPsNIkl31O75IfoPfgDXP IeRwICR/mRCMvBCQQoAoFmJoqUoAd62826zlTYbUlYSCYo3mhsYyvWZxUAZnzZtJZcnb 4Xpg== X-Gm-Message-State: AFuF++lM1gaDaeJkltg7KLaSkLk3WsulYMUDs4gU0H7Z7IfruxZaFLEp jaTQcTW1Z4HPRZbtzHc18mrr8t3m/BSybhaI7JTiJqEn6FBc6grp2nAK X-Gm-Gg: AYBFou3aZ93JKdZuDU4sSQVTAd0jyjPE8xJlcgd8J2WcRKoBvmnd19pzrthS8JV1Ron 6liQgweyo6vBWecz7HR8alfFApF37OVDtKjYpl5N6+UxW0+0SM20q6fLThqt2BNyejfJloXA2q+ bvYgQVmz+lj5bZMDmwOqAVoavX40FdQoMV1dumxhT3E3PrYWUK7+ORV3z6WyaDlrzikIjSStrvM VTxOwHflCM62t8PyTrt9IFj25IFJsvKihxr+qtf/Mr5mpdS/KtoS4eG4SaRe7VVxvF0J+kgWKy9 YJYdFRxqUl1P1AsXxYMKhtM23YaiBv6eD95eYlobmv4myc3UdtOqmOxBQDOK/bzVDcci8wZO3/8 Ro5HhjQbKJTQ9oYVOMElyyD+W0yf9UCTl6XS52vBpNe0kZtQFNLEmL4u0gnCWfM/lO37HPzBiV9 z/jBvgUSOZOCymXBBY63Be5GDJg9e9S9vuZRNE0UE0pdc5vfYmo0ZglPP6Pq1E9SIskMZKQQfl0 FJZcVGEMykptTSXj/a+qlZhRhDIOizIM7OntGI= X-Received: by 2002:a05:600d:848a:b0:49c:ff20:451a with SMTP id 5b1f17b1804b1-49cff20452amr16081905e9.27.1788533706660; Fri, 04 Sep 2026 07:55:06 -0700 (PDT) Message-ID: <91c9abf0-a25f-42d0-9d55-61a9cc62e233@gmail.com> Date: Fri, 4 Sep 2026 16:55:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788533707-6C8DD4E9-DD442570/10/73395122804 X-purgate-type: spam X-purgate-size: 9907 On 9/4/26 10:26 AM, Baptiste Le Duc wrote: > As I understand it, a generation wrap doesn't retire a single VMID, it > resets next_vmid to 1, which makes every VMID in 1..max_vmid reusable > again in the new generation. We do a full (local) flush at that point to > avoid two different vCPUs ending up with the same VMID valid at once, > across generations. > > If this is correct, doing a full flush there also throws away entries > for the current vCPU that a local HFENCE.GVMA(vmid) per retired VMID We are doing flushed for the pCPU on which a vCPU is ran. > could have preserved. A local-flush-per-VMID approach could also > reduce how often we need a full flush at all. > > Is there a reason we don't do local flushing instead? I see x86 and KVM > use the same flush-all design on wrap, so I assume there's a reason I'm > missing, I'd like to understand it. What do you mean here by "local flushing instead"? We are doing local flush: if ( unlikely(need_flush) ) local_hfence_gvma_all(); Do you mean why we don't do hfence_gvma only for specific VMID? A vCPU's VMID is valid only while vmid->generation == data->generation (vmid.c:141). Bumping the generation invalidates every vCPU's VMID on this hart simultaneously, so every G-stage entry in the TLB (whatever number it is tagged with) belongs to a (vcpu, vmid) binding that can never be consulted again. Each of those vCPUs will be handed a fresh number on its next vmenter before it can run. That includes the current vCPU, which is the case you're worried about. At the wrap it is being assigned VMID 1, not its previous number, so its old entries are unreachable regardless of whether we flush them. hfence.gvma per retired VMID would preserve them physically but not usefully [A concrete example. vCPU A is running on the hart with VMID=100 in generation G; the TLB holds G-stage entries tagged VMID=100. A wrap occurs: the generation becomes G+1, next_vmid is reset to 1, and A is assigned VMID=1 (vmid.c:154). From that moment on, the hardware looks up translations for A under the tag VMID=1. The entries tagged 100 will no longer match anything: A isn't 100 any more, and no one else will be handed 100 until the next wrap. So A loses its warm entries not because we did an hfence.gvma, but because it was renumbered. The flush has nothing to do with it. It merely discards what has already become unreachable.]; they'd just occupy TLB capacity until natural eviction. Preserving them would require a different allocator that keeps a vCPU's number stable across a rollover (Linux/KVM-arm64 style, with an active/reserved set pinning live ASIDs), not a different flush granularity. So x86's hvm_asid_handle_vmenter() and KVM's equivalent aren't doing this out of inertia — with a round-robin generation allocator, the full flush is free of useful collateral damage and strictly cheaper than the alternative. Preserving entries across a rollover is a real optimisation, but it's an allocator change, and IMO worth doing only if profiling shows the wrap flush matters. > >> H/VS CSRs, virtual timer and P2M context, and __context_switch() in assembly, >> which switches Xen's own callee-saved state (and thereby the stack) from >> prev to next. Virtual interrupt controller context switch will be >> introduced later. >> >> Add offsets of struct arch_vcpu's xen_saved_context to asm-offsets.c for >> use by __context_switch(). >> >> henvcfg and htimedelta are 64-bit on both RV32 and RV64, so store them as >> uint64_t and use csr_{read,write}64() instead of open-coding accesses to >> the high halves. >> >> A hart which drops out of a domain's dirty_cpumask stops being a target >> of p2m_tlb_flush() while its TLB may still hold G-stage translations of >> that domain, and neither the vCPU which just ran nor any other vCPU of >> that domain which ran there earlier has had its VMID invalidated. Move >> the hart to a new VMID generation at that point: a VMID number is never >> re-used until a full local flush has happened, hence none of those >> translations can be reached again. >> >> Claim the VMID in p2m_ctxt_switch_to() rather than at the next guest >> entry. VMIDs are a per-hart resource, so the (generation, vmid) pair a >> migrating vCPU brings from another hart is meaningless here and may even >> match this hart's current generation, leaving the vCPU under a VMID owned >> by another domain. ctxt_switch_to() invalidates that pair, but claiming a >> replacement only on guest entry is too late: p2m_ctxt_switch_to() has by >> then already made HGATP live, and speculation can populate G-stage entries >> of the incoming domain under the stale VMID. The local flush for a wrapped >> generation moves along with the claim. >> >> That leaves p2m_handle_vmenter() with nothing to do, so drop it together >> with its call from check_for_pcpu_work(). A VMID can only be invalidated >> while its vCPU isn't running: vmid_flush_vcpu() is called for the vCPU >> being switched in, and vmid_flush_hart() runs either from schedule_tail(), >> ahead of ctxt_switch_to(), or from the wrap path of vmid_handle_vmenter() >> itself. A P2M change on another hart doesn't invalidate it either, as >> p2m_tlb_flush() drops the stale entries directly with >> sbi_remote_hfence_gvma() instead of retiring the VMIDs which tag them. A >> guest therefore always runs under the VMID claimed on its way in, and >> there is nothing left for a guest entry hook to notice. >> >> p2m_handle_vmenter() also skipped the HGATP write when the VMID it claimed >> was unchanged. That isn't carried over: HGATP holds the G-stage root as >> well, and skipping the write is only correct where that root is already >> the incoming domain's. On the guest entry path it is, on the context >> switch path it is not. >> >> While at it, fix the inclusion order of headers in asm-offsets.c: Xen's >> headers go first, then arch specific ones. > This could have a dedicated patch no? It could but considering that it is pretty small fix I think it could be part of this patch. If you are insisting on moving that to separate patch I will happy to do that. >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c >> index ec327a5e8a..91a46d630f 100644 >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -11,9 +11,11 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> +#include >> #include >> >> struct csr_masks { >> @@ -158,6 +160,8 @@ int arch_vcpu_create(struct vcpu *v) >> if ( is_idle_vcpu(v) ) >> return 0; >> >> + v->arch.last_cpu = NR_CPUS; >> + >> vcpu_csr_init(v); >> >> if ( (rc = vcpu_vtimer_init(v)) ) >> @@ -329,6 +333,169 @@ int arch_domain_create(struct domain *d, >> return rc; >> } >> >> +static void save_csr_regs(struct vcpu *vcpu) >> +{ >> + /* >> + * There is no need to save these CSRs as only hypervisor writes them in >> + * restore_csr_regs() and guest can't access them so they shouldn't be >> + * stored here. Keep them commented here just for symmetry with the >> + * restore CSRs register part. >> + * >> + * vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); >> + * vcpu->arch.hideleg = csr_read(CSR_HIDELEG); >> + * vcpu->arch.henvcfg = csr_read64(CSR_HENVCFG); >> + * vcpu->arch.hcounteren = csr_read(CSR_HCOUNTEREN); >> + * vcpu->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); >> + * >> + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + * vcpu->arch.hstateen0 = csr_read(CSR_HSTATEEN0); >> + */ >> + >> + vcpu->arch.hvip = csr_read(CSR_HVIP); >> + >> + vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS); >> + vcpu->arch.vsie = csr_read(CSR_VSIE); > > >> + vcpu->arch.vstvec = csr_read(CSR_VSTVEC); >> + vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH); >> + vcpu->arch.vscause = csr_read(CSR_VSCAUSE); >> + vcpu->arch.vstval = csr_read(CSR_VSTVAL); >> + vcpu->arch.vsepc = csr_read(CSR_VSEPC); >> +} >> + >> +static void restore_csr_regs(struct vcpu *vcpu) >> +{ >> + csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); >> + csr_write(CSR_HIDELEG, vcpu->arch.hideleg); >> + csr_write(CSR_HVIP, vcpu->arch.hvip); >> + csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); >> + csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); >> + csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); >> + >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); >> + >> + csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); >> + csr_write(CSR_VSIE, vcpu->arch.vsie); > > >> + csr_write(CSR_VSTVEC, vcpu->arch.vstvec); >> + csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); >> + csr_write(CSR_VSCAUSE, vcpu->arch.vscause); >> + csr_write(CSR_VSTVAL, vcpu->arch.vstval); >> + csr_write(CSR_VSEPC, vcpu->arch.vsepc); >> +} >> + >> +static void ctxt_switch_from(struct vcpu *p) > Is it expected to have diverse names for the vcpu arg? Above it's vcpu, > here it's p (I assume it's for `previous` but I think the _from alone is > enough to understand) and below it's n. Shouldn't be better to keep the same name? Above should be used n. It is what usually is used in Xen in such cases. vcpu isn't the best one name in general as it should be v. But for these functions I will use n and p correspondignly. Thanks for noticing that. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 04 15:15:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 15:15:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408721.1641119 (Exim 4.92) (envelope-from ) id 1x2Vd5-0008VG-Qr; Fri, 04 Sep 2026 15:14:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408721.1641119; Fri, 04 Sep 2026 15:14:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Vd5-0008V9-Ne; Fri, 04 Sep 2026 15:14:59 +0000 Received: by outflank-mailman (input) for mailman id 1408721; Fri, 04 Sep 2026 15:14:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Vd4-0008V3-Cs for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 15:14:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Vd3-006clq-MN for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 17:14:57 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ae06f-8faa-0a2a0a5109dd-0a2a450787d4-6 for ; Fri, 04 Sep 2026 17:14:57 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ae070-b4ea-0a2a45070019-a0658309acea-3 for ; Fri, 04 Sep 2026 17:14:57 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id B1B2883C64ED; Fri, 4 Sep 2026 11:12:52 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Abdelkareem Abdelsaamad To: xen-devel@lists.xenproject.org, teddy.astie@vates.tech Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, jbeulich@suse.com Subject: Re: Re: [PATCH v3] x86/nSVM: Check injected event consistency Date: Fri, 4 Sep 2026 16:10:10 +0100 Message-ID: <20260904151014.3113677-1-abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <1787565706.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3@vates.tech> References: <1787565706.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788534897-A54C3AE4-D82F6540/0/0 X-purgate-type: clean X-purgate-size: 4351 On 24.08.2026 12:12, Teddy Astie wrote: >On 06.08.2026 19:26, Abdelkareem Abdelsaamad wrote: >> On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has >> debugging complications, security and performance implications. The APM >> volume #2 15.20 (40332-Rev. 4.10-July 2026) states the two possibilities that >> result in a VMRUN exit with VMEXIT_INVALID due to the injected event. These are >> • Reserved values of TYPE have been specified. >> • TYPE = 3 (exception) has been specified with a vector that does not >> correspond to an exception (this includes vector 2, which is an NMI, not >> an exception). >> >> Extend the VMCB validation to check for such inconsistency. >> >> The collection of the invalid exception vectors are ported from the upstream >> KVM commit >> ("7e79f71bca5c" KVM: nSVM: Add missing consistency check for EVENTINJ). Adjust >> the checks from the commit to align with the APM Volume #2 and Volume #3 >> (40332—Rev. 4.40—July 2026) for the X86_EXC_OF and X86_EXC_BR vectors which >> should not be valid on the x86 64-bit (long mode) platforms. The adjustment is >> posted to the KVM mailing commit patch thread >> https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/ >> >> Signed-off-by: Abdelkareem Abdelsaamad >> --- >> Changes in v3: >> - Restricted X86_EXC_OF (4) and X86_EXC_BR (5) vector injections to >> non-64-bit guests to prevent impossible guest-mode state injections >> per AMD APM Volumes 2 & 3. >> - Refactored exception vector validation from if-conditions to a switch >> statement to improve readability and extensibility. >> - Restricted X86_EXC_CP (21) vector injection to hosts with enabled CET >> to prevent VMRUN failures on hardware without CET support. >> >> Changes in v2: >> - Remove the redundant SVM_EVENT_INJ_TYPE_MASK and SVM_EVENT_INJ_VEC_MASK >> constants. >> - Correct the Injected Event Type consistency check to disallow the injection >> of reserved type 1 events. >> --- > >(...) > >> https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2734283788 >> --- >> xen/arch/x86/hvm/svm/vmcb.c | 51 +++++++++++++++++++++++++++++++++++++ >> 1 file changed, 51 insertions(+) >> > >I would add this newly introduced function in svm_vmexit_handler(), when >encountering VMEXIT_INVALID to attempt giving more information of the >problem (nobody likes to debug VMEXIT_INVALID). By this, do you mean calling the svm_vmcb_isvalid from svm_vmexit_handler or calling only is_valid_svm_vmcb_injected_exception_vector? I see that VMEXIT_INVALID already dumps the VMCB. > >> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c >> index 975a1eaef8..4379bbef09 100644 >> --- a/xen/arch/x86/hvm/svm/vmcb.c >> +++ b/xen/arch/x86/hvm/svm/vmcb.c >> @@ -320,6 +320,41 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) >> svm_dump_sel(" TR", &vmcb->tr); >> } >> >> +static bool is_valid_svm_vmcb_injected_exception_vector( >> + const struct vmcb_struct *vmcb, uint8_t vmcb_injected_vector) >> +{ >> + switch ( vmcb_injected_vector ) >> + { >> + case X86_EXC_DE: >> + case X86_EXC_DB: >> + case X86_EXC_BP: >> + case X86_EXC_UD: >> + case X86_EXC_NM: >> + case X86_EXC_DF: >> + case X86_EXC_TS: >> + case X86_EXC_NP: >> + case X86_EXC_SS: >> + case X86_EXC_GP: >> + case X86_EXC_PF: >> + case X86_EXC_MF: >> + case X86_EXC_AC: >> + case X86_EXC_MC: >> + case X86_EXC_XM: >> + case X86_EXC_HV: > >As you plan to drop #HV (due to being SEV-SNP specific), could it be at >least commented out; which would hint the need for a appropriate check >when implementing SEV-SNP restricted injections. I will address this in v5, since v4 has already been posted. > >> + case X86_EXC_SX: >> + return true; >> + case X86_EXC_OF: >> + case X86_EXC_BR: >> + return !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l); >> + case X86_EXC_VC: >> + return vmcb_get_sev_es(vmcb); >> + case X86_EXC_CP: >> + return !!(vmcb_get_cr4(vmcb) & X86_CR4_CET); >> + default: >> + return false; >> + } >> +} >> + > > >Teddy From xen-devel-bounces@lists.xenproject.org Fri Sep 04 15:15:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 15:15:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408728.1641128 (Exim 4.92) (envelope-from ) id 1x2VdU-0000SM-2o; Fri, 04 Sep 2026 15:15:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408728.1641128; Fri, 04 Sep 2026 15:15:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2VdT-0000SF-VZ; Fri, 04 Sep 2026 15:15:23 +0000 Received: by outflank-mailman (input) for mailman id 1408728; Fri, 04 Sep 2026 15:15:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2VdS-0000Qk-Cy for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 15:15:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2VdR-005Htr-3D; Fri, 04 Sep 2026 15:15:21 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2VdR-00H6Hu-19; Fri, 04 Sep 2026 15:15:21 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=AP8kuuP1oLO8xlTvnHhGDH+2KG+mEDzx3FziRKwtXY4=; b=nyYTn0v/00RNhNsTzu3OjfrAJK LYTJWTD4C8a5eCkXuswASlV9pcsKuDIaXT5pNobpdr0FPIFKjZwuxJk5q+mPqvDZxvO4jd9daHqzK owPCrI7l61nI26EkVwIyZR0XF71dSQ8dGyngVnzaboAnP1z0Kq8f4QwSnQGUc34bGxn0=; Date: Fri, 4 Sep 2026 17:15:19 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Ross Lagerwall Cc: xen-devel@lists.xenproject.org, Paul Durrant , Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v2 2/3] x86/viridian: Implement synthetic timer direct mode Message-ID: References: <20260904141516.367862-1-ross.lagerwall@citrix.com> <20260904141516.367862-3-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260904141516.367862-3-ross.lagerwall@citrix.com> On Fri, Sep 04, 2026 at 03:15:15PM +0100, Ross Lagerwall wrote: > In direct mode, the timer asserts an interrupt on expiration rather than > using a SynIC message. It is useful to implement this since Windows 11's > Hyper-V can only use synthetic timers in direct mode. > > Signed-off-by: Ross Lagerwall > --- > > In v2: > > * Handle migration from older Xen by introducing a new Viridian flag. > * Added more sanity checks during MSR write and vCPU context load. > > xen/arch/x86/hvm/viridian/time.c | 46 ++++++++++++++++++++++++---- > xen/arch/x86/hvm/viridian/viridian.c | 3 ++ > xen/include/public/hvm/params.h | 7 ++++- > 3 files changed, 49 insertions(+), 7 deletions(-) > > diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c > index 082528dc9416..4c8352612b19 100644 > --- a/xen/arch/x86/hvm/viridian/time.c > +++ b/xen/arch/x86/hvm/viridian/time.c > @@ -223,6 +223,14 @@ static void start_stimer(struct viridian_stimer *vs) > set_timer(&vs->timer, timeout + NOW()); > } > > +static void stimer_deliver_direct(struct vcpu *v, const struct viridian_stimer *vs) > +{ > + struct vlapic *vlapic = vcpu_vlapic(v); > + > + if ( vlapic_enabled(vlapic) ) > + vlapic_set_irq(vlapic, vs->config.apic_vector, 0); > +} > + > static void poll_stimer(struct vcpu *v, unsigned int stimerx) > { > struct viridian_vcpu *vv = v->arch.hvm.viridian; > @@ -242,9 +250,11 @@ static void poll_stimer(struct vcpu *v, unsigned int stimerx) > if ( !test_bit(stimerx, &vv->stimer_pending) ) > return; > > - if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx, > - stimerx, vs->expiration, > - time_ref_count(v->domain)) ) > + if ( vs->config.direct_mode ) > + stimer_deliver_direct(v, vs); > + else if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx, > + stimerx, vs->expiration, > + time_ref_count(v->domain)) ) > return; > > clear_bit(stimerx, &vv->stimer_pending); > @@ -361,6 +371,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) > case HV_X64_MSR_STIMER2_CONFIG: > case HV_X64_MSR_STIMER3_CONFIG: > { > + union hv_stimer_config new; > unsigned int stimerx = (idx - HV_X64_MSR_STIMER0_CONFIG) / 2; > struct viridian_stimer *vs = > &array_access_nospec(vv->stimer, stimerx); > @@ -368,11 +379,18 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) > if ( !(viridian_feature_mask(d) & HVMPV_stimer) ) > return X86EMUL_EXCEPTION; > > + new.as_uint64 = val; > + if ( new.direct_mode && > + !(viridian_feature_mask(d) & HVMPV_stimer_direct) ) > + return X86EMUL_EXCEPTION; Do we know whether native HyperV also injects a #GP in case of setting reserved bits on the register? To keep the previous behavior, should Xen silently ignore the setting when not supported, like it did in the past? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Sep 04 16:40:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 16:40:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408840.1641137 (Exim 4.92) (envelope-from ) id 1x2WxZ-000503-Ow; Fri, 04 Sep 2026 16:40:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408840.1641137; Fri, 04 Sep 2026 16:40:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2WxZ-0004zw-LW; Fri, 04 Sep 2026 16:40:13 +0000 Received: by outflank-mailman (input) for mailman id 1408840; Fri, 04 Sep 2026 16:40:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2WxX-0004zq-MS for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:40:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2WxW-008Bd7-VJ for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 18:40:10 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9af464-bab6-0a2a0a5309dd-0a2a4505d49c-12 for ; Fri, 04 Sep 2026 18:40:10 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9af46a-4cb1-0a2a45050019-d155802ed578-3 for ; Fri, 04 Sep 2026 18:40:10 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-490cf322ed0so12851595e9.1 for ; Fri, 04 Sep 2026 09:40:10 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cff81c9b5sm16979075e9.4.2026.09.04.09.40.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 09:40:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788540010; x=1789144810; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0uaRiF92XmAFBOP+wJ34ETAAVKNmbfG+f+mu0tHy9ek=; b=iY5IwhztR1HOo6uQDhjAZkOKH3RmeOcawKpTs3EKjSAW0kyfOwmEjAgkgbJaon+CPi MiCA10iEkrznIPMn2mkQnFkViuX4SJJleWFH5UCxQEaXqSuZUx3kdeZZlPEwyfJWp6pP 3PTH1VSSfuN1VTPVJjpzsU4EuLM9E49ppjKo3713+gAhAFkE04GRMDzvFP1itJb3GXSY 3wWgcTq8JY1dtX8VMVQQOJ3nFO2LYurgpNbzfUSkOXvEby5C/MVvwNr6lgnmx7nKVaSN LB+jsgJK/iWbq5F/Ywtq8OXM2gkUigcsOfF68551FaViTHHkCuxrzfsO550qrbX5iVvq esGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788540010; x=1789144810; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=0uaRiF92XmAFBOP+wJ34ETAAVKNmbfG+f+mu0tHy9ek=; b=fNv5YgH0trTBbyz6Sdr+L/rg44ww590aIxDejFuiPUTDU/kanthU6DuGVD44564QtW 5HXtO/ODAkk4VztRctV+MWREkxu0EZQ2I+TEgHLFXYG6WT2bVrX4rUP6xmRW5Zm8sG7a UNWSqSdNCGpgD3lGaMHjvM1Sv0Y6bBVOUgCpXbYVcyOQGnE2bRR/VNpdnyn4bTddE2Lt rpl1SWOFA97hhzQ6mvsu9ba+jWqZsYLvBK1Y1B0WfuenU0SZND/iHf2ZTFyk4OA8rVax MeMbr7gFgM0bSqC+/vhlS6RvGqagAL98OtSOdXqXt9+tiJOIm9haOcYfAfQR6DM8JYjF Ib0Q== X-Gm-Message-State: AFuF++kytEHV2+S9S57qhN81uYUFHxkifnf7x0UXj5S/zhgbNmLctRe1 aa22RVKy/y3Crgf7eX3wTE36eMehg/loWps0fRT3t1soOKgFqlmZEUrw X-Gm-Gg: AYBFou0E1v5iUUsdgD1O6DoVAbja2UKH9WBIEDa616oOJHEIMbuo/Wyx4hN7cFvknmK oX5OSXe5grmraZ9cbs2Uqpsqsu+ADh+3PauwuAeHS7GdYrW1/4/Pup7HeKzx61eznAM3EpsjGpZ IO0SuMkdmsyDUZUqh8yPDO9/xs53+9wPC8VhdEeg2XE8KeTE7git6ojpuhX0GG4BukDttxHptWn WUf30xo07rh7iahvIAsEZZ42/PzTWT/0g2MMsW/WfsPxDZdBw7zA+LdgZ73bIEOwxAJE6Y9bqC7 AJIcILUjRqjY9/twhxK6KmnPehe6nsJ7ufLW+V7fy/1OpXByzMZ9VwGZ5o6EqQah+L3pBNkVOuH w/N6TQ7waCXMqxLMhROLAT2tHUxdydRxw8zVgJjBXgYu7pg4AZ5rHIytMUdtOx8SHq2D6Q71YV6 ECbrmryr/gt01DhlSAFNivjTWRacNgxhmilwjkWVxXTw3FS6CGNWlpfIgGullihainmj/l2xMzs deXCDomZDaqrV5aD3XlLSfCtC6/ZXGTdBzNmxE= X-Received: by 2002:a05:600c:46d5:b0:49c:fc6c:be04 with SMTP id 5b1f17b1804b1-49cfc6cc091mr46777165e9.27.1788540010053; Fri, 04 Sep 2026 09:40:10 -0700 (PDT) Message-ID: Date: Fri, 4 Sep 2026 18:40:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 13/39] xen/riscv: save and restore AIA state on vCPU context switch To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <32e8b81fd276498cfd339defd2720bce1745c1cf.1787838835.git.oleksii.kurochko@gmail.com> <1788515561.8631fc262581453bbf619ec5b2062170.1a06bd5af1a000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788515561.8631fc262581453bbf619ec5b2062170.1a06bd5af1a000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788540010-73CB82A1-0E01E2BA/10/73395122804 X-purgate-type: spam X-purgate-size: 6933 On 9/4/26 11:52 AM, Baptiste Le Duc wrote: >> vsiselect and hviprio{1,2} are per-hart CSRs which a guest can change, so >> they have to be part of the vCPU context: > Where in the spec did you see that? Because in AIA spec section 6.3.1, > it is written that "When vsiselect has a value in the range 0x30-0x3F, > an attempt from VS-mode to access sireg (really vsireg) causes a virtual > instruction exception" and this even when hstateen0.CSRIND is set as hstateen0 > just control whether a guest/S-mode is allowed to access a CSR (exactly > as you described below). Your understanding is correct, it was me who confused the things. Sorry for that. > > Therefore, the hypervisor has two options to modify the priority of a > major irq: > - emulate the iprio array in software. > - Use hviprio1/hviprio2 (only 10 irqs configurable). > > But the guest shouldn't be able to modify h CSRs at all, in any case, or > I may have misunderstood a part of the spec. > > For the moment I don't see any catch of possible instruction exception > in do_trap(). There is no such because we don't emulate range 0x30-0x3F. We don't have such use cases now. I think that I have to recheck what should be saved/restored now. There is no need to save/restore CSR_HVIPRIO* during context switch as we don't have support of handling of 0x30-0x3f. I will introduce that later when we really will need that. VSISELECT should be save/restored then only in this patch as we have hstateen0.SMSTATEEN0_SVSLCT set so guest could change VSISELECT directly so we need to store/restore. Am I missing something? With having only VSISELECT saved/restored in this patch I think the commit message should be: xen/riscv: save and restore vsiselect on vCPU context switch vsiselect is a per-hart CSR which a guest changes on its own: when V=1, VS-mode accesses to siselect are really accesses to vsiselect. Architecturally a vCPU has to find there the value it last wrote, but as long as the CSR isn't part of the vCPU context it finds whatever selector the vCPU which ran on the hart before it left behind. A guest which writes siselect, is descheduled and then reads sireg without rewriting siselect therefore reaches a register it never selected, and it can also observe another guest's selector value. When Smstateen is implemented, access to vsiselect and vsireg is gated by hstateen0.CSRIND (bit 60, SMSTATEEN0_SVSLCT in Xen's headers), and v->arch.hstateen0 holds the bits vcpu_csr_init() ended up with. A clear bit there covers the two cases in which the CSR has to be skipped: - Xen didn't hand the guest access to it, so the guest can't have changed the CSR and there is no state to preserve; - M-mode denied the state altogether. Smstateen makes a bit which is zero in mstateen0 read-only zero in hstateen0, and a zero bit in mstateen0 traps accesses from every privilege mode less privileged than M-mode, HS-mode included, so Xen couldn't even read the CSR to save it. Without Smstateen no bit controls access to the CSR, so it is saved and restored whenever Ssaia is available. Signed-off-by: Oleksii Kurochko --- Changes in v3: - Update the commit message. - Save and restore only VSISELECT. --- Changes in v2: - New patch. --- diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 0ad851ee0f5f..1085ef152b8b 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -327,6 +327,28 @@ int arch_domain_create(struct domain *d, return rc; } +/* + * vsiselect is a per-hart CSR, but a guest changes it on its own: when V=1, + * VS-mode accesses to siselect are really accesses to vsiselect. Hence it is + * part of the vCPU context. + * + * When Smstateen is implemented, hstateen0.CSRIND (SMSTATEEN0_SVSLCT) gates + * that access, and a bit staying clear in v->arch.hstateen0 (see + * vcpu_csr_init()) means either that the guest was never given access to the + * CSR, and so can't have changed it, or that M-mode denied the state + * altogether, in which case the CSR can't be accessed from HS-mode either. + */ +static bool vcpu_can_access_vsiselect(const struct vcpu *v) +{ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) ) + return false; + + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) + return true; + + return v->arch.hstateen0 & SMSTATEEN0_SVSLCT; +} + static void save_csr_regs(struct vcpu *p) { /* @@ -354,6 +376,9 @@ static void save_csr_regs(struct vcpu *p) p->arch.vscause = csr_read(CSR_VSCAUSE); p->arch.vstval = csr_read(CSR_VSTVAL); p->arch.vsepc = csr_read(CSR_VSEPC); + + if ( vcpu_can_access_vsiselect(p) ) + p->arch.vsiselect = csr_read(CSR_VSISELECT); } static void restore_csr_regs(struct vcpu *n) @@ -375,6 +400,9 @@ static void restore_csr_regs(struct vcpu *n) csr_write(CSR_VSCAUSE, n->arch.vscause); csr_write(CSR_VSTVAL, n->arch.vstval); csr_write(CSR_VSEPC, n->arch.vsepc); + + if ( vcpu_can_access_vsiselect(n) ) + csr_write(CSR_VSISELECT, n->arch.vsiselect); } static void ctxt_switch_from(struct vcpu *p) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 58d1e8076876..b0824d7f9add 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -75,6 +75,7 @@ struct arch_vcpu { register_t vscause; register_t vsepc; uint64_t vsie; + register_t vsiselect; register_t vsscratch; register_t vsstatus; register_t vstval; Does it make sense to you? > >> - vsiselect is written directly by VS-mode through siselect; >> - hviprio1 and hviprio2 hold the priorities of the local interrupts which >> VS-mode reaches through the iprio array of vsiselect/vsireg, so writes >> the guest performs there land in these CSRs. > hviprio1 and hviprio2 hold priorities for interrupts 1 (SSI), 5 (STI), > 13 (counter overflow), and 14-23 (local) so calling all of them "local" > is wrong. Agree, it is incorrect to call them "local" >> Without saving them, one vCPU's selector leaks into another vCPU's vsireg >> accesses and one guest's interrupt priorities apply to the next guest which >> runs on the same hart. >> >> Whether the CSRs may be touched at all is gated by hstateen0 when Smstateen >> is implemented: SVSLCT for vsiselect/vsireg and AIA for the rest of the AIA > I couldn't find any reference to SVSLCT in the spec. I assume you wanted > to refer to CSRIND and SVSLCT is an OpenSBI's own nickname. > Indeed, SVSLCT is the OpenSBI nickname/macro definition for this feature and CSRIND would be better to use in commit message. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 04 16:54:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 16:54:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408869.1641146 (Exim 4.92) (envelope-from ) id 1x2XB7-0007G6-WD; Fri, 04 Sep 2026 16:54:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408869.1641146; Fri, 04 Sep 2026 16:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XB7-0007Fz-T0; Fri, 04 Sep 2026 16:54:13 +0000 Received: by outflank-mailman (input) for mailman id 1408869; Fri, 04 Sep 2026 16:54:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2XB6-0007Ft-CL for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:54:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2XB5-00C1lZ-P5 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 18:54:11 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9af7b3-2eae-0a2a0a5409dd-0a2a450ce614-0 for ; Fri, 04 Sep 2026 18:54:11 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9af7b3-f479-0a2a450c0019-d155802ab0c2-3 for ; Fri, 04 Sep 2026 18:54:11 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b0dbfbf7bso9524725e9.2 for ; Fri, 04 Sep 2026 09:54:11 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce58da3acsm426952495e9.0.2026.09.04.09.54.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 09:54:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788540851; x=1789145651; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=aQvMTCI/O6mBW8lrtMSenSHB02btM6NqWxYBSr0VoLs=; b=fA15PTSRmt9tbmacXwzmYBBJAyh/e/t7LO4YV/vtWJdH6kPQnryhbD0rhWOPul/sSp nUlcN4V+QDsiHDWXJ4mW9i78s2gAqYQ4aWMy803IaK14ufZ8YxobxJnXoAHjcgcBoLEW wwnMrYuza2HGN+nj9YDPHMhTjw4htwBlXMu8UX/YnXNm82fAP/YKcZna7Sf/GPj5Iopr +88i/SvoYrRqVTQUSOmIwiokrfjbzZlPCSfjqEVMBW9nmTejwVNRTfGeYKlWsxwWoyBu r4bB0EkjjsVww3EH/yjTcPVMzjG12XCh2NNalISmyXoxWjRNHkPe9PS5sbm7RMUPI8M3 5QSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788540851; x=1789145651; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=aQvMTCI/O6mBW8lrtMSenSHB02btM6NqWxYBSr0VoLs=; b=bz3OvbPqu5RaB3n8UqCdvf4BW+SPw/a33xc2a2uD2wJ3mQONWDV0ZzdGOPsXW0J0X1 ad+o47T5SdYur5No9pOI/+R/cTlFC+YZuY1qwU/wMTKhYw3oTpYNul2hg3sxADXl9IRq GuJtAUUo7yjhX+CF/zXPOzC62vGYtapgaV1RpiQjoDF4h8RlepMgmjZBCZPbWJU9NFjp JtKMEft41aRlfL/guenfGfUSpLIDPJzefNzZ03lgnv2osH1rvKKi5PBJVTvucO72NDkW +D6zVCoENhqk98cdwEJyRrpDeslshnK4upTd6x9J+yOYRkwcJefhjA8CNMtW5sk3Nw6Q Np8w== X-Gm-Message-State: AFuF++miip3vLHwwbdYB6bQxKczHkqAwgsC94O151yV/zc7GRWKNqw5J OxVRDQsshxZyWcP7gtjS2+FnR9LUSddqkFyiuRHMCZdPEK6+5BWvjWPZ X-Gm-Gg: AYBFou1ldPKlb9uZxlANvlpSH/p40iagmGxO00IQu2o2OwQRYyjjHTg2z/f3C3CXXST oaSfa6U3TuEj1hOxZkfCU2ogMoODRtiYoy07ke1KjUNqGBEvYC56S8Cux2TANfRaiPvdiK8EFWh lVpmTu8WW4crMLmJQij8wa+hb3MW+SdtPkV9rsqmji96vJHPwmmYCzUodwU7fe/zhXtcllXuNMi vnahA5hiI+9x0myJAff6uEaAFkePMnYG/buJRbB3X8IL2F7bAhqx6bnUpGLUxdb0aD1ZJPbHPn8 wxjGW2ncLMr4Nnv43+2VbOdj2ArjmUzvadrEj84probhUbCN7C8oE0n8wwYqn0K0Ynj68edwGAL GYmQ97GPkdaaDWelS6A+QzV63Q/NcLa1X+jvXIHh/B+a/HpjTNS7vAyLzLCODNAYMDhtcr9awzV gNhNffOsuBpDFD8+uVoFnGhqGgVYf1xSdpF3s3UeNK5XSeuln5LAWIkKInZeBtJd58iOM+r00m1 qEL/JHP8boHz4T1+VTeZkiFMK3YNPK3bJu/Xws= X-Received: by 2002:a05:600c:a405:b0:49c:feb6:d46 with SMTP id 5b1f17b1804b1-49cfeb60de9mr61790335e9.12.1788540850884; Fri, 04 Sep 2026 09:54:10 -0700 (PDT) Message-ID: <67c9edde-4f97-49e3-8d5a-e6309559075e@gmail.com> Date: Fri, 4 Sep 2026 18:54:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 14/39] xen/riscv: introduce vintc_ctxt_switch_{from,to}() To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <678236568970b18a1924a76588c4c50f9bf0c659.1787838835.git.oleksii.kurochko@gmail.com> <1788521115.8631fc262581453bbf619ec5b2062170.1a06c2a6d8f000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788521115.8631fc262581453bbf619ec5b2062170.1a06c2a6d8f000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788540851-766DEA5B-74D655F6/10/73395122804 X-purgate-type: spam X-purgate-size: 1055 On 9/4/26 1:25 PM, Baptiste Le Duc wrote: >> Virtual interrupt controller state must be preserved across vCPU context >> switches. >> >> Introduce vintc_ctxt_switch_{from,to}() wrappers around new >> ctxt_switch_{from,to}() hooks in struct vintc_ops, and call them from the >> context switch path, so that this state can be saved/restored without >> knowing which vINTC variant a domain uses. >> >> No vINTC variant implements the hooks yet: the vAPLIC implementation is >> added separately. > So this patch couldn't be applied alone as, at the time of this commit, you only set in vaplic.c: > static const struct vintc_ops vintc_ops = { > .vcpu_init = vcpu_imsic_init, > .vcpu_deinit = vcpu_imsic_deinit, > }; > > So ops->ctxt_switch_from(v) or ops->ctxt_switch_to(v) will try to > deference NULL pointer causing segfault. I don't know if it's matter but > worth to mention somewhere. > Just abstraction is introduced here and context switch isn't happen for now so we are safe. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 04 16:56:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 16:56:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408876.1641154 (Exim 4.92) (envelope-from ) id 1x2XDB-0007qu-BZ; Fri, 04 Sep 2026 16:56:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408876.1641154; Fri, 04 Sep 2026 16:56:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XDB-0007qn-8k; Fri, 04 Sep 2026 16:56:21 +0000 Received: by outflank-mailman (input) for mailman id 1408876; Fri, 04 Sep 2026 16:56:20 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2XDA-0007qh-1V for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 16:56:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2XD8-008DUc-Tg for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 18:56:18 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9af82c-8faa-0a2a0a5109dd-0a2a450b9850-2 for ; Fri, 04 Sep 2026 18:56:18 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9af832-b7e8-0a2a450b0019-d155802de1c4-3 for ; Fri, 04 Sep 2026 18:56:18 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49cd9add88aso8727475e9.3 for ; Fri, 04 Sep 2026 09:56:18 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cee3b0af8sm170951985e9.0.2026.09.04.09.56.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Sep 2026 09:56:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788540978; x=1789145778; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=8PynylFYm4sY0Xl0aAJeG3VPTE5sVKvJJyvGzuWpf+s=; b=RsnFHbds31LXFQAYtjjmXtwHht5kkJSgQFY0SSADzAeL4hkhiwSCjhB+GOJlAVNujq LdiapEuabRXG/IrZ3C2ww7/eYnrtDq6FuZikasCwMiitunOM31Ha2NAufgwVlqDR2aMA i349e0WM+jtLNm4xERld6wgrOFie1iIB30qoyJMMbuDBa7JasVJG92Gw+4QKRmnYsROh MLgUynZCIECAEm3bED2jM+5qdr/4ngjK0sUrDL2GVPXgSOFZYB0dJcXFD6aBG71hQzC1 8f1qe1drb7swFAGiBJjhbh7JUN6nQJiMJ4HuW2R0VltpLw41TpAh1efHMHlrn/rf9Nml ev5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788540978; x=1789145778; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=8PynylFYm4sY0Xl0aAJeG3VPTE5sVKvJJyvGzuWpf+s=; b=hh2sV4o31iZOMOWpENZKhV0u2TT7Nuh/lH3tcEDrW9Q+ip/4q51sn26ob05jWbtUbm H82TVlAMkhpUM9/MmrBa52KILArXyjmhB0Hd0YJ+yq9jX9X8kfiURvHCc9deoL2DnQ7T Nyz4dgwq6hHcg02GGh+e2AGSLkx/3G2dYMJ7HcSZUwwYCiIpuF9mAVYcCYSVo5Xd4N8+ yjIznqkoghn7ET06bPFlqehWk69yC0L5VPb2GkSZovbpVnj2en3DyQ+w22AWb+qRP+ia yoekYxqpHHl7uUNTcD8j+Ss3zOiNr4sGbyHSzhIErE9Qr5TxY4OX4bwwyxCrXCzMCU8/ cJQg== X-Gm-Message-State: AFuF++knD5MdEUYZiNrh5UsJg1rU4JXh3oMLy4YhR1ArgoUUqk7jRaKh TVkGpeX469mNL15CRB7HiRQvMzAVLHoUGpSx5Gpm+6VyVpvtYsA4qLZH X-Gm-Gg: AYBFou1RljUsWO5UeGHfj7gow2YCmVG3jwcKhrZ+85Iq2CPEqB1/pnyxZbyZkNQvPNs vtiN7KpYOGz0ibBpuphBAeKbH8HDnN7LrLxNN4o/ZNu69UOR+bw+dTohc/fFOU6WFeoB7B/Jwyz 9Q3JJ7fRyXAC313pJznJTXz/ENajgAJlFC7nTJjztja6uxO6V4h+ZuqsakJkPmXCRLy6oP7MzzH btJovepR+mmybAQ4XgVxoNHttP2aCGrPrLxvz3j5lrOPylBgKsNKz1Lhdavk7aePyYUXr4W7TUz i30YuOK3kTDNN8HlpiKZjaYw4qdEAxoXkpd/F/5kLD6r64V8/kp+SXcvpb0nvp7Xb5bGIMG66S8 4aup44LpIsw4yio3b70ze8b8dzAlzFKIws+SYozJU72S6/3zh5ffyMog8CwEjsUhZk+YANssrYL Ulfx/qIevvix/ItU+bb+jGCOFD91rgN9tjJ8Y2eWIYbeYQf5ANUiROjFdCocy27atxywsE037G/ AxGjbh6f2czK0SzT7iKCTkFi3LJA0o4rnvsSy/39ilyXKNzpXvY X-Received: by 2002:a05:600c:19d1:b0:49c:fc6e:8cbb with SMTP id 5b1f17b1804b1-49cfc6e8e05mr52339725e9.31.1788540978067; Fri, 04 Sep 2026 09:56:18 -0700 (PDT) Message-ID: <890cda7e-a80e-4965-9d91-69c15076de88@gmail.com> Date: Fri, 4 Sep 2026 18:56:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 15/39] xen/riscv: add IMSIC vCPU context switch handlers To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <867af892784c295296cdf63e0371fa1b7ed7a1e7.1787838835.git.oleksii.kurochko@gmail.com> <1788521592.8631fc262581453bbf619ec5b2062170.1a06c31b828000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788521592.8631fc262581453bbf619ec5b2062170.1a06c31b828000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788540978-A94C39EA-B444B5B2/10/73395122804 X-purgate-type: spam X-purgate-size: 4563 On 9/4/26 1:33 PM, Baptiste Le Duc wrote: >> IMSIC state currently needs to track only which physical CPU owns a vCPU's >> IMSIC guest interrupt file, as the CPU id is part of the physical address >> the file is mapped at. >> >> Add imsic_ctxt_switch_from() to record that CPU when a vCPU is switched >> out. A vCPU running on the s/w VS-file has no h/w file bound to a CPU, so >> there is nothing to record for it. The recorded value stays unused until >> vCPU migration support, which needs it to find the file to move away from, >> is added later. >> >> imsic_ctxt_switch_to() has nothing to do: by the time a vCPU is switched >> in, VGEIN is already assigned to it and its guest interrupt file is already >> mapped. Work is only required once a vCPU can move to a different CPU, >> which means recalculating VGEIN and remapping the file; that is handled >> separately by the vCPU migration patches. >> >> Install both as the ctxt_switch_{from,to} hooks of struct vintc_ops. MSI >> delivery is the only mode Xen supports ( aplic_init() panics on an APLIC >> without an "msi-parent" property, and a guest's domaincfg.DM reads back as >> a fixed one) so the vAPLIC state to save and restore is always the IMSIC >> one and no vAPLIC-level forwarder is needed. Being indirect call targets, >> both handlers get cf_check. >> >> Co-developed-by: Romain Caritey >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c >> index ad0a220eda..3787f270d8 100644 >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -20,6 +20,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -342,6 +343,28 @@ static int __init imsic_parse_node(const struct dt_device_node *node, >> return 0; >> } >> >> +void cf_check imsic_ctxt_switch_from(struct vcpu *v) >> +{ >> + struct vimsic_state *imsic_state = v->arch.vimsic_state; >> + unsigned long flags; >> + >> + /* >> + * A vCPU using the s/w IMSIC VS-file (guest_file_id == 0) has no h/w >> + * VS-file bound to a physical CPU, so there is no location to record. >> + */ >> + if ( !vcpu_guest_file_id(v) ) >> + return; >> + >> + write_lock_irqsave(&imsic_state->vsfile_lock, flags); >> + imsic_state->vsfile_cpu = v->processor; >> + write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >> +} >> + >> +void cf_check imsic_ctxt_switch_to(struct vcpu *v) >> +{ >> + /* Nothing to do */ >> +} >> + >> int cf_check vcpu_imsic_init(struct vcpu *v) >> { >> struct vimsic_state *imsic_state; >> diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h >> index 93f9e44c7d..73129c3c9e 100644 >> --- a/xen/arch/riscv/include/asm/imsic.h >> +++ b/xen/arch/riscv/include/asm/imsic.h >> @@ -109,4 +109,7 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v); >> >> int vimsic_make_domu_dt_node(struct kernel_info *kinfo, unsigned int *phandle); >> >> +void imsic_ctxt_switch_from(struct vcpu *v); >> +void imsic_ctxt_switch_to(struct vcpu *v); >> + >> #endif /* ASM_RISCV_IMSIC_H */ >> diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c >> index 8726f7203d..6c60fe2baf 100644 >> --- a/xen/arch/riscv/vaplic.c >> +++ b/xen/arch/riscv/vaplic.c >> @@ -422,6 +422,13 @@ static const struct mmio_handler_ops vaplic_mmio_ops = { >> static const struct vintc_ops vintc_ops = { >> .vcpu_init = vcpu_imsic_init, >> .vcpu_deinit = vcpu_imsic_deinit, >> + /* >> + * MSI delivery is the only supported mode: aplic_init() panics on an >> + * APLIC without an "msi-parent", so the vAPLIC state to save and restore >> + * is always the IMSIC one. >> + */ >> + .ctxt_switch_from = imsic_ctxt_switch_from, >> + .ctxt_switch_to = imsic_ctxt_switch_to, > > Maybe this patch could be merged with previous one: patch 50fe9554e1c0 ("xen/riscv: introduce vintc_ctxt_switch_{from,to}()") At some point I agree but I think I prefer a little bit to separate them. It is safe to have them separately as context switch isn't happening between these patches so any problem will occur. What I intented to do is that to separately introduce abstraction and separately introduce users of this abstraction. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 04 17:14:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 17:14:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408902.1641173 (Exim 4.92) (envelope-from ) id 1x2XUe-0003BP-UA; Fri, 04 Sep 2026 17:14:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408902.1641173; Fri, 04 Sep 2026 17:14:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUe-0003BI-RO; Fri, 04 Sep 2026 17:14:24 +0000 Received: by outflank-mailman (input) for mailman id 1408902; Fri, 04 Sep 2026 17:14:23 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUd-0003B4-L4 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 17:14:23 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2XUc-005Kk8-1v; Fri, 04 Sep 2026 17:14:22 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2XUc-000PXA-02; Fri, 04 Sep 2026 17:14:22 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=5FAZdrD/CSlhzCnqj5dZaUZDZ9GfXXAxevwlxaPWsI4=; b=uzdZ741gH0rcrN+RgRlzc39Q8t z6dnLjO5DoDWktcrogGnvXLbTTU/kjCv0A3dXJeQD3EIr5h8JjaeBNnpugHP33AMcCh/O9/YxUe1i FzYl9WJ70WuFLJL62foQJqXPRaJGZ6ocmia1T86q0LhWNQviCFLMn1BV6ijKlYPy2aBg=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?J=C3=BCrgen=20Gro=C3=9F?= , Roger Pau Monne , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH 1/5] xen/rcu: fix types Date: Fri, 4 Sep 2026 19:11:17 +0200 Message-ID: <20260904171121.65300-2-roger@xenproject.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904171121.65300-1-roger@xenproject.org> References: <20260904171121.65300-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adjust some types: int -> bool, int -> unsigned int. Also fix a couple of typos plus trailing white space. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/common/rcupdate.c | 12 ++++++------ xen/include/xen/rcupdate.h | 8 ++++---- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c index fd5d3d7484a5..3b96f829c87c 100644 --- a/xen/common/rcupdate.c +++ b/xen/common/rcupdate.c @@ -509,18 +509,18 @@ static int __rcu_pending(struct rcu_ctrlblk *rcp, struct rcu_data *rdp) return 0; } -int rcu_pending(int cpu) +bool rcu_pending(unsigned int cpu) { - return __rcu_pending(&rcu_ctrlblk, &per_cpu(rcu_data, cpu)); + return !!__rcu_pending(&rcu_ctrlblk, &per_cpu(rcu_data, cpu)); } /* * Check to see if any future RCU-related work will need to be done * by the current CPU, even if none need be done immediately, returning - * 1 if so. This function is part of the RCU implementation; it is -not- + * true if so. This function is part of the RCU implementation; it is -not- * an exported member of the RCU API. */ -int rcu_needs_cpu(int cpu) +bool rcu_needs_cpu(unsigned int cpu) { struct rcu_data *rdp = &per_cpu(rcu_data, cpu); @@ -529,7 +529,7 @@ int rcu_needs_cpu(int cpu) /* * Timer for making sure the CPU where a callback is queued does - * periodically poke rcu_pedning(), so that it will invoke the callback + * periodically poke rcu_pending(), so that it will invoke the callback * not too late after the end of the grace period. */ static void rcu_idle_timer_start(void) @@ -588,7 +588,7 @@ static void cf_check rcu_idle_timer_handler(void* data) IDLE_TIMER_PERIOD_MIN); } -void rcu_check_callbacks(int cpu) +void rcu_check_callbacks(unsigned int cpu) { struct rcu_data *rdp = &this_cpu(rcu_data); diff --git a/xen/include/xen/rcupdate.h b/xen/include/xen/rcupdate.h index 95f4ad81c4a8..c57f628107cf 100644 --- a/xen/include/xen/rcupdate.h +++ b/xen/include/xen/rcupdate.h @@ -77,8 +77,8 @@ struct rcu_head { } while (0) -int rcu_pending(int cpu); -int rcu_needs_cpu(int cpu); +bool rcu_pending(unsigned int cpu); +bool rcu_needs_cpu(unsigned int cpu); /* * Dummy lock type for passing to rcu_read_{lock,unlock}. Currently exists @@ -168,10 +168,10 @@ static inline void rcu_read_unlock(rcu_read_lock_t *lock) #define rcu_assign_pointer(p, v) ({ smp_wmb(); (p) = (v); }) void rcu_init(void); -void rcu_check_callbacks(int cpu); +void rcu_check_callbacks(unsigned int cpu); /* Exported interfaces */ -void call_rcu(struct rcu_head *head, +void call_rcu(struct rcu_head *head, void (*func)(struct rcu_head *head)); void rcu_barrier(void); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 17:14:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 17:14:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408903.1641182 (Exim 4.92) (envelope-from ) id 1x2XUh-0003PO-8X; Fri, 04 Sep 2026 17:14:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408903.1641182; Fri, 04 Sep 2026 17:14:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUh-0003PE-2j; Fri, 04 Sep 2026 17:14:27 +0000 Received: by outflank-mailman (input) for mailman id 1408903; Fri, 04 Sep 2026 17:14:25 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUf-0003MH-Oo for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 17:14:25 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2XUe-005KkI-2V; Fri, 04 Sep 2026 17:14:24 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2XUe-000PhT-0i; Fri, 04 Sep 2026 17:14:24 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=2HiqIR5wDrd1IuylDmsDPpeiruy+pLJWmkc28OV2WQ8=; b=hp6HIua5hoLvQLeIHvXYsd+av9 X8SygqolTaBWogbx/59xIJKuNQPpWBqxlV/e4Faow3cwsOYnxtgRqf9HbE0NPOUplm+jsBPLsp8Vw 6kyCWj6WVzDBdvB0oVVz43SfhiifRbRnc/iOrnOGXIYbzSQJx5qMFnyIlqpjTBK3shMg=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?J=C3=BCrgen=20Gro=C3=9F?= , Roger Pau Monne , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH 2/5] xen/rcu: sort includes Date: Fri, 4 Sep 2026 19:11:18 +0200 Message-ID: <20260904171121.65300-3-roger@xenproject.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904171121.65300-1-roger@xenproject.org> References: <20260904171121.65300-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Roger Pau Monné --- xen/common/rcupdate.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c index 3b96f829c87c..c1b6b2ae768b 100644 --- a/xen/common/rcupdate.c +++ b/xen/common/rcupdate.c @@ -31,21 +31,22 @@ * For detailed explanation of Read-Copy Update mechanism see - * http://lse.sourceforge.net/locking/rcupdate.html */ -#include -#include +#include +#include #include +#include #include -#include -#include -#include +#include #include #include -#include -#include -#include +#include +#include #include -#include +#include #include +#include + +#include DEFINE_PER_CPU(unsigned int, rcu_lock_cnt); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 17:14:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 17:14:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408901.1641164 (Exim 4.92) (envelope-from ) id 1x2XUc-0002yo-Nj; Fri, 04 Sep 2026 17:14:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408901.1641164; Fri, 04 Sep 2026 17:14:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUc-0002yh-Kv; Fri, 04 Sep 2026 17:14:22 +0000 Received: by outflank-mailman (input) for mailman id 1408901; Fri, 04 Sep 2026 17:14:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUb-0002yb-MQ for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 17:14:21 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2XUa-005Kk1-0B; Fri, 04 Sep 2026 17:14:19 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2XUZ-000KXP-1S; Fri, 04 Sep 2026 17:14:19 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=EyrrA52snfvNiGK2CDuBhupD7aRPn0GYLmxoad+/ods=; b=3M3/b0tDCFqpAVJLSCyKpx7sxv TK8aOHz0ozakGb9iZVj0zxV6bwejlkvHCiwsRoOb37AtXu2SLoaFRZi3dHoXbFPEdoITGYyapMWC8 e9BoneJxl8LKeIW95WfFmH0ikzJDpJuRD0Z/YpTgB4duqIKkQ9paAVDmQH6jcdb6+pp4=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?J=C3=BCrgen=20Gro=C3=9F?= , Roger Pau Monne , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH 0/5] xen/rcu: rework the RCU logic Date: Fri, 4 Sep 2026 19:11:16 +0200 Message-ID: <20260904171121.65300-1-roger@xenproject.org> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello, Following series aims to solve two problems we have observed with the RCU subsystem, complete details on patch 4. The series is basically a re-write (and IMO simplification) of the RCU logic, patch 4 containing most of the newly introduced logic. It's been (slightly) tested locally and on the safety CI. Maybe I'm being naive, but this looks much easier to reason about and maintain than the current logic. This "simplification" is only possible after the introduction of rcu_read_{lock,unlock}() helpers that identify RCU critical sections. Thanks, Roger. Roger Pau Monne (5): xen/rcu: fix types xen/rcu: sort includes xen/rcu: introduce the concept of RCU epoch xen/rcu: simplify RCU implementation xen/rcu: remove rcu_needs_cpu() xen/common/rcupdate.c | 502 +++++++++---------------------------- xen/include/xen/rcupdate.h | 45 ++-- xen/include/xen/sched.h | 2 +- 3 files changed, 153 insertions(+), 396 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 17:14:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 17:14:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408904.1641192 (Exim 4.92) (envelope-from ) id 1x2XUj-0003f0-Et; Fri, 04 Sep 2026 17:14:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408904.1641192; Fri, 04 Sep 2026 17:14:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUj-0003et-9J; Fri, 04 Sep 2026 17:14:29 +0000 Received: by outflank-mailman (input) for mailman id 1408904; Fri, 04 Sep 2026 17:14:27 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUh-0003QO-Ae for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 17:14:27 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2XUg-005KkT-1w; Fri, 04 Sep 2026 17:14:26 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2XUg-000Pv2-07; Fri, 04 Sep 2026 17:14:26 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=8QytEU0lmc6HwZdMirOP0o0H/nj+OB9HGqWTN4Ozvyo=; b=ErK5gLZmPi/Pj+Sm/QFByhluxM jBJnkHR45oUMKGQ59xflf5wJBimyQemm5/ekZAyBtdMW5UZOGpCcibAJD7+C6+tjO8rkHGS3HNCf7 uyUz1CfKKrcueNNN2dLdjYIri5aSDrnmjB5vIEh3AeNBHqpIATWpKxSsPdSjn1oJcqR4=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?J=C3=BCrgen=20Gro=C3=9F?= , Roger Pau Monne , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH 3/5] xen/rcu: introduce the concept of RCU epoch Date: Fri, 4 Sep 2026 19:11:19 +0200 Message-ID: <20260904171121.65300-4-roger@xenproject.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904171121.65300-1-roger@xenproject.org> References: <20260904171121.65300-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit An RCU epoch signals the lifetime of RCU references. Each CPU keeps track of the epoch when an RCU critical section is entered. When a RCU callback is added the current epoch is recorded in the callback, and increased, as a way to know when all CPUs have moved past a specific epoch, and thus there are no longer active references to objects fetched during that epoch. The compiler barrier is switched to a full memory barrier, as future uses of rcu_lock_cnt must ensure the count is increased before taking a reference to any RCU protected object. Use ACCESS_ONCE() avoid the compiler from shattering accesses to the variables. The reordering prevention aspect of ACCESS_ONCE() is not relevant here, but we must ensure accesses are not shattered, as there will be remote consumers of those variables. Signed-off-by: Roger Pau Monné --- Can possibly be folded into the next patch, as it's lacking context on its own to understand the need to introduce the logic. --- xen/common/rcupdate.c | 6 ++++++ xen/include/xen/rcupdate.h | 19 +++++++++++++++---- 2 files changed, 21 insertions(+), 4 deletions(-) diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c index c1b6b2ae768b..bd63280fd63c 100644 --- a/xen/common/rcupdate.c +++ b/xen/common/rcupdate.c @@ -49,6 +49,11 @@ #include DEFINE_PER_CPU(unsigned int, rcu_lock_cnt); +/* Store epoch when CPU entered the RCU critical section. */ +DEFINE_PER_CPU(unsigned int, rcu_lock_epoch); + +/* Current RCU epoch, bumped every time a new callback is queued. */ +unsigned int rcu_epoch; /* Global control variables for rcupdate callback mechanism. */ static struct rcu_ctrlblk { @@ -282,6 +287,7 @@ void call_rcu(struct rcu_head *head, head->func = func; head->next = NULL; + head->added = arch_fetch_and_add(&rcu_epoch, 1); local_irq_save(flags); rdp = &this_cpu(rcu_data); *rdp->nxttail = head; diff --git a/xen/include/xen/rcupdate.h b/xen/include/xen/rcupdate.h index c57f628107cf..6c265c672c14 100644 --- a/xen/include/xen/rcupdate.h +++ b/xen/include/xen/rcupdate.h @@ -34,24 +34,34 @@ #include #include #include +#include #include #include #define __rcu DECLARE_PER_CPU(unsigned int, rcu_lock_cnt); +DECLARE_PER_CPU(unsigned int, rcu_lock_epoch); + +extern unsigned int rcu_epoch; static inline void rcu_quiesce_disable(void) { + unsigned int cpu = smp_processor_id(); + preempt_disable(); - this_cpu(rcu_lock_cnt)++; - barrier(); + if ( !ACCESS_ONCE(per_cpu(rcu_lock_cnt, cpu))++ ) + { + ACCESS_ONCE(per_cpu(rcu_lock_epoch, cpu)) = ACCESS_ONCE(rcu_epoch); + smp_mb(); + } } static inline void rcu_quiesce_enable(void) { - barrier(); - this_cpu(rcu_lock_cnt)--; + if ( this_cpu(rcu_lock_cnt) == 1 ) + smp_mb(); + ACCESS_ONCE(this_cpu(rcu_lock_cnt))--; preempt_enable(); } @@ -68,6 +78,7 @@ static inline bool rcu_quiesce_allowed(void) struct rcu_head { struct rcu_head *next; void (*func)(struct rcu_head *head); + unsigned int added; }; #define RCU_HEAD_INIT { .next = NULL, .func = NULL } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 17:14:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 17:14:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408905.1641200 (Exim 4.92) (envelope-from ) id 1x2XUk-0003tb-Oa; Fri, 04 Sep 2026 17:14:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408905.1641200; Fri, 04 Sep 2026 17:14:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUk-0003tU-KY; Fri, 04 Sep 2026 17:14:30 +0000 Received: by outflank-mailman (input) for mailman id 1408905; Fri, 04 Sep 2026 17:14:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUj-0003f6-Bo for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 17:14:29 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2XUi-005Kkf-23; Fri, 04 Sep 2026 17:14:28 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2XUi-000Q0G-0I; Fri, 04 Sep 2026 17:14:28 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=LZhALLn0ovpkb2bRdZsHBI4v5WiQPyVT/P5+n0/4JSI=; b=GA0ucdRsDlYpOMJX5g+REXqjui 8nRAl10euTpuzFxzt4cTjjUuS8m8OFybg20rxzHpraqmgkGr9mpmOvel1iHzai9WV5a1hOxtI1T9J +UTWil2l39Hsp0GpWpvVtB3S6RP6km2VDG3k9dIQsItoo1w5kvB7ylCI28tSkDiMEJNc=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?J=C3=BCrgen=20Gro=C3=9F?= , Roger Pau Monne , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH 4/5] xen/rcu: simplify RCU implementation Date: Fri, 4 Sep 2026 19:11:20 +0200 Message-ID: <20260904171121.65300-5-roger@xenproject.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904171121.65300-1-roger@xenproject.org> References: <20260904171121.65300-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current implementation has two shortcomings for certain Xen usages: * When using the null scheduler it's possible for a CPU to never enter Xen context. A CPU not entering Xen context can block other CPUs from executing RCU callbacks, as there will be no quiescent state observed if the CPU doesn't enter Xen context. * If a certain amount of callbacks are pending, RCU will try to force a quiescent state, by sending an IPI to remote CPUs. This causes unwanted interference. Keep track of the RCU epoch when a callback was added, and only execute it once all CPUs are either outside of RCU critical regions, or any CPUs inside of RCU critical regions have entered such past the epoch when the callback was queued. Knowing whether a CPU is inside a RCU critical region is done based on the CPU rcu_lock_cnt value. There's an additional cost introduced in rcu_quiesce_{disable,enable}(), as we now need to use a full memory barrier on the outermost critical section entry/exit to make sure changes to rcu_lock_cnt cannot be reordered with accesses to RCU protected objects. This simplifies the current RCU implementation, as we get rid of grace/quiescent periods and a fair amount of logic to manage the state tracking. Signed-off-by: Roger Pau Monné --- The maximum batch of callbacks processed is limited to 10, this is bit arbitrary, but I think matches what the current logic attempts does. There's possibly some logic missing that rate-limits the amount of callbacks to process during a certain period. I can add those in v2 if the current approach is considered sane. Possibly there's a bit more pruning to do regarding the usage of grace and quiesce in comments or functions names - I leave that to either v2 or a different change. --- xen/common/rcupdate.c | 464 +++++++++---------------------------- xen/include/xen/rcupdate.h | 13 +- 2 files changed, 112 insertions(+), 365 deletions(-) diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c index bd63280fd63c..d3c11f45bfa0 100644 --- a/xen/common/rcupdate.c +++ b/xen/common/rcupdate.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -55,74 +56,28 @@ DEFINE_PER_CPU(unsigned int, rcu_lock_epoch); /* Current RCU epoch, bumped every time a new callback is queued. */ unsigned int rcu_epoch; -/* Global control variables for rcupdate callback mechanism. */ -static struct rcu_ctrlblk { - long cur; /* Current batch number. */ - long completed; /* Number of the last completed batch */ - int next_pending; /* Is the next batch already waiting? */ - - spinlock_t lock __cacheline_aligned; - cpumask_t cpumask; /* CPUs that need to switch in order ... */ - cpumask_t idle_cpumask; /* ... unless they are already idle */ - /* for current batch to proceed. */ -} __cacheline_aligned rcu_ctrlblk = { - .cur = -300, - .completed = -300, - .lock = SPIN_LOCK_UNLOCKED, -}; - -/* - * Per-CPU data for Read-Copy Update. - * nxtlist - new callbacks are added here - * curlist - current batch for which quiescent cycle started if any - */ +/* Per-CPU data for Read-Copy Update. */ struct rcu_data { - /* 1) quiescent state handling : */ - long quiescbatch; /* Batch # for grace period */ - int qs_pending; /* core waits for quiesc state */ - - /* 2) batch handling */ - long batch; /* Batch # for current RCU batch */ - struct rcu_head *nxtlist; - struct rcu_head **nxttail; - long qlen; /* # of queued callbacks */ - struct rcu_head *curlist; - struct rcu_head **curtail; - struct rcu_head *donelist; - struct rcu_head **donetail; - long blimit; /* Upper limit on a processed batch */ - int cpu; - long last_rs_qlen; /* qlen during the last resched */ - - /* 3) idle CPUs handling */ + /* + * List of pending callbacks, sorted by ascending epoch. Use a threshold + * value to raise an RCU softirq if the queue exceeds a given length. + */ + struct list_head pending; + unsigned int nr; +#define RCU_QUEUE_THRESHOLD 100 + + /* Idle CPU handling */ struct timer idle_timer; bool idle_timer_active; - bool process_callbacks; + /* Barrier handling. */ bool barrier_active; }; /* - * If a CPU with RCU callbacks queued goes idle, when the grace period is - * not finished yet, how can we make sure that the callbacks will eventually - * be executed? In Linux (2.6.21, the first "tickless idle" Linux kernel), - * the periodic timer tick would not be stopped for such CPU. Here in Xen, - * we (may) don't even have a periodic timer tick, so we need to use a - * special purpose timer. - * - * Such timer: - * 1) is armed only when a CPU with an RCU callback(s) queued goes idle - * before the end of the current grace period (_not_ for any CPUs that - * go idle!); - * 2) when it fires, it is only re-armed if the grace period is still - * running; - * 3) it is stopped immediately, if the CPU wakes up from idle and - * resumes 'normal' execution. - * - * About how far in the future the timer should be programmed each time, - * it's hard to tell (guess!!). Since this mimics Linux's periodic timer - * tick, take values used there as an indication. In Linux 2.6.21, tick - * period can be 10ms, 4ms, 3.33ms or 1ms. + * If a CPU with RCU callbacks queued goes idle before the callbacks can be + * drained use a timer to ensure the CPU is woken up to process the remaining + * callback queue. * * By default, we use 10ms, to enable at least some power saving on the * CPU that is going idle. The user can change this, via a boot time @@ -137,21 +92,18 @@ static s_time_t __read_mostly idle_timer_period; /* * Increment and decrement values for the idle timer handler. The algorithm * works as follows: - * - if the timer actually fires, and it finds out that the grace period isn't - * over yet, we add IDLE_TIMER_PERIOD_INCR to the timer's period; - * - if the timer actually fires and it finds the grace period over, we - * subtract IDLE_TIMER_PERIOD_DECR from the timer's period. + * - If the timer actually fires, and it finds out there are CPUs still in RCU + * critical regions, we add IDLE_TIMER_PERIOD_INCR to the timer's period. + * Note this is not very accurate, as the CPUs in those RCU critical regions + * might not be holding back the execution of the local callbacks. + * - If the timer actually fires and it finds no CPUs in critical RCU regions, + * we subtract IDLE_TIMER_PERIOD_DECR from the timer's period. */ #define IDLE_TIMER_PERIOD_INCR MILLISECS(10) #define IDLE_TIMER_PERIOD_DECR MICROSECS(100) static DEFINE_PER_CPU(struct rcu_data, rcu_data); -static int blimit = 10; -static int qhimark = 10000; -static int qlowmark = 100; -static int rsinterval = 1000; - /* * rcu_barrier() handling: * Two counters are used to synchronize rcu_barrier() work: @@ -246,35 +198,12 @@ void rcu_barrier(void) put_cpu_maps(); } -/* Is batch a before batch b ? */ -static inline int rcu_batch_before(long a, long b) -{ - return (a - b) < 0; -} - -static void force_quiescent_state(struct rcu_data *rdp, - struct rcu_ctrlblk *rcp) -{ - cpumask_t cpumask; - raise_softirq(RCU_SOFTIRQ); - if (unlikely(rdp->qlen - rdp->last_rs_qlen > rsinterval)) { - rdp->last_rs_qlen = rdp->qlen; - /* - * Don't send IPI to itself. With irqs disabled, - * rdp->cpu is the current cpu. - */ - cpumask_andnot(&cpumask, &rcp->cpumask, cpumask_of(rdp->cpu)); - cpumask_raise_softirq(&cpumask, RCU_SOFTIRQ); - } -} - /** * call_rcu - Queue an RCU callback for invocation after a grace period. * @head: structure to be used for queueing the RCU updates. * @func: actual update function to be invoked after the grace period * - * The update function will be invoked some time after a full grace - * period elapses, in other words after all currently executing RCU + * The update function will be invoked after all currently executing RCU * read-side critical sections have completed. RCU read-side critical * sections are delimited by rcu_read_lock() and rcu_read_unlock(), * and may be nested. @@ -283,205 +212,77 @@ void call_rcu(struct rcu_head *head, void (*func)(struct rcu_head *rcu)) { unsigned long flags; - struct rcu_data *rdp; + struct rcu_data *rdp = &this_cpu(rcu_data); head->func = func; - head->next = NULL; head->added = arch_fetch_and_add(&rcu_epoch, 1); local_irq_save(flags); - rdp = &this_cpu(rcu_data); - *rdp->nxttail = head; - rdp->nxttail = &head->next; - if (unlikely(++rdp->qlen > qhimark)) { - rdp->blimit = INT_MAX; - force_quiescent_state(rdp, &rcu_ctrlblk); - } - local_irq_restore(flags); -} - -/* - * Invoke the completed RCU callbacks. They are expected to be in - * a per-cpu list. - */ -static void rcu_do_batch(struct rcu_data *rdp) -{ - struct rcu_head *next, *list; - int count = 0; - - list = rdp->donelist; - while (list) { - next = rdp->donelist = list->next; - list->func(list); - list = next; - rdp->qlen--; - if (++count >= rdp->blimit) - break; - } - if (rdp->blimit == INT_MAX && rdp->qlen <= qlowmark) - rdp->blimit = blimit; - if (!rdp->donelist) - rdp->donetail = &rdp->donelist; - else - { - rdp->process_callbacks = true; - raise_softirq(RCU_SOFTIRQ); - } -} - -/* - * Grace period handling: - * The grace period handling consists out of two steps: - * - A new grace period is started. - * This is done by rcu_start_batch. The start is not broadcasted to - * all cpus, they must pick this up by comparing rcp->cur with - * rdp->quiescbatch. All cpus are recorded in the - * rcu_ctrlblk.cpumask bitmap. - * - All cpus must go through a quiescent state. - * Since the start of the grace period is not broadcasted, at least two - * calls to rcu_check_quiescent_state are required: - * The first call just notices that a new grace period is running. The - * following calls check if there was a quiescent state since the beginning - * of the grace period. If so, it updates rcu_ctrlblk.cpumask. If - * the bitmap is empty, then the grace period is completed. - * rcu_check_quiescent_state calls rcu_start_batch(0) to start the next grace - * period (if necessary). - */ -/* - * Register a new batch of callbacks, and start it up if there is currently no - * active batch and the batch to be registered has not already occurred. - * Caller must hold rcu_ctrlblk.lock. - */ -static void rcu_start_batch(struct rcu_ctrlblk *rcp) -{ - if (rcp->next_pending && - rcp->completed == rcp->cur) { - rcp->next_pending = 0; + list_add_tail(&head->list, &rdp->pending); + if ( ++rdp->nr > RCU_QUEUE_THRESHOLD ) /* - * next_pending == 0 must be visible in - * __rcu_process_callbacks() before it can see new value of cur. + * Raise a softirq to attempt to force draining the queue, albeit + * there's no guarantee. */ - smp_wmb(); - rcp->cur++; - - /* - * Make sure the increment of rcp->cur is visible so, even if a - * CPU that is about to go idle, is captured inside rcp->cpumask, - * rcu_pending() will return false, which then means cpu_quiet() - * will be invoked, before the CPU would actually enter idle. - * - * This barrier is paired with the one in rcu_idle_enter(). - */ - smp_mb(); - cpumask_andnot(&rcp->cpumask, &cpu_online_map, &rcp->idle_cpumask); - } -} - -/* - * cpu went through a quiescent state since the beginning of the grace period. - * Clear it from the cpu mask and complete the grace period if it was the last - * cpu. Start another grace period if someone has further entries pending - */ -static void cpu_quiet(int cpu, struct rcu_ctrlblk *rcp) -{ - cpumask_clear_cpu(cpu, &rcp->cpumask); - if (cpumask_empty(&rcp->cpumask)) { - /* batch completed ! */ - rcp->completed = rcp->cur; - rcu_start_batch(rcp); - } + raise_softirq(RCU_SOFTIRQ); + local_irq_restore(flags); } -/* - * Check if the cpu has gone through a quiescent state (say context - * switch). If so and if it already hasn't done so in this RCU - * quiescent cycle, then indicate that it has done so. - */ -static void rcu_check_quiescent_state(struct rcu_ctrlblk *rcp, - struct rcu_data *rdp) +#define RCU_MAX_BATCH 10 +static void cf_check rcu_process_callbacks(void) { - if (rdp->quiescbatch != rcp->cur) { - /* start new grace period: */ - rdp->qs_pending = 1; - rdp->quiescbatch = rcp->cur; - return; - } - - /* Grace period already completed for this cpu? - * qs_pending is checked instead of the actual bitmap to avoid - * cacheline trashing. - */ - if (!rdp->qs_pending) - return; - - rdp->qs_pending = 0; + static DEFINE_PER_CPU(cpumask_t, rcu_scratch); + cpumask_t *in_rcu = &this_cpu(rcu_scratch); + struct rcu_data *rdp = &this_cpu(rcu_data); + unsigned int queued = 0, cpu; + LIST_HEAD(expired); + struct rcu_head *rcu; - spin_lock(&rcp->lock); /* - * rdp->quiescbatch/rcp->cur and the cpu bitmap can come out of sync - * during cpu startup. Ignore the quiescent state. + * Populate a cpumask with any CPUs inside RCU critical regions. Note that + * CPUs entering past this point are of no interest, they will certainly + * use an epoch past any queued callbacks here. */ - if (likely(rdp->quiescbatch == rcp->cur)) - cpu_quiet(rdp->cpu, rcp); - - spin_unlock(&rcp->lock); -} - - -/* - * This does the RCU processing work from softirq context. - */ -static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp, - struct rcu_data *rdp) -{ - if (rdp->curlist && !rcu_batch_before(rcp->completed, rdp->batch)) { - *rdp->donetail = rdp->curlist; - rdp->donetail = rdp->curtail; - rdp->curlist = NULL; - rdp->curtail = &rdp->curlist; - } - - local_irq_disable(); - if (rdp->nxtlist && !rdp->curlist) { - rdp->curlist = rdp->nxtlist; - rdp->curtail = rdp->nxttail; - rdp->nxtlist = NULL; - rdp->nxttail = &rdp->nxtlist; - local_irq_enable(); - + cpumask_clear(in_rcu); + for_each_online_cpu ( cpu ) + if ( ACCESS_ONCE(per_cpu(rcu_lock_cnt, cpu)) ) + __cpumask_set_cpu(cpu, in_rcu); + + while ( queued < RCU_MAX_BATCH && + (rcu = list_first_entry_or_null(&rdp->pending, struct rcu_head, + list)) ) + { /* - * start the next batch of callbacks - */ - - /* determine batch number */ - rdp->batch = rcp->cur + 1; - /* see the comment and corresponding wmb() in - * the rcu_start_batch() + * Fetching rcu_lock_epoch out of order is not a concern here: in the + * worst case it's going to result in an older more restrictive epoch + * being checked against. Note the adding of a callback issues a + * arch_fetch_and_add() which is a barrier on itself, and guarantees + * remote changes to the CPU mask to be visible here. */ - smp_rmb(); - - if (!rcp->next_pending) { - /* and start it/schedule start if it's a new batch */ - spin_lock(&rcp->lock); - rcp->next_pending = 1; - rcu_start_batch(rcp); - spin_unlock(&rcp->lock); - } - } else { - local_irq_enable(); + for_each_cpu ( cpu, in_rcu ) + if ( (int)(ACCESS_ONCE(per_cpu(rcu_lock_epoch, cpu)) - + rcu->added) <= 0 ) + /* + * Callbacks are sorted, exit loop as soon as we find one that + * can't be processed yet. + */ + goto process; + + list_del(&rcu->list); + list_add_tail(&rcu->list, &expired); + ASSERT(rdp->nr); + rdp->nr--; + queued++; } - rcu_check_quiescent_state(rcp, rdp); - if (rdp->donelist) - rcu_do_batch(rdp); -} -static void cf_check rcu_process_callbacks(void) -{ - struct rcu_data *rdp = &this_cpu(rcu_data); + if ( queued == RCU_MAX_BATCH && rdp->nr ) + /* There's more work to do, yield and raise a softirq to come back. */ + raise_softirq(RCU_SOFTIRQ); - if ( rdp->process_callbacks ) + process: + while ( (rcu = list_first_entry_or_null(&expired, struct rcu_head, list)) ) { - rdp->process_callbacks = false; - __rcu_process_callbacks(&rcu_ctrlblk, rdp); + list_del(&rcu->list); + rcu->func(rcu); } if ( atomic_read(&cpu_count) && !rdp->barrier_active ) @@ -492,33 +293,9 @@ static void cf_check rcu_process_callbacks(void) } } -static int __rcu_pending(struct rcu_ctrlblk *rcp, struct rcu_data *rdp) -{ - /* This cpu has pending rcu entries and the grace period - * for them has completed. - */ - if (rdp->curlist && !rcu_batch_before(rcp->completed, rdp->batch)) - return 1; - - /* This cpu has no pending entries, but there are new entries */ - if (!rdp->curlist && rdp->nxtlist) - return 1; - - /* This cpu has finished callbacks to invoke */ - if (rdp->donelist) - return 1; - - /* The rcu core waits for a quiescent state from the cpu */ - if (rdp->quiescbatch != rcp->cur || rdp->qs_pending) - return 1; - - /* nothing to do */ - return 0; -} - bool rcu_pending(unsigned int cpu) { - return !!__rcu_pending(&rcu_ctrlblk, &per_cpu(rcu_data, cpu)); + return !!per_cpu(rcu_data, cpu).nr; } /* @@ -529,15 +306,13 @@ bool rcu_pending(unsigned int cpu) */ bool rcu_needs_cpu(unsigned int cpu) { - struct rcu_data *rdp = &per_cpu(rcu_data, cpu); - - return (rdp->curlist && !rdp->idle_timer_active) || rcu_pending(cpu); + return rcu_pending(cpu); } /* * Timer for making sure the CPU where a callback is queued does * periodically poke rcu_pending(), so that it will invoke the callback - * not too late after the end of the grace period. + * not too late. */ static void rcu_idle_timer_start(void) { @@ -545,10 +320,9 @@ static void rcu_idle_timer_start(void) /* * Note that we don't check rcu_pending() here. In fact, we don't want - * the timer armed on CPUs that are in the process of quiescing while - * going idle, unless they really are the ones with a queued callback. + * the timer armed on CPUs that don't have pending callbacks. */ - if (likely(!rdp->curlist)) + if (likely(!rdp->nr)) return; set_timer(&rdp->idle_timer, NOW() + idle_timer_period); @@ -587,7 +361,7 @@ static void cf_check rcu_idle_timer_handler(void* data) { perfc_incr(rcu_idle_timer); - if ( !cpumask_empty(&rcu_ctrlblk.cpumask) ) + if ( this_cpu(rcu_data).nr ) idle_timer_period = min(idle_timer_period + IDLE_TIMER_PERIOD_INCR, IDLE_TIMER_PERIOD_MAX); else @@ -597,55 +371,43 @@ static void cf_check rcu_idle_timer_handler(void* data) void rcu_check_callbacks(unsigned int cpu) { - struct rcu_data *rdp = &this_cpu(rcu_data); - - rdp->process_callbacks = true; raise_softirq(RCU_SOFTIRQ); } -static void rcu_move_batch(struct rcu_data *this_rdp, struct rcu_head *list, - struct rcu_head **tail) +/* Sorting functions for RCU list concatenation when a CPU goes offline. */ +static int cmp_rcu(void *priv, struct list_head *a, struct list_head *b) { - local_irq_disable(); - *this_rdp->nxttail = list; - if (list) - this_rdp->nxttail = tail; - local_irq_enable(); + const struct rcu_head *l = container_of(a, struct rcu_head, list), + *r = container_of(b, struct rcu_head, list); + + return (int)(l->added - r->added); } static void rcu_offline_cpu(struct rcu_data *this_rdp, - struct rcu_ctrlblk *rcp, struct rcu_data *rdp) + struct rcu_data *rdp) { kill_timer(&rdp->idle_timer); - /* If the cpu going offline owns the grace period we can block - * indefinitely waiting for it, so flush it here. - */ - spin_lock(&rcp->lock); - if (rcp->cur != rcp->completed) - cpu_quiet(rdp->cpu, rcp); - spin_unlock(&rcp->lock); - - rcu_move_batch(this_rdp, rdp->donelist, rdp->donetail); - rcu_move_batch(this_rdp, rdp->curlist, rdp->curtail); - rcu_move_batch(this_rdp, rdp->nxtlist, rdp->nxttail); + if ( !rdp->nr ) + return; + /* + * Append pending callbacks to the current CPU. By the time this is + * executed the CPU going offline cannot be in any RCU critical section or + * queue any more RCU work. + */ local_irq_disable(); - this_rdp->qlen += rdp->qlen; + list_splice(&rdp->pending, &this_rdp->pending); + this_rdp->nr += rdp->nr; + INIT_LIST_HEAD(&rdp->pending); + list_sort(NULL, &this_rdp->pending, cmp_rcu); local_irq_enable(); } -static void rcu_init_percpu_data(int cpu, struct rcu_ctrlblk *rcp, - struct rcu_data *rdp) +static void rcu_init_percpu_data(int cpu, struct rcu_data *rdp) { memset(rdp, 0, sizeof(*rdp)); - rdp->curtail = &rdp->curlist; - rdp->nxttail = &rdp->nxtlist; - rdp->donetail = &rdp->donelist; - rdp->quiescbatch = rcp->completed; - rdp->qs_pending = 0; - rdp->cpu = cpu; - rdp->blimit = blimit; + INIT_LIST_HEAD(&rdp->pending); init_timer(&rdp->idle_timer, rcu_idle_timer_handler, rdp, cpu); } @@ -658,11 +420,11 @@ static int cf_check cpu_callback( switch ( action ) { case CPU_UP_PREPARE: - rcu_init_percpu_data(cpu, &rcu_ctrlblk, rdp); + rcu_init_percpu_data(cpu, rdp); break; case CPU_UP_CANCELED: case CPU_DEAD: - rcu_offline_cpu(&this_cpu(rcu_data), &rcu_ctrlblk, rdp); + rcu_offline_cpu(&this_cpu(rcu_data), rdp); break; default: break; @@ -693,36 +455,18 @@ void __init rcu_init(void) } idle_timer_period = MILLISECS(idle_timer_period_ms); - cpumask_clear(&rcu_ctrlblk.idle_cpumask); cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu); register_cpu_notifier(&cpu_nfb); open_softirq(RCU_SOFTIRQ, rcu_process_callbacks); } -/* - * The CPU is becoming idle, so no more read side critical - * sections, and one more step toward grace period. - */ +/* The CPU is becoming idle, ensure pending RCU work will get processed. */ void rcu_idle_enter(unsigned int cpu) { - ASSERT(!cpumask_test_cpu(cpu, &rcu_ctrlblk.idle_cpumask)); - cpumask_set_cpu(cpu, &rcu_ctrlblk.idle_cpumask); - /* - * If some other CPU is starting a new grace period, we'll notice that - * by seeing a new value in rcp->cur (different than our quiescbatch). - * That will force us all the way until cpu_quiet(), clearing our bit - * in rcp->cpumask, even in case we managed to get in there. - * - * Se the comment before cpumask_andnot() in rcu_start_batch(). - */ - smp_mb(); - rcu_idle_timer_start(); } void rcu_idle_exit(unsigned int cpu) { rcu_idle_timer_stop(); - ASSERT(cpumask_test_cpu(cpu, &rcu_ctrlblk.idle_cpumask)); - cpumask_clear_cpu(cpu, &rcu_ctrlblk.idle_cpumask); } diff --git a/xen/include/xen/rcupdate.h b/xen/include/xen/rcupdate.h index 6c265c672c14..9c3e06bbe6e8 100644 --- a/xen/include/xen/rcupdate.h +++ b/xen/include/xen/rcupdate.h @@ -35,6 +35,7 @@ #include #include #include +#include #include #include @@ -72,19 +73,21 @@ static inline bool rcu_quiesce_allowed(void) /** * struct rcu_head - callback structure for use with RCU - * @next: next update requests in a list + * @list: list anchor. * @func: actual update function to call after the grace period. + * @added: epoch when the callback was added. */ struct rcu_head { - struct rcu_head *next; + struct list_head list; void (*func)(struct rcu_head *head); unsigned int added; }; -#define RCU_HEAD_INIT { .next = NULL, .func = NULL } -#define RCU_HEAD(head) struct rcu_head head = RCU_HEAD_INIT +#define RCU_HEAD_INIT(head) { .list = LIST_HEAD_INIT((head).list), \ + .func = NULL } +#define RCU_HEAD(head) struct rcu_head head = RCU_HEAD_INIT(head) #define INIT_RCU_HEAD(ptr) do { \ - (ptr)->next = NULL; (ptr)->func = NULL; \ + INIT_LIST_HEAD(&(ptr)->list); (ptr)->func = NULL; \ } while (0) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 17:14:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 17:14:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408906.1641208 (Exim 4.92) (envelope-from ) id 1x2XUn-0004BB-0U; Fri, 04 Sep 2026 17:14:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408906.1641208; Fri, 04 Sep 2026 17:14:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUm-0004B4-TE; Fri, 04 Sep 2026 17:14:32 +0000 Received: by outflank-mailman (input) for mailman id 1408906; Fri, 04 Sep 2026 17:14:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2XUl-000469-L5 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 17:14:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2XUk-005Kkr-2N; Fri, 04 Sep 2026 17:14:30 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x2XUk-000Q84-0Z; Fri, 04 Sep 2026 17:14:30 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=i3K9AqM6qwFFz7KWpD8EsWRfNCM+xPNYSDsWiwSOLiU=; b=loTAIcNBrVQJjRtRs4qxjFYDS1 FKHo8hmBkLhMqoDzF8TXlo7qmhgLMCU94UiJqMpTQ8qubpeckKzjXYOZoFiTwqAuYWKB6HK6/NPRn rDcFvoeW2qgK7x2eRQQiMZ6lUd2HVjdvIGZAuwLEFzF3gmytfvVmwPe2PU/nz/2UB080=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?J=C3=BCrgen=20Gro=C3=9F?= , Roger Pau Monne , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH 5/5] xen/rcu: remove rcu_needs_cpu() Date: Fri, 4 Sep 2026 19:11:21 +0200 Message-ID: <20260904171121.65300-6-roger@xenproject.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904171121.65300-1-roger@xenproject.org> References: <20260904171121.65300-1-roger@xenproject.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit After the changes to the RCU logic, there's no longer a difference between rcu_pending() and rcu_needs_cpu(). With the previous implementation rcu_pending() signaled whether there was RCU work ready to handle, while rcu_needs_cpu() signaled whether the CPU had queued RCU callback that could not yet execute. With the new logic figuring out whether callbacks can be executed requires more work, and hence is deferred to the processing logic in rcu_process_callbacks(). Both rcu_pending() and rcu_needs_cpu() return whether there's any pending work, without making guarantees any callbacks are ready to be executed. Given this lack of difference, remove rcu_needs_cpu() and use rcu_pending() in cpu_is_haltable(). Signed-off-by: Roger Pau Monné --- xen/common/rcupdate.c | 11 ----------- xen/include/xen/rcupdate.h | 7 +++++-- xen/include/xen/sched.h | 2 +- 3 files changed, 6 insertions(+), 14 deletions(-) diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c index d3c11f45bfa0..c8164b0ad7e0 100644 --- a/xen/common/rcupdate.c +++ b/xen/common/rcupdate.c @@ -298,17 +298,6 @@ bool rcu_pending(unsigned int cpu) return !!per_cpu(rcu_data, cpu).nr; } -/* - * Check to see if any future RCU-related work will need to be done - * by the current CPU, even if none need be done immediately, returning - * true if so. This function is part of the RCU implementation; it is -not- - * an exported member of the RCU API. - */ -bool rcu_needs_cpu(unsigned int cpu) -{ - return rcu_pending(cpu); -} - /* * Timer for making sure the CPU where a callback is queued does * periodically poke rcu_pending(), so that it will invoke the callback diff --git a/xen/include/xen/rcupdate.h b/xen/include/xen/rcupdate.h index 9c3e06bbe6e8..1700b73a6c3b 100644 --- a/xen/include/xen/rcupdate.h +++ b/xen/include/xen/rcupdate.h @@ -90,9 +90,12 @@ struct rcu_head { INIT_LIST_HEAD(&(ptr)->list); (ptr)->func = NULL; \ } while (0) - +/* + * Check whether there's pending RCU work queued on this CPU. This merely + * signals whether there are callbacks pending, there's no guarantee that any + * callbacks are ready to be executed. + */ bool rcu_pending(unsigned int cpu); -bool rcu_needs_cpu(unsigned int cpu); /* * Dummy lock type for passing to rcu_read_{lock,unlock}. Currently exists diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index e352e2b38e7d..5bccf9b748a6 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -1155,7 +1155,7 @@ void scheduler_disable(void); * the tasklet_work_to_do() helper). */ #define cpu_is_haltable(cpu) \ - (!rcu_needs_cpu(cpu) && \ + (!rcu_pending(cpu) && \ !softirq_pending(cpu) && \ cpu_online(cpu) && \ !per_cpu(tasklet_work_to_do, cpu)) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 17:37:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 17:37:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408955.1641217 (Exim 4.92) (envelope-from ) id 1x2Xqq-0000Dj-UV; Fri, 04 Sep 2026 17:37:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408955.1641217; Fri, 04 Sep 2026 17:37:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Xqq-0000Dc-Rl; Fri, 04 Sep 2026 17:37:20 +0000 Received: by outflank-mailman (input) for mailman id 1408955; Fri, 04 Sep 2026 17:37:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Xqp-0000DW-H2 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 17:37:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Xqo-00AuMp-QF for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 19:37:18 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b01a7-bab6-0a2a0a5309dd-0a2a450a81fa-24 for ; Fri, 04 Sep 2026 19:37:18 +0200 Received: from [52.101.85.63] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b01cc-f2d2-0a2a450a0019-3465553f1a63-3 for ; Fri, 04 Sep 2026 19:37:18 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH4PR03MB7745.namprd03.prod.outlook.com (2603:10b6:610:243::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 17:37:15 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Fri, 4 Sep 2026 17:37:15 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=O5AXKIm81qxT6fHzKwsf061NIYgfxi3Y9K7mGmNisNVQJAwoceDSGNArg8AApNFKyyfKcIwntMhu/LgUtPEEbrqz6ZkkQJAWjBsG04uK061UfSQTsS670gdLNY2Sm7YFheFfMPepEWtkMxBr9NU/aJeXXXFrHNcFENsVl16UNocgwmshjVIIL1Jy9octn892Gjw8xt9/GAeETBVR9YTXLhH3V3Zrpj5nAGwc6UB67WimgFattUzzIRwtih12w6nGVQ1Xx3arl/wFYKITJUWCLnwn1jE1IWyh6aHZZnndXYEoq7eSXiYkT4bGHpBl0r0JSEtMeSqYUJpY2c+PQl8B5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qe4XvzUfjP/2ntOZwR0gFrXJFwGGLI3w3WixppGkrTQ=; b=EzO1fU5afBIoTLMLK4aWwYzJBp7jro+nKhlJqlWBG50TeJbXR2dR41jQT3G2FnyhSJjA7+6njOziHOnfRSWIJn7Fo6pgDNYw8TaKRCk9lq4xl1WEzzXY1uhozeOoh/nMccw6O0ms8sOByLTrMsZ1zNj3TQCh/gEWiMbt2/f/xMJTVGiupYwOPuh55vKucRG5xt/CdH5KmZviF/qK35X4RzRCxFK3LNCjoK0PB75f50xFBEZRCYBZ16g0NEXSw0wQHHDvhEl4fTfGmTJ1bGqJJfTpwwgIoUdaBIxed1Zegm30U9wCZW/krCli1QkjFmx3UEXtFtyIKSP1EwOAGoPHkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qe4XvzUfjP/2ntOZwR0gFrXJFwGGLI3w3WixppGkrTQ=; b=CcRsqobKIPc41yr88vewErSjd+TQTSK+j1jcFs5qds2pzqSv6ym7nZSXg9PdEg1VoWE+o/Q8r2AoF1q9QRugVDjNWgF/fBQoCdklLdhs1QLHOPpkJSxIRMF92Fnl9TB8QRLsaDAYPDLuevYk3jmczhGXVm5eemOY1pOUiQfk6KU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 4 Sep 2026 18:37:11 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH] nestedsvm: Crash domain rather than Xen on unexpected VMEXIT To: Ross Lagerwall , xen-devel@lists.xenproject.org References: <20260904142757.375773-1-ross.lagerwall@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260904142757.375773-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0221.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:33a::20) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH4PR03MB7745:EE_ X-MS-Office365-Filtering-Correlation-Id: 7b87c727-fc4f-4035-cd77-08df0aab28a0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|11063799006|18002099003|22082099003|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: 4Ll8b8v/Z6p8nAJy77KNO7h+edmOqghHX75idTNYVDPahFuv0JfYEG8U58xzYSSWXVbGj1JHQP1OZqWGKTsUxgKlsqtt9bhdv4LVtzWa8UxQDCweseck0g60EJK53G53ZB0lOD5Dq4zCRVEKoOQl836Pz6pCsnP8USgCI5XR6Q3Bp6XavFyDzfWgPK/rCqNUfXyBfhDGkKKGF4hcP6nx7Kf6bCCO+Rcum/5QVoufbCoolIp5udg7cn5ih33EOtnttMMykMubW3UEcDh3e4YCDMtFQkziGlZvjAqf4Rnfj6rVgtPs/2QuknkE5k8XVkAENwoGfv3f21R1gD/mxZySl5MK1O1FK/JJy3306B2AZvkB4IwHiLm+sz5mWvxxxhI/F25iPea9rhOQRM/YjKbZedxRJdRLSc5e6H6EroMYbrfsp3IzOFO707TcBkiIT6xCjlghpQuRp/gWst2oPIUAgXwq/ZuYeu73jC8+H9VhSShnNytymC5AllQ23xlzJc7LllxKzEWQt/8hS7X5Y6z0QxFNKkg0M0fXxM9KYA52PAKoKkEvOauo+KFS2GDFtJfOGgwTKfllDM69w0lENzOgh4891/nW5Wi39Q1FNCoCKGnlSlxQeYireresusKVOk25nHVDeD66m2AWU3yyh9pdLg2Ld6am18OJuZjuCsQjIr0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(11063799006)(18002099003)(22082099003)(10067099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y3cvNGZNaXJUUGhHVjBmd0x3N09YK0JaVitrV1ZLTlFmTWNveUFlbTRhZ0lS?= =?utf-8?B?VzNmRTBqY1Z6R2tGZXhoVERnS0tKV01IRk9Md2FOdC9vaEhrRlBRWnA2VnVi?= =?utf-8?B?dTVkMVY0ajZwR1drUC9CL3BvVHNITitHNms0QW1vbWdlM3NVZnpUaE5HOFVO?= =?utf-8?B?MEZDblNUeGJwRlg3cFI4Wk5NU3lPRldWRkxlSEdCSVl6bXFvQTZFTHJrM2Fo?= =?utf-8?B?U3ZYbUNIV2lQUDZzdHNvVW9XMm04enNoR0V0ZUhCaDZyMGhjcTJoRzlUUks5?= =?utf-8?B?U24zOTExSXBmTmFIeUNpbi9ZME4zdEJabElKZDVlYU15VlBLSXljOEY5bWdS?= =?utf-8?B?Q0RKaEloV3FqU05rOWJ6T1JoK0FzMGVrdGxJV05NMC9RNVBVeERua3EzWmx1?= =?utf-8?B?cndpenZhSUNXU3BEL3dVenFvbDZWVlpBSWlaTklCOUMxdlhhelNLWmNjTDl0?= =?utf-8?B?Uk1uNG0rTkxoT2IyYjA2c2t1Y2VDc3c1U0o0Q2NBQ3VGa3R0OUtjTjYyTzhU?= =?utf-8?B?T3luVlFNM2VXREY3c0p6aEZHYUUxMWRjdlZnVXBzL0ZvTTcwQ2JrUm5XS3Zu?= =?utf-8?B?bXYrQS8weTU3UW5MTHpHUEYxN3ZkU0ppMjR2OE9PbDdHeWlMcGc2THErS3I5?= =?utf-8?B?MmgrR3NIZzRnb0J3TllQM1pHNi9ycS9NN0RMc1NiZzgydXk1dWZmZXBFWlhK?= =?utf-8?B?RVMzaElrVVJ3b1lQYWtZYXVoMG5tbmQ0cGpDYmpSbWZwSHk5VXJoTFAxWmFr?= =?utf-8?B?a3JnbExPeDRORmlaa1hWSkNaL3EzaXAvUzhRV1ZZRlFVbFo1WUIrS3dXcW5v?= =?utf-8?B?dFhhLzBhOEl4bklHZURLSFk0N3JzY0NKQnZINFJINkcwTW1TUEJLREdobUNI?= =?utf-8?B?dHdBWHcxY0FqOGx6aVBXZjZiSjNWVEhXU1ZTNXgzS3AyNzVIVnlPamVXdlNF?= =?utf-8?B?UmtrTnNtc0Q0d2JuZXZOb0xScDVxV3NUVjBIVTc1aVEvSHl1U1QzdFFCSFhC?= =?utf-8?B?SDJVKzlzcGtXV2s4T3c5TVA4N0Q3ZS9SSjBQcUVhc1Z1REpnRDFGYzhaUWdV?= =?utf-8?B?YURFdUlzMlgvaURwVldNWTFuYkQ0d2ovR3hIcU1aYjBGQjRNUUhqTlBodGs5?= =?utf-8?B?ZmVodUczNGtKYlJVb1BXZmlpNTdjRlJSS2h2ZjdabWp5L09sUW1nT2VxLzRO?= =?utf-8?B?YzB4OWdGOVNRbE5lMVZodnpaV0piQjhMRGpHbTd6VG1lSmNPRGVicEJqUU1Y?= =?utf-8?B?dnRhclVmOGVhTmFnVmFpbnNFekhNSWkvN2dVR0FEL2dYNzI1eW52WGpOcmVO?= =?utf-8?B?cnh4a0RqNXQ2VEVyUEVURGtTUGVUOUFXWjBDcnB1QzloUDQxTHdpYUlJYm91?= =?utf-8?B?bE9SekRmNzN6bmlDTExJOHVITGNmcHNaQzhYMmFMdEVpMmIyOFh0TlMzSVh2?= =?utf-8?B?dWxpbit5ejFvV3J0ckRUNHVFMTlUQUhKeFBjUytIT25NQVJjY3pNbDdVUUhN?= =?utf-8?B?MFpacU1UVTBHcHVRZ1pHUTNwNGxDa3gxWlloNm1VR1h5eGVXb1hZenRxY0I5?= =?utf-8?B?RUFlZnBtTVFsZlh4bnQxMkpiYVJPYTJUVGNkY2NRdlVTQ0o1WThPZ2NXOHRz?= =?utf-8?B?SGRYaHI3RWtaaUszVVQrYUhZRG11Smh6MENJZTZxNWtzVjFCTlZOR1lBeW1y?= =?utf-8?B?VlRNdUZablA1S29ubU84NjB5SWN4SElyVTA3SS95VVYxWTRQUDJTc1lPOU82?= =?utf-8?B?MHJCU1lqZGxteWMvc0tRb09Sa0ZRalNLL2U4bWlYa3NXTDVwdVpZTUJqWlY3?= =?utf-8?B?SEhGVXducXVtS2Q4dXNxRkFHVlE1cmFtVndhc0d4NC91VEZRQitleXpEZGU4?= =?utf-8?B?TjRjY0wwRk1Oai83Rll6TDJodkRFMlFhRGRFaVh2aEtNWE9VaS84TFJDdnlV?= =?utf-8?B?Y2NJRUZqdzFiWEU2UHA1N0IxWXN6UDBCcjlTdUNyU3Zlc0x5UVN4ZU0wVHdV?= =?utf-8?B?T2JkMUFLeWIwcHJ1WW9rdWZpbm9VSzkwTFhQSURLSUxKNU9wWFBxKysyWERJ?= =?utf-8?B?N1FwbTFDZ1U1Y2poODRvWG9mcytMYkEyOE5sWHpRUHBiQjkvL2I4V2lYd012?= =?utf-8?B?RzNZUkdRYUJTaHFsU2d3VnVqVW9FSWhVVUU4OVdsY1R2dm50RHVGcFJPRzFa?= =?utf-8?B?VS83RkRXaVQrTDhLOXNFR3JwdmxoVFdpaFpMcW9MeGVHWlJJdVN4U0V6RG9B?= =?utf-8?B?K2FxV0lBL0lzUnJsY3NwZVpTT2NsQU16djFnWjdSbzZaM2xCTDdWR3FTeWxD?= =?utf-8?B?Y1pHWjBhU09rOUI0SndxMmViUjdiT0hCWFVEaW1Ic3BZbCtQMTlGWTJDbGRt?= =?utf-8?Q?KMUtr5wpPIfL+M0E=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b87c727-fc4f-4035-cd77-08df0aab28a0 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 17:37:14.8884 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vw6bwL5AVoSzBOyt6rgA98Rm/3zo+M+hobnfmavin4CT8aqMM5E6IWPY0CD3GGzadjliajKLBKxymbDrG0Ym47ZFORktlnpxzSlj2zPLZAI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7745 X-purgate-ID: tlsNG-4011c0/1788543438-530D9CFC-330A8DCF/0/0 X-purgate-type: clean X-purgate-size: 414 On 04/09/2026 3:27 pm, Ross Lagerwall wrote: > On encountering an unexpected VMEXIT (e.g. because L1 has used an > intercept that L0 Xen doesn't know about), crash the domain rather than > the hypervisor. > > Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") > Signed-off-by: Ross Lagerwall Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Sep 04 18:20:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 18:20:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1408993.1641226 (Exim 4.92) (envelope-from ) id 1x2YWR-0007Nk-0l; Fri, 04 Sep 2026 18:20:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1408993.1641226; Fri, 04 Sep 2026 18:20:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2YWQ-0007Nd-UA; Fri, 04 Sep 2026 18:20:18 +0000 Received: by outflank-mailman (input) for mailman id 1408993; Fri, 04 Sep 2026 18:20:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2YWP-0007NX-B6 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 18:20:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2YWO-0007Zn-5q for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 20:20:16 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b0ba2-2eae-0a2a0a5409dd-0a2a4503b2c6-34 for ; Fri, 04 Sep 2026 20:20:16 +0200 Received: from [52.101.57.8] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b0bdf-fae8-0a2a45030019-346539082ecf-3 for ; Fri, 04 Sep 2026 20:20:15 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA6PR03MB7854.namprd03.prod.outlook.com (2603:10b6:806:433::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 18:20:12 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Fri, 4 Sep 2026 18:20:12 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HymuAomGaQejLO/QPpK6byFpfFTFTRkaGQHAYNUbwm07TguEEf7OiJUG3IK1Jzpfwa+95KxoFqanGBMpTQEPvndKcRY41waYSk7Mx6Lb97cPBPB6diqqMUEthkCmCMIawciHy5j8LS1OvCTG5/TkV+BUA6fptfSmTm6U+FMRmtxteF14a4iP7qUvRtJDfIZblnYGxCmTJRAC9uvE8sXDcht4aBo0oOfa++4zR8CPNLMloanwIex2seOPPXYGMnaNIxF3GTlcS9LL5w3dswWu/VYdJ3YaAUg+Pk+SfQVZsy4Nd8dS8e25Zk5K4A25q4k8zlL28taYfPSxIEvAX/At+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5qaKEsLC8SALULxW4bwGJJYR6zksEJVMDAwXSqFpIoY=; b=aPfUGAkAGTIXzxlOqPKaejDOHZ7xvgk7xECo9fB5qPBlPTTQ1kLQVZxmYiz2O5IdO0f4AbCYPdXYonFZqbnJm3jpf4vSx+SQYFqJDpuPmcW1r62zXE/V+ClZrXpkEaiuNt2MlzHD/xZS4VXf8sR3NG+s2Uy9f6EyXmCtIW3GhwdsD258+12JG1u/FUYNGHPa2j8z2rZ6APN+5fn7KXfHmxDrweMdSN/tJH3h/BjN1mwTglKgDI3Me+uKV0imYpcAA2MlfC67x/S1Rx9mPy4SRKpy7Q5Zijn+QF986xHYbYOXI7iTIeiP3IB/LqvUT+NX/rjxr/KwLWuAME9vebOBwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5qaKEsLC8SALULxW4bwGJJYR6zksEJVMDAwXSqFpIoY=; b=rnHaD/2JpGc2wVWmvVSXVrqzwHiuvA/jkicIQUcvu5gl3hXeoCO64cV1J1c1o1CtupDcfyRgfMVQSmo69zoHLDDLzl81wJFtbNAG1TauOPPnl1GNsVsLV/qkK7zMxmBkiZuW+MQrs48BDCP6XTFgj97tjoMhvYCNm5clE213Zn8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1dbfedb4-d3a3-4d11-9b24-dea509c38dad@citrix.com> Date: Fri, 4 Sep 2026 19:20:08 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH v2 5/5] xen/arm: Rewrite arm_smccc_*() to return by value To: Bertrand Marquis References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> <20260904111228.3022634-6-andrew.cooper3@citrix.com> <9301544B-8F8D-4E27-9BFA-B7244633B41F@arm.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <9301544B-8F8D-4E27-9BFA-B7244633B41F@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P123CA0095.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:139::10) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA6PR03MB7854:EE_ X-MS-Office365-Filtering-Correlation-Id: 4675eb76-891d-4500-d3a9-08df0ab128b8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|3023799007|18002099003|10067099003|4143699003|56012099006|11063799006|22082099003; X-Microsoft-Antispam-Message-Info: xrg+soBStrgt7/t6DoU24UxHM1TvP9EK9RZbNYXSD0W8S2hmBbGtc8j9jYbpnZGm/99jScXczXJtvGOTnp23QsOqkcAI4+emkXyJIgOyuOhAIKNAQQBIbNg+yEabPucW4+k0tCPCNCHws4QhxMdbRKx83AHgypUWFupxx4A92KnwVEvG/WL0jMkH5egSgHAuNHPKiRIQ7Qz7pwSUD+LPla7y5B3At+OfAKUIvI93jJUAYQ3xaYhFTB+J1xENppt+VdAt3oJiFrApYYy6nG2AEQ/9FW2xYE/i5Evk2lHFl6tVjUvAG3CyNqNJuROFip+fZNKEeI8c7x9dJH4/D/3cAVv8Fs3On3I6TydAtdc2WDgPB811aGR5N2CsARfCNIUPyL+dicZ8Qvs/Xv7FmqZTK+OfzTxQBoHL90Ku4GaM3UabQiY3i0Y66ZwrhnmEbaarVl0u7stuD4lrXxInOk+02LbD+t1vHwJENrmVXMO+7OJ/rDS8Q59BWe4t5l2n4V2Q0t15MSIAc7lyNd3aEKoepXpz01OG5+fHWK2r1kPuqo+RzJ27JrXb9NZOEKqj1bTBO1q571/GSZk+Oep04i0MhJOzjDGIMYVu9ZfuxbUM28RF0svpg6OhZb8GPJwmiShpy4bRGY0W1D4mPKqUXg0F99t8p667H/AgINxwb4TG0KU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(3023799007)(18002099003)(10067099003)(4143699003)(56012099006)(11063799006)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QnJTNHh2TktVT1hzVy9QVGRXMjdnc2J2ZlNSamZKZDdHajBRL0hXMnN0ZWZR?= =?utf-8?B?QWlTTkJ2dmk4ZlZtdnVudkZLakMzdDVQTExrd25nWHQyNlkrOE9mOGh4aTBG?= =?utf-8?B?d3JzbDA2WGEyY2JVaE15cDRmellBT2NwWDFhRk00QW5JMG9nMWFURjFSMWJJ?= =?utf-8?B?bEYxMXo2Z1lmYUQrT3hLZmdEeGVDczhPUGhNdW5qTVRDQjhlRmtuK1RHUFkv?= =?utf-8?B?MktSR2JTNlBSVjF3WjRkRVFwalZ1Zk5ncnE3bGc2SzlCNEp5bXhXVXJsd2hD?= =?utf-8?B?MThpRnowdnV0Z3hBd2VCR085NVIzSlQzNm54ZjN1dWVFS1I2ZFcwZ3FyVG5r?= =?utf-8?B?bGxMSHhrYWFjeG1uNHZMS0RIaWk1aHB4MDU5ZHYwc2RMaFQyRk1xdU5uRTdQ?= =?utf-8?B?SzNLT0pSVjdUbHZDWFJ2aUx5N2VjVmxxVlNRV01DRjF3ZFg5SS8ycnZLMDFT?= =?utf-8?B?UjROcDNZUkF3b2VCclhzVGM2dkcwc3RzVFJITDJYWXBVc0VNVWxLZlBFbkw3?= =?utf-8?B?Y1U4eThwWE5MM1d5RzcyeEUzNGlBenFvSmxQUEQxNktGbzNJZ2tSamkvK1Zj?= =?utf-8?B?bHkycGlOTDhMTVhaaTU2ZWMxTXBIUkd5K0xOekh3emJKZGI4VjMwejQ1TlU5?= =?utf-8?B?REVnSVJqditIR3c5bENPbnJGUHJGckpNdDRWSVBET0w1aTkrcjFpODdhQnd6?= =?utf-8?B?eTJoZ004elY5VHdtTEZMUDNRMU5kZWFkUGFRM2s1QVpaNzFGMjFVVlRobTVa?= =?utf-8?B?MjI4V2F0MzdaMjNpZ1lhSUFVbFpqbDBqcUtYWWdEN0RmdGZoYUNjdlpTZmlt?= =?utf-8?B?T1I2RWF0TlpmUWdzeTZXSW05NjNmOEFLS0U1OWhTaUdVaEFDU21ZTkw0UmEx?= =?utf-8?B?Z295NmRpUlZJdDFQY2tJdk01UDdURmYyK3htZ2ovbEt3cUxJajM0Y2Z6akNv?= =?utf-8?B?WG4rTHdSYUl1RVBCV2c2Y3pBdDlNWFl6WnZvaVFqZkZqWWVUQWE0NnlyUmxk?= =?utf-8?B?RzRkQ0VJRG9Sek1Hd3NXN3FENXZkTHlCZXhZQXFBQmlodit4YnlyMng1KzBN?= =?utf-8?B?YVM5TFJSNDN6bzcwNzQ3OHphaUJybkV1RFNCVTB4cVRmRXRpZGsyems0VTcz?= =?utf-8?B?eGxVMi9wS0lpc3NSNjJrL3lBdWx4OXZGMjlMa0lYeFZsKzJiZG9iaXZCb3VS?= =?utf-8?B?NU1pUWN4WWtpTXMxeXErWFd1K3ArT0NmWjF1Qnhhd0hOa0RSMWU5ZGRxYStS?= =?utf-8?B?Q0VVRjliZHcvWmNhN0ZuZE1KdFJoOC9aZXN0NVVhdm9sbG41ZklubEg5ZWcw?= =?utf-8?B?bWlwZ0dNbzhMdnpqRWZKZ1IycnBiTitwYmNVOURMRWYwbUJUVDI4eFp2ZEUr?= =?utf-8?B?andqQWhRb2RNbEdPcTZqN3laamkrcFl2NWFZdU5TdTgrZ0dMY3o4eG0yYjV1?= =?utf-8?B?emxWUGgvaG82MEVESWF3UmJMT0FDYmdVQjZDNFZoRFhPVE5qS3YvMUdTUjZO?= =?utf-8?B?dzJRRUtkdU5aL2tZT3VobitOK2RuS29heCtiWHhrbW9hRVlPald1Vlk2MHNL?= =?utf-8?B?eW9SKzA2eC9MM1NQaWF1WkdiQTVyTzFHT2NZWkJxQWhTSHRMUzh1aFkzZU9l?= =?utf-8?B?MUtsUDRoNW5Cak9FY1ozWTZlcDZsNHl6aHNnbjVSeHd5TDd5S0JGZFdZLzNa?= =?utf-8?B?MllNMExFS3FidHl5SXNrZ01Da2lsSW1WZ0lHdnE2WDArcG9qb2MvSXlIanVD?= =?utf-8?B?VUpsRXRRTUc4T2VwTHRLVlZjSlFaVVNVKzE0UmdHMVk0b3dIYVFYdFVLQ2xY?= =?utf-8?B?QUg0aUJuUy9QY3FmcVZEQmFFOVkyaHgrNExkYnU5enNSNWNicmZwY0o2TmRC?= =?utf-8?B?WmhNUWhlOFZzSkNKWGQ0YmphNitORnpsd29jQ1p6ZmhRMDVQaXE5NlR6VEFI?= =?utf-8?B?T0JKejZZajFWTUFIa0QwZmdpR2pic2V0Q1M5TEt6cDVXL2lSemhreHdQUVRT?= =?utf-8?B?bFNtYVV3ZzByeVhhNEkwUldSeC9CcFozTEVXK0JlUGF6Z3RDdWtzQzg3QUt1?= =?utf-8?B?NjBGdFErVjJJSE5JaktNZVVxeGE1U0RNU0xZbTdoT1VnbUxRY1lvWEhQdW9T?= =?utf-8?B?Zlp2QXVnTE42aGI3SmF4T1AxQU9HRUUzaklEeCtONVo4V3VmVVdOZCtQMkRW?= =?utf-8?B?R0l1ZjdTaHVMb2lraFNHN0pudnNRR0FQdTdCUmllZEs4UzdEYkVEa3h4RjFh?= =?utf-8?B?YUdGdVI2ZlJkbktBVkdWVXBzbVVPWElYWEtIMHFlN3B6ZEo5UVNET0ljK2pK?= =?utf-8?B?dTE0UHZqVWZSY2p4MXpRalhXMUNtUGlCakFNVnBSRUl3YkhoUTFXZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4675eb76-891d-4500-d3a9-08df0ab128b8 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 18:20:11.9479 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vE1jNjxv/fXobqn/iHEIl6NZmHttWLrTT/ZGcXIBdVzgxueuyxBA/tr4S90Md+NYMzGDRLZEbpkrnsqPBwIcyz+2fT6gYgCC9hI/h+4eWes= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7854 X-purgate-ID: tlsNG-33051d/1788546016-6F4C74E9-49B23C76/0/0 X-purgate-type: clean X-purgate-size: 2488 On 04/09/2026 1:13 pm, Bertrand Marquis wrote: > Hi Andrew, > >> On 4 Sep 2026, at 13:12, Andrew Cooper wrote: >> >> diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h >> index 4ed2a40ed0ac..2d0f2db0b256 100644 >> --- a/xen/arch/arm/include/asm/smccc.h >> +++ b/xen/arch/arm/include/asm/smccc.h >> @@ -181,21 +174,20 @@ struct arm_smccc_res { >> * makes it stick. >> */ >> #define arm_smccc_1_1_smc(...) \ > The comment would need fixing on top of this as current > one still describes the optional @res argument while now > we only take a0 to a7 as arguments and return the structure > instead. Are you happy with this delta? diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h index 2d0f2db0b256..c7763acd7f7d 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -159,15 +159,14 @@ struct arm_smccc_res {   * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call   *   * This is a variadic macro taking one to eight source arguments, and - * an optional return structure. + * returns four values.   *   * @a0-a7: arguments passed in registers 0 to 7   * @res: result values from registers 0 to 3   *   * This macro is used to make SMC calls following SMC Calling Convention v1.1.   * The content of the supplied param are copied to registers 0 to 7 prior - * to the SMC instruction. The return values are updated with the content - * from register 0 to 3 on return from the SMC instruction if not NULL. + * to the SMC instruction.   *   * We have an output list that is not necessarily used, and GCC feels   * entitled to optimise the whole sequence away. "volatile" is what The overall comment now reads: /*  * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call  *  * This is a variadic macro taking one to eight source arguments, and  * returns four values.  *  * @a0-a7: arguments passed in registers 0 to 7  * @res: result values from registers 0 to 3  *  * This macro is used to make SMC calls following SMC Calling Convention v1.1.  * The content of the supplied param are copied to registers 0 to 7 prior  * to the SMC instruction.  *  * We have an output list that is not necessarily used, and GCC feels  * entitled to optimise the whole sequence away. "volatile" is what  * makes it stick.  */ ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 04 18:32:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 18:32:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409016.1641236 (Exim 4.92) (envelope-from ) id 1x2YiH-0000eM-1d; Fri, 04 Sep 2026 18:32:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409016.1641236; Fri, 04 Sep 2026 18:32:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2YiG-0000eF-VI; Fri, 04 Sep 2026 18:32:32 +0000 Received: by outflank-mailman (input) for mailman id 1409016; Fri, 04 Sep 2026 18:32:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2YiF-0000e9-TI for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 18:32:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2YiD-001tn7-Da for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 20:32:29 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b0ea1-bab6-0a2a0a5309dd-0a2a4508c1a4-26 for ; Fri, 04 Sep 2026 20:32:29 +0200 Received: from [52.101.61.2] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b0eb9-f659-0a2a45080019-34653d02175b-4 for ; Fri, 04 Sep 2026 20:32:29 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5727.namprd03.prod.outlook.com (2603:10b6:a03:2af::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 18:32:24 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Fri, 4 Sep 2026 18:32:24 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vkfa1pwWkdvhdI8EBfyLmH3TNV56Ji6/KrYtKOQ7/xl2Qw431WazTwIS+UbEzgHrMovskJC2yLI9eadVENANh4eGpfUVW294p8GgiRXkK9UQMGfdIFt8H9q1DFLEDx00YiF7wB8I/QxwugZDd+Fz7h1tFe1O1uwlb34Apos2c/pxLrN5/dEdYiaKKXWCK6ELPSocOoL9UrWCGdr418w0WuuxhbNE7mM8eHxbhHwJD5q+QYtvZzLh8LfgUlWgxmtksKh+VFF5+TgfGPSg0coQZ7IHUDkwK0UVrHid8uejtKvct7QoDu+VWfOcc2mlf24eefzxvNVE+A8HtTpYYb9JLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jAdqvY7EGKjA22s1xDamwL+EgoiwzuubLrqjIkoE3lg=; b=mXgNkQ4zdM3vpD5KB8ZNO0WvCIRwNmnG01fQnAmtGVC/xoHuhVDix9dHLJDYoVjWL1KCDDPCVz9lcQAaW598N08S6sgoLA9g28UwjLd2aeZLU98bhWLOdLFBZY8KXeGyJjjHwGNEDo8DQ0gdQbt0Yu+WhcftvUsMoZQ+mko3pMd1Nl1PYLtH+zGXXWiv3e90AkYOws8ifLybJBShfXzBCZUn+S7ou5p7WgKpabpVDVY9YFXCghZMWhDOKHISOgzJ0c52bV0VB0xSLizIfSS6IkA/9hsRyCMCtf1RH0sSFQ5bxmGtK5bUL89aDNOiOAjKOP7WYCXPnHSoCZsGggapsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jAdqvY7EGKjA22s1xDamwL+EgoiwzuubLrqjIkoE3lg=; b=VZlbLTCkS0cWCa8pXNxVMew1QynYhkX8SnsXlIGawV6MyvmjAXeyCzJIZqi5admE1OReElltfxNsHBCXjqUO5gOcN4+uI2nqURl5zlihLnbpTxuzDn1KCKhb+iS0DyEZEUOcyIVwk40sf681/6TqWmqVNOLEQ5FjIJN7GQjWBU0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <8cb14cba-d905-4e5c-89dd-7196b068ca87@citrix.com> Date: Fri, 4 Sep 2026 19:32:20 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?B?SsO8cmdlbiBHcm8=?= =?UTF-8?B?w58=?= , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH 1/5] xen/rcu: fix types To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20260904171121.65300-1-roger@xenproject.org> <20260904171121.65300-2-roger@xenproject.org> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260904171121.65300-2-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0503.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::22) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5727:EE_ X-MS-Office365-Filtering-Correlation-Id: fe8f4557-f755-4587-1cac-08df0ab2dd1a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: +XCVUx0Kuf62xu4zq0Iwhl3w/bk5wESz+daIaRRBaNehNwwLd2jGu6TBDmtBSFAvXuSlcvLdt9D11Yv/6FNj3DvB9KhOoLVvTqdj4yrZSn/fSVGYQo0s1cManJtb83IVjfpaxNxa7ROs402dtSy4dG+UlJ1AsXTEatRJLJGUAyBzAH2S0EH8ckHR6jruAumOkjqhn4+BixrP4fospSbzXuwvFzz88+6oObmhUvCsBCXsKlDWPdbyPEEjHYnMSr24OZz8ExRoLbZ6kH+n2eW7KyeRZdrQ9zNne5iR3EhU4zLf/SBnh6R9BvR+GNCN8YO1Bk7aGyU94YtSrNCJKEv7IUEWV4HgDMngcQ349A6YFDQZ5zjtixn6V2OWMKzX6Tqi5O+ddZIJ5fTEgqEBFxyrnGS83dmC68lFx9mpBPiiFO/KmAokuda1+hmsJDcbhlaBx7IzY6JVXpiTDWA5d9q+5y12yCA1d8K87NcE5oIcAxUB/QUOQ/u6hn6okeZgopJPjDBNEV0rhJ0OVF3vTM3awQqugg5uQiqnjAFUhuC6qEBsPWsKpk2iYxXWZs3bPrTL9vLPz9BgmkFWizdGvRglokca2N5qMHTysz9WuUl6NQZf4dyEbpr6Z7del+AnbsfPK8MtNPdyWcZoVkjlmwDQ6yoOkbKr+lab0sJa4FWxK/Q= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cGFKT1NRTXJYQjQ3dFBQNUdlak9hYWIvdFVyQWgyQVExQ0hlRlJyTXE2eEJO?= =?utf-8?B?emNJVWd1eFNlMVpObGNuT1JQRUxXajQwT1p4eEFsRUh2ckszVUpJUmZ1Y2d2?= =?utf-8?B?dGg0K014ZW5URVA0YVcwQ1ROV21uR1pMeEtIOW15Zi9GbHd3bVVlaEJZcnRn?= =?utf-8?B?UHZsRmdxV25tSExvV1hSU0hCdGxvY002WmtXbXFOM1l1eXh0YjJpSjhSMWxm?= =?utf-8?B?ZC9lOXFqZU1qS012bmI1L0RtUDRXWEdsUVRWTWJ5Ky90akV1eDA4WUgvV1Fv?= =?utf-8?B?dUJKcjVZMUNoRUozRXZka0dUa2xxczE5VGFia3daSm1BcEMvUkt5OXEzVWZj?= =?utf-8?B?djNycFZDeWZ1bzAwdjBINmR1eGt6VytveDVWUDIyN01FaXBLS1pTMmN0bi9J?= =?utf-8?B?WndiWldyTzBDRHFoVXN3aHk3SkNyNSt4cFA1L0o3VktvZHdncWp0M25DMUNF?= =?utf-8?B?MWJDQy9BU0tBai9wdFhFSjVBTis2SmdFYkgvVnBKQm5WcElJWElFcXZXVEVo?= =?utf-8?B?aVlxcDRWeWNXWDBQUkdXWVorTGk2SHJkUDMvbUs4a3lYbmZWYUFXbm15cWIw?= =?utf-8?B?UW1La1JXaFhoRmxqUzBNYkJvajR1eWR3YjFHRzY5YVlOdy9CZ2I4ZVd2MFVu?= =?utf-8?B?NHllcC9zUkJPbkJLdzBZNFpjODdLaTlMcW5YaUJiUWJSa1hPZU90Nm1GSkRn?= =?utf-8?B?Vmp2RFAza3o4djM0bkFRRUdjU0kxbzlURk5sbU5XOGIxMm1SRUhNS0NhSkZM?= =?utf-8?B?QThza05Hc2JFY0EwZlZIMzZ1NUxyYUtsNk9zU1E1YmNsZlF3VzFzaWRNRnFR?= =?utf-8?B?c0NNbWQxM3VDTVYxRVF0UllxbHVRWkVYeDhhYnpjQnk3VGg3NUFBNzVZang1?= =?utf-8?B?MkppUVZPVlN4c1c0OEl5TCttdjVRSXF6SHZQOFFFTkNiV0RDWjBQYmcvSnJX?= =?utf-8?B?ZWZnUS9TTENGM3hCVkdoaTJIMjlZbkFuVDN4NUxvd2xKMFVTZ2pGdE01MlQy?= =?utf-8?B?NFhGNGRMVmlKZEFqVWZsbFNYa1dBckhHZG50UnJhSWJvdVkzUmJrSDV1N29o?= =?utf-8?B?TlY3RERIaVhDenU4RUJLdlkycnQ3WTd5Vm5xb0lDTG5MTWRIZ2ZaRTBFeEhF?= =?utf-8?B?QWFYQWhhclR4dXZVczdrN0FNM3JJNlRtUzZhVDBMQWpxRDluaTg0L3FTejAz?= =?utf-8?B?RVgwS2VBS0tGL242Y0pnZ0d3RHNrUHhmN2taUXZCNFQ5UGUwNVNuY29QQ1h3?= =?utf-8?B?S08yVCt0Nm1tYlA5NE1zTHRkKzVDbUdpUzMxSVVGb0RlaXhCWmI2dC94T05G?= =?utf-8?B?QllLMHpwci9BdHFVNU5vR1Q0a3EyZEFQK2RTSkFncmFLaXg3Rk0vVjNOTG5P?= =?utf-8?B?bnVGTEIrVFlLOE1QNXBMSjkwTFFSaUlCSVVnTCtmdlBEc3VoMmFEcWhhUlBE?= =?utf-8?B?cWpjUmgxaldIazlxTkI1QmFKeC9KQUc1ZVFEd1ZzOTRxUDF0dnVhZDg0VFJx?= =?utf-8?B?VHY1VXB0MW5Dd3hnNzEyK282cjJxbHczQ2JDUENqdnFYd0hsTlNCZExKN0tH?= =?utf-8?B?eFE2NjhWay9UZk1Rb3ZTeDduR0w0Tlc5YUZVRHA4eGdRZWJGTGlJRHh4L1E5?= =?utf-8?B?R0FsUHlDQjNBc2JvY1pmcklTSXhlb0d5VGIvZVhYa0pYOGhTaUJ1NkxKSjBh?= =?utf-8?B?eHFsLzEwS2JvbHpGUERwTC9kaFVUNzJGbDBDajlQVDNIS1k1MUFISmFyVkk1?= =?utf-8?B?MldFN0l2Mk10dGkwVjY5emVkY2QwdHhSdlM3T3Q3Ynl0SHNNYllYeVhQQjNV?= =?utf-8?B?cHpwcDd6cXJUUDQ2ZGJMZ2NxellDcjF4b0hDcS9HRGhoK2o4OVg0TnFyQ2NF?= =?utf-8?B?c1FJU2tqZVk0aHRuS3ZKK3FlQi9jUzlsYkRMTWJlQmlFZnc3V0FwN0NWVkVF?= =?utf-8?B?MkNlUkhLSzNGZVRNQVMxZG9BMUdKTTNQUWNGdUNhbjB2RlVQVkt1UFdZUXdS?= =?utf-8?B?VTJ6azZYaXphaXBmS0dWdkFjUmpjeEdZdEFNd21RUzZJSmZHRmRlSERWVDZN?= =?utf-8?B?QzMwZHNlRys1ZllQYi9BcDE5enRIak9vVmJ0YWtZMGlRb1IzWUloc3VaUGZ3?= =?utf-8?B?SC9KSmt5K01LVUtvaGd6aU9ENWtQWFNhSzI3T3prUmpLbTg1S0Y4R1Q0NFB5?= =?utf-8?B?aDRXWXhJbExabW16dXAwYlVxNStuSUhSNXZENDV0MlBnNTFNZk16YnVoSVVL?= =?utf-8?B?MkZyTzFzeCtNRU40M2xyTlZrUDgweTlNM0pSNVZFdXBZQWdBY3kvU25ORG9v?= =?utf-8?B?MHZ4TElYbU45T08wLzRxYXdQWktDUkpWOFM2blpzU2paazFBT3cwdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe8f4557-f755-4587-1cac-08df0ab2dd1a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 18:32:24.1386 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EEDKPPGCcv83IrFra7lBuLKVnuZmeGANHj9ZBkSiV/q9Y/biQ7z0ZYl35qv04nP6kVzLDxxPT5jJUrbXIEUbknzSieAMGxkwVWBLV7EDZOo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5727 X-purgate-ID: tlsNG-c1860d/1788546749-D795A87B-FCF93308/0/0 X-purgate-type: clean X-purgate-size: 313 On 04/09/2026 6:11 pm, Roger Pau Monne wrote: > Adjust some types: int -> bool, int -> unsigned int. Also fix a couple of > typos plus trailing white space. > > No functional change intended. > > Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Sep 04 18:33:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 18:33:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409025.1641245 (Exim 4.92) (envelope-from ) id 1x2Yj0-00018k-CK; Fri, 04 Sep 2026 18:33:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409025.1641245; Fri, 04 Sep 2026 18:33:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Yj0-00018d-9E; Fri, 04 Sep 2026 18:33:18 +0000 Received: by outflank-mailman (input) for mailman id 1409025; Fri, 04 Sep 2026 18:33:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2Yiz-00018T-3U for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 18:33:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2Yiy-00FKkv-GB for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 20:33:16 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b0eea-2eae-0a2a0a5409dd-0a2a450ceb6e-6 for ; Fri, 04 Sep 2026 20:33:16 +0200 Received: from [52.101.53.45] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b0eeb-f479-0a2a450c0019-3465352d1757-3 for ; Fri, 04 Sep 2026 20:33:16 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5727.namprd03.prod.outlook.com (2603:10b6:a03:2af::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 18:33:12 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0360.008; Fri, 4 Sep 2026 18:33:12 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UZxujtk+rC0E2sofKI/PTHKInvTe5kA+vdtzcpX9NB/msb93rwuDZirjSgJ4uXPzeUEvWRU6nboRKAmD9ty+49oIjc+JidnJB4x0Ag9Auu+6tH479mgafuCWsHP6KcfJ40HJSWNyHCC/fIxOl28qrT2Qq83Nz9wjDo3s1YXu7GHCqnQbj2SSxynt+qKL4OSzIpXg0Kx4tNMHCNC/hBI84j7MzefIrSr7/7BmxSY81x0O2J71rAVwiUic+vyWrpHZaRLpZJOegxL4Bu3PTghCAy44E7iY3YAE7K4z9SWHEao0UFYFrIPhpP7TuS7vRvfwyBC4dpKc4smhmwxVpLkA4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HmDU/reGsjLRrkDCK6HZNwyCHUm2mDqS29Pz+lfbx6g=; b=SvtjJBb3ZpL7vEx341s+cvhr8t/OMJFQ1mPpyZ4eSyyFIFY8p1DUk2Tq3qFLb+HT7YokITy5VzQORWDb+joXXb2nOiUg9uWjxGs5/NJOGR16w1s+4698UuSBHwVuntxYCG/cYG6jGvTTIWhkMHHsfqUwqDbT9S2JUUdtdqgQVMv0Mosn7SsXVCBl17eQK74aYXahTqun6RH8x/hmTRzV56wMKfVznKsWxGJoySf/Sb7KBCqPryu+9+6QQzFnCqLOh8nHxC1X/iCdTmOpDnMfmMsfbroRjLXmJbtCAvnUNuiPd02kpncF7waWdf94xBCd5Jl9aZeuEhK5048UFOIvbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HmDU/reGsjLRrkDCK6HZNwyCHUm2mDqS29Pz+lfbx6g=; b=XLtAIJar9kQVZsNwpIwcqOy6oaMaqYIJKCV4p6JeP7qEZe+arQBayv/jo9ijh/DM2v3KRFKWZldLDN7VpmHtuN+g5AqnlDA5R4QRW5Yddc2t9/tQs11cbx7a9ZDu/XBsG1xVeZf8eWvljElWGos3CoMVOrldYxwcJNII2luIZB4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 4 Sep 2026 19:33:08 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?B?SsO8cmdlbiBHcm8=?= =?UTF-8?B?w58=?= , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH 2/5] xen/rcu: sort includes To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20260904171121.65300-1-roger@xenproject.org> <20260904171121.65300-3-roger@xenproject.org> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260904171121.65300-3-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0493.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5727:EE_ X-MS-Office365-Filtering-Correlation-Id: a6ccb57f-1830-47f1-8ba4-08df0ab2f9fb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|56012099006|10067099003|4143699003|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 7uO2In/8fWtrZDGR4jbGAi06eGnBDZV5VJfac7rResVuumw2EBuLOEH0OOGPnHg9Wnprl6iT20jgMHAItEC/U7iGJ/r9eFxfWpXPLwx5yS6Bt1oW0ZTdZkTSa74uerDI+Xo+0e8XhdzgbgXLRWiP3Um90JKlmokqhAMElVsTEXjehSl1DTZ/ZxeByAYNgK2ny/5wSwh6OGoxm65kfgS8J+/TIsf4mLmV1Jr6S7PtNB92N1XvScWIc95SId1trgHqt/AkrPvquV/ybxUOSLYrJCBZZhXhEfncn2ELTTzEaXKg7bDWmRws2G/4SgXOqixrzFsMUzHsonOiFmCKj459/MbtLQeZV2xa4E8F1lnEMvnqh06fVSdEasWriifF2Fu6ksEXkUn7ECWO6N4JuUK+TLIHeE7uNnz+D/X6Yx/WqqsWP2dClIYog1flQuFSkhZugvvSue6u/5D+yv4ugeMorXVcsWSA1x62Q/eGLLDXi6kLASqX2RQulVXi56J/fKyCCN9IYI9W/HBPVz5figRhxDZLW/evIKPEjuuHSXUVLlBsh/QaXQhI8Yv+8Cu7Mk7sLFBzln9vxW9BCATrEBTkkAEs8gv/Tq/hjiB3KEYS9b+6MDtvgAqLIYZjUP95FDhh X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(56012099006)(10067099003)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?REV2dU94aEg4S0VEMGZiK2dTTkJ6UkFVUDR6Z0NETDV3TEtpUUxLT2d6cXFP?= =?utf-8?B?a0plSjg5dnNpVUxidTFmT2ZJblZZQTNIcnVkaTM0ZEsrQzFTQ05QUlZiT21v?= =?utf-8?B?WFdzZE1nTVFtQ0Rua2gwc3djVGgvWGlWT3RQRng5T2MxbUd2NnBxUmQ0S2g0?= =?utf-8?B?bnI3NFl2Wmw2emdvaHJzUndaMm8wYVlIZTFGVzdFOHJIMmJLWllxZzl6dk5r?= =?utf-8?B?K1hEWGErNjYyUTdnZHZ5ZWVTNjZENVlLQnA3dzRwdUlRSThhMkUyaklhS2V0?= =?utf-8?B?cGw2NTBjT201czlTZXh6emdiWmlTWlEyTVhnNWdYQ01GeWc1ajRVZ2loSFlP?= =?utf-8?B?aWRTaXI2WWpuNkhXUTUzS01zZ1pETmhxTDM4c29rSVJHMldjWU91Sk9BQTc1?= =?utf-8?B?bmd6S05ETDhraEJWbXM1cGxGZG5rVTdESC9TTHgrMHRUL3I4eFZVR2ZPOGtp?= =?utf-8?B?Z0FCMDlBV0wwZ0ZrTWtqNGlVT1NVMTE3TEhueWdQYjVpYVZRdzFiT3F3allp?= =?utf-8?B?NU5vaHQ5YlJkSlNNRERaME1KL2FhUGpBbEF1RFRTdzFBTkpwZWRzRDJDNU1j?= =?utf-8?B?UU10TUVKSTBHKzlwWE5YTjRmY2pGNWRwWHpkYTQyeDBoVXF6aDBuazlTWkZW?= =?utf-8?B?eUVXOXZkaGhqYXhhR3pJaVczUjgvMjFPTGMrV2JNemRVU1VFTEtac0ZROGJQ?= =?utf-8?B?dVBpM1R3dnVFc1FBMzhkNzBtRWpPVWlaTE41Q2VBcnZNOWczTlpiSDQvSG1y?= =?utf-8?B?Wm05WDd1NFZyQURCV0xZUkVGdzdZME5hRnNaYnd1UkRpSVN6Y3pmR0Q5ZG84?= =?utf-8?B?aUNwZzN6TytCNFFmY2lTRlVITWk0c0RSd25TV3VhSkFCT0dRUktuUExPN1lt?= =?utf-8?B?RG1rY3NjSmdqQm9zRU11WU5XaVd3bDNDMW5pdWZ0OUkzVWg1TXA3SFlCRFJM?= =?utf-8?B?Q2k4ZUh3czJpUi9vb1BUaGQvWkxib2NuVzVZUXorZ1ZORTc5R1loOEh3U0hD?= =?utf-8?B?VC9PZktyeFdSc0NacUlxeEVvdTFlWTdVS2tHVEZscGtWV2dETDhhd1pXZnJ5?= =?utf-8?B?QUZzOHhTVmdUaHp5Q2lrVkw1S3ZvV0tUYTJ3Wk9sWXg0T3NRZmI0WjRjL1Vq?= =?utf-8?B?Znk2OFJwWDI5SjNJbzkreDNPclJyV1FKOTZBMXJuaFdWVW9oVHdueno5dEpY?= =?utf-8?B?eW43KzNtNCtVeUJLSlJwdzFiWmZ1a29XOVJOVk1uem1Kd2x0QjM4TmY0by9J?= =?utf-8?B?d3RCVkhIdm0zZU05aXBDTWZJUUpBcktLazdlYTJwM2U1MmVIYk5UeDRoWHBj?= =?utf-8?B?Rmh3enk0ZHVMUkZFMkpPSXlFbnI4K2JxUjgyTktuak52Z01WcnhPdklNUlVz?= =?utf-8?B?TUxJV3pLZlJyaWZwUzVpZVo1TzR4cE1hT2JyQUR6YUxXZ2prbjNtZ0VSYWp3?= =?utf-8?B?a0VsazZjcno1Y1l4emtUK1pVM0NqdW9FWUphT25LT2lTYytVd2NOcWdXQTA2?= =?utf-8?B?MWtSTXNYUFVVOUNoVEhxK3ZUSmZuQyswYjZ3OG9vTkJjZGlTVi9peUd6WUhY?= =?utf-8?B?NU5PQkVqNjhUK1dCTWpjb00xT2d3NXpuWmM0d2ZzWnY0R2hra2pvdm5Wb3Zj?= =?utf-8?B?bWJJNUkzK1F5NXlSVWhKZGR2NHozOTlIR0hITlRHRHFoNHcwVVAxaUV5SDJC?= =?utf-8?B?V3VJUzdXTVprR0NGc0ZBdUMwcEJ5STRvbDRZelhNZnhlMUk0bEpxRkc1eEdn?= =?utf-8?B?b051dzZPVHRyM1Q1NlA2bDM5YjY5KzVHU3B0RCtVVmNoRlRxMVljamVkb1BY?= =?utf-8?B?dzNjWFc0T2FTR1FQL3IvWUlNZ0Z6YTZsZFdlaFJSSVBNeG9qV1VOYnA0NW4y?= =?utf-8?B?eUFvdnVIR2Q1L2tvTWMvd3hsNVVZWm8vWmNYL09sTUdPUmpxWXZZVFRDMjNo?= =?utf-8?B?cFE4aDEvRFJ3R05hWEIyeWcyLzVybnJjb2tyV0IxQXYwR2hIM1JGUC9jSFBn?= =?utf-8?B?SlQ2U0w1THhlWE5yamdtUWYrMEJxbEYralprV1JvTmltYm9MNEZqeTEzTXJt?= =?utf-8?B?UUROcXhHNW40cVE3N3hwMGVrZS9CL2pGSE5tVi96dldNaGl3eUoxOTZnK0d2?= =?utf-8?B?NGRjMExpRzF3RktTYVBUNmRUSWJUM09sV2luYTVWb1hLaEtwRDBhV0lpbHF4?= =?utf-8?B?WjlHQnFHdnZlOUFJdFVDUXF3Z1FRaHcvL1dZQk9lYmxmeHVmVmhReVkyU0ZB?= =?utf-8?B?alFQcXFLL09OWk04VmpoWEJrcWRuSXNlTXlCc2Jsdkt1N050WXpFL1JNY0lH?= =?utf-8?B?YmhyS09mWlVOOEFBVzVwbWYxRVZKMFRxWVZnaS92SmVMN0thdTZDdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6ccb57f-1830-47f1-8ba4-08df0ab2f9fb X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 18:33:12.5744 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Kw1+ddE9hTLjfCYqUEANQ1UKtFc+gATh1vZTgfSP5WjVx6LAFq1syEUJtEvqtqENSF2Hsqx0ueJ1QX5/r6V4j7gN62WHw2J3jeeihuyjnaU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5727 X-purgate-ID: tlsNG-d25034/1788546796-018C5A5B-23280E41/0/0 X-purgate-type: clean X-purgate-size: 1156 On 04/09/2026 6:11 pm, Roger Pau Monne wrote: > diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c > index 3b96f829c87c..c1b6b2ae768b 100644 > --- a/xen/common/rcupdate.c > +++ b/xen/common/rcupdate.c > @@ -31,21 +31,22 @@ > * For detailed explanation of Read-Copy Update mechanism see - > * http://lse.sourceforge.net/locking/rcupdate.html > */ > -#include > -#include > +#include > +#include > #include > +#include > #include > -#include > -#include > -#include > +#include > #include > #include > -#include > -#include > -#include > +#include > +#include > #include > -#include > +#include > #include > +#include I'd just drop types.h.  It's really not needed by this point in the list. Acked-by: Andrew Cooper ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 04 19:16:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 19:16:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409061.1641257 (Exim 4.92) (envelope-from ) id 1x2ZOX-0007Ms-Ex; Fri, 04 Sep 2026 19:16:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409061.1641257; Fri, 04 Sep 2026 19:16:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2ZOX-0007Ml-C7; Fri, 04 Sep 2026 19:16:13 +0000 Received: by outflank-mailman (input) for mailman id 1409061; Fri, 04 Sep 2026 19:16:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2ZOW-0007Me-7O for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 19:16:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2ZOU-005oF4-Qb for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 21:16:10 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b18bf-bab6-0a2a0a5309dd-0a2a4504c00c-38 for ; Fri, 04 Sep 2026 21:16:10 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b18fa-b57f-0a2a45040019-b9ff1c12b209-3 for ; Fri, 04 Sep 2026 21:16:10 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06dd97b80000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 19:16:04 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id C0BD581F87; Fri, 4 Sep 2026 21:16:03 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=5WJN/PtIxGMmN69Dw8Jmca+4P3NFGLx9nwRCcVfgtPg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=bsDjWv8GFM46/MCtlBlF0pHrBuUk1UqNehLv8GdWfk49RhcUUd906j16E0QekzdLqupBXEmvN bbeUhd254twHxmYGYMc3FlkKIrouKESAX2r2CwSjktVSH+Qg1/CrPAhTdBo7U55jU6FY2uBZowc a5r4SNmM8FWuUvOsWXz1uYrfju5UhvS3CudsgbSf0N6vcO60T7mnOlT6EL7ZeapDT9KQoQWtBfh 6KiuOypkX48SlmGBQlOnypRROm7+PVTewxsmGsrNNmwAowTwvluqtEkswiKLQPjJkpbhVbV10hY sTPVbETiy87Qq7yPDv74fMhRzPWjMIooC/bhVzAR0h/g== X-Zone-Loop: 9cbdbaadd00b8baf91ab25ea69e57b2702abe656f479 x-campaign-type: default x-transaction-id: 6fc5a7ef-ac18-470a-ba8d-3ca3cabace9c x-swg-uid: 01-d8bbcaa1-0e32-4c9e-bc62-c482862d8f09 X-Mailer: Sweego Message-ID: <1788549364.8631fc262581453bbf619ec5b2062170.1a06dd97b80000c4f3@vates.tech> x-swg-bid: 1788549364.8631fc262581453bbf619ec5b2062170.1a06dd97b80000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 4 Sep 2026 21:16:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/nSVM: Check injected event consistency To: Abdelkareem Abdelsaamad , xen-devel@lists.xenproject.org Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, jbeulich@suse.com References: <1787565706.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3@vates.tech> <20260904151014.3113677-1-abdelkareem.abdelsaamad@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260904151014.3113677-1-abdelkareem.abdelsaamad@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------p8bZ6tlnaIzb8JdfFKFuI3Zr" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788549363953 X-purgate-ID: tlsNG-ebf023/1788549370-C2CCFB50-C1718A3A/0/0 X-purgate-type: clean X-purgate-size: 6745 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------p8bZ6tlnaIzb8JdfFKFuI3Zr Content-Type: multipart/mixed; boundary="------------Y0ECcbAZ9iQ8wuLK9fkHk0h5"; protected-headers="v1"; hp="clear" Message-ID: <401e44b6-0284-487d-8d90-3918b85e5e86@vates.tech> Date: Fri, 4 Sep 2026 21:16:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/nSVM: Check injected event consistency To: Abdelkareem Abdelsaamad , xen-devel@lists.xenproject.org Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, jbeulich@suse.com References: <1787565706.8631fc262581453bbf619ec5b2062170.1a033380dce000c4f3@vates.tech> <20260904151014.3113677-1-abdelkareem.abdelsaamad@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260904151014.3113677-1-abdelkareem.abdelsaamad@citrix.com> --------------Y0ECcbAZ9iQ8wuLK9fkHk0h5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDQvMDkvMjAyNiDDoCAxNzoxNywgQWJkZWxrYXJlZW0gQWJkZWxzYWFtYWQgYSDDqWNy aXTCoDoNCj4gT24gMjQuMDguMjAyNiAxMjoxMiwgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiBP biAwNi4wOC4yMDI2IDE5OjI2LCBBYmRlbGthcmVlbSBBYmRlbHNhYW1hZCB3cm90ZToNCj4+ PiBPbiB0aGUgQU1EIHBsYXRmb3JtcywgYWxsb3dpbmcgYSBWTVJVTiBpbnN0cnVjdGlvbiB3 aXRoIGEgbWFsZm9ybWVkIFZNQ0IgaGFzDQo+Pj4gZGVidWdnaW5nIGNvbXBsaWNhdGlvbnMs IHNlY3VyaXR5IGFuZCBwZXJmb3JtYW5jZSBpbXBsaWNhdGlvbnMuIFRoZSBBUE0NCj4+PiB2 b2x1bWUgIzIgMTUuMjAgKDQwMzMyLVJldi4gNC4xMC1KdWx5IDIwMjYpIHN0YXRlcyB0aGUg dHdvIHBvc3NpYmlsaXRpZXMgdGhhdA0KPj4+IHJlc3VsdCBpbiBhIFZNUlVOIGV4aXQgd2l0 aCBWTUVYSVRfSU5WQUxJRCBkdWUgdG8gdGhlIGluamVjdGVkIGV2ZW50LiBUaGVzZSBhcmUN Cj4+PiDigKIgUmVzZXJ2ZWQgdmFsdWVzIG9mIFRZUEUgaGF2ZSBiZWVuIHNwZWNpZmllZC4N Cj4+PiDigKIgVFlQRSA9IDMgKGV4Y2VwdGlvbikgaGFzIGJlZW4gc3BlY2lmaWVkIHdpdGgg YSB2ZWN0b3IgdGhhdCBkb2VzIG5vdA0KPj4+ICAgICBjb3JyZXNwb25kIHRvIGFuIGV4Y2Vw dGlvbiAodGhpcyBpbmNsdWRlcyB2ZWN0b3IgMiwgd2hpY2ggaXMgYW4gTk1JLCBub3QNCj4+ PiAgICAgYW4gZXhjZXB0aW9uKS4NCj4+Pg0KDQooLi4uKQ0KDQo+Pg0KPj4+IGh0dHBzOi8v Z2l0bGFiLmNvbS94ZW4tcHJvamVjdC9wZW9wbGUvYWFiZGVsc2EveGVuLy0vcGlwZWxpbmVz LzI3MzQyODM3ODgNCj4+PiAtLS0NCj4+PiAgICB4ZW4vYXJjaC94ODYvaHZtL3N2bS92bWNi LmMgfCA1MSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+Pj4gICAg MSBmaWxlIGNoYW5nZWQsIDUxIGluc2VydGlvbnMoKykNCj4+Pg0KPj4NCj4+IEkgd291bGQg YWRkIHRoaXMgbmV3bHkgaW50cm9kdWNlZCBmdW5jdGlvbiBpbiBzdm1fdm1leGl0X2hhbmRs ZXIoKSwgd2hlbg0KPj4gZW5jb3VudGVyaW5nIFZNRVhJVF9JTlZBTElEIHRvIGF0dGVtcHQg Z2l2aW5nIG1vcmUgaW5mb3JtYXRpb24gb2YgdGhlDQo+PiBwcm9ibGVtIChub2JvZHkgbGlr ZXMgdG8gZGVidWcgVk1FWElUX0lOVkFMSUQpLg0KPiBCeSB0aGlzLCBkbyB5b3UgbWVhbiBj YWxsaW5nIHRoZSBzdm1fdm1jYl9pc3ZhbGlkIGZyb20gc3ZtX3ZtZXhpdF9oYW5kbGVyIG9y DQo+IGNhbGxpbmcgb25seSBpc192YWxpZF9zdm1fdm1jYl9pbmplY3RlZF9leGNlcHRpb25f dmVjdG9yPyBJIHNlZSB0aGF0DQo+IFZNRVhJVF9JTlZBTElEIGFscmVhZHkgZHVtcHMgdGhl IFZNQ0IuDQo+Pg0KDQpJdCdzIGFib3V0IGFkZGluZyB0aGlzIHRvIHN2bV92bWV4aXRfaGFu ZGxlcigpIGluIHRoZSBpZiAoZXhpdF9yZWFzb24gPT0gDQpWTUVYSVRfSU5WQUxJRCkuIEhh dmluZyB0aGUgVk1DQiBkdW1wZWQgaXMgdXNlZnVsLCBidXQgYWxzbyBoYXZpbmcgDQpzb21l dGhpbmcgdGVsbGluZyB1cyBpZiBpdCBkZXRlY3RlZCBzb21ldGhpbmcgd3JvbmcgKGFuZCB3 aGF0KSB3b3VsZCANCmhlbHAgYXMgd2VsbC4NCg0KVGVkZHkNCg== --------------Y0ECcbAZ9iQ8wuLK9fkHk0h5-- --------------p8bZ6tlnaIzb8JdfFKFuI3Zr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqbGPMFAwAAAAAACgkQZg+p0QLLz9Ae Vgv/V86nl9DFiDr8uKysRJ3a9PRz5NBaGFPcOUzUXBK3M+3Kyxp8X7qtQzhxOtIWWYYhbMjbVmzZ zOBjl+Bq/qQn2sd9FNsZZPA8qRi9B+/xMrZ6x/TmXGzIGoADypbGFJNy4JLg4DGY7h/GdItMJgcf h/uh/TXEyMnfL5GmII6M9IrAzNYGV307PI0xP49ysOb52DX/2pMKoJrhOAd9pYHQTvK7nA3UpNK5 1+9+QEmQULbzPQIC+HkPdYumrWTVrWHJjvKNa3a57lAT8Y82PamkW6eKddL5fqmyh7eSwkqMdloV BlpjncraM0KwAaVnA9h52fXMK/JqUcuZ+ywbMm9j7txnPbMGIZIc4kcei50pZ0l/M5NPOoiixQ+H eGgTYSk5q3dxiYzRTACXXf58WMYKkR/WSPNk37ZFZ2J2/FlOPacXBgPzzDdUXvRhwmVQoyuywtrX ae+z1+csQSUw+HGj7SzxWU31N8DeFC0buzdzBjeRmpAWtr+KOVlBpQnUzx91 =pmZm -----END PGP SIGNATURE----- --------------p8bZ6tlnaIzb8JdfFKFuI3Zr-- From xen-devel-bounces@lists.xenproject.org Fri Sep 04 19:21:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 19:21:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409071.1641266 (Exim 4.92) (envelope-from ) id 1x2ZTe-0000d7-00; Fri, 04 Sep 2026 19:21:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409071.1641266; Fri, 04 Sep 2026 19:21:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2ZTd-0000d0-Tg; Fri, 04 Sep 2026 19:21:29 +0000 Received: by outflank-mailman (input) for mailman id 1409071; Fri, 04 Sep 2026 19:21:28 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2ZTc-0000cu-Io for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 19:21:28 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x2ZTb-005NUe-28; Fri, 04 Sep 2026 19:21:27 +0000 Received: from 2a01cb08929da000b174d1b7ad985933.ipv6.abo.wanadoo.fr ([2a01:cb08:929d:a000:b174:d1b7:ad98:5933]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1x2ZTa-00Co0D-0n; Fri, 04 Sep 2026 19:21:26 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=Zwsb2vulpDjYukfWgtMuZHAe4zYpD2FqWIcPvD8JMUE=; b=ehoVHju0pfdt5X7ZapC+4FXxnY KjkMbk38QsZq7dmfzASioMaP7vcbDg6/QfnttQ77BIDayns+BusgRJ0nOcSy76J4P80TAswiJh+cz jMQsfmNcqM31EEvSXnXkXP9B0adMb476NKWb8c437H4kNWgTkI+Bwf7P3N72bCLdDoCs=; Message-ID: <7d6ffbc7-83e7-4254-9cc2-f2a7113088ab@xen.org> Date: Fri, 4 Sep 2026 21:21:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 for 4.23] Add GIC SGI boot/self tests in Xen To: Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Roger Pau Monne , Doug Goldstein References: <20260529170956.49797-1-ayan.kumar.halder@amd.com> <20260828102933.2853627-1-ayan.kumar.halder@amd.com> Content-Language: en-GB From: Julien Grall In-Reply-To: <20260828102933.2853627-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ayan, It is usually preferred to send a new version in its own thread rather than in-reply-to an existing version. On 28/08/2026 12:29, Ayan Kumar Halder wrote: > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile > index b7afd3e58c..71f177824b 100644 > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -24,6 +24,7 @@ obj-y += domctl.o > obj-$(CONFIG_EARLY_PRINTK) += early_printk.o > obj-y += efi/ > obj-y += gic.o > +obj-$(CONFIG_BOOT_SELFTEST) += gic-test.o > obj-$(CONFIG_GICV2) += gic-v2.o > obj-$(CONFIG_GICV3) += gic-v3.o > obj-$(CONFIG_HAS_ITS) += gic-v3-its.o > diff --git a/xen/arch/arm/gic-test.c b/xen/arch/arm/gic-test.c > new file mode 100644 > index 0000000000..9ddd47cad2 > --- /dev/null > +++ b/xen/arch/arm/gic-test.c > @@ -0,0 +1,102 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ The preferred license for Xen is GPLv2-only (see COPYING). Can you confirm the use of GPL2+ is intended? > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +static bool __initdata opt_gic_test; > +boolean_param("gic-test", opt_gic_test); > + > +static DEFINE_PER_CPU(unsigned int, sgi_test_count); > + > +void gic_sgi_test_interrupt(void) > +{ > + this_cpu(sgi_test_count)++; In sgi_count(), you are using ACCESS_ONCE() to read the content of the variable, but I am not entirely sure this_cpu(...)++ is guarantee to be a single write. As this happen on different CPU, don't we also need to use ACCESS_ONCE() here too or atomically increment? [...] > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index 078049e741..6a132c64e1 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -330,6 +330,11 @@ static void do_static_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi) > case GIC_SGI_CALL_FUNCTION: > smp_call_function_interrupt(); > break; > +#ifdef CONFIG_BOOT_SELFTEST > + case GIC_SGI_TEST: > + gic_sgi_test_interrupt(); > + break; > +#endif > default: > panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id()); > break; > diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h > index ee2c26adb4..40635a9d32 100644 > --- a/xen/arch/arm/include/asm/gic.h > +++ b/xen/arch/arm/include/asm/gic.h > @@ -306,6 +306,9 @@ enum gic_sgi { > GIC_SGI_EVENT_CHECK, > GIC_SGI_DUMP_STATE, > GIC_SGI_CALL_FUNCTION, > +#ifdef CONFIG_BOOT_SELFTEST > + GIC_SGI_TEST, > +#endif > GIC_SGI_STATIC_MAX, > }; > > @@ -321,6 +324,11 @@ extern void send_SGI_one(unsigned int cpu, enum gic_sgi sgi); > extern void send_SGI_self(enum gic_sgi sgi); > extern void send_SGI_allbutself(enum gic_sgi sgi); > > +#ifdef CONFIG_BOOT_SELFTEST > +/* Record a GIC_SGI_TEST delivered to this CPU (see arch/arm/gic-test.c). */ I would suggest to remove (see ...). One can easily find gic_sgi_test_interrupt() and this reduces the risk of stale file name. > +void gic_sgi_test_interrupt(void); > +#endif > + > /* print useful debug info */ > extern void gic_dump_info(struct vcpu *v); > extern void gic_dump_vgic_info(struct vcpu *v); > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h > index 0adfa4993a..2fdf5da526 100644 > --- a/xen/arch/arm/include/asm/setup.h > +++ b/xen/arch/arm/include/asm/setup.h > @@ -50,6 +50,15 @@ void setup_mm(void); > extern uint32_t hyp_traps_vector[]; > void init_traps(void); > > +#ifdef CONFIG_BOOT_SELFTEST > +#define __initcallboottest(fn) \ > + static const initcall_t __initcall_##fn __init_call("boottest") = (fn) > + > +void do_init_boottests(void); > +#else > +static inline void do_init_boottests(void) {} > +#endif > + > int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt, > struct rangeset *iomem_ranges, struct rangeset *irq_ranges); > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 6310a47d68..c7abbdb04e 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -83,6 +83,24 @@ static void __init init_idle_domain(void) > /* TODO: setup_idle_pagetable(); */ > } > > +#ifdef CONFIG_BOOT_SELFTEST > +extern const initcall_t __initcall_boot_test_start[], > + __initcall_boot_test_end[]; > + > +void do_init_boottests(void) > +{ > + const initcall_t *call; > + > + printk("CPU%u: boot self-tests start\n", smp_processor_id()); > + > + for ( call = __initcall_boot_test_start; call < __initcall_boot_test_end; > + call++ ) > + (*call)(); > + > + printk("CPU%u: boot self-tests done\n", smp_processor_id()); > +} > +#endif /* CONFIG_BOOT_SELFTEST */ > + > static const char * __initdata processor_implementers[] = { > ['A'] = "ARM Limited", > ['B'] = "Broadcom Corporation", > @@ -470,6 +488,8 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) > enable_errata_workarounds(); > enable_cpu_features(); > > + do_init_boottests(); > + > /* Create initial domain 0. */ > if ( !is_dom0less_mode() ) > create_dom0(); > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > index 1806c47a08..97d8b19cf4 100644 > --- a/xen/arch/arm/smpboot.c > +++ b/xen/arch/arm/smpboot.c > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include Style: I think this wants to go after asm/tee/tee.h (acpi.h seems to be misplaced). > #include > #include > > @@ -413,6 +414,8 @@ void asmlinkage noreturn start_secondary(void) > > printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id()); > > + do_init_boottests(); > + > startup_cpu_idle_loop(); > } > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S > index 2d5f1c516d..14f64a856c 100644 > --- a/xen/arch/arm/xen.lds.S > +++ b/xen/arch/arm/xen.lds.S > @@ -146,6 +146,10 @@ SECTIONS > *(.initcall1.init) > __initcall_end = .; > > + __initcall_boot_test_start = .; > + *(.initcallboottest.init) > + __initcall_boot_test_end = .; > + > . = ALIGN(4); > __alt_instructions = .; > *(.altinstructions) Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Sep 04 20:01:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 20:01:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409103.1641276 (Exim 4.92) (envelope-from ) id 1x2a6B-0006pM-TD; Fri, 04 Sep 2026 20:01:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409103.1641276; Fri, 04 Sep 2026 20:01:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2a6B-0006pF-Pm; Fri, 04 Sep 2026 20:01:19 +0000 Received: by outflank-mailman (input) for mailman id 1409103; Fri, 04 Sep 2026 20:01:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2a69-0006p9-GM for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 20:01:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2a68-00BBEn-TC for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 22:01:16 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b2371-8faa-0a2a0a5109dd-0a2a4508c06a-32 for ; Fri, 04 Sep 2026 22:01:16 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b238b-f659-0a2a45080019-aa0a817c936b-3 for ; Fri, 04 Sep 2026 22:01:16 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-453-VChG_IsiNHqq84Is3Jl6Iw-1; Fri, 04 Sep 2026 16:01:08 -0400 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id BC56B19560B5; Fri, 4 Sep 2026 20:01:00 +0000 (UTC) Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E9D201955F01; Fri, 4 Sep 2026 20:00:53 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788552075; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lxBbvAr67l+ay1JAMD0STbt+EdH/TmTJeK9Lr7BezhA=; b=KmZpTUQ/W4EDR9Is6tjGamcOnZlSkhmrn+i4oXYKYRDr+aKOaPb83YEav7amjBGglwIYYz d0tDsyD5Chhu5ZbjjDvvWOWk/SYddTV1wtE/X9jT0w+K4PG98d1phqRmrClyIN7oNQIVvc udGweyqARv6qebcSTLhF+m9ylJfdDsk= X-MC-Unique: VChG_IsiNHqq84Is3Jl6Iw-1 X-Mimecast-MFC-AGG-ID: VChG_IsiNHqq84Is3Jl6Iw_1788552062 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Fri, 04 Sep 2026 23:58:29 +0400 Subject: [PATCH v4 46/75] qom: convert scalar properties to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20260904-qom-qapi-v4-46-a985f168e938@redhat.com> References: <20260904-qom-qapi-v4-0-a985f168e938@redhat.com> In-Reply-To: <20260904-qom-qapi-v4-0-a985f168e938@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Michael Roth , Pierrick Bouvier , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Alexander Graf , Richard Henderson , "Gonglei (Arei)" , zhenwei pi , David Hildenbrand , Igor Mammedov , Alberto Garcia , Kevin Wolf , Hanna Reitz , "Michael S. Tsirkin" , Ani Sinha , Peter Maydell , Luc Michel , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Steven Lee , Troy Lee , Jamin Lin , Kane Chen , Andrew Jeffery , Joel Stanley , Samuel Tardieu , Marcelo Tosatti , John Snow , "Denis V. Lunev" , Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , FangSheng Huang , Tyrone Ting , Hao Wu , Jason Wang , Keith Busch , Klaus Jensen , Jesper Devantier , Nicholas Piggin , Aditya Gupta , Glenn Miles , Harsh Prateek Bora , Amit Machhiwal , Conor Dooley , Sebastian Huber , Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , Halil Pasic , Christian Borntraeger , Jason Herne , Ilya Leoshkevich , Eric Farman , Matthew Rosato , Cornelia Huck , Titus Rwantare , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Zhang Chen , Li Zhijian , Peter Xu , Chinmay Rath , Hendrik Brueckner , kvm@vger.kernel.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, linux-cxl@vger.kernel.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org X-Developer-Signature: v=1; a=openpgp-sha256; l=108088; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=cHU4sMAOTK0nyjqP8Kte0SJwDuBniWlAjYgt6I7u8VY=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqmyLKEZ5SvUfjS5X2xFeeknK9H7KeJC0Ms2+/K BrbtjNQrcaJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapsiygAKCRDa6OEJdZac 5b+mEACScl4BbdYgc3pRJej9WkBSQGao4mCcmcadphCYf9peTiIH9x45yjfg+H2XxEilltlPmJU BEkeFi/UzK7MdHZdu3JKngI03qCG2f5cBRrwQRYQpZepcoiQBTex+6e7mqJ/fWmSd31t6XzGXfK 3eA2AdQEXHYrX9bC91wRBbVVEMM1DapYApnaaFn9c8vnDW9xvqynWEINrzfzKMVGK0ifbNCguYt gZPbobnnbfNVpIGIL9pn998cQawlphkgzTB8080gNtKZMkVD0Hpb7JTKWsHRDmy+SaAZTU7N9g1 2PBPw9Hi6nRyF4TRJziJxJhTqSIw+lISCtCwjkRnATTj6F1W+whp8f/7kWQrLclt2oytmLQb1r6 wjMB7X23rCcBm+cdk6Ys3UjjHbJHRcCZbLaRpzUqgj+v8/khFUEyRxXe0hDS1HaCHMRqNwjbx3c GfY/m/Wf4ODlRNiGGqYkPEwU/jYq6DxyNjnknhN7uDcCyLQ0utDuY7+LiKvkOvWfwe7i1N9p7L7 73w5ZSfaLZgJFj5aWCVSZrvr6nT9GibTyAhyNDIIfgVY4G8ngBA3Q1OSBxFrqS75Zu4gS0iUYU+ Hqe+Ggtf+hccnj57z6hNv159RookAUSqCV0ncNAvQ1BuJV2Z/TEhDIkuVzPuvR+X6XmzdYTcyQn +1frzdeAbEMkiHg== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: AUf_b-MJNhv7QUT0Q89yclkUfJOwfYSXueCBtFGYpRA_1788552062 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788552076-D7B59BDB-04830E4A/0/0 X-purgate-type: clean X-purgate-size: 108090 Signed-off-by: Marc-André Lureau --- accel/kvm/kvm-all.c | 5 ++- accel/nitro/nitro-accel.c | 3 +- accel/tcg/tcg-all.c | 3 +- backends/cryptodev.c | 7 ++-- backends/hostmem-file.c | 4 +- backends/hostmem-memfd.c | 3 +- backends/hostmem.c | 6 +-- block/throttle-groups.c | 5 ++- crypto/secret_keyring.c | 9 +++-- event-loop-base.c | 7 ++-- hw/acpi/ich9.c | 1 + hw/acpi/pci.c | 7 ++-- hw/arm/virt.c | 4 +- hw/core/clock.c | 3 +- hw/core/machine.c | 2 +- hw/cpu/core.c | 10 +++-- hw/cxl/cxl-host.c | 2 +- hw/gpio/aspeed_gpio.c | 5 ++- hw/gpio/aspeed_sgpio.c | 3 +- hw/gpio/stm32l4x5_gpio.c | 5 ++- hw/i386/pc.c | 6 +-- hw/i386/sgx-epc.c | 3 +- hw/i386/x86.c | 6 +-- hw/ide/ide-dev.c | 3 +- hw/intc/apic_common.c | 3 +- hw/loongarch/virt.c | 2 +- hw/mem/nvdimm.c | 7 ++-- hw/mem/pc-dimm.c | 3 +- hw/misc/aspeed_lpc.c | 73 +++++++++++++++++++++++++------------ hw/misc/aspeed_sdmc.c | 3 +- hw/misc/npcm7xx_mft.c | 3 +- hw/net/ne2000-isa.c | 3 +- hw/nvme/ctrl.c | 3 +- hw/pci-bridge/pci_expander_bridge.c | 3 +- hw/pci-host/i440fx.c | 29 +++++++++------ hw/pci-host/pnv_phb3.c | 5 ++- hw/pci-host/pnv_phb4.c | 5 ++- hw/pci-host/q35.c | 9 +++-- hw/ppc/spapr_drc.c | 3 +- hw/riscv/microchip_pfsoc.c | 3 +- hw/s390x/sclpcpi.c | 8 ++-- hw/s390x/virtio-ccw-mem.c | 3 +- hw/sensor/adc128d818.c | 16 +++++--- hw/sensor/adm1266.c | 3 +- hw/sensor/adm1272.c | 9 +++-- hw/sensor/emc141x.c | 9 +++-- hw/sensor/isl_pmbus_vr.c | 19 +++++----- hw/sensor/lsm303dlhc_mag.c | 9 +++-- hw/sensor/max34451.c | 5 ++- hw/sensor/tmp105.c | 3 +- hw/sensor/tmp421.c | 9 +++-- hw/usb/dev-storage-classic.c | 3 +- hw/virtio/virtio-balloon.c | 3 +- hw/virtio/virtio-mem-pci.c | 3 +- hw/virtio/virtio-mem.c | 18 +++++---- hw/xen/xen-pvh-common.c | 9 +++-- iothread.c | 9 +++-- net/colo-compare.c | 7 ++-- net/dump.c | 6 ++- net/filter-buffer.c | 3 +- qom/object.c | 42 ++++++++++----------- system/bootdevice.c | 3 +- system/memory.c | 5 ++- target/arm/cpu64.c | 11 +++--- target/arm/kvm.c | 3 +- target/arm/tcg/cpu64.c | 11 +++--- target/i386/cpu.c | 12 +++--- target/i386/kvm/kvm.c | 8 ++-- target/i386/sev.c | 2 +- target/ppc/compat.c | 3 +- target/riscv/cpu.c | 15 ++++---- target/riscv/kvm/kvm-cpu.c | 7 ++-- target/riscv/tcg/tcg-cpu.c | 13 ++++--- target/s390x/cpu_models.c | 5 ++- tests/unit/test-qdev-global-props.c | 11 ++++-- ui/console.c | 3 +- util/thread-context.c | 7 ++-- 77 files changed, 343 insertions(+), 241 deletions(-) diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index e2cfbcf44046..ff9db3ca8b3d 100644 --- a/accel/kvm/kvm-all.c +++ b/accel/kvm/kvm-all.c @@ -24,6 +24,7 @@ #include "qemu/config-file.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/pci/msi.h" #include "hw/pci/msix.h" #include "hw/s390x/adapter.h" @@ -4278,13 +4279,13 @@ static void kvm_accel_class_init(ObjectClass *oc, const void *data) .description = "Configure KVM in-kernel irqchip", )); - object_class_property_add(oc, "kvm-shadow-mem", "int", + object_class_property_add_qapi(oc, "kvm-shadow-mem", &int_type_info, kvm_get_kvm_shadow_mem, kvm_set_kvm_shadow_mem, NULL, NULL); object_class_property_set_description(oc, "kvm-shadow-mem", "KVM shadow MMU size"); - object_class_property_add(oc, "dirty-ring-size", "uint32", + object_class_property_add_qapi(oc, "dirty-ring-size", &uint32_type_info, kvm_get_dirty_ring_size, kvm_set_dirty_ring_size, NULL, NULL); object_class_property_set_description(oc, "dirty-ring-size", diff --git a/accel/nitro/nitro-accel.c b/accel/nitro/nitro-accel.c index a1e97a9162e9..05841c1277dc 100644 --- a/accel/nitro/nitro-accel.c +++ b/accel/nitro/nitro-accel.c @@ -29,6 +29,7 @@ #include "qemu/osdep.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qemu/rcu.h" @@ -238,7 +239,7 @@ static void nitro_accel_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, "debug-mode", "Start enclave in debug mode (enables console output)"); - object_class_property_add(oc, "enclave-cid", "uint64", + object_class_property_add_qapi(oc, "enclave-cid", &uint64_type_info, nitro_get_enclave_cid, nitro_set_enclave_cid, NULL, NULL); diff --git a/accel/tcg/tcg-all.c b/accel/tcg/tcg-all.c index 767e8805552f..277cf0e2d012 100644 --- a/accel/tcg/tcg-all.c +++ b/accel/tcg/tcg-all.c @@ -29,6 +29,7 @@ #include "exec/icount.h" #include "tcg/startup.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/error-report.h" #include "qemu/accel.h" #include "qemu/atomic.h" @@ -270,7 +271,7 @@ static void tcg_accel_class_init(ObjectClass *oc, const void *data) tcg_get_thread, tcg_set_thread); - object_class_property_add(oc, "tb-size", "uint32", + object_class_property_add_qapi(oc, "tb-size", &uint32_type_info, tcg_get_tb_size, tcg_set_tb_size, NULL, NULL); object_class_property_set_description(oc, "tb-size", diff --git a/backends/cryptodev.c b/backends/cryptodev.c index e8f2b18f2017..a69adb70440c 100644 --- a/backends/cryptodev.c +++ b/backends/cryptodev.c @@ -25,6 +25,7 @@ #include "system/cryptodev.h" #include "system/stats.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-commands-cryptodev.h" #include "qapi/qapi-types-stats.h" #include "qapi/visitor.h" @@ -622,15 +623,15 @@ cryptodev_backend_class_init(ObjectClass *oc, const void *data) ucc->prepare_delete = cryptodev_backend_prepare_delete; QTAILQ_INIT(&crypto_clients); - object_class_property_add(oc, "queues", "uint32", + object_class_property_add_qapi(oc, "queues", &uint32_type_info, cryptodev_backend_get_queues, cryptodev_backend_set_queues, NULL, NULL); - object_class_property_add(oc, "throttle-bps", "uint64", + object_class_property_add_qapi(oc, "throttle-bps", &uint64_type_info, cryptodev_backend_get_bps, cryptodev_backend_set_bps, NULL, NULL); - object_class_property_add(oc, "throttle-ops", "uint64", + object_class_property_add_qapi(oc, "throttle-ops", &uint64_type_info, cryptodev_backend_get_ops, cryptodev_backend_set_ops, NULL, NULL); diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c index 9c7e0183d480..aeb6fc37858c 100644 --- a/backends/hostmem-file.c +++ b/backends/hostmem-file.c @@ -275,11 +275,11 @@ file_backend_class_init(ObjectClass *oc, const void *data) file_memory_backend_get_discard_data, file_memory_backend_set_discard_data); object_class_property_add_str(oc, "mem-path", get_mem_path, set_mem_path); - object_class_property_add(oc, "align", "uint64", + object_class_property_add_qapi(oc, "align", &uint64_type_info, file_memory_backend_get_align, file_memory_backend_set_align, NULL, NULL); - object_class_property_add(oc, "offset", "int", + object_class_property_add_qapi(oc, "offset", &int_type_info, file_memory_backend_get_offset, file_memory_backend_set_offset, NULL, NULL); diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c index e21c5a3f2e24..42027529ab50 100644 --- a/backends/hostmem-memfd.c +++ b/backends/hostmem-memfd.c @@ -16,6 +16,7 @@ #include "qemu/memfd.h" #include "qemu/module.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qom/object.h" #include "migration/cpr.h" @@ -145,7 +146,7 @@ memfd_backend_class_init(ObjectClass *oc, const void *data) memfd_backend_set_hugetlb); object_class_property_set_description(oc, "hugetlb", "Use huge pages"); - object_class_property_add(oc, "hugetlbsize", "uint64", + object_class_property_add_qapi(oc, "hugetlbsize", &uint64_type_info, memfd_backend_get_hugetlbsize, memfd_backend_set_hugetlbsize, NULL, NULL); diff --git a/backends/hostmem.c b/backends/hostmem.c index e7f9b436a459..d05ab53ab662 100644 --- a/backends/hostmem.c +++ b/backends/hostmem.c @@ -529,7 +529,7 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data) host_memory_backend_set_prealloc); object_class_property_set_description(oc, "prealloc", "Preallocate memory"); - object_class_property_add(oc, "prealloc-threads", "int", + object_class_property_add_qapi(oc, "prealloc-threads", &int_type_info, host_memory_backend_get_prealloc_threads, host_memory_backend_set_prealloc_threads, NULL, NULL); @@ -540,13 +540,13 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data) object_property_allow_set_link, OBJ_PROP_LINK_STRONG); object_class_property_set_description(oc, "prealloc-context", "Context to use for creating CPU threads for preallocation"); - object_class_property_add(oc, "size", "size", + object_class_property_add_qapi(oc, "size", &size_type_info, host_memory_backend_get_size, host_memory_backend_set_size, NULL, NULL); object_class_property_set_description(oc, "size", "Size of the memory region (ex: 500M)"); - object_class_property_add(oc, "host-nodes", "[uint16]", + object_class_property_add_qapi(oc, "host-nodes", &uint16List_type_info, host_memory_backend_get_host_nodes, host_memory_backend_set_host_nodes, NULL, NULL); diff --git a/block/throttle-groups.c b/block/throttle-groups.c index 6312157802da..851617237f80 100644 --- a/block/throttle-groups.c +++ b/block/throttle-groups.c @@ -31,6 +31,7 @@ #include "qemu/thread.h" #include "system/qtest.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-type-infos-block-core.h" #include "qapi/qapi-visit-block-core.h" #include "qom/object.h" @@ -983,9 +984,9 @@ static void throttle_group_obj_class_init(ObjectClass *klass, /* individual properties */ for (i = 0; i < sizeof(properties) / sizeof(ThrottleParamInfo); i++) { - object_class_property_add(klass, + object_class_property_add_qapi(klass, properties[i].name, - "int64", + &int64_type_info, throttle_group_get, throttle_group_set, NULL, &properties[i]); diff --git a/crypto/secret_keyring.c b/crypto/secret_keyring.c index 78d7f09b3b97..de813e79d8d6 100644 --- a/crypto/secret_keyring.c +++ b/crypto/secret_keyring.c @@ -21,6 +21,7 @@ #include "qemu/osdep.h" #include #include +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/error.h" #include "qom/object_interfaces.h" #include "trace.h" @@ -108,10 +109,10 @@ qcrypto_secret_keyring_class_init(ObjectClass *oc, const void *data) QCryptoSecretCommonClass *sic = QCRYPTO_SECRET_COMMON_CLASS(oc); sic->load_data = qcrypto_secret_keyring_load_data; - object_class_property_add(oc, "serial", "int32_t", - qcrypto_secret_prop_get_key, - qcrypto_secret_prop_set_key, - NULL, NULL); + object_class_property_add_qapi(oc, "serial", &int32_type_info, + qcrypto_secret_prop_get_key, + qcrypto_secret_prop_set_key, + NULL, NULL); } diff --git a/event-loop-base.c b/event-loop-base.c index 23f554d92ce8..c16c5366f680 100644 --- a/event-loop-base.c +++ b/event-loop-base.c @@ -14,6 +14,7 @@ #include "qemu/osdep.h" #include "qom/object_interfaces.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "block/thread-pool.h" #include "system/event-loop-base.h" @@ -104,15 +105,15 @@ static void event_loop_base_class_init(ObjectClass *klass, ucc->complete = event_loop_base_complete; ucc->prepare_delete = event_loop_base_prepare_delete; - object_class_property_add(klass, "aio-max-batch", "int64", + object_class_property_add_qapi(klass, "aio-max-batch", &int64_type_info, event_loop_base_get_param, event_loop_base_set_param, NULL, &aio_max_batch_info); - object_class_property_add(klass, "thread-pool-min", "int64", + object_class_property_add_qapi(klass, "thread-pool-min", &int64_type_info, event_loop_base_get_param, event_loop_base_set_param, NULL, &thread_pool_min_info); - object_class_property_add(klass, "thread-pool-max", "int64", + object_class_property_add_qapi(klass, "thread-pool-max", &int64_type_info, event_loop_base_get_param, event_loop_base_set_param, NULL, &thread_pool_max_info); diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c index 8082eae4282a..cf503668c00a 100644 --- a/hw/acpi/ich9.c +++ b/hw/acpi/ich9.c @@ -26,6 +26,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/pci/pci.h" #include "migration/vmstate.h" diff --git a/hw/acpi/pci.c b/hw/acpi/pci.c index c82924be8620..71d01307e141 100644 --- a/hw/acpi/pci.c +++ b/hw/acpi/pci.c @@ -27,6 +27,7 @@ #include "qemu/error-report.h" #include "qom/object_interfaces.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/core/boards.h" #include "hw/acpi/aml-build.h" #include "hw/acpi/pci.h" @@ -139,7 +140,7 @@ static void acpi_generic_initiator_class_init(ObjectClass *oc, const void *data) acpi_generic_initiator_set_pci_device); object_class_property_set_description(oc, "pci-dev", "PCI device to associate with the node"); - object_class_property_add(oc, "node", "uint32", NULL, + object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL, acpi_generic_initiator_set_node, NULL, NULL); object_class_property_set_description(oc, "node", "NUMA node associated with the PCI device"); @@ -253,8 +254,8 @@ static void acpi_generic_port_class_init(ObjectClass *oc, const void *data) acpi_generic_port_set_pci_bus); object_class_property_set_description(oc, "pci-bus", "PCI Bus of the host bridge associated with this GP affinity structure"); - object_class_property_add(oc, "node", "uint32", NULL, - acpi_generic_port_set_node, NULL, NULL); + object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL, + acpi_generic_port_set_node, NULL, NULL); object_class_property_set_description(oc, "node", "The NUMA node like ID to index HMAT/SLIT NUMA properties involving GP"); } diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 872920b6482b..4e5d8d9f86e3 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -4258,7 +4258,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) "Set on/off to enable/disable high " "memory region for PCI MMIO"); - object_class_property_add(oc, "highmem-mmio-size", "size", + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_info, virt_get_highmem_mmio_size, virt_set_highmem_mmio_size, NULL, NULL); @@ -4266,7 +4266,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) "Set the high memory region size " "for PCI MMIO"); - object_class_property_add(oc, "virtio-mmio-transports", "uint8", + object_class_property_add_qapi(oc, "virtio-mmio-transports", &uint8_type_info, virt_get_virtio_transports, virt_set_virtio_transports, NULL, NULL); diff --git a/hw/core/clock.c b/hw/core/clock.c index 3fc98a0c65d5..f55cb17af77e 100644 --- a/hw/core/clock.c +++ b/hw/core/clock.c @@ -13,6 +13,7 @@ #include "qemu/osdep.h" #include "qemu/cutils.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "system/qtest.h" #include "hw/core/clock.h" @@ -185,7 +186,7 @@ static void clock_initfn(Object *obj) QLIST_INIT(&clk->children); if (qtest_enabled()) { - object_property_add(obj, "qtest-clock-period", "uint64", + object_property_add_qapi(obj, "qtest-clock-period", &uint64_type_info, clock_period_prop_get, NULL, NULL, NULL); } } diff --git a/hw/core/machine.c b/hw/core/machine.c index 530fbaeb0b28..aa2d90a4e4df 100644 --- a/hw/core/machine.c +++ b/hw/core/machine.c @@ -1133,7 +1133,7 @@ static void machine_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, "smp-cache", "Cache properties list for SMP machine"); - object_class_property_add(oc, "phandle-start", "int", + object_class_property_add_qapi(oc, "phandle-start", &int_type_info, machine_get_phandle_start, machine_set_phandle_start, NULL, NULL); object_class_property_set_description(oc, "phandle-start", diff --git a/hw/cpu/core.c b/hw/cpu/core.c index 26e488f3d8e3..d7c89f47ab04 100644 --- a/hw/cpu/core.c +++ b/hw/cpu/core.c @@ -12,6 +12,7 @@ #include "hw/core/boards.h" #include "hw/cpu/core.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" static void core_prop_get_core_id(Object *obj, Visitor *v, const char *name, @@ -82,10 +83,11 @@ static void cpu_core_class_init(ObjectClass *oc, const void *data) DeviceClass *dc = DEVICE_CLASS(oc); set_bit(DEVICE_CATEGORY_CPU, dc->categories); - object_class_property_add(oc, "core-id", "int", core_prop_get_core_id, - core_prop_set_core_id, NULL, NULL); - object_class_property_add(oc, "nr-threads", "int", core_prop_get_nr_threads, - core_prop_set_nr_threads, NULL, NULL); + object_class_property_add_qapi(oc, "core-id", &int_type_info, core_prop_get_core_id, + core_prop_set_core_id, NULL, NULL); + object_class_property_add_qapi(oc, "nr-threads", &int_type_info, + core_prop_get_nr_threads, core_prop_set_nr_threads, + NULL, NULL); } static const TypeInfo cpu_core_type_info = { diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c index 7592c4ac6c7b..4133398fec48 100644 --- a/hw/cxl/cxl-host.c +++ b/hw/cxl/cxl-host.c @@ -565,7 +565,7 @@ static void machine_set_cfmw(Object *obj, Visitor *v, const char *name, void cxl_machine_init(Object *obj, CXLState *state) { - object_property_add(obj, "cxl", "bool", machine_get_cxl, + object_property_add_qapi(obj, "cxl", &bool_type_info, machine_get_cxl, machine_set_cxl, NULL, state); object_property_set_description(obj, "cxl", "Set on/off to enable/disable " diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c index 1cf6f5df5505..0c90bcd723da 100644 --- a/hw/gpio/aspeed_gpio.c +++ b/hw/gpio/aspeed_gpio.c @@ -12,6 +12,7 @@ #include "hw/gpio/aspeed_gpio.h" #include "hw/misc/aspeed_scu.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/irq.h" #include "migration/vmstate.h" @@ -1481,7 +1482,7 @@ static void aspeed_gpio_init(Object *obj) int pin_idx = j % GPIOS_PER_GROUP; const char *group = &props->group_label[group_idx][0]; char *name = g_strdup_printf("gpio%s%d", group, pin_idx); - object_property_add(obj, name, "bool", aspeed_gpio_get_pin, + object_property_add_qapi(obj, name, &bool_type_info, aspeed_gpio_get_pin, aspeed_gpio_set_pin, NULL, NULL); g_free(name); } @@ -1489,7 +1490,7 @@ static void aspeed_gpio_init(Object *obj) for (int i = 0; i < agc->nr_gpio_sets; i++) { g_autofree char *name = g_strdup_printf("gpio-set[%d]", i); - object_property_add(obj, name, "uint32", aspeed_gpio_get_set, + object_property_add_qapi(obj, name, &uint32_type_info, aspeed_gpio_get_set, aspeed_gpio_set_set, NULL, NULL); } } diff --git a/hw/gpio/aspeed_sgpio.c b/hw/gpio/aspeed_sgpio.c index 7d2f73699520..67b0c10d79fa 100644 --- a/hw/gpio/aspeed_sgpio.c +++ b/hw/gpio/aspeed_sgpio.c @@ -11,6 +11,7 @@ #include "qemu/log.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/irq.h" #include "hw/core/qdev-properties.h" @@ -300,7 +301,7 @@ static void aspeed_sgpio_init(Object *obj) { for (int i = 0; i < ASPEED_SGPIO_MAX_PIN_PAIR * 2; i++) { g_autofree char *name = g_strdup_printf("sgpio%03d", i); - object_property_add(obj, name, "bool", aspeed_sgpio_get_pin, + object_property_add_qapi(obj, name, &bool_type_info, aspeed_sgpio_get_pin, aspeed_sgpio_set_pin, NULL, NULL); } } diff --git a/hw/gpio/stm32l4x5_gpio.c b/hw/gpio/stm32l4x5_gpio.c index 92fa397fbafe..d349d41e41a1 100644 --- a/hw/gpio/stm32l4x5_gpio.c +++ b/hw/gpio/stm32l4x5_gpio.c @@ -25,6 +25,7 @@ #include "hw/core/qdev-properties.h" #include "qapi/visitor.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "migration/vmstate.h" #include "trace.h" @@ -409,10 +410,10 @@ static void stm32l4x5_gpio_init(Object *obj) s->clk = qdev_init_clock_in(DEVICE(s), "clk", NULL, s, 0); - object_property_add(obj, "disconnected-pins", "uint16", + object_property_add_qapi(obj, "disconnected-pins", &uint16_type_info, disconnected_pins_get, disconnected_pins_set, NULL, &s->disconnected_pins); - object_property_add(obj, "clock-freq-hz", "uint32", + object_property_add_qapi(obj, "clock-freq-hz", &uint32_type_info, clock_freq_get, NULL, NULL, NULL); } diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 18b5dc169ab7..24c4c589ed04 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1720,7 +1720,7 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data) mc->default_ram_id = "pc.ram"; pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_AUTO; - object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size", + object_class_property_add_qapi(oc, PC_MACHINE_MAX_RAM_BELOW_4G, &size_type_info, pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g, NULL, NULL); object_class_property_set_description(oc, PC_MACHINE_MAX_RAM_BELOW_4G, @@ -1758,13 +1758,13 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data) pc_machine_get_default_bus_bypass_iommu, pc_machine_set_default_bus_bypass_iommu); - object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size", + object_class_property_add_qapi(oc, PC_MACHINE_MAX_FW_SIZE, &size_type_info, pc_machine_get_max_fw_size, pc_machine_set_max_fw_size, NULL, NULL); object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE, "Maximum combined firmware size"); - object_class_property_add(oc, PC_MACHINE_SMBIOS_EP, "str", + object_class_property_add_qapi(oc, PC_MACHINE_SMBIOS_EP, &str_type_info, pc_machine_get_smbios_ep, pc_machine_set_smbios_ep, NULL, NULL); object_class_property_set_description(oc, PC_MACHINE_SMBIOS_EP, diff --git a/hw/i386/sgx-epc.c b/hw/i386/sgx-epc.c index d3fe10028c51..d9b9ab3f7a96 100644 --- a/hw/i386/sgx-epc.c +++ b/hw/i386/sgx-epc.c @@ -15,6 +15,7 @@ #include "hw/mem/memory-device.h" #include "hw/core/qdev-properties.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "target/i386/cpu.h" #include "system/address-spaces.h" @@ -43,7 +44,7 @@ static void sgx_epc_get_size(Object *obj, Visitor *v, const char *name, static void sgx_epc_init(Object *obj) { - object_property_add(obj, SGX_EPC_SIZE_PROP, "uint64", sgx_epc_get_size, + object_property_add_qapi(obj, SGX_EPC_SIZE_PROP, &uint64_type_info, sgx_epc_get_size, NULL, NULL, NULL); } diff --git a/hw/i386/x86.c b/hw/i386/x86.c index 63f297a10532..d0c782ec8544 100644 --- a/hw/i386/x86.c +++ b/hw/i386/x86.c @@ -420,9 +420,9 @@ static void x86_machine_class_init(ObjectClass *oc, const void *data) "in ACPI table header." "The string may be up to 8 bytes in size"); - object_class_property_add(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, "uint64_t", - x86_machine_get_bus_lock_ratelimit, - x86_machine_set_bus_lock_ratelimit, NULL, NULL); + object_class_property_add_qapi(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, &uint64_type_info, + x86_machine_get_bus_lock_ratelimit, + x86_machine_set_bus_lock_ratelimit, NULL, NULL); object_class_property_set_description(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, "Set the ratelimit for the bus locks acquired in VMs"); diff --git a/hw/ide/ide-dev.c b/hw/ide/ide-dev.c index 5d478588c614..e2dd2439991f 100644 --- a/hw/ide/ide-dev.c +++ b/hw/ide/ide-dev.c @@ -19,6 +19,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-types-block.h" #include "qemu/error-report.h" #include "qemu/module.h" @@ -174,7 +175,7 @@ out: static void ide_dev_instance_init(Object *obj) { - object_property_add(obj, "bootindex", "int32", + object_property_add_qapi(obj, "bootindex", &int32_type_info, ide_dev_get_bootindex, ide_dev_set_bootindex, NULL, NULL); object_property_set_int(obj, "bootindex", -1, NULL); diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c index 0f0f37d45734..dc0517ceea90 100644 --- a/hw/intc/apic_common.c +++ b/hw/intc/apic_common.c @@ -22,6 +22,7 @@ #include "qemu/error-report.h" #include "qemu/module.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/i386/apic.h" #include "hw/i386/apic_internal.h" @@ -442,7 +443,7 @@ static void apic_common_initfn(Object *obj) APICCommonState *s = APIC_COMMON(obj); s->id = s->initial_apic_id = -1; - object_property_add(obj, "id", "uint32", + object_property_add_qapi(obj, "id", &uint32_type_info, apic_common_get_id, apic_common_set_id, NULL, NULL); } diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 750ce2dbe5fc..209a0feddd80 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -1520,7 +1520,7 @@ static void virt_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, "highmem-mmio", "Set on/off to enable/disable high " "memory region for PCI MMIO"); - object_class_property_add(oc, "highmem-mmio-size", "size", + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_info, virt_get_highmem_mmio_size, virt_set_highmem_mmio_size, NULL, NULL); diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c index cf8a4d8c5f2a..123ddc938546 100644 --- a/hw/mem/nvdimm.c +++ b/hw/mem/nvdimm.c @@ -26,6 +26,7 @@ #include "qemu/module.h" #include "qemu/pmem.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/mem/nvdimm.h" #include "hw/core/qdev-properties.h" @@ -99,9 +100,9 @@ static void nvdimm_set_uuid(Object *obj, Visitor *v, const char *name, static void nvdimm_init(Object *obj) { - object_property_add(obj, NVDIMM_LABEL_SIZE_PROP, "size", - nvdimm_get_label_size, nvdimm_set_label_size, NULL, - NULL); + object_property_add_qapi(obj, NVDIMM_LABEL_SIZE_PROP, &size_type_info, + nvdimm_get_label_size, nvdimm_set_label_size, NULL, + NULL); object_property_add(obj, NVDIMM_UUID_PROP, "QemuUUID", nvdimm_get_uuid, nvdimm_set_uuid, NULL, NULL); diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c index 68862926ee2d..ee586ecc0c7d 100644 --- a/hw/mem/pc-dimm.c +++ b/hw/mem/pc-dimm.c @@ -26,6 +26,7 @@ #include "hw/mem/nvdimm.h" #include "hw/mem/memory-device.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "system/hostmem.h" @@ -176,7 +177,7 @@ static void pc_dimm_get_size(Object *obj, Visitor *v, const char *name, static void pc_dimm_init(Object *obj) { - object_property_add(obj, PC_DIMM_SIZE_PROP, "uint64", pc_dimm_get_size, + object_property_add_qapi(obj, PC_DIMM_SIZE_PROP, &uint64_type_info, pc_dimm_get_size, NULL, NULL, NULL); } diff --git a/hw/misc/aspeed_lpc.c b/hw/misc/aspeed_lpc.c index 7f7e4f1a0985..e2d9b7572f27 100644 --- a/hw/misc/aspeed_lpc.c +++ b/hw/misc/aspeed_lpc.c @@ -12,6 +12,7 @@ #include "qemu/error-report.h" #include "hw/misc/aspeed_lpc.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/irq.h" #include "hw/core/qdev-properties.h" @@ -417,30 +418,54 @@ static void aspeed_lpc_realize(DeviceState *dev, Error **errp) static void aspeed_lpc_init(Object *obj) { - object_property_add(obj, "idr1", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "odr1", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "str1", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "idr2", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "odr2", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "str2", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "idr3", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "odr3", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "str3", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "idr4", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "odr4", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "str4", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); + object_property_add_qapi(obj, "idr1", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "odr1", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "str1", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "idr2", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "odr2", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "str2", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "idr3", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "odr3", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "str3", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "idr4", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "odr4", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "str4", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); } static const VMStateDescription vmstate_aspeed_lpc = { diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c index f8fbaebee6ab..d096cc88f5c5 100644 --- a/hw/misc/aspeed_sdmc.c +++ b/hw/misc/aspeed_sdmc.c @@ -15,6 +15,7 @@ #include "hw/core/qdev-properties.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "trace.h" #include "qemu/units.h" #include "qemu/cutils.h" @@ -259,7 +260,7 @@ static void aspeed_sdmc_set_ram_size(Object *obj, Visitor *v, const char *name, static void aspeed_sdmc_initfn(Object *obj) { - object_property_add(obj, "ram-size", "int", + object_property_add_qapi(obj, "ram-size", &int_type_info, aspeed_sdmc_get_ram_size, aspeed_sdmc_set_ram_size, NULL, NULL); } diff --git a/hw/misc/npcm7xx_mft.c b/hw/misc/npcm7xx_mft.c index 742166c4e828..99e9e49788c0 100644 --- a/hw/misc/npcm7xx_mft.c +++ b/hw/misc/npcm7xx_mft.c @@ -23,6 +23,7 @@ #include "hw/core/registerfields.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/bitops.h" #include "qemu/error-report.h" @@ -491,7 +492,7 @@ static void npcm7xx_mft_init(Object *obj) s->clock_2 = qdev_init_clock_out(dev, "clock2"); for (int i = 0; i < NPCM7XX_PWM_PER_MODULE; ++i) { - object_property_add(obj, "max_rpm[*]", "uint32", + object_property_add_qapi(obj, "max_rpm[*]", &uint32_type_info, npcm7xx_mft_get_max_rpm, npcm7xx_mft_set_max_rpm, NULL, &s->max_rpm[i]); diff --git a/hw/net/ne2000-isa.c b/hw/net/ne2000-isa.c index 673c785abc94..63e0d40ee726 100644 --- a/hw/net/ne2000-isa.c +++ b/hw/net/ne2000-isa.c @@ -29,6 +29,7 @@ #include "ne2000.h" #include "system/system.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qom/object.h" @@ -131,7 +132,7 @@ out: static void isa_ne2000_instance_init(Object *obj) { - object_property_add(obj, "bootindex", "int32", + object_property_add_qapi(obj, "bootindex", &int32_type_info, isa_ne2000_get_bootindex, isa_ne2000_set_bootindex, NULL, NULL); object_property_set_int(obj, "bootindex", -1, NULL); diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c index 4893cf7e7418..e4549aa9e534 100644 --- a/hw/nvme/ctrl.c +++ b/hw/nvme/ctrl.c @@ -203,6 +203,7 @@ #include "qemu/units.h" #include "qemu/range.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "system/system.h" #include "system/block-backend.h" @@ -10578,7 +10579,7 @@ static void nvme_instance_init(Object *obj) "bootindex", "/namespace@1,0", DEVICE(obj)); - object_property_add(obj, "smart_critical_warning", "uint8", + object_property_add_qapi(obj, "smart_critical_warning", &uint8_type_info, nvme_get_smart_warning, nvme_set_smart_warning, NULL, NULL); } diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c index 40ffbc4e0821..9bb7d3c9debe 100644 --- a/hw/pci-bridge/pci_expander_bridge.c +++ b/hw/pci-bridge/pci_expander_bridge.c @@ -12,6 +12,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/pci/pci.h" #include "hw/pci/pci_bus.h" #include "hw/pci/pci_host.h" @@ -103,7 +104,7 @@ static void pxb_bus_class_init(ObjectClass *class, const void *data) pbc->bus_num = pxb_bus_num; pbc->numa_node = pxb_bus_numa_node; - object_class_property_add(class, "acpi_uid", "uint32", + object_class_property_add_qapi(class, "acpi_uid", &uint32_type_info, prop_pxb_uid_get, NULL, NULL, NULL); object_class_property_set_description(class, "acpi_uid", "ACPI Unique ID used to distinguish this PCI Host Bridge / ACPI00016"); diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c index c1982f7962a6..feafa6a72fe4 100644 --- a/hw/pci-host/i440fx.c +++ b/hw/pci-host/i440fx.c @@ -32,6 +32,7 @@ #include "hw/core/qdev-properties.h" #include "hw/core/sysbus.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "migration/vmstate.h" #include "qapi/visitor.h" #include "qemu/error-report.h" @@ -387,21 +388,25 @@ static void i440fx_pcihost_class_init(ObjectClass *klass, const void *data) /* Reason: needs to be wired up by pc_init1 */ dc->user_creatable = false; - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_START, "uint32", - i440fx_pcihost_get_pci_hole_start, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_START, + &uint32_type_info, + i440fx_pcihost_get_pci_hole_start, + NULL, NULL, NULL); - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_END, "uint32", - i440fx_pcihost_get_pci_hole_end, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_END, + &uint32_type_info, + i440fx_pcihost_get_pci_hole_end, + NULL, NULL, NULL); - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_START, "uint64", - i440fx_pcihost_get_pci_hole64_start, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_START, + &uint64_type_info, + i440fx_pcihost_get_pci_hole64_start, + NULL, NULL, NULL); - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_END, "uint64", - i440fx_pcihost_get_pci_hole64_end, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_END, + &uint64_type_info, + i440fx_pcihost_get_pci_hole64_end, + NULL, NULL, NULL); } static const TypeInfo i440fx_pcihost_info = { diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c index db061c134e95..667e9585ab8f 100644 --- a/hw/pci-host/pnv_phb3.c +++ b/hw/pci-host/pnv_phb3.c @@ -11,6 +11,7 @@ #include "qemu/bswap.h" #include "qapi/visitor.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/pci-host/pnv_phb3_regs.h" #include "hw/pci-host/pnv_phb.h" #include "hw/pci-host/pnv_phb3.h" @@ -1164,12 +1165,12 @@ static void pnv_phb3_root_bus_class_init(ObjectClass *klass, const void *data) { BusClass *k = BUS_CLASS(klass); - object_class_property_add(klass, "phb-id", "uint32", + object_class_property_add_qapi(klass, "phb-id", &uint32_type_info, pnv_phb3_root_bus_get_prop, pnv_phb3_root_bus_set_prop, NULL, NULL); - object_class_property_add(klass, "chip-id", "uint32", + object_class_property_add_qapi(klass, "chip-id", &uint32_type_info, pnv_phb3_root_bus_get_prop, pnv_phb3_root_bus_set_prop, NULL, NULL); diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c index 9acaf4c0c2f5..96c2f89f889b 100644 --- a/hw/pci-host/pnv_phb4.c +++ b/hw/pci-host/pnv_phb4.c @@ -11,6 +11,7 @@ #include "qemu/bswap.h" #include "qapi/visitor.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "target/ppc/cpu.h" #include "hw/pci-host/pnv_phb4_regs.h" #include "hw/pci-host/pnv_phb4.h" @@ -1761,12 +1762,12 @@ static void pnv_phb4_root_bus_class_init(ObjectClass *klass, const void *data) { BusClass *k = BUS_CLASS(klass); - object_class_property_add(klass, "phb-id", "uint32", + object_class_property_add_qapi(klass, "phb-id", &uint32_type_info, pnv_phb4_root_bus_get_prop, pnv_phb4_root_bus_set_prop, NULL, NULL); - object_class_property_add(klass, "chip-id", "uint32", + object_class_property_add_qapi(klass, "chip-id", &uint32_type_info, pnv_phb4_root_bus_get_prop, pnv_phb4_root_bus_set_prop, NULL, NULL); diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c index f4556ad03a04..6eba30e06811 100644 --- a/hw/pci-host/q35.c +++ b/hw/pci-host/q35.c @@ -35,6 +35,7 @@ #include "hw/core/qdev-properties.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" @@ -226,19 +227,19 @@ static void q35_host_initfn(Object *obj) qdev_prop_set_uint64(DEVICE(s), PCI_HOST_PROP_PCI_HOLE64_SIZE, Q35_PCI_HOST_HOLE64_SIZE_DEFAULT); - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32", + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_START, &uint32_type_info, q35_host_get_pci_hole_start, NULL, NULL, NULL); - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "uint32", + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_END, &uint32_type_info, q35_host_get_pci_hole_end, NULL, NULL, NULL); - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "uint64", + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_START, &uint64_type_info, q35_host_get_pci_hole64_start, NULL, NULL, NULL); - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "uint64", + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_END, &uint64_type_info, q35_host_get_pci_hole64_end, NULL, NULL, NULL); diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c index 5c2150b71c86..64f9ca29b02e 100644 --- a/hw/ppc/spapr_drc.c +++ b/hw/ppc/spapr_drc.c @@ -12,6 +12,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qobject/qnull.h" #include "qemu/cutils.h" #include "hw/ppc/spapr_drc.h" @@ -584,7 +585,7 @@ static void spapr_dr_connector_instance_init(Object *obj) SpaprDrcClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc); object_property_add_uint32_ptr(obj, "id", &drc->id, OBJ_PROP_FLAG_READ); - object_property_add(obj, "index", "uint32", prop_get_index, + object_property_add_qapi(obj, "index", &uint32_type_info, prop_get_index, NULL, NULL, NULL); object_property_add(obj, "fdt", "struct", prop_get_fdt, NULL, NULL, NULL); diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c index 60bb96da0161..cf3974577463 100644 --- a/hw/riscv/microchip_pfsoc.c +++ b/hw/riscv/microchip_pfsoc.c @@ -39,6 +39,7 @@ #include "qemu/units.h" #include "qemu/cutils.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/boards.h" #include "hw/core/loader.h" @@ -741,7 +742,7 @@ static void microchip_icicle_kit_machine_class_init(ObjectClass *oc, */ mc->default_ram_size = 1537 * MiB; - object_class_property_add(oc, "clint-timebase-frequency", "uint32_t", + object_class_property_add_qapi(oc, "clint-timebase-frequency", &uint32_type_info, microchip_icicle_kit_get_clint_timebase_freq, microchip_icicle_kit_set_clint_timebase_freq, NULL, NULL); diff --git a/hw/s390x/sclpcpi.c b/hw/s390x/sclpcpi.c index ec4bdf23509b..97d37ae4b932 100644 --- a/hw/s390x/sclpcpi.c +++ b/hw/s390x/sclpcpi.c @@ -53,6 +53,7 @@ #include "qemu/timer.h" #include "hw/s390x/event-facility.h" #include "hw/s390x/ebcdic.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-visit-machine.h" #include "qapi/qapi-events-machine-s390x.h" #include "migration/vmstate.h" @@ -195,12 +196,13 @@ static void cpi_class_init(ObjectClass *klass, const void *data) "name of the cluster which the VM belongs to, if any" " e.g. \"PLEX \""); - object_class_property_add(klass, "system_level", "uint64", get_system_level, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, "system_level", + &uint64_type_info, get_system_level, + NULL, NULL, NULL); object_class_property_set_description(klass, "system_level", "distribution and kernel version in Linux e.g. 74872343805430528"); - object_class_property_add(klass, "timestamp", "uint64", get_timestamp, + object_class_property_add_qapi(klass, "timestamp", &uint64_type_info, get_timestamp, NULL, NULL, NULL); object_class_property_set_description(klass, "timestamp", "latest update of CPI data in nanoseconds since the UNIX EPOCH"); diff --git a/hw/s390x/virtio-ccw-mem.c b/hw/s390x/virtio-ccw-mem.c index dea30aacfb32..046dfd544cf3 100644 --- a/hw/s390x/virtio-ccw-mem.c +++ b/hw/s390x/virtio-ccw-mem.c @@ -13,6 +13,7 @@ #include "qemu/osdep.h" #include "hw/core/qdev-properties.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/module.h" #include "virtio-ccw-mem.h" #include "hw/mem/memory-device.h" @@ -205,7 +206,7 @@ static void virtio_ccw_mem_instance_init(Object *obj) OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZE_PROP); object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->vdev), VIRTIO_MEM_SIZE_PROP); - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, virtio_ccw_mem_get_requested_size, virtio_ccw_mem_set_requested_size, NULL, NULL); } diff --git a/hw/sensor/adc128d818.c b/hw/sensor/adc128d818.c index c65508cba144..b0f93e28d19f 100644 --- a/hw/sensor/adc128d818.c +++ b/hw/sensor/adc128d818.c @@ -8,6 +8,7 @@ #include "qemu/osdep.h" #include "qemu/log.h" +#include "qapi-builtin-type-infos.h" #include "qapi/error.h" #include "qapi/visitor.h" #include "qom/object.h" @@ -642,15 +643,18 @@ static void adc128d818_initfn(Object *obj) for (unsigned ch = 0u; ch < ADC128D818_NUM_CHANNELS; ch++) { char *name = g_strdup_printf("ain%u", ch); - object_property_add(obj, name, "int", adc128d818_get_ain, - adc128d818_set_ain, NULL, NULL); + object_property_add_qapi(obj, name, &int_type_info, + adc128d818_get_ain, + adc128d818_set_ain, NULL, NULL); g_free(name); } - object_property_add(obj, "temperature", "int", adc128d818_get_temperature, - adc128d818_set_temperature, NULL, NULL); - object_property_add(obj, "ext-vref-mv", "int", adc128d818_get_ext_vref, - adc128d818_set_ext_vref, NULL, NULL); + object_property_add_qapi(obj, "temperature", &int_type_info, + adc128d818_get_temperature, + adc128d818_set_temperature, NULL, NULL); + object_property_add_qapi(obj, "ext-vref-mv", &int_type_info, + adc128d818_get_ext_vref, + adc128d818_set_ext_vref, NULL, NULL); } static void adc128d818_realize(DeviceState *dev, Error **errp) diff --git a/hw/sensor/adm1266.c b/hw/sensor/adm1266.c index 37d1cffd57a9..62f563af7a7a 100644 --- a/hw/sensor/adm1266.c +++ b/hw/sensor/adm1266.c @@ -14,6 +14,7 @@ #include "hw/core/irq.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/log.h" #include "qemu/module.h" @@ -217,7 +218,7 @@ static void adm1266_init(Object *obj) for (int i = 0; i < ADM1266_NUM_PAGES; i++) { pmbus_page_config(pmdev, i, flags); - object_property_add(obj, "vout[*]", "uint16", + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, adm1266_get, adm1266_set, NULL, &pmdev->pages[i].read_vout); } diff --git a/hw/sensor/adm1272.c b/hw/sensor/adm1272.c index 0aa2a8655683..e1c1bf1c54de 100644 --- a/hw/sensor/adm1272.c +++ b/hw/sensor/adm1272.c @@ -12,6 +12,7 @@ #include "hw/core/irq.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/log.h" #include "qemu/module.h" @@ -493,19 +494,19 @@ static void adm1272_init(Object *obj) pmbus_page_config(pmdev, 0, flags); - object_property_add(obj, "vin", "uint16", + object_property_add_qapi(obj, "vin", &uint16_type_info, adm1272_get, adm1272_set, NULL, &pmdev->pages[0].read_vin); - object_property_add(obj, "vout", "uint16", + object_property_add_qapi(obj, "vout", &uint16_type_info, adm1272_get, adm1272_set, NULL, &pmdev->pages[0].read_vout); - object_property_add(obj, "iout", "uint16", + object_property_add_qapi(obj, "iout", &uint16_type_info, adm1272_get, adm1272_set, NULL, &pmdev->pages[0].read_iout); - object_property_add(obj, "pin", "uint16", + object_property_add_qapi(obj, "pin", &uint16_type_info, adm1272_get, adm1272_set, NULL, &pmdev->pages[0].read_pin); diff --git a/hw/sensor/emc141x.c b/hw/sensor/emc141x.c index a51fc44395ab..5efe94643ca0 100644 --- a/hw/sensor/emc141x.c +++ b/hw/sensor/emc141x.c @@ -22,6 +22,7 @@ #include "hw/i2c/i2c.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qom/object.h" @@ -251,16 +252,16 @@ static void emc141x_reset(DeviceState *dev) static void emc141x_initfn(Object *obj) { - object_property_add(obj, "temperature0", "int", + object_property_add_qapi(obj, "temperature0", &int_type_info, emc141x_get_temperature, emc141x_set_temperature, NULL, NULL); - object_property_add(obj, "temperature1", "int", + object_property_add_qapi(obj, "temperature1", &int_type_info, emc141x_get_temperature, emc141x_set_temperature, NULL, NULL); - object_property_add(obj, "temperature2", "int", + object_property_add_qapi(obj, "temperature2", &int_type_info, emc141x_get_temperature, emc141x_set_temperature, NULL, NULL); - object_property_add(obj, "temperature3", "int", + object_property_add_qapi(obj, "temperature3", &int_type_info, emc141x_get_temperature, emc141x_set_temperature, NULL, NULL); } diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c index 0fad04def773..8923e9e87510 100644 --- a/hw/sensor/isl_pmbus_vr.c +++ b/hw/sensor/isl_pmbus_vr.c @@ -9,6 +9,7 @@ #include "qemu/osdep.h" #include "hw/sensor/isl_pmbus_vr.h" #include "hw/core/qdev-properties.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/log.h" #include "qemu/module.h" @@ -136,63 +137,63 @@ static void isl_pmbus_vr_add_props(Object *obj, uint64_t *flags, uint8_t pages) PMBusDevice *pmdev = PMBUS_DEVICE(obj); for (int i = 0; i < pages; i++) { if (flags[i] & PB_HAS_VIN) { - object_property_add(obj, "vin[*]", "uint16", + object_property_add_qapi(obj, "vin[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_vin); } if (flags[i] & PB_HAS_VOUT) { - object_property_add(obj, "vout[*]", "uint16", + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_vout); } if (flags[i] & PB_HAS_IIN) { - object_property_add(obj, "iin[*]", "uint16", + object_property_add_qapi(obj, "iin[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_iin); } if (flags[i] & PB_HAS_IOUT) { - object_property_add(obj, "iout[*]", "uint16", + object_property_add_qapi(obj, "iout[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_iout); } if (flags[i] & PB_HAS_PIN) { - object_property_add(obj, "pin[*]", "uint16", + object_property_add_qapi(obj, "pin[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_pin); } if (flags[i] & PB_HAS_POUT) { - object_property_add(obj, "pout[*]", "uint16", + object_property_add_qapi(obj, "pout[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_pout); } if (flags[i] & PB_HAS_TEMPERATURE) { - object_property_add(obj, "temp1[*]", "uint16", + object_property_add_qapi(obj, "temp1[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_temperature_1); } if (flags[i] & PB_HAS_TEMP2) { - object_property_add(obj, "temp2[*]", "uint16", + object_property_add_qapi(obj, "temp2[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_temperature_2); } if (flags[i] & PB_HAS_TEMP3) { - object_property_add(obj, "temp3[*]", "uint16", + object_property_add_qapi(obj, "temp3[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_temperature_3); diff --git a/hw/sensor/lsm303dlhc_mag.c b/hw/sensor/lsm303dlhc_mag.c index cd5773ae64e8..c8085739ca47 100644 --- a/hw/sensor/lsm303dlhc_mag.c +++ b/hw/sensor/lsm303dlhc_mag.c @@ -25,6 +25,7 @@ #include "hw/i2c/i2c.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qemu/log.h" @@ -509,19 +510,19 @@ static void lsm303dlhc_mag_reset(DeviceState *dev) */ static void lsm303dlhc_mag_initfn(Object *obj) { - object_property_add(obj, "mag-x", "int", + object_property_add_qapi(obj, "mag-x", &int_type_info, lsm303dlhc_mag_get_x, lsm303dlhc_mag_set_x, NULL, NULL); - object_property_add(obj, "mag-y", "int", + object_property_add_qapi(obj, "mag-y", &int_type_info, lsm303dlhc_mag_get_y, lsm303dlhc_mag_set_y, NULL, NULL); - object_property_add(obj, "mag-z", "int", + object_property_add_qapi(obj, "mag-z", &int_type_info, lsm303dlhc_mag_get_z, lsm303dlhc_mag_set_z, NULL, NULL); - object_property_add(obj, "temperature", "int", + object_property_add_qapi(obj, "temperature", &int_type_info, lsm303dlhc_mag_get_temperature, lsm303dlhc_mag_set_temperature, NULL, NULL); } diff --git a/hw/sensor/max34451.c b/hw/sensor/max34451.c index 4d64434f3af4..3c8fa3d4a861 100644 --- a/hw/sensor/max34451.c +++ b/hw/sensor/max34451.c @@ -11,6 +11,7 @@ #include "hw/core/irq.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/log.h" #include "qemu/module.h" @@ -727,7 +728,7 @@ static void max34451_init(Object *obj) /* get and set the voltage in millivolts, max is 32767 mV */ for (int i = 0; i < MAX34451_NUM_PWR_DEVICES; i++) { - object_property_add(obj, "vout[*]", "uint16", + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, max34451_get, max34451_set, NULL, &pmdev->pages[i].read_vout); } @@ -737,7 +738,7 @@ static void max34451_init(Object *obj) * centidegrees Celsius i.e.: 2500 -> 25.00 C, max is 327.67 C */ for (int i = 0; i < MAX34451_NUM_TEMP_DEVICES; i++) { - object_property_add(obj, "temperature[*]", "uint16", + object_property_add_qapi(obj, "temperature[*]", &uint16_type_info, max34451_get, max34451_set, NULL, diff --git a/hw/sensor/tmp105.c b/hw/sensor/tmp105.c index c5089d74f4bf..ce4ff4856afb 100644 --- a/hw/sensor/tmp105.c +++ b/hw/sensor/tmp105.c @@ -24,6 +24,7 @@ #include "migration/vmstate.h" #include "hw/sensor/tmp105.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "hw/core/registerfields.h" @@ -308,7 +309,7 @@ static void tmp105_realize(DeviceState *dev, Error **errp) static void tmp105_initfn(Object *obj) { - object_property_add(obj, "temperature", "int", + object_property_add_qapi(obj, "temperature", &int_type_info, tmp105_get_temperature, tmp105_set_temperature, NULL, NULL); } diff --git a/hw/sensor/tmp421.c b/hw/sensor/tmp421.c index 127edd0ba568..60844e76b21f 100644 --- a/hw/sensor/tmp421.c +++ b/hw/sensor/tmp421.c @@ -28,6 +28,7 @@ #include "hw/i2c/i2c.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qom/object.h" @@ -350,16 +351,16 @@ static void tmp421_class_init(ObjectClass *klass, const void *data) dc->vmsd = &vmstate_tmp421; sc->dev = (DeviceInfo *) data; - object_class_property_add(klass, "temperature0", "int", + object_class_property_add_qapi(klass, "temperature0", &int_type_info, tmp421_get_temperature, tmp421_set_temperature, NULL, NULL); - object_class_property_add(klass, "temperature1", "int", + object_class_property_add_qapi(klass, "temperature1", &int_type_info, tmp421_get_temperature, tmp421_set_temperature, NULL, NULL); - object_class_property_add(klass, "temperature2", "int", + object_class_property_add_qapi(klass, "temperature2", &int_type_info, tmp421_get_temperature, tmp421_set_temperature, NULL, NULL); - object_class_property_add(klass, "temperature3", "int", + object_class_property_add_qapi(klass, "temperature3", &int_type_info, tmp421_get_temperature, tmp421_set_temperature, NULL, NULL); } diff --git a/hw/usb/dev-storage-classic.c b/hw/usb/dev-storage-classic.c index 977151c4a087..06584092bcae 100644 --- a/hw/usb/dev-storage-classic.c +++ b/hw/usb/dev-storage-classic.c @@ -9,6 +9,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/usb/usb.h" #include "hw/usb/desc.h" @@ -122,7 +123,7 @@ out: static void usb_msd_instance_init(Object *obj) { - object_property_add(obj, "bootindex", "int32", + object_property_add_qapi(obj, "bootindex", &int32_type_info, usb_msd_get_bootindex, usb_msd_set_bootindex, NULL, NULL); object_property_set_int(obj, "bootindex", -1, NULL); diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c index 4c5f486ba238..9e43948128f7 100644 --- a/hw/virtio/virtio-balloon.c +++ b/hw/virtio/virtio-balloon.c @@ -27,6 +27,7 @@ #include "hw/virtio/virtio-balloon.h" #include "system/address-spaces.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-events-machine.h" #include "qapi/visitor.h" #include "trace.h" @@ -1022,7 +1023,7 @@ static void virtio_balloon_instance_init(Object *obj) object_property_add(obj, "guest-stats", "guest statistics", balloon_stats_get_all, NULL, NULL, NULL); - object_property_add(obj, "guest-stats-polling-interval", "int", + object_property_add_qapi(obj, "guest-stats-polling-interval", &int_type_info, balloon_stats_get_poll_interval, balloon_stats_set_poll_interval, NULL, NULL); diff --git a/hw/virtio/virtio-mem-pci.c b/hw/virtio/virtio-mem-pci.c index f592eb1a7849..80e9bfedd9f5 100644 --- a/hw/virtio/virtio-mem-pci.c +++ b/hw/virtio/virtio-mem-pci.c @@ -14,6 +14,7 @@ #include "virtio-mem-pci.h" #include "hw/mem/memory-device.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-events-machine.h" #include "qapi/qapi-events-misc.h" @@ -211,7 +212,7 @@ static void virtio_mem_pci_instance_init(Object *obj) OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZE_PROP); object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->vdev), VIRTIO_MEM_SIZE_PROP); - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, virtio_mem_pci_get_requested_size, virtio_mem_pci_set_requested_size, NULL, NULL); } diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c index 7130ed852d9c..42dc028e3bdc 100644 --- a/hw/virtio/virtio-mem.c +++ b/hw/virtio/virtio-mem.c @@ -26,6 +26,7 @@ #include "hw/virtio/virtio-bus.h" #include "hw/virtio/virtio-mem.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "migration/misc.h" #include "hw/core/boards.h" @@ -1533,14 +1534,15 @@ static void virtio_mem_instance_init(Object *obj) notifier_list_init(&vmem->size_change_notifiers); - object_property_add(obj, VIRTIO_MEM_SIZE_PROP, "size", virtio_mem_get_size, - NULL, NULL, NULL); - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", - virtio_mem_get_requested_size, - virtio_mem_set_requested_size, NULL, NULL); - object_property_add(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, "size", - virtio_mem_get_block_size, virtio_mem_set_block_size, - NULL, NULL); + object_property_add_qapi(obj, VIRTIO_MEM_SIZE_PROP, &size_type_info, + virtio_mem_get_size, + NULL, NULL, NULL); + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, + virtio_mem_get_requested_size, + virtio_mem_set_requested_size, NULL, NULL); + object_property_add_qapi(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, &size_type_info, + virtio_mem_get_block_size, virtio_mem_set_block_size, + NULL, NULL); } static void virtio_mem_instance_finalize(Object *obj) diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c index cca37202ffb2..7b4fd933a8fb 100644 --- a/hw/xen/xen-pvh-common.c +++ b/hw/xen/xen-pvh-common.c @@ -9,6 +9,7 @@ #include "qemu/osdep.h" #include "qemu/error-report.h" #include "qemu/units.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/boards.h" #include "hw/core/irq.h" @@ -413,7 +414,7 @@ void xen_pvh_class_setup_common_props(XenPVHMachineClass *xpc) #define OC_MEMMAP_PROP_BASE(c, prop_name, name) \ do { \ - object_class_property_add(c, prop_name "-base", "uint64_t", \ + object_class_property_add_qapi(c, prop_name "-base", &uint64_type_info,\ xen_pvh_get_ ## name ## _base, \ xen_pvh_set_ ## name ## _base, NULL, NULL); \ object_class_property_set_description(oc, prop_name "-base", \ @@ -422,7 +423,7 @@ do { \ #define OC_MEMMAP_PROP_SIZE(c, prop_name, name) \ do { \ - object_class_property_add(c, prop_name "-size", "uint64_t", \ + object_class_property_add_qapi(c, prop_name "-size", &size_type_info, \ xen_pvh_get_ ## name ## _size, \ xen_pvh_set_ ## name ## _size, NULL, NULL); \ object_class_property_set_description(oc, prop_name "-size", \ @@ -458,7 +459,7 @@ do { \ OC_MEMMAP_PROP(oc, "pci-mmio", pci_mmio); OC_MEMMAP_PROP(oc, "pci-mmio-high", pci_mmio_high); - object_class_property_add(oc, "pci-intx-irq-base", "uint32_t", + object_class_property_add_qapi(oc, "pci-intx-irq-base", &uint32_type_info, xen_pvh_get_pci_intx_irq_base, xen_pvh_set_pci_intx_irq_base, NULL, NULL); @@ -468,7 +469,7 @@ do { \ #ifdef CONFIG_TPM if (xpc->has_tpm) { - object_class_property_add(oc, "tpm-base-addr", "uint64_t", + object_class_property_add_qapi(oc, "tpm-base-addr", &uint64_type_info, xen_pvh_get_tpm_base, xen_pvh_set_tpm_base, NULL, NULL); diff --git a/iothread.c b/iothread.c index 76eea6df3861..7285135d40a8 100644 --- a/iothread.c +++ b/iothread.c @@ -20,6 +20,7 @@ #include "system/event-loop-base.h" #include "system/iothread.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-commands-misc.h" #include "qemu/error-report.h" #include "qemu/rcu.h" @@ -315,19 +316,19 @@ static void iothread_class_init(ObjectClass *klass, const void *class_data) bc->init = iothread_init; bc->update_params = iothread_set_aio_context_params; - object_class_property_add(klass, "poll-max-ns", "int64", + object_class_property_add_qapi(klass, "poll-max-ns", &int64_type_info, iothread_get_poll_param, iothread_set_poll_param, NULL, &poll_max_ns_info); - object_class_property_add(klass, "poll-grow", "int64", + object_class_property_add_qapi(klass, "poll-grow", &int64_type_info, iothread_get_poll_param, iothread_set_poll_param, NULL, &poll_grow_info); - object_class_property_add(klass, "poll-shrink", "int64", + object_class_property_add_qapi(klass, "poll-shrink", &int64_type_info, iothread_get_poll_param, iothread_set_poll_param, NULL, &poll_shrink_info); - object_class_property_add(klass, "poll-weight", "int64", + object_class_property_add_qapi(klass, "poll-weight", &int64_type_info, iothread_get_poll_param, iothread_set_poll_param, NULL, &poll_weight_info); diff --git a/net/colo-compare.c b/net/colo-compare.c index a6910de869ff..4b237a59d120 100644 --- a/net/colo-compare.c +++ b/net/colo-compare.c @@ -16,6 +16,7 @@ #include "qemu/error-report.h" #include "trace.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "net/net.h" #include "net/eth.h" #include "qom/object_interfaces.h" @@ -1373,15 +1374,15 @@ static void colo_compare_init(Object *obj) object_property_add_str(obj, "notify_dev", compare_get_notify_dev, compare_set_notify_dev); - object_property_add(obj, "compare_timeout", "uint64", + object_property_add_qapi(obj, "compare_timeout", &uint64_type_info, compare_get_timeout, compare_set_timeout, NULL, NULL); - object_property_add(obj, "expired_scan_cycle", "uint32", + object_property_add_qapi(obj, "expired_scan_cycle", &uint32_type_info, compare_get_expired_scan_cycle, compare_set_expired_scan_cycle, NULL, NULL); - object_property_add(obj, "max_queue_size", "uint32", + object_property_add_qapi(obj, "max_queue_size", &uint32_type_info, get_max_queue_size, set_max_queue_size, NULL, NULL); diff --git a/net/dump.c b/net/dump.c index 0c39f09892c2..3d7bb36182ec 100644 --- a/net/dump.c +++ b/net/dump.c @@ -25,6 +25,7 @@ #include "qemu/osdep.h" #include "clients.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/error-report.h" #include "qemu/iov.h" #include "qemu/module.h" @@ -238,8 +239,9 @@ static void filter_dump_class_init(ObjectClass *oc, const void *data) { NetFilterClass *nfc = NETFILTER_CLASS(oc); - object_class_property_add(oc, "maxlen", "uint32", filter_dump_get_maxlen, - filter_dump_set_maxlen, NULL, NULL); + object_class_property_add_qapi(oc, "maxlen", &uint32_type_info, + filter_dump_get_maxlen, + filter_dump_set_maxlen, NULL, NULL); object_class_property_add_str(oc, "file", file_dump_get_filename, file_dump_set_filename); diff --git a/net/filter-buffer.c b/net/filter-buffer.c index 427da24097f2..9d7a9f5cb2c7 100644 --- a/net/filter-buffer.c +++ b/net/filter-buffer.c @@ -10,6 +10,7 @@ #include "net/filter.h" #include "net/queue.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/timer.h" #include "qemu/iov.h" #include "qapi/qapi-builtin-visit.h" @@ -182,7 +183,7 @@ static void filter_buffer_class_init(ObjectClass *oc, const void *data) { NetFilterClass *nfc = NETFILTER_CLASS(oc); - object_class_property_add(oc, "interval", "uint32", + object_class_property_add_qapi(oc, "interval", &uint32_type_info, filter_buffer_get_interval, filter_buffer_set_interval, NULL, NULL); diff --git a/qom/object.c b/qom/object.c index 8e6ca25dc49d..bbaa999ae0c9 100644 --- a/qom/object.c +++ b/qom/object.c @@ -22,9 +22,9 @@ #include "qapi/string-output-visitor.h" #include "qapi/qobject-input-visitor.h" #include "qapi/forward-visitor.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-builtin-visit.h" #include "qobject/qdict.h" -#include "qobject/qjson.h" #include "qemu/id.h" #include "qapi/qmp/qerror.h" #include "trace.h" @@ -2429,7 +2429,7 @@ object_property_add_str(Object *obj, const char *name, prop->get = get; prop->set = set; - return object_property_add(obj, name, "string", + return object_property_add_qapi(obj, name, &str_type_info, get ? property_get_str : NULL, set ? property_set_str : NULL, property_release_data, @@ -2447,7 +2447,7 @@ object_class_property_add_str(ObjectClass *klass, const char *name, prop->get = get; prop->set = set; - return object_class_property_add(klass, name, "string", + return object_class_property_add_qapi(klass, name, &str_type_info, get ? property_get_str : NULL, set ? property_set_str : NULL, NULL, @@ -2499,7 +2499,7 @@ object_property_add_bool(Object *obj, const char *name, prop->get = get; prop->set = set; - return object_property_add(obj, name, "bool", + return object_property_add_qapi(obj, name, &bool_type_info, get ? property_get_bool : NULL, set ? property_set_bool : NULL, property_release_data, @@ -2516,7 +2516,7 @@ object_class_property_add_bool(ObjectClass *klass, const char *name, prop->get = get; prop->set = set; - return object_class_property_add(klass, name, "bool", + return object_class_property_add_qapi(klass, name, &bool_type_info, get ? property_get_bool : NULL, set ? property_set_bool : NULL, NULL, @@ -2856,8 +2856,8 @@ object_property_add_uint8_ptr(Object *obj, const char *name, setter = property_set_uint8_ptr; } - return object_property_add(obj, name, "uint8", - getter, setter, NULL, (void *)v); + return object_property_add_qapi(obj, name, &uint8_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -2897,8 +2897,8 @@ object_class_static_property_add_uint8_ptr(ObjectClass *klass, setter = property_set_uint8_ptr; } - return object_class_property_add(klass, name, "uint8", - getter, setter, NULL, (void *)v); + return object_class_property_add_qapi(klass, name, &uint8_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -2917,8 +2917,8 @@ object_property_add_uint16_ptr(Object *obj, const char *name, setter = property_set_uint16_ptr; } - return object_property_add(obj, name, "uint16", - getter, setter, NULL, (void *)v); + return object_property_add_qapi(obj, name, &uint16_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -2958,8 +2958,8 @@ object_class_static_property_add_uint16_ptr(ObjectClass *klass, setter = property_set_uint16_ptr; } - return object_class_property_add(klass, name, "uint16", - getter, setter, NULL, (void *)v); + return object_class_property_add_qapi(klass, name, &uint16_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -2978,8 +2978,8 @@ object_property_add_uint32_ptr(Object *obj, const char *name, setter = property_set_uint32_ptr; } - return object_property_add(obj, name, "uint32", - getter, setter, NULL, (void *)v); + return object_property_add_qapi(obj, name, &uint32_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -3019,8 +3019,8 @@ object_class_static_property_add_uint32_ptr(ObjectClass *klass, setter = property_set_uint32_ptr; } - return object_class_property_add(klass, name, "uint32", - getter, setter, NULL, (void *)v); + return object_class_property_add_qapi(klass, name, &uint32_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -3039,8 +3039,8 @@ object_property_add_uint64_ptr(Object *obj, const char *name, setter = property_set_uint64_ptr; } - return object_property_add(obj, name, "uint64", - getter, setter, NULL, (void *)v); + return object_property_add_qapi(obj, name, &uint64_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -3080,8 +3080,8 @@ object_class_static_property_add_uint64_ptr(ObjectClass *klass, setter = property_set_uint64_ptr; } - return object_class_property_add(klass, name, "uint64", - getter, setter, NULL, (void *)v); + return object_class_property_add_qapi(klass, name, &uint64_type_info, + getter, setter, NULL, (void *)v); } typedef struct { diff --git a/system/bootdevice.c b/system/bootdevice.c index 9538b08983f5..7789e464186a 100644 --- a/system/bootdevice.c +++ b/system/bootdevice.c @@ -24,6 +24,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "system/system.h" #include "qapi/visitor.h" #include "qemu/error-report.h" @@ -336,7 +337,7 @@ void device_add_bootindex_property(Object *obj, int32_t *bootindex, prop->suffix = suffix; prop->dev = dev; - object_property_add(obj, name, "int32", + object_property_add_qapi(obj, name, &int32_type_info, device_get_bootindex, device_set_bootindex, property_release_bootindex, diff --git a/system/memory.c b/system/memory.c index d4a0a5b81805..ae768cba80bd 100644 --- a/system/memory.c +++ b/system/memory.c @@ -16,6 +16,7 @@ #include "qemu/osdep.h" #include "qemu/log.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "system/memory.h" #include "qapi/visitor.h" #include "qemu/bitops.h" @@ -1318,11 +1319,11 @@ static void memory_region_initfn(Object *obj) object_property_add_uint64_ptr(OBJECT(mr), "addr", &mr->addr, OBJ_PROP_FLAG_READ); - object_property_add(OBJECT(mr), "priority", "int32", + object_property_add_qapi(OBJECT(mr), "priority", &int32_type_info, memory_region_get_priority, NULL, /* memory_region_set_priority */ NULL, NULL); - object_property_add(OBJECT(mr), "size", "uint64", + object_property_add_qapi(OBJECT(mr), "size", &uint64_type_info, memory_region_get_size, NULL, /* memory_region_set_size, */ NULL, NULL); diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c index 4e8c47253086..55df765e64d1 100644 --- a/target/arm/cpu64.c +++ b/target/arm/cpu64.c @@ -20,6 +20,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "cpu.h" #include "cpregs.h" #include "qemu/module.h" @@ -320,7 +321,7 @@ static void prop_bool_set_false(Object *obj, Visitor *v, const char *name, static void prop_add_stub_bool(Object *obj, const char *name) { - object_property_add(obj, name, "bool", prop_bool_get_false, + object_property_add_qapi(obj, name, &bool_type_info, prop_bool_get_false, prop_bool_set_false, NULL, NULL); } @@ -510,13 +511,13 @@ void aarch64_add_sve_properties(Object *obj) for (vq = 1; vq <= ARM_MAX_VQ; ++vq) { char name[8]; snprintf(name, sizeof(name), "sve%d", vq * 128); - object_property_add(obj, name, "bool", cpu_arm_get_vq, + object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_get_vq, cpu_arm_set_vq, NULL, &cpu->sve_vq); } #ifdef CONFIG_USER_ONLY /* Mirror linux /proc/sys/abi/sve_default_vector_length. */ - object_property_add(obj, "sve-default-vector-length", "int32", + object_property_add_qapi(obj, "sve-default-vector-length", &int32_type_info, cpu_arm_get_default_vec_len, cpu_arm_set_default_vec_len, NULL, &cpu->sve_default_vq); @@ -535,13 +536,13 @@ void aarch64_add_sme_properties(Object *obj) for (vq = 1; vq <= ARM_MAX_VQ; vq <<= 1) { char name[8]; snprintf(name, sizeof(name), "sme%d", vq * 128); - object_property_add(obj, name, "bool", cpu_arm_get_vq, + object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_get_vq, cpu_arm_set_vq, NULL, &cpu->sme_vq); } #ifdef CONFIG_USER_ONLY /* Mirror linux /proc/sys/abi/sme_default_vector_length. */ - object_property_add(obj, "sme-default-vector-length", "int32", + object_property_add_qapi(obj, "sme-default-vector-length", &int32_type_info, cpu_arm_get_default_vec_len, cpu_arm_set_default_vec_len, NULL, &cpu->sme_default_vq); diff --git a/target/arm/kvm.c b/target/arm/kvm.c index ed99be7fd80c..198b7615f4cc 100644 --- a/target/arm/kvm.c +++ b/target/arm/kvm.c @@ -20,6 +20,7 @@ #include "qemu/main-loop.h" #include "qom/object.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "system/system.h" #include "system/runstate.h" #include "system/ramblock.h" @@ -1777,7 +1778,7 @@ static void kvm_arch_set_eager_split_size(Object *obj, Visitor *v, void kvm_arch_accel_class_init(ObjectClass *oc) { - object_class_property_add(oc, "eager-split-size", "size", + object_class_property_add_qapi(oc, "eager-split-size", &size_type_info, kvm_arch_get_eager_split_size, kvm_arch_set_eager_split_size, NULL, NULL); diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c index affd87a3ae55..da8d44f1fc61 100644 --- a/target/arm/tcg/cpu64.c +++ b/target/arm/tcg/cpu64.c @@ -20,6 +20,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "cpu.h" #include "qemu/module.h" #include "qapi/visitor.h" @@ -1392,9 +1393,9 @@ void aarch64_max_v8_tcg_initfn(Object *obj) /* v8.2: FEAT_SVE */ cpu->sve_vq.supported = MAKE_64BIT_MASK(0, ARM_MAX_VQ); aarch64_add_sve_properties(OBJECT(cpu)); - object_property_add(OBJECT(cpu), "sve-max-vq", "uint32", - cpu_max_get_sve_max_vq, cpu_max_set_sve_max_vq, - NULL, NULL); + object_property_add_qapi(OBJECT(cpu), "sve-max-vq", &uint32_type_info, + cpu_max_get_sve_max_vq, + cpu_max_set_sve_max_vq, NULL, NULL); /* v8.2: FEAT_PAuth2 */ aarch64_add_pauth_properties(OBJECT(cpu)); @@ -1524,8 +1525,8 @@ void aarch64_max_v9_tcg_initfn(Object *obj) object_property_add_bool(obj, "x-rme", cpu_arm_get_rme, cpu_arm_set_rme); /* v9.4: FEAT_RME_GPC2 */ - object_property_add(obj, "x-l0gptsz", "uint32", cpu_max_get_l0gptsz, - cpu_max_set_l0gptsz, NULL, NULL); + object_property_add_qapi(obj, "x-l0gptsz", &uint32_type_info, cpu_max_get_l0gptsz, + cpu_max_set_l0gptsz, NULL, NULL); } static const ARMCPUInfo aarch64_cpus[] = { diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 8650ff6caecc..ebce8e128224 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -10431,7 +10431,7 @@ static void x86_cpu_register_bit_prop(X86CPUClass *xcc, fp = g_new0(BitProperty, 1); fp->w = w; fp->mask = mask; - object_class_property_add(oc, prop_name, "bool", + object_class_property_add_qapi(oc, prop_name, &bool_type_info, x86_cpu_get_bit_prop, x86_cpu_set_bit_prop, NULL, fp); @@ -10950,13 +10950,13 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) dc->user_creatable = true; - object_class_property_add(oc, "family", "uint64", + object_class_property_add_qapi(oc, "family", &uint64_type_info, x86_cpuid_version_get_family, x86_cpuid_version_set_family, NULL, NULL); - object_class_property_add(oc, "model", "uint64", + object_class_property_add_qapi(oc, "model", &uint64_type_info, x86_cpuid_version_get_model, x86_cpuid_version_set_model, NULL, NULL); - object_class_property_add(oc, "stepping", "uint64", + object_class_property_add_qapi(oc, "stepping", &uint64_type_info, x86_cpuid_version_get_stepping, x86_cpuid_version_set_stepping, NULL, NULL); object_class_property_add_str(oc, "vendor", @@ -10965,7 +10965,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) object_class_property_add_str(oc, "model-id", x86_cpuid_get_model_id, x86_cpuid_set_model_id); - object_class_property_add(oc, "tsc-frequency", "int", + object_class_property_add_qapi(oc, "tsc-frequency", &int_type_info, x86_cpuid_get_tsc_freq, x86_cpuid_set_tsc_freq, NULL, NULL); /* @@ -10978,7 +10978,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) x86_cpu_get_unavailable_features, NULL, NULL, NULL); - object_class_property_add(oc, "avx10-version", "uint8", + object_class_property_add_qapi(oc, "avx10-version", &uint8_type_info, x86_cpuid_get_avx10_version, x86_cpuid_set_avx10_version, NULL, NULL); diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index 9f65419a2c1a..aa4967adf99e 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -7099,7 +7099,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc) .set = kvm_arch_set_notify_vmexit, )); - object_class_property_add(oc, "notify-window", "uint32", + object_class_property_add_qapi(oc, "notify-window", &uint32_type_info, kvm_arch_get_notify_window, kvm_arch_set_notify_window, NULL, NULL); @@ -7107,7 +7107,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc) "Clock cycles without an event window " "after which a notification VM exit occurs"); - object_class_property_add(oc, "xen-version", "uint32", + object_class_property_add_qapi(oc, "xen-version", &uint32_type_info, kvm_arch_get_xen_version, kvm_arch_set_xen_version, NULL, NULL); @@ -7116,14 +7116,14 @@ void kvm_arch_accel_class_init(ObjectClass *oc) "(in XENVER_version form " "e.g. 0x4000a for 4.10)"); - object_class_property_add(oc, "xen-gnttab-max-frames", "uint16", + object_class_property_add_qapi(oc, "xen-gnttab-max-frames", &uint16_type_info, kvm_arch_get_xen_gnttab_max_frames, kvm_arch_set_xen_gnttab_max_frames, NULL, NULL); object_class_property_set_description(oc, "xen-gnttab-max-frames", "Maximum number of grant table frames"); - object_class_property_add(oc, "xen-evtchn-max-pirq", "uint16", + object_class_property_add_qapi(oc, "xen-evtchn-max-pirq", &uint16_type_info, kvm_arch_get_xen_evtchn_max_pirq, kvm_arch_set_xen_evtchn_max_pirq, NULL, NULL); diff --git a/target/i386/sev.c b/target/i386/sev.c index b2c7260c80a4..3a36fa4d0b95 100644 --- a/target/i386/sev.c +++ b/target/i386/sev.c @@ -3266,7 +3266,7 @@ sev_snp_guest_class_init(ObjectClass *oc, const void *data) x86_klass->adjust_cpuid_features = sev_snp_adjust_cpuid_features; x86_klass->kvm_type = sev_snp_kvm_type; - object_class_property_add(oc, "policy", "uint64", + object_class_property_add_qapi(oc, "policy", &uint64_type_info, sev_snp_guest_get_policy, sev_snp_guest_set_policy, NULL, NULL); object_class_property_add_str(oc, "guest-visible-workarounds", diff --git a/target/ppc/compat.c b/target/ppc/compat.c index 55de3bd5d5de..4d81225de37f 100644 --- a/target/ppc/compat.c +++ b/target/ppc/compat.c @@ -23,6 +23,7 @@ #include "kvm_ppc.h" #include "system/cpus.h" #include "qemu/error-report.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/error.h" #include "qapi/visitor.h" #include "cpu-models.h" @@ -335,7 +336,7 @@ void ppc_compat_add_property(Object *obj, const char *name, gchar *names, *desc; int i; - object_property_add(obj, name, "string", + object_property_add_qapi(obj, name, &str_type_info, ppc_compat_prop_get, ppc_compat_prop_set, NULL, compat_pvr); diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index fd1afbc7fe23..a1faea801d1d 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -27,6 +27,7 @@ #include "target/riscv/tcg/csr.h" #include "internals.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/error-report.h" #include "qemu/timer.h" @@ -1396,20 +1397,20 @@ void riscv_add_satp_mode_properties(Object *obj) { RISCVCPU *cpu = RISCV_CPU(obj); - object_property_add(obj, "svbare", "bool", cpu_riscv_get_satp, - cpu_riscv_set_satp, NULL, &cpu->satp_modes); + object_property_add_qapi(obj, "svbare", &bool_type_info, cpu_riscv_get_satp, + cpu_riscv_set_satp, NULL, &cpu->satp_modes); if (cpu->env.misa_mxl == MXL_RV32) { - object_property_add(obj, "sv32", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv32", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); } else { - object_property_add(obj, "sv39", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv39", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); - object_property_add(obj, "sv48", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv48", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); - object_property_add(obj, "sv57", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv57", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); - object_property_add(obj, "sv64", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv64", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); } } diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c index 68e1501b21e2..d2d6cb7a4c66 100644 --- a/target/riscv/kvm/kvm-cpu.c +++ b/target/riscv/kvm/kvm-cpu.c @@ -24,6 +24,7 @@ #include "qemu/timer.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/error-report.h" #include "qemu/main-loop.h" #include "qapi/visitor.h" @@ -532,7 +533,7 @@ static void riscv_cpu_add_kvm_unavail_prop(Object *obj, const char *prop_name) * unknown to KVM and error out if the user attempts * to enable any of them. */ - object_property_add(obj, prop_name, "bool", + object_property_add_qapi(obj, prop_name, &bool_type_info, cpu_get_cfg_unavailable, cpu_set_cfg_unavailable, NULL, (void *)prop_name); @@ -552,7 +553,7 @@ static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj) misa_cfg->name = riscv_get_misa_ext_name(bit); misa_cfg->description = riscv_get_misa_ext_description(bit); - object_property_add(cpu_obj, misa_cfg->name, "bool", + object_property_add_qapi(cpu_obj, misa_cfg->name, &bool_type_info, kvm_cpu_get_misa_ext_cfg, kvm_cpu_set_misa_ext_cfg, NULL, misa_cfg); @@ -568,7 +569,7 @@ static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj) for (i = 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) { KVMCPUConfig *multi_cfg = &kvm_multi_ext_cfgs[i]; - object_property_add(cpu_obj, multi_cfg->name, "bool", + object_property_add_qapi(cpu_obj, multi_cfg->name, &bool_type_info, kvm_cpu_get_multi_ext_cfg, kvm_cpu_set_multi_ext_cfg, NULL, multi_cfg); diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c index 9e3cc87f8a31..92e03a386832 100644 --- a/target/riscv/tcg/tcg-cpu.c +++ b/target/riscv/tcg/tcg-cpu.c @@ -26,6 +26,7 @@ #include "pmu.h" #include "time_helper.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/accel.h" #include "qemu/error-report.h" @@ -1438,7 +1439,7 @@ static void riscv_cpu_add_misa_properties(Object *cpu_obj) continue; } - object_property_add(cpu_obj, name, "bool", + object_property_add_qapi(cpu_obj, name, &bool_type_info, cpu_get_misa_ext_cfg, cpu_set_misa_ext_cfg, NULL, (void *)misa_cfg); @@ -1492,7 +1493,7 @@ static void riscv_cpu_add_profiles(Object *cpu_obj) for (int i = 0; riscv_profiles[i] != NULL; i++) { RISCVCPUProfile *profile = riscv_profiles[i]; - object_property_add(cpu_obj, profile->name, "bool", + object_property_add_qapi(cpu_obj, profile->name, &bool_type_info, cpu_get_profile, cpu_set_profile, NULL, (void *)profile); @@ -1568,10 +1569,10 @@ static void riscv_cpu_add_user_properties(Object *obj) for (edata = isa_edata_arr; edata && edata->name; edata++) { if (edata->prop_name) { - object_property_add(obj, edata->prop_name, "bool", - cpu_get_multi_ext_cfg, - cpu_set_multi_ext_cfg, - NULL, (void *)&edata->ext_enable_offset); + object_property_add_qapi(obj, edata->prop_name, &bool_type_info, + cpu_get_multi_ext_cfg, + cpu_set_multi_ext_cfg, + NULL, (void *)&edata->ext_enable_offset); } } diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c index c41d629d6803..72bf0f48de83 100644 --- a/target/s390x/cpu_models.c +++ b/target/s390x/cpu_models.c @@ -17,6 +17,7 @@ #include "system/kvm.h" #include "system/tcg.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/error-report.h" #include "qapi/visitor.h" #include "qemu/module.h" @@ -915,13 +916,13 @@ void s390_cpu_model_class_register_props(ObjectClass *oc) for (feat = 0; feat < S390_FEAT_MAX; feat++) { const S390FeatDef *def = s390_feat_def(feat); - object_class_property_add(oc, def->name, "bool", get_feature, + object_class_property_add_qapi(oc, def->name, &bool_type_info, get_feature, set_feature, NULL, (void *) feat); object_class_property_set_description(oc, def->name, def->desc); } for (group = 0; group < S390_FEAT_GROUP_MAX; group++) { const S390FeatGroupDef *def = s390_feat_group_def(group); - object_class_property_add(oc, def->name, "bool", get_feature_group, + object_class_property_add_qapi(oc, def->name, &bool_type_info, get_feature_group, set_feature_group, NULL, (void *) group); object_class_property_set_description(oc, def->name, def->desc); } diff --git a/tests/unit/test-qdev-global-props.c b/tests/unit/test-qdev-global-props.c index 8ea362cbb902..204436fb7276 100644 --- a/tests/unit/test-qdev-global-props.c +++ b/tests/unit/test-qdev-global-props.c @@ -27,6 +27,7 @@ #include "hw/core/qdev-properties.h" #include "qom/object.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" @@ -171,10 +172,12 @@ static void prop2_accessor(Object *obj, Visitor *v, const char *name, static void dynamic_instance_init(Object *obj) { - object_property_add(obj, "prop1", "uint32", prop1_accessor, prop1_accessor, - NULL, NULL); - object_property_add(obj, "prop2", "uint32", prop2_accessor, prop2_accessor, - NULL, NULL); + object_property_add_qapi(obj, "prop1", &uint32_type_info, + prop1_accessor, prop1_accessor, + NULL, NULL); + object_property_add_qapi(obj, "prop2", &uint32_type_info, + prop2_accessor, prop2_accessor, + NULL, NULL); } static void dynamic_class_init(ObjectClass *oc, const void *data) diff --git a/ui/console.c b/ui/console.c index a8a2a247d8f4..b4345b06d012 100644 --- a/ui/console.c +++ b/ui/console.c @@ -28,6 +28,7 @@ #include "ui/vgafont.h" #include "hw/core/qdev.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-commands-ui.h" #include "qapi/visitor.h" #include "qemu/coroutine.h" @@ -535,7 +536,7 @@ qemu_graphic_console_class_init(ObjectClass *oc, const void *data) offsetof(QemuGraphicConsole, device), object_property_allow_set_link, OBJ_PROP_LINK_STRONG); - object_class_property_add(oc, "head", "uint32", + object_class_property_add_qapi(oc, "head", &uint32_type_info, qemu_graphic_console_prop_get_head, NULL, NULL, NULL); diff --git a/util/thread-context.c b/util/thread-context.c index 88d8f0a55a4e..7fa6840dd401 100644 --- a/util/thread-context.c +++ b/util/thread-context.c @@ -13,6 +13,7 @@ #include "qemu/osdep.h" #include "qemu/thread-context.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-builtin-visit.h" #include "qapi/visitor.h" #include "qemu/config-file.h" @@ -278,13 +279,13 @@ static void thread_context_class_init(ObjectClass *oc, const void *data) UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc); ucc->complete = thread_context_instance_complete; - object_class_property_add(oc, "thread-id", "uint64", + object_class_property_add_qapi(oc, "thread-id", &uint64_type_info, thread_context_get_thread_id, NULL, NULL, NULL); - object_class_property_add(oc, "cpu-affinity", "[uint16]", + object_class_property_add_qapi(oc, "cpu-affinity", &uint16List_type_info, thread_context_get_cpu_affinity, thread_context_set_cpu_affinity, NULL, NULL); - object_class_property_add(oc, "node-affinity", "[uint16]", NULL, + object_class_property_add_qapi(oc, "node-affinity", &uint16List_type_info, NULL, thread_context_set_node_affinity, NULL, NULL); } -- 2.55.0.543.g5ebe2ebe4ea8 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 20:02:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 20:02:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409111.1641285 (Exim 4.92) (envelope-from ) id 1x2a7A-0007L1-Br; Fri, 04 Sep 2026 20:02:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409111.1641285; Fri, 04 Sep 2026 20:02:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2a7A-0007Ku-81; Fri, 04 Sep 2026 20:02:20 +0000 Received: by outflank-mailman (input) for mailman id 1409111; Fri, 04 Sep 2026 20:02:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2a78-0007Kk-Py for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 20:02:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2a78-00BBPW-6a for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 22:02:18 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b23c5-2eae-0a2a0a5409dd-0a2a4505c458-10 for ; Fri, 04 Sep 2026 22:02:17 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b23c8-4cb1-0a2a45050019-aa0a857c7047-3 for ; Fri, 04 Sep 2026 22:02:17 +0200 Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-416-IWU0nSy2PnWCVq_nvHCZLw-1; Fri, 04 Sep 2026 16:02:12 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 72E3218F0F0D; Fri, 4 Sep 2026 20:02:08 +0000 (UTC) Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3B8F030002F4; Fri, 4 Sep 2026 20:02:05 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788552136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uDadYbb+MvTukZ4DS18E0pLdpqsEG2v4jBcqkrYw0bM=; b=T4Ql7Mol8BUUMYul3AzIbQuKeZ3trrh8pLPg1/aOaTVRTd0btosLTuV4xR3uDtom9o4tkb SIQTjgs/o8XiiA5g8p7xCwCfh9I7uDvPQ6MxzDTBQG8YTVTjEvtNz6T4e5BGKdIZ+w0fi5 0+0/p9NYomrtYIqPDXKh9btcT9MN160= X-MC-Unique: IWU0nSy2PnWCVq_nvHCZLw-1 X-Mimecast-MFC-AGG-ID: IWU0nSy2PnWCVq_nvHCZLw_1788552129 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Fri, 04 Sep 2026 23:58:47 +0400 Subject: [PATCH v4 64/75] hw: convert device-local PropertyInfo definitions to use qapi_type MIME-Version: 1.0 Message-Id: <20260904-qom-qapi-v4-64-a985f168e938@redhat.com> References: <20260904-qom-qapi-v4-0-a985f168e938@redhat.com> In-Reply-To: <20260904-qom-qapi-v4-0-a985f168e938@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Michael Roth , Pierrick Bouvier , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Kevin Wolf , Hanna Reitz , Phil Dennis-Jordan , Alistair Francis , Peter Maydell , Keith Busch , Klaus Jensen , Jesper Devantier , "Michael S. Tsirkin" , Halil Pasic , Christian Borntraeger , Eric Farman , Farhan Ali , Matthew Rosato , Cornelia Huck , Richard Henderson , Ilya Leoshkevich , David Hildenbrand , Alex Williamson , =?utf-8?q?C=C3=A9dric_Le_Goater?= , xen-devel@lists.xenproject.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, qemu-s390x@nongnu.org X-Developer-Signature: v=1; a=openpgp-sha256; l=8761; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=JMD8CHS/Ms/ZN3B00kadMDC30ZNsy393OriqSCvH/Y0=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqmyLLxp67EFAkaEpd3WKP4FD56N94sNeVMF5/4 Rz0oJm8TwGJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCapsiywAKCRDa6OEJdZac 5a/GEACgM37bOE7xh8937jq4gCqcIYr3R0ftgwPqG7ZfxTrH+ADF5OrXrSWlGdaYE3vZmYWeWvE Ay0/GEkzLQ27Tkp0uGZqarxstlBi1Qb1hJ+VGeCoo2oy3QVC/VzvHGUzXFuu+q+KcpsJy/vz+rm TYQNst2H8aOh69l6a5pmW6xTvfVpZ2ulbkkSicOqDf2w8/l7+32aVxr4n9Rpbi3cHyYnmprQ09i Dq3YOy/Sx/x3O3G35/3vZf2ueHVsN9yfAfe5iNfh4qHntyNkf/jrIvNIgvC/r5hGOSs0Btsgx9j 0bKDAcQL74zjzWQbkFVk4XDTaLMaw7MP88VeJ3SnPj09/EdFYfNHyTbLUYCDVSE2xYBVwLcSgm+ g9Z2ceGQGLH6dT3w1VjsnN7l8lL1EUk00XNUYgxxjqCEH7KKWY1PuZlLXV5z18ZeE6w4odwBid+ jtiAa9vRzoSygzMEVCDwKTc1t/n4RbZnaZrlge/VpCUQG7LCZ2LHUrPCgz2wKOmoBAmJlQ9vOsJ 0QZDWpWRu+TIwt8JfVw8B7j+0dlFMTQAx2kwGMUr04qkhu1KtOAi44D57OZ9zc8MA5O3tqzURsZ bHoHzseTmlAcB55HF+5b6+ssWCHSFf3vTO+2iF3KxzqWoeD400QHZKULWt4JFKYWWlPQ0MoCoab 6nmkrZqZmEuUV3A== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: vdrKhz4BQZVMO8kr9NAbihcGroSXTo1hNP-nKldg_h4_1788552129 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1788552137-738BE2A1-17E957B4/0/0 X-purgate-type: clean X-purgate-size: 8763 Mechanical conversion of PropertyInfo definitions in device-specific files, replacing .type string with .qapi_type pointer to the corresponding QAPITypeInfo. Except "display_mode" for apple-gfx, which is a string of a specific format. Signed-off-by: Marc-André Lureau --- hw/block/xen-block.c | 3 ++- hw/display/apple-gfx.m | 3 ++- hw/misc/xlnx-versal-trng.c | 3 ++- hw/nvme/nguid.c | 3 ++- hw/nvram/xlnx-bbram.c | 3 ++- hw/nvram/xlnx-efuse.c | 3 ++- hw/pci/pci.c | 3 ++- hw/s390x/ccw-device.c | 3 ++- hw/s390x/css.c | 5 +++-- hw/s390x/s390-pci-bus.c | 3 ++- hw/vfio/pci-quirks.c | 3 ++- 11 files changed, 23 insertions(+), 12 deletions(-) diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c index 474c12fe4ac8..d9721c565c5f 100644 --- a/hw/block/xen-block.c +++ b/hw/block/xen-block.c @@ -29,6 +29,7 @@ #include "dataplane/xen-block.h" #include "hw/xen/interface/io/xs_wire.h" #include "trace.h" +#include "qapi/qapi-builtin-type-infos.h" #define XVDA_MAJOR 202 #define XVDQ_MAJOR (1 << 20) @@ -663,7 +664,7 @@ invalid: * https://xenbits.xen.org/docs/unstable/man/xen-vbd-interface.7.html */ static const PropertyInfo xen_block_prop_vdev = { - .type = "str", + .qapi_type = &str_type_info, .description = "Virtual Disk specifier (d*p*/xvd*/hd*/sd*)", .get = xen_block_get_vdev, .set = xen_block_set_vdev, diff --git a/hw/display/apple-gfx.m b/hw/display/apple-gfx.m index be0061b9db25..77c420b30006 100644 --- a/hw/display/apple-gfx.m +++ b/hw/display/apple-gfx.m @@ -15,6 +15,7 @@ #include "qemu/lockable.h" #include "qemu/cutils.h" #include "qemu/log.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qapi/error.h" #include "qemu/aio-wait.h" @@ -871,7 +872,7 @@ static void apple_gfx_set_display_mode(Object *obj, Visitor *v, } const PropertyInfo qdev_prop_apple_gfx_display_mode = { - .type = "display_mode", + .qapi_type = &str_type_info, .description = "Display mode in pixels and Hertz, as x@ " "Example: 3840x2160@60", diff --git a/hw/misc/xlnx-versal-trng.c b/hw/misc/xlnx-versal-trng.c index 0584ee089e3c..97bd3c3f8475 100644 --- a/hw/misc/xlnx-versal-trng.c +++ b/hw/misc/xlnx-versal-trng.c @@ -36,6 +36,7 @@ #include "qapi/visitor.h" #include "migration/vmstate.h" #include "hw/core/qdev-properties.h" +#include "qapi/qapi-builtin-type-infos.h" #ifndef XLNX_VERSAL_TRNG_ERR_DEBUG #define XLNX_VERSAL_TRNG_ERR_DEBUG 0 @@ -662,7 +663,7 @@ static void trng_prop_fault_event_get(Object *obj, Visitor *v, } static const PropertyInfo trng_prop_fault_events = { - .type = "uint32", + .qapi_type = &uint32_type_info, .description = "Set to trigger TRNG fault events", .set = trng_prop_fault_event_set, .get = trng_prop_fault_event_get, diff --git a/hw/nvme/nguid.c b/hw/nvme/nguid.c index 4cd6fad6ac9b..6eaf90fca88e 100644 --- a/hw/nvme/nguid.c +++ b/hw/nvme/nguid.c @@ -18,6 +18,7 @@ #include "qapi/visitor.h" #include "qemu/ctype.h" #include "nvme.h" +#include "qapi/qapi-builtin-type-infos.h" #define NGUID_SEPARATOR '-' @@ -179,7 +180,7 @@ static void set_nguid(Object *obj, Visitor *v, const char *name, void *opaque, } const PropertyInfo qdev_prop_nguid = { - .type = "str", + .qapi_type = &str_type_info, .description = "NGUID or \"" NGUID_VALUE_AUTO "\" for random value", .get = get_nguid, diff --git a/hw/nvram/xlnx-bbram.c b/hw/nvram/xlnx-bbram.c index e336874bdef4..eb032ab8b9c8 100644 --- a/hw/nvram/xlnx-bbram.c +++ b/hw/nvram/xlnx-bbram.c @@ -34,6 +34,7 @@ #include "hw/core/qdev-properties.h" #include "hw/core/qdev-properties-system.h" #include "hw/nvram/xlnx-efuse.h" +#include "qapi/qapi-builtin-type-infos.h" #ifndef XLNX_BBRAM_ERR_DEBUG #define XLNX_BBRAM_ERR_DEBUG 0 @@ -486,7 +487,7 @@ static void bbram_prop_release_drive(Object *obj, const char *name, } static const PropertyInfo bbram_prop_drive = { - .type = "str", + .qapi_type = &str_type_info, .description = "Node name or ID of a block device to use as BBRAM backend", .realized_set_allowed = true, .get = bbram_prop_get_drive, diff --git a/hw/nvram/xlnx-efuse.c b/hw/nvram/xlnx-efuse.c index 03c9fbc0d076..b1c9ee4980a0 100644 --- a/hw/nvram/xlnx-efuse.c +++ b/hw/nvram/xlnx-efuse.c @@ -34,6 +34,7 @@ #include "system/blockdev.h" #include "hw/core/qdev-properties.h" #include "hw/core/qdev-properties-system.h" +#include "qapi/qapi-builtin-type-infos.h" #define TBIT0_OFFSET 28 #define TBIT1_OFFSET 29 @@ -251,7 +252,7 @@ static void efuse_prop_release_drive(Object *obj, const char *name, } static const PropertyInfo efuse_prop_drive = { - .type = "str", + .qapi_type = &str_type_info, .description = "Node name or ID of a block device to use as eFUSE backend", .realized_set_allowed = true, .get = efuse_prop_get_drive, diff --git a/hw/pci/pci.c b/hw/pci/pci.c index af6e1d440c37..89a36221bc43 100644 --- a/hw/pci/pci.c +++ b/hw/pci/pci.c @@ -53,6 +53,7 @@ #include "qapi/error.h" #include "qemu/cutils.h" #include "pci-internal.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/xen/xen.h" #include "hw/i386/kvm/xen_evtchn.h" @@ -80,7 +81,7 @@ static void prop_pci_busnr_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_pci_busnr = { - .type = "uint8", + .qapi_type = &uint8_type_info, .get = prop_pci_busnr_get, }; diff --git a/hw/s390x/ccw-device.c b/hw/s390x/ccw-device.c index 25c427327957..fd21a4346522 100644 --- a/hw/s390x/ccw-device.c +++ b/hw/s390x/ccw-device.c @@ -17,6 +17,7 @@ #include "qapi/visitor.h" #include "qemu/ctype.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" static void ccw_device_refill_ids(CcwDevice *dev) { @@ -74,7 +75,7 @@ static void ccw_device_set_loadparm(Object *obj, Visitor *v, } const PropertyInfo ccw_loadparm = { - .type = "str", + .qapi_type = &str_type_info, .description = "Up to 8 chars in set of [A-Za-z0-9. ] to select" " a guest kernel", .get = ccw_device_get_loadparm, diff --git a/hw/s390x/css.c b/hw/s390x/css.c index 76dbca3bb961..60cba93e7eec 100644 --- a/hw/s390x/css.c +++ b/hw/s390x/css.c @@ -24,6 +24,7 @@ #include "hw/s390x/s390-virtio-ccw.h" #include "hw/s390x/s390-ccw.h" #include "exec/cpu-common.h" +#include "qapi/qapi-builtin-type-infos.h" typedef struct CrwContainer { CRW crw; @@ -2518,7 +2519,7 @@ out: } const PropertyInfo css_devid_propinfo = { - .type = "str", + .qapi_type = &str_type_info, .description = "Identifier of an I/O device in the channel " "subsystem, example: fe.1.23ab", .get = get_css_devid, @@ -2526,7 +2527,7 @@ const PropertyInfo css_devid_propinfo = { }; const PropertyInfo css_devid_ro_propinfo = { - .type = "str", + .qapi_type = &str_type_info, .description = "Read-only identifier of an I/O device in the channel " "subsystem, example: fe.1.23ab", .get = get_css_devid, diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c index eff980fdfe92..f77632810b76 100644 --- a/hw/s390x/s390-pci-bus.c +++ b/hw/s390x/s390-pci-bus.c @@ -33,6 +33,7 @@ #include "system/runstate.h" #include "trace.h" +#include "qapi/qapi-builtin-type-infos.h" S390pciState *s390_get_phb(void) { @@ -1541,7 +1542,7 @@ static void s390_pci_set_fid(Object *obj, Visitor *v, const char *name, } static const PropertyInfo s390_pci_fid_propinfo = { - .type = "uint32", + .qapi_type = &uint32_type_info, .description = "zpci_fid", .get = s390_pci_get_fid, .set = s390_pci_set_fid, diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c index c5b4f9091d49..4a3fd374a211 100644 --- a/hw/vfio/pci-quirks.c +++ b/hw/vfio/pci-quirks.c @@ -26,6 +26,7 @@ #include "pci.h" #include "pci-quirks.h" #include "trace.h" +#include "qapi/qapi-builtin-type-infos.h" /* * List of device ids/vendor ids for which to disable @@ -1436,7 +1437,7 @@ static void set_nv_gpudirect_clique_id(Object *obj, Visitor *v, } const PropertyInfo qdev_prop_nv_gpudirect_clique = { - .type = "uint8", + .qapi_type = &uint8_type_info, .description = "NVIDIA GPUDirect Clique ID (0 - 15)", .get = get_nv_gpudirect_clique_id, .set = set_nv_gpudirect_clique_id, -- 2.55.0.543.g5ebe2ebe4ea8 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 20:58:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 20:58:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409150.1641298 (Exim 4.92) (envelope-from ) id 1x2az3-0006Q3-8o; Fri, 04 Sep 2026 20:58:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409150.1641298; Fri, 04 Sep 2026 20:58:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2az3-0006Pw-5l; Fri, 04 Sep 2026 20:58:01 +0000 Received: by outflank-mailman (input) for mailman id 1409150; Fri, 04 Sep 2026 20:57:59 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2az1-0006Pp-Cg for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 20:57:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2ayz-002Wei-Vk for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 22:57:57 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b30cf-2eae-0a2a0a5409dd-0a2a450bea8a-2 for ; Fri, 04 Sep 2026 22:57:57 +0200 Received: from [178.154.239.136] (helo=forwardcorp1b.mail.yandex.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b30d4-b7e8-0a2a450b0019-b29aef88c08e-3 for ; Fri, 04 Sep 2026 22:57:56 +0200 Received: from mail-nwsmtp-smtp-corp-canary-81.sas.yp-c.yandex.net (mail-nwsmtp-smtp-corp-canary-81.sas.yp-c.yandex.net [IPv6:2a02:6b8:c11:43a8:0:640:574d:0]) by forwardcorp1b.mail.yandex.net (postfix) with ESMTPS id 08FC880A61; Fri, 04 Sep 2026 23:57:56 +0300 (MSK) Received: from i115954770.yandex-team.ru (unknown [2a02:6bf:8080:4d::1:17]) by mail-nwsmtp-smtp-corp-canary-81.sas.yp-c.yandex.net (smtpcorp) with ESMTPSA id rvQjs41YPqM0-UooXil1Y; Fri, 04 Sep 2026 23:57:55 +0300 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=default header.d=yandex-team.ru header.i="@yandex-team.ru" header.h="Message-ID:Date:In-Reply-To:Cc:Subject:References:To:From" X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1788555475; bh=Dlc3dK5WOaqmo7z+t9buAmX2gat8HcjIw965WO9A260=; h=Message-ID:Date:In-Reply-To:Cc:Subject:References:To:From; b=aFCJE6IQeVsZRJl6yv7vJPVyaDOeihMcE1i2xYJwRBLOy+OAqg25ttfEbdwewBfIl GFcGpErcsRrKygFyU1ZvDJfl76GdFJBqnwlEodNaMHoTtAOQGP8UYOH++P+1PVc6ZV vGgqWrgWzf0I5/gPfyq9LRJZN/4JewRXr29PMplM= Authentication-Results: mail-nwsmtp-smtp-corp-canary-81.sas.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Vladimir Sementsov-Ogievskiy To: pbonzini@redhat.com Cc: qemu-devel@nongnu.org, vsementsov@yandex-team.ru, Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , xen-devel@lists.xenproject.org (open list:X86 Xen CPUs) Subject: [PATCH 4/6] runstate: simplify qemu_shutdown_requested_get() Date: Fri, 4 Sep 2026 23:57:47 +0300 Message-ID: <20260904205749.510493-5-vsementsov@yandex-team.ru> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260904205749.510493-1-vsementsov@yandex-team.ru> References: <20260904205749.510493-1-vsementsov@yandex-team.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1788555477-18AC89EA-99E2A508/0/0 X-purgate-type: clean X-purgate-size: 1992 The only caller needs to know whether a shutdown request is pending, not its reason. Return bool and rename the function to qemu_shutdown_requested(). Signed-off-by: Vladimir Sementsov-Ogievskiy --- hw/xen/xen-hvm-common.c | 2 +- include/system/runstate.h | 2 +- system/runstate.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c index 62d88804c43..4d01a12062d 100644 --- a/hw/xen/xen-hvm-common.c +++ b/hw/xen/xen-hvm-common.c @@ -610,7 +610,7 @@ static void cpu_handle_ioreq(void *opaque) if (runstate_is_running()) { ShutdownCause request; - if (qemu_shutdown_requested_get()) { + if (qemu_shutdown_requested()) { destroy_hvm_domain(false); } request = qemu_reset_requested_get(); diff --git a/include/system/runstate.h b/include/system/runstate.h index 929379adae4..3ed35921bb7 100644 --- a/include/system/runstate.h +++ b/include/system/runstate.h @@ -146,7 +146,7 @@ void qemu_system_debug_request(void); void qemu_system_vmstop_request(RunState reason); void qemu_system_vmstop_request_prepare(void); bool qemu_vmstop_requested(RunState *r); -ShutdownCause qemu_shutdown_requested_get(void); +bool qemu_shutdown_requested(void); bool qemu_force_shutdown_requested(void); ShutdownCause qemu_reset_requested_get(void); void qemu_system_killed(int signal, pid_t pid); diff --git a/system/runstate.c b/system/runstate.c index 01f936649b4..2b28e2a30e2 100644 --- a/system/runstate.c +++ b/system/runstate.c @@ -582,7 +582,7 @@ static NotifierList shutdown_notifiers = NOTIFIER_LIST_INITIALIZER(shutdown_notifiers); static uint32_t wakeup_reason_mask = ~(1 << QEMU_WAKEUP_REASON_NONE); -ShutdownCause qemu_shutdown_requested_get(void) +bool qemu_shutdown_requested(void) { return shutdown_requested; } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 04 23:21:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 04 Sep 2026 23:21:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409213.1641307 (Exim 4.92) (envelope-from ) id 1x2dDK-0008I6-0s; Fri, 04 Sep 2026 23:20:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409213.1641307; Fri, 04 Sep 2026 23:20:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2dDJ-0008Hz-UT; Fri, 04 Sep 2026 23:20:53 +0000 Received: by outflank-mailman (input) for mailman id 1409213; Fri, 04 Sep 2026 23:20:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2dDH-0008Ht-O5 for xen-devel@lists.xenproject.org; Fri, 04 Sep 2026 23:20:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2dDG-007UC1-Vu for xen-devel@lists.xenproject.org; Sat, 05 Sep 2026 01:20:51 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9b51cb-e002-0a2a0a5209dd-0a2a4503c090-44 for ; Sat, 05 Sep 2026 01:20:50 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9b5252-fae8-0a2a45030019-b9ff1c22a72f-3 for ; Sat, 05 Sep 2026 01:20:50 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a06eb98619000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Sep 2026 23:20:47 +0000 Received: from [192.168.1.61] (155.223.66.37.rev.sfr.net [37.66.223.155]) (Authenticated sender: ngoc-tu.dinh@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 985F68426A; Sat, 5 Sep 2026 01:20:46 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=qbNpbvLUJ2ieNtUxtsOHK5WJXuN6EDp80qnBb6l3Ros=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=V64neSLTdDsF9XPMsevH7vZL9CX/Raw4zIy6wO+JDUuZGOZwilwFHmfQcHqAjt1g3iVrjuUpk k7HBnbIjQ5SgTrUOrMv5pspAwSr51wfcn10sGswcqJwEMOXIeJa621yANUKvgASJDQifOTd19CF /W7QtZ4RvjfBEMMf1Yil68856DbNKlUox1FVLmVqSCqWhkhzLdgkplFWTfaWhYyth0EBvepc3e6 m2X9I30yrWC/J3awsRa0HGbFYdZRPnwQTsxRr8Xaj3upnkW6zvg7s6bwGwDP9AEFb+JdgZt8J7j kTyft2Ia6kV2OXX+XLC0v6BsHG2Io9oVx95095LkzWwQ== X-Zone-Loop: bf943b14c1399985b111dea518b645298f6da775ab29 x-campaign-type: default x-transaction-id: 34e1525c-cc2e-408c-9574-e4d3f6a9e879 x-swg-uid: 01-f07115dd-bdcc-4019-8cdf-b056612b70bb X-Mailer: Sweego Message-ID: <1788564047.8631fc262581453bbf619ec5b2062170.1a06eb98619000c4f3@vates.tech> x-swg-bid: 1788564047.8631fc262581453bbf619ec5b2062170.1a06eb98619000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Sat, 5 Sep 2026 01:20:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] tools/libxl: Add support for Viridian stimer direct mode To: Ross Lagerwall , xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross References: <20260904141516.367862-1-ross.lagerwall@citrix.com> <20260904141516.367862-4-ross.lagerwall@citrix.com> Content-Language: en-US From: Tu Dinh In-Reply-To: <20260904141516.367862-4-ross.lagerwall@citrix.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.36fc.b1f8d9cd55c526b5.1a06eb98368.5d61744e6f8e51be=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788564046696 X-purgate-ID: tlsNG-33051d/1788564050-758824E9-240C9F5E/0/0 X-purgate-type: clean X-purgate-size: 3548 ---=Part.36fc.b1f8d9cd55c526b5.1a06eb98368.5d61744e6f8e51be=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/09/2026 16:17, Ross Lagerwall wrote: > Add support to libxl for using the stimer enlightenments in direct mode= =2E >=20 > Signed-off-by: Ross Lagerwall > --- >=20 > New in v2, since the new Viridian flag was added=2E >=20 > docs/man/xl=2Ecfg=2E5=2Epod=2Ein | 5 +++++ > tools/include/libxl=2Eh | 6 ++++++ > tools/libs/light/libxl_types=2Eidl | 1 + > tools/libs/light/libxl_x86=2Ec | 5 +++++ > 4 files changed, 17 insertions(+) >=20 > diff --git a/docs/man/xl=2Ecfg=2E5=2Epod=2Ein b/docs/man/xl=2Ecfg=2E5=2E= pod=2Ein > index d34951edb98d=2E=2E784e926c9990 100644 > --- a/docs/man/xl=2Ecfg=2E5=2Epod=2Ein > +++ b/docs/man/xl=2Ecfg=2E5=2Epod=2Ein > @@ -2496,6 +2496,11 @@ ticks and hence enabling this group will ensure t= hat ticks will be > consistent with use of an enlightened time source (B o= r > B)=2E > =20 > +=3Ditem B > + > +This set is the same as the B set but additionally supports > +using synthetic timers in direct mode=2E > + I think this should be stimer_direct=2E > =3Ditem B > =20 > This set incorporates use of a hypercall for interprocessor interrupts= =2E > diff --git a/tools/include/libxl=2Eh b/tools/include/libxl=2Eh > index 7c098edab663=2E=2E5475530a5002 100644 > --- a/tools/include/libxl=2Eh > +++ b/tools/include/libxl=2Eh > @@ -381,6 +381,12 @@ > */ > #define LIBXL_HAVE_VIRIDIAN_HCALL_IPI 1 > =20 > +/* > + * LIBXL_HAVE_VIRIDIAN_STIMER_DIRECT indicates that the 'stimer_direct'= value > + * is present in the viridian enlightenment enumeration=2E > + */ > +#define LIBXL_HAVE_VIRIDIAN_STIMER_DIRECT 1 > + > /* > * LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that > * libxl_domain_build_info has the u=2Ehvm=2Eacpi_laptop_slate field= =2E > diff --git a/tools/libs/light/libxl_types=2Eidl b/tools/libs/light/libxl= _types=2Eidl > index a7893460f013=2E=2E95075f04fe45 100644 > --- a/tools/libs/light/libxl_types=2Eidl > +++ b/tools/libs/light/libxl_types=2Eidl > @@ -260,6 +260,7 @@ libxl_viridian_enlightenment =3D Enumeration("viridi= an_enlightenment", [ > (10, "ex_processor_masks"), > (11, "no_vp_limit"), > (12, "cpu_hotplug"), > + (13, "stimer_direct"), > ]) > =20 > libxl_hdtype =3D Enumeration("hdtype", [ > diff --git a/tools/libs/light/libxl_x86=2Ec b/tools/libs/light/libxl_x86= =2Ec > index 60d4e8661c93=2E=2E9e8b48372d63 100644 > --- a/tools/libs/light/libxl_x86=2Ec > +++ b/tools/libs/light/libxl_x86=2Ec > @@ -389,6 +389,11 @@ static int hvm_set_viridian_features(libxl__gc *gc,= uint32_t domid, > if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMEN= T_CPU_HOTPLUG)) > mask |=3D HVMPV_cpu_hotplug; > =20 > + if (libxl_bitmap_test(&enlightenments, > + LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER_DIRECT)) > + mask |=3D HVMPV_time_ref_count | HVMPV_synic | HVMPV_stimer | > + HVMPV_stimer_direct; > + > if (mask !=3D 0 && > xc_hvm_param_set(CTX->xch, > domid, -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates = solutions web: https://vates=2Etech ---=Part.36fc.b1f8d9cd55c526b5.1a06eb98368.5d61744e6f8e51be=--- From xen-devel-bounces@lists.xenproject.org Sat Sep 05 07:25:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 Sep 2026 07:25:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409346.1641315 (Exim 4.92) (envelope-from ) id 1x2km5-0002PP-Tk; Sat, 05 Sep 2026 07:25:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409346.1641315; Sat, 05 Sep 2026 07:25:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2km5-0002PI-Qw; Sat, 05 Sep 2026 07:25:17 +0000 Received: by outflank-mailman (input) for mailman id 1409346; Sat, 05 Sep 2026 07:25:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x2km4-0002PC-Cx for xen-devel@lists.xenproject.org; Sat, 05 Sep 2026 07:25:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2km3-006zLp-J9 for xen-devel@lists.xenproject.org; Sat, 05 Sep 2026 09:25:15 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9bc3c5-8faa-0a2a0a5109dd-0a2a4507932e-4 for ; Sat, 05 Sep 2026 09:25:15 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9bc3db-b4ea-0a2a45070019-d155802bad17-3 for ; Sat, 05 Sep 2026 09:25:15 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49b0dd3c9a0so15859365e9.1 for ; Sat, 05 Sep 2026 00:25:15 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cee5f912esm215699955e9.4.2026.09.05.00.25.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Sep 2026 00:25:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788593115; x=1789197915; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=XtjlR+/HYPerpsAetYIT8+9GJJf3q+kJd7E3y9JB/is=; b=hLCm0+X3m/qgVjGvjYzUdjLsa5/6SaOQFTgf6xn9DQ6p8yLDmCO9qkMgRFbAyIm804 pQZDSzGGvSHb4hxM2gIzwH4rlrObLMUp4fMpGjce16FJDWXVExFrgGQgJdjAfsd8SiOi tZtgJM6pcrQboTxbT3DlcJtx6LUqoE3aN7TrwMnaYbhmf0r9dqMd9ZIFmbJnR7DWmeBc mKVKCJPuZJGOJU+2sEdNcNWsYliH9I6bhG7beEwvfQGe9ri5hImq98hA20LX17ftJ4jY cR7J158F5FIvMMyQkaP9WHBydawbJM+uHfZZtd5e9ubi7anDeZb91lxF/bUqWYyHsCTD xOZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788593115; x=1789197915; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=XtjlR+/HYPerpsAetYIT8+9GJJf3q+kJd7E3y9JB/is=; b=CDreJifHw6Sv42HKomUZE234v2r/csEFZtcwgd9Zs3rDPu9k+09LX9964bRh75cPtY uooV6HPiJG0vRRcxIA9Wf/usgzGtYqx4FX+Fs66Dt9/Y/uGj10qQt7CO/2AZl2RgPQK7 Y6P9sUdXFXSeiwb69yri5Jf7yBAe0ijWH26OS+ctV9BgXePH2ipePBcTGWreV32ZIGeV 0QJUxTjrPKz89UFBVc2UFMLmAFCJJNAHcf66wSfaXk3etjXtV5m8DemNu94x/XLZrArX vl53rHZBj4ZVgUeEwAYHYiBSZvEWaNAyzqlttr2XypvnTs2zqGcVChtQBTZL95ZsXKx1 mBoQ== X-Gm-Message-State: AFuF++nfKiJlMt9IhBOrrX7H9IeZBJj2Ri8GHit3f9wFIhMxs1NuvYaN uggcYPmdSNnHFHfrTgXjePXkeM7lJabw699FtKRjwgfXgv1k2/hWMzMvdAEu1w== X-Gm-Gg: AYBFou13nLKJNrF0gmxr3emrJHg4zsxAYcKDPjJOKA+fkw8TPqM1HBBCn+aOFthoC6D CwrXbwst3/2e2houmC797KbNyGOT9ET5S+chkf360TWdN2GukB33vTmxNLKtDU86gc1rJqW+2yf oDOe8HciWmKv9IzRhopjwGne5XX2ngMkOlBKUl+eIDHNxezJnYCtHNnH9s+u07x80SGue+h8k4T h72RDZNOLOHJ9i3CGnp9vcfzNkdNubyYOV4Cg0FVmjXfDDzW0soYqV7So/ga4azIML9StQOWB+n XY9HmbLKpxJ96aF7scbOnh2rnllJdNWLF6r/9a994YXgWHfRHU0su8UwL6j3beOx/almnSE/ohL l7pE0O0Nscs2J8oim5FGhhW+ZVUh0YgVuBJBAUPG7kx0TEgz3cuHkXCB1rENMMS7Q8Jl8ZCIAJt cQCeEXtZzpJEuZyp5IepzFvyBZl+FHDLm2uXPfpSUQUAgj8qrjc+6tBmshC6CiAPvOWAk5sFn2i FHKr2t0Qr2HaJ7dHNEnlv8JXWhdxchaBjWQY1E= X-Received: by 2002:a05:600c:a00a:b0:49c:ed94:cdd8 with SMTP id 5b1f17b1804b1-49cf81f6736mr198916385e9.6.1788593114809; Sat, 05 Sep 2026 00:25:14 -0700 (PDT) Message-ID: <9267476f-c6a0-4cfb-b128-10c475d2d5a6@gmail.com> Date: Sat, 5 Sep 2026 09:25:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788593115-A74D3AE4-0A5BEB25/10/73395122804 X-purgate-type: spam X-purgate-size: 7997 I've updated the part of handling of VMID for p2m during context switch as some things were still missed. This one implementation looks more correct to me. diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 0ad851ee0f5f..c05d6f8abaaa 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -404,16 +404,6 @@ static void ctxt_switch_to(struct vcpu *n) if ( is_idle_vcpu(n) ) return; - /* - * If this vCPU last ran on a different pCPU, invalidate its VMID so - * vmid_handle_vmenter() assigns a fresh one from the current pCPU's pool. - * Without this, two pCPUs could independently assign the same - * (generation, vmid) pair, generation counters start at the same value - * on all pCPUs and increment independently, causing TLB contamination. - */ - if ( n->arch.last_cpu != smp_processor_id() ) - vmid_flush_vcpu(n); - vtimer_ctxt_switch_to(n); restore_csr_regs(n); @@ -421,6 +411,15 @@ static void ctxt_switch_to(struct vcpu *n) p2m_ctxt_switch_to(n); } +/* + * Domain whose p2m this hart's HGATP points at. ctxt_switch_to() bails out + * early for the idle vCPU, so HGATP survives a pass through idle and keeps + * pointing at the domain which ran here last. That domain, rather than the + * one the scheduler switched away from, is what owns this hart's G-stage + * translations. + */ +static DEFINE_PER_CPU(struct domain *, hgatp_owner); + static void schedule_tail(struct vcpu *prev) { unsigned int cpu = smp_processor_id(); @@ -429,40 +428,88 @@ static void schedule_tail(struct vcpu *prev) ctxt_switch_from(prev); + write_atomic(&prev->dirty_cpu, VCPU_CPU_CLEAN); + /* - * Mark this CPU in next domain's dirty cpumasks before calling - * ctxt_switch_to(). This avoids a race on things like p2m flushing, - * which is synchronised on that function. + * Switching to the idle vCPU leaves HGATP alone, so this hart keeps both + * the G-stage translations of its owner and its place in that domain's + * dirty_cpumask: p2m_tlb_flush() goes on reaching it, and a domain which + * idles between two runs on the same hart keeps its VMIDs. */ - if ( prev->domain != current->domain ) + if ( !is_idle_vcpu(current) ) + { + struct domain *owner = this_cpu(hgatp_owner); + + if ( owner != current->domain ) + { + /* + * Once this hart drops out of the owner's dirty_cpumask it stops + * being a target of p2m_tlb_flush(), while its TLB may still hold + * G-stage translations of that domain: none of the vCPUs of that + * domain which ran here has had its VMID invalidated. Move the + * hart to a new VMID generation so that none of them can be + * reached again. + */ + if ( owner ) + { + vmid_flush_hart(); + + cpumask_clear_cpu(cpu, owner->dirty_cpumask); + } + + /* + * Mark this hart in the incoming domain's dirty_cpumask before + * ctxt_switch_to() points HGATP at its p2m. This avoids a race on + * things like p2m flushing, which is synchronised on that + * function. + */ + cpumask_set_cpu(cpu, current->domain->dirty_cpumask); + + /* + * Pairs with the barrier in p2m_tlb_flush(). cpumask_set_cpu() is + * an unordered AMO on RISC-V, so without this a concurrent flusher + * could read the mask without this hart in it while this hart is + * already walking the p2m it is about to be pointed at. + */ + smp_mb(); + + this_cpu(hgatp_owner) = current->domain; + } + } + + if ( !is_idle_vcpu(current) ) { - cpumask_set_cpu(cpu, current->domain->dirty_cpumask); + bool need_flush; + + /* + * A VMID is meaningful only on the hart whose pool issued it: + * generations are per-hart counters which all start at 1 and advance + * independently, so the pair a vCPU brings from another hart may match + * this hart's generation by coincidence, leaving the vCPU under a VMID + * which is live here for someone else. + */ + if ( current->arch.last_cpu != cpu ) + vmid_flush_vcpu(current); /* - * Once this hart drops out of prev's dirty_cpumask it stops being a - * target of p2m_tlb_flush(), while its TLB may still hold G-stage - * translations of prev's domain: neither the vCPU which just ran nor - * any other vCPU of that domain which ran here earlier has had its - * VMID invalidated. Move the hart to a new VMID generation so that - * none of them can be reached again. - * - * Switching away from the idle vCPU needs no bump: the idle domain - * has no p2m of its own, and whatever G-stage entries this hart may - * still hold (or speculatively create while HGATP keeps pointing at - * the last guest's p2m) are tagged with a VMID which was already made - * stale when that guest was switched out. Skipping the bump here also - * avoids burning a generation on every pass through idle. + * Claim the VMID here rather than leaving it to the next guest entry: + * ctxt_switch_to() makes HGATP live below, and a stale VMID there + * pairs this domain's G-stage root with a tag which may already have + * been re-issued to a vCPU of another domain. */ - if ( !is_idle_vcpu(prev) ) - vmid_flush_hart(); + need_flush = vmid_handle_vmenter(¤t->arch.vmid); - cpumask_clear_cpu(cpu, prev->domain->dirty_cpumask); + /* + * A VMID isn't re-used until the generation it was issued in wraps, so + * a G-stage flush is needed only when vmid_handle_vmenter() says so. + */ + if ( unlikely(need_flush) ) + local_hfence_gvma_all(); } - write_atomic(¤t->dirty_cpu, cpu); ctxt_switch_to(current); - write_atomic(&prev->dirty_cpu, VCPU_CPU_CLEAN); + write_atomic(¤t->dirty_cpu, cpu); current->arch.last_cpu = cpu; diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 1f7a6907525d..98c2d6de6933 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -243,6 +243,15 @@ static void p2m_tlb_flush(struct p2m_domain *p2m) p2m->need_flush = false; + /* + * Order the p2m updates above against the read of dirty_cpumask below, + * pairing with the barrier in schedule_tail(). Either that hart is seen + * here and gets an HFENCE.GVMA, or it adds itself to the mask afterwards, + * in which case it starts walking this p2m only once the updates are + * visible to it. + */ + smp_mb(); + sbi_remote_hfence_gvma(d->dirty_cpumask, 0, 0); } @@ -1523,22 +1532,12 @@ void p2m_ctxt_switch_from(struct vcpu *p) void p2m_ctxt_switch_to(struct vcpu *n) { struct p2m_domain *p2m = p2m_get_hostp2m(n->domain); - bool need_flush; if ( is_idle_vcpu(n) ) return; - need_flush = vmid_handle_vmenter(&n->arch.vmid); - csr_write(CSR_HGATP, construct_hgatp(p2m, n->arch.vmid.vmid)); - /* - * A VMID isn't re-used until the generation it was issued in wraps, so - * a G-stage flush is needed only when vmid_handle_vmenter() says so. - */ - if ( unlikely(need_flush) ) - local_hfence_gvma_all(); - csr_write(CSR_VSATP, n->arch.vsatp); /* Any concerns about this implementation? Thanks in advance. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Sat Sep 05 08:30:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 05 Sep 2026 08:30:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1409397.1641325 (Exim 4.92) (envelope-from ) id 1x2lmy-00051f-PY; Sat, 05 Sep 2026 08:30:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1409397.1641325; Sat, 05 Sep 2026 08:30:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2lmy-00051Y-MV; Sat, 05 Sep 2026 08:30:16 +0000 Received: by outflank-mailman (input) for mailman id 1409397; Sat, 05 Sep 2026 08:30:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x2lmx-00051S-0B for xen-devel@lists.xenproject.org; Sat, 05 Sep 2026 08:30:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x2lmw-009mgI-9T for xen-devel@lists.xenproject.org; Sat, 05 Sep 2026 10:30:14 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9bd300-2eae-0a2a0a5409dd-0a2a4503bae0-8 for ; Sat, 05 Sep 2026 10:30:13 +0200 Received: from [52.101.84.33] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9bd314-fae8-0a2a45030019-34655421e1f1-3 for ; Sat, 05 Sep 2026 10:30:12 +0200 Received: from CPAP307CA0004.DNKP307.PROD.OUTLOOK.COM (2603:10a6:380:3::17) by DU0PR08MB9846.eurprd08.prod.outlook.com (2603:10a6:10:445::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.4; Sat, 5 Sep 2026 08:30:09 +0000 Received: from CPH1EPF00000525.eurprd05.prod.outlook.com (2603:10a6:380:3:cafe::26) by CPAP307CA0004.outlook.office365.com (2603:10a6:380:3::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.11 via Frontend Transport; Sat, 5 Sep 2026 08:30:09 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by CPH1EPF00000525.mail.protection.outlook.com (10.167.241.136) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.5 via Frontend Transport; Sat, 5 Sep 2026 08:30:08 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by AMBPR08MB696964.eurprd08.prod.outlook.com (2603:10a6:20b:78a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.4; Sat, 5 Sep 2026 08:29:36 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%6]) with mapi id 15.21.0382.007; Sat, 5 Sep 2026 08:29:35 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=Adpk4JDD3GyIvGPFwyI3IT0UQocRD1sX2iOL8M+7qul/bciZHc9lKSoTHrGi5gbpPNkj8xuvRRQe9fPLk6m4vuViYeBf5trUKLYUprFLjprP4Zo/QV2dMfPDwFFvyicVBlipNIlPGQoi6eRLZHLE4zXnqw1pCh0MVyii7zSTztTAp4C2CBtxidJvXNNcTyf1+32wHfoN/NRKOVhYHYtyD8B18vvyCuWZpDYdI3lSy6Fn8oNQ0mKqCNPGLoZjF/UrYM0nSi1CU+T7mSoTNyME02eTgw2ECAFPe0NOVjGhIyioDocIfujiXyjsycCissRlVbfpdvdn2zJo/Pvn2ydVcQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=65NLJw5aZZ3lvys9uj52mrYTJnMsAcXdZ85K453K9hE=; b=XCIyMwUAFuslSbFiEvrTV69vqxj1+HKpwB1TMuyisDok41Pl1rnSlTBAiWPJnfavUrGA3ptKXBER+wwc/Wij73JPk5eXlbJs0TJXVSQJk69O1HIFSLbdKtU1OTDCZMuqEFzq70+jYW7qytN4n381tOSDNiDLq9cbHaLKOTU/CBJfI7VVNgAmntZM8neW2fRbgF/66aBpA3XGOyXtU5gOwh76sGdwBKsS5v8+uOaWA2DujUR9KxXHI0kLD672ENcWEF0pzOBGHOe6yjSYYbsFI7bsNWXYEW0UAq4Me2LO0Ql7izUkab7+VgaV4C1CHvC52xAOgZ58jHFdMABcCZnbTA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=65NLJw5aZZ3lvys9uj52mrYTJnMsAcXdZ85K453K9hE=; b=gl0KYGUxtV8X7CUfcZcOlYjXSbiz3hVmpGyJcOteS50AvHD1RpI2iyTAJiKLuoy0m7SkVv5SALnR2nffRWXRXQXz4Cv9jby3gOPP82b/3sGE7NSonMxo50rB6uQ4LLGjWuSoqNjqKzwT3i6bN1OtWCFsY/3dqA8joqJTwSl/F3Q= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KkqmtKHxe5OeVY+ZZthKZoAljRwf6Xal7LWN0Q4LhNOr1oTnUNCq7EspVe8P0Iqh31pA0NbfEd4xnnw4qeEYxYUL8j6PRn90lim9/Cv4NJS5GM9A9R7ZJoaySsNPvILDAqSf5PEiZcNzQKFT7bitSGj81xy7KqbX+uSxJpeKqDgCsaWjk/J/FW82kla9kEio6Tyik878nKGZluOPV6+LcuxH5pv+JCaJnwXJIAKgtscZmC0O9lHuibsIrrmzcbM9W0QRKp0r2+V1jbeDzuBTlHV0lVYWFbXqYjoq1RPX7MVBMNvqTRYNmkT+ZHy1lSaDingQHL3nUJZc8z8KPw7HrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=65NLJw5aZZ3lvys9uj52mrYTJnMsAcXdZ85K453K9hE=; b=gRKFqYc5QcHo+g9QCKePp5CLx33RGqq608jY93SEnahbCpiNKDGraBRK5VT+Yc68vrgbjUYC7iPKzBv5JtGVBBPXjuSLoQX9ptDTowfZC8XAFOGU/0BhZ1OnP6MUdF2SLoDuxzRekvrde1UVpGhDMoMLLB79ZnxrY51SAZKx3nhOMSo5ApQHPzl9eeUqVPoRa4wsKLaWwihTIAO+L7WNIYeG9swlGgkz6TFr7BiofqtFETy8GGwcGi5zSicOMgdlJXrmyj5AvPh+cCRPCDzizWeaUMaSyh8HfjKZb4V8hdRc0O2WJxp2/I5ICcOg6LwPq3MrvOM2pOCZPXSGg4Qx9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=65NLJw5aZZ3lvys9uj52mrYTJnMsAcXdZ85K453K9hE=; b=gl0KYGUxtV8X7CUfcZcOlYjXSbiz3hVmpGyJcOteS50AvHD1RpI2iyTAJiKLuoy0m7SkVv5SALnR2nffRWXRXQXz4Cv9jby3gOPP82b/3sGE7NSonMxo50rB6uQ4LLGjWuSoqNjqKzwT3i6bN1OtWCFsY/3dqA8joqJTwSl/F3Q= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Michal Orzel , Jan Setje-Eilers Subject: Re: [PATCH v2 5/5] xen/arm: Rewrite arm_smccc_*() to return by value Thread-Topic: [PATCH v2 5/5] xen/arm: Rewrite arm_smccc_*() to return by value Thread-Index: AQHdPF5PySaNy6Ey5EKldcmUqkyt+ba+VLAAgABmmwCAAO1IAA== Date: Sat, 5 Sep 2026 08:29:35 +0000 Message-ID: <8D81C513-CCA2-445B-830C-A8825E3D818C@arm.com> References: <20260904111228.3022634-1-andrew.cooper3@citrix.com> <20260904111228.3022634-6-andrew.cooper3@citrix.com> <9301544B-8F8D-4E27-9BFA-B7244633B41F@arm.com> <1dbfedb4-d3a3-4d11-9b24-dea509c38dad@citrix.com> In-Reply-To: <1dbfedb4-d3a3-4d11-9b24-dea509c38dad@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|AMBPR08MB696964:EE_|CPH1EPF00000525:EE_|DU0PR08MB9846:EE_ X-MS-Office365-Filtering-Correlation-Id: dbe242b8-c9c7-4ce6-cbf4-08df0b27e529 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|10067099003|11063799006|4143699003|56012099006|18002099003|3023799007|22082099003|38070700021; X-Microsoft-Antispam-Message-Info-Original: hG0bzLvVTWjhaM+PaHYZEzdcqbZkpHua18R5ipkVdSJQ4sko3AqNM+6Te4T4lWGQrOwyEmE06egXK5vL30msO9TLELhSFTe91803Yim4Sdu2sQwMc0NHSsm3arOq6mCYFFiKT1X0fitD4ox/JsNwmDzTNFCAJD5qgXOmFvRiTRmF8RFBrCzYWzc5DxR4EEr+fmRGXmquv2M+qGjCYy/A2vaZbxqYTele0W0FVg3EuCj6ztKtGmqKQsZjEu3EJN+Phb4cijS9uQzqJULF/ruDfOXLhvbEOqbYVEkHYeypmndDXYbIGMuuqBdkcLncL4p9tQg/efqC2VrY5UlLyloJkel3B0QrThUS8AuCSz1ESje4ELUDuLr/rnEy3rCiw99FNMqdN3GgmQyaRWygDCTntAezPH3SSMc52wnvWGuN4ctfoo8UUWcr5uqAN2uYGb+2vvC/sRTo+Fag2NRsXAzDPnGRzfrmZ8Fx/kUkViTQ8wrj7SDXxhcELu33f29PM3GbHWfduE05zBAqdyC/dCWEyreMJPTy/0oovp1BgJ/NtHtTQ2SEAGVVk65Z8gQDS0bqZDPS51DGgFebd8XzI1l7tHvOKwsRPNeeJxRUhbnnYvVJ6BrsoWO0XFjXIUoo+o66ERtseePINy+gm9i2I9932V4oenJyL87u7a3jqBfWy0gfm5lNwKnvMN3Y4jbtG2B1ZbQE3b8YRodpBiVc4wTlbgEX+fYyQzicknOuqVtaFYQ= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(10067099003)(11063799006)(4143699003)(56012099006)(18002099003)(3023799007)(22082099003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <804F10032889A9478F9F9AF21D9050DA@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: UXULFL+kgMAw+nDdwjEUh/7d6ZpC+wIg8Il2tv6BYpx/yFQL2hxqqz4XjXjY44LWQoD7i6G6vJZnqVNUFHhoV6Kh9BjYGXHp8xsL+Gb/OJnHQh5mzAsJ65sGZcJzklIPFJ9dzDzpKpRpw3wFbcqE9jA1naceOuE/L77qAROtlahHdZ6p5m2Rk8+EWFw9vntEmcNhrlar5WpFUwc/nCgPeSexvoXv6gRmEuCNsrR/hXguX68FIx5528sdl0b7Z8F47wiQyN262TFxOB0V3PAKio0FdFiJZspR3KBEna/UFRpCl7nuOb4i64Tvby/6xw7sI+yQB+ZUA2o2J36/IXgjlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMBPR08MB696964 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: CPH1EPF00000525.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: a90a0d00-9ef1-40aa-d68d-08df0b27d152 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|35042699022|14060799003|23010399003|82310400026|36860700016|376014|10067099003|4143699003|11063799006|56012099006|18002099003|3023799007|22082099003; X-Microsoft-Antispam-Message-Info: FwGv3e2teHAQ07xeg424B6KTQ9y+b5MI5VLDaE2FqzSAJaNAC6Br/MZAC3/sAR2pdl0xCf7RpoLzQxG8i1X5NzLPsE26M5BjiOFa7P0eHw+UJ+oIRrl4pz7fdKGFBAtCwuHnIdy31TJO2w+FweManaXofBAOTVmF9AQK3K22TjFngieq6ukHSizrh4O4MNv7qMBGaBw9kk42NsRFeMFR6s/Ut9q6VvQ8gznKbU0+1sZu8vkpH2tvNiNSqaZ1OStZU8/4mqy4csEjLoP7Znm0Duh4N8rWtqNfEUlmjLS0eLK60nsc1+1l+3O8LMpSMwoCXSF5xGocoOfWx2VSKFVhhUQxiS4aa1sAZ1kJWTY0iy1Zoz6d+l9D19MCOyIAw1BmnrWA/VlCzFlQuVakf/mjfMTPh3/ai8Kal4p3Ms5kQ5ukefk/fUBJoPAAFHB21j/Jie9SIB8cbVCeFG/8pwfuixkMkphWhk442HwZz7iea9mMwrl/3eZPnHhduGimj6vb5tQvHM+XamG9jNCdF9pscH0p9SscjPaN7m8rlNcjZ+ybO6/bZdA0VITV1HetlkzcENfezASraHO9KKXAbD3oyIEE5yum1dAT2m5v7T/lZTa38Mt9VJwd0AKtuqng+TymDrQpErEq9eohEPsyTrLSXjHawCvaF7JbrZYS3dZ/3rw= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(35042699022)(14060799003)(23010399003)(82310400026)(36860700016)(376014)(10067099003)(4143699003)(11063799006)(56012099006)(18002099003)(3023799007)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 4HrsRyTmiJ6T1rrfY3KSQ+9OPUI/PL6m7MloI5fohZ3iuCU1G9UC+G1bjPzz52Au4WXqIeLFu2XXezu6qEltups61rYEn/pbBqKHN2RzSfo6CYJQ5OFUzC1qVxzoioIHUqPXohfJYBHn9IV5jnisegGf6o6GItKje8kfVnVDUMd58981/w/HJKvobqpLUuxM4PqRt6MdPY3PlfhDUuHCqANilf4Pt0DYgRp75v8POjIlmssRBaDBbvDNFCNQcYcxOe33YFaAE0pJNB2VvGvVckIATaVe6V4hlJNdy47wqn+OnKRwPxaLvkPZl3hDfVgJRLHdo977ZBLdFKUpPrXBuWp2Zm9TmcwpczOplz0y1Gck2CCjzfEQ9kr7wmvhupP8GPfIXQEp/DfpMln1TnoG7vkZcIjJM796nCjD6i8HOloBjSMMyAapH2Jyc7u6ovdF X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2026 08:30:08.4862 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dbe242b8-c9c7-4ce6-cbf4-08df0b27e529 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: CPH1EPF00000525.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9846 X-purgate-ID: tlsNG-33051d/1788597013-6F0C94E9-D6AEF782/0/0 X-purgate-type: clean X-purgate-size: 2824 Hi Andrew, > On 4 Sep 2026, at 20:20, Andrew Cooper wrote: >=20 > On 04/09/2026 1:13 pm, Bertrand Marquis wrote: >> Hi Andrew, >>=20 >>> On 4 Sep 2026, at 13:12, Andrew Cooper wrot= e: >>>=20 >>> diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/as= m/smccc.h >>> index 4ed2a40ed0ac..2d0f2db0b256 100644 >>> --- a/xen/arch/arm/include/asm/smccc.h >>> +++ b/xen/arch/arm/include/asm/smccc.h >>> @@ -181,21 +174,20 @@ struct arm_smccc_res { >>> * makes it stick. >>> */ >>> #define arm_smccc_1_1_smc(...) \ >> The comment would need fixing on top of this as current >> one still describes the optional @res argument while now=20 >> we only take a0 to a7 as arguments and return the structure=20 >> instead. >=20 > Are you happy with this delta? >=20 > diff --git a/xen/arch/arm/include/asm/smccc.h > b/xen/arch/arm/include/asm/smccc.h > index 2d0f2db0b256..c7763acd7f7d 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -159,15 +159,14 @@ struct arm_smccc_res { > * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call > * > * This is a variadic macro taking one to eight source arguments, and > - * an optional return structure. > + * returns four values. > * > * @a0-a7: arguments passed in registers 0 to 7 > * @res: result values from registers 0 to 3 > * > * This macro is used to make SMC calls following SMC Calling > Convention v1.1. > * The content of the supplied param are copied to registers 0 to 7 prio= r > - * to the SMC instruction. The return values are updated with the conten= t > - * from register 0 to 3 on return from the SMC instruction if not NULL. > + * to the SMC instruction. > * > * We have an output list that is not necessarily used, and GCC feels > * entitled to optimise the whole sequence away. "volatile" is what >=20 > The overall comment now reads: >=20 > /* > * arm_smccc_1_1_smc() - make an SMCCC v1.1 compliant SMC call > * > * This is a variadic macro taking one to eight source arguments, and > * returns four values. > * > * @a0-a7: arguments passed in registers 0 to 7 > * @res: result values from registers 0 to 3 > * > * This macro is used to make SMC calls following SMC Calling Convention > v1.1. > * The content of the supplied param are copied to registers 0 to 7 prior > * to the SMC instruction. > * > * We have an output list that is not necessarily used, and GCC feels > * entitled to optimise the whole sequence away. "volatile" is what > * makes it stick. > */ Looks good to me. With that: Reviewed-by: Bertrand Marquis Cheers Bertrand >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Sun Sep 06 13:16:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 Sep 2026 13:16:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410225.1641334 (Exim 4.92) (envelope-from ) id 1x3CjF-0001PJ-Vz; Sun, 06 Sep 2026 13:16:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410225.1641334; Sun, 06 Sep 2026 13:16:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3CjF-0001PB-Qr; Sun, 06 Sep 2026 13:16:13 +0000 Received: by outflank-mailman (input) for mailman id 1410225; Sun, 06 Sep 2026 13:16:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3CjD-0001P4-N6 for xen-devel@lists.xenproject.org; Sun, 06 Sep 2026 13:16:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3CjC-00F3Xd-Ev for xen-devel@lists.xenproject.org; Sun, 06 Sep 2026 15:16:10 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9d6767-2eae-0a2a0a5409dd-0a2a4508978a-38 for ; Sun, 06 Sep 2026 15:16:10 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9d6799-f659-0a2a45080019-a0658309c3dc-3 for ; Sun, 06 Sep 2026 15:16:10 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id 7AEFC8356EA8; Sun, 6 Sep 2026 09:14:04 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Abdelkareem Abdelsaamad To: xen-devel@lists.xenproject.org, jbeulich@suse.com Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: Re: [PATCH v4] x86/nSVM: Check injected event consistency Date: Sun, 6 Sep 2026 14:11:14 +0100 Message-ID: <20260906131117.3121334-1-abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788700570-CE94287B-B2387E36/0/0 X-purgate-type: clean X-purgate-size: 9373 On 26.08.2026 15:33, Jan Beulich wrote: >On 23.08.2026 18:11, Abdelkareem Abdelsaamad wrote: >> On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has >> debugging complications, security and performance implications. The APM >> volume #2 15.20 (40332-Rev. 4.10-July 2026) states the two possibilities that >> result in a VMRUN exit with VMEXIT_INVALID due to the injected event. These are >> • Reserved values of TYPE have been specified. >> • TYPE = 3 (exception) has been specified with a vector that does not >> correspond to an exception (this includes vector 2, which is an NMI, not >> an exception). >> >> Extend the VMCB validation to check for such inconsistency. >> >> The collection of the invalid exception vectors are ported from the upstream >> KVM commit >> ("7e79f71bca5c" KVM: nSVM: Add missing consistency check for EVENTINJ). Adjust >> the checks from the commit to align with the APM Volume #2 and Volume #3 >> (40332—Rev. 4.10—July 2026) for the X86_EXC_OF and X86_EXC_BR vectors which >> should not be valid on the x86 64-bit (long mode) platforms. The adjustment is >> posted to the KVM mailing commit patch thread >> https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/ >> >> Injecting the vector X86_EXC_HV is also found to trigger VMEXIT_INVALID with >> the Xen hypervisor. Drop the X86_EXC_HV vector from the permitted vectors. > >Is this matched by anything in the PM? There is "#HV is only allowed to be >injected into VMSAs that execute with Restricted Injection." Which suggests >#HV can be injected, but only under a certain condition. Following what >Teddy said towards v3, this may want expressing by a separate case block >also returning false, but having a comment. I will put it separately with a comment in v5. Regarding the APM question: the manual does not appear to fully document generation-specific or microarchitecture-dependent constraints for all the vectors. Some vectors are only valid starting with the specific CPU generation that introduced the corresponding feature. To verify the hardware behavior, I am performing case-by-case testing on 64-bit Windows guests. I inject the various events at the end of svm_vmexit_handler and see the result: - If it triggers VMEXIT_INVALID, the injection is invalid. - If it triggers a triple fault, the event passed the hardware checks and completed the event delivery. It is valid. I am testing this across a Naples (older) and a Genoa (modern) platform. For the X86_EXC_HV, I am consistently getting VMEXIT_INVALID. I will update the code comments in v5 with the testing matrix used and the findings. > >> --- a/xen/arch/x86/hvm/svm/vmcb.c >> +++ b/xen/arch/x86/hvm/svm/vmcb.c >> @@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) >> svm_dump_sel(" TR", &vmcb->tr); >> } >> >> +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, >> + uint8_t vmcb_injected_vector) >> +{ >> + switch ( vmcb_injected_vector ) >> + { >> + case X86_EXC_DE: >> + case X86_EXC_DB: >> + case X86_EXC_BP: >> + case X86_EXC_UD: >> + case X86_EXC_NM: >> + case X86_EXC_DF: >> + case X86_EXC_TS: >> + case X86_EXC_NP: >> + case X86_EXC_SS: >> + case X86_EXC_GP: >> + case X86_EXC_PF: >> + case X86_EXC_MF: >> + case X86_EXC_AC: >> + case X86_EXC_MC: > >Is #MC valid to inject without CR4.MCE set? The testing I performed (see previous comment) does not show that set CR4.MCE is required for the valid injection. >> + case X86_EXC_XM: > >As before: Doesn't #XM (AMD: #XF) require CR4.OSXMMEXCPT to be set? The testing I performed (see previous comment) does not show that set CR4.MCE is required for the valid injection. >> + case X86_EXC_SX: > >Again as before: Is #SX really permitted without any constraints? You did >reply to both comments on v3, but that outcome isn't reflected here. The >more that what you said there could equally apply ... The testing I performed (see the first comment) does not show that set CR4.MCE is required for the valid injection. > >> + return true; >> + >> + case X86_EXC_OF: >> + case X86_EXC_BR: >> + return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l; >> + >> + case X86_EXC_VC: >> + return vmcb_get_sev_es(vmcb); >> + >> + case X86_EXC_CP: >> + return vmcb_get_cr4(vmcb) & X86_CR4_CET; > >... e.g. here. That is, if a CR4 (or other) check is needed here, but not >for #XM (or #SX), that's surely worth (briefly) commenting upon. The more >that, afaics, none of this is spelled out in the PM. In my testing, the hardware behavior differs across the generations support for the Control-flow Enforcement Technology (CET): - Naples (No hardware support): Injecting the event when the feature is completely unsupported by the CPU results in VMEXIT_INVALID. The VMCB's CR4 bit is not set as it is expected. - Genoa (Hardware support exists): If the CPU supports the feature but the guest has not enabled it in CR4 (not opted-in), injecting the event results in a triple fault. I am accordingly checking for the CPU feature and report it as invalid. > >> @@ -330,6 +368,12 @@ bool svm_vmcb_isvalid( >> unsigned long cr4 = vmcb_get_cr4(vmcb); >> unsigned long valid; >> uint64_t efer = vmcb_get_efer(vmcb); >> + uint8_t vmcb_injected_type = vmcb->event_inj.type; >> + uint8_t vmcb_injected_vector = vmcb->event_inj.vector; >> + uint8_t vmcb_valid_event_inj_types_mask = (1 << X86_ET_EXT_INTR) | >> + (1 << X86_ET_NMI) | >> + (1 << X86_ET_HW_EXC) | >> + (1 << X86_ET_SW_INT); > >The absence of X86_ET{_PRIV,}_SW_EXC likely wants a brief comment, as that's >a peculiarity of SVM. Alternatively how about introducing X86_ET_SVM_ALL (or >some such) as a #define somewhere? I thought the mask varibale name is sufficient? I am also fine with the #define but it will be a one time usage. What is your suggestion? >> @@ -392,6 +436,20 @@ bool svm_vmcb_isvalid( >> PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n", >> vmcb->event_inj.raw); >> >> + if ( !vmcb->event_inj.v ) >> + PRINTF("eventinj: valid bit is not set (%#"PRIx64")\n", >> + vmcb->event_inj.raw); > >I understand the parentheses in the log message here. Yet ... > >> + if ( !((1 << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) ) > >If vmcb_injected_type really could take all possible uint8_t values (see >below), this shift would be at risk of becoming UB. And uint8_t is a >stronger hint that all possible values may appear than unsigned int is. I am OK to change to unsigned int for safety with future possible extensions. > >> + PRINTF("eventinj: Invalid Injected Event Type: (%#"PRIx8")\n", >> + vmcb_injected_type); > >... what purpose do they serve here (and below)? I did it just to go with the previous format but I am OK to drop in v5. > >As to the use of PRIx8: Imo that's unnecessary to use. We assume >sizeof(int) >= 4, and every type smaller than that will be promoted to >int. Just %#x will hence do here (and below), improving readability. >Furthermore, the use of fixed-width types here is in conflict with >./CODING_STYLE anyway. I'm willing to accept it for variables holding >vector numbers (albeit longer term they will apparently need to widen >anyway), but the other two should be unsigned int. I will change to %#x and I will change the other two variables to unsigned int. > + if ( (vmcb_injected_type == X86_ET_HW_EXC) && > + !is_valid_injected_exception_vector(vmcb, vmcb_injected_vector) ) > + PRINTF("eventinj: Invalid exception type: (%#"PRIx8") vector: " > + "(%#"PRIx8") for the platform\n", > >Does "for the platform" really add any value? With it dropped, the >whole format string could also go on a single line (which we generally >prefer). My point was to give an expressive hint as the injection combination can be invalid on one platform/mode but valid on another (for example, #BR injection triggers VMEXIT_INVALID in 64-bit long mode but is allowed in 32-bit mode). The CPU generation also matter as outlined before. > >One more check would likely be worthwhile doing: We have X86_EXC_HAVE_EC, >and vmcb->event_inj.ev could also do with checking. I will test this and add the check in v5 in the case it is needed. > >Finally a more general comment: svm_vmcb_isvalid() is used solely out of >nestedsvm.c. I hence think it would better move there, and such moving >would better come ahead of adding more code (which would then also need >moving). This is a point that needs to reach a consensus between you and Teddy. In the v3 review, Teddy commented to expand the use of svm_vmcb_isvalid() by calling it within svm_vmexit_handler() when exit_reason == VMEXIT_INVALID. If I follow Teddy's suggestion, the function needs to stay in a shared location. Otherwise, the function will be kept, as is, strictly for nested SVM usage and moving it >Jan From xen-devel-bounces@lists.xenproject.org Sun Sep 06 13:37:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 Sep 2026 13:37:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410267.1641343 (Exim 4.92) (envelope-from ) id 1x3D3M-0004gZ-H3; Sun, 06 Sep 2026 13:37:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410267.1641343; Sun, 06 Sep 2026 13:37:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3D3M-0004gR-Dj; Sun, 06 Sep 2026 13:37:00 +0000 Received: by outflank-mailman (input) for mailman id 1410267; Sun, 06 Sep 2026 13:37:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3D3M-0004gL-0v for xen-devel@lists.xenproject.org; Sun, 06 Sep 2026 13:37:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3D3L-006VLh-DC for xen-devel@lists.xenproject.org; Sun, 06 Sep 2026 15:36:59 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9d6c1e-2eae-0a2a0a5409dd-0a2a4501dae8-32 for ; Sun, 06 Sep 2026 15:36:59 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9d6a5d-5984-0a2a45010019-a0658309caa2-3 for ; Sun, 06 Sep 2026 15:27:58 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id 858D183FBC99; Sun, 6 Sep 2026 09:25:52 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Abdelkareem Abdelsaamad To: xen-devel@lists.xenproject.org, jbeulich@suse.com Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: Re: Re: [PATCH v4] x86/nSVM: Check injected event consistency Date: Sun, 6 Sep 2026 14:22:48 +0100 Message-ID: <20260906132248.3121411-1-abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260906131117.3121334-1-abdelkareem.abdelsaamad@citrix.com> References: <20260906131117.3121334-1-abdelkareem.abdelsaamad@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788701278-1D272757-18EA1D61/13/0 X-purgate-type: clean X-purgate-size: 1560 >>> @@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) >>> svm_dump_sel(" TR", &vmcb->tr); >>> } >>> >>> +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, >>> + uint8_t vmcb_injected_vector) >>> +{ >>> + switch ( vmcb_injected_vector ) >>> + { >>> + case X86_EXC_DE: >>> + case X86_EXC_DB: >>> + case X86_EXC_BP: >>> + case X86_EXC_UD: >>> + case X86_EXC_NM: >>> + case X86_EXC_DF: >>> + case X86_EXC_TS: >>> + case X86_EXC_NP: >>> + case X86_EXC_SS: >>> + case X86_EXC_GP: >>> + case X86_EXC_PF: >>> + case X86_EXC_MF: >>> + case X86_EXC_AC: >>> + case X86_EXC_MC: >> >>Is #MC valid to inject without CR4.MCE set? >The testing I performed (see previous comment) does not show that set CR4.MCE >is required for the valid injection. >>> + case X86_EXC_XM: >> >>As before: Doesn't #XM (AMD: #XF) require CR4.OSXMMEXCPT to be set? >The testing I performed (see previous comment) does not show that set CR4.MCE >is required for the valid injection. I meant ..does not show that set CR4.OSXMMEXCPT is required. >> >>Again as before: Is #SX really permitted without any constraints? You did >>reply to both comments on v3, but that outcome isn't reflected here. The >>more that what you said there could equally apply ... >The testing I performed (see the first comment) does not show that set CR4.MCE >is required for the valid injection. I meant ..does not show that any CR4 bit is required. From xen-devel-bounces@lists.xenproject.org Sun Sep 06 17:02:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 Sep 2026 17:02:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410427.1641352 (Exim 4.92) (envelope-from ) id 1x3GFa-0007am-2E; Sun, 06 Sep 2026 17:01:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410427.1641352; Sun, 06 Sep 2026 17:01:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3GFZ-0007ae-UH; Sun, 06 Sep 2026 17:01:49 +0000 Received: by outflank-mailman (input) for mailman id 1410427; Sun, 06 Sep 2026 17:01:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3GFY-0007aY-0P for xen-devel@lists.xenproject.org; Sun, 06 Sep 2026 17:01:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3GFX-00GQhM-7S for xen-devel@lists.xenproject.org; Sun, 06 Sep 2026 19:01:47 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9d9c6e-e002-0a2a0a5209dd-0a2a450cc8a0-6 for ; Sun, 06 Sep 2026 19:01:47 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9d9c7a-f479-0a2a450c0019-416d716cd4c8-3 for ; Sun, 06 Sep 2026 19:01:47 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 0FFDD40E01E1; Sun, 6 Sep 2026 17:01:46 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OAwfk7M4z7hs; Sun, 6 Sep 2026 17:01:36 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1FD6A40E00B9; Sun, 6 Sep 2026 17:01:19 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1788714094; bh=51b2uIj3sChLBhb35/VVuLepNdtIGJ1sMqXdDiS37Is=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=S0nd3Ts689qj7P6JKRDKgJwW5mYJkSTZowCBIaltEgk3wibuedZir76K0Tnqhms+s 8In1rBmBQ3Z68uuT7c9k8u1jWTtS3cfSMXjf+UAgLJ9l6uoqVgXgJMaV6u/Sd60/Kf Ow4SW6rWyNymNIrO4OfEbsWTTw3APvpEYqBCUJ9Mn8oqarh91Rlqy7RP1tVLqp4PeP ubRSeyzmvJh6KerZNcYVdtrJd6SuhoP/1knyHPfNpCAB7jkyAI0v6yIy6tiEFiZ7cw BXCm0kKXXZLj4U1zZ22gmeU0+Xr5yHLYEpLYpXUHsPredmfxvTIPM20m+wyH0r8pUW ZuKsdJHDV2yG0TcCwBAw8bhyzpzmr70pVSn2dq4zIQHq6DzA90wiWuO49rjAwVjl+J Uy5a+meD0joxhmnmogwcQXedt3MEMpD7FtKjMzcOgwfzusZr5W0ok+lduv5JAuHGs2 lmsNpbGSxBPn0Ki9rTILAXDI8quIosiyRx9OuFU1v8uVtZPoPANcxzZKXjntO/U+m8 UQxYYV4t2duz7Ds02CJqeV8OJqTnwJ+aCcGjdI9yrjvrZ7z9uTEzS/A4+XUhXztiAq bTQSP2p3w8S6e3Fbl6aZXAxtkZHuvUQSbOx8KuLCZU56KqdT/H4Z1l4u+FY6mfcVxR pIHMHXtkpn4zUNH1CtrlT41A= Date: Sun, 6 Sep 2026 10:01:16 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() Message-ID: <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> X-purgate-ID: tlsNG-d25034/1788714107-51538A5B-BCC3AA26/0/0 X-purgate-type: clean X-purgate-size: 1765 On Sat, Aug 22, 2026 at 03:33:18PM -0300, Mauricio Faria de Oliveira wrote: > Move the inline memcmp function currently only available in 'boot/string.c' > into the shared string function header to be reused. > > This is not done through to avoid pulling unnecessary code > in 'boot/string.c' that causes build errors in 'boot/compressed/string.c' > and 'purgatory/purgatory.ro'. Please drop those '' quotes - it is perfectly clear that those are .c files. > No functional changes. > > Signed-off-by: Mauricio Faria de Oliveira > > --- > > Thanks to David Laight for noticing the return value difference between > inline and regular memcmp(). > --- > arch/x86/boot/string.c | 13 ++----------- > arch/x86/include/asm/shared/string.h | 26 ++++++++++++++++++++++++++ > 2 files changed, 28 insertions(+), 11 deletions(-) ... > diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h > new file mode 100644 > index 0000000000000000000000000000000000000000..06c1d5e5013e4d59cfb49866d10e164362d2c4cc > --- /dev/null > +++ b/arch/x86/include/asm/shared/string.h > @@ -0,0 +1,26 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _ASM_X86_SHARED_STRING_H > +#define _ASM_X86_SHARED_STRING_H > + > +/* > + * This inline memcmp() returns 0 (equal) or 1 (not equal). > + * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (greater than) > + * to indicate ordering as well. No need to overdo it: Returns: 0 (equal) 1 (not equal) In contrast, the regular memcmp() follows glibc return value semantics. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Sun Sep 06 18:16:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 06 Sep 2026 18:16:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410465.1641362 (Exim 4.92) (envelope-from ) id 1x3HPi-0008F6-83; Sun, 06 Sep 2026 18:16:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410465.1641362; Sun, 06 Sep 2026 18:16:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3HPi-0008Ez-3Z; Sun, 06 Sep 2026 18:16:22 +0000 Received: by outflank-mailman (input) for mailman id 1410465; Sun, 06 Sep 2026 18:16:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3HPg-0008Et-OH for xen-devel@lists.xenproject.org; Sun, 06 Sep 2026 18:16:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3HPf-006zlu-SE for xen-devel@lists.xenproject.org; Sun, 06 Sep 2026 20:16:20 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9dadb8-2eae-0a2a0a5409dd-0a2a450cc842-24 for ; Sun, 06 Sep 2026 20:16:19 +0200 Received: from [198.137.202.136] (helo=mail.zytor.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9dadf1-f479-0a2a450c0019-c689ca88c9be-3 for ; Sun, 06 Sep 2026 20:16:18 +0200 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 686IFdJ2989969 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 6 Sep 2026 11:15:39 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=2026082801 header.d=zytor.com header.i="@zytor.com" header.h="Date:From:To:CC:Subject:In-Reply-To:References" DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 686IFdJ2989969 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026082801; t=1788718541; bh=DhRKyzANNARtmaWAz4jDDix5ntjLK+kItZzluS+D+BQ=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=My5wT8OQBzVZyrqJR8KvHJV9I7W4IPlJ3k+N1opZm9C4RhQbBHPkMIsiGH4D2WXmq +CYlxhppw5y9EgKmYnWHx4hLBlthWwC0uFmTSvcXgviltv2uImyN1pue9kESh+J2QJ QbqRDmoUiTUb4BfVsk+UCS1z2gix8XSM0GJW/gZA+EArA5vCCzvzd0vq0af6CWn3Sp w1loWnM91xquRmfSrUfad02Cmv3ACRf4eUTCU+rZGvw6WSTpm0/2DdkFZmDVFVF40O 44I7W65KC1lgkxbo8t7DhLUe0yBiwGrDdl0yrPQBj9eirxzUMqa6iEyjlEqYdB7b0k 0gTCPh/269mAA== Date: Sun, 06 Sep 2026 11:15:33 -0700 From: "H. Peter Anvin" To: Borislav Petkov , Mauricio Faria de Oliveira CC: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() User-Agent: K-9 Mail for Android In-Reply-To: <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1788718579-52331A5B-498861EC/0/0 X-purgate-type: clean X-purgate-size: 1993 On September 6, 2026 10:01:16 AM PDT, Borislav Petkov wrot= e: >On Sat, Aug 22, 2026 at 03:33:18PM -0300, Mauricio Faria de Oliveira wrot= e: >> Move the inline memcmp function currently only available in 'boot/strin= g=2Ec' >> into the shared string function header to be re= used=2E >>=20 >> This is not done through to avoid pulling unnecessary = code >> in 'boot/string=2Ec' that causes build errors in 'boot/compressed/strin= g=2Ec' >> and 'purgatory/purgatory=2Ero'=2E > >Please drop those '' quotes - it is perfectly clear that those are =2Ec f= iles=2E > >> No functional changes=2E >>=20 >> Signed-off-by: Mauricio Faria de Oliveira >>=20 >> --- >>=20 >> Thanks to David Laight for noticing the return value difference between >> inline and regular memcmp()=2E >> --- >> arch/x86/boot/string=2Ec | 13 ++----------- >> arch/x86/include/asm/shared/string=2Eh | 26 ++++++++++++++++++++++++++ >> 2 files changed, 28 insertions(+), 11 deletions(-) > >=2E=2E=2E > >> diff --git a/arch/x86/include/asm/shared/string=2Eh b/arch/x86/include/= asm/shared/string=2Eh >> new file mode 100644 >> index 0000000000000000000000000000000000000000=2E=2E06c1d5e5013e4d59cfb= 49866d10e164362d2c4cc >> --- /dev/null >> +++ b/arch/x86/include/asm/shared/string=2Eh >> @@ -0,0 +1,26 @@ >> +/* SPDX-License-Identifier: GPL-2=2E0 */ >> +#ifndef _ASM_X86_SHARED_STRING_H >> +#define _ASM_X86_SHARED_STRING_H >> + >> +/* >> + * This inline memcmp() returns 0 (equal) or 1 (not equal)=2E >> + * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (grea= ter than) >> + * to indicate ordering as well=2E > >No need to overdo it: > > Returns: 0 (equal) > 1 (not equal) > >In contrast, the regular memcmp() follows glibc return value semantics=2E > > Worth noting that memeq() and streq() are becoming used in other contexts,= e=2Eg=2E glibc=2E From xen-devel-bounces@lists.xenproject.org Mon Sep 07 05:13:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 05:13:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410558.1641370 (Exim 4.92) (envelope-from ) id 1x3RfW-00039G-DQ; Mon, 07 Sep 2026 05:13:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410558.1641370; Mon, 07 Sep 2026 05:13:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3RfW-000398-8F; Mon, 07 Sep 2026 05:13:22 +0000 Received: by outflank-mailman (input) for mailman id 1410558; Mon, 07 Sep 2026 01:24:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3O6B-0008CX-53 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 01:24:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3O68-00C0s1-21 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 03:24:36 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e1254-e002-0a2a0a5209dd-0a2a4506cbc8-0 for ; Mon, 07 Sep 2026 03:24:36 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e1253-195a-0a2a45060019-d155dd2cac54-3 for ; Mon, 07 Sep 2026 03:24:35 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48444ec4fe2so1691949f8f.0 for ; Sun, 06 Sep 2026 18:24:35 -0700 (PDT) Received: from localhost.localdomain (dynamic-2a02-3100-9d84-5101-9c80-d25b-14b6-410c.310.pool.telefonica.de. [2a02:3100:9d84:5101:9c80:d25b:14b6:410c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883be709sm25538034f8f.21.2026.09.06.18.24.33 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 06 Sep 2026 18:24:34 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788744275; x=1789349075; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=OzgRAz+t0pvu1F0bGXuWPazB1YZpsW2di9FQ9hUcZ7o=; b=OG5cAlLzLJlpzxiwmTzG2FmnQHKCJaQ8GKdtIb3ouHz1N6De7R/q7L0cSdzFAsat8i WgRGKGHrecQUIEb+44A1mNlXZhIdZ1sHeco9J8yza34+9Mh3CcDobZTxmZbZQuPMq3Av lT6s+UY9/e+8QCRGqMz1dmPXL0QkpyKfHfY4P91s7X3JoDsxVpdEk3DCOmOHED2pH4Zt y83myuM8mwrFKa7QBdPZoWsATpOFa7uYjte37uAuVmfNab//X0GUKiDAY/cQbhJfCRjW npMnboIu2dbHqeftXJ5nLoF81yOjpu+F8kUuxcRmTS1iCct9nJ96fN1Qm4M6X+u+cze6 1QcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788744275; x=1789349075; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=OzgRAz+t0pvu1F0bGXuWPazB1YZpsW2di9FQ9hUcZ7o=; b=Z9QN1bBwxMwJaQg/pdZfp4zY85Bi6B8gvKlQ+v5AJulbpAgBiUyS1Vw/gihrXWdTOc ViG3vKd4iQ6MFoNUPlyKA3HlD2JeBqQq6VQMoF20dTtJ8NHCfIZi+JyVU0fnYAbKbicE DS9ZATW+7dBl4kVZSqy7V6QS4AoPk+aQlMNXBItS5D6EqmAtRsSUeJyY+v7BKX/Xx7U2 SRAJic5Nwaq6OMxbz2fGvoh3JZC6uQx31sxh4j7rE5ribIhBW1bOc5ZJxdS7mJIsQVsz u0jr08qJp2Vz0vCJvgJY1QPdiuSOuhG3y7LmwIt/Mg0S4RfUGGu4+6AEKi9M8oIlsj4G vpJQ== X-Forwarded-Encrypted: i=1; AKwUvByrrs3uvoWdA74j/bi/uW0iTc2KBwr2LLdjHwKKOxGr4SAELiY7w4CDMZpfAdimF4QOhlfZau9rLUc=@lists.xenproject.org X-Gm-Message-State: AFuF++mEkvr0BwpwsUzqYGnIMGTmzClKDC4m2umeAkfrbGNoU5ZzaDRd AOVRhD98vperP4JN9z+91LbVTodj9UawSeoL3dIsjArUtP+fMzzWZL0s X-Gm-Gg: AYBFou00ygs5aNkVjWFG8zPv1KFhr5dn1iwf2xB/wCiEg2wjDl6nN1DLjyE1MrOaeUJ CJwWG/cDFAR9kHwvDz7D1UFpuKUAXeqriLRvWO78JSfubZDb9eTL7CVCw3ffF8PHtJ/mSGWXdwe 9ElyGs6PaD8c1BEqrFkzwL2ZeRnR+b4rmV56+tQGCut8wfFTbvf9IgkzCBgVt2VcP1gqA6Bw8My H/E+wsLt9eFZ7p7SYm4tvazGL3ppjrPt1uBlM170Rgxe0Y2xiDUuTIIkZr+Vv5P5VS0PndtuI57 Yuv1uAXNpsJU5yEBEHUNFLM15FVJapgR/2vUKsmrGu8sp8PT4jafIdWs2YRfTIFK71RZSzqz0RB jzBRcf6phSiglCHK/PbzNzEZeXqAJuwzQ8CiFDEcy3wh75RKL4vUPwwDShcIdn84EcfgyYJahHh xS9B00DqjdIehgmFwZpzGzcMj4RsmwqI+VGhgMKz/fV7FG/7VXHD+YMouZvCLx7VUaQCdIPXt/N 55VVmLXI0YwMbCSml3VDWx3+ow0ty+sisJPEzx9fNHJkY/HJNBOu1RT2+BAnSQHNA2IEsQ2rJXK eAr23egRr6ohAPtUVl8qXeM/ZU9NS+TOw0uFkxHf1lb7WnB7pZD2EE4daehEPOthDMs= X-Received: by 2002:a05:6000:468a:b0:484:3310:710e with SMTP id ffacd0b85a97d-48587291a2cmr31033495f8f.26.1788744275141; Sun, 06 Sep 2026 18:24:35 -0700 (PDT) From: Karl Mehltretter To: Stefano Stabellini Cc: Karl Mehltretter , xen-devel@lists.xenproject.org, linux-arm-kernel@lists.infradead.org, Tejas Mutalikdesai Subject: [PATCH] arm/xen: Point the comment at the YAML binding Date: Mon, 7 Sep 2026 03:24:30 +0200 Message-Id: <20260907012430.21823-1-kmehltretter@gmail.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1788744275-FE87577B-EC72D5F3/0/0 X-purgate-type: clean X-purgate-size: 960 The binding was converted by commit 4dbfe5467485 ("dt-bindings: arm: xen: Convert to DT schema"), so Documentation/devicetree/bindings/arm/ xen.txt no longer exists. Point the comment at the YAML schema. Fixes: 4dbfe5467485 ("dt-bindings: arm: xen: Convert to DT schema") Assisted-by: LLM Signed-off-by: Karl Mehltretter --- arch/arm/xen/enlighten.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 25a0ce3b4584..0b7b7e3417e3 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -251,7 +251,7 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname, } /* - * see Documentation/devicetree/bindings/arm/xen.txt for the + * see Documentation/devicetree/bindings/arm/xen.yaml for the * documentation of the Xen Device Tree format. */ void __init xen_early_init(void) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 07 06:35:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 06:35:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410576.1641379 (Exim 4.92) (envelope-from ) id 1x3SxD-0004iT-2V; Mon, 07 Sep 2026 06:35:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410576.1641379; Mon, 07 Sep 2026 06:35:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3SxC-0004iL-VY; Mon, 07 Sep 2026 06:35:42 +0000 Received: by outflank-mailman (input) for mailman id 1410576; Mon, 07 Sep 2026 06:35:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3SxB-0004iD-VB for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 06:35:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Sx9-00GrDN-1C for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:35:39 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e5b35-2eae-0a2a0a5409dd-0a2a4504953c-42 for ; Mon, 07 Sep 2026 08:35:38 +0200 Received: from [209.85.210.177] (helo=mail-pf1-f177.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e5b39-b57f-0a2a45040019-d155d2b1d1ad-3 for ; Mon, 07 Sep 2026 08:35:38 +0200 Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-85377c8bc96so2873947b3a.3 for ; Sun, 06 Sep 2026 23:35:38 -0700 (PDT) Received: from volcano9f6e-hostos.amd.com ([165.204.217.251]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3339aa37dbdsm21319326eec.11.2026.09.06.23.35.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Sep 2026 23:35:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788762937; x=1789367737; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=4J4rYjNQoetFmHhwvDThjrrPfLTRssIW7zzZbk53w90=; b=UwuWVn/oINxUVovpKDiCvsZ/rd8qNTOFJV2EOfQPPlNjo9GECw+ZxY0S7SSFX7JHwd ePgCKq3shzw0K8gsddgZUPFBMwx17dvGjKLurinzsPz2Q+riiDkRLzTf9ukfj+OKn2Nx WYf8VDw/NqRQWhvfLiTXQk0VdYrkXch+Qq+67m5fP3QJeOjsATg3eLsj0Ylnur/2gOiX 6VHPkwZUmszO9ty2Tw1M9NT2CARmh5GOK/TnxFXDlD+DhIhzPftJOqSM4K0unwwbPhKK zZXAljtJRIzFmxzAKRkVLZcAOY7tZhh9H/sKoZQPHLWpUgFkxBk8KrjG/jIZ3mydREYa d76A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788762937; x=1789367737; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4J4rYjNQoetFmHhwvDThjrrPfLTRssIW7zzZbk53w90=; b=O7ZPP0xU4ePJ95i+WsN7MyLMepuEK5atq3I0yZs19Pical5iEs+Xckoyxx9LsYtsvQ 7w23HX2sstw4+Tx00I1etZV0mN5R5fLFU7EfYsBAsbKkCbs2j4O22HOGbs5bXWIUw/kj UYUp42agVx+ugs9v4TnlImIjTWzWBtzbjGXDP+ghEgzyhtPFqomSnu2pMs/RxufyIrJ5 RoI2XfcQKpXLsPiy0VwFkOGR1GJu+df0SMBRbBeLxhsZO8VUtXmB4fbtm2O57X9YzOOy qOk5GZrAh/hNzqdWsjbe2ibS45nWyU3Ko4lSlVNrYBD5DmRvGNeXzf7XqGqcPA+uyEqP h1kg== X-Gm-Message-State: AFuF++mAi9W/4YFNOBz9OWBFP8laoGmdusvYOGAYuHV4fIJNUK2CUs1Q FO9Og5zLE7LNLqZahpC0lL5DN2vMKOSnnKFOIdYFb4irwAPm8znrrkZW X-Gm-Gg: AYBFou1CkfN/jK8c9x+aTTNw0Xn8Er1zyHyqjedIspDhYVhNeERFcNdP9XTLSs5Ilbp pWohgElqLtJSAwaJv6GHEpJLr9rtmWolr5uAdsYVjyW4gnqdOWqIDQmNseZdxh60dgjj0wkDtrQ G0MvQyN5nDIpMghalcwVlEWZbctjJDBsQX0mjkF7XeDtFfUDyciRd1TVVTFOsYOlKv9rltGs4pz qgIDqY1AaSr4bXwqWAJhJt7xTD++vmEfRTjFme0FRzVbp6q31hpbRBSzb8SVgyOvG0KmCRMNFCo 0xLbZob+Ir1T30u/cj0Dlxcc7PudJ6PhWiyruWRyyzCCs2sEsgMkwhcgIgqKlmY4+DrQjXsgtgn vSH7SC23rVgtizbmlqAMYL3gSNgpbjp8ayMjBj0M2RWrqiHVG/pRJnpgzT3JVhhl/y8wNWX50jj se1AFI4RpBE3ZaraWbq5hBJ+aulh5197+LdVQUTHyD9wtWs5SZr+mVt4CFVnNFwNjDb8AF5chRu jkkw53NziwMQA== X-Received: by 2002:a05:6a21:2983:b0:3d9:6f0:b42f with SMTP id adf61e73a8af0-3da39fd0822mr34557933637.17.1788762936771; Sun, 06 Sep 2026 23:35:36 -0700 (PDT) From: Hemanth Selam To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "James E . J . Bottomley" , "Martin K . Petersen" Cc: xen-devel@lists.xenproject.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] xen: fix typos in comments Date: Mon, 7 Sep 2026 12:05:31 +0530 Message-ID: <20260907063531.23981-1-hemanth.selam@gmail.com> X-Mailer: git-send-email 2.48.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788762938-C08D9B50-967823B3/0/0 X-purgate-type: clean X-purgate-size: 3588 Fix typos in comments, reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam --- drivers/scsi/xen-scsifront.c | 2 +- drivers/xen/mcelog.c | 2 +- include/xen/interface/platform.h | 4 ++-- include/xen/interface/xen.h | 2 +- include/xen/xenbus.h | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c index 989bcaee42ca..f86a47056ea8 100644 --- a/drivers/scsi/xen-scsifront.c +++ b/drivers/scsi/xen-scsifront.c @@ -1076,7 +1076,7 @@ static void scsifront_do_lun_hotplug(struct vscsifrnt_info *info, int op) /* * Front device state path, used in sdev_configure called - * on successfull scsi_add_device, and in sdev_destroy called + * on successful scsi_add_device, and in sdev_destroy called * on remove of a device. */ snprintf(info->dev_state_path, sizeof(info->dev_state_path), diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c index 32ab419bb503..f19cc7a67f36 100644 --- a/drivers/xen/mcelog.c +++ b/drivers/xen/mcelog.c @@ -1,6 +1,6 @@ /****************************************************************************** * mcelog.c - * Driver for receiving and transferring machine check error infomation + * Driver for receiving and transferring machine check error information * * Copyright (c) 2012 Intel Corporation * Author: Liu, Jinsong diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h index 79a443c65ea9..462e36392a9f 100644 --- a/include/xen/interface/platform.h +++ b/include/xen/interface/platform.h @@ -421,10 +421,10 @@ struct xenpf_pcpuinfo { /* IN */ uint32_t xen_cpuid; /* OUT */ - /* The maxium cpu_id that is present */ + /* The maximum cpu_id that is present */ uint32_t max_present; #define XEN_PCPU_FLAGS_ONLINE 1 - /* Correponding xen_cpuid is not present*/ + /* Corresponding xen_cpuid is not present*/ #define XEN_PCPU_FLAGS_INVALID 2 uint32_t flags; uint32_t apic_id; diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index 40c9793e9880..f9acb21875cf 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -94,7 +94,7 @@ #define VIRQ_XENOPROF 7 /* V. XenOprofile interrupt: new sample available */ #define VIRQ_CON_RING 8 /* G. (DOM0) Bytes received on console */ #define VIRQ_PCPU_STATE 9 /* G. (DOM0) PCPU state changed */ -#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occured */ +#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occurred */ #define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient */ #define VIRQ_ENOMEM 12 /* G. (DOM0) Low on heap memory */ #define VIRQ_XENPMU 13 /* PMC interrupt */ diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h index 8ca15743af7f..6424c5cf8ef5 100644 --- a/include/xen/xenbus.h +++ b/include/xen/xenbus.h @@ -63,7 +63,7 @@ struct xenbus_watch unsigned int nr_pending; /* - * Called just before enqueing new event while a spinlock is held. + * Called just before enqueuing new event while a spinlock is held. * The event will be discarded if this callback returns false. */ bool (*will_handle)(struct xenbus_watch *, -- 2.48.1 From xen-devel-bounces@lists.xenproject.org Mon Sep 07 06:36:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 06:36:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410581.1641388 (Exim 4.92) (envelope-from ) id 1x3Sy2-00059R-9Q; Mon, 07 Sep 2026 06:36:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410581.1641388; Mon, 07 Sep 2026 06:36:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Sy2-00059K-6c; Mon, 07 Sep 2026 06:36:34 +0000 Received: by outflank-mailman (input) for mailman id 1410581; Mon, 07 Sep 2026 06:36:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Sy0-00059A-Hw for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 06:36:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Sxz-00EMRo-Uf for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:36:31 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e5b6b-8faa-0a2a0a5109dd-0a2a4506e846-20 for ; Mon, 07 Sep 2026 08:36:31 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e5b6f-195a-0a2a45060019-d155dd33b004-3 for ; Mon, 07 Sep 2026 08:36:31 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-4858269e3d9so176705f8f.2 for ; Sun, 06 Sep 2026 23:36:31 -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 ffacd0b85a97d-485885bfdf6sm27364909f8f.34.2026.09.06.23.36.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Sep 2026 23:36:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788762991; x=1789367791; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=e7Q7QcH+rs+UC/qC/pvy536BuZ0LaD2I57YR+dceG1E=; b=YzlK2oePPlCwm1nihxNKzk63DedXKfEB4iMEI5Wo7iOhylY/RdhNfzHIeumnkYQ91x +o4n+tgeIsLEfp8NS5vistLmL2HRcuovek1Oup7wIPcBk4SSiWMEjsfUj56+VmNSelWJ ewgiVhTyaq0Wxz3dx4y1q+nTFwTNzenypIRWQsymEHNA0ht7FxCB5W72TvM52d67vonb 7tk/9dxzs4AGvXxj5V6lKZj854sKxQ0VUxhejVBIumJX3XvLYYyZ42aYqvV/NYKiUPyY rA1k5YgaX1w9yAVeaMPrHiJBE+0XpmFu9xd2VmUM+3ftoHlGxr7ZVdJSshsCbOGcsA8D FMKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788762991; x=1789367791; h=content-transfer-encoding:content-type: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:content-type; bh=e7Q7QcH+rs+UC/qC/pvy536BuZ0LaD2I57YR+dceG1E=; b=pNTkavzR7K02SzYkGzQ4iMogQLhMi320tcy/QdKtz/zPR8A1rlvKK75v7SKGlXR9aJ /xuqPlwot19bY5nxcsvomKd2lQtceuuOC16EbOEAMsk2JtqrTYZaKbI+n1Fz1E8BHcFP mhpK9Rof67SAbzEkIo3jSuU18UiajRz2uYWMKVJBtyL5FldzEgwj2VQu/6sx+fu6UW6I JznGx2pF7/Fy+Wis09c5OaGULCEzU1Iuh0QtWaCSDV434UV5EGIoviRz76538W6qcS4k omHuaNB+/PRZGvYTpPFBamgHucNdDUWMAmnANgbHVLzQRy86i0zfhmuoSHqbzmsE/5Bd gYrg== X-Forwarded-Encrypted: i=1; AKwUvBx0sFKWlON4gcicxKvoUhS1OtIoIZQcRwcQj0uvCNNuoDHh8d/uT9gOmv+G5Z4Fw3eZpzWYutG/oQQ=@lists.xenproject.org X-Gm-Message-State: AFuF++lxsROKwJJs7Taggy6C7t38IMM3Ewxy3rLI9H8J85Ew9/vnsnAI EZEfvzZ5LzKooDDH/WAjWGpMNOpmGCc9WPRvZs5xBlFwQ8xL72/DiS0sEHh1ZF76Zg== X-Gm-Gg: AYBFou2+i37eTHBa4IQSxU2WS0IzM3OQkGd1m3/LJvce/oiFVNklTLX/DkYsQgHcYIB 8EkBHUExTioD+R8aVyayEfSNIu1lTJcxf4WbMk1QmBaLa7l+auT+FOkJoxGr2dcwcoEgk5GP6x5 3TbwXlhJT3E7fgSlxOQkGl/1JLGm/UEQvJyvg+zVU95PAAuVkpTtmTiZgbAXOv523GP/kN/+RJW 6b2mw7Qu7rx8lH5kj9gtbiNwi2oGRV/geXwP3LFLzurdyMDoLFaz5nAwmtCoGYPAgE/0fzPcvZ5 guMDYaIYRIVIfqnp3TVQJWH11IVd9JuGzBNrdWhzTo3+uNwmytGWu6+AnVsEP9YLCa23MhhzqIO IR33txuevWVCiPUMGxsvhYwhStMPGMcVFu5yRvK5daHUKMaDwAaGRL1jMeKn/CAw6tKKwysIhvl t58ll1rRcivvJA+9JiGSvlu9wLqZy04aIVte3l8didt4xSLd4eI0RVhRskxXk6zpUqYCCHIK0Iw bMeeGenDEVSxfxQNb0YLhVDN5nt8zwV+J/ZQyW+IWHKaAuoFAnT X-Received: by 2002:a05:6000:612:b0:485:8e19:1979 with SMTP id ffacd0b85a97d-4858e191d46mr32572561f8f.11.1788762991188; Sun, 06 Sep 2026 23:36:31 -0700 (PDT) Message-ID: Date: Mon, 7 Sep 2026 08:36:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] x86/nSVM: Check injected event consistency To: Abdelkareem Abdelsaamad Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20260906131117.3121334-1-abdelkareem.abdelsaamad@citrix.com> <20260906132248.3121411-1-abdelkareem.abdelsaamad@citrix.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: <20260906132248.3121411-1-abdelkareem.abdelsaamad@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788762991-F72C677B-E0406677/0/0 X-purgate-type: clean X-purgate-size: 1750 On 06.09.2026 15:22, Abdelkareem Abdelsaamad wrote: >>>> @@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) >>>> svm_dump_sel(" TR", &vmcb->tr); >>>> } >>>> >>>> +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, >>>> + uint8_t vmcb_injected_vector) >>>> +{ >>>> + switch ( vmcb_injected_vector ) >>>> + { >>>> + case X86_EXC_DE: >>>> + case X86_EXC_DB: >>>> + case X86_EXC_BP: >>>> + case X86_EXC_UD: >>>> + case X86_EXC_NM: >>>> + case X86_EXC_DF: >>>> + case X86_EXC_TS: >>>> + case X86_EXC_NP: >>>> + case X86_EXC_SS: >>>> + case X86_EXC_GP: >>>> + case X86_EXC_PF: >>>> + case X86_EXC_MF: >>>> + case X86_EXC_AC: >>>> + case X86_EXC_MC: >>> >>> Is #MC valid to inject without CR4.MCE set? >> The testing I performed (see previous comment) does not show that set CR4.MCE >> is required for the valid injection. >>>> + case X86_EXC_XM: >>> >>> As before: Doesn't #XM (AMD: #XF) require CR4.OSXMMEXCPT to be set? >> The testing I performed (see previous comment) does not show that set CR4.MCE >> is required for the valid injection. > I meant ..does not show that set CR4.OSXMMEXCPT is required. >>> >>> Again as before: Is #SX really permitted without any constraints? You did >>> reply to both comments on v3, but that outcome isn't reflected here. The >>> more that what you said there could equally apply ... >> The testing I performed (see the first comment) does not show that set CR4.MCE >> is required for the valid injection. > I meant ..does not show that any CR4 bit is required. And I didn't mention CR4. I intentionally said "without any constraints". Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 06:37:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 06:37:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410588.1641396 (Exim 4.92) (envelope-from ) id 1x3Sys-0005by-H3; Mon, 07 Sep 2026 06:37:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410588.1641396; Mon, 07 Sep 2026 06:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Sys-0005br-Dg; Mon, 07 Sep 2026 06:37:26 +0000 Received: by outflank-mailman (input) for mailman id 1410588; Mon, 07 Sep 2026 06:37:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Syr-0005bi-CM for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 06:37:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Syq-007N0g-PH for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:37:24 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e5b97-2eae-0a2a0a5409dd-0a2a4508d1a0-46 for ; Mon, 07 Sep 2026 08:37:24 +0200 Received: from [40.93.198.45] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e5ba2-f659-0a2a45080019-285dc62dae19-3 for ; Mon, 07 Sep 2026 08:37:23 +0200 Received: from BL1PR13CA0204.namprd13.prod.outlook.com (2603:10b6:208:2be::29) by DS7PR12MB5837.namprd12.prod.outlook.com (2603:10b6:8:78::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Mon, 7 Sep 2026 06:37:18 +0000 Received: from BN3PEPF0000B06C.namprd21.prod.outlook.com (2603:10b6:208:2be:cafe::97) by BL1PR13CA0204.outlook.office365.com (2603:10b6:208:2be::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.6 via Frontend Transport; Mon, 7 Sep 2026 06:37:17 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF0000B06C.mail.protection.outlook.com (10.167.243.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.1 via Frontend Transport; Mon, 7 Sep 2026 06:37:17 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 7 Sep 2026 01:37:16 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Mon, 7 Sep 2026 01:37:14 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kmRtBCmB40lpkxmj6VeGcyRKCn8GzmVc8lVGTSdPbXqMN76vQUEn6vgGT8hi3K3X6oXqZ5Fj6IqvZ6cq7e27LPNl1srUjmm/vWUEnjf+gOWTD2ZCJ72W9zT5gU7rys4d8JPdIZqYRbcnLbTUKQWZjfv32PwYjhIz6ruDf40AX8ozOAlNwUT9cp7WpND+EUllPTcAWXShhRJlI+p3fguRiKH7zn0YF1om47L8MSmhysrOHtRt9V5UM/D+/wdt3PEGasYQcEQSHZ+d+lwoEnj120mJ1z8DKSE/I/IZl2cqJ+KSjxxjgkwyuMB1QizmdKceO4DfVWyOkc+mYBTtD3Wpeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v4StcKgkQ4GBBNqC7rmJv1+YJwlWU0j125A71M3d4aA=; b=mRyzLWO6YYrMndoYp4UUJF8oxbxlR/SoO0qtT92TEWvKnXQ78Nzf0d+hqUL7EU9eczaPNojit4JVN2nnmEoEbpbsg8g+V2mpvdgI8UqztccZzJnjNdzijdPoFeU8OL+xsLQHeCKDkJjKWI03/+LTCjzFIgR+kDTa8k815yxBowruGjWNdexOLbg742JiJQ7SHVVJ71YoMHXCe/1EOb2rTD4r+1/b48A6U6Zk48gP6BhsAcX644+11hKvgEMl2wq0WD8H3+OS/Blx+QVc9dAWrCZJlKCP4vRcNSdVO9lqc9ZwrPSywxV4ULAFQCzkfjHbu4Ho+Qpi21JiG5SVwJWzXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v4StcKgkQ4GBBNqC7rmJv1+YJwlWU0j125A71M3d4aA=; b=M4xQOqKScxHz0mvOA4FXGIGqGASoEYU+g7jRQ4jVrv2HfLrk7bwx46rgpG1K0R6WF4XrXo2OZe433hK0ntyYlDZ1URmvIdLEsRN34xWthDbhWEdv7LSd9hb77MLh4F/6gOdd30nYgogAT5g/S4kvMs3J4RI8XUZoLzLbmJNbsOg= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Mon, 7 Sep 2026 08:37:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/14] Arm/guestcopy: deviate copy_guest() uses just like their x86 counterparts To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Nicola Vetrini , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06C:EE_|DS7PR12MB5837:EE_ X-MS-Office365-Filtering-Correlation-Id: 5a4ac08d-bea6-42cf-215e-08df0caa763b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|36860700016|23010399003|1800799024|10067099003|56012099006|4143699003|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: p5qVCTwZ7XLdVYjJYt5yZlJKq9Ppi98fWgQKpNw/vsQ4w8Se47WXv8EnQ1fcJd6Z6H/DckdDa+mt7UPTMOq0vzVjK5UJIY92CfvpbefupILdiqh6xFi0rGgxOuyvI6ErJI4te/968qSKpszdkYx9S7vDM8J3TXmyvfIpiiZXD832fRFkWqo6Hr0QQbVKD8x2jPAsb6zCL45D8g52UNbFTtQcy8G79+gYzEdDuoGyqF8mO/rjMEyTse4jvK810gylPXNvP0WIIXZzA01BTs6RPaZQm28b8JgVlwB5fy1vi4dLpm3bvXlOOCIDOGLBagZ8d3oc7HQJK84of0w1EedsQ8OcuHEE3PbLbRYCNZHgAhxh3FolJTzHw7oNgaITuraHCR0R5dHaLp/gCmuO8tBcQhxhDpKlE9mfeXarIGaRrDnw7Hv0Pwxxq2HjEkL/w63PCHI9LfclX2SJ2xJftVLWQi/08RLTB3OfaSYVCd4tYehh7YhAgoBgAT6Ou+FXZCuT+xiIrPj3T+MMpwDQDPC2WQKaoEA5wyUg0fOTJ8etBK/BWoyNWdZ1An1gH6B2v8uVL07K9iXveS4pH817qruUySo5FTTodnEDLyjfsoWfxE+SXiPPxNTbnp4GB1ag4bwmwyvlSS/UpK7aURuNRqSwKA29lOiH9cEeIXeYw71RBzuAPPX0mA8968N/KfFE9AR+8RcDSvu+vPB5a0Rz4Fl/Ag== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700016)(23010399003)(1800799024)(10067099003)(56012099006)(4143699003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: eeboS0hosql8OIzBOffG92MUOHYmeqvFlt0P3iY1CdkvkI0VdEWPMH5HYj2u0DJ2B1rJ/S3mXUUZubGvmIzIoqdS9VN/sZmmegofdu217tB57ySJwmuoKtvpnRU2BRXbG8rKIhZwU7o46zh9WGLv2MOH5VCh4zRcDeLpBuw1DMJvvRZFKV6asKZ2Hi0DmQz8tVJ+Ilc+2GNMm6ycE1XXj7gdeGk8a2+j9zEjgk71aa/St6QFhbP0flMEDr4Lq5uUg1RSSdw05Y3VBWEMHikj0b96GTyOiBnOYqI3/yqglRRfAWFuoGT0e/iPPeDmC6RucYlyMN1HJnQfkk0NJEuVupShYqsKlNLlP8jIY3xDh2bTGkMtkby4PlWYmymYJhMeqkN6TRq4IEVIkM0ZQHR6ogsVzdqc6iu3Qe+OzIL/Bzmd8f/YFgepMSZiIylBt3P6 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2026 06:37:17.7042 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5a4ac08d-bea6-42cf-215e-08df0caa763b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B06C.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5837 X-purgate-ID: tlsNG-c1860d/1788763044-CDB4987B-B84D59A4/0/0 X-purgate-type: clean X-purgate-size: 432 On 02-Sep-26 08:33, Jan Beulich wrote: > Like x86/HVM's __hvm_copy(), Arm's copy_guest() is used for both to-guest > and from-guest copying. Naturally in the latter case the hypervisor buffer > needs writing to, hence the function parameter cannot be pointer-to-const. > > No functional change intended. > > Signed-off-by: Jan Beulich Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 07 06:50:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 06:50:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410599.1641406 (Exim 4.92) (envelope-from ) id 1x3TBF-000088-Hz; Mon, 07 Sep 2026 06:50:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410599.1641406; Mon, 07 Sep 2026 06:50:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3TBF-00007w-FI; Mon, 07 Sep 2026 06:50:13 +0000 Received: by outflank-mailman (input) for mailman id 1410599; Mon, 07 Sep 2026 06:50:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3TBE-00007q-IY for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 06:50:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3TBD-005jgi-Ih for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:50:11 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e5e9d-2eae-0a2a0a5409dd-0a2a450a9f68-26 for ; Mon, 07 Sep 2026 08:50:11 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e5ea2-f2d2-0a2a450a0019-d155dd2fd9d5-3 for ; Mon, 07 Sep 2026 08:50:10 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-485850cf499so1929152f8f.3 for ; Sun, 06 Sep 2026 23:50:10 -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 ffacd0b85a97d-485881353e8sm26571417f8f.1.2026.09.06.23.50.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Sep 2026 23:50:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788763810; x=1789368610; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=jC8PUEm3nmVLXH+bG8ipMslzXTkwRKCB7LVcNscwLPw=; b=X5F+8pM5EyMRAEBdKLv6P1oEcnmE4O4LkFpet1Qz/WEnnrWHC3tuOh0RJTw+7UuS1z uJMnqGAr9iiHE/6CaDkF7fSWU4K+UMFS2MR1PgbTTjy/KxFdg4IG7WsByrug+HDJQ0RA mVuXfleMMYj9XZ9PSoh55/DLQqvxI5U6i+8KtECcP7YlXf0pagFubKhiEkRKOkwtv5kN eJYuiO/ta+2mT6MsqZOS7tHVAFRH1FYcmsEu0jD/ktis8wnejdyDscpHRW9gF6JJumvl hDD9wbngWRj0MT2Hy2XZAcECAzsa+Eb7OSHcw9o6je7m0N6jZBqFwC0nBRyVfIcXQr6t Im/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788763810; x=1789368610; h=content-transfer-encoding:content-type: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:content-type; bh=jC8PUEm3nmVLXH+bG8ipMslzXTkwRKCB7LVcNscwLPw=; b=OUGm9+jdQNRij5sv4ucEJOrjpQXiix4+sVeSUsFSpJ9X267xaFkqkk0ujKCbIYWw5f L4O84cSakCcyYAyHHk1e40V0xQDslUfHO2kl24b0qiAZnyHs+9Vz5+xPw1wemPcd5v0P XhlSR4vS5KPQboLRMGpWujSHJj9NupGzy30HPIH3W0MDEjvyUSgDag6aGNmQ4hBrnz9I zrFT9VmG/XjMY0ma67fiS5HTCrNpUsbD6rFr3MCeTyPuigMG7jhlpOV47zf2ftj/dh0l cvYzpBV98g7UrQprDixwZLnZjDj5HKLbnleDm23eDZom2sNpWonlNdEWhrbZlLkxLgGJ 3DsA== X-Forwarded-Encrypted: i=1; AKwUvBygryGJXs61Paj5mgCOs5pxXXWDhx0w0tB3suLZXyzW2RAu24h6h29RDwvo+gVh6SqkCWB0mbY1EaU=@lists.xenproject.org X-Gm-Message-State: AFuF++lqKq5bLIRxlpr1/biw1l1M8dqqQwtK+xmUaOMz5+6JfSFkCFTQ 37vgzlCcLRtxFAdK2FxYIlCqNryE43CbMcerGr0llfLxKIGtrazv287CoW7Fs7GcOQ== X-Gm-Gg: AYBFou31G77PD+cDjGHPewatepEh8vYBJkI0ikqt4J7nTFdxpH/b3XXCz/MT+PlCLW+ d/a9xYBvy6A8rDflYzHxWd1UbnrueoFDLoLEwoO7tdr1C6h96Y8jqOsqlIBlGNHzt/RN/5gKI44 3s/LcYfoefFs8CCO/ptovBbapJKgilAWTmVXY5t+JAEqhQw9wHNlGc204WliSmd909BZYct+k2k yD7p/zKVERpgH+B+CcOhqDiocSSWr/tBZrIz5UecgezERmZpnea9ieUEEx0sJ6Rl6xP1pO5gCdZ msKaxhBvL/ymJfotMGexYB/Vn5cIipU9NixEbS+tNpvzQcOe7qxlazRZbAaqKD0/sIYpX7wEZqg 4bSWttS/rKymfipmDYykUQvM8za+/63csh8n15dosWLazxjaey/lTSQjyraBbmZlKhFA68d8WB/ wJwGE9XOiz/hD6MwosGA1j0exIWSn+MlgKFpe+sRf/mVDTClzcloIZEJG4L7C6TQ50qyK6rMoDv zOEeSNDXQ5Qn+VBlRJ7glL9zmI7x0mo+MoD7RxXGHJOKZRCr4KZXhAeZwJ9MGQ= X-Received: by 2002:a05:6000:2287:b0:485:8c17:975c with SMTP id ffacd0b85a97d-4858c179908mr16994029f8f.30.1788763810080; Sun, 06 Sep 2026 23:50:10 -0700 (PDT) Message-ID: <586da975-bd71-4305-a17e-cd5ba35995a4@suse.com> Date: Mon, 7 Sep 2026 08:50:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] x86/nSVM: Check injected event consistency To: Abdelkareem Abdelsaamad , roger@xenproject.org Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20260906131117.3121334-1-abdelkareem.abdelsaamad@citrix.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: <20260906131117.3121334-1-abdelkareem.abdelsaamad@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1788763810-589C9CFC-5849B29F/0/0 X-purgate-type: clean X-purgate-size: 9537 On 06.09.2026 15:11, Abdelkareem Abdelsaamad wrote: > On 26.08.2026 15:33, Jan Beulich wrote: >> On 23.08.2026 18:11, Abdelkareem Abdelsaamad wrote: >>> On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has >>> debugging complications, security and performance implications. The APM >>> volume #2 15.20 (40332-Rev. 4.10-July 2026) states the two possibilities that >>> result in a VMRUN exit with VMEXIT_INVALID due to the injected event. These are >>> • Reserved values of TYPE have been specified. >>> • TYPE = 3 (exception) has been specified with a vector that does not >>> correspond to an exception (this includes vector 2, which is an NMI, not >>> an exception). >>> >>> Extend the VMCB validation to check for such inconsistency. >>> >>> The collection of the invalid exception vectors are ported from the upstream >>> KVM commit >>> ("7e79f71bca5c" KVM: nSVM: Add missing consistency check for EVENTINJ). Adjust >>> the checks from the commit to align with the APM Volume #2 and Volume #3 >>> (40332—Rev. 4.10—July 2026) for the X86_EXC_OF and X86_EXC_BR vectors which >>> should not be valid on the x86 64-bit (long mode) platforms. The adjustment is >>> posted to the KVM mailing commit patch thread >>> https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/ >>> >>> Injecting the vector X86_EXC_HV is also found to trigger VMEXIT_INVALID with >>> the Xen hypervisor. Drop the X86_EXC_HV vector from the permitted vectors. >> >> Is this matched by anything in the PM? There is "#HV is only allowed to be >> injected into VMSAs that execute with Restricted Injection." Which suggests >> #HV can be injected, but only under a certain condition. Following what >> Teddy said towards v3, this may want expressing by a separate case block >> also returning false, but having a comment. > I will put it separately with a comment in v5. > Regarding the APM question: the manual does not appear to fully document > generation-specific or microarchitecture-dependent constraints for all the > vectors. And there was no request to add conditionals going in that direction. Checks want to be against feature or enable bits, wherever possible. > Some vectors are only valid starting with the specific CPU generation > that introduced the corresponding feature. To verify the hardware behavior, I > am performing case-by-case testing on 64-bit Windows guests. I inject the > various events at the end of svm_vmexit_handler and see the result: > - If it triggers VMEXIT_INVALID, the injection is invalid. > - If it triggers a triple fault, the event passed the hardware checks and > completed the event delivery. It is valid. > I am testing this across a Naples (older) and a Genoa (modern) platform. For > the X86_EXC_HV, I am consistently getting VMEXIT_INVALID. I will update the > code comments in v5 with the testing matrix used and the findings. >> >>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>> @@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) >>> svm_dump_sel(" TR", &vmcb->tr); >>> } >>> >>> +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, >>> + uint8_t vmcb_injected_vector) >>> +{ >>> + switch ( vmcb_injected_vector ) >>> + { >>> + case X86_EXC_DE: >>> + case X86_EXC_DB: >>> + case X86_EXC_BP: >>> + case X86_EXC_UD: >>> + case X86_EXC_NM: >>> + case X86_EXC_DF: >>> + case X86_EXC_TS: >>> + case X86_EXC_NP: >>> + case X86_EXC_SS: >>> + case X86_EXC_GP: >>> + case X86_EXC_PF: >>> + case X86_EXC_MF: >>> + case X86_EXC_AC: >>> + case X86_EXC_MC: >> >> Is #MC valid to inject without CR4.MCE set? > The testing I performed (see previous comment) does not show that set CR4.MCE > is required for the valid injection. I find this worrying. Roger, any chance you could try to find out whether that's perhaps more an erratum than intended behavior? >>> + return true; >>> + >>> + case X86_EXC_OF: >>> + case X86_EXC_BR: >>> + return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l; >>> + >>> + case X86_EXC_VC: >>> + return vmcb_get_sev_es(vmcb); >>> + >>> + case X86_EXC_CP: >>> + return vmcb_get_cr4(vmcb) & X86_CR4_CET; >> >> ... e.g. here. That is, if a CR4 (or other) check is needed here, but not >> for #XM (or #SX), that's surely worth (briefly) commenting upon. The more >> that, afaics, none of this is spelled out in the PM. > In my testing, the hardware behavior differs across the generations support for > the Control-flow Enforcement Technology (CET): > - Naples (No hardware support): Injecting the event when the feature is > completely unsupported by the CPU results in VMEXIT_INVALID. The VMCB's CR4 > bit is not set as it is expected. > - Genoa (Hardware support exists): If the CPU supports the feature but the > guest has not enabled it in CR4 (not opted-in), injecting the event > results in a triple fault. I am accordingly checking for the CPU feature and > report it as invalid. A guest triple fault, I assume? I'm not entirely convinced this is a sufficient indication of injection being permitted, even though I agree it very much looks so. Then again, like above, I'm also unconvinced this is actually intended behavior. Guests unaware of a feature (and hence not enabling it) should never observe exceptions related to only that feature. >>> @@ -330,6 +368,12 @@ bool svm_vmcb_isvalid( >>> unsigned long cr4 = vmcb_get_cr4(vmcb); >>> unsigned long valid; >>> uint64_t efer = vmcb_get_efer(vmcb); >>> + uint8_t vmcb_injected_type = vmcb->event_inj.type; >>> + uint8_t vmcb_injected_vector = vmcb->event_inj.vector; >>> + uint8_t vmcb_valid_event_inj_types_mask = (1 << X86_ET_EXT_INTR) | >>> + (1 << X86_ET_NMI) | >>> + (1 << X86_ET_HW_EXC) | >>> + (1 << X86_ET_SW_INT); >> >> The absence of X86_ET{_PRIV,}_SW_EXC likely wants a brief comment, as that's >> a peculiarity of SVM. Alternatively how about introducing X86_ET_SVM_ALL (or >> some such) as a #define somewhere? > I thought the mask varibale name is sufficient? I am also fine with the #define > but it will be a one time usage. What is your suggestion? I gave my suggestion. The variable name I, personally, consider too long anyway. >>> @@ -392,6 +436,20 @@ bool svm_vmcb_isvalid( >>> PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n", >>> vmcb->event_inj.raw); >>> >>> + if ( !vmcb->event_inj.v ) >>> + PRINTF("eventinj: valid bit is not set (%#"PRIx64")\n", >>> + vmcb->event_inj.raw); >> >> I understand the parentheses in the log message here. Yet ... >> >>> + if ( !((1 << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) ) >> >> If vmcb_injected_type really could take all possible uint8_t values (see >> below), this shift would be at risk of becoming UB. And uint8_t is a >> stronger hint that all possible values may appear than unsigned int is. > I am OK to change to unsigned int for safety with future possible extensions. >> >>> + PRINTF("eventinj: Invalid Injected Event Type: (%#"PRIx8")\n", >>> + vmcb_injected_type); >> >> ... what purpose do they serve here (and below)? > I did it just to go with the previous format but I am OK to drop in v5. You did notice the difference in message type, though? Where parentheses are used in existing messages, the values put there serve as auxiliary information to the wording used. Whereas here you plainly dump a value, without saying what exactly is wrong (that's actually said by the value dumped). >> + if ( (vmcb_injected_type == X86_ET_HW_EXC) && >> + !is_valid_injected_exception_vector(vmcb, vmcb_injected_vector) ) >> + PRINTF("eventinj: Invalid exception type: (%#"PRIx8") vector: " >> + "(%#"PRIx8") for the platform\n", >> >> Does "for the platform" really add any value? With it dropped, the >> whole format string could also go on a single line (which we generally >> prefer). > My point was to give an expressive hint as the injection combination can be > invalid on one platform/mode but valid on another (for example, #BR injection > triggers VMEXIT_INVALID in 64-bit long mode but is allowed in 32-bit mode). The > CPU generation also matter as outlined before. I fear I don't see how this explains the extra words used. >> Finally a more general comment: svm_vmcb_isvalid() is used solely out of >> nestedsvm.c. I hence think it would better move there, and such moving >> would better come ahead of adding more code (which would then also need >> moving). > This is a point that needs to reach a consensus between you and Teddy. In the > v3 review, Teddy commented to expand the use of svm_vmcb_isvalid() by calling > it within svm_vmexit_handler() when exit_reason == VMEXIT_INVALID. If I follow > Teddy's suggestion, the function needs to stay in a shared location. Otherwise, > the function will be kept, as is, strictly for nested SVM usage and moving it Well, my comment was based on present code. If you follow Teddy's suggestion, my comment would simply become inapplicable. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 07:54:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 07:54:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410615.1641415 (Exim 4.92) (envelope-from ) id 1x3UBT-0000Sf-6Z; Mon, 07 Sep 2026 07:54:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410615.1641415; Mon, 07 Sep 2026 07:54:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3UBT-0000SY-2z; Mon, 07 Sep 2026 07:54:31 +0000 Received: by outflank-mailman (input) for mailman id 1410615; Mon, 07 Sep 2026 07:54:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3UBR-0000SS-Qi for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 07:54:29 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3UBQ-0036KC-12; Mon, 07 Sep 2026 07:54:28 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x3UBQ-00F9Mb-2X; Mon, 07 Sep 2026 07:54:28 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=TjaK1aNsxcIM7rgTT/kjgetUHqMwYgfVRiGkAesnSd0=; b=h/LnFSj72cNOcv7NmV0usANS3m ZyigNSP672EM/0ywWcvAuJG3YS678hnuxG15HQMttVuXTCGeYdzCKUiOjD8Sz+o1Fuo4By6r3/pY/ HuQPF+h43FtmXhPnNfVkzmkbdd5i0O/TF+mmio+9nCnhLyyZfWwQoqlWuk7QDw6sBaYs=; Date: Mon, 7 Sep 2026 09:54:06 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 05/14] x86/altcall: hide casting away of const Message-ID: References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Sep 02, 2026 at 08:32:09AM +0200, Jan Beulich wrote: > ALT_CALL_PTR() really means to get rid of const (when necessary, i.e. when > used from apply_alt_calls()): We want to patch the original call site, > after all, and memory-wise that's unrelated to the struct alt_call * that > we start from. > > No functional change intended. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:02:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:02:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410632.1641423 (Exim 4.92) (envelope-from ) id 1x3UJ9-0002i0-7q; Mon, 07 Sep 2026 08:02:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410632.1641423; Mon, 07 Sep 2026 08:02:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3UJ9-0002ht-4c; Mon, 07 Sep 2026 08:02:27 +0000 Received: by outflank-mailman (input) for mailman id 1410632; Mon, 07 Sep 2026 08:02:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3UJ8-0002hn-4c for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:02:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3UJ6-0036ym-1n; Mon, 07 Sep 2026 08:02:24 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x3UJ7-00FxG0-04; Mon, 07 Sep 2026 08:02:24 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=1Q3WAeJi2uYHZWOdjLfRH35Q5Pn7ObXOgMy9qYT+rJU=; b=gG5AV0HqUz26A+Nu5Ee97djvsy XoAiuQhFsLJ3tCg3mGK7Ild6M+mnT32YE6AxSNYQluGhqTvpz3O1/vllbj5+fk06U45mTgjKANWnb Jd83YEzIcirIRnhfg2cEEZk68pLdtOOVMsVsCCYyzHbFzTRjZ2K+yTAc8zVG82nMNXLY=; Date: Mon, 7 Sep 2026 10:02:21 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 04/14] x86/boot: don't cast away const-ness Message-ID: References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Sep 02, 2026 at 08:31:45AM +0200, Jan Beulich wrote: > While the general C library strchr() has to do so, the early boot cmdline > parsing has no such requirement. > > No functional change. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné I won't usually agree to changing the interface of C library functions, but this is limited enough to early boot cmdline parsing that's IMO OK. It might be good to rename the function so it doesn't alias with the C library namespace now, since it's a different interface. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:13:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:13:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410642.1641432 (Exim 4.92) (envelope-from ) id 1x3UTa-0004UF-47; Mon, 07 Sep 2026 08:13:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410642.1641432; Mon, 07 Sep 2026 08:13:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3UTa-0004U8-1I; Mon, 07 Sep 2026 08:13:14 +0000 Received: by outflank-mailman (input) for mailman id 1410642; Mon, 07 Sep 2026 08:13:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3UTZ-0004U1-5D for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:13:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3UTY-008itU-I5 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 10:13:12 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e720a-e002-0a2a0a5209dd-0a2a450bcac4-30 for ; Mon, 07 Sep 2026 10:13:12 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e7218-b7e8-0a2a450b0019-d155dd29edcc-3 for ; Mon, 07 Sep 2026 10:13:12 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-47ddf7b09e5so3655114f8f.1 for ; Mon, 07 Sep 2026 01:13:12 -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-49ce58da3acsm802142145e9.0.2026.09.07.01.13.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 01:13:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788768792; x=1789373592; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=rDWRoaixBSa+yrlWavbiaoOEY8KRr2jDNabOhhHI10g=; b=MyHeFJLz6JuQu7/C7SRyFZH0mogdhAQg0v5luu3BqIrDff5JnnvFNjh6bBxPZSbz0E Ja8vDQ2bKr8wo50kIgmyTJtzyFG290cpsGtnypB2D0bTax9mjp5P95ITKIpPdT+uPWLG GKpt5dEFGwBn8X16VFFK6UFzYwgGgJzRLGIIsMDcxe18trA60MxyIoHk2PlniQwu/ZmL Wx4VM8josW2f2R3nJSjZh6ZUS7LenXzMU2Gg7odryvgr9/STKhj3gsyIIrWT/yFmwKAM 4Z+4ASCgsI201paYPkEDUYrELGYQCz6AlAOZ1lx8NxDi6kK8bLIDfeKHl2vTulku4lEN FXKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788768792; x=1789373592; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rDWRoaixBSa+yrlWavbiaoOEY8KRr2jDNabOhhHI10g=; b=LGTuLyf1kP4vzwEfrphXJgSrTmSPLJzOiL2EgIc77TXF64BqL9gzT+kaW8i0b5/B/2 MmFMv2zfFg8INvbWT5W6v4aoNcbn+5e8ZVnkvh8/q6W7UvUHfZ4ou1gBJbtW0kLS0qPE KXumIdgyG88DIqbR4KhWR/dDbBb8Dmk0p+akZPOjw9NzhjzjcOAQBIuLK18kArvOAXNs mFu3BofJDjZikoRVw6FLXh9QqVyr04XMeKQqA/ToNKehEbDPSj2K+BrxV/ParTwvh9Uo pLieI/+0WiNjmGIJY45LIzbTJch+Yfp7CFNX+dbTo/g3RuSIYIPspYRpZeAk+pAc3e1w sJ3A== X-Gm-Message-State: AFuF++k+aCeagzUe+3yEyrDHEgVx4mlgjGi0pR8E+xV2UqRNg8Uqyh4X AFZvQ3gWm72wLptZBtWqxsCM+vbK7uePnsc29O8Z2HcGsu8/Xju1LVXe/l27BNLgOYhhsw+nce3 aYiJ/sA== X-Gm-Gg: AYBFou3lQ+rMItEQvlZ3ZXXltCmqJmoqV7tBusuO42VdoO9FglWGwIFWyklAdUWESYy g8ivIxNyW4vwbgf5caNS5CBVrtJJlZEl0Ab08UavflF9NcPto1h3hSuQN3n8U5AvsudygSS9hH8 3mQ3osrEukt89JeNgh97eb+1J4gW0LCvMWZGaW0blIUjihK0NcZiD6eMsdWHRVrIGihGzO8oh5a em33opAIrAWtJz8jOUdSBjsgZSnaAo3fM6l734zcMsJ8hKsDH2IVWa1rBd+9vdK7pdm7o+8dmcA QWQqlDwc9s3fp7UU8rwZ4ItR923H5yqAwvsUTpbSTCdt+xTPHCD5ClKEewYZ4c99uIaPxn0hizb spM27tcQqnikbAlb0f02HAEeyUUSApu/yIFS6nj1utU6YPuy2JyXg2t+C9EVb2KHhX3z5UC4WkR gafiQUffOtegqvKS66k/N0YgBygIS8STk55zVTgO4Uby5SoBLTu/Yqs2e841S+kWG/pdMXCXSHq sFgiE0aI9bwC2BIrpSOW+RbdU8ngMXE2JM3siGPV3Bu+75YjZkt X-Received: by 2002:a05:600c:474a:b0:499:79b9:e220 with SMTP id 5b1f17b1804b1-49cf825d722mr192950165e9.10.1788768791903; Mon, 07 Sep 2026 01:13:11 -0700 (PDT) Message-ID: <7a77f613-84b9-4049-804c-c3f53d804a38@suse.com> Date: Mon, 7 Sep 2026 10:13:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/vRTC: don't overrun array when storing century field 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788768792-A9AC09EA-A23823E1/0/0 X-purgate-type: clean X-purgate-size: 1515 rtc_ioport_write() has two writes of the new value, yet only one was made aware of the century going outside of the array. Fold both writes by changing the RTC_SET short-circuiting. Fixes: f2ff80877f66 ("x86/vRTC: support century field") Coverity ID: 1700943 Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/rtc.c +++ b/xen/arch/x86/hvm/rtc.c @@ -521,20 +521,22 @@ static int rtc_ioport_write(RTCState *s, case RTC_MONTH: case RTC_YEAR: case RTC_CENTURY: - /* if in set mode, just write the register */ - if ( (s->hw.cmos_data[RTC_REG_B] & RTC_SET) ) - s->hw.cmos_data[s->hw.cmos_index] = data; - else + /* If in set mode, just write the register. */ + if ( !(s->hw.cmos_data[RTC_REG_B] & RTC_SET) ) { /* Fetch the current time and update just this field. */ s->current_tm = gmtime(get_localtime(d)); rtc_copy_date(s); - if ( s->hw.cmos_index != RTC_CENTURY ) - s->hw.cmos_data[s->hw.cmos_index] = data; - else - s->hw.century = data; - rtc_set_time(s); } + + if ( s->hw.cmos_index != RTC_CENTURY ) + s->hw.cmos_data[s->hw.cmos_index] = data; + else + s->hw.century = data; + + if ( !(s->hw.cmos_data[RTC_REG_B] & RTC_SET) ) + rtc_set_time(s); + alarm_timer_update(s); break; case RTC_REG_A: From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:17:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:17:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410649.1641441 (Exim 4.92) (envelope-from ) id 1x3UXw-00058f-Jo; Mon, 07 Sep 2026 08:17:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410649.1641441; Mon, 07 Sep 2026 08:17:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3UXw-00058Y-H6; Mon, 07 Sep 2026 08:17:44 +0000 Received: by outflank-mailman (input) for mailman id 1410649; Mon, 07 Sep 2026 08:17:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3UXv-00058S-8X for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:17:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3UXu-00C5Nt-EC for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 10:17:42 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e7323-8faa-0a2a0a5109dd-0a2a450587ba-18 for ; Mon, 07 Sep 2026 10:17:42 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e7326-4cb1-0a2a45050019-d155802caca8-3 for ; Mon, 07 Sep 2026 10:17:42 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-495590dde14so46406695e9.0 for ; Mon, 07 Sep 2026 01:17:42 -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-49cee6158e9sm376679445e9.12.2026.09.07.01.17.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 01:17:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788769062; x=1789373862; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=9vXrpa2vGTgtGlYpl9YYOGu5SXAWi1wkcb5Ol8iXcrw=; b=KeZP2G7OYI/UN0YryRQbHq/As9ppzcGjlVVDFmc3rZxX6oGI829saw/SQ9j1PgKRwu 66OHVKgPZpKJuse4LC3qkgXVTTlv0T7R6hIF81R20uibEiIWwKwoGZ0k7Vrry4MCvRgY 4xMCaPYeEvrJi60dM3Uot3JBD3drlw9U/AoQZfiqalw8DlzZPW2GUFvTHVUKxA1CsFBS JjDnc9tpg853VnkpcRY+MC2LsZ/YKraIAgTOjHUhpuhLfmaHrZeKeGDH85RmnUjyOSo5 h6zcyPgZrsK7M8zTmZS5diRz/RwLcPUWzhSQbXotz+oGio47JifGrDitYvI908GRoM94 Af9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788769062; x=1789373862; h=content-transfer-encoding:content-type: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:content-type; bh=9vXrpa2vGTgtGlYpl9YYOGu5SXAWi1wkcb5Ol8iXcrw=; b=pcxKbGz43H5HupWGWRXuOo2y7OJQ0tQtMCBT1PR+7rFPrNOFKprFZ8HGnHwkJO4+sr j1AxtLO8vkA09fUxqlbOtEDY1X1Ez/WuNwhd+GXyDtPAw5OzCh4icoJFIlXDOBlqdciS 1eOSpk5p9KLU8+AstCLEr5i85EyrL3tkmKpbSebz2s/qj8PFVR1xAQ465ihu3KvrjW2x eDCmLB9s8P3f5UFqbI1794TLE/0CIDVuAsg71UtpsbNnnm0JptFOolFsHXDRZcMBvWIX GWEmjP8EuicmsBXH019TgvnzvFA0tpxPeobfaB7CpoostH/N4X0W4ElUdptbPjl8n3LZ WUfg== X-Gm-Message-State: AFuF++mLEV8krhRA3U/1Vby50jMQY/RynHWpXj7RZ7aawfAyqELSxVRB 3t4awjnBLFPKjcS8HAzGR4Ia/Dpi5dWdKn5kPk0/9qE/++sducPRFBeGsEAdUtJNLw== X-Gm-Gg: AYBFou1T6q3I/kgues17uQ+81LZd6/xz8ox5Hh6d1Xz/5C6SyeFx+5WQfOsU8/41Y0a y0i8FSDfPnJZt3Fwq/sTovXjEooC8FkNCxWzjgJjzVtIMlHCLsUnbq1IzOGVMWgzRtszamz6uUc MuyoGUhSNYsvsG1pBdgZneNSfTuGqDUR/u8PQEEXp7GLdpq/3vdiDgxWT/So5jtLp+6awwBtN/C 7opT16rfAYEZVhk58fjknEROQmC/8toynYKzKOcLtXPiz0jXmrsBV7zTca8JrW+EoXsxSeugwOd xTvm0J8l7ZKdih4DE1UFPpk1vdEF18RRCmgKNpPkPco2CGyqlPP2ypmMQNDni8o5VXiXKlMyCNw Q+4/GA5Q6/pmdYmDb4QXcESRFnjbC6CbSWwed8oiNT9Vxb6OlDW8UpwE4nTrxF2XWbBqz78qV16 cp8iY9i6nKSn49/Tj29DqJ8iUOZePWcBxCF2v88UdUuQd/Vl6zOeUQe7FmwKmUCviEooyB02UKM eYnjQCHMYic+WD2AsaxrWCP4gZOO30KaXw2IsKnivDr0SDpsmFR X-Received: by 2002:a05:600c:860b:b0:49c:ee20:e787 with SMTP id 5b1f17b1804b1-49cf7fe62e9mr438063175e9.1.1788769061691; Mon, 07 Sep 2026 01:17:41 -0700 (PDT) Message-ID: Date: Mon, 7 Sep 2026 10:17:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3@vates.tech> <91c9abf0-a25f-42d0-9d55-61a9cc62e233@gmail.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: <91c9abf0-a25f-42d0-9d55-61a9cc62e233@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1788769062-F46A52A1-3939C5D7/10/73395122804 X-purgate-type: spam X-purgate-size: 10100 On 04.09.2026 16:55, Oleksii Kurochko wrote: > > > On 9/4/26 10:26 AM, Baptiste Le Duc wrote: >> As I understand it, a generation wrap doesn't retire a single VMID, it >> resets next_vmid to 1, which makes every VMID in 1..max_vmid reusable >> again in the new generation. We do a full (local) flush at that point to >> avoid two different vCPUs ending up with the same VMID valid at once, >> across generations. >> >> If this is correct, doing a full flush there also throws away entries >> for the current vCPU that a local HFENCE.GVMA(vmid) per retired VMID > > We are doing flushed for the pCPU on which a vCPU is ran. > >> could have preserved. A local-flush-per-VMID approach could also >> reduce how often we need a full flush at all. >> >> Is there a reason we don't do local flushing instead? I see x86 and KVM >> use the same flush-all design on wrap, so I assume there's a reason I'm >> missing, I'd like to understand it. > > What do you mean here by "local flushing instead"? We are doing local flush: > > if ( unlikely(need_flush) ) > local_hfence_gvma_all(); > > Do you mean why we don't do hfence_gvma only for specific VMID? > > A vCPU's VMID is valid only while vmid->generation == data->generation > (vmid.c:141). Bumping the generation invalidates every vCPU's VMID on > this hart simultaneously, so every G-stage entry in the TLB (whatever > number it is tagged with) belongs to a (vcpu, vmid) binding that can > never be consulted again. Each of those vCPUs will be handed a fresh > number on its next vmenter before it can run. > > That includes the current vCPU, which is the case you're worried about. > At the wrap it is being assigned VMID 1, not its previous number, so its > old entries are unreachable regardless of whether we flush them. > hfence.gvma per retired VMID would preserve them physically but not > usefully [A concrete example. vCPU A is running on the hart with > VMID=100 in generation G; the TLB holds G-stage entries tagged VMID=100. > A wrap occurs: the generation becomes G+1, next_vmid is reset to 1, and > A is assigned VMID=1 (vmid.c:154). From that moment on, the hardware > looks up translations for A under the tag VMID=1. The entries tagged 100 > will no longer match anything: A isn't 100 any more, and no one else > will be handed 100 until the next wrap. > So A loses its warm entries not because we did an hfence.gvma, but > because it was renumbered. The flush has nothing to do with it. It > merely discards what has already become unreachable.]; they'd just > occupy TLB capacity until natural eviction. Preserving them would > require a different allocator that keeps a vCPU's number stable across a > rollover (Linux/KVM-arm64 style, with an active/reserved set pinning > live ASIDs), not a different flush granularity. > > So x86's hvm_asid_handle_vmenter() and KVM's equivalent aren't doing > this out of inertia — with a round-robin generation allocator, the full > flush is free of useful collateral damage and strictly cheaper than the > alternative. Preserving entries across a rollover is a real > optimisation, but it's an allocator change, and IMO worth doing only if > profiling shows the wrap flush matters. > >> >>> H/VS CSRs, virtual timer and P2M context, and __context_switch() in assembly, >>> which switches Xen's own callee-saved state (and thereby the stack) from >>> prev to next. Virtual interrupt controller context switch will be >>> introduced later. >>> >>> Add offsets of struct arch_vcpu's xen_saved_context to asm-offsets.c for >>> use by __context_switch(). >>> >>> henvcfg and htimedelta are 64-bit on both RV32 and RV64, so store them as >>> uint64_t and use csr_{read,write}64() instead of open-coding accesses to >>> the high halves. >>> >>> A hart which drops out of a domain's dirty_cpumask stops being a target >>> of p2m_tlb_flush() while its TLB may still hold G-stage translations of >>> that domain, and neither the vCPU which just ran nor any other vCPU of >>> that domain which ran there earlier has had its VMID invalidated. Move >>> the hart to a new VMID generation at that point: a VMID number is never >>> re-used until a full local flush has happened, hence none of those >>> translations can be reached again. >>> >>> Claim the VMID in p2m_ctxt_switch_to() rather than at the next guest >>> entry. VMIDs are a per-hart resource, so the (generation, vmid) pair a >>> migrating vCPU brings from another hart is meaningless here and may even >>> match this hart's current generation, leaving the vCPU under a VMID owned >>> by another domain. ctxt_switch_to() invalidates that pair, but claiming a >>> replacement only on guest entry is too late: p2m_ctxt_switch_to() has by >>> then already made HGATP live, and speculation can populate G-stage entries >>> of the incoming domain under the stale VMID. The local flush for a wrapped >>> generation moves along with the claim. >>> >>> That leaves p2m_handle_vmenter() with nothing to do, so drop it together >>> with its call from check_for_pcpu_work(). A VMID can only be invalidated >>> while its vCPU isn't running: vmid_flush_vcpu() is called for the vCPU >>> being switched in, and vmid_flush_hart() runs either from schedule_tail(), >>> ahead of ctxt_switch_to(), or from the wrap path of vmid_handle_vmenter() >>> itself. A P2M change on another hart doesn't invalidate it either, as >>> p2m_tlb_flush() drops the stale entries directly with >>> sbi_remote_hfence_gvma() instead of retiring the VMIDs which tag them. A >>> guest therefore always runs under the VMID claimed on its way in, and >>> there is nothing left for a guest entry hook to notice. >>> >>> p2m_handle_vmenter() also skipped the HGATP write when the VMID it claimed >>> was unchanged. That isn't carried over: HGATP holds the G-stage root as >>> well, and skipping the write is only correct where that root is already >>> the incoming domain's. On the guest entry path it is, on the context >>> switch path it is not. >>> >>> While at it, fix the inclusion order of headers in asm-offsets.c: Xen's >>> headers go first, then arch specific ones. >> This could have a dedicated patch no? > > It could but considering that it is pretty small fix I think it could be > part of this patch. If you are insisting on moving that to separate > patch I will happy to do that. > >>> Signed-off-by: Oleksii Kurochko >>> >>> diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c >>> index ec327a5e8a..91a46d630f 100644 >>> --- a/xen/arch/riscv/domain.c >>> +++ b/xen/arch/riscv/domain.c >>> @@ -11,9 +11,11 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> +#include >>> #include >>> >>> struct csr_masks { >>> @@ -158,6 +160,8 @@ int arch_vcpu_create(struct vcpu *v) >>> if ( is_idle_vcpu(v) ) >>> return 0; >>> >>> + v->arch.last_cpu = NR_CPUS; >>> + >>> vcpu_csr_init(v); >>> >>> if ( (rc = vcpu_vtimer_init(v)) ) >>> @@ -329,6 +333,169 @@ int arch_domain_create(struct domain *d, >>> return rc; >>> } >>> >>> +static void save_csr_regs(struct vcpu *vcpu) >>> +{ >>> + /* >>> + * There is no need to save these CSRs as only hypervisor writes them in >>> + * restore_csr_regs() and guest can't access them so they shouldn't be >>> + * stored here. Keep them commented here just for symmetry with the >>> + * restore CSRs register part. >>> + * >>> + * vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); >>> + * vcpu->arch.hideleg = csr_read(CSR_HIDELEG); >>> + * vcpu->arch.henvcfg = csr_read64(CSR_HENVCFG); >>> + * vcpu->arch.hcounteren = csr_read(CSR_HCOUNTEREN); >>> + * vcpu->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); >>> + * >>> + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >>> + * vcpu->arch.hstateen0 = csr_read(CSR_HSTATEEN0); >>> + */ >>> + >>> + vcpu->arch.hvip = csr_read(CSR_HVIP); >>> + >>> + vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS); >>> + vcpu->arch.vsie = csr_read(CSR_VSIE); >> >> >>> + vcpu->arch.vstvec = csr_read(CSR_VSTVEC); >>> + vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH); >>> + vcpu->arch.vscause = csr_read(CSR_VSCAUSE); >>> + vcpu->arch.vstval = csr_read(CSR_VSTVAL); >>> + vcpu->arch.vsepc = csr_read(CSR_VSEPC); >>> +} >>> + >>> +static void restore_csr_regs(struct vcpu *vcpu) >>> +{ >>> + csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); >>> + csr_write(CSR_HIDELEG, vcpu->arch.hideleg); >>> + csr_write(CSR_HVIP, vcpu->arch.hvip); >>> + csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); >>> + csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); >>> + csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); >>> + >>> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >>> + csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); >>> + >>> + csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); >>> + csr_write(CSR_VSIE, vcpu->arch.vsie); >> >> >>> + csr_write(CSR_VSTVEC, vcpu->arch.vstvec); >>> + csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); >>> + csr_write(CSR_VSCAUSE, vcpu->arch.vscause); >>> + csr_write(CSR_VSTVAL, vcpu->arch.vstval); >>> + csr_write(CSR_VSEPC, vcpu->arch.vsepc); >>> +} >>> + >>> +static void ctxt_switch_from(struct vcpu *p) >> Is it expected to have diverse names for the vcpu arg? Above it's vcpu, >> here it's p (I assume it's for `previous` but I think the _from alone is >> enough to understand) and below it's n. Shouldn't be better to keep the same name? > > Above should be used n. Why would that be? n in such contexts stands for "next", while here it can only be "previous". Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:27:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:27:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410657.1641452 (Exim 4.92) (envelope-from ) id 1x3Uhd-00076M-KK; Mon, 07 Sep 2026 08:27:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410657.1641452; Mon, 07 Sep 2026 08:27:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Uhd-00076F-Fw; Mon, 07 Sep 2026 08:27:45 +0000 Received: by outflank-mailman (input) for mailman id 1410657; Mon, 07 Sep 2026 08:27:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Uhb-000769-N8 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:27:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Uha-0064pF-6L for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 10:27:42 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e7571-bab6-0a2a0a5309dd-0a2a4506a462-20 for ; Mon, 07 Sep 2026 10:27:41 +0200 Received: from [205.220.177.32] (helo=mx0b-00069f02.pphosted.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e757c-195a-0a2a45060019-cddcb12043ce-3 for ; Mon, 07 Sep 2026 10:27:41 +0200 Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6871o22Q1765250; Mon, 7 Sep 2026 08:27:08 GMT Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4ggbdmhneb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 07 Sep 2026 08:27:07 +0000 (GMT) Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.7/8.18.1.7) with ESMTP id 6878P4M6019806; Mon, 7 Sep 2026 08:27:06 GMT Received: from bl2pr02cu003.outbound.protection.outlook.com (mail-eastusazon11011025.outbound.protection.outlook.com [52.101.52.25]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 4gh711upfu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 07 Sep 2026 08:27:06 +0000 (GMT) Received: from CO1PR10MB5506.namprd10.prod.outlook.com (2603:10b6:303:161::7) by LV3PR10MB7913.namprd10.prod.outlook.com (2603:10b6:408:20f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.6; Mon, 7 Sep 2026 08:27:03 +0000 Received: from CO1PR10MB5506.namprd10.prod.outlook.com ([fe80::da72:a0a9:5f18:cda4]) by CO1PR10MB5506.namprd10.prod.outlook.com ([fe80::da72:a0a9:5f18:cda4%6]) with mapi id 15.21.0382.007; Mon, 7 Sep 2026 08:27:02 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-oracle-onmicrosoft-com header.d=oracle.onmicrosoft.com header.i="@oracle.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2025-04-25; bh=UYtwU8nSl4f+pvu1Cyhe+AkaSo2R6RBy/0GAoDQZLhM=; b= U1oQcSpp36PYppmQpc79sJKsSMqNpfAy/1cqqAdBX1KWx6dBEqyXa4wlRu7OMt9T 8bEUIxcplSGd2OztSXKTrqbH5Oj3qAxFVLTx7reNtVGl84DYWkgbw1BP/GDODCnN cZ3ieddT9YtCWgekcW79L6POumSLAWGDJJsQN63yKlc01ATlHBiNlix3EtsJ15ra A8EJySHE3Sa8Cughd3rWP/mYiNCyBgNp6IfNdgqePcLbr0zjoM7NpgSnWNZFV84Z Q796teiRka+N9C2i4LkiuW5go7fbUBJhGtyvZLJLwH/kRpoDSy7VPHNY2FC89d2J 6C0XScGqr9Yq7ooLafvogg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kPKSJFkUf0pbym8jIRf5WLhw4agnJp6Qu9FpVyKQbaCzqFeivTNMVfXDX8oIKvMeCV3ew23rF0+1WcfY+L/YaSU065txe7r9yQ+xxMnCjZY1Ms376f7egkGaCDQ0O+OS0CR9NT5Rrm2GTBMOrzYGzu1ZnnpirmQa6tbVVq/9Nx801ZIbHpsAK6PDrkKIQC8oMgBA8shtVBoPyOwQR9a6V18iTg+IIRe/C+BE0fl/5yiRwbxyVGrJUZq/BtDp1dsGZ/KQ3iMzZOB6tnFVqsfZ6Tqoqm5v4r9P2uuFqV0Wb+4ulQjzTVGojjJ8Xo8Uv5dWzSozRZjBGMNeOdmz2IexGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UYtwU8nSl4f+pvu1Cyhe+AkaSo2R6RBy/0GAoDQZLhM=; b=tAWTScL6mdERC4z/Y73gGJ+AIeTj3h3mU89yNZB0gufVyX3G+Z2hzn9koR6oo7IATy3y653DSkLMkKmfVckkjP3Dhmx8s32BMxRc7Aym3XAwDTrTVjNMt14qhoX/bU5WATVWGC5wqFM/ZJdge4ED7H14715MkyA5Hg8eOF10C1VktguXOs6+quqDyQaAZbch4a0qQ8+EXTb2CbVQ/jVFF1J1+PIiYRjiXFtEkOYo2q202dws0yh7x8j/DyPtNLW1nTobV9mto2tQcq7OGM9EAsRmXffDHDzuRxWVUJMZCsINQWNqSz4mcLjDx0c/5JJcw5cXTJQC+r8iDTEa5sZUVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UYtwU8nSl4f+pvu1Cyhe+AkaSo2R6RBy/0GAoDQZLhM=; b=spwNYNid096Lw/W/L5lGET+qkaKJa0ude4n+5XVSQc4sIGj/yEtkerV87QeHLF/Wh7+pqtABdCKXhi8pTg8dhGeiiCjvc9eBnBFV4PxjCYJZr03ZWYaa2JSeCG9WyjSUp/ZlZCRmoLsDGMP70JdpEdX1NMYHmC4MQ3/SZn5tZOY= Message-ID: <6154b857-16b3-476b-a2cb-8837464dd4cb@oracle.com> Date: Mon, 7 Sep 2026 01:26:57 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug To: Igor Mammedov Cc: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, mst@redhat.com, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> Content-Language: en-US From: Dongli Zhang In-Reply-To: <20260903172835.0e253a25@imammedo> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PH7PR10CA0017.namprd10.prod.outlook.com (2603:10b6:510:23d::10) To CO1PR10MB5506.namprd10.prod.outlook.com (2603:10b6:303:161::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR10MB5506:EE_|LV3PR10MB7913:EE_ X-MS-Office365-Filtering-Correlation-Id: 0fa3682b-2ad8-4ea2-bfee-08df0cb9c9f2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|7416014|10067099003|6133799003|56012099006|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: zoNjfVWQUSRkk5N7Eh9feERoXAja1d2pn31XgfOMdkM7bJiWi8XAiEVM1JkfQqXo+iqUSRtQRZDITWC2rzPQp4zcnJ/4tz/bUDioMDsPnxmKVIL4HyG8V1gYIbjxRw7mcI0RJ7ghm7xdCm5eE2gPExCPACRq8dhVK7jy1tZt1g9WEa59qb2vdjTsU1VnIA4tzxg25duu7XatdD6Px4szIayP76Sqeu9ln4ZrL0sk7T9tnODz5YTxT3wcnjlr4/zJzP/j29qRiAd5QQ4SfITjCzAcJSiDcdJVEcUoU4cysTGb5PclkLxllLzHiVGMYn/Tty+YYuTlCXzAz/wWsLkvZIsIypaGXQV6BXpWJJ7wumj5SjD4YfbBRCQ5Klnko/MHC2A2D+kw1gvOXzjlvqlpAX4w2neoddGSPoB0FF9M3nhUK0ykTjXWAKX7wnh5rpr+hXUvw3gEQNvhEvDiMRMMyPim0O8bA8W4f1SW0s/2F9NylAwrMYs3cccWrlZzMF2TetKJPG9+t4SlM1KXMgZKEkN05uvEwpqlQQV0RE4BbeIG07iw5m6JTYgBq2LJgQwqfU/rG2XpdtOS+4mW+nFoksgumP/uiXJsWsXoJpxmF7aDHeHr1rggktLrGDpSs5Jpp5vD3pE5Q+ujk+wG/HNrDt+nocu9L0+2OaLjrYFLqf8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR10MB5506.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(7416014)(10067099003)(6133799003)(56012099006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SjBRbnppbjA0eE9RV2g4WXJPcHJOSHN6c2FZcmF3b1dtaThGNjBzcjlHT0p6?= =?utf-8?B?QzhYdWpGRzUxcyt0Wnl4NjVjWVIzNW1nY09wWE56dGpsalJzV05vaWhjUnBD?= =?utf-8?B?K3hSeEFoekE2TG9xMndZb1E2Zlk1UVBoTmwvandMQ2VMZEpseVhlMCtoaUZI?= =?utf-8?B?Zms2ZjRUY0lHUXRtaFZKYmxXOXI5bXNVeWJGNzJmUG9uUUVmV1l0cjhLQ3Nt?= =?utf-8?B?OFZFc0dTZkkzSS9Wb3pYYm5PNnhXVURYdzFQRjczRGpLK2hEVFY5cjdhYWw5?= =?utf-8?B?d1lYdFRyYks2aU8xeGl6Wnk0VGo3eVBDNmFKVkJ1dlBienZzLytzU1NFVW9k?= =?utf-8?B?OCszZXYrQ0hIWklRRHpIOENnWUUzdnFJcXVqeHV0Wnp0NlpwWVIrQ3JPcERC?= =?utf-8?B?Y0tjUDhnaGlZQk10RHhGMDk0NVRkRnl6TDBNS3AzYzFFdHR2Y1RpMHB2Mzl3?= =?utf-8?B?Uk1lQ0RBZEkrZ0g4eEcvUFc1cnJmLzFkNWpiOXNQRzFPV0E3cThMUG8wajRi?= =?utf-8?B?eDRPUkFvVk9iVGFodjFMRzdYZzY1dnBNMTFlZEwzS0JxRWJkVkZxbzladEdz?= =?utf-8?B?cTJ0WVd0NGlQRmZaVzFERmpZaTJmcnd0c3FqRTU2end6N3F0a1Q4TDJCUzBi?= =?utf-8?B?SXBXSkpZdTB6TElZWWk3V3ljVTBaRkhzdkNiRW91SStMSVB3NlQrc3FBemMv?= =?utf-8?B?b1ZoT0k1Nkx0WWxHM1F5ZWEyV3BuYmlDKzN4YlBoVWsyME84dEltUWVNTGk2?= =?utf-8?B?bTZObUFWcnBTYXVmbXFiSGJwaHIwSDR5MlFaK3hFbjl6SEdXNEt6RFZvd0lz?= =?utf-8?B?YjdTemtsM2JuSFlwRDVIdU81L3JmNy92U2FobWx6T24zTFJQUkg4NVVrdEt4?= =?utf-8?B?d2ZkTkNaV3QwdHhrR2JpeUoyNUVEdGJsTXcrZ2ViWUMxTFZsMnp0cEIxTkpG?= =?utf-8?B?QWc2cWRqS2JTTXNyS3h4TXJVVlZ3Yk53OVJKc3VMbnRpd0pUcjgxQXJ4V01Z?= =?utf-8?B?VnhycDh0aWQwT09QTHpVZFA4ZzlKN1F1NW0wbi80UVdhOGhJM0EyaHpjM29W?= =?utf-8?B?cVY1TC9ScmlYckdaUHJVQmUvZ1R1RVF5OUtwYVZ3UG9FOWtxaUdaOVdoLzlN?= =?utf-8?B?Ujc4NzhRcG02ejdpc3BDU3J3djU5aDlCam1UV2IrZWtCTFJzdWthSGh5Ykdx?= =?utf-8?B?YlZyTDZTNW1tNnBBL0JrdnRHYW15V0w3UTRHaElXU3AwbkhzaEtWeGhLQytE?= =?utf-8?B?NWdKY29tMUQ2cisrTzNKaHllMlhHcjVYYnJJWm56MG81dFhIL3NrZE1lVkNJ?= =?utf-8?B?VzNKYXJjQXFPK1RVc1J2NUtrUC9sdkNDVWQrQndYVkg4dnV0VkVkSExnOGtl?= =?utf-8?B?dVdsejJFWmQyNlVUZHYwOHA0Z0pMYkhXRTZZYVhmZGFFUy8ra3RpdHdkQ09y?= =?utf-8?B?am4yWlRqbzVMOVBEMXZSMlNRYVgrbjJSaVh1cGFPeE9hYndiL2tjM2ZKazVi?= =?utf-8?B?NWx3ZEJmMVh2cmRJK0VmbWhIelcrWU9FcGFFTUJ2RWhDcjdPNU9WYUl3N1h2?= =?utf-8?B?QlRyR1E1MHRGS2tyUFA0Z2s0SGlwZjZBbXFHQmJPV3BIdEZ4NFFQTGltYjI0?= =?utf-8?B?NU9zT2RzbCs1a3NHT0JvdW5uYldJL3M0bWhUeFZYc0p0OHI1VTA5b24zcjNW?= =?utf-8?B?UzcxaDRnemV2YWo3Nkl0UnpCRkFIb0lDdnNlRUZJZ1RhY1VKMVU5ZkVwUytP?= =?utf-8?B?ZzJmdGJ6bk1BVkRoUzJJWWRJbmdBK1pXa2tVbEVaSGFyVldIRmcvV0FBaGIv?= =?utf-8?B?STFNMVAxdFNnYTVQSGZsV1Y3KzF3MnNkZVdiZU9MM1h0azcwWHBUZ0M3Q3E5?= =?utf-8?B?ek5TWkJzRStFUkQwTWpKZ0c5Z0tJUWo1Q3d1TEhJdEF0TWNXVDE2Qjk3S0Jv?= =?utf-8?B?RldaSVl3VnBmcGNJVjRUNEIvRjNjRHB3cjNSbEVSSXpQSVVBSTgxZ3YycStw?= =?utf-8?B?NGZXZVNNRFpRTUVWNlJ6RzJ6bVZ6N1BmSEp5andFYTlHQWMwODc1WXRNbVYr?= =?utf-8?B?c0g4SEdNR2Q2Qy9oaTIzOTRVejBjeEZtcm4xTHRWUjZQdHhKUVhhTC9zTk5S?= =?utf-8?B?enF4b3lWZGZRZGo3dlZxbXZOb0lkNTA3M0FkTEwyYWtRaTNUQ1hBV2I0QnZS?= =?utf-8?B?dFgvL0dtdklURUVicU4yL2t6Ly9HZHpITDZGMXgxY0Jkb09FdHl5dDNSRHhB?= =?utf-8?B?UU4vS2VHeGZXeS9lYjc4akpqdDd0ZHpWOVRVSFVabmZ4WjBnNk8yODZSbXhN?= =?utf-8?B?dEtlOFNBamFSZVFZVmZuZURXckl5dXRpbUk5TlZIWWM2MzZwQ1M3RzVCMFox?= =?utf-8?Q?mEj5CaHZqN0RjzGk=3D?= X-Exchange-RoutingPolicyChecked: zfYFjaI07fmE59/p7htKdWeyXhutLBSqWLJLf7cQyGqkiXpuWhMvBVlv90KtfTTGiNKdt9bxosHnZrKT5gRe6efc5xbdleVYfWPSzHMO3QcgZM3vfauwPxbiLa4fRJuxyTmsIHQPgLH01tKzhMHCMvixqeD9rkhzM1/t99fBtLuLtb3jejnwCadCtN0a9VGxAIHaoiuSk18mf/z3x6qaeNYxGjQH+h54PiCNxd1reY7bIxgneSlH6mCm9qe/VTwnpYqsA+Jv5rwoMoADWaP3OeeF4DKvII+bCExDMOgnRrRRYWOPN+iRW8oG5xmAEJg/KQakntCAiYUkIft28/SonQ== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: lSgQka8/GCRrS87eGIrDHHNROFHNIY3szgkiQWRk5gNZwPqTdUd5r/AvE0rda0mb1XGFLZs9MiiVfYzQgjIa+Zu+iw9KET3GsFf2Ky/OfgUSP0xGv9+vLQUBncOQR/bwmZXbNGKL+y9lfFpnbuWl6cXO/tXYbS4TVpVvIucEK2fMZVRIkONYRtZvOweqOFPIZ4v5J2cmebKqfHGskBao4mslSBYGEXEeVcHAjd26ND4uzu/rvLxG9ffKWU0oIW5fjnQt2B/CopXTCwFQBmyKkjlFmFP+kPC5Oy2/eJC49tZhKph31Ir5fFNH0KAipwuKknikdZFsgN/ovF9145R9SQsSysQlHQ7yXXmUXYnQWGPPdGmaHX8AjhO68QsWrpzVNoIP73YJ+y4up3AvnKGZLQn5dDhR6W8lbVb8fKfhWdXPPQQR7EoY9/qYhGRkXRLBnNEBVW6s+Ci/sXNP/il30W66cuUC36lWIa6l+/tnmdrhG9q9i/nzta6anT5GOokYUg0JgaSpydx31rPtCy+cTZneazQfu+eVfmRWKKbULPPtAVWTmoBMhid975tcdKJVpG8hyb74doLubaFidnzeQ+5LFj/+TNei1xKfqjxR/EA= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0fa3682b-2ad8-4ea2-bfee-08df0cb9c9f2 X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB5506.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2026 08:27:02.5942 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QKtUHy5eo0y2EdqAFrnKSh+orzOEtgXl42yK3fN93UWSVwMpzcpGeik+0S4aXBJtTM+3XjyoFaRGwuusOxTppQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR10MB7913 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-07_02,2026-09-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 adultscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2609070091 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA3MDA5MSBTYWx0ZWRfXwwA8Lzh0RqZO LPg0Jwz1J9fJmoNVs5HPpyVK54XWGNcgokRjC2vv9afftnUBil/CoEtJ16q3XPOo0cYNKisRklS Mh1GiFmhVbwfyEpcNnYae7GXgNrE2Ag6YVvc6jKneuEIbI6NLL9WWgUp5Mrnb7kyhDK/VCK2eYI rcSWMsFuJG4k7CsMfAk5ix9sOV3xIQ74PPm2hTvXl1E7fygWpJy6bNJATuyZKU4U3GLpcMIb2JW 6xw+4zM7outluaknX4js/GAIo2dfNlUUjPUW3B3u8XgX6kHvNc3qp+1g5H2Y3694onAgX7sq5Wa gGNfYae/n3Rq+iVhcA9ipnkfApZ5T1ZVijqLb+FYzoM2+zgGR4tlRMcxD37j/UlPKzorpC06xEy CyJg06DJLdzIRPCFPfCGbV8g52VKk0QZeUY/yCmZdyzaHsu5VrIXk7hDxlktiYEE6wZaX1DNIJv 8ThvIloXYgOwo/7feRg== X-Proofpoint-ORIG-GUID: wsLlE6fb6CVKazHsKY7PDTTA65coNvGG X-Authority-Analysis: v=2.4 cv=d/DFDxjE c=1 sm=1 tr=0 ts=6a9e755c b=1 cx=c_pps a=WeWmnZmh0fydH62SvGsd2A==:117 a=WeWmnZmh0fydH62SvGsd2A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22 a=BqU2WV_vvsyTyxaotp0D:22 a=yPCof4ZbAAAA:8 a=urFVru_c1OEmphyQEPcA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=WmVTiCyuxqgg3mnwYu6p:22 X-Proofpoint-GUID: wsLlE6fb6CVKazHsKY7PDTTA65coNvGG X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA3MDA5MSBTYWx0ZWRfXyCV8cKTjqwFF bGsuH/apV1t/4oDVLMUnMiJi7pKmzdd2DB60UrqTnN0uOAAxc8/xEnzMDnHOqzjoZgUQMN6MwnX DtWBjqwYd+o9rsDW22SfjlHJ9QBFoowgA82xb29QyGVcBMEHZ3cZ X-purgate-ID: tlsNG-16d1c6/1788769661-F540B77B-D43FB720/0/0 X-purgate-type: clean X-purgate-size: 5227 On Thu, Sep 3, 2026 8:28:35AM -0700, Igor Mammedov wrote: > On Wed, 26 Aug 2026 09:15:47 -0700 > Dongli Zhang wrote: > >> On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrangé wrote: >> > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: >> >> Hot-unplugging a PCI device can require cooperation from the guest. For >> >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest >> >> eventually writes the ACPI PCI eject register. For PCIe native hotplug, >> >> QEMU notifies the guest through the PCIe hotplug mechanism and waits for >> >> the slot unplug flow to complete. Only after that completion does QEMU >> >> unrealize the device and emit DEVICE_DELETED. >> >> >> >> This can leave a device stuck in the unplug pending state when the guest >> >> does not cooperate. Examples include: >> >> >> >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is >> >> unavailable. >> >> >> >> 2. The guest is stalled and cannot handle the hot-unplug event. For >> >> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this >> >> for ACPI-based hot-unplug. >> >> >> >> 3. The device was attached to a slot that the guest cannot use. For >> >> example, a pcie-root-port only supports slot 0. If a device is added to a >> >> non-zero slot below a pcie-root-port, the guest may never discover the >> >> device and therefore may never complete the unplug request. > > all of above is actually expected, no (functioning) driver => no hotplug/unplug. > it's the guest problem. Once device it exposed to guest its life-cycle > not longer owned by QEMU. > > That's what one would see in real hw as well, you press eject button > but it will not do anything if OS doesn't process it. > also see comment at the end. Users are generally more tolerant of issues with real hardware. In virtualization and cloud environments, PCI hotplug is more commonly used for NICs and storage devices. Users are less tolerant of disruption or unexpected failures. > >> >> >> >> The non-zero slot case has also been discussed in: >> >> [snip] >> > >> >> Thank you very much! >> >> I see that the issue has been fixed. The ticket mentions the following. >> >> "What I am observing is that it seems when the slot ID != 0, the guest OS seems >> to ignore this and we never seem to hit ich9_pm_device_unplug_cb()." >> >> Based on my experience and evaluation, ACPI-based hotplug is more likely to >> encounter an issue where the guest VM does not respond to an unplug operation. > > I'm not sure it's a good idea to delete device when guest still thinks it's there > (you can make guesses on QEMU side if it's in use, how useful those are is questionable). By instrumenting the QEMU functions related to device hotplug and PCI initialization, we may be able to make informed assumptions. > > as far as I know, ACPI hotplug has no notion of surprise removal (pls educate me if it's not the case), > so I wouldn't do what you are proposing here at all, it's basically asking for disaster to happen. > And all this is basically for dealing with abused qemu flexibility. > > Please (re)formulate usecase and make it more clear as what is eludes me > no matter how many times i've read this cover letter. Here are some use cases in virtualization and cloud environments: 1. Suppose there is a QEMU user configuration error and a PCI device is attached to slot 1 of a pcie-root-port that uses ACPI-based hotplug. The device may not be detected or ejected. As a result, there is no way to detach it from the user's QEMU instance until the guest VM reboots. 2. For an unknown reason in the customer's guest kernel (Linux, Windows, or BSD), a PCI device may still be referenced by the guest kernel or its services. As a result, the guest never writes the eject register for ACPI-based hotplug, and QEMU cannot detach the device. The customer may blame QEMU for not removing it. A force-detach option could provide an escape hatch, with a warning that it may make the VM unstable or insecure. 3. Suppose a VM is stuck because of a guest kernel bug, such as a Linux kernel panic without a kdump kernel being triggered. The guest kernel is unresponsive. Force detach could allow the block device to be temporarily attached to another VM without resetting the currently panicked VM. 4. Provide a mechanism to demonstrate that force detach is unsafe. Otherwise, users may repeatedly attempt it and mistakenly conclude that QEMU is at fault :) Thank you very much! Dongli Zhang > > On positive note: > > What you can try to implement is native PCI-E support for surprise removal. > How hard that would be I don't know. And I would well expect if one deviates from > real hw expectations/configs (such as not 0 slot/partial func removal), > one would quickly stumble upon issues as that's not what what vendors write/test > drivers for. > > Even if it's not likely to be used in practice (guest still might not support it), > it may serve as test-bed for guest drivers. > >> Thank you very much! >> >> Dongli Zhang >> > From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:29:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:29:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410664.1641460 (Exim 4.92) (envelope-from ) id 1x3Uio-0007bL-SF; Mon, 07 Sep 2026 08:28:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410664.1641460; Mon, 07 Sep 2026 08:28:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Uio-0007bE-PK; Mon, 07 Sep 2026 08:28:58 +0000 Received: by outflank-mailman (input) for mailman id 1410664; Mon, 07 Sep 2026 08:28:58 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Uin-0007b8-W7 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:28:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Uin-00Elg9-Cl for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 10:28:57 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e75b2-2eae-0a2a0a5409dd-0a2a4505b020-38 for ; Mon, 07 Sep 2026 10:28:57 +0200 Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e75c7-4cb1-0a2a45050019-cddca520d1c2-3 for ; Mon, 07 Sep 2026 10:28:56 +0200 Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 686NS7Zj155496; Mon, 7 Sep 2026 08:28:41 GMT Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4ggbhuhmts-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 07 Sep 2026 08:28:41 +0000 (GMT) Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7) with ESMTP id 6878PVe6013773; Mon, 7 Sep 2026 08:28:40 GMT Received: from sn4pr2101cu001.outbound.protection.outlook.com (mail-southcentralusazon11012002.outbound.protection.outlook.com [40.93.195.2]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 4gh7atk5vy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 07 Sep 2026 08:28:39 +0000 (GMT) Received: from CO1PR10MB5506.namprd10.prod.outlook.com (2603:10b6:303:161::7) by LV3PR10MB7913.namprd10.prod.outlook.com (2603:10b6:408:20f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.6; Mon, 7 Sep 2026 08:28:36 +0000 Received: from CO1PR10MB5506.namprd10.prod.outlook.com ([fe80::da72:a0a9:5f18:cda4]) by CO1PR10MB5506.namprd10.prod.outlook.com ([fe80::da72:a0a9:5f18:cda4%6]) with mapi id 15.21.0382.007; Mon, 7 Sep 2026 08:28:36 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-oracle-onmicrosoft-com header.d=oracle.onmicrosoft.com header.i="@oracle.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2025-04-25; bh=GoWkOocCrR6kERzkLPXbFWN+S4QZEoZqyUBx6EmTCoI=; b= apysbmjR+oDlPsoumQ87OWxVFD9e3i6EtfcH2Na0Eb7P0+fEF/5LMdkxMllLcwSI 68B0kbNdsyzbr21Wo5s61B9ZuV/dfGeuD7uTjAOFPgLAIg4eDly0IPRGAP6R0Svv DvtK6JLnZ/VXyHDb75uNqZPgQCCvIDjufVBNdDC/v6MNQppLm0qa4SPnvtGDeIUG 6Pd1A8kJEegpnQUEyXv/MlR2KqHrw2T2JCaIM14rzQ3bHx1yp1paLr5wy7SgtN28 PBNY3gKWJcGJ6+v0MPPFSwlrXazygXXgQQv3T+FeSfz9DNP24mDtVWPyHU9WVZXZ 3i44lid2Kpv1dvUQByYA1g== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jgxkXQVBI9TianvL1S3g0RFDGVuVwXCbURYfz4KDNtdQY0SvgnZASzgQ7HtFnOULZheImkLs3AkXmkwRO2xOrUm4eDXf1s7+j2hwyzKQY4P+7A67iNoTjCxxcyOWLkWSVx2XfyZne43aaEyLmX5nz/plerNL0AtmVgYsKEX9df4Gq75e/H44kwi4x6u1f7Wx+6HDPoumLHKZV+EbBa7psHGGrvnLq2GBH24vNLjN5BvVYI1nHywxxMcyZiLYEkqRr777gmpr2jyxp+Xh8vjnzFWnrGdRrnz/KJJlJaIBSaKdpYcinrKy5Mh3hs9zkfnuG13EbrWDgJc7Hb/IkHgJjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GoWkOocCrR6kERzkLPXbFWN+S4QZEoZqyUBx6EmTCoI=; b=c1NgDiffIEKt2B+b4xWJsEwbH3eK7VEPRMJyxU4DN8Nd/AvdwR+uE5OLyvEtghrh7USTP2ADPnVGfvbiNtNCVRLs4kp5YHAPjskvEfds+a7T1weZumznzNXzyy8GbNoGlRGYN1fiS82ABE5RSPzwZiMt4BpA+rr6vXjgca3sMRgXcP+K5ZZiW+9SKM3M1QQ6eW+4C6WtB8nYu2ggujV+7JXPpvAW1tRY5P5x/bJVKP7CqJNHX0nTKVp0cw6D55ySobBwwfDuxtV5UOMey0uAXXm5VzI2Ff/zCKOKmMg9/rZvk1eQlCSu0Nby9fbMOl/QxH4dI2rVbmOqPOml8n7vxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GoWkOocCrR6kERzkLPXbFWN+S4QZEoZqyUBx6EmTCoI=; b=Dm0VC16r2r/cDyGfZhZz+qRxsjlCCd2aCfkEBzkzPEcC5t5XPoOgkk7CyOzrSHSd7AqwQZXr9lTLV1kEvXb7pfq2sESDAGdYjUcw0el+elUhLFbp8Xxlh9U8I+KewNegoy9T/1R0AL17/DPnsCCPNb+I6W+4oZUrqUmsZSriw5I= Message-ID: Date: Mon, 7 Sep 2026 01:28:33 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug To: Igor Mammedov , "Michael S. Tsirkin" Cc: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> <20260903160401-mutt-send-email-mst@kernel.org> <20260904130709.6769caee@imammedo> <20260904072052-mutt-send-email-mst@kernel.org> <20260904140824.177711f8@imammedo> Content-Language: en-US From: Dongli Zhang In-Reply-To: <20260904140824.177711f8@imammedo> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PH7P222CA0030.NAMP222.PROD.OUTLOOK.COM (2603:10b6:510:33a::13) To CO1PR10MB5506.namprd10.prod.outlook.com (2603:10b6:303:161::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR10MB5506:EE_|LV3PR10MB7913:EE_ X-MS-Office365-Filtering-Correlation-Id: a8ffa852-8bb3-4879-6ae0-08df0cba02fe X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|7416014|10067099003|6133799003|56012099006|4143699003|5023799004|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 20+8T+ZhIErWgQbtZ83DQvsv5PU11k2HXzHYEtt/XvuXf2K9BUoadMGlGAEBxzXNmsBDfhhXFJK7NZHPe5XO8bISURH7ob4KoXllTMpR9xV7dgUJzcVKT+2bhREj08DUavpaPoPU9qmqK10dPkDcJwR4a6IU33CyI1llC0ArrNzoy3FH+BUUqUy6oPI0z8hnYtVWxymKb0ldkQfDE/XI+VByY1qg+lfKWxBeqOj6BGIC/9/XFM0KxxiXnUcFC3WUEYM+SQvJFIBQgUMpZp/paA2YwcZGHAv+foyB9rjSbB6MuNtwP43oOZ17ij1KVeavAUypaPPyboHJp4QeI6aYYE25KNsUy0xLOvOnd3Udlc6rbKMqBlRXq1HXtXqQq4eYEj3AGkYY7JUzVKbUCY8z5woiE8cLOtaLWaJZKE4g6S7BAKVi9atTxP4d762yStc9U0Qu+dpAJwIFkIWx9qshDvBX/0jQBiTAXK+tdqR4N40rROkkkLQGz53yF+c9UHJB0wobBJNDtUJ8ZRz+KHOaBlobJB4f0RsinMav2OUlwMzvX0W+P6HT4o+YY4ZXRf5peKSj9rKgtEwh219R6ZztG3ABLDrlrYpbu5vX6wRylwIdU3+ksrpQZA0s6s+Vg07aO3AIoXJmRcvhvfMwiL8279igUZsWfVc7LPJc0+d9hDg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR10MB5506.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(7416014)(10067099003)(6133799003)(56012099006)(4143699003)(5023799004)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M0JzYWZ0Z2d3MlZGdnI4eVpDeFcvdG9xck1URklqNXJ4NGpzc3Bielo4VnMy?= =?utf-8?B?RUJoVzFSMHVISlZBczZxVy81WGROUmwzUzdzdlhHKzI1c2hHQVNSdTBXWmxo?= =?utf-8?B?bzcydDRqVVNlbkpmSW82UFpvaHNrenBTK2p6Ylk1RDNLODc0L2tiaFdqUTZI?= =?utf-8?B?ZVh1M3pDUFlRSEdYb3FmYVhUR2t2U1hrcW1WSk5ZYWxnNjNMWGE2UjRla25w?= =?utf-8?B?dlNFY21zQWdQM1VkT3RDT3BFdkx2SWxITVEzOWRIMndIK3JQMGV1STRjN3BF?= =?utf-8?B?MktWVXZ3U3g1U0U2ZUwyT3B2c3JYNTFFSHVKN1ZHWkpybHpPNzBXVjRtQURM?= =?utf-8?B?SnZhbWJlU214U1AvcXkxZ2lCSlNhVEJQdEN4OGRYNFpwbzZGNFBQbVBXc1BT?= =?utf-8?B?UEVXY0NTMk55dUlYZUg5MUZENXNjVlZva3ViZ2xLYjZ5bTNmVFVTcEpnNklU?= =?utf-8?B?WkV3VkdkWk0yUXFFaVJvanpFbkVrMWxaend6VWlXSEdQa3dEUCsxdFJDQ01C?= =?utf-8?B?Nkl6cDgyeExpa3lUZGV5R2grL3FMT0lHNnZsZldRSUFIYUp6dnJ1Q21jc0Yw?= =?utf-8?B?cVY0TlJWV1dIMWVsdk9QSmVJQTQ1S0FTemNzblNtNlFlNGpLVG1UeFA1alJS?= =?utf-8?B?YkxaRk5yVjRQOHhxb2xSUWdyNHJEWUdFRmhtYUZrb0hybGhKcHBIQm05M3l5?= =?utf-8?B?SlYyMW5UcFQ4Q2NLakhUdmxZVjF3bU5nUXFmSlFjQUs1ZXYyQnJsOVkrcko1?= =?utf-8?B?N0tudnlDVVBCRlcxbCt1V05FSW9yWERZTGxtT0dkZ2wyMUw2VXBuOHFWTDhZ?= =?utf-8?B?MHdpSGJnQmtSOWpwd2xVL09iS21XRk84Z3FONkV6SnZ6TG1MK3NMemhzZ2k1?= =?utf-8?B?RDAyY3lKdFNqck8xTkdFY3ZrTWQrc1dPdWpBdXRhY3NLem8waFBKbzBhQzVm?= =?utf-8?B?UzRsU1VRclJveE9pRUUrZUdwZklVMjBKTDVsMXcyV1VCM1BjOVNSeXU2Q3dP?= =?utf-8?B?dW1LdGpYby9keVNzQlhLa2FXdFR4UVNYTmpQei9mV2MxdWxMTkN1Q05uancy?= =?utf-8?B?ZzF1Y0NjeFBIU0FTOXBMZmdkRGg5WDVDSDR0MkJOVGxLY1Q0M0N0MHpIYzVO?= =?utf-8?B?SEpSRVh1R0F1SjR6emJtaW42aGl5TEVhOEUyS1MzVE9XSWJwWHpYbzJWRHk3?= =?utf-8?B?NWJXck5RQ2prSHZNd0NNVTZOcVZtZXdhb1I0QUdaNjkzMHNnMDIvVDR2aFgw?= =?utf-8?B?Vi9rZ3d3c1BWNmErREZOQnZXYkJnR2E2M3R1dGhtN1BlZmUwYlpMbUorTTht?= =?utf-8?B?M0NJeGpET2tsNEVFazd1RnBSRmozemxRT25adE9ad1NWNmoxZHdoZnhVTXBn?= =?utf-8?B?cXNqSkZ0ZnJCbnZWVzc5bExiSmF4UjRUaHNCT3NnRjNOMW4rS3FZQTZYZ1Yz?= =?utf-8?B?cEFzckRXV1QzcmpkemFEMHdTMVdhSGJDaHV2cGEzbVo1c3RlVlhUdlhKZ2x3?= =?utf-8?B?czdaZ01LbEN2K1dIK09KMVI4UkxNV0dRenJyZXJpKzJSSWRVYncwR2ZqMTRD?= =?utf-8?B?WXQ4cklieTRLbUQ5SnM3aUpmMWZ4VWxUTWZlelJ1ZENRMkdTcE9XSmJPaisz?= =?utf-8?B?MkdBdEZUMEZKa2NwQmw1MUJ1Z2xqLzRNQlFVa1MzeW8vZFJuTmdOY0lZMXF2?= =?utf-8?B?aGRubkk1Sk9FZGdsdlRLazZsdW1mdTF4b25oWlVvNXRrQ1pZSnY4aTB0S3NV?= =?utf-8?B?aldXdzg4OFpYeGxQYUFGRnlMQUs5M2ZaL1diL3J3cEt5NzFIL1dLVlFPQ3U0?= =?utf-8?B?SG9ycFZHOUVhekZMNHVxWlFjeGF2MHFaeExibFAxVzdoWTBiVll1VkM2bElG?= =?utf-8?B?eFlXd1R4b0hmdjVaY0NGdjY4RTJBWUVHNXdJMWhKN3JzcWJDNU16UG9ESWhM?= =?utf-8?B?ZGV3ZnBva3hTT1hxOHprc3FENklTaTg4UWs1VGlUZVRqTkJualJqNHB5WURy?= =?utf-8?B?SW9UVk5GczQwZEE3RlJEMkRUZXh4dGpqaUFyUG5mZmhVMW5aN2V6aUR3UnZr?= =?utf-8?B?eVUvbE5mNk5CQU1YTGxyOUZDZjk4RUtsSjZNdDJhdTg2cDBBL2JOeWszZzVD?= =?utf-8?B?S3FzU2FuV1VGb1hPUG9YSHk5ekhlZU5ZdXo2ZjFSOHUyWXp4SXZ3TzFtRUl6?= =?utf-8?B?TjNHWE0ydU5zS1JSdUpuY2RxdlBDd2E1cVM1K3FhZGdMWmlMMDd1SlY1bXl3?= =?utf-8?B?V0xqcXVMWHFoOFZoZUtDM0tsaU5GbXovay9BOFd2cnJ4YmlTWU4xdGlkcnZk?= =?utf-8?B?Y3QwMkc4VEtEUFpTODRDUUF6YkFlcE1sY2dUUTJJSFBBMHF4RmRmZz09?= X-Exchange-RoutingPolicyChecked: lPgq6YuUeK03QXo35Gq5HDwdJXWAfSq3NxWI0yoNZOiM3sR2j23UZCDcmZO1z4VqZ+qZXI+fZtFqfuJQ0BGRmYt5uNTUZ51qieRIqujdmTcFJzQzf4IIMxyVodR+2At2yGbZ02z/bkOlKO4ep9WyC8Lwl6nrdKaDtMjye+R8OsH9gE7nLDSkrvbm8h74vWqCuqgMcF25XzgaZMaULDoHdVwmkcDMtf9Wgoy96X0e/cescWEiGYE6KNZnhFKFWb4y/KHePOzXoQ9ghVnahI9bcRFl/jpZcpCCS41qnHzRBQRo1zlw/so7CJeQu/HZBfnMxaxq0hAdArwAfqDE9HsQkA== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: dORxooCUcRh8LExhKuOezGRxw3GorDuN7VhdEwU5Z+9bQaYdn91kkMZtjQiIU4mxy4Do8Q7T0fW36+OpCAsmyNwIQrLR7s2JcZ9ZDIgV1LNIJoo0MQNpEJVxafFS5FbUEfDyttN2RuayDGfPgyTrfA7Cn9mwRODThQ9bc1j1EFGIl1a/b77UF+m9kZSumcXONSTCCchq7sYdxszLCoLScn074f7gz1ilLYoaQVBVZFWJUDNY5pPFMkuxZ8X9bCKv97ESd7P2EpMh/67QiLOcLqp85Vv9nIbocCFMPVgL0hjCHf9XDOs/0w1T0rKGdxaotsJH86uXIqU2Grv/zhKj2q4V0SDSJOZH8djTZ5dy6OgpM1UbYNKpvoa2nDoMWsdOYOyhL7l3bLwA1EeUgX/Z07Mb/sAeoPab3nVUPh4jWXK1jMu4TMCsti+ZyZqTO2dvGVY2y08EyiECOAFjUG6U2cFCm0abgsAYIKrjzcu1xdu6Rh6kFZylPpH1p75P+S7LiLrBQ361irhcVZuF+rquE7HvuBslOjkztfq/yVUU3SkGMQRSfdaG7Uy5JTMd23HwEN4vq3GO3T6XyJ233NmzttkIQJKfEeL8dqQXcoVrrdk= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: a8ffa852-8bb3-4879-6ae0-08df0cba02fe X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB5506.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2026 08:28:36.4361 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: CrVHTw2cLdK18jAJ9BDfdHDwDkxE+b4nltCMUvgPh4WeT3LlEUZZD7N4H0K+R2MPDfRyzxlxfUT/H6KCPeCAzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR10MB7913 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-07_02,2026-09-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2609070091 X-Proofpoint-GUID: s2gACWvghr1jGpjJpTwv8fA1zrMakTkx X-Proofpoint-ORIG-GUID: s2gACWvghr1jGpjJpTwv8fA1zrMakTkx X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA3MDA5MSBTYWx0ZWRfX2zmlbpi9oHKm zakFWOSeFBu1Y2RUjLQqRThWJU/uKCtMA/9vVEtTXomeboMvBv+TawjIyYUVjgomrZY9ERxLwT5 VYJemWb0Eatengxl2+//r0GgsmVQy5ObLAzaGETZNiAoPQSyc72n1ahHK6sXkbLYDgRTA3ljKLN KkQ+OUJ4qtfnDyghmIaBJ4cP3sJSeyxbyAvF5uv1cdr1cMflhizNmuxCMDH0iXgjHr9EDY/I7Gr Ev1DhBurO/rewfZ7bBtghWXRnYMUTiIoDGy9RSHA8LzVUBwicPeAG+LkMPZ4wOfLq+0Yv7bDDH8 r+ViY/nR3rlbCMoMVvU4C89Z0R+64vPK7CAc1svVQhS6vO3pTHGEMp+BzsFPuOV95qKjePViD9q dt0Wnzjq5fS6Nxy82vynrDRVwgtzDTi7Xwqpn7s9MxMQFL0mOUjpbl8cvMGXHTZBmFTvnykUvZ8 QkA3BNe85qrIjENxqg7C1ESpLuDlvYh8N0+w6XNs= X-Authority-Analysis: v=2.4 cv=S4HpBosP c=1 sm=1 tr=0 ts=6a9e75b9 b=1 cx=c_pps a=qoll8+KPOyaMroiJ2sR5sw==:117 a=qoll8+KPOyaMroiJ2sR5sw==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22 a=RD47p0oAkeU5bO7t-o6f:22 a=20KFwNOVAAAA:8 a=yPCof4ZbAAAA:8 a=ty4yZqpHH24XlNHnSPkA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:12102 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA3MDA5MSBTYWx0ZWRfX4usfcJ1Sx0WX hxpc8Jcd1Hwn0LXGmoWfO1HcPPpUunHgVQcODe6rAte2AYr65hbM5kPrCb0RzReOMXnNyyKKLfb 9SXTOQhX5hSFShhl6uCD+JatGnGjGXfL/zn6Lkw4Ajg6xAFyDkuf X-purgate-ID: tlsNG-c201ff/1788769737-2491C2A1-B1E4E7FC/0/0 X-purgate-type: clean X-purgate-size: 8003 On Fri, Sep 4, 2026 5:08:24AM -0700, Igor Mammedov wrote: > On Fri, 4 Sep 2026 07:22:10 -0400 > "Michael S. Tsirkin" wrote: > >> On Fri, Sep 04, 2026 at 01:07:09PM +0200, Igor Mammedov wrote: >> > On Thu, 3 Sep 2026 16:17:20 -0400 >> > "Michael S. Tsirkin" wrote: >> > >> > > On Thu, Sep 03, 2026 at 05:28:35PM +0200, Igor Mammedov wrote: >> > > > On Wed, 26 Aug 2026 09:15:47 -0700 >> > > > Dongli Zhang wrote: >> > > > >> > > > > On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrangé wrote: >> > > > > > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: >> > > > > >> Hot-unplugging a PCI device can require cooperation from the guest. For >> > > > > >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest >> > > > > >> eventually writes the ACPI PCI eject register. For PCIe native hotplug, >> > > > > >> QEMU notifies the guest through the PCIe hotplug mechanism and waits for >> > > > > >> the slot unplug flow to complete. Only after that completion does QEMU >> > > > > >> unrealize the device and emit DEVICE_DELETED. >> > > > > >> >> > > > > >> This can leave a device stuck in the unplug pending state when the guest >> > > > > >> does not cooperate. Examples include: >> > > > > >> >> > > > > >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is >> > > > > >> unavailable. >> > > > > >> >> > > > > >> 2. The guest is stalled and cannot handle the hot-unplug event. For >> > > > > >> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this >> > > > > >> for ACPI-based hot-unplug. >> > > > > >> >> > > > > >> 3. The device was attached to a slot that the guest cannot use. For >> > > > > >> example, a pcie-root-port only supports slot 0. If a device is added to a >> > > > > >> non-zero slot below a pcie-root-port, the guest may never discover the >> > > > > >> device and therefore may never complete the unplug request. >> > > > >> > > > all of above is actually expected, no (functioning) driver => no hotplug/unplug. >> > > > it's the guest problem. Once device it exposed to guest its life-cycle >> > > > not longer owned by QEMU. >> > > > [snip] >> > > > > > >> > > > > > If we actually wanted this to remain a warning, then that shutdown >> > > > > > crash would need to be fixed. >> > > > > > >> > > > > >> > > > > Thank you very much! >> > > > > >> > > > > I see that the issue has been fixed. The ticket mentions the following. >> > > > > >> > > > > "What I am observing is that it seems when the slot ID != 0, the guest OS seems >> > > > > to ignore this and we never seem to hit ich9_pm_device_unplug_cb()." >> > > > > >> > > > > Based on my experience and evaluation, ACPI-based hotplug is more likely to >> > > > > encounter an issue where the guest VM does not respond to an unplug operation. >> > > > >> > > > I'm not sure it's a good idea to delete device when guest still thinks it's there >> > > > (you can make guesses on QEMU side if it's in use, how useful those are is questionable). >> > > > >> > > > as far as I know, ACPI hotplug has no notion of surprise removal (pls educate me if it's not the case), >> > > >> > > why would it not? >> > > >> > > how do you think you can pull a laptop out of a dock? >> > > I expect bus check + _STA and config space saying it is gone >> > > will do exactly that. >> > > >> > > >> > > Here's linux code: >> > > static void acpiphp_check_bridge(struct acpiphp_bridge *bridge) >> > > { >> > > struct acpiphp_slot *slot; >> > > >> > > /* Bail out if the bridge is going away. */ >> > > if (bridge->is_going_away) >> > > return; >> > > >> > > if (bridge->pci_dev) >> > > pm_runtime_get_sync(&bridge->pci_dev->dev); >> > > >> > > list_for_each_entry(slot, &bridge->slots, node) { >> > > struct pci_bus *bus = slot->bus; >> > > struct pci_dev *dev, *tmp; >> > > >> > > if (slot_no_hotplug(slot)) { >> > > ; /* do nothing */ >> > > } else if (device_status_valid(get_slot_status(slot))) { >> > > /* remove stale devices if any */ >> > > list_for_each_entry_safe_reverse(dev, tmp, >> > > &bus->devices, bus_list) >> > > if (PCI_SLOT(dev->devfn) == slot->device) >> > > trim_stale_devices(dev); >> > > >> > > /* configure all functions */ >> > > enable_slot(slot, true); >> > > } else { >> > > disable_slot(slot); >> > > } >> > > } >> > > >> > > if (bridge->pci_dev) >> > > pm_runtime_put(&bridge->pci_dev->dev); >> > > } >> > > >> > > >> > > so weirdly it wants bus check on a parent bus, otherwise it will >> > > not trim devices? probably a bug, but easy to work around. >> > >> > Modern docks would use native pcie surprise removal path. >> > >> > As for ACPI, my old laptop, had an unlock button => _LCK >> > and that relied on OS processing ACPI events, not so surprise. >> > >> > There might have been ACPI/hybrid docks that did surprise removal, >> > but then one need to find one and model after that instead of >> > just blanket force removal. (likely out come would a doc device >> > support only, not an arbitrary device removal) >> > >> > (not the case described in this series, though. hence my request to clarify usecase) >> > >> > from what I see in spec there is _RMV method that says that device >> > supports surprise removal that can be used for devices that support it. >> > However I would hesitate very much to blank apply it to every PCI device. >> > (it's not even realistic to ask for proving safe tear down across various >> > drivers and OSes/versions) >> > >> > Rather than a knee jerk treatment of misconfig consequences, >> > I'd rather see patches to prevent misconfig in the 1st place >> > (subj to deprecation but doable). >> > >> > As for the cases where OS mis-behaves (apcihp thread starvation,...), >> > fixing guest to follow hotplug contract is a proper place to do it. >> > >> > On QEMU side we have it covered as well. If unplug was not processed, >> > mgmt is free to repeat action. >> >> >> Sorry if I am unclear. I just meant that it looks like we >> can support surprise removal with ACPI just by reporting >> bus check events on the parent. > > maybe, but that ain't SPECed and might be OS specific. > > The way I've read the cover letter, that won't work for mentioned mis-config cases. > Also what would happen on bus-check 'cleanup' would be a lottery. > hence I'm for being safe here. > > It's better to implement native PCIE surprise removal if that's really needed. > Suppose many x86 users use q35 and pcie-root-port. Since commit 17858a169508 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35"), ACPI-based hotplug has been the default for q35. arm64 still uses native PCIe hotplug. Therefore, in my opinion, it is more crucial to support ACPI-based hotplug than native PCIe hotplug. In addition, native PCIe hotplug can still detach a PCI device even when the device is erroneously attached to slot 1 of a pcie-root-port. Although surprise removal is not explicitly specified and may be OS-specific, my understanding is that it involves two steps: 1. Force-detach the PCI device. 2. Use a mechanism to notify the guest VM that the device is no longer present. Therefore, may I assume that this can address the use cases mentioned in the cover letter? Thank you very much! Dongli Zhang From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:41:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:41:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410673.1641469 (Exim 4.92) (envelope-from ) id 1x3Uuf-0002RV-0Y; Mon, 07 Sep 2026 08:41:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410673.1641469; Mon, 07 Sep 2026 08:41:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Uue-0002RO-To; Mon, 07 Sep 2026 08:41:12 +0000 Received: by outflank-mailman (input) for mailman id 1410673; Mon, 07 Sep 2026 08:41:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Uud-0002RG-Vm for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:41:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Uuc-00CAzs-LN for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 10:41:10 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e78a4-e002-0a2a0a5209dd-0a2a45068bbe-8 for ; Mon, 07 Sep 2026 10:41:10 +0200 Received: from [52.101.46.51] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e78a4-195a-0a2a45060019-34652e3352da-3 for ; Mon, 07 Sep 2026 10:41:10 +0200 Received: from SJ0PR05CA0150.namprd05.prod.outlook.com (2603:10b6:a03:33d::35) by CYXPR12MB9277.namprd12.prod.outlook.com (2603:10b6:930:d8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Mon, 7 Sep 2026 08:41:01 +0000 Received: from MWH0EPF000A6732.namprd04.prod.outlook.com (2603:10b6:a03:33d:cafe::a1) by SJ0PR05CA0150.outlook.office365.com (2603:10b6:a03:33d::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.6 via Frontend Transport; Mon, 7 Sep 2026 08:41:01 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MWH0EPF000A6732.mail.protection.outlook.com (10.167.249.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.5 via Frontend Transport; Mon, 7 Sep 2026 08:41:01 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 7 Sep 2026 03:41:00 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 7 Sep 2026 03:41:00 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Mon, 7 Sep 2026 03:40:59 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EUd2HDnD1uOEDYX48Xc+iJhXXvWyc31ksSIQ53SOsvPLdtwVpTJSNH17Qu3fggSmJznUbQBiw6bU7HtES5w+Pj+kCMdt8xcfQ9gEJY7yuQSKk/mrfZFcVABzgpll6YZUeF1ygtIeQjA9eUTu43ctq0yeBm+j3vB3x84Volw3zEt183xjkC18uljmqFlUx9Wg2cwmOOa8uUjp0h8yeQ68Oajq7Vessg8Ll5ihVk00uhaNcu/bUb+7Nb+2JFBnPv1X9W81l3hqQQIGcBizgGquxriIdkvNdn15+ERne4LA0kSEo3o6S9Ofx7ydti6BdIXdLvjtw/NfWOMZ0TtnIH14WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5rcyr3XZVhs0K1/6bEO+VbaLgOLMUp13wtOdx6oM/dc=; b=AWXM18w9PLRlcOJAXUEUWrvo4F4KRf/7kTR686Gv9wWyOxyRcAlHoJB5Jrx988uebn4GYRv8FRR7Pd6d2Tj5Ir/4TpXYC45qw7CS3MdajJhnyufFcwBwkr+9poDudCN89l6Uzt8bnsYA90dWkMNBNHTUW6C/cz0VVQ4lHuppL21C17gj4ZI1E/571QP11EOHc0mhrGsJ38eBsKDEbDp16JTpVrMEuenAcZ8WwlwRFI6YmpphoM9FdnNurxRsH5vlRSy9xY3oBDjm1Ng2T+0ojpKYKdj+aNOWbgnLgrz6tppMw1mhhd+8bDLTAG9c4DNFgIJqp/Ad1EUrup0LL0kPwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5rcyr3XZVhs0K1/6bEO+VbaLgOLMUp13wtOdx6oM/dc=; b=rXLNncuGsH1q4J6jjCF2QIcEDxmyHxs2EIJsi3cxmiNs/xQW4NOH645MD8kotxjAiMbaVyxa72OVcimkmYkBvcfr8jhLLj3acozfRhyXDlmLJpXuqB2xRAkeoXP4sEigghmamWITxvj7nIYeQNIe7CSHyfw2/sK1qsTwGWlaYcI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <4c8bc3eb-44a3-4c27-aa15-8dfa80faf5e4@amd.com> Date: Mon, 7 Sep 2026 10:40:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/arm: smmuv3: Add support for removing devices To: Mykyta Poturai , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Rahul Singh , Oleksandr Tyshchenko References: <56e7734d60ad8cca4279a71b4beb21ca51250386.1787303836.git.mykyta_poturai@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <56e7734d60ad8cca4279a71b4beb21ca51250386.1787303836.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000A6732:EE_|CYXPR12MB9277:EE_ X-MS-Office365-Filtering-Correlation-Id: 23bf5be2-8f84-4dd8-34ab-08df0cbbbf33 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|82310400026|36860700016|1800799024|376014|10067099003|6133799003|22082099003|18002099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: ROIclYKy5gdV7/a5f4gYYGZ4oe2odKpeOip7ETZmEaQPzc3VthSFGhtULWE8fRkrlR7r3EWMpEJntMWYdWWdC9MmqVsUHMVb3rjEH8hW2NTvhU7oiO6MwmwvsTW+dpojpSQD/V/JaNSGPr7toRkWJxUZz5i+sMWkPksmpPoBTOsG6zp4wziZekmoP2LHjnz6IFJHaYw5gETxS0y2YC+3Cl89TscD6QGko2WXVdY1aKQF7fysFHMfVsXUYS7SWdnmX0qOSEsLLdcjMuk9aA/iMkVbfWZpW68GVWZUdJqnlTrkdNG87fyiADXou+80Jto+IdF6hR++L8EkmtyTwoKbnye4mCQCon1JW6wpXGkCD70YpQ85hJCtMN/Whg/OSqg/smoEegZzJQFsMYSk4LsdDSkMr2FhcwU32zVIlU7pBdqcqah7AkzNRjhLbDoYo5+o2uqhUJ4lpKvRNmDv9bVbtq7bSao313MG+OCpQ5YHq+G2X5tVt1URvEnzxjlqBlkdmTPMNYPn9d/npXiBJzfHRLOq4659fnBPOOy9ZC5/twGJGZVQL1C57VzTHK8GcKio+wgnQ8LqueteedsRDAqMqcQaxqQu8yH8KwT11+nxTvnkioAYCAHmxfkm5mC9n5HsntOgXJAvTB1cfvKoCQu4HQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(82310400026)(36860700016)(1800799024)(376014)(10067099003)(6133799003)(22082099003)(18002099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Ryqblx9Bccay9Lpphsi0m/d6dPI0bqvGpi1vaOLHvt4lqUiQvYA7F+gBUz0/zX/VAqJuH6crmvQ9Yh3EdQahJtLYD9I1JL7s9qRkwMSihxMEF0M3npDoZcHdRygz5YC7Dz82yhEQ445jFxYeBA+h8g8yBItXAlyOQpTQNZjUey1SXSt2FoMhz85I/mWQk3atYW/cPs1kMcNueu17bT31qoLIWwYHpOt55oLD05tNfRm9P4sKty3Zo7aSTTe3d0FlT4nUOhDeMvSMxLE1NbBUBENqaX7hxv7YVRJWVq66Vf2dgE8qhXP/TN/d1d2pm+FQFATKXzE6AOu5GCbJjZIA3lTEAmVol/Vbc4Mj8FdSXdTfdrwiaeGDeZFob+QgaDn5BJo7rfIjG+sRAvaCgmvYo2W43JnkBxxfWk4wkvgodv5YQ1faptbUhJ8YJC9LuPiU X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2026 08:41:01.5279 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 23bf5be2-8f84-4dd8-34ab-08df0cbbbf33 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MWH0EPF000A6732.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9277 X-purgate-ID: tlsNG-16d1c6/1788770470-F4A0477B-CF78D7D1/0/0 X-purgate-type: clean X-purgate-size: 4668 On 25-Aug-26 09:39, Mykyta Poturai wrote: > Allow for removing devices from SMMUv3. arm_smmu_deassign_dev handles > most of the work by disabling ATS and zeroing STEs. Additionally, unset > the dt_device_is_protected flag and free no longer needed smmu_master. > Free iommu_fwspec for PCI devices only, for DT devices it is handled by > generic IOMMU layer. > > Rework dt_device_set_protected to accept a boolean parameter, update > callsites. > > Signed-off-by: Mykyta Poturai > --- > > Tested on QEMU with SRIOV series[1] by repeatedly enabling/disabling > VFs. > > [1]: https://patchew.org/Xen/cover.1772806036.git.mykyta._5Fpoturai@epam.com/ > > V3->V4: > * s/u8/uint8_t/ > * assert pcidevs_locked > * assert deassignment is only reachable by PCI > * fix build error with HAS_PCI=n > > V2->V3: > * free fwspec for pci devices > * remove testing note from commit message > > V1->V2: > * check for phantom functions > * simplify pci/dt device split > * improve error handling > * don't try to free master for unprotected devices > * rework dt_device_set_protected > --- > xen/drivers/passthrough/arm/ipmmu-vmsa.c | 2 +- > xen/drivers/passthrough/arm/smmu-v3.c | 77 +++++++++++++++++++++++- > xen/drivers/passthrough/arm/smmu.c | 4 +- > xen/include/xen/device_tree.h | 5 +- > 4 files changed, 82 insertions(+), 6 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > index fa9ab9cb13..0648f9b407 100644 > --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c > +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > @@ -1367,7 +1367,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) > } > > /* Let Xen know that the master device is protected by an IOMMU. */ > - dt_device_set_protected(dev_to_dt(dev)); > + dt_device_set_protected(dev_to_dt(dev), true); > } > #ifdef CONFIG_HAS_PCI > if ( dev_is_pci(dev) ) > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c > index bf153227db..3578f36259 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -1493,6 +1493,80 @@ static int arm_smmu_assign_dev(struct domain *d, u8 devfn, struct device *dev, > static int arm_smmu_deassign_dev(struct domain *d, uint8_t devfn, > struct device *dev); > > +static int arm_smmu_remove_device(uint8_t devfn, struct device *dev) > +{ > + struct arm_smmu_master *master; > + struct iommu_fwspec *fwspec; > + struct domain *d = NULL; > + > + fwspec = dev_iommu_fwspec_get(dev); > + if ( !fwspec ) > + return -ENODEV; > + > + master = dev_iommu_priv_get(dev); > + if ( !master ) > + return -ENODEV; > + > +#ifdef CONFIG_HAS_PCI > + if ( dev_is_pci(dev) ) > + { > + struct pci_dev *pdev = dev_to_pci(dev); > + > + /* Ignore calls for phantom functions */ > + if ( devfn != pdev->devfn ) > + return 0; > + > + ASSERT(pcidevs_locked()); > + > + d = pdev->domain; > + } > + else > +#endif > + { > + if ( !dt_device_is_protected(dev_to_dt(dev)) ) > + { > + dev_err(dev, "Not added to SMMUv3\n"); > + return -ENODEV; > + } > + > + dt_device_set_protected(dev_to_dt(dev), false); > + if ( master->domain && master->domain->d ) > + d = master->domain->d; Given the comment below and `ASSERT(dev_is_pci(dev))`, `d` can never be != NULL in DT case, so these two lines can be dropped. > + } > + > + if ( d ) > + { > + int ret; > + > + /* > + * For DT devices, iommu_remove_dt_device() returns -EBUSY if the > + * device is still assigned, so d is always NULL on the DT path. > + */ > + ASSERT(dev_is_pci(dev)); > + > + ret = arm_smmu_deassign_dev(d, devfn, dev); > + /* This should never fail because we already checked the domain */ > + ASSERT(!ret); You checked the domain but the assignment takes place before `arm_smmu_attach_dev()` can fail in .assign_device, so I think it's still possible and the ASSERT should be dropped. > + } > + > + arm_smmu_disable_pasid(master); > + > + dev_info(dev, "Removed master device (SMMUv3 %s StreamIds %u)\n", > + dev_name(fwspec->iommu_dev), fwspec->num_ids); > + > + xfree(master); > + dev_iommu_priv_set(dev, NULL); > + > + /* > + * For DT devices the fwspec is freed by iommu subsystem, but for PCI > + * devices we need to free it here > + */ > + if ( IS_ENABLED(CONFIG_HAS_PCI) && dev_is_pci(dev) ) No need for IS_ENABLED here. > + iommu_fwspec_free(dev); Spaces but should be tabs. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:56:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:56:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410686.1641479 (Exim 4.92) (envelope-from ) id 1x3V8t-0004SN-5N; Mon, 07 Sep 2026 08:55:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410686.1641479; Mon, 07 Sep 2026 08:55:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3V8t-0004SG-1l; Mon, 07 Sep 2026 08:55:55 +0000 Received: by outflank-mailman (input) for mailman id 1410686; Mon, 07 Sep 2026 08:55:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3V8r-0004S8-Fd for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:55:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3V8q-007t7b-3V for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 10:55:52 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e7c10-2eae-0a2a0a5409dd-0a2a45068424-26 for ; Mon, 07 Sep 2026 10:55:51 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e7c16-195a-0a2a45060019-aa0a817c99cf-3 for ; Mon, 07 Sep 2026 10:55:51 +0200 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-687-pH3RCcqBM0-dUY0gV0E7gg-1; Mon, 07 Sep 2026 04:55:49 -0400 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-47f4bff865cso1763819f8f.0 for ; Mon, 07 Sep 2026 01:55:48 -0700 (PDT) Received: from redhat.com (IGLD-80-230-79-236.inter.net.il. [80.230.79.236]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883c5bc5sm28593436f8f.24.2026.09.07.01.55.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Sep 2026 01:55:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788771350; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z5bsH4JVOIdSG44t0GSgJUXlu2Xpc7hHFUMLKgNg5Gg=; b=VvKIO4SQ64CWg7Dlsie7LC00If58JGEBJ10v7R13ocdlJ5Zi1LaJeaaUDsS/0uGEJPc4v6 FQ6PQE+A5IwkjszpouY32jYpGd7bdSlWMpzL4+/uOMxO41ArwZCHuDCF8IqUoJOkfaogRA Zi4L4JPZgYB4yLjmbQnk4yBEE/mSXZw= X-MC-Unique: pH3RCcqBM0-dUY0gV0E7gg-1 X-Mimecast-MFC-AGG-ID: pH3RCcqBM0-dUY0gV0E7gg_1788771348 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788771348; x=1789376148; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=z5bsH4JVOIdSG44t0GSgJUXlu2Xpc7hHFUMLKgNg5Gg=; b=MadrBfZN6Y4Svz2uuAUlDJPLdm6RjZeFMaWaahK4b919zu1xk0M+ZusEW0vwC1Gx0+ uvtK/4in3IXRMfhLEZEP3b/96da4Lz92f3FpLkcMJ1zadOR/yJce4kCGslghrg5GOg/p cCdXZ++BCH5HlDEIUGrBWUTfzeNycBsnG0L+hx6KBJeJ5dR9MI1p2PROoS7aYnWAqww4 h2NdlVWNmeXwZyYe3HxlJujuW+sM7gmOE+OiKxzJiDCxiunG1NbYUK9Rhw5fmMnVcJM1 +2wBrW7g/xauEamoRXwNkwIjLhjH/pfCxrjNHXSrLCWn9ZO01IPE30Hh9bHS5O7HZm3V KW0A== X-Forwarded-Encrypted: i=1; AKwUvByulgY7aQMSWFsdilGPcTdcxMpU7rWvCF0i3e7de3NKVDn2kjjGo9va9mHRdMDutDkhS0SWaGf5Cxg=@lists.xenproject.org X-Gm-Message-State: AFuF++mpOD+So4wLCLvkuM2lEplZtNCjfcoCuRaV1OPTDw8RIZXG2vMi LssyaDs85m9Oc94SlSvpq8rwtrnHo6A/izu9SDtHnopJWJSkXPq5WlJAcXcGEzLCnIITNR6md89 PecE1loF1rjKVpO2GMgSeubmZmysmB+hT4tSPdKTiYd5zm+E/BYn9gAUMplYpiyNgDvl1 X-Gm-Gg: AYBFou2otCaZjPeJBPO/gKnH8UEvWgqkq9YDl0MHbqBKS2/UNTk+nzEApahe8fScYd+ bbmrSK2+v25+Q5xfAaNbjB9zXraZqKew5DkBU1ZXG/AVAXMTwhQQ+Nx5dBEhNhKjN00pqC5Lh/g UDmC3/64H3cyyqWWjABt2eG2jCwwiFmI9TBHQ+So1kWv3xOr8PFwdUI73M7kzUEalFYQTfZuNC9 TwN1lzeFOk2zJ8weK0tORVYJ2IaiMIA0gVTzTQy7RtSgbsKUDyXwOaqBsYwrMDvleIzprqb48OP dwpOtIUCiyWpL7+W/wtvSMJuGbWHctbgXUUscHjIS/1/X9yxCjLFtWMYLe4RBjhng+RRrd4XEYO NcekWonYK10KkCs178LK5aJs= X-Received: by 2002:a05:6000:1acb:b0:485:8b5d:96d with SMTP id ffacd0b85a97d-4858b5d0d2dmr33824029f8f.19.1788771347747; Mon, 07 Sep 2026 01:55:47 -0700 (PDT) X-Received: by 2002:a05:6000:1acb:b0:485:8b5d:96d with SMTP id ffacd0b85a97d-4858b5d0d2dmr33823972f8f.19.1788771347225; Mon, 07 Sep 2026 01:55:47 -0700 (PDT) Date: Mon, 7 Sep 2026 04:55:42 -0400 From: "Michael S. Tsirkin" To: Dongli Zhang Cc: Igor Mammedov , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug Message-ID: <20260907044608-mutt-send-email-mst@kernel.org> References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> <6154b857-16b3-476b-a2cb-8837464dd4cb@oracle.com> MIME-Version: 1.0 In-Reply-To: <6154b857-16b3-476b-a2cb-8837464dd4cb@oracle.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EtH5O6Ew4p8Dq20iqk_OScyHyLNmcNRZFDDy31Cd6fA_1788771348 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1788771351-1FACA77B-E0EC0B94/0/0 X-purgate-type: clean X-purgate-size: 6402 On Mon, Sep 07, 2026 at 01:26:57AM -0700, Dongli Zhang wrote: > > > On Thu, Sep 3, 2026 8:28:35AM -0700, Igor Mammedov wrote: > > On Wed, 26 Aug 2026 09:15:47 -0700 > > Dongli Zhang wrote: > > > >> On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrang wrote: > >> > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: > >> >> Hot-unplugging a PCI device can require cooperation from the guest. For > >> >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest > >> >> eventually writes the ACPI PCI eject register. For PCIe native hotplug, > >> >> QEMU notifies the guest through the PCIe hotplug mechanism and waits for > >> >> the slot unplug flow to complete. Only after that completion does QEMU > >> >> unrealize the device and emit DEVICE_DELETED. > >> >> > >> >> This can leave a device stuck in the unplug pending state when the guest > >> >> does not cooperate. Examples include: > >> >> > >> >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is > >> >> unavailable. > >> >> > >> >> 2. The guest is stalled and cannot handle the hot-unplug event. For > >> >> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this > >> >> for ACPI-based hot-unplug. > >> >> > >> >> 3. The device was attached to a slot that the guest cannot use. For > >> >> example, a pcie-root-port only supports slot 0. If a device is added to a > >> >> non-zero slot below a pcie-root-port, the guest may never discover the > >> >> device and therefore may never complete the unplug request. > > > > all of above is actually expected, no (functioning) driver => no hotplug/unplug. > > it's the guest problem. Once device it exposed to guest its life-cycle > > not longer owned by QEMU. > > > > That's what one would see in real hw as well, you press eject button > > but it will not do anything if OS doesn't process it. > > also see comment at the end. > > Users are generally more tolerant of issues with real hardware. > > In virtualization and cloud environments, PCI hotplug is more commonly used for > NICs and storage devices. Users are less tolerant of disruption or unexpected > failures. Simply put, surprise removal exists in the hardware. Emulating that makes sense, at a high level. Nor is it too hard. However, guests, especially Linux, do not handle it all that well generally. Exactly because users would tend to impatiently reach for that tool, then blame QEMU after a crash, we avoided emulating that. I'd expect much more in the way of research into how guests behave, perhaps some ways to limit it to devices that work well, and likely some linux patches to make it work better, before we commit to supporting such interfaces. > > > >> >> > >> >> The non-zero slot case has also been discussed in: > >> >> > > [snip] > > >> > > >> > >> Thank you very much! > >> > >> I see that the issue has been fixed. The ticket mentions the following. > >> > >> "What I am observing is that it seems when the slot ID != 0, the guest OS seems > >> to ignore this and we never seem to hit ich9_pm_device_unplug_cb()." > >> > >> Based on my experience and evaluation, ACPI-based hotplug is more likely to > >> encounter an issue where the guest VM does not respond to an unplug operation. > > > > I'm not sure it's a good idea to delete device when guest still thinks it's there > > (you can make guesses on QEMU side if it's in use, how useful those are is questionable). > > By instrumenting the QEMU functions related to device hotplug and PCI > initialization, we may be able to make informed assumptions. So try. But just know that pci initialization is commonly done by firmware, not the driver. > > > > as far as I know, ACPI hotplug has no notion of surprise removal (pls educate me if it's not the case), > > so I wouldn't do what you are proposing here at all, it's basically asking for disaster to happen. > > And all this is basically for dealing with abused qemu flexibility. > > > > Please (re)formulate usecase and make it more clear as what is eludes me > > no matter how many times i've read this cover letter. > > Here are some use cases in virtualization and cloud environments: > > 1. Suppose there is a QEMU user configuration error and a PCI device is attached > to slot 1 of a pcie-root-port that uses ACPI-based hotplug. The device may not > be detected or ejected. As a result, there is no way to detach it from the > user's QEMU instance until the guest VM reboots. sounds vague. if users can not configure qemu what are the chances they will use force detach responsibly? > 2. For an unknown reason in the customer's guest kernel (Linux, Windows, or > BSD), a PCI device may still be referenced by the guest kernel or its services. > As a result, the guest never writes the eject register for ACPI-based hotplug, > and QEMU cannot detach the device. The customer may blame QEMU for not removing > it. A force-detach option could provide an escape hatch, with a warning that it > may make the VM unstable or insecure. So just reboot the guest. > 3. Suppose a VM is stuck because of a guest kernel bug, such as a Linux kernel > panic without a kdump kernel being triggered. The guest kernel is unresponsive. > Force detach could allow the block device to be temporarily attached to another > VM without resetting the currently panicked VM. So just reboot the guest. > 4. Provide a mechanism to demonstrate that force detach is unsafe. Otherwise, > users may repeatedly attempt it and mistakenly conclude that QEMU is at fault :) We have that - we don't support unsafe detach. > Thank you very much! > > Dongli Zhang > > > > > On positive note: > > > > What you can try to implement is native PCI-E support for surprise removal. > > How hard that would be I don't know. And I would well expect if one deviates from > > real hw expectations/configs (such as not 0 slot/partial func removal), > > one would quickly stumble upon issues as that's not what what vendors write/test > > drivers for. > > > > Even if it's not likely to be used in practice (guest still might not support it), > > it may serve as test-bed for guest drivers. > > > >> Thank you very much! > >> > >> Dongli Zhang > >> > > From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:56:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:56:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410689.1641487 (Exim 4.92) (envelope-from ) id 1x3V9H-0004lm-Bl; Mon, 07 Sep 2026 08:56:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410689.1641487; Mon, 07 Sep 2026 08:56:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3V9H-0004lf-9A; Mon, 07 Sep 2026 08:56:19 +0000 Received: by outflank-mailman (input) for mailman id 1410689; Mon, 07 Sep 2026 08:56:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3V9F-0004k2-Lj for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:56:17 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3V9E-0037sh-2A; Mon, 07 Sep 2026 08:56:16 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x3V9F-003NNF-0T; Mon, 07 Sep 2026 08:56:16 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=VZnLNEhfVgfNC1P6C289F10iPIoaAUjsSA3SkyDubHk=; b=Fw19cNM3fa7tbAPZiU/HCe9ku9 iVMuSaJRYC9Te88bkH46QYUJKgu4iUZ2kUo9Ehq8LDj4g4VyQqiIbH/kBpfLHboLOETXXtv8qjcEd LjldQ3B23ZFdRWPIA7Jd1O6NYtMheALXTCfpDdpR0Y0/EWJkqvMv3fWsBrn7q7xCXvIE=; Date: Mon, 7 Sep 2026 10:56:14 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH] x86/vRTC: don't overrun array when storing century field Message-ID: References: <7a77f613-84b9-4049-804c-c3f53d804a38@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7a77f613-84b9-4049-804c-c3f53d804a38@suse.com> On Mon, Sep 07, 2026 at 10:13:10AM +0200, Jan Beulich wrote: > rtc_ioport_write() has two writes of the new value, yet only one was made > aware of the century going outside of the array. Fold both writes by > changing the RTC_SET short-circuiting. > > Fixes: f2ff80877f66 ("x86/vRTC: support century field") > Coverity ID: 1700943 > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -521,20 +521,22 @@ static int rtc_ioport_write(RTCState *s, > case RTC_MONTH: > case RTC_YEAR: > case RTC_CENTURY: > - /* if in set mode, just write the register */ > - if ( (s->hw.cmos_data[RTC_REG_B] & RTC_SET) ) > - s->hw.cmos_data[s->hw.cmos_index] = data; > - else > + /* If in set mode, just write the register. */ > + if ( !(s->hw.cmos_data[RTC_REG_B] & RTC_SET) ) > { > /* Fetch the current time and update just this field. */ > s->current_tm = gmtime(get_localtime(d)); > rtc_copy_date(s); > - if ( s->hw.cmos_index != RTC_CENTURY ) > - s->hw.cmos_data[s->hw.cmos_index] = data; > - else > - s->hw.century = data; > - rtc_set_time(s); > } > + > + if ( s->hw.cmos_index != RTC_CENTURY ) > + s->hw.cmos_data[s->hw.cmos_index] = data; > + else > + s->hw.century = data; Might it be best to do this based on the array size? ie: if ( s->hw.cmos_index < ARRAY_SIZE(s->hw.cmos_data) ) s->hw.cmos_data[s->hw.cmos_index] = data; else { ASSERT(s->hw.cmos_index == RTC_CENTURY); s->hw.century = data; } I don't think we are going to use more indexes, but otherwise we could use a switch. In any case, this is a fix so I don't intend to delay it any longer, with either the current code or the suggested array size checking (if suitable): Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 07 08:57:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 08:57:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410701.1641496 (Exim 4.92) (envelope-from ) id 1x3VA7-0005PH-Nr; Mon, 07 Sep 2026 08:57:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410701.1641496; Mon, 07 Sep 2026 08:57:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3VA7-0005P8-Jw; Mon, 07 Sep 2026 08:57:11 +0000 Received: by outflank-mailman (input) for mailman id 1410701; Mon, 07 Sep 2026 08:57:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3VA5-0005Ok-Qt for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 08:57:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3VA4-00EsAq-Nj for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 10:57:08 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e7c64-e002-0a2a0a5209dd-0a2a4504ce30-4 for ; Mon, 07 Sep 2026 10:57:08 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e7c64-b57f-0a2a45040019-d1558029d949-3 for ; Mon, 07 Sep 2026 10:57:08 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49b96837ca3so25901435e9.3 for ; Mon, 07 Sep 2026 01:57:08 -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-49cf7740d44sm654838095e9.15.2026.09.07.01.57.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 01:57:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788771428; x=1789376228; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=/b1TuQi8hJ+/5nCdhhrLQiTB7nR8a5uYW4Q3nMNx7rA=; b=Q5+2SPeq7TrA4U1FiNCzDfZdqU9szglQ1cDDaULGwxbl0TeO70FwsdRazihcrxgF5b ST/YAuOSrcBrJ9/JSRCy8Lmdt97vpR6lPvv9Tc+qEM8n6n6Y8HbByUNtGys8NguxUYkX tfFwG2HNTDokUoUkPAwxmRTO7qB7406jPO4zxStGUR6Wk4OPoU/eGOYm5jhJB9s+JYuG EiIT7w2GmQTaTpS5/5NUHdq5GU7SQT051OW52CNAG+MEv7VHQZJaG+TQ19r612Vkijae bNvWxAhdKH49i0J4RcxTpVZxEQBL//a+T6Fvg7vHUjY8mYiLoc6FJuFnH/sy0UUmTmLO 2mNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788771428; x=1789376228; h=content-transfer-encoding:content-type: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:content-type; bh=/b1TuQi8hJ+/5nCdhhrLQiTB7nR8a5uYW4Q3nMNx7rA=; b=FvQfMR7xJu8xu3i4T27g0txf8Q5w+b2RUyjoaT1pv4M8WY9eHwZBHWi8J8qXuYAFXj kdjiXkJOdqiQfx3kwjm1UQTq8e/jUurwDntrxjqAa/h/XMq26AYMlRQvUmNd6RIaMsLh hg76/NyD2V1G0dMQ45dcE8m20dV4oIqr9dKrLbso80R6lcd+2FeFcAv+X5JRPAsJP9ik zAIeDE3Y/UghK+7KmMKLQyoLtWswk+kXb9iH0upu6S9+Sj0ZahCm4Fdlly4Q1ttGk/3q mkKRLRYkvGEU2ed5928SNa2pGCL39lnWrY1/DhOX7xG6OwtkqyPeYycOLLJv7wuDIZ6X PGdA== X-Gm-Message-State: AFuF++nbY/e6M4dROB4/x0/ldlq10Kam79WIDe2pf2x1lZCDOIBmujJE ISFDMiXuGzrcArIEbslqNi0lOHdevl0RbmL35oBxQobIHOneJUeiDoWgfSvDsExUIQ== X-Gm-Gg: AYBFou05IK7H9dHPsmJBm9ozVSFVm4Vz50aojWmljuefXdyaT5I45JzyvDEayBobsan TaYc4JBmp6V4+Bl3le4l534lKe2eb1BmE+SikvdV1Eqq2mlMhBFh5LLgXXafW1oxAd9RIpd7g92 ScBI1Qj0rYSOPLC3UKp7G7fPxMkgOOP/74GQtg9ikfZH+X1akbycv1285SDp65YWl2Kf370D3sE auAhxECApzApaaDKh7NpfkukMdUcNxZdhflzzmSXsedbgEwVXOxRe8LpGBOZFj46EJCd/4LlD2g JhkW+Y3Jn1l58IjeicNJiVbcGiIRMbMhM6TxncHAbs+UWDSQmUmDk8ANvfJAJ9IfFILL7gBj9Ix yv4ELBRhjyaFVAGBybqVOh+ZbSuTgU3AeMh0sK2vA3jpmLUlAQ1Fsm170liroZqlE0s7ePLv/Vv TlxWRq+cmprgirzTP0YaePHpEt/QyM53D/prM3ruq9fMDoL5c1tSqENHBmf4IfmkCPEYJK1VsHV CEVPMSwMsJfs98dcr9U8mo/spTYjMXsi9NVTWUYj2AdvPoJ8pea X-Received: by 2002:a05:600c:190d:b0:49d:72d:9ba3 with SMTP id 5b1f17b1804b1-49d072d9bccmr117813685e9.14.1788771427931; Mon, 07 Sep 2026 01:57:07 -0700 (PDT) Message-ID: <4591a5ee-5fd9-4caa-95b3-81ef9078e600@suse.com> Date: Mon, 7 Sep 2026 10:57:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] x86/viridian: Implement synthetic timer direct mode To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Ross Lagerwall Cc: xen-devel@lists.xenproject.org, Paul Durrant , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini References: <20260904141516.367862-1-ross.lagerwall@citrix.com> <20260904141516.367862-3-ross.lagerwall@citrix.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: 8bit X-purgate-ID: tlsNG-ebf023/1788771428-526CAB50-E8F2F81B/0/0 X-purgate-type: clean X-purgate-size: 878 On 04.09.2026 17:15, Roger Pau Monné wrote: > On Fri, Sep 04, 2026 at 03:15:15PM +0100, Ross Lagerwall wrote: >> @@ -368,11 +379,18 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) >> if ( !(viridian_feature_mask(d) & HVMPV_stimer) ) >> return X86EMUL_EXCEPTION; >> >> + new.as_uint64 = val; >> + if ( new.direct_mode && >> + !(viridian_feature_mask(d) & HVMPV_stimer_direct) ) >> + return X86EMUL_EXCEPTION; > > Do we know whether native HyperV also injects a #GP in case of setting > reserved bits on the register? > > To keep the previous behavior, should Xen silently ignore the setting > when not supported, like it did in the past? I think so, yes (and I thought I had expressed this also in the v1 comments, but apparently not, or not sufficiently clearly). Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 09:02:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 09:02:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410712.1641506 (Exim 4.92) (envelope-from ) id 1x3VFY-0007L4-Aq; Mon, 07 Sep 2026 09:02:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410712.1641506; Mon, 07 Sep 2026 09:02:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3VFY-0007Kx-6X; Mon, 07 Sep 2026 09:02:48 +0000 Received: by outflank-mailman (input) for mailman id 1410712; Mon, 07 Sep 2026 09:02:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3VFX-0007Kr-Kf for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 09:02:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3VFW-00CGCP-Rb for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 11:02:46 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e7db0-2eae-0a2a0a5409dd-0a2a4502caee-20 for ; Mon, 07 Sep 2026 11:02:46 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e7db6-6ca4-0a2a45020019-d155dd2db558-3 for ; Mon, 07 Sep 2026 11:02:46 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-485843aeab8so3660015f8f.1 for ; Mon, 07 Sep 2026 02:02:46 -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 ffacd0b85a97d-485885bbb51sm28002855f8f.30.2026.09.07.02.02.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 02:02:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788771766; x=1789376566; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=qsOUt6UxOYz2imrFrcbysjwwValjgsYgX7ewlR2PANM=; b=Tjkc2++KcXq8NxnoHvcHQOMPXRI8prxZiObYZA9XRvvvyDSrTf4Mroz5v2uXH4hN1R U8JvV1YyWJcHVmnbXLV8rmhLio/Xw1gcveBnKgUtlMws/8Os11Vv8b8pJS5C7BnAbmfU SdWSmykqHKr0P37AYV4gGcO08pUR6vZrIDDdE4xyG5G+4DhqZi9j6Y4QhBj+PgCwa1/U cp+1gvniDHjA65wlFKOQPX8g2kYkc0DmGa4ph94nlSRJnvQJX7YJkLnr/u0y6xD4BN+z fGfs69sKGv9ZV5Ik77F4X2Ihd0ca1Cmp433k7Spnt1hnxWmHcnIeXPyMh/mkNgJ5YbPS g+DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788771766; x=1789376566; h=content-transfer-encoding:content-type: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:content-type; bh=qsOUt6UxOYz2imrFrcbysjwwValjgsYgX7ewlR2PANM=; b=eEo9/VvEAnBTQlXsWU5on3OaDQ2vAmKIbf20mZW72P0jBNWk6wjFwppqHIKx2PWCMS mmLrBV1mdWJdM8FBlZBWyuAWtF92bM3fJl2wlrw0eG4d8riBS61wA1k9IXp53fnN5XCF BMYQe1IY3kqrpCAjKh7Y5nezztg5/WhgTuvB8jB7Gntf/0Ks1v/SNZAP906HDcDyeSBz VdCKkICZC/42cF7+sfXEF3GD7oFIoNC1Qkgd4qGSYKeWJ3Y7KvzuPKMJHWmcWDh2nukK xq1wLjbrnRIsKt5W7mcp/dCT0QS74JKII11TkSWTY2rY66tVgP5YKzGsaazz9MdsmYnY XLWQ== X-Forwarded-Encrypted: i=1; AKwUvByVU386WHRve6P9Mn22mrU71tCp9b9jc23MUO5k/YGWByRV0Q3GFTIkGVTK9fVQ+vXeURo3TvmrrSU=@lists.xenproject.org X-Gm-Message-State: AFuF++nTSmcPudo/1RRvYncbNV6tIHRejxs99JLxfa0fH+9MxcaMU8Vs cSwQPj3BV/z6/zDgpGJDnM/cvK7+hS9wmedC3F/4rLI3d9q+Z54mScnomYmSWZVwKg== X-Gm-Gg: AYBFou0emQoJZoBj4T6PhLQyO054Mie9yfV6TgXSCRjq++JdyYfmFTgjN/EnqtkU+2T oToPzqZeBuMwq3lJ3uIxn25gLVLMxZ1hATeoVw3MK2WJUjwPV5GO3oUEWmgvPmQHUj04io9nzRE B3OLCZ+6B2X6rhgb+4+4TsdZzhUge7YojW4HeJ/38a5QprNRWquvHkLbMaGsdrcUfT4uTqSCnHN vFQ0GGYUlMAbpqxj6sKlS6IHcDk9EkpH8wSb2hSqWGfcud0XR1YBXrqIoxc7DHNQ+C+XopzrIW1 73MKFNOVTzfNm1JADCLG8Crsl2XTweo6E+qa0yj2tOA9V8LE2Ft/pZ6U6E2v1b6QIE5Au4j1T2H TCOAf65vtd8XNgLbqLLPz4E+uRM2qkQ64OEgNs/loOcz1rWx1umvxgv9jAZW9ywSR/tH14zBmL4 fLsVEyN+S72XP1Vcdm/oNyFa5DWTpGACOf7NxpXPBqN0MLgkcjlnE+wFVXmAvJyDOX3efF2IMeK cM+KVaEs95rEnQVRttXxG5TZFvlTYV+2JbGLUJm0j1zSrLf38v+ X-Received: by 2002:a05:6000:41cb:b0:482:f61c:7cdd with SMTP id ffacd0b85a97d-48586e4a6bbmr45364305f8f.4.1788771766197; Mon, 07 Sep 2026 02:02:46 -0700 (PDT) Message-ID: Date: Mon, 7 Sep 2026 11:02:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] x86/viridian: Implement synthetic timer direct mode To: Ross Lagerwall Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260904141516.367862-1-ross.lagerwall@citrix.com> <20260904141516.367862-3-ross.lagerwall@citrix.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: <20260904141516.367862-3-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788771766-F2AB52AC-34825D84/0/0 X-purgate-type: clean X-purgate-size: 1235 On 04.09.2026 16:15, Ross Lagerwall wrote: > @@ -368,11 +379,18 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) > if ( !(viridian_feature_mask(d) & HVMPV_stimer) ) > return X86EMUL_EXCEPTION; > > + new.as_uint64 = val; > + if ( new.direct_mode && > + !(viridian_feature_mask(d) & HVMPV_stimer_direct) ) > + return X86EMUL_EXCEPTION; > + > stop_stimer(vs); > > vs->config.as_uint64 = val; > > - if ( !vs->config.sintx || !vs->count ) > + if ( (vs->config.direct_mode && > + (vs->config.sintx || vs->config.apic_vector < 0x10)) || > + (!vs->config.direct_mode && !vs->config.sintx) || !vs->count ) > vs->config.enable = 0; Personally I find conditionals like this one ((a && ...) || (!a && ...)) pretty odd to read. Imo that's a case where the conditional operator is quite helpful: if ( (vs->config.direct_mode ? vs->config.sintx || vs->config.apic_vector < 0x10 : !vs->config.sintx) || !vs->count ) (Of course further adjustments are going to be needed here to address Roger's comment.) Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 09:17:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 09:17:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410721.1641514 (Exim 4.92) (envelope-from ) id 1x3VTS-0001QA-ET; Mon, 07 Sep 2026 09:17:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410721.1641514; Mon, 07 Sep 2026 09:17:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3VTS-0001Q3-BI; Mon, 07 Sep 2026 09:17:10 +0000 Received: by outflank-mailman (input) for mailman id 1410721; Mon, 07 Sep 2026 09:17:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3VTR-0001Px-8I for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 09:17:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3VTQ-004KDP-Hl for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 11:17:08 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e8110-e002-0a2a0a5209dd-0a2a450aa8e4-2 for ; Mon, 07 Sep 2026 11:17:08 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e8114-f2d2-0a2a450a0019-d155802fece6-3 for ; Mon, 07 Sep 2026 11:17:08 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49b0d8bc2aaso42208955e9.0 for ; Mon, 07 Sep 2026 02:17:08 -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-49cee6158e9sm380041265e9.12.2026.09.07.02.17.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 02:17:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788772628; x=1789377428; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=nPhPvdW4Ysb7735tdEwrEe38QbozZ6fosusBrH1dFJ0=; b=XRcD+sNxZVslPqMCE0/rw20AA9J8+K7GvYxvAXIFkuxlVmd+W6meWCzAhGcIVKZXx3 A0Knl9hML2Q+2ipX4CpQ4SgE6bbDwRxtQYRI87qCVGgnCnvDpc6W++sKlRxZFHQpy4O7 lyyKtAHw5S5WTX1MD7Dn7f2EdbIiHpX7JUj+wpdxDFN3/yAV+BdAu+R1+YojrmCEMeYK Ll6ktpsl1cZYAIaSZAap5auPsB9khD8Gz8HA7zH1f3RJ+3rhDiNeuVVTQZDKjc2m9Csx e6KRQtJbldxFsWnugSdGFZQe4iaSGiBE8HqaEwx9V6i3LGBHosrBVCeBynnBnIlizjXI pnAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788772628; x=1789377428; h=content-transfer-encoding:content-type: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:content-type; bh=nPhPvdW4Ysb7735tdEwrEe38QbozZ6fosusBrH1dFJ0=; b=Pyq6zaC6QZyQd1bvePeEj2ep4Ue5U4OAixjF/h75pgqladnOnQn09YTCSBHtC/L/zY lbmUCu3jsr8YZlWRN2/4iTPNtBOMdwtBWXF1OdDS/lRcaXNutkUlftZ3zQ9nJy9FSuLQ +BhBUYt3CCo165z4ekP7VfpZTNvhacJ7hT+esWctqttp+lGejyN83XAYNUIkP+sb+6hv VPYWe3WvQanX1M6h5HvfIKePykDDVyX/pcbqI9j/wEy700Sup+971jjWTO+F4dQ2eEYq 4HJazUR7sly+iHnkwvRMkvs2/7c4hHZZiqxij0Y+5h8hNjxbF8Y0Td9VsPpNEbIZ059V +pqQ== X-Gm-Message-State: AFuF++m8rxkINxwWyU4xpGRl/Ag1ngopDHccAcXVF5gfMLQE+vA4vfPV AAQolRxuh6kKpFrIwY6272Q1JLyhjYhH8tQCEPAyBRUhYNHvX30iD91IXWNltj42/w== X-Gm-Gg: AYBFou2QFKRm1JNafMDB0s/tz50flHzEL0sMzKS0jfLAaOEEZ2axjECJ7Zzv37c3vPO tgWWollMMEoEODz9XNGetoBYBG2W/EJoFntYBV2BdwvbDll+pLzl/6Dv6XCVooOASApr21nHIeI kZGE8RMA01Pk9Atcqf1yAr8sAcNLjSNEnJa/pFCLQUCEN5jAIUNvueViv5gSCmmd4cumFnjuS9T KwBQcUT3zyygImYn1pNkfg92f2s1VChsh174HI7VDs0MiSY7w0eKp6M7E/14PVvOjD9F55z1qTv JT7kaFty2iVIUWQJ8Dgf/DGNwaWceuIk1AuLWDi3ar0kZsLp4k9mC7jxBXPiGK4I8OT/oW19QwR ES1A5/SVd6MO9q89hm4OZS9Q7iG0I4y0crGOILgGYowLaeVlPN0pMYtuz2fd2AKd9560+ftcnKS k9ZrHYZdhaiEzKDZvtUrR+95psdFFdbPBH8VbxVIVaV9gJj7dE6YDymlkIQsnQG6EpPQ1DsPDcn 3wMp+D6YEPLFmxPYpN1gkzBDWZ0wLXiazOfXdw8c0PhFQZ6MsoH X-Received: by 2002:a05:600c:5394:b0:49c:fc6c:be0d with SMTP id 5b1f17b1804b1-49cffdc89e4mr153062075e9.19.1788772627863; Mon, 07 Sep 2026 02:17:07 -0700 (PDT) Message-ID: Date: Mon, 7 Sep 2026 11:17:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/vRTC: don't overrun array when storing century field To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <7a77f613-84b9-4049-804c-c3f53d804a38@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: 8bit X-purgate-ID: tlsNG-4011c0/1788772628-58FC6CFC-775A201A/0/0 X-purgate-type: clean X-purgate-size: 2630 On 07.09.2026 10:56, Roger Pau Monné wrote: > On Mon, Sep 07, 2026 at 10:13:10AM +0200, Jan Beulich wrote: >> rtc_ioport_write() has two writes of the new value, yet only one was made >> aware of the century going outside of the array. Fold both writes by >> changing the RTC_SET short-circuiting. >> >> Fixes: f2ff80877f66 ("x86/vRTC: support century field") >> Coverity ID: 1700943 >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/hvm/rtc.c >> +++ b/xen/arch/x86/hvm/rtc.c >> @@ -521,20 +521,22 @@ static int rtc_ioport_write(RTCState *s, >> case RTC_MONTH: >> case RTC_YEAR: >> case RTC_CENTURY: >> - /* if in set mode, just write the register */ >> - if ( (s->hw.cmos_data[RTC_REG_B] & RTC_SET) ) >> - s->hw.cmos_data[s->hw.cmos_index] = data; >> - else >> + /* If in set mode, just write the register. */ >> + if ( !(s->hw.cmos_data[RTC_REG_B] & RTC_SET) ) >> { >> /* Fetch the current time and update just this field. */ >> s->current_tm = gmtime(get_localtime(d)); >> rtc_copy_date(s); >> - if ( s->hw.cmos_index != RTC_CENTURY ) >> - s->hw.cmos_data[s->hw.cmos_index] = data; >> - else >> - s->hw.century = data; >> - rtc_set_time(s); >> } >> + >> + if ( s->hw.cmos_index != RTC_CENTURY ) >> + s->hw.cmos_data[s->hw.cmos_index] = data; >> + else >> + s->hw.century = data; > > Might it be best to do this based on the array size? ie: > > if ( s->hw.cmos_index < ARRAY_SIZE(s->hw.cmos_data) ) > s->hw.cmos_data[s->hw.cmos_index] = data; > else > { > ASSERT(s->hw.cmos_index == RTC_CENTURY); > s->hw.century = data; > } We could do so, but then consistently (i.e. also in rtc_ioport_read()). > I don't think we are going to use more indexes, but otherwise we could > use a switch. We will want to gain further indexes, for alarm day/month (as indicated in a remark in the original patch'es submission). I decided (in the original patch) against switch() because they're a little odd to have inside a case block already covering the same (strictly speaking: a subset) of the cases. But once the other two fields are added, I think switch() will be the form to use. > In any case, this is a fix so I don't intend to delay > it any longer, with either the current code or the suggested array > size checking (if suitable): > > Acked-by: Roger Pau Monné Thanks. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 09:26:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 09:26:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410729.1641523 (Exim 4.92) (envelope-from ) id 1x3Vch-0003cj-B8; Mon, 07 Sep 2026 09:26:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410729.1641523; Mon, 07 Sep 2026 09:26:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Vch-0003cc-7u; Mon, 07 Sep 2026 09:26:43 +0000 Received: by outflank-mailman (input) for mailman id 1410729; Mon, 07 Sep 2026 09:22:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3VYB-0003Ep-Us for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 09:22:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3VYB-006FcV-4k for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 11:22:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e822b-bab6-0a2a0a5309dd-0a2a4504d7b0-42 for ; Mon, 07 Sep 2026 11:22:03 +0200 Received: from [209.85.128.173] (helo=mail-yw1-f173.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e8239-b57f-0a2a45040019-d15580ada41a-3 for ; Mon, 07 Sep 2026 11:22:02 +0200 Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-855de2d0d4dso35064747b3.0 for ; Mon, 07 Sep 2026 02:22:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1788772921; cv=none; d=google.com; s=arc-20260327; b=HcUnBuFAXPepcnQEsV/FnnAv0QxZ6t1SFrR49kVDNxlWUtNkOLbrBMkHDPRZAK4nA1 6Q/tTYqQkyR2lWpEEySGODE6H4nEePHgtRBLulkDvzDN8nhUGVVerNHRmZiJTLCXrq3S zhjSpG80y6PK2cXu5KsU6Tky5BfQJ6J8UupJzyEFd5UVwUXjLnMXGVkMejzU4iFvqGuL eV5LKhu3CrfAsN3SjMiK+4DSITOl/x9AQ06fwps54eyk/IhMfuGAICNz5U8SyN1ugvSX Wffqh3EboBbBLXdstTexFg/rSiQX+REYLqVEfDrDg3Oi97i5ghrM8qI448EmrxXuO6bL ZTHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=J0t5MHJvx2iLkVwFpdNQYQKKsnnTlLCT8TZwcuf3lTs=; fh=MLKe2YFdBtG+CQJioQQ4py81TRbJLTewHNkwBRtiK1s=; b=mDUgMp4rKjGvgMjtOs1x0ElP93RQhvRr3eG0q3KUa7JTmcpvbH10+RULUkS9Wr+mGv wLkVAU+iR6C58C461Zn8kZu7BmNqM/fq3fxtp2xvNTX+N6TxkBtGfJZqpLMoUdtwsGkS dTgmCzn9uf/yZJOWpfowuGT/FnrXYa2ZYoHaxc3AKQlgxUJ+IBGagadIzCV6Sb4Zm2vW ypE+qYz+a4BFNEhgUvaRQJqdRpvBHoqBOW4wHaVP+9vckPMCn7zTfl5/YF7rNW5lsk7B Eu/mi49H0kHn4C5v5ow8sts3iXEg2o8+DxkzgsGR6KAwSzyvvJ0N4TqJwAqKSFZmFqVJ xSow==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788772921; x=1789377721; darn=lists.xenproject.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=J0t5MHJvx2iLkVwFpdNQYQKKsnnTlLCT8TZwcuf3lTs=; b=exUg6jkWeEPZGiRJxZmNI2KOT10c+EfhkbPhdvhVNV/QgI5o4x6eV4u+z/EpIJ1zE7 OhfUzFrys5q4d6jac/gx64sdKmQwgWuG98yxjBE4xxMWcijJCXh56+PrcQXO+ZupoEmG LE8iOkUpno9+fWoX8bccf8crtvxaTIOU0A8hmpoLp+Vno14wmn2r/6+UwWS9CpE6WJVU 3vr0YVv8rrK9DhlpfIPi2dSm7ouha616L1TkUQNQVNn2Z5mEoipDRbp1J/phTrdWrUAQ kIev/P8oF2eviesmb7mMPltEOysYwtleJ5zGxkoQbOFl+WIMOdUYDOcXhdc8Z/vdR5od C/Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788772921; x=1789377721; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=J0t5MHJvx2iLkVwFpdNQYQKKsnnTlLCT8TZwcuf3lTs=; b=NOl/R6MEz28Bojrcb6WGKvBnEYgTkcj+gA9UQmI8qi+LoQkA5ZcS5nAONfgL17ZBx0 CmuLIXAksURrYFy+ebzuD+Q3bPXJh7L/hMaOEx5wgLLi72fNjylr+c10+w09NLpmoTLj DXmiwcYrRJHgukmG64WL2hAgoS0DOJiHq8AUIldG0uuvcpXr/DN3AIbH3NU8HkokwiTd vGxwKRKKaUj/LeMfNMzRO4gftouNtpYw+ICHzBL3fQnd9LObM+cJ9S8sD9c7d3XEb/HC IqFnWP1csnv0P5rHlDKNNYP5pomPXkFF/2eRxBTExakMRy03e1y/NpDCorvinCSSxbc8 8Uwg== X-Forwarded-Encrypted: i=1; AKwUvBxg/AxaLHg58ndoCq/+7Zjj2kM470fojRmFvtFBxOu9kw0ZRuRmiRgBb7e3vkICmVb/WdSC7HJN9Bk=@lists.xenproject.org X-Gm-Message-State: AFuF++nVg/ED45A4Sc7aRcnuLoiOhYA5qanrQ24FPyvEeQZjm2x62/Vn UwgOtW1MSMts6zoxPSR29xmPgdJu3KDBdvamAXcX3cecMOqKgLLg/lEBM3oYK1yJKMRiZNTtrLu u9l2y7CN6ccdgXDE9eN1y1qQt9Eotyg0= X-Gm-Gg: AYBFou2qabCxx/dvrXgXcySBKsajvGkLhNXmPdcHE28d1mgX4rlfX8widCLAUgYW0nd 6TvVO3cNM+jbU2dBtd+SyVyEal/5hiUBd8p12FvCTbNitmQLHoo/Cfptm5l/iSdIMEcMQ3+1ggb 8Bx4DXUDNXev/lcKbPapVjIahDzml3embbWdA1szprkOmZlWW8Hp4E5kDCKxYHkuEaBSwwGgVka 1fz2EHD/xMb7W0qrLPX0R4WrKmoHVmUMOs/P0O52udxYNLqR3eQUlBUUfFvRhbjGSvgrEuk7q/u PgxzGj7gVCvquQw2oAcFSs9tiw6i9rVbAH3OEJeMu5pE63W7rRiKQ0CWOqKXiJUIp7mEr87DKYA O X-Received: by 2002:a05:690c:a84:b0:7f0:38f7:6ca6 with SMTP id 00721157ae682-86e6d7905ccmr100098477b3.5.1788772921510; Mon, 07 Sep 2026 02:22:01 -0700 (PDT) MIME-Version: 1.0 References: <20260907063531.23981-1-hemanth.selam@gmail.com> In-Reply-To: <20260907063531.23981-1-hemanth.selam@gmail.com> From: Frediano Ziglio Date: Mon, 7 Sep 2026 10:21:50 +0100 X-Gm-Features: AcwNN1UZe9OK-phDYGL6Rp7bdzbs1SB4QayVK-l7Y6JKSNPJ-dx1Aq5zzRqdwzM Message-ID: Subject: Re: [PATCH] xen: fix typos in comments To: Hemanth Selam Cc: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "James E . J . Bottomley" , "Martin K . Petersen" , xen-devel@lists.xenproject.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ebf023/1788772923-516D2B50-89A26183/0/0 X-purgate-type: clean X-purgate-size: 4070 On Mon, 7 Sept 2026 at 07:36, Hemanth Selam wrote: > > Fix typos in comments, reported by scripts/checkpatch.pl using the > misspelling list in scripts/spelling.txt. Only touches comments, no code > changes. > > Assisted-by: Cursor:claude-opus-5 > Signed-off-by: Hemanth Selam > --- > drivers/scsi/xen-scsifront.c | 2 +- > drivers/xen/mcelog.c | 2 +- > include/xen/interface/platform.h | 4 ++-- > include/xen/interface/xen.h | 2 +- > include/xen/xenbus.h | 2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c > index 989bcaee42ca..f86a47056ea8 100644 > --- a/drivers/scsi/xen-scsifront.c > +++ b/drivers/scsi/xen-scsifront.c > @@ -1076,7 +1076,7 @@ static void scsifront_do_lun_hotplug(struct vscsifrnt_info *info, int op) > > /* > * Front device state path, used in sdev_configure called > - * on successfull scsi_add_device, and in sdev_destroy called > + * on successful scsi_add_device, and in sdev_destroy called > * on remove of a device. > */ > snprintf(info->dev_state_path, sizeof(info->dev_state_path), > diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c > index 32ab419bb503..f19cc7a67f36 100644 > --- a/drivers/xen/mcelog.c > +++ b/drivers/xen/mcelog.c > @@ -1,6 +1,6 @@ > /****************************************************************************** > * mcelog.c > - * Driver for receiving and transferring machine check error infomation > + * Driver for receiving and transferring machine check error information > * > * Copyright (c) 2012 Intel Corporation > * Author: Liu, Jinsong > diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h > index 79a443c65ea9..462e36392a9f 100644 > --- a/include/xen/interface/platform.h > +++ b/include/xen/interface/platform.h > @@ -421,10 +421,10 @@ struct xenpf_pcpuinfo { > /* IN */ > uint32_t xen_cpuid; > /* OUT */ > - /* The maxium cpu_id that is present */ > + /* The maximum cpu_id that is present */ > uint32_t max_present; > #define XEN_PCPU_FLAGS_ONLINE 1 > - /* Correponding xen_cpuid is not present*/ > + /* Corresponding xen_cpuid is not present*/ > #define XEN_PCPU_FLAGS_INVALID 2 > uint32_t flags; > uint32_t apic_id; > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h > index 40c9793e9880..f9acb21875cf 100644 > --- a/include/xen/interface/xen.h > +++ b/include/xen/interface/xen.h > @@ -94,7 +94,7 @@ > #define VIRQ_XENOPROF 7 /* V. XenOprofile interrupt: new sample available */ > #define VIRQ_CON_RING 8 /* G. (DOM0) Bytes received on console */ > #define VIRQ_PCPU_STATE 9 /* G. (DOM0) PCPU state changed */ > -#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occured */ > +#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occurred */ > #define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient */ > #define VIRQ_ENOMEM 12 /* G. (DOM0) Low on heap memory */ > #define VIRQ_XENPMU 13 /* PMC interrupt */ > diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h > index 8ca15743af7f..6424c5cf8ef5 100644 > --- a/include/xen/xenbus.h > +++ b/include/xen/xenbus.h > @@ -63,7 +63,7 @@ struct xenbus_watch > unsigned int nr_pending; > > /* > - * Called just before enqueing new event while a spinlock is held. > + * Called just before enqueuing new event while a spinlock is held. > * The event will be discarded if this callback returns false. > */ > bool (*will_handle)(struct xenbus_watch *, Reviewed-by: Frediano Ziglio Frediano From xen-devel-bounces@lists.xenproject.org Mon Sep 07 09:48:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 09:48:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410750.1641547 (Exim 4.92) (envelope-from ) id 1x3Vxa-0007fX-5P; Mon, 07 Sep 2026 09:48:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410750.1641547; Mon, 07 Sep 2026 09:48:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Vxa-0007fQ-2E; Mon, 07 Sep 2026 09:48:18 +0000 Received: by outflank-mailman (input) for mailman id 1410750; Mon, 07 Sep 2026 09:48:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3VxY-0007fK-RB for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 09:48:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3VxX-004ToB-Ei for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 11:48:15 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e8857-2eae-0a2a0a5409dd-0a2a450aaa52-38 for ; Mon, 07 Sep 2026 11:48:15 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e885e-f2d2-0a2a450a0019-d1558029bd54-3 for ; Mon, 07 Sep 2026 11:48:15 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49556f97a9dso28239155e9.1 for ; Mon, 07 Sep 2026 02:48:15 -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-49d0656e7bbsm195921945e9.10.2026.09.07.02.48.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 02:48:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788774494; x=1789379294; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=nOUGvh6ep1mInl0Q2DlDHVX6PKKvK4aUiskOUYilt2c=; b=dtqIZDEvNvQEDeen9BKm9OkHJ+UXrLPjbQY2LOp/HM+xwraNokiuTScexHLVME070m Wno5p9SnPg+YjeJ78GvAg6xpingNO6eT3M/Y3CnwthUq0UDRVi/NSUxxVFe+CtEmmGzP hZPCcNCoiWkoNHA7MpbYzvak+JQ1q7RTmpz7QgstJB/P5Ic1QGLvF0LN9Az0koLJin5l AJH/K7gWhxpy4fqlgeKBX7bjeTn7NVSBjf/gMCJ3DiOme1ieV7ZlQEFj13uC0rfNW1rK TDp/abceVJXcRG33gqVW40RMB4CqR3bjc3dwI9Are3mBGZMoPYvN5FGHKcY7yWLTbvMe 5Hlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788774494; x=1789379294; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=nOUGvh6ep1mInl0Q2DlDHVX6PKKvK4aUiskOUYilt2c=; b=g2bTrWiw7nww/SNlyw1DntwjBp7DzWzIqbz18GN3MG89DgzqBxXzm2Ebc7RszLgP6Y tMS/z3v97hH1wNgjG28reTzH3L+56mKKDnL1WPu0ds3Cp02ZMKoKw/36qC0QYhmgav8v bAEuhCigRpphy8TlgN6xtmHLVfxFB5jDS7Gnl3Tuk0hdeZc4NI4ADvT6IhfyRgtEkJhb 0NdZbZnTXRF40gXQEvFXPfBny+f+GvxHWWuKGgqH92ZnnFSTAg5qBnXxr59XPiNqANMk diZ8SgYM3yXmiH3qgswhTYjzcOFTPexes8nnw95E2LjYbqbRorpdbG0wuqoCeL+u16FW Tcmg== X-Gm-Message-State: AFuF++lINbkJHXlLZXXHvejeFeT5yTkUF87DP8kP4Wrpiaoa/3udToqb TobA/w4CYDnJZ9d+jQe6HwaHrZfJzNk9/C/j+Uo3ay3vV6r/mgD8bW2kAbf6s1bSn/Sx37/W2GY ELQGMiQ== X-Gm-Gg: AYBFou2g1Z1mh/ZwVNfTnHWGzvt5abl3S6BIIYnH/JEehwkyQ4nsAljoqfAiSfpC2vq nA8yzk9yIFGvGmw9l7zvofvmAhTd7ezePwuI6kd2ETwYBBUTC4fmKwERIZJSvZqLr7uTIbgQ5FL 0m+cAyfn3ifJxpGPR0C1w94Y+wlTj1z16sOdI17rnJRo4817IrWRYWlOf4XgxUCtR63yJe7QFU4 HJ43Cr/w9EpRZUOygZleZXzbBZgaHfPER12wQz1xbT/TnxtB6HFc8vyzL0ruOPHixePGP7cSzmA GQYft9hwWcJvKPIDUu6ZEmGui+pBHeYG+UgWsSOoXNbADa8KxkwJCCubjBsRE+Y+2QfqGsoc4D+ 4HS3bfIusaYJMHpS8xIZcawVsZXTLkR1uZUsiIslr5MxOR7tLZ5d2jvJqYGtZvKNrkTml+35XYA 6PDwrik6bmzdOpC/uTjv4BU/8rd8DFAxa2wZ4Dy57KoZrfzflC5a+uB5rhEIBaChjHuruJOl+2q Pqo/Xl05s/CLRpY4u3eO8ZKq+VaYkarGTi7Sg05YMnbZ+WDW6Bf X-Received: by 2002:a05:600c:474c:b0:49c:f4e1:4c2d with SMTP id 5b1f17b1804b1-49cf828cd70mr200254295e9.16.1788774494397; Mon, 07 Sep 2026 02:48:14 -0700 (PDT) Message-ID: <13ebb85c-62c2-477b-87ff-377bbe3cfc6a@suse.com> Date: Mon, 7 Sep 2026 11:48:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] libacpi: drop mk_dsdt's -d / --debug option 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788774495-5A1DDCFC-1F47096C/0/0 X-purgate-type: clean X-purgate-size: 2406 Recent Clang complains about the "debug" static variable only ever being written to. Drop it and the command line option controlling it. Fixes: 19ab8356abe4 ("tools: remove support for running a guest with qemu-traditional") Signed-off-by: Jan Beulich --- a/tools/libacpi/mk_dsdt.c +++ b/tools/libacpi/mk_dsdt.c @@ -15,7 +15,6 @@ #endif static unsigned int indent_level; -static bool debug = false; typedef enum dm_version { QEMU_NONE, @@ -73,7 +72,6 @@ static struct option options[] = { #ifdef CONFIG_X86 { "dm-version", 1, 0, 'q' }, #endif - { "debug", 1, 0, 'd' }, { 0, 0, 0, 0 } }; @@ -125,10 +123,7 @@ int main(int argc, char **argv) } break; #endif - case 'd': - if (*optarg == 'y') - debug = true; - break; + default: return -1; } --- a/tools/libacpi/Makefile +++ b/tools/libacpi/Makefile @@ -43,7 +43,7 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.a # Remove last bracket awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX) cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX) - $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX) + $(MK_DSDT) --dm-version qemu-xen >> $@.$(TMP_SUFFIX) mv -f $@.$(TMP_SUFFIX) $@ # NB. awk invocation is a portable alternative to 'head -n -1' @@ -51,17 +51,17 @@ $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.as # Remove last bracket awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX) cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX) - $(MK_DSDT) --debug=$(debug) --maxcpu $* --dm-version qemu-xen >> $@.$(TMP_SUFFIX) + $(MK_DSDT) --maxcpu $* --dm-version qemu-xen >> $@.$(TMP_SUFFIX) mv -f $@.$(TMP_SUFFIX) $@ $(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT) printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 0)\n{" > $@ cat dsdt_acpi_info.asl >> $@ - $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> $@ + $(MK_DSDT) --maxcpu any --dm-version none >> $@ $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl: $(MK_DSDT) printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 3, \"Xen\", \"ARM\", 1)\n{" > $@.$(TMP_SUFFIX) - $(MK_DSDT) --debug=$(debug) >> $@.$(TMP_SUFFIX) + $(MK_DSDT) >> $@.$(TMP_SUFFIX) mv -f $@.$(TMP_SUFFIX) $@ $(C_SRC): $(ACPI_BUILD_DIR)/%.c: $(ACPI_BUILD_DIR)/%.asl From xen-devel-bounces@lists.xenproject.org Mon Sep 07 09:50:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 09:50:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410758.1641557 (Exim 4.92) (envelope-from ) id 1x3Vzz-0000q3-Gt; Mon, 07 Sep 2026 09:50:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410758.1641557; Mon, 07 Sep 2026 09:50:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Vzz-0000pw-Da; Mon, 07 Sep 2026 09:50:47 +0000 Received: by outflank-mailman (input) for mailman id 1410758; Mon, 07 Sep 2026 09:50:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Vzw-0000po-Vw for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 09:50:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Vzw-0095Pf-9W for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 11:50:44 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9e88ed-e002-0a2a0a5209dd-0a2a4501c3ee-30 for ; Mon, 07 Sep 2026 11:50:44 +0200 Received: from [52.101.53.5] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9e88f2-5984-0a2a45010019-346535052d8e-4 for ; Mon, 07 Sep 2026 11:50:43 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5888.namprd03.prod.outlook.com (2603:10b6:a03:2d6::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Mon, 7 Sep 2026 09:50:40 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Mon, 7 Sep 2026 09:50:40 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=f5iJZyJg7r1gKBfkIKKrBCk8xVsTEf3nKiJu/uFaTMRP32XK16ATRa3ytIU1ds4aYecefFcTCPNyq9AD8HYAa2bSzkP5ocryRdFoqX7nHa4Z5c+v1S40XqeGbiiq9BMeZdOKIZe3zLcRzCfsKhQvmXAmPd+0lcVIlUaFvNd0or4gn/7u5agYv74mUmgQ29Uc/rcALo3EWsWfSeaZbJPMK6k7HB10zVBXmf1ZvZGm1CNXSwZ9/H4kTdxRgJioLrBMiTN/tsec/Ss+n4mY5tigK1PiVdafuGSfeJ5E6UWsH8xOZyR0VX2O6Vjnd1nNxApea2PbOSOiXqCi5ECKtlEOtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EsNg8QlryyCY/8GraPHkjLroq59cBwkONyyVBPoVZu4=; b=hX5uG3WRVwripw7Fe8wGvf9Wot8/Kfv5kn+Rqc6sl8Qu+6I3YxnTIhbwPovBcZsOYJ3wWoodmA8U6TLIfGs/VW+lHRhkXxhcBaM9J4ABhNQ9TnpcDkOkBtiYBFhHUqHSMPQVRVUeR048smx/CODZ4QDBskrZlSt2PQv55KzEnYxoiWhqbYP9xUoYkMEtUfbkN46PLDyHKKdkLXw6NmtFsEv9YbtQbDmm8d0Z0FWcK829n9uTrTdEn7ppf7w2zgJwhVCWKx5/ltZPpmHbKYYYJ5ixEPjFA5fbhAwQRtOcN3Oo6ImW5I3S50GHwRLVif8LV8oo8zHbXgSEew6JySKQQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EsNg8QlryyCY/8GraPHkjLroq59cBwkONyyVBPoVZu4=; b=xzYEFHW+dw0kistHEHvIr6DndHWWSBJtqBbkZleMu0RG6EYcsu/aMiD2M5E3ZKV2iVZw5nsv4/cl7bq3ma9ucXxplYHVgDo/wcGgpvPQON3clL2LcC1KhTuAF7kzUc7YeTutwUnROlql2DUSJnceqGrvh6zHBq3tr2rFiWmOTjQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1f1d9746-4eab-43bc-a638-99d9b0e0531a@citrix.com> Date: Mon, 7 Sep 2026 10:50:36 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] libacpi: drop mk_dsdt's -d / --debug option To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <13ebb85c-62c2-477b-87ff-377bbe3cfc6a@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <13ebb85c-62c2-477b-87ff-377bbe3cfc6a@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO0P123CA0007.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:354::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5888:EE_ X-MS-Office365-Filtering-Correlation-Id: 7a724d41-7ad4-4ab8-d265-08df0cc579aa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|10067099003|6133799003|22082099003|18002099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: rE9AWaU78P2bp8Eu5osqSrEnVGx9WRM/nJopNtJhFFhridpMiwQAZA/Zv11GCuD1UYElQq6QrfgqUI2fLaOI6fTEZRPES04xZcqK//rgiIcUhfeNOhdxf3kmQp7QmB+Bfvc4k0hDIFY7CgfiZkZPgjLFPEa6R+QenvvDnNlstuzJ3E0h0BWfEnHRED3HK5ZuRFeP7rpQJCgPV1xAdmona3jiegvU5FQZ/ZHmgI9YXAkXC6rhAj9V8oMPkcjB/M4bAZDVMThnR1rqybjCkrk+2NaCwoCKDUru6A5rwLDtlZceDpFsWVrIuPmGm7+SdySnK6W6ZJQdDvVD0NkRmuw/sea1I4ZzydJ5oeR3QqWggOMJ0hbGPqaz3UKS/8F3WWcobGZx07QWfR/k3FR/4WGgkMMM5dZtl3RpxkdoaC2F8Y0iqre01pAIjxim68w2YNlCG9eBDMy6EqUjjAHJ626quAUb15MdGpD7Nt6BiP9zlW57/RRUxqG46TSv/dGWNgotadMSUVBXaAiX1nSAkEkPNLrpVtfcqk8WOZQtsS//Rk+69Rm26biu7I0if6ZMJRXWXwVKoBAklS+JBGSdJxS+cxiffEJT9LEH0cQDDN75pXusbw3ItWMy39AapGPbAbxu1+XPicf/9F8PI6V498UAijwrebgkd3qIAEMGVCYqRdc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(10067099003)(6133799003)(22082099003)(18002099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QnVla3ZuWk5MUE45dUN1WFJ0N1BudDJBZklWN3BhTVY2RDh5VXpMWHhQUmRn?= =?utf-8?B?V3pJUFZVOUpTSDdDemFRUHFxTDcwWnBuU1dRMjZHTWxsUUlsT2gvcXRYMlN0?= =?utf-8?B?aEJQZGh5ODE5akRtd0VtWWlYUnZiLzArVzl3WkNYYjBTQXVxb09iNGx0cW9D?= =?utf-8?B?anQrNXEzMGtoM0xVQ29PYnVTTHhzbVVXS1ZoY3pGcVlOS3F3Um1WYVIwdVNJ?= =?utf-8?B?M1VDcVBKTHV5OGg4MHI5Z2U4OVdpWGc3ZTZOMkhVdGU1YTRzSm13MHlMbnhY?= =?utf-8?B?NG43amFROXpNVFdHSStlZlpQd0t3VnNUcUhnYVNLa3NTNzFDY1BkMmJhNisy?= =?utf-8?B?Q01KOHVWN0ltRFZsOWdnVHhHNVpSYWhlS0wwaUpwWHUrZThTWVg3dnpUYzlr?= =?utf-8?B?RmtJRUJHNXE1dzVSR1dESjR2aXd3RkVTT01LY08rSS9aNXFIekx5dFNGTnFr?= =?utf-8?B?UXh6QzdJUGNGU2p2SlJEQWdmajk3QlhHV1NRMitQVUtlNUZzNk10a25DWk82?= =?utf-8?B?MGhYV2VzV0NKV00yOVk5ZXRGbzI0WHFWajdrY0kvQmlQTVlTS1ozd3dtZmpq?= =?utf-8?B?b2I2emNia21ERTdWcFlLcDFGWis3V0pnTHlvbk00dWgwNis4NkJ2Rm9oczBR?= =?utf-8?B?bkhOaVJabmQrbVJOSWNTMW41dUtjZmtMSGxCcDdlOFQzM0FIYWl6ODVrUHdn?= =?utf-8?B?YjRtRDl2eVFvU2oyVWRXL25YTzA4U3BuRFQ1Tlp1OGFTUkFXcjZKYy9qS2RK?= =?utf-8?B?czlIWU52clBLQ3NrMFRQVy9KYTQrQ0FXK3RqbmJRa3Z6bm1JaG5tYUVmM3JB?= =?utf-8?B?OGZERXVZd1QyMVl1Z0RoV01TaDlraGZMQTc2ZUNUdm1hR3VxS2ZobWt4OFIx?= =?utf-8?B?eDhFQTJyQklOclZzNDVGaEVNT0FsZnFPOExGQVlnRmZvdGthTFJkUzJVMm16?= =?utf-8?B?MGZ0NUpzbVpWaHkydnh1eXlXYmhnOTlzMDlyYzQ5cGp4ZEhmZFlLWkNoV0sv?= =?utf-8?B?dnZZOVlOb3lqS3pNRklMMWloYWxxRGRoWWRTUGhTYzVuK1RlaU9vS1p4M3A5?= =?utf-8?B?akk5K0JueVl4MGw2TW9VbFM4RzZ6TEpLazBGdktCeFdiZkhnSk0wMDdJV01H?= =?utf-8?B?WjdZT1JqYmQ0QlpGbUxaTDk1emVqVk0zdFI5VnlCclltSzJBbzd2SHFSME0r?= =?utf-8?B?R3FIbUxnbVptZFVQcFJpa0RxQldUclRmTE9LSGJyaVNTaUhpVWVyc3lxZm11?= =?utf-8?B?TE9kVWM2dHlmZXV1SThweld0VGVmb3V6aFM0U3lrdnNQV2xpbzJaL016MTc0?= =?utf-8?B?Ylh3dlIvbTVTVWR5Q1RBYzl1NmRTRHdqcXFwQXdIeWZTbXoreGJXTTBLUEhD?= =?utf-8?B?d2d4UXVpaFJWcFhjMHVVTnM0dDBlNnlja1hpMFlRcXZvTTgyMGRkUTdYcXM4?= =?utf-8?B?Njd0bElrcSs4T3E0RzZqd1Fkd0M3S3k3amdSU3ZsSTQyV1lLZGNVYzZ6S2or?= =?utf-8?B?Ui8rYkhDZWdDVGZKSUM2ZWlPdUprWW1EdTZiYWhEeGZlZThTOEI3a3Vxa0Fq?= =?utf-8?B?bG1kR3hKNUgrRkt6cFJZOGwyZTRhL2VCVTJFSkZTazZmYWxycUlDQ01QUWZF?= =?utf-8?B?VXlvc0UyZVZHMWFxYUU5K1RBS3NldGhhOW4xcExqSHJQcUlmZGJjdEtpd3ZJ?= =?utf-8?B?MzhKVU40aGN3bzJaYTEzNmMxeHNZam01MXpCQllrYWZPdHl2Z1oxZGk2WmJD?= =?utf-8?B?b2VoYmExejNTWlBvTXF1OFNoT203R0VWVmVrb0Y4ejJ6RGVacGp0QUtGbUFI?= =?utf-8?B?VkxZUHpGb2psWE0zVHloUjNHL3RRQURGSlhoVTdRTlB3UnJwMGhzMFNkams1?= =?utf-8?B?anh4YjNYVExnTUVoeHgwMDN0MGZwMDFYL0ZKM0lENmFwMkJiYTdZT1E2TTZo?= =?utf-8?B?SW1sR2tTSGpGMnpGUFBCNEMranJTeGdXd0szRjFQRUszVHBiQndPd0w0dUxV?= =?utf-8?B?dVA5UkNVQjI5amQ2MlRTRFZJeHlMRnRGNDgwZEdCWkN1Q3F4YmdHR2xQTnAw?= =?utf-8?B?Q2kxb2tWc3czeUU5R2lJMjNaZWZYZ3ZNKytGVDRaR281Q1dZYklpMWxSUHJE?= =?utf-8?B?aXFoV3owaGFEb0orU2orQXlPMmgzb0hqZXpBUDlhKytUY2dQN0s3Ylh1Nzg1?= =?utf-8?B?U2ZYZWs5aDI1RGlDSEVkc2JmMFk0ZjNBcVI2TFpSbFVrYWFoSWxTbkZ6TkF1?= =?utf-8?B?eUtLdno1MHhMYndadmlta3I0Qm9BMVRKbk9OaHRrd0JtOHFaK05jTEpGekhC?= =?utf-8?B?eFdZRmt2S3dTd0RKNCtZMEFDMlNPb0dHRDJHOTlucU1wZXorYnFjZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a724d41-7ad4-4ab8-d265-08df0cc579aa X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2026 09:50:40.0104 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: NhKhghMb9DGXmrl4nqnHUft3x4NqCD2scxTzR+s315c3gdTw5TjqBP1k6gMdxf2cmHWte93tSnWeDPM5Dt+gXnzgihXzASehJk/BZ8Y6aP8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5888 X-purgate-ID: tlsNG-d62444/1788774644-1D87F757-223C5636/0/0 X-purgate-type: clean X-purgate-size: 386 On 07/09/2026 10:48 am, Jan Beulich wrote: > Recent Clang complains about the "debug" static variable only ever being > written to. Drop it and the command line option controlling it. > > Fixes: 19ab8356abe4 ("tools: remove support for running a guest with qemu-traditional") > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Sep 07 09:52:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 09:52:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410764.1641566 (Exim 4.92) (envelope-from ) id 1x3W1J-0001ON-Qz; Mon, 07 Sep 2026 09:52:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410764.1641566; Mon, 07 Sep 2026 09:52:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3W1J-0001OG-Np; Mon, 07 Sep 2026 09:52:09 +0000 Received: by outflank-mailman (input) for mailman id 1410764; Mon, 07 Sep 2026 09:52:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3W1I-0001N3-RR for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 09:52:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3W1H-0038uo-0V; Mon, 07 Sep 2026 09:52:07 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x3W1H-008oZa-24; Mon, 07 Sep 2026 09:52:07 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=p78z3h/AnlFLx6eQ+HL1StCn11CfHHPV9pA0iQ+2uns=; b=zCirJZdH0Gf3jWfIsp5JVg9n8m q1lIEgb3kPApupz00qJG3aVNolQWe5rMSyVV1gLOZuWk5QpH6w42jFchOhEKXp5jNn2ud19ZFMYuy EsBRS2aBeTuzlCNP3MmmPmSDMkVSUhq+k4WJrwBl+DPrhMeCD2VcxWH1Upp4JhQxlTSQ=; Date: Mon, 7 Sep 2026 11:52:04 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] libacpi: drop mk_dsdt's -d / --debug option Message-ID: References: <13ebb85c-62c2-477b-87ff-377bbe3cfc6a@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <13ebb85c-62c2-477b-87ff-377bbe3cfc6a@suse.com> On Mon, Sep 07, 2026 at 11:48:12AM +0200, Jan Beulich wrote: > Recent Clang complains about the "debug" static variable only ever being > written to. Drop it and the command line option controlling it. > > Fixes: 19ab8356abe4 ("tools: remove support for running a guest with qemu-traditional") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 07 11:55:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 11:55:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410804.1641610 (Exim 4.92) (envelope-from ) id 1x3Xwq-0007BL-DH; Mon, 07 Sep 2026 11:55:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410804.1641610; Mon, 07 Sep 2026 11:55:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Xwq-0007BE-Ac; Mon, 07 Sep 2026 11:55:40 +0000 Received: by outflank-mailman (input) for mailman id 1410804; Mon, 07 Sep 2026 11:55:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Xwn-0007B5-W7 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 11:55:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Xwn-001C8S-CS for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 13:55:37 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ea62c-e002-0a2a0a5209dd-0a2a450ab44a-46 for ; Mon, 07 Sep 2026 13:55:37 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ea638-f2d2-0a2a450a0019-b9ff1c23b31d-3 for ; Mon, 07 Sep 2026 13:55:37 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a07bb94a33000c4f3.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 07 Sep 2026 11:55:35 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 1AE6881FD4; Mon, 7 Sep 2026 13:55:35 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=YjOE8REo2CBY71a9iSMAFpW+kTRW8M15Sl+pkAQMNcg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=L1A/BXYO+iZJLCc4uQp7LOtWCSWAscanujONuGSszB9hn6T0zDPUoGZYbwVabwy9a6goCSglz PqiL60Ff6RIA4ettMaSgC1a7BcBXXeBgiaqpmiuSs3gY7/JcstM2Aoc7KO/CWk2EbndnVWjERbQ 8doOinznqmuOHTfs7A5jLgmPjZukVfpYtQCa62J918aGsWDjmBofFs/ewajjxP8pB5AYfBcSdsn 3oBIjNK5/8lv9/k9oUsibcVJYhB4C6UvXk4M3E1MMa/fa4VXuW5D9o5dWkT12vFhOYpFs9Hvq6z xc2B494n45FYGiiIvvxP/2ysfrBdQ5VPmkQydT/L2NXw== X-Zone-Loop: 75edadf0f8b99601145d024117e651b3204e4512f6c0 x-campaign-type: default x-transaction-id: 668a922f-16b7-477e-84a6-e8d8ed50026f x-swg-uid: 01-b41cde92-c6b1-4d64-94d2-b12cbe190249 X-Mailer: Sweego Message-ID: <1788782135.8631fc262581453bbf619ec5b2062170.1a07bb94a33000c4f3@vates.tech> x-swg-bid: 1788782135.8631fc262581453bbf619ec5b2062170.1a07bb94a33000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: qemu-devel@nongnu.org Cc: Anthony PERARD , Stefano Stabellini , "Edgar E. Iglesias" , xen-devel@lists.xenproject.org, Julian Vetter Subject: [PATCH] hw/xen: Prepare qemu for multi-ioreqpage support Date: Mon, 7 Sep 2026 13:55:28 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.37f2.6c69314bc0b464d5.1a07bb947b7.d34544470c674e2=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788782135226 X-purgate-ID: tlsNG-4011c0/1788782137-5A5DBCFC-2339E7C1/0/0 X-purgate-type: clean X-purgate-size: 7926 ---=Part.37f2.6c69314bc0b464d5.1a07bb947b7.d34544470c674e2=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable When Xen gains support for ioreq servers backed by more than a single ioreq page, which is needed once a domain's vCPU count exceeds what fits on one page (XC_PAGE_SIZE / sizeof(ioreq_t) =3D 128 vCPUs), Qemu needs to be extended to request as many ioreq frames as the domain's max vCPU count requires, via xen_map_ioreq_server() and treat the mapped ioreq region as a flat array of ioreq_t rather than a single shared_iopage_t=2E To support this, xen_map_ioreq_server() now takes max_cpus and computes the number of required ioreq frames and then requests that many frames from the resource-mapping API=2E XenIOState::shared_page is changed from shared_iopage_t * to ioreq_t *, and xen_vcpu_eport()/xen_vcpu_ioreq() index it directly as a flat array, matching how the Xen side will lay out multiple ioreq pages contiguously via vmap()=2E Also guard against hosts that don't support multi-page ioreq servers=2E Currently the xen_get_ioreq_server_info()/xenforeignmemory_map() path only gives out a single ioreq page, so bail out instead of silently mapping fewer pages than max_cpus needs=2E Continuing past that one page leaves xen_vcpu_eport()/xen_vcpu_ioreq() reading and writing past the single mapped page for vCPUs beyond the first 128=2E Likewise, a host that recognizes XENMEM_resource_ioreq_server but predates multi-page support rejects frame indices beyond the legacy bufioreq/ioreq pair with EINVAL=2E Signed-off-by: Julian Vetter --- This patch is the QEMU counterpart to the corresponding Xen-side ioreq multi-page series, which adds support to expose more than one ioreq frame per server depending on the number of vCPUs: https://lore=2Ekernel=2Eorg/xen-devel/20260420093820=2E825969-1-julian=2Ev= etter@vates=2Etech/ As long as this series hasn't landed this patch has no effect, other than explicitly rejecting requests for HVM domains with more than 128 vCPUs=2E But, this isn't currenly possible because HVM_MAX_VCPUS is still 128 in Xen=2E So, on an unmodified Xen, num_ioreq_pages can never exceed 1=2E This patch and the series for Xen is just preparatory work=2E Once a patch raises the HVM_MAX_VCPUS the ioreq server code is ready=2E --- hw/xen/xen-hvm-common=2Ec | 39 ++++++++++++++++++++++++++++----- include/hw/xen/xen-hvm-common=2Eh | 10 ++++----- 2 files changed, 38 insertions(+), 11 deletions(-) diff --git a/hw/xen/xen-hvm-common=2Ec b/hw/xen/xen-hvm-common=2Ec index 62d88804c4=2E=2Ede729ead95 100644 --- a/hw/xen/xen-hvm-common=2Ec +++ b/hw/xen/xen-hvm-common=2Ec @@ -677,16 +677,19 @@ void xen_exit_notifier(Notifier *n, void *data) xs_daemon_close(state->xenstore); } =20 -static int xen_map_ioreq_server(XenIOState *state) +static int xen_map_ioreq_server(XenIOState *state, unsigned int max_cpus) { void *addr =3D NULL; xen_pfn_t ioreq_pfn; xen_pfn_t bufioreq_pfn; evtchn_port_t bufioreq_evtchn; - unsigned long num_frames =3D 1; - unsigned long frame =3D 1; + unsigned long num_ioreq_pages; + unsigned long num_frames; + unsigned long frame; int rc; =20 + num_ioreq_pages =3D DIV_ROUND_UP(max_cpus, XC_PAGE_SIZE / sizeof(iore= q_t)); + /* * Attempt to map using the resource API and fall back to normal * foreign mapping if this is not supported=2E @@ -696,7 +699,10 @@ static int xen_map_ioreq_server(XenIOState *state) =20 if (state->has_bufioreq) { frame =3D 0; - num_frames =3D 2; + num_frames =3D 1 + num_ioreq_pages; + } else { + frame =3D 1; + num_frames =3D num_ioreq_pages; } state->fres =3D xenforeignmemory_map_resource(xen_fmem, xen_domid, XENMEM_resource_ioreq_server, @@ -711,6 +717,17 @@ static int xen_map_ioreq_server(XenIOState *state) state->buffered_io_page =3D addr; state->shared_page =3D addr + XC_PAGE_SIZE; } + } else if (errno =3D=3D EINVAL && num_ioreq_pages > 1) { + /* + * The host may predate support for more than a single ioreq fram= e + * (i=2Ee=2E it rejects any frame index beyond the single bufiore= q/ioreq + * pair with EINVAL)=2E We can't run this many vCPUs without an i= oreq + * slot for each of them=2E + */ + error_report("Xen does not support mapping %lu ioreq pages " + "(needed for %u vCPUs)", + num_ioreq_pages, max_cpus); + return -1; } else if (errno !=3D EOPNOTSUPP) { error_report("failed to map ioreq server resources: error %d hand= le=3D%p", errno, xen_xc); @@ -740,6 +757,17 @@ static int xen_map_ioreq_server(XenIOState *state) if (state->shared_page =3D=3D NULL) { trace_xen_map_ioreq_server_shared_page(ioreq_pfn); =20 + if (num_ioreq_pages > 1) { + /* + * The legacy get_ioreq_server_info()/map() path only eve= r + * hands out a single ioreq page, so it has no way to giv= e us + * ioreq slots for every vCPU=2E + */ + error_report("ioreq server fallback path supports only 1 = " + "ioreq page=2E %lu pages are needed for %u v= CPUs", + num_ioreq_pages, max_cpus); + return -1; + } state->shared_page =3D xenforeignmemory_map(xen_fmem, xen_dom= id, PROT_READ | PROT_WR= ITE, 1, &ioreq_pfn, NULL= ); @@ -840,7 +868,7 @@ static void xen_do_ioreq_register(XenIOState *state, */ qemu_register_wakeup_support(); =20 - rc =3D xen_map_ioreq_server(state); + rc =3D xen_map_ioreq_server(state, max_cpus); if (rc < 0) { goto err; } @@ -857,7 +885,6 @@ static void xen_do_ioreq_register(XenIOState *state, =20 state->ioreq_local_port =3D g_new0(evtchn_port_t, max_cpus); =20 - /* FIXME: how about if we overflow the page here? */ for (i =3D 0; i < max_cpus; i++) { rc =3D qemu_xen_evtchn_bind_interdomain(state->xce_handle, xen_do= mid, xen_vcpu_eport(state->share= d_page, diff --git a/include/hw/xen/xen-hvm-common=2Eh b/include/hw/xen/xen-hvm-co= mmon=2Eh index d177ff14ea=2E=2E7a0037aa45 100644 --- a/include/hw/xen/xen-hvm-common=2Eh +++ b/include/hw/xen/xen-hvm-common=2Eh @@ -25,13 +25,13 @@ extern DeviceListener xen_device_listener; =20 #define XEN_GRANT_ADDR_OFF (1ULL << 63) =20 -static inline uint32_t xen_vcpu_eport(shared_iopage_t *shared_page, int i= ) +static inline uint32_t xen_vcpu_eport(ioreq_t *shared_page, int i) { - return shared_page->vcpu_ioreq[i]=2Evp_eport; + return shared_page[i]=2Evp_eport; } -static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int v= cpu) +static inline ioreq_t *xen_vcpu_ioreq(ioreq_t *shared_page, int vcpu) { - return &shared_page->vcpu_ioreq[vcpu]; + return &shared_page[vcpu]; } =20 #define BUFFER_IO_MAX_DELAY 100 @@ -53,7 +53,7 @@ typedef struct XenPciDevice { =20 typedef struct XenIOState { ioservid_t ioservid; - shared_iopage_t *shared_page; + ioreq_t *shared_page; buffered_iopage_t *buffered_io_page; xenforeignmemory_resource_handle *fres; QEMUTimer *buffered_io_timer; --=20 2=2E53=2E0 -- | Vates XCP-ng & Xen Orchestra - Vates solutions web: https://vate= s=2Etech ---=Part.37f2.6c69314bc0b464d5.1a07bb947b7.d34544470c674e2=--- From xen-devel-bounces@lists.xenproject.org Mon Sep 07 12:18:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 12:18:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410817.1641620 (Exim 4.92) (envelope-from ) id 1x3YIp-0003Q4-7A; Mon, 07 Sep 2026 12:18:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410817.1641620; Mon, 07 Sep 2026 12:18:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3YIp-0003Px-4K; Mon, 07 Sep 2026 12:18:23 +0000 Received: by outflank-mailman (input) for mailman id 1410817; Mon, 07 Sep 2026 12:18:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3YIo-0003Pr-26 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 12:18:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3YIm-00Fa8y-SL for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 14:18:20 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9eab80-8faa-0a2a0a5109dd-0a2a450896f4-34 for ; Mon, 07 Sep 2026 14:18:20 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9eab8c-f659-0a2a45080019-d155802aad22-3 for ; Mon, 07 Sep 2026 14:18:20 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b0dd3c9a0so33525945e9.1 for ; Mon, 07 Sep 2026 05:18:20 -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 ffacd0b85a97d-4858d2693e8sm26986931f8f.3.2026.09.07.05.18.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 05:18:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788783500; x=1789388300; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=WAjQRnMuZxIfoU4dVrnh2A6T7GTY+WeJHUk/vwuM5xw=; b=a5oRBdn1rHk63QE4liMbrWE/RJrGcrBTwVjNk19rFCWBvgWGA5EWrxV1V0yk75rfyn xLtQcTVxpq05bbRnP9Cms7ZPHJgf55bxzGg/8/ES/NzSK7fWYMQyWJvRoCB7vjJnFs+N JpxjCZPXc1GBQECQjqCoYnoJHwSVyTW4P3yi5QFxBFWBaQWQinLJiDDTm+La4xfXGJcy vSYd7Pj0yl+hzMaxeyJ96+oKihOvxsQi0lOEYtJe2Tb8h+K9fVa6Ub+8I0TmFLul0oCO 8EhPoRnAlaUOODEyUA1t+qg6IDwUfTQP8+93txkmLUKH5bhxCuU1oQf+n9Y0SfhO6+ou dn2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788783500; x=1789388300; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=WAjQRnMuZxIfoU4dVrnh2A6T7GTY+WeJHUk/vwuM5xw=; b=QI5T3E7nml6ezF1eggSTt5jVd3U7W2RB0ZBCGyMnz81/M52wDzX4U8TwtX+KZpP/dX pkY3Rwmcdb8atDoY09D5XGLNW7PP1cZINKUslRdk/r0xpa0h2VayvvV1eHg6mmZT/OQl DAj9md5tZmH9fmsrSkZK25e38Yck/JZmuwtutKrSOIRtxO4lo6A5DRTdAu3uyQOGxxNb daOkK3SK79Yjf4H1SYR9B/tpTItITltQTna7qGtHpewV5Aw7Fk6VamE3aRjKG3UnZoBU yrbDuI9ImWRYxCJNTYcaGY8IiZYhQArqd7J/dhlTnjY7MuQAMoPetmtEKv4i6ZrE+2iA i9lQ== X-Gm-Message-State: AFuF++lwoBrW9KoOIVpeHWCW7Y/6biVj2pj2o0EjJVambDZjY0KgWcn2 DSG35zscugxvSh0pEWYjwlSl3gHRejMUEBZzqBK0WYmIoEbQY5nxb1KZj2REH5X3dOMKJX1w6AI PXiEkfA== X-Gm-Gg: AYBFou0aGwB/PT600Tv7uFe9nFUSoOle21a4E8gsU0WZuGtQay/KwICJC4AS7e2kIr+ +HcqoqPp1t2b86dcZQVK29x35l8hbL2dVgti2NwZNFTp4DSOtklR5OK1Uo56ATZ0D25sCUmv1kN Q/zZVec7e1PqjoWQFb+fc7ECeG49kpJPq6dmireN8wqD+gl0sGj0fzoCAFeIjMaXsVSefEjuxX7 1sBb7ssTzkMwZZQezAbnnmvITJRdNngNDuaZ0xLnleB3clvFKHtk4iDx3D9gUoseEYYJ/Xdp47Z BV0T9kfhWGDUD6wuPb6EdMh4cUEDqxhCa5A8ZPaXGuRJGa0lVcwM88R+XnK5GjKoBk43pAnEvtB MU7lGKFjL35y/ysLZSwdecXKVP1SzsrJtY/HxxRxUPIa1Y0I25bh3jyx0iSzx+78KNbys3HdK8C sbYqQUqPIQE47RRc48xYaxBEA5kP2324Ie17WdZ+oV13g7gXyGAfqigDa4nziJWUQpNEcu0PAMr r8kJ2/vvcyT+8mGY1pNWJosQQShTtoqe4UoucXlxUUoDo3HrEQP X-Received: by 2002:adf:e19e:0:b0:482:dac8:cd0d with SMTP id ffacd0b85a97d-48587288cddmr47851359f8f.21.1788783500173; Mon, 07 Sep 2026 05:18:20 -0700 (PDT) Message-ID: <0d40567f-6527-419a-a210-65e74bef988b@suse.com> Date: Mon, 7 Sep 2026 14:18:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] build: also exclude .data.rel.ro in $(cmd_obj_init_o) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788783500-CE34587B-9791E135/0/0 X-purgate-type: clean X-purgate-size: 1254 .data.rel.ro really is merely a special case of .rodata: r/o data, but with runtime relocations (not relevant to Xen), i.e. r/o only after relocations were performed (by the dynamic loader). Signed-off-by: Jan Beulich --- .*.local did already cover gcc's use of .data.rel.ro.local, but doesn't cover Clang using e.g. .data.rel.ro..Lswitch.table.. Beyond exclusion being similarly (slightly) fragile as that of .rodata, there's an extra naming issue here: A writable file scope variable named "ro" with an initializer taking the address of another identifier would, with -fdata-sections and -fpic, be put in .data.rel.ro by gcc (Clang uses .data.ro irrespective of -fpic). See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127240. --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -263,7 +263,7 @@ quiet_cmd_obj_init_o = INIT_O $@ define cmd_obj_init_o $(OBJDUMP) -h $< | while read idx name sz rest; do \ case "$$name" in \ - .*.local) ;; \ + .*.local|.data.rel.ro|.data.rel.ro.*) ;; \ .text|.text.*|.data|.data.*|.bss|.bss.*) \ test $$(echo $$sz | sed 's,00*,0,') != 0 || continue; \ echo "Error: size of $<:$$name is 0x$$sz" >&2; \ From xen-devel-bounces@lists.xenproject.org Mon Sep 07 12:24:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 12:24:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410828.1641649 (Exim 4.92) (envelope-from ) id 1x3YP9-0005Up-2t; Mon, 07 Sep 2026 12:24:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410828.1641649; Mon, 07 Sep 2026 12:24:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3YP8-0005Ui-W5; Mon, 07 Sep 2026 12:24:54 +0000 Received: by outflank-mailman (input) for mailman id 1410828; Mon, 07 Sep 2026 12:24:54 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3YP8-0005Uc-1i for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 12:24:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3YP7-00FbWY-3f for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 14:24:53 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ead09-8faa-0a2a0a5109dd-0a2a4509b37a-40 for ; Mon, 07 Sep 2026 14:24:52 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ead14-be1a-0a2a45090019-d155802ccd4f-3 for ; Mon, 07 Sep 2026 14:24:52 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-498028b3d5eso33191175e9.1 for ; Mon, 07 Sep 2026 05:24:52 -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 ffacd0b85a97d-4858d312ca0sm28162430f8f.4.2026.09.07.05.24.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 05:24:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788783892; x=1789388692; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Bl/qQ2SfhfVrk4NuGod2kJzGCRtkuRD03XNrSIn0gi4=; b=BbQHTPXQT0Ba4pa30qPl2HmqMUS7GfIHMZdVEoLo4lbV6QTmcO3qZGysSHUHgAXKTs QGlRMo/47mZlmQz1iyhD4o0oupZdRUVCCrgEJlGacXSbV9fdntpF2sKRuZ6UlJjj+KZ4 AuDnD8f6sNFl/MaKPtmE7UNKEL6qIoNJFNFoWME+DmqH0CeqsY/ji9qvojHzbA7JF4v1 xtBTRMOTfoLOHxqSWHjks6As1ZsAhMd9jcjZ+krrdNRahpQDVICVGLtpOI22oABr2m3w Dh+j2JQSrA83V0JJFQlKAo4YmgEu1eIb0GnK14C9pH9wGgtdNrjppcuplIfFD/BqMcUq e0LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788783892; x=1789388692; h=content-transfer-encoding:content-type: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:content-type; bh=Bl/qQ2SfhfVrk4NuGod2kJzGCRtkuRD03XNrSIn0gi4=; b=M+dEFbQLnpi5PmJks0gy272zHxztGzOEuBXNxRA71jaRNXQGJWPISeS2dBzDRo6zNh M54qF4SN8Fe9o5zkUIF1qUoGRujtMm9okAwOTRnNjhRyacLpBB1Pn6y35sJ222SlhrpZ lppvMy3OmE8GdY2QJ6OOhOfwxdZlaN1oa/ljtubtz5ZMUVdfFlWqVkgl5JUu5VtWTO1G vvWjEhnFdbfuaIhlkrQ1mRUXD/rowEB2H2fnBCp3bU10yRPcJoNuoYbBlux01918oH+W NAVqBP2Tpi1EinrQuHqjHPSTDA69cmJc/ax6O+U5EOvgNODm57RSv1d00hDiBrN6mjhK CqcQ== X-Forwarded-Encrypted: i=1; AKwUvBxrazheefJ9uhfhIsOcKbUUm1BsrWUx2Tq9kPUnIUox/0QTVkZRLohHA5RqifXKCREXhYzC7Hu1M0c=@lists.xenproject.org X-Gm-Message-State: AFuF++k/a4vRss+JX9AebEWSN5OXCqwKppP/bokGyYzMCeZ74htLeAe4 85JrWvAstxknuUfyaErCo4xaf11UFSbiqFC1TgXcKhA6Xa3lbR4IPqTizMc2YRIcZA== X-Gm-Gg: AYBFou2F+WfGXt2I7gGQpEPCASrFipfi03axMMBeqUC81bWR9NN+q6dOZKk7nnm5spm kZFCaYE5PJD2xcX4Q/80SBW7dAKadMd0+ieQLWIop7lJpoT1hTpC/6i9GbO4GZX4Hk6w4SB6A9R KaUar6rjfUn97lqVGL+zdgZjMImoGPR6dJPkaR0ZTdvp+VUFdnO2CxHRhFgeXx5kQr/bj7+z9io suj7gKlqhjAgLAnAjpkFV8Wosm67KV4zgo2QjTwF9IIbTyLtlT1bwZLlvTtxr9sdfxyaWKD0qqH epmkfyHrmoKWogZWSxfILiIr3bJT/ir3tRBZ/tYBuluqRpkKh23jOu353VeVZ8lXwGoqBV6qXHO KX2SlxXDl7WvA6pn2xpVxKY4Qd59aqFXjY2teHKlIOfx4osc8VLAkWDPDBWTRkKiwlN4/oVQUHW Q9uy+xSOpAJSQfQ8YNqcyH31Z2YXfXMEnNdvcPuHuaUwEhUCAzydSpL9YRRz6K3uGN6qltriLEq AKeupIIfT4tR6uMHsgTq4qypHY6kXVT3PluwlmOKK9+xWAn75LU X-Received: by 2002:a05:600c:8708:b0:49c:fa21:1c7c with SMTP id 5b1f17b1804b1-49cfa211d48mr194996565e9.17.1788783892277; Mon, 07 Sep 2026 05:24:52 -0700 (PDT) Message-ID: Date: Mon, 7 Sep 2026 14:24:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/svm: Intercept CR0 writes selectively To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260904122330.306936-1-ross.lagerwall@citrix.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: <20260904122330.306936-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788783892-FC212034-6DA51CC8/0/0 X-purgate-type: clean X-purgate-size: 3202 On 04.09.2026 14:23, Ross Lagerwall wrote: > Since 3356d685dbda ("x86/svm: Remove lazy FPU support"), Xen does not > need to track when the TS or MP bits change so opt to intercept CR0 > writes selectively. Aside from potentially reducing a few VMEXITs, this > fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE and L0 > intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so L1 never > sees any CR0 writes. > > Since CR0 may now change behind Xen's back, sync it on VMEXIT so that > the emulator sees the correct value. > > Signed-off-by: Ross Lagerwall Reviewed-by: Jan Beulich with two remarks (which I may take the liberty of carrying out while committing): > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -50,13 +50,13 @@ static int construct_vmcb(struct vcpu *v) > struct vmcb_struct *vmcb = svm->vmcb; > > vmcb->_general1_intercepts = > - GENERAL1_INTERCEPT_INTR | GENERAL1_INTERCEPT_NMI | > - GENERAL1_INTERCEPT_SMI | GENERAL1_INTERCEPT_INIT | > - GENERAL1_INTERCEPT_CPUID | GENERAL1_INTERCEPT_INVD | > - GENERAL1_INTERCEPT_HLT | GENERAL1_INTERCEPT_INVLPG | > - GENERAL1_INTERCEPT_INVLPGA | GENERAL1_INTERCEPT_IOIO_PROT | > - GENERAL1_INTERCEPT_MSR_PROT | GENERAL1_INTERCEPT_SHUTDOWN_EVT| > - GENERAL1_INTERCEPT_TASK_SWITCH; > + GENERAL1_INTERCEPT_INTR | GENERAL1_INTERCEPT_NMI | > + GENERAL1_INTERCEPT_SMI | GENERAL1_INTERCEPT_INIT | > + GENERAL1_INTERCEPT_CR0_SEL_WRITE | GENERAL1_INTERCEPT_CPUID | > + GENERAL1_INTERCEPT_INVD | GENERAL1_INTERCEPT_HLT | > + GENERAL1_INTERCEPT_INVLPG | GENERAL1_INTERCEPT_INVLPGA | > + GENERAL1_INTERCEPT_IOIO_PROT | GENERAL1_INTERCEPT_MSR_PROT | > + GENERAL1_INTERCEPT_TASK_SWITCH | GENERAL1_INTERCEPT_SHUTDOWN_EVT; I think it would be nice to avoid moving the |-s out, to keep ... > vmcb->_general2_intercepts = > GENERAL2_INTERCEPT_VMRUN | GENERAL2_INTERCEPT_VMMCALL | > GENERAL2_INTERCEPT_VMLOAD | GENERAL2_INTERCEPT_VMSAVE | ... aligning with the ones here. > @@ -76,8 +76,12 @@ static int construct_vmcb(struct vcpu *v) > /* Intercept all debug-register writes. */ > vmcb->_dr_intercepts = ~0u; > > - /* Intercept all control-register accesses except for CR2 and CR8. */ > - vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR2_READ | > + /* > + * Intercept all control-register accesses except for CR0 writes (use > + * selective write instead), and CR2 and CR8 reads/writes. > + */ Imo slightly more precise as "... (using selective write intercept instead) ..." Jan > + vmcb->_cr_intercepts = ~(CR_INTERCEPT_CR0_WRITE | > + CR_INTERCEPT_CR2_READ | > CR_INTERCEPT_CR2_WRITE | > CR_INTERCEPT_CR8_READ | > CR_INTERCEPT_CR8_WRITE); From xen-devel-bounces@lists.xenproject.org Mon Sep 07 12:51:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 12:51:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410842.1641658 (Exim 4.92) (envelope-from ) id 1x3YoO-0002BI-24; Mon, 07 Sep 2026 12:51:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410842.1641658; Mon, 07 Sep 2026 12:51:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3YoN-0002BB-V6; Mon, 07 Sep 2026 12:50:59 +0000 Received: by outflank-mailman (input) for mailman id 1410842; Mon, 07 Sep 2026 12:50:59 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3YoN-0002B5-7K for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 12:50:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3YoM-009i7H-K8 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 14:50:58 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9eb321-8faa-0a2a0a5109dd-0a2a4508ed1a-40 for ; Mon, 07 Sep 2026 14:50:58 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9eb332-f659-0a2a45080019-d155802fc166-3 for ; Mon, 07 Sep 2026 14:50:58 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49b8687630fso30192725e9.3 for ; Mon, 07 Sep 2026 05:50:58 -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-49d057f4778sm206232265e9.8.2026.09.07.05.50.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 05:50:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788785458; x=1789390258; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=KDQnOlJQJah94QU/wb3zuGNWKdlBM18vyiNCWzXsH+o=; b=cHjQIUGBg09qflUncPykA1eeXnZTwyqznBpmPkoZt8ix2ZkI3FL7JA/mFRSuA3ub6B /wgWzx1J073cnR3I3RoGF8WhiphHPYCPA+aWRvIttar2NCfnu5Ys33u451GiNP6cSqFw uG5cyRMZo7aQT1vI3R4+Sfth5t3oWZM34GwM4yRf387NV7clcstJGPXiXdXJUBr2IwHK MeGiOt2OS/CzKSMbSFNwM/2YZOVL1CReQShsT2/Z3wnMl4jG158dHWTzn1ExXT9lFeLC evHPrO8Dilbpgi180Tt5J3R+3h8sOPz7Ga/RhhoiJX32nBUuOD7jn8agYAEYPS0F6HjV eQ2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788785458; x=1789390258; h=content-transfer-encoding:content-type: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:content-type; bh=KDQnOlJQJah94QU/wb3zuGNWKdlBM18vyiNCWzXsH+o=; b=ArnLEwj/dF5yHlEWWAcR3jZAjIsUfpC6RjxbY3MLi5PiDafqXGL4zLvAwh0kqCDuJS NLkyA32o0urfBMEtg+gltYsyl4oWbMqO7qoYNSGjJwqftZ9sp4tAZ4CftqyHp/irYl9K 1+vRNELLbnEBY+N2FD/9vG5IZAcRKxUPDMdOwN1MpOYuAMfjgjW2b55kmFaIxoGoxXZr +KweHNxYqd1eIdEb6rS0owF271tICguScmKuoAiFFU9LyTnFEjUh1w7183h/zhQcgHbg 81qdejc3JymC43uWc5qlfuRB/HkDMx0fYeI6lNrQXdx7hmOP7/A4y2FCdhahG8f7izL3 KiBQ== X-Forwarded-Encrypted: i=1; AKwUvBxwT7KLlEaLDmp8lzGDvs8K/MAuXAveNP9tpmWz6kFAqwMtRws7ZdwL9lMo0CzV+J6D/HY1XCrJBzo=@lists.xenproject.org X-Gm-Message-State: AFuF++ndPFTI/ggZ31PR+fYANQcHQhPz4W43OrfEwYGVq1SjFD84Vj1X ysOqNq7s00PRqdwpAsjZFJ3SwltoOxnjYC1mDVsdiFyZPp3d0BtiGcfvZO7fCO4iyg== X-Gm-Gg: AYBFou3MeNa5CuywPx+asG4pIrtlQ+ub06A9Fm0tpuJNHB/bAbQyfW5PfUhyWLlnU5J 2kehWj1ZSHgBYWh4olzhJzduWP35VUOvwpiYQak5tRREzymFThxFWSCUA/tjdkkUdk72VPV0MDe m78BAUfMQPFnR1h2iTujOAsqxxJ7GarIl0MkPawUYJeZbrLaEItz00bEVbx/ACOPMzo82f0C5cF YIrsMQpifv4RTXcGoNUc55i/Skbdl4jaJB3CKE1JMoH1WaGqUzlzKEj9idiHDAZMcReIqGvJOVP d3pej+LeCH+PlzopahnJ9Jqdit/7zaDzQsTZ4J/6RDSDz+h41m9rqYd7OV+QAPrB4H8XszxEFVP aWHR3o1uV4FBvbctJR3Sybb7ZG9IdNiZvdZ4alUKiAAI18XC4nRDWIEC9o73+lPeMTBbDNFEnu0 PIn3M1fn9vpIvtrerl5pue6S/9mAAs+35pNhSrgwpvPD+f6K0A1xglHAUt7BIjSDrSno22wHTnL h4zLV9CpCJM8oyBS7j63Wy9zwsyFCgSejebHB3jz/syAYG1ozckJOV+11cMeqY= X-Received: by 2002:a05:600c:a40f:b0:49c:fa21:e74b with SMTP id 5b1f17b1804b1-49cfa21e9a7mr152484925e9.33.1788785457867; Mon, 07 Sep 2026 05:50:57 -0700 (PDT) Message-ID: <39118b9f-2c63-4523-a7c6-76cc25d43163@suse.com> Date: Mon, 7 Sep 2026 14:50:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/14] x86/pv: set/clear guest GDT mappings using populate_perdomain_mapping() To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-4-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-4-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788785458-CDB4987B-C402601F/0/0 X-purgate-type: clean X-purgate-size: 3879 On 02.09.2026 11:43, George Dunlap wrote: > From: Roger Pau Monné > > Until the previous patch, update_xen_slot_in_full_gdt() used the Please can we avoid "previous patch" (also again below) and alike in commit messages? > stashed pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming > vCPU's page tables with Xen's GDT; this was previously necessary > because map_domain_page() couldn't be called in a context switch. > Having a handy pointer to an always-mapped version of the GDT/LDT L1 > table, other sites which modify the table started using it for > convenience, even if they weren't called from within a context switch. > One example is pv_{set,destroy}_gdt(). > > The previous patch switched the main user of the stashed reference to > use populate_perdomain_mapping() instead. Continue that process by > switching both pv_{set,destroy}_gdt() to it as well. > > pv_destroy_gdt() currently loops over the L1 entries directly, > extracting the MFN from each, dropping the type and reference unless > it was the zero page, and replacing the entry with a read-only mapping > of the zero page. Rather than reading from the stashed L1, drop the > references using v->arch.pv.gdt_frames[] instead, and install the > zero-page mappings with a single populate_perdomain_mapping() call. > This makes gdt_frames[] consistently the source of truth for MFNs. > > Note that we must maintain the invariant introduced in cf6d39f819 > ("x86/PV: properly populate descriptor tables"): pv_destroy_gdt() maps > the zero page read-only in torn-down slots rather than unmapping them, > so that LAR/LSL/VERR/VERW on a selector beyond the guest's limit clear > ZF as on native rather than taking a #PF-converted #GP. (And since > pv_set_gdt() tears down the old GDT before installing the new one, > guests never see unmapped entries, only zero-page entries.) > > In the case of pv_set_gdt(), we have a slightly awkward situation with > types. The ABI with the guest uses unsigned long[], but > populate_perdomain_mapping() wants an array of mfn_t. > v->arch.pv.gdt_frames being unsigned long means we can just copy from > it across the guest ABI with no conversions. We could in theory > convert it to mfn_t[] instead, and then pass v->arch.pv.gdt_frames > into populate_perdomain_mapping(); but then we'd need to add a > conversion on all the places where frames are copied out. We choose > instead to copy frames into a temporary mfn_t array on the stack to > pass into populate_perdomain_mapping(). > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 > Signed-off-by: George Dunlap With the adjustment above: Reviewed-by: Jan Beulich > --- a/xen/arch/x86/pv/descriptor-tables.c > +++ b/xen/arch/x86/pv/descriptor-tables.c > @@ -49,33 +49,42 @@ bool pv_destroy_ldt(struct vcpu *v) > > void pv_destroy_gdt(struct vcpu *v) > { > - l1_pgentry_t *pl1e = pv_gdt_ptes(v); > - mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page)); > - l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO); > + const mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page)); > + mfn_t zero_mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)]; I wonder if having an initializer here might not result in better code. The array could likely be filled with REP STOSQ here, and ... > unsigned int i; > > ASSERT(v == current || !vcpu_cpu_dirty(v)); > > v->arch.pv.gdt_ents = 0; > - for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ ) > + > + for ( i = 0; i < ARRAY_SIZE(zero_mfns); i++ ) > { > - mfn_t mfn = l1e_get_mfn(pl1e[i]); > + zero_mfns[i] = zero_mfn; ... the live range of zero_mfn would reduce to about nothing. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 13:52:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 13:52:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410871.1641674 (Exim 4.92) (envelope-from ) id 1x3Zld-00052R-DI; Mon, 07 Sep 2026 13:52:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410871.1641674; Mon, 07 Sep 2026 13:52:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Zld-00052K-AA; Mon, 07 Sep 2026 13:52:13 +0000 Received: by outflank-mailman (input) for mailman id 1410871; Mon, 07 Sep 2026 13:52:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Zlb-00052E-JJ for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 13:52:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Zla-000gWE-Oj for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:52:10 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ec179-2eae-0a2a0a5409dd-0a2a4506abaa-44 for ; Mon, 07 Sep 2026 15:52:09 +0200 Received: from [18.216.144.57] (helo=yurei.relay-egress.a.mail.umich.edu) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ec182-195a-0a2a45060019-12d89039abdc-3 for ; Mon, 07 Sep 2026 15:52:04 +0200 Received: from stately-duende.authn-relay.a.mail.umich.edu (ip-10-0-72-237.us-east-2.compute.internal [10.0.72.237]) by yurei.relay-egress.a.mail.umich.edu with ESMTPS id 6A9EC181.384435A2.5BB17DE6.837726; Mon, 07 Sep 2026 09:52:01 -0400 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by stately-duende.authn-relay.a.mail.umich.edu with ESMTPSA id 6A9EC181.8EF07DF.4ABD0CEC.892931; Mon, 07 Sep 2026 09:52:01 -0400 Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-3a33307ecd9so39108451fa.2 for ; Mon, 07 Sep 2026 06:52:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-2 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1788789121; bh=YNHbCtSnVPR8dGzK+lBth6MAGgEKazLdKLPlhiNoHeE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=BeHgazNSYi0XVbhWtNzVuaGB6z9KuI20qW9W5/I3d3WyO1RDXNbOUGpFW/CiYX/La Txcpdo0/2Ro/5s1XJ3g5cTsDzWCf49xEpvJilYZqKM/qfPn6SSkdHAxbM+hPePzkkI ME9wImbCd588hqtKQ1rXCdYuF/oc151mekVWjIIz0xc5o7QIk75WBkHQCqvWShR+cO LXcvOEWz2FaTRZ9ABbV7D6oucVamEMU8GFkb/GEnTgYNpAA4oGTsU1zunrgVRYs0vv fE2Rq89SBZD6r/C22/N5o7SsMVRb5scCwnqyXPiaXG9cBsILz/GfDe082FKltIpX88 BpaJzclx6u31Q== Authentication-Results: stately-duende.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.208.169 (mail-lj1-f169.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvBx24d9EvEs++3seCwC1oBlLwpsNOSWx9mSNa/PvNQ2ZI0cFTXNQvhEdfZqHSy5TUO70iR9s+2sTPDo=@lists.xenproject.org X-Gm-Message-State: AFuF++l32WHBXSpdxclLiQIwGHlm5FT89ndJqyipCP12KtFm9zVUKaes eJX571/2EY8QluH6K1JW10a0yiUg37iXPuNUMae6DtklQ7732P5JULuxT1gdXS/TrmQsYKHpUih f2XMwJEln4tKCedga6ElZb9JHjOMVqD8= X-Received: by 2002:a05:651c:b26:b0:3a3:7681:6d58 with SMTP id 38308e7fff4ca-3a376817465mr19637121fa.16.1788789118905; Mon, 07 Sep 2026 06:51:58 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-4-ecc269f268b7@xenproject.org> <39118b9f-2c63-4523-a7c6-76cc25d43163@suse.com> In-Reply-To: <39118b9f-2c63-4523-a7c6-76cc25d43163@suse.com> From: George Dunlap Date: Mon, 7 Sep 2026 14:51:45 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1WV-VpuqnwSn5zZyD5mv8C8CtvmIPZ757oTGi1XPHCwvRzAgU2KAB2xwnM Message-ID: Subject: Re: [PATCH v2 04/14] x86/pv: set/clear guest GDT mappings using populate_perdomain_mapping() To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-16d1c6/1788789129-F74C977B-84893CF7/0/0 X-purgate-type: clean X-purgate-size: 3054 On Mon, Sep 7, 2026 at 1:51=E2=80=AFPM Jan Beulich wrot= e: > > On 02.09.2026 11:43, George Dunlap wrote: > > From: Roger Pau Monn=C3=A9 > > > > Until the previous patch, update_xen_slot_in_full_gdt() used the > > Please can we avoid "previous patch" (also again below) and alike in > commit messages? Something like this then? 8<--- update_xen_slot_in_full_gdt() used to update the incoming vCPU's page tables with Xen's GDT through the stashed pointer in d->arch.pv.gdt_ldt_l1tab, because map_domain_page() couldn't be called in a context switch. Having a handy pointer to an always-mapped version of the GDT/LDT L1 table, other sites which modify the table started using it for convenience, even though they aren't called from within a context switch. One example is pv{set,destroy}gdt(). With update_xen_slot_in_full_gdt() now using populate_perdomain_mapping() (see "x86/pv: use populate_perdomain_mapping() to map the Xen GDT"), the stashed reference has lost the user that justified it. Switch pv{set,destroy}gdt() to populate_perdomain_mapping() as well; the LDT paths are the remaining users, after which the stash can go. --->8 > > Signed-off-by: Roger Pau Monn=C3=A9 > > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 > > Signed-off-by: George Dunlap > > With the adjustment above: > Reviewed-by: Jan Beulich Thanks! > > --- a/xen/arch/x86/pv/descriptor-tables.c > > +++ b/xen/arch/x86/pv/descriptor-tables.c > > @@ -49,33 +49,42 @@ bool pv_destroy_ldt(struct vcpu *v) > > > > void pv_destroy_gdt(struct vcpu *v) > > { > > - l1_pgentry_t *pl1e =3D pv_gdt_ptes(v); > > - mfn_t zero_mfn =3D _mfn(virt_to_mfn(zero_page)); > > - l1_pgentry_t zero_l1e =3D l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR= _RO); > > + const mfn_t zero_mfn =3D _mfn(virt_to_mfn(zero_page)); > > + mfn_t zero_mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)]; > > I wonder if having an initializer here might not result in better code. T= he > array could likely be filled with REP STOSQ here, and ... > > > unsigned int i; > > > > ASSERT(v =3D=3D current || !vcpu_cpu_dirty(v)); > > > > v->arch.pv.gdt_ents =3D 0; > > - for ( i =3D 0; i < FIRST_RESERVED_GDT_PAGE; i++ ) > > + > > + for ( i =3D 0; i < ARRAY_SIZE(zero_mfns); i++ ) > > { > > - mfn_t mfn =3D l1e_get_mfn(pl1e[i]); > > + zero_mfns[i] =3D zero_mfn; > > ... the live range of zero_mfn would reduce to about nothing. Tried it: GCC didn't use REP STOSQ [1], but seems worth it for clarity and register efficiency anyway. -George [1] Fable experimented with a few different compiler flags, but couldn't get a REP operation; it said "The reason is structural: GCC's string-op machinery handles block clears and byte-splat fills (memset means a repeated byte); a fill with a non-constant 8-byte value is not a memset and never reaches that expander". From xen-devel-bounces@lists.xenproject.org Mon Sep 07 13:56:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 13:56:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410881.1641684 (Exim 4.92) (envelope-from ) id 1x3Zq9-0005oU-Vo; Mon, 07 Sep 2026 13:56:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410881.1641684; Mon, 07 Sep 2026 13:56:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Zq9-0005oN-Si; Mon, 07 Sep 2026 13:56:53 +0000 Received: by outflank-mailman (input) for mailman id 1410881; Mon, 07 Sep 2026 13:56:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Zq7-0005oH-Os for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 13:56:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Zq7-009wzU-5S for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:56:51 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ec291-e002-0a2a0a5209dd-0a2a4508c720-42 for ; Mon, 07 Sep 2026 15:56:51 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ec2a2-f659-0a2a45080019-b9ff1c22a899-3 for ; Mon, 07 Sep 2026 15:56:50 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a07c283b48000c4f3.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 07 Sep 2026 13:56:46 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id EFAE183FF2; Mon, 7 Sep 2026 15:56:44 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=ei0/Uha+qMA4uzVKshxVNrw/Y68MyUmSLd1HlfXsqts=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=ewAGVebrBHz8wdbZvRRAPWVEAGH1/vraOlJL4jOXtfV50M3kLhnXHz8h4fSEXdIyAd0u6K8fk Qye5h7tfOvDpthmkeuHXitBK4jUuxh1nxVuDjOgMwt6XdBULXfXYKJVLMvEH/1QwUgXaLdCkEyw N9H+668/g1cI0UGsYUa5eGY+PYpRn0RIE6/NeuFY1H4Trca586PFGKVDx0N0RfuOgSZLwKqak/q wffsKC5P2JOmc0pJ4oHuMUWPRPPrrOR1dUCkRJU2EjA1MqQRYOaXj1wSSJEyxtlrjAKzpA/HSCC 7JMlT4IcMbXMvYO6ZSKoi6BTC83nIi0FZ1DHaIhWssjg== X-Zone-Loop: ad078b0bcefa1c1ee2c1c87affc6a9a8e4449e6e6512 x-campaign-type: default x-transaction-id: af5ff466-d346-46ae-82c9-0b04a8519f83 x-swg-uid: 01-81c76782-6454-49ed-9a0c-8ffc3233692b X-Mailer: Sweego Message-ID: <1788789406.8631fc262581453bbf619ec5b2062170.1a07c283b48000c4f3@vates.tech> x-swg-bid: 1788789406.8631fc262581453bbf619ec5b2062170.1a07c283b48000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 7 Sep 2026 15:56:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] public/xen.h: Update comment on mmu_update sub-command size and PTE alignment To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Frediano Ziglio , xen-devel@lists.xenproject.org References: <1787563949.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@vates.tech> <94e4e14c-11bb-48cf-aced-7ed6be8ad34a@suse.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <94e4e14c-11bb-48cf-aced-7ed6be8ad34a@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------gOp6nqs3tDMkMuzK2WTbbtAK" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788789405173 X-purgate-ID: tlsNG-c1860d/1788789411-D735D87B-361784E7/0/0 X-purgate-type: clean X-purgate-size: 9111 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------gOp6nqs3tDMkMuzK2WTbbtAK Content-Type: multipart/mixed; boundary="------------Tnc0yrZyUtSmLFLhedM6G4RJ"; protected-headers="v1"; hp="clear" Message-ID: Date: Mon, 7 Sep 2026 15:56:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] public/xen.h: Update comment on mmu_update sub-command size and PTE alignment To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Frediano Ziglio , xen-devel@lists.xenproject.org References: <1787563949.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@vates.tech> <94e4e14c-11bb-48cf-aced-7ed6be8ad34a@suse.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <94e4e14c-11bb-48cf-aced-7ed6be8ad34a@suse.com> --------------Tnc0yrZyUtSmLFLhedM6G4RJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjQvMDgvMjAyNiDDoCAxNDoxMywgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gT24g MjQuMDguMjAyNiAxMTozMSwgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiBIWVBFUlZJU09SX21t dV91cGRhdGUgcGFzc2VzIGEgc2V0IG9mIHJlcXVlc3QsIHdoZXJlIGVhY2ggcmVxdWVzdCBo YXMgYSBwb2ludGVyDQo+PiB0byB0aGUgUFRFIGFsb25nIHdpdGggYSBzdWItY29tbWFuZC4N Cj4+DQo+PiBUaGUgUFRFIGFsaWdubWVudCBwYWRkaW5nIGlzIHVzZWQgdG8gdHJhbnNwb3J0 IHRoZSBzdWItY29tbWFuZCB3aGlsZSB0aGUgcmVzdA0KPiANCj4gVGhlcmUncyBubyAiYWxp Z25tZW50IHBhZGRpbmciIGhlcmUuIEl0J3MgdGhlIGxvdyBiaXRzIG9mIGEgbmVjZXNzYXJp bHktYWxpZ25lZA0KPiBQVEUgd2hpY2ggYXJlIHVzZWQuDQo+IA0KPj4gaXMgdXNlZCBhcyBh biBhZGRyZXNzIHRvIGEgUFRFIGVudHJ5LiBUaGUgY3VycmVudCBkb2N1bWVudGF0aW9uIHN0 YXRlIHRoYXQgdGhlDQo+IA0KPiBOaXQ6IHN0YXRlcw0KPiANCj4+IDIgZmlyc3QgYml0cyBh cmUgdXNlZCBmb3Igc3ViLWNvbW1hbmQsIGhlbmNlIHRoZSBvdGhlciBvbmVzIGZvciBQVEUg d2hpY2gNCj4gDQo+IEJldHRlciAiMiBsb3cgaXRzIiwgYXMgImZpcnN0IiBpcyBhbWJpZ3Vv dXMuDQo+IA0KPj4gaW1wbHkgaGVyZSBhIDQtYnl0ZXMgYWxpZ25tZW50IG9uIFBURXMuDQo+ IA0KPiBUaGUgcGFydCBhZnRlciB0aGUgY29tbWEgSSdtIGhhdmluZyB0cm91YmxlIHBhcnNp bmcuIENhbiB0aGlzIHBsZWFzZSBiZSByZS0NCj4gd3JpdHRlbiBzb21lPw0KPiANCg0KSSBh Z3JlZSwgdGhlIHdvcmRpbmcgaXMgYSBiaXQgd2VpcmQuIFRob3VnaCB0aGUgbmFtZSBvZiB0 aGUgZmllbGRzIG1ha2VzIA0KaXQgYSBiaXQgb2RkIHRvIHdvcmsgd2l0aC4NCg0KV2UgaGF2 ZSBpbiBzdHJ1Y3QgbW11X3VwZGF0ZQ0KDQogIHVpbnQ2NF90IHB0cjsgICAgICAgLyogTWFj aGluZSBhZGRyZXNzIG9mIFBURS4gKi8NCg0KeWV0LCBwdHIgaXMgYWN0dWFsbHkgc29tZXRo aW5nIGxpa2UgKHB0ZV9hZGRyIHwgc3ViX2NvbW1hbmQpLg0KDQpTbyB3ZSBwcm9iYWJseSB3 YW50IHRvIHNheSB0aGF0IGl0J3MgYSBudW1iZXIgY29tcG9zZWQgb2YgYSA4LWJ5dGUgDQph bGlnbmVkIFBURSBhZGRyZXNzIGNvbWJpbmVkIHdpdGggMyBsb3cgYml0cyBsYXJnZSBzdWIt Y29tbWFuZCA/DQoNCj4+IE9uIFBWNjQgYW5kIFBWMzItUEFFIGd1ZXN0cywgYWxsIHBhZ2V0 YWJsZSBQVEVzIGFyZSA4LWJ5dGVzIGFsaWduZWQsIGhlbmNlDQo+PiBvZmYtYnktNCBQVEVz IGFkZHJlc3NlcyBhcmUgYWx3YXlzIGluY29ycmVjdC4gTm9uLVBBRSBQVjMyIGd1ZXN0cyB1 c2VkDQo+PiAibGVnYWN5IHBhZ2V0YWJsZXMiIHdoaWNoIGhhZCA0LWJ5dGUgYWxpZ25lZCBQ VEVzLiBIb3dldmVyLCBzdXBwb3J0IGhhZA0KPj4gYmVlbiBjb21wbGV0ZWx5IHJlbW92ZWQg c2luY2UgWGVuIDQuMCwgYW5kIHdhcyBvbmx5IGF2YWlsYWJsZSB3aGVuIFhlbiB3YXMNCj4+ IGJ1aWx0IGluIDMyLWJpdHMgbm9uLVBBRSBtb2RlIFsxXS4NCj4+DQo+PiBDdXJyZW50IFhl biBsb2dpYyBiZWhhdmVzIGFzIGlmIDMgYml0cyBhcmUgdXNlZCBhcyBzdWItY29tbWFuZCwg dGh1cyBhbGwNCj4+IG9mZi1ieS00IFBURXMgYXJlIGFjdHVhbGx5IHJlamVjdGVkIGFzIGJl aW5nIHVua25vd24gc3ViLWNvbW1hbmRzLg0KPj4NCj4+IEFkanVzdCB0aGUgZG9jdW1lbnRh dGlvbiB0byBtYXRjaCB0aGUgY3VycmVudCBsb2dpYyBpbXBsZW1lbnRlZCBpbiBYZW4sDQo+ PiBhbHNvIGV4cGFuZGluZyB0aGUgZG9jdW1lbnRlZCBzdWItY29tbWFuZCBwYXJhbWV0ZXIg dG8gMyBiaXRzLg0KPj4NCj4+IFsxXSA4NGQ1NGQ1ZDhiMzEgKCJpMzg2OiBSZW1vdmUgbm9u LVBBRSBoeXBlcnZpc29yIGJ1aWxkIHRhcmdldC4iKQ0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6 IEZyZWRpYW5vIFppZ2xpbyA8ZnJlZGlhbm8uemlnbGlvQGNpdHJpeC5jb20+DQo+PiBTaWdu ZWQtb2ZmLWJ5OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMudGVjaD4NCj4gDQo+ IERpZCB5b3UgZm9yZ2V0IHRvIGFsc28gYWRkIGEgRnJvbTogdGFnPw0KPiANCj4+IEBAIC0y NjAsMjEgKzI2MCwyNiBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fdWxvbmdfdCk7 DQo+PiAgICAqIGh5cGVyY2FsbC4gQWxzbyBpZiBzbyBkZXNpcmVkIHRoZSBPUyBjYW4gYWxz byB0cnkgdG8gd3JpdGUgdG8gdGhlIFBURQ0KPj4gICAgKiBhbmQgYmUgdHJhcHBlZCBieSB0 aGUgaHlwZXJ2aXNvciAoYXMgdGhlIFBURSBlbnRyeSBpcyBSTykuDQo+PiAgICAqDQo+PiAr ICogTm90ZTogSGlzdG9yaWNhbGx5LCBYZW4gaGFkIHN1cHBvcnQgZm9yIG5vbi1QQUUgUFYg Z3Vlc3RzIHdpdGggNC1ieXRlcyB3aWRlDQo+PiArICogICAgICAgUFRFcyAoaWYgWGVuIHdh cyBidWlsdCBpbiBub24tUEFFIG1vZGUpOyB3aGljaCBzdXBwb3J0IGdvdCByZW1vdmVkIGlu DQo+IA0KPiBBIG5hdGl2ZSBzcGVha2VyIG1heSBjb3JyZWN0IG1lLCBidXQgIndoaWNoIHN1 cHBvcnQiIHJlYWRzIG9kZCB0byBtZS4gSW1vIGVpdGhlcg0KPiAidGhhdCBzdXBwb3J0IiBv ciAic3VwcG9ydCBmb3Igd2hpY2giIChhbmQgdGhlbiBwZXJoYXBzIHdpdGggYSBjb21tYSBp biBwbGFjZSBvZg0KPiB0aGUgc2VtaWNvbG9uKS4NCj4gDQoNCk1heWJlIGl0IGNhbiBiZSBy ZXdvcmRlZCBhcw0KDQpYZW4gaGFkIHN1cHBvcnQgZm9yIG5vbi1QQUUgUFYgZ3Vlc3RzIHdp dGggNC1ieXRlcyB3aWRlIFBURXMgKGlmIFhlbiB3YXMgDQpidWlsdCBpbiBub24tUEFFIG1v ZGUpIHVudGlsIFhlbiA0LjAuDQoNCj4+ICsgKiAgICAgICBYZW4gNC4wLiBBcyBhIHJlc3Vs dCwgaW4gY3VycmVudCBYZW4sLCBhbGwgUFRFIGFyZSBub3cgYWx3YXlzIDgtYnl0ZQ0KPiAN Cj4gTml0OiBEb3VibGUgY29tbWEgKHdoZW4gcGVyaGFwcyBub25lIGlzIG5lZWRlZCBhdCBh bGwgaW4gdGhhdCBwbGFjZSkuDQo+IA0KPj4gKyAqICAgICAgIGFsaWduZWQgd2hpY2ggYWxs b3dzIGV4cGFuZGluZyBzdWItY29tbWFuZHMgcGFydCAobm93IDMtYml0cyB3aWRlKS4NCj4g DQo+IFdoZXRoZXIgdGhlIHBhcnQgZnJvbSAid2hpY2giIG9ud2FyZHMgaXMgcmVhbGx5IHJl bGV2YW50IGhlcmUgSSdtIG5vdCBxdWl0ZSBzdXJlLg0KPiANCj4gSmFuDQoNClRlZGR5DQo= --------------Tnc0yrZyUtSmLFLhedM6G4RJ-- --------------gOp6nqs3tDMkMuzK2WTbbtAK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqewpwFAwAAAAAACgkQZg+p0QLLz9Bm agv9F1B0l5cmOYaU2aZPUoDobJzjKme/qHixmKfKfbXVxLfRs+maXvy16IRK1j4oH2ojIZeD+gNI EKpVRfDZq/O1fmNLMHEBN+O+DCtHif8l6OpFcnZJdnZESQU1YR3OnhcNCWmfAKJWTOSNlOsYchHt LrhsM9xeXxfRv4u+uW35O4pa5qyn2CnIRWBcvhvEZ0rTndKsmK4pNg2LhaBJ9BVutXd/PSIDi2n9 UNUdx1LQOM6aB04Udrn0NhvVY4jIkm3LOYyjVHajTWygSy7qKzN9A89Mjg38eAwjuoubcz6EpPni bbxAM+5wogU+QzppCIw5utu4s1C9sn/fJY7+e9Bl6sdPuEPtL0Vt8430JUXvsEAvN4g5urwkpRUS IN9l4QRzV4An8ibOQ23zgEkDIUCfH2a8jmzx6+xVHgNgOIce5KzPzOJ5Orzs8A9/hSi8IUoCBQGD 3J4DgENICBAnVODySY897oz6xzPm/KJ2lXwBOui6iH+l+xjguVI3+Bwxc6aR =tnmJ -----END PGP SIGNATURE----- --------------gOp6nqs3tDMkMuzK2WTbbtAK-- From xen-devel-bounces@lists.xenproject.org Mon Sep 07 13:58:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 13:58:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410888.1641692 (Exim 4.92) (envelope-from ) id 1x3Zrn-0006PT-8o; Mon, 07 Sep 2026 13:58:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410888.1641692; Mon, 07 Sep 2026 13:58:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Zrn-0006PM-68; Mon, 07 Sep 2026 13:58:35 +0000 Received: by outflank-mailman (input) for mailman id 1410888; Mon, 07 Sep 2026 13:58:34 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3Zrm-0006PG-SF for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 13:58:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3Zrm-00DCu6-5U for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:58:34 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ec2f3-e002-0a2a0a5209dd-0a2a4508dfa8-34 for ; Mon, 07 Sep 2026 15:58:33 +0200 Received: from [18.217.159.240] (helo=ghoul.relay-egress.a.mail.umich.edu) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ec308-f659-0a2a45080019-12d99ff0dd66-3 for ; Mon, 07 Sep 2026 15:58:33 +0200 Received: from supernal-garuda.authn-relay.a.mail.umich.edu (ip-10-0-72-192.us-east-2.compute.internal [10.0.72.192]) by ghoul.relay-egress.a.mail.umich.edu with ESMTPS id 6A9EC308.E0FBD53.79CECFE.261231; Mon, 07 Sep 2026 09:58:32 -0400 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by supernal-garuda.authn-relay.a.mail.umich.edu with ESMTPSA id 6A9EC307.18650543.3E4BBE93.260121; Mon, 07 Sep 2026 09:58:31 -0400 Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-5b6036e9c70so2707620e87.1 for ; Mon, 07 Sep 2026 06:58:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-2 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1788789511; bh=Vi363ho9/7H9YTUq27CT/23svKZQ7SB0u62NNWIH71k=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=iyBDfwPkIur/lT5juUckBDoAAm5LAEtI2gGO9nEMpC8FdkRTXAUmnZVXMv/KSnxQK ONxBsIUF87K9NU+jITOBNAr38F5cf8C2x6QWGGerfZlJcK5Kf5KSFL6Arkx7GMH1Gy MwXHI7A6v5u4gviYk9NkLvjjQ/GNSZUxGjBl774vD9JYWay1j0/O2V4ZbT9X4kydfj EVIlKjYm7MSj0poeHTDqqXZsFEC3RDqu3rDrCZOnJy1EYLWdpW4J8EplEm4SBhnd2K Vorj+mh2C2nGCXfMCtMa5po9xJP6wnTq+tfDV3SkYr8/i/B84ww/TFPjt6ZC+sn703 I2Me+kzQmMcvg== Authentication-Results: supernal-garuda.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.167.51 (mail-lf1-f51.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvByrkfMdmuKpnX1N22cU6xLaNK8iKumtnzslC1QB4nJm2RwpkEWWqUmk4PVRs9vLoH7uweHl2ksDJdE=@lists.xenproject.org X-Gm-Message-State: AFuF++mGv9J7ME3Gbw7HM10Quub1GeJ5RuGgXZcjbFSfZ5rgDn+peqdT fWPqPrkM2t0kg/xX+tfRybbtVnoDh5MhD5oDLgilBZmADDfFk6VpoW7EO0UVtqUkop5o0z71dvR 9wQFNe+P5uDcFpygDCqb9uzwARDrL8sk= X-Received: by 2002:a05:6512:3d07:b0:5b3:e02:b3a0 with SMTP id 2adb3069b0e04-5b616f01f35mr3492292e87.7.1788789509401; Mon, 07 Sep 2026 06:58:29 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-3-ecc269f268b7@xenproject.org> <554687e3-1fab-4d23-9a4e-0bdc3bc1fc60@suse.com> <07d332a4-a5a3-44d4-95ce-fc67d86edacf@suse.com> <050f44ec-47e5-4754-b73b-1173458736b0@suse.com> In-Reply-To: From: George Dunlap Date: Mon, 7 Sep 2026 14:58:16 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1W-p67KphIux9-AXqcMIp3wWYIDfvLoVkw_C1Hh5f8KwGnexJxCGS5dy8Q Message-ID: Subject: Re: [PATCH v2 03/14] x86/pv: use populate_perdomain_mapping() to map the Xen GDT To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Jan Beulich , Andrew Cooper , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c1860d/1788789513-D735D87B-94E06030/0/0 X-purgate-type: clean X-purgate-size: 2811 On Fri, Sep 4, 2026 at 11:34=E2=80=AFAM Roger Pau Monn=C3=A9 wrote: > > On Fri, Sep 04, 2026 at 09:50:02AM +0100, George Dunlap wrote: > > On Fri, Sep 4, 2026 at 9:29=E2=80=AFAM Jan Beulich = wrote: > > > > your position here is really inconsistent: You wave > > > > away a partial pagetable walk with three map/unmap operations on th= e > > > > context switch path as something we'll have to do in the interim, a= nd > > > > can optimize later, but are now threatening to make me add in > > > > special-case codepaths and run tests to save a few memory reads and > > > > shifts. > > > > > > I think you misunderstood. There was a concern raised already on v1, > > > and that concern wasn't covered by the patch description. In my initi= al > > > reply I said "Functionally the change looks okay to me" for a reason, > > > after all. > > > > To quote Andy's mail: > > > > <<< > > > > So what this patch is doing is still keeping the double copy (the > > fragility) but reintroducing the expensive part of the operation into > > the context switch path. If you can't keep it being L1e, there's > > probably no point keeping the optimisation at all. > > > > >>> > > > > Basically what I took from this is; > > > > - Andy thinks stashing any intermediate form (whether L1E or MFN) has > > a technical cost (two copies that could potentially go out of sync, > > thus "fragility") > > > > - Andy thinks that the expensive part of the conversion is the MFN -> > > L1E conversion, not the vaddr -> MFN conversion > > We later discussed this, and the assumption was that the expensive > part was the vaddr -> MFN translation, as that's where PDX is > involved. I expect crafting a PTE shouldn't be expensive at all, but > maybe there's something I'm missing here. > > The original patch cached the MFN in an attempt to not remove the > optimization, because my understanding was that the possible expensive > part was the PDX translation. Then again I don't have real > measurements to back up any of the claims above, and hence it might > all be plain wrong. I ran some tests on my NUC. Measuring cycles for *just* update_xen_slot_in_full_gdt(), using the previous version (stashed xenheap pointer + stashed l1e), and then mapcache walk with {stashed mfn, full conversion} x {default, PDX forced on}. xenheap+l1e: 38 cycles mapcache walk, stashed mfn (v1), no PDX: 98 cycles mapcache walk, full convervion, no PDX: 97 cycles mapcache walk, stashed mfn (v1), PDX forced on: 128 cycles mapcache walk, full conversion: 122 cycles The variance is pretty high, so basically the mfn stashing didn't have any statistically significant effect. I'll leave it doing the full conversion for now. -George From xen-devel-bounces@lists.xenproject.org Mon Sep 07 14:16:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 14:16:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410900.1641709 (Exim 4.92) (envelope-from ) id 1x3a8m-00023H-Ms; Mon, 07 Sep 2026 14:16:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410900.1641709; Mon, 07 Sep 2026 14:16:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3a8m-00023A-K8; Mon, 07 Sep 2026 14:16:08 +0000 Received: by outflank-mailman (input) for mailman id 1410900; Mon, 07 Sep 2026 14:16:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3a8l-000234-Ac for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 14:16:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3a8i-000krg-Vw for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 16:16:04 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ec710-e002-0a2a0a5209dd-0a2a450583b6-32 for ; Mon, 07 Sep 2026 16:16:04 +0200 Received: from [52.101.52.12] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ec723-4cb1-0a2a45050019-3465340ce1fb-3 for ; Mon, 07 Sep 2026 16:16:04 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB6367.namprd03.prod.outlook.com (2603:10b6:510:a9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Mon, 7 Sep 2026 14:16:01 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Mon, 7 Sep 2026 14:16:01 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=o7MW1ZUx9b9t6qQYKgWP2b//oMHownP8vWwq6QfJ1EFdFcUdc1sdgwFnSSHSeR5NSxfCzgAYCJ6LHuldpetQKXDwLqJbLyjyuvQ3MapaDI0clvFc/YYC+BJe8VG29IVotLMvy1t8YTfSOy1Qt9ixcSmQxZMHeSitW35TdFH7yTV8JSXh5vJdVzBzboQyuphg2IJnMYZTY8/w/fRcVcO1vewXzVGgQUzEFaLqG4Lj24Fcm44iDcr0oqSTNpY+lcDFXLXxeNrpSHFvJz3qyANR9bac6s6ZcVxnupaH9/zvlOL7WcmZAIwBTc3W2A6+P3p6XbPieJQNA355Hi7y5vf1lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O6oETVrXcAV99ocSF1FA5hDufNvJs33C0rjCdbF1QHY=; b=si6V/jfcI9QxVYnOFptXfvmfm7NJbgX6mPgMxDYrX6C5vU23nTJQ6useEwbguv40rvgiypqeBFxpVWQKv+yDUw7s7BmkcVF9gXymoBqFqydLYafs02rvT3mSZ+veX2njAsRxLVlgZ7OSGwoQrb8x9sd7EpSQm3JeJp+aKsjOF6JzTDLaXIVjtHHPaDocVuNnABUg+TxkRbXOCjcJ8w5FxI5alblZxvP8l6ZaFFrMgW3RylGZzFO2wOGGnvoIL/zJ4b3AMC+t8BvbouXGDUeUHHvVbQLR3yBVLJ+ivnp2l5OpKyYsY0HUcUbHNVJizvFTuXMgy0Y5URzIxGRALvHFew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O6oETVrXcAV99ocSF1FA5hDufNvJs33C0rjCdbF1QHY=; b=VjP9CjIOxcP6b4t7xFhO+Sy2PPAJgEEwL2hRLlIaRYSGGu9J4MLDKE9koTq+mYL47aTRaxEOMPCKV0klTtTYR0gPV5eC347rgJHrg0vSUI4KBPT1hK3/4xtACcWwq+tkFnDa2cGeBgjEoscR3RroDF3DLUDd2dfTttwYL5Ht8U8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <00433163-b6fe-473e-9726-17790e1feae0@citrix.com> Date: Mon, 7 Sep 2026 15:15:57 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] build: also exclude .data.rel.ro in $(cmd_obj_init_o) To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <0d40567f-6527-419a-a210-65e74bef988b@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <0d40567f-6527-419a-a210-65e74bef988b@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0562.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:33b::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB6367:EE_ X-MS-Office365-Filtering-Correlation-Id: df92d128-5837-4047-76ca-08df0cea8b9d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|10067099003|11063799006|22082099003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: 9M1ml3qN5XLRWYoZqlHzNS3jTZJUvrS//UES37St9cLRvbZ8T0EHpPYORHCCXKxB/fvc65RzQ9fBtKG4AElm34Magc8W+gNHfkGZsT4h+qknD0us7s33MJ7ON5i9G8CmfCtZ0wWpjLBfGlu+cwwyE6eLyd4VxGvv6RUuo47mCE1DEwxbL6E43ZS1VNwzYdliFHEDRZr7/UVd+dceehv4RkOxmpCHC9l20EzJK+jNA76QQjhK4JlrkzDPmxr+uElgqWZ9AdMeqvIRrupi2eJML4oeK240SyeCd7r3fIJC4QLoVRBgONgtJMI8nEqsAccBbIM7bUf+6yaENdZeAFQg7R/79yAkZyL8j+USLRpn2m0HhsOU/O7lZzj17oG/AxC5svNk0udLz1AzI4EjQ2F2nDT8NIrGRnoA0jaTtbChnwH/UVXDJTjqd8IYWPahT9RZGh9RqtqAjyHC4AGyomiXd8ARtLzxns3LlCgPa0bHwslgdPaKtB8BxWfi/cYOg6lpY+F95QGrCLq37t6zCdEv9ApqdeXTcZ0CVqqk7zys1+8gqYKEZ1WJGtDv2qt1vn0o8mv7/2Ceesk99MAdegYT6KhPAVuaxLU+ZGSANWhtvzMPmLDLKArqqcvwsgS+z72kwU6PrH8A1mc1/ge3iONIGy0ev4LqoVxraMPCNJLEap4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(10067099003)(11063799006)(22082099003)(18002099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M1cybndiRldoR0daaWU5c2NpQ0V0Mk5qTVVNcWQwdCtYSitya3c0R01NeTVC?= =?utf-8?B?YldJQ1ArQmtWamJnREtNQ3dscndtek1wUmxPdEtHWG94TDNQT3pCSkxLZ0tq?= =?utf-8?B?RUsyeVV4ZXhGM0p3MEpjWW9VMVFCWnBuZHhsMC94QmtlcCtkZGN2blVrQ1Vl?= =?utf-8?B?dkRXbS9MTHdaTFpFNVNSSDhqcHd5YlZqSzJiS1FyRU5MYnJ2MWhBcklMRDJW?= =?utf-8?B?UnZWVTEwNGk4dnhMenY2TmNvdjIwU0tIZStCQ1VuZllDaHkwWW1LMGp6TkJC?= =?utf-8?B?d0VjZktweXJ0S1pveFpyd0ZYSnFIVXVKeld1QWs0ZmRyOE44djhWVVM4bGZq?= =?utf-8?B?djR0UWZTQXNjLzc0OHYzN2cvMVNsalJJckQya2tMQWFvNFdVK3FqejQxelpj?= =?utf-8?B?dzRGZ3FiaGRGVmV4WUE1K1pQNmw3eE1qSFljWC9BRmxKM0luMU9KZWtyVnFQ?= =?utf-8?B?dzJka0pTN2RXQnMwR2FnM2MrQUpHREdRSDh2RjRCUkNQbjd2eGY3eHV3dXFl?= =?utf-8?B?Y21EZDIzd1lnei9UaE1TUWdqYmtqUVFuUTd2MUZLM1NaTWVzb1lLZVpxK0pT?= =?utf-8?B?RWZWT3BNaFBGVFBmSlJjVkJ1ZWQ0M3lmK3QycWkyOEREZmdIQlpDU05tZHJr?= =?utf-8?B?SFN2OGdyOGdMK1lHdVhBSlV2QkxtaGg1dHZYMjRZOUFBdWUzY1FJOXdzSDBj?= =?utf-8?B?TTBsMUZJQ2VsaDV5bDhUM3BZZlVrTWN0TzFSTHloK3VFSHlnOU5nay9VSyt5?= =?utf-8?B?eWJxT3YzejF4TGx3WEthODRTQmZSMDFNNEtwaDZpNndySnpGalBVUzdPUzVi?= =?utf-8?B?ejA2TWhaTFh4bnhkMEtYaWhTd3BWUENIdVRqUXV6R0w2NWFzOXhnMitMTGc4?= =?utf-8?B?alNPNCtkeEhlRFRucm9Zekc3cVo2dWxxM0R3SEFqczVxVEhLVmJGdGw1L0xL?= =?utf-8?B?emdFdU04OGlwSjM4cmRka1VUekJ2Rm1meGhTKy94djMzL3BPVk1jL1hCaGZa?= =?utf-8?B?cmFKUUlEclZhSVQvb0xNZW52eVJ1OS8rVTVEM0dhdTJTUzBZelVnUlZyRk9t?= =?utf-8?B?WmVYSXBKamIyUkF3T3VZVUpOQXM3SWtGRm51cHQ0ZmM5NElWT2xweGg2aTl2?= =?utf-8?B?NWR2NG1yNFhKQ0FPT2pTVUI4Vk9sNjk4MXl4Y01yaFM3NFRaM05qbGF2eWhr?= =?utf-8?B?cXc4VFIxU0YwWTk2a3dKWE9iR2dFMFdScGY1NisxeWdXYWREMnR1YWgzbjU2?= =?utf-8?B?ZnZId01kZ1phYTlpNkpPSU44WWJuc2NQRFJjVUQ3VTRpTVpla3llRmlFUCto?= =?utf-8?B?SDBzYXZuREJZd0dxTVVxL3lNU0xyeUlWdE5BbmFJbnlNMUZZcmxuSHczQnJt?= =?utf-8?B?UEcrRk42YjRobElPTFRxSUI2dmd1MjBITzh6R3dGMnpKQ2MxQmM4RGUrNURW?= =?utf-8?B?R1RRVTEzaGxOOEt0czhVdDI4M05OdVdjdU9KL1BLWWdUMlo3aGltazNUdFBz?= =?utf-8?B?cVNvSXlaZkwvTVpSSnBlOXNQekRFMWFMRnRxVktBOXFVY3hoR01TLzBGd1Ji?= =?utf-8?B?V3k2dE1ja244WC9UdWVYN3ZseGkvc0FkeHdmU2l6MytXWmJTOTNLYkJJcjdT?= =?utf-8?B?WFBQRHA4bWZ1cW84a2JpcGprQ1BSNUdtRTg0TXltUDY1QUJOazJFZlRsZFI1?= =?utf-8?B?S091cXZxYzBRbG96UGwxVGl2S0VWaXpzTmlCRTlKRS9kNjZxQUZld3FrVkdO?= =?utf-8?B?ZFNjSU5NMTJRd05mdERuUjhja25DcTNCdkI2cWxmU0ZvU25CUURVNWFicUlE?= =?utf-8?B?WThWRzJ4TW5CaXZTR3JWNXgvNXRZWHQ0M1NZUWJ3WElpdEFqMlpIemplYlhI?= =?utf-8?B?dW5ZQ1JDR21nZFVOb25aSmFBYnR1MldrUjFjQWwwT2wza05QRThlNlFXZ29t?= =?utf-8?B?SzVjckhxWkYrQjNla3NFcWt6akdkaWo2ZGlXd01FNVVOWngrMlV4MVd3UWlR?= =?utf-8?B?a3VjZ1duVThlRDY4NERBNUQ5RENoZTBxZXZobVFLdHoxUllTTVJPRkpLYlRx?= =?utf-8?B?UHlKbW43NkhwN3dFSkQ3NlhOekRRUkRWYmh3S1ZZSFFMVG84TEZqVXFKakg5?= =?utf-8?B?bGUzVDJQMVUxaGEzMjBoTXp3bmF6NGtOWHVOQTdoUWkzODc0aUZqR25iUmFI?= =?utf-8?B?Wkp4djVJVlpVRlJiTUIvZTNsdmFnMjRnVzdMN01qaE5Mek13NVI5SXNhS1Ni?= =?utf-8?B?anhodW4xRHU2dy90L1BKTFl6cFl4aWZLT0FpZFpZWkd0U1E2Q25xYk92YnpK?= =?utf-8?B?VGNaaVBjUGlYMVg5NEtIL3QyRktYaVNZN1A1aUdXVzdhNzEyOW9Zdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: df92d128-5837-4047-76ca-08df0cea8b9d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2026 14:16:01.4836 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iTKbgVQ549FttGrlYMrebF/N6J/zSNvnubpi515JSxYtfS5bQ1LgDhj4zBkaPhFe/v3WKRGz6mWqJIi6LZbzGz6T2B7Rn1jZGyEVQGptdiM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6367 X-purgate-ID: tlsNG-c201ff/1788790564-71EA92A1-FA11E4B8/0/0 X-purgate-type: clean X-purgate-size: 351 On 07/09/2026 1:18 pm, Jan Beulich wrote: > .data.rel.ro really is merely a special case of .rodata: r/o data, but > with runtime relocations (not relevant to Xen), i.e. r/o only after > relocations were performed (by the dynamic loader). > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Sep 07 14:54:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 14:54:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410915.1641720 (Exim 4.92) (envelope-from ) id 1x3ajN-0001QK-Hp; Mon, 07 Sep 2026 14:53:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410915.1641720; Mon, 07 Sep 2026 14:53:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3ajN-0001QD-EJ; Mon, 07 Sep 2026 14:53:57 +0000 Received: by outflank-mailman (input) for mailman id 1410915; Mon, 07 Sep 2026 14:53:56 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3ajL-0001Q7-TN for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 14:53:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3ajL-000ray-4k for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 16:53:55 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ecfdf-2eae-0a2a0a5409dd-0a2a450ca0ec-36 for ; Mon, 07 Sep 2026 16:53:55 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ecffd-f479-0a2a450c0019-d1558030d01a-3 for ; Mon, 07 Sep 2026 16:53:50 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49b392ccaacso55148345e9.2 for ; Mon, 07 Sep 2026 07:53:49 -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 ffacd0b85a97d-485883c6ba4sm33307283f8f.25.2026.09.07.07.53.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 07:53:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788792829; x=1789397629; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=4edHddT0m1mePVUVxLLIFvpz3mhD/PlFMkh58naLP8M=; b=CP3WFl8Dlm5bpYgq4UscSXW+AAQHIiTcSiuWe8ZTVlHtwKHR7Cswh/7QEfqMenK3Fw iC5rDZ09/XCC01AEieBne/mUKVbK5AnZfRfZdFNPBOZN2B4973MDVCpeHguTold9vCLo DWMkmOjP1qomfl/r+/PcZa2/Cf+z1SGkiO3Dz39iJ2BP5uB89p1wEi0D1rLwKto8dvxH AeXLOHg3Mmwv3awRrsBhpl6dMq5bmqaeVEE3oIOA2QmyTNlIc/BrlD+7oknbWdTKJn9I PyBOUlu0WqriT+pDqC3icX6luP+2EGsmlagS+S6kPNCE5YgQXaPosuk66rh5SIcq/fOo 9yVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788792829; x=1789397629; h=content-transfer-encoding:content-type: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:content-type; bh=4edHddT0m1mePVUVxLLIFvpz3mhD/PlFMkh58naLP8M=; b=owXVELOlvw2OzyCKfpkv5ZjYgwsoH7k8Yu9DjXq3Kp1xH0YsVrD58xC8G9cHm/3WI3 ie1BESv0XpiLW+hngJ2+2LzUnDs3ermePIYv7VON8TjpBp+dutWcbq7gkzHBRd0CRQPc neHcFKx6h+5IpOgfXEzrEkXvVzKb437/iw+LFk3GuiO16ywIxd8k8dLlNRYt4u92SNXe mmgsVOQUjooWsBZeaUIYYYNJWczj90fM404jg5RFH3P6TZRY24HkOb+hVrb+GDlnDQ6t 6z5/2WwyDKRWTb585RlEhT9FDMpwCVLN/0f57iPdbgHY4e/W2L/IESp/iK7VXKUfpjm6 ccig== X-Forwarded-Encrypted: i=1; AKwUvBwzmoIssXy2akyYETgzXn1Pc9kVMpm7eUubSO4V6B+mZI7aFY4nTeGXyPp4sRyzdRk8uKw0JiViE2E=@lists.xenproject.org X-Gm-Message-State: AFuF++mTtWAwtjhQ2uOiwDf37JO+/Exko6xZY15ZTqxkL0vIRzoJcDc3 JAmv7O+EumuWxObXMKD7AVydheGXb9bAzsOyXoZpJBHMRNnaowQuWw3nbh1DXVQjLQ== X-Gm-Gg: AYBFou2IW0YkQt7Qzdi1xlKkP7qtANGq7M+IwELkdxuau0NOTgLcRkWeu5yhyEfYYol wdxLOMOy5LxFr7Ig/ZoEI3nxQdQLjWYU5W1DIg7KXrRl9ZLmtUipqql3Mde3VDgSWK+97BUsZQj K0PfmhGzdZCQ00uPPRvvgm49OvLiKbHheuDQ8dqaVmFLCKECw+uUJaAAcCA3oQb/ZxqOyeTfFUC cA5I8bZa9REhSjkZkjGFJc4aTwEwnV3n2kk+qJTHSK1NDZQH5j0P678ay5SZKTfsTziVDUslrO1 3nweQC6/5rqkysLhZv6jsVeP9Jc27JB6iyaWSRfaVyirquiyUR4iuRp6iUZi+M4ULdLucNy5/aL iwf+OJABatzJse0+NJ31+H8PqOnrfDt2NVpLeH2aa45UJdMlso74ZpH9qYM2vTGIlV3g1nlZMf7 473Wn17kQWljmtlV0Una90JBCGtUciXLUSUfMqTvSzOfgaTwcdhUzeu7Ax0J0u0jVtY6NW1wi31 XLtByB/qxbRLqJYapOA3x91vutex19njzgQ1bwoU+cmXlaCbBDR X-Received: by 2002:a05:600c:3e06:b0:49d:99:1d98 with SMTP id 5b1f17b1804b1-49d00991db1mr166780145e9.9.1788792829490; Mon, 07 Sep 2026 07:53:49 -0700 (PDT) Message-ID: <33a7c1f0-9bc2-4256-8234-91d7d6823db4@suse.com> Date: Mon, 7 Sep 2026 16:53:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] public/xen.h: Update comment on mmu_update sub-command size and PTE alignment To: Teddy Astie Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Frediano Ziglio , xen-devel@lists.xenproject.org References: <1787563949.8631fc262581453bbf619ec5b2062170.1a0331d3dbc000c4f3@vates.tech> <94e4e14c-11bb-48cf-aced-7ed6be8ad34a@suse.com> <1788789406.8631fc262581453bbf619ec5b2062170.1a07c283b48000c4f3@vates.tech> 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: <1788789406.8631fc262581453bbf619ec5b2062170.1a07c283b48000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788792835-032D8A5B-52DF429E/0/0 X-purgate-type: clean X-purgate-size: 3058 On 07.09.2026 15:56, Teddy Astie wrote: > Le 24/08/2026 à 14:13, Jan Beulich a écrit : >> On 24.08.2026 11:31, Teddy Astie wrote: >>> HYPERVISOR_mmu_update passes a set of request, where each request has a pointer >>> to the PTE along with a sub-command. >>> >>> The PTE alignment padding is used to transport the sub-command while the rest >> >> There's no "alignment padding" here. It's the low bits of a necessarily-aligned >> PTE which are used. >> >>> is used as an address to a PTE entry. The current documentation state that the >> >> Nit: states >> >>> 2 first bits are used for sub-command, hence the other ones for PTE which >> >> Better "2 low its", as "first" is ambiguous. >> >>> imply here a 4-bytes alignment on PTEs. >> >> The part after the comma I'm having trouble parsing. Can this please be re- >> written some? > > I agree, the wording is a bit weird. Though the name of the fields makes > it a bit odd to work with. > > We have in struct mmu_update > > uint64_t ptr; /* Machine address of PTE. */ > > yet, ptr is actually something like (pte_addr | sub_command). > > So we probably want to say that it's a number composed of a 8-byte > aligned PTE address combined with 3 low bits large sub-command ? Along these lines, yes. >>> On PV64 and PV32-PAE guests, all pagetable PTEs are 8-bytes aligned, hence >>> off-by-4 PTEs addresses are always incorrect. Non-PAE PV32 guests used >>> "legacy pagetables" which had 4-byte aligned PTEs. However, support had >>> been completely removed since Xen 4.0, and was only available when Xen was >>> built in 32-bits non-PAE mode [1]. >>> >>> Current Xen logic behaves as if 3 bits are used as sub-command, thus all >>> off-by-4 PTEs are actually rejected as being unknown sub-commands. >>> >>> Adjust the documentation to match the current logic implemented in Xen, >>> also expanding the documented sub-command parameter to 3 bits. >>> >>> [1] 84d54d5d8b31 ("i386: Remove non-PAE hypervisor build target.") >>> >>> Signed-off-by: Frediano Ziglio >>> Signed-off-by: Teddy Astie >> >> Did you forget to also add a From: tag? >> >>> @@ -260,21 +260,26 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); >>> * hypercall. Also if so desired the OS can also try to write to the PTE >>> * and be trapped by the hypervisor (as the PTE entry is RO). >>> * >>> + * Note: Historically, Xen had support for non-PAE PV guests with 4-bytes wide >>> + * PTEs (if Xen was built in non-PAE mode); which support got removed in >> >> A native speaker may correct me, but "which support" reads odd to me. Imo either >> "that support" or "support for which" (and then perhaps with a comma in place of >> the semicolon). >> > > Maybe it can be reworded as > > Xen had support for non-PAE PV guests with 4-bytes wide PTEs (if Xen was > built in non-PAE mode) until Xen 4.0. That'll be fine with me. Preferably "32-bit" instead of "4-bytes wide", though. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 14:57:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 14:57:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410923.1641727 (Exim 4.92) (envelope-from ) id 1x3amb-00027A-UR; Mon, 07 Sep 2026 14:57:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410923.1641727; Mon, 07 Sep 2026 14:57:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3amb-000273-Rq; Mon, 07 Sep 2026 14:57:17 +0000 Received: by outflank-mailman (input) for mailman id 1410923; Mon, 07 Sep 2026 14:57:16 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3ama-00025s-9r for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 14:57:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3amY-00G3d8-Te for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 16:57:14 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ed0b4-e002-0a2a0a5209dd-0a2a4505abe4-30 for ; Mon, 07 Sep 2026 16:57:14 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ed0ca-4cb1-0a2a45050019-d155dd2aec16-3 for ; Mon, 07 Sep 2026 16:57:14 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-4858be8b509so1570051f8f.0 for ; Mon, 07 Sep 2026 07:57:14 -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 ffacd0b85a97d-485885be1c1sm28553566f8f.32.2026.09.07.07.57.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 07:57:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788793034; x=1789397834; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=KyaRUQmJ8nPY1L6eHcD2/c7rGWnpm8vJp4444N2bS8g=; b=JlTOlDNfs8w+gmphMqarsN7KDe4CQrkYe7tkVAxoUgtZXeb+UG5YY0HOvgMjM9/pU5 OzowYHJInD20WJth2/pZBEzwsNeTzss97sSPM2RGpbk6GNU1b3vkuYJBUFy+r08HW/kS BJGK9o0ovd/dFt1RtM/Q5xUqO625hT8qKBvksqR1PUFUgeSPtjL4xyyq3kKM3fnqFXr1 QCmGBmJQbbYlK1uq2ygzADsLkL7nK+S11K4vRpYd8nVC1RIBo7+j1UAozme38BIgry/X LUeekEwjfMAvrStmwUNVTPdgLbjRQLj2lpaeQZIUIiwcAIqwPHjE0w/z/sZ6Qxln38qL 12SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788793034; x=1789397834; h=content-transfer-encoding:content-type: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:content-type; bh=KyaRUQmJ8nPY1L6eHcD2/c7rGWnpm8vJp4444N2bS8g=; b=XO/sQlW0mHeIJZRhNQXCJ7Dl8pteJJUyHsuVdcuk1MEx0YlaClSortubj9CsmvjJNM NR6I5wqe8X3k/WC7vzLW55qMe+d8yv8xwKwVX1zoPhXew0MHlKn6qo3HvjaKh8mD4jlm tjIQWeXs7Sq8Y2+AaZ8Wq2Iyvd4bWLai0DQtXRQVfvh8ig2RK6MnPJ33j3KOX6sr/CcH W7U7V6juJqW/aHV3PdJpR3qIVOCpAIbN9fhxjOBHBQHLRHXV5LHHsOnhe5gSMTACe0Gt js8nd6kEHBBvjjrRU6cHLz0JPQs/gXdRjx7Pi+9waiiUMIQ4+9TgSoG2YO48clNStcAV 8Jtg== X-Forwarded-Encrypted: i=1; AKwUvByVUscV9+lNrZSPxHAPsSeVU4o8Nx7LcpphGfspA0B8J5QTlgPWGoeM0IHH9eGOE4xtXkE50Qez/f0=@lists.xenproject.org X-Gm-Message-State: AFuF++kc2g+imJqYauZL0Y9dvsqC1ACafmguDCQs/GDxmTeLA5i1XrCK D/cGyto/xF/MKy5NqlNXWfjDELgd3k5FUkmEe29wFfIbCAPl4H+BHejC3nPeJ+/qEA== X-Gm-Gg: AYBFou1bZO9pvS4ilXy1bpG3IxgBKdgohsc7eVT5qV/JRETOlSWKu0W5oRAHZ7S8mBn 5uPPdtew2pQLTNr+nWgpu/YqIjkpgnfFuVfezjV1Jo0w2DDH29Iu+prG4Z9ZrTCKCZgS8FCNauf lApRSfJCfzpYY/ivFXlruXVEQt/1vxhkhfuDN5gaGHNxX14SI5KFK5rBNsTiziBupMwVuSGlqc3 pvaGmErYcJJESSRWHpOtBRAiqmVTMELGCieeVmvjCAkMlKQOSYXMFFVN007iHsDkku51ZIjmRMa 3F0HNInosFNI/0NbZ6bYzhENN7IQxJLfzcDqoD29iRvjnB4heo4xa5fveHLzS97Y2JKR0HTyVf7 TAvMKcnWDLtDUUzxHoRb70UzM3felqdA4WQuShZDgqaBxV1KZvOSJee/yucWC4BsF2E0UkK2VRZ Mvbz4VGhd9xBFf7wQ9GbB5xdYBlgk+x24bIzNfAoS2G3IfRPtqhjRjazTTOu/3DmIJ9Cj3wGOeo 6vsbOdlXOpEZ13KHBMqHcES5Drpi+int9LAAVjCgo5Yaan+ndHZ X-Received: by 2002:a05:6000:4029:b0:485:8bad:fb4a with SMTP id ffacd0b85a97d-4858badfe5bmr24135966f8f.7.1788793034322; Mon, 07 Sep 2026 07:57:14 -0700 (PDT) Message-ID: <3f23bfd1-8f55-43ac-a49a-825ad483f083@suse.com> Date: Mon, 7 Sep 2026 16:57:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/14] x86/pv: set/clear guest GDT mappings using populate_perdomain_mapping() To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-4-ecc269f268b7@xenproject.org> <39118b9f-2c63-4523-a7c6-76cc25d43163@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: 8bit X-purgate-ID: tlsNG-c201ff/1788793034-F5EA92A1-EC747458/0/0 X-purgate-type: clean X-purgate-size: 2900 On 07.09.2026 15:51, George Dunlap wrote: > On Mon, Sep 7, 2026 at 1:51 PM Jan Beulich wrote: >> >> On 02.09.2026 11:43, George Dunlap wrote: >>> From: Roger Pau Monné >>> >>> Until the previous patch, update_xen_slot_in_full_gdt() used the >> >> Please can we avoid "previous patch" (also again below) and alike in >> commit messages? > > Something like this then? > > 8<--- > update_xen_slot_in_full_gdt() used to update the incoming vCPU's page > tables with Xen's GDT through the stashed pointer in > d->arch.pv.gdt_ldt_l1tab, because map_domain_page() couldn't be called > in a context switch. Having a handy pointer to an always-mapped > version of the GDT/LDT L1 table, other sites which modify the table > started using it for convenience, even though they aren't called from > within a context switch. One example is pv{set,destroy}gdt(). > > With update_xen_slot_in_full_gdt() now using > populate_perdomain_mapping() (see "x86/pv: use > populate_perdomain_mapping() to map the Xen GDT"), the stashed > reference has lost the user that justified it. Switch > pv{set,destroy}gdt() to populate_perdomain_mapping() as well; the LDT > paths are the remaining users, after which the stash can go. > --->8 Sgtm, thanks. >>> --- a/xen/arch/x86/pv/descriptor-tables.c >>> +++ b/xen/arch/x86/pv/descriptor-tables.c >>> @@ -49,33 +49,42 @@ bool pv_destroy_ldt(struct vcpu *v) >>> >>> void pv_destroy_gdt(struct vcpu *v) >>> { >>> - l1_pgentry_t *pl1e = pv_gdt_ptes(v); >>> - mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page)); >>> - l1_pgentry_t zero_l1e = l1e_from_mfn(zero_mfn, __PAGE_HYPERVISOR_RO); >>> + const mfn_t zero_mfn = _mfn(virt_to_mfn(zero_page)); >>> + mfn_t zero_mfns[ARRAY_SIZE(v->arch.pv.gdt_frames)]; >> >> I wonder if having an initializer here might not result in better code. The >> array could likely be filled with REP STOSQ here, and ... >> >>> unsigned int i; >>> >>> ASSERT(v == current || !vcpu_cpu_dirty(v)); >>> >>> v->arch.pv.gdt_ents = 0; >>> - for ( i = 0; i < FIRST_RESERVED_GDT_PAGE; i++ ) >>> + >>> + for ( i = 0; i < ARRAY_SIZE(zero_mfns); i++ ) >>> { >>> - mfn_t mfn = l1e_get_mfn(pl1e[i]); >>> + zero_mfns[i] = zero_mfn; >> >> ... the live range of zero_mfn would reduce to about nothing. > > Tried it: GCC didn't use REP STOSQ [1], but seems worth it for clarity > and register efficiency anyway. Interesting - room for improvement there then. Jan > [1] Fable experimented with a few different compiler flags, but > couldn't get a REP operation; it said "The reason is structural: > GCC's string-op machinery handles block clears and byte-splat fills > (memset means a repeated byte); a fill with a non-constant 8-byte > value is not a memset and never reaches that expander". From xen-devel-bounces@lists.xenproject.org Mon Sep 07 15:14:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 15:14:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410932.1641736 (Exim 4.92) (envelope-from ) id 1x3b3A-0005z3-8n; Mon, 07 Sep 2026 15:14:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410932.1641736; Mon, 07 Sep 2026 15:14:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3b3A-0005yw-5o; Mon, 07 Sep 2026 15:14:24 +0000 Received: by outflank-mailman (input) for mailman id 1410932; Mon, 07 Sep 2026 15:14:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3b38-0005yn-6a for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:14:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3b37-00EG8y-9J for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 17:14:21 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ed4af-e002-0a2a0a5209dd-0a2a450bdb74-38 for ; Mon, 07 Sep 2026 17:14:21 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ed4cd-b7e8-0a2a450b0019-d155802ddcca-3 for ; Mon, 07 Sep 2026 17:14:21 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49b965570d7so43383295e9.0 for ; Mon, 07 Sep 2026 08:14:21 -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-49cf755c22esm317860845e9.0.2026.09.07.08.14.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 08:14:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788794061; x=1789398861; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=PMVyM4gT0ULYuoEwe8vmc7r/tdxbG+MESD/ICXqmTCc=; b=Wtoj8qUfynTmW/gaPyW9KbUEysi1RuLxubsq71TSqFtS8hA/rmbWhMv9SRG4XX0ubZ OtlJR/aQ5NgEwrpKLEM/dnBfYXpRW8usKOo+kMoQ1tKjcJsOG6Gek4ISIi81+PbhcjUD EZiVfwOi//05scr1wumZ08jKHz2thZmjS5Qp2DukpMtks9HujxF3zDs4RBoixTq6LgcM pWqtveY9hMVWzKK3kHbMNsJ9Vm54vgw0nOCxqmj/KVJcDuePO4Rm0L0W0x822qsCIv5f olP9A+geHvf6vnhAk2rlskSex5dtzUYg+bBj+gmQJNhkXomXEaqUQbfHjSoPsmQhUyew cmGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788794061; x=1789398861; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=PMVyM4gT0ULYuoEwe8vmc7r/tdxbG+MESD/ICXqmTCc=; b=pRT7p4O3MKtaKiquQMue7vTb1BrXYFcw0oVutp3JdJ5QSl94KRVLr2rQhRYeRi0dp1 1+IK7YbxB4THWgTjcE+Y/0Byy5ElkL91BQ8xQwDN6gDKzei7NwJ0r9RB9YU1sAAV/nDT uMPRpnyB923cibRZGZgTFF1lyzh0ElvtzSOL/44JPukfrE7uBBItsJwWByJ9UcqBUZBK CDn36SlDhFWy8oAyefSkatte7pY+2lc9XNOM9/en21BulhTIWaG8TroNPvUCDqAmr7tl 50vLHucwdpETGecDiW6RGv8nE09lHI3HuDuECiUYTy0beLAWV6k7S18pSgzmr4waUK3H mHpQ== X-Gm-Message-State: AFuF++nK/Eq8AVl+oYbL6wJueC61OAiD5/VdzwDuTWDgZhxAdFBENqJn 0k+OSrlYP3ylpgA61MnV5Nxj2SNh5G+jH+F9eCsofBNHzdlA3iNbC5CsWfo3yT0wHIMCSOgNZ1i lf0L7iA== X-Gm-Gg: AYBFou0dAVOFHwKGuApJMsfhwRmUzDP5JRjk17iDwTAxqgZKAKR4MBhbA812qyt+3kg 4wuT40lmwV5RENhXrcch3Q67KhwowryBBPOSGZcSj42mWssNh5krBGMTXNVg9/usxfHwRCaj2hk h56SbILWsN2UJHib8sc+XglfsNWVugrJWyr2jZ58RQrW5PICkXFJPAJ/wwaMNR1L5dptLYC5In6 WffVhFC1QkFGCprvjjyzYbCC4CmVkYjs/OL+5NUfA+SqFfOYHXRqinxGH29VyV37cxf0r/Ol2mW WJlkmCBhDQzaBITy61rd57SOF8mB7ke4/Tj+EGWnNzJ7eQv0WqadnP3YNWIDZgfUF4DB5/T4eOz v2SWZAG4gVP9bq851srqcW9Olun1B9vYFmvM/RjBR3LAokTBvPQTLH47RvOU4Gf4H9PuHLRrQoc Q9Jd7wt3Vezme5Bk8q41fZ9COUN21j1PJ9kWVVqhuaXBjFKlDFl0v1OrOdGuSVUfK1a9GGrwhsn TjOBQ6eGVIf+jrJ4iv0EAT5Z1ca/dND4AQgh6XE2VyvOlyFKzKk X-Received: by 2002:a05:600c:4fc9:b0:49c:fc6e:8cb9 with SMTP id 5b1f17b1804b1-49cfc6e8e1emr203795765e9.29.1788794060612; Mon, 07 Sep 2026 08:14:20 -0700 (PDT) Message-ID: <4326ea69-572c-4a1a-ba89-147fab55b2d5@suse.com> Date: Mon, 7 Sep 2026 17:14:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Marek Marczykowski , Daniel Smith From: Jan Beulich Subject: [PATCH] EFI: don't use alias attribute for compat hypercall stubs 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788794061-19AC09EA-4F87FE96/0/0 X-purgate-type: clean X-purgate-size: 817 Recent Clang objects to types differing between alias and aliasee. Accept the unnecessary overhead and make the two compat stubs real functions. Signed-off-by: Jan Beulich --- a/xen/common/efi/common-stub.c +++ b/xen/common/efi/common-stub.c @@ -27,10 +27,14 @@ int efi_runtime_call(struct xenpf_efi_ru #ifdef CONFIG_COMPAT -int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *) - __attribute__((__alias__("efi_get_info"))); +int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *info) +{ + return -ENOSYS; +} -int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *) - __attribute__((__alias__("efi_runtime_call"))); +int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *op) +{ + return -ENOSYS; +} #endif From xen-devel-bounces@lists.xenproject.org Mon Sep 07 15:16:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 15:16:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410941.1641746 (Exim 4.92) (envelope-from ) id 1x3b4l-0006b0-IX; Mon, 07 Sep 2026 15:16:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410941.1641746; Mon, 07 Sep 2026 15:16:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3b4l-0006at-FB; Mon, 07 Sep 2026 15:16:03 +0000 Received: by outflank-mailman (input) for mailman id 1410941; Mon, 07 Sep 2026 15:16:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3b4k-0006al-Gv for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:16:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3b4j-00ACV8-TC for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 17:16:01 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ed50f-e002-0a2a0a5209dd-0a2a450cd178-46 for ; Mon, 07 Sep 2026 17:16:01 +0200 Received: from [40.93.198.68] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ed530-f479-0a2a450c0019-285dc644ea79-3 for ; Mon, 07 Sep 2026 17:16:01 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA2PR03MB5705.namprd03.prod.outlook.com (2603:10b6:806:11a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Mon, 7 Sep 2026 15:15:58 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Mon, 7 Sep 2026 15:15:58 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TV5QItgNMRiZVuGiSXMdm34Qj1eTF/m+KTf+Xxk0525u6hX9rdLhJ/f3TC8guB8B6vtqedYVwfbsUzrd34OfOffHtw3VTQUmnUeoLStAKS0VSiLn0BqYUH1B2znokNTo5FJwhdfNqDCz1zLLWuQD70JyNwbBp0VxoUezH1sqA2M3p4p0GbpHbonkzgZSs/czvTP4WFjDZDBasCTrrGttngNixHUEvgGLAgT5wmdNZpzQs6Ww6N87ta0oiJgKUCMwenkXM+ficUacM+j0WUAjyW3tZD1j5EjsikGJDgekv5kAGkURUFUu5QHQa4ZKUzmFygaG5gZ+GwqdHHWsK618bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9d7RCEnJ7qkoWNu6bXse0/3RGXFhgVEUq560o+40iGw=; b=INBWVxXeBW3nRBoOEwst7K/o3xMQxC67+0yHDdemBq4Jb6jn40upZboeBrge08Otih1H9Msvd9d1kOM89a5aQdtyFIeAfuRRseX0xJNZkCr/CL5NUEm42sSqZo9QozeDxR2wliL+ck8AAsrqTDNRgSR1uKG61Cc/Y74hReNNm9yisqJEHLnl6V0fjVlgi3MMo1cccKZKQGINmM6TsxQguMuaf+9+gNIAjdx/KheYmnBU9BoH6NWCNhvATuNwH47vvt324yEHGDdJeb5ZNuUCUUJIvd8/BgwCZJvKp1DqZsZyxpQEuSzr5vZ2EEaV+TW8Wt4L2mNVgojhpLrc2tEbOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9d7RCEnJ7qkoWNu6bXse0/3RGXFhgVEUq560o+40iGw=; b=Gp6aG4YUDYl3m5Y0XvVeqZTUNGkWUgxroihOxy5qJQyrD98GR3iqNlAf+IMLNG4bpRZ+QDVp2XOeWUk71DdblV1YRjT3CtOk9hsod7UYdMuQsUxqZzOCVxbhRFCSj8thG6GLHvFZh5wF7vNrVh+MXuJRbGLU0ghMGq9ni/BwPOc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5a3b475d-6c1f-47da-89be-ae45e34c4e49@citrix.com> Date: Mon, 7 Sep 2026 16:15:54 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Marek Marczykowski , Daniel Smith Subject: Re: [PATCH] EFI: don't use alias attribute for compat hypercall stubs To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <4326ea69-572c-4a1a-ba89-147fab55b2d5@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <4326ea69-572c-4a1a-ba89-147fab55b2d5@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P123CA0095.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:139::10) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA2PR03MB5705:EE_ X-MS-Office365-Filtering-Correlation-Id: 4b694d65-60ad-488b-21e2-08df0cf2eb44 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|6133799003|10067099003|11063799006|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: q/uxnTi4skFYPawT6p/cyTID39qJ1lwrPxDMv7749ggVIS8SD7yKFV+JpNX3du9ylOlNXk3tC790SIiooNpWw49ZkRvt77k1dbeicDupeSD7xDeSMe1DjKDiAtzD3UnqxDHFX9tzBoDtqX44JWfm7TzCi0bJArKbe+huU8z/nzQSS83kgl83UD656UVNWax+RvNaW08yB2J+8+rik5WVtLerNAPETf6XJzUi/W7OM/r0AqwNWgXxKQPCniCtKcpb6U6zZj+sFoOchJ/yp+PYDEtQUtM8TLvzRMKHpN4YhowtC+xedOFpWLfMAC8drIcpHwbz0VW6CAzYVIWkEggEl+rcI1VIx3phNTG/UC21vucCkaa+QeWvkEUHuHJz22Ue2ieaxBwqvzUUgd6oRkoEABRwnvgx5VjrSjiU3ZK4Y9vOcFCPKBnd0BMmcBR6kWwTUDnRm1Ak9rj8QPm6N4TYFkVQ1ymj2zb2bVydrIOtXl4BU5k4rNavxQLwPgx8JuQtDM2KwAWzQgJZT1T+zLLiW7BxDjnYWkmdC3HMEntjtXQm0ajGrfuZ3+JM6heNWYbEWaMTQJximASTDGrsSlNsoQUIt5E44FOIYMhmQ0oVtEVIHKe6iwCYD1I458jgWZD0IvS/sCzygvQQbVX57pCjJz/w8dN3RtFpZ+kwJTMYMTA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(6133799003)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MVlNSjR3aU9aaXNsYlduNm94c2lyNTE5OUlXbXlJNk5oblNTTC9hRkZhSWdp?= =?utf-8?B?L3dUdzltb2hub1MwVEsxVjdrdFZTU1B6ZW5CSlp0dHpvN1paZno3SmQ0bVJi?= =?utf-8?B?YlM0clpHOFhIWHBVemc4SWdQeFoxdEVpWlN6a0dvQ2RIU0ZUeUU0empCbEMy?= =?utf-8?B?d0JkY3RDd0IrRmNoUE1rM0ZZWWh6bklyckM4Y0JhRzE1SDdXNVl6bXVVekgv?= =?utf-8?B?YmdPTnhQa2d0OFdRajBPT29kdmdMS1R3elJYbUtKa0RGVmRVTWx5dlJZdmZL?= =?utf-8?B?RHpyRTgrVjYzVnZSb29iY0ZGKzc4cFBCckFadjJVUk93MGFnbFhGTkk1cEVi?= =?utf-8?B?Z1VFZVk3ZHZxUkdBRHRGelkya092M3JORWZrZWt4aTliNXo0TG1YOUZkb1py?= =?utf-8?B?U2ozNW5TNjV2K2Y1dU5tMThCbUlUQ3VnUlYwdnFYRFpyNDNPSHV6dXJ6RlNU?= =?utf-8?B?UEt6NUZyeVUvUHNZZ1NwdmpsSzJSSUJ1UUYxeDNISHp6R2p5NHBRWXdmRTkz?= =?utf-8?B?eFhiTmpNdE0yZTlMZ1V5ZHJZRXUvR1NZWFAyY0tiekpvRmVuVFpsMGx0ak01?= =?utf-8?B?a2hDMkNlQzBacEt4dnJQa3hrRU1hYms1UFlaUVNlTXlrcldBV2V3b29QaTNM?= =?utf-8?B?VmJWaTRGNXVMb0Vld0oxaXZxZk02Zk8rY0VpaW5aWkVFRlhYN003WFRzNk8y?= =?utf-8?B?SWlaUGRyYXY5eVpjdkxnT3JXcFoxRWZqK1FCZXUwNDFXaHhHSkVmcTA2ZTJ1?= =?utf-8?B?YTJnVnEwcGl5UDJrS2l5L3UwVUdhdHZjUnRQY3lvdkZsaHhxNWM2TUYxKy90?= =?utf-8?B?SXFJNzJGYXQ5dy9ITExQVm5CL3FubExSYmZhT09NL1NxNEI2eCtzcHJwV1pZ?= =?utf-8?B?cWlUWUNGZDQ2TWJrTGt4VDFoNktLN2RoRE1pdlQ3N2NwTHV5R1lhUk52cEk0?= =?utf-8?B?cGcydGlseDdlOWI3TEg0OUFNcDFub2lJYU9UTlQxUU8yTzUzZ0xGYlNJWWNE?= =?utf-8?B?NSswZEpBZUhkcDE4bVhFR2NMY28yVWFQbmdRdmtaQnNCd0xGb3c1TGEvYTVs?= =?utf-8?B?Y1dUQ2NBbHFMdFFhcDdvNXJHTXM1Mm9oR0hNZVgwbjBHc3c0ZGV6SmErZlRt?= =?utf-8?B?NisrQUxaS2JNV1lEUitteEdlNUZwRnVGSkVDa1dCOUFFNC94TGJwQXNydXZZ?= =?utf-8?B?K1VZQzdYM1BWakM3OEVRZTlvMzJ0VFhBNGcxNE84cm9kdmF2MlJpRCtNL3ZZ?= =?utf-8?B?UEFleE1rT0pEUzkyVVB1NEZlUjhPUjZJS3g4dFJDTURqODFPOG9Td0R6Tk1Q?= =?utf-8?B?dU9GS1orVkp0NEo2QVpOZStaSDlHU01DWTlFQWJMVVM4YVFWZUVUYzJYZkdw?= =?utf-8?B?c3IxWndiRmxyR084UG4vR1R4M1VBallYNERHUUNyVklVTjU1TWxZNUV1aHYr?= =?utf-8?B?N1hJcjFHMG5FQmJ0Skc5aDhpL0FaaEdjeXBaMUQ3Wmd0MVpvVHdkRW1wbFVY?= =?utf-8?B?aFFkSXg5Y0IvMVMxQUdPTTdXcHFNVHVpTEZxbUNveDlTNTN2MG9Nbjd1dm5X?= =?utf-8?B?VmdDNStyc0VkblUxVkJ5cHFlWlp4QVFLc3hKbkNFZTdFdzRyOUtyYktXVXV4?= =?utf-8?B?NzA2dFptdGY3M1JPMkQ5dGZkcEhqRmdqWEEwYi9wNFBZRTZxMzIza1BLS0Zu?= =?utf-8?B?UElhTGk5R25nUEphSGo5UFBUTDdyVTFsdDg5bXBtY092cklWeE5US0l6Ykh0?= =?utf-8?B?cnhOM2JwcWJqbm5BVDY5VDZSZmFzYUFuMUpxbERsVGxHUEltMWVaWmM5cmVy?= =?utf-8?B?UndRd2RjU3YwbmIzdlJ4V2dGSW9Ya3RTOUtXVXZINjIzT1Z5Sm5qVzFTdm8r?= =?utf-8?B?ZHZGb2lIUDlZdzB5Q1BIeUVhS0s1eUFPNW85U3hxaWE2NDhtREhuVkxvaUF6?= =?utf-8?B?bmUwREVDMXNEdVhaMkVpNElDbWt4Y0dBVURtbFlQZEFNSk9qbDFrcmZteUlE?= =?utf-8?B?aDRPTWxmN294cmpYQlk5dEo2Y0M3WmFHK2lHRGhVK1k1aForTjA2aHQwaDRG?= =?utf-8?B?RkdRR0tramxwWkpwV2JxZzNWNkJCNFgyNGp2TG5BZXlyV0oxSTdZWThuNFMx?= =?utf-8?B?eVFrYTNuRlRJQlhwcmkxbEtQSGZQa0pNdm5FaXBvUEdwelkxaVFJWVlGaWFo?= =?utf-8?B?NlB2MTdHQTl4MmJsbkdHeFE4a3hBWmY1UkhidzNzdWVLK1JweksxSmJMOEdY?= =?utf-8?B?RXZSdTNUTFp3ZEQxNGFIMVN3bHdWVUZDbVVsODRORUVnNGs5TlNVTGVmM0dw?= =?utf-8?B?WllIOW5QaFBjcE0vbEFxenpabSt4Ymc2MlI0d0pCTlhNT2VCRkd3Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b694d65-60ad-488b-21e2-08df0cf2eb44 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2026 15:15:57.9281 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 4I8PKKG/F1GgLxALXmqR7FxDsqoRVyLwP9+S0XW4J0G5seBcVEcHZjpVNn56R5KZCH2+sUX9Dw+v5G4pU0S9cAAx1gtw+xUMncGztIY/i/g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5705 X-purgate-ID: tlsNG-d25034/1788794161-006CEA5B-052A99A0/0/0 X-purgate-type: clean X-purgate-size: 302 On 07/09/2026 4:14 pm, Jan Beulich wrote: > Recent Clang objects to types differing between alias and aliasee. Accept > the unnecessary overhead and make the two compat stubs real functions. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Sep 07 15:57:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 15:57:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410960.1641755 (Exim 4.92) (envelope-from ) id 1x3bih-0006xe-KU; Mon, 07 Sep 2026 15:57:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410960.1641755; Mon, 07 Sep 2026 15:57:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3bih-0006xW-H6; Mon, 07 Sep 2026 15:57:19 +0000 Received: by outflank-mailman (input) for mailman id 1410960; Mon, 07 Sep 2026 15:57:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3bif-0006xQ-P9 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:57:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3bie-001pHD-F0 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 17:57:16 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9edec2-2eae-0a2a0a5409dd-0a2a4505bff4-34 for ; Mon, 07 Sep 2026 17:57:16 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ededb-4cb1-0a2a45050019-b9ff1c229643-3 for ; Mon, 07 Sep 2026 17:57:16 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a07c968185000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 07 Sep 2026 15:57:13 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id A1D8280789; Mon, 7 Sep 2026 17:57:12 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=EgOs7JPzGam1Fpl29GasqI8GLvb/vDiU5k36KsaeRJc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=FxqRqYxWNpprn9CCzB8aZE+zngC3YSn8Jn0lUYIjHzOSOQ47d4uO5JaK9I8VtQ69zvFuRsgbn b38BtuBV47Dn2gHqWjyRYpSIOebCRw57bZHoPKauVVihUweJ7c3CDKO9MXKktniLK9Fowmh+QNl 6CkxVave1KU3oHvGEWjI5pfHBqXjFGk9roTX0y7/EdCBkFubQMtr4IYh/ZlwaPfdiT+fDkDZ5Ya +kV0Bwl+azsEJOINLGIooL+oc4xSrf4dIYsjRmSmKkB6j1mStxE0HiDf/USQksXgMa1Kgq1l+Ug 34cRBHR78ptO0HC6MpI1+Mw7M8/A9JzoSqpAvkuoHICA== X-Zone-Loop: a6400040302f8247c486706b092b3b8473d38f4a5e04 x-campaign-type: default x-transaction-id: edb9a02f-d5cf-468b-90ca-ff5e28aba6c3 x-swg-uid: 01-11f25bc9-f0d2-431e-bf6f-953bbba4381b X-Mailer: Sweego Message-ID: <1788796633.8631fc262581453bbf619ec5b2062170.1a07c968185000c4f3@vates.tech> x-swg-bid: 1788796633.8631fc262581453bbf619ec5b2062170.1a07c968185000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> Date: Mon, 07 Sep 2026 17:57:03 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788796632; l=12091; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=xVbthVlFdzn4JrnWWiG8bYfo/RvVk41EN2jucCbnq1Y=; b=hLOiCdH2kENcw7CLkl3au6ty0IHGv0/8a1xP5SPIlhEgu83+MwdxOxvjRYPJeOP6OzZoazF2w 7DatlIM3T1RCVwt1ylskztCGo1B4R1AjvyXJGg1iw2TWpHnwSKFfZbu X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788796632910 X-purgate-ID: tlsNG-c201ff/1788796636-247132A1-7A469C0E/10/73395122804 X-purgate-type: spam X-purgate-size: 12091 > Extend the RISC-V exception table format to include a type and > auxiliary data field. > > The existing format only supports simple fixups. Some use cases require > additional context from the fault (e.g. capturing trap information), > which cannot be expressed with the current EX_TYPE_FIXUP entries. > > Introduce a generic ASM_EXTABLE_RAW() helper to describe entries with a > handler type and associated data. Reimplement ASM_EXTABLE() in terms of > it using EX_TYPE_FIXUP for compatibility. > > Add EX_TYPE_TRAP_INFO to allow handlers to retrieve trap state > (sepc/scause/stval) and pass it to the fixup path. The data field is > used to encode which GPR contains a pointer to a struct trap_info. > > Provide ASM_EXTABLE_TRAP_INFO() as a convenience wrapper for this case. > > Also add gpr-num.h, providing symbolic GPR numbers for use in assembly > and inline asm. This is derived from Linux 6.16 with minor adjustments such > as using .irp instead of open-coding the same using a set of .equ. > > Update the exception handling code to dispatch based on the entry type. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/extable.c b/xen/arch/riscv/extable.c > index 5b89c4278c..6470198d01 100644 > --- a/xen/arch/riscv/extable.c > +++ b/xen/arch/riscv/extable.c > @@ -6,8 +6,10 @@ > #include > #include > > +#include > #include > #include > +#include > > #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field) > > @@ -32,6 +34,12 @@ static void __init cf_check swap_ex(void *a, void *b) > > x->fixup = y->fixup + delta; > y->fixup = tmp.fixup - delta; > + > + x->type = y->type; > + y->type = tmp.type; > + > + x->data = y->data; > + y->data = tmp.data; > } > > static int cf_check cmp_ex(const void *a, const void *b) > @@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_table_entry *ex, > regs->sepc = ex_fixup(ex); > } > > -bool fixup_exception(struct cpu_user_regs *regs) > +#define CHECK_GPR_INDEX(num, name) \ > + BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) \ > + != (num) * sizeof(unsigned long)); > + > +static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, > + unsigned int num) > +{ > + /* > + * The GPR number -> struct index mapping below relies on x0..x31 being > + * laid out at the start of struct cpu_user_regs in architectural order, > + * matching the register numbers GPR_LIST() hands to the assembler. > + */ > + GPR_LIST(CHECK_GPR_INDEX) > + > + ASSERT(num < 32); > + > + return ((const unsigned long *)regs)[num]; > +} > + > +#undef CHECK_GPR_INDEX > + > +static void ex_handler_trap_info(const struct exception_table_entry *ex, > + struct cpu_user_regs *regs, > + unsigned long cause) > +{ > + struct trap_info *trap_info = > + (struct trap_info *)regs_get_gpr(regs, ex->data); > + > + BUG_ON(!trap_info); > + > + /* > + * Only stval still needs a CSR read: sepc and scause were already > + * captured by the trap entry path and do_trap() respectively. Latch > + * trap_info->sepc before regs->sepc is pointed at the fixup code. > + */ > + trap_info->sepc = regs->sepc; > + trap_info->scause = cause; > + trap_info->stval = csr_read(CSR_STVAL); > + > + regs->sepc = ex_fixup(ex); > +} > + > +bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause) > { > unsigned long pc = regs->sepc; > const struct virtual_region *region = find_text_region(pc); > @@ -77,7 +127,23 @@ bool fixup_exception(struct cpu_user_regs *regs) > if ( !ex ) > return false; > > - ex_handler_fixup(ex, regs); > + switch ( ex->type ) > + { > + case EX_TYPE_FIXUP: > + ex_handler_fixup(ex, regs); > + break; > + > + case EX_TYPE_TRAP_INFO: > + ex_handler_trap_info(ex, regs, cause); > + break; > + > + default: > + printk(XENLOG_ERR > + "Unsupported exception table entry type %u for pc %#lx\n", > + ex->type, pc); > + > + return false; > + } > > return true; > } > diff --git a/xen/arch/riscv/include/asm/extable.h b/xen/arch/riscv/include/asm/extable.h > index c0128a9181..7378f86e7e 100644 > --- a/xen/arch/riscv/include/asm/extable.h > +++ b/xen/arch/riscv/include/asm/extable.h > @@ -3,17 +3,24 @@ > #ifndef ASM__RISCV__ASM_EXTABLE_H > #define ASM__RISCV__ASM_EXTABLE_H > > +#include > + > +#define EX_TYPE_FIXUP 0 > +#define EX_TYPE_TRAP_INFO 1 > + > #ifdef __ASSEMBLER__ > > -#define ASM_EXTABLE(insn, fixup) \ > - .pushsection .ex_table, "a"; \ > - .balign 4; \ > - .word (insn) - .; \ > - .word (fixup) - .; \ > +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ > + .pushsection .ex_table, "a"; \ > + .balign 4; \ > + .word (insn) - .; \ > + .word (fixup) - .; \ > + .half (type); \ > + .half (data); \ > .popsection > > -.macro asm_extable, insn, fixup > - ASM_EXTABLE(\insn, \fixup) > +.macro _asm_extable, insn, fixup > + ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0) > .endm > > #else /* __ASSEMBLER__ */ > @@ -23,20 +30,36 @@ > > struct cpu_user_regs; > > -#define ASM_EXTABLE(insn, fixup) \ > - ".pushsection .ex_table, \"a\"\n" \ > - ".balign 4\n" \ > - ".word (" #insn " - .)\n" \ > - ".word (" #fixup " - .)\n" \ > +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ > + ".pushsection .ex_table, \"a\"\n" \ > + ".balign 4\n" \ > + ".word (" insn ") - .\n" \ > + ".word (" fixup ") - .\n" \ > + ".half (" type ")\n" \ > + ".half (" data ")\n" \ > ".popsection\n" > > +#define ASM_EXTABLE(insn, fixup) \ > + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_FIXUP), "0") > + > +#define EX_TRAP_INFO_REG(gpr) \ > + "(.L_gpr_num_" #gpr ")" > + > +#define ASM_EXTABLE_TRAP_INFO(insn, fixup, data) \ > + DEFINE_ASM_GPR_NUMS \ > + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_TRAP_INFO), \ > + EX_TRAP_INFO_REG(data)) > + > /* > - * The exception table consists of pairs of relative offsets: the first > - * is the relative offset to an instruction that is allowed to fault, > - * and the second is the relative offset at which the program should > - * continue. No general-purpose registers are modified by the exception > - * handling mechanism itself, so it is up to the fixup code to handle > - * any necessary state cleanup. > + * Each exception table entry consists of two relative offsets and a > + * handler description: `insn` is the relative offset to an instruction > + * that is allowed to fault, `fixup` is the relative offset at which the > + * program should continue, `type` selects how the exception is handled > + * (EX_TYPE_*), and `data` holds auxiliary information for the handler > + * (e.g. for EX_TYPE_TRAP_INFO, the number of the GPR that contains a > + * pointer to a struct trap_info). No general-purpose registers are > + * modified by the exception handling mechanism itself, so it is up to > + * the fixup code to handle any necessary state cleanup. > * > * The exception table and fixup code live out of line with the main > * instruction path. This means when everything is well, we don't even > @@ -45,14 +68,15 @@ struct cpu_user_regs; > */ > struct exception_table_entry { > int32_t insn, fixup; > + uint16_t type, data; > }; > > extern struct exception_table_entry __start___ex_table[]; > extern struct exception_table_entry __stop___ex_table[]; > > void sort_exception_tables(void); > -bool fixup_exception(struct cpu_user_regs *regs); > +bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause); > > -#endif /* __ASSEMBLY__ */ > +#endif /* __ASSEMBLER__ */ > > #endif /* ASM__RISCV__ASM_EXTABLE_H */ > diff --git a/xen/arch/riscv/include/asm/gpr-num.h b/xen/arch/riscv/include/asm/gpr-num.h > new file mode 100644 > index 0000000000..3b97a72e6c > --- /dev/null > +++ b/xen/arch/riscv/include/asm/gpr-num.h > @@ -0,0 +1,37 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef RISCV_GPR_NUM_H > +#define RISCV_GPR_NUM_H Nit: commit message says this is derived from Linux 6.16. Other imported RISC-V headers here carry an in-file note (bitops.h: "Based on linux/arch/.../bitops.h") but this file doesn't. > +/* > + * GPRs by ABI name, together with their register number (x0 .. x31). > + * > + * This is the single source of truth for the mapping: it generates the > + * .L_gpr_num_ assembler symbols used to turn a register name emitted > + * by the compiler into a register number, and struct cpu_user_regs is > + * checked against it at build time (see regs_get_gpr()). Neither list can > + * therefore be changed without the other. > + */ > +#define GPR_LIST(x) \ > + x(0, zero) x(1, ra) x(2, sp) x(3, gp) \ > + x(4, tp) x(5, t0) x(6, t1) x(7, t2) \ > + x(8, s0) x(9, s1) x(10, a0) x(11, a1) \ > + x(12, a2) x(13, a3) x(14, a4) x(15, a5) \ > + x(16, a6) x(17, a7) x(18, s2) x(19, s3) \ > + x(20, s4) x(21, s5) x(22, s6) x(23, s7) \ > + x(24, s8) x(25, s9) x(26, s10) x(27, s11) \ > + x(28, t3) x(29, t4) x(30, t5) x(31, t6) > + > +#ifdef __ASSEMBLER__ > + > +#define GPR_NUM_EQU(num, name) .equ .L_gpr_num_##name, num; > +GPR_LIST(GPR_NUM_EQU) > +#undef GPR_NUM_EQU > + > +#else /* __ASSEMBLER__ */ > + > +#define GPR_NUM_EQU(num, name) ".equ .L_gpr_num_" #name ", " #num "\n" > +#define DEFINE_ASM_GPR_NUMS GPR_LIST(GPR_NUM_EQU) > + > +#endif /* __ASSEMBLER__ */ > + > +#endif /* RISCV_GPR_NUM_H */ > diff --git a/xen/arch/riscv/include/asm/processor.h b/xen/arch/riscv/include/asm/processor.h > index b1745c1071..e7b0f2321a 100644 > --- a/xen/arch/riscv/include/asm/processor.h > +++ b/xen/arch/riscv/include/asm/processor.h > @@ -12,7 +12,19 @@ > > #ifndef __ASSEMBLER__ > > -/* On stack VCPU state */ > +/* > + * On stack VCPU state. > + * > + * x0..x31 must remain at the start of this structure, in architectural > + * register-number order: code which resolves a register number to its saved > + * value indexes this structure directly (instruction emulation via > + * REG_PTR() from asm/riscv_encoding.h, exception table fixups via > + * regs_get_gpr()). ->zero therefore has to stay at offset 0 and must always > + * read as 0, since it supplies the value of x0 when x0 is used as a source > + * operand. The layout is checked against GPR_LIST() at build time; see > + * regs_get_gpr() in extable.c. Do not reorder these fields or insert > + * anything between them. > + */ > { > unsigned long zero; Comment claims ->zero "must always read as 0" as it's hard-wired to zero by the HW, but nothing enforces that, it's still a plain writable unsigned long. Maybe a write-side counterpart that special-cases num==0 as a no-op, or with a minimum ASSERT(num != 0) / BUG_ON(num == 0) to anticipate any future forbidden writes. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Sep 07 15:57:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 15:57:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410962.1641773 (Exim 4.92) (envelope-from ) id 1x3bir-0007OR-2n; Mon, 07 Sep 2026 15:57:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410962.1641773; Mon, 07 Sep 2026 15:57:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3biq-0007OJ-VC; Mon, 07 Sep 2026 15:57:28 +0000 Received: by outflank-mailman (input) for mailman id 1410962; Mon, 07 Sep 2026 15:57:27 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3bip-0007Lt-Q7 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:57:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3bip-00111U-6e for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 17:57:27 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9edee3-e002-0a2a0a5209dd-0a2a450bcb8c-6 for ; Mon, 07 Sep 2026 17:57:27 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9edee3-b7e8-0a2a450b0019-b9ff1c229b35-4 for ; Mon, 07 Sep 2026 17:57:27 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a07c9684ae000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 07 Sep 2026 15:57:14 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 87732840A3; Mon, 7 Sep 2026 17:57:13 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=K2JiV2l64MiUPAkrL8g3m/vsaQjxcNNBdSjgGcbCx0s=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=e8tZgygLIehJHYpIKhd2gUmjD8AlRFqFbhEMc6+soVSVGSnUQMX2TvUPE41lK5cMfqvZsfK7F j+dnF2MCgD/jVJGoDkuemoiYDpv7ng4DbOhghkWA0SKSUJv6q17Dyh0EH5vZ5z3gdMxkVv17KP4 vBkr/4dupnUEy2fPlxIEscEtrIg0uMMaEwofAXANbF5pItmgq5frdhJ4EO+0rWZHOoGq8zssfum c6N75a+Gpbbw/ih7s3ebSiZ6nSXz+lZ+jkYFZWOd8SrQamHkJJZd9ACF/4el3u956hioX/y9stw HsPGN2x7pc4Z3Pgc7bGZ/sTRMYIKjvIXHoIAX7ebEiOQ== X-Zone-Loop: b16d8af7a75364fe99864d450971367f86bf4531a0bc x-campaign-type: default x-transaction-id: 9234ac01-ab3a-4d70-9d4e-8be8d1d4b3e5 x-swg-uid: 01-83b1b9d6-7988-455a-a69f-7867cc56d257 X-Mailer: Sweego Message-ID: <1788796634.8631fc262581453bbf619ec5b2062170.1a07c9684ae000c4f3@vates.tech> x-swg-bid: 1788796634.8631fc262581453bbf619ec5b2062170.1a07c9684ae000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 18/39] xen/riscv: add guest page fault handling stub From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.com> References: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.com> Date: Mon, 07 Sep 2026 17:57:03 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788796632; l=4745; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Xz9T0Naka2ZxLXOY0iG2z3w0ta6fjbdRTIqPiotud1M=; b=qH/JkXhmvH35uaDyKSAwfQmqNQKw/zLhBjDgScH8XsnpowZ1+ANZgMm0vpmtnXUHmkt88BS7L dH2GK41O8IWCjqdf+/9NLUrH/wxop7MpFxNjTO14hOLvY4CE+SCw6Q8 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788796633879 X-purgate-ID: tlsNG-42698a/1788796647-AAEDE9EA-CA122EB3/10/73395122804 X-purgate-type: spam X-purgate-size: 4745 > Add a handler for guest page faults and hook it into the trap path, > providing the trap-side entry point which will later feed the MMIO > dispatch. > > This will be used, for example, to trap accesses to APLIC registers so > that a guest can initialize and drive an emulated interrupt controller. > > Two of the situations handled here are already decided, as neither can > ever be turned into an emulated access: > > - A fault reported with a pseudoinstruction in htinst was taken on an > implicit access made for VS-stage address translation, so htval holds > the address of a VS-stage PTE rather than of anything the guest asked > for, and the guest physical address behind the original access is not > known. This is orthogonal to the cause and can accompany any of the > three, which is why it is checked first. scause keeps reporting the > type of the original access, and on bare hardware a PTE which cannot > be read raises an access fault of exactly that type, so reflect one > back to the guest. > > - A fetch fault means the guest tried to execute from a guest physical > address which is unmapped or which G-stage does not allow to be > executed. On bare hardware a fetch from physical memory which does > not exist, or which may not be executed, raises an instruction access > fault, so reflect one back too. > > Explicit loads and stores are where MMIO emulation will hook in. > > Neither of the two paths above consults the p2m first, and neither will > the MMIO one: RISC-V has no populate-on-demand, no paging and no > mem_access, so every guest mapping is established eagerly and a G-stage > fault never denotes a mapping Xen could install to let the faulting > access complete. > > Both of the helpers this leans on, resolve_faulting_gpa() and > trap_redirect(), are BUG_ON() placeholders for now, so each of the three > causes currently takes the host down rather than the domain. That is no > worse than before this patch, where the same causes fell through to > do_unexpected_trap() and die(). Implementing the helpers is left to > later patches. > > Signed-off-by: Oleksii Kurochko > I think the commit message it not very clear as it conflates two different countable things (the 3 fault causes reported via scause vs. the pseudoinstruction condition, which is orthogonal and can accompany any of them), which makes "two situations decided" or "any of the three" hard to follow on first read. Here is a proposition with a split to distinguish fetch-fault and pseudoinstruction cases into explicit bullets with their outcome stated ("Decided here"), and added spec-mentioned conditions about the pseudoinstruction's existence conditions: ``` Add a handler for guest page faults and hook it into the trap path, providing the trap-side entry point which will later feed the MMIO dispatch. This will be used, for example, to trap accesses to APLIC registers so that a guest can initialize and drive an emulated interrupt controller. A G-stage (stage-2) fault has one of three causes, reported via scause: - Fetch fault: guest tried to execute from a guest-physical address that is unmapped or that G-stage marks non-executable. Never emulatable (nothing to emulate a fetch into). On real hardware this raises an instruction access fault, so Xen reflects the same fault back to the guest. Decided here. - Load fault / Store fault: left undecided by this patch, this is where MMIO emulation will hook in later. Any of these three faults can instead be reported via a pseudoinstruction in htinst, when both: (a) the fault occurred on an implicit access Xen made to walk a VS-stage page table, and (b) htval holds a nonzero value: the guest-physical address of that VS-stage PTE, not of the guest's original access. However, none of these paths consult the p2m first, and the future MMIO path won't either: RISC-V has no populate-on-demand, no paging, and no mem_access, so every guest mapping is established eagerly. A G-stage fault therefore never indicates a mapping Xen could lazily resolve to let the access complete. Both helpers this handler relies on, resolve_faulting_gpa() and trap_redirect(), are BUG_ON() placeholders for now, so all three causes currently take the host down instead of just the guest. This is no worse than before this patch, where these traps fell through to do_unexpected_trap() and die(). ``` -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Sep 07 15:57:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 15:57:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410961.1641763 (Exim 4.92) (envelope-from ) id 1x3bio-0007Ar-QX; Mon, 07 Sep 2026 15:57:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410961.1641763; Mon, 07 Sep 2026 15:57:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3bio-0007Ak-NJ; Mon, 07 Sep 2026 15:57:26 +0000 Received: by outflank-mailman (input) for mailman id 1410961; Mon, 07 Sep 2026 15:57:25 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3bin-0007A2-AU for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:57:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3bil-00111U-LJ for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 17:57:23 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9edee3-e002-0a2a0a5209dd-0a2a450bcb8c-2 for ; Mon, 07 Sep 2026 17:57:23 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9edee3-b7e8-0a2a450b0019-b9ff1c229b35-3 for ; Mon, 07 Sep 2026 17:57:23 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a07c9682ec000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 07 Sep 2026 15:57:13 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 1CDF38409A; Mon, 7 Sep 2026 17:57:13 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=jnc1o8azbpt3q96zAmQUDwrEJuwl/41nwrNJgIomgtY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=LXF2Q/aIMtL0zgWPGQKGWueSqqXaxSvg4RF5c6pQUUFmgDleP30CqkKic6i9WrJKScJqMZ917 olqhOmXhosCArJDLsiPO+/8NIM0VCMucSkeJqyrFXq473H6XYOoztUqPoT7mzq2hfYytKICbMVf GHUL5iOl6KghTofX9bWznm4afuGaAqzkJzJdsyJFHCUvBtdfAQeAwBa4MPtKkdgunnt2dWqMzaz VHy1f39U4cHwVpSSlA4/nq890z+7DyMjQWqUqUhDVQMlvX0Z0Cw+uEyCOGj1UPMrL4jl7qIJ26v 5MGFnz+ps/w1qjzdGyQAPHgbjnSFrXAIOIF5mzuCgMZA== X-Zone-Loop: 158a99d76f427bac4fe71ec7be609830f36d3ce5fa93 x-campaign-type: default x-transaction-id: 3b072c70-7ea9-4156-97c3-4bbda24585f2 x-swg-uid: 01-6e402b2a-168e-43e8-9b26-b485346a102c X-Mailer: Sweego Message-ID: <1788796633.8631fc262581453bbf619ec5b2062170.1a07c9682ec000c4f3@vates.tech> x-swg-bid: 1788796633.8631fc262581453bbf619ec5b2062170.1a07c9682ec000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 17/39] xen/riscv: decouple INSN_PSEUDO_VS_* from the hypervisor's XLEN From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <2a69992aa02ff114237ec27204cfac0f8278b1d6.1787838835.git.oleksii.kurochko@gmail.com> References: <2a69992aa02ff114237ec27204cfac0f8278b1d6.1787838835.git.oleksii.kurochko@gmail.com> Date: Mon, 07 Sep 2026 17:57:03 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788796632; l=3288; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=CGTaarprigZS1mCShM6ahN0K5tFhfdXGr5CIh2d29RI=; b=7P7q+KpzeJGIX0WAf2mB1Ox4W7tUR0M9VXBd/egkHtTu+4Glf2pr9sAAJNo3tpTAuPs/54NfT PHo8M9DL76KDJuvbt416jBSVAt3za27k2r60l64cmSInHXCJtG+Ko4S X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788796633311 X-purgate-ID: tlsNG-42698a/1788796643-19AC09EA-B2F9F05D/10/73395122804 X-purgate-type: spam X-purgate-size: 3288 > htinst reports a pseudoinstruction when a guest page fault is taken on an > implicit memory access done for VS-stage address translation. Four such > values are defined, differing in the access type (read or write) and in the > access width: 4 bytes (0x2000/0x2020) or 8 bytes (0x3000/0x3020). > > That width is the width of a VS-stage PTE, i.e. it follows the guest's > paging mode (4 bytes for Sv32, 8 bytes for Sv39 and wider) and has nothing > to do with the XLEN Xen itself is built for. Selecting just one pair with > where a guest running with VSXL=32 and Sv32 in vsatp produces the 4-byte Sentence is broken. Guess you mean "Selecting just one pair based on Xen's XLEN misses the case where …". > forms. Such an htinst would not be recognized as a pseudoinstruction and the > fault would be mistaken for an ordinary MMIO trap: Xen would fetch and > decode whatever instruction sepc happens to point at (unrelated to the > access which faulted) and emulate it against a guest physical address > derived from htval, which for an implicit access holds the address of a > VS-stage PTE rather than of any access the guest performed. > > Define all four values unconditionally instead, named after the access width > they encode rather than after the build's XLEN. On RV32 the 8-byte forms > simply never occur, so recognizing them costs nothing. > > Dropping the ladder loses no build-time coverage: a build for an XLEN other > than 32 or 64 already fails on the equivalent ladders in asm/asm.h and > asm/config.h, so no replacement #error is needed here. Adding one keyed on > CONFIG_RISCV_* would in any case re-introduce exactly the conflation this > patch removes. > > This diverges from the imported version of riscv_encoding.h. > > No functional change: the values have no user yet. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h > index c63e5e3046..2d2e7e11b3 100644 > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -839,25 +839,17 @@ > #define INSN_MASK_FENCE_TSO 0xffffffff > #define INSN_MATCH_FENCE_TSO 0x8330000f > > -#if __riscv_xlen == 64 > - > /* 64-bit read for VS-stage address translation (RV64) */ > -#define INSN_PSEUDO_VS_LOAD 0x00003000 > +#define INSN_PSEUDO_VS_LOAD64 0x00003000 > > /* 64-bit write for VS-stage address translation (RV64) */ > -#define INSN_PSEUDO_VS_STORE 0x00003020 > - > -#elif __riscv_xlen == 32 > +#define INSN_PSEUDO_VS_STORE64 0x00003020 > > /* 32-bit read for VS-stage address translation (RV32) */ > -#define INSN_PSEUDO_VS_LOAD 0x00002000 > +#define INSN_PSEUDO_VS_LOAD32 0x00002000 > > /* 32-bit write for VS-stage address translation (RV32) */ > -#define INSN_PSEUDO_VS_STORE 0x00002020 > - Whole point of patch is these no longer depend on build XLEN, yet comments still say "(RV64)"/"(RV32)" which could be confusing. Maybe it should be better to indicate, as the spec does, that RV32 values are used when VSXLEN=32 (only sv32 paging mode) and RV64 values when VSXLEN=64 (sv39+ paging modes). -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Sep 07 15:57:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 15:57:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410963.1641781 (Exim 4.92) (envelope-from ) id 1x3bit-0007dV-ER; Mon, 07 Sep 2026 15:57:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410963.1641781; Mon, 07 Sep 2026 15:57:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3bit-0007dK-BW; Mon, 07 Sep 2026 15:57:31 +0000 Received: by outflank-mailman (input) for mailman id 1410963; Mon, 07 Sep 2026 15:57:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3bis-0007cj-OE for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:57:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3bis-001pMF-4s for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 17:57:30 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ededc-2eae-0a2a0a5409dd-0a2a45078e0a-18 for ; Mon, 07 Sep 2026 17:57:30 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9edee9-b4ea-0a2a45070019-b9ff1c239fa7-3 for ; Mon, 07 Sep 2026 17:57:29 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a07c96862b000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 07 Sep 2026 15:57:14 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id F3C4E81DF0; Mon, 7 Sep 2026 17:57:13 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=EWlbJfshw55uOAtF/lqi8vCOopbWc+B9Iv25xVsQaY0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=o7lh3/cukCYaiA4wxliVN0p1yXiJYg2LCe7OgcVSF5fyG6Iuxl/cqxyKpupVx69eKegH9VNxx wf3c3NcOB2kb2YXye5WVF5p0DasVqT7cK4HXbPzfd9+vepyph+Ej2me2CZCqqvdBLto4Cusvcgl V/CVF+gvkWGFxqzeXtMlDjxHK2QMf82hqcU5HuLkye1JnGRhBucZMXN7mb/ufAXWi/Ut5SilzyC nwwHtu5y957IBDtW7YWVugOOzZes5ZZgcYah7yzT0mz4g1W+hQTjJh0FhnuxpsJjqkJVnLzYf+7 wApbZGx1WvN8wafaLDZ0WmPtkObqilMZ/ovJQt96a2PA== X-Zone-Loop: 38dfda20ee6743df597ca2b3ba95d0217b8d82321e48 x-campaign-type: default x-transaction-id: f860a4da-45dd-4b5f-a178-e88cdd492f28 x-swg-uid: 01-cdd55ba7-6d08-45c6-9f53-001683d25b1f X-Mailer: Sweego Message-ID: <1788796634.8631fc262581453bbf619ec5b2062170.1a07c96862b000c4f3@vates.tech> x-swg-bid: 1788796634.8631fc262581453bbf619ec5b2062170.1a07c96862b000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> Date: Mon, 07 Sep 2026 17:57:03 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788796632; l=3605; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=7bOpoYd/1VwkJ+AJmm/i+QnhYspYB5cPzUp5yLYwH18=; b=Sop5BUipDbpPp7eL3rtauUTaWRDiG4Jkhyg0oG23EKxS2VBKxX1f76pgZ1T47JmNlPVmWk/5d iuqal0cKQw0CW5OaLvEQcAcRNTkaWiKHSGccwuKDe1ufx1TndOXRiFX X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788796634260 X-purgate-ID: tlsNG-ef75cf/1788796649-3C817AE4-504CC69C/10/73395122804 X-purgate-type: spam X-purgate-size: 3605 > Some traps taken by Xen on behalf of a guest can't or shouldn't be handled > by the hypervisor and have to be reflected to the guest's own S-mode trap > handler instead: the access faults which handle_guest_page_fault() injects > for a fault that can never become an emulated access, and, later on, a > fault taken by the hlv/hlvx sequences of riscv_read_guest() while > accessing guest memory on a vCPU's behalf. > Access faults from handle_guest_page_fault() aren't "taken by Xen on behalf of a guest" as those are guest-page faults taken directly from the guest's own execution. Xen just decides they can't be emulated and reflects them back as access faults. Only the hlv/hlvx case is Xen trapping on the guest's behalf (Xen itself executes the faulting access). Conflating the two under one description makes the paragraph confusing. Suggest splitting into two: Two kinds of traps can't or shouldn't be handled by the hypervisor and have to be reflected to the guest's own S-mode trap handler instead: - Traps Xen takes on the guest's behalf: the hlv/hlvx sequences riscv_read_guest() uses to access guest memory. - Access faults handle_guest_page_fault() injects for a guest-page fault that can never become an emulated access. > > Implement trap_redirect(), until now a BUG_ON() placeholder, for that > purpose. It makes the trap appear to the guest as if it had been taken > directly in VS-mode: the trap information is transferred to the guest's > virtual supervisor CSRs and the vCPU is resumed at its exception vector in > supervisor mode, following the trap entry rules of the RISC-V privileged > specification. > > Add the STVEC_* definitions needed to tell the BASE and MODE fields of > vstvec apart. > > The implementation is based on kvm_riscv_vcpu_trap_redirect() from Linux, > with a few deviations: > - The function reads and writes physical VS-mode CSRs, so it is only > meaningful for the currently running vCPU. Instead of taking a > struct vcpu argument, it always operates on current. > - The MODE field of vstvec is masked off explicitly when computing the > exception target PC (exceptions always vector to BASE), rather than > relying on the hardwired zero bit of sepc to drop it on VM entry. > - Assertions document the preconditions: the trap must have been taken > from virtualized mode (hstatus.SPV set), and only synchronous > exceptions may be redirected - interrupts must be injected via hvip > instead, so that the hardware performs VS-mode trap entry itself, > respecting vsstatus.SIE and vectored vstvec dispatch. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h > index 2d2e7e11b3..b2071f4758 100644 > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -109,6 +109,12 @@ > #define SIP_SSIP MIP_SSIP > #define SIP_STIP MIP_STIP > > +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ > +#define STVEC_MODE_MASK _UL(0x3) > +#define STVEC_MODE_DIRECT _UL(0x0) > +#define STVEC_MODE_VECTORED _UL(0x1) > +#define STVEC_BASE_MASK (~STVEC_MODE_MASK) Nit: STVEC_MODE_DIRECT and STVEC_MODE_VECTORED aren't used anywhere in this patch (only STVEC_BASE_MASK is). Either use them where you decide exceptions always target BASE regardless of MODE, or drop them until a patch that needs them. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Sep 07 15:57:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 15:57:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410964.1641791 (Exim 4.92) (envelope-from ) id 1x3biw-0007ti-Kz; Mon, 07 Sep 2026 15:57:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410964.1641791; Mon, 07 Sep 2026 15:57:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3biw-0007tU-I5; Mon, 07 Sep 2026 15:57:34 +0000 Received: by outflank-mailman (input) for mailman id 1410964; Mon, 07 Sep 2026 15:57:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3biw-0007sr-2P for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 15:57:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3biv-00111U-Ez for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 17:57:33 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9edecd-e002-0a2a0a5209dd-0a2a4501baf8-38 for ; Mon, 07 Sep 2026 17:57:33 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9edeed-5984-0a2a45010019-b9ff1c12b079-3 for ; Mon, 07 Sep 2026 17:57:33 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a07c968805000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 07 Sep 2026 15:57:15 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 5CA748409A; Mon, 7 Sep 2026 17:57:14 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=KB1DiIJHEfPZZ3TklRboiaJUI7RetTEAxcTDNjbMqeA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=PAF69VG72VXt/UeeRtOnYCNBLsmeBqlnaD3ELV6ah2OChuTytVobsAAB9dyVi9dEeLQKXaCPa oy2/fWopSmkhMPyjJxB6AGbCKmdnIsCk2zxnhkH9gA16NP0yPMIJbBOf/zIIZDidj0CQ8mGM/oc 9Sr68JhOlOA1wAsw8dOWWesqXQiRcwJkGKHg50EbMUfcwKY4T5NZKQs6fNBlgS94CEwg4NhhXBz 3cBGx6a+jXTQc3VXlP2L3cNMLf/Odde9l6qlQ8KvrtGV3q+9Th9OkX7H5tDu0/XI9iO1RXTQLlZ mGb0PzdWuaegfRJ5cU/jFyECafYeZBysOVrPETLf7pFg== X-Zone-Loop: e0829702275528cdb2ba722dfab25c33be22796b0754 x-campaign-type: default x-transaction-id: 1e1f7348-aa93-4c5b-b287-64261dfd2c80 x-swg-uid: 01-d0e34013-47c0-41a2-80df-e23633dd0a7c X-Mailer: Sweego Message-ID: <1788796635.8631fc262581453bbf619ec5b2062170.1a07c968805000c4f3@vates.tech> x-swg-bid: 1788796635.8631fc262581453bbf619ec5b2062170.1a07c968805000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 20/39] xen/riscv: detect Shtvala From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <611683b3d2e3b836d08d0499f7caff782ba80a34.1787838835.git.oleksii.kurochko@gmail.com> References: <611683b3d2e3b836d08d0499f7caff782ba80a34.1787838835.git.oleksii.kurochko@gmail.com> Date: Mon, 07 Sep 2026 17:57:03 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788796632; l=1604; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=mN+LNRvmlstaOovVuKX9opPQimAGNpumM0+HcJfuTEc=; b=4PonStdCMsN1CBP6LcAhd9pkF3eS4plPyPdqKutst7YrriydHL4ilmTzrMr+oMbhNQU+4y5ih U0Ot7TrGFZiCgUn98IDZMT/GMlFYx5QDyv4Bu7M5jTNYPclHmdXDzsz X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788796634700 X-purgate-ID: tlsNG-d62444/1788796653-BC558757-E39E5FAB/10/73395122804 X-purgate-type: spam X-purgate-size: 1604 > Shtvala says that htval is written with the faulting guest physical address > on a guest-page fault. The H extension itself allows an implementation to > write htval with either that address or with zero, so where the extension is > absent a zero htval cannot be told apart from a genuine fault on guest > physical address 0-3. > > It is not offered to guests. Shtvala describes the HS-mode trap interface, > which a VS-mode guest never sees, and the H extension it belongs to is > already withheld from guests. Its guest-facing counterpart is a separate > extension, Shvstvala. > > Signed-off-by: Oleksii Kurochko > I thought this commit message is not very clear. Here is a more direct suggestion: ``` The H extension allows htval, on a guest-page fault, to be written with either the faulting guest physical address or zero. Shtvala extension removes the ambiguity of this zero-write by guaranteeing that htval is written with the faulting guest physical address in every circumstance permitted by the ISA. Not offered to guests: Shtvala describes htval, an HS-mode-only trap register a VS-mode guest never touches and the H extension it belongs to is already hidden from guests. The guest-visible equivalent is a separate extension, Shvstvala, covering vstval instead. ``` Btw, I saw Linux has Documentation/devicetree/bindings/riscv/extensions.yaml which describes all of the extensions supported, don't you think it would be useful to have the same in docs/misc/devicetree/...? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Mon Sep 07 16:06:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 16:06:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1410995.1641799 (Exim 4.92) (envelope-from ) id 1x3brx-0003ND-Dy; Mon, 07 Sep 2026 16:06:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1410995.1641799; Mon, 07 Sep 2026 16:06:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3brx-0003N6-BO; Mon, 07 Sep 2026 16:06:53 +0000 Received: by outflank-mailman (input) for mailman id 1410995; Mon, 07 Sep 2026 16:06:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3brw-0003N0-8D for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 16:06:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3brv-00EMuy-L3 for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 18:06:51 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ee106-2eae-0a2a0a5409dd-0a2a4502849e-18 for ; Mon, 07 Sep 2026 18:06:51 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ee11b-6ca4-0a2a45020019-d155dd2db4e0-3 for ; Mon, 07 Sep 2026 18:06:51 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-48436251906so4250344f8f.0 for ; Mon, 07 Sep 2026 09:06:51 -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-49cfbe5b252sm276392875e9.3.2026.09.07.09.06.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 09:06:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788797211; x=1789402011; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=CLFr3OlASOjwaBAVPfUk7hR+IE8iW3XD8/uzk2PZJjI=; b=E2A5jq/KwWEMkdh1tCWcdSMiJTuyPURZs+Bn6+oXwkVNa+TYno6O4JFakI+5asdNWJ 71y9Il5TGbViAZhugMLam34dhQP5h7UX0J3tWkT12r8FbRywyuJVvswpgWfzpi95Fx0w wM26noyNoTOpTkFsGKskvuPnR0h0vcAwPrCUyZBharYl5LGBfb78k2byi/f7ZjGTm5eJ oYNEphJ73YLY9GL+vixVmekI37bJK2PFYVX4BF3UrRigaXGxWAIL4lL8ofb1XtZdTgea M/ABO7nGbWSlB1hG9WK302H/f0Wg0e5jlUWnxxSylytKKg/dSf/VgL/pKOV1SgOeEN5a OnPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788797211; x=1789402011; h=content-transfer-encoding:content-type: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:content-type; bh=CLFr3OlASOjwaBAVPfUk7hR+IE8iW3XD8/uzk2PZJjI=; b=PyaAa+7zJkbhVtuq/y4nCoL+6+OHyL8042n/2u9IFJqiSzqXzTbEHoauwSfbtO8DbF Fc8YRBIX6gdV5KnJrhRDUL68qoaB+xPoV7g2Ro4cATymXgcrDIDMJJysS9NmdsWu+4pM F3ldQsv7rQV8J0MNx5SJgmD8Zk/r+qIu3FislVJntFquhvMfy4Q/M86IzJh7YfYeC9EP m+FvynOAIEe3HixcAdhiV6Zd3pg7WDnIKWa53v0WsxKKK4otPxFKNaS1yPLjWUX3Hu43 8GXnUgRwjjRpDrapuF1yoKccU4gwN75l25xlXdRDZLJTmL63XxXGE/grVUeLrZJBiC+w dBAA== X-Forwarded-Encrypted: i=1; AKwUvBzXIkOmRAFpRytm8Zkz+LmovV3YCR5OZ8pSKW63VGcrp/LwVi2MpJPa1w2E8x9iSQ9dhZVTnGZ8B/Q=@lists.xenproject.org X-Gm-Message-State: AFuF++nO8XAweh/Iz5cGaTnPiE8MNUnLY8/twtbehfvC7qm9SYFq9uV1 T1TzKKZfyClPwMZHKWS4FEiu57c6KeJAkFANExtwOQrMJOhGmGfodYqLdWON+n24GQ== X-Gm-Gg: AYBFou2drGbvli1IfqgdU7BjMTciMjR6DxHgaOaGrvJ1KoY3E4CvMferD1bvG9xrkgJ F1644W7OEgIDPf4Q5DQvZI95U2ezasVXOIF+liq646Vmov8Uvtfzn/EYw8pGC6hsoiAeRzwp35G sKqaxDgLKHcdvsRwFppewsvnKWZh1p62TMjMMNc08uS55D9Qs9hMr935yw02gnTcVO0SnZqrJcm B7GKHiKkJJ9il+5dopwPAzYe5wU5b52ofAgj8jy4//O/LMkFPYO4d3ePgsJ+ZZWPHWNjc0WjJA1 4+iecKEhIGA4u2DZIRWE3oLqmmPMMi1ALWQyIqKHCn5yC1QMO3+N622EUelKE7yIRH/43BqObhn +FaVPfW629Gfyg9k0k12bAHLc3kunY2qKwdEXUwOgE+SLK/9JB7M6g5w9Wb0ddrjyrw24euHStC pvNuZn/kau8qtZHBOoabVTshGeHsGVcapRvloO349fgcbTSSWPeg84COh82DYzBVHKbNAY0mSFN 4l/MCsPG4XSg1dn1vxKx9ByXekcbZdEESgrhWaAM39PetxbdoXjqjMbBiJNteVA X-Received: by 2002:a05:600c:3485:b0:49c:cee0:e7c1 with SMTP id 5b1f17b1804b1-49cf825c119mr518591815e9.16.1788797210898; Mon, 07 Sep 2026 09:06:50 -0700 (PDT) Message-ID: <99a68a9d-79f0-4090-b0ed-3afdddb57fd6@suse.com> Date: Mon, 7 Sep 2026 18:06:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 05/14] x86/pv: update guest LDT mappings using {populate,destroy}_perdomain_mapping() To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-5-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-5-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788797211-F28B42AC-73030BB8/0/0 X-purgate-type: clean X-purgate-size: 3148 On 02.09.2026 11:43, George Dunlap wrote: > From: Roger Pau Monné > > Until two patches ago, update_xen_slot_in_full_gdt() used the stashed With wording at the start here and ... > pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vCPU's page > tables with Xen's GDT; this was previously necessary because > map_domain_page() couldn't be called in a context switch. Having a > handy pointer to an always-mapped version of the GDT/LDT L1 table, > other sites which modify the table started using it for convenience, > even if they weren't called from within a context switch. These > include pv_map_ldt_shadow_page() and pv_destroy_ldt(). > > Continue the process of switching users of the stashed reference to use > populate_perdomain_mapping() instead. > > pv_map_ldt_shadow_page() is, by definition, always modifying the > currently-running vCPU: it runs from the #PF handler for a descriptor > fetch on the guest's behalf, and running the guest implies its page > tables are loaded. So it could simply write the linear recursive > mappings directly. Go through populate_perdomain_mapping() anyway, to > keep a single writer for the per-domain area. > > For pv_destroy_ldt(), use destroy_perdomain_mapping(). > > Previously, pv_destroy_ldt() used the L1 LDT entries themselves to > determine which MFNs to drop type and count references to. Rather > than reading from the stashed L1, keep the MFNs corresponding to L1 > slots in an array in the vCPU structure, as we do in the GDT case. > (Note that unlike the GDT case, these are not part of a public ABI, so > can be mfn_t, avoiding a recast-and-copy.) > > Note that mappings_dropped (the return value of pv_destroy_ldt()) now > reflects the *number of valid MFNs in this array*, not *the number of > non-empty L1 entries*. This introduces an invariant we must maintain: > pv_map_ldt_shadow_page() writes both the array entry and the mapping, > and pv_destroy_ldt() clears both, so the two stay in lockstep. > > Also note that, unlike pv_destroy_gdt() from the previous patch, ... here adjusted as per the comment on the earlier patch, ... > pv_destroy_ldt() doesn't fill in the values with zero_l1e (see > 61031e64d3), so there's no change here. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 > Signed-off-by: George Dunlap Reviewed-by: Jan Beulich On the basis that ... > --- a/xen/arch/x86/include/asm/domain.h > +++ b/xen/arch/x86/include/asm/domain.h > @@ -541,6 +541,8 @@ struct pv_vcpu > struct trap_info *trap_ctxt; > > unsigned long gdt_frames[FIRST_RESERVED_GDT_PAGE]; > + /* Max LDT entries is 8192, so 8192 * 8 = 64KiB (16 pages). */ > + mfn_t ldt_frames[16]; > unsigned long ldt_base; > unsigned int gdt_ents, ldt_ents; ... this not really insignificant size increase is okay-ish as long as struct hvm_vcpu is about three times the size (i.e. is still more than double the size after this change). Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 07 21:07:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 21:07:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411049.1641810 (Exim 4.92) (envelope-from ) id 1x3gYS-0006UT-Jd; Mon, 07 Sep 2026 21:07:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411049.1641810; Mon, 07 Sep 2026 21:07:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3gYS-0006UI-Ee; Mon, 07 Sep 2026 21:07:04 +0000 Received: by outflank-mailman (input) for mailman id 1411049; Mon, 07 Sep 2026 21:07:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3gYQ-0006Ts-Kp for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 21:07:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3gYP-00Au1y-Ts for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 23:07:01 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9f2773-e002-0a2a0a5209dd-0a2a450cbf14-2 for ; Mon, 07 Sep 2026 23:06:59 +0200 Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9f2772-f479-0a2a450c0019-cddca5201304-3 for ; Mon, 07 Sep 2026 23:06:59 +0200 Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 687DKLEl1981575; Mon, 7 Sep 2026 21:06:40 GMT Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4ggbd3tanp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 07 Sep 2026 21:06:39 +0000 (GMT) Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.7/8.18.1.7) with ESMTP id 687L5Sp9009266; Mon, 7 Sep 2026 21:06:38 GMT Received: from sn4pr2101cu001.outbound.protection.outlook.com (mail-southcentralusazon11012005.outbound.protection.outlook.com [40.93.195.5]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 4gh753nqhs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 07 Sep 2026 21:06:38 +0000 (GMT) Received: from CO1PR10MB5506.namprd10.prod.outlook.com (2603:10b6:303:161::7) by IA1PR10MB7309.namprd10.prod.outlook.com (2603:10b6:208:3fe::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.6; Mon, 7 Sep 2026 21:06:34 +0000 Received: from CO1PR10MB5506.namprd10.prod.outlook.com ([fe80::da72:a0a9:5f18:cda4]) by CO1PR10MB5506.namprd10.prod.outlook.com ([fe80::da72:a0a9:5f18:cda4%6]) with mapi id 15.21.0382.007; Mon, 7 Sep 2026 21:06:34 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-oracle-onmicrosoft-com header.d=oracle.onmicrosoft.com header.i="@oracle.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2025-04-25; bh=AqmjaxDO2DAKhVCifJPQSLqdgXkmYjqs6jRh6BnFATU=; b= caHkL8QlUKhZujtY4BO+uqz63mz030uAJFTwYlUhkYF6cq+sXDFQaYn3oKuDWP+b 1sU+/LGrlMxs+SVyYzcWmJs8KvxKyriurY9dXlN6c3/I0OYWtRqC4/QhR/K0tEYE kXkfX/o4dOjy8MwGKc5cAIP6vChUGzrGvtZsZzomhuJOZUe8qUxwlf4FliMyQ5K3 hOgSoCiCMKJLdTvPsicnuz+BTkaFuO2js15FUOAodcmHKGjFUdRIGwJMpvuWpZx2 /opj6St2kDfr6s86FVSO4DaDGLav444IOaxWbQa1/DKKGFjmT7pLEvb6MSeVmAiG RBeK54lGucnpW+dKboYXUg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tDiWkKBYLhymkc3gYj5VgdJ7/3GAdjQzNE0swWgTWh2yHwFsBhA/7p9e/3vNYz3DtPQlhFOmi03Cfwu/UddwB+0ahlbGulCJYg2Au0FsLHCOXQJt/fZC9UA1uqWk1EQ+pV2F3MozuNUjAfuGj6hPB5vOm6pWzBcoHNRvdqC465bTU9cx9zLHLPObkyOFaOKtjYqhXNYSBOkJ06zpbrt6Gty7ZB8TgdWdkKUWbUSeJa6jU6mJls2KFpmPk/jT/fGfveTaN/DO7QnjL1UqiRjVkAo7Mk7HVFzemDS42xHjmeg7B5uXw5TqxMxKFTX05S0sd1x7ZPL/YstS5/g9odS0BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AqmjaxDO2DAKhVCifJPQSLqdgXkmYjqs6jRh6BnFATU=; b=nxHVpxT1Xwv6QUnTb9WCG6/qeccM3Z/P1pgA12xdqHo7HRu1by5MRsXD5xFqKQeG5PmE0gaJHPRVr8T7GChwFXXbAe2tw1lWLyrw48RsHECIZ+Rr3L3GGgyzIaog20Bm8thIES7CizRAQa/CMB+OeZ2RvRgAT+iDHUXD1CgsAiWWqgYgsx5QNc0VGIfrGu8pFxAxwZyXhhf6OYe7REXgQXUrS0Yijnz8L2KLUIxQmQia7dAX1/EDKkCxiMX8Blg0Z5CAOi6ubOchlCYI3siNx/QZAlx9ExKu/PMCE+3fc3ocPR0KG7c3ZyAl3a3hS2pbNgPnhoViDG6URqJJzCykJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AqmjaxDO2DAKhVCifJPQSLqdgXkmYjqs6jRh6BnFATU=; b=XB1nI16FNhKGaI0Thw9GeGSMpSoNRaeZGqByMTOQanCG9y+R5/g7S4Dassw9F019XOEGDlW82GyniN19ae8Pls8ARAKt8rxV09Bg+F1WM1ObHY58JV0oZLdnBvJVdX+IQ6e0EL5QXTpuck8jbYiBFqYWWxi0tgFbCaHSXT7QXBw= Message-ID: <296a04a7-f917-4abd-b564-4a6b8fc6aace@oracle.com> Date: Mon, 7 Sep 2026 14:06:29 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug To: "Michael S. Tsirkin" Cc: Igor Mammedov , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> <6154b857-16b3-476b-a2cb-8837464dd4cb@oracle.com> <20260907044608-mutt-send-email-mst@kernel.org> Content-Language: en-US From: Dongli Zhang In-Reply-To: <20260907044608-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: CH0PR03CA0383.namprd03.prod.outlook.com (2603:10b6:610:119::18) To CO1PR10MB5506.namprd10.prod.outlook.com (2603:10b6:303:161::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR10MB5506:EE_|IA1PR10MB7309:EE_ X-MS-Office365-Filtering-Correlation-Id: 6936be15-463b-4771-cd33-08df0d23e5f9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|6133799003|10067099003|18002099003|4143699003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: we0aapbxGdSsA2BqMVmpSMp1XGXzIuABomJv9arPV3oLT9z3pY1W8Ht3nJdiln4zR2LPOp34vlRDnoRGdmyb7SD2G9LjKgZOi6F/iMG4R0EYeNpakDi3I8PA6NeOxJ8nG6Wl62xT/5BlEXbjJoXclBuIs2Pcf5eTphKDrutX8+ukiA3jNw/5+9/eSvrn1xFaW7kCtNVwMNQjXfcQLurKwN908iS1zCsp99Bce7orG8NSew5qGp3fi5LpWuKLw1D00lwQpbV1veBn4eJeGg/3GiHwzo0ARRMxcW8DdOoqO5rSJX2s3C0Hjde8SC+aNrEqkMbi6IH/G73GCOlQOSskUqAZ97joXIsTYLfu7kLM1NphsUWZ9hmdCGEiaGx8toDWWDAWfum382Y0Z1yXeZm/+dBfuOR3p1uQK3q9f2+VJkcxyLdIr2QJz9wpjO9hEGlsEpxwa0bg8eDdoagCOi6kmVbRjGhRJ6ZuxwttrpQUSREOMsi/05+Hv8+VnTdCFUWN2THtw25nGZJTSnz2ovNNr2qBMbwWwrpsT6PNekzYyVPJykwctwEFOgQupno8weT/XnQaHpXGzSOL2Y53Cncpx4IHTwKRrplCB/hWnhvslxV1Wn05SfpK9hLsZQi08AhHPW7vaPqPVQFvTlVZS/nS5Zmwl5MgvInrOL2N1AQh4Do= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR10MB5506.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(6133799003)(10067099003)(18002099003)(4143699003)(56012099006)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OGF2Q3NOL0R6WEpFZHJMMjA4VXVKSDVoNEJYM2ViODJSZDNZTXdjVUJNdm40?= =?utf-8?B?b1BYTVNmNWJiNnc2VlNmUSs2c3AxbVZjWStoOVhsU1F0TjJYNGxxTTFkK3hQ?= =?utf-8?B?dlVJT3NDZmFEaUpxNnJqWWpOZlNGWm9zS3pTa1VXZ2x3OGo4a3ppSzVwZS9R?= =?utf-8?B?SW5xd3ZRUjd1ZWUxYSs5WVlnaVo3TEhIQ2VaeGRZcTVJYWtmTEtCMTNaeDUv?= =?utf-8?B?ZkNoQUpzZjEvbmpDQU9mVFRzQktCZTJHM3o5dnIxYWMrcU1kUDY5REVYNEs1?= =?utf-8?B?eExIdW1lTGVmY0xyazdZSjFjS1hGZUpoQmxxYkdKSlZLZ20rVTZCN0tCTFd5?= =?utf-8?B?SmRFb2VLM1lzcW5BdktVb1dqNXVvL2JzZzlWOU5yQlNzd1ozR3NmVVhObjc3?= =?utf-8?B?VTkrSGQvc0t0TVZPdm9OSnJGdkVUQllvN2x2aDRuUms5QzgyV21wejdqdGN5?= =?utf-8?B?WmxMVFcwem0zZXRJTTJnME9wdUJQbVAxb0JhUk41RGM1VXROb1hQZUdrNXZq?= =?utf-8?B?bGVKekJVQWZ4SVNMKzJYaWFFRUNGQTRkcHlZNWErMWxYV3F3WHZBNTUzVDI2?= =?utf-8?B?TWlhd0hnTGdmdXpHbXlweElhcUtFTmt5UlFpUlpCMy9KTVRzUkRSKzJ0ZFRX?= =?utf-8?B?VlowUGdMYlZPUkl5RExhVUxYSDNvdjl3dkcvS0Jydnp1QVIyNUszbnl6WUFO?= =?utf-8?B?c1dPNFlJMk1NUjFSU2wxYkNna0Q2Q0RwTzRlclF3dmk3eHRiYW5HMEdRRWlq?= =?utf-8?B?RWRQcWRMZElMaEE5UzlpM0oxTVB2RnpQdnNkNTJ0VzRRTTJaeFVHOCt0bWZo?= =?utf-8?B?NElHMXJFc0xCZ2xvQi9lMkMxMzlDNHA0azZxZjdmeVJud08wT2Fiekx1alV4?= =?utf-8?B?L25abUFjVUxQZjVTa1R3VFlhWXRBVFJjQnEvY0lEYzlieVVlZlJtUGJkeWEx?= =?utf-8?B?K1F6Q1BtbUFDanBUN0FiSkVjeGNnb2hyS0YyK0RJZTErOUZjbFkxUDd2OElZ?= =?utf-8?B?UjhXTTBoR3ppa3lzYWpSM2JNR0IwOThNRGZBWjB2Q2VOVEhhbkJpYVpZSi9B?= =?utf-8?B?MVZheEpaa21sTzZXdEg4dW5XdHFxU3hEWkU4Wlo4aTFlbkROZXZJQVZ6UlFB?= =?utf-8?B?enozMWNocWFYTW5mUnFFRGdHaGJCZm9lRmN4NEdRMzJZNCt6OC9GZHVwSTF4?= =?utf-8?B?QnFTckNXdW5FU2tVWlZCcEVTTENjcUhCa1JYU2FBajY1czVEcFZDdzJ1NVpM?= =?utf-8?B?QzFxeDZBODNTSnM2cE9kRUxkOGFUVUxRSTRGcmN6aldLa3VEUUZMVWVSSXY4?= =?utf-8?B?eTFLZUxGN1IxK3JWYzNqbTZlQyt5ZkJXRlZSOU5pZm9rZVJ2Qjc2NWFxaW1H?= =?utf-8?B?TUZTckFMZVJoQnFDcllzdTlnNmZLSXpwWEF6UC9TNUZVUkF3eUNtTXNBTi84?= =?utf-8?B?OCtldmluclgyeHMvbEhjS1owOThZTmRLMzJKZCt6NnBtaG5UN0hmdUQrT3Rm?= =?utf-8?B?WTVQeWxaWGxZZitPL3V0L213dElLOUpLVFRLclpqV0NBMFN1cGkzUi8rU1hV?= =?utf-8?B?bFlsTzNpOFhBQk9kYUliRUd0TmtqY2RhbDRmd0NsY1VYeGNCYW1JYTd2TjA2?= =?utf-8?B?ajRaOFpIb0tFWTdjM3pFTFk2MThRa3ZkbHA2WnVkZDBEcXhoRUVQVzZuYUZO?= =?utf-8?B?NEEvRGlocWU4Y0pnbExuUkVpeThPclNWM3hSeEpvbFQ3b2d3YmVWOUVZOFR1?= =?utf-8?B?WFN6OS9qMWxjY2lXWENHYjl6dmhldVhIa3J5MDRaTkdiVUdIaFc5QmhVL3cy?= =?utf-8?B?RDYrbzZVSEJHRUo5bW8xSy8zVEkyU3AyNWlMdkR5V3NyZHFwclkvaGZuMUM1?= =?utf-8?B?VkNpaEpvNmVxeVk3UWh1UElBazVpOXNYUElFbERtN3YzaVIvMmQ4aDFmV2t3?= =?utf-8?B?TVZiNm4vM2h4b2ZxcXlVMXMzYWZiMldhUTBnNDEyUXVJN0ZQc2RVQXZraTlo?= =?utf-8?B?UnowaUUzeGZYRlpEN2NjL0JEY2Y1QjRyNHg0bkFrN2ZoMmxZWVZUZk5FRlpq?= =?utf-8?B?OUtQRkRjaVN4Wm4wVll1Rmc4REcySWdvaFdIQnRjZEVXTjZ6dmVsMUpMVU93?= =?utf-8?B?RElranR2c1NmcEhrWTEzV0MzWWtjclRmN0FzcnVFSlBpVXYrclgydkE5cHVJ?= =?utf-8?B?UktzUUJCQ1pIbUFHZTJ2UC9ySGIxRUNvRmNVUW0yek0vRTVmZSs5aGpSRGRZ?= =?utf-8?B?KzJoLzZ4NWRyK0FLbTFhS2d5QnE1OEkvM2FuazMvdEtYS2FyRmJnSDJsUk1W?= =?utf-8?B?NHNSdG1nOFlTMEZ2T0gyQjBLa2lxeVpGY1M5ODdlb3dVdSt0R01KUT09?= X-Exchange-RoutingPolicyChecked: frAODmUJamSYFLDlgog3i7JWVjspfyAnMELa6UcZ9myh37UoPmcf9wrjnGXkeDYZsdN2XXbv/CIUswYFwGC9haHUqgRLvotzkkmBycs94JcZetwnPZV4xbvD+iL/zhrspEm8RKe57hi1S1Tjd0oNuuZfGDz7sGw6/SFGQtUVCyUDGjzTkGrM9g0JBI/EiSIQrlolBVTlCPy8IltuHBdFbjK90IKlAmXXzJl8xP12cfItEc0/RaJbH9JdPNXdfK/Gc2vqtfQ/GcPg8FxoQ5mB4Mdz2is0Ts4eXpllxFIA8WzrM4rgJsQ45uFZVd/UBO73JHZ/AYGMo0+6XXHHppaDvg== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: CguOmCVy7x1zTABQjWU9ZPmVdgblEUH7SmzwQzGWp9IH966cSvGrHwZPfHGnJLf/v629czoJYOOLhuVGYMCrivOeyGsnVNORWnV4oeOk9rYiIz1P/w6bL6eSBcKB14R7x3iRaILEKbFB1mye2Wl7ivmKYWuyx02oF6EzP87UnIVUufSpnOctXvd8+AdGkEoUTw8ggxdZd1kGZ7vG25uDrhoTEgJalkv1WEr5605HPCePIuxl8HahPpRAdyd2hYiOaGuwmw4WEbz6YHwEiVtL2hFlMseV7HqsN40AtLDM/VyJkbCdJZ5c6eU7Z972bUmUToyFPp9JfdpOs48emqj2e0NW/kB1tAmVAM0OYH+EWKTv+A4dfHvPOhUk0padYCoC+2Q0uBW4RlUWnXd0Tiye5Ngdi6/s0DXvhPHR7MCkdyoLfuXcn/0xY/ZXqPTe4OW7sZ0LKWK4uBgUabyfFGj8YYxLxhYfSkmEzIW7SQoOenLg8DTBxnc1MToVpM33zCYdqsdvqUDKhFLmIL1SjGiqv6qLiCM1vFzzOwKyY5CQcT36Fv8xrqqAli5JERoPHwEnL/3EeaYrYltCN6MrsJhIvqR5QVbJs/Sh73amygNyPTw= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6936be15-463b-4771-cd33-08df0d23e5f9 X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB5506.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2026 21:06:34.4333 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ki0vWwGa7IisJmwdwxFtczCikiPysoW7Cho2gAK1kg4eod3A9dOHyk5hrab7ItIbLCNTpmvLodPhUU4FSxT7Lg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB7309 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-07_06,2026-09-07_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 mlxscore=0 suspectscore=0 bulkscore=0 phishscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2606160000 definitions=main-2609070232 X-Authority-Analysis: v=2.4 cv=EuDiaycA c=1 sm=1 tr=0 ts=6a9f275f b=1 cx=c_pps a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22 a=EIcjfB9IiI4px24ztqRk:22 a=yPCof4ZbAAAA:8 a=BbSywiCuCK1ZzUgePn0A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=5yU3S35YU4bGjq-dph-N:22 a=Bho9c0fBagfJEIQBS7DQ:22 cc=ntf awl=host:12108 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA3MDIzMiBTYWx0ZWRfXxtDgp7iXrev0 Bp+dk5kCJJa9QY8R2u/IlEqSkHLsyqU95ZKDPKfqitdIV0K8u9LcwQbgFIT/TI3XyHZuVJvqLV2 o2+8h2+fz56K0WxSLye2fn3Xi56W1dzIgBTqcd1PXXsiG6np0xD+ X-Proofpoint-GUID: ODkSNkRfWVZJdKO88-9-rFmAYcg7BJxx X-Proofpoint-ORIG-GUID: ODkSNkRfWVZJdKO88-9-rFmAYcg7BJxx X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA3MDIzMiBTYWx0ZWRfX3WqEBjIybOIV Ls7eO2FzKaX/TZlj6zddIENWKcsdSkGVTp0Ns1k0opoeE8e3bao963nLuSFJUz3MgIpR0pf1t23 OCdGQrINsoJrsN8QlYu/pOFpDgOipH5lzBG9E2W5DBHG4TbXlNzWmgUmPeAM77NrDS1NIw9uZbr EVvYIIekBZPBoaiLJzEkE6QEsWuezjbhd9GaUExVZF3NAfUSmK6ZfsyOSpLjGjli5xSmu+emTY+ kUl+vLG+2CEOYfAwzaYV1IfFVrpywZxtn0Bga+/1hi0kGA8/tknen8zBrgkDvMHUVimwK6A7h7W J0K0e4fjptVQOmjR8yTzs3sJ2tAfg9mWs07GvHppwarQgeLQIiSopBZmVSu0Y1IDg4pqtqyoOHI 9dP1QWZiioFOFJ37lCyV5cGlt8nJLrllWOwjDD/051xVgKXJaKzpG07Kpu0ax6K9av/vcsxCXMm kEdlUV3HGxmnrdD6X9UmOGt9NR0JxBQcdCAksBR0= X-purgate-ID: tlsNG-d25034/1788815219-02ADCA5B-7F6A9C4B/0/0 X-purgate-type: clean X-purgate-size: 8490 On Mon, Sep 7, 2026 1:55:42AM -0700, Michael S. Tsirkin wrote: > On Mon, Sep 07, 2026 at 01:26:57AM -0700, Dongli Zhang wrote: >> >> >> On Thu, Sep 3, 2026 8:28:35AM -0700, Igor Mammedov wrote: >> > On Wed, 26 Aug 2026 09:15:47 -0700 >> > Dongli Zhang wrote: >> > >> >> On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrangé wrote: >> >> > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote: >> >> >> Hot-unplugging a PCI device can require cooperation from the guest. For >> >> >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest >> >> >> eventually writes the ACPI PCI eject register. For PCIe native hotplug, >> >> >> QEMU notifies the guest through the PCIe hotplug mechanism and waits for >> >> >> the slot unplug flow to complete. Only after that completion does QEMU >> >> >> unrealize the device and emit DEVICE_DELETED. >> >> >> >> >> >> This can leave a device stuck in the unplug pending state when the guest >> >> >> does not cooperate. Examples include: >> >> >> >> >> >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is >> >> >> unavailable. >> >> >> >> >> >> 2. The guest is stalled and cannot handle the hot-unplug event. For >> >> >> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this >> >> >> for ACPI-based hot-unplug. >> >> >> >> >> >> 3. The device was attached to a slot that the guest cannot use. For >> >> >> example, a pcie-root-port only supports slot 0. If a device is added to a >> >> >> non-zero slot below a pcie-root-port, the guest may never discover the >> >> >> device and therefore may never complete the unplug request. >> > >> > all of above is actually expected, no (functioning) driver => no hotplug/unplug. >> > it's the guest problem. Once device it exposed to guest its life-cycle >> > not longer owned by QEMU. >> > >> > That's what one would see in real hw as well, you press eject button >> > but it will not do anything if OS doesn't process it. >> > also see comment at the end. >> >> Users are generally more tolerant of issues with real hardware. >> >> In virtualization and cloud environments, PCI hotplug is more commonly used for >> NICs and storage devices. Users are less tolerant of disruption or unexpected >> failures. > > > Simply put, surprise removal exists in the hardware. Emulating that > makes sense, at a high level. Nor is it too hard. > However, guests, especially Linux, do not > handle it all that well generally. Exactly because users > would tend to impatiently reach for that tool, then > blame QEMU after a crash, we avoided emulating that. > > > I'd expect much more in the way of research into how guests behave, > perhaps some ways to limit it to devices that work well, and > likely some linux patches to make it work better, before we commit to > supporting such interfaces. Here is my summary of the current situation and plan: 1. Folks are not against adding an option to force-detach a PCI device. It should emulate surprise removal, which exists in real hardware. This requires adding the emulation to QEMU. 2. However, the more important issue is ensuring that surprise removal works well in guest operating systems, such as Linux and Windows, and for a defined subset of devices, including virtio devices, VFIO-assigned devices, Intel, Mellanox, and Broadcom NICs, and NVMe devices. >From QEMU’s perspective, it is preferable not to expose an interface that may cause a guest crash and lead users to blame QEMU for a guest-side limitation. 3. More research and development work is required to support surprise removal in both QEMU and guest operating systems, especially the Linux kernel. 4. So far, from QEMU's perspective, everyone suggest rebooting the guest VM for many of the use cases I mentioned 5. By instrumenting QEMU code and possibly adding additional metadata, we can track whether a PCI device has been accessed by the guest VM, especially during PCI hotplug. If the device has never been used by the guest VM, it may be safer to force-detach it. > > >> > >> >> >> >> >> >> The non-zero slot case has also been discussed in: >> >> >> >> >> [snip] >> >> >> > >> >> >> >> Thank you very much! >> >> >> >> I see that the issue has been fixed. The ticket mentions the following. >> >> >> >> "What I am observing is that it seems when the slot ID != 0, the guest OS seems >> >> to ignore this and we never seem to hit ich9_pm_device_unplug_cb()." >> >> >> >> Based on my experience and evaluation, ACPI-based hotplug is more likely to >> >> encounter an issue where the guest VM does not respond to an unplug operation. >> > >> > I'm not sure it's a good idea to delete device when guest still thinks it's there >> > (you can make guesses on QEMU side if it's in use, how useful those are is questionable). >> >> By instrumenting the QEMU functions related to device hotplug and PCI >> initialization, we may be able to make informed assumptions. > > So try. But just know that pci initialization is commonly done by firmware, not > the driver. Thank you very much for the confirmation. This also provides users with telemetry to narrow down the potential reasons why QEMU does not send the DEVICE_DELETED QMP event. > >> > >> > as far as I know, ACPI hotplug has no notion of surprise removal (pls educate me if it's not the case), >> > so I wouldn't do what you are proposing here at all, it's basically asking for disaster to happen. >> > And all this is basically for dealing with abused qemu flexibility. >> > >> > Please (re)formulate usecase and make it more clear as what is eludes me >> > no matter how many times i've read this cover letter. >> >> Here are some use cases in virtualization and cloud environments: >> >> 1. Suppose there is a QEMU user configuration error and a PCI device is attached >> to slot 1 of a pcie-root-port that uses ACPI-based hotplug. The device may not >> be detected or ejected. As a result, there is no way to detach it from the >> user's QEMU instance until the guest VM reboots. > > sounds vague. if users can not configure qemu what are the chances > they will use force detach responsibly? I should have clarified the difference between the QEMU user and the VM owner. The QEMU user is the software that manages VMs, such as libvirt or any other software that communicates with QEMU through QMP. The VM owner does not have access to QEMU. However, any mistake made by the QEMU user can affect the VM owner. For example, if the QEMU user mistakenly adds a PCI device to slot 1 of a pcie-root-port, the VM owner cannot detach the device from the QEMU instance until the guest reboots. In this case, the QEMU user is at fault, but the VM owner is affected. A force or surprise removal option helps the QEMU user recover from a configuration error without requiring action from the VM owner. > >> 2. For an unknown reason in the customer's guest kernel (Linux, Windows, or >> BSD), a PCI device may still be referenced by the guest kernel or its services. >> As a result, the guest never writes the eject register for ACPI-based hotplug, >> and QEMU cannot detach the device. The customer may blame QEMU for not removing >> it. A force-detach option could provide an escape hatch, with a warning that it >> may make the VM unstable or insecure. > > So just reboot the guest. I agree. Sometimes, the VM owner blames QEMU for not detaching a PCI device, even though QEMU is technically waiting for the guest VM to write to the EJ register :( > >> 3. Suppose a VM is stuck because of a guest kernel bug, such as a Linux kernel >> panic without a kdump kernel being triggered. The guest kernel is unresponsive. >> Force detach could allow the block device to be temporarily attached to another >> VM without resetting the currently panicked VM. > > So just reboot the guest. I agree. Sometimes, the VM owner blames QEMU for not detaching a PCI device, even though QEMU is technically waiting for the guest VM to write to the EJ register :( > >> 4. Provide a mechanism to demonstrate that force detach is unsafe. Otherwise, >> users may repeatedly attempt it and mistakenly conclude that QEMU is at fault :) > > We have that - we don't support unsafe detach. Thank you very much! Dongli Zhang From xen-devel-bounces@lists.xenproject.org Mon Sep 07 21:16:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 21:16:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411060.1641817 (Exim 4.92) (envelope-from ) id 1x3ghq-0000SL-EM; Mon, 07 Sep 2026 21:16:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411060.1641817; Mon, 07 Sep 2026 21:16:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3ghq-0000SE-BZ; Mon, 07 Sep 2026 21:16:46 +0000 Received: by outflank-mailman (input) for mailman id 1411060; Mon, 07 Sep 2026 21:16:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3ghp-0000S8-EB for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 21:16:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3gho-002O5G-RD for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 23:16:44 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9f2974-8faa-0a2a0a5109dd-0a2a4507df3c-32 for ; Mon, 07 Sep 2026 23:16:44 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9f29bb-b4ea-0a2a45070019-aa0a857c6979-3 for ; Mon, 07 Sep 2026 23:16:44 +0200 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-428-SeNEevirPw2xlOwOZvOJXw-1; Mon, 07 Sep 2026 17:16:41 -0400 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-485866e0066so2135272f8f.2 for ; Mon, 07 Sep 2026 14:16:41 -0700 (PDT) Received: from redhat.com (IGLD-80-230-79-236.inter.net.il. [80.230.79.236]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4858e239862sm26191451f8f.9.2026.09.07.14.16.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Sep 2026 14:16:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788815803; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mw8RFV/2HjpqWkwUwmTokzDl1/223/6QlsoHVWfboPU=; b=RMkbwb4dcu+vzvPC1g6A2PqKkPa4vUm9wHZr1aYcRu51gy/K/xLpNojESwlRNG9IZ3WwYK qQxDylMdIpsSeRI+bOlarBYJps9J4ArAAqu3bH31UDG97uANCeizbbNxmdmLWKnSStc2Id 3SELq7RHFxHN7fi2/yCuZl5+KR9FcJ0= X-MC-Unique: SeNEevirPw2xlOwOZvOJXw-1 X-Mimecast-MFC-AGG-ID: SeNEevirPw2xlOwOZvOJXw_1788815800 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788815800; x=1789420600; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mw8RFV/2HjpqWkwUwmTokzDl1/223/6QlsoHVWfboPU=; b=PzXi0M6xDWGIO96GJnA2jqxH/8uzXbgPMyWk2ITD856T9FQbQx5OSMyidp1rOb9WFU W6YGeeHipB/lRIdqRGkmTOhudFHuREIxrrkw1rigUJS9LVA98c8lhgO5W7pTDdjJrFGH Skts9wZ2+vGtysxBX/yiiM992RUVM6UeIBV4JeodvtXqi8HEK0FlFUt5ye7uNKhMkyr+ +FawJxUHr6KDSLMjN4gMVhn2Lb8c6KCAJq6odS6r98iMfY28Pd32i1uG9wpNuheqM2hb dccSBQ0c6PyMi0uvpWN1i5bK36pqZ8BKijc5XkXCYcxt1xLDUNCOmotG3m7neIw/uxnK VBOw== X-Forwarded-Encrypted: i=1; AKwUvBxk7S0N6/QMPlxc5XxBN3xnm9dnj0UmiXcK8GE+n1kJzHMkVrstv/UFG3D7+d0yJLX4MErnNKJeAF8=@lists.xenproject.org X-Gm-Message-State: AFuF++l08V22OJ2KgJQEokhqN1QY/yA5aocXeQBEpkcWOuQiYE7ElFna oHqy8owcuKAaxPZInNEhF4qrkRrK8PhKAf/zbh5APGxtRaAMKjXdIcC7vazwlY86+yydKRhfDkO 0d8LjlDP88Dmm1ZuH8uPg00MSuHneEp3a6c2+ZqIfyvDwx9QCBgh/DkiBI1YijfpKJR2J X-Gm-Gg: AYBFou0RFZRXOqGbxNX4esOaeA+KSXYgf00S5wmGXo0pI0Ljk3lpB/B0YNzssH3CpxI aGt/AmUopV1FG0wfPwxI948UI1czMH4MNsCMagBaqgm1k4nuDHUxtio0HDrHPQqypjxHK6bOin8 a/ExOZNtirvMQrX3/C26SEZhyj9VAltXCJ3Hnw3YWozzVLl2GowA9fCAAPH+0E7uJiyAc0loq7O mnL90iQY8MQKEw81qeIkaUvbzx/oi59B1IjJQKoY0ke4L9ADdtqoD5VqL/jf6Z+zM/Yz/qw3Qi3 VPTQWFf1kynfo7Ir/+ggySfP/DHDlKcvLmx+edKQ/Z/QrhUaevaDlBmof/i8F6dJwkIgqxdWjb1 pfdPTmTkI+d++3xXez+fsdkI= X-Received: by 2002:a05:6000:1a52:b0:481:51ce:542f with SMTP id ffacd0b85a97d-485872b40e3mr21034577f8f.21.1788815799871; Mon, 07 Sep 2026 14:16:39 -0700 (PDT) X-Received: by 2002:a05:6000:1a52:b0:481:51ce:542f with SMTP id ffacd0b85a97d-485872b40e3mr21034526f8f.21.1788815799406; Mon, 07 Sep 2026 14:16:39 -0700 (PDT) Date: Mon, 7 Sep 2026 17:16:34 -0400 From: "Michael S. Tsirkin" To: Dongli Zhang Cc: Igor Mammedov , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, dave@treblig.org, anisinha@redhat.com, philmd@mailo.com, aurelien@aurel32.net, mjrosato@linux.ibm.com, alifm@linux.ibm.com, farman@linux.ibm.com, richard.henderson@linaro.org, iii@linux.ibm.com, david@kernel.org, pasic@linux.ibm.com, borntraeger@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org, clg@redhat.com, akrowiak@linux.ibm.com, jjherne@linux.ibm.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, pbonzini@redhat.com, eblake@redhat.com, armbru@redhat.com, joe.jin@oracle.com Subject: Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug Message-ID: <20260907171522-mutt-send-email-mst@kernel.org> References: <20260824011420.752806-1-dongli.zhang@oracle.com> <01ee4841-76d8-4749-a80e-eb945ab8799a@oracle.com> <20260903172835.0e253a25@imammedo> <6154b857-16b3-476b-a2cb-8837464dd4cb@oracle.com> <20260907044608-mutt-send-email-mst@kernel.org> <296a04a7-f917-4abd-b564-4a6b8fc6aace@oracle.com> MIME-Version: 1.0 In-Reply-To: <296a04a7-f917-4abd-b564-4a6b8fc6aace@oracle.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 1taDTRGFZUBoRqBjgR28qygnpPPlk3O4GO5IeSGcEvI_1788815800 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-purgate-ID: tlsNG-ef75cf/1788815804-366DAAE4-8A5ED4D2/0/0 X-purgate-type: clean X-purgate-size: 428 On Mon, Sep 07, 2026 at 02:06:29PM -0700, Dongli Zhang wrote: > 5. By instrumenting QEMU code and possibly adding additional metadata, we can > track whether a PCI device has been accessed by the guest VM, especially during > PCI hotplug. If the device has never been used by the guest VM, it may be safer > to force-detach it. this last one I am not sure about. as I said, devices are commonly accessed by firmware. From xen-devel-bounces@lists.xenproject.org Mon Sep 07 21:32:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 07 Sep 2026 21:32:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411069.1641827 (Exim 4.92) (envelope-from ) id 1x3gx9-0003kg-LN; Mon, 07 Sep 2026 21:32:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411069.1641827; Mon, 07 Sep 2026 21:32:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3gx9-0003kZ-IW; Mon, 07 Sep 2026 21:32:35 +0000 Received: by outflank-mailman (input) for mailman id 1411069; Mon, 07 Sep 2026 21:32:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3gx8-0003kT-LJ for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 21:32:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3gx8-00GtOk-1N for xen-devel@lists.xenproject.org; Mon, 07 Sep 2026 23:32:34 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9f2d31-8faa-0a2a0a5109dd-0a2a4509d3be-34 for ; Mon, 07 Sep 2026 23:32:33 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9f2d71-be1a-0a2a45090019-d1558031a4c0-3 for ; Mon, 07 Sep 2026 23:32:33 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49b0eab380eso33433805e9.0 for ; Mon, 07 Sep 2026 14:32:33 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48588394fa1sm29801934f8f.8.2026.09.07.14.32.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Sep 2026 14:32:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788816753; x=1789421553; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1m3vZKFL0g/sGBvqTg0JocdJ+WVDcptllpplD2p/x7A=; b=au57hIewRAhS9+2F8iiBn1PIZC3i3lqhgfdHtP+5o1Jd4WkqdQf1uHM+cnMsNhZ5T2 kS7KOg0ZXu/ajgbJoP60uR1rQJFjP1j0IT4UVsWGfn4btqqAjqmUCAJ6J+e/WqJLotwv HLfC3HJNYlG9OoXmvmoRgq6dMqhXXwYkh3GAA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788816753; x=1789421553; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=1m3vZKFL0g/sGBvqTg0JocdJ+WVDcptllpplD2p/x7A=; b=Twb33zj3zyQJODSYrZv2RtogBPxcdUEgUeJXTxnxCsE4wDoERidNW3hCDnZfjPC6rV tq4i8jHGZDt15L+IazHl1uGa2OHLNXqNabzV20z1WZUSqhuRUQCKq3tdnlODrRO/op/6 XDa/e0vLSn1CyaS+L/ixt03jpgLkFKleqlRqgDxAvakk8kqAtaKgPwHjgcHKBGIkFTC9 REvCTsEbtCGC5qm7xsfexFcqJyLJWzHsr4kDNidcHTYRTLc5zYrPmRAnkUIkSBNOeuj5 QpiQNNLGUgnuuYnZv4/pxZMoZPO27m48CxbGQhFVkcDqoTCJta6kFBKqjmhlUi2c0Wh1 vQQA== X-Gm-Message-State: AFuF++n4EERaa3DsCbOC4Q4c883qcMGBOgEx3id9bi1pC6MBbgf3rXGe RD3V4KqO4d7Z277JOhHmXKDuxCSHysvi4gxbjKSP5VHzpln95L0Dq2o9W7fi3gpCMYzC8o/MZvt nY8DSs1E= X-Gm-Gg: AYBFou0aSJyZvsrrOD5ybffR3oWAEHHvzFbWpDh/1p9yzwYnxpAQC6PX1FmO8EOy9hY 90PiAx+L7FXr1O17YAIWC2gKsrrDjfcNakY7svQgirl+saO8xuIwiqAWOUxCrBCfgu/CP1N00qS sHSR9C3z+nktq93SXyOvC9HsSBO8hcfeOT4VbjY12ydfihA4dhNLJz9VJhUKgOYC9TkkpfoHSEi DfqN2LNNbijKWE3sS2rb1QtmPgMieBm3EEaWSsMe3uUWD+xW/6pGclIJoikwri0FSnnxWbb/b+U opqmCcLIydtFIT33G1+waXaoC9+SV/8peuz3uhFCPEk4ItpYGPNvBnimVQy+VtoMGuVRyWw5lTX RyEO51NTJBvnKbnGk9RXxKXyzESRUr3wDU/bxwqw/wsbxaxSwjJY988ZFJ4QSv/et7p/vnpeaXB +c3qiP4A2aaCQNROjh6NE6wplYclcUM6ZyXsm2aj0+XgVGXpIzTX5p2G5NHMphAfBt15/z+xY6/ ulJLk8R/4FKaoMFM2mUY7iphUIqzJ5L2V/JJBY= X-Received: by 2002:a05:600c:204e:b0:49c:e0e8:bd94 with SMTP id 5b1f17b1804b1-49cee5b0415mr277544055e9.1.1788816753202; Mon, 07 Sep 2026 14:32:33 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v2] x86/ucode: Work around Granite Rapids erraturm GNR98 Date: Mon, 7 Sep 2026 22:32:30 +0100 Message-Id: <20260907213231.3159241-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1788816753-BE0C5034-14A2B057/0/0 X-purgate-type: clean X-purgate-size: 3122 Block loads which are known to hang the system. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie A more complete solution is in the works, but it's taken 4 months to get this much published... v2: * Correct the sign of the cpu_sig->rev check. * Expand the comment to explain why we are not following what GNR98 says. --- xen/arch/x86/cpu/microcode/intel.c | 40 ++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c index c45b00c6b033..dc21a89aa47b 100644 --- a/xen/arch/x86/cpu/microcode/intel.c +++ b/xen/arch/x86/cpu/microcode/intel.c @@ -27,6 +27,7 @@ #include #include +#include #include #include #include @@ -273,6 +274,44 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) return false; } +static bool microcode_safe_to_load(const struct microcode_patch *mc) +{ + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); + + /* + * Treat pre-production as always safe - anyone using pre-production + * microcode knows what they are doing, and can keep any resulting pieces. + */ + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) + return true; + + /* + * GNR98 states that Granite Rapids systems hang when loading new ucode on + * sufficiently old firmware. GNR101 retroactively declares that one + * ucode had incorrect min_rev fields, in light of discovering GNR98. + * + * Both are incomplete statements of the problem. + * + * At the time of writing (August 2026), the believed safe sequence is: + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later + * + * Disallow known-unsafe loads while permitting believed-safe loads. For + * GNR, this allows multi-hop loading to get up to the latest. + */ + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || + (cpu_sig->rev < 0x01000405 && mc->rev > 0x01000405)) ) + { + printk_once(XENLOG_WARNING + "microcode: Granite Rapids erratum GNR98 detected. Skipping ucode 0x%08x\n" + "microcode: Firmware update recommended\n", mc->rev); + return false; + } + + return true; +} + static int cf_check intel_compare( const struct microcode_patch *old, const struct microcode_patch *new) { @@ -365,6 +404,7 @@ static struct microcode_patch *cf_check intel_ucode_parse( * one with higher revision. */ if ( microcode_fits_cpu(mc) && + microcode_safe_to_load(mc) && (!saved || compare_revisions(saved->rev, mc->rev) == NEW_UCODE) ) saved = mc; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Sep 08 02:56:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 02:56:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411098.1641844 (Exim 4.92) (envelope-from ) id 1x3m0s-0003Bu-Pk; Tue, 08 Sep 2026 02:56:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411098.1641844; Tue, 08 Sep 2026 02:56:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3m0s-0003Bn-Mz; Tue, 08 Sep 2026 02:56:46 +0000 Received: by outflank-mailman (input) for mailman id 1411098; Tue, 08 Sep 2026 02:56:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3m0r-0003BH-7M for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 02:56:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3m0q-00FPjB-BQ for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 04:56:44 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9f7969-2eae-0a2a0a5409dd-0a2a450b8fb2-2 for ; Tue, 08 Sep 2026 04:56:44 +0200 Received: from [52.101.85.50] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9f796a-b7e8-0a2a450b0019-34655532cad3-3 for ; Tue, 08 Sep 2026 04:56:43 +0200 Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DM6PR12MB4435.namprd12.prod.outlook.com (2603:10b6:5:2a6::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Tue, 8 Sep 2026 02:56:27 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0382.014; Tue, 8 Sep 2026 02:56:27 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FNLKY/TL9ihjVf2a51ONNvLPuDvfAHEdEwlp53OPvKoYISnQQCA1Pe3CuSbYICUW75wUwpeq4vqynBY714801xJh2vGx0V302o5ftHSglYgVDCUyLqlubRlMBRt3M/du4b95mEDv/WmKdIeRZxufODQNX0K/jxby0sWLM/+kSf4LndFxaTIVE44HayniZ9TespyJWKuOrV1dkjkGd7Binj3Nb2Y38hxDZwCAAoabkSD6wvnhgSwv0K2NlbS4hrf/ZCHMNqQsdvJd89lIjHxEUEbqG7xOR7CQ89JaQNBRfuM6GY33kpv5qRbsasVCoNQa5C7mihcg97TM+rEAj2xsxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0/+loFgTpB5WI64K9N4RnP70y5sRGMjPtenQs1tbBDA=; b=lTeeySTtb4b/YkEw9x3cLjYc0qImguU9uDMHWRKpgl+r3iioTtN2l5VS0TPf2FqB82Zw8VfxqaA8LnUnUMnEJEOXI40UVp7lobphhdoFnRRsTwiakI8PrpUn4VefNlAvMYTCK8vH4qXM5c3XxfuXO4zQor7tF/YNB2N8H2eZnH+Var5a6JLgL173TsC2Z8d7LBC3Pq1+VqdlkR3g62QHWBruGh7IkdaubyHRPPXGjl5d/TJnpodOEJToSHKRn4hJcOzAp9VdD6n+g7MtGBn6EhgLMKakXPsJzxrdCtTNzU1GfwdSWmnpxGJqfpJqwMIy1OPonfEY9IPzys26aoA3nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0/+loFgTpB5WI64K9N4RnP70y5sRGMjPtenQs1tbBDA=; b=O7zqGrJipndOZP+iH4uMuHVRC/jFfGog+WpzDfJc48qIu1XEmMioqbdt1soIAjrJi9tD2laD1hutZUAdLf6QmmC8EWG8ZPJSGgIXVl/5ZzLy+XnpQJ4FXR6k+8e35lfIafxsS4BC/tKH/fwqoaWpcREealRy0eT0Ij2bKudWYOXRyl/wKtFIdQNhegY+kjBoCKrd7uYIJ87o5ts0MnRt2YEsUJ+RtX2KPa/+wz9rHaBBOpye4ptOGIkLndknWWTy2+oCBMqu1uC0rgV2A5hG4gm+HWonFtSV8vddbrmU/bBfTmLQ269DUCpZ8nZ592kK3WNDA6sPi/FZ5M0e/YMbgg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; From: Zi Yan Subject: [PATCH v3 00/14] Remove PG_private by using page/folio->private checks instead Date: Mon, 07 Sep 2026 22:56:07 -0400 Message-Id: <20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-B4-Tracking: v=1; b=H4sIAAAAAAAC/23N0QqCMBTG8VeRXbdwZzm3rnqPiFjzqOciJ5uMQ nz3pgQRePn/4PzOzCIGwsjOxcwCJorkhxzyUDDX26FDTk1uBiWosgbNAz59Qj529zFQshNy16I B5epWS8fy3RiwpddmXm+5e4qTD+/tRRLr+tWk2NGS4CUXJ3CmflhZKbgMiRqyR+efbOUS/Ai9T 0AmpFJaVMY1BvUfsSzLB/oTPbj2AAAA X-Change-ID: 20260728-remove-pg_private-cfe926c7f83c To: David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zi Yan , Minchan Kim , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, Oscar Salvador , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Gao Xiang , Jan Kara , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-trace-kernel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Song Liu , Yu Kuai , Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , Li Nan , Xiao Ni , linux-raid@vger.kernel.org, ceph-devel@vger.kernel.org, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org, Baoquan He , Pasha Tatashin , Pratyush Yadav , Jonathan Corbet , Dave Young , Shuah Khan , kexec@lists.infradead.org, linux-doc@vger.kernel.org X-Mailer: b4 0.15.2 X-ClientProxiedBy: BL1PR13CA0376.namprd13.prod.outlook.com (2603:10b6:208:2c0::21) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DM6PR12MB4435:EE_ X-MS-Office365-Filtering-Correlation-Id: f5a43f69-1177-4e40-a343-08df0d54c6aa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|366016|23010399003|1800799024|921020|6133799003|5023799004|10067099003|56012099006|11063799006|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: DFa4PsxrZxBeb2/5wrXjfZDIHi2Fxy5+95qvY6K4FHW1tGYNOuTnl0W80trBtV+yMqR20GMCuTgFr7jFXcNEmVzhUYPAo027yju8Vx8gRqUcB+HEeQIptn/BNF1M2gTahlQnDAjgZ1/7THy+UX6nw2ejea5UInnMW5HhPRVMTAOyfICe/ya5H/gVoTCIMTledsODGZHVBYq7eNHD25KQ2GLYI0p/4QzIptdrvqJ89u4P/Cmg2sYCOS44wtcqJFMO3E4+Gc0QNeSm6FmDKV9HuhPkcOGKidN2Uk3xf/LGljecrN4+ePb0TJHhNXaEzTYCJjHU2sh5N5IJEZKT9DyaF5FLJcUiXZ+Vu5pvTGykaT0fVMnLXB2ykNEDDChCUP/P5gPd+UWNCnPVmW+wG3jY1tjDAJDQZ8Y4Tw9WQ4N3Za69ZGQEHPcoKgWN8EdXlh6QFhDag1F4I13DZvFbkNJDd0wTgp3uAE9sXC9BdB0R6wjKihtaEqmWZlXl+Apul6nfDUVeSp9cnZGCmobaPmOm6VphOHAn+wqKtQvCDuQ/4LvGuWIDl29E9xye9CdVGd8AonXkh3hIaL5KTr72yUqyS4+cD6kawxp5eavsy7pDA09skWDfYkGrCQuWjrwgZazW3JQXALmF24ITJylhDA244hv+dhXgFOM5ftIrMEpncTy1cE49CJOt5h8rABb1CEKW3lf4jTlhiR8tLDtRPWDFFw== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(23010399003)(1800799024)(921020)(6133799003)(5023799004)(10067099003)(56012099006)(11063799006)(18002099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c0ZkUmxZZjFYTzVXbExEWUhiMGkyWk9VWjc2aE1yTUl4UnVURW1lZWY2RGNW?= =?utf-8?B?S3ozbW9vV20xazBDUVFzNlFTRkRYVlJSQUhFS3pDTWVLZGNLQ0prd1M3R2k5?= =?utf-8?B?MlZoc0c3ZHFXMGRkSUFaejlWQTNLZm4xYUp5TjZPNGZEczRzUy9CdkdOa3o3?= =?utf-8?B?bStheEdaSGlQNnIxTjdZOXU5em0wekVoTjcyR2Q3TStmNWVWZldQSGRVRXRP?= =?utf-8?B?VkNHWHdMZFU2ZFBzOEpQNURzYm13dXVBQU5wSmtQQXc4dHBmc0lTeVJKbGJo?= =?utf-8?B?TkxMYW5uNnZRUWlweDFORE5sUERQeUtlcTdLeGEyU0RNbTltWndwR3l4L2ZO?= =?utf-8?B?V1MybllhMUtlYlY4Z2ZlT0VtOHpkTktwLzJEaFdnVE1lMVdtR3BMT0dlaGly?= =?utf-8?B?NXdGWUl0cHR1anRVcy9MV3M4dWNVSWx0QmtmSVZ6NEdYcmVCbUJQaDY4QmRk?= =?utf-8?B?alRQOUZYU09PZ2pva2c4YW1FeXhBSDVGMFRzM0ZyYnVtQ2dWemx0bCs5dW5u?= =?utf-8?B?eEorTENjbnRKU3ZIWDZKcldBR0p1R2dTV3ZZTVdPUHJuWjZRUUUxWXNlRXJj?= =?utf-8?B?eTA2VzFtRjFSMGk0OEZLcDc4QTJIa21hZmJTNUoxZlpzQ1d5V3FvQWxxWWVO?= =?utf-8?B?Qi9sczVsU2Z5K0p1TW5GTnJldUtjc0hEOWdSbWtWcGV3RnhtSGlaOUdQWW9x?= =?utf-8?B?enhzRWsrMU04bDJzSlUvNm5HY1M0OE1GY29VRjk1Z1FsNDZscVJIMFIyVHBr?= =?utf-8?B?bloxSUNCRXJLWnVQMHduZVdEZ2EvVzVvUDJva3Z3UXhaSmpUU1hsZG53aG1D?= =?utf-8?B?Tmt0ZmNJQjY4WkpMdng4TWt1MmFHZG1QQi9Wa2dXNzc5NEdWdnNqY09QbUw4?= =?utf-8?B?SzJPbUcycVpvQmtiS1c1QmlWRUEzMGM0OGhJVWR6RDh2ZTZNbWppSjlBWGdi?= =?utf-8?B?dTkrdmFja25tekpnYXROSFJRK3FtNWU2WFA4TkE2MFBPeTZsak5ZTVkvS0h5?= =?utf-8?B?dVZheFRqSUxJSXZSSHc0dG95RXVVVnMyYytBUTNoQ1QrZUZ4M2xuRVZ6Y2F3?= =?utf-8?B?T0VGcFprY3lmbkNVSksrUEVBSDkrNTdzS21MSzB2VEVRUFNQNTgzcVQ4S2Nl?= =?utf-8?B?Q0VGUEVOTk9MZS9Ebk02azhaQkNrQTM2ZVFWazNBUjBtS3gzdlovR1lGMk1r?= =?utf-8?B?V0NKaytEQzMvNlE1UGJJTEFnK01GQ0J0d2lCNkxRM3ZGRWJFUGw0UERDdVEx?= =?utf-8?B?UVFMaWV4NERCU1MvZlhIbEJuN1psWXBvSWJvNGIrdW9ZRXlhemZuckltOFVr?= =?utf-8?B?NHUvSGp6Y2psbWRhcVdZTkFsSDhWMkJHNEc0eUtESldzRkNmb3NiSFR6akk5?= =?utf-8?B?UGRzcHNTaGpFRVMzVUlnSmJ1dzRuL0NkaHVTWk1OSC9qNU5IVk9CQWhvQ3dZ?= =?utf-8?B?Sy9aUHJRNWtxWlkza0RqSFVOL0FYRTVINXF1YS9vVTRyM2l4RkZBVXFpSzlk?= =?utf-8?B?c0pNTGtVOGRobTBkWHZCeUc0YTFybUt6U3c3UlpObWpoRWlKd3k5MzVXdjZM?= =?utf-8?B?cHNFSzFRL0JpV0ZOUzlRY09ldE94Vkg2RzJOZFJ3Y2IyTUVjNURyRzZMNlNw?= =?utf-8?B?MStzSG1nZHIvdEZLdVJVQ25FYi8yTkRKaFF1OTVQUlNINXJOVXZJM0JuczhN?= =?utf-8?B?SjRIVFJNUEpqNFlsc3FlTWUvaVBodTN0ZVZBb01zYk5YdkJzUDdGNVVtd3RV?= =?utf-8?B?eFpKY0g5MTN4NkhxM2ZnZUlpeTBvMTQ1WTg0emFadi9heTRORGF3Y2pqU2do?= =?utf-8?B?US9PaTN3VnJTYSt3MHA4R3FsN1JYS0dqTWRpdFdwU0ozNEJKUHd3djNVMzlt?= =?utf-8?B?cmRjN2htTDRTajVxc3JhYi9xeHg1WTlzeXc1SU9jWmxTeTNoRW1IWjRRMVBR?= =?utf-8?B?VVJCYVRaSVdiL3JYaVplWnJmNjFFUW5zclArN3J4WTF6YUx6WFdDYmdrNlVt?= =?utf-8?B?c1krOGFHcVlNblRFUkFESDBEb2tHc2VXNTBVTUY5eTh4dmZieHJpUGQ2K01n?= =?utf-8?B?UVlRUWdUOUVSNmhiRmYyU3dLSnJIZ05vRjVCM0RpZWtPRTUwT3NaRHFQQXJL?= =?utf-8?B?cGQ4MzAxQ0tPRVhBa3A4dC85bVlNRElEd1JMUUJObkNqRStQeHdzMm1uNThS?= =?utf-8?B?c3pQTXNIUCtxS3lKRURaUU9BUDV3TlBhVGxXZHNmZzZHUFczVWFGMjdUN1R3?= =?utf-8?B?MDRBZzd4T1VsM0wrTzY1M0hUem5zR0pJRDE2SU1IcS8wVG81TUkzNS9aYzhx?= =?utf-8?Q?tqOmrccOv/+NYgACkW?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: f5a43f69-1177-4e40-a343-08df0d54c6aa X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 02:56:27.2502 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: INmokXrarh8Yoor8WTq7CLfba+LlxdubfXkWLLcIL40rtSGcfkO9FCQhfhZ4OJUH X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4435 X-purgate-ID: tlsNG-42698a/1788836203-1A0C59EA-18CA8075/0/0 X-purgate-type: clean X-purgate-size: 10512 Hi all, This patchset removes PG_private to make space for upcoming PG_folio (reserved as __PG_folio) for identifying pages from a folio (more details in Note below). Instead of checking PG_private, all code is changed to check page/folio->private != NULL instead. MM people are cc'd on all patches and subsystem people are cc'd on the cover letter and corresponding patches. Patch 6 is picked up separately in f2fs tree, but since mm-new does not have it yet, it is sent for MM testing. Overview === Most code uses folio_attach/detach/change_private() functions, so folio refcount is increased and decreased when folio->private is set and reset, respectively. There is no need to change them. Changes are needed for exceptional users: 1. zsmalloc uses PG_private to indicate first component zpdesc page and page->private is used to store zspage in zpdesc. To remove PG_private, is_first_zpdesc() is replaced by pointer comparison. 2. kernel/events/ring_buffer.c stores page order in page->private. Replacing PG_private with page->private != NULL works. 3. drivers/xen/grant-table.c stores xen_page_foreign in page->private, where on 32-bit, a pointer to xen_page_foreign is stored; on 64-bit, page->private is used as xen_page_foreign. PG_private check is replaced by page->private != NULL on 32-bit for xen_page_foreign deallocation. On 64-bit, page->private is cleared unconditionally since {domid=0, gref=0} (xen_page_foreign can be 0) is valid. 4. fs/crypto/crypto.c stores a folio pointer in page->private, PG_private checks are replaced by page->private != NULL. 5. fs/erofs has two different uses: 5a. folio->private is used to form a reversed list of the outputs of readahead_folio(). readahead_folio_last() is added to output folios in reversed order, so that ->private is no longer needed. 5b. folio->private is used as an in-flight I/O counter. Convert the code to use folio_attach/detach/get_private() and add bias==1 to the counter to avoid folio->private being zero. 6. fs/nfs/write.c: folio refcount maintenance is in a bigger scope than folio->private. So folio_attach/detach/get_private() is not used. Nothing to change. 7. fs/f2fs uses attach_page_private() to first reset folio->private then immediately sets PAGE_PRIVATE_NOT_POINTER bit on it. Change it to use attach_page_private() to set PAGE_PRIVATE_NOT_POINTER bit directly to avoid folio->private == NULL gap inside set_page_private_##name(). 8. hugetlb uses folio_change_private(folio, NULL) without folio refcount maintenance. Change it to folio->private = NULL. After the above changes, PG_private ops are converted to page/folio->private ops. folio_test_fs_private() is added to check filesystem-only private data by excluding swapcache and hugetlb folios, because swapcache folios overlap swp_entry_t swap with ->private and hugetlb sets its own flags in ->private. Note === 1. KPF_PRIVATE is removed after PG_private is removed. 2. Documentation/mm/hugetlbfs_reserv.rst is outdated, so I did not remove PG_private related text. It should be rewritten. 3. PG_folio is planned to be set on every page from a folio in page_rmappable_folio(), so folios with any order (currently PG_large_rmappable is used to identify >0 order folios, but not order-0 folios) can be identified. Then vm_insert_*() can correctly reject all folios and rmap code will only see folios. Eventually, page_folio() will return NULL for non-folio pages by checking PG_folio, but before that all existing users that treat compound pages as folios will need to be converted. Tests === 1. allmodconfig build passed. 2. zsmalloc is tested using ext4 on a 1GB lz4 zram: 2a. zram load + zsmalloc compaction; 2b. concurrent zspage migration via memory compaction; 2c. confirmed that multi-page zspages actually formed. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_zsmalloc.md 3. erofs is tested on images created with -C4096 and lz4hc, lzma, deflate, and zstd algorithms: 3a. cold read of all files, verify checksums match source; 3b. readahead + reclaim/migration race. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_erofs.md 4. fscrypt is tested on software-encrypted ext4 with writes to exercise bounce pages. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_fscrypt.md 5. f2fs is tested on an image with inline_data,compress_algorithm=lz4: 5a. INLINE_INODE — lots of tiny files; 5b. REF_RESOURCE + general writeback — buffered write churn with fsync; 5c. ONGOING_MIGRATION — force GC / page migration; 5d. ATOMIC_WRITE — atomic-write ioctl path. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_f2fs.md (I did not run xfstests) 6. MM selftests passed. LLM use === Claude was used to form a concrete plan on what code needs to be changed and how to change them. The plan was reviewed by Codex until no issue was spotted. Plan is at: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/plan.md I then followed the plan to make code changes. I did bounce ideas with Claude how to change fs/erofs, since I did not like the original idea. After each change, I asked Claude to review my code and git commit message. I also asked Claude to give me test plans (see above). At last, Codex was used to review all patches. Comments and suggestions are welcome. Thanks. Assisted-by: Claude:claude-opus-4-8 Assisted-by: Codex:gpt-5 Signed-off-by: Zi Yan --- Changes in v3: 1. changed folio_test_fs_private() to check PG_swapbacked instead of PG_swapcache for excluding swapcache folios. Because folio->private and PG_swapcache are not set as a whole, making folio_test_fs_private() give false positive, whereas PG_swapbacked is always set for swapcache folios. 2. added __DEF_PAGEFLAG_NAME() to show __PG_folio instead of open code. 3. f2fs change is picked up at https://git.kernel.org/jaegeuk/f2fs/c/5ad9409a9533, mm-new currently does not have it, so the patch is sent for MM testing purpose. - Link to v2: https://patch.msgid.link/20260831-remove-pg_private-v2-0-3668159cd9e8@nvidia.com Changes in v2: 1. removed is_first_zpdesc() in patch 1 and open coded the checks. 2. fixed wording in patch 2's commit message and clarified page_private() also works when ring buffer's AUX page order is 0. 3. removed the empty loop in 64-bit gnttab_pages_set_private(). 4. clarified folio->private will be reset to NULL by fscrypt_free_bounce_page() in the commit message. 5. clarified why hugetlb needs to restore hugetlb_vmemmap_optimized. 6. renamed readahead_folio_reverse() readahead_folio_last() and reimplemented readahead_folio_last() by adding a new readahead_control private member, _forward, and a new helper __readahead_advance(). 7. added a bias, 1, to erofs I/O counter, so that folio->private stays non NULL between folio_attach_private() and folio_detach_private(). 8. converted more call sites to use folio_test_fs_private(). - Link to v1: https://lore.kernel.org/r/20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com --- Zi Yan (14): mm/zsmalloc: replace PG_private with pointer comparison perf/ring_buffer: stop using PG_private as AUX page high-order marker xen/grant-table: stop setting PG_private on pages for grant mapping fscrypt: stop setting PG_private on bounce page mm/hugetlb: use direct assignment instead of folio_change_private() f2fs: stop using PG_private erofs: mm/pagemap: add readahead_folio_last() to avoid folio->private erofs: use folio_attach/detach_private() instead of direct assignment mm/page-flags: check page/folio->private instead of PG_private mm/page-flags: introduce folio_test_fs_private() treewide: remove folio_set/clear_private() treewide: replace PagePrivate() with page_private() treewide: adjust comments on PagePrivate and PG_private mm/page-flags: remove PG_private Documentation/admin-guide/kdump/vmcoreinfo.rst | 2 +- Documentation/filesystems/vfs.rst | 6 +-- arch/x86/events/intel/bts.c | 3 -- arch/x86/events/intel/pt.c | 6 +-- drivers/md/md-bitmap.c | 6 +-- drivers/xen/balloon.c | 5 +++ drivers/xen/grant-table.c | 11 +++-- fs/ceph/addr.c | 8 ++-- fs/crypto/crypto.c | 2 - fs/erofs/data.c | 16 ++++--- fs/erofs/zdata.c | 13 ++---- fs/f2fs/f2fs.h | 8 ++-- fs/nfs/file.c | 4 +- fs/nfs/write.c | 2 - fs/proc/page.c | 1 - fs/ubifs/file.c | 8 ++-- include/linux/buffer_head.h | 6 --- include/linux/kernel-page-flags.h | 1 - include/linux/mm.h | 35 +++++++++------ include/linux/mm_types.h | 4 +- include/linux/page-flags.h | 43 +++++++++++++----- include/linux/pagemap.h | 60 +++++++++++++++++++++----- include/trace/events/mmflags.h | 3 +- include/trace/events/pagemap.h | 3 +- kernel/events/ring_buffer.c | 7 ++- kernel/vmcore_info.c | 1 - mm/huge_memory.c | 3 +- mm/hugetlb.c | 6 +-- mm/migrate.c | 3 +- mm/page-writeback.c | 3 +- mm/vmscan.c | 2 +- mm/zpdesc.h | 2 +- mm/zsmalloc.c | 24 +++-------- tools/mm/page-types.c | 2 - 34 files changed, 172 insertions(+), 137 deletions(-) --- base-commit: 5f4c0999b2bde1fbbba3c499208b415447ca4c7a change-id: 20260728-remove-pg_private-cfe926c7f83c Best regards, -- Yan, Zi From xen-devel-bounces@lists.xenproject.org Tue Sep 08 02:56:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 02:56:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411097.1641836 (Exim 4.92) (envelope-from ) id 1x3m0m-0002yl-Lc; Tue, 08 Sep 2026 02:56:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411097.1641836; Tue, 08 Sep 2026 02:56:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3m0m-0002yc-GA; Tue, 08 Sep 2026 02:56:40 +0000 Received: by outflank-mailman (input) for mailman id 1411097; Tue, 08 Sep 2026 02:56:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3m0k-0002yW-My for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 02:56:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3m0i-00BVAx-FL for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 04:56:36 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9f790d-e002-0a2a0a5209dd-0a2a4506b926-24 for ; Tue, 08 Sep 2026 04:56:35 +0200 Received: from [52.101.53.18] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9f7962-195a-0a2a45060019-3465351205af-3 for ; Tue, 08 Sep 2026 04:56:35 +0200 Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DM6PR12MB4435.namprd12.prod.outlook.com (2603:10b6:5:2a6::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Tue, 8 Sep 2026 02:56:29 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0382.014; Tue, 8 Sep 2026 02:56:29 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QZ5hLKHaYzmJkZSLcIYKJ2gJ+/N4E7Ljz8W2kKf+SOtYnLwoFibxJ+OyoYlZRwYorCx2u4VktKelVQ56HW+6lLTH7rMkPEHpZFYOETZXm308oKSLnYBTEjqKADN/izUCYf+0HVH2fDX3jWv4XhGS383/gVAPkzNzZ6gFs88biQ+ei8t71phKXPCBA0VZ2tRbylAUxiVxD5hF/jkYswbNAGoTLwkoOL8IHiZ9GuAV+IGpd+uS/xVNLLcJ33rW3ePNSMZJemOYhPiKwYKp1hH6cPMf6YW3LEZmLWKjAuZmgQxpgRm3G9yzQoz8LvozaHs8/9/z/n+ffGYskJXq2ecZCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vgf8AR8nU41qGg9Ak0WHclMBa3GGy6njR91QTF4tAYc=; b=P9DGD2WqumsVeUHRW1wsQabiE4SdQC62RmuTLn0BFQvCWYHGvu7Pm6M2a+dTlVDZCD5qHtDT+FWaTiPvDjcaVv53oAO4FBbnCIWWgsmhpktgU64momMCeW0sLZWdwvVAw8qix2gFt5RFav7isTm/NKncT8zW5k4Ow89HrKQaB5eiFklaLu4vyRU4sJtaqBw8BMyRad2k0eiiJHPOnniDMZgWQsQoX2C0yyttEHkFKKHyDrJ7qOBWEwYTa6XFNuxKV1YlGS8o4jCDeoNGrvK0atuQJRhp3ylNZztlHQ/qefNk7o1ksEWUvGndzmO+EwvqtR5fWqqCMbMJh1bUPt3Ljw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vgf8AR8nU41qGg9Ak0WHclMBa3GGy6njR91QTF4tAYc=; b=aDOhnCljt+nkoWR04sKhhWlQezDH6t5jOU6EPM5JMpkRft3AU2JVG+vr+Ig6vC5a+OFe+hcCf16TNV2gf0TGjr0sGr+csi1xYdTp7t6UCPVrzfvX7r5bv3p0lECox736zOqYkjAIMtSJScdiW26ucq0A28WBBhRs0o3aCkU7s4AXxv7FnlXDrQcAbbGJyP3fQ0jjsgaufGXjVTTwBRqJQyycoIr8mk82CEotTT/odZQJFiCUL3OvUPwJTGS0L2ww4v8zKZEAwTbUORxsNi9J+4Bc6IW17xlCcIeOOGroj1tSk+b7OJ4fvsgqiBMspjSbzXrnaba1ndekyHJIMGcjjA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; From: Zi Yan Date: Mon, 07 Sep 2026 22:56:10 -0400 Subject: [PATCH v3 03/14] xen/grant-table: stop setting PG_private on pages for grant mapping Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260907-remove-pg_private-v3-3-6ae22f9d9272@nvidia.com> References: <20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com> In-Reply-To: <20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com> To: David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zi Yan , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org X-Mailer: b4 0.15.2 X-ClientProxiedBy: BL1PR13CA0335.namprd13.prod.outlook.com (2603:10b6:208:2c6::10) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DM6PR12MB4435:EE_ X-MS-Office365-Filtering-Correlation-Id: 311f21fe-4e34-4094-6a66-08df0d54c840 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|366016|23010399003|1800799024|921020|10067099003|56012099006|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: jbSabVQG30RHv71lVYeVvSNmq4tYCclGHpQ7tv4QEmjEItFEMzotKrbMHuoBF6ELwqr9+ZHiyF9B8loNLYGK59EDFDMTp36tIuVT6z8KuE8qEhf6VmH1lmkUSLQTCR/KzQGmn0BkdsMvv2BjIumSIdtFqKfMbYKrEPglyyjCW6dCV1m7BmuX0e3t37qT7LsWEf775QlJK7zxePaNw9YUhXywmgeKB1QS5lWuMkpsdYbD8emlRRDjw7axZauZNtWHl1PikVX/vGGccGiQ5lYqJS3H+Ex57Y8WW7geIaMLqwNV+2LByXWbfF7HwBQkXOKs81DpcRjKfd9adzx8xVWPlo7/X//yiv8bAAnKgnsPRegcfUdjvUimhsUGaHC2qTvWBbOLkRsFvRgs1bNBASwFi2u3anJtEKV+euddny4H2ZSU6iBohjLbFgo5ZMERe9ff/6Lkt0oQOho7rNU0znGOMqh8ERqZLiO6lrhAF4FvtSMV3J13tRmQmZrw+/uAgTJUeAbPUYQstteDqlAV9tKM1+XmMlsQ87pKsO00OFKc4Y0duKFhs47zZIMxUunsl44dw0OIS+sLCkUpqeL5+ccrYCl1eFkU1A38Z71mGH+bg7Yvzwq8WAgTri0Lvhmnm4m+8d9N3yKrV5S+FU3spNC974KlzB4ZIXrlMu8k0h5kUjKxkIeuRujjPzsfaLXA3xtjeObYR7sx29+KnRMbQFo9+w== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(23010399003)(1800799024)(921020)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RzFGbDcwL0c3a3A4a2ZjQjRlT3B5ZFZWOXJSSGJvaXg0UFZ5M2pwV2R0UFd6?= =?utf-8?B?bXAwcGdQZXRUSXVzL3d0cmlhbXZvVFUyMEM5ZHpOM1Fya2RqVUhIbWZ1VjRs?= =?utf-8?B?cVVKVGR0SndpSTQrcjF0ZC9WaTlVekRXeVBlRTJJVHozeEd1cTB2ektzRi80?= =?utf-8?B?QXp4K09TTWhIZklxUzlJeVc2VmVPYXRvNEgxQitnaG9LdFFkb1djUEVoZ282?= =?utf-8?B?SXJaY0pCaE82UkxGTTV4Uk0waW0zb0Npbi9NR0lRcmlJWlNjUnRQMm5BcEUy?= =?utf-8?B?dkl2cTFsZjdTRVkxYVJ5Tkd1b0JYak0vL2owa0RrVVJJM0NHOEZBUlBVU0RE?= =?utf-8?B?MkdEUXVGVXJYWGJFcUhhQmZKZkQ4WUJnTGlpeHlMTE5rcGprSXd1cElxNWtt?= =?utf-8?B?QkliQXpLdVZ3dUxuVjRHSisrT0JmSHExN2hIYWJzeitaZ2ZkU2VjdHJ0a3RS?= =?utf-8?B?ZFo4clRlM1Bqald2QThOWkc4WHpySTBtcHN5bExQRjQ4a1JCNzVDUmRzejZZ?= =?utf-8?B?SUJwZHZqNE53REtxRzNuTnZEeWFBRlVFYlZFUDJvWEtST05rVU8yTjRhVk51?= =?utf-8?B?RXE0a0ZPRE9PSVV0dkdMMlE0WmtaMFBrenhTZFRac1NrbXlBT0l2S2s1VXRP?= =?utf-8?B?YWtJQWZ1NHhqcFJST21DdmpvM2lBWVRsYjN3dk4rL0E5ZW9XNTJGckdrUzhH?= =?utf-8?B?eFhIMnJveFRxOUpLNG9jQWxoZW5XQ0FBSmtIK2F1SnBrY0tjVWkwcmZmQ3pa?= =?utf-8?B?VjBkMWNtc1d6YlBrRWlWLy9QM3ptRDZ5dGpIRXJvZG12VlpFSkF3LzhzVFU4?= =?utf-8?B?KzBYSmk5OE1wMks5NUF1UEdTWnNpOVRkazJ0c3RjRlBMR3JZMUhpQTBhcW5n?= =?utf-8?B?QnVMbFd6Y0dFa0lETGhhTERjQTJOaGFmczVkR3BSNmdLWkZwQmp1MEVnS3BD?= =?utf-8?B?THZRNnBmMzZYVVJZRnY3VStrOXdFVmR5RlZRZlFyRVY1eGZEblZUMnZpdGZZ?= =?utf-8?B?Q1BBamRFbkNVQzlyeWQxZ1RQS2loTzVob1BFa1V0N2NuWXpwbHp2dHBwclc5?= =?utf-8?B?NkJXL1NuZDRKY3pwQU1YcUEvdThqSGhRVStWSlZFdTltcUxqbzFXUTN6V1I1?= =?utf-8?B?NFpWWUV2WkI3am5tOXdraFh5V1UxREJpUy9BeEhXUWhPV2RnV0M0NExpaXd4?= =?utf-8?B?S0JwZ1UxVmdWOUh5TkJmK0RJaEFBSEZGMHRzWXg3MW1ML1YvM3JETW0rd2pm?= =?utf-8?B?MGEzRDVtTGQxYmIrMWltZjBOcmd3NGIrSzVBM2tkanVHNUFXV0VDYUJMc25Y?= =?utf-8?B?M1JyUm02K05jZ1BSR2JnanRKTllVRTRNbVlCTytGN0F1MXhVQnVLUmNsbTRZ?= =?utf-8?B?K2VlNlR1ZUVBZVVXVG1zTGx3TCs2YW0yeFlhRkdhcEk0eXdLaG4yMml4aDJ2?= =?utf-8?B?MVp1VDNGVE1tNnI5MEFQRVFJcWdpUHR4MkUzV3kzU1V5Vk1MQjFERFVCZVAw?= =?utf-8?B?Q3Mxak1YbXVZNmYySk5kTEhhcGVMbkpKRHRCVWdMRUFoMjJhelFZY1FKbkM2?= =?utf-8?B?enVBSTZlWkd3L09IeUMzQlFmdFE1T25DR3ZKeU9WVDdLUStKVm9Ea3kxbDVt?= =?utf-8?B?MmlHVlhGdldLTXRvbm00QlowbWN1UHB1cm9YYVFaT1ZqSEFmSThlVXpxU2RP?= =?utf-8?B?dC9XaDNuOEpoUTR2WmRaRjd5RXBPVFVxRS9XZXUwTUt6b1JnendZVGQvUjU5?= =?utf-8?B?TlVhMGlWcUk3RWNiZDAwRTBEcFBYYXVuV292RDJ3aStIZk5BWVFpNE5tYmZp?= =?utf-8?B?TmpGR2EzZG5tMEtkWkxsSmhobEtVUXdNWjNFNE1vbFVGMjBwRy9OdFIxR3hQ?= =?utf-8?B?SWhuTXMybURZYVpMbDdCTW0yY2QxVkpPdHAwM2JDUkJvY3NpZ3I0YU04TGJD?= =?utf-8?B?YmJ2ZkhGRVZWY28ycnVmamsrL25FeFhNQklpTWFwU1kvdjBTVE9GLzNhcWcr?= =?utf-8?B?cCs3cUJOQ252ZmZqazlmNWdCRXJxLzZZYXdMVFppYThCWExMQ0dNOUo4eWFa?= =?utf-8?B?cTFDNituUDBPSWJCVmtrdWZuU0N5R2JBK2cvWXZHRWFIUjkvSlY0bmQwcUEx?= =?utf-8?B?M1pKRmVXTFpSckVMWm9hMHp6dW9VK1llaHM3cXZyRldpSWMxUEVncWZNSWs5?= =?utf-8?B?YVNNYUw2OWJqbG16ZitKL3lUL0k3ZjVwK2NWdU9IRTBWbHdUWkYwL2VWcEpW?= =?utf-8?B?bE5tUjRJcll6MjRYT28zT3FBS0swY1lZWWRjdXgrV3Vnd2xNckM2Uk5ITzJH?= =?utf-8?Q?lBp7EAf5XXWIufUjfY?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 311f21fe-4e34-4094-6a66-08df0d54c840 X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 02:56:29.8638 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 2QlM/uczXHjWE7PSdJaYLIQu0dSp0UAjugrRRw4tmD2alv1B38aHLz0wjbAg2Vpg X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4435 X-purgate-ID: tlsNG-16d1c6/1788836195-FE67277B-69239FAC/0/0 X-purgate-type: clean X-purgate-size: 2610 gnttab_alloc_pages() stores xen_page_foreign in page->private. On 32-bit, a pointer to an allocated xen_page_foreign is stored; on 64-bit, xen_page_foreign is stored inline. Checking page->private != NULL is enough to tell whether a xen_page_foreign needs to be freed on 32-bit and page->private is zeroed unconditionally on 64-bit. It prepares for a future commit that remove PG_private. No functional change intended. Assisted-by: Claude:claude-opus-4-8 Assisted-by: Codex:gpt-5 Signed-off-by: Zi Yan To: Juergen Gross To: Stefano Stabellini Cc: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org Cc: linux-kernel@vger.kernel.org --- drivers/xen/balloon.c | 5 +++++ drivers/xen/grant-table.c | 11 +++++------ 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index e7f74ea7cd5eb..fdb18348cfdfe 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -182,6 +182,11 @@ static struct page *balloon_retrieve(bool require_lowmem) __ClearPageOffline(page); dec_node_page_state(page, NR_BALLOON_PAGES); + /* + * clear page->private before giving it out, since it might be used to + * store xen_page_foreign info. + */ + set_page_private(page, 0); return page; } diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 69922be28b54c..993f89f048e21 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -863,10 +863,10 @@ EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames); int gnttab_pages_set_private(int nr_pages, struct page **pages) { +#if BITS_PER_LONG < 64 int i; for (i = 0; i < nr_pages; i++) { -#if BITS_PER_LONG < 64 struct xen_page_foreign *foreign; foreign = kzalloc_obj(*foreign); @@ -874,9 +874,9 @@ int gnttab_pages_set_private(int nr_pages, struct page **pages) return -ENOMEM; set_page_private(pages[i], (unsigned long)foreign); -#endif - SetPagePrivate(pages[i]); } +#endif + /* Data is stored in page->private on 64-bit */ return 0; } @@ -1031,12 +1031,11 @@ void gnttab_pages_clear_private(int nr_pages, struct page **pages) int i; for (i = 0; i < nr_pages; i++) { - if (PagePrivate(pages[i])) { #if BITS_PER_LONG < 64 + if (page_private(pages[i])) kfree((void *)page_private(pages[i])); #endif - ClearPagePrivate(pages[i]); - } + set_page_private(pages[i], 0); } } EXPORT_SYMBOL_GPL(gnttab_pages_clear_private); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 08 06:06:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 06:06:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411122.1641854 (Exim 4.92) (envelope-from ) id 1x3oyY-00016Y-Of; Tue, 08 Sep 2026 06:06:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411122.1641854; Tue, 08 Sep 2026 06:06:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3oyY-00016R-Lv; Tue, 08 Sep 2026 06:06:34 +0000 Received: by outflank-mailman (input) for mailman id 1411122; Tue, 08 Sep 2026 06:06:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3oyW-00016L-N9 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 06:06:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3oyV-000Fbl-Jh for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 08:06:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fa5d9-bab6-0a2a0a5309dd-0a2a45048688-32 for ; Tue, 08 Sep 2026 08:06:31 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fa5e7-b57f-0a2a45040019-d155dd33e56f-3 for ; Tue, 08 Sep 2026 08:06:31 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso3022747f8f.1 for ; Mon, 07 Sep 2026 23:06:31 -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 ffacd0b85a97d-4858ab73c2bsm32003538f8f.22.2026.09.07.23.06.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 23:06:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788847591; x=1789452391; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=fToW8Qfa/ir2WdXjPYveDRJbLRU0M7rdpYwMx0TEukg=; b=CTGBvRJk9x7ATEpc295VK9SB87dxR3ZImsgw24jEg9s3kEIhYsZNw0a2aIhM1Z8bTl sgngVLfow970oepi2544c7L+ZvArOr9BTfs9lRfZg1BbSupO1FB0+ZrqknmWgfUllmta 7JTc1NGHJMk0V7lADdHDbuXRVLCRTqXepoG7Fg4NOM3Q0daIlZLPDUqBnCwsudu9lskt shLzhhjJMIAAdVSUNm+vwV4f4zzDYqRMeXANK/csBRk86uvbrR49L0rWOTzP59K6sdtJ 5CCfwtWTexFqwthharpJ5m6l11omx/jOsBGyJ2JJEQVDoX6uODkkv68uXANLpFiiH6RW 6RBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788847591; x=1789452391; h=content-transfer-encoding:content-type: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:content-type; bh=fToW8Qfa/ir2WdXjPYveDRJbLRU0M7rdpYwMx0TEukg=; b=FYKlBA5+kJ1qei3C5Yb5R4qBFTKf4AjdzsTvDexblqfTFcsIdYOhocgKaJzGAZLc/a axjRPhxOi7T/VEbM+nB2ixLXmTFH/fmaur46kbBCxKjlrDPMjfATvHJnXKp8fRMfJt2L 2nFJiCHYudoExl8Iw7Fo+9rDjhQTbP4OOy50hzQb3POhA/AtkV3OnoAlv3Y2JGxvGAEO M3uEyEVF+6BzRK69nAec6LoOVbR9k0+SmU3WCp/3uKF36cen9iOJNDX8yZjExHmgOIRf YJzhP61iZqRuaixzebQj9oCgnE0d6Mvk+yALsaaU02+dym4YBJFKX+2eWgKnVbA8h/O7 TSZQ== X-Gm-Message-State: AFuF++lWnMyFJMG307N8pHt+wHlRfVWZT4e+h2uCfAXRzNxUS6zYzVP5 2ZEKgRmCUtZ+IYROI70fjmMtkmdfPglaPIVvWi5VW7msfnmodHqx4ha7zRRmWiu4Sw== X-Gm-Gg: AYBFou1sj+MFEybV298gj/Q0ylDZz+i2qzR+qh9SQmNqPvkQmEVtyEMa6tNe/ajoIAw YR5roIpNfIdmnMT7yHCMLcQmldWsZbNvlzAGspfkvNSjQDSR1jIs6V1E/7Akw7HHzkmqenPeVxF /ZTPFT3Xcoub8mO04WMdfpIpVyKmwrXkWvnRxi2lfTWG7YsHnOpxrGcwmIef5gRMtDH6Spf4EL7 YXJSutnYS0lLxCLXooyMgreY+5SHgH77SOYEFed8TkpFAjvMYk5kOISkLttwBiPQESRlqajRAfE uxJKsJvVUwwrTWKCQ2zDMUWeJ3QhfcbiBQKp+lWlYGa9TDRXb2lQCGO0++QUt9/1STliNbkHphv +B60TVtTpIP1WQZezGV6LP8gg1q6DqrPn4lVgOU2fh9YXC9l28DL2JNdtYpp85CqsFaljU6sJj4 WnvjjJPg2YCPs9xlnmthj4Pu+acuJvvrAQ3XoNqcJGxQr5YWzLhpoaboZqpjOGeMdBo3TbA+bzj FeeyBS9nu8hACoqTqW+EDQCOurXusZUzhANUazYsNylrnvtkX+Z X-Received: by 2002:a05:6000:4819:b0:485:8c16:a347 with SMTP id ffacd0b85a97d-4858c16a542mr22692240f8f.31.1788847590898; Mon, 07 Sep 2026 23:06:30 -0700 (PDT) Message-ID: <9123f379-6f87-4116-95d4-982e55f27053@suse.com> Date: Tue, 8 Sep 2026 08:06:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields To: Baptiste Le Duc , Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> <1788796633.8631fc262581453bbf619ec5b2062170.1a07c968185000c4f3@vates.tech> 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: <1788796633.8631fc262581453bbf619ec5b2062170.1a07c968185000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788847591-C24CBB50-79E9ABA1/0/0 X-purgate-type: clean X-purgate-size: 1353 On 07.09.2026 17:57, Baptiste Le Duc wrote: >> --- a/xen/arch/riscv/include/asm/processor.h >> +++ b/xen/arch/riscv/include/asm/processor.h >> @@ -12,7 +12,19 @@ >> >> #ifndef __ASSEMBLER__ >> >> -/* On stack VCPU state */ >> +/* >> + * On stack VCPU state. >> + * >> + * x0..x31 must remain at the start of this structure, in architectural >> + * register-number order: code which resolves a register number to its saved >> + * value indexes this structure directly (instruction emulation via >> + * REG_PTR() from asm/riscv_encoding.h, exception table fixups via >> + * regs_get_gpr()). ->zero therefore has to stay at offset 0 and must always >> + * read as 0, since it supplies the value of x0 when x0 is used as a source >> + * operand. The layout is checked against GPR_LIST() at build time; see >> + * regs_get_gpr() in extable.c. Do not reorder these fields or insert >> + * anything between them. >> + */ >> { >> unsigned long zero; > Comment claims ->zero "must always read as 0" as it's hard-wired to zero > by the HW, but nothing enforces that, it's still a plain writable > unsigned long. Maybe a write-side counterpart that special-cases num==0 > as a no-op, or with a minimum ASSERT(num != 0) / BUG_ON(num == 0) to > anticipate any future forbidden writes. With polarity inverted, though. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 06:26:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 06:26:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411129.1641864 (Exim 4.92) (envelope-from ) id 1x3pHw-0005UZ-BC; Tue, 08 Sep 2026 06:26:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411129.1641864; Tue, 08 Sep 2026 06:26:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3pHw-0005US-7I; Tue, 08 Sep 2026 06:26:36 +0000 Received: by outflank-mailman (input) for mailman id 1411129; Tue, 08 Sep 2026 06:26:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3pHu-0005UK-Hg for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 06:26:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3pHt-008uw5-5i for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 08:26:33 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9faa98-8faa-0a2a0a5109dd-0a2a4505c5fc-2 for ; Tue, 08 Sep 2026 08:26:33 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9faa98-4cb1-0a2a45050019-d155dd2dbd0e-3 for ; Tue, 08 Sep 2026 08:26:33 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-4859245e493so2038395f8f.1 for ; Mon, 07 Sep 2026 23:26:32 -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-49ce46696e8sm318885975e9.0.2026.09.07.23.26.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2026 23:26:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788848792; x=1789453592; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=NCGHLLm0dUzJmFJNvDd/j288PmHir+QouhzLPNUm8nY=; b=VfwWWWmx4OXLevCN5iLZMX8RdslKEtMb/v0wyvFXJ7AP4gHtmV2HcrUdc37Ezu0pnN j8GIgd42SUXjHH/+JhSABOURxiBbwZpinM0cRHFDvEo176R/5Xmgl13H9Cmj5yBLpED2 jSQuAGXmg66RdoMYWdpGHdRON5LSV+eXMg0P2Q6LOMF2XGBAofAlRMMyXtByFgh3afmA c9JcPJAxNDo7+rAsQh+5NXRn+NFVDQ2petHf5x2fbt5fy5/UehRkcMEVFo86se9ZXatm i9SWR+ukatviCMG3R9SuCPeybMrEsm5E/eQiOqzP6at2AxAM5rx08UYuRslFRGJFwcTK 45vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788848792; x=1789453592; h=content-transfer-encoding:content-type: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:content-type; bh=NCGHLLm0dUzJmFJNvDd/j288PmHir+QouhzLPNUm8nY=; b=gC1G+yiS+FPP8isPxIjkQolqu7oHbJmM1D9situmYl9/JfTJIzI45LSskKM6BZeUb1 Em2s8sdwL0T3n77RJyzF2ViiMBOcCjWundOHhtqrBf7tvE2wzU/nIu19DmXDmHT4Q6PS nzDcKja2idzFgQ/TW4vim5GgvPD8MALTUcvKk0MiWJCmtIyDsXwFuQQJpMqBIrUB1MTX /nean8olYR8ZUNyI+Ab4iVj4d9kVoCK2LstG4GcMBtZcaBbf5ZCzzzmZXwVQr7Q6WCVe RbSCOvQdu1P4dQ3ws7t9s0cZB2GWh4XbgM9gZUYcWavTFVfCGbvUipfJ4epG8ZkcnI0b 8fQg== X-Forwarded-Encrypted: i=1; AKwUvByMPrnVE9JeVCyQBC9ad/dAmOwfVeqMEN4js2AzEioxHAkbubHqjF9PmOsghs+Wfn4IRohZ049xr8k=@lists.xenproject.org X-Gm-Message-State: AFuF++lozKdx7Y3LTV7BqPBobJV59B0LksoXAPfbfIw90Rt2bbbTh7Hg xYK+WLuyMdeH3VIO9x8qvYtZPuxGLCtGQ6yKIHd3MrBKejsW26hsTuyTG2vmLizOBA== X-Gm-Gg: AYBFou3ySyraH7boK3bwHD27Y6K4sAsTaQAkFUnI+LF4hSUhBkCxAQbfD+HnZhW/Nhp hPOSjHGNlvgC2QtTG3NvBbGHliHJ963c/1olmczXZsLwR6FQ6Q/Uo9pfJdUy8yD2/A04IiIA/Q7 nQ0tqFlEmwZlJaM/gaek58gKZxCLX4lXq+GUcOBj6gxorJOX5fqNn2ujObwxJNz5z/kspJLDZVA EiA6ZdrcRgWSltOqWmayM3+B116eJdgN65YJeBb85pgbveRuJPrMHl3g178PYL876Ox6WVeQe9r ZgnXQeoeruOEuVajoAsbhKB5iX8m8t7oCukgpjRF3Titmj/UvX0RIFBjrIEmjQtX60Pd5B1usT8 /nVPp0IMrUWcZNd9112sqPlNXqex8j3TolU+qkiz5dlkr2FaJj9Zs7EUSOUAoneM8zzJPLOZwS0 Do5bBN0Zk58dzZRYyZRwasKE9xrHs2AjnmuIvJQlK26aiQqqf0+T6Isb8uZDCFeAx5TkG8rVgO0 ioU7hKnsHeL58Hamwvhileak/p74wUws40J0QtcRg6PyHmri+LW X-Received: by 2002:a05:600d:4444:20b0:49c:fa21:e74a with SMTP id 5b1f17b1804b1-49cfa21e8c9mr176786235e9.32.1788848792483; Mon, 07 Sep 2026 23:26:32 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 08:26:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260907213231.3159241-1-andrew.cooper3@citrix.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: <20260907213231.3159241-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788848793-F4AA72A1-23E0712B/0/0 X-purgate-type: clean X-purgate-size: 2359 On 07.09.2026 23:32, Andrew Cooper wrote: > @@ -273,6 +274,44 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) > return false; > } > > +static bool microcode_safe_to_load(const struct microcode_patch *mc) > +{ > + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); > + > + /* > + * Treat pre-production as always safe - anyone using pre-production > + * microcode knows what they are doing, and can keep any resulting pieces. > + */ > + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) > + return true; > + > + /* > + * GNR98 states that Granite Rapids systems hang when loading new ucode on > + * sufficiently old firmware. GNR101 retroactively declares that one > + * ucode had incorrect min_rev fields, in light of discovering GNR98. We still have no min_rev field, so imo a reference to it wants some clarification. Really I first meant to ask why there's no use of that field, to merely make that one exception. > + * Both are incomplete statements of the problem. > + * > + * At the time of writing (August 2026), the believed safe sequence is: > + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later > + * > + * Disallow known-unsafe loads while permitting believed-safe loads. For > + * GNR, this allows multi-hop loading to get up to the latest. > + */ > + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && > + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && > + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || This is odd: The lhs of && uses the lower bound of the inner permitted range, while the rhs of the && doesn't use the upper one. If it's intended that way, I think this also needs clarifying in the comment. Otherwise imo lhs and rhs better would be consistent in this regard. > + (cpu_sig->rev < 0x01000405 && mc->rev > 0x01000405)) ) This one, otoh, fully matches the comment. > + { > + printk_once(XENLOG_WARNING > + "microcode: Granite Rapids erratum GNR98 detected. Skipping ucode 0x%08x\n" > + "microcode: Firmware update recommended\n", mc->rev); I think a 2nd XENLOG_WARNING is wanted after the inner \n (or none at all, to use the default for both). Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 08:19:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 08:19:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411176.1641880 (Exim 4.92) (envelope-from ) id 1x3r2g-0003lO-Bv; Tue, 08 Sep 2026 08:18:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411176.1641880; Tue, 08 Sep 2026 08:18:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3r2g-0003lG-7b; Tue, 08 Sep 2026 08:18:58 +0000 Received: by outflank-mailman (input) for mailman id 1411176; Tue, 08 Sep 2026 08:18:57 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3r2e-0003lA-VW for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 08:18:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3r2c-009ICz-J3 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 10:18:54 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fc4ea-2eae-0a2a0a5409dd-0a2a45088860-10 for ; Tue, 08 Sep 2026 10:18:54 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fc4ed-f659-0a2a45080019-b9ff1c22b06b-3 for ; Tue, 08 Sep 2026 10:18:54 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a080193399000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 08 Sep 2026 08:18:50 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 8211783346; Tue, 8 Sep 2026 10:18:49 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=+RMLBvJEtS0xTq4PcjrpT+C+Nw0tIqQWaxlAZ0yjahM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=IxjXqfYcKnUxKPFovh4dtgdUBYg/Q/Vfc4AmMSl7ii3CooDKeArMxgMbL0dwB8t24/8AnR+AF eCfgGWbYpX88I4lB9SM8fmvhZFiUz2V4uZDqFHlZm7IY9gitSWffhdGfehmvLzAnLgKhcy34GfG Q+/71U+gSmBfGMBOgGIxSrRNMrQYyAt2Gx2wMzlFmept0CrmEfSdY+WShKHR6d3U07USZ+s6KDA mDHga4I5gQG6YV4jV+jZL2G21Hn7vV3YPZGivFAHfqyJaLow4jlx1szDNLAAl61jpklG1uegG3D HdCiodX99q1sh/hyVhD/2m1L2QigUUlcW1x4ZjkTj+Dg== X-Zone-Loop: 032c064d72bb20a60b4ac7d7f633bbe49f58a40450f3 x-campaign-type: default x-transaction-id: 1473e2af-80f3-4685-bd52-00f79230cafc x-swg-uid: 01-f8de22c1-9d47-45eb-b242-64e8b2a13fd4 X-Mailer: Sweego Message-ID: <1788855530.8631fc262581453bbf619ec5b2062170.1a080193399000c4f3@vates.tech> x-swg-bid: 1788855530.8631fc262581453bbf619ec5b2062170.1a080193399000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , Oleksii Kurochko , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <9123f379-6f87-4116-95d4-982e55f27053@suse.com> References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> <1788796633.8631fc262581453bbf619ec5b2062170.1a07c968185000c4f3@vates.tech> <9123f379-6f87-4116-95d4-982e55f27053@suse.com> Date: Tue, 08 Sep 2026 10:18:44 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788855529; l=608; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Qwvpw+2VFvMEXbZnYB+iZbEu3Juq2tyty4Fn9wojnT4=; b=EephggSH6J/IX78cDXM9x4lRR9D5Qssn0AvaTY2CId69Ub8Nyg51DeIDUvx5XChnyUQNzOi5H T7w9JNz2LXlDXtkV91NrijWCO0D8e/8XdGZjg1YMDBuvV6pgtzUsuZT X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788855529741 X-purgate-ID: tlsNG-c1860d/1788855534-CF75B87B-718A3B73/0/0 X-purgate-type: clean X-purgate-size: 612 On 2026-09-08 08:06:29+02:00, Jan Beulich wrote: > On 07.09.2026 17:57, Baptiste Le Duc wrote: > > >> --- a/xen/arch/riscv/include/asm/processor.h > > Comment claims ->zero "must always read as 0" as it's hard-wired to zero > > by the HW, but nothing enforces that, it's still a plain writable > > unsigned long. Maybe a write-side counterpart that special-cases num==0 > > as a no-op, or with a minimum ASSERT(num != 0) / BUG_ON(num == 0) to > > anticipate any future forbidden writes. > > With polarity inverted, though. Yes sorry, it should be ASSERT(num == 0) / BUG_ON(num != 0) > > Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 08:44:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 08:44:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411185.1641890 (Exim 4.92) (envelope-from ) id 1x3rR9-0007dP-8j; Tue, 08 Sep 2026 08:44:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411185.1641890; Tue, 08 Sep 2026 08:44:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3rR9-0007dI-4O; Tue, 08 Sep 2026 08:44:15 +0000 Received: by outflank-mailman (input) for mailman id 1411185; Tue, 08 Sep 2026 08:44:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3rR8-0007dC-3e for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 08:44:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3rR7-00CTI5-4j for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 10:44:13 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fcadc-bab6-0a2a0a5309dd-0a2a450aa97a-4 for ; Tue, 08 Sep 2026 10:44:12 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fcadc-f2d2-0a2a450a0019-d155dd31b1dd-3 for ; Tue, 08 Sep 2026 10:44:12 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-484374f54d0so2762223f8f.3 for ; Tue, 08 Sep 2026 01:44:12 -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 ffacd0b85a97d-48588392b3esm39542898f8f.12.2026.09.08.01.44.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 01:44:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788857052; x=1789461852; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=rAoilZe4XuyKlFsnA3IuQchtDpRbFQCE7Y4noXN962g=; b=OBv1r/Xh2hC1pAEENJI7KadQp3dFSB+AhCiwjIwQUvl4tqiU+xispmQD1Mt5fj4YSP OavZDQq3n8WHe1pKmjiKdehiHYw1awxHIQnHWoW5Q0P8WVmh39aIKDn9cYjJ3TR6G6eX Ve78l6hVTWzxeG4QMhvfarxox1zMKLEEfsp/qMMtI6up/2DGB0OluZDpPY+yw5WJhaCO 7MbTURD9j0nMHbQMIU50aFRNztjeaHMR4Xmwl/nLmyz5oGg4QKFig2pTRTXE2HRK5g1J 9EpVTU9hPTemkXob6URJ78/tUGBkQex0joMoDiHF0O7GXEkni5SH9w8ioUMGi9gYzMVg rpLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788857052; x=1789461852; h=content-transfer-encoding:content-type: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:content-type; bh=rAoilZe4XuyKlFsnA3IuQchtDpRbFQCE7Y4noXN962g=; b=enLBSrsDox91N9lj4oy1+sKy5zwGmSeWA8V9C6dpDmldGmXdiijllN1gv1LVFUZm+j rTsPC+hQop3pBJYKPbU/jdf4cnrD+h5sGWAVyvieVrTylsxYM2G91d6fmNOq7xZ30KDN YgYrqnB6zYthC4c2CpavcWSuqjePpEeMRjl0Xf6QvrSYBdwJAbBimYCUHkqSIpT38HAQ CKeD694t6RPjOKuKREa9N9QDlcxCzmK3i5GeHRIH0/wwQH9tc4cWef4xLKCU44/JMFcy rPqKvOMMVAKzGoMMzrCjEsDG4YQsLcgS0h6iApYG/0lTNEN8UhtUyOiM9N/XcrD2VuN6 G4yg== X-Forwarded-Encrypted: i=1; AKwUvBxHoT4OhmyNpHyKUIfjGr7X/87gtiy9kF6oUHB+kQydpop2a+qXnOaiQJH99JLXYxsUZ1nPmtioBkQ=@lists.xenproject.org X-Gm-Message-State: AFuF++nR3YrbIuFkYbHvGb68qwWQgzZVHnx1u2xhTQaTZuQRdjNoJN/t B4yveBec2XZE5DRMwPUL6lhmw4G5PIM/6QNqBuQnya1eB5BoV/kTVaA6v+zPKKrYQg== X-Gm-Gg: AYBFou3wM9y0ophzIWmAzyXCh/5c+SFXTXj45EgcEOf5m4vUvUp9v9og5Xlqb5yDenc dSHkBZapTz8SiTW4uhFFKG9PHpaGAUYp/MBlce6wYDAsJcacJxQPyyql1vb8rc5yU3+KP3lK+Y2 lk+oE9U8Kj13rZBAhl2PxX7dVq8tEpx6c72akhr1Ji3guKfobRCrjV261iuPXw8LbVBWoUGRZ6Y rmiP4WNlWyPK69GCJJAVyVWHnp7QVpzNvLy8Ne2L37L12HKDLRshbAlKiRuPWlmbwvpcl/Kqnht sThagoY5l1BfP15WQMXsXamLgocJfZ540dfdkHvDN6rE6M76lD7ZBedfGXS8RdCcavADgyyffVv vtso8dgGQBrPG8j0Rx/CkJrBF9LJ37Xht08g4RP6bUJoPsvmXnmNVvaky/rWOg0vBsiBql2EKxi Oye9EGk9+iMbcIEu2KBHMrWMNwR/MIKcAO1bOCSPNhtKpFTvrP6zJX3mYpQVVoCRoV7t/aFUl/n CioRrR3bqmmGEiyDyXnMfgUXDQERhWTVDN5HYAqxQZGI7ofh9xloPSC4hg+Efo= X-Received: by 2002:a05:6000:420d:b0:485:8ebb:be1a with SMTP id ffacd0b85a97d-4858ebbbee4mr46152477f8f.4.1788857052213; Tue, 08 Sep 2026 01:44:12 -0700 (PDT) Message-ID: <8fbc99b1-d98b-4f52-b9ea-bd84e8bfa2ca@suse.com> Date: Tue, 8 Sep 2026 10:44:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/svm: Intercept CR0 writes selectively To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260904122330.306936-1-ross.lagerwall@citrix.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: <20260904122330.306936-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788857052-4B8D5CFC-6E57ACC9/0/0 X-purgate-type: clean X-purgate-size: 1266 On 04.09.2026 14:23, Ross Lagerwall wrote: > @@ -2517,6 +2518,7 @@ void asmlinkage svm_vmexit_handler(void) > hvm_sanitize_regs_fields( > regs, !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l)); > > + v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb); > v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb); > if ( paging_mode_hap(v->domain) ) > v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb); gitlab-CI says no to this patch [1], and I think it's the change above which gets in the way of running guests in shadow mode (as is the case for the two qemu-smoke-x86_64-*-pvh tests). svm_update_guest_cr() has value = v->arch.hvm.guest_cr[0]; if ( paging_mode_shadow(v->domain) ) value |= X86_CR0_PG | X86_CR0_WP; vmcb_set_cr0(vmcb, value); i.e. upon reading back the guest's CR0 value we would wrongly record it having PG (and WP) enabled, at which point shadow code would try to use the still-zero CR3 as page table base. I think values need merging here, with only TS and MP taken from what vmcb_get_cr0() returns. The zen2-* failure in [1] is, I think, unrelated. Jan [1] https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2828369624 From xen-devel-bounces@lists.xenproject.org Tue Sep 08 09:06:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 09:06:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411198.1641897 (Exim 4.92) (envelope-from ) id 1x3rmm-0002Hd-0r; Tue, 08 Sep 2026 09:06:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411198.1641897; Tue, 08 Sep 2026 09:06:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3rml-0002HW-U9; Tue, 08 Sep 2026 09:06:35 +0000 Received: by outflank-mailman (input) for mailman id 1411198; Tue, 08 Sep 2026 09:06:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3rml-0002HO-2A for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 09:06:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3rmk-00FlME-BN for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 11:06:34 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fd01a-2eae-0a2a0a5409dd-0a2a4507a2a0-2 for ; Tue, 08 Sep 2026 11:06:34 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fd01a-b4ea-0a2a45070019-4a7de48caab0-3 for ; Tue, 08 Sep 2026 11:06:34 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f9c60d5so65885866b.1 for ; Tue, 08 Sep 2026 02:06:34 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d4aa01dsm582950966b.15.2026.09.08.02.06.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 02:06:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788858394; x=1789463194; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=3AHP7sy+fgkGxbPk/SmQ3YaMHYxTwvN7LycOYk7SzX0=; b=JAdBmaC1j4Ef8cuRoh3lZRgKrXxJHbCJmUh6S7wVpdobuGkiACEN99IfCAySdPFN2D /OYSYm8fPlEGb1zW76Zgz6RSBS+u0PHTd6oIhisa7q3ve1MBYtP9U3kzQ9ojGZZ6Hp+s dek4O14FK/XNrduXsAEIgOSFoHcGi8pn1mMsCkVO9dW1bMPgLs4lX9zu8swet1KKrrh9 Mb43lSb+wtIcq4OpOw6QzTV5f7mO7pugyN8LTlI2vkjKjJQ0t9/Zy15oftYo1hIqjFOw KXU9Sc0ai5zfPGi6a/kz9xwFyhOp+EfN1m/1STcPzo4RbwgKybSUKBoeheQhZZ2K8Jvc 0U/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788858394; x=1789463194; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=3AHP7sy+fgkGxbPk/SmQ3YaMHYxTwvN7LycOYk7SzX0=; b=oV46Q6PH72gAZgOenzoS4V/YNP4FBM1LrUi0To7zICG3+YC77DZ7GwYMuRTT5K0rtB XRCsrcEPQYjtVSOdzJYlDujqeFNqmEuYxdAPLvnQGzpIouDu1luCO7aeOEEcwoFNfRon YRjiuIGrDLDJOncqQM9RxA1RFYt2+0O8GaJCp7R3E2NZgIMl7KOrhSgQL+e7bxnqGTUM HD9BARVfgm53FG+yQxNZJP/vCr/JCHBBJLzxLITaoSXq4jrIQ1iYOifRUU7/HOP2Q3IC 0XUHzLjmLgjcKP1QTSTEZ6LuXfyP8+lIw4V7hM1Gk4/AwbdSuiEcMR5v9ZRHNBGkU26L cXWA== X-Gm-Message-State: AFuF++nm9xwOH2iPvPDOmWjB2OJRiFmcMjKQ58bm4GnjVvcXg12cPDDD QFMwH0Cwj9nfJLNI03nnduU7nZJOCBy/B9o/2KNThCXPKYLv08UQTZRU X-Gm-Gg: AYBFou2Z19zUmYisDKp+QWs0bBXDARJBYRSBNBURDLZnCruW7Xy+jM3LDtlzr6uk6JM hlvGJS6e5BCAoDu9myPYM3cYU/qxYLI5B2XU9GvV8x1sjksl4jvZYH3yKjqG6U2A2EDCCCHAbY4 hdS/+N+x590ZqaA7UysHChfxJEu21uHJz+TFLp/mSHtfeAtDcbjbxl/TZ+jfH5iIoGRG/IvSpWR DbI+bkViB9FkoHBDoaV5Eok23uvfWCJa1hMfbrl0JdL6inf7EyFO+tBFeFcJbU4K23EXVeZkMUg Ce1t9oac8kpJK1qADItp1apEMDMFRQkR0sFalEUwnCoESYyyDJ6YykXq39lcPfR2cWMs6zDKxSp dr5E2P5ZqWs4DbNq9/dYb9Za5Y/GWduWZUwtz9IMBcIVEn5AqTjbI9TV2UoHH4PUTT2ha0kVNeL h1iLrjL7hUjIYqadJYamFVOrHK/S2loHlY2GrtYZsVQ+o6WZt19gGRWdlvrdJyubCv+K7EuRK8o JtgScndc/UbDDt9TA4jndI= X-Received: by 2002:a17:907:3e0c:b0:c25:f7db:4bef with SMTP id a640c23a62f3a-c2904519fdamr282291266b.21.1788858393517; Tue, 08 Sep 2026 02:06:33 -0700 (PDT) Message-ID: <02fad9cd-e721-485c-b84e-2dc563c49d1f@gmail.com> Date: Tue, 8 Sep 2026 11:06:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a349000c4f3@vates.tech> <91c9abf0-a25f-42d0-9d55-61a9cc62e233@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788858394-A60C5AE4-34AFF76F/10/73395122804 X-purgate-type: spam X-purgate-size: 10508 On 9/7/26 10:17 AM, Jan Beulich wrote: > On 04.09.2026 16:55, Oleksii Kurochko wrote: >> >> >> On 9/4/26 10:26 AM, Baptiste Le Duc wrote: >>> As I understand it, a generation wrap doesn't retire a single VMID, it >>> resets next_vmid to 1, which makes every VMID in 1..max_vmid reusable >>> again in the new generation. We do a full (local) flush at that point to >>> avoid two different vCPUs ending up with the same VMID valid at once, >>> across generations. >>> >>> If this is correct, doing a full flush there also throws away entries >>> for the current vCPU that a local HFENCE.GVMA(vmid) per retired VMID >> >> We are doing flushed for the pCPU on which a vCPU is ran. >> >>> could have preserved. A local-flush-per-VMID approach could also >>> reduce how often we need a full flush at all. >>> >>> Is there a reason we don't do local flushing instead? I see x86 and KVM >>> use the same flush-all design on wrap, so I assume there's a reason I'm >>> missing, I'd like to understand it. >> >> What do you mean here by "local flushing instead"? We are doing local flush: >> >> if ( unlikely(need_flush) ) >> local_hfence_gvma_all(); >> >> Do you mean why we don't do hfence_gvma only for specific VMID? >> >> A vCPU's VMID is valid only while vmid->generation == data->generation >> (vmid.c:141). Bumping the generation invalidates every vCPU's VMID on >> this hart simultaneously, so every G-stage entry in the TLB (whatever >> number it is tagged with) belongs to a (vcpu, vmid) binding that can >> never be consulted again. Each of those vCPUs will be handed a fresh >> number on its next vmenter before it can run. >> >> That includes the current vCPU, which is the case you're worried about. >> At the wrap it is being assigned VMID 1, not its previous number, so its >> old entries are unreachable regardless of whether we flush them. >> hfence.gvma per retired VMID would preserve them physically but not >> usefully [A concrete example. vCPU A is running on the hart with >> VMID=100 in generation G; the TLB holds G-stage entries tagged VMID=100. >> A wrap occurs: the generation becomes G+1, next_vmid is reset to 1, and >> A is assigned VMID=1 (vmid.c:154). From that moment on, the hardware >> looks up translations for A under the tag VMID=1. The entries tagged 100 >> will no longer match anything: A isn't 100 any more, and no one else >> will be handed 100 until the next wrap. >> So A loses its warm entries not because we did an hfence.gvma, but >> because it was renumbered. The flush has nothing to do with it. It >> merely discards what has already become unreachable.]; they'd just >> occupy TLB capacity until natural eviction. Preserving them would >> require a different allocator that keeps a vCPU's number stable across a >> rollover (Linux/KVM-arm64 style, with an active/reserved set pinning >> live ASIDs), not a different flush granularity. >> >> So x86's hvm_asid_handle_vmenter() and KVM's equivalent aren't doing >> this out of inertia — with a round-robin generation allocator, the full >> flush is free of useful collateral damage and strictly cheaper than the >> alternative. Preserving entries across a rollover is a real >> optimisation, but it's an allocator change, and IMO worth doing only if >> profiling shows the wrap flush matters. >> >>> >>>> H/VS CSRs, virtual timer and P2M context, and __context_switch() in assembly, >>>> which switches Xen's own callee-saved state (and thereby the stack) from >>>> prev to next. Virtual interrupt controller context switch will be >>>> introduced later. >>>> >>>> Add offsets of struct arch_vcpu's xen_saved_context to asm-offsets.c for >>>> use by __context_switch(). >>>> >>>> henvcfg and htimedelta are 64-bit on both RV32 and RV64, so store them as >>>> uint64_t and use csr_{read,write}64() instead of open-coding accesses to >>>> the high halves. >>>> >>>> A hart which drops out of a domain's dirty_cpumask stops being a target >>>> of p2m_tlb_flush() while its TLB may still hold G-stage translations of >>>> that domain, and neither the vCPU which just ran nor any other vCPU of >>>> that domain which ran there earlier has had its VMID invalidated. Move >>>> the hart to a new VMID generation at that point: a VMID number is never >>>> re-used until a full local flush has happened, hence none of those >>>> translations can be reached again. >>>> >>>> Claim the VMID in p2m_ctxt_switch_to() rather than at the next guest >>>> entry. VMIDs are a per-hart resource, so the (generation, vmid) pair a >>>> migrating vCPU brings from another hart is meaningless here and may even >>>> match this hart's current generation, leaving the vCPU under a VMID owned >>>> by another domain. ctxt_switch_to() invalidates that pair, but claiming a >>>> replacement only on guest entry is too late: p2m_ctxt_switch_to() has by >>>> then already made HGATP live, and speculation can populate G-stage entries >>>> of the incoming domain under the stale VMID. The local flush for a wrapped >>>> generation moves along with the claim. >>>> >>>> That leaves p2m_handle_vmenter() with nothing to do, so drop it together >>>> with its call from check_for_pcpu_work(). A VMID can only be invalidated >>>> while its vCPU isn't running: vmid_flush_vcpu() is called for the vCPU >>>> being switched in, and vmid_flush_hart() runs either from schedule_tail(), >>>> ahead of ctxt_switch_to(), or from the wrap path of vmid_handle_vmenter() >>>> itself. A P2M change on another hart doesn't invalidate it either, as >>>> p2m_tlb_flush() drops the stale entries directly with >>>> sbi_remote_hfence_gvma() instead of retiring the VMIDs which tag them. A >>>> guest therefore always runs under the VMID claimed on its way in, and >>>> there is nothing left for a guest entry hook to notice. >>>> >>>> p2m_handle_vmenter() also skipped the HGATP write when the VMID it claimed >>>> was unchanged. That isn't carried over: HGATP holds the G-stage root as >>>> well, and skipping the write is only correct where that root is already >>>> the incoming domain's. On the guest entry path it is, on the context >>>> switch path it is not. >>>> >>>> While at it, fix the inclusion order of headers in asm-offsets.c: Xen's >>>> headers go first, then arch specific ones. >>> This could have a dedicated patch no? >> >> It could but considering that it is pretty small fix I think it could be >> part of this patch. If you are insisting on moving that to separate >> patch I will happy to do that. >> >>>> Signed-off-by: Oleksii Kurochko >>>> >>>> diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c >>>> index ec327a5e8a..91a46d630f 100644 >>>> --- a/xen/arch/riscv/domain.c >>>> +++ b/xen/arch/riscv/domain.c >>>> @@ -11,9 +11,11 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> #include >>>> #include >>>> #include >>>> +#include >>>> #include >>>> >>>> struct csr_masks { >>>> @@ -158,6 +160,8 @@ int arch_vcpu_create(struct vcpu *v) >>>> if ( is_idle_vcpu(v) ) >>>> return 0; >>>> >>>> + v->arch.last_cpu = NR_CPUS; >>>> + >>>> vcpu_csr_init(v); >>>> >>>> if ( (rc = vcpu_vtimer_init(v)) ) >>>> @@ -329,6 +333,169 @@ int arch_domain_create(struct domain *d, >>>> return rc; >>>> } >>>> >>>> +static void save_csr_regs(struct vcpu *vcpu) >>>> +{ >>>> + /* >>>> + * There is no need to save these CSRs as only hypervisor writes them in >>>> + * restore_csr_regs() and guest can't access them so they shouldn't be >>>> + * stored here. Keep them commented here just for symmetry with the >>>> + * restore CSRs register part. >>>> + * >>>> + * vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); >>>> + * vcpu->arch.hideleg = csr_read(CSR_HIDELEG); >>>> + * vcpu->arch.henvcfg = csr_read64(CSR_HENVCFG); >>>> + * vcpu->arch.hcounteren = csr_read(CSR_HCOUNTEREN); >>>> + * vcpu->arch.htimedelta = csr_read64(CSR_HTIMEDELTA); >>>> + * >>>> + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >>>> + * vcpu->arch.hstateen0 = csr_read(CSR_HSTATEEN0); >>>> + */ >>>> + >>>> + vcpu->arch.hvip = csr_read(CSR_HVIP); >>>> + >>>> + vcpu->arch.vsstatus = csr_read(CSR_VSSTATUS); >>>> + vcpu->arch.vsie = csr_read(CSR_VSIE); >>> >>> >>>> + vcpu->arch.vstvec = csr_read(CSR_VSTVEC); >>>> + vcpu->arch.vsscratch = csr_read(CSR_VSSCRATCH); >>>> + vcpu->arch.vscause = csr_read(CSR_VSCAUSE); >>>> + vcpu->arch.vstval = csr_read(CSR_VSTVAL); >>>> + vcpu->arch.vsepc = csr_read(CSR_VSEPC); >>>> +} >>>> + >>>> +static void restore_csr_regs(struct vcpu *vcpu) >>>> +{ >>>> + csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); >>>> + csr_write(CSR_HIDELEG, vcpu->arch.hideleg); >>>> + csr_write(CSR_HVIP, vcpu->arch.hvip); >>>> + csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); >>>> + csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); >>>> + csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); >>>> + >>>> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >>>> + csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); >>>> + >>>> + csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); >>>> + csr_write(CSR_VSIE, vcpu->arch.vsie); >>> >>> >>>> + csr_write(CSR_VSTVEC, vcpu->arch.vstvec); >>>> + csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); >>>> + csr_write(CSR_VSCAUSE, vcpu->arch.vscause); >>>> + csr_write(CSR_VSTVAL, vcpu->arch.vstval); >>>> + csr_write(CSR_VSEPC, vcpu->arch.vsepc); >>>> +} >>>> + >>>> +static void ctxt_switch_from(struct vcpu *p) >>> Is it expected to have diverse names for the vcpu arg? Above it's vcpu, >>> here it's p (I assume it's for `previous` but I think the _from alone is >>> enough to understand) and below it's n. Shouldn't be better to keep the same name? >> >> Above should be used n. > > Why would that be? n in such contexts stands for "next", while here > it can only be "previous". Sorry for confusion. I meant for restore_csr_regs() and correpondingly p for save_csr_regs(). I will also renaim the function to cxt_switch_to/from style. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 08 09:20:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 09:20:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411208.1641907 (Exim 4.92) (envelope-from ) id 1x3rzu-0005B1-5C; Tue, 08 Sep 2026 09:20:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411208.1641907; Tue, 08 Sep 2026 09:20:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3rzu-0005Au-2G; Tue, 08 Sep 2026 09:20:10 +0000 Received: by outflank-mailman (input) for mailman id 1411208; Tue, 08 Sep 2026 09:20:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3rzt-0005Ao-0M for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 09:20:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3rzs-00BDnZ-D3 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 11:20:08 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fd33d-e002-0a2a0a5209dd-0a2a450ca638-18 for ; Tue, 08 Sep 2026 11:20:08 +0200 Received: from [209.85.218.46] (helo=mail-ej1-f46.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fd348-f479-0a2a450c0019-d155da2ec50c-3 for ; Tue, 08 Sep 2026 11:20:08 +0200 Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-c259e5c22ffso348524266b.1 for ; Tue, 08 Sep 2026 02:20:08 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2624eb1813sm453768766b.38.2026.09.08.02.20.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 02:20:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788859208; x=1789464008; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=jnCLKJ77mUMpT3mH8mFEo/V++A6Zz0zlernPGtB6I+w=; b=aa3gPBX6G0xDy9z13dEuxWx5jELM3ZfaVnHE1i0b/ZBHwOao8p+kcb1TAB3hUKM7mr eq2kz40+M/m9TtXpqCvmsQ+IBC6W5eb4eGAMpH9xjz8zEdYxqPQwahfYznuBlJOgm+J/ RzZQlmrZCqFyLQyLrDGziNg3eqxvL0e0jUV4WhsLipDF3o4vyxIOzl1CAq28byXgipg6 43dyJjB6bpni3Em+abbzBeOEB8FxAvtvsLa8H8Lm1X3YGm49TFQhhj9A3w01OEBr+X4d 6MFkAs3ZtjOak8R2iQiDn5CSzgL+Wf5vy2pW6MatWeTCvN+CUHujA7T8gQoIRe4Pi9g3 0xgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788859208; x=1789464008; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=jnCLKJ77mUMpT3mH8mFEo/V++A6Zz0zlernPGtB6I+w=; b=Vh03TTJT0ZT9m5xY7rpRBuoNrfcrmaBUMd1T3Mer5rftvRUTLdYY1fL/bZ4D11+p/Y PsOShn+3seklAa+7i3roqWpKu+Kz0seqiNfS554iaY+6XRG/+NhlAgi4ZW2TwbzO1QQ6 j6doQ8+QrPUhA13mNo8ZzJL5fX2tV89WdMVsi2S5EBIWBhEglyZg9s/H2SkZpTiSL3ei tQSLOrs2KxF/0aZ4FbPh5zP8qjjxuF6GeL4OHlob/7+pITkvaCcgopan5jXVTtUQ3B8y XBloeoX/XlMvgLMfav5vlFhkolMVlz/29y5DevVik53ZZ0s0uj7hi+yHl6Yswe32RTYl GQZg== X-Gm-Message-State: AFuF++nl95euuXOIBGBYjtVMO1b6IdAh9EPcVhyrWRFqsdqKj0Va8SUw YKxBSRR0OP/zGAFtWPl0JuI9hWMzIAHHOobMjJfzrwD3I5CBujdwEMPX X-Gm-Gg: AYBFou0u77B3N/j5O9v5kgJPhMlGtESMWnKck6ANX3XmzdOojVg1116QFdSsJXfLra/ nlY7lCcnouH+B4klXGjpvNuNa+jKoyp+BwiD3Qg//YVV7+kLXevthJYHa4mzwvT3oLzQ8MejNXW WGZvNe+5R6FrNAnkwpQMz2PRGxNMyt8sV38BmqsegdO1ZX7dzRAacTAX2j7+OPEGnV4oAFtqcYw 7qaGOTfywLhGIx/5aCUXRrGQSu3UGD2uXJ5VIY2yU/CYHf64ZVvz5/z+846Sh/JSyLMyQVNybRC zB32Ldm86Y6/hypAQ6HnvL27fE6F0saCEAytkWgeV1WM7OI4vWK4J9J+Ik6kURjZQf3nXqae5ku TKFPHhrWGcNgYs1M1P8vD9cHe9TtKueaftuboBy2n85DMxtuz5iMNr7J+PUVEJ1B1ggUhGvCwMS BTfeHB2VAVYuz1EGiN6Ohg2UUfF4o/HWMYqx+Yij4CP9nXVga7RcthgKXbTYwK6vRKSWOmNNUEA 37PE9+zPz7EDPKLotxPow== X-Received: by 2002:a17:907:94c7:b0:c1c:3b06:ed03 with SMTP id a640c23a62f3a-c260cb54617mr1090264466b.23.1788859207724; Tue, 08 Sep 2026 02:20:07 -0700 (PDT) Message-ID: <11432bb6-009c-4563-9339-ddfbed1b50dc@gmail.com> Date: Tue, 8 Sep 2026 11:19:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> <1788796633.8631fc262581453bbf619ec5b2062170.1a07c968185000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788796633.8631fc262581453bbf619ec5b2062170.1a07c968185000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788859208-52132A5B-15722E92/10/73395122804 X-purgate-type: spam X-purgate-size: 12663 On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >> Extend the RISC-V exception table format to include a type and >> auxiliary data field. >> >> The existing format only supports simple fixups. Some use cases require >> additional context from the fault (e.g. capturing trap information), >> which cannot be expressed with the current EX_TYPE_FIXUP entries. >> >> Introduce a generic ASM_EXTABLE_RAW() helper to describe entries with a >> handler type and associated data. Reimplement ASM_EXTABLE() in terms of >> it using EX_TYPE_FIXUP for compatibility. >> >> Add EX_TYPE_TRAP_INFO to allow handlers to retrieve trap state >> (sepc/scause/stval) and pass it to the fixup path. The data field is >> used to encode which GPR contains a pointer to a struct trap_info. >> >> Provide ASM_EXTABLE_TRAP_INFO() as a convenience wrapper for this case. >> >> Also add gpr-num.h, providing symbolic GPR numbers for use in assembly >> and inline asm. This is derived from Linux 6.16 with minor adjustments such >> as using .irp instead of open-coding the same using a set of .equ. >> >> Update the exception handling code to dispatch based on the entry type. >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/extable.c b/xen/arch/riscv/extable.c >> index 5b89c4278c..6470198d01 100644 >> --- a/xen/arch/riscv/extable.c >> +++ b/xen/arch/riscv/extable.c >> @@ -6,8 +6,10 @@ >> #include >> #include >> >> +#include >> #include >> #include >> +#include >> >> #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field) >> >> @@ -32,6 +34,12 @@ static void __init cf_check swap_ex(void *a, void *b) >> >> x->fixup = y->fixup + delta; >> y->fixup = tmp.fixup - delta; >> + >> + x->type = y->type; >> + y->type = tmp.type; >> + >> + x->data = y->data; >> + y->data = tmp.data; >> } >> >> static int cf_check cmp_ex(const void *a, const void *b) >> @@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_table_entry *ex, >> regs->sepc = ex_fixup(ex); >> } >> >> -bool fixup_exception(struct cpu_user_regs *regs) >> +#define CHECK_GPR_INDEX(num, name) \ >> + BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) \ >> + != (num) * sizeof(unsigned long)); >> + >> +static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, >> + unsigned int num) >> +{ >> + /* >> + * The GPR number -> struct index mapping below relies on x0..x31 being >> + * laid out at the start of struct cpu_user_regs in architectural order, >> + * matching the register numbers GPR_LIST() hands to the assembler. >> + */ >> + GPR_LIST(CHECK_GPR_INDEX) >> + >> + ASSERT(num < 32); >> + >> + return ((const unsigned long *)regs)[num]; >> +} >> + >> +#undef CHECK_GPR_INDEX >> + >> +static void ex_handler_trap_info(const struct exception_table_entry *ex, >> + struct cpu_user_regs *regs, >> + unsigned long cause) >> +{ >> + struct trap_info *trap_info = >> + (struct trap_info *)regs_get_gpr(regs, ex->data); >> + >> + BUG_ON(!trap_info); >> + >> + /* >> + * Only stval still needs a CSR read: sepc and scause were already >> + * captured by the trap entry path and do_trap() respectively. Latch >> + * trap_info->sepc before regs->sepc is pointed at the fixup code. >> + */ >> + trap_info->sepc = regs->sepc; >> + trap_info->scause = cause; >> + trap_info->stval = csr_read(CSR_STVAL); >> + >> + regs->sepc = ex_fixup(ex); >> +} >> + >> +bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause) >> { >> unsigned long pc = regs->sepc; >> const struct virtual_region *region = find_text_region(pc); >> @@ -77,7 +127,23 @@ bool fixup_exception(struct cpu_user_regs *regs) >> if ( !ex ) >> return false; >> >> - ex_handler_fixup(ex, regs); >> + switch ( ex->type ) >> + { >> + case EX_TYPE_FIXUP: >> + ex_handler_fixup(ex, regs); >> + break; >> + >> + case EX_TYPE_TRAP_INFO: >> + ex_handler_trap_info(ex, regs, cause); >> + break; >> + >> + default: >> + printk(XENLOG_ERR >> + "Unsupported exception table entry type %u for pc %#lx\n", >> + ex->type, pc); >> + >> + return false; >> + } >> >> return true; >> } >> diff --git a/xen/arch/riscv/include/asm/extable.h b/xen/arch/riscv/include/asm/extable.h >> index c0128a9181..7378f86e7e 100644 >> --- a/xen/arch/riscv/include/asm/extable.h >> +++ b/xen/arch/riscv/include/asm/extable.h >> @@ -3,17 +3,24 @@ >> #ifndef ASM__RISCV__ASM_EXTABLE_H >> #define ASM__RISCV__ASM_EXTABLE_H >> >> +#include >> + >> +#define EX_TYPE_FIXUP 0 >> +#define EX_TYPE_TRAP_INFO 1 >> + >> #ifdef __ASSEMBLER__ >> >> -#define ASM_EXTABLE(insn, fixup) \ >> - .pushsection .ex_table, "a"; \ >> - .balign 4; \ >> - .word (insn) - .; \ >> - .word (fixup) - .; \ >> +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ >> + .pushsection .ex_table, "a"; \ >> + .balign 4; \ >> + .word (insn) - .; \ >> + .word (fixup) - .; \ >> + .half (type); \ >> + .half (data); \ >> .popsection >> >> -.macro asm_extable, insn, fixup >> - ASM_EXTABLE(\insn, \fixup) >> +.macro _asm_extable, insn, fixup >> + ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0) >> .endm >> >> #else /* __ASSEMBLER__ */ >> @@ -23,20 +30,36 @@ >> >> struct cpu_user_regs; >> >> -#define ASM_EXTABLE(insn, fixup) \ >> - ".pushsection .ex_table, \"a\"\n" \ >> - ".balign 4\n" \ >> - ".word (" #insn " - .)\n" \ >> - ".word (" #fixup " - .)\n" \ >> +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ >> + ".pushsection .ex_table, \"a\"\n" \ >> + ".balign 4\n" \ >> + ".word (" insn ") - .\n" \ >> + ".word (" fixup ") - .\n" \ >> + ".half (" type ")\n" \ >> + ".half (" data ")\n" \ >> ".popsection\n" >> >> +#define ASM_EXTABLE(insn, fixup) \ >> + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_FIXUP), "0") >> + >> +#define EX_TRAP_INFO_REG(gpr) \ >> + "(.L_gpr_num_" #gpr ")" >> + >> +#define ASM_EXTABLE_TRAP_INFO(insn, fixup, data) \ >> + DEFINE_ASM_GPR_NUMS \ >> + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_TRAP_INFO), \ >> + EX_TRAP_INFO_REG(data)) >> + >> /* >> - * The exception table consists of pairs of relative offsets: the first >> - * is the relative offset to an instruction that is allowed to fault, >> - * and the second is the relative offset at which the program should >> - * continue. No general-purpose registers are modified by the exception >> - * handling mechanism itself, so it is up to the fixup code to handle >> - * any necessary state cleanup. >> + * Each exception table entry consists of two relative offsets and a >> + * handler description: `insn` is the relative offset to an instruction >> + * that is allowed to fault, `fixup` is the relative offset at which the >> + * program should continue, `type` selects how the exception is handled >> + * (EX_TYPE_*), and `data` holds auxiliary information for the handler >> + * (e.g. for EX_TYPE_TRAP_INFO, the number of the GPR that contains a >> + * pointer to a struct trap_info). No general-purpose registers are >> + * modified by the exception handling mechanism itself, so it is up to >> + * the fixup code to handle any necessary state cleanup. >> * >> * The exception table and fixup code live out of line with the main >> * instruction path. This means when everything is well, we don't even >> @@ -45,14 +68,15 @@ struct cpu_user_regs; >> */ >> struct exception_table_entry { >> int32_t insn, fixup; >> + uint16_t type, data; >> }; >> >> extern struct exception_table_entry __start___ex_table[]; >> extern struct exception_table_entry __stop___ex_table[]; >> >> void sort_exception_tables(void); >> -bool fixup_exception(struct cpu_user_regs *regs); >> +bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause); >> >> -#endif /* __ASSEMBLY__ */ >> +#endif /* __ASSEMBLER__ */ >> >> #endif /* ASM__RISCV__ASM_EXTABLE_H */ >> diff --git a/xen/arch/riscv/include/asm/gpr-num.h b/xen/arch/riscv/include/asm/gpr-num.h >> new file mode 100644 >> index 0000000000..3b97a72e6c >> --- /dev/null >> +++ b/xen/arch/riscv/include/asm/gpr-num.h >> @@ -0,0 +1,37 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +#ifndef RISCV_GPR_NUM_H >> +#define RISCV_GPR_NUM_H > Nit: commit message says this is derived from Linux 6.16. Other > imported RISC-V headers here carry an in-file note (bitops.h: "Based on > linux/arch/.../bitops.h") but this file doesn't. >> +/* >> + * GPRs by ABI name, together with their register number (x0 .. x31). >> + * >> + * This is the single source of truth for the mapping: it generates the >> + * .L_gpr_num_ assembler symbols used to turn a register name emitted >> + * by the compiler into a register number, and struct cpu_user_regs is >> + * checked against it at build time (see regs_get_gpr()). Neither list can >> + * therefore be changed without the other. >> + */ >> +#define GPR_LIST(x) \ >> + x(0, zero) x(1, ra) x(2, sp) x(3, gp) \ >> + x(4, tp) x(5, t0) x(6, t1) x(7, t2) \ >> + x(8, s0) x(9, s1) x(10, a0) x(11, a1) \ >> + x(12, a2) x(13, a3) x(14, a4) x(15, a5) \ >> + x(16, a6) x(17, a7) x(18, s2) x(19, s3) \ >> + x(20, s4) x(21, s5) x(22, s6) x(23, s7) \ >> + x(24, s8) x(25, s9) x(26, s10) x(27, s11) \ >> + x(28, t3) x(29, t4) x(30, t5) x(31, t6) >> + >> +#ifdef __ASSEMBLER__ >> + >> +#define GPR_NUM_EQU(num, name) .equ .L_gpr_num_##name, num; >> +GPR_LIST(GPR_NUM_EQU) >> +#undef GPR_NUM_EQU >> + >> +#else /* __ASSEMBLER__ */ >> + >> +#define GPR_NUM_EQU(num, name) ".equ .L_gpr_num_" #name ", " #num "\n" >> +#define DEFINE_ASM_GPR_NUMS GPR_LIST(GPR_NUM_EQU) >> + >> +#endif /* __ASSEMBLER__ */ >> + >> +#endif /* RISCV_GPR_NUM_H */ >> diff --git a/xen/arch/riscv/include/asm/processor.h b/xen/arch/riscv/include/asm/processor.h >> index b1745c1071..e7b0f2321a 100644 >> --- a/xen/arch/riscv/include/asm/processor.h >> +++ b/xen/arch/riscv/include/asm/processor.h >> @@ -12,7 +12,19 @@ >> >> #ifndef __ASSEMBLER__ >> >> -/* On stack VCPU state */ >> +/* >> + * On stack VCPU state. >> + * >> + * x0..x31 must remain at the start of this structure, in architectural >> + * register-number order: code which resolves a register number to its saved >> + * value indexes this structure directly (instruction emulation via >> + * REG_PTR() from asm/riscv_encoding.h, exception table fixups via >> + * regs_get_gpr()). ->zero therefore has to stay at offset 0 and must always >> + * read as 0, since it supplies the value of x0 when x0 is used as a source >> + * operand. The layout is checked against GPR_LIST() at build time; see >> + * regs_get_gpr() in extable.c. Do not reorder these fields or insert >> + * anything between them. >> + */ >> { >> unsigned long zero; > Comment claims ->zero "must always read as 0" as it's hard-wired to zero > by the HW, but nothing enforces that, it's still a plain writable > unsigned long. Maybe a write-side counterpart that special-cases num==0 > as a no-op, or with a minimum ASSERT(num != 0) / BUG_ON(num == 0) to > anticipate any future forbidden writes. > Could you please clarify where do you want me to put this check in this patch? In regs_get_gpr()? There is no write-side in this patch. Am i missing something? Thanks in advance. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 08 09:27:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 09:27:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411221.1641920 (Exim 4.92) (envelope-from ) id 1x3s6V-0005oN-To; Tue, 08 Sep 2026 09:26:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411221.1641920; Tue, 08 Sep 2026 09:26:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3s6V-0005oG-Qw; Tue, 08 Sep 2026 09:26:59 +0000 Received: by outflank-mailman (input) for mailman id 1411221; Tue, 08 Sep 2026 09:26:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3s6U-0005oA-6f for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 09:26:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3s6T-003LQY-JN for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 11:26:57 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fd4db-e002-0a2a0a5209dd-0a2a4504b176-38 for ; Tue, 08 Sep 2026 11:26:57 +0200 Received: from [52.101.62.6] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fd4df-b57f-0a2a45040019-34653e067d64-4 for ; Tue, 08 Sep 2026 11:26:57 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by LV8PR03MB7376.namprd03.prod.outlook.com (2603:10b6:408:18b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.6; Tue, 8 Sep 2026 09:26:53 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.014; Tue, 8 Sep 2026 09:26:53 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=j8/lBlIEjayLSegD7LL5zfUp9GIM/aRy/qo/uBBUFPvY70InDJEdQIXTs2KgZSt6C7zjZgHkBZBgoYvUIWOU8uouCvJJ5Q3SGWPIllQcNBwdckUokhLl6W98YYN0OX+WCAY8k+Uyj19NafZEMLbdbvo6y2NUVw8auLVOtYv/GN5FfEsJDbzBYxrLD+/q1jn0itnWLNKQBcdJI6YUcD+YhEWcPQ3yYRoObHVhC9FKs6hq8uBioq8OVstU8oh7vBqtTe5BwEHqlLW9KMfeGXBrnwXhV+VOn6h70qI8/FGKezcLQuprul9l4GXRjVXvl1QRQTKpuPNPLeGhOMAYby/wiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XG3OLYfogiIpj1NnZTtoGu3tcU7fDM3bO+5n2zd3SYs=; b=h4/EgOJTHyUH+j7KkZmuZi5K9WkACmrgDWvLPTaWzYFODEk4D9ZdiUqkBuG1rCYHmXZpImeXzx1BZmYfuhZ5WBRsD2ETUClbf8biIfWO4HgRUQ+4KUGmWSAfGWniGg2CS2jLZR+9hpw/06uwFYbyI21qbtbkEw1O/Wja3R40EPj+Shq9YqV47SH544VdKJZI7rRh1HFtl7UF8sc0uRRJ0QeffnOtx4etGWIjFH7YLynMK+xabTwwgshRziNW/uihhPHtwwywLEcJ66FAyQ063kBvI0AkpfANofd8QE9kIO8KjOEB7w+cPlcEYPFFyDf0muSBHVIU+uaxrLBR/NmGKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XG3OLYfogiIpj1NnZTtoGu3tcU7fDM3bO+5n2zd3SYs=; b=yg5hEKmvu2rFkdD1XW0TO0KwADGbHyQ4rJEX1xfycQlZDlHXHyAJrvTRZ3ya0NEp4tNYbyPbBAzHX6yJ2/Ovtj7QD9c1iu5wekToup1mRFroM6WTQ9Th+r/UdBc0mmZBbK1W6LTIwRZiuKEiAC2FbCMz4QoVzYebWCuxXdI5IzI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3b899e5e-b434-40b4-a87c-0a4984462689@citrix.com> Date: Tue, 8 Sep 2026 10:26:48 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/3] x86/viridian: Workaround Hyper-V GP fault writing to MSR To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Paul Durrant , Jan Beulich , Andrew Cooper , Teddy Astie References: <20260904141516.367862-1-ross.lagerwall@citrix.com> <20260904141516.367862-2-ross.lagerwall@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0056.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:153::7) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|LV8PR03MB7376:EE_ X-MS-Office365-Filtering-Correlation-Id: c92e8efd-9a6a-425a-f4d1-08df0d8b51ab X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|10067099003|18002099003|22082099003|11063799006|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: k9tglt9ivsnnD9vTvH90CLeIqkMSsSGZHZHAsEv7PBYQA68ydBZBOLKhS1pnLAZGyDiWCVsg7xJOGNg6oY3yMvtoMvWoSt9Ng1bWtNwlKsR7K1WyoD1nFb7cNGejGebapQ386ovcYRTk8oqqIxPaTqAbvLIuUQueZMpIwKoPWixgXSc1JxFWA4hTHCU88dcp0e0HHJgIVoqUtrIWZVZxVG8qW5NH2v+Bdzp8Wn6L4+lV1XS3Erfa5Wuj+CCzIvZ0uE+moA/7ehDt29bmt9Ht1aeAuKSgBZLoYGyN3KyF4v0oBGrlPqTh0I8WTzqmsM2B2jgcyiXkVXH0jqlctM5WPiW0H8TdX6J2LSgpiGW/F6iqm2AZVI65Ca8gCDHucVHJYpNksETdrb438k52lNVyHsXoz5TbHxxifk6SsnvnFoJ3AbDSPnP31hmJnhb+MMxZQaBCWBWqirX4286p0sX9f0DlJHPNgGUMo0OCUTTCHxjmUoTGgN+T2g4KVfbqndyn5vQRQ30eWN1DARY9/7YJUBhEErUJ8lmALKTJdrmPYJhOsZAW63+zH63VkjiJ4FajD+DHRwpVtdBFZmNH0z40lqkGxcR/2kKfcpFANeM/7tKbxIg1q0AL1qtYxZVAazB630lIrz8PFD8a8zjlyvnWbA== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(10067099003)(18002099003)(22082099003)(11063799006)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?anQ5RzAvWEYxVUdlUFk1MnByVE0rUm1iWS9NbzNjVjMza0kzVldoZXNvNmhJ?= =?utf-8?B?amZxdUZWQ2d3N2NzbURib29qd1NTVStBZGl5dkdjSXNDUWNhUEFSNldnNlRx?= =?utf-8?B?TEMrKy9nNU0zaU56S2ppMDFFUytlajlreFUvaVR6ZGFvQm9HQmdpUHZiU0kw?= =?utf-8?B?VkRWSi9Sc1VWclY1VHVpZjg4N0FVZ1lpRWpYdGx1VlVQT0NOZ3FKTnVTbCtX?= =?utf-8?B?dFZaY2pSckhMYit5TXBVTkFtYS92OEdZeDgxandYUWExQk4vOE1vaVNONGRL?= =?utf-8?B?VzBpQ1N6M25NWVR6Q0M1dVZiZEtaU1EwRzJwN0NqVk9RcVBYODdDS1Jic0s1?= =?utf-8?B?aTU1Z0NoUVoraTZVY21yeEkwVGpJaGNrMEF4czVEY201UkxOU0c2WUZQY25r?= =?utf-8?B?VkhqcVo4bHFoNkdLak5QbGRlZ3RsdUtDQm9WRDMxWlp5cisvZU04aWhjK2Y1?= =?utf-8?B?eWRBeUxwYUk0R2UvRWJzOEROV2psUytvL2U4MEZ6NWVGSW5KS0pVR2pIblVt?= =?utf-8?B?bHdlS3ZEaEJZNUkwMlI5RnRndmNWZHBHNVVoMjRDTEJiUVdMOW12QjdaMU9Y?= =?utf-8?B?eURFMnJJK2doREJYdDVIN0IxYUJabGJUSGF5Uldpek8wVzhKM0huYmFyZ3ds?= =?utf-8?B?SmtIVkFwcXF3b0tDcVlqSVE1SzJHTnpKVHo5SEo1RWFZL0xoNUtnR3ZXYXhu?= =?utf-8?B?MSt3ZlhWb3FKVWlMeFU1SU9aZ0tSQWJncVRVVnBBV01OaTl6ekJ0ZGJYYktO?= =?utf-8?B?S2pFcUpXS0g4SVRieENMcXEwSEJSWEdWVkZnWDVwNlJjRmhsalpJNGJ3WmRP?= =?utf-8?B?MXo0Q3FUVmtZNCttMzRscERlVzVMRENIVHcxOE9XY21kSElBZ3lTNUw1UlVo?= =?utf-8?B?VGpnR0hpNTB5MEpQcHh1eEtGK2Nxc09rUVU4TkEzeVhEWlJWcXdIUE1SV1dS?= =?utf-8?B?VDk0OGdrem9zTkpheENpWndwU21IblRiYUJ4NFJUQXA3cmJPRlB6R0JpY0Ju?= =?utf-8?B?SElHQi9oNS9GbXBNMXU4a3ZRV0cwcWZNVzFBL0YraGJ6U1F1WGE2V1lKeU9M?= =?utf-8?B?b1FlTzVPbllrZURXb1JxVnluM3RyYUNwWlBjVlI0L09zUGRBRnZ3SXVxeGVa?= =?utf-8?B?bnBMQzhoRmg2UDAvbWJjTlhlV3UvajRKL2M1WVBLZU5zcSsrVmo3SVJjdGp6?= =?utf-8?B?R0p2TjFSTms2aVFWNzhUc2Z1TWs0cnlPZm1UeHF0eTZudnBpSE5EUzZvaFpW?= =?utf-8?B?VXZCWHkyVWs4YjZlSENPV3FGNXFrbDloOWJLdjhMZXV2bHhPa1QrczhvOVNS?= =?utf-8?B?UU9tdGsyMUJUU0Q5TjdYN1haL2pNcDBUbHBRSlF3dmZaYlZaNFZsSW1WakN1?= =?utf-8?B?MTFqU05DNE00NEVYZ3h6Wk53V1ozUnVkdVR6Nzc2aGJDQ085dFpLK2RYSEpU?= =?utf-8?B?NzdFSzc5bjFoekRFc3hiOW51V2FqNU5FSFN5NmhOMFdSR0k4U2pEa21KUDJR?= =?utf-8?B?bTlEcUl6U0dZQ1ZJZXZpcWFCMDhNR1h2WGg0RjBmMzA3TU9ucDBZMjBQRFp4?= =?utf-8?B?aXloOE9zSTBIWDI3MWNqa0JSYzlEOGVKMWpLS0NtaklVK0FRdTFrWEw5aWl2?= =?utf-8?B?T1g1TVhvUFNHbmxmejNuUk5BblQ5NDJEZkluQlF5RlFYR2RtWGV5eU9TS2w2?= =?utf-8?B?VTFIbkQ4ZGd3STFybGw2MHhWQ3RVRjJkN1ljVXZxKzNick1KQVVQWmttdmth?= =?utf-8?B?Z3d3MWtpRkF2SWJDTDJMOFE5Y0dvREZMZVhUajhyUTNiR0krM3VjSFhBbmE5?= =?utf-8?B?WlNoVDBjN09UaW15QVo1MENtdzcya3k4RzlhU25VT0JMNEJKaUZuMUVpT2lB?= =?utf-8?B?Z00zOTkxL3I4dkhNT1gxV21yU3BJVGxFVXl4WC9RY1E2THN0dll4SlFxRzVB?= =?utf-8?B?MSs5TDh3TzhkeVZiT3BnQ1JJWWpDM1lOYjJ0ZnI5azU1MDB5b3duL1ZaSlhC?= =?utf-8?B?Ri9ub0tiNWJHeDYzYnoxVU54SVdEOEE2SENzanZJeTkrZ1NkdjVwR3Y2SnRl?= =?utf-8?B?WTN0bCtPOGdiWEExYUdPTnR5SDZsb3drcCtWN29UbmowbGZHUldFeGtPQXdh?= =?utf-8?B?RGZtUHkvWWFhVDhtRm9hODJ6RlJUWjNSbGwxWE5iQlcrQSt0cnM5bjJOZVhZ?= =?utf-8?B?b3BoRUxXZVpOeVVSTHN3bHBxbElUU0dvNW13ZUl1cmM5cDVsZ0xYUkxwVldk?= =?utf-8?B?QnRxQ3BYWlhvZVdpWVhuc3FBKzFDMlc0VEpwUk9iSDhoVDQ1SVlKZWVuWlpi?= =?utf-8?B?cXJuTlMrM1JsdWhFaVo4MXlUVlMzVmd3d3BlMVRNYkJDR3hEOFR3YVE5aDU5?= =?utf-8?Q?4dx+y2oR22VBzY2c=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c92e8efd-9a6a-425a-f4d1-08df0d8b51ab X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 09:26:53.3632 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fsMz6SqEnuyYEMnR9dnI+/RyGf3nDbuZc3yaYBHwmmbl1JH5NjH/YGYj3AtuvZZZTlmdivLsvfMnkcc6S9wTUhJkD71hk4/gcRXjdxjRKtU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7376 X-purgate-ID: tlsNG-ebf023/1788859617-585C7B50-A659879C/0/0 X-purgate-type: clean X-purgate-size: 1736 On 9/4/26 3:53 PM, Roger Pau Monné wrote: > On Fri, Sep 04, 2026 at 03:15:14PM +0100, Ross Lagerwall wrote: >> The Viridian spec requires the vector to be >= 0x10 when writing to the >> SINTx MSR, otherwise it should #GP fault. >> The spec-defined initial value is 0x0000000000010000, i.e. the vector is >> 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to >> the spec-defined initial value and since the vector is 0, it GP faults. >> To workaround this, treat the write as a no-op if the value is >> unchanged. >> >> Signed-off-by: Ross Lagerwall >> Acked-by: Jan Beulich >> --- >> >> In v2: Added a comment to clarify >> >> xen/arch/x86/hvm/viridian/synic.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/xen/arch/x86/hvm/viridian/synic.c b/xen/arch/x86/hvm/viridian/synic.c >> index e6cba7548f1b..75b004440e58 100644 >> --- a/xen/arch/x86/hvm/viridian/synic.c >> +++ b/xen/arch/x86/hvm/viridian/synic.c >> @@ -157,6 +157,14 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) >> if ( !(viridian_feature_mask(d) & HVMPV_synic) ) >> return X86EMUL_EXCEPTION; >> >> + /* >> + * Windows 11 Hyper-V (26H1) has been seen to write this MSR to >> + * its default value, despite not being a spec compliant value. >> + * Tolerate writes which have no change in value. >> + */ >> + if ( val == vs->as_uint64 ) >> + break; > > To make this a bit less workaround like, could we ignore the vector if > the SINT is masked (bit 16 set)? Yes, that might be better and it appears to be what KVM does. Ross From xen-devel-bounces@lists.xenproject.org Tue Sep 08 09:34:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 09:34:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411229.1641929 (Exim 4.92) (envelope-from ) id 1x3sDj-0007St-Jp; Tue, 08 Sep 2026 09:34:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411229.1641929; Tue, 08 Sep 2026 09:34:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3sDj-0007Sm-H7; Tue, 08 Sep 2026 09:34:27 +0000 Received: by outflank-mailman (input) for mailman id 1411229; Tue, 08 Sep 2026 09:34:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3sDi-0007Sg-1c for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 09:34:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3sDh-00GY4f-8A for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 11:34:25 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fd69c-8faa-0a2a0a5109dd-0a2a4509e0ba-26 for ; Tue, 08 Sep 2026 11:34:25 +0200 Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fd6a1-be1a-0a2a45090019-d155da29b03f-3 for ; Tue, 08 Sep 2026 11:34:25 +0200 Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-c2533d83e3bso754715066b.2 for ; Tue, 08 Sep 2026 02:34:25 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c26e956ea81sm376416966b.33.2026.09.08.02.34.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 02:34:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788860065; x=1789464865; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=jIXQVEUqa9D7i03beXcgoj5TiD/kN8vTM/UcnAY9lCs=; b=InxJHVkSRkPDv9aXQW763zbjTJ3RMhGjblRYYRgup2yMQk3x49BDsyYusT+yuhfTYp YIHDggYb6l7HJkOv3PuxD9FMPPFwM7D4wExZJQVUWF+933qtkunDehFs0NEpIQ2x35aI 6Y0R6yz6fvENfQ1txHUS5DzAx9RA4nHuWrnd9ZKgNITvQfC8OjP8gcZDnKgg4sJ3Odwr YhuHDBjWCeMD5j14Z17RpCxaX0s9yRU+n7f1BSc5JtkUk7kZEn6YulJZHNYhwGF88ZaN 1VOzWSDuBL8M2PFI1tPrWNngYA3g6bL7z/P3Lu+z/uXRLp+nltXvKvut37kD+oOmDRu4 ZRpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788860065; x=1789464865; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=jIXQVEUqa9D7i03beXcgoj5TiD/kN8vTM/UcnAY9lCs=; b=Orz0xg6U2J4PKWVKPMygxl65Aj7oJtXNnOOJs+bzs/AkEuXK8SYt1RTcUEnOztgIF1 Bg+8lz6RJVS6ARykEKNJdeCIY56RU2zyDe8dtlnEvuqiAj7/crF9tqUfQ5rtS/etfE2/ 9pmi+SUY2ff4/MSUGtsHJ/wh2gZPT7/CIn5+figp4slJDE1BD7h/hpr8c8dN25yvxeub lh7JulGV+KtFYnSTjSY+r8REpswzW99SXJbHEMrK9DKHAlvbrp+MuVCdRmYIkRS5nRFm HQQ7nr0ZpHy0RK314DTEIbajRnrfPtD+a++2Y1dtnuUYsWtM144g2eorCQR+WkHrfDyS MVdg== X-Gm-Message-State: AFuF++lWMjlZTtbIqfIu+Zxog47jSPvWyFTeKUTfluQ5TEXA3x9oF38h qDQpvyOiW7wfMhXi0jJclRLnVCuuNEKSaubeaBwNsK/7+sm7ItjwzUZt X-Gm-Gg: AYBFou3+h3jICC9wQ+H0YZyxL167fKxy1ArLafPS2eVZ8dAZYqYAY1H2lkp6C0R+Efb SWBkJ4Y1hYQvg2Phq/U5sQGSxodjbDsA/T+7m4tnV2l6ujG5LUxKOxxGAG9SV55dOsxtL8C8cYG 242uN7b0yUNQ/XTqC4v4so/cPStKzFTWzxdjkmYrGSKQvwB0LRm19aNPKZsM4JKiIztel6Hr0Tq 5GcpY2VixzrWMqmRFEPRks69DSOFH+78CGrxyZArQnbvf/tLLTrSsAT8zOwYgXpj5igBNCC0ZIZ p4KlSlEjQ3JflR0ipd9GTZQcxnXPQ4xeRthjZ2BP8yTrlipJ9fURbHVbgmPTs1GXbJ4x3w6za67 ZJ98aJJtT8vZl2Q3YS7bpxD/dKF+YeAJbjIGWMb2xJRxboKfykvZKz1tO7cfUS/YXgNzlypT+ep PNkqOaqSzWQyzlP781xCHGJJUAR3zomBHeeMiN/h5lfYQER0rLaymJRdhPQlbaIdQwPnG5R+hiz 4KV2bBdPdU4NHbQVbzMkQ== X-Received: by 2002:a17:907:1c25:b0:c26:337e:7e05 with SMTP id a640c23a62f3a-c26337ea2f5mr1272648166b.4.1788860064524; Tue, 08 Sep 2026 02:34:24 -0700 (PDT) Message-ID: <9a7dea59-be4a-4dbd-9935-f48e24adc009@gmail.com> Date: Tue, 8 Sep 2026 11:34:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 17/39] xen/riscv: decouple INSN_PSEUDO_VS_* from the hypervisor's XLEN To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <2a69992aa02ff114237ec27204cfac0f8278b1d6.1787838835.git.oleksii.kurochko@gmail.com> <1788796633.8631fc262581453bbf619ec5b2062170.1a07c9682ec000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788796633.8631fc262581453bbf619ec5b2062170.1a07c9682ec000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1788860065-3BCD7034-BE982E63/10/73395122804 X-purgate-type: spam X-purgate-size: 4721 On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >> htinst reports a pseudoinstruction when a guest page fault is taken on an >> implicit memory access done for VS-stage address translation. Four such >> values are defined, differing in the access type (read or write) and in the >> access width: 4 bytes (0x2000/0x2020) or 8 bytes (0x3000/0x3020). >> >> That width is the width of a VS-stage PTE, i.e. it follows the guest's >> paging mode (4 bytes for Sv32, 8 bytes for Sv39 and wider) and has nothing >> to do with the XLEN Xen itself is built for. Selecting just one pair with >> where a guest running with VSXL=32 and Sv32 in vsatp produces the 4-byte > Sentence is broken. Guess you mean "Selecting just one pair based on Xen's XLEN misses the case where > …". Likely it is becuase of my low level English but it seems that original version wast okay and what you added is just a part from prev. sentence but I will add your suggestion for better clearness. Thanks for noticing that! > >> forms. Such an htinst would not be recognized as a pseudoinstruction and the >> fault would be mistaken for an ordinary MMIO trap: Xen would fetch and >> decode whatever instruction sepc happens to point at (unrelated to the >> access which faulted) and emulate it against a guest physical address >> derived from htval, which for an implicit access holds the address of a >> VS-stage PTE rather than of any access the guest performed. >> >> Define all four values unconditionally instead, named after the access width >> they encode rather than after the build's XLEN. On RV32 the 8-byte forms >> simply never occur, so recognizing them costs nothing. >> >> Dropping the ladder loses no build-time coverage: a build for an XLEN other >> than 32 or 64 already fails on the equivalent ladders in asm/asm.h and >> asm/config.h, so no replacement #error is needed here. Adding one keyed on >> CONFIG_RISCV_* would in any case re-introduce exactly the conflation this >> patch removes. >> >> This diverges from the imported version of riscv_encoding.h. >> >> No functional change: the values have no user yet. >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h >> index c63e5e3046..2d2e7e11b3 100644 >> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >> @@ -839,25 +839,17 @@ >> #define INSN_MASK_FENCE_TSO 0xffffffff >> #define INSN_MATCH_FENCE_TSO 0x8330000f >> >> -#if __riscv_xlen == 64 >> - >> /* 64-bit read for VS-stage address translation (RV64) */ >> -#define INSN_PSEUDO_VS_LOAD 0x00003000 >> +#define INSN_PSEUDO_VS_LOAD64 0x00003000 >> >> /* 64-bit write for VS-stage address translation (RV64) */ >> -#define INSN_PSEUDO_VS_STORE 0x00003020 >> - >> -#elif __riscv_xlen == 32 >> +#define INSN_PSEUDO_VS_STORE64 0x00003020 >> >> /* 32-bit read for VS-stage address translation (RV32) */ >> -#define INSN_PSEUDO_VS_LOAD 0x00002000 >> +#define INSN_PSEUDO_VS_LOAD32 0x00002000 >> >> /* 32-bit write for VS-stage address translation (RV32) */ >> -#define INSN_PSEUDO_VS_STORE 0x00002020 >> - > Whole point of patch is these no longer depend on build XLEN, yet > comments still say "(RV64)"/"(RV32)" which could be confusing. Maybe it > should be better to indicate, as the spec does, that RV32 values are > used when VSXLEN=32 (only sv32 paging mode) and RV64 values when > VSXLEN=64 (sv39+ paging modes). > Could you please clarify to me what in the spec it is? This comments are just copy from the spec: Table 39. Special pseudoinstruction values for guest-page faults. The RV32 values are used when VSXLEN=32, and the RV64 values when VSXLEN=64. Value Meaning 0x00002000 32-bit read for VS-stage address translation (RV32) 0x00002020 32-bit write for VS-stage address translation (RV32) Value Meaning 0x00003000 64-bit read for VS-stage address translation (RV64) 0x00003020 64-bit write for VS-stage address translation (RV64) So the comments are just copy of "Meaning" column from the spec. And I think that Meaning column is fine here as we could have a case of when hypervisor has XLEN=64 but guests could be on it RV32 and RV64 and if a guest is RV32 (what means VSXLEN=32) then the comment above defintion mean that we hav 32-bit read/write VS-stage address translation for (RV32) guest and the similar is for RV64. Do I miss something? Is a comments make more sense now or I have to still update them in some way? Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 08 09:50:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 09:50:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411235.1641938 (Exim 4.92) (envelope-from ) id 1x3sSg-0000xM-Pv; Tue, 08 Sep 2026 09:49:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411235.1641938; Tue, 08 Sep 2026 09:49:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3sSg-0000xF-Ml; Tue, 08 Sep 2026 09:49:54 +0000 Received: by outflank-mailman (input) for mailman id 1411235; Tue, 08 Sep 2026 09:49:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3sSf-0000x9-Dm for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 09:49:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3sSe-009c86-1X for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 11:49:52 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fda2d-2eae-0a2a0a5409dd-0a2a450c9540-32 for ; Tue, 08 Sep 2026 11:49:51 +0200 Received: from [209.85.218.54] (helo=mail-ej1-f54.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fda3f-f479-0a2a450c0019-d155da36cd79-3 for ; Tue, 08 Sep 2026 11:49:51 +0200 Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-c1677c91969so435334466b.1 for ; Tue, 08 Sep 2026 02:49:51 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2621d3f5b6sm473789266b.45.2026.09.08.02.49.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 02:49:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788860991; x=1789465791; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=AIntCyxA5t+PensHW3kaaYXckrxkH4l4HmN3LUFeYcI=; b=jaa80YMAhcapfH7UsBs3OmQhHi4+Ymg5cMi9/J0I9AKnaDkIKAwkQtSdsIMYLxprZl vsQr3NAzV+RT7ogLw63Ga42cO7p2ghokhFvOaDe320BRatITtbNswI/iueMEKEYJ3QUu JrDCtsKNYrzfWP27gPGW/vFFByRN3xTJ4a0XD25ver28AMsb7fDph6Tt9eoShVYAT9aS DrsxmhUcM78ltBaTTRpMJ+mSZjY0qsU6lkOaYxyhh4fDbE6gSlNRmAftqzaWiRI5vaJq XuiEi0FnKZsO8ANE0mw97m1mFYj+ffmdIJcTMbTcmH+VcYMDqIfFEl1uZmh5Istuisac r/Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788860991; x=1789465791; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=AIntCyxA5t+PensHW3kaaYXckrxkH4l4HmN3LUFeYcI=; b=Dl6mDWNqpoPAXXiZFVgmTVtW8BwixWaMvBJbB9d9Z2Tdp21CETVKDv+tLGO81cHDqX Ai9sTWt0MuD05RXYpF+pY/EN2HTslRbmI/t3a+LE7A+1IywjBT20qIjjmqzuC51iriBa keIj9vj8F39GzcoMXbOEGL10dlteyu/KVPlpf/QZ5HWvA8n0MnaKJI0shuC9lEB/S7Zm g9iFKMNGZsjle3wv2J8xmBfHuN8zX/9fLq3NQyQmWBAeYoy67XxkDZU3WKlgQVk2nUs6 JAUlt+qRaAwfJW09WOgP6tyirfW92H1HAzm4UDqYQVXmcev4uMXtztJKSrJqJlFzXV6w hYbA== X-Gm-Message-State: AFuF++nUQxZ3LJjbdjAdI4bb5Tb2ZmfRkmd67puQw8F+tm6LK04HG4CT rRUBGreSFkR9S2SbIv8yPewEigPLfzNk1/yhoGepNnCjyJPSyoPs89Sp X-Gm-Gg: AYBFou0Yxo8OWQfuBALtJcmCHMeI6n2DWKBeJEhdqPAbwn+0ulHF6qLX4SyJM/E5Zrm w6KjFlakeLKJD3lLZebAaXbXXogDQ80UrB5/r4vhrDnFq9KMsUICQaxVhzjntwPnunHQIioxOvK ntdghwTDtsRdj6uESimoGBXrhEOmA/vcSCcgZIvlcQTSiEeDDwVi5QzG42WLJqP3dnC6KjILFuj Dhtj4iYsEyjq2sE4DdiLyxoonbstDaZJ6McdKzLRYvdEco/FPWrzt+WIv9DGn93rqogAZgXwoDF E+dhCUZ6kcrMVQOUKyzdG8Z3AU3d+uuLGZnRdPyfRa4a7VuP3kCdy8MK3FSAZ07DrgfCfhs7IOS 2WogWnAgdEVHWghHUb802T58F4BO2vTGHLdD0uSU2y/73eGV4NZ0b+lUcyPqJvYxnDlX5qjLuNJ mJhmQUPgdfoOzMA1mdsYIGEXLLSTAM0NoySgRE+sBZq27QtRPo+m5xQ8FRc9/Anir4QdHo8glWA 9N+W1xzL8qCexlfpN5p7ZQElUkrstH3NaQ= X-Received: by 2002:a17:907:1c22:b0:c26:1649:47a8 with SMTP id a640c23a62f3a-c26164956d1mr947596266b.30.1788860991058; Tue, 08 Sep 2026 02:49:51 -0700 (PDT) Message-ID: <6d0a9922-a970-469c-b946-2f3c0deeb0e9@gmail.com> Date: Tue, 8 Sep 2026 11:49:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 18/39] xen/riscv: add guest page fault handling stub To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.com> <1788796634.8631fc262581453bbf619ec5b2062170.1a07c9684ae000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788796634.8631fc262581453bbf619ec5b2062170.1a07c9684ae000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788860991-52331A5B-6D45A3EA/10/73395122804 X-purgate-type: spam X-purgate-size: 4973 On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >> Add a handler for guest page faults and hook it into the trap path, >> providing the trap-side entry point which will later feed the MMIO >> dispatch. >> >> This will be used, for example, to trap accesses to APLIC registers so >> that a guest can initialize and drive an emulated interrupt controller. >> >> Two of the situations handled here are already decided, as neither can >> ever be turned into an emulated access: >> >> - A fault reported with a pseudoinstruction in htinst was taken on an >> implicit access made for VS-stage address translation, so htval holds >> the address of a VS-stage PTE rather than of anything the guest asked >> for, and the guest physical address behind the original access is not >> known. This is orthogonal to the cause and can accompany any of the >> three, which is why it is checked first. scause keeps reporting the >> type of the original access, and on bare hardware a PTE which cannot >> be read raises an access fault of exactly that type, so reflect one >> back to the guest. >> >> - A fetch fault means the guest tried to execute from a guest physical >> address which is unmapped or which G-stage does not allow to be >> executed. On bare hardware a fetch from physical memory which does >> not exist, or which may not be executed, raises an instruction access >> fault, so reflect one back too. >> >> Explicit loads and stores are where MMIO emulation will hook in. >> >> Neither of the two paths above consults the p2m first, and neither will >> the MMIO one: RISC-V has no populate-on-demand, no paging and no >> mem_access, so every guest mapping is established eagerly and a G-stage >> fault never denotes a mapping Xen could install to let the faulting >> access complete. >> >> Both of the helpers this leans on, resolve_faulting_gpa() and >> trap_redirect(), are BUG_ON() placeholders for now, so each of the three >> causes currently takes the host down rather than the domain. That is no >> worse than before this patch, where the same causes fell through to >> do_unexpected_trap() and die(). Implementing the helpers is left to >> later patches. >> >> Signed-off-by: Oleksii Kurochko >> > > I think the commit message it not very clear as it conflates two > different countable things (the 3 fault causes reported via scause vs. > the pseudoinstruction condition, which is orthogonal and can accompany > any of them), which makes "two situations decided" or "any of the three" > hard to follow on first read. > > Here is a proposition with a split to distinguish fetch-fault and > pseudoinstruction cases into explicit bullets with their outcome stated > ("Decided here"), and added spec-mentioned conditions about the > pseudoinstruction's existence conditions: > ``` > Add a handler for guest page faults and hook it into the trap path, > providing the trap-side entry point which will later feed the MMIO > dispatch. > > This will be used, for example, to trap accesses to APLIC registers so > that a guest can initialize and drive an emulated interrupt controller. > > A G-stage (stage-2) fault has one of three causes, reported via scause: > > - Fetch fault: guest tried to execute from a guest-physical address > that is unmapped or that G-stage marks non-executable. Never > emulatable (nothing to emulate a fetch into). On real hardware > this raises an instruction access fault, so Xen reflects the same > fault back to the guest. Decided here. > > - Load fault / Store fault: left undecided by this patch, this is > where MMIO emulation will hook in later. > > Any of these three faults can instead be reported via a pseudoinstruction > in htinst, when both: > > (a) the fault occurred on an implicit access Xen made to walk a > VS-stage page table, and > (b) htval holds a nonzero value: the guest-physical address of that > VS-stage PTE, not of the guest's original access. > > However, none of these paths consult the p2m first, and the future MMIO path > won't either: RISC-V has no populate-on-demand, no paging, and no > mem_access, so every guest mapping is established eagerly. A G-stage > fault therefore never indicates a mapping Xen could lazily resolve to > let the access complete. > > Both helpers this handler relies on, resolve_faulting_gpa() and > trap_redirect(), are BUG_ON() placeholders for now, so all three causes > currently take the host down instead of just the guest. This is no worse > than before this patch, where these traps fell through to > do_unexpected_trap() and die(). > ``` I will apply your suggestion. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 08 10:01:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 10:01:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411249.1641946 (Exim 4.92) (envelope-from ) id 1x3se5-0003k3-Sv; Tue, 08 Sep 2026 10:01:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411249.1641946; Tue, 08 Sep 2026 10:01:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3se5-0003jw-QH; Tue, 08 Sep 2026 10:01:41 +0000 Received: by outflank-mailman (input) for mailman id 1411249; Tue, 08 Sep 2026 10:01:40 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3se4-0003jq-N3 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 10:01:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3se3-00FxW3-HP for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:01:39 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fdcf5-2eae-0a2a0a5409dd-0a2a450bdada-30 for ; Tue, 08 Sep 2026 12:01:39 +0200 Received: from [209.85.218.45] (helo=mail-ej1-f45.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fdd03-b7e8-0a2a450b0019-d155da2ded77-3 for ; Tue, 08 Sep 2026 12:01:39 +0200 Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-c15cf78d1a2so423073066b.1 for ; Tue, 08 Sep 2026 03:01:39 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d6dfad6sm582834166b.60.2026.09.08.03.01.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 03:01: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788861699; x=1789466499; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0ptI15inGDkfay3iPU1VaPqGcMwTwBXIm3eQI4TcEhE=; b=XXcR03zxrqVlp4tzp+05P0lI6l4EEntHqclTZbp0y6jqkd5kuO+qhHQDCLx3ELBT6F i+vC4qQH4y+AxEoduEOIwJ/plhngbiH4iJoCtSD4kgP9oAf8dHATEDnRGmP4IuNYED0K ZgwIUElIGAMGVvQU+fFSLlT6Gyqgna1Ms0aPrGgsKOLIfL7TrzcUGDe+4HSoTjBMyI4O IYxpOHbXjAr3BU3n+bWNAJ+vwoXdClH9zUGM4pHvillj2GXTTDArCLI17hDkf+OWnhdN +tY8Y80vftSRyyzSwC6XA/zaKg5tsvStYoKumbDwYIXUsGhAB5fY8rfjfrBFrmrnc0HG L7yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788861699; x=1789466499; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=0ptI15inGDkfay3iPU1VaPqGcMwTwBXIm3eQI4TcEhE=; b=hNUhIqfmuRaitRyocCY4fEOSSFrIqTIefj9MUgWs0Bq3fL0MaEPDz6U5rThQp+Tg0n 4ALVLJlKOzU0+h55wnza69hOjI8k3b46eAOD8009SWJyO1eE91Y/I+o43hUyQtnnxbP0 lG4onNRhJZMhCypfFRZa59d0i6IbGPPDnzrkNVhGKdLGDEQIbhnNOdGAWFSRtYiObi3B qhZJ/L1fwGqeDwZjrDJYBE3/HNGa30Ux7Up4jXgskYKSZmSAdSd/lnuKwRvgd5MeAb7G 5MMjylSRtA5GE4QiY8WDtnAbaxaMmFbZh7aJiw+gNUIEalGQbldZof9JN5VPpm1m2pOt VKTQ== X-Gm-Message-State: AFuF++mOMDpaEA+rIzrFXwFhHEZnpqbfZsrUPdl1f2hcrxBcIz+9ZnJM S8PCI6hsgTWsw7lZaYQE4gnxEgDJaZiR9+/sn+1wDgUW+lc5SVChqw48 X-Gm-Gg: AYBFou1ADuJZwChM5/OSSnQA1S22aSzojhU0EbA5LxBJWTnwYcRqJjjyvckhYcWXvkI OsT0EJM+hO0tQDPHwOUQ7WVUyPZkuSRGv6j/pzBVXkHXZjQYR+7Nu1KHn53JTMMGCF+W1zCKMOq olIRomTZGO+oexqQ+DOSFIX++vgVenq6IjBG9iR2SO9MNiFd0oqFNLklD8y9PceoCFu2Bt1B1YT isEEWNNrYyCSDW9Kq6Enh45WhUJtweS8Amwpvvaq6HA+hUE7IX22Mt8b/cYEbKOh/Db98/ffwmA Bx2PH3LMqnpSoqrYopiljqra3wG0ROjDjXo8Hfwky+fExgQe2/B38GrIEURg30mSdIB/GkJfFQJ mDZB6nG6QagSP8b51x7Z3bMdrQTbiLyRJGHLHbxLRJaAF15D5E7Z6l4Avv+qWmX/SpjlDXcTE50 D7Vgh3qBbf3uGnf6DoNxVOJuxexmDy87Uo31ufMvajyojAlKEAVnn+IX7U1D0pDQ7hISIXy4tGl kjvY1KFbK5YqrugO4fg8w== X-Received: by 2002:a17:907:7a8e:b0:c26:19e3:e97d with SMTP id a640c23a62f3a-c2619e3eefbmr903459066b.29.1788861698506; Tue, 08 Sep 2026 03:01:38 -0700 (PDT) Message-ID: <2f734f0a-7f3e-4e27-82ed-52ccf72fe49a@gmail.com> Date: Tue, 8 Sep 2026 12:01:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> <1788796634.8631fc262581453bbf619ec5b2062170.1a07c96862b000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788796634.8631fc262581453bbf619ec5b2062170.1a07c96862b000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788861699-ABCD79EA-6722052C/10/73395122804 X-purgate-type: spam X-purgate-size: 4083 On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >> Some traps taken by Xen on behalf of a guest can't or shouldn't be handled >> by the hypervisor and have to be reflected to the guest's own S-mode trap >> handler instead: the access faults which handle_guest_page_fault() injects >> for a fault that can never become an emulated access, and, later on, a >> fault taken by the hlv/hlvx sequences of riscv_read_guest() while >> accessing guest memory on a vCPU's behalf. >> > Access faults from handle_guest_page_fault() aren't "taken by Xen on > behalf of a guest" as those are guest-page faults taken directly from the > guest's own execution. Xen just decides they can't be emulated and > reflects them back as access faults. Only the hlv/hlvx case is Xen > trapping on the guest's behalf (Xen itself executes the faulting access).> Conflating the two under one description makes the paragraph confusing. > > Suggest splitting into two: > > Two kinds of traps can't or shouldn't be handled by the hypervisor and > have to be reflected to the guest's own S-mode trap handler instead: > > - Traps Xen takes on the guest's behalf: the hlv/hlvx sequences > riscv_read_guest() uses to access guest memory. > - Access faults handle_guest_page_fault() injects for a guest-page > fault that can never become an emulated access. Thanks, I'll update original paragraph with what you suggested.> >> >> Implement trap_redirect(), until now a BUG_ON() placeholder, for that >> purpose. It makes the trap appear to the guest as if it had been taken >> directly in VS-mode: the trap information is transferred to the guest's >> virtual supervisor CSRs and the vCPU is resumed at its exception vector in >> supervisor mode, following the trap entry rules of the RISC-V privileged >> specification. >> >> Add the STVEC_* definitions needed to tell the BASE and MODE fields of >> vstvec apart. >> >> The implementation is based on kvm_riscv_vcpu_trap_redirect() from Linux, >> with a few deviations: >> - The function reads and writes physical VS-mode CSRs, so it is only >> meaningful for the currently running vCPU. Instead of taking a >> struct vcpu argument, it always operates on current. >> - The MODE field of vstvec is masked off explicitly when computing the >> exception target PC (exceptions always vector to BASE), rather than >> relying on the hardwired zero bit of sepc to drop it on VM entry. >> - Assertions document the preconditions: the trap must have been taken >> from virtualized mode (hstatus.SPV set), and only synchronous >> exceptions may be redirected - interrupts must be injected via hvip >> instead, so that the hardware performs VS-mode trap entry itself, >> respecting vsstatus.SIE and vectored vstvec dispatch. >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h >> index 2d2e7e11b3..b2071f4758 100644 >> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >> @@ -109,6 +109,12 @@ >> #define SIP_SSIP MIP_SSIP >> #define SIP_STIP MIP_STIP >> >> +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ >> +#define STVEC_MODE_MASK _UL(0x3) >> +#define STVEC_MODE_DIRECT _UL(0x0) >> +#define STVEC_MODE_VECTORED _UL(0x1) >> +#define STVEC_BASE_MASK (~STVEC_MODE_MASK) > Nit: STVEC_MODE_DIRECT and STVEC_MODE_VECTORED aren't used anywhere in > this patch (only STVEC_BASE_MASK is). Either use them where you decide > exceptions always target BASE regardless of MODE, or drop them until a > patch that needs them. IMO it is fine to introduce *_DIRECT/VECORED here as they are used implicitly through STVEC_BASE_MASK and thereby it will be better to introduce them here now instead of open-code them and then just update STVEC_BASE_MASK again when *_DIRECT/VECORED will be re-introduced. Thanks for review. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 08 10:08:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 10:08:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411261.1641955 (Exim 4.92) (envelope-from ) id 1x3skl-0004Xz-Ey; Tue, 08 Sep 2026 10:08:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411261.1641955; Tue, 08 Sep 2026 10:08:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3skl-0004Xs-CG; Tue, 08 Sep 2026 10:08:35 +0000 Received: by outflank-mailman (input) for mailman id 1411261; Tue, 08 Sep 2026 10:08:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3skk-0004Xm-PL for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 10:08:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3skk-00GezZ-66 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:08:34 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fde9d-8faa-0a2a0a5109dd-0a2a450ab962-8 for ; Tue, 08 Sep 2026 12:08:34 +0200 Received: from [52.101.48.34] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fdea0-f2d2-0a2a450a0019-346530225001-3 for ; Tue, 08 Sep 2026 12:08:33 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PHXPR03MB989210.namprd03.prod.outlook.com (2603:10b6:510:3cc::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Tue, 8 Sep 2026 10:08:30 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Tue, 8 Sep 2026 10:08:30 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=egYX3NaCAZeEyLzozSklJrg//ag//BvnIblln+NTwCdl3ipFlwy+JRspNhgRzd3/y15M7lN9uaRKq1ZSDRJLOH2I5+g0nXamZmHPrDJhkLRAjXOFZa0bt1qWQ6tkVqtg4Gcp7G/zQK1QTSAV8osgHhA2VlSp8soUom4xooLASU0JhqkBxOZB/D2RDHILvBo3Dsr0gQ7E66LaReyETPjRk3LdICmIgNK6Kl582w+uB5f/BuMrA1fFg/4UX9GaIitcPb2ZHyMvFqLbyb8pAmr4h2ItkOR34x1sFyWUvdE0FDLnBgc1zZIbEyWjbE0MkwzrcXOBrhAywQSCVQyMPY5zdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mSe9AtPtUzmjRahO69RkSadqwMTlHahpcjJPsoV9Ydo=; b=XlRyRzPUFyHxdVTg6sxSmiKWnCMBPYjynOhK0UfFLcKNPbUCe5S65iT0GMgeJsIlupcJtaGrGix0LpLrnMoQNI59j3/B7hh3451SruV6BpADdpMfC0PnvIN8CngVyeE5Ab4IZ5Sz3d0HM6w2iXygeuCn/LSHElITns4UZzkyvZuViliPHzkRJO1LYqw3J8+qusP7WSM9KwKTBJutkDXoAP5eOL87+kZf+3mGVJ23WNG1FKkJhnc6bA6HxvfiNtPz+8eAjd5XpsaQkdoktdZ85lMW/D3CJkzyd7+9XWQOpM8eizNAubyAXHwWWVhIOWESZcSbqEua0iCP0rojdRscYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mSe9AtPtUzmjRahO69RkSadqwMTlHahpcjJPsoV9Ydo=; b=CksvXvxhab9U4JbykfOUrtCcbLOZdQ/5tE0zMsXnKVWD9ybEiMXEZXhkcIdTMpcRB4ArewzD11+EC7nRPCnaU2sWLWnp/JJjCmyknZOdV+RAQ9/VBtyT/vIu1AV+9vnWZgM/TTHGibuX4U0C13w8jgHfkqevWOGHYKaHkvvVKUs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <6a54806f-061b-4b76-b42d-6fa5b54581e4@citrix.com> Date: Tue, 8 Sep 2026 11:08:26 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel Subject: Re: [PATCH v2] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Jan Beulich References: <20260907213231.3159241-1-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P265CA0016.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ff::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PHXPR03MB989210:EE_ X-MS-Office365-Filtering-Correlation-Id: 6d978744-5e89-4886-7e98-08df0d9121d8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|6133799003|18002099003|22082099003|4143699003|11063799006|56012099006|10067099003; X-Microsoft-Antispam-Message-Info: ViPPxCsPGTS4xoBIegROXCLuZXxvETeMmKou1PZMOOZcpasK6CeBz9nCGJpx8SxN06acbrn0ggzkaih1IkgK2+H82tSG5echF84u2BIRuOWfoMVwJLsFiaeNzgLFwbsFP4Ff1kX9Hjv81JwpD9eVnz6WAb+A/Y8LY6rXLJE082HEBgHQMSSgBiFMviiQ3+PD0Ap+VBlhFgl33xqPECkOrbsizZKNa6ty2GmT957urkEawOutb0iU+cHlmbRAiWaXgRjv4ZHkJ84sRhEIWnnGGJRTNt8yeqneZLEJJF3ciih7RRzp0mSFNTOG7GHKssLUoYDCOQyyhtV8P8YxElqx+5XijpQQjYoSn1vfnhKFG6vaBKkdAY51oYs00teTGWLXNMAQKHbJVF5J1ZnP7VAJTxLWGXOKIWr6zQeLYcaG8jYc1qSUL6loztuY9vHeAy8tnvbHla7ODcfkN1PriIwg7as6+7ybsKhACmUboPHU9x/9VDzrR0e+alnUKylt+k/8EJd43V5SgueD6Xy9Ku572Vjvi/eroj7Hm9zt/ROunmcLsyA0hZ7Et+t0vyfFzMOyCRcNGrxsQ1L8XGAMp1DB9aWC78IbRJJyIQZ3Mec8q+MlklSYZgrrsUtjx7KmAcgqgkisXMLYB+65KzaObgBITtFbX3j9IAWkMEJsYXfg5Lo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(6133799003)(18002099003)(22082099003)(4143699003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VjNMemVhL2Vpam5JSjhsWFArWE5NSEtLTmJzM3ZhY0FFM0VabEVMZDJydE8r?= =?utf-8?B?MmpEKzdhQlBEQVkrUGJvRDJWbjk5TWh4Q1lyV3c1TkFOYlNBdzJQczQ1L0FJ?= =?utf-8?B?SDV6ZGk2dlQ2RDhXaDJiakFnb2EzcGtCNDFMMjM0RzI2aUpFZWhkN2VzNXdz?= =?utf-8?B?WVVtNnBYc3JvODNvSVh2U2RoVVRVczhzT0J3aTB5ZVRJY2ZYVTM4ZXUyYVlz?= =?utf-8?B?aVRySzdzZmlRQWRkL05FajRnWDRyVHhMYVpyMHdLZlJoU0RLNUhkSyt1dTl6?= =?utf-8?B?dXhEYVM1WUFQcWdoZzVkRm4xRS9TTW9FQXFEUGdwU1J1WGxvVCt2WU4vZDFz?= =?utf-8?B?QjZVNjNrMnlQajFDcElkeHh5WHVxOEZFQ1FndFhGYWV4S1BZR0xoT2kyd2hM?= =?utf-8?B?d1kzRm5lYmFrVkx3RkVmeFZiTHhQK0NxcDcrTHo4OFg5NVNYQkJDVnJsRXB2?= =?utf-8?B?alFLK3NhUVNOVE8yZmVJQTh1SmVHWTZYUW9ZN0t1L1pzSjBvM0V5QkcyMEU1?= =?utf-8?B?bHpsWmdieXhMK1h4U3o0N2FnTFRST1U0RS9uWXdMTXlFbTY4NkxxSm9XR25y?= =?utf-8?B?RSsvUjB5UHdjOXBETXZjYzlZYTQ0STlPVC9ITFAvRHFNS2NoQjdtaDJYcWlJ?= =?utf-8?B?SFFCbGl0UlNrRSs2eThodmlPdEpxN1BLSWZFMWtJWEFnRVZnTXFwQVROaFdR?= =?utf-8?B?bWpNdW9qRHdqTnZEZ0lUai82TXJnT3puTmFHMGw0VUl0aC9OZkFlaWg5OUhG?= =?utf-8?B?VnNzVmhnMm9qRnlheXlZU3V1K1M0ZHFyTlZDYXpQQkNUVjQwc1cwbm44dEZT?= =?utf-8?B?UGtrYThRUklacnJYRmZFV3FwNTlMZnloRlRJb3YrbE5FMlEzUkVyRmxxMmZJ?= =?utf-8?B?ckg3Q1FrR3ozazhSN0M3MFFiL2p3d05hSTgvWWk5ejVaOGJNb011eFhZRThL?= =?utf-8?B?cFBjeE42SVhBOHlNRk1HbTdCMHFCWDhPK1A2aUV5RXdJMlVNUFNYR1dJWGZs?= =?utf-8?B?TldCVEkzTHdoaEhHL2FXc2xjR1ZzTkhYcWtZaVhGOVRHSUFjaDg2WHJuSnZQ?= =?utf-8?B?czhDZkFzYVF6dDZWWjNaeisrMG1selFXd01oY1dPWVlEdWF3Z2NWQmtaNzlR?= =?utf-8?B?YUljT2xPYkVQOThnYm5Wb3N4TmI3YkVWUDhGVHNCZVR0cTBjckRUbGVwZ2JZ?= =?utf-8?B?Um13ZXdNc1JBV3I1Vm9kS1IyMStqOEJlaTNIRmtQN3lpcXhieUdDUHZmeEI4?= =?utf-8?B?NmUwS1pFU1B0NGdUVWpqbmdKMXlmV0tMeVk1dEtHV25heUlOWkQyM1lxUzRM?= =?utf-8?B?S2tkbHk1eG96UmdvVloralJlem5Wa0lvK0NnN2JIY0t4VFZkUXRDQnpoM05J?= =?utf-8?B?QkF3cEU2MXY2UExBSjRPNkFLcmRYdWZkNG1neWs3elZwNkE4ZXlYcDFjU3JR?= =?utf-8?B?Vk9tV0Q4dWR0aWNCWWhWMUpmR0ZXK1pzNFRNUExBcHFGa0xTUXByRWVjbWJw?= =?utf-8?B?cmcvcjdQZWZ4cXkrSDBTektLNUF5cnZQTC9MNUozcTgvcm9vNGo3dzBzYVBa?= =?utf-8?B?eGg1V3hDcGZwNSs4NU9weGhTaTkvSnJqajJEMDVtcGJ3MUxzK0tZQTJmUlNz?= =?utf-8?B?ZHdWN2p3T1FIb0YvK0NUMFBrR1BSL1VObXFDd3Q3QXN0eUhKU3dwUnJLVXBa?= =?utf-8?B?RlpOY1J2U1NhR0FIRnJOM2Rkcyswa3JnbGdobHVkZmhCUHN5eCtsREVlMUhF?= =?utf-8?B?RTN3MlBHT2FGTGROdTZvaWFDZ2lkQkNxTVllaHJMSTBjYUloS2tsNmg4NDFr?= =?utf-8?B?dkxORXNTNUF0ODd5L1AydDhLcUJ0WlZJclN2ekV6U2pwZGV5QUNNNVpZZVFL?= =?utf-8?B?NmpzSnA3YWlDcHdNZkFHSWFpV01tb1BobVk2blBEUW5ZSm5nWGxvTkFUSGNH?= =?utf-8?B?UUpBaStYQmdKcG5ySmlVNTZEQVRTdjd0aUtqdk1ueHFXbDdYbDd0dTZQcVpy?= =?utf-8?B?b0xZbytVckxDZEhYbTJyYm0xd1I3S0ZoV1NXN21nM09GaUhRUGFlMDI2NVZM?= =?utf-8?B?SUdjTjlxaGFYb0FQWVpzT1k0RzVJY3pmOW5lVm8yb1VjaXhLTkhCM2tTcXBP?= =?utf-8?B?R09JTWVaaTRYNk5zL3pnaS9lTHV3bmF1YzN3akhKOGR4Yi9WeWtGeDNtbm43?= =?utf-8?B?NEprWHNmYmZ4WkJDTXRTV1FiUGZnWkRmVnhaZUVKMHZoSDdMWGc2VEN2Zi8x?= =?utf-8?B?b0ppZEtJRERTSndjUlNseHRUQzlaRWlMc0U0M0w5Y2phV2QzM2hiTG5JbFBr?= =?utf-8?B?VVo4Sk5EeXd2NWg2dkp2dkIrVFF0NVJ3NHBnelZuV0ZHcXFvMHFzQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d978744-5e89-4886-7e98-08df0d9121d8 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 10:08:30.0841 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: xXsFLccQrogUsnL8KksLAWbMcZUfgdkpQL7pPWyauji+0LEJRYJBD5327chTTZh1JLwNHXapOvOjB2aJI6RzoMOEzsB6NPxEFjlydpuv5Ys= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR03MB989210 X-purgate-ID: tlsNG-4011c0/1788862114-514C7CFC-245E4C47/0/0 X-purgate-type: clean X-purgate-size: 3259 On 08/09/2026 7:26 am, Jan Beulich wrote: > On 07.09.2026 23:32, Andrew Cooper wrote: >> @@ -273,6 +274,44 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) >> return false; >> } >> >> +static bool microcode_safe_to_load(const struct microcode_patch *mc) >> +{ >> + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); >> + >> + /* >> + * Treat pre-production as always safe - anyone using pre-production >> + * microcode knows what they are doing, and can keep any resulting pieces. >> + */ >> + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) >> + return true; >> + >> + /* >> + * GNR98 states that Granite Rapids systems hang when loading new ucode on >> + * sufficiently old firmware. GNR101 retroactively declares that one >> + * ucode had incorrect min_rev fields, in light of discovering GNR98. > We still have no min_rev field, so imo a reference to it wants some > clarification. No, I don't think so.  The fact Xen has no min_rev field (yet) has no baring on the wording of GNR101. This patch stops Xen hanging with the real ucode which has existed in the world for 6 months. I am still waiting on Intel to publish new blobs (including corrected min_rev fields) before the multi-hop update can be made to work.  I have no ETA on this. > Really I first meant to ask why there's no use of that field, > to merely make that one exception. > >> + * Both are incomplete statements of the problem. >> + * >> + * At the time of writing (August 2026), the believed safe sequence is: >> + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later >> + * >> + * Disallow known-unsafe loads while permitting believed-safe loads. For >> + * GNR, this allows multi-hop loading to get up to the latest. >> + */ >> + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && >> + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && >> + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || > This is odd: The lhs of && uses the lower bound of the inner permitted > range, while the rhs of the && doesn't use the upper one. If it's intended > that way, I think this also needs clarifying in the comment. Otherwise imo > lhs and rhs better would be consistent in this regard. It is intentional.  Furthermore, it is the only coherent way of expressing the sequence as given. I'm not writing a comment explaining why it's a good idea to use the same boundary numerals between the comment and the code.  It goes without saying. I'm also not interested about pureness concerns about inner vs outer bounds.  I can't see a change here that won't make it worse. > >> + (cpu_sig->rev < 0x01000405 && mc->rev > 0x01000405)) ) > This one, otoh, fully matches the comment. > >> + { >> + printk_once(XENLOG_WARNING >> + "microcode: Granite Rapids erratum GNR98 detected. Skipping ucode 0x%08x\n" >> + "microcode: Firmware update recommended\n", mc->rev); > I think a 2nd XENLOG_WARNING is wanted after the inner \n (or none at all, > to use the default for both). Fine, fixed up locally. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 08 10:15:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 10:15:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411273.1641969 (Exim 4.92) (envelope-from ) id 1x3sro-00069t-6G; Tue, 08 Sep 2026 10:15:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411273.1641969; Tue, 08 Sep 2026 10:15:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3sro-00069m-2p; Tue, 08 Sep 2026 10:15:52 +0000 Received: by outflank-mailman (input) for mailman id 1411273; Tue, 08 Sep 2026 10:15:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3srn-00069g-3V for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 10:15:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3srm-00445Y-4i for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:15:50 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fe050-e002-0a2a0a5209dd-0a2a4507b64c-16 for ; Tue, 08 Sep 2026 12:15:50 +0200 Received: from [209.85.218.46] (helo=mail-ej1-f46.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fe056-b4ea-0a2a45070019-d155da2eb8f8-3 for ; Tue, 08 Sep 2026 12:15:50 +0200 Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-c20e70a0962so556337666b.2 for ; Tue, 08 Sep 2026 03:15:50 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d503f96sm583474066b.26.2026.09.08.03.15.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 03:15:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788862549; x=1789467349; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=48xvm1sXjxlbELL90k6ywU4/pB7nbGZAULGKSdWcQ6A=; b=TYpMyg9m4NW5+5k28UfUrPvOtzIikBg8NKEIAKNOaaOd+SgawO8zScuzlGqfOwS93h NEkyteDWcWNJUgC1uvXSPSkBztT5wajbzRk8BFexh6OV3lk0sV76Sbje3hEfnHtZPcii HYeue6koXWmj8dK1ocUKNCWKa+eW4WETuqhdOCaIbXq+b7zVj5nDYu1oF56JHNJ+lieS s6PjOxPK6ouMAijN24/1fZ7VtFXsGoqBvT+GQ67WT/XGMUHItwRDeq4vNJgSqtp3HUBT wFapJr768GDc+8+QK0QzhCCt90DMSwykJ6qG+yMdIK8CsEqeGi7GUJHOZc9Or10Zgcr5 spkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788862549; x=1789467349; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=48xvm1sXjxlbELL90k6ywU4/pB7nbGZAULGKSdWcQ6A=; b=sLUBJf4Tg6Y6kY3iCWHYvT473BSfQQuZAT1YR/Vpx1lTuLDSxe5EHtbAOiSRyQsfbq wZJiqcmd2cppjc2ep52YlsnzY2M3L0NnuH/U3t1PakFz1DE+XEm76KXf3rPvTt1r+s0x 4yx1n6C9pmc3owLp4pFJ0xFKL9ZPXbu483S+eorbps/mh9Em3NJF8w0PzyA3IeOMDjKp kQfd+johgTu8LfDV1ArvYP9i2VFvFkaKvnbAbRXMi3EVd5boeZi/XzMdJkbxByNZDCYg JbFzsM/btXgU+cMrYNJvvDWTo8d4c4Wbe3/I9roGP5tVQssqWk6qAw1t7m2CF1tNXNnS hrfg== X-Gm-Message-State: AFuF++lQYKLaBlGwtu7jgKC6SNpaW6Y92wwKkDnW8t59HHF/25bIFzhq dwktosgLU+gnTRIdjxY2jEr3jSwb9R4TFTvli1O6Az+yD7dupOA1mFuZIZSA6A== X-Gm-Gg: AYBFou1afWS9C6vq2hYqLg78jO2vfdZwsMsVuUMOh3q/Bb7mj199vNIym+AiSx/MapV vYiO7V4Wh0817IrotQ3PCaWbmnREBtkQ3ZQgPZsVhG4ojtDGedWUFDwlrf8rIlqxBXmJnvURhdX /p+NPsiU8atLw+VfZUdkBeuce6YeESBHNJbitiysWXSz97LBTu3wCc7znf6M7lOd6VLoTz0c2Ge iEvU5BRRRjzd5TL+vBGPSGguCPehIdnE1cqW0Dgnlf311Is2F8DE20jTZtitnJvQhHRxFxUdKrh 2TonYQt2ogRR52s637Xqap7e7JoLjhjvVEhbQbBqL3sNe2r4MModtMWFETkNDeu+YUbMyT8YM8O fQTgnzrRhPL8yMNlHRMwvtQE4ZU4mNmSbyYRUuM/HkPvstRsQgEefbvO66o/y5iVU10BUHIaUXh rgYXGK8CqO2qT8P8RIv1AA9fpvBOtQID14F92w5cP8ZvCY9hX4BhzXqJ2Yixp6yofwZ05iHtpv/ V2BGsT+xuiR3IVQyx6DwPJUC1esz1zs X-Received: by 2002:a17:907:d93:b0:c25:2a78:15ed with SMTP id a640c23a62f3a-c260c8b4c36mr1821644866b.6.1788862549334; Tue, 08 Sep 2026 03:15:49 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 12:15:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 20/39] xen/riscv: detect Shtvala To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <611683b3d2e3b836d08d0499f7caff782ba80a34.1787838835.git.oleksii.kurochko@gmail.com> <1788796635.8631fc262581453bbf619ec5b2062170.1a07c968805000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788796635.8631fc262581453bbf619ec5b2062170.1a07c968805000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788862550-A5AC0AE4-13175BBE/10/73395122804 X-purgate-type: spam X-purgate-size: 2064 On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >> Shtvala says that htval is written with the faulting guest physical address >> on a guest-page fault. The H extension itself allows an implementation to >> write htval with either that address or with zero, so where the extension is >> absent a zero htval cannot be told apart from a genuine fault on guest >> physical address 0-3. >> >> It is not offered to guests. Shtvala describes the HS-mode trap interface, >> which a VS-mode guest never sees, and the H extension it belongs to is >> already withheld from guests. Its guest-facing counterpart is a separate >> extension, Shvstvala. >> >> Signed-off-by: Oleksii Kurochko >> > I thought this commit message is not very clear. Here is a more direct > suggestion: > > ``` > The H extension allows htval, on a guest-page fault, to be written with > either the faulting guest physical address or zero. Shtvala extension > removes the ambiguity of this zero-write by guaranteeing that htval is > written with the faulting guest physical address in every circumstance > permitted by the ISA. > > Not offered to guests: Shtvala describes htval, an HS-mode-only trap > register a VS-mode guest never touches and the H extension it belongs to > is already hidden from guests. The guest-visible equivalent is a > separate extension, Shvstvala, covering vstval instead. > ``` Sounds good to me. I will apply your suggestion. > > Btw, I saw Linux has Documentation/devicetree/bindings/riscv/extensions.yaml > which describes all of the extensions supported, don't you think it would > be useful to have the same in docs/misc/devicetree/...? I think it could be useful. I think also about booting.txt already exitsted in the codebase. Would you be okay with that? I think I will add the section to booting.txt and pointing to riscv_isa_ext[] in cpufeature.c and so we won't miss an update of doc if we will add or remove support of an extension. Does it sound good to you? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 08 10:16:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 10:16:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411274.1641978 (Exim 4.92) (envelope-from ) id 1x3srx-0006PF-FA; Tue, 08 Sep 2026 10:16:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411274.1641978; Tue, 08 Sep 2026 10:16:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3srx-0006P6-CH; Tue, 08 Sep 2026 10:16:01 +0000 Received: by outflank-mailman (input) for mailman id 1411274; Tue, 08 Sep 2026 10:16:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3srw-0006OD-59 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 10:16:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3sru-00Ggz6-Pd for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:15:58 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fe052-bab6-0a2a0a5309dd-0a2a45068510-34 for ; Tue, 08 Sep 2026 12:15:58 +0200 Received: from [52.101.62.48] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fe05a-195a-0a2a45060019-34653e30e2b8-3 for ; Tue, 08 Sep 2026 12:15:55 +0200 Received: from BN0PR10CA0027.namprd10.prod.outlook.com (2603:10b6:408:143::28) by BL1PR12MB5802.namprd12.prod.outlook.com (2603:10b6:208:392::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Tue, 8 Sep 2026 10:15:50 +0000 Received: from BN3PEPF00022BBE.namprd04.prod.outlook.com (2603:10b6:408:143::4) by BN0PR10CA0027.outlook.office365.com (2603:10b6:408:143::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.15 via Frontend Transport; Tue, 8 Sep 2026 10:15:49 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF00022BBE.mail.protection.outlook.com (10.167.248.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.5 via Frontend Transport; Tue, 8 Sep 2026 10:15:49 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Tue, 8 Sep 2026 05:15:49 -0500 Received: from [10.71.198.170] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Tue, 8 Sep 2026 05:15:47 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=acQdO/Oep2Y81sWePjSaARO498RepWQaoKpCpor90ZyLD7SBVNC/fBmzUVLlaA8QgMreahO3hqWVCVu74WP0KB0nq9tOJYeqHKNP+InVnM9iHHi+v6fWlg1dzp4l8SSO5/9YV+FWJ9k7TH2tiUwkPTt40MHfvcbcGNs8/OXVTfG6CMqGcmdncrktTevkP+yAoeUyjyus3XYuowev+xeLii1H1DAdQALdslOAUtrrDuspBT2w8+IroD6QB3ZjNzwPcyz62EyOMVtKihFZxkydffsLvsbNgbG8Rkx7pw6BxhVRVbb7IOEwnSOk1P1P53+KaetRs972LsrCwCuqu8CYsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CL0RqkCcFHvzY0x/FMtT+wm5AEKe2Jhg4P6VvBd5Aq8=; b=W4lhjvaeQTPvG8DHZdqvvETwp48D+G3ZgF7KehhBdA37FHv45u0lQFM1WmY0Cjox/gFKxzNYuvAVZXliLPUNtwk5TMkxV1ex3KxG6IxY2pI5iIjXCMw5/qL+CN40CV/QMZmuk+8hal4OY7OHjmurz7WxZJpo3Zw5FX/Xg3dYkr7SWwjwlJmhD9HNKAcoc214xgjOoIC054LYQVqU4vx5iFzC/khtCdhgTOr1awHo9gPlceyrdmwqiieno2F5GFaqJIi2OLf6qiRGuax5Gk3q1m8WB4u364be2VjvdS6xFYEc3eZxIz7orDL65aZirN4ASvMEZpDvuW6v+vS6MNTSMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CL0RqkCcFHvzY0x/FMtT+wm5AEKe2Jhg4P6VvBd5Aq8=; b=Ent3vZqiNV/zoqrASG9+TmJIWXGMa9FwavZzDb0x2DitVv0tAq+XJTubnjj2umgaBkEFMo00sHteTTlBnDnuAr4PGSG/X+c7biRERGUEgrk0yhYhwVKUOgp6dGF3WrVph+Ab61G92tbbhIDqWbSH/TZUbrmq6d0g5e9dTBgyT30= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Tue, 8 Sep 2026 11:15:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] drivers/char: Panic when the requested UART fails to initialise From: "Halder, Ayan Kumar" To: Michal Orzel , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alistair Francis , "Connor Davis" , Oleksii Kurochko , , Andrei Buzdugan , Simone Weiss , , References: <20260902073606.61062-1-michal.orzel@amd.com> <20260902073606.61062-4-michal.orzel@amd.com> <48a7a4a3-605a-4a22-a7ad-2a4041f65b77@amd.com> Content-Language: en-US In-Reply-To: <48a7a4a3-605a-4a22-a7ad-2a4041f65b77@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BBE:EE_|BL1PR12MB5802:EE_ X-MS-Office365-Filtering-Correlation-Id: 94f5be00-4f06-4098-e98c-08df0d9227f0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|376014|7416014|23010399003|1800799024|82310400026|10067099003|11063799006|4143699003|56012099006|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: ZRdyLV+uT/Co3Fg4BO5O3A6EdMleGh95K0Mrd9g4+SPCh2YBkUirtzc20nLqPsu1X/TW2Iu4lbH5O/GT55dL4+PcHqA1xovjdmM0Q56eaE+raj1jFMufe6iBgilz1MQriqq5vv9MPmgGae36sf0vPJlI8n9XEmwRWFTqdpYvAa19NAlFLcZZlF1IaMdN9OaA5YFEqE5XhHcCjZsgRP2x/OjRtxDVTK510OPQ6AZ/P9yDIocOK20GnTs8cb6ePxcpdeTP5VEBrw4bYFWvwvNDzy7a4ZbR2gGNXbI6IRIr5SJSsTQxFrhi85AbMNvGTKVeP3Jo6z8cDn/Ps6/CK2OzuPCMCPGUWtGP6zwRSGqiQlDNWF5lZ1aNrktxMA4e5iQFm9XCtc1VQGh/I4rF8p1wy0QhkWprqAViqFQmrufiI5xzWsr7tn8eV+yTIt6UaQMk9OKn43CRY+6bmo0nWSIyH6A1Ol9GdMrbqWv59w9PiQczmfXA0xRVcAVpXtpCZOnqJZdMsafsg6I6I26lQ9oH73GSd30TmFd5H530rIjJX939xYrKVC16iwmAa8ozmg+iZiuboOAMl1AuVKG9W4hjDngMNDAffj1tFnhYd9rKab1LfBLjEWRGOpjQkIpWA795rTTFyahP9vS5iOeW1PQ0enq6AYz+Sg7KSS/711XdtXwrEGy6oBuXH43FN46knjStryDEcQYWKVKtNxC6x99hoQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(376014)(7416014)(23010399003)(1800799024)(82310400026)(10067099003)(11063799006)(4143699003)(56012099006)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ktPSyHM0l/cBpOR7GIaq4wZy/bpcxLmf9ZgnuuaetEEwxrNmHgY3W3GlBx+XWY0RIAHFB7jn02SsTWnmTTp0gcVR/YkUuTpKFU0Hv2d3l0lB/NRa3Zb5mehYv4kBmCD7oLV/CU+FtE8KzbMSXOVzfmjxSFoKJUxK1Ice8Ve4AVlX/+3CcuMwYNB6fAyD3fpm8CVJNt+vmJenLirdg04Tzfwmjjq4otdKjo2D3TZJdl+m0wYCg/CKT0Sx/QxBN24Wn6mZvd4mNTTxNimhbEEN2aYegTtE60owT1zFyoyd8UHee4cisJfKo0SRk/T09BpvR/1sltw5S97jYJKUIaUGXFPsAWdhZujIKDipLcFju9StcGJXmmjSyQF16wk7v6ZHt5oOACFpF8TUZd2SLfBqkLa8SBOLfFeaPd+40YRjk7RphNuR87s5Y0yCRS3A4hNH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 10:15:49.5960 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 94f5be00-4f06-4098-e98c-08df0d9227f0 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF00022BBE.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5802 X-purgate-ID: tlsNG-16d1c6/1788862556-F5A0C77B-4D9375E6/0/0 X-purgate-type: clean X-purgate-size: 1953 On 02/09/2026 10:44, Halder, Ayan Kumar wrote: > Hi, > > On 02/09/2026 08:36, Michal Orzel wrote: >> uart_init() cannot tell its caller that the UART the user asked for did >> not come up: every failure path only printks. Arm and RISC-V carry on >> into console_init_preirq() and boot without a console, rather than >> refusing to boot as they do elsewhere when a user request cannot be met. > I just want to emphasize that from functional safety perspective, this > is the preferred approach. The user's request is given the priority > and whenever it cannot be satisfied, Xen should panic. The patch does it, so we are good. >> >> Return an error from dt_uart_init() and panic in start_xen(). An >> explicit request Xen cannot satisfy should stop the boot rather than >> silently degrade it, > > If there is a silent degradation, then we need to document this > behavior somewhere. I am happy to keep this documented under docs/fusa. > > In the safety manual, we should mention all the instances when there > is a silent degradation observed, the underlying reason and how the > end user can detect it. > > Other FuSa experts can comment. > >>   which is what start_xen() already does for the rest >> of the boot configuration. >> >> Only a path given on the command line counts as a request we have to >> satisfy. Falling back to /chosen/stdout-path or acpi_uart_init() >> therefore never fails. SPCR is firmware provided, the analogue of >> stdout-path, and there is no ACPI equivalent of dtuart= to make an >> explicit request with. >> >> While here, decide whether the SPCR table was found from the returned >> acpi_status rather than from the table pointer, which was only NULL >> because the caller initialised it - acpi_get_table() writes it solely >> on success. >> >> Signed-off-by: Michal Orzel Reviewed-by: Ayan Kumar Halder - Ayan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 10:56:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 10:56:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411296.1641988 (Exim 4.92) (envelope-from ) id 1x3tUS-0003jr-BY; Tue, 08 Sep 2026 10:55:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411296.1641988; Tue, 08 Sep 2026 10:55:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3tUS-0003jk-7q; Tue, 08 Sep 2026 10:55:48 +0000 Received: by outflank-mailman (input) for mailman id 1411296; Tue, 08 Sep 2026 10:55:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3tUQ-0003je-A7 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 10:55:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3tUP-00Goyj-Mr for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:55:45 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fe9b1-8faa-0a2a0a5109dd-0a2a4503b82a-2 for ; Tue, 08 Sep 2026 12:55:45 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fe9b1-fae8-0a2a45030019-4a7de14cafe5-3 for ; Tue, 08 Sep 2026 12:55:45 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356256so439712f8f.1 for ; Tue, 08 Sep 2026 03:55:45 -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-49cf7703cc7sm385441815e9.4.2026.09.08.03.55.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 03:55:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788864945; x=1789469745; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=qNeMh7XzwyNa7ehNx2IeWsej1scrZpT0zI4y4PTC3Sk=; b=Iuffnznf0g+4MzaGq1BF/f+jQQuggVNZtRX9LI7qpZgMJmmyTK2qHj7nW8aHRzgiAy dYl4pcPYF+PUOP4AWdbY6UNimPFjAValMgry5uTg9FMYzKz495w/lrPN75q5ArbaL3Ql hCTh7MRUZcZQqY0SY020aoW09ezWC2nSua8Lka8z+HbYZO2CN8dHF0mRaTCa1ZfDFA/r tYfP5msgNdsyYVGg+dhxWqBa4aXCRr3JkYrLXCsq6nQChIdc9UChzBrGMeJ0hjoMGf2B lTbzi/jq2zbdb2yHuFAMhD4eaNpuMJ1wSV0TXakYbNN/3GWj1PgXXtHCFyXdpAu9RNaJ LqrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788864945; x=1789469745; h=content-transfer-encoding:content-type: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:content-type; bh=qNeMh7XzwyNa7ehNx2IeWsej1scrZpT0zI4y4PTC3Sk=; b=dexrnOyPiXbLyfumYPJadQtVo/XBrMgIhxxNNzVp2U6p2OrTOJ9GEbWoKFvecsVj2j w177CfzB0H/dBxvG5gkH920KzM9yU0FIGvwYsZEQPpXw4CP+O+5puMsR0SjvT8L7JxZQ c567Gj6uyJZkvp5MZgzgFz6i9VLZxdPPyI9NNKiFCKQqq5Q2Q8TmmtUlVxA/J8J9n4tf o3Jj89RVL5AcMNQzh1KATgQpUUbOE6MTZzKD4VwiYqXxdoaoDLlS7jaFHCLZorVQOwDO /3YFsZ0yiWFFCoiuhTh/t70jwfHXVCdUrP0VFmebYjCbl+F9kpb+nI/AlzA5f09s8T42 MC7A== X-Forwarded-Encrypted: i=1; AKwUvBw57o/8Xu+Y2mnM1WG+2framiTseunpIUDdcCumG6pbMZcw0fzu6Po6cLJ8Qb4w33YZaT/EW1W3KN0=@lists.xenproject.org X-Gm-Message-State: AFuF++lcBu/OovR0Z7hdAE7h6kBKPq+naNKcbyonL34g8mtrNNUUeE7h kjupGGprA1PpjVJj6JHb3Mq8DjSke5sf/LqXYHdp87wmFUiT43ZP7oizyYsxJ4fm/Q== X-Gm-Gg: AYBFou2R1qHMwWPor/lLvFSOopqJGuSzQnBJCtYpvMi16+wZtW5GahZBFdf7sgZbxfm P3ZaXivW1mrf+PFn4qlG0hfKoQsvSx1Vp9+gKX6bMBx/o0iyg/Vu4h6NFFzFGHxloXZZMu8Iibv WwInG6wYQ8Z8jI+xpWm8PFTaTp5YndVWnG7Y3uFP6qwBM8Bw0SmCoUir4fl6wOCmM6CVuoPm8Xq 6m090Nc2qIAHXvPUu9HxXOTFgoEVye4TgAcfUEqo7hwb0Ck7w1fnCatvCEwsPGT7+4HHcKxP3zV V89Ge7j7PJFuxcW+RAwtmPoHsJKCcAbuxTp1ib4qBnE5m2lmaBTqEhY33E+72tUYmrR7Vwt3Av+ 1jTX2UhusjLBClv/PxInWmccd82yvQT6y0meRArrvus4ksx5EqpjvRTrZbUJZYeXW2BuJq+mwjd ddA0zpnyWSkbV+piV3eJX+yFzs4cuv3b+JbTVzW9jtfXVhOcWFwgPelES7LKqoLEu3GDUrOZPZ9 Mksza2jz4SuvXI1ng+AYFf8u+xzhctFC3kOEQKjRarGR+Yq+vHMx+2L75BlKw0= X-Received: by 2002:a05:600c:a01:b0:49d:1916:2133 with SMTP id 5b1f17b1804b1-49d1916215amr38415655e9.8.1788864944747; Tue, 08 Sep 2026 03:55:44 -0700 (PDT) Message-ID: <70dd9e38-bc54-4532-b310-cb9fb3d3f2ce@suse.com> Date: Tue, 8 Sep 2026 12:55:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260907213231.3159241-1-andrew.cooper3@citrix.com> <6a54806f-061b-4b76-b42d-6fa5b54581e4@citrix.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: <6a54806f-061b-4b76-b42d-6fa5b54581e4@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788864945-7468B4E9-0B25B350/0/0 X-purgate-type: clean X-purgate-size: 3748 On 08.09.2026 12:08, Andrew Cooper wrote: > On 08/09/2026 7:26 am, Jan Beulich wrote: >> On 07.09.2026 23:32, Andrew Cooper wrote: >>> @@ -273,6 +274,44 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) >>> return false; >>> } >>> >>> +static bool microcode_safe_to_load(const struct microcode_patch *mc) >>> +{ >>> + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); >>> + >>> + /* >>> + * Treat pre-production as always safe - anyone using pre-production >>> + * microcode knows what they are doing, and can keep any resulting pieces. >>> + */ >>> + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) >>> + return true; >>> + >>> + /* >>> + * GNR98 states that Granite Rapids systems hang when loading new ucode on >>> + * sufficiently old firmware. GNR101 retroactively declares that one >>> + * ucode had incorrect min_rev fields, in light of discovering GNR98. >> We still have no min_rev field, so imo a reference to it wants some >> clarification. > > No, I don't think so.  The fact Xen has no min_rev field (yet) has no > baring on the wording of GNR101. The wording there is "Minimum Runtime Microcode Update Revision". As long as we don't have a field of the name, how can such a comment be unambiguous? >>> + * Both are incomplete statements of the problem. >>> + * >>> + * At the time of writing (August 2026), the believed safe sequence is: >>> + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later >>> + * >>> + * Disallow known-unsafe loads while permitting believed-safe loads. For >>> + * GNR, this allows multi-hop loading to get up to the latest. >>> + */ >>> + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && >>> + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && >>> + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || >> This is odd: The lhs of && uses the lower bound of the inner permitted >> range, while the rhs of the && doesn't use the upper one. If it's intended >> that way, I think this also needs clarifying in the comment. Otherwise imo >> lhs and rhs better would be consistent in this regard. > > It is intentional.  Furthermore, it is the only coherent way of > expressing the sequence as given. > > I'm not writing a comment explaining why it's a good idea to use the > same boundary numerals between the comment and the code.  It goes > without saying. But that's the problem - code and comment are not (obviously) in sync. > I'm also not interested about pureness concerns about inner vs outer > bounds.  I can't see a change here that won't make it worse. So why are ((cpu_sig->rev <= 0x01000370 && mc->rev >= 0x01000405) || and ((cpu_sig->rev < 0x01000380 && mc->rev > 0x010003f3) || both worse? Both 0x01000370 ... 0x01000380 and 0x010003f3 ... 0x01000405 are discontiguous, which is bad enough. If then you pick apparently randomly (and in any event inconsistently) from the possible boundaries, how can that help the situation (and be "the only coherent way of expressing the sequence as given")? Even if it's merely a matter of us disagreeing on what "consistent" or "coherent" would be here, doesn't me as the first reader not easily spotting the "coherency" you claim already indicate there is a (possible) issue? (For context: Whichever way the expressions are going to end up, they'll make implicit statements on the gaps, i.e. on the non-public 0x01000371 ... 0x0100037f and 0x010003f4 ... 0x01000404. You may say that doesn't matter, because of their non-publicness, but that won't make that implicit statement go away.) Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:00:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:00:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411329.1642046 (Exim 4.92) (envelope-from ) id 1x3uVQ-0005B3-7C; Tue, 08 Sep 2026 12:00:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411329.1642046; Tue, 08 Sep 2026 12:00:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVQ-0005AK-0o; Tue, 08 Sep 2026 12:00:52 +0000 Received: by outflank-mailman (input) for mailman id 1411329; Tue, 08 Sep 2026 12:00:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVN-0004KE-J8; Tue, 08 Sep 2026 12:00:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uVM-00BhQN-Vy; Tue, 08 Sep 2026 14:00:48 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ff8ea-8faa-0a2a0a5109dd-0a2a45058a8e-48 for ; Tue, 08 Sep 2026 14:00:48 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ff8ef-4cb1-0a2a45050019-6882d725b970-3 for ; Tue, 08 Sep 2026 14:00:48 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3uVF-004n4b-2Z; Tue, 08 Sep 2026 12:00:42 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1x3uVG-00GjtI-0E; Tue, 08 Sep 2026 12:00:42 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.510 (Entity 5.510) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team CC: Xen.org security team Subject: Xen Security Advisory 510 v3 (CVE-2026-79602) - x86: improper handling of HVM emulation return codes Message-Id: Date: Tue, 08 Sep 2026 12:00:42 +0000 X-purgate-ID: tlsNG-c201ff/1788868848-F4AA72A1-504A4F66/0/0 X-purgate-type: clean X-purgate-size: 5243 --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2026-79602 / XSA-510 version 3 x86: improper handling of HVM emulation return codes UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= A guest with a PCI device assigned that has at least a BAR on the IO port space can trigger a BUG() in Xen. IMPACT ====== Passing through a PCI device with at least one BAR in IO address space to unprivileged HVM guests can result in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS ================== Xen versions 4.6 and later are vulnerable. This is known to be the case with the fix for XSA-491, but it's possible the issue can also be triggered from other, non-analyzed paths. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only HVM guests with a PCI device with IO BARs assigned can leverage the vulnerability. MITIGATION ========== There is no mitigation available. CREDITS ======= This issue was discovered by Jiqian Chen of AMD and diagnosed as a security issue by Roger Pau Monné of AMD. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa510.patch xen-unstable - Xen 4.17.x $ sha256sum xsa510* 915cca4f0e6af998683a3551e5913d2489b23a697d5eab11358d4d8ffe0a0e55 xsa510.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmqf98UMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ3GEIALHxkeOzpl3/ctf8o9R89LFTfayDXMY6xGbUTsRk oiLIoKkYkZJPtiG6cY8YGRvzm/UYr+KpeMBsNtm0EcbZlPClGjkEc7JSSpMvcVps XTzRkIUhyOTfpKklhDQJynIIpMu8NkJBLvyVYDcY8fpeZ7yDykMkQ4RyvXT5A56r Vn18FJ401QqBO0+NTD0aCcasiLFpfrsh3AhPfKLIi7c3q0tIayyNBS8NBSNss+TF OJew3jWX7bWnAUlPl4b8EMm4gwK/7o6YJYW+NMCTNMJ/UdfvOJkkq9T8l/41FIXq ArtZrFpKWxsitNoXG7pJIyH/C5wBH2DFABzfqgNjkpzfqKw= =sVA/ -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa510.patch" Content-Disposition: attachment; filename="xsa510.patch" Content-Transfer-Encoding: base64 RnJvbSA3OTY1MzczMTE3OTdkNjAwYzBjNzE2ZDBjMDE1NTMxZmM0MWFiYjky IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u bmUgPHJvZ2VyQHhlbnByb2plY3Qub3JnPgpEYXRlOiBGcmksIDcgQXVnIDIw MjYgMTE6MDM6NDggKzAyMDAKU3ViamVjdDogW1BBVENIXSB4ODYvZW11bDog Y29wZSB3aXRoIGludGVybmFsIGhhbmRsZXJzIHJldHVybmluZyBYODZFTVVM X1JFVFJZCk1JTUUtVmVyc2lvbjogMS4wCkNvbnRlbnQtVHlwZTogdGV4dC9w bGFpbjsgY2hhcnNldD1VVEYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5n OiA4Yml0Cgpodm1faW9faW50ZXJjZXB0KCkgY2FuIHJldHVybiBYODZFTVVM X1JFVFJZLCBhbmQgYXMgc3VjaCBpdCBuZWVkcyB0byBiZQpoYW5kbGVkIGlu IHRoZSBzd2l0Y2ggaW4gaHZtZW11bF9kb19pbygpIHRvIGF2b2lkIHRyaWdn ZXJpbmcgdGhlIEJVRygpIGZyb20KdGhlIGRlZmF1bHQgY2FzZS4KClJlc2V0 IHRoZSB2Q1BVIHN0YXRlIHRvIG5vIGluLWZsaWdodCBJT1JFUSBhbmQgcmV0 dXJuIFg4NkVNVUxfUkVUUlkgc28gdGhhdAp0aGUgYWNjZXNzIGlzIHJldHJp ZWQuCgpUaGlzIGlzIFhTQS01MTAgLyBDVkUtMjAyNi03OTYwMi4KClJlcG9y dGVkLWJ5OiBKaXFpYW4gQ2hlbiA8SmlxaWFuLkNoZW5AYW1kLmNvbT4KU2ln bmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXJAeGVucHJvamVj dC5vcmc+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3Vz ZS5jb20+Ci0tLQogeGVuL2FyY2gveDg2L2h2bS9lbXVsYXRlLmMgfCAxICsK IDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKQoKZGlmZiAtLWdpdCBh L3hlbi9hcmNoL3g4Ni9odm0vZW11bGF0ZS5jIGIveGVuL2FyY2gveDg2L2h2 bS9lbXVsYXRlLmMKaW5kZXggMmVmYjFkNGYwODIzLi5jMDllYTAwMmVjNjIg MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vZW11bGF0ZS5jCisrKyBi L3hlbi9hcmNoL3g4Ni9odm0vZW11bGF0ZS5jCkBAIC0zMDgsNiArMzA4LDcg QEAgc3RhdGljIGludCBodm1lbXVsX2RvX2lvKAogICAgIHN3aXRjaCAoIHJj ICkKICAgICB7CiAgICAgY2FzZSBYODZFTVVMX09LQVk6CisgICAgY2FzZSBY ODZFTVVMX1JFVFJZOgogICAgICAgICB2aW8tPnJlcS5zdGF0ZSA9IFNUQVRF X0lPUkVRX05PTkU7CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgWDg2RU1V TF9VTkhBTkRMRUFCTEU6Ci0tIAoyLjUzLjAKCg== --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:00:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:00:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411333.1642085 (Exim 4.92) (envelope-from ) id 1x3uVV-00067a-F6; Tue, 08 Sep 2026 12:00:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411333.1642085; Tue, 08 Sep 2026 12:00:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVV-00066k-6R; Tue, 08 Sep 2026 12:00:57 +0000 Received: by outflank-mailman (input) for mailman id 1411333; Tue, 08 Sep 2026 12:00:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVS-0005zp-SD; Tue, 08 Sep 2026 12:00:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uVS-00H0es-8n; Tue, 08 Sep 2026 14:00:54 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ff8ef-bab6-0a2a0a5309dd-0a2a450691f0-26 for ; Tue, 08 Sep 2026 14:00:54 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ff8f4-195a-0a2a45060019-6882d725bd26-3 for ; Tue, 08 Sep 2026 14:00:53 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3uVI-004n4v-2j; Tue, 08 Sep 2026 12:00:45 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1x3uVJ-00GkHd-0R; Tue, 08 Sep 2026 12:00:45 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.510 (Entity 5.510) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team CC: Xen.org security team Subject: Xen Security Advisory 511 v3 (CVE-2026-79603) - Unconditionally do TLB flushing ahead of page scrubbing Message-Id: Date: Tue, 08 Sep 2026 12:00:45 +0000 X-purgate-ID: tlsNG-16d1c6/1788868854-1FCCD77B-EEAF3B43/0/0 X-purgate-type: clean X-purgate-size: 54589 --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2026-79603 / XSA-511 version 3 Unconditionally do TLB flushing ahead of page scrubbing UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= x86 PV guests can free memory pages while still keeping a stale TLB entry pointing to them. A TLB flush is only issued by Xen (if needed) when the page is re-used. Since it's possible for the page to be scrubbed ahead of the TLB flush, there's a window where a PV guest can modify an already scrubbed page. IMPACT ====== Deployments using `xsm=silo scrub-domheap` with the aim of not allowing the exchange of information amongst guests are not effective in the presence of PV guests. VULNERABLE SYSTEMS ================== All Xen versions from 4.13 onwards are vulnerable. Xen versions 4.12 and earlier are not vulnerable as they lack the `scrub-domheap` command line option. Only x86 PV guests can exploit the vulnerability. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered by Roger Pau Monné of AMD. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa511.patch xen-unstable - Xen 4.22.x xsa511-4.21.patch Xen 4.21.x xsa511-4.20.patch Xen 4.20.x xsa511-4.19.patch Xen 4.19.x xsa511-4.18.patch Xen 4.18.x - Xen 4.17.x $ sha256sum xsa511* ba3731960983ef88836f96655f917abb25447eab69fda1d9cf7f4e8203138403 xsa511.patch c05a2d9fb391739a9ed39aa9247be264eb039bdac74f2db3b51e20199e6234cd xsa511-4.18.patch 9653110b3e82ea5c28185d436b22231f39d6e875712a7c9c6882d8cb1bd0d406 xsa511-4.19.patch 0a475b8622d867210346612c5f97a9c3b7b638de2704d51fbd86317b6b11a840 xsa511-4.20.patch 61aa358aef962a1e4dda3dd45cac7436e395362e9b5f9314ad3c60d39231cb97 xsa511-4.21.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmqf98YMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZf6EH/3BoQ+95hSDLUYJzmWNdjdqwYpyrWe1RaMcXWfuM DuvbkEd6SIrtkhEmO8ZHSiBm2g5v9/SyXrm0L4NZ2+LcZWbOAx0PK9D3DOjpIZk2 LpQJg75GPWLkBZ62vgZlCzcXa0opVNSrmnJvYimoHvdplMpFQOhd7Ve3988XCx1G Mb7tKeQ7IdgAW0P/gMTGpunGL9dF58N2d8H5qbp5695tneszzW1UtAVB+4BxlEuh WenQ1hJVtEWznRTYvaEJ7v6CYBoY7TmeYkpZviGhTj8cuTWguMNrKuSitPkRNJ+P OLIQ/pz3E6PGhJxXWw8BpjkDzHf9ETACu1g+sa+18z6/+1o= =/FMW -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa511.patch" Content-Disposition: attachment; filename="xsa511.patch" Content-Transfer-Encoding: base64 RnJvbSA2MGFkMzM5N2Y3Y2U0MzJmYTQ1ZjQ4ZTMwMTRlMWJkYjc0NzkwZDg3 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u bmUgPHJvZ2VyQHhlbnByb2plY3Qub3JnPgpEYXRlOiBUdWUsIDQgQXVnIDIw MjYgMTI6MjM6MTkgKzAyMDAKU3ViamVjdDogW1BBVENIXSB4ZW4vcGFnZV9h bGxvYzogZW5zdXJlIFRMQiBmbHVzaCBpcyBkb25lIGFoZWFkIG9mIHBhZ2UK IHNjcnViYmluZwpNSU1FLVZlcnNpb246IDEuMApDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogOGJpdAoKVGhlIGN1cnJlbnQgd2F5IGluIHdoaWNoIGlkbGUgVExC IGZsdXNoIGFuZCBUTEIgZmx1c2hpbmcgd2hlbiBhbGxvY2F0aW5nIGEKcGFn ZSBhcmUgZG9uZSBhbGxvd3MgZm9yIHRoZSBzY3J1YmJpbmcgdG8gYmUgZG9u ZSBhaGVhZCBvZiB0aGUgVExCIGZsdXNoLgpBIFBWIGRvbWFpbiBjYW4gc3Rp bGwgaGF2ZSBhIFRMQiBlbnRyeSBmb3IgdGhlIHBhZ2UgYWZ0ZXIgc2NydWJi aW5nLCBhbmQKaGVuY2UgaXQgbWF5IGJlIGFibGUgdG8gbW9kaWZ5IGl0LiAg U3VjaCB1bmludGVuZGVkIHBhZ2UgYWNjZXNzaW5nIGFsbG93cwpkb21haW5z IHRvIHBvc3NpYmx5IGV4Y2hhbmdlIGluZm9ybWF0aW9uIGV2ZW4gd2hlbiBg eHNtPXNpbG8gc2NydWItZG9taGVhcGAKYXJlIGluIGVmZmVjdC4KClJlbW92 ZSB0aGUgTUVNRl9ub190bGJmbHVzaCBtZW1vcnkgYWxsb2NhdGlvbiBmbGFn LCBhbmQgcmVvcmRlciB0aGUKZmx1c2hpbmcgc28gaXQncyBhbHdheXMgZG9u ZSBhaGVhZCBvZiB0aGUgc2NydWJiaW5nIGluCmFsbG9jX3ssY29sb3JffWhl YXBfcGFnZXMoKS4gIFRoZSBzb2xlIHVzZXIgb2YgTUVNRl9ub190bGJmbHVz aCBpcwpwb3B1bGF0ZV9waHlzbWFwKCksIGFuZCBnaXZlbiB0aGUgY29uc3Ry YWlucyBhYm92ZSBpdCdzIG5vIGxvbmdlciBzYWZlCnRvIGRlZmVyIHRoZSBm bHVzaCwgaGVuY2UgdGhlIGZsYWcgcmVtb3ZhbCBhbmQgdGhlIGZvbGRpbmcg b2YgdGhlIGZsdXNoIGluCnRoZSBhbGxvY2F0b3IgZnVuY3Rpb24gaXRzZWxm LgoKVGhpcyBpcyBYU0EtNTExIC8gQ1ZFLTIwMjYtNzk2MDMuCgpGaXhlczog MjRmMWE1OGQxOTU0ICgibW06IG9wdGlvbiB0byBfYWx3YXlzXyBzY3J1YiBm cmVlZCBkb21oZWFwIHBhZ2VzIikKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1 IE1vbm7DqSA8cm9nZXJAeGVucHJvamVjdC5vcmc+ClJldmlld2VkLWJ5OiBK YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Ci0tLQogeGVuL2NvbW1v bi9tZW1vcnkuYyAgICAgfCAyMSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHhl bi9jb21tb24vcGFnZV9hbGxvYy5jIHwgMzQgKysrKysrKysrKysrKysrKysr Ky0tLS0tLS0tLS0tLS0tLQogeGVuL2luY2x1ZGUveGVuL21tLmggICAgfCAg MiAtLQogMyBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAzOCBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL21lbW9yeS5j IGIveGVuL2NvbW1vbi9tZW1vcnkuYwppbmRleCBlMjQ1YjE2MGQ0NjcuLmZm MmVkNjFmZTJmMiAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9tZW1vcnkuYwor KysgYi94ZW4vY29tbW9uL21lbW9yeS5jCkBAIC0yMzIsOCArMjMyLDYgQEAg c3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3BfYXJn cyAqYSkKICAgICB1bnNpZ25lZCBpbnQgaSwgajsKICAgICB4ZW5fcGZuX3Qg Z3BmbjsKICAgICBzdHJ1Y3QgZG9tYWluICpkID0gYS0+ZG9tYWluLCAqY3Vy cl9kID0gY3VycmVudC0+ZG9tYWluOwotICAgIGJvb2wgbmVlZF90bGJmbHVz aCA9IGZhbHNlOwotICAgIHVpbnQzMl90IHRsYmZsdXNoX3RpbWVzdGFtcCA9 IDA7CiAKICAgICBpZiAoICFndWVzdF9oYW5kbGVfc3VicmFuZ2Vfb2theShh LT5leHRlbnRfbGlzdCwgYS0+bnJfZG9uZSwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhLT5ucl9leHRlbnRzLTEpICkKQEAgLTI0 NSwxNSArMjQzLDYgQEAgc3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21hcChz dHJ1Y3QgbWVtb3BfYXJncyAqYSkKIAogICAgIGlmICggdW5saWtlbHkoIWQt PmNyZWF0aW9uX2ZpbmlzaGVkKSApCiAgICAgewotICAgICAgICAvKgotICAg ICAgICAgKiBXaXRoIE1FTUZfbm9fdGxiZmx1c2ggc2V0LCBhbGxvY19oZWFw X3BhZ2VzKCkgd2lsbCBpZ25vcmUKLSAgICAgICAgICogVExCLWZsdXNoZXMu IEFmdGVyIFZNIGNyZWF0aW9uLCB0aGlzIGlzIGEgc2VjdXJpdHkgaXNzdWUg KGl0IGNhbgotICAgICAgICAgKiBtYWtlIHBhZ2VzIGFjY2Vzc2libGUgdG8g Z3Vlc3QgQiwgd2hlbiBndWVzdCBBIG1heSBzdGlsbCBoYXZlIGEKLSAgICAg ICAgICogY2FjaGVkIG1hcHBpbmcgdG8gdGhlbSkuIFNvIHdlIGRvIHRoaXMg b25seSBkdXJpbmcgZG9tYWluIGNyZWF0aW9uLAotICAgICAgICAgKiB3aGVu IHRoZSBkb21haW4gaXRzZWxmIGhhcyBub3QgeWV0IGJlZW4gdW5wYXVzZWQg Zm9yIHRoZSBmaXJzdAotICAgICAgICAgKiB0aW1lLgotICAgICAgICAgKi8K LSAgICAgICAgYS0+bWVtZmxhZ3MgfD0gTUVNRl9ub190bGJmbHVzaDsKICAg ICAgICAgLyoKICAgICAgICAgICogV2l0aCBNRU1GX25vX2ljYWNoZV9mbHVz aCwgYWxsb2NfaGVhcF9wYWdlcygpIHdpbGwgc2tpcAogICAgICAgICAgKiBw ZXJmb3JtaW5nIGljYWNoZSBmbHVzaGVzLiBXZSBkbyBpdCBvbmx5IGJlZm9y ZSBkb21haW4KQEAgLTM5NiwxMyArMzg1LDYgQEAgc3RhdGljIHZvaWQgcG9w dWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3BfYXJncyAqYSkKICAgICAgICAg ICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgIH0KIAotICAgICAgICAg ICAgICAgIGlmICggdW5saWtlbHkoYS0+bWVtZmxhZ3MgJiBNRU1GX25vX3Rs YmZsdXNoKSApCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAg ICAgICBmb3IgKCBqID0gMDsgaiA8ICgxVSA8PCBhLT5leHRlbnRfb3JkZXIp OyBqKysgKQotICAgICAgICAgICAgICAgICAgICAgICAgYWNjdW11bGF0ZV90 bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBhZ2Vbal0sCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZ0bGJmbHVzaF90 aW1lc3RhbXApOwotICAgICAgICAgICAgICAgIH0KLQogICAgICAgICAgICAg ICAgIG1mbiA9IHBhZ2VfdG9fbWZuKHBhZ2UpOwogICAgICAgICAgICAgfQog CkBAIC00MTcsOSArMzk5LDYgQEAgc3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5 c21hcChzdHJ1Y3QgbWVtb3BfYXJncyAqYSkKICAgICB9CiAKIG91dDoKLSAg ICBpZiAoIG5lZWRfdGxiZmx1c2ggKQotICAgICAgICBmaWx0ZXJlZF9mbHVz aF90bGJfbWFzayh0bGJmbHVzaF90aW1lc3RhbXApOwotCiAgICAgaWYgKCBh LT5tZW1mbGFncyAmIE1FTUZfbm9faWNhY2hlX2ZsdXNoICkKICAgICAgICAg aW52YWxpZGF0ZV9pY2FjaGUoKTsKIApkaWZmIC0tZ2l0IGEveGVuL2NvbW1v bi9wYWdlX2FsbG9jLmMgYi94ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYwppbmRl eCA0MGZkYjVmYjk4YzIuLjJlZTlkNzMwZjBjMiAxMDA2NDQKLS0tIGEveGVu L2NvbW1vbi9wYWdlX2FsbG9jLmMKKysrIGIveGVuL2NvbW1vbi9wYWdlX2Fs bG9jLmMKQEAgLTEwOTksMTUgKzEwOTksMTcgQEAgc3RhdGljIHN0cnVjdCBw YWdlX2luZm8gKmFsbG9jX2hlYXBfcGFnZXMoCiAgICAgICAgIC8qIFByZXNl cnZlIFBHQ19uZWVkX3NjcnViIHNvIHdlIGNhbiBjaGVjayBpdCBhZnRlciBs b2NrIGlzIGRyb3BwZWQuICovCiAgICAgICAgIHBnW2ldLmNvdW50X2luZm8g PSBQR0Nfc3RhdGVfaW51c2UgfCAocGdbaV0uY291bnRfaW5mbyAmIFBHQ19u ZWVkX3NjcnViKTsKIAotICAgICAgICBpZiAoICEobWVtZmxhZ3MgJiBNRU1G X25vX3RsYmZsdXNoKSApCi0gICAgICAgICAgICBhY2N1bXVsYXRlX3RsYmZs dXNoKCZuZWVkX3RsYmZsdXNoLCAmcGdbaV0sCi0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZ0bGJmbHVzaF90aW1lc3RhbXApOworICAgICAg ICBhY2N1bXVsYXRlX3RsYmZsdXNoKCZuZWVkX3RsYmZsdXNoLCAmcGdbaV0s ICZ0bGJmbHVzaF90aW1lc3RhbXApOwogCiAgICAgICAgIGluaXRfZnJlZV9w YWdlX2ZpZWxkcygmcGdbaV0pOwogICAgIH0KIAogICAgIHNwaW5fdW5sb2Nr KCZoZWFwX2xvY2spOwogCisgICAgLyogRmx1c2ggYWhlYWQgb2Ygc2NydWJi aW5nOiBlbnN1cmUgbm8gUFYgZG9tYWluIGhhcyBhIHN0YWxlIFRMQiBlbnRy eS4gKi8KKyAgICBpZiAoIG5lZWRfdGxiZmx1c2ggKQorICAgICAgICBmaWx0 ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVzaF90aW1lc3RhbXApOworCiAg ICAgaWYgKCBmaXJzdF9kaXJ0eSAhPSBJTlZBTElEX0RJUlRZX0lEWCB8fAog ICAgICAgICAgKHNjcnViX2RlYnVnICYmICEobWVtZmxhZ3MgJiBNRU1GX25v X3NjcnViKSkgKQogICAgIHsKQEAgLTExNDMsOSArMTE0NSw2IEBAIHN0YXRp YyBzdHJ1Y3QgcGFnZV9pbmZvICphbGxvY19oZWFwX3BhZ2VzKAogICAgICAg ICB9CiAgICAgfQogCi0gICAgaWYgKCBuZWVkX3RsYmZsdXNoICkKLSAgICAg ICAgZmlsdGVyZWRfZmx1c2hfdGxiX21hc2sodGxiZmx1c2hfdGltZXN0YW1w KTsKLQogICAgIC8qCiAgICAgICogRW5zdXJlIGNhY2hlIGFuZCBSQU0gYXJl IGNvbnNpc3RlbnQgZm9yIHBsYXRmb3JtcyB3aGVyZSB0aGUgZ3Vlc3QKICAg ICAgKiBjYW4gY29udHJvbCBpdHMgb3duIHZpc2liaWxpdHkgb2YvdGhyb3Vn aCB0aGUgY2FjaGUuCkBAIC0xNDA1LDYgKzE0MDQsMTMgQEAgYm9vbCBzY3J1 Yl9mcmVlX3BhZ2VzKHZvaWQpCiAgICAgICAgICAgICAgICAgewogICAgICAg ICAgICAgICAgICAgICBpZiAoIHRlc3RfYml0KF9QR0NfbmVlZF9zY3J1Yiwg JnBnW2ldLmNvdW50X2luZm8pICkKICAgICAgICAgICAgICAgICAgICAgewor ICAgICAgICAgICAgICAgICAgICAgICAgYm9vbCBuZWVkX3RsYmZsdXNoID0g ZmFsc2U7CisgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB0bGJm bHVzaF90cyA9IDA7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGFjY3Vt dWxhdGVfdGxiZmx1c2goJm5lZWRfdGxiZmx1c2gsICZwZ1tpXSwgJnRsYmZs dXNoX3RzKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIGlmICggbmVlZF90 bGJmbHVzaCApCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlsdGVy ZWRfZmx1c2hfdGxiX21hc2sodGxiZmx1c2hfdHMpOworCiAgICAgICAgICAg ICAgICAgICAgICAgICBzY3J1Yl9vbmVfcGFnZSgmcGdbaV0sIHRydWUpOwog ICAgICAgICAgICAgICAgICAgICAgICAgLyoKICAgICAgICAgICAgICAgICAg ICAgICAgICAqIFdlIGNhbiBtb2RpZnkgY291bnRfaW5mbyB3aXRob3V0IGhv bGRpbmcgaGVhcApAQCAtMjA3Miw3ICsyMDc4LDcgQEAgc3RhdGljIHN0cnVj dCBwYWdlX2luZm8gKmFsbG9jX2NvbG9yX2hlYXBfcGFnZSh1bnNpZ25lZCBp bnQgbWVtZmxhZ3MsCiAgICAgdWludDMyX3QgdGxiZmx1c2hfdGltZXN0YW1w ID0gMDsKICAgICBib29sIG5lZWRfc2NydWI7CiAKLSAgICBpZiAoIG1lbWZs YWdzICYgfihNRU1GX25vX3JlZmNvdW50IHwgTUVNRl9ub19vd25lciB8IE1F TUZfbm9fdGxiZmx1c2ggfAorICAgIGlmICggbWVtZmxhZ3MgJiB+KE1FTUZf bm9fcmVmY291bnQgfCBNRU1GX25vX293bmVyIHwKICAgICAgICAgICAgICAg ICAgICAgICBNRU1GX25vX2ljYWNoZV9mbHVzaCB8IE1FTUZfbm9fc2NydWIp ICkKICAgICAgICAgcmV0dXJuIE5VTEw7CiAKQEAgLTIxMDEsMTMgKzIxMDcs MTYgQEAgc3RhdGljIHN0cnVjdCBwYWdlX2luZm8gKmFsbG9jX2NvbG9yX2hl YXBfcGFnZSh1bnNpZ25lZCBpbnQgbWVtZmxhZ3MsCiAgICAgZnJlZV9jb2xv cmVkX3BhZ2VzW2NvbG9yXS0tOwogICAgIHBhZ2VfbGlzdF9kZWwocGcsIGNv bG9yX2hlYXAoY29sb3IpKTsKIAotICAgIGlmICggIShtZW1mbGFncyAmIE1F TUZfbm9fdGxiZmx1c2gpICkKLSAgICAgICAgYWNjdW11bGF0ZV90bGJmbHVz aCgmbmVlZF90bGJmbHVzaCwgcGcsICZ0bGJmbHVzaF90aW1lc3RhbXApOwor ICAgIGFjY3VtdWxhdGVfdGxiZmx1c2goJm5lZWRfdGxiZmx1c2gsIHBnLCAm dGxiZmx1c2hfdGltZXN0YW1wKTsKIAogICAgIGluaXRfZnJlZV9wYWdlX2Zp ZWxkcyhwZyk7CiAKICAgICBzcGluX3VubG9jaygmaGVhcF9sb2NrKTsKIAor ICAgIC8qIEZsdXNoIGFoZWFkIG9mIHNjcnViYmluZzogZW5zdXJlIG5vIFBW IGRvbWFpbiBoYXMgYSBzdGFsZSBUTEIgZW50cnkuICovCisgICAgaWYgKCBu ZWVkX3RsYmZsdXNoICkKKyAgICAgICAgZmlsdGVyZWRfZmx1c2hfdGxiX21h c2sodGxiZmx1c2hfdGltZXN0YW1wKTsKKwogICAgIGlmICggIShtZW1mbGFn cyAmIE1FTUZfbm9fc2NydWIpICkKICAgICB7CiAgICAgICAgIGlmICggbmVl ZF9zY3J1YiApCkBAIC0yMTE2LDkgKzIxMjUsNiBAQCBzdGF0aWMgc3RydWN0 IHBhZ2VfaW5mbyAqYWxsb2NfY29sb3JfaGVhcF9wYWdlKHVuc2lnbmVkIGlu dCBtZW1mbGFncywKICAgICAgICAgICAgIGNoZWNrX29uZV9wYWdlKHBnKTsK ICAgICB9CiAKLSAgICBpZiAoIG5lZWRfdGxiZmx1c2ggKQotICAgICAgICBm aWx0ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVzaF90aW1lc3RhbXApOwot CiAgICAgZmx1c2hfcGFnZV90b19yYW0obWZuX3gocGFnZV90b19tZm4ocGcp KSwKICAgICAgICAgICAgICAgICAgICAgICAhKG1lbWZsYWdzICYgTUVNRl9u b19pY2FjaGVfZmx1c2gpKTsKIApAQCAtMzAzMyw5ICszMDM5LDcgQEAgc3Rh dGljIGJvb2wgcHJlcGFyZV9zdGF0aWNtZW1fcGFnZXMoc3RydWN0IHBhZ2Vf aW5mbyAqcGcsIHVuc2lnbmVkIGxvbmcgbnJfbWZucywKICAgICAgICAgICAg IGdvdG8gb3V0X2VycjsKICAgICAgICAgfQogCi0gICAgICAgIGlmICggISht ZW1mbGFncyAmIE1FTUZfbm9fdGxiZmx1c2gpICkKLSAgICAgICAgICAgIGFj Y3VtdWxhdGVfdGxiZmx1c2goJm5lZWRfdGxiZmx1c2gsICZwZ1tpXSwKLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnRsYmZsdXNoX3RpbWVz dGFtcCk7CisgICAgICAgIGFjY3VtdWxhdGVfdGxiZmx1c2goJm5lZWRfdGxi Zmx1c2gsICZwZ1tpXSwgJnRsYmZsdXNoX3RpbWVzdGFtcCk7CiAKICAgICAg ICAgLyoKICAgICAgICAgICogUHJlc2VydmUgZmxhZyBQR0Nfc3RhdGljIGFu ZCBjaGFuZ2UgcGFnZSBzdGF0ZQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv eGVuL21tLmggYi94ZW4vaW5jbHVkZS94ZW4vbW0uaAppbmRleCBiODBiZWMw MGMxMjQuLjM3OWE4ZTRjYmU1NiAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUv eGVuL21tLmgKKysrIGIveGVuL2luY2x1ZGUveGVuL21tLmgKQEAgLTIyMiw4 ICsyMjIsNiBAQCBzdHJ1Y3QgbnBmZWMgewogI2RlZmluZSAgTUVNRl9leGFj dF9ub2RlICAoMVU8PF9NRU1GX2V4YWN0X25vZGUpCiAjZGVmaW5lIF9NRU1G X25vX293bmVyICAgIDUKICNkZWZpbmUgIE1FTUZfbm9fb3duZXIgICAgKDFV PDxfTUVNRl9ub19vd25lcikKLSNkZWZpbmUgX01FTUZfbm9fdGxiZmx1c2gg NgotI2RlZmluZSAgTUVNRl9ub190bGJmbHVzaCAoMVU8PF9NRU1GX25vX3Rs YmZsdXNoKQogI2RlZmluZSBfTUVNRl9ub19pY2FjaGVfZmx1c2ggNwogI2Rl ZmluZSAgTUVNRl9ub19pY2FjaGVfZmx1c2ggKDFVPDxfTUVNRl9ub19pY2Fj aGVfZmx1c2gpCiAjZGVmaW5lIF9NRU1GX25vX3NjcnViICAgIDgKLS0gCjIu NTMuMAoK --=separator Content-Type: application/octet-stream; name="xsa511-4.18.patch" Content-Disposition: attachment; filename="xsa511-4.18.patch" Content-Transfer-Encoding: base64 RnJvbSA4YzAyMWExZGY5ZTAxZjBhNjczYmM4MjgwMzViMzllMjY1OTBmZjZm IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u bmUgPHJvZ2VyQHhlbnByb2plY3Qub3JnPgpEYXRlOiBUdWUsIDQgQXVnIDIw MjYgMTI6MjM6MTkgKzAyMDAKU3ViamVjdDogW1BBVENIXSB4ZW4vcGFnZV9h bGxvYzogZW5zdXJlIFRMQiBmbHVzaCBpcyBkb25lIGFoZWFkIG9mIHBhZ2UK IHNjcnViYmluZwpNSU1FLVZlcnNpb246IDEuMApDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogOGJpdAoKVGhlIGN1cnJlbnQgd2F5IGluIHdoaWNoIGlkbGUgVExC IGZsdXNoIGFuZCBUTEIgZmx1c2hpbmcgd2hlbiBhbGxvY2F0aW5nIGEKcGFn ZSBhcmUgZG9uZSBhbGxvd3MgZm9yIHRoZSBzY3J1YmJpbmcgdG8gYmUgZG9u ZSBhaGVhZCBvZiB0aGUgVExCIGZsdXNoLgpBIFBWIGRvbWFpbiBjYW4gc3Rp bGwgaGF2ZSBhIFRMQiBlbnRyeSBmb3IgdGhlIHBhZ2UgYWZ0ZXIgc2NydWJi aW5nLCBhbmQKaGVuY2UgaXQgbWF5IGJlIGFibGUgdG8gbW9kaWZ5IGl0LiAg U3VjaCB1bmludGVuZGVkIHBhZ2UgYWNjZXNzaW5nIGFsbG93cwpkb21haW5z IHRvIHBvc3NpYmx5IGV4Y2hhbmdlIGluZm9ybWF0aW9uIGV2ZW4gd2hlbiBg eHNtPXNpbG8gc2NydWItZG9taGVhcGAKYXJlIGluIGVmZmVjdC4KClJlbW92 ZSB0aGUgTUVNRl9ub190bGJmbHVzaCBtZW1vcnkgYWxsb2NhdGlvbiBmbGFn LCBhbmQgcmVvcmRlciB0aGUKZmx1c2hpbmcgc28gaXQncyBhbHdheXMgZG9u ZSBhaGVhZCBvZiB0aGUgc2NydWJiaW5nIGluCmFsbG9jX3ssY29sb3JffWhl YXBfcGFnZXMoKS4gIFRoZSBzb2xlIHVzZXIgb2YgTUVNRl9ub190bGJmbHVz aCBpcwpwb3B1bGF0ZV9waHlzbWFwKCksIGFuZCBnaXZlbiB0aGUgY29uc3Ry YWlucyBhYm92ZSBpdCdzIG5vIGxvbmdlciBzYWZlCnRvIGRlZmVyIHRoZSBm bHVzaCwgaGVuY2UgdGhlIGZsYWcgcmVtb3ZhbCBhbmQgdGhlIGZvbGRpbmcg b2YgdGhlIGZsdXNoIGluCnRoZSBhbGxvY2F0b3IgZnVuY3Rpb24gaXRzZWxm LgoKVGhpcyBpcyBYU0EtNTExIC8gQ1ZFLTIwMjYtNzk2MDMuCgpGaXhlczog MjRmMWE1OGQxOTU0ICgibW06IG9wdGlvbiB0byBfYWx3YXlzXyBzY3J1YiBm cmVlZCBkb21oZWFwIHBhZ2VzIikKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1 IE1vbm7DqSA8cm9nZXJAeGVucHJvamVjdC5vcmc+ClJldmlld2VkLWJ5OiBK YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Ci0tLQogeGVuL2NvbW1v bi9tZW1vcnkuYyAgICAgfCAyMSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHhl bi9jb21tb24vcGFnZV9hbGxvYy5jIHwgMjIgKysrKysrKysrKysrKy0tLS0t LS0tLQogeGVuL2luY2x1ZGUveGVuL21tLmggICAgfCAgMiAtLQogMyBmaWxl cyBjaGFuZ2VkLCAxMyBpbnNlcnRpb25zKCspLCAzMiBkZWxldGlvbnMoLSkK CmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL21lbW9yeS5jIGIveGVuL2NvbW1v bi9tZW1vcnkuYwppbmRleCA1MjUxYWIzNDM3NzguLjY0MGYzYTcwYWI1NCAx MDA2NDQKLS0tIGEveGVuL2NvbW1vbi9tZW1vcnkuYworKysgYi94ZW4vY29t bW9uL21lbW9yeS5jCkBAIC0xNjEsOCArMTYxLDYgQEAgc3RhdGljIHZvaWQg cG9wdWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3BfYXJncyAqYSkKICAgICB1 bnNpZ25lZCBpbnQgaSwgajsKICAgICB4ZW5fcGZuX3QgZ3BmbjsKICAgICBz dHJ1Y3QgZG9tYWluICpkID0gYS0+ZG9tYWluLCAqY3Vycl9kID0gY3VycmVu dC0+ZG9tYWluOwotICAgIGJvb2wgbmVlZF90bGJmbHVzaCA9IGZhbHNlOwot ICAgIHVpbnQzMl90IHRsYmZsdXNoX3RpbWVzdGFtcCA9IDA7CiAKICAgICBp ZiAoICFndWVzdF9oYW5kbGVfc3VicmFuZ2Vfb2theShhLT5leHRlbnRfbGlz dCwgYS0+bnJfZG9uZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhLT5ucl9leHRlbnRzLTEpICkKQEAgLTE3NCwxNSArMTcyLDYg QEAgc3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3Bf YXJncyAqYSkKIAogICAgIGlmICggdW5saWtlbHkoIWQtPmNyZWF0aW9uX2Zp bmlzaGVkKSApCiAgICAgewotICAgICAgICAvKgotICAgICAgICAgKiBXaXRo IE1FTUZfbm9fdGxiZmx1c2ggc2V0LCBhbGxvY19oZWFwX3BhZ2VzKCkgd2ls bCBpZ25vcmUKLSAgICAgICAgICogVExCLWZsdXNoZXMuIEFmdGVyIFZNIGNy ZWF0aW9uLCB0aGlzIGlzIGEgc2VjdXJpdHkgaXNzdWUgKGl0IGNhbgotICAg ICAgICAgKiBtYWtlIHBhZ2VzIGFjY2Vzc2libGUgdG8gZ3Vlc3QgQiwgd2hl biBndWVzdCBBIG1heSBzdGlsbCBoYXZlIGEKLSAgICAgICAgICogY2FjaGVk IG1hcHBpbmcgdG8gdGhlbSkuIFNvIHdlIGRvIHRoaXMgb25seSBkdXJpbmcg ZG9tYWluIGNyZWF0aW9uLAotICAgICAgICAgKiB3aGVuIHRoZSBkb21haW4g aXRzZWxmIGhhcyBub3QgeWV0IGJlZW4gdW5wYXVzZWQgZm9yIHRoZSBmaXJz dAotICAgICAgICAgKiB0aW1lLgotICAgICAgICAgKi8KLSAgICAgICAgYS0+ bWVtZmxhZ3MgfD0gTUVNRl9ub190bGJmbHVzaDsKICAgICAgICAgLyoKICAg ICAgICAgICogV2l0aCBNRU1GX25vX2ljYWNoZV9mbHVzaCwgYWxsb2NfaGVh cF9wYWdlcygpIHdpbGwgc2tpcAogICAgICAgICAgKiBwZXJmb3JtaW5nIGlj YWNoZSBmbHVzaGVzLiBXZSBkbyBpdCBvbmx5IGJlZm9yZSBkb21haW4KQEAg LTI4MiwxMyArMjcxLDYgQEAgc3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21h cChzdHJ1Y3QgbWVtb3BfYXJncyAqYSkKICAgICAgICAgICAgICAgICAgICAg Z290byBvdXQ7CiAgICAgICAgICAgICAgICAgfQogCi0gICAgICAgICAgICAg ICAgaWYgKCB1bmxpa2VseShhLT5tZW1mbGFncyAmIE1FTUZfbm9fdGxiZmx1 c2gpICkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAg IGZvciAoIGogPSAwOyBqIDwgKDFVIDw8IGEtPmV4dGVudF9vcmRlcik7IGor KyApCi0gICAgICAgICAgICAgICAgICAgICAgICBhY2N1bXVsYXRlX3RsYmZs dXNoKCZuZWVkX3RsYmZsdXNoLCAmcGFnZVtqXSwKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnRsYmZsdXNoX3RpbWVz dGFtcCk7Ci0gICAgICAgICAgICAgICAgfQotCiAgICAgICAgICAgICAgICAg bWZuID0gcGFnZV90b19tZm4ocGFnZSk7CiAgICAgICAgICAgICB9CiAKQEAg LTMwMyw5ICsyODUsNiBAQCBzdGF0aWMgdm9pZCBwb3B1bGF0ZV9waHlzbWFw KHN0cnVjdCBtZW1vcF9hcmdzICphKQogICAgIH0KIAogb3V0OgotICAgIGlm ICggbmVlZF90bGJmbHVzaCApCi0gICAgICAgIGZpbHRlcmVkX2ZsdXNoX3Rs Yl9tYXNrKHRsYmZsdXNoX3RpbWVzdGFtcCk7Ci0KICAgICBpZiAoIGEtPm1l bWZsYWdzICYgTUVNRl9ub19pY2FjaGVfZmx1c2ggKQogICAgICAgICBpbnZh bGlkYXRlX2ljYWNoZSgpOwogCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3Bh Z2VfYWxsb2MuYyBiL3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCmluZGV4IDli NWRmNzRmZGRhYi4uNWU4ODI0OWY1MDk5IDEwMDY0NAotLS0gYS94ZW4vY29t bW9uL3BhZ2VfYWxsb2MuYworKysgYi94ZW4vY29tbW9uL3BhZ2VfYWxsb2Mu YwpAQCAtMTAzMCw5ICsxMDMwLDcgQEAgc3RhdGljIHN0cnVjdCBwYWdlX2lu Zm8gKmFsbG9jX2hlYXBfcGFnZXMoCiAgICAgICAgIC8qIFByZXNlcnZlIFBH Q19uZWVkX3NjcnViIHNvIHdlIGNhbiBjaGVjayBpdCBhZnRlciBsb2NrIGlz IGRyb3BwZWQuICovCiAgICAgICAgIHBnW2ldLmNvdW50X2luZm8gPSBQR0Nf c3RhdGVfaW51c2UgfCAocGdbaV0uY291bnRfaW5mbyAmIFBHQ19uZWVkX3Nj cnViKTsKIAotICAgICAgICBpZiAoICEobWVtZmxhZ3MgJiBNRU1GX25vX3Rs YmZsdXNoKSApCi0gICAgICAgICAgICBhY2N1bXVsYXRlX3RsYmZsdXNoKCZu ZWVkX3RsYmZsdXNoLCAmcGdbaV0sCi0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICZ0bGJmbHVzaF90aW1lc3RhbXApOworICAgICAgICBhY2N1 bXVsYXRlX3RsYmZsdXNoKCZuZWVkX3RsYmZsdXNoLCAmcGdbaV0sICZ0bGJm bHVzaF90aW1lc3RhbXApOwogCiAgICAgICAgIC8qIEluaXRpYWxpc2UgZmll bGRzIHdoaWNoIGhhdmUgb3RoZXIgdXNlcyBmb3IgZnJlZSBwYWdlcy4gKi8K ICAgICAgICAgcGdbaV0udS5pbnVzZS50eXBlX2luZm8gPSBQR1RfVFlQRV9J TkZPX0lOSVRJQUxJWkVSOwpAQCAtMTA0Miw2ICsxMDQwLDEwIEBAIHN0YXRp YyBzdHJ1Y3QgcGFnZV9pbmZvICphbGxvY19oZWFwX3BhZ2VzKAogCiAgICAg c3Bpbl91bmxvY2soJmhlYXBfbG9jayk7CiAKKyAgICAvKiBGbHVzaCBhaGVh ZCBvZiBzY3J1YmJpbmc6IGVuc3VyZSBubyBQViBkb21haW4gaGFzIGEgc3Rh bGUgVExCIGVudHJ5LiAqLworICAgIGlmICggbmVlZF90bGJmbHVzaCApCisg ICAgICAgIGZpbHRlcmVkX2ZsdXNoX3RsYl9tYXNrKHRsYmZsdXNoX3RpbWVz dGFtcCk7CisKICAgICBpZiAoIGZpcnN0X2RpcnR5ICE9IElOVkFMSURfRElS VFlfSURYIHx8CiAgICAgICAgICAoc2NydWJfZGVidWcgJiYgIShtZW1mbGFn cyAmIE1FTUZfbm9fc2NydWIpKSApCiAgICAgewpAQCAtMTA2Niw5ICsxMDY4 LDYgQEAgc3RhdGljIHN0cnVjdCBwYWdlX2luZm8gKmFsbG9jX2hlYXBfcGFn ZXMoCiAgICAgICAgIH0KICAgICB9CiAKLSAgICBpZiAoIG5lZWRfdGxiZmx1 c2ggKQotICAgICAgICBmaWx0ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVz aF90aW1lc3RhbXApOwotCiAgICAgLyoKICAgICAgKiBFbnN1cmUgY2FjaGUg YW5kIFJBTSBhcmUgY29uc2lzdGVudCBmb3IgcGxhdGZvcm1zIHdoZXJlIHRo ZSBndWVzdAogICAgICAqIGNhbiBjb250cm9sIGl0cyBvd24gdmlzaWJpbGl0 eSBvZi90aHJvdWdoIHRoZSBjYWNoZS4KQEAgLTEzMTUsNiArMTMxNCwxMyBA QCBib29sIHNjcnViX2ZyZWVfcGFnZXModm9pZCkKICAgICAgICAgICAgICAg ICB7CiAgICAgICAgICAgICAgICAgICAgIGlmICggdGVzdF9iaXQoX1BHQ19u ZWVkX3NjcnViLCAmcGdbaV0uY291bnRfaW5mbykgKQogICAgICAgICAgICAg ICAgICAgICB7CisgICAgICAgICAgICAgICAgICAgICAgICBib29sIG5lZWRf dGxiZmx1c2ggPSBmYWxzZTsKKyAgICAgICAgICAgICAgICAgICAgICAgIHVp bnQzMl90IHRsYmZsdXNoX3RzID0gMDsKKworICAgICAgICAgICAgICAgICAg ICAgICAgYWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBn W2ldLCAmdGxiZmx1c2hfdHMpOworICAgICAgICAgICAgICAgICAgICAgICAg aWYgKCBuZWVkX3RsYmZsdXNoICkKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICBmaWx0ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVzaF90cyk7CisK ICAgICAgICAgICAgICAgICAgICAgICAgIHNjcnViX29uZV9wYWdlKCZwZ1tp XSk7CiAgICAgICAgICAgICAgICAgICAgICAgICAvKgogICAgICAgICAgICAg ICAgICAgICAgICAgICogV2UgY2FuIG1vZGlmeSBjb3VudF9pbmZvIHdpdGhv dXQgaG9sZGluZyBoZWFwCkBAIC0yNzkxLDkgKzI3OTcsNyBAQCBzdGF0aWMg Ym9vbCBwcmVwYXJlX3N0YXRpY21lbV9wYWdlcyhzdHJ1Y3QgcGFnZV9pbmZv ICpwZywgdW5zaWduZWQgbG9uZyBucl9tZm5zLAogICAgICAgICAgICAgZ290 byBvdXRfZXJyOwogICAgICAgICB9CiAKLSAgICAgICAgaWYgKCAhKG1lbWZs YWdzICYgTUVNRl9ub190bGJmbHVzaCkgKQotICAgICAgICAgICAgYWNjdW11 bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBnW2ldLAotICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAmdGxiZmx1c2hfdGltZXN0YW1w KTsKKyAgICAgICAgYWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVz aCwgJnBnW2ldLCAmdGxiZmx1c2hfdGltZXN0YW1wKTsKIAogICAgICAgICAv KgogICAgICAgICAgKiBQcmVzZXJ2ZSBmbGFnIFBHQ19zdGF0aWMgYW5kIGNo YW5nZSBwYWdlIHN0YXRlCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4v bW0uaCBiL3hlbi9pbmNsdWRlL3hlbi9tbS5oCmluZGV4IDhiYzVmNDI0OWQx Yi4uMWZlZjU0MmY2ZmJhIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS94ZW4v bW0uaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vbW0uaApAQCAtMTk3LDggKzE5 Nyw2IEBAIHN0cnVjdCBucGZlYyB7CiAjZGVmaW5lICBNRU1GX2V4YWN0X25v ZGUgICgxVTw8X01FTUZfZXhhY3Rfbm9kZSkKICNkZWZpbmUgX01FTUZfbm9f b3duZXIgICAgNQogI2RlZmluZSAgTUVNRl9ub19vd25lciAgICAoMVU8PF9N RU1GX25vX293bmVyKQotI2RlZmluZSBfTUVNRl9ub190bGJmbHVzaCA2Ci0j ZGVmaW5lICBNRU1GX25vX3RsYmZsdXNoICgxVTw8X01FTUZfbm9fdGxiZmx1 c2gpCiAjZGVmaW5lIF9NRU1GX25vX2ljYWNoZV9mbHVzaCA3CiAjZGVmaW5l ICBNRU1GX25vX2ljYWNoZV9mbHVzaCAoMVU8PF9NRU1GX25vX2ljYWNoZV9m bHVzaCkKICNkZWZpbmUgX01FTUZfbm9fc2NydWIgICAgOAotLSAKMi41My4w Cgo= --=separator Content-Type: application/octet-stream; name="xsa511-4.19.patch" Content-Disposition: attachment; filename="xsa511-4.19.patch" Content-Transfer-Encoding: base64 RnJvbSBkZTk0YzFlODJkNTc5ZDYxN2I2NmQzNDNmZTdhNWVhODc1NzdhYTYy IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u bmUgPHJvZ2VyQHhlbnByb2plY3Qub3JnPgpEYXRlOiBUdWUsIDQgQXVnIDIw MjYgMTI6MjM6MTkgKzAyMDAKU3ViamVjdDogW1BBVENIXSB4ZW4vcGFnZV9h bGxvYzogZW5zdXJlIFRMQiBmbHVzaCBpcyBkb25lIGFoZWFkIG9mIHBhZ2UK IHNjcnViYmluZwpNSU1FLVZlcnNpb246IDEuMApDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogOGJpdAoKVGhlIGN1cnJlbnQgd2F5IGluIHdoaWNoIGlkbGUgVExC IGZsdXNoIGFuZCBUTEIgZmx1c2hpbmcgd2hlbiBhbGxvY2F0aW5nIGEKcGFn ZSBhcmUgZG9uZSBhbGxvd3MgZm9yIHRoZSBzY3J1YmJpbmcgdG8gYmUgZG9u ZSBhaGVhZCBvZiB0aGUgVExCIGZsdXNoLgpBIFBWIGRvbWFpbiBjYW4gc3Rp bGwgaGF2ZSBhIFRMQiBlbnRyeSBmb3IgdGhlIHBhZ2UgYWZ0ZXIgc2NydWJi aW5nLCBhbmQKaGVuY2UgaXQgbWF5IGJlIGFibGUgdG8gbW9kaWZ5IGl0LiAg U3VjaCB1bmludGVuZGVkIHBhZ2UgYWNjZXNzaW5nIGFsbG93cwpkb21haW5z IHRvIHBvc3NpYmx5IGV4Y2hhbmdlIGluZm9ybWF0aW9uIGV2ZW4gd2hlbiBg eHNtPXNpbG8gc2NydWItZG9taGVhcGAKYXJlIGluIGVmZmVjdC4KClJlbW92 ZSB0aGUgTUVNRl9ub190bGJmbHVzaCBtZW1vcnkgYWxsb2NhdGlvbiBmbGFn LCBhbmQgcmVvcmRlciB0aGUKZmx1c2hpbmcgc28gaXQncyBhbHdheXMgZG9u ZSBhaGVhZCBvZiB0aGUgc2NydWJiaW5nIGluCmFsbG9jX3ssY29sb3JffWhl YXBfcGFnZXMoKS4gIFRoZSBzb2xlIHVzZXIgb2YgTUVNRl9ub190bGJmbHVz aCBpcwpwb3B1bGF0ZV9waHlzbWFwKCksIGFuZCBnaXZlbiB0aGUgY29uc3Ry YWlucyBhYm92ZSBpdCdzIG5vIGxvbmdlciBzYWZlCnRvIGRlZmVyIHRoZSBm bHVzaCwgaGVuY2UgdGhlIGZsYWcgcmVtb3ZhbCBhbmQgdGhlIGZvbGRpbmcg b2YgdGhlIGZsdXNoIGluCnRoZSBhbGxvY2F0b3IgZnVuY3Rpb24gaXRzZWxm LgoKVGhpcyBpcyBYU0EtNTExIC8gQ1ZFLTIwMjYtNzk2MDMuCgpGaXhlczog MjRmMWE1OGQxOTU0ICgibW06IG9wdGlvbiB0byBfYWx3YXlzXyBzY3J1YiBm cmVlZCBkb21oZWFwIHBhZ2VzIikKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1 IE1vbm7DqSA8cm9nZXJAeGVucHJvamVjdC5vcmc+ClJldmlld2VkLWJ5OiBK YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Ci0tLQogeGVuL2NvbW1v bi9tZW1vcnkuYyAgICAgfCAyMSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHhl bi9jb21tb24vcGFnZV9hbGxvYy5jIHwgMjIgKysrKysrKysrKysrKy0tLS0t LS0tLQogeGVuL2luY2x1ZGUveGVuL21tLmggICAgfCAgMiAtLQogMyBmaWxl cyBjaGFuZ2VkLCAxMyBpbnNlcnRpb25zKCspLCAzMiBkZWxldGlvbnMoLSkK CmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL21lbW9yeS5jIGIveGVuL2NvbW1v bi9tZW1vcnkuYwppbmRleCA3MjNhYjNjMGRhOGYuLmU2NWQzY2UzYjA0NiAx MDA2NDQKLS0tIGEveGVuL2NvbW1vbi9tZW1vcnkuYworKysgYi94ZW4vY29t bW9uL21lbW9yeS5jCkBAIC0xNjEsOCArMTYxLDYgQEAgc3RhdGljIHZvaWQg cG9wdWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3BfYXJncyAqYSkKICAgICB1 bnNpZ25lZCBpbnQgaSwgajsKICAgICB4ZW5fcGZuX3QgZ3BmbjsKICAgICBz dHJ1Y3QgZG9tYWluICpkID0gYS0+ZG9tYWluLCAqY3Vycl9kID0gY3VycmVu dC0+ZG9tYWluOwotICAgIGJvb2wgbmVlZF90bGJmbHVzaCA9IGZhbHNlOwot ICAgIHVpbnQzMl90IHRsYmZsdXNoX3RpbWVzdGFtcCA9IDA7CiAKICAgICBp ZiAoICFndWVzdF9oYW5kbGVfc3VicmFuZ2Vfb2theShhLT5leHRlbnRfbGlz dCwgYS0+bnJfZG9uZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhLT5ucl9leHRlbnRzLTEpICkKQEAgLTE3NCwxNSArMTcyLDYg QEAgc3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3Bf YXJncyAqYSkKIAogICAgIGlmICggdW5saWtlbHkoIWQtPmNyZWF0aW9uX2Zp bmlzaGVkKSApCiAgICAgewotICAgICAgICAvKgotICAgICAgICAgKiBXaXRo IE1FTUZfbm9fdGxiZmx1c2ggc2V0LCBhbGxvY19oZWFwX3BhZ2VzKCkgd2ls bCBpZ25vcmUKLSAgICAgICAgICogVExCLWZsdXNoZXMuIEFmdGVyIFZNIGNy ZWF0aW9uLCB0aGlzIGlzIGEgc2VjdXJpdHkgaXNzdWUgKGl0IGNhbgotICAg ICAgICAgKiBtYWtlIHBhZ2VzIGFjY2Vzc2libGUgdG8gZ3Vlc3QgQiwgd2hl biBndWVzdCBBIG1heSBzdGlsbCBoYXZlIGEKLSAgICAgICAgICogY2FjaGVk IG1hcHBpbmcgdG8gdGhlbSkuIFNvIHdlIGRvIHRoaXMgb25seSBkdXJpbmcg ZG9tYWluIGNyZWF0aW9uLAotICAgICAgICAgKiB3aGVuIHRoZSBkb21haW4g aXRzZWxmIGhhcyBub3QgeWV0IGJlZW4gdW5wYXVzZWQgZm9yIHRoZSBmaXJz dAotICAgICAgICAgKiB0aW1lLgotICAgICAgICAgKi8KLSAgICAgICAgYS0+ bWVtZmxhZ3MgfD0gTUVNRl9ub190bGJmbHVzaDsKICAgICAgICAgLyoKICAg ICAgICAgICogV2l0aCBNRU1GX25vX2ljYWNoZV9mbHVzaCwgYWxsb2NfaGVh cF9wYWdlcygpIHdpbGwgc2tpcAogICAgICAgICAgKiBwZXJmb3JtaW5nIGlj YWNoZSBmbHVzaGVzLiBXZSBkbyBpdCBvbmx5IGJlZm9yZSBkb21haW4KQEAg LTI4MiwxMyArMjcxLDYgQEAgc3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21h cChzdHJ1Y3QgbWVtb3BfYXJncyAqYSkKICAgICAgICAgICAgICAgICAgICAg Z290byBvdXQ7CiAgICAgICAgICAgICAgICAgfQogCi0gICAgICAgICAgICAg ICAgaWYgKCB1bmxpa2VseShhLT5tZW1mbGFncyAmIE1FTUZfbm9fdGxiZmx1 c2gpICkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAg IGZvciAoIGogPSAwOyBqIDwgKDFVIDw8IGEtPmV4dGVudF9vcmRlcik7IGor KyApCi0gICAgICAgICAgICAgICAgICAgICAgICBhY2N1bXVsYXRlX3RsYmZs dXNoKCZuZWVkX3RsYmZsdXNoLCAmcGFnZVtqXSwKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnRsYmZsdXNoX3RpbWVz dGFtcCk7Ci0gICAgICAgICAgICAgICAgfQotCiAgICAgICAgICAgICAgICAg bWZuID0gcGFnZV90b19tZm4ocGFnZSk7CiAgICAgICAgICAgICB9CiAKQEAg LTMwMyw5ICsyODUsNiBAQCBzdGF0aWMgdm9pZCBwb3B1bGF0ZV9waHlzbWFw KHN0cnVjdCBtZW1vcF9hcmdzICphKQogICAgIH0KIAogb3V0OgotICAgIGlm ICggbmVlZF90bGJmbHVzaCApCi0gICAgICAgIGZpbHRlcmVkX2ZsdXNoX3Rs Yl9tYXNrKHRsYmZsdXNoX3RpbWVzdGFtcCk7Ci0KICAgICBpZiAoIGEtPm1l bWZsYWdzICYgTUVNRl9ub19pY2FjaGVfZmx1c2ggKQogICAgICAgICBpbnZh bGlkYXRlX2ljYWNoZSgpOwogCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3Bh Z2VfYWxsb2MuYyBiL3hlbi9jb21tb24vcGFnZV9hbGxvYy5jCmluZGV4IGJi Yjg1Nzg0NTk2NS4uN2JkNTY1Y2QyN2JlIDEwMDY0NAotLS0gYS94ZW4vY29t bW9uL3BhZ2VfYWxsb2MuYworKysgYi94ZW4vY29tbW9uL3BhZ2VfYWxsb2Mu YwpAQCAtMTAzOCwxNSArMTAzOCwxNyBAQCBzdGF0aWMgc3RydWN0IHBhZ2Vf aW5mbyAqYWxsb2NfaGVhcF9wYWdlcygKICAgICAgICAgLyogUHJlc2VydmUg UEdDX25lZWRfc2NydWIgc28gd2UgY2FuIGNoZWNrIGl0IGFmdGVyIGxvY2sg aXMgZHJvcHBlZC4gKi8KICAgICAgICAgcGdbaV0uY291bnRfaW5mbyA9IFBH Q19zdGF0ZV9pbnVzZSB8IChwZ1tpXS5jb3VudF9pbmZvICYgUEdDX25lZWRf c2NydWIpOwogCi0gICAgICAgIGlmICggIShtZW1mbGFncyAmIE1FTUZfbm9f dGxiZmx1c2gpICkKLSAgICAgICAgICAgIGFjY3VtdWxhdGVfdGxiZmx1c2go Jm5lZWRfdGxiZmx1c2gsICZwZ1tpXSwKLSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJnRsYmZsdXNoX3RpbWVzdGFtcCk7CisgICAgICAgIGFj Y3VtdWxhdGVfdGxiZmx1c2goJm5lZWRfdGxiZmx1c2gsICZwZ1tpXSwgJnRs YmZsdXNoX3RpbWVzdGFtcCk7CiAKICAgICAgICAgaW5pdF9mcmVlX3BhZ2Vf ZmllbGRzKCZwZ1tpXSk7CiAgICAgfQogCiAgICAgc3Bpbl91bmxvY2soJmhl YXBfbG9jayk7CiAKKyAgICAvKiBGbHVzaCBhaGVhZCBvZiBzY3J1YmJpbmc6 IGVuc3VyZSBubyBQViBkb21haW4gaGFzIGEgc3RhbGUgVExCIGVudHJ5LiAq LworICAgIGlmICggbmVlZF90bGJmbHVzaCApCisgICAgICAgIGZpbHRlcmVk X2ZsdXNoX3RsYl9tYXNrKHRsYmZsdXNoX3RpbWVzdGFtcCk7CisKICAgICBp ZiAoIGZpcnN0X2RpcnR5ICE9IElOVkFMSURfRElSVFlfSURYIHx8CiAgICAg ICAgICAoc2NydWJfZGVidWcgJiYgIShtZW1mbGFncyAmIE1FTUZfbm9fc2Ny dWIpKSApCiAgICAgewpAQCAtMTA3MSw5ICsxMDczLDYgQEAgc3RhdGljIHN0 cnVjdCBwYWdlX2luZm8gKmFsbG9jX2hlYXBfcGFnZXMoCiAgICAgICAgIH0K ICAgICB9CiAKLSAgICBpZiAoIG5lZWRfdGxiZmx1c2ggKQotICAgICAgICBm aWx0ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVzaF90aW1lc3RhbXApOwot CiAgICAgLyoKICAgICAgKiBFbnN1cmUgY2FjaGUgYW5kIFJBTSBhcmUgY29u c2lzdGVudCBmb3IgcGxhdGZvcm1zIHdoZXJlIHRoZSBndWVzdAogICAgICAq IGNhbiBjb250cm9sIGl0cyBvd24gdmlzaWJpbGl0eSBvZi90aHJvdWdoIHRo ZSBjYWNoZS4KQEAgLTEzMjAsNiArMTMxOSwxMyBAQCBib29sIHNjcnViX2Zy ZWVfcGFnZXModm9pZCkKICAgICAgICAgICAgICAgICB7CiAgICAgICAgICAg ICAgICAgICAgIGlmICggdGVzdF9iaXQoX1BHQ19uZWVkX3NjcnViLCAmcGdb aV0uY291bnRfaW5mbykgKQogICAgICAgICAgICAgICAgICAgICB7CisgICAg ICAgICAgICAgICAgICAgICAgICBib29sIG5lZWRfdGxiZmx1c2ggPSBmYWxz ZTsKKyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHRsYmZsdXNo X3RzID0gMDsKKworICAgICAgICAgICAgICAgICAgICAgICAgYWNjdW11bGF0 ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBnW2ldLCAmdGxiZmx1c2hf dHMpOworICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCBuZWVkX3RsYmZs dXNoICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWx0ZXJlZF9m bHVzaF90bGJfbWFzayh0bGJmbHVzaF90cyk7CisKICAgICAgICAgICAgICAg ICAgICAgICAgIHNjcnViX29uZV9wYWdlKCZwZ1tpXSk7CiAgICAgICAgICAg ICAgICAgICAgICAgICAvKgogICAgICAgICAgICAgICAgICAgICAgICAgICog V2UgY2FuIG1vZGlmeSBjb3VudF9pbmZvIHdpdGhvdXQgaG9sZGluZyBoZWFw CkBAIC0yNzk2LDkgKzI4MDIsNyBAQCBzdGF0aWMgYm9vbCBwcmVwYXJlX3N0 YXRpY21lbV9wYWdlcyhzdHJ1Y3QgcGFnZV9pbmZvICpwZywgdW5zaWduZWQg bG9uZyBucl9tZm5zLAogICAgICAgICAgICAgZ290byBvdXRfZXJyOwogICAg ICAgICB9CiAKLSAgICAgICAgaWYgKCAhKG1lbWZsYWdzICYgTUVNRl9ub190 bGJmbHVzaCkgKQotICAgICAgICAgICAgYWNjdW11bGF0ZV90bGJmbHVzaCgm bmVlZF90bGJmbHVzaCwgJnBnW2ldLAotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmdGxiZmx1c2hfdGltZXN0YW1wKTsKKyAgICAgICAgYWNj dW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBnW2ldLCAmdGxi Zmx1c2hfdGltZXN0YW1wKTsKIAogICAgICAgICAvKgogICAgICAgICAgKiBQ cmVzZXJ2ZSBmbGFnIFBHQ19zdGF0aWMgYW5kIGNoYW5nZSBwYWdlIHN0YXRl CmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vbW0uaCBiL3hlbi9pbmNs dWRlL3hlbi9tbS5oCmluZGV4IDc1NjEyOTdhNzU1My4uY2M3ODUyNjYyYTQ4 IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS94ZW4vbW0uaAorKysgYi94ZW4v aW5jbHVkZS94ZW4vbW0uaApAQCAtMjAwLDggKzIwMCw2IEBAIHN0cnVjdCBu cGZlYyB7CiAjZGVmaW5lICBNRU1GX2V4YWN0X25vZGUgICgxVTw8X01FTUZf ZXhhY3Rfbm9kZSkKICNkZWZpbmUgX01FTUZfbm9fb3duZXIgICAgNQogI2Rl ZmluZSAgTUVNRl9ub19vd25lciAgICAoMVU8PF9NRU1GX25vX293bmVyKQot I2RlZmluZSBfTUVNRl9ub190bGJmbHVzaCA2Ci0jZGVmaW5lICBNRU1GX25v X3RsYmZsdXNoICgxVTw8X01FTUZfbm9fdGxiZmx1c2gpCiAjZGVmaW5lIF9N RU1GX25vX2ljYWNoZV9mbHVzaCA3CiAjZGVmaW5lICBNRU1GX25vX2ljYWNo ZV9mbHVzaCAoMVU8PF9NRU1GX25vX2ljYWNoZV9mbHVzaCkKICNkZWZpbmUg X01FTUZfbm9fc2NydWIgICAgOAotLSAKMi41My4wCgo= --=separator Content-Type: application/octet-stream; name="xsa511-4.20.patch" Content-Disposition: attachment; filename="xsa511-4.20.patch" Content-Transfer-Encoding: base64 RnJvbSA3NDFlZTVhYjczMDMyMDAwOTgzMjJmZjVlODczMmQ0MDlmMzU2OTgx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u bmUgPHJvZ2VyQHhlbnByb2plY3Qub3JnPgpEYXRlOiBUdWUsIDQgQXVnIDIw MjYgMTI6MjM6MTkgKzAyMDAKU3ViamVjdDogW1BBVENIXSB4ZW4vcGFnZV9h bGxvYzogZW5zdXJlIFRMQiBmbHVzaCBpcyBkb25lIGFoZWFkIG9mIHBhZ2UK IHNjcnViYmluZwpNSU1FLVZlcnNpb246IDEuMApDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogOGJpdAoKVGhlIGN1cnJlbnQgd2F5IGluIHdoaWNoIGlkbGUgVExC IGZsdXNoIGFuZCBUTEIgZmx1c2hpbmcgd2hlbiBhbGxvY2F0aW5nIGEKcGFn ZSBhcmUgZG9uZSBhbGxvd3MgZm9yIHRoZSBzY3J1YmJpbmcgdG8gYmUgZG9u ZSBhaGVhZCBvZiB0aGUgVExCIGZsdXNoLgpBIFBWIGRvbWFpbiBjYW4gc3Rp bGwgaGF2ZSBhIFRMQiBlbnRyeSBmb3IgdGhlIHBhZ2UgYWZ0ZXIgc2NydWJi aW5nLCBhbmQKaGVuY2UgaXQgbWF5IGJlIGFibGUgdG8gbW9kaWZ5IGl0LiAg U3VjaCB1bmludGVuZGVkIHBhZ2UgYWNjZXNzaW5nIGFsbG93cwpkb21haW5z IHRvIHBvc3NpYmx5IGV4Y2hhbmdlIGluZm9ybWF0aW9uIGV2ZW4gd2hlbiBg eHNtPXNpbG8gc2NydWItZG9taGVhcGAKYXJlIGluIGVmZmVjdC4KClJlbW92 ZSB0aGUgTUVNRl9ub190bGJmbHVzaCBtZW1vcnkgYWxsb2NhdGlvbiBmbGFn LCBhbmQgcmVvcmRlciB0aGUKZmx1c2hpbmcgc28gaXQncyBhbHdheXMgZG9u ZSBhaGVhZCBvZiB0aGUgc2NydWJiaW5nIGluCmFsbG9jX3ssY29sb3JffWhl YXBfcGFnZXMoKS4gIFRoZSBzb2xlIHVzZXIgb2YgTUVNRl9ub190bGJmbHVz aCBpcwpwb3B1bGF0ZV9waHlzbWFwKCksIGFuZCBnaXZlbiB0aGUgY29uc3Ry YWlucyBhYm92ZSBpdCdzIG5vIGxvbmdlciBzYWZlCnRvIGRlZmVyIHRoZSBm bHVzaCwgaGVuY2UgdGhlIGZsYWcgcmVtb3ZhbCBhbmQgdGhlIGZvbGRpbmcg b2YgdGhlIGZsdXNoIGluCnRoZSBhbGxvY2F0b3IgZnVuY3Rpb24gaXRzZWxm LgoKVGhpcyBpcyBYU0EtNTExIC8gQ1ZFLTIwMjYtNzk2MDMuCgpGaXhlczog MjRmMWE1OGQxOTU0ICgibW06IG9wdGlvbiB0byBfYWx3YXlzXyBzY3J1YiBm cmVlZCBkb21oZWFwIHBhZ2VzIikKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1 IE1vbm7DqSA8cm9nZXJAeGVucHJvamVjdC5vcmc+ClJldmlld2VkLWJ5OiBK YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Ci0tLQogeGVuL2NvbW1v bi9tZW1vcnkuYyAgICAgfCAyMSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHhl bi9jb21tb24vcGFnZV9hbGxvYy5jIHwgMzQgKysrKysrKysrKysrKysrKysr Ky0tLS0tLS0tLS0tLS0tLQogeGVuL2luY2x1ZGUveGVuL21tLmggICAgfCAg MiAtLQogMyBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAzOCBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL21lbW9yeS5j IGIveGVuL2NvbW1vbi9tZW1vcnkuYwppbmRleCA3YTAwYmY5NWRkY2YuLjU0 ZDJkNjBmY2M1ZiAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9tZW1vcnkuYwor KysgYi94ZW4vY29tbW9uL21lbW9yeS5jCkBAIC0xNjMsOCArMTYzLDYgQEAg c3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3BfYXJn cyAqYSkKICAgICB1bnNpZ25lZCBpbnQgaSwgajsKICAgICB4ZW5fcGZuX3Qg Z3BmbjsKICAgICBzdHJ1Y3QgZG9tYWluICpkID0gYS0+ZG9tYWluLCAqY3Vy cl9kID0gY3VycmVudC0+ZG9tYWluOwotICAgIGJvb2wgbmVlZF90bGJmbHVz aCA9IGZhbHNlOwotICAgIHVpbnQzMl90IHRsYmZsdXNoX3RpbWVzdGFtcCA9 IDA7CiAKICAgICBpZiAoICFndWVzdF9oYW5kbGVfc3VicmFuZ2Vfb2theShh LT5leHRlbnRfbGlzdCwgYS0+bnJfZG9uZSwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhLT5ucl9leHRlbnRzLTEpICkKQEAgLTE3 NiwxNSArMTc0LDYgQEAgc3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21hcChz dHJ1Y3QgbWVtb3BfYXJncyAqYSkKIAogICAgIGlmICggdW5saWtlbHkoIWQt PmNyZWF0aW9uX2ZpbmlzaGVkKSApCiAgICAgewotICAgICAgICAvKgotICAg ICAgICAgKiBXaXRoIE1FTUZfbm9fdGxiZmx1c2ggc2V0LCBhbGxvY19oZWFw X3BhZ2VzKCkgd2lsbCBpZ25vcmUKLSAgICAgICAgICogVExCLWZsdXNoZXMu IEFmdGVyIFZNIGNyZWF0aW9uLCB0aGlzIGlzIGEgc2VjdXJpdHkgaXNzdWUg KGl0IGNhbgotICAgICAgICAgKiBtYWtlIHBhZ2VzIGFjY2Vzc2libGUgdG8g Z3Vlc3QgQiwgd2hlbiBndWVzdCBBIG1heSBzdGlsbCBoYXZlIGEKLSAgICAg ICAgICogY2FjaGVkIG1hcHBpbmcgdG8gdGhlbSkuIFNvIHdlIGRvIHRoaXMg b25seSBkdXJpbmcgZG9tYWluIGNyZWF0aW9uLAotICAgICAgICAgKiB3aGVu IHRoZSBkb21haW4gaXRzZWxmIGhhcyBub3QgeWV0IGJlZW4gdW5wYXVzZWQg Zm9yIHRoZSBmaXJzdAotICAgICAgICAgKiB0aW1lLgotICAgICAgICAgKi8K LSAgICAgICAgYS0+bWVtZmxhZ3MgfD0gTUVNRl9ub190bGJmbHVzaDsKICAg ICAgICAgLyoKICAgICAgICAgICogV2l0aCBNRU1GX25vX2ljYWNoZV9mbHVz aCwgYWxsb2NfaGVhcF9wYWdlcygpIHdpbGwgc2tpcAogICAgICAgICAgKiBw ZXJmb3JtaW5nIGljYWNoZSBmbHVzaGVzLiBXZSBkbyBpdCBvbmx5IGJlZm9y ZSBkb21haW4KQEAgLTI4NCwxMyArMjczLDYgQEAgc3RhdGljIHZvaWQgcG9w dWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3BfYXJncyAqYSkKICAgICAgICAg ICAgICAgICAgICAgZ290byBvdXQ7CiAgICAgICAgICAgICAgICAgfQogCi0g ICAgICAgICAgICAgICAgaWYgKCB1bmxpa2VseShhLT5tZW1mbGFncyAmIE1F TUZfbm9fdGxiZmx1c2gpICkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAg ICAgICAgICAgICAgIGZvciAoIGogPSAwOyBqIDwgKDFVIDw8IGEtPmV4dGVu dF9vcmRlcik7IGorKyApCi0gICAgICAgICAgICAgICAgICAgICAgICBhY2N1 bXVsYXRlX3RsYmZsdXNoKCZuZWVkX3RsYmZsdXNoLCAmcGFnZVtqXSwKLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnRs YmZsdXNoX3RpbWVzdGFtcCk7Ci0gICAgICAgICAgICAgICAgfQotCiAgICAg ICAgICAgICAgICAgbWZuID0gcGFnZV90b19tZm4ocGFnZSk7CiAgICAgICAg ICAgICB9CiAKQEAgLTMwNSw5ICsyODcsNiBAQCBzdGF0aWMgdm9pZCBwb3B1 bGF0ZV9waHlzbWFwKHN0cnVjdCBtZW1vcF9hcmdzICphKQogICAgIH0KIAog b3V0OgotICAgIGlmICggbmVlZF90bGJmbHVzaCApCi0gICAgICAgIGZpbHRl cmVkX2ZsdXNoX3RsYl9tYXNrKHRsYmZsdXNoX3RpbWVzdGFtcCk7Ci0KICAg ICBpZiAoIGEtPm1lbWZsYWdzICYgTUVNRl9ub19pY2FjaGVfZmx1c2ggKQog ICAgICAgICBpbnZhbGlkYXRlX2ljYWNoZSgpOwogCmRpZmYgLS1naXQgYS94 ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYyBiL3hlbi9jb21tb24vcGFnZV9hbGxv Yy5jCmluZGV4IDBhMGViYzE1OTgxYi4uMjY4MmZmZjljY2JjIDEwMDY0NAot LS0gYS94ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYworKysgYi94ZW4vY29tbW9u L3BhZ2VfYWxsb2MuYwpAQCAtMTA2OCwxNSArMTA2OCwxNyBAQCBzdGF0aWMg c3RydWN0IHBhZ2VfaW5mbyAqYWxsb2NfaGVhcF9wYWdlcygKICAgICAgICAg LyogUHJlc2VydmUgUEdDX25lZWRfc2NydWIgc28gd2UgY2FuIGNoZWNrIGl0 IGFmdGVyIGxvY2sgaXMgZHJvcHBlZC4gKi8KICAgICAgICAgcGdbaV0uY291 bnRfaW5mbyA9IFBHQ19zdGF0ZV9pbnVzZSB8IChwZ1tpXS5jb3VudF9pbmZv ICYgUEdDX25lZWRfc2NydWIpOwogCi0gICAgICAgIGlmICggIShtZW1mbGFn cyAmIE1FTUZfbm9fdGxiZmx1c2gpICkKLSAgICAgICAgICAgIGFjY3VtdWxh dGVfdGxiZmx1c2goJm5lZWRfdGxiZmx1c2gsICZwZ1tpXSwKLSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJnRsYmZsdXNoX3RpbWVzdGFtcCk7 CisgICAgICAgIGFjY3VtdWxhdGVfdGxiZmx1c2goJm5lZWRfdGxiZmx1c2gs ICZwZ1tpXSwgJnRsYmZsdXNoX3RpbWVzdGFtcCk7CiAKICAgICAgICAgaW5p dF9mcmVlX3BhZ2VfZmllbGRzKCZwZ1tpXSk7CiAgICAgfQogCiAgICAgc3Bp bl91bmxvY2soJmhlYXBfbG9jayk7CiAKKyAgICAvKiBGbHVzaCBhaGVhZCBv ZiBzY3J1YmJpbmc6IGVuc3VyZSBubyBQViBkb21haW4gaGFzIGEgc3RhbGUg VExCIGVudHJ5LiAqLworICAgIGlmICggbmVlZF90bGJmbHVzaCApCisgICAg ICAgIGZpbHRlcmVkX2ZsdXNoX3RsYl9tYXNrKHRsYmZsdXNoX3RpbWVzdGFt cCk7CisKICAgICBpZiAoIGZpcnN0X2RpcnR5ICE9IElOVkFMSURfRElSVFlf SURYIHx8CiAgICAgICAgICAoc2NydWJfZGVidWcgJiYgIShtZW1mbGFncyAm IE1FTUZfbm9fc2NydWIpKSApCiAgICAgewpAQCAtMTEwMSw5ICsxMTAzLDYg QEAgc3RhdGljIHN0cnVjdCBwYWdlX2luZm8gKmFsbG9jX2hlYXBfcGFnZXMo CiAgICAgICAgIH0KICAgICB9CiAKLSAgICBpZiAoIG5lZWRfdGxiZmx1c2gg KQotICAgICAgICBmaWx0ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVzaF90 aW1lc3RhbXApOwotCiAgICAgLyoKICAgICAgKiBFbnN1cmUgY2FjaGUgYW5k IFJBTSBhcmUgY29uc2lzdGVudCBmb3IgcGxhdGZvcm1zIHdoZXJlIHRoZSBn dWVzdAogICAgICAqIGNhbiBjb250cm9sIGl0cyBvd24gdmlzaWJpbGl0eSBv Zi90aHJvdWdoIHRoZSBjYWNoZS4KQEAgLTEzNTcsNiArMTM1NiwxMyBAQCBi b29sIHNjcnViX2ZyZWVfcGFnZXModm9pZCkKICAgICAgICAgICAgICAgICB7 CiAgICAgICAgICAgICAgICAgICAgIGlmICggdGVzdF9iaXQoX1BHQ19uZWVk X3NjcnViLCAmcGdbaV0uY291bnRfaW5mbykgKQogICAgICAgICAgICAgICAg ICAgICB7CisgICAgICAgICAgICAgICAgICAgICAgICBib29sIG5lZWRfdGxi Zmx1c2ggPSBmYWxzZTsKKyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQz Ml90IHRsYmZsdXNoX3RzID0gMDsKKworICAgICAgICAgICAgICAgICAgICAg ICAgYWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBnW2ld LCAmdGxiZmx1c2hfdHMpOworICAgICAgICAgICAgICAgICAgICAgICAgaWYg KCBuZWVkX3RsYmZsdXNoICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICBmaWx0ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVzaF90cyk7CisKICAg ICAgICAgICAgICAgICAgICAgICAgIHNjcnViX29uZV9wYWdlKCZwZ1tpXSk7 CiAgICAgICAgICAgICAgICAgICAgICAgICAvKgogICAgICAgICAgICAgICAg ICAgICAgICAgICogV2UgY2FuIG1vZGlmeSBjb3VudF9pbmZvIHdpdGhvdXQg aG9sZGluZyBoZWFwCkBAIC0yMDQwLDcgKzIwNDYsNyBAQCBzdGF0aWMgc3Ry dWN0IHBhZ2VfaW5mbyAqYWxsb2NfY29sb3JfaGVhcF9wYWdlKHVuc2lnbmVk IGludCBtZW1mbGFncywKICAgICB1aW50MzJfdCB0bGJmbHVzaF90aW1lc3Rh bXAgPSAwOwogICAgIGJvb2wgbmVlZF9zY3J1YjsKIAotICAgIGlmICggbWVt ZmxhZ3MgJiB+KE1FTUZfbm9fcmVmY291bnQgfCBNRU1GX25vX293bmVyIHwg TUVNRl9ub190bGJmbHVzaCB8CisgICAgaWYgKCBtZW1mbGFncyAmIH4oTUVN Rl9ub19yZWZjb3VudCB8IE1FTUZfbm9fb3duZXIgfAogICAgICAgICAgICAg ICAgICAgICAgIE1FTUZfbm9faWNhY2hlX2ZsdXNoIHwgTUVNRl9ub19zY3J1 YikgKQogICAgICAgICByZXR1cm4gTlVMTDsKIApAQCAtMjA2OSwxMyArMjA3 NSwxNiBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxsb2NfY29sb3Jf aGVhcF9wYWdlKHVuc2lnbmVkIGludCBtZW1mbGFncywKICAgICBmcmVlX2Nv bG9yZWRfcGFnZXNbY29sb3JdLS07CiAgICAgcGFnZV9saXN0X2RlbChwZywg Y29sb3JfaGVhcChjb2xvcikpOwogCi0gICAgaWYgKCAhKG1lbWZsYWdzICYg TUVNRl9ub190bGJmbHVzaCkgKQotICAgICAgICBhY2N1bXVsYXRlX3RsYmZs dXNoKCZuZWVkX3RsYmZsdXNoLCBwZywgJnRsYmZsdXNoX3RpbWVzdGFtcCk7 CisgICAgYWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgcGcs ICZ0bGJmbHVzaF90aW1lc3RhbXApOwogCiAgICAgaW5pdF9mcmVlX3BhZ2Vf ZmllbGRzKHBnKTsKIAogICAgIHNwaW5fdW5sb2NrKCZoZWFwX2xvY2spOwog CisgICAgLyogRmx1c2ggYWhlYWQgb2Ygc2NydWJiaW5nOiBlbnN1cmUgbm8g UFYgZG9tYWluIGhhcyBhIHN0YWxlIFRMQiBlbnRyeS4gKi8KKyAgICBpZiAo IG5lZWRfdGxiZmx1c2ggKQorICAgICAgICBmaWx0ZXJlZF9mbHVzaF90bGJf bWFzayh0bGJmbHVzaF90aW1lc3RhbXApOworCiAgICAgaWYgKCAhKG1lbWZs YWdzICYgTUVNRl9ub19zY3J1YikgKQogICAgIHsKICAgICAgICAgaWYgKCBu ZWVkX3NjcnViICkKQEAgLTIwODQsOSArMjA5Myw2IEBAIHN0YXRpYyBzdHJ1 Y3QgcGFnZV9pbmZvICphbGxvY19jb2xvcl9oZWFwX3BhZ2UodW5zaWduZWQg aW50IG1lbWZsYWdzLAogICAgICAgICAgICAgY2hlY2tfb25lX3BhZ2UocGcp OwogICAgIH0KIAotICAgIGlmICggbmVlZF90bGJmbHVzaCApCi0gICAgICAg IGZpbHRlcmVkX2ZsdXNoX3RsYl9tYXNrKHRsYmZsdXNoX3RpbWVzdGFtcCk7 Ci0KICAgICBmbHVzaF9wYWdlX3RvX3JhbShtZm5feChwYWdlX3RvX21mbihw ZykpLAogICAgICAgICAgICAgICAgICAgICAgICEobWVtZmxhZ3MgJiBNRU1G X25vX2ljYWNoZV9mbHVzaCkpOwogCkBAIC0yOTk5LDkgKzMwMDUsNyBAQCBz dGF0aWMgYm9vbCBwcmVwYXJlX3N0YXRpY21lbV9wYWdlcyhzdHJ1Y3QgcGFn ZV9pbmZvICpwZywgdW5zaWduZWQgbG9uZyBucl9tZm5zLAogICAgICAgICAg ICAgZ290byBvdXRfZXJyOwogICAgICAgICB9CiAKLSAgICAgICAgaWYgKCAh KG1lbWZsYWdzICYgTUVNRl9ub190bGJmbHVzaCkgKQotICAgICAgICAgICAg YWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBnW2ldLAot ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmdGxiZmx1c2hfdGlt ZXN0YW1wKTsKKyAgICAgICAgYWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90 bGJmbHVzaCwgJnBnW2ldLCAmdGxiZmx1c2hfdGltZXN0YW1wKTsKIAogICAg ICAgICAvKgogICAgICAgICAgKiBQcmVzZXJ2ZSBmbGFnIFBHQ19zdGF0aWMg YW5kIGNoYW5nZSBwYWdlIHN0YXRlCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVk ZS94ZW4vbW0uaCBiL3hlbi9pbmNsdWRlL3hlbi9tbS5oCmluZGV4IDE2Zjcz MzI4MWFmMy4uZDEyODU0MWUyY2Y4IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVk ZS94ZW4vbW0uaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vbW0uaApAQCAtMjAy LDggKzIwMiw2IEBAIHN0cnVjdCBucGZlYyB7CiAjZGVmaW5lICBNRU1GX2V4 YWN0X25vZGUgICgxVTw8X01FTUZfZXhhY3Rfbm9kZSkKICNkZWZpbmUgX01F TUZfbm9fb3duZXIgICAgNQogI2RlZmluZSAgTUVNRl9ub19vd25lciAgICAo MVU8PF9NRU1GX25vX293bmVyKQotI2RlZmluZSBfTUVNRl9ub190bGJmbHVz aCA2Ci0jZGVmaW5lICBNRU1GX25vX3RsYmZsdXNoICgxVTw8X01FTUZfbm9f dGxiZmx1c2gpCiAjZGVmaW5lIF9NRU1GX25vX2ljYWNoZV9mbHVzaCA3CiAj ZGVmaW5lICBNRU1GX25vX2ljYWNoZV9mbHVzaCAoMVU8PF9NRU1GX25vX2lj YWNoZV9mbHVzaCkKICNkZWZpbmUgX01FTUZfbm9fc2NydWIgICAgOAotLSAK Mi41My4wCgo= --=separator Content-Type: application/octet-stream; name="xsa511-4.21.patch" Content-Disposition: attachment; filename="xsa511-4.21.patch" Content-Transfer-Encoding: base64 RnJvbSA3MGUyODE0MjJhZDFlZTVlOGY5Y2IyZGJhYWQ0MThkYjA4ZGM1YmRh IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9u bmUgPHJvZ2VyQHhlbnByb2plY3Qub3JnPgpEYXRlOiBUdWUsIDQgQXVnIDIw MjYgMTI6MjM6MTkgKzAyMDAKU3ViamVjdDogW1BBVENIXSB4ZW4vcGFnZV9h bGxvYzogZW5zdXJlIFRMQiBmbHVzaCBpcyBkb25lIGFoZWFkIG9mIHBhZ2UK IHNjcnViYmluZwpNSU1FLVZlcnNpb246IDEuMApDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1FbmNv ZGluZzogOGJpdAoKVGhlIGN1cnJlbnQgd2F5IGluIHdoaWNoIGlkbGUgVExC IGZsdXNoIGFuZCBUTEIgZmx1c2hpbmcgd2hlbiBhbGxvY2F0aW5nIGEKcGFn ZSBhcmUgZG9uZSBhbGxvd3MgZm9yIHRoZSBzY3J1YmJpbmcgdG8gYmUgZG9u ZSBhaGVhZCBvZiB0aGUgVExCIGZsdXNoLgpBIFBWIGRvbWFpbiBjYW4gc3Rp bGwgaGF2ZSBhIFRMQiBlbnRyeSBmb3IgdGhlIHBhZ2UgYWZ0ZXIgc2NydWJi aW5nLCBhbmQKaGVuY2UgaXQgbWF5IGJlIGFibGUgdG8gbW9kaWZ5IGl0LiAg U3VjaCB1bmludGVuZGVkIHBhZ2UgYWNjZXNzaW5nIGFsbG93cwpkb21haW5z IHRvIHBvc3NpYmx5IGV4Y2hhbmdlIGluZm9ybWF0aW9uIGV2ZW4gd2hlbiBg eHNtPXNpbG8gc2NydWItZG9taGVhcGAKYXJlIGluIGVmZmVjdC4KClJlbW92 ZSB0aGUgTUVNRl9ub190bGJmbHVzaCBtZW1vcnkgYWxsb2NhdGlvbiBmbGFn LCBhbmQgcmVvcmRlciB0aGUKZmx1c2hpbmcgc28gaXQncyBhbHdheXMgZG9u ZSBhaGVhZCBvZiB0aGUgc2NydWJiaW5nIGluCmFsbG9jX3ssY29sb3JffWhl YXBfcGFnZXMoKS4gIFRoZSBzb2xlIHVzZXIgb2YgTUVNRl9ub190bGJmbHVz aCBpcwpwb3B1bGF0ZV9waHlzbWFwKCksIGFuZCBnaXZlbiB0aGUgY29uc3Ry YWlucyBhYm92ZSBpdCdzIG5vIGxvbmdlciBzYWZlCnRvIGRlZmVyIHRoZSBm bHVzaCwgaGVuY2UgdGhlIGZsYWcgcmVtb3ZhbCBhbmQgdGhlIGZvbGRpbmcg b2YgdGhlIGZsdXNoIGluCnRoZSBhbGxvY2F0b3IgZnVuY3Rpb24gaXRzZWxm LgoKVGhpcyBpcyBYU0EtNTExIC8gQ1ZFLTIwMjYtNzk2MDMuCgpGaXhlczog MjRmMWE1OGQxOTU0ICgibW06IG9wdGlvbiB0byBfYWx3YXlzXyBzY3J1YiBm cmVlZCBkb21oZWFwIHBhZ2VzIikKU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1 IE1vbm7DqSA8cm9nZXJAeGVucHJvamVjdC5vcmc+ClJldmlld2VkLWJ5OiBK YW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Ci0tLQogeGVuL2NvbW1v bi9tZW1vcnkuYyAgICAgfCAyMSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHhl bi9jb21tb24vcGFnZV9hbGxvYy5jIHwgMzQgKysrKysrKysrKysrKysrKysr Ky0tLS0tLS0tLS0tLS0tLQogeGVuL2luY2x1ZGUveGVuL21tLmggICAgfCAg MiAtLQogMyBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAzOCBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL21lbW9yeS5j IGIveGVuL2NvbW1vbi9tZW1vcnkuYwppbmRleCA3NmExYmYxYjExNTkuLjZj MWVhNmFhZTI3MyAxMDA2NDQKLS0tIGEveGVuL2NvbW1vbi9tZW1vcnkuYwor KysgYi94ZW4vY29tbW9uL21lbW9yeS5jCkBAIC0xNjUsOCArMTY1LDYgQEAg c3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3BfYXJn cyAqYSkKICAgICB1bnNpZ25lZCBpbnQgaSwgajsKICAgICB4ZW5fcGZuX3Qg Z3BmbjsKICAgICBzdHJ1Y3QgZG9tYWluICpkID0gYS0+ZG9tYWluLCAqY3Vy cl9kID0gY3VycmVudC0+ZG9tYWluOwotICAgIGJvb2wgbmVlZF90bGJmbHVz aCA9IGZhbHNlOwotICAgIHVpbnQzMl90IHRsYmZsdXNoX3RpbWVzdGFtcCA9 IDA7CiAKICAgICBpZiAoICFndWVzdF9oYW5kbGVfc3VicmFuZ2Vfb2theShh LT5leHRlbnRfbGlzdCwgYS0+bnJfZG9uZSwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhLT5ucl9leHRlbnRzLTEpICkKQEAgLTE3 OCwxNSArMTc2LDYgQEAgc3RhdGljIHZvaWQgcG9wdWxhdGVfcGh5c21hcChz dHJ1Y3QgbWVtb3BfYXJncyAqYSkKIAogICAgIGlmICggdW5saWtlbHkoIWQt PmNyZWF0aW9uX2ZpbmlzaGVkKSApCiAgICAgewotICAgICAgICAvKgotICAg ICAgICAgKiBXaXRoIE1FTUZfbm9fdGxiZmx1c2ggc2V0LCBhbGxvY19oZWFw X3BhZ2VzKCkgd2lsbCBpZ25vcmUKLSAgICAgICAgICogVExCLWZsdXNoZXMu IEFmdGVyIFZNIGNyZWF0aW9uLCB0aGlzIGlzIGEgc2VjdXJpdHkgaXNzdWUg KGl0IGNhbgotICAgICAgICAgKiBtYWtlIHBhZ2VzIGFjY2Vzc2libGUgdG8g Z3Vlc3QgQiwgd2hlbiBndWVzdCBBIG1heSBzdGlsbCBoYXZlIGEKLSAgICAg ICAgICogY2FjaGVkIG1hcHBpbmcgdG8gdGhlbSkuIFNvIHdlIGRvIHRoaXMg b25seSBkdXJpbmcgZG9tYWluIGNyZWF0aW9uLAotICAgICAgICAgKiB3aGVu IHRoZSBkb21haW4gaXRzZWxmIGhhcyBub3QgeWV0IGJlZW4gdW5wYXVzZWQg Zm9yIHRoZSBmaXJzdAotICAgICAgICAgKiB0aW1lLgotICAgICAgICAgKi8K LSAgICAgICAgYS0+bWVtZmxhZ3MgfD0gTUVNRl9ub190bGJmbHVzaDsKICAg ICAgICAgLyoKICAgICAgICAgICogV2l0aCBNRU1GX25vX2ljYWNoZV9mbHVz aCwgYWxsb2NfaGVhcF9wYWdlcygpIHdpbGwgc2tpcAogICAgICAgICAgKiBw ZXJmb3JtaW5nIGljYWNoZSBmbHVzaGVzLiBXZSBkbyBpdCBvbmx5IGJlZm9y ZSBkb21haW4KQEAgLTI4NiwxMyArMjc1LDYgQEAgc3RhdGljIHZvaWQgcG9w dWxhdGVfcGh5c21hcChzdHJ1Y3QgbWVtb3BfYXJncyAqYSkKICAgICAgICAg ICAgICAgICAgICAgZ290byBvdXQ7CiAgICAgICAgICAgICAgICAgfQogCi0g ICAgICAgICAgICAgICAgaWYgKCB1bmxpa2VseShhLT5tZW1mbGFncyAmIE1F TUZfbm9fdGxiZmx1c2gpICkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAg ICAgICAgICAgICAgIGZvciAoIGogPSAwOyBqIDwgKDFVIDw8IGEtPmV4dGVu dF9vcmRlcik7IGorKyApCi0gICAgICAgICAgICAgICAgICAgICAgICBhY2N1 bXVsYXRlX3RsYmZsdXNoKCZuZWVkX3RsYmZsdXNoLCAmcGFnZVtqXSwKLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnRs YmZsdXNoX3RpbWVzdGFtcCk7Ci0gICAgICAgICAgICAgICAgfQotCiAgICAg ICAgICAgICAgICAgbWZuID0gcGFnZV90b19tZm4ocGFnZSk7CiAgICAgICAg ICAgICB9CiAKQEAgLTMwNyw5ICsyODksNiBAQCBzdGF0aWMgdm9pZCBwb3B1 bGF0ZV9waHlzbWFwKHN0cnVjdCBtZW1vcF9hcmdzICphKQogICAgIH0KIAog b3V0OgotICAgIGlmICggbmVlZF90bGJmbHVzaCApCi0gICAgICAgIGZpbHRl cmVkX2ZsdXNoX3RsYl9tYXNrKHRsYmZsdXNoX3RpbWVzdGFtcCk7Ci0KICAg ICBpZiAoIGEtPm1lbWZsYWdzICYgTUVNRl9ub19pY2FjaGVfZmx1c2ggKQog ICAgICAgICBpbnZhbGlkYXRlX2ljYWNoZSgpOwogCmRpZmYgLS1naXQgYS94 ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYyBiL3hlbi9jb21tb24vcGFnZV9hbGxv Yy5jCmluZGV4IGE3YjNiMDRhNGQwMS4uYzRhOGY4YmM3NjdlIDEwMDY0NAot LS0gYS94ZW4vY29tbW9uL3BhZ2VfYWxsb2MuYworKysgYi94ZW4vY29tbW9u L3BhZ2VfYWxsb2MuYwpAQCAtMTA5NiwxNSArMTA5NiwxNyBAQCBzdGF0aWMg c3RydWN0IHBhZ2VfaW5mbyAqYWxsb2NfaGVhcF9wYWdlcygKICAgICAgICAg LyogUHJlc2VydmUgUEdDX25lZWRfc2NydWIgc28gd2UgY2FuIGNoZWNrIGl0 IGFmdGVyIGxvY2sgaXMgZHJvcHBlZC4gKi8KICAgICAgICAgcGdbaV0uY291 bnRfaW5mbyA9IFBHQ19zdGF0ZV9pbnVzZSB8IChwZ1tpXS5jb3VudF9pbmZv ICYgUEdDX25lZWRfc2NydWIpOwogCi0gICAgICAgIGlmICggIShtZW1mbGFn cyAmIE1FTUZfbm9fdGxiZmx1c2gpICkKLSAgICAgICAgICAgIGFjY3VtdWxh dGVfdGxiZmx1c2goJm5lZWRfdGxiZmx1c2gsICZwZ1tpXSwKLSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJnRsYmZsdXNoX3RpbWVzdGFtcCk7 CisgICAgICAgIGFjY3VtdWxhdGVfdGxiZmx1c2goJm5lZWRfdGxiZmx1c2gs ICZwZ1tpXSwgJnRsYmZsdXNoX3RpbWVzdGFtcCk7CiAKICAgICAgICAgaW5p dF9mcmVlX3BhZ2VfZmllbGRzKCZwZ1tpXSk7CiAgICAgfQogCiAgICAgc3Bp bl91bmxvY2soJmhlYXBfbG9jayk7CiAKKyAgICAvKiBGbHVzaCBhaGVhZCBv ZiBzY3J1YmJpbmc6IGVuc3VyZSBubyBQViBkb21haW4gaGFzIGEgc3RhbGUg VExCIGVudHJ5LiAqLworICAgIGlmICggbmVlZF90bGJmbHVzaCApCisgICAg ICAgIGZpbHRlcmVkX2ZsdXNoX3RsYl9tYXNrKHRsYmZsdXNoX3RpbWVzdGFt cCk7CisKICAgICBpZiAoIGZpcnN0X2RpcnR5ICE9IElOVkFMSURfRElSVFlf SURYIHx8CiAgICAgICAgICAoc2NydWJfZGVidWcgJiYgIShtZW1mbGFncyAm IE1FTUZfbm9fc2NydWIpKSApCiAgICAgewpAQCAtMTEzMSw5ICsxMTMzLDYg QEAgc3RhdGljIHN0cnVjdCBwYWdlX2luZm8gKmFsbG9jX2hlYXBfcGFnZXMo CiAgICAgICAgIH0KICAgICB9CiAKLSAgICBpZiAoIG5lZWRfdGxiZmx1c2gg KQotICAgICAgICBmaWx0ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVzaF90 aW1lc3RhbXApOwotCiAgICAgLyoKICAgICAgKiBFbnN1cmUgY2FjaGUgYW5k IFJBTSBhcmUgY29uc2lzdGVudCBmb3IgcGxhdGZvcm1zIHdoZXJlIHRoZSBn dWVzdAogICAgICAqIGNhbiBjb250cm9sIGl0cyBvd24gdmlzaWJpbGl0eSBv Zi90aHJvdWdoIHRoZSBjYWNoZS4KQEAgLTEzODcsNiArMTM4NiwxMyBAQCBi b29sIHNjcnViX2ZyZWVfcGFnZXModm9pZCkKICAgICAgICAgICAgICAgICB7 CiAgICAgICAgICAgICAgICAgICAgIGlmICggdGVzdF9iaXQoX1BHQ19uZWVk X3NjcnViLCAmcGdbaV0uY291bnRfaW5mbykgKQogICAgICAgICAgICAgICAg ICAgICB7CisgICAgICAgICAgICAgICAgICAgICAgICBib29sIG5lZWRfdGxi Zmx1c2ggPSBmYWxzZTsKKyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQz Ml90IHRsYmZsdXNoX3RzID0gMDsKKworICAgICAgICAgICAgICAgICAgICAg ICAgYWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBnW2ld LCAmdGxiZmx1c2hfdHMpOworICAgICAgICAgICAgICAgICAgICAgICAgaWYg KCBuZWVkX3RsYmZsdXNoICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICBmaWx0ZXJlZF9mbHVzaF90bGJfbWFzayh0bGJmbHVzaF90cyk7CisKICAg ICAgICAgICAgICAgICAgICAgICAgIHNjcnViX29uZV9wYWdlKCZwZ1tpXSwg dHJ1ZSk7CiAgICAgICAgICAgICAgICAgICAgICAgICAvKgogICAgICAgICAg ICAgICAgICAgICAgICAgICogV2UgY2FuIG1vZGlmeSBjb3VudF9pbmZvIHdp dGhvdXQgaG9sZGluZyBoZWFwCkBAIC0yMDU0LDcgKzIwNjAsNyBAQCBzdGF0 aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxsb2NfY29sb3JfaGVhcF9wYWdlKHVu c2lnbmVkIGludCBtZW1mbGFncywKICAgICB1aW50MzJfdCB0bGJmbHVzaF90 aW1lc3RhbXAgPSAwOwogICAgIGJvb2wgbmVlZF9zY3J1YjsKIAotICAgIGlm ICggbWVtZmxhZ3MgJiB+KE1FTUZfbm9fcmVmY291bnQgfCBNRU1GX25vX293 bmVyIHwgTUVNRl9ub190bGJmbHVzaCB8CisgICAgaWYgKCBtZW1mbGFncyAm IH4oTUVNRl9ub19yZWZjb3VudCB8IE1FTUZfbm9fb3duZXIgfAogICAgICAg ICAgICAgICAgICAgICAgIE1FTUZfbm9faWNhY2hlX2ZsdXNoIHwgTUVNRl9u b19zY3J1YikgKQogICAgICAgICByZXR1cm4gTlVMTDsKIApAQCAtMjA4Mywx MyArMjA4OSwxNiBAQCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxsb2Nf Y29sb3JfaGVhcF9wYWdlKHVuc2lnbmVkIGludCBtZW1mbGFncywKICAgICBm cmVlX2NvbG9yZWRfcGFnZXNbY29sb3JdLS07CiAgICAgcGFnZV9saXN0X2Rl bChwZywgY29sb3JfaGVhcChjb2xvcikpOwogCi0gICAgaWYgKCAhKG1lbWZs YWdzICYgTUVNRl9ub190bGJmbHVzaCkgKQotICAgICAgICBhY2N1bXVsYXRl X3RsYmZsdXNoKCZuZWVkX3RsYmZsdXNoLCBwZywgJnRsYmZsdXNoX3RpbWVz dGFtcCk7CisgICAgYWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVz aCwgcGcsICZ0bGJmbHVzaF90aW1lc3RhbXApOwogCiAgICAgaW5pdF9mcmVl X3BhZ2VfZmllbGRzKHBnKTsKIAogICAgIHNwaW5fdW5sb2NrKCZoZWFwX2xv Y2spOwogCisgICAgLyogRmx1c2ggYWhlYWQgb2Ygc2NydWJiaW5nOiBlbnN1 cmUgbm8gUFYgZG9tYWluIGhhcyBhIHN0YWxlIFRMQiBlbnRyeS4gKi8KKyAg ICBpZiAoIG5lZWRfdGxiZmx1c2ggKQorICAgICAgICBmaWx0ZXJlZF9mbHVz aF90bGJfbWFzayh0bGJmbHVzaF90aW1lc3RhbXApOworCiAgICAgaWYgKCAh KG1lbWZsYWdzICYgTUVNRl9ub19zY3J1YikgKQogICAgIHsKICAgICAgICAg aWYgKCBuZWVkX3NjcnViICkKQEAgLTIwOTgsOSArMjEwNyw2IEBAIHN0YXRp YyBzdHJ1Y3QgcGFnZV9pbmZvICphbGxvY19jb2xvcl9oZWFwX3BhZ2UodW5z aWduZWQgaW50IG1lbWZsYWdzLAogICAgICAgICAgICAgY2hlY2tfb25lX3Bh Z2UocGcpOwogICAgIH0KIAotICAgIGlmICggbmVlZF90bGJmbHVzaCApCi0g ICAgICAgIGZpbHRlcmVkX2ZsdXNoX3RsYl9tYXNrKHRsYmZsdXNoX3RpbWVz dGFtcCk7Ci0KICAgICBmbHVzaF9wYWdlX3RvX3JhbShtZm5feChwYWdlX3Rv X21mbihwZykpLAogICAgICAgICAgICAgICAgICAgICAgICEobWVtZmxhZ3Mg JiBNRU1GX25vX2ljYWNoZV9mbHVzaCkpOwogCkBAIC0zMDA2LDkgKzMwMTIs NyBAQCBzdGF0aWMgYm9vbCBwcmVwYXJlX3N0YXRpY21lbV9wYWdlcyhzdHJ1 Y3QgcGFnZV9pbmZvICpwZywgdW5zaWduZWQgbG9uZyBucl9tZm5zLAogICAg ICAgICAgICAgZ290byBvdXRfZXJyOwogICAgICAgICB9CiAKLSAgICAgICAg aWYgKCAhKG1lbWZsYWdzICYgTUVNRl9ub190bGJmbHVzaCkgKQotICAgICAg ICAgICAgYWNjdW11bGF0ZV90bGJmbHVzaCgmbmVlZF90bGJmbHVzaCwgJnBn W2ldLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmdGxiZmx1 c2hfdGltZXN0YW1wKTsKKyAgICAgICAgYWNjdW11bGF0ZV90bGJmbHVzaCgm bmVlZF90bGJmbHVzaCwgJnBnW2ldLCAmdGxiZmx1c2hfdGltZXN0YW1wKTsK IAogICAgICAgICAvKgogICAgICAgICAgKiBQcmVzZXJ2ZSBmbGFnIFBHQ19z dGF0aWMgYW5kIGNoYW5nZSBwYWdlIHN0YXRlCmRpZmYgLS1naXQgYS94ZW4v aW5jbHVkZS94ZW4vbW0uaCBiL3hlbi9pbmNsdWRlL3hlbi9tbS5oCmluZGV4 IGI5NjhmNDdiODdlMC4uNTg0MTBhMzY3YTM5IDEwMDY0NAotLS0gYS94ZW4v aW5jbHVkZS94ZW4vbW0uaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vbW0uaApA QCAtMjA0LDggKzIwNCw2IEBAIHN0cnVjdCBucGZlYyB7CiAjZGVmaW5lICBN RU1GX2V4YWN0X25vZGUgICgxVTw8X01FTUZfZXhhY3Rfbm9kZSkKICNkZWZp bmUgX01FTUZfbm9fb3duZXIgICAgNQogI2RlZmluZSAgTUVNRl9ub19vd25l ciAgICAoMVU8PF9NRU1GX25vX293bmVyKQotI2RlZmluZSBfTUVNRl9ub190 bGJmbHVzaCA2Ci0jZGVmaW5lICBNRU1GX25vX3RsYmZsdXNoICgxVTw8X01F TUZfbm9fdGxiZmx1c2gpCiAjZGVmaW5lIF9NRU1GX25vX2ljYWNoZV9mbHVz aCA3CiAjZGVmaW5lICBNRU1GX25vX2ljYWNoZV9mbHVzaCAoMVU8PF9NRU1G X25vX2ljYWNoZV9mbHVzaCkKICNkZWZpbmUgX01FTUZfbm9fc2NydWIgICAg OAotLSAKMi41My4wCgo= --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:00:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:00:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411325.1642003 (Exim 4.92) (envelope-from ) id 1x3uVN-0004HH-AN; Tue, 08 Sep 2026 12:00:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411325.1642003; Tue, 08 Sep 2026 12:00:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVN-0004GV-56; Tue, 08 Sep 2026 12:00:49 +0000 Received: by outflank-mailman (input) for mailman id 1411325; Tue, 08 Sep 2026 12:00:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVL-0004Co-IW; Tue, 08 Sep 2026 12:00:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uVK-00BhQN-FC; Tue, 08 Sep 2026 14:00:46 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ff8ea-8faa-0a2a0a5109dd-0a2a45058a8e-24 for ; Tue, 08 Sep 2026 14:00:46 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ff8ed-4cb1-0a2a45050019-6882d725a1bc-3 for ; Tue, 08 Sep 2026 14:00:46 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3uVB-004n4N-1v; Tue, 08 Sep 2026 12:00:37 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1x3uVB-00GjSA-2j; Tue, 08 Sep 2026 12:00:37 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.510 (Entity 5.510) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team CC: Xen.org security team Subject: Xen Security Advisory 509 v3 (CVE-2026-62437) - x86: DMs may cause mem leak by IRQ binding Message-Id: Date: Tue, 08 Sep 2026 12:00:37 +0000 X-purgate-ID: tlsNG-c201ff/1788868846-71CA82A1-59F74CBE/0/0 X-purgate-type: clean X-purgate-size: 5993 --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2026-62437 / XSA-509 version 3 x86: DMs may cause mem leak by IRQ binding UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= When guests are terminated, various pieces of cleanup need carrying out. The cleaning up of PCI devices which were assigned to guests, and the associated removal of tracking structures for IRQs used by the devices occurs relatively early in the process. Unfortunately after that point the guest about to be terminated could cause its device model (DM) to re-establish such tracking structures, by having it bind one or more IRQs anew. While some of those tracking structures would still be cleaned up later on, at least one would not be. IMPACT ====== A HVM guest with one or more PCI devices assigned can cause a memory leak in the hypervisor, possibly leading to Denial of Service (DoS) of the entire host. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are affected. Older versions have not been inspected. Only HVM guests with assigned PCI devices can leverage the vulnerability. MITIGATION ========== Running only PV or PVH guests will avoid the vulnerability. Running only HVM guests without passing through PCI devices to them will also avoid the vulnerability. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa509.patch xen-unstable - Xen 4.17.x $ sha256sum xsa509* 1e027737afa753f3498102ceac4abe62b11a49cfa019f25bb19728a7931f9096 xsa509.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because removing/replacing of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmqf970MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ6hYIAIDrF44cxjA9slR5fXYXpQvlGHE8wvTr5F5vNdXO JlB8yMQjdUPMfSLX0oMPapUwLE/UzFFA/MTXORrK6nj3TbRRHLqF9e9upL6e3QHH RrV4m2R5OSVjD6PG+T+e24ES5I4SLUTWv9i4vQZPzY54rjMtZ4d53DZk2eQ5v9kj ozYgQzwk5vMvRhnPv6MVdcBr2EfQ274+XxMKioMBZaFuv+zeomaQTAiok8gXhotX 6twiuhuhvMOtF2FA8V1WkKwUqw5NKm/plv54d8RRB/XNdxPe/8bxY0NlLGgRpMf3 cjSqsuhpEgpY3Vh62v3S0fAtExnWppdb/glJE+g4MZGzC7s= =J7JJ -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa509.patch" Content-Disposition: attachment; filename="xsa509.patch" Content-Transfer-Encoding: base64 RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0 OiB4ODYvcGFzcy10aHJvdWdoOiBkaXNhbGxvdyBwdF9pcnFfY3JlYXRlX2Jp bmQoKSBvbiBkeWluZyBkb21haW5zCgpETXMgbWF5IGludm9rZSBYRU5fRE9N Q1RMX2JpbmRfcHRfaXJxIGZvciBkb21haW5zIGFscmVhZHkgdW5kZXIKZGVz dHJ1Y3Rpb24uIFdoZW4gWEVOX0RPTUNUTF9iaW5kX3B0X2lycSBpcyBpbnZv a2VkIGFmdGVyCnBjaV9yZWxlYXNlX2RldmljZXMoKSAoaW52b2tlZCBmcm9t IHVuZGVybmVhdGggZG9tYWluX2tpbGwoKSkgaGFkIGFscmVhZHkKY29tcGxl dGVkLCBpdCB3b3VsZCBhbGxvY2F0ZSBodm1fZG9tYWluX2lycShkKS0+ZHBj aSBhbmV3LCB3aXRob3V0IHRoYXQKZXZlciBiZWluZyBmcmVlZCBkdXJpbmcg c3Vic2VxdWVudCBkb21haW4gY2xlYW51cC4KCkxldmVyYWdlIGV2dGNobl9k ZXN0cm95KCkncyBraW5kLW9mLXNwaW4tYmFycmllciwgYWxsb3dpbmcgdG8g c2ltcGx5IGNoZWNrCi0+aXNfZHlpbmcgd2l0aCB0aGUgZG9tYWluJ3MgZXZl bnQgbG9jayBoZWxkLgoKVGhpcyBpcyBYU0EtNTA5IC8gQ1ZFLTIwMjYtNjI0 MzcuCgpGaXhlczogN2EyNmI1NDFhMjAyICgidnRkOiBEeW5hbWljYWxseSBh bGxvY2F0ZSBJUlEtdHJhY2tpbmcgc3RydWN0dXJlcywgb25seSBmb3IgdGhv c2UiKQpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3Vz ZS5jb20+ClJldmlld2VkLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5w YXVAY2l0cml4LmNvbT4KCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo L3g4Ni9odm0uYworKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC94ODYv aHZtLmMKQEAgLTIzMSw2ICsyMzEsMTIgQEAgaW50IHB0X2lycV9jcmVhdGVf YmluZCgKICByZXN0YXJ0OgogICAgIHdyaXRlX2xvY2soJmQtPmV2ZW50X2xv Y2spOwogCisgICAgaWYgKCBkLT5pc19keWluZyApCisgICAgeworICAgICAg ICB3cml0ZV91bmxvY2soJmQtPmV2ZW50X2xvY2spOworICAgICAgICByZXR1 cm4gLUVTUkNIOworICAgIH0KKwogICAgIGh2bV9pcnFfZHBjaSA9IGRvbWFp bl9nZXRfaXJxX2RwY2koZCk7CiAgICAgaWYgKCAhaHZtX2lycV9kcGNpICYm ICFpc19oYXJkd2FyZV9kb21haW4oZCkgKQogICAgIHsK --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:01:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:01:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411336.1642108 (Exim 4.92) (envelope-from ) id 1x3uVX-0006fd-Oz; Tue, 08 Sep 2026 12:00:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411336.1642108; Tue, 08 Sep 2026 12:00:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVX-0006bh-F5; Tue, 08 Sep 2026 12:00:59 +0000 Received: by outflank-mailman (input) for mailman id 1411336; Tue, 08 Sep 2026 12:00:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVU-00061x-Lr; Tue, 08 Sep 2026 12:00:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uVU-00H0es-2W; Tue, 08 Sep 2026 14:00:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ff8ef-bab6-0a2a0a5309dd-0a2a450691f0-34 for ; Tue, 08 Sep 2026 14:00:56 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ff8f6-195a-0a2a45060019-6882d725cd8e-3 for ; Tue, 08 Sep 2026 14:00:55 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3uVM-004n5G-0m; Tue, 08 Sep 2026 12:00:48 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1x3uVM-00GkcL-1j; Tue, 08 Sep 2026 12:00:48 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.510 (Entity 5.510) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team CC: Xen.org security team Subject: Xen Security Advisory 512 v3 (CVE-2026-79604) - oxenstored: Unbounded accumulation of watches Message-Id: Date: Tue, 08 Sep 2026 12:00:48 +0000 X-purgate-ID: tlsNG-16d1c6/1788868855-F460277B-5B52116B/0/0 X-purgate-type: clean X-purgate-size: 30031 --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2026-79604 / XSA-512 version 3 oxenstored: Unbounded accumulation of watches UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Oxenstored maintains two datastructures about watches; one global trie, and one hashtable tracked per domain. When a xenbus reconnect is requested, watches are not cleared out of the global trie. IMPACT ====== A guest can cause unbounded memory usage in oxenstored. This can lead to a system-wide DoS. VULNERABLE SYSTEMS ================== All version of Xen from 4.6 onwards are vulnerable. Only systems using the Ocaml Xenstored implementation are vulnerable. Systems using the C Xenstored implementation are not vulnerable. MITIGATION ========== There are no mitigations. CREDITS ======= Found by Anthropic using agents to study the security of open-source projects, with Ada Logics validating and reporting. RESOLUTION ========== Applying the appropriate set of attached patches resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. For xen.git oxenstored: xsa512-?.patch xen-unstable - Xen 4.18.x xsa512-4.17-?.patch Xen 4.17.x For xapi-project/oxenstored: xsa512-oxenstored-?.patch oxenstored master $ sha256sum xsa512* c4f92a3e032f853a85cbd43391b6fd6a2c8f6f4caeee49bec9bc97a5279ce9a3 xsa512-1.patch 2cc57079eda8f0db34885e8be242d736f590ae8094c60a044b55b4889e10392f xsa512-2.patch 16bfa30473d4ba67dea69f1915357ecbe4aefc3b10bfd413f0bd7a7d2cfe2a80 xsa512-4.17-1.patch 7c23fb0e64429db074d7ec4cf7ba6ba319b69d5f1d059aa848c19b9ce148244c xsa512-4.17-2.patch 28c6267057ccf3508eee92dd82a9726e6b0d616fd7cc3e7dcee9cbfd3b0b80f7 xsa512-oxenstored-1.patch 00b9df35d9cc3ee393385a65725a2a681e31b9e00c4d1d76e0441e284f005707 xsa512-oxenstored-2.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmqf98gMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZk9kIAMqGI+5EVMLUd++EmpLqiTyGPcMYcDexca9XIpfJ Gx+DICPIRfRDCFtUG4jEeEDi8lmDvIKp5XXTNRkxyWF3uVKYDA5xCxekKOGmS40A p46pGzVVzGeSKdm2FfxEDDyuhhET5QrZLN98rJBcoL0/aX5sI4UoDR/FfdFemoAV BVrRG4WgQuBDa7+/t4jgZ8DysZbn/zmLoOtNIPVtaH5zvep0ehGQSnR8sAOEB+mV tmiW3kQoR1hxlOF/p1iVKLoBdOtJktwJ+Tk6OCCssS5TNGlGcpTs0KPukkXKwrem vYDYkHeUTf4rd3khUfCdW1S0Gc/3XSBtdL26VSj1xku5kMA= =6TLi -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa512-1.patch" Content-Disposition: attachment; filename="xsa512-1.patch" Content-Transfer-Encoding: base64 RnJvbSA1MzMyYTJjNDZkYjRmOTZlNWQ1YTU3MTAwYzU1MDc2ZmU1NjEwYmVi IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyaWkgU3VsdGFu b3YgPGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgpEYXRlOiBUaHUsIDIw IEF1ZyAyMDI2IDE2OjAwOjAyICswMTAwClN1YmplY3Q6IG94ZW5zdG9yZWQ6 IEZhY3RvciBvdXQgUHJvY2Vzcy5kb19yZWNvbm5lY3QoKQoKVGhlIGxvZ2lj IGZsb3cgaGVyZSBpcyBjb21wbGljYXRlZC4gIEluIHByZXBhcmF0aW9uIHRv IGZpeCBhIGJ1ZywgZmFjdG9yIG91dApyZWNvbm5lY3RpbmcgYSB4ZW5idXMg Y29ubmVjdGlvbiwgYW5kIGZvbGQgSGlzdG9yeS5yZWNvbm5lY3QgaW50byBp dCdzIHNpbmdsZQpjYWxsZXIuCgpObyBmdW5jdGlvbmFsIGNoYW5nZS4KClRo aXMgaXMgcGFydCBvZiBYU0EtNTEyIC8gQ1ZFLTIwMjYtNzk2MDQuCgpTaWdu ZWQtb2ZmLWJ5OiBBbmRyaWkgU3VsdGFub3YgPGFuZHJpeS5zdWx0YW5vdkB2 YXRlcy50ZWNoPgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRy ZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogQW5kcmlpIFN1 bHRhbm92IDxhbmRyaXkuc3VsdGFub3ZAdmF0ZXMudGVjaD4KCmRpZmYgLS1n aXQgYS90b29scy9vY2FtbC94ZW5zdG9yZWQvaGlzdG9yeS5tbCBiL3Rvb2xz L29jYW1sL3hlbnN0b3JlZC9oaXN0b3J5Lm1sCmluZGV4IGYwM2ZiMTgzMjky My4uMzQ3NGE2MmRhMjMwIDEwMDY0NAotLS0gYS90b29scy9vY2FtbC94ZW5z dG9yZWQvaGlzdG9yeS5tbAorKysgYi90b29scy9vY2FtbC94ZW5zdG9yZWQv aGlzdG9yeS5tbApAQCAtMzksMTAgKzM5LDYgQEAgbGV0IGVuZF90cmFuc2Fj dGlvbiB0eG4gY29uIHRpZCBjb21taXQgPQogICB0cmltIH50eG4gKCk7CiAg IHN1Y2Nlc3MKIAotbGV0IHJlY29ubmVjdCBjb24gPQotICB0cmltICgpOwot ICBDb25uZWN0aW9uLmRvX3JlY29ubmVjdCBjb24KLQogbGV0IHB1c2ggKHg6 IGhpc3RvcnlfcmVjb3JkKSA9CiAgIGxldCBkb20gPSB4LmNvbi5Db25uZWN0 aW9uLmRvbSBpbgogICBtYXRjaCBkb20gd2l0aApkaWZmIC0tZ2l0IGEvdG9v bHMvb2NhbWwveGVuc3RvcmVkL3Byb2Nlc3MubWwgYi90b29scy9vY2FtbC94 ZW5zdG9yZWQvcHJvY2Vzcy5tbAppbmRleCAwYzljNDYwYTk5MTUuLmJjNjhj NTRjOWFiYSAxMDA2NDQKLS0tIGEvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3By b2Nlc3MubWwKKysrIGIvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3Byb2Nlc3Mu bWwKQEAgLTM1MCw2ICszNTAsMTMgQEAgbGV0IGRvX3Jlc2V0X3dhdGNoZXMg Y29uIF90IF9kb21haW5zIGNvbnMgX2RhdGEgPQogICBDb25uZWN0aW9ucy5k ZWxfd2F0Y2hlcyBjb25zIGNvbjsKICAgQ29ubmVjdGlvbi5kZWxfdHJhbnNh Y3Rpb25zIGNvbgogCitsZXQgZG9fcmVjb25uZWN0IGNvbnMgY29uID0KKyAg bGV0IGRvbXN0ciA9IENvbm5lY3Rpb24uZ2V0X2RvbXN0ciBjb24gaW4KKyAg aW5mbyAiJXMgcmVxdWVzdHMgYSByZWNvbm5lY3QiIGRvbXN0cjsKKyAgSGlz dG9yeS50cmltICgpOworICBDb25uZWN0aW9uLmRvX3JlY29ubmVjdCBjb247 CisgIGluZm8gIiVzIHJlY29ubmVjdGlvbiBjb21wbGV0ZSIgZG9tc3RyCisK ICgqIG9ubHkgaW4gPj0geGVuMy4zICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKikKIGxldCBkb19zZXRfdGFyZ2V0IGNvbiBfdCBf ZG9tYWlucyBjb25zIGRhdGEgPQogICBpZiBub3QgKENvbm5lY3Rpb24uaXNf ZG9tMCBjb24pCkBAIC03MzUsOSArNzQyLDcgQEAgbGV0IGRvX2lucHV0IHN0 b3JlIGNvbnMgZG9tcyBjb24gPQogICAgICAgaWYgQ29ubmVjdGlvbi5jYW5f aW5wdXQgY29uIHRoZW4gQ29ubmVjdGlvbi5kb19pbnB1dCBjb24KICAgICAg IGVsc2UgTm9uZQogICAgIHdpdGggWGVuYnVzLlhiLlJlY29ubmVjdCAtPgot ICAgICAgaW5mbyAiJXMgcmVxdWVzdHMgYSByZWNvbm5lY3QiIChDb25uZWN0 aW9uLmdldF9kb21zdHIgY29uKTsKLSAgICAgIEhpc3RvcnkucmVjb25uZWN0 IGNvbjsKLSAgICAgIGluZm8gIiVzIHJlY29ubmVjdGlvbiBjb21wbGV0ZSIg KENvbm5lY3Rpb24uZ2V0X2RvbXN0ciBjb24pOworICAgICAgZG9fcmVjb25u ZWN0IGNvbnMgY29uOwogICAgICAgTm9uZQogICAgICAgIHwgSW52YWxpZF9h cmd1bWVudCBleHAgfCBGYWlsdXJlIGV4cCAtPgogICAgICAgICAgZXJyb3Ig ImNhdWdodCBleGNlcHRpb24gJXMiIGV4cDsKQEAgLTc2MCw3ICs3NjUsNyBA QCBsZXQgZG9faW5wdXQgc3RvcmUgY29ucyBkb21zIGNvbiA9CiAgICAgd3Jp dGVfYWNjZXNzX2xvZyB+dHkgfnRpZCB+Y29uOihDb25uZWN0aW9uLmdldF9k b21zdHIgY29uKSB+ZGF0YTsKICAgICBDb25uZWN0aW9uLmluY3Jfb3BzIGNv bgogCi1sZXQgZG9fb3V0cHV0IF9zdG9yZSBfY29ucyBfZG9tcyBjb24gPQor bGV0IGRvX291dHB1dCBfc3RvcmUgY29ucyBfZG9tcyBjb24gPQogICBDb25u ZWN0aW9uLnNvdXJjZV9mbHVzaF93YXRjaGV2ZW50cyBjb247CiAgIGlmIENv bm5lY3Rpb24uaGFzX291dHB1dCBjb24gdGhlbiAoCiAgICAgaWYgQ29ubmVj dGlvbi5oYXNfbmV3X291dHB1dCBjb24gdGhlbiAoCkBAIC03NzUsOCArNzgw LDYgQEAgbGV0IGRvX291dHB1dCBfc3RvcmUgX2NvbnMgX2RvbXMgY29uID0K ICAgICB0cnkKICAgICAgIGlnbm9yZSAoQ29ubmVjdGlvbi5kb19vdXRwdXQg Y29uKQogICAgIHdpdGggWGVuYnVzLlhiLlJlY29ubmVjdCAtPgotICAgICAg aW5mbyAiJXMgcmVxdWVzdHMgYSByZWNvbm5lY3QiIChDb25uZWN0aW9uLmdl dF9kb21zdHIgY29uKTsKLSAgICAgIEhpc3RvcnkucmVjb25uZWN0IGNvbjsK LSAgICAgIGluZm8gIiVzIHJlY29ubmVjdGlvbiBjb21wbGV0ZSIgKENvbm5l Y3Rpb24uZ2V0X2RvbXN0ciBjb24pCisgICAgICBkb19yZWNvbm5lY3QgY29u cyBjb24KICAgKQogCg== --=separator Content-Type: application/octet-stream; name="xsa512-2.patch" Content-Disposition: attachment; filename="xsa512-2.patch" Content-Transfer-Encoding: base64 RnJvbSA4ZGM0Y2E1MGU2MmYyNTg3YTAyMTNiMDc4ZmM5MDhmZGZiNTQ4Mjhi IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyaWkgU3VsdGFu b3YgPGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgpEYXRlOiBUaHUsIDIw IEF1ZyAyMDI2IDE1OjAwOjAyICswMDAwClN1YmplY3Q6IG94ZW5zdG9yZWQ6 IFJlc2V0IHRoZSB3YXRjaGVzIHRyaWUgb24gZG9tYWluIHJlY29ubmVjdAoK b3hlbnN0b3JlZCBtYWludGFpbnMgdHdvIGRhdGFzdHJ1Y3R1cmVzIGFib3V0 IHdhdGNoZXM7IG9uZSBnbG9iYWwgdHJpZSwgYW5kCm9uZSBoYXNodGFibGUg dHJhY2tlZCBwZXIgZG9tYWluLiAgQm90aCBuZWVkIGtlZXBpbmcgaW4gc3lu YywgYW5kIHJpZ2h0IG5vdwp0aGUgZ2xvYmFsIHRyaWUgaXMgbm90IGVtcHRp ZWQgd2hlbiBhIHhlbmJ1cyByZWNvbm5lY3QgaXMgcmVxdWVzdGVkLgoKVGhp cyBpcyBiYXNpY2FsbHkgdGhlIHNhbWUgYnVnIGFzIFhTQS0zMzAsIGNvbW1p dCA0OTFhMDc3ZWQ0YzUKKCJ0b29scy9vY2FtbC94ZW5zdG9yZWQ6IGRlbGV0 ZSB3YXRjaCBmcm9tIHRyaWUgdG9vIHdoZW4gcmVzZXR0aW5nIHdhdGNoZXMi KSwKanVzdCB0aWNrbGVkIHZpYSBhbm90aGVyIHBhdGguCgpBcnJhbmdlIGZv ciBib3RoIFByb2Nlc3MuZG9fcmVzZXRfd2F0Y2hlcygpIGFuZCBQcm9jZXNz LmRvX3JlY29ubmVjdCgpIHRvCnNoYXJlIGEgY29tbW9uIGNvZGVwYXRoIGZv ciB0aGUgcmVzZXR0aW5nIG9mIHdhdGNoZXMgYW5kIHRyYW5zYWN0aW9ucy4K Tm90YWJseSwgdGhpcyBtZWFucyB0aGF0IHRoZSBsYXR0ZXIgbm93IGNhbGxz IENvbm5lY3Rpb25zLmRlbF93YXRjaGVzKCkgd2hpY2gKY2xlYXJzIHRoZSBn bG9iYWwgdHJpZSB0b28uCgpDb25uZWN0aW9ucy5kZWxfd2F0Y2hlcygpIGFs cmVhZHkgY2FsbHMgQ29ubmVjdGlvbi5kZWxfd2F0Y2hlcygpIHNvIHJlbW92 ZSB0aGUKcmUtY2xlYXJpbmcgb2YgdGhlIHN0YXRlIGZyb20gQ29ubmVjdGlv bi5kb19yZWNvbm5lY3QoKS4KCk1vdmUgSGlzdG9yeS50cmltKCkgaW50byBy ZXNldF93YXRjaGVzX2FuZF90cmFuc2FjdGlvbnMoKSBzbyBpdCdzIG9uIHRo ZQpjb21tb24gcGF0aCwgYW5kIHBsYWNlIGl0IGFmdGVyIHJlbW92aW5nIHRo ZSB0cmFuc2FjdGlvbnMgcmF0aGVyIHRoYW4gYmVmb3JlLgoKVGhpcyBpcyBw YXJ0IG9mIFhTQS01MTIgLyBDVkUtMjAyNi03OTYwNC4KClJlcG9ydGVkLWJ5 OiBEYXZpZCBLb3Jjenluc2tpIDxEYXZpZEBBZGFsb2dpY3MuY29tPgpGaXhl czogNjc0YWQyYmU0MDlkICgieGVuc3RvcmU6IGV4dGVuZCB0aGUgeGVuc3Rv cmUgcmluZyB3aXRoIGEgJ2Nsb3NpbmcnIHNpZ25hbCIpClNpZ25lZC1vZmYt Ynk6IEFuZHJpaSBTdWx0YW5vdiA8YW5kcml5LnN1bHRhbm92QHZhdGVzLnRl Y2g+ClNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29w ZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBBbmRyaWkgU3VsdGFub3Yg PGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgoKZGlmZiAtLWdpdCBhL3Rv b2xzL29jYW1sL3hlbnN0b3JlZC9jb25uZWN0aW9uLm1sIGIvdG9vbHMvb2Nh bWwveGVuc3RvcmVkL2Nvbm5lY3Rpb24ubWwKaW5kZXggZDExMDExZTE2NDM5 Li4zN2ViMjQ0NGI5MzYgMTAwNjQ0Ci0tLSBhL3Rvb2xzL29jYW1sL3hlbnN0 b3JlZC9jb25uZWN0aW9uLm1sCisrKyBiL3Rvb2xzL29jYW1sL3hlbnN0b3Jl ZC9jb25uZWN0aW9uLm1sCkBAIC0xNDgsMTMgKzE0OCwxMSBAQCBsZXQgbWFy a19hc19iYWQgY29uID0KIGxldCBpbml0aWFsX25leHRfdGlkID0gMQogCiBs ZXQgZG9fcmVjb25uZWN0IGNvbiA9CisgICgqIHRyYW5zYWN0aW9ucyBhbmQg d2F0Y2hlcyBoYW5kbGVkIGJ5IGNhbGxlciAqKQogICBYZW5idXMuWGIucmVj b25uZWN0IGNvbi54YjsKICAgKCogZG9tIGlzIHRoZSBzYW1lICopCi0gIEhh c2h0YmwuY2xlYXIgY29uLnRyYW5zYWN0aW9uczsKICAgY29uLm5leHRfdGlk IDwtIGluaXRpYWxfbmV4dF90aWQ7Ci0gIEhhc2h0YmwuY2xlYXIgY29uLndh dGNoZXM7CiAgICgqIGFub25pZCBpcyB0aGUgc2FtZSAqKQotICBjb24ubmJf d2F0Y2hlcyA8LSAwOwogICBjb24uc3RhdF9uYl9vcHMgPC0gMDsKICAgKCog cGVybSBpcyB0aGUgc2FtZSAqKQogICAoKQpkaWZmIC0tZ2l0IGEvdG9vbHMv b2NhbWwveGVuc3RvcmVkL3Byb2Nlc3MubWwgYi90b29scy9vY2FtbC94ZW5z dG9yZWQvcHJvY2Vzcy5tbAppbmRleCBiYzY4YzU0YzlhYmEuLmZjMjU1OGFj M2Q5YiAxMDA2NDQKLS0tIGEvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3Byb2Nl c3MubWwKKysrIGIvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3Byb2Nlc3MubWwK QEAgLTM0NSwxNSArMzQ1LDE4IEBAIGxldCBkb19pc2ludHJvZHVjZWQgY29u IF90IGRvbWFpbnMgX2NvbnMgZGF0YSA9CiAgIGluCiAgIGlmIGRvbWlkID0g RGVmaW5lLmRvbWlkX3NlbGYgfHwgRG9tYWlucy5leGlzdCBkb21haW5zIGRv bWlkIHRoZW4gIlRcMDAwIiBlbHNlICJGXDAwMCIKIAotKCogb25seSBpbiB4 ZW4gPj0gNC4yICopCi1sZXQgZG9fcmVzZXRfd2F0Y2hlcyBjb24gX3QgX2Rv bWFpbnMgY29ucyBfZGF0YSA9CitsZXQgcmVzZXRfd2F0Y2hlc19hbmRfdHJh bnNhY3Rpb25zIGNvbnMgY29uID0KICAgQ29ubmVjdGlvbnMuZGVsX3dhdGNo ZXMgY29ucyBjb247Ci0gIENvbm5lY3Rpb24uZGVsX3RyYW5zYWN0aW9ucyBj b24KKyAgQ29ubmVjdGlvbi5kZWxfdHJhbnNhY3Rpb25zIGNvbjsKKyAgSGlz dG9yeS50cmltICgpCisKK2xldCBkb19yZXNldF93YXRjaGVzIGNvbiBfdCBf ZG9tYWlucyBjb25zIF9kYXRhID0KKyAgcmVzZXRfd2F0Y2hlc19hbmRfdHJh bnNhY3Rpb25zIGNvbnMgY29uCiAKIGxldCBkb19yZWNvbm5lY3QgY29ucyBj b24gPQogICBsZXQgZG9tc3RyID0gQ29ubmVjdGlvbi5nZXRfZG9tc3RyIGNv biBpbgogICBpbmZvICIlcyByZXF1ZXN0cyBhIHJlY29ubmVjdCIgZG9tc3Ry OwotICBIaXN0b3J5LnRyaW0gKCk7CisgIHJlc2V0X3dhdGNoZXNfYW5kX3Ry YW5zYWN0aW9ucyBjb25zIGNvbjsKICAgQ29ubmVjdGlvbi5kb19yZWNvbm5l Y3QgY29uOwogICBpbmZvICIlcyByZWNvbm5lY3Rpb24gY29tcGxldGUiIGRv bXN0cgogCg== --=separator Content-Type: application/octet-stream; name="xsa512-4.17-1.patch" Content-Disposition: attachment; filename="xsa512-4.17-1.patch" Content-Transfer-Encoding: base64 RnJvbSBjYTIxZjIyOGZlODMwMmYzZmM3MjRiMmZmZjQ2YjI0OTA2ZDlkY2Q3 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyaWkgU3VsdGFu b3YgPGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgpEYXRlOiBUaHUsIDIw IEF1ZyAyMDI2IDE2OjAwOjAyICswMTAwClN1YmplY3Q6IG94ZW5zdG9yZWQ6 IEZhY3RvciBvdXQgUHJvY2Vzcy5kb19yZWNvbm5lY3QoKQoKVGhlIGxvZ2lj IGZsb3cgaGVyZSBpcyBjb21wbGljYXRlZC4gIEluIHByZXBhcmF0aW9uIHRv IGZpeCBhIGJ1ZywgZmFjdG9yIG91dApyZWNvbm5lY3RpbmcgYSB4ZW5idXMg Y29ubmVjdGlvbiwgYW5kIGZvbGQgSGlzdG9yeS5yZWNvbm5lY3QgaW50byBp dCdzIHNpbmdsZQpjYWxsZXIuCgpObyBmdW5jdGlvbmFsIGNoYW5nZS4KClRo aXMgaXMgcGFydCBvZiBYU0EtNTEyIC8gQ1ZFLTIwMjYtNzk2MDQuCgpTaWdu ZWQtb2ZmLWJ5OiBBbmRyaWkgU3VsdGFub3YgPGFuZHJpeS5zdWx0YW5vdkB2 YXRlcy50ZWNoPgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRy ZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogQW5kcmlpIFN1 bHRhbm92IDxhbmRyaXkuc3VsdGFub3ZAdmF0ZXMudGVjaD4KCmRpZmYgLS1n aXQgYS90b29scy9vY2FtbC94ZW5zdG9yZWQvaGlzdG9yeS5tbCBiL3Rvb2xz L29jYW1sL3hlbnN0b3JlZC9oaXN0b3J5Lm1sCmluZGV4IGJhNWM5Y2I1NzFm Zi4uMDI5ODAyYmQxNTQ0IDEwMDY0NAotLS0gYS90b29scy9vY2FtbC94ZW5z dG9yZWQvaGlzdG9yeS5tbAorKysgYi90b29scy9vY2FtbC94ZW5zdG9yZWQv aGlzdG9yeS5tbApAQCAtMzksMTAgKzM5LDYgQEAgbGV0IGVuZF90cmFuc2Fj dGlvbiB0eG4gY29uIHRpZCBjb21taXQgPQogCXRyaW0gfnR4biAoKTsKIAlz dWNjZXNzCiAKLWxldCByZWNvbm5lY3QgY29uID0KLQl0cmltICgpOwotCUNv bm5lY3Rpb24uZG9fcmVjb25uZWN0IGNvbgotCiBsZXQgcHVzaCAoeDogaGlz dG9yeV9yZWNvcmQpID0KIAlsZXQgZG9tID0geC5jb24uQ29ubmVjdGlvbi5k b20gaW4KIAltYXRjaCBkb20gd2l0aApkaWZmIC0tZ2l0IGEvdG9vbHMvb2Nh bWwveGVuc3RvcmVkL3Byb2Nlc3MubWwgYi90b29scy9vY2FtbC94ZW5zdG9y ZWQvcHJvY2Vzcy5tbAppbmRleCAwMmJkMGY3ZDgwOTguLjMzMTYxZGE1ZWI4 YiAxMDA2NDQKLS0tIGEvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3Byb2Nlc3Mu bWwKKysrIGIvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3Byb2Nlc3MubWwKQEAg LTMzMyw2ICszMzMsMTMgQEAgbGV0IGRvX3Jlc2V0X3dhdGNoZXMgY29uIF90 IF9kb21haW5zIGNvbnMgX2RhdGEgPQogICBDb25uZWN0aW9ucy5kZWxfd2F0 Y2hlcyBjb25zIGNvbjsKICAgQ29ubmVjdGlvbi5kZWxfdHJhbnNhY3Rpb25z IGNvbgogCitsZXQgZG9fcmVjb25uZWN0IGNvbnMgY29uID0KKyAgbGV0IGRv bXN0ciA9IENvbm5lY3Rpb24uZ2V0X2RvbXN0ciBjb24gaW4KKyAgaW5mbyAi JXMgcmVxdWVzdHMgYSByZWNvbm5lY3QiIGRvbXN0cjsKKyAgSGlzdG9yeS50 cmltICgpOworICBDb25uZWN0aW9uLmRvX3JlY29ubmVjdCBjb247CisgIGlu Zm8gIiVzIHJlY29ubmVjdGlvbiBjb21wbGV0ZSIgZG9tc3RyCisKICgqIG9u bHkgaW4gPj0geGVuMy4zICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKikKIGxldCBkb19zZXRfdGFyZ2V0IGNvbiBfdCBfZG9tYWlu cyBjb25zIGRhdGEgPQogCWlmIG5vdCAoQ29ubmVjdGlvbi5pc19kb20wIGNv bikKQEAgLTcxOCw5ICs3MjUsNyBAQCBsZXQgZG9faW5wdXQgc3RvcmUgY29u cyBkb21zIGNvbiA9CiAJCQlpZiBDb25uZWN0aW9uLmNhbl9pbnB1dCBjb24g dGhlbiBDb25uZWN0aW9uLmRvX2lucHV0IGNvbgogCQkJZWxzZSBOb25lCiAJ CXdpdGggWGVuYnVzLlhiLlJlY29ubmVjdCAtPgotCQkJaW5mbyAiJXMgcmVx dWVzdHMgYSByZWNvbm5lY3QiIChDb25uZWN0aW9uLmdldF9kb21zdHIgY29u KTsKLQkJCUhpc3RvcnkucmVjb25uZWN0IGNvbjsKLQkJCWluZm8gIiVzIHJl Y29ubmVjdGlvbiBjb21wbGV0ZSIgKENvbm5lY3Rpb24uZ2V0X2RvbXN0ciBj b24pOworCQkJZG9fcmVjb25uZWN0IGNvbnMgY29uOwogCQkJTm9uZQogCQl8 IEludmFsaWRfYXJndW1lbnQgZXhwIHwgRmFpbHVyZSBleHAgLT4KIAkJCWVy cm9yICJjYXVnaHQgZXhjZXB0aW9uICVzIiBleHA7CkBAIC03NDMsNyArNzQ4 LDcgQEAgbGV0IGRvX2lucHV0IHN0b3JlIGNvbnMgZG9tcyBjb24gPQogCQl3 cml0ZV9hY2Nlc3NfbG9nIH50eSB+dGlkIH5jb246KENvbm5lY3Rpb24uZ2V0 X2RvbXN0ciBjb24pIH5kYXRhOwogCQlDb25uZWN0aW9uLmluY3Jfb3BzIGNv bgogCi1sZXQgZG9fb3V0cHV0IF9zdG9yZSBfY29ucyBfZG9tcyBjb24gPQor bGV0IGRvX291dHB1dCBfc3RvcmUgY29ucyBfZG9tcyBjb24gPQogCUNvbm5l Y3Rpb24uc291cmNlX2ZsdXNoX3dhdGNoZXZlbnRzIGNvbjsKIAlpZiBDb25u ZWN0aW9uLmhhc19vdXRwdXQgY29uIHRoZW4gKAogCQlpZiBDb25uZWN0aW9u Lmhhc19uZXdfb3V0cHV0IGNvbiB0aGVuICgKQEAgLTc1OCw4ICs3NjMsNiBA QCBsZXQgZG9fb3V0cHV0IF9zdG9yZSBfY29ucyBfZG9tcyBjb24gPQogCQl0 cnkKIAkJCWlnbm9yZSAoQ29ubmVjdGlvbi5kb19vdXRwdXQgY29uKQogCQl3 aXRoIFhlbmJ1cy5YYi5SZWNvbm5lY3QgLT4KLQkJCWluZm8gIiVzIHJlcXVl c3RzIGEgcmVjb25uZWN0IiAoQ29ubmVjdGlvbi5nZXRfZG9tc3RyIGNvbik7 Ci0JCQlIaXN0b3J5LnJlY29ubmVjdCBjb247Ci0JCQlpbmZvICIlcyByZWNv bm5lY3Rpb24gY29tcGxldGUiIChDb25uZWN0aW9uLmdldF9kb21zdHIgY29u KQorCQkJZG9fcmVjb25uZWN0IGNvbnMgY29uOwogCSkKIAo= --=separator Content-Type: application/octet-stream; name="xsa512-4.17-2.patch" Content-Disposition: attachment; filename="xsa512-4.17-2.patch" Content-Transfer-Encoding: base64 RnJvbSA2NmIzMTA1NzA5OTZjNjliZjc5NTRhYWJhY2RkNjY3ODYzMGVmOGFj IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyaWkgU3VsdGFu b3YgPGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgpEYXRlOiBUaHUsIDIw IEF1ZyAyMDI2IDE1OjAwOjAyICswMDAwClN1YmplY3Q6IG94ZW5zdG9yZWQ6 IFJlc2V0IHRoZSB3YXRjaGVzIHRyaWUgb24gZG9tYWluIHJlY29ubmVjdAoK b3hlbnN0b3JlZCBtYWludGFpbnMgdHdvIGRhdGFzdHJ1Y3R1cmVzIGFib3V0 IHdhdGNoZXM7IG9uZSBnbG9iYWwgdHJpZSwgYW5kCm9uZSBoYXNodGFibGUg dHJhY2tlZCBwZXIgZG9tYWluLiAgQm90aCBuZWVkIGtlZXBpbmcgaW4gc3lu YywgYW5kIHJpZ2h0IG5vdwp0aGUgZ2xvYmFsIHRyaWUgaXMgbm90IGVtcHRp ZWQgd2hlbiBhIHhlbmJ1cyByZWNvbm5lY3QgaXMgcmVxdWVzdGVkLgoKVGhp cyBpcyBiYXNpY2FsbHkgdGhlIHNhbWUgYnVnIGFzIFhTQS0zMzAsIGNvbW1p dCA0OTFhMDc3ZWQ0YzUKKCJ0b29scy9vY2FtbC94ZW5zdG9yZWQ6IGRlbGV0 ZSB3YXRjaCBmcm9tIHRyaWUgdG9vIHdoZW4gcmVzZXR0aW5nIHdhdGNoZXMi KSwKanVzdCB0aWNrbGVkIHZpYSBhbm90aGVyIHBhdGguCgpBcnJhbmdlIGZv ciBib3RoIFByb2Nlc3MuZG9fcmVzZXRfd2F0Y2hlcygpIGFuZCBQcm9jZXNz LmRvX3JlY29ubmVjdCgpIHRvCnNoYXJlIGEgY29tbW9uIGNvZGVwYXRoIGZv ciB0aGUgcmVzZXR0aW5nIG9mIHdhdGNoZXMgYW5kIHRyYW5zYWN0aW9ucy4K Tm90YWJseSwgdGhpcyBtZWFucyB0aGF0IHRoZSBsYXR0ZXIgbm93IGNhbGxz IENvbm5lY3Rpb25zLmRlbF93YXRjaGVzKCkgd2hpY2gKY2xlYXJzIHRoZSBn bG9iYWwgdHJpZSB0b28uCgpDb25uZWN0aW9ucy5kZWxfd2F0Y2hlcygpIGFs cmVhZHkgY2FsbHMgQ29ubmVjdGlvbi5kZWxfd2F0Y2hlcygpIHNvIHJlbW92 ZSB0aGUKcmUtY2xlYXJpbmcgb2YgdGhlIHN0YXRlIGZyb20gQ29ubmVjdGlv bi5kb19yZWNvbm5lY3QoKS4KCk1vdmUgSGlzdG9yeS50cmltKCkgaW50byBy ZXNldF93YXRjaGVzX2FuZF90cmFuc2FjdGlvbnMoKSBzbyBpdCdzIG9uIHRo ZQpjb21tb24gcGF0aCwgYW5kIHBsYWNlIGl0IGFmdGVyIHJlbW92aW5nIHRo ZSB0cmFuc2FjdGlvbnMgcmF0aGVyIHRoYW4gYmVmb3JlLgoKVGhpcyBpcyBw YXJ0IG9mIFhTQS01MTIgLyBDVkUtMjAyNi03OTYwNC4KClJlcG9ydGVkLWJ5 OiBEYXZpZCBLb3Jjenluc2tpIDxEYXZpZEBBZGFsb2dpY3MuY29tPgpGaXhl czogNjc0YWQyYmU0MDlkICgieGVuc3RvcmU6IGV4dGVuZCB0aGUgeGVuc3Rv cmUgcmluZyB3aXRoIGEgJ2Nsb3NpbmcnIHNpZ25hbCIpClNpZ25lZC1vZmYt Ynk6IEFuZHJpaSBTdWx0YW5vdiA8YW5kcml5LnN1bHRhbm92QHZhdGVzLnRl Y2g+ClNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29w ZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBBbmRyaWkgU3VsdGFub3Yg PGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgoKZGlmZiAtLWdpdCBhL3Rv b2xzL29jYW1sL3hlbnN0b3JlZC9jb25uZWN0aW9uLm1sIGIvdG9vbHMvb2Nh bWwveGVuc3RvcmVkL2Nvbm5lY3Rpb24ubWwKaW5kZXggNTRmN2Y3NjUxNjdi Li5hOTFjYWFiZWM2NzQgMTAwNjQ0Ci0tLSBhL3Rvb2xzL29jYW1sL3hlbnN0 b3JlZC9jb25uZWN0aW9uLm1sCisrKyBiL3Rvb2xzL29jYW1sL3hlbnN0b3Jl ZC9jb25uZWN0aW9uLm1sCkBAIC0xNDgsMTMgKzE0OCwxMSBAQCBsZXQgbWFy a19hc19iYWQgY29uID0KIGxldCBpbml0aWFsX25leHRfdGlkID0gMQogCiBs ZXQgZG9fcmVjb25uZWN0IGNvbiA9CisJKCogdHJhbnNhY3Rpb25zIGFuZCB3 YXRjaGVzIGhhbmRsZWQgYnkgY2FsbGVyICopCiAJWGVuYnVzLlhiLnJlY29u bmVjdCBjb24ueGI7CiAJKCogZG9tIGlzIHRoZSBzYW1lICopCi0JSGFzaHRi bC5jbGVhciBjb24udHJhbnNhY3Rpb25zOwogCWNvbi5uZXh0X3RpZCA8LSBp bml0aWFsX25leHRfdGlkOwotCUhhc2h0YmwuY2xlYXIgY29uLndhdGNoZXM7 CiAJKCogYW5vbmlkIGlzIHRoZSBzYW1lICopCi0JY29uLm5iX3dhdGNoZXMg PC0gMDsKIAljb24uc3RhdF9uYl9vcHMgPC0gMDsKIAkoKiBwZXJtIGlzIHRo ZSBzYW1lICopCiAJKCkKZGlmZiAtLWdpdCBhL3Rvb2xzL29jYW1sL3hlbnN0 b3JlZC9wcm9jZXNzLm1sIGIvdG9vbHMvb2NhbWwveGVuc3RvcmVkL3Byb2Nl c3MubWwKaW5kZXggMzMxNjFkYTVlYjhiLi5iMmVlNGQwYWRmMWIgMTAwNjQ0 Ci0tLSBhL3Rvb2xzL29jYW1sL3hlbnN0b3JlZC9wcm9jZXNzLm1sCisrKyBi L3Rvb2xzL29jYW1sL3hlbnN0b3JlZC9wcm9jZXNzLm1sCkBAIC0zMjgsMTUg KzMyOCwxOCBAQCBsZXQgZG9faXNpbnRyb2R1Y2VkIGNvbiBfdCBkb21haW5z IF9jb25zIGRhdGEgPQogCQlpbgogCWlmIGRvbWlkID0gRGVmaW5lLmRvbWlk X3NlbGYgfHwgRG9tYWlucy5leGlzdCBkb21haW5zIGRvbWlkIHRoZW4gIlRc MDAwIiBlbHNlICJGXDAwMCIKIAotKCogb25seSBpbiB4ZW4gPj0gNC4yICop Ci1sZXQgZG9fcmVzZXRfd2F0Y2hlcyBjb24gX3QgX2RvbWFpbnMgY29ucyBf ZGF0YSA9CitsZXQgcmVzZXRfd2F0Y2hlc19hbmRfdHJhbnNhY3Rpb25zIGNv bnMgY29uID0KICAgQ29ubmVjdGlvbnMuZGVsX3dhdGNoZXMgY29ucyBjb247 Ci0gIENvbm5lY3Rpb24uZGVsX3RyYW5zYWN0aW9ucyBjb24KKyAgQ29ubmVj dGlvbi5kZWxfdHJhbnNhY3Rpb25zIGNvbjsKKyAgSGlzdG9yeS50cmltICgp CisKK2xldCBkb19yZXNldF93YXRjaGVzIGNvbiBfdCBfZG9tYWlucyBjb25z IF9kYXRhID0KKyAgcmVzZXRfd2F0Y2hlc19hbmRfdHJhbnNhY3Rpb25zIGNv bnMgY29uCiAKIGxldCBkb19yZWNvbm5lY3QgY29ucyBjb24gPQogICBsZXQg ZG9tc3RyID0gQ29ubmVjdGlvbi5nZXRfZG9tc3RyIGNvbiBpbgogICBpbmZv ICIlcyByZXF1ZXN0cyBhIHJlY29ubmVjdCIgZG9tc3RyOwotICBIaXN0b3J5 LnRyaW0gKCk7CisgIHJlc2V0X3dhdGNoZXNfYW5kX3RyYW5zYWN0aW9ucyBj b25zIGNvbjsKICAgQ29ubmVjdGlvbi5kb19yZWNvbm5lY3QgY29uOwogICBp bmZvICIlcyByZWNvbm5lY3Rpb24gY29tcGxldGUiIGRvbXN0cgogCg== --=separator Content-Type: application/octet-stream; name="xsa512-oxenstored-1.patch" Content-Disposition: attachment; filename="xsa512-oxenstored-1.patch" Content-Transfer-Encoding: base64 RnJvbSA1NDkzMTI2OTJkZTFkMjJlNzBiZTc1YjkzMzllZjFlNTc1YmFhOTY0 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyaWkgU3VsdGFu b3YgPGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgpEYXRlOiBUaHUsIDIw IEF1ZyAyMDI2IDE2OjAwOjAyICswMTAwClN1YmplY3Q6IG94ZW5zdG9yZWQ6 IEZhY3RvciBvdXQgUHJvY2Vzcy5kb19yZWNvbm5lY3QoKQoKVGhlIGxvZ2lj IGZsb3cgaGVyZSBpcyBjb21wbGljYXRlZC4gIEluIHByZXBhcmF0aW9uIHRv IGZpeCBhIGJ1ZywgZmFjdG9yIG91dApyZWNvbm5lY3RpbmcgYSB4ZW5idXMg Y29ubmVjdGlvbiwgYW5kIGZvbGQgSGlzdG9yeS5yZWNvbm5lY3QgaW50byBp dCdzIHNpbmdsZQpjYWxsZXIuCgpObyBmdW5jdGlvbmFsIGNoYW5nZS4KClRo aXMgaXMgcGFydCBvZiBYU0EtNTEyIC8gQ1ZFLTIwMjYtNzk2MDQuCgpTaWdu ZWQtb2ZmLWJ5OiBBbmRyaWkgU3VsdGFub3YgPGFuZHJpeS5zdWx0YW5vdkB2 YXRlcy50ZWNoPgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRy ZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1ieTogQW5kcmlpIFN1 bHRhbm92IDxhbmRyaXkuc3VsdGFub3ZAdmF0ZXMudGVjaD4KCmRpZmYgLS1n aXQgYS9veGVuc3RvcmVkL2hpc3RvcnkubWwgYi9veGVuc3RvcmVkL2hpc3Rv cnkubWwKaW5kZXggYmUxOTk0ZjE4MDIwLi40OTBkN2EwZWU2NmUgMTAwNjQ0 Ci0tLSBhL294ZW5zdG9yZWQvaGlzdG9yeS5tbAorKysgYi9veGVuc3RvcmVk L2hpc3RvcnkubWwKQEAgLTQxLDEwICs0MSw2IEBAIGxldCBlbmRfdHJhbnNh Y3Rpb24gdHhuIGNvbiB0aWQgY29tbWl0ID0KICAgbGV0IHN1Y2Nlc3MgPSBD b25uZWN0aW9uLmVuZF90cmFuc2FjdGlvbiBjb24gdGlkIGNvbW1pdCBpbgog ICB0cmltIH50eG4gKCkgOyBzdWNjZXNzCiAKLWxldCByZWNvbm5lY3QgY29u ID0KLSAgdHJpbSAoKSA7Ci0gIENvbm5lY3Rpb24uZG9fcmVjb25uZWN0IGNv bgotCiBsZXQgcHVzaCAoeCA6IGhpc3RvcnlfcmVjb3JkKSA9CiAgIGxldCBk b20gPSB4LmNvbi5Db25uZWN0aW9uLmRvbSBpbgogICBtYXRjaCBkb20gd2l0 aApkaWZmIC0tZ2l0IGEvb3hlbnN0b3JlZC9wcm9jZXNzLm1sIGIvb3hlbnN0 b3JlZC9wcm9jZXNzLm1sCmluZGV4IDQ3N2I0ZTQxYjNiZS4uNTIzYWQ0ZmFh ZmQ4IDEwMDY0NAotLS0gYS9veGVuc3RvcmVkL3Byb2Nlc3MubWwKKysrIGIv b3hlbnN0b3JlZC9wcm9jZXNzLm1sCkBAIC00NzcsNiArNDc3LDEzIEBAIGxl dCBkb19yZXNldF93YXRjaGVzIGNvbiBfdCBfZG9tYWlucyBjb25zIF9kYXRh ID0KICAgQ29ubmVjdGlvbnMuZGVsX3dhdGNoZXMgY29ucyBjb24gOwogICBD b25uZWN0aW9uLmRlbF90cmFuc2FjdGlvbnMgY29uCiAKK2xldCBkb19yZWNv bm5lY3QgY29ucyBjb24gPQorICBsZXQgZG9tc3RyID0gQ29ubmVjdGlvbi5n ZXRfZG9tc3RyIGNvbiBpbgorICBpbmZvICIlcyByZXF1ZXN0cyBhIHJlY29u bmVjdCIgZG9tc3RyIDsKKyAgSGlzdG9yeS50cmltICgpIDsKKyAgQ29ubmVj dGlvbi5kb19yZWNvbm5lY3QgY29uIDsKKyAgaW5mbyAiJXMgcmVjb25uZWN0 aW9uIGNvbXBsZXRlIiBkb21zdHIKKwogKCogb25seSBpbiA+PSB4ZW4zLjMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqKQogbGV0 IGRvX3NldF90YXJnZXQgY29uIF90IF9kb21haW5zIGNvbnMgZGF0YSA9CiAg IGlmIG5vdCAoQ29ubmVjdGlvbi5pc19kb20wIGNvbikgdGhlbgpAQCAtOTc2 LDEwICs5ODMsNyBAQCBsZXQgZG9faW5wdXQgc3RvcmUgY29ucyBkb21zIGNv biA9CiAgICAgICAgIE5vbmUKICAgICB3aXRoCiAgICAgfCBYZW5idXMuWGIu UmVjb25uZWN0IC0+Ci0gICAgICAgIGluZm8gIiVzIHJlcXVlc3RzIGEgcmVj b25uZWN0IiAoQ29ubmVjdGlvbi5nZXRfZG9tc3RyIGNvbikgOwotICAgICAg ICBIaXN0b3J5LnJlY29ubmVjdCBjb24gOwotICAgICAgICBpbmZvICIlcyBy ZWNvbm5lY3Rpb24gY29tcGxldGUiIChDb25uZWN0aW9uLmdldF9kb21zdHIg Y29uKSA7Ci0gICAgICAgIE5vbmUKKyAgICAgICAgZG9fcmVjb25uZWN0IGNv bnMgY29uIDsgTm9uZQogICAgIHwgSW52YWxpZF9hcmd1bWVudCBleHAgfCBG YWlsdXJlIGV4cCAtPgogICAgICAgICBlcnJvciAiY2F1Z2h0IGV4Y2VwdGlv biAlcyIgZXhwIDsKICAgICAgICAgZXJyb3IgImdvdCBhIGJhZCBjbGllbnQg JXMiIChzcHJpbnRmICIlLThzIiAoQ29ubmVjdGlvbi5nZXRfZG9tc3RyIGNv bikpIDsKQEAgLTEwMDIsNyArMTAwNiw3IEBAIGxldCBkb19pbnB1dCBzdG9y ZSBjb25zIGRvbXMgY29uID0KICAgICAgIHdyaXRlX2FjY2Vzc19sb2cgfnR5 IH50aWQgfmNvbjooQ29ubmVjdGlvbi5nZXRfZG9tc3RyIGNvbikgfmRhdGEg OwogICAgICAgQ29ubmVjdGlvbi5pbmNyX29wcyBjb24KIAotbGV0IGRvX291 dHB1dCBfc3RvcmUgX2NvbnMgX2RvbXMgY29uID0KK2xldCBkb19vdXRwdXQg X3N0b3JlIGNvbnMgX2RvbXMgY29uID0KICAgQ29ubmVjdGlvbi5zb3VyY2Vf Zmx1c2hfd2F0Y2hldmVudHMgY29uIDsKICAgaWYgQ29ubmVjdGlvbi5oYXNf b3V0cHV0IGNvbiB0aGVuICgKICAgICAoIGlmIENvbm5lY3Rpb24uaGFzX25l d19vdXRwdXQgY29uIHRoZW4KQEAgLTEwMTUsOCArMTAxOSw1IEBAIGxldCBk b19vdXRwdXQgX3N0b3JlIF9jb25zIF9kb21zIGNvbiA9CiAgICAgICAgIHdy aXRlX2Fuc3dlcl9sb2cgfnR5IH50aWQgfmNvbjooQ29ubmVjdGlvbi5nZXRf ZG9tc3RyIGNvbikgfmRhdGEKICAgICApIDsKICAgICB0cnkgaWdub3JlIChD b25uZWN0aW9uLmRvX291dHB1dCBjb24pCi0gICAgd2l0aCBYZW5idXMuWGIu UmVjb25uZWN0IC0+Ci0gICAgICBpbmZvICIlcyByZXF1ZXN0cyBhIHJlY29u bmVjdCIgKENvbm5lY3Rpb24uZ2V0X2RvbXN0ciBjb24pIDsKLSAgICAgIEhp c3RvcnkucmVjb25uZWN0IGNvbiA7Ci0gICAgICBpbmZvICIlcyByZWNvbm5l Y3Rpb24gY29tcGxldGUiIChDb25uZWN0aW9uLmdldF9kb21zdHIgY29uKQor ICAgIHdpdGggWGVuYnVzLlhiLlJlY29ubmVjdCAtPiBkb19yZWNvbm5lY3Qg Y29ucyBjb24KICAgKQo= --=separator Content-Type: application/octet-stream; name="xsa512-oxenstored-2.patch" Content-Disposition: attachment; filename="xsa512-oxenstored-2.patch" Content-Transfer-Encoding: base64 RnJvbSBkYTQ3YjU5Njk1NzZkNjBlODg2NGI1ZWNjNGZkMGRiNjdlN2U0NjAx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyaWkgU3VsdGFu b3YgPGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgpEYXRlOiBUaHUsIDIw IEF1ZyAyMDI2IDE1OjAwOjAyICswMDAwClN1YmplY3Q6IG94ZW5zdG9yZWQ6 IFJlc2V0IHRoZSB3YXRjaGVzIHRyaWUgb24gZG9tYWluIHJlY29ubmVjdAoK b3hlbnN0b3JlZCBtYWludGFpbnMgdHdvIGRhdGFzdHJ1Y3R1cmVzIGFib3V0 IHdhdGNoZXM7IG9uZSBnbG9iYWwgdHJpZSwgYW5kCm9uZSBoYXNodGFibGUg dHJhY2tlZCBwZXIgZG9tYWluLiAgQm90aCBuZWVkIGtlZXBpbmcgaW4gc3lu YywgYW5kIHJpZ2h0IG5vdwp0aGUgZ2xvYmFsIHRyaWUgaXMgbm90IGVtcHRp ZWQgd2hlbiBhIHhlbmJ1cyByZWNvbm5lY3QgaXMgcmVxdWVzdGVkLgoKVGhp cyBpcyBiYXNpY2FsbHkgdGhlIHNhbWUgYnVnIGFzIFhTQS0zMzAsIGNvbW1p dCA5MTAzODhiYjRmMzcKKCJ0b29scy9vY2FtbC94ZW5zdG9yZWQ6IGRlbGV0 ZSB3YXRjaCBmcm9tIHRyaWUgdG9vIHdoZW4gcmVzZXR0aW5nIHdhdGNoZXMi KSwKanVzdCB0aWNrbGVkIHZpYSBhbm90aGVyIHBhdGguCgpBcnJhbmdlIGZv ciBib3RoIFByb2Nlc3MuZG9fcmVzZXRfd2F0Y2hlcygpIGFuZCBQcm9jZXNz LmRvX3JlY29ubmVjdCgpIHRvCnNoYXJlIGEgY29tbW9uIGNvZGVwYXRoIGZv ciB0aGUgcmVzZXR0aW5nIG9mIHdhdGNoZXMgYW5kIHRyYW5zYWN0aW9ucy4K Tm90YWJseSwgdGhpcyBtZWFucyB0aGF0IHRoZSBsYXR0ZXIgbm93IGNhbGxz IENvbm5lY3Rpb25zLmRlbF93YXRjaGVzKCkgd2hpY2gKY2xlYXJzIHRoZSBn bG9iYWwgdHJpZSB0b28uCgpDb25uZWN0aW9ucy5kZWxfd2F0Y2hlcygpIGFs cmVhZHkgY2FsbHMgQ29ubmVjdGlvbi5kZWxfd2F0Y2hlcygpIHNvIHJlbW92 ZSB0aGUKcmUtY2xlYXJpbmcgb2YgdGhlIHN0YXRlIGZyb20gQ29ubmVjdGlv bi5kb19yZWNvbm5lY3QoKS4KCk1vdmUgSGlzdG9yeS50cmltKCkgaW50byBy ZXNldF93YXRjaGVzX2FuZF90cmFuc2FjdGlvbnMoKSBzbyBpdCdzIG9uIHRo ZQpjb21tb24gcGF0aCwgYW5kIHBsYWNlIGl0IGFmdGVyIHJlbW92aW5nIHRo ZSB0cmFuc2FjdGlvbnMgcmF0aGVyIHRoYW4gYmVmb3JlLgoKVGhpcyBpcyBw YXJ0IG9mIFhTQS01MTIgLyBDVkUtMjAyNi03OTYwNC4KClJlcG9ydGVkLWJ5 OiBEYXZpZCBLb3Jjenluc2tpIDxEYXZpZEBBZGFsb2dpY3MuY29tPgpGaXhl czogNjc0YWQyYmU0MDlkICgieGVuc3RvcmU6IGV4dGVuZCB0aGUgeGVuc3Rv cmUgcmluZyB3aXRoIGEgJ2Nsb3NpbmcnIHNpZ25hbCIpClNpZ25lZC1vZmYt Ynk6IEFuZHJpaSBTdWx0YW5vdiA8YW5kcml5LnN1bHRhbm92QHZhdGVzLnRl Y2g+ClNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29w ZXIzQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBBbmRyaWkgU3VsdGFub3Yg PGFuZHJpeS5zdWx0YW5vdkB2YXRlcy50ZWNoPgoKZGlmZiAtLWdpdCBhL294 ZW5zdG9yZWQvY29ubmVjdGlvbi5tbCBiL294ZW5zdG9yZWQvY29ubmVjdGlv bi5tbAppbmRleCAyOWQxOTExZjMxNzkuLjU4YjkwYThmYWE1YyAxMDA2NDQK LS0tIGEvb3hlbnN0b3JlZC9jb25uZWN0aW9uLm1sCisrKyBiL294ZW5zdG9y ZWQvY29ubmVjdGlvbi5tbApAQCAtMTkzLDEzICsxOTMsMTEgQEAgbGV0IG1h cmtfYXNfYmFkIGNvbiA9CiBsZXQgaW5pdGlhbF9uZXh0X3RpZCA9IDEKIAog bGV0IGRvX3JlY29ubmVjdCBjb24gPQorICAoKiB0cmFuc2FjdGlvbnMgYW5k IHdhdGNoZXMgaGFuZGxlZCBieSBjYWxsZXIgKikKICAgWGVuYnVzLlhiLnJl Y29ubmVjdCBjb24ueGIgOwogICAoKiBkb20gaXMgdGhlIHNhbWUgKikKLSAg SGFzaHRibC5jbGVhciBjb24udHJhbnNhY3Rpb25zIDsKICAgY29uLm5leHRf dGlkIDwtIGluaXRpYWxfbmV4dF90aWQgOwotICBIYXNodGJsLmNsZWFyIGNv bi53YXRjaGVzIDsKICAgKCogYW5vbmlkIGlzIHRoZSBzYW1lICopCi0gIGNv bi5uYl93YXRjaGVzIDwtIDAgOwogICBjb24uc3RhdF9uYl9vcHMgPC0gMCA7 CiAgICgqIHBlcm0gaXMgdGhlIHNhbWUgKikKICAgKCkKZGlmZiAtLWdpdCBh L294ZW5zdG9yZWQvcHJvY2Vzcy5tbCBiL294ZW5zdG9yZWQvcHJvY2Vzcy5t bAppbmRleCA1MjNhZDRmYWFmZDguLjAzOGNkYjcyYmUwYiAxMDA2NDQKLS0t IGEvb3hlbnN0b3JlZC9wcm9jZXNzLm1sCisrKyBiL294ZW5zdG9yZWQvcHJv Y2Vzcy5tbApAQCAtNDcyLDE1ICs0NzIsMTggQEAgbGV0IGRvX2lzaW50cm9k dWNlZCBjb24gX3QgZG9tYWlucyBfY29ucyBkYXRhID0KICAgZWxzZQogICAg ICJGXDAwMCIKIAotKCogb25seSBpbiB4ZW4gPj0gNC4yICopCi1sZXQgZG9f cmVzZXRfd2F0Y2hlcyBjb24gX3QgX2RvbWFpbnMgY29ucyBfZGF0YSA9Cits ZXQgcmVzZXRfd2F0Y2hlc19hbmRfdHJhbnNhY3Rpb25zIGNvbnMgY29uID0K ICAgQ29ubmVjdGlvbnMuZGVsX3dhdGNoZXMgY29ucyBjb24gOwotICBDb25u ZWN0aW9uLmRlbF90cmFuc2FjdGlvbnMgY29uCisgIENvbm5lY3Rpb24uZGVs X3RyYW5zYWN0aW9ucyBjb24gOworICBIaXN0b3J5LnRyaW0gKCkKKworbGV0 IGRvX3Jlc2V0X3dhdGNoZXMgY29uIF90IF9kb21haW5zIGNvbnMgX2RhdGEg PQorICByZXNldF93YXRjaGVzX2FuZF90cmFuc2FjdGlvbnMgY29ucyBjb24K IAogbGV0IGRvX3JlY29ubmVjdCBjb25zIGNvbiA9CiAgIGxldCBkb21zdHIg PSBDb25uZWN0aW9uLmdldF9kb21zdHIgY29uIGluCiAgIGluZm8gIiVzIHJl cXVlc3RzIGEgcmVjb25uZWN0IiBkb21zdHIgOwotICBIaXN0b3J5LnRyaW0g KCkgOworICByZXNldF93YXRjaGVzX2FuZF90cmFuc2FjdGlvbnMgY29ucyBj b24gOwogICBDb25uZWN0aW9uLmRvX3JlY29ubmVjdCBjb24gOwogICBpbmZv ICIlcyByZWNvbm5lY3Rpb24gY29tcGxldGUiIGRvbXN0cgogCg== --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:01:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:01:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411341.1642151 (Exim 4.92) (envelope-from ) id 1x3uVb-0007aB-Ve; Tue, 08 Sep 2026 12:01:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411341.1642151; Tue, 08 Sep 2026 12:01:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVb-0007W1-8P; Tue, 08 Sep 2026 12:01:03 +0000 Received: by outflank-mailman (input) for mailman id 1411341; Tue, 08 Sep 2026 12:01:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uVY-0006bj-7D; Tue, 08 Sep 2026 12:01:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uVW-004OAf-UC; Tue, 08 Sep 2026 14:00:58 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ff8f2-e002-0a2a0a5209dd-0a2a450b9730-30 for ; Tue, 08 Sep 2026 14:00:58 +0200 Received: from [104.130.215.37] (helo=mail.xenproject.org) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ff8f9-b7e8-0a2a450b0019-6882d7258fae-3 for ; Tue, 08 Sep 2026 14:00:58 +0200 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x3uVQ-004n5e-3D; Tue, 08 Sep 2026 12:00:53 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1x3uVR-00Gl8b-0v; Tue, 08 Sep 2026 12:00:53 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.510 (Entity 5.510) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team CC: Xen.org security team Subject: Xen Security Advisory 513 v3 (CVE-2026-79605,CVE-2026-79606) - Out-of-bounds accesses in Tapdisk Message-Id: Date: Tue, 08 Sep 2026 12:00:53 +0000 X-purgate-ID: tlsNG-42698a/1788868858-186CA9EA-4D68BDF9/0/0 X-purgate-type: clean X-purgate-size: 13168 --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2026-79605,CVE-2026-79606 / XSA-513 version 3 Out-of-bounds accesses in Tapdisk UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Tapdisk is a userspace xen-blkback implementation used by the XAPI toolstack. Several bounds checks have been found to be incorrect. * There is no upper bounds check for blkif->last_sect. Passing a value larger than 7 will result in a read or write beyond the mapped grant. This is CVE-2026-79605. * The gcopy_segs[] object has incorrect bounds checks on it. Passing nr_segments between 12 and 32 will corrupt adjacent memory. This is CVE-2026-79606. IMPACT ====== A malicious guest can obtain code execution within the tapdisk process running in dom0. Tapdisk normally runs as root. VULNERABLE SYSTEMS ================== All versions of tapdisk are vulnerable. MITIGATION ========== There are no mitigations. CREDITS ======= Found by Jihwan Yoon of NAVER Cloud, and reported via XenServer. RESOLUTION ========== Applying the appropriate attached patchs resolves this issue. xsa513-?.patch blktap master $ sha256sum xsa513* 41e5f1929a7acbe83820ee0b359f9558120222d32442ea4fb5a6eee0bf937bf1 xsa513-1.patch a5af5a73d2ede5124735213e4974f1aeff7f8118dfbacd52fbb03168fe96c6af xsa513-2.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmqf98kMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZiuMIAIaNhPYKG/UeGc1JV70GEcyqS4d6NNlNBY0qtuGl qVQ8LRVBReqRk0aS0hNDI7txFRsZ18ENteBKG/JaXD4mj5rylpnKdl7y8suTFrGi QuFk1EyYBrud5gtpwW8sq4GKQLf5hoAIIUDGX4qmEC+blRuHTagUIHNwehrkRB+d 38UxmWQR2ppgBSsCJlclMJKSm1nWo04Qx/Nm3Aoc0og0hv+/UkdkDShTGrP/nutb /r4yywz6LaqdCl7Te1ULx6sRVl1MIxtDqcvsRajqKc9nV56RAgrj3moIJRXRusW9 YqZxuUw8HJkhpisOlj6A/N16f+G7bxZwb3FEZBKuNGvM6lQ= =oXUQ -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa513-1.patch" Content-Disposition: attachment; filename="xsa513-1.patch" Content-Transfer-Encoding: base64 RnJvbTogTWFyayBTeW1zIDxtYXJrLnN5bXNAY2l0cml4LmNvbT4KU3ViamVj dDogVmFsaWRhdGUgZ3Vlc3QgYmxraWYgcmVxdWVzdCBzZWdtZW50IGJvdW5k cwoKZmlyc3Rfc2VjdC9sYXN0X3NlY3QgaW4gYSBibGtpZiByZXF1ZXN0IHNl Z21lbnQgYXJlIGd1ZXN0LWNvbnRyb2xsZWQgOC1iaXQKdmFsdWVzLCBidXQg ZWFjaCBzZWdtZW50IGFkZHJlc3NlcyBhdCBtb3N0IGEgc2luZ2xlIHBhZ2Ug KDggc2VjdG9ycykuCnRhcGRpc2tfeGVuYmxraWZfcGFyc2VfcmVxdWVzdCgp IG9ubHkgY2hlY2tlZCBsYXN0X3NlY3QgPj0gZmlyc3Rfc2VjdCwgc28gYQpz ZWdtZW50IHdpdGggbGFzdF9zZWN0ID4gNyB5aWVsZGVkIGFuIG92ZXJzaXpl ZCB0cmFuc2ZlciBsZW5ndGguIFRoYXQgZHJpdmVzCm91dC1vZi1ib3VuZHMg cG9pbnRlciBhcml0aG1ldGljIGFnYWluc3QgdGhlIHBlci1yZXF1ZXN0IGJ1 ZmZlciBhbmQgb3ZlcmZsb3dzCnRoZSB1aW50MTZfdCBnbnRkZXYgZ3JhbnQt Y29weSBsZW5ndGggaW4gZ3Vlc3RfY29weTIoKSAoZS5nLiA2OEtCIHRydW5j YXRlcyB0bwo0S0IsIHNvIHN0YWxlIGJ1ZmZlciBjb250ZW50cyBhcmUgdHJh bnNmZXJyZWQpLgoKUmVqZWN0IGFueSBzZWdtZW50IHdob3NlIHNlY3RvcnMg ZmFsbCBvdXRzaWRlIHRoZSBwYWdlLCByZXBsYWNpbmcgdGhlCmxvbmctc3Rh bmRpbmcgVE9ETyBhdCB0aGUgdmVjdG9yaXNhdGlvbiBsb29wLgoKVGhpcyBp cyBDVkUtMjAyNi03OTYwNSwgcGFydCBvZiBYU0EtNTEzLgoKU2lnbmVkLW9m Zi1ieTogTWFyayBTeW1zIDxtYXJrLnN5bXNAY2l0cml4LmNvbT4KQ28tQXV0 aG9yZWQtQnk6IENsYXVkZSBPcHVzIDQuOCA8bm9yZXBseUBhbnRocm9waWMu Y29tPgpSZXZpZXdlZC1ieTogVGltIFNtaXRoIDx0aW0uc21pdGhAY2l0cml4 LmNvbT4KCmRpZmYgLS1naXQgYS9kcml2ZXJzL3RkLXJlcS5jIGIvZHJpdmVy cy90ZC1yZXEuYwppbmRleCAyYTNmYjA1ZjRhZDAuLjY5YTk0N2Y1NzBlYyAx MDA2NDQKLS0tIGEvZHJpdmVycy90ZC1yZXEuYworKysgYi9kcml2ZXJzL3Rk LXJlcS5jCkBAIC02NDQsOCArNjQ0LDE2IEBAIHRhcGRpc2tfeGVuYmxraWZf cGFyc2VfcmVxdWVzdChzdHJ1Y3QgdGRfeGVuYmxraWYgKiBjb25zdCBibGtp ZiwKICAgICAgICAgLyoKICAgICAgICAgICogTm90ZSB0aGF0IGZpcnN0IGFu ZCBsYXN0IG1heSBiZSBlcXVhbCwgd2hpY2ggbWVhbnMgb25seSBvbmUgc2Vj dG9yCiAgICAgICAgICAqIG11c3QgYmUgdHJhbnNmZXJyZWQuCisgICAgICAg ICAqCisgICAgICAgICAqIGZpcnN0X3NlY3QvbGFzdF9zZWN0IGFyZSBndWVz dC1jb250cm9sbGVkIDgtYml0IHZhbHVlcywgYnV0IGVhY2gKKyAgICAgICAg ICogc2VnbWVudCBhZGRyZXNzZXMgYXQgbW9zdCBhIHNpbmdsZSBwYWdlLiBS ZWplY3QgYW55IHNlZ21lbnQgd2hvc2UKKyAgICAgICAgICogc2VjdG9ycyBm YWxsIG91dHNpZGUgdGhlIHBhZ2U6IGFuIG91dC1vZi1yYW5nZSBsYXN0X3Nl Y3Qgd291bGQKKyAgICAgICAgICogcHJvZHVjZSBhbiBvdmVyc2l6ZWQgdHJh bnNmZXIgbGVuZ3RoICh3aGljaCBhbHNvIG92ZXJmbG93cyB0aGUKKyAgICAg ICAgICogdWludDE2X3QgZ250ZGV2IGdyYW50LWNvcHkgbGVuZ3RoKSBhbmQg ZHJpdmUgb3V0LW9mLWJvdW5kcyBhY2Nlc3NlcworICAgICAgICAgKiB0byB0 aGUgcGVyLXJlcXVlc3QgYnVmZmVyLgogICAgICAgICAgKi8KLSAgICAgICAg aWYgKHNlZy0+bGFzdF9zZWN0IDwgc2VnLT5maXJzdF9zZWN0KSB7CisgICAg ICAgIGlmIChzZWctPmxhc3Rfc2VjdCA8IHNlZy0+Zmlyc3Rfc2VjdCB8fAor ICAgICAgICAgICAgc2VnLT5sYXN0X3NlY3QgPj0gKFBBR0VfU0laRSA+PiBT RUNUT1JfU0hJRlQpKSB7CiAgICAgICAgICAgICBSSU5HX0VSUihibGtpZiwg InJlcSAlbHU6IGludmFsaWQgc2VjdG9ycyAlZC0lZFxuIiwKICAgICAgICAg ICAgICAgICAgICAgcmVxLT5tc2cuaWQsIHNlZy0+Zmlyc3Rfc2VjdCwgc2Vn LT5sYXN0X3NlY3QpOwogICAgICAgICAgICAgZXJyID0gRUlOVkFMOwpAQCAt NjcwLDcgKzY3OCw3IEBAIHRhcGRpc2tfeGVuYmxraWZfcGFyc2VfcmVxdWVz dChzdHJ1Y3QgdGRfeGVuYmxraWYgKiBjb25zdCBibGtpZiwKICAgICAgICAg c3RydWN0IGJsa2lmX3JlcXVlc3Rfc2VnbWVudCAqc2VnID0gJnJlcS0+bXNn LnNlZ1tpXTsKICAgICAgICAgc2l6ZV90IHNpemU7CiAKLSAgICAgICAgLyog VE9ETyBjaGVjayB0aGF0IGZpcnN0X3NlY3QvbGFzdF9zZWN0IGFyZSB3aXRo aW4gcGFnZSAqLworICAgICAgICAvKiBmaXJzdF9zZWN0L2xhc3Rfc2VjdCBh cmUgYWxyZWFkeSB2YWxpZGF0ZWQsIGFib3ZlICovCiAKICAgICAgICAgbmV4 dCA9IHBhZ2UgKyAoc2VnLT5maXJzdF9zZWN0IDw8IFNFQ1RPUl9TSElGVCk7 CiAgICAgICAgIHNpemUgPSBzZWctPmxhc3Rfc2VjdCAtIHNlZy0+Zmlyc3Rf c2VjdCArIDE7Cg== --=separator Content-Type: application/octet-stream; name="xsa513-2.patch" Content-Disposition: attachment; filename="xsa513-2.patch" Content-Transfer-Encoding: base64 RnJvbTogTWFyayBTeW1zIDxtYXJrLnN5bXNAY2l0cml4LmNvbT4KU3ViamVj dDogQm91bmQgbnJfc2VnbWVudHMgYnkgc2VnW10gY2FwYWNpdHkgYW5kIHJp Z2h0LXNpemUgYnVmZmVyCgpUd28gY29uc3RhbnRzIHdlcmUgaW4gcGxheSBm b3IgdGhlIG51bWJlciBvZiBzZWdtZW50cyBpbiBhIHJlcXVlc3Q6CgogLSBC TEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QgKDExKSwgdGhlIFhlbiBB QkkgbGltaXQgYW5kIHRoZSBzaXplIG9mIHRoZQogICByaW5nIGRlc2NyaXB0 b3IncyBibGtpZl9yZXF1ZXN0LnNlZ1tdIGFycmF5OyBhbmQKIC0gQkxLSUZf TUFYX0JVRkZFUl9TRUdNRU5UU19QRVJfUkVRVUVTVCAoMzIpLCBhIGJsa3Rh cC1sb2NhbCB2YWx1ZSBpbnRyb2R1Y2VkCiAgIHdoZW4gbXVsdGktcGFnZSBy aW5ncyB3ZXJlIGVuYWJsZWQgKGRkNjA5NWMpLgoKTXVsdGktcGFnZSByaW5n cyBlbmxhcmdlIHRoZSByaW5nIChtb3JlIHJlcXVlc3Qgc2xvdHMpLCBub3Qg dGhlIG51bWJlciBvZgpzZWdtZW50cyBwZXIgcmVxdWVzdCwgc28gc2l6aW5n IHRoZSBwZXItcmVxdWVzdCBzdHJ1Y3R1cmVzIGJ5IDMyIHdhcyBib3RoCnVu bmVjZXNzYXJ5IGFuZCB1bnNhZmU6CgogLSB0YXBkaXNrX3hlbmJsa2lmX21h a2VfdmJkX3JlcXVlc3QoKSB2YWxpZGF0ZWQgbnJfc2VnbWVudHMgYWdhaW5z dCAzMiwgYnV0CiAgIG5yX3NlZ21lbnRzIGlzIGEgZ3Vlc3QtY29udHJvbGxl ZCB1aW50OF90IGFuZCBtc2cuc2VnW10gb25seSBob2xkcyAxMQogICBlbnRy aWVzLiBBIHJlcXVlc3Qgd2l0aCBucl9zZWdtZW50cyBpbiAoMTEsIDMyXSBw YXNzZWQgdmFsaWRhdGlvbiBhbmQgdGhlbgogICBkcm92ZSBvdXQtb2YtYm91 bmRzIHJlYWRzIG9mIG1zZy5zZWdbXSBpbiB0YXBkaXNrX3hlbmJsa2lmX3Bh cnNlX3JlcXVlc3QoKQogICBhbmQgZ3Vlc3RfY29weTIoKSwgd2hvc2Ugc3Rh bGUgYnl0ZXMgd2VyZSB1c2VkIGFzIGdyZWYvZmlyc3Rfc2VjdC9sYXN0X3Nl Y3QuCiAtIFRoZSBwZXItcmVxdWVzdCBidWZmZXIgYW5kIHRoZSBpb3ZbXS9n cmVmW10gYXJyYXlzIHdlcmUgb3Zlci1hbGxvY2F0ZWQgdG8gMzIKICAgcGFn ZXMvZW50cmllcyB3aGVyZSBvbmx5IDExIGFyZSByZWFjaGFibGUgKGdjb3B5 X3NlZ3NbXSB3YXMgYWxyZWFkeSAxMSkuCgpCb3VuZCBucl9zZWdtZW50cyBi eSBCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVFU1QgYW5kIHNpemUgdGhl IHBlci1yZXF1ZXN0CmJ1ZmZlciAoVERfUkVRX0JVRkZFUl9TSVpFKSBhbmQg dGhlIGlvdltdL2dyZWZbXSBhcnJheXMgYnkgdGhlIHNhbWUgY29uc3RhbnQs CnNvIHRoZSB2YWxpZGF0aW9uIGJvdW5kLCB0aGUgc2VnbWVudCBhcnJheXMs IGFuZCB0aGUgcmluZyBkZXNjcmlwdG9yJ3Mgc2VnW10KYWxsIGFncmVlLiBi bG9jay1sY2FjaGUuYyBpbmhlcml0cyB0aGUgY29ycmVjdGVkIGJ1ZmZlciBz aXplIHZpYQpURF9SRVFfQlVGRkVSX1NJWkUuIEFsc28gZGVyaXZlIHRoZSBi dWZjYWNoZSBtdW5tYXAgc2l6ZSBmcm9tIFREX1JFUV9CVUZGRVJfU0laRQpz byB0aGUgbWFwIGFuZCB1bm1hcCBzaXplcyBzaGFyZSBvbmUgZGVmaW5pdGlv bi4KClRoZSBsZWdhY3kgYmxrdGFwMiBrZXJuZWwtbW1hcCBtYWNyb3MgaW4g YmxrdGFwbGliLmggKE1NQVBfUEFHRVMgLyBNTUFQX1ZBRERSKQphcmUgYSBz ZXBhcmF0ZSwga2VybmVsLXNoYXJlZCBsYXlvdXQgYW5kIGFyZSBpbnRlbnRp b25hbGx5IGxlZnQgdW50b3VjaGVkLgoKVGhpcyBpcyBDVkUtMjAyNi03OTYw NiwgcGFydCBvZiBYU0EtNTEzLgoKU2lnbmVkLW9mZi1ieTogTWFyayBTeW1z IDxtYXJrLnN5bXNAY2l0cml4LmNvbT4KQ28tQXV0aG9yZWQtQnk6IENsYXVk ZSBPcHVzIDQuOCA8bm9yZXBseUBhbnRocm9waWMuY29tPgpSZXZpZXdlZC1i eTogVGltIFNtaXRoIDx0aW0uc21pdGhAY2l0cml4LmNvbT4KCmRpZmYgLS1n aXQgYS9kcml2ZXJzL3RkLXJlcS5jIGIvZHJpdmVycy90ZC1yZXEuYwppbmRl eCA1YjliMzNmMTVjNWQuLmY0Njc5YWYxMWMzOSAxMDA2NDQKLS0tIGEvZHJp dmVycy90ZC1yZXEuYworKysgYi9kcml2ZXJzL3RkLXJlcS5jCkBAIC0xMjEs NyArMTIxLDcgQEAgdGRfeGVuYmxraWZfYnVmY2FjaGVfZnJlZShzdHJ1Y3Qg dGRfeGVuYmxraWYgKiBjb25zdCBibGtpZikKIAogICAgIHdoaWxlIChibGtp Zi0+bl9yZXFzX2J1ZmNhY2hlX2ZyZWUgPiBURF9SRVFTX0JVRkNBQ0hFX01J Til7CiAgICAgICAgIG11bm1hcChibGtpZi0+cmVxc19idWZjYWNoZVstLWJs a2lmLT5uX3JlcXNfYnVmY2FjaGVfZnJlZV0sCi0gICAgICAgICAgICAgICAo c2l6ZV90KUJMS0lGX01BWF9CVUZGRVJfU0VHTUVOVFNfUEVSX1JFUVVFU1Qg PDwgUEFHRV9TSElGVCk7CisgICAgICAgICAgICAgICAoc2l6ZV90KVREX1JF UV9CVUZGRVJfU0laRSk7CiAgICAgfQogfQogCkBAIC03ODYsMTEgKzc4Niwx NCBAQCB0YXBkaXNrX3hlbmJsa2lmX21ha2VfdmJkX3JlcXVlc3Qoc3RydWN0 IHRkX3hlbmJsa2lmICogY29uc3QgYmxraWYsCiAgICAgZ2V0dGltZW9mZGF5 KCZ0YXByZXEtPnRzLCBOVUxMKTsKIAogICAgIC8qCi0gICAgICogQ2hlY2sg dGhhdCB0aGUgbnVtYmVyIG9mIHNlZ21lbnRzIGlzIHNhbmUuCisgICAgICog Q2hlY2sgdGhhdCB0aGUgbnVtYmVyIG9mIHNlZ21lbnRzIGlzIHNhbmUuIG5y X3NlZ21lbnRzIGlzIGd1ZXN0LQorICAgICAqIGNvbnRyb2xsZWQ7IHRoZSBi bGtpZiBwcm90b2NvbCBwZXJtaXRzIGF0IG1vc3QKKyAgICAgKiBCTEtJRl9N QVhfU0VHTUVOVFNfUEVSX1JFUVVFU1Qgc2VnbWVudHMgcGVyIHJlcXVlc3Qs IHdoaWNoIGlzIGhvdyB0aGUKKyAgICAgKiByaW5nIGRlc2NyaXB0b3IgYW5k IG91ciBwZXItcmVxdWVzdCBidWZmZXJzIGFyZSBzaXplZC4KICAgICAgKi8K ICAgICBpZiAodW5saWtlbHkoKHRhcHJlcS0+bXNnLm5yX3NlZ21lbnRzID09 IDAgJiYKICAgICAgICAgICAgICAgICB0YXByZXEtPm1zZy5vcGVyYXRpb24g IT0gQkxLSUZfT1BfV1JJVEVfQkFSUklFUikgfHwKLSAgICAgICAgICAgIHRh cHJlcS0+bXNnLm5yX3NlZ21lbnRzID4gQkxLSUZfTUFYX0JVRkZFUl9TRUdN RU5UU19QRVJfUkVRVUVTVCkpIHsKKyAgICAgICAgICAgIHRhcHJlcS0+bXNn Lm5yX3NlZ21lbnRzID4gQkxLSUZfTUFYX1NFR01FTlRTX1BFUl9SRVFVRVNU KSkgewogICAgICAgICBSSU5HX0VSUihibGtpZiwgInJlcSAlbHU6IGJhZCBu dW1iZXIgb2Ygc2VnbWVudHMgaW4gcmVxdWVzdCAoJWQpXG4iLAogICAgICAg ICAgICAgICAgIHRhcHJlcS0+bXNnLmlkLCB0YXByZXEtPm1zZy5ucl9zZWdt ZW50cyk7CiAgICAgICAgIGVyciA9IEVJTlZBTDsKZGlmZiAtLWdpdCBhL2Ry aXZlcnMvdGQtcmVxLmggYi9kcml2ZXJzL3RkLXJlcS5oCmluZGV4IGRhZDQw ZjI5NDYyOC4uNzI3OWE5MzVhNmI1IDEwMDY0NAotLS0gYS9kcml2ZXJzL3Rk LXJlcS5oCisrKyBiL2RyaXZlcnMvdGQtcmVxLmgKQEAgLTM4LDcgKzM4LDE0 IEBACiAjaW5jbHVkZSA8eGVuL2dudGRldi5oPgogI2luY2x1ZGUgInRkLWJs a2lmLmgiCiAKLSNkZWZpbmUgVERfUkVRX0JVRkZFUl9TSVpFIChCTEtJRl9N QVhfQlVGRkVSX1NFR01FTlRTX1BFUl9SRVFVRVNUIDw8IFBBR0VfU0hJRlQp CisvKgorICogQSByaW5nIHJlcXVlc3QgZGVzY3JpcHRvciAoYmxraWZfcmVx dWVzdF90KSBjYXJyaWVzIGF0IG1vc3QKKyAqIEJMS0lGX01BWF9TRUdNRU5U U19QRVJfUkVRVUVTVCBzZWdtZW50cywgZWFjaCBtYXBwaW5nIGEgc2luZ2xl IHBhZ2UsIHNvIHRoZQorICogcGVyLXJlcXVlc3QgZGF0YSBidWZmZXIgYW5k IHRoZSB2ZWN0b3Jpc2VkIHNlZ21lbnQgYXJyYXlzIGJlbG93IG9ubHkgZXZl cgorICogbmVlZCB0aGF0IG1hbnkgZW50cmllcy4gKFRoaXMgYmFja2VuZCBk b2VzIG5vdCBpbXBsZW1lbnQgQkxLSUZfT1BfSU5ESVJFQ1QsCisgKiB3aGlj aCBpcyB0aGUgb25seSBtZWNoYW5pc20gdGhhdCB3b3VsZCByYWlzZSB0aGUg cGVyLXJlcXVlc3Qgc2VnbWVudCBjb3VudC4pCisgKi8KKyNkZWZpbmUgVERf UkVRX0JVRkZFUl9TSVpFIChCTEtJRl9NQVhfU0VHTUVOVFNfUEVSX1JFUVVF U1QgPDwgUEFHRV9TSElGVCkKIAogLyoqCiAgKiBSZXByZXNlbnRhdGlvbiBv ZiB0aGUgaW50ZXJtZWRpYXRlIHJlcXVlc3QgdXNlZCB0byByZXRyaWV2ZSBh IHJlcXVlc3QgZnJvbQpAQCAtODAsOSArODcsOSBAQCBzdHJ1Y3QgdGRfeGVu YmxraWZfcmVxIHsKICAgICAvKioKICAgICAgKiBUaGUgc2NhdHRlci9nYXRo ZXIgbGlzdCB0ZF92YmRfcmVxdWVzdF90LmlvdiBwb2ludHMgdG8uCiAgICAg ICovCi0gICAgc3RydWN0IHRkX2lvdmVjIGlvdltCTEtJRl9NQVhfQlVGRkVS X1NFR01FTlRTX1BFUl9SRVFVRVNUXTsKKyAgICBzdHJ1Y3QgdGRfaW92ZWMg aW92W0JMS0lGX01BWF9TRUdNRU5UU19QRVJfUkVRVUVTVF07CiAKLSAgICBn cmFudF9yZWZfdCBncmVmW0JMS0lGX01BWF9CVUZGRVJfU0VHTUVOVFNfUEVS X1JFUVVFU1RdOworICAgIGdyYW50X3JlZl90IGdyZWZbQkxLSUZfTUFYX1NF R01FTlRTX1BFUl9SRVFVRVNUXTsKICAgICBpbnQgcHJvdDsKIAogCXN0cnVj dCBnbnRkZXZfZ3JhbnRfY29weV9zZWdtZW50Cg== --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:17:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:17:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411860.1642337 (Exim 4.92) (envelope-from ) id 1x3uld-0001zJ-VM; Tue, 08 Sep 2026 12:17:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411860.1642337; Tue, 08 Sep 2026 12:17:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uld-0001zC-Qt; Tue, 08 Sep 2026 12:17:37 +0000 Received: by outflank-mailman (input) for mailman id 1411860; Tue, 08 Sep 2026 12:17:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3ulc-0001z4-DH for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:17:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3ulb-004S3u-CT for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:17:35 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ffcd5-8faa-0a2a0a5109dd-0a2a450bdac0-46 for ; Tue, 08 Sep 2026 14:17:35 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ffcdf-b7e8-0a2a450b0019-d1558032dd95-3 for ; Tue, 08 Sep 2026 14:17:35 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-499ac87c92bso49313205e9.1 for ; Tue, 08 Sep 2026 05:17:35 -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-49cfd3f8192sm350315025e9.3.2026.09.08.05.17.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:17:34 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788869855; x=1789474655; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=O5lPzo+t3hfm7cwSI12MDpP1K3B9KD0k3C3qPSDsa/M=; b=NFdz1OZ3BbY5mg+ItSKIzE/nTxVDhsJfVU7Kj3BpXjxtl+Co7XPtdpKlnECSf2J7XD oai6mMA7icgtajB0UQgKhl4lU8OI10npm2YvYVtwsz4OieMpKtgEKqo2MJN0majquHVn ltNvsocLEuZAkz/+5ZznofneT8JtPsGuXcsc/H0VJBFZDm3hknuURukcsGZ/Sik5o7j9 7ASgNfHX1FUNethdXJCaxm8VB/vtBnmH3jJJThOZzC00qsSETf9jzPpQ/z3xEF5e6a3r U9TksmHEpo6eOB11+xXGBym8vqDftH5R5uO6WlCIjll3RzqREXbqX0FpaOHVvEDfCxzK reMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788869855; x=1789474655; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=O5lPzo+t3hfm7cwSI12MDpP1K3B9KD0k3C3qPSDsa/M=; b=sEYIxrLUdJxsbTEW+EvJhWUk0TAVHv1yIF1kX7BagJaHRDZeHDLRvDbWuIvAFgSs+B k6srebT3OXUnj6dKsJgl6TGVcyp36CTXMyP9O3sPkLIanY02UEDdgqkSK+2g7O9gEV0X FCN4O5L0W+mideQWc3/cZhojZ3OJAZRu3YMFoPdBqoCDuCirJC4gA7AW7CXeGmmAl2C1 6/kVA3AONj0oa4PvaJO9q8DxS3r6PpKgJ3mgqoAF24S9sTBITA0xFXjtEPKQlEOxa71Z j7unEjD0f/rCHhjSnycMmAQR658TXsmdxGzGp0VsTDYmzFCTdpXZCf1snfDjftSmkrg8 7lUQ== X-Gm-Message-State: AFuF++kdbM5MFaZ4zOdryu4qKjVw3m0J0G/myMWdoB9aX5ilPfAM85Cw 4EAeslPWYlKMgxqha6yIp8ROpOxqxW5tBDWV/uNmwVWfvluSXq9XLj2NZfCL8qMFZJZlU830tq7 vykHRNQ== X-Gm-Gg: AYBFou2wNeQ9ncHQmYV8g4+HS3roXXPA3RSMDFxBuox6XTowQyAR3No7thwUA/RSRxQ Y95qMFOi58/fHxiaTMDjVkxjNQtSnIMiS13UHAwSMZWIPQbwkpcnMoC7a6hCwPsPaN/qyYR2x00 uc9351RaufNtnoT5t/tk1T1oeIMx7ajGC0zNBABpdpYUonuVveAy9R5S6dB2Mu4txjWGGizvmuV UoYD56DG+tejc3yPuCUq8Ajh2feLl8kRi4l14rnA8bxEzTpyD7ElVrfofHjjqtNhWsjPQ5jukz7 1Vuhu6HKv6TZjphydo6jt3bPJDfOj1fyDXkEUNhkg5+5jvrdSPRqnCQq5igNWuh493ulJvDyz6T s6I3bdwknTs1HQaok1zcdfOVFcyAwctWGlL6xFyFyJcYx17s8PeevXTiPmtpL91pGgBJISPolxY IO8e2uu4MoLgLwwR3lAg62hWuGTBkpc/ka+d+RCaowm0dmqtb6K3CiIpDrM1OoKJY3b46fU9yEP s/GBA7UxmWyN9X8zmcTUYh0awUxRh630u+QBTi+8rbmeQwV8fxB X-Received: by 2002:a05:600c:530d:b0:49c:fc6e:8cae with SMTP id 5b1f17b1804b1-49cfc6e8f24mr232362155e9.18.1788869854572; Tue, 08 Sep 2026 05:17:34 -0700 (PDT) Message-ID: <837bce31-aa87-43ee-82b9-1f188432d572@suse.com> Date: Tue, 8 Sep 2026 14:17:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/HVM: move evtchn_upcall_vector field 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788869855-A92CC9EA-696A5DCE/0/0 X-purgate-type: clean X-purgate-size: 838 ... into an available 8-bit slot, rather than having it followed by 7 bytes of padding. Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/hvm/vcpu.h +++ b/xen/arch/x86/include/asm/hvm/vcpu.h @@ -129,6 +129,8 @@ struct hvm_vcpu { spinlock_t tm_lock; struct list_head tm_list; + uint8_t evtchn_upcall_vector; + bool flag_dr_dirty; bool debug_state_latch; bool single_step; @@ -165,8 +167,6 @@ struct hvm_vcpu { /* In mode delay_for_missed_ticks, VCPUs have differing guest times. */ int64_t stime_offset; - u8 evtchn_upcall_vector; - struct hvm_vcpu_io hvm_io; /* Pending hw/sw interrupt (.vector = -1 means nothing pending). */ From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:21:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:21:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411877.1642344 (Exim 4.92) (envelope-from ) id 1x3up1-0003bg-Ca; Tue, 08 Sep 2026 12:21:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411877.1642344; Tue, 08 Sep 2026 12:21:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3up1-0003bZ-9i; Tue, 08 Sep 2026 12:21:07 +0000 Received: by outflank-mailman (input) for mailman id 1411877; Tue, 08 Sep 2026 12:21:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3up0-0003bR-6L for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:21:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uoz-00H5I8-FB for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:21:05 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ffda5-8faa-0a2a0a5109dd-0a2a45048360-46 for ; Tue, 08 Sep 2026 14:21:05 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ffdb1-b57f-0a2a45040019-d155802ee806-3 for ; Tue, 08 Sep 2026 14:21:05 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49d05d51553so24245895e9.2 for ; Tue, 08 Sep 2026 05:21:05 -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-49ce554d52esm333316485e9.3.2026.09.08.05.21.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:21:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788870065; x=1789474865; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=Y400oWD1wHNJh0ADtJXm8+RnBJvVktOI+IIWHcewNYQ=; b=R4atMQZMSmO7g+jWt/12Hcd3G9ax89Xi2wTBQYWr4PRfIcMH0JJ/GqYsfFGG4hY/qQ RLpV7RPoTiYXIuihpkfA8SBHtG3TI2lRmCm1Y7eAD3k+wVJqINswTRGdy8ckaHsXagIm 7mvHWkiZE8KaJtmjC1+Hh9NjxxKZKhWeSuOq+iGttqo+B4nzYV0/U7s3Maszzc/7P3R3 OHubq8Bb8XL4z2CdTi8Jmc8qpUs8SMT8wkvLvFVYv4y7TGxWQIGO/mvdo2t9L3wVJiBs IH1wQmmlHNBtTUXBxC8no409xCCL6pALmis70r3VoJPjkiDSiAt1s1Rus1tIuG07XiQE dqog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788870065; x=1789474865; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Y400oWD1wHNJh0ADtJXm8+RnBJvVktOI+IIWHcewNYQ=; b=G4xRgMlCQeZOMqi1N6m9Hmo4TjA462J9Ul9SEsGtAXWD2CYeXRo4MrwhUkvI6mnVpB rWj3n0smQmG1mXvw9+P5qfUYp+BPV7/UGqQfcwIXrcQlvQCHykt/i5Wzby5muwNrC31K wQLCVy+b2NVLdDDjPvJWWjGKbuKiDtaWb8lK/LKDdgO2TjlrgA5hZkdUznvPkuEcgrIB 7B6OxrhLBXeNXPb+9jXM55+/XLlwHdAcpkybvvb1Rtg8Xe6hDpuzcAN8ekQRbeOVfJVq lTuFsDOvJGaD0uiX+DXgJA3ljH+zjmlboBW5sdHnVIEgzoPFuqpwgRytEEKipEzSdjZ1 66eg== X-Gm-Message-State: AFuF++mDgrcoadc4bdQcIO+pXS1T4FtrGf5YSJMliOuTFX23T8XdbiGu vvsbsTM/25eB3+1KpaMNcMoyOENG6eGFXwP4wq7hF/Y7NW3+U5VfKvSBXl/qPi+VMg9FfiFgBf2 XjZFTpw== X-Gm-Gg: AYBFou3Z84Qw1lFYz+32AiqzC7ga8kJquAXdg8Fj52GmOVsIfjCV1B/T3isbCBpwLLo vpgOTYJvafR6ytMbupJ27x1cgMt4G+RmKpPxngXQyHq2MGGsKf7ZduHCEuKz3/8JRw2qfcGiM+X B9b/tADMG+pobyXsPF5he6njoyHWS9fbTHGf1XmzvSEBJMsJFuhY5iuDKolh/W8GCvmj2LpAfGX PKIN/lv3T5DpIME+C7JDOL6Rbi6j3uTx/Aofm/p9rgh2TLwwcie8zzZ3q64F+tYxeq0OrGbZsQN /4I4WntUVLSKn2oKQma+btcrXEL7ICTerDfl5ilbSy0mFwcesQTu1b0Y51ZJRS/oYSmQkRNCYRG xAWYEoeFUZSSb95v1BCwsg3oQpctNi2TEbM41VaTJD62S+TvPimnFtoytizT3cmudi3oO5crt/v SN7zWj1G4tEYMVGwrUHl2bcVUtNoXH0qDBp79BeRBu71WjjiQoeZOJMFiaWnRdktmBAk/bKQ1Yf KbIx+CL24DzwIOrb6ouw+RfhXLighYuug3lrHuRGMj0qy6d6xtk X-Received: by 2002:a05:600c:8b88:b0:49c:fc6e:a3d8 with SMTP id 5b1f17b1804b1-49cffde8d95mr239986635e9.23.1788870064722; Tue, 08 Sep 2026 05:21:04 -0700 (PDT) Message-ID: <1ba6f97e-4745-4b12-bc80-dffebcadf576@suse.com> Date: Tue, 8 Sep 2026 14:21:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v1.1 3/4] sched/core: avoid use of "current" in initializer lists To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Juergen Gross , Dario Faggioli , George Dunlap References: Content-Language: en-US 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 X-purgate-ID: tlsNG-ebf023/1788870065-C34C3B50-2175747A/0/0 X-purgate-type: clean X-purgate-size: 4943 TRACE_TIME() uses an initializer list and hence is covered by Misra C:2012 rule 13.1 ("Initializer lists shall not contain persistent side effects"). Use intermediate variables to address this. In vcpu_yield() take the opportunity to rename the existing variable which better would have been used already before. In do_sched_op() extend the scope of and rename an existing variable. Use both variables throughout the function. Also drop a pointless (and slightly malformed, style-wise) cast there, and adjust to other one to by style conformant. No functional change intended. Signed-off-by: Jan Beulich --- Note that the violations presently are reported only for Arm. Similar issues would exist on x86 in Clang builds, afaict. --- v1.1: Also replace further (unrelated) uses of current in do_sched_op(). --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -1531,20 +1531,20 @@ static long do_poll(const struct sched_p /* Voluntarily yield the processor for this allocation. */ long vcpu_yield(void) { - struct vcpu * v=current; + struct vcpu *curr = current; spinlock_t *lock; rcu_read_lock(&sched_res_rculock); - lock = unit_schedule_lock_irq(v->sched_unit); - sched_yield(vcpu_scheduler(v), v->sched_unit); - unit_schedule_unlock_irq(lock, v->sched_unit); + lock = unit_schedule_lock_irq(curr->sched_unit); + sched_yield(vcpu_scheduler(curr), curr->sched_unit); + unit_schedule_unlock_irq(lock, curr->sched_unit); rcu_read_unlock(&sched_res_rculock); SCHED_STAT_CRANK(vcpu_yield); - TRACE_TIME(TRC_SCHED_YIELD, current->domain->domain_id, current->vcpu_id); + TRACE_TIME(TRC_SCHED_YIELD, curr->domain->domain_id, curr->vcpu_id); raise_softirq(SCHEDULE_SOFTIRQ); return 0; } @@ -1914,6 +1914,8 @@ typedef long ret_t; ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { + struct vcpu *curr = current; + struct domain *currd = curr->domain; ret_t ret = 0; switch ( cmd ) @@ -1938,9 +1940,9 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN if ( copy_from_guest(&sched_shutdown, arg, 1) ) break; - TRACE_TIME(TRC_SCHED_SHUTDOWN, current->domain->domain_id, - current->vcpu_id, sched_shutdown.reason); - ret = domain_shutdown(current->domain, (u8)sched_shutdown.reason); + TRACE_TIME(TRC_SCHED_SHUTDOWN, currd->domain_id, curr->vcpu_id, + sched_shutdown.reason); + ret = domain_shutdown(currd, sched_shutdown.reason); break; } @@ -1948,19 +1950,18 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN case SCHEDOP_shutdown_code: { struct sched_shutdown sched_shutdown; - struct domain *d = current->domain; ret = -EFAULT; if ( copy_from_guest(&sched_shutdown, arg, 1) ) break; - TRACE_TIME(TRC_SCHED_SHUTDOWN_CODE, d->domain_id, current->vcpu_id, + TRACE_TIME(TRC_SCHED_SHUTDOWN_CODE, currd->domain_id, curr->vcpu_id, sched_shutdown.reason); - spin_lock(&d->shutdown_lock); - if ( d->shutdown_code == SHUTDOWN_CODE_INVALID ) - d->shutdown_code = (u8)sched_shutdown.reason; - spin_unlock(&d->shutdown_lock); + spin_lock(&currd->shutdown_lock); + if ( currd->shutdown_code == SHUTDOWN_CODE_INVALID ) + currd->shutdown_code = (uint8_t)sched_shutdown.reason; + spin_unlock(&currd->shutdown_lock); ret = 0; break; @@ -1993,7 +1994,7 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN if ( d == NULL ) break; - ret = xsm_schedop_shutdown(XSM_DM_PRIV, current->domain, d); + ret = xsm_schedop_shutdown(XSM_DM_PRIV, currd, d); if ( likely(!ret) ) domain_shutdown(d, sched_remote_shutdown.reason); @@ -2010,8 +2011,7 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN if ( copy_from_guest(&sched_watchdog, arg, 1) ) break; - ret = domain_watchdog( - current->domain, sched_watchdog.id, sched_watchdog.timeout); + ret = domain_watchdog(currd, sched_watchdog.id, sched_watchdog.timeout); break; } @@ -2021,7 +2021,7 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN unsigned int cpu; ret = -EPERM; - if ( !is_hardware_domain(current->domain) ) + if ( !is_hardware_domain(currd) ) break; ret = -EFAULT; @@ -2033,7 +2033,7 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HAN break; cpu = sched_pin_override.pcpu < 0 ? NR_CPUS : sched_pin_override.pcpu; - ret = vcpu_temporary_affinity(current, cpu, VCPU_AFFINITY_OVERRIDE); + ret = vcpu_temporary_affinity(curr, cpu, VCPU_AFFINITY_OVERRIDE); break; } From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:22:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:22:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411893.1642354 (Exim 4.92) (envelope-from ) id 1x3uqI-0004Cw-PL; Tue, 08 Sep 2026 12:22:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411893.1642354; Tue, 08 Sep 2026 12:22:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uqI-0004Cp-MK; Tue, 08 Sep 2026 12:22:26 +0000 Received: by outflank-mailman (input) for mailman id 1411893; Tue, 08 Sep 2026 12:22:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uqH-0004Cj-Ik for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:22:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uqG-00BmUL-U6 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:22:24 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ffe00-8faa-0a2a0a5109dd-0a2a450ba55c-0 for ; Tue, 08 Sep 2026 14:22:24 +0200 Received: from [40.93.196.30] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ffdff-b7e8-0a2a450b0019-285dc41e243c-3 for ; Tue, 08 Sep 2026 14:22:24 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB5056.namprd03.prod.outlook.com (2603:10b6:208:1b2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Tue, 8 Sep 2026 12:22:21 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Tue, 8 Sep 2026 12:22:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=U8y2emMBI9ynufwnnDZMt1h+G/ND71GZBOF7oPasipID/HulSDIDYpYfg8hzb59U/2OLodjdPF7TlTSFRzIPr8bipTtqeTqX3YNbRtWCgM8DWgqYQKQECecYqaS5HtRagyHzs7fEJNvJBaFOycJFOnfKogJe5uSZwb4o5fuR+ug4icTyXbT4QMeOWr/Jt3GvOIXgrmDyzqc9SfTX5KmslGrJl+5b+YEbpCgOlcYdRL+soEXIwXTfOnYhDimQoHyjyJr/2tlQF6USnkfL3m0zOTREYvP6AZyhBwRAhdS90CyKEVKTYxau+ftAIcwrf6fjuI0IHxPpkGATxCvAd4fqRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3TC5WxXG7rrt/FrhpeNxSgCqOXaSHMmr5DeZkB0Oxq4=; b=NVxgtC+kPA55/VHo5LqFjfhfpvJLkSWzoAJCOskc3FS4oniAf596/GBw9CdDmHOy1uJ8VScwzbrQe+3mJlF5ZL3Kq0uyiYtCObg9Q24MWrCnOYFylTSrpIAcU28z3xSXL0HsFBcmhTyLXaIUjta6DlohqXHF9B6cmUujRclp5JU5ZjnDyDHP2BpeZX5tOtVjTfZpAuVG/XlAmqO693O7w92z7eC60mV7gmNqYnFUMQWkBISQAs3V6asHprYwNcMMud3PEUkyFrMz4Ufh4wtQmYvmQca9KbGKLFnutqV8cB5QdGu5WLT8hT6eyBodI2hQMGGHPy38aXn2EwGkY4q/6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3TC5WxXG7rrt/FrhpeNxSgCqOXaSHMmr5DeZkB0Oxq4=; b=v4TYTmm5sLsAR7TxPvkBP9e8C9MN28kpYHJzqFIkiRj9Lg+6vr3mD9WsDB3qM8Y294sOXeBXALk08KYy1ig7FkiVHDrLjWaedy24ugGDo19YY0h3Cpx1r9CSW+FnqaD1gSqbYXZS7+UPa1FDJKeRpX7mEbkG1huBwtIYUN8FXDw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 8 Sep 2026 13:22:18 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/HVM: move evtchn_upcall_vector field To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <837bce31-aa87-43ee-82b9-1f188432d572@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <837bce31-aa87-43ee-82b9-1f188432d572@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0033.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::20) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN2PR03MB5056:EE_ X-MS-Office365-Filtering-Correlation-Id: 52f90a82-79e2-418d-5e3e-08df0da3d4fe X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|10067099003|56012099006|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: xuaj8OWAAqZBeFDW7IkYLH6A+oBJN4gfCEVIOBSNx1XSCm5fa861NsfWumWz2HRKD4rVJuGJtoa+zvHgu6CfWD0vvfNWpB8Q/596tEcRpulwpmlWvElEQayL/5mi0icWIY6qrZpAizIEwxWJutkq2w8JD90TIVUow9SD+q5bW/GUI5MaYIbfiLhJHIZx63ajs1y/3ZbqveRCHvzz9nwAkOxInyQ/Xj+It5Bd6DZyBcT28BSVKvnaQIPfrRPEWxMJ+Z0qqKy08XkxC7ZgUr/y4RcH0gO5Dfw1NSWzJzKW0DN+J2iNoeFrEjbnriEgGbFrjksZACve5zHk9oFNYZ59Xv2INAp/N/rqTu2l7t6RahxzVyDlDumC6U39EgpUTCMkcKFzNewCRU2Wep0wRKTcrbgXTZf2FWUPyaeSzYnJJWrnl9Okl5kfiKH4Di4nqarczi6ApfNofCfFxjoSy5I/Cn9NeDzVtMlyhqCLJ4TRG/P2sP9W7tWT+TaP+9bXoVjcJbJn+uV+p0wCerMhW1X8pnpXULW73zR+b4/ayoYs+WY7YCzgbNSb6CkT7kKA2PxSMlotapaPWuB8/Jx/Srd8VROM2+6X9g84M3XQim0BYgruy4rW1iuHgyOdV84dDNk2w6LYCHsL3D/CObdvCRp/MN8Hu5/6B5r516YhT+oHNi4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NVZqZzRLNWNPQzZzWkFMOW1DRkF2MWllVkVlaWJFUkgzNWJPWVVJcVl4VVRr?= =?utf-8?B?MkRwNUJyYnlrOWhWWVZRNzM1aEJ4Snl4aWRHbDBXaUJVdWFQRWdlYUhjTmF0?= =?utf-8?B?aXp0QndJT1dzMHo3ZTlUdG9Ra0xBZjE4RWE2Q2pNY2F1enF3MHNzYXdOUk5m?= =?utf-8?B?d2FXRXBXN2o3NDNUYUtEWU9qTFByRDRMT1IyWFd3ZCsvM25nTmRySlVtNUcy?= =?utf-8?B?aVZvbVRRa0draEM4dmxyTWwzNnBkN2tBemp1K3pjQklqMk51QTBGUHgrbEJQ?= =?utf-8?B?TzJ4SlQ1TTNaMzNIZm9nTWV4ZENpVWVJd2E5cWxkVnhJMGlycWwwSVhKczdQ?= =?utf-8?B?T0UvdWpuRlE2ZURzTm96bVlCN3Nsd1Jjd1A1Uk9BVmlHbWlHVjYweURrbFFG?= =?utf-8?B?T2haaWdUcU9JV0plZ0d3MmdSM3RUeGdCU3BjczBFVVNma2R0d09jQXIwQ2F5?= =?utf-8?B?Qk8zVzJDVytKSExQNlBSVEQ3UGYrWUZicll1cTBwWTBYT2tPcTA3WHQ4dysr?= =?utf-8?B?eG80aVhpb2lPbmo3Rk9VcTU1eGpOYmR4TURmTTlnNXRRNk5kcC9uRThLRTBM?= =?utf-8?B?ZHZDU2RML0RKUVdrOTZFblcvZDMxUkwxMVdGeG9RODcyTm1wQjMwcFZ0ZnlR?= =?utf-8?B?NnFVTzQwU2MxTTB5M1l1Qk9qU1NFTERuazNvT3FjMU1zM2ZXOStPNkEzV0NL?= =?utf-8?B?Ry94dU9xa2ZRampDeEdBOWZHWElVQU55RzB1SHZDT2NjM3JvVnNGOXhSeW9I?= =?utf-8?B?dDJhMnpWQXZobCtlbURETzBOUC9FODNKaUx5R3RWZllMejhDZXFtYXFobm0v?= =?utf-8?B?Q3VSVjN2bkhqYlVzZXJWV0E5Q2gyWHg3R1kxVGZqVWVTczhGclMvUTFoSWkz?= =?utf-8?B?YytlanYxUGQrOGwvc1duWnlPNkt0OGpLaUk2TFJpNTZOMWhKQytrWlprZG00?= =?utf-8?B?cUJiY2xTSm1ObWE5RUxzVW9LenZHMWJtUmFEdFZxdG9kT0ZTKzhCSmdVZDcx?= =?utf-8?B?dm5KYTVpTU1QMGdpajNFdFZoR2lhYmpkYjZDSnBTcGxCbHJoM2twNlBvemNs?= =?utf-8?B?ajFGSUxRN2pGQzl3SU93OGNDQzFmYlhLRXFudkVORjI4Z09kUjBBM0RSOVNZ?= =?utf-8?B?SExEUndRblNlUTVBVkNFaERMbjJZYlpnTmJZMSt1MHl0ZTNObXZScy9VYW9R?= =?utf-8?B?REc4RTAzaTJEaC84WEJPUGl1ejJRTktPQ0VTenk4NlBPNUdrL29lNjJBUWxp?= =?utf-8?B?ckl5M1d4Tm1GYnlxOHY1OEVsQ3JvUlpXcm55ZWpLZDRKRXdZTFFMM1ptd09q?= =?utf-8?B?RG1zZHBwN0doSzF0VWt1OWFLczYyZm54MS9LdmZDVDRFZm5jMWowamdyRmxX?= =?utf-8?B?dFMyanhTL3N0eVhRNk1mQ3NOZENFNHAvNHh4Zm01MUpIWmJocTZmeEQ5Y25u?= =?utf-8?B?M3d4ODdRNlBXVTY0Z20zVzFEcFI2L2w4SGJlekJjNm96bllCdmJ1NEhKeUhY?= =?utf-8?B?ZkNvMEROYTRHMzNtQUJuMVlUSWZ4aW94ZWo2UkRXeXY4cjNpZjdEdUk5V1Bs?= =?utf-8?B?QWl4UWZpVC83STVQWXZ1Q3BBdXhhMHU3bnVWWnVBOGF6emVUQUhaWWpUYlEv?= =?utf-8?B?QVJlV2lHOVpsUkxGT0w5aFlaQ2pHOVdOUGVJMlBJdHJIVmZLbmk3VXNHbXpr?= =?utf-8?B?eFlrN2xjbkEyTDJxNHVXK2x2VXQ1QTRFUVBXUVAxYjRWRjBPbnM3QlFBVzU1?= =?utf-8?B?emhaRzhvZmZuQ21uWFFpczdmZEpBM2pSRUpWS3M4cktwZWF5b2MybHNBUEZz?= =?utf-8?B?UU5ZM0RjcndkOGpjTE5ZZk12SVlqeFFQZGRzT0xaNkdPeE8wLzl0S1liT1BJ?= =?utf-8?B?bkwwQWdLNVlKeWQyNTZmckxCTUFwZGFZYzk2NjFHK2xXUEUrUWczNDhQUVJM?= =?utf-8?B?WEM4R0Jlc1JKYmc2WStUMGhucDZ5a0owbmQzNUxCdzdxeTJZNEw1aHFyTnIz?= =?utf-8?B?MjAzQUw0VlNtNlhpcW5YL1lLdUZFUGZvQk1WNi9ha0FCWkM0OVB6NWdXOGFm?= =?utf-8?B?ZlN3RGNDU2VKeHBTT3FUeXNXY2JmVjNlVUFKaWdURGZIQ00wK05hUE91dWt6?= =?utf-8?B?Nmp6cUVGZmVxVzY3WkZzd2p4WDBKbHNSSlBxYkUxeEdQLzJDblQwQ3VrVUox?= =?utf-8?B?b3h0K3NuMUpYUkd5RG9BSnliWkZvNHozUWVudzYxMXFyY0NSTGtxM2pnaTRz?= =?utf-8?B?RThlOUcwdjh5MjZWcVg1N1BkY2RWdWZnUTR6UllFbXpIeXdvTnlySDFhb25p?= =?utf-8?B?OHo0UXlaYTJLSUZPbTEraXRGbGpsS1VTSVd5NElTamxoT05seHVVQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52f90a82-79e2-418d-5e3e-08df0da3d4fe X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 12:22:21.5178 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: V/Mk7+zJx3RTZaS8vcQ2Cpdc+qDmnDSfpCFFPjNKkU8xS7+VVZYcVXV0GzYmwn8kbNp9uuyoIxxRvQbpRzAKrxylKpBMJHS+FrbEaojrxlE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5056 X-purgate-ID: tlsNG-42698a/1788870144-182F49EA-4F515A4F/0/0 X-purgate-type: clean X-purgate-size: 245 On 08/09/2026 1:17 pm, Jan Beulich wrote: > ... into an available 8-bit slot, rather than having it followed by 7 > bytes of padding. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:26:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:26:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411910.1642362 (Exim 4.92) (envelope-from ) id 1x3uuY-0004qw-7q; Tue, 08 Sep 2026 12:26:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411910.1642362; Tue, 08 Sep 2026 12:26:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uuY-0004qp-56; Tue, 08 Sep 2026 12:26:50 +0000 Received: by outflank-mailman (input) for mailman id 1411910; Tue, 08 Sep 2026 12:26:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uuX-0004qj-3v for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:26:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uuW-003uv9-Gm for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:26:48 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fff08-e002-0a2a0a5209dd-0a2a4509cf1e-0 for ; Tue, 08 Sep 2026 14:26:48 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fff08-be1a-0a2a45090019-d155dd2bb585-3 for ; Tue, 08 Sep 2026 14:26:48 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-485843aeab8so5107139f8f.1 for ; Tue, 08 Sep 2026 05:26:48 -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 ffacd0b85a97d-4858bc74298sm32279700f8f.6.2026.09.08.05.26.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:26:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Content-Language:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788870408; x=1789475208; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:content-language :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=/jnIXZxy5wL1r0hTCYkZDnPYR/0n3ToX9UUqnXE7Kl4=; b=Fm+87f8w2JBibJTX5uUY4RITXEfP1NrRngn+pSSbCJpgCDM3Z/qjRSWiq+PJQQItQ/ VIH9JyqvPgGIBmDZeQvG/UuV9PT8uWM14n0jJd246cz9AMTSF41hS4LGQv3gpuW4dfqi 68c5ZmZjU53MLnNPrFiBbtO+EmbN5RdSxL66ur9q5tB7egQbHVAdyJXAK9GHoOQVwLX7 UviuNSQhGSiyrnVRkMqwets8dVGNF8lL+jAgeRr2UrdJ/UohrrUQt4/1S7IImPwor7yi 3nBMeHmuCwGAFAl+n/qqjSALooifnI495W73dfkuD6FE6mhJSKsh7/NSzvO11GUVpJrc JHuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788870408; x=1789475208; h=content-transfer-encoding:content-type:autocrypt:content-language :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/jnIXZxy5wL1r0hTCYkZDnPYR/0n3ToX9UUqnXE7Kl4=; b=krPertEK7LMebgqfG3kiTWTv81rft6vxCRZq/PGj2AgnGL4TJuBsp8skYgdMkQgBbJ Q7DVqj3EL/yRIugBvbvfMYt6CDoqx6bkvHtbyUNpgDndhlmKPGn60vqqNX1TA8TPFkfH DUg6Z8k5wMWLMBCEhAohyQpq/imZiF6PKqOLv1SF+wnZ+p3QD0m5I5NyIE9JDFuo3gWy RcPlcmSjxL7/q3Gr8khD6g5GAgrc9BdNyK2uoy1lHPKnq4BJvmEJmFlNdUCiGoJHZv8G XFMz9EqUSniFRJNHjaMMUxiNvuFQpw1RVc591qsuFj5w3ywzpfmyOQw4kaUK5uJr4cwX RDVg== X-Gm-Message-State: AFuF++lueXo9V3co+1u6qc4sX+9b/E9Nn54SuyafwgW2f6PT6dNW0brO Tj3QOk3UFStNCiBF0d2vOAnu95VxoD5/xB/PtxwcZr0rar0c3XALBlVBZTq43IecGu630L7YELy YjtoaUw== X-Gm-Gg: AYBFou1a3hxLFAo6NTK/ir2pssOTbucibaE8FaMossYFvZSxfCkMFaRIH9PLHf/Bi74 iInOdUAEFH8SqBL80H4EApLKFZvY34XYdFIL99B/TXXh5xb1NSi7xJZoHBz0GUEjWkyEtlfBK1B aLcq7YT/R4J8ZhrH9+D99IR3ifsL/dsHf5UqqThCljZH9mjTsAIMIeWKbCTYkW0uG74MP9k+Ilt dvydNNGrpg2n3Y3bJNUZM+WLjlU4J+6+D3QQEZMAaYxKk3QTJ/K0S9IytwtjZja0mWEzprl54VS mfrA1XBBWnKxsw77+KvV7RNU88Jg6yzdeeUgDd3F+4T7coICFBMRynbncjSlFFl8v4zOLXEepzZ KaMQwo7X9UFq0wbWCJb0pnGY/Vxfy7NWfV2I9oVQ/P42s0K5w0Eig3y5T4U5X8wuHWpc4KezGEL GsPsScPjbssDfv4eFQnIkA0j3KEMpboN2vnLnWdnMbUHcF89onkd9urOMXbo6jpRRO3EHGY7AaM ipnjNB3sMR09SNbgkI0Kuab4z/UbALGH2I7wBeZu9UGdEwVU3ZH X-Received: by 2002:a05:6000:4796:b0:484:3312:f127 with SMTP id ffacd0b85a97d-4858709b371mr47597122f8f.27.1788870407878; Tue, 08 Sep 2026 05:26:47 -0700 (PDT) Message-ID: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Date: Tue, 8 Sep 2026 14:26:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v3 0/6] build: split and unify linking of final image(s) To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Language: en-US 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788870408-FD06B034-F9D8E49D/0/0 X-purgate-type: clean X-purgate-size: 743 The monolithic rules, largely but not entirely identical between ports, were pretty ugly to fiddle with. They also ended up going out of sync when really they would better have stayed consistent. Break them up, and use (largely) the same rules for all ports (x86'es xen.efi being somewhat special, though). The final three patches are related only in so far as they address observations made while doing the conversion. v3 addresses review feedback (patch 1 only; see there for details). 1: x86: split xen-syms/xen.efi linking rules 2: Arm: split xen-syms linking rule 3: RISC-V: split xen-syms linking rule 4: PPC: split xen-syms linking rule 5: build: move $(all-symbols-*) 6: build: move $(compare-symbol-tables) Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:28:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:28:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411919.1642372 (Exim 4.92) (envelope-from ) id 1x3uvr-0005Jx-HQ; Tue, 08 Sep 2026 12:28:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411919.1642372; Tue, 08 Sep 2026 12:28:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uvr-0005Jq-Ek; Tue, 08 Sep 2026 12:28:11 +0000 Received: by outflank-mailman (input) for mailman id 1411919; Tue, 08 Sep 2026 12:28:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uvq-0005Ji-6y for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:28:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uvp-003vKg-K6 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:28:09 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fff56-8faa-0a2a0a5109dd-0a2a4504afdc-10 for ; Tue, 08 Sep 2026 14:28:09 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fff59-b57f-0a2a45040019-d155dd35e59f-3 for ; Tue, 08 Sep 2026 14:28:09 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso3290289f8f.1 for ; Tue, 08 Sep 2026 05:28:09 -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 ffacd0b85a97d-485883a9b49sm30406536f8f.17.2026.09.08.05.28.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:28:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788870489; x=1789475289; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=mdmkLvp6nYkhyhtBgOM6h0nLGXstsr5K+tgDTiHWdn0=; b=Iv+M570sJNy5J+otJgOl90x8LOB7DxB7o16AtGQXX4NC/dCqWr5EUoOzVIarXHRJyk 3CNmmrJNY7iYIBsdhTXvYpRJCjbo6+rvQbxR3EyqG/hYPXLsI75ege3+NIFOpg3kJlOG 2CepWT9bNJY0LZL1upOTIdTXEcnaDIfl5BX6myXOqgmEoKq6CfyVygLcPktN4OZrA5tw BiZklQ9ZeZ7KEL8sf+7rbV8Va9AbpPmp5JsmfFNVhLYozdF29fHRJ1Jeiixspvwv3hMI TojQT3OnsOd/MH1jvHNiSptQMswXLPV1GlQTZfTunEPslXQRstpK+bagA/8+hAHE0uyw E9eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788870489; x=1789475289; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=mdmkLvp6nYkhyhtBgOM6h0nLGXstsr5K+tgDTiHWdn0=; b=NSbUDUvINktM3ezTxU2zcWbz4X2wdmdvJRh1IAEPnIHNzZOv2ws19WQvhCQ+aHrGoi 6xpGh21YmD6D/+xRE9IW16Axq6TIVcjthGodVHNdpYeEzJmAKhjArWeEY/Ytq+GlybG/ +t5RT+VoxCKiBr8yaVmPuuAgstfGNAZYi2MNh9EZMtQXqU85PgzJ78DlnI3e7PmL/qFZ wxydspBut4la2f6AL2Znue+HuOZSNvqYLxCfAShKJDOcA1nuZFroCU1WdaToXM5B3+AE cADy2nsZLQM5IEPp8nPwX8LXqcGE3VnJfkDbSMxUQk8azjespKrshmRkMGfWbNIZoWrV gbQA== X-Gm-Message-State: AFuF++lmTA7qX5Y3A2TMW8whHV9B25D3oXdL5Pcvr4jp6apCuW3hiNTQ RrgwItVMBUFG/beVZ7We05FNzWyRTMrlDO2iLYGOIphlUZA9rTUM8SbvcwhF0dddTMQV44lHldE JVJeK6Q== X-Gm-Gg: AYBFou0ZR0uLU7Xuy/rOSsSRIDwpua2E3EIlKApLE1nRcgu5M+2VT4XGsVUewHgonYb w9Knx36EpMN/VPCdZWvUvMsFKngPrNI6dubFUNThhC9p7428VYYVa8VowAhtoNTF8TDJWbLBwtM UI1qkzY6Ze9Y+OtDQLUTVtIhu4KhsPcX8Tgbc15RLB7cPAhx8daiQK9nO8wibuaq4zKTPeie6uv +J1WCW5a30zryZ+MljWyV7xEi0LlVbg2CmNBoOvsoYFlZUuiFh7IkvWRKLscmTlj0JtK1S3Ag7C 7mtCpdKctBi9wuLF4Va1BUJ5LA3jKcjy5Z0r5/P+RmyVKGmbPt5KetV61IX3LlI606cqbRkt2iU Nnlg2UjCNU501Cx+dLVIliTq6hYPVA/k4WXVmpN/c6joASveEVeiDYqq2faq4vWT+L8gumIfJLo KUjKs23IgMaUN+oG6/M0R5atKmGxVv2S24iOzgctwtyxdKZcTHG6jIfX84u3e5NEbciBwljIYnT cy6NHBsD72R+KzUL58aoItlfqErx2KfzdiPusqqZ23CZZocWDqm X-Received: by 2002:a05:6000:4819:b0:485:8c16:a347 with SMTP id ffacd0b85a97d-4858c16a542mr24404465f8f.31.1788870488852; Tue, 08 Sep 2026 05:28:08 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 14:28:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 1/6] x86: split xen-syms/xen.efi linking rules From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Language: en-US 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: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788870489-50EDEB50-AAB49B68/0/0 X-purgate-type: clean X-purgate-size: 10417 Doing so, besides (hopefully) adding clarity (not the least by way of using pattern rules where possible), also avoids explicit recursive $(MAKE) invocations. For xen-syms move re-usable helper rules to a new scripts/Makefile.link. While doing so, re-order .map file creation (which can in principle fail) and check-endbr.sh invocation ahead of putting in place the final image (which is now the result of a simple rename). Also drop --source-name= from the tools/symbols invocation which has --empty passed, for being meaningless there. Signed-off-by: Jan Beulich --- I'd like to keep the "beautification" part, i.e. transforming to more use of Kbuild.include machinery, separate. The check-endbr.sh invocation doesn't fit neatly into this model. I was considering to move it into $(TARGET)'s rule, but that's not very nice either (both because it'd be odd [strictly speaking: wrong] for xen.efi, and because it would reduce parallelism). --- v3: Drop stale part of description. Have $(final-image-check-y) use sites pass in the intended argument. Drop leftover FORCE from xen.efi logic. Move $(obj)/efi/mkreloc dependency to correct rule. v2: Mark intermediate files as such. Don't use $(if_changed ...). --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -102,12 +102,6 @@ notes_phdrs = --notes endif endif -syms-warn-dup-y := --warn-dup -syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) := -syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup - -orphan-handling-$(call ld-option,--orphan-handling=warn) += --orphan-handling=warn - $(TARGET): TMP = $(dot-target).elf32 $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32 $(obj)/boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TMP) $(XEN_IMG_OFFSET) @@ -119,31 +113,11 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI -$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds - $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S - $(MAKE) $(build)=$(@D) $(dot-target).0.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) --strip-debug \ - $(dot-target).0.o -o $(dot-target).0 - $(NM) -pa --format=sysv $(dot-target).0 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).1.S - $(MAKE) $(build)=$(@D) $(dot-target).1.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) --strip-debug \ - $(dot-target).1.o -o $(dot-target).1 - $(NM) -pa --format=sysv $(dot-target).1 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort $(syms-warn-dup-y) \ - > $(dot-target).2.S - $(MAKE) $(build)=$(@D) $(dot-target).2.o - $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(orphan-handling-y) $(dot-target).2.o -o $@ - $(NM) -pa --format=sysv $@ \ - | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \ - > $@.map - rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]* -ifeq ($(CONFIG_XEN_IBT),y) - $(SHELL) $(srctree)/tools/check-endbr.sh $@ -endif +LAST_LINKING_PASS := 2 + +final-image-check-$(CONFIG_XEN_IBT) = $(SHELL) $(srctree)/tools/check-endbr.sh $(1) + +include scripts/Makefile.link $(obj)/note.o: $(TARGET)-syms $(OBJCOPY) -O binary --only-section=.note.gnu.build-id $< $@.bin @@ -191,51 +165,69 @@ note_file_option ?= $(note_file) extra-$(XEN_BUILD_PE) += efi.lds ifeq ($(XEN_BUILD_PE),y) -$(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o $(obj)/efi/mkreloc -$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds + +.INTERMEDIATE: $(addprefix .$(TARGET).efi., \ + $(foreach n, 0 1 2, \ + $(n) alt.$(n) $(n)r.o $(n)s.o $(n)r.S $(n)s.S)) + +.$(TARGET).efi.%.o: .$(TARGET).efi.%.S + $(call cmd,cc_o_S) + +.$(TARGET).efi.1r.S: .$(TARGET).efi.0 $(if $(relocs-dummy),.$(TARGET).efi.alt.0) +.$(TARGET).efi.2r.S: .$(TARGET).efi.1 $(if $(relocs-dummy),.$(TARGET).efi.alt.1) + +.$(TARGET).efi.0r.o: $(obj)/efi/relocs-dummy.o + ln -sf $< $@ + +.$(TARGET).efi.%r.S: $(obj)/efi/mkreloc + $(MKRELOC) $(filter .$(TARGET).efi.%, $^) > $@ + +.$(TARGET).efi.0s.S: + $(objtree)/tools/symbols $(all_symbols) --empty > $@ + +.$(TARGET).efi.1s.S: .$(TARGET).efi.0 +.$(TARGET).efi.2s.S: .$(TARGET).efi.1 + +.$(TARGET).efi.%s.S: + $(NM) -pa --format=sysv $< \ + | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ + --source-name=$(TARGET).efi.S \ + > $@ + +# See above for why $(note_file) needs removing here. +efi-objs = $(filter-out $(note_file),$(filter %.o,$^)) + +.$(TARGET).efi.%: $(objtree)/prelink.o .$(TARGET).efi.%r.o \ + .$(TARGET).efi.%s.o $(note_file) $(obj)/efi.lds + $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $(efi-objs) \ + --strip-debug $(note_file_option) -o $@ + +.$(TARGET).efi.alt.%: $(objtree)/prelink.o .$(TARGET).efi.%r.o \ + .$(TARGET).efi.%s.o $(note_file) $(obj)/efi.lds + $(LD) $(call EFI_LDFLAGS,$(ALT_BASE)) -T $(obj)/efi.lds $(efi-objs) \ + --strip-debug $(note_file_option) -o $@ + +.$(TARGET).efi.2: $(objtree)/prelink.o $(obj)/efi/relocs-empty.o \ + .$(TARGET).efi.2r.o .$(TARGET).efi.2s.o $(note_file) \ + $(obj)/efi.lds + $(call compare-symbol-tables, .$(TARGET).efi.1r.o, .$(TARGET).efi.2r.o) + $(call compare-symbol-tables, .$(TARGET).efi.1s.o, .$(TARGET).efi.2s.o) + $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $(efi-objs) \ + $(orphan-handling-y) $(note_file_option) -o $@ + +$(TARGET).efi: .$(TARGET).efi.2 ifeq ($(CONFIG_DEBUG_INFO),y) - $(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug info from $(@F)" + $(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "No debug info in $(@F)" endif - $(objtree)/tools/symbols $(all_symbols) --source-name=$(@F).S --empty \ - > $(dot-target).0s.S - $(MAKE) $(build)=$(@D) .$(@F).0s.o - $(foreach base, $(VIRT_BASE) $(ALT_BASE), \ - $(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $< $(relocs-dummy) \ - $(dot-target).0s.o $(note_file_option) --strip-debug \ - -o $(dot-target).$(base).0 &&) : - $(MKRELOC) $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(dot-target).$(base).0) \ - > $(dot-target).1r.S - $(NM) -pa --format=sysv $(dot-target).$(VIRT_BASE).0 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - --source-name=$(@F).S \ - > $(dot-target).1s.S - $(MAKE) $(build)=$(@D) .$(@F).1r.o .$(@F).1s.o - $(foreach base, $(VIRT_BASE) $(ALT_BASE), \ - $(LD) $(call EFI_LDFLAGS,$(base)) -T $(obj)/efi.lds $< --strip-debug \ - $(dot-target).1r.o $(dot-target).1s.o $(note_file_option) \ - -o $(dot-target).$(base).1 &&) : - $(MKRELOC) $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(dot-target).$(base).1) \ - > $(dot-target).2r.S - $(NM) -pa --format=sysv $(dot-target).$(VIRT_BASE).1 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - --source-name=$(@F).S \ - > $(dot-target).2s.S - $(MAKE) $(build)=$(@D) .$(@F).2r.o .$(@F).2s.o - $(call compare-symbol-tables, $(dot-target).1r.o, $(dot-target).2r.o) - $(call compare-symbol-tables, $(dot-target).1s.o, $(dot-target).2s.o) - $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< $(obj)/efi/relocs-empty.o \ - $(dot-target).2r.o $(dot-target).2s.o $(orphan-handling-y) \ - $(note_file_option) -o $@ - $(NM) -pa --format=sysv $@ \ - | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \ - > $@.map + $(NM) -pa --format=sysv $< \ + | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \ + > $@.map ifeq ($(CONFIG_DEBUG_INFO),y) - $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $@ $@.elf + $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O elf64-x86-64 $< $@.elf endif + $(call final-image-check-y, $<) + mv $< $@ rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]* -ifeq ($(CONFIG_XEN_IBT),y) - $(SHELL) $(srctree)/tools/check-endbr.sh $@ -endif else $(TARGET).efi: FORCE rm -f $@ --- /dev/null +++ b/xen/scripts/Makefile.link @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0 +# ========================================================================== +# Helper rules for linking xen-syms +# ========================================================================== + +syms-warn-dup-y := --warn-dup +syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) := +syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup + +orphan-handling-$(call ld-option,--orphan-handling=warn) := --orphan-handling=warn + +final-image-check-y ?= true + +.INTERMEDIATE: $(addprefix .$(TARGET)-syms.,$(foreach n,0 1 2 3,$(n) $(n).o $(n).S)) + +.$(TARGET)-syms.%.o: .$(TARGET)-syms.%.S + $(call cmd,cc_o_S) + +.$(TARGET)-syms.0.S: + $(objtree)/tools/symbols $(all_symbols) --empty > $@ + +.$(TARGET)-syms.1.S: .$(TARGET)-syms.0 +.$(TARGET)-syms.2.S: .$(TARGET)-syms.1 +.$(TARGET)-syms.3.S: .$(TARGET)-syms.2 + +.$(TARGET)-syms.%.S: + $(NM) -pa --format=sysv $< \ + | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ + $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \ + > $@ + +.$(TARGET)-syms.%: $(objtree)/prelink.o .$(TARGET)-syms.%.o $(obj)/xen.lds + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \ + $(build_id_linker) --strip-debug -o $@ + +.$(TARGET)-syms.$(LAST_LINKING_PASS): $(objtree)/prelink.o \ + .$(TARGET)-syms.$(LAST_LINKING_PASS).o \ + $(obj)/xen.lds + $(call compare-symbol-tables, \ + .$(TARGET)-syms.$(shell expr $(LAST_LINKING_PASS) - 1).o, \ + .$(TARGET)-syms.$(LAST_LINKING_PASS).o) + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \ + $(build_id_linker) $(orphan-handling-y) -o $@ + +$(TARGET)-syms: .$(TARGET)-syms.$(LAST_LINKING_PASS) + $(NM) -pa --format=sysv $< \ + | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \ + > $@.map + $(call final-image-check-y, $<) + mv $< $@ + rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]* From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:28:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:28:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411922.1642381 (Exim 4.92) (envelope-from ) id 1x3uwM-0005hz-TK; Tue, 08 Sep 2026 12:28:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411922.1642381; Tue, 08 Sep 2026 12:28: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 1x3uwM-0005hr-Q4; Tue, 08 Sep 2026 12:28:42 +0000 Received: by outflank-mailman (input) for mailman id 1411922; Tue, 08 Sep 2026 12:28:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uwL-0005hU-2y for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:28:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uwK-00DGpw-Fm for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:28:40 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fff6e-e002-0a2a0a5209dd-0a2a450cde94-28 for ; Tue, 08 Sep 2026 14:28:40 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fff78-f479-0a2a450c0019-d1558033c9c2-3 for ; Tue, 08 Sep 2026 14:28:40 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-49ccfbe062eso44019405e9.3 for ; Tue, 08 Sep 2026 05:28:40 -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-49ce591f846sm229036025e9.1.2026.09.08.05.28.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:28:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788870520; x=1789475320; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=Iv2vMmZDDkUbtSsBC1iLfuXEsdGTvN+CdOPuJTT4q+M=; b=HjVMG4sv1rvGjemFV3CtWRum+vwydICFkqV+hZ2ZNUpk/yh5g3uwCllEGLXm5F0nAq 9gzepqA9hkkoqjnjzOTyGQuBnRdGyYWEdQs8bzuzYrKPgLWzAseYdZs91NxDEAOer2xh rmV6qMudcA+SLl6wVsK40YnsdT3a83CF9vo0dQcKbxuNzG/dc8uQVo8ol4MqnENyFAJt DnVB8pR5pvJND8tV/M1Gl8Zpys66zn1k+JwEbU9KvPwL1l+3FHTqCNGNZIbSWg8E/roV Wn6joMHb4NFwCM9BS7FfnweYhqMY2xvhKrgcXLyV/xqMFoyFa1+t6xpxHDJs5c1meWn7 lDfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788870520; x=1789475320; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Iv2vMmZDDkUbtSsBC1iLfuXEsdGTvN+CdOPuJTT4q+M=; b=JbU1Tx75gAuVajT9KSQgCA4WA/efTz2n1B5di1fGrXUtSqe/XvMZkGwAOBLOuaLXmE 4yzExDgGbGFmYpQd/gX8hllG6t48p066JO08gmJp3PhPksEFUyjeyB/wdLvpG5wzDZSh ZWIOwllzjDbSp3iVAguvWQ4hBOwWoykCh2rh6un0a/Ju+cPB2sDQBvRBR4uV2Vg9Uc7n yIPzcZ/xC0/6BkgjaiGIBAX9MqiJ/8S3PvsF+vO2wF8vGhPuheTM5ToFBtySscHOdoNM KFBX6V4cVLqC75PP/hpgPFgxCARYsWOXo3GDr7yd4ukOCqarBHP33Q0/ty96b18zF8AS hasQ== X-Gm-Message-State: AFuF++kniu2O7S75IsAF0vzR4Z6LeeFLeYCVrm9ZiSdXAk3LDNsANMdt 9/zU9hG6LJcbNDYKf2skDT01FmLWvuQofnCsewrlRjuRCwwG9pVkprfK3CP6jWCpnxgkdMkLHhS cu3TbKw== X-Gm-Gg: AYBFou0NJlrSmLtvSzAxTQR5AFTYwFkDWqONt1hOp0t3QeK7q6OtUHp5i7WxJdYH/Nd JSK4gBgtIuiI6fCIPZ91a7UtVvxvcFeKOfW9nbwk3mXlNbRgxpGxobFBlY6RHGGmcaC7Ue3IBXD 1YwKczs4l3M73f8YQCdBBkd45Am1YK2fkw8grambKP0O6azxgDucQrnWqZ7FjSRBLQgEyeu8VP+ MgTszqGlM0Zoygyfe+ajfiCGTxBuZzaY33gq1qwRByiN+YctIKf3GDE5Dd0Ioh39KtceqFB4mQ2 XnWBIBy8pjml0QwrNBhyzDzcWNSO60V50VsAD7NKxkuuIfrFk8bZh/xsLv3gKCObsckZ7N6XZRx znuiuEJbGEmH1IfEt4no87R622Hx4ihCixmE9qDL5k3sjP7/+zNoPQka6YOOk04CKi95yMssi5N WCqFSp02U09om+VBxwSJ2e8PjyTjWh1fHHI5PfmjoKYqdB4ZxYfUbLqADglgI4yobvPnsAvhpIi HnGBp14YfpPkoSwDnugq8tl4mfjgaOBwH1mAXHXPHB/PeBnKPCV X-Received: by 2002:a05:600c:314f:b0:49c:ffde:45ff with SMTP id 5b1f17b1804b1-49cffde4629mr227184785e9.17.1788870519858; Tue, 08 Sep 2026 05:28:39 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 14:28:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 2/6] Arm: split xen-syms linking rule From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Language: en-US 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: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788870520-03ED2A5B-48B8E538/0/0 X-purgate-type: clean X-purgate-size: 3878 Doing so, besides (hopefully) adding clarity (not the least by way of [re-]using pattern rules where possible), also avoids explicit recursive $(MAKE) invocations. By re-using the generic rules introduced when the respective x86 rule was split, - the .map file now isn't created after the final binary anymore, - --strip-debug is passed to $(LD) during early linking passes (for consistency the option is also explicitly added to the optional linking pass rule), - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are now properly respected. Orphan section checking, otoh, is getting suppressed for now, until the about a dozen warnings which would result have been taken care of. While the 4th linking step continues to be avoided when possible, a redundant invocation of $(NM) and tools/symbols (plus the assembling of the resulting .S file) is hopefully deemed acceptable. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD --- As for the x86 patch, I'd like to keep the "beautification" part, i.e. transforming to more use of Kbuild.include machinery, separate. --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -84,40 +84,12 @@ ifeq ($(CONFIG_ARM_64),y) ln -sf $(@F) $@.efi endif -$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds - $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S - $(MAKE) $(build)=$(@D) $(dot-target).0.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).0.o -o $(dot-target).0 - $(NM) -pa --format=sysv $(dot-target).0 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).1.S - $(MAKE) $(build)=$(@D) $(dot-target).1.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).1.o -o $(dot-target).1 - $(NM) -pa --format=sysv $(dot-target).1 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).2.S - $(MAKE) $(build)=$(@D) $(dot-target).2.o - if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \ - then \ - set -e; \ - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).2.o -o $(dot-target).2; \ - $(NM) -pa --format=sysv $(dot-target).2 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).3.S; \ - $(MAKE) $(build)=$(@D) $(dot-target).3.o; \ - $(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \ - else \ - ln -sf $(dot-target).2.o $(dot-target).3.o; \ - fi - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).3.o -o $@ - $(NM) -pa --format=sysv $@ \ - | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \ - > $@.map - rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]* +LAST_LINKING_PASS := 3 + +include scripts/Makefile.link + +# Suppress orphan section checking for the time being. +orphan-handling-y := .PHONY: include include: --- a/xen/scripts/Makefile.link +++ b/xen/scripts/Makefile.link @@ -33,6 +33,19 @@ final-image-check-y ?= true $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \ $(build_id_linker) --strip-debug -o $@ +ifneq ($(LAST_LINKING_PASS),2) + +.$(TARGET)-syms.2: $(objtree)/prelink.o .$(TARGET)-syms.2.o $(obj)/xen.lds + if ! { $(call compare-symbol-tables, .$(TARGET)-syms.1.o, .$(TARGET)-syms.2.o) >/dev/null; }; \ + then \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \ + $(build_id_linker) --strip-debug -o $@; \ + else \ + ln -sf .$(TARGET)-syms.1 $@; \ + fi + +endif + .$(TARGET)-syms.$(LAST_LINKING_PASS): $(objtree)/prelink.o \ .$(TARGET)-syms.$(LAST_LINKING_PASS).o \ $(obj)/xen.lds From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:29:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:29:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411932.1642389 (Exim 4.92) (envelope-from ) id 1x3uwm-0006HT-4n; Tue, 08 Sep 2026 12:29:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411932.1642389; Tue, 08 Sep 2026 12:29:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uwm-0006HK-28; Tue, 08 Sep 2026 12:29:08 +0000 Received: by outflank-mailman (input) for mailman id 1411932; Tue, 08 Sep 2026 12:29:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3uwl-0006HA-I5 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:29:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uwk-001cW4-V1 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:29:06 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fff8a-8faa-0a2a0a5109dd-0a2a450aa976-14 for ; Tue, 08 Sep 2026 14:29:06 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fff92-f2d2-0a2a450a0019-d1558035cda1-3 for ; Tue, 08 Sep 2026 14:29:06 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-498028b3d5eso43792205e9.1 for ; Tue, 08 Sep 2026 05:29:06 -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-49d04fe7f9dsm290984285e9.0.2026.09.08.05.29.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:29:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788870546; x=1789475346; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=QquCSsjr9+yRZ78MRMZyhAJQGwjy2mQJD5ivmHA7k+Q=; b=LzdPEJUurq2/vhmczzFydOgHUPre4ooHZpKcyAWAqKYK7qrUA6E5FeIZ8Rje56V/Kj pdD24F0OpnFvN86gBPkdhenEpd1WO/Nzs6Oe0o/ARVBc2KcOjJCNi++2EpUT85Np7v2u SfUZ+/bVDfkOajRUn4/++z8CsYi2+MelO7Vxjv0IcFZDlykMfB4204sZHyphaV2Kn3xX W+qspNhslxoveTMlhHnEGzzhS2ZmFEFz+Ua+NJSzAH9yFhupdBllpNpyIiIQnuj0pE1h IO8kL2hE4h1hEh7xv0cTmb0l3pzz7rlFKBIC86GfXjyBzIf3tW/50wqFVH5VJYoWxAUC 4kog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788870546; x=1789475346; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=QquCSsjr9+yRZ78MRMZyhAJQGwjy2mQJD5ivmHA7k+Q=; b=P0/ldCAwPIJGIReR5Sl73FmNb12pDnVzmh2ZihwF0KsT6DU5fUvMmKp435Au1/MAYu +x0Mh9kS1W08RFlQKEI8nClfiXw2U5nJOhnETMjgsLYa130vFXS2iJ+lSuy0kMGFJAgI 3PgV0TgnpdU0eYckhYlwgilVtHb60tgKeygLwRyD5PWVv3+5RZl+Pi3miWKC1lTqgZWc 27B+9dPkYnoXeuODM8jJ685LFV2Xels3XKjsgcx8AXiU8I8GFxl1MKAlJGRC+iVUz5FV iQsosF7vxHV1qVTJYq0/LET3Ta1+WZTEYNnPDtm5zj4GClPXPc/3uiB2HK/5+SlTtLAu UckA== X-Gm-Message-State: AFuF++ljZhPFJbR9iWqTyU20Rjc1JqRRFOEwzoahTRC7CplB0KoBaFJ+ DszeAol5snbivxJ4O4P/gEWOaazKVVUmEYxCiwKWXEdKkB+hgegCAGlX4tyWocpGpxVUBX5U+pa 3KHQwHA== X-Gm-Gg: AYBFou3fBWd47VTl4v5+Xo9gaQsAbEOAb7RoO3mTJ6Vwe1IYy2ufgoul+PKiVtGWHOq 8kniptC51cQREx1USuJ/uflbbBhf97rDPk+PuhE0mU39iNS0Nm1050CbdgEx8O3LqnYHeuTkfT3 FebjAfxoL++1z3Hf8p8gpOUzSEJt0WQLECCnUooz3u1GasQQFkIE0w88ReeI16O3rYcCMITKoxy XcsZTgcBkpdqd91wymar8NqWa5Ay9DqTomwjS6txiOT6xexIJ8D0bqeTdhujOoeXny0Q9xYtHG+ iZ8cuAmbUdoTmT3pqAwmSWrhUz8xWOWL/vuPKo+6UDdau6gxuo0XQLs6Ekyr3qbml0sdL7yZi4Z SP4kw56F3nOfXO5iA7d1tygnKRlLatFf9U140jvPRTWe0p6gwGZFsh9sewnlDYKppMTz6WmIhPy sOudP1AC0JWPoffcG9Ne31nisye1uN2Kacg0pWqjL6IYJjXifxrjkoPxjjYGj/Qf3YAyrQi4F2m MdycDholY7nOtIjpfhwfWJYS4GIETAdxDbCnGWgmXjy2ucDS+I8 X-Received: by 2002:a05:600c:3b02:b0:49c:fa21:1c7d with SMTP id 5b1f17b1804b1-49cfa211d76mr269958855e9.18.1788870546243; Tue, 08 Sep 2026 05:29:06 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 14:29:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 3/6] RISC-V: split xen-syms linking rule From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alistair Francis , Connor Davis , Oleksii Kurochko References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Language: en-US 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: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788870546-4B8D5CFC-4FE45DCB/10/73395122804 X-purgate-type: spam X-purgate-size: 2987 Doing so, besides (hopefully) adding clarity (not the least by way of [re-]using pattern rules where possible), also avoids explicit recursive $(MAKE) invocations. By re-using the generic rules introduced when the respective x86 rule was split, - the .map file now isn't created after the final binary anymore, - --strip-debug is passed to $(LD) during early linking passes (for consistency the option is also explicitly added to the optional linking pass rule), - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are now properly respected. Orphan section checking, otoh, is getting suppressed for now, until the about a dozen warnings which would result have been taken care of. While the 4th linking step continues to be avoided when possible, a redundant invocation of $(NM) and tools/symbols (plus the assembling of the resulting .S file) is hopefully deemed acceptable. Signed-off-by: Jan Beulich Reviewed-by: Oleksii Kurochko --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -31,40 +31,12 @@ obj-y += vtimer.o $(TARGET): $(TARGET)-syms $(OBJCOPY) -O binary -S $< $@ -$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds - $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S - $(MAKE) $(build)=$(@D) $(dot-target).0.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).0.o -o $(dot-target).0 - $(NM) -pa --format=sysv $(dot-target).0 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).1.S - $(MAKE) $(build)=$(@D) $(dot-target).1.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).1.o -o $(dot-target).1 - $(NM) -pa --format=sysv $(dot-target).1 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).2.S - $(MAKE) $(build)=$(@D) $(dot-target).2.o - if ! { $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) >/dev/null; }; \ - then \ - set -e; \ - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).2.o -o $(dot-target).2; \ - $(NM) -pa --format=sysv $(dot-target).2 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).3.S; \ - $(MAKE) $(build)=$(@D) $(dot-target).3.o; \ - $(call compare-symbol-tables, $(dot-target).2.o, $(dot-target).3.o); \ - else \ - ln -sf $(dot-target).2.o $(dot-target).3.o; \ - fi - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).3.o -o $@ - $(NM) -pa --format=sysv $@ \ - | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \ - > $@.map - rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]* +LAST_LINKING_PASS := 3 + +include scripts/Makefile.link + +# Suppress orphan section checking for the time being. +orphan-handling-y := $(obj)/xen.lds: $(src)/xen.lds.S FORCE $(call if_changed_dep,cpp_lds_S) From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:29:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:29:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411939.1642398 (Exim 4.92) (envelope-from ) id 1x3uxA-0006j0-CA; Tue, 08 Sep 2026 12:29:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411939.1642398; Tue, 08 Sep 2026 12:29:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uxA-0006it-9V; Tue, 08 Sep 2026 12:29:32 +0000 Received: by outflank-mailman (input) for mailman id 1411939; Tue, 08 Sep 2026 12:29:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3ux9-0006ij-Hp for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:29:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3ux8-001cia-Us for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:29:30 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fff9e-bab6-0a2a0a5309dd-0a2a4501b972-24 for ; Tue, 08 Sep 2026 14:29:30 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fffaa-5984-0a2a45010019-d1558036b479-3 for ; Tue, 08 Sep 2026 14:29:30 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49b9320423cso51674495e9.0 for ; Tue, 08 Sep 2026 05:29:30 -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-49d00a5b19dsm324066855e9.2.2026.09.08.05.29.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:29:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788870570; x=1789475370; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=3Uv3x4F3bahJVd0v49025RLOSGv5M2Xej8rLk94QGpY=; b=gkTKy5dzWf7litWwAA2K1y+1s2J+xiQ01TKOHrH3XcEJzbAZHX65BhjDdY85iYBwZw gLVekH9+NMj96b6o3gc/D1uR3OrANW9GMaIOkyUfgIsj5SMFPvTGttatJA+v9+tMo4cb A7y+Zb7uG4tyhsLD+7iSIyS6JBckncOjc8k9Ua2s6GQ34zl7JL0HsprBPHgrLO/MjYYY mSlekZBoYu3fdHh7mMM6y/lVrZMkADODBDav6rrN3n/fe5WlvCF+2PvUTuXt75MustRd M2tSJTNeBvEz6gfdxyIrxpoTQcE66V3w/7ceEsTB1SegBuGEoDAmwF8HG0NwZl5zydC0 itEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788870570; x=1789475370; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=3Uv3x4F3bahJVd0v49025RLOSGv5M2Xej8rLk94QGpY=; b=fUkjdWDp/O1oBTGL2Fyc7mMpfobh2lN59bjgpu45HPW1DbWRATrpUl8tQGZhyoI5Wn MiFETXCAid/4R2ASoruYCQzsiJdJaMTP/tWFoNtcQ02ZMLULigYMtufhUoJ5bdJKiLrx t2ha1+sz+Tsql51i92AW2DfppXSaA8ltnxIE+12PUKktFhdqdSr13aGoKSrzoDIdGLLp CXvwL87DPYmrLx7r/aM04My/jbpBmqBGN3PqdFKS8UiDF2mTP2p9DeBJTkkbPlz++gEc +Au2PukY3c95YnadZ8+d060gQXF+R7/0V8usYeDFP1WSjRipW2EsM+eXfHFESDVkeRHE k9Eg== X-Gm-Message-State: AFuF++khR+dSnK2LuSqqEm8zMeD3jJISD5nOSscjUp1V+nIMotGvXq7O rlrYQYk19XmTRWfEHV3QtMDuzLZ62GZo+aRu4f1ck0Uor/hyrXXLZa/9FfGL1PGJT1s5gLArhLM ms66nGg== X-Gm-Gg: AYBFou2CXPRGNBgpAmjJJ95TOncEhAo2ehMAVnlcjeidRRf+8lADA7fKpX8IO2tWR5Q GDidX2qS3BLDOZip9neTnbVvS1dOfg0sgTl2i+g1bhmFCoiEjNWrmMSC/cNFXQ+070PxM1pb3xn gFeMPe44FXWao2FzSLx7Kx353Nc5XzwLTJFNN3fwZcsMmIQbKwed92ddyiFu811XqrqFyy8DdFS 2gUMgLBoSHs52ljxgnXQCy9f4942VtSEjp468tdKtjf2FVyChSoISrfrYOquzO8iigOaJl6ZnKf poO+gIm1eTHMrVGuV4z/Owi2wbV8TbJKomwD8bcaY6P1RTcNpck9ssatYu1p2N8lnJ29ED2LQSA 2l4R6otqHNF2jvYr2t8IEH9a9kHoB9tm6M3HbW+HqkQBUbDbRVbla1expKRYaptdwVd7hgVKc8R ooiFDn22dt9UarXLThTS1qk0UjSjlH3M3A6vCzKqoXj/5qZqVGjmuWai3mYUZ/lkYD0UJYIj13/ RRcKP819dDhx/XDMJnBAy59DhAzbaakZtkdBzsi6D4zKEuQSHP2 X-Received: by 2002:a05:600c:4e94:b0:498:943:ccc0 with SMTP id 5b1f17b1804b1-49cf81e368emr489093245e9.6.1788870570161; Tue, 08 Sep 2026 05:29:30 -0700 (PDT) Message-ID: <6502b5fe-7127-4a5c-b16e-aa1525c54201@suse.com> Date: Tue, 8 Sep 2026 14:29:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 4/6] PPC: split xen-syms linking rule From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Language: en-US 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: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1788870570-BE867757-FB2D2EE4/0/0 X-purgate-type: clean X-purgate-size: 2276 Doing so, besides (hopefully) adding clarity (not the least by way of [re-]using pattern rules where possible), also avoids explicit recursive $(MAKE) invocations. By re-using the generic rules introduced when the respective x86 rule was split, - the .map file now isn't created after the final binary anymore, - --strip-debug is passed to $(LD) during early linking passes (for consistency the option is also explicitly added to the optional linking pass rule), - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are now properly respected. Orphan section checking, otoh, is getting suppressed for now, until the about a dozen warnings which would result have been taken care of. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD --- a/xen/arch/ppc/Makefile +++ b/xen/arch/ppc/Makefile @@ -11,28 +11,12 @@ obj-y += tlb-radix.o $(TARGET): $(TARGET)-syms cp -f $< $@ -$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds - $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S - $(MAKE) $(build)=$(@D) $(dot-target).0.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).0.o -o $(dot-target).0 - $(NM) -pa --format=sysv $(dot-target).0 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).1.S - $(MAKE) $(build)=$(@D) $(dot-target).1.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).1.o -o $(dot-target).1 - $(NM) -pa --format=sysv $(dot-target).1 \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - > $(dot-target).2.S - $(MAKE) $(build)=$(@D) $(dot-target).2.o - $(call compare-symbol-tables, $(dot-target).1.o, $(dot-target).2.o) - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ - $(dot-target).2.o -o $@ - $(NM) -pa --format=sysv $@ \ - | $(objtree)/tools/symbols --all-symbols --xensyms --sysv --sort \ - > $@.map - rm -f $(dot-target).[0-9]* $(@D)/..$(@F).[0-9]* +LAST_LINKING_PASS := 2 + +include scripts/Makefile.link + +# Suppress orphan section checking for the time being. +orphan-handling-y := $(obj)/xen.lds: $(src)/xen.lds.S FORCE $(call if_changed_dep,cpp_lds_S) From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:30:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:30:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411949.1642409 (Exim 4.92) (envelope-from ) id 1x3uy1-0008Jf-Ox; Tue, 08 Sep 2026 12:30:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411949.1642409; Tue, 08 Sep 2026 12:30:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uy1-0008JY-L5; Tue, 08 Sep 2026 12:30:25 +0000 Received: by outflank-mailman (input) for mailman id 1411949; Tue, 08 Sep 2026 12:30:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uxz-0008J8-Ua for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:30:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uxz-003vnT-9T for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:30:23 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9fffdb-bab6-0a2a0a5309dd-0a2a4506cd22-10 for ; Tue, 08 Sep 2026 14:30:23 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9fffdf-195a-0a2a45060019-d1558033f099-3 for ; Tue, 08 Sep 2026 14:30:23 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-49cf4f81d86so35926895e9.2 for ; Tue, 08 Sep 2026 05:30:23 -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-49cf7736132sm384330685e9.12.2026.09.08.05.30.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:30:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788870623; x=1789475423; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=kiWbQw9EwIxXGXNqk4rZjP+K/qOOMDmRGIIFqlnYnvE=; b=AO1iReM59fFMpshHWr5GYE7CB96aGoUN+uNe+EA/Nd3PwhBnkUIHBjDE/p6XvRJGn0 HJdvfc5bRCmyA2Ug38Fen1cRaeCRpEg2+Rov9KlsBWcdWRQhhs7/GBS3W0OF/K12G4m2 rF0AOGLYFev6Rxyjwj82I+VF0ztIDvrlPayj82garGZSbicD+7n/kVMOVDyew9L+3bF2 W5S7rSyw6U7BDFglopB1IxJldOAYKvlmKCrqcNFo6MDulHkfr3IKfIO4MpyT6IRZ/+fW 004/OnpJSjV+LL+T7q+TpA3ZDmt3JYLCIDXV2njC5Y5jZQ1eSrJC5jc6i26MOH0QVVuY CYOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788870623; x=1789475423; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=kiWbQw9EwIxXGXNqk4rZjP+K/qOOMDmRGIIFqlnYnvE=; b=NNQtvzmBOijb0qI0OgtA8jbCyD8BblF26qd/AeaIKJNFzUJ0LvfY9xurZiRTEj9J5P iwiHUFxMsPasKjLiVBfOF0eJVgictSWf3jAUB4VyAgxUaUwMhj6nFJZa0+x0l8A9jM2E NIdvLbchGKW3j2wzC8dKaTUlEs0n7IV+E5Gpa6QpiC/dPdf9gmYXPpOjI8Ud7KXSEL3d ulFBYGZPVpIrQTvyI/HsYomB1nitZiS+REAtWVgler0xphNHgk+5NHxXm5BqJuiw5cuE vxT6HVX8uKsjVRZCY6sew1nlFNw3SehROD7bH9NjeimyYSCQBuSxbABAezTwiluUmss0 /Gxw== X-Gm-Message-State: AFuF++laEPrt5Pl1aHRi2S2wxcSlmQo5vpyCiAPN8IBR8AKWDvlJOhzx yzETAoKOkU+teJLi8h3PUB3YIP1CB2J6gFZ4X3gGV4BYlF82lCCwbcoAZPUW17t1d/LY927KEi9 1NRp0eg== X-Gm-Gg: AYBFou1PDXDcitfSQ/Fuf4lN/6WpHxk9LJpEdHyGXXU7iaUckX7BK6w7a7yUBkF3xOi jezP7pQInqVpVEUXdrjAFyaA8Ue1W3CX+LkrvZwGBtxFB/86LWy3DCcL2oj3tWNTv/C83RVINRf KYQQz9GLoB45yj3/MESVh2vnUJ0yoaFQxwtfxWl51NFnGDQefIgNHlvX13YWwsMPdBM+hWaREq+ E1uUDeki5rQaYj6ZARZVODk9Tl3vFHHEiueZ9RtXM60JrBtwcuJaiI5PK6kzNt9liE5lwAAPPz+ h8w0Vge3BOG3rk4Yq+Jaa3ivgJ9VLvX9BFHNd61woTvJW6/qsbT3L5GKMVbgm+8tEEPv5zdRUDD OetI1FQtgKJwClf3IiPtO5MwO09C9rolhWm7vKMlvduHR0bDbrkwaeFfbOQWbrdJcETqcy2Y5AX Jk4eL60kFtaJ4vRFqe7a4Swdu5d2NqGoFDoI9OjIw1khVMRFWVKiuGYptwiLgdsNcky77ZJsiXx nL39k5HHj9SxEO7+2fmmookwcgQHqOxFHmwh12R2NOmcj3qEEgx X-Received: by 2002:a05:600c:3e06:b0:49c:fc6c:be1b with SMTP id 5b1f17b1804b1-49cfc6cc0e9mr231534555e9.33.1788870622577; Tue, 08 Sep 2026 05:30:22 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 14:30:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 5/6] build: move $(all-symbols-*) From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Language: en-US 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: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788870623-FDA0C77B-A0ACEED3/0/0 X-purgate-type: clean X-purgate-size: 2927 With the final linking logic now consolidated in scripts/Makefile.link, $(all-symbols-*) also doesn't need setting anymore in (and passing down from) the top level Makefile. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD --- a/xen/Makefile +++ b/xen/Makefile @@ -465,10 +465,6 @@ ALL_OBJS-$(CONFIG_CRYPTO) += crypto/buil ARCH_LIBS-y := ALL_LIBS-y := lib/lib.a -all-symbols-y := -all-symbols-$(CONFIG_LIVEPATCH) += --all-symbols -all-symbols-$(CONFIG_FAST_SYMBOL_LOOKUP) += --sort-by-name - include $(srctree)/arch/$(SRCARCH)/arch.mk # define new variables to avoid the ones defined in Config.mk @@ -622,8 +618,7 @@ $(TARGET): outputmakefile asm-generic FO $(Q)$(MAKE) $(build)=arch/$(SRCARCH) include $(Q)$(MAKE) $(build)=. arch/$(SRCARCH)/include/asm/asm-offsets.h $(Q)$(MAKE) $(build)=. MKRELOC=$(MKRELOC) 'ALL_OBJS=$(ALL_OBJS-y)' \ - 'ALL_LIBS=$(ARCH_LIBS-y) $(ALL_LIBS-y)' \ - 'all_symbols=$(all-symbols-y)' $@ + 'ALL_LIBS=$(ARCH_LIBS-y) $(ALL_LIBS-y)' $@ SUBDIRS = xsm arch common crypto drivers lib test define all_sources --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -183,14 +183,14 @@ ifeq ($(XEN_BUILD_PE),y) $(MKRELOC) $(filter .$(TARGET).efi.%, $^) > $@ .$(TARGET).efi.0s.S: - $(objtree)/tools/symbols $(all_symbols) --empty > $@ + $(objtree)/tools/symbols $(all-symbols-y) --empty > $@ .$(TARGET).efi.1s.S: .$(TARGET).efi.0 .$(TARGET).efi.2s.S: .$(TARGET).efi.1 .$(TARGET).efi.%s.S: $(NM) -pa --format=sysv $< \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ + | $(objtree)/tools/symbols $(all-symbols-y) --sysv --sort \ --source-name=$(TARGET).efi.S \ > $@ --- a/xen/scripts/Makefile.link +++ b/xen/scripts/Makefile.link @@ -3,6 +3,10 @@ # Helper rules for linking xen-syms # ========================================================================== +all-symbols-y := +all-symbols-$(CONFIG_LIVEPATCH) += --all-symbols +all-symbols-$(CONFIG_FAST_SYMBOL_LOOKUP) += --sort-by-name + syms-warn-dup-y := --warn-dup syms-warn-dup-$(CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS) := syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --error-dup @@ -17,7 +21,7 @@ final-image-check-y ?= true $(call cmd,cc_o_S) .$(TARGET)-syms.0.S: - $(objtree)/tools/symbols $(all_symbols) --empty > $@ + $(objtree)/tools/symbols $(all-symbols-y) --empty > $@ .$(TARGET)-syms.1.S: .$(TARGET)-syms.0 .$(TARGET)-syms.2.S: .$(TARGET)-syms.1 @@ -25,7 +29,7 @@ final-image-check-y ?= true .$(TARGET)-syms.%.S: $(NM) -pa --format=sysv $< \ - | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ + | $(objtree)/tools/symbols $(all-symbols-y) --sysv --sort \ $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \ > $@ From xen-devel-bounces@lists.xenproject.org Tue Sep 08 12:30:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 12:30:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411955.1642417 (Exim 4.92) (envelope-from ) id 1x3uyS-0000HR-03; Tue, 08 Sep 2026 12:30:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411955.1642417; Tue, 08 Sep 2026 12:30:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uyR-0000HK-T5; Tue, 08 Sep 2026 12:30:51 +0000 Received: by outflank-mailman (input) for mailman id 1411955; Tue, 08 Sep 2026 12:30:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3uyQ-0000Fk-Nk for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 12:30:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3uyQ-003w3D-43 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:30:50 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9ffffa-bab6-0a2a0a5309dd-0a2a450ca434-0 for ; Tue, 08 Sep 2026 14:30:50 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9ffff9-f479-0a2a450c0019-d155dd30c120-3 for ; Tue, 08 Sep 2026 14:30:50 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-47fe89fb333so2994022f8f.3 for ; Tue, 08 Sep 2026 05:30:50 -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 ffacd0b85a97d-485885c5bbdsm34120922f8f.36.2026.09.08.05.30.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 05:30:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788870649; x=1789475449; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=PlF7Jt2csGAhocWKbAzmDtcyIGA0UXGHP2uf+mocDok=; b=Rukwc760F112/pB7mVr4RlZaZAFSXZT8CCe+RvlGItC+x27hHBrXI+aiMI5BYTE1Ll GFXia76gp2xAPXoXj1kreQG7xn64UnAGGJZLHN/p/YPopClUDV617MRdFlkK6sdZFHB/ 0ry6n2HbzvHyclPhc2gZb1Pe8MnHuw4SfITaneZi+yzkL8CPRbkUtRou71hn921Hl6S+ fNf77PhIqSVnRkPDwDXKsgQxqS6zvHiEyO8ZJN1R8aJ2crn7unf+R/ebO8ki2sooFy84 LjsPOi9laioYsix3/J3gkCpcsf/i0z3Qjuco3A5osdH5kp7va+ptd578rI+pTL7j2GTK 2+qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788870649; x=1789475449; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=PlF7Jt2csGAhocWKbAzmDtcyIGA0UXGHP2uf+mocDok=; b=qKYrqIfnF516mUeZsu8PWtgl3DVwpJp64VvjrbUWNrldvM+ZWeWKMQBbgjLu5ioBck 4aQzKBfFJk/Rp/0JZpIhe9RJ6P9idBG+EtgMsFjz8NgedGrC4z3zafX7tOZg8Ay+zy0e Ex5vfvrtLKpLbyeHLqYZ+4Hu1mR1EpYIws3NttbYSQeIWwv9ToqdPTrVrIo2t0sLSZqT MtEnFGKgJ0AP6qEHkbZiRPlOzMes4x4/NadylptH+lI9ZqcgMSAcZOhfqu6+vGwJzrdy 5xeJX43/UHx0QpROHzvF/b5KFtMKvlMHwSncxZRhnC9DGfPFvFZQrfIHZNyUOWkGGwmw S68w== X-Gm-Message-State: AFuF++mEftARRRPzDIecj1ftVAt232gY+PBWdh4gnr7QD3oQDNowhZdx fPewZEo0Tr4hqdk6VTI8zIcpjZZWM1jbL6zRyfstxKjkoYuhRbEeUbLqQ2bEriR7e7lBJdx9r5j dWungpg== X-Gm-Gg: AYBFou2/uI9NgklcewZTFm5zB18HedkNtb3Ce+bQyeDyICdgyqZmvRnpjxQCOLkIkGM TtqLmjMt8fJwoZfwESwLDn5kdCFoc9F0V725UQuh1lMypzQJKNU78iufE71wvWl92x9SmIOilOt refzURDRG/WPdLHS/is+z4fpk9vo1wId8BbPN10z+simsm3d9l9UjBoZGcspJMeVwdr7D1BAk6R EeTffaDJY6cQ7HfwoJUhXNu2lx0oY2k2VnDhVIwABTpsrA4ywde4fgzfZ87/+BpzDOPRaun4g4w 1kGuguCXyb2owH5u/5OBnukLKWeEbT/tag+7siI7GgSCwHZBImBUJlA2IDYZr3vXiQ5Ug3V9ZXM jntEE1c8Xuf2ZTyqQEP5e8648AJ5DuyTDnjHaCLWm0XkQ6sXlbcvuiivODcysnw3zQlW3mMdiFe 2w/XpcAtJMTFlaQ9ZTC4hE39/AvQV1foTcepkBs6tBFxqOLOcAjxMPm/gNbGdDVizLfUhJWsqd1 eHPc6HazEc/gqrrNvSaXuBIJfgE6eyWOS/H6mc09qt8HKI9MOYj X-Received: by 2002:a05:600c:3e0a:b0:495:6e68:5df2 with SMTP id 5b1f17b1804b1-49cf8267a36mr375734495e9.12.1788870649394; Tue, 08 Sep 2026 05:30:49 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 14:30:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 6/6] build: move $(compare-symbol-tables) From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Language: en-US 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: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788870650-76EDAA5B-43761154/0/0 X-purgate-type: clean X-purgate-size: 1887 With the final linking logic now consolidated in scripts/Makefile.link, $(compare-symbol-tables) also doesn't need setting anymore in Kbuild.include. Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD --- v2: New. --- a/xen/scripts/Kbuild.include +++ b/xen/scripts/Kbuild.include @@ -56,19 +56,6 @@ define filechk fi endef -### -# Compare the symbol tables of two object files. As diff's -I option isn't -# standardized, the name difference of the two object files needs abstracting -# out. -define compare-symbol-tables - ln -f $(1) $(@D)/.cst.$$$$; \ - $(OBJDUMP) -t $(@D)/.cst.$$$$ > $(1).sym; \ - ln -f $(2) $(@D)/.cst.$$$$; \ - $(OBJDUMP) -t $(@D)/.cst.$$$$ > $(2).sym; \ - rm -f $(@D)/.cst.$$$$; \ - diff -u $(1).sym $(2).sym -endef - # as-insn: Check whether assembler supports an instruction. # Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no) as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \ --- a/xen/scripts/Makefile.link +++ b/xen/scripts/Makefile.link @@ -33,6 +33,18 @@ final-image-check-y ?= true $(if $(filter $(LAST_LINKING_PASS),$*), $(syms-warn-dup-y)) \ > $@ +# Compare the symbol tables of two object files. As diff's -I option isn't +# standardized, the name difference of the two object files needs abstracting +# out. +define compare-symbol-tables + ln -f $(1) $(@D)/.cst.$$$$; \ + $(OBJDUMP) -t $(@D)/.cst.$$$$ > $(1).sym; \ + ln -f $(2) $(@D)/.cst.$$$$; \ + $(OBJDUMP) -t $(@D)/.cst.$$$$ > $(2).sym; \ + rm -f $(@D)/.cst.$$$$; \ + diff -u $(1).sym $(2).sym +endef + .$(TARGET)-syms.%: $(objtree)/prelink.o .$(TARGET)-syms.%.o $(obj)/xen.lds $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $(filter %.o,$^) \ $(build_id_linker) --strip-debug -o $@ From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:01:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:01:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411979.1642445 (Exim 4.92) (envelope-from ) id 1x3vRT-0005I5-Ds; Tue, 08 Sep 2026 13:00:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411979.1642445; Tue, 08 Sep 2026 13:00:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vRT-0005Hx-BN; Tue, 08 Sep 2026 13:00:51 +0000 Received: by outflank-mailman (input) for mailman id 1411979; Tue, 08 Sep 2026 13:00:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vRS-0005Hp-Hs for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:00:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3vRR-001i16-4t for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:00:49 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa006fb-2eae-0a2a0a5409dd-0a2a450cddc8-24 for ; Tue, 08 Sep 2026 15:00:48 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa00700-f479-0a2a450c0019-4a7de18c8e6d-3 for ; Tue, 08 Sep 2026 15:00:48 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ce364488dso3924205e9.0 for ; Tue, 08 Sep 2026 06:00:48 -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 ffacd0b85a97d-485883953cfsm30106289f8f.13.2026.09.08.06.00.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 06:00:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788872448; x=1789477248; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=BEQrCqmECj+iaTpwB31qWz+WGIw5mDkclPlRgVgLLu4=; b=GnQW4CzI5CpbVAO2tSXK9v2xhQaq85ThuzDBIsehuatbWHlcond2pbW7UlgYFMVzWU hZtVIGkEBxPyxg1mtyRSt7sfe8us+cdC5ksPaLLa6/2eHJ0AwEzOmqD605PQ3iRS30Sg J6G294Z0DTAMiZ/Xx5j0nS8rf20vYexfWzIa/OcHWGsl9wFRpSz726zbupuU73uW4tnb O+U9h1+jD48G1chceuvt8t2+QaP1KX0Gy6uCi0Xrp6o/PUPt2LDtr/bnD8fUCSK1Czrd NnZi6FDtOZuIAm6pLwTq7FnO0lNGkmRjqEBFciQV/DI6Cef+FQz1K6mnxAh4qwU9okZd o/gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788872448; x=1789477248; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BEQrCqmECj+iaTpwB31qWz+WGIw5mDkclPlRgVgLLu4=; b=RFuVTleRPz88aYzrzveiAnl1E/3cqFFK4sI6OpeKTMkWS3xYhcmB8Q3W0J2Ix90kyM EzOVwZ16gq0jViP9DyMpXDcz4sI6c4Z+AvHrTjlytf/yUj6RxbONfN8SHYyIeo0qGmto WwFeEDrNp0WwGwDgKAmxDWE2D0F98lZ76UJDPdLGsUEgtfg8QGR2T62wS/NoRtTMmJni KpweuP24InE2/GjD5jR8/8klwKD8/YuuBeH9YwGSfECeirMc2cRbxowkIu45JvgpYBXK YoiLfxDdghU27I89j/np0cqLNOKusYEzGkKgY5lhoTzO6TZfbGxErlPZ/vXAL+NtoxV8 +6JA== X-Gm-Message-State: AFuF++m8XIRPgZ4CtYbmQ621qneTDg4BRu9wWZ9eSAiEFLHuumvVGZx2 uzymtzHZEij/ei6/E0JpLU4/l3b/F+23Jf9YDzz673lKNsGefHlZBf5ttdqIZywAFWkLo+V/PmI SQ4wNEw== X-Gm-Gg: AYBFou39yeFHeMK8y08u6XJS/VxUEIDQ39ISThtSVJAfAFSlIQ6PJWUXFb2a7RYWYZE JAK4+zjZ9BpsHKuEwptfxrgcljwK/VSfYaOb0Ct3ClTAQfduEnPPMDmrPFkEJN9z9Qrgk/KRgOd XejA+jT1bmDVfUbNelvFBz3f3cWmsIMfQU0N86AwMggXYOabNQ5P11jJ1LfBENgU0SQ04Whqhvy CfJVllQTBNFhQYcTDzzBrFVHcMDtAxyE6/8zzlY8nWe74qe9exYOsyc6pyt6/crBljPYZHSZ499 aFf+Eal1xcVm1RHWcd5oqaQcsoOtOl6pv8QqeUK3kz8ZduiJmR+5Sr6/U+ZgjnaN5/l/99kwkNy wU0LYTLKRcC1reKTUaSGF5oNAb+E5eyfpUqBykp9MHK1v6+V6NdA7YKvnZtja2/3+f4vyqJMsT7 7df95DFhFBvFwI2Ul0T6yviruLBKll9tVOk+5X6OjBz63b29Zd87l/5sokyNbQe/oVTokKB8XQi 9E5UXs+SrIWTOEqwVOgYBySRRB2TgFvu04M8NfumzeUetfIzFvyo7AOMovRTsY= X-Received: by 2002:a05:600c:4752:b0:499:59fd:dbfc with SMTP id 5b1f17b1804b1-49d175439dbmr72508055e9.1.1788872448093; Tue, 08 Sep 2026 06:00:48 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 15:00:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH 0/6] x86: pass-through / {,v}PCI locking 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788872448-50B3DA5B-A88921A0/0/0 X-purgate-type: clean X-purgate-size: 486 Now that XSA-509 went out, here's what actually caused the issue to be noticed, plus some follow-on cleanup. 1: x86/pass-through: defer event unlock in pt_irq_create_bind() 2: x86/pass-through: no locking around pt_irq_{create,destroy}_bind() 3: x86/vPCI: tighten locking assertions 4: vPCI: drop bogus locking assertion 5: x86/pass-through: use simpler locking primitives in pt_irq_{create,destroy}_bind() 6: x86/HVM: drop vector parameter from .pi_update_irte() hook Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:01:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:01:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411983.1642456 (Exim 4.92) (envelope-from ) id 1x3vS7-0005fZ-MB; Tue, 08 Sep 2026 13:01:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411983.1642456; Tue, 08 Sep 2026 13:01:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vS7-0005fS-Ie; Tue, 08 Sep 2026 13:01:31 +0000 Received: by outflank-mailman (input) for mailman id 1411983; Tue, 08 Sep 2026 13:01:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vS6-0005fK-JV for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:01:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3vS6-00Btv0-0D for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:01:30 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa00724-8faa-0a2a0a5109dd-0a2a450ae664-26 for ; Tue, 08 Sep 2026 15:01:29 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa00729-f2d2-0a2a450a0019-d155dd2be8da-3 for ; Tue, 08 Sep 2026 15:01:29 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-482e4998d28so3686925f8f.2 for ; Tue, 08 Sep 2026 06:01:29 -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 ffacd0b85a97d-485883a9b49sm30584345f8f.17.2026.09.08.06.01.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 06:01:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788872489; x=1789477289; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=wCtbma6yni6NMPug+FRpjh+vc4wJezGbeyKqAGWmcyU=; b=NqGiAJ3K27SAv1I8ywaqWfqMw0PM5zWq7t3hCRS5WEH1MYW8mZo1Tm3OzNgMuQJUu6 Ww4A7d6v2NuoPKRHXZxRmEjS2t+rpIbmDSewsiM5ka2eTkQun08bewwymYNMuvPFr2PX SPJh0L1r2+wKxCo5qLzHTAB1LLuHOPOi7Vrj5egOcPe451KuUmM5dTv7QkxemZ24Inys tq3UNLQwegQSqXXUCaCrYhMZP4s9IQPPRTETEmXpUxM7FCn9ajuwRZAb/bjEf+cTJ+cD tlk+OEg/9VUj0sLPUNZnffrUEbEPwf/t4DLqtenBosidl4Qltctvp0ggqWftrd7Fk43/ 1K4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788872489; x=1789477289; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=wCtbma6yni6NMPug+FRpjh+vc4wJezGbeyKqAGWmcyU=; b=n4MUSUDq/1wRtVav25HBsSS/xCtSJ/SbDNNBNEnG2WbtgaqlFcQAum9njUERyERwvw WD90uJxBaryklJzwnRVSALi8ONUAXZ8zHdtL8f1SLhFrsFPwlu28R8lQvtHlmQQNrgXx 826pr9nqQys8eaWRPA+FfpfMNXg+Lc/Gp/HWtelW/++keg9+1nWGzjJu47/OytGLg06J Qg5Nrh+3SsFemP8cReWVv4KjvifmzhWl91hyBAbTM883GRWHyLXiidbg8+MosLU2R9xW RyCXVmjLBptaVH+xZa0AQyOkYCywV58VdN8c72jjNm3KdH+nuu4by7n/KE12Gk+qlKBG wIsw== X-Gm-Message-State: AFuF++luu+mKhsnF8M2vtNekcPwUTMRqgI5CxKUYj2fqwxOTdilxziEj /VMTsZQAG70us1byARUJL+by6bhYmu0gMvMQJ8natKxpmwMf9mR0uG28exxmJYgFT/1J8h/axY0 e7uNRyg== X-Gm-Gg: AYBFou2C6vQt5ebHlL4R2iU42rercu4OxnryG8PElwW1Z2UoNPL8is4Yjl+bazFyhWE 1pXbCHLqjmhtXGLAB5qOlX5RMu+rKGkvvBrdfLAxH7kAc4M8MS8GpuORiuasshP+9AsG0l6tFFq xCt0TQeOh2Jbm+f0+rixm+Bcpocl27yXjTuoLkS2CXOaHNhQYtvS2zEMb83gvQ2DDhYDBifNiDQ Pu/xnIZuFgPOHSTi/XgFZpIOqsnkcuYnDsmK+e/zBgIoq1yLxT/FijmSsySPY3lOAvLTJ7wKLnf JeACdaNW/HzWkRJTY0h11OqNmp/hGbqpdMLU37bgLEV2jr1qWe2wUa6/TO6JM1ZtkmRxbB7iHBl l0J2IN8VSCarOjtP7EWq92OnsVTGOLbXrdJfoB5T2Ws23UXVlsNOTxPrKBWnzq3uxZ8/FOzjnx/ bsrJ93K7FK91R/Q76u5ACMNBIPa6ICuMnLVoHBHobVMu6P9ETUCBw+NvVHw6y1VjJkqgvD2r0ey nwQP7TBcGAcBKeDCbthH2e9vFjjYKZozLKk5yz9NBf0rSedJnmjmQ== X-Received: by 2002:a05:6000:2381:b0:485:8c16:a353 with SMTP id ffacd0b85a97d-4858c16a639mr25518802f8f.43.1788872489153; Tue, 08 Sep 2026 06:01:29 -0700 (PDT) Message-ID: <7618c144-2f4a-483c-b078-0d9100b9f251@suse.com> Date: Tue, 8 Sep 2026 15:01:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/6] x86/pass-through: defer event unlock in pt_irq_create_bind() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US 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 X-purgate-ID: tlsNG-4011c0/1788872489-50CCBCFC-FDC2351B/0/0 X-purgate-type: clean X-purgate-size: 3280 The radix tree holding struct pirq * as obtained by pirq_get_info() is protected by the domain's event lock. The result ("info") and the derived "pirq_dpci" therefore may not be de-referenced past the dropping of that lock. Moving the unlock down is safe, but perhaps not obviously so: - vector_hashing_dest() does a memory allocation, but core event channel code does so too while holding the lock; the call to vlapic_match_dest() doesn't involve any further locking, - hvm_migrate_pirq() operates on the corresponding IRQ descriptor, where obtaining of its lock is of course fine (those locks always nest inside the event lock), - {hvm,vmx}_pi_update_irte() are very similar to hvm_migrate_pirq() locking-wise, - the locking around guest_mask_msi_irq() is the same as in the earlier two bullet points. As long as the PCI-devs lock is held around both pt_irq_{create,destroy}_bind(), this is only a latent issue. Fixes: 35a1caf8b6b5 ("pass-through: update IRTE according to guest interrupt config changes") Fixes: 1066331913c9 ("passthrough: don't migrate pirq when it is delivered through VT-d PI") Fixes: 782cf8ba4678 ("pass-through: adjust pIRQ migration") Signed-off-by: Jan Beulich --- The last two unlocks could be done a little more efficiently, but then also in a little less straightforward a way: if ( pt_irq_bind->u.msi.gflags & XEN_DOMCTL_VMSI_X86_UNMASKED ) { unsigned long flags; struct irq_desc *desc = pirq_spin_lock_irq_desc(info, &flags); write_unlock(&d->event_lock); if ( !desc ) { pt_irq_destroy_bind(d, pt_irq_bind); return -EINVAL; } guest_mask_msi_irq(desc, false); spin_unlock_irqrestore(&desc->lock, flags); } else write_unlock(&d->event_lock); break; Seeing that the IRQ descriptor lock is taken up to three times in a row, I wonder whether we shouldn't consolidate this (by obtaining desc once and then passing it into hvm_migrate_pirq() (or a suitable new sibling thereof) and hvm_pi_update_irte()). --- a/xen/drivers/passthrough/x86/hvm.c +++ b/xen/drivers/passthrough/x86/hvm.c @@ -371,7 +371,6 @@ int pt_irq_create_bind( dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode); pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id; - write_unlock(&d->event_lock); pirq_dpci->gmsi.posted = false; vcpu = (dest_vcpu_id >= 0) ? d->vcpu[dest_vcpu_id] : NULL; @@ -393,6 +392,7 @@ int pt_irq_create_bind( if ( rc ) { + write_unlock(&d->event_lock); pt_irq_destroy_bind(d, pt_irq_bind); return rc; } @@ -405,6 +405,7 @@ int pt_irq_create_bind( if ( !desc ) { + write_unlock(&d->event_lock); pt_irq_destroy_bind(d, pt_irq_bind); return -EINVAL; } @@ -413,6 +414,7 @@ int pt_irq_create_bind( spin_unlock_irqrestore(&desc->lock, flags); } + write_unlock(&d->event_lock); break; } From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:01:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:01:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411986.1642463 (Exim 4.92) (envelope-from ) id 1x3vSW-000627-08; Tue, 08 Sep 2026 13:01:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411986.1642463; Tue, 08 Sep 2026 13:01:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vSV-000620-Tj; Tue, 08 Sep 2026 13:01:55 +0000 Received: by outflank-mailman (input) for mailman id 1411986; Tue, 08 Sep 2026 13:01:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vSU-00061b-Eq for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:01:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3vST-00DNLB-Rr for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:01:53 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa00737-bab6-0a2a0a5309dd-0a2a450be5a4-12 for ; Tue, 08 Sep 2026 15:01:53 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa00741-b7e8-0a2a450b0019-d155dd2cd582-3 for ; Tue, 08 Sep 2026 15:01:53 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-482f2ee53e7so3444471f8f.1 for ; Tue, 08 Sep 2026 06:01:53 -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 ffacd0b85a97d-485883acd33sm35297675f8f.18.2026.09.08.06.01.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 06:01:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788872513; x=1789477313; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=lvz8MuJ79mtzbquJ0FCpYwwGJ4AQQZ5W74E+80dtosw=; b=XZ40PVwrt54TAzK9r8GF2EStGV0rkTsXvIChD3Ajv9PJLYxb/lornSZxGcES828LE+ 1yUmi6RntQ87WEXoC17bUQTngweYGKMN8gEmmzagSrO1TUoGkVBCIEUMGXQ0nS0v8k8M Ucb7k7UR9OveY4qFc8T0YBu8lKCVD3dvjN67dbSxbJfhp9LbWs0enOKZz97qH727bk/I ZA0bAcSJtC/vNfAbeGdFvGMJV8pv1v4UQx+zzRPWyQhI9zcRyhn3/AmAwVhgCgEpJo7k 7Q/ehlqRKuzklyJqq3bf1PnbmxWvTtNsSmXT4jtWhjAcKO/H2wxG0OsLgY7r0nfPdugy jESA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788872513; x=1789477313; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=lvz8MuJ79mtzbquJ0FCpYwwGJ4AQQZ5W74E+80dtosw=; b=TFjRQ4yUjbvibogYgghShOetjsPBIO2e8J4ZH2GMc+2y8ML9gFzGEOUuv7oi43gLiT 5CJChw8vs+H27aBgFC/wfj0mDWf8cSWxjY6BQUjQx26Xur+JXmbJBkqIoprUjbY0hyMV rZ/kFMF39BTKd6MQUVrORVc7k+bTtu1lOq9YvBTrltfUCoWAQFLpbrQzSMhDIimU2pCj 6olawee1wYRjA6qe3rxOSd6Ptv2VF8cQDgwezhmv7eZW8WaOD+2+ZsfTQ24yFouzLqzr WlS9bbdgPwIenwLZp1kw+YNGS4YTm5lxMCUJSVtXs6muxDkE9XrXuVCWKv0PKbwg6d50 a1Wg== X-Gm-Message-State: AFuF++m/fy2ZEjLx7PXFlorLS34Ixnk6YU5Mqt4gkJL5SoNJETONDUzz P0++OuNWynezLfd1Sp6AtFEGVrIQ12mHxiWPaaY4ki5JGz7X6+fvGXIhcF0+snaUcc3Ol4M7k5D JfLTSew== X-Gm-Gg: AYBFou2sTmGfnd9bD7X3Jc8y1ZFHJF7Lwy/XT+XgrFWWzt/V3DOOUQ6wwiBMG0VGeeT IdZ/UbC7H953Ejlkm6MVn5gyBuwNMtFUJye7zOlxBScGQJ51fS97+LVjvQcKuYtfbKEM3v4q9V2 bmzNFlUNM/zvE/t5uyyvQFO5G7uL/gD7ovnZe8MLFSE4BHUc1ENPsUGM+uRp2hKsRMf98/b6AKs +zy6UUm1LHfruM5ycUtUKqOgFBy9FRt+G94kQMp1EU/O8+jOfUBXz5PpR6eimD3yNJChsgk/VRX tWzsLe/tycO6JwHQO0DwlZIgwUnBu8gmK2fz+MgVACGE9Ihgc60qXynvtuvSmDxkpZAxyhAlIQD KcQL01MPdJlJyqcQXXqjrfW3s2LFROxhDPJIBCIoJ1bybq7rr+HV8CAsCIVlqh2Un/rD0W08sFV GtPQrDQl+hIubepbJQhJAcEYwuhAJXWCTqf26wzf+4rFTIkBb800XWZmuCCd8Yb6gFcD7sHapIq OAevWEa2LrWefejnYJAP3zgFrpcuJrQ5gLh7M/zVaUPuvMeNHuH X-Received: by 2002:adf:fd81:0:b0:482:fbb0:a262 with SMTP id ffacd0b85a97d-485872abe78mr23925428f8f.20.1788872513184; Tue, 08 Sep 2026 06:01:53 -0700 (PDT) Message-ID: <92b0a72a-44df-424f-acbe-58d7167f1c4d@suse.com> Date: Tue, 8 Sep 2026 15:01:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/6] x86/pass-through: no locking around pt_irq_{create,destroy}_bind() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter References: Content-Language: en-US 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 X-purgate-ID: tlsNG-42698a/1788872513-196C29EA-04DCD6D1/0/0 X-purgate-type: clean X-purgate-size: 1703 The questionable use of pcidevs_lock() there was discussed more than once. It really is pointless: The functions synchronize primarily via the per- domain event lock. They also may already be called with the global PCI devices lock not held: See hvm/vmsi.c:vpci_msi_update(), hvm/vmsi.c:vpci_msi_arch_update(), and hvm/vmsi.c:vpci_msi_disable(). Signed-off-by: Jan Beulich --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -636,10 +636,7 @@ long arch_do_domctl( ret = -EPERM; else if ( is_iommu_enabled(d) ) { - pcidevs_lock(); ret = pt_irq_create_bind(d, bind); - pcidevs_unlock(); - if ( ret < 0 ) printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for %pd\n", ret, d); @@ -670,10 +667,7 @@ long arch_do_domctl( ret = -EPERM; else if ( is_iommu_enabled(d) ) { - pcidevs_lock(); ret = pt_irq_destroy_bind(d, bind); - pcidevs_unlock(); - if ( ret < 0 ) printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for %pd\n", ret, d); --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -197,7 +197,6 @@ static int vioapic_hwdom_map_gsi(unsigne return ret; } - pcidevs_lock(); ret = pt_irq_create_bind(currd, &pt_irq_bind); if ( ret ) { @@ -207,7 +206,6 @@ static int vioapic_hwdom_map_gsi(unsigne unmap_domain_pirq(currd, pirq); write_unlock(&currd->event_lock); } - pcidevs_unlock(); return ret; } From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:02:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:02:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1411995.1642472 (Exim 4.92) (envelope-from ) id 1x3vSx-0006VR-70; Tue, 08 Sep 2026 13:02:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1411995.1642472; Tue, 08 Sep 2026 13:02:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vSx-0006VK-4L; Tue, 08 Sep 2026 13:02:23 +0000 Received: by outflank-mailman (input) for mailman id 1411995; Tue, 08 Sep 2026 13:02:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vSv-0006V6-Ok for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:02:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3vSv-00BuDp-5C for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:02:21 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa00759-8faa-0a2a0a5109dd-0a2a4508a30e-26 for ; Tue, 08 Sep 2026 15:02:21 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0075c-f659-0a2a45080019-4a7de18c96d2-3 for ; Tue, 08 Sep 2026 15:02:21 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd6185db7so6626425e9.1 for ; Tue, 08 Sep 2026 06:02:20 -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-49ce5952560sm435083775e9.3.2026.09.08.06.02.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 06:02:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788872540; x=1789477340; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=o0d1D4rqSgyoha+rBAysFKG64mCQkEkUN/Iu3QpC/L0=; b=cohtIV/Ai114lus60zViohoPaSkSFgfaUoZuTmSpb3/wJYTg9EKvOYyeZ0Hb4xu2Ux v595O1UDzYf0Ak5wKydWxYwr4AtpbQQGM72r527YgKJcR1Vr6LN6DHtKM6mmJrAMUoYK UsmN88dFuFW2WUlbL5GsBW8IFpwGw44JwCefm263d0MoqzGIhAmn16PesALzLjSzQbHv jdxCTFcUQQQvz/scA8QCpxAn6i43K6Nqit/pVcEv4SeUQMMgNaTD56ONh3Lp9ZY/uszl S+XxPNJYaLGmcnk0tDSEsXq9wQUN9YN5YXyo+lOzmNRJ08tHzxBm9z0utYmKSA4LDyKx qWPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788872540; x=1789477340; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=o0d1D4rqSgyoha+rBAysFKG64mCQkEkUN/Iu3QpC/L0=; b=qjsobDUd56ztLbo3/pEFwxX9AVf/2CIu4OW2FkShgyO+n68ttxkS6S9CpNQNINrkEH XCt7XXJht2xOWwvGzyCvqejPJ+bMa8JfrX1ffaAs1NAcdIc/UMPbdaMu5OJh5ngK1X9j Sh5aZLyIm0gFnJt4sRmco9/6P/pDWoW8MbQmaF9j6n+jkfYddD/IKQ0FykZszewDU59u aWiME7Nj3TAf5ql7znr6WgMCEZ7hbYQszcsCFTSlgFfVnQK4pSwiVC4HC+2UbmSXnnz8 F8iKd8g+zHbt05eRh+ZgLIH8gbI6SIXsErGvLprWFApYzJvWL1Z/n5D5j1Ug1fMSid8x 3r4g== X-Gm-Message-State: AFuF++m4BXjlUx5YvQXTY3TY6nY6Ts2OtLVXKXjjp4+S3VlU5FG/vquC R8kzR1ojxRJRs97b2vJd31EIY7PqqjGgt2fNxIe8J5mOy1mvDr+w4Oatdh3i10gyaD11yglzswg ijX83IQ== X-Gm-Gg: AYBFou3C3TMW/AM9tYecKW8SdIlwD8ASrcjMBnIbfEDxQ9gNUMAf8sc6n+zEq15GUNZ wB1nLd430GCbM4XKVNb5I6Npf8CQ6jOQ0q5neGd2qGap671AtcXuefL/09OYCsG/sODqmdCzJ2i B+WYGuL/oYHUliNEghILI9iP0jTreg8LHZortauFlGkOmPiLsX2zeRLeGNidkRY7/8pTuE2OBep GuN8rvlcnJS9lXREJnOLxPjId2NHebsf63sy9M6tEZBKfF6Dn6f3sfAfcVBBaAtXGw1chdyWicL abBHKLFICVht92BusBCz0/e6x/4m9mcmTT85SB/f+cO+hRWGbfxknr3NBaWLEoE/6AUxBcySPYa EbFXMXp+v6Eldfgn5L/QOAdl5WPUPjo+lmnR/zLM0T1kptMrsLheIkVuPrrYx58Hs/o1xIMrcID kEJPDEkpbyHsc5irq5JxlSsPnZ2wYb4OYdkCyh9VUxaodyVhJfRdhR9hkr/lfV+EzjdUJDWq55U G/Eu+2ETuoN2aB4HsHrrrQZ4aOkBMrV/99+5Nd8+RUh30bs8IZN X-Received: by 2002:a05:600c:1c21:b0:49d:1e79:35d6 with SMTP id 5b1f17b1804b1-49d1e79368dmr199645e9.14.1788872540374; Tue, 08 Sep 2026 06:02:20 -0700 (PDT) Message-ID: <1b8c4276-0031-4a19-9663-b63799f5cf81@suse.com> Date: Tue, 8 Sep 2026 15:02:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 3/6] x86/vPCI: tighten locking assertions From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US 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 X-purgate-ID: tlsNG-c1860d/1788872541-CD74B87B-912D8256/0/0 X-purgate-type: clean X-purgate-size: 2867 Already when they were introduced, they seemed overly lax. In particular anything invoked solely from vpci_{read,write}() can check that the per- domain PCI r/w lock is held. There's no need to permit the alternative of holding the global PCI devices lock. vpci_msi_arch_update()'s sole call site is update_msi(), which in turn is solely called from write handling hooks. vpci_msi_update(), besides being called from vpci_msi_arch_update() (see above), has two further call sites: - vpci_msi_arch_enable(), called upon control register writes, - vpci_msix_arch_enable_entry(), called solely from update_entry(), which in turn is again called upon control register writes, plus from msix_write(), which read-locks the domain's PCI lock. Both arch_enable functions therefore can also have their assertions adjusted. vpci_msi_disable() is called from - vpci_msi_arch_disable(), called upon control register writes, - vpci_msix_arch_enable_entry(), covered above, - vpci_msix_arch_disable_entry(), called update_entry() (see above) and upon control register writes. Signed-off-by: Jan Beulich --- With this perhaps the comment near the top of vpci_msix_arch_print() might better go away. Thoughts? --- a/xen/arch/x86/hvm/vmsi.c +++ b/xen/arch/x86/hvm/vmsi.c @@ -837,7 +837,7 @@ static int vpci_msi_update(const struct { unsigned int i; - ASSERT_PDEV_LIST_IS_READ_LOCKED(pdev->domain); + ASSERT(rw_is_locked(&pdev->domain->pci_lock)); if ( (address & MSI_ADDR_BASE_MASK) != MSI_ADDR_HEADER ) { @@ -878,7 +878,7 @@ void vpci_msi_arch_update(struct vpci_ms int rc; ASSERT(msi->arch.pirq != INVALID_PIRQ); - ASSERT_PDEV_LIST_IS_READ_LOCKED(pdev->domain); + ASSERT(rw_is_locked(&pdev->domain->pci_lock)); for ( i = 0; i < msi->vectors && msi->arch.bound; i++ ) { @@ -930,7 +930,8 @@ int vpci_msi_arch_enable(struct vpci_msi int rc; ASSERT(msi->arch.pirq == INVALID_PIRQ); - ASSERT_PDEV_LIST_IS_READ_LOCKED(pdev->domain); + ASSERT(rw_is_locked(&pdev->domain->pci_lock)); + rc = vpci_msi_enable(pdev, vectors, 0); if ( rc < 0 ) return rc; @@ -948,7 +949,7 @@ static void vpci_msi_disable(const struc unsigned int i; ASSERT(pirq != INVALID_PIRQ); - ASSERT_PDEV_LIST_IS_READ_LOCKED(pdev->domain); + ASSERT(rw_is_locked(&pdev->domain->pci_lock)); for ( i = 0; i < nr && bound; i++ ) { @@ -1004,7 +1005,8 @@ int vpci_msix_arch_enable_entry(struct v int rc; ASSERT(entry->arch.pirq == INVALID_PIRQ); - ASSERT_PDEV_LIST_IS_READ_LOCKED(pdev->domain); + ASSERT(rw_is_locked(&pdev->domain->pci_lock)); + rc = vpci_msi_enable(pdev, vmsix_entry_nr(pdev->vpci->msix, entry), table_base); if ( rc < 0 ) From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:03:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:03:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412010.1642482 (Exim 4.92) (envelope-from ) id 1x3vTu-0007CS-Et; Tue, 08 Sep 2026 13:03:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412010.1642482; Tue, 08 Sep 2026 13:03:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vTu-0007CL-CG; Tue, 08 Sep 2026 13:03:22 +0000 Received: by outflank-mailman (input) for mailman id 1412010; Tue, 08 Sep 2026 13:03:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vTs-0007CD-Ou for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:03:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3vTs-004ZPd-55 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:03:20 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa00793-8faa-0a2a0a5109dd-0a2a4503a44e-18 for ; Tue, 08 Sep 2026 15:03:20 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa00797-fae8-0a2a45030019-d155dd2dddc9-3 for ; Tue, 08 Sep 2026 15:03:20 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-482f9309813so4256037f8f.1 for ; Tue, 08 Sep 2026 06:03:20 -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-49cee6158e9sm478335795e9.12.2026.09.08.06.03.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 06:03:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788872599; x=1789477399; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=UD/LJtaYXoAHqAilG4ijFKHbuTzxrL9p3CeWMQG+5VI=; b=MXu0T5l5CqFEdlbnSYrD/iWXpHImoYVJGEEobPOxmsTvzGYhVv7lxq9nPuWfVrW2Q3 DyPUgVFigt2KC/Gv+vNfV/vh43VEEPKcdmn5ixVsU12P76wVbRjAHcRWhvhhAfscm0AS QSk1dGYs6pgvRlFtZb5oDLNABqF2hEyOKSPRkS1hSRBZhdbbwUI7KvQFto1veY2Ipdlq d10la64P+DeJRYC6svT8NdPTlpI+jox7k9fMiirDlcahbyEDW054beSfNelE2JEzN8jm sGxFdtoLeL8ObWKBY1Wm/65J+OW93RSaS50GYve5JdAEhyjXv+DA7W1JyJ081z91Q/PW XAQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788872599; x=1789477399; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=UD/LJtaYXoAHqAilG4ijFKHbuTzxrL9p3CeWMQG+5VI=; b=ZtrLH27oo8g8mG5ey/ejJyetxdxXAbioSn4ExOSvDLsONgSm7OAh1BGIwalLvtMVnF 9SWcxbj9rjpGZgKqUC3gDPyT7QzAiRJF1fAAgNwgfKHYAAoJK7KhI0zfgIbP4DZzDZ8U dOJHEkmR2o/KMbqArs6m46gYnGRCqVQWAAEuS92Ho7755cF2TEgw425CPmxVtt3sFyyu +T0v00RasLBLuKXFHjbgKB6Xqsc5Vp+Qo0Hakx9RvO7RAu1sRdha2wxvdj1xmOFuLnRR /pdow2iUvXWne3efpnyAdiUk/JiTllW/V0MFrNoeh3WagQqvGCfJnCIQojjP6rGwlf2A QFyQ== X-Gm-Message-State: AFuF++le6KnXyHviL4VO7ZytQzfmAQphAtwwxyITYydcsfsy51UceghS m9So/5ckRR0wdo1VUUbr5TTRm2GS1gwJiU5PxTaGDrBbGzhpNwj2DTT7JKcvTj6gsse7k0hDjn3 MD8U9dQ== X-Gm-Gg: AYBFou2MEZV3QH5KLpyAOKXxER7CnqmlNL8Y8fvoeVuGHU2k/Yk/gDgjFkKlBtndN1c hX24r1vmhouNWhBCYsJR3Qt5DIEaAnae9BTtHoX2ItU1nWEtjqqMEwEBlBtxKwAmz51w+Btfcvx jJPANSoEXtk2DJGfPu0qlUcwhQsjvNgJOe/tTDpcyWXA7lvcfVm9wUplMxqADSSCcov8wzXdV8i SycrgUyz8RxTl80x3a7tgWJCpiZj7+XbTEoERJd9Ey6NvaQzbmhFcPQAjB0LK9Y+vylfgyT5eJr b2EtvW6hMSDQSm0q7XAratM/gg3/3MtW1Fxie38X23S93WaEFDQZEDlusKgqV/Hg+XQCYWpXu+p R7WQkjE075Aj+kspbtiOW9lMuq2NHKGTp5I2u38A+Y2ywC8faeO3Vo6PS0unY7R6G7TZboSRVIz 6J6M6Im6bvQ08ZHRRPP+Y+oL6Qc1AOQiXYVkdvEvaSRmB8Viwfb5KOFexhqnQT36EsuviATF6zD A5DW7XddrkFlUjF0dHQPClTCeSTyntMUKgJZmoWin+07g3felH1 X-Received: by 2002:a05:600c:3551:b0:49d:16df:8521 with SMTP id 5b1f17b1804b1-49d16df85a8mr77640395e9.4.1788872598900; Tue, 08 Sep 2026 06:03:18 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 15:03:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/6] vPCI: drop bogus locking assertion From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: Content-Language: en-US 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 X-purgate-ID: tlsNG-33051d/1788872600-77EC24E9-83652250/0/0 X-purgate-type: clean X-purgate-size: 647 msix_find() is a local helper, with all callers explicitly acquiring the per-domain PCI r/w lock. The checking, which should never have included the alternative of holding the global PCI devices lock, therefore is pretty much pointless. Signed-off-by: Jan Beulich --- a/xen/drivers/vpci/msix.c +++ b/xen/drivers/vpci/msix.c @@ -158,8 +158,6 @@ static struct vpci_msix *msix_find(const { struct vpci_msix *msix; - ASSERT_PDEV_LIST_IS_READ_LOCKED(d); - list_for_each_entry ( msix, &d->arch.hvm.msix_tables, next ) { const struct vpci_bar *bars = msix->pdev->vpci->header.bars; From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:03:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:03:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412012.1642491 (Exim 4.92) (envelope-from ) id 1x3vUM-0007Wt-MJ; Tue, 08 Sep 2026 13:03:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412012.1642491; Tue, 08 Sep 2026 13:03:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vUM-0007Wj-Io; Tue, 08 Sep 2026 13:03:50 +0000 Received: by outflank-mailman (input) for mailman id 1412012; Tue, 08 Sep 2026 13:03:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vUK-0007VN-Aw for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:03:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3vUJ-00HE7L-Nv for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:03:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa007a4-bab6-0a2a0a5309dd-0a2a4504da4c-48 for ; Tue, 08 Sep 2026 15:03:47 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa007b3-b57f-0a2a45040019-d155802bdde3-3 for ; Tue, 08 Sep 2026 15:03:47 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-499ac87c92bso49770895e9.1 for ; Tue, 08 Sep 2026 06:03:47 -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-49d1e728677sm784515e9.2.2026.09.08.06.03.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 06:03:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788872627; x=1789477427; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=+vtrY7KzlKFzHbPTxxbP/vZcWl/f7JuDpE3t3EALSeM=; b=N/hmohWgq3L7vOHbCEUZ85XQ7SpR/NJE8N48YnEHUdfivIDNPJwUCnFE20n4JBFMcV wrQYzD4Txkt6mJSIEL8LAq5A2MMMMoVz+4TgMO5HTH8H1P8tkMrW+ke8UdZztvXfh8TE gAFn7Y2FR4A+K8b1Z2eDRukR/t4Mu6SXGkJG+xbpPZ9pW/wHwcOIX/MRD7WSaNc+cEIb PX55hbYbu+T/sWQv7NCzabw3z0/3h9o1deOTttiphzVghpaEDgbfcK3en4PIXIn8h2o3 uigX4csz4oQ1czrXlsx4ZAtZVM7QHn3Mtlcim6YAdGWvf91zZWDOUNUlFKEng4+wSoXm t9WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788872627; x=1789477427; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=+vtrY7KzlKFzHbPTxxbP/vZcWl/f7JuDpE3t3EALSeM=; b=seEZbXbGVQNlkGSGysNSpko0QFam1S1nsp3hmo1YXL4+H0cjguIvrlx8hR8o8gDZbb 1sIQlyJavD4uDKkNLlNA6NBApk7HhWki1iZX68FIJbPKAGmnjZpARONnWSFSG/LJknxE HmxEHWt8Vzye3U9hg6fGszEJ87k6dB4bWvhgdM1bxBX8359t9E0+zjjvcr1KIrRs3TYa 1nc/+oqikS3bq4yK3nm1h7DZOtOKKz7UfE3ndEHz59DL9VWFFXomFaBjABoEBS5x1XJ6 Dke3AWLRCt2/oKPaOtZNNSWEGOOZMLPGUtUBi0SmZjCYt10cRwyZJFELM677mFhhKZIL OoHw== X-Gm-Message-State: AFuF++lLndc3M/PqRj3ZXk2q3PcA3I7vhVtAEqpQr1f7bydifUyo4bA0 +2Q7krLs/WcOaIJsaGHr91F2VSoZTxe2NXvG3mgB8/yCZ0finG7gOF+fsttXyLePfs8CjMA0Syw EzMuVRw== X-Gm-Gg: AYBFou0qk2Q9AT7nj8ZQ7azhV0zAp8uppXJJoAJTjgwIulZaSczluGkWW8sqTTgXr2z 0Qn2gA2h1xtuuRN+AIi/tY7W2MsZD7wzTvWgINLhDnMqx764N3AXHGnuAYP9Epc8p4GnzmMEzSs UH/aZ2rhpHpcwEHzH6f0GAn+L/37EafDH7NS4fzFAfmpBJoHs1YP5TJiUxurISBI7oYHsaGPZi3 EvN7Rkl7n70cYEsG1eoBfdlxw6q3o3okq4LLK0HvAotddbjWpQc+UlQvSJdizl3fZCcAIi8XoOl vufuknsa2B/G5vgmDLA7oSUan9IXBQKkODYOlYqrEnWYok6p7rg6G4HHVMO8+rNvggzf6hZXVZ9 5xjm8kmvZVyp9mq6Alo8YouwUx/JKpGyG8TrNKyqsaA+b11dhrtn1t3arErIpE+cWhp1dflrRSG wLQ2fugCpCo5xDryIdA7gil5UtCsU4a5k1tZEjo4f7y8/Jw4PeVBFZTmq5LIcxRorYXnSexS8mj 6RPxv9hd/xx4CcvZSrbqgb4czDAZyA1d2YL71lSE/XncpN5o79G X-Received: by 2002:a05:600c:34c9:b0:49c:f729:d757 with SMTP id 5b1f17b1804b1-49cf824f757mr282660295e9.11.1788872627030; Tue, 08 Sep 2026 06:03:47 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 15:03:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 5/6] x86/pass-through: use simpler locking primitives in pt_irq_{create,destroy}_bind() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US 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 X-purgate-ID: tlsNG-ebf023/1788872627-C14D3B50-4B870148/0/0 X-purgate-type: clean X-purgate-size: 1788 Both functions already assume IRQs to be enabled upon entry, by e.g. their acquiring of the domain's event channel lock. Hence like e.g. hvm_migrate_pirq() (also called from here) does, saving/restoring of EFLAGS.IF isn't necessary (because of the functions called, we can't really avoid the saving there). Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/x86/hvm.c +++ b/xen/drivers/passthrough/x86/hvm.c @@ -400,8 +400,7 @@ int pt_irq_create_bind( if ( pt_irq_bind->u.msi.gflags & XEN_DOMCTL_VMSI_X86_UNMASKED ) { - unsigned long flags; - struct irq_desc *desc = pirq_spin_lock_irq_desc(info, &flags); + struct irq_desc *desc = pirq_spin_lock_irq_desc(info, NULL); if ( !desc ) { @@ -411,7 +410,7 @@ int pt_irq_create_bind( } guest_mask_msi_irq(desc, false); - spin_unlock_irqrestore(&desc->lock, flags); + spin_unlock_irq(&desc->lock); } write_unlock(&d->event_lock); @@ -606,9 +605,7 @@ int pt_irq_destroy_bind( break; case PT_IRQ_TYPE_MSI: { - unsigned long flags; - struct irq_desc *desc = domain_spin_lock_irq_desc(d, machine_gsi, - &flags); + struct irq_desc *desc = domain_spin_lock_irq_desc(d, machine_gsi, NULL); if ( !desc ) return -EINVAL; @@ -617,7 +614,7 @@ int pt_irq_destroy_bind( * pt_irq_create_bind is consistent across bind/unbinds. */ guest_mask_msi_irq(desc, true); - spin_unlock_irqrestore(&desc->lock, flags); + spin_unlock_irq(&desc->lock); break; } From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:04:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:04:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412017.1642500 (Exim 4.92) (envelope-from ) id 1x3vUf-0007yZ-0B; Tue, 08 Sep 2026 13:04:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412017.1642500; Tue, 08 Sep 2026 13:04:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vUe-0007yS-TT; Tue, 08 Sep 2026 13:04:08 +0000 Received: by outflank-mailman (input) for mailman id 1412017; Tue, 08 Sep 2026 13:04:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3vUd-0007xu-Os for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:04:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3vUd-004Zhk-5J for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:04:07 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa007bd-8faa-0a2a0a5109dd-0a2a450b8ee4-26 for ; Tue, 08 Sep 2026 15:04:07 +0200 Received: from [209.85.208.176] (helo=mail-lj1-f176.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa007c6-b7e8-0a2a450b0019-d155d0b0d453-3 for ; Tue, 08 Sep 2026 15:04:07 +0200 Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-39c74c469e8so29495451fa.0 for ; Tue, 08 Sep 2026 06:04:07 -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 ffacd0b85a97d-485885bfe14sm36519258f8f.35.2026.09.08.06.04.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 06:04:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788872646; x=1789477446; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=N4ehEHAnD16Wpc4/Cpl1nzW0/o6yLO83VsoudM0AX+E=; b=StqUffyYbC8vWMRWtrFhFKzJYaDcrQ5u+KPMsBxhltwXgCptzdFXZGt4aFCSwVFUmS lCaqwQpuiFF9YZuEr3wdmVAT0KgvSJM8mR7nApmr//ZbHS88Ma1iRcVfsc41hBhhPQ9r gxM+k6RR2RKWVmk4lTKso8Y75rYpjtcbvmzsh/wI+QQqe+0TwAekfjjCakEV8YsTG4sA 5XNpjiq1eiO7k5/XomfDdGUGnnmbFAFFsx1USmdRpEyaWcpauiymejXDCoQfix2xLMJT 80PKCoT0JxznrnEj394vt+YHu9GKKnN06V2e4zdpKgAlqX1gAUGG7HGj6txOnYnHvQtf 8NNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788872646; x=1789477446; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=N4ehEHAnD16Wpc4/Cpl1nzW0/o6yLO83VsoudM0AX+E=; b=qd3prFamnMPRUtSlGLbAq+FAl0m7xgBW4ZCbIOdt+eCKyll3u/4A63jvoQO+vNrmai 9TAMwN8xt4lSQXUaSz8lxAh5fs/9yP9E3sMA8D5pyIcKkQbvNM8SyLqR8Lp4gedV/Rtd iETft/4SLTedliKAQpyOeiy7Bp5ygol0F6keIbPlLFlitv2W0kWG8U2PP76NjpIu3NKO 43w9sFZYOsK/o5PurU9IpEJe9xx1R/YlCHcyHmuCX18u7zd3ZckY+gDFboiZao5GRkmZ aWUV7+Uwjpx5w6iG1PZcOywnbn49HK4xo2k60e678yXVwEUZfGBS8W+IyIfiX/d9R4Rj nehA== X-Gm-Message-State: AFuF++m7cjp66oq+nS6SQemWgDx0LlfJ9ofHDiA0W4R06R44rIsmA9BA Bhb2ZHqWaCGlLAnyuVMjL8yNEElrrSt2BByYyRPIdD9sHCgjCvGZd0h18uOoXqzFAOx8aQewvHw T0GbRGA== X-Gm-Gg: AYBFou1C65f7WP5PF7RakbIslw3JJpBVLSyKK9XOvkltoYJggaHJnWjAQZKwjokHYbQ byrbfBEqp+uGvFFwPfwaM0rSnOLzNgVeLEC+Pdk10Bio6IrTDhyUj6cDZ9FZCgU4FIi5ENjF/3Q nL1qUltIWLbG1HvKw+SuxFP4tt3lLK3SCvZC/pD6NzsE+zBU+7Cvi2jX1U8j4XXUJHySKxbxaHG Pn5E2OcYNVk5BTk+E+XabRILSxHt+VmbRB0N9FJpoLmOc90SvsaFKQHAzj/2zY/W9ArJhpEfjc6 gpCsSR9k4+ZFAAjlKb3kkFnF7XS1bYO/nSht/DachY3eG6x44FWILzGvBlH8FasyFPHYVFJEJfq fIigoayyjMElk5kINara3Mn6r9ahWiGVyVWJIULE0RpWWEsOrbwlKBQtJtSDdp9Cnv1k7vnQYZ5 ibtODAM/L8oWGzHPhWeq+suXUQRdwE4xocwjpMZBlpB2sSt1hUz/vQITfYGG8snAOsFUW4HfXj4 HLQOdDWS/ZbiEWCRdGB6+WqUwAtektei8/adFkOAtj0hG+WOcutCqr7eFQP2wY= X-Received: by 2002:a05:651c:a11a:20b0:3a3:7681:6d6e with SMTP id 38308e7fff4ca-3a3768174ebmr19166161fa.23.1788872646239; Tue, 08 Sep 2026 06:04:06 -0700 (PDT) Message-ID: <20d7bba5-33d2-48c0-963e-7ed24e014e21@suse.com> Date: Tue, 8 Sep 2026 15:04:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 6/6] x86/HVM: drop vector parameter from .pi_update_irte() hook From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US 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 X-purgate-ID: tlsNG-42698a/1788872647-AB4D39EA-10A8BAFC/0/0 X-purgate-type: clean X-purgate-size: 2804 It's redundant with the struct pirq * being passed, and the vector field in struct msi_desc wanting to be cleared can be derived from v (and hence pi_desc) being NULL. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -395,7 +395,7 @@ void vmx_pi_hooks_deassign(struct domain * when guest changes MSI/MSI-X information. */ static int cf_check vmx_pi_update_irte(const struct vcpu *v, - const struct pirq *pirq, uint8_t gvec) + const struct pirq *pirq) { const struct pi_desc *pi_desc = v ? &v->arch.hvm.vmx.pi_desc : NULL; struct irq_desc *desc; @@ -414,7 +414,7 @@ static int cf_check vmx_pi_update_irte(c goto unlock_out; } msi_desc->pi_desc = pi_desc; - msi_desc->gvec = gvec; + msi_desc->gvec = pi_desc ? pirq_dpci(pirq)->gmsi.gvec : 0; msg = msi_desc->msg; spin_unlock_irq(&desc->lock); --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -220,8 +220,7 @@ struct hvm_function_table { void (*sync_pir_to_irr)(struct vcpu *v); bool (*test_pir)(const struct vcpu *v, uint8_t vector); void (*handle_eoi)(uint8_t vector, int isr); - int (*pi_update_irte)(const struct vcpu *v, const struct pirq *pirq, - uint8_t gvec); + int (*pi_update_irte)(const struct vcpu *v, const struct pirq *pirq); void (*update_vlapic_mode)(struct vcpu *v); /*Walk nested p2m */ @@ -835,9 +834,9 @@ static inline void hvm_set_nonreg_state( } static inline int hvm_pi_update_irte(const struct vcpu *v, - const struct pirq *pirq, uint8_t gvec) + const struct pirq *pirq) { - return alternative_call(hvm_funcs.pi_update_irte, v, pirq, gvec); + return alternative_call(hvm_funcs.pi_update_irte, v, pirq); } static inline void hvm_update_vlapic_mode(struct vcpu *v) --- a/xen/drivers/passthrough/x86/hvm.c +++ b/xen/drivers/passthrough/x86/hvm.c @@ -388,7 +388,7 @@ int pt_irq_create_bind( /* Use interrupt posting if it is supported. */ if ( iommu_intpost ) { - rc = hvm_pi_update_irte(vcpu, info, pirq_dpci->gmsi.gvec); + rc = hvm_pi_update_irte(vcpu, info); if ( rc ) { @@ -686,7 +686,7 @@ int pt_irq_destroy_bind( what = "bogus"; } else if ( pirq_dpci && pirq_dpci->gmsi.posted ) - hvm_pi_update_irte(NULL, pirq, 0); + hvm_pi_update_irte(NULL, pirq); if ( pirq_dpci && (pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) && list_empty(&pirq_dpci->digl_list) ) From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:44:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:44:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412056.1642536 (Exim 4.92) (envelope-from ) id 1x3w7a-0005kV-3a; Tue, 08 Sep 2026 13:44:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412056.1642536; Tue, 08 Sep 2026 13:44:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3w7a-0005kO-0X; Tue, 08 Sep 2026 13:44:22 +0000 Received: by outflank-mailman (input) for mailman id 1412056; Tue, 08 Sep 2026 13:44:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3w7Y-0005kF-86 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:44:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3w7X-0091en-0o for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:44:19 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa01129-8faa-0a2a0a5109dd-0a2a450a83dc-10 for ; Tue, 08 Sep 2026 15:44:13 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0112d-f2d2-0a2a450a0019-d155802ce1c7-3 for ; Tue, 08 Sep 2026 15:44:13 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49d0da752ffso25320195e9.3 for ; Tue, 08 Sep 2026 06:44:13 -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-49d03543064sm302982865e9.13.2026.09.08.06.44.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 06:44:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788875053; x=1789479853; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=jkSMrQgpk18fZwC2aPVLtuqV8lZqxCdCFIjkgd3VC04=; b=HxxFFlOfiTOUAV7RPB0T/ghvKCbHvF07SvNOuFvFQuKS43xo7G5zp2tOeVZn1PivdX doxWRq5Mg8zJy6wkXGnW8I8Eq0ieDlAZyYcosx3f1+crPFeoSWZvmCvSIjxSN0YNV/5M GGKwZ9hpOc239iD113If7PLh0Njff2ZIQFERCrs0bTHyuz5TFKE13PAYSh5G1ax7IMJI C7xIVtNQz4aCcHEuihtKk3mI5EH3z+jcyIPSTdi8yG5t/DVBj4EIoocnlwmD0M/OwG7W obr+BB50Q1dcZPS/kaPJp/1F9OHM0DX6Jd9NjX4Hqgk5FwaLizFYaMfP0c/G89ZIJSVA fXGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788875053; x=1789479853; h=content-transfer-encoding:content-type: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:content-type; bh=jkSMrQgpk18fZwC2aPVLtuqV8lZqxCdCFIjkgd3VC04=; b=Seuf0RFFI3ZxbxLthGcsUGlIn+8rD8wpJ2blhtSidiQopjD7/U45ZCGhblgXzaiJKD V0KHy2Bg9PGh64tNoyMy14CCOzfWdUdUe6jsbe00tGCuxEoVGtclrhpfdKsRmSCDQxb/ hRId5AR6qSwtMpQZBgA7gSAzjk2RVyI29yqhnHehMd3g9E7E79VPxHT8mit2LFcNO4ZR Gl6twwlJ7aHlZ/148OK6NhoLM6MkcDwGLPrHeGcV4a51sj6mrstSW1KgKBiC5yOGCH/j yfvlfgse2GA7swdps3uKOGiq2VbErcsrbLWB6wSIzIJciDxY1gb/iTebjURrVZPe/O7p RSMw== X-Forwarded-Encrypted: i=1; AKwUvBzP+yCLzenv1Hvqcg5eAFz4qKLnFRNMsCGGlRwmiMwFJ/8H0qpqtHABDQvpDYPHtD+VlMDb/yUybkI=@lists.xenproject.org X-Gm-Message-State: AFuF++nJaHJo8qRY3btRJ5TYzoa6buPUtm0Bdc4BDqvhjsbbM6+q60b0 jTJIPaxxdtL8HI3fMm3HyezPbfKfSjJyEt/0YnolJlG32okuCUHZ2FyL3DRruZg8Pw== X-Gm-Gg: AYBFou0xQUEV5YE5cYkjYx4exlySfXMUMcXep9jck9z+bB5s+iVnqMBbbA3HkJRdga/ wTgVDs+6P6WfLVrgEQ40Nb38vp/I3jpAnrYiaVYgaBP32+rUwJ/P9gpPQqXm5lOsBSiBldhwYiR zI7ngRcizL2OenjCku0MQgboN4yyb27hT7SS/yfRYWFVN8wYkN4gKe4OlZd1BRpjWCO4WVpyMsm NO8V0vQEFOpg2dXt+7E/BGm1LIyakRcnYTQog6Jap1KJmTXQGr1YUormolVgrtn4mJ6nsxv5xgL X7dcRrCGct/eDYfUChcoANjTFhJQuNgJbC4kVzQ1FUscPyzO/GSqcyU9V95MbOnMZH/tEDaq025 0vfYaoRdt07CUeJ3TnqgAP4GtIV8PYODyY1TkwhRLkkDyGwbZyjczupjYZ+bHsDhRYQRFjtZ3YN LmFWh1+EcvQNQopTJR5qc4qVx/sAHpqJzjYfjqR40CkzaAAQ3PBqY0uVCF/UCXz3NDUmlIUczYR 4h6jf1Qhnklc27fw/hM+40plLODadRyZQ/Rq1feCnbZZxzVN475kePBWTK1HvE= X-Received: by 2002:a05:600c:4fc9:b0:49c:fc6e:8cb9 with SMTP id 5b1f17b1804b1-49cfc6e8e1emr259560385e9.29.1788875053057; Tue, 08 Sep 2026 06:44:13 -0700 (PDT) Message-ID: <39841f44-2b18-4368-a9f8-7c0db307ff6d@suse.com> Date: Tue, 8 Sep 2026 15:44:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.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: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788875053-504CFCFC-D4C222CD/0/0 X-purgate-type: clean X-purgate-size: 6373 On 27.08.2026 17:21, Oleksii Kurochko wrote: > @@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_table_entry *ex, > regs->sepc = ex_fixup(ex); > } > > -bool fixup_exception(struct cpu_user_regs *regs) > +#define CHECK_GPR_INDEX(num, name) \ > + BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) \ > + != (num) * sizeof(unsigned long)); Nit: Placement of the !=. Also there should be no semicolon here; it wants to ... > +static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, > + unsigned int num) > +{ > + /* > + * The GPR number -> struct index mapping below relies on x0..x31 being > + * laid out at the start of struct cpu_user_regs in architectural order, > + * matching the register numbers GPR_LIST() hands to the assembler. > + */ > + GPR_LIST(CHECK_GPR_INDEX) ... appear here instead, for this to actually look like a statement. > + ASSERT(num < 32); > + > + return ((const unsigned long *)regs)[num]; What about release builds? You'd happily overrun the array there. Maybe (ab)use array_index_nospec() here? > +} > + > +#undef CHECK_GPR_INDEX If the sole use of the macro is in a single function, it wants #define-ing (and #undef-ing) there, not outside of it. > +static void ex_handler_trap_info(const struct exception_table_entry *ex, > + struct cpu_user_regs *regs, > + unsigned long cause) > +{ > + struct trap_info *trap_info = > + (struct trap_info *)regs_get_gpr(regs, ex->data); > + > + BUG_ON(!trap_info); This feels extremely weak. As you're fetching from a GPR, the majority of possible values stored in GPRs is going to be invalid, not just NULL. And while the accesses below would trap on NULL anyway, whether other bogus values would trap is pretty hard to predict. If trap_info is expected to always live on the stack, why not check for that (perhaps also check that the low few bits are clear)? > @@ -23,20 +30,36 @@ > > struct cpu_user_regs; > > -#define ASM_EXTABLE(insn, fixup) \ > - ".pushsection .ex_table, \"a\"\n" \ > - ".balign 4\n" \ > - ".word (" #insn " - .)\n" \ > - ".word (" #fixup " - .)\n" \ > +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ > + ".pushsection .ex_table, \"a\"\n" \ > + ".balign 4\n" \ > + ".word (" insn ") - .\n" \ > + ".word (" fixup ") - .\n" \ > + ".half (" type ")\n" \ > + ".half (" data ")\n" \ > ".popsection\n" > > +#define ASM_EXTABLE(insn, fixup) \ > + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_FIXUP), "0") > + > +#define EX_TRAP_INFO_REG(gpr) \ > + "(.L_gpr_num_" #gpr ")" This doesn't need to be wrapped across lines, does it? > +#define ASM_EXTABLE_TRAP_INFO(insn, fixup, data) \ > + DEFINE_ASM_GPR_NUMS \ > + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_TRAP_INFO), \ > + EX_TRAP_INFO_REG(data)) There's no visible statement separator between DEFINE_ASM_GPR_NUMS and ASM_EXTABLE_RAW(), which only works because DEFINE_ASM_GPR_NUMS appends a separator also at the very end of its expansion. I think that better would be changed, such that at use sites such as this one a separator becomes mandatory. > /* > - * The exception table consists of pairs of relative offsets: the first > - * is the relative offset to an instruction that is allowed to fault, > - * and the second is the relative offset at which the program should > - * continue. No general-purpose registers are modified by the exception > - * handling mechanism itself, so it is up to the fixup code to handle > - * any necessary state cleanup. > + * Each exception table entry consists of two relative offsets and a > + * handler description: `insn` is the relative offset to an instruction > + * that is allowed to fault, `fixup` is the relative offset at which the > + * program should continue, "... in case of a fault, ..." > --- /dev/null > +++ b/xen/arch/riscv/include/asm/gpr-num.h > @@ -0,0 +1,37 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef RISCV_GPR_NUM_H > +#define RISCV_GPR_NUM_H > + > +/* > + * GPRs by ABI name, together with their register number (x0 .. x31). > + * > + * This is the single source of truth for the mapping: True until here, but ... > it generates the > + * .L_gpr_num_ assembler symbols ... no, it doesn't. It's ... > used to turn a register name emitted > + * by the compiler into a register number, and struct cpu_user_regs is > + * checked against it at build time (see regs_get_gpr()). Neither list can > + * therefore be changed without the other. > + */ > +#define GPR_LIST(x) \ > + x(0, zero) x(1, ra) x(2, sp) x(3, gp) \ > + x(4, tp) x(5, t0) x(6, t1) x(7, t2) \ > + x(8, s0) x(9, s1) x(10, a0) x(11, a1) \ > + x(12, a2) x(13, a3) x(14, a4) x(15, a5) \ > + x(16, a6) x(17, a7) x(18, s2) x(19, s3) \ > + x(20, s4) x(21, s5) x(22, s6) x(23, s7) \ > + x(24, s8) x(25, s9) x(26, s10) x(27, s11) \ > + x(28, t3) x(29, t4) x(30, t5) x(31, t6) > + > +#ifdef __ASSEMBLER__ > + > +#define GPR_NUM_EQU(num, name) .equ .L_gpr_num_##name, num; > +GPR_LIST(GPR_NUM_EQU) > +#undef GPR_NUM_EQU ... this construct which does. This is relevant to separate, since GPR_LIST() is also used elsewhere. > --- a/xen/arch/riscv/include/asm/processor.h > +++ b/xen/arch/riscv/include/asm/processor.h > @@ -12,7 +12,19 @@ > > #ifndef __ASSEMBLER__ > > -/* On stack VCPU state */ > +/* > + * On stack VCPU state. > + * > + * x0..x31 must remain at the start of this structure, in architectural > + * register-number order: I understand that the order need retaining. But why would it being at the start of the struct be (overly) relevant? You could use the "zero" field as the anchor for calculations. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 13:57:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 13:57:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412066.1642559 (Exim 4.92) (envelope-from ) id 1x3wK4-0007ap-BA; Tue, 08 Sep 2026 13:57:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412066.1642559; Tue, 08 Sep 2026 13:57:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wK4-0007ai-6y; Tue, 08 Sep 2026 13:57:16 +0000 Received: by outflank-mailman (input) for mailman id 1412066; Tue, 08 Sep 2026 13:57:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wK2-0007aJ-Ae for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 13:57:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3wK1-004j65-2i for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:57:13 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa01429-bab6-0a2a0a5309dd-0a2a4506d750-36 for ; Tue, 08 Sep 2026 15:57:12 +0200 Received: from [52.101.61.4] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa01437-195a-0a2a45060019-34653d04ab6b-3 for ; Tue, 08 Sep 2026 15:57:12 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH7PR03MB7980.namprd03.prod.outlook.com (2603:10b6:610:249::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Tue, 8 Sep 2026 13:57:08 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Tue, 8 Sep 2026 13:57:08 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EPDTlBNd6SFlSubrN/OFn1/9sqpVRCzbU3hPnQBt1duxrpXxj3ZmPN0m5evosqjCaAcSjmHFzLfvkfoxv+OwhBb7UbBubgp5NShlIg+5/etzACLfxqTEN4zAHH/5xq6WtFZlAk/87HVuOSKBn5kroWxsxI91Py6IVk+GNvLUPjjLaNrj9F5G04/j+xlLn9P+2FaTt+eeCJVT+oEuRWLl/fm5sslD74RBt4+CnjA7FnEn0YJqd4zYPgLMZ8U+miKqyemlNxlylYmePkxN2hTYU/B1I8n0BmWxVINn6K0MPtuOSJr7IxhfqKcTugFdVIYm+9no/TbR/HI7yp11muWwLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IyY/cLIvGbmFJPpTHDCnZ6kLwWjrCl/J+pPigG+JXCI=; b=HXu48m4Sy4F/Yj9Vx9NUGAEvnc8txhWEQnmA4xpYP9O5rDOAIeJUXlRlVPe8uI5JZu6EvfKUMo4FZa1KW0rjPYDyXDBbO2YPfe2ulk3JMotFirDxLQf8no61d0fvmemLAeCSbC5ai1bZyBb1tgnxVB0Uh6PUE51GEcZA3BfohLz3zkNq2RMZuT3699hZRFK3MCfRDeNOKCZmIPi9mbVgVhQuPTQsClWIbGreOcjQ4MW40zEfD+rgqYll4+t9DjMf1Wy8uzBKy/scfQlcCVJciysEM+qjIbE0jn7TCR20tlm0T81RAK5YVaUqIKbv+fOnrBLrzhce5CGjtr8eFnYU2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IyY/cLIvGbmFJPpTHDCnZ6kLwWjrCl/J+pPigG+JXCI=; b=wnFZMc8utVp6t8+Akqrr9Gi9gaHm7movv6iign5ILgDx+VI5Ari6pga45iV01yo/g576e/CVd5A6HY8GrZzvreX0NF333t9gmXqoNnVDB3hgABS0tothh5kutzpQbtZz1XIGLpahlj+TitcXjOvw7TT9soSt7yRSo/JVE4+d+Jo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 8 Sep 2026 14:57:05 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] x86/svm: Intercept CR0 writes selectively To: Jan Beulich , Ross Lagerwall References: <20260904122330.306936-1-ross.lagerwall@citrix.com> <8fbc99b1-d98b-4f52-b9ea-bd84e8bfa2ca@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <8fbc99b1-d98b-4f52-b9ea-bd84e8bfa2ca@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P123CA0023.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:313::9) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH7PR03MB7980:EE_ X-MS-Office365-Filtering-Correlation-Id: a85841f5-51c2-4534-a117-08df0db112b9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|10067099003|4143699003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: XwiQc3sKTd0G/2M73CID8lbZfWvASzx8VNVoJC81coswKxkNoMH3FfL4YgYeXGf8mmWXKh7oNRRGtLBLnDVRP+xDyzg4NrD9qz+ZHFaS9VqCqucX1lBup2sJYt98MXgai4h7a3UR71w2k+VjCBtHoSUA7MLAUke2ll0d/A6FvE2C6SmIUbGMGuNsNzzNoYryqFgEznCQMSwld9nLisFN4e+EVeC3db+QKw0asuhYd504K5xloRqSSg0zjJmkoJ6NUDecASsJm4sgyeuZO0DbfWGyndNhXsG807a2B1l/OPcpFfLQl88AnN5XFw1DvOhJ/3qdDMr4EP38SPANH5C6AZrq/wYpi5BQSF6t0tGfYVPITMPosSB5NV0K/KSG3fSdJwBxRTbiTcVO5U7Kr6MzglneRw4yIjr40DaFLPGW3hHuPg9E1Bx6VGKb5M8EDi94IwEmIGk91GLq8vUeutoR+m/IF2e1vIViFmluUSP/mbiEF/3ac+p1kRR2EDuPZmSJ7AX3bjNfFGcKZPTe8qnNkJ12ySHSBwMnyxmU+mhUPACNz8KtPqH7XDCISkp7DdVAp0HHmdQuvp0MGBzgUaWbnhV2r5xrxKTnbLNdjgmuE5aL8UY8Fox8sPwru66zI+a7oAFNhYhJULb4HLKUQ/4saVIDgWYVaggKmWJyb6Aifr0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(10067099003)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aG85MElQcWFqRmZoWXUzV0FzZy9jcVJ2VlBpdlZVSkhacUR1Tm1NSFBwM2Nx?= =?utf-8?B?WVdSY0pDUlhtZmZjdUlSYlBJMGNpbVlFWkZhZFVUYzgwd1lkNEgrUEFON09s?= =?utf-8?B?RjZITFBVb05EU0hSYzFCcG1mVVlyUk5DeHBzU2NXUEZudjF4U1FDeUJnOTJm?= =?utf-8?B?dFNzaTBtckN0MzNORXNBNitidTFyYzJ2cG1oRFB5dXJYa0ZReEFSeXMvcFNU?= =?utf-8?B?UzYzR0NEK2ZIRytsWHpoV1UrZmxjVzM4SGRwMFBhV0xYdlR2N3NZVDg3YTdj?= =?utf-8?B?WjJXZG45ZDNkd3pSMHNkcTc5UnozOGVac0RZUFVkengyRmZaMXVFS3ZTRVNZ?= =?utf-8?B?T1U3ZnNtd1RXQS96ZVVqM0Z3SXdHUHlmT1U0S2JsM05ZMXJQZzQ1NGRaN3NN?= =?utf-8?B?TzJVeWtSSTdYekdRdkVHRjd5bVdpMlBYQmx2S2RYY0Y1c056ekVYYkZJRjdZ?= =?utf-8?B?aUd3OGp5ZDVNbmhaWGZnYTIzREZ6RkgzNkNROHVzVjZJaEpHTmZtbE5uL3Bv?= =?utf-8?B?UERIcDVTd0MveTU3U0VHMXRjYVB0eXhLWnJncTNNZUhhNmV0cUI1S3MrTUJi?= =?utf-8?B?S014c0xJelpKZXBETmg2WWs0N3ljRlh1VjMwT1JzUXlXL0J4QVpSVVNiMnlF?= =?utf-8?B?ZFcweWxvcmlhMVZQNWNseHVpUUJBRGszd0QvVnNZMnhISStTeG5wZ0YvM042?= =?utf-8?B?eHdnVXRZZ25PU3l1RDFqT1RwNUd3LzhrakxIblVkTHdPMXYyVlh4WmpwNVVM?= =?utf-8?B?S0loR2t2K0tvQ1g5ek51TVYvRUdicERuSXFzMEpkeGxYaXZrTno4d2Z1QzNE?= =?utf-8?B?Um9OZStjVEljNk1Wd0RZYTlnbWQ2STFXMFM5RUo5bC9yU0F0VVMwRGpGZzMr?= =?utf-8?B?TjFWZWlFcG8wYWZ0dFBuUDlqWVI5ODlUZjdObVNTNHdoV3EwMVlpaFI4UGs0?= =?utf-8?B?QW5KZGd6ZnBZOGV0aHppemdjTUkwZ0d2c0ZGdHZzK2VVSmFyK3hLeEV1RHZN?= =?utf-8?B?MUJhcm9VSWQ3R1ppTy8xVmRMckR5bndxR2p0cDdTblhZaUZCUm5uUkpaN2p4?= =?utf-8?B?TkV2Ym5VVlJLYnZaYVAwL3BYaVpUVjdnQnBEcUtRdVh6RGp4bzNHYmlMdWRJ?= =?utf-8?B?QXdPdGNhSDQ4elVtRTJXUFU5N2hMNWNML3MwWGhYQUxSSm0zWmtoT0pDZjk0?= =?utf-8?B?T25UcFhvbzB6NDc3dkp3QmxNcHVlTU5IcFpMSm1adTlRTTRKNUJ5VkNlRHNU?= =?utf-8?B?bG5SdTdHRDZvY0RvcFVveVhuL25QM1lzOTRQVFExNzVSZk1EQnI3clFiV3VG?= =?utf-8?B?T3NRaXArQjlkcFVCaXBRdHhSNUIwem5maWd3elc0S0p0SlpWaEE1d2V6bVpQ?= =?utf-8?B?SkF4K2RzMHlDVjdXYVNnQmhZaWNEV05LQ0QrbElHMmlWczBTcmE1TE9hZXl1?= =?utf-8?B?VXp1ZHdUZlNobTFDei83aHZkMjZVUnlWMS9xREZxZHNrSmtKL0ovUTR3cjAz?= =?utf-8?B?bXdVa3dNQXc4TVUzWEVpL3dhb29waUpWM0ZHb0tnZGlYQTBVS1ZoV1BSMlB4?= =?utf-8?B?ZzNhSCtUWkJaTUFUMlN6WkF0QnVmaGJrNGtkSlFLUFJzV1lzdlN1V0JrMmdE?= =?utf-8?B?VWxXYVRzdXlEbkY0cHBaZmRvZFJTTW03Mkp3RWFHWHF1YXRrblFFRDQyWWl3?= =?utf-8?B?d2h4cmhPaXY3cHZHNHFJYkRtalcyOXBvMU1lQ2piYXVYTVk3MWNld3JjY2Zh?= =?utf-8?B?QnBUeXdVMWxBS29pMzhteVBNS0dzbVkwWWZNYmN6ZjNlbUhscFdaM3JFeURu?= =?utf-8?B?RkxrU2hRektZWGo1QXB5MWdUdFovRGJIRWNqbjQ5U21DWTViaVdSY0NxYjFv?= =?utf-8?B?L1dENjRwWlRjdjVucUxnSDViNHNxYmhnSEVaZVYvRmdvSlhvcW9BemFZK3JB?= =?utf-8?B?aGZrS29CVVZRNDlOZEh2QStXbWhWYW93Rjg3Q0VrbEk2a2dPdkJiUnpCTXVn?= =?utf-8?B?UW9xZHNZdktyT2VWOVphVDhmRDlybVZlT2VQeFFlUGxrTEllU1NSSXdzM3Zv?= =?utf-8?B?eFVpODRVSmxkVmFFRXJEd3h6Nmd3Y3o1TUN6YVh4bkd4b0ZDWVpXTEhVeHo1?= =?utf-8?B?VlJkN0FvdEw3ZCtrdnludjFrc2xEWnIxN0dLa0dCSEFhMlhpUWNvTENRTi8z?= =?utf-8?B?NmtSN1cwQ0ZjRkxYc3Y1bzUvdW11VHFram81bFRTRjBHZ3dhVDBWc2d6OUd6?= =?utf-8?B?M2hrVjZid0JpWWlYN3hmcGdCNEtKaVg2K3huQk5RWlVBOGVVWkY0VlBlYVQ3?= =?utf-8?B?NHR5NjByb0xUeDZtakhscDRhV085Y2ZqSEVtQUNmTUxVSk5PUEFKQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a85841f5-51c2-4534-a117-08df0db112b9 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 13:57:08.5364 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FMh9V03g1bHuBxS4RQERuWmjx2VGnBz6FYd7Ct0DKnSkmt5Z2wlxfEIFxJkX9MXeN39GuPFqDWN8UjZgqaLIqmyZKqJ3FVSRmH2EruOvNYg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH7PR03MB7980 X-purgate-ID: tlsNG-16d1c6/1788875832-F5E0E77B-F171FC4C/0/0 X-purgate-type: clean X-purgate-size: 1480 On 08/09/2026 9:44 am, Jan Beulich wrote: > On 04.09.2026 14:23, Ross Lagerwall wrote: >> @@ -2517,6 +2518,7 @@ void asmlinkage svm_vmexit_handler(void) >> hvm_sanitize_regs_fields( >> regs, !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l)); >> >> + v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb); >> v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb); >> if ( paging_mode_hap(v->domain) ) >> v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb); > gitlab-CI says no to this patch [1], and I think it's the change above which > gets in the way of running guests in shadow mode (as is the case for the two > qemu-smoke-x86_64-*-pvh tests). svm_update_guest_cr() has > > value = v->arch.hvm.guest_cr[0]; > if ( paging_mode_shadow(v->domain) ) > value |= X86_CR0_PG | X86_CR0_WP; > vmcb_set_cr0(vmcb, value); > > i.e. upon reading back the guest's CR0 value we would wrongly record it > having PG (and WP) enabled, at which point shadow code would try to use the > still-zero CR3 as page table base. I think values need merging here, with > only TS and MP taken from what vmcb_get_cr0() returns. Yes this is broken for Shadow. Shadow shouldn't be trying to use CR0_WRITE_SEL.  What's in the VMCB is unrelated to the guest's choice of value, and reverse engineering it is fragile. Use full CR0_WRITE for Shadow guests, and use CR0_WRITE_SEL for HAP only. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 08 14:09:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 14:09:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412080.1642567 (Exim 4.92) (envelope-from ) id 1x3wVr-0001j1-CH; Tue, 08 Sep 2026 14:09:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412080.1642567; Tue, 08 Sep 2026 14:09:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wVr-0001iu-9T; Tue, 08 Sep 2026 14:09:27 +0000 Received: by outflank-mailman (input) for mailman id 1412080; Tue, 08 Sep 2026 14:09:26 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wVq-0001io-NK for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:09:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3wVq-00GkFn-42 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:09:26 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa01715-8faa-0a2a0a5109dd-0a2a450ba786-4 for ; Tue, 08 Sep 2026 16:09:26 +0200 Received: from [40.107.208.52] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa01713-b7e8-0a2a450b0019-286bd0344bb3-3 for ; Tue, 08 Sep 2026 16:09:24 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DS4PR03MB8446.namprd03.prod.outlook.com (2603:10b6:8:322::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Tue, 8 Sep 2026 14:09:18 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.014; Tue, 8 Sep 2026 14:09:18 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sSa+SlxtlDRH7MLMeJhbGOTkMCKUxW9AsL/WzzhTcs9X9eBhfA93nmpkXf0t5YOmof88Qh3WheXhRTia/+c0KJjamttcUUSvnv3bLImZqEL3vO/Etj7PlyxLrilimnkPqZK1127o2tKI4WIYMvKZAeI8yQEqavqhL6VUqQfbJ6rsyAf/qzJl6l8aV6EQ1TihfkwMK0Bfo8TmcV7Yyz9HenZRFwnbkKDts1AvWTKGoCuhuQFQuYI80Yg+El2GtMEp/jguJn3WlBegKBGeI1oXXexnZc91jEJRnpEhJBdR1ggvXXCb6QPFAtyFUGFHzx8ewCRWtLyZGWHvjSoLeLu9Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UpaGsNzzJWRgZ78NXPfKGfndninYraoAyb0SMbIgvtU=; b=tQQlQQEATJ88rmDVJQF4V5/Zl/IKMHOREICE0j5DHVJFlX/w3hk6yBlbVRELinuQ9mmI9k5R3M/df+YAklfYmlZbGFQtCWNgxeZrsq1wvzVee/TCTDCrZi7rvXMQPWJgZ/GxHuB2Ml72iMBIkIPefthQlxIQQr450wEggRmg3k7I6Hg4t1TBRhz5OmzOJGCwu9nrDqeqqvM/ebo380FnRlNpTRAlnjIxgdF7v11HTrK3W6t/J6XxzNeB1xHKky7L2VFcyUbGOgVKvBYZPmy6vJ9ngP57YGytvfFwCEKPRr9Sb8ByXewq7SPNDeTUk+VDlTxH7tiQUaJvuDVDzFv/mg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UpaGsNzzJWRgZ78NXPfKGfndninYraoAyb0SMbIgvtU=; b=HJvyBqKZL1245Bq93PQHdaRrO/G4+kowGCdiGYeqh5wsuLfz+XJUWFJsaLbji0EVvQtrY1jr+ftV5s8lOAv8giye6IOSPksAPFwsOP/fJMIobepYKlmJncHADLdJFoKCY5DI3W1Q1ZQlvX9151BShc8rKGXjvR4kxQnLfsjy10c= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 8 Sep 2026 15:09:12 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/svm: Intercept CR0 writes selectively To: Andrew Cooper , Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260904122330.306936-1-ross.lagerwall@citrix.com> <8fbc99b1-d98b-4f52-b9ea-bd84e8bfa2ca@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0082.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:190::15) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|DS4PR03MB8446:EE_ X-MS-Office365-Filtering-Correlation-Id: ac675d28-14a6-4380-db97-08df0db2c59a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|18002099003|22082099003|56012099006|4143699003|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: fTJxtBIJpbeLohIjkVRclHs5Tr5ZowXN0SbBz9K7dE4BwQltrfjxRIot4lZHPjrTzTcrKod5bjOyfzS5i6H8p5O4A4owaA48AVGlljX5E2ML/QO2gjWH5HpMpg3iYAHfhcSWk5kFh53LaiywhrZfhTzYv371hTHPjcmA1G8ds5h71mBDPz1TfW4ULt6sfK39nNVfMzce9U18Fve9uG4c0A52ZVK6STZlgGTtJtcVGXcu2uDcbe56JxWtugdrXQHu/kkoaAFyz5CH07lD0EKEHPMUG2P+XU8ERlIHVBN4KC/UQxlfYeStzZr4xAzTQZNQby133ntgNeaEZiqTelGkJU5GM9dOjIvPqJLwYJ05fG9eWD20nTRshcUtLHa6/kimmm0FZxGiQ70qVSWt52rqfCGwKg0XO4u5i3fQv6yTITQ+Ljmb6IcOUnJfWVplkEzYo+ZRB4ljy5ATvmJbfYdswv/2dnimbAsKf5Gg1m9DlwDliYdISm/up5XpBr0vQNvKM5Ek9PKvVPmvp0Di9KmxFpkkfjJDlcRWvWKbDXDntCqscqnnNhhxt1nMpTc0eaW7uWWsnKJDhVTbEIjFeApGLWKmmMx7XSZFm0SF0XZN+gM8bRj7DzcShSxM90r945V3ejRtYt3MDUAoUO1dWBAXA7fD2h1Bgsc0Y/Unxbc5laM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(18002099003)(22082099003)(56012099006)(4143699003)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TjZZVjhKNVIyc2xQL0RqelJIa2FxUDFDOWVNUEloYmlReUtyUnE4TTk5MVZt?= =?utf-8?B?Qm9FWFlLVkZQSGR0ZENVZTlxTHVJenc1OFBISm1PSE9jb3V3N3VLQzJrKzNt?= =?utf-8?B?YXZHUWN0ZGJCY3hvQUJsdERyWm1sc3FYOGdBZ2o4cllsQW9ENEMwQWhhQjNs?= =?utf-8?B?aE9KZlV5bVRpNDRudlU4b0NhN3RKN1Y3WGVMSWZqSDZlNkZhd2c4Z3RDWnlw?= =?utf-8?B?L2xrYTZqdHRPY3RuOEVuam8xQ3RaaVZJa3g0VkdoV01CNTRtbHJJUFZVdHZn?= =?utf-8?B?MzFFOEN5WlVvV1gxUm1WZGhvc3J6M0htWVN1YmljN2hsYkpWalZTSkp0aThO?= =?utf-8?B?NjhnbmUwTytka2JkVzJJc1NNa0hXbjdZbjhiVm1QVVpPclhrdVpnVlZjQVhr?= =?utf-8?B?cmI0TzA2T0RpakQ3bk8yR0ZGRC9WZWY1Vjk1MnRzU0J0M1k5WEdnV3Q1d3BH?= =?utf-8?B?SUZMWVdNUTJ3cGlYczExcVpKb1B4TVhaNE5kZVJBUVkrK01TNFlwUjFGdlRx?= =?utf-8?B?eE1hUjhDeDEwYnhJWFUwVkZaWnpDZjBnTHk2WDl1UHpTRlVqV1R5bUhqV2hM?= =?utf-8?B?a0Fsbm53STBPTVZmRS9rUXZURHdvTEdXdlp0OWxNM3pmczJwZ1FxTUtMaTNY?= =?utf-8?B?RDFEZ1dMUjJybm5HclgvOGJ0SUZnV24rdWVRTWVDZlNObjlMQWhzTHRrTHAy?= =?utf-8?B?MnFNZVBURXZoNWZpNis1azV1U1pWeVB0Unh3SEtEQ0R2U0NZTndTNHpxWUNz?= =?utf-8?B?YWFHVitsb2xRVldUc2tya3hFSU5Ba3NUb2srSHRFK2lrVW1CZjA0cUVPb2lz?= =?utf-8?B?ZmJKY29qZVFvbjlIUjBxcWtDUFRkcFB4VXRkdmlENXR2akhxbHVHVFJqbE9l?= =?utf-8?B?aWcxMnZZWE9tL00wOU5qQnRqRnJrVXpua215WCt2NWdIdDlUajQyNVNtZGdI?= =?utf-8?B?OGdkc1dsakMwOVJFN0E0VlRqVDRjdlpqUm84azMxeU4rendUM21uMXhDRWth?= =?utf-8?B?SEVMczFaclllWnE5MDZ5Z3ZCZk9jNCtBVnAvOHZnQUg2bEk0bmswMTM5Nk1H?= =?utf-8?B?RFJ6MnNpbksrejBlemV6N1BldmtvaEUwamdvM1dBci9CRWtLcTZ1c25IZ1Ux?= =?utf-8?B?TnQ2a2wyODZRc3JwS0FPSTZJWXdXbTZzSkd2ODFrV3lpazFvaHN4Vi95MmNX?= =?utf-8?B?OHNwUkNFMWJhZVQ0QjNja1dCT004ck5yVEZ4ZjBXZ3cxTkg4clNSZWhxZFk1?= =?utf-8?B?emFiWk5CV2xUSE83elY3M2JvcnFpdWdFU3l1ZEhiMTRPaGZsMk5JOHBGc2JE?= =?utf-8?B?blJvSUU3b2lWTTRxbXNacG5uak4wWlRuUHI5ODIzd2JreENCRlB2a3JpVThH?= =?utf-8?B?MWNtakZjclpDaG0rMjF1TVZLS2REa2VuMGtrcDhPU0J4endrUUFpRW44aE1E?= =?utf-8?B?VXV0cGtnMGN2RzV1bWROSnNGL09iL1lxR2FpaTJvRkl2RnBtYTFDeFVDaTI1?= =?utf-8?B?dFArbGZQTzl3YzN2UXJ0ekZ4TVplU0FvUjdNWE04c3JKWVdyOUF6bHB6UnRp?= =?utf-8?B?RE1zQWhkTG0rL3FFbzVxL1VjZVZTYnN1eVY0T1hHVTdJRks4YlV0MzlxcnJs?= =?utf-8?B?VXl6Z3lxc2pFbWthQm9mZDk3SVVWNm1STlVsV2ZDTHc1TUR2V2RLdmI2RVdW?= =?utf-8?B?Z01GM2IzZ2xKYjd4K2VEcklJWlphZk1sSlJxRjhycjVTRWlxSnhrNS9GdGtY?= =?utf-8?B?VE1tak1uVEtFUm9WcEgrb0RiTFVScnpBZU1qdHh2WmgvMklPSHhvbk1pREdM?= =?utf-8?B?NmRrWnM4TGt0TlZVRHh4SVp0QVFjRktCeE5kUXYzSExsWmh2cXh6N29zQ3NN?= =?utf-8?B?WGdqVTZ6TzNicTJEcVZxOXM4V3loZGRRSWhkb01oVk1GWXVMTENZMFg1NkZs?= =?utf-8?B?UGV3Y3Jlbm9ZWFZXam9pdHlyWU1Td2lZYTdTMktyRmJWaXR1WlNSb3I4OG5v?= =?utf-8?B?ZDRieUpMZy9vSTZES2JBeW54ZjJXdi8zeUdSeTU0OUZ6NUUzWnNWS3dWMWF2?= =?utf-8?B?ZnVlUWxwY1JCbytxS2IxYlAzVGdjZ3VNcmE3cUpDbUVXMHNIVWVnVEVqMVBJ?= =?utf-8?B?cEd0TFdIc3hVWDRROEFSbENuMkY2bmRhSURTQUU2c3QyOUhTcmRyOVNOM2VC?= =?utf-8?B?Q1dWZjFJR0V3ZnZrRkhpOUd6Rmk0L2ZVM0E2Sk83MEdUQjNXemJXdnZwVWJ0?= =?utf-8?B?L2xiNFZGaml0SFd5RlpDb3V1M3pPL0c4SVhWVW1VTFMrMjdsQ085U1FaYjVY?= =?utf-8?B?WVMxM1VEdFIyWXVNN0dUL0cwQi9iVGpBdmNKSlhEZkRLbVZzSlorcjQxRkZD?= =?utf-8?Q?UaZ9NZgLH388wUDQ=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac675d28-14a6-4380-db97-08df0db2c59a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 14:09:18.2219 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VSQoF/DxvQiycfOwK9o0pFbO7yxegjV7IoVqCyyk3xD5dF1Z2ny76mJXDehaMu/erU8ost6GiY2Hp4Z+jOi5WIxEV51T1nhjd08aCPhfqqg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR03MB8446 X-purgate-ID: tlsNG-42698a/1788876565-196C29EA-D641BD4F/0/0 X-purgate-type: clean X-purgate-size: 1868 On 9/8/26 2:57 PM, Andrew Cooper wrote: > On 08/09/2026 9:44 am, Jan Beulich wrote: >> On 04.09.2026 14:23, Ross Lagerwall wrote: >>> @@ -2517,6 +2518,7 @@ void asmlinkage svm_vmexit_handler(void) >>> hvm_sanitize_regs_fields( >>> regs, !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l)); >>> >>> + v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb); >>> v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb); >>> if ( paging_mode_hap(v->domain) ) >>> v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb); >> gitlab-CI says no to this patch [1], and I think it's the change above which >> gets in the way of running guests in shadow mode (as is the case for the two >> qemu-smoke-x86_64-*-pvh tests). svm_update_guest_cr() has >> >> value = v->arch.hvm.guest_cr[0]; >> if ( paging_mode_shadow(v->domain) ) >> value |= X86_CR0_PG | X86_CR0_WP; >> vmcb_set_cr0(vmcb, value); >> >> i.e. upon reading back the guest's CR0 value we would wrongly record it >> having PG (and WP) enabled, at which point shadow code would try to use the >> still-zero CR3 as page table base. I think values need merging here, with >> only TS and MP taken from what vmcb_get_cr0() returns. > > Yes this is broken for Shadow. > > Shadow shouldn't be trying to use CR0_WRITE_SEL. What's in the VMCB is > unrelated to the guest's choice of value, and reverse engineering it is > fragile. > > Use full CR0_WRITE for Shadow guests, and use CR0_WRITE_SEL for HAP only. I did try Jan's suggestion which fixes the initial problem but crashes when dom0 brings up its second vCPU. If keeping Shadow guests using full CR0_WRITE is acceptable, I'll update the patch to do that since there are surely better things to do than spending time making Shadow improvements. Ross From xen-devel-bounces@lists.xenproject.org Tue Sep 08 14:11:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 14:11:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412087.1642576 (Exim 4.92) (envelope-from ) id 1x3wXP-0003CJ-Lj; Tue, 08 Sep 2026 14:11:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412087.1642576; Tue, 08 Sep 2026 14:11:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wXP-0003CC-J4; Tue, 08 Sep 2026 14:11:03 +0000 Received: by outflank-mailman (input) for mailman id 1412087; Tue, 08 Sep 2026 14:11:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wXO-0003C4-Hh for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:11:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3wXN-00986B-UV for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:11:01 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa01762-e002-0a2a0a5209dd-0a2a4504c36a-30 for ; Tue, 08 Sep 2026 16:11:01 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa01775-b57f-0a2a45040019-d155dd2dc5cb-3 for ; Tue, 08 Sep 2026 16:11:01 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-4843f205a5bso2905499f8f.1 for ; Tue, 08 Sep 2026 07:11:01 -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 ffacd0b85a97d-485885b1320sm35519732f8f.27.2026.09.08.07.11.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 07:11:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788876661; x=1789481461; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=X9ZV+IXjqldc8rwvZehjQnhQUA17T2GsGKUUd9xV2EU=; b=dtDK7+0dWcfrNRO50/0JodRt0Q57VFdPGNP5kvyncCUhSlbmoqFTSN+F/3Bf7e5/QY i5ggFUXl3jr/d91MkH3XuAJ6igwMZadgt9eed8upGyvDfcsYL5yieGrHjpUI/KKS+udI Oj4y2VQh0RDiOXy5osIXUsnFCX0N7WfwEMLBuJKUwGVWVIeIXBxf9L46Wvx73kaqCafn qabFq+TLcsVGuWLKELpxj9sCZMJyAF1ZC2xCPC+IM7zPPcglNtX5nkNoKSQS9tAlDI/J C2Y3tp20BgNPCI8M8z7U0Uh1y0RPwcX+LgAMHb6diXArVLdUZ1FnhPdcbKohahVrP7CX 8/Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788876661; x=1789481461; h=content-transfer-encoding:content-type: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:content-type; bh=X9ZV+IXjqldc8rwvZehjQnhQUA17T2GsGKUUd9xV2EU=; b=qtA1/gZeqxFo3WKJy4fZuQfUVsj3X0cvcy1P4agR6vD3UFciZxnkoIU95Zy5bUdGCi 0EyCIqzTmLUdzVmHULzVzweeDl+mMRV3ah5YIPKDruyEOZO+FJ2KIb+tDrM+l8GBYcE5 w5pJcDywKhn5mPg5O1fr0DhFVpEQpMQRFDRP7gUftbL+my8BbEs/BN7Btg3mffvSBKxF O7ML28HrumlqXF3CStNUiQJ9odFiJnKN/Q36y799a8NeVV0mMpfwxxOYn4MDZuObe26Q zbjM4SbL4omz63Of50PwrWmJqkZ7tjUbHkBI2RgsKxD44ZH1GOdeTC2Gqlc5noTaqDiD 0KdQ== X-Forwarded-Encrypted: i=1; AKwUvByQlrP3HRQzkrNVGr2DqjECOop7Pg5LxHtAPNt5qsa/p39YTAGf7KD3S3Nk+li6gDQfiWmxj3+bBuk=@lists.xenproject.org X-Gm-Message-State: AFuF++n2h8dJLDRhI7Uhyg7an51OP08w0CYFOAvzUUceCG0WlEQn+5LX kgZzosFymLVezzwL0bK4qwk+oVHUlpCgRryp4g0zxUesdNwtQnPOHiQbcNa/mBsmBQ== X-Gm-Gg: AYBFou3kPA8mxacNlxqDTQ525CiJCsBne1vHr8cwdXZcTzjoF4xdU78yb0srGzIAjqc esStE0YKAAxVTHlAu6EhH3EVD1Imgr03UwfNrg30krZjK0NhD6z2Jrx0hFlzgcuRapmIVNKvY2x XK6sGDSmIGnqzc+QfggQgjCeV/pWLyVvinDiySkM91IIXJ4jsP+CcXEyCY6LhZd8+enJovtcdI4 5VOniEKQQGhqTZVvwH70WrITn0QHGMI9tcbLoOjNSTLc1h7Nt5mdVWQI4Pe+dNT5fi/OdXkzyvi P/xk/viNR/JRIONICMvdhYJRGGYw9LR7mB2b89Cpai59tggLsPFBy+7wgeZqor2wDqo/E5yZR6e 7kmN/oEuGF6nGVqSxo0JgkFECW6EjMxTQgIGPgg21Eqyb5pi/UohtzIfO1N27Xy+pWoc3OyulMc SFCBG18s/DvLnyqoEyeKx+uyXXCXTNq3RTqvJlIT1YXllPt0h8QWr87Dnn29JbzxyEcquEy6b4i yEbKtYFp2ZqeEvVMg4t+FI9N7AfytI/rR2bw8EKqHZ5dbgNPlGS X-Received: by 2002:a05:6000:25e7:b0:485:8a46:b3d1 with SMTP id ffacd0b85a97d-4858a46b5acmr28711020f8f.57.1788876661138; Tue, 08 Sep 2026 07:11:01 -0700 (PDT) Message-ID: <35aecc68-d16e-4350-9aca-101de2b21c1f@suse.com> Date: Tue, 8 Sep 2026 16:10:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 18/39] xen/riscv: add guest page fault handling stub To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.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: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788876661-C08D9B50-29B247E5/0/0 X-purgate-type: clean X-purgate-size: 6661 On 27.08.2026 17:21, Oleksii Kurochko wrote: > --- /dev/null > +++ b/xen/arch/riscv/emulate.c > @@ -0,0 +1,179 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > + > +/* > + * RISC-V instruction emulation for trapped guest accesses > + */ > + > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > + > +/* > + * The hardware-reported details of a guest page fault, gathered once by > + * handle_guest_page_fault() and passed down to the emulation of the faulted > + * access. > + */ > +struct guest_fault { > + /* The guest register state as saved on entry to do_trap(). */ > + struct cpu_user_regs *regs; If the comment was true, this could be pointer-to-const. > + /* scause: a fetch, a load or a store/AMO guest page fault. */ > + unsigned long cause; > + /* > + * htinst: the trapped instruction in its transformed form, or one of the > + * special values (zero, or a pseudoinstruction). > + */ > + unsigned long htinst; > + /* htval: as written by hardware; see resolve_faulting_gpa(). */ > + unsigned long htval; > + /* stval: the guest virtual address of the faulting access. */ > + unsigned long stval; > + /* The faulting guest physical address, filled by resolve_faulting_gpa(). */ > + paddr_t gpa; > +}; > + > +/* > + * Is @htinst one of the pseudoinstructions reported for a guest page fault > + * taken on an implicit memory access done for VS-stage address translation? > + * > + * All four values are recognized regardless of the hypervisor's XLEN: the > + * width they encode is that of a VS-stage PTE, i.e. it follows the guest's > + * paging mode (4 bytes for Sv32, 8 otherwise). On RV32 the 64-bit forms > + * simply never occur. > + */ > +static bool htinst_is_pseudo(unsigned long htinst) > +{ > + switch ( htinst ) > + { > + case INSN_PSEUDO_VS_LOAD32: > + case INSN_PSEUDO_VS_STORE32: > + case INSN_PSEUDO_VS_LOAD64: > + case INSN_PSEUDO_VS_STORE64: > + return true; > + > + default: > + return false; > + } > +} This feels fragile. New pseudo-insns can appear at any time. If the value as a whole is non-zero, aiui the low two bits being zero indicate a pseudo-insn. In which case enumerating pseudo-insns we are currently aware of isn't necessary. > +static void inject_access_fault(const struct guest_fault *gf) > +{ > + struct trap_info utrap = {}; > + > + switch ( gf->cause ) > + { > + case CAUSE_FETCH_GUEST_PAGE_FAULT: > + utrap.scause = CAUSE_FETCH_ACCESS; > + break; > + > + case CAUSE_LOAD_GUEST_PAGE_FAULT: > + utrap.scause = CAUSE_LOAD_ACCESS; > + break; > + > + case CAUSE_STORE_GUEST_PAGE_FAULT: > + utrap.scause = CAUSE_STORE_ACCESS; > + break; > + > + default: > + domain_crash(current->domain, "Impossible cause (%#lx) in %s?\n", > + gf->cause, __func__); > + return; > + } > + > + utrap.sepc = gf->regs->sepc; > + utrap.stval = gf->stval; Would there be anything wrong with putting these in utrap's initializer? > + trap_redirect(&utrap); > +} > + > +void handle_guest_page_fault(struct cpu_user_regs *regs, unsigned long cause) > +{ > + struct guest_fault gf = { > + .regs = regs, > + .cause = cause, > + .htinst = csr_read(CSR_HTINST), > + .htval = csr_read(CSR_HTVAL), > + .stval = csr_read(CSR_STVAL), > + .gpa = INVALID_PADDR, > + }; At some point RISC-V code will (very likely) also be scanned for Misra violations. The csr_read()s here violate rule 13.1 ("Initializer lists shall not contain persistent side effects"), and I think it would be better if such was avoided from the start. > + int rc; > + > + /* > + * A guest-page fault may arise due to an implicit memory access during > + * first-stage (VS-stage) address translation, in which case a guest > + * physical address written to htval is that of the implicit memory > + * access that faulted - for example, the address of a VS-level page > + * table entry that could not be read. (The guest physical address > + * corresponding to the original virtual address is unknown when > + * VS-stage translation fails to complete) > + * > + * In such cases htinst reports one of the pseudoinstructions recognized > + * by htinst_is_pseudo(), and the fault requires separate handling (since > + * G-stage translation failed on an unpopulated/unmapped guest physical > + * address during a hardware page-table walk). To match bare hardware > + * behavior, we must inject an access fault of the ORIGINAL access type > + * (Instruction, Load, or Store/AMO) that initiated the address > + * translation. > + */ > + if ( htinst_is_pseudo(gf.htinst) ) > + { > + inject_access_fault(&gf); > + > + return; > + } I.e. you imply that guests won't put their page tables in MMIO? That's fragile imo; I have seen OSes to use video frame buffers for all kinds of (transient) purposes, for example. > + resolve_faulting_gpa(&gf); Since the function is only a stub right now - how is one to tell whether this indeed can never fail? > + switch ( cause ) > + { > + case CAUSE_LOAD_GUEST_PAGE_FAULT: > + rc = emulate_load(&gf); > + break; > + > + case CAUSE_STORE_GUEST_PAGE_FAULT: > + rc = emulate_store(&gf); > + break; > + > + case CAUSE_FETCH_GUEST_PAGE_FAULT: > + /* > + * Guest is trying to reach unmapped/unpopulated or G-stage PTE doesn't > + * allow execution (X=0). Generate fetch fault in this case. > + */ Is there perhaps a comma missing before "or", to help parsing the sentence? > + inject_access_fault(&gf); > + rc = 0; > + break; Simply "return" instead of the latter two statements? > + default: > + rc = -EOPNOTSUPP; > + ASSERT_UNREACHABLE(); To fit a common pattern, these two lines want to be the other way around. > + break; > + } > + > + if ( rc ) > + domain_crash(current->domain, > + "%s: unable to handle guest page fault (cause=%#lx) at " > + "gpa %#"PRIpaddr"\n", Please avoid wrapping of format strings across lines. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 14:16:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 14:16:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412099.1642594 (Exim 4.92) (envelope-from ) id 1x3wd6-00041m-IK; Tue, 08 Sep 2026 14:16:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412099.1642594; Tue, 08 Sep 2026 14:16:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wd6-00041f-Fj; Tue, 08 Sep 2026 14:16:56 +0000 Received: by outflank-mailman (input) for mailman id 1412099; Tue, 08 Sep 2026 14:16:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wd5-00040c-9Z for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:16:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3wd4-00HS4H-Mb for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:16:54 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa018cb-e002-0a2a0a5209dd-0a2a4505cc84-24 for ; Tue, 08 Sep 2026 16:16:50 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa018d2-4cb1-0a2a45050019-d155802eadbe-3 for ; Tue, 08 Sep 2026 16:16:50 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49b0dd3c9a0so45248615e9.1 for ; Tue, 08 Sep 2026 07:16:50 -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-49cee7fec25sm562374895e9.13.2026.09.08.07.16.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 07:16:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788877010; x=1789481810; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=vkFu4wHmCm79gU+WiRRgAh0ocsuf24N8LsJQC8PS9Ss=; b=O1C0M+3XTJXjvs6YwwePoDnJluQQKIJYxkcLvtP+P6Q7/vHmGh5gdsfn2yXMeWxEFG 2UNn0mygdWEJcqdzabS3pQu/itMLDKxs2u36S23U/UcG5r/3rc6n1RC9N+onzw5JeDD7 8QVIh0y1CfpWl91Jyb793Ug6EOjd+5t3K4ep58oFekDf3iY1pyrDbOkQMjAZEJZvdBJc dqQL1i1uyB84C6SWd0bbTmtAfc4Qo1N/2QnMhxnBRSMG1ASj5+bpSq+TwNJb4OfoIroR 4s+PYx4o9Ceobqj+CUq4a/8fJ8pC3Icy8Shmsnqeuu4EGL1RtImN40Uw90BxoCyaDmWG ZjKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788877010; x=1789481810; h=content-transfer-encoding:content-type: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:content-type; bh=vkFu4wHmCm79gU+WiRRgAh0ocsuf24N8LsJQC8PS9Ss=; b=f3tA/eusPjDD8mEw5QUjhRVAWRBo1uRK4TVawyYQh2YlFnzgkkiy1ZPsngLmn0ED+j 3kq3v5oZ6Abl7UwX9q1PNHfbEYya1OS9EV1ApiLlqxDfhwiSwUd59W7SgBJLT9WswR/1 YOm4ee4riT3Tzd8EWsCrhQ3+0Pyy7ImVM+PfRwu0HTQNXV5Spz40c//Vea/5FvjVklWL /WAPTJEwrmMZwOHHV4aLhbL0BNZ+ee1j2yxS0H6F7MDLOSAT6obzQPzCIE1GbCpueLcS TwICrwcKAlTE5HXUOh4SUhud6Ewu8CDGQLMw6egqWcsXSdDHEdo/GhwiYBAGzMPR/69v 00yw== X-Forwarded-Encrypted: i=1; AKwUvBwE+ceDG4ANudjO3yQ1mLFztEmF1mdZ7BP6f1qC/vNK1IGbbGyKW1AeV2Uc/9gvzIEgkO2jjj1B3ko=@lists.xenproject.org X-Gm-Message-State: AFuF++nfzETZJhM0DFcLQEBbUAD13O9EoXun5s0/Mqvqzz9eeDpV302n TDr+WTyWwhaj/JWLFHct+tYtYvqRAFzTVaj6B+62amAr7FBKkKcTeRCctUtgp7j4Kw== X-Gm-Gg: AYBFou2Nubok2JQ/x2rIKm2JYJ3YWAtoFzFeW+0u+c52GGpaXa1mSrR84H6wPvAo6PO Acqbr/dPAxh8AYy754bnQXg4CFCxaBX6adstflTlzxfk15ZRVKfCCCT3USIaVSZGu4Ekqb5oftl CIpWzAxVWy+9ClbLJR40kMFm15eGHPew4CecflfqgkmYaiUpPLkpycvDv2Yu+qo+Fm+xvyPDp6C Lp2tk2kpxa5yDP+uODG8bmrLzmb2emtUzmR7VOjcXbCZAZrfYh2YI8p2PNSvstrzXjRgJqkq9We +IDCSOkUUNoDZoHOvjAY1me7UQ+lr3xq0UG6ZJOXaBFJ1GiJNNuB4O45oDwXMD50r05nuLoNg/j I0fyLpjM6jIGMkegzn3JtVKFklo69MkffzCYa9xcnvUQJ2a55ldDmTYw8NtK17bAXmVJj1mX9fL rNG+iROecaWBG9BSaqQIr/ISa4INnDCeVvyePAjwHSIZoXUwFbgsPbJUDN8/7f0Ke5e6tGMseVZ bwuVdJN5y2N5ssGS/ZBCcBXa+eQ6adocRVYyigrmyGpj9wh X-Received: by 2002:a05:600c:3496:b0:49d:1deb:a629 with SMTP id 5b1f17b1804b1-49d1deba75cmr49158825e9.2.1788877009658; Tue, 08 Sep 2026 07:16:49 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 16:16:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.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: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788877010-F66B52A1-0899C172/0/0 X-purgate-type: clean X-purgate-size: 2882 On 27.08.2026 17:21, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -109,6 +109,12 @@ > #define SIP_SSIP MIP_SSIP > #define SIP_STIP MIP_STIP > > +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ > +#define STVEC_MODE_MASK _UL(0x3) > +#define STVEC_MODE_DIRECT _UL(0x0) > +#define STVEC_MODE_VECTORED _UL(0x1) As on earlier occasions: Do the 0x here actually add any value? There are none ... > +#define STVEC_BASE_MASK (~STVEC_MODE_MASK) > + > #define PRV_U _UL(0) > #define PRV_S _UL(1) > #define PRV_M _UL(3) ... here, for example. > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -294,5 +294,53 @@ enum mc_disposition arch_do_multicall_call(struct mc_state *state) > /* Redirect trap to Guest. */ > void trap_redirect(const struct trap_info *trap) > { > - BUG_ON("unimplemented"); > + struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current); > + unsigned long vsstatus = csr_read(CSR_VSSTATUS); > + > + /* > + * Redirecting a trap makes sense only if the trap was taken from > + * virtualized mode, i.e. sret is going to return to VS-mode. > + */ > + ASSERT(regs->hstatus & HSTATUS_SPV); > + > + /* > + * Only synchronous exceptions can be redirected. Interrupts must be > + * injected via hvip instead, so that the hardware itself performs > + * VS-mode trap entry, respecting vsstatus.SIE and the vectored > + * dispatch (BASE + 4 * cause) if vstvec is configured so. > + */ > + ASSERT(!(trap->scause & CAUSE_IRQ_FLAG)); > + > + /* Change Guest SSTATUS.SPP bit */ > + vsstatus &= ~SSTATUS_SPP; > + if ( regs->sstatus & SSTATUS_SPP ) > + vsstatus |= SSTATUS_SPP; > + > + /* Change Guest SSTATUS.SPIE bit */ > + vsstatus &= ~SSTATUS_SPIE; > + if ( vsstatus & SSTATUS_SIE ) > + vsstatus |= SSTATUS_SPIE; > + > + /* Clear Guest SSTATUS.SIE bit */ > + vsstatus &= ~SSTATUS_SIE; > + > + /* Update Guest SSTATUS */ > + csr_write(CSR_VSSTATUS, vsstatus); > + > + /* Update Guest SCAUSE, STVAL, and SEPC */ > + csr_write(CSR_VSCAUSE, trap->scause); > + csr_write(CSR_VSTVAL, trap->stval); > + csr_write(CSR_VSEPC, trap->sepc); > + > + /* > + * Set Guest PC to Guest exception vector. > + * > + * vstvec's MODE field is not part of the address. Exceptions always > + * target BASE regardless of MODE, so mask it off explicitly instead of > + * relying on the hardwired zero bit of sepc to drop it. > + */ > + regs->sepc = csr_read(CSR_VSTVEC) & STVEC_BASE_MASK; Nit: Given how much the comment talks about MODE, imo using ~STVEC_MODE_MASK here directly (and dropping STVEC_BASE_MASK) might be better. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 14:16:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 14:16:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412098.1642584 (Exim 4.92) (envelope-from ) id 1x3wd4-0003oj-8v; Tue, 08 Sep 2026 14:16:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412098.1642584; Tue, 08 Sep 2026 14:16:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wd4-0003oc-6J; Tue, 08 Sep 2026 14:16:54 +0000 Received: by outflank-mailman (input) for mailman id 1412098; Tue, 08 Sep 2026 14:16:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wd2-0003oW-JX for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:16:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3wd1-004mjy-PK for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:16:51 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa018ba-2eae-0a2a0a5409dd-0a2a4502cdc8-22 for ; Tue, 08 Sep 2026 16:16:51 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa018d3-6ca4-0a2a45020019-d155802dad22-3 for ; Tue, 08 Sep 2026 16:16:51 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49b0dd3c9a0so45248875e9.1 for ; Tue, 08 Sep 2026 07:16:51 -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-49cee7fec25sm562374895e9.13.2026.09.08.07.16.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 07:16:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788877011; x=1789481811; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=vkFu4wHmCm79gU+WiRRgAh0ocsuf24N8LsJQC8PS9Ss=; b=bvpyJzUd1Qnzl1skMzwhd0KyVlbZzGt7ceOCV9RXwyz1nUl0OskHiHJ1vRkbXL/brH qR/OdeSUsiN9d30ogJZGsv2rZ9dnt3oWaHjQ3vIeypFI7SWO8dolH6pMp4YwcfyKJ3jd pCwfV0lw9OBLWE2XH9wuDjSx2cEroKuFEtQ/FPJAvD5u0szjiP9+ScmnUMQLEbBbmpsd actaXF9NcYxDLNlEw/KxPIG+UhEIAnA9orrcvyWdcizNVgYuNgB+Z5Mc8if84vWl2sHe drWBi6ku5ZbNie5uFqR1gCkPRIcChQZyuva2vg8+o14XPIHnPMsx6YOILV9JFmIPp/8U T1kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788877011; x=1789481811; h=content-transfer-encoding:content-type: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:content-type; bh=vkFu4wHmCm79gU+WiRRgAh0ocsuf24N8LsJQC8PS9Ss=; b=ollSpty4pnPSbvY+px0lwCESWOilwyqvfqZys582OdgPUqbtCbthlQNMecPUG81jOe cuyrrw5WMo+Wf5pygee1dQ2CYHZV7SM+psNe9Knolx/YeTEMj/knZEHoyGIfPm19DBT0 XvYPXWGrdiH5TuKIpLw2os+5pIrlMlfOyT1N5Cj7DgYZcfEq3J6tezbzJHUnuFuAaQM+ QBh9lD3pfZS9JHaR08iu+5+CEJt5NKWbsBguYKYv0pryejNuuVOCW/V0lzdjGZDwAo5z yCA7J6BCgwnim0ldFgLQug89KdnhP20rM8YnlxFzoUCnM/wJ3A/sTGi1fYPNOArLY3uO bA/g== X-Forwarded-Encrypted: i=1; AKwUvByKX/8gXPkFxeO+05fviZS88cdGPv4zeq9EPDpT6a/e4Vijb3qZZpo5qmYsWZii83STq72cK1LtQGU=@lists.xenproject.org X-Gm-Message-State: AFuF++l81qSjMO4CELT46gGhT/JA7gkiQedyj5BDf/NDKbSwVw2B6Fcn fG1slZJj5sB2IQ98PBBGVLc3kAEUrjZgpSwx/jbvO3Eos0L3CCZ1h0ZQfxWU3pDvIw== X-Gm-Gg: AYBFou1km9X36/G4aS/lcGy/2vQAV9h4ybEee3JWx5j0KNXWPWlg1fbQ9zFj5flie9k 6h5WruSIc0kU1LR91SsVqr2dBy5pVbIMQYf/2uM+yE5NByENjGy6kQ2aZhkp+1wHMZuFxLIdQaL Dija0ESgDlSFn4FFPxDh9bWIQvXh5O5PPvTJsNjlSo1b7JVscNKjwhdj2pSUOx2P1Q0IFjYvzBT WS5yiPH+NLEck52XN8EJxyeMR2zMmjhKQKD3qmKeS9l08Tg6uJ0UZpXKVdqLCzj+xJKshPwK/8t DjJ/Iho/1hEsfc60BmN4IYnIDtd9oECf+jJHV7yiP4HzHvZkODdH4gZbPFZyR7AyuUbjjYDGd7c 0Ui6aPv2RnUbr2mog+5zOqmcRkRIruI7bjaO2XCgiVenuIU4f8Gw7L+quNBAY4Q6HiSeGsy0E4b JqTIKRCr4MBAV9DULY8xA7SHuk0mUh/ZsRFrJb0zFiMOYIoGuEuCf5E6/K/lu9pgJuFFq86r11y CnGlCt0NcWGPNy4hPBaItY+ua0UkL5yDDIRwRMMR0jejJBpdiIV X-Received: by 2002:a05:600c:6214:b0:49c:dca4:94c with SMTP id 5b1f17b1804b1-49cf825115bmr595119825e9.13.1788877011010; Tue, 08 Sep 2026 07:16:51 -0700 (PDT) Message-ID: <1afe58b5-feff-44cc-9be5-c4dc759b2d87@suse.com> Date: Tue, 8 Sep 2026 16:16:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.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: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788877011-F1CAA2AC-CD9490D3/0/0 X-purgate-type: clean X-purgate-size: 2882 On 27.08.2026 17:21, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -109,6 +109,12 @@ > #define SIP_SSIP MIP_SSIP > #define SIP_STIP MIP_STIP > > +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ > +#define STVEC_MODE_MASK _UL(0x3) > +#define STVEC_MODE_DIRECT _UL(0x0) > +#define STVEC_MODE_VECTORED _UL(0x1) As on earlier occasions: Do the 0x here actually add any value? There are none ... > +#define STVEC_BASE_MASK (~STVEC_MODE_MASK) > + > #define PRV_U _UL(0) > #define PRV_S _UL(1) > #define PRV_M _UL(3) ... here, for example. > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -294,5 +294,53 @@ enum mc_disposition arch_do_multicall_call(struct mc_state *state) > /* Redirect trap to Guest. */ > void trap_redirect(const struct trap_info *trap) > { > - BUG_ON("unimplemented"); > + struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current); > + unsigned long vsstatus = csr_read(CSR_VSSTATUS); > + > + /* > + * Redirecting a trap makes sense only if the trap was taken from > + * virtualized mode, i.e. sret is going to return to VS-mode. > + */ > + ASSERT(regs->hstatus & HSTATUS_SPV); > + > + /* > + * Only synchronous exceptions can be redirected. Interrupts must be > + * injected via hvip instead, so that the hardware itself performs > + * VS-mode trap entry, respecting vsstatus.SIE and the vectored > + * dispatch (BASE + 4 * cause) if vstvec is configured so. > + */ > + ASSERT(!(trap->scause & CAUSE_IRQ_FLAG)); > + > + /* Change Guest SSTATUS.SPP bit */ > + vsstatus &= ~SSTATUS_SPP; > + if ( regs->sstatus & SSTATUS_SPP ) > + vsstatus |= SSTATUS_SPP; > + > + /* Change Guest SSTATUS.SPIE bit */ > + vsstatus &= ~SSTATUS_SPIE; > + if ( vsstatus & SSTATUS_SIE ) > + vsstatus |= SSTATUS_SPIE; > + > + /* Clear Guest SSTATUS.SIE bit */ > + vsstatus &= ~SSTATUS_SIE; > + > + /* Update Guest SSTATUS */ > + csr_write(CSR_VSSTATUS, vsstatus); > + > + /* Update Guest SCAUSE, STVAL, and SEPC */ > + csr_write(CSR_VSCAUSE, trap->scause); > + csr_write(CSR_VSTVAL, trap->stval); > + csr_write(CSR_VSEPC, trap->sepc); > + > + /* > + * Set Guest PC to Guest exception vector. > + * > + * vstvec's MODE field is not part of the address. Exceptions always > + * target BASE regardless of MODE, so mask it off explicitly instead of > + * relying on the hardwired zero bit of sepc to drop it. > + */ > + regs->sepc = csr_read(CSR_VSTVEC) & STVEC_BASE_MASK; Nit: Given how much the comment talks about MODE, imo using ~STVEC_MODE_MASK here directly (and dropping STVEC_BASE_MASK) might be better. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 14:29:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 14:29:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412115.1642603 (Exim 4.92) (envelope-from ) id 1x3wot-0006Gm-L6; Tue, 08 Sep 2026 14:29:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412115.1642603; Tue, 08 Sep 2026 14:29:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wot-0006Gf-HS; Tue, 08 Sep 2026 14:29:07 +0000 Received: by outflank-mailman (input) for mailman id 1412115; Tue, 08 Sep 2026 14:29:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wos-0006GT-98 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:29:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3wor-00ASxI-0l for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:29:05 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa01ba7-8faa-0a2a0a5109dd-0a2a45029f92-10 for ; Tue, 08 Sep 2026 16:29:04 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa01bb0-6ca4-0a2a45020019-d155dd2ed9ae-3 for ; Tue, 08 Sep 2026 16:29:04 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-485850cf499so3112412f8f.3 for ; Tue, 08 Sep 2026 07:29:04 -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 ffacd0b85a97d-4858e239862sm31233518f8f.9.2026.09.08.07.29.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 07:29:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788877744; x=1789482544; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=LqPm/7OXv4D6CUb3M2PsRvj/xLPM7MkqPNPKCiLldDg=; b=Lf629HStqKGcpsla3/zE4BQiRFPi47MJEKFNdoZ24tqeQmDU89WBcg8ngLQLd6mFzs jsE5wjeRjZ2TZ1CVrjzAIsK7hchcO/5s/qA/XTsIRSuaW2nY4iviVjvbR7ov87po6uX2 6cuuiTN5i1+ilH1VbL2DRBmxXaxK3bsGfZYT/GPoI2A8vRYkFe4SLJYWTQ8GbLKSS6n5 K99Ry9ZokTwGhETMct6IJ787Iraud2yjXRa5+mJK5XHnqnhsO6o4i1P+OehYSLYzfC0V S9GCvDDcvxDogDDhVdmOZyDECcvrcRbFdE1djsguNgoX+PSPyd2t/UjAZiTZNkG1f3lt klmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788877744; x=1789482544; h=content-transfer-encoding:content-type: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:content-type; bh=LqPm/7OXv4D6CUb3M2PsRvj/xLPM7MkqPNPKCiLldDg=; b=shQ7DGf78v02U15aWm+uDduQtMnmiGzvl0XIb70iZecLlybPgvZ9ODz1nvGewyw0ca /Bmi/IRl5kT4vIfbP3WqgSpf4v8aWyiMswNW0CPJZVNYUCn3w/x1oSXj/ojc/aw4dDKK d42TMj1nBg8ad2avj+jHegskYelLa+SACc+bnswcnVuW8FfDQBjgE9lek+HycqivPd/i kqfERUAEw4wA41W7tqs2ForqlHadi/vmJnwk1trrpCjQwrsy1UGjv4uZfU9cbuv0dBio Y6C181MM79WhUO8oKK0pwxvC9kTyS9Zvk9yWndLPTiK7Ocrrg7b6AyVyHSQ5r5qOHyOf Xjbw== X-Forwarded-Encrypted: i=1; AKwUvBxtYzSbGXw6c0Ky/j+IMdcm33TaNrQ66sLMXKPHmKrb5Sw/k2B29vXNmerJLY5xQbY9YhiV0V5si6k=@lists.xenproject.org X-Gm-Message-State: AFuF++mwxLoKfeXf7l5EUNHQnV3WzwHm5yGxKaqnhrGmxyzsRrc2+zHH koEvhfomUfahIK66Zj8G/y0vSdkWYIthkumQBO9qmiT3o6oK7Dxmu1esg41R4YZdBA== X-Gm-Gg: AYBFou3uYMNJsafBvN3c4+bRbNKsVoX5PZEahOqL7bZzfNtHQiOG1MrWw34n1E+05FH HZj3jMbzeFIBnmydKN4m9Ol/X+yMYWJDKqRSX4lr0Dg6Yty+sb9wQaxTp6C/oxnwpr37bHYLksn w67FEFg0TYSdB8sF1Os9higjcrrmlUJZe0Ta6XbLUexK75ebsnzZ1Js61o1scC9p/NLYGN/mxyj D8vmcNXwc12F5998+qUPThxeBwDA4KWbmyvuHTANXU+17F0p0LoeDDRikDCUOXz3H8etRaQS4F5 lCD3m0hXE6FwTMmcD/YH1Mk3Oozve6CfOyneIVn5QMkHUrBZZsYsP5bQPJUgb1A4FV5VsWIz2nh pxVqVBxmgXBg6hoeHwvB2ZKqaFLAcL2jMOoSTCLsqwStenq8La1N1a1tZRoFcM8lmHovEy1lO8V 1Kv0+Zxslka5vDc+e8oMy4+XwsMK/hrq9HXomIJv4tGNsUSKpTp5DXNJIBGSVUABdiLmzAsbKd1 J93LDTWbfGzs4KzRc2PCxs0xMIfeMXAUn2nCXnhcTchoGsTGtEwm/sANk50f3g= X-Received: by 2002:a05:6000:25fc:b0:47f:e886:6dff with SMTP id ffacd0b85a97d-48587087196mr32260366f8f.4.1788877744289; Tue, 08 Sep 2026 07:29:04 -0700 (PDT) Message-ID: <3c5dab15-3daa-4941-a09a-29ca7d7a370f@suse.com> Date: Tue, 8 Sep 2026 16:29:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 06/14] x86/pv: remove stashing of GDT/LDT L1 page-tables To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-6-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-6-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788877744-F38BC2AC-53E9AA05/0/0 X-purgate-type: clean X-purgate-size: 1232 On 02.09.2026 11:43, George Dunlap wrote: > From: Roger Pau Monné > > There are no remaining users of the stashed L1 page-tables in > pv_domain.gdt_ldt_l1tab. Remove it, and all helpers. This removes a > globally-mapped xenheap allocation, and sets the stage for per-vCPU > root page tables. > > pv_create_gdt_ldt_l1tab() now passes NIL() rather than the stash > array. This will cause create_perdomain_mapping() to still eagerly > allocate the L1 tables covering the GDT/LDT range; but their addresses > are no longer handed back. Doing this is necessary because > populate_perdomain_mapping() only fills existing tables, and treats > missing structure as a bug. > > Another side effect of passing NIL() rather than a pointer is that the > L1 tables move from the xenheap to the domheap. Residing in the > xenheap was only ever a requirement when the stashed pointer had to > stay usable; with that requirement dropped, we can relax the > allocation requirement as well. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5 > Signed-off-by: George Dunlap Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Sep 08 14:39:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 14:39:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412138.1642631 (Exim 4.92) (envelope-from ) id 1x3wyY-0008FQ-Qi; Tue, 08 Sep 2026 14:39:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412138.1642631; Tue, 08 Sep 2026 14:39:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wyY-0008FJ-Nz; Tue, 08 Sep 2026 14:39:06 +0000 Received: by outflank-mailman (input) for mailman id 1412138; Tue, 08 Sep 2026 14:39:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3wyX-0008F7-5i for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:39:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3wyW-004N4E-Cl for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:39:04 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa01df5-bab6-0a2a0a5309dd-0a2a45089d02-30 for ; Tue, 08 Sep 2026 16:39:04 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa01e07-f659-0a2a45080019-d155dd31bced-3 for ; Tue, 08 Sep 2026 16:39:04 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-47f96c5b722so3339353f8f.0 for ; Tue, 08 Sep 2026 07:39:04 -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 ffacd0b85a97d-485885bfdf6sm37621260f8f.34.2026.09.08.07.39.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 07:39:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788878343; x=1789483143; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=u73mHx95QTyprz2OlvWoAsMRAPhleXlRiwoawDxfZog=; b=LN+SBbZY4zPtWjPb8RQkQ7Q97WehNpfjogmq7wqezRZK+Qo7tUoaJFMeBnlDKYieEC 3syA2ZuDthatUtn0i1sIq1dkK9nDWRxVH/8nKdn6YL1Tb8a4jCHLZo6wRXFSkLhY2uOW K5/jsV1wwNdmpy/ciJg9iwBcv7dxg6V/6pV1avWGSzMKOsS6S7Y5hkOa1yrJeV9PM6/w /DMchc/rjBpZn2m2JjYK5hQl7ZPML88WyGhXZ1aI56RyxvMKVvGspME2zSkIDFh1NGhE YX6I7MSLyAfI0VyY0S5s1s9nV482jgJDKxWH3XowWfi/2TqwFqAf9bbobz2L38OdGwm5 aQiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788878343; x=1789483143; h=content-transfer-encoding:content-type: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:content-type; bh=u73mHx95QTyprz2OlvWoAsMRAPhleXlRiwoawDxfZog=; b=f8TzZtkeg8rsthOZhmNOQG2fQiUIooBtY4Kjy+vzkxqXncS6nwjdH0pJWg9VcJgIQD EnWG3pmd+rEk27zJfiOhbzqCEwBsUw7q//tyJ3TtLvVIy/p+VbebP3iGJH8LHeNeFfSs wk6EQEKBCOu0t7cGweMBg2qujVN0qgmUuJOj3W2dpEq7+mCMXSrAWkg5kLdBQnwmbJ3A uERMmuIYmjmO5v2tnJTiYuIHUpSETu7elPkAOssGLBaV/7M2iTa+pM0E4CdCBwk8SsAs Itq6JIiWFNOv2ixeU5kjrMdV404M5lme3eODhSUqUzFdF/lgLlEKcvLOCPgSKD7ihRRV mD+g== X-Forwarded-Encrypted: i=1; AKwUvBzlO3Zk9P2Bu/M5Qja/geCCiT5oNHaYoPeZl8R9QjW28wtsVgE5OWWR+gvZ/LfdWYqfsyKAWgMhdQw=@lists.xenproject.org X-Gm-Message-State: AFuF++n3rddzSedY+co/JJCR5+09jrfiIWpXqvStZilmu+JMgYSAQyeK F757vRujShDyXzgCJL+/3xv4z5pywEQ6L08N3Ob8DFJRas9J79YRI+/gZKvgxcnT5g== X-Gm-Gg: AYBFou0k1fLqyE30OyFFmB1ZLjpq8lMF77ZKJuMP1SHrO7FNjvFb8/aC0T/SpypouHj Ej63k+0oUjQ/m7JjbyPDCWzdXvDY2++y9S3z81PhqdyD0VFc2x+e5u20kLT/bzTHH3raytlLcQo DyLf2bikjzrcsv0VMXj//3fkBqkDb6vsetIA4rOXOnl8HrfXflQvgAhlELZdBUxDzLh7zELtvkI ooZVy8QQ0IPm18O4UO5A1HH7Id6TygmTcsWPPliXsdecMauBkJdGB8Qu33XSmjjCrQo0uhM6qtj +5QKKSWjH+SwRL0sMgIFfYDkNk7gFNthdv+lPW3AD5JnRxnQpS1K2pfACAMTtFl36HROEtyVA+e +hS/nei4gLn8E6JwWGw1gcePmnREbAAneG4SFjiBc9bDmJUqP7ZyGeyePDgNgMRYpXQJDyv/Ugh d5xuUT6aJJXaavDC0Flokgch6mtDFFMiFJYwxIr8lu4trsiCTl4Lnn/JLcME89KCqrwqpSFty5E yTVNlDbiwsAHhh3QIToiHEFn2Es4ZWINJA/CVENfmh+cZjidLz+ X-Received: by 2002:a05:6000:4a16:b0:485:8a47:5b98 with SMTP id ffacd0b85a97d-4858a475d20mr27381493f8f.53.1788878343531; Tue, 08 Sep 2026 07:39:03 -0700 (PDT) Message-ID: <6a2b153f-e823-454c-a449-9683c76aae9a@suse.com> Date: Tue, 8 Sep 2026 16:39:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/14] x86/mm: simplify create_perdomain_mapping() interface To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-7-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-7-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788878344-D735D87B-22CE9049/0/0 X-purgate-type: clean X-purgate-size: 2358 On 02.09.2026 11:43, George Dunlap wrote: > From: Roger Pau Monné > > create_perdomain_mapping()'s interface is richer than any caller needs. > The paging structure for the requested range is built to a depth > selected by the pl1tab and ppg arguments, each of which distinguishes > NULL from NIL() from a real pointer: > > - nr == 0: only ensure the per-domain L3 exists; nothing else is > allocated, and the other arguments are ignored. > - pl1tab == a pointer: allocate the L1 tables covering the range from > the *xenheap*, and return their (stable, direct-map) addresses in > the array -- the mode that existed to build the GDT/LDT stash. > - pl1tab == NIL(): allocate the L1 tables from the domain heap, and > return nothing. > - pl1tab == NULL: do not plumb L1 tables for their own sake (they are > still allocated on demand if data-page population requires them). > - ppg == a pointer: allocate and install zeroed data pages across the > range, and return their struct page_info pointers in the array. > - ppg == NIL(): allocate and install the zeroed data pages, but hand > nothing back; the pages are reachable only through the mapping. > - ppg == NULL: do not allocate data pages. > - both NULL, nr > 0: stop after the slot's L2; do not plumb L1 tables > at all. > > Very few of these modes have users now. The last user of the > pl1tab capture mode was removed when we removed the GDT/LDT stash. > The ppg capture mode never had any users. Nothing uses the both-NULL > L2-only mode with nr != 0. What remains is exactly one bit of > information: whether the caller wants the range populated with zeroed, > area-owned data pages, or merely plumbed down to the L1 tables, ready > for populate_perdomain_mapping() to install caller-owned pages. > > Replace the two arguments with a boolean expressing that bit. With the > stashing mode gone the NIL()/IS_NIL() macros lose their last user, so > drop them as well; and document the resulting interface. > > No caller changes behaviour: every existing call maps onto the boolean > exactly. > > Signed-off-by: Roger Pau Monné > Assisted-by: Claude Code:claude-fable-5 > Signed-off-by: George Dunlap Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Sep 08 14:58:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 14:58:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412151.1642649 (Exim 4.92) (envelope-from ) id 1x3xHK-0002vu-Bb; Tue, 08 Sep 2026 14:58:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412151.1642649; Tue, 08 Sep 2026 14:58:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xHK-0002vn-8s; Tue, 08 Sep 2026 14:58:30 +0000 Received: by outflank-mailman (input) for mailman id 1412151; Tue, 08 Sep 2026 14:58:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3xHI-0002vh-65 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 14:58:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3xHG-00AXWe-PM for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:58:26 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0228f-2eae-0a2a0a5409dd-0a2a4505a9d6-14 for ; Tue, 08 Sep 2026 16:58:26 +0200 Received: from [209.85.218.50] (helo=mail-ej1-f50.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa02292-4cb1-0a2a45050019-d155da32c5f5-3 for ; Tue, 08 Sep 2026 16:58:26 +0200 Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-c259e5c22ffso416745066b.1 for ; Tue, 08 Sep 2026 07:58:26 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d036674sm643829866b.8.2026.09.08.07.58.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 07:58:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788879506; x=1789484306; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=JEmh4Lqec1cy1UW024Cm5lr7aE+xJUksKB82LS3mPow=; b=QTy3i46yJAuPmbVno4X7beKLmxwgIPFaSR/6kwvXODid3eFAaekXohOsPfhrpsOVTp itrQJAqoEEJIcWxvUhTeo4zj8amb8z9xVmQsr/8kDq9ChHNvy87AutIqJI5o1hDgI+Q1 GaodtMx9FaXF2x7R8PWNcIQPn9F6pmVOFJpqXfpOu3r2FHZtQqM1/mIjv+ziayV7gkh/ Ts25Vzoo5+BN+tcmj6LTUgj8L8YvA0GbWWap1FczXhz3Np4o02NQoN5VB9EQu2mMgKEM lURcqO/QLdTRyaOYS2pb1lpS7MyRmemxVeKlmXzPqDSUzhxJBspplpduCe4LZYRgrXIc tqEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788879506; x=1789484306; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JEmh4Lqec1cy1UW024Cm5lr7aE+xJUksKB82LS3mPow=; b=aME9jm/yFw5SXZtXmlekxwFOj3aB4By+64BOOnSeJS8KInOtIpRTGcsT2OFCVjJqnn /a7vV1Sht7iEMTP9iB58dxUR4tA+0yHIIXTBYGkhgPvfnVmzEuy0cHtzJVUcgk4WU3tH xluQ8lyAVs9xEh8yUX48XnVsEqtwVDiOIMnDTbd/a4KyOcgzj0dQ5swGbIUP0vYg3Kzd b/SNhmPQdzbpKmothKvsrCKLLeY9thV7yppNgrCY3SMWHzi/yksy6UMPeI+pQNST7yXK YKe5xK890RXTg7ySeaTaMyZmfR0BQ98K4zOQmg5rNzRjvOvbWV+DoTEXmZjvo6vF+s8r 5fbg== X-Gm-Message-State: AFuF++neXjiuviF+JBV1dGjGrIEjNCzG3nG+OEWdsIx6m8KklIGTZgeS bLtq/dhy9laKMTzgIo+fuLaQGz3zE+RsztykMzw0DSoeSRVU4TRteE/j X-Gm-Gg: AYBFou1W7/qbdDr89E+pY0U2S81quXMffUjMEP/itLb0Zwe7rL6JyTMOlFGUbjHmlLM uGSo2gzZHAcE/SA4p1Xr8FBpUqFljIEpUoaHoE657aJ8sWRCLzIdIiYc7FLPJ8swD6PvTPsz1ur MZztLR06YECXT+8do+f/QDEHPGeE4ONPsPyyyvmO/MafS6KfjatUIbD2KTnme09J8Ja5mUCXQHw SgSQJe3/xWdMabyJFgMWGdU4SXxFOQl2v1DJqoWdx9h/5iBr4+sdAcRcap0NCphLYbPu0wCTzB8 w9ieu4SsRRB9EjkLbgmOrdiD9ilwXGMUAREgpkIR8DYscUIVC+rgCTZbg+v7i2s1tMJmrImnnHX al5T3UI79JqkQb7Z4V82k2z0Sc7ILDs8/2Y3FSulj7nCMuPjL9MpTyb0nVJ8ZKZwyUSMrnzOz8d TJ0lW3hvS8u3Frn2n8bSFZ4nN0UG82uDWnYgjbO/26gfk0PHVr3RVmQLZ9hmhv5DN7N3q8ggesG jN1zZD0Vhc9vdhQX7KgibA= X-Received: by 2002:a17:907:9709:b0:c1c:4e36:eec6 with SMTP id a640c23a62f3a-c260ca22ce1mr1187731066b.18.1788879505883; Tue, 08 Sep 2026 07:58:25 -0700 (PDT) Message-ID: <72b89a0c-ad0e-4c1d-97f7-92f49ede7a55@gmail.com> Date: Tue, 8 Sep 2026 16:58:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest From: Oleksii Kurochko To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> <1788796634.8631fc262581453bbf619ec5b2062170.1a07c96862b000c4f3@vates.tech> <2f734f0a-7f3e-4e27-82ed-52ccf72fe49a@gmail.com> Content-Language: en-US In-Reply-To: <2f734f0a-7f3e-4e27-82ed-52ccf72fe49a@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1788879506-F76BD2A1-40ADE2DA/10/73395122804 X-purgate-type: spam X-purgate-size: 4719 On 9/8/26 12:01 PM, Oleksii Kurochko wrote: > > > On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >>> Some traps taken by Xen on behalf of a guest can't or shouldn't be >>> handled >>> by the hypervisor and have to be reflected to the guest's own S-mode >>> trap >>> handler instead: the access faults which handle_guest_page_fault() >>> injects >>> for a fault that can never become an emulated access, and, later on, a >>> fault taken by the hlv/hlvx sequences of riscv_read_guest() while >>> accessing guest memory on a vCPU's behalf. >>> >> Access faults from handle_guest_page_fault() aren't "taken by Xen on >> behalf of a guest" as those are guest-page faults taken directly from the >> guest's own execution. Xen just decides they can't be emulated and >> reflects them back as access faults. Only the hlv/hlvx case is Xen >> trapping on the guest's behalf (Xen itself executes the faulting >> access).> Conflating the two under one description makes the paragraph >> confusing. >> >> Suggest splitting into two: >> >>      Two kinds of traps can't or shouldn't be handled by the >> hypervisor and >>      have to be reflected to the guest's own S-mode trap handler instead: >> >>      - Traps Xen takes on the guest's behalf: the hlv/hlvx sequences >>      riscv_read_guest() uses to access guest memory. >>      - Access faults handle_guest_page_fault() injects for a guest-page >>      fault that can never become an emulated access. > > Thanks, I'll update original paragraph with what you suggested.> >>> >>> Implement trap_redirect(), until now a BUG_ON() placeholder, for that >>> purpose. It makes the trap appear to the guest as if it had been taken >>> directly in VS-mode: the trap information is transferred to the guest's >>> virtual supervisor CSRs and the vCPU is resumed at its exception >>> vector in >>> supervisor mode, following the trap entry rules of the RISC-V privileged >>> specification. >>> >>> Add the STVEC_* definitions needed to tell the BASE and MODE fields of >>> vstvec apart. >>> >>> The implementation is based on kvm_riscv_vcpu_trap_redirect() from >>> Linux, >>> with a few deviations: >>>   - The function reads and writes physical VS-mode CSRs, so it is only >>>     meaningful for the currently running vCPU. Instead of taking a >>>     struct vcpu argument, it always operates on current. >>>   - The MODE field of vstvec is masked off explicitly when computing the >>>     exception target PC (exceptions always vector to BASE), rather than >>>     relying on the hardwired zero bit of sepc to drop it on VM entry. >>>   - Assertions document the preconditions: the trap must have been taken >>>     from virtualized mode (hstatus.SPV set), and only synchronous >>>     exceptions may be redirected - interrupts must be injected via hvip >>>     instead, so that the hardware performs VS-mode trap entry itself, >>>     respecting vsstatus.SIE and vectored vstvec dispatch. >>> >>> Signed-off-by: Oleksii Kurochko >>> >>> diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/ >>> riscv/include/asm/riscv_encoding.h >>> index 2d2e7e11b3..b2071f4758 100644 >>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >>> @@ -109,6 +109,12 @@ >>>   #define SIP_SSIP            MIP_SSIP >>>   #define SIP_STIP            MIP_STIP >>> +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ >>> +#define STVEC_MODE_MASK            _UL(0x3) >>> +#define STVEC_MODE_DIRECT        _UL(0x0) >>> +#define STVEC_MODE_VECTORED        _UL(0x1) >>> +#define STVEC_BASE_MASK            (~STVEC_MODE_MASK) >> Nit: STVEC_MODE_DIRECT and STVEC_MODE_VECTORED aren't used anywhere in >> this patch (only STVEC_BASE_MASK is). Either use them where you decide >> exceptions always target BASE regardless of MODE, or drop them until a >> patch that needs them. > > IMO it is fine to introduce *_DIRECT/VECORED here as they are used > implicitly through STVEC_BASE_MASK and thereby it will be better to > introduce them here now instead of open-code them and then just update > STVEC_BASE_MASK again when *_DIRECT/VECORED will be re-introduced. > Oh, sorry, you are right. STVEC_MODE_DIRECT and STVEC_MODE_VECTORED are really not used here (in this implementation). I planned to do: #define STVEC_MODE_MASK (STVEC_MODE_DIRECT | STVEC_MODE_VECTORED) But I missed to do in that way. I will update the defintion of STVEC_MODE_MASK in suggested above way. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:03:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:03:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412159.1642657 (Exim 4.92) (envelope-from ) id 1x3xM6-0004Zx-08; Tue, 08 Sep 2026 15:03:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412159.1642657; Tue, 08 Sep 2026 15:03:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xM5-0004Zq-Tk; Tue, 08 Sep 2026 15:03:25 +0000 Received: by outflank-mailman (input) for mailman id 1412159; Tue, 08 Sep 2026 15:03:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xM4-0004Zi-Nw for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:03:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3xM4-00HZYe-2c for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:03:24 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa023ab-e002-0a2a0a5209dd-0a2a450cd188-24 for ; Tue, 08 Sep 2026 17:03:23 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa023bb-f479-0a2a450c0019-d155dd2cdda3-3 for ; Tue, 08 Sep 2026 17:03:23 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-482f9309813so4410387f8f.1 for ; Tue, 08 Sep 2026 08:03:23 -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 ffacd0b85a97d-485aa2c9acasm870243f8f.36.2026.09.08.08.03.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 08:03:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788879803; x=1789484603; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=nDB8xtTNhXauDE129EoyiIX+KnpI6yb74jUIYhx9piY=; b=TIX4arOI455RnnDfjQKwvmhnWdbdIwCVhrHwq9iMv8/56GVzeGBVZ35HZ9Oc+Jz2IR SssFFFA+pV8Z4pev5q1tXSKh+NCIM4tJmKWR6KFR1JqN4Vt0qaaEQ5q3CHKMcAqju0gE uPD0KMDHn7tnrSntp8svF4INJPPl832AaTO3rt1dRkMq5+1C/9v16zjkyEQMnQK88PhE emp4FApizMH43N5Px1ZMZOp+wwXkhtVK0HT551MOO8m5Wsk3zCIwt/5cOKgB+9MN0j2k RekdMExuHnYifxhnkeL2j7Kk75Rzfr1GW85rjJsl5nQqJNwzj6YqbKfh/a0apn8iNy7a sHwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788879803; x=1789484603; h=content-transfer-encoding:content-type: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:content-type; bh=nDB8xtTNhXauDE129EoyiIX+KnpI6yb74jUIYhx9piY=; b=aKKPGYmsJRMuqu1xf/VrWLROaNnBQ6xiO35mWDBAP0W8OuRPS/8gNg16sEyq0UcAWn +wb8rLe/63ogY0QlikGxd8MkeBAa28uyJcsp6HvjMJ2imwVGxSdsOPKq4vrEF2/ois+5 +zs9AS4zwPoF0HzVVzJFHPIof8EFjONzV5NTr9TZO9IZ9hHMZigEXGPKjsmnQ4bequWA U+lND+geyFAcya4zd6dDalJnbK1Mcu/dxzu2Ua8YxYfV/d5OoEnmKIA1mmC5mCwYa49w MqgzcMwcjIamkb3SUEC4LhbPS1lAKrxvwJKxC6cgksJkNICRgaiD7qZMMizlEFeGHvzW 9qOA== X-Forwarded-Encrypted: i=1; AKwUvByECdQXJ7hxfysKIiheDFz8wGiYP82XNgUUQ7tWDsRKZPVwZmAv4K7H1wNJq1MAnVaUeTntXlWMB00=@lists.xenproject.org X-Gm-Message-State: AFuF++nFM5+9ndqF8QPlTzXOWGazlIJ/U/jr1gk6KluTD98i4Qp/Um7T zXcolVIHX1nHXDJfw/6s7bcLoEXSGcgtHiwM7U0Y4HzwzkE1hKySC9XRyoZdFo390g== X-Gm-Gg: AYBFou37s7Bk7r2h9E0LR3+89YES+U4YJH15GcMJBCzYM3wj7aYQIoTJgSocTAJrX0M p+ybYtcpIMjJvFaG5fHnxAxW+qIPf4oKp9/FAYEeBCxJ4kaTsVdqYfYI4b3Zi2bVXPfL4g4dj22 FRq89OHWfx9HotOfkR93H219f3aOo2+e3I7NtVBeafh9iiGjI8uEtpjxaUrI2FrDKMvj3VJisNi QNNnbO9PxhqYQg+985N7U3GiOcwPrZsi05KjCbqLr49ducYU0iQ/N1gV59e6+XC/Wd62NP2DseV OiJkfNafv0974OEFU7J4mfiYj1/BIj3sDSKYPn2CZ/GlMRBHiFPzO4+Lvkne9IdB4uyb9vRWeLb 0p8hpNj2SNH7rJyMZF0EqBBGb6VzhH1se4yCiX7asNlEnYV7UNLbyVyUmaFgEPJG2fbGnbW04uj Tg2PdEhk172o3Rn0fSmN+xmIZi3UjNZJxUzcM9T5txKX/iqa8UqH/0Lr/IIeHY2Qb9kXp08fu3J dGqblJBEL+GyvgAFEF86zL1gDzjqEbdm6jRAdFvVIZkz0t4iQp9 X-Received: by 2002:a05:6000:4601:b0:485:8c16:5ef8 with SMTP id ffacd0b85a97d-4858c1660eamr25700983f8f.50.1788879803278; Tue, 08 Sep 2026 08:03:23 -0700 (PDT) Message-ID: <77fa3707-d224-4690-8cdb-0dbe703d853b@suse.com> Date: Tue, 8 Sep 2026 17:03:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/14] x86/mm: purge unneeded destroy_perdomain_mapping() To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-8-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-8-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788879803-50520A5B-E1685535/0/0 X-purgate-type: clean X-purgate-size: 1672 On 02.09.2026 11:43, George Dunlap wrote: > From: Roger Pau Monné > > We want to change per-domain mappings to be per-vCPU mappings. In > preparation for that, we want to arrange that > destroy_perdomain_mapping() work either with a single perdomain area, > or with a per-vCPU perdomain area. > > There are two calls made from domain-scoped contexts; both calls turn > out to be unnecessary: > > - destroy_perdomain_mapping() is not logically the undo of > create_perdomain_mapping(), as the name and its use in > hvm_domain_initialise() suggest. create_ allocates a per-domain L3, > but destroy_ tears down mappings without freeing it; and since the > call here passes nr == 0, it tears down nothing at all. The > per-domain L3 page is actually freed by free_perdomain_mappings(), > which hvm_domain_initialise()'s caller, arch_domain_create(), > already invokes on its failure path. > > - The call in pv_domain_destroy() is redundant: arch_domain_destroy() > unconditionally calls free_perdomain_mappings(), which tears down > the same entries and additionally frees the page-table structures. pv_domain_destroy() has a 2nd call site (the error path of pv_domain_initialise()), but the situation is the same there: arch_domain_create()'s error path also calls free_perdomain_mappings(). > Signed-off-by: Roger Pau Monné > Reviewed-by: Alejandro Vallejo > Assisted-by: Claude Code:claude-fable-5 > Signed-off-by: George Dunlap With the description amended: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:05:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:05:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412169.1642667 (Exim 4.92) (envelope-from ) id 1x3xOU-0005CG-Bt; Tue, 08 Sep 2026 15:05:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412169.1642667; Tue, 08 Sep 2026 15:05:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xOU-0005C9-9A; Tue, 08 Sep 2026 15:05:54 +0000 Received: by outflank-mailman (input) for mailman id 1412169; Tue, 08 Sep 2026 15:05:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xOT-0005C3-CQ for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:05:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3xOS-00DlmT-Fy for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:05:52 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0244c-8faa-0a2a0a5109dd-0a2a4504c984-12 for ; Tue, 08 Sep 2026 17:05:52 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa02450-b57f-0a2a45040019-d1558035d033-3 for ; Tue, 08 Sep 2026 17:05:52 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49b392ccaacso70586715e9.2 for ; Tue, 08 Sep 2026 08:05:52 -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-49d07a23e85sm284549695e9.5.2026.09.08.08.05.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 08:05:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788879951; x=1789484751; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=4+MXLPBiJokAR+uDH2BKPAQ1ps4nAD/H6MbmfGExJ7g=; b=PnaLqdlT3RaBqSRbZofpHiMtsjUy6j3M6XakavjnZG/j//VBp01Zmc4NYn6Vi0YaQv 7WejhwFE8RzDVl8BTjckTKWG9M4PtPZaj8gD3LJGI+pCzDarM+9Xyyva1+XoeSY6vel9 upjU7oKqCE37sUh5xO3z2+KQWJ2yCybW6tFzVRjdlMGCeMW5uxN3AUBXUpdo+I3f9jYI EO2MjuqaoxUzj7BvEqniNIxR4SSH3hbb5E+H0+jSDinDcYxAxQB32i3yyLIdi2Xbzdvt WXf8ZVX5wYeHQ4gAj/j1CqVbYvA7L880Q9iHOY2QPB3hmrq5JO4crUKXYjNSQIiDQuuV vDBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788879951; x=1789484751; h=content-transfer-encoding:content-type: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:content-type; bh=4+MXLPBiJokAR+uDH2BKPAQ1ps4nAD/H6MbmfGExJ7g=; b=fX9rdL2vvkzWdtjM5qr6qB4+C0I9NQdDFXVg+WiqKuJSuO+FVwXjroc2ssRmiCNG/Y F7W386yz12npjOL2norNr5h9EfsVdUMudX2DQvx+8juX1419BOLH7rqBxsztCjJc9ka0 507fS9fHUE8fmnYEpj7IaxdtsxsXSP/ehENqjEJqyDwRyH4o2rYppAbKHNQiSnF/5G39 ks5c8JEBGLFwfM2lYsTPXEMBcCfVZgYfbZXPdL4hMHKBNWO13sH7HdE7xYmnvBB46lIo MB8bqYOkG426pMra39tsBR06xuT5Bse23bUp56/W5YFlVxWm1wpWQpt4zUMuB3V/W3Vu Xthw== X-Gm-Message-State: AFuF++mu60nI9+yAXK9VsKgdm5ayLqdhfKMAW9AmWJhHOzjAcXD/WdD5 9pney9OvFsvndfqA4gWh/EV9IGosK6jqiyaPqQCYgc3v6a0PF28yT622Yp4MjQQ5LQ== X-Gm-Gg: AYBFou2OSfqFqnUpV6WOkbXK+S7Da9RZhl9AoLIu5y2J4QxS5xoIPReVbgvwOT3jtdk NXitHQkbLk/4sZaKlMHPLJxXFa4nkxrcaryjosrY2hEfDUcEFhS1PNaIuyFZvX0V1Ya0lOgC5BE bz/WY2JYcwoaCyWPpO6+cI33g1kEn2f8sLVzLrKX1L4SHC+9DZ9pS1uOM98iBzuHrBgDgn0zicr V8fZrx5a72oKNroGwq4vq2NdVuCCFIUG7nNcRJVD6YMPL+MR7aOMZ+4xqMG061vffSg7PB7ep6H GatQB+Vp1mYEOsFTMP/dar1K1zGIT8keC6Ghv0l2DjmG35npyFbCO0XiGLMnCADhQGut7EWbjtD 0tVWdVrTvoXmdKWJeunXK+u+xrJz457qyEmVtO4XQRNV/qXcBqKykB/C4BSdlmikQpMtxyAaj3r CrxZdF7mWcVTtNMA41Jii46B9F9KDNZFfbKG9U24wSLkH0svls8lNCh5oT2SI9dCtg5qooqNHK0 bWARexu2DjW9UPDEep2s2XgqUjNM7rXhTJG/nzX2QfAgvF9477U X-Received: by 2002:a05:600c:3f06:b0:49d:1cc3:fa9a with SMTP id 5b1f17b1804b1-49d1cc3fde0mr34132975e9.14.1788879951576; Tue, 08 Sep 2026 08:05:51 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 17:05:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> <1788796634.8631fc262581453bbf619ec5b2062170.1a07c96862b000c4f3@vates.tech> <2f734f0a-7f3e-4e27-82ed-52ccf72fe49a@gmail.com> <72b89a0c-ad0e-4c1d-97f7-92f49ede7a55@gmail.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: <72b89a0c-ad0e-4c1d-97f7-92f49ede7a55@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788879952-536C2B50-1EA30396/0/0 X-purgate-type: clean X-purgate-size: 1723 On 08.09.2026 16:58, Oleksii Kurochko wrote: > On 9/8/26 12:01 PM, Oleksii Kurochko wrote: >> On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >>>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >>>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >>>> @@ -109,6 +109,12 @@ >>>>   #define SIP_SSIP            MIP_SSIP >>>>   #define SIP_STIP            MIP_STIP >>>> +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ >>>> +#define STVEC_MODE_MASK            _UL(0x3) >>>> +#define STVEC_MODE_DIRECT        _UL(0x0) >>>> +#define STVEC_MODE_VECTORED        _UL(0x1) >>>> +#define STVEC_BASE_MASK            (~STVEC_MODE_MASK) >>> Nit: STVEC_MODE_DIRECT and STVEC_MODE_VECTORED aren't used anywhere in >>> this patch (only STVEC_BASE_MASK is). Either use them where you decide >>> exceptions always target BASE regardless of MODE, or drop them until a >>> patch that needs them. >> >> IMO it is fine to introduce *_DIRECT/VECORED here as they are used >> implicitly through STVEC_BASE_MASK and thereby it will be better to >> introduce them here now instead of open-code them and then just update >> STVEC_BASE_MASK again when *_DIRECT/VECORED will be re-introduced. >> > > Oh, sorry, you are right. STVEC_MODE_DIRECT and STVEC_MODE_VECTORED are > really not used here (in this implementation). I planned to do: > > #define STVEC_MODE_MASK (STVEC_MODE_DIRECT | STVEC_MODE_VECTORED) > > But I missed to do in that way. > > I will update the defintion of STVEC_MODE_MASK in suggested above way. But that's yield a mask value of 1, when you want it to be 3. That ORing together looks bogus to me anyway. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:14:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:14:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412181.1642695 (Exim 4.92) (envelope-from ) id 1x3xWK-0007Jx-9i; Tue, 08 Sep 2026 15:14:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412181.1642695; Tue, 08 Sep 2026 15:14:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xWK-0007Jq-6v; Tue, 08 Sep 2026 15:14:00 +0000 Received: by outflank-mailman (input) for mailman id 1412181; Tue, 08 Sep 2026 15:13:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xWI-0007Jk-C3 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:13:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3xWH-00007V-8r for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:13:57 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0262f-e002-0a2a0a5209dd-0a2a4501c81a-18 for ; Tue, 08 Sep 2026 17:13:53 +0200 Received: from [40.107.201.60] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0262f-5984-0a2a45010019-286bc93cab53-3 for ; Tue, 08 Sep 2026 17:13:52 +0200 Received: from MW4PR03CA0030.namprd03.prod.outlook.com (2603:10b6:303:8f::35) by CY1PR12MB9626.namprd12.prod.outlook.com (2603:10b6:930:106::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Tue, 8 Sep 2026 15:13:43 +0000 Received: from SJ1PEPF00001CE0.namprd05.prod.outlook.com (2603:10b6:303:8f:cafe::a5) by MW4PR03CA0030.outlook.office365.com (2603:10b6:303:8f::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Tue, 8 Sep 2026 15:13:42 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00001CE0.mail.protection.outlook.com (10.167.242.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.5 via Frontend Transport; Tue, 8 Sep 2026 15:13:42 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Tue, 8 Sep 2026 10:13:41 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Tue, 8 Sep 2026 10:13:41 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Tue, 8 Sep 2026 10:13:39 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uVea7vsCiCXyNGoqBSO3Ybt1VOOyz97nD10TvRCCuLvfV0mgosqFuDRevEX2+PcFBqLIJzX3sDCbgdUgvtOQHE6N9GESnN3eL/sv4cKy3DN0pScmvuY/TZ05M2wjfavNnDwN9wP+PRAem83+HlCeO9YqftwcPZixs+i7kQuUUKYCihO4K4BlvqB4AXFynkPB0gM9Hhy+9PBfwwHeaMpVyNm1v1P6zFvK76qk2gibYN5qvxrEHysdxlSMDzmchEKDErdbyjc2RlkqLJC0GaOH8W0B7shv4yZAs5yNFXloGUawlYgV+DhNwobSfUCQec0WkmQhvuUm66CqeuKFVgYHpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ymwuSxIc8L2A0aZh0nJQph6+TFrsfQpORWoS/czfQVw=; b=FOt5Mx5ciD2h/dva5eb57IVLY97erlUT18+ZpPEbMl1MoaTV4vHInCdyc8/cJy0Gr0z2NqKHhMkNqOZQHRn2893DpjzTPfcfasIYCSJjkGPGHv7zyEWi6dQz0VsSRdZQ5Y/OZ0uJHDhfVI9/q84BGd3e1uRK8n8BRs2Cs3Za16ySXTKu1lIMVxWzyjLbH3OBQ0Jbih5jJPaaqjnja9w6m8kSPD5tlqkrYJENx4j13sSxJ+SniyfBI0/lGISiuJ9rmlW1LN/ENzfUdUPbJQagOemcWM/fZwYuddPLuX4TX3ui6KsRNAWwEYBAC5qb8pwKwzR2VqIInviTHH7K97A64w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=valinux.co.jp smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ymwuSxIc8L2A0aZh0nJQph6+TFrsfQpORWoS/czfQVw=; b=Baul8iN/YbUQw9xvpxtRjJfT5Tz7UUJfotiKlzoemEhihcK1Z8uaFVetlta8DIkrkATGUUjUG+03RRX2x8KW0N4pDZWa3jPnHkqYIicpysW+VcW/1J9abdHmAsqqA6RbqwtTmayAFx6tUnP8vyI8DOb4HgU+jllVvgSGPNnLdfs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <47b25166-c689-4e31-a161-f68001ca777b@amd.com> Date: Tue, 8 Sep 2026 17:13:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration To: Hirokazu Takahashi , CC: , Jan Beulich , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260728050642.411240-1-taka@valinux.co.jp> <20260728050642.411240-2-taka@valinux.co.jp> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260728050642.411240-2-taka@valinux.co.jp> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00001CE0:EE_|CY1PR12MB9626:EE_ X-MS-Office365-Filtering-Correlation-Id: fd897239-4a0d-45db-c8e6-08df0dbbc4ea X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|82310400026|36860700016|23010399003|1800799024|6133799003|10067099003|56012099006|4143699003|11063799006|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: sWW9iV/m2XOwf7rHjomEJpInUoxTEfXy+QesBvcxiNDXQefPCZBH+9T4CmECZZxa3kznyyu2cVC+ec8HMyXk9yS8FYWV15QPXakVN+PhPFF1cyvGwOR/DRDSP45Pt0ko+ntZlak3xlMlCgtni9gcP8Y+SOo5sGmFqI7GGX5Wa6mayFJ3Cbyf+pA8bqJszSX/I70XtE3s/HJt7vGoHyc1LxuNPhyfUKxPBaI2KHQGp3juZmPQHDZeshYoJFmXThVAiJp/e/mounOZO/4sLoY/NMhnhNPBQDv5SyeCXvH92TqSbc1rfSa9XDxxfToRnNCVzfQHrAbYJr0Cdfi8UMZTM+Grovc4LjWpR2Fx6JdDhbdqvfO80IednOQw7AeVFzcR+cZ4x/nVTGLZETDRHTlZ9t2pjrChFHu++OCrp2UWAqNnJiDa3OE0duEV2no1KgaaoqTd2MN+aisoV4ys/jwqCn5dDct3v6HmTS4GCiVB4u2iRlPt6l7l/ttYRAb5R3C7PvhwW4YCMk0mtaA1duE+vhUlnbhtK1gZb3jSW5Ofy7bdoePDhbAxUPACEFKGPI9o7rveMEtH1J/OdHeyN3/ti+lGhj8wuv/G70AuZU3IL4BVL5OgTVd6Md1Vvt0ch3TQPCxKGnarIARmKf/x0M7SvYrsIXi1T3iDZhzjTIe8szV+ssX6cP3hZCH5Ut89Ogi0/glnwvzDyw48feNdczQvVg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(82310400026)(36860700016)(23010399003)(1800799024)(6133799003)(10067099003)(56012099006)(4143699003)(11063799006)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Qd06SUolGVtV0epTA2+cwGkelf6kYR8fMqFwrJYEiAyqYtOKNwpJRxeCMIcl2wK9QXUuMpdNIuJJzllco53XHSvHs2cTzvDtt8Q7WjQxflOky0rqDUiMftJ8mSv7STIBY3VokY9nms28ggOHpfC9ymvFqA8GzvV8j5zpx4J5rG3koYf9LZQuFMlrI7YJxxaE4hZLhkN8l1EDWkD6sd11+DK17O7IBEy3p5X1d1wOn+cUhj8xg+97wfPX4tR970VnIMN+Tgkzlz0+uDWcOQeYknRHAmg56fugGFYyNeJhvxRgst97mP0WJU/rw0K1HaD+NxWtynM3sY2j/fxH+rctQ7YOHt1RL82R+U9X6afFCv9vrgxZkTi1IN1eHBVkG2zuy4jLdwmiXiJ/jOzAA+c1QFgMF4GgXBjl8fVbv8cw9mOGJIT63PfN9qVe2wS3dMOR X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 15:13:42.2946 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fd897239-4a0d-45db-c8e6-08df0dbbc4ea X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00001CE0.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9626 X-purgate-ID: tlsNG-d62444/1788880433-1D87F757-77D357BC/0/0 X-purgate-type: clean X-purgate-size: 19457 On 28-Jul-26 07:06, Hirokazu Takahashi wrote: > Parse the 'cpu-map' node in the Device Tree to extract CPU topology > information. If the 'cpu-map' node is absent, fall back to > generating the topology data from the NUMA information. This > generation assumes exactly one socket per NUMA node and that SMT > is unsupported. This does not seem to reflect the implementation. If there is no `cpu-map` node, you just return error and free the table. > > Signed-off-by: Hirokazu Takahashi > Reviewed-by: Jan Beulich # common, acpi > --- > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/smpboot.c | 7 + > xen/common/Kconfig | 22 ++ > xen/common/Makefile | 1 + > xen/common/cpu-topology.c | 62 +++++ > xen/common/cpu.c | 5 + > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/cpu-topology.c | 344 ++++++++++++++++++++++++++ > xen/drivers/acpi/Makefile | 1 + > xen/drivers/acpi/topology.c | 41 +++ > xen/include/xen/acpi.h | 13 + > xen/include/xen/cpu-topology.h | 34 +++ > xen/include/xen/dt-cpu-topology.h | 35 +++ > 13 files changed, 567 insertions(+) > create mode 100644 xen/common/cpu-topology.c > create mode 100644 xen/common/device-tree/cpu-topology.c > create mode 100644 xen/drivers/acpi/topology.c > create mode 100644 xen/include/xen/cpu-topology.h > create mode 100644 xen/include/xen/dt-cpu-topology.h > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 843a43897e..1e0fd4957e 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -19,6 +19,7 @@ config ARM > select HAS_ALTERNATIVE if HAS_VMAP > select HAS_DEVICE_TREE_DISCOVERY > select HAS_DOM0LESS > + select HAS_GENERIC_CPU_TOPOLOGY > select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE > select HAS_STACK_PROTECTOR > select HAS_STATIC_MEMORY > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > index ba5fd2dd52..d957553a44 100644 > --- a/xen/arch/arm/smpboot.c > +++ b/xen/arch/arm/smpboot.c > @@ -9,10 +9,12 @@ > > #include > #include > +#include > #include > #include > #include > #include > +#include > #include > #include > #include > @@ -244,6 +246,9 @@ static void __init dt_smp_init_cpus(void) > } > else > tmp_map[i] = hwid; > + > + /* Pass the info to dt_init_cpu_topology() */ > + map_cpu_to_dt_node(i, cpu); You should call this only after successful `arch_cpu_init()`. > } > > if ( !bootcpu_valid ) > @@ -280,6 +285,8 @@ void __init smp_init_cpus(void) > else > acpi_smp_init_cpus(); > > + init_cpu_topology(); This is not a good placement. See below. > + > if ( opt_hmp_unsafe ) > warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n" > "It has implications on the security and stability of the system,\n" > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index da80fdba84..29879a9131 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -140,6 +140,9 @@ config HAS_EX_TABLE > config HAS_FAST_MULTIPLY > bool > > +config HAS_GENERIC_CPU_TOPOLOGY > + bool > + > config HAS_IOPORTS > bool > > @@ -191,6 +194,25 @@ config VM_EVENT > config NEEDS_LIBELF > bool > > +config GENERIC_CPU_TOPOLOGY > + bool > + > +config DT_CPU_TOPOLOGY > + bool "Device tree based CPU topology support (UNSUPPORTED)" > + depends on HAS_GENERIC_CPU_TOPOLOGY && DEVICE_TREE_PARSE && UNSUPPORTED > + select GENERIC_CPU_TOPOLOGY > + help > + Retrieve CPU topology information from the device tree to optimize > + vCPU scheduling. > + > +config ACPI_CPU_TOPOLOGY > + bool "ACPI based CPU topology support (UNSUPPORTED)" > + depends on HAS_GENERIC_CPU_TOPOLOGY && ACPI && UNSUPPORTED > + select GENERIC_CPU_TOPOLOGY > + help > + Retrieve CPU topology information from the ACPI PPTT to optimize > + vCPU scheduling. > + > config NUMA > bool > > diff --git a/xen/common/Makefile b/xen/common/Makefile > index 6018e25614..901bb37925 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -5,6 +5,7 @@ obj-$(CONFIG_GENERIC_BUG_FRAME) += bug.o > obj-$(CONFIG_HYPFS_CONFIG) += config_data.o > obj-$(CONFIG_CORE_PARKING) += core_parking.o > obj-y += cpu.o > +obj-$(CONFIG_GENERIC_CPU_TOPOLOGY) += cpu-topology.init.o > obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o > obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o > obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o > diff --git a/xen/common/cpu-topology.c b/xen/common/cpu-topology.c > new file mode 100644 > index 0000000000..52e31ef518 > --- /dev/null > +++ b/xen/common/cpu-topology.c > @@ -0,0 +1,62 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ The main license for Xen is GPLv2-only. Any reason for GPLv2+ in the new files? I'm asking because if you don't care about the license and simply copied it from other places, v2-only is a better fit for some organizations that cannot contribute to v2+. > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +static void __init free_topology_table(void) > +{ > + unsigned int cpu; > + > + for ( cpu = 0; cpu < nr_cpu_ids; cpu++ ) > + { > + free_cpumask_var(cpu_topology[cpu].thread_sibling); > + free_cpumask_var(cpu_topology[cpu].core_sibling); > + free_cpumask_var(cpu_topology[cpu].cluster_sibling); > + } > + > + XVFREE(cpu_topology); > +} > + > +void __init init_cpu_topology(void) > +{ > + unsigned int cpu; > + int ret; > + > + cpu_topology = xvzalloc_array(struct cpu_topology, nr_cpu_ids); You call it from `smp_init_cpus()` at which point `nr_cpu_ids` is not yet set and simply denotes `NR_CPUS`. > + if ( !cpu_topology ) > + return; > + > + for ( cpu = 0; cpu < nr_cpu_ids; cpu++ ) > + { > + if ( !zalloc_cpumask_var(&cpu_topology[cpu].thread_sibling) || > + !zalloc_cpumask_var(&cpu_topology[cpu].core_sibling) || > + !zalloc_cpumask_var(&cpu_topology[cpu].cluster_sibling) ) > + { > + free_topology_table(); > + return; > + } > + } > + > + if ( acpi_disabled ) > + ret = dt_init_cpu_topology(); > + else > + ret = acpi_init_cpu_topology(); > + > + /* Free the CPU topology table if initialization fails. */ > + if ( ret != 0 ) > + free_topology_table(); > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/common/cpu.c b/xen/common/cpu.c > index f09af0444b..9591ada60a 100644 > --- a/xen/common/cpu.c > +++ b/xen/common/cpu.c > @@ -1,5 +1,6 @@ > #include > #include > +#include > #include > #include > #include > @@ -46,6 +47,10 @@ const unsigned long cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)] = { > #undef MASK_DECLARE_2 > #undef MASK_DECLARE_1 > > +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY > +struct cpu_topology *__ro_after_init cpu_topology; > +#endif /* CONFIG_GENERIC_CPU_TOPOLOGY */ > + > static DEFINE_RWLOCK(cpu_add_remove_lock); > > bool get_cpu_maps(void) > diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile > index 9036e455d6..6ee670b5f4 100644 > --- a/xen/common/device-tree/Makefile > +++ b/xen/common/device-tree/Makefile > @@ -1,6 +1,7 @@ > obj-y += bootfdt.init.o > obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo-fdt.init.o > obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo.init.o > +obj-$(CONFIG_DT_CPU_TOPOLOGY) += cpu-topology.init.o > obj-y += device-tree.o > obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o > obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o > diff --git a/xen/common/device-tree/cpu-topology.c b/xen/common/device-tree/cpu-topology.c > new file mode 100644 > index 0000000000..9259be73bc > --- /dev/null > +++ b/xen/common/device-tree/cpu-topology.c > @@ -0,0 +1,344 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +/* > + * Derived from Linux kernel 7.0's $drivers/base/arch_topology.c > + * Parse cpu topology information. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define INVALID_TOPO_ID (~0U) > + > +struct cpu_map { > + unsigned int thread_id; > + unsigned int core_id; > + unsigned int cluster_id; > + unsigned int package_id; > +}; > + > +static struct cpu_map __initdata cpu_map[NR_CPUS] = { > + [0 ... NR_CPUS - 1] = { > + .thread_id = INVALID_TOPO_ID, > + .core_id = INVALID_TOPO_ID, > + .cluster_id = INVALID_TOPO_ID, > + .package_id = INVALID_TOPO_ID, > + }, > +}; > +static struct dt_device_node *__initdata dt_cpu_table[NR_CPUS]; > + > +static void __init setup_siblings_masks(unsigned int target_cpu) > +{ > + const struct cpu_topology *target_topo = &cpu_topology[target_cpu]; > + const struct cpu_map *target_map = &cpu_map[target_cpu]; > + unsigned int cpu; > + > + /* Update cluster, core and thread sibling masks */ > + for_each_possible_cpu(cpu) > + { > + const struct cpu_topology *cpu_topo = &cpu_topology[cpu]; > + const struct cpu_map *map = &cpu_map[cpu]; > + > + if ( target_cpu > cpu ) > + continue; > + > + if ( target_map->package_id != map->package_id ) > + continue; > + > + cpumask_set_cpu(target_cpu, cpu_topo->core_sibling); > + cpumask_set_cpu(cpu, target_topo->core_sibling); > + > + if ( target_map->cluster_id != map->cluster_id ) > + continue; > + > + if ( target_map->cluster_id != INVALID_TOPO_ID ) > + { > + cpumask_set_cpu(target_cpu, cpu_topo->cluster_sibling); > + cpumask_set_cpu(cpu, target_topo->cluster_sibling); > + } > + > + if ( target_map->core_id != map->core_id ) > + continue; > + > + cpumask_set_cpu(target_cpu, cpu_topo->thread_sibling); > + cpumask_set_cpu(cpu, target_topo->thread_sibling); > + } > +} > + > +static const struct dt_device_node *__init dt_find_child_node_by_name( > + const struct dt_device_node *dt, > + const char *name) > +{ > + const struct dt_device_node *np; > + > + dt_for_each_child_node(dt, np) > + if ( np->name && (dt_node_cmp(np->name, name) == 0) ) > + return np; > + > + return NULL; > +} > + > +void __init map_cpu_to_dt_node(unsigned int cpu, > + struct dt_device_node *cpu_node) > +{ > + if ( cpu < ARRAY_SIZE(dt_cpu_table) ) > + dt_cpu_table[cpu] = cpu_node; > + else > + printk(XENLOG_WARNING > + "cpu %u exceeds the max cpus %zu\n", > + cpu, ARRAY_SIZE(dt_cpu_table)); > +} > + > +static unsigned int __init cpu_node_to_id( > + const struct dt_device_node *cpu_node) > +{ > + unsigned int cpu; > + > + for_each_possible_cpu(cpu) > + if ( cpu_node == dt_cpu_table[cpu] ) > + return cpu; > + > + return INVALID_TOPO_ID; > +} > + > +/* > + * This function returns the Xen cpu number of the DT node. > + */ > +static unsigned int __init get_cpu_for_node( > + const struct dt_device_node *dt_node) > +{ > + const struct dt_device_node *cpu_node = > + dt_parse_phandle(dt_node, "cpu", 0); > + > + if ( !cpu_node ) > + return INVALID_TOPO_ID; > + > + return cpu_node_to_id(cpu_node); > +} > + > +static int __init parse_core(const struct dt_device_node *core, > + unsigned int package_id, > + unsigned int cluster_id, > + unsigned int core_id) > +{ > + bool leaf = true; > + unsigned int thread_id; > + unsigned int cpu; > + > + for ( thread_id = 0; ; thread_id++ ) > + { > + const struct dt_device_node *thread; > + char name[20]; > + > + snprintf(name, sizeof(name), "thread%u", thread_id); > + thread = dt_find_child_node_by_name(core, name); > + > + if ( !thread ) > + break; > + > + leaf = false; > + cpu = get_cpu_for_node(thread); > + > + if ( cpu == INVALID_TOPO_ID ) > + { > + printk(XENLOG_ERR > + "ERROR: %s: Can't get CPU for thread\n", dt_node_name(thread)); > + return -EINVAL; > + } > + > + ASSERT(cpu_map[cpu].package_id == INVALID_TOPO_ID); > + ASSERT(cpu_map[cpu].cluster_id == INVALID_TOPO_ID); > + ASSERT(cpu_map[cpu].core_id == INVALID_TOPO_ID); > + ASSERT(cpu_map[cpu].thread_id == INVALID_TOPO_ID); This ASSERT block and the identical one below validate DT data, not Xen internal invariant. Return error instead. > + > + cpu_map[cpu].package_id = package_id; > + cpu_map[cpu].cluster_id = cluster_id; > + cpu_map[cpu].core_id = core_id; > + cpu_map[cpu].thread_id = thread_id; > + } > + > + cpu = get_cpu_for_node(core); > + > + if ( cpu != INVALID_TOPO_ID ) > + { > + if ( !leaf ) > + { > + printk(XENLOG_ERR "ERROR: %s: Core has both threads and CPU\n", > + dt_node_name(core)); > + return -EINVAL; > + } > + > + ASSERT(cpu_map[cpu].package_id == INVALID_TOPO_ID); > + ASSERT(cpu_map[cpu].cluster_id == INVALID_TOPO_ID); > + ASSERT(cpu_map[cpu].core_id == INVALID_TOPO_ID); > + ASSERT(cpu_map[cpu].thread_id == INVALID_TOPO_ID); > + > + cpu_map[cpu].package_id = package_id; > + cpu_map[cpu].cluster_id = cluster_id; > + cpu_map[cpu].core_id = core_id; > + cpu_map[cpu].thread_id = 0; > + } > + else if ( leaf ) > + { > + printk(XENLOG_ERR > + "ERROR: %s: Can't get CPU for leaf core\n", dt_node_name(core)); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int __init parse_cluster(const struct dt_device_node *cluster, > + unsigned int package_id, > + unsigned int cluster_id, > + unsigned int depth) > +{ > + bool leaf = true; > + bool has_cores = false; > + unsigned int core_id; > + unsigned int child_cluster_id; > + > + /* > + * First check for child clusters; we currently ignore any > + * information about the nesting of clusters and present the > + * scheduler with a flat list of them. > + */ > + for ( child_cluster_id = 0; ; child_cluster_id++ ) > + { > + const struct dt_device_node *child_cluster; > + char name[20]; > + int ret; > + > + snprintf(name, sizeof(name), "cluster%u", child_cluster_id); > + child_cluster = dt_find_child_node_by_name(cluster, name); > + > + if ( !child_cluster ) > + break; > + > + leaf = false; > + ret = parse_cluster(child_cluster, package_id, child_cluster_id, > + depth + 1); > + if ( depth > 0 ) > + printk(XENLOG_WARNING > + "WARNING: Topology for clusters of clusters not yet supported\n"); > + if ( ret != 0 ) > + return ret; > + } > + > + /* Now check for cores */ > + for ( core_id = 0; ; core_id++ ) > + { > + const struct dt_device_node *core; > + char name[20]; > + int ret; > + > + snprintf(name, sizeof(name), "core%u", core_id); > + core = dt_find_child_node_by_name(cluster, name); > + > + if ( !core ) > + break; > + > + has_cores = true; > + > + if ( depth == 0 ) > + { > + printk(XENLOG_ERR > + "ERROR: %s: cpu-map children should be clusters\n", > + dt_node_name(core)); > + return -EINVAL; > + } > + > + if ( leaf ) > + { > + ret = parse_core(core, package_id, cluster_id, core_id); > + if ( ret != 0 ) > + return ret; > + } > + else > + { > + printk(XENLOG_ERR "ERROR: %s: Non-leaf cluster with core %s\n", > + dt_node_name(cluster), name); > + return -EINVAL; > + } > + } > + > + if ( leaf && !has_cores ) > + printk(XENLOG_WARNING "WARNING: %s: empty cluster\n", > + dt_node_name(cluster)); > + > + return 0; > +} > + > +static int __init parse_socket(const struct dt_device_node *socket) > +{ > + bool has_socket = false; > + unsigned int package_id; > + int ret; > + > + for ( package_id = 0; ; package_id++ ) > + { > + const struct dt_device_node *cluster; > + char name[20]; > + > + snprintf(name, sizeof(name), "socket%u", package_id); > + cluster = dt_find_child_node_by_name(socket, name); The names are one level off (I know you took it from Linux which suffers from the same problem): the parameter is the cpu-map node, not a socket, and the local is a socket node, not a cluster. parse_cluster() has the same problem. Please name the parameters after what they actually receive, e.g.parse_socket(cpu_map) with a local 'socket'. It makes it difficult to parse the code and I'll wait with reviewing this file until this is fixed. > + > + if ( !cluster ) > + break; > + > + has_socket = true; > + ret = parse_cluster(cluster, package_id, INVALID_TOPO_ID, 0); > + if ( ret != 0 ) > + return ret; > + } > + > + if ( !has_socket ) > + ret = parse_cluster(socket, 0, INVALID_TOPO_ID, 0); > + > + return ret; > +} > + > +static int __init parse_dt_topology(void) > +{ > + const struct dt_device_node *cpus; > + const struct dt_device_node *map; > + > + cpus = dt_find_node_by_path("/cpus"); > + if ( !cpus ) > + return -ENOENT; > + > + map = dt_find_child_node_by_name(cpus, "cpu-map"); > + if ( !map ) > + return -ENOENT; > + > + return parse_socket(map); > +} > + > +int __init dt_init_cpu_topology(void) > +{ > + unsigned int cpu; > + int ret; > + > + BUG_ON(!acpi_disabled); > + BUG_ON(!cpu_topology); ASSERTs are a better fit here, given that these are already validated by the sole caller. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:16:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:16:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412190.1642704 (Exim 4.92) (envelope-from ) id 1x3xYr-0007tb-Q7; Tue, 08 Sep 2026 15:16:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412190.1642704; Tue, 08 Sep 2026 15:16:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xYr-0007tU-NR; Tue, 08 Sep 2026 15:16:37 +0000 Received: by outflank-mailman (input) for mailman id 1412190; Tue, 08 Sep 2026 15:16:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xYq-0007tO-EM for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:16:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3xYp-009IxJ-RI for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:16:35 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa026c4-2eae-0a2a0a5409dd-0a2a4503bac8-30 for ; Tue, 08 Sep 2026 17:16:35 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa026d2-fae8-0a2a45030019-aceafc1fab4c-3 for ; Tue, 08 Sep 2026 17:16:35 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 67B3542E3B; Tue, 8 Sep 2026 15:16:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2F2B1F00A3A; Tue, 8 Sep 2026 15:16:24 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Message-ID: Date: Tue, 8 Sep 2026 17:16:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 03/14] xen/grant-table: stop setting PG_private on pages for grant mapping To: Zi Yan , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org References: <20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com> <20260907-remove-pg_private-v3-3-6ae22f9d9272@nvidia.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <20260907-remove-pg_private-v3-3-6ae22f9d9272@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788880595-764FC4E9-E82700AA/0/0 X-purgate-type: clean X-purgate-size: 1642 On 9/8/26 04:56, Zi Yan wrote: > gnttab_alloc_pages() stores xen_page_foreign in page->private. On 32-bit, a > pointer to an allocated xen_page_foreign is stored; on 64-bit, > xen_page_foreign is stored inline. Checking page->private != NULL is enough > to tell whether a xen_page_foreign needs to be freed on 32-bit and > page->private is zeroed unconditionally on 64-bit. > > It prepares for a future commit that remove PG_private. > > No functional change intended. > > Assisted-by: Claude:claude-opus-4-8 > Assisted-by: Codex:gpt-5 > Signed-off-by: Zi Yan > To: Juergen Gross > To: Stefano Stabellini > Cc: Oleksandr Tyshchenko > Cc: xen-devel@lists.xenproject.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/xen/balloon.c | 5 +++++ > drivers/xen/grant-table.c | 11 +++++------ > 2 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index e7f74ea7cd5eb..fdb18348cfdfe 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -182,6 +182,11 @@ static struct page *balloon_retrieve(bool require_lowmem) > > __ClearPageOffline(page); > dec_node_page_state(page, NR_BALLOON_PAGES); > + /* > + * clear page->private before giving it out, since it might be used to > + * store xen_page_foreign info. > + */ > + set_page_private(page, 0); Who would have set it to != 0 in the first place? e.g., gnttab_free_pages() resets it to 0 now before calling xen_free_unpopulated_pages(). -- Cheers, David From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:27:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:27:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412204.1642715 (Exim 4.92) (envelope-from ) id 1x3xjD-0001FK-N1; Tue, 08 Sep 2026 15:27:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412204.1642715; Tue, 08 Sep 2026 15:27:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xjD-0001FD-JB; Tue, 08 Sep 2026 15:27:19 +0000 Received: by outflank-mailman (input) for mailman id 1412204; Tue, 08 Sep 2026 15:27:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3xjB-0001F7-PL for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:27:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3xjA-00Dphl-Qv for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:27:16 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa02946-bab6-0a2a0a5309dd-0a2a4501d3a8-36 for ; Tue, 08 Sep 2026 17:27:16 +0200 Received: from [209.85.218.53] (helo=mail-ej1-f53.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa02954-5984-0a2a45010019-d155da35c1e4-3 for ; Tue, 08 Sep 2026 17:27:16 +0200 Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-c252e703fa3so736139966b.3 for ; Tue, 08 Sep 2026 08:27:16 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d53c37csm626637366b.32.2026.09.08.08.26.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 08:27:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788881236; x=1789486036; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wwyha5CEvTVTebVQhfueu6paExhbIMYaOo2vqUYwd4E=; b=SU6YadpYL6kYCvoSoMoNCV63ZdpH7nTLfUX1IVmuNSXmJZP9KGUHTnwFnhnBcmHaHO DpL3vz0Cze99npXmlRBudPiGlfSQpyBx79rkKN6rsCaPIS99kJdviQu+a/s0X7ONfCH6 VVbmb5zn8JJ9nfhJSbZrJVp/MOXvaSlaJbHrwYHtf5LPAnpcsm1YPFbAbWsD88KrRMKq tWlHrJSDTt6it3grTtdyFzK8yQ9rmYgWne+S/i8yB0P3FzaboU4Y2IR1v2AuGCEBoaKf q1WdLDZb96LI3IMer+G+NdPGZOMZtDknIlgnTjgpF1lHkVgJRefpwAuPfWKIuI9z3l+Y RDSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788881236; x=1789486036; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=wwyha5CEvTVTebVQhfueu6paExhbIMYaOo2vqUYwd4E=; b=STqcZZxIKWb9hi7OGnGPhO05s6newurSxocCWOSRmPwrMMhuKUa0Ldc8O6zsmEmSW5 Jk8UpkPBpre8o1CO5HSQ9E9NmmlNGZG4MP9MBo/SoEhC0K2w9VAYVVWydsHcAgM8x5R3 P5GOZIs13fu86+GNiH08dGKp1VC0TQGATaHJD2zbjAoTfWEZ8WZ3a21/wbiH+V/jMvA+ ZCKWS5WwE6M//WR6nXS8FoSDTd3AAJ4ohEb4iqDhWXmgWgYxfBAPlIo0R0OtXf3KQNby XVuVAxJdfG2lInYA6XMBAfwkt1Dc0ItWtaA45dk8pvh1M3NDsgAnqXYiNj+twBF5ce0s E1PA== X-Forwarded-Encrypted: i=1; AKwUvBztkdDmng5+IbICrdbWif0MdGSPcnBRa83v0Wv5Ka1hLEreWtUzt1FANqi6cfsvBlsLV8+0uoVVCZA=@lists.xenproject.org X-Gm-Message-State: AFuF++ngdph6mjFIsWk6DwY3rw1HlcmgRh51uUr0P7gWWNwnIXJbB59M kAj7bYzOgkrI9qBT1goBPZYDdoKZVEblh5izhQoJ8JYqChLMfGNVmMI6 X-Gm-Gg: AYBFou34KWw/WVHEbA4uHwUTn0jYmd9ETQdKSLYtA4/JqzNK1K/ZuQSVaMpM+997aWf 2wEoDyJmJlUpWw4LD/QXcZaddLisrcr1MzFU3LUnT6jsF4DPilDIFROqow9vnBx+3hYaRuMIu7J 0jshDOy1I8vOZ7ItEhAnPuJiU181rI8ondf0xPKS0acaahnbRrRH1GoULOv1CYICktGeFuI26eL aNETPDObg/eOQRSHAWEVPMz7ne795KH1VPrUqhEKFp7N9w8Z2qNtjqmJ44HGL6eheRi+L3xD+uV zX2RKYx24v+WAMhQfcqwElvpzT1P+ElZ2ei6JJMxvnQpfyuPPdjNMN9xUslNilWnpJVTKKTN4wd FqfD1cHqnP+7axD9Q7+PaViEnJFGJ65SF/fc40+CTBnPgYsbhrMVuOj8HTmFzm6ssK+p7ZqFyfY izPNzocFYy+2pzUwj8b33xk3MRDPWSh26doxXuUtArH6B6+PEpffccimigXPMHZ0ILzxFjobzY4 1cbqrbhVLdfGrtRV69OQQ== X-Received: by 2002:a17:906:ef05:b0:c26:1648:a06b with SMTP id a640c23a62f3a-c261648b772mr1079466866b.38.1788881236097; Tue, 08 Sep 2026 08:27:16 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 17:25:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1788881236-BF063757-A9E9551C/10/73395122804 X-purgate-type: spam X-purgate-size: 3132 On 9/8/26 4:16 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >> @@ -109,6 +109,12 @@ >> #define SIP_SSIP MIP_SSIP >> #define SIP_STIP MIP_STIP >> >> +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ >> +#define STVEC_MODE_MASK _UL(0x3) >> +#define STVEC_MODE_DIRECT _UL(0x0) >> +#define STVEC_MODE_VECTORED _UL(0x1) > > As on earlier occasions: Do the 0x here actually add any value? There are > none ... > >> +#define STVEC_BASE_MASK (~STVEC_MODE_MASK) >> + >> #define PRV_U _UL(0) >> #define PRV_S _UL(1) >> #define PRV_M _UL(3) > > ... here, for example. Agree, not too much sense. > >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -294,5 +294,53 @@ enum mc_disposition arch_do_multicall_call(struct mc_state *state) >> /* Redirect trap to Guest. */ >> void trap_redirect(const struct trap_info *trap) >> { >> - BUG_ON("unimplemented"); >> + struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(current); >> + unsigned long vsstatus = csr_read(CSR_VSSTATUS); >> + >> + /* >> + * Redirecting a trap makes sense only if the trap was taken from >> + * virtualized mode, i.e. sret is going to return to VS-mode. >> + */ >> + ASSERT(regs->hstatus & HSTATUS_SPV); >> + >> + /* >> + * Only synchronous exceptions can be redirected. Interrupts must be >> + * injected via hvip instead, so that the hardware itself performs >> + * VS-mode trap entry, respecting vsstatus.SIE and the vectored >> + * dispatch (BASE + 4 * cause) if vstvec is configured so. >> + */ >> + ASSERT(!(trap->scause & CAUSE_IRQ_FLAG)); >> + >> + /* Change Guest SSTATUS.SPP bit */ >> + vsstatus &= ~SSTATUS_SPP; >> + if ( regs->sstatus & SSTATUS_SPP ) >> + vsstatus |= SSTATUS_SPP; >> + >> + /* Change Guest SSTATUS.SPIE bit */ >> + vsstatus &= ~SSTATUS_SPIE; >> + if ( vsstatus & SSTATUS_SIE ) >> + vsstatus |= SSTATUS_SPIE; >> + >> + /* Clear Guest SSTATUS.SIE bit */ >> + vsstatus &= ~SSTATUS_SIE; >> + >> + /* Update Guest SSTATUS */ >> + csr_write(CSR_VSSTATUS, vsstatus); >> + >> + /* Update Guest SCAUSE, STVAL, and SEPC */ >> + csr_write(CSR_VSCAUSE, trap->scause); >> + csr_write(CSR_VSTVAL, trap->stval); >> + csr_write(CSR_VSEPC, trap->sepc); >> + >> + /* >> + * Set Guest PC to Guest exception vector. >> + * >> + * vstvec's MODE field is not part of the address. Exceptions always >> + * target BASE regardless of MODE, so mask it off explicitly instead of >> + * relying on the hardwired zero bit of sepc to drop it. >> + */ >> + regs->sepc = csr_read(CSR_VSTVEC) & STVEC_BASE_MASK; > > Nit: Given how much the comment talks about MODE, imo using ~STVEC_MODE_MASK > here directly (and dropping STVEC_BASE_MASK) might be better. > Agree, it could be dropped. I will update that in v3. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:36:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:36:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412217.1642743 (Exim 4.92) (envelope-from ) id 1x3xsA-0003Ck-LD; Tue, 08 Sep 2026 15:36:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412217.1642743; Tue, 08 Sep 2026 15:36:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xsA-0003Cd-IY; Tue, 08 Sep 2026 15:36:34 +0000 Received: by outflank-mailman (input) for mailman id 1412217; Tue, 08 Sep 2026 15:36:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3xs9-0003CX-Fb for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:36:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3xs8-00H12z-SW for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:36:32 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa02b5e-e002-0a2a0a5209dd-0a2a45028040-32 for ; Tue, 08 Sep 2026 17:36:32 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa02b80-6ca4-0a2a45020019-d155dd31a8df-3 for ; Tue, 08 Sep 2026 17:36:32 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48431648f33so3801247f8f.0 for ; Tue, 08 Sep 2026 08:36:32 -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 ffacd0b85a97d-485883c074asm35967770f8f.23.2026.09.08.08.36.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 08:36:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788881792; x=1789486592; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=eHZqF9+F1KWCj3lF8faY6w+JvEdXiNbJY2NR6FAt3RY=; b=GyzLBpv+Djiy2Gh97VZ2a/CPCgVVkYPS7GJ9xjOvU48UWYizyc4SA+o+V0XFN0MlFb HZdNF1obxA9S7qcaRWvJFcanZ7gRuK1E7L7nM4EKQarQAxd6wIZp/U/cDZXfa5NaP1zj IUBRBxmb+UQONBmMw+izodne+qVSezB0engYfAOwwdq5LsdIFURDmkliVUeEMI+81myd nAdqwP1hSJOUIZveDhdmSAuiTKAcbwrQtQnNQ2gdsWYuSIsaRGWY+HwUROCta+sKurRR sI+UPBoJkBGSTCKFvRmv4Tm/KG0oNjR/07Sef2pW+Cq9tpzKQAT1mqHbpfgCpKLwCXif PPPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788881792; x=1789486592; h=content-transfer-encoding:content-type: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:content-type; bh=eHZqF9+F1KWCj3lF8faY6w+JvEdXiNbJY2NR6FAt3RY=; b=AjN4cb1INr7DdJUG5zT9Q/Q53E/GqwSZwdJ1kjYtHetK7C6+c4xLASUiNYdCXMTBOQ j8JWTzhYelSq4INftjyTHXi4RQm+iFs9+1EiL6iDSbzOzf3qbeFOTg1RDjpTvbxLYpeA l0Zumpw/mn+QZmC9uh501jtFjKXVX8mZ/zntYYg2RjoLVv99ZJ9x2+Se0eT5Y8v5E4/C /BTvkjEHNtsxbrh1QejYXibMkL4+tLROKQBqawaWRIEy//ZkP785GiPvyH4Ulx/AW1Gx RBYTCQ9bKEeq7IpEo0Jd4d8ecSMrgwlqdiqXg2ar5oP+p6m2+lqDFv8MvC3ieeFpSEmf m5kg== X-Forwarded-Encrypted: i=1; AKwUvBwFDyNooXhMBLu13I03BhPZaYak+BWSbcg9penaF/LaoaFDoPGP/kRgUP0ENTWJbfyMKSbGezN72aE=@lists.xenproject.org X-Gm-Message-State: AFuF++m3qVuFn/bJq03D/Gp7OwDhvjQHJlMW6t0PA6BLb9rcAJQfeA6F fGRBczBtcRVkq41otMaKQNcGu+5BxsSXeGXROQ25pzPfUhUKyJCkXWRqBlzeeRm3zQ== X-Gm-Gg: AYBFou3R+xoJ0+ArfuU+kKUUbcfz4dwLxV5tKynBdVURdaPz5m0jIZO3hb0ZwvKUA+t u9vNMprG2lRC3ocpoCFwhcS4Qz8PzNQ3m1vJ2NFGIsG2dnQdGmLIcZY1x5GvQhWewCNI6gsjatY rmog+xX9eZnnruMcAMRHfISE65CDJYftZgeGyh5NfrxXWfgbn6TMsiCYcon1cYmyUxZBSB+NSe2 AAnaprn3ZeV/luuvbFny6BzwgxqzXKsBmUHjlYpUTr/j8spsvx/GGaI2Z/wWKQXAUjzUF26bZ8S J7C8a2pd5b+M4uB6Elj7cOxQMRSJSCeqvdrZrx1HFrbz2O0P9Vbwl622kcvZO26tksuQ6zmc+0W 1k4jRhhdEdLO+NfPDYawRFSDvakplM4MrKuAzXyTVb3dufBrhqeWia6OTEyD29qH94pwaWxWG8q RxJxYP216x8WrXSCugx+bjy9r57JGw+731B1iavvWpW//mD141f5MFUFRlJo1uTPh6sLq2gAd3I eVPuOP0PU+XM5UdBpvPG5I25dQNDAWwAHW5hIcofel+C9jlY4QY X-Received: by 2002:a05:6000:2008:b0:485:8226:c69d with SMTP id ffacd0b85a97d-4858226c991mr37825225f8f.28.1788881792212; Tue, 08 Sep 2026 08:36:32 -0700 (PDT) Message-ID: <97a420e4-87d3-4600-b169-8ec7e5f62a21@suse.com> Date: Tue, 8 Sep 2026 17:36:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/14] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-9-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-9-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788881792-F3CBA2AC-4DB3A1A3/0/0 X-purgate-type: clean X-purgate-size: 3077 On 02.09.2026 11:43, George Dunlap wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -6456,10 +6456,11 @@ void populate_perdomain_mapping(const struct vcpu *v, unsigned long va, > local_irq_restore(irq_flags); > } > > -void destroy_perdomain_mapping(struct domain *d, unsigned long va, > +void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, > unsigned int nr) > { > const l3_pgentry_t *l3tab, *pl3e; > + const struct domain *d = v->domain; > > ASSERT(va >= PERDOMAIN_VIRT_START && > va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); > @@ -6468,6 +6469,26 @@ void destroy_perdomain_mapping(struct domain *d, unsigned long va, > if ( !d->arch.perdomain_l3_pg ) > return; > > + if ( likely(this_cpu(pgtable_vcpu) == v) ) Right now this looks to be relevant only to some of the call sites of pv_destroy_ldt(). I expect this is going to change down the road? > + { > + l1_pgentry_t *pl1e; > + > + /* > + * Fast path: v's page-tables are loaded on this pCPU, so the L1 > + * entries can be zapped using the recursive linear mappings. > + */ > + pl1e = &__linear_l1_table[l1_linear_offset(va)]; > + > + for ( ; nr--; pl1e++ ) > + { > + if ( perdomain_l1e_needs_freeing(*pl1e) ) > + free_domheap_page(l1e_get_page(*pl1e)); > + l1e_write(pl1e, l1e_empty()); > + } > + > + return; > + } > + > l3tab = __map_domain_page(d->arch.perdomain_l3_pg); > pl3e = l3tab + l3_table_offset(va); The slow path is resilient against an area never having been mapped. This fast path looks like it would crash on a missing L2 or L1 table. I.e. for domain cleanup (and error handling during domain creation) we'd implicitly rely on those never taking the fast path. May be worth making explicit in the description. > --- a/xen/arch/x86/pv/domain.c > +++ b/xen/arch/x86/pv/domain.c > @@ -319,8 +319,7 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v) > > static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v) > { > - destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v), > - 1U << GDT_LDT_VCPU_SHIFT); > + destroy_perdomain_mapping(v, GDT_VIRT_START(v), 1U << GDT_LDT_VCPU_SHIFT); > } Considering what patch 08 does - is this explicit call really needed? There are no pages to free here, unlike ... > --- a/xen/arch/x86/x86_64/mm.c > +++ b/xen/arch/x86/x86_64/mm.c > @@ -738,7 +738,7 @@ int setup_compat_arg_xlat(struct vcpu *v) > > void free_compat_arg_xlat(struct vcpu *v) > { > - destroy_perdomain_mapping(v->domain, ARG_XLAT_START(v), > + destroy_perdomain_mapping(v, ARG_XLAT_START(v), > PFN_UP(COMPAT_ARG_XLAT_SIZE)); > } ... here. Then again even the freeing is taken care of by free_perdomain_mappings(), so even for this one the question arises whether it's actually needed. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:45:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:45:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412231.1642771 (Exim 4.92) (envelope-from ) id 1x3y0H-0005GW-K6; Tue, 08 Sep 2026 15:44:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412231.1642771; Tue, 08 Sep 2026 15:44:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3y0H-0005GP-HD; Tue, 08 Sep 2026 15:44:57 +0000 Received: by outflank-mailman (input) for mailman id 1412231; Tue, 08 Sep 2026 15:44:56 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3y0G-0005GH-8q for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:44:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3y0F-004Xzh-Lf for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:44:55 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa02d72-2eae-0a2a0a5409dd-0a2a4507b41a-10 for ; Tue, 08 Sep 2026 17:44:55 +0200 Received: from [52.101.52.42] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa02d76-b4ea-0a2a45070019-3465342a76b5-3 for ; Tue, 08 Sep 2026 17:44:55 +0200 Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DSSPR12MB999211.namprd12.prod.outlook.com (2603:10b6:8:375::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Tue, 8 Sep 2026 15:44:48 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0406.005; Tue, 8 Sep 2026 15:44:48 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XNXTeJn3wAg9WXnadc23COLow0t+fVtyrSLdBMioSg5aXICV5bD0aB1n3v39op2ITN6V93hppovIIPHIo5pRlumrqSHEI+ea/kevee/IT8UhCPUEsHmKkJ3mldz8BUGhQFkOKIhnuU+5dzAeMHXChSYWnx1wzVI8YtvxQXedsdGOLpMznnnFdC3PSbxZTDnbT0q2phGAf4VOiNRHMUsx0yfwwccG4NMp+sP6YPQhl7nTlH7z/6gBnKLwHt9JDV2cRwt4PUajH8ySLywTgqKbCK/CyUDqHyr4ueNvyUHJ0r4g5oos9Zhm3Wzk/L32ldFSKpDkNo6kB5sP36NhVPkBJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wUonv+1fXdqRVR64AjAKSh8fzS4K5yeQQGpHI4+sTZ8=; b=PikpR45oEYt7MOJrMl878COZoD2IIZKHqiCAwU58mVam3iieo2TBvGtCh/j9um5cL1A2iMlsqPQgLVZwEQua7eA9S9omvpF6t1V3OCx4Mgztnm7AaLNbw0BfjhZsaAYaFADhkaZyeLC+6n4/Nm3qCyw3ewxvpFS8Oz0+LncaaO14l3spbkJWmM/tFP9jCHoJ8J8O1Lvi0ZWDc4L54MCSLAA/qE//ge7iFLRVkV+LiH/QL129zXUPD221WRuRtjvV83Q1RlbYUYJIrbBqsSV+6srlsuFiVfETaAS5WS6Pywl0QJNH9gYXo0ENyLzrZ0NpVt7s7JcTaFMcm2qZtma4ZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wUonv+1fXdqRVR64AjAKSh8fzS4K5yeQQGpHI4+sTZ8=; b=VQx6+JOEraj6F3kNb1lGvXWTN1o/WItmH/zgpXqIqgTvd/xwyfGVpRMN0IejkRjKj63anvIeHtak/4zmN8cbKRHU8FWG6ZPn4b95MnE5BZT44qeeX5g0aRmbUs9Az8hhZVOjxpCbmIS1diERpW2YQoiPHHeE/rgLtMuqFwL1aILcIyVB0p8kP45bWm9efkuBk8zAg2gZkv5JVszC6sGzooeOg6mt9Uuo96TjleJWDGc9uowAsXgQdIPRbPTbTNelpaAMktdLfNTvkwwDGZt4ki+hBH4p8/+d3JcF9iMclf11k/r9zoCPHrG6ydqkAxF6AB5rHTLHQU7AP7zyZ0FTfQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 08 Sep 2026 11:44:46 -0400 Message-Id: From: "Zi Yan" Subject: Re: [PATCH v3 03/14] xen/grant-table: stop setting PG_private on pages for grant mapping Cc: , , "Juergen Gross" , "Stefano Stabellini" , "Oleksandr Tyshchenko" , To: "David Hildenbrand (Arm)" , "Matthew Wilcox (Oracle)" , "Andrew Morton" , "Muchun Song" , "Lorenzo Stoakes" , "Liam R. Howlett" , "Vlastimil Babka" , "Mike Rapoport" , "Suren Baghdasaryan" , "Michal Hocko" , "Baolin Wang" , "Nico Pache" , "Ryan Roberts" , "Dev Jain" , "Barry Song" , "Lance Yang" , "Usama Arif" , "Gregory Price" , "Ying Huang" , "Alistair Popple" , "Johannes Weiner" , "Qi Zheng" , "Shakeel Butt" , "Kairui Song" X-Mailer: aerc 0.22.0 References: <20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com> <20260907-remove-pg_private-v3-3-6ae22f9d9272@nvidia.com> In-Reply-To: X-ClientProxiedBy: YQBPR0101CA0188.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:f::31) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DSSPR12MB999211:EE_ X-MS-Office365-Filtering-Correlation-Id: 2942c721-1277-418e-bc0f-08df0dc01d2a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|7416014|1800799024|921020|18002099003|22082099003|56012099006|4143699003|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: XaYRZ3hMQP1dy8zHLVQuJFN5za1QToGQt9Np4pUCVCDk0m5zU5/n9F7pr0ubBVv20NDKcCih2Whe8JgqBx+5Ca5Q747AsQ5Lv38E96I82nShv7lgit+PCqqwNXuDrCm4aaZvCrplHUZjpp1SmNciGZvIftAkkXsg5Yh5IY8/MrwlIvsWHVmcm8mQxJnOPceQYiJxM/03zdLcdcv/At02p7ThuMRAHUEe566VIP/OcD++mMgGnHLJ7ixzSXCnt6Jl5xxJw9PoUiDw8vZYAVvRuo7SJOmjRR6hcOqKg7IOMbo2ZvRy1eJxYTaCY43yeaQuhbvbKoUKCQsxRsATmIGRsUsgtGqImuf4v23nNxoj7h/GPjSvL3ejGU0QeuQdXCMGmT6GjVMh8K/Pi10q34gW/yghJU/wBuhaMrEATFRoLtJ+l9qPEnTQwjErQT8KkkvDOja6zS3h25UELh4VCZVwg3D3ndPYJN7gBt0a8lUJ7NGItcGExgsRAcMpSkBMcKVV62FCDJnK//N4c0VMsnBHcvsLygFdSHc0CYpLZVPosIaHl/mgM0ET4wh/DmPS/6UJsX8HhgLnGH38TnO+NL6eusjsHFYnjWj+qqtveTG+gPhI/tnqsUIMa1c+mWhOAcDwn0JCE5clzRqvJjqm30WObf813onLye+4tPFXdlxaQLJ8yiwcTxX1N2aQfHLYfuvS1r1DESH47op/YTAN3zQl3g== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(7416014)(1800799024)(921020)(18002099003)(22082099003)(56012099006)(4143699003)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bG1QZHNEaEpGdWJNK3ZaZXhKbFFSQzdXak1CdUJYZkw1VnQwWlN4aWFGemxJ?= =?utf-8?B?MjlpUmJVeWVjRFpaYXpWUVAyQkFGMW8xR3pDRGtxY0ErcFVwazhlZXZSWG9M?= =?utf-8?B?bXVNUnBsUURZZy96QnY1YXpVVlJ0YitXaEhwL3NNTEt2KzlWOEZ5S1Z4WDhZ?= =?utf-8?B?SzNsNVBYYlF0REpXOVdpTjQ0R3dXOFFLNVp2ODlHT1BBT1JwT2U5TDBhMVBw?= =?utf-8?B?alcrUzVaWUlHRVN1MkxaWWNCOEN1VlQ2Vy8zR25EVkkvQ0FROUVZM3hZaVVx?= =?utf-8?B?bEcxeUphc05SYXdML0tGTVl0ZFJDMWxJWm95UWNxWk5ZR3dqTXBXZ0hvdWwy?= =?utf-8?B?bk9VNGpDbzV4SzZMakR3UFlDK0dURVNVTlUxMmtOUFE1RHJ1ejc3SXBvNXZ4?= =?utf-8?B?WWxvWUR4S0RuMjZtTlNoVnBHQVJ2RWJ1aC9udjZNRmhOcXF2K0lpTGUxRFo2?= =?utf-8?B?NTJmVzhoN2ZoS2IzOCsySlpCQVlVbFhsTGVXWDV1dUZTMEtoYWllSXI5cXdy?= =?utf-8?B?cmlOcHVPcEFkNXJpQklVeXNoK2dPK0E4SWEwMTllTzRoa0Zwb1JTcDVEa1kv?= =?utf-8?B?ZmNGTTF3TzgwVGRVd3hQMWZsMVRhbmp1S1lwVTJqWllucU8vL1ErOVpXV1dl?= =?utf-8?B?OE5adjcwS0xJbVp3a002aGJJMnNjNmtxbXN1NUhMVmlERDRaaFlubFY1Y0ZC?= =?utf-8?B?Y0xOU044MmxEdXdoVzQ2WHBYRXhMbWVENU4wajEvNkJrWkpLY0t3bkNsbnkr?= =?utf-8?B?eUMxZkY1Y0pRODJOUHUxK0RXbm00M05TaGIyVGZteDBBR0tKejliai9VeW5x?= =?utf-8?B?b3ZBczlUMU9TNmxBUmFveElEY3JITXhTRDJTYkdVMzdSZWNPdGV5cVVqZ2pQ?= =?utf-8?B?Vis5UHRvN3U4U2Z3OXNiRWZVdVIxL216QllOb0d6YjFmcXpHcW0zMWZ1Mytv?= =?utf-8?B?RW0raURBYWFXamNKK3BDVzlCalFIaW5tQk45cHZzK1VXSFRQTkUvajBPUGZj?= =?utf-8?B?VkxrWHNmMVVJcjZ3cUMwcFZtWmdtaUJud1hxdTlhMWtIM2lhZVpxU0R4QnZu?= =?utf-8?B?Mi9NQlR2elpPTnZIa1VuTWp6N1FyYUU5SW5tUERYOFRkMStmb3NIcGRVMHhC?= =?utf-8?B?NVJ2NFV1aEZNK2VzeGhHdUJjeDZrRUIyQ0hCV2l6VEEvbTBrWkxxdkh4MUpO?= =?utf-8?B?NWw2QWp5RnZvN0x4V1lKTHUzenpzbkpTK0MzbHQwYVU3dFBZcTRsZzNCNk02?= =?utf-8?B?UHBqS0k4cGFvbTVWc2k0TjhUOXM1RGVkeDhQdklWK2VsR0dnRG1WZEFTM1p0?= =?utf-8?B?WThIVnhwOVNDcFVPeER2dWtyWlE2QnNaRi9INWVMSVlTUkNwYU9DTDR4cTIx?= =?utf-8?B?Z1o4Y042YUFEMGVVeWg2dzJHZWcvazVhM1JweTlsRWVtT2dCT0ZFYTY5aXJ4?= =?utf-8?B?alNqMXJUbVZYQmx4VVBhZGl3Rjg5aEZaTnRTdG4vMFRiamtxMnhUNmsrVlBv?= =?utf-8?B?M2F6NVdjdGFqWTRBaGZnTy9EYXhEWnY5allHWUlqR3pyTjlQMHc3SUJvc21l?= =?utf-8?B?RzZjdzIyVUFEZ05MZmcvdVBtbVErS0ZINGtFZGsybEgxWkVGeHFJK0NhaGIy?= =?utf-8?B?cWsySmNPaHdCOUFTbC9jU1FhcVRlaG5Pc3l2Nk5NZngwY2xvY0VqbXoyMFdS?= =?utf-8?B?REFSbU9YS2pia256amJJY3JXTzg1U1FhQmJWOXFvT2ZvUU1XZjlNNjUvVXR2?= =?utf-8?B?a2lGVTJQODJudUJTZFRPMHdNaC9EWWxJQ0NuUk9UZXF5aXhIc2NzVG5wekh5?= =?utf-8?B?b2plSjRMQlAwVWllS1RId1AxR3M4K1RBWWRrWm1td3ZrQzZUd0pCSlF5dElj?= =?utf-8?B?ekVtTENtdUtiYmNCcWdXSG9iaExoS0VZUGttODIyc3FWR2s5Ylp4cUZQLzR0?= =?utf-8?B?T3Y4em02aXNGcUhWMTcwYXhiYkhsNWVhZTJWSU1VL0hGS3ZSUXcvZjFjMnVq?= =?utf-8?B?ZmU2SFd2NXdMRS9VdkxNRzFxOEN1TXdFWjFOcXdRamQxZGM4Vk1QQkprb21u?= =?utf-8?B?Vi8wSllnRmw4Qk9DN3RnSGRDQU9QOXpDd2E3YVV5bFp0Zk5rdmRrTHowdmR6?= =?utf-8?B?cHdEUDlIZ2IrVVM0R09SN29kTWx6N0tMa1VYcHJDVldkV3RTVmlkMmtrNUFa?= =?utf-8?B?cTU0SVE2bnlvMnBMNjlVMUNUZm5sRzZIKzN6QklsR25Md2RocjcwZ1RpOW83?= =?utf-8?B?K3V0YWxPZ0dkdmxwNDUwZEJLT2lnZHFtd2liTnYxVndtRk5pUnp3Y0JJVHlz?= =?utf-8?Q?c0ed76aK3anHzx1UPS?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2942c721-1277-418e-bc0f-08df0dc01d2a X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 15:44:48.5324 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sfRJXV2NR0FgilVsT6+QHdVji/HcNkfjCIduQjGWJd6mj1bOCPnzJy91HGcXIOh9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSSPR12MB999211 X-purgate-ID: tlsNG-ef75cf/1788882295-A7ED6AE4-AC36BC75/0/0 X-purgate-type: clean X-purgate-size: 1937 On Tue Sep 8, 2026 at 11:16 AM EDT, David Hildenbrand (Arm) wrote: > On 9/8/26 04:56, Zi Yan wrote: >> gnttab_alloc_pages() stores xen_page_foreign in page->private. On 32-bit= , a >> pointer to an allocated xen_page_foreign is stored; on 64-bit, >> xen_page_foreign is stored inline. Checking page->private !=3D NULL is e= nough >> to tell whether a xen_page_foreign needs to be freed on 32-bit and >> page->private is zeroed unconditionally on 64-bit. >>=20 >> It prepares for a future commit that remove PG_private. >>=20 >> No functional change intended. >>=20 >> Assisted-by: Claude:claude-opus-4-8 >> Assisted-by: Codex:gpt-5 >> Signed-off-by: Zi Yan >> To: Juergen Gross >> To: Stefano Stabellini >> Cc: Oleksandr Tyshchenko >> Cc: xen-devel@lists.xenproject.org >> Cc: linux-kernel@vger.kernel.org >> --- >> drivers/xen/balloon.c | 5 +++++ >> drivers/xen/grant-table.c | 11 +++++------ >> 2 files changed, 10 insertions(+), 6 deletions(-) >>=20 >> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >> index e7f74ea7cd5eb..fdb18348cfdfe 100644 >> --- a/drivers/xen/balloon.c >> +++ b/drivers/xen/balloon.c >> @@ -182,6 +182,11 @@ static struct page *balloon_retrieve(bool require_l= owmem) >> =20 >> __ClearPageOffline(page); >> dec_node_page_state(page, NR_BALLOON_PAGES); >> + /* >> + * clear page->private before giving it out, since it might be used to >> + * store xen_page_foreign info. >> + */ >> + set_page_private(page, 0); > > Who would have set it to !=3D 0 in the first place? No one else, except > > e.g., gnttab_free_pages() resets it to 0 now before calling > xen_free_unpopulated_pages(). After reading more, I agree with you that the above change is unnecesary and will remove it in the next version. Thanks. --=20 Best Regards, Yan, Zi From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:47:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:47:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412240.1642780 (Exim 4.92) (envelope-from ) id 1x3y2v-0005qj-3w; Tue, 08 Sep 2026 15:47:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412240.1642780; Tue, 08 Sep 2026 15:47:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3y2v-0005qc-19; Tue, 08 Sep 2026 15:47:41 +0000 Received: by outflank-mailman (input) for mailman id 1412240; Tue, 08 Sep 2026 15:47:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3y2t-0005qW-7h for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:47:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3y2s-004YPJ-Cn for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:47:38 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa02e17-bab6-0a2a0a5309dd-0a2a4505b926-6 for ; Tue, 08 Sep 2026 17:47:38 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa02e19-4cb1-0a2a45050019-b9ff1c229485-3 for ; Tue, 08 Sep 2026 17:47:38 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a081b40589000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 08 Sep 2026 15:47:33 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 0EF7E81E3D; Tue, 8 Sep 2026 17:47:33 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=iobqbY4hXcgl0TKnlbtRriDRQECHZAFhR21sU2egqo8=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=M77+4bfeJKBHs1i4JrFEU/y33odOEEHf+CVU+JKewss7AsLK65CkHDNZstBW89t4A0R9rjXP/ xWzNE2OEudGUT5g606CpxC8wBW5z+38l/r+lQ1I3JW9rTi85m2yYpoKp5gADrHpFfyXXzAypaBX Vt2Xbb0wYFMl2M1A6dCJtnnLQVvK1J2LRlpnxr4CnTOVNEJ5HIMbwZDgOyMF/wXAWFQTipAFiT/ l1YNtRDTpqfLUHQeJ+kJ7Jt1U6RhKTiwhUxgVCg5RsD2SEx0IB+pYLwCLuJuJxL/T1XlBAouu+g DaVblQ/795DA2a71lf9NTxcj7+NBLAFOr42lwqq08FtQ== X-Zone-Loop: 970be37ace34271542d862f43924bebadcc113fba6b1 x-campaign-type: default x-transaction-id: a4c5344e-8a63-4b2c-a7a8-2ba981e482a5 x-swg-uid: 01-8ca27ab0-8393-4503-b7a4-20a5be144845 X-Mailer: Sweego Message-ID: <1788882453.8631fc262581453bbf619ec5b2062170.1a081b40589000c4f3@vates.tech> x-swg-bid: 1788882453.8631fc262581453bbf619ec5b2062170.1a081b40589000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest From: Baptiste Le Duc To: Jan Beulich Cc: Oleksii Kurochko , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc In-Reply-To: References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> <1788796634.8631fc262581453bbf619ec5b2062170.1a07c96862b000c4f3@vates.tech> <2f734f0a-7f3e-4e27-82ed-52ccf72fe49a@gmail.com> <72b89a0c-ad0e-4c1d-97f7-92f49ede7a55@gmail.com> Date: Tue, 08 Sep 2026 17:47:27 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788882453; l=2072; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=uRTs1NB5ei0hRJUPFWWuFHGD3/kb2+HU9VJNB94eJB0=; b=BCr0SMUn08tyEsLZRlDyLA9W2rb5XPa0z6+BNe/xmOIeQpR/2Za9vcCVumPPIfYk5GVWpXCJ9 RmqpyLKl1/cDEURihL+na/Q0R4on3by0fm6ZAkIxdevoEGpwODJQU4d X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788882453275 X-purgate-ID: tlsNG-c201ff/1788882458-720AA2A1-FA8700D6/0/0 X-purgate-type: clean X-purgate-size: 2076 On 2026-09-08 17:05 +0200, Jan Beulich wrote: > On 08.09.2026 16:58, Oleksii Kurochko wrote: > > On 9/8/26 12:01 PM, Oleksii Kurochko wrote: > >> On 9/7/26 5:57 PM, Baptiste Le Duc wrote: > >>>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h > >>>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > >>>> @@ -109,6 +109,12 @@ > >>>>   #define SIP_SSIP            MIP_SSIP > >>>>   #define SIP_STIP            MIP_STIP > >>>> +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ > >>>> +#define STVEC_MODE_MASK            _UL(0x3) > >>>> +#define STVEC_MODE_DIRECT        _UL(0x0) > >>>> +#define STVEC_MODE_VECTORED        _UL(0x1) > >>>> +#define STVEC_BASE_MASK            (~STVEC_MODE_MASK) > >>> Nit: STVEC_MODE_DIRECT and STVEC_MODE_VECTORED aren't used anywhere in > >>> this patch (only STVEC_BASE_MASK is). Either use them where you decide > >>> exceptions always target BASE regardless of MODE, or drop them until a > >>> patch that needs them. > >> > >> IMO it is fine to introduce *_DIRECT/VECORED here as they are used > >> implicitly through STVEC_BASE_MASK and thereby it will be better to > >> introduce them here now instead of open-code them and then just update > >> STVEC_BASE_MASK again when *_DIRECT/VECORED will be re-introduced. > >> > > > > Oh, sorry, you are right. STVEC_MODE_DIRECT and STVEC_MODE_VECTORED are > > really not used here (in this implementation). I planned to do: > > > > #define STVEC_MODE_MASK (STVEC_MODE_DIRECT | STVEC_MODE_VECTORED) > > > > But I missed to do in that way. > > > > I will update the defintion of STVEC_MODE_MASK in suggested above way. > > But that's yield a mask value of 1, when you want it to be 3. That ORing > together looks bogus to me anyway. > Yes I agree. It might be enough, for the moment, to only keep #define STVEC_MODE_MASK _UL(3) and drop the others defines (even STVEC_BASE_MASK as Jan mentioned the comment in the caller is already precise enough). > > Jan > > From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:49:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:49:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412248.1642790 (Exim 4.92) (envelope-from ) id 1x3y50-0006Vk-EW; Tue, 08 Sep 2026 15:49:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412248.1642790; Tue, 08 Sep 2026 15:49:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3y50-0006Vd-Bw; Tue, 08 Sep 2026 15:49:50 +0000 Received: by outflank-mailman (input) for mailman id 1412248; Tue, 08 Sep 2026 15:49:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3y4z-0006VT-Fm for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:49:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3y4y-009O9S-GU for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:49:48 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa02e73-2eae-0a2a0a5409dd-0a2a4506ec94-46 for ; Tue, 08 Sep 2026 17:49:48 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa02e9b-195a-0a2a45060019-b9ff1c2293dd-3 for ; Tue, 08 Sep 2026 17:49:47 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a081b5fc57000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 08 Sep 2026 15:49:42 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id D1E2A81E3D; Tue, 8 Sep 2026 17:49:41 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=PjSKXYrFDqF1tvOk46fFDGwrgwt46WQi78Ek5Z9BM/c=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=TGaazBb6pbi0CVEVn2LeloQndE9qKh/IPgIumbFTFbhtUOfsBJGJZ3UbHxC5B9NBz76pmeP7s aujF/6nZF7HQ+dEToD6YCVviiLD0t95X8VQ894d6zD5rJkcNO55q3jjQ/HmdP8/g+xgQ2eHjBll dDzcp44nuomxssdhDxQECWbXYC9MITYRI0DHb/MjkSNnz/Mpeib2PgwYMbjGVibryamW0+x4Yv5 zCeRc27kfo3+l/JzFB8Ge/jj9h1qGA3Wvyu3oK85xq55LM1a0KmrUv5AtySld2S4Tgqpovg3HEr uHt7fXSJtwboiALv7wmnAt+mCxH5cjDeFMdVmX3om14A== X-Zone-Loop: b3ead5be65518e820b1ada6b7346fc55ec353665d055 x-campaign-type: default x-transaction-id: 30865c66-a9ba-418e-8c07-36b2701edc16 x-swg-uid: 01-a0ff05e6-b74b-4197-92af-c4610b584eff X-Mailer: Sweego Message-ID: <1788882582.8631fc262581453bbf619ec5b2062170.1a081b5fc57000c4f3@vates.tech> x-swg-bid: 1788882582.8631fc262581453bbf619ec5b2062170.1a081b5fc57000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 20/39] xen/riscv: detect Shtvala From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: <611683b3d2e3b836d08d0499f7caff782ba80a34.1787838835.git.oleksii.kurochko@gmail.com> <1788796635.8631fc262581453bbf619ec5b2062170.1a07c968805000c4f3@vates.tech> Date: Tue, 08 Sep 2026 17:49:36 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788882581; l=2253; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=BClAJEILSN8n/Pp6M9gTs3jT7uCGm8KrxYpyibuUaAU=; b=BWUZ85tFE/nx9Jf6P9sjZc2pq0Vf/NnPgyLkLWdvR2VLzYRVXSyX6pQGn5AnBN6Ew2rgNjwgr qQ4g11pdYALB/86mpjnHCv+W2MEZCbH4cGAC385YXxZsWAkeYVmbLQI X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788882582070 X-purgate-ID: tlsNG-16d1c6/1788882587-1EEC477B-631A84D6/10/73395122804 X-purgate-type: spam X-purgate-size: 2257 On 2026-09-08 12:15 +0200, Oleksii Kurochko wrote: > > > On 9/7/26 5:57 PM, Baptiste Le Duc wrote: > >> Shtvala says that htval is written with the faulting guest physical address > >> on a guest-page fault. The H extension itself allows an implementation to > >> write htval with either that address or with zero, so where the extension is > >> absent a zero htval cannot be told apart from a genuine fault on guest > >> physical address 0-3. > >> > >> It is not offered to guests. Shtvala describes the HS-mode trap interface, > >> which a VS-mode guest never sees, and the H extension it belongs to is > >> already withheld from guests. Its guest-facing counterpart is a separate > >> extension, Shvstvala. > >> > >> Signed-off-by: Oleksii Kurochko > >> > > I thought this commit message is not very clear. Here is a more direct > > suggestion: > > > > ``` > > The H extension allows htval, on a guest-page fault, to be written with > > either the faulting guest physical address or zero. Shtvala extension > > removes the ambiguity of this zero-write by guaranteeing that htval is > > written with the faulting guest physical address in every circumstance > > permitted by the ISA. > > > > Not offered to guests: Shtvala describes htval, an HS-mode-only trap > > register a VS-mode guest never touches and the H extension it belongs to > > is already hidden from guests. The guest-visible equivalent is a > > separate extension, Shvstvala, covering vstval instead. > > ``` > > Sounds good to me. I will apply your suggestion. > > > > > Btw, I saw Linux has Documentation/devicetree/bindings/riscv/extensions.yaml > > which describes all of the extensions supported, don't you think it would > > be useful to have the same in docs/misc/devicetree/...? > > I think it could be useful. > > I think also about booting.txt already exitsted in the codebase. Would > you be okay with that? I think I will add the section to booting.txt and > pointing to riscv_isa_ext[] in cpufeature.c and so we won't miss an > update of doc if we will add or remove support of an extension. Does it > sound good to you? > Yes it sounds okay! Thanks > ~ Oleksii > > > > From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:55:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:55:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412254.1642798 (Exim 4.92) (envelope-from ) id 1x3yAf-000851-0p; Tue, 08 Sep 2026 15:55:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412254.1642798; Tue, 08 Sep 2026 15:55:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3yAe-00084u-UG; Tue, 08 Sep 2026 15:55:40 +0000 Received: by outflank-mailman (input) for mailman id 1412254; Tue, 08 Sep 2026 15:55:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3yAd-00084n-Sc for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:55:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3yAd-00Dtws-5I for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:55:39 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa02ff2-e002-0a2a0a5209dd-0a2a450ae898-44 for ; Tue, 08 Sep 2026 17:55:39 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa02ffa-f2d2-0a2a450a0019-d1558035bd28-3 for ; Tue, 08 Sep 2026 17:55:39 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49556f97a9dso40520805e9.1 for ; Tue, 08 Sep 2026 08:55:38 -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-49cf7740d44sm881426855e9.15.2026.09.08.08.55.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 08:55: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788882938; x=1789487738; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=T18GByUwBPJxm1HBGtNW/Ap/ZlYW2LSyeoW6v3TNUUI=; b=d/ZgOphAU/5mIupF6V0mUclTb3STLDN8nd5Be01OpZJgeFSEc/E9KML79c0qouegau LvLnk2+0i+zLjbjjnXXfJ3CWGatz4O3H2A9gFXTa9mtpZxfoax1giKzK9Fq6Qw8K64xr 1Ixbo0oGSPuzF9J5L553t7DMsd/cLizmBPql96m+l8l7ZSnkGwfdri6f7KpwW+hEIRQW YwOoc8PEzAqwfiZej7OsLGzA4YHmQ5ebj91S73LRLrICWGtGERmX5zcGb2WPdnKargn5 XnnCsx2sVIxs96v7VonBPVEm6072mGMoba8XDAfya/uCHyrePY8WZW4kYu3c2gLC0VYn 9loA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788882938; x=1789487738; h=content-transfer-encoding:content-type: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:content-type; bh=T18GByUwBPJxm1HBGtNW/Ap/ZlYW2LSyeoW6v3TNUUI=; b=dL1spWMwRJ1N8/P27tQI7k3s+M8ql5JAEGQzroWJN5r1MYX2dbDmbRiEzsDslvUVOa E5DkyX8cJCMUNKk0SbCzbqAY6ITTePZEVWRs+oiKNTAp7T+blYzp3dzq1Y2eP/Tn6gKA +KDd+2FmjYR50z6JhwgGozWfc8NSJgiUmYUwUcdccQuth7k/xTAW8H8BHCmUVM6FT2AY /7tACkco7qvOlpeIctc+vjhke9VQFAGikwBF4YzJrajCS9JzTtk8MLe48EVCZ6PNhB9c 5K8c4TpQmTKYX802vodIqC6bt6dkNxhVaIuvqOF3tsGRB9HwkV/me0f1W9mgwycDI8Rs 09sQ== X-Forwarded-Encrypted: i=1; AKwUvByk/cHOYxaryUvHbwwhQVXtiXfzDnnD5DlPUTXXe2OmuM8nQtgzhCxbNTQmVBsEYtFWlSP5zNEMAkM=@lists.xenproject.org X-Gm-Message-State: AFuF++mIDoB/gieiYu50CC7rQ43HZDv81awfWbhp1247c7LN1RIp947N 3NPSkM7jeJQW2eYpXgzhJU/aGP/vM2HRvUl9yZ7fhEwXiyiGXtIKw33gsM2b7uxjOw== X-Gm-Gg: AYBFou3hAXJgZutVZz8ANv/23JB5vreTjrfRJI5M/NFVQsiUGmOQrZHS/PDHFXjUHqA NqolkgUXlfPkljmXMb5gnW1pxfIT0RhwEkSE4bd5qf9txgYlPLf5svSn8D8ck6gtkVzXZ05wzh3 OHc29I2emSbNeuII+vl2fXH7WujdoBEo4mbWmOGTPcVBV5Mwq7RHToe8P+ZqvZRgDZJ4nRx/jM+ D2dK1CDLY+SpA19vpiaQYfh2OnDBHI3eW/o7O1TR3LmxIwXWhLBiiVPhwR8fGpHP9lGf90nt9dW 1P9f9yfk5yr5gis4e761d7UCYSnAUJnNYPNvIxSNZeCPavsqIXIOxqCAJd2WG5JbvjNWqAYvbEa LsV3xTePoJBdey9EpWPEZBsEMIJ9eAqE5w0Xxsj7kuEwJG7Wz/Duh/8fKj7ul5ROuZe8xn8KZzU mmavRS9JYNRC2t2w+gahvN4VApPhuLtYLBlojY6KE77Kl712F1fWB4+IzY7AXCopZC3ydImCn91 Ja+Vv9hJl5eb/wBdQLr7rMUD23AjGjkcYOyJSsBxkUreBhyQyoL X-Received: by 2002:a05:600c:1986:b0:49c:fa21:e744 with SMTP id 5b1f17b1804b1-49cfa21e906mr246470085e9.26.1788882938434; Tue, 08 Sep 2026 08:55:38 -0700 (PDT) Message-ID: <5b5a8303-b018-4b5a-a4d2-6eabd4c48559@suse.com> Date: Tue, 8 Sep 2026 17:55:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/14] x86/domain_page: drop redundant create_perdomain_mapping() call To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , George Dunlap , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-10-ecc269f268b7@xenproject.org> 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: <20260901-asi-part2-10-ecc269f268b7@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788882939-5A7DACFC-5E31D95D/0/0 X-purgate-type: clean X-purgate-size: 1469 On 02.09.2026 11:43, George Dunlap wrote: > --- a/xen/arch/x86/domain_page.c > +++ b/xen/arch/x86/domain_page.c > @@ -256,7 +256,7 @@ void unmap_domain_page_irqoff(const void *ptr) > do_unmap_domain_page(ptr, true); > } > > -int mapcache_domain_init(struct domain *d) > +void mapcache_domain_init(struct domain *d) > { > struct mapcache_domain *dcache = &d->arch.pv.mapcache; > unsigned int bitmap_pages; > @@ -265,7 +265,7 @@ int mapcache_domain_init(struct domain *d) > > #ifdef NDEBUG > if ( !mem_hotplug && max_page <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) ) > - return 0; > + return; > #endif > > BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 + > @@ -277,9 +277,6 @@ int mapcache_domain_init(struct domain *d) > (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); > > spin_lock_init(&dcache->lock); > - > - return create_perdomain_mapping(d, (unsigned long)dcache->inuse, > - 2 * bitmap_pages + 1, false); > } At this point rather than removing this, all of what is done ... > int mapcache_vcpu_init(struct vcpu *v) ... in this function (per-domain-mapping-wise) would want moving into mapcache_domain_init(). The present arrangement, aiui, is a leftover from when d->max_vcpus could change post-domain-creation. Question is - would that go against further ASI plans? (Likely the answer is "yes".) Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 15:58:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 15:58:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412263.1642807 (Exim 4.92) (envelope-from ) id 1x3yD3-0000Gw-CD; Tue, 08 Sep 2026 15:58:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412263.1642807; Tue, 08 Sep 2026 15:58:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3yD3-0000Gp-9Z; Tue, 08 Sep 2026 15:58:09 +0000 Received: by outflank-mailman (input) for mailman id 1412263; Tue, 08 Sep 2026 15:58:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3yD1-0000FQ-Sy for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 15:58:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3yD0-00AgR2-Tt for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:58:06 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa03089-8faa-0a2a0a5109dd-0a2a4509d370-12 for ; Tue, 08 Sep 2026 17:58:06 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0308e-be1a-0a2a45090019-4a7de18caf91-3 for ; Tue, 08 Sep 2026 17:58:06 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e2406so5770795e9.1 for ; Tue, 08 Sep 2026 08:58:06 -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-49cf7703cefsm542419305e9.5.2026.09.08.08.58.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 08:58:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788883086; x=1789487886; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=0FqjIpQ2V7YAmkR374RfNe0WAKCvDu36VQreGuLfgxI=; b=c01xPeJEwV/Uz35tA0KgRyEKLnOfaTfxQBcfZ11PZ8pf72UueCogXi63CCa4clYJtT /qHZO+68O8Q2gALuY60cF3tKjdFUY3KTyeXZd3MB/e8+GdO8YOQZYeYDzLp06m06nF/x Z64hU2qmjRd+Bulq/x6LKbFUdWN5OKkkGtmqb0Xtk77IFp9pOL/P8qpX3lT4M1gojJi8 56PKB9SxtrUbKJv+Z+H6TP4U96CYKFeFIt1foAGgByp3EdYuFNDB+wpI+0rjDuMEUFVs E63oO+fxzqkcl7uZCWw81Yp0P3TVzcDXzo6Gms5VcU7Co0R40bFrxuR1sFSEgI0ujmKZ fBaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788883086; x=1789487886; h=content-transfer-encoding:content-type: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:content-type; bh=0FqjIpQ2V7YAmkR374RfNe0WAKCvDu36VQreGuLfgxI=; b=nJWy/wVkCwrs9VVdYXdKd56UKcWfR9ZwrEYCc01gtiFE/AYvblS6Hc+gEoiDT2cIgV b0J2n1Z8dDY8r9LF95D6IjkVImir4++akbAYkvt1uFT9y7qJn0+ZbLM7FkvzSXCLQ1+6 1SH+cGRsZOGCf4Z0mFPGwVp3sRavfF2QY7Sde0rhZ9zDLe7oOmoh2zlRaejkZJfGaKyC zbWruzSjyzaOM1nrr8/A1FcOCsq/razxtUTttwReRlciI5PiIjoZXSkKSTvG0JufnaKa ieRt9hRiGMtDG9DDwHUVNiV5IOVIz/ZuSXtK2aR3+VDToqKYkR/uM6s7m1cAhAB0LKue NaYw== X-Forwarded-Encrypted: i=1; AKwUvBwkNeg8hNfte1K9qosCWXu/eHSUkmaq1bDrpo4Zj91VzqP3jTyQvPAuWu3QD6C0yTmyhRA4ZxTqlrk=@lists.xenproject.org X-Gm-Message-State: AFuF++lkyrGnKWqdrOfS+U/1ts4aZAeZYDXOY3FaYg7S6zkHeL1BQWcC T5sjgbs0rPvBuJVXV144Lbdij+mJWsXt7wKsB0eviRsHcmJ4HP0bBKMNGVtcxkKj7Q== X-Gm-Gg: AYBFou1XDwhh5u6ErGuEmhmKlBH/qYbVf3mxx2kwzNT6G6BpH1aYad9+bXpoVxIvBOV mbKj02eHZGLIpzNdKGWbF/jscogl8LKHgMVEPaPTdUiSbIHOJyihZ8k42zb0752PcsQcCRnKplt 0PldgHRf1alZJJrk/8odaV9kbOxXsdXBTWq5/zv7pDr0YNvgX9nvmV9QiY0L/dYoU1pQ+IsFTQr IoVdMf0IDyHBmMLAlreb2huoZXnQ21FPrqYAC5fQF1/AKXVCPRaIYQlWm3LvNUAjUIlnxmaDwe7 tUnEAtfVxpZHhi5FKLSmwuHo+f4rSdEk8HdSOrsGvwTVAdOmAi5ThGhezm3uH50wFrPOd8x/fn5 qF/Ne5w/AIXrsakvrwiNjshXkP8KhyzsEz57zllzSljMhpKQOe+m8AvFZMbJ3Ht4CqB5WwdIjcY NETyVHpPtb8CLK3ulYvASJNdZKMkFCAnDO9hYgZJEpheREj2WxFBH5IYhrVipV+5hUFX7cv72D+ HimGrpoXD8tNXTO+cc/31Lm9w/45rvigkFQLbx2PC8fRw95Zd5V X-Received: by 2002:a05:600c:a01:b0:49d:1916:2133 with SMTP id 5b1f17b1804b1-49d1916215amr56268315e9.8.1788883086303; Tue, 08 Sep 2026 08:58:06 -0700 (PDT) Message-ID: Date: Tue, 8 Sep 2026 17:58:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest To: Baptiste Le Duc Cc: Oleksii Kurochko , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> <1788796634.8631fc262581453bbf619ec5b2062170.1a07c96862b000c4f3@vates.tech> <2f734f0a-7f3e-4e27-82ed-52ccf72fe49a@gmail.com> <72b89a0c-ad0e-4c1d-97f7-92f49ede7a55@gmail.com> <1788882453.8631fc262581453bbf619ec5b2062170.1a081b40589000c4f3@vates.tech> 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: <1788882453.8631fc262581453bbf619ec5b2062170.1a081b40589000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1788883086-3A2C4034-22CFF9E1/0/0 X-purgate-type: clean X-purgate-size: 2228 On 08.09.2026 17:47, Baptiste Le Duc wrote: > On 2026-09-08 17:05 +0200, Jan Beulich wrote: >> On 08.09.2026 16:58, Oleksii Kurochko wrote: >>> On 9/8/26 12:01 PM, Oleksii Kurochko wrote: >>>> On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >>>>>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >>>>>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >>>>>> @@ -109,6 +109,12 @@ >>>>>>   #define SIP_SSIP            MIP_SSIP >>>>>>   #define SIP_STIP            MIP_STIP >>>>>> +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ >>>>>> +#define STVEC_MODE_MASK            _UL(0x3) >>>>>> +#define STVEC_MODE_DIRECT        _UL(0x0) >>>>>> +#define STVEC_MODE_VECTORED        _UL(0x1) >>>>>> +#define STVEC_BASE_MASK            (~STVEC_MODE_MASK) >>>>> Nit: STVEC_MODE_DIRECT and STVEC_MODE_VECTORED aren't used anywhere in >>>>> this patch (only STVEC_BASE_MASK is). Either use them where you decide >>>>> exceptions always target BASE regardless of MODE, or drop them until a >>>>> patch that needs them. >>>> >>>> IMO it is fine to introduce *_DIRECT/VECORED here as they are used >>>> implicitly through STVEC_BASE_MASK and thereby it will be better to >>>> introduce them here now instead of open-code them and then just update >>>> STVEC_BASE_MASK again when *_DIRECT/VECORED will be re-introduced. >>>> >>> >>> Oh, sorry, you are right. STVEC_MODE_DIRECT and STVEC_MODE_VECTORED are >>> really not used here (in this implementation). I planned to do: >>> >>> #define STVEC_MODE_MASK (STVEC_MODE_DIRECT | STVEC_MODE_VECTORED) >>> >>> But I missed to do in that way. >>> >>> I will update the defintion of STVEC_MODE_MASK in suggested above way. >> >> But that's yield a mask value of 1, when you want it to be 3. That ORing >> together looks bogus to me anyway. >> > Yes I agree. It might be enough, for the moment, to only keep #define > STVEC_MODE_MASK _UL(3) and drop the others defines (even STVEC_BASE_MASK as Jan > mentioned the comment in the caller is already precise enough). To me having STVEC_MODE_MASK without at least one of STVEC_MODE_{DIRECT,VECTORED} would feel odd / incomplete. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 08 16:05:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 16:05:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412273.1642818 (Exim 4.92) (envelope-from ) id 1x3yJm-0002Zw-67; Tue, 08 Sep 2026 16:05:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412273.1642818; Tue, 08 Sep 2026 16:05:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3yJm-0002Zp-2I; Tue, 08 Sep 2026 16:05:06 +0000 Received: by outflank-mailman (input) for mailman id 1412273; Tue, 08 Sep 2026 16:05:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3yJk-0002Zj-PL for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:05:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3yJj-00H5LV-K9 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 18:05:03 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa03224-bab6-0a2a0a5309dd-0a2a450ca092-18 for ; Tue, 08 Sep 2026 18:05:03 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0322f-f479-0a2a450c0019-b9ff1c12aaa9-3 for ; Tue, 08 Sep 2026 18:05:03 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a081c3f83a000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 08 Sep 2026 16:04:59 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 5212984143; Tue, 8 Sep 2026 18:04:58 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=2tlW4w1t6KCM3zSNeh8baEqLTz0vIS9H0ZxoyjGx+TU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=J+hVQtVHW7D6Tbidr52xdLMcjQbaS0dgt3nh0hzBUKCE2UbabBGyEU5PDIOb6EWqcaz8IdBo+ 21gjVoScq02xwsjCiTGzaCdWH83FQcNlVWKiS6NJ0w3L+WXSFhv4XiNIG+mQaG7zsDWwiKhsbsw ctekG1m7JWAdzj6PyWUmGvIaUlcgCAeqlAPPvyNvyDIMiuMOMKCvfJq0XPNOH06gHoPaleKsn2o HWQlsR8dX17yaANfllSRtyBR7I8dteYNaNJhZwzMhd+7Fn9SZE4lbjCDsRJemWBUln/cjUJXazf gcosLQqgY8F6sdVLpTGHeUu1NeXCDHBiwI7reGTTdU0A== X-Zone-Loop: 56dc10f638cd2653f32f0549df4d1d270ca9b9a27960 x-campaign-type: default x-transaction-id: 52de1e6c-a031-44ba-a3ba-319c9773a85c x-swg-uid: 01-c372b82d-2b3d-486e-9eaa-f0d317a11b63 X-Mailer: Sweego Message-ID: <1788883499.8631fc262581453bbf619ec5b2062170.1a081c3f83a000c4f3@vates.tech> x-swg-bid: 1788883499.8631fc262581453bbf619ec5b2062170.1a081c3f83a000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 17/39] xen/riscv: decouple INSN_PSEUDO_VS_* from the hypervisor's XLEN From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <9a7dea59-be4a-4dbd-9935-f48e24adc009@gmail.com> References: <2a69992aa02ff114237ec27204cfac0f8278b1d6.1787838835.git.oleksii.kurochko@gmail.com> <1788796633.8631fc262581453bbf619ec5b2062170.1a07c9682ec000c4f3@vates.tech> <9a7dea59-be4a-4dbd-9935-f48e24adc009@gmail.com> Date: Tue, 08 Sep 2026 18:04:52 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788883498; l=5639; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=YC1eJUqc9W5+Ahpoud4LWTaci9Jwr3Fbc43LuXWek1s=; b=1clSyFv4gaHHI8stmVZu3xTLOr1qtUg/sL5B+mgZSaV7IZ8J25dIhL9BUBsfgI6UhlasdG+mG GPqwJhTJpm0AKL/GVDTfmjccv97idhjQoRpi8lQqnwg1UDuthmzA5dF X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788883498541 X-purgate-ID: tlsNG-d25034/1788883503-766DEA5B-D2FA790F/10/73395122804 X-purgate-type: spam X-purgate-size: 5643 On 2026-09-08 11:34 +0200, Oleksii Kurochko wrote: > > > On 9/7/26 5:57 PM, Baptiste Le Duc wrote: > >> htinst reports a pseudoinstruction when a guest page fault is taken on an > >> implicit memory access done for VS-stage address translation. Four such > >> values are defined, differing in the access type (read or write) and in the > >> access width: 4 bytes (0x2000/0x2020) or 8 bytes (0x3000/0x3020). > >> > >> That width is the width of a VS-stage PTE, i.e. it follows the guest's > >> paging mode (4 bytes for Sv32, 8 bytes for Sv39 and wider) and has nothing > >> to do with the XLEN Xen itself is built for. Selecting just one pair with > >> where a guest running with VSXL=32 and Sv32 in vsatp produces the 4-byte > > Sentence is broken. Guess you mean "Selecting just one pair based on Xen's XLEN misses the case where > > …". > > Likely it is becuase of my low level English but it seems that original > version wast okay and what you added is just a part from prev. sentence > but I will add your suggestion for better clearness. Thanks for noticing > that! > > > > >> forms. Such an htinst would not be recognized as a pseudoinstruction and the > >> fault would be mistaken for an ordinary MMIO trap: Xen would fetch and > >> decode whatever instruction sepc happens to point at (unrelated to the > >> access which faulted) and emulate it against a guest physical address > >> derived from htval, which for an implicit access holds the address of a > >> VS-stage PTE rather than of any access the guest performed. > >> > >> Define all four values unconditionally instead, named after the access width > >> they encode rather than after the build's XLEN. On RV32 the 8-byte forms > >> simply never occur, so recognizing them costs nothing. > >> > >> Dropping the ladder loses no build-time coverage: a build for an XLEN other > >> than 32 or 64 already fails on the equivalent ladders in asm/asm.h and > >> asm/config.h, so no replacement #error is needed here. Adding one keyed on > >> CONFIG_RISCV_* would in any case re-introduce exactly the conflation this > >> patch removes. > >> > >> This diverges from the imported version of riscv_encoding.h. > >> > >> No functional change: the values have no user yet. > >> > >> Signed-off-by: Oleksii Kurochko > >> > >> diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h > >> index c63e5e3046..2d2e7e11b3 100644 > >> --- a/xen/arch/riscv/include/asm/riscv_encoding.h > >> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > >> @@ -839,25 +839,17 @@ > >> #define INSN_MASK_FENCE_TSO 0xffffffff > >> #define INSN_MATCH_FENCE_TSO 0x8330000f > >> > >> -#if __riscv_xlen == 64 > >> - > >> /* 64-bit read for VS-stage address translation (RV64) */ > >> -#define INSN_PSEUDO_VS_LOAD 0x00003000 > >> +#define INSN_PSEUDO_VS_LOAD64 0x00003000 > >> > >> /* 64-bit write for VS-stage address translation (RV64) */ > >> -#define INSN_PSEUDO_VS_STORE 0x00003020 > >> - > >> -#elif __riscv_xlen == 32 > >> +#define INSN_PSEUDO_VS_STORE64 0x00003020 > >> > >> /* 32-bit read for VS-stage address translation (RV32) */ > >> -#define INSN_PSEUDO_VS_LOAD 0x00002000 > >> +#define INSN_PSEUDO_VS_LOAD32 0x00002000 > >> > >> /* 32-bit write for VS-stage address translation (RV32) */ > >> -#define INSN_PSEUDO_VS_STORE 0x00002020 > >> - > > Whole point of patch is these no longer depend on build XLEN, yet > > comments still say "(RV64)"/"(RV32)" which could be confusing. Maybe it > > should be better to indicate, as the spec does, that RV32 values are > > used when VSXLEN=32 (only sv32 paging mode) and RV64 values when > > VSXLEN=64 (sv39+ paging modes). > > > > Could you please clarify to me what in the spec it is? It is the same table as you indicated below (but mine is Table 56, so it seems we don't have the same spec version, I'm using the version 20260120). When I found unclear is that "RV32" or "RV64" alone is ambiguous, since host and guest can differ (e.g. RV64 host running an RV32 guest). Saying it depends on VSXLEN instead makes clear which one is meant. > > This comments are just copy from the spec: > > Table 39. Special pseudoinstruction values for guest-page faults. The > RV32 values are used when VSXLEN=32, and the RV64 values when VSXLEN=64. > Value Meaning > 0x00002000 32-bit read for VS-stage address translation (RV32) > 0x00002020 32-bit write for VS-stage address translation (RV32) > > Value Meaning > 0x00003000 64-bit read for VS-stage address translation (RV64) > 0x00003020 64-bit write for VS-stage address translation (RV64) > > So the comments are just copy of "Meaning" column from the spec. > > And I think that Meaning column is fine here as we could have a case of > when hypervisor has XLEN=64 but guests could be on it RV32 and RV64 and > if a guest is RV32 (what means VSXLEN=32) then the comment above > defintion mean that we hav 32-bit read/write VS-stage address > translation for (RV32) guest and the similar is for RV64. > > Do I miss something? Is a comments make more sense now or I have to > still update them in some way? > I think it would be more clear to modify the comment by that: /* 32-bit read for VS-stage address translation (VSXLEN=32) */ But now with your explanation, your comment is more clear as it specify VS-stage address, so the guest. Feel free to adopt my version or not. > > Thanks! > > ~ Oleksii > > > > From xen-devel-bounces@lists.xenproject.org Tue Sep 08 16:27:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 16:27:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412284.1642826 (Exim 4.92) (envelope-from ) id 1x3yeu-0005yz-Pv; Tue, 08 Sep 2026 16:26:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412284.1642826; Tue, 08 Sep 2026 16:26:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3yeu-0005ys-NG; Tue, 08 Sep 2026 16:26:56 +0000 Received: by outflank-mailman (input) for mailman id 1412284; Tue, 08 Sep 2026 16:26:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x3yet-0005ym-Di for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 16:26:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3yes-00H8cn-6p for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 18:26:54 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0374e-bab6-0a2a0a5309dd-0a2a45088f14-0 for ; Tue, 08 Sep 2026 18:26:54 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0374d-f659-0a2a45080019-b9ff1c228025-3 for ; Tue, 08 Sep 2026 18:26:54 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a081d7fd55000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 08 Sep 2026 16:26:51 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 4A75281F1A; Tue, 8 Sep 2026 18:26:50 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=BNooUJFj17vn28id/72MdZJ4fzxtNpDNa+NRhcUCBbw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=RsVyBJt9IFo+hbEfjVJNGOBsNJSxj7li1347PjjBy9buA2hxyr6VVYHaN3d4jpGCbSA9R0gkz mhqOPg8jMqWSGtOgUbHP6jRlCWiZcd6X8S1V1Q1YM7FHO7x4h+5mgE2btoDjKl3cJQHH3FXNg6v P7JMSl2dqtT3jUZy3O6oA8Cg93PXQMIJmjBC3M2oYTbz9U4lVkN/06hSp5xTE5XkFVgRAaiWoEW mYknxCgYuQeDUgI9zUBJRbH19AvPl00Vu4EYKg5SUnNCL7F2rgaEU9HSoBXsAsVkNJy914a1nwF CZ8kn6J+2pgk9hKHWdyMHI8jt5qlqVycRcsmD74FUPfQ== X-Zone-Loop: abd2896f67ed2cc50327b62c8baec90b322af8521612 x-campaign-type: default x-transaction-id: ee76e8a8-0e35-44ba-8341-3f5de6c70e60 x-swg-uid: 01-fa1edfc4-1213-4681-9b1c-bc1324a11eb0 X-Mailer: Sweego Message-ID: <1788884811.8631fc262581453bbf619ec5b2062170.1a081d7fd55000c4f3@vates.tech> x-swg-bid: 1788884811.8631fc262581453bbf619ec5b2062170.1a081d7fd55000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <11432bb6-009c-4563-9339-ddfbed1b50dc@gmail.com> References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> <1788796633.8631fc262581453bbf619ec5b2062170.1a07c968185000c4f3@vates.tech> <11432bb6-009c-4563-9339-ddfbed1b50dc@gmail.com> Date: Tue, 08 Sep 2026 18:26:44 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788884810; l=14056; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=gNReYr2HTUbjitpcHBdI2MNLWZe1QxeVTIFDsCQ5eac=; b=kmQDj47enyE5Ma98pLvrKna06kW3IxR/U9FmRJOaE0TUoBI0Ws4EpD2ST+EL6UBAIJ/KHpwH4 anZnr/B2FmeCjmCoa9NF1XwD5uI4Mf24dkz6Vy8E+g0ACB7l1B8O6Pg X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788884810515 X-purgate-ID: tlsNG-c1860d/1788884814-D795A87B-C1DC85C3/10/73395122804 X-purgate-type: spam X-purgate-size: 14060 On 2026-09-08 11:19 +0200, Oleksii Kurochko wrote: > > > On 9/7/26 5:57 PM, Baptiste Le Duc wrote: > >> Extend the RISC-V exception table format to include a type and > >> auxiliary data field. > >> > >> The existing format only supports simple fixups. Some use cases require > >> additional context from the fault (e.g. capturing trap information), > >> which cannot be expressed with the current EX_TYPE_FIXUP entries. > >> > >> Introduce a generic ASM_EXTABLE_RAW() helper to describe entries with a > >> handler type and associated data. Reimplement ASM_EXTABLE() in terms of > >> it using EX_TYPE_FIXUP for compatibility. > >> > >> Add EX_TYPE_TRAP_INFO to allow handlers to retrieve trap state > >> (sepc/scause/stval) and pass it to the fixup path. The data field is > >> used to encode which GPR contains a pointer to a struct trap_info. > >> > >> Provide ASM_EXTABLE_TRAP_INFO() as a convenience wrapper for this case. > >> > >> Also add gpr-num.h, providing symbolic GPR numbers for use in assembly > >> and inline asm. This is derived from Linux 6.16 with minor adjustments such > >> as using .irp instead of open-coding the same using a set of .equ. > >> > >> Update the exception handling code to dispatch based on the entry type. > >> > >> Signed-off-by: Oleksii Kurochko > >> > >> diff --git a/xen/arch/riscv/extable.c b/xen/arch/riscv/extable.c > >> index 5b89c4278c..6470198d01 100644 > >> --- a/xen/arch/riscv/extable.c > >> +++ b/xen/arch/riscv/extable.c > >> @@ -6,8 +6,10 @@ > >> #include > >> #include > >> > >> +#include > >> #include > >> #include > >> +#include > >> > >> #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field) > >> > >> @@ -32,6 +34,12 @@ static void __init cf_check swap_ex(void *a, void *b) > >> > >> x->fixup = y->fixup + delta; > >> y->fixup = tmp.fixup - delta; > >> + > >> + x->type = y->type; > >> + y->type = tmp.type; > >> + > >> + x->data = y->data; > >> + y->data = tmp.data; > >> } > >> > >> static int cf_check cmp_ex(const void *a, const void *b) > >> @@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_table_entry *ex, > >> regs->sepc = ex_fixup(ex); > >> } > >> > >> -bool fixup_exception(struct cpu_user_regs *regs) > >> +#define CHECK_GPR_INDEX(num, name) \ > >> + BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) \ > >> + != (num) * sizeof(unsigned long)); > >> + > >> +static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, > >> + unsigned int num) > >> +{ > >> + /* > >> + * The GPR number -> struct index mapping below relies on x0..x31 being > >> + * laid out at the start of struct cpu_user_regs in architectural order, > >> + * matching the register numbers GPR_LIST() hands to the assembler. > >> + */ > >> + GPR_LIST(CHECK_GPR_INDEX) > >> + > >> + ASSERT(num < 32); > >> + > >> + return ((const unsigned long *)regs)[num]; > >> +} > >> + > >> +#undef CHECK_GPR_INDEX > >> + > >> +static void ex_handler_trap_info(const struct exception_table_entry *ex, > >> + struct cpu_user_regs *regs, > >> + unsigned long cause) > >> +{ > >> + struct trap_info *trap_info = > >> + (struct trap_info *)regs_get_gpr(regs, ex->data); > >> + > >> + BUG_ON(!trap_info); > >> + > >> + /* > >> + * Only stval still needs a CSR read: sepc and scause were already > >> + * captured by the trap entry path and do_trap() respectively. Latch > >> + * trap_info->sepc before regs->sepc is pointed at the fixup code. > >> + */ > >> + trap_info->sepc = regs->sepc; > >> + trap_info->scause = cause; > >> + trap_info->stval = csr_read(CSR_STVAL); > >> + > >> + regs->sepc = ex_fixup(ex); > >> +} > >> + > >> +bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause) > >> { > >> unsigned long pc = regs->sepc; > >> const struct virtual_region *region = find_text_region(pc); > >> @@ -77,7 +127,23 @@ bool fixup_exception(struct cpu_user_regs *regs) > >> if ( !ex ) > >> return false; > >> > >> - ex_handler_fixup(ex, regs); > >> + switch ( ex->type ) > >> + { > >> + case EX_TYPE_FIXUP: > >> + ex_handler_fixup(ex, regs); > >> + break; > >> + > >> + case EX_TYPE_TRAP_INFO: > >> + ex_handler_trap_info(ex, regs, cause); > >> + break; > >> + > >> + default: > >> + printk(XENLOG_ERR > >> + "Unsupported exception table entry type %u for pc %#lx\n", > >> + ex->type, pc); > >> + > >> + return false; > >> + } > >> > >> return true; > >> } > >> diff --git a/xen/arch/riscv/include/asm/extable.h b/xen/arch/riscv/include/asm/extable.h > >> index c0128a9181..7378f86e7e 100644 > >> --- a/xen/arch/riscv/include/asm/extable.h > >> +++ b/xen/arch/riscv/include/asm/extable.h > >> @@ -3,17 +3,24 @@ > >> #ifndef ASM__RISCV__ASM_EXTABLE_H > >> #define ASM__RISCV__ASM_EXTABLE_H > >> > >> +#include > >> + > >> +#define EX_TYPE_FIXUP 0 > >> +#define EX_TYPE_TRAP_INFO 1 > >> + > >> #ifdef __ASSEMBLER__ > >> > >> -#define ASM_EXTABLE(insn, fixup) \ > >> - .pushsection .ex_table, "a"; \ > >> - .balign 4; \ > >> - .word (insn) - .; \ > >> - .word (fixup) - .; \ > >> +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ > >> + .pushsection .ex_table, "a"; \ > >> + .balign 4; \ > >> + .word (insn) - .; \ > >> + .word (fixup) - .; \ > >> + .half (type); \ > >> + .half (data); \ > >> .popsection > >> > >> -.macro asm_extable, insn, fixup > >> - ASM_EXTABLE(\insn, \fixup) > >> +.macro _asm_extable, insn, fixup > >> + ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0) > >> .endm > >> > >> #else /* __ASSEMBLER__ */ > >> @@ -23,20 +30,36 @@ > >> > >> struct cpu_user_regs; > >> > >> -#define ASM_EXTABLE(insn, fixup) \ > >> - ".pushsection .ex_table, \"a\"\n" \ > >> - ".balign 4\n" \ > >> - ".word (" #insn " - .)\n" \ > >> - ".word (" #fixup " - .)\n" \ > >> +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ > >> + ".pushsection .ex_table, \"a\"\n" \ > >> + ".balign 4\n" \ > >> + ".word (" insn ") - .\n" \ > >> + ".word (" fixup ") - .\n" \ > >> + ".half (" type ")\n" \ > >> + ".half (" data ")\n" \ > >> ".popsection\n" > >> > >> +#define ASM_EXTABLE(insn, fixup) \ > >> + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_FIXUP), "0") > >> + > >> +#define EX_TRAP_INFO_REG(gpr) \ > >> + "(.L_gpr_num_" #gpr ")" > >> + > >> +#define ASM_EXTABLE_TRAP_INFO(insn, fixup, data) \ > >> + DEFINE_ASM_GPR_NUMS \ > >> + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_TRAP_INFO), \ > >> + EX_TRAP_INFO_REG(data)) > >> + > >> /* > >> - * The exception table consists of pairs of relative offsets: the first > >> - * is the relative offset to an instruction that is allowed to fault, > >> - * and the second is the relative offset at which the program should > >> - * continue. No general-purpose registers are modified by the exception > >> - * handling mechanism itself, so it is up to the fixup code to handle > >> - * any necessary state cleanup. > >> + * Each exception table entry consists of two relative offsets and a > >> + * handler description: `insn` is the relative offset to an instruction > >> + * that is allowed to fault, `fixup` is the relative offset at which the > >> + * program should continue, `type` selects how the exception is handled > >> + * (EX_TYPE_*), and `data` holds auxiliary information for the handler > >> + * (e.g. for EX_TYPE_TRAP_INFO, the number of the GPR that contains a > >> + * pointer to a struct trap_info). No general-purpose registers are > >> + * modified by the exception handling mechanism itself, so it is up to > >> + * the fixup code to handle any necessary state cleanup. > >> * > >> * The exception table and fixup code live out of line with the main > >> * instruction path. This means when everything is well, we don't even > >> @@ -45,14 +68,15 @@ struct cpu_user_regs; > >> */ > >> struct exception_table_entry { > >> int32_t insn, fixup; > >> + uint16_t type, data; > >> }; > >> > >> extern struct exception_table_entry __start___ex_table[]; > >> extern struct exception_table_entry __stop___ex_table[]; > >> > >> void sort_exception_tables(void); > >> -bool fixup_exception(struct cpu_user_regs *regs); > >> +bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause); > >> > >> -#endif /* __ASSEMBLY__ */ > >> +#endif /* __ASSEMBLER__ */ > >> > >> #endif /* ASM__RISCV__ASM_EXTABLE_H */ > >> diff --git a/xen/arch/riscv/include/asm/gpr-num.h b/xen/arch/riscv/include/asm/gpr-num.h > >> new file mode 100644 > >> index 0000000000..3b97a72e6c > >> --- /dev/null > >> +++ b/xen/arch/riscv/include/asm/gpr-num.h > >> @@ -0,0 +1,37 @@ > >> +/* SPDX-License-Identifier: GPL-2.0-only */ > >> +#ifndef RISCV_GPR_NUM_H > >> +#define RISCV_GPR_NUM_H > > Nit: commit message says this is derived from Linux 6.16. Other > > imported RISC-V headers here carry an in-file note (bitops.h: "Based on > > linux/arch/.../bitops.h") but this file doesn't. > >> +/* > >> + * GPRs by ABI name, together with their register number (x0 .. x31). > >> + * > >> + * This is the single source of truth for the mapping: it generates the > >> + * .L_gpr_num_ assembler symbols used to turn a register name emitted > >> + * by the compiler into a register number, and struct cpu_user_regs is > >> + * checked against it at build time (see regs_get_gpr()). Neither list can > >> + * therefore be changed without the other. > >> + */ > >> +#define GPR_LIST(x) \ > >> + x(0, zero) x(1, ra) x(2, sp) x(3, gp) \ > >> + x(4, tp) x(5, t0) x(6, t1) x(7, t2) \ > >> + x(8, s0) x(9, s1) x(10, a0) x(11, a1) \ > >> + x(12, a2) x(13, a3) x(14, a4) x(15, a5) \ > >> + x(16, a6) x(17, a7) x(18, s2) x(19, s3) \ > >> + x(20, s4) x(21, s5) x(22, s6) x(23, s7) \ > >> + x(24, s8) x(25, s9) x(26, s10) x(27, s11) \ > >> + x(28, t3) x(29, t4) x(30, t5) x(31, t6) > >> + > >> +#ifdef __ASSEMBLER__ > >> + > >> +#define GPR_NUM_EQU(num, name) .equ .L_gpr_num_##name, num; > >> +GPR_LIST(GPR_NUM_EQU) > >> +#undef GPR_NUM_EQU > >> + > >> +#else /* __ASSEMBLER__ */ > >> + > >> +#define GPR_NUM_EQU(num, name) ".equ .L_gpr_num_" #name ", " #num "\n" > >> +#define DEFINE_ASM_GPR_NUMS GPR_LIST(GPR_NUM_EQU) > >> + > >> +#endif /* __ASSEMBLER__ */ > >> + > >> +#endif /* RISCV_GPR_NUM_H */ > >> diff --git a/xen/arch/riscv/include/asm/processor.h b/xen/arch/riscv/include/asm/processor.h > >> index b1745c1071..e7b0f2321a 100644 > >> --- a/xen/arch/riscv/include/asm/processor.h > >> +++ b/xen/arch/riscv/include/asm/processor.h > >> @@ -12,7 +12,19 @@ > >> > >> #ifndef __ASSEMBLER__ > >> > >> -/* On stack VCPU state */ > >> +/* > >> + * On stack VCPU state. > >> + * > >> + * x0..x31 must remain at the start of this structure, in architectural > >> + * register-number order: code which resolves a register number to its saved > >> + * value indexes this structure directly (instruction emulation via > >> + * REG_PTR() from asm/riscv_encoding.h, exception table fixups via > >> + * regs_get_gpr()). ->zero therefore has to stay at offset 0 and must always > >> + * read as 0, since it supplies the value of x0 when x0 is used as a source > >> + * operand. The layout is checked against GPR_LIST() at build time; see > >> + * regs_get_gpr() in extable.c. Do not reorder these fields or insert > >> + * anything between them. > >> + */ > >> { > >> unsigned long zero; > > Comment claims ->zero "must always read as 0" as it's hard-wired to zero > > by the HW, but nothing enforces that, it's still a plain writable > > unsigned long. Maybe a write-side counterpart that special-cases num==0 > > as a no-op, or with a minimum ASSERT(num != 0) / BUG_ON(num == 0) to > > anticipate any future forbidden writes. > > > > Could you please clarify where do you want me to put this check in this > patch? In regs_get_gpr()? There is no write-side in this patch. Am i > missing something? Honestly, I don't know where it would be most appropriate. But I'd like to highlight that nothing strictly forbids Xen code from writing a value != 0 into regs->zero. I saw that in emulate_load(), which is introduced later, you used a branch to avoid an incorrect load into regs->zero: /* * A load into x0 discards its result: writing regs->zero would break * the invariant that it reads as zero when x0 is a source operand * elsewhere. */ One solution could be to make cpu_user_regs private and add get/set methods, with a check in the setter that forbids this type of write, but that would imply some big changes, so it may not be the appropriate fix. > > > Thanks in advance. > > ~ Oleksii > > > From xen-devel-bounces@lists.xenproject.org Tue Sep 08 17:10:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 17:10:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412305.1642835 (Exim 4.92) (envelope-from ) id 1x3zLK-0004ba-Uu; Tue, 08 Sep 2026 17:10:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412305.1642835; Tue, 08 Sep 2026 17:10:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3zLK-0004bT-RN; Tue, 08 Sep 2026 17:10:46 +0000 Received: by outflank-mailman (input) for mailman id 1412305; Tue, 08 Sep 2026 17:10:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3zLJ-0004bN-Px for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:10:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3zLJ-00CWeZ-5K for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 19:10:45 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa04178-bab6-0a2a0a5309dd-0a2a450b977a-22 for ; Tue, 08 Sep 2026 19:10:45 +0200 Received: from [40.93.194.30] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa04193-b7e8-0a2a450b0019-285dc21e5a1b-3 for ; Tue, 08 Sep 2026 19:10:44 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB7236.namprd03.prod.outlook.com (2603:10b6:806:2f8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Tue, 8 Sep 2026 17:10:39 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Tue, 8 Sep 2026 17:10:29 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AxT3Wl+0zhV8K/yQcQOaUQKI/Nnpdy8uRq9GZZWwz8tkM1MYOmvLW5AWHbH4WpM8HxIWoLefIuVvq6cckA86rceMZHmnpqMeelghZhBcT8rikXybIRt4t6i1+dgJHStYeAveiVxrzZm5dW762ETcQ6w2Q/hzVe6PFtGce5DL0zyQmfVyKvanwp/BeyyOAh53uMzJDHc64gAKiL+R9TRAqfqtu7bP7qgA2zkLl83HqgbR7g2PHhxDlCaFpktPqv8NQfXJOQnLI6RqXBLUYEzK7p/7mfCerEWASkKkz6XDCgBylLjPuIOMRT8UBhirfcta9vh2wH/ICSpC+9hjIeR1+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cr7WMKYcq5gf4TpySz35NF7OfL/SUKkozW4TLNv3w+U=; b=jGtBZKNYL+XYDlN+99mTFzm+ELjK/tj6Ap7ynJSYUUGIyTWLi7T5J5HwkUw7cgzY7fB9CHHwrpRUiIDWn55QbHGNVMA1V4VLwYs9UipRCCLXWkPel4x4Uv8vWO5lm1mMLwsPtIajys5Tdlt18UY8/ktmZMHOYUWKkTFS2sHGNCVINrvcgdyq22ybLKuiYoJdQ6Bi+rgCq8GIH0Q5WAJfGd+wGT8MEu+HrMF6J07Dm9cxz0qpYZtZ9+fUwqLz867QOddLsz/vHvI9/RqH+QcMbkWiMlp9Ds5je9I1bJQjHhRYmxrRXuXRJqteTtSKJFV9lbgrgv0QnZulnXTgzhd4tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cr7WMKYcq5gf4TpySz35NF7OfL/SUKkozW4TLNv3w+U=; b=WwXYtqhh+O1WNlmNbgv60P6MOERv0OHTinPaz2Z+GIO78r/sDW5VnR3C4EIXlb20i4NbvNzGfgD/ZxLJ9p6NOE8wJODxALPt7qPgm6QZIGktTnFBDjfLF+fqiH+M+h52/LqR2VUqIu7pte4+yw4jYXYMLAfEYO5veOXyZlyQOv0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0ad272a0-8afa-40fd-a7cd-fc953e1b992f@citrix.com> Date: Tue, 8 Sep 2026 18:10:26 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel Subject: Re: [PATCH v2] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Jan Beulich References: <20260907213231.3159241-1-andrew.cooper3@citrix.com> <6a54806f-061b-4b76-b42d-6fa5b54581e4@citrix.com> <70dd9e38-bc54-4532-b310-cb9fb3d3f2ce@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <70dd9e38-bc54-4532-b310-cb9fb3d3f2ce@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0366.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::11) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB7236:EE_ X-MS-Office365-Filtering-Correlation-Id: 27dff21c-a92c-4795-3dd4-08df0dcc15af X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|6133799003|10067099003|4143699003|22082099003|11063799006|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: yYuMk08sIx7idsw+yPpC/5CNNVuEvu1oHu/4HofAA3Egbhyg7FZJx32idOhXXiaySBYIYMjjNGqxyHShlzrgUxHB6IpDjKOwSf9BiJaoEpy9+KIWhe+62qSbnVFFeS/ShWL5puN6fZdUpIPzaTL8qCH7bz3eG64leUBZ7vrSrd0w2SCC7G5WAejJJs1KLE/DP/ksr1XLEf9pwBJ8s99aKSWcc+L4c3GP8k9xKtW6uvsbLc06WAOzkOBWNusEvOdOrJ0mJ7QW7s0VNOxEK90Z0D9yA4kaKCPN/RiRet8UP/gZ38kgidlE/TEsyce1GyTbzf/xJXU8clveKx1wSxisHQbuNlI8yA9IOQUWFEh9bFeAhwqULbOnY++8cnmxVzyjR3RfBOrKB1uxWcQPvPpHCY++BL27v7HuiSc4PNYYCBO6baBwf+aViZkR36Vp1eJHMUBtHt8pMMFA5fbl2p5/vthde1xZjhWzSKppWukDaWIfBoGBZZBGcYYMiuXfAX6j08g38waTZY0AJys59rIQDUuFW4ztUBjkxu4XWCHaR7/lbZ0hEofN3glO8fjO+glAoe+EJyGFWpUgds9JecbeSKCh01yBpp4OZ3Pl62l1rhnyAiC4Vzch3fL2v5XeVuJD85T4nsBIhM3A5yIdESVY5RgBkDWy7IWITD2C7DtT6tQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(6133799003)(10067099003)(4143699003)(22082099003)(11063799006)(18002099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dEV4MmVQc2ZjQXRtRjJLMnZ4VFgvMVV6a2Qwc2FLWlBXNDhxUllKWlhVdWVH?= =?utf-8?B?R2dYeVRaRWVPZ2tNUlpLUG9rN3RscURnMjkzSEtjd2dPUXFsZUJJRExOZEFt?= =?utf-8?B?aTJxRmxJT0tHY1g2VkNZQWRvbStiaWNnUldCbHZRSUxQQVljVk9FTGYwNzNY?= =?utf-8?B?ZUtYWjF0MVBPVlIyMlV3OHJBekdyVGRMcUhEajVKVXJoTnVHNXRGMWxETVpn?= =?utf-8?B?NlBsek9QMHZtWkVMU1huK3N6SDd5bG5tSmZvZ0dPeDhUZlNsSlcvY2JKZkQ4?= =?utf-8?B?dXpvSDRReWlteWk1NXFJemJLVldrWUs5dWJTeEsvaXk3N3JnQlRjcW1jcUpE?= =?utf-8?B?dm9XL3pLLzE2V2F1RDNhT1U0aGJpMmhqdnI3U0o4bnFpeVYvQUM2SHZjSmpw?= =?utf-8?B?blBQTXgvVVp6Y2lrUWRmQU9tSnQ5bjlCQW9zODFBOU9oUjVZSXdLMll6U2ho?= =?utf-8?B?cFJ3ZXpHRGJxQjRaVm1ZSEwwWHBiMjIyak5jREU4eXBRbmZBZlh6TThxY1cv?= =?utf-8?B?YXQyZzB6eTlGK0h1NTZoeUc0akI2dklIdDU3d21kb3ZsaFhDUU5uV0JUc0dK?= =?utf-8?B?eklTUzZwTEpHbnFQZ0JGMDI3eUdReE83Nm82MXpxOThmZXo4Y0h0Q3BGSnF1?= =?utf-8?B?bzVpMnNEQVlmbGoweVQwRGw2N2wyaUE4RzQ3NnQxNldJYUJNTU40bVcyVnF2?= =?utf-8?B?Q2JyYXQzZ21VeXZjNzBmeS9SRTVNOHBMazdEY2FQdFEyY0JBRGtiZVJvSkRx?= =?utf-8?B?VWdoL05vekFyazJRSkdRNGt6bkkvUHJOV3dqaTdPV3R5MDFuTTBaSG9TVk9K?= =?utf-8?B?SnFrZ2JteFkyMytQMm9hRE84NU9oMXA3QXJuSkl0RVh4RFowTEk2L0ZhR0J0?= =?utf-8?B?Tjlja2l4TVZTY0s1bC81UWhvYjVXZ3FoOGVYMy9rT2U3TGpsTVdvQXRvb1BG?= =?utf-8?B?WkpMZjRFS2NjK2ZrQzRxTHBIWEgycndiYXMvemtoYUlmTnFjbHhhZGlOUjdO?= =?utf-8?B?aEpkL2txUmoxcCsxeXdBVkRCMVJHWkZROEtQWmNUZnpzM0ZxT0MwRkdDWG5E?= =?utf-8?B?cmJ6c3hCelh1ZjRLUjZMNzdjNHdTK0ZINWNCU2R4WUlyMHlJT0hDVGhDV1Yv?= =?utf-8?B?djVRbU56T2ZyWmQzVmhIQ1JsMDdRQWhleVI3U1ludk5odDkydkhjRDJkV0JV?= =?utf-8?B?VHBRTVhWZmwvU2l1amo4aUJTWVArczNHcGYra3F1aVhEZ252c3dxRVdkVHU5?= =?utf-8?B?bE5BZWU3TkRLdzhNYVNxYXFSekpEdG5RQVM5bDJRMzJ0NWFTbXAvUGljYVUw?= =?utf-8?B?V3ZWMmMxd1d1OU54Z3dwTzMyYW5HdG1rTm5tcEZKQ1VlMCsreFArSjdJWDJQ?= =?utf-8?B?Qko0UG9CbER5WmUwTDhOOTdUOTVBd0wvbFNxaW96M3RySWdLZTd4VTFFd2NS?= =?utf-8?B?NVlJYUNIL0hLbmY3c2x2VUR6N0F1cWRCYmVEWktZV1g4QktXV1ZFM3d6TmRL?= =?utf-8?B?c1U0RHRFU2F6OWdhM3BTd3NYMElaZ2Z1K0RJaSs3WGZDQ0wwTjFyc09aNExX?= =?utf-8?B?bkYvUlB0OW5FdUF3Q3J4N3lmdGQzUmE0MHVabzJJRnIybWhkcjd1Q1N0UFdt?= =?utf-8?B?dGxObkdlVGJxeUVGMFd6a0FlTStwSVl4TzFvbHJmMHdacUo0bmVvaldnMHAx?= =?utf-8?B?cXFBMFRtSW8rUXF3MUY3UUpWT0xneVdMRzlVVFF3TDljVTAzdmdkU01MYzFJ?= =?utf-8?B?YzJ2NjBxcFdpbzNOT3NzenB3SXJsREpyQUgzMGN6bTliUGhOc0llSUdueGJi?= =?utf-8?B?UFRoelZ6UjNSRWhhQTRNVEdzTTAyenJtcXBwRUtCUG5HVU9UNWVUdFRMV0tj?= =?utf-8?B?REc1eHlXek9tQkNkV3NVZTRVV1hiVlVEWWF3T3pSUEpHeThYd2ExWkFObXpR?= =?utf-8?B?YlhWdlVvZUlabGdBMng2MFd6T0ZmRWpaWTZjaUYxbGFUU1BFU29WdmRZVHpm?= =?utf-8?B?eFFLUTU0QzQ4VVQ3R1hEbXo0TlVMWEZvM043UXpTRDZIeEUxeHZQU2loc3Yy?= =?utf-8?B?LzF5TGNsNFVkWE9LMGt5Ynpsa0tJYTF2Z2k4cTY4bTVWeTl4U1ZMSU5uYk9C?= =?utf-8?B?amtsbE9ydFF3RzZtWHRaV21obncwSWZ3aVNzUzFrcXFZeFQvVnB1NzE1TGo3?= =?utf-8?B?L1FCRnRrY0diR0J0MndxeGMzS2xkejQveWE1ZjZpYzRITG9EYjBHQmRkYlNG?= =?utf-8?B?dUFKVTJVc0ZhTlBuL2VKUzBJd2R3QmRxR1ZjdnhWRVJlaTM4V3dIdkovSlRa?= =?utf-8?B?YWtQR3A2ZEhUNy92Y2J6T1czLys4YzY2UmNDQUdKWHlsSU5oMUVuUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 27dff21c-a92c-4795-3dd4-08df0dcc15af X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2026 17:10:29.9033 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ivE/+x1TNmJM/7skmcTxoYkrTOGBWEA5jaQf2gqs7A/cyGArAjExaduBqr4AKwVnuXx50qnjAcNswt+MwBRa5U5GA9IL7hNn26Zi+mG0cpw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB7236 X-purgate-ID: tlsNG-42698a/1788887445-18ECE9EA-981B688A/0/0 X-purgate-type: clean X-purgate-size: 3240 On 08/09/2026 11:55 am, Jan Beulich wrote: > On 08.09.2026 12:08, Andrew Cooper wrote: >> On 08/09/2026 7:26 am, Jan Beulich wrote: >>> On 07.09.2026 23:32, Andrew Cooper wrote: >>>> @@ -273,6 +274,44 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) >>>> return false; >>>> } >>>> >>>> +static bool microcode_safe_to_load(const struct microcode_patch *mc) >>>> +{ >>>> + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); >>>> + >>>> + /* >>>> + * Treat pre-production as always safe - anyone using pre-production >>>> + * microcode knows what they are doing, and can keep any resulting pieces. >>>> + */ >>>> + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) >>>> + return true; >>>> + >>>> + /* >>>> + * GNR98 states that Granite Rapids systems hang when loading new ucode on >>>> + * sufficiently old firmware. GNR101 retroactively declares that one >>>> + * ucode had incorrect min_rev fields, in light of discovering GNR98. >>> We still have no min_rev field, so imo a reference to it wants some >>> clarification. >> No, I don't think so.  The fact Xen has no min_rev field (yet) has no >> baring on the wording of GNR101. > The wording there is "Minimum Runtime Microcode Update Revision". As long > as we don't have a field of the name, how can such a comment be unambiguous? Fine, I'll say "minimum revision field", but the whole name is (and always has been) silly. > >>>> + * Both are incomplete statements of the problem. >>>> + * >>>> + * At the time of writing (August 2026), the believed safe sequence is: >>>> + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later >>>> + * >>>> + * Disallow known-unsafe loads while permitting believed-safe loads. For >>>> + * GNR, this allows multi-hop loading to get up to the latest. >>>> + */ >>>> + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && >>>> + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && >>>> + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || >>> This is odd: The lhs of && uses the lower bound of the inner permitted >>> range, while the rhs of the && doesn't use the upper one. If it's intended >>> that way, I think this also needs clarifying in the comment. Otherwise imo >>> lhs and rhs better would be consistent in this regard. >> It is intentional.  Furthermore, it is the only coherent way of >> expressing the sequence as given. >> >> I'm not writing a comment explaining why it's a good idea to use the >> same boundary numerals between the comment and the code.  It goes >> without saying. > But that's the problem - code and comment are not (obviously) in sync. > >> I'm also not interested about pureness concerns about inner vs outer >> bounds.  I can't see a change here that won't make it worse. > So why are > > ((cpu_sig->rev <= 0x01000370 && mc->rev >= 0x01000405) || > > and > > ((cpu_sig->rev < 0x01000380 && mc->rev > 0x010003f3) || > > both worse? Because they are both buggy.  They fail to exclude some unsafe cases. If it's not obvious, I do know more than I can say publicly. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 08 17:15:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 17:15:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412315.1642843 (Exim 4.92) (envelope-from ) id 1x3zPv-0005Fa-Ju; Tue, 08 Sep 2026 17:15:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412315.1642843; Tue, 08 Sep 2026 17:15:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3zPv-0005FT-Gf; Tue, 08 Sep 2026 17:15:31 +0000 Received: by outflank-mailman (input) for mailman id 1412315; Tue, 08 Sep 2026 17:15:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x3zPu-0005FN-0V for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:15:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x3zPs-002MWe-VI for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 19:15:28 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa042aa-e002-0a2a0a5209dd-0a2a450188d8-6 for ; Tue, 08 Sep 2026 19:15:28 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa042b0-5984-0a2a45010019-d1558031a557-3 for ; Tue, 08 Sep 2026 19:15:28 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-495437bb891so28439045e9.1 for ; Tue, 08 Sep 2026 10:15:28 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883c6ba4sm42308095f8f.25.2026.09.08.10.15.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2026 10:15:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788887728; x=1789492528; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mJSy1oOnfZYuUJld/ZrDnUr2X+fXVk73FeNzFX3opLg=; b=KdT+SCW66LbI3HcZ4msa85CuNWmEagIwIsBn95T7QLSL7L+RVuOXtf6Hef5ziREJpo 1AMGiNkB3zmPfJaW/EXXmnZhhM6SLB3j5t2SZupTDr9lmAvdn88jiArbE8u1cc25UOTC HwDml92IkKLzFodfBcGmg+6RL85LjgWqN+7rY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788887728; x=1789492528; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=mJSy1oOnfZYuUJld/ZrDnUr2X+fXVk73FeNzFX3opLg=; b=CK9SueLM8jclWXp8fKbTjXzuixuBNqingD5lu6d6/Y/PdL33LLdZnnZLoa1qUFDUSG ZrQHh0u/Wg2iDw2/YC0lqeD91/4FwlAYfK/lEzEL1Tw7NA1OVflT14H3iFS3H80r89Th VQ+YJsE0U9nD2n7L5QVv+fxIVvlbppJpDkNPXks/UvYNooKN0/00eP/l6UH/9Vsj+kxO MEDfzduF+eA1ktL/yw14T5nD1Yhjp+KIOfcjq9wmZa5acWU1ZjSbbErshgDIluUnHgsG ovFPTIV1CU8xBDjG7pDs8ZOuqnDmEx4ZtAMzJugXnmwJyaRV3VJAphJqRoK1ZTlfCj+b zH/Q== X-Gm-Message-State: AFuF++mrFA5c9CwRJIRVZoWZP52+u+MFLz4NRZ+i8o/tWv1vOek6hnRw PXGynINPZasJKyM3HeEzJmHzrPhX4S70nlvW/Zm59sqMJ2V/34MRS8DBC+jQVxARxH4Ke8upPBG Jp9JdXVw= X-Gm-Gg: AYBFou2iYGb5LP+jGwPeflAnnB9xrqTGw8rfuClPRhv4qezcxef1Xq1iyzLk6uEmWm9 mTrYAbTsE4sxq2Jz9chzkcsD7CydewRL9+MRuC7zggLmIu3IgqLsFsYno/fl5iMqoWa25OHRMVt zD4ig/Wj9/yELesqg7pHCQQ4iuoFEZpu/m0gUhVB7DsNQmr+zidxtcHMejerBi3QK4mKM4NP/Nw brBM7qIpfgrW0OCyG5Ftv8qzo69bKAq/W6sd+AXx2D2SMEtFMaHc1EmHXeM5EzJHmNA+x84xpMI DbrBZT4c9xF1zvB2BtSX5fZx0fBEWkIzXyBKb9lf7hAjWoUMxEqCAY1YVM0Ds39h26iRlxui/iI cO7yvcy9Pxm9KDZ3rPD6Husln2EBTyZlCBFLt/DTEpyConozX2MdjPZ6lTiLl+J+LqeGvX4WbT7 DH0QtHEMBkH9iYsQKVVbHqzUAwy9n3JkZr86nweNimMLTERb14GMtFYMoGgBFFfHAb1gYfvqIaW JRu1YGSJwnX4u2tbCBnZ0cLmfNuY2LmpOxEXbs= X-Received: by 2002:a05:600c:74a:b0:49d:10b8:7e05 with SMTP id 5b1f17b1804b1-49d10b87ec4mr104627155e9.19.1788887727994; Tue, 08 Sep 2026 10:15:27 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3] x86/ucode: Work around Granite Rapids erraturm GNR98 Date: Tue, 8 Sep 2026 18:15:25 +0100 Message-Id: <20260908171525.3196765-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788887728-BE07B757-E7476D12/0/0 X-purgate-type: clean X-purgate-size: 3179 Block loads which are known to hang the system. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie A more complete solution is in the works, but it's taken 4 months to get this much published... v3: * Double XENLOG_WARNING v2: * Correct the sign of the cpu_sig->rev check. * Expand the comment to explain why we are not following what GNR98 says. --- xen/arch/x86/cpu/microcode/intel.c | 40 ++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c index c45b00c6b033..86cbfb798160 100644 --- a/xen/arch/x86/cpu/microcode/intel.c +++ b/xen/arch/x86/cpu/microcode/intel.c @@ -27,6 +27,7 @@ #include #include +#include #include #include #include @@ -273,6 +274,44 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) return false; } +static bool microcode_safe_to_load(const struct microcode_patch *mc) +{ + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); + + /* + * Treat pre-production as always safe - anyone using pre-production + * microcode knows what they are doing, and can keep any resulting pieces. + */ + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) + return true; + + /* + * GNR98 states that Granite Rapids systems hang when loading new ucode on + * sufficiently old firmware. GNR101 retroactively states that one ucode + * had an incorrect minimum revision field, in light of discovering GNR98. + * + * Both are incomplete statements of the problem. + * + * At the time of writing (August 2026), the believed safe sequence is: + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later + * + * Disallow known-unsafe loads while permitting believed-safe loads. For + * GNR, this allows multi-hop loading to get up to the latest. + */ + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || + (cpu_sig->rev < 0x01000405 && mc->rev > 0x01000405)) ) + { + printk_once(XENLOG_WARNING "microcode: Granite Rapids erratum GNR98 detected. Skipping ucode 0x%08x\n" + XENLOG_WARNING "microcode: Firmware update recommended\n", + mc->rev); + return false; + } + + return true; +} + static int cf_check intel_compare( const struct microcode_patch *old, const struct microcode_patch *new) { @@ -365,6 +404,7 @@ static struct microcode_patch *cf_check intel_ucode_parse( * one with higher revision. */ if ( microcode_fits_cpu(mc) && + microcode_safe_to_load(mc) && (!saved || compare_revisions(saved->rev, mc->rev) == NEW_UCODE) ) saved = mc; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Sep 08 17:57:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 17:57:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412338.1642853 (Exim 4.92) (envelope-from ) id 1x404i-0002fo-KI; Tue, 08 Sep 2026 17:57:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412338.1642853; Tue, 08 Sep 2026 17:57:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x404i-0002fh-HT; Tue, 08 Sep 2026 17:57:40 +0000 Received: by outflank-mailman (input) for mailman id 1412338; Tue, 08 Sep 2026 17:57:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x404f-0002bf-OA for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 17:57:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x404e-004qW8-Ba for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 19:57:36 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa04c8c-2eae-0a2a0a5409dd-0a2a4505d8f8-4 for ; Tue, 08 Sep 2026 19:57:36 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa04c8f-4cb1-0a2a45050019-d561b338ac0a-3 for ; Tue, 08 Sep 2026 19:57:35 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x4047-00Gcpz-4h; Tue, 08 Sep 2026 19:57:03 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x4046-006bwL-A4; Tue, 08 Sep 2026 19:57:03 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x4046-00000007AAD-14In; Tue, 08 Sep 2026 19:57:02 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=oSRZzJnAPLDDt/YuSrYjYSdAxN1Qp6X1YLFSuBN6GE8=; b=UQ1DZdEWCGgl5OC/rNxNxZ60eE yjcGBcIqiuFAo51PkATaGhWHtJxSvVMFvtKp7MyRCyc34U7A4SOHVQOsFaVGsSuGrzbmZ1DbUZv78 SYxEBXzm95ONDdcupbJmVj2lIJg627nu4y2IthveO3N7YeY5O+D7GDVr7EjBGKaVLcGuEplae/xC9 hLMNujvnbhplyP0o9cEqVHqHPMtMmmbtU4Ziql0QZKbFcMiiUfNdHc3qVOOo/zQuIjhTeYthVWIHq IUd9eyDjZ7YmAPDBY/q/YWM+nlSlHJOlqftXKram1aC608My7bDNWMtiAFjivRZavT+49XrAOkQsJ 2txK5O5w==; MIME-Version: 1.0 Date: Tue, 08 Sep 2026 14:57:01 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() In-Reply-To: <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> Message-ID: <4f91e90230e415fb036fbaac86bd5b27@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-c201ff/1788890256-F76BD2A1-8A330FA9/0/0 X-purgate-type: clean X-purgate-size: 1820 On 2026-09-06 14:01, Borislav Petkov wrote: > On Sat, Aug 22, 2026 at 03:33:18PM -0300, Mauricio Faria de Oliveira wrote: >> Move the inline memcmp function currently only available in 'boot/string.c' >> into the shared string function header to be reused. >> >> This is not done through to avoid pulling unnecessary code >> in 'boot/string.c' that causes build errors in 'boot/compressed/string.c' >> and 'purgatory/purgatory.ro'. > > Please drop those '' quotes - it is perfectly clear that those are .c files. Ok. > >> No functional changes. >> >> Signed-off-by: Mauricio Faria de Oliveira >> >> --- >> >> Thanks to David Laight for noticing the return value difference between >> inline and regular memcmp(). >> --- >> arch/x86/boot/string.c | 13 ++----------- >> arch/x86/include/asm/shared/string.h | 26 ++++++++++++++++++++++++++ >> 2 files changed, 28 insertions(+), 11 deletions(-) > > ... > >> diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h >> new file mode 100644 >> index 0000000000000000000000000000000000000000..06c1d5e5013e4d59cfb49866d10e164362d2c4cc >> --- /dev/null >> +++ b/arch/x86/include/asm/shared/string.h >> @@ -0,0 +1,26 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +#ifndef _ASM_X86_SHARED_STRING_H >> +#define _ASM_X86_SHARED_STRING_H >> + >> +/* >> + * This inline memcmp() returns 0 (equal) or 1 (not equal). >> + * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (greater than) >> + * to indicate ordering as well. > > No need to overdo it: > > Returns: 0 (equal) > 1 (not equal) > > In contrast, the regular memcmp() follows glibc return value semantics. Ok. Thanks, -- Mauricio From xen-devel-bounces@lists.xenproject.org Tue Sep 08 18:05:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 18:05:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412346.1642861 (Exim 4.92) (envelope-from ) id 1x40C5-0004VO-9t; Tue, 08 Sep 2026 18:05:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412346.1642861; Tue, 08 Sep 2026 18:05:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x40C5-0004VH-78; Tue, 08 Sep 2026 18:05:17 +0000 Received: by outflank-mailman (input) for mailman id 1412346; Tue, 08 Sep 2026 18:05:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x40C3-0004VB-CR for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 18:05:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x40C1-000MXo-Tg for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 20:05:13 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa04e56-8faa-0a2a0a5109dd-0a2a4509a64e-4 for ; Tue, 08 Sep 2026 20:05:13 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa04e58-be1a-0a2a45090019-d561b3388098-3 for ; Tue, 08 Sep 2026 20:05:13 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x40Bi-00GcyI-N0; Tue, 08 Sep 2026 20:04:54 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x40Bh-006cMp-P2; Tue, 08 Sep 2026 20:04:54 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x40Bh-00000007AFC-2x4D; Tue, 08 Sep 2026 20:04:53 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=vp63UVaxTdJB+T//K0HyE8/U9OGm3JAcHr89i9lbZwo=; b=PcSRrgveRmq44kFUJ6/suRcHNj jE4yYchg++9GF1E4naqI/IwTOm+LKLpqOYaHgbSD4INDiAbCX+wX772SaHygl6iOWoWEYtEqHpuRA miA/IrtAq3HJPmEHwW5QtH1WFtwjhPgC/FMFBCBWfC2hKwnGJPbtwddVwVJ1c1V6yAaM/T11UEkZU 9sXTOR3kTslOmlanM2crHTWCT91IwZU1AEzBjXPouiZUyCz4gaEkLzjvdM1yunF70c4EKMKtxzC4J g/4wqu7UySpgDH2SlRDPcM4ghFH+CQ1lILUuzPLYZYBaXx8bIKas+wVhTrB3NpL6+CheEYmDuB4tO uEn+Tu9w==; MIME-Version: 1.0 Date: Tue, 08 Sep 2026 15:04:53 -0300 From: Mauricio Faria de Oliveira To: "H. Peter Anvin" , Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() In-Reply-To: References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> Message-ID: X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-bad1c0/1788890713-BDEC6034-8DA78F1D/0/0 X-purgate-type: clean X-purgate-size: 2308 On 2026-09-06 15:15, H. Peter Anvin wrote: > On September 6, 2026 10:01:16 AM PDT, Borislav Petkov wrote: >>On Sat, Aug 22, 2026 at 03:33:18PM -0300, Mauricio Faria de Oliveira wrote: >>> Move the inline memcmp function currently only available in 'boot/string.c' >>> into the shared string function header to be reused. >>> >>> This is not done through to avoid pulling unnecessary code >>> in 'boot/string.c' that causes build errors in 'boot/compressed/string.c' >>> and 'purgatory/purgatory.ro'. >> >>Please drop those '' quotes - it is perfectly clear that those are .c files. >> >>> No functional changes. >>> >>> Signed-off-by: Mauricio Faria de Oliveira >>> >>> --- >>> >>> Thanks to David Laight for noticing the return value difference between >>> inline and regular memcmp(). >>> --- >>> arch/x86/boot/string.c | 13 ++----------- >>> arch/x86/include/asm/shared/string.h | 26 ++++++++++++++++++++++++++ >>> 2 files changed, 28 insertions(+), 11 deletions(-) >> >>... >> >>> diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h >>> new file mode 100644 >>> index 0000000000000000000000000000000000000000..06c1d5e5013e4d59cfb49866d10e164362d2c4cc >>> --- /dev/null >>> +++ b/arch/x86/include/asm/shared/string.h >>> @@ -0,0 +1,26 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +#ifndef _ASM_X86_SHARED_STRING_H >>> +#define _ASM_X86_SHARED_STRING_H >>> + >>> +/* >>> + * This inline memcmp() returns 0 (equal) or 1 (not equal). >>> + * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (greater than) >>> + * to indicate ordering as well. >> >>No need to overdo it: >> >> Returns: 0 (equal) >> 1 (not equal) >> >>In contrast, the regular memcmp() follows glibc return value semantics. >> >> > > Worth noting that memeq() and streq() are becoming used in other contexts, e.g. glibc. Thanks for mentioning. Boris, perhaps the approach here could be changed to add an actual memcmp()-like inline implementation (e.g., as provided in a previous revision, without return value differences), or continue with the memeq()-like memcmp() from arch/x86/boot/ but rename it to memeq() ? -- Mauricio From xen-devel-bounces@lists.xenproject.org Tue Sep 08 19:33:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 19:33:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412380.1642871 (Exim 4.92) (envelope-from ) id 1x41Yz-00005S-AO; Tue, 08 Sep 2026 19:33:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412380.1642871; Tue, 08 Sep 2026 19:33:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x41Yz-00005L-77; Tue, 08 Sep 2026 19:33:01 +0000 Received: by outflank-mailman (input) for mailman id 1412380; Tue, 08 Sep 2026 19:33:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x41Yx-000054-A5 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 19:33:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x41Yw-000VoL-LP for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 21:32:58 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa062bb-e002-0a2a0a5209dd-0a2a4508841a-38 for ; Tue, 08 Sep 2026 21:32:58 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa062ea-f659-0a2a45080019-416d716cdb3e-3 for ; Tue, 08 Sep 2026 21:32:58 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 7ABD340E01F9; Tue, 8 Sep 2026 19:32:57 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EOvuZCCfcmsb; Tue, 8 Sep 2026 19:32:47 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id D3FB040E01DD; Tue, 8 Sep 2026 19:32:32 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1788895967; bh=CSxdJl4VBmqHBG2bWI7rm0ZQwyV1SRPcqmp/fkG/2Fc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cwg+fHP68U1E4MZ59lLpLK/8gQ6qCUXS7fi5N32ugrohWQjHI6hDpvpxTWRIE5Uhn p6GUxO/I9ZXLuYKmVbEuMqDqRrGw5eI4prsmMRnlGxCY4C4+TTQ1Q97gBYJa3GCdmv ASmk0yH1wCK1RvHvz+mp8scgjIluUYfD+ejJtJmyjcJRYecg3WnfY+Hwcq4DB0i0zE L2m+h1SAkafW6bkrpr8pNiBUSa+gdznsgnLq1PMzc/pBupjiqfExCFGUPNvEY8TSrP cL7dfrs1tAC9t9AOfJM8duIPbsCHZZbehvFl0cvQdGC3KSJ4V2P7IKZwmKMGohEph8 7KAVVlgS9yOdoDDWPurPqj+d5p6nsY7ROShKx9SQa8LK2DVdR9tOLAc7GC7pWoM++w VJO05TcWaSy6da/m+C2WftviWAvOtriATkGbNX1L3Yhb15QMwYatOukSuqqXDXOMo+ 5eJxuquCtyeN7sVE3Dxgjvhlb9ZN/EAqkVNrzKWQuogJ86EvXw//L8RmpUpAj0dl3Z /11ogNuRl0PeDHKTpqMJa96NpNeh/dY16TGIXH3JGLbLWrAWpgKYPwK2ZiVP/+KDxM vBGlz8imGLf75+JzTvp248YRm3SiWdd9NdJx4kCbAVkcABxryoqq4N5zIjSrv6tUKn cGqY+ntuQUYJ7gzDyyyd1aa0= Date: Tue, 8 Sep 2026 12:32:29 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() Message-ID: <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-c1860d/1788895978-CEF5F87B-FBD08618/0/0 X-purgate-type: clean X-purgate-size: 539 On Tue, Sep 08, 2026 at 03:04:53PM -0300, Mauricio Faria de Oliveira wrote: > Boris, perhaps the approach here could be changed to add an actual > memcmp()-like inline implementation (e.g., as provided in a previous > revision, without return value differences), or continue with the > memeq()-like memcmp() from arch/x86/boot/ but rename it to memeq() ? Nah, new functionality is not needed. We can add it later when it is really needed. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Tue Sep 08 20:04:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 20:04:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412393.1642880 (Exim 4.92) (envelope-from ) id 1x423L-0004Ot-HX; Tue, 08 Sep 2026 20:04:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412393.1642880; Tue, 08 Sep 2026 20:04:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x423L-0004Om-Dl; Tue, 08 Sep 2026 20:04:23 +0000 Received: by outflank-mailman (input) for mailman id 1412393; Tue, 08 Sep 2026 20:04:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x423K-0004Oc-9E for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 20:04:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x423E-009vFo-M2 for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 22:04:21 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa06a04-bab6-0a2a0a5309dd-0a2a4505ac68-48 for ; Tue, 08 Sep 2026 22:04:16 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa06a40-4cb1-0a2a45050019-b9ff1c12a4fd-3 for ; Tue, 08 Sep 2026 22:04:16 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0829f022d000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 08 Sep 2026 20:04:13 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 14EDF82029; Tue, 8 Sep 2026 22:04:13 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=N7xmxj6HVlgvPHf7dm+GRrZU1J+ZJ/dHwrlkB7bLXGg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=TOouHHc9R/wuX9Bf3FjQi8P9eISnIOr6uaoqRNVyD+7AtOfyxQKHg54Wfp1ZkUzg3B3z4xnLW WmtOaO+T/41tRsa6YaQ9LzST9HaC2tENbwqM1HutGjkGxoKzNO6MJSvIx7aU9/1s5Xi8F15G0Fk v9yFTqLKiCnoIJpYX+kCfElpIOycwDPmOpRshchG46WYZcL59RxauKNlYisB3eUZqKVSBT5ikh7 94setz/aNb8ExDWa+gXkZ6IP2Kmmdtvz/WRpceh6W5Suzooa7TGIqLID2nPOYGN3lkL0zB1LYWT 5P22ZNVNA0wJ35g30CHJFI0pcoEXIWKh962NpJky7LPw== X-Zone-Loop: 4a65d638a1bce82a569e2c87bc3381c0340c8cfc3fd2 x-campaign-type: default x-transaction-id: 3864bc44-3248-4405-98c1-6c06768968b0 x-swg-uid: 01-a6b4dfd6-0846-4897-8780-d4958ee44c84 X-Mailer: Sweego Message-ID: <1788897854.8631fc262581453bbf619ec5b2062170.1a0829f022d000c4f3@vates.tech> x-swg-bid: 1788897854.8631fc262581453bbf619ec5b2062170.1a0829f022d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 8 Sep 2026 22:04:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper , Xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260908171525.3196765-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260908171525.3196765-1-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------lk9BpKF28q5HqSgKEZ79QwkS" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788897853195 X-purgate-ID: tlsNG-c201ff/1788897856-247132A1-1B70EB86/0/0 X-purgate-type: clean X-purgate-size: 9213 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------lk9BpKF28q5HqSgKEZ79QwkS Content-Type: multipart/mixed; boundary="------------pjG0quQQ5qAZwmFDT2wXZmFG"; protected-headers="v1"; hp="clear" Message-ID: <46d1bd3d-aae1-4cd1-bda9-b31e376a44df@vates.tech> Date: Tue, 8 Sep 2026 22:04:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper , Xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260908171525.3196765-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260908171525.3196765-1-andrew.cooper3@citrix.com> --------------pjG0quQQ5qAZwmFDT2wXZmFG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDgvMDkvMjAyNiDDoCAxOToxNSwgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBC bG9jayBsb2FkcyB3aGljaCBhcmUga25vd24gdG8gaGFuZyB0aGUgc3lzdGVtLg0KPiANCj4g U2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4NCj4gLS0tDQo+IENDOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IEND OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlckB4ZW5wcm9qZWN0Lm9yZz4NCj4gQ0M6IFRlZGR5 IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0KPiANCj4gQSBtb3JlIGNvbXBsZXRl IHNvbHV0aW9uIGlzIGluIHRoZSB3b3JrcywgYnV0IGl0J3MgdGFrZW4gNCBtb250aHMgdG8g Z2V0IHRoaXMNCj4gbXVjaCBwdWJsaXNoZWQuLi4NCj4gDQo+IHYzOg0KPiAgICogRG91Ymxl IFhFTkxPR19XQVJOSU5HDQo+IA0KPiB2MjoNCj4gICAqIENvcnJlY3QgdGhlIHNpZ24gb2Yg dGhlIGNwdV9zaWctPnJldiBjaGVjay4NCj4gICAqIEV4cGFuZCB0aGUgY29tbWVudCB0byBl eHBsYWluIHdoeSB3ZSBhcmUgbm90IGZvbGxvd2luZyB3aGF0IEdOUjk4IHNheXMuDQo+IC0t LQ0KPiAgIHhlbi9hcmNoL3g4Ni9jcHUvbWljcm9jb2RlL2ludGVsLmMgfCA0MCArKysrKysr KysrKysrKysrKysrKysrKysrKysrKysNCj4gICAxIGZpbGUgY2hhbmdlZCwgNDAgaW5zZXJ0 aW9ucygrKQ0KPiANCj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jcHUvbWljcm9jb2Rl L2ludGVsLmMgYi94ZW4vYXJjaC94ODYvY3B1L21pY3JvY29kZS9pbnRlbC5jDQo+IGluZGV4 IGM0NWIwMGM2YjAzMy4uODZjYmZiNzk4MTYwIDEwMDY0NA0KPiAtLS0gYS94ZW4vYXJjaC94 ODYvY3B1L21pY3JvY29kZS9pbnRlbC5jDQo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWlj cm9jb2RlL2ludGVsLmMNCj4gQEAgLTI3LDYgKzI3LDcgQEANCj4gICAjaW5jbHVkZSA8eGVu L3N0cmluZy5oPg0KPiAgICNpbmNsdWRlIDx4ZW4veG1hbGxvYy5oPg0KPiAgIA0KPiArI2lu Y2x1ZGUgPGFzbS9pbnRlbC1mYW1pbHkuaD4NCj4gICAjaW5jbHVkZSA8YXNtL21zci5oPg0K PiAgICNpbmNsdWRlIDxhc20vcHJvY2Vzc29yLmg+DQo+ICAgI2luY2x1ZGUgPGFzbS9zeXN0 ZW0uaD4NCj4gQEAgLTI3Myw2ICsyNzQsNDQgQEAgc3RhdGljIGJvb2wgbWljcm9jb2RlX2Zp dHNfY3B1KGNvbnN0IHN0cnVjdCBtaWNyb2NvZGVfcGF0Y2ggKm1jKQ0KPiAgICAgICByZXR1 cm4gZmFsc2U7DQo+ICAgfQ0KPiAgIA0KPiArc3RhdGljIGJvb2wgbWljcm9jb2RlX3NhZmVf dG9fbG9hZChjb25zdCBzdHJ1Y3QgbWljcm9jb2RlX3BhdGNoICptYykNCj4gK3sNCj4gKyAg ICBzdHJ1Y3QgY3B1X3NpZ25hdHVyZSAqY3B1X3NpZyA9ICZ0aGlzX2NwdShjcHVfc2lnKTsN Cj4gKw0KPiArICAgIC8qDQo+ICsgICAgICogVHJlYXQgcHJlLXByb2R1Y3Rpb24gYXMgYWx3 YXlzIHNhZmUgLSBhbnlvbmUgdXNpbmcgcHJlLXByb2R1Y3Rpb24NCj4gKyAgICAgKiBtaWNy b2NvZGUga25vd3Mgd2hhdCB0aGV5IGFyZSBkb2luZywgYW5kIGNhbiBrZWVwIGFueSByZXN1 bHRpbmcgcGllY2VzLg0KPiArICAgICAqLw0KPiArICAgIGlmICggKGludCljcHVfc2lnLT5y ZXYgPCAwIHx8IG1jLT5yZXYgPCAwICkNCj4gKyAgICAgICAgcmV0dXJuIHRydWU7DQo+ICsN Cj4gKyAgICAvKg0KPiArICAgICAqIEdOUjk4IHN0YXRlcyB0aGF0IEdyYW5pdGUgUmFwaWRz IHN5c3RlbXMgaGFuZyB3aGVuIGxvYWRpbmcgbmV3IHVjb2RlIG9uDQo+ICsgICAgICogc3Vm ZmljaWVudGx5IG9sZCBmaXJtd2FyZS4gIEdOUjEwMSByZXRyb2FjdGl2ZWx5IHN0YXRlcyB0 aGF0IG9uZSB1Y29kZQ0KPiArICAgICAqIGhhZCBhbiBpbmNvcnJlY3QgbWluaW11bSByZXZp c2lvbiBmaWVsZCwgaW4gbGlnaHQgb2YgZGlzY292ZXJpbmcgR05SOTguDQo+ICsgICAgICoN Cj4gKyAgICAgKiBCb3RoIGFyZSBpbmNvbXBsZXRlIHN0YXRlbWVudHMgb2YgdGhlIHByb2Js ZW0uDQo+ICsgICAgICoNCj4gKyAgICAgKiBBdCB0aGUgdGltZSBvZiB3cml0aW5nIChBdWd1 c3QgMjAyNiksIHRoZSBiZWxpZXZlZCBzYWZlIHNlcXVlbmNlIGlzOg0KPiArICAgICAqICAg MHgwMTAwMDM3MCAtPiBbMHgwMTAwMDM4MC4uLjB4MDEwMDAzZjNdIC0+IDB4MDEwMDA0MDUg LT4gYW55IGxhdGVyDQo+ICsgICAgICoNCj4gKyAgICAgKiBEaXNhbGxvdyBrbm93bi11bnNh ZmUgbG9hZHMgd2hpbGUgcGVybWl0dGluZyBiZWxpZXZlZC1zYWZlIGxvYWRzLiAgRm9yDQo+ ICsgICAgICogR05SLCB0aGlzIGFsbG93cyBtdWx0aS1ob3AgbG9hZGluZyB0byBnZXQgdXAg dG8gdGhlIGxhdGVzdC4NCj4gKyAgICAgKi8NCj4gKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEu dmZtID09IElOVEVMX0dSQU5JVEVSQVBJRFNfWCAmJg0KPiArICAgICAgICAgYm9vdF9jcHVf ZGF0YS5zdGVwcGluZyA9PSAxICYmIChjcHVfc2lnLT5wZiAmIDB4OTUpICYmDQo+ICsgICAg ICAgICAoKGNwdV9zaWctPnJldiA8IDB4MDEwMDAzODAgJiYgbWMtPnJldiA+PSAweDAxMDAw NDA1KSB8fA0KPiArICAgICAgICAgIChjcHVfc2lnLT5yZXYgPCAweDAxMDAwNDA1ICYmIG1j LT5yZXYgPiAgMHgwMTAwMDQwNSkpICkNCj4gKyAgICB7DQo+ICsgICAgICAgIHByaW50a19v bmNlKFhFTkxPR19XQVJOSU5HICJtaWNyb2NvZGU6IEdyYW5pdGUgUmFwaWRzIGVycmF0dW0g R05SOTggZGV0ZWN0ZWQuICBTa2lwcGluZyB1Y29kZSAweCUwOHhcbiINCj4gKyAgICAgICAg ICAgICAgICAgICAgWEVOTE9HX1dBUk5JTkcgIm1pY3JvY29kZTogRmlybXdhcmUgdXBkYXRl IHJlY29tbWVuZGVkXG4iLA0KPiArICAgICAgICAgICAgICAgICAgICBtYy0+cmV2KTsNCj4g KyAgICAgICAgcmV0dXJuIGZhbHNlOw0KPiArICAgIH0NCj4gKw0KPiArICAgIHJldHVybiB0 cnVlOw0KPiArfQ0KPiArDQo+ICAgc3RhdGljIGludCBjZl9jaGVjayBpbnRlbF9jb21wYXJl KA0KPiAgICAgICBjb25zdCBzdHJ1Y3QgbWljcm9jb2RlX3BhdGNoICpvbGQsIGNvbnN0IHN0 cnVjdCBtaWNyb2NvZGVfcGF0Y2ggKm5ldykNCj4gICB7DQo+IEBAIC0zNjUsNiArNDA0LDcg QEAgc3RhdGljIHN0cnVjdCBtaWNyb2NvZGVfcGF0Y2ggKmNmX2NoZWNrIGludGVsX3Vjb2Rl X3BhcnNlKA0KPiAgICAgICAgICAgICogb25lIHdpdGggaGlnaGVyIHJldmlzaW9uLg0KPiAg ICAgICAgICAgICovDQo+ICAgICAgICAgICBpZiAoIG1pY3JvY29kZV9maXRzX2NwdShtYykg JiYNCj4gKyAgICAgICAgICAgICBtaWNyb2NvZGVfc2FmZV90b19sb2FkKG1jKSAmJg0KPiAg ICAgICAgICAgICAgICAoIXNhdmVkIHx8IGNvbXBhcmVfcmV2aXNpb25zKHNhdmVkLT5yZXYs IG1jLT5yZXYpID09IE5FV19VQ09ERSkgKQ0KPiAgICAgICAgICAgICAgIHNhdmVkID0gbWM7 DQo+ICAgDQoNClJldmlld2VkLWJ5OiBUZWRkeSBBc3RpZSA8dGVkZHkuYXN0aWVAdmF0ZXMu dGVjaD4NCg0KVGVkZHkNCg== --------------pjG0quQQ5qAZwmFDT2wXZmFG-- --------------lk9BpKF28q5HqSgKEZ79QwkS Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqgajwFAwAAAAAACgkQZg+p0QLLz9CR yAv/c9eMD08r3jUu5VYvAUiieLJHm86f39+3fplUOLasf8eWXjLb0U+AIa/oSzAvcJt3vt8envEE 2p51xOd+wQErgV2rXjPidL5ge19VbUQndzvvwdgTm8daZaZXLZhB8IMAkk3iSVloLSJReNKOUSfX yUqYbmkr4WBARGrZQUAoRwCVuiuhpsgZ133dX9OTfezKVSC8BuqK99TjLZii8Lap83NeaHo18Xdf 1MhiGw3mBChbvozSRyTu30sbgTIhthGNoVz2F8tmzXDvET+HpgWxjiI/jPBqXvZmAM0IujSgDCxh 8sWhRsRVvMTRodHmPAi1mDCMvsC4xUS1ZG4kYwAy3D03i4QOFkcSFe7iX+UU6E50L3LJzMA9IDhW EtI7aaxMrb7ePZUMt1O8ysZIcGnmoaSqR4lzS+OZqKL8jxx5p1LQNs0dFAFrzcM/7jW0KtOXz42/ dzZDm29pqHAl5X7bNrHrQ/SFaR1kMeVykHYyZVRt/JIniIOXvbYl6Zh7O9L0 =Dkcu -----END PGP SIGNATURE----- --------------lk9BpKF28q5HqSgKEZ79QwkS-- From xen-devel-bounces@lists.xenproject.org Tue Sep 08 21:07:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 21:07:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412412.1642888 (Exim 4.92) (envelope-from ) id 1x431t-0004qK-0s; Tue, 08 Sep 2026 21:06:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412412.1642888; Tue, 08 Sep 2026 21:06:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x431s-0004qD-UK; Tue, 08 Sep 2026 21:06:56 +0000 Received: by outflank-mailman (input) for mailman id 1412412; Tue, 08 Sep 2026 21:06:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x431o-0004q7-KR for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 21:06:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x431m-00CvCh-Sn for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 23:06:50 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa078d6-8faa-0a2a0a5109dd-0a2a4501d660-14 for ; Tue, 08 Sep 2026 23:06:50 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa078e9-5984-0a2a45010019-d561b33896f6-3 for ; Tue, 08 Sep 2026 23:06:50 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x431K-00GhLn-AS; Tue, 08 Sep 2026 23:06:22 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x431J-006po3-Hm; Tue, 08 Sep 2026 23:06:22 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x431J-00000007CH8-21e5; Tue, 08 Sep 2026 23:06:21 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=W0woORh2sNhrNSjAwp60+N8VcUpv9x0tKH5X9eMmLCg=; b=V5NqWq41aeMDKSrS6F5dVbnjgf wmRNBzjY7koiaSRlpGgHcaEW+WiAjGfhY/AEBITXtuN8+Kj0qi1WkK9OzF0EWMNO42/ZOFej31+MA NGAaehYeDoel9AG2AePrXiLwxJHohpFSAXawU2in6A+w+AuGEpKLe1yII5ZaFS1qqYALtstTNnmOC 2s+3GD2s/LB1h6jOgF5kc/LMFN1w/Teo51XlhZuHYFSRRd073dS50NCZfUOZq2f2x7ICyy/IWFAam P7XJzaL2aI1lgZg3A/is2Ir0mMDVhCGr/verxPv1N4zGbjDZ9Epx56fgVqg0lWScqdp3txuKyvqNJ MSbbubvg==; MIME-Version: 1.0 Date: Tue, 08 Sep 2026 18:06:21 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() In-Reply-To: <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> Message-ID: X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-d62444/1788901610-1D67C757-E66A97A8/0/0 X-purgate-type: clean X-purgate-size: 580 On 2026-09-08 16:32, Borislav Petkov wrote: > On Tue, Sep 08, 2026 at 03:04:53PM -0300, Mauricio Faria de Oliveira wrote: >> Boris, perhaps the approach here could be changed to add an actual >> memcmp()-like inline implementation (e.g., as provided in a previous >> revision, without return value differences), or continue with the >> memeq()-like memcmp() from arch/x86/boot/ but rename it to memeq() ? > > Nah, new functionality is not needed. We can add it later when it is really needed. Ack, and to confirm: not rename the existing one, either? -- Mauricio From xen-devel-bounces@lists.xenproject.org Tue Sep 08 21:57:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 21:57:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412432.1642925 (Exim 4.92) (envelope-from ) id 1x43or-0004Ox-FF; Tue, 08 Sep 2026 21:57:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412432.1642925; Tue, 08 Sep 2026 21:57:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x43or-0004Oo-Bh; Tue, 08 Sep 2026 21:57:33 +0000 Received: by outflank-mailman (input) for mailman id 1412432; Tue, 08 Sep 2026 21:57:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x43oq-0003xW-Ax for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 21:57:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x43op-005JD4-OE for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 23:57:31 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0847a-2eae-0a2a0a5409dd-0a2a4506a8b0-48 for ; Tue, 08 Sep 2026 23:57:27 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa084c7-195a-0a2a45060019-d155dd31a5b1-3 for ; Tue, 08 Sep 2026 23:57:27 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-4843e397f74so5544437f8f.1 for ; Tue, 08 Sep 2026 14:57:27 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883927a3sm30151604f8f.11.2026.09.08.14.57.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2026 14:57:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788904647; x=1789509447; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=8nsY8C7Ub4Yq2VugNbgpd/jDfcIIEiXdpyQ8LzQ4e38=; b=StpWe4GOOjirw/+q+J8orS8Ej1gfFqGjM9dZRwCTfooAk6NVuXQP++zNmqLHwo+qS5 wN5XEODCqo75jM12fJjGnXGK8XFFDqCBQLPQmdJuIGfrW03ftX+6mPkg6z6K4utFbBfG i0wx14lzIRTXh1FTg4JEER/pck65qikpcTPk0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788904647; x=1789509447; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=8nsY8C7Ub4Yq2VugNbgpd/jDfcIIEiXdpyQ8LzQ4e38=; b=We7Mwx1JhzK4bpR3rNBH7IJcy98BQqj61zlKNm7xLfY+zKHqfvWcsr35KrVmq0JEti WRQ5ABeenTC9Sp/vsxar/WolEFRMH30oMyE3FfQ8KHPtT7XqtJmNPx8XVhq8H1uyAL7m mEAa1w5OB/reMVUCTDV/ckY8NLW+Wm0439EQFoEjykptSrMKphyQCzFS1pn0UvLV0J61 tRM86+r+wqIFg5jd/X68Jgn9m7/iQGr3qJszyYA7G754KsHnBRHIaW2dm5bPnD/4mchv 768oMnWCMjbcNKDQ46RhqCrHzlF7c/FUrqjlFuSLDa7L9Jd8U+1FFoweNlLHpdgoLQtB 5SOw== X-Gm-Message-State: AFuF++lyCrziUljt0wGcTiU7EuLJBsVvZuJolHO1ntywu7UWDC5Tacxx aUgM3oKL+wUmvPyuyAia6EckHogEqzbvzBZuvWpObLM98zvpwhIHN1TAvvmiWfFk3V2Qa+RjEAf RPbRddmA= X-Gm-Gg: AYBFou0O26E6riEjxyvbdfzIAwdfPjsNRWGHa0tpX34kGGuC80UieWSu0t6gIXhw00m 2YiJSn6QCcOB3I8sFB+72bkYncmt0NbSNRwohQgT+0l3EuHrry23yqJHiTIT4GXHl26Gi7att9k wH6m/EJKOCfBdsG21lLioStuYkWsTcndL/hs8FMybUmHSuUY0i8yuVaXzoRSVqkrkQ+7ckJTI5b 1hbAboO8LJ64hZ91gQJ3CGfzE3DwV3iG7uSYJkChdpT1Ac6BPK6NdOmOVWQx0/uIp4hewKGAE5o ziNlkwrtc4rhxWdNLlfDQVQ4jnoQAJOw+GmUMMglajP0sL8xEqVxOycsfuyR7mbz4lotjo0/2W0 +VNqRF6wTi9P5dsd+RcjfFK1tft6TxPIL91eR7yUK2HVlb64/IvnynHv2NL8/qtKAgZZu3mG30c klXZs1tKSZtYbcTopG679FxezGd85udVL2Dvokcv/iPardE6vzdwqgWy1NY6LJCQ+UELLZxWkEY LRtyHlRPRu60JtuWFiXv8QJOhgkGfPod3tx2Usp9Xwdlht4pCQ= X-Received: by 2002:a05:6000:26ca:b0:485:9309:6ec1 with SMTP id ffacd0b85a97d-485930976admr27972933f8f.13.1788904646454; Tue, 08 Sep 2026 14:57:26 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH 1/3] x86/pv: Convert struct mmio_ro_emulate_ctxt to use pci_sbdf_t Date: Tue, 8 Sep 2026 22:57:19 +0100 Message-Id: <20260908215721.3346842-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260908215721.3346842-1-andrew.cooper3@citrix.com> References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1788904647-1EAC277B-4A539AA2/0/0 X-purgate-type: clean X-purgate-size: 2450 This will be used to simplify some call chains. Reposition the new field to avoid creating a interior hole. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie --- xen/arch/x86/pv/ro-page-fault.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/pv/ro-page-fault.c b/xen/arch/x86/pv/ro-page-fault.c index d89306d34fc6..e70e09a6a6a1 100644 --- a/xen/arch/x86/pv/ro-page-fault.c +++ b/xen/arch/x86/pv/ro-page-fault.c @@ -301,10 +301,10 @@ static int ptwr_do_page_fault(struct x86_emulate_ctxt *ctxt, struct mmio_ro_emulate_ctxt { unsigned long cr2; - /* Used only for mmcfg case */ - unsigned int seg, bdf; /* Used only for non-mmcfg case */ mfn_t mfn; + /* Used only for mmcfg case */ + pci_sbdf_t sbdf; }; static int cf_check mmcfg_intercept_write( @@ -329,10 +329,10 @@ static int cf_check mmcfg_intercept_write( } offset &= 0xfff; - if ( pci_conf_write_intercept(mmio_ctxt->seg, mmio_ctxt->bdf, + if ( pci_conf_write_intercept(mmio_ctxt->sbdf.seg, mmio_ctxt->sbdf.bdf, offset, bytes, p_data) >= 0 ) - pci_mmcfg_write(mmio_ctxt->seg, PCI_BUS(mmio_ctxt->bdf), - PCI_DEVFN(mmio_ctxt->bdf), offset, bytes, + pci_mmcfg_write(mmio_ctxt->sbdf.seg, mmio_ctxt->sbdf.bus, + mmio_ctxt->sbdf.devfn, offset, bytes, *(uint32_t *)p_data); return X86EMUL_OKAY; @@ -390,6 +390,7 @@ static int mmio_ro_do_page_fault(struct x86_emulate_ctxt *ctxt, unsigned long addr, l1_pgentry_t pte) { struct mmio_ro_emulate_ctxt mmio_ro_ctxt = { .cr2 = addr }; + unsigned int seg, bdf; mfn_t mfn = l1e_get_mfn(pte); if ( mfn_valid(mfn) ) @@ -404,8 +405,12 @@ static int mmio_ro_do_page_fault(struct x86_emulate_ctxt *ctxt, } ctxt->data = &mmio_ro_ctxt; - if ( pci_ro_mmcfg_decode(mfn_x(mfn), &mmio_ro_ctxt.seg, &mmio_ro_ctxt.bdf) ) + if ( pci_ro_mmcfg_decode(mfn_x(mfn), &seg, &bdf) ) + { + mmio_ro_ctxt.sbdf = PCI_SBDF(seg, bdf); + return x86_emulate(ctxt, &mmcfg_intercept_ops); + } mmio_ro_ctxt.mfn = mfn; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Sep 08 21:57:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 21:57:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412431.1642909 (Exim 4.92) (envelope-from ) id 1x43oq-0003vV-3Y; Tue, 08 Sep 2026 21:57:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412431.1642909; Tue, 08 Sep 2026 21:57:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x43op-0003vN-VY; Tue, 08 Sep 2026 21:57:31 +0000 Received: by outflank-mailman (input) for mailman id 1412431; Tue, 08 Sep 2026 21:57:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x43on-0003mr-Kz for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 21:57:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x43om-00Ebur-9q for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 23:57:28 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa08476-e002-0a2a0a5209dd-0a2a4502d8d0-46 for ; Tue, 08 Sep 2026 23:57:28 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa084c7-6ca4-0a2a45020019-d155dd33d96f-3 for ; Tue, 08 Sep 2026 23:57:28 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-485850cf499so3423721f8f.3 for ; Tue, 08 Sep 2026 14:57:28 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883927a3sm30151604f8f.11.2026.09.08.14.57.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2026 14:57:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788904647; x=1789509447; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=mx0mbQyAO+ZqGpRbcIGGYFMcnA7LXXlkWe7jpOQ9f0A=; b=gpsNh0Ucct2iiMFHjLtfQLQ3uVd9eO9XQuXfjoa1ELh7w7TiT90rtU3r4Zsa20ys5Q y0X9rEjzgkonET3buSz6YsLbVXZ/8x6Z7XArPTTUIMYas+rpBg6zeRHknRUuNeW2meZq CXhMoSoaIJzkaZuYKjY+A3RlNCMjoKv1ZV1wo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788904647; x=1789509447; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mx0mbQyAO+ZqGpRbcIGGYFMcnA7LXXlkWe7jpOQ9f0A=; b=pAZmlBWOT7P+xlcLiy+Y/4EfkQ3wkJfJGpc1zysLVL9fJSbsRJTKbH8Pne0surOuhk E0dz2Pq2IMs4FMRuVcqerPW9skcadmovmBDQpPk0uIikX72X6BiqUROIfVBRjznYIBZZ chkr4Ox7X6k3PXuznwZKUWM16O8khO9dlLYsCSMqmewXWiILbrn6gtv+ORRoQ+29IFDV qpDS+MJ5V7xXj79YoUBzFR6cxozZHuzuT1l7mBiWaRCETOkqvrGnivs3QiYkUlOB+59/ aEcrchw9Nd/gmsDzJRW6K0VYS7Xpoq54X9dQKWM3/ZGOm8WBkisMAJ8lNqcBuVOI5zZa FrJA== X-Gm-Message-State: AFuF++kXyQyaNWpBotq5Oel7EQqASw3EgKZe6jWIAdQhk8i5bRJiTfJX +oQlGvtkV60kL4pyfKhk3YFuWOWjk/ohBBfXHCT4dy7I33V+T/uzjC/MUWj5PgoGZYFYEQBfQbu fJYQZ X-Gm-Gg: AYBFou1jg+sI2yeAK7OD4Kz96VORHkrprB9mERhlZGIB9jjCQPEY9Ws+2dQnEMeq2be MdMkqD+6vhg/tWPS6ZQLrbR2qz91qfm9y3A4tGiuNI0Kv7t2x6ww4xYLxRLIdnHGJ2nfFw757H4 tRwdZ5TMkDofwhiZbgb/x2vy0SXveryHgX5kf+KycHM/FP6rvYY9lm2R+MrwhqDG4lqVl15o8tB MuZqlTHNYp+qiPPRDH5IYQftsIxrtIlDz+jBPLkoBvKtYXQFdTGo8zd5EqqO8xgVulgR90373Mu riDrz08m/hZiEznjksCUCi5mVWYQS3h4HBO00H8cDdpuhNYtW1YUw/oq1swwondq3FA1TxHl1XJ wJ6oqJypYft3DnK2PzaHfezzXdHBh4/FQW4Vtq26uMNIk++cJl6DJYogDv8bnflc8sPruFH2d/F +Y5fWtT4B2yd9Kpzxo7eAsYa1u8AYpTeJObvOdGh4+lTtKGmzGDb7gaziao18cnde7j6cWMn4cL yPfW/sRFtDrnCHmeiswYkpz11WtbIe6MAwUXFg= X-Received: by 2002:a05:6000:4694:b0:47f:80d1:be0a with SMTP id ffacd0b85a97d-485872a0086mr28634604f8f.14.1788904647115; Tue, 08 Sep 2026 14:57:27 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH 2/3] x86/pci: Convert pci_mmcfg_{read,write}() to use pci_sbdf_t Date: Tue, 8 Sep 2026 22:57:20 +0100 Message-Id: <20260908215721.3346842-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260908215721.3346842-1-andrew.cooper3@citrix.com> References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788904648-F26B72AC-741A4236/0/0 X-purgate-type: clean X-purgate-size: 6680 All callers now have an sbdf already. Pass it down directly, rather than splitting into three parameters. In turn this shows that bus and devfn bounds checks were unreachable, making them safe to drop. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie --- xen/arch/x86/pv/ro-page-fault.c | 4 +--- xen/arch/x86/x86_64/mmconfig_64.c | 18 ++++++++---------- xen/arch/x86/x86_64/pci.c | 12 ++++++------ xen/include/xen/pci.h | 8 ++++---- 4 files changed, 19 insertions(+), 23 deletions(-) diff --git a/xen/arch/x86/pv/ro-page-fault.c b/xen/arch/x86/pv/ro-page-fault.c index e70e09a6a6a1..c10541709e8b 100644 --- a/xen/arch/x86/pv/ro-page-fault.c +++ b/xen/arch/x86/pv/ro-page-fault.c @@ -331,9 +331,7 @@ static int cf_check mmcfg_intercept_write( offset &= 0xfff; if ( pci_conf_write_intercept(mmio_ctxt->sbdf.seg, mmio_ctxt->sbdf.bdf, offset, bytes, p_data) >= 0 ) - pci_mmcfg_write(mmio_ctxt->sbdf.seg, mmio_ctxt->sbdf.bus, - mmio_ctxt->sbdf.devfn, offset, bytes, - *(uint32_t *)p_data); + pci_mmcfg_write(mmio_ctxt->sbdf, offset, bytes, *(uint32_t *)p_data); return X86EMUL_OKAY; } diff --git a/xen/arch/x86/x86_64/mmconfig_64.c b/xen/arch/x86/x86_64/mmconfig_64.c index 91b1a398e646..6477bf8b44bd 100644 --- a/xen/arch/x86/x86_64/mmconfig_64.c +++ b/xen/arch/x86/x86_64/mmconfig_64.c @@ -55,19 +55,18 @@ static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus, unsigned i return addr + ((bus << 20) | (devfn << 12)); } -int pci_mmcfg_read(unsigned int seg, unsigned int bus, - unsigned int devfn, int reg, int len, u32 *value) +int pci_mmcfg_read( + pci_sbdf_t sbdf, unsigned int reg, unsigned int len, uint32_t *value) { char __iomem *addr; /* Why do we have this when nobody checks it. How about a BUG()!? -AK */ - if (unlikely((bus > 255) || (devfn > 255) || - (reg + len > PCI_CFG_SPACE_EXP_SIZE))) { + if (unlikely(reg + len > PCI_CFG_SPACE_EXP_SIZE)) { err: *value = -1; return -EINVAL; } - addr = pci_dev_base(seg, bus, devfn); + addr = pci_dev_base(sbdf.seg, sbdf.bus, sbdf.devfn); if (!addr) goto err; @@ -86,17 +85,16 @@ err: *value = -1; return 0; } -int pci_mmcfg_write(unsigned int seg, unsigned int bus, - unsigned int devfn, int reg, int len, u32 value) +int pci_mmcfg_write( + pci_sbdf_t sbdf, unsigned int reg, unsigned int len, uint32_t value) { char __iomem *addr; /* Why do we have this when nobody checks it. How about a BUG()!? -AK */ - if (unlikely((bus > 255) || (devfn > 255) || - (reg + len > PCI_CFG_SPACE_EXP_SIZE))) + if (unlikely(reg + len > PCI_CFG_SPACE_EXP_SIZE)) return -EINVAL; - addr = pci_dev_base(seg, bus, devfn); + addr = pci_dev_base(sbdf.seg, sbdf.bus, sbdf.devfn); if (!addr) return -EINVAL; diff --git a/xen/arch/x86/x86_64/pci.c b/xen/arch/x86/x86_64/pci.c index 6298141c3ca7..970c010e12f6 100644 --- a/xen/arch/x86/x86_64/pci.c +++ b/xen/arch/x86/x86_64/pci.c @@ -17,7 +17,7 @@ uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg) if ( sbdf.seg || reg > 255 ) { - pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 1, &value); + pci_mmcfg_read(sbdf, reg, 1, &value); return value; } @@ -30,7 +30,7 @@ uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg) { uint32_t value; - pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 2, &value); + pci_mmcfg_read(sbdf, reg, 2, &value); return value; } @@ -43,7 +43,7 @@ uint32_t pci_conf_read32(pci_sbdf_t sbdf, unsigned int reg) { uint32_t value; - pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 4, &value); + pci_mmcfg_read(sbdf, reg, 4, &value); return value; } @@ -53,7 +53,7 @@ uint32_t pci_conf_read32(pci_sbdf_t sbdf, unsigned int reg) void pci_conf_write8(pci_sbdf_t sbdf, unsigned int reg, uint8_t data) { if ( sbdf.seg || reg > 255 ) - pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 1, data); + pci_mmcfg_write(sbdf, reg, 1, data); else pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), reg & 3, 1, data); } @@ -61,7 +61,7 @@ void pci_conf_write8(pci_sbdf_t sbdf, unsigned int reg, uint8_t data) void pci_conf_write16(pci_sbdf_t sbdf, unsigned int reg, uint16_t data) { if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 2) ) - pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 2, data); + pci_mmcfg_write(sbdf, reg, 2, data); else pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), reg & 2, 2, data); } @@ -69,7 +69,7 @@ void pci_conf_write16(pci_sbdf_t sbdf, unsigned int reg, uint16_t data) void pci_conf_write32(pci_sbdf_t sbdf, unsigned int reg, uint32_t data) { if ( sbdf.seg || reg > 255 || !IS_ALIGNED(reg, 4) ) - pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 4, data); + pci_mmcfg_write(sbdf, reg, 4, data); else pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), 0, 4, data); } diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h index ade882caeef4..b7a35371a71a 100644 --- a/xen/include/xen/pci.h +++ b/xen/include/xen/pci.h @@ -258,10 +258,10 @@ void pci_conf_write16(pci_sbdf_t sbdf, unsigned int reg, uint16_t data); void pci_conf_write32(pci_sbdf_t sbdf, unsigned int reg, uint32_t data); uint32_t pci_conf_read(uint32_t cf8, uint8_t offset, uint8_t bytes); void pci_conf_write(uint32_t cf8, uint8_t offset, uint8_t bytes, uint32_t data); -int pci_mmcfg_read(unsigned int seg, unsigned int bus, - unsigned int devfn, int reg, int len, u32 *value); -int pci_mmcfg_write(unsigned int seg, unsigned int bus, - unsigned int devfn, int reg, int len, u32 value); +int pci_mmcfg_read( + pci_sbdf_t sbdf, unsigned int reg, unsigned int len, uint32_t *value); +int pci_mmcfg_write( + pci_sbdf_t sbdf, unsigned int reg, unsigned int len, uint32_t value); unsigned int pci_find_cap_offset(pci_sbdf_t sbdf, unsigned int cap); unsigned int pci_find_next_cap_ttl(pci_sbdf_t sbdf, unsigned int pos, const unsigned int caps[], unsigned int n, -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Sep 08 21:57:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 21:57:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412429.1642899 (Exim 4.92) (envelope-from ) id 1x43op-0003nF-KJ; Tue, 08 Sep 2026 21:57:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412429.1642899; Tue, 08 Sep 2026 21:57:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x43op-0003n8-GT; Tue, 08 Sep 2026 21:57:31 +0000 Received: by outflank-mailman (input) for mailman id 1412429; Tue, 08 Sep 2026 21:57:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x43on-0003mq-Ky for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 21:57:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x43ol-005f1W-9b for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 23:57:27 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa08450-bab6-0a2a0a5309dd-0a2a4505ac84-42 for ; Tue, 08 Sep 2026 23:57:27 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa084c7-4cb1-0a2a45050019-d155802dbd26-3 for ; Tue, 08 Sep 2026 23:57:27 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49556f97a9dso43358935e9.1 for ; Tue, 08 Sep 2026 14:57:27 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883927a3sm30151604f8f.11.2026.09.08.14.57.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2026 14:57:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788904647; x=1789509447; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=YHVAeT2GPyQVTW/x3ZgZmuDMoOXPzwlAseIbiz+kT/w=; b=G5nDTKRzNn6Pszq2a5nU5C06KQEwVOuOLRSSefD4qgWCzvbOWJHkDjL+oXMaKEVsss PqC6Y+Dl/zaf7uiuxpqehxZs4h84W+ZGVkssvrBl68I2T9DA1p7t4/ygJlSEJTUeScF1 1iSBGuMoiAFzcWLgSWY/izSjT0+s3lH4wQXz4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788904647; x=1789509447; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=YHVAeT2GPyQVTW/x3ZgZmuDMoOXPzwlAseIbiz+kT/w=; b=i2U9Moobk7DrJsSe4YoS/ILo92LcP+/VlTv1TJyc/OXNTqXWZ4tw4j3Hhuz3WKnEkt lIU6zBtgHAmN4qSdMl6rZKVzBR0cNCrs+dHI7dtGPo4fn2oaK60jG2ddbpMNx6MAGjNl Az3HbWVhZ2wNY77TYHZ10fpSQLLPo9x9epDcAKYhwYIhZV6XqdltKvAlqNhmnveK6YUs Vb9Zw0ElL1I7breo5F2bXkxjxg86UfBV+AZi2G8I7CJ6AtH9qX1qySaH7yytAs89AVe1 bUpBW+E0QuvrWKKZdvMEu5KsxZZeakhZCM4lpmdiUUduSMNWCaE6e6/cLN3eC7yFqP3j ZmuQ== X-Gm-Message-State: AFuF++leM3jR5fVEkeokhXaiRvhk5Xf+8z2LrG3qPWiFIIeZTdn5JgX9 BenojUyznZyiICcLw34hmEYVFn6CFZXJz3PTAcP5vNhb6XjHXHnoW555GJ14vKaXBaWd2mtg75Q btHtEe3g= X-Gm-Gg: AYBFou2Xu/mFMG4Qq5IxKJFarX31c4nMRlnsAiq+3356o9L6scPXtt//QQ35JiM3Dko mkvdDFtoClxxZhdwRCOzpXiCksSaBLxju0aRZUod2OsuMt+yqqYyhGp79lcbRqt2Wg8VUFl7WLn PMRwo/GS5Taon41QjivWMNf/fw2olc/zc132yffEaoAobjEDOLYdUpZXO+LYfE1/sU0JHp/ZKMQ YdsDsl1dRccf2hlWwlAng1a8m0v9qr8dQcpzizDtq9O+SayMaiihtyHk8aRNrNypXt9AtpEcPcu f+/lOpHdIpGHophP8hCwDpSviTyO+UoYYRPPd6JhP/qRt12bKh7RD0t79YqDyXqfI1z1UWMgAPH 5WuDD7PGxLVtH8DUCjo+2E6HV+st1BKXojpGjEH/Lej6dnuReY++3B+tZzkbaPsKj7Ix+rGoCAB pD2OTPfP2Fj9IPanI6aB9tvgwkkM/x2kBzhddVKly9SDw4606TZWVltqm0mTMZokiDZAFnOmuEs xLNpVUpHqfKi3ymBjL09XtI/TnMVxoy/ek6DrU= X-Received: by 2002:a05:600c:6089:b0:49c:fa21:e73f with SMTP id 5b1f17b1804b1-49cfa21e8b9mr277475065e9.21.1788904645803; Tue, 08 Sep 2026 14:57:25 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH 0/3] x86: Fixes for not-quite-XSA in pci_conf_write_intercept() Date: Tue, 8 Sep 2026 22:57:18 +0100 Message-Id: <20260908215721.3346842-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1788904647-732B32A1-FE1CBD7B/0/0 X-purgate-type: clean X-purgate-size: 831 Plumb pci_sbdf_t up and down the callchain to simplify parameter passing and make it harder to forget the segment. Andrew Cooper (3): x86/pv: Convert struct mmio_ro_emulate_ctxt to use pci_sbdf_t x86/pci: Convert pci_mmcfg_{read,write}() to use pci_sbdf_t x86/pci: Update pci_conf_write_intercept() to use pci_sbdf_t xen/arch/x86/include/asm/pci.h | 5 ++--- xen/arch/x86/pci.c | 6 ++---- xen/arch/x86/pv/emul-priv-op.c | 10 +++++----- xen/arch/x86/pv/ro-page-fault.c | 18 ++++++++++-------- xen/arch/x86/x86_64/mmconfig_64.c | 18 ++++++++---------- xen/arch/x86/x86_64/pci.c | 12 ++++++------ xen/include/xen/pci.h | 8 ++++---- 7 files changed, 37 insertions(+), 40 deletions(-) base-commit: a2ca4f8b9890899ca89d6116002e7a9c5957d8c6 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Sep 08 21:57:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 21:57:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412430.1642902 (Exim 4.92) (envelope-from ) id 1x43op-0003pm-Qj; Tue, 08 Sep 2026 21:57:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412430.1642902; Tue, 08 Sep 2026 21:57:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x43op-0003pf-NG; Tue, 08 Sep 2026 21:57:31 +0000 Received: by outflank-mailman (input) for mailman id 1412430; Tue, 08 Sep 2026 21:57:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x43on-0003ms-KP for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 21:57:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x43om-00Ebur-Fg for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 23:57:28 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa084c6-e002-0a2a0a5209dd-0a2a45099166-6 for ; Tue, 08 Sep 2026 23:57:28 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa084c8-be1a-0a2a45090019-d155dd2bd999-3 for ; Tue, 08 Sep 2026 23:57:28 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-485850cf499so3423728f8f.3 for ; Tue, 08 Sep 2026 14:57:28 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883927a3sm30151604f8f.11.2026.09.08.14.57.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2026 14:57:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788904648; x=1789509448; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Vti7XuJny5sukz1d1q8fbM2VnpDn4fSAdXusGCg11E8=; b=LwDth/1xbthXUCa1pjtOyVYtPb+FxMjT4/TMBaqsh+5MnMb76H7LAHbgKS5LqdqRMW +NaYs6p8eQKggHlYrVtfXefAUROW/nQfoETQx1Gi53tZcraDdcWsrq1GvuVyL8nyyqzf bOXY2BwRIGkoTT2DGPMUo7DLOdrmDL22TLNKs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788904648; x=1789509448; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Vti7XuJny5sukz1d1q8fbM2VnpDn4fSAdXusGCg11E8=; b=ZnVKnten+3JDd79hlyhO1gXw+73vQ8NVrKra9GqzxWfg0EtdFf3T6a7yxPK8nonIwn Ne9A+fYP5emP6A0VEA0OLm7oLYO7iyLd6reJSMUfUFxbul290OWcq7JJ3gfnW7T9BBud qusnHAM3clInkpcKTX4dWfiwaBhfUodSB7u2uQ3DcIP+F7EsYmSbUhcghuyUywQRygDe Gi4IPTPHJLS0jt+029m/xunxXWptaA7nBO2nyd7YK9YEdSRUU/7Kq6uPkNaTVNYdBE+x NgVJur1/PoDxuddXb9MEfXuD4DdjoCuNtuNjtTwxWiMnYuxmRCq9laoMu06SrFWlzJJT oxtg== X-Gm-Message-State: AFuF++nvQ/mLOnnJgSwLTMZXu4zVje/pDJI2GL4L8kGZQnY8GMRA3QS1 4fCCno0H/BRbLJ4646l132WwSY8LzfW2qr/YKyqi0/OP31BZ0m9dj1Fx2tlDzX1Zp8agH0wjzBh ZAkprOSw= X-Gm-Gg: AYBFou2xg2rGFc3AR7+B3luIkffatxzLvVd8EE4n5rd/z26ipff86JqxDjgRk49hfKr xVMhFL49Gc4fVb6PMlhNXl9pXhTmP/sHrlO9mth7oDXt4hTMPNH/xPlESy4Ly/Mc9Z1VueRZya2 pF6guU+k5s2MQ7w+QN8wBu3fg+rMa9GXQSgUN9GhbBuSvRnxF/dlDiYlGAERZ77ZYeGIEs63Gvp 5Hfh+xvQfhPn9c+rJCjwyj7gc/2QvJkc7yds4KuU+qwltlSCFRlBNVGQuk7zlCjGnhi2X8m/H9B Sh4h8ItV5yBEWF+J4+pjFFrzfyh/SaYyQC9G0flpKINHb5/SI3fNUhbTxp/mbeAg8AOyHy7lqWn UsAEnZwN8zjGSN5HRnylTGWj/ainZ8E7KCqhNnyUAlwoMOTCgRr3Of/hpt2njbIAzi6GibKvd2f QSoQ5S7UXahIF1qUaMLfy3DXxDC5Q6yHi2bf2N3HEETGbZGAREVNJWoxvkaQDstvDRbgFsd8XuO y1VHeWHtsX3w8YeahKx+tGP9Ou6O8d7+/4J76A= X-Received: by 2002:a05:6000:2287:b0:485:8c17:975c with SMTP id ffacd0b85a97d-4858c179908mr27978280f8f.30.1788904647749; Tue, 08 Sep 2026 14:57:27 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH 3/3] x86/pci: Update pci_conf_write_intercept() to use pci_sbdf_t Date: Tue, 8 Sep 2026 22:57:21 +0100 Message-Id: <20260908215721.3346842-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260908215721.3346842-1-andrew.cooper3@citrix.com> References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1788904648-39AC0034-FC394EDA/0/0 X-purgate-type: clean X-purgate-size: 4452 ... rather than splitting across two parameters. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie --- xen/arch/x86/include/asm/pci.h | 5 ++--- xen/arch/x86/pci.c | 6 ++---- xen/arch/x86/pv/emul-priv-op.c | 10 +++++----- xen/arch/x86/pv/ro-page-fault.c | 3 +-- 4 files changed, 10 insertions(+), 14 deletions(-) diff --git a/xen/arch/x86/include/asm/pci.h b/xen/arch/x86/include/asm/pci.h index 0b98081aeaa4..8d8e66928d7f 100644 --- a/xen/arch/x86/include/asm/pci.h +++ b/xen/arch/x86/include/asm/pci.h @@ -36,9 +36,8 @@ struct arch_pci_dev { struct page_list_head pgtables_list; }; -int pci_conf_write_intercept(unsigned int seg, unsigned int bdf, - unsigned int reg, unsigned int size, - uint32_t *data); +int pci_conf_write_intercept( + pci_sbdf_t sbdf, unsigned int reg, unsigned int size, uint32_t *data); int pci_msi_conf_write_intercept(struct pci_dev *pdev, unsigned int reg, unsigned int size, uint32_t *data); bool pci_mmcfg_decode(unsigned long mfn, unsigned int *seg, diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c index 4c279875517b..0731f7e762b8 100644 --- a/xen/arch/x86/pci.c +++ b/xen/arch/x86/pci.c @@ -72,11 +72,9 @@ void pci_conf_write(uint32_t cf8, uint8_t offset, uint8_t bytes, uint32_t data) spin_unlock_irqrestore(&pci_config_lock, flags); } -int pci_conf_write_intercept(unsigned int seg, unsigned int bdf, - unsigned int reg, unsigned int size, - uint32_t *data) +int pci_conf_write_intercept( + pci_sbdf_t sbdf, unsigned int reg, unsigned int size, uint32_t *data) { - pci_sbdf_t sbdf = PCI_SBDF(seg, bdf); struct pci_dev *pdev; int rc = xsm_pci_config_permission(XSM_HOOK, current->domain, sbdf.sbdf, reg, reg + size - 1, true); diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index dc21515e447b..fd9b533e57c7 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -228,7 +228,7 @@ static bool admin_io_okay(unsigned int port, unsigned int bytes, static bool pci_cfg_ok(struct domain *currd, unsigned int start, unsigned int size, uint32_t *write) { - uint32_t machine_bdf; + pci_sbdf_t sbdf = {}; /* Seg always 0 for IO port CFG accesses. */ if ( !is_hardware_domain(currd) ) return false; @@ -236,12 +236,12 @@ static bool pci_cfg_ok(struct domain *currd, unsigned int start, if ( !CF8_ENABLED(currd->arch.pci_cf8) ) return true; - machine_bdf = CF8_BDF(currd->arch.pci_cf8); + sbdf.bdf = CF8_BDF(currd->arch.pci_cf8); if ( write ) { const unsigned long *ro_map = pci_get_ro_map(0); - if ( ro_map && test_bit(machine_bdf, ro_map) ) + if ( ro_map && test_bit(sbdf.bdf, ro_map) ) return false; } start |= CF8_ADDR_LO(currd->arch.pci_cf8); @@ -259,9 +259,9 @@ static bool pci_cfg_ok(struct domain *currd, unsigned int start, } return !write ? - xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf, + xsm_pci_config_permission(XSM_HOOK, currd, sbdf.sbdf, start, start + size - 1, false) == 0 : - pci_conf_write_intercept(0, machine_bdf, start, size, write) >= 0; + pci_conf_write_intercept(sbdf, start, size, write) >= 0; } static uint32_t guest_io_read(unsigned int port, unsigned int bytes, diff --git a/xen/arch/x86/pv/ro-page-fault.c b/xen/arch/x86/pv/ro-page-fault.c index c10541709e8b..34349e9437eb 100644 --- a/xen/arch/x86/pv/ro-page-fault.c +++ b/xen/arch/x86/pv/ro-page-fault.c @@ -329,8 +329,7 @@ static int cf_check mmcfg_intercept_write( } offset &= 0xfff; - if ( pci_conf_write_intercept(mmio_ctxt->sbdf.seg, mmio_ctxt->sbdf.bdf, - offset, bytes, p_data) >= 0 ) + if ( pci_conf_write_intercept(mmio_ctxt->sbdf, offset, bytes, p_data) >= 0 ) pci_mmcfg_write(mmio_ctxt->sbdf, offset, bytes, *(uint32_t *)p_data); return X86EMUL_OKAY; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Sep 08 23:17:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 08 Sep 2026 23:17:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412474.1642934 (Exim 4.92) (envelope-from ) id 1x454R-0000Vq-0a; Tue, 08 Sep 2026 23:17:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412474.1642934; Tue, 08 Sep 2026 23:17: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 1x454Q-0000Vj-TN; Tue, 08 Sep 2026 23:17:42 +0000 Received: by outflank-mailman (input) for mailman id 1412474; Tue, 08 Sep 2026 23:17:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x454O-0000Vc-NO for xen-devel@lists.xenproject.org; Tue, 08 Sep 2026 23:17:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x454N-0031pj-JD for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 01:17:39 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0978e-e002-0a2a0a5209dd-0a2a4508d874-16 for ; Wed, 09 Sep 2026 01:17:39 +0200 Received: from [198.137.202.136] (helo=mail.zytor.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa09791-f659-0a2a45080019-c689ca88a178-3 for ; Wed, 09 Sep 2026 01:17:38 +0200 Received: from [IPV6:2601:646:8081:8d71:e98b:813a:9897:e5d1] ([IPv6:2601:646:8081:8d71:e98b:813a:9897:e5d1]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 688NGusI2287284 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 8 Sep 2026 16:16:56 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=2026082801 header.d=zytor.com header.i="@zytor.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 688NGusI2287284 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026082801; t=1788909420; bh=YxvPbk1+TIa+eRjm3uzymXdFyg0V4mRSsiJGDFWOH4c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=DhyEuYlJaKlD5Kqmx1TR6UbWQOE2kUzui755tS5hezt4IAReRx2LCRaz8exC7PYiV 2tY6rnOGQK3M9ywC0h8kXKEFjc2o6kFF6poiyH9WdyWsr2+QlZxds+1u2MwrHSfwG+ XLbKaeii0VHMChicpduK82c3XGU/pKMi5DDWa4O6CWkTWkZFzkg45hbAk2FmaT2ka8 xenh3PCD3NouI+Xtx0kVqsAN2RA7rQ5EGQv7eglg8KNs8Hfcv2rZP7c0guZx/YQOIJ n4zWBf7ULs/igJ9KZOSWOg/f+/eKClMasKTWLS0RWqOHcG4Q4tjgRcow7mDQy8vCA3 IyQJ4H5mGZ+pQ== Message-ID: Date: Tue, 8 Sep 2026 16:16:51 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() To: Borislav Petkov , Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788909459-D514E87B-3C234374/0/0 X-purgate-type: clean X-purgate-size: 3246 On 2026-09-08 12:32, Borislav Petkov wrote: > On Tue, Sep 08, 2026 at 03:04:53PM -0300, Mauricio Faria de Oliveira wrote: >> Boris, perhaps the approach here could be changed to add an actual >> memcmp()-like inline implementation (e.g., as provided in a previous >> revision, without return value differences), or continue with the >> memeq()-like memcmp() from arch/x86/boot/ but rename it to memeq() ? > > Nah, new functionality is not needed. We can add it later when it is really needed. > I personally think it would be a good reason to explicitly rename it memeq(), after all it indicates what it actually *does*. bool memeq(const void *m1, const void *m2, size_t n); Note, however, that the sense of the return value is opposite -- true means equal, so !memcmp(...) needs to be replaced with memeq(...) and vice versa. The other issue is when gcc/clang wants to call memcmp() out of line. Although a theoretical concern, there really isn't any reason not to DTRT there since there is only one instance in the code, ever. Here is an out-of-line compact memcmp() which works for both 16/32 and 64 bits: int memcmp(const void *s1, const void *s2, size_t len) { int rv; asm volatile("xor %0,%0 ; " "test %3, %3 ; " /* Handle len == 0 correctly */ "repe cmpsb ; "}g "setz %b0 ; " "sbb $0, %0" : "=&r" (rv), "+D" (s1), "+S" (s2), "+c" (len) : : "cc", "memory"); return rv; } On 64 bits it compiles to: 0000000000000000 : 0: 48 89 d1 mov %rdx,%rcx 3: 31 d2 xor %edx,%edx 5: 31 c0 xor %eax,%eax 7: f3 a6 repz cmpsb (%rdi),(%rsi) 9: 0f 97 c2 seta %dl c: 0f 92 c0 setb %al f: 29 d0 sub %edx,%eax 11: c3 ret On 32 bits (-mregparm=3): 00000000 : 0: 57 push %edi 1: 56 push %esi 2: 89 c7 mov %eax,%edi 4: 89 d6 mov %edx,%esi 6: 31 d2 xor %edx,%edx 8: 31 c0 xor %eax,%eax a: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi) c: 0f 97 c2 seta %dl f: 0f 92 c0 setb %al 12: 29 d0 sub %edx,%eax 14: 5e pop %esi 15: 5f pop %edi 16: c3 ret On 16 bits: 00000000 : 0: 66 57 push %edi 2: 66 56 push %esi 4: 66 89 c7 mov %eax,%edi 7: 66 89 d6 mov %edx,%esi a: 66 31 d2 xor %edx,%edx d: 66 31 c0 xor %eax,%eax 10: f3 a6 repz cmpsb %es:(%di),%ds:(%si) 12: 0f 97 c2 seta %dl 15: 0f 92 c0 setb %al 18: 66 29 d0 sub %edx,%eax 1b: 66 5e pop %esi 1d: 66 5f pop %edi 1f: 66 c3 retl -hpa From xen-devel-bounces@lists.xenproject.org Wed Sep 09 05:53:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 05:53:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412540.1642943 (Exim 4.92) (envelope-from ) id 1x4BFA-0004ol-1u; Wed, 09 Sep 2026 05:53:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412540.1642943; Wed, 09 Sep 2026 05:53:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4BF9-0004od-Sy; Wed, 09 Sep 2026 05:53:11 +0000 Received: by outflank-mailman (input) for mailman id 1412540; Wed, 09 Sep 2026 05:53:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4BF7-0004oX-Kl for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 05:53:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4BF6-003kHi-Go for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 07:53:08 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0f42f-2eae-0a2a0a5409dd-0a2a4504e08e-38 for ; Wed, 09 Sep 2026 07:53:07 +0200 Received: from [52.101.125.77] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0f43b-b57f-0a2a45040019-34657d4d5eb7-3 for ; Wed, 09 Sep 2026 07:53:01 +0200 Received: from TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:af::12) by TY6P286MB7361.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:35c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Wed, 9 Sep 2026 05:52:55 +0000 Received: from TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM ([fe80::2067:ff0e:4c3:ad0b]) by TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM ([fe80::2067:ff0e:4c3:ad0b%5]) with mapi id 15.21.0360.008; Wed, 9 Sep 2026 05:52:55 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MWhhUUKLNqYZNfePFnnJVDZrxfpGDzkbRMwrL87K9W9MzbwcZRLefzyf5cCEqyFk75Q/t9g/CUhxl3djPvFXYE7zlUzbxh0QKcoenkI0d3WwFI7LLJnS2Y9bTgrVNBWFEFkDesO9RbSeBZsN4JmIeEZdATyh6sB2fIogVEyQrd4Id9Oyr44cryo1kRL+NFBJKHuOSKXwTowF/oLkvo2xImnbkNEd059/ps60OYoYfZXlpObLnxI8+K6ksnN1gikzohCwhLUIhju6qnjsewQPNAWxb1AeFSBWvHz8XlCR+gclSIcxPB9GZSnxeqZDd0nblDdQxstFo3sMtzn0Qi2IMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BWaPMVJIRKQcX9poEII5w10otm4TFZtQ5aiX1u0k+S8=; b=WvkHT/NNiIq+BW+llXIo01ZqT+vaTlaR7vS5AvscwCXZC9hMEhRjsueV1Pi+3xcNThY7m8IOvlD80+nW9ie9vj/saOlFFK1CQqN9Z5HZY7zwMXgnnpKO7Jnfe/K0gdZvhXFn+2N8qC4T3ZiSOMCfl9dXwTXRSJA7MP9iSB6jWfmOQlicoguJagEGabXsomM5IYiIIP6Dk8xKg/ImaCfmGmFscCzwLetdFORpECjdygzn03W9VBjz5EIDP8Ov5Tw2Hj9i5N05fLGpD0j5KmM8hR8nfOpZGyTM14wMZXPT+tM73UbwTm9OIe2/uHSMz816gyBoq2uWYvUpH1+ppDPb3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BWaPMVJIRKQcX9poEII5w10otm4TFZtQ5aiX1u0k+S8=; b=eV3Ljmg1xz0FQV2u+Li1NSMzSqJMqP/5xqacTUwDsBzdQuEBsKyXvPs7e8QbZPHMXSv5l4YtqkS/qG++HyFqCur+p4DDfucI18NmvcKB3C/khcV2hpd0sZtQF5xFqQM+fXde9XLxEU5uezdt3SntUE7zjuiryx0EjzUt5JQlz4M= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryoji Okamoto To: xen-devel@lists.xenproject.org Cc: Hirokazu Takahashi , Ryoji Okamoto , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH] xen/arm64/atomic: Clear exclusive monitor on cmpxchg failure Date: Wed, 9 Sep 2026 14:52:37 +0900 Message-ID: <20260909055238.521966-1-okamoto@valinux.co.jp> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TY4P301CA0028.JPNP301.PROD.OUTLOOK.COM (2603:1096:405:2b1::10) To TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:af::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TYCP286MB1053:EE_|TY6P286MB7361:EE_ X-MS-Office365-Filtering-Correlation-Id: 9d6feddb-1206-4942-c41f-08df0e3697ed X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|376014|1800799024|23010399003|366016|10067099003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: mMj4I95xT0qSXtNJligsI4ifziqF9RBv9vdgA7UB7m5ymcGC7/R5XVkijJV3qd/IMFIILBrJCpNYCprHB4hp12HU1WNLyJ6sEOG1vN98tyZ3Upa9ssBLm+9rW+Toi31dW1o+38ZaBt6bitrdb6xT7rpiooHLo0I0Ela5IcgDBzNJWTS1L5ZyPrYb3mhcDDjNiAiogaym/I/BUIH1itUX0Rppboj5DsKOOhv9kvKyR2NEjJcb+8LwEKCFpaVZ+OM55iQzmTr7+voCpn9vGzfSYtjl0JBH5GFWaFYdS5IiLZIzxKWRRH/W8uMS2+Iv+xeW7s+fblXRYYEoSJqKr1cA1D88w8e+kcF+DPZ9VkRB0ijLY2RloZSyImEHHW1qEc9BtHNQ0Ri9dMCsePt7zlqduo/h55KvXdvOMAzC9hhbrqa2QxbG7OifQZ929AwV9o4yJAg2Pe2EbYy49OX418lew92WS+eQ/5DJoJRzA5DK2oZkNC8WXRIwbMEX8ByvqxZjRKWe2qht7d4xELmK2xVGxwmAZXv6DWjTWITffLtlEiRMzh+Q4+E5aiA4h5dtDNkiOjevqGHgnDWlJ2zuTw+ONkpSvVs8yRFWGZtoOUChA6EGARzpwhJL5WQvnrr9LuhgQTmP3T3m8/lOsyWFLb/Lh8svbi/fXBAY1DskCYHWjfA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(376014)(1800799024)(23010399003)(366016)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zmB+hFptLAhe6YZ8b49s5DwbX3juSDc97wYsozaCMh+3KctCsWdYn4dHTJAg?= =?us-ascii?Q?Ijivp8FoJ4l9LkachaV7lHPsGXnI3JrqkWQknNFBggMz301Pttgnu8o6OpHB?= =?us-ascii?Q?aRGp1NdbZHmi1mirh2w8oDW3EZPsLpvMfGp1sN7rszlAJUkoD23qgQF1xwKI?= =?us-ascii?Q?A/8Qv3ov36MBrhEmrSmwcFMmUJzW9jDfs4ptghJtedirF7XmJn0A6GQ2l5zv?= =?us-ascii?Q?e4Q47zV8LtRHqgx99IkNlgK5lCQR7Y5JmdoslflyKUp5UVqQoAKlkJbdi1ow?= =?us-ascii?Q?zEwR9B3QItq4VzUHyXUXygK17HczTRFuutF46aQ+c93orGnfWVnCYOhssbQI?= =?us-ascii?Q?Zpr8oC2GBWB9bZa4sh7htAZeevKOVjAePTgLlIKSoUbFy/WI6JuPTx2DFWRr?= =?us-ascii?Q?gIYxQlRfd+X/k7vy4rdIrYgagwoGFcTtWfMbUvKSl3hwvx4JQh3Pt6JW8JpA?= =?us-ascii?Q?hC2sYS0Sxg26cJWLz2ctBzyyWlt9mGudLqDywu1jQfX3qCWQ2a8bcH5MAklQ?= =?us-ascii?Q?EYwJKN3bHQ1EX8xG3VbfB+iH1nzbWisHHXKFHAxEFf6clkXAgC4OlO2T6bIt?= =?us-ascii?Q?itVE3/EKJWnd7s+15ZrvmpwgrZJ/2q728yx3XULM7ij2kWWt9/sspesKLE+y?= =?us-ascii?Q?OYGSNzwMWsd9h603yoyQllxyVyCi6+ep+REx0pg3VHB8GVLHZO1HoHFinEqO?= =?us-ascii?Q?3kpxLpzWu7HCSBP1tqilwd9V+iL2Q5JWYDxyRn6v6pMwpHrAV45kWV7Ryugb?= =?us-ascii?Q?zyU3QGMOgC46es5UjSbBjREsYpULOm9jpMP+CV2Zau7GvZvQ+VkXt+OCUNvx?= =?us-ascii?Q?wWmmoO4XeREKE7Lqjgh/25SnbjmGu4+fJC843vO5VwSjTYs2//eFkf/dRgix?= =?us-ascii?Q?kwnwxDtxVDVJ0eeAUvKopREwJoaW6trIs1mAxV2Bc0cVmDYEbswUCUaJXh61?= =?us-ascii?Q?mgsnbiNor1x0KzvTZd9k9eL9rasdzNJtAXLhDcmNPqujXzsp/XtHQNbIc3kM?= =?us-ascii?Q?bk1ACwRWORw8ZimTXI89QvIrLe7GLxOdsPPAXi3YtDhFEblgYvfceSXdTSJJ?= =?us-ascii?Q?+k5QgmW1BVcbq36FX5H/j77gGR1DWLcHk1Ftfz/8UTBAo5yLz1hPQyN8Ed6A?= =?us-ascii?Q?e41uZfZtVNAcOVRZOsoJHyauxu99bb7laLceAS7aCYbQSkrE2Sgl/8tdh10H?= =?us-ascii?Q?aITjCIO09qEM2mAgN6g3zfTAmYdgg3Z2O5SvhDC2YIdCmmN1kRVh16Oh8tok?= =?us-ascii?Q?Bn2gqUCxH9sbvwR/QLEbbUtkdLRq096SGgyM3oJkw09qKHQ9+Ondi4s1gI8s?= =?us-ascii?Q?jVVx525wNon1SMJ7DrxOU9c1gScs6cwSlD+yzILDscXkxo8nDF3DHtPr87n0?= =?us-ascii?Q?xC4Re9vm/rTXZqrgQTD92xmPHZG4qWWESP+2sMRRGXRX0Avg9co6qnx3XHyG?= =?us-ascii?Q?uUZh4KMzhoMd8cmJ6iKb2Np4SdiyqH/4lRrQVF+P778sq2U3JijD2rDFpeWS?= =?us-ascii?Q?3L1nXNDprU20bdYV4455gqqhTd+UwXUs3FiNvr3jAPjqR5gmzjdRrff9Hj7T?= =?us-ascii?Q?Uo9c1/WP2YiaLc3yTnmMKSUZe58ioZ+1OiaanAhlbUfQeRItHlLMNGN5QgmT?= =?us-ascii?Q?lQwXlgrXUYWK/QFdXUCHm/jsIAeEyAgIubPi+07bWUZlsahArxWuQNHSNNkg?= =?us-ascii?Q?3nKIHjPWRSQo76nZy9KYsiByiXrs0xDVR9m/ic+5g51vlv10UIbsQUPmsxvQ?= =?us-ascii?Q?Y1U+pEK7MtU4ouVzB9aMkTE3NE+pGIXKcIvVdSUCGo6naiXt3pcIAh0gxmpv?= X-MS-Exchange-AntiSpam-MessageData-1: 3mjy27ViL07ybQ== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 9d6feddb-1206-4942-c41f-08df0e3697ed X-MS-Exchange-CrossTenant-AuthSource: TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 05:52:55.2489 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /ffCfci9Txr6Q8qcohzlzt6CQe4JWmqvbV8lVJrYoK26JE9CnSflbihKDD+Kh4jUHmnn+E6/+M/d315itgg9Ew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY6P286MB7361 X-purgate-ID: tlsNG-ebf023/1788933187-C32CCB50-728203E1/0/0 X-purgate-type: clean X-purgate-size: 980 When the value comparison fails in atomic_cmpxchg, the code branches out without executing stxr, leaving the exclusive monitor in the exclusive state set by ldxr. Add `clrex` to the failure path to explicitly clear the exclusive monitor. Fixes: d2654a556835 ("xen: arm64: atomics") Signed-off-by: Ryoji Okamoto --- xen/arch/arm/include/asm/arm64/atomic.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/include/asm/arm64/atomic.h b/xen/arch/arm/include/asm/arm64/atomic.h index 4460165295..2c74ede740 100644 --- a/xen/arch/arm/include/asm/arm64/atomic.h +++ b/xen/arch/arm/include/asm/arm64/atomic.h @@ -118,7 +118,9 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, int new) " b.ne 2f\n" " stxr %w0, %w4, %2\n" " cbnz %w0, 1b\n" -"2:" +" b 3f\n" +"2: clrex\n" +"3:" : "=&r" (tmp), "=&r" (oldval), "+Q" (v->counter) : "Ir" (old), "r" (new) : "cc"); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 05:55:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 05:55:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412547.1642951 (Exim 4.92) (envelope-from ) id 1x4BHa-0005KD-BK; Wed, 09 Sep 2026 05:55:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412547.1642951; Wed, 09 Sep 2026 05:55: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 1x4BHa-0005K6-8h; Wed, 09 Sep 2026 05:55:42 +0000 Received: by outflank-mailman (input) for mailman id 1412547; Wed, 09 Sep 2026 05:55:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4BHZ-0005Jy-85 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 05:55:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4BHY-006PQi-7e for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 07:55:40 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0f4d7-bab6-0a2a0a5309dd-0a2a450b8f7c-20 for ; Wed, 09 Sep 2026 07:55:40 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0f4db-b7e8-0a2a450b0019-4a7de14c8207-3 for ; Wed, 09 Sep 2026 07:55:40 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843c2790ccso369548f8f.1 for ; Tue, 08 Sep 2026 22:55:40 -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-49d057f4778sm344362225e9.8.2026.09.08.22.55.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 22:55:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788933339; x=1789538139; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=fRUw5q3QNtblCskUdHcTvX5dr0LJ7DxVsCZho4EFS3Y=; b=OE/dJYFo2U/Pg34c9s4sDiZl9b8T3z3QSIkqqq6s3EytwuJ6uNX9SdA/ghWc1Z8ffp KBUaUnG3jA6qdl+26Go6R2n8iUEShYQoOb0ezaHdCC1DJu4KKPTDUOHSZAlbj2qwkU8C sD4Nn/QZU+mC74cY38OGgSsNY00QrxnlswrVsvIr6xKmRtKnH8f9vjhCk6fwYyG7hDiF VU4MzjAdMuOqu6uQgJ4uDvVKa3LLms21LjKbVVnm2VlxjTvgHxiRRytCcoNQ4Sge3LMA 5KQrpLTABnRNhcBKJ/YObkuPz8jWWgtdTEJGevIGU8vqFPmOlTIC8sDEXwE488lTgB/u IfWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788933339; x=1789538139; h=content-transfer-encoding:content-type: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:content-type; bh=fRUw5q3QNtblCskUdHcTvX5dr0LJ7DxVsCZho4EFS3Y=; b=UNiYmne5yrEC1RzsVqBCdAVLGWqh00IVhXNtCzFUPH6ebB5Z1ETnV+gnffQHpn2yDu r+3kWqoCZT829K04ViiNbSAsazj0BswTfj6mOrD7zSD0cNN5FW1BO7dX7DchIPDSoQ8F J8rxMaRUlZ//yQyh/tlKQn5iTEKHfqSU3rbtSJUzTWImP5gCvxF+idikcd6i6W60MCTq aP28ujAp4Jn+gI6ogZTp29ioPwUZkGHAhKUE49p2wWBJmXIaIc7fvy2JKuXCIWuSA05e bG8tKy9MFjaiNWjZjCo6VbVyxPAslaAvXOGZ54xSJwd/g+6T+vHiRUAbuX+vmzuWDVpR VR7A== X-Forwarded-Encrypted: i=1; AKwUvBwMxiJVH80XeaFQo/cxevZM71/uRE7oMlwbuyTs23KPt48VJycxhrrU3JyNvO8eIct3ASsb3U6rpdY=@lists.xenproject.org X-Gm-Message-State: AFuF++mrM4k+fky3TiYl3Py9dryuJSz9Rc5mv9wTL9/GVklMwga/AaoC 1D9CbDWLXo0sTJ3jezEO1hvsJE45mFiKGak2LdG2sNH/Vl4ACCS62M9Q5U55wFiLpQ== X-Gm-Gg: AYBFou0BeJysX4Zw4hbB6kKPgfg4g/Taod7AVMZ1enIaOVAi2Gfq7aFIPxzSuNzKBzj fXCzZXcXdeaR8rGeAW+wE1YjKbzfMAijaGm1TbLBEGukaagStvvwDjKSZsB9DS/AQ+e4JtDSPE+ G1tmDLCRgFWiPvY1NTI2MljyBrxHJqlDTk8SnlG87O5Ja1tPCfOOLX7Vb8W83pges+ST3jaOdJV i2VbG0Xadfqe5MIFOtQ9mzv47ywOFwiqY7ZOBkhm3+H2c5Q95caSr9oXSuZZ/VNcKajL4BAdQ+x KwXT4vASlawe6SroEkZ4wmuE2DlJ/e5yxR/7WWZcugb5d0K3Abnf+JWvYcoq90ksCVkW4/affCt 3zG5qAoA6hD5Oh9SNJe/R9t3oJg64l5EklifatSjc3NnfFe0/3Z8dRQqWwDQkn0z4o+Z6O1mO8U SWVJCc77am45jhAwJ/sxEjto9gr3G5jjoHsZsh5w1hZRZQA6EsBMDCSI+MxSHQkyQ07sW6oHQgz w42prV3NixZZidvO72rlUf34MOmSCMmhT4R9cO+J+YSwBXiIaTerS/VPLGf/nI= X-Received: by 2002:a05:600c:4f4b:b0:49c:ee20:e787 with SMTP id 5b1f17b1804b1-49d1f21afcdmr65238065e9.1.1788933339519; Tue, 08 Sep 2026 22:55:39 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 07:55:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/ucode: Work around Granite Rapids erraturm GNR98 To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260907213231.3159241-1-andrew.cooper3@citrix.com> <6a54806f-061b-4b76-b42d-6fa5b54581e4@citrix.com> <70dd9e38-bc54-4532-b310-cb9fb3d3f2ce@suse.com> <0ad272a0-8afa-40fd-a7cd-fc953e1b992f@citrix.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: <0ad272a0-8afa-40fd-a7cd-fc953e1b992f@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1788933340-AB6D29EA-3260CFFE/0/0 X-purgate-type: clean X-purgate-size: 3570 On 08.09.2026 19:10, Andrew Cooper wrote: > On 08/09/2026 11:55 am, Jan Beulich wrote: >> On 08.09.2026 12:08, Andrew Cooper wrote: >>> On 08/09/2026 7:26 am, Jan Beulich wrote: >>>> On 07.09.2026 23:32, Andrew Cooper wrote: >>>>> @@ -273,6 +274,44 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) >>>>> return false; >>>>> } >>>>> >>>>> +static bool microcode_safe_to_load(const struct microcode_patch *mc) >>>>> +{ >>>>> + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); >>>>> + >>>>> + /* >>>>> + * Treat pre-production as always safe - anyone using pre-production >>>>> + * microcode knows what they are doing, and can keep any resulting pieces. >>>>> + */ >>>>> + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) >>>>> + return true; >>>>> + >>>>> + /* >>>>> + * GNR98 states that Granite Rapids systems hang when loading new ucode on >>>>> + * sufficiently old firmware. GNR101 retroactively declares that one >>>>> + * ucode had incorrect min_rev fields, in light of discovering GNR98. >>>> We still have no min_rev field, so imo a reference to it wants some >>>> clarification. >>> No, I don't think so.  The fact Xen has no min_rev field (yet) has no >>> baring on the wording of GNR101. >> The wording there is "Minimum Runtime Microcode Update Revision". As long >> as we don't have a field of the name, how can such a comment be unambiguous? > > Fine, I'll say "minimum revision field", but the whole name is (and > always has been) silly. > >> >>>>> + * Both are incomplete statements of the problem. >>>>> + * >>>>> + * At the time of writing (August 2026), the believed safe sequence is: >>>>> + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later >>>>> + * >>>>> + * Disallow known-unsafe loads while permitting believed-safe loads. For >>>>> + * GNR, this allows multi-hop loading to get up to the latest. >>>>> + */ >>>>> + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && >>>>> + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && >>>>> + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || >>>> This is odd: The lhs of && uses the lower bound of the inner permitted >>>> range, while the rhs of the && doesn't use the upper one. If it's intended >>>> that way, I think this also needs clarifying in the comment. Otherwise imo >>>> lhs and rhs better would be consistent in this regard. >>> It is intentional.  Furthermore, it is the only coherent way of >>> expressing the sequence as given. >>> >>> I'm not writing a comment explaining why it's a good idea to use the >>> same boundary numerals between the comment and the code.  It goes >>> without saying. >> But that's the problem - code and comment are not (obviously) in sync. >> >>> I'm also not interested about pureness concerns about inner vs outer >>> bounds.  I can't see a change here that won't make it worse. >> So why are >> >> ((cpu_sig->rev <= 0x01000370 && mc->rev >= 0x01000405) || >> >> and >> >> ((cpu_sig->rev < 0x01000380 && mc->rev > 0x010003f3) || >> >> both worse? > > Because they are both buggy.  They fail to exclude some unsafe cases. > > If it's not obvious, I do know more than I can say publicly. Which I had in mind as a possible option. Problem being that with incomplete information it's of questionable value to offer an ack on such changes. Here you go: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 06:13:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 06:13:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412560.1642960 (Exim 4.92) (envelope-from ) id 1x4BYP-0000IP-Q3; Wed, 09 Sep 2026 06:13:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412560.1642960; Wed, 09 Sep 2026 06:13:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4BYP-0000II-NS; Wed, 09 Sep 2026 06:13:05 +0000 Received: by outflank-mailman (input) for mailman id 1412560; Wed, 09 Sep 2026 06:13:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4BYN-0000IC-4e for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 06:13:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4BYL-00C7d5-Se for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:13:01 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0f8e7-2eae-0a2a0a5409dd-0a2a450ce6d0-24 for ; Wed, 09 Sep 2026 08:13:01 +0200 Received: from [52.101.228.107] (helo=OS0P286CU011.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0f8ea-f479-0a2a450c0019-3465e46be3f4-3 for ; Wed, 09 Sep 2026 08:13:00 +0200 Received: from TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:af::12) by OSZP286MB1909.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:1b0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Wed, 9 Sep 2026 06:12:56 +0000 Received: from TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM ([fe80::2067:ff0e:4c3:ad0b]) by TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM ([fe80::2067:ff0e:4c3:ad0b%5]) with mapi id 15.21.0360.008; Wed, 9 Sep 2026 06:12:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=x0Z2Zx7HDVWz2nOy00xZMSVWJ0v+ENpl/RYPM2LDAdcLa8Qxzyb12PXT/tLOxlgkQaSjotKl/6dn1DprR6qh+ZBrAYZ6RCX3Y4MMqNgAFu79fzwwwI7q/9ET0kvlL6rgOcSL1lPcF3yg6zyPLVY41cRigwe7/QjijkCt4Cw2xzRTVs0M1teyC102yDCtd3tf0m3TCrUvi541EU7vLS5RpjWJ/+08OO2sjgXauxve5LX9MOfdoMIzhF4yKuqSptAeUSVqHd8pNDsopGH4fQQTmbMHFzfOZwgXaPQRzvgH29WeaPMEucwP1MAW3pfzlPWYTjde+G9fVoL5cs2jVl7sRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6TPhRfSzE8LUkpcYp2RbKf88gop1wKnKgJwVM7D/+XY=; b=HUhPU2pcuXc6tua4n/ET1zge/QzRGekm8FEXKYuEJnbVmIvm8hmbmb5nGVb+Q1lmqM15YyFqqUtsbKMy5fZEUBTQpM2LrLPLVdUk1jnq33wPJX9+k90Gsfuq1QFO/ymksVJGrain2Z4abdnwh6bcF1Y4SPteQYOZVoVeo6JOW1lZ54viNv/1GW25Nkw5aJX4ZJRIUY2LHI8n4fLdaURGgmd0jVlnHqzGTYOz5LBzPgWwl6pKy96NB92tEHOKdozBpqiLFzvhR2Ar7mG0MZqPcuUcOUlcNiu3JXvFGafkdzNEqGl1VJe7Nf3lPnvAjeqygmJyG82MS2ubSa/RFC4XFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6TPhRfSzE8LUkpcYp2RbKf88gop1wKnKgJwVM7D/+XY=; b=KoZbN4iEBCOWQsnkrfpnfWn0PeLVUAoCP8gOHIwNXvJu5bSGktebiT38nzJIAqxgKt69fDbi6f2jhHUkmIZZrNS5ekrxO6mdnYpUld/a4hBe5iKD1lIYdbPLJRznwvNrEf2gpYWvOOnjlXvcBKPCTpapi8hF6og+grW0tD1UsI4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Ryoji Okamoto To: xen-devel@lists.xenproject.org Cc: Hirokazu Takahashi , Ryoji Okamoto , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v2] xen/arm64/atomic: Clear exclusive monitor on cmpxchg failure Date: Wed, 9 Sep 2026 15:12:53 +0900 Message-ID: <20260909061253.546312-1-okamoto@valinux.co.jp> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP286CA0063.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:31a::12) To TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:af::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TYCP286MB1053:EE_|OSZP286MB1909:EE_ X-MS-Office365-Filtering-Correlation-Id: d99d0b94-3152-4fa0-2777-08df0e3963a7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|376014|1800799024|23010399003|366016|10067099003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: fLWkHiYC62e0jPjNXnZGnObD+Q7G57gcJWrxb4iHBE3fl2on0I+bZQD0n5y3XDk0LK1hONeO8x5g3IF9A+Xx7LFCDC8cI0uy8IyHHy6uuuL7IwDDHxOXMQU908hQrSRsHNewrb/6z6+UTrR7GQQodTz23mgef352grOLEr8kUUqvMlaStSWJyH8KwLF4ROgxL7NvqHNDJTIEkmzBorRbcyGAPmPYqchj4X2/wfewx7dMilJ1+yhVtoMmDnxvu+Qwb35xzgQTEnImjYwTD22qOs1kOSciyjrUKhx9hAVQvOylfr0JWxQMYBqZAwumiXwvQXWuBsHNBPJtZ+YdUhzvv8usvPxTwT3eYtrVZl1+O5wzSbVd56NYil3fvinWGxM/h4amFKwYKEqQfdr1OL/CYvOM94SIg2Fwc1CICIPaeMW2sxPwxjZGLfnRh50WHaNmQoYVgO59jKdycQAcvUfAUOQ9wPoevm/BEhRpX/eLgo8qfDSHp6eqwvQTJKD90CFZ5njd4/nnehLObJAou8T9TU9TVvCF1ib8yTDi21NIyX9Q3vpT1ckG7gMHfbiqjE0YlWkxVh4U5I1idhisLJnQJSnKJB6hGcMv453MvCQEl3I6fptbwxVELlOhWhdZcfVMHURPJ3UChKhHwocBeUp9JNuL0v5SVhjZi0LBtDFxsZk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(376014)(1800799024)(23010399003)(366016)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KkKHGGhPyHf0YP7zaa5ECuUUOfWOMzheLMmjKYSzgivcFXcnQYHQWRj54yVH?= =?us-ascii?Q?+LkvND81Rn9XhOBDhtdlRIau/EEHSPfiBdbNYZ9/2QuU6O64SydpQh9n1aQM?= =?us-ascii?Q?5tOjeJP2pw8IXMTNGdtBakrJXpoOcT4SbF49vwgKPevd6tQkf5h3Qr9haY63?= =?us-ascii?Q?oOr2FSukB7Z04RJI37WEkakRkL/f03CUg4P/AYB+zZY99k30woqRBFxK2DSW?= =?us-ascii?Q?u6cn2PX4J4MqB5PCkrlj9ryAX9lbSzlw7WFoRYtsTlnY5iP+2nifxmOv2dov?= =?us-ascii?Q?9pRvEv1hXuBvITPAuqDwv4MqeP2dmM+K+TlBqjFlDDbiFUA+Ph31zkRXHEij?= =?us-ascii?Q?vwR9e0vc/MOsNYQZs9TyLBZOxiksbqEZhZsBEJpGPDjuqmkYdXy1Ttwbws/S?= =?us-ascii?Q?z+iiFlchV0guChNrLHi5xVw8rfTv36XlugemhrXIYobSqlU4NewsoWC5+6+F?= =?us-ascii?Q?SUAaaNmEhqc6rO+rfbPv4OoredzrWCbfFqhMaqGlHyG7+04U6z5RTV0TzqIu?= =?us-ascii?Q?mmtU+Hl2OnUpsmrTGwMFFQ+rGHV58Xd8cNhBqZ2Y0zo3UwI/FBrJ3YOWsrWx?= =?us-ascii?Q?ponQYTEMkg8vFEbPQzNDpYrTM96mQUe5/ozfOywAkCIvQDZ8w7u7QpiwteHw?= =?us-ascii?Q?2lCR3Lh5bllFj5s4ogO/Ddod+hxmQBg0tzjfRpA8E+lKt5qVdgjIPL4kI4w+?= =?us-ascii?Q?F6rUpC7RuQZGm9siVyOPo6ZfZVHDr3yf5FdgR3PX+3MDxI67MEI/YA9um+1R?= =?us-ascii?Q?X2aoU4VUyJjc2/McFZIVIbbEX+wqEGK9tl3LYOJrRGDBO3FNpMVYP2aHtftw?= =?us-ascii?Q?TGovKH/M1a65i3ABM4zwMS01Q+5zmIh8qJYwKlB0ksO9Co41/tmsSHZgsGzp?= =?us-ascii?Q?cFC4ih0NX9E6zDgmqX1zjy+JIN/shw+HRVVSvg/ROPnS5b4XaTTclbYiaHtM?= =?us-ascii?Q?2XgMwhDwkNz/aNvpX+y6Z7V1DGGEViUrvzycfOzcyfmmGTV9Amc69ETlyUUx?= =?us-ascii?Q?56S77OsryOHsd4XSPWCxv2lQ+A84mUNeNuWxUgJ6TpN9ytFOqTqOAI/Xo+mn?= =?us-ascii?Q?U7tJnAtqX3soM+6JFGvt2E9ERkzPgqPkyzPUuhZ6ope5Rp/9LY+zCVm9r0nS?= =?us-ascii?Q?OL8l8OYlao0QtnZmG1IJ7xiFUSYYrAtQsGx+ZkyTJl3kRlK6Z0+4fmcPLQWr?= =?us-ascii?Q?c8r9gTgYniZhvkEJ4k+eN0pkcoCaxF0M0DV8V3Lrc2umVck16unH5rBMvUB3?= =?us-ascii?Q?jZ1Y/JwdyHXp1Y2xwwo1ilGe/CFT4HskjVxT1p8LBEq8BxuhqMBpz5Tnyu5p?= =?us-ascii?Q?iN64xuOe0lbF8Ow6dFNEzQ9AmgJthkgavzIeiFlF5ylCY3Vp1fRsM3RbFlxb?= =?us-ascii?Q?E7zUtcVzy56oxeRBpkTmO3+ZB+baEIJvdI0KcTNci2lRDh9DllKG326rDq1/?= =?us-ascii?Q?Iq5dR311uU+vakKUCLX01H1uE/YTp2jHdAE1RicboRGklEtHPchYbZjw5hJS?= =?us-ascii?Q?IxliDDy/UHUYTRRvNejAde8SZo/DkRDq8aZFoVO1mgNbJ2UXTfv7Lj/zJafI?= =?us-ascii?Q?2B6woKhZ153Th0VjjyMFg/BlSiXkjwslkYGkfQdZ2+QUaXmXw5UxfuTOntfU?= =?us-ascii?Q?ixLVCVNwwICBU7/tzv6YFl3yFWai09qRqQ5BwqDiDXqSjpLQH2cUQorv3FYV?= =?us-ascii?Q?Bw9lJTVQOiTdcrWe3WY4aw4zhHVS7/x2Wwkui/Z+2u1thyAXcKdQIVLN2uIu?= =?us-ascii?Q?yd6+8MfJOqe6/fEB0/qW82kW4CG7hU4NxzQndnSmwTlFWRjZRsM5uX2gUdYc?= X-MS-Exchange-AntiSpam-MessageData-1: A1EJw6W3v1pLwQ== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: d99d0b94-3152-4fa0-2777-08df0e3963a7 X-MS-Exchange-CrossTenant-AuthSource: TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 06:12:55.9908 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 3fbWXz6k4/nbdgXtB+hqY/GlHaruV9P/44sgiYkULli06GO/jZzB+s2Z0xY2MB6CEoldlV4gIVxoFBDpkhvEQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSZP286MB1909 X-purgate-ID: tlsNG-d25034/1788934381-034D7A5B-D21BAE60/0/0 X-purgate-type: clean X-purgate-size: 1022 When the value comparison fails in atomic_cmpxchg, the code branches out without executing stxr, leaving the exclusive monitor in the exclusive state set by ldxr. Add `clrex` to the failure path to explicitly clear the exclusive monitor. Fixes: d2654a556835 ("xen: arm64: atomics") Signed-off-by: Ryoji Okamoto --- v2: Use tabs for indentation instead of spaces xen/arch/arm/include/asm/arm64/atomic.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/include/asm/arm64/atomic.h b/xen/arch/arm/include/asm/arm64/atomic.h index 4460165295..3aa0ffb4d9 100644 --- a/xen/arch/arm/include/asm/arm64/atomic.h +++ b/xen/arch/arm/include/asm/arm64/atomic.h @@ -118,7 +118,9 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, int new) " b.ne 2f\n" " stxr %w0, %w4, %2\n" " cbnz %w0, 1b\n" -"2:" +" b 3f\n" +"2: clrex\n" +"3:" : "=&r" (tmp), "=&r" (oldval), "+Q" (v->counter) : "Ir" (old), "r" (new) : "cc"); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 06:30:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 06:30:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412577.1642969 (Exim 4.92) (envelope-from ) id 1x4Boo-0002NL-3V; Wed, 09 Sep 2026 06:30:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412577.1642969; Wed, 09 Sep 2026 06:30:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Boo-0002Mj-0f; Wed, 09 Sep 2026 06:30:02 +0000 Received: by outflank-mailman (input) for mailman id 1412577; Wed, 09 Sep 2026 06:30:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Bom-0002JK-Cd for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 06:30:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Boj-00FaBO-Uf for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:29:57 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0fce2-e002-0a2a0a5209dd-0a2a45089b18-20 for ; Wed, 09 Sep 2026 08:29:57 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0fce5-f659-0a2a45080019-d1558030d806-3 for ; Wed, 09 Sep 2026 08:29:57 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49b0d78a801so53948895e9.2 for ; Tue, 08 Sep 2026 23:29:57 -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-49cfbdacc45sm419611795e9.11.2026.09.08.23.29.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 23:29:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788935397; x=1789540197; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=zNNrwzlgwXbpRUEBSY7hJJvBKiZ4KZJRYme6JSu7CMA=; b=Zrtc79TgIAO8G6a6PHhdnf1YkHS/tJ9eC+4We8gn4Ls0PJLacW300IxJaKxvmmXRKB Q/CFGH47AI2hFrKWA4moHTG6Xmkt1TDmfAcagw/a/LVGmVSEUcaB6Ts8Nc1gIfZeV40W u74muZiyDxIpHsahHt/4r3o+H/ssv/CRiTyarbX85dXDEQ/JWNkqcSoHQZK0Mo3wNSDd PugNBrdv4Uyg9PW//gLznswgjsThNkIFc/vQcFnzsRuaKB4KJwvOKJuu8QURGMzoJE9p FavOMKaCMj2ZQGbSzC6ZwiT6C71KoNZS6+1OoiWpcRPW6wj6jYYzasFbl2vScpmGppse S2AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788935397; x=1789540197; h=content-transfer-encoding:content-type: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:content-type; bh=zNNrwzlgwXbpRUEBSY7hJJvBKiZ4KZJRYme6JSu7CMA=; b=ZsX5FKpFlBjGFeklRj9026uoBjzeY/vEpjHwSoAsmn4446JYaLtR9GLYm5FhV2uB1d oM1BnDDj9UTIL73sl616UWWZe8j0J1N9//rzCyS8B3gEo6ABO6tDofZjIkonU1IpPTa2 cRuMO5rs1aUajnLrXqORazac1ZtPQ0PSzZsXTIFlqCoMo2Ow+5tzr1sfHhy1z2agk0ES uekoqqT9FgPGG/LI2MhgtX3vd2tHSDQbqcOBtX4WYlUVHZqqtcYturPVFo312U9pJblA dltn4L1+403tpd/KWnYwmLOjQFuAhfp8Iljli8JPVBL/P8jMde337VMMPkuluK1NsoCr KGcg== X-Forwarded-Encrypted: i=1; AKwUvBx/pooyB6IMZs4sl/5VzbyCUETVWZflz+gtCcLogs42R/1eT+Kj5oH/QSkU9eEZpR7L4THUU3W0HXs=@lists.xenproject.org X-Gm-Message-State: AFuF++ksJy7Fvj0YCkc7Ooc9Y1bZ70Im5vwyzWCp78wcUtzhyoqQCjH/ ZXyXWuC9Gb+DFe9XrX9oUsk9JzJ8lJMCq65NwRHOrMj55rwyXBgKOBfJiBdvX1bKbA== X-Gm-Gg: AYBFou2sOh1SPOEzW5HZ3E8aiV4Nuk7kmF/9dvmkEkRfVAMLYrza/0pVzlyEm8ZJzFc LCWjeaohd613BhdVC9BE9UY8WMKVa9cFiQPH1ckuF72bQItUXmeE4nOAH2WcWaxfv8kAMMUDEcn v7YYSr1esFUbLysJOcyIq6lP/8Q8U3WZpi78dzOolEM678IzEJlQ7qzi5ALuG1+YGjMFcszeK42 33EnxBnQX3W64OU31xV1iH179Oshq65d6bSwcq4QzrM4vRRbXqG0cNX0G1k9xjuC0LUwoXLxXQH ofrep08tq0wAeZ149Ku4/TYi+ATJObs/BidlgvOFEMl96uGmlmo17vSEsGcj5KB9p2cXdwNV5EB Aci97uM+ZUjsbbQsleHsQdRP/V3p4tk39uM+cFd+9xwb9STMtFxfTgDu3ttSVVa3wUvmmE2OSG4 re5nJvLSb8NTMAx7QGAdaceI3r3f2trsX6oT2WSgPbCo6cpFS3p2rcGzGzecphzSGUz9BjsX7w3 N0zKMpk18ZlcLXIYDxmJn8jms3DovDTKyzA4kfrsfj0olxXsyHb9ijZb73cWc3t+L4nc1guZA== X-Received: by 2002:a05:600d:4449:20b0:49d:3a:e576 with SMTP id 5b1f17b1804b1-49d003ae639mr195365485e9.5.1788935397190; Tue, 08 Sep 2026 23:29:57 -0700 (PDT) Message-ID: <1aacf944-6de7-4f81-9ee1-0c0b266c5f2c@suse.com> Date: Wed, 9 Sep 2026 08:29:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm64/atomic: Clear exclusive monitor on cmpxchg failure To: Ryoji Okamoto Cc: Hirokazu Takahashi , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260909055238.521966-1-okamoto@valinux.co.jp> 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: <20260909055238.521966-1-okamoto@valinux.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788935397-DF8D587B-3C24E9D0/0/0 X-purgate-type: clean X-purgate-size: 1014 On 09.09.2026 07:52, Ryoji Okamoto wrote: > When the value comparison fails in atomic_cmpxchg, the code branches > out without executing stxr, leaving the exclusive monitor in the > exclusive state set by ldxr. > > Add `clrex` to the failure path to explicitly clear the exclusive > monitor. > > Fixes: d2654a556835 ("xen: arm64: atomics") > Signed-off-by: Ryoji Okamoto Reviewed-by: Jan Beulich with ... > --- a/xen/arch/arm/include/asm/arm64/atomic.h > +++ b/xen/arch/arm/include/asm/arm64/atomic.h > @@ -118,7 +118,9 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, int new) > " b.ne 2f\n" > " stxr %w0, %w4, %2\n" > " cbnz %w0, 1b\n" > -"2:" > +" b 3f\n" > +"2: clrex\n" > +"3:" ... padding changed to match that of surrounding code (hard tabs). I have to admit though that I'm uncertain of the usefulness of the new B that you insert. If CLREX is cheap enough, avoiding the extra branch may be better. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 06:31:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 06:31:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412585.1642979 (Exim 4.92) (envelope-from ) id 1x4Bpp-0003jm-BC; Wed, 09 Sep 2026 06:31:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412585.1642979; Wed, 09 Sep 2026 06:31:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Bpp-0003jf-8Z; Wed, 09 Sep 2026 06:31:05 +0000 Received: by outflank-mailman (input) for mailman id 1412585; Wed, 09 Sep 2026 06:31:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Bpn-0003jT-L7 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 06:31:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Bpn-00DpRo-1O for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:31:03 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0fd1e-e002-0a2a0a5209dd-0a2a450aaad6-46 for ; Wed, 09 Sep 2026 08:31:03 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0fd26-f2d2-0a2a450a0019-d155802eb80e-3 for ; Wed, 09 Sep 2026 08:31:02 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49cdc81f40eso39466175e9.2 for ; Tue, 08 Sep 2026 23:31:02 -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-49cf75cd8d0sm420729005e9.2.2026.09.08.23.31.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 23:31:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788935462; x=1789540262; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=ykPP613s+lqKQzctAfcNpcJC3T9ELT93c67MZ4nXxVs=; b=H8mTad37cyrNmbI5QfTsrllgunHw5sxeWNBUVg6BNrrk7/jXsqejmakFjr2H46ey45 NY9YGBNVnYH3rDADblWHh1HBC+U5u5GLYRI2cgLKNs4ta1voZRRIM1GYC2JNbx490qCt 7U04ShW+Vve6u12Zx6Y8mAbbUhVJiaExT5ml6n4UhDbFnqlC1NRTeryMmLg0gF8Z9I1T FTBzFlOyurw+oFo2+LTd6uZRtTJh/8hfkwus2gXgfpm2+yZCyr4M79OclIjCEqxxEESm lNwEs1IJcL9reQ62HudXlLfRia10pubjKrC4d84MWTHojzJq2CX/DiE5yOe+T5eGMq/N S1Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788935462; x=1789540262; h=content-transfer-encoding:content-type: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:content-type; bh=ykPP613s+lqKQzctAfcNpcJC3T9ELT93c67MZ4nXxVs=; b=f31by+uvwTwDRMvVMH9RI6YLSitfHE0OGXEcFb+P1+tMhK2cIR53Z4wDqbiuRjxnmJ WxiIpxBo47YSp6xH3C86dqDhjmkWaBU4WJq5jjcLaAEjlYn3oqD4g0NsNT/v3NKnZ3xS +9A2DzbkRQoPSW9Uuqet+l5xLmIoUio/viQoEpElhj/nFuSzUWBxts+pMzDsjrIHA6MU wTOEYdFdHVIyqfMAdKC+2aZL2STGgMMZVf6pslf0vT9ZeoPVlCDmlhNQV36PDJxQpu3H 16aOnyLowaKV9qIcllkk3sghLN45Zn3yX0kvuAcLS+jyIcuPhOVPZb3NpHZXIDhbGi16 hUqw== X-Forwarded-Encrypted: i=1; AKwUvBz2sc5KAwkYwJ65eODQlmC666rhFmphLw1vWzz6qQ6GufA9kcwxtfT4e6/MezeMVrNZMk5H8JR6bYE=@lists.xenproject.org X-Gm-Message-State: AFuF++k8q42C3bq/qmTNJbioWYho8x9rfiECtQgKrLWdbFsF3zUe5CHo aRY+IkEgxwopgHJtTIP7Oum9LGpNqdcNZoVL2Z5XlbJSvGt7bxE+DXzKDBwojrzp3g== X-Gm-Gg: AYBFou3i+BMH0gqpdcVY8I8R7KSdd+ApxP7zvFugyEYjCzjHYQPIgjkIfRahVzkYNQK jBmrhDMOAZhHrWnsxlHaEShJy/txsWMroh4rec+9PUAqFHS399Qo8aulm8Xg04+9lVacJI07yR7 wbUn2FSX+2ry8Uo7LHoi7buxQwoe+dJaDpWZUQeiI/IEAyJ8WUHeY9IZxTFb6YgGxhtaQAsXEUP ZidaTXNk6JIbYt4JVUyJiLB+w6LoR/eWNsoFiONlSDLlLqhMrX5t1XqyG5sjr2sddRCr9fLuzIj QOHwuoZ9R0iczdWhreho9EmZVwb9giGqQLDtbipzhOutGnHbqz2TP2/YLFMP+/P8qSPQf/1Mp/V p4ipRc/DLTjHUwzB+n714aNhs58jVJNsjm6/bb6ujPKjQj9RAeNfwmibxVz98Qokz57gBjwD5CG j9+QZgviby1h/cHY0xeGdt3U9kC5o8uBBI122LD3ydIUt1yVUNe/+LeooX1TXeIo5/MAmFiqzom uRapDqY/5RIKRjPI55X59ZdGQZeYGMSCiXDC5DDZpz635fStjrvEfo/ndEqNAQ= X-Received: by 2002:a05:600c:3b01:b0:49b:4d64:bbc4 with SMTP id 5b1f17b1804b1-49cf81f1592mr579905035e9.8.1788935462274; Tue, 08 Sep 2026 23:31:02 -0700 (PDT) Message-ID: <60532fdb-616d-4a25-8c7f-fd5cdc558787@suse.com> Date: Wed, 9 Sep 2026 08:31:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/arm64/atomic: Clear exclusive monitor on cmpxchg failure To: Ryoji Okamoto Cc: Hirokazu Takahashi , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260909061253.546312-1-okamoto@valinux.co.jp> 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: <20260909061253.546312-1-okamoto@valinux.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788935462-53CD3CFC-C8438E25/0/0 X-purgate-type: clean X-purgate-size: 834 On 09.09.2026 08:12, Ryoji Okamoto wrote: > When the value comparison fails in atomic_cmpxchg, the code branches > out without executing stxr, leaving the exclusive monitor in the > exclusive state set by ldxr. > > Add `clrex` to the failure path to explicitly clear the exclusive > monitor. > > Fixes: d2654a556835 ("xen: arm64: atomics") > Signed-off-by: Ryoji Okamoto > --- > v2: Use tabs for indentation instead of spaces Well, ... > --- a/xen/arch/arm/include/asm/arm64/atomic.h > +++ b/xen/arch/arm/include/asm/arm64/atomic.h > @@ -118,7 +118,9 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, int new) > " b.ne 2f\n" > " stxr %w0, %w4, %2\n" > " cbnz %w0, 1b\n" > -"2:" > +" b 3f\n" ... you now do here, but ... > +"2: clrex\n" ... still not here. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 06:40:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 06:40:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412593.1642987 (Exim 4.92) (envelope-from ) id 1x4ByQ-0004WF-48; Wed, 09 Sep 2026 06:39:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412593.1642987; Wed, 09 Sep 2026 06:39:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ByQ-0004W8-13; Wed, 09 Sep 2026 06:39:58 +0000 Received: by outflank-mailman (input) for mailman id 1412593; Wed, 09 Sep 2026 06:39:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ByP-0004W2-8N for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 06:39:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4ByO-00BBNE-Hk for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:39:56 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa0ff2f-e002-0a2a0a5209dd-0a2a450bb530-14 for ; Wed, 09 Sep 2026 08:39:56 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa0ff3c-b7e8-0a2a450b0019-4a7de14caf11-3 for ; Wed, 09 Sep 2026 08:39:56 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356256so807711f8f.1 for ; Tue, 08 Sep 2026 23:39:56 -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-49cee7fec25sm625008065e9.13.2026.09.08.23.39.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Sep 2026 23:39:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788935996; x=1789540796; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=pk0Y7Ri/0c66D0rPaxC/+e1fmcCnGHtLIj5KUnOiFQ0=; b=DV6g3HqGoWxwbaMmwOUYqoVKbhQanr1oE2ITocaYq8hH7vXHelqk5nxTGFz/cNutyx u72N/sAfPFp6lgld9xdFiyLC0pzqCTtCv6lw5Deb1qqP2VK1XJRO4T6cWB8l8NSIwdJ6 ugX+IeS2Lht+UqIVbM9F1KtKf8Nk5GJqhH3L5Cv6YNdMs/kTp66MFFjIAtZcQe22KqQA 6Omp3vNWyidBGy5SZO94sBGi1hhTXya1M1XWIcioAgbmlFC6zeGgt1UAVQ3hOvMmz4zA hs6AKGmAuqKnM7ay8LjAH4ejtgc04Cd21pIP0jB3Quddkd3Aj8HgCV9gszSKKrefe3d+ xIqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788935996; x=1789540796; h=content-transfer-encoding:content-type: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:content-type; bh=pk0Y7Ri/0c66D0rPaxC/+e1fmcCnGHtLIj5KUnOiFQ0=; b=GMU2klYZ0OEfeoMIjoVJ5JLiZln/rGq6/CoZBTiL71olC3L1OOzoBq03qYIYaiQ9ho 7lAk9HBNpedek4DelxZKSYJTk06zokTjlB26fCMkBt00BYdoLo8O4WVseJWW1FmosRrH W71auXBk6xKOoYNnmBV+EWzmv692YBOifu25Ma+DYM5xqpyvQaaBvoo3QBRzCKZqQkbZ xbkLUm85vDQcbmzx4dBwInWfgd1diIi+PW5oulftrGzVqdi0iB1+TG/99q5gRSIC8o1S gcHOcjSkEMR/MFnK+hX1FvHvBNkLi9qRqXkF5J8oyMly991YhokiLy6KRn8lhCPJZqvz T9qg== X-Forwarded-Encrypted: i=1; AKwUvBwpvoxtAb1Jsu5iNE9SPvHrvXnVXuJvUZ5DuP6Od0qTW1/4Jl6P/mQfjReqEio7obrSUHbjAl9TQmE=@lists.xenproject.org X-Gm-Message-State: AFuF++kvWPjZt65X+68JkjUty3tX66mIkgcKn4ZGMc592ZwySPMEvQxM +pDzQ0zaaCVPHcZ38E17vc/AC1mGJSRwhrUgpn8/fu/sxY6chSG/6YS3aiDHAXiMGgua2k7yWZ3 crTRQsg== X-Gm-Gg: AYBFou2tAN4knIxAHPHhLl7OL5BsHabtfpH6z+CwlDHYfm5YWWK3QImz1R0rReV0XA0 flNvWAWaBay3QObgRxC+4dRMHLxsV9eMaGXvU/i3jXl/Um1hG+2uF59UoMiU5b+eEhKO45NcLsW j1dwKDhGzlyX1gBv/uuaUQE/K4Zgo3SDF+gopgFSkw8xRXvEi27HTomYLYrlHrCmmiHYtzfvpTv zkdEn0LsBy9Y3CWmqqLDzWFmHmWxd6+N7C3a2qDc4iDdddoqKeGOqBhEmaU7DtlYNDbfiA+kw+8 QQoapJ6EPIIHf1y246fiQRwFvVsK1g6nGAF8sEn6ZR3MTw86pBU0r3NhwNq9GlkPJDW7614l7rq H94XhVCSoXXpuoXvBjk8D6mOlggLH8thoPUYvQD4qBvBVzdy2KD6iBV+U7hbd/d9J1H0nLqfDuX M4QSRjiM+2bOt7+5wAX9bMKyfQxmo9KjxXUTW1J0LOWFSgtFeLcL1mqX1RmivKRxMzd2fNoeH4D zuzf0spHtsvZvel/8uRJAbsMKqdywOlglcgb3kgnUACYqzy5CvqKAJzb9pIjzGV X-Received: by 2002:a05:600c:8b12:b0:49c:f13e:e4d with SMTP id 5b1f17b1804b1-49d17572958mr113105835e9.10.1788935995876; Tue, 08 Sep 2026 23:39:55 -0700 (PDT) Message-ID: <891c139a-d6b3-4293-8eb5-7c0af82fd80c@suse.com> Date: Wed, 9 Sep 2026 08:39:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] x86: Fixes for not-quite-XSA in pci_conf_write_intercept() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260908215721.3346842-1-andrew.cooper3@citrix.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: <20260908215721.3346842-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788935996-ABCD79EA-0A3D56B8/0/0 X-purgate-type: clean X-purgate-size: 438 On 08.09.2026 23:57, Andrew Cooper wrote: > Plumb pci_sbdf_t up and down the callchain to simplify parameter passing and > make it harder to forget the segment. > > Andrew Cooper (3): > x86/pv: Convert struct mmio_ro_emulate_ctxt to use pci_sbdf_t > x86/pci: Convert pci_mmcfg_{read,write}() to use pci_sbdf_t > x86/pci: Update pci_conf_write_intercept() to use pci_sbdf_t Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Sep 09 07:10:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 07:10:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412604.1642998 (Exim 4.92) (envelope-from ) id 1x4CSA-000225-GC; Wed, 09 Sep 2026 07:10:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412604.1642998; Wed, 09 Sep 2026 07:10: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 1x4CSA-00021y-CW; Wed, 09 Sep 2026 07:10:42 +0000 Received: by outflank-mailman (input) for mailman id 1412604; Wed, 09 Sep 2026 07:10:41 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4CS9-00021s-Qn for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 07:10:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4CS8-006KcO-1K; Wed, 09 Sep 2026 07:10:40 +0000 Received: from [2a02:8012:3a1:0:111e:e427:1551:134] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1x4CS9-006Qxe-06; Wed, 09 Sep 2026 07:10:40 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=79YGx68BM0QGfMeF3+qw2QlvE/vUpsEo3n5u+HdzZOM=; b=06XibakQADxRmKc77/Msef9sAO BLRStR3Uth4MNXAuDPfl08+Nzx0FxA3wKo737cCeYmwaHKALss35+Ud3VMvbNdUp720mZM5WMjLNy Op7TgRqArRdVrtM7dovCiDGEQRPWI+eT1MLkZnaBgy6TDpjONgGgipuwZeBNEvLfVOJU=; Message-ID: Date: Wed, 9 Sep 2026 08:10:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/arm64/atomic: Clear exclusive monitor on cmpxchg failure To: Ryoji Okamoto , xen-devel@lists.xenproject.org Cc: Hirokazu Takahashi , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260909061253.546312-1-okamoto@valinux.co.jp> Content-Language: en-GB From: Julien Grall In-Reply-To: <20260909061253.546312-1-okamoto@valinux.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ryoji, On 09/09/2026 08:12, Ryoji Okamoto wrote: > When the value comparison fails in atomic_cmpxchg, the code branches > out without executing stxr, leaving the exclusive monitor in the > exclusive state set by ldxr. > > Add `clrex` to the failure path to explicitly clear the exclusive > monitor. The Xen atomics operations were originally taken from Linux. Looking at the implementation there, I don't see a clrex on the failure path. Do you have more details why we would want it? Also, if this is necessary on arm64, then we most likely we want the same for the arm32 implementation (including __atomic_add_unless()). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Sep 09 07:16:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 07:16:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412613.1643005 (Exim 4.92) (envelope-from ) id 1x4CY7-0002Zv-2M; Wed, 09 Sep 2026 07:16:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412613.1643005; Wed, 09 Sep 2026 07:16:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4CY6-0002Zo-Vf; Wed, 09 Sep 2026 07:16:50 +0000 Received: by outflank-mailman (input) for mailman id 1412613; Wed, 09 Sep 2026 07:16:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4CY5-0002Zi-OZ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 07:16:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4CY4-006QqJ-VZ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 09:16:48 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa107d5-bab6-0a2a0a5309dd-0a2a4505ee44-20 for ; Wed, 09 Sep 2026 09:16:48 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa107e0-4cb1-0a2a45050019-d155dd32d935-3 for ; Wed, 09 Sep 2026 09:16:48 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-485850cf499so3697424f8f.3 for ; Wed, 09 Sep 2026 00:16:48 -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 ffacd0b85a97d-485885bfe14sm42263339f8f.35.2026.09.09.00.16.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 00:16:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788938208; x=1789543008; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=DwnqTRQY8vAJqjQdX1/yppoGjNj95LCZ3z+ZCPsojp0=; b=OK7P1orzZCKGU206HZTz31BZxGz9B8Hhc/FVKbsC2CVrYbBJV4uIAUqdupI2baUktI iIGuGWAcMvg/XutZ7DgVCBfWRpfemQiIF9JawL8djeT1AM0hzV5GF33Zxeb1GDzqub/G SjsCEf1v6yMJta2KkBnsCh2ZmKJil7Cb5T4kggvNJlHW4FeooD0hTGVOxFEQqqSJzijI cNPnSN/0yzXvTWpZryZFgWxQc9X3xyemm4XESPl814XLnqd/TUhSMbb7zSZFndhTi+p7 USLnC2++Gfp09px2bkZBCwpops06nPKgIZ1pt1KV8dAOGYXSvM5PRsUs950aqQnE6oua 4hfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788938208; x=1789543008; h=content-transfer-encoding:content-type: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:content-type; bh=DwnqTRQY8vAJqjQdX1/yppoGjNj95LCZ3z+ZCPsojp0=; b=SE1LM4J5wJmW11W0Gp4jXpDR8IzftZKCf/btzcDp1SCRtEWxb53UYLbdGkBFk470XH mqsqYOd54Y5MlQgchrPHT5ozW2hdzjWf0DQcv4kg6DpdezeAt3hY9IUJ4Ai1ipuRaeAL GBXqpkLrgOAq5ynYgjej5RernZC4R+EpZEiviPfNiXaR8a4ZhIWMeGgQxsAXo9kP7gEx uVxazO2yOIa1yBPIBrWCDX5BL4CPZsl2TptO64meSlJVTUP00/DuEuWNaPnH62MkE4aq tB3c2qm20nPzkTDvUjuYXpKFkwaMa10hyXK5caMRUIBWL+gSIz2xihz93K+v6JH/edZj H57g== X-Forwarded-Encrypted: i=1; AKwUvBwfhxIt0kqHBVLnthgvtSCY9OpwJfKim4AdNaIUhM/4xJnnYsmxuLYtawQYUBEy34kuo7Ed7822xFA=@lists.xenproject.org X-Gm-Message-State: AFuF++lSYoCtHSZoGXQW2Z6DU2ML8/GVeeDCIaOOkVTc8kjYBvGjju/g dr9ZzRoQPIEZmnxhxtM50E+79WvLVUFAeaFowssW83POnIcdvh3kbezrqJlqJ23s6w== X-Gm-Gg: AYBFou05RcfYcL2UtYWpzypEM4NdTwG8E93vnDdu9iYqMDh7BKjfdrre7G/cwJ8ZUwh 2xeHRyjVENKjSDqNcKiIHDWQogSJzjybZG9q+QSCVkJGQ16bGpqOdPse9k/n3FmBxLYWzwTCPnu mBQSRFsNGrAWZ4Lnxp4JUftpCBszAtAjfSAaUk8APLYuk2GHJEOOonUumljPZEXEqqvIe5QzXee LZkemdAPDZFWaUG7WNrWakv9uz2jSQj2BWmQK9Thhz82dk4t0C6dAePewNFViMalI7rp4wY4Lw7 UoY/foJXgFEAtwhs0UL6xzQwgg6nG04Lsijhu39bqaBxSJ9s/AIukEfDlSJvmRCjBrDD69vorlO I5eBtzMnU1KRFZC4bdvD8iIQ/H/gMM7jDLBkd/6HY22+qFOJrjldfLp5LOhUi4/ChQbe1ALDnPy JeAA/LMv28aCkpIo4fRs533JcRQ0DihFo6M9ZifJLTOEMvOTD0ZpPdPwZWP20lkeBT1vX6di6h3 dKN0STX4sdsCjTgrj2M8SrTk9eS+tGuNMNgAP8DfHi8CrxGQ0APYHK4nRekxC8= X-Received: by 2002:a05:6000:2287:b0:485:8c17:975c with SMTP id ffacd0b85a97d-4858c179908mr30015189f8f.30.1788938208019; Wed, 09 Sep 2026 00:16:48 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 09:16:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/3] x86/PCI: use pci_sbdf_t also for pci_dev_base() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260908215721.3346842-1-andrew.cooper3@citrix.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: <20260908215721.3346842-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788938208-F64B42A1-EAC7EA94/0/0 X-purgate-type: clean X-purgate-size: 1389 No need to pass three arguments when both callers already hold SBDF in their hands. No functional change. Signed-off-by: Jan Beulich --- With gcc16 this turns out to change generated code only in so far as a SHR moves position. --- a/xen/arch/x86/x86_64/mmconfig_64.c +++ b/xen/arch/x86/x86_64/mmconfig_64.c @@ -45,14 +45,15 @@ static char __iomem *get_virt(unsigned i return NULL; } -static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus, unsigned int devfn) +static char __iomem *pci_dev_base(pci_sbdf_t sbdf) { - char __iomem *addr; + unsigned int bus = sbdf.bus; + char __iomem *addr = get_virt(sbdf.seg, &bus); - addr = get_virt(seg, &bus); if (!addr) return NULL; - return addr + ((bus << 20) | (devfn << 12)); + + return addr + ((bus << 20) | (sbdf.devfn << 12)); } int pci_mmcfg_read( @@ -66,7 +67,7 @@ err: *value = -1; return -EINVAL; } - addr = pci_dev_base(sbdf.seg, sbdf.bus, sbdf.devfn); + addr = pci_dev_base(sbdf); if (!addr) goto err; @@ -94,7 +95,7 @@ int pci_mmcfg_write( if (unlikely(reg + len > PCI_CFG_SPACE_EXP_SIZE)) return -EINVAL; - addr = pci_dev_base(sbdf.seg, sbdf.bus, sbdf.devfn); + addr = pci_dev_base(sbdf); if (!addr) return -EINVAL; From xen-devel-bounces@lists.xenproject.org Wed Sep 09 07:22:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 07:22:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412620.1643016 (Exim 4.92) (envelope-from ) id 1x4Cdm-0004Fg-LC; Wed, 09 Sep 2026 07:22:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412620.1643016; Wed, 09 Sep 2026 07:22: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 1x4Cdm-0004FZ-Gn; Wed, 09 Sep 2026 07:22:42 +0000 Received: by outflank-mailman (input) for mailman id 1412620; Wed, 09 Sep 2026 07:22:41 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Cdl-0004FT-Jq for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 07:22:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4Cdh-006KpL-3A; Wed, 09 Sep 2026 07:22:38 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4Cdi-007L4p-1V; Wed, 09 Sep 2026 07:22:38 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=FE1URNGmNGeJXKw7trSii6LEWHPhb09jYiVQReAtcio=; b=iVg88/ll3nU9wxuqSZfGDc239L SGAsw4S+QLVZmetr1TUjCy8hutM5OYKXo91zdSTvNJCMlYgwRGMp7Q7YNN/85piyAxHiQa8o+AyIQ k1g+OcFXYVX7q1Ogm0EuSe1GZtE8ES5vLYlKn0s3run7jTn/7YUVAHA4FFNOdjAVD0FI=; Date: Wed, 9 Sep 2026 09:22:28 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Teddy Astie , Xen-devel Subject: Re: [PATCH 4/3] x86/PCI: use pci_sbdf_t also for pci_dev_base() Message-ID: References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Sep 09, 2026 at 09:16:46AM +0200, Jan Beulich wrote: > No need to pass three arguments when both callers already hold SBDF in > their hands. > > No functional change. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 09 07:25:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 07:25:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412628.1643024 (Exim 4.92) (envelope-from ) id 1x4Cg1-0004mY-VI; Wed, 09 Sep 2026 07:25:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412628.1643024; Wed, 09 Sep 2026 07:25:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Cg1-0004mR-Rx; Wed, 09 Sep 2026 07:25:01 +0000 Received: by outflank-mailman (input) for mailman id 1412628; Wed, 09 Sep 2026 07:24:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Cfz-0004mK-UQ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 07:24:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4Cfy-006KtE-21; Wed, 09 Sep 2026 07:24:58 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4Cfz-007Wbw-0J; Wed, 09 Sep 2026 07:24:58 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=3jw4iKButHJPwaMb26bDfnz2RJqz2Vwhjbbd7CxUQaM=; b=MCYOSvEzycmvGW87zaA1Lt2fWF Wq3Ry7QlufSuSOU7/JIHoaAqiF+9eNg12bm0AVqczoXX4abFxhlrRStsPFSvL/6q+jdDYvJzhMT4N TI+7iUZQO3/03kYKcEkUoJ0AhkvEtW8iVVxwHsZvN2ZQ7nq9dJ2wOtLOLhV+Nxy5grXI=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH] x86/mm: limit deferred TLB flushing to PV owned pages Date: Wed, 9 Sep 2026 09:24:51 +0200 Message-ID: <20260909072451.67324-1-roger@xenproject.org> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current logic on x86 will mark all domain owned pages as needed a TLB flush before being re-used. However such TLB flushing is only strictly needed for PV domain owned pages, as those can keep a reference to the page in the TLB after it has been freed. Limit the requirement of a flush to pages that are owned by PV domains. Signed-off-by: Roger Pau Monné --- xen/common/page_alloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 62ac89b824de..be202f0b8d1e 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1501,6 +1501,7 @@ bool scrub_free_pages(void) static bool mark_page_free(struct page_info *pg, mfn_t mfn) { + const struct domain *owner = page_get_owner(pg); bool pg_offlined = false; ASSERT(mfn_x(mfn) == mfn_x(page_to_mfn(pg))); @@ -1539,7 +1540,7 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) } /* If a page has no owner it will need no safety TLB flush. */ - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); + pg->u.free.need_tlbflush = owner && is_pv_domain(owner); if ( pg->u.free.need_tlbflush ) page_set_tlbflush_timestamp(pg); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 08:26:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 08:26:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412650.1643033 (Exim 4.92) (envelope-from ) id 1x4DdN-00051Q-JU; Wed, 09 Sep 2026 08:26:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412650.1643033; Wed, 09 Sep 2026 08:26:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4DdN-00051I-GK; Wed, 09 Sep 2026 08:26:21 +0000 Received: by outflank-mailman (input) for mailman id 1412650; Wed, 09 Sep 2026 08:26:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4DdL-00051C-LU for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:26:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4DdK-001Tz4-6i for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 10:26:18 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1181f-e002-0a2a0a5209dd-0a2a450bec8a-26 for ; Wed, 09 Sep 2026 10:26:17 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa11829-b7e8-0a2a450b0019-b9ff1c12a133-3 for ; Wed, 09 Sep 2026 10:26:17 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a085465762000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 08:26:14 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 0C7CF8032F; Wed, 9 Sep 2026 10:26:14 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=rDsp81kQ5Ukn1shiHUXJQUWHJKFM7Z5doiSivEQ6fDA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=KggpzwGp2mojiSwKwBnvWseaKYVXp923/dZJLP4Xr4DsoZiFHoB8qagxl6Cw7WCjrK9z8pyqo 88IPbYUBaof1UQwoRTVnmWjzWx0VAC6M/Xi3O1l0eITRVQQGWi8rYiKVz3g7x9ct+g7uGLCJTe4 mWOwZPFG/gjOI1NMq1Bfjnjrw5cU7k5o8/6Ojqca2GXzA8Ny8ZaV1AtluucmrzNf5V3SFa/xnOy QnRoqYfOmnd4ICPMeqLDucyquUNxEELF+kIHDXBTyYtgoi+JV930cb7mU0sR3LwS/yk5DtFja4H Ff2NCb3EVtIC/C0/sSdzwniRwnOBayQz/gevSyJW6bhQ== X-Zone-Loop: c5c3c8e62e6044932e9067935122743e54444a14020c x-campaign-type: default x-transaction-id: ad88ef2d-05da-44cc-bc20-8ac3d7ceca31 x-swg-uid: 01-276f61d5-df59-443f-8616-44a77f824306 X-Mailer: Sweego Message-ID: <1788942374.8631fc262581453bbf619ec5b2062170.1a085465762000c4f3@vates.tech> x-swg-bid: 1788942374.8631fc262581453bbf619ec5b2062170.1a085465762000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 9 Sep 2026 10:26:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] x86: Fixes for not-quite-XSA in pci_conf_write_intercept() To: Andrew Cooper , Xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260908215721.3346842-1-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------oJGUQlzPbZJyZQDCU88A3H2y" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788942374168 X-purgate-ID: tlsNG-42698a/1788942377-A8AC89EA-43FE9D94/0/0 X-purgate-type: clean X-purgate-size: 5788 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------oJGUQlzPbZJyZQDCU88A3H2y Content-Type: multipart/mixed; boundary="------------AETanEuFm6aVWvPpFJJRCMs8"; protected-headers="v1"; hp="clear" Message-ID: <53824df0-e1f3-4cf7-894f-f932eb27b980@vates.tech> Date: Wed, 9 Sep 2026 10:26:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] x86: Fixes for not-quite-XSA in pci_conf_write_intercept() To: Andrew Cooper , Xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260908215721.3346842-1-andrew.cooper3@citrix.com> --------------AETanEuFm6aVWvPpFJJRCMs8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDgvMDkvMjAyNiDDoCAyMzo1NywgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBQ bHVtYiBwY2lfc2JkZl90IHVwIGFuZCBkb3duIHRoZSBjYWxsY2hhaW4gdG8gc2ltcGxpZnkg cGFyYW1ldGVyIHBhc3NpbmcgYW5kDQo+IG1ha2UgaXQgaGFyZGVyIHRvIGZvcmdldCB0aGUg c2VnbWVudC4NCj4gDQo+IEFuZHJldyBDb29wZXIgKDMpOg0KPiAgICB4ODYvcHY6IENvbnZl cnQgc3RydWN0IG1taW9fcm9fZW11bGF0ZV9jdHh0IHRvIHVzZSBwY2lfc2JkZl90DQo+ICAg IHg4Ni9wY2k6IENvbnZlcnQgcGNpX21tY2ZnX3tyZWFkLHdyaXRlfSgpIHRvIHVzZSBwY2lf c2JkZl90DQo+ICAgIHg4Ni9wY2k6IFVwZGF0ZSBwY2lfY29uZl93cml0ZV9pbnRlcmNlcHQo KSB0byB1c2UgcGNpX3NiZGZfdA0KPiANCj4gICB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20v cGNpLmggICAgfCAgNSArKy0tLQ0KPiAgIHhlbi9hcmNoL3g4Ni9wY2kuYyAgICAgICAgICAg ICAgICB8ICA2ICsrLS0tLQ0KPiAgIHhlbi9hcmNoL3g4Ni9wdi9lbXVsLXByaXYtb3AuYyAg ICB8IDEwICsrKysrLS0tLS0NCj4gICB4ZW4vYXJjaC94ODYvcHYvcm8tcGFnZS1mYXVsdC5j ICAgfCAxOCArKysrKysrKysrLS0tLS0tLS0NCj4gICB4ZW4vYXJjaC94ODYveDg2XzY0L21t Y29uZmlnXzY0LmMgfCAxOCArKysrKysrKy0tLS0tLS0tLS0NCj4gICB4ZW4vYXJjaC94ODYv eDg2XzY0L3BjaS5jICAgICAgICAgfCAxMiArKysrKystLS0tLS0NCj4gICB4ZW4vaW5jbHVk ZS94ZW4vcGNpLmggICAgICAgICAgICAgfCAgOCArKysrLS0tLQ0KPiAgIDcgZmlsZXMgY2hh bmdlZCwgMzcgaW5zZXJ0aW9ucygrKSwgNDAgZGVsZXRpb25zKC0pDQo+IA0KPiANCj4gYmFz ZS1jb21taXQ6IGEyY2E0ZjhiOTg5MDg5OWNhODlkNjExNjAwMmU3YTljNTk1N2Q4YzYNCg0K UmV2aWV3ZWQtYnk6IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0K --------------AETanEuFm6aVWvPpFJJRCMs8-- --------------oJGUQlzPbZJyZQDCU88A3H2y Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqhGCUFAwAAAAAACgkQZg+p0QLLz9BZ Xgv+MBUPjvcxyq2HJ/YwZCq737x2zWf9WvGPX5GVqjtmTFiISLfhJ+tXbeKiMlZZSe9LcTL/q8B4 i7naC626blgtRjVHI1MkkVWgNxfhSJ0cUJBoYx7WhV5aZKKQvz2vNKBIwGd0bNRijRcJ5GdOUld8 s9vPa7P7Gn0krAipE+Et7QdTIgImGF4anc0+LbZu8FGVwbccvfHyUkI6p50zirl2Ml2mJ1nz50bw HKRdxW8u7S5+RZ5wrjJfyQD38nVuZQ/pMG5QnUFnCJWrr7iOlK2uR94Iup5uJsi8bfR4fO21y2hg rH/6u0+T8pCmoA92gAGMiEKc+m8mkR5IseiLnJh06/o0+Rlwi1XQuRZ2lgOeu+mm2yp4+XgjrrML JYhaInB1tL14tUbJfVS5r3tnoqIMekNCSKpbZ+1xvQL/NVe1DM98yFu0RB/OE/SKhebXhN/Z0ljy aw4Vhj3RYNfhyQdIKT0RTVrbEaeeZvLSoiKOhpPvnbV5+FGZZO/eidPEceBR =GFkH -----END PGP SIGNATURE----- --------------oJGUQlzPbZJyZQDCU88A3H2y-- From xen-devel-bounces@lists.xenproject.org Wed Sep 09 08:27:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 08:27:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412658.1643042 (Exim 4.92) (envelope-from ) id 1x4De4-0005TJ-UU; Wed, 09 Sep 2026 08:27:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412658.1643042; Wed, 09 Sep 2026 08:27:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4De4-0005TC-Re; Wed, 09 Sep 2026 08:27:04 +0000 Received: by outflank-mailman (input) for mailman id 1412658; Wed, 09 Sep 2026 08:27:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4De3-0005T3-Sy for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:27:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4De3-00G3Hj-9j for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 10:27:03 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa11851-8faa-0a2a0a5109dd-0a2a4507ee22-12 for ; Wed, 09 Sep 2026 10:27:03 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa11856-b4ea-0a2a45070019-b9ff1c228f6b-3 for ; Wed, 09 Sep 2026 10:27:03 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a085470866000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 08:27:00 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 6CD1C81B2C; Wed, 9 Sep 2026 10:26:59 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=UgkyHAm7i5n0tVB7RoWZhcSpVXwxZSQ6WKMYeexxndU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=M/hA2OzXQuhBuwKMnSEYpbS0FTD50ahBJKqtNEsYKokVkxMTx+wG8vfGMRTJSlhiZKw36h0NU 7fWgcJSNq6KOrvYXdjnTPTaEg3/jvvPc0jbXQCXIEN2dmO2UL+MPDJALTLhDr4biwIrfzn43EH2 BaB7sJe47vW7bJHBtaSDOGS47vDNu6QuSeN3K4m94sSx1v8rMjahx/DFErsBbGLMdCrLxleKn0X ClL9/Q05TXbm/JgqaH5SKOJLTxHNDNE0X43tk43CRW3Vwfp2UBofVEmQf7t/kbjDT01K8yUfnBP K/PWoqBbiEhK7JgR8SkFIVPkiEO/VY58jQ3/Eh0YZukg== X-Zone-Loop: 2c9a917afd961e7d0242bce26598f4f8c0f7646b4fd6 x-campaign-type: default x-transaction-id: 250231dc-9e70-40e3-9cab-f70f1cf75a7c x-swg-uid: 01-1a2172cc-abba-4296-b591-6dc7e0b53fbc X-Mailer: Sweego Message-ID: <1788942420.8631fc262581453bbf619ec5b2062170.1a085470866000c4f3@vates.tech> x-swg-bid: 1788942420.8631fc262581453bbf619ec5b2062170.1a085470866000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 9 Sep 2026 10:26:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/3] x86/PCI: use pci_sbdf_t also for pci_dev_base() To: Jan Beulich , Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------z7zWYfpnEEUceiZJalqurD43" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788942419549 X-purgate-ID: tlsNG-ef75cf/1788942423-A5AC0AE4-3D8E94B3/0/0 X-purgate-type: clean X-purgate-size: 6698 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------z7zWYfpnEEUceiZJalqurD43 Content-Type: multipart/mixed; boundary="------------v3KcJk2Is8aD75En0Qk8dll4"; protected-headers="v1"; hp="clear" Message-ID: <074b9d6f-9db5-4310-8d0c-e5cb6d47e71c@vates.tech> Date: Wed, 9 Sep 2026 10:26:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/3] x86/PCI: use pci_sbdf_t also for pci_dev_base() To: Jan Beulich , Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: --------------v3KcJk2Is8aD75En0Qk8dll4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDkvMDkvMjAyNiDDoCAwOToxNiwgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gTm8g bmVlZCB0byBwYXNzIHRocmVlIGFyZ3VtZW50cyB3aGVuIGJvdGggY2FsbGVycyBhbHJlYWR5 IGhvbGQgU0JERiBpbg0KPiB0aGVpciBoYW5kcy4NCj4gDQo+IE5vIGZ1bmN0aW9uYWwgY2hh bmdlLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2Uu Y29tPg0KPiAtLS0NCj4gV2l0aCBnY2MxNiB0aGlzIHR1cm5zIG91dCB0byBjaGFuZ2UgZ2Vu ZXJhdGVkIGNvZGUgb25seSBpbiBzbyBmYXIgYXMgYQ0KPiBTSFIgbW92ZXMgcG9zaXRpb24u DQo+IA0KPiAtLS0gYS94ZW4vYXJjaC94ODYveDg2XzY0L21tY29uZmlnXzY0LmMNCj4gKysr IGIveGVuL2FyY2gveDg2L3g4Nl82NC9tbWNvbmZpZ182NC5jDQo+IEBAIC00NSwxNCArNDUs MTUgQEAgc3RhdGljIGNoYXIgX19pb21lbSAqZ2V0X3ZpcnQodW5zaWduZWQgaQ0KPiAgICAg ICByZXR1cm4gTlVMTDsNCj4gICB9DQo+ICAgDQo+IC1zdGF0aWMgY2hhciBfX2lvbWVtICpw Y2lfZGV2X2Jhc2UodW5zaWduZWQgaW50IHNlZywgdW5zaWduZWQgaW50IGJ1cywgdW5zaWdu ZWQgaW50IGRldmZuKQ0KPiArc3RhdGljIGNoYXIgX19pb21lbSAqcGNpX2Rldl9iYXNlKHBj aV9zYmRmX3Qgc2JkZikNCj4gICB7DQo+IC0gICAgY2hhciBfX2lvbWVtICphZGRyOw0KPiAr ICAgIHVuc2lnbmVkIGludCBidXMgPSBzYmRmLmJ1czsNCj4gKyAgICBjaGFyIF9faW9tZW0g KmFkZHIgPSBnZXRfdmlydChzYmRmLnNlZywgJmJ1cyk7DQo+ICAgDQo+IC0gICAgYWRkciA9 IGdldF92aXJ0KHNlZywgJmJ1cyk7DQo+ICAgICAgIGlmICghYWRkcikNCj4gICAgICAgICAg IHJldHVybiBOVUxMOw0KPiAtICAgICByZXR1cm4gYWRkciArICgoYnVzIDw8IDIwKSB8IChk ZXZmbiA8PCAxMikpOw0KPiArDQo+ICsgICAgcmV0dXJuIGFkZHIgKyAoKGJ1cyA8PCAyMCkg fCAoc2JkZi5kZXZmbiA8PCAxMikpOw0KPiAgIH0NCj4gICANCj4gICBpbnQgcGNpX21tY2Zn X3JlYWQoDQo+IEBAIC02Niw3ICs2Nyw3IEBAIGVycjogICAgICAgICp2YWx1ZSA9IC0xOw0K PiAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+ICAgICAgIH0NCj4gICANCj4gLSAgICBh ZGRyID0gcGNpX2Rldl9iYXNlKHNiZGYuc2VnLCBzYmRmLmJ1cywgc2JkZi5kZXZmbik7DQo+ ICsgICAgYWRkciA9IHBjaV9kZXZfYmFzZShzYmRmKTsNCj4gICAgICAgaWYgKCFhZGRyKQ0K PiAgICAgICAgICAgZ290byBlcnI7DQo+ICAgDQo+IEBAIC05NCw3ICs5NSw3IEBAIGludCBw Y2lfbW1jZmdfd3JpdGUoDQo+ICAgICAgIGlmICh1bmxpa2VseShyZWcgKyBsZW4gPiBQQ0lf Q0ZHX1NQQUNFX0VYUF9TSVpFKSkNCj4gICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPiAg IA0KPiAtICAgIGFkZHIgPSBwY2lfZGV2X2Jhc2Uoc2JkZi5zZWcsIHNiZGYuYnVzLCBzYmRm LmRldmZuKTsNCj4gKyAgICBhZGRyID0gcGNpX2Rldl9iYXNlKHNiZGYpOw0KPiAgICAgICBp ZiAoIWFkZHIpDQo+ICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4gICANCg0KUmV2aWV3 ZWQtYnk6IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0K --------------v3KcJk2Is8aD75En0Qk8dll4-- --------------z7zWYfpnEEUceiZJalqurD43 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqhGFMFAwAAAAAACgkQZg+p0QLLz9Cl Kwv/Y3VRCRMuy2u2IHwfwIy0OAXBfLUcnfbUTPjbxXITz1Q9jop406XSmCKR+IuXfx0+U9cI0siL u4hMzx9axvv1sipyBlWuEXtRNE9/JhdHh8FRXhvDGu6Z8t7+HrIp5REaitBam43PJSi6voBGdBwV OB95dxgLw/Q/mapaus8RxpmKY5/1uYy1bIaBx6CxPR29hUlgg9HkfMRlstDBHXtAei1+BzN+q5LN SEqfTuFCxWP6xMDMuvUtVMyOYVQJAoPLjKYlkDcUTd7NrbGjnwGuQ6tfc1zEuEdOcR9llc1trVA9 7FSa0o9c5qeB6CzA7U84ZmuWigNhqgza+AC7p6m0Egj5ESb8v0yC22yjSblFzsGO9BbkUThXdNT0 Yz0qI7D75qCr9m2JiZ4a1xITuyF7R/VU5+/056D9GdDcylj1mhv02QEP7IHY3DU4wPaCjyEBqZ0y hRCOpEZj5Kok+EKL4xzDLCwe2xRfya5nCGtCjsdldyA/sIkfK/x9SJog01Re =zkBp -----END PGP SIGNATURE----- --------------z7zWYfpnEEUceiZJalqurD43-- From xen-devel-bounces@lists.xenproject.org Wed Sep 09 08:38:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 08:38:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412672.1643051 (Exim 4.92) (envelope-from ) id 1x4DpD-0007UK-Ua; Wed, 09 Sep 2026 08:38:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412672.1643051; Wed, 09 Sep 2026 08:38:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4DpD-0007UD-Rl; Wed, 09 Sep 2026 08:38:35 +0000 Received: by outflank-mailman (input) for mailman id 1412672; Wed, 09 Sep 2026 08:38:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4DpC-0007U7-J4 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:38:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4DpB-006iYA-Jf for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 10:38:33 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa11b01-8faa-0a2a0a5109dd-0a2a4509ddc6-14 for ; Wed, 09 Sep 2026 10:38:33 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa11b09-be1a-0a2a45090019-4a7de18caac1-3 for ; Wed, 09 Sep 2026 10:38:33 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd5462b69so4571515e9.1 for ; Wed, 09 Sep 2026 01:38:33 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d08144037sm370597035e9.7.2026.09.09.01.38.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 01:38:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788943113; x=1789547913; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=uhIKk2TEmYzBuTS8CzFFK4ZoaLgPdXfCnSl12U5DxsY=; b=k0e78w/cAbAwaxekbOrc+zEqy5SW3vLiZa0AXGzf612eu18DRmVp7NRJnAzme/IyUW q5qZHqKQEAHCTIKNZObj2xeXGgpGAR4Cp1MAr9dV94NhwUo14kPyfHKUzeoJnHVSUsMq Ar+U7vwgvClMOlLZOL74kn1wMiR7q1+76GxmRmFYCiGwvIT0KrVi0xKfvS7SZAuevcjP 9KxSppi+hr7OXLm175B8BCmVFYkc5AXbcukjgJ89muDJ9vasLQ2PAv/2UVcJiVhrI2H7 vO3fZOTwSwZ2933A60HDZubOCbyOFim5hEbI2x0rVZnobcE2di2UpkxeaDDhxXkpAl/m KrnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788943113; x=1789547913; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=uhIKk2TEmYzBuTS8CzFFK4ZoaLgPdXfCnSl12U5DxsY=; b=NsAR2E3PpA5g3rBC6iP38fT9RsmzBV1mW34u/L8x9PViYQ8OoLKFY9e8HyRzlTnAqB uTQ3LhEaO+Pw5L7MOI8X/GvFDylZl4rYR6f4LceNqv9Z9exLHlggoy9TRj/Pe+ugMgdx n98PZh1ivqAt1/6sI18d5PJkNdee59uudU/9WoAqqaneYRzRN0lZRL48F8Zwvv7ZHJOq lhhq7vV8qG0oV0j+sLNF3dfbQ/eJJIQzPB1wE06Q5czQrgpZfIXr8i1AclrLLdyuJcx7 CNVomQlPn403ZG2rESYmmJhPX9GPszj8ZQmTy+UGvLi9KKxQNigDSKmng3Y6GwEsCLpU GDGw== X-Forwarded-Encrypted: i=1; AKwUvBxytSIwA/VCYF2nn23BvsR+V3xcQMbRcOxoSCyk0x9yQZIlCn22yRTOKtdp6o/KxD9bA6/+OwAn1zA=@lists.xenproject.org X-Gm-Message-State: AFuF++lEToUVrbg/kEofZ/10ee+S3sEI7ZbZ2/wDnlYWF7/BlL2lWiMk 7e3PxECft4P/XTK535aHPL8aHvrb6qaTgqak453VVEj7fGEAcHWswD5G X-Gm-Gg: AYBFou1kt5g94SXoyGzUvq/cj5J0A2RATQgM52wEVC9eIQhEF5SrIAfKCYVZm9i/FoE Zvw5WPM4Z7p4idMpR7EWt5j+nuUIDSU8FT7hFUXSTMSH42876rxLM1PHQgko8xxK6HrW5qxcb5K /mmVYtQr2i4sFp2oXgZLlrKbI9DsLqQssIq34Ze63NunxFKzEp9ME7nbAF+omgEl+BRCCTUOTF9 GyMEmtp9or2mnHAb5htsyWnJrapL3PIhb71pprYw9QBzsUMmdNLpCXNAk6JSiihb+anF88RxRl2 vr16ICHzpZoBY9CnzoiBymI6Ztt6u7Ss+XJNk3v/bukMnGXucl3U+59zDN30EKOvnMUOVgoxqER 0VU/mT2PBXdS+fJlc5KeAKqs9AYGj/c4oSH+3S9MlmyPTkZGnNOwUGmf9htuAqKN0wo5HLn+DJb F6utXZxytqdYsueEXaLiWfpmzx946x8CJnb+gUTn4rJyUP1JbpI00HkxPKfPYZqBD9pmi6jnFyv XFHFetZ60KzleQwyXtuup3CKxbpsL0jjpBB X-Received: by 2002:a05:600c:3146:b0:49b:9105:cdaf with SMTP id 5b1f17b1804b1-49d1f32335amr77527365e9.8.1788943112674; Wed, 09 Sep 2026 01:38:32 -0700 (PDT) Date: Wed, 9 Sep 2026 09:38:31 +0100 From: David Laight To: "H. Peter Anvin" Cc: Borislav Petkov , Mauricio Faria de Oliveira , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() Message-ID: <20260909093831.095b89cb@pumpkin> In-Reply-To: References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1788943113-BE4DB034-03D3055D/0/0 X-purgate-type: clean X-purgate-size: 2418 On Tue, 8 Sep 2026 16:16:51 -0700 "H. Peter Anvin" wrote: > On 2026-09-08 12:32, Borislav Petkov wrote: > > On Tue, Sep 08, 2026 at 03:04:53PM -0300, Mauricio Faria de Oliveira wrote: > >> Boris, perhaps the approach here could be changed to add an actual > >> memcmp()-like inline implementation (e.g., as provided in a previous > >> revision, without return value differences), or continue with the > >> memeq()-like memcmp() from arch/x86/boot/ but rename it to memeq() ? > > > > Nah, new functionality is not needed. We can add it later when it is really needed. > > > > I personally think it would be a good reason to explicitly rename it memeq(), > after all it indicates what it actually *does*. > > bool memeq(const void *m1, const void *m2, size_t n); > > Note, however, that the sense of the return value is opposite -- true means > equal, so !memcmp(...) needs to be replaced with memeq(...) and vice versa. > > The other issue is when gcc/clang wants to call memcmp() out of line. Although > a theoretical concern, there really isn't any reason not to DTRT there since > there is only one instance in the code, ever. > > Here is an out-of-line compact memcmp() which works for both 16/32 and 64 bits: > > int memcmp(const void *s1, const void *s2, size_t len) > { > int rv; > > asm volatile("xor %0,%0 ; " > "test %3, %3 ; " /* Handle len == 0 correctly */ That comment doesn't really say what the instruction is for. The XOR sets Z and clears C (I just checked) so it isn't needed in order to get the correct flags. > "repe cmpsb ; "}g > "setz %b0 ; " > "sbb $0, %0" That pair is just wrong. Only one of C or Z can be set, so I think this is ok: "seta %b0 ; " /* C == 0 && Z == 0 */ "sbb $0, %0" > : "=&r" (rv), "+D" (s1), "+S" (s2), "+c" (len) > : : "cc", "memory"); > > return rv; > } > > On 64 bits it compiles to: > > 0000000000000000 : > 0: 48 89 d1 mov %rdx,%rcx > 3: 31 d2 xor %edx,%edx > 5: 31 c0 xor %eax,%eax > 7: f3 a6 repz cmpsb (%rdi),(%rsi) > 9: 0f 97 c2 seta %dl > c: 0f 92 c0 setb %al > f: 29 d0 sub %edx,%eax That isn't the object code from the source ... David From xen-devel-bounces@lists.xenproject.org Wed Sep 09 08:57:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 08:57:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412685.1643060 (Exim 4.92) (envelope-from ) id 1x4E7K-00023N-C4; Wed, 09 Sep 2026 08:57:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412685.1643060; Wed, 09 Sep 2026 08:57:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4E7K-00023F-9E; Wed, 09 Sep 2026 08:57:18 +0000 Received: by outflank-mailman (input) for mailman id 1412685; Wed, 09 Sep 2026 08:57:16 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4E7I-000239-Cf for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:57:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4E7H-00CgMy-PU for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 10:57:15 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa11f5c-2eae-0a2a0a5409dd-0a2a45068c28-28 for ; Wed, 09 Sep 2026 10:57:15 +0200 Received: from [52.101.69.118] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa11f6b-195a-0a2a45060019-346545765b56-3 for ; Wed, 09 Sep 2026 10:57:15 +0200 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11) by GVUPR03MB11305.eurprd03.prod.outlook.com (2603:10a6:150:33d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.8; Wed, 9 Sep 2026 08:57:09 +0000 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292%7]) with mapi id 15.21.0406.005; Wed, 9 Sep 2026 08:57:09 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ke7BL2N39ZhKYS1uILv/wr9/0Fy7mzYmKYczeqWsKFBHtdTa8UmgCzpdQaTMHhsLjhCuem/vMVvaWKih7pu7uw8Zk67T+xisKURPNOAmhbftvIJOnrOgX2JXVA/smm/iwDetb5EX4VZWau1SnCHE/8iRx4tjq6H51aHxeDwuFd0OnmDDhkLV+KbKdeQ5rBeW43uU1vh5t7Wvl5OOZHODC3kU6yhoVVFnqPfWUH5wR3ndwMvzn9F+7MB8JdmjlFOuzw45pqdmSwS9Bb/+R565ALkxtpOqU/WKRNlcPpluxOWx7Li/4P5LlOUx7o+l495OcaI+pLWqSxA8lAA6kDcycA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pO75MlVDe0nMYZAvzFeDEUNClrnEUOmHUJcaSb/LUBU=; b=fODwZGr3GD1aBpxotbuYLQs1kak3n6rwsyeU/AawD/3p/pRSCuz5HPrMMgsMXvIWlinO5FrjzR9PWhkE7LK6cWXjO40xHSdScKP19+HdLdkaZk490DfcKWwTmGZ72o1pkjvHlV+XvwSo7BEhBIXPBCDXUUt8MZtqVp3hZU3BoEAIroa6wmudO2WmTFIrz7MM8Bu34Vx+e5/1mSiOLKjBcY4VYjzVdCAOqA+Dx17UwLTEExQQ+9umakK7TnvgwFoJTxoQ8B6eTHkGDWtoBOog20VYSjXgdVaRRXdrugsz+K/vNP2SM9avTFcVxnl59tPN2Y3QFT55iDkXGyBBD/JaAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pO75MlVDe0nMYZAvzFeDEUNClrnEUOmHUJcaSb/LUBU=; b=CP3zOy1wp/9pHUkPVwTH4DqxysZ/gjIRsFeBV108wCj6qInx9S6W44lYnHHTaoDu0GsfrhM3iyBBxfYPI2nfwkPlIgrHn6VoJdAcOd1+8e8UpvEup9S0zpFjYiVoyOZz5zSnpdi0rH8nooT8jng0bL8DywPBIdf/iAmN5cVkywfTLPM03tXqP6upnZSEixhdaT6KSFsnB5e1zgL3SBvjFy7Cfya3RZZIqYrcr6drCb8Kas2qUzUSJ+OwyPXWYynbb6RLNG9yeGWWU0wTt1tGiz9Em/mk+icKQGD+tWlsOaSf6loQX4oPbU00Kkpcr/5Uitv6ihG0pO2+7/5Ft6Gj5g== From: Sergiy Kibrik To: "xen-devel@lists.xenproject.org" CC: Sergiy Kibrik , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , "Daniel P. Smith" , Andrew Cooper Subject: [PATCH v2] common: dom0less-bindings: introduce XSM labels Thread-Topic: [PATCH v2] common: dom0less-bindings: introduce XSM labels Thread-Index: AQHdQDkyagFQfWFtmkmXmxebnPrTEg== Date: Wed, 9 Sep 2026 08:57:09 +0000 Message-ID: <20260909085707.2359322-1-Sergiy_Kibrik@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS8PR03MB9192:EE_|GVUPR03MB11305:EE_ x-ms-office365-filtering-correlation-id: f0a1711e-8c55-46c6-a376-08df0e5054d1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|10067099003|6133799003|18002099003|11063799006|56012099006|38070700021; x-microsoft-antispam-message-info: KM3xhJes4iGHoavvYnyFFg46sp0eGk1RCvQfiBajgLadbqrCXOYwdmDoUqh1f3eDPOnkxbFFatDrBxEphV8T/zRlZ6B+1TAN8t0pgVCiEza1eKWCrt+QxQeQnR+WWiXNSutc0lTyFu1DN4kpYCCREgZBHRyRZ8KqCWbad5OgOaZBvSb4TFtSl3XrPdDf9kCxI0AxXI1f4MGD0429qJ5s768I+E/4Z3+Tl19DJwie7XC9MEA1/pYihcQgRxY48YsPBrSqbDm9Ee3X4xrznx1D4yMJRZWr3q16Arbpgt0f0+4UkGTHXkT6Gi7SIdJyxfUO9BiOiqQ/DkZokU4SIKjOSV7IYnu+mRObTNnGn082GYXezYJfwuUGr0afMIy9AxXQJDHSXFQdRSGHRtq8ngUo0dC0CYgA25b7ONRdmzJv46nM7y2t+J6KjJ39ymYiFdMgE8dY98ABVpDgJAWirFJYF0vwsO5DLObcz3e2oL+riANBjRDBIHf8OVx3ixVrkLp979md9o+VB9Bua9dC5vCStaSno4/xfGXAaz0Nt0kCz8DY1qT/TASoqdfLEiQNNDh1VBRX+381ib0cEaEZhoUAT4Qst3OHn/kDi3sZJTenbbFk/of0SMrnT/D4X5ZGQ4yI/9Aj23q/QBZPbvAiRhEbe8XakPCU0N0ocpq2JbH/WnN73dKHttkowUQMSGNvSO8zwAfUdn4ZZgS9XkWFh1/5JXojW8Jhd2WNrl5owWk4bow= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(10067099003)(6133799003)(18002099003)(11063799006)(56012099006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UjlxT09sd3VCSVBiRDcvOWxiMUZwRVBZZlRFTHk3QUtFbU5PK2NsajF1MXNm?= =?utf-8?B?eGovN0k2MEZJNTNPRGh4eEs1RFJyQjl5Wkp4TXBHYi91S3cyY0RPL1RKNFc2?= =?utf-8?B?Skd5Skp5MS9ZTVlWcmo3ZitObjF5YmdnWGNLRWFwQlNIY21pbU1wZEJuNGFD?= =?utf-8?B?bFNaV2NZQ0FYUHpCSm52cm9uWjBwZ2ltejdFclBrcE93ZnZWMW9sQXMwUncx?= =?utf-8?B?K2wrU0pqcUl4UEkrcHgrNGd2N0JodFBOOVlvQXk0QmFQNS93c3JBU1l1WVhl?= =?utf-8?B?dWpZWnhjSnFqMlh3UWJuanl0eksxZkhKemx5VnN0UHdZNEZNNTNkZHhnMHh2?= =?utf-8?B?dnh4YVJjL2JWOWs3Yitudy9JLzZpQ0xyaVZCaSsrcXI2T1Urc1FQZmJBSlBh?= =?utf-8?B?eHJGaHZ1L0xUQnZYYTNWbHpmV2Z0RmRIcTk4SW8vdUhUWllmbk1yajl5Szgv?= =?utf-8?B?V29MTjIrNE1TQ2NSRjlicVQ4QTNidUFLcFBUQUFyKzZWTkl5NVNnTmVZNkVZ?= =?utf-8?B?OE56eEhZdjQ1VXlQd1FVbk1pYXdGeE1jTy9NRkNYUllRSlZxMHB2ZDdDREsr?= =?utf-8?B?dGdCell3YWt5enZYM3hhOGFqMW10VTBwdFVSYXpxWFRTRE9QRERXZk5lbFlS?= =?utf-8?B?NXVOL3p5TzhqaWZSUCs0YzBXZnJXMUJJVE5OUEdYbCtMSmdESDRyMDV2RlIx?= =?utf-8?B?aG56eENTMExQQjNSWml1U3gzRWdZSWs5MUJPeTFuN050TEVEbG1sNTNlbWln?= =?utf-8?B?MWtMKzAvV0g0Y0pNV1BZN25aMTdLMkVnM1k4TC9yYmVBbHoxTDI4NThDeVJE?= =?utf-8?B?YXlnN1k2NUFZZkZBQ0h3VGl3MGNqK083ZExlcklCSVNaNlEvK3FhcHU0U3hL?= =?utf-8?B?THpNT2VmM3F6VkJBZm80RGdaRjU3UTJGQUlEZDJBU2NCYmFzMm41cUZJNjJr?= =?utf-8?B?S2dUUUxtby9sbEZWNitveUhDQjV5Snk5K0ltR1NsUy9wQ29GNGZrWWVqOU43?= =?utf-8?B?SmJkWi9ZTzd2cUltZUNMWW1oQ09CMHdvVkI1UzlQUEZWY0ZteEVPWlBiNUxw?= =?utf-8?B?STFibnVZK0ljalpCdzJUK2JVYTlsdklBOUFVQ3Q2ajFVZVRCSXQ1czQwT3ZC?= =?utf-8?B?TjZnVktuS25YalQ2MFBHNUVSOTZ5NFg0bUtRQ1hQSlI3bGZOK0EyTkphYlM2?= =?utf-8?B?ZDM0VEh3WWtQSzNUNVNEanJweURqcWI5WnA2NTdDRVhMOXNkZ3hGbmFaUHI0?= =?utf-8?B?bVFZRmd3RjhGWDdaUUhNN3JlUDdaS21acHNMVXB4VDJMTndvWVI2aVNPYTFN?= =?utf-8?B?RW1jL1VhVFJWTHV6SWR2TkduN0JZQ0hQTXp2WHpIVXV6MmFsSU5nbk9LSWtT?= =?utf-8?B?bm81cGMrSGxiYnlLSDNxVStjVG1RN1RwUkhrcEc0dzl2eXU2RzJ3Q1ZMbTdO?= =?utf-8?B?eGFObGEveStCZHVBWW5zTGh4YnlUZ1lUYkcyczlVdG5hWDZUL2ZkWEdwNG9I?= =?utf-8?B?ektyclNkLzIza1VYai9JYXNRZ2ZTbk1uSmJDaVZER3BOK1dBeG1GWmlsdDN5?= =?utf-8?B?VDFUQ1JSK3lMY0F0U0s4RDBtUGVsQ1ZFUWkvUWVjYnpPWnRlZjlVY0IxS1R1?= =?utf-8?B?a3VoVERvSkpVd2d5VG9jSWVBcWc2K2laeHp4UDdwaTJwVXdSd0JsZ1p5bzAw?= =?utf-8?B?ZDdiZXJmQkp0NWR0ZnpHQTZPdEczVWx4dG5waFlaVTRjcTVTNnYreXBsaHBI?= =?utf-8?B?NjhrMzBoZTlVQk9PMDdXcGJFYkxsZGtMUk16dCtlMUxwUlhhY1huK3NnY0N0?= =?utf-8?B?ZDFzODNBVXg5dGQ3Z1piaXdMY3piMENMelduQktjbXFyOXVSR0NJaXplSEgr?= =?utf-8?B?S2xZd3EzVXdXOUhmVExnVTBMZTZlaHNmdVdrZDBuemU1dXg3M1hVMmNBek5o?= =?utf-8?B?YnE4ekxIZndMZElrTDlpblpSTjY5WFVCcEFGc3pRT0hOanVkOTlJWDdnekVo?= =?utf-8?B?NEx3am5BQ0pHaTF3dVMyZk03Q2lPYy96TUtnK2VqcXNJSnhiNkY2VVZjUGt1?= =?utf-8?B?d25XVlRRaVRldkxVRlNqL0g5SmpWaDUxTzFCRWRtOE1uU05PYWJlNEJ2SFRW?= =?utf-8?B?S3NQdmdna0s4MjNlb3Fsa3BDZG1uRGtnbVp1Z2hoV3pmOCtxWFBhRHBlY0FW?= =?utf-8?B?MmJxdzFOM0c2eG5yb1pyeXJQUTZlUjczN1FUN1dXKzFRMDNQNHFodTdRMHFr?= =?utf-8?B?bkkvd05CMFNMYnRFL3FsVmZHS0pYajlBczU5VGYyb2w5L2hFUWNESHhubVQw?= =?utf-8?B?VVhjV0lOa3lLZUttQThLK0I1enFRTDNxdU5yYnVoRkppV2t5d1dCRXhGeWF3?= =?utf-8?Q?lmMYawhLq8+orLH0=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0a1711e-8c55-46c6-a376-08df0e5054d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2026 08:57:09.2968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yyDwndxF2nl2oz4iPVhc9jWJL7JW2cKwF9hHIpLGvj16X5uQ86UxWSCM+hznSTbhR31kk5c94SJllbT8aZ+GNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11305 X-purgate-ID: tlsNG-16d1c6/1788944235-F7CCD77B-003003ED/0/0 X-purgate-type: clean X-purgate-size: 6142 QWRkICJzZWNsYWJlbCIgcHJvcGVydHkgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IHNlY3VyaXR5IGxh YmVsIGZvciBhIGRvbWFpbg0Kd2hlbiBYU00gRmxhc2sgaXMgZW5hYmxlZCwgc2ltaWxhciB0byB4 bCBjb25maWd1cmF0aW9uIGZpbGVzLg0KDQpDdXJyZW50bHkgZ3Vlc3QgZG9tYWluIGNhbid0IGJl IGNyZWF0ZWQgYnkgWGVuIGluIGRvbTBsZXNzIGNvbmZpZ3VyYXRpb24gd2hlbg0KRmxhc2sgaXMg ZW5hYmxlZCwgYXMgZG9tYWluIGlzIGFzc2lnbmVkICJzeXN0ZW1fdTpzeXN0ZW1fcjp1bmxhYmVs ZWRfdCIgbGFiZWwNCmJ5IGRlZmF1bHQsIHdoaWNoIEZsYXNrIGRlbmllcyB0byBjcmVhdGUgYWNj b3JkaW5nIHRvIGN1cnJlbnQgcG9saWN5Lg0KDQpCZWNhdXNlIGNvZGUgZnJvbSBvdXRzaWRlIG9m IGZsYXNrIGNhbid0IGRpcmVjdGx5IGV4ZWN1dGUgaXRzIGludGVybmFsIEFQSQ0KYSBuZXcgcm91 dGluZSBmbGFza19jb250ZXh0X3RvX3NpZCgpIGludHJvZHVjZWQgYXMgcGFydCBvZiBYU00gQVBJ IGV4cG9zZWQNCnRvIHJlc3Qgb2YgWGVuLCB3aGljaCBpcyBhIGRpcmVjdCB3cmFwcGVyIGZvciBz ZWN1cml0eV9jb250ZXh0X3RvX3NpZCgpLg0KDQpTaWduZWQtb2ZmLWJ5OiBTZXJnaXkgS2licmlr IDxTZXJnaXlfS2licmlrQGVwYW0uY29tPg0KQ0M6IERhbmllbCBQLiBTbWl0aCA8ZHBzbWl0aEBh cGVydHVzc29sdXRpb25zLmNvbT4NCkNDOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0Bj aXRyaXguY29tPg0KLS0tDQpjaGFuZ2VzIGluIHYyOg0KIC0gYWRkICYgdXNlIGZsYXNrX2NvbnRl eHRfdG9fc2lkKCkgd3JhcHBlcg0KLS0tDQogZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290 aW5nLnR4dCAgICAgIHwgIDggKysrKysrKysNCiB4ZW4vY29tbW9uL2RldmljZS10cmVlL2RvbTBs ZXNzLWJpbmRpbmdzLmMgfCAxMSArKysrKysrKysrKw0KIHhlbi9pbmNsdWRlL3hzbS94c20uaCAg ICAgICAgICAgICAgICAgICAgICB8ICAzICsrKw0KIHhlbi94c20vZmxhc2svaG9va3MuYyAgICAg ICAgICAgICAgICAgICAgICB8ICA1ICsrKysrDQogNCBmaWxlcyBjaGFuZ2VkLCAyNyBpbnNlcnRp b25zKCspDQoNCmRpZmYgLS1naXQgYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3Rpbmcu dHh0IGIvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KaW5kZXggYmNiMDZi Yzc5Ni4uZmNjN2JlMGZmYiAxMDA2NDQNCi0tLSBhL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUv Ym9vdGluZy50eHQNCisrKyBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQN CkBAIC0zNDUsNiArMzQ1LDEyIEBAIHdpdGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0KICAg ICBub3QgcGFzc2VkLiBUaGlzIGNvbmZpZ3VyYXRpb24gcmVxdWlyZXMgc3RhdGljIGFsbG9jYXRp b24gKHhlbixzdGF0aWMtbWVtKQ0KICAgICBhbmQgZGlyZWN0IG1hcHBpbmcgKGRpcmVjdC1tYXAp Lg0KIA0KKy0gc2VjbGFiZWwNCisNCisgICAgQSBzdHJpbmcgcHJvcGVydHkgc3BlY2lmeWluZyBh biBYU00gc2VjdXJpdHkgbGFiZWwgdG8gdGhpcyBkb21haW4uIEVmZmVjdGl2ZQ0KKyAgICBvbmx5 IHdoZW4gRkxBU0sgaXMgZW5hYmxlZC4gRG9tYWlucyB3aWxsIGJlIGNsYXNzaWZpZWQg4oCcdW5s YWJlbGVk4oCdIGlmDQorICAgIHRoaXMgcHJvcGVydHkgbm90IHNwZWNpZmllZC4NCisNCiBVbmRl ciB0aGUgInhlbixkb21haW4iIGNvbXBhdGlibGUgbm9kZSwgb25lIG9yIG1vcmUgc3ViLW5vZGVz IGFyZSBwcmVzZW50DQogZm9yIHRoZSBEb21VIGtlcm5lbCBhbmQgcmFtZGlzay4NCiANCkBAIC00 MjIsNiArNDI4LDcgQEAgY2hvc2VuIHsNCiAgICAgICAgIG1lbW9yeSA9IDwwIDEzMTA3Mj47DQog ICAgICAgICBjcHVzID0gPDI+Ow0KICAgICAgICAgdnBsMDExOw0KKyAgICAgICAgc2VjbGFiZWwg PSAic3lzdGVtX3U6c3lzdGVtX3I6ZG9tVV90IjsNCiANCiAgICAgICAgIHZjcHUwIHsNCiAgICAg ICAgICAgICBjb21wYXRpYmxlID0gInhlbix2Y3B1IjsNCkBAIC00NTMsNiArNDYwLDcgQEAgY2hv c2VuIHsNCiAgICAgICAgICNzaXplLWNlbGxzID0gPDB4MT47DQogICAgICAgICBtZW1vcnkgPSA8 MCA2NTUzNj47DQogICAgICAgICBjcHVzID0gPDE+Ow0KKyAgICAgICAgc2VjbGFiZWwgPSAic3lz dGVtX3U6c3lzdGVtX3I6ZG9tVV90IjsNCiANCiAgICAgICAgIG1vZHVsZUAweDRjMDAwMDAwIHsN CiAgICAgICAgICAgICBjb21wYXRpYmxlID0gIm11bHRpYm9vdCxrZXJuZWwiLCAibXVsdGlib290 LG1vZHVsZSI7DQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1i aW5kaW5ncy5jIGIveGVuL2NvbW1vbi9kZXZpY2UtdHJlZS9kb20wbGVzcy1iaW5kaW5ncy5jDQpp bmRleCA0MWQ3MmQwZDU4Li4wYjBlZDZlMjVkIDEwMDY0NA0KLS0tIGEveGVuL2NvbW1vbi9kZXZp Y2UtdHJlZS9kb20wbGVzcy1iaW5kaW5ncy5jDQorKysgYi94ZW4vY29tbW9uL2RldmljZS10cmVl L2RvbTBsZXNzLWJpbmRpbmdzLmMNCkBAIC0xMSw2ICsxMSw4IEBADQogI2luY2x1ZGUgPHB1Ymxp Yy9ib290ZmR0Lmg+DQogI2luY2x1ZGUgPHB1YmxpYy9kb21jdGwuaD4NCiANCisjaW5jbHVkZSA8 eHNtL3hzbS5oPg0KKw0KIGludCBfX2luaXQgcGFyc2VfZG9tMGxlc3Nfbm9kZShzdHJ1Y3QgZHRf ZGV2aWNlX25vZGUgKm5vZGUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVj dCBib290X2RvbWFpbiAqYmQpDQogew0KQEAgLTIxLDYgKzIzLDcgQEAgaW50IF9faW5pdCBwYXJz ZV9kb20wbGVzc19ub2RlKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9kZSwNCiAgICAgYm9vbCBo YXNfZHRiID0gZmFsc2U7DQogICAgIGJvb2wgaW9tbXUgPSBmYWxzZTsNCiAgICAgY29uc3QgY2hh ciAqZG9tMGxlc3NfaW9tbXUgPSBOVUxMOw0KKyAgICBjb25zdCBjaGFyICp4c21fc2VjbGFiZWwg PSBOVUxMOw0KIA0KICAgICBpZiAoICFkdF9kZXZpY2VfaXNfY29tcGF0aWJsZShub2RlLCAieGVu LGRvbWFpbiIpICkNCiAgICAgICAgIHJldHVybiAtRU5PRU5UOw0KQEAgLTE0MSw1ICsxNDQsMTMg QEAgaW50IF9faW5pdCBwYXJzZV9kb20wbGVzc19ub2RlKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAq bm9kZSwNCiAgICAgICAgIHBhbmljKCInbGxjLWNvbG9ycycgZm91bmQsIGJ1dCBMTEMgY29sb3Jp bmcgaXMgZGlzYWJsZWRcbiIpOw0KICNlbmRpZg0KIA0KKyAgICBpZiAoIElTX0VOQUJMRUQoQ09O RklHX1hTTV9GTEFTSykgJiYNCisgICAgICAgICAhZHRfcHJvcGVydHlfcmVhZF9zdHJpbmcobm9k ZSwgInNlY2xhYmVsIiwgJnhzbV9zZWNsYWJlbCkgKQ0KKyAgICB7DQorICAgICAgICBpZiAoIGZs YXNrX2NvbnRleHRfdG9fc2lkKHhzbV9zZWNsYWJlbCwgc3RybGVuKHhzbV9zZWNsYWJlbCksDQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZkX2NmZy0+c3NpZHJlZikgKQ0K KyAgICAgICAgICAgIHBhbmljKCJJbnZhbGlkIHNlY3VyaXR5IGNvbnRleHQgZm9yIGRvbWFpbjog JXNcbiIsIHhzbV9zZWNsYWJlbCk7DQorICAgIH0NCisNCiAgICAgcmV0dXJuIGFyY2hfcGFyc2Vf ZG9tMGxlc3Nfbm9kZShub2RlLCBiZCk7DQogfQ0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hz bS94c20uaCBiL3hlbi9pbmNsdWRlL3hzbS94c20uaA0KaW5kZXggOTgwOWUwMDVlMC4uNzNkMDU4 YThiMiAxMDA2NDQNCi0tLSBhL3hlbi9pbmNsdWRlL3hzbS94c20uaA0KKysrIGIveGVuL2luY2x1 ZGUveHNtL3hzbS5oDQpAQCAtMjYxLDQgKzI2MSw3IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCBoYXNf eHNtX21hZ2ljKHBhZGRyX3Qgc3RhcnQpDQogDQogI2VuZGlmIC8qIENPTkZJR19YU00gKi8NCiAN CitpbnQgZmxhc2tfY29udGV4dF90b19zaWQoY29uc3QgY2hhciAqc2NvbnRleHQsDQorICAgICAg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHNjb250ZXh0X2xlbiwgdWludDMyX3QgKnNpZCk7 DQorDQogI2VuZGlmIC8qIF9fWFNNX0ggKi8NCmRpZmYgLS1naXQgYS94ZW4veHNtL2ZsYXNrL2hv b2tzLmMgYi94ZW4veHNtL2ZsYXNrL2hvb2tzLmMNCmluZGV4IDkwMjg1NzQxNWIuLjliMTA3ODRh Y2IgMTAwNjQ0DQotLS0gYS94ZW4veHNtL2ZsYXNrL2hvb2tzLmMNCisrKyBiL3hlbi94c20vZmxh c2svaG9va3MuYw0KQEAgLTIwMTQsNiArMjAxNCwxMSBAQCBjb25zdCBzdHJ1Y3QgeHNtX29wcyAq X19pbml0IGZsYXNrX2luaXQoDQogICAgIHJldHVybiAmZmxhc2tfb3BzOw0KIH0NCiANCitpbnQg Zmxhc2tfY29udGV4dF90b19zaWQoY29uc3QgY2hhciAqc2NvbnRleHQsIHVpbnQzMl90IHNjb250 ZXh0X2xlbiwgdWludDMyX3QgKnNpZCkNCit7DQorICAgIHJldHVybiBzZWN1cml0eV9jb250ZXh0 X3RvX3NpZChzY29udGV4dCwgc2NvbnRleHRfbGVuLCBzaWQpOw0KK30NCisNCiAvKg0KICAqIExv Y2FsIHZhcmlhYmxlczoNCiAgKiBtb2RlOiBDDQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Wed Sep 09 08:59:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 08:59:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412698.1643070 (Exim 4.92) (envelope-from ) id 1x4E9C-0002l2-S8; Wed, 09 Sep 2026 08:59:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412698.1643070; Wed, 09 Sep 2026 08:59:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4E9C-0002kv-OP; Wed, 09 Sep 2026 08:59:14 +0000 Received: by outflank-mailman (input) for mailman id 1412698; Wed, 09 Sep 2026 08:59:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4E9B-0002ko-LW for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 08:59:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4E9A-00EIUE-UP for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 10:59:12 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa11fd6-bab6-0a2a0a5309dd-0a2a4505a900-32 for ; Wed, 09 Sep 2026 10:59:12 +0200 Received: from [40.107.200.38] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa11fdf-4cb1-0a2a45050019-286bc826fe9e-3 for ; Wed, 09 Sep 2026 10:59:12 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5896.namprd03.prod.outlook.com (2603:10b6:510:3b::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Wed, 9 Sep 2026 08:59:09 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Wed, 9 Sep 2026 08:59:08 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=x0FHh2dJQh14VEZ3Zgx9VeJRJLtlfklgNfzCp6/L+dXLOl5f0HO8O9+pE8sgNOy/oIJ3b+4GIeDKC7FwD7yahNW4j7lFOX9ptmqshh7uCIuvTzuDrnFYFIIuSgBbDhkj+xOYdbup0vB/mQKfCUbMHj4ShYnG9j6vLez+GUr8B84iBelZBKg25BL8VQ495x0BkP7ExWIPsLFJmmu7Cp6mtrhHc63JzOj5wpkwiThpF/ROcsjKWHdir+t+vDO2H4tUTdugSwK/tUU8czp1+ovRCfIxmmgttU6faLVhhwlEOMhMrEPz+guGpyvW9XO/0GP829bCRe14lcOX+n9zokLo/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9Ml1cD2jLAbQ1K2jC2vkpy3/LpR8eJ3EBmtmx1sYcAk=; b=ToC/L1Wp9OhpK0x2FrA2nikwbcdMOyqWpdXAdCgVxR+riUjkB+FK+qa18hmavQsYFsqZcDd+0XY/DKmuK5bZmhgRybvvNDLe9Ya7tvzGECfHv+H2kB5Mue0SGih1uykmQ2rb8Nuo5mZ88Br8h6sA2KUzloaaOelWVAeAbuzDuE5g97URPIqhyqJJARvLjRRcuU5gM6c1F66KuPOZCecNi9ekYYHQIoVBV0I0/75+6P7+/TqgwQHdSbzHSiDUNKUHsaYJ4sYBKCqdIxWvbcntNdWmxis94ZMot613/RSJLz+UeXu6/4a+H9XZkWh8WZL43+Nbdzc7dDamsO47xz3bpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Ml1cD2jLAbQ1K2jC2vkpy3/LpR8eJ3EBmtmx1sYcAk=; b=un+YFFTAb9eHIFq9VHrGycE74FPRdt6GyBKT65/1zNjYcwxa4yaBVnPO/huipoWeTK7IYBXjOj8ResWS3cw7FnEaRqoy7HCmgrDwjzvqA1JCyqY/WsHws2ly9sgCXf/L8Nuit/ksG82/8R5vs1i6K7/BX290Xz/8xhcSpF2hmv0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4844d64b-a747-46a2-a9c5-d0f8c3cbbbbf@citrix.com> Date: Wed, 9 Sep 2026 09:59:05 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel Subject: Re: [PATCH 0/3] x86: Fixes for not-quite-XSA in pci_conf_write_intercept() To: Jan Beulich References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> <891c139a-d6b3-4293-8eb5-7c0af82fd80c@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <891c139a-d6b3-4293-8eb5-7c0af82fd80c@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0254.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:194::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB5896:EE_ X-MS-Office365-Filtering-Correlation-Id: ca1a93b5-d138-42f8-8975-08df0e509bf0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|4143699003|56012099006|11063799006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: qJ58pfUx3LX2cdDF+H9JDc0NDLB0P7UixmMnBGnwMimAahk5in3kJvYXyweB+X6kCaFN97LS3LV3dyXszalLsSvL67e1I0w6sWwqFD/FYVw4Ad+dEfjhOMQ/zvEhPih0vWqSmjbJH8ZztGU6JGTlIOg7RZ6OVxPxxkrIgqfImjO3hkoz+2GlT/3pIj8TLZTtO3rp8ggf1u1m1aF4M0BPBMPIVDKWTihMMRTpWejIwXsCntcIDwaKQ9TNHLTaGm2WswIwOrRovuLKoViBYTTKxWoDIQK/eZQK8HP9csIXjeq7kvw0yoXHdajMUrvfQ+g8gVlL9XLEjngGqq5YbJgzy/YlItgl8p0TcGCf6FPfLz57gdgSRqM5yq+MC4/XGvsy4JJK/gtpcsB4cY+fo4Ejp5ystGnpik4ebYmAcycTdEjLNtyJUQUjpmecPqh+RIumNz6r5rS+1LDQNMlGIwhl0GZoSCMhk+PW+/GV4lelk0SlJRHHgJP5WyQE+Qa/mLbnsXsQG/saql8AIXyre5OalpeWcAiUdja927apBFwhbmLFLccXDSZH60OHh7IY7xkphTcmDYjFEELQiIEFIFMeAlS1mNloXZKinTNaZ5jhote/8+qO1TULO01IXW1AObsaquKmV1XqrCjB6qft5Pp34m2HdcLBBNZWTxWyAK78jDs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(4143699003)(56012099006)(11063799006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eCszTzFyR0tqQnltcnFKdGs3NVJ0M2xIcFROOVJEQnE2VXRlMG9pblpBSC9u?= =?utf-8?B?bmRTRGpEZi9NT09oTTlCV1JXeWZiR1l6UTloK256bFpmK1VmTE9PR21pTVVF?= =?utf-8?B?NTFDZmpFVm4xRjJqM0dEWlFaa2J5dnU4L0hLSklCdWRoT2VJU2puSVhBR0Z2?= =?utf-8?B?cVBsMmVFRk83SlphaTVFTlNhK0V0TVJsRk80c1JGUG1rY0VtS0tYRFdSNE1u?= =?utf-8?B?SVVaS2ljcDZXT0tQVWl3blJKaTFzZm5GZXFjOUwraTlQeDBFOXE4RUxFdG5i?= =?utf-8?B?N1o5c1JpVzdnd1BhUExDMyttODN3eHU0NU1mTUg3Y2R1a01Eb29kczdVZm1H?= =?utf-8?B?TjRiSUJ0UlU4cVJ1cFVIdkRWRVpuV2g4Ulp5TEozMGh5UzVsdnpTbDBzc2VO?= =?utf-8?B?dk9GNlI1RGdYS2g5TDErYlg2WXM3NFdLbzRmTmF6dTVWQ3lMbWUwUy9vNDBU?= =?utf-8?B?Zk9GcG0rcE9qcElWTFNhaXp6M3N6amhoMldRbzFsUENBMGQySW93YjNxVEF6?= =?utf-8?B?RDZoSzZNcVlUdlRTOElOVGV0TWhzdk5jVUVyMWg5V3p5ZW16NjBKMWVOQnE0?= =?utf-8?B?QWR4a3NnVUk5M0RJaXNFZE5ZZkJ5cU1XNWhvek1sRnNPQTlsTWNJRk9zL1ln?= =?utf-8?B?VStsemFlcVFoNFErTDhmanVoSFpPa2RDTGNFWFVTNHM5QVNJWEZSbTM3R0pv?= =?utf-8?B?M1JLK2hyS09PMFNBTVlLNUVuUEVHMCthU2MrcXFjSU90R0wvRFQ3USs2dlRW?= =?utf-8?B?QzJ1aUVLUHk4cFJxeGZLUkpzdlF2ZXc4MGNBWENlS0RiaE1PclhoMHFlZ29H?= =?utf-8?B?ejkzWVRsR3VmcmFsalJJY0JIb0xXR0Vzb1hZRUVPNUg2c1FkRWpCV2Ryc2hi?= =?utf-8?B?cXlmRytEeGFrSXpyWWg0Y2h3NGVZQjRGZjdFUnZ0aEFLbHl6RzQ2WjFSQnQv?= =?utf-8?B?K2hnQnRzT1c2a2MyRko4NHArbldTVkYydlZBaElHSTExazh4QXpSMldxNC95?= =?utf-8?B?WXNVWFNJNXlIblhDUE0vbVUrK1lxakxxcmlQakVwRVpNUWJoSEpxMGhkaVA4?= =?utf-8?B?VUZvbWdLUXNRVDBvUXZqZTBua3hBQU1kS01hOURERjV5ZTFJWHB1cXBiUTZv?= =?utf-8?B?ekw4aldqVTE5MnVlUFBxTHpGdkxhRTE4TGMySjR4TGszbUt0dE9vTjQ1RWtP?= =?utf-8?B?dVloTWNmcjJzZzQxb2RnbDYvM0RYNFBrZnNueUhDaXdBTzBvRUxsYUEwN2dt?= =?utf-8?B?cEs2bzY2Wm44eE1OVmtaRjIvUm4rQXlrNk11WVBMdXV0TFhFQnR1WjkzYUVP?= =?utf-8?B?Wjd1MUUxd1VaQ29obnBqa2ZKMSs2eXNiT0htSmcyN3NuOXpPWDNmdW95TWZS?= =?utf-8?B?c01uNVVpUmY4NXlnaVBwQlBUWHJUa2RvSzE1T0pUd21qRWdrZ0ZySUQ3T1RC?= =?utf-8?B?QUdXWG1DbEMyVkRkVytSenhtN0J2Q3hPZFRVS1JNRE5ndVREcHVKdUh3NWxq?= =?utf-8?B?ZmJBMHFoNDVoVEF0aWV5WWpQay96Nm95UnZGSTBNNGZsU1BEbWhpSUNwcUUx?= =?utf-8?B?aFp6WFpLU2tES1VlRDNaMm5BWFE2UG5MbXMvSTR1NzJOYnM5SkdJZ3JzYVB0?= =?utf-8?B?ZVBhTnBUOHlwZ2xld2F0aUJ2M2hQTTVCZmNCQ091NG9adVAxbStFektRSGJJ?= =?utf-8?B?TnJ3aXRGVzZCaXJZNGw0ZjF2dzc2SUFlUGpmaGsyNGxTNmg3WHE5QmRyNWdK?= =?utf-8?B?ckZ6M0pYSFFRWEduWjVYVEZ1TEVCUnBsYjZGSVJsYmkyTUg0U0YrUFBsTHlT?= =?utf-8?B?QUpaRjdxNXJOZjRQVUhHM2k4VmpUMnZiTUhReXYwTFprdmRLMEYrQkhxTFNO?= =?utf-8?B?MnNlM2kxSFd6QzRMMjNPS28ya0tQd2lIZ05ZaHBqaElxSGh6S0xTSEYvTkw3?= =?utf-8?B?SXhtS1M5Q0lTZnVRWWY4RFNYVDhBc3NNVnNwUFFGK1FIbzJrNmhkTnFGSEll?= =?utf-8?B?ajBZUitPc1pkTUE2aE1sWGNrUWFTTndPNUh6TlpaZXV2cE9KbVdJeFNYR083?= =?utf-8?B?MmpQMlB5ZkxZSDd0ZmNKNkcyWE11Z1IxVGtPNUFrL25paHdscDNLVkZOdGkx?= =?utf-8?B?ZFcrSXZzVGFuWUIzbmc5c0Zpem9DSVV5a0xCOVFOWk81OWhObmhBWnYxZXdP?= =?utf-8?B?ZjlFRitONnVLR1FPTUpsSVZYQW9RZmtzVHdPbkI1WDZaQXBRMlgzUmpINmtm?= =?utf-8?B?R29WVldoYTUvMzM4ZUNLUVZHWHEvcXdBeVhRSk9mRWxFdmYrTi9RY0RJckp4?= =?utf-8?B?djlidHBvRXRyaWc4LytlajJEc1dUSCt5ZzdObmx5dkpGd08xTWEzZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca1a93b5-d138-42f8-8975-08df0e509bf0 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 08:59:08.6942 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: kwEAFAZmztYdfV35E1OYFdSA3eEh9zMlpPWvF/3n9VctKOo6bTVA69FBmXzc3ek2Wdwq3eBgWq6DDS3/gZmkUjGJWig+d8z5yTdmRQA3ijE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5896 X-purgate-ID: tlsNG-c201ff/1788944352-24F1F2A1-78DA86F6/0/0 X-purgate-type: clean X-purgate-size: 684 On 09/09/2026 7:39 am, Jan Beulich wrote: > On 08.09.2026 23:57, Andrew Cooper wrote: >> Plumb pci_sbdf_t up and down the callchain to simplify parameter passing and >> make it harder to forget the segment. >> >> Andrew Cooper (3): >> x86/pv: Convert struct mmio_ro_emulate_ctxt to use pci_sbdf_t >> x86/pci: Convert pci_mmcfg_{read,write}() to use pci_sbdf_t >> x86/pci: Update pci_conf_write_intercept() to use pci_sbdf_t > Reviewed-by: Jan Beulich > Thanks. It's worth saying that there's also some cleanup to XSM wanting to happen, but I'm going to wait until your series is fully in before even starting to look at that. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Sep 09 09:01:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 09:01:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412705.1643077 (Exim 4.92) (envelope-from ) id 1x4EB0-0004If-5X; Wed, 09 Sep 2026 09:01:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412705.1643077; Wed, 09 Sep 2026 09:01:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4EB0-0004IY-2P; Wed, 09 Sep 2026 09:01:06 +0000 Received: by outflank-mailman (input) for mailman id 1412705; Wed, 09 Sep 2026 09:01:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4EAy-0004IQ-VS for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 09:01:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4EAx-001auO-Ut for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 11:01:04 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1204f-8faa-0a2a0a5109dd-0a2a45018fb8-6 for ; Wed, 09 Sep 2026 11:01:03 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1204f-5984-0a2a45010019-b9ff1c23a10f-3 for ; Wed, 09 Sep 2026 11:01:03 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a085662958000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 09:01:00 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 9E82481013; Wed, 9 Sep 2026 11:00:57 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=yiA8qUMkmKgdXDhxRU1HTaWcJZ6ST41EmhPuoXyPNyg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=sYrWCzXuJurcejsfLqEuReIRsSvkayJPi9QwWdpy8ukNcW0YawIylyNBfdotrjd7n3IGx5UtW Qdlie9KD+UBT/Yutvs3lg0ifQPIQujBv0iyatfpSF61NbC7RuHUZJTvKuo6x/4fiFHBbIemCH7m 2CBiOU2fzHujFOdFPguAljwl/XAEtPTOh86WFzX/PdIL2EHyadHF+1/XfQi0ARoUdTAfD9n5z+k 6NO4y/zCgWtQID4R7Q27suksAUukS61eXb8MebNg1ynw4FbdVi5RYKKchJcPinEyk2cVKkwPHio TXv8waUxukRlGw96pf1pfMVM/gXEUV8AqHbl9uEdlkwg== X-Zone-Loop: 3e4384984ceecacb8e3380b6218184d147acdc5003af x-campaign-type: default x-transaction-id: c7ebb5bd-b1ac-4e02-a45d-8a5ebeacf7c1 x-swg-uid: 01-4d20a89c-3281-4182-b694-84e1555d0e2c X-Mailer: Sweego Message-ID: <1788944460.8631fc262581453bbf619ec5b2062170.1a085662958000c4f3@vates.tech> x-swg-bid: 1788944460.8631fc262581453bbf619ec5b2062170.1a085662958000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 9 Sep 2026 11:00:57 +0200 From: Anthony PERARD To: Mykyta Poturai Cc: "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v9 5/6] tools: Allow building xen-hptool without CONFIG_MIGRATE References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.a.42c3cb8910d3e9bd.1a085661ff5.d0e6a0c84c99f504=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788944457721 X-purgate-ID: tlsNG-d62444/1788944463-1DE78757-B86C331A/0/0 X-purgate-type: clean X-purgate-size: 977 ---=Part.a.42c3cb8910d3e9bd.1a085661ff5.d0e6a0c84c99f504=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2026 at 08:48:31AM +0000, Mykyta Poturai wrote: > With CPU hotplug sysctls implemented on Arm it becomes useful to have a > tool for calling them=2E >=20 > According to the commit history it seems that putting hptool under > config MIGRATE was a measure to fix IA64 build=2E As IA64 is no longer > supported it can now be brought back=2E So build it unconditionally=2E >=20 > Operations specific to x86 architecture are moved into a separate file > and only built on x86=2E >=20 > Signed-off-by: Mykyta Poturai Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.a.42c3cb8910d3e9bd.1a085661ff5.d0e6a0c84c99f504=--- From xen-devel-bounces@lists.xenproject.org Wed Sep 09 09:07:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 09:07:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412713.1643087 (Exim 4.92) (envelope-from ) id 1x4EH4-00058s-QD; Wed, 09 Sep 2026 09:07:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412713.1643087; Wed, 09 Sep 2026 09:07:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4EH4-00058l-Mt; Wed, 09 Sep 2026 09:07:22 +0000 Received: by outflank-mailman (input) for mailman id 1412713; Wed, 09 Sep 2026 09:07:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4EH3-00058f-CD for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 09:07:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4EH2-001cKP-LB for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 11:07:20 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa121c8-e002-0a2a0a5209dd-0a2a450cb05e-0 for ; Wed, 09 Sep 2026 11:07:20 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa121c8-f479-0a2a450c0019-d155802ec4da-3 for ; Wed, 09 Sep 2026 11:07:20 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49a97714f5dso54963035e9.0 for ; Wed, 09 Sep 2026 02:07:20 -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-49d20fce7a7sm96338115e9.4.2026.09.09.02.07.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 02:07:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788944840; x=1789549640; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=iHE8jaulGAEwrLHrzoGfPszK91vl6DFnbrJHVc6I92I=; b=grMmu7lHpcC79K2lQ73N+70kLLE7Vt2EfqpAF9WggKm31ZaW7ilzqlt7ccd2dYRjXC 7bFAm6y9JVOoGRxPfFjUGpQvsstXIzg/QvZ0tRSaqJdETvc0ybBe+RBxWodFrm2cTLRF PzmWWF14ifUWQDA5u+nMoJSBejwd43Fiicv5xXygDDZkeybftatdTjK9Wx1954JJOMWI KEopzEXRqe66NyHun3RAFblAXh3M53rv+sOIIRvRiZC4fB/WRzVQPecS5YxHN5U7USsF uNWzrpe7AZO5BsrEcK6Ri12VbqQyeRNGv5eYEPEemV3jRg2jCIfw0VC4fLI7yFneokFX uUPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788944840; x=1789549640; h=content-transfer-encoding:content-type: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:content-type; bh=iHE8jaulGAEwrLHrzoGfPszK91vl6DFnbrJHVc6I92I=; b=ll3MhStdI2Vo5Wi5sAAyHr9uGdhJuvLoetvvP23PlmJEjivoLRiDDvlhtOOAmX58Xu HA2e3efsZyl0CaUecVYuGMz4T3lEwR4GtbcC7NMhyaanLqJdZnXcu+4OQaR7Frd1CX79 QgM0arER7Ta2lhCIIXIIXxvc9PGB5hejgIBN6QBxqbEH2twwlPyJP1oKAF7UsFef+jV2 IRVIaZLtJb/axdm3Hh+OQnx4JJTDkZXWAa+x9yjjZrst+rmgGXB8tkSRxuiTIRebse36 s2Tm50yAz1mvhHvWnl283U/qhuKVnaUmhlwFzVqEJIG/zdZbUFdGNtFdTE4iB0NISP0T lwFQ== X-Forwarded-Encrypted: i=1; AKwUvBxvua0zZva00IVhg7zOU4rKaHJL/yxNlVJDGk8s2VMx6b0qFn+M07trQcT17usN557Yw3d84v93KT0=@lists.xenproject.org X-Gm-Message-State: AFuF++moQ3jQ81BeAdI3XLLBID8OL09NQCfvSvTN9GLoKsb2hYd8Woef TQd+D+v8GCaJT9/2OcMFPFcvGdB0rAeSJR3Q7PrQ2wxP4dwg2Y19PT6cxg6i7amXRw== X-Gm-Gg: AYBFou0SQeIebH3c6Z+NgV6Rv+MMKFMNOnLy5xYIAFsq7x4WsXIHc+vRJ+s3n5cY7k8 nudskF1+05aYXsVVkAdbEYpNoK6JmudbbM3oG4zJiGk/BHcUhI0PvVqrk02Nou6dh8Ta4jz2lyS wKAplXuGIHPAr4onFDpQekAEJOqOqRzinxrEy7t/LrOIJCYcUCglcvH8hMWcwCSIuWCpPPQSPou 0NCfcM2LVDsSOtO5/vZRRp0OlpH2tQJpO85qTc6MGTavwdRl9Kf25u+rdJzzl19qW3uEV2iIMVE 4ih/jLp+UeEZfq/aGaQWznPATlpwjqnPESKW7zTp5tz6YEGm8B+liTIWNzZQhGs/zPMsxnqnrnW 9i0fytjE0W1QZaY8+Wk4JHlT9MAD2dXrvpXf259RSUd2kYNfkxHIMGNPb8sXIA0XybMKKKCJBta oaRwjGQWxOxo7oY5av9g4PkOkewzDZn5z1ZtnTPz3qqB6SwBef3CGF6lH04B3/AduuwEuSZEdn1 hgJULj5o6jumEPXJNzWdpnJ833fko504+dg3ZrZ4loMRycq1JJgV2FSQI+P9y8= X-Received: by 2002:a05:600c:3544:b0:49c:f5c0:aa79 with SMTP id 5b1f17b1804b1-49cf8244bd0mr349787475e9.9.1788944839835; Wed, 09 Sep 2026 02:07:19 -0700 (PDT) Message-ID: <3f2bb6fe-a517-421f-adb9-c33d67ef4591@suse.com> Date: Wed, 9 Sep 2026 11:07:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] common: dom0less-bindings: introduce XSM labels To: Sergiy Kibrik Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , "Daniel P. Smith" , Andrew Cooper , "xen-devel@lists.xenproject.org" References: <20260909085707.2359322-1-Sergiy_Kibrik@epam.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: <20260909085707.2359322-1-Sergiy_Kibrik@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788944840-77AD4A5B-742F1EC6/0/0 X-purgate-type: clean X-purgate-size: 674 On 09.09.2026 10:57, Sergiy Kibrik wrote: > @@ -141,5 +144,13 @@ int __init parse_dom0less_node(struct dt_device_node *node, > panic("'llc-colors' found, but LLC coloring is disabled\n"); > #endif > > + if ( IS_ENABLED(CONFIG_XSM_FLASK) && > + !dt_property_read_string(node, "seclabel", &xsm_seclabel) ) > + { > + if ( flask_context_to_sid(xsm_seclabel, strlen(xsm_seclabel), > + &d_cfg->ssidref) ) > + panic("Invalid security context for domain: %s\n", xsm_seclabel); > + } Is there a reason this isn't a single if()? Also (nit) the one wrapped line is mis-indented. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 09:22:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 09:22:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412725.1643095 (Exim 4.92) (envelope-from ) id 1x4EV8-0008Mp-Vj; Wed, 09 Sep 2026 09:21:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412725.1643095; Wed, 09 Sep 2026 09:21:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4EV8-0008Mi-T1; Wed, 09 Sep 2026 09:21:54 +0000 Received: by outflank-mailman (input) for mailman id 1412725; Wed, 09 Sep 2026 09:21:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4EV7-0008Ma-UE for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 09:21:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4EV6-002BZu-Ow for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 11:21:52 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1252d-8faa-0a2a0a5109dd-0a2a4504a2f0-16 for ; Wed, 09 Sep 2026 11:21:52 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa12530-b57f-0a2a45040019-d155802ed49a-3 for ; Wed, 09 Sep 2026 11:21:52 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49954b88fffso41758295e9.0 for ; Wed, 09 Sep 2026 02:21:52 -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-49d057f4778sm356877635e9.8.2026.09.09.02.21.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 02:21:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788945712; x=1789550512; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=RvTueSMmC85xvgISAk8rclCvuKn+yoZ+BpUvFMd4JTg=; b=fi5UEjUKo3BU+HKxYxZ1B6uPNr7hB+su2QsUhPzIqAAdRAWUWtCe4ZyVvG5CjoY+Qp Ge9sCEEov5X1YieHj/LOtVYonk3kJd0QGv6Cn7AWVNr+GekT7ema9/tZ9O0cszzyG5lr rUuOjlC/kjb/d/yKLzwu+hkM1aTJfYdx0AcXJi1yFw6vo8+ajoF602FrV8cYGsRrA4Cw VEr5xrDU19Nsg/lbeTUoXbJ8L7QbpJ2iT0StpN4pBmSlpWFA8DJ5IwuSJqGZvvkW5Snl CFOVTOMqA2TGLYMfWiMkH6SZpu9zQDazwmcnmghIaQiEgNbspQpEaSchhwHrz1OjRN3C hEOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788945712; x=1789550512; h=content-transfer-encoding:content-type: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:content-type; bh=RvTueSMmC85xvgISAk8rclCvuKn+yoZ+BpUvFMd4JTg=; b=G2KtXIY9wT6GjqKu0acUNKQcG04LPARM047OlCfXrMrve75tz8gyYtrtE1P41tO0aH c0rl3YDc5lL8AQ5eQa0mecY5uHFcgSgkqgZn2ZFx2LvIrUD+xQhEkb9zMiUFwDMu21gp Rs/+SR/4+kJF+v3xWLbtojEauvG1BkP7RMILqnVD31Ldwu8BO9s3DpnlOOGXw/FOfvzZ GFbN72BE30kiKwOqwd34T+OObDL/hJtL/UoGBsucn0GGtJCICpfA0maQ51DwQkI5EMCU GOs48228yh8P28q4JYQ4pJnCx7Z+ByyN688+vCwk7zyAjtulfSof8LhmRHdJ4rjREOph J1ag== X-Forwarded-Encrypted: i=1; AKwUvBwyXTxR7UHCIfcOqyG58xf5E91FT8UjUu9yN89LsZU6PCk2KA0n/KCwqMu/NtBpVMSZj+OHxrlCFZA=@lists.xenproject.org X-Gm-Message-State: AFuF++kgKUH58oC3BKzIcp19Vew6STyH3UjP+0BICnN0iO+MAJOqJ4Mb ylMX+LJSiXZpb56RwqQvTTDy0OaqPpz9CH3dJ5eXDzCvwSUEpI156yq5Gq6WFfww9A== X-Gm-Gg: AYBFou2GVPCyn3Oxsy7mVvbqcepEyf830dYVVtonsA89GgE07fnVpOkUKDwZnWjwN+x oqPwKJ9FsB4CfBNX1Re1GCPiFfhxML3rFBerbODw3ZwJXi+bEsg8KnLLuR285vdSjoJeGODHjMJ k984+Vqd+G0MpSula7yD2cAeiLr9nIMBmAneIoFPECQky8o+zs5O+RPYJrM5q6E35Q5TO4FVYPM haRwV5BkPc5c7Qc+qEP1KuvEoYVMBeog7JejGADQ/RSNXeOpSJ+VZUlD2ercr+sW+yx8FFGB1qx gbebD07ULAcBkUJ763kiJwh2iEGEyNEkcYazXmwcVpkkt/HMANbVKbnvgr/HNR8GPzjsQOsKmWb d2yIzsm3P6tZMh4UVY74f/p55eez8uVWrzscQRkCz75UCwJubrUxrV0N+tcYldWYceNfm2f+Yv+ JRBHj4nbegcZ1qYXWT3D4qZKuToli8DDO7AllxJsUHCec/IkGLYg3BYtyPUFJqIuvALnvIjAIBv xpnDgWS4L6GXSgr0kiMf5VeOZyZOWKQ2lI9A2uwAg6pV/wRejmdNzcCM667BCc= X-Received: by 2002:a05:600c:4fc8:b0:49b:5521:785d with SMTP id 5b1f17b1804b1-49cf81e6783mr358762005e9.4.1788945712058; Wed, 09 Sep 2026 02:21:52 -0700 (PDT) Message-ID: <1cadfc6c-efc1-4e23-b778-1df97fd0fa4d@suse.com> Date: Wed, 9 Sep 2026 11:21:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: limit deferred TLB flushing to PV owned pages To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260909072451.67324-1-roger@xenproject.org> 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: <20260909072451.67324-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788945712-510DDB50-56FEFCC5/0/0 X-purgate-type: clean X-purgate-size: 1240 On 09.09.2026 09:24, Roger Pau Monne wrote: > The current logic on x86 will mark all domain owned pages as needed a TLB > flush before being re-used. However such TLB flushing is only strictly > needed for PV domain owned pages, as those can keep a reference to the page > in the TLB after it has been freed. What about HVM-owned ones which a PV domain has grant- or foreign-mapped? > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -1501,6 +1501,7 @@ bool scrub_free_pages(void) > > static bool mark_page_free(struct page_info *pg, mfn_t mfn) > { > + const struct domain *owner = page_get_owner(pg); > bool pg_offlined = false; > > ASSERT(mfn_x(mfn) == mfn_x(page_to_mfn(pg))); > @@ -1539,7 +1540,7 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) > } > > /* If a page has no owner it will need no safety TLB flush. */ > - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); > + pg->u.free.need_tlbflush = owner && is_pv_domain(owner); > if ( pg->u.free.need_tlbflush ) > page_set_tlbflush_timestamp(pg); Imo whichever change it is going to be here, it definitely also requires the comment to be kept in sync. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 09:36:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 09:36:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412747.1643105 (Exim 4.92) (envelope-from ) id 1x4EiZ-000206-5S; Wed, 09 Sep 2026 09:35:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412747.1643105; Wed, 09 Sep 2026 09:35:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4EiZ-0001zz-2p; Wed, 09 Sep 2026 09:35:47 +0000 Received: by outflank-mailman (input) for mailman id 1412747; Wed, 09 Sep 2026 09:35:45 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4EiX-0001zt-BT for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 09:35:45 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4EiW-006Nuy-1H; Wed, 09 Sep 2026 09:35:44 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4EiW-000bfd-2j; Wed, 09 Sep 2026 09:35:44 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=329bJcs3GTBUNSLxRj8qY4RilkncelvMpWFDZDKA+2I=; b=hLbGOGdB1xXE3CuBFY2pWNdOjj ThgwJ0SJ8OO24bIaZQ8ieXFjXyYVh3QX6QZyCbgIl6G3PqnrhU6xORFfGq+H1qXMAok70JfiyhSRq nBGzlFTTYMvqR6lmazM1WQvOvOuRcCWj7EiblsXFEKL1q8DPQ9U/t8xxgWKTsfvs0ep0=; Date: Wed, 9 Sep 2026 11:35:42 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Teddy Astie Subject: Re: [PATCH v3] x86/ucode: Work around Granite Rapids erraturm GNR98 Message-ID: References: <20260908171525.3196765-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260908171525.3196765-1-andrew.cooper3@citrix.com> On Tue, Sep 08, 2026 at 06:15:25PM +0100, Andrew Cooper wrote: > Block loads which are known to hang the system. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Teddy Astie > > A more complete solution is in the works, but it's taken 4 months to get this > much published... > > v3: > * Double XENLOG_WARNING > > v2: > * Correct the sign of the cpu_sig->rev check. > * Expand the comment to explain why we are not following what GNR98 says. > --- > xen/arch/x86/cpu/microcode/intel.c | 40 ++++++++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > > diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c > index c45b00c6b033..86cbfb798160 100644 > --- a/xen/arch/x86/cpu/microcode/intel.c > +++ b/xen/arch/x86/cpu/microcode/intel.c > @@ -27,6 +27,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -273,6 +274,44 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) > return false; > } > > +static bool microcode_safe_to_load(const struct microcode_patch *mc) > +{ > + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig); I think this could be const? Or are there further changes expected that will modify the signature? > + > + /* > + * Treat pre-production as always safe - anyone using pre-production > + * microcode knows what they are doing, and can keep any resulting pieces. > + */ > + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) > + return true; > + > + /* > + * GNR98 states that Granite Rapids systems hang when loading new ucode on > + * sufficiently old firmware. GNR101 retroactively states that one ucode > + * had an incorrect minimum revision field, in light of discovering GNR98. > + * > + * Both are incomplete statements of the problem. > + * > + * At the time of writing (August 2026), the believed safe sequence is: > + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later > + * > + * Disallow known-unsafe loads while permitting believed-safe loads. For > + * GNR, this allows multi-hop loading to get up to the latest. > + */ > + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && > + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && > + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || > + (cpu_sig->rev < 0x01000405 && mc->rev > 0x01000405)) ) Given the logic, I don't think the CPU needs to strictly be in version 0x01000370 to update to the [0x01000380...0x010003f3] range? Maybe you want to replace 0x01000370 with "any previous" to match the semantics used in the tail of the sequence with "any later". In any case: Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 09 09:58:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 09:58:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412760.1643115 (Exim 4.92) (envelope-from ) id 1x4F4h-0005NS-VF; Wed, 09 Sep 2026 09:58:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412760.1643115; Wed, 09 Sep 2026 09:58:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4F4h-0005NG-QC; Wed, 09 Sep 2026 09:58:39 +0000 Received: by outflank-mailman (input) for mailman id 1412760; Wed, 09 Sep 2026 09:58:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4F4g-0005MP-OC for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 09:58:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4F4e-00Ct9H-AX for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 11:58:36 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa12dbe-e002-0a2a0a5209dd-0a2a45018642-30 for ; Wed, 09 Sep 2026 11:58:36 +0200 Received: from [52.101.193.25] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa12dca-5984-0a2a45010019-3465c11994dd-3 for ; Wed, 09 Sep 2026 11:58:35 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB8327.namprd03.prod.outlook.com (2603:10b6:806:462::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Wed, 9 Sep 2026 09:58:18 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Wed, 9 Sep 2026 09:58:17 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ojtBlAb3BUSkolcT7BkfANnY6Osx91Tlq75PoczCq6hpwyYpEevfjFS37NTCuaG1/1s0/kukAuIngQW3udNtE/6dJODRkoJLW9HWHdTac0aiAWKzxLhrrE9baqfbjOAh5Ypv+gB/0XLG67A9IErDvO7Nc1s9qT5SQ9qeIbxfhbpNPeCBtsBK+W/oxxEAffrZPCOeAtBoLtuhuQR8vHWOaikFhbMuU1kWLokD8lq3ZO0Dxj/rW75ArtDV3KzgrqEZBOL2Rq986o28V+GC5A7Y3zZ2Ft5yzpOTtnRg4/7r9uF1X0s0KnqM73sZ7wFRHfd2iefF5w+atjAfK1KKh0zLWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NE3GfjM+oOCpbHQ8qwGPZGtvfiPbjSSwpc++0eLKcPc=; b=bZcYY7/SmWEGi0LOmpFlfcM5MuZgGRnNerK7Z8ZUx91x+afwDmACt8JY3+IJi+8XUJ9yscNyyebdUAt6fU3IF8lNSWr5mUQgqtv5nPRzkW+FTTHRs+9g+oRMF9sbW+6kiwAVVCBt5Eq0udMvxio+Aa2dFz9Jekb/b9fW7DP4atVRd6iFaZZwbWUEzFm+0hb3FMusJszpjPujoatfRWFhHxUVucAzSI0CPggHVxbcrbRxDttX/XUkmKolmMLyVr7NtE9SlC9Lj7Ikp14QpvgWEDa2TWeM6zk1UNMeyX3D+3yKzjW0SHGZEYEzlAPaxOyunPWUCGLvpuwjA3PHYgbYXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NE3GfjM+oOCpbHQ8qwGPZGtvfiPbjSSwpc++0eLKcPc=; b=Pa8O4Tn37W8XmEb1MWpn8bZm5wnRjq+bfeK4nhhMopG+WhA7YXYmWRCjWUY+ai2Qk9Sj15h0CnR8Tf5XbtdREzE4xqZy4BMrAqH6R/GEGJ9pU9bljB+Pku0YptldkuHvsYeKB3Td3QHksByW8xYHW61v3QeseJx7QS5K3oc3Ai4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <07a6219a-d591-425e-bdd9-07ed20d59d78@citrix.com> Date: Wed, 9 Sep 2026 10:58:14 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/mm: limit deferred TLB flushing to PV owned pages To: Jan Beulich , Roger Pau Monne References: <20260909072451.67324-1-roger@xenproject.org> <1cadfc6c-efc1-4e23-b778-1df97fd0fa4d@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <1cadfc6c-efc1-4e23-b778-1df97fd0fa4d@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0417.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18b::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB8327:EE_ X-MS-Office365-Filtering-Correlation-Id: 6347ed21-4858-4b6e-6423-08df0e58df6a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|10067099003|56012099006|18002099003|4143699003|11063799006|22082099003; X-Microsoft-Antispam-Message-Info: QjZc40STJ3SnEI1btZGs7/tUpN/ABXCVZ/7ihqKptqOD6s4GCO1tcZfu57OhniE1FlqWvhg/opR1H/V6hfAF6gTbLjP1U9rQXW+LAPVyQGm0g5G4b0QJq/qp3CfvNMUy/Sia+RDq3lO7waeOX4nQcLLug3FOmLCxkdURdLp6UVSJi1mi7s1UxclGBAoHvwiNmt9OR4XfnIhtNXgjXMHFKl2RV3zMk/+o/AdiCJbAC1WUb7eI7Gm1/czyTkb6iw9uHkR0RNCVRBJRB6VYdutT9WvMzjhTbGOtdjcjuAqoxOK2NdxG++rgfLzTZAW9u4JerY3OhP9Gf+BFye+lpWuCDxBIINKpYlR6G4npMeRCy27m730GYlYW+ImmTDhkpx4iA6tVqCT0jq3x62eZ8/EjSZC5TPrh7vIRFALSon4k74be1DJvGXJFrZZcLXwoapieTSR1ZFkQamK/9N1W1lcBSWoLCV3Vi3gYEcLe2lP4MspZmASdc8rhOjuejI3WP6cXORDzkkHUw7m3etPtJ9dtWzvmAqu2aE3+CRxo+c7pFwLfnPDYjfN4Ezy/2D74Omj8Krhex1l8pDkH+LCbzt5aVKDx2tC64AwtV/gPHjiCjNuJy5lwuak9vwrQE6Pex01Jt75Irw4jGthamS1c2ng9lp5BF+BwY6Mu/zbQlemH3gE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(10067099003)(56012099006)(18002099003)(4143699003)(11063799006)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bWhSUGlSRjJNUTNSSHFaSE9UZGhNSTYvYUhxNkZwZThtK0JtbXVYaXJzbnh0?= =?utf-8?B?VWQwTGpzS0RvYXJTYTE2QkdWUXNFRFdNOENraE1JWmJ1MXd3TjUvYndxS1gx?= =?utf-8?B?dkNBVjlBeks4WnJMR3BWS1g3MWpPTkk3d0R3NzlRRmJ1SUE2Y1Y5bzdVZVhW?= =?utf-8?B?a1p1enpLNG9taUFIaDVzT1orc0ZQMmhLa2wzVkhjQjg2MTV2OTh3NW13N1Vl?= =?utf-8?B?UlBFbE5CWVlIcnhWT3QxOUl0OTVlOU5oS3dyQkk0em8yUWJ5ZVNFQTFPSDF5?= =?utf-8?B?WVJlNDJwRWQwaXpPWXBrZGRyVUw5Z1VxQzY3Ni9nMVlMOWxSc1MyUjdYYjBZ?= =?utf-8?B?NERCT2dacFQ1YjVYQ0NWNkd0TU1Gamc1SU0wNWM0czdPdnYzM09tYkRPam1L?= =?utf-8?B?cEM3dkhpUUVBNlFsMkdXMkFpWjZ5Ry80WDJqd1pmTFRDVWxWS01LeERUSDJa?= =?utf-8?B?eDVMUTIyNXliMVdTL2RLMHRQOElGdzFvSlpVV3IzNjd6M3AyTlFucXZmUFlt?= =?utf-8?B?a05GeUpXV1g0RWZXaUtVYmp6VGxlZlBGNGRNODUzQjU3azZWS0QvY0V2SHc0?= =?utf-8?B?YmRCUEttZHZ4SXoxK0hERGYxNzdNUVZqZU5YRW1FNGtvZGwrNEY1YWdLcDJq?= =?utf-8?B?TkwrVEEyZ1JDaHk3L0tCV2xSbmY2NWpxcGJGajNvOWZEa2RjalJ2a29LQmFn?= =?utf-8?B?ZStCWXo3djZxVXNiUXZEVmx3bktEeWx3UlNvQVhHMSsvZldwV01CMkZjRXN4?= =?utf-8?B?NW9NNzNabC92dUIvUFk0TDU0MjBCK29SUVBEYkt0UlhLWWtUbnZTUUlYSjBZ?= =?utf-8?B?eURZc1R0Z04wdDlDdXNTYnlIZCtPZjB0Q0hlT0JESVQ4TU9TZGZMcVpIdUU2?= =?utf-8?B?RWlhZldTTWRTajlUU2kyTkY0ZWI4UzhLVGx3NEtQU0xCMGthTkpCL0FVa2c0?= =?utf-8?B?a2VsZjFUVS9ncVN4eXhGVGUyV3BUVGZCMDFiYm5jdUZDYnhkbjBFZGp3cjU1?= =?utf-8?B?eCtWVmUwNThzb1cxeUdpS2dlb1lLcG9leTVPSS9EeEdjeDhTMmdrL2JSbTJx?= =?utf-8?B?Znl0dE1nNkZaa1BEbWZUL2lFSEhic0VrdlBDUjU1U3NQMGo4eGRSRWZhK2FH?= =?utf-8?B?UFJoR3R5ZTVhMksxdEVXT0V6VDk5LzZEMk5QZjE3dldNN2J1c1cxYUFpOFRa?= =?utf-8?B?YzZDejlGZ0s2QkRTSzdzUUdBQlFTOWtVc2VsaVhEMWJ2bHVPT0dac1IxT2kr?= =?utf-8?B?ZHlDVlNTejEyQ0pGa2g5ZEdWVnFyTUFINWEwTDgvWDEzU0l2V3VUZ1Y4bzc1?= =?utf-8?B?dGxFaW54Ylg4Wk5aQXAxRkttbkNJMFFZSi9OeCt1Rk9ocHRvQy9walpKVmZm?= =?utf-8?B?NVdEKzhkRFJCdFN6bnd6RWVaR2FlT3ZyM2NLTE5SNGtVb3lxOW83TmIvMkVn?= =?utf-8?B?MUZxTXhCZEN2amVpZnYveWJkb2NlZ2svNndWc2s5UHR6dGRBMTFwVTJLZE1O?= =?utf-8?B?VkJsU2FaYVExMVZ2L2Q4b2VZTGthQnh6Kzd3eitNQ3BFMEhjaG13MHhSM3k1?= =?utf-8?B?T09UTUtXK0YwOGFEdTNqZVl3bjdZazRzeWdCK2NVcGJrTERnem95NnB5aVhX?= =?utf-8?B?bHcvdkI4U2hDNjN3NFFMRzhGcTgwaVVDU0NjMFFOOEVSYzZ1Z0sxRmM1cVhJ?= =?utf-8?B?VkRiZnBldHAxWmJ2aGsyUUFZWmtJOXFHc0NzWGF3TVNSV3Z1R1ErQXJFZzY2?= =?utf-8?B?d1V3TkVYQnJtYmhkaEVJZ0xxU0JGeS9QWkJucnRWNDY3dUxXUzN5ekJCYVlO?= =?utf-8?B?c0VBQnJzQXJ5b1ZiNWRXMStBdVdubkVjNmtxWDlDRFlBazVNem9WRU53aklv?= =?utf-8?B?UmlPRVl6QTI5MWJCcXJMYWJ1OG5ISEY0YzkzaWZVSERuSjVCcUcvakVOUS9K?= =?utf-8?B?clJRYUE2UlR4VzhkUVU3SUFKL0JkRTBWVUlMNXZZajdLdFdRQzBJdG1ab053?= =?utf-8?B?T1krTWxka1Y0d01VdEN1U2t2RUpjUU5HMlA4UWNkK0YvQzViYTZPYkttWmo3?= =?utf-8?B?dXJQaHRQSmdnc1c3bkl2N2o3c2hEcWkvWHgwQ0pXM3hmWnVTMXJpQk05dDVq?= =?utf-8?B?NXRsRkFQWDBzbFRYbzEvVk1BOENVUmNTRy9pV3ZzcDFVL0VvVk9vdFQ3dEdB?= =?utf-8?B?WVExVFVOQXhVM0FZcit2bzFmQmFhMUNTc3pMM21QYW5pV1RPWS9tbTlaQmc5?= =?utf-8?B?UmphQjBtdUdaME1FRzFGZnBzYlVNQVBDd1JBUUtxNlhaTWFEditRN0pSbUFz?= =?utf-8?B?WGtOdElralVpV2J0ck93UUE2QUNkV3BudnBUWkNCMTZHNE9QbSt3QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6347ed21-4858-4b6e-6423-08df0e58df6a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 09:58:17.8731 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1efPZoMOILJJhq3YNW+UX27EL2+gTj5h3MlVeSt5ri1ZV0F4mtSkhXfOMwu4OZvdSkb5eg0Xql077Oj7cYUrEfzxeEN7ztCEeoMW39IXH3Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB8327 X-purgate-ID: tlsNG-d62444/1788947916-1D272757-F691864F/0/0 X-purgate-type: clean X-purgate-size: 653 On 09/09/2026 10:21 am, Jan Beulich wrote: > On 09.09.2026 09:24, Roger Pau Monne wrote: >> The current logic on x86 will mark all domain owned pages as needed a TLB >> flush before being re-used. However such TLB flushing is only strictly >> needed for PV domain owned pages, as those can keep a reference to the page >> in the TLB after it has been freed. > What about HVM-owned ones which a PV domain has grant- or foreign-mapped? If a patch is grant or foreign mapped, then it can't be in the process of being freed. I presume you mean "had been grant/foreign mapped previously", and with that, I agree with your concern. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Sep 09 09:59:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 09:59:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412764.1643123 (Exim 4.92) (envelope-from ) id 1x4F5D-0005nM-3v; Wed, 09 Sep 2026 09:59:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412764.1643123; Wed, 09 Sep 2026 09:59:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4F5D-0005nF-1B; Wed, 09 Sep 2026 09:59:11 +0000 Received: by outflank-mailman (input) for mailman id 1412764; Wed, 09 Sep 2026 09:59:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4F5B-0005mx-JL for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 09:59:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4F5A-002JkT-IK for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 11:59:08 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa12de3-bab6-0a2a0a5309dd-0a2a450c99e0-20 for ; Wed, 09 Sep 2026 11:59:08 +0200 Received: from [40.107.208.61] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa12dea-f479-0a2a450c0019-286bd03d53f5-3 for ; Wed, 09 Sep 2026 11:59:08 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB8327.namprd03.prod.outlook.com (2603:10b6:806:462::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Wed, 9 Sep 2026 09:59:05 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Wed, 9 Sep 2026 09:59:05 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=A4gYgRzikJjzRoJuz22hhmibLitXbqTzpGPlBa3KflsNgn79IjAFvvoV2kv7jumHLtwn6uw19CCaalL7NY1/gOD+SbY6plwa5PToksKUx/QCODlNbNkXEfeOP194QvzR/kHpGrMOPq7NJ6jh7HZ5jyz6Svbt4E7mkckwtaYEcHLL8BzMIld5uwrzzDNDwGqEbfchJEQCg6wwDgmKAjX56U3PaGtkB/6VIJNT0Uy8Y+eS0BTahQCJJ7gI+bnr4B1QTVhMsVZMnyoiejfT9/gmtCJae7TtJZjmtM9DlpkJsr6ZeprIKnJHJwMarsxI5ferBXNS06Ui8OuQyj1gcey4PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3eK1jtWcvDiMSUz2rhX485aFGD3Z2Us6Jlh6zXyxfdk=; b=j1hvDD4OfjviY+bi6VWJyyW4dHmDne1fZwHLY0tQnKpfoFrgJU0IHGWH8zCFufWSuU+ypI2R6a/102LfUyNVAe35buxrsFoCsKQ/Qi7mGPbJA/hWjmulOs8JobzozN/QhU8G+3JLNM1I1Y4EpYAr2SJlNUu2H+u4BsSVpKIiuiRW9KBbI3h3J9CSQQpH2DMdbe4qxxMN/UQ8eyxe8+Wua1QKtrCWTKdfNOS/LH6Ec7r1b1osJs6Hh36Asssb1TMBrjdQNG6pCsRdnx3a3sA3mpCI7SshSHOfTLr9vfUxre+7hqjjZYxfF4RejBVVuxEr4SzqGrSYNtCYGStkTC9s5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3eK1jtWcvDiMSUz2rhX485aFGD3Z2Us6Jlh6zXyxfdk=; b=F0/+l2zaNqg5Gr3g8Xqu2btKWDqP1spBs0DcZAuRz3o9tm+CyGA/UIWTsvOvEvh3R7q9Ha5vGsuMo+cVfjAWOtXdYYOrqoYBA1UvJ0bqdIQkPFpMP5a+gZmWLYivks4dYECUs0CajiXxSo3qI5a9anc/4QmGVkg9I8ZwOX8WUiA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <343ccc16-bc42-41b4-a192-2ce446288d04@citrix.com> Date: Wed, 9 Sep 2026 10:59:02 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel Subject: Re: [PATCH 4/3] x86/PCI: use pci_sbdf_t also for pci_dev_base() To: Jan Beulich References: <20260908215721.3346842-1-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0424.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18b::15) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB8327:EE_ X-MS-Office365-Filtering-Correlation-Id: 1665ba64-5ce1-4cbf-5e8f-08df0e58fbd7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|10067099003|56012099006|18002099003|4143699003|11063799006|22082099003; X-Microsoft-Antispam-Message-Info: LsKmXaPNYtAD6glHqx7fAGBYbfL7lbWst2jWeuQa0EMrwr4kOvW37rCgQa3qJJM1t1R6l2ZI5r7+/B+k74lWG7ueZcYrnEC26vtr93Q8xkdeoCvHIUT+jpm8DaUw+jGRnvd39k/YIWo+tNb+xMNSyVUcxnvqxJ7RQrkNEQqkczCyzhtVavmeYakhnU+wzh9km0GcHoZaR9x1Kum1ff2+ncM9u8ui9JBcwHbul7K52gVltYQmTYoqdF9FlVOANw1p7VJ9pCNpouNaBs5Su36KOps8LWny9oEJKSiQTa1kIJzV+00v84sH0nb0zVtJXX6ARnYNmaPrks3XdwUPDeQgcCx+yAGbpU9+wRIodgxVBKVBHEvMPWA+bf3G+YaOOXwAliZNkJ3K0xgW79TkPT9lvmi8unyim/hnD8Ni5tnc58IaiDP4r4S6npN50J9hLhlF2abTJxzZIyEPERv/umNlkwHbWfjPh+v5/gGnwzrb2PTNwnPtxecvCrFX3NuQ/eie3gFCorVHjiDmJSYzLk856gF/CFSXOeh+PebfUkRtXPe9bXYxON8728CVTvQzz4rNRJzjF4VPnjcBL9e2VJZi5A1N+KUEki0bFCs4FsolDtoWewQMsGmuLJmOEBC2ckE2qx3iDNTxVQjNAXkAyHDL1j3QWt/L15vXKNFA1d7xw7g= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(10067099003)(56012099006)(18002099003)(4143699003)(11063799006)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Wk5XaXpQbU5OeG8xRG9Qdmhna1d3Z29KNm9JMWlJSHc4V2J6Ymo4dnFLaTRO?= =?utf-8?B?UEJpdjlzLzI1Yjh6Y09SM1NVdGpCeUdpWTF2UVJKaHJ1bDFZem1sUllOLyt6?= =?utf-8?B?ZzNjVWU5Ri9lVDhZVTNkeUhBa0t4Zi9iM0U0NzBaR1d2YWJKNUYrTUxpR0lM?= =?utf-8?B?SnlZMzBTYlpZc3JnUVFYaC8weU1FMjFmUStHVEVQanhrMCt6Umo2NDBmQnNX?= =?utf-8?B?Y0hIUTBXOUEvQmhFTkxMNDk2ajZuL2tpRDc4aXNBQ2NKbzUrd3hKY1d0cE5M?= =?utf-8?B?a0ZzellnL0dnSzRnSWgwdHU5N3g1YnlMSjZBd2VOS0lxbHhLSWowUDRveU9n?= =?utf-8?B?UjJjQnQ5c0paVGdpL3lwcTVNZ2NxTjdyYUFyN2t6R3BidGJBcldEcHdSc1Fs?= =?utf-8?B?WjJMbVg2Ym15dTFKaytXcW1jSHFmUmprdjhCZkhxVnMrTUwvRjFFUmJtUVFE?= =?utf-8?B?aWNPZEhJQmZLVnpGVG5JTERZcFR0L2prSzMxR0N4YTlNaEVGc1RpU1l4TGF0?= =?utf-8?B?M2tJOHRDbkZKK3NvNzIzeDI3SFg2OXBNanZtN0doaWNsNjkwUkFncWg2YllC?= =?utf-8?B?UFE4SjlObjhTeEsvd3VJYkFub1Zob1ZtZ0xZRGdwYUFZS0xEN2FGQ0tsdTBq?= =?utf-8?B?a0JRT0xja082T3hxdmw1eS9tbEVuWmh4U1Q0cjR1QlQ1TDJXYmc4aVI3TkpU?= =?utf-8?B?R3ppZy9iTUxmbHFUREI2ZCtRV2p0emlFbTVHUlY3M1VFUnI1amVVeEx4Z2Qv?= =?utf-8?B?Sm1WM29pK3ppWlduWmZ0M2VXTjVkcy9KZmZCSzZPNmRPcnVlSXY5ak9yVGtC?= =?utf-8?B?cXo3QjZQT2RGSnJQUS9aNk1IbEE5WGlqZndCc29ZT3c5K2R2ZDJkNDA2R29N?= =?utf-8?B?bUFQTnJIWE8yemJCVXJQaDhYOVpCaUFUTWUraW1zWTR1b2lOakdMeTlUVWlU?= =?utf-8?B?cWhvbnVnYVFjejl1RXQ0NWR0T0FwbUxlbk1JeUh0cmhYeFlRT0phYWovTjg2?= =?utf-8?B?dkFBcFVhbEROWU8xZWNId3ZZQ1NHV095YTJ4ckZkeS8xNDJHdnlRR1dUR0JP?= =?utf-8?B?QzRtK1krcVNQSGxaRXhrSVV4Tm11eTFSQVp0aU9lN3RUVFhnMVB1SHRCQmtz?= =?utf-8?B?TXJ2elpIUUNSZ2FLdHZkcDJQSllhaEdUTjRXRVc5VExkSmxNVnM5TWluVnpT?= =?utf-8?B?QzViTjFpN2JGMWt3czhhZ0J3d1dBQi9ySjhNak4zT0FjWlVWVVhleWdaSloy?= =?utf-8?B?SlVWSmUxNGxldVNpTzNtckJ6Nms5QVFzbVRUY0lHdmp6dnVZamgwSWQzU3Jk?= =?utf-8?B?Y2lBZm1SUXlRQmxjRUhmeDNMbFMzVmRkRTlPeHprTlRaL1gwVjVYVjlkeVQ4?= =?utf-8?B?Q3U3eEMwTjdxZDBQQ2dBZmovU0I0MmdkdHJyL0h5Z0JLOU9CQTNuWjhmOWh3?= =?utf-8?B?YW12U1hiUWlGQjkrT3ZDZTUxb1lZLzg5RUJXT2tVNHJ0UnhDUC9rb2hibnBS?= =?utf-8?B?S3MvUFJzQ1FTSTI2N21lUzVvbWJFSEVkYnh0QUZQNFQrR3ViL3JJS2RJNTB4?= =?utf-8?B?NXE1NEh5bFQyWTd3V01LUi9xWnNtb1FsS2hMaFNzdlpNKzJkN1NYUXBsRHB2?= =?utf-8?B?TDFYQ1liZWY2WVJHVkU5VENFdWFHQXY2V0tFci95MVFWME5obUR0TXN0Vmpt?= =?utf-8?B?ak44cjhZQWMxUE0vTGt0ZllKVHltb0V0cXowRFhSSjU4Q3hRdko1VlZFRFFa?= =?utf-8?B?dk5RdnQ3SWtVbHVIZTczWFRuMTRQc3pJbE04MG9XdHlYenMwazJKSWRCdEls?= =?utf-8?B?d3dTM1BEQkN5WU1INmhoUVB3a2hTYTRqYWlTT3V6aGV3MkM4WTRlUWZrWXpq?= =?utf-8?B?QmVjNFBXaHFuSVY1VjQ4d2NvTlh0dFNXYnNudTkzZVVhTVMvNWNQYXJJV2Zu?= =?utf-8?B?Um9RYU5acThOTGdBYlRoV29YN1Q3dXZXcVRVaHUwY2ZMWnFVTXBEWjNJMWlV?= =?utf-8?B?ckV2amlzWDdTSHNoemR6QktSUUNJaStCckNmVEJFODd2MWo4dTdQdkJCaXkx?= =?utf-8?B?YnEvWUpaeVlHb1dkM0IzcXRJTTQrQk51a3FsemtNNHVJNzhnUVRleFBNem5J?= =?utf-8?B?c0NZbFRYTWlqdGpwVGF4QytCK0VFYTFVaHV1SkhwNnpRQUF4MFdpczJ3NmFl?= =?utf-8?B?bXczK0hMU09RMXdTSjVPTTVjcUJRR2dXdFNHSFA3dmlNZUU0WllOSUtNckx6?= =?utf-8?B?eHRQUVdSZFBxMXRrenZhM3k2Qm1qTUZWM1c2SkVNbW92eDB0T2xpVWdtc3Av?= =?utf-8?B?OFltOWR1MkpTUmN3WjRRVC9neVFSelVHNGUvVFFtRTFETGVzYUdMdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1665ba64-5ce1-4cbf-5e8f-08df0e58fbd7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 09:59:05.5698 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 6KuJL7kJKvzC2wdMg9pdm2S/Mr+jJewHCqLivRnMTzhboJ456tpKpG3iApop0fPqieYs9Z+aKv6ku+biet3x8ruXqjRyNXI4RYNcd9XVCz8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB8327 X-purgate-ID: tlsNG-d25034/1788947948-00CCBA5B-310A9BB5/0/0 X-purgate-type: clean X-purgate-size: 272 On 09/09/2026 8:16 am, Jan Beulich wrote: > No need to pass three arguments when both callers already hold SBDF in > their hands. > > No functional change. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Wed Sep 09 10:40:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 10:40:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412784.1643132 (Exim 4.92) (envelope-from ) id 1x4Fif-0003aL-1E; Wed, 09 Sep 2026 10:39:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412784.1643132; Wed, 09 Sep 2026 10:39:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Fie-0003aE-Ur; Wed, 09 Sep 2026 10:39:56 +0000 Received: by outflank-mailman (input) for mailman id 1412784; Wed, 09 Sep 2026 10:39:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Fid-0003a2-Hg for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 10:39:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Fic-00Ed8O-UW for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:39:54 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa13775-bab6-0a2a0a5309dd-0a2a450aabf4-12 for ; Wed, 09 Sep 2026 12:39:54 +0200 Received: from [52.101.65.86] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1377a-f2d2-0a2a450a0019-346541564edc-3 for ; Wed, 09 Sep 2026 12:39:54 +0200 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11) by AS8PR03MB7000.eurprd03.prod.outlook.com (2603:10a6:20b:23c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Wed, 9 Sep 2026 10:39:51 +0000 Received: from AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292]) by AS8PR03MB9192.eurprd03.prod.outlook.com ([fe80::61a0:97f5:ac5f:e292%7]) with mapi id 15.21.0406.005; Wed, 9 Sep 2026 10:39:51 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wCmqF2dy/SDrDiTVE791ryu3SotJ463xfP5BmOSIQkOkS90+dpOW0F4EJSCXlszW4rsh6Psqbe2/ahTNXd3Wy/mm9kNnloMhxVOT69JQCC6MpTJie+EZ38aqVG+a5aWR50LyTop2BXGrBCw93+EVDbjKu6royGGXrIcb1l5Vy2wUlIKl48Ubl1mYP4kzMXW02w2FH7f86x75jRlKMPFeFUFrhkYvnJYFb7epUzXNFlkimN/EfuxjUpTgJsjAlbKUxUXSw4IL2ErQy+6RVjFKeYMfc5Q22gcuAfkUVHAd7aq0bzpQwMjbAEAUpTZ0WnYLGKxex2dH4MQ4BUtKc5Umuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aqAx4JXBDjsuTjvGn0Yn946AEs/s02oIA1BLDhDbrWo=; b=oNhhiBX5yQuoGDtsrC3PELnBrqbEFq+r3yNc8oz7GFo3pi9WUsbE65YKY3X53E7y5CJaHm50u2zaSj04ukPDpmH8eJBvQtXu62+kBxfEVpWfiXDPGILW9R+4v8mRGO3L3hK5qecvOv5/hKXJixID41cKbS4q/nRSe//pAkwOxW1Gc0hErV7pMDHC6a03fvjw+ZHCxrLjJmO3PRq+RwP2aSoyyrOJLqdEOFo350xDxA/IvjwGVsZHfQjJuo+9Qllg7nRtbWDhLsx8AhbLNoA+V6h2XKJzIRWTqKi3A5KvsMKtDuQ0m+Wlq6bCOK21YHnLn6D9KysZm8xiSriBZgXg3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aqAx4JXBDjsuTjvGn0Yn946AEs/s02oIA1BLDhDbrWo=; b=Pv9HgM9I4hecbTg46yz86PiP/LSyxcg0k80BA8hb27oLJI7Zn6hSx4CnfmEkxoeaqSRST5YaY3xs6jTXeuuEzvRA6Z8sj6hMDWQvDeRKER5BA6zr0FmYr7ixaFiAAtH7n0PcdxViSPGco5mHCxEDDko+sltD36//GajwCiSsDTnJL6j/PRxv5NJc+G15S/HnubOCAsci2HTT+IhFDwhe1ys5tX4yzltDtSuSOoXuYHV+CPXpGsDIEyPvwxBMFZROEpvixNw8hlp+25t5Xaq5MvZDP/UhMPX/OvGZI9OvqxEUQpat8VPAABMJrqnbF5DfaMxVyZA90d1xkF7OSZpCgg== From: Sergiy Kibrik To: Jan Beulich CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , "Daniel P. Smith" , Andrew Cooper , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2] common: dom0less-bindings: introduce XSM labels Thread-Topic: [PATCH v2] common: dom0less-bindings: introduce XSM labels Thread-Index: AQHdQDkyagFQfWFtmkmXmxebnPrTErbF9McAgAAZ2wA= Date: Wed, 9 Sep 2026 10:39:51 +0000 Message-ID: References: <20260909085707.2359322-1-Sergiy_Kibrik@epam.com> <3f2bb6fe-a517-421f-adb9-c33d67ef4591@suse.com> In-Reply-To: <3f2bb6fe-a517-421f-adb9-c33d67ef4591@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS8PR03MB9192:EE_|AS8PR03MB7000:EE_ x-ms-office365-filtering-correlation-id: 0abb13f9-ffc1-4d71-904f-08df0e5ead8d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|38070700021|10067099003|4143699003|11063799006|56012099006|22082099003|18002099003; x-microsoft-antispam-message-info: jz+8O25GAgzbC0mg0uqOCvOg5LwLrClT9vikrLzZrczNRcAto+TW3iaaR/gyKYxcBWJnpP6+yez/5Qh1csGdK2P0sRDmE/QxiGFhGCDJv3Q0oMYXvSiqWJYj8TPa6Ntm5j4mojL5nNfyqpwnAxK0S1jez6bFlPM+NK2zIjMQgyUXhLuQnh20AdU8ScT9ddcAdYnkBPRhR7zSHsmqOSIRRaFs6qv/VYEAB7zGK366ZyZGTvS9mgbxj38XsOj8XQaY8bxh+QiraDWEZNx1FRvHIpr8R6+oWswIjYCIHSp86lYKlZPAd51JGafbcFb1z4jk/cCNNtUrEXRlzVLUZrc2Gyjp3cMEdPmM/mdc1tYm4C9cNzkTX+lg4K7gYLKzXYcvoKgNsOdMwI9F0wwABa4BiEvms22N6rBGYFz/0O9hl3soK4Pf1BT1ByDbOsOxZ1h7WMw2JjRlvGZivdYT07WCl1iRNwSsZXUaTQmpyKwNtfJZ9pRB/DMYnm5GMtMAMWVodP2EE3geKCKmEPSYyUHGC59Z16bmAnzR7xhkJwyZ5nmEsBAZMnRWHjAkXLCj6rVgVvC4O//9OFrr6snuPu1R73TJgQMqQD+Z+FqpcKhDWX5VyjsOBYeZ+mikVOyXJaVJiYNwyQSrEgXD0nmenqBHb+dzkJs3I7ZzeLNNyhFycTMm7cZRgnhavV1CP0ZscUz7Tqos9xSHYrLz9gPQn1sYIwLePXQzscybR0BS7KYPDUE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(38070700021)(10067099003)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?elYxcXpLeW5iYTg1b1VDaXdJRytCZXRwUXZPVGVYeGVvOE0vemgwZXhXUTg2?= =?utf-8?B?MTBwa3Iwd0h3THlRcWhhZmtidkVsQ3hFQ3pBV2lkeE5RdnVoWlJKMFdzN1lq?= =?utf-8?B?bTAwbzdwdzQyOVVZaWdzOENBbStnWUhWOXg2WUlaK2xxazFyaTluU3kzaFRl?= =?utf-8?B?cmVPWnV4VDg5RlJvc3JESDlsQU9DUnZzV0NqWHo4akpISlJNR2ZpRkY2dzhR?= =?utf-8?B?aEFlbXgzVGFSV3VqaFc5bGQrdFIrWFd1RUYvSnk0TVA0bVAyVnVRZDhvRklP?= =?utf-8?B?SGV2Tmt1R09XMnlJQzFKWTAwbXpOelFDeDcwQjZGRFB3a0g4TVA1R3ltYy9x?= =?utf-8?B?azlaVzllUjN4UVZVS29MWkpQRFhKelE3THVWWUFGTEtwQm94T3JVK1BzeFE0?= =?utf-8?B?QUhEd3NkRzcrZFBYNVlhN3dEY0lTR0tJQ2dzRFRucjFFUEthYXB1dVdpRUlY?= =?utf-8?B?aVFkOUt0YmxNemM3c2RabFNWTGxXS05Xc0tjOTZKNmNQYzd6STJMdmdSdWt2?= =?utf-8?B?VWxxZlJPY3JzUzJZZnk5ZDhNK0pTVE1sNnR1dzlpSnBXYWxoSlpTKzNUc0Yr?= =?utf-8?B?Wllpc3pxeWVXUXNTRUZmdmpBMXpVRlBXQzYvNkthQnB3UjZMMlVnVlVpM3dC?= =?utf-8?B?aUZ6Y2Jmc21QTGxqM0lxV3d6V2kwYTRTd3FrcHJDYnNHdy84Q2xkTDB5cTRv?= =?utf-8?B?V3A2clJrTVBid1p3ajVCN1UzT2hhUkpWSVgwQjIyTUVWTGZBaFhnUzZ6VTZl?= =?utf-8?B?VE03Z0dLTE5xQm1KTDdIZUJpTkhIc2tzOGYwQjBZQngvcWJ1RC82SXh5K2pT?= =?utf-8?B?MTFuckVwckZncG1NVm9FUVdJSE1RRGN6bXlBK25CMHc0RDlxTG1hR3pvOFZy?= =?utf-8?B?ZUwxcU1sbG1wQ2ZXTVMvZEVsTWN5RU9hcWhRNTlJZWdVVEFuRnhRRS93OEpH?= =?utf-8?B?RlhVRG5PdXVJemtaY0k2MEEvZUErQ01rRXFZaW92dXVFY0pYOFlndlkzeWN2?= =?utf-8?B?T3B6enhER1V0M2hRdlNGbjVxcHJuQUltdUdNVFNOT1lUOXVhanhlcGFvSHdz?= =?utf-8?B?ZldDQ0l5TUJqS0x5MXFpVXQ5V1pUcXUySkdHUVg3cHN4UGxXTE9WaVFvNkFu?= =?utf-8?B?R244WVVRMEpWUmZIYUdnYURCdEhhN21oRlZSTTlNa1hodXdLRmx0bHhZeTVY?= =?utf-8?B?SWp1dXNIejM0SkN0L3VWYmtBSktUeTV5YkdjTmMxNllOZFh2RkhnQzlHcTJL?= =?utf-8?B?UlBKQ3NqcWUxSndOcFJHdWs2RzliTmZTVkhyWTRjbHFSN1ZtTVJZQmd5bUxC?= =?utf-8?B?VGhjRnpEYVpONU1JcVMyT2FjanVUWldyV3RaZTlJclBaTldFZ0dpTndkUlla?= =?utf-8?B?RzNIZkRLajJ5WXZaZ1hvU3F3bUFNT0UvZUh5eWkxUlh5UmZsbEJmdXpyMVFW?= =?utf-8?B?NUVDd0dVQXA4NGlET2lNY2c0M0hPaXYrdWZHOS9PSjd4RWVYRmtjSTlVYzBv?= =?utf-8?B?bGFJQk1CckxJbzRic3NNMnlHVDl2TzNnYklaM1RCZG9lWUZzVHpQMjlCOGJN?= =?utf-8?B?MnZUZCtoaitMN0xLWEI4QkVPbUMwT0duTjk3Ym4xTGJDSXMrYzd6QW1JdnRJ?= =?utf-8?B?b2V3aU0wRlB3Z2dneFNVWGRsSzdIT0ZGUVBSK09YK09VeDRTcjJDQTlMRkFD?= =?utf-8?B?elVJRG14WWU4TGx4Qk5tYlZBejFjTUgyZFkxQmwwNlRQUEkzSUIrZzhOZTNI?= =?utf-8?B?eTc0Qm1UUktMTjc0SVgzS1VFdnVlM1lUbEhCQk5oUTRyZityUWEvRGhYVExn?= =?utf-8?B?Tm1BSHE4V1ZyYXB3SVRnajN3M3lxd0N2aVUza2VwWHR2UnZLSXNia095cFp0?= =?utf-8?B?L1hITlRaTU5MNHFqK2l6UFVobmRJd2NRK2V3c08rOVEySlBzSW9jVkxDQVB5?= =?utf-8?B?SjJEemFGTERvRU9ZZlhkSzZ2RFFlQ0JFbjZxeXBsVDlSZjVGamRsbmFCdnMz?= =?utf-8?B?Z1FoKzlWSFZ2eXY5WkhvTnM0elBrTFpYVk82emFqdjRyMkcvT1h3c1ZlbXVB?= =?utf-8?B?d0NsejIra0V1RUI3VGVMdDFNMzkyVUJ2WVlUT2RQVVVSQUR0OU02Rk5Wa0JY?= =?utf-8?B?T0RBcjA0YmZzSm9OTzR1clNLaHgySTlVRXdZSGs1ZFBoSzN4eU04eFFUTHNa?= =?utf-8?B?WFJKcnBzVWNoSDVQWGlVSWtpNGtMaDZJQm5uTmxERU1CMlUvb2tpVUNDaitz?= =?utf-8?B?YzE1UEg5RVV1VXcwWlVyMkdpaC8xOG5xQkNSR2JwN3JIa2FnU3NaZXZCNExU?= =?utf-8?B?VWVad1F5R2tWa3o0VWhNQmVrbFZLTEZTQXFEYTlWVDQvSGhXdmlSdFJneWtD?= =?utf-8?Q?PZaqPEGXf9lNKrY0=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0abb13f9-ffc1-4d71-904f-08df0e5ead8d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2026 10:39:51.1314 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QhVagre9zifZZg6cBX6BTx1KSJU1/TdeJopxUCZFSlrRz31cqyaOTxAbkhmHAb1SBcVRzh0Mq8+mWopYXs6kyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7000 X-purgate-ID: tlsNG-4011c0/1788950394-50ACCCFC-FEA97E27/0/0 X-purgate-type: clean X-purgate-size: 1150 T24gOS85LzI2IDEyOjA3LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDkuMDkuMjAyNiAxMDo1 NywgU2VyZ2l5IEtpYnJpayB3cm90ZToNCj4+IEBAIC0xNDEsNSArMTQ0LDEzIEBAIGludCBfX2lu aXQgcGFyc2VfZG9tMGxlc3Nfbm9kZShzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUsDQo+PiAg ICAgICAgICAgcGFuaWMoIidsbGMtY29sb3JzJyBmb3VuZCwgYnV0IExMQyBjb2xvcmluZyBpcyBk aXNhYmxlZFxuIik7DQo+PiAgICNlbmRpZg0KPj4gICANCj4+ICsgICAgaWYgKCBJU19FTkFCTEVE KENPTkZJR19YU01fRkxBU0spICYmDQo+PiArICAgICAgICAgIWR0X3Byb3BlcnR5X3JlYWRfc3Ry aW5nKG5vZGUsICJzZWNsYWJlbCIsICZ4c21fc2VjbGFiZWwpICkNCj4+ICsgICAgew0KPj4gKyAg ICAgICAgaWYgKCBmbGFza19jb250ZXh0X3RvX3NpZCh4c21fc2VjbGFiZWwsIHN0cmxlbih4c21f c2VjbGFiZWwpLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZF9j ZmctPnNzaWRyZWYpICkNCj4+ICsgICAgICAgICAgICBwYW5pYygiSW52YWxpZCBzZWN1cml0eSBj b250ZXh0IGZvciBkb21haW46ICVzXG4iLCB4c21fc2VjbGFiZWwpOw0KPj4gKyAgICB9DQo+IA0K PiBJcyB0aGVyZSBhIHJlYXNvbiB0aGlzIGlzbid0IGEgc2luZ2xlIGlmKCk/IEFsc28gKG5pdCkg dGhlIG9uZSB3cmFwcGVkIGxpbmUNCj4gaXMgbWlzLWluZGVudGVkLg0KDQpubyBzcGVjaWZpYyBy ZWFzb24sIGNhbiB2ZXJ5IHdlbGwgYmUgdGhyZWUgbG9uZyBleHByZXNzaW9ucyBjb21iaW5lZCAN CmludG8gc2luZ2xlIGlmKCkgY29uZGl0aW9uLg0KDQogICAtU2VyZ2l5 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 10:59:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 10:59:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412798.1643141 (Exim 4.92) (envelope-from ) id 1x4G1n-0006kF-IN; Wed, 09 Sep 2026 10:59:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412798.1643141; Wed, 09 Sep 2026 10:59:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4G1n-0006k8-Ew; Wed, 09 Sep 2026 10:59:43 +0000 Received: by outflank-mailman (input) for mailman id 1412798; Wed, 09 Sep 2026 10:59:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4G1m-0006jw-53 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 10:59:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4G1j-004kQu-CZ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:59:39 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa13c18-8faa-0a2a0a5109dd-0a2a450cad20-10 for ; Wed, 09 Sep 2026 12:59:39 +0200 Received: from [52.101.57.54] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa13c19-f479-0a2a450c0019-34653936fb7b-3 for ; Wed, 09 Sep 2026 12:59:38 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DS4PR03MB017780.namprd03.prod.outlook.com (2603:10b6:8:3e7::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.8; Wed, 9 Sep 2026 10:59:35 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0382.014; Wed, 9 Sep 2026 10:59:35 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Q87JX48OZP1hyS3ReEUuAUmZnfFZl0CxzYkcgxHaLCwZgu8A4g+WJ7wQJ5eDqv5Z+0UW4TvoTLaDSzf8J5cdMeyJOh9r1Stmbqhz+IlJTqkiKp7v09vBNBy0uChluQV/5to6VcJEgcPGmOXkp6DyJV6pNhRjDziEGND9/Sp5Lkvuifm54PJsEgZniBN1p/RRyLkhNeE3+yzi2+u2W8sVjtzHjqRllMzLf2v6Jt8oh3oPE07PHL6Wb7g5NFm7KiUHHyGjreFgrNmcelduVoxnyD3Ie90/DyYcGEULqWVRXD7NXVj9oBL574UCSEezGAtlLa6eZxywiK9H8cME2VT4/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iRRatVfPlabWz6C1vuH5L6jVfQWHxAF+090Hq+u2EU0=; b=k2X49mm+KFPADahN2u9xHRIau85JKfxZ+VY60YjSn2Nl96GPYZxG0jSvJhyLD1Yo5WAw8+K8cuzd3/mcAFiOpSlIi7N8ZO2gWw1ErBswrNWDFb1zeA2jd9t1GZeRyr+b9MlCaYKZOkQfixCavEsJJJT99s27LVu0S2QBVzWUUba7tKS3APLPRSs2HvoiXfi1qXBphFmvUOD4zxaoTmw6iZKX5s0DU3D4q8165dzHYmu3PKAH3ULFlXpeYhJFxKBRb9E2xchM2h1iL6v2PDV+oYKlt3XGVIhifFtGMBhFX1/Q0V4yJofJjGVAxBu9YMzbfZUZJHFJtTebeYavkbrTyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iRRatVfPlabWz6C1vuH5L6jVfQWHxAF+090Hq+u2EU0=; b=uRSahXtXxOpbAxemjjS3TrYFewuTG1/V3WbQHPC9kcKYrrOd5/O8iyT92DzAVDzP4uaYN/W4gX5GU42AKII9KOdepaBL/qW9cd2yAJLzUhf6Ppr/Vd463FuThmQ/pvqT+zco/i+KCjydYuQBKY4GfrZawPGHDWcdERIm2nVso04= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 9 Sep 2026 11:59:28 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] x86/viridian: Implement synthetic timer direct mode To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Paul Durrant , Jan Beulich , Andrew Cooper , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini References: <20260904141516.367862-1-ross.lagerwall@citrix.com> <20260904141516.367862-3-ross.lagerwall@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: OS6P279CA0166.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:38::6) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|DS4PR03MB017780:EE_ X-MS-Office365-Filtering-Correlation-Id: d539a374-6792-4c16-fa87-08df0e616f45 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|10067099003|56012099006|11063799006|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: DOBI5B0I+wq11Z17pltxj97fr3n5vnKE41aYCrd5li2eGzF/KpGlEeoNl8vU0c5EuWhyzMxxCJO3hoKyFigN4vk+ofo2RJ2NDL/zrhQxASjQ2xklW6E9oVfraXc67vFAPzYW9dCTIHQ1/iR5FCm2EN1x1OIXSpSs7+AZpeme7RkjkQeK8GMKeVoD/0miexL7A7F19l8nR1Espz2G0iItYcAgvIDhtykjlOGi/GhwwlHij6P1YU2z+vtgWYNNSwChYt9dOAb2wZzJl+RKCj0kWUL0i5gPnAeCwTJqYdWit6hERipXXXOoKM4inOWG/6VMpFFo86V0vV0dbzhPNW/tBilNinebyt2Zz9+MFIMVaTuNzdaQaM6xc/iLCJKAvCLwdvWYmHH/nG+UOHE7Jg0cWif2FbGKfDpu6uYHOliNTgNyepJe3dsWtdcftUFdHePWk6fOENGrZLlqdWqJdPRAJMZUBJ55TvNI77vBpNF/PnNY0+nrVD2f4W4M28TIbdLYh75hkWCENqwcS3MP9J60KNbj9CMmnd5oCngI1hbM323aIuS2b0l4ogO+Yh5PsGXiB69k6Vpvqxh2urzdLMd7D2VxA1hXc7/jq1ExvYDi65o/ktJf4Dr2oaeuHhOfSywrkaemDZ6UlhGHfqsE3Hl+jKIehxcx9w0jXhCzcczOPEQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(10067099003)(56012099006)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SDRBcG9RZUlaa2pWazAxR0RSY1BBd2hZNmgyYkMzQWR1Y3ZrOXkwakM5VlFN?= =?utf-8?B?dW5OR1RXQWNRcWRubnNwMGgrYXhBUGVzMHlDQ09GZG53MG9wZjNrdHdjd2V5?= =?utf-8?B?RWoxamI2ekVma0t5dXV3RUxhTHBrbmtLbmc5MjF4TGZ2cnI1TFVDc0ZQeSta?= =?utf-8?B?VGhSblVUbWgrMUozVEJvZWF0K2RWNkpxSWgrQ3ZjRkFFdEJRQnJtKzVOeFE0?= =?utf-8?B?ZUJEVWtCY1dCMUp1Qk5FelExTCtqaGFmVXhlWUtsQXV3YTl0aVM2aC91WlVB?= =?utf-8?B?RUE0TnJhL01VbHhhQ0tENTMvSUJRYi9hdU5NYUVDRGxMQ3FRTmVxeU45Tlo2?= =?utf-8?B?ckJpMnBHSlVLa3c0Zy9wUWMxa1dmTHpSOVk3TFd0SlJoczB6RGJXT0JkNFFO?= =?utf-8?B?bU1YS1ZucFA5dTFmR0I2bSs0aEVHTnBVTGVHRllrUE1VVHNlRTY0YVVBMDRJ?= =?utf-8?B?ancxVTh6RTJkNVZzWmpabXA3VkdWRERUaTZKRUwybmE2a0Y5UUVLcUVkMzhK?= =?utf-8?B?cStLWEpINEhmYjRWUEtIcngwTmNoZk51Z25udGtUSHNoTTZqWE9nVDlxb3lo?= =?utf-8?B?blNPb2ZSWmpDNlVFajVhYldFUGUyZW1KMHJHdlpwQkpndG52bklvbjU4Smlq?= =?utf-8?B?ZWdCMkw4ang3Y0NucTljRkhYZ05IMVJiL2tWVXdFVGNmRVNsUjBDMG5uWDhB?= =?utf-8?B?VFdFdGt5c2xkZkZTa0JPZ2tsWTNkNnRWMVBROFA1cDl1OXVJNVM2YVhMWlZz?= =?utf-8?B?SytFdk5Rd2diWllxK0piZHVMWk4xK1cvRjBESkg5V0VMdXlTZWZ5Ykd2aXNQ?= =?utf-8?B?V0d5YTBiT01HYlVsbWNZaHBQOFRqelJRN2UxQTNmUVdzcFhMUWR1U0wwdEFs?= =?utf-8?B?WHVCNWpvaHh2NTdFK0oybjZpbWc1Z05oUWJvN0VSbmhwTWxRZHhEUUMwZmR2?= =?utf-8?B?UXpjOGdNSjVlbFpDY1R1d1M4RE9JM3ptYkk4ZFZPR1lYVHlPZXFTbkpTc3R1?= =?utf-8?B?T1NWVkRnQkZSWGxQT1M5QzhaSWdROTNVcGxVNlN3Zmd6R29QUmM4RC95aVIz?= =?utf-8?B?TkdJTHI2N2VaT250NDFmeXpGeUpidGR6b21OZktMSEVUS3lRSVUzRloyV2xQ?= =?utf-8?B?QTlrVFhQcWs0MkZKRTQ4VnR1cWxMOFYrMVh6OG9lMWt0QWpsZExWcTd0SnBz?= =?utf-8?B?NlFwR2hzdjFRSUs0aGpEL2JQVGprdDJ0anhkcmxNOGFTV3dlTTJKSXpkUTR0?= =?utf-8?B?a2ExbldDcVdPZHl1K3hsTDJ6TVFhemFZb3IwZDJQdHhlNVFjTy91VHZtZXdr?= =?utf-8?B?dWhGR05PUDJuOUhWRTFQZkFlNU9BSGRGcWNHQmtJL3daQmE0Zklta1pkQzB5?= =?utf-8?B?cXRnQnVOZ0lNNWNrSUd1aXBJM3ovTzN1R1VaOExSL09YZjErTW9MZ0hWM2FF?= =?utf-8?B?ZzNrQXdIZUE3bWR1OUFyM0dZblJ4R2RxbEl2ODAvNTBDd1JYd2N2cjNtc211?= =?utf-8?B?dk9SVzZienVRWWhqQjVlb1RvWHhZVmswRWR4RjFQTnNBOWFVZzM2YmIvZHh4?= =?utf-8?B?VGk3aThPb0NueXF1MVQyR3hLQ1BMQUpoOERvVnhQN25IQ0VhYnpEYkdVb2xG?= =?utf-8?B?eFoxNXVFRVBaQ0d3Njd3d2RUQy9pR2tPWkdzUnlIaE1NZHZyS1BxS0lVdDVT?= =?utf-8?B?Zy9JOE15T1NYcTRncTY0MkVTY3VhODBhTURmZCtJeVNJdktVeUJucVJENThw?= =?utf-8?B?Y1d0QndrdUhBc0RIaWlJdzRhMEFGaVRubDVhYXVKR2xNTEs0RnRRNS8yOEFo?= =?utf-8?B?RHVmRFBJV2VHTkRrNGs0dmVXNFZ4c216NlUwdmpuREZWMDVKb0ZhbmlpQmxN?= =?utf-8?B?eVNoSGZqM1lhT2xHOXJZWkwvUTloZnF3Rm1QMWxPTldkWm5yVFJpamlNZTdI?= =?utf-8?B?NUJ6M1pmMHROMi82ZGFCUGE0NTZ5Nkk3aVRpc0swVzllQ1UyNnVVd005VzZ1?= =?utf-8?B?SzRocWRzWVZJdGgxS1lEQnBlQ1h4NFZMVG1ob0dOVHE3TCsyM05wSG40UVZG?= =?utf-8?B?aUZJZWdKSmFnM1RucThRVXJyMk9TcWFMRThPSHVwcU1aUE1OUEwycEY0bjdJ?= =?utf-8?B?dUljYUE1Q3lsVENxVThwb3UrV2JlSnkrM2IwTVlzL0ZWQkYyWGJScFRKNzFQ?= =?utf-8?B?YXhLT1hPaURJaEIzOE8wZnJIUENSbitLdHhpYmRsYlR1OUxESlZjL2dpOFEx?= =?utf-8?B?MU1rSmdmYmo3SVFHOWZMRldyUUQ3dG5KT2FDY3ZVTEtNRno3ZVhFR1FYQWZ2?= =?utf-8?B?Ny9tbk5XSDY1SGlXQURWdHc3MEl6YkEvK1h6Z2FwZUFpOGkrZ0xjWWtJM2d3?= =?utf-8?Q?UoHe/GI2kE5u1sn8=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d539a374-6792-4c16-fa87-08df0e616f45 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 10:59:35.3383 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9WPvLMtLcc0v9oILr6rCQRuIn7Hub+4fvh8+fXutjFapSbNOP9bWmpF2pOjUJhjUrrI7C5PtYSOBsijN9ZGjYrOhFag1SH3M7pL6N7/fLwo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR03MB017780 X-purgate-ID: tlsNG-d25034/1788951579-032D8A5B-15B303F9/0/0 X-purgate-type: clean X-purgate-size: 3995 On 9/4/26 4:15 PM, Roger Pau Monné wrote: > On Fri, Sep 04, 2026 at 03:15:15PM +0100, Ross Lagerwall wrote: >> In direct mode, the timer asserts an interrupt on expiration rather than >> using a SynIC message. It is useful to implement this since Windows 11's >> Hyper-V can only use synthetic timers in direct mode. >> >> Signed-off-by: Ross Lagerwall >> --- >> >> In v2: >> >> * Handle migration from older Xen by introducing a new Viridian flag. >> * Added more sanity checks during MSR write and vCPU context load. >> >> xen/arch/x86/hvm/viridian/time.c | 46 ++++++++++++++++++++++++---- >> xen/arch/x86/hvm/viridian/viridian.c | 3 ++ >> xen/include/public/hvm/params.h | 7 ++++- >> 3 files changed, 49 insertions(+), 7 deletions(-) >> >> diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c >> index 082528dc9416..4c8352612b19 100644 >> --- a/xen/arch/x86/hvm/viridian/time.c >> +++ b/xen/arch/x86/hvm/viridian/time.c >> @@ -223,6 +223,14 @@ static void start_stimer(struct viridian_stimer *vs) >> set_timer(&vs->timer, timeout + NOW()); >> } >> >> +static void stimer_deliver_direct(struct vcpu *v, const struct viridian_stimer *vs) >> +{ >> + struct vlapic *vlapic = vcpu_vlapic(v); >> + >> + if ( vlapic_enabled(vlapic) ) >> + vlapic_set_irq(vlapic, vs->config.apic_vector, 0); >> +} >> + >> static void poll_stimer(struct vcpu *v, unsigned int stimerx) >> { >> struct viridian_vcpu *vv = v->arch.hvm.viridian; >> @@ -242,9 +250,11 @@ static void poll_stimer(struct vcpu *v, unsigned int stimerx) >> if ( !test_bit(stimerx, &vv->stimer_pending) ) >> return; >> >> - if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx, >> - stimerx, vs->expiration, >> - time_ref_count(v->domain)) ) >> + if ( vs->config.direct_mode ) >> + stimer_deliver_direct(v, vs); >> + else if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx, >> + stimerx, vs->expiration, >> + time_ref_count(v->domain)) ) >> return; >> >> clear_bit(stimerx, &vv->stimer_pending); >> @@ -361,6 +371,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) >> case HV_X64_MSR_STIMER2_CONFIG: >> case HV_X64_MSR_STIMER3_CONFIG: >> { >> + union hv_stimer_config new; >> unsigned int stimerx = (idx - HV_X64_MSR_STIMER0_CONFIG) / 2; >> struct viridian_stimer *vs = >> &array_access_nospec(vv->stimer, stimerx); >> @@ -368,11 +379,18 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) >> if ( !(viridian_feature_mask(d) & HVMPV_stimer) ) >> return X86EMUL_EXCEPTION; >> >> + new.as_uint64 = val; >> + if ( new.direct_mode && >> + !(viridian_feature_mask(d) & HVMPV_stimer_direct) ) >> + return X86EMUL_EXCEPTION; > > Do we know whether native HyperV also injects a #GP in case of setting > reserved bits on the register? I did some investigation into Hyper-V's behaviour (W11 26H1) since the spec doesn't say anything about it: Reserved bits set => GP fault Direct=1 SINTx=any ApicVector<16 => GP fault Direct=1 SINTx=any ApicVector=any => SINTx appears to be ignored Direct=0 SINTx=any ApicVector>0 => GP fault Direct=0 SINTx=0 ApicVector=0 => sets Enabled=0 I'll update the patch accordingly. > > To keep the previous behavior, should Xen silently ignore the setting > when not supported, like it did in the past? OK. Unless someone objects, I'll still perform the new checks for reserved bits and the ApicVector set while Direct=0 case even if the stimer_direct flag is not present. Ross From xen-devel-bounces@lists.xenproject.org Wed Sep 09 11:21:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 11:21:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412823.1643149 (Exim 4.92) (envelope-from ) id 1x4GMY-0002lS-5v; Wed, 09 Sep 2026 11:21:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412823.1643149; Wed, 09 Sep 2026 11:21:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4GMY-0002lL-33; Wed, 09 Sep 2026 11:21:10 +0000 Received: by outflank-mailman (input) for mailman id 1412823; Wed, 09 Sep 2026 11:21:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4GMW-0002lF-IQ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 11:21:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4GMV-00D9N0-8V for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:21:07 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa14119-bab6-0a2a0a5309dd-0a2a450c9dd0-28 for ; Wed, 09 Sep 2026 13:21:07 +0200 Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa14123-f479-0a2a450c0019-d155da2fc55e-3 for ; Wed, 09 Sep 2026 13:21:07 +0200 Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-c259e5c22ffso617151166b.1 for ; Wed, 09 Sep 2026 04:21:07 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d5497cbsm758024566b.34.2026.09.09.04.21.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 04:21:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788952867; x=1789557667; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=jD5KtwmlQplH54crfONcX5Td6/rkTj5zFBMiTo4IZDY=; b=MrkvjmDx8RTTdn3/J5z57vK7sWuUJLvCUBTqemTaUZumpsVE4JkkQLo8frjVhNZMQ2 p8stFaF6UOKs7xpWPqhhBE4t9GxxhGEMz1oGL8ib6lpCXXHIVqn/Jw2zoi8B80CezmCf tANI9q3yfo0tVRxYMt2rFUNk+qJZBBMaq3BQFbo3uusFOSx0RW+WvmSD5KTlAIeju4gt eofp1PvrH/nfJlBXEthfhOUCzhWfo0akqY+iaWqEhIzJSZ5/iBkgYkk4sXdY9UB373e2 VCrzFEwDsgDKv3DPOWEUr8mCQM0DuEZXwhwU9CHQqR90DesngnOwA1I32sQF3l6cv0b0 hrnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788952867; x=1789557667; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=jD5KtwmlQplH54crfONcX5Td6/rkTj5zFBMiTo4IZDY=; b=E37WG1ehH/C+D7HsBgeO7M9X5RoSEdNssf7U4KJi6IJydMTtTNunBYwZjWaFfwFmRk kbyJ/8afCXKQhIA2MfcvGYiOcVVF3GVbi1kzIiUVoou5aErJG6qzdwNJ9XKYjiMypjES w1XqtJ+UFI0o8E9RQz3rg/mzYEt0Ukp1t5EcXpZPBXUjJuWslv9MbTN7UfOKftD+lAXs 9tSWrJirvix0zwJSfG907ayWGGRWx7hjIH23fHYYXnac2a+X9J6VAz4uEZpllyZ5pNAP RMln/Xc6STaBOUH+kLpEojSzKgTBUqspHGhJ8snXmSvFgVQ2GV1zHfzqVN01AMJ++/yt Ycsg== X-Forwarded-Encrypted: i=1; AKwUvBxM8dIgXGsnTdTaJ4rSIyGriU2I6OQ8X2hmITU3hM/TPvtVynVVi3XtwAw2ni5Ooz3zOJXkd0VkByc=@lists.xenproject.org X-Gm-Message-State: AFuF++nnVFmcNqf4hYnbAHF8UUCfAy0zTgDoeCE2ZcB4Wi8VOci3/O3y fwuisB/yRqSM82O8RSRhbVa3ZUNynxT5M3Ki9cTGH1Po0AbE0GqFvYx2 X-Gm-Gg: AYBFou1Guydg+ItM5CpR0Z1F4vHoQPJrcWFM+/qDRu7dQpKf2MMAXWUBp2CGbQtfOH8 HtPVR7kVqbcyvV30Ixyph/fYL145ztJuaTFH0hO325wtjWr9UHcYAW3R8IQWcpTbF6EC8xxQSST GwBwnQzTClVHSUTSopC4kdJHZse1YEmCRjzUR3AsdfTxvnKMI1balLMq8isUQjobJ3sMQEmQXuM DenE6qdvW/2GILwI61gZscQpLePp8eBnmWDSDhUSonaEisIt8WqwT1n5rpX7ZoX9XMOoRQ6znrH mJJy7Jc/3alQsLA7x/tsGCGtPushR3hAaYOZRqerx8GYaFT+JrcdV7Ik1BEoVACQ4faBbO24sc7 l0ai+YBmdr3bHPqwFMh1Bhi5Vatkw8iYJNWEiOQYq9pMyZoWhEafdOFxNzwjiAQv1uS0R/ysW9C Gms/6bGPq71gOnNRDKNsinR1f1f2VzUtVVYx59jQh4RgicDepNS2iJ9BY5hXWi5ewALqnZ/YKAY VKFNucFMH2n4VX7dS+mhoMH27xbF8TwlqDHRA6fN4A= X-Received: by 2002:a17:907:3f8b:b0:c28:e01d:1d10 with SMTP id a640c23a62f3a-c28e01d2ae8mr928314966b.49.1788952866479; Wed, 09 Sep 2026 04:21:06 -0700 (PDT) Message-ID: <09c883b1-38fd-423c-b516-d39865729e18@gmail.com> Date: Wed, 9 Sep 2026 13:20:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> <39841f44-2b18-4368-a9f8-7c0db307ff6d@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <39841f44-2b18-4368-a9f8-7c0db307ff6d@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1788952867-008CDA5B-40046B79/10/73395122804 X-purgate-type: spam X-purgate-size: 10616 On 9/8/26 3:44 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> @@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_table_entry *ex, >> regs->sepc = ex_fixup(ex); >> } >> >> -bool fixup_exception(struct cpu_user_regs *regs) >> +#define CHECK_GPR_INDEX(num, name) \ >> + BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) \ >> + != (num) * sizeof(unsigned long)); > > Nit: Placement of the !=. Also there should be no semicolon here; it wants > to ... > >> +static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, >> + unsigned int num) >> +{ >> + /* >> + * The GPR number -> struct index mapping below relies on x0..x31 being >> + * laid out at the start of struct cpu_user_regs in architectural order, >> + * matching the register numbers GPR_LIST() hands to the assembler. >> + */ >> + GPR_LIST(CHECK_GPR_INDEX) > > ... appear here instead, for this to actually look like a statement. I will apply that. > >> + ASSERT(num < 32); >> + >> + return ((const unsigned long *)regs)[num]; > > What about release builds? You'd happily overrun the array there. Maybe > (ab)use array_index_nospec() here? num is coming not from guest, not from calculation in runtume, it is generated by assembler at the build time. So it should be always correct. So just having the following looks okay to me: static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, unsigned int num) { #define CHECK_GPR_INDEX(num, name) \ BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) != \ (num) * sizeof(unsigned long)) #define GPR_CASE(nr, name) case nr: return regs->name; /* * The GPR number -> struct index mapping below relies on x0..x31 being * laid out at the start of struct cpu_user_regs in architectural order, * matching the register numbers GPR_LIST() hands to the assembler. */ GPR_LIST(CHECK_GPR_INDEX); #undef CHECK_GPR_INDEX switch ( num ) { GPR_LIST(GPR_CASE) } #undef GPR_CASE ASSERT_UNREACHABLE(); return 0; } Any thoughts on that regard? >> +} >> + >> +#undef CHECK_GPR_INDEX > > If the sole use of the macro is in a single function, it wants #define-ing > (and #undef-ing) there, not outside of it. > I will move inside. >> +static void ex_handler_trap_info(const struct exception_table_entry *ex, >> + struct cpu_user_regs *regs, >> + unsigned long cause) >> +{ >> + struct trap_info *trap_info = >> + (struct trap_info *)regs_get_gpr(regs, ex->data); >> + >> + BUG_ON(!trap_info); > > This feels extremely weak. As you're fetching from a GPR, the majority of > possible values stored in GPRs is going to be invalid, not just NULL. And > while the accesses below would trap on NULL anyway, whether other bogus > values would trap is pretty hard to predict. If trap_info is expected to > always live on the stack, why not check for that (perhaps also check that > the low few bits are clear)? > Considering the nature if how trap_info is filled I think we could just drop BUG_ON(), it is guaranteed by compilation that trap_info will be correct. I think it could be also hard to force trap_info be always allocated on the stack. >> @@ -23,20 +30,36 @@ >> >> struct cpu_user_regs; >> >> -#define ASM_EXTABLE(insn, fixup) \ >> - ".pushsection .ex_table, \"a\"\n" \ >> - ".balign 4\n" \ >> - ".word (" #insn " - .)\n" \ >> - ".word (" #fixup " - .)\n" \ >> +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ >> + ".pushsection .ex_table, \"a\"\n" \ >> + ".balign 4\n" \ >> + ".word (" insn ") - .\n" \ >> + ".word (" fixup ") - .\n" \ >> + ".half (" type ")\n" \ >> + ".half (" data ")\n" \ >> ".popsection\n" >> >> +#define ASM_EXTABLE(insn, fixup) \ >> + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_FIXUP), "0") >> + >> +#define EX_TRAP_INFO_REG(gpr) \ >> + "(.L_gpr_num_" #gpr ")" > > This doesn't need to be wrapped across lines, does it? Oh, really, it could be one line. > >> +#define ASM_EXTABLE_TRAP_INFO(insn, fixup, data) \ >> + DEFINE_ASM_GPR_NUMS \ >> + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_TRAP_INFO), \ >> + EX_TRAP_INFO_REG(data)) > > There's no visible statement separator between DEFINE_ASM_GPR_NUMS and > ASM_EXTABLE_RAW(), which only works because DEFINE_ASM_GPR_NUMS appends > a separator also at the very end of its expansion. I think that better > would be changed, such that at use sites such as this one a separator > becomes mandatory. I will do the following then: #define ASM_EXTABLE_TRAP_INFO(insn, fixup, data) \ - DEFINE_ASM_GPR_NUMS \ + DEFINE_ASM_GPR_NUMS "\n" \ ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_TRAP_INFO), \ EX_TRAP_INFO_REG(data)) diff --git a/xen/arch/riscv/include/asm/gpr-num.h b/xen/arch/riscv/include/asm/gpr-num.h index 3b97a72e6c30..d497bd501e87 100644 --- a/xen/arch/riscv/include/asm/gpr-num.h +++ b/xen/arch/riscv/include/asm/gpr-num.h @@ -23,13 +23,19 @@ #ifdef __ASSEMBLER__ -#define GPR_NUM_EQU(num, name) .equ .L_gpr_num_##name, num; +/* + * The separator is emitted ahead of each entry rather than after it, so that + * the expansion doesn't end with one: whatever follows a use of the list has + * to supply its own separator, instead of silently relying on a trailing one. + */ +#define GPR_NUM_EQU(num, name) ; .equ .L_gpr_num_##name, num GPR_LIST(GPR_NUM_EQU) #undef GPR_NUM_EQU #else /* __ASSEMBLER__ */ -#define GPR_NUM_EQU(num, name) ".equ .L_gpr_num_" #name ", " #num "\n" +/* See the comment ahead of the __ASSEMBLER__ flavour above. */ +#define GPR_NUM_EQU(num, name) "\n.equ .L_gpr_num_" #name ", " #num #define DEFINE_ASM_GPR_NUMS GPR_LIST(GPR_NUM_EQU) > >> /* >> - * The exception table consists of pairs of relative offsets: the first >> - * is the relative offset to an instruction that is allowed to fault, >> - * and the second is the relative offset at which the program should >> - * continue. No general-purpose registers are modified by the exception >> - * handling mechanism itself, so it is up to the fixup code to handle >> - * any necessary state cleanup. >> + * Each exception table entry consists of two relative offsets and a >> + * handler description: `insn` is the relative offset to an instruction >> + * that is allowed to fault, `fixup` is the relative offset at which the >> + * program should continue, > > "... in case of a fault, ..." Applied. > >> --- /dev/null >> +++ b/xen/arch/riscv/include/asm/gpr-num.h >> @@ -0,0 +1,37 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +#ifndef RISCV_GPR_NUM_H >> +#define RISCV_GPR_NUM_H >> + >> +/* >> + * GPRs by ABI name, together with their register number (x0 .. x31). >> + * >> + * This is the single source of truth for the mapping: > > True until here, but ... > >> it generates the >> + * .L_gpr_num_ assembler symbols > > ... no, it doesn't. It's ... I will update the comment to: /* * GPRs by ABI name, together with their register number (x0 .. x31). * * This is the single source of truth for the mapping; users expand it with * their own per-register macro. Among them, struct cpu_user_regs is checked * against this list at build time (see regs_get_gpr()), so neither list can * be changed without the other. */ #define GPR_LIST(x) \ ... and then ... > >> used to turn a register name emitted >> + * by the compiler into a register number, and struct cpu_user_regs is >> + * checked against it at build time (see regs_get_gpr()). Neither list can >> + * therefore be changed without the other. >> + */ >> +#define GPR_LIST(x) \ >> + x(0, zero) x(1, ra) x(2, sp) x(3, gp) \ >> + x(4, tp) x(5, t0) x(6, t1) x(7, t2) \ >> + x(8, s0) x(9, s1) x(10, a0) x(11, a1) \ >> + x(12, a2) x(13, a3) x(14, a4) x(15, a5) \ >> + x(16, a6) x(17, a7) x(18, s2) x(19, s3) \ >> + x(20, s4) x(21, s5) x(22, s6) x(23, s7) \ >> + x(24, s8) x(25, s9) x(26, s10) x(27, s11) \ >> + x(28, t3) x(29, t4) x(30, t5) x(31, t6) >> + >> +#ifdef __ASSEMBLER__ >> + >> +#define GPR_NUM_EQU(num, name) .equ .L_gpr_num_##name, num; >> +GPR_LIST(GPR_NUM_EQU) >> +#undef GPR_NUM_EQU > > ... this construct which does. This is relevant to separate, since > GPR_LIST() is also used elsewhere. > ... here: /* * Generate the .L_gpr_num_ assembler symbols, used to turn a register * name emitted by the compiler into a register number. * * The separator is emitted ahead of each entry rather than after it, so that >> --- a/xen/arch/riscv/include/asm/processor.h >> +++ b/xen/arch/riscv/include/asm/processor.h >> @@ -12,7 +12,19 @@ >> >> #ifndef __ASSEMBLER__ >> >> -/* On stack VCPU state */ >> +/* >> + * On stack VCPU state. >> + * >> + * x0..x31 must remain at the start of this structure, in architectural >> + * register-number order: > > I understand that the order need retaining. But why would it being at the > start of the struct be (overly) relevant? You could use the "zero" field > as the anchor for calculations. You're right. The placement requirement comes only from REG_PTR() computing a byte offset from the struct base. Anchoring it on ->zero instead removes the need for the block to sit at the start: #define REG_PTR(insn, pos, regs) \ (&(regs)->zero + (REG_OFFSET(insn, pos) / REGBYTES)) I'll do that and reword the comment to state the actual invariants: the x0..x31 fields have to stay contiguous and in ascending register-number order, and ->zero has to read as 0. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 09 11:54:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 11:54:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412845.1643159 (Exim 4.92) (envelope-from ) id 1x4Gs7-0007OP-Mi; Wed, 09 Sep 2026 11:53:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412845.1643159; Wed, 09 Sep 2026 11:53:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Gs7-0007OI-Jx; Wed, 09 Sep 2026 11:53:47 +0000 Received: by outflank-mailman (input) for mailman id 1412845; Wed, 09 Sep 2026 11:53:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Gs6-0007OC-50 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 11:53:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Gs4-004v81-Vs for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:53:44 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1489e-8faa-0a2a0a5109dd-0a2a4502a3c2-34 for ; Wed, 09 Sep 2026 13:53:44 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa148c8-6ca4-0a2a45020019-4a7de18c8d26-3 for ; Wed, 09 Sep 2026 13:53:44 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49d097b4939so659945e9.0 for ; Wed, 09 Sep 2026 04:53:44 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d20da3354sm41850325e9.2.2026.09.09.04.53.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 04:53:43 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1788954824; x=1789559624; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=B/6yXL54bLxkuz/0JL99kwUk+Zbxp7yQGgiSS7WqOJI=; b=qjCoxzmVA1mm8ZfkWzZT7/BnA8Sliv12/Mro3EfNEhumZEZIu8Iu+lx3K2ygaKl5EA naG8R3dgqsyOCo0tgUXtqGGuTi5VgbaaZZL9JtaTY1bu8dSMV6KmaPvVdIGk/ppVfE8Y T0C/GkKfTRlr0Em+FvczH3bMPffNq9kZ66Loc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788954824; x=1789559624; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=B/6yXL54bLxkuz/0JL99kwUk+Zbxp7yQGgiSS7WqOJI=; b=hHJEOHyo49H1xgRMqypeRelemkJHZ2YIR6gWbYeRbNP9CnviZuR2SDtr/s+KmnaQ7c 4UITbdoOuxFXzUkQNFeSyrL0W8vo26VzlwkAoFBNCyFvXBeLVbGKEPSrjC1kdghQswQO MIrm3mfKB2GCbvlhtjNFU8hl7WU5SZt/nRo5P9L8iOyKID43C7zASC0mk3jfx5nw6VCY wuYZOw4uzmIw2rH6sPux1ehm1H9D5bDYOrEXEIGNw5ghv07PBuS6ghwp7hT40hMVFzW1 u7EL9PiQDdYQzfRj9MP/L/9hI+hUQU6Hu8eqWZbNDvzG65MxTw1F36h/fWgGjZIlyQ9E Uyig== X-Gm-Message-State: AFuF++lSdV7h2ASFA7QMNp4qBTOa4KmmLf/fQznycdnBErca90530Ba1 gx4iFlnOv0zqdxpoUVmRpcf8laxk6sdGAbUzuSJFrmzaZ+VjE+/gmmIggqBnGD12cNG4QLf652/ LMC232wQ= X-Gm-Gg: AYBFou3Y/nN+QtxHIWY+R6tr0rYa2Cqq9P6wq2kXM/SJSRtzx7fQ/ig/zfrSKdupT3G 9YlDcFnzFpS7ZuNiA5vnyBKXFJkoC0gdONjJxLRze2gTyWBEVFpTXlsdXH7AiRfQWsjbiqy+c6g /nTDyqPxXYsVejUv21qI4YAXeP5h/Pw+SfGQkPiffQanJ/HFmfFIadLGOsLk5Wc3GQ1aH47j535 7wZrpGp8pj4BSiRbku2BC3Re2jOY6z/y7LB3h4rn5PWnTb5fXo4eiPWceEMPyaM2JL7fp5CgL/9 Sss9DYBSbbhJOznkYVPTaFAg8YhChCtAlDk8JsDPoAMprXrYDr7e8TDD0vZHzDTjrV2wP/8b6WT 8Ff5rHsZpDmMcAIeByjhU4Fskyq2O1qjfIFBFEwfnV9m6PhzzEjSz7k6PzK9wrmQtwniak1L+10 D2qIk5hfhYewukcaCMh8i4AG3nwcohsnv3I0cnjo2gTNvMicPfExRvN37xyGB8MNF3fVECETJiC mWOoGy0dMeVGkFx5lXhL1RZin3K8bQMULlcN4ZpcjgUCD45fQ== X-Received: by 2002:a05:600c:4f44:b0:49d:e0c:e55e with SMTP id 5b1f17b1804b1-49d25914e45mr5985165e9.23.1788954824184; Wed, 09 Sep 2026 04:53:44 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko Subject: [PATCH] xen: Use __has_include() in xen/percpu.h Date: Wed, 9 Sep 2026 12:53:42 +0100 Message-Id: <20260909115342.3376342-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788954824-67ABD2AC-34FFB9F1/10/73395122804 X-purgate-type: spam X-purgate-size: 3296 Only x86 has an asm/percpu.h. Have the compiler only include it if it's present, rather than symlinking an empty file. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Oleksii Kurochko This same pattern can be applied most of the rest of generic-*, and it's high time we purged that logic. --- xen/arch/arm/include/asm/Makefile | 1 - xen/arch/ppc/include/asm/Makefile | 1 - xen/arch/riscv/include/asm/Makefile | 1 - xen/include/asm-generic/percpu.h | 14 -------------- xen/include/xen/percpu.h | 4 +++- 5 files changed, 3 insertions(+), 18 deletions(-) delete mode 100644 xen/include/asm-generic/percpu.h diff --git a/xen/arch/arm/include/asm/Makefile b/xen/arch/arm/include/asm/Makefile index 4565baca6a4d..a78a498eb566 100644 --- a/xen/arch/arm/include/asm/Makefile +++ b/xen/arch/arm/include/asm/Makefile @@ -5,7 +5,6 @@ generic-y += hardirq.h generic-y += iocap.h generic-y += irq-dt.h generic-y += paging.h -generic-y += percpu.h generic-y += random.h generic-y += softirq.h generic-y += vm_event.h diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile index c989a7f89b34..a5c46704ccad 100644 --- a/xen/arch/ppc/include/asm/Makefile +++ b/xen/arch/ppc/include/asm/Makefile @@ -6,7 +6,6 @@ generic-y += hardirq.h generic-y += hypercall.h generic-y += iocap.h generic-y += paging.h -generic-y += percpu.h generic-y += perfc_defn.h generic-y += random.h generic-y += softirq.h diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile index 86c56251d5d7..d3483699278d 100644 --- a/xen/arch/riscv/include/asm/Makefile +++ b/xen/arch/riscv/include/asm/Makefile @@ -6,7 +6,6 @@ generic-y += hardirq.h generic-y += hypercall.h generic-y += iocap.h generic-y += irq-dt.h -generic-y += percpu.h generic-y += random.h generic-y += softirq.h generic-y += vm_event.h diff --git a/xen/include/asm-generic/percpu.h b/xen/include/asm-generic/percpu.h deleted file mode 100644 index 3fdb3a2a0208..000000000000 --- a/xen/include/asm-generic/percpu.h +++ /dev/null @@ -1,14 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -#ifndef __ASM_GENERIC_PERCPU_H__ -#define __ASM_GENERIC_PERCPU_H__ - -#endif /* __ASM_GENERIC_PERCPU_H__ */ - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/xen/include/xen/percpu.h b/xen/include/xen/percpu.h index 30609f49f0b3..d324671b5b5f 100644 --- a/xen/include/xen/percpu.h +++ b/xen/include/xen/percpu.h @@ -27,7 +27,9 @@ #define get_per_cpu_var(var) (per_cpu__##var) -#include +#if __has_include() +# include +#endif #ifndef __ASSEMBLER__ base-commit: a2ca4f8b9890899ca89d6116002e7a9c5957d8c6 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 11:54:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 11:54:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412848.1643168 (Exim 4.92) (envelope-from ) id 1x4GsX-0007jY-Tt; Wed, 09 Sep 2026 11:54:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412848.1643168; Wed, 09 Sep 2026 11:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4GsX-0007jR-RL; Wed, 09 Sep 2026 11:54:13 +0000 Received: by outflank-mailman (input) for mailman id 1412848; Wed, 09 Sep 2026 11:54:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4GsW-0007ho-Li for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 11:54:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4GsV-007MMj-Q7 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:54:12 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa148d2-bab6-0a2a0a5309dd-0a2a4509b5f6-28 for ; Wed, 09 Sep 2026 13:54:11 +0200 Received: from [103.168.172.155] (helo=fhigh-a4-smtp.messagingengine.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa148e1-be1a-0a2a45090019-67a8ac9bc37d-3 for ; Wed, 09 Sep 2026 13:54:10 +0200 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id A769A14000F4; Wed, 9 Sep 2026 07:54:09 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Wed, 09 Sep 2026 07:54:09 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 9 Sep 2026 07:54:08 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1788954849; x=1789041249; bh=GAXFhXvRC6+vGyqr4aNL560qyE7fHFaTxZb+EtyBrt8=; b= HbEewaqUoSeJxUG4vVJ+UQ8cFk+Cy/T+N2dbjupo+DC60saaZfsAMicM+1JFuTkj vkK81n77dQFYWK6etpzazRANhzAEMUIE7U05avJHo2ROdf1rr2ifg8kmMAp1SXfm vGZFgPr2hypMYbmnHaT0Z8w2ZdpWg8diEPkWruzJSTYYTKPgOad0jaXdGXC16f8F g/EGkPREjI0m6R1ytaFh5lEBUq6koDQxzGy+zMPTvrjw54QOMjGvIS17njQ3KxyD IT/HHqof6zZkFzC8BO7obz9zGfzkrwh2YNeixbtMXlomjXsFdBq6tDZq3AZlnddd GZgGLgIiuzYE4+jJTd0CXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1788954849; x=1789041249; bh=GAXFhXvRC6+vGyqr4aNL560qyE7fHFaTxZb +EtyBrt8=; b=BPX/gkYEO7zYnBxXzMX5lkQWVzQrEK/RGE+aAt2T4Iw7yLqF1Jq FI6fOU6c3OIRv2BLei4bSDtrPCDwz1CoQBfNX0md5j9M946nBmwFKXzAVbjf8zpW WGNaaBJuHHstECkF9VR4UeGJx7oDe/TfA/jdDW+V9uXr6PYcIEX7Td39bZhovUzB kIMLtZJHT32f6GoXUsWnPBj6kvkmV5I1vkpBYGYdOappCUp1+UcPTAsSw537l1Y3 v1ISfBgp4AHJJi+7SU+Ryji+jyWHjR/cTc0UWuMOtuXl0TzT3YPlojbyshloTaPx N/ii30egw+XtVqYPKQsbgis2qcp+yljY6OQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE1c10p/68Ffk0RTi6beBp3tyoAS8TRAOTWjm8THH6rnTE+ZHyf+mDP7Hag7oZFWq VfX5ahJPNWPCfSegu5BIqnfApqUTuvbL0Sj8lk/BnOs9ZZQlurSxDaR+ATr1bMy/6tVTPy JPFSKcQLYaD/F5uZ+FCOWM5qag6j57XoNSJy5iWeZ38wer4iWRmTheGYK/DSWXUmieegDK PGlIifvoazem/1FXp2TZDFHnwwAMMLhzk85iIKMZojuDag9yszgppadXnBnz3KWSxmYm/5 CwyEkrzVf78EbQ9RGB+HMFXvwtRlgsqNuKECiUFK0pktSQwtKS88BqbrLJJJfbJcGyZfA8 OR7fzKf9MPYrYQmWrm0HA4VDhaQBy91cjcsoDQYRZeuQXgfQosM1QLxohbzL7f9glJO/yI rHj85SGXmNnZavzqYQvBXWZiGiHfX7JxGHJmFuZJvhQxL3Nt28yGtg7+hjnKymJT4dtVm7 qVAW7Zt3bwvO+23Wn4GLGUe3RnXtl3UxSF0MC5juJCTtXO+fmE09dEjjMB6yOLim2sYC+n Xz2s3FE6XqUaTGlhHu0Lwyf8d1AfYeKFIVfBHwMzsq/Q/jEKSwVN/wa1uLY/Tasl2Latw0 FKDu4zO/EslGmIx4yFA73AKflfl3Wb1205QollsAFJKPBy59xa+413HzHk/Q X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Wed, 9 Sep 2026 13:54:06 +0200 From: Marek Marczykowski To: Andrew Cooper Cc: Jan Beulich , "xen-devel@lists.xenproject.org" , Daniel Smith Subject: Re: [PATCH] EFI: don't use alias attribute for compat hypercall stubs Message-ID: References: <4326ea69-572c-4a1a-ba89-147fab55b2d5@suse.com> <5a3b475d-6c1f-47da-89be-ae45e34c4e49@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QBWwqiG9Zif3r5q8" Content-Disposition: inline In-Reply-To: <5a3b475d-6c1f-47da-89be-ae45e34c4e49@citrix.com> X-purgate-ID: tlsNG-bad1c0/1788954851-BD8C1034-BBACB9D0/0/0 X-purgate-type: clean X-purgate-size: 1688 --QBWwqiG9Zif3r5q8 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2026 13:54:06 +0200 From: Marek Marczykowski To: Andrew Cooper Cc: Jan Beulich , "xen-devel@lists.xenproject.org" , Daniel Smith Subject: Re: [PATCH] EFI: don't use alias attribute for compat hypercall stubs On Mon, Sep 07, 2026 at 04:15:54PM +0100, Andrew Cooper wrote: > On 07/09/2026 4:14 pm, Jan Beulich wrote: > > Recent Clang objects to types differing between alias and aliasee. Acce= pt > > the unnecessary overhead and make the two compat stubs real functions. > > > > Signed-off-by: Jan Beulich >=20 > Acked-by: Andrew Cooper Acked-by: Marek Marczykowski-G=C3=B3recki --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --QBWwqiG9Zif3r5q8 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqhSN4ACgkQ24/THMrX 1yw/AwgAhx0PCWUmKc7kw1RlcVuOh9vwWofpBY0IciGiQb0vkaU2tXcQtwgoy26z g4mIwG+ia6v2ZpnQ/HjtL487JBpqYpMTLQu9g4AMcHmgBjthRMf1+joYEZyYrjY6 waH2FUb6mtwLD9f7gryFeZn3hVdRQRd30nforwRjmHlKg9hcXQBbIgL3bdMbxCId PLLjIFxwNAuTkQWR4wsfQ5Qkl9NFIlePROeU/ZQL2sOKQp2j1ftoa3n85kUnLuL1 rOWocAjRMeIQqwA9mOcmtVUhhv61gfyO27Fep/dUrl+nNWTwl4L4AkmCze73s4Zw yMx7uEw406/WM6l/klk57R5bR/1bug== =Ul4G -----END PGP SIGNATURE----- --QBWwqiG9Zif3r5q8-- From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:03:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:03:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412888.1643176 (Exim 4.92) (envelope-from ) id 1x4H11-0001TN-3h; Wed, 09 Sep 2026 12:02:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412888.1643176; Wed, 09 Sep 2026 12:02:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4H11-0001TG-0u; Wed, 09 Sep 2026 12:02:59 +0000 Received: by outflank-mailman (input) for mailman id 1412888; Wed, 09 Sep 2026 12:02:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4H0y-0001TA-Qb for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:02:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4H0y-00CMDP-7F for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:02:56 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa14ae7-e002-0a2a0a5209dd-0a2a4507a2d0-46 for ; Wed, 09 Sep 2026 14:02:56 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa14aef-b4ea-0a2a45070019-b9ff1c2398ad-3 for ; Wed, 09 Sep 2026 14:02:56 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0860cb11c000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 12:02:53 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 1F9B281D0C; Wed, 9 Sep 2026 14:02:51 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=DRVzdlYg7u+JKQiDIxgiiOYbBBoqBlmWSLoU22CyEik=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=KvxOtDScrYcEi1TLoteRYP727Rd6FAuqbspSfsVGrHP5scf1NeAtlAz0JXunHyt2JV1vwSylF qwVxfgAIYkdfWRf10n540ZZy016HuTGyWHwg7qjhJfAsjUEJpT/jhlfVuNBOyFPHb0ehElnTFBy nFJRQB3kphDigndXjmd9H7Iz9cM84ctEdm2z6MmqqgpDVoQuDLBCIBgfEu8tzWCBaK0oUytTD46 tAbuTbpmhSeC9wSp+/yygI42aKDKtOKvyrv+woEjlLXEsbhRQRa1lY5B9eyR5QFqnX1MTqk6NQG Ciiw9zzo+IqLLNKrNrPxMT9m10E4qhcXKhOAzgpce4Fw== X-Zone-Loop: 4e6d492b330297936a2bb5555289a3790e3a09119967 x-campaign-type: default x-transaction-id: 2d536c37-4874-45e4-a933-bee39f2f27fa x-swg-uid: 01-3695df48-b236-41b9-abee-bc8e855589b9 X-Mailer: Sweego Message-ID: <1788955373.8631fc262581453bbf619ec5b2062170.1a0860cb11c000c4f3@vates.tech> x-swg-bid: 1788955373.8631fc262581453bbf619ec5b2062170.1a0860cb11c000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH 3/5] xen/riscv: make Svpbmt no longer a required extension From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, zhangzheng@iscas.ac.cn, Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <59555237-425d-47f0-80b6-b7273cc8d6ec@gmail.com> References: <1787844438.8631fc262581453bbf619ec5b2062170.1a043d52a06000c4f3@vates.tech> <1787844809.8631fc262581453bbf619ec5b2062170.1a043dad34e000c4f3@vates.tech> <59555237-425d-47f0-80b6-b7273cc8d6ec@gmail.com> Date: Wed, 09 Sep 2026 14:02:45 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788955371; l=10184; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=q5ozkt96CaE0FinvuF687LELJyNwspS7AGQT+mxY0Ew=; b=ESE1eqTvlHs8WeEJ+8wT+7Gqv04SwyJMNoQQtVmdGXcCYChYBXXZ33Jlt2MVEMRB+0wxpVe3K X1DafZOF84QA6n9pNEzTHZhKgGvL5+X8HDYbtJwoBZCvEq32kAydMpB X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788955371337 X-purgate-ID: tlsNG-ef75cf/1788955376-A76D2AE4-8818A74E/0/0 X-purgate-type: clean X-purgate-size: 10188 On 2026-08-28 17:58:14+02:00, Oleksii Kurochko wrote: > On 8/27/26 5:33 PM, Baptiste Le Duc wrote: > > > required_extensions[] panics at boot if Svpbmt is missing, which is a > > problem on hardware that doesn't implement it. > > Based only on this sentence it isn't clear why it is safe to have SvPBMT > = n and what guarantees that if some memory for a device dma for example > should be non-cachable and strongly ordered what will guarantee that. > > So basically something like that should be added to the commit message: > ``` > Without the Svpbmt extension, memory attributes (such as cacheability > and ordering) are strictly tied to physical address ranges and enforced > by the hardware's Physical Memory Attributes (PMA) checker. > > In this configuration, supervisor software relies on the platform's > memory map: peripheral device registers (MMIO) are physically mapped > into hardware-defined I/O regions (which are implicitly non-cacheable > and strongly-ordered), while regular RAM is mapped as cacheable main > memory. > > S-mode paging can safely map these physical ranges without specifying > page-based memory types in the PTEs, as the hardware MMU and PMA > pipeline will correctly bypass caches for MMIO accesses based on the > target physical address. Furthermore, on platforms that either feature > fully hardware-coherent DMA or do not expose non-coherent DMA agents to > the OS, page-level programmatic cache control via Svpbmt is not > required, making it safe to boot and run when Svpbmt is absent. > ``` > > Xen already checks Svpbmt at > > > runtime in some places (vcpu_csr_init()), but not everywhere: > > This part sounds like there are additional places where you think the > Svpbmt related bits should be set but I don’t see in this patch (or in > others in this patch series_ where you are adding Svpbmt related bits to > places where they weren’t added before. Am I missing something or did I > misunderstand your message? If the latter then could you please re-word > this part of the sentence. > > > p2m_pte_from_mfn() and the PAGE_HYPERVISOR_NOCACHE/WC macros still set the > > raw PTE_PBMT* encoding unconditionally. > > > > Drop Svpbmt from required_extensions, and introduce pte_pbmt(), which masks > > the requested PBMT encoding down to 0 when Svpbmt is unavailable, using it > > in both remaining unguarded spots. > > > > Assisted-by: Claude:claude-opus-5 > > Signed-off-by: Baptiste Le Duc > > --- > > xen/arch/riscv/cpufeature.c | 1 - > > xen/arch/riscv/include/asm/page.h | 8 ++++++-- > > xen/arch/riscv/p2m.c | 2 +- > > 3 files changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > > index 92235fdfd5..900cb9d772 100644 > > --- a/xen/arch/riscv/cpufeature.c > > +++ b/xen/arch/riscv/cpufeature.c > > @@ -157,7 +157,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = { > > RISCV_ISA_EXT_DATA(zifencei), > > RISCV_ISA_EXT_DATA(zihintpause), > > RISCV_ISA_EXT_DATA(zbb), > > - RISCV_ISA_EXT_DATA(svpbmt), > > }; > > Also, please update docs/misc/riscv/booting.txt. > > > static bool __init is_lowercase_extension_name(const char *str) > > diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h > > index 5c02f64a17..6a3749526d 100644 > > --- a/xen/arch/riscv/include/asm/page.h > > +++ b/xen/arch/riscv/include/asm/page.h > > @@ -11,6 +11,7 @@ > > #include > > > > #include > > +#include > > #include > > > > #define VPN_MASK (PAGETABLE_ENTRIES - 1UL) > > @@ -54,6 +55,9 @@ > > #define PAGE_HYPERVISOR_RX (PTE_LEAF_DEFAULT | PTE_EXECUTABLE) > > > > #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW > > + > > +#define pte_pbmt(pbmt) \ > > + (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? (pbmt) : 0UL) > > Checking the ISA string alone isn't sufficient. > > Svpbmt in HS-mode is gated by menvcfg.PBMTE. If M-mode firmware hasn't > set it, the hardware behaves as though Svpbmt were not implemented: bits > [62:61] become reserved again, and a non-zero encoding raises a page > fault (even though the DT ISA string advertises svpbmt). The same > applies to the G-stage mappings built by p2m_pte_from_mfn() below. > > menvcfg isn't readable from S-mode, but the spec gives an indirect > probe: when menvcfg.PBMTE is 0, henvcfg.PBMTE is read-only zero. Xen > already relies on exactly this in vcpu_csr_init() (ENVCFG_PBMTE & > csr_masks.henvcfg). So it would be more robust to compute a single flag > in init_csr_masks(): > > pbmt_enabled = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) > && (csr_masks.henvcfg & ENVCFG_PBMTE); > > and have pte_pbmt() test that instead. This makes the check reflect what > the hardware will actually honour rather than what the DT claims, and it > also collapses the condition in vcpu_csr_init() to a single test. > > > + > > +#define pte_pbmt(pbmt) \ > > + (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? > (pbmt) : 0UL) > > PAGE_HYPERVISOR_NOCACHE / PAGE_HYPERVISOR_WC are no longer constant > expressions, they are now evaluated at each use site. riscv_fill_hwcap() > runs fairly late in start_xen(), after setup_fixmap_mappings(), > early_fdt_map() and setup_mm(). All current ioremap() callers (aplic.c, > kernel.c) run after it, so the code is correct today, but this is an > implicit dependency: any ioremap introduced earlier in boot would > silently get PBMT=0 with no diagnostic. I don't know honestly speaking > if it is a real issue. > > Worth either documenting this with a comment next to pte_pbmt(), or > adding an ASSERT() on the initialisation state. Switching to the > __ro_after_init flag suggested above makes the dependency explicit, > since the flag can be set alongside csr_masks, which is also populated > after riscv_fill_hwcap(). What do you think of something like that: ``` diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 2819ff4e7c..1b07d75105 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -47,6 +47,10 @@ static struct csr_masks __ro_after_init csr_masks; #define HENVCFG_VALID_MASK 0xe0000003000000ffUL #define HSTATEEN0_VALID_MASK 0xde00000000000007UL +static unsigned int __ro_after_init is_pbmte; +unsigned long __ro_after_init pte_pbmt_io; +unsigned long __ro_after_init pte_pbmt_nocache; + void __init init_csr_masks(void) { /* @@ -79,6 +83,18 @@ void __init init_csr_masks(void) INIT_RO_ONE_MASK(HSTATEEN0, hstateen0); } + is_pbmte = (riscv_isa_extension_available(NULL, + RISCV_ISA_EXT_svpbmt)) && (ENVCFG_PBMTE & + csr_masks.henvcfg); + + if (!is_pbmte) + pte_pbmt_io = pte_pbmt_nocache = 0; + + else { + pte_pbmt_nocache = PTE_PBMT_NOCACHE; + pte_pbmt_io = PTE_PBMT_IO; + } + #undef INIT_CSR_MASK #undef INIT_RO_ONE_MASK } @@ -97,8 +113,8 @@ static void vcpu_csr_init(struct vcpu *v) */ v->arch.hcounteren = HCOUNTEREN_TM; - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) - v->arch.henvcfg = ENVCFG_PBMTE & csr_masks.henvcfg; + if ( is_pbmte ) + v->arch.henvcfg = ENVCFG_PBMTE; if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) { diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index 1cc01289a0..2ac2731eda 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -55,8 +55,6 @@ #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW -#define pte_pbmt(pbmt) \ - (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? (pbmt) : 0UL) /* * PAGE_HYPERVISOR_NOCACHE is used for ioremap(). * @@ -64,8 +62,10 @@ * is that IO is non-idempotent and strongly ordered, which makes it a good * candidate for mapping IOMEM. */ -#define PAGE_HYPERVISOR_NOCACHE (PAGE_HYPERVISOR_RW | pte_pbmt(PTE_PBMT_IO)) -#define PAGE_HYPERVISOR_WC (PAGE_HYPERVISOR_RW | pte_pbmt(PTE_PBMT_NOCACHE)) +extern unsigned long pte_pbmt_nocache; +extern unsigned long pte_pbmt_io; +#define PAGE_HYPERVISOR_NOCACHE (PAGE_HYPERVISOR_RW | pte_pbmt_io) +#define PAGE_HYPERVISOR_WC (PAGE_HYPERVISOR_RW | pte_pbmt_nocache) ``` This avoids having to recompute PAGE_HYPERVISOR_NOCACHE/PAGE_HYPERVISOR_WC at each call site. However, I don't like that PTE_PBMT_IO/pte_pbmt_io (resp. PTE_PBMT_NOCACHE/pte_pbmt_nocache) end up coexisting, that's confusing as we should not use PTE_PBMT_IO/PTE_PBMT_NOCACHE. Another solution could be: ``` /* page.h */ extern bool svpbmt_enabled; static inline unsigned long pte_pbmt_nocache(void) { return svpbmt_enabled ? PTE_PBMT_NOCACHE : 0; } static inline unsigned long pte_pbmt_io(void) { return svpbmt_enabled ? PTE_PBMT_IO : 0; } /* domain.c */ static unsigned int __ro_after_init svpbmt_enabled; void __init init_csr_masks(void) { ... svpbmt_enabled = (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt)) && (ENVCFG_PBMTE & csr_masks.henvcfg); } ``` What do you think? > > > + > > +#define pte_pbmt(pbmt) \ > > + (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ? > (pbmt) : 0UL) > > pte_pbmt(pbmt) reads like a PTE accessor, i.e. something with the > signature pte_pbmt(pte) -> enum pbmt_type, especially given that enum > pbmt_type is declared just below in the same header. What it actually > does is convert a requested PBMT encoding into the encoding that may > safely be written to a PTE on this hardware. > > Something like PTE_PBMT() (matching the PTE_* naming of the values it > takes) or pbmt_encoding() would convey that better. > > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:05:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:05:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412897.1643185 (Exim 4.92) (envelope-from ) id 1x4H32-000223-FB; Wed, 09 Sep 2026 12:05:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412897.1643185; Wed, 09 Sep 2026 12:05:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4H32-00021w-C8; Wed, 09 Sep 2026 12:05:04 +0000 Received: by outflank-mailman (input) for mailman id 1412897; Wed, 09 Sep 2026 12:05:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4H31-00020k-2C for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:05:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4H2z-002Apd-RV for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:05:01 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa14b69-e002-0a2a0a5209dd-0a2a4501dc36-10 for ; Wed, 09 Sep 2026 14:05:01 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa14b6d-5984-0a2a45010019-b9ff1c23aa85-3 for ; Wed, 09 Sep 2026 14:05:01 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0860e9a70000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 12:04:59 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 50B1E81D1B; Wed, 9 Sep 2026 14:04:58 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=SkuYxjZ1B5YFTEgieTR6yPubK5Xfl64bqCNy4funigg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=X83l/zztBu4p1c1Ec2wVabCwloF5u07GkEq3UEU0IH5r0bLkJoQqwBUC9KwPI0vuYp54xXilC cEorXyDPpspoWlDSZUqfvbU0QAL32GsDws5Pb0GQtVhbIHtXLdMVMm2uRoZcsDreII5gzH/igkM dg88aPvjA4PyzZxzV5+oIP3GMVCmb66xFRRXmcg8RnIFD6RtCftZPOjWEqTl54EYeLkVfwf2O5s iNDNjH/PTo+gwaUp0qBB97jRXlGycNM/4YvFppkikLqR1d6/EyePaWiBvyEKQon/laL3VVk6+6j +RQUifwMpJJ5B34Nh3qt+UytupxnRKhJsAc+4NXMxliA== X-Zone-Loop: b9439202ed9b83d8ce94fe610df575d4749f47f7edb9 x-campaign-type: default x-transaction-id: fee67b83-b446-43e5-81d7-41ca9b597b07 x-swg-uid: 01-80742788-40b0-4177-a8fa-151a0b2d5faa X-Mailer: Sweego Message-ID: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9a70000c4f3@vates.tech> x-swg-bid: 1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9a70000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 21/39] xen/riscv: resolve the faulting guest physical address From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Wed, 09 Sep 2026 14:04:50 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788955498; l=3751; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=RS+bCt0Q6wrr4O9Nud/sTDEh4x8UsS4NDZCGRoZAyV4=; b=UQLlewz1h1vhEiTEXmQK7fhjMu3gU1u2mzUT4EY+35e8wAomp5id+PEAzGDGMj1bIP7Gblz0D xW8Q7qBM0VbDXOzPkRirfX9N5uf1+rq356ZjCwNMOE25hvpqSROatXg X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788955498538 X-purgate-ID: tlsNG-d62444/1788955501-BCD44757-084C0343/10/73395122804 X-purgate-type: spam X-purgate-size: 3751 > Take the guest physical address from htval and stval: on a guest-page fault > htval holds it shifted right by 2, so that an address wider than XLEN fits, > and stval holds the faulting guest virtual address, whose two least > significant bits are those of the guest physical address. The shift is done > on paddr_t rather than on the raw register: a guest physical address is 34 > bits wide on RV32 with Sv32x4, so shifting an XLEN-wide value would drop its > top two bits. > > Those two low bits come from stval only for a fault on an explicit access. > Where one is taken on an implicit access made for VS-stage translation htval > holds the address of the VS-stage PTE which could not be read, while stval > still holds the guest virtual address which started the walk, and the low > bits of the address written to htval are zero instead. htinst tells the two > apart, which is what the spec points at it for. > I'd just precise (the spec is also not clear on this point though), what is "current XLEN" here, clearly indicate that htval holds the GPA >> 2 and stval holds VGA and also put the two different cases we need to distinguish clearly: ``` Recover the guest physical address from htval and stval. On a guest-page fault to hypervisor, htval holds the guest physical address shifted right by 2, so that an address wider than HSXLEN fits, and stval holds the faulting guest virtual address. The shift is done on paddr_t rather than on the raw register: a guest physical address is 34 bits wide on RV32 with Sv32x4, so shifting an XLEN-wide value would drop its top two bits. However, there are two cases to distinguish when recovering the faulting GPA: - Explicit memory access: we use the two least significant bits of stval, which are the same as those of the guest physical address. - Implicit memory access for VS-stage translation: the two least significant bits of htval are zero. These two cases can be distinguished using the value provided in register htinst. ``` > > stval needs no check against an ISA extension: a guest-page fault writes it > with the faulting guest virtual address regardless. Sstvala would not be the > right thing to test for either (it covers stval across every trap type > which writes it, a wider guarantee than what is needed here). > > htval does need one. The H extension lets an implementation write it with > either the faulting address or zero, so without Shtvala a zero htval cannot > be told apart from a genuine fault on guest physical address 0-3, and the > address has to be recovered by decoding the access and walking the VS-stage > page tables in software instead. That is left as a TODO, and until it is > written such hardware panics rather than acting on an address which may not > be the one which faulted. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c > index f9da075104..ff530ef2df 100644 > --- a/xen/arch/riscv/emulate.c > +++ b/xen/arch/riscv/emulate.c > @@ -9,6 +9,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -62,10 +63,28 @@ static bool htinst_is_pseudo(unsigned long htinst) > } > } > > -/* Reconstruct the guest physical address of the access which faulted. */ > +/* Resolves the guest physical address the access faulted on into @gf->gpa. */ Why did you change the comment apart for adding @gf->gpa? I think the "reconstruct" is more clear but there might be another reason why you changed it. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:05:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:05:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412898.1643196 (Exim 4.92) (envelope-from ) id 1x4H37-0002Fc-MY; Wed, 09 Sep 2026 12:05:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412898.1643196; Wed, 09 Sep 2026 12:05:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4H37-0002FV-IQ; Wed, 09 Sep 2026 12:05:09 +0000 Received: by outflank-mailman (input) for mailman id 1412898; Wed, 09 Sep 2026 12:05:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4H36-0002F4-PF for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:05:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4H36-002AsR-1x for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:05:08 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa14b72-e002-0a2a0a5209dd-0a2a450b8218-18 for ; Wed, 09 Sep 2026 14:05:08 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa14b73-b7e8-0a2a450b0019-b9ff1c12acb3-3 for ; Wed, 09 Sep 2026 14:05:07 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0860e9b57000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 12:04:59 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id B11CD81D29; Wed, 9 Sep 2026 14:04:58 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=P1Fan9ahgx2VBI8jliJ5LQtzmgAzErGHYFISr9EhURY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=WwIno9lwwYlYHntYi869ckVap9ge2VS3F9+ps2AMEMhXd7taM+hs/r0G3hMJ29lZl5kVewOE2 bnupksPVZ01+fNJ8nIIlKemzsNH2qBCp/w4/4i7UYL2jM+/t6CqEbpicWavHMHK85v91fnDV3Q0 lwYAhS8+neCyrvpiIUFTEs3TzFnMCmGhJq+yfotBBf5ZWsGh0pquIgt8DPJ+McmJ6cNiIr9F8L2 R97+YTtp8F0tSi1iuIuw5yNZDVBYQCXQRIFOaOqeBtaK5i21tBuiNV92E0adptQNdlz3v7J3gcZ ljAHwYKA/HKHw0N6Y8cDIjIb1U1tL6tcC9Zyokb8psxA== X-Zone-Loop: 880373e9f02c3b0fbfc057b49853be444a6872c7ee59 x-campaign-type: default x-transaction-id: 1ad97e21-e073-4d3d-8d05-868ff0f91f71 x-swg-uid: 01-481fe253-67e6-491c-a2ca-1b27c86c6acb X-Mailer: Sweego Message-ID: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3@vates.tech> x-swg-bid: 1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Wed, 09 Sep 2026 14:04:50 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1788955498; l=3931; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=FYp7Yp+6NxVDJREZj+5tCvCL3vAYifXWUEp4s3gGLPw=; b=LIwZlhpleQKZI4wVaJNHF7QVE4PBFm1mLXeNd9hPdj2/BBWxWa86NMQ6OO2fFg1OwAAGyz9Aq 2cbVhznTfKyAqOLBRxikXAuBvXACfK8J/DTy0ZxTWYvvcmRfS36B/V7 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788955498924 X-purgate-ID: tlsNG-42698a/1788955508-AA0C59EA-0CED9A1D/10/73395122804 X-purgate-type: spam X-purgate-size: 3931 > Introduce riscv_read_guest() to allow Xen to safely read guest memory > using HLV/HLVX instructions while reliably capturing trap context. > This is required for instruction fetch emulation and MMIO decoding, where > Xen must inspect guest memory that may not be directly accessible and may > fault. > > The implementation is based on kvm_riscv_vcpu_unpriv_read() from Linux, > with one deviation: the hlv/hlvx instructions translate the guest address > through the live vsatp/hgatp CSRs, i.e. through the address space of the > currently running vCPU, so the function can only be called safely for > current. Instead of taking a struct vcpu argument, it always operates on > current directly. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/guestcopy.c b/xen/arch/riscv/guestcopy.c > index 8a89212e0b..b2327822ac 100644 > --- a/xen/arch/riscv/guestcopy.c > +++ b/xen/arch/riscv/guestcopy.c > @@ -6,6 +6,7 @@ > #include > > #include > +#include > > #define COPY_from_guest 0U > #define COPY_to_guest BIT(0, U) > @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, > return copy_guest(buf, gpa, len, GPA_INFO(d), > COPY_to_guest | COPY_gpa); > } > + > +/* > + * Read machine word from guest memory > + * > + * @guest_addr: Guest address to read > + * @read_insn: Flag representing whether we are reading instruction > + * @trap: Output pointer to trap details if something went wrong during read > + * > + * The hlv/hlvx instructions translate guest_addr through the live > + * vsatp/hgatp CSRs, so the read is only meaningful for the address > + * space of the currently running vCPU. > + * > + * At most two halfwords are fetched when @read_insn is true, i.e. encodings > + * wider than 32 bits are not supported. Such an encoding cannot be completed > + * by calling this function again at @guest_addr + 4: the length check is > + * applied to the first halfword read, which would then be a continuation of > + * the instruction rather than its opcode. It is up to the caller to reject > + * anything that is neither a 16- nor a 32-bit encoding. > + */ > +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, > + struct trap_info *trap) Nit: every other function in this file / declared in this header (raw_copy_from_guest, copy_to_guest_phys, ...) has no riscv_ prefix. Why does this one get it? > +{ > + /* > + * Poison the result: if the very first access faults, the fixup skips > + * over the loads without writing it. Callers must check trap->scause. > + */ > + unsigned long val = ~0UL, tmp; > The actual "did a trap happen" contract callers rely on is trap->scause == 0. If the very first access faults, fixup_exception() will write scause accordingly to a non-zero value, but nothing in this function clears trap->scause on the success path. > + > + /* > + * hlv/hlvx use hstatus.SPVP for the privilege of the access, and the > + * live vsatp/hgatp for the translation. Xen never installs a value of > + * its own in hstatus (it is only saved on trap entry and restored > + * before sret) and it doesn't reschedule before returning to the > + * guest, so all three still belong to the vCPU which trapped. > + * > + * Check the saved copy rather than the live CSR: a nested trap taken > + * from HS-mode clears hstatus.SPV in the CSR (but leaves SPVP alone). > + */ > + ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV); Just to understand, what is the aim of this check? Is it to be sure this function has been called during a guest fault and not a nested HS fault? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:14:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:14:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412923.1643203 (Exim 4.92) (envelope-from ) id 1x4HCB-0004cX-L7; Wed, 09 Sep 2026 12:14:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412923.1643203; Wed, 09 Sep 2026 12:14:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HCB-0004cQ-I4; Wed, 09 Sep 2026 12:14:31 +0000 Received: by outflank-mailman (input) for mailman id 1412923; Wed, 09 Sep 2026 12:14:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HCA-0004cH-Ha for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:14:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HC9-007Pxf-T0 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:14:29 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa14d9b-e002-0a2a0a5209dd-0a2a4504d6b6-44 for ; Wed, 09 Sep 2026 14:14:29 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa14da5-b57f-0a2a45040019-b9ff1c23a4e3-3 for ; Wed, 09 Sep 2026 14:14:29 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a086174641000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 12:14:27 +0000 Received: from localhost.localdomain (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 8DF7B81D31; Wed, 9 Sep 2026 14:14:26 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=64t6DlOqM5oBcjLpnyKokKcO6pW+6+MyeV0F8Ibs75E=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=Ua0gCRnti2XirZLWwe2wV9P0RbXcee1SQXpSHqXvPDpyVzxXRWvNQMtQw9SOD9ghPNGFP6t1G PMSTXBccLQolZY8m7o7sg0QiEMSs5UtB/CMFVxPatmYyLIY74CUDyY2N9/d42LBvlGMQB+asWK0 0pcfPUMxtLh+mrJ/wEeYMGHBuvqnZU4UAbdm8mvUJfW0SvHDAGc5CeQDd1e6iuRwCbmIDYyWIVs /JnmPX0dJWiN4S1lkDfg1i7sRaEbLcYH6TnouyMnnvXlMJvrQBeKn+4yTMwjUqP7KlT8zvJEfv2 zBFbHcwM/aDnpGVz1UnDYj+828hLX4iBuK1u00/B4JSw== X-Zone-Loop: a34b4a0410d78ebd248b70c52de1449c37237a01c9d5 x-campaign-type: default x-transaction-id: 210a9964-ee39-40df-bc42-e6984d4378ec x-swg-uid: 01-a2d3c175-c1e6-4107-ad60-399b8219d23b X-Mailer: Sweego Message-ID: <1788956067.8631fc262581453bbf619ec5b2062170.1a086174641000c4f3@vates.tech> x-swg-bid: 1788956067.8631fc262581453bbf619ec5b2062170.1a086174641000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Teddy Astie To: xen-devel@xenproject.org, xen-devel@lists.xenproject.org Cc: Teddy Astie , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v3] x86/vmx: Avoid pausing on HVM_PARAM_IDENT_PT in additional cases Date: Wed, 9 Sep 2026 14:12:43 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.33.3b80ac56d6942fe5.1a0861743bb.7e3b699b805aa14=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788956066752 X-purgate-ID: tlsNG-ebf023/1788956069-C20D5B50-95E5652E/0/0 X-purgate-type: clean X-purgate-size: 1678 ---=Part.33.3b80ac56d6942fe5.1a0861743bb.7e3b699b805aa14=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable When settings HVM_PARAM_IDENT_PT, skip domain pausing when : - there is no vcpu - unrestricted guest capability is used Signed-off-by: Teddy Astie --- Regarding checking for hvm_paging_enabled(v) (proposed in v2 review), we c= an't as hvm_paging_enabled() is vCPU specific, and vCPU 0 may have a different = value to another one=2E v3: - rebased patches with staging - adjusted formatting v2: - rebased patches with staging xen/arch/x86/hvm/hvm=2Ec | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/hvm=2Ec b/xen/arch/x86/hvm/hvm=2Ec index 9a4147b62e=2E=2E2981a61cee 100644 --- a/xen/arch/x86/hvm/hvm=2Ec +++ b/xen/arch/x86/hvm/hvm=2Ec @@ -4237,11 +4237,14 @@ static int hvm_set_param(struct domain *d, uint32_= t index, uint64_t value) rc =3D -EINVAL; break; case HVM_PARAM_IDENT_PT: + v =3D domain_vcpu(d, 0); + /* * Only actually required for VT-x lacking unrestricted_guest * capabilities=2E Short circuit the pause if possible=2E */ - if ( paging_mode_shadow(d) || !using_vmx() ) + if ( paging_mode_shadow(d) || !using_vmx() || !v || + vmx_unrestricted_guest(v) ) break; =20 /* --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.33.3b80ac56d6942fe5.1a0861743bb.7e3b699b805aa14=--- From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:23:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:23:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412936.1643213 (Exim 4.92) (envelope-from ) id 1x4HKI-0006UW-DY; Wed, 09 Sep 2026 12:22:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412936.1643213; Wed, 09 Sep 2026 12:22:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HKI-0006UP-A4; Wed, 09 Sep 2026 12:22:54 +0000 Received: by outflank-mailman (input) for mailman id 1412936; Wed, 09 Sep 2026 12:22:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HKG-0006UJ-6B for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:22:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HKF-00ExDP-J5 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:22:51 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa14f8f-8faa-0a2a0a5109dd-0a2a4508cf48-32 for ; Wed, 09 Sep 2026 14:22:51 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa14f9b-f659-0a2a45080019-d1558034e8e8-3 for ; Wed, 09 Sep 2026 14:22:51 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49d05d51553so34620405e9.2 for ; Wed, 09 Sep 2026 05:22:51 -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-49d1fd58c31sm46583475e9.1.2026.09.09.05.22.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 05:22:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788956571; x=1789561371; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=QVDU/bjjPFMfmCPUgJPWFMURmw36Oro4ApkU4yUs6tA=; b=ayF3NdXXf68YMaFf7mRcbx+OhZE4GquDT5G39Z0HnOMCEOyd5nkfWEGjIDWRnB43MI 8ut2b4mXayCifKHcXDHxMrlBCuxnptTfA6/Wz1+kG2g6NpwF2OtFZw3yoEU8tl8GfwkO XwnWJTFXQ+8RUrIYT69wTa/TGOUd5URuXrNrhRAS9L7zVp+uoVaPPpf5ei8glrTZnc63 VaRjVRNAxjlxFSRCYoroOK8AF8hbfTHuB5f2JUrL5GQ3sTOZb7OdDiNFNl1FmJhKZGNv 4fMF2u3LzcMY72ZUdLIHq+CZ55fc7PJIpm1yFH4hpDjnl22HH59PxBDN1ToMjQpU7K/V pDyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788956571; x=1789561371; h=content-transfer-encoding:content-type: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:content-type; bh=QVDU/bjjPFMfmCPUgJPWFMURmw36Oro4ApkU4yUs6tA=; b=ln4WmEx4d1I5zT+a/zb/rUtZqokOIOEOwSN7VhxtIAfa7o2J/Vb24Ddh83XW2rOZmV 9WFDdQvTVbJuXwV5KhPikltlRJMG2iqlQyn8MflFvP3IiFHM8U7/nNjGwwfJAUVwSR3x ND2zYn+3PmB946eJtvuGRKT4FRz6Oz+j2STXSXdU8Q7XASOcDIh93rUVnngFxXPjuTar xOLr7VrtkL/vHqXLk7WRbE3Ql/+couiTpnVYtYanKlVEZ9WVz4FOOwGKzMryHiL9DG6f v3fQq5gvESYnVgeenYypJYsWwm1xSw5d39mBgWUPevx6bNQ2galS7aBt7ZJ9ecQFa2+N C5VA== X-Forwarded-Encrypted: i=1; AKwUvBwgUgTOaT+aFasluWTFdJkcyz03OJOUlkLcumaLKEafiUierHdz0l89NIDOuZvJs+uFyjPHH+FK06A=@lists.xenproject.org X-Gm-Message-State: AFuF++maM5BGAblqMu5SQKY1aKAhO3fm6kQpJINlQb2YVQJfY/0eyvb6 uwquRfwsKKYHxOZXuVTGW2kFhLI3sHp2WAYJL6BYYUuUP9VQsKkEdtmgFNn1j7MqWw== X-Gm-Gg: AYBFou34OpbCG/zRPJcRBqcNq1r0cFDdrqNNZFbgaAsDzaLRIqH1k5MhjAvsAowhGFS Byx3Kr1djq16srUn60+hRvhOa84sENRI20SgZqRudjfBVzsA5roZySZ9H3xPw2KtSX5KI9s3y4N TOjN5fMSEU633nSFfMojN0jR+zEEU3XjwBd/Ois2rc/SbhU0sKhbQQkVolwmfhXUci/DpsKibVx yymxMCHCeiQUYJZ6h9aVaeB3xsYGb2gtga883kNan6WtcHPQ6auauOlaklSzKa8QZuHc+A8MmSZ ZjpkrPwH2ixS/Ct+79MG2EwUeoejHlBJS1FaZB78NuYGI7h+SzoTimmvfc041FXe7niK8sgWQlN d8DBbEfd7JPCU2ULoYCPnR90uROTSvmy36i3af7pAqyCJhXggYupZWEPS9ytu64P5m95QtDYcPP xpTAGW/wrdziDNa+P2u/nTo2A9SChLj2XNz4SpfYfLl5Cm9fBWljfRXro15FK2yxrEI7hZQPXBJ IgOoehWljhXEmePfLXtL6NZBytd3FqY/CnzjCzmGMi8VkWvdH+KoxVY1pctlN22 X-Received: by 2002:a05:600c:3b0e:b0:49c:fc6e:a3d5 with SMTP id 5b1f17b1804b1-49cfc6ea726mr310616355e9.20.1788956570805; Wed, 09 Sep 2026 05:22:50 -0700 (PDT) Message-ID: <40c2524b-ab7e-461a-9113-ceee0560a918@suse.com> Date: Wed, 9 Sep 2026 14:22:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> <39841f44-2b18-4368-a9f8-7c0db307ff6d@suse.com> <09c883b1-38fd-423c-b516-d39865729e18@gmail.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: <09c883b1-38fd-423c-b516-d39865729e18@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1788956571-D514E87B-6DD5891E/0/0 X-purgate-type: clean X-purgate-size: 2587 On 09.09.2026 13:20, Oleksii Kurochko wrote: > On 9/8/26 3:44 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> @@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_table_entry *ex, >>> regs->sepc = ex_fixup(ex); >>> } >>> >>> -bool fixup_exception(struct cpu_user_regs *regs) >>> +#define CHECK_GPR_INDEX(num, name) \ >>> + BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) \ >>> + != (num) * sizeof(unsigned long)); >> >> Nit: Placement of the !=. Also there should be no semicolon here; it wants >> to ... >> >>> +static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, >>> + unsigned int num) >>> +{ >>> + /* >>> + * The GPR number -> struct index mapping below relies on x0..x31 being >>> + * laid out at the start of struct cpu_user_regs in architectural order, >>> + * matching the register numbers GPR_LIST() hands to the assembler. >>> + */ >>> + GPR_LIST(CHECK_GPR_INDEX) >> >> ... appear here instead, for this to actually look like a statement. > > I will apply that. > >> >>> + ASSERT(num < 32); >>> + >>> + return ((const unsigned long *)regs)[num]; >> >> What about release builds? You'd happily overrun the array there. Maybe >> (ab)use array_index_nospec() here? > > num is coming not from guest, not from calculation in runtume, it is > generated by assembler at the build time. So it should be always correct. > > So just having the following looks okay to me: > > static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, > unsigned int num) > { > #define CHECK_GPR_INDEX(num, name) \ > BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) != \ > (num) * sizeof(unsigned long)) > > #define GPR_CASE(nr, name) case nr: return regs->name; > > /* > * The GPR number -> struct index mapping below relies on x0..x31 being > * laid out at the start of struct cpu_user_regs in architectural > order, > * matching the register numbers GPR_LIST() hands to the assembler. > */ > GPR_LIST(CHECK_GPR_INDEX); > > #undef CHECK_GPR_INDEX > > switch ( num ) > { > GPR_LIST(GPR_CASE) > } > > #undef GPR_CASE > > ASSERT_UNREACHABLE(); > > return 0; > } > > Any thoughts on that regard? Depends very much on how efficiently the compiler translates this (as opposed to the other variant). Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:26:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:26:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412946.1643221 (Exim 4.92) (envelope-from ) id 1x4HO2-00072Q-RG; Wed, 09 Sep 2026 12:26:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412946.1643221; Wed, 09 Sep 2026 12:26:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HO2-00072J-Of; Wed, 09 Sep 2026 12:26:46 +0000 Received: by outflank-mailman (input) for mailman id 1412946; Wed, 09 Sep 2026 12:26:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HO0-00072C-Sr for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:26:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HO0-00CRQp-92 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:26:44 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15082-2eae-0a2a0a5409dd-0a2a4505896e-4 for ; Wed, 09 Sep 2026 14:26:44 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15084-4cb1-0a2a45050019-d1558034e04c-3 for ; Wed, 09 Sep 2026 14:26:44 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49b8e527d63so70819995e9.2 for ; Wed, 09 Sep 2026 05:26:44 -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 ffacd0b85a97d-4858d312ca0sm45662274f8f.4.2026.09.09.05.26.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 05:26:43 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788956803; x=1789561603; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=kYMa0F1IAPGmOPjH8uSmEseFasQH0wqDn+4S/HZLdVE=; b=PPNMlXKX1KSEF5VDEXgJQ7jlAZK+t+PSUrBD+6UX7zbxv4D8BBp7pUZeU/bO3WlLVd vC1yKTrczAuidc7m8CXTpMU5mdP55KoP65voh5viIrrKcGMwCxety/D6MT7r72dcgr8B p1FtlYgJM+6JuwHRlkAgi/YzXJX3kx2Moy1/FH07jOGsz894mAO3U90HbIied1Iln2I1 /b2jrmlQng7ifxGNVtDyqiEfgrbXEi8Lp5uJg2ZGMPaInnu3vZ1xljeTchTTS3aGeaOh R8+R8e+Uzx+9YHl83wGcpNkvUHidJhnwH1rpcu+mXM+2T2Zp5v5s8qqPcMoPGk6VNeO8 k9wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788956803; x=1789561603; h=content-transfer-encoding:content-type: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:content-type; bh=kYMa0F1IAPGmOPjH8uSmEseFasQH0wqDn+4S/HZLdVE=; b=Ru+50GIg3IafEDMj7dEfz36AhURZIUx5cBYaPdVQpj0lgl07j7ddBX5785AfRJwYhv jGeKUxhUss782E/pAHi2YgY+0JI4Suvfh8NM3amQ/k9eKCMwQWX6iVB3tk1yn3BU0N6l 7smR3FpPAtKkpF4GgT1/Aytyqe4F19bl2VB9yfrPdK9+Jlay1jHma9v2rXGnUVXDeDZs gJgfoKohiwfuMhusns3Jl9UN1QAoio2lhmEIc8LmXtsNbJEIbCPd9KeJkPSgiKnRRudE lcYdgyBGzh99Cf8rFT1FloYPjxYwvkl7uJR6QIz3fUZKU5hzqHaSNhlQWDRQUWZOJ3TY m0tg== X-Forwarded-Encrypted: i=1; AKwUvBxHwWjM4+DYikSLdfotST/YTeQatSKysp1jxyqQG66Hfxr6jQMwPVCsMC2ssp6nUliWkTsC7BkaSww=@lists.xenproject.org X-Gm-Message-State: AFuF++nv/M05yxUwtV7r+oTcSMWHAn+7T+AsXYr0Yk/hmFnpam9Uioih mUuXy/mvTGm8KcdxByOdwNmYribrkUJW25TvFHlBwZq7nwWoL94cogWU0OjWI84skw== X-Gm-Gg: AYBFou066flKwAsFRfaghkoHbx123pEbKBaaj6CtG816V2otHXZzHC7AWjv9mu4icL8 LXsStI5wUvpKtBylsJ/hhq6zinozvDbxVSrFBeUuUkpj/TUwsUrB7lG5B0vAruHuQJmllnZG2Pg XcbkfTnNUbIQt3Ddq5iFCS0mkTKcvqNuz0HedbuExgrRY7PyiirXiUi1Heh3Gls2KO3bw3EVwFW 9N0SXHn/I5p+4DphwNac+nShOZ4krsa06A7re2n5qIVZxU38NUGFIMGP322AS9+wL6xPxg46KFZ ra6leQj1kcgJGXHJeuKxtj285E3QcGXpFvCVfQ6PnWh8pywQtnLz2LgZN0itVxfgekOREsb9tN1 p7u8CZaIxurHKmRPQ4Pzd19VJds/c9tf59LJhb1y55218VPBKpAvv/otxlVeRt/bjBhbVLDsC/U MAfV4y8W+N8Q6wHc34nUt/Z8qgS6ohYs2so9nYvLLg937O1i5Vh8yvzYonskO2kCx55jH3w5VXl lnUgBwFUkgWdADz6aX9aSHRplIU0LNw4y8VnFSNM19CrrAdRV7jKs0WzrwNoYo= X-Received: by 2002:a05:600c:154f:b0:49c:fc6e:8cb5 with SMTP id 5b1f17b1804b1-49cfc6e8ee3mr358556145e9.25.1788956803570; Wed, 09 Sep 2026 05:26:43 -0700 (PDT) Message-ID: <5e51bf1d-8e2e-4638-b9ba-c192bb97f539@suse.com> Date: Wed, 9 Sep 2026 14:26:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Use __has_include() in xen/percpu.h To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Xen-devel References: <20260909115342.3376342-1-andrew.cooper3@citrix.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: <20260909115342.3376342-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788956804-F62AB2A1-153FAF14/0/0 X-purgate-type: clean X-purgate-size: 312 On 09.09.2026 13:53, Andrew Cooper wrote: > Only x86 has an asm/percpu.h. Have the compiler only include it if it's > present, rather than symlinking an empty file. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:30:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:30:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412953.1643230 (Exim 4.92) (envelope-from ) id 1x4HRZ-0000Kg-8E; Wed, 09 Sep 2026 12:30:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412953.1643230; Wed, 09 Sep 2026 12:30:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HRZ-0000KZ-5e; Wed, 09 Sep 2026 12:30:25 +0000 Received: by outflank-mailman (input) for mailman id 1412953; Wed, 09 Sep 2026 12:30:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HRY-0000KT-Qv for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:30:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HRY-002kqj-3k for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:30:24 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1515d-8faa-0a2a0a5109dd-0a2a45059d4e-14 for ; Wed, 09 Sep 2026 14:30:24 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1515f-4cb1-0a2a45050019-d155dd2cf101-3 for ; Wed, 09 Sep 2026 14:30:23 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-482dd6ee390so6444715f8f.3 for ; Wed, 09 Sep 2026 05:30:23 -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 ffacd0b85a97d-485885bf3f0sm48209345f8f.33.2026.09.09.05.30.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 05:30:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788957022; x=1789561822; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=4vfWcV+Rr/yaJNNidS4GBbHBi7UAgQvsCOyZHLutSvQ=; b=VmsgqP8n8fxNmWETNVu6/wxm6Lwy0tynQ37JUol9UXnmAfCKiE1APR1UcCpMnbCrx9 B918DwOi1arZjXRp7aYbF416X8U1FgPDnI9i65xzwBKZaUcd0Gqfx4YYbAj6gO/V5/Vb 6/s6ZCIj+ydhH1zy17UNM1czqYj0JTI+J8zR1kKMaXi4/6CQIf1Ma58rmd9MM45094Jk aFEi4D19PqUGDxxcsZoSBr97sTCui2HpdYvV7wHsLr3XFnUKZ7p3HPpwzJWTQ8XGNiOf tq9jqTbN8CXRZ9UCySKD0KhWXKhV6SLTc8TeIFLf121zUY5PUh7iJTCcbgKhngvqob+2 0qkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788957022; x=1789561822; h=content-transfer-encoding:content-type: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:content-type; bh=4vfWcV+Rr/yaJNNidS4GBbHBi7UAgQvsCOyZHLutSvQ=; b=KRUQ7xGHxI70denBwHratHDbHGEUAuwaAeyiIq1191Br0gc8u7OqOJUZw41mHFU1x7 8AaTqFYOHmiAyFWf9s8KJEdLKY29MlN5OzT4xJxzM0QATQT76zruMyCmLy7OtuIz5OHG n7TS3NZQ4jfcR7xRnFyKujbpDx4MiabmcSo83YMTo7jnzTQJzttIf9ba9XHZTWGU+8g8 YkNg72/jvc6GrpkP84lrrKQMAzVucgX6fNLNoZwTod1Tfg+4tZ5an8L/WYF3QdakMWSq rq6lWu0y+4qbAkOjZQ/F17UZcFQGqL4mlWNTfNRr/N64ngt6RqAzd0Jyy3b4glvNSbFh RpBQ== X-Forwarded-Encrypted: i=1; AKwUvByPjTYBw5Qp1+RONiqgcICdmoeG6XTIjnX8pFjYeQjA4/n9KszNqQvUxCTipn/7KJDC62zB4sbTpME=@lists.xenproject.org X-Gm-Message-State: AFuF++k8LpHdXW/Ll5tYCkJtOoCuTo7/SIz8WwyNacOqLgSCy2P6Z+dr lo3rMzp6606FwFu+qP3avDtk6DQ65dusJLZ6PH5uIcXtkL+z+EEcXTQvaiyGSCGJGg== X-Gm-Gg: AYBFou2K6u7nE8xqdc5RlqJd2CNBlFpnkOwSTngdLnzGIJACBErdoi2P0LIwr6tveiM aCsaO1gtP8A3fgkRMvKETlQesxqG5Z3vEmHdeQe83OQoJLFhVrPP6VVTwaGTKdoZeYW6CLkFab4 /N4S4CBatlWbcEfseaf0oawNntjmvjrwDCsuzFECpa4y9PK2jaZhqBClOdtuL/E+PmefGZsFKdz TqUJlc+CgB1v/I632IDVdj0FdRF4ZYNMJ+r2oYlg8y2zZG0VHGzCSERAFG9jFvjEg7cuac5ejQJ 7qMKRlJ4NyeECWY5eviLdcs2eMLmjWlv0rSFAOMg1n1AcUAWpCOczsynzZJ/hdBHm3iI3UxTSTk FZU8xq9om5kl554T0HAVKB1BeDYvr7XFAwBwI7YH/w++cqGxCH7bbaKoUwn0hIN+tZfwqpdw9Bg wagl7dnleptd6QeEKXrWJGO/a/Dt9S602UuEAyJiU+sSRCS13aDe7rPUMrYR/bKmIvj6xZjHt9w u92yDHXsKgOZbifEtZxUuVvY6Zj0bq30EGDfZsk5X58e4+gMTYpxAMkj2Bc X-Received: by 2002:a05:6000:718:b0:485:8c16:a341 with SMTP id ffacd0b85a97d-4858e703eabmr30026683f8f.54.1788957022389; Wed, 09 Sep 2026 05:30:22 -0700 (PDT) Message-ID: <1f371e61-8418-48d8-9382-ae8827e6b714@suse.com> Date: Wed, 9 Sep 2026 14:30:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/vmx: Avoid pausing on HVM_PARAM_IDENT_PT in additional cases To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1788956067.8631fc262581453bbf619ec5b2062170.1a086174641000c4f3@vates.tech> 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: <1788956067.8631fc262581453bbf619ec5b2062170.1a086174641000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788957023-F68B62A1-6ADAA26D/0/0 X-purgate-type: clean X-purgate-size: 500 On 09.09.2026 14:12, Teddy Astie wrote: > When settings HVM_PARAM_IDENT_PT, skip domain pausing when : > - there is no vcpu > - unrestricted guest capability is used > > Signed-off-by: Teddy Astie Reviewed-by: Jan Beulich > --- > Regarding checking for hvm_paging_enabled(v) (proposed in v2 review), we can't > as hvm_paging_enabled() is vCPU specific, and vCPU 0 may have a different value > to another one. Ah, yes, of course. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:42:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:42:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412968.1643240 (Exim 4.92) (envelope-from ) id 1x4HdL-0002Et-BG; Wed, 09 Sep 2026 12:42:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412968.1643240; Wed, 09 Sep 2026 12:42:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HdL-0002Em-8V; Wed, 09 Sep 2026 12:42:35 +0000 Received: by outflank-mailman (input) for mailman id 1412968; Wed, 09 Sep 2026 12:42:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4HdK-0002Ee-4v for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:42:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HdJ-002mwj-HH for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:42:33 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15433-2eae-0a2a0a5409dd-0a2a450abaac-14 for ; Wed, 09 Sep 2026 14:42:33 +0200 Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15439-f2d2-0a2a450a0019-d155da2ad04e-3 for ; Wed, 09 Sep 2026 14:42:33 +0200 Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c2544ff970dso856439666b.2 for ; Wed, 09 Sep 2026 05:42:33 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d57fd88sm739635066b.44.2026.09.09.05.42.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 05:42:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788957753; x=1789562553; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=c1ynL1CBn4CZNWbSyyocQzxmKFO9Hsc7Fep/W5P+d2M=; b=qe7M4gsgOK5TIAtXRCDYVaYY9T+0VVoOKjOOi0MPtt/+elJkSAPDS87weInZ36YS+H tCPadfGCRXfi9zJrrYBdKq4iVXBJlhxJ5apanSro9dN2aHxvJsLE9wpEMYXPZZKuNOEW mUL/dNnkHGEPRs7RiyL6MbjWHXDtsHOt7gVnqRIOFlGt/riqCtjc2ynwQowyqXmZT0SL s8G4JmblI8L0VTR7xiJsy4y1Gw/sVc+WZSAx/WbR9JCLUDdOmabKWXi1q5KxN+CKr+eK QayCrfejIdKvclQ9uaHaPJQ5oLLa8lPz36vqVZfGcMpQIyqXYoTqagOX/lbbWCHdbQP6 AQow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788957753; x=1789562553; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=c1ynL1CBn4CZNWbSyyocQzxmKFO9Hsc7Fep/W5P+d2M=; b=PTiLlQtQtaMYPZEVH1Dhm7wnvVVoZOpAi24EwKVbG0NWL68Ena3raWL6Kk7d88koOV BJcu+FSaDEVQZP0zFCHtNPcZjisqkyE/FaM4JFl6/RoubHsEqJ1b7PRERUPwDWEL3Gi2 qwgJetPqNIUifxGDEIsW3bC9N7+k4tzRUnco8c0vQUCz1uaTN2C2MjWutsK96ecVgmrW JtvdbWn2nxxQCfCU4TXD7yno1OqYzl7luWsipQjdOlUimCpV+6EQCkOPlM1TO18ghuVE W/Eu+bbDtlNZI4nRz9gPBOEoxO3biPKyH6iA4oXT+OCNSi7kYKwWEXuYrUreXWu4ybjO vRXA== X-Forwarded-Encrypted: i=1; AKwUvBz1sHhJ6mTUNX7YQuURbL3TBJeP2V1mBgMivJfbLJ7ILi/jA+PEoENvXDq7wPKGWL6FTaCqAZeoHHI=@lists.xenproject.org X-Gm-Message-State: AFuF++m3/kwpU/V8ibkhMUuq6ROR6TdXGIKv9Al+2GYcnf6HyZ2AXnVC /5B/nwXOEQ06L/Fy/tBodPfI9t5dXiW5EuLuTgHLiIQ/7sWaNVjltQyb X-Gm-Gg: AYBFou0i4kg+GdcjbJc2he6AUL6e/HqNGQgm2Ai2MYTccXMD4K+v1bIYBZmiYmpsCN/ +xexhZSN29I8w3fgmEL3jrXqJfSJqr1BsFAu8fzItwZADR95wFzX9i8K76CJoMs9JjONXJshs7f GZbRFDCjo69iBZjH5EDOnNsBomC2XGDRKGQrHalrvxYKZDmA6/j13JlzgcdGYaEtc5BDSswJWtC 7fXry0QU1K7Dz4tLKeZexrHUd90hT1Zb5d4LZeFWf3vNewuJLcI1IkWN9+szHRcmjz2PFnRPvkw t7oHBRduQAJtOo51QI/+SQGr1BWh3v27hcFDQ70z8L5fpt9pRhAOpRMCLLMaqVg3xfGACRBl0Dl Hp2IfEAGq8Hai5KWimOCsHDfkeSMpstM3cMwQeGeqRgRl9SwujfaPJ06jAFx2yYejDwVsiORWa5 wrpDhBsqeB3XBo90wiYedpoU8+tx+W3pfxt16p6Z4bniTbByKI7kyb5L8/GMOVO+zOkpQN/Ehbd oce+kRqcuZ7KXeWtjQFSt4YMYO1ocDv X-Received: by 2002:a17:907:3f88:b0:c26:1649:47b3 with SMTP id a640c23a62f3a-c2616495639mr1228111666b.41.1788957752467; Wed, 09 Sep 2026 05:42:32 -0700 (PDT) Message-ID: <7ee299ac-7ed3-4e37-92bc-ba8ee5bec3bd@gmail.com> Date: Wed, 9 Sep 2026 14:42:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> <39841f44-2b18-4368-a9f8-7c0db307ff6d@suse.com> <09c883b1-38fd-423c-b516-d39865729e18@gmail.com> <40c2524b-ab7e-461a-9113-ceee0560a918@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <40c2524b-ab7e-461a-9113-ceee0560a918@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788957753-536D6CFC-973C0FA6/10/73395122804 X-purgate-type: spam X-purgate-size: 2815 On 9/9/26 2:22 PM, Jan Beulich wrote: > On 09.09.2026 13:20, Oleksii Kurochko wrote: >> On 9/8/26 3:44 PM, Jan Beulich wrote: >>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>> @@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_table_entry *ex, >>>> regs->sepc = ex_fixup(ex); >>>> } >>>> >>>> -bool fixup_exception(struct cpu_user_regs *regs) >>>> +#define CHECK_GPR_INDEX(num, name) \ >>>> + BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) \ >>>> + != (num) * sizeof(unsigned long)); >>> >>> Nit: Placement of the !=. Also there should be no semicolon here; it wants >>> to ... >>> >>>> +static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, >>>> + unsigned int num) >>>> +{ >>>> + /* >>>> + * The GPR number -> struct index mapping below relies on x0..x31 being >>>> + * laid out at the start of struct cpu_user_regs in architectural order, >>>> + * matching the register numbers GPR_LIST() hands to the assembler. >>>> + */ >>>> + GPR_LIST(CHECK_GPR_INDEX) >>> >>> ... appear here instead, for this to actually look like a statement. >> >> I will apply that. >> >>> >>>> + ASSERT(num < 32); >>>> + >>>> + return ((const unsigned long *)regs)[num]; >>> >>> What about release builds? You'd happily overrun the array there. Maybe >>> (ab)use array_index_nospec() here? >> >> num is coming not from guest, not from calculation in runtume, it is >> generated by assembler at the build time. So it should be always correct. >> >> So just having the following looks okay to me: >> >> static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, >> unsigned int num) >> { >> #define CHECK_GPR_INDEX(num, name) \ >> BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) != \ >> (num) * sizeof(unsigned long)) >> >> #define GPR_CASE(nr, name) case nr: return regs->name; >> >> /* >> * The GPR number -> struct index mapping below relies on x0..x31 being >> * laid out at the start of struct cpu_user_regs in architectural >> order, >> * matching the register numbers GPR_LIST() hands to the assembler. >> */ >> GPR_LIST(CHECK_GPR_INDEX); >> >> #undef CHECK_GPR_INDEX >> >> switch ( num ) >> { >> GPR_LIST(GPR_CASE) >> } >> >> #undef GPR_CASE >> >> ASSERT_UNREACHABLE(); >> >> return 0; >> } >> >> Any thoughts on that regard? > > Depends very much on how efficiently the compiler translates this (as opposed > to the other variant). It is worthier. I will follow then your original suggestion and use array_index_nospec(). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:57:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:57:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412977.1643248 (Exim 4.92) (envelope-from ) id 1x4HrX-00044i-GT; Wed, 09 Sep 2026 12:57:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412977.1643248; Wed, 09 Sep 2026 12:57:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HrX-00044b-DL; Wed, 09 Sep 2026 12:57:15 +0000 Received: by outflank-mailman (input) for mailman id 1412977; Wed, 09 Sep 2026 12:57:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4HrW-00044V-5v for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:57:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HrV-00DR3s-4Z for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:57:13 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15799-8faa-0a2a0a5109dd-0a2a4504b648-44 for ; Wed, 09 Sep 2026 14:57:13 +0200 Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa157a8-b57f-0a2a45040019-d155da2ff101-3 for ; Wed, 09 Sep 2026 14:57:12 +0200 Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-c2940d16190so35122966b.3 for ; Wed, 09 Sep 2026 05:57:12 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c262c770678sm607825566b.53.2026.09.09.05.57.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 05:57:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788958632; x=1789563432; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=FICCDewFemx7amMe/5cJmWLejfHXoU9z6m0V9R07YpM=; b=sp+O841w43xuESop50MfnmtBz2X86GB7s8Z2Os9G2qFU1rdF6FVsc5iB5xownpMmRj 0FDDQLyn6dhEG6rnZhe8s8TtHZxHTLVJuIZC6vyfg0KYKaLEp4dfoc4BXqpNDIfkqUBz 2GMujIiw7AkDjS4l1wYbBBa59/c2DNtGp2kDtNsZf3xysvoZh8Yb0r2nm17tsDd3nmiZ 2wO1D/2Q4T6uHu9GKLBU4hqhfBxeKxnYol01NMBi0EBfOEX8eRjvKkFrkJjkpbOJ0gxZ WDETjwZolvoJ2sz7PDx6V8lsgzSxEMwzLJ63WWMhkdmfjBc1SyOX1TGYmk6R2R0nbL8j aO/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788958632; x=1789563432; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=FICCDewFemx7amMe/5cJmWLejfHXoU9z6m0V9R07YpM=; b=GWwq07ZFM/3mll3V2Z16MmPc9r3NpdSN3tQvMRgFxdT+lG+wq8qCubtiRRVt54tr5W 5E5VqHYZDWqZhya9n2v9LHyrRkg6RSIG1eXtgd77PiqSkZyktvwINeJ1UOV45qh+fT9+ a3Wu1tp/8nsbtIPXh3w2LyYCLBJhhv/YfsuRkXq90yKDa5vCLq4L4AdaWzT9zUba1YvK 7ZXLgUFiYQHXM62PlYvYKph86wsZLITLgZvOW+bD+5fMCySlSzceiNmGVuTls//wHaQ7 raP3TeHiXxpdfix+jWsKmv4RH2HJ/+TwSpd67nEsGRp58MrOEVzAIiw/T074W6wYdMkz yGRQ== X-Gm-Message-State: AFuF++nEEhIshWMeflAohf+ZpgNCFyIffnAcrVoJrPfwK4v3uMiqSGY9 nd936n+zWVXzmb27rluzpj+TXvSAJ1QPaVrg/UGjG/RZrMei+eaLOTya X-Gm-Gg: AYBFou3n94Da+8yYGaK4n8e1XAsadqnSqrUBvO2fuYJSsDOfJjjLwDf/DLy0eJyatbp QuMU5nW4zimhSmn37yQJNNPUPhwqsx2SzKA9WcYfek8UVZCS5s05y46FBHdzM1LD2LHzFnp/k+R faqks9ElPVtMZG14yvm4m1i+f5R5FTkFDGeEUClr96FH5dFX4BVKMIjYmiDspLn+DsaSc9xmUDG JS23gDEnDdDD+TJTjiRUlakAvebjbFAgHhvdeiLGz1Y1fn2Roo9galHwm+NaIWI8tb8FHmF07tX WKU4GdDfHa9wWxknihHDH3GOGbFW0w7MKbJprOyb8EPdh8ZAduvJkPdwLzkBp3xRO8jesBhtubn A17RO6FSxDyzlfrbLJcF8Q0SPC1sUg+xup9RKif+ioJPToB9vv4SJtTTyvsS1EltSK3cn6p/neg zM68vmfSM9PoktvlEOQYfJkXCSwmgLThRDY3DlWxk0qv1spIXIM7NN8KOPCiuRi4i+a9ynVXCgu P5w8YME75lok4tQF4TaDGTNPvZ6yH7V X-Received: by 2002:a17:907:3f98:b0:c26:19e3:e988 with SMTP id a640c23a62f3a-c2619e3ef32mr1274834966b.40.1788958632374; Wed, 09 Sep 2026 05:57:12 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 14:57:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 17/39] xen/riscv: decouple INSN_PSEUDO_VS_* from the hypervisor's XLEN To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <2a69992aa02ff114237ec27204cfac0f8278b1d6.1787838835.git.oleksii.kurochko@gmail.com> <1788796633.8631fc262581453bbf619ec5b2062170.1a07c9682ec000c4f3@vates.tech> <9a7dea59-be4a-4dbd-9935-f48e24adc009@gmail.com> <1788883499.8631fc262581453bbf619ec5b2062170.1a081c3f83a000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788883499.8631fc262581453bbf619ec5b2062170.1a081c3f83a000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788958632-51AD0B50-452F3C23/10/73395122804 X-purgate-type: spam X-purgate-size: 5778 On 9/8/26 6:04 PM, Baptiste Le Duc wrote: > On 2026-09-08 11:34 +0200, Oleksii Kurochko wrote: >> >> >> On 9/7/26 5:57 PM, Baptiste Le Duc wrote: >>>> htinst reports a pseudoinstruction when a guest page fault is taken on an >>>> implicit memory access done for VS-stage address translation. Four such >>>> values are defined, differing in the access type (read or write) and in the >>>> access width: 4 bytes (0x2000/0x2020) or 8 bytes (0x3000/0x3020). >>>> >>>> That width is the width of a VS-stage PTE, i.e. it follows the guest's >>>> paging mode (4 bytes for Sv32, 8 bytes for Sv39 and wider) and has nothing >>>> to do with the XLEN Xen itself is built for. Selecting just one pair with >>>> where a guest running with VSXL=32 and Sv32 in vsatp produces the 4-byte >>> Sentence is broken. Guess you mean "Selecting just one pair based on Xen's XLEN misses the case where >>> …". >> >> Likely it is becuase of my low level English but it seems that original >> version wast okay and what you added is just a part from prev. sentence >> but I will add your suggestion for better clearness. Thanks for noticing >> that! >> >>> >>>> forms. Such an htinst would not be recognized as a pseudoinstruction and the >>>> fault would be mistaken for an ordinary MMIO trap: Xen would fetch and >>>> decode whatever instruction sepc happens to point at (unrelated to the >>>> access which faulted) and emulate it against a guest physical address >>>> derived from htval, which for an implicit access holds the address of a >>>> VS-stage PTE rather than of any access the guest performed. >>>> >>>> Define all four values unconditionally instead, named after the access width >>>> they encode rather than after the build's XLEN. On RV32 the 8-byte forms >>>> simply never occur, so recognizing them costs nothing. >>>> >>>> Dropping the ladder loses no build-time coverage: a build for an XLEN other >>>> than 32 or 64 already fails on the equivalent ladders in asm/asm.h and >>>> asm/config.h, so no replacement #error is needed here. Adding one keyed on >>>> CONFIG_RISCV_* would in any case re-introduce exactly the conflation this >>>> patch removes. >>>> >>>> This diverges from the imported version of riscv_encoding.h. >>>> >>>> No functional change: the values have no user yet. >>>> >>>> Signed-off-by: Oleksii Kurochko >>>> >>>> diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h >>>> index c63e5e3046..2d2e7e11b3 100644 >>>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >>>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >>>> @@ -839,25 +839,17 @@ >>>> #define INSN_MASK_FENCE_TSO 0xffffffff >>>> #define INSN_MATCH_FENCE_TSO 0x8330000f >>>> >>>> -#if __riscv_xlen == 64 >>>> - >>>> /* 64-bit read for VS-stage address translation (RV64) */ >>>> -#define INSN_PSEUDO_VS_LOAD 0x00003000 >>>> +#define INSN_PSEUDO_VS_LOAD64 0x00003000 >>>> >>>> /* 64-bit write for VS-stage address translation (RV64) */ >>>> -#define INSN_PSEUDO_VS_STORE 0x00003020 >>>> - >>>> -#elif __riscv_xlen == 32 >>>> +#define INSN_PSEUDO_VS_STORE64 0x00003020 >>>> >>>> /* 32-bit read for VS-stage address translation (RV32) */ >>>> -#define INSN_PSEUDO_VS_LOAD 0x00002000 >>>> +#define INSN_PSEUDO_VS_LOAD32 0x00002000 >>>> >>>> /* 32-bit write for VS-stage address translation (RV32) */ >>>> -#define INSN_PSEUDO_VS_STORE 0x00002020 >>>> - >>> Whole point of patch is these no longer depend on build XLEN, yet >>> comments still say "(RV64)"/"(RV32)" which could be confusing. Maybe it >>> should be better to indicate, as the spec does, that RV32 values are >>> used when VSXLEN=32 (only sv32 paging mode) and RV64 values when >>> VSXLEN=64 (sv39+ paging modes). >>> >> >> Could you please clarify to me what in the spec it is? > > It is the same table as you indicated below (but mine is Table 56, so it > seems we don't have the same spec version, I'm using the version 20260120). > > When I found unclear is that "RV32" or "RV64" alone is ambiguous, > since host and guest can differ (e.g. RV64 host running an RV32 guest). > Saying it depends on VSXLEN instead makes clear which one is meant. > >> >> This comments are just copy from the spec: >> >> Table 39. Special pseudoinstruction values for guest-page faults. The >> RV32 values are used when VSXLEN=32, and the RV64 values when VSXLEN=64. >> Value Meaning >> 0x00002000 32-bit read for VS-stage address translation (RV32) >> 0x00002020 32-bit write for VS-stage address translation (RV32) >> >> Value Meaning >> 0x00003000 64-bit read for VS-stage address translation (RV64) >> 0x00003020 64-bit write for VS-stage address translation (RV64) >> >> So the comments are just copy of "Meaning" column from the spec. >> >> And I think that Meaning column is fine here as we could have a case of >> when hypervisor has XLEN=64 but guests could be on it RV32 and RV64 and >> if a guest is RV32 (what means VSXLEN=32) then the comment above >> defintion mean that we hav 32-bit read/write VS-stage address >> translation for (RV32) guest and the similar is for RV64. >> >> Do I miss something? Is a comments make more sense now or I have to >> still update them in some way? >> > I think it would be more clear to modify the comment by that: > /* 32-bit read for VS-stage address translation (VSXLEN=32) */ > > But now with your explanation, your comment is more clear as it specify > VS-stage address, so the guest. Feel free to adopt my version or not. Agree your suggestion here will be more clear. I will apply it. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:57:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:57:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412981.1643257 (Exim 4.92) (envelope-from ) id 1x4Hs9-0004aB-O4; Wed, 09 Sep 2026 12:57:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412981.1643257; Wed, 09 Sep 2026 12:57:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Hs9-0004a3-Kt; Wed, 09 Sep 2026 12:57:53 +0000 Received: by outflank-mailman (input) for mailman id 1412981; Wed, 09 Sep 2026 12:57:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Hs8-0004Wj-Cd for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:57:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Hs7-007kK0-L8 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:57:51 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa157be-e002-0a2a0a5209dd-0a2a4504c4c4-46 for ; Wed, 09 Sep 2026 14:57:51 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa157cf-b57f-0a2a45040019-4a7de14c8594-3 for ; Wed, 09 Sep 2026 14:57:51 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-484366874b0so568600f8f.2 for ; Wed, 09 Sep 2026 05:57:51 -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 ffacd0b85a97d-48594172546sm35614885f8f.15.2026.09.09.05.57.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 05:57:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788958671; x=1789563471; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=HnVr1jyQc0qSmMH+0ikdTdtbkkw9KPu6ZvDPravnleQ=; b=WkNP6Ulga1KqEUvv//U4myJTvW8zpKs9MfESyL5ErY0bMq5gDhubXcpC1vZrJkqG/F WjaaxvtOS80uaSYqMZiaCLhylGda17YzLkIDSAi+mkQtV5wh4H4Q4WKrcFDBN36XcRKW 9m6tKGRO30j0UQyPaysCy+WtfNcW7ifon2RuiyuuKpXZxdLAeLeNq0qxJM2ZgyBKAaCZ Ki7j4ziwkvibuGVcVOyN75P1OFvjcQaHgA5ECCeEyKssxjKenZIQjN59t5Nkxg5YE720 bzVDUHpSvPL/L5JYConmU+OZt1kM5y7QyUtAU7uWHKoKN7r+TJr136aI47dhxU9LAQUr VbhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788958671; x=1789563471; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HnVr1jyQc0qSmMH+0ikdTdtbkkw9KPu6ZvDPravnleQ=; b=lM1jIlb/3w9xFgzDqCIZJqQTssaqCyrKfbc/drI6x7zmxayULrM1bhJBtM+qQLWvLx RpZAAdb3uxifwrxc1XPZqH4y1wcyk3jdSrawgbBzM7gHE0XabMk0lgs6MvoyeByjENz0 PxM6hdIsNz4Ge1RHJrJQkuGCzNPPPN3vTZ39BjA577DZXwj2qULIGQzyoK4luU2WRJRM /TsPEe9VrFJmMpWXnA+4AaHeRxMCthidzPKNL/zYkDlpLrA2QNgPoJeK6f5S+NdwcWVY +gJqM0lrvBBuRHNBBFIFiPttHtvcniJHZKCiO38jNVySCuchW8uWCczozRuk8nLbD3o1 /VmA== X-Gm-Message-State: AFuF++mmEknnXYvOLrejBPbBIegBcIdznZ6NymSJ/w/I+Pn+gwIC0yzS +rapenzQtUehhet3DvvF9qCFrubBG+rK9xfDm5RLMmYU02xGYoS66zAwhTTx86CUsoTeH6lmhov nrVc42g== X-Gm-Gg: AYBFou0pD/LnEs2LILGHwcYaz11hxtsheUPqS0GNOaLCa2UAx9wMQ8qTxb5UN0yW44p um5tz7awyoHaKApUBotccneGvmxOU+3gZT8cvMtUEbhSNoJmKcuMF8FZg//V2lXaHkB/nHkkFTn ZWDGx0LkdEzkXfDi867jNIu6Ul3gyEJELzzJiUhnaJPjGjCQoD7UWAtPLUbI7CamocCxpmtBpYk Lch56DP9Q6nO6JTTsN3fVFqJrsgOhs5T9hH7MsUijQ4kCCZXj55hGe80fI+x5wdQ9X7X/E8TAha 4rwpNBbPA8LX1cHJgNVd43QSNmqfObgxYAh5Nz4MXuZ/39f2PXhdYDV2wtamrQiyV9qHtI67OPd 5qG0SQI1zLUlsQmVa3ByMDJawDyzKFDdUHucrOAtEiKKuz5cvfIPgla3Hue5ZMpa6M89/Cp425g R7ISObMMU9YgvLFooj1yfQT+REfk8uxO570a3ekly6u1X6FmXuDEJzl2+3LARZOIN07J6/TUdZF zliYZShBSEaXe+NImVMsuFxlxSApltvBhM6XfyU2aSOqveE70hwQCVV6W9O5fk= X-Received: by 2002:a5d:59c8:0:b0:484:3604:c7bd with SMTP id ffacd0b85a97d-485aadd2ca0mr12920147f8f.17.1788958670865; Wed, 09 Sep 2026 05:57:50 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 14:57:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini From: Jan Beulich Subject: [PATCH 0/6] x86: address remaining rule 18.2 violations and mark clean 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1788958671-C3AC0B50-49217D01/0/0 X-purgate-type: clean X-purgate-size: 558 Arm64 is already clean. And all four analysis jobs have already been clean for rule 18.1. 1: PV: adjust APPEND_CALL() to comply to Misra rule 18.2 2: alternatives: adjust _apply_alternatives() to comply to Misra rule 18.2 3: EFI: adjust efi_multiboot2_prelude() to comply to Misra rule 18.2 4: cpufreq: annotate Eclair false-positives for rule 18.2 5: Viridian: annotate Eclair false-positives for rule 18.2 6: automation/Eclair: tag rules 18.1 and 18.2 as clean https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2832933871 Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:59:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:59:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412990.1643267 (Exim 4.92) (envelope-from ) id 1x4HtX-0005BA-0Y; Wed, 09 Sep 2026 12:59:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412990.1643267; Wed, 09 Sep 2026 12:59:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HtW-0005B3-Tz; Wed, 09 Sep 2026 12:59:18 +0000 Received: by outflank-mailman (input) for mailman id 1412990; Wed, 09 Sep 2026 12:59:17 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HtV-0005At-Dx for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:59:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HtU-002MF2-Qc for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:59:16 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1581b-bab6-0a2a0a5309dd-0a2a4504854e-16 for ; Wed, 09 Sep 2026 14:59:16 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15824-b57f-0a2a45040019-d155dd2bcd3d-3 for ; Wed, 09 Sep 2026 14:59:16 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-48441a2ba14so4887665f8f.1 for ; Wed, 09 Sep 2026 05:59:16 -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 ffacd0b85a97d-485883c074asm42807935f8f.23.2026.09.09.05.59.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 05:59:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788958756; x=1789563556; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=w7BwYGLPgsKXy885hcRpE5vhEVrFLgWJ5GO8dwiELeY=; b=ZIFov2F7D+xg/PTLsYfAMzErJlypSh6sXh5wgI6N2CyXZyS+19lE+aCVL3vRyDTsIF OyTTAWJ8hO+L9gRKpmsRCDWpQphi7+N5ybApfIElfnI8JmZ6pZgCvNoKFxf6HHWRRBKo iYz+HDSv0DS91ruPxPpLNqBHUm81m6VBw53MLcDV4cxsbR6H+CvHspt7UeFFJHtixmtV 0HCH4O5GDv+KODTs3x/jWjfXH/DJvo1U82E4kMcMCXuEEmavWNjtlQJu0ztcnVgEVceM nAb5ORGMhcgyYKzGwMUgRFhi7S0zTnp4qY++TSo+e2x51KZNXtxbpTjOA7xOePHf1O2v LBmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788958756; x=1789563556; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=w7BwYGLPgsKXy885hcRpE5vhEVrFLgWJ5GO8dwiELeY=; b=aHd0lMUVH/IDPq8J1gY4u0XIjzNgqSHZ6VYGTiICkEKPvxbF4mxIWHlp/7UWZbGENy qL9p0jq5YDi4mi3O09O+7zkFOiSyMxbO7mNBWNsNRxKge2S1FZgaFeBqATjlb0bbd+AT GATXa3MAMcTUQj+UBUTIKGN9HjfaeDizHWXI0gm816QK4/ZJ40OE/RFuy3iszozqfvfR ZHGsVWY39PA/CRcJnqEX7OcFsOnStuc+iDDS9gncoPaKU8M1ujphZWUnl4eVd4k7Mgug KBz4U1CpyeV4yXg6gI11JXToHDrbWKTbCZSyZobK3ThsnUr6Odna7c8J9pccMGiONESp 5diQ== X-Gm-Message-State: AFuF++mXce3uup0C9WyJ/aQcAlnfNjbnWdhtBbHnQTPFMpRp6IQdeWZg j+HJMj+9CKrqnd1Cwm4E78PGJTN1pq7OzgQl05mp4avcbrIne8GS9J+OV3rZdJ/Ah1st3ZReVzr 0TrNtvQ== X-Gm-Gg: AYBFou2imAfbChjSQ2ZpN441X6kt8eT0IOlWnkuQUIOlXq2bt1BpMQuV7kU0xKT7XHJ /bCIwLPoeFtEC4qh5gCr/6ac1navtScLFcU4ZN06GBJwPttXVioxRp1GjWeNv+uGeoi+Rrkds9g +PmLIORj3oRmL/MDSsbD/U5nVrt+YRVHuKMLLjAJcKnmFXmixbhI0z8679Dc+tgwND+s8PBS3DA 82dESpjP8C2Vx7rS+s7j2GHcRtLsUxd3aDerkqVcdGuRbO7nJx4HbmxtKyTKSqzfoJp4RtYMnpP 438MelZkHCxLJ5XO/ZjI9kkqevcvBnAeyg/arn2f63LMnoKtsu85rnltlspCbi4uG7f5s24hpGY nHrkNwjqwpoe6x2VjU1HEC5brZl5iay0+trNQuNCBocyVTB0u/wITKDkK7cB+BGlMKMrI7oocDM pifF9cIUb/WfA4nOP8M6pbxLxduQ6MW7WpDnyiyPEtMSnhGUB1kZ88SAHJXPUhzS8iUQD/1Imsu qEz4smBjYtBo5t8qgJH7Fm+aDdhb82LsA1Zkmjmm19UU2IcvGXfD92hQWV6PGc= X-Received: by 2002:a5d:5e09:0:b0:485:956a:1607 with SMTP id ffacd0b85a97d-485956a162emr22560186f8f.40.1788958756180; Wed, 09 Sep 2026 05:59:16 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 14:59:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/6] x86/PV: adjust APPEND_CALL() to comply to Misra rule 18.2 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini References: Content-Language: en-US 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 X-purgate-ID: tlsNG-ebf023/1788958756-583C0B50-2BB92F9C/0/0 X-purgate-type: clean X-purgate-size: 1268 While casting to pointer types may be more natural there, the subtraction then ends up violating "Subtraction between pointers shall only be applied to pointers that address elements of the same array". Use long arithmetic instead. No functional change intended. Signed-off-by: Jan Beulich --- Depends on "Eclair: relax long <-> function-pointer conversion deviation" to not introduce other violations in turn. --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -92,7 +92,8 @@ static io_emul_stub_t *io_emul_stub_setu #define APPEND_BUFF(b) ({ memcpy(p, b, sizeof(b)); p += sizeof(b); }) #define APPEND_CALL(f) \ ({ \ - long disp = (void *)(f) - (stub_va + (p - ctxt->io_emul_stub) + 5); \ + long disp = (long)(f) - \ + ((long)stub_va + (p - ctxt->io_emul_stub) + 5); \ BUG_ON((int32_t)disp != disp); \ *p++ = 0xe8; \ *(int32_t *)p = disp; p += 4; \ From xen-devel-bounces@lists.xenproject.org Wed Sep 09 12:59:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 12:59:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1412996.1643275 (Exim 4.92) (envelope-from ) id 1x4Hu0-0005e8-CW; Wed, 09 Sep 2026 12:59:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1412996.1643275; Wed, 09 Sep 2026 12:59:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Hu0-0005e1-9l; Wed, 09 Sep 2026 12:59:48 +0000 Received: by outflank-mailman (input) for mailman id 1412996; Wed, 09 Sep 2026 12:59:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Htz-0005cc-IQ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 12:59:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Hty-00Gv9n-VD for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:59:46 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1583f-8faa-0a2a0a5109dd-0a2a4503c250-14 for ; Wed, 09 Sep 2026 14:59:46 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15842-fae8-0a2a45030019-4a7de14caabc-3 for ; Wed, 09 Sep 2026 14:59:46 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-48583cc7ab1so106229f8f.2 for ; Wed, 09 Sep 2026 05:59:46 -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 ffacd0b85a97d-485883be709sm43699951f8f.21.2026.09.09.05.59.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 05:59:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788958786; x=1789563586; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=uiDbqnQFDxQWBEQL3jORPSdEhXKfJVufeVtoG8lnjEg=; b=Lw09bTqe/xiZX42hL+FofneeuaMNodhqY0csMH3ksA51qkGa+unXfcski+Se/MdECN 4RyMbIUouqQ5FZGpxR0Z+fTjCgq/8tJ4dYTN18+jWAecAM+LbZPbRgE/kJLqhQKtO4pD ZRc2qzhZpFYBuv5+C/aojnMalQzCG6qefdftbO+NFoGFaMlJ9cZn+EOUTV0T/W9aAbPo l9uwC+V2TyTzXceSfJ47ODpKQqssBFrIpl0+Be8orGA1qGfCbscnFo7nb4/9q7fjkXw+ xNuc5e8kIsrZk3x+bhBqZbYQcdWPRuqWR7TAFMxdNxzAkizizHiZbygS0Uc9zDyuKc2U lSeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788958786; x=1789563586; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=uiDbqnQFDxQWBEQL3jORPSdEhXKfJVufeVtoG8lnjEg=; b=SQOBMkCg+l0Nl+a71a99Jc8zBRLBp3eItrEaeUQf1wk9aup3ZGAr0SDlxfpbptSppR TKBcet4oQEt7g28OQgJcO8+Knx9ShimYmqdt7RPSSMOYEvEON0WBds/D5Q++vqLOIvSX 1qCSbCu3QMAN/a/0VCkstRE0NtFPq+4t9RQvcIDQBQK9vYRmIbIXWO6i18eiO9u/7Rou FxUip0WDgnk7uCrC3s2HYK+eVo+kA0/GlaHD/t4pWK5UOjXYXO4o2c1ydLaLOD/3DtrD bUJ0wTPm7mO/oqclV9y2Ex3HKLdg6+v7Fopblq2bxmDGHlWsJj6crSatjaZYp6P6X5/A GdmQ== X-Gm-Message-State: AFuF++myn5cpsYvXUGSAy2t+DFwPkg9YSzR3MJfgECEwv2KoW0AsReQB 6dj7PCHqa8TL3jEDN8gO2DUvswL1k1TkGzCYPj7PUv2An8MToa9viM0cp7lG0rpnzD95kCvIBGw +Rk9apg== X-Gm-Gg: AYBFou130pG8//s1bD7/ixiLYFBYt2tsbr/lKgLGio539Deabafz+ehK5MjG/4pZNcm YfXddFBD3jQZ46OlGSJ9c4gGEXPcA888jZ2CEWCZCu7nz4SupINag08y6xGvJh1OdX/129mreEg p6b1DeLw/fBON2lvHbMdKIEGa5if4VAqf6/8YZgyV/60Q+gIpKiurIQwAKWEDQl20CPjN67y3he DpQnANCXl5bOYW86l5+HDcgZU1yJcy/58JyohobP4+aBJ7pmM03GwKFZ6grLZbkfKiO+fwjdhOR d3gJKKLVeztz7f8O/FmHmiSLOYCc+lIQ9IdUaiwKg2UTtMoJ1o+dEySyiqPv9MZFOvXgyrAgSHt BCOWzILS/RV+r2gkxluRRqF8T8Swii/6FQDrhZGnGFgwfkitdfRD0/KK36Ia2gCbsvlXG2EUURF TeL9Xd7MP70JUhRmRDuOCCcORCUnMzfXfABpq3SQSnYGpIJmJKjuNfPs5ij8sxlgqJeD8qwWYEy g2J9MGA59GFkWwwkAxNryaZ+jm/cNGuyA0X7GRAQdrDdMI5L2bAgMHPA6dTxfo= X-Received: by 2002:a05:6000:400f:b0:485:8a47:5b91 with SMTP id ffacd0b85a97d-485c24042e3mr1415613f8f.46.1788958786307; Wed, 09 Sep 2026 05:59:46 -0700 (PDT) Message-ID: <6e503818-3446-4bdc-8b65-d61169667b7a@suse.com> Date: Wed, 9 Sep 2026 14:59:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/6] x86/alternatives: adjust _apply_alternatives() to comply to Misra rule 18.2 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini References: Content-Language: en-US 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 X-purgate-ID: tlsNG-33051d/1788958786-756834E9-296AE92E/0/0 X-purgate-type: clean X-purgate-size: 1138 While avoiding casts would be preferable here, the subtraction ends up violating "Subtraction between pointers shall only be applied to pointers that address elements of the same array". Use long arithmetic instead. No functional change intended. Signed-off-by: Jan Beulich --- a/xen/arch/x86/alternative.c +++ b/xen/arch/x86/alternative.c @@ -342,13 +342,13 @@ static int init_or_livepatch _apply_alte /* 0xe8/0xe9 are relative branches; fix the offset. */ if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 ) - *(int32_t *)(buf + 1) += repl - orig; + *(int32_t *)(buf + 1) += (long)repl - (long)orig; else if ( IS_ENABLED(CONFIG_RETURN_THUNK) && a->repl_len > 5 && buf[a->repl_len - 5] == 0xe9 && ((long)repl + a->repl_len + *(int32_t *)(buf + a->repl_len - 4) == (long)__x86_return_thunk) ) - *(int32_t *)(buf + a->repl_len - 4) += repl - orig; + *(int32_t *)(buf + a->repl_len - 4) += (long)repl - (long)orig; a->priv = 1; From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:00:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:00:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413005.1643284 (Exim 4.92) (envelope-from ) id 1x4Hub-00079R-Kg; Wed, 09 Sep 2026 13:00:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413005.1643284; Wed, 09 Sep 2026 13:00:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Hub-00079K-Hy; Wed, 09 Sep 2026 13:00:25 +0000 Received: by outflank-mailman (input) for mailman id 1413005; Wed, 09 Sep 2026 13:00:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HuZ-00077o-Uh for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:00:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HuZ-007Z4F-BH for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:00:23 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15865-e002-0a2a0a5209dd-0a2a45048c36-12 for ; Wed, 09 Sep 2026 15:00:23 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15866-b57f-0a2a45040019-d155dd30ec60-3 for ; Wed, 09 Sep 2026 15:00:23 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-4858be8b509so2614034f8f.0 for ; Wed, 09 Sep 2026 06:00:23 -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 ffacd0b85a97d-4858e239862sm38385950f8f.9.2026.09.09.06.00.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 06:00:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788958822; x=1789563622; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=bWlSSzoVmVaek1Pzh48/jWlFrsNac/GAHMWoEX91Hj8=; b=BAKaWvRFLX83BoeutOQIaqvh9Sy7KER39lULuFuDn+3jpfF+1OF9rOeNMCi0CmyO3O yVyUE81UtbmRVO0GGthdzvGuKjTgTl6tij0HU8y4KDVRq8bfBJEkHIo3EyOHIzwaxcTl 78aqslXjG/q7WBsGudUjFHLk+0kxK9w/02oJD3wX09GE0VEwjMQuKrtqR+VadOd+mwmO HRDtlTqNQlpecNP3pU3koPc7sBiEndxWmoSwsIFzPlMTR7HF/jfOFSvlVSs69RuEpJRk 5er3jTsmxDT2RNerURMkPMkeyPgsKEiRgKLTaTsRrEaGhmXYsAg0d9dSSm4QbYkTx/0O A1dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788958822; x=1789563622; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=bWlSSzoVmVaek1Pzh48/jWlFrsNac/GAHMWoEX91Hj8=; b=eTlT7sq4nAU77Q0RAUQSq+r52Upfvk91nmJinziVmvSscdPKiNCtyoqe7724ZW+mqj bNkqTo89ebJUZFJ7IDXcqZPpWR+A8uYtpAHQzqDN6m/pEN7tVBACALjlYEfbvxifXkrh Mo4cXE+6i08YKntXsrQmL1j2+wGJ04o+Q3cEsf0YdCAtby4k6X6l7KtYTC1vhoPQNG0e lLq89vL2cD8AH0YSOMLJDS9AtBNK7Xnmhp64rtAZY5+1O8CT9ctI5CdA5s1006ZW+x9E NiYxpBOmHAzNPXbuIbjWZ2W4FQGo/6r3oV6TcAp1Blqt9TmDwueuOGe/Wkp4UbZvh0vT Z2CA== X-Gm-Message-State: AFuF++k+GbxGDRXXpB9uXT8XAh17PjYDyZgSLa9sVRq0iSGwdH7Zxq4Q Oox7xwAOX26Dfqg1ScqwjdsGqrq3oeLVnW6f390llKtKyDrLIBRtSsx2zudmJH5ujF0kH9jbdiy 5muW0MA== X-Gm-Gg: AYBFou0bJCrJoNyTonBVBcvAdtbOlYToRry+tvVjJkGehCguTA5/DonXglhdgVVE2V9 QjfeKcSnhX5YwVP95yUBNDd5/1D1ozg+sbwuQdeG70ztTTfiHesb6xIal6JUIh7kQAG87GbTRTp dJSb5PnQlJ51+JLhXGlokuSbclNETqTH1x5yrjCGOsUe5AmbnQcCJQlkUMt3bzvgY57NpEKrodz tKWgPAvD8Z2++j2tclEcQ0nPVihFlsYCNKIAkBJNejRXYtlSRaCeoJqUmuAiud0jQ/4IsFEsCBD er10lyT5YqRHt3ECdxByVnf6b0yF3TCqWHk2p7Mk6nUewXLHYKpgJ5rEXpTbecY0vaTY20kPEbT S7hPlj1RvEqUH4h7rebwwgcSG4nTSw1zRaam3L8ccQGz0sA0xDgiGq4ZAAsjMmPRjvnMRzTTp6A /FQDwDCJAulZeL+ysQ65PDnCKxWCAInOoBhsH4AqfO6tqunX7qFxPOVhEaaUz7ZSO6tpA9Td0hX zSHKt+HeDa9GPANYQPuNsc6txIpYyaFU7FmfJpub1QnUvuO1af+bYn+tGPV2ycx X-Received: by 2002:a05:6000:985:b0:485:8b95:706f with SMTP id ffacd0b85a97d-4858b9570c4mr30979983f8f.13.1788958822351; Wed, 09 Sep 2026 06:00:22 -0700 (PDT) Message-ID: <25c71873-9043-40c7-a514-c7cd557f91d1@suse.com> Date: Wed, 9 Sep 2026 15:00:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 3/6] x86/EFI: adjust efi_multiboot2_prelude() to comply to Misra rule 18.2 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini , Marek Marczykowski , Daniel Smith References: Content-Language: en-US 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 X-purgate-ID: tlsNG-ebf023/1788958823-C38C1B50-5EB107AA/0/0 X-purgate-type: clean X-purgate-size: 1446 While casting to pointer types may be more natural there, the subtraction then ends up violating "Subtraction between pointers shall only be applied to pointers that address elements of the same array". Use unsigned long arithmetic instead. No functional change intended. Signed-off-by: Jan Beulich --- a/xen/arch/x86/efi/mbi2.c +++ b/xen/arch/x86/efi/mbi2.c @@ -13,7 +13,7 @@ efi_multiboot2_prelude(uint32_t magic, c EFI_HANDLE ImageHandle = NULL; EFI_SYSTEM_TABLE *SystemTable = NULL; const char *cmdline = NULL; - const void *const mbi_raw = (const void *)mbi; + unsigned long mbi_raw = (unsigned long)mbi; bool have_bs = false; if ( magic != MULTIBOOT2_BOOTLOADER_MAGIC ) @@ -22,10 +22,10 @@ efi_multiboot2_prelude(uint32_t magic, c /* Skip Multiboot2 information fixed part. */ tag = _p(ROUNDUP((unsigned long)(mbi + 1), MULTIBOOT2_TAG_ALIGN)); - for ( ; (const void *)(tag + 1) - mbi_raw <= mbi->total_size && + for ( ; (unsigned long)(tag + 1) - mbi_raw <= mbi->total_size && tag->type != MULTIBOOT2_TAG_TYPE_END && tag->size >= sizeof(*tag) && - (const void *)tag + tag->size - mbi_raw <= mbi->total_size; + (unsigned long)tag + tag->size - mbi_raw <= mbi->total_size; tag = _p(ROUNDUP((unsigned long)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) ) { From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:00:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:00:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413009.1643294 (Exim 4.92) (envelope-from ) id 1x4Huw-0007Ug-RM; Wed, 09 Sep 2026 13:00:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413009.1643294; Wed, 09 Sep 2026 13:00:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Huw-0007UZ-Oq; Wed, 09 Sep 2026 13:00:46 +0000 Received: by outflank-mailman (input) for mailman id 1413009; Wed, 09 Sep 2026 13:00:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Huv-0007U9-Cl for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:00:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Huu-00GvQy-Ps for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:00:44 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15878-bab6-0a2a0a5309dd-0a2a4505ae82-14 for ; Wed, 09 Sep 2026 15:00:44 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1587c-4cb1-0a2a45050019-d155802ad0fb-3 for ; Wed, 09 Sep 2026 15:00:44 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b392ccaacso84559025e9.2 for ; Wed, 09 Sep 2026 06:00:44 -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-49cfbdacc45sm443341775e9.11.2026.09.09.06.00.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 06:00:43 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788958844; x=1789563644; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=2hiugmH/DfrkMOq2Rrm79IM9Vi54MWLDW0uP3xzNUMw=; b=O59Mh62IrcM7NczrKaQbC8ZS7fQ9R4IrhfEKLKb3olmsvJ6nmr8H+oBl2ZE3LCv88e VLNCssv1PXwEYm62mnQ6U9J/Bv8Z76EN+7YzErjFXiGTje4IgzDuNP7vYjNdieUgcABi y4PZ2RAqwtQCGqxDIJyFT9Hti+B9Y+bAaMF1knZNgoBkeTpbK6+xdo5amgRlcEjkh+eT 05jcrPMl+kzaud9iWd3JQNOHhG+rq+8ChZLRpzFmt1Nf9rO7UOPqpbDJdxYO5l1Z7pYc 71sJ0R0DHC7Bn1lK1g2grh1i+MPpgYybIXjiUTsEFheZ0io6RjuzANjkpHXp4rsl2Ca1 AxvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788958844; x=1789563644; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=2hiugmH/DfrkMOq2Rrm79IM9Vi54MWLDW0uP3xzNUMw=; b=Lt23S2cXQ/8sX3SiElPjLUw8tTKVixe5+3eo8TJ3U+MyJw6lpMG51C0+8sE8mq+CT+ l0F0gmadZCT+gUBuln8lz6Y4aSso8+HhyDWmgIRFMU/JUYetNGOGVsWZjHPAsgrk5MNR JzQg8gNVNa7gWl+OYnT1AJaBJ0gt4Gui7x5LicqY4dtpqIyUHHK66QuxyM9lgJWBW7u4 UON8DIIBBerInoH1H6NZQ+Q7OlI1KLe65iIB3fpGa1W2vPkbTa4f2dBthUaxK8Y16Nrg PAELfuuRQP4+UqqAf1v7bsS1Id02E+txBZuLG0faLZdnaFcOszqlfSQHeplPHbpXqW6q eJxw== X-Gm-Message-State: AFuF++le/TWNnGFCQqkxC6RIMqttCXvvbU1GczLgeJBpNA448J5P29J9 usoCPMol/0y+VXFf9PbW/iOUpxbQ8ovdWu5Cz9hbQ7hqkgQmDHXy1h9rLifpenQAJq64blLucfz 6tQLgPA== X-Gm-Gg: AYBFou1O9C4JAI+ngXmiIUnnMeBxYLeOrwPyRDIUc3hsUQbhyoEbBNUvcWD5W+yea8z rUbhZ8h+pnSut9zcBO1/Rhg6vZ1tf1opDW31AYaNo3i/9BhKP+zMCUYf0YIhIMJqvBw0DAPdayg GpRCa8C0zEn4Amx27ampa7uu0xX+zuH/5TaFVG1u6mCAAf7aUEZvVaBx5tcqcpQaH8b++AOHlgO O00GfI+GaRuLsGMnDtCGSYrxIXoemU55GAiYK7lL+ijhPyPSQdFIZufXB1J+IGQBbBiGaoXnlA0 8Jkl0GviSIYw+fVkRnGJO1NlKtgKgu7v/Z7LQRkmW4qkFURsddt5FqYSHs9oYu01TDK+Lx2Dxxq 3Lf0B9AFeyV1jZT3WJUrxfGgDmRyZgaYnA5/7CgHGlOP7fGEyxXDJJ7TZ0LN/PmdCfoAydAyWJ4 1HBnI0W9TQ5I0tEcJUl6mHHGZjuDQZnrBxEAo93jovMLp65CzBmBDp/5pZb4h3GdG08nTQnXyRo 7NLPY8Ct7nq+fKzTlNW9UGCZrST5X1WqWqYQ0v7kg3ixOvrSWb1me2oosE8FXY= X-Received: by 2002:a05:600c:3b18:b0:49c:fa21:1c8a with SMTP id 5b1f17b1804b1-49cfa211d97mr298047735e9.31.1788958843949; Wed, 09 Sep 2026 06:00:43 -0700 (PDT) Message-ID: <6fe2a230-4c36-48ce-93c0-ee8d75500d3a@suse.com> Date: Wed, 9 Sep 2026 15:00:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/6] x86/cpufreq: annotate Eclair false-positives for rule 18.2 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini References: Content-Language: en-US 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 X-purgate-ID: tlsNG-c201ff/1788958844-724B42A1-9A133E62/0/0 X-purgate-type: clean X-purgate-size: 1941 "Subtraction between pointers shall only be applied to pointers that address elements of the same array" is not violated here. Elsewhere, on simple "e - s" Eclair manages to notice this; apparently "(end ?: e)" is too complex ("end" being derived from "s" a few lines earlier). Suggested-by: Nicola Vetrini Signed-off-by: Jan Beulich --- As per Nicola Eclair 16.0.0 has this fixed. --- a/docs/misra/false-positive-eclair.json +++ b/docs/misra/false-positive-eclair.json @@ -3,6 +3,13 @@ "content": [ { "id": "SAF-0-false-positive-eclair", + "violation-id": "MC3A2.R18.2", + "tool-version": "3.14.0", + "name": "Rule 18.2: pointer subtraction", + "text": "Cmdline parsing start/end pointers point into the same array" + }, + { + "id": "SAF-1-false-positive-eclair", "violation-id": "", "tool-version": "", "name": "Sentinel", --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c @@ -67,6 +67,7 @@ int __init amd_cppc_cmdline_parse(const { printk(XENLOG_WARNING "cpufreq/amd-cppc: option '%.*s' not recognized\n", + /* SAF-0-false-positive-eclair s, e, and end point into the cmdline array */ (int)((end ?: e) - s), s); return -EINVAL; --- a/xen/arch/x86/acpi/cpufreq/hwp.c +++ b/xen/arch/x86/acpi/cpufreq/hwp.c @@ -85,6 +85,7 @@ int __init hwp_cmdline_parse(const char if ( !hwp_handle_option(s, end) ) { printk(XENLOG_WARNING "cpufreq/hwp: option '%.*s' not recognized\n", + /* SAF-0-false-positive-eclair s, e, and end point into the cmdline array */ (int)((end ?: e) - s), s); return -EINVAL; From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:01:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:01:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413013.1643302 (Exim 4.92) (envelope-from ) id 1x4HvI-0007si-22; Wed, 09 Sep 2026 13:01:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413013.1643302; Wed, 09 Sep 2026 13:01:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HvH-0007sZ-Vf; Wed, 09 Sep 2026 13:01:07 +0000 Received: by outflank-mailman (input) for mailman id 1413013; Wed, 09 Sep 2026 13:01:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4HvG-0007rs-6S for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:01:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4HvF-005AXD-JE for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:01:05 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15887-2eae-0a2a0a5409dd-0a2a4505b5de-44 for ; Wed, 09 Sep 2026 15:01:05 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15891-4cb1-0a2a45050019-d155dd36d5a1-3 for ; Wed, 09 Sep 2026 15:01:05 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-482f2ee53e7so4308877f8f.1 for ; Wed, 09 Sep 2026 06:01:05 -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 ffacd0b85a97d-4859162f354sm36448884f8f.20.2026.09.09.06.01.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 06:01:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788958865; x=1789563665; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=RIlpRmcgmO+OHiE8JCj69D3pFRhEmMDX/T6up7aFl3o=; b=MJXRQgADLxW7XGDeadnxnsR+6jrttTbdcOkAPL/BfERs684KpfF1GDp4LaH6FptC+Z 9eyKo8rQv02Rev8qhsoAHyJKW+gJHKtWVoEBsB/oTfj6rGtSFd9ei2pf+wH5znz2RSIX DPqakSKhC9+MRFyQOtyg5HjmzpPfG7OIzUj5Q8bZLjLc04g4nBHl9ZCPMzbgkNi3soCh BIP1wrU6DkeUQ9+r7IB9wUbaAWCOr2UQVqkRt2qmVSX235zzqSlfDpnRvoOcX9q6CJZe MZ86O4lcpP8uVKQZWDqoeq2fm7VFoQBt8qfxcPxn3eJ5FekVp6lG7wIlDFWu12lRjuUE uVsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788958865; x=1789563665; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=RIlpRmcgmO+OHiE8JCj69D3pFRhEmMDX/T6up7aFl3o=; b=XzCLUgistFGxUWFA0ovMWbZDjw5FbTIaNutQtCLy5BCX6CTmdH4bLh8IBfNI/1AGBw oLDwwrAj5VR398VdbOtuxu/NieWNQmPlk5W6jOU8vhPHrfPcCZfxTxbQCm2rasCMdi3e 1zn004++PwjgC/m3It+plVvTGHfd7MXANizyjc7f3FT1ocm+OBf3bjdcTeS/kqR+jwuG U29LS1aIrF3eQQqEocRJFD4IbNqT6P9MQTZPUR2hoFC4JPZMeOXBVpMq0HQX/REbJrV5 DvEzB+TPsRUTQ+1uSNxZw6M1KxBc818XBbITVrK1/TSuV1K4RQo7r3OuPY+bJ1/g/63r AHww== X-Gm-Message-State: AFuF++mB13+RPpGEL1pSERPbnT42B0zAk+Uey4EjltVNCbVi/+kOAOY7 xYX0pcmWWKQoQHh5lwh1+J1cmoLDE13PedQIGHBioYytXpSb7Si3/HnYoCqz9nT2CNWplbZIoGU YWK/nHg== X-Gm-Gg: AYBFou2s0NlvcYpcNINXm/wNstmxm9tHuDwO/OMgKQmG+uUGbFWfkI+SPKzHFce8sBs /2prFGURtBcvJr8szR4B/zbB0MFWVcct2V24UryvFyEJyUXl+9z2wKcwTG+pmiliTFncLdEE2DE Gr5nOBh3sr/1RwUrOsRu8VT3v86ucgmqGZSsq+DWwl4aTvrK8mLpc9dk1+J9948vOefg4gXMogT 7PxwUe2RdWPwIuF60p0DYVipFrFOIPnxkXtTdG18oSFeYDBcHvobqAMhYi+oRB1UbJ/jTRF2Q66 MGtDEldddofudLIPT1g/zQo1mF+owz9LQLrxUxypoLvx9Y3bAHLS6HrI962CcCHz+kUiiK6oHrS x+HbPeRXWBPXtO0cPuH0pzg/9cUsNOaO95fFwGPoUlIDSUaL+vriaeDG5fDVz+zq9wElpy37pGy zhdrsZ2p1h86ctXbDVvYU8RJnwjLjhaPa0i/op+J/qOY5lZWH+X2RBAmdAiTPppFVgjrvy72cGo VLmGoy/PTTyiTchBtR5KlEeDu2MxGvd6J9M+S4RUKuHjLwkz1G7XljfcCn5zWA= X-Received: by 2002:a05:6000:2584:b0:482:b813:8315 with SMTP id ffacd0b85a97d-485872ac3b1mr39548042f8f.21.1788958864913; Wed, 09 Sep 2026 06:01:04 -0700 (PDT) Message-ID: <08038aa9-6902-4070-b49c-0a9ff113c786@suse.com> Date: Wed, 9 Sep 2026 15:01:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 5/6] x86/Viridian: annotate Eclair false-positives for rule 18.2 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini References: Content-Language: en-US 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 X-purgate-ID: tlsNG-c201ff/1788958865-F4EA12A1-AA17D865/0/0 X-purgate-type: clean X-purgate-size: 1863 "Subtraction between pointers shall only be applied to pointers that address elements of the same array" is not violated here: start_stimer() is only ever passed a sane argument, and stimer_expire() is either called from start_stimer() (using its parameter as argument) or as a callback, where a sane callback argument is also guaranteed to be set up. Suggested-by: Nicola Vetrini Signed-off-by: Jan Beulich --- As per Nicola Eclair 16.0.0 has this fixed. --- a/docs/misra/false-positive-eclair.json +++ b/docs/misra/false-positive-eclair.json @@ -10,6 +10,13 @@ }, { "id": "SAF-1-false-positive-eclair", + "violation-id": "MC3A2.R18.2", + "tool-version": "3.14.0", + "name": "Rule 18.2: pointer subtraction", + "text": "Viridian stimer index calculations use sane pointers" + }, + { + "id": "SAF-2-false-positive-eclair", "violation-id": "", "tool-version": "", "name": "Sentinel", --- a/xen/arch/x86/hvm/viridian/time.c +++ b/xen/arch/x86/hvm/viridian/time.c @@ -136,6 +136,7 @@ static void cf_check stimer_expire(void struct viridian_stimer *vs = data; struct vcpu *v = vs->v; struct viridian_vcpu *vv = v->arch.hvm.viridian; + /* SAF-1-false-positive-eclair vs is always sane */ unsigned int stimerx = vs - &vv->stimer[0]; set_bit(stimerx, &vv->stimer_pending); @@ -146,6 +147,7 @@ static void start_stimer(struct viridian { const struct vcpu *v = vs->v; struct viridian_vcpu *vv = v->arch.hvm.viridian; + /* SAF-1-false-positive-eclair vs is always sane */ unsigned int stimerx = vs - &vv->stimer[0]; int64_t now = time_ref_count(v->domain); int64_t expiration; From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:09:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:09:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413051.1643311 (Exim 4.92) (envelope-from ) id 1x4I3R-00013w-Tc; Wed, 09 Sep 2026 13:09:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413051.1643311; Wed, 09 Sep 2026 13:09:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4I3R-00013p-R5; Wed, 09 Sep 2026 13:09:33 +0000 Received: by outflank-mailman (input) for mailman id 1413051; Wed, 09 Sep 2026 13:09:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4I3Q-00013e-LC for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:09:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4I3P-002OaV-Jg for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:09:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15a8a-e002-0a2a0a5209dd-0a2a4504bb0c-4 for ; Wed, 09 Sep 2026 15:09:31 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15a8b-b57f-0a2a45040019-4a7de48cb203-3 for ; Wed, 09 Sep 2026 15:09:31 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254fa663c1so20678866b.0 for ; Wed, 09 Sep 2026 06:09:31 -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-49d1fd532dcsm54775715e9.1.2026.09.09.06.01.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 06:01:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788959371; x=1789564171; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=GEucQ5HDVmg61mzKURTSDX41DOGEMC5gWDJ5N9xWUyc=; b=Q3zNq+bFV0bFs0awn5kL0X+utm8IRwPlSuWI5ZVGPA8fbZWjIRY2gfjlIRUNtg07oW 4/Rs4J67T8C4cuJ/AetJPwBgbMumMUD45xEXHvIkEW6WSzBTDptE4NaFeaqUYOyMhbVu HNw6/nbmD1Dp9BjnKPDbwotg6u77gh5bkgAgmRgGG4gjNFtcPX1FgpJjsBuwy02NFkwr MaTkpBkpaCz3GYcniB7LrYIUmU4hM5TgVp613tCZf6g1CDjhsiL/1HTPHTjnShpuZeFl 6tvvEtB6azxHn1ol5jOUy/+FuGZPIpYMaiBQkBae5CEr6U7sgw1XeML5t/JaBcH6N+9U Wr1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788959371; x=1789564171; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=GEucQ5HDVmg61mzKURTSDX41DOGEMC5gWDJ5N9xWUyc=; b=KViceom6U5XD94jy9yZDh1QpB0NhFMnNM2QHDX57ws1y9wnDvIlhO7p9CnqmxEDDJs qHZPfrN72MUlnHYqihtim3fMZUk8A3LvMafTh8BzSqs8TArFLCp/GO5pJ9iwRxLYwRbs uXs4bNCVnBcC/61fUDX7iTa9Lfb9OpUMI4c0kF6ejrr31eXHZmyuJlCeH6dna+fKi9e3 WWU++UsKmvGwHdaXq5LjxN8XuKa6EZ9R+pnd7iy8dD44IUPfLEmZvG5UQori2/Q2qwEx NaDS9ispObRDdr2qxkJus1rL1lqprBVQcSi3jiuu8iTToTPx2BqU+ja1T440irnpri2C aGrw== X-Gm-Message-State: AFuF++kkoLPx69DG49LfWQ5AIQWGqKcpodPVrctosDOdjuHpt6fRXhOc B4wyQmoRwMrVVpXRUzNhcbSRukM2HKKSoHaZhWCHTXUM6Cqb0zdDnJFyyoWtlzrTF/I4y/r2Eoz dFMFb1Q== X-Gm-Gg: AYBFou0OPxvpSPgT+9c9lw8gQfP/+De5tP6nH593/fh3sJ8LuLenjKuxWXvWW5wBiGH mQQS+UL+Cx861G9sA8X4huLUyvB24RzMVgvLV9yQ7L+w5Daab0DPK4gj9bDlEp9VwyelLPOmCzc 7ZA4ScsXgAjn8QojQivWT+Xh6PH9cdVv9/ZCM8kdw5/nK3VSMmOu+nAx1jj8fD4Q1oX72UqiyNc cm4HVlcRusnfd7D2t1L+R96zQAScB+g6McxeFdBb7NGbtFEJlCSnC8wN3NJNdmJDE+zoTAi4meN b4xSsnwOuFi4Jtc6SHZz94e8DLRojyJceLlXJOyowNRimceJOVHUi8rLhA7UQZGaolp/zKDlxn7 XQQmnHXBAzeFUQaMxaC9wKsNGz1KCDIUDftvKBtHPbQhIEKTBaUWU/K0ai313kQVL8snN/z8w41 MDwJc36HGdiFMyXHkqTHjdP4jdq2CV78a70ZZk3Kkx29Mk02q+odQ35bHryg/rOPGF633sXsZvW p6AtM+W2/9/kJSfa9wrf+8ILH4wpVmXBGGkk+9sgDSbqiuPqnMfVzz0N5Tta9o= X-Received: by 2002:a05:600c:45d5:b0:493:f140:c3fb with SMTP id 5b1f17b1804b1-49d258f1d5cmr17648745e9.7.1788958916303; Wed, 09 Sep 2026 06:01:56 -0700 (PDT) Message-ID: <486cf199-33fa-4373-965c-d59a782ae6d4@suse.com> Date: Wed, 9 Sep 2026 15:01:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 6/6] automation/Eclair: tag rules 18.1 and 18.2 as clean From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini References: Content-Language: en-US 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 X-purgate-ID: tlsNG-ebf023/1788959371-C04DBB50-2D2A2FD0/0/0 X-purgate-type: clean X-purgate-size: 406 Remaining (x86) 18.2 violations were addressed. 18.1 was already clean everywhere. Signed-off-by: Jan Beulich --- a/automation/eclair_analysis/ECLAIR/tagging.ecl +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl @@ -80,6 +80,8 @@ MC3A2.R17.3|| MC3A2.R17.4|| MC3A2.R17.5|| MC3A2.R17.6|| +MC3A2.R18.1|| +MC3A2.R18.2|| MC3A2.R18.6|| MC3A2.R18.8|| MC3A2.R19.1|| From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:09:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:09:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413055.1643320 (Exim 4.92) (envelope-from ) id 1x4I3p-0001P0-3s; Wed, 09 Sep 2026 13:09:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413055.1643320; Wed, 09 Sep 2026 13:09:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4I3p-0001Ot-1C; Wed, 09 Sep 2026 13:09:57 +0000 Received: by outflank-mailman (input) for mailman id 1413055; Wed, 09 Sep 2026 13:09:56 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4I3o-0001Og-6D for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:09:56 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4I3k-006RyC-0G; Wed, 09 Sep 2026 13:09:52 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4I3k-004CwE-1m; Wed, 09 Sep 2026 13:09:52 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=oCWPexW5I9t37fhWl80Bh7/TVolgvm8ds9NR6cfQVGA=; b=xlKIV3rzict+yorOV66U0Fa2VZ wqb00/kjKIhm+BwzKbYaMa9Zg9K0M8VZcU4dj23PhFI+4BwhbKWDHSVAyNuuW0dE72SE5Z5xUvV8F k6s0pul9kZ4ISBL1O/fhCS0vLZDFh3rj/gYIZQbndUuE1TcZe0QuEChMwuaMem08VHTA=; Date: Wed, 9 Sep 2026 15:09:43 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/mm: limit deferred TLB flushing to PV owned pages Message-ID: References: <20260909072451.67324-1-roger@xenproject.org> <1cadfc6c-efc1-4e23-b778-1df97fd0fa4d@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1cadfc6c-efc1-4e23-b778-1df97fd0fa4d@suse.com> On Wed, Sep 09, 2026 at 11:21:51AM +0200, Jan Beulich wrote: > On 09.09.2026 09:24, Roger Pau Monne wrote: > > The current logic on x86 will mark all domain owned pages as needed a TLB > > flush before being re-used. However such TLB flushing is only strictly > > needed for PV domain owned pages, as those can keep a reference to the page > > in the TLB after it has been freed. > > What about HVM-owned ones which a PV domain has grant- or foreign-mapped? I've looked at grant pages, and that's handled correctly, a TLB flush is strictly done when the pages are unmapped, so there are no stale references in the receiver TLB one the grant is released (see gnttab_flush_tlb()). However I cannot find any forced TLB flush for foreign mappings, I assume this is fine because foreign mappings are not controlled by the source domain, and hence there's no need to forcefully purge any TLB references. However there isn't much that can be done here: forcing a flush on unmap in do_mmu_update() itself would be a high performance penalty. > > --- a/xen/common/page_alloc.c > > +++ b/xen/common/page_alloc.c > > @@ -1501,6 +1501,7 @@ bool scrub_free_pages(void) > > > > static bool mark_page_free(struct page_info *pg, mfn_t mfn) > > { > > + const struct domain *owner = page_get_owner(pg); > > bool pg_offlined = false; > > > > ASSERT(mfn_x(mfn) == mfn_x(page_to_mfn(pg))); > > @@ -1539,7 +1540,7 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) > > } > > > > /* If a page has no owner it will need no safety TLB flush. */ > > - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); > > + pg->u.free.need_tlbflush = owner && is_pv_domain(owner); I guess I will need to adjust this to: pg->u.free.need_tlbflush = owner && IS_ENABLED(CONFIG_PV); As keeping track of whether a page has been ever mapped by a PV domain seems overly complicated, and not worth it. > > if ( pg->u.free.need_tlbflush ) > > page_set_tlbflush_timestamp(pg); > > Imo whichever change it is going to be here, it definitely also requires > the comment to be kept in sync. Ops, yes, should adjust the comment. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:13:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:13:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413073.1643330 (Exim 4.92) (envelope-from ) id 1x4I72-00034K-Hx; Wed, 09 Sep 2026 13:13:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413073.1643330; Wed, 09 Sep 2026 13:13:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4I72-00034D-F3; Wed, 09 Sep 2026 13:13:16 +0000 Received: by outflank-mailman (input) for mailman id 1413073; Wed, 09 Sep 2026 13:13:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4I71-000347-Oc for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:13:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4I70-00GyZs-T9 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:13:14 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15b5f-bab6-0a2a0a5309dd-0a2a4506e2e4-16 for ; Wed, 09 Sep 2026 15:13:14 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15b6a-195a-0a2a45060019-a237832fbe66-3 for ; Wed, 09 Sep 2026 15:13:14 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 6FD744EE0060; Wed, 9 Sep 2026 15:13:14 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1788959594; b=hixid/nfu0DeRYxpIsUpAiRXT5SrL/MUPtnaebYcpk2lR8OpTMcw36XASYvZ9hu60ff4 w6MM3Aoq6CO46VugUnNss5dLiX2uj9CcLMD3MFDfY4C+t7yf7QPLsAjUUjucMSAHUgTeh YgETkrIvyYPf8I5hKQspJcuMO/nvc99MeFuyiWqg/57EsoP4/k761CmzYhH9Bia3vXWeE G+EDwXrPT1xY0t6MjgPi+ym3D7pUqug36ksqAplLqoAjdvEm4W/qpUliJi53pAUpgO8Nv SU23N1KH6fEak9pp6tQ2e7hEJBYNUqJjPTuRj0f14yRtZUDRsa5eZLg47r+50J4X8aLfG rbtIm5XqfzIUCWLWRN1ecyIulS5hNHxU6TcasBlfu/yFGdGwt2A1EKmEAlPrCM3KBniXw Qi9BPxthyDl/NpgTv4CQ4E6uJcUqKZ26+FYLRDg5vBTuJsBU3QWkCbmepc1pK/LiznKXO CBElrFJnaNnfKsubSLMmZYmmR3u9ETop39cc175ZM7AGSU9yzj6UXeNq7q9CTqJyB1pjc UBRevfXD316L9fOEt79XgyrloPBg0dsgD9YN7K+O6IeHSti0fc4dgNrL3LaHXCKRSezUn em4lrbHLbHZG9l/ZLUu7CjX9xm1K9gtFRqikv2uKMyM7qiBwobTcfILdg/kUDrY= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1788959594; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=N45BUT9bQLoOghpSgU8eM6kYG4cRMsUb3+R1YEfzTmw=; b=o9Cx/eci/4ZwjzPT9HCbJl4VQeuwBPTASDgcz2hxDZtc4H5kZnAQj1GV2hY1xacX29H6 ZnLihVPRfhUWxFEvgROIvUye1GzAnJhuTdPXKVXGpBHuuverKCP3QER4J3NcEWopmFcR9 r3gyLhiUPdpF10SNygRe8GcQ6lK3otWW3GNfNLMujZqee1yYJgVf1R4+rGpvCvrRyqdsf lECZIh+LHR3vfQLB7eekeRs6pf0YHFtS1odb3GqN7X4xT5sE1j/jc0yprCC2hougjheSv PngNmwWJkG/xXYvWAj3zDG90UM7WnOfrQk55rtrjgStm5Mx0jmomHOYINTZzPJz/AxhwN B7j+rpC+Z+vtw1OGTAZlG1jpI9nK01Mwl+jP/5ityZvl2U9akBF9PdMYlKjU6Di4aEBWs XGgpK/teOMfrF/cMGDtDD8LhiXvGUGWrGf1e9G5HIioIw/GJrpl0wFmB9kY53p94li6gD ti6IhmYf0pm6amJxCQcfFgbIM9g0WN6LSOq4mQwoJunZ3Wdq1YWU8Er0m34XqCPfJEKF4 MbvFjM5AvJXkO+rT+xY18un0sMDKSBKLyEBvH01mCcE5OeWJf2YvRx9S/BAb7rhl0yZdG F7+PwwPF25aqF1O3x2NfW4hAYjFZ/pa8XjbUX5HNSMDJGXu4kgp/GeHJC/3BClE= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Wed, 09 Sep 2026 15:13:14 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 5/6] x86/Viridian: annotate Eclair false-positives for rule 18.2 In-Reply-To: <08038aa9-6902-4070-b49c-0a9ff113c786@suse.com> References: <08038aa9-6902-4070-b49c-0a9ff113c786@suse.com> Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788959594-F667277B-BCC0AE2A/0/0 X-purgate-type: clean X-purgate-size: 2399 On 2026-09-09 15:01, Jan Beulich wrote: > "Subtraction between pointers shall only be applied to pointers that > address elements of the same array" is not violated here: > start_stimer() > is only ever passed a sane argument, and stimer_expire() is either > called > from start_stimer() (using its parameter as argument) or as a callback, > where a sane callback argument is also guaranteed to be set up. > > Suggested-by: Nicola Vetrini > Signed-off-by: Jan Beulich > --- > As per Nicola Eclair 16.0.0 has this fixed. Perhaps I didn't express clearly that the remark was about the violation annotated in patch 4/6. Here instead, a suitable reproducer is not yet available. Nevertheless, if the claim is true the approach to address the violation is still ok. > > --- a/docs/misra/false-positive-eclair.json > +++ b/docs/misra/false-positive-eclair.json > @@ -10,6 +10,13 @@ > }, > { > "id": "SAF-1-false-positive-eclair", > + "violation-id": "MC3A2.R18.2", > + "tool-version": "3.14.0", > + "name": "Rule 18.2: pointer subtraction", > + "text": "Viridian stimer index calculations use sane > pointers" > + }, > + { > + "id": "SAF-2-false-positive-eclair", > "violation-id": "", > "tool-version": "", > "name": "Sentinel", > --- a/xen/arch/x86/hvm/viridian/time.c > +++ b/xen/arch/x86/hvm/viridian/time.c > @@ -136,6 +136,7 @@ static void cf_check stimer_expire(void > struct viridian_stimer *vs = data; > struct vcpu *v = vs->v; > struct viridian_vcpu *vv = v->arch.hvm.viridian; > + /* SAF-1-false-positive-eclair vs is always sane */ > unsigned int stimerx = vs - &vv->stimer[0]; > > set_bit(stimerx, &vv->stimer_pending); > @@ -146,6 +147,7 @@ static void start_stimer(struct viridian > { > const struct vcpu *v = vs->v; > struct viridian_vcpu *vv = v->arch.hvm.viridian; > + /* SAF-1-false-positive-eclair vs is always sane */ > unsigned int stimerx = vs - &vv->stimer[0]; > int64_t now = time_ref_count(v->domain); > int64_t expiration; -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:24:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:24:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413086.1643338 (Exim 4.92) (envelope-from ) id 1x4IHn-00052y-Fi; Wed, 09 Sep 2026 13:24:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413086.1643338; Wed, 09 Sep 2026 13:24:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4IHn-00052r-Cj; Wed, 09 Sep 2026 13:24:23 +0000 Received: by outflank-mailman (input) for mailman id 1413086; Wed, 09 Sep 2026 13:24:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4IHl-00052i-VS for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:24:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4IHl-005GBf-CI for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:24:21 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15e00-8faa-0a2a0a5109dd-0a2a450ae004-20 for ; Wed, 09 Sep 2026 15:24:21 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15e05-f2d2-0a2a450a0019-d155802fe833-3 for ; Wed, 09 Sep 2026 15:24:21 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49d05d51553so35353515e9.2 for ; Wed, 09 Sep 2026 06:24:21 -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-49cf755c22esm477753945e9.0.2026.09.09.06.24.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 06:24:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788960261; x=1789565061; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=ZdXMlpi2UJ1gQjCY2civr/JHz6NVV18sHsTq8zd6vtU=; b=UfQbze8JDTpFPxfeU8C4OsLx/NStV91d2hWkyifiQdLk/vv39ZOTVM4QCRpc34pHjV H6itgwM7f2Bnq8dX12xlofngx1PtBfwUMdjEotXm4SIiOs7HBUyAVxydlHLUnQ1ObZdN CwK9oOwpOb+EizB2V2JmzV8Ozc079i7Dfc+ZwxgakIliCcAkqBARaU2snR2s0FbqA3GL TXkoo7NXrJEY/dBDSwLh6SDaQd0R3Sf5nOFpbLQZOfXKWQS1GUh7+GyUDHUDQppjlAOH 75BKYUdk9J9LQKwCKijnLr4RhpVEwP2c8zl4LjMNyctttPI3E7K2Fwinn2u7YO3uQh2R qAog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788960261; x=1789565061; h=content-transfer-encoding:content-type: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:content-type; bh=ZdXMlpi2UJ1gQjCY2civr/JHz6NVV18sHsTq8zd6vtU=; b=O1Oj5B0BHVB0aHYvCoybsyG1KImOag59wL6OgL3z+GDWQkr61EdWinmoNPxkY4WXKW 9VUDD5VYFXa7rFt3JFODw2RUu1eW5oEaodH0aG9jJvOJCO6aaFBQcWoNpUHTHniy/eyj gYZS1aFzgPTNtvVvNuktU4UYHPmvwgp8jyNLYWbl9PIy9skHWN0b4wMO6D1HBcLhcPVR ser49ai2K/ORxhCyAGm1n7LztsOg91xxbfhgyU4UthDtyEvhgaWOmMaJwDfpvGB8ny0s yZyZowo88NyRRJCnd9/3M7o85QEZU+LZFGdFSdy26AVGoMINaCWU09ckuZNkmVJCyrvB 4LFg== X-Forwarded-Encrypted: i=1; AKwUvBzLgwE34HK7CaQG4MQqPBrM/vxpzihK/RjGczN3nchbkBj51k4/hnH+uP30CMDK5ql+gq5H7zcn9t8=@lists.xenproject.org X-Gm-Message-State: AFuF++maKR6u08dKTX9R1c+ftp28brJcdyMdthZroyYnOKxJ5LbAW1Qo LmQd+p8k5eu9MYEO5ih+WNntAUpvLcje2x0c8R3ivTbuecreEeBjKThwsfFvB12qWw== X-Gm-Gg: AYBFou3cO2bKrKjd7+sZq1exIGtWuh0wXrQ7qYGyoNRT67vJDl0U3LxDZwOwukyrMa+ 2e+jhmykIlat0tfPO6uInSPUwUv0KhaPCl+iTpdJ9lopAvcJ7R6gfTQU/sA7SaEghWFnAc1d90a JmZaxjhCNhRDYbT4vWXZULihQcIXSpgZdKsdEtwiVPGF+4bx6iuLTKZJO0n8hMHcsETbOBJODja E0w/aI7kSj6HprH71MG4Jq8zNFGWZkFUgAy7eXf3hT3uHz4JXUJdwNptAlr2N0zmlcuItngeqDm A0hPQyzuSfV9JKp2OlLJ3Hn5HmEv6kpBCKYQmCdPkJui3vnYazUhDXMd3M9UiVUrr1RjJaYbvIM 5jmE6yIewvM/XLGhW5fvNkEmdEj9JrvCnxQIAef/M8KRAlcq1IsMDdDwsBQf+sUdn9RSb38QOM6 kchf7pey/7VCktzq56i/wjTScr8HFhB56OAfhsq5Bh+vMtVNyeNWB48LuqpMJf+rco/ptKg4wt0 XO7boRwO73DqC6r0wBuvbTMR4fsBK3y1pMnMuL79c9jl68MNYcePlW95TTKO1o= X-Received: by 2002:a05:600c:4ec9:b0:49c:fc6e:a3d2 with SMTP id 5b1f17b1804b1-49cfff39708mr304249235e9.17.1788960260646; Wed, 09 Sep 2026 06:24:20 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 15:24:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-4011c0/1788960261-593C4CFC-5AB7B9D5/0/0 X-purgate-type: clean X-purgate-size: 4020 On 27.08.2026 17:20, Oleksii Kurochko wrote: > --- /dev/null > +++ b/xen/arch/riscv/include/asm/mmio.h > @@ -0,0 +1,63 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +#ifndef RISCV_MMIO_H > +#define RISCV_MMIO_H > + > +#include > +#include > + > +struct domain; > +struct vcpu; > + > +#define MAX_IO_HANDLER 16 > + > +typedef struct { > + paddr_t gpa; > + unsigned int len; /* access width in bytes (1, 2, 4, 8) */ > + bool is_write; > + /* store: value to write; load: value read (set by handler) */ Nit: Comment style (twice). I'd also like to mention that enumerating access widths is prone to go stale once the V or Q extensions are supported. > + register_t data; > +} mmio_info_t; > + > +enum io_state > +{ > + IO_ABORT, /* The IO was handled and led to an abort. */ > + IO_HANDLED, /* The IO was successfully handled. */ > + IO_UNHANDLED, /* No handler found for the IO. */ > +}; > + > +typedef enum io_state (mmio_read_t)(struct vcpu *v, mmio_info_t *info); > +typedef enum io_state (mmio_write_t)(struct vcpu *v, const mmio_info_t *info); I don't quite understand the (need for) parentheses around the typedef names. > +/* > + * Check alignment and dispatch a decoded MMIO access to a registered > + * handler. On success (0), info->data holds the read value for loads. > + * > + * There is no "retry" outcome to handle: find_mmio_handler() returns a > + * copy of the matching handler taken under vmmio->lock and the ops > + * structures are never freed, so the lookup result cannot go stale > + * between finding the handler and invoking it. > + */ > +int do_mmio(mmio_info_t *info, paddr_t fault_addr, unsigned int len) > +{ > + /* Fault address should be aligned to length of MMIO */ > + if ( fault_addr & (len - 1) ) > + return -EIO; Better first check (or at least assert) that len is a power of 2? > +int register_mmio_handler(struct domain *d, > + const struct mmio_handler_ops *ops, > + paddr_t addr, paddr_t size) > +{ > + struct vmmio *vmmio = &d->arch.vmmio; > + struct mmio_handler *handlers = vmmio->handlers; > + paddr_t end = addr + size; > + unsigned int i; > + int rc = 0; > + bool overlap; > + > + if ( !ops || !ops->read || !ops->write || !size || end < addr ) > + return -EINVAL; "!size || end < addr" can be had shorter as "end <= addr". Whether it's worth checking ops to be non-NULL I question, bit I wouldn't insist on dropping the check. > + write_lock(&vmmio->lock); > + > + if ( vmmio->num_entries >= ARRAY_SIZE(vmmio->handlers) ) > + { > + rc = -ENOSPC; > + goto out; > + } > + > + /* > + * The array is kept sorted by base address, so rather than appending and > + * re-sorting, find the slot the new region belongs to and shift the tail > + * up by one. > + */ > + for ( i = vmmio->num_entries; > + i > 0 && handlers[i - 1].addr > addr; > + i-- ) > + /* Nothing */; for ( i = vmmio->num_entries; i-- > 0 && handlers[i].addr > addr; ) /* Nothing */; ? > + /* > + * Regions are required not to overlap; check both neighbours. Their > + * addr + size cannot overflow, as such regions are rejected above when > + * they get registered. > + */ > + overlap = (i > 0 && handlers[i - 1].addr + handlers[i - 1].size > addr) || > + (i < vmmio->num_entries && end > handlers[i].addr); > + > + if ( overlap ) > + { > + rc = -EEXIST; I fear -EEXIST can be misleading; it generally means _this_ range is already covered, not some sub-range thereof. > +void domain_io_init(struct domain *d) > +{ > + rwlock_init(&d->arch.vmmio.lock); > + d->arch.vmmio.num_entries = 0; The latter shouldn't be necessary, as struct domain-s start out zero filled. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:26:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:26:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413095.1643348 (Exim 4.92) (envelope-from ) id 1x4IK8-0005e6-UB; Wed, 09 Sep 2026 13:26:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413095.1643348; Wed, 09 Sep 2026 13:26:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4IK8-0005dy-R5; Wed, 09 Sep 2026 13:26:48 +0000 Received: by outflank-mailman (input) for mailman id 1413095; Wed, 09 Sep 2026 13:26:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4IK7-0005ds-DX for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:26:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4IK6-00CdEo-Mo for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:26:46 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa15e90-8faa-0a2a0a5109dd-0a2a4503ace8-32 for ; Wed, 09 Sep 2026 15:26:46 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa15e96-fae8-0a2a45030019-4a7de18ca237-3 for ; Wed, 09 Sep 2026 15:26:46 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d37b5so6546495e9.2 for ; Wed, 09 Sep 2026 06:26:46 -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-49d20fce7a7sm121098935e9.4.2026.09.09.06.26.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 06:26:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788960406; x=1789565206; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=VqN+bt1mKMsfmlOhfK9GOFdSVjaP+VQ5U5vmVdwoJfE=; b=DNfL9yXnxt1VRi0Cwmj8SVQ2rsdCDz1ynyFIfRT16ByZaSpHm0KVoORx+42gQ9Pb4z c97Pcy6xjbDQ25H2Ql6aDoBwSVtnExTetnda1wfp39jFPghi0yMn54kxBYIrq+QzqCrC lHO/f2AVvtltW4uLfqBD1ByJnC7AMP7tAC7kaoD/QC87SRNNUafv9k0wjFQPA+mD8LEq MO/UE5Rhzoji09vFBt7jxBdkxhIrHOASGC/5oO9dwRXPOv0wgo4aFV/NO9eM2VsCgg+i csU5QIers9B0xkPhNZDIer3BzzNRGkAFMGyQGGNB/nU8tSroMHScIVm54zB0aZcMTx4B 9mQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788960406; x=1789565206; h=content-transfer-encoding:content-type: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:content-type; bh=VqN+bt1mKMsfmlOhfK9GOFdSVjaP+VQ5U5vmVdwoJfE=; b=edjtTodv3xOugMXFRVNnoYk+3N4dSEjNTImdttYb8EliYne0/g5cVpAmJ3gpX6fJgh lCBvJiAus3MjRtvfZDieCfYr0MBY3Zei8FtHUWvwYZ5f5BQ6P1JjQEHevogBQRJ3h3rf 9nLHdOsZtiIKosdwoNH2RjaQdID7/hfjkLQ6Ud4XkWLWrS8QCz/5xERMdNfELfMy2R4f /K5mNlJbOO/N8r7uOO/lUudJd7F8cbctW9FAOPoZnQ1JQoYABVwRuq58STjzxz6hClw+ fgHW/MflsVYtl0g0rCs9RYu7KvPvRTCcsVQJuym06uy1zCdRB5a7SSxCcD4mELiSEew6 aS0g== X-Forwarded-Encrypted: i=1; AKwUvBwzbi9qoNKno0Nyhxkot7qWfK9YrgVbyGgxdEOeit1bNaVUe6FOxf7TivfaGBcALM71nZHKpgO7XsI=@lists.xenproject.org X-Gm-Message-State: AFuF++lDyG6K5QCI9+hwZeRlDdDC8ljJsDDXX/75yIwMA97VmLWy8DYo 84iyMo6bnTBMV78wNSRFRMLZWx5lpJ0D63gTcZk3KKGGT+19sgkp50YYvCBXeuJE0A== X-Gm-Gg: AYBFou3ZwxKmX74sWD4D/9RysTkdLI83/om7QDceDQ7z8rSYK89MfKYWutqT1unQtni fufQUMt4YgzSRKZEGTrQZVn4LgL9tTOTBab1mL5h5qIp1gMdlPe1xyZTCGjMAJeXCiOI7AayhPR +vnjrRt6clE5GWOvylqx7JSM/q3FLDt5GqqK6vydM6YBYiFfp4TuNzynAryZcWXBClLgDoYUHQA rb2q/YkyLTEzod3ryO+sOAVoBDqjJHaYOsekVY3Y+6KImOgoDnHHBf3zQkaL+fNiJTorZxTEQLs k0wSNLvugVHo/9yiXXlnxwvaHRBBvg4Yw5hCmwv4R6QFt27xXi5jA0f/O6ZhGvpr/3KYPgmPqmg 9K/Eg2y2vVIAOmQhnxv7NwT6ev4rZy4D4NuuydOueILz0mdq+bFzD04f7GyUqwSsHdfp2yVlNUO hEPKgpXhCcwVVcffNFi5lsKJ5MxYjGwJrTJXWj5NMzmjkUsW3lc/xQ5nAYlOxKiQlQSJtj0vwtG QuKpvktPrf+Zi8FV+eJaeM7rM5pHLQpyykFuCDS0eTV+JRwx2ef1mMuQgMQhNF1jUNa3ACx3w== X-Received: by 2002:a05:600c:3146:b0:49b:9105:cdaf with SMTP id 5b1f17b1804b1-49d1f32335amr104412935e9.8.1788960406113; Wed, 09 Sep 2026 06:26:46 -0700 (PDT) Message-ID: <4ed55315-4eed-4c68-9af4-7d96149bcf50@suse.com> Date: Wed, 9 Sep 2026 15:26:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mm: limit deferred TLB flushing to PV owned pages To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260909072451.67324-1-roger@xenproject.org> <1cadfc6c-efc1-4e23-b778-1df97fd0fa4d@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: 8bit X-purgate-ID: tlsNG-33051d/1788960406-766FB4E9-A3F80E5D/0/0 X-purgate-type: clean X-purgate-size: 2107 On 09.09.2026 15:09, Roger Pau Monné wrote: > On Wed, Sep 09, 2026 at 11:21:51AM +0200, Jan Beulich wrote: >> On 09.09.2026 09:24, Roger Pau Monne wrote: >>> The current logic on x86 will mark all domain owned pages as needed a TLB >>> flush before being re-used. However such TLB flushing is only strictly >>> needed for PV domain owned pages, as those can keep a reference to the page >>> in the TLB after it has been freed. >> >> What about HVM-owned ones which a PV domain has grant- or foreign-mapped? > > I've looked at grant pages, and that's handled correctly, a TLB flush > is strictly done when the pages are unmapped, so there are no stale > references in the receiver TLB one the grant is released (see > gnttab_flush_tlb()). > > However I cannot find any forced TLB flush for foreign mappings, I > assume this is fine because foreign mappings are not controlled by the > source domain, and hence there's no need to forcefully purge any TLB > references. However there isn't much that can be done here: forcing a > flush on unmap in do_mmu_update() itself would be a high performance > penalty. Right, and hence ... >>> --- a/xen/common/page_alloc.c >>> +++ b/xen/common/page_alloc.c >>> @@ -1501,6 +1501,7 @@ bool scrub_free_pages(void) >>> >>> static bool mark_page_free(struct page_info *pg, mfn_t mfn) >>> { >>> + const struct domain *owner = page_get_owner(pg); >>> bool pg_offlined = false; >>> >>> ASSERT(mfn_x(mfn) == mfn_x(page_to_mfn(pg))); >>> @@ -1539,7 +1540,7 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) >>> } >>> >>> /* If a page has no owner it will need no safety TLB flush. */ >>> - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); >>> + pg->u.free.need_tlbflush = owner && is_pv_domain(owner); > > I guess I will need to adjust this to: > > pg->u.free.need_tlbflush = owner && IS_ENABLED(CONFIG_PV); > > As keeping track of whether a page has been ever mapped by a PV domain > seems overly complicated, and not worth it. ... "yes" here as well. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:43:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:43:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413118.1643356 (Exim 4.92) (envelope-from ) id 1x4IaW-0000Lt-84; Wed, 09 Sep 2026 13:43:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413118.1643356; Wed, 09 Sep 2026 13:43:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4IaW-0000Lm-5E; Wed, 09 Sep 2026 13:43:44 +0000 Received: by outflank-mailman (input) for mailman id 1413118; Wed, 09 Sep 2026 13:43:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4IaU-0000Le-Mr for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:43:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4IaT-005KJf-LG for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:43:41 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1627b-bab6-0a2a0a5309dd-0a2a450a86dc-46 for ; Wed, 09 Sep 2026 15:43:41 +0200 Received: from [198.137.202.136] (helo=mail.zytor.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1628b-f2d2-0a2a450a0019-c689ca88826c-3 for ; Wed, 09 Sep 2026 15:43:40 +0200 Received: from [IPV6:2601:646:8081:8d71:5cb3:1591:3c4d:f1f4] ([IPv6:2601:646:8081:8d71:5cb3:1591:3c4d:f1f4]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 689Dh6ow3804694 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 9 Sep 2026 06:43:06 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=2026082801 header.d=zytor.com header.i="@zytor.com" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 689Dh6ow3804694 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026082801; t=1788961388; bh=ZL/gT4kHs9WamtcdUxmyF1tgVVpVFEeVqovXe+EpBQI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eFwHwSC6hjap02ACpRnHIRPw4THKCVy96V7SRclSv0/wvuYj94WdAndZ412lZjsIc ib2dBilG8mtldf/d2E3Hya1jj6o9Zk0Q79lICDrC2lXPZycxmIDR6BMtmn+iMwxd13 oyUtUB6IFtwNA2gyH+XgJWNfSBRUAxY/EZqEkIfeO8dY5AHITqf3EmMcOvcElK+Vl9 v6VuBiudgQWGq2SHQLrm/vdw1poseknYCfQsThqM83O6PmKtmMho1BxZpAnnk0H5h6 yPMZgaU/BF4TkPQ/qZw8cSrbhtDNfIX36C6nbD5kwMiHoJfDBuxLmsWFqIT/oTT9+X EecohgN80cYTA== Message-ID: <8b00b7d2-2bd3-4871-9908-9fe1568d2690@zytor.com> Date: Wed, 9 Sep 2026 06:43:01 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() To: David Laight Cc: Borislav Petkov , Mauricio Faria de Oliveira , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> <20260909093831.095b89cb@pumpkin> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260909093831.095b89cb@pumpkin> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1788961421-59FDECFC-90042805/0/0 X-purgate-type: clean X-purgate-size: 1476 On 2026-09-09 01:38, David Laight wrote: >> >> Here is an out-of-line compact memcmp() which works for both 16/32 and 64 bits: >> >> >> On 64 bits it compiles to: >> >> 0000000000000000 : >> 0: 48 89 d1 mov %rdx,%rcx >> 3: 31 d2 xor %edx,%edx >> 5: 31 c0 xor %eax,%eax >> 7: f3 a6 repz cmpsb (%rdi),(%rsi) >> 9: 0f 97 c2 seta %dl >> c: 0f 92 c0 setb %al >> f: 29 d0 sub %edx,%eax > > That isn't the object code from the source ... > And that's the ultimate hint that a cut and paste error had happened. This was the actual source code. int memcmp(const void *s1, const void *s2, size_t len) { int lt, gt; /* * Note: for the benefit of 64-bit code, xDI and xSI are reversed * compared with what CMPSB uses; hence SETA and SETB are also reversed. * * The XOR statements set ZF = 1, CF = 0, which is required to handle * the case len == 0 correctly. */ asm volatile("xor %[lt],%[lt] ; " "xor %[gt],%[gt] ; " "repe cmpsb ; " "seta %b[lt] ; " "setb %b[gt]" : "+D" (s1), "+S" (s2), "+c" (len), [lt] "=&q" (lt), [gt] "=&q" (gt) : : "cc", "memory"); return gt - lt; } From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:47:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:47:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413129.1643373 (Exim 4.92) (envelope-from ) id 1x4Ie7-0000w6-Nn; Wed, 09 Sep 2026 13:47:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413129.1643373; Wed, 09 Sep 2026 13:47:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Ie7-0000vz-L3; Wed, 09 Sep 2026 13:47:27 +0000 Received: by outflank-mailman (input) for mailman id 1413129; Wed, 09 Sep 2026 13:47:26 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Ie6-0000vt-5Q for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:47:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Ie5-007u7Q-I9 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:47:25 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1636d-e002-0a2a0a5209dd-0a2a4503eca4-2 for ; Wed, 09 Sep 2026 15:47:25 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1636d-fae8-0a2a45030019-b9ff1c238095-3 for ; Wed, 09 Sep 2026 15:47:25 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0866c5bfe000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 13:47:23 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 92BC281D2F; Wed, 9 Sep 2026 15:47:22 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=30FDC8+SyZ8JvOgAC8CWDsrwu0Mz5znm0ZmniOiLZ2Q=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=RwPTFOFpIH32R4ZS1A/8RxnAcESF1T0iKGc5P8tY5IsRbDOvW8Bllb34ASHyOqkprZKGQJM47 vU5+1FxLMEHuD+taO/c2NZ9lvtqZH6qKRJ+jdx+WSK08dWaCOEw2AKB6cNflzGIyC29ogFyfOQJ 0438WUGdDPr9JlSmHVIOP+wY/iIEtFyDGvqScbU2uq4VLtWWC3v0f8kD2pGQohv1USSrmBui7Yk 5A+46kOBZmgSJH1i8ezWXe6cSwVy8JMPxY8TPiD+ipx+NORRnyJl55D4lUL5ZkJu5ty8oaspz7m kPk7Vcqz0G/F1ooYxXFm7ar8J/BPS71duVl94v1qoyjA== X-Zone-Loop: 13474b69ce2261f95457bcd23a0374c6ef00aeaa4519 x-campaign-type: default x-transaction-id: 0bc88b75-d9a1-48fe-bc60-09de4a5adae1 x-swg-uid: 01-08037513-d8df-4681-92df-9b999cb01863 X-Mailer: Sweego Message-ID: <1788961643.8631fc262581453bbf619ec5b2062170.1a0866c5bfe000c4f3@vates.tech> x-swg-bid: 1788961643.8631fc262581453bbf619ec5b2062170.1a0866c5bfe000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 9 Sep 2026 15:47:22 +0200 From: Anthony PERARD To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Michal Orzel , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Teddy Astie Subject: Re: [PATCH v3 1/6] x86: split xen-syms/xen.efi linking rules References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.40.8ad13e28d3b61d08.1a0866c58f1.730368a99bde9348=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788961642738 X-purgate-ID: tlsNG-33051d/1788961645-75C804E9-A8FAD571/0/0 X-purgate-type: clean X-purgate-size: 1131 ---=Part.40.8ad13e28d3b61d08.1a0866c58f1.730368a99bde9348=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 08, 2026 at 02:28:07PM +0200, Jan Beulich wrote: > Doing so, besides (hopefully) adding clarity (not the least by way of > using pattern rules where possible), also avoids explicit recursive > $(MAKE) invocations=2E For xen-syms move re-usable helper rules to a new > scripts/Makefile=2Elink=2E >=20 > While doing so, re-order =2Emap file creation (which can in principle fa= il) > and check-endbr=2Esh invocation ahead of putting in place the final imag= e > (which is now the result of a simple rename)=2E >=20 > Also drop --source-name=3D from the tools/symbols invocation which has > --empty passed, for being meaningless there=2E >=20 > Signed-off-by: Jan Beulich Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.40.8ad13e28d3b61d08.1a0866c58f1.730368a99bde9348=--- From xen-devel-bounces@lists.xenproject.org Wed Sep 09 13:54:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 13:54:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413140.1643384 (Exim 4.92) (envelope-from ) id 1x4Ikg-0002fl-Da; Wed, 09 Sep 2026 13:54:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413140.1643384; Wed, 09 Sep 2026 13:54:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Ikg-0002fe-A5; Wed, 09 Sep 2026 13:54:14 +0000 Received: by outflank-mailman (input) for mailman id 1413140; Wed, 09 Sep 2026 13:54:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Ikf-0002fY-K7 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 13:54:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Ike-002XOx-0w for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:54:12 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa164f4-8faa-0a2a0a5109dd-0a2a450bdee4-18 for ; Wed, 09 Sep 2026 15:54:11 +0200 Received: from [202.12.124.148] (helo=fout-b5-smtp.messagingengine.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa16502-b7e8-0a2a450b0019-ca0c7c94d141-3 for ; Wed, 09 Sep 2026 15:54:11 +0200 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id C7D5C1D000CC; Wed, 9 Sep 2026 09:54:09 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Wed, 09 Sep 2026 09:54:10 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 9 Sep 2026 09:54:07 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1788962049; x=1789048449; bh=VMvOOyY9mcnhXRYtdukfXBzrxZKMNsKzYYKcZnz3G+s=; b= cFdKeLDAzC9n8RycW3FnwasBMZtWVWrwPdAnAGh++ATUnInltOuq0175DlK6qgiI ifDQO52ZX1k6hknsu8XFZ/AIt5ufUdgLhlpzCk9Et7DmvFARShrWTknhy2hWef/b SsIiHsfAAr++XD+EeZMbrOMHFwpv/kp6Hj4ZjNndyvw464pQGg9Va3k1wn8kX97T 1zyW1qSZa3S6U4OlREoH8300qTqg0j/bE9/05AgslyPDH6TuEdgyDq7rvBmR9SuO 5I+E0yqlbjdwPxlaDFGnhud0Y7yarYiPECclV214/AeoQr4eNDYowv8DgzxZMgED a5nTwguAwnaB/KvQX4CEwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1788962049; x=1789048449; bh=VMvOOyY9mcnhXRYtdukfXBzrxZKMNsKzYYK cZnz3G+s=; b=wj3UTmfX3a79OeucEgObnXUYyvflVaPAvpDJQB/nV8V3awp6Sad w893/LuTM6Hub7vNSOvkro2NXEBRSO4ks73oSyy0QGzfTfwEzUB3IGGMfQmA8NqQ A8vWeTrBU8JX4dlQyc1nKR1ksBc9iqihwGb+RAzlLlmTL5ve4tJoWdS2D6Hd4yA2 RoSpWRLQ2mpi9AQ9rbR/si05PZuTiyzbnqPJjAq275B9TsV7M3jlseJ/iVSYQE96 i4i3aHYK9+BchYGXNkFaFFgo2qA+qXfNzIyFLH6AeoeYxcpuqWGNvqyNAEgOHsSU +11hmfbYGDWCB9mJqua9qrjg5x73TYE3WqQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTG1NR6sYhmdAkE1G2MkdeeKu4jVrYRkLE+37adJBo113bK+to5NDDf+ghPO9tSip/ X+IqF6wjFEy8ucFVUFtMYO7pD1t4HhAN4Ye7ePD/gxRahrkAnsSRRks7MUyRgXSZ9iK3OD aMNSi69kA6RwA/DCdxuNQp4zt60RpZBXxUWWlMJNQUg/b1cpWqT3Mtp+OGROAUM5eZ4FK7 lx8kub0cIm7J/uuT0lt2zUEWe4Hm39qm4ZejJkLoHcIEGFftyuNxT9xIWtvI6nplC9i3Qb +2ZQtT/snmRtEU34Olv0Xu28IR0+SmP3lOT1ZdqoeFVbhctgrsfpS1jb2oEfa1H9/DeWLr wy8/bEeQewVJrDGL0gs9Gl/fTIm8GAz8FTHTjwKJgsBBHJvJZNtaDm9F2gcSGgqwT41sEW g8LYkQiod8tAU9YsMWzMuKNAPADXuvIjZuZFm4TjyjUcqW8H52iTd3vwitGg6B7O1V879p PSbmu2GQTDk6tpyYdqdPk4DC89sjs7wg7nfBdptxa6TsA/DHB1/zLDmlmnM6oV3S8mF0Zu OiKO0UBY5LKK2hdtgUgjf4w5a8nc893IREEn2ZYWcRT0qaU2Gt8t+ZJDV1G2N2YHFcD2E8 Ph3ijsyBocl061IoW5/JPcEdHQTPvXKinNihhI9uuZNvm/a/BQpdmpyvzgUg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Wed, 9 Sep 2026 15:54:05 +0200 From: Marek Marczykowski To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Roger Pau =?utf-8?B?TW9ubsOp?= , Nicola Vetrini , Daniel Smith Subject: Re: [PATCH 3/6] x86/EFI: adjust efi_multiboot2_prelude() to comply to Misra rule 18.2 Message-ID: References: <25c71873-9043-40c7-a514-c7cd557f91d1@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YnbfIwn8Kgs20i6B" Content-Disposition: inline In-Reply-To: <25c71873-9043-40c7-a514-c7cd557f91d1@suse.com> X-purgate-ID: tlsNG-42698a/1788962051-196C29EA-3D851B37/0/0 X-purgate-type: clean X-purgate-size: 2089 --YnbfIwn8Kgs20i6B Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Sep 2026 15:54:05 +0200 From: Marek Marczykowski To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Roger Pau =?utf-8?B?PT91dGYtOD9CP1RXOXVic09wPz0=?= , Nicola Vetrini , Daniel Smith Subject: Re: [PATCH 3/6] x86/EFI: adjust efi_multiboot2_prelude() to comply to Misra rule 18.2 On Wed, Sep 09, 2026 at 03:00:21PM +0200, Jan Beulich wrote: > While casting to pointer types may be more natural there, the subtraction > then ends up violating "Subtraction between pointers shall only be applied > to pointers that address elements of the same array". Use unsigned long > arithmetic instead. >=20 > No functional change intended. >=20 > Signed-off-by: Jan Beulich I was going to propose pre-calculating mbi_raw + mbi->total_size and checking against that, but then checking for overflow would need to be explicit. So, your version indeed looks better. Acked-by: Marek Marczykowski-G=C3=B3recki --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --YnbfIwn8Kgs20i6B Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqhZP0ACgkQ24/THMrX 1yzFPAf/Yt2/hgR5XfVVB9l3qHX9tFd58Y5hGtiiG3nk0GLhIXfp8aaYuz0FDgRB 2Je1t408daMmm4euc5vqzCjtrq2ie5hE7HAoO9zEU7v7jRtTjjh4yzbGQxrqiekG /6mySuCGS3S7xReQhj/ZnWP3NHA5phNLSuZyMiFso/80FaYn92ffeTmjRvPy5t0e VUZWN07Od14OkcXIw7EPZl98/06k837cPmXgTyxb2jAv4ajP0fhV1ssPmFZyIRNe vp8m9Vmobq9tQC7Lbnos9Gy/G1bsjSeKIzXrF6Eyqj9A/eyA8bpOy1vNpVesG/YB rKbviNmnQEvCb/+9H8+3nKfRwi6Jvg== =K9n7 -----END PGP SIGNATURE----- --YnbfIwn8Kgs20i6B-- From xen-devel-bounces@lists.xenproject.org Wed Sep 09 14:05:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 14:05:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413151.1643391 (Exim 4.92) (envelope-from ) id 1x4Iv0-0004gZ-7O; Wed, 09 Sep 2026 14:04:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413151.1643391; Wed, 09 Sep 2026 14:04:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Iv0-0004gS-4o; Wed, 09 Sep 2026 14:04:54 +0000 Received: by outflank-mailman (input) for mailman id 1413151; Wed, 09 Sep 2026 14:04:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Iuy-0004gM-VV for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:04:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Iuy-007xwJ-CH for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:04:52 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa16733-bab6-0a2a0a5309dd-0a2a4502e872-18 for ; Wed, 09 Sep 2026 16:04:52 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa16784-6ca4-0a2a45020019-4a7de48ca899-3 for ; Wed, 09 Sep 2026 16:04:52 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f9f0b1fso164224766b.2 for ; Wed, 09 Sep 2026 07:04:52 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d4a9cbbsm789027466b.13.2026.09.09.07.04.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 07:04:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788962692; x=1789567492; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=N/qLeRGKLFe1TR3mDBZ/zQ19jESJ0lDOanHFh7sul2g=; b=A2cNpnO9bX11hWa2bddqIMEk9LJMiEvSr3Sq1j60nXB3TIG1KqiBOTDBQpJIbVusr/ jTPAFHGPXwt76lq4QYhoYYlxedpDTqFkI2v80fTHQSMcjuIafvPnspm2IFgyoYLRHqM5 1b2OJAlhXuMVh40u2xa+MvHEqyqsj4Jfun3N4fJhqvb7LxxmN11xjUE5lOCXWy1nrdn0 rd6cS/AyVMv+XojU87XKAjczdGj59icECQFXSan30ZU0A7A2NObHs4K4tp+33z3f6jHT bcVWd9i/txF+SM24PDl1E/E+scLHiWzm6+WOLTyqd+E2+W1oQXwPJC+50x9dDzISRwlx 3PRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788962692; x=1789567492; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=N/qLeRGKLFe1TR3mDBZ/zQ19jESJ0lDOanHFh7sul2g=; b=Fc7cJgcJmqwgymz5ocSEo4yf8DRoXVHsAuVOyDgML8GLej2HJDi8EGk9+UWVmnTrO+ +eK8VhMTKiQ5lgZ+C6974VzqzLBszpTJk0+8gK6rXIgLZpJEsMev/tPNaU1Qf+EtSbkz wOU0vC04wR8RJW+0f9d9cdpLPqnou0uFJPG1jfsCzxhK8nbmP3xNoPQQ8ORqtE8OZfFb VBvSVmhx3AMqTORugW9ugTj/P61n4FkqRhzguQmZmIXsHb2ulDfF2VhOafBrIgg2fVY8 rmhMLjtKrwoek2/Lvauq8i+2nHjG95mU4wj6nVzRUqdps8NNMWtvks3FO5+c4wBt96tm 3QUA== X-Forwarded-Encrypted: i=1; AKwUvByxhUZf88+g5ifYLfnm/x7ntndRQolTem501T+SufmdMiv46fHigI5UqgZEv6boHBQcrfuvWHqX3g8=@lists.xenproject.org X-Gm-Message-State: AFuF++kXBYrvnxpgYfIeIMcvbqE8DRuQpfvFI4qQ3JuqfmIOCsPDEbT6 FW/vwzyD7pQICu9DRA31ddkUpj9MHruv3p/PXFxKbTppsD8amKh0wv2O X-Gm-Gg: AYBFou0D/MYlwZIQXMHCzUp+pUV5nUaEwjFWr2cD6o44A8iwCL2V0YTTLxqkb8Lyk/Z QMKQtm0EvADABQ6sA+m6g9fdNJ+/bvaQVCCdGIkQ967TlWk+t34I5pJx1xJfRNSifJHFda2baTT ilqW9RyBMfhT4vygIb149UpGt5rewJZrE7C7Ow5sX7gRbObHBW7qkBG5B/SuarX7YbIU2V8cA5K lRsv2poAWdcIrliRDNkL+qTfm/IHZpWnAfONVFNgOyQNQVRcXGzvP4vm1FG6w9Wfo1YkjkuYsTt +xrwmg4McV1keCvF7C2BiJYdyY+Ejch/s96Gkv98FkKtxQHhjiL0hO1Wj0G1TFIULkQLiF5IpgG Z9t5E3J0la+Im5NfZr5bb3dGWTr7Hbkmg6zfyYW8Q3844oKpVQRw7vH6Tzo2upJgRCQko9Q4bqC qjk9mcHFDQl+GaY5mJgH8izGE+eFa4Ugop/IjMCjkg1QyUEgHfc1oM0uCy1hSjP47Jmbder7xeP 5PVBXB9Errmbqvglj+zad/VNJBjsdAA X-Received: by 2002:a17:907:a313:b0:c21:752f:c44e with SMTP id a640c23a62f3a-c292b190470mr548936866b.16.1788962691446; Wed, 09 Sep 2026 07:04:51 -0700 (PDT) Message-ID: <926c0356-efb9-4eb7-a7e7-d57e9bdc96c1@gmail.com> Date: Wed, 9 Sep 2026 16:04:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788962692-662A92AC-3ABECD66/10/73395122804 X-purgate-type: spam X-purgate-size: 3920 On 9/9/26 3:24 PM, Jan Beulich wrote: > On 27.08.2026 17:20, Oleksii Kurochko wrote: > >> +/* >> + * Check alignment and dispatch a decoded MMIO access to a registered >> + * handler. On success (0), info->data holds the read value for loads. >> + * >> + * There is no "retry" outcome to handle: find_mmio_handler() returns a >> + * copy of the matching handler taken under vmmio->lock and the ops >> + * structures are never freed, so the lookup result cannot go stale >> + * between finding the handler and invoking it. >> + */ >> +int do_mmio(mmio_info_t *info, paddr_t fault_addr, unsigned int len) >> +{ >> + /* Fault address should be aligned to length of MMIO */ >> + if ( fault_addr & (len - 1) ) >> + return -EIO; > > Better first check (or at least assert) that len is a power of 2? It make sense. I will do then: if ( len & (len - 1) || fault_addr & (len - 1) ) > >> +int register_mmio_handler(struct domain *d, >> + const struct mmio_handler_ops *ops, >> + paddr_t addr, paddr_t size) >> +{ >> + struct vmmio *vmmio = &d->arch.vmmio; >> + struct mmio_handler *handlers = vmmio->handlers; >> + paddr_t end = addr + size; >> + unsigned int i; >> + int rc = 0; >> + bool overlap; >> + >> + if ( !ops || !ops->read || !ops->write || !size || end < addr ) >> + return -EINVAL; > > "!size || end < addr" can be had shorter as "end <= addr". I will apply this. > > Whether it's worth checking ops to be non-NULL I question, bit I wouldn't > insist on dropping the check. > Probably it isn't really needed but just extra check that someone miss to provide implementation of ->read, ->write still could be useful. Also it is executed only at boot time so not big perfomance impact. >> + write_lock(&vmmio->lock); >> + >> + if ( vmmio->num_entries >= ARRAY_SIZE(vmmio->handlers) ) >> + { >> + rc = -ENOSPC; >> + goto out; >> + } >> + >> + /* >> + * The array is kept sorted by base address, so rather than appending and >> + * re-sorting, find the slot the new region belongs to and shift the tail >> + * up by one. >> + */ >> + for ( i = vmmio->num_entries; >> + i > 0 && handlers[i - 1].addr > addr; >> + i-- ) >> + /* Nothing */; > > for ( i = vmmio->num_entries; i-- > 0 && handlers[i].addr > addr; ) > /* Nothing */; > > ? It seems like it will break the code after it. This breaks cases: 1. On a normal exit (handlers[i].addr <= addr), i is the index of the entry that was found, whereas the insertion slot ought to be i + 1. The code below, however, uses i as the insertion slot and handlers[i - 1] as the left neighbour - an off-by-one. 2.If every entry has a bigger addr than the new one, the loop exits when i == 0: 0 > 0 is false, yet i-- has already taken effect, so i == UINT_MAX. Then i > 0 is true, leading to a read of handlers[UINT_MAX - 1] and to memmove() with a size of (num_entries - UINT_MAX). Case 1 pretty easy to fix, just use proper indexing but case 2 will require extra check at least. Thereby I think we could keep here original for loop. > >> + /* >> + * Regions are required not to overlap; check both neighbours. Their >> + * addr + size cannot overflow, as such regions are rejected above when >> + * they get registered. >> + */ >> + overlap = (i > 0 && handlers[i - 1].addr + handlers[i - 1].size > addr) || >> + (i < vmmio->num_entries && end > handlers[i].addr); >> + >> + if ( overlap ) >> + { >> + rc = -EEXIST; > > I fear -EEXIST can be misleading; it generally means _this_ range is > already covered, not some sub-range thereof. Then probably EADDRINUSE() would be better. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 09 14:05:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 14:05:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413153.1643401 (Exim 4.92) (envelope-from ) id 1x4IvG-0004wh-Hm; Wed, 09 Sep 2026 14:05:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413153.1643401; Wed, 09 Sep 2026 14:05:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4IvG-0004wa-ED; Wed, 09 Sep 2026 14:05:10 +0000 Received: by outflank-mailman (input) for mailman id 1413153; Wed, 09 Sep 2026 14:05:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4IvF-0004w5-8N for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:05:09 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4IvD-006T2L-1e; Wed, 09 Sep 2026 14:05:07 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4IvD-009AfJ-0Q; Wed, 09 Sep 2026 14:05:06 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=mSzuR5Ka/pPapr0FJwRJ5lPhaQWm8jB/vfBAH3X6m10=; b=ihbnoxw9Ktw/YprWK12X9Ke+75 tLY9HfBhd+tiisDs/3wpDxCyL12GpISN8dJAgd0KumEGu8Tkd2EAyHpqU8d8/Jb4Uw9uLVfDKFX6Q snJ7Eq8P/0SfwZhBn9CRaORlwzNETVFrlR0JgVs9+uJLD7P4+dcuRLyFZPMweWvEYgjo=; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v2] x86/mm: limit deferred TLB flushing to PV domain support Date: Wed, 9 Sep 2026 16:05:00 +0200 Message-ID: <20260909140500.73483-1-roger@xenproject.org> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The current logic on x86 will mark all domain owned pages as needing a TLB flush before being re-used. However such TLB flushing is only strictly needed when the pages might have been mapped by a PV domain, as those can keep a reference to the page in the TLB after it has been freed. Limit the flushing to builds with PV domain support, as tracking whether a page might have been mapped by a PV domain is not trivial (and possibly not worth the extra logic). Signed-off-by: Roger Pau Monné --- Changes since v1: - Only avoid the flush if there's no PV domain support. - Fix comment. --- xen/common/page_alloc.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 62ac89b824de..cbb2af7f64ce 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1538,8 +1538,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) BUG(); } - /* If a page has no owner it will need no safety TLB flush. */ - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); + /* + * If a page has no owner and there's no PV domain support it will need no + * safety TLB flush, there can be no stale TLB entries. + */ + pg->u.free.need_tlbflush = IS_ENABLED(CONFIG_PV) && page_get_owner(pg); if ( pg->u.free.need_tlbflush ) page_set_tlbflush_timestamp(pg); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 14:26:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 14:26:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413180.1643409 (Exim 4.92) (envelope-from ) id 1x4JFy-00006W-3F; Wed, 09 Sep 2026 14:26:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413180.1643409; Wed, 09 Sep 2026 14:26:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JFy-00006P-0E; Wed, 09 Sep 2026 14:26:34 +0000 Received: by outflank-mailman (input) for mailman id 1413180; Wed, 09 Sep 2026 14:26:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JFw-00006J-93 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:26:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JFv-007rmQ-46 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:26:31 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa16c8b-8faa-0a2a0a5109dd-0a2a450bcae8-22 for ; Wed, 09 Sep 2026 16:26:31 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa16c96-b7e8-0a2a450b0019-d1558030c542-3 for ; Wed, 09 Sep 2026 16:26:30 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49b8ce9b733so47711815e9.1 for ; Wed, 09 Sep 2026 07:26:30 -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-49d1fd58c31sm51666065e9.1.2026.09.09.07.26.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 07:26:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788963990; x=1789568790; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=4X2H/90oQDfjM4+y9oJSlivSth0VhUyGD5q0kYrhqD0=; b=ashy+tJEthRb/QFCa2TSTmPDhz6BVgXrlMdo0o+KouC/93B+m9FpjNTzOkdTOkPA2W Y3q2G3j6W5o1SqlZTIvbxHoXHJSbHNOVONkV/QVDBVT0kpEpx1AA6k7q4us2LG1T4sEL 8lqkuyZ0bwkeJfF2YVlNLfyVanKn4hKqUidwSaxdPfS2m9f77pTwuGrOw9JrOPvTcXbM MnAn3mbhjlf5JruC1idhNcHbY+7tk/TDRR1NcZKdVZWk4aREHG6m1x5v5C66RvYQa4i+ IiMu7rPvCxOibN+g99Woo2uWS1hFe3JLLjccj596Xr6sePLPVU2woKkM+mqZGtOj1jp6 SqFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788963990; x=1789568790; h=content-transfer-encoding:content-type: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:content-type; bh=4X2H/90oQDfjM4+y9oJSlivSth0VhUyGD5q0kYrhqD0=; b=B1rhrt9rpTlWnPe5lM0z2aFEkDbtAVxau1VGvIXtLGNHIOk6mIo6GUlMO5uMs9H7aM farRgwUvxrj/bC9MbTrkmxVR6bdop79uFK1udSWXIPoEykwuGGHDUwyh9+zyeUjxe/0c wDnLK/+B5JxRC5OESZly5fF2LAzLHwA6mNRDDMl+ZLVhmNqQaSYfEjDlXRWbCEh+jTCJ sweo840FRGiED8yFLkt4aG6ZUgFs8s8De4/IseyLrymC416zdbZQ4NbH00idlhPwYZHT 5JMcVMilG0ZZIwV0NUHn6xBoiSKqAMtzP5o5R+SuTwyZ8ghQDNCpJ07tOEc3JZoJLhPL 7bFA== X-Forwarded-Encrypted: i=1; AKwUvBwEGbBDVUeSizuirHzWG7bWiYyGpbyb2xWrokbyLbHVEmcrr/L6Nc6N4jiQFr5i1FxonZfnbRy9alE=@lists.xenproject.org X-Gm-Message-State: AFuF++m/e+m/kPwuB6G/NH5zpqkRSC70OyOZ0w5fcOmZ3PMZIbMHDhhp JUlxbkWSEVUBJWCL62Dt0pKMWxtiiTbaoSP0zaJsAYcRtfplpngu7MlFP99hvDoQnNADbIt9Rym ytHYG4g== X-Gm-Gg: AYBFou3mvCTJvf2BcdFLyfVV+g/Dy+DHcbeF5vLgtAL1uGf8PHP06PBiIauPEbf1uo1 /w+UIEeIAxza3iOccFLDXqS8auHVfTKSM5qv892EHfVkvinQJq3HPVddmOPVqD1+5qeGHTxhFlS 9eaz0uJVCtFWuHWGMdZajRwYgYnztrLlRsjU52q/95i4yWFXY+mqIyGqNPZER9wJ6/RHKOqY47v lqfS0pIoPpU1mvfBFGP4TksCql6HQSBTr1ePy/QNBWLpz9uNrAvRddZVJvORcjWOtyKUf6/c0S9 Oxu9FVFNRjvq5bEzGrcYGaZOcEF3jVgbV/6RhC4GzAiOD3G0oxqouj4ufnWBCsKRXWrklbhAYBf 4LSQMnuXUkYiE5T0tv4XpApvBycFlhkIdYuyCf4hh15NEuii48MPv/VGMC1qv48hjUc4IdyGuO7 134EzBEJ1hYSBsLkeF/Ker8O0jCnxXMFdcXYTCrvj01N7CjRzpReW0dTXzQiuRLAiOPNmTZdIsM W1agXUiPTejEe1mgohTAjXcV0jXi98K+VBbj6R/BMLmsJLEMnjl5D3hZkzhXTw= X-Received: by 2002:a05:600c:37c8:b0:49c:cee2:a508 with SMTP id 5b1f17b1804b1-49cf826c4e2mr344372345e9.16.1788963990158; Wed, 09 Sep 2026 07:26:30 -0700 (PDT) Message-ID: <68ab5241-7301-4988-9420-bcccc4b16e3d@suse.com> Date: Wed, 9 Sep 2026 16:26:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.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: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788963991-196C29EA-6BBBFA75/0/0 X-purgate-type: clean X-purgate-size: 11180 On 27.08.2026 17:20, Oleksii Kurochko wrote: > +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, > + uint32_t base_val) > +{ > + unsigned int guest_id = vcpu_guest_file_id(target_vcpu); > + unsigned long hart_field = aplic_hart_field(target_vcpu->processor); What guarantees target_vcpu's ->processor field to be meaningful at this point? (Also again naming of the parameter: Generally it wants to be "v" or "curr"; only very special cases may use other names.) > +uint32_t aplic_hw_read_reg(unsigned int offset) > +{ > + unsigned long flags; > + uint32_t val; > + > + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); > + > + spin_lock_irqsave(&aplic.lock, flags); > + val = readl((volatile void __iomem *)aplic.regs + offset); Please can this have const alongside volatile? > @@ -98,6 +108,27 @@ > #define APLIC_SIZE(nr_cpus) \ > (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus))) > > +/* > + * Using setip is fine here, as all SET* and CLR* register groups consist of 32 > + * registers and therefore have identical sizes. > + * > + * Lowest 2 bits are always zero for SET* and CLR* registers. > + */ > +#define APLIC_SETCLR_OFFSET_MASK \ > + (sizeof_field(struct aplic_regs, setip) - sizeof(uint32_t)) > + > +#define APLIC_xMSICFGADDR_PPN_SHIFT IMSIC_MMIO_PAGE_SHIFT > + > +#define APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw) \ > + (BIT(hhxw, UL) - 1) > +#define APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs) \ > + ((hhxs) + APLIC_xMSICFGADDR_PPN_SHIFT) > + > +#define APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw) \ > + (BIT(lhxw, UL) - 1) > +#define APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs) \ > + (lhxs) May I ask to avoid unnecessary line splitting here as well? > --- a/xen/arch/riscv/include/asm/vaplic.h > +++ b/xen/arch/riscv/include/asm/vaplic.h > @@ -21,11 +21,16 @@ struct domain; > > struct vaplic_regs { > uint32_t domaincfg; > + > + uint32_t *target; > }; A pointer in this structure is odd, as this (supposedly) is a set of guest register values. The field name also doesn't clarify its purpose. All in all: Likely a comment is needed here. > --- a/xen/arch/riscv/vaplic.c > +++ b/xen/arch/riscv/vaplic.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > > #include "aplic-priv.h" > @@ -27,6 +28,279 @@ unsigned int __ro_after_init guest_aplic_num_sources; > > #define FDT_VAPLIC_INT_CELLS 2 > > +#define AUTH_IRQ_BIT(d, irqn) \ > + (((irqn) < (d)->arch.vintc->nr_virqs) && \ > + test_bit(irqn, (d)->arch.vintc->used_irqs)) > + > +/* > + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group) to > + * a 32-bit word index into the used_irqs bitmap. Each word covers 32 > + * interrupt sources. For SOURCECFG and TARGET groups the same division also > + * yields the interrupt number directly, because those arrays store one 32-bit > + * register per source. > + */ > +#define regoffset_to_word_idx(reg_val) ((reg_val) / sizeof(uint32_t)) > + > +static uint32_t vaplic_target_read(const struct domain *d, unsigned int irqn) > +{ > + const struct vaplic *vaplic = to_vaplic(d); > + > + /* target[0] doesn't exist so irqn == 0 should be impossible */ > + if ( !irqn || irqn >= vaplic->vintc.nr_virqs ) > + return 0; > + > + return read_atomic(&vaplic->regs.target[irqn]); > +} > + > +static inline uint32_t generate_auth_mask(const struct domain *currd, > + unsigned int word_idx) > +{ > + unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE; > + > + if ( word_idx >= DIV_ROUND_UP(currd->arch.vintc->nr_virqs, > + sizeof(uint32_t) * BITS_PER_BYTE) ) > + { > + gdprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx); Along the lines of earlier remarks: What value does "is passed" add? > +static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, > + uint32_t value) > +{ > + const struct domain *currd = curr->domain; > + unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK; > + > + ASSERT(curr == current); > + > + switch ( offset ) > + { > + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: > + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: > + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: > + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: > + { > + unsigned int word_idx = > + regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); > + > + value &= generate_auth_mask(currd, word_idx); > + > + break; > + } > + > + case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: > + if ( value & APLIC_SOURCECFG_D ) > + { > + dprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); gdprintk()? > + goto fail; > + } > + > + /* > + * As sourcecfg register starts from 1: > + * 0x0000 domaincfg > + * 0x0004 sourcecfg[1] > + * 0x0008 sourcecfg[2] > + * ... > + * 0x0FFC sourcecfg[1023] > + * It is necessary to calculate an interrupt number by subtracting > + * APLIC_DOMAINCFG instead of APLIC_SOURCECFG_BASE. > + */ > + if ( !AUTH_IRQ_BIT(currd, > + regoffset_to_word_idx(offset - APLIC_DOMAINCFG)) ) > + /* Interrupt not enabled, ignore it */ > + return true; > + > + if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW ) > + { > + gdprintk(XENLOG_ERR, > + "value(%#x) is incorrect for sourcecfg register\n", > + value); > + > + return true; > + } > + > + break; > + > + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: > + { > + struct vaplic *vaplic = to_vaplic(currd); > + struct vcpu *target_vcpu; This, btw, is a case where I think not using "v" is warranted. > + unsigned int guest_hart_idx = MASK_EXTR(value, APLIC_TARGET_HART_IDX); > + /* > + * Look at vaplic_emulate_load() for explanation why APLIC_GENMSI is > + * subtracted. > + */ > + unsigned int srcn = regoffset_to_word_idx(offset - APLIC_GENMSI); > + > + if ( !AUTH_IRQ_BIT(currd, srcn) ) > + /* Interrupt not enabled, ignore it */ > + return true; > + > + target_vcpu = domain_vcpu(currd, guest_hart_idx); > + > + if ( !target_vcpu ) > + { > + dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n"); > + > + /* Ignore such writings */ > + return true; > + } > + > + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) > + { > + /* > + * A non-zero guest index asks for delivery to an interrupt file of > + * nested guest. The vIMSIC node has no riscv,guest-index-bits > + * property, so a guest is told its harts have no guest interrupt > + * files and the field is read-only zero for them. The write isn't > + * rejected (that would throw away a valid hart index and EIID); > + * instead the field is dropped, which is also what > + * aplic_msi_target_gen() does with it when programming the h/w. > + */ > + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) > + { > + printk_once(XENLOG_WARNING > + "%pd: vAPLIC target guest index != 0 is unsupported\n", > + currd); > + > + /* Ignore such writes ... */ > + return true; > + } > + > + write_atomic(&vaplic->regs.target[srcn], value); > + > + value = aplic_msi_target_gen(target_vcpu, value); > + } > + else > + { > + /* > + * IPRIO is WARL and zero isn't a legal value for it, so normalize > + * it once: the guest then reads back exactly what it gets. > + */ What is "reads back exactly what it gets" supposed to express? The use of "once" there also isn't quite clear to me. > + unsigned int iprio = MASK_EXTR(value, APLIC_TARGET_IPRIO) ?: > + APLIC_TARGET_IPRIO_DEFAULT; > + unsigned long h = cpuid_to_hartid(guest_hart_idx); > + > + value = MASK_INSR(guest_hart_idx, APLIC_TARGET_HART_IDX) | > + MASK_INSR(iprio, APLIC_TARGET_IPRIO); > + > + write_atomic(&vaplic->regs.target[srcn], value); > + > + value = MASK_INSR(h, APLIC_TARGET_HART_IDX) | > + MASK_INSR(iprio, APLIC_TARGET_IPRIO); > + } > + > + break; > + } > + > + case APLIC_SETIPNUM: > + case APLIC_SETIPNUM_LE: > + case APLIC_CLRIPNUM: > + case APLIC_SETIENUM: > + case APLIC_CLRIENUM: > + if ( !value || !AUTH_IRQ_BIT(currd, value) ) > + return true; > + > + break; > + > + case APLIC_DOMAINCFG: > + { > + struct vaplic *vaplic = to_vaplic(currd); > + > + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO | > + (value & APLIC_DOMAINCFG_WMASK); > + > + return true; > + } May I suggest that you arrange case blocks (primarily) by offset? This would then mean for DOMAINCFG handling to move to the top, helping at least a little with SOURCECFG_{BASE,LAST} handling (slightly oddly) using APLIC_DOMAINCFG. > @@ -122,7 +447,29 @@ int domain_vaplic_init(struct domain *d) > */ > d->arch.vintc->nr_virqs = guest_aplic_num_sources + 1; > > - return 0; > + /* Slot 0 is unused: APLIC source numbering starts at 1 (see used_irqs). */ > + vaplic->regs.target = xvzalloc_array(uint32_t, d->arch.vintc->nr_virqs); > + if ( !vaplic->regs.target ) > + { > + d->arch.vintc = NULL; > + xvfree(vaplic); > + > + return -ENOMEM; > + } > + > + vaplic->regs_start = GUEST_APLIC_S_BASE; > + vaplic->regs_size = APLIC_SIZE(d->max_vcpus); > + > + rc = register_mmio_handler(d, &vaplic_mmio_ops, > + vaplic->regs_start, vaplic->regs_size); > + if ( rc ) > + { > + d->arch.vintc = NULL; > + xvfree(vaplic->regs.target); > + xvfree(vaplic); > + } Could you perhaps arrange for it to be possible to simply call domain_vaplic_deinit() here (and maybe also on at least some of the earlier error paths)? The code above loks very similar to ... > @@ -134,5 +481,6 @@ void domain_vaplic_deinit(struct domain *d) > > vaplic = to_vaplic(d); > d->arch.vintc = NULL; > + xvfree(vaplic->regs.target); > xvfree(vaplic); > } ... what's here. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 14:32:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 14:32:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413192.1643418 (Exim 4.92) (envelope-from ) id 1x4JLv-0001m6-MP; Wed, 09 Sep 2026 14:32:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413192.1643418; Wed, 09 Sep 2026 14:32:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JLv-0001lz-Jl; Wed, 09 Sep 2026 14:32:43 +0000 Received: by outflank-mailman (input) for mailman id 1413192; Wed, 09 Sep 2026 14:32:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JLt-0001lt-TO for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:32:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JLt-007tGb-AN for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:32:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa16ded-e002-0a2a0a5209dd-0a2a450bbedc-38 for ; Wed, 09 Sep 2026 16:32:41 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa16e09-b7e8-0a2a450b0019-d155dd29d5a0-3 for ; Wed, 09 Sep 2026 16:32:41 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-482f2ee53e7so4397746f8f.1 for ; Wed, 09 Sep 2026 07:32:41 -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 ffacd0b85a97d-48594172546sm36102224f8f.15.2026.09.09.07.32.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 07:32:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788964361; x=1789569161; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=niI+hug1B0D87D3cWhx9zMTux9Md3jAEf2XG7mWaltg=; b=gesJYAWqmsp0cmbRWyPaSjuQLgAQ2bm03jL3Chq0QbiB5O2PQWYwZlYth0EeTCCJ4R WaMn+m4sO5pHhL1SFLjLhinIGeq/5aV/8FCoFKw9noLWINE0PyeUyxE43I7bojYm9KxO BS6WpR3BQwxK/Hr+2im3/ci9M3f13/nrblWP0CuTzqjA5dCH2V4sy3bqR6D/tVZG3Ja8 ePQiPdWBkRavKWzWz1yKkEflUb5rUmuMS4cYjL3lo1l6Y1Y8wJ0UxD6m5tbN29hZL80S 1RL2yH3FTVAYm17HWu1mW9hzSxxWwAQ/+016Q7kOc7pHodblW+orlDvh/o9L0/il9xPt mE2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788964361; x=1789569161; h=content-transfer-encoding:content-type: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:content-type; bh=niI+hug1B0D87D3cWhx9zMTux9Md3jAEf2XG7mWaltg=; b=Ij5Zj9yLvDl2MgQNQVq2Gv3IIjFMOHZq7EBWyMDevohJBMLJRecbuTwj1BEhiucQR5 /RjWRyYMcy6yF/NHGLdlDfq+tIe4pjVhAWSm0coakzm4MjsYcqx+bpjqSrSkEUQamjtd V8evrk7O++ZTyUfh3gGD7vbaUiTQXmJ3JN9xHDkrUoar4eXw3QY57xtEO0nkASwyRvRt Wv1N3V3cnm9iVXupfzQc3wJIUsaqZivFPu+G7GQMuBMP7zKY9VWc7uZuQf65t8QogNjE b43+fpeod5FjujkUEAuXE12+q5r8LlFGPQpLSYZ4hyfvs2Ohwlv1gTyt4itrsMzB1U/p MXNA== X-Forwarded-Encrypted: i=1; AKwUvBxLtkQOETnAmD+PnFnO2LEiY30ZHVfW+FxZnFVhKbBZYAz2NjmogZH9Ut1imMPCFZtb0gohGUOoOcg=@lists.xenproject.org X-Gm-Message-State: AFuF++kIELKJVTTh9FFVcy3Phq9+5upB+BHs2rOCcgR5/LyaCQKq9M7R Yc1gcJNND1N0wfs+i8CLMtQW1lplk9WdNajcbRM7iaOaJv7nX1/Emqrkvn6HBsV4hA== X-Gm-Gg: AYBFou3oKfCAhygBe7TjWAoxF8c7nMyJKjNIRK7U6x/M5bivIamytHNTEBjEodhNjFH ibwcaRaSefVk0dY/E7kiRKvR3QPAf/ha85RmYhyMznYKjdcr6M5zGYNK2f4/lrNuihvtEeI2VLZ WByjGdVpdqG63N9DfkKW8/DB7KF/4MsTX6cCG8qZV0Ks4nW4CGEseZRzNqT5l6lFrHSN4alw9gs zUyQE4O1WtPYMyx+EUIsEjgoYagvkSXyUghOTNgRFxsXSgip1XU9PmJ/hDsHfjXrbdCW1bzSucc 8x9c3PT5idBuL4SuOKZqHkn283q5y75izt66zqmkK05XHuqTmrNV0EuaiwJC8dMM83krBMTnvDA V3Cq2jXUHXBSLk4J+hYxj4IXn46Xa6TXytdm+mbnXoxnxZN7/JIvBRKF+R2DCbsPWEQVyoDWuzG VG4O6QZn8mtnjsufCaed4Z3HoeGEXdhDMDVuJVh14bCIH2tFSO2dTd0Vd9QKolzRb/QDl+70wXT hk+EKIlNAL5ark/WElX14tiWKPGiphXX+anWklsDKHF/9V1NuDIOJf43SLuCit6UEPehoYw/w== X-Received: by 2002:a05:6000:41db:b0:485:8c17:9768 with SMTP id ffacd0b85a97d-4858c179982mr33005011f8f.42.1788964360610; Wed, 09 Sep 2026 07:32:40 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 16:32:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <926c0356-efb9-4eb7-a7e7-d57e9bdc96c1@gmail.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: <926c0356-efb9-4eb7-a7e7-d57e9bdc96c1@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788964361-190CD9EA-6EE30E4F/0/0 X-purgate-type: clean X-purgate-size: 3607 On 09.09.2026 16:04, Oleksii Kurochko wrote: > On 9/9/26 3:24 PM, Jan Beulich wrote: >> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>> +/* >>> + * Check alignment and dispatch a decoded MMIO access to a registered >>> + * handler. On success (0), info->data holds the read value for loads. >>> + * >>> + * There is no "retry" outcome to handle: find_mmio_handler() returns a >>> + * copy of the matching handler taken under vmmio->lock and the ops >>> + * structures are never freed, so the lookup result cannot go stale >>> + * between finding the handler and invoking it. >>> + */ >>> +int do_mmio(mmio_info_t *info, paddr_t fault_addr, unsigned int len) >>> +{ >>> + /* Fault address should be aligned to length of MMIO */ >>> + if ( fault_addr & (len - 1) ) >>> + return -EIO; >> >> Better first check (or at least assert) that len is a power of 2? > > It make sense. I will do then: > > if ( len & (len - 1) || fault_addr & (len - 1) ) With more parentheses added, I suppose. >>> +int register_mmio_handler(struct domain *d, >>> + const struct mmio_handler_ops *ops, >>> + paddr_t addr, paddr_t size) >>> +{ >>> + struct vmmio *vmmio = &d->arch.vmmio; >>> + struct mmio_handler *handlers = vmmio->handlers; >>> + paddr_t end = addr + size; >>> + unsigned int i; >>> + int rc = 0; >>> + bool overlap; >>> + >>> + if ( !ops || !ops->read || !ops->write || !size || end < addr ) >>> + return -EINVAL; >> >> "!size || end < addr" can be had shorter as "end <= addr". > > I will apply this. > >> >> Whether it's worth checking ops to be non-NULL I question, bit I wouldn't >> insist on dropping the check. > > Probably it isn't really needed but just extra check that someone miss > to provide implementation of ->read, ->write still could be useful. Also > it is executed only at boot time so not big perfomance impact. I questioned merely the checking of ops itself, not that of the ->read and ->write hooks. >>> + write_lock(&vmmio->lock); >>> + >>> + if ( vmmio->num_entries >= ARRAY_SIZE(vmmio->handlers) ) >>> + { >>> + rc = -ENOSPC; >>> + goto out; >>> + } >>> + >>> + /* >>> + * The array is kept sorted by base address, so rather than appending and >>> + * re-sorting, find the slot the new region belongs to and shift the tail >>> + * up by one. >>> + */ >>> + for ( i = vmmio->num_entries; >>> + i > 0 && handlers[i - 1].addr > addr; >>> + i-- ) >>> + /* Nothing */; >> >> for ( i = vmmio->num_entries; i-- > 0 && handlers[i].addr > addr; ) >> /* Nothing */; >> >> ? > > It seems like it will break the code after it. > > This breaks cases: > 1. On a normal exit (handlers[i].addr <= addr), i is the index of the > entry that was found, whereas the insertion slot ought to be i + 1. The > code below, however, uses i as the insertion slot and handlers[i - 1] as > the left neighbour - an off-by-one. > > 2.If every entry has a bigger addr than the new one, the loop exits when > i == 0: 0 > 0 is false, yet i-- has already taken effect, so i == > UINT_MAX. Then i > 0 is true, leading to a read of handlers[UINT_MAX - > 1] and to memmove() with a size of (num_entries - UINT_MAX). > > Case 1 pretty easy to fix, just use proper indexing but case 2 will > require extra check at least. Thereby I think we could keep here > original for loop. Oh, I'm sorry for the bad suggestion then. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 14:46:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 14:46:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413209.1643428 (Exim 4.92) (envelope-from ) id 1x4JYr-0003o3-VA; Wed, 09 Sep 2026 14:46:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413209.1643428; Wed, 09 Sep 2026 14:46:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JYr-0003nw-RR; Wed, 09 Sep 2026 14:46:05 +0000 Received: by outflank-mailman (input) for mailman id 1413209; Wed, 09 Sep 2026 14:46:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JYq-0003nq-R1 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:46:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JYp-00HGRr-Me for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:46:03 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1711d-e002-0a2a0a5209dd-0a2a4501c0a2-32 for ; Wed, 09 Sep 2026 16:46:03 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1712b-5984-0a2a45010019-4a7de14cb59a-3 for ; Wed, 09 Sep 2026 16:46:03 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485b1d2874aso288674f8f.1 for ; Wed, 09 Sep 2026 07:46:03 -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 ffacd0b85a97d-4858bc74298sm40334717f8f.6.2026.09.09.07.46.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 07:46:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788965163; x=1789569963; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Lgbui3E8HMFt4aMlGQ4+Kjn+ED8eLzo4WfdkMfbAOdc=; b=FOyHtH88gSSCFmntT1pmqWfkSX/GRNiuSkqcg3grolq6wb6QTfDApkOxMWy+X8kOCb qPgR8vP7YiaX84vB50eRCONJ4uSoGItXQXzLGDWxefMkF5zEiWMKhiErFaHRdmadYF4g 0hQdqzmszwsOFNxKxSVIboJ5g7vA3i08qTqFhY1DRnqgcwoxW+lKg/rgUesxt4rUhGln XKa7Fjd5b2enedQqc2dvw1fPlJgaIedwOdolxVa5NAlvOcm/FekjO+SjQJS23Q8zdUoX letE+WwlG7mKcs24s15041qUCk0OtwCVdtbXr66+PIO9WFBkP/Hnsd7M39lZ5vbU177k syJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788965163; x=1789569963; h=content-transfer-encoding:content-type: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:content-type; bh=Lgbui3E8HMFt4aMlGQ4+Kjn+ED8eLzo4WfdkMfbAOdc=; b=rFLv7O66g7Y1dxQyNgTyx9dRddqhC/1lXAEKzR9oBJ9k8oaH3ZlO1J3tmOTgPLR/Q1 L5hG22lFJj2/Di5kMqtsIFjY6QOSWxHPoCPnlh2HmO4zgQd0Nyy1p3VUQNP4NCfVk3lk BLYGPq7A76AoUKcrt9oKxlw7hT+8nkSCC5drJDzxAxpCMzCOr9T973VCqFRn2jbrvpZ5 0ljrsVowvabkTWUMKeG0CdJsEV6kde9oEc97buktBGFCNurD8jH8q+lIgbmXTvk91klq VbGG4PGpD6wBo8KRVWAldLgNp1amRQOyKw6SmwxY/exH9yWGeSaPyhkz8YnNCwhlUDeP Lchw== X-Forwarded-Encrypted: i=1; AKwUvBx96pcbgxo9PXHGLwGIHT3iklQ9KL8yjkS+UYDWXHHk8KesQie6IMjPiZKAEabVQEi3F9AjknevRNw=@lists.xenproject.org X-Gm-Message-State: AFuF++nxJcdLDgRPS1gVlxLPBczxJZGapPRnui5v7N2MmgkrSkfxwJ7H ehRZtvSRU+xOkGivS6eIVlY79zmO+ZySWKno2WWxPN3ORnSQ9l91Fqydn3h2diIdkQ== X-Gm-Gg: AYBFou3IDNiqqhy02BDv8oOoqgG7ZzQhP5oWzQYlboEtOEt73ewKrElxauFhqdton6R YggtsVL9yev+HhYwtz8590EN5x/9FKmqQg468p62ABaEvFeiK0rqGp31yVKierFNboZgj42hKtY hcyOYPK0mzUoo7F40Pf3fe90XYVar1bMn9luScUvLtDB8IBsJJpwx3j1ySzbEjjIp9JpH2bkZFl i6XVT6LukgHjD/IAon/0EfIMoUh+iBOdwXuFGybDYwiMvR1nPy0bDYY/fHQb4wc6BjTS8gN+Pub 4Ul8Sbo/0dZdtqwK5H9CH891khun/0QpHeZlLq9CVYbaWeYaK+CnX64qVPXftShm0kjm9r00HtQ Ut96wsvu+iAtKXJYO1h/nGp5SmnOQZHVyzzZZOKnnzHLXCGrIHe8B7aXfoin3BPWO+xLePUcv4p 7W36dz0psGo81lklqN5n8shUmueiuEXf4XXzmDAC+KiuEOHTzoJ5KV9w0ZbLtcylP2k3WyHxkfz UZtJlrPuqGylTp1yg1ovoifHefxWBkfvus9SZOt3BgaGYapxOjDaIBIYBUojqY= X-Received: by 2002:a5d:584f:0:b0:484:3314:eff6 with SMTP id ffacd0b85a97d-485c240e5a3mr3515484f8f.28.1788965162908; Wed, 09 Sep 2026 07:46:02 -0700 (PDT) Message-ID: <92c9bf4b-5171-4a26-a62e-f2a7b1cb89ef@suse.com> Date: Wed, 9 Sep 2026 16:46:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/mm: limit deferred TLB flushing to PV domain support To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260909140500.73483-1-roger@xenproject.org> 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: <20260909140500.73483-1-roger@xenproject.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1788965163-C4359757-5C97A854/0/0 X-purgate-type: clean X-purgate-size: 1274 On 09.09.2026 16:05, Roger Pau Monne wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -1538,8 +1538,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) > BUG(); > } > > - /* If a page has no owner it will need no safety TLB flush. */ > - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); > + /* > + * If a page has no owner and there's no PV domain support it will need no > + * safety TLB flush, there can be no stale TLB entries. > + */ > + pg->u.free.need_tlbflush = IS_ENABLED(CONFIG_PV) && page_get_owner(pg); > if ( pg->u.free.need_tlbflush ) > page_set_tlbflush_timestamp(pg); I'm okay with the code change now, but the comment is still concerning me. All by itself there is no reason why stale TLB entries couldn't also exist for HVM guests. It's just that (a) only the host TLBs are flushed by filtered_flush_tlb_mask() and (b) flushes of guest TLBs occur when pages are removed from their P2Ms (aiui; hopefully true also for Arm). IOW what the comment says looks to be correct, just that it leaves too much to be figured out by the reader. At the very least I'd suggest "..., there can be no stale (host) TLB entries." Thoughts? Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 14:51:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 14:51:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413217.1643437 (Exim 4.92) (envelope-from ) id 1x4Jdl-0005Wb-Fb; Wed, 09 Sep 2026 14:51:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413217.1643437; Wed, 09 Sep 2026 14:51:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Jdl-0005WU-Co; Wed, 09 Sep 2026 14:51:09 +0000 Received: by outflank-mailman (input) for mailman id 1413217; Wed, 09 Sep 2026 14:51:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Jdk-0005VJ-LD for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:51:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Jdk-0039a4-1b for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:51:08 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1724b-8faa-0a2a0a5109dd-0a2a4503aac8-24 for ; Wed, 09 Sep 2026 16:51:02 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17256-fae8-0a2a45030019-d1558035d8d9-3 for ; Wed, 09 Sep 2026 16:51:02 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49b0d78a801so59275265e9.2 for ; Wed, 09 Sep 2026 07:51:02 -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-49cf7740d44sm1037476305e9.15.2026.09.09.07.51.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 07:51:01 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788965462; x=1789570262; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=gUYQi1MVI1FsspeqjeqM6EEgqL7Bgt2IUomotef3ofI=; b=RuYuh3ubU6Epm5IQcJ5aBgJvxkfyAlvimnpNjUlXiNn6XxQhnWiydxp7K456xGyT/M 46YJJy/PsqboYe1QJwdzYHggwyexhyRBXRLRmR+tCeHOFlH8ocggsRWrm+6sV3b9ICud RBKOzEbzLPwyaJgHEybXmgHBCsOdF5pfZfvHWPAEdlSdRp9MooR+sph02sTSZOW+qCVL 0lQFdcl8bgcmKrvbDEKZkWeF+XX7Du8bJAkFTL7+Xz2Rnc8r/53QtF8NHqcNAlqAiyi/ NH07s/rm8AfJEE0idOhbB08ekX31dII9nZpsr6OOFPn53mXbmCF8nDCfDsZic3O7ccLA k/EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788965462; x=1789570262; h=content-transfer-encoding:content-type: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:content-type; bh=gUYQi1MVI1FsspeqjeqM6EEgqL7Bgt2IUomotef3ofI=; b=A0fFpGs9H0QlhhYq5ej8toGbpimJrw8y5yp7yCIU5ULewNvk0ND+Ib270oe4AK5bTa M+44h+h+H9Q0gHt0BdsWX5JI3wdi2NXNrVfndmCZYVpaPrXV0WYHwFCRY0XaIQQTxJf9 KCob02zgCFMtBpYAWWpR0XhcPV+H9F8/gOkptPL2mKNMpMIGWWoVE6AOn/9A2XTQ26M3 qA1BJb5+rsuWHlXZZ1SF/nQPUgNjjzr0g9SgS1MDqYU0F3HWTvqRfL+NCg1KBAZ+X/Wf 1KcPiikpztRDUAMRrKr8saw4kJA1f21G6D8jQ7geAnDTZUoUQsjFU/U9QSwMdM324b5a IYBA== X-Gm-Message-State: AFuF++lACA4gLjTI4Swd893yZ/17VtKDg0RMH+wTTxcEAyG4Bg4N1dMc gBABCjZ6/RHjKk/AvdTGXOuB0oFb/WbcVO8yLptT5/ukwm/Bzp24EqzXeG4BRRtUJg== X-Gm-Gg: AYBFou2R88bun00fPu5/AVXsJKdVwUnrU06Dmt02ko4TYLWXruR/HBrmLLeBA97u9M8 MKz+TS7e9+t/zQly6yACF4wQfaWGqvH7XfH1iUxZjW0YmvXQtKYnSK1nBsUMkS+KXEmHkuyQRV0 NnxwZM+cTwtX+73rQd1R//504/4K8GIwj+A9Fl4FHSBn3ZDsQi2fWdzuVSI3NSxXOWfEvmrWpmS 7EM540kNrquRLDQnfet3700m42JlkEOD51/TKtNRVD94zznH2huwnq3pwTE0WB2YL5WtJc5Dtie ScfKj/v71FM9TVQHKz4HYgq4pP6qz4NFIvctI8MwW1AsH82WYm6Fzdrb7x7L+yXcdB2qdDs7+L7 WhnaZvuyoQhYPOvkoDuQn84pvT2IDSOWv40H12CY36y8ecBY46D9IyW9su5f5SgSey5Qx+Ye3uY tYViHstSYI++X0PWRtNMqNRdM/KFGjzDE5UtXcLv3a3Jln605MNm384kHPCBFD1Taj4kwr1ESiD N6Vu2xd2aA2fjvPuptNGQoo17APn8aDhqXryFRkcuPOX/Ntdh8sV/LBxmF9LNA= X-Received: by 2002:a05:600c:6098:b0:49c:fc6c:be05 with SMTP id 5b1f17b1804b1-49cfc6cbfdbmr379845445e9.28.1788965462046; Wed, 09 Sep 2026 07:51:02 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 16:51:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Baptiste Le Duc , Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> <1788510380.8631fc262581453bbf619ec5b2062170.1a06b869ff7000c4f3@vates.tech> 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: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b869ff7000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1788965462-77AF14E9-C1051B53/10/73395122804 X-purgate-type: spam X-purgate-size: 808 On 04.09.2026 10:26, Baptiste Le Duc wrote: > On Thu, 27 Aug 2026 17:20:54 +0200, Oleksii Kurochko wrote: >> aplic_set_irq_affinity() open-coded the packing of the group and hart >> indices into the target register, and got two things wrong along the >> way: >> >> - imsic_config.msi[] is indexed by logical CPU id, but the index was >> run through cpuid_to_hartid() first. On any platform where the two >> spaces differ this picks another CPU's interrupt file, or reads past >> the array; >> >> [...] > > Reviewed-by: Baptiste Le Duc I'm puzzled by this being unconditional, considering the naming comment you gave on patch 09. With the (aiui now agreed upon) renaming: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 14:52:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 14:52:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413222.1643446 (Exim 4.92) (envelope-from ) id 1x4JfQ-00060j-Pb; Wed, 09 Sep 2026 14:52:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413222.1643446; Wed, 09 Sep 2026 14:52:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JfQ-00060c-Mw; Wed, 09 Sep 2026 14:52:52 +0000 Received: by outflank-mailman (input) for mailman id 1413222; Wed, 09 Sep 2026 14:52:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JfP-00060W-7B for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:52:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JfO-00DlEY-5L for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:52:50 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa172b9-8faa-0a2a0a5109dd-0a2a4507ca6a-14 for ; Wed, 09 Sep 2026 16:52:50 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa172c1-b4ea-0a2a45070019-4a7de14cb9bb-3 for ; Wed, 09 Sep 2026 16:52:50 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4834977ae75so695894f8f.3 for ; Wed, 09 Sep 2026 07:52:50 -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 ffacd0b85a97d-485883c074asm43508683f8f.23.2026.09.09.07.52.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 07:52:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788965569; x=1789570369; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=7MTDuaKiColxHVcHeUOieknlvsgeaH6ki8cCSq2F2+I=; b=c1BTG2g44ZzihEAAX561N4XqmrNrIAdYYFuYJlUBMj6xTSmyJm0x+H6xJq3gBkBdFT UI2eBIdCE9f5AM91I1st1/YjY8UTTan99sEht0qloO3w92tbdOVl0cZRr74oGdaaUhzA AeKLXBAnXXAcYGF5nksSnltDQ0if6/gIF8opQckUXzsg6NKuMz0fSghfR52arMYDbla9 2eDjw6h30AwhTEdFf25DkO9bvKngMOstDytEfbAo+s0AD/uXGF9mxYnUGd5EkcXHLLT0 WcRevn+DkeBy7lCpGyfapWVhxLLKPKo8XHSx93cZ3S0BUcjKZTRS9xgWGu7M/iWFNosr 1Pmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788965569; x=1789570369; h=content-transfer-encoding:content-type: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:content-type; bh=7MTDuaKiColxHVcHeUOieknlvsgeaH6ki8cCSq2F2+I=; b=UTT5NYYkerHA526zlK8R4G08dv7nAM8OfQJBzKm4bDsXDLAwK0QR8s1YiDzOeA+chZ Ar8awB8HcsaExqFGBGrDKH/epMlfxL0N4jssnhoCClO2gGeUKnLLhg9DpJSwRTv3uecB WOSFxLrQfMqsf5ZTIYKsAj3kmAmpa0wEmgqe5IQJLhDtu+3EYHNWpP+pwPaW1PKGuIrq efRBIY0jQrtMMZnll25/xIG2dS4vvIQ/+JnyVXFiyKq+XnI7UdGw/gxzEHDk/vFIPgYH pSXbY0l3NbPQgV1e4MUxhP8ew5OuImJbHPMohHrruQQAgBLJqY9RTQGOLTnGsT5z/ACU jAXQ== X-Forwarded-Encrypted: i=1; AKwUvBxhtXVgJ3fkd73vduQO9V5X8gTyy/uoRPkUtHaGZusmTRIUwLLBV2qx3tB/FcsQ76XeerugO9yq4Yo=@lists.xenproject.org X-Gm-Message-State: AFuF++k2QCYtBGJXSJBpgthTgj6dErJ9m1XhIZ5RFGj6m8DAVvR62zxa hf66oq21zu9qU5ARRyWI8WMb2wPN4ZFnfspsTeiCBRWJO0FNwnnCCxUWsm6qFf5k0A== X-Gm-Gg: AYBFou0n4yGcrtu2ttbrFL2Fib/0WLGbJgA4di9K+/mJ8o4JOo0/+dLB1z11xWyNxWF j0ayR77J36uFanQGrQPxSaxVN8M2wHXMDDsdiNLG50W7zhSum7CN9Jp/jbRFAxfgUofKcdeQMpZ gya+hUE+loMV25vLybJ91m2yb7LhMdGSb1gRP/7kk46AkuQOOabz4idq6I/Ovga1oqAA9he6Cy1 F5plvZtoIezjo5WiXoYyP1L7VuqYymTV9DmU1TzuDUu/Zsih4/q2sGkIm7ByrqH3Gjs9HOTe91D JwcONhOtd/NhUGrfGfCUP7bs2e19EHYlP7zw5u3K9XoZ38IEKI34+c1ahvE9LG1ZcQ8wlYb7gex IHEZJvryLGV5xwbMhd+Hm1/fHL0OOkkuLA6+QfJiFwjUcqzP2uocNdT0zwzOB2pnwhHAiF6eLM4 NNjFSDrWJ5IEiLq/I70tHsf7GQB62xggvQoletyWrhpkkuAEmbQn3+fKLmP5lbKcFMshJRm7GAr bIVmAacvFhnUL0X8e6hmuNWaqbRHKNWdqZhMvirauODKxZcZkQWAmdhRsoLKH4= X-Received: by 2002:a05:6000:402c:b0:485:acfd:4fa2 with SMTP id ffacd0b85a97d-485acfd572dmr9381409f8f.28.1788965569410; Wed, 09 Sep 2026 07:52:49 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 16:52:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.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: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1788965570-A4AC8AE4-E96C8034/0/0 X-purgate-type: clean X-purgate-size: 1761 On 27.08.2026 17:20, Oleksii Kurochko wrote: > @@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask > > ASSERT(spin_is_locked(&desc->lock)); > > - cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask)); > - hhxw = imsic->group_index_bits; > - lhxw = imsic->hart_index_bits; > - /* > - * Although this variable is used only once in the calculation of > - * group_index, and it might seem that hhxs could be defined as: > - * hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT; > - * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted > - * when calculating the group index. > - * It was done intentionally this way to follow the formula from > - * the AIA specification for calculating the MSI address. > - */ > - hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; > - base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT; > - > - /* Update hart and EEID in the target register */ > - group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) & > - (BIT(hhxw, UL) - 1); > - value = desc->irq; Hmm, only after sending the ack I noticed that there's no masking here, ... > - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; > - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); > + cpu = aplic_get_cpu_from_mask(mask); > + > + /* Update hart index and EIID in the target register */ > + value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | > + (desc->irq & APLIC_TARGET_EIID); ... but there is masking here. Chopping off bits doesn't look as if it can lead to anything good. What's the deal here? Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 09 14:53:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 14:53:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413227.1643455 (Exim 4.92) (envelope-from ) id 1x4JgE-0006U5-11; Wed, 09 Sep 2026 14:53:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413227.1643455; Wed, 09 Sep 2026 14:53:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JgD-0006Ty-Ue; Wed, 09 Sep 2026 14:53:41 +0000 Received: by outflank-mailman (input) for mailman id 1413227; Wed, 09 Sep 2026 14:53:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JgC-0006Tp-Ij for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 14:53:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JgB-00HHl6-VL for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:53:39 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa172df-8faa-0a2a0a5109dd-0a2a4502aca8-44 for ; Wed, 09 Sep 2026 16:53:39 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa172f3-6ca4-0a2a45020019-4a7de18c9b97-3 for ; Wed, 09 Sep 2026 16:53:39 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso3993715e9.3 for ; Wed, 09 Sep 2026 07:53: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-49d0af538d0sm353600305e9.8.2026.09.09.07.53.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 07:53:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788965619; x=1789570419; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=ibtg7GRbj5aBCLz+vm7BKyUkJ0AR3wj9fM1b/8ldv1Q=; b=RACS2LklzdVcsDrLoxcRxtLad7fwg2LLtM9MLpw8aQYnLiQC7m3VzL4eI5y99SBiPi 3AMVLAb3iNa+qYcfFpLQlyregF4RSE/hmrQ4rSJbbxnHOvq8W6KC/tTZV0kSFjFKHdzw YCXdILRT3EnK0/tvE5OaQcLNL6AtkasmcgfU/QaDlezYjJsxiy36CjhkM6TJMq7x+tbc QUOX0/r3hYFwwtIXCrbV433ylslxGqdGqpQ9isQiWyECGQV5ftFfiiKDc6VD/6RE/mGk FzMKgBjk6+55ugbgppHQ3W2itL7IsDXELErunmH42pNTxKTTOb87pQBcPjgK58W25Ilh Z8yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788965619; x=1789570419; h=content-transfer-encoding:content-type: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:content-type; bh=ibtg7GRbj5aBCLz+vm7BKyUkJ0AR3wj9fM1b/8ldv1Q=; b=itU7ECdLFXbq6lMdnHdY1LRKm0zC2ddTmUk2P0QnQHU3hcmGXuYNyMyDeFcm5IkB+f ge4ruo/CC/+AEcvIC++MrrEVu/7si4naQKK2l28snAJhQEEESYIzRiqqPIld+9l60Oob nFnbVTb3+5vvbC4jSqvUCghtuqVEgSoILxGJ1yHcdeFXJJCxFXDAarfEcZkNb4fLCPkJ 2Pkot0dB/rC3umJw9MGLaMwhdyQcpR4ParHEJSMlCTPVApbCt2AQxJdPv5HiJRTcgmjN I70V+84zmzHDHSN8ZjDpGwvZSaffB0v3KFq9ldhbGRMI8rWrbrrdS9o3ZkRB4/bq8UCJ +1QQ== X-Gm-Message-State: AFuF++kkwVfBravukQGSBjkDwVRIAYbAyBK3b5Brjkn2a7xsiQRFIWRN /79rhBunvNN/5Ja2X7MQ5LckNbjDOnW2XhVJFGn0hT4Bcmwav7X+k7z2mSpZWey/hA== X-Gm-Gg: AYBFou3q972VLGuI7+BfyFe7uN0wjJ7haHrXuLniuHhly3uupX84/D4dgrvdnnrcJiI DmkGC1CI9b7H4K7dtbrUr78jT53OsViWRAKyaT6uB4RVk6Gxs+j2kZl7m2heYz/tOKLyOUUD4ET bNcWXclx2UpBHi5OuYTirRv4ZWZFOcS86GPONCQbARCv4ukN7kHVHkAtFsBdZ1esjpzPDR7EKgQ IbJw1QpgvSwyATWStrWrIUcG9xmowRXrHlC5PvPodqiLo5z8WF5AvdHLbGPyHzqRTf9Zwmf85Zl 9Y32MdJMpHUIMRV57ZEbrum0x1l0XiazmXrrPVbPK19h5pZ6eWqyggHx8ElTY8QH74fOm+gwkQE YnToYxvdi31DvlquhkehGDmGNN2fEy5vVIMBVafzIqI7MnxbsdXWs5slP8XkfIj6mkwgcaFtc1H kaXb/K2CkNN+cmIPmkKzuJ67XvKCFRKWYhKBNNL4pPt1w7TGXfITfp1nypVwkuTgsiAhlsow6oX Rf3nky2kMvaOOospLOUDnw+V4YPH3scIhZeSvjvjqcBBjG9sTAvX5q6XizgvRg= X-Received: by 2002:a05:600c:46d5:b0:497:fecd:5b00 with SMTP id 5b1f17b1804b1-49d258d8be2mr14718035e9.9.1788965619128; Wed, 09 Sep 2026 07:53:39 -0700 (PDT) Message-ID: <7fe791b7-0a35-474b-924d-290595935621@suse.com> Date: Wed, 9 Sep 2026 16:53:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/39] xen/riscv: add helper to check APLIC MSI mode To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a1b8000c4f3@vates.tech> 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: <1788510380.8631fc262581453bbf619ec5b2062170.1a06b86a1b8000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1788965619-319CB2AC-E5AB16F5/10/73395122804 X-purgate-type: spam X-purgate-size: 308 On 04.09.2026 10:26, Baptiste Le Duc wrote: > On Thu, 27 Aug 2026 17:20:55 +0200, Oleksii Kurochko wrote: >> Use convient helper instead of open-coding the things. > > Reviewed-by: Baptiste Le Duc Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413249.1643482 (Exim 4.92) (envelope-from ) id 1x4JuH-0000pp-Tm; Wed, 09 Sep 2026 15:08:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413249.1643482; Wed, 09 Sep 2026 15:08:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JuH-0000pg-QR; Wed, 09 Sep 2026 15:08:13 +0000 Received: by outflank-mailman (input) for mailman id 1413249; Wed, 09 Sep 2026 15:08:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JuG-0000p1-Oo for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JuG-00Cu0U-5R for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:12 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17648-e002-0a2a0a5209dd-0a2a450ad012-42 for ; Wed, 09 Sep 2026 17:08:12 +0200 Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1765c-f2d2-0a2a450a0019-d155da2ad51d-3 for ; Wed, 09 Sep 2026 17:08:12 +0200 Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c2938116fefso119849366b.1 for ; Wed, 09 Sep 2026 08:08:12 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966492; x=1789571292; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=SGIWlTbDaP0A9QeYN/SYThh0YL+nKcmDxCzTgmCJBSs=; b=Vcy9qTzC5oyzOybAnphld3Lmoj0cnx8KFsgD5lvb/mRMRzB0z6mJCpJhxoS8EWtjl9 4mcFF77O+crTHEDO2lTZ0a0FoBSJDU8svU7G/ypCq+wQfuuZZpA1YfevjLVhJyJ8682s XRllNBpLrNwT/UzsckzmHpQidXqL94YM0PU/38KCmq2J+DLHcjj/6SMpAA09v/AOGlb5 efZxt0JVXs4WKAsOXlMbzXqf+zrzJCFnBvtPybO7toVQ029Sa3aK3c2FTG1IgN8xwImD IjJa/VYU9mlNKC9EYRN4QzF8Mv0Ky2Nw6oKQ/RGo6Y8mkswEnvkqyH5F5wJW4teFTyjE 4oMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966492; x=1789571292; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=SGIWlTbDaP0A9QeYN/SYThh0YL+nKcmDxCzTgmCJBSs=; b=USoYzmgAYOKNoA6HM4Tw/FsYxzlnXgZtWYCyabBvX5VxW8kCWa9fQm0XlJOlVt1L8q 0oxNYaOcprID5O6Of3lX9mp3pTZTpieXOy/i8TWMTd2qLc5vTfkywgRSoj4Tu8Sm6zYx f7lD+aqJqUHyHoK1iHubOXgFw+byvmrGbCgyDOapgXH7hrzAirifqXEgbyuQN1TIvbVW YbeMxkqDwbYCmxUeGAbHHZkIzlo2VHm9Yn4ovvrZ6zf//vBsF2AigPlN34gWjEQTC2yF hbIgfg8OyITWuN+JS3wCfyzM71BcsTcik+UHOEwZqrwiN77Z/3E3aSfu1/BagBN8DiQe NGbQ== X-Gm-Message-State: AFuF++m6OCp+o5UDFOjsmA73Ye/1qB3WN51B6piBqZS+AHuoyKkL/vdg NR5YVk2INqToACt/S5BWIcbL7pgdF4w65w0OCSGbbhuVnOhi+Sf7PW0GdHJ6QgH9 X-Gm-Gg: AYBFou3bHmF/MWzVIzVxGZ43UsR5mmG9xgGO1aAW6DTJeFJ+QWi3MGAIujm2kw17cmv 4F1jN69O1sSjfSmB5X0fSsNUks5cAVbM9RuPBR33LOqU7LJYBsBvmvSTWxVskhotnhFAq90xoRz t+9cxK1HJXjgfv1G7u5taqVSX7naArWDurHhcdsxy9qS4uq1kIhdnGf9yblayqWiNDsdsy1nPoT MRoglJIR5hKC8lSBmr/fwSK0X4tb/w9KUY1T20Sck6YJZN1a9icveLM6R0s2A67SdpLIul6i+8x sXAi4sUhmp386Q+TeoYDXSf5OZ/KN+lnHiaKqMze35nDqfKOsbREGlmhx3Dw/+PwABG1i2Wygry H+9tLVZQPbBkiDzEs1MQ9ZEWLVpYp5zfiIL6RlVqjZuuKQWP6tPECzUF7ECpCOa/D3CZqioZn5I qoDbhsJzjydy0smIYAur3Mn9orrTK2UZjqK9/WlieN4iXeMYD2TKeVEncwE3EhU6j7dwQf7/fRo O0uiwtjOziBICfcpoQ= X-Received: by 2002:a17:907:805:b0:c29:3a1b:ec7a with SMTP id a640c23a62f3a-c293a1bf1bfmr147233566b.10.1788966491349; Wed, 09 Sep 2026 08:08:11 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie Subject: [PATCH v9 02/20] xen/dom0less: turn max_init_domid into a common variable Date: Wed, 9 Sep 2026 17:07:20 +0200 Message-ID: <4d2919b7b191d6fa91c11043e7f08de228012852.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1788966492-59BC0CFC-D7DEA16E/10/73395122804 X-purgate-type: spam X-purgate-size: 6771 Until now every architecture carried its own notion of max_init_domid: Arm defined a real variable (declared in asm/setup.h, defined in setup.c), while ppc, riscv and x86 each provided a "#define max_init_domid (0)" stub in their asm/setup.h. This duplicated the same declaration across all arches and placed a purely dom0less concept in arch setup headers. Now that the dom0less build code lives in common (xen/common/ device-tree/dom0less-build.c sets max_init_domid, and the console serial-input switcher reads it), there is no reason for the symbol to be per-arch. Provide a single declaration in , with the !CONFIG_DOM0LESS_BOOT stub kept there as well, so there is one source of truth and the arch headers no longer need to mention it. Update console.c to include for the declaration instead of relying on asm/setup.h, and drop the now unneeded include. Place the definition in xen/common/domid.c rather than in dom0less- build.c. The latter is built as dom0less-build.init.o, i.e. the whole object is relocated into the .init.* sections and freed after boot, whereas max_init_domid must outlive boot because it is read at runtime by the console serial-input switcher. domid.c is always linked (obj-y) and resides in regular (non-init) sections, so it is a correct home for the variable. It is marked __ro_after_init since it is only updated while creating boot-time domains and read-only afterwards, and guarded by CONFIG_DOM0LESS_BOOT as domid.c itself is unconditional. While at it, make self-contained: it includes , which uses the fixed-width types provided by , so include the latter explicitly rather than relying on the includer having pulled it in first. This becomes necessary as soon as comes first in an alphabetically sorted include list, as it now does in domid.c. Signed-off-by: Oleksii Kurochko Reviewed-by: Jan Beulich Reviewed-by: Michal Orzel --- Changes in v9: - Sort the includes in domid.c alphabetically ("dom0less" before "domain") and add to , which the re-ordering requires. - Drop the leftover include from console.c as nothing from it depends in console.c anymore. - Add Reviewed-by: Michal Orzel . --- Changes in v6-8: - Nothing changed. Only rebase. --- Changes in v5: - Add Reviewed-by: Jan Beulich --- Changes in v4: - New patch. --- --- xen/arch/arm/include/asm/setup.h | 2 -- xen/arch/arm/setup.c | 2 -- xen/arch/ppc/include/asm/setup.h | 2 -- xen/arch/riscv/include/asm/setup.h | 2 -- xen/arch/x86/include/asm/setup.h | 2 -- xen/common/domid.c | 5 +++++ xen/drivers/char/console.c | 2 +- xen/include/xen/dom0less-build.h | 8 ++++++++ 8 files changed, 14 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 0adfa4993a8f..2af780512540 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -25,8 +25,6 @@ struct map_range_data struct rangeset *irq_ranges; }; -extern domid_t max_init_domid; - void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); size_t estimate_efi_size(unsigned int mem_nr_banks); diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 6310a47d68b6..86532d0a35b6 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -62,8 +62,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo; bool __read_mostly acpi_disabled; #endif -domid_t __read_mostly max_init_domid; - static __used void noreturn init_done(void) { /* Must be done past setting system_state. */ diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h index e4f64879b68c..956fa6985adb 100644 --- a/xen/arch/ppc/include/asm/setup.h +++ b/xen/arch/ppc/include/asm/setup.h @@ -1,6 +1,4 @@ #ifndef __ASM_PPC_SETUP_H__ #define __ASM_PPC_SETUP_H__ -#define max_init_domid (0) - #endif /* __ASM_PPC_SETUP_H__ */ diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h index 2215894cfbb1..73ce2f293348 100644 --- a/xen/arch/riscv/include/asm/setup.h +++ b/xen/arch/riscv/include/asm/setup.h @@ -5,8 +5,6 @@ #include -#define max_init_domid (0) - void setup_mm(void); void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h index b01e83a8ed9f..5925c5f39cff 100644 --- a/xen/arch/x86/include/asm/setup.h +++ b/xen/arch/x86/include/asm/setup.h @@ -68,6 +68,4 @@ extern bool opt_dom0_verbose; extern bool opt_dom0_cpuid_faulting; extern bool opt_dom0_msr_relaxed; -#define max_init_domid (0) - #endif diff --git a/xen/common/domid.c b/xen/common/domid.c index b0258e477c1a..c0cb025609b8 100644 --- a/xen/common/domid.c +++ b/xen/common/domid.c @@ -8,8 +8,13 @@ * Copyright 2025 Ford Motor Company */ +#include #include +#ifdef CONFIG_DOM0LESS_BOOT +domid_t __ro_after_init max_init_domid; +#endif + static DEFINE_SPINLOCK(domid_lock); static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED); diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index fcacf37c52f0..e4df0bbc2eec 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -30,7 +30,7 @@ #include #include #include -#include +#include #include #include diff --git a/xen/include/xen/dom0less-build.h b/xen/include/xen/dom0less-build.h index 4118dec76c0a..75bfaa185fa6 100644 --- a/xen/include/xen/dom0less-build.h +++ b/xen/include/xen/dom0less-build.h @@ -4,6 +4,9 @@ #define XEN_DOM0LESS_BUILD_H #include +#include + +#include struct domain; @@ -13,6 +16,9 @@ struct boot_domain; struct dt_device_node; struct kernel_info; +/* Highest domain ID assigned to a boot-time (dom0less) domain. */ +extern domid_t max_init_domid; + /* * List of possible features for dom0less domUs * @@ -72,6 +78,8 @@ static inline bool is_dom0less_mode(void) } static inline void set_xs_domain(struct domain *d) {} +#define max_init_domid 0 + #endif /* CONFIG_DOM0LESS_BOOT */ #endif /* __ASM_GENERIC_DOM0LESS_BUILD_H__ */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413254.1643518 (Exim 4.92) (envelope-from ) id 1x4JuU-0001vV-2H; Wed, 09 Sep 2026 15:08:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413254.1643518; Wed, 09 Sep 2026 15:08:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JuT-0001vI-U8; Wed, 09 Sep 2026 15:08:25 +0000 Received: by outflank-mailman (input) for mailman id 1413254; Wed, 09 Sep 2026 15:08:24 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JuS-0001sK-Kw for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JuS-002kD3-1b for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:24 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17656-8faa-0a2a0a5109dd-0a2a4504bdce-40 for ; Wed, 09 Sep 2026 17:08:24 +0200 Received: from [209.85.218.43] (helo=mail-ej1-f43.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17667-b57f-0a2a45040019-d155da2ba8eb-3 for ; Wed, 09 Sep 2026 17:08:23 +0200 Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-c2569aa5116so928988666b.0 for ; Wed, 09 Sep 2026 08:08:23 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966503; x=1789571303; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/L1VhqjM9/gZZzhdCNypBrVlymm8xmNghq5Zkc3eF/E=; b=HJ/s9LKAUeGxT7JkjlX/o83bXoNqeH5tDwvQ2t1chcSBNh8VNpri/OfVPcvVQNv+6Q Ht3p4EyoKh+bod8LF94WHpFrTeCrC+Z8hiXYNHlSvL7zNq1EJzj9Vl1tM4QYJ5u8iYfz k40H8aZ7pwR3ARosIYab7NvK8WJDapRJBOLDPPvfF67robe4k9SMoF9CIWQZPXUiJwi1 6FlG9WOJA+Yk1797nVeYLXXALelIoX8W9LcZB+zPL127JhhIYxdzqwsCK4hSRvwhR8HF SuhZ/0mqaawg4pAUXgfE8R6fudV1kQBuTCc5NpXtNXA7vg5+EeVXySYSmddQhjzy6uiJ WSwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966503; x=1789571303; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=/L1VhqjM9/gZZzhdCNypBrVlymm8xmNghq5Zkc3eF/E=; b=K4C3u6OpdrPP5D4ooZjmRDJ9eOWpZ+BV2b1Zh8eIbnoon8JDu8cJ1KVaikJ80ueoXs QnM++XZ4vkbOF/EhkEZM1+4T6BsNTmTIEMxWzSMlxOmcX+f8Sl/7abDGmb7+H7ZyxwGq GhiiWn9m6aAyuEuz3RbYHIbMa3Rjs6V0zkW2FUwVhJU1/KMY3+OartwHtX+hu4Va0b8A 7Uok7v6zs1Lnh9fMGdZmNrm+96vOWUi/KR1l2jMvoViuwpAvz6ICRlSIZHtoG4LMoob8 KsSOTNh+BS5l9Rit72laDlq6RkcP7ybs/qnLjsAyxoNX6numb0izTJpadhhtrLotATvl oDPQ== X-Gm-Message-State: AFuF++kukREZboqrBfoD4qBejDscg4kbnlDUGw5ypoK4G+4W4swh8Fi4 n6iFRm32fLfAZuSaAcauRWkK1PCZQajEKCrH+BqOiHu0R6JBb3SR5eErE6cIDWks X-Gm-Gg: AYBFou0UL+me/gM0Mt6cF4JFHCPHYYaX9kqFuWAtQeWpVxw6cQhCaouKPTPXbyoEfrK 6S3mn2QrSoRS3bqmBGYcyaphkJdCMuB0B4RkQJ9jOeCloabXBrR6Ab2mnyXREhE9f/stwMUVUSC fBV1yh2hdMM95eAYeAbYqaB1QSy7rspSRRDz9kj1wfbfSknkRcpHtW64otI7tueWly08yHw3SuE QCS0HrVC2ojhRCEsKHx132o3EbdbG9aE9zdZ6/slOvsvTki/1PkmZQjaqcBsg3P2Qcvd2H2hmF6 MS8d3taeSOawxcpY/ufmiC1EK/1w2oBBNpG0VHl6DJVx4kk7Z1R9hjbCG+l88ERaJvyVhYTq2I8 uVelscTKLsH6dlyV19KOFWQeJh4QYDmZ1pdPc1V5zppleyn8MaKkQ3u0gPd6lFVRQIbDXTq5Wa4 5t2dxD+8/V73nxObqtJBwk0l6B/P3aszgIEO+xUX05rUT/b2KXIazKsJunM9RJvIzQNF7jqIHZE G/jwtKM0fW0QCbl6A7ZJVTzMPIJrw== X-Received: by 2002:a17:907:9810:b0:c25:c787:43c with SMTP id a640c23a62f3a-c25f01f0adcmr1884110266b.14.1788966503256; Wed, 09 Sep 2026 08:08:23 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 07/20] xen/riscv: implement make_arch_nodes() Date: Wed, 9 Sep 2026 17:07:25 +0200 Message-ID: <7f0f371c916fb7226f0ec82921e091804affc491.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788966504-C2CCFB50-1294E092/10/73395122804 X-purgate-type: spam X-purgate-size: 1444 No RISC-V-specific nodes need to be created at the moment, so make_arch_nodes() is implemented to simply return 0. It is placed in dom0less-build.c as make_arch_nodes() is only used in the dom0less code path. In the future, it will be extended to create an emulated UART node. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v6-v9: - Nothing changed. Only rebase. --- Changes in v5: - Drop "Add" before Acked-by above the footer. --- Change in v4: - Add lost Acked-by. --- Changes in v3: - Add Acked-by: Jan Beulich . --- Changes in v2: - Update the commit message. --- --- xen/arch/riscv/dom0less-build.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index a683972e9235..4cc00012aa8d 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -2,10 +2,18 @@ #include #include +#include #include #include +int __init make_arch_nodes(struct kernel_info *kinfo) +{ + /* No RISC-V specific nodes need to be made, at the moment. */ + + return 0; +} + int __init arch_parse_dom0less_node(struct dt_device_node *node, struct boot_domain *bd) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413256.1643527 (Exim 4.92) (envelope-from ) id 1x4JuW-0002CH-CE; Wed, 09 Sep 2026 15:08:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413256.1643527; Wed, 09 Sep 2026 15:08:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JuW-0002C8-81; Wed, 09 Sep 2026 15:08:28 +0000 Received: by outflank-mailman (input) for mailman id 1413256; Wed, 09 Sep 2026 15:08:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JuU-0001yQ-Ej for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JuT-00DoJa-Qv for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:25 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17659-e002-0a2a0a5209dd-0a2a4507ddba-46 for ; Wed, 09 Sep 2026 17:08:25 +0200 Received: from [209.85.218.49] (helo=mail-ej1-f49.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17669-b4ea-0a2a45070019-d155da31e086-3 for ; Wed, 09 Sep 2026 17:08:25 +0200 Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-c1c52d920b8so799616666b.2 for ; Wed, 09 Sep 2026 08:08:25 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966505; x=1789571305; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=yk8KF/HUlDCJZvlpTURbkM7U/Ti3G4IswH0NPpHEPoA=; b=QxoZodVZAtG29WKbXX2W0cP+45LEl/vCY9bE9pfV8GdNtQ0hUEbmdi9Kunw3LGegkf AbZbqty5Dj1Rn1u/3X3bagA029tPM5t8Bziaiz/9QdaWqk6foBVdeIwViF9qm9TTyeES C4/xkXX0BZsgrwOwYnNrngx/eUK33GuxRWahZhWARnyW/Pkvgc2q8P9h8PLxI+8EweY6 OdDoTWyl4lXxz3z5yR2D4dQ9Jllpq3fA+DlvI9vyi+e3flRexSF89lNSjsBB+3DmZgg5 sNVJgH1wZsVgFf81c28eTC/dXBianhei7r777L9OZPjYSHNsNsib6L4XfbPHGjKljrTf UpIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966505; x=1789571305; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=yk8KF/HUlDCJZvlpTURbkM7U/Ti3G4IswH0NPpHEPoA=; b=iIAV2akK4K8jrtgoESaPdR9gVeWYIJTQkstRD1hfx4u42dkedCK7vh9E+Gcxv/h5Pl wagUxiNILaMy4caXoFXBduf6UVRwAZqh0dm4WV96ttbFyJHeX/+rmPY8AQ1PRORXwqOg hHgiNPXvKvyuFHEgBUzs6gF1cDrYQQu14cNRL2erH0PWGrR2oM0vXuVmhKgrXiGZEYmg cpGISTkzVrB8ePaIhKOPzFL80HlG6yJEsxc/ro8RKOmMvFrP+Kugu/7oJpfWyXYaFNNe RkuMhRvbP5QeAFsbSW1mykxucWYXjSUfwE/r2YFCZ5pDBKckV89jprCvAgxmm0Hsv5BS 3zeA== X-Gm-Message-State: AFuF++lywUroqMaU7h0uAMxbHbnPp798gSS4NynhoGL0TwzUI0JZYKOP 5834H44T6Ma9biDfxwWJv8NTLdXBVWcuQ5jj9sQUqISv2g7K4WSB9AhueQxVZUTq X-Gm-Gg: AYBFou2xtikHQnmv2mltBUihgbOZUuNEcs1bHzgjknOBfjLvNZoKaQuWkRW8awIKkf+ pDyvEC7Pmf4vDY4QYdGHNRFEtadc6wpy3bqbLK6dbPnGzCLJ9+3NUIiFdp5ymQmoFpiJ4YEjIQy TNKp9un2hapy7DlCLKUgu9KlJsZC6uQFeajsLlv7BMno9ckoKg/Mtp+vtytIgOS/XQsP7SKMiVN 0TyKAFLec8bhH0Bk0rOVBx86s70vLy18wcNarArixQq7GteoTC/RfX7eolvXCupRsGSZEiuF21W FEL7PpWsjpT8FMNxmcvbDuxmfblQbk+jWCRcVjOnCVr09EhTTEQwWObyJCjKJGtwL+cepyxs7Fc zNt2ycAJww4SAhhGZGfTo944m0SCKrtXXQagwE4AnW+kGRdlp90EelGoyDjeZLrAzENmCW7LNRI E+3qETK3rYItkVxonUs/m4tjmVS+uz+2M1NYfqgrWG6pzoIqC8ziuQo5NMresObqtU8fce8v+WD iBOCLG1hjF3wN6ILqA= X-Received: by 2002:a17:907:3d44:b0:c27:420b:7c90 with SMTP id a640c23a62f3a-c27420ba0camr957267066b.48.1788966505230; Wed, 09 Sep 2026 08:08:25 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 08/20] xen/riscv: introduce init interrupt controller operations Date: Wed, 9 Sep 2026 17:07:26 +0200 Message-ID: <5e0a955e030deb690f1a5f7fdd94d6ac7cee794f.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788966505-A6AD8AE4-BCD9DC0F/10/73395122804 X-purgate-type: spam X-purgate-size: 4033 Introduce intc_hw_init_ops structure to avoid risky mix of init function and non-init function. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v5-9: - Nothing changed. Only rebase. --- Changes in v4: - Use __initconstrel instead of __initconst for aplic_init_ops as both initialized fields incur a relocation. - Add Acked-by: ... . --- Changes in v3: - Use __initconst instead of __initdata for const intc_hw_init_ops. - Embed const struct intc_hw_operations *ops into intc_hw_init_ops so register_intc_ops() takes a single pointer argument. --- Changes in v2: - New patch. --- --- xen/arch/riscv/aplic.c | 8 ++++++-- xen/arch/riscv/include/asm/intc.h | 10 +++++++--- xen/arch/riscv/intc.c | 11 ++++++++--- 3 files changed, 21 insertions(+), 8 deletions(-) diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index 9f023db5d525..d08401db46b3 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -325,12 +325,16 @@ static const hw_irq_controller aplic_xen_irq_type = { static const struct intc_hw_operations aplic_ops = { .info = &aplic_info, - .init = aplic_init, .host_irq_type = &aplic_xen_irq_type, .handle_interrupt = aplic_handle_interrupt, .set_irq_type = aplic_set_irq_type, }; +static const struct intc_hw_init_ops __initconstrel aplic_init_ops = { + .ops = &aplic_ops, + .init = aplic_init, +}; + static int cf_check aplic_irq_xlate(const uint32_t *intspec, unsigned int intsize, unsigned int *out_hwirq, @@ -366,7 +370,7 @@ static int __init aplic_preinit(struct dt_device_node *node, const void *dat) dt_irq_xlate = aplic_irq_xlate; - register_intc_ops(&aplic_ops); + register_intc_ops(&aplic_init_ops); /* Enable supervisor external interrupt */ csr_set(CSR_SIE, BIT(IRQ_S_EXT, UL)); diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index 675f703ec97f..d7b34fc15ad1 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -28,8 +28,6 @@ struct intc_info { struct intc_hw_operations { /* Hold intc hw information */ const struct intc_info *info; - /* Initialize the intc and the boot CPU */ - int (*init)(void); /* hw_irq_controller to enable/disable/eoi host irq */ const struct hw_interrupt_type *host_irq_type; @@ -43,9 +41,15 @@ struct intc_hw_operations { void (*handle_interrupt)(struct cpu_user_regs *regs); }; +struct intc_hw_init_ops { + const struct intc_hw_operations *ops; + /* Initialize the intc and the boot CPU */ + int (*init)(void); +}; + void intc_preinit(void); -void register_intc_ops(const struct intc_hw_operations *ops); +void register_intc_ops(const struct intc_hw_init_ops *init_ops); void intc_init(void); diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index ea317aea5ad8..3600d23bdb5b 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -12,9 +12,12 @@ static const struct intc_hw_operations *__ro_after_init intc_hw_ops; -void __init register_intc_ops(const struct intc_hw_operations *ops) +static const struct intc_hw_init_ops *__initdata intc_hw_init_ops; + +void __init register_intc_ops(const struct intc_hw_init_ops *init_ops) { - intc_hw_ops = ops; + intc_hw_ops = init_ops->ops; + intc_hw_init_ops = init_ops; } void __init intc_preinit(void) @@ -27,7 +30,9 @@ void __init intc_preinit(void) void __init intc_init(void) { - if ( intc_hw_ops->init() ) + ASSERT(intc_hw_init_ops && intc_hw_init_ops->init); + + if ( intc_hw_init_ops->init() ) panic("Failed to initialize the interrupt controller drivers\n"); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413250.1643490 (Exim 4.92) (envelope-from ) id 1x4JuK-00013Z-43; Wed, 09 Sep 2026 15:08:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413250.1643490; Wed, 09 Sep 2026 15:08:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JuK-00013Q-17; Wed, 09 Sep 2026 15:08:16 +0000 Received: by outflank-mailman (input) for mailman id 1413250; Wed, 09 Sep 2026 15:08:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JuJ-0000xL-0L for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JuH-002k9M-Vc for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:13 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1765c-8faa-0a2a0a5109dd-0a2a4508a5c0-8 for ; Wed, 09 Sep 2026 17:08:13 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1765d-f659-0a2a45080019-4a7de48ca10e-3 for ; Wed, 09 Sep 2026 17:08:13 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f8694aeso186304066b.0 for ; Wed, 09 Sep 2026 08:08:13 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966493; x=1789571293; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=r1oo8fqOn/g4Do2VHXYk4O/g0/dgS+YsUhtfJgbBmh8=; b=J7PuxVxCvCFogSroI+hEUxacjogC3onZyTiqd7EJi6IqSq0bDSdCNLtC3xspKlGH2i Il16esjFMbRE14XVtwnMXV2kPna9t9FIcOxH69HhXzsIHl3xi9EHoJfWTkpczIsL+cS2 k8kISxcHN5xzEU0ETur6uE7rbNVX1fl/2U3OI6k/JP594Qleo2+Eb04KPK8RD6OIiI40 OCJ/KTIO2EllaOIGmmcNq/glNLtaZtcG29r3IH4Gh+i4PcZnRiEg4NrI4O4XZz5YT5vo jYxl4nlQTGbqE6jm7v4KqK8aBr/+gyTGyVv6tqhBHbqfH/z4aiDT56QOqIUmCa6enC1N h7gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966493; x=1789571293; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=r1oo8fqOn/g4Do2VHXYk4O/g0/dgS+YsUhtfJgbBmh8=; b=SBwD9wSDLzfyP0HyjBD/dBAncW0PC/vo6gghGSIakA5sW6FvgAeYdGLhIvmdJg/bjK +oJCRlSS/ER+DsVvWNi4YH7nA8WAjNmn5qUjAX6Q347WZneWa7ASSeZNXX5kPRE2Io2s 34mOqFVltIHRFTeEAC/5oaAnf7NNb59u61s6RC96p9G9LlMNgKbS8JQsd/LWHoTXTWQr abYTT7phfMPwYWjczExVSOjy/49E4klpFfcl7p++U2g2hD9g+y2p1fXowY0bgUFG5BPp ZYWHFMUo47+ZZ05ugGrH987hCFDEY2Ff59Dy/uP69PFzeHSuHg//oS4dZVWNKMDzG3yE M0WQ== X-Gm-Message-State: AFuF++k2K4LNmRNswB8GyhgDUI2+yOzOAZLVfhqWAtaY0wKIhdXZrP8e cqhqWT9r17V/QsW6wciIFhi7DfPFp4Gj2irlZCAm17ylpdyIHTANyh0ukyiZcmoP X-Gm-Gg: AYBFou1qnlT+Z+Str+OhZXVBJMN0cePynA+jb060rmvgDKH3YYTX74Qm1ZWiJ4YHzDq I2Doomp5aIAbWfAX3htwmMcrkfVb/OOTQx1dt4EIY4+KiglKGqnIFjFubaF4wx6Q/ktqn4PJmI3 tPg9ImUKEkxdjj0Lvwqkk/quN3DiK1Tl1/OyLR+kvgVeg6mYVX3+eFw6n3ZHrYhLwL8D1Fs/22U oDAb1TTbQpGtpKVf7pF40MeX0pdGLvXbpCXN33tU0yXsABR6W7y0as2HRTcXIwK+2Ii76Vgtiy1 PLHkoOVNsiJfFvWdrW0fhE13j+Y/5i+gT6+x2TqrUz5I9XnTijoPh5frMhK0l8kiyhxw0DjZ0tH Hx/vXnFSmaNIdsADenWF91m883pNWeYvJLxd72yI64C5OUc6F5peZpNBTAZWYQs8ZdtIAl9RXL1 YNjDG8souJexD4NUM3laqBU1BZw6FblR7AsTBOysXWzSRroSEXSydVEIflstp8MHGqvKxDKfj9X G+yEHGx8YIMAOQNgD+ovTIE+kjZSA== X-Received: by 2002:a17:907:3e0c:b0:c25:f7db:4bef with SMTP id a640c23a62f3a-c2904519fdamr700357866b.21.1788966493404; Wed, 09 Sep 2026 08:08:13 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 03/20] xen/riscv: Implement construct_domain() Date: Wed, 9 Sep 2026 17:07:21 +0200 Message-ID: <5e84ec86b5144a7387638fea98548a83db2ee03f.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1788966493-D5F4787B-83A6C472/10/73395122804 X-purgate-type: spam X-purgate-size: 3117 Implement construct_domain() function for RISC-V, which performs initial setup for the domain's first vCPU, loads the kernel, initrd, and device tree, and sets up guest CPU registers for boot. It also creates additional vCPUs up to max_vcpus and assigns the device tree address and boot cpuid in registers. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v5-v9: - Only rebase. Nothing changed. --- Changes in v4: - Drop the blank before v%u in the printk() failure message so the output matches that of %pv. - Restore Acked-by that was lost in v3. --- Changes in v3: - s/%d/%u for printing vCPU index in the failure message. - Drop dprintk() for successful vCPU creation. --- Changes in v2: - Rework construct_domain() to print that vCPU1...n are created using %pv. - Use true instead of 1 for initialization of v->is_initialised. - Drop unnessary BUG_ON() in construct_domain(). - Add TODO comment above *_load() functions. --- --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/domain-build.c | 50 +++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+) create mode 100644 xen/arch/riscv/domain-build.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 4fcdcf9e24de..2d24670dfc74 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -1,6 +1,7 @@ obj-y += aplic.o obj-y += cpufeature.o obj-y += domain.o +obj-y += domain-build.init.o obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o obj-y += entry.o diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c new file mode 100644 index 000000000000..5f6f4b6248a5 --- /dev/null +++ b/xen/arch/riscv/domain-build.c @@ -0,0 +1,50 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#include +#include +#include +#include + +#include +#include + +int __init construct_domain(struct domain *d, struct kernel_info *kinfo) +{ + struct vcpu *v = d->vcpu[0]; + struct cpu_user_regs *regs = vcpu_guest_cpu_user_regs(v); + + BUG_ON(v->is_initialised); + + /* + * At the moment *_load() don't return value and will just panic() + * inside. + * TODO: it will be good to change that. + */ + kernel_load(kinfo); + initrd_load(kinfo, copy_to_guest_phys); + dtb_load(kinfo, copy_to_guest_phys); + + regs->sepc = kinfo->entry; + + /* Guest boot cpuid = 0 */ + regs->a0 = 0; + regs->a1 = kinfo->dtb_paddr; + + for ( unsigned int i = 1; i < d->max_vcpus; i++ ) + { + const struct vcpu *tmp_v = vcpu_create(d, i); + + if ( !tmp_v ) + { + printk("Failed to allocate %pdv%u\n", d, i); + break; + } + } + + domain_update_node_affinity(d); + + v->is_initialised = true; + clear_bit(_VPF_down, &v->pause_flags); + + return 0; +} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413247.1643463 (Exim 4.92) (envelope-from ) id 1x4JuE-0000PB-CN; Wed, 09 Sep 2026 15:08:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413247.1643463; Wed, 09 Sep 2026 15:08:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JuE-0000P4-9o; Wed, 09 Sep 2026 15:08:10 +0000 Received: by outflank-mailman (input) for mailman id 1413247; Wed, 09 Sep 2026 15:08:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JuC-0000Oy-M7 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JuB-003DEf-DU for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:07 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17646-bab6-0a2a0a5309dd-0a2a4501d2c0-46 for ; Wed, 09 Sep 2026 17:08:06 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17656-5984-0a2a45010019-4a7de48cb2cb-3 for ; Wed, 09 Sep 2026 17:08:06 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254fa663c1so42032566b.0 for ; Wed, 09 Sep 2026 08:08:06 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.07.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966486; x=1789571286; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Hl/WIlAfaBabbdRA8g/iLMTmzy3stlDFgCPr5maALGA=; b=iWOrvnFdTs074OjMcaAFzHqPgSH2gjMWRQoTZZipXiBqGeLJPjhHq8FDzjwgQBmuVN 6bHM3VEschqk4/nR409+8vr8QcTZC2LHmETEsuc1rGbdcpUi6n5PWHAd+FTaiQzqrr0L iFrfmmGIEW+lpXc7sWVEiGQC6ttieoIJDjYRkskX6ewq+hzdJzU0oSAxftkZ0SNJQjOA RzChB7OXLuJdN36DD6isOpWGf+m21X8miYBeSIjMts86nRK8ZXc3L+7tvOElLL0wEbDP 9w0qbj++FY722VTKY+RjFX+ntvXvGjTvFFEL9i7UA06pRj5EuEUii1lJMNsXPZnJoI+k FlBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966486; x=1789571286; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Hl/WIlAfaBabbdRA8g/iLMTmzy3stlDFgCPr5maALGA=; b=X7pAGLLMsYcZsJ9hDf4yA3lKuDzaiuFT1jKRMIhFOZdtger0/505BYoP8DSvc/IGNd 1dsAC1IIqfaTS97dRw758peC0lCMyWiJgGaDnLMPQW0p8rL63M3sfC4rJS8MfF9CzaS2 5Y4wwRTbzaTSguJQWJ1vJgJfi4bc4P4mtp0ttZFsRkb1V9ZPKyYrjOEMxJhUI9BktnEo AHiPlpapaCGoKMvCO49mblIb8LivIFmpKb4SaklRSQrzVKj1qwZ8O+l/oY7RZ8fNhgNL eSGY9kfXry7LfIKZtgHelog7ZOdgJo6mHQ33O94HaDFQe/sCO/xYK0rlLsSJhBQdwxc4 RYxw== X-Gm-Message-State: AFuF++kiPGycd5VbL41V4fLUxoabAZigF1tGMZXhw0P3umHUJy/ubKY9 F212jnYPMj19oYoj+RMI7MsGFlu/FwyDoLMNG7NW0uSowz4p4a7VeT9tWb4Q8b3m X-Gm-Gg: AYBFou18GkGVMaWbaUpk3uRrVhy613rlm2RqR2Jvq0BNjU+lvQbCqDTfXmXVptAPnT3 PA/OYap5yt04ShCa0dfHTFIiJ18RnyjYFd58FYpIM8QnyY5BMpld1r+jUgJ+6Ngylb7LOWONbun XGsBFmPNpsbLVkChtf9HjJvUOjAbhDl5Ot74F5OOh0KR1/dNIPjqALW2lyiR1FCQxHKEWXn7dtl K8E9jUWbC21YallbrK9c8cwzkbbJutGFYkSTeJNEsAsnAPImp18YvZ2vYXo4ZmQvdHLHOU3PkEy ru+481LSG/We0DuTIc4XLNa63gGatIq8ZJLq87KT2k9OCQCuvWKQaf1i2MCYADCKaZZ0UnVb7dT suxoiYiSqSxAhfvdTojH9Zkw9AIYEs47bc0tWo8zq4I8mVFICqSCqLqdobTj8cJU7yypJcC9oSB okXQnYsk5wTq6fPeEmREAGXTxRymdsqf5moXo/JzSQJAoBhwOTPKAb1VlvQJDkl6r5YEo57GnIg ljdcTZlLeXC6cd1fDg= X-Received: by 2002:a17:907:934b:b0:c25:c67d:53cc with SMTP id a640c23a62f3a-c29419fc8f3mr123950566b.8.1788966486130; Wed, 09 Sep 2026 08:08:06 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Timothy Pearson , Alistair Francis , Connor Davis , "Daniel P. Smith" Subject: [PATCH v9 00/20] Introduce enablemenant of dom0less Date: Wed, 9 Sep 2026 17:07:18 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788966486-BE664757-6894119A/10/73395122804 X-purgate-type: spam X-purgate-size: 6614 This patch series reprensent a bunch of patches necessary to enable common part of Dom0less. The stuff necessary to start/launch domains will be introduced separately. CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2829940455 --- Changes in v9: - Address the comments. --- Changes in v8: - Address the comments. - Rename some variable in [PATCH v8 11/20] xen/riscv: introduce per-vCPU IMSIC state. - Drop vaplic_init() and vcpu_aplic_deinit() in [PATCH v8 12/20] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure. --- Changes in v7: - Merged to upstream/staging: - xen/riscv: Implement ARCH_PAGING_MEMPOOL - xen: arm: update p2m_set_allocation() prototype - xen/riscv: do a 4th linking pass if necessary - Address the comments from ML. --- Changes in v6: - Merged to upstream/staging: - xen: arm: move declaration of map_device_irqs_to_domain() to common header - xen/Kconfig: introduce HAS_STATIC_MEMORY - xen/riscv: rename enum intc_version to intc_variant - xen/riscv: implement prerequisites for domain_create() - Move UBSAN fix ("xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page") to this patch series as it is connected to "xen/Kconfig: introduce HAS_STATIC_MEMORY". - Address the comments from ML. --- Changes in v5: - Add new patch (xen/riscv: do a 4th linking pass if necessary) which fixes randconfig job issue. - Address comments from ML. --- Changes in v4: - Address comments from ML. --- Changes in v3: - Drop dependency from other patch series ([1] https://lore.kernel.org/xen-devel/cover.1778140240.git.oleksii.kurochko@gmail.com/T/#t) as it was merged. - Reorder patches: - move common patches to the start. - Move some patches to separate patch series (will be introduced later) - Address comments from ML. --- Changes in v2: - Move patch "[PATCH v1 04/27] xen/riscv: rework G-stage mode handling" to patch series [1] - Address the comments from ML. - The following patches were folded into one: # xen/riscv: implement init_intc_phandle() # xen/riscv: call do_initcalls() in start_xen() # xen/riscv: setup system domains - The following patch were folded into one: # xen/riscv: add vaplic access check # xen/riscv: emulate guest writes to virtual APLIC MMIO # xen/riscv: emulate guest reads from virtual APLIC MMIO - Add new bug fix, not really necessary to this patch series: xen/riscv: manage IRQ_DISABLED flag in APLIC irq enable/disable callbacks --- Oleksii Kurochko (20): xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page xen/dom0less: turn max_init_domid into a common variable xen/riscv: Implement construct_domain() xen/riscv: introduce guest riscv,isa string xen/riscv: implement make_cpus_node() xen/riscv: implement make_timer_node() xen/riscv: implement make_arch_nodes() xen/riscv: introduce init interrupt controller operations xen/riscv: implement make_intc_domU_node() xen/riscv: introduce aia_init() and aia_usable() xen/riscv: introduce per-vCPU IMSIC state xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure xen/riscv: introduce (de)initialization helpers for vINTC xen/riscv: generate IMSIC DT node for guest domains xen/riscv: create APLIC DT node for guest domains xen/riscv: implement IRQ routing for device passthrough xen/riscv: implement init_intc_phandle() xen/riscv: initialize RCU, scheduler, and system domains in start_xen() xen/riscv: provide init_vuart() xen/riscv: add initial dom0less infrastructure support xen/arch/arm/Kconfig | 1 + xen/arch/arm/include/asm/setup.h | 2 - xen/arch/arm/irq.c | 2 +- xen/arch/arm/setup.c | 2 - xen/arch/ppc/include/asm/setup.h | 2 - xen/arch/riscv/Kconfig | 2 + xen/arch/riscv/Makefile | 4 + xen/arch/riscv/aia.c | 23 ++ xen/arch/riscv/aplic-priv.h | 13 ++ xen/arch/riscv/aplic.c | 41 +++- xen/arch/riscv/cpufeature.c | 200 +++++++++++++++-- xen/arch/riscv/device.c | 100 +++++++++ xen/arch/riscv/dom0less-build.c | 40 ++++ xen/arch/riscv/domain-build.c | 192 ++++++++++++++++ xen/arch/riscv/domain.c | 20 +- xen/arch/riscv/imsic.c | 178 ++++++++++++++- xen/arch/riscv/include/asm/aia.h | 10 + xen/arch/riscv/include/asm/aplic.h | 15 ++ xen/arch/riscv/include/asm/cpufeature.h | 5 + xen/arch/riscv/include/asm/domain.h | 7 + xen/arch/riscv/include/asm/guest-layout.h | 24 ++ xen/arch/riscv/include/asm/imsic.h | 25 +++ xen/arch/riscv/include/asm/intc.h | 44 +++- xen/arch/riscv/include/asm/irq.h | 5 + xen/arch/riscv/include/asm/setup.h | 2 - xen/arch/riscv/include/asm/vaplic.h | 34 +++ xen/arch/riscv/intc.c | 117 +++++++++- xen/arch/riscv/irq.c | 261 ++++++++++++++++++++++ xen/arch/riscv/setup.c | 12 + xen/arch/riscv/vaplic.c | 138 ++++++++++++ xen/arch/x86/Kconfig | 1 + xen/arch/x86/include/asm/setup.h | 2 - xen/common/Kconfig | 3 + xen/common/Makefile | 2 +- xen/common/domain.c | 6 +- xen/common/domctl.c | 4 + xen/common/domid.c | 5 + xen/common/event_channel.c | 55 ++++- xen/common/event_channel.h | 6 + xen/common/event_fifo.c | 18 +- xen/common/time.c | 2 + xen/drivers/char/console.c | 2 +- xen/include/xen/dom0less-build.h | 8 + xen/include/xen/event.h | 2 +- xen/include/xen/sched.h | 2 + xen/include/xen/shared.h | 6 + xen/include/xen/time.h | 5 + 47 files changed, 1587 insertions(+), 63 deletions(-) create mode 100644 xen/arch/riscv/aia.c create mode 100644 xen/arch/riscv/device.c create mode 100644 xen/arch/riscv/domain-build.c create mode 100644 xen/arch/riscv/include/asm/aia.h create mode 100644 xen/arch/riscv/include/asm/vaplic.h create mode 100644 xen/arch/riscv/vaplic.c -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413248.1643473 (Exim 4.92) (envelope-from ) id 1x4JuF-0000be-Ix; Wed, 09 Sep 2026 15:08:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413248.1643473; Wed, 09 Sep 2026 15:08:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JuF-0000bX-G8; Wed, 09 Sep 2026 15:08:11 +0000 Received: by outflank-mailman (input) for mailman id 1413248; Wed, 09 Sep 2026 15:08:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JuE-0000PH-J4 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JuD-00Cu0U-W9 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:10 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17659-e002-0a2a0a5209dd-0a2a4507ddba-2 for ; Wed, 09 Sep 2026 17:08:09 +0200 Received: from [209.85.218.43] (helo=mail-ej1-f43.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17659-b4ea-0a2a45070019-d155da2bd548-3 for ; Wed, 09 Sep 2026 17:08:09 +0200 Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-c2938116fefso119839866b.1 for ; Wed, 09 Sep 2026 08:08:09 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966489; x=1789571289; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=lvvILD6LxqUZ5OrEiQyNFYfNqt1pXsQ3qXxqOC13MNM=; b=GDEnIhRzPILyaE228ezRTwzYTj3B9B3m6uXaFyEfqhvForn1hA7mhmaSm8uVzqEsNd 4EA5dJB18Su9P0X2pPD4Nw7WJB/rX8+IZ0TEA048U6HPE1PDKb7tqwz6uOvr9igU24YE lWM1yK38Fl6jdEtTH95k0s/3kvFzeJ1gOaouEgdIe8MVLqraGsv1+n++j4vn9AnMv76j UrRZLGvcHmoajNXfOi6ig90RrjKUDCEODgGAN5wr3P8ySodqRGq9d6/elDqIAGCoiKew PYTSn9cewm0sVczPK5p9/Yq+/AXLCdqli60wUbPeiuPdNRD9U+mJiU4qtMjHSgZICNCV rG/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966489; x=1789571289; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=lvvILD6LxqUZ5OrEiQyNFYfNqt1pXsQ3qXxqOC13MNM=; b=S/4wvBIVYbzsct/XP/ny9F2CplYRmg6Sx62dmFnz8Um4egTc0FCB1iVCOVw5neyZRn NXprSr/IhgZQsKoq3QoGGZw3Z2vlGbDjLCGrWV1InGZjbI/wwMANtjnhlAC4u3MyCjOs WnB6CaKP3q+Ebdu1lU9igaIcsF2gTVvbMiQI9EhMacA14Q7yGSHKwj/+c5QpElGKGnSM +12fTy1qXO+23KCQy+D/lFmzwOx58t/t7j+5labu5S6jW75MLNXUl/wjYT9DJdEYb4Tr GxG2TDwkGur3oYa2TleDzbFjHKhNbtiLwxZiCaRyZJpa7caO+UXhg/7lXKbY1Y83rbi0 38ow== X-Gm-Message-State: AFuF++l4deIk2x+OqZETq2KvlLvlDMNKn52wqk3Utin+ZHmlXep1IrxJ MiTjawqS+pQ7Vn2gz5jXUnoMO2HNyLOVjyHov0zGrCxTowzezVnZmuB7+qKxcl3v X-Gm-Gg: AYBFou30mG19p4jRvMwr+2m83iYI0PAbAcVgPJxZ9aasKAbSkpA9JGYeHvD1EL/HtfW ac656KnJXAbTIr8BhI3c3Vgu6Tk5aN29d9E0fWFHWTMIWxtZCR/wxXypuol47GikYcoWwdFXG0s +5hH6Lg1/noSLOoxrWtQwhKuvfcR2onVzTkqTxb4DrzWHO1P3V9II0c8zECre674vn/mwuIyCFu TSp724wqbAzClud7pj61/DqbZoydJwW4xnuleaTmAvr0guVAjK/sVxTEArJodhq3dq/nroFNbEC STugyJvvWEO7jyXAuqF+xorYayjOMLKTQD0v1BxanWtxxksjfSyfXRuNUayG1WzaPt4979/jGqI geAVl+linJfGzoNtGq1PcXZWkHC7ZEwKTd2Wv48JbF7wcQaBzO3yw37ARtUOCqHDgflvWrRjSq7 4AzhBH2tRIFTI22HaPxWzEievYGVzEE72b37RC0t7qaN4QI7apXFF9vslzYSQB0hzVBtCQXasOu Od6bZfiS/65PqJLECo= X-Received: by 2002:a17:907:94cc:b0:c26:19de:9ac5 with SMTP id a640c23a62f3a-c2619dea621mr1326204666b.29.1788966488902; Wed, 09 Sep 2026 08:08:08 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v9 01/20] xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page Date: Wed, 9 Sep 2026 17:07:19 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788966489-34ECEAE4-E410B852/10/73395122804 X-purgate-type: spam X-purgate-size: 19187 On architectures that run guests in dom0less mode without the PV ABI (currently RISC-V), no shared_info page is allocated and d->shared_info remains NULL throughout the domain lifetime. Several places in common code access d->shared_info through the shared_info() macro or directly, causing UBSAN null-pointer errors on such architectures. Rather than adding runtime NULL guards that are logically unreachable on x86 and Arm (where shared_info is always allocated), introduce a new Kconfig symbol CONFIG_HAS_SHARED_INFO selected by x86 and Arm. On !HAS_SHARED_INFO the shared_info() macro expands to a dereference of shared_info_absent, an extern pointer that is declared but intentionally never defined. Any use of shared_info() that is not dead-code-eliminated will therefore cause a link-time failure, making missed guards impossible to overlook. The 2L event-channel ops call shared_info() and must not be compiled on architectures without a shared_info page, so event_2l.o is gated on CONFIG_HAS_SHARED_INFO. On such architectures evtchn_init() installs the FIFO ops as a placeholder instead, so that a later guest opt-in to the FIFO ABI via EVTCHNOP_init_control has no special-casing to do; if FIFO support itself is also unavailable (!CONFIG_EVTCHN_FIFO), a dedicated no-op evtchn_port_ops_none table is installed instead, so that d->evtchn_port_ops is never NULL. evtchn_fifo_word_from_port() is guarded against uninitialised d->evtchn_fifo so the FIFO ops are safe before evtchn_fifo_init_control() is called by the guest. With CONFIG_HAS_SHARED_INFO=n all vCPUs fall back to the global dummy_vcpu_info, so writes through vcpu_info() could leak data between vCPUs. Reviewing the write paths in common code: the write in map_guest_area() stores the constant ~0 so nothing serious would happen if it were leaked; the event_2l.c paths are not compiled on !HAS_SHARED_INFO, as event_2l.o is gated on CONFIG_HAS_SHARED_INFO; the write in vcpu_info_populate() targets the new mapping buffer, not dummy_vcpu_info. Outside common code, the remaining writes are x86 PV-specific, for which CONFIG_HAS_SHARED_INFO=y. No code changes are needed. Finally, struct domain's shared_info field itself is gated on CONFIG_HAS_SHARED_INFO, as it would otherwise be a permanently NULL pointer: every user of it is either arch code for an architecture that selects HAS_SHARED_INFO, or common code already guarded by the same Kconfig symbol. Signed-off-by: Oleksii Kurochko Reviewed-by: Jan Beulich --- Changes in v9: - Nothing done. Only rebase. --- Changes in v8: - Introduce evtchn_preinit(). - Update some comments in the code. - Add Reviewed-by: Jan Beulich . --- Changes in v7: - domctl.c: use a plain #ifdef CONFIG_HAS_SHARED_INFO / #else instead of the IS_ENABLED() if/else in getdomaininfo(), and set info->shared_info_frame to ~0 in the !HAS_SHARED_INFO case. - sched.h: drop struct domain's shared_info field when !HAS_SHARED_INFO, rather than keeping a field that can only ever be NULL there. All of its users are either in arch code selecting HAS_SHARED_INFO or already guarded by CONFIG_HAS_SHARED_INFO, so no further changes are needed. Update the commit message accordingly. --- Changes in v6: - s/INVALID_GFN_RAW/gfn_x(INVALID_GFN) as INVALID_GFN_RAW was dropped. - event_channel.c: make evtchn_none_init() static, moving the evtchn_port_ops_none table and its definition above evtchn_reset(), their first caller; move the leftover prototype into the #else arm of the same #ifndef guard instead of leaving it as a free-standing non-static declaration. - event_channel.c: evtchn_reset() now follows the same IS_ENABLED(CONFIG_HAS_SHARED_INFO) / IS_ENABLED(CONFIG_EVTCHN_FIFO) / else cascade already used by evtchn_init(), rather than assuming the FIFO ABI is unconditionally available whenever d->evtchn_fifo was set. - event_channel.c: narrow the evtchn_port_ops_none / evtchn_none_init guard from !CONFIG_HAS_SHARED_INFO to !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO, so the placeholder cf_check functions are only built for the one combination that actually needs them. - event_channel.c: fix the evtchn_port_ops_none comment, which claimed the ops were never reachable in practice; they are reached whenever an event is delivered to (or queried on) a !HAS_SHARED_INFO && !EVTCHN_FIFO domain, they just have no ABI to record it in and discard it. - event_channel.h / event_fifo.c: drop the static inline evtchn_fifo_init_ops() stub for !CONFIG_EVTCHN_FIFO; a plain declaration outside the #ifdef/#else is enough, matching the treatment already given to evtchn_2l_init() and evtchn_none_init(). Update the "only call site" comment in event_fifo.c to mention both evtchn_init() and evtchn_reset(). --- Changes in v5: - drop the static inline evtchn_2l_init() stub for !HAS_SHARED_INFO; a plain declaration is enough since the only call sites are guarded by IS_ENABLED(CONFIG_HAS_SHARED_INFO) and the dead call is eliminated before linking. - fix a NULL d->evtchn_port_ops dereference when CONFIG_HAS_SHARED_INFO=n and CONFIG_EVTCHN_FIFO=n: evtchn_init() was unconditionally calling evtchn_fifo_init_ops(), whose !EVTCHN_FIFO stub leaves d->evtchn_port_ops unset. Gate the FIFO branch on IS_ENABLED(CONFIG_EVTCHN_FIFO) and add a dedicated evtchn_port_ops_none table for the remaining case. Stubs are shared where signatures permit: evtchn_none_noop covers both clear_pending and unmask; evtchn_none_false covers both is_pending and is_masked. evtchn_none_init() is called only from event_channel.c, so its declaration is kept there rather than in event_channel.h. - gate evtchn_fifo_init_ops() on !CONFIG_HAS_SHARED_INFO; its only call site is in the IS_ENABLED(CONFIG_EVTCHN_FIFO) dead branch of evtchn_init(), which is never reached on HAS_SHARED_INFO=y builds. --- Changes in v4: - event_channel.c: drop the redundant evtchn_fifo_init_ops() in the else branch of evtchn_reset(); evtchn_fifo_destroy() does not undo the ops installed by evtchn_init(), so only the switch back to 2-level ABI needs an explicit call. - shared.h: simplify the !HAS_SHARED_INFO shared_info() definition to use an undefined "extern struct shared_info *shared_info_absent" instead of shared_info_absent() with a typeof cast. - Extend the commit description to note that vcpu_info()/__vcpu_info() uses were also audited: on !HAS_SHARED_INFO vcpu_info_area.map points at dummy_vcpu_info, reads are harmless, and writes in common code do not open a cross-domain info-leak side channel, so no code changes are needed on that path. --- Changes in v3: - Introduce CONFIG_HAS_SHARED_INFO Kconfig symbol selected by x86 and Arm; RISC-V does not select it. - Gate shared_info() macro on CONFIG_HAS_SHARED_INFO; on !HAS_SHARED_INFO it calls shared_info_absent() (declared, never defined) so any unguarded use produces a link-time error. - Replace runtime if (!d->shared_info) guards with IS_ENABLED() at call sites so both branches type-check and dead code is eliminated. - Guard shared_info_frame assignment in domctl.c. - Gate event_2l.o on CONFIG_HAS_SHARED_INFO; use FIFO ops as placeholder on !HAS_SHARED_INFO archs instead of dedicated stub ops; guard evtchn_fifo_word_from_port() against uninitialised d->evtchn_fifo. - Add static inline stubs for evtchn_2l_init() (!HAS_SHARED_INFO) and evtchn_fifo_init_ops() (!EVTCHN_FIFO) so call sites can use IS_ENABLED() without #ifdef. - Drop inaccurate changelog entry about "only FIFO ABI" migration. - Update the commit message. - Drop R-by: Baptiste ... as some extra checks are added. --- Changes in v2: - Update commit message + subject. - Drop Fixes tag. --- xen/arch/arm/Kconfig | 1 + xen/arch/x86/Kconfig | 1 + xen/common/Kconfig | 3 +++ xen/common/Makefile | 2 +- xen/common/domain.c | 6 ++--- xen/common/domctl.c | 4 +++ xen/common/event_channel.c | 55 +++++++++++++++++++++++++++++++++++--- xen/common/event_channel.h | 6 +++++ xen/common/event_fifo.c | 18 ++++++++++++- xen/common/time.c | 2 ++ xen/include/xen/event.h | 2 +- xen/include/xen/sched.h | 2 ++ xen/include/xen/shared.h | 6 +++++ xen/include/xen/time.h | 5 ++++ 14 files changed, 104 insertions(+), 9 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 843a43897e7b..d748404e82da 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -20,6 +20,7 @@ config ARM select HAS_DEVICE_TREE_DISCOVERY select HAS_DOM0LESS select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE + select HAS_SHARED_INFO select HAS_STACK_PROTECTOR select HAS_STATIC_MEMORY select HAS_UBSAN diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 3ce0774b8d76..e5535ac48467 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -29,6 +29,7 @@ config X86 select HAS_PCI_MSI select HAS_PIRQ select HAS_SCHED_GRANULARITY + select HAS_SHARED_INFO imply HAS_SOFT_RESET select HAS_UBSAN select HAS_VMAP diff --git a/xen/common/Kconfig b/xen/common/Kconfig index da80fdba8469..5b289e444fa5 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -158,6 +158,9 @@ config HAS_PMAP config HAS_SCHED_GRANULARITY bool +config HAS_SHARED_INFO + bool + config HAS_STATIC_MEMORY bool diff --git a/xen/common/Makefile b/xen/common/Makefile index 6018e256147f..f69d47d18934 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -12,7 +12,7 @@ obj-$(CONFIG_DEVICE_TREE_PARSE) += device-tree/ obj-$(CONFIG_IOREQ_SERVER) += dm.o obj-y += domain.o obj-y += domid.o -obj-y += event_2l.o +obj-$(CONFIG_HAS_SHARED_INFO) += event_2l.o obj-y += event_channel.o obj-$(CONFIG_EVTCHN_FIFO) += event_fifo.o obj-$(CONFIG_GRANT_TABLE) += grant_table.o diff --git a/xen/common/domain.c b/xen/common/domain.c index e16f1ac38396..6b52713518da 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -316,9 +316,9 @@ void vcpu_info_reset(struct vcpu *v) struct domain *d = v->domain; v->vcpu_info_area.map = - ((v->vcpu_id < XEN_LEGACY_MAX_VCPUS) - ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id]) - : &dummy_vcpu_info); + IS_ENABLED(CONFIG_HAS_SHARED_INFO) && v->vcpu_id < XEN_LEGACY_MAX_VCPUS + ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id]) + : &dummy_vcpu_info; } static struct domain *alloc_domain_struct(void) diff --git a/xen/common/domctl.c b/xen/common/domctl.c index a6210db4fb97..83405a766a54 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -102,9 +102,13 @@ void getdomaininfo(struct domain *d, struct xen_domctl_getdomaininfo *info) #ifdef CONFIG_MEM_PAGING info->paged_pages = atomic_read(&d->paged_pages); #endif +#ifdef CONFIG_HAS_SHARED_INFO info->shared_info_frame = gfn_x(mfn_to_gfn(d, _mfn(virt_to_mfn(d->shared_info)))); BUG_ON(SHARED_M2P(info->shared_info_frame)); +#else + info->shared_info_frame = ~0; +#endif info->cpupool = cpupool_get_id(d); diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index a7f9cc5fe0ac..bd03e094d096 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -40,6 +40,54 @@ #define consumer_is_xen(e) (!!(e)->xen_consumer) +#if !defined(CONFIG_HAS_SHARED_INFO) && !defined(CONFIG_EVTCHN_FIFO) +/* + * Placeholder ops for domains with neither a shared_info page nor a FIFO + * control block. Such a domain has no ABI to record event state in, so these + * are reachable whenever an event is delivered to (or queried on) one of its + * ports; they just discard/no-op it. They exist to keep d->evtchn_port_ops + * non-NULL. + */ +static void cf_check evtchn_none_set_pending( + struct vcpu *v, struct evtchn *evtchn) {} +static void cf_check evtchn_none_noop( + struct domain *d, struct evtchn *evtchn) {} +static bool cf_check evtchn_none_false( + const struct domain *d, const struct evtchn *evtchn) { return false; } +static void cf_check evtchn_none_print_state( + struct domain *d, const struct evtchn *evtchn) {} + +static const struct evtchn_port_ops evtchn_port_ops_none = { + .set_pending = evtchn_none_set_pending, + .clear_pending = evtchn_none_noop, + .unmask = evtchn_none_noop, + .is_pending = evtchn_none_false, + .is_masked = evtchn_none_false, + .print_state = evtchn_none_print_state, +}; + +static void evtchn_none_init(struct domain *d) +{ + d->evtchn_port_ops = &evtchn_port_ops_none; +} +#else /* CONFIG_HAS_SHARED_INFO || CONFIG_EVTCHN_FIFO */ +/* + * Declaration only; the call in evtchn_preinit() is DCE'd unless both + * configs are off. + */ +void evtchn_none_init(struct domain *d); +#endif /* !CONFIG_HAS_SHARED_INFO && !CONFIG_EVTCHN_FIFO */ + +static void evtchn_preinit(struct domain *d) +{ + if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) ) + evtchn_2l_init(d); + else if ( IS_ENABLED(CONFIG_EVTCHN_FIFO) ) + evtchn_fifo_init_ops(d); + else + evtchn_none_init(d); +} + /* * Lock an event channel exclusively. This is allowed only when the channel is * free or unbound either when taking or when releasing the lock, as any @@ -1324,9 +1372,9 @@ int evtchn_reset(struct domain *d, bool resuming) rc = -EAGAIN; else if ( d->evtchn_fifo ) { - /* Switching back to 2-level ABI. */ + /* Switching back to the default ABI. */ evtchn_fifo_destroy(d); - evtchn_2l_init(d); + evtchn_preinit(d); } write_unlock(&d->event_lock); @@ -1625,7 +1673,8 @@ void evtchn_check_pollers(struct domain *d, unsigned int port) int evtchn_init(struct domain *d, unsigned int max_port) { - evtchn_2l_init(d); + evtchn_preinit(d); + d->max_evtchn_port = min_t(unsigned int, max_port, INT_MAX); d->evtchn = alloc_evtchn_bucket(d, 0); diff --git a/xen/common/event_channel.h b/xen/common/event_channel.h index dc94a43cc2dd..423c4ee77bd0 100644 --- a/xen/common/event_channel.h +++ b/xen/common/event_channel.h @@ -70,6 +70,12 @@ static inline void evtchn_fifo_destroy(struct domain *d) } #endif /* CONFIG_EVTCHN_FIFO */ +/* + * Declaration only when !CONFIG_EVTCHN_FIFO; the call in evtchn_preinit() is + * DCE'd in that case. + */ +void evtchn_fifo_init_ops(struct domain *d); + #endif /* EVENT_CHANNEL_H */ /* diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c index 611bf8a78801..e4225b1b668e 100644 --- a/xen/common/event_fifo.c +++ b/xen/common/event_fifo.c @@ -62,6 +62,9 @@ static inline event_word_t *evtchn_fifo_word_from_port(const struct domain *d, */ smp_rmb(); + if ( unlikely(!d->evtchn_fifo) ) + return NULL; + if ( unlikely(port >= d->evtchn_fifo->num_evtchns) ) return NULL; @@ -419,6 +422,18 @@ static const struct evtchn_port_ops evtchn_port_ops_fifo = .print_state = evtchn_fifo_print_state, }; +/* + * evtchn_fifo_init_ops()'s only call site is the + * IS_ENABLED(CONFIG_EVTCHN_FIFO) branch of evtchn_preinit(), which is never + * reached on HAS_SHARED_INFO=y builds because of DCE. + */ +#ifndef CONFIG_HAS_SHARED_INFO +void evtchn_fifo_init_ops(struct domain *d) +{ + d->evtchn_port_ops = &evtchn_port_ops_fifo; +} +#endif + static int map_guest_page(struct domain *d, uint64_t gfn, void **virt) { struct page_info *p; @@ -561,7 +576,8 @@ static void setup_ports(struct domain *d, unsigned int prev_evtchns) evtchn = evtchn_from_port(d, port); - if ( guest_test_bit(d, port, &shared_info(d, evtchn_pending)) ) + if ( IS_ENABLED(CONFIG_HAS_SHARED_INFO) && + guest_test_bit(d, port, &shared_info(d, evtchn_pending)) ) evtchn->pending = true; evtchn_fifo_set_priority(d, evtchn, EVTCHN_FIFO_PRIORITY_DEFAULT); diff --git a/xen/common/time.c b/xen/common/time.c index 0ddf65448d22..58d2b54a291b 100644 --- a/xen/common/time.c +++ b/xen/common/time.c @@ -98,6 +98,7 @@ struct tm gmtime(unsigned long t) return tbuf; } +#ifdef CONFIG_HAS_SHARED_INFO void update_domain_wallclock_time(struct domain *d) { uint32_t *wc_version; @@ -126,6 +127,7 @@ void update_domain_wallclock_time(struct domain *d) spin_unlock(&wc_lock); } +#endif /* CONFIG_HAS_SHARED_INFO */ /* Set clock to after 00:00:00 UTC, 1 January, 1970. */ void do_settime(u64 secs, unsigned int nsecs, u64 system_time_base) diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h index 930190054cf0..595dedf0792c 100644 --- a/xen/include/xen/event.h +++ b/xen/include/xen/event.h @@ -211,7 +211,7 @@ static bool evtchn_usable(const struct evtchn *evtchn) void evtchn_check_pollers(struct domain *d, unsigned int port); -/* Close all event channels and reset to 2-level ABI. */ +/* Close all event channels and reset to the default ABI. */ int evtchn_reset(struct domain *d, bool resuming); /* diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index e352e2b38e7d..73c54794ac02 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -404,7 +404,9 @@ struct domain struct vcpu **vcpu; +#ifdef CONFIG_HAS_SHARED_INFO shared_info_t *shared_info; /* shared data area */ +#endif rcu_read_lock_t rcu_lock; diff --git a/xen/include/xen/shared.h b/xen/include/xen/shared.h index 5b71342cab32..1589e8793f9d 100644 --- a/xen/include/xen/shared.h +++ b/xen/include/xen/shared.h @@ -43,7 +43,13 @@ typedef struct vcpu_info vcpu_info_t; extern vcpu_info_t dummy_vcpu_info; +#ifdef CONFIG_HAS_SHARED_INFO #define shared_info(d, field) __shared_info(d, (d)->shared_info, field) +#else +extern struct shared_info *shared_info_absent; +#define shared_info(d, field) (((void)(d), shared_info_absent)->field) +#endif /* CONFIG_HAS_SHARED_INFO */ + #define vcpu_info(v, field) \ __vcpu_info(v, (vcpu_info_t *)(v)->vcpu_info_area.map, field) diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h index 4db24617a97c..09da150c2a40 100644 --- a/xen/include/xen/time.h +++ b/xen/include/xen/time.h @@ -72,7 +72,12 @@ extern bool NOW_good; #define version_update_begin(v) (((v) + 1) | 1) #define version_update_end(v) ((v) + 1) extern void update_vcpu_system_time(struct vcpu *v); + +#ifdef CONFIG_HAS_SHARED_INFO extern void update_domain_wallclock_time(struct domain *d); +#else +static inline void update_domain_wallclock_time(struct domain *d) {} +#endif extern void do_settime( u64 secs, unsigned int nsecs, u64 system_time_base); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413251.1643500 (Exim 4.92) (envelope-from ) id 1x4JuM-0001Ja-D0; Wed, 09 Sep 2026 15:08:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413251.1643500; Wed, 09 Sep 2026 15:08:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JuM-0001JP-8n; Wed, 09 Sep 2026 15:08:18 +0000 Received: by outflank-mailman (input) for mailman id 1413251; Wed, 09 Sep 2026 15:08:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JuK-0001BI-QC for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JuK-003DHh-74 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:16 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17660-bab6-0a2a0a5309dd-0a2a450ad5b2-0 for ; Wed, 09 Sep 2026 17:08:16 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17660-f2d2-0a2a450a0019-4a7de48ca3e2-3 for ; Wed, 09 Sep 2026 17:08:16 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f9f0b20so195221966b.3 for ; Wed, 09 Sep 2026 08:08:16 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966495; x=1789571295; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=x4D/wRNO94pIhJ33n24GH3v08GesvRDLwYVJ73G/CmU=; b=TkJP8OLdsj1GdtulPzNPR2znLqbHJOpPwCF4aJyp84JZAv0LKq8V59kkoWyvb/pydU howajn9kXjrbWnTPBJdPFT4dYDcreV5qWCx08dYIR/IrloNvMib7eXSeiqd51aQ/MCXE k6jSFJJ7ZpGlgSdXB2Ds1r3UDBKKgXuSotM1OEaHEtiiiiY02GD4/XjUbvktMXzzQO0X cWC4qpzMgBlyiVV62rhE2l/ZCidHjtqadxYK+sJqj65B04UMhbO9adTvE3SHKxKOnwC8 jTkhMwB8Gk0R1Mo2p034782Uoz70SIhBDNdUwXbCw950QE59lpmmnKqLWHRYxM4YXBRv OziQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966495; x=1789571295; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=x4D/wRNO94pIhJ33n24GH3v08GesvRDLwYVJ73G/CmU=; b=ine+KzdRFMa6bMJ6T17T6omgrnSV62AdNYN87e/n4u0XPokaLFm5z63KZODmbyeN3Q b1FatTnLy/N0TfesdyvORgXfW0XxSmbNRujZF2DlQCyIzevEh7nmaDWZSi7mszkZR6jA kjpJ2bSvp4gp4lqmPz0QPwcpAg86TNBhEXU8Rj8LqHvVK2CjRMhH/ALI0PFpYu8BO89B z6zcQJMe6fnS5H4Y3d5CzO61nuhNsZizpC6fmg98RCb/UGOHV4wFVH+GBsAIKvd9gcBP gtUoWaZ+GHz+GFp86mN+jinQfO9jFM2Y6a70Adtzdrk7k5Nc5/EtKNLTDzHNLwFx498W lWfw== X-Gm-Message-State: AFuF++l9fAer2RUjAiv/MKal/TC5pn6FvbQz8HOyD4zAO3Lwn4OxfzRL CXTJNUV/1HliMj1cpzQ8ScoMTfJhRCPAn/unqGSkg8tsqVmpUv5uh2an2r4aeLQv X-Gm-Gg: AYBFou36kd6NuKY8iv/7w0LODcJfW0dvWqbLmglshO5z4BnU8picy/V+64n1ZWMDbvu 3PQlyJtXektW4z87xM0UvKi34H3Dnt9d4zRwZtK1WVYTwyJV4x6NHXVLTaH1ZY3D/M4TtvpFc/E S+JskkPwdbssaxu9o31/AR8eN5TULkgErqlnHeTWTUtIm0KLlaTj4BLrdnUuQfqisoCmapmnavl ZD6UC8zOnyzWzs5xNZ+IwKWjQjM0ATEM0h7Bouins3I93PtGuwh0RXF07kp1rGDC1Upw0DI2r6V uUl05JZWvjFyU1lzPSLPDZbTi5m0XHtw2BxLDoXAEITmQKyhwMry1YmFgg1UeU3kjrN6dZVuN40 D/IlnBg9kipJ5Wv436dS4cFY9EylsyL97U/RCOjWlme2mYSJoIOYEE36YZNYWzMSWMCHofNrQ8Y fRTifmJst9BtBG1F9lDjRwPFQWecuwlFxcWkDUMq1n/cUO9KXjj3kTAExxCH7HTVTk7Kc0sX9fb f0MYdXehhxWcX1kSbnM2/XC1Hw37Q== X-Received: by 2002:a17:906:794b:b0:c25:938a:754c with SMTP id a640c23a62f3a-c292b1ac282mr583108366b.20.1788966495468; Wed, 09 Sep 2026 08:08:15 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 04/20] xen/riscv: introduce guest riscv,isa string Date: Wed, 9 Sep 2026 17:07:22 +0200 Message-ID: <6fc9e21cf24775a27ee38ddf62e643a4530a3fe0.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1788966496-524DFCFC-E752E469/10/73395122804 X-purgate-type: spam X-purgate-size: 16877 Introduce build_guest_isa_str() to generate the riscv,isa string to be passed to the guest via the Device Tree riscv,isa property. Introduce the per-domain guest ISA bitmap, populated during domain creation by calling init_guest_isa(). Introduce struct riscv_isa_ext_entry with a new guest_flags field to filter out ISA extensions that should not be exposed to guests: - f/d/q/v: FPU and vector context save/restore are not yet implemented for guests. - Z*inx are not exposed either: they aren't in riscv_isa_ext[], so they can never be set in riscv_isa and thus never reach a guest, and no current hardware/guest-OS advertises or expects them. Supporting them would be cheaper than F/D/Q (FP values stay in integer registers Xen already context-switches), but is left as future work. - h: Nested virtualisation is not supported. - sstc: Xen owns the supervisor timer; guests must use SBI. - svade: Xen manages hardware A/D bit updates in stage-2 page tables. - svpbmt: Page-based memory types are not yet wired up in stage-2 code. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v9: - Add string concatanation for initialization of .guest_flags in RISCV_ISA_EXT_ENTRY(). Also drop RISCV_ISA_EXT_GUEST_ prefix in riscv_isa_ext[] as it is covered by concatanation. - s/guest_flgs/guest. - Add Acked-by: Jan Beulich . --- Changes in v8: - Replace struct riscv_isa_ext_entry's bool guest_supported with an unsigned int guest_flags bitmask (RISCV_ISA_EXT_GUEST_{NONE,RV32,RV64,ANY}), so an extension can be withheld from guests of one XLEN only; select the bit matching the guest's width with RISCV_ISA_EXT_GUEST_XLEN in compute_guest_isa(). Guests are currently of the same width as Xen, so RISCV_ISA_EXT_GUEST_XLEN is derived from CONFIG_RISCV_{32,64} for now. - Add some spaces between # and "error" in build_guest_isa_str(). --- Changes in v7: - build_guest_isa_str(): drop the struct domain argument and work directly on the guest_isa bitmap; make the function static as it has no external users anymore. - build the guest "riscv,isa" string only once, in compute_guest_isa(), and store it in an __ro_after_init pointer, instead of rebuilding it for every domain: all domains are currently given the same guest ISA, so apply here the same reasoning as for the guest_isa bitmap. - panic() on length calculation, allocation or formatting failure, in line with the rest of riscv_fill_hwcap() initialization. - introduce get_guest_isa_str() accessor and expose it in asm/cpufeature.h instead of build_guest_isa_str(). --- Changes in v6: - build_guest_isa_str() now takes a `const struct domain *d` instead of a raw `const unsigned long *isa_bitmap`, to leave room for using more than just the bitmap in the future. - Compute the guest-visible ISA bitmap once at boot, into a new __ro_after_init `guest_isa` bitmap (compute_guest_isa(), called at the end of riscv_fill_hwcap()), instead of re-deriving it from riscv_isa_ext[] on every domain creation in init_guest_isa(). All guests currently get the same extension set, so this avoids repeating identical work per domain; will need revisiting if/when per-domain ISA policy is introduced. - struct arch_domain's `isa` field is now `const unsigned long *isa` instead of an embedded bitmap; init_guest_isa() just points it at the shared `guest_isa` bitmap rather than copying bits into a per-domain array. - Mark riscv_isa_ext[] __initconstrel, since its entries hold name pointers and the need for relocations requires that the compiler emit the data to a writable section. - Make build_guest_isa_str() __init as it is called during make_cpus_node() which is used only (at least, for now) in build time of domain. --- Changes in v5: - Introduce struct riscv_isa_ext_entry with a guest_supported field and RISCV_ISA_EXT_ENTRY(name, guest_supp) macro for riscv_isa_ext[], replacing the ad-hoc guest_unsupp bitmap and init_guest_unsupp(). Every entry now carries an explicit true/false decision, enforced at compile time. - init_guest_isa() builds d->arch.isa by iterating riscv_isa_ext[] directly instead of using bitmap_andnot() against guest_unsupp. - init_guest_isa() changed to void as it can no longer fail. - Drop isa_str from struct arch_domain; the ISA string does not need to persist over the domain lifetime. build_guest_isa_str() is made non-static and declared in cpufeature.h for use when building the guest device tree. - Updated the fix of underflow in build_guest_isa_str(). - Drop unnecessary empty line in cpufeature.h before enum riscv_isa_ext_id. --- Changes in v4: - Add an explicit overflow guard in build_guest_isa_str(): return -ENOSPC when buf is non-NULL and total >= size, to avoid the size - total underflow being passed to snprintf(). - Expand the commit message to explain why Zfinx/Zdinx/Zqinx are not added to guest_unsupp (not in riscv_isa_ext[], so never set in riscv_isa nor exposed to a guest; left as future work) --- Changes in v3: - s/set_bit/__set_bit in init_guest_unsupp() as atomicity isn't needed at init time. - Drop RISCV_GUEST_ISA_STR_MAX; allocate isa_str dynamically with xvmalloc_array(). - Drop "guest" prefix from d->arch.guest_isa and d->arch.guest_isa_str. - Introduce build_guest_isa_str() using snprintf(NULL, 0, ...) to determine the needed buffer size; init_guest_isa() calls it once for sizing and once to fill, keeping both in a single function so they can't go out of sync. - Scope ret inside the loop; initialize total directly from the prefix snprintf(). - Merge "_" separator and extension name into a single snprintf() with "%s%s". - Replace ASSERT with an explicit error check: if the fill call returns a different length, free isa_str and return -EINVAL. --- Changes in v2: - s/guest_unsupp_bmp/guest_unsupp. - Drop guest_isa_str. - Provide init_guest_isa() instead of polluting match_isa_ext(). - Drop xlen. - Add the comment about guest_unsupp. - Update the way how guest_unsupp is init-ed. - Drop __initconst for riscv_isa_ext[] as it is used in init_guest_isa() which isn't marked as __init as it could be used after init stage. --- --- xen/arch/riscv/cpufeature.c | 200 +++++++++++++++++++++--- xen/arch/riscv/domain.c | 2 + xen/arch/riscv/include/asm/cpufeature.h | 5 + xen/arch/riscv/include/asm/domain.h | 3 + 4 files changed, 186 insertions(+), 24 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 92235fdfd5ab..aaf544d13fea 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -14,7 +14,9 @@ #include #include #include +#include #include +#include #include #include @@ -34,9 +36,64 @@ struct riscv_isa_ext_data { .name = #ext_name, \ } +/* + * Which guests an extension may be handed out to, by guest XLEN. + * + * These flags express Xen's policy, not the ISA's rules: extensions which + * are architecturally tied to one XLEN (Zilsd on RV32, say) need no special + * treatment here, as they can only ever appear in the "riscv,isa" of a host + * of that XLEN, and guest_isa is masked against the host ISA bitmap anyway. + * They are only of use for extensions Xen chooses not to expose to guests of + * a given width despite the hardware implementing them. + */ +#define RISCV_ISA_EXT_GUEST_NONE 0 +#define RISCV_ISA_EXT_GUEST_RV32 (1U << 0) +#define RISCV_ISA_EXT_GUEST_RV64 (1U << 1) +#define RISCV_ISA_EXT_GUEST_ANY (RISCV_ISA_EXT_GUEST_RV32 | \ + RISCV_ISA_EXT_GUEST_RV64) + +/* + * Guests are of the same width as Xen itself for the time being; once guest + * XLEN can differ from host XLEN (hstatus.VSXL), this becomes a per-domain + * property, just as guest_isa below does. + */ +#if defined(CONFIG_RISCV_32) +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV32 +#elif defined(CONFIG_RISCV_64) +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV64 +#else +# error "Unsupported RISC-V bitness" +#endif + +struct riscv_isa_ext_entry { + unsigned int id; + const char *name; + unsigned int guest_flags; +}; + +#define RISCV_ISA_EXT_ENTRY(ext_name, guest) \ +{ \ + .id = RISCV_ISA_EXT_ ## ext_name, \ + .name = #ext_name, \ + .guest_flags = RISCV_ISA_EXT_GUEST_ ## guest, \ +} + /* Host ISA bitmap */ static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX); +/* + * ISA bitmap handed out to every guest. + * + * All guests are given the same extensions for the time being, so this is + * computed once out of riscv_isa_ext[] and riscv_isa, rather than redoing + * the walk for every domain created. Should per-domain ISA policy ever be + * introduced, this will need to become per-domain again. + */ +static __ro_after_init DECLARE_BITMAP(guest_isa, RISCV_ISA_EXT_MAX); + +/* "riscv,isa" string corresponding to guest_isa, shared by all domains. */ +static char *__ro_after_init guest_isa_str; + static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu, unsigned long *dt_cpuid) { @@ -120,29 +177,30 @@ static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu, * and strncmp() is used in match_isa_ext() to compare extension names instead * of strncasecmp(). */ -const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = { - RISCV_ISA_EXT_DATA(i), - RISCV_ISA_EXT_DATA(m), - RISCV_ISA_EXT_DATA(a), - RISCV_ISA_EXT_DATA(f), - RISCV_ISA_EXT_DATA(d), - RISCV_ISA_EXT_DATA(q), - RISCV_ISA_EXT_DATA(c), - RISCV_ISA_EXT_DATA(h), - RISCV_ISA_EXT_DATA(zicntr), - RISCV_ISA_EXT_DATA(zicsr), - RISCV_ISA_EXT_DATA(zifencei), - RISCV_ISA_EXT_DATA(zihintpause), - RISCV_ISA_EXT_DATA(zihpm), - RISCV_ISA_EXT_DATA(zba), - RISCV_ISA_EXT_DATA(zbb), - RISCV_ISA_EXT_DATA(zbs), - RISCV_ISA_EXT_DATA(smaia), - RISCV_ISA_EXT_DATA(smstateen), - RISCV_ISA_EXT_DATA(ssaia), - RISCV_ISA_EXT_DATA(sstc), - RISCV_ISA_EXT_DATA(svade), - RISCV_ISA_EXT_DATA(svpbmt), +static const struct riscv_isa_ext_entry __initconstrel riscv_isa_ext[] = { + RISCV_ISA_EXT_ENTRY(i, ANY), + RISCV_ISA_EXT_ENTRY(m, ANY), + RISCV_ISA_EXT_ENTRY(a, ANY), + RISCV_ISA_EXT_ENTRY(f, NONE), + RISCV_ISA_EXT_ENTRY(d, NONE), + RISCV_ISA_EXT_ENTRY(q, NONE), + RISCV_ISA_EXT_ENTRY(c, ANY), + RISCV_ISA_EXT_ENTRY(v, NONE), + RISCV_ISA_EXT_ENTRY(h, NONE), + RISCV_ISA_EXT_ENTRY(zicntr, ANY), + RISCV_ISA_EXT_ENTRY(zicsr, ANY), + RISCV_ISA_EXT_ENTRY(zifencei, ANY), + RISCV_ISA_EXT_ENTRY(zihintpause, ANY), + RISCV_ISA_EXT_ENTRY(zihpm, ANY), + RISCV_ISA_EXT_ENTRY(zba, ANY), + RISCV_ISA_EXT_ENTRY(zbb, ANY), + RISCV_ISA_EXT_ENTRY(zbs, ANY), + RISCV_ISA_EXT_ENTRY(smaia, ANY), + RISCV_ISA_EXT_ENTRY(smstateen, ANY), + RISCV_ISA_EXT_ENTRY(ssaia, ANY), + RISCV_ISA_EXT_ENTRY(sstc, NONE), + RISCV_ISA_EXT_ENTRY(svade, NONE), + RISCV_ISA_EXT_ENTRY(svpbmt, NONE), }; static const struct riscv_isa_ext_data __initconst required_extensions[] = { @@ -181,7 +239,7 @@ static void __init match_isa_ext(const char *name, const char *name_end, for ( unsigned int i = 0; i < riscv_isa_ext_count; i++ ) { - const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i]; + const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i]; /* * `ext->name` (according to initialization of riscv_isa_ext[] @@ -480,6 +538,98 @@ bool riscv_isa_extension_available(const unsigned long *isa_bitmap, return test_bit(id, isa_bitmap); } +static int __init build_guest_isa_str(char *buf, size_t size) +{ + char *p = buf; + size_t left = size; + int total; + +#if defined(CONFIG_RISCV_32) + total = snprintf(p, left, "rv32"); +#elif defined(CONFIG_RISCV_64) + total = snprintf(p, left, "rv64"); +#else +# error "Unsupported RISC-V bitness" +#endif + + if ( total < 0 ) + return total; + + if ( buf ) + { + if ( (size_t)total >= left ) + return -ENOSPC; + + p += total; + left -= total; + } + + for ( unsigned int i = 0; i < ARRAY_SIZE(riscv_isa_ext); i++ ) + { + const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i]; + int ret; + + if ( !riscv_isa_extension_available(guest_isa, ext->id) ) + continue; + + ret = snprintf(p, left, "%s%s", + ext->id >= RISCV_ISA_EXT_BASE ? "_" : "", + ext->name); + if ( ret < 0 ) + return ret; + + total += ret; + + if ( buf ) + { + if ( (size_t)ret >= left ) + return -ENOSPC; + + p += ret; + left -= ret; + } + } + + return total; +} + +static void __init compute_guest_isa(void) +{ + int len; + + for ( unsigned int i = 0; i < ARRAY_SIZE(riscv_isa_ext); i++ ) + { + const struct riscv_isa_ext_entry *ext = &riscv_isa_ext[i]; + + if ( (ext->guest_flags & RISCV_ISA_EXT_GUEST_XLEN) && + riscv_isa_extension_available(NULL, ext->id) ) + __set_bit(ext->id, guest_isa); + } + + /* + * All domains are given the same guest ISA, so the "riscv,isa" string + * is built only once here and then shared by all of them. + */ + if ( (len = build_guest_isa_str(NULL, 0)) < 0 ) + panic("Failed to calculate guest \"riscv,isa\" length: %d\n", len); + + if ( !(guest_isa_str = xvmalloc_array(char, len + 1)) ) + panic("Failed to allocate guest \"riscv,isa\" string\n"); + + if ( build_guest_isa_str(guest_isa_str, len + 1) != len ) + panic("Failed to build guest \"riscv,isa\" string\n"); +} + +void init_guest_isa(struct domain *d) +{ + d->arch.isa = guest_isa; +} + +const char *get_guest_isa_str(void) +{ + return guest_isa_str; +} + void __init riscv_fill_hwcap(void) { unsigned int i; @@ -527,4 +677,6 @@ void __init riscv_fill_hwcap(void) if ( !all_extns_available ) panic("Look why the extensions above are needed in " "https://xenbits.xenproject.org/docs/unstable/misc/riscv/booting.txt\n"); + + compute_guest_isa(); } diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 2819ff4e7c92..c9933147595e 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -308,6 +308,8 @@ int arch_domain_create(struct domain *d, if ( is_idle_domain(d) ) return 0; + init_guest_isa(d); + if ( (rc = p2m_init(d, config)) != 0) goto fail; diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h index 0c48d57a03bb..2973eb13a513 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -5,6 +5,7 @@ #ifndef __ASSEMBLER__ #include +#include /* * These macros represent the logical IDs of each multi-letter RISC-V ISA @@ -44,7 +45,11 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_MAX }; +struct domain; + void riscv_fill_hwcap(void); +void init_guest_isa(struct domain *d); +const char *get_guest_isa_str(void); bool riscv_isa_extension_available(const unsigned long *isa_bitmap, enum riscv_isa_ext_id id); diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 6044ce0feee0..8ae01a5e4dcc 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -7,6 +7,7 @@ #include #include +#include #include #include #include @@ -94,6 +95,8 @@ struct arch_domain { struct p2m_domain p2m; struct paging_domain paging; + + const unsigned long *isa; }; #include -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413252.1643509 (Exim 4.92) (envelope-from ) id 1x4JuO-0001ZN-Q6; Wed, 09 Sep 2026 15:08:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413252.1643509; Wed, 09 Sep 2026 15:08:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JuO-0001ZC-ND; Wed, 09 Sep 2026 15:08:20 +0000 Received: by outflank-mailman (input) for mailman id 1413252; Wed, 09 Sep 2026 15:08:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JuN-0001Tv-Bv for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JuM-003DHh-Oh for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:18 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17658-bab6-0a2a0a5309dd-0a2a4503bcf8-28 for ; Wed, 09 Sep 2026 17:08:18 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17662-fae8-0a2a45030019-4a7de48cb13c-3 for ; Wed, 09 Sep 2026 17:08:18 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254fa663c2so45963866b.3 for ; Wed, 09 Sep 2026 08:08:18 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966498; x=1789571298; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZgRpdRy/E2EC0N94y/FzcJNCbvvQyl1VngGFLh0kH90=; b=p9JNTyDHwVirKvvMN/7RpnT1x39acqQ7AXVm0eLPPRPC20KmPeCCb92agyW9Zq/d6r tMlC3trRFokr9EUSMN3y/EiLOwfQznfNBVMkigN9qwt24vDmP4Zf1E0Aahe5vnbR+2Co uSa6xm8LvR4Wlwa/pjtXAGZ+R4dil2t9UxBv/bQgHkbvoNqkpG+beFETyDdID2d1XkaG sa6e0w0eLKkqZe9+juNcIyF2LLo7+4+z0PXC6ClwMBMchDANQgwT7WkiUyXvKw5f9IKA ufQDiinWs3GGwHc0Feo4Z3ng9GEf5zoVcSOKa3jthfXz9grfTSygx6uM+Tdz7ZXc+fhl ckKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966498; x=1789571298; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ZgRpdRy/E2EC0N94y/FzcJNCbvvQyl1VngGFLh0kH90=; b=b755eauxEsdj62KV587M03d3WqnWMoRiG309GsEa2T2MDyt7rCj/3fozFmXr8xkogM XUHgSADPp4kKStsH+tz4p7tweNF97Tmix8+tI8DetN299sbJOesOshrTXfwVBKASXQep z2QX39GtWL80PNFhOiX7/k0Z1W71WWGg+PX86qovSmryINguDSk8dyAFCzJrNMjrDl4w c83Iq4se/WJp+O6WEyVjtfaimEX8bbZZaScc9VvfQ2oEbOliKwsZsOVV49sPUb4BzXKT osUgxe+e7RaNXVaN7VmQBwIyjZYvlSHdJSe2KceR2ccPeGNoM0jlc2ldjuKYMOZWxxp6 NZcA== X-Gm-Message-State: AFuF++kUMo3G1TWZE/9ovqRPt4O0nfQG9+De3jhN76iE3Dt0LkAFP3TH MRJH+uGPRr0nquy9BGU35W5XTdPdgpaq+mkdUxKSlpxkKb4qGY2KcVflBLXM0Nt6 X-Gm-Gg: AYBFou3WrEGOFrkGn53O822uajv/4hQNUigwmKgiRFaxIe0SnwyZXvhZpG1f5vmOCxe YufOfHxAlfbq8cUH+MlV+rBrcu3lozmVs5RfIfzG8swrTiOijlUvUnxjbV0gS6aHVzpxbj/sPCn wSxWjqKKquo0Nks2JylQ/gczS6nAe27htuu7LKuKg9++hpYWXlkDj0IU0kijBmWRNYaP2gjLMwb /xZXGNH7z/M7QsgxwPhEJokEksiAB+/hyaTvyy82nezyUHI03UUPAoWDwmvTpBFhDY7CCBpRByn Xbn6M8JJx74fTZ1A8nM7O8J1r2TEE+UyXD30EPTXOK+uUOk1LmDGNkPC/MNI4xVytnzJ3Ve3B9F 55VRBu8NGE6OIrCg/tcUhLE9H6XjuahGozkNJ4Xq+8SsXYM59vrNnMbE/mB7yjOEI4Q5T7G1Gd0 7rxlkk1p53/gxoVb/623xp+BnVuSO1VNGM4DieF3f94VT6v8lTZaN6K+FFqWP14xF465hHq02/X +wzHrh35Zt1ZmERluams6wjxY6tjw== X-Received: by 2002:a17:907:728f:b0:c25:362e:fb8b with SMTP id a640c23a62f3a-c29419f9643mr142637266b.7.1788966498060; Wed, 09 Sep 2026 08:08:18 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 05/20] xen/riscv: implement make_cpus_node() Date: Wed, 9 Sep 2026 17:07:23 +0200 Message-ID: <123512c9a3686aac6c3c97e5624ae98c4ad26f3d.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788966498-6DAD44E9-4DA18F8F/10/73395122804 X-purgate-type: spam X-purgate-size: 6219 Implement make_cpus_node() to create cpus node for a guest domain. This function is going to be use by common dom0less code during construction domain. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v9: - Only rebase. Nothing changed. --- Changes in v8: - Add Acked-by: Jan Beulich . --- Changes in v7: - use get_guest_isa_str() for the "riscv,isa" property instead of building the string per domain. - as a consequence, drop the isa_str/len local variables, the xvmalloc_array()/xvfree() pair and the inclusion; with no resource left to release, the error paths now return res directly and the "out" label is gone. - s/sizeof/ARRAY_SIZE for snprintf's argument. - Drop Acked-by: Jan B. as some changes were done so it would be nice if Jan B. will review them again. --- Changes in v6: - Update the two build_guest_isa_str() call sites for its new `const struct domain *d` signature. - Drop build/tools/fixdep from the patch. - Add Acked-by: Jan Beulich . --- Changes in v5: - Drop Acked-by: Jan Beulich as extra changes were done because of the changed in prev. patch. - Move isa_str allocation and construction out of arch_domain_create() and into make_cpus_node() as a local variable, since the string is only needed during FDT generation. Use a two-call build_guest_isa_str() pattern (size probe, then fill) with xvmalloc_array, and convert all post-allocation error returns to goto out so xvfree() runs on every path. --- Changes in v4: - Update the comment in make_cpus_node() to match code style. - Add Acked-by: Jan Beulich . --- Changes in v3: - Add blank line above make_cpus_node() function definition. - Move 'unsigned int cpu' from function-level declarations into the for loop. - Drop 'uint32_t reg = cpu_to_fdt32(cpu)'; use fdt_property_cell(fdt, "reg", cpu) instead of fdt_property(fdt, "reg", ®, sizeof(reg)) so byte-order adjustment is handled internally. - Add matching /* interrupt-controller */ start comment; fix end comment to /* end interrupt-controller */. - Update d->arch.guest_isa_str to ->isa_str in make_cpus_node() function. --- Changes in v2: - s/u32/uint32_t for timebase_frequency local variable. - Drop +1 from BUILD_BUG_ON(). - return fdt_end_node(fdt); instead of res at the end of the function. --- --- xen/arch/riscv/domain-build.c | 106 ++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c index 5f6f4b6248a5..1af4c48fb30c 100644 --- a/xen/arch/riscv/domain-build.c +++ b/xen/arch/riscv/domain-build.c @@ -3,8 +3,10 @@ #include #include #include +#include #include +#include #include #include @@ -48,3 +50,107 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) return 0; } + +int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo) +{ + int res; + const struct dt_device_node *cpus = dt_find_node_by_path("/cpus"); + uint32_t timebase_frequency; + bool frequency_valid; + void *fdt = kinfo->fdt; + + dt_dprintk("Create cpus node\n"); + + if ( !cpus ) + { + dprintk(XENLOG_ERR, "Missing /cpus node in the device tree?\n"); + return -ENOENT; + } + + frequency_valid = dt_property_read_u32(cpus, "timebase-frequency", + &timebase_frequency); + + res = fdt_begin_node(fdt, "cpus"); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "#address-cells", 1); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "#size-cells", 0); + if ( res ) + return res; + + if ( frequency_valid ) + res = fdt_property_cell(fdt, "timebase-frequency", timebase_frequency); + + for ( unsigned int cpu = 0; cpu < d->max_vcpus; cpu++ ) + { + char buf[64]; + + snprintf(buf, ARRAY_SIZE(buf), "cpu@%u", cpu); + res = fdt_begin_node(fdt, buf); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "reg", cpu); + if ( res ) + return res; + + res = fdt_property_string(fdt, "status", "okay"); + if ( res ) + return res; + + res = fdt_property_string(fdt, "compatible", "riscv"); + if ( res ) + return res; + + BUILD_BUG_ON((sizeof("riscv,") + + sizeof_field(struct gstage_mode_desc, name)) >= sizeof(buf)); + snprintf(buf, ARRAY_SIZE(buf), "riscv,%s", max_gstage_mode->name); + res = fdt_property_string(fdt, "mmu-type", buf); + if ( res ) + return res; + + res = fdt_property_string(fdt, "riscv,isa", get_guest_isa_str()); + if ( res ) + return res; + + res = fdt_property_string(fdt, "device_type", "cpu"); + if ( res ) + return res; + + /* Start of interrupt-controller */ + res = fdt_begin_node(fdt, "interrupt-controller"); + if ( res ) + return res; + + res = fdt_property_string(fdt, "compatible", "riscv,cpu-intc"); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "#interrupt-cells", 1); + if ( res ) + return res; + + res = fdt_property(fdt, "interrupt-controller", NULL, 0); + if ( res ) + return res; + + res = fdt_property_u32(fdt, "phandle", alloc_phandle(kinfo)); + if ( res ) + return res; + + /* End of interrupt-controller */ + res = fdt_end_node(fdt); + if ( res ) + return res; + + res = fdt_end_node(fdt); + if ( res ) + return res; + } + + return fdt_end_node(fdt); +} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413273.1643536 (Exim 4.92) (envelope-from ) id 1x4Juq-0003Sc-JD; Wed, 09 Sep 2026 15:08:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413273.1643536; Wed, 09 Sep 2026 15:08:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Juq-0003SV-GT; Wed, 09 Sep 2026 15:08:48 +0000 Received: by outflank-mailman (input) for mailman id 1413273; Wed, 09 Sep 2026 15:08:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Juo-0003Ef-GW for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Jun-00DoNW-TR for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:45 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17665-e002-0a2a0a5209dd-0a2a4506ec68-38 for ; Wed, 09 Sep 2026 17:08:45 +0200 Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1767d-195a-0a2a45060019-d155da2ae80b-3 for ; Wed, 09 Sep 2026 17:08:45 +0200 Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c262bc686d9so755811766b.2 for ; Wed, 09 Sep 2026 08:08:45 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966525; x=1789571325; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/0W7LJeeRtFjbmuJPQsrOkLOl9/tUs9pbSj+ISpVBYg=; b=QSNg//iiO1wdtmenxp2hOlm263UL1KyUdEwAhj/QCuphQTHIHazJKpMd42ELcU9cNv H3rXCsDOTKCnowz9ACl7L39tmn7l43rhHQxIsav4ZvyUbGOGUizMUtvREJxHze1ewJTK RMq8g3YgWw+Vz4T8hps2WD+KkRBvMAlsfY9OdKyByneZISTsC00ozF5Y/drVoV0yDlyO TAyJM+2Kc6vNSz9VNIT5zOnr80OdtT+4TBDxR66Uw6grouFCK1IN4rJsvZAAwcw01uW0 Xcyo25rrg9yqM8/0yL3k1b7vouEzMWHuoupWdrntTbkdzA2JLZjxSmYVn1j2G9+LbLTk SbCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966525; x=1789571325; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=/0W7LJeeRtFjbmuJPQsrOkLOl9/tUs9pbSj+ISpVBYg=; b=ej6rIToaNfBhOfQpHL/2sEIC1gpD9wzIYNqTtjHzTD1VhU4tR4nIx9atqotyJExQI/ ufKbhbQbph9mne1yPLx4iHKEMyZe/PuBkrtIjfyJK1rfR6Om8uuqs96pZlSwZsAlRreV 5C7pwXZm1I54wXTZO3uvA4Tzkm7E3tl67YNHLAQd2ueu4whfrZ+TS8uJvUsnqrhc/wh1 FW/piyjLjpF4oabA030Gv67FZd0SvIQUmtAQdfaJlJ+VO6bE6pajBF2TdeiHN3Th9YJV 2RWoewZfDrg+3rL8VahOMW4DGvpBJpqnr6zEiB4nM8JfPM0KumgUNtBLI5wLfp0nmN4R 0/rg== X-Gm-Message-State: AFuF++m2sCKlNGWorZ+bR0DThApHSUSMhlioalsqiPfK7aqGiHQClDCx QpWKx3tPSV3q1v0MGGazhRksLGG4cxLaRDAS6puDvpuUgdwRB5YxOxltf/czyt3b X-Gm-Gg: AYBFou0X81ELmsSHtJVjem6fa66/qyDNu0Jgc7m0kMNn2ftO3U5Cqyrl/66NtcFkAmw MTYOcqGd+n/V3smw2qZJqvyRFZEoSqvsE/wK8wl2yo0rZNvVRZjNEbOBX+3Qnk1fzv8O9oYZx6w y2kOuv8SxO0EHtfMUmp+JPQonl91+qg0Y+H5g0FMhmgeZB5ocCZWHwmGkGPoHTPX2iHbCb6lWSL s4t9DrmVOeqDHR6kwoYPgXNJP2OXGj63AIBFLk6LlG7TUwwp8fUzdwop14P0WxQhCaDYw0wHLLe mBr5QUlZnAvqDFkUBsN89DYZZIuhqebazSP86XT7ttHWIQUVMxk9TnC97OM41wodz5ALW3srWJ8 5d+v+Kkpj4bjrJB5RMJml8b8RHA17KMsJwASub9hf7ldBQbe2GfEkQIRkt9fFlj6I8mghIMpuJk kSd4n6TCDdiHCdv5bPP54EZWLe1nXjo1f+MXGQqfCoSGwAC1vX34kN6vrvTWJKyN2jFEJhEXOKg aNQnhWAUt5hGcK85rQ= X-Received: by 2002:a17:907:c81a:b0:c21:726b:34eb with SMTP id a640c23a62f3a-c260c7ad2e2mr1393559666b.8.1788966525397; Wed, 09 Sep 2026 08:08:45 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 10/20] xen/riscv: introduce aia_init() and aia_usable() Date: Wed, 9 Sep 2026 17:07:28 +0200 Message-ID: <38e822dac4d22a8f8348b54a8d0f7dff9187b904.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1788966525-FDA0C77B-CC68EF0F/10/73395122804 X-purgate-type: spam X-purgate-size: 3240 aia_init() is going to contain all the logic related to AIA initialization. At the moment, it only checks whether the SSAIA extension is available, and if so, sets is_aia_usable (which indicates more than just the availability of the extension) to true; it also signifies that the necessary components (to be introduced in follow-up patches) have been initialized. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v6-9: - Nothing changed. Only rebase. --- Changes in v5: - Update the guards in asm/aia.h according to CODING_STYLE: s/ASM__RISCV__AIA_H/RISCV_AIA_H. --- Changes in v4: - Add Acked-by: Jan Beulich --- Changes in v3: - s/is_aia_usable/_aia_usable to drop the is_ prefix while avoiding conflict with the aia_usable() function name. --- Changes in v2: - s/is_aia_available/is_aia_usable. - Drop return value for aia_init(). - s/aia_available()/aia_usable(). --- --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/aia.c | 23 +++++++++++++++++++++++ xen/arch/riscv/include/asm/aia.h | 10 ++++++++++ xen/arch/riscv/intc.c | 3 +++ 4 files changed, 37 insertions(+) create mode 100644 xen/arch/riscv/aia.c create mode 100644 xen/arch/riscv/include/asm/aia.h diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 2d24670dfc74..8e7a6370eee2 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -1,3 +1,4 @@ +obj-y += aia.o obj-y += aplic.o obj-y += cpufeature.o obj-y += domain.o diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c new file mode 100644 index 000000000000..e31c9c2d24b6 --- /dev/null +++ b/xen/arch/riscv/aia.c @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include + +#include + +static bool __ro_after_init _aia_usable; + +bool aia_usable(void) +{ + return _aia_usable; +} + +void __init aia_init(void) +{ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) ) + return; + + _aia_usable = true; +} diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/aia.h new file mode 100644 index 000000000000..aaa4bf91fc75 --- /dev/null +++ b/xen/arch/riscv/include/asm/aia.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef RISCV_AIA_H +#define RISCV_AIA_H + +bool aia_usable(void); + +void aia_init(void); + +#endif /* RISCV_AIA_H */ diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index e63da5e22efc..2864a896b677 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -9,6 +9,7 @@ #include #include +#include #include static const struct intc_hw_operations *__ro_after_init intc_hw_ops; @@ -33,6 +34,8 @@ void __init intc_init(void) { ASSERT(intc_hw_init_ops && intc_hw_init_ops->init); + aia_init(); + if ( intc_hw_init_ops->init() ) panic("Failed to initialize the interrupt controller drivers\n"); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413280.1643545 (Exim 4.92) (envelope-from ) id 1x4Jus-0003hc-0q; Wed, 09 Sep 2026 15:08:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413280.1643545; Wed, 09 Sep 2026 15:08:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Jur-0003hS-U9; Wed, 09 Sep 2026 15:08:49 +0000 Received: by outflank-mailman (input) for mailman id 1413280; Wed, 09 Sep 2026 15:08:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Juq-0003SN-SI for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Jup-007z99-TZ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:47 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17668-8faa-0a2a0a5109dd-0a2a450cbeca-38 for ; Wed, 09 Sep 2026 17:08:47 +0200 Received: from [209.85.218.45] (helo=mail-ej1-f45.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1767f-f479-0a2a450c0019-d155da2de946-3 for ; Wed, 09 Sep 2026 17:08:47 +0200 Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-c1670dad7a8so965968466b.3 for ; Wed, 09 Sep 2026 08:08:47 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966527; x=1789571327; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=w/c0Ov9Mx+pVjgOHFwnnwfC8nzGn8agSgog6oIobVXU=; b=Yf3hNfrCXlL3KsMPBBIiT2PvxEYMaSIZX6cJzDvN6G9J1f8yRujOd/1jGA1qw+37Hi 5WrXsaVjU+uwQmPzA1qdK7oV3ar+7BT16klwDDzosS6r36jpE24GH7B/C1nlRqjb0Gpl GZS+by6eUHGG3u8YOHA4cdc0d2a0WhVyFHtegCR97xcvCZXW8bg2b2ymHkb3wTZSW+fG d8O5q90NHS/BobMjUnISTPot+Bg7D+G0XxXYJV61GGBJdjhDqpvZU6irxuUJCinvtPM3 HzqsuaoPV1ZQY5wkpc0xXhUAtnX+DPLsWoj/VcFSB/eQgb0wqrviUpT8UwgQ6FoE1fPK rRcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966527; x=1789571327; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=w/c0Ov9Mx+pVjgOHFwnnwfC8nzGn8agSgog6oIobVXU=; b=PGLcnsClMaGphpDiB41uFmIBCqv6AeljnkCqb3T26w23mnGgEI8YuG5Br4zkPlcGkY 4KW41pX5ZDU3WAOun9VZHZq+3Ri4wFOKxTi+5l+2vIq/rJTLvNlzsjBVNXQJpUJLNyk0 QVFw1EbB4+Ri2IKPapVEGH+yzVFIMCXntoua30s0PxBioD2dCY3fUbc6AHOF3YzvKlnv +WzBrrY5jFH+SeG1lyOh0URyJ26JiC9hg1Co6qb3eyrj2x70h21NKpkPbTaC7GbC24lQ X+rT1N93JAt+q6jvNGPRrE/Cu0Jz6G6yz5PBtI27OBxiMbwmMcftth/sn04FHlS2Jm1T fmYg== X-Gm-Message-State: AFuF++nGGoDnB3si7bnJLHnCa3n9SneVn3DwiXLwSCj7Wnkgv7iwVpBt tY+wnR6gfo8SOqosx4ZydycASLOkz2V1nnjMJrTKgxbD1kQQVbeSvEEeZrEyq10S X-Gm-Gg: AYBFou3oXRpO7SFqpFFHjxtugz6HxrP5CqYoletnLkmWS9mPyI84aHUHT0OIpHU3KRZ 6Aabe9JrV3jc3l3tdpGrZQ/2LphCnnIqLbaE9l1nUA5TgXySWtmUJUD6y04aAMJLpzAZ9ahxxfS P8bhOkYLOkyQJft/Ng5IR+OAhrZ/gXVrtEgYcFCYujpz/GzsS8HgL7bySdbTqujTkOx+q3DID/l ifleLAHsT3HQ+vsCk5Evs45lcGWFhmvcCILJLJjOE+hHmTSr9rH0AxgobkmVmgx4JD9tkdv3n1E V083WFQwuK9sX7tkPGcsDmr0J8odSfFqTmwyEdOEsx3uwL8gQ3+ywyRv5MTc9XrbUpvHLkZAY/i X0SI/Ml6iakppWqiav5M3I/7gjd4b5Z0SV6aGObH8dgikdC6ir4FA68xxOp1dgd9YzySSbyqcPa rBOiUlfw7WAjOhcAE5+URVZUXgcJn5NAvlCKhXV2xRHLg+0Riw5pWhMNG+U18/AeACrLtdZusJD ertbO0wtnq9qmStjRo= X-Received: by 2002:a17:907:3e90:b0:c29:448b:f5d0 with SMTP id a640c23a62f3a-c29448bfc23mr14248766b.33.1788966527314; Wed, 09 Sep 2026 08:08:47 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 11/20] xen/riscv: introduce per-vCPU IMSIC state Date: Wed, 9 Sep 2026 17:07:29 +0200 Message-ID: <630876d9cfd6ba0917c430bfd4ff03d997e7880d.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788966527-76ADCA5B-DB51CAA7/10/73395122804 X-purgate-type: spam X-purgate-size: 6651 Each vCPU interacting with the IMSIC requires state to track the associated guest interrupt file and its backing context. Introduce a per-vCPU structure to hold IMSIC-related state, including the guest interrupt file identifier and the CPU providing the backing VS-file. Access to the guest file identifier is protected by a lock. Initialize this structure during vCPU setup and store it in arch_vcpu. The initial state marks the VS-file as software-backed until it becomes associated with a physical CPU. Add helper to retrieve the guest interrupt file identifier: - vcpu_guest_file_id() is going to be used during update of APLIC's target register with the pair of information (to have MSI delivery mode work properly) when guest is trying to access vAPLIC's target register. It will be used in the follow up patches. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v9: - Nothing changed. Only rebase. --- Change in v8: - Rename imsic_state->vsfile_pcpu to ->*_cpu to reflect better its sentinel NR_CPUS. --- Changes in v6-7: - Nothing changed. Only rebase. --- Changes in v5: - Move v->arch.vimsic_state = imsic_state; after full initialization of the struct, so the pointer only becomes globally visible once all fields are set up. - Add Acked-by: Jan Beulich . --- Changes in v4: - s/w vs h/w IMSIC VS-file commentary for struct vimsic_state: - fix the vsfile_pcpu h/w condition: "vsfile_pcpu >= 0" -> "vsfile_pcpu < NR_CPUS" (the old wording conflicted with the s/w "== NR_CPUS" case). - reorder both comment blocks to the "s/w ... / h/w ..." form for readability. - drop IMPOSSIBLE_GUEST_FILE_ID: the s/w IMSIC VS-file is always available and corresponds to guest_file_id == 0, which xvzalloc() already provides, so the explicit initializer in vcpu_imsic_init() and the macro itself are unneeded. --- Changes in v3: - Drop const from imsic_set_guest_file_id() and vcpu_imsic_deinit() as it only works due to vimsic_state being a pointer member. - Use XVFREE() in vcpu_imsic_deinit() to make it idempotent. - Fix SW-file typo in struct vimsic_state comments; should be VS-file. - Drop imsic_set_guest_file_id() here, it will be added later when it will be nessary to initialise guest file id as the correspondendt code in this patch series was reworked and there is no need to use this function in arch_vcpu_create(). - Introduce IMPOSSIBLE_GUEST_FILE_ID and init with it ->guest_file_id. --- Changes in v2: - Rename imsic_state to vimsic_state. - Use 'unsigned int' for vsfile_pcpu. - Drop initialzation of ->guest_file_id as it will be by default zero. - Add the comment about ->guest_file_id field. - Drop __init for vcpu_imsic_init() as it could be used during post-boot vCPU creation. - Update the commit message. - Drop locks around ->guest_file_id() in vcpu_guest_file_id() and imsic_set_guest_file_id(). --- --- xen/arch/riscv/imsic.c | 35 +++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/domain.h | 2 ++ xen/arch/riscv/include/asm/imsic.h | 22 ++++++++++++++++++ 3 files changed, 59 insertions(+) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 8da72c007225..4a2ef5069d0c 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -56,6 +57,11 @@ do { \ csr_clear(CSR_SIREG, v); \ } while (0) +unsigned int vcpu_guest_file_id(const struct vcpu *v) +{ + return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); +} + void __init imsic_ids_local_delivery(bool enable) { if ( enable ) @@ -312,6 +318,35 @@ static int imsic_parse_node(const struct dt_device_node *node, return 0; } +int vcpu_imsic_init(struct vcpu *v) +{ + struct vimsic_state *imsic_state; + + /* Allocate IMSIC context */ + imsic_state = xvzalloc(struct vimsic_state); + if ( !imsic_state ) + return -ENOMEM; + + /* Setup IMSIC context */ + rwlock_init(&imsic_state->vsfile_lock); + + /* + * xvzalloc() already cleared the context, so guest_file_id == 0, i.e. the + * always-available s/w IMSIC VS-file. Only vsfile_cpu needs an explicit + * initializer as its s/w VS-file value is NR_CPUS rather than 0. + */ + imsic_state->vsfile_cpu = NR_CPUS; + + v->arch.vimsic_state = imsic_state; + + return 0; +} + +void vcpu_imsic_deinit(struct vcpu *v) +{ + XVFREE(v->arch.vimsic_state); +} + /* * Initialize the imsic_cfg structure based on the IMSIC DT node. * diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index bd43ed08c22c..e035b33ddfdc 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -54,6 +54,8 @@ struct arch_vcpu { struct vtimer vtimer; + struct vimsic_state *vimsic_state; + register_t hcounteren; register_t hedeleg; register_t hideleg; diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h index c6c59215df20..5ee954bbf3ef 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -11,6 +11,7 @@ #ifndef ASM_RISCV_IMSIC_H #define ASM_RISCV_IMSIC_H +#include #include #include #include @@ -61,7 +62,24 @@ struct imsic_config { spinlock_t lock; }; +struct vimsic_state { + /* IMSIC VS-file */ + rwlock_t vsfile_lock; + /* + * s/w IMSIC VS-file -> guest_file_id == 0 + * h/w IMSIC VS-file -> guest_file_id > 0 + */ + unsigned int guest_file_id; + /* + * s/w IMSIC VS-file -> vsfile_cpu == NR_CPUS + * h/w IMSIC VS-file -> vsfile_cpu < NR_CPUS + */ + unsigned int vsfile_cpu; +}; + struct dt_device_node; +struct vcpu; + int imsic_init(const struct dt_device_node *node); const struct imsic_config *imsic_get_config(void); @@ -71,4 +89,8 @@ void imsic_irq_disable(unsigned int hwirq); void imsic_ids_local_delivery(bool enable); +int vcpu_imsic_init(struct vcpu *v); +void vcpu_imsic_deinit(struct vcpu *v); +unsigned int vcpu_guest_file_id(const struct vcpu *v); + #endif /* ASM_RISCV_IMSIC_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413281.1643554 (Exim 4.92) (envelope-from ) id 1x4Juu-0003zJ-7Z; Wed, 09 Sep 2026 15:08:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413281.1643554; Wed, 09 Sep 2026 15:08:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Juu-0003z8-3a; Wed, 09 Sep 2026 15:08:52 +0000 Received: by outflank-mailman (input) for mailman id 1413281; Wed, 09 Sep 2026 15:08:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Jus-0003ra-VY for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Jus-00DoNW-CD for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:50 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17680-e002-0a2a0a5209dd-0a2a45048b98-12 for ; Wed, 09 Sep 2026 17:08:50 +0200 Received: from [209.85.218.46] (helo=mail-ej1-f46.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17681-b57f-0a2a45040019-d155da2ed9b8-3 for ; Wed, 09 Sep 2026 17:08:49 +0200 Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-c255c58156bso1230116666b.3 for ; Wed, 09 Sep 2026 08:08:49 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966529; x=1789571329; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Dt+oJbLlbJOl272w2oSgdeAx/VzdS+DDC/2pUVZckDs=; b=HuAUpCbos4lRFB/J4xlcz5OHPjwi6dJTZ2LdcaqS/jtojHTrsiX4aQ8BSQ+K88RyCY gkQWXGQf0uxh3KgAc5lQEM+M8LbKp7FfyA/CEnxchQwov3oWlc7BMmpzMhsJjMgUAx6B JWnW4v3kIMzlQKsnn/Lsj43FEKRuHWvQuOxURFXxATfbCaKtyujVShXvqC7qTENfU2Ux GwuzICfLP2mpl+lZIKCnz+oaF3JZolusN0zuBmDbeWjDSH1RXJCCaPhpeF5PsfVk3t8H 5CAq7y4z7EHdxVbtu+h5ut0mRMsXvAy0jvxyHgH39x6wDIOpBDLYYD8M+QW5HZF4AEYp iBsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966529; x=1789571329; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Dt+oJbLlbJOl272w2oSgdeAx/VzdS+DDC/2pUVZckDs=; b=No5rS1RqeeHTXdw8UixBNHCdnwGxDg3WhHHyzoUkL8iW0lxZDjzDWZlBTl3SfqQm0X mq+c2iMY4p/a8iapfId+N908YFVqjyI9s7fqajGPYULSZOLeYlzICnY30XmNioH7JbTj Zv6iWxMEWnWd7XEoA23tiJN40LwHWZ7oBQVRs+f9vl0Gb/dkVUbokbijtyO7smowLfZ3 kknx26CnzkApBTUc0yOrBxk4JcfCeg/Y2/GBxIpg6BHy0aOtD2gmIXxrQreJC2zodaGK 3LuOOaP0uRc+Hn6mKf9GwzJkq9bMbwRVyE5kPV2ZzOS2nR5cNAvWXFIFaxliM3z/8Nx5 hzew== X-Gm-Message-State: AFuF++lhXknTGnHfIAAXNCGdnAQLx5e8VZpYHIlgAkjTkkiXFbqLrEHP Oeqi+4DihaXuYyY14FR5E4G2VELdalOoJB/nGtgGJTOLEkRvSRKCG4riEVD4EDWk X-Gm-Gg: AYBFou0+COdw4Sn2jRA9SBTumHmuW8fHzK3IIJeXTmNVTg5PMAvbPLeJhXVmEkfBNOi Kic9d8bNYjxit3p7b0QY3ULaR/Io+cwWqGAbd4QLoPJ1wO6cUs+iGMp3KqpDCrZ+U01MXiCeMeE jXn3R3IlcU4x0zm13l7d1px4AkRMl+vE5kxmea+6FCvrcrr6Jx94UU+SebjPtyuIJG4HdG8gegc FrfrkgjoZq9wAazpHi6mpLJ99Gl2ZSt1PdnQfVyD+VRUcAFnDJR6LSZj7l8bZIxIdBnk9kVQb1M CNkEVYhke7zD0FW/e7rUuJGaXCTYZfbWSFH5ODwxaS2LbQ+lPDMTXAe70alXtPUF6TKXztrFM9P xuE0xiJPran90lgm92ardK6TDQLSX5WmYE2KIquX4VdXtlwhKNTyzUsgCTfxz80sqTsQzpP4Tw8 71baRLTwDwkjuMrm61Eh65Amwp+auPOZMaZTjeEuEvvzFPzIw0XlwbA5ZTTSxoAqzTwGMUt4CrT FCxLhFg+KNaNAJcfEmPMmNWZDqaUw== X-Received: by 2002:a17:907:d90:b0:c24:6985:d7a1 with SMTP id a640c23a62f3a-c260c7aa1d2mr1326746266b.7.1788966529239; Wed, 09 Sep 2026 08:08:49 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 12/20] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure Date: Wed, 9 Sep 2026 17:07:30 +0200 Message-ID: <2317c9e591944d29f77d5759f2b4c7570186e6cf.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1788966529-508D9B50-9E6824E9/10/73395122804 X-purgate-type: spam X-purgate-size: 10434 At the current development stage, only domain vINTC init and deinit operations are required, so implement those first. Initialize vAPLIC's domaincfg to with the interrupt-enable bit set and MSI delivery mode selected as the current solution is exepcted to have always IMSIC, and initialize vintc->ops. Other operations such as emulate_load(), emulate_store(), and is_access() will be needed once guests are running and MMIO accesses to APLIC MMIO range must be handled. These will be introduced separately later. Introduce a structure to describe a virtual interrupt controller (vINTC) and a vintc_ops structure, which provides operations to emulate load and store accesses to interrupt controller MMIOs and to check whether a given address falls within the MMIO range of a specific virtual interrupt controller. Note that already existed init_ops field in struct vintc will be init-ed for APLIC in the follow up patch. The vAPLIC implementation of these operations will be provided later once guests can be run and these operations are actually needed. Introduce these structures here as they are required for the implementation of domain_vaplic_init() and domain_vaplic_alloc(). Also, introduce vaplic_init() and init vintc_ops->vcpu_init() with it. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v9: - Nothing changed. Only rebase. --- Changes in v8: - Drop vaplic_init() and vcpu_imsic_deinit() as they are just calling IMSIC related files as we are expecting to work only MSI mode. - And add cf_check for vcpu_imsic_(de)init as they are directly used now for vintc_ops->vcpu_(de)init. --- Changes in v7: - Add Acked-by: Jan Beulich . - Update the comment above init_ops member of vintc structure. --- Changes in v6: - Nothing changed. Only rebase. --- Changes in v5: - Add explanational comments for fields in struct vintc. - Drop unnessary empty line in asm/aplic.h. - Update the commit message to tell that init_ops will be init-ed later in follow up patch. - Init. .domaincfg with only APLIC_DOMAINCFG_RO. - Update the comment above APLIC_DOMAINCFG_RO. - Add defintion for APLIC_DOMAINCFG_BE. --- Changes in v4: - Change subject of the commit. - s/APLIC_DOMAINCFG_RO80/APLIC_DOMAINCFG_RO + added a comment above definition. - Drop unnessary blank lines. --- Changes in v3: - Drop ASSERT() before vintc->ops->vcpu_init() in arch_vcpu_create(); a NULL deref already produces a sufficient backtrace. - Parenthesize macro argument in to_vaplic(). - Drop __init from domain_vaplic_init() and domain_vaplic_deinit() since the caller domain_vintc_init() (follow-up patch) is not __init. - Remove pointless zero-initializer for rc in vcpu_vaplic_init(). - Fix domain_vaplic_deinit() to null d->arch.vintc before freeing, making the function idempotent. - Drop intc_irq_nums(), (*nr_irqs)(void) hook from intc_hw_operations, aplic_nr_irqs(), and vintc->nr_irqs field entirely. - Rename vcpu_vaplic_init() to vaplic_init() and drop vgein_assign() and imsic_set_guest_file_id() calls; those will be introduced/called later, where for sure we will know on which pCPU vCPU as it is required for proper h/w IMSIC interrupt file calculation, to have this initialization in one place. - Introduce vaplic_deinit(). --- Changes in v2: - s/vcpu/v for function arguments in struct vintc_ops(). - Update the comment above is_access() and drop const for addr argument. - Update to_vaplic() to work with 'struct domain *'. - Drop smsiaddrcfg{h} from vaplic_regs struct as they aren't used for now. - Drop inclusion of xen/schec.h from intc.c. - use result of xvzalloc() as initializer in vpalic_alloc(). - Drop goto in domain_vaplic_init(). - s/XVFREE/xvfree. - s/aplic/vintc. - Drop __init for vcpu_vaplic_init() as it could be called for secondary CPU bring up. - Drop vaplic_alloc(). - Drop vintc_ops struct, embed callbacks iniside struct vintc. - Introduce and init vintc irqs for vAPLIC. - Introduce intc_irq_nums() to properly initialize number of vAPLIC's irqs. --- --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/domain.c | 11 ++---- xen/arch/riscv/imsic.c | 4 +-- xen/arch/riscv/include/asm/aplic.h | 7 ++++ xen/arch/riscv/include/asm/intc.h | 12 +++++++ xen/arch/riscv/include/asm/vaplic.h | 34 +++++++++++++++++++ xen/arch/riscv/vaplic.c | 52 +++++++++++++++++++++++++++++ 7 files changed, 111 insertions(+), 10 deletions(-) create mode 100644 xen/arch/riscv/include/asm/vaplic.h create mode 100644 xen/arch/riscv/vaplic.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 8e7a6370eee2..fcd73c7a2dd5 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -25,6 +25,7 @@ obj-y += smpboot.o obj-y += stubs.o obj-y += time.o obj-y += traps.o +obj-y += vaplic.o obj-y += vmid.o obj-y += vm_event.o obj-y += vsbi/ diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index c9933147595e..45712d305975 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include @@ -155,14 +156,8 @@ int arch_vcpu_create(struct vcpu *v) if ( (rc = vcpu_vtimer_init(v)) ) goto fail; - /* - * As interrupt controller (IC) is not yet implemented, - * return an error. - * - * TODO: Drop this once IC is implemented. - */ - rc = -EOPNOTSUPP; - goto fail; + if ( (rc = v->domain->arch.vintc->ops->vcpu_init(v)) ) + goto fail; return rc; diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 4a2ef5069d0c..809f29af860a 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -318,7 +318,7 @@ static int imsic_parse_node(const struct dt_device_node *node, return 0; } -int vcpu_imsic_init(struct vcpu *v) +int cf_check vcpu_imsic_init(struct vcpu *v) { struct vimsic_state *imsic_state; @@ -342,7 +342,7 @@ int vcpu_imsic_init(struct vcpu *v) return 0; } -void vcpu_imsic_deinit(struct vcpu *v) +void cf_check vcpu_imsic_deinit(struct vcpu *v) { XVFREE(v->arch.vimsic_state); } diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h index b0724fe6f360..5a7fcb6ec4f1 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -15,8 +15,15 @@ #include +/* + * domaincfg read-only fields (AIA spec): + * - bits [31:24] -> read-only 0x80 + * - bit 7 -> read-only 0 + */ +#define APLIC_DOMAINCFG_RO (0x80U << 24) #define APLIC_DOMAINCFG_IE BIT(8, U) #define APLIC_DOMAINCFG_DM BIT(2, U) +#define APLIC_DOMAINCFG_BE BIT(0, U) #define APLIC_SOURCECFG_SM_INACTIVE 0x0 #define APLIC_SOURCECFG_SM_DETACH 0x1 diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index a4e678fad90b..875728885292 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -17,6 +17,7 @@ enum intc_variant { struct cpu_user_regs; struct irq_desc; struct kernel_info; +struct vcpu; struct intc_info { enum intc_variant hw_variant; @@ -53,8 +54,19 @@ struct vintc_init_ops { int (*make_domu_dt_node)(struct kernel_info *kinfo); }; +struct vintc_ops { + /* Initialize some vINTC-related stuff for a vCPU */ + int (*vcpu_init)(struct vcpu *v); + + /* Deinitialize some vINTC-related stuff for a vCPU */ + void (*vcpu_deinit)(struct vcpu *v); +}; + struct vintc { + /* Callbacks invoked during domain construction only. */ const struct vintc_init_ops *init_ops; + /* Runtime callbacks used for the lifetime of the guest. */ + const struct vintc_ops *ops; }; void intc_preinit(void); diff --git a/xen/arch/riscv/include/asm/vaplic.h b/xen/arch/riscv/include/asm/vaplic.h new file mode 100644 index 000000000000..96080bfbc23b --- /dev/null +++ b/xen/arch/riscv/include/asm/vaplic.h @@ -0,0 +1,34 @@ +/* SPDX-License-Identifier: MIT */ +/* + * xen/arch/riscv/vaplic.c + * + * Virtual RISC-V Advanced Platform-Level Interrupt Controller support + * + * Copyright (c) Microchip. + */ + +#ifndef ASM__RISCV__VAPLIC_H +#define ASM__RISCV__VAPLIC_H + +#include +#include + +#include + +struct domain; + +#define to_vaplic(d) container_of((d)->arch.vintc, struct vaplic, vintc) + +struct vaplic_regs { + uint32_t domaincfg; +}; + +struct vaplic { + struct vintc vintc; + struct vaplic_regs regs; +}; + +int domain_vaplic_init(struct domain *d); +void domain_vaplic_deinit(struct domain *d); + +#endif /* ASM__RISCV__VAPLIC_H */ diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c new file mode 100644 index 000000000000..c9f188b989a3 --- /dev/null +++ b/xen/arch/riscv/vaplic.c @@ -0,0 +1,52 @@ +/* SPDX-License-Identifier: MIT */ +/* + * xen/arch/riscv/vaplic.c + * + * Virtual RISC-V Advanced Platform-Level Interrupt Controller support + * + * Copyright (c) Microchip. + * Copyright (c) Vates + */ + +#include +#include +#include + +#include +#include +#include +#include + +#include "aplic-priv.h" + +static const struct vintc_ops vintc_ops = { + .vcpu_init = vcpu_imsic_init, + .vcpu_deinit = vcpu_imsic_deinit, +}; + +int domain_vaplic_init(struct domain *d) +{ + struct vaplic *vaplic = xvzalloc(struct vaplic); + + if ( !vaplic ) + return -ENOMEM; + + d->arch.vintc = &vaplic->vintc; + d->arch.vintc->ops = &vintc_ops; + + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO; + + return 0; +} + +void domain_vaplic_deinit(struct domain *d) +{ + struct vaplic *vaplic; + + if ( !d->arch.vintc ) + return; + + vaplic = to_vaplic(d); + d->arch.vintc = NULL; + xvfree(vaplic); +} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413284.1643563 (Exim 4.92) (envelope-from ) id 1x4Juv-0004F1-H9; Wed, 09 Sep 2026 15:08:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413284.1643563; Wed, 09 Sep 2026 15:08:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Juv-0004Eq-DU; Wed, 09 Sep 2026 15:08:53 +0000 Received: by outflank-mailman (input) for mailman id 1413284; Wed, 09 Sep 2026 15:08:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Juu-0003yx-6p for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Jut-007z99-Jn for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:51 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17682-8faa-0a2a0a5109dd-0a2a450c8274-2 for ; Wed, 09 Sep 2026 17:08:51 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17683-f479-0a2a450c0019-4a7de48c9210-3 for ; Wed, 09 Sep 2026 17:08:51 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c294496989aso15911166b.3 for ; Wed, 09 Sep 2026 08:08:51 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966531; x=1789571331; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=XBmqn5QW1wcqH90/ZG0vHM4CgtbXqvupt8SmP6XIcus=; b=NZsNTGh80mlwrtH2WIm2Z+8QvqQhqheAerJa0op/12z2uUpkFGimIqnpTP0s8qJmtk 12hUKIMIoatn28V7Jgz8BDV4TmZD/ClcgQ9Uw7HrhGwCUqOgB7PMJRVaU/HXgTZY6FsP trbbUXzAoKKzpr7eEqb8L3kczfDAtbR+3jX1Y8ZyIyaOuB1LWJbZR7rGqrY2hvkijAfN RBadKHfLZUiNxCuuieASXfcH91YnmHqRZSQ+ITPSU6A7ZM7cEHk/4LDVQ+j+DSaQjyFg 7wfD107cOI5/oyH1m1JfZWvFSIexFXobwuNNfo7PraAIP8MGwrimPsZ7rvM+IccaoIen K+9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966531; x=1789571331; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=XBmqn5QW1wcqH90/ZG0vHM4CgtbXqvupt8SmP6XIcus=; b=LzaVE5MtE70gHZtyMxWRYkF2hyuEhQf5eQ1Vz5lyEbBCysbjBvqGblH8O31TdD1rqL 4e+/ZhuspbSw1M3xSDYFgMJ685IPpnqq1+xlf58l/Vn3znD1mexWHj0tKgRqGfIZQ9AD LCm3EmFdtzFAxz171mR8IS56cUpiqGRP+l/ABvTvmVzX29RSiXf1Qq5b60fbi3qFNaqL /gCQynDirjGOyU4hW2FzLbm14Ad9/U4YQMxZnnU9tCSfkMHYJdUHoQnsof0bzGJlaWhm 6AjC2g3cQOsxMmYKF6zn486g3+85vDi97bxTs2n4Yi9clhvo/gOezOs2uT7vLHKd5fWs gVnw== X-Gm-Message-State: AFuF++ngALNpHhJm8Ni9dblpLNjoAIZ8XM+fNX9Gkm7qCIwEtilPtgOd yxQho2h5RL7qib6MJowVRxKNO4ATth02DkE0uJVEjFoUVkzNekZSx7bTvTdpxon/ X-Gm-Gg: AYBFou0O06SpyLSIRg272zvXlRtyeLDuwaMTE+jnCoKgd1uNPYPdbEigGXW6q/fAyB5 S+QPD2MHVDImZUJ66Sy+6pmcZ/mrYIqsBJWUjjf8hHhUP98xFpcD2wfYszEOiT1Ap63KIDTkQnK N+0up77wfKZ9wLOX5fH+bqcOC6U/tqQ55k3PmPtwHe8CFup6BhwmvjS7nLJ9plJiejCF1QjlkgX fCQGUKwtrvFfCXhvJNaz8H5gB+gKEp4C1zVSmv+Fuh/Mwl7N1Urj3fViruDa7I/ko8KsxJuKAZt LfA1g7DIwkDYZa1HkNbi37sQLHQq8zKn9LxGEuOhExnOzt3Mw8N81EWKjzYWiT+mCSVt5PL7OXy WMitO00HpeFRYafcSqutvtGjgVK+V2fOXx5Axg6+1NP+Lz6PVK4VG4NoNmWq/vKUXYguQvAVw4Y KuRC1qimFPrixyavk4zwFTWucvRmXYE+bTApfqgA700t91zLOheCKwIc2WgPfWc+WnxcMDkWh2N AbcShW2NpcqqUGKGZ4= X-Received: by 2002:a17:907:c244:b0:c26:1648:a076 with SMTP id a640c23a62f3a-c2941be4cc7mr63914866b.49.1788966530979; Wed, 09 Sep 2026 08:08:50 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 13/20] xen/riscv: introduce (de)initialization helpers for vINTC Date: Wed, 9 Sep 2026 17:07:31 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1788966531-768DDA5B-AB41261D/10/73395122804 X-purgate-type: spam X-purgate-size: 4217 Add common helpers domain_vintc_init() and domain_vintc_deinit() to allocate and deallocate a virtual interrupt controller (vINTC) structure and initialize basic virtual interrupt controller registers. domain_vintc_deinit() isn't called at the moment as arch_domain_destroy() is implemented as stub at the moment. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v9: - Add Acked-by: Jan Beulich . --- Changes in v8: - Add call of domain_vintc_deinit() to arch_domain_destroy(). - Update printk message. - Drop Acked-by. --- Changes in v6-7: - Nothing changed. Only rebase. --- Changes in v5: - s/printk/printk_once(). - Add Acked-by: Jan Beulich . --- Changes in v4: - Drop the comment from domain_vintc_init() about guests receiving a virtual interrupt controller that mirrors the host hardware as there can (and eventually should) be alternatives. - Finish renaming intc_version to intc_variant in domain_vintc_(de)init() (enum intc_variant, info->hw_variant, local variable) started in the prev patch. --- Changes in v3: - Drop redundant printk() from domain_vintc_deinit()'s default case to avoid duplicate messages when init fails. - Add a comment to domain_vintc_init() clarifying that guests currently receive a virtual interrupt controller that mirrors the host hardware. --- Changes in v2: - Drop __init for domain_vintc_(de)init(). - Update the commit message. --- --- xen/arch/riscv/domain.c | 7 ++++++- xen/arch/riscv/include/asm/intc.h | 3 +++ xen/arch/riscv/intc.c | 35 +++++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 45712d305975..d94652809e36 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -291,7 +291,9 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) void arch_domain_destroy(struct domain *d) { - printk(XENLOG_WARNING "%s: unimplemented\n", __func__); + printk(XENLOG_WARNING "%s: not fully implemented\n", __func__); + + domain_vintc_deinit(d); } int arch_domain_create(struct domain *d, @@ -308,6 +310,9 @@ int arch_domain_create(struct domain *d, if ( (rc = p2m_init(d, config)) != 0) goto fail; + if ( (rc = domain_vintc_init(d)) ) + goto fail; + return rc; fail: diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index 875728885292..6fc0e620e937 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -79,4 +79,7 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority); void intc_handle_external_irqs(struct cpu_user_regs *regs); +int domain_vintc_init(struct domain *d); +void domain_vintc_deinit(struct domain *d); + #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */ diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index 2864a896b677..f5c8af6ddea4 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -11,6 +11,7 @@ #include #include +#include static const struct intc_hw_operations *__ro_after_init intc_hw_ops; @@ -83,3 +84,37 @@ int __init make_intc_domU_node(struct kernel_info *kinfo) return vintc->init_ops->make_domu_dt_node(kinfo); } + +int domain_vintc_init(struct domain *d) +{ + int ret = -EOPNOTSUPP; + const enum intc_variant variant = intc_hw_ops->info->hw_variant; + + switch ( variant ) + { + case INTC_APLIC: + ret = domain_vaplic_init(d); + break; + + default: + printk_once("vintc (variant:%d) isn't implemented\n", variant); + break; + } + + return ret; +} + +void domain_vintc_deinit(struct domain *d) +{ + const enum intc_variant variant = intc_hw_ops->info->hw_variant; + + switch ( variant ) + { + case INTC_APLIC: + domain_vaplic_deinit(d); + break; + + default: + break; + } +} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413285.1643571 (Exim 4.92) (envelope-from ) id 1x4Juy-0004Yy-0g; Wed, 09 Sep 2026 15:08:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413285.1643571; Wed, 09 Sep 2026 15:08:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Jux-0004Yk-Sz; Wed, 09 Sep 2026 15:08:55 +0000 Received: by outflank-mailman (input) for mailman id 1413285; Wed, 09 Sep 2026 15:08:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Juw-0004P5-CZ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Juv-003DUG-Pj for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:53 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17672-2eae-0a2a0a5409dd-0a2a4501e5d2-46 for ; Wed, 09 Sep 2026 17:08:53 +0200 Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17685-5984-0a2a45010019-d155da2ae984-3 for ; Wed, 09 Sep 2026 17:08:53 +0200 Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c1670dad7a8so965985966b.3 for ; Wed, 09 Sep 2026 08:08:53 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966533; x=1789571333; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=KTaQ9h189jrQ8PflO0q1KoloPtCJkXzXCsZXadZts+I=; b=DSRuXFGGcE4SP7xaT531FHP64lCVLDfoI97NZwuAzIEpEyguFkJPGVLqVysZuXe4Ek /u77etr9wP9NLXgod77MuPV2zXfO3KREe6sJV2S41ao8uRFj9TOKOyArctzvFgxw/07O i54sY9WZgLrOywwrg2QRF7/Q0gyvKFIGJO1A/ges+tTtwD3+1aI61WMhY1UUI/fmxoe6 r+/0PJyeUR9D1PHF6j81JBUQXf0x3GbEgeiNlJgSIP7rDmbpATyNeWJ/b6CJkUJks4T8 WxuBamm6B+JnTGNPkux9WS+gzTDbZKUDymBvLGJHwNETMtxfI7nofO88D544K/80es4y BPzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966533; x=1789571333; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=KTaQ9h189jrQ8PflO0q1KoloPtCJkXzXCsZXadZts+I=; b=UaxuYnqSZDaAMTzChXT0z5rqAIHZa1+t06cBI807am7jQQm/zQvdoi9ffi+ac8jjVs StFB+Bu+TCSI2yP/PLnBgz4igbzfujILpsnRjbBrdt/i4g6jKl/lTJ2zyEE8CSW8aI1A crgIpQnFYGx494gp04EGelAyWs4+AVDluMACx8Lam0mFOuc2JPY2rvL0OqBkrTHIyEwk yEhTHlxIQSiC6tclcNTkVz5D6R2AI3pNOOJYLx6CYZxXN9QF9PZDSqaxr2llXpsJKthZ 2N8pfC5bkn7G36O8XnIqvADNb7SZrkR04d9lt59enIhR+pWVDg8iTvYW0C/J8tHSk400 UfZQ== X-Gm-Message-State: AFuF++kNvgF2NWUyj6u+07OmMHjrIg1BCHj8W/4OewsiFM9EZytWtbu8 Ymke9YWyyVlrwrCicYr7eh5/NKV36h6iiR4Xr9H0/98zZKJJPOadBLIRP6ikpnzB X-Gm-Gg: AYBFou2lD3vqBHc5tbt0xZHv0FNgsiU80OVuYs8RV/BcV/LjUIeYHSIM8YyPvJtNaGU DGk/LfrviKhlTg+Jj/vYsGCVnVzcl5txnkXOrv794N81I06ZinBS3WrD4Z8EMVBp4xCuoy0t9us 4wHHdMFD7YeVqAQS2xphy5LvOYgVLU7HK+sy9kThH0qV2H2KPoAiBfxUfbfQSppm6NWWy6ToSlw y0RqherUkJZq4DeOIUMiKIWO5EdqeIr5qkNXcczgf/l3kkEtoNKX5oSXZjt+7el0jslFGH3+9uF OJsLr20bXVXD9532amfVT0HVDM63+dQiZhK/dr+DDZwv2KO6jiuQKSJ4VMztU20Hcj4pX10E+2+ pb/0IT5x+oi9vwDwpzMdqu9fIAa10Z/0VfYCxJG39f6YfKGs8bCl7kddWbsmYIoRjVI6OL9/Tkp 0Vh98BQtHZSRrw5SaftJZiyQuRO92bNQQOjT9lQTfAbjcjeEa4v11PJ+cQ7F/Z5sGy5zK8dB5Yv P2tIlTL92aNnu3aHNk= X-Received: by 2002:a17:907:b045:20b0:c26:24ed:39e5 with SMTP id a640c23a62f3a-c2624ed44cfmr762869766b.18.1788966532972; Wed, 09 Sep 2026 08:08:52 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 14/20] xen/riscv: generate IMSIC DT node for guest domains Date: Wed, 9 Sep 2026 17:07:32 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788966533-1E07B757-28D47B88/10/73395122804 X-purgate-type: spam X-purgate-size: 10790 Guests using the IMSIC interrupt controller require a corresponding Device Tree description. Add support for generating an IMSIC node when building the guest DT. This allows guests to discover and use the IMSIC interrupt controller. The value choosen for GUEST_IMSIC_S_BASE is an address which is typically used for IMSIC and QEMU. DT-building functions are marked __init because domain creation happens at boot time, before the init sections are freed. In a typical deployment libxl creates the interrupt controller node in userspace and hands the complete FDT to Xen, so these functions are only called during early domain construction. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v8-v9: - Nothing changed. Only rebase. --- Changes in v7: - Add Acked-by: Jan Beulich . --- Changes in v6: - Simplify initialization of guest_num_msis. - s/sizeof(vimsic_name)/ARRAY_SIZE(...). - Add empty line between declaration(s) and statement(s) in make_domu_dt_node(). - define GUEST_IMSIC_MAX_MSIS as 255U to avoid '+0U' when min(...) is used. --- Changes in v5: - s/GUEST_IMSIC_NUM_MSIS/GUEST_IMSIC_MAX_MSIS throughout. - Changed __read_mostly → __ro_after_init on guest_num_msis, since the value is set once during __init and never again. - Made imsic_parse_node() __init. - Moved the min(GUEST_IMSIC_MAX_MSIS, ...) cap into imsic_parse_node() right after guest_num_msis is assigned, so the bound is applied once at init time rather than on every DT node construction call. - Removed the now-unnecessary num_msis local variable from vimsic_make_domu_dt_node(); guest_num_msis is used directly. - s/snprintf(buf, sizeof(buf), ...)/snprintf(buf, ARRAY_SIZE(buf), ...) in guest_imsic_set_interrupt_extended_prop(). - Added decl. of vimsic_make_domu_dt_node() in this patch instead of next. --- Changes in v4: - Add a comment for guest_num_msis explaining that it is host-dependent and therefore identical for every domain, which is why a single global is used instead of a per-domain value. - Reduce vimsic_name[] from 128 to 32 bytes, which is enough to hold "/soc/imsic@" plus a 64-bit hex address. - Add a comment before GUEST_IMSIC_S_BASE noting that the value is the address typically used for IMSIC by QEMU. - s/__ULL/_UL for defintion of GUEST_IMSIC_S_BASE. --- Changes in v3: - s/__ro_after_init/__read_mostly for guest_num_msis. - Use IMSIC_MAX_ID as default for guest_num_msis instead of imsic_cfg.nr_ids. - Drop base_addr local variable in guest_imsic_make_reg_property(); use GUEST_IMSIC_S_BASE directly and introduce size to avoid spelling IMSIC_MMIO_PAGE_SZ * d->max_vcpus twice. - Change irq_ext type from uint32_t * to __be32 * in guest_imsic_set_interrupt_extended_prop(). - Move phandle declaration into the loop body. - Extend commit message to explain why __init is used for DT-building functions: libxl creates the interrupt controller node before handing the FDT to Xen, so these functions are only invoked during boot-time domain construction. - Re-order patch before APLIC DT node creation patch. - Update commit message. --- Changes in v2: - s/imsic_make_reg_property/guest_imsic_make_reg_property. - s/imsic_set_interrupt_extended_prop/guest_imsic_set_interrupt_extended_prop. - Use initalizer for regs[] array in imsic_make_reg_property(). - Move buf[] insde the for() loop. - Correct check of returned phandle. - Drop local variable len. - /s/XVFREE/xvfree in imsic_set_interrupt_extended_prop(). - Drop initializer for local variable data. - s/uint32_t/unsinged int for pos and cpu in imsic_set_interrupt_extended_prop(). - Drop next_phandle as it is now in common code. - Introduce vcpu_imsic_deinit. - Refactor vimsic_make_domu_dt_node() to avoid usage of host IMSIC dt node. --- --- xen/arch/riscv/imsic.c | 143 +++++++++++++++++++++- xen/arch/riscv/include/asm/guest-layout.h | 6 + xen/arch/riscv/include/asm/imsic.h | 3 + 3 files changed, 151 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 809f29af860a..44b8640ea39a 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -13,8 +13,12 @@ #include #include #include +#include #include +#include +#include #include +#include #include #include #include @@ -34,6 +38,21 @@ static struct imsic_config imsic_cfg = { .lock = SPIN_LOCK_UNLOCKED, }; +/* + * Number of MSIs available to a guest. Determined by the host interrupt + * controller, so it is identical for every domain -- hence a single global + * rather than a per-domain value. + */ +static unsigned int __ro_after_init guest_num_msis; + +#define GUEST_IMSIC_COMPATIBLE "riscv,imsics" + +/* + * Value is inspired by what QEMU is using for riscv,num-ids property for IMSIC + * node. + */ +#define GUEST_IMSIC_MAX_MSIS 255U + #define IMSIC_DISABLE_EIDELIVERY 0 #define IMSIC_ENABLE_EIDELIVERY 1 #define IMSIC_DISABLE_EITHRESHOLD 1 @@ -182,7 +201,7 @@ static int __init imsic_get_parent_hartid(const struct dt_device_node *node, * or IRQ_M_EXT if the IMSIC node corresponds to a machine-mode IMSIC, * which should be ignored by the hypervisor. */ -static int imsic_parse_node(const struct dt_device_node *node, +static int __init imsic_parse_node(const struct dt_device_node *node, unsigned int *nr_parent_irqs, unsigned int *nr_mmios) { @@ -285,6 +304,11 @@ static int imsic_parse_node(const struct dt_device_node *node, return -ENOENT; } + if ( dt_property_read_u32(node, "riscv,num-guest-ids", &tmp) ) + guest_num_msis = min(GUEST_IMSIC_MAX_MSIS, tmp); + else + guest_num_msis = GUEST_IMSIC_MAX_MSIS; + if ( (imsic_cfg.nr_ids < IMSIC_MIN_ID) || (imsic_cfg.nr_ids > IMSIC_MAX_ID) ) { @@ -526,3 +550,120 @@ int __init imsic_init(const struct dt_device_node *node) return rc; } + +static int __init guest_imsic_make_reg_property(struct domain *d, void *fdt) +{ + paddr_t size = IMSIC_MMIO_PAGE_SZ * d->max_vcpus; + __be32 regs[4] = { + cpu_to_be32(GUEST_IMSIC_S_BASE >> 32), + cpu_to_be32(GUEST_IMSIC_S_BASE), + cpu_to_be32(size >> 32), + cpu_to_be32(size), + }; + + return fdt_property(fdt, "reg", regs, sizeof(regs)); +} + +static int __init guest_imsic_set_interrupt_extended_prop(struct domain *d, + void *fdt) +{ + unsigned int cpu, pos = 0; + __be32 *irq_ext; + int res; + + irq_ext = xvzalloc_array(__be32, d->max_vcpus * 2); + if ( !irq_ext ) + return -ENOMEM; + + for ( cpu = 0; cpu < d->max_vcpus; cpu++ ) + { + char buf[64]; + uint32_t phandle; + + snprintf(buf, ARRAY_SIZE(buf), "/cpus/cpu@%u/interrupt-controller", cpu); + phandle = fdt_get_phandle(fdt, fdt_path_offset(fdt, buf)); + + if ( !phandle ) + { + res = -ENODEV; + goto out; + } + + irq_ext[pos++] = cpu_to_be32(phandle); + irq_ext[pos++] = cpu_to_be32(IRQ_S_EXT); + } + + res = fdt_property(fdt, "interrupts-extended", irq_ext, + d->max_vcpus * 2 * sizeof(*irq_ext)); + + out: + xvfree(irq_ext); + + return res; +} + +int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, + unsigned int *phandle) +{ + int res; + void *fdt = kinfo->fdt; + char vimsic_name[32]; + unsigned int vimsic_phandle; + + res = snprintf(vimsic_name, ARRAY_SIZE(vimsic_name), "/soc/imsic@%lx", + GUEST_IMSIC_S_BASE); + if ( res >= ARRAY_SIZE(vimsic_name) ) + { + dprintk(XENLOG_DEBUG, "vimsic name is truncated\n"); + return -ENOBUFS; + } + + res = fdt_begin_node(fdt, vimsic_name); + if ( res ) + return res; + + res = fdt_property_string(fdt, "compatible", GUEST_IMSIC_COMPATIBLE); + if ( res ) + return res; + + res = guest_imsic_make_reg_property(kinfo->bd.d, fdt); + if ( res ) + return res; + + res = guest_imsic_set_interrupt_extended_prop(kinfo->bd.d, fdt); + if ( res ) + return res; + + res = fdt_property_u32(fdt, "riscv,num-ids", guest_num_msis); + if ( res ) + return res; + + res = fdt_property(fdt, "msi-controller", NULL, 0); + if ( res ) + return res; + + res = fdt_property_u32(fdt, "#msi-cells", 0); + if ( res ) + return res; + + res = fdt_property(fdt, "interrupt-controller", NULL, 0); + if ( res ) + return res; + + res = fdt_property_u32(fdt, "#interrupt-cells", 0); + if ( res ) + return res; + + vimsic_phandle = alloc_phandle(kinfo); + if ( !vimsic_phandle ) + return -EOVERFLOW; + + res = fdt_property_cell(fdt, "phandle", vimsic_phandle); + if ( res ) + return res; + + if ( phandle ) + *phandle = vimsic_phandle; + + return fdt_end_node(fdt); +} diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h index 68d95a09394c..5e566450bdfa 100644 --- a/xen/arch/riscv/include/asm/guest-layout.h +++ b/xen/arch/riscv/include/asm/guest-layout.h @@ -3,6 +3,12 @@ #include +/* + * Base address of the guest's supervisor-mode IMSIC. The value is the address + * typically used for IMSIC by QEMU. + */ +#define GUEST_IMSIC_S_BASE _UL(0x28000000) + #define GUEST_RAM_BANKS 2 /* diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h index 5ee954bbf3ef..2425430ed116 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -78,6 +78,7 @@ struct vimsic_state { }; struct dt_device_node; +struct kernel_info; struct vcpu; int imsic_init(const struct dt_device_node *node); @@ -93,4 +94,6 @@ int vcpu_imsic_init(struct vcpu *v); void vcpu_imsic_deinit(struct vcpu *v); unsigned int vcpu_guest_file_id(const struct vcpu *v); +int vimsic_make_domu_dt_node(struct kernel_info *kinfo, unsigned int *phandle); + #endif /* ASM_RISCV_IMSIC_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:08:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:08:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413288.1643581 (Exim 4.92) (envelope-from ) id 1x4Juz-0004rW-By; Wed, 09 Sep 2026 15:08:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413288.1643581; Wed, 09 Sep 2026 15:08:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Juz-0004qT-68; Wed, 09 Sep 2026 15:08:57 +0000 Received: by outflank-mailman (input) for mailman id 1413288; Wed, 09 Sep 2026 15:08:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Juy-0004av-Al for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:08:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Jux-00DoNW-NW for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:08:55 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1766f-e002-0a2a0a5209dd-0a2a4505af18-42 for ; Wed, 09 Sep 2026 17:08:55 +0200 Received: from [209.85.218.50] (helo=mail-ej1-f50.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17687-4cb1-0a2a45050019-d155da32e593-3 for ; Wed, 09 Sep 2026 17:08:55 +0200 Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-c15e2dab83eso1042451966b.1 for ; Wed, 09 Sep 2026 08:08:55 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966535; x=1789571335; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=YFhrvSESi6fuTpLM2ezR0PpqXfEfgOGaTAHwrSqOA/E=; b=N+maZJfail7MMaasnzjppekChzt5mDu3reYwp9qcGzxiCIUvnYW3ql0F/PvYdr9xB6 a1FvVNLokZfrew54TbiEeJx587u34vDi1rMxpoXlky6iHuCU8NYvDnrObB3Whtttd4eF BNwhXi2+nWLlimUrtcxMIePqYdCPzd9lSG42K3kUCltGIBQVawlnobQHEEcbh2SAUZ19 qMjwAcfWHtWEq6jgUWhdF93E6A5FWnQ7DzJ+1/ISteN8YKoH43AOYl1J/eovsDJ1bg0g M74A6GV3qT/DnoSDxD2EwAwBxu+euA6ps5Jogh/Urxx0kDfI9tSRoN/yAONqwyrV0Zvl 7ekQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966535; x=1789571335; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=YFhrvSESi6fuTpLM2ezR0PpqXfEfgOGaTAHwrSqOA/E=; b=oLq9ErnqVmHAA2RCC9SlzxXiWYlt0dqWrkM5oEZy+2pNvxMLXJPWgzzWac1MAyubS9 GnFv4gEU6I6WA+Y7tAsStNBPtCLJIiyd9bbsmdGPuP4D6gy6qBwQwXe3nYWWwR5KWK1n zGud5l3xs8gm7nh6nKX+9W884q2eoVqnIJ+1jcflpqhxrMOLa6JBWwmb/s24vQnNcrlu hTE5yvHhlBpdHVOdzcBsJpAXrl5JaAM6mK3pddTgP/7+76kEW5ZivNtmKMm1AMRdwbo4 ZFU6Jv/GMowSwB5wCzqZdwtzVCVwGYcXTdRaqM5fPpHqzIvGb0Q4RuY9PYdRACh8sbW0 ePAw== X-Gm-Message-State: AFuF++kLcvYnKA54cBEzXhInqwZ2bfKkNafgIQntNrEBCFGK/faBMI8g FsbMKMwjxW/OGctJ1imL5iPLG71S4oMNePx0LOH5HfTI+WMCpiZ+zqu9UmRLI6e2 X-Gm-Gg: AYBFou2ZFZLsUw7YhjL7fdtisURET7vJDB22DOUAzMi0qe/bdKL9yXQNreWN1Btqzcn KyadfedoesYsrayYMNDDEBo6CtGfJps6H52OXDLjoLRGjGcoVwxTdf/XPTbjQ7fJqXDIwe0aBZ7 GSTy4hmnYUocw2VDKYy9v3W6zFQWRNOyWYOJEK/F1e1u1LKKLWXX372EkeZQFy2GVwxmCe6mehM +ONFTqfpF2qegoTkUVJnbzIXGtLu8xl6AJC6emoAEZHWSmkeiki1fIMKAVl+Q1LgzmRXgsVPPir SttC5koGxBCgJCWJJa40gLKPTLK2G4WF/k/nFnHBgFz0y6l1CNIsyWkWRRWlmzpKKlGUPnDZvXL SrwdjKPhMNrT/poUncabf99+IliLPo0dUfqZxMvUnAJ94g29NWPGpy7tlkEW695vomUS3FHyKB6 maTqtxsZimDdW5C/uDI+fxSTX6yncdjRzdQ37oUT1X7dws2FXerNmYDQBGtL3JDFaS5P7Jd/BOg KXwo/YweLl5m4a1YYY= X-Received: by 2002:a17:906:c151:b0:c26:19de:912c with SMTP id a640c23a62f3a-c2619dea162mr1489635866b.31.1788966534970; Wed, 09 Sep 2026 08:08:54 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 15/20] xen/riscv: create APLIC DT node for guest domains Date: Wed, 9 Sep 2026 17:07:33 +0200 Message-ID: <6ca287c7944692cd86720871eaf441071450563b.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1788966535-716AD2A1-AD4769AD/10/73395122804 X-purgate-type: spam X-purgate-size: 8888 Guests require a Device Tree description of the interrupt controller topology. Add support for creating an APLIC node when building the guest DT. Provide stub for imsic_make_dt_node() it will be introduced properly in follow-up patch. The value chosen for GUEST_APLIC_S_BASE is based on QEMU one. DT-building functions are marked __init because domain creation happens at boot time, before the init sections are freed. In a typical deployment libxl creates the interrupt controller node in userspace and hands the complete FDT to Xen, so these functions are only called during early domain construction. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- changes in v8 - v9: - Nothing changed. Only rebase. --- Changes in v7: - Update the comment for guest_aplic_num_sources: drop "wired" to be less confusing, and mention that it is identical for every domain only for now. - Use ARRAY_SIZE() instead of sizeof() for the size argument of snprintf() in vaplic_make_domu_dt_node(). - Add Acked-by: Jan Beulich --- Changes in v6: - Redefine GUEST_APLIC_MAX_SOURCES as 96U to avoid '+OU' in min(...). - s/guest_num_sources/guest_aplic_num_sources. --- Changes in v5: - Drop pointless initializer for local variable res in vaplic_make_domu_dt_node(). - Limit guest_num_sources in the similar way to IMSIC. - Rename VAPLIC_NUM_SOURCES to GUEST_APLIC_MAX_SOURCES to be aligned with the similar place in vIMSIC related code. --- Changes in v4: - Drop spurious and includes from aplic.c (mistakenly added, they belong to vaplic.c). - Reduce vaplic_name[] from 128 to 32 bytes in vaplic_make_domu_dt_node(). - Use __initconstrel (with const) for init_ops instead of __initdata. - s/__ULL/_UL for defintion of GUEST_APLIC_S_BASE. --- Changes in v3: - Fix rebase conflicts becuase of this patch is reordered after IMSIC DT node creation is intoduced. - Update the commit message. - Move initialization of domaincfg with APLIC_DOMAINCFG_RO80 from this patch to earlier. - Change paddr_t aplic_size to unsigned int in vaplic_make_domu_dt_node() and replace the UB (after it started to be uint) aplic_size >> 32 with an explicit 0 in the DT reg property. - Add BUILD_BUG_ON() to be sure that aplic size isn't bigger then UINT32_MAX. --- Changes in v2: - Avoid as max as possible of host properties inheritance. Only number of APLIC's irqs are checked what leads to an introduction of get_aplic_irqs_num(). - Move this patch earlier what leads to an introduction of vimsic_make_domu_dt_node() stub. - s/vimsic_make_domu_dt_node/imsic_make_domu_dt_node. - Refactor vimsic_make_domu_dt_node() to avoid re-usage of APLIC host properties. - Drop next_phandle as it is now in common code. - Drop const for kinfo argument of vimsic_make_domu_dt_node() is is going to be updated inside vimsic_make_domu_dt_node(). - Use introduced before vintc->num_irqs. --- --- xen/arch/riscv/aplic-priv.h | 13 ++++ xen/arch/riscv/aplic.c | 2 + xen/arch/riscv/include/asm/aplic.h | 8 +++ xen/arch/riscv/include/asm/guest-layout.h | 6 ++ xen/arch/riscv/vaplic.c | 77 +++++++++++++++++++++++ 5 files changed, 106 insertions(+) diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h index 85e0d028d1ae..35100d3a64fe 100644 --- a/xen/arch/riscv/aplic-priv.h +++ b/xen/arch/riscv/aplic-priv.h @@ -34,4 +34,17 @@ struct aplic_priv { const struct imsic_config *imsic_cfg; }; +/* + * Value is inspired by what QEMU is using for riscv,num-sources property for + * APLIC node. + */ +#define GUEST_APLIC_MAX_SOURCES 96U + +/* + * Specifies the number of interrupt sources supported by guest APLIC domain. + * Could be limited by host interrupt controller and is identical for every + * domain for now. + */ +extern unsigned int guest_aplic_num_sources; + #endif /* ASM_RISCV_APLIC_PRIV_H */ diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index d08401db46b3..c2d7183e1852 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -92,6 +92,8 @@ static int __init cf_check aplic_init(void) panic("%s: failed to get number of interrupt sources\n", node->full_name); + guest_aplic_num_sources = min(GUEST_APLIC_MAX_SOURCES, aplic_info.num_irqs); + if ( aplic_info.num_irqs > ARRAY_SIZE(aplic.regs->sourcecfg) ) aplic_info.num_irqs = ARRAY_SIZE(aplic.regs->sourcecfg); diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h index 5a7fcb6ec4f1..07318aaac25d 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -34,6 +34,14 @@ #define APLIC_TARGET_HART_IDX_SHIFT 18 +#define APLIC_IDC_SIZE 32 + +#define APLIC_MIN_SIZE 0x4000 +#define APLIC_SIZE_ALIGN(x) ROUNDUP(x, APLIC_MIN_SIZE) + +#define APLIC_SIZE(nr_cpus) (APLIC_MIN_SIZE + \ + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus))) + struct aplic_regs { uint32_t domaincfg; /* 0x0000 */ uint32_t sourcecfg[1023]; /* 0x0004 */ diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h index 5e566450bdfa..90603f06bb91 100644 --- a/xen/arch/riscv/include/asm/guest-layout.h +++ b/xen/arch/riscv/include/asm/guest-layout.h @@ -3,6 +3,12 @@ #include +/* + * Base address of the guest's supervisor-mode APLIC. The value is the address + * typically used for APLIC by QEMU. + */ +#define GUEST_APLIC_S_BASE _UL(0xd000000) + /* * Base address of the guest's supervisor-mode IMSIC. The value is the address * typically used for IMSIC by QEMU. diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index c9f188b989a3..a529a5b1dc49 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -9,6 +9,8 @@ */ #include +#include +#include #include #include @@ -19,6 +21,80 @@ #include "aplic-priv.h" +unsigned int __ro_after_init guest_aplic_num_sources; + +#define VAPLIC_COMPATIBLE "riscv,aplic" + +#define FDT_VAPLIC_INT_CELLS 2 + +static int __init cf_check vaplic_make_domu_dt_node(struct kernel_info *kinfo) +{ + struct domain *d = kinfo->bd.d; + int res; + void *fdt = kinfo->fdt; + unsigned int msi_parent_phandle; + char vaplic_name[32]; + unsigned int aplic_size = APLIC_SIZE(d->max_vcpus); + const __be32 reg[] = { + cpu_to_be32(GUEST_APLIC_S_BASE >> 32), + cpu_to_be32(GUEST_APLIC_S_BASE), + cpu_to_be32(0), + cpu_to_be32(aplic_size), + }; + + BUILD_BUG_ON(APLIC_SIZE(MAX_VIRT_CPUS) > UINT_MAX); + + res = snprintf(vaplic_name, ARRAY_SIZE(vaplic_name), "/soc/aplic@%lx", + GUEST_APLIC_S_BASE); + if ( res >= sizeof(vaplic_name) ) + { + dprintk(XENLOG_DEBUG, "vaplic name is truncated\n"); + return -ENOBUFS; + } + + res = vimsic_make_domu_dt_node(kinfo, &msi_parent_phandle); + if ( res ) + return res; + + res = fdt_begin_node(fdt, vaplic_name); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "#interrupt-cells", FDT_VAPLIC_INT_CELLS); + if ( res ) + return res; + + res = fdt_property(fdt, "reg", reg, sizeof(reg)); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "riscv,num-sources", guest_aplic_num_sources); + if ( res ) + return res; + + res = fdt_property(fdt, "interrupt-controller", NULL, 0); + if ( res ) + return res; + + res = fdt_property_string(fdt, "compatible", VAPLIC_COMPATIBLE); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "msi-parent", msi_parent_phandle); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "phandle", kinfo->phandle_intc); + if ( res ) + return res; + + return fdt_end_node(fdt); +} + +static const struct vintc_init_ops __initconstrel init_ops = { + .make_domu_dt_node = vaplic_make_domu_dt_node, +}; + static const struct vintc_ops vintc_ops = { .vcpu_init = vcpu_imsic_init, .vcpu_deinit = vcpu_imsic_deinit, @@ -33,6 +109,7 @@ int domain_vaplic_init(struct domain *d) d->arch.vintc = &vaplic->vintc; d->arch.vintc->ops = &vintc_ops; + d->arch.vintc->init_ops = &init_ops; vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:09:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:09:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413305.1643590 (Exim 4.92) (envelope-from ) id 1x4Jv9-0005iJ-Rm; Wed, 09 Sep 2026 15:09:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413305.1643590; Wed, 09 Sep 2026 15:09:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Jv9-0005iC-Ob; Wed, 09 Sep 2026 15:09:07 +0000 Received: by outflank-mailman (input) for mailman id 1413305; Wed, 09 Sep 2026 15:09:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4Jv8-0005cI-5K for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:09:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Jv7-00DoQS-I6 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:09:05 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17686-e002-0a2a0a5209dd-0a2a45018c2e-22 for ; Wed, 09 Sep 2026 17:09:05 +0200 Received: from [209.85.218.45] (helo=mail-ej1-f45.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17691-5984-0a2a45010019-d155da2de5bb-3 for ; Wed, 09 Sep 2026 17:09:05 +0200 Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-c15e2dab83eso1042489266b.1 for ; Wed, 09 Sep 2026 08:09:05 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:09:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966545; x=1789571345; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=H5HNH6k6iCxxkoSMpv3sBw0b64bZYiUjkym7mIw7F1o=; b=TIIOko2H+zKfPZfFFAUavUo+VW1QFOl8T+ZwvTcGJSnxG9aPwSEJrUDmlWiN24nG2m jJuOj+gXBl+XtJ82JKZv+/t5WjJ+9FR+hKX5CV5KTvb50NCopDui1/gsaRgR7foDHNFU 1EL8ZtXVKFP9Fznk22l5qdF06RcAMCujqAfITzZWkB2ZE1qsSKD6pwf/rTjtpqdCKzqw Ee9i04knoxjhdXvCeyy36psD+XqyjaTB4wc5XHZQlHIHYct54ZGz1i7oQNOna5WZrznd yyOwhAw0IOPHPBzWLFwIjDLR4L0hRPSqcsdGB/HE65IXVKc9e9QP8MgNR/9WLfSl4j/q YpSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966545; x=1789571345; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=H5HNH6k6iCxxkoSMpv3sBw0b64bZYiUjkym7mIw7F1o=; b=R9OkFlaUEw5NcfN1/EB5k/MhsSQ5GSwpo86gX+n2IH9YFnPTa5vzSQRciT+Mxm6N03 BbTs/pxxT6VQkrzpNzHt+GdS1/OfHXY0wckfzVBiH35mGgTVD/qMN0isETskOFQSKSn1 KI/4M3CV/s1CBt6ea7kVpV5SXhWd2dMUuAkPdtryv6OsAceUVQrp5ddzj/9vX7ntsTC4 IMMeQtR7myEJ9l8b/rW7HocmcDvtQYLW2rvN0rETvfOIBh4TmjFGPq9iziA4STAaMPK6 BYKAnfjc6cc5UWiKVoBm7nPY/0zU27lVF/8exWga8zG0yCFa1rTsnuq5A5TJZAzY4BQO djCw== X-Gm-Message-State: AFuF++l0GBx5kOOFaQJHkptqhL/IrcdPyxDlQA55ALJInSbIGjqOCl2m LlXTwHS3PQ/efBYYzvr7nfxuB7wlkUufbAPfgGsGhF6munp4SsKRnJpnSgeJPH6q X-Gm-Gg: AYBFou1EUy81R3GgJUhPcXn/TUNW7fwujP0b2EXAg8arU74URxKHk7LxaISfAI9rw8W W3qQp8VZl3fVkdDToDz1TYIr/eJsgxAAQjDLTKWhmD2NEoKhq7ggd04draGWioa6+LWU5xdtHA0 ld+nUdOKEn2m6FTxiMrb8NbMLd2F8aAn3g3KdADDJbwO53JT2UBL8ChU1gIt/8QOFFIZvtilNtf bzzkRe/JNhZbIra1sEQ/Oqudcd0dYre4KaICzeT2GBn0QlazkbULx7aXnAAVebMNuaqVe4bI6TF ylSb87ZA2QDF/tSJmGyAgHvJwpT2CQ9N+2uOorhEHmYoVHeZuLzIzmMGtYqLMPCDUWiQiV6xHYO 3Mx6zhFHfhjGHFSCJ6aFQ7Oal6SgILoiUAn7WzjSuMSWbBNMKqF4zHRkBefHdm9AFUsc132h5Nu 8nWENT7Nfgqc6j5Q3M0rP0F1HxUFJybYuPnjNtnWy1cc8Xz26DKzgiAhsrVqBiInfFUJ1Hewt2z 6xAe9DHmmBdWXKdyLc= X-Received: by 2002:a17:906:eec9:b0:c26:19de:912a with SMTP id a640c23a62f3a-c2619dea136mr1237650566b.29.1788966544563; Wed, 09 Sep 2026 08:09:04 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Alistair Francis , Connor Davis , "Daniel P. Smith" Subject: [PATCH v9 16/20] xen/riscv: implement IRQ routing for device passthrough Date: Wed, 9 Sep 2026 17:07:34 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788966545-BEC61757-C521D6DB/10/73395122804 X-purgate-type: spam X-purgate-size: 30424 dom0less device passthrough requires granting guest domains access to device interrupts. Introduce map_device_irqs_to_domain() to enumerate a DT node's interrupt properties, skipping those not owned by the primary interrupt controller (as at the moment I haven't seen usages of it), and map_irq_to_domain() to grant domain access and configure Xen's interrupt descriptor accordingly. Sharing IRQ between domains is rejected. Both map_irq_to_domain() and map_device_irqs_to_domain() are marked __overlay_init, mirroring Arm: without CONFIG_OVERLAY_DTB this expands to __init, so the functions are init-only and need no XSM check; with CONFIG_OVERLAY_DTB they become runtime-callable, but the only runtime entry point is dt_overlay_domctl(), which performs the XSM checks at the domctl layer. RISC-V does not wire up DT overlay yet, so today these are strictly __init; if/when overlay support is added, the domctl-level XSM gating must be added together with it, as on Arm. route_irq_to_guest() and release_irq() manage irq_desc ownership for guest-assigned interrupts. Each assignment carries a small irq_guest structure as irqaction::dev_id, recording the owning domain and virtual IRQ number which is 1:1 mapped to physical IRQ number. A per-domain vIRQ allocation bitmap (used_irqs in struct vintc), managed by vintc_reserve_virq(), prevents the same vIRQ being claimed twice. Host and guest interrupts may differ in some operations (EOI timing in particular, possibly others): a host IRQ is completed once Xen's handler runs, whereas a passthrough IRQ must defer the physical completion until the guest issues its own EOI, otherwise a still-asserted level line would immediately retrigger and storm. This affects only the .end callback; the rest of hw_interrupt_type is shared, hence the separate host and guest hw_interrupt_type instances. With APLIC+IMSIC, guest interrupts are delivered directly by hardware through the IMSIC, bypassing do_IRQ(). The _IRQ_GUEST branch in do_IRQ() is therefore left as BUG() until a platform without direct IMSIC delivery is encountered. Signed-off-by: Oleksii Kurochko --- Changes in v9: - s/aplic_guest_irq_type/aplic_guest + introduce stubs for callbacks instead of re-using callbacks used for Xen itself. - Correct the comment above action member of struct irq_guest. - Drop test_bit() from ASSERT() in irq_get_guest_info(). - Use bit operations instead of __clear_bit() in irq_detach_action(). - Fomrat do () while () in irq_release_action() according to code style. - Update the comment above irq_release_action() and inside (before smp_rmb()). - Make an argument of release_guest_irq() pointer to const. - Drop init. of info->action.free_on_release as it will be false because of how info is allocated. - Align comments in printk() inside route_irq_to_guest(). - Move smp_rmb() after the wait loop in irq_release_action() (inside it, it ordered nothing useful) and spin with cpu_relax(). --- Changes in v8: - vintc_reserve_virq(): return an error code instead of a bool: 0 on success, -EEXIST when the vIRQ has already been reserved (which legitimately happens for an IRQ shared between devices) and -ERANGE when the vIRQ is outside the range the vINTC provides. Document the function and its return values. - vintc_reserve_virq(): mark it __overlay_init, as its only caller map_irq_to_domain() is __overlay_init too. Add the and includes this needs. - map_irq_to_domain(): check the return value of vintc_reserve_virq() and propagate anything but -EEXIST. Otherwise the IRQ would end up routed to the domain without domain_vintc_deinit() ever releasing it again. Update the stale comment accordingly. - domain_vintc_deinit(): only walk used_irqs and free it if it has actually been allocated. domain_vintc_init() can fail after the vINTC itself has been allocated, leaving used_irqs NULL. - irq.c: split the body of release_irq() into two helpers: irq_detach_action(), which removes the action matching dev_id from desc->action with desc->lock held, and irq_release_action(), which waits for a handler still running on another CPU and frees the action with desc->lock dropped. Both document the locking rules they rely on. release_irq() is now just a wrapper around the two. - release_guest_irq(): use irq_detach_action()/irq_release_action() instead of open-coding __clear_bit(_IRQ_GUEST, ...) followed by release_irq(), which looked the action up by dev_id a second time. - release_guest_irq(): drop the -EBUSY restriction that only allowed unrouting from a dying domain. Detaching the action under desc->lock now closes the window this was working around. - route_irq_to_guest(): on the intc_route_irq_to_guest() failure path, detach the action while desc->lock is still held and only release it after the lock has been dropped, instead of dropping the lock first and calling release_irq(). - route_irq_to_guest(): initialise desc at its declaration. - irq_get_guest_info(): use ASSERT(desc->action) instead of ASSERT(desc->action != NULL). --- Changes in v7: - Build device.c as device.init.o: everything it provides is __overlay_init, which is plain __init as long as CONFIG_OVERLAY_DTB stays Arm-only. Unlike Arm, which picks device.o/device.init.o based on that config, RISC-V cannot enable it, so the choice is unconditional for now. - Don't have release_irq() free the guest IRQ info anymore: set free_on_release = false and free 'info' explicitly in release_guest_irq(), i.e. reinstate the xvfree() dropped in v5. The action stays embedded in struct irq_guest, so a single allocation still covers both, but it no longer has to be the structure's first member: the offsetof() BUILD_BUG_ON and the xvfree() of a pointer that merely happened to coincide with the allocation base are gone. The ->dev_id concern from v5 doesn't apply: release_irq() clears desc->action under desc->lock and waits for in-flight handling before returning, so nothing can observe ->dev_id once 'info' is freed. - Move 'action' to the end of struct irq_guest and reword its comment accordingly. - Use xvzalloc() instead of xvmalloc() for struct irq_guest, so that the embedded action is fully initialized (action.handler was left uninitialized before). - route_irq_to_guest(): free 'info' via the common free_info label when intc_route_irq_to_guest() fails, now that release_irq() no longer frees it. - Drop a stray blank line ahead of release_irq(). --- Changes in v6: - size nr_virqs as guest_aplic_num_sources + 1 to reserve APLIC's 1-indexed source 0, so the highest source/irq could be reserved. --- Changes in v5: - add early -EINVAL return in route_irq_to_guest() if domain is dying - use __clear_bit() instead of clear_bit() in release_guest_irq() since desc->lock is already held - remove irq_get_domain() wrapper; inline irq_get_guest_info(desc)->d at its single call site - reword IRQ_GUEST comment in do_IRQ() for clarity - move XVFREE(used_irqs) before the switch so it is freed prior to variant-specific vintc teardown - fix missing space in dt_dprintk() format string split across lines - Drop 'inline' for irq_get_guest_info() and leave it only static. - Drop xfree(info) from release_guest_irq() to avoid a potential dangling-pointer issue with the ->dev_id field. Now that 'struct irqaction action;' is embedded into 'struct irq_guest', 'info' will be freed as part of release_irq() at the end. --- Changes in v4: - Update the commit message. - Mark map_irq_to_domain() and map_device_irqs_to_domain() as __overlay_init (mirroring Arm) and include . - Fix grammar in the controller-skip comment ("IRQ" -> "IRQs"). - Drop the redundant 'base' local in guest_imsic_make_reg_property(); use GUEST_IMSIC_S_BASE directly. - Rename vintc::irq_nums -> nr_virqs and update all users. - Guard domain_vintc_deinit() against a NULL d->arch.vintc. - Use smp_rmb() instead of smp_mb() in release_irq()'s wait loop and document how it pairs with the spin_unlock() in do_IRQ(). - In release_guest_irq(), reject live unrouting from a non-dying domain (-EBUSY) and clear _IRQ_GUEST under desc->lock so a concurrent release for the same IRQ bails out instead of double-freeing 'info'. - Tidy spurious whitespace in release_irq()'s spin_lock/unlock calls. --- Changes in v3: - Drop extraneous "to" from "Unable to permit to %pd" message. - Move res/irq/rirq to loop scope; use nirq as declaration initializer. - Hoist irq_ranges check before the loop (it is loop-invariant). - Remove spurious forward declarations (struct dt_device_node, struct rangeset) from intc.h; remove all three from setup.h. - Use __set_bit() instead of set_bit() in intc_route_irq_to_guest() since desc->lock is always held on every write path for desc->status. - Use XVFREE() instead of xvfree() in domain_vintc_deinit(). - Rename allocated_irqs -> used_irqs in struct vintc. - Fix dangling desc->action in release_irq()'s !IRQ_HAS_MULTIPLE_ACTION path by nulling *action_ptr after saving the action pointer. - Use true (not 1) for free_on_release in route_irq_to_guest(). - Use %pd for domain printing in route_irq_to_guest() error paths. - Introduce release_guest_irq() to pair with route_irq_to_guest() and plug the irq_guest info leak; call it from domain_vintc_deinit() for each vIRQ recorded in used_irqs. --- Changes in v2: - Rework IRQ mapping in more common (similar approach to Arm). --- xen/arch/arm/irq.c | 2 +- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/aplic.c | 31 ++++ xen/arch/riscv/device.c | 100 ++++++++++++ xen/arch/riscv/include/asm/intc.h | 9 ++ xen/arch/riscv/include/asm/irq.h | 5 + xen/arch/riscv/intc.c | 60 +++++++ xen/arch/riscv/irq.c | 261 ++++++++++++++++++++++++++++++ xen/arch/riscv/vaplic.c | 9 ++ 9 files changed, 477 insertions(+), 1 deletion(-) create mode 100644 xen/arch/riscv/device.c diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 73e58a5108ad..866fd4c4c6e6 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -205,7 +205,7 @@ void __init init_IRQ(void) static inline struct irq_guest *irq_get_guest_info(struct irq_desc *desc) { ASSERT(spin_is_locked(&desc->lock)); - ASSERT(test_bit(_IRQ_GUEST, &desc->status)); + ASSERT(desc->status & IRQ_GUEST); ASSERT(desc->action != NULL); return desc->action->dev_id; diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index fcd73c7a2dd5..3b948c11dd61 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -1,6 +1,7 @@ obj-y += aia.o obj-y += aplic.o obj-y += cpufeature.o +obj-y += device.init.o obj-y += domain.o obj-y += domain-build.init.o obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index c2d7183e1852..422c65ece4f7 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -325,9 +325,40 @@ static const hw_irq_controller aplic_xen_irq_type = { .set_affinity = aplic_set_irq_affinity, }; +static unsigned int cf_check aplic_guest_irq_startup(struct irq_desc *desc) +{ + BUG_ON("unimplemented"); +} + +/* + * Shared by ->shutdown(), ->enable(), ->disable() and ->end(), which have + * no state. + */ +static void cf_check aplic_guest_irq_stub(struct irq_desc *desc) +{ + BUG_ON("unimplemented"); +} + +static void cf_check aplic_guest_set_irq_affinity(struct irq_desc *desc, + const cpumask_t *mask) +{ + BUG_ON("unimplemented"); +} + +static const hw_irq_controller aplic_guest = { + .typename = "aplic", + .startup = aplic_guest_irq_startup, + .shutdown = aplic_guest_irq_stub, + .enable = aplic_guest_irq_stub, + .disable = aplic_guest_irq_stub, + .end = aplic_guest_irq_stub, + .set_affinity = aplic_guest_set_irq_affinity, +}; + static const struct intc_hw_operations aplic_ops = { .info = &aplic_info, .host_irq_type = &aplic_xen_irq_type, + .guest_irq_type = &aplic_guest, .handle_interrupt = aplic_handle_interrupt, .set_irq_type = aplic_set_irq_type, }; diff --git a/xen/arch/riscv/device.c b/xen/arch/riscv/device.c new file mode 100644 index 000000000000..fc41c075c772 --- /dev/null +++ b/xen/arch/riscv/device.c @@ -0,0 +1,100 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#include +#include +#include +#include +#include +#include + +#include + +int __overlay_init map_irq_to_domain(struct domain *d, unsigned int irq, + bool need_mapping, const char *devname) +{ + int res; + + res = irq_permit_access(d, irq); + if ( res ) + { + printk(XENLOG_ERR "Unable to permit %pd access to IRQ %u\n", d, irq); + return res; + } + + if ( need_mapping ) + { + /* + * -EEXIST merely means that the IRQ has already been reserved, which + * legitimately happens when the IRQ is shared between devices. Any + * other failure has to be fatal: the IRQ would otherwise be routed to + * the domain without domain_vintc_deinit() ever releasing it again. + */ + res = vintc_reserve_virq(d, irq); + if ( res && (res != -EEXIST) ) + { + printk(XENLOG_ERR "Unable to reserve vIRQ %u for %pd\n", irq, d); + return res; + } + + res = route_irq_to_guest(d, irq, irq, devname); + if ( res < 0 ) + { + printk(XENLOG_ERR "Unable to map IRQ%u to %pd\n", irq, d); + return res; + } + } + + dt_dprintk(" - IRQ: %u\n", irq); + + return 0; +} + +int __overlay_init map_device_irqs_to_domain(struct domain *d, + struct dt_device_node *dev, + bool need_mapping, + struct rangeset *irq_ranges) +{ + unsigned int i, nirq = dt_number_of_irq(dev); + + if ( irq_ranges ) + return -EOPNOTSUPP; + + /* Give permission and map IRQs */ + for ( i = 0; i < nirq; i++ ) + { + int res, irq; + struct dt_raw_irq rirq; + + res = dt_device_get_raw_irq(dev, i, &rirq); + if ( res ) + { + printk(XENLOG_ERR "Unable to retrieve irq %u for %s\n", + i, dt_node_full_name(dev)); + return res; + } + + /* + * Don't map IRQs that have no physical meaning + * ie: IRQs whose controller is not APLIC/IMSIC/PLIC. + */ + if ( rirq.controller != dt_interrupt_controller ) + { + dt_dprintk("irq %u not connected to primary controller. Connected to %s\n", + i, dt_node_full_name(rirq.controller)); + continue; + } + + irq = platform_get_irq(dev, i); + if ( irq < 0 ) + { + printk("Unable to get irq %u for %s\n", i, dt_node_full_name(dev)); + return irq; + } + + res = map_irq_to_domain(d, irq, need_mapping, dt_node_name(dev)); + if ( res ) + return res; + } + + return 0; +} diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index 6fc0e620e937..1bfba7c6155b 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -15,6 +15,7 @@ enum intc_variant { }; struct cpu_user_regs; +struct domain; struct irq_desc; struct kernel_info; struct vcpu; @@ -34,6 +35,9 @@ struct intc_hw_operations { /* hw_irq_controller to enable/disable/eoi host irq */ const struct hw_interrupt_type *host_irq_type; + /* hw_irq_controller to enable/disable/eoi guest irq */ + const struct hw_interrupt_type *guest_irq_type; + /* Set IRQ type */ void (*set_irq_type)(struct irq_desc *desc, unsigned int type); /* Set IRQ priority */ @@ -63,6 +67,8 @@ struct vintc_ops { }; struct vintc { + unsigned int nr_virqs; + unsigned long *used_irqs; /* Callbacks invoked during domain construction only. */ const struct vintc_init_ops *init_ops; /* Runtime callbacks used for the lifetime of the guest. */ @@ -76,10 +82,13 @@ void register_intc_ops(const struct intc_hw_init_ops *init_ops); void intc_init(void); void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority); +int intc_route_irq_to_guest(struct irq_desc *desc, unsigned int priority); void intc_handle_external_irqs(struct cpu_user_regs *regs); int domain_vintc_init(struct domain *d); void domain_vintc_deinit(struct domain *d); +int vintc_reserve_virq(const struct domain *d, unsigned int virq); + #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */ diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h index 62648bdc4252..57e814d90cf4 100644 --- a/xen/arch/riscv/include/asm/irq.h +++ b/xen/arch/riscv/include/asm/irq.h @@ -52,6 +52,11 @@ void init_IRQ(void); void do_IRQ(struct cpu_user_regs *regs, unsigned int irq); +int route_irq_to_guest(struct domain *d, unsigned int virq, + unsigned int irq, const char *devname); + +int release_guest_irq(const struct domain *d, unsigned int virq); + #endif /* ASM__RISCV__IRQ_H */ /* diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index f5c8af6ddea4..bca83b4f4fa3 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -3,11 +3,15 @@ #include #include #include +#include +#include #include #include #include #include +#include #include +#include #include #include @@ -78,6 +82,22 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority) intc_set_irq_priority(desc, priority); } +int intc_route_irq_to_guest(struct irq_desc *desc, + unsigned int priority) +{ + ASSERT(spin_is_locked(&desc->lock)); + + ASSERT(intc_hw_ops->guest_irq_type); + + desc->handler = intc_hw_ops->guest_irq_type; + __set_bit(_IRQ_GUEST, &desc->status); + + intc_set_irq_type(desc, desc->arch.type); + intc_set_irq_priority(desc, priority); + + return 0; +} + int __init make_intc_domU_node(struct kernel_info *kinfo) { const struct vintc *vintc = kinfo->bd.d->arch.vintc; @@ -101,6 +121,15 @@ int domain_vintc_init(struct domain *d) break; } + if ( !ret ) + { + d->arch.vintc->used_irqs = + xvzalloc_array(unsigned long, + BITS_TO_LONGS(d->arch.vintc->nr_virqs)); + if ( !d->arch.vintc->used_irqs ) + ret = -ENOMEM; + } + return ret; } @@ -108,6 +137,20 @@ void domain_vintc_deinit(struct domain *d) { const enum intc_variant variant = intc_hw_ops->info->hw_variant; + if ( !d->arch.vintc ) + return; + + if ( d->arch.vintc->used_irqs ) + { + unsigned int virq; + + for ( virq = 0; virq < d->arch.vintc->nr_virqs; virq++ ) + if ( test_bit(virq, d->arch.vintc->used_irqs) ) + release_guest_irq(d, virq); + + XVFREE(d->arch.vintc->used_irqs); + } + switch ( variant ) { case INTC_APLIC: @@ -118,3 +161,20 @@ void domain_vintc_deinit(struct domain *d) break; } } + +/* + * Mark @virq as used by @d so that domain_vintc_deinit() knows that it has to + * be released. + * + * Returns 0 on success, -EEXIST if @virq has already been reserved, which + * legitimately happens when an IRQ is shared between devices, and -ERANGE if + * @virq is outside the range of the interrupt sources the vINTC provides. + */ +int __overlay_init vintc_reserve_virq(const struct domain *d, + unsigned int virq) +{ + if ( virq >= d->arch.vintc->nr_virqs ) + return -ERANGE; + + return test_and_set_bit(virq, d->arch.vintc->used_irqs) ? -EEXIST : 0; +} diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c index b5066fc3e981..df0c4668dbbf 100644 --- a/xen/arch/riscv/irq.c +++ b/xen/arch/riscv/irq.c @@ -12,11 +12,27 @@ #include #include #include +#include #include +#include #include #include +/* Describe an IRQ assigned to a guest */ +struct irq_guest +{ + struct domain *d; + unsigned int virq; + /* + * The action of a guest IRQ has the same lifetime as this structure, so + * embed it here to have both covered by a single allocation. Consequently + * it must not be freed on its own, which is why free_on_release is left + * false for it (see irq_release_action()). + */ + struct irqaction action; +}; + static irq_desc_t irq_desc[NR_IRQS]; struct irq_desc *irq_to_desc(unsigned int irq) @@ -198,6 +214,14 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq) if ( desc->handler->ack ) desc->handler->ack(desc); + if ( desc->status & IRQ_GUEST ) + /* + * With APLIC + IMSIC, guest interrupts bypass Xen and are delivered + * directly to the guest. Without IMSIC, interrupts would be trapped + * by Xen and would need injecting into the guest here. + */ + panic("unimplemented"); + if ( desc->status & IRQ_DISABLED ) goto out; @@ -227,3 +251,240 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq) spin_unlock(&desc->lock); irq_exit(); } + +static struct irq_guest *irq_get_guest_info(struct irq_desc *desc) +{ + ASSERT(spin_is_locked(&desc->lock)); + ASSERT(test_bit(_IRQ_GUEST, &desc->status)); + ASSERT(desc->action); + + return desc->action->dev_id; +} + +/* + * Detach the action registered with 'dev_id' from 'desc' and, if it was the + * last one, shut the interrupt down. + * + * To be called with desc->lock held, which is still held upon return. The + * detached action is returned (NULL if 'dev_id' had no action registered) and + * has to be handed to irq_release_action() once the lock has been dropped. + */ +static struct irqaction *irq_detach_action(struct irq_desc *desc, + const void *dev_id) +{ + struct irqaction *action, **action_ptr = &desc->action; + + ASSERT(spin_is_locked(&desc->lock)); + +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION + for ( ;; ) + { + action = *action_ptr; + if ( !action || (action->dev_id == dev_id) ) + break; + + action_ptr = &action->next; + } +#else + action = *action_ptr; +#endif + + if ( !action ) + { + printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n", + desc->irq); + return NULL; + } + + /* Found it - remove it from the action list */ +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION + *action_ptr = action->next; +#else + *action_ptr = NULL; +#endif + + /* If this was the last action, shut down the IRQ */ + if ( !desc->action ) + { + desc->handler->shutdown(desc); + desc->status &= ~IRQ_GUEST; + } + + return action; +} + +/* + * Complete the release of an action detached by irq_detach_action(). + * + * To be called with desc->lock dropped: the lock cannot be held all the way + * through, as waiting for a handler still running on another CPU to complete + * requires do_IRQ() to be able to acquire the very same lock. + * + * Once this function has returned, the action (and hence any object embedding + * it) is no longer referenced by anyone and may be freed. + */ +static void irq_release_action(const struct irq_desc *desc, + struct irqaction *action) +{ + /* Wait to make sure it's not being used on another CPU. */ + while ( test_bit(_IRQ_INPROGRESS, &desc->status) ) + cpu_relax(); + + /* + * _IRQ_INPROGRESS is cleared in do_IRQ() after re-acquiring desc->lock, + * and lock acquisition implies a full barrier, so the handler's accesses + * are ordered before the clearing becomes visible here. The barrier below + * adds the missing load-load ordering (the loop's exit branch already + * prevents the store in xvfree() from becoming visible early), so that + * having observed the bit cleared we also see whatever the handler did on + * that CPU. Only then is it safe to free the action. + */ + smp_rmb(); + + if ( action->free_on_release ) + xvfree(action); +} + +void release_irq(unsigned int irq, const void *dev_id) +{ + struct irq_desc *desc = irq_to_desc(irq); + struct irqaction *action; + unsigned long flags; + + spin_lock_irqsave(&desc->lock, flags); + action = irq_detach_action(desc, dev_id); + spin_unlock_irqrestore(&desc->lock, flags); + + if ( action ) + irq_release_action(desc, action); +} + +int release_guest_irq(const struct domain *d, unsigned int virq) +{ + struct irq_desc *desc = irq_to_desc(virq); + struct irqaction *action; + struct irq_guest *info; + unsigned long flags; + int ret = -EINVAL; + + spin_lock_irqsave(&desc->lock, flags); + + if ( !test_bit(_IRQ_GUEST, &desc->status) ) + goto unlock_err; + + info = irq_get_guest_info(desc); + if ( d != info->d ) + goto unlock_err; + + /* + * Detaching the action happens with desc->lock still held, so that a + * concurrent release_guest_irq() for the same IRQ sees _IRQ_GUEST already + * cleared and bails out, rather than capturing the same 'info' and + * double-freeing it below. + */ + action = irq_detach_action(desc, info); + + spin_unlock_irqrestore(&desc->lock, flags); + + if ( action ) + irq_release_action(desc, action); + + xvfree(info); + + return 0; + + unlock_err: + spin_unlock_irqrestore(&desc->lock, flags); + return ret; +} + +/* Route an IRQ to a specific guest */ +int route_irq_to_guest(struct domain *d, unsigned int virq, + unsigned int irq, const char *devname) +{ + struct irq_guest *info; + struct irq_desc *desc = irq_to_desc(irq); + unsigned long flags; + int retval = 0; + + if ( d->is_dying ) + return -EINVAL; + + info = xvzalloc(struct irq_guest); + if ( !info ) + return -ENOMEM; + + info->d = d; + info->virq = virq; + + info->action.dev_id = info; + info->action.name = devname; + /* The action is part of 'info', thus it is freed together with it. */ + info->action.free_on_release = false; + + spin_lock_irqsave(&desc->lock, flags); + + /* + * If the IRQ is already used by someone + * - If it's the same domain -> Xen doesn't need to update the IRQ desc. + * For safety check if we are not trying to assign the IRQ to a + * different vIRQ. + * - Otherwise -> For now, don't allow the IRQ to be shared between + * Xen and domains. + */ + if ( desc->action != NULL ) + { + if ( test_bit(_IRQ_GUEST, &desc->status) ) + { + struct domain *ad = irq_get_guest_info(desc)->d; + + if ( d != ad ) + { + printk(XENLOG_G_ERR "IRQ %u is already used by %pd\n", + irq, ad); + retval = -EBUSY; + } + else if ( irq_get_guest_info(desc)->virq != virq ) + { + printk(XENLOG_G_ERR + "%pd: IRQ %u is already assigned to vIRQ %u\n", + d, irq, irq_get_guest_info(desc)->virq); + retval = -EBUSY; + } + } + else + { + printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq); + retval = -EBUSY; + } + goto out; + } + + retval = _setup_irq(desc, 0, &info->action); + if ( retval ) + goto out; + + retval = intc_route_irq_to_guest(desc, IRQ_NO_PRIORITY); + if ( retval ) + { + struct irqaction *action = irq_detach_action(desc, info); + + spin_unlock_irqrestore(&desc->lock, flags); + + if ( action ) + irq_release_action(desc, action); + + goto free_info; + } + + spin_unlock_irqrestore(&desc->lock, flags); + + return 0; + + out: + spin_unlock_irqrestore(&desc->lock, flags); + free_info: + xvfree(info); + + return retval; +} diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index a529a5b1dc49..14f6e3164a9b 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -113,6 +113,15 @@ int domain_vaplic_init(struct domain *d) vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO; + /* + * APLIC source 0 is reserved; sources are numbered 1..guest_aplic_num_sources + * and used directly as indices into used_irqs. Size the bitmap to + * guest_aplic_num_sources + 1 so the highest source has a valid slot + * (index 0 stays unused). Without the +1, vintc_reserve_virq() can't record + * the top source, so domain_vintc_deinit() never releases it. + */ + d->arch.vintc->nr_virqs = guest_aplic_num_sources + 1; + return 0; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:09:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:09:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413308.1643599 (Exim 4.92) (envelope-from ) id 1x4JvB-0005y6-Bn; Wed, 09 Sep 2026 15:09:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413308.1643599; Wed, 09 Sep 2026 15:09:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JvB-0005xp-7Q; Wed, 09 Sep 2026 15:09:09 +0000 Received: by outflank-mailman (input) for mailman id 1413308; Wed, 09 Sep 2026 15:09:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JvA-0005pP-HG for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:09:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Jv9-007zEL-U9 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:09:07 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17692-2eae-0a2a0a5409dd-0a2a4503b4d4-10 for ; Wed, 09 Sep 2026 17:09:07 +0200 Received: from [209.85.218.41] (helo=mail-ej1-f41.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17693-fae8-0a2a45030019-d155da29cdaf-3 for ; Wed, 09 Sep 2026 17:09:07 +0200 Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-c2941f7229dso45907066b.1 for ; Wed, 09 Sep 2026 08:09:07 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.09.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:09:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966547; x=1789571347; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2X2VEgPXszXG0oyqHbVR3NMIcSkcalO4zvs2bK/KDwI=; b=cUoFw3E7EihKMubAZAa+sRY1cB67G9SxB6stNh6MaeTVbxsdHcxDri9OUSgR56QTsj 0wzJgFp+53wpniop+7N8iaIm0HyX8uLBw5VPXKrehsJtjxAdX283l1bnFzeUu/U0KKRb DluM+GCKs/FX1l5viUyQrSkMHb5HDwfWddJ2DvCYbv7U3wNG2G9Oos+GDuDtCHg3UJDW QwkmSqrl4Rzei3Lx15rF8IOReUKLlQWOxlniP6lKmWi3w5ibzAkadzXYx5XwPyHOylFO jdE6dXlS42NpQJwTqEAymM9GFZOsB93uEcsl/QaiYHMy4D+NkJw0yi8XNRYDkMftNIQy WF/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966547; x=1789571347; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=2X2VEgPXszXG0oyqHbVR3NMIcSkcalO4zvs2bK/KDwI=; b=HVoW+i3ld+nfIWrVIT8YRgsvGf8n/04DIRv5WuBgfX0yrvhYCADJrX9Cq3HRGvt+FD nueHWZhqCMR5UVnaY8RMV/R8x3rdElp0MaW7gUkO7i4JabIP1U+aJ12yAU7MXUVBmAfo lIXV+1/6+K0EBumEs1ihfetVfG9+W3cmgRpIOM+FIopzxwPKlf9M/6kufgivY8dHIORR 5ON33qbpXuh9cFaBFu/x3vr/ukbGdOH8Q9O/5nPrKAjupWG6cGn026Anqkk1sH98eKEm NGZUbu2DyS6BUU7nDexp1w/r4qBPrggQgUsZoJIz6Ylye2Z2AXU4CWZgUCjA550bSnyo 8joQ== X-Gm-Message-State: AFuF++nCqfa33KnEKTUr2RW9vnt6PRokJ8ua14ldB2FS/VV/P+C/niCZ mQcp8uJ5KpqxAYjT+sWKNoORnqeYRmszzDf9DTt/xJ7ow+m9t1VkiJr+dMGsGh0I X-Gm-Gg: AYBFou16Aj32WZ1fZpg6lwXOJquLEndyfrg2X+WAB+STEfTV5wZHgEkjLp4PaNGtUby jVMxOs3bDvcuiZt6VXa+LhTB9G+fQwF4QwANaBb9p/3660Rt6s9Yb3nV5AMwrIo9sgD194pftbR +z9w+sZGBw70rgrhKUdEM8x6AJaGOq/RxWytLG3jqQbWdafwcDVtZWwEa8dtgFR0/3zLxsOCpKm kAOEW9x/ufMkLuT0q7W8269nkrjRaecpHAVnHnoUxo+ZxbZvWZvyFnnPUSVQOcPXfadgdEVJLta 6UmHm10RI6gIGVT2yWjo/dzyDIS4vbsA7YqLoo1qpiFF6Na9pgCktuhuLcLUbH31WSQo9fl5TLd dKDIozqsJEqryRJmR+dBSWAT8/SnNrYQopBgdUvuO5mMHvGonoZPKQyXKnThE5SdH5UkrBARAjT pxdgsYULwqK+xi72285uF89m+6qMdND0IPrzowj4gJnVph3FU4vndAG++A3CeqzBV6dqoccfFlq NJxL6wQr2CYuNzXpEY= X-Received: by 2002:a17:907:7281:b0:c25:cb7a:12d6 with SMTP id a640c23a62f3a-c260c9972aemr1413358966b.14.1788966547335; Wed, 09 Sep 2026 08:09:07 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 17/20] xen/riscv: implement init_intc_phandle() Date: Wed, 9 Sep 2026 17:07:35 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788966547-768FA4E9-CDF77EAF/10/73395122804 X-purgate-type: spam X-purgate-size: 1373 Implement init_intc_phandle() to read phandle of interrupt controller node and save it in kernel->phandle_intc for the future usage during creation of guest interrupt controller node. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v4-9: - Nothing changed. Only rebase. --- xen/arch/riscv/dom0less-build.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index 4cc00012aa8d..a1fa51b996a7 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -4,9 +4,26 @@ #include #include #include +#include #include +int __init init_intc_phandle(struct kernel_info *kinfo, const char *name, + const int node_next, const void *pfdt) +{ + if ( dt_node_cmp(name, "intc") == 0 ) + { + uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); + + if ( phandle_intc != 0 ) + kinfo->phandle_intc = phandle_intc; + + return 0; + } + + return 1; +} + int __init make_arch_nodes(struct kernel_info *kinfo) { /* No RISC-V specific nodes need to be made, at the moment. */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:09:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:09:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413312.1643609 (Exim 4.92) (envelope-from ) id 1x4JvD-0006LW-OU; Wed, 09 Sep 2026 15:09:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413312.1643609; Wed, 09 Sep 2026 15:09:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JvD-0006Kq-GO; Wed, 09 Sep 2026 15:09:11 +0000 Received: by outflank-mailman (input) for mailman id 1413312; Wed, 09 Sep 2026 15:09:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JvC-0006DU-HR for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:09:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JvB-003DYK-UB for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:09:09 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1768c-8faa-0a2a0a5109dd-0a2a4505e412-24 for ; Wed, 09 Sep 2026 17:09:09 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17695-4cb1-0a2a45050019-4a7de48c9262-3 for ; Wed, 09 Sep 2026 17:09:09 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c294496989aso15988166b.3 for ; Wed, 09 Sep 2026 08:09:09 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.09.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:09:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966549; x=1789571349; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=NRZDx0chfMO39A9GRZrF50iTQKdAjHPK16jqhdN5EMw=; b=qe/7EVF5HDwkYa29mb6UMD7aiaNVCK/0OjOmgroXrl+CfQSmbADxq0tAeUo55qV/Nu xBSXsn3fZAnRVRoMPRVayAvH3H1oPcL8rpRWQvVMOAf7+coGYWaMY4/UyP8Jp11U+QxS /p9c2E+uRsHlWv6H2vaRBg0Bx4FLQ1h6OSTictMvodiEyU55u2lQbMwyDC1Lpr7EmA4L VIwvXyjVFi/bC/N3EDT7Stcx2Szpf08GK+gFtga4O9Vx1xE6DQ0sHACM0WqZCE30wibO XlnVNYtLAkeQIO0xnepXpPp1yVGy9kHTQ95ZodUmOcVqygSMHpVlBtvVH+lYvPEogLbK hJng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966549; x=1789571349; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=NRZDx0chfMO39A9GRZrF50iTQKdAjHPK16jqhdN5EMw=; b=fwc+mwFjib9d0t9Pn2OBE9tmHzoRMB3HvuiCUsU+2+oxcjPh0EgxCJynLvqxlEIDLA eQe23zOKhqiApVnut1C5FGrl4AsjUerSTmI2lf5B0dTWcS6k+yMoM9RZOJlbBtHYOUkJ qQu8xthDGw8quy0lUv/RqNYEWOcbP4wp1tt8O6R6eGaj2ZDw/9tUceRhlHfBTZEdSTYu 3y+Qfv34372+jHQOp7u1V3mUkT4fB9S3Vl3arTzK+RENksSPmUEnD8QP6+h7dl4mumUt yJ64LaqsfksMLHxFKKJnbHjiR4mT1iWy/pJ45DxofpCRBu2kcrWBd3lJrt7pT00GVhle PJDw== X-Gm-Message-State: AFuF++mL/yGQJEaydyMNK05CDKLfPDV3DaeBSfzNQ12iypAQJOphxUti iEBkUay5GY85lZZxerdi+ldaZNHxdz/iIC9/6qtBCQWaXr2o6STbXtF9Mf6LDLr3 X-Gm-Gg: AYBFou0SZuMIyE5Fyq2XAbxJUhHxSbdOZKuTJPpis9JBiB+94/SG7RBnpGJPA4lxlei KPbGnHDhY3/nRUZIRtvnjHVlaVxRjm48E5jIl/Kglk2Z1V9fCieKip0/pcvaBc+C0csWUlj1PZ1 ZwsV4R6XeE1gjuvCfYk4+4bNNP6LmQw5g6f2HsLy7wfj1ykh5TagVpoxMz0ec3YeFa5j3AqTD7J vQWHv0wbPVT7Jd5CNq5XcQwfESXnNTwbceSe81U9KwVSGOgmaAA0M/ffjEgfTSplQ2FO2tQeX2r +RX/4Okcsb5+TfnndK0QZQpjD6TZzhx1VIkubwB21MwO/lIWZcgxtk3xolWO9zdQai+/eSnuV5k +rGD9ENWDw73j4/YJHR1ijl6EpAPO8nbBYnHwfEj+pWysabaavd4sedjk9fg+kapC7uStnx1UjW KB/U0BOO6MOBSv3dAcCRTvhXr4ACLYlK6K+L2zjSdsoJUCw7JVksXsQK67s4F/V4A1eh27Rt2Pv +OFtQSkeG/1svyB68M= X-Received: by 2002:a17:907:3f16:b0:c25:977e:5377 with SMTP id a640c23a62f3a-c2941866b25mr73624966b.10.1788966549400; Wed, 09 Sep 2026 08:09:09 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 18/20] xen/riscv: initialize RCU, scheduler, and system domains in start_xen() Date: Wed, 9 Sep 2026 17:07:36 +0200 Message-ID: <8d5aa546940bc94610fb24e90b7ab3868ab18420.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1788966549-72CB02A1-D99ED192/10/73395122804 X-purgate-type: spam X-purgate-size: 1560 Wire up the missing early-boot initialization steps in start_xen(). The scheduler must be initialized prior to do_initcalls() because cpupool_create_pool() is called during initcalls; without it, BUG_ON(IS_ERR(pool)) is triggered inside cpupool_create_pool(). Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v4-9: - Nothing changed. Only rebase. --- Changes in v3: - Add Acked-by: Jan Beulich . --- Changes in v2: - New patch. Several patches were folded into one. --- --- xen/arch/riscv/setup.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index 56a0907a855f..c3e98733ebc3 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -6,9 +6,12 @@ #include #include #include +#include #include #include #include +#include +#include #include #include #include @@ -156,12 +159,21 @@ void __init noreturn start_xen(unsigned long bootcpu_id, timer_init(); + rcu_init(); + + setup_system_domains(); + local_irq_enable(); console_init_postirq(); guest_mm_init(); + scheduler_init(); + set_current(idle_vcpu[0]); + + do_initcalls(); + printk("All set up\n"); machine_halt(); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:09:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:09:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413316.1643616 (Exim 4.92) (envelope-from ) id 1x4JvF-0006gB-UG; Wed, 09 Sep 2026 15:09:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413316.1643616; Wed, 09 Sep 2026 15:09:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JvF-0006g0-R8; Wed, 09 Sep 2026 15:09:13 +0000 Received: by outflank-mailman (input) for mailman id 1413316; Wed, 09 Sep 2026 15:09:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JvE-0006X6-MZ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:09:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JvE-007zEL-3V for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:09:12 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17692-2eae-0a2a0a5409dd-0a2a4503b4d4-34 for ; Wed, 09 Sep 2026 17:09:12 +0200 Received: from [209.85.218.52] (helo=mail-ej1-f52.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17697-fae8-0a2a45030019-d155da34e5a0-3 for ; Wed, 09 Sep 2026 17:09:11 +0200 Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-c15e2dab83eso1042514866b.1 for ; Wed, 09 Sep 2026 08:09:11 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.09.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:09:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966551; x=1789571351; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Vye8DtWFQY9KBcaSdJnoE64blVyzkPlMXr9ggX+iVYM=; b=UqTVnUfhE7qWw5I9ygN5vrIRvv4W0CWHlOT98ZujTx5FBhLOVDcE8CFV+1fXCOAz0f wwBjDXUmgolF1LcioS4WUJx9vBtyvBEM66arlHae0NMTPRDqKo1jKnzv/X2PVStkx2sm ldTrxUiUrqnt5BHNtZ7LbErww2PWGezp5ZhcGvFB89u2FbZ7sncLxymAhFB8OR5KeuA8 GmeN0M6ndrsYMR5YJ8pSv4LENLJzqBvRvhzJLKDw9vWOF85Zzzoln/Lm+5/3XeE8jKU/ sgsOdcw0N/IlODq4szTYerg0RbrmLu1IHukxcC3k+Jud35dRvYwJA2we88TBdl9DhVLH 6RbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966551; x=1789571351; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Vye8DtWFQY9KBcaSdJnoE64blVyzkPlMXr9ggX+iVYM=; b=lZ7KLeYmXobiXyctbm71zRl/OhRgy1EFcm24jTeCACQpd3cEisN8hZIKa1f65/S7TG N5SLdfI8zmf/gb9W6nxTy8MX7DePc5GkQkXxIZV24ufRJWTD6oFmjNjtmy6w8uPgw7Uu mAP0mlErEYkonUR25sgoNQtI4meJWZHaOvlgGVmEF4P2UWFtA+TNhOFy/vXsE3WW9C6W Dy3xndXUi4hUe9ilvAO+ELSXpzXafQkZCokkAllvzxT0RtVZ8vR9FJkCHDcX1sUUrQgH 5lZcqAudXPqw5SfHhn0vuGKm239NBOMe1qsIhi4PTTUyy797EYYalkpA7aU7XH8JoEA/ UChA== X-Gm-Message-State: AFuF++kgGKjd/4hd99UKPy99ffS6I2CuIkJp8w1YO5SFR/sQDEcTZdJZ e5cb8XUlq1wqoBEgz8gZuuYzkoP4wrfBodRPlO+bxdjGe2pa2VHJ0ncr73GS+wQV X-Gm-Gg: AYBFou3xnaKbz5ZKW2ZygWeqoqq/syYOY9Ayxhpqei2lnOYNkTCzcSS6RgZwIsS6PL/ 09xNJ1n+aKOgZ7zZ3fYZ+6pxqM5EGxWDe2zT0t7gmtlHkDMXY5Cecd7WDPmFCFKDsqJHIlj1JXG eimRHtMS2uxj4FZK+3dckc7TH8SCD4StRILvPxnsJhgAwIcJZE2CAMeDOVsYOf3dh3ng+AA+5o4 Sw8jPciS3QPM664D1jE9f248OQlTAeB8xxAT81XdP8G5BmXNsZAp6rzIDp1+pnrlBTLvkoyQ+Oz WiFJ/ZcfW7La4UmGtToVjTaau8OGEKWrXXgY021yu+iPXY/v+0FmC3UprqZvgOLxL6Hv/DrSpRW v7N04K2vBGATqVVVX+dvEsIklsCVpSW4PDfMZCfFBcOxc9fOCOif89hBHVi5PLSmT6+BK/jTGcr fmyohetMpyPiEwfkwRH4RyFgVEF4Pk6R5pvM1e9FEHJ97rtlNlZRtxPHYqn7SMIJgSeZwUATitW h1S X-Received: by 2002:a17:907:c81a:b0:c21:726b:34eb with SMTP id a640c23a62f3a-c260c7ad2e2mr1393683466b.8.1788966551230; Wed, 09 Sep 2026 08:09:11 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 19/20] xen/riscv: provide init_vuart() Date: Wed, 9 Sep 2026 17:07:37 +0200 Message-ID: <91853d1537d3222998d82fd1319631b0dc36a36c.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1788966551-6CCDB4E9-19B190E9/10/73395122804 X-purgate-type: spam X-purgate-size: 1391 For debug purpose is enough to have only print messages from guest what is now implemented in vsbi_legacy_ecall_handler(). For full guesst console support it will better to have something similar to [1], thereby there is nothing specific should be done, at least, for now and init_vuart() is provided to make dom0less code buildable. [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2602041533440.3175371@ubuntu-linux-20-04-desktop/ Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v3-v9: - Nothing changed. Only rebase. --- Changes in v2: - Add Acked-by: Jan Beulich . --- --- xen/arch/riscv/dom0less-build.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index a1fa51b996a7..d1a51b92936a 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -8,6 +8,14 @@ #include +int __init init_vuart(struct domain *d, struct kernel_info *kinfo, + const struct dt_device_node *node) +{ + /* Nothing to do at the moment */ + + return 0; +} + int __init init_intc_phandle(struct kernel_info *kinfo, const char *name, const int node_next, const void *pfdt) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:09:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:09:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413319.1643626 (Exim 4.92) (envelope-from ) id 1x4JvK-0007H0-9D; Wed, 09 Sep 2026 15:09:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413319.1643626; Wed, 09 Sep 2026 15:09:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JvK-0007GJ-4m; Wed, 09 Sep 2026 15:09:18 +0000 Received: by outflank-mailman (input) for mailman id 1413319; Wed, 09 Sep 2026 15:09:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JvI-000724-6b for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:09:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JvH-007zEL-JX for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:09:15 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17690-2eae-0a2a0a5409dd-0a2a450ad276-22 for ; Wed, 09 Sep 2026 17:09:15 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1769b-f2d2-0a2a450a0019-4a7de48ca1bb-3 for ; Wed, 09 Sep 2026 17:09:15 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f8694aeso186373966b.0 for ; Wed, 09 Sep 2026 08:09:15 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.09.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:09:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966554; x=1789571354; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=0ob9SOR6fkbhNbTtoSGEUBOvglDU9/ukL9qvQqIiBtg=; b=E9mYlKZpnx2qYl+g28RrvGiIRdnB9Uw3FR62pmuXncQnbtBGz8TWsQ0B9OcvRx5aXU qYTk+aV0ZdMYmCJaSPj8EUQyf8ZhcKDApmpzTriqtujOJ6r/80b5059FAHty6USXeMKN QE2PAj30WHjlvHaRUb+Q4fC0GNRkcKz7ODc7HEiKP64zDuP3813TcRqxhtVMEDJgt+xg eZU3QBuCTIpFei9sOIlReYPnDvywgfLLGylXwo3SO39bArIZgm+UZ4dgRumD53C/DQ/J RDdCP1SzDHU3sDn1StKnV85LsaidnfxPpQIqR3ZVtk2RdAW03k7TNWF9OdqmHkJ9TvwQ 1NHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966554; x=1789571354; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=0ob9SOR6fkbhNbTtoSGEUBOvglDU9/ukL9qvQqIiBtg=; b=JqReOxjI9XSddQR1x7Lwagnq7Lsg1f0XR4rqzQwlMDFQAJPt2Se9agkthboHbbMWb1 HX2tgsE2l1UiEU34f9QluMA8FqhZ04fwn8YbCB89HUupl2J5hNnclzulgsxcfh1sx0lc HtWX/sKV4v/69UtyFEHYUyGrIebq2kEWo0peHlI4FppIyNDKh4bd725QQAb7ShO0zgjZ 3cOWBep9h608DU4Gz6nSCqzJZj7nLP+G5+CHx5rh3l5tYUoMKah3bt/8HB0Uv1iVzf4A UkO0XjTZIiw4NOPhvWVjCaXc+/19WCmVri6X5LCa+YEoWrhLdhmM4lMx0Kie3WmLhVfR OZ8Q== X-Gm-Message-State: AFuF++kgWA4KF04RsHBmZgiTOgf/w92ZKUza3vv58OHX/HGScJwa4ngj swL7mdtG4FY+inrfLkMpHrnDGE2sAdr6QflN1uJqZTuvF6Ca05SMfnrxNGAeG9Xt X-Gm-Gg: AYBFou3LUaX/7RVj1XA8I2fRIHpFyUbeQVO5wWDmrGCoKaCVW0LlqtPsH9wCN6/Kpsl tjiSQo/0ZJEQ4EfMjkVyc95TKSjkArVq+8KBnZxdEF2bAMNNpNGxxGYemS4hDbB+Za0ehPxqyDJ Ls0WcYLQhBg2Rd3zAlh6ZTQXmRhYMAl3kzMrp9J6g1D0T87RMnuHH8qbp0Vh4QG5Rhy/TLPlCc8 8ZZ8SPEZXJBfiHdgIqLiUGGu/Sq7l+seOXmmKCGfkQkYLVHugGywAsL82xAtRaiO9UnTyOhA26W KHnMhjQwIwTXUThK0rNZmsu1Lyq5uEqkgdiaE4wT+iWbFZxaTo/vrmMlr0dVjdIIJfj0qbaVSYQ xyLL0eUAOL/4nGJ0Jg+wLLlqt10HiENg6GiMj8DqKyIJ14beNiL3K1cXgKNCKbm3yRzR7HSNgq7 aDg6YOtY8q7yAc3bo7sPi52op9WKsUM2rAHeOiXLGsaXeu1Id4O0Z0YM/6QwgzQqK8azZddliS3 +0qUNmaDFpUY5DEWek= X-Received: by 2002:a17:907:84e:b0:c25:35cd:fdb2 with SMTP id a640c23a62f3a-c29042fd596mr642560666b.7.1788966553927; Wed, 09 Sep 2026 08:09:13 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 20/20] xen/riscv: add initial dom0less infrastructure support Date: Wed, 9 Sep 2026 17:07:38 +0200 Message-ID: <913c29fc85190a131e88dc7bf300ab734e570ebb.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1788966555-51EC2CFC-9AC3BCFD/10/73395122804 X-purgate-type: spam X-purgate-size: 7399 Enable dom0less support for RISC-V by selecting HAS_DOM0LESS and providing the minimal architecture hooks required by the common dom0less infrastructure. Add stub implementations for architecture-specific helpers used when building domains from the device tree. These allow the generic dom0less code to build and let a basic DomU be constructed on RISC-V. construct_hwdom() and make_hypervisor_node() are still stubs returning an error: Dom0/hwdom construction isn't supported yet, and the hypervisor node generation (needed by domains with DOM0LESS_ENHANCED_NO_XS set) is not implemented. Both are marked with a TODO and are not reached by the currently supported configurations. Provide missing helpers and definitions required by the domain construction code, including domain bitness helpers and the p2m_set_allocation() prototype. Additionally define the guest magic memory region (GUEST_MAGIC_BASE / GUEST_MAGIC_SIZE) in asm/guest-layout.h. The base is arbitrary; the only constraint is that the region must not overlap guest RAM or the emulated device regions. It is placed in the unused gap below GUEST_RAM0_BASE (0x80000000); the constraints are documented next to the #define-s. A separate region for grant tables will be introduced at the same time as the introduction of the grant table for RISC-V. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v8-9: - Nothing changed. Only rebase. --- Changes in v6-7: - Acked-by: Jan Beulich . --- Changes in v5: - Reword the comment above defintion of GUEST_MAGIC_BASE. - Shrunk the size of GUEST_MAGIC_SIZE to 2Mb as looking on the Arm only 4 pages are used and there is no technical reason to have 16Mb for that region. (Maybe in case of Arm it is connected that Arm has these definitions in public header so more space is reserved to not "break" public API in future) - Update the commit message with a remark about grant table region in guest-layout.h. --- Changes in v4: - Reword the description: the stubs do not let dom0less fully "run" since construct_hwdom() and make_hypervisor_node() return an error; spell out these limitations instead. - Add a TODO comment to construct_hwdom() explaining that Dom0/hwdom construction isn't supported yet. - Add a TODO comment to make_hypervisor_node() explaining that returning an error breaks building of domains with DOM0LESS_ENHANCED_NO_XS set, and why that is harmless for now. - Document the constraints on GUEST_MAGIC_BASE/GUEST_MAGIC_SIZE next to the #define-s and drop the QEMU-based justification (QEMU is not involved); the base is simply an arbitrary non-overlapping address. Changes in v3: - Add /* Nothing specific to do for now */ comment to arch_handle_passthrough_prop(). - Use _ULL() instead of xen_mk_ullong() for GUEST_MAGIC_BASE and GUEST_MAGIC_SIZE (xen_mk_ullong() is intended for public headers only). - Fix GUEST_MAGIC_BASE from 0x39000000 to 0x79000000 to avoid the QEMU RISC-V virt machine PCIE_ECAM range. - Drop CONFIG_STATIC_MEMORY=n from the CI randconfig; now redundant since STATIC_MEMORY depends on HAS_STATIC_MEMORY which RISC-V does not select. Changes in v2: - Move declaration of p2m_set_allocation() to p2m-common.h. - Add __initdata for max_init_domid and drop initalizer for it. - Add CONFIG_STATIC_MEMORY=n to CI's randconfig to avoid compilation error because of guest_physmap_add_pages() isn't provided. --- xen/arch/riscv/Kconfig | 2 ++ xen/arch/riscv/dom0less-build.c | 7 ++++++ xen/arch/riscv/domain-build.c | 28 +++++++++++++++++++++++ xen/arch/riscv/include/asm/guest-layout.h | 12 ++++++++++ 4 files changed, 49 insertions(+) diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig index 48520588fe40..d8a348c0cf07 100644 --- a/xen/arch/riscv/Kconfig +++ b/xen/arch/riscv/Kconfig @@ -6,6 +6,8 @@ config RISCV select GENERIC_BUG_FRAME select GENERIC_UART_INIT select HAS_DEVICE_TREE_DISCOVERY + select HAS_DOM0LESS + select HAS_DOMAIN_TYPE select HAS_EX_TABLE select HAS_PMAP select HAS_UBSAN diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index d1a51b92936a..0801d7e25059 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -102,3 +102,10 @@ int __init arch_parse_dom0less_node(struct dt_device_node *node, return 0; } + +int __init arch_handle_passthrough_prop(struct kernel_info *kinfo, + struct dt_device_node *node) +{ + /* Nothing specific to do for now */ + return 0; +} diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c index d7613721db95..1e3abe259ccd 100644 --- a/xen/arch/riscv/domain-build.c +++ b/xen/arch/riscv/domain-build.c @@ -156,9 +156,37 @@ int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo) return fdt_end_node(fdt); } +int __init construct_hwdom(struct kernel_info *kinfo, + const struct dt_device_node *node) +{ + /* + * TODO: Dom0/hwdom construction isn't supported on RISC-V yet, so this + * is a stub returning an error. It must be implemented before a hardware + * domain can be built from the device tree. + */ + + return -EOPNOTSUPP; +} + int __init make_timer_node(const struct kernel_info *kinfo) { /* There is no need for timer node for RISC-V. */ return 0; } + +int __init make_hypervisor_node(struct domain *d, + const struct kernel_info *kinfo, + int addrcells, int sizecells) +{ + /* + * TODO: Generating the hypervisor node isn't implemented yet. Returning + * an error here breaks building of any domain (DomU included) whose + * dom0less_feature has DOM0LESS_ENHANCED_NO_XS set. This is harmless for + * now because Dom0/hwdom construction isn't supported on RISC-V yet + * either, and no RISC-V DomU sets that flag, so this path is never taken. + * It must be implemented before DOM0LESS_ENHANCED_NO_XS is used. + */ + + return -EOPNOTSUPP; +} diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h index 90603f06bb91..ceed9125e7e2 100644 --- a/xen/arch/riscv/include/asm/guest-layout.h +++ b/xen/arch/riscv/include/asm/guest-layout.h @@ -32,4 +32,16 @@ #define GUEST_RAM_BANK_BASES { GUEST_RAM0_BASE, GUEST_RAM1_BASE } #define GUEST_RAM_BANK_SIZES { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE } +/* + * The guest magic region holds the Xen-reserved pages mapped into the + * guest's physical address space. The only real constraint on + * GUEST_MAGIC_BASE/SIZE is that the region must not overlap guest RAM + * (the GUEST_RAMx banks) or the emulated device regions defined above; + * the exact base is otherwise arbitrary. Here it is placed in the unused gap + * below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM bank would work + * equally well. + */ +#define GUEST_MAGIC_BASE _UL(0x79000000) +#define GUEST_MAGIC_SIZE _UL(0x00200000) + #endif /* ASM_RISCV_GUEST_LAYOUT_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:09:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:09:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413338.1643635 (Exim 4.92) (envelope-from ) id 1x4JvT-00087s-Pr; Wed, 09 Sep 2026 15:09:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413338.1643635; Wed, 09 Sep 2026 15:09:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4JvT-00087a-Lk; Wed, 09 Sep 2026 15:09:27 +0000 Received: by outflank-mailman (input) for mailman id 1413338; Wed, 09 Sep 2026 15:09:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4JvS-00081n-9c for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:09:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4JvR-007zGT-MU for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:09:25 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1769d-bab6-0a2a0a5309dd-0a2a4505abf2-34 for ; Wed, 09 Sep 2026 17:09:25 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa176a5-4cb1-0a2a45050019-4a7de48c9c46-3 for ; Wed, 09 Sep 2026 17:09:25 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f705534so63176466b.2 for ; Wed, 09 Sep 2026 08:09:25 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d55b306sm792717866b.36.2026.09.09.08.09.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 08:09:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966565; x=1789571365; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=kR7V91A5R6Cs/mRRpc93dDWh4xXmrh8wNkBOBaA0yQs=; b=I0KOT90hWIQRGNXzHbmMQHfroBuPMc9X8UrpfhGWVDOKJxB9UkPrFOCf1QOSf71Ok2 Ggo9bbYFgppk5o2Kd6Y8y9zHHqJ8APFIX1FbaQxqEJ6tUViEJ/yYMGUwjCLg2u27OI5P LN0ZOCKGLCp7eL8ZjhDCw+icRqpsjavqtusjmEBDJY6W4yBOpnsb/IsL3em7PruJjMOh g0DjkSM2CTlPbbJAnPM6GfyXK6S+vIvZLOrDcv+VE2ycIxbuF8J0y5k+Qs/t993u3HNM YzRbnQKM07ohYv+158oqMxORgFhZucjQiKt1wB1cGuKNfaP+bE161iw3ut8kjoLhMPRZ Fu/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966565; x=1789571365; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=kR7V91A5R6Cs/mRRpc93dDWh4xXmrh8wNkBOBaA0yQs=; b=fskfZMJK4ip8hjieVWhH36N2cX9LwCRc7JS+gV8ObpvPWFpkt0nATFJr+cwyMdW6aT GWTbOQ2SHajFlzlmEXPt2V0ybfgUwG4eBsz+1DYB59p3svfeFUAGFVkSnX2ECUz9vOGV d+S/JtM4SEw2ztLiH5NW4Y0223usxiPseFfR+pG17Pw2XAE1XDbl0NGnW94/xdFCnJ6k lw43tBhiJh44ZrvRh7UPxc553lZ7K5BUuwS314bLWfJP+l87rGCjLTp6TU+OIBz7X8KD mtGUAHAUQgg7jbkuNYHgVxdF07tARW8XgNjlGWdj18gy0tBGnybHoRJFgw97AUxEHdoV XB1g== X-Forwarded-Encrypted: i=1; AKwUvBwrnz4LENMuahdEsGM/qK5GBssMBF4pvJUXMEHghUCn6uM4NLcdrMPAkxCpsf0DFoVENANPWV3PX94=@lists.xenproject.org X-Gm-Message-State: AFuF++kGdstDKqCwdqGanJ+k1gKo1jsW0Yc+dVJMXyR4UCdoox2MiePJ Jg/GSVi/+lLz2NzNogAynHbI5slrEpBl+oE7bjbYeu45eESA+eWSJkF+ X-Gm-Gg: AYBFou0jclP4/d/JbAE6bi5VhnttqUsrmp98sHGC6Eno+E0G1uwhfk6kSJF9VGxqm/n zhlILSw/JMBKmixmgqE+N2ZXYxG1iu1bG2lSyh8gMvRoE3X8kcDMSNWWVRoiEWHxv0ubuva9MTZ qs+5HkuOuMcgsbGVpWW8cqpoEqEQ7BwJe9U52e0qWqXsHf/fW8gJQuLtP/cLgcmscam3F1N8YxF heCqRdKSSnse/hF1ActKcY9gL0xZTx9U69csk0g4j+aEnAt6b8uOQAk3wWqe7mMFh3u+9sJXzct qqr2paOFjOSESbRa0Z2hVShVIuC0nwgLgVIP51ngOJ1c7f2BN3zmTZjakP6Y1XUVzG21DP2Lv82 ArTz5odW+Bo2HkiCghnOWqrSPwF0eEvnopzxSr3DV0mL935pQuW2dtJzCrYh5FcDAukMxrH+Uwx 7iGPMgz/WmXpflon4mnKLg/9BparOaJMrvDvbOibOYxBGneXXwFAhYlCJssc1oFCqgos2BpzwK4 DkidecEs5YfAw/l4dRM7bCARAIuY8Y4 X-Received: by 2002:a17:907:c244:b0:c26:1648:a076 with SMTP id a640c23a62f3a-c2941be4cc7mr64078666b.49.1788966565018; Wed, 09 Sep 2026 08:09:25 -0700 (PDT) Message-ID: <19aae90d-bd5b-4637-828c-bb5164ba4191@gmail.com> Date: Wed, 9 Sep 2026 17:09:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 18/39] xen/riscv: add guest page fault handling stub To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.com> <35aecc68-d16e-4350-9aca-101de2b21c1f@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <35aecc68-d16e-4350-9aca-101de2b21c1f@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1788966565-F76BD2A1-0321CD91/10/73395122804 X-purgate-type: spam X-purgate-size: 8318 On 9/8/26 4:10 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> --- /dev/null >> +++ b/xen/arch/riscv/emulate.c >> @@ -0,0 +1,179 @@ >> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >> + >> +/* >> + * RISC-V instruction emulation for trapped guest accesses >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* >> + * The hardware-reported details of a guest page fault, gathered once by >> + * handle_guest_page_fault() and passed down to the emulation of the faulted >> + * access. >> + */ >> +struct guest_fault { >> + /* The guest register state as saved on entry to do_trap(). */ >> + struct cpu_user_regs *regs; > > If the comment was true, this could be pointer-to-const. I think it can't be pointer-to-const as emulate_load/store functions wants to change PC register after MMIO access emulation is finished to not trap again. Regarding the comment itself I agree that it isn't fully true right now because there is no trap from guest and so no guest registers save/restore but it will for sure be and we can't not to save/restore guest registers when do_trap() happens. I will re-word it to: /* The guest register state */ > >> + /* scause: a fetch, a load or a store/AMO guest page fault. */ >> + unsigned long cause; >> + /* >> + * htinst: the trapped instruction in its transformed form, or one of the >> + * special values (zero, or a pseudoinstruction). >> + */ >> + unsigned long htinst; >> + /* htval: as written by hardware; see resolve_faulting_gpa(). */ >> + unsigned long htval; >> + /* stval: the guest virtual address of the faulting access. */ >> + unsigned long stval; >> + /* The faulting guest physical address, filled by resolve_faulting_gpa(). */ >> + paddr_t gpa; >> +}; >> + >> +/* >> + * Is @htinst one of the pseudoinstructions reported for a guest page fault >> + * taken on an implicit memory access done for VS-stage address translation? >> + * >> + * All four values are recognized regardless of the hypervisor's XLEN: the >> + * width they encode is that of a VS-stage PTE, i.e. it follows the guest's >> + * paging mode (4 bytes for Sv32, 8 otherwise). On RV32 the 64-bit forms >> + * simply never occur. >> + */ >> +static bool htinst_is_pseudo(unsigned long htinst) >> +{ >> + switch ( htinst ) >> + { >> + case INSN_PSEUDO_VS_LOAD32: >> + case INSN_PSEUDO_VS_STORE32: >> + case INSN_PSEUDO_VS_LOAD64: >> + case INSN_PSEUDO_VS_STORE64: >> + return true; >> + >> + default: >> + return false; >> + } >> +} > > This feels fragile. New pseudo-insns can appear at any time. If the value as > a whole is non-zero, aiui the low two bits being zero indicate a pseudo-insn. > In which case enumerating pseudo-insns we are currently aware of isn't > necessary. I will write it simpler then: /* * Is @htinst one of the special pseudoinstruction values, reported for a guest * page fault taken on an implicit memory access done for VS-stage address * translation? * * It is enough to check only bits[1:0] as according to the spec: * * The value is one of the special pseudoinstructions defined later, all of * which have bits 1:0 equal to 00. */ static bool htinst_is_pseudo(unsigned long htinst) { return htinst && ((htinst & 3) == 0); } > >> +static void inject_access_fault(const struct guest_fault *gf) >> +{ >> + struct trap_info utrap = {}; >> + >> + switch ( gf->cause ) >> + { >> + case CAUSE_FETCH_GUEST_PAGE_FAULT: >> + utrap.scause = CAUSE_FETCH_ACCESS; >> + break; >> + >> + case CAUSE_LOAD_GUEST_PAGE_FAULT: >> + utrap.scause = CAUSE_LOAD_ACCESS; >> + break; >> + >> + case CAUSE_STORE_GUEST_PAGE_FAULT: >> + utrap.scause = CAUSE_STORE_ACCESS; >> + break; >> + >> + default: >> + domain_crash(current->domain, "Impossible cause (%#lx) in %s?\n", >> + gf->cause, __func__); >> + return; >> + } >> + >> + utrap.sepc = gf->regs->sepc; >> + utrap.stval = gf->stval; > > Would there be anything wrong with putting these in utrap's initializer? It could be initializers. I will use utrap's initializer. > >> + trap_redirect(&utrap); >> +} >> + >> +void handle_guest_page_fault(struct cpu_user_regs *regs, unsigned long cause) >> +{ >> + struct guest_fault gf = { >> + .regs = regs, >> + .cause = cause, >> + .htinst = csr_read(CSR_HTINST), >> + .htval = csr_read(CSR_HTVAL), >> + .stval = csr_read(CSR_STVAL), >> + .gpa = INVALID_PADDR, >> + }; > > At some point RISC-V code will (very likely) also be scanned for Misra violations. > The csr_read()s here violate rule 13.1 ("Initializer lists shall not contain > persistent side effects"), and I think it would be better if such was avoided from > the start. I will do the following then: struct guest_fault gf = { .regs = regs, .cause = cause, .gpa = INVALID_PADDR, }; int rc; gf.htinst = csr_read(CSR_HTINST); gf.htval = csr_read(CSR_HTVAL); gf.stval = csr_read(CSR_STVAL); > >> + int rc; >> + >> + /* >> + * A guest-page fault may arise due to an implicit memory access during >> + * first-stage (VS-stage) address translation, in which case a guest >> + * physical address written to htval is that of the implicit memory >> + * access that faulted - for example, the address of a VS-level page >> + * table entry that could not be read. (The guest physical address >> + * corresponding to the original virtual address is unknown when >> + * VS-stage translation fails to complete) >> + * >> + * In such cases htinst reports one of the pseudoinstructions recognized >> + * by htinst_is_pseudo(), and the fault requires separate handling (since >> + * G-stage translation failed on an unpopulated/unmapped guest physical >> + * address during a hardware page-table walk). To match bare hardware >> + * behavior, we must inject an access fault of the ORIGINAL access type >> + * (Instruction, Load, or Store/AMO) that initiated the address >> + * translation. >> + */ >> + if ( htinst_is_pseudo(gf.htinst) ) >> + { >> + inject_access_fault(&gf); >> + >> + return; >> + } > > I.e. you imply that guests won't put their page tables in MMIO? That's > fragile imo; I have seen OSes to use video frame buffers for all kinds > of (transient) purposes, for example. I think it is okay for now and if it will a real use case then an update of this code will be needed. > >> + resolve_faulting_gpa(&gf); > > Since the function is only a stub right now - how is one to tell whether > this indeed can never fail? It can't be tell. But what is wrong if it could fail? (Actually with current implementation introduced in later patches you can find it can fail if a necessary extension or software page walk isn't introduced). If we can't resolve faulting GPA address then we can't continue to work and so at least domain should be crashed. > >> + switch ( cause ) >> + { >> + case CAUSE_LOAD_GUEST_PAGE_FAULT: >> + rc = emulate_load(&gf); >> + break; >> + >> + case CAUSE_STORE_GUEST_PAGE_FAULT: >> + rc = emulate_store(&gf); >> + break; >> + >> + case CAUSE_FETCH_GUEST_PAGE_FAULT: >> + /* >> + * Guest is trying to reach unmapped/unpopulated or G-stage PTE doesn't >> + * allow execution (X=0). Generate fetch fault in this case. >> + */ > > Is there perhaps a comma missing before "or", to help parsing the sentence? I will add one. > >> + inject_access_fault(&gf); >> + rc = 0; >> + break; > > Simply "return" instead of the latter two statements? It makes sense. I will do just return. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:16:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:16:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413392.1643653 (Exim 4.92) (envelope-from ) id 1x4K2C-00033L-Jq; Wed, 09 Sep 2026 15:16:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413392.1643653; Wed, 09 Sep 2026 15:16:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4K2C-00033D-G4; Wed, 09 Sep 2026 15:16:24 +0000 Received: by outflank-mailman (input) for mailman id 1413392; Wed, 09 Sep 2026 15:16:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4K2B-000336-8x for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:16:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4K2A-00CvId-MD for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:16:22 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17835-8faa-0a2a0a5109dd-0a2a45079ebe-30 for ; Wed, 09 Sep 2026 17:16:22 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17846-b4ea-0a2a45070019-4a7de44cb5bd-3 for ; Wed, 09 Sep 2026 17:16:22 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a60591ae54so1999389a12.3 for ; Wed, 09 Sep 2026 08:16:22 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788966982; x=1789571782; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=pmK9naUMbOofZXsZTLQyyxB70Co/ElUNF72aKPXn/H8=; b=i8SMFLYLTsBjl487V7MNH5F3VWRKW11sToSG0c24UaNBwfVqQ2D5D+rhm0L58Jb50E ijCtSqaQsInXgoQu0oOJHTip6jfTv+mck9esKtEJcF7wLGky8p74Lmg/uTzxIcTFwyy9 sPutq6DDYMIp93ScZqy84mASqo2eJotcrbmnNSRl8aFio9oj5onwSxEzbFE7zkQIIprt 3ULyrSgNbQXMHTyGnzlb1aZAmoqpzLxvpY+3qeIe3zSPV+UGDuqtoYfx4PC4hu2WfPks 5xyuYjd/ZtRh9RLS8KSJu7QW+nxVmffpKgL0Xlp9jwbAssrh2zRdNAuyZgzt5Y3DwjW5 Ixqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788966982; x=1789571782; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=pmK9naUMbOofZXsZTLQyyxB70Co/ElUNF72aKPXn/H8=; b=AGx+O2ikbIJn2reGoek3f/4SwkAqol85B0wv5GL46/Xq/nQg1W3O0VX1wJfBdAFop0 Pas6BH/nbtgXYr9lsFJ8NyonKjqX7O8i7+PER+LM8TG9eOFpaHFQKiXF0djXUP8+ZJvZ g+uUUqemjtz2BQvAUCBAqZR4Laet5FiM7W+xEsn6ikiPOu4Ow/wrEnoa2ILuQDqPt+YT 2wtduiGUlHhjxODDs3attMcrbUSOFHVzns+7N1h/wgKHSY3pcfenFxhqDflxOIXvvLyo oN92UIqeqqXN5Pk54DLQ2Wk9qbRsYn4IKsXJA2J7yRZodfH2gZsabwcliNk+JGTTQ7F/ 3/kQ== X-Gm-Message-State: AFuF++mkoQz2zCBr6rOBmn953QtBn+fe64XCc/P7HAZNvv2xDMEl5WKq oBc5q2yZFPqFsTaYxsIeWFsQOJDM2/rYlXy6Hjhs6hEaHR5+IGsY1CnHfr69TMnj X-Gm-Gg: AYBFou2mONKv8P4oUJsuyYhn4QIgXpjA2OiKP60YUrXJysaVygf6zl2Q9l5M5dmMs01 MwRylESge+MdMyeJvtiGi1xpZbIkZ7A6uXgxSLIGimFKhQkm5QKyk2/EpCxxmgEmUSUbAd11paI ubSbiT+moQkG5wcHdC4sBYWj9CWs8/fRTqV+cis4JIN/3g8tTxR8VFwCMNbvK1rbXCH+9fNzmp0 gS1gXlO0NMY1lwDI2kxvIfkh9zEmr4ozqhd++udhxjVQ7hFCMOj0+NV7P9GEwea42ZRSVu1POL3 eQkvmAifCxsh55qe5A7GA6Mx1qFw2/2497AJf7EmWseZRDb3vZStHg4HzSwjGRFQL/8uBtMDmLc ESpkCEWLZaBRsvVWExuYwBQJT3M14+o5eSSIxr4sVjKwLyRCNUXqf55MeLCB6yC936M12ipGbvn RcbcYcHaboUaejCm94blyHCIBMq18rmLgN6pxQbY9Q06W2lQmcTY8NTCHmvR6He7oBsqPzlJFOu InmSm3tUg5RG03BLt0= X-Received: by 2002:a17:907:7214:b0:c25:ed6e:7edf with SMTP id a640c23a62f3a-c292b138196mr498302266b.11.1788966507316; Wed, 09 Sep 2026 08:08:27 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 09/20] xen/riscv: implement make_intc_domU_node() Date: Wed, 9 Sep 2026 17:07:27 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1788966982-A5AC0AE4-42CEE675/10/73395122804 X-purgate-type: spam X-purgate-size: 3439 Introduce a RISC-V specific function to create an interrupt controller Device Tree node for DomU domains during dom0less build. Add make_intc_domU_node() to the dom0less build path and wire it to a new generic helper, intc_make_domu_dt_node(), which delegates DT node creation to the active interrupt controller implementation via vintc_init_ops. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v5-9: - Nothing changed. Onlye rebase. --- Change in v4: - Made local variable vintc pointer-to-const. - Add Acked-by: Jan Beulich --- Changes in v3: - Use const struct vintc_init_ops *init_ops in struct vintc. - Drop redundant intc_hw_ops check in make_intc_domU_node(). - Drop NULL pointer checks in make_intc_domU_node() as we can't start domU without properly created interrupt contoller node. --- Changes in v2: - s/intc_make_domu_dt_node/make_intc_domU_node. - introduce separate intc_hw_init_ops structure for init operations. - Return -EOPNOTSUPP instead of -ENOSYS. - Drop const for kinfo argument as it could be changed by interrupt controller node creation code. - Refactor make_domu_dt_node(). - Make make_domu_dt_node part of vintc structure as it looks more logical to be there. --- --- xen/arch/riscv/include/asm/domain.h | 2 ++ xen/arch/riscv/include/asm/intc.h | 10 ++++++++++ xen/arch/riscv/intc.c | 8 ++++++++ 3 files changed, 20 insertions(+) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 8ae01a5e4dcc..bd43ed08c22c 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -97,6 +97,8 @@ struct arch_domain { struct paging_domain paging; const unsigned long *isa; + + struct vintc *vintc; }; #include diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index d7b34fc15ad1..a4e678fad90b 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -16,6 +16,7 @@ enum intc_variant { struct cpu_user_regs; struct irq_desc; +struct kernel_info; struct intc_info { enum intc_variant hw_variant; @@ -47,6 +48,15 @@ struct intc_hw_init_ops { int (*init)(void); }; +struct vintc_init_ops { + /* Create interrupt controller node for domain */ + int (*make_domu_dt_node)(struct kernel_info *kinfo); +}; + +struct vintc { + const struct vintc_init_ops *init_ops; +}; + void intc_preinit(void); void register_intc_ops(const struct intc_hw_init_ops *init_ops); diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index 3600d23bdb5b..e63da5e22efc 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -3,6 +3,7 @@ #include #include #include +#include #include #include #include @@ -72,3 +73,10 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority) intc_set_irq_type(desc, desc->arch.type); intc_set_irq_priority(desc, priority); } + +int __init make_intc_domU_node(struct kernel_info *kinfo) +{ + const struct vintc *vintc = kinfo->bd.d->arch.vintc; + + return vintc->init_ops->make_domu_dt_node(kinfo); +} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:33:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:33:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413416.1643661 (Exim 4.92) (envelope-from ) id 1x4KIR-0006pV-To; Wed, 09 Sep 2026 15:33:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413416.1643661; Wed, 09 Sep 2026 15:33:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4KIR-0006pO-Qi; Wed, 09 Sep 2026 15:33:11 +0000 Received: by outflank-mailman (input) for mailman id 1413416; Wed, 09 Sep 2026 15:33:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4KIQ-0006pI-AF for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:33:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4KIP-003HI1-Kp for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:33:09 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17c27-bab6-0a2a0a5309dd-0a2a4506d522-36 for ; Wed, 09 Sep 2026 17:33:09 +0200 Received: from [52.101.57.15] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17c34-195a-0a2a45060019-3465390faec6-3 for ; Wed, 09 Sep 2026 17:33:09 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5557.namprd03.prod.outlook.com (2603:10b6:5:2d3::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.8; Wed, 9 Sep 2026 15:33:01 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Wed, 9 Sep 2026 15:33:00 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=szsjK0mfuc6lLH/T57LuntXlcnQknbX7kPE+clF+SUXzyKC6zofrYqmJaoayrdgeNF4CU2iJHhqdXtbUfK1hAoWvBeEoGjdg3YGSR1xcULbCDEamGdVqeAxeqSGRqvEFVAHg5d6EkFijEr6k2wpUsB8reINm78FK8YrLlmNl8UCdJLx4DISSOTFWBQuGXEc8lm4eAbtTmS5nc4wfvqE0gvI12Y/8fo/K/QjCv657PC+68BmEsu0rcxa8Ad6XVl8GAZAXRpJtvQjIgDRsA97x1SJMAAr5ZeeH86UFypAo6dAG+LQMbU6y4xc4vTp46iTDherpMLeHy+EteV7KVwebBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qBKbdE+f+zhhwCRgFByge8UKwgCiEt7GhX475so68Do=; b=YFGs2uw7A0GsCzqhOgqtyXmy0737RBlitYwjz5GxBP0wil/vZ1bsuBpvw+yvuYOWhU8FdHI7i6abAdcoLg2NFA2wKRLJN+sSKAkg6ny+06jT2SZrAPk10wX3GufPn227B4m+W3PzFuEfVix7y73c/iUlXOmmA/1mSYJV2WAhVcjxGDZ7KkRJzNEk1Nv2zWWOy5eGdjTfnBHDIgcsjnL9Jjb4EC9ruy3C0xDmXZnfgacGjZj5aJfFh9Z4QNkhZseU35LM9b8kolnL1xBojpd5dU2lNyhBn7KUEsxux07mfuxdA4ZyRexTmaH43oevymTAQBoDvaYaHpamsKUogOLJ8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qBKbdE+f+zhhwCRgFByge8UKwgCiEt7GhX475so68Do=; b=dR51EkET2X8pBdhW+Da/r/AEAm6gvRSYi/NyT89IwaAnAQ9sYRdf4t3BNYu72sGzeP4hAdVMC5x13pHTQsXoA8gypfy7VlABIR9GgDsvLczZwW77M7h8nq4/vrcMmYR+UhzREdKmwix3akug07bnalz/AHaaPPsDVI9+iADx98M= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4413f32d-3c76-4248-b7f9-577576bb4ea2@citrix.com> Date: Wed, 9 Sep 2026 16:32:57 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3] x86/vmx: Avoid pausing on HVM_PARAM_IDENT_PT in additional cases To: Teddy Astie , xen-devel@xenproject.org, xen-devel@lists.xenproject.org References: <1788956067.8631fc262581453bbf619ec5b2062170.1a086174641000c4f3@vates.tech> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <1788956067.8631fc262581453bbf619ec5b2062170.1a086174641000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0011.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ad::19) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5557:EE_ X-MS-Office365-Filtering-Correlation-Id: 17bc1b9a-7f66-4c97-301c-08df0e87a1d4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|5023799004|11063799006|56012099006|3023799007|10067099003|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 4GVOfrcJiz7zoC8abEnqTX15rEq/xTD9xMjh/p2Zi9+3VLDol+cGRvTi998FzFzIzafhpuWb9F8QnR9kx6RataiiCzH6pl90CtsxBTyiQdqEikBigVLtkurqQsufBdlvkx3HSgKBgL/FTgiVDowf/3+vReoIxr75UzAvZaN3o877foS5ghJ2GxI89ntQ2smvC/Z577MCSei2XwLaEy5EdMhh32QLW8QQA5D/I4JyWRMU8AEDkFWPAsqfQcPxUQX2pCD0WQjg4H3bmRAlXHENv6hHyX9Z4nINW7GSsxnCnNiRM93epPw623E9Up/UYW++S6RlxXl0p7YoGWv1LpVfly9nw+hbjZS4ljcJZNyRafKToip/nfjYZCGzu8/96LJnjd37KQ9W+1IlGz89z1cas/JOBYRRz7ZP/5Xe+aFVhrg22okkmIUMlrrvvV6zxl69BQhTUwYRlIs/Ixi/AqgUp8LQWWS9jeFu0FXhiKF2tKns/2YATnHFxuTdrxLGVDrxWGN0tbadEDfDNeaKqLbtpJAC/QWxsEh/dtXrvHfmzEXV1veU/5U87+SU5Z7JgxhzZWDgJldBMQ5RRTEvaDlgEA9e6Fo9L72gi7X3b55Z9+xoq+R/7A6bjhnQaviSUFv2vi/+9Oz3IKKP9MHLkN6GwU+rGHXreKzWFepx8XEJ2Ig= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(5023799004)(11063799006)(56012099006)(3023799007)(10067099003)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SEhKajFCL1RSOER6ZWp4cEd3MExyVnQ1aDI5TFpIZDVFOFVkaWg3YmJ5Ylcy?= =?utf-8?B?THUrNkhxd2poZ0c0QjBESXhQM3NwLytjVVFnV05hZllrRmlEYjB1d0dBazJP?= =?utf-8?B?OXVKdTMySjlwVmNNaWxMd2pGQWNYeUZuRzc2eE1UVlpLRkVkcVVUZzNuMHJm?= =?utf-8?B?TnpkYVNFV09jWjNpQ2t4dEc3dmtZSVpzY1ZBRVkwK1pVSzcrZ0hQMTlsK1p2?= =?utf-8?B?d1AvN3dPQWRWcWFmQjBTZEc1MTNXK1hZVG14TUJaWktMYzN0TFQrLzdVWU9Z?= =?utf-8?B?L0kwMWFpSFBKVExiV3V0WjdiNmFtR1J4bElCUjFOZ0JpeUR6ekpzd0M0Q1cy?= =?utf-8?B?TWNlbnREUjlsMzd6bVl4Y2VhUHdVdDdqcTRhWmNYZ0FDMXBzcm8xZW5CUllC?= =?utf-8?B?VzcrQndJZ2JVZkcxeVJzS2RZb2dGZjV1R1c3NWR2citzeWpnM21ONzFVYXpt?= =?utf-8?B?S3VNa0xjUjR3TXNzbVRkb21WUEpYaUNraG9FYm1DM0FiQkl2TzJseHJkL0pv?= =?utf-8?B?NytwdHBZc25YcHY5Q0l5aXNZSWR1czlBOEFVeERqTmx1WFZpMzdxbS96RlJI?= =?utf-8?B?c0QyK3l1YVF1aDJmVVNqeXNZeDdLOFd6RUhjSU5ZZGVSL2hkSDYvQ252S2Vk?= =?utf-8?B?Yk9Ebm1rdTN4VXFNcHUyNGZDdGVzdFJrOXUrdy9KSUlubk1lRzZaU2wraTFp?= =?utf-8?B?TjdNZEkwdE5IOTVpUFBwVkJGWTVWbjFkNWRUa2VLM3UwaVRaY041RUErWHM5?= =?utf-8?B?NFJGTFVYNVBURjR3Ynp5eXFEQU5KVGYyaThjYzFrZ0N5MGlFYlhtaUtldkxv?= =?utf-8?B?ekpMZlNlNzE2Wm5RMGFObkdlakFYNHM1c09Fbmhmd09ESjYweVh3VFBJV053?= =?utf-8?B?Zm1ZRTNXeUVHb1ZXRFdMMWdXZEd2U0d5OTIvRzlRSW11YnNFUkpqMkhqNkc5?= =?utf-8?B?VUp4UDQzdnFvMXJCTVhrYjZQcHRnUnAzb2xqbWEyVGhDdmxobGJQT3pOQ2hq?= =?utf-8?B?Q2ZlRlIxZFg4UnFETkJTVGY0elM2UDRscGxtYXFJWkFDbDV3cCsrNGJRRXZH?= =?utf-8?B?NVNNcjdxNHNBck1KRkVPWENQQU5CNzZxSnRRYlcvNU9nelA1WDhBeWd6akZB?= =?utf-8?B?ODM3NVZCT2ZNK3NGU1o1ak41Mm0veFZiZVpweThSMnd4YkVvMEJCQ1lsdUdp?= =?utf-8?B?b09kOVZqQ1JqSXhOTHZzbmJHTjFGYzVUM1NBRjVpbUJzWjQ5dXFXemZzSzdG?= =?utf-8?B?L1d6dVFsdUpRTkljWW0rN2N3U29wU0JBYkxuVTR6YXh3emhJZWNHbGh0WlND?= =?utf-8?B?akhWSW8zVTIyMFJGZzd3ejZiWGMxdk1kZUNEMC9uR0xkN092U1pYem82eU41?= =?utf-8?B?UGplVXp4Q3lWeCtOVjVNZFNiMHJOSmx2b3IvSUROUWpNekQwWENOMk1HR1cr?= =?utf-8?B?WWFLc3dnVUtzZFk2dm1qaGJTT1MxVndJUmhYMHZDemF1Sng4L1lYa2ZGQksr?= =?utf-8?B?N3kzcTM0YnkzTzZ0dk1DYnZjSnV4aC9oNittV3VHMnFWd1YrUkFiVDEvZFlE?= =?utf-8?B?Sm5jaE1BMmZCeE15SHdxaVdhTDFHazloR2lxVHVHYXZmSHhaSjhzRjFkK2Rq?= =?utf-8?B?OWFoQ1RLMXAzbWlCZ3gxMzhlWnJ1SDhkejh2WS9pRU1Dd3hWVndma3E0NWtL?= =?utf-8?B?RWJ2R1BEWTc1Y1puVWl5VFhobUNZWTF4MXVETEFpRE4zci8rb1hpYW0zNVVE?= =?utf-8?B?dFV1K2U3ZFRoSG02YkVVMmtMUGJHTkoyd0tXV3ZFam1vLzJGUThhSVo4a2Vz?= =?utf-8?B?S3Y4MlZsR3N4ZEV2OFVtVDBuT1gyY2lOS3lEK3JPdXgwdzRYL2FEYkhhRjVF?= =?utf-8?B?bnU1aytXazZCSlBSUFVqUUpkS3dVSGxPZDJadi82NW9BbXl6T0dtWHJJU2hq?= =?utf-8?B?bGdEOS9EdTVRa2VKU2s3dDFESFRoQkZMZUh1TDhUN3VDcmVvTWU0TTNkUkpx?= =?utf-8?B?aWdGQnl4am50QWNwWlBDallwYktvU1UzalI5aDRiK2xzekhQc0R5YnkreDhK?= =?utf-8?B?WGhlMDFvWWNSQ3M4N0RFLzc2T1VlREpQdWNCaWg2ZjIwNzZXaHRrM05HMWtE?= =?utf-8?B?b29Xak9IaW1DSUV3NHVNelVoNEM2ZHBxWC9QQVdaMVNmaVNQMHlpTDB2cWo2?= =?utf-8?B?bWI4ZGZCRXAyUzlLVjhyNlRWajJwdmluY2R5Z1NXMUs0T3FnLytxdVdRTGZ0?= =?utf-8?B?TGljQkx3OWdwZ2xQUjNNY3RMOTRrcjFNOHlsR1lSbVhONG9KdDhXbzFhdXpB?= =?utf-8?B?K2REbUxkSTFiWVpTVkFjaW0rMnlwM2hCUE5UdVFnSVpOdHdQNFpadz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17bc1b9a-7f66-4c97-301c-08df0e87a1d4 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 15:33:00.9195 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: p7v4XUE+2uyMpdRckarmLahSBrK8X3fVIneUyINkh8uCG8BxTtZpCNdgJQFXyHuzy6xn+b99JfnMhle3WFliRxNKnAeV5pXVD7ioL4AbTfI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5557 X-purgate-ID: tlsNG-16d1c6/1788967989-F74C977B-1474F329/0/0 X-purgate-type: clean X-purgate-size: 2570 On 09/09/2026 1:12 pm, Teddy Astie wrote: > When settings HVM_PARAM_IDENT_PT, skip domain pausing when : > - there is no vcpu > - unrestricted guest capability is used > > Signed-off-by: Teddy Astie > --- > Regarding checking for hvm_paging_enabled(v) (proposed in v2 review), we can't > as hvm_paging_enabled() is vCPU specific, and vCPU 0 may have a different value > to another one. > > v3: > - rebased patches with staging > - adjusted formatting > > v2: > - rebased patches with staging > > xen/arch/x86/hvm/hvm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 9a4147b62e..2981a61cee 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -4237,11 +4237,14 @@ static int hvm_set_param(struct domain *d, uint32_t index, uint64_t value) > rc = -EINVAL; > break; > case HVM_PARAM_IDENT_PT: > + v = domain_vcpu(d, 0); > + > /* > * Only actually required for VT-x lacking unrestricted_guest > * capabilities. Short circuit the pause if possible. > */ > - if ( paging_mode_shadow(d) || !using_vmx() ) > + if ( paging_mode_shadow(d) || !using_vmx() || !v || > + vmx_unrestricted_guest(v) ) > break; The comment isn't really correct, and using vmx_unrestricted_guest() isn't really correct either. How about this instead:         /*          * IDENT_PT is needed only for Nehalem-era VT-x, where EPT is          * available but Unrestricted Guest is not.          *          * The identity pagetable is configured by the toolstack or hvmloader,          * and the param needs to move in the migration stream in case the VM          * lands on an EPT && !Unrestricted system.          *          * Nothing, besides recording the value, needs to happen other than          * for VT-x EPT && !Unrestricted VMs.          *          * TODO: Unrestricted Guest should be a domain property not a vCPU          * property.          */         v = domain_vcpu(d, 0);         if ( !using_vmx() || !paging_mode_hap(d) || !v ||              vmx_unrestricted_guest(v) )             break; The case of no vCPUs isn't very interesting; in that case, pausing the domain is free.  We can at least note that the data is in the wrong place, even if we don't fix it yet. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Sep 09 15:34:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 15:34:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413425.1643669 (Exim 4.92) (envelope-from ) id 1x4KJE-0007Rj-8b; Wed, 09 Sep 2026 15:34:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413425.1643669; Wed, 09 Sep 2026 15:34:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4KJE-0007Rc-63; Wed, 09 Sep 2026 15:34:00 +0000 Received: by outflank-mailman (input) for mailman id 1413425; Wed, 09 Sep 2026 15:33:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4KJD-0007RT-GJ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 15:33:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4KJC-00CxjB-Ss for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 17:33:58 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa17c66-8faa-0a2a0a5109dd-0a2a4501beb4-2 for ; Wed, 09 Sep 2026 17:33:58 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa17c66-5984-0a2a45010019-4a7de44cc0ff-3 for ; Wed, 09 Sep 2026 17:33:58 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a6249b76a8so582740a12.2 for ; Wed, 09 Sep 2026 08:33:58 -0700 (PDT) Received: from fedora (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c261f673000sm709991666b.24.2026.09.09.08.08.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 08:08:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788968038; x=1789572838; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=EHF1dWy+i1zH0Zv8Fgb2tmZxyyTHJFjQ0vjmPRcM214=; b=P1v5vTKInZqBUHWgGrguDpfjmOaqO5VjPRnUG4dD05youW0WmOOSzn+kcmmz4PMLmp Wc4cYqDF4EurXS7soHfGLvPQIGPrPHeJGOckm7QE7AFV7lcO/y0YRvUwtm4YQDyGcoeD ocDLqe5SJbH40/LvLiZJpyXr+MdqqneBVxI3ZnxbxkdkE0inzQ0dCrrq4FSK72o48Xvc +lpWUQKP8ewdWFBx46lvy0kAPpYa/f25bNLBt4l1YWIqA1MymxLYt/Cn9tR6NpsT3NpC XHP9DEVJkBL658Qy8Thbfy9/15fBINFaL292OKAtN/5pIgigWoM+ccn1pYyPhfPS8Cmh 7YuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788968038; x=1789572838; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=EHF1dWy+i1zH0Zv8Fgb2tmZxyyTHJFjQ0vjmPRcM214=; b=n2kDFrv3NFgiH0TmAXw+igMNqYLjUp7Bh8j8la1cjLKfu5RTeJ5cfjKJ5lnYxF0VaK TLMkAVh4GnjVVp+rS0rA9nMnErM5gi8iktgQcNFzZsvR3IYxMLJF9BnDrTLUet80ll0k Ph6EC8rL4pGYQUBvnG0j+miFqVz7TxRaeCfynJNsTcWpLKGBucC9LclH4PhE+awmEOz7 Wp1n8P898wzZp0yym65AN+v7j9LqKlc4IEKQlE1NYnum/GKXwHecfKJwwSmcoLvokPVK +VcBOFHPlOTQffeVaj2aPBXwtsq9YeFZnvKmzPaFY2AaG/780OC+S8RZNt37ETO1m0jm DvFg== X-Gm-Message-State: AFuF++km/EBhXsOf8FWhtxTZuBa7UWvFyVHCZ4+wByrGDspm2pow5XPL jgIJYjgdtEdmEg5tcwm4S4z9Lbzfw1sWxaokYjQMScMg2gC226UY+6buOXXYXYd4 X-Gm-Gg: AYBFou0ADIJqe0rzw0yAJ8P91JWIm08YtXkA0048GcC4bHn3twkLQhEVLLvlQK9iUCH hr2hFR1+/IQTGbdJs5IZInQPMul6C0QpeIoJw2z522JufucfBDQ2H3DAYfaIIZs9wFTE4sVAu7b EFIRrfThx02sbY3Ul/TYJNQPLRAaXA0aO4YJ7ZuGS6CXajzXFPRPCA0qbz58M1OKReoe4U2zHaz WZTMKGBIH6keaIkKDfcDXs+J1fP7ZhxI/xcIxPMwV9euvIdbc14Yfeiuspmah5e8pivojBveecq IJy0xjmgYwO/eXKORumf6NJbug6r7k9iAOV55g1mrPwn1cIDF555WDNylpgbNcM8ZAkmATC00z6 InRsnENKDdGhB4mLYkiCZVdIAx4YK1eIyl9MDXtbFLfi3qD7NUUxTpnnlMacXr5+kmOX79g8YQ4 SKiiI/6mjd7NqDeG7FaDM7lIQKdVLbsNB9z2sF4zClKw7D2RwmnTK78p4/JYwZVtg0Q2nWNnyC4 kc/BOtpQyvAsa+6S+U= X-Received: by 2002:a17:907:c408:b0:c26:1648:a075 with SMTP id a640c23a62f3a-c2941be4cddmr61403866b.48.1788966500181; Wed, 09 Sep 2026 08:08:20 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 06/20] xen/riscv: implement make_timer_node() Date: Wed, 9 Sep 2026 17:07:24 +0200 Message-ID: <63d5e0a7f9e8d9891b248d503c33498a5bca4225.1788876411.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1788968038-BE664757-B6A07A71/10/73395122804 X-purgate-type: spam X-purgate-size: 1618 Generally, in DT for RISC-V there is a document which describes a timer node (riscv,timer.yaml or sifive,clint.yaml), but the Linux timer driver is declared with TIMER_OF_DECLARE(riscv_timer, "riscv", ...). It matches the CPU node (compatible "riscv"), not the timer node itself. It then calls of_find_compatible_node(NULL, NULL, "riscv,timer") only to read the optional riscv,timer-cannot-wake-cpu property. Since Xen does not care about that property for now, make_timer_node() is implemented to return 0, as no timer node needs to be created for RISC-V guests. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v3-9: - Nothing changed. Only rebase. --- Changes in v2: - Acked-by: Jan Beulich - Update the commit message. --- --- xen/arch/riscv/domain-build.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c index 1af4c48fb30c..d7613721db95 100644 --- a/xen/arch/riscv/domain-build.c +++ b/xen/arch/riscv/domain-build.c @@ -3,6 +3,7 @@ #include #include #include +#include #include #include @@ -154,3 +155,10 @@ int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo) return fdt_end_node(fdt); } + +int __init make_timer_node(const struct kernel_info *kinfo) +{ + /* There is no need for timer node for RISC-V. */ + + return 0; +} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 16:11:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 16:11:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413452.1643679 (Exim 4.92) (envelope-from ) id 1x4Kso-0006wM-VM; Wed, 09 Sep 2026 16:10:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413452.1643679; Wed, 09 Sep 2026 16:10:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Kso-0006wF-Sh; Wed, 09 Sep 2026 16:10:46 +0000 Received: by outflank-mailman (input) for mailman id 1413452; Wed, 09 Sep 2026 16:10:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Ksn-0006w9-FH for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:10:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Ksm-00HTqS-JC for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 18:10:44 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa184fe-bab6-0a2a0a5309dd-0a2a45049102-16 for ; Wed, 09 Sep 2026 18:10:44 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa18504-b57f-0a2a45040019-b9ff1c228b11-3 for ; Wed, 09 Sep 2026 18:10:44 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a086ef8e26000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 09 Sep 2026 16:10:41 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id CCEFF80518; Wed, 9 Sep 2026 18:10:40 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=9NNFCQfDU3iYqavqMiFq2UaeIBizjyCH9ddiAciEbIk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=QGkX+mUWzoQGL3fk2fEKytfaQvO92LzGEB8DCYLqtLCJhNkFE8pnRk+Vg2fvLGN393R1iIfQA nrzxgWx+hWgu6k7eQTTk2faZQbg4HV1ON//C96qH7ikFerJKNzb4NuzoK6l2cali7MQpmt9tWkV 6VvyFVvrWLg/4fCWwZxqbibIwZiZ7nVyWt9w21/OYz3E35UOxgZS7dUZPyM03kvpMac5pBfmxjt hB/VNVTCiM3IR0Y6TRrV7fyLTJqRPXa2YM0MWCQUOQu2qj99YQJI9T9QdkT8CkqMuCenvwHGifR q8JkeJpaKN5VB6zLRmiKmL3mxGJ1zEso3p3rjs+LRuiQ== X-Zone-Loop: 2c8db8930fe5dacf6d665c819fb9df91e0dc6f15b598 x-campaign-type: default x-transaction-id: 6c587687-abb4-4aac-b3d0-8a09a7e70e3b x-swg-uid: 01-1e5a0017-6422-4002-9f9f-b0acdada2fdd X-Mailer: Sweego Message-ID: <1788970241.8631fc262581453bbf619ec5b2062170.1a086ef8e26000c4f3@vates.tech> x-swg-bid: 1788970241.8631fc262581453bbf619ec5b2062170.1a086ef8e26000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 9 Sep 2026 18:10:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/vmx: Avoid pausing on HVM_PARAM_IDENT_PT in additional cases To: Andrew Cooper , xen-devel@xenproject.org, xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1788956067.8631fc262581453bbf619ec5b2062170.1a086174641000c4f3@vates.tech> <4413f32d-3c76-4248-b7f9-577576bb4ea2@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <4413f32d-3c76-4248-b7f9-577576bb4ea2@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ZTrvgSBTHOXXfsRvAG3m0tPG" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1788970240971 X-purgate-ID: tlsNG-ebf023/1788970244-534C3B50-5554A5CD/0/0 X-purgate-type: clean X-purgate-size: 9123 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ZTrvgSBTHOXXfsRvAG3m0tPG Content-Type: multipart/mixed; boundary="------------gF5QGscVnOhz5eh172NZunRi"; protected-headers="v1"; hp="clear" Message-ID: <222d4212-9091-4fa2-a48a-4d13249ba145@vates.tech> Date: Wed, 9 Sep 2026 18:10:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/vmx: Avoid pausing on HVM_PARAM_IDENT_PT in additional cases To: Andrew Cooper , xen-devel@xenproject.org, xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1788956067.8631fc262581453bbf619ec5b2062170.1a086174641000c4f3@vates.tech> <4413f32d-3c76-4248-b7f9-577576bb4ea2@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <4413f32d-3c76-4248-b7f9-577576bb4ea2@citrix.com> --------------gF5QGscVnOhz5eh172NZunRi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMDkvMDkvMjAyNiDDoCAxNzozNSwgQW5kcmV3IENvb3BlciBhIMOpY3JpdMKgOg0KPiBP biAwOS8wOS8yMDI2IDE6MTIgcG0sIFRlZGR5IEFzdGllIHdyb3RlOg0KPj4gV2hlbiBzZXR0 aW5ncyBIVk1fUEFSQU1fSURFTlRfUFQsIHNraXAgZG9tYWluIHBhdXNpbmcgd2hlbiA6DQo+ PiAtIHRoZXJlIGlzIG5vIHZjcHUNCj4+IC0gdW5yZXN0cmljdGVkIGd1ZXN0IGNhcGFiaWxp dHkgaXMgdXNlZA0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IFRlZGR5IEFzdGllIDx0ZWRkeS5h c3RpZUB2YXRlcy50ZWNoPg0KPj4gLS0tDQo+PiBSZWdhcmRpbmcgY2hlY2tpbmcgZm9yIGh2 bV9wYWdpbmdfZW5hYmxlZCh2KSAocHJvcG9zZWQgaW4gdjIgcmV2aWV3KSwgd2UgY2FuJ3QN Cj4+IGFzIGh2bV9wYWdpbmdfZW5hYmxlZCgpIGlzIHZDUFUgc3BlY2lmaWMsIGFuZCB2Q1BV IDAgbWF5IGhhdmUgYSBkaWZmZXJlbnQgdmFsdWUNCj4+IHRvIGFub3RoZXIgb25lLg0KPj4N Cj4+IHYzOg0KPj4gICAtIHJlYmFzZWQgcGF0Y2hlcyB3aXRoIHN0YWdpbmcNCj4+ICAgLSBh ZGp1c3RlZCBmb3JtYXR0aW5nDQo+Pg0KPj4gdjI6DQo+PiAgIC0gcmViYXNlZCBwYXRjaGVz IHdpdGggc3RhZ2luZw0KPj4NCj4+ICAgeGVuL2FyY2gveDg2L2h2bS9odm0uYyB8IDUgKysr Ky0NCj4+ICAgMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigt KQ0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaHZtL2h2bS5jIGIveGVuL2Fy Y2gveDg2L2h2bS9odm0uYw0KPj4gaW5kZXggOWE0MTQ3YjYyZS4uMjk4MWE2MWNlZSAxMDA2 NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMNCj4+ICsrKyBiL3hlbi9hcmNo L3g4Ni9odm0vaHZtLmMNCj4+IEBAIC00MjM3LDExICs0MjM3LDE0IEBAIHN0YXRpYyBpbnQg aHZtX3NldF9wYXJhbShzdHJ1Y3QgZG9tYWluICpkLCB1aW50MzJfdCBpbmRleCwgdWludDY0 X3QgdmFsdWUpDQo+PiAgICAgICAgICAgICAgIHJjID0gLUVJTlZBTDsNCj4+ICAgICAgICAg ICBicmVhazsNCj4+ICAgICAgIGNhc2UgSFZNX1BBUkFNX0lERU5UX1BUOg0KPj4gKyAgICAg ICAgdiA9IGRvbWFpbl92Y3B1KGQsIDApOw0KPj4gKw0KPj4gICAgICAgICAgIC8qDQo+PiAg ICAgICAgICAgICogT25seSBhY3R1YWxseSByZXF1aXJlZCBmb3IgVlQteCBsYWNraW5nIHVu cmVzdHJpY3RlZF9ndWVzdA0KPj4gICAgICAgICAgICAqIGNhcGFiaWxpdGllcy4gIFNob3J0 IGNpcmN1aXQgdGhlIHBhdXNlIGlmIHBvc3NpYmxlLg0KPj4gICAgICAgICAgICAqLw0KPj4g LSAgICAgICAgaWYgKCBwYWdpbmdfbW9kZV9zaGFkb3coZCkgfHwgIXVzaW5nX3ZteCgpICkN Cj4+ICsgICAgICAgIGlmICggcGFnaW5nX21vZGVfc2hhZG93KGQpIHx8ICF1c2luZ192bXgo KSB8fCAhdiB8fA0KPj4gKyAgICAgICAgICAgICB2bXhfdW5yZXN0cmljdGVkX2d1ZXN0KHYp ICkNCj4+ICAgICAgICAgICAgICAgYnJlYWs7DQo+IA0KPiBUaGUgY29tbWVudCBpc24ndCBy ZWFsbHkgY29ycmVjdCwgYW5kIHVzaW5nIHZteF91bnJlc3RyaWN0ZWRfZ3Vlc3QoKQ0KPiBp c24ndCByZWFsbHkgY29ycmVjdCBlaXRoZXIuDQo+IA0KPiBIb3cgYWJvdXQgdGhpcyBpbnN0 ZWFkOg0KPiANCj4gIMKgIMKgIMKgIMKgIC8qDQo+ICDCoCDCoCDCoCDCoCDCoCogSURFTlRf UFQgaXMgbmVlZGVkIG9ubHkgZm9yIE5laGFsZW0tZXJhIFZULXgsIHdoZXJlIEVQVCBpcw0K PiAgwqAgwqAgwqAgwqAgwqAqIGF2YWlsYWJsZSBidXQgVW5yZXN0cmljdGVkIEd1ZXN0IGlz IG5vdC4NCj4gIMKgIMKgIMKgIMKgIMKgKg0KPiAgwqAgwqAgwqAgwqAgwqAqIFRoZSBpZGVu dGl0eSBwYWdldGFibGUgaXMgY29uZmlndXJlZCBieSB0aGUgdG9vbHN0YWNrIG9yIGh2bWxv YWRlciwNCj4gIMKgIMKgIMKgIMKgIMKgKiBhbmQgdGhlIHBhcmFtIG5lZWRzIHRvIG1vdmUg aW4gdGhlIG1pZ3JhdGlvbiBzdHJlYW0gaW4gY2FzZSB0aGUgVk0NCj4gIMKgIMKgIMKgIMKg IMKgKiBsYW5kcyBvbiBhbiBFUFQgJiYgIVVucmVzdHJpY3RlZCBzeXN0ZW0uDQo+ICDCoCDC oCDCoCDCoCDCoCoNCj4gIMKgIMKgIMKgIMKgIMKgKiBOb3RoaW5nLCBiZXNpZGVzIHJlY29y ZGluZyB0aGUgdmFsdWUsIG5lZWRzIHRvIGhhcHBlbiBvdGhlciB0aGFuDQo+ICDCoCDCoCDC oCDCoCDCoCogZm9yIFZULXggRVBUICYmICFVbnJlc3RyaWN0ZWQgVk1zLg0KPiAgwqAgwqAg wqAgwqAgwqAqDQo+ICDCoCDCoCDCoCDCoCDCoCogVE9ETzogVW5yZXN0cmljdGVkIEd1ZXN0 IHNob3VsZCBiZSBhIGRvbWFpbiBwcm9wZXJ0eSBub3QgYSB2Q1BVDQo+ICDCoCDCoCDCoCDC oCDCoCogcHJvcGVydHkuDQo+ICDCoCDCoCDCoCDCoCDCoCovDQo+ICDCoCDCoCDCoCDCoCB2 ID0gZG9tYWluX3ZjcHUoZCwgMCk7DQo+ICDCoCDCoCDCoCDCoCBpZiAoICF1c2luZ192bXgo KSB8fCAhcGFnaW5nX21vZGVfaGFwKGQpIHx8ICF2IHx8DQo+ICDCoCDCoCDCoCDCoCDCoCDC oCDCoHZteF91bnJlc3RyaWN0ZWRfZ3Vlc3QodikgKQ0KPiAgwqAgwqAgwqAgwqAgwqAgwqAg YnJlYWs7DQo+IA0KDQpJJ20gb2sgd2l0aCBpdCAodGhvdWdoIHJlZ2FyZGluZyBwYWdpbmdf bW9kZV9oYXAsIEkgdGhpbmsgDQpwYWdpbmdfbW9kZV9zaGFkb3cgaXMgcHJlZmVyZWQgaGVy ZSBiZWNhdXNlIGl0IHdpbGwgdHJhbnNsYXRlIGludG8gDQpkaXJlY3RseSAwIGlmIHNoYWRv dyBwYWdpbmcgaXMgZGlzYWJsZWQsIG90aGVyd2lzZSB3ZSBjaGVjayBmb3IgDQpQR19IQVBf ZW5hYmxlLCBhdCBsZWFzdCwgdGhhdCdzIHdoYXQgWzFdIHNlZW1zIHRvIGJlIGFib3V0KS4N Cg0KQnV0IGlmIHdlIG1vdmUgdW5yZXN0cmljdGVkIGd1ZXN0IGFzIGJlaW5nIGEgZG9tYWlu LXdpZGUgcHJvcGVybHkgKG9yIA0KYWx0ZXJuYXRpdmVseSBhIHN5c3RlbS13aWRlIG9uZSk7 IHRoYXQgY291bGQgbWFrZSB0aGluZ3Mgc2ltcGxlci4NCg0KWzFdIHg4Ni9wYWdpbmc6IHJl cGxhY2UgIXBhZ2luZ19tb2RlX2hhcCgpIHdpdGggcGFnaW5nX21vZGVfc2hhZG93KCkNCg0K PiANCj4gVGhlIGNhc2Ugb2Ygbm8gdkNQVXMgaXNuJ3QgdmVyeSBpbnRlcmVzdGluZzsgaW4g dGhhdCBjYXNlLCBwYXVzaW5nIHRoZQ0KPiBkb21haW4gaXMgZnJlZS7CoCBXZSBjYW4gYXQg bGVhc3Qgbm90ZSB0aGF0IHRoZSBkYXRhIGlzIGluIHRoZSB3cm9uZw0KPiBwbGFjZSwgZXZl biBpZiB3ZSBkb24ndCBmaXggaXQgeWV0Lg0KPiANCg0KVGhlIGNoZWNrIGZvciAhdiBpcyBt b3N0bHkgcmVxdWlyZWQgZm9yIHZteF91bnJlc3RyaWN0ZWRfZ3Vlc3QodikgdG8gbm90IA0K ZGVyZWZlcmVuY2UgTlVMTC4NCg0KPiB+QW5kcmV3DQoNClRlZGR5DQo= --------------gF5QGscVnOhz5eh172NZunRi-- --------------ZTrvgSBTHOXXfsRvAG3m0tPG Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqhhQAFAwAAAAAACgkQZg+p0QLLz9Dc igv9FxG36GXQ1Sg8SZ6fH34KGiBBkz1pcBSvxYB92Q+cXuzwnTUp81gYt/NPbciLXzp1YR3IglTf ZQgdScSS/kX7Xma/Lafhia9sa0a7b/rd9ONEh2nIRrUQmwHxXhJsBvMkTRMHC1wFtxsW1GoWSn8a P/uWpLfMWzFtJHHq+7aqGX2QD28GxFux92arelxVCG7VzXs5jRbkAd3T8240cLZAuNw2rl5Yn8Uf dFX8pfCjvxs5akNyFCG8ZNzl0nfHDZ3EkU0nLvDZZFHqSBeAOCZa64adgMuNCMQJEs+rD+5y+Nx3 5NpS4an2xv3boFKi+q07+MBn/0uAXGMSr5cPD0rKbo8ZKHThxV4AxqIEHOYLcIQz4AO/MhWUNT/o jO9fjGQYNi6Yv/sXfA5Xm2QXLRzfn4+xr85iWuLwW22StcO1LunR466VpIFVkJArK/CxMN8wbkq/ tKkavA22X2lOZzclrINu9iNYGPhZK56Xx0ih3gps6V3P0fegiARulTp3Pzy5 =6LWX -----END PGP SIGNATURE----- --------------ZTrvgSBTHOXXfsRvAG3m0tPG-- From xen-devel-bounces@lists.xenproject.org Wed Sep 09 16:28:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 16:28:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413478.1643688 (Exim 4.92) (envelope-from ) id 1x4L9y-0000ZS-A8; Wed, 09 Sep 2026 16:28:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413478.1643688; Wed, 09 Sep 2026 16:28:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4L9y-0000ZL-7N; Wed, 09 Sep 2026 16:28:30 +0000 Received: by outflank-mailman (input) for mailman id 1413478; Wed, 09 Sep 2026 16:28:28 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4L9w-0000ZF-Ow for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:28:28 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4L9s-006WCu-12; Wed, 09 Sep 2026 16:28:24 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4L9s-005Q2Q-2R; Wed, 09 Sep 2026 16:28:24 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=fEXi57et85c1vW2jLuHqAtjGNNllgpoKc5osiOaje6c=; b=XcjvezNao0LahQUYywiH3VjeDb gc2QaXTTZpJfG1Y1dFjVNr4Xq11WBn64UQPhBmUQlbispvmeLa3dfVL8hk56va71tV8xpTipNwoX3 4ZhfE+WhfPczxElPPGFUq7G0xhOAkHQeswv4W+/NBk6lv3b3ll42iOCeQmhVsBiqx+mw=; Date: Wed, 9 Sep 2026 18:28:21 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] x86/mm: limit deferred TLB flushing to PV domain support Message-ID: References: <20260909140500.73483-1-roger@xenproject.org> <92c9bf4b-5171-4a26-a62e-f2a7b1cb89ef@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <92c9bf4b-5171-4a26-a62e-f2a7b1cb89ef@suse.com> On Wed, Sep 09, 2026 at 04:46:01PM +0200, Jan Beulich wrote: > On 09.09.2026 16:05, Roger Pau Monne wrote: > > --- a/xen/common/page_alloc.c > > +++ b/xen/common/page_alloc.c > > @@ -1538,8 +1538,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) > > BUG(); > > } > > > > - /* If a page has no owner it will need no safety TLB flush. */ > > - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); > > + /* > > + * If a page has no owner and there's no PV domain support it will need no > > + * safety TLB flush, there can be no stale TLB entries. > > + */ > > + pg->u.free.need_tlbflush = IS_ENABLED(CONFIG_PV) && page_get_owner(pg); > > if ( pg->u.free.need_tlbflush ) > > page_set_tlbflush_timestamp(pg); > > I'm okay with the code change now, but the comment is still concerning me. > All by itself there is no reason why stale TLB entries couldn't also exist > for HVM guests. It's just that (a) only the host TLBs are flushed by > filtered_flush_tlb_mask() and (b) flushes of guest TLBs occur when pages > are removed from their P2Ms (aiui; hopefully true also for Arm). IOW what > the comment says looks to be correct, just that it leaves too much to be > figured out by the reader. At the very least I'd suggest "..., there can > be no stale (host) TLB entries." Thoughts? Hm, I find adding "(host)" to also be slightly confusing, as I would usually associate host TLB with Xen context TLB state. Which is also made more confusing by how PV guests share the page-tables with Xen. "If a page has no owner and there's no PV domain support it will need no safety TLB flush. PV domains are the only domain types that can keep stale entries on the TLB, as they have (limited) control over the host MMU and when flushes are performed" Is this any better? I'm still not fully convinced, as HVM guests do have full control over the MMU, it's just that in that case p2m changes unconditionally lead to flushes. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 09 16:36:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 16:36:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413492.1643697 (Exim 4.92) (envelope-from ) id 1x4LHi-0002HV-4e; Wed, 09 Sep 2026 16:36:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413492.1643697; Wed, 09 Sep 2026 16:36:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4LHi-0002HO-1t; Wed, 09 Sep 2026 16:36:30 +0000 Received: by outflank-mailman (input) for mailman id 1413492; Wed, 09 Sep 2026 16:36:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4LHg-0002HI-1c for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 16:36:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4LHf-003PWQ-9b for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 18:36:27 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa18adf-bab6-0a2a0a5309dd-0a2a4505d3fe-36 for ; Wed, 09 Sep 2026 18:36:27 +0200 Received: from [52.101.53.67] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa18b09-4cb1-0a2a45050019-3465354383b0-3 for ; Wed, 09 Sep 2026 18:36:26 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH3PR03MB7481.namprd03.prod.outlook.com (2603:10b6:610:19a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.8; Wed, 9 Sep 2026 16:36:19 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0382.014; Wed, 9 Sep 2026 16:36:19 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SckKboWbHDHUvFJXGZAWayrjM8HsbkwqAHbjVT/YrhUZUHSySsaH2IIVwIjnL6qDIsdAJ3hPUcef0PDYAY1ErYpLHGLMaxLgIFIvEea3+CzwwlTcvEfe7cp/p8bpCLijWBs5EEsDH8ER1nnsVcv5SB4YBUY7a4M/XbUvo0zaaLF+Tsw5g8uNsZst1UuFb8t7Q8JwPd6Zx8UwD0FUv/KdGwsXcIUj24nBQV0fnGbuYjtvqWTazFATi88bl5FJl882nYqGNDpayoXQ5NtlPHM/wZL0hf1ocQEzZZwU8PTkuMyyJUSlomP3Y4epMl9zo0PQ2wWfYOQiHEbQZei+vFFrNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=h05uelj3kCaL5HmqleICISmLf2xoEmSZCvNmkWm6L8Y=; b=GzeE8uDHmsJA9YncKjN3qfFIxMuNQLEfRPdU8Z3o/y8N1Jypla9VkSXIcfthtq/SALlpkXN8Sw4jf3kzH+FXpnNnAnC7LaqqrLipIKiMm52W9c9yLM0Dw+g7IF1XIwRoaAom6tBsBfX/5eifyRVqcIiOCasdVECky9zcSUjwXYh0wacRd/K9sAmOSLMf/JjY6o2CAC1/zdjI+gsDvLBqf5Z6/h9Mld1j4wbGVfmB6ICJ7fDj2XBxZccxh+nyj/Jcq7jp02t4rh/e86OIJhKLIMCo+28yJXYMdNV8x4D5xYFq79Sl0NBCt7drsP7i4nGpbLX2g3JZpAP2RxodEU/qYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h05uelj3kCaL5HmqleICISmLf2xoEmSZCvNmkWm6L8Y=; b=j2i1znBn/AGnkpDdxMhdPnqUBKxiGZ6hsc2zLqET9c/gnH7eFHdUvD/zDj6/L+fNqGOhhn+p2OI3QsWFFx6YBd/jA0y2/ecjNtQzKaN0vFNroO+qMs2F1YjOss7kwZBx1PzRPGgCkDvldV9ckpRaduA6t8tgfxDoK8vwlecn1AU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <157b7cb8-5e20-40d5-96ac-8f2488fff234@citrix.com> Date: Wed, 9 Sep 2026 17:36:15 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Jan Beulich , Teddy Astie Subject: Re: [PATCH v3] x86/ucode: Work around Granite Rapids erraturm GNR98 To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260908171525.3196765-1-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0130.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c6::19) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH3PR03MB7481:EE_ X-MS-Office365-Filtering-Correlation-Id: 726375b1-b065-4ac1-80bd-08df0e9079a3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|6133799003|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: fiY3XT9uWupuzwpb5W/cqcQTtkmgK4rWN7Y4XzXATAv7fD8bpHdI0T1bNPt3dP7m3cv0YXA14kCgqmaasxCD9OwE0WrchmDCrU+PMPFxdZTYtWdPPWmcBf8ESmUj0hsfRpw6r2I/Z2UUQsSLufbGKEVZLF9/5FggRNSNw3p+gHpiJVvQw71HfGb5ibRRDZy8voCvU+ig2jqNizcKVAtMALrncHyu6BNzjZQVIo5rLRP30AHYtQ271BSDCDH/mS0NtQwWdJ1qonlAmOUVts5eyXj3P8UtiHLr/rlPApTfM0Ei+gEJFq8H7VHpdnJty39i+FILUPh4MXiEpgfU1Tfbv/bMOgBPvpdFykwxyjRpKuqZtZYOqmGBsTDVIGXc0H+YB1CUPVil8r80qlESu5UC+oSOvhF/2m4jeSaEyn/ziu7dPt8YrxZUWvyTJzPXo716kyq79VAbQpPzLy/lTkuVd8yoFOigMjvd7We+ibIMJVln4ikcgkDr7PN/zWoyGClfvPQD+HBX/BkdAZMt590mcwVfWIUciyDqc59jMxhd0AezNL1zBuIuft2nC3thxVmZ2l/L2hTn94MD0T8zJw46PBFU2fQwaV5yv1GLiMymZNZvxHB3xbkSLszqsMKg6nAdGXfuYAhSkABM/kvNeXNLRVQTYMibeeGk3Z7qlfumzHg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(6133799003)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WnRSR2ZpTFdMTlo3UGpCZCtwS25KbndySzFoRHA0WWlNUWRka2ZSY1dWWGNZ?= =?utf-8?B?MHZ0MkdOY1U5aFE2a2dSeE52OXQzK2l3L2NjYTB0S2xyME1qbTZDYlFucEN6?= =?utf-8?B?VTVBQ2Vrd0svbUdGVndnbEhSbGlhZDQyVnNZb1dqc1hzWjVTQmdTWlNtcFd3?= =?utf-8?B?SEZSYmxLTlhqTWdGSDZyRFNiWTFGR01tOTVEOEJtZHM0eFBydlBHeUE5VUNJ?= =?utf-8?B?cnJpdTBrYTJGMGdkcFdDMnJjQVVCb285ZXE3dUdtVjBuNVFJaXdnOUpYSWVy?= =?utf-8?B?T01pV2NjaEJhd05IYk5ZWVNBS2ZwcWFmaExQNDZwc2FwRlZDVVlBYWtneHMx?= =?utf-8?B?ME5sRk53MEtVTWV3SitpajYrTTQzcFk5SUpua0xiUzZKaS81US85dkRQYVhB?= =?utf-8?B?bTJBZ3VqS3RNZlJMeVRodk5aYW1WUWk3eDNhSFV6dUZhTHlyNm5KaDhkMFdl?= =?utf-8?B?TXFaWnF2ajAzbVQ1aXZsdUxNMGRxbUEzYmFaVElPcElOYTdtemlLMTA1ckxq?= =?utf-8?B?eWZZNG5GS1VPQytUVzdsdXQ0S3NCVTBjYnlMSjkwRitNN2dnQXR0QjZTSEpV?= =?utf-8?B?eFp0OTczOVhZSjQvMCtFdFF6YzVqcXBzV1NsMEp1Tml5UjVnSElJV055VWNI?= =?utf-8?B?TXRsbXVVczFCODJKR0VkSFR0cm5RK2UrU0VuODE3cjNhZjNldVE5RFNEcThV?= =?utf-8?B?UXpWRDJ2ZVpQbldkM1JTMzI4d1Zjb2U5NHQxU1ZISFRwbVkzMXdNVTMxSGkr?= =?utf-8?B?eFZqU2wzb2Y4QzdrcDJnWm5FNEs3NDd5SXdhT3VQeUxaSVE3VjJDVy9BVnp0?= =?utf-8?B?M25rUDI1QU4zbjFxTGc5Z3pvK3pReHBXZkZjaUI4TEZxbUNSL3A5cWxwQXIw?= =?utf-8?B?K0I3cTFzTExYMlVGbUVicUJFdkpINzBJelB1TkdQUDlhamJGVHVSb0pOWlAx?= =?utf-8?B?dTB1VmNjNnRWMjA2UForWXlpMFF2N09OSGkyL0JMb1NXMUFFZ0ZCOXMyNm0y?= =?utf-8?B?Tng5akN0b0pXZkROcUhteFVwRXQ4SGxHZzhDU21ERVpSMlVsNlZseGpCZzN2?= =?utf-8?B?QkVsc3laN245alArL0ZDdmUwa1RzdTN4TzJrRmRwcW8vbm1sSEgvc2lrTk12?= =?utf-8?B?T1UySHhoNVlYSzFnc0x4NVhoOXhEa1NKQTc0b0dGb01NYmI2NEdQdmh2WXg4?= =?utf-8?B?eDlONno5bkp6TzhCN25KelBpQkRSYVRoMFIxbjF5Yk9rTW9oTWlEcUhDRTg2?= =?utf-8?B?OE5xc24zMUZuUFluK2ZTN0FGZjhzT0NMRDlqd2dZdytjQU5wVUplZlIyVStw?= =?utf-8?B?b2RDRXBkRCtHS2JKbnpWTnZCZnRwODQ5U3l6OE03ZHdDTFNoVDN0N09tL1di?= =?utf-8?B?WnBtRUJ2bVhycFgvSERMRERtWTRaQXBmMXExbjlPOTB4U2dRWStYWmZoVkVK?= =?utf-8?B?ZHloV3YzTnB2TXpZcVZRWEZrQURqWEo2eTJweHQwakMrKzcveVBvRnU2M3Fn?= =?utf-8?B?NTBsSExkQWNoalVqeE5aMFFlU2lxN2tiV3VkdmlLUm9XK0FRTklKdFRHV21y?= =?utf-8?B?cFUwZDRzbkpCcVZNNHpOZzhWWUN4bHVKWE9KR0pxb1pLdE5tMHRpREtLdk45?= =?utf-8?B?cDRPRXVFSzBrOFBIOGlvZHhvcEtUckJHU3BDMU1CRzZlSUx3a1hjVGpCTEUx?= =?utf-8?B?OEpKVUE3STZlQVJTVW1KOFdlYklmVzQ0N1ljS2lZSlprZUtWblhTRVRUeCtI?= =?utf-8?B?eG5hZWxZVmJHdFNIa1VYbGRrbzZPK0pOS3ZYaUJvVFYwNjl4Q1RtQXg2SGNl?= =?utf-8?B?bWxzU0IyNXFxa1IwUzdRR2ZUd0JYcFhRSS92Z1RYZUFNdWlFWEpsU1haSjlr?= =?utf-8?B?eHRKbGQ2Z0JZZnNxZENiTmE5SE1obVNvNEVWSHNNU1MyOFE0VmdPS01QOHBK?= =?utf-8?B?TzBIMEd3V1k2RDlXaDhrTUFGdG52QUVCL3h4cHRwcUw5aVUwbFY5VzZyQlZx?= =?utf-8?B?c0pLTXY3VjBSUG1FMDJxYWsyRCtmL2x2am14RVNrY0xvV3NqSFl3eGZ3ZmZo?= =?utf-8?B?SFlDNzdCOHZzYit1K3o2ekRMbTBTeG1sbDdBb2QyN25PZTN3U3kwZkc2S1Zh?= =?utf-8?B?S2p5K1RDclIyeEJkQjFKV3FEUGs5MDNVWU1FWWkwemorSklra2NXeVlCNkZt?= =?utf-8?B?WnFnZEpQVVh2aS9IY1AzWkVtRGtqTE1iN0I0T3NIS29rUVRhaEl4YVhRWlBr?= =?utf-8?B?b0UwRzdBbjI4cDJJZHhYQ3JSOTNaZEUwN3lUc0huSkY4TnN2d2owZmNBU2VL?= =?utf-8?B?Q2RLTDZ5em0xSVZ1ZHhaY0t1UkMxSGdWYzJqc2NyNlRyQi82TGhOUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 726375b1-b065-4ac1-80bd-08df0e9079a3 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 16:36:18.9407 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7pVXj+Se7hDnt5xhRnzieYy/ARPfv4Lpsx0EDYJuZnNgoSyece3pKYT1KErqk2aYhVYA33Nnx3tUph8wKq7gmJCcSGImwschiU4Iqrmk8nQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR03MB7481 X-purgate-ID: tlsNG-c201ff/1788971787-247132A1-E6EA3735/0/0 X-purgate-type: clean X-purgate-size: 1956 On 09/09/2026 10:35 am, Roger Pau Monné wrote: > On Tue, Sep 08, 2026 at 06:15:25PM +0100, Andrew Cooper wrote: >> + >> + /* >> + * Treat pre-production as always safe - anyone using pre-production >> + * microcode knows what they are doing, and can keep any resulting pieces. >> + */ >> + if ( (int)cpu_sig->rev < 0 || mc->rev < 0 ) >> + return true; >> + >> + /* >> + * GNR98 states that Granite Rapids systems hang when loading new ucode on >> + * sufficiently old firmware. GNR101 retroactively states that one ucode >> + * had an incorrect minimum revision field, in light of discovering GNR98. >> + * >> + * Both are incomplete statements of the problem. >> + * >> + * At the time of writing (August 2026), the believed safe sequence is: >> + * 0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later >> + * >> + * Disallow known-unsafe loads while permitting believed-safe loads. For >> + * GNR, this allows multi-hop loading to get up to the latest. >> + */ >> + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X && >> + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) && >> + ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) || >> + (cpu_sig->rev < 0x01000405 && mc->rev > 0x01000405)) ) > Given the logic, I don't think the CPU needs to strictly be in version > 0x01000370 to update to the [0x01000380...0x010003f3] range? > > Maybe you want to replace 0x01000370 with "any previous" to match the > semantics used in the tail of the sequence with "any later". Hmm.  370 was the first release, so the analysis of the problem stops there.  Everything older was development phase. But yes, the eventual planned fix doesn't have 370 as a boundary, so I'll adjust to "previous". > > In any case: > > Reviewed-by: Roger Pau Monné Thanks. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Sep 09 19:08:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 19:08:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413597.1643726 (Exim 4.92) (envelope-from ) id 1x4NeI-0004sb-T6; Wed, 09 Sep 2026 19:07:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413597.1643726; Wed, 09 Sep 2026 19:07:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4NeI-0004sU-Q4; Wed, 09 Sep 2026 19:07:58 +0000 Received: by outflank-mailman (input) for mailman id 1413597; Wed, 09 Sep 2026 19:07:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4NeI-0004sO-9l for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 19:07:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4NeH-000GAd-Fz for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 21:07:57 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1ae66-8faa-0a2a0a5109dd-0a2a45029810-32 for ; Wed, 09 Sep 2026 21:07:57 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1ae8d-6ca4-0a2a45020019-a237832fc308-3 for ; Wed, 09 Sep 2026 21:07:57 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id D7CC14EE00C1; Wed, 9 Sep 2026 21:07:56 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1788980877; b=A3qUI1u2Dk4VHrELb/TJZmWV2Rr3vWge1ORQfYI+seb+SR3S7F9SnhfKXQB4QiSaA5kG nKmNe2lSnroeydb/1xS13Sh5kjZpWh+1jYS35D0jpp3khGFVPhniMcaVALtjcaAX7UXT6 sOm1gIm7OrtKfcQazanXyyzLVAvSjZFT2OWKI+rArMZoMVIc9NO2ZIKohqj99XA/MTcKq 4CLgH9Ez8xxgXrJsS6tiPjrpH8PvGX9jKilCBj0E5cIcVf6hW0wSwfLu4p0o+LOLDC/Eg rSb2AsVQFy45iqP+954pNrcHsphtPC1/UnLiLPMxZrOhZsworhqAGjxY+AQ9BaTJn1koO WNBe5RfzG7vIk963Ykx3W5J8N71iLrX6X5GLfssYNLttuSy24jbP/R68d6/8VDCZRamjo uXcHn8RKNLb5OTs9RsBvzJHDZzfh2TE/0UUF1Cx2H7xDClfof5myFpio8gD+mXGpE4m1S cSqQ/lnho9KK8FCV+1fAa/AWYyg6FjHEXKWMnsWTKqqBUdJqh34YL2udO68XOLRw3IwEe hUGUzKk/yruMgzsuZWAGloeHmfvYPPUpjVs3daVAAAIDOaguHR7qncqCfASqv6nZAnbXW ZtFpHENI/+4JBLtKE3HEHP1DjISuhEBVZIl/kTdT5Xk1QqyMW0A4oa4PBV89ezI= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1788980877; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=NDrl5IY0otNcDgKDoWPhJydoi9fBTL1klCgRxR16pvs=; b=LJA2XYJzsRha7w+g7NqleDUJioCxCTHcipysx4g/dNSsAQmQDSQeVyR+P13wMn5TU9qD v+pq6vWlC1uRoEg1HrapLv0CCCYn2Bk2LgjZQ3U6OSqtRiOQEKKbNX5rxzz+GX8t6UF1S hbG5r4gEYnyGvD/sQ2sgvwqcWbK+y+jpYkA0330nV+wv6HMBsyZahCrhQ8MIx6UO+HiKm tnYKMI+qKpCvD09YCwA+qkoQxuOba0XM4i2RpyoTkZgoYjbDlrDjNbUvu4u0MVlEE6RmH vSFxTSwqoiWcoHZ1xcJtfMph4n4GCr/8/U5c1YBQBo6bA4S9atkyR5FmWeslNX6Eq1vvm H/DX8aXPzwttQqxdidgVsfH9igiKu6pFZZVzoVE8dfUV+imOoikPWjE+3upE15I9Wj866 ga0xIwALk1htwbyFmkQlhxgRvVsydBzLoGJxgqqYYze2kMfPi12GlA+QybJrTYuPVmxG2 Glc+swQdUbPl0UbiKvkEbfT/g8L89F/0HcZnXGqaR4Xh9nsroz8r2vxaiL3PDvCIJw8Z1 lzYodcL+mnxDtUbUS+hWNbYQOQfc/GUW3SPz3Lf25kPm0dmZEOt1cOInJo4xHwuhl3bIK 9chPax2AjaUZG5l8SIEHZwdDk1ch5W9SMDdlI15uAon8EnpvPYyB52CQZSp5OPY= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Wed, 09 Sep 2026 21:07:56 +0200 From: Nicola Vetrini To: Jan Beulich Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places In-Reply-To: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.com> Message-ID: <320b920b3e673671eddceccb4b86f211@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1788980877-66CB22AC-21802FE6/0/0 X-purgate-type: clean X-purgate-size: 3063 On 2026-09-01 08:26, Jan Beulich wrote: > On 31.08.2026 21:13, Andrew Cooper wrote: >> On 28/08/2026 8:01 am, Jan Beulich wrote: >>> --- a/xen/arch/x86/traps.c >>> +++ b/xen/arch/x86/traps.c >>> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu >>> case X86_ET_HW_EXC: >>> switch ( vec ) >>> { >>> - case X86_EXC_DF: return do_double_fault(regs); >>> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>> case X86_EXC_MC: return do_machine_check(regs); >>> } >>> break; >>> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp >>> case X86_ET_HW_EXC: >>> switch ( regs->fred_ss.vector ) >>> { >>> - case X86_EXC_DF: return do_double_fault(regs); >>> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>> case X86_EXC_MC: return do_machine_check(regs); >>> } >>> break; >>> >> >> For starters you're missing a break, and the only reason this isn't a >> compile error is the trailing comment. > > "break" there would again be unreachable, though. > >>   Second, it's a tailcall anyway.  >> There really is nothing unreachable anywhere in this construct. > > Just that the concept of "tailcall" is an optimization, not something > inherent to the language. > >> But by far the most important, it the singular noreturn attribute on >> do_double_fault() (elsewhere, and not visible when reading these two >> functions) which is preventing #DF falling into #MC.   This introduces >> fragility which did not exist previously. > > I realized that when making the patch, yet what do you do when the rule > is as it is? Hence why I added the comment, really. > >> do_double_fault() would conditionally return if we ever got around to >> fixing espfix64. > > And hence would have to lose its "noreturn". At which point call sites > would need inspecting. (As said - yes, I do realize the fragility.) > >> So no - I'm going to insist that Eclair is taught to accept "return >> some_noreturn_fn();" as intentional.  It is objectively less fragile >> than the MISRA-preferred option. > > Nicola, thoughts? > If you find a suitable argument from the toolchain that the generated code is correct even though you return from a function where you promised not to return in its declaration, I suppose that's fine, but that MISRA Rule I mentioned ("A function declared with a _Noreturn function specifier shall not return to its caller"), which is not (yet) applied to Xen exists to defend from stumbling on UB 71 of C11: A function declared with a _Noreturn function specifier shall not return to its caller. So in general ECLAIR should not accept this by default. What you can do is deviate these (hopefully few) cases if you have backing evidence of the correct behavior. -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Wed Sep 09 19:28:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 19:28:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413630.1643736 (Exim 4.92) (envelope-from ) id 1x4NyP-00084U-GO; Wed, 09 Sep 2026 19:28:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413630.1643736; Wed, 09 Sep 2026 19:28:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4NyP-00084N-Co; Wed, 09 Sep 2026 19:28:45 +0000 Received: by outflank-mailman (input) for mailman id 1413630; Wed, 09 Sep 2026 19:28:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4NyO-00084H-O2 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 19:28:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4NyO-008W4u-4I for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 21:28:44 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1b33f-2eae-0a2a0a5409dd-0a2a450bbfa4-26 for ; Wed, 09 Sep 2026 21:28:44 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1b36b-b7e8-0a2a450b0019-d155dd33d5fd-3 for ; Wed, 09 Sep 2026 21:28:44 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-482f2ee53e7so4620406f8f.1 for ; Wed, 09 Sep 2026 12:28:44 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d20fc23fcsm68962995e9.3.2026.09.09.12.28.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 12:28:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788982123; x=1789586923; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=3OqLNu4tTJ8NtFG6KAdKCHnZlkuKkQ1EKyLuMpgNzJ0=; b=jGOuRffEOTIjYFvlaIXbGmR3UlinipdhkGm7y8PuMAjajRMPwcllMhG7B2t9YbTDGB dIhZUMzcdEyoRM5gbYf/56sETsRhpLyueNW74VGECQF3X2+qZt2ki96GU+h6y77DMC30 aV0ZdfcE3irPnCVtSVja9X9EJ5MxRZ/i9sIk0WvUXC6MZ09AB+OPbM+4j8zJK0GTu7Rw +VWkSyUJ8vYA358Sz6o9IwSIR9VdC9Zfxm1zOZ087Y6WT8ElwaNQk/RzXZEZFor9N+X1 GjnsP5rfKTSwRp61Rj0wuqwMGfeZCR5GK2yHzde39MkME2ndW8VCqlu7uLwKapHLdRRF utQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788982123; x=1789586923; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=3OqLNu4tTJ8NtFG6KAdKCHnZlkuKkQ1EKyLuMpgNzJ0=; b=VtyUW5ZMGsaGe+RkCl+xNy/tS58j2X2AEn/Pwi+L/59GmwJb9uxEcMmm3Y2vsiQMA+ mR/NGNwE9gtSa0Sbg0BwNQV+lvjidJXc/COKf/AA61VVFGfRb778gqY9O3+OVDdtT4jN Xs/VE6rnSKS2QEH8p6przHUS0eNicrWLxFQ5wX8LTCpCPR1pdokI/4EDmnFXnT4W8UlY pboO1meWuajtlQ/W71BbxK6Z9bQJi/UXnakU2jZLa2cucDK9zO3MQQmg+OL6cQKPKk13 w/YR0i3snujFxokZp6cbmHLlwY9phEfv/yIDnx4sxQyoOklAyt5aSznsZ9J+KqzikLV9 vUQQ== X-Forwarded-Encrypted: i=1; AKwUvBxlt0jeXOVZVA6MevN1nH3Ad6f97WEeFrNaVl0nCluoQ3p+XrHc5g0sPxiWCE+iAP3pagx7UD40tqY=@lists.xenproject.org X-Gm-Message-State: AFuF++mhbGIFmO3qukwngP3AxMp3N/Tc93JiVDtXCVlwznZd1ALSVB/R RvWXkje2tFXncb9+B/Mt8kMejfvfwL1aTLTgknze7iodYJhP9yDiLsbu X-Gm-Gg: AYBFou3PGo4TzjxvqrOW2jRosrrpFnS/4k20ikneoVUolGsfcpXQgOV0UPBl46HYgL+ TYHd2uTOHpkfSNS99dy6FemN26wL2AX2HU1w/PqW23AVaprCnrptMVXiVAmcdpSbMGuljIREZzV w/ceFe9Qkzm1eQTuE9xoKIQwKnC16ipbZIwpSwQ6hlJrHNjavrFPFl2kz2BzUf7ZyeNHmagc141 jd84xmL7uwBVycWkJj7C6o6ZO0M9jCKLO0P1KGScNf5VnLehYvfwH53cq4Q/i3vadvQ7RWwZleL Gtj/imZoTZCK2iKP0VyXRagenPJLRJN5NGA6Z9xvzaiZX8ozZz9baID7a5kmmEDD/s+EHfOXGZL CbOBoEAvCrbPfOF1UBUGp+dPktD7eMRFRfi0lDeEkor8y/aTY2IZbSMZfAhzUS/Dh+ddj5hBJi/ v0LDP7jH8P9J28LF7Cd4vj1weJjXyvJrU/uyGel6f6H+Za2ie1j9XH+OAjyduXyCpaUX8bWKQ8S w2nuIo0iBfttRPdGUNUX8CZX6zAna6n5syy X-Received: by 2002:a05:600c:a087:b0:49c:d26a:cf70 with SMTP id 5b1f17b1804b1-49cf825a75dmr385537435e9.15.1788982123211; Wed, 09 Sep 2026 12:28:43 -0700 (PDT) Date: Wed, 9 Sep 2026 20:28:38 +0100 From: David Laight To: "H. Peter Anvin" Cc: Borislav Petkov , Mauricio Faria de Oliveira , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() Message-ID: <20260909202838.28071bff@pumpkin> In-Reply-To: <8b00b7d2-2bd3-4871-9908-9fe1568d2690@zytor.com> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> <20260909093831.095b89cb@pumpkin> <8b00b7d2-2bd3-4871-9908-9fe1568d2690@zytor.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1788982124-1A0C59EA-25F09D46/0/0 X-purgate-type: clean X-purgate-size: 2251 On Wed, 9 Sep 2026 06:43:01 -0700 "H. Peter Anvin" wrote: > On 2026-09-09 01:38, David Laight wrote: > >> > >> Here is an out-of-line compact memcmp() which works for both 16/32 and 64 bits: > >> > > > >> > >> On 64 bits it compiles to: > >> > >> 0000000000000000 : > >> 0: 48 89 d1 mov %rdx,%rcx > >> 3: 31 d2 xor %edx,%edx > >> 5: 31 c0 xor %eax,%eax > >> 7: f3 a6 repz cmpsb (%rdi),(%rsi) > >> 9: 0f 97 c2 seta %dl > >> c: 0f 92 c0 setb %al > >> f: 29 d0 sub %edx,%eax > > > > That isn't the object code from the source ... > > > And that's the ultimate hint that a cut and paste error had happened. > > This was the actual source code. > > int memcmp(const void *s1, const void *s2, size_t len) > { > int lt, gt; > > /* > * Note: for the benefit of 64-bit code, xDI and xSI are reversed > * compared with what CMPSB uses; hence SETA and SETB are also reversed. > * > * The XOR statements set ZF = 1, CF = 0, which is required to handle > * the case len == 0 correctly. > */ > asm volatile("xor %[lt],%[lt] ; " > "xor %[gt],%[gt] ; " > "repe cmpsb ; " > "seta %b[lt] ; " > "setb %b[gt]" > : "+D" (s1), "+S" (s2), "+c" (len), > [lt] "=&q" (lt), [gt] "=&q" (gt) > : : "cc", "memory"); > return gt - lt; > } > Try: int memcmp_2(const void *s1, const void *s2, unsigned long len) { signed char lt, gt; asm volatile("repe cmpsb ; " "seta %[lt] ; " "setb %[gt]" : "+D" (s1), "+S" (s2), "+c" (len), [lt] "=&q" (lt), [gt] "=&q" (gt) : : "cc", "memory"); return (signed char)(gt - lt); } https://www.godbolt.org/z/6hrxGxb18 Saves the XORs - go away completely in the usual case of 'if (memcpy(....))'. The 'mess' on the return statement moves the sign extend after the subtract. David From xen-devel-bounces@lists.xenproject.org Wed Sep 09 19:30:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 19:30:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413638.1643744 (Exim 4.92) (envelope-from ) id 1x4Nzs-00015U-Od; Wed, 09 Sep 2026 19:30:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413638.1643744; Wed, 09 Sep 2026 19:30:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Nzs-00015N-Lr; Wed, 09 Sep 2026 19:30:16 +0000 Received: by outflank-mailman (input) for mailman id 1413638; Wed, 09 Sep 2026 19:30:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Nzr-00015F-Cd for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 19:30:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Nzq-008d9S-Kz for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 21:30:14 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1b3c4-2eae-0a2a0a5409dd-0a2a4501d4c2-0 for ; Wed, 09 Sep 2026 21:30:12 +0200 Received: from [18.216.144.57] (helo=yurei.relay-egress.a.mail.umich.edu) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1b3c2-5984-0a2a45010019-12d89039b882-3 for ; Wed, 09 Sep 2026 21:30:11 +0200 Received: from cordial-tupilaq.authn-relay.a.mail.umich.edu (ip-10-0-73-96.us-east-2.compute.internal [10.0.73.96]) by yurei.relay-egress.a.mail.umich.edu with ESMTPS id 6AA1B3C2.133EE0D3.3FA85465.863495; Wed, 09 Sep 2026 15:30:10 -0400 Received: from mail-lr2-f12.google.com (mail-lr2-f12.google.com [74.125.230.76]) by cordial-tupilaq.authn-relay.a.mail.umich.edu with ESMTPSA id 6AA1B3C1.1D89F1BC.69C29CAE.2253200; Wed, 09 Sep 2026 15:30:09 -0400 Received: by mail-lr2-f12.google.com with SMTP id 38308e7fff4ca-3a2ff16c0e6so5486881fa.0 for ; Wed, 09 Sep 2026 12:30:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-2 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1788982210; bh=3qD7oKjtga1WJ5C1IefDKa3vD1bZ+h2/LGmahRIrgXQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Bq4nzcS4+2Blo9xL7PrBoPvqc9yyz1vMBSDaer2qa0m5eDa8xfE/K/ZsE8aXlV5Ug lym5HGJk0vxZLLoKJFssHc+bt2jR/3FY9OBiNQhLmDke6egEq/hSktrAi5cvIyZYUa aq4ooFm31HU6XFuXy9oUwW3eCWqolhpTR6tJvRUq/NsHxVLf4uawIzzZLBMV7ZBbGN YA7khTmYJVzU8tlpkobbE0ncjsNnutJ9Kxh5JL1Zk1EpTVxWBJULzEUzdVDPQbjPxQ +IPp0a90ntIO+ANLU1nIjZCzHdLGFIBn9z5VVYaJdEJuWWp7dgBaM64SLvoSin2jhX icUUVinACpYwg== Authentication-Results: cordial-tupilaq.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=74.125.230.76 (mail-lr2-f12.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvBypSZGbC0Ma/ZTHbijOIoLE1m9XXifHnyfHcYaSPn4xGSYOwWd80dPVk2Kj3rGAuBHAOQodOKEVTR4=@lists.xenproject.org X-Gm-Message-State: AFuF++nqVMWQRsxSnCrAlhmREnjxZBIMPydIcZH7aY9hxx3gg39qZtqP YeDSAt9EcNvmw1Cn55YTZRsbCqKlOBf7jpVE2ZKn9Fq6QmE7JFN2Ns+MOsVGHnL3GrWA/jrF83R e7hHkambOFCmgQxVuE9suvwGDIIzitzM= X-Received: by 2002:a05:651c:2121:b0:3a3:63a:bb06 with SMTP id 38308e7fff4ca-3a58d516346mr3673451fa.13.1788982207312; Wed, 09 Sep 2026 12:30:07 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-5-ecc269f268b7@xenproject.org> <99a68a9d-79f0-4090-b0ed-3afdddb57fd6@suse.com> In-Reply-To: <99a68a9d-79f0-4090-b0ed-3afdddb57fd6@suse.com> From: George Dunlap Date: Wed, 9 Sep 2026 20:29:54 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1XAVmO1-fFBfTxrYUyBqNyuO2Xjj88aughFA6ydXdhdZgdpTzeKlmyngPY Message-ID: Subject: Re: [PATCH v2 05/14] x86/pv: update guest LDT mappings using {populate,destroy}_perdomain_mapping() To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1788982212-1D47D757-B5783638/0/0 X-purgate-type: clean X-purgate-size: 3684 On Mon, Sep 7, 2026 at 5:06=E2=80=AFPM Jan Beulich wrot= e: > > On 02.09.2026 11:43, George Dunlap wrote: > > From: Roger Pau Monn=C3=A9 > > > > Until two patches ago, update_xen_slot_in_full_gdt() used the stashed > > With wording at the start here and ... > > > pointer in d->arch.pv.gdt_ldt_l1tab to update the incoming vCPU's page > > tables with Xen's GDT; this was previously necessary because > > map_domain_page() couldn't be called in a context switch. Having a > > handy pointer to an always-mapped version of the GDT/LDT L1 table, > > other sites which modify the table started using it for convenience, > > even if they weren't called from within a context switch. These > > include pv_map_ldt_shadow_page() and pv_destroy_ldt(). > > > > Continue the process of switching users of the stashed reference to use > > populate_perdomain_mapping() instead. > > > > pv_map_ldt_shadow_page() is, by definition, always modifying the > > currently-running vCPU: it runs from the #PF handler for a descriptor > > fetch on the guest's behalf, and running the guest implies its page > > tables are loaded. So it could simply write the linear recursive > > mappings directly. Go through populate_perdomain_mapping() anyway, to > > keep a single writer for the per-domain area. > > > > For pv_destroy_ldt(), use destroy_perdomain_mapping(). > > > > Previously, pv_destroy_ldt() used the L1 LDT entries themselves to > > determine which MFNs to drop type and count references to. Rather > > than reading from the stashed L1, keep the MFNs corresponding to L1 > > slots in an array in the vCPU structure, as we do in the GDT case. > > (Note that unlike the GDT case, these are not part of a public ABI, so > > can be mfn_t, avoiding a recast-and-copy.) > > > > Note that mappings_dropped (the return value of pv_destroy_ldt()) now > > reflects the *number of valid MFNs in this array*, not *the number of > > non-empty L1 entries*. This introduces an invariant we must maintain: > > pv_map_ldt_shadow_page() writes both the array entry and the mapping, > > and pv_destroy_ldt() clears both, so the two stay in lockstep. > > > > Also note that, unlike pv_destroy_gdt() from the previous patch, > > ... here adjusted as per the comment on the earlier patch, ... > > > pv_destroy_ldt() doesn't fill in the values with zero_l1e (see > > 61031e64d3), so there's no change here. > > > > Signed-off-by: Roger Pau Monn=C3=A9 > > Assisted-by: Claude Code:claude-fable-5, Claude Code:claude-opus-4-8 > > Signed-off-by: George Dunlap > > Reviewed-by: Jan Beulich > > On the basis that ... > > > --- a/xen/arch/x86/include/asm/domain.h > > +++ b/xen/arch/x86/include/asm/domain.h > > @@ -541,6 +541,8 @@ struct pv_vcpu > > struct trap_info *trap_ctxt; > > > > unsigned long gdt_frames[FIRST_RESERVED_GDT_PAGE]; > > + /* Max LDT entries is 8192, so 8192 * 8 =3D 64KiB (16 pages). */ > > + mfn_t ldt_frames[16]; > > unsigned long ldt_base; > > unsigned int gdt_ents, ldt_ents; > > ... this not really insignificant size increase is okay-ish as long as > struct hvm_vcpu is about three times the size (i.e. is still more than > double the size after this change). FYI it looks like by the end of the whole series struct pv_vcpu has net zero change: we add this array, but then move the mapcache structure out into arch_vcpu. In turn arch_vcpu by the end is an extra 256 bytes, but with some rearrangement, we can reduce padding and increase struct vcpu by only 192 bytes. -George From xen-devel-bounces@lists.xenproject.org Wed Sep 09 19:34:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 19:34:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413646.1643754 (Exim 4.92) (envelope-from ) id 1x4O3m-0001cr-8p; Wed, 09 Sep 2026 19:34:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413646.1643754; Wed, 09 Sep 2026 19:34:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4O3m-0001cj-59; Wed, 09 Sep 2026 19:34:18 +0000 Received: by outflank-mailman (input) for mailman id 1413646; Wed, 09 Sep 2026 19:34:16 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4O3k-0001cd-D3 for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 19:34:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4O3j-00EM76-QA for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 21:34:15 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1b4ad-e002-0a2a0a5209dd-0a2a4501ebd2-26 for ; Wed, 09 Sep 2026 21:34:15 +0200 Received: from [198.137.202.136] (helo=mail.zytor.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1b4b5-5984-0a2a45010019-c689ca88d2ec-3 for ; Wed, 09 Sep 2026 21:34:15 +0200 Received: from ehlo.thunderbird.net ([172.59.163.197]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 689JXmnX244897 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 9 Sep 2026 12:33:49 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=2026082801 header.d=zytor.com header.i="@zytor.com" header.h="Date:From:To:CC:Subject:In-Reply-To:References" DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 689JXmnX244897 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026082801; t=1788982429; bh=zueCsCe8V8E1QlZnV2vxZr3SDXS0e2EOBXgTRQRGVOU=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=OTxwCipdJVod32y/l/D4j0FczO8SKbm2ZoWd8aIFaiO6ez1D8NFPbCI8j6WlPH4Na o5pfzh5zO+vfUs9Jzd7JTjRDFyjybw8Ec+TdddlfKY03/7zDvLdipGCH4Enh1hyW/D RALHe0McqtQBHnJEf1ocjKKLSX8uCV8kMnmSZ6wfnIpm+X8+oDf1cqeViVXShJb7XF sZo0r2xRLDYI+JmRh8I66EqaSKGkVJzNrIHDpzwOuU3u0uXG1i0OBMyYNkhZ4lyPoA oPgntgef8wrDYCFWYJGKpiTmFWRN4KjZ3jM3vn0hfKx7vs+NvE9CwgTokZHI6xwifo tmAIjxV9iHeUw== Date: Wed, 09 Sep 2026 12:33:40 -0700 From: "H. Peter Anvin" To: David Laight CC: Borislav Petkov , Mauricio Faria de Oliveira , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() User-Agent: K-9 Mail for Android In-Reply-To: <20260909202838.28071bff@pumpkin> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> <20260909093831.095b89cb@pumpkin> <8b00b7d2-2bd3-4871-9908-9fe1568d2690@zytor.com> <20260909202838.28071bff@pumpkin> Message-ID: <95D5AACE-1D91-402A-9B6B-8D03C3D90705@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1788982455-BD341757-FA2FB682/0/0 X-purgate-type: clean X-purgate-size: 2660 On September 9, 2026 12:28:38 PM PDT, David Laight wrote: >On Wed, 9 Sep 2026 06:43:01 -0700 >"H=2E Peter Anvin" wrote: > >> On 2026-09-09 01:38, David Laight wrote: >> >> >> >> Here is an out-of-line compact memcmp() which works for both 16/32 a= nd 64 bits: >> >> =20 >> >>=20 >> >> >> >> On 64 bits it compiles to: >> >> >> >> 0000000000000000 : >> >> 0: 48 89 d1 mov %rdx,%rcx >> >> 3: 31 d2 xor %edx,%edx >> >> 5: 31 c0 xor %eax,%eax >> >> 7: f3 a6 repz cmpsb (%rdi),(%rsi) >> >> 9: 0f 97 c2 seta %dl >> >> c: 0f 92 c0 setb %al >> >> f: 29 d0 sub %edx,%eax =20 >> >=20 >> > That isn't the object code from the source =2E=2E=2E >> > =20 >> And that's the ultimate hint that a cut and paste error had happened=2E >>=20 >> This was the actual source code=2E >>=20 >> int memcmp(const void *s1, const void *s2, size_t len) >> { >> int lt, gt; >>=20 >> /* >> * Note: for the benefit of 64-bit code, xDI and xSI are reversed >> * compared with what CMPSB uses; hence SETA and SETB are also reve= rsed=2E >> * >> * The XOR statements set ZF =3D 1, CF =3D 0, which is required to = handle >> * the case len =3D=3D 0 correctly=2E >> */ >> asm volatile("xor %[lt],%[lt] ; " >> "xor %[gt],%[gt] ; " >> "repe cmpsb ; " >> "seta %b[lt] ; " >> "setb %b[gt]" >> : "+D" (s1), "+S" (s2), "+c" (len), >> [lt] "=3D&q" (lt), [gt] "=3D&q" (gt) >> : : "cc", "memory"); >> return gt - lt; >> } >>=20 > >Try: > >int memcmp_2(const void *s1, const void *s2, unsigned long len) >{ > signed char lt, gt; > > asm volatile("repe cmpsb ; " > "seta %[lt] ; " > "setb %[gt]" > : "+D" (s1), "+S" (s2), "+c" (len), > [lt] "=3D&q" (lt), [gt] "=3D&q" (gt) > : : "cc", "memory"); > return (signed char)(gt - lt); >} > >https://www=2Egodbolt=2Eorg/z/6hrxGxb18 > >Saves the XORs - go away completely in the usual case of 'if (memcpy(=2E= =2E=2E=2E))'=2E >The 'mess' on the return statement moves the sign extend after the >subtract=2E > >David The xors are explicitly in the asm to deal with the len =3D 0 case (this i= s for the out of line version!) We need to enter with ZF =3D 1 CF =3D 0=2E From xen-devel-bounces@lists.xenproject.org Wed Sep 09 20:07:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 20:07:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413664.1643762 (Exim 4.92) (envelope-from ) id 1x4OaE-0006Cc-PS; Wed, 09 Sep 2026 20:07:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413664.1643762; Wed, 09 Sep 2026 20:07:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4OaE-0006CU-M8; Wed, 09 Sep 2026 20:07:50 +0000 Received: by outflank-mailman (input) for mailman id 1413664; Wed, 09 Sep 2026 20:07:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4OaC-0006CG-MP for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 20:07:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4OaC-003nvY-2k for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 22:07:48 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1bc64-bab6-0a2a0a5309dd-0a2a450bce7a-28 for ; Wed, 09 Sep 2026 22:07:47 +0200 Received: from [52.101.56.15] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1bc92-b7e8-0a2a450b0019-3465380fbe6b-3 for ; Wed, 09 Sep 2026 22:07:47 +0200 Received: from BL1PR13CA0099.namprd13.prod.outlook.com (2603:10b6:208:2b9::14) by SJ0PR12MB6927.namprd12.prod.outlook.com (2603:10b6:a03:483::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.8; Wed, 9 Sep 2026 20:07:40 +0000 Received: from BN1PEPF00005FFD.namprd05.prod.outlook.com (2603:10b6:208:2b9:cafe::8a) by BL1PR13CA0099.outlook.office365.com (2603:10b6:208:2b9::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.5 via Frontend Transport; Wed, 9 Sep 2026 20:07:39 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00005FFD.mail.protection.outlook.com (10.167.243.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.5 via Frontend Transport; Wed, 9 Sep 2026 20:07:39 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 9 Sep 2026 15:07:39 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 9 Sep 2026 15:07:38 -0500 Received: from [192.168.19.2] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Wed, 9 Sep 2026 15:07:38 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r645R55wjpqgnhqxdzM/ms7FZSpnLRXeNWiZEt5YC2SQx2oUUPoEbRxWGJPZMapxIH8bPDHp4thObFYBYz1eFfaDQhMqHu6vJ6A0s067mFhgt3i1Aaan1bcYW675lFGb41udb0TWs/AqZXarlgmrkCwSsZkLPJcSBSgbMWQTUoBQJwBUvxfuWNO8lhZelexI1imPdQqeAEd64A2hhbxSsODOTG2hEEQyK6lDIqPp1FzzCFrnRd01R+ZH74/evtxdfp01Un4jK4XirNx0kQus4IMwaNut4LKdH7DbK5h9ZNHY0SiC46nLLP38zvr1xTqtew5GtNbsNUKbxDn0OghX6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/0gX/DTWEj0mwqiaGPrnbN628OX8x2I7RIGGS0EYmiQ=; b=rEQ9LzKW/dVssnGIvjEHTD6bdXswL6QU3+c+R8rPyfrjQ1FU1A1ysA7q8RRAxsNWc/AQb6KmcNxOnTOr1/8H0dJZ1tjKny1jCPkxcLDYyGv1r7WyrOt6jPEpvVMqpFi/XIj7bA3pnceCMUzdwdkOMe/bid0g+ILglcH0ZyZaN40lJsdvk6DIS2Qlo55Q+CCXVoMhuiOoC7lziOaUfpHPXq4YfZ8lOL40mT/QrM85wNL4+Nl8WzHLBHTRTv9aQ7vaXjvyt7Q3wTRILIG1l6kb2qkfqxbD2ACDeeLdfpVeTCpDycosXdER5wEmksAZFwi4mfMu8zy8RRChZcwuuv0Qmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/0gX/DTWEj0mwqiaGPrnbN628OX8x2I7RIGGS0EYmiQ=; b=va25Tgt5o6NRiAoYWAgJNvy5/EfvaaPR+tkMTQf1njAH/9Xk8OIhnW3Gv+++9/rHwRU+n+73D9bUsjE7/zvSn08BUPzQfno6/9TPeEr35EBzApwbiAhL5H1gSiRfmwkqZkIEH8cJeP6YgwBQtFt/GR867cGmC4gsDNM5jFNsScg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <22028c12-2400-4131-8e5e-b2dc7a65326f@amd.com> Date: Wed, 9 Sep 2026 16:07:32 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/mm: limit deferred TLB flushing to PV domain support To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , Stefano Stabellini , References: <20260909140500.73483-1-roger@xenproject.org> <92c9bf4b-5171-4a26-a62e-f2a7b1cb89ef@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00005FFD:EE_|SJ0PR12MB6927:EE_ X-MS-Office365-Filtering-Correlation-Id: aba6d6ff-9017-447a-6607-08df0eadffc1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|82310400026|1800799024|36860700016|6133799003|10067099003|11063799006|4143699003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: CvVI/nvndqp7wsWqPayQEv954hMYkt9Sc1dqkl2fYGOAcaEmSSSMAQgJgHUr7jVEEdkOGwKkrxs6LlQlS1DmIACcHwAK+BwMq5V8SxwR6dkePEDW9K+0bqWG3ch8XpbxMzQVO5bpmkjkXwvQ4m6Y6NB2wBnFYDgS5iSnC3LfK3FSGTSn6qdBaJYaFeR2ujMa9hu1+I0dI/AQqOLl2t8ZWqq0ow/7wtU/IyAIZnu5qH8wZ/Hj9FtbW9I24lQTfOxV2ZUM9orU2O82B2Ay0wEvQmlXMKMuQNClFtxbhuCR3qr8qShWqJgl8u9h4eGjK/ZDdnppfHynVz252w70NEsGOaYMzmQ61VKWHCnx6Ki7GLbPN4oS3vnTMUKjiimceLpmQp8xLgqxO/HZNX7xkHc/kR9RFkAmdrhdD+F7LL5bqmuZP/hiBRKCLqE91QGEpjlYzNQa3LvChmoobA+1w2et1AN0jKJfn601UvBKGU87FeABaH7U1iUHwg0vfpTFk74j8Li+3upYYnu5L+hOfdU4PiPgoa8JLOSRb3+ZHtxtMKfc6Gq5dn5oZVxm2IlZbQnXw4UgTU9omLvew4ciD9CqdWjg7T42CLJScO1VcZjsI4FnSVENImiKZUrY217ndiDClNg8htP7ki3v9jzciilgW+7tpBGpJJtCLhRt1DaMQTCnuLNZhoBM2usWM1qpg7ccj593CviUoEYJUmjQsOWeGA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(23010399003)(82310400026)(1800799024)(36860700016)(6133799003)(10067099003)(11063799006)(4143699003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: TuqQFBcxa5b8YsbsaQhhR1D1r5PupoqJ0ofHY3tFnVskzHKvA6bgbQCaZaDXDCrEPH+JFJeuroYASW4poZYU5eJM/P4BbQhEjYonmbSKZWDtVJh6UghlmskZLto942djsqhy5jAdP9rvS0YCIuK1CsCofHoWWzkNinfEKHi6zUE5kKDlSau8LvMuGP+TTmnuuGWnnKrn+jkb5qhNa8yDZcTTSc/+A1oIpu77Jlv5j30wbjnxQp1TZI8nBZthNEhKR6NnGC0WI41NA3ZyTxL5KpZ6Z5DnAhYec69NFlAkww1w9XPqRod/kmXoHjAm56YitXbccDrGRikV0XhXOqZrnk0tnk9h/LZ5sO5BqvTi0vzEZv3UpdTSAl/H7K1EFaA5L+zF08/nyoPybJBEuEj4s9MNotcHbbYmY9pOeX2YBGXOaC4B5F2q8FstUrSN0Ui4 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2026 20:07:39.2494 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aba6d6ff-9017-447a-6607-08df0eadffc1 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF00005FFD.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6927 X-purgate-ID: tlsNG-42698a/1788984467-1B4D39EA-79AF346B/0/0 X-purgate-type: clean X-purgate-size: 2206 On 2026-09-09 12:28, Roger Pau Monné wrote: > On Wed, Sep 09, 2026 at 04:46:01PM +0200, Jan Beulich wrote: >> On 09.09.2026 16:05, Roger Pau Monne wrote: >>> --- a/xen/common/page_alloc.c >>> +++ b/xen/common/page_alloc.c >>> @@ -1538,8 +1538,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) >>> BUG(); >>> } >>> >>> - /* If a page has no owner it will need no safety TLB flush. */ >>> - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); >>> + /* >>> + * If a page has no owner and there's no PV domain support it will need no >>> + * safety TLB flush, there can be no stale TLB entries. >>> + */ >>> + pg->u.free.need_tlbflush = IS_ENABLED(CONFIG_PV) && page_get_owner(pg); >>> if ( pg->u.free.need_tlbflush ) >>> page_set_tlbflush_timestamp(pg); >> >> I'm okay with the code change now, but the comment is still concerning me. >> All by itself there is no reason why stale TLB entries couldn't also exist >> for HVM guests. It's just that (a) only the host TLBs are flushed by >> filtered_flush_tlb_mask() and (b) flushes of guest TLBs occur when pages >> are removed from their P2Ms (aiui; hopefully true also for Arm). IOW what >> the comment says looks to be correct, just that it leaves too much to be >> figured out by the reader. At the very least I'd suggest "..., there can >> be no stale (host) TLB entries." Thoughts? > > Hm, I find adding "(host)" to also be slightly confusing, as I would > usually associate host TLB with Xen context TLB state. Which is also > made more confusing by how PV guests share the page-tables with Xen. > > "If a page has no owner and there's no PV domain support it will need > no safety TLB flush. PV domains are the only domain types that can > keep stale entries on the TLB, as they have (limited) control over the > host MMU and when flushes are performed" I find "will need no" a little awkward. Maybe: "If a page has no owner and there's no PV domain support it does not need a safety TLB flush." or: "If a page has no owner and there's no PV domain support, then a safety TLB flush is not needed." Regards, Jason From xen-devel-bounces@lists.xenproject.org Wed Sep 09 21:40:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 21:40:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413715.1643771 (Exim 4.92) (envelope-from ) id 1x4Q1M-0001Ch-4D; Wed, 09 Sep 2026 21:39:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413715.1643771; Wed, 09 Sep 2026 21:39:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Q1M-0001Ca-0e; Wed, 09 Sep 2026 21:39:56 +0000 Received: by outflank-mailman (input) for mailman id 1413715; Wed, 09 Sep 2026 21:39:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Q1L-0001CP-1X for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 21:39:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Q1J-00DcVO-MJ for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 23:39:53 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1d1c8-e002-0a2a0a5209dd-0a2a4506e4ac-42 for ; Wed, 09 Sep 2026 23:39:53 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1d229-195a-0a2a45060019-4a7de14caf29-3 for ; Wed, 09 Sep 2026 23:39:53 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356256so1157387f8f.1 for ; Wed, 09 Sep 2026 14:39:53 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4859162f354sm38982359f8f.20.2026.09.09.14.39.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Sep 2026 14:39:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788989993; x=1789594793; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=GEVD0ONiRBgZcGn2NlyLse7rj8h6967aW8UFFN5/dyY=; b=KkQ+6j3mSfvIznSip3tN9o6tjzAfJ4pifM2kJR1AnSJYonMXwh1Wx0KVTV30Owezh/ f1j1+gjD/CibEvT1KCs6oMa1VEEjN5TravUSvJ6SespW13xFlt3XNLAmJeFLA9ojeTRx /Gn0DpvKzIXGIE5zys1egE9yStBnUY9xMuMAWgoe/02cEm7t/EAnFPuivWqu+trx5ePT T/EirEnF5To/EVmXeiFwDD4+cnfAuuXMfdT9RK4ob5qWSFnaurH/Q594KsH70HSWYW+n MNoxuPijULnvmtwIVhKnsedJdZtuwCuspLOYTdLTKW26bGWgAQoxPzozJcr2MZeJyNrS FoiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788989993; x=1789594793; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=GEVD0ONiRBgZcGn2NlyLse7rj8h6967aW8UFFN5/dyY=; b=HTkzvYEZa8KyIfllap4/w/co0KrFod3X0xSyECvo8VDelT52qIcpOwjcZTJalX05h5 q70q79+i5eHFriUGUTJr8+UHgB9O+//5N+E2KS7w5BVb3n5CP/zKEuKDoxhXFy5dNg8U UPz5BpZNYzBnshAfBXJ5KkE68VDMeTBu/++0D2mm+aLcXpcn8N3XRvUWhsYK0cUyzI0i XbI8uv3TB7Gy79UZKZN8RGTzfsE2/5XNow3b4ZrD/UK1PkR0u286rNqAGsgXAvLJWRf8 NtLzT+mRCRyxjSVi7z1jj7r0itUeI7koFfZlDk8uIj5QF58np6Xwtj29eTGo+fRWauI6 ClFQ== X-Forwarded-Encrypted: i=1; AKwUvBw3Xx3Oc7JcVvbo6+DACFo5+N/KMqlThUJTfqOE1UKSSDaxjyxQfr7yMDvDW0gY7NU/ezIJHeuDXII=@lists.xenproject.org X-Gm-Message-State: AFuF++m63X2NyzPrN+QP6pwoDPuyPYTB8AHZtDvQSyGqELEo/Z8yoaET FYmU9h7dNJvvyTZ1BdGF4YWIKKlp/Tcsbft9LZyi0vPROP9zClOssRRu X-Gm-Gg: AYBFou0UJj+K0l6wKgf92Q501Hn5L08bUYPvvHXZsjn9XOaa8F9j4cExzrT9rQ1OiT7 hKR+XQltcP+qNXgow7o+j/HNU41Rejk/0N6Zl//2nG6nbKpECV3hNF2WUzmVM50k1Fewzyt+JOB qtzOoiV1PMeyAiu0vX/Mkrzdlin84b2CdeZBJD1iKmUUY4ZcG9JyErM3Q7QSrqsrZvGb2rHwfjM RRIYYLjWTjqT7sP+ConHi+qIeXB8/zfVVMQ2ITJjKGRKvRko1W3Jm4kWZH9JXZgv/MZN+sRIyCI p9H/9OskKy9+Z/Ge5rbENTfgQxetjJLGmh5HtpsjESGLND/xupHaoIxbjoxIMy2v5R5iiaSVAV0 uS6hYLO+D0t7ukjATZJczv9ztPpSuW4tn1Xw/wcl64lLBdzobQMmBDetgtkK/dA3hGrb8l8c3Nh 4GKCOgaYCjPMHfHsCoC57gcAes4kr3Oh9hebxl/fhJq1wzd4iQtZBKXAaofcQGb83YZgHkvcyO7 Rq7nBbaN6IXpSL+u53i0UJ13dHHYYmyB/7m X-Received: by 2002:a05:6000:4607:b0:485:a32b:1ee8 with SMTP id ffacd0b85a97d-486e0fa01ecmr1480012f8f.20.1788989992817; Wed, 09 Sep 2026 14:39:52 -0700 (PDT) Date: Wed, 9 Sep 2026 22:39:51 +0100 From: David Laight To: "H. Peter Anvin" Cc: Borislav Petkov , Mauricio Faria de Oliveira , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() Message-ID: <20260909223951.1fe5fe25@pumpkin> In-Reply-To: <95D5AACE-1D91-402A-9B6B-8D03C3D90705@zytor.com> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> <20260909093831.095b89cb@pumpkin> <8b00b7d2-2bd3-4871-9908-9fe1568d2690@zytor.com> <20260909202838.28071bff@pumpkin> <95D5AACE-1D91-402A-9B6B-8D03C3D90705@zytor.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1788989993-1F4C977B-9668A1B8/0/0 X-purgate-type: clean X-purgate-size: 2982 On Wed, 09 Sep 2026 12:33:40 -0700 "H. Peter Anvin" wrote: > On September 9, 2026 12:28:38 PM PDT, David Laight wrote: > >On Wed, 9 Sep 2026 06:43:01 -0700 > >"H. Peter Anvin" wrote: > > > >> On 2026-09-09 01:38, David Laight wrote: > >> >> > >> >> Here is an out-of-line compact memcmp() which works for both 16/32 and 64 bits: > >> >> > >> > >> > >> >> > >> >> On 64 bits it compiles to: > >> >> > >> >> 0000000000000000 : > >> >> 0: 48 89 d1 mov %rdx,%rcx > >> >> 3: 31 d2 xor %edx,%edx > >> >> 5: 31 c0 xor %eax,%eax > >> >> 7: f3 a6 repz cmpsb (%rdi),(%rsi) > >> >> 9: 0f 97 c2 seta %dl > >> >> c: 0f 92 c0 setb %al > >> >> f: 29 d0 sub %edx,%eax > >> > > >> > That isn't the object code from the source ... > >> > > >> And that's the ultimate hint that a cut and paste error had happened. > >> > >> This was the actual source code. > >> > >> int memcmp(const void *s1, const void *s2, size_t len) > >> { > >> int lt, gt; > >> > >> /* > >> * Note: for the benefit of 64-bit code, xDI and xSI are reversed > >> * compared with what CMPSB uses; hence SETA and SETB are also reversed. > >> * > >> * The XOR statements set ZF = 1, CF = 0, which is required to handle > >> * the case len == 0 correctly. > >> */ > >> asm volatile("xor %[lt],%[lt] ; " > >> "xor %[gt],%[gt] ; " > >> "repe cmpsb ; " > >> "seta %b[lt] ; " > >> "setb %b[gt]" > >> : "+D" (s1), "+S" (s2), "+c" (len), > >> [lt] "=&q" (lt), [gt] "=&q" (gt) > >> : : "cc", "memory"); > >> return gt - lt; > >> } > >> > > > >Try: > > > >int memcmp_2(const void *s1, const void *s2, unsigned long len) > >{ > > signed char lt, gt; > > > > asm volatile("repe cmpsb ; " > > "seta %[lt] ; " > > "setb %[gt]" > > : "+D" (s1), "+S" (s2), "+c" (len), > > [lt] "=&q" (lt), [gt] "=&q" (gt) > > : : "cc", "memory"); > > return (signed char)(gt - lt); > >} > > > >https://www.godbolt.org/z/6hrxGxb18 > > > >Saves the XORs - go away completely in the usual case of 'if (memcpy(....))'. > >The 'mess' on the return statement moves the sign extend after the > >subtract. > > > >David > > The xors are explicitly in the asm to deal with the len = 0 case (this is for the out of line version!) > > We need to enter with ZF = 1 CF = 0. And, of course, I knew that. They also zero the high 24bits of the registers. Given the setup cost of 'repe cmpsb' I suspect the xor just add code bytes. David From xen-devel-bounces@lists.xenproject.org Wed Sep 09 23:13:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 09 Sep 2026 23:13:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413752.1643780 (Exim 4.92) (envelope-from ) id 1x4RTT-0005xm-GN; Wed, 09 Sep 2026 23:13:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413752.1643780; Wed, 09 Sep 2026 23:13:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4RTT-0005xf-Dm; Wed, 09 Sep 2026 23:13:03 +0000 Received: by outflank-mailman (input) for mailman id 1413752; Wed, 09 Sep 2026 23:13:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4RTR-0005xU-WF for xen-devel@lists.xenproject.org; Wed, 09 Sep 2026 23:13:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4RTR-008sTW-5A for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 01:13:01 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa1e7b2-e002-0a2a0a5209dd-0a2a450becd2-42 for ; Thu, 10 Sep 2026 01:13:00 +0200 Received: from [198.137.202.136] (helo=mail.zytor.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa1e7fb-b7e8-0a2a450b0019-c689ca88dcc0-3 for ; Thu, 10 Sep 2026 01:13:00 +0200 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 689NCRHa620834 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 9 Sep 2026 16:12:28 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=2026082801 header.d=zytor.com header.i="@zytor.com" header.h="Date:From:To:CC:Subject:In-Reply-To:References" DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 689NCRHa620834 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026082801; t=1788995549; bh=R/8nMPS3dvCdQrQ8+hytYRqJVY0aLJ29jddBRs4THwo=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=BfXbzxtQljma3DPp+z1n7nZZBVIiCTYHFVbmngpcJlUb9S/8wubQ3mPZaZgtqGyUe w2sG6l/nWEpiKuI2fQ8IeODF2F6YGEfrGyurEObB9+BWseQYUpCyx0dDOb/7ip59ZE PUXdAZixQkKfdXJuF0iixatU7BhJ05RHO3S0phCXNd4RBHiGgOHLZXGpcdX/uWLbvV 96lwK16wsBjytCqOLQZ5cL0aYbU4tcH1bAhLHPN04Tpgwez2bgkBtj8+OHpZQg5riS BembEYyOZqW7I6whRYJEDBqd0SPEvgVJrnRr9QV9WVUsEKxPiFQ5OMUvtGvjmS8i+9 lT+oljNGv5q1A== Date: Wed, 09 Sep 2026 16:12:20 -0700 From: "H. Peter Anvin" To: David Laight CC: Borislav Petkov , Mauricio Faria de Oliveira , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() User-Agent: K-9 Mail for Android In-Reply-To: <20260909223951.1fe5fe25@pumpkin> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> <20260909093831.095b89cb@pumpkin> <8b00b7d2-2bd3-4871-9908-9fe1568d2690@zytor.com> <20260909202838.28071bff@pumpkin> <95D5AACE-1D91-402A-9B6B-8D03C3D90705@zytor.com> <20260909223951.1fe5fe25@pumpkin> Message-ID: <7046AFCC-2E5C-438B-BF53-907F09640572@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1788995580-A9AC09EA-91FFE0AA/0/0 X-purgate-type: clean X-purgate-size: 3366 On September 9, 2026 2:39:51 PM PDT, David Laight wrote: >On Wed, 09 Sep 2026 12:33:40 -0700 >"H=2E Peter Anvin" wrote: > >> On September 9, 2026 12:28:38 PM PDT, David Laight wrote: >> >On Wed, 9 Sep 2026 06:43:01 -0700 >> >"H=2E Peter Anvin" wrote: >> > =20 >> >> On 2026-09-09 01:38, David Laight wrote: =20 >> >> >> >> >> >> Here is an out-of-line compact memcmp() which works for both 16/3= 2 and 64 bits: >> >> >> =20 >> >> >> >> =20 >> >> >> >> >> >> On 64 bits it compiles to: >> >> >> >> >> >> 0000000000000000 : >> >> >> 0: 48 89 d1 mov %rdx,%rcx >> >> >> 3: 31 d2 xor %edx,%edx >> >> >> 5: 31 c0 xor %eax,%eax >> >> >> 7: f3 a6 repz cmpsb (%rdi),(%rsi) >> >> >> 9: 0f 97 c2 seta %dl >> >> >> c: 0f 92 c0 setb %al >> >> >> f: 29 d0 sub %edx,%eax =20 >> >> >=20 >> >> > That isn't the object code from the source =2E=2E=2E >> >> > =20 >> >> And that's the ultimate hint that a cut and paste error had happened= =2E >> >>=20 >> >> This was the actual source code=2E >> >>=20 >> >> int memcmp(const void *s1, const void *s2, size_t len) >> >> { >> >> int lt, gt; >> >>=20 >> >> /* >> >> * Note: for the benefit of 64-bit code, xDI and xSI are reverse= d >> >> * compared with what CMPSB uses; hence SETA and SETB are also r= eversed=2E >> >> * >> >> * The XOR statements set ZF =3D 1, CF =3D 0, which is required = to handle >> >> * the case len =3D=3D 0 correctly=2E >> >> */ >> >> asm volatile("xor %[lt],%[lt] ; " >> >> "xor %[gt],%[gt] ; " >> >> "repe cmpsb ; " >> >> "seta %b[lt] ; " >> >> "setb %b[gt]" >> >> : "+D" (s1), "+S" (s2), "+c" (len), >> >> [lt] "=3D&q" (lt), [gt] "=3D&q" (gt) >> >> : : "cc", "memory"); >> >> return gt - lt; >> >> } >> >> =20 >> > >> >Try: >> > >> >int memcmp_2(const void *s1, const void *s2, unsigned long len) >> >{ >> > signed char lt, gt; >> > >> > asm volatile("repe cmpsb ; " >> > "seta %[lt] ; " >> > "setb %[gt]" >> > : "+D" (s1), "+S" (s2), "+c" (len), >> > [lt] "=3D&q" (lt), [gt] "=3D&q" (gt) >> > : : "cc", "memory"); >> > return (signed char)(gt - lt); >> >} >> > >> >https://www=2Egodbolt=2Eorg/z/6hrxGxb18 >> > >> >Saves the XORs - go away completely in the usual case of 'if (memcpy(= =2E=2E=2E=2E))'=2E >> >The 'mess' on the return statement moves the sign extend after the >> >subtract=2E >> > >> >David =20 >>=20 >> The xors are explicitly in the asm to deal with the len =3D 0 case (thi= s is for the out of line version!) >>=20 >> We need to enter with ZF =3D 1 CF =3D 0=2E > >And, of course, I knew that=2E >They also zero the high 24bits of the registers=2E >Given the setup cost of 'repe cmpsb' I suspect the xor just add code >bytes=2E > >David > > The XOR is cheaper than the sign extend; look at the object code=2E From xen-devel-bounces@lists.xenproject.org Thu Sep 10 01:52:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 01:52:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413823.1643789 (Exim 4.92) (envelope-from ) id 1x4TxC-0000hO-9j; Thu, 10 Sep 2026 01:51:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413823.1643789; Thu, 10 Sep 2026 01:51:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4TxC-0000hG-4W; Thu, 10 Sep 2026 01:51:54 +0000 Received: by outflank-mailman (input) for mailman id 1413823; Thu, 10 Sep 2026 01:51:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Tx8-0000hA-Cr for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 01:51:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Tx7-003ooe-0y for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 03:51:49 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa20d32-2eae-0a2a0a5409dd-0a2a450487f4-12 for ; Thu, 10 Sep 2026 03:51:48 +0200 Received: from [40.107.74.114] (helo=OS0P286CU010.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa20d2f-b57f-0a2a45040019-286b4a7288d2-3 for ; Thu, 10 Sep 2026 03:51:46 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TYWP286MB2038.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:161::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 01:51:38 +0000 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 01:51:38 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yaoOM8qvPbWGGZLtQkG8nI+TlO7N5aMpdffK4r5r+sApO0Sv9AUKOBruwH3gSHy0diQb9UZxL3Nr02KAsWnJyHbmE4H0uLPZx2DaRlrdaKb36EsJBavflYJ1gGkAai2davtsZJcePlusYOYtWsXnsr3NSZ1DOekIf8a8n05SS/+2CzCJAnYzJR1VL+Rz5qf0yQOOKHtyR/s24sf1FTTJdO2YA5UgqetpNL/L7UrfQSNX54qjClmItR/Nk1A+/fzxy8rxEGslh/UbF/7V28tr7SknKfsPc5te6iFanceSSjL684AIJfVVQ06bPjSMvlPF/uC5t20U5RD+XoxqWfdKkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z9SXJSpG8g7QWZVOE/XglaywWgnT/jl6lCS9gJOAu80=; b=UiaoNxgIbpKNHC0wkIFU9wrRQq0QHbXlujzODTTbfm3uSzV6YtHiYBdUBCG7eyIqYn5wJ7GghtjxFEhMLofpfB+5WcTb+nRZxaWwkbow/riweXYlYYDcm1ztlRPF1kPb1i3Cf01FSCzDpi8kuFOg+/68w3EZg0vw5NXOxt2BBCgMahdSiAyVoY+yU97OxHl78rQBMmH9LSyhB19vWM1PNxWC9LEl6WswA0aX9FUxHWXEqbhUm+cWWgsjlaHMGzoJb0KcQPVPFFKXn+CM0Gg7saaeiGl9KfVcjLsrv6HJRbd7U9ma3lI3eiXdqp35y9IK6SJvSbB1NqJy8n2iDpBYSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z9SXJSpG8g7QWZVOE/XglaywWgnT/jl6lCS9gJOAu80=; b=F8fMSMUWJGDDl7ubqb6j5J5fp2lo4YwXa8uQqp2JvmdvnNHakfxJT7dFlNysliq1tB6lS8DNNvxus41P29hYnHlTsB/EIIJeeDxB1xFwr51BnPMw3QvHpjwaNv5oyb3MQG8q3YTqZ0NdMDVC4Ieky3Yw+r1fhrWNnyi6dy8VqTk= From: Hirokazu Takahashi To: "Orzel, Michal" , "xen-devel@lists.xenproject.org" CC: "Mykyta_Poturai@epam.com" , Jan Beulich , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH v9 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Thread-Topic: [PATCH v9 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Thread-Index: AQHdHk7mICxhGBSPnk+jOkY/FjDeULbFDJ0AgAI+6BA= Date: Thu, 10 Sep 2026 01:51:38 +0000 Message-ID: References: <20260728050642.411240-1-taka@valinux.co.jp> <20260728050642.411240-2-taka@valinux.co.jp> <47b25166-c689-4e31-a161-f68001ca777b@amd.com> In-Reply-To: <47b25166-c689-4e31-a161-f68001ca777b@amd.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: OS9P286MB7222:EE_|TYWP286MB2038:EE_ x-ms-office365-filtering-correlation-id: 55b16656-f1c9-4b7e-49aa-08df0ede0d79 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|7416014|376014|22082099003|18002099003|56012099006|3023799007|38070700021|10067099003|4143699003; x-microsoft-antispam-message-info: YDtzNvz8D3ji+WDYKL1zRcj1BxGjoSfrgFTjhGU4R6JSL8sEik9ulWW+tTl4nU1jeByBaP9+pRk8WHUjxeR34fHZ77cfrpJ+pNT7Q5iHI87CtlDQuZIlLpbwftBKN1vb3TzYuYHB03ubNl29s32dFOVIaJ0ZOpf9s7EvyzWUpCUA/pW+BCIDHD4pgjMLuV8L1G1RnEM3Z1y3jatloyIEYWc4GyAy6WZ95U1yUGboce0VP8u+hCVMqH2xCe2WWhf2pHHBo3xvmZKKPkBUsQP54dyDr3eM2vvHKdPA6hPD/lyneHiHsnpKoRTDk4O+aHWnawMRh3bnbAuvC6bOZYM7RA7uGopITlfgsVcdWIEcnGfiXkA7MeSnANsgK7KD6YyqA38Azzrc7zcpKzF/1n9huTZ5GuAjs1s0UjkTmeuDXEsErjcl+3uHy1mW6G9mCqddaBa+3blwMRhRhS44skkpLKePvhjs1iyNzayCu+a1ii621iFAU0WNpJGo4tDSoipGYH4HNFsS5F+IA+LNtxaqMBrc2TD+t2pwlWDVrwKAJXmhQLbi0FszNeRTFLZ4CrVx4UDYtqNYs/iv2MVOUxUag7M4MesT02beIFl0NCzMnfFJUB3ZlFWZT8c2wtwE+oTQB5RvNzMIFAoDKK23UPSFOClLRUvTYYxRX9uveOVZKR62UH1bw0UCSMVbUJNZHeje++hgc7JN1v1nrVZVJwNYNX7yq03HjHUsYHyJpx/fKIc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(7416014)(376014)(22082099003)(18002099003)(56012099006)(3023799007)(38070700021)(10067099003)(4143699003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZkdzbVpFcVZaS3dNVUtFb0lCRWVJV05zOUF0bzZ3Y3RuZHMzVFFWc3VYci80?= =?utf-8?B?NFhEMHBxTlBJeXVUYS9uRi9KR3lYZkc5Y3g0SDhjRERaQXV0Q3ZGaS9WVjNE?= =?utf-8?B?VEFZOUhDaGZ1cGZHODNSdFEwd0pveFJEMVVOZTdzaDJyOGVnVGV1c0NYaThO?= =?utf-8?B?WmVuM0ZGbU5MbUxyQmZmVmkwZEtsRmxQVWVrU3BPbnpWMm5OeW56OG9SSkg1?= =?utf-8?B?Nnc0eXBWaVdaTmt3ZGozU1FwR005aXg4Yy9xSDlReVRrQWZCMXJ2ZEd2bWxM?= =?utf-8?B?TlArQ1FvOXRlb2ErYURuKy9jcmtQd213WlFnTzkweURnZ3BXamlmQlM4VHEy?= =?utf-8?B?NFgzTEI4dDljTFFaRFY2VWNXZ25DZkt3Y3BoK3dTdW1zanRzYlZuRFZGdThJ?= =?utf-8?B?YThZd2lvM24yNG91RmdPekVyaXM4d3lkZ01BZmF0cjk5NHlleE0yc0xKZFhs?= =?utf-8?B?cTBraUFTb0p2Sk9GRjNYeDRaRjBFdC96S2pxQWpLZnZZOC9STVFIOElYRmxW?= =?utf-8?B?MlV4TDVlR2dFenV5Z296WlRxbFlJdnJqdmpnQ0hhRGIrZEpxaGZ4aGYxendD?= =?utf-8?B?L25pUm5JaUsxWDUzMThWZ3lZajNaajltN0ZRUjdaZUJ3WUtFeU1ETGxhbFdz?= =?utf-8?B?Z1FLMjFWZmNud3pXSmpjQnVVaE1xZnFvb0x5YVZyekNBcjJINHk5OURjcUFS?= =?utf-8?B?TW5VeEd0MHdKYVAvWlozVWZGelVicTF3UEFNL2taMFB6ckwvS3pNOEpBREcw?= =?utf-8?B?SzRmN2V3RG5neGNqbzlEUjlXREpoYjRNMUtPaldmUTluL2lXdzJFSys0bmQ0?= =?utf-8?B?V3o3Q21JcmpkUm9BMTRZNGVkYm9OK2k2c0pEUFFaTm90RmtzaHZiaVRaT2M4?= =?utf-8?B?dFVLaU9EdGdzcUsyWXY4SHpTMTRjbDdPSDNxQUZhM1JnTkNieGlvVjc2emVi?= =?utf-8?B?K2VZS2xicVRJcloxK000YjZ0T0pkendhOE1ubWZRdm4xTFZjaEZsT2hPWUpE?= =?utf-8?B?akJPc2RtRWVsN1U5MmhRS2NLS2czZ1hqekl2NUEyQ2c3RGtxcCtpTGhNYWQ3?= =?utf-8?B?ZWFrcFRFWG5TRE1CUlJLQy8rV2JPV2FmZkF2dSt0TWloNi9uZk40d1RhNGN3?= =?utf-8?B?M3hhSWZRNW5kTERZSUlXNWNTQ0pDQ2RwT21UUG1oNFBBQ0JXNU1nSUlva0dr?= =?utf-8?B?UEpCR29JY1BIVU4rZG14VHVPNnFhNXhiZ281M0pUb2ZhK3RpVkdRcGVrczkz?= =?utf-8?B?czFQZk0yZE1pbWpVTHRraU84ak1zMFNTYzhlVkdzSUw3cVlqSjRpNEprVk93?= =?utf-8?B?VHJZb1JRNmFuby96L3hsMFB1V3VMbE5EY01oN1o3bk9YaWRIVmxMTXBic2hC?= =?utf-8?B?NEo5MWJad3Vrc2g2WlhwbWM3bitiYWJzN2dnT2NrQ2x5Ylh6dmlzOFZFQW5J?= =?utf-8?B?REtIekVMVUNld29sTnZVc2NrMm04ZjVlYUtMT3JvOUpIdGhNMWQxT3BKY3R6?= =?utf-8?B?djZsRGcwdGg5cDY5aWlsSGhIN1ZmMkRLbzh3UHo2bHJvUEFSOUs1T0E5ZU4w?= =?utf-8?B?UldRdEFJVHUyWU56Ym11OTZVeXkxaVFKNXc2RERLSDYzL09zdUlXNm9FemUx?= =?utf-8?B?N09PdVRKa2VIQlFzeFBGZVg2cE9ybzk5N3BxRGtiMnh2SlRMTXN3TjBwS1p2?= =?utf-8?B?YjJxdzFYelhzVzZpU09WalE4MEFBLzFrbUlGb1hEeUdXSTZySUI0NnNhU09H?= =?utf-8?B?cmZHZUdLc2dnRFcxTk9SL3RrWjFGUFgrRHFJVE1yRlNqbFN5bHYvV2dERGc4?= =?utf-8?B?VFpkekNXTGRXNVFQdUtXTU9abFVVT0Z0VDRIdmVMM1N0dTBUTjJyNlRmQ1g0?= =?utf-8?B?WDJmS2NrOWk3REU2a0JpSFRJWEp2VDZud04vY2MwOTFwQkg2TjVWL3BIeGFv?= =?utf-8?B?eWNpUWxzSmJxM002WHlPL09zYjhIaGMrWmFaSFRGaHlrQURoQW9xSHdDeWcy?= =?utf-8?B?NkFNblE3Kzl2eVhDZWdvaVZ1TStmUE00cU5GMUdwYXNQcFhZeDRuVGlpQnJn?= =?utf-8?B?bGxUUjZnNm9rUU41Sk8reGs1bnNrN3ZWSDhsTVNHQUVYSjB5Z3VnbU00Rmxr?= =?utf-8?B?OXJuNkc0TWZkQTIzdHgrQzlZQzVDd2dWQnBxK0pmekkyaFVwaVlBYktJenl4?= =?utf-8?B?aGQ4WVJuS3hRSDBzZWtZckJmU0tRWE14QVlsVkRMdjhYd0F4OVFRUlVQeVZ3?= =?utf-8?B?ZFYvUWZMZmJ0Q2NjR1BBUFBiS0RLWC9RVENzRS9YNVplOWl0VnI5ZTBwOVla?= =?utf-8?Q?fCrzSXsgU7QVpGG7qH?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 55b16656-f1c9-4b7e-49aa-08df0ede0d79 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2026 01:51:38.0291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y7sagFiB+WtVexbQxsA0xlsg5P+cqAtA9yYUCRyOC6aqVeLiSL/QT5e8UR7fQV8APMKGLHUZwRdTV8tW40p14A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYWP286MB2038 X-purgate-ID: tlsNG-ebf023/1789005108-583C0B50-184CCD11/0/0 X-purgate-type: clean X-purgate-size: 10518 SGkgTWljaGFsLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBmZWVkYmFjay4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPcnplbCwgTWljaGFsIDxtaWNoYWwub3J6ZWxAYW1k LmNvbT4NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgOSwgMjAyNiAxMjoxNCBBTQ0KPiBU bzogSGlyb2thenUgVGFrYWhhc2hpIDx0YWthQHZhbGludXguY28uanA+OyB4ZW4tZGV2ZWxAbGlz dHMueGVucHJvamVjdC5vcmcNCj4gQ2M6IE15a3l0YV9Qb3R1cmFpQGVwYW0uY29tOyBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+OyBTdGVmYW5vDQo+IFN0YWJlbGxpbmkgPHNzdGFiZWxs aW5pQGtlcm5lbC5vcmc+OyBKdWxpZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsgQmVydHJhbmQN Cj4gTWFycXVpcyA8YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPjsgVm9sb2R5bXlyIEJhYmNodWsN Cj4gPFZvbG9keW15cl9CYWJjaHVrQGVwYW0uY29tPjsgQW5kcmV3IENvb3Blcg0KPiA8YW5kcmV3 LmNvb3BlcjNAY2l0cml4LmNvbT47IEFudGhvbnkgUEVSQVJEDQo+IDxhbnRob255LnBlcmFyZEB2 YXRlcy50ZWNoPjsgUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXJAeGVucHJvamVjdC5vcmc+DQo+IFN1 YmplY3Q6IFJlOiBbUEFUQ0ggdjkgMS80XSB4ZW4vZGV2aWNlLXRyZWU6IFBhcnNlICdjcHUtbWFw JyBub2RlIGZvciBDUFUNCj4gdG9wb2xvZ3kgZXhwbG9yYXRpb24NCj4gDQo+IA0KPiANCj4gT24g MjgtSnVsLTI2IDA3OjA2LCBIaXJva2F6dSBUYWthaGFzaGkgd3JvdGU6DQo+ID4gUGFyc2UgdGhl ICdjcHUtbWFwJyBub2RlIGluIHRoZSBEZXZpY2UgVHJlZSB0byBleHRyYWN0IENQVSB0b3BvbG9n eQ0KPiA+IGluZm9ybWF0aW9uLiBJZiB0aGUgJ2NwdS1tYXAnIG5vZGUgaXMgYWJzZW50LCBmYWxs IGJhY2sgdG8NCj4gPiBnZW5lcmF0aW5nIHRoZSB0b3BvbG9neSBkYXRhIGZyb20gdGhlIE5VTUEg aW5mb3JtYXRpb24uIFRoaXMNCj4gPiBnZW5lcmF0aW9uIGFzc3VtZXMgZXhhY3RseSBvbmUgc29j a2V0IHBlciBOVU1BIG5vZGUgYW5kIHRoYXQgU01UDQo+ID4gaXMgdW5zdXBwb3J0ZWQuDQo+IFRo aXMgZG9lcyBub3Qgc2VlbSB0byByZWZsZWN0IHRoZSBpbXBsZW1lbnRhdGlvbi4gSWYgdGhlcmUg aXMgbm8gYGNwdS1tYXBgIG5vZGUsDQo+IHlvdSBqdXN0IHJldHVybiBlcnJvciBhbmQgZnJlZSB0 aGUgdGFibGUuDQoNCkkgZm9yZ290IHRvIHVwZGF0ZSB0aGUgZGVzY3JpcHRpb24gZnJvbSBhbiBl YXJsaWVyIGltcGxlbWVudGF0aW9uLiBJIHdpbGwgZml4DQp0aGUgY29tbWl0IG1lc3NhZ2UuDQoN Cj4gPiAtLS0gL2Rldi9udWxsDQo+ID4gKysrIGIveGVuL2NvbW1vbi9jcHUtdG9wb2xvZ3kuYw0K PiA+IEBAIC0wLDAgKzEsNjIgQEANCj4gPiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQ TC0yLjAtb3ItbGF0ZXIgKi8NCj4gVGhlIG1haW4gbGljZW5zZSBmb3IgWGVuIGlzIEdQTHYyLW9u bHkuIEFueSByZWFzb24gZm9yIEdQTHYyKyBpbiB0aGUgbmV3DQo+IGZpbGVzPw0KPiBJJ20gYXNr aW5nIGJlY2F1c2UgaWYgeW91IGRvbid0IGNhcmUgYWJvdXQgdGhlIGxpY2Vuc2UgYW5kIHNpbXBs eSBjb3BpZWQgaXQgZnJvbQ0KPiBvdGhlciBwbGFjZXMsIHYyLW9ubHkgaXMgYSBiZXR0ZXIgZml0 IGZvciBzb21lIG9yZ2FuaXphdGlvbnMgdGhhdCBjYW5ub3QNCj4gY29udHJpYnV0ZSB0byB2Misu DQoNCk9rYXkuDQoNCj4gPiArdm9pZCBfX2luaXQgaW5pdF9jcHVfdG9wb2xvZ3kodm9pZCkNCj4g PiArew0KPiA+ICsgICAgdW5zaWduZWQgaW50IGNwdTsNCj4gPiArICAgIGludCByZXQ7DQo+ID4g Kw0KPiA+ICsgICAgY3B1X3RvcG9sb2d5ID0geHZ6YWxsb2NfYXJyYXkoc3RydWN0IGNwdV90b3Bv bG9neSwgbnJfY3B1X2lkcyk7DQo+IFlvdSBjYWxsIGl0IGZyb20gYHNtcF9pbml0X2NwdXMoKWAg YXQgd2hpY2ggcG9pbnQgYG5yX2NwdV9pZHNgIGlzIG5vdCB5ZXQgc2V0DQo+IGFuZCBzaW1wbHkg ZGVub3RlcyBgTlJfQ1BVU2AuDQoNClRoYXQgaXMgY29ycmVjdC4gSSB3aWxsIG1vdmUgdGhlIGNh bGwgdG8gaW5pdF9jcHVfdG9wb2xvZ3koKSB0byBhIGxhdGVyIHBvaW50IHdoZXJlDQpucl9jcHVf aWRzIGlzIGZpbmFsaXplZC4NCg0KPiA+ICtzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9jb3JlKGNv bnN0IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqY29yZSwNCj4gPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB1bnNpZ25lZCBpbnQgcGFja2FnZV9pZCwNCj4gPiArICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgY2x1c3Rlcl9pZCwNCj4gPiArICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgY29yZV9pZCkNCj4gPiArew0KPiA+ICsgICAg Ym9vbCBsZWFmID0gdHJ1ZTsNCj4gPiArICAgIHVuc2lnbmVkIGludCB0aHJlYWRfaWQ7DQo+ID4g KyAgICB1bnNpZ25lZCBpbnQgY3B1Ow0KPiA+ICsNCj4gPiArICAgIGZvciAoIHRocmVhZF9pZCA9 IDA7IDsgdGhyZWFkX2lkKysgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGNvbnN0IHN0cnVj dCBkdF9kZXZpY2Vfbm9kZSAqdGhyZWFkOw0KPiA+ICsgICAgICAgIGNoYXIgbmFtZVsyMF07DQo+ ID4gKw0KPiA+ICsgICAgICAgIHNucHJpbnRmKG5hbWUsIHNpemVvZihuYW1lKSwgInRocmVhZCV1 IiwgdGhyZWFkX2lkKTsNCj4gPiArICAgICAgICB0aHJlYWQgPSBkdF9maW5kX2NoaWxkX25vZGVf YnlfbmFtZShjb3JlLCBuYW1lKTsNCj4gPiArDQo+ID4gKyAgICAgICAgaWYgKCAhdGhyZWFkICkN Cj4gPiArICAgICAgICAgICAgYnJlYWs7DQo+ID4gKw0KPiA+ICsgICAgICAgIGxlYWYgPSBmYWxz ZTsNCj4gPiArICAgICAgICBjcHUgPSBnZXRfY3B1X2Zvcl9ub2RlKHRocmVhZCk7DQo+ID4gKw0K PiA+ICsgICAgICAgIGlmICggY3B1ID09IElOVkFMSURfVE9QT19JRCApDQo+ID4gKyAgICAgICAg ew0KPiA+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPiA+ICsgICAgICAgICAgICAg ICAgICAgIkVSUk9SOiAlczogQ2FuJ3QgZ2V0IENQVSBmb3IgdGhyZWFkXG4iLCBkdF9ub2RlX25h bWUodGhyZWFkKSk7DQo+ID4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPiA+ICsgICAg ICAgIH0NCj4gPiArDQo+ID4gKyAgICAgICAgQVNTRVJUKGNwdV9tYXBbY3B1XS5wYWNrYWdlX2lk ID09IElOVkFMSURfVE9QT19JRCk7DQo+ID4gKyAgICAgICAgQVNTRVJUKGNwdV9tYXBbY3B1XS5j bHVzdGVyX2lkID09IElOVkFMSURfVE9QT19JRCk7DQo+ID4gKyAgICAgICAgQVNTRVJUKGNwdV9t YXBbY3B1XS5jb3JlX2lkID09IElOVkFMSURfVE9QT19JRCk7DQo+ID4gKyAgICAgICAgQVNTRVJU KGNwdV9tYXBbY3B1XS50aHJlYWRfaWQgPT0gSU5WQUxJRF9UT1BPX0lEKTsNCj4gVGhpcyBBU1NF UlQgYmxvY2sgYW5kIHRoZSBpZGVudGljYWwgb25lIGJlbG93IHZhbGlkYXRlIERUIGRhdGEsIG5v dCBYZW4gaW50ZXJuYWwNCj4gaW52YXJpYW50LiBSZXR1cm4gZXJyb3IgaW5zdGVhZC4NCg0KT2th eS4NCg0KPiA+ICtzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9jbHVzdGVyKGNvbnN0IHN0cnVjdCBk dF9kZXZpY2Vfbm9kZSAqY2x1c3RlciwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1bnNpZ25lZCBpbnQgcGFja2FnZV9pZCwNCj4gPiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB1bnNpZ25lZCBpbnQgY2x1c3Rlcl9pZCwNCj4gPiArICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgZGVwdGgpDQo+ID4gK3sNCj4gPiArICAgIGJv b2wgbGVhZiA9IHRydWU7DQo+ID4gKyAgICBib29sIGhhc19jb3JlcyA9IGZhbHNlOw0KPiA+ICsg ICAgdW5zaWduZWQgaW50IGNvcmVfaWQ7DQo+ID4gKyAgICB1bnNpZ25lZCBpbnQgY2hpbGRfY2x1 c3Rlcl9pZDsNCj4gPiArDQo+ID4gKyAgICAvKg0KPiA+ICsgICAgICogRmlyc3QgY2hlY2sgZm9y IGNoaWxkIGNsdXN0ZXJzOyB3ZSBjdXJyZW50bHkgaWdub3JlIGFueQ0KPiA+ICsgICAgICogaW5m b3JtYXRpb24gYWJvdXQgdGhlIG5lc3Rpbmcgb2YgY2x1c3RlcnMgYW5kIHByZXNlbnQgdGhlDQo+ ID4gKyAgICAgKiBzY2hlZHVsZXIgd2l0aCBhIGZsYXQgbGlzdCBvZiB0aGVtLg0KPiA+ICsgICAg ICovDQo+ID4gKyAgICBmb3IgKCBjaGlsZF9jbHVzdGVyX2lkID0gMDsgOyBjaGlsZF9jbHVzdGVy X2lkKysgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2Vf bm9kZSAqY2hpbGRfY2x1c3RlcjsNCj4gPiArICAgICAgICBjaGFyIG5hbWVbMjBdOw0KPiA+ICsg ICAgICAgIGludCByZXQ7DQo+ID4gKw0KPiA+ICsgICAgICAgIHNucHJpbnRmKG5hbWUsIHNpemVv ZihuYW1lKSwgImNsdXN0ZXIldSIsIGNoaWxkX2NsdXN0ZXJfaWQpOw0KPiA+ICsgICAgICAgIGNo aWxkX2NsdXN0ZXIgPSBkdF9maW5kX2NoaWxkX25vZGVfYnlfbmFtZShjbHVzdGVyLCBuYW1lKTsN Cj4gPiArDQo+ID4gKyAgICAgICAgaWYgKCAhY2hpbGRfY2x1c3RlciApDQo+ID4gKyAgICAgICAg ICAgIGJyZWFrOw0KPiA+ICsNCj4gPiArICAgICAgICBsZWFmID0gZmFsc2U7DQo+ID4gKyAgICAg ICAgcmV0ID0gcGFyc2VfY2x1c3RlcihjaGlsZF9jbHVzdGVyLCBwYWNrYWdlX2lkLCBjaGlsZF9j bHVzdGVyX2lkLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVwdGggKyAxKTsN Cj4gPiArICAgICAgICBpZiAoIGRlcHRoID4gMCApDQo+ID4gKyAgICAgICAgICAgIHByaW50ayhY RU5MT0dfV0FSTklORw0KPiA+ICsgICAgICAgICAgICAgICAgICAgIldBUk5JTkc6IFRvcG9sb2d5 IGZvciBjbHVzdGVycyBvZiBjbHVzdGVycyBub3QgeWV0IHN1cHBvcnRlZFxuIik7DQo+ID4gKyAg ICAgICAgaWYgKCByZXQgIT0gMCApDQo+ID4gKyAgICAgICAgICAgIHJldHVybiByZXQ7DQo+ID4g KyAgICB9DQo+ID4gKw0KPiA+ICsgICAgLyogTm93IGNoZWNrIGZvciBjb3JlcyAqLw0KPiA+ICsg ICAgZm9yICggY29yZV9pZCA9IDA7IDsgY29yZV9pZCsrICkNCj4gPiArICAgIHsNCj4gPiArICAg ICAgICBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmNvcmU7DQo+ID4gKyAgICAgICAgY2hh ciBuYW1lWzIwXTsNCj4gPiArICAgICAgICBpbnQgcmV0Ow0KPiA+ICsNCj4gPiArICAgICAgICBz bnByaW50ZihuYW1lLCBzaXplb2YobmFtZSksICJjb3JlJXUiLCBjb3JlX2lkKTsNCj4gPiArICAg ICAgICBjb3JlID0gZHRfZmluZF9jaGlsZF9ub2RlX2J5X25hbWUoY2x1c3RlciwgbmFtZSk7DQo+ ID4gKw0KPiA+ICsgICAgICAgIGlmICggIWNvcmUgKQ0KPiA+ICsgICAgICAgICAgICBicmVhazsN Cj4gPiArDQo+ID4gKyAgICAgICAgaGFzX2NvcmVzID0gdHJ1ZTsNCj4gPiArDQo+ID4gKyAgICAg ICAgaWYgKCBkZXB0aCA9PSAwICkNCj4gPiArICAgICAgICB7DQo+ID4gKyAgICAgICAgICAgIHBy aW50ayhYRU5MT0dfRVJSDQo+ID4gKyAgICAgICAgICAgICAgICAgICAiRVJST1I6ICVzOiBjcHUt bWFwIGNoaWxkcmVuIHNob3VsZCBiZSBjbHVzdGVyc1xuIiwNCj4gPiArICAgICAgICAgICAgICAg ICAgIGR0X25vZGVfbmFtZShjb3JlKSk7DQo+ID4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFM Ow0KPiA+ICsgICAgICAgIH0NCj4gPiArDQo+ID4gKyAgICAgICAgaWYgKCBsZWFmICkNCj4gPiAr ICAgICAgICB7DQo+ID4gKyAgICAgICAgICAgIHJldCA9IHBhcnNlX2NvcmUoY29yZSwgcGFja2Fn ZV9pZCwgY2x1c3Rlcl9pZCwgY29yZV9pZCk7DQo+ID4gKyAgICAgICAgICAgIGlmICggcmV0ICE9 IDAgKQ0KPiA+ICsgICAgICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4gPiArICAgICAgICB9DQo+ ID4gKyAgICAgICAgZWxzZQ0KPiA+ICsgICAgICAgIHsNCj4gPiArICAgICAgICAgICAgcHJpbnRr KFhFTkxPR19FUlIgIkVSUk9SOiAlczogTm9uLWxlYWYgY2x1c3RlciB3aXRoIGNvcmUgJXNcbiIs DQo+ID4gKyAgICAgICAgICAgICAgICAgICBkdF9ub2RlX25hbWUoY2x1c3RlciksIG5hbWUpOw0K PiA+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4gPiArICAgICAgICB9DQo+ID4gKyAg ICB9DQo+ID4gKw0KPiA+ICsgICAgaWYgKCBsZWFmICYmICFoYXNfY29yZXMgKQ0KPiA+ICsgICAg ICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiV0FSTklORzogJXM6IGVtcHR5IGNsdXN0ZXJcbiIs DQo+ID4gKyAgICAgICAgICAgICAgIGR0X25vZGVfbmFtZShjbHVzdGVyKSk7DQo+ID4gKw0KPiA+ ICsgICAgcmV0dXJuIDA7DQo+ID4gK30NCj4gPiArDQo+ID4gK3N0YXRpYyBpbnQgX19pbml0IHBh cnNlX3NvY2tldChjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnNvY2tldCkNCj4gPiArew0K PiA+ICsgICAgYm9vbCBoYXNfc29ja2V0ID0gZmFsc2U7DQo+ID4gKyAgICB1bnNpZ25lZCBpbnQg cGFja2FnZV9pZDsNCj4gPiArICAgIGludCByZXQ7DQo+ID4gKw0KPiA+ICsgICAgZm9yICggcGFj a2FnZV9pZCA9IDA7IDsgcGFja2FnZV9pZCsrICkNCj4gPiArICAgIHsNCj4gPiArICAgICAgICBj b25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmNsdXN0ZXI7DQo+ID4gKyAgICAgICAgY2hhciBu YW1lWzIwXTsNCj4gPiArDQo+ID4gKyAgICAgICAgc25wcmludGYobmFtZSwgc2l6ZW9mKG5hbWUp LCAic29ja2V0JXUiLCBwYWNrYWdlX2lkKTsNCj4gPiArICAgICAgICBjbHVzdGVyID0gZHRfZmlu ZF9jaGlsZF9ub2RlX2J5X25hbWUoc29ja2V0LCBuYW1lKTsNCj4gVGhlIG5hbWVzIGFyZSBvbmUg bGV2ZWwgb2ZmIChJIGtub3cgeW91IHRvb2sgaXQgZnJvbSBMaW51eCB3aGljaCBzdWZmZXJzIGZy b20NCj4gdGhlIHNhbWUgcHJvYmxlbSk6IHRoZSBwYXJhbWV0ZXIgaXMgdGhlIGNwdS1tYXAgbm9k ZSwgbm90IGEgc29ja2V0LCBhbmQgdGhlDQo+IGxvY2FsIGlzIGEgc29ja2V0IG5vZGUsIG5vdCBh IGNsdXN0ZXIuIHBhcnNlX2NsdXN0ZXIoKSBoYXMgdGhlIHNhbWUgcHJvYmxlbS4NCj4gUGxlYXNl IG5hbWUgdGhlIHBhcmFtZXRlcnMgYWZ0ZXIgd2hhdCB0aGV5IGFjdHVhbGx5IHJlY2VpdmUsDQo+ IGUuZy5wYXJzZV9zb2NrZXQoY3B1X21hcCkgd2l0aCBhIGxvY2FsICdzb2NrZXQnLiBJdCBtYWtl cyBpdCBkaWZmaWN1bHQgdG8gcGFyc2UNCj4gdGhlIGNvZGUgYW5kIEknbGwgd2FpdCB3aXRoIHJl dmlld2luZyB0aGlzIGZpbGUgdW50aWwgdGhpcyBpcyBmaXhlZC4NCg0KSSBoYWQgdGhlIGV4YWN0 IHNhbWUgaW1wcmVzc2lvbiB3aGVuIHBvcnRpbmcgdGhpcyBjb2RlIGZyb20gdGhlIExpbnV4IGtl cm5lbC4NCkkgd2lsbCByZW5hbWUgdGhlIGZ1bmN0aW9uIHBhcmFtZXRlcnMgYW5kIGxvY2FsIHZh cmlhYmxlcy4NCg0KPiA+ICsNCj4gPiAraW50IF9faW5pdCBkdF9pbml0X2NwdV90b3BvbG9neSh2 b2lkKQ0KPiA+ICt7DQo+ID4gKyAgICB1bnNpZ25lZCBpbnQgY3B1Ow0KPiA+ICsgICAgaW50IHJl dDsNCj4gPiArDQo+ID4gKyAgICBCVUdfT04oIWFjcGlfZGlzYWJsZWQpOw0KPiA+ICsgICAgQlVH X09OKCFjcHVfdG9wb2xvZ3kpOw0KPiBBU1NFUlRzIGFyZSBhIGJldHRlciBmaXQgaGVyZSwgZ2l2 ZW4gdGhhdCB0aGVzZSBhcmUgYWxyZWFkeSB2YWxpZGF0ZWQgYnkgdGhlDQo+IHNvbGUgY2FsbGVy Lg0KDQpPa2F5Lg0KDQpUaGFuayB5b3UsDQpIaXJva2F6dSBUYWthaGFzaGkuDQo= From xen-devel-bounces@lists.xenproject.org Thu Sep 10 03:38:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 03:38:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413868.1643797 (Exim 4.92) (envelope-from ) id 1x4VcY-0006SG-Jx; Thu, 10 Sep 2026 03:38:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413868.1643797; Thu, 10 Sep 2026 03:38: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 1x4VcY-0006S8-Gz; Thu, 10 Sep 2026 03:38:42 +0000 Received: by outflank-mailman (input) for mailman id 1413868; Thu, 10 Sep 2026 03:38:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4VcW-0006Rl-Ip for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 03:38:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4VcV-00GeXg-DG for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 05:38:39 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa225df-bab6-0a2a0a5309dd-0a2a450784e0-44 for ; Thu, 10 Sep 2026 05:38:39 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2263e-b4ea-0a2a45070019-416d716cc876-3 for ; Thu, 10 Sep 2026 05:38:39 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 4973640E02DA; Thu, 10 Sep 2026 03:38:38 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DgxUcYTwl7IG; Thu, 10 Sep 2026 03:38:28 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id B712E40E00B9; Thu, 10 Sep 2026 03:38:13 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1789011508; bh=56esme3wXZzA28wrdzVrMK053H2QTxOeMLqIu/NG3Z4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DRVn8+E1wzobwfUIvffLigaTfD/SQPfkWwOp01/4UpBFVPp41n6e4eLpNABn+J/Z7 YSayQr1sO7A0Vbv1omE5ki9NMfGZ7qyUt7zWVv+lQXRiF+wDrTcmV0GbxRGGbRiG/I MYo4XuPDfuiL9oqA1+TRF3MovHk0ENv6ZGFWbWSpD8Oe7mZ/mxfqTJgqyI8YZ9ZbRk d+jIgHx7SfsXfrJ7wa+Lrw75EAU+7LSp+fCdsLIbmG1gU+8c/0Boh3xjoz/JKwcXqO nHeWvB6SK2u5JiapAUTymNccX9Iu6m8KFpjCdxbdU7QAQZOMrdi4EiG+tPItT11p8h eQ2HfwY29+dzimYjiMfTv85EsrSYwux/Rvf8Ac3R7tk5GOi22DCFnqfsTd+RRRE4d/ Tv3NVi1bRA3WO7ZiTZupPOuDmfohylcdWSAfwzt65vGyeP9zRwO9GqQnYGqDTtS1yK E6iOfH564Pf4kZWeE1sozVDbOCNA0TGPx6/7scnQngsTCx/LHNYx2ETPp+F/VsJDpj RXp4/3YBRAFi4AIjhx2zCMV8jSfMAhFY3qM+/XdwQ23u+cPYGbzSMyVwvze8LR0cnM izR0TdiZ18N6qehBtfOc525L8UaYPw31ZEGgUMp/nbChY4enOCxAjfVc9sFRGde8Aw KNbgm0ZepzF5joHLu0mrIF9M= Date: Wed, 9 Sep 2026 20:38:10 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() Message-ID: <20260910033810.GFaqImIu15e_pszuO2@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-ef75cf/1789011519-374D3AE4-AE275F51/0/0 X-purgate-type: clean X-purgate-size: 350 On Tue, Sep 08, 2026 at 06:06:21PM -0300, Mauricio Faria de Oliveira wrote: > Ack, and to confirm: not rename the existing one, either? Nah, concentrate only on what you're trying to achieve. hpa can send a patch ontop since he cares so much. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Thu Sep 10 06:33:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 06:33:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413962.1643828 (Exim 4.92) (envelope-from ) id 1x4YLu-0004mY-TQ; Thu, 10 Sep 2026 06:33:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413962.1643828; Thu, 10 Sep 2026 06:33: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 1x4YLu-0004mR-P2; Thu, 10 Sep 2026 06:33:42 +0000 Received: by outflank-mailman (input) for mailman id 1413962; Thu, 10 Sep 2026 06:33:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4YLt-0004m2-CW for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 06:33:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4YLs-009jEA-0y for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 08:33:40 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa24f30-8faa-0a2a0a5109dd-0a2a4507bada-38 for ; Thu, 10 Sep 2026 08:33:39 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa24f43-b4ea-0a2a45070019-4a7de18cb34d-3 for ; Thu, 10 Sep 2026 08:33:39 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b91369ef6so6988305e9.1 for ; Wed, 09 Sep 2026 23:33: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 ffacd0b85a97d-485883a9234sm48471752f8f.14.2026.09.09.23.33.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 23:33:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789022019; x=1789626819; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=mylF4wULlC9jyJ5OamXqxZWkcxZx6dV+aky3gJWgiUQ=; b=UoiJ+LK/nkjgFGyLXer6V8iOK5OBM5TFMMzK1l+pumF3ZaJ2F8JLEtWxVPjexpHSOc 3uhIAT+VdbMIHaA5s7g8BqBGhjl96rvsaNfNPi9xroYD95Bq7nVMaICp4tCEjf1Hk5YL 3apyOyxi9XV0g/MsvmBELAHHJ2PBL7LYcmKWkRUMdPIDnqIRScn8lqSAJab5TT7O8t00 7fKeIwoid9zND0625qMyaUdMQSvtLWmQyjZgD//6MI5o+VaXFd0X9wO5g3Xwx95AT5y8 9oOtEu0rgn6SfwZhaelUrMiZLNJZSsPtHmO7leR9dFSRtkicxzhwB5ii2JOkhx3Z4S2v 1YXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789022019; x=1789626819; h=content-transfer-encoding:content-type: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:content-type; bh=mylF4wULlC9jyJ5OamXqxZWkcxZx6dV+aky3gJWgiUQ=; b=eFF+rWATUwCPWI3U/96edWKStzz+EUNwCwn2A56JhQ0RLFnOTBpgzt4p5LsnBkHbof 9eI2To0SFJV6bWioigloMjO+QSlJVKKJYmArdp4AYc/mNV1nPMxrLWbaf0TTZxkckM8B I+nktJzhc43LqV+A6LUSQit9567yfyJVPWkwINV8VgVuTFxoernfRpIv+r2YYMEusjMV 0cFvHEQIjgnJtXFaPuFxALWND3tfLNFKhmv+CC/7XT7HPtliE2FmrXz4ziTMc+fFnqtw diEgGMO+C3vbtYegbT4ulfBtPPYakjecD3bo86pa/YOxqhXlTcIUdx5H/ClGpNw/8kCz dfHw== X-Forwarded-Encrypted: i=1; AKwUvByvnpI5T3r5ZPmMAPPK+1JZeJ4X25RRnpUVliglxKP723G25fmW4rB6+x82Ah4P1f7MnYltCyBR6UE=@lists.xenproject.org X-Gm-Message-State: AFuF++nZJvP+5kqAKjmaSCDLMeOhZlXF9qaIA3Hrq5ePi2P9/gr2phJd N9ANSB1slIe/1rIrMvI2jkDR6+y6k+7pyWmy7tvlRDgJ2GepSliq1fph41N87abZYw== X-Gm-Gg: AYBFou3lco6zvbzWREOEoFW977f2QoupRNOFzfEq1tBTfcibgAcQYNajDjHoUYcMKHD 9ynBZ43NinRu2xNS/8ra+DlgEWvHGvOye8751BncrRQH//OYEVDzaMzYYcrCdmhKxwN6/BBqF6i 30f3wrXbCsmkWLjL65N0k5QKNuKZkXYy63Zjh0PyXWxulG6EtMH/tiea2ueBusNon+mh9iXrhsi zDmHRWwPpFcQx/v/RATOuWjoeA+T3fnUimOewK/41B25zjBy7HLY8d16ao5IBWI4DjHzSOKkkDa NOLQqBQ/MXVZUwG3y/13c0CtSdjFoQCP863WfycNT/WAos3ILG6aXnB+971btp/yAEbt6gRzKT+ 6/qWeUCsWP8uFNp2p0XzcJ6CZGsCA1RiYbqfSoUM5mfe6jdDFpUKaigpJRUvYg5/024iUGgai3P VKDPLC/yllRGS6ShZkCrFw/nBUHG8GEyOFp8Dy3AW2i9Kx6E6sWODyDdfUywcizNjELJWgaUInW RA61cmKg8P+nt4dFMFxNpS4kYBLrxKCP6EbIDeB2slrDgFJGkl0hQSH7SYL+Cg= X-Received: by 2002:a05:600c:150a:b0:499:7a15:fcec with SMTP id 5b1f17b1804b1-49d2592e85bmr65613105e9.13.1789022018668; Wed, 09 Sep 2026 23:33:38 -0700 (PDT) Message-ID: <7ab4cb61-6943-49fc-9d5b-1b5d67196b23@suse.com> Date: Thu, 10 Sep 2026 08:33:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/mm: limit deferred TLB flushing to PV domain support To: Jason Andryuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260909140500.73483-1-roger@xenproject.org> <92c9bf4b-5171-4a26-a62e-f2a7b1cb89ef@suse.com> <22028c12-2400-4131-8e5e-b2dc7a65326f@amd.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: <22028c12-2400-4131-8e5e-b2dc7a65326f@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1789022019-34ECEAE4-D023610E/0/0 X-purgate-type: clean X-purgate-size: 2376 On 09.09.2026 22:07, Jason Andryuk wrote: > On 2026-09-09 12:28, Roger Pau Monné wrote: >> On Wed, Sep 09, 2026 at 04:46:01PM +0200, Jan Beulich wrote: >>> On 09.09.2026 16:05, Roger Pau Monne wrote: >>>> --- a/xen/common/page_alloc.c >>>> +++ b/xen/common/page_alloc.c >>>> @@ -1538,8 +1538,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) >>>> BUG(); >>>> } >>>> >>>> - /* If a page has no owner it will need no safety TLB flush. */ >>>> - pg->u.free.need_tlbflush = (page_get_owner(pg) != NULL); >>>> + /* >>>> + * If a page has no owner and there's no PV domain support it will need no >>>> + * safety TLB flush, there can be no stale TLB entries. >>>> + */ >>>> + pg->u.free.need_tlbflush = IS_ENABLED(CONFIG_PV) && page_get_owner(pg); >>>> if ( pg->u.free.need_tlbflush ) >>>> page_set_tlbflush_timestamp(pg); >>> >>> I'm okay with the code change now, but the comment is still concerning me. >>> All by itself there is no reason why stale TLB entries couldn't also exist >>> for HVM guests. It's just that (a) only the host TLBs are flushed by >>> filtered_flush_tlb_mask() and (b) flushes of guest TLBs occur when pages >>> are removed from their P2Ms (aiui; hopefully true also for Arm). IOW what >>> the comment says looks to be correct, just that it leaves too much to be >>> figured out by the reader. At the very least I'd suggest "..., there can >>> be no stale (host) TLB entries." Thoughts? >> >> Hm, I find adding "(host)" to also be slightly confusing, as I would >> usually associate host TLB with Xen context TLB state. Which is also >> made more confusing by how PV guests share the page-tables with Xen. >> >> "If a page has no owner and there's no PV domain support it will need >> no safety TLB flush. PV domains are the only domain types that can >> keep stale entries on the TLB, as they have (limited) control over the >> host MMU and when flushes are performed" > I find "will need no" a little awkward. Maybe: > > "If a page has no owner and there's no PV domain support it does not > need a safety TLB flush." > > or: > > "If a page has no owner and there's no PV domain support, then a safety > TLB flush is not needed." I'd be okay with any of these. Then: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 06:38:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 06:38:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413969.1643835 (Exim 4.92) (envelope-from ) id 1x4YQR-0005Nc-Cg; Thu, 10 Sep 2026 06:38:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413969.1643835; Thu, 10 Sep 2026 06:38:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4YQR-0005NV-9m; Thu, 10 Sep 2026 06:38:23 +0000 Received: by outflank-mailman (input) for mailman id 1413969; Thu, 10 Sep 2026 06:38:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4YQP-0005NP-N2 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 06:38:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4YQP-004LiJ-3T for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 08:38:21 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa25053-bab6-0a2a0a5309dd-0a2a45098d2e-10 for ; Thu, 10 Sep 2026 08:38:16 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa25057-be1a-0a2a45090019-d155dd2bc81d-3 for ; Thu, 10 Sep 2026 08:38:16 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-4859b45abadso626043f8f.2 for ; Wed, 09 Sep 2026 23:38:15 -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 ffacd0b85a97d-485883a9b49sm41005570f8f.17.2026.09.09.23.38.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 23:38:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789022295; x=1789627095; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=3NX0OxbB28DbZIwihOdfCW5vty+HHgQZ6fPgsUPCvWg=; b=R7rHPkKYYN6r+VW7kcfBDnEFm6hoC8yglGw2279WuzM9VuFeqNHVnAaaylAWNxLsqH EhIqQPHZF+0PHOiOl/AVsWRfMR4hz/m3NoCv5QfLjC57PN+7B6evB5q4ypQontYV2v4t gkDGjfYvrAuCNFczrM9YnEh42DDWCaVKdhZbHHfPEaaWLsY4KY/1+CaCwrzxfwqhmGyC O6PYdxjXzdZQerLN+0Y5BM/0YBzWRi/KQJ3X0qGd07xntHgJV5ZcONSExQztaK3EQR2C 0pJ7H8R+cbV+G6TMd9xgPHkpsape4gU9aXusPMiC0nzWMDELhIy8+jCXWtXLx5D9sgjM zkxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789022295; x=1789627095; h=content-transfer-encoding:content-type: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:content-type; bh=3NX0OxbB28DbZIwihOdfCW5vty+HHgQZ6fPgsUPCvWg=; b=oJF3rqXPuogABsSDdtMnG1xZ5aP4zurypZFj6kJXf9r5+cdQj3C8wmO3w3kobJUR3z bVSXokn7aDa/8FV+1L2r83fgXcmEEDDiwLDA2EVjh+jzKV1qLeDMdqV3ZzqSGGaPbkaW 2Id0qjUR32ofvU2eu2Wfl2Zk+sinm9WqDpR3O76i9H2HLQKgX6/H0YsU5hg4VqjYAtdO atAa7D7NYf/YmwMq2Rq3n1UW8k0lrl25WClgvVhXJ/iw4YiUKVwy8AwiPbUQCSSaOBqz Wqy5KwzJHxz330PFKdzGxXSTeMUQtyITbit+LNUjRGeVHLzM/fDgadpurUoxWOdh81fl XBMw== X-Forwarded-Encrypted: i=1; AKwUvBxsLiSp2CIvxgT6QIAUUevOhKxqzoeZdM4AqgwAqtKHu6jtBAa2GeFivxYIVHXOGPbQHgddDE93Wcc=@lists.xenproject.org X-Gm-Message-State: AFuF++k9AXyFhK2S7vg0F0EIFtSiJncUm8EfwO/WX3sMrklFEka+ufe8 h3qz581zFjyzG17GpyXxXcSz+P49RcM7uPKs36cyD3FovfnTqbe7m0aat+oAyQY8UQ== X-Gm-Gg: AYBFou2Qw7LDO/JQIkB2PLJtL3a0yz+eXi8UEYFb43uGY7nBePsbxNEz3j4frFGUAK8 k/6xh8XU6qLsa/Va23JgIx6SJwZdNaQBkwnX9VBae+MKn1kZE4pLVtUnvTQb8+7OTDzGIUpyqOW mFVP2g04aeoh0NnKwtO+9X0gitYfZmr0MSrp/ysWsnW+4XzkF5Og66z+wYwbnQpzZyzqzRWCzc6 Z2BYM4ur+scSe7BRXbixa87rFQ2L+JxMpRLLlsvibd4NT6eyuAkOJalMPg41KPdh2VLgFeT+Dsz jszuX3isSDlnToETlw70iN+Ls3R24Bb3qmJYwSfXBxcDEPx3Hqvy7UaOY2p1My16j72NGZYWrj+ HvPdEcd3vBT4EP1S3b9vz6A7hFmdKukahe0kk0dUDk4wzuz/U7mSQcuBCBswtssGn1lRg3sD+xt izmDWxpES9S98uMW93JxX6MHFd57TWkSJxEW03Zpi7Rd6BVtm5Fwg0VTMNXLrnyRconfS4h3pFX 7sHwEo1qrel8ozyaVqGChpl5NqhqhG4kBnaVeWDPV3tD0wcHmXo6EZFS/MIZUoV1ERWmYC4VA== X-Received: by 2002:a05:6000:420b:b0:485:ac3b:4a79 with SMTP id ffacd0b85a97d-485ac3b4b63mr9046278f8f.43.1789022295471; Wed, 09 Sep 2026 23:38:15 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 08:38:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 18/39] xen/riscv: add guest page fault handling stub To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.com> <35aecc68-d16e-4350-9aca-101de2b21c1f@suse.com> <19aae90d-bd5b-4637-828c-bb5164ba4191@gmail.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: <19aae90d-bd5b-4637-828c-bb5164ba4191@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1789022296-3B2DC034-15BE0AA9/0/0 X-purgate-type: clean X-purgate-size: 5707 On 09.09.2026 17:09, Oleksii Kurochko wrote: > On 9/8/26 4:10 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> --- /dev/null >>> +++ b/xen/arch/riscv/emulate.c >>> @@ -0,0 +1,179 @@ >>> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >>> + >>> +/* >>> + * RISC-V instruction emulation for trapped guest accesses >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +/* >>> + * The hardware-reported details of a guest page fault, gathered once by >>> + * handle_guest_page_fault() and passed down to the emulation of the faulted >>> + * access. >>> + */ >>> +struct guest_fault { >>> + /* The guest register state as saved on entry to do_trap(). */ >>> + struct cpu_user_regs *regs; >> >> If the comment was true, this could be pointer-to-const. > > I think it can't be pointer-to-const as emulate_load/store functions > wants to change PC register after MMIO access emulation is finished to > not trap again. Of course, hence how I started the sentence. >>> + /* scause: a fetch, a load or a store/AMO guest page fault. */ >>> + unsigned long cause; >>> + /* >>> + * htinst: the trapped instruction in its transformed form, or one of the >>> + * special values (zero, or a pseudoinstruction). >>> + */ >>> + unsigned long htinst; >>> + /* htval: as written by hardware; see resolve_faulting_gpa(). */ >>> + unsigned long htval; >>> + /* stval: the guest virtual address of the faulting access. */ >>> + unsigned long stval; >>> + /* The faulting guest physical address, filled by resolve_faulting_gpa(). */ >>> + paddr_t gpa; >>> +}; >>> + >>> +/* >>> + * Is @htinst one of the pseudoinstructions reported for a guest page fault >>> + * taken on an implicit memory access done for VS-stage address translation? >>> + * >>> + * All four values are recognized regardless of the hypervisor's XLEN: the >>> + * width they encode is that of a VS-stage PTE, i.e. it follows the guest's >>> + * paging mode (4 bytes for Sv32, 8 otherwise). On RV32 the 64-bit forms >>> + * simply never occur. >>> + */ >>> +static bool htinst_is_pseudo(unsigned long htinst) >>> +{ >>> + switch ( htinst ) >>> + { >>> + case INSN_PSEUDO_VS_LOAD32: >>> + case INSN_PSEUDO_VS_STORE32: >>> + case INSN_PSEUDO_VS_LOAD64: >>> + case INSN_PSEUDO_VS_STORE64: >>> + return true; >>> + >>> + default: >>> + return false; >>> + } >>> +} >> >> This feels fragile. New pseudo-insns can appear at any time. If the value as >> a whole is non-zero, aiui the low two bits being zero indicate a pseudo-insn. >> In which case enumerating pseudo-insns we are currently aware of isn't >> necessary. > > I will write it simpler then: > > /* > * Is @htinst one of the special pseudoinstruction values, reported for > a guest > * page fault taken on an implicit memory access done for VS-stage address > * translation? > * > * It is enough to check only bits[1:0] as according to the spec: > * > * The value is one of the special pseudoinstructions defined later, all of > * which have bits 1:0 equal to 00. > */ > static bool htinst_is_pseudo(unsigned long htinst) > { > return htinst && ((htinst & 3) == 0); > } And preferably return htinst && !(htinst & 3); to be self-consistent. >>> + /* >>> + * A guest-page fault may arise due to an implicit memory access during >>> + * first-stage (VS-stage) address translation, in which case a guest >>> + * physical address written to htval is that of the implicit memory >>> + * access that faulted - for example, the address of a VS-level page >>> + * table entry that could not be read. (The guest physical address >>> + * corresponding to the original virtual address is unknown when >>> + * VS-stage translation fails to complete) >>> + * >>> + * In such cases htinst reports one of the pseudoinstructions recognized >>> + * by htinst_is_pseudo(), and the fault requires separate handling (since >>> + * G-stage translation failed on an unpopulated/unmapped guest physical >>> + * address during a hardware page-table walk). To match bare hardware >>> + * behavior, we must inject an access fault of the ORIGINAL access type >>> + * (Instruction, Load, or Store/AMO) that initiated the address >>> + * translation. >>> + */ >>> + if ( htinst_is_pseudo(gf.htinst) ) >>> + { >>> + inject_access_fault(&gf); >>> + >>> + return; >>> + } >> >> I.e. you imply that guests won't put their page tables in MMIO? That's >> fragile imo; I have seen OSes to use video frame buffers for all kinds >> of (transient) purposes, for example. > > I think it is okay for now and if it will a real use case then an update > of this code will be needed. May I then ask that you leave a remark (maybe even fixme) to this effect? >>> + resolve_faulting_gpa(&gf); >> >> Since the function is only a stub right now - how is one to tell whether >> this indeed can never fail? > > It can't be tell. But what is wrong if it could fail? (Actually with > current implementation introduced in later patches you can find it can > fail if a necessary extension or software page walk isn't introduced). Well, quite obviously if it can fail, its return value would need checking here. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 06:44:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 06:44:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413980.1643846 (Exim 4.92) (envelope-from ) id 1x4YVm-00070b-Vn; Thu, 10 Sep 2026 06:43:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413980.1643846; Thu, 10 Sep 2026 06:43:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4YVm-00070U-S1; Thu, 10 Sep 2026 06:43:54 +0000 Received: by outflank-mailman (input) for mailman id 1413980; Thu, 10 Sep 2026 06:43:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4YVl-00070L-B2 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 06:43:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4YVk-007B1V-Bf for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 08:43:52 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa25195-8faa-0a2a0a5109dd-0a2a450aa434-38 for ; Thu, 10 Sep 2026 08:43:52 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa251a8-f2d2-0a2a450a0019-d1558032cccb-3 for ; Thu, 10 Sep 2026 08:43:52 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49d0b98d6d0so46595815e9.0 for ; Wed, 09 Sep 2026 23:43:52 -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-49d26c437besm49078465e9.11.2026.09.09.23.43.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 23:43:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789022632; x=1789627432; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=YqPiClyDQWL2eh7tbuvmcAWQELtxg+LbHOcj6JzGFpY=; b=Zj3XteF/7CqYY1lJ7a5pySGc9nI7QOY2LbraoVcqRBlqxX7LLKEjpIw9ZX/tR+obM1 tpXdjR+C7azapvimCHB8Yz/5H11Ng1zb5vtYIFqk+utl8BRyHLnt1oXhnBkLdIYKF8ls VuXMlJInxr6WDYLieveArse8Fa4PsEzs7BFPZXUhZeYhUEe+I7ANCJQ192Nfu1lVz7lp g+LdvszOigAcPSdhRyyf03WuHwf9GX0ZrTNmdiT7dOIJbOfp4ci2oqlb/ptQluDUWhlu cS9DIUVnomPCFAVIPi5PpKcXnvAqt4bBOgXX0I8fhjhuVL27F6C0D3X5oFgaESPDco/h GS7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789022632; x=1789627432; h=content-transfer-encoding:content-type: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:content-type; bh=YqPiClyDQWL2eh7tbuvmcAWQELtxg+LbHOcj6JzGFpY=; b=LCPe1rbjjq6bGPdbioLkYaLV/ftcApr68uHKLqe0j+OvvJ2jL0R9aGqByEHU7dtj2j sw5U8aWn04C33D3u+S5zunpwoz7yCLaOnlXi5ioH5kAYoKvHIiiz/3G6yfakps0qiMyL eLuUnYC8sGZ0iA6r9XyNFDxjunZQLswTu0qax2VsiCUx4Xt9meK5Hr4CO1ybwENNOpTY buW7JuXf3avJWqIp5oPKUipLEVo7DTKBg3UPMBvr/JhJtYbHqQwcV6SxiJ9MeUbhM01p 3jvLHxiIVrV1x/xTEM6dOgre6czimDyeMfEFbupyl5h+vBzV7DDA2ROSv9/RzUuMQv4+ HxWA== X-Forwarded-Encrypted: i=1; AKwUvBzkrabhQKiRqkYNiBNOa5WRLzAOZsl1p9+9MmJM+qMyuF8vP12hhUHVoDIDTUgh3q2rIqbi/ew9yN0=@lists.xenproject.org X-Gm-Message-State: AFuF++k3RCxIKLG0JAotzIJEdpwiGeElTR3qdHX30zbJ8goOOWV9ti2x QPB5UsmA5sRA7oj7CemlqWQy4FgYmCcL5pYGw36vWZ4WZT+kj3tVc0hjqL6wQRnVrg== X-Gm-Gg: AYBFou2pmPeKfB/MTc8/O8rzdqeG7qY7Ak9baeHnWwEoOkS84cP8NnzxAhssb3f+WxE uWtqdBZk5PBwPpyHMSCruc5z2SxGAAHJ6HuFtM2+scVieRAlynl0TftnF6QhRtwTGEPLx1z2qcq fbv+OO9dGswph1xvXkvrk6EFrlCRU/7PH6Yvpt9pnrLaqpcOA3lw3jpqiKoog/rOHhwcI+JHg/h pP6PKEDPSEPf1O6ENf9gIznaWC57mPPK2PSGSrrubjNahga7ng5rdkwS/ouyQ9ZCR3DBlXhALes xyJg/Kvg6nqd2pe8AN/PCK3LSdLM4BfSqOqEYtwUYFDzIpIR6uIy1F3tdX0Z9gkCccTeWvdM0lb CZLXx5EwnaCZiBT3ffln9crWVazNOtpbe5EzZbrcTSQF/mcXOsNuheEpw+/yL1PGLmd+I4+Vvpm 9ZnTnCv3iUvsCCLqlTICt6c2T34l0EawhvILshKU3cQbDyi0+DE9TrZRbsVLfeGpF2hxUTWZIxE eWYVMSgdKNe0jC/KhX/kYJFytNapHegwL+pkp00f2+4wSIp9IDpDLSjsr3Z9Zc= X-Received: by 2002:a05:600c:5492:b0:49c:fa21:1c7e with SMTP id 5b1f17b1804b1-49cfa211d31mr361861905e9.19.1789022631724; Wed, 09 Sep 2026 23:43:51 -0700 (PDT) Message-ID: <26a57fab-955a-4de6-b17b-eb57aa1f014b@suse.com> Date: Thu, 10 Sep 2026 08:43:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places To: Nicola Vetrini , Andrew Cooper , Stefano Stabellini Cc: Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.com> <320b920b3e673671eddceccb4b86f211@bugseng.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: <320b920b3e673671eddceccb4b86f211@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1789022632-5A9D9CFC-7E53D6FC/0/0 X-purgate-type: clean X-purgate-size: 3383 On 09.09.2026 21:07, Nicola Vetrini wrote: > On 2026-09-01 08:26, Jan Beulich wrote: >> On 31.08.2026 21:13, Andrew Cooper wrote: >>> On 28/08/2026 8:01 am, Jan Beulich wrote: >>>> --- a/xen/arch/x86/traps.c >>>> +++ b/xen/arch/x86/traps.c >>>> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu >>>> case X86_ET_HW_EXC: >>>> switch ( vec ) >>>> { >>>> - case X86_EXC_DF: return do_double_fault(regs); >>>> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>>> case X86_EXC_MC: return do_machine_check(regs); >>>> } >>>> break; >>>> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp >>>> case X86_ET_HW_EXC: >>>> switch ( regs->fred_ss.vector ) >>>> { >>>> - case X86_EXC_DF: return do_double_fault(regs); >>>> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>>> case X86_EXC_MC: return do_machine_check(regs); >>>> } >>>> break; >>>> >>> >>> For starters you're missing a break, and the only reason this isn't a >>> compile error is the trailing comment. >> >> "break" there would again be unreachable, though. >> >>>   Second, it's a tailcall anyway.  >>> There really is nothing unreachable anywhere in this construct. >> >> Just that the concept of "tailcall" is an optimization, not something >> inherent to the language. >> >>> But by far the most important, it the singular noreturn attribute on >>> do_double_fault() (elsewhere, and not visible when reading these two >>> functions) which is preventing #DF falling into #MC.   This introduces >>> fragility which did not exist previously. >> >> I realized that when making the patch, yet what do you do when the rule >> is as it is? Hence why I added the comment, really. >> >>> do_double_fault() would conditionally return if we ever got around to >>> fixing espfix64. >> >> And hence would have to lose its "noreturn". At which point call sites >> would need inspecting. (As said - yes, I do realize the fragility.) >> >>> So no - I'm going to insist that Eclair is taught to accept "return >>> some_noreturn_fn();" as intentional.  It is objectively less fragile >>> than the MISRA-preferred option. >> >> Nicola, thoughts? > > If you find a suitable argument from the toolchain that the generated > code is correct even though you return from a function where you > promised not to return in its declaration, I suppose that's fine, but > that MISRA Rule I mentioned ("A function declared with a _Noreturn > function specifier shall not return to its caller"), which is not (yet) > applied to Xen exists to defend from stumbling on UB 71 of C11: A > function declared with a _Noreturn function specifier shall not return > to its caller. > > So in general ECLAIR should not accept this by default. What you can do > is deviate these (hopefully few) cases if you have backing evidence of > the correct behavior. The disagreement between you suggesting a deviation and Andrew demanding "that Eclair is taught to accept ..." will need resolving. The argument towards the code being overall less fragile in its original shape cannot easily be put away. And Misra demanding code to be made more fragile than it needs to be cannot really be the goal either. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 06:56:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 06:56:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413993.1643853 (Exim 4.92) (envelope-from ) id 1x4Yhs-0000M5-2d; Thu, 10 Sep 2026 06:56:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413993.1643853; Thu, 10 Sep 2026 06:56:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Yhr-0000Ly-WE; Thu, 10 Sep 2026 06:56:24 +0000 Received: by outflank-mailman (input) for mailman id 1413993; Thu, 10 Sep 2026 06:56:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Yhq-0000Lr-E0 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 06:56:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Yhp-004PWd-3p for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 08:56:21 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2548a-8faa-0a2a0a5109dd-0a2a45069bc6-16 for ; Thu, 10 Sep 2026 08:56:20 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa25494-195a-0a2a45060019-d1558036e070-3 for ; Thu, 10 Sep 2026 08:56:20 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49b8e527d63so84350035e9.2 for ; Wed, 09 Sep 2026 23:56:20 -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-49d26bf2bb2sm46769135e9.7.2026.09.09.23.56.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 23:56:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789023380; x=1789628180; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=ZGeg65X8xrMBCKHpM+4jNdPFWFcOAEGzT83tBCH4FU4=; b=Kl/vmLJvefXzn9oE4kmcsEGw2PAMUS6ZRKqGGKp2psAueQD1v1GxwwRdonG3alXEM2 5lvqt2u+Us424XODrxT+WBwjhQaGuMORQl4idnPcA1+Fyh+a5yIdl25BNsBjWSNoc8AL AzgDMX/58tSJUCjxGYsM3WkiZADUwyq8WzEuWeFHSjsST2M6ENNBI8yzq5A0ePjSmHq6 YmnACEfVRSiArW30+duD/JXaR1kPgsIlIh3GDPMoxyFk8TYpaOcYrXH1vkhRpm30uSuK ZxFyrtmvVOj1qVVzMSR0xD0DKV01elnSwL2yijiNkoRJKGr1bryrTwUTzN+1x4lKmJSr 93OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789023380; x=1789628180; h=content-transfer-encoding:content-type: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:content-type; bh=ZGeg65X8xrMBCKHpM+4jNdPFWFcOAEGzT83tBCH4FU4=; b=DUeHAL0VVaqF3WsjBYPvovGZJJC8Y9PY9BHuABBTlObfu/sQQCYKkV34ZlKGuYOFsa PvqV8kyrjt3otoei3EhIx00yOfUVMqrcrzKNhwocm43N3SkQ2Bjgkuu2WxEthOSAUoEg jaP1qsI/djCePfHP6brdrO5gQYJo8fvN9PTpgmyg8nz1EKwTxz2mm5W1BrEQIF/4bJCB 9pewcLOsghcM6GYCYCjp+9cS29o+HvunAg/1gTXBAiCsiLSZ2gBc5Sw9fDL2IZ8d/YU2 QcGPRkiwUgkycXj9fA09tox/y5ij0YSz4o6+Crzd/vI6pkyrMhpe0eBvF7jGAkSCweJK DSjA== X-Forwarded-Encrypted: i=1; AKwUvBztnADu0jlINjhJqIjEYoAGhTUWAKXYLt+uan3unyB4dAOcogrI8rh1wav9UBGj011L0g6gHOSQpMQ=@lists.xenproject.org X-Gm-Message-State: AFuF++lWqpaLMSDfe4fJC5yEkMh3GHwpxB1RFYcINTHZfRUDBNUieMvj OWynf4jq2ocf+Ug/dvq6YNMzhHEe7eaGjulRS7BHaUTRd2PSmFcKP7z7i6of4oj/GQ== X-Gm-Gg: AYBFou3pA5e+USJL37RotUpssuabhtnHuxL+vq74I3F8RSMf8JsruZi0j9nyWaVQ4VZ UDpoRqlU/hB/IgWwVLNgGIuzTW38ajEdf8r3STGC/0NHoCDXgyCtnd8VJ2zS+0wDdZFMHOR3ldO Z39D07ESR5kUwPisae8/TMhma5vPThnmUFA0BAU04LBt7ZHo6j//tiqLVNSPOxR09Ccy6V8Kvyn 5BsURNlodvBtbWVzH69dO+a0EkQiyhG167OLaaxqWXcLCSGd1ZVo56T/71O84hgNnsVWWG8U+Al cxN3wJNe0fsgKokCOCj8gkYgt1SHQ2dymHWJMwiva4pyEN+drtRMjURMYZWnHWVmWYb/V1wtJKT 2wVTWL3vwRuoG7kJGj/Km8Jp3XqsNs057nM2Dtoou79lXNtqs9WrsJCkU3YGQlmuXvkPyLaPgIv ZA8PZhvKNb1hpNHdjrZrkj2B1/2P90oPBJ2cCocCxopjvZqlbETvFZUmIOHItA11oRszc07D94l +5CWvDuBwBw+8uO0XljndbekqgY9n8/ac2MDcYN7PVgxrdOJp4Z4oXa+pvoGeQ= X-Received: by 2002:a05:600c:34c2:b0:49d:10d6:fd55 with SMTP id 5b1f17b1804b1-49d10d6fdeemr231467635e9.1.1789023380428; Wed, 09 Sep 2026 23:56:20 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 08:56:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 00/20] Introduce enablemenant of dom0less To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Timothy Pearson , Alistair Francis , Connor Davis , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-16d1c6/1789023380-FDC0F77B-CF0FB9B6/0/0 X-purgate-type: clean X-purgate-size: 4227 On 09.09.2026 17:07, Oleksii Kurochko wrote: > This patch series reprensent a bunch of patches necessary to enable common part > of Dom0less. > The stuff necessary to start/launch domains will be introduced separately. > > CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2829940455 > > --- > Changes in v9: > - Address the comments. > --- > Changes in v8: > - Address the comments. > - Rename some variable in [PATCH v8 11/20] xen/riscv: introduce per-vCPU IMSIC state. > - Drop vaplic_init() and vcpu_aplic_deinit() in > [PATCH v8 12/20] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure. > --- > Changes in v7: > - Merged to upstream/staging: > - xen/riscv: Implement ARCH_PAGING_MEMPOOL > - xen: arm: update p2m_set_allocation() prototype > - xen/riscv: do a 4th linking pass if necessary > - Address the comments from ML. > --- > Changes in v6: > - Merged to upstream/staging: > - xen: arm: move declaration of map_device_irqs_to_domain() to common header > - xen/Kconfig: introduce HAS_STATIC_MEMORY > - xen/riscv: rename enum intc_version to intc_variant > - xen/riscv: implement prerequisites for domain_create() > - Move UBSAN fix ("xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page") > to this patch series as it is connected to "xen/Kconfig: introduce HAS_STATIC_MEMORY". > - Address the comments from ML. > --- > Changes in v5: > - Add new patch (xen/riscv: do a 4th linking pass if necessary) which fixes > randconfig job issue. > - Address comments from ML. > --- > Changes in v4: > - Address comments from ML. > --- > Changes in v3: > - Drop dependency from other patch series > ([1] https://lore.kernel.org/xen-devel/cover.1778140240.git.oleksii.kurochko@gmail.com/T/#t) > as it was merged. > - Reorder patches: > - move common patches to the start. > - Move some patches to separate patch series (will be introduced later) > - Address comments from ML. > --- > Changes in v2: > - Move patch "[PATCH v1 04/27] xen/riscv: rework G-stage mode handling" to > patch series [1] > - Address the comments from ML. > - The following patches were folded into one: > # xen/riscv: implement init_intc_phandle() > # xen/riscv: call do_initcalls() in start_xen() > # xen/riscv: setup system domains > - The following patch were folded into one: > # xen/riscv: add vaplic access check > # xen/riscv: emulate guest writes to virtual APLIC MMIO > # xen/riscv: emulate guest reads from virtual APLIC MMIO > - Add new bug fix, not really necessary to this patch series: > xen/riscv: manage IRQ_DISABLED flag in APLIC irq enable/disable callbacks > --- > > Oleksii Kurochko (20): > xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page > xen/dom0less: turn max_init_domid into a common variable > xen/riscv: Implement construct_domain() > xen/riscv: introduce guest riscv,isa string > xen/riscv: implement make_cpus_node() > xen/riscv: implement make_timer_node() > xen/riscv: implement make_arch_nodes() > xen/riscv: introduce init interrupt controller operations > xen/riscv: implement make_intc_domU_node() > xen/riscv: introduce aia_init() and aia_usable() > xen/riscv: introduce per-vCPU IMSIC state > xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure > xen/riscv: introduce (de)initialization helpers for vINTC > xen/riscv: generate IMSIC DT node for guest domains > xen/riscv: create APLIC DT node for guest domains > xen/riscv: implement IRQ routing for device passthrough > xen/riscv: implement init_intc_phandle() > xen/riscv: initialize RCU, scheduler, and system domains in > start_xen() > xen/riscv: provide init_vuart() > xen/riscv: add initial dom0less infrastructure support It is hard to tell how far into the series things could be committed without committing patch 1 (which _still_, despite me pointing out the need, is lacking an Arm ack). I'll be conservative and try solely patch 02. (Also, btw, we're at v9 and you still didn't notice the typo in this cover letter's subject.) Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 07:29:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 07:29:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414010.1643862 (Exim 4.92) (envelope-from ) id 1x4ZE8-0004pU-FV; Thu, 10 Sep 2026 07:29:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414010.1643862; Thu, 10 Sep 2026 07:29:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZE8-0004pN-Cu; Thu, 10 Sep 2026 07:29:44 +0000 Received: by outflank-mailman (input) for mailman id 1414010; Thu, 10 Sep 2026 07:29:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZE6-0004oy-OJ for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 07:29:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4ZE4-007KLQ-RM for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:29:40 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa25c60-2eae-0a2a0a5409dd-0a2a450ac260-16 for ; Thu, 10 Sep 2026 09:29:40 +0200 Received: from [209.85.221.41] (helo=mail-wr1-f41.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa25c64-f2d2-0a2a450a0019-d155dd29d434-3 for ; Thu, 10 Sep 2026 09:29:40 +0200 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-48436216a98so4644370f8f.0 for ; Thu, 10 Sep 2026 00:29:40 -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-49d1fd532dcsm103274285e9.1.2026.09.10.00.29.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 00:29:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789025380; x=1789630180; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=shTrhPJT0Rvh0GI+uaE1DcyfXYiG/sseduOAlSbGj+Y=; b=Z7H3jFxvu+sKPAAs5Q5c1XSNG04Nb+xnygTjBX3sUmnTM4QW1wwmjfkeqEauPYmi02 0JUssQ4ORh9iCAfiyEPEarbANVTzLpfeOEcsocAK+lh663zyYxQ/iN+1Rbiij5a7EXso wSEEJ5fcl7INx3jHRjoykhVB+Ll4Ombs5jkTqo1Ub3TKynZxsNjpneLtLTb31ot1hh0A EFWov5O3CJzLIZEgx32WYHN+gDZXGnZWHYUjRg8aJl21UEpmiOQjzPhztOnEpH0AAlMX ooecdD1q2MChJ6aGvpdtFI6lkRBqw2Mo574qdoa9SCpfRUJL+p9fAAY5+uq30sy6QnDQ 73Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789025380; x=1789630180; h=content-transfer-encoding:content-type: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:content-type; bh=shTrhPJT0Rvh0GI+uaE1DcyfXYiG/sseduOAlSbGj+Y=; b=Rw2zq9ts8x2XROdCOp/LIikoS32ll+91bPrEQhuBUqaQzhjCrBSoeZ7fwhfbsFr4yH 9yMI99gqZpxx8aKyiHjoxYudz5nnkaR3elz9eeSsqzJHJAncYo1CC1FaKQ6lqak8Y84P VjlkVzcFzXoWI2j0WUgvPQBwkji3Zas4pJ/Y6bIWKChsfEWp8rH6tylNMJqQc2sHAydj BXl5q7Do0NZIrI5HrJwL07bhpcO/WStDkF/8/wsullObzjVEHv1XQL+ZzZNK/GJhh8T2 mD3kvR1ZmTgpDy14kFB7UpmsHwApvsqNyQeZl/fJmvCJn+3ad4pBPoZLU6kb3j2d+MXU Vh/g== X-Forwarded-Encrypted: i=1; AKwUvBxSvqO01Ku5BrOot5eWKvyYSUiCwU9R2IS9REsGIQJKSuWn/8aqB+F3lC+EAXOb078KEhlekgelrxE=@lists.xenproject.org X-Gm-Message-State: AFuF++k/kjjAks5AVr7hA5ELCBt7/82AbcjadZLC7cjVW+JqHMdeUTiI hRjYCI8MC+JK9sC03I+VCoB6VT9MZC5KVNuVwOzzoOK60VRYSTxl6wS7bNqCtoDfjw== X-Gm-Gg: AYBFou3FfYSskUoe510r1hDcs3wpqlPUDhfhv9AW0ms3b0mx+MdSCCLUX1xJR8cyiCj 26LdIpdTzEaSS1JxrhzCmXHBl+z7/nSJTBsgbfn8Vg7LPlyXQ3NYIK6EJaSChLXEIMfoerCpOjk w4Rcvp/3IavFrWXUcuRj32+2czyYX1ve/yDblHig1SbuxuFJfzhrl0MjyE/FVhAOnkY7fLtg2sX 327HaMU5TI4VkoDhSrLgCnGpwGkC8Chgirs3bYL0SaPo390AgqxQE9qWnpV+11YOU/lHfoHyUqH iugA/eaqNTaGdhDD+mTihNIN+Iu+UgAs3kGqn32vWDU4GdravdmsHJobrGaLL45gErdI/HCZx98 wxWSJJQNUcm7HlB1mkpXVvFurhThH/+oV8GQH7BwlPb+bM/LrMXp3PCjfOWTKCUd1shkFO7D8iZ rm5a04ELXZnBsur0/MtnJYPKKnJbkaqN12si1KCTf/fvxjGGt/+TGiLSJdT24f2pWL3gSGBh4m4 adIIiQsfdCL4K7pIi2bgDKY2+5T/NWEV5GEo6D6TcQ9o7CAapQY/RYJBnl8lss= X-Received: by 2002:a05:600c:474a:b0:49c:e42b:a4ac with SMTP id 5b1f17b1804b1-49cf823f60amr355087195e9.11.1789025380158; Thu, 10 Sep 2026 00:29:40 -0700 (PDT) Message-ID: <73918fa5-0c61-4a91-8e44-be5bd377141b@suse.com> Date: Thu, 10 Sep 2026 09:29:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Validate the L1 MSRPM physical address range To: Lin Liu Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , Abdelkareem Abdelsaamad , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-4011c0/1789025380-524DFCFC-25DAB5EC/0/0 X-purgate-type: clean X-purgate-size: 342 On 10.09.2026 08:18, Lin Liu wrote: > 8c36d5a500 ("x86/nSVM: Validate the L1 IOPM physical address range") added > this check for the IOPM. The MSRPM requires a check as well. See https://lists.xen.org/archives/html/xen-devel/2026-08/msg00242.html and Abdelkareem's reply. If you disagree, please go into further detail here. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 07:36:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 07:36:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414017.1643871 (Exim 4.92) (envelope-from ) id 1x4ZKZ-0006Lh-3k; Thu, 10 Sep 2026 07:36:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414017.1643871; Thu, 10 Sep 2026 07:36:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZKZ-0006La-0w; Thu, 10 Sep 2026 07:36:23 +0000 Received: by outflank-mailman (input) for mailman id 1414017; Thu, 10 Sep 2026 07:36:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZKY-0006LU-Fa for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 07:36:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4ZKX-007zkR-0D; Thu, 10 Sep 2026 07:36:21 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4ZKX-005jP5-1f; Thu, 10 Sep 2026 07:36:21 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Vy7/5yw5D43SVvElmSodx3WN5su6H6CmFdyMxNAl5s8=; b=Z8wCFOZxiXaF9zinIS8nWs9cnb FgeB80T9oYGkppdmwt7f++Enb2qXywAbmT+QhCe4oNEWdgwzpjCNWb4da+vNnnJTp0Y4VkZggjvIl zwuH9Rn7s2Oeo2ezv4QjT6tajoNg2y+BCmqFJCjlZV+qexDH2vZgRnEIpeTLrxUlzDcI=; Date: Thu, 10 Sep 2026 09:36:15 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 02/12] x86/mm: pagetable_dying() is HVM+SHADOW_PAGING only Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <12b3dd09-7249-47cd-8c66-e0efc1611b14@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12b3dd09-7249-47cd-8c66-e0efc1611b14@suse.com> On Fri, Aug 28, 2026 at 09:00:04AM +0200, Jan Beulich wrote: > The referenced commit didn't go far enough, leaving a Misra rule 2.1 > (unreachable code) violation: The function lacks "noreturn" in this > configuration. Since with SHADOW_PAGING=n paging_mode_shadow() is compile- > time-constant false, the compiler can DCE the call site. Hence we can > avoid building the function itself altogether. > > No functional change. > > Fixes: 2fb2dee1ac62 ("x86/mm: pagetable_dying() is HVM-only") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 10 07:38:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 07:38:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414024.1643880 (Exim 4.92) (envelope-from ) id 1x4ZMt-0006vv-DO; Thu, 10 Sep 2026 07:38:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414024.1643880; Thu, 10 Sep 2026 07:38:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZMt-0006vo-Ai; Thu, 10 Sep 2026 07:38:47 +0000 Received: by outflank-mailman (input) for mailman id 1414024; Thu, 10 Sep 2026 07:38:46 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZMs-0006vi-9R for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 07:38:46 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4ZMr-007zlr-0R; Thu, 10 Sep 2026 07:38:45 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4ZMr-005rLE-20; Thu, 10 Sep 2026 07:38:45 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=ZadJenT7WXiUfYrdH3hkxphw83tVWloPDVk8Swz1wLc=; b=zuh7zuydL8d8y2WUh7fJRu3IdD vw5bRRfQshxOJu5wBSGDuNqvfsewyIe38Oy6fcn4iLqg3bryPfO5I69MN0CyRcjEgvOYBWVjZ+DN1 UDubSNStjjuAKX0GEGDHtEi2CoCWnGfvQhsbQNxCS2u+sMOtOfTAP2ghFsRuGeCO6agA=; Date: Thu, 10 Sep 2026 09:38:43 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 01/12] x86/IO-APIC: address Misra 2.1 rule violations Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <85c111a5-105c-4b8f-8b81-d7ec1d0f9436@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <85c111a5-105c-4b8f-8b81-d7ec1d0f9436@suse.com> On Fri, Aug 28, 2026 at 08:59:41AM +0200, Jan Beulich wrote: > In both functions cases 0..3 are handled, and a 2-bit mask is applied to > the switch() expression. Therefore the default: cases are reported > unreachable by Eclair. Subsume the "case 2" blocks each into the > corresponding default ones. > > While there also drop all the pointless figure braces inside the various > case blocks, inserting blank lines instead between them. > > No functional change. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > > --- a/xen/arch/x86/io_apic.c > +++ b/xen/arch/x86/io_apic.c > @@ -804,66 +804,48 @@ static int __init MPBIOS_polarity(int id > switch (mp_irqs[idx].mpc_irqflag & 3) > { > case 0: /* conforms, ie. bus-type dependent polarity */ > - { > switch (mp_bus_id_to_type[bus]) > { > case MP_BUS_ISA: /* ISA pin */ > - { > polarity = default_ISA_polarity(idx); > break; > - } > + > case MP_BUS_EISA: /* EISA pin */ > - { > polarity = default_EISA_polarity(idx); > break; > - } > + > case MP_BUS_PCI: /* PCI pin */ > - { > polarity = default_PCI_polarity(idx); > break; > - } > + > case MP_BUS_MCA: /* MCA pin */ > - { > polarity = default_MCA_polarity(idx); > break; > - } > + > case MP_BUS_NEC98: /* NEC 98 pin */ > - { > polarity = default_NEC98_polarity(idx); > break; > - } > + > default: > - { > printk(KERN_WARNING "broken BIOS!!\n"); > polarity = 1; > break; > } > - } > break; > - } > + > case 1: /* high active */ > - { > polarity = 0; > break; > - } > - case 2: /* reserved */ > - { > - printk(KERN_WARNING "broken BIOS!!\n"); > - polarity = 1; > - break; > - } > + > case 3: /* low active */ > - { > polarity = 1; > break; > - } > - default: /* invalid */ > - { > + > + default: /* reserved */ > printk(KERN_WARNING "broken BIOS!!\n"); We should also see about improving those messages, because this is not helpful at all. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 10 07:39:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 07:39:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1413940.1643889 (Exim 4.92) (envelope-from ) id 1x4ZNu-0007Q1-Lf; Thu, 10 Sep 2026 07:39:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1413940.1643889; Thu, 10 Sep 2026 07:39:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZNu-0007Pu-J9; Thu, 10 Sep 2026 07:39:50 +0000 Received: by outflank-mailman (input) for mailman id 1413940; Thu, 10 Sep 2026 06:18:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Y7a-0002Vu-Qn for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 06:18:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4Y7X-004ngE-AN for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 08:18:51 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa24bc7-2eae-0a2a0a5409dd-0a2a4506d066-12 for ; Thu, 10 Sep 2026 08:18:51 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa24bca-195a-0a2a45060019-a0658308e172-3 for ; Thu, 10 Sep 2026 08:18:51 +0200 Received: from xenrt10716048 (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id D45B0455F60E; Thu, 10 Sep 2026 02:16:53 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Lin Liu To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie , Abdelkareem Abdelsaamad , Lin Liu Subject: [PATCH] x86/nSVM: Validate the L1 MSRPM physical address range Date: Thu, 10 Sep 2026 06:18:43 +0000 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1789021131-FE67277B-EBEBBB5A/0/0 X-purgate-type: clean X-purgate-size: 2357 8c36d5a500 ("x86/nSVM: Validate the L1 IOPM physical address range") added this check for the IOPM. The MSRPM requires a check as well. "The MSR or IOIO intercept tables extend to a physical address that is greater than or equal to the maximum supported physical address" is illegal VMCB state. Refer to APM vol.2 15.5. Assisted-by: Claude:claude-opus-5 Signed-off-by: Lin Liu --- xen/arch/x86/hvm/svm/nestedsvm.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 5adb1bd72c..3614473702 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -283,6 +283,12 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) return 0; } +static bool nsvm_perm_map_valid(const struct vcpu *v, uint64_t base, + unsigned int last) +{ + return gfn_valid(v->domain, gfn_add(gaddr_to_gfn(base), PFN_DOWN(last))); +} + static int nsvm_vmrun_permissionmap(struct vcpu *v) { struct svm_vcpu *arch_svm = &v->arch.hvm.svm; @@ -295,18 +301,22 @@ static int nsvm_vmrun_permissionmap(struct vcpu *v) enum hvm_translation_result ret; unsigned long *ns_viomap; bool ioport_80 = true, ioport_ed = true; - /* IOPM is structured as a linear array of 64K+3 bits. */ - gfn_t ns_iopm_end = - gfn_add(gaddr_to_gfn(ns_vmcb->_iopm_base_pa), - PFN_DOWN((0x10000 + 3) / 8)); - if ( !gfn_valid(v->domain, ns_iopm_end) ) + /* IOPM is structured as a linear array of 64K+3 bits. */ + if ( !nsvm_perm_map_valid(v, ns_vmcb->_iopm_base_pa, (0x10000 + 3) / 8) ) { gdprintk(XENLOG_ERR, "%s invalid _iopm_base_pa address (%#"PRIx64")\n", __func__, ns_vmcb->_iopm_base_pa); return NSVM_ERROR_VVMCB; } + if ( !nsvm_perm_map_valid(v, ns_vmcb->_msrpm_base_pa, MSRPM_SIZE - 1) ) + { + gdprintk(XENLOG_ERR, "%s invalid _msrpm_base_pa address (%#"PRIx64")\n", + __func__, ns_vmcb->_msrpm_base_pa); + return NSVM_ERROR_VVMCB; + } + ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm; ret = hvm_copy_from_guest_phys(svm->ns_cached_msrpm, -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 07:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 07:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414060.1643899 (Exim 4.92) (envelope-from ) id 1x4ZS8-0000bD-88; Thu, 10 Sep 2026 07:44:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414060.1643899; Thu, 10 Sep 2026 07:44:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZS8-0000b6-5H; Thu, 10 Sep 2026 07:44:12 +0000 Received: by outflank-mailman (input) for mailman id 1414060; Thu, 10 Sep 2026 07:44:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZS6-0000b0-VJ for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 07:44:10 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4ZS5-007zuY-1R; Thu, 10 Sep 2026 07:44:09 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4ZS5-0069N6-2z; Thu, 10 Sep 2026 07:44:09 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=kuAXpiu8NosbbBAcbeswokbW1v5xo6hOB9np/FBn9no=; b=EEmyBLb443GbsSJ7scFDsaCBNO rMzWTlO5bKcZwSt+rt4uf3zOzISdjYllUdcRsFYPUzoAVECMJT6j0jQ4dl4U37i6abAj8MEUFkNXy SmpQrS8JwMyps5vB9pXl4Z3eMEY/Z6zw035N0yaxje9H/p17iAgEV68kUv6gqLYIGqb4=; Date: Thu, 10 Sep 2026 09:44:07 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 12/12] x86/nSVM: address Misra 2.1 rule violation Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Aug 28, 2026 at 09:06:20AM +0200, Jan Beulich wrote: > The 16-bit range of "port" is fully handled by the switch(). Therefore the > default: case is reported unreachable by Eclair. Insert BUILD_ERROR() to > annotate this for Eclair. > > No functional change. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné That however is a bit weird IMO, as we have usually said we would prefer not to use fixed width types in general, and hence one might argue that port should be unsigned int. Then the BUILD_ERROR() might trigger? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 10 07:45:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 07:45:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414069.1643907 (Exim 4.92) (envelope-from ) id 1x4ZTk-0001Fg-Ha; Thu, 10 Sep 2026 07:45:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414069.1643907; Thu, 10 Sep 2026 07:45:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZTk-0001FZ-Eo; Thu, 10 Sep 2026 07:45:52 +0000 Received: by outflank-mailman (input) for mailman id 1414069; Thu, 10 Sep 2026 07:45:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZTi-0001FR-Ja for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 07:45:50 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4ZTg-007zvy-1d; Thu, 10 Sep 2026 07:45:48 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4ZTg-006F4X-3D; Thu, 10 Sep 2026 07:45:48 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=qUqpvrLm01bEV3rqQHuL2VV7JdXjeU4C+n/Ocjhb0yM=; b=gVBDZQArKMxHixqEo2I9uxhHkH gnsi+cgsfacGGtmnYCqoifCJ9YnpbMqQrMl70GcKO40bJOwswyMKZhVLKlI27j92tYQzieqNNUU79 mwqIGRKraPtqQrJsSWka613MqMNBOkX3xtKaQ7PZuX9V8kwyx9Us90ul6Ikhb/UIhZlM=; Date: Thu, 10 Sep 2026 09:45:46 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie , Tim Deegan Subject: Re: [PATCH 03/12] x86/shadow: eliminate unused forms of sh_map_and_validate_gle() Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <9c4e5674-e79e-4623-b87c-ada690778ffa@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9c4e5674-e79e-4623-b87c-ada690778ffa@suse.com> On Fri, Aug 28, 2026 at 09:00:57AM +0200, Jan Beulich wrote: > The L2H, L3, and L4 forms only have GUEST_PAGING_LEVELS=4 call sites, i.e. > their 2- and 3-level forms are unreachable, violating Misra rule 2.1. The > L2H form additionally is unused (call site DCE-d) with PV32=n. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Looks like a net win in the number of ifdefs. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 10 07:50:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 07:50:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414077.1643916 (Exim 4.92) (envelope-from ) id 1x4ZXl-00022Z-0V; Thu, 10 Sep 2026 07:50:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414077.1643916; Thu, 10 Sep 2026 07:50:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZXk-00022S-UA; Thu, 10 Sep 2026 07:50:00 +0000 Received: by outflank-mailman (input) for mailman id 1414077; Thu, 10 Sep 2026 07:49:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ZXj-00022M-DV for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 07:49:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4ZXh-00801K-2v; Thu, 10 Sep 2026 07:49:58 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4ZXi-006Sm2-1H; Thu, 10 Sep 2026 07:49:58 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=/nkYktJ/Gms1fzlmyRlujUNA/qmGw3jyNW7tB6Jbk0A=; b=wbZO2Y+O3TZfMPE9irRLKAt8e/ 9cRow/HOqoZ5rwXZ7x66/YpwQPjJ7806mfo7QFkijSBi/gayppt8VP0bq1KnRcayRkoepHq5YiQ0Q jsGwl/w+Dsr9k0vRJAjYZ3uHbszvcKHMxFvR4W26VtelmwNSN8mMjIWhZBaoarrjZvyA=; Date: Thu, 10 Sep 2026 09:49:56 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com> On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote: > The use of unreachable(), when unreachability is visible to Eclair (and > compilers), is deemed a violation. Drop the redundant statement. Urg, isn't that something that should be fixed in Eclair then? Otherwise all the unreachable() calls in our codebase are likely to be found by Eclair sooner or later, and will need to be removed. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 10 07:55:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 07:55:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414089.1643926 (Exim 4.92) (envelope-from ) id 1x4Zcd-0003Ya-Iv; Thu, 10 Sep 2026 07:55:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414089.1643926; Thu, 10 Sep 2026 07:55:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Zcd-0003YT-Fp; Thu, 10 Sep 2026 07:55:03 +0000 Received: by outflank-mailman (input) for mailman id 1414089; Thu, 10 Sep 2026 07:55:02 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4Zcc-0003YN-Fi for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 07:55:02 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4Zca-00807d-34; Thu, 10 Sep 2026 07:55:01 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4Zcb-006j5N-1J; Thu, 10 Sep 2026 07:55:01 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=ZeLEtSI+pTw804a0+0vh7wmdpkxtV8MoRKXGVeME87M=; b=eWE1qF9KzqSNwU61M1bQGNb9eh u7k7ATuzl6OAm0p7529GmUqUFqv/1Ona+RxDEiP1fKzqcbSK7p326ZY7EDjhXKmrpjzZfGdS5zZQr ftRl9UWl1Owj44BOwSmc6LI+2WLPSGZP6Pn4pR2AWUpXbTgFWwJDDlcK9wkHYy+j1HfI=; Date: Thu, 10 Sep 2026 09:54:58 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 11/12] x86/HVM: address Misra 2.1 rule violations Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <65330fe2-0a0d-4b70-a647-27290d0041e0@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <65330fe2-0a0d-4b70-a647-27290d0041e0@suse.com> On Fri, Aug 28, 2026 at 09:05:43AM +0200, Jan Beulich wrote: > In hvm_set_cr3() the "bad_cr3" label is reachable only with > SHADOW_PAGING=y; the code being there is therefore a Misra rule 2.1 > (unreachable code) violation when SHADOW_PAGING=n. > > Similarly code past the initial switch() in hvm_debug_op() is reachable > only when CONFIG_INTEL_VMX=y. > > No functional change. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 10 08:38:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 08:38:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414157.1643955 (Exim 4.92) (envelope-from ) id 1x4aIp-0001Un-5N; Thu, 10 Sep 2026 08:38:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414157.1643955; Thu, 10 Sep 2026 08:38:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4aIp-0001UN-2B; Thu, 10 Sep 2026 08:38:39 +0000 Received: by outflank-mailman (input) for mailman id 1414157; Thu, 10 Sep 2026 08:38:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4aIo-0001U6-5n for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 08:38:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4aIm-001qTP-UV for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 10:38:36 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa26c84-8faa-0a2a0a5109dd-0a2a45058a6e-24 for ; Thu, 10 Sep 2026 10:38:36 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa26c8c-4cb1-0a2a45050019-d1558033ed16-3 for ; Thu, 10 Sep 2026 10:38:36 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so78283305e9.1 for ; Thu, 10 Sep 2026 01:38:36 -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-49d26bc08edsm36238895e9.3.2026.09.10.01.38.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 01:38:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789029516; x=1789634316; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=lZZC7wigyBTvp1BFyhOuPgXhvvKf9IAra8F/1p1aImM=; b=DipOqXdLcVeIHnglixtvqvQ3EKEwRtZ2DteRpXI8EODndV+a5Kl4dG8hJJlL70HzHN aZEUO7s7sQY28tJOo/Ir/jXPQ7whlnil1g/PhF5prxydD8T92/dYtGsSEeSksnLs8zv5 HI47OvZmO1RWGwr4cA0I7v4sCULmjW6NvpZfdCybgAzrHegwObt72l7YtGGnHA9TZTOC CDzYdK72UQ7ECcGBypNonRKrElcsoC6Qa6+EuPN4RKHKlXWBZWZ4KFEI954bFUeiTbil WKsGydjySPg+TZqT/mkZM5nwZH3a4IgYBiFqxhGhDUzD+hVoRqcsGCiNyCs2OiNgQvbS txtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789029516; x=1789634316; h=content-transfer-encoding:content-type: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:content-type; bh=lZZC7wigyBTvp1BFyhOuPgXhvvKf9IAra8F/1p1aImM=; b=A8co1h5WnpbY1bmJeg6YBap4zcVvOxt/n7VTQqaj02k0I+cN+D+vOrW6S8t0+Hf+kV SohFzfoUm9gCpLUu6uYCadwO8AqaOL63nWX/Nx3MmI+wIN+yJ0hvR2+2+VcSXPT32TCd YEb4usziK7Y42fmEcSegWpveA/4KSwiQRzf1UxRZ1yJGzOyRe2RhstZn4oxh1TuCKRLR TBgp9CEJiJGNl8VX5uaexhgjQ4/16V91Zsm7y4ll0Tx7HSVMH9Ysg10Y1kAaBx9IjmLm WMGDxhCHoh1KLqjfbhtDEcwqA6U+KRN83iEd8xPmxLN1xjk6kag3rwX1SczN8cPGLSWW 5j5Q== X-Gm-Message-State: AFuF++m1OewApJbPaH4ADmX4iKgeQtweUoT4KHC0eB9+Hb4SIv38q+Ec 5iyeSuUwQ2LOSCv/LaANT//6kalRr+VrmU8A7qReuLubhtf46Bn3egyQ4dOSV7NJDQ== X-Gm-Gg: AYBFou393GAVSLHdpHol+wa9M/8vMzV7dlM1yAdMW/737c/05qG3cvpaHH+6Ceu6exw 96YWzBImRNL03f+AnX9dgnGGdGlsHCh123H2sCEeoWIztD0VoNXeSpfw/jPAR9Hl1B7XSz+DxME rnFudEyoEZUgl6mPRfsb139gu0YEzyMmtXtGJGsUznZ01c4eoyUY/z61ExRsvufn7vlYG0uJz/f NKyvTJ17vdoV5wEcsYJvx+mWBmnf2cE54c4/NIO4DPvs8gjFK4pfZ2W/WOiPcNJjZEb420WuArF TPa+Z/cWUt8mf3dBcNUfbuL0yqYOLm57Pm5vnsOIalIf5Wo3ox+EP9nrDr+YDU/IQhxSzJEjcUJ 6W3+v6pNca6lS/oONmPxFy1ZZkNsN9Yrx8gyfRJGtPacJJHPPVmNIe0FK8KKHDGrfbhg7OhcOqn ALwkQ/fEQRLHlFpKGD4dRAqPMrMAcIBYBdBjtf6blhADSrCklStg1rZnkOigcVRv8wCSwGnJRBp 9C5HWeXRLAVaP36Cmh+l6LK2VFnyp0uWeOBo7J+JF61BwJmJsDXKn1wOzFVZyQ= X-Received: by 2002:a05:600c:190b:b0:49c:fc6c:be12 with SMTP id 5b1f17b1804b1-49cfc6cc0acmr332222285e9.24.1789029515881; Thu, 10 Sep 2026 01:38:35 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 10:38:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@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: 8bit X-purgate-ID: tlsNG-c201ff/1789029516-F64B42A1-88AD3134/0/0 X-purgate-type: clean X-purgate-size: 570 On 10.09.2026 09:49, Roger Pau Monné wrote: > On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote: >> The use of unreachable(), when unreachability is visible to Eclair (and >> compilers), is deemed a violation. Drop the redundant statement. > > Urg, isn't that something that should be fixed in Eclair then? > Otherwise all the unreachable() calls in our codebase are likely to be > found by Eclair sooner or later, and will need to be removed. No, aiui most are covered by deviations. In particular ones in BUG() and ASSERT_UNREACHABLE(). Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 08:42:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 08:42:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414165.1643964 (Exim 4.92) (envelope-from ) id 1x4aMc-0002yg-KR; Thu, 10 Sep 2026 08:42:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414165.1643964; Thu, 10 Sep 2026 08:42:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4aMc-0002yY-HQ; Thu, 10 Sep 2026 08:42:34 +0000 Received: by outflank-mailman (input) for mailman id 1414165; Thu, 10 Sep 2026 08:42:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4aMa-0002yQ-N4 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 08:42:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4aMa-005HuE-3k for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 10:42:32 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa26d6f-bab6-0a2a0a5309dd-0a2a4507a658-30 for ; Thu, 10 Sep 2026 10:42:32 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa26d77-b4ea-0a2a45070019-4a7de14c8c82-3 for ; Thu, 10 Sep 2026 10:42:32 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843172bff4so605485f8f.0 for ; Thu, 10 Sep 2026 01:42:32 -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 ffacd0b85a97d-48588390e30sm47425843f8f.7.2026.09.10.01.42.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 01:42:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789029751; x=1789634551; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=1pWuZG3C9ZMCfHNOsmsZlnGOIA4yXPpXBgL2cwq5Bkc=; b=KJTOEuwSUP99YkaPecKiibamO1m70hGtY0nSkiB++upCP5lrN2K4K9iiAimqtq4RQL 8MSbCVNzRXGbUt+AdFz02CO2KISpYEQJgQyi+gfPFP+EcKYmKugfxGkBX/Z99G66BVAd r/xspqbyBFcfKEudzyvmcefXR/cov20agR5HSpJRKVpQRh+2VHSJFu1EoyXWQmThC06N mfI+2aBnPwrCNculTsYTYCeGtwZIZTV1RgWlWXCL2JJSbk9GfIxrCX+xHS1WkCzKthg5 vwRJODSRqYZhxvwQGJDkSLBLceLPC6XpLSPcZzGXE+RV4EZGFDv62/1mC8jjt+Kew9b+ iFGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789029751; x=1789634551; h=content-transfer-encoding:content-type: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:content-type; bh=1pWuZG3C9ZMCfHNOsmsZlnGOIA4yXPpXBgL2cwq5Bkc=; b=GMXl8gG+QaGJx7iqCRzBc+bLuKLVGUrowaYSjoRJbblyGm4uFZ6PPwgl3h/U09MNqK Ll8OFHNpfwcjMvYzbqe48zE/n5dS4t27eJO1Xf4iEEBONthD1uJiMyAJZUOMD9UOd7sd KTPiCgv+bcQynol7SSfydwdynh8k7L0bGZjEfgWyiS+8zzkRTOwlKx0s4Sm2KgEjoNXG dztkSvHqR/e/ws2+NDArZs662HuDEDFHHbbckpHDUDD2UcWvE+6tea8Zw+y7SYBKQMDH yWxN//DfX1glvUTNyS1XJSg3LjVHUHSRjn+mGjImNRnYKuku8OjbEqzhktAAVUvw+dpU gAjg== X-Gm-Message-State: AFuF++msFw4dA9gCbO/xJoKr5I4VY36GWXCEZArvUWH2O+Os2h9gy3QR mlJZy63TswfFX0Pnz6pE2Ee9jvgqVhlCavGYJcCImsECa9VaZmFNytTs2SSYDzSpHA== X-Gm-Gg: AYBFou2xBv6x8WTwOnk2LQsNy9LC+/FPDxf/G6YIHnMyPzdWLeHCnPHV4YbZlB6fWMW 0vnVn3lUiANh4oSvg2OXtFc8bLS0y9+hx+40oWbKkqmATl7d9jkewJJj4XRyMJ5fFUPSZB46n/0 8rUG0KYWI7uKA++uIHUVPB41+gbJSzzZFVl0R9TZ71otbfBt4bCFZL7Bf/izejGdcOSQbAq3YyB P3exXHO6bamH0qZytNMF98tY+J75D4MA5zbVHbhP3AVWi5mN+j/5xMdfD3ryMKz45le6Zi+mhtY AqBfzpSyDwrYzb06+g+9O23SZAxbLWeWWSldIL3Ly9Co1eNyJlK+4dFTNB+9BVdFV/ylXRPB4F0 60PJO0jLMjWRYXG5oQ6ecc3fO+ns1BgxRZWtobGXCaLb+AWbCraX01/unyTPx7b7ylyys/EEulL zATPtXbOWuXmAd5MTeVKVmqmQ4hW0h3AFTzxOX/BphmQTeI3mtYP51mjxS5zAbxTjxvG80GwxO9 MO9orQr1ZaOgv5tKr0IDmJBCrdahBuk8IVFa45EWzVzg+oZlerhbaBUCOT8Nvs= X-Received: by 2002:a05:6000:4020:b0:485:8f37:79b7 with SMTP id ffacd0b85a97d-485c23d66camr5721741f8f.33.1789029751489; Thu, 10 Sep 2026 01:42:31 -0700 (PDT) Message-ID: <8bf3576c-2d76-49c2-9df1-a8303f0090d2@suse.com> Date: Thu, 10 Sep 2026 10:42:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 12/12] x86/nSVM: address Misra 2.1 rule violation To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@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: 8bit X-purgate-ID: tlsNG-ef75cf/1789029752-37CD7AE4-0C473EED/0/0 X-purgate-type: clean X-purgate-size: 881 On 10.09.2026 09:44, Roger Pau Monné wrote: > On Fri, Aug 28, 2026 at 09:06:20AM +0200, Jan Beulich wrote: >> The 16-bit range of "port" is fully handled by the switch(). Therefore the >> default: case is reported unreachable by Eclair. Insert BUILD_ERROR() to >> annotate this for Eclair. >> >> No functional change. >> >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. > That however is a bit weird IMO, as we have usually said we would > prefer not to use fixed width types in general, and hence one might > argue that port should be unsigned int. Then the BUILD_ERROR() might > trigger? Yes, such a type change would need accompanying by removal of that BUILD_ERROR(). The default: case then also wouldn't be deemed unreachable anymore (even though in practice it still would be). Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:15:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:15:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414196.1643973 (Exim 4.92) (envelope-from ) id 1x4asG-0007ZE-08; Thu, 10 Sep 2026 09:15:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414196.1643973; Thu, 10 Sep 2026 09:15:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4asF-0007Z7-Tb; Thu, 10 Sep 2026 09:15:15 +0000 Received: by outflank-mailman (input) for mailman id 1414196; Thu, 10 Sep 2026 09:15:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4asE-0007Z0-EN for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:15:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4asD-00G3Ul-Q4 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:15:13 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2751c-bab6-0a2a0a5309dd-0a2a450bd7c0-18 for ; Thu, 10 Sep 2026 11:15:13 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa27521-b7e8-0a2a450b0019-4a7de18c8d90-3 for ; Thu, 10 Sep 2026 11:15:13 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49d097b4939so5960005e9.0 for ; Thu, 10 Sep 2026 02:15:13 -0700 (PDT) Received: from debian.debian ([102.213.48.6]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d26c38e3asm64476215e9.9.2026.09.10.02.15.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 02:15:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789031713; x=1789636513; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Hk6ntHXUeJYTRX8HAaEa/PKmgwGWJjC3R3z8/hR5mi8=; b=ELxyRKE9rY7of6aqO9oGMuSs8wH4R0bo/XeWsV0/QUrzYL4TWCembP/nSIWrEyhrKk vHo08wbvepAZRXMW9GxVqf2x+JJQB5hU5duWKjP23GKlY9n0EOk2AAjs8X2KA/bvlx25 5/8c37cXlKfNyxrLGp7DsnvieINOWA1HlLc+JZnbwfuIpPh09EYe+pJK1tEAXAIH/4xC LmgjnIeUDOUR5pnaFJmW8tyRTQY6j1OHqtTXE6sb2cnjvemMY+194xDRzXUK/dkecU56 +E2kN5ul1Qvlx8r/h6+ehTzvQYDp6CNA3ae7+KKKTJGDHUy1HxCNzatN1WZEPGmgebTi NHdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789031713; x=1789636513; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Hk6ntHXUeJYTRX8HAaEa/PKmgwGWJjC3R3z8/hR5mi8=; b=GgoPdomsacTRlo1oNuUKWffccftqMEyGUtryvsit9pTB0Qa6VDippFdKTtIiLjsW/3 Uiu94ImSIaDB7X0XDdo3chsvzfmGe914iUyaqiXnooxGwUaK8jgyFVXyKwn+KyxxkLXq yRa9GScHsDyv4rXwZUVKIAghB4Fj79YnN6d3i/+bikJw6YHIold7eQG2y2xRmoS6LndY vxqnKO5c+pQPW6YWlm0hMXz6V9FE5hvMaQk8lt1vlmSNJCXrK+qzsPnfSyFSveDn91RB SJor9fjpYvPXv2W7y8yWghJpD9B+nTIZD4QDoLS02c6NTB3HG1oPVqiBXWDopb+1f3hj 86mg== X-Gm-Message-State: AFuF++kdN80hDB7KvkPXnFWS2FYs61lLLsNW/riJeRMJThNCYI1VB85a h21/ZtvYbvlc7iJSC2pk+xv+DvriiPwh7JqLxKoF9oFcAnOb9oOX87wenKGT+T0j X-Gm-Gg: AYBFou0YXPLPJ8XyKaeGjx3pnfFzQkxJwmL4cbVMSsDtqyPhGnYyaySUcsPRobLeNiK cmsf1myLSRYprpIRu5QldaCJ8gOhdDlFcRUqXIJzR5nNY8MGZtZwTVMQLMh/iIa7raUt4dhG60E QuovSpHA45PWUGSBXBp55io3JJ3diCNePzqS69gOlcm2oileh31CslKF5ceRkOVkLgdQQdDaimp EIgBHETTccXHSCOuZP/x8tjZ9K3LtHVKKzuZh9e9IGItKw4+av/ZJ0+8ctkm4mQEQLf+HD4fw7S nbLBgcDfu3P2MQI3nKY+6VnY7NdLscdrKwn6lhc0r+mnshrMjgcZS9HUzIwOmAeetpcUlfpfWOe LwUpUI7MKTd+8kCVpgxiaT0gMcPBnTcRz+v/7HbTYw1YdbZvJKImwJDrNvPqLA/13SzO0C7qcvu oZlwURsyn201XWj98YWV6JY1ehkmyqRTOllaOVCc5oUAkI3VGstRHoolNm8gn2qDrA396g35EWg VKAukE= X-Received: by 2002:a05:600c:310f:b0:499:b65d:124f with SMTP id 5b1f17b1804b1-49d258d85b5mr55939695e9.11.1789031712832; Thu, 10 Sep 2026 02:15:12 -0700 (PDT) From: Andrew Mbugua To: xen-devel@lists.xenproject.org Cc: Andrew Mbugua Subject: [PATCH v2] stubdom: Fix GCC 14 -Wmemset-elt-size compiler warnings in PolarSSL Date: Thu, 10 Sep 2026 12:14:14 +0300 Message-ID: <20260910091414.22966-1-andrewprecious388@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <37902bbd-1ab9-4b49-8f94-4b788b3620d9@suse.com> References: <37902bbd-1ab9-4b49-8f94-4b788b3620d9@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789031713-A9CC79EA-C264F4A6/0/0 X-purgate-type: clean X-purgate-size: 2067 A followup to the email thread with the previously suggested changes. I have: 1. Added the patch reference to the Makefile 2. Removed the new subdirectory I created. 3. Formatted patch message to be <75 characters per line When compiling Xen with GCC 14, I get a compiler warning originating from the /polarssl-x86_64/library about a memset element size mismatch: ssl_tls.c: In function ‘ssl_session_reset’: ssl_tls.c:1778:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] 1778 | memset( ssl->ctx_enc, 0, 128 ); | ^~~~~~ ssl_tls.c:1779:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] 1779 | memset( ssl->ctx_dec, 0, 128 ); | ^~~~~~ This patch introduces a build-time patch to PolarSSL that replaces the hardcoded 128 byte length with sizeof() allowing clean compilation without warnings. Signed-off-by: Andrew Mbugua --- stubdom/v2-0001-PATCH-stubdom-Fix-GCC-14-Wmemset-elt-size-compile.patch | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 stubdom/v2-0001-PATCH-stubdom-Fix-GCC-14-Wmemset-elt-size-compile.patch diff --git a/stubdom/v2-0001-PATCH-stubdom-Fix-GCC-14-Wmemset-elt-size-compile.patch b/stubdom/v2-0001-PATCH-stubdom-Fix-GCC-14-Wmemset-elt-size-compile.patch new file mode 100644 index 0000000000..3528f2817a --- /dev/null +++ b/stubdom/v2-0001-PATCH-stubdom-Fix-GCC-14-Wmemset-elt-size-compile.patch @@ -0,0 +1,13 @@ +--- a/library/ssl_tls.c ++++ b/library/ssl_tls.c +@@ -1775,8 +1775,8 @@ + memset( ssl->iv_dec, 0, 16 ); + memset( ssl->mac_enc, 0, 32 ); + memset( ssl->mac_dec, 0, 32 ); +- memset( ssl->ctx_enc, 0, 128 ); +- memset( ssl->ctx_dec, 0, 128 ); ++ memset( ssl->ctx_enc, 0, sizeof( ssl->ctx_enc ) ); ++ memset( ssl->ctx_dec, 0, sizeof( ssl->ctx_dec ) ); + + md5_starts( &ssl->fin_md5 ); + sha1_starts( &ssl->fin_sha1 ); -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:30:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:30:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414212.1643982 (Exim 4.92) (envelope-from ) id 1x4b6e-00029S-88; Thu, 10 Sep 2026 09:30:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414212.1643982; Thu, 10 Sep 2026 09:30:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4b6e-00029L-4z; Thu, 10 Sep 2026 09:30:08 +0000 Received: by outflank-mailman (input) for mailman id 1414212; Thu, 10 Sep 2026 09:30:07 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4b6d-00029E-31 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:30:07 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4b6b-0082gS-22; Thu, 10 Sep 2026 09:30:05 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4b6c-00CnTW-0E; Thu, 10 Sep 2026 09:30:05 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=DRQLwICropSsTA3p1eK/BextFSV52IaHcHlhfCScjzg=; b=cC8S1rovSv2n0SubDekEbrOn52 x1eBiwsBSazgHOI8aZixnH70M++ArAw5cIEIrTS7OArdSFJRkCXodAYUaZKUkRj0i3ag7tMuhVuZK muUcbTngZkYvd5A+ix5QqcxrXzAq2APHwXVSQr2m240+N/MSymvpiNj71MGU9SB4nvw8=; Date: Thu, 10 Sep 2026 11:30:03 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Sep 10, 2026 at 10:38:34AM +0200, Jan Beulich wrote: > On 10.09.2026 09:49, Roger Pau Monné wrote: > > On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote: > >> The use of unreachable(), when unreachability is visible to Eclair (and > >> compilers), is deemed a violation. Drop the redundant statement. > > > > Urg, isn't that something that should be fixed in Eclair then? > > Otherwise all the unreachable() calls in our codebase are likely to be > > found by Eclair sooner or later, and will need to be removed. > > No, aiui most are covered by deviations. In particular ones in BUG() and > ASSERT_UNREACHABLE(). Shouldn't this be a deviation then also? Maybe it would be helpful if the commit message states why this is handled differently from other unreachable() instances then. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:31:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:31:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414219.1643991 (Exim 4.92) (envelope-from ) id 1x4b7W-0002b5-FP; Thu, 10 Sep 2026 09:31:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414219.1643991; Thu, 10 Sep 2026 09:31:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4b7W-0002ay-Cs; Thu, 10 Sep 2026 09:31:02 +0000 Received: by outflank-mailman (input) for mailman id 1414219; Thu, 10 Sep 2026 09:31:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4b7U-0002ao-WF for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:31:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4b7U-0004Dg-9u for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:31:00 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa278d0-8faa-0a2a0a5109dd-0a2a45039f7c-20 for ; Thu, 10 Sep 2026 11:31:00 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa278d2-fae8-0a2a45030019-b9ff1c228fe3-3 for ; Thu, 10 Sep 2026 11:30:58 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aa7f23b000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:30:57 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 95CF681DCD; Thu, 10 Sep 2026 11:30:56 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=/qNmr2snEUxJ6RXSRdNUkSONPkCnA0TqdMW4rVChrNE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=auwo4TIqbTpOO5c6OsdUfz5lZAv8tX/Edh/qopMvanMvs47jIss6L+pMRLKOfvzPna2eZ/Fvw 5Xqbt2ckVmwpGp2wERGTyTbWJIHh0Hj3TA57hAG2iAOsmZoTamjJcEvbrQ0QsaPBYKydGMnkCnC 24SQj6t11sL5CvtjgSLld+L6gH9gq4IZX0mUypDRSLUc/Um0baRqves92wDV9pBxq2dlo0PNhuA BOZ9RlVIuI2aKDl3j/dRIBsGmam439p5PhQocxTleHCPRGf+sj5C1HAqRE1FpIHfVbNxRDd8s3t YsMZDxFNUEh2NPoyezU5FykTukmxCvEvtTJ7ZxjVpmqQ== X-Zone-Loop: 9ad6b4758e3e310fc4b4d177861fa70e8090c18fb7ac x-campaign-type: default x-transaction-id: 7ae9e231-e991-4d2e-a636-202933472252 x-swg-uid: 01-8e1b69f9-48ce-44d4-ae07-6e283c2a465e X-Mailer: Sweego Message-ID: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> x-swg-bid: 1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Zheng Zhang Subject: [PATCH v2 0/6] xen/riscv: fix boot on missing extensions and MMU setup bugs Date: Thu, 10 Sep 2026 11:30:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Change-ID: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=2757; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ycGBvEciYSSaDSWIu6A69qet0SFqv1AzaVH2EK0KtfU=; b=XYHDAkRM6LacylJB8xuGFYrJZrs717a8ZqhxaHtUMY3acVqpjiIn2YYnx+WJnoUTwaCDatkmG qE1uItQRnjfBrlBSeEYdiIF1P4lWqgJpWiWEtK5dLr3h7P8ttk+eTDz X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032656820 X-purgate-ID: tlsNG-33051d/1789032660-766FB4E9-3150732A/10/73395122804 X-purgate-type: spam X-purgate-size: 2759 This series introduces bugs fixes that were found while bringing up CI support for the HiFive Premier P550 board with a basic smoke test. The board-support series itself will follow separately as it depends on PLIC/vPLIC and dom0less support that have not been upstreamed yet. This series carries only the independent fixes found along the way, none of them need the board-support series to apply. This series: 1: Fix Svade/Svadu A/D bit handling 2: Set A/D bits in Xen's own page-table mappings under Svade 3: Make Svpbmt no longer a required extension 4: Make Zihintpause no longer a required extension 5: Flush speculatively cached Bare-mode TLB entries in turn_on_mmu() 6: Fix level_map_mask truncation on load_start CI pipeline: https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2836284276 --- Changes since v1: - address ML comments - rename some patchs - add new patch-fix: 242dd1f890e4 ("xen/riscv: fix level_map_mask truncation on load_start") discovered when working on Spacemit K3 support To: Zheng Zhang To: Alistair Francis To: Connor Davis To: Oleksii Kurochko To: Andrew Cooper To: Anthony PERARD To: Michal Orzel To: Jan Beulich To: Julien Grall To: Roger Pau Monné To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org --- Baptiste Le Duc (6): xen/riscv: fix Svade/Svadu A/D bit handling xen/riscv: set A/D bits in Xen's page-table mappings under Svade xen/riscv: make Svpbmt no longer a required extension xen/riscv: make Zihintpause no longer a required extension xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu() xen/riscv: fix level_map_mask truncation on load_start xen/arch/riscv/cpufeature.c | 61 +++++++++++++++++++++++++++++++-- xen/arch/riscv/domain.c | 10 ++++-- xen/arch/riscv/include/asm/cpufeature.h | 1 + xen/arch/riscv/include/asm/page.h | 37 ++++++++++++++------ xen/arch/riscv/include/asm/sbi.h | 8 +++++ xen/arch/riscv/mm.c | 11 +++--- xen/arch/riscv/p2m.c | 49 ++++++++++---------------- xen/arch/riscv/riscv64/head.S | 1 + 8 files changed, 127 insertions(+), 51 deletions(-) --- base-commit: f7eab298bb9f2634e555aea1db70efcbbfd4d316 change-id: 20260902-riscv-fix-boot-missing-ext-a79c23bad694 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:35:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:35:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414227.1644001 (Exim 4.92) (envelope-from ) id 1x4bBN-0003A0-UW; Thu, 10 Sep 2026 09:35:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414227.1644001; Thu, 10 Sep 2026 09:35:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBN-00039t-QO; Thu, 10 Sep 2026 09:35:01 +0000 Received: by outflank-mailman (input) for mailman id 1414227; Thu, 10 Sep 2026 09:35:00 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBM-00039m-30 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBL-007nqx-Fy for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:34:59 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279bd-8faa-0a2a0a5109dd-0a2a4502cc62-22 for ; Thu, 10 Sep 2026 11:34:59 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279c3-6ca4-0a2a45020019-b9ff1c23b5c1-3 for ; Thu, 10 Sep 2026 11:34:59 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aab9d76000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:57 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 3373E81DDF; Thu, 10 Sep 2026 11:34:57 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=gYWVowcg1/XIljyI4nY8iK28MBBdYrH7NMXkWVSNpfM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=sTiR6FgdvGnCzho+hwFBWWNTxCNMZavPQLPoiXrUorI83SUmBEeVjdpzI4tFBPnkPPkDFtRbw qi2/biOF69sDiFNgiEf0sDL6idkS1NbnyYn8LpgOJ075O2IR5la1LUS2vCJuHQTg9msnWdhF6qO 1yYUL1cWgCaVUjAAQwIiAw89EHD2gaIxSMYadeFFcR+Shw/OSoHnBgIQqJ21l53XOXho0drjFMt K2vI0qbbxwVLcci8X0q4fCu5HyuaMNrUhgxNAWI/UT+fECgnURQ3dO06kwClPzeferFUrNXzsLy RpAO43oae5+DlT7x8LPOhzipeQ2lesjh2sQK6NBGRvUA== X-Zone-Loop: 500b563be99b06f20e9ebef69834de1db2119f884266 x-campaign-type: default x-transaction-id: 60bd194f-56ef-4de6-9b44-6482c5c4eda9 x-swg-uid: 01-0624438b-142b-4702-b68e-5c575101639d X-Mailer: Sweego Message-ID: <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> x-swg-bid: 1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling Date: Thu, 10 Sep 2026 11:34:49 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=10641; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=O+TAA7wrcm6AfiwPOIR/C5+ZEMAyiEayDxvF+dXKij4=; b=OBLZp0zMgkk12Yg/gEuepBjWKf+LHBW3gB7JCv2AO4uChiyS8U4eqLm1A0SZ5UmNBakPr67/z 2q0QUiAHQyGCGr1JLUCw23KK7UnDeig4i1JM2tDy7D2zTG5TPWPxKN6 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032897403 X-purgate-ID: tlsNG-720697/1789032899-668B42AC-2613E51E/0/0 X-purgate-type: clean X-purgate-size: 10643 p2m_set_permission() only presets the PTE A/D bits when the Svade extension is present in the device tree. This causes an unhandled page fault when neither Svade nor Svadu is present (the platform's actual behaviour is then unknown), and when both are present in the device tree. Move the Svade/Svadu resolution out of p2m_set_permission() and into a new riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). For each of the four possible Svade/Svadu combinations (inspired by [1]), it decides whether software has to preset the A/D bits and, if so, sets RISCV_ISA_EXT_svade to record that decision: - neither present: assume Svade, since assuming Svade is harmless on real Svadu hardware, while assuming Svadu on real Svade hardware risks an unhandled page fault - only Svade present: assume Svade - only Svadu present: leave A/D management to hardware - both present: Svade wins until Xen supports the SBI FWFT call needed to enable hardware updating of A/D bits, so assume Svade and warn that dropping 'svade' from the DT is the only way to get Svadu. [1] https://lwn.net/Articles/980016/ Fixes: ff14053983b0 ("xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration") Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v1: - change commit title - expose RISCV_ISA_EXT_svadu so the two extensions can be told apart. - move the Svade/Svadu resolution to a new riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). - expose sbi_probe_extension() (was static) to probe for SBI FWFT. - stop presetting A/D bits unconditionally in p2m_set_permission(), do it only when Svade is present. --- xen/arch/riscv/cpufeature.c | 59 +++++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 1 + xen/arch/riscv/include/asm/sbi.h | 8 +++++ xen/arch/riscv/p2m.c | 47 ++++++++++---------------- 4 files changed, 86 insertions(+), 29 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 92235fdfd5..19454544a7 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -18,6 +18,7 @@ #include #include +#include #ifdef CONFIG_ACPI # error "cpufeature.c functions should be updated to support ACPI" @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) return false; } +/* + * Svade and Svadu extensions represent two schemes for managing the PTE A/D + * bits. When the PTE A/D bits need to be set, the Svade extension indicates + * that a page fault will be raised. In contrast, the Svadu extension supports + * hardware updating of the PTE A/D bits. + * + * There are 4 possible combinations of these extensions in the device tree. + * The default hardware behavior for each is: + * + * 1) Neither Svade nor Svadu present in DT => It is technically unknown + * whether the platform uses Svade or Svadu. Xen should be prepared to + * handle either hardware updating of the PTE A/D bits or page faults when + * they need updating. In that case, Xen assumes Svade because it's + * harmless if the platform is actually Svadu, while assuming Svadu on real + * Svade hardware risks an unhandled page fault. + * + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. + * + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. + * + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off + * at boot time by setting A/D bits. To use Svadu, the supervisor must + * explicitly enable it using the SBI FWFT extension. + * + * The Svade extension is mandatory and the Svadu extension is optional in the + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose + * option 3. Platforms aware of the profile can choose option 4, and Xen won't + * get the benefit of Svadu until the SBI FWFT extension is available. + * + * In other words, hardware manages the A/D bits on its own only in case 3, in + * all the other cases software has to preset them. Instead of open coding this + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. + */ +static void __init riscv_resolve_ad_scheme(void) +{ + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); + + /* Case 3: leave the A/D bits management to hardware. */ + if ( svadu && !svade ) + return; + + /* Case 4 */ + if ( svadu && svade ){ + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" + "RISC-V: Defaulting to software A/D updates (Svade).\n" + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); + } + } + + /* Cases 1, 2: Xen assume Svade to be enabled */ + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); +} + bool riscv_isa_extension_available(const unsigned long *isa_bitmap, enum riscv_isa_ext_id id) { @@ -513,6 +570,8 @@ void __init riscv_fill_hwcap(void) __set_bit(RISCV_ISA_EXT_sstc, riscv_isa); } + riscv_resolve_ad_scheme(); + for ( i = 0; i < req_extns_amount; i++ ) { const struct riscv_isa_ext_data ext = required_extensions[i]; diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h index 0c48d57a03..74200ce7c9 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_sstc, RISCV_ISA_EXT_svade, RISCV_ISA_EXT_svpbmt, + RISCV_ISA_EXT_svadu, RISCV_ISA_EXT_MAX }; diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h index 1952868e96..4f13e8c7a0 100644 --- a/xen/arch/riscv/include/asm/sbi.h +++ b/xen/arch/riscv/include/asm/sbi.h @@ -30,6 +30,7 @@ #define SBI_EXT_BASE 0x10 #define SBI_EXT_RFENCE 0x52464E43 #define SBI_EXT_TIME 0x54494D45 +#define SBI_EXT_FWFT 0x46574654 /* SBI function IDs for BASE extension */ #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 @@ -138,6 +139,13 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, size_t size, unsigned long vmid); +/** + * Check if an SBI extension ID is supported or not. + * @extid: The extension ID to be probed. + * + * @return: 1 or an extension specific nonzero value if yes, 0 otherwise. + */ +int sbi_probe_extension(long extid); /* * Initialize SBI library * diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 1cea86512c..22ad4a2aee 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -586,42 +586,31 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_cache) static void p2m_set_permission(pte_t *e, p2m_type_t t) { + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); + e->pte &= ~PTE_ACCESS_MASK; e->pte |= PTE_USER; /* - * Two schemes to manage the A and D bits are defined: - * • The Svade extension: when a virtual page is accessed and the A bit - * is clear, or is written and the D bit is clear, a page-fault - * exception is raised. - * • When the Svade extension is not implemented, the following scheme - * applies. - * When a virtual page is accessed and the A bit is clear, the PTE is - * updated to set the A bit. When the virtual page is written and the - * D bit is clear, the PTE is updated to set the D bit. When G-stage - * address translation is in use and is not Bare, the G-stage virtual - * pages may be accessed or written by implicit accesses to VS-level - * memory management data structures, such as page tables. - * Thereby to avoid a page-fault in case of Svade is available, it is - * necessary to set A and D bits. - * - * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI - * delegates page faults to a lower privilege mode and so OpenSBI - * isn't expect to handle page-faults occured in lower modes. - * By setting the A/D bits here, page faults that would otherwise - * be generated due to unset A/D bits will not occur in Xen. - * - * Currently, Xen on RISC-V does not make use of the information - * that could be obtained from handling such page faults, which - * could otherwise be useful for several use cases such as demand - * paging, cache-flushing optimizations, memory access tracking,etc. + * riscv_fill_hwcap() sets either RISCV_ISA_EXT_svade or + * RISCV_ISA_EXT_svadu (mutually exclusive) depending on the Svade/Svadu + * device tree combination (see riscv_resolve_ad_scheme()): + * - RISCV_ISA_EXT_svade means that software is responsible for the A/D + * bits. + * - RISCV_ISA_EXT_svadu means the hardware is responsible for the A/D + * bits. * - * To support the more general case and the optimizations mentioned - * above, it would be better to stop setting the A/D bits here and - * instead handle page faults that occur due to unset A/D bits. + * Currently, when RISCV_ISA_EXT_svade is set, Xen doesn't track A/D + * bits, so it does not make use of the information that could be + * obtained from handling the resulting page faults, which could + * otherwise be useful for several use cases such as demand paging, + * cache-flushing optimizations, memory access tracking, etc. To avoid + * such a page fault, Xen presets the A and D bits instead. */ - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) + ASSERT(svade != svadu); /* exactly one of svade/svadu must be set by riscv_fill_hwcap() */ + if ( svade ) e->pte |= PTE_ACCESSED | PTE_DIRTY; switch ( t ) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:35:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:35:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414228.1644009 (Exim 4.92) (envelope-from ) id 1x4bBQ-0003Ml-4M; Thu, 10 Sep 2026 09:35:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414228.1644009; Thu, 10 Sep 2026 09:35:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBQ-0003Me-11; Thu, 10 Sep 2026 09:35:04 +0000 Received: by outflank-mailman (input) for mailman id 1414228; Thu, 10 Sep 2026 09:35:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBO-0003Kb-Rc for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBO-007nqx-8P for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:02 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279bd-8faa-0a2a0a5109dd-0a2a4502cc62-34 for ; Thu, 10 Sep 2026 11:35:02 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279c3-6ca4-0a2a45020019-b9ff1c23b5c1-4 for ; Thu, 10 Sep 2026 11:35:02 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aab9ea7000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:58 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 8FCB681E02; Thu, 10 Sep 2026 11:34:57 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=OQMa161a+Wta8D11iB/ndQm1se8KfDbFH6WIHdvaHGI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=cWCdmEszRBcC73GGCImq8qDcfqxOmDvHgI6m4jSxSdHq2O9T8j15VYmlPKQZ2/NsFkkvCx+a6 d0IyGfjCK4F+Qe7A1/iiAvjogboos/uESXFDF1K+5x2kocxbetN71mdAVctcnypbOMp4xIGpeQL HeraKIcSHVw93MyJW9FA/TO+2EEnmu0k/KPtdHHnGrWee8RXZWRIc3Gs1/7b+iqD55TmkujTN/V YuIa70Qw4+vnF5wkqlyekiClYKYNPwhBlNsOyJ6AM2BXDY0bTw8PLVFBgsPSPW41uEhpUl2SDY8 /TKpzcVi9oKncoOr045sd0y2cChLQYuJlbiGhGAyy7TQ== X-Zone-Loop: a778dacaedad8c10749e69f932d7b5b69dfed1b74b21 x-campaign-type: default x-transaction-id: 4ea3cbea-497b-4bbe-8884-f42ffaf428a8 x-swg-uid: 01-05164e3a-3a95-4fc3-8b65-84eac62a50bc X-Mailer: Sweego Message-ID: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3@vates.tech> x-swg-bid: 1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 2/6] xen/riscv: set A/D bits in Xen's page-table mappings under Svade Date: Thu, 10 Sep 2026 11:34:50 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=5833; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=oru9y8klMzu0KQzmHiXjBGBZGoTU/bzItz+YJ4+V2kI=; b=aqJBmtx9lgcJ1XkvpeN6/IaSMIUP8hMfW5EQpERjH0bEvJa7oau9woD2G/ciY+RXwX1d+Hn1/ jYG7W1NW7bHDlMaBvBSpjurL2Svy54ID5y9f75bQHcwIDOjGAjUshUJ X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032897774 X-purgate-ID: tlsNG-720697/1789032902-678BC2AC-0AED1F10/0/0 X-purgate-type: clean X-purgate-size: 5835 The previous patch set A/D bits in case of the Svade extension for G-stage mappings. Xen's own S-stage mappings need the same fix as both setup_initial_mapping() (the boot page tables) and arch_pmap_map() (the fixmap) build leaf PTEs directly instead of going through pt_update_entry(), which is what adds A/D bits. So with Svade, both would fault on first access. Add PTE_ACCESSED to all PAGE_HYPERVISOR_* and also PTE_DIRTY to PAGE_HYPERVISOR_RW as it needs to be set during a write to avoid a fault. This fixes arch_pmap_map() for free, since it already builds its PTE from PAGE_HYPERVISOR_RW. Switch setup_initial_mapping() to use these macros for its default, text and rodata permissions, and for the temporary root entry built by check_pgtbl_mode_support(), instead of the equivalent raw bit lists. The latter drops PTE_WRITABLE, going from RWX to RX, but this is harmless, as that entry only has to make the current instruction stream fetchable between the two CSR_SATP writes used to probe SATP mode support, and nothing writes through it. Drop the now-redundant PTE_LEAF_DEFAULT, since converting the last open-coded site above leaves it with no user outside page.h itself. A PTE is a table entry iff PTE_VALID is set and R/W/X are all clear, so update pte_is_table() and pte_is_mapping() accordingly. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v1: - change commit title - mention in patch message that arch_pmap_map() is fixed too, via the PAGE_HYPERVISOR_RW change, not just setup_initial_mapping(). - convert check_pgtbl_mode_support()'s temporary root entry to PAGE_HYPERVISOR_RX, as it's harmless. - drop PTE_LEAF_DEFAULT entirely instead of keeping it, now that no site open-codes it anymore. - drop the pte_is_table() comment line that referenced PAGE_HYPERVISOR_RW, now stale. --- xen/arch/riscv/include/asm/page.h | 15 +++++++-------- xen/arch/riscv/mm.c | 9 ++++----- 2 files changed, 11 insertions(+), 13 deletions(-) diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index b465a90325..1977634efc 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -46,12 +46,11 @@ #define PTE_PBMT_NOCACHE BIT(61, UL) #define PTE_PBMT_IO BIT(62, UL) -#define PTE_LEAF_DEFAULT (PTE_VALID | PTE_READABLE | PTE_WRITABLE) #define PTE_TABLE (PTE_VALID) -#define PAGE_HYPERVISOR_RO (PTE_VALID | PTE_READABLE) -#define PAGE_HYPERVISOR_RW (PTE_VALID | PTE_READABLE | PTE_WRITABLE) -#define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE) +#define PAGE_HYPERVISOR_RO (PTE_VALID | PTE_READABLE | PTE_ACCESSED) +#define PAGE_HYPERVISOR_RW (PTE_VALID | PTE_READABLE | PTE_WRITABLE | PTE_ACCESSED | PTE_DIRTY) +#define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE | PTE_ACCESSED) #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW /* @@ -174,10 +173,9 @@ static inline bool pte_is_table(pte_t p) * According to the spec if V=1 and W=1 then R also needs to be 1 as * R = 0 is reserved for future use ( look at the Table 4.5 ) so check * in ASSERT that if (V==1 && W==1) then R isn't 0. - * - * PAGE_HYPERVISOR_RW contains PTE_VALID too. */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); + ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) != + (PTE_VALID | PTE_WRITABLE)); return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == PTE_VALID); } @@ -185,7 +183,8 @@ static inline bool pte_is_table(pte_t p) static inline bool pte_is_mapping(pte_t p) { /* See pte_is_table() */ - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); + ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) != + (PTE_VALID | PTE_WRITABLE)); return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); } diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c index 4d3b8c2204..53bebbcabf 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -140,7 +140,7 @@ static void __init setup_initial_mapping(struct mmu_desc *mmu_desc, case 1: /* Level 0 */ { unsigned long paddr = (page_addr - map_start) + pa_start; - unsigned int permissions = PTE_LEAF_DEFAULT; + unsigned int permissions = PAGE_HYPERVISOR_RW; unsigned long addr = is_identity_mapping ? page_addr : virt_to_maddr(page_addr); pte_t pte_to_be_written; @@ -149,11 +149,10 @@ static void __init setup_initial_mapping(struct mmu_desc *mmu_desc, if ( is_kernel_text(addr) || is_kernel_inittext(addr) ) - permissions = - PTE_EXECUTABLE | PTE_READABLE | PTE_VALID; + permissions = PAGE_HYPERVISOR_RX; if ( is_kernel_rodata(addr) ) - permissions = PTE_READABLE | PTE_VALID; + permissions = PAGE_HYPERVISOR_RO; pte_to_be_written = paddr_to_pte(paddr, permissions); @@ -198,7 +197,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_desc *mmu_desc, index = pt_index(page_table_level, aligned_load_start); stage1_pgtbl_root[index] = paddr_to_pte(aligned_load_start, - PTE_LEAF_DEFAULT | PTE_EXECUTABLE); + PAGE_HYPERVISOR_RX); sfence_vma(); csr_write(CSR_SATP, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:35:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:35:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414229.1644018 (Exim 4.92) (envelope-from ) id 1x4bBW-0003do-FJ; Thu, 10 Sep 2026 09:35:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414229.1644018; Thu, 10 Sep 2026 09:35:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBW-0003dh-C6; Thu, 10 Sep 2026 09:35:10 +0000 Received: by outflank-mailman (input) for mailman id 1414229; Thu, 10 Sep 2026 09:35:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBU-0003cL-TQ for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBU-00G7oY-A2 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:08 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279bd-8faa-0a2a0a5109dd-0a2a4502cc62-48 for ; Thu, 10 Sep 2026 11:35:08 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279cb-6ca4-0a2a45020019-b9ff1c22b70b-3 for ; Thu, 10 Sep 2026 11:35:08 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aab9fe1000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:58 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id E19E581E0F; Thu, 10 Sep 2026 11:34:57 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=y+IsxIUnoTJ7eAPggcrJIaoVT6eUFG1bxyCAiLEuHMg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=mVEoV+cdWmYpo0yN2PoFoFm6su5rVz9xmpjr2yWvBwTfeGCwU96zUfmc9E0dv31V+3n0L6SqX +PWI9+HXQzGFqDsxOYcO4Z820DzupzKK5U5dCg8Fj5W8E+ZSYamWl759jj7I3JAWrBsEqChpI1t 1s9GuejpFOvyLtUH7lA4JYTbw4IMYhVc2jnCWOuC3xuEphcxH1HTkT8m/cEgAxrNnF0NNsk8FVo MXaho4VsObjRpr2I+H0IMjeVx6Bs1XhFSW/5qYizoZa5mJqK5L/nVP6glqHXIFrgQ22HwTgAyhy Jz8lJAu568BFdwK9rwxaD7KZY0ufZ8U0a7HQ1HxIMFrQ== X-Zone-Loop: fed367620279910bd4afbcd0f0efd652e782570c53d3 x-campaign-type: default x-transaction-id: df48f6a2-9f66-4e4c-a685-0a9b35d69214 x-swg-uid: 01-a095095e-5f1b-4da2-8e07-b164421b7cdd X-Mailer: Sweego Message-ID: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3@vates.tech> x-swg-bid: 1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 3/6] xen/riscv: make Svpbmt no longer a required extension Date: Thu, 10 Sep 2026 11:34:51 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=6794; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=jrynfzaXIgAgy7hsDbMYdbj40qrjRkErilQHWPhMvw4=; b=jL58PSCbRDoyd13ZmmFspDh5pZCqXjOmrh0K13a6ZPVkYgmY5IWP9x+fS03FnnxWULDTx4l7h Y8s8jl0vBxBBVXMlCqdTfn2fFLY9fQANeduvMqcWWxF/HvFFkatZITX X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032898104 X-purgate-ID: tlsNG-720697/1789032908-F2EB32AC-725EF78D/0/0 X-purgate-type: clean X-purgate-size: 6796 Without the Svpbmt extension, memory attributes (such as cacheability and ordering) are strictly tied to physical address ranges and enforced by the hardware's Physical Memory Attributes (PMA) checker. In this configuration, supervisor software relies on the platform's memory map: - peripheral device registers (MMIO) are physically mapped into hardware-defined I/O regions (which are implicitly non-cacheable and strongly-ordered) - regular RAM is mapped as cacheable main memory. S-mode paging can safely map these physical ranges without specifying page-based memory types in the PTEs, as the hardware MMU and PMA pipeline will correctly bypass caches for MMIO accesses and use caches for RAM accesses, based on the target physical address. Furthermore, on platforms that either feature fully hardware-coherent DMA or don't expose non-coherent DMA agents to the OS, page-level programmatic cache control via Svpbmt is not required, making it safe to boot and run when Svpbmt is absent. Drop Svpbmt from required_extensions. Introduce svpbmt_enabled, a __ro_after_init flag computed once in init_csr_masks() from ISA availability and the henvcfg.PBMTE bit. Xen cannot read menvcfg.PBMTE directly, since menvcfg is M-mode-only and unreadable from HS-mode, but the spec guarantees henvcfg.PBMTE reads as zero whenever menvcfg.PBMTE is zero, so checking henvcfg.PBMTE alone is sufficient. Use svpbmt_enabled in pte_pbmt_nocache()/pte_pbmt_io(), two new inline helpers that mask the PBMT encoding down to 0 when Svpbmt is unavailable. Also switch vcpu_csr_init() branch to determine if Svpbmt was enabled to svpbmt_enabled as it does the same logic. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v1: - Replace the pte_pbmt() macro, which re-checked riscv_isa_extension_available() on every call, with a svpbmt_enabled flag cached once in init_csr_masks(). - Add pte_pbmt_nocache()/pte_pbmt_io() inline helpers instead, used by PAGE_HYPERVISOR_NOCACHE/WC and p2m_pte_from_mfn(). - Switch vcpu_csr_init() to the same cached svpbmt_enabled flag instead of re-deriving Svpbmt availability itself. --- xen/arch/riscv/cpufeature.c | 1 - xen/arch/riscv/domain.c | 10 ++++++++-- xen/arch/riscv/include/asm/page.h | 22 +++++++++++++++++++--- xen/arch/riscv/p2m.c | 2 +- 4 files changed, 28 insertions(+), 7 deletions(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 19454544a7..986a6dec78 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -158,7 +158,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = { RISCV_ISA_EXT_DATA(zifencei), RISCV_ISA_EXT_DATA(zihintpause), RISCV_ISA_EXT_DATA(zbb), - RISCV_ISA_EXT_DATA(svpbmt), }; static bool __init is_lowercase_extension_name(const char *str) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 2819ff4e7c..f6f20824e3 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -47,6 +47,8 @@ static struct csr_masks __ro_after_init csr_masks; #define HENVCFG_VALID_MASK 0xe0000003000000ffUL #define HSTATEEN0_VALID_MASK 0xde00000000000007UL +bool __ro_after_init svpbmt_enabled; + void __init init_csr_masks(void) { /* @@ -79,6 +81,10 @@ void __init init_csr_masks(void) INIT_RO_ONE_MASK(HSTATEEN0, hstateen0); } + svpbmt_enabled = (riscv_isa_extension_available(NULL, + RISCV_ISA_EXT_svpbmt)) && (ENVCFG_PBMTE & + csr_masks.henvcfg); + #undef INIT_CSR_MASK #undef INIT_RO_ONE_MASK } @@ -97,8 +103,8 @@ static void vcpu_csr_init(struct vcpu *v) */ v->arch.hcounteren = HCOUNTEREN_TM; - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) - v->arch.henvcfg = ENVCFG_PBMTE & csr_masks.henvcfg; + if ( svpbmt_enabled ) + v->arch.henvcfg = ENVCFG_PBMTE; if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) { diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h index 1977634efc..a7d087ff52 100644 --- a/xen/arch/riscv/include/asm/page.h +++ b/xen/arch/riscv/include/asm/page.h @@ -11,6 +11,7 @@ #include #include +#include #include #define VPN_MASK (PAGETABLE_ENTRIES - 1UL) @@ -42,7 +43,21 @@ * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory * 11 - Rsvd Reserved for future standard use + * + * These bits are only meaningful when Svpbmt is enabled. Otherwise they must + * stay 0 (PMA). */ +extern bool svpbmt_enabled; +static inline unsigned long pte_pbmt_nocache(void) +{ + return svpbmt_enabled ? BIT(61, UL) : 0; +} + +static inline unsigned long pte_pbmt_io(void) +{ + return svpbmt_enabled ? BIT(62, UL) : 0; +} + #define PTE_PBMT_NOCACHE BIT(61, UL) #define PTE_PBMT_IO BIT(62, UL) @@ -53,6 +68,7 @@ #define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE | PTE_ACCESSED) #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW + /* * PAGE_HYPERVISOR_NOCACHE is used for ioremap(). * @@ -60,8 +76,8 @@ * is that IO is non-idempotent and strongly ordered, which makes it a good * candidate for mapping IOMEM. */ -#define PAGE_HYPERVISOR_NOCACHE (PAGE_HYPERVISOR_RW | PTE_PBMT_IO) -#define PAGE_HYPERVISOR_WC (PAGE_HYPERVISOR_RW | PTE_PBMT_NOCACHE) +#define PAGE_HYPERVISOR_NOCACHE (PAGE_HYPERVISOR_RW | pte_pbmt_io()) +#define PAGE_HYPERVISOR_WC (PAGE_HYPERVISOR_RW | pte_pbmt_nocache()) /* * The PTE format does not contain the following bits within itself; @@ -82,7 +98,7 @@ enum pbmt_type { #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE) -#define PTE_PBMT_MASK (PTE_PBMT_NOCACHE | PTE_PBMT_IO) +#define PTE_PBMT_MASK (BIT(61, UL) | BIT(62, UL)) /* Calculate the offsets into the pagetables for a given VA */ #define pt_linear_offset(lvl, va) ((va) >> XEN_PT_LEVEL_SHIFT(lvl)) diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 22ad4a2aee..15cbc92b76 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -658,7 +658,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, switch ( t ) { case p2m_mmio_direct_io: - e.pte |= PTE_PBMT_IO; + e.pte |= pte_pbmt_io(); break; default: -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:35:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:35:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414230.1644027 (Exim 4.92) (envelope-from ) id 1x4bBZ-0003t8-Lk; Thu, 10 Sep 2026 09:35:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414230.1644027; Thu, 10 Sep 2026 09:35:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBZ-0003sx-It; Thu, 10 Sep 2026 09:35:13 +0000 Received: by outflank-mailman (input) for mailman id 1414230; Thu, 10 Sep 2026 09:35:13 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBZ-0003s3-1L for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBY-00G7oY-E1 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:12 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279cb-8faa-0a2a0a5109dd-0a2a45038d98-12 for ; Thu, 10 Sep 2026 11:35:12 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279d0-fae8-0a2a45030019-b9ff1c128343-3 for ; Thu, 10 Sep 2026 11:35:12 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aaba10f000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:58 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 3643E81DDF; Thu, 10 Sep 2026 11:34:58 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=zCcQNFh0g12JPMddG2Ca8xIh45osQOHtYcniGIWjeXE=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=oUaTveciXV3djdoStuZbp035Tod9lxjUIJV5N/uaryGMr0u0EWDkupTdEyCka8cUCDABlHVxR 6bYEFm0Jc4St/rXDddtPLscXRGQffHfCSFCYQKOhD9gc3Jzhow+r6MbLzu/s8v5hM/p5FRfVj4z cw8JgaWV82/jKblqraJN+HAOVcfwtAsgUDLE89Rjk0XuSEkZ1f5Rk0JnJODTBH3xjxCYP/SGaup 1J4lDAyvVewy8Ke1xHa1aVTGp+hqB4fLzbNgUND/jiy6rHzN0BtVNimYKxVQue2at15ZMf7pX2G 6dO457/neia5ihLW4XUPohpKH1tgDEhMuZ7XexIXa+dQ== X-Zone-Loop: d73f9eca2dae5907b35fb4a46eb39ffdffe62ccb1db2 x-campaign-type: default x-transaction-id: aaae94c8-24f6-4a94-b203-c19ea85e5935 x-swg-uid: 01-4d4eba5c-662a-4f18-af2f-bc0a62b6dd06 X-Mailer: Sweego Message-ID: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3@vates.tech> x-swg-bid: 1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 4/6] xen/riscv: make Zihintpause no longer a required extension Date: Thu, 10 Sep 2026 11:34:52 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=1274; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=oiDBllyOiotIYkSmw8xo419f4GoaBYdPMeKZi/GUUr4=; b=9p1WqN6dVAil6viKUhFyTXxVDTkqE3OiwnQioTXdPTkSSt3+/xfZwZKRD1xv7ZqSd45Vygn+V 7dEtBVmMbXRB2cYqvxOpB2IydCWjl2NTnkfBqDPOyrIW6qfWnoNn0j/ X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032898419 X-purgate-ID: tlsNG-33051d/1789032912-6FAC44E9-23DC6F3F/0/0 X-purgate-type: clean X-purgate-size: 1276 required_extensions[] panics at boot if Zihintpause is missing, but Xen never actually depends on it: cpu_relax() only emits the "pause" hint when the extension is implemented, otherwise it emits `0x0100000F`, a legally valid FENCE instruction (`FENCE W, 0`) rather than a native NOP. FENCE is guaranteed by the RISC-V base ISA, so it never raises an illegal instruction fault. With an empty successor set, it enforces no memory-ordering constraints and thus architecturally behaves as a NOP. Drop it from required_extensions so hardware without Zihintpause still boots. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v1: - rewrite commit message. --- xen/arch/riscv/cpufeature.c | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 986a6dec78..41bb1d2e80 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -156,7 +156,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = { RISCV_ISA_EXT_DATA(h), RISCV_ISA_EXT_DATA(zicsr), RISCV_ISA_EXT_DATA(zifencei), - RISCV_ISA_EXT_DATA(zihintpause), RISCV_ISA_EXT_DATA(zbb), }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:35:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:35:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414231.1644036 (Exim 4.92) (envelope-from ) id 1x4bBa-00047K-Tz; Thu, 10 Sep 2026 09:35:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414231.1644036; Thu, 10 Sep 2026 09:35:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBa-00047D-Qu; Thu, 10 Sep 2026 09:35:14 +0000 Received: by outflank-mailman (input) for mailman id 1414231; Thu, 10 Sep 2026 09:35:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBa-0003zD-7V for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBZ-004vNh-KY for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:13 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279cb-8faa-0a2a0a5109dd-0a2a45038d98-16 for ; Thu, 10 Sep 2026 11:35:13 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279d0-fae8-0a2a45030019-b9ff1c128343-4 for ; Thu, 10 Sep 2026 11:35:13 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aaba238000c4f3.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:59 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 83BF281E02; Thu, 10 Sep 2026 11:34:58 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=X/8cvkaIvfN4ORXWCv9sGu6JJ/CUQev1gsouw1gwXDY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=d/KG/E5Q+6iDzxx3DY1MpAJVlJrQCl6ys/adIosnB5+2AvYOPRsIbhtMZXkOOfkO5Kn2CB5VW Oe8xpHjg9wx//KDw1j7OLqyse56/wWEOdHC9TwkqxC3bDdH1hvEMXYx0LoMt0QvS9aQC0HmBQYQ 67hIk499KEw0temB4z9eGtgA7Ew42nBgiSJImPuReLdOv+0LR79hFR3zpE/qrZ6oYFtkPJhNoCG BRihAJ8MnT5mPzkGm/vCvL246ETTVglJkjIS2BKIjj+WIbx+o/txvIMf/yhUMOksuSoTm7lKw69 Wg3wca7dXQDcPT78GUmiToWe2JyxNX/C4qxPbZvZqfIA== X-Zone-Loop: 2eb777688ec98a335e6d365e5d176e2b551c73a96b11 x-campaign-type: default x-transaction-id: c0c46c87-1c28-4fce-8319-2dae7e389f67 x-swg-uid: 01-e7b1a648-d90d-48ff-b090-12dd9535cc96 X-Mailer: Sweego Message-ID: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba238000c4f3@vates.tech> x-swg-bid: 1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba238000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org Subject: [PATCH v2 5/6] xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu() Date: Thu, 10 Sep 2026 11:34:53 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=1716; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ke7mA7f4Dus9EMjPR0lmZSmqmnKbVtyeE23BIEFxZ5g=; b=t0w307/1fcBfuw+FuOWqjaQqVd0M1voh3gOg4v3raHsmDgjZUSoln+0nnnorn1BTUfZxYn43h D7kGFssZWsXAcI68rvdb2BeoyN35708/HPcXOHZjEy1BiNL4t7DUk3S X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032898729 X-purgate-ID: tlsNG-33051d/1789032913-6DED24E9-A9DFECA2/0/0 X-purgate-type: clean X-purgate-size: 1718 The existing SFENCE.VMA before the satp write only orders the page table stores from setup_initial_pagetables() against subsequent implicit reads. It does not prevent the CPU from speculatively caching translations after the fence retires. According to the RISC-V Privileged specification, implementations are permitted to speculatively cache Bare-mode identity mappings. Furthermore, selecting MODE=Bare (which happens during check_pgtbl_mode_support()) requires zeroing the remaining fields of satp, causing ASID=0 to be actively used in Bare mode. Consequently, the TLB can be polluted with Bare identity mappings tagged with ASID=0. Once satp is written to enable Sv39 translation, these cached identity mappings (tagged with ASID=0) can shadow the true Sv39 translations. This would lead to translation failures since turn_on_mmu() jumps to a non-identity-mapped linker address. Fix this by adding a post-satp-write SFENCE.VMA to invalidate any stale translations (including Bare-mode identity mappings under ASID=0) before jumping to the virtual address space. Assisted-by: Claude:claude-opus-5 Signed-off-by: Baptiste Le Duc --- Changes since v1: - rewrite commit message --- xen/arch/riscv/riscv64/head.S | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/head.S index 9c40512e61..7f6edc972f 100644 --- a/xen/arch/riscv/riscv64/head.S +++ b/xen/arch/riscv/riscv64/head.S @@ -98,6 +98,7 @@ FUNC(turn_on_mmu) srli t1, t1, PAGE_SHIFT or t1, t1, t0 csrw CSR_SATP, t1 + sfence.vma jr a0 END(turn_on_mmu) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:35:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:35:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414234.1644045 (Exim 4.92) (envelope-from ) id 1x4bBe-0004Px-3z; Thu, 10 Sep 2026 09:35:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414234.1644045; Thu, 10 Sep 2026 09:35:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBe-0004Pq-0y; Thu, 10 Sep 2026 09:35:18 +0000 Received: by outflank-mailman (input) for mailman id 1414234; Thu, 10 Sep 2026 09:35:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bBc-0004NG-Rt for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:35:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bBc-00FAkC-8e for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:35:16 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa279d1-2eae-0a2a0a5409dd-0a2a45058730-18 for ; Thu, 10 Sep 2026 11:35:16 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa279d3-4cb1-0a2a45050019-b9ff1c228a0d-3 for ; Thu, 10 Sep 2026 11:35:16 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08aaba3b8000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:34:59 +0000 Received: from leducb.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id CE6E281E0F; Thu, 10 Sep 2026 11:34:58 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=RCwI/CvQHkl5huemyVSULsoFXmRH9tLdrSmGjZIII34=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=CJ4qTI7zUwSds4AzJvDmNfX7YW154myeoHUFQe2iaBY7fW/xrNaZmBACelc4yNhvogY61uwIJ 8+l5baFBzH6O2K0Lcs6pR7EYUQNff6p/UTRv/JyBA+VVvyVnHKlbPPQ6yS/zwGqiyr9aNbpPLHw b+sM0RVkyEITuT+HyJEZj36z1fq3OKtHYWGIAx0W+nZeJAurP8tZkd5bVvZSE6VA9lJIhVr5Ied Wdws9cTUHRTbnTHDkLDysMLGeTRNhuTEkChqXKNE2JOBaLIUdqlVwOEMrAUpvP8GpC7y72kohNI 5H6Z2Q1uhn2YwpnGN8p4uZFVOA7Levr2tLHwv1L51JxA== X-Zone-Loop: 18e32e81ebd0207eee728b0687c3892bf11de8fca549 x-campaign-type: default x-transaction-id: d4089c17-9daa-4106-9d65-11b371a56fce x-swg-uid: 01-5b7aa16d-d323-4cb3-9789-779f9dbd7309 X-Mailer: Sweego Message-ID: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3@vates.tech> x-swg-bid: 1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc To: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Zheng Zhang Subject: [PATCH v2 6/6] xen/riscv: fix level_map_mask truncation on load_start Date: Thu, 10 Sep 2026 11:34:54 +0200 In-Reply-To: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=ed25519-sha256; t=1789032264; l=2391; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=EukpbiTX/G19DWwnVmYEkUdIYk1+eY5cBq7NCGMGSwY=; b=5NN6pbNqsPZBOVYzXv7RM+d3wJTOBMlrqhqWaPZw16orp1hq1gxMAcUo/9v3z16gOZQIG9Mxg 4OVRQ8S/7ZlC0jdgROlf36Q0X62pXqyCXUk+qUwtjSkZZEnt+9AVnJ4 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789032899042 X-purgate-ID: tlsNG-c201ff/1789032916-F6EB12A1-6F3DD476/0/0 X-purgate-type: clean X-purgate-size: 2393 check_pgtbl_mode_support() declares level_map_mask as bare `unsigned`, i.e. a 32-bit type while it derives from a paddr_t which is in both RV32/RV64 a 64-bit type. Storing that value into a 32-bit local silently drops any set bits above bit 31. The mask is then used as: aligned_load_start = load_start & level_map_mask; load_start is `unsigned long` (64-bit on riscv64) and if it requires more than 32 bits to represent, because load_start zero-extend to 64 bits, we would drop some load_start's bits during the AND. Widen level_map_mask to `unsigned long`, matching the width of the physical address. Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") Reported-by: Zheng Zhang Signed-off-by: Baptiste Le Duc --- Changes since v1: - new patch --- Question: I would think replacing unsigned long by paddr_t would be better in this case but for consistency with other variables in the function I just kept unsigned long. However, there are many variables in mm.c which are unsigned long while they are, in reality, physical addresses and could technically be paddr_t. Using paddr_t would also let us bypass the compiler's decision on what unsigned long extends to (u32 or u64, depending on the target), and therefore be more generic. I've seen similar code in Arm using this convention, and found nothing on the mailing list explaining the original choice of unsigned long over paddr_t. Replacing every such field would be a fairly large change, so I'm asking for your opinion on whether it's worth doing. --- xen/arch/riscv/mm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c index 53bebbcabf..e7f2491257 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -180,7 +180,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_desc *mmu_desc, bool is_mode_supported = false; unsigned int index; unsigned int page_table_level = (mmu_desc->num_levels - 1); - unsigned level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level); + unsigned long level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level); unsigned long aligned_load_start = load_start & level_map_mask; unsigned long aligned_page_size = XEN_PT_LEVEL_SIZE(page_table_level); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:46:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:46:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414276.1644054 (Exim 4.92) (envelope-from ) id 1x4bMX-0007bg-CR; Thu, 10 Sep 2026 09:46:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414276.1644054; Thu, 10 Sep 2026 09:46:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bMX-0007bZ-9t; Thu, 10 Sep 2026 09:46:33 +0000 Received: by outflank-mailman (input) for mailman id 1414276; Thu, 10 Sep 2026 09:46:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bMW-0007bT-37 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:46:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bMU-00AEjn-NE for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:46:30 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa27c75-2eae-0a2a0a5409dd-0a2a450bd5e2-8 for ; Thu, 10 Sep 2026 11:46:30 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa27c76-b7e8-0a2a450b0019-4a7de18c9bc4-3 for ; Thu, 10 Sep 2026 11:46:30 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso12661305e9.3 for ; Thu, 10 Sep 2026 02:46:30 -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 ffacd0b85a97d-485883c6ba4sm55085318f8f.25.2026.09.10.02.46.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 02:46:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789033590; x=1789638390; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from :cc:content-language:references:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=RWICW0eODkNw0pMXItBLQ++rYqChoX6o+XJRj72Bgp8=; b=EmPS0B6Hk97fx3pqtkn9letU3JlYOPNL4EJoy9RQdVCF8QsBp38uBPBWYmvHomRm3f Q985dGOC7x2NVNHhYdawJXjWSo3wUgSfQN6sVfkdHdeosEVtGCnU4j/T+8inldckbpkU SLQrO9sy2Hjnu2FUQ6WO8CE5w+zdC+0vWAN4Le1IR/FtQ0B+3AdZJrvnvayJS2TGV+sM ul/zDbWcacY/8ku9ZB4GOzzCN3cZJMquk9H81LTD3f+3CHPQgG9G0fzKebMcEohKNvLJ JBGvgIEVlk/c0Ho+jQKXBarkC5zNI+bpCz7pcjLwCe50Jf+6vA5hxSPO56hFPPtxdxo+ xocA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789033590; x=1789638390; h=content-transfer-encoding:content-type:in-reply-to:autocrypt:from :cc:content-language:references: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:content-type; bh=RWICW0eODkNw0pMXItBLQ++rYqChoX6o+XJRj72Bgp8=; b=jVokG5svhM3uqJqLtga7VtiIzAaMiJQU3Y0DTq2349ei9tPwVbMLXGzWUWUcHIKAGd PCQlDcciaCP1BkKFI+P6ILPqjwOkgnNoHxZexpegmmr89bCoYNjeXXrWV2gT1DihZRTl R3KqpXXkgOuHE2vs/f3aQSintUBRlF/o+f/6W9JLAXmjvbANklEdorgYeut7Gwv4aaNL g/r8aDlGhKBMuLetaCUNjOzJNROqkbe6u0gtKLFMHNQTRlIZcH4z+KicJ1ckxChaKdt6 i2huQXPYBuyQiGWDq69jRcdmzsMbo/sVytGfvKGOaQ0JRQrKGnERVMbLK0YbNPJ92h6T WOwg== X-Gm-Message-State: AFuF++k+RSqBICtQ10uymQYjv6jau+J/Ke4+FSMzynIqQ1/zLs/nZX0U G+qbJnqZSu407+B7qQ4VaORNuoPENbXFO4VaD325ouUMHqPcL/dlcj5QBEj0Jtu+7g== X-Gm-Gg: AYBFou2oI5x7g1n2AGRMDNLnl9Q0wabPBIzG0mBlXSeAYF14/7KohLDCEP7F4hl5S2V UphCQsXG41VyDCDQWSZVKsDVMBgLVl/f75Ml5w1PL/4C4+1BiRc3RPAx1UbcOudC3nHHqXvOAXX ITI9siIlfYahbHC2t0kCrmbTcMjLpsn1WIafyx9licv0s+HowDHuU0eSefGjECsyCxegk33FtOJ CDw+NLmqQ37CWyjLzuv08z9ZNUgFISKF6uZM9gySWL5rwH7vczoB6JOayy2jjvDsZ0SwznEtId3 BfWIRn2r2PwPjFxJOEUMWrs8ozHToPA7z+UXSsCL4LPABU5qeAsmD2VJScPwi4bpf78fZGhEsHS JFX3ju/wf184czmvPqyLDZ59CqyUbunNqwuFYlLyiYy2pHRkswlwFa2J7j2qm4nQmATU4gAnJ2X j2wvdiTJNlfTrv/ALKuZdM7jlvDszqaSKbAIH0wnOUY1EQQ9wgo+wc95a+sQFOzevqx2s9DwgYL UhlLNt3NohSsBkU9jY2oPQUR7+W1n/PfY1sbr5dG3IiU07v6JPfTtDMzlij69k= X-Received: by 2002:a05:6000:46c3:b0:486:e594:a6ce with SMTP id ffacd0b85a97d-486e594a8c3mr1330062f8f.35.1789033589890; Thu, 10 Sep 2026 02:46:29 -0700 (PDT) Message-ID: <768c0fb8-cf54-49af-a529-8a59cbc9aaeb@suse.com> Date: Thu, 10 Sep 2026 11:46:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] stubdom: Fix GCC 14 -Wmemset-elt-size compiler warnings in PolarSSL To: Andrew Mbugua References: <37902bbd-1ab9-4b49-8f94-4b788b3620d9@suse.com> <20260910091414.22966-1-andrewprecious388@gmail.com> Content-Language: en-US Cc: xen-devel@lists.xenproject.org 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: <20260910091414.22966-1-andrewprecious388@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789033590-1AEDE9EA-850543A7/0/0 X-purgate-type: clean X-purgate-size: 2784 On 10.09.2026 11:14, Andrew Mbugua wrote: > A followup to the email thread with the previously suggested changes. > > I have: > 1. Added the patch reference to the Makefile > 2. Removed the new subdirectory I created. > 3. Formatted patch message to be <75 characters per line For one, none of the above should be part of the commit message. Such wants to move past the first --- separator. Then: While I see you did 2, I don't think you really did 1 and 3. As to 3, ... > When compiling Xen with GCC 14, I get a compiler warning originating from the /polarssl-x86_64/library about a memset element size mismatch: ... this is still in need of wrapping, whereas ... > ssl_tls.c: In function ‘ssl_session_reset’: > ssl_tls.c:1778:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] > 1778 | memset( ssl->ctx_enc, 0, 128 ); > | ^~~~~~ > ssl_tls.c:1779:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] > 1779 | memset( ssl->ctx_dec, 0, 128 ); > | ^~~~~~ ... compiler output may be kept as is (imo). > This patch introduces a build-time patch to PolarSSL that replaces the hardcoded > 128 byte length with sizeof() allowing clean compilation without warnings. This again looks to need suitable wrapping. Furthermore, isn't there a little more to be said here? After all sizeof(ssl->ctx_enc) != 128, afaict. > Signed-off-by: Andrew Mbugua > --- > stubdom/v2-0001-PATCH-stubdom-Fix-GCC-14-Wmemset-elt-size-compile.patch | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > create mode 100644 stubdom/v2-0001-PATCH-stubdom-Fix-GCC-14-Wmemset-elt-size-compile.patch In line with other patches we have there, maybe better name this e.g. polarssl-gcc14.patch? > --- /dev/null > +++ b/stubdom/v2-0001-PATCH-stubdom-Fix-GCC-14-Wmemset-elt-size-compile.patch > @@ -0,0 +1,13 @@ > +--- a/library/ssl_tls.c > ++++ b/library/ssl_tls.c > +@@ -1775,8 +1775,8 @@ > + memset( ssl->iv_dec, 0, 16 ); > + memset( ssl->mac_enc, 0, 32 ); > + memset( ssl->mac_dec, 0, 32 ); > +- memset( ssl->ctx_enc, 0, 128 ); > +- memset( ssl->ctx_dec, 0, 128 ); > ++ memset( ssl->ctx_enc, 0, sizeof( ssl->ctx_enc ) ); > ++ memset( ssl->ctx_dec, 0, sizeof( ssl->ctx_dec ) ); > + > + md5_starts( &ssl->fin_md5 ); > + sha1_starts( &ssl->fin_sha1 ); I haven't tried it out, but I can't help the impression that this patch is not going to apply. The source code I'm looking at has no use of hard tabs, yet there are hard tabs on the patch context lines above (yet interestingly not on the lines actually altered). Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:48:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:48:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414285.1644063 (Exim 4.92) (envelope-from ) id 1x4bNz-0008Ab-Lh; Thu, 10 Sep 2026 09:48:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414285.1644063; Thu, 10 Sep 2026 09:48:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bNz-0008AU-IX; Thu, 10 Sep 2026 09:48:03 +0000 Received: by outflank-mailman (input) for mailman id 1414285; Thu, 10 Sep 2026 09:48:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4bNy-000899-Df for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:48:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bNx-0025Nl-Qe for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:48:01 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa27cce-8faa-0a2a0a5109dd-0a2a450285ee-8 for ; Thu, 10 Sep 2026 11:48:01 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa27cd1-6ca4-0a2a45020019-d155802ce485-3 for ; Thu, 10 Sep 2026 11:48:01 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49cca4ffdcfso56534765e9.0 for ; Thu, 10 Sep 2026 02:48:01 -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-49d26c06f04sm64243345e9.13.2026.09.10.02.48.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 02:48:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789033681; x=1789638481; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=dLXmqrgSVLlstBLicQkdZBAUJ+mHmKliLnE6FFI7R3E=; b=Rk7gvoLDp7od5o2Ho3diCkOF1OSG5u0tTcICjxZ5iikOlaU9qwojf5f9SZ5V7m5kGi /JbgHOEqdTiterYdPQ9LPDwwcKK5QbizH59hNur1iFG+RzLpq8nwdm++ZHfXPQWeIISr j1rAkLpFfnKVawWP1+Ce4wBGRjdjyWBv5drDVWGPtk2sXHpzNplfrQHmm73nnHzvfkge xokAiPPosRY3gqsYZ6B+9/KLKVP1YfREl272gjC1v5CQgAiXkmxtNcu3htDRyOq52XHt kUsq3bH8J42ldgZpDgTT0S6g6+Kw3pq47PXAZ7GkUVfFo8CtKfZ3MdcdnU8jMunzfeIg S5bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789033681; x=1789638481; h=content-transfer-encoding:content-type: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:content-type; bh=dLXmqrgSVLlstBLicQkdZBAUJ+mHmKliLnE6FFI7R3E=; b=eFb4rlAPZUu0t3YDS+xHwcKrLe4rwBbSe2XekrpHurD6T8KwNoxcjPdtrdINoFppd3 rSDWc3qwNoKtVo37cFnu7VpAR8MZSixrKQga5RZwSV4UJJ2sNllKJtJXQnNkzlXxvYWk LClak+LgcP8m2a35qPf/OjDOfJz6oukUvCqfaqYiARJz6n4rREanTnnPOrMbH9HC45A4 /19XA8fF26JSxWaafKoYnTtvgP9DJ60p3IKdSQMYtTEazKZvEaSNJH1TcDfhhlBIP61u BLg6/7usYThH4UsdZsk7jXqx+2mWS8qKPG7wBPFzD3KIgSZVTYu6K3PWQ3tm7T5MfQmC hOQQ== X-Gm-Message-State: AFuF++ljly1/4v7tC0jXR0Kl0+R4WkMcuIWSzWcDsA0H8wfD/dh4OgzW o8cZyv9slpB7FR52IE/DkPANHzzsLuJ60fH/h0Rugo983yckzX/F5bmtqfCrt84lYZgwZHVb5RX QlADYtw== X-Gm-Gg: AYBFou16ZSqmIOinkFAz/w0kjqNouN1Fhv7qlC8onoGSNDfPmXcQVLgaBjl5AgqdEJN GeQk+CvQjsfIo386qqDNCfz8M5cEcg6dvYrnyt3/4fSuBx14YB4HrX/ON6pF5au0DDNhso6hI/n m5UFkmoJ833tX+ociVIcC98DjUtusiMU5Z7QQ2fvbtScye5Krrrl7FQPUMhAMihgTW762xGdMwx Jnf9A6xx/k5A+Cl9N8/YnZ/wUpWiv988h66P5Hhz7tNiQV/MaS6f7LMBjCGypZ/1YWALda7Mvw2 tVcxoC/MghjjAy5OiGDx87qPOMsvFe/uXys74HbvSI7g1W/heNY7R6gkihwTmuHk9SDigx877DF 4GkIr/Gvz2RITo3wiB/C13CSqapvRMNIddEI5inzANGy2xfdVWjJ4tyj+cMkbpb8aLFzNdUdcUM 3Pjp+cP5TuwOAfb5dxqCwmf5MCALcu5HCoR4IhmjRd4sL3TEQKq6zhi7pBQB3+tCLy0El9UWYLS IH4gy7cXUk/IqWdJLJSgof2ajiOBl5ydRQLnu3KUxNHJo87ySfVTSmxy2tgbXc= X-Received: by 2002:a05:600c:4f12:b0:499:da8b:1476 with SMTP id 5b1f17b1804b1-49cf825a5bcmr425426845e9.14.1789033681231; Thu, 10 Sep 2026 02:48:01 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 11:47:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/6] xen/riscv: fix boot on missing extensions and MMU setup bugs To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Zheng Zhang , Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> 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: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789033681-670B02AC-3D16F129/10/73395122804 X-purgate-type: spam X-purgate-size: 1849 On 10.09.2026 11:30, Baptiste Le Duc wrote: > This series introduces bugs fixes that were found while bringing up CI > support for the HiFive Premier P550 board with a basic smoke test. The > board-support series itself will follow separately as it depends on > PLIC/vPLIC and dom0less support that have not been upstreamed yet. This > series carries only the independent fixes found along the way, none of them > need the board-support series to apply. > > This series: > 1: Fix Svade/Svadu A/D bit handling > 2: Set A/D bits in Xen's own page-table mappings under Svade > 3: Make Svpbmt no longer a required extension > 4: Make Zihintpause no longer a required extension > 5: Flush speculatively cached Bare-mode TLB entries in turn_on_mmu() > 6: Fix level_map_mask truncation on load_start > > CI pipeline: > https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2836284276 > > --- > Changes since v1: > - address ML comments > - rename some patchs > - add new patch-fix: 242dd1f890e4 ("xen/riscv: fix level_map_mask > truncation on load_start") discovered when working on Spacemit K3 support > > To: Zheng Zhang > To: Alistair Francis > To: Connor Davis > To: Oleksii Kurochko > To: Andrew Cooper > To: Anthony PERARD > To: Michal Orzel > To: Jan Beulich > To: Julien Grall > To: Roger Pau Monné > To: Stefano Stabellini > Cc: xen-devel@lists.xenproject.org Please can you adhere to patch submission rules? Patches are to be sent To: the list, with relevant people Cc:-ed. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:52:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:52:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414292.1644072 (Exim 4.92) (envelope-from ) id 1x4bS2-0001YY-5e; Thu, 10 Sep 2026 09:52:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414292.1644072; Thu, 10 Sep 2026 09:52:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bS2-0001YR-2q; Thu, 10 Sep 2026 09:52:14 +0000 Received: by outflank-mailman (input) for mailman id 1414292; Thu, 10 Sep 2026 09:52:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bS0-0001YL-UQ for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:52:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bS0-00AG8B-70 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:52:12 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa27dca-e002-0a2a0a5209dd-0a2a45058ca4-6 for ; Thu, 10 Sep 2026 11:52:12 +0200 Received: from [209.85.128.44] (helo=mail-wm1-f44.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa27dcb-4cb1-0a2a45050019-d155802cd49b-3 for ; Thu, 10 Sep 2026 11:52:12 +0200 Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49954b88fffso50180805e9.0 for ; Thu, 10 Sep 2026 02:52:12 -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 ffacd0b85a97d-485958f1493sm38170192f8f.37.2026.09.10.02.52.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 02:52:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789033931; x=1789638731; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=X3SFNLvQSoJtBjgqhOMA4Ch6yzscJjCRZhPApbgo4IE=; b=eJQe54Pe3MaPzxWhvvH560Wl8g54wKiH20AuW2ZpZfYdDoeR8noSMeRnhcS71TBgHD j8S3CMMdjp9jepdNMbcUcTcznoQQK241EfXZSW/bF872oYWvOzQAAnEIFjuynSTQLIxi CeMmN74IX7+2O4iqm9DZkNPcoCZBCzKLzI3KMcKz74R/asiypDD/1Z2ZShJcI6WETVyw 8qvhnxYQiWdzx93BABxjDw2RRm4HDPz4ZGvkcU2zDdEofEQfVCsTRiEBgIEA/enIWh/Y vGUczqnttEjBV5flnwOCBax9b+JaDsEAybdAsKvktO+nOvEUBzBpHJpOfQ7KrXkp1PRE 0L6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789033931; x=1789638731; h=content-transfer-encoding:content-type: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:content-type; bh=X3SFNLvQSoJtBjgqhOMA4Ch6yzscJjCRZhPApbgo4IE=; b=aB0lZCdll2rPvqmOvMF4I8BHA7nPV6wAUZD+FezV30Nr+guTuEvQVre9kgvM7byZA0 Cr1qPsi/z/7zF9tdwpoJtRzvzGfUrmUJ0ST7PBRzSROtN4S8bGe1rT2py2PU3twDv3tA bHMGMHs3MIuEslOLl4JBGyV+orJIjwyVz1y3LysP8th9fw1QECghY1Wi8E+08f0VOOV8 UOkNYHwu/YUmJUSbcUu07/ZirEbt9+yyKPdvN+xO+GCLDMlJ3orEX3Ba/CzJgxfR1iJN DKskE+MdOs2mG+siCdcJso1/XHHahUImjOQP1gAW4F1tQg4uAjdWwZJUoSJFs1ZmenPq Lk0Q== X-Gm-Message-State: AFuF++mYfZbmQ7ReTa4/yuZPfZh3FeKgTOFmLfOSEKKT6s217bXzXo9L FcNl7QQNLd62BMrOcn+U58/Lof4mD7cFZbTt513Pg6Snd/rdAnrCC3ulg5ghHTJ8PA== X-Gm-Gg: AYBFou1gmWUTRzoDHbOo0+cJAhBe0Vy4aDiI92pwXGI0AbpXKnvxypwrUTSkGaB9vDB t6dQrq2dpcZxax7c7uEeykVOA7xypUvZQoRNUk4G1IxAyUsoIda0PfSICqEbA8XiWsBpz/Mrk9/ G2xg3jAZUcghozO80I0uznOis13/0Di+LZa4ovrLAwY14GROeVG1xSBW18xu7IilF+DbNXIA5kc FCjr9kq8cXmm0pFHarOhz658o4f4k8Z9lf3qml36GeLUQmKdTuv0m2OKLZiqQF8X2kEhEfbE/Y0 7+vE5SEvRMAidLZ5RT663+KxdqCgIzV5q54iK/+i1398g3yOMTkfam50MEEBzPZ84bYo3fUq6Lt 4YMAil4xIoL/8HFkXA6PBGsgqKV5r4ijEbGrbRaJmMKPxuY5E16/mFVpuOXdMHt2AqCbfHDafuD r0lNAhNwDGGkjN+9JSIq2nbW0aKsInljATz1bnTcn1wbSDO8lf5YPRKS2cYXLyT1FRdncf2eZN4 +ejFCPGHTeswETOjT+vud0TPOn6mHAXejhVnsK4cOpNJr3bKRGk8kZOJJP0dZI= X-Received: by 2002:a05:600c:b93:b0:49d:17c5:8f7a with SMTP id 5b1f17b1804b1-49d17c58fa8mr175719285e9.18.1789033931576; Thu, 10 Sep 2026 02:52:11 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 11:52:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@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: 8bit X-purgate-ID: tlsNG-c201ff/1789033932-71CA82A1-A8F500FD/0/0 X-purgate-type: clean X-purgate-size: 1112 On 10.09.2026 11:30, Roger Pau Monné wrote: > On Thu, Sep 10, 2026 at 10:38:34AM +0200, Jan Beulich wrote: >> On 10.09.2026 09:49, Roger Pau Monné wrote: >>> On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote: >>>> The use of unreachable(), when unreachability is visible to Eclair (and >>>> compilers), is deemed a violation. Drop the redundant statement. >>> >>> Urg, isn't that something that should be fixed in Eclair then? >>> Otherwise all the unreachable() calls in our codebase are likely to be >>> found by Eclair sooner or later, and will need to be removed. >> >> No, aiui most are covered by deviations. In particular ones in BUG() and >> ASSERT_UNREACHABLE(). > > Shouldn't this be a deviation then also? Maybe, just that I had no good idea how to express such a deviation (preferably without a SAF comment). > Maybe it would be helpful if > the commit message states why this is handled differently from other > unreachable() instances then. I've added "..., , and the one here isn't covered by a deviation" to the first sentence. Will that suffice? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:55:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:55:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414301.1644085 (Exim 4.92) (envelope-from ) id 1x4bUs-00026b-J6; Thu, 10 Sep 2026 09:55:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414301.1644085; Thu, 10 Sep 2026 09:55:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bUs-00026U-Ga; Thu, 10 Sep 2026 09:55:10 +0000 Received: by outflank-mailman (input) for mailman id 1414301; Thu, 10 Sep 2026 09:55:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bUr-00026F-3M for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:55:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bUq-00AOig-GJ for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:55:08 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa27e6a-e002-0a2a0a5209dd-0a2a4502802c-44 for ; Thu, 10 Sep 2026 11:55:08 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa27e7c-6ca4-0a2a45020019-4a7de14caf29-3 for ; Thu, 10 Sep 2026 11:55:08 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356256so1300018f8f.1 for ; Thu, 10 Sep 2026 02:55:08 -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-49d26bdbb02sm55396955e9.3.2026.09.10.02.55.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 02:55:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789034108; x=1789638908; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=p8PLS0B/eOL2vcsxGj2sSaIE6QRFDPlPY0srq63ErSQ=; b=OdcmY2TDMkIfzSgAeSHO5SYyKh6Uz5rKqNu18CqkJM9HZsm+Q/4YUeTFNwc9wKk9Rd meeKHkham5P2JmsX3579kJhaT9vyCzu63I3K7PPbLIFU8GDcuYBqLuj1R7H1kK0ACo28 eSjo5gDdfTAaRc66J5yGEPC4FpK0A07DamoOg8VQKztBUeWG2BBKOX0KPwVdAFc+qVVv 2+ej/wW+oiDJxtcW0zIBzy7R2fT0lU+TFk2t+obryav1wf+3CvURlGFp3b4+hLBf0wyt 6m6K1M1/ct5dp9bYaYVGUNhabIcEKp1K8JD4c1QlzNxTZvFlXK9fk265M4F8YcgLS26G mkjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789034108; x=1789638908; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=p8PLS0B/eOL2vcsxGj2sSaIE6QRFDPlPY0srq63ErSQ=; b=lRbQuzsfbuGRbNTLmbqbepsp6W3hXhIlZeQvKSxdjAQE0k40K1qNQIUIOqX+m8wRG3 2lvn9CK2KDgY3ve5k2LDTM300nFKmR2LnliAEpx08XjD02suIqiizv4y4fysm15jAMxo b+6YeCx1X3ENWgwF849uwG7Xsk1lCdfZjKohHF0WimVNOGxPihCNNh1PNw8CimFZP7Ih bqd+4khDAVjibQRs468tjrWGfZMZF5AGNpPkNuNOFgUN1kiOekyAJG8FLOwo9o9qNIP9 t2peaUlg+nc1n1fiOzm8tVMbC4AQfvRW12CDmaHOKAAY54r/mT43Iqfj4sqPaQguLmWm DL/g== X-Gm-Message-State: AFuF++l4fjv7N28EhnvwBjrFhtW06xc4xh8tFDECYXsvExEbEy8d2nLl ERPJpwVsUwvltMrybYU6bpVqtHghf1bCe8YMzVWg0CmKewcjNtJ8T1OBLW9UzCfCgP3k0jsz9n0 kE7/j/A== X-Gm-Gg: AYBFou05bAB2a+j7QL+2nRteqOxIt24uRDwsA0pgLYH/EyQe7yKA6CvsWEPkaT7+v/h vQA/o5W1dZPeClZNl1fp0ccRTiZ/U4InG4qwVyz5HHaRpVjLQW7cQLVKu2paVdfg8UTkt+bo89j nkWKYUxzwy+a1Fj113EfEzhTqYaheaYAl6CrqFq/ETm5pu7NQk46LrWrK7BTSF0xFGeO+vktQce JFuLVDrmZZBBDheO9bNXOzEusNbUFLDS74lvvyAUIjOsI8t+2AfZRwfwiwe0t+8woX85XnHhq09 bQUjN26kg7IOfZg5ZogIPT7inzoOq+c4m7fWDFtDsNAzgXnjFQkV44cxWvctz9kDgq89vsyEXY0 zificVQ4rgXYTos8jkGORt7ql+91Z2KNhV3RWPVhkGKpM52DBnYDVBXDcHwZ33FFUhZm/zZteFn CQ+/SuV0jc40et4z/fyNjgBLUfIB+Fg6XAYHGFLhLP654R8sxITqvxZUMHvH60kBYvdw0QJmg22 cGW3WU+JECDq8dn7kPD+gEKOTtVE3BY3xzTx9lJTHf5t36j/OkxAdsbnfPblY8jcfv1us9lhQ== X-Received: by 2002:a05:600c:4592:b0:49c:ee3b:723d with SMTP id 5b1f17b1804b1-49d26c3081fmr38960535e9.0.1789034107817; Thu, 10 Sep 2026 02:55:07 -0700 (PDT) Message-ID: <19fff81a-5920-4c9b-be8f-74354f88bb69@suse.com> Date: Thu, 10 Sep 2026 11:55:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] Eclair: re-enable scanning of the (almost) final linking step 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789034108-31BC82AC-2F19C3C5/0/0 X-purgate-type: clean X-purgate-size: 1121 The real final binaries are now no longer created by a linker invocation, but by renaming an intermediate file (each). Arrange for linking pass 2 outputs to be scanned instead, yet continue to exclude the auxiliary .xen.efi.alt.* binaries. Fixes: da944a72fdf4 ("x86: split xen-syms/xen.efi linking rules")) Signed-off-by: Jan Beulich --- Sadly for Arm64, until "Arm: split xen-syms linking rule" has gone in, this will slow down analysis jobs. --- a/automation/eclair_analysis/ECLAIR/analysis.ecl +++ b/automation/eclair_analysis/ECLAIR/analysis.ecl @@ -36,8 +36,8 @@ their Standard Library equivalents." -doc_begin="Do not analyze intermediate linking artifacts, as they do not differ from their final counterparts for the purposes of MISRA C static analysis." --file_tag+={xen_efi_tmp, "^xen/\\.xen\\.efi\\..*$"} --file_tag+={xen_syms_tmp, "^xen/\\.xen-syms\\..*$"} +-file_tag+={xen_efi_tmp, "^xen/\\.xen\\.efi\\.([01]|alt\\..*)$"} +-file_tag+={xen_syms_tmp, "^xen/\\.xen-syms\\.[013]$"} -frames+={hide, "kind(program)&&target(xen_syms_tmp||xen_efi_tmp)"} -doc_end From xen-devel-bounces@lists.xenproject.org Thu Sep 10 09:56:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 09:56:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414316.1644111 (Exim 4.92) (envelope-from ) id 1x4bVx-0002mf-6Q; Thu, 10 Sep 2026 09:56:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414316.1644111; Thu, 10 Sep 2026 09:56:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bVx-0002mY-2n; Thu, 10 Sep 2026 09:56:17 +0000 Received: by outflank-mailman (input) for mailman id 1414316; Thu, 10 Sep 2026 09:56:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4bVv-0002mO-OV for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 09:56:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4bVv-0008gj-4G for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:56:15 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa27eb2-2eae-0a2a0a5409dd-0a2a4505dec6-40 for ; Thu, 10 Sep 2026 11:56:15 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa27ebe-4cb1-0a2a45050019-b9ff1c23abcb-3 for ; Thu, 10 Sep 2026 11:56:15 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08abf05da000c4f3.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 09:56:09 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 8F3B2815B7; Thu, 10 Sep 2026 11:56:08 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=lBEogv02IQ/RjcN//vVO5A/mS9eBVXtNGDN/7rY8ezQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=KJ+uthc36pPK3xmvvubFvbrIi/NfzBKTwu8fb308ZGRE8AQaRJL4ZMm1A3/ejx0oDxykUkKdU byaEjrfcWEM9EUmUlDdB1YccvOvCn3UVAWDnHa1sNEU4L2tV5egnBiMOz68u03XppDQ7dCH0FPg RHfhRsRHvzUylARAjY8l7Sf5tvWpRCIWskJx2zkZNBzvgJPWmO+7EmGMOcVMoSsRSGqIilSKyU3 6Dvuzs4tZVafnC7CPLWRR/XcAz0hf6xB+KRqNYE8PeYC+6oW5eQH6OvtlwE/2LoV3tko5x4UqY5 r78z/0LAWP0kPgYNAIuWbJHfYrLkOvU2cFI7HqvJQf2A== X-Zone-Loop: 5e4246ad2319e4cdf9745d930b2b32f5a05e25efc3e6 x-campaign-type: default x-transaction-id: e0aac2ce-5db8-4456-a809-042823fa4981 x-swg-uid: 01-a848026c-4e75-4616-b468-d6f545542ba2 X-Mailer: Sweego Message-ID: <1789034169.8631fc262581453bbf619ec5b2062170.1a08abf05da000c4f3@vates.tech> x-swg-bid: 1789034169.8631fc262581453bbf619ec5b2062170.1a08abf05da000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 0/6] xen/riscv: fix boot on missing extensions and MMU setup bugs From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Zheng Zhang , Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> Date: Thu, 10 Sep 2026 11:56:03 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789034168; l=2230; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=r2qWR2lokpGc90Yxnlr9AvFDQNPvU2bqxZYSTc5oCbU=; b=Ytz6+f8rhXm/2JYntkAuYvAHJJaK/MwnurGSSEuvp/l1ZIKQyoqbVbdc6xRfO5t87OFWyZ6lu gZHw7sTBvskANukekYrmlJWpd6Xp5SHEHimCmhXx+VqnHh8pUgp2XEw X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789034169122 X-purgate-ID: tlsNG-c201ff/1789034175-F4EA12A1-ABA62935/10/73395122804 X-purgate-type: spam X-purgate-size: 2234 On 2026-09-10 11:47 +0200, Jan Beulich wrote: > On 10.09.2026 11:30, Baptiste Le Duc wrote: > > This series introduces bugs fixes that were found while bringing up CI > > support for the HiFive Premier P550 board with a basic smoke test. The > > board-support series itself will follow separately as it depends on > > PLIC/vPLIC and dom0less support that have not been upstreamed yet. This > > series carries only the independent fixes found along the way, none of them > > need the board-support series to apply. > > > > This series: > > 1: Fix Svade/Svadu A/D bit handling > > 2: Set A/D bits in Xen's own page-table mappings under Svade > > 3: Make Svpbmt no longer a required extension > > 4: Make Zihintpause no longer a required extension > > 5: Flush speculatively cached Bare-mode TLB entries in turn_on_mmu() > > 6: Fix level_map_mask truncation on load_start > > > > CI pipeline: > > https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/2836284276 > > > > --- > > Changes since v1: > > - address ML comments > > - rename some patchs > > - add new patch-fix: 242dd1f890e4 ("xen/riscv: fix level_map_mask > > truncation on load_start") discovered when working on Spacemit K3 support > > > > To: Zheng Zhang > > To: Alistair Francis > > To: Connor Davis > > To: Oleksii Kurochko > > To: Andrew Cooper > > To: Anthony PERARD > > To: Michal Orzel > > To: Jan Beulich > > To: Julien Grall > > To: Roger Pau Monné > > To: Stefano Stabellini > > Cc: xen-devel@lists.xenproject.org > > Please can you adhere to patch submission rules? Patches are to be sent To: > the list, with relevant people Cc:-ed. > Sorry, first time I used b4 tool which automatically added the To: and I missed that during the dry-run... I'd like to do a .b4-config with the submission rules that could be added in the repo, do you think it could be a good idea? > Jan > > > From xen-devel-bounces@lists.xenproject.org Thu Sep 10 10:14:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 10:14:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414330.1644131 (Exim 4.92) (envelope-from ) id 1x4bn8-0006dh-MW; Thu, 10 Sep 2026 10:14:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414330.1644131; Thu, 10 Sep 2026 10:14:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4bn8-0006da-Js; Thu, 10 Sep 2026 10:14:02 +0000 Received: by outflank-mailman (input) for mailman id 1414330; Thu, 10 Sep 2026 10:00:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ba1-0004uR-6p for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 10:00:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4ba0-0050qw-Jb for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 12:00:28 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa27fb7-2eae-0a2a0a5409dd-0a2a4508a918-24 for ; Thu, 10 Sep 2026 12:00:25 +0200 Received: from [159.226.251.21] (helo=cstnet.cn) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa27fb6-f659-0a2a45080019-9fe2fb15b84c-3 for ; Thu, 10 Sep 2026 12:00:25 +0200 Received: from iscas-ws (unknown [36.110.52.2]) by APP-01 (Coremail) with SMTP id qwCowAAX7O+0f6JqWJeYBw--.31307S2; Thu, 10 Sep 2026 18:00:21 +0800 (CST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Date: Thu, 10 Sep 2026 18:00:52 +0800 From: Zhang Zheng To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH v2 2/6] automation/qtb: add jinja2 device trees for riscv64 smoke tests Message-ID: References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech> X-CM-TRANSID:qwCowAAX7O+0f6JqWJeYBw--.31307S2 X-Coremail-Antispam: 1UD129KBjvJXoW3WFyDur4ftr1DWrW5GF17ZFb_yoWxGFyDpw srG39ruFs7tr47Kws8Wa1UGrn7CanYkFWrur1UJryUAryqgr40vrnxKw48Cr4xKr1kJ342 vF4ruF1j9wsxJ3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r126r1DMcIj6I8E87Iv67AKxVW8Jr0_Cr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCF04k20xvY0x0EwIxGrwCFx2Iq xVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r 106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AK xVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7 xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_ GrUvcSsGvfC2KfnxnUUI43ZEXa7IU5ksqtUUUUU== X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-c1860d/1789034425-CED4087B-D1700052/0/0 X-purgate-type: clean X-purgate-size: 7629 On Thu, Aug 27, 2026 at 11:42:48AM +0200, Baptiste Le Duc wrote: > The dom0less RISC-V smoke tests need a host device tree describing the > platform (CPUs, APLIC/IMSIC, uart). It varies per machine (hart count, MMU > type), so a single static .dts cannot cover the test matrix. > > Add dts/qemu-host.dts.j2, a template of the QEMU virt platform in > aia=aplic-imsic mode: per-hart cpu/cpu-intc nodes, the M- and S-mode APLIC > and IMSIC pairs, CLINT and the ns16550a uart. It takes ncpus, mmu_type and > xen_bootargs as arguments. > > Values QEMU hardcodes are set as named constants matching their source > symbols (QEMU_UART0_IRQ, QEMU_IRQCHIP_NUM_SOURCES, ...) rather than > open-coded, so a QEMU-side change is easy to trace. > > The template is inert on its own: the generated dtb will be used in next > patch. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > .../scripts/qtb/riscv/dts/qemu-host.dts.j2 | 160 ++++++++++++++++++ > 1 file changed, 160 insertions(+) > create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > > diff --git a/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > new file mode 100644 > index 0000000000..13a8e983ce > --- /dev/null > +++ b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > @@ -0,0 +1,160 @@ > +/dts-v1/; > + > +{#- > + * Jinja2 QEMU "virt" platform device tree for Xen RISC-V tests. > + * > + * Interrupt controller: APLIC in MSI mode + IMSIC > + * (QEMU -M virt,aia=aplic-imsic). > + * > + * Rendered by xen_dt.py. > + * > + * Variables: > + * ncpus - number of physical harts (int, >= 1) > + * mmu_type - Xen host MMU type, e.g. "sv39" (string) > + * xen_bootargs - Xen command line (string) > + * > + * Per-hart nodes are labelled cpu / cpu_intc and referenced with &label. > + * > + * No `aia-guests=N`, so no VS-mode guest files: IMSIC reg size is > + * ncpus * page size. > +-#} > +{#- Values QEMU hardcodes, need to be described to Xen -#} > +{%- set QEMU_TIMEBASE_FREQUENCY = 10000000 %} {#- RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ -#} > +{%- set QEMU_IRQCHIP_NUM_SOURCES = 96 %} {#- VIRT_IRQCHIP_NUM_SOURCES (virt.h) -#} > +{%- set QEMU_IRQCHIP_NUM_MSIS = 255 %} {#- VIRT_IRQCHIP_NUM_MSIS -#} > +{%- set QEMU_UART_CLOCK_FREQUENCY = 3686400 %} {#- create_fdt_uart() -#} > +{%- set QEMU_UART0_IRQ = 10 %} {#- UART0_IRQ -#} > +{%- set QEMU_IMSIC_PAGE_SZ = 0x1000 %} {#- IMSIC_MMIO_PAGE_SZ -#} > + > +{%- set IRQ_TYPE_LEVEL_HIGH = 4 %} > +{%- set APLIC_IRQ_CELLS = 2 %} > + > +{%- set IRQ_M_SOFT = 3 %} > +{%- set IRQ_M_TIMER = 7 %} > +{%- set IRQ_S_EXT = 9 %} > +{%- set IRQ_M_EXT = 11 %} > + > +/ { > + #address-cells = <0x02>; > + #size-cells = <0x02>; > + compatible = "riscv-virtio"; > + model = "riscv-virtio,qemu"; > + > + memory@80000000 { > + device_type = "memory"; > + reg = <0x00 0x80000000 0x00 0x80000000>; > + }; > + > + cpus { > + #address-cells = <0x01>; > + #size-cells = <0x00>; > + timebase-frequency = <{{ QEMU_TIMEBASE_FREQUENCY }}>; > +{% for i in range(ncpus) %} > + cpu{{ i }}: cpu@{{ i }} { > + device_type = "cpu"; > + reg = <0x{{ '%x' % i }}>; > + status = "okay"; > + compatible = "riscv"; > + riscv,cbop-block-size = <0x40>; > + riscv,cboz-block-size = <0x40>; > + riscv,cbom-block-size = <0x40>; > + riscv,isa = "rv64imafdch_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_smstateen_svpbmt_smaia_ssaia"; > + mmu-type = "riscv,{{ mmu_type }}"; > + > + cpu{{ i }}_intc: interrupt-controller@{{ i }} { > + #interrupt-cells = <0x01>; > + interrupt-controller; > + compatible = "riscv,cpu-intc"; > + }; > + }; > +{% endfor %} > + cpu-map { > + > + cluster0 { > +{% for i in range(ncpus) %} > + core{{ i }} { > + cpu = <&cpu{{ i }}>; > + }; > +{% endfor %} > + }; > + }; > + }; > + > + soc { > + #address-cells = <0x02>; > + #size-cells = <0x02>; > + compatible = "simple-bus"; > + ranges; > + > + serial@10000000 { > + interrupts = <{{ QEMU_UART0_IRQ }} {{ IRQ_TYPE_LEVEL_HIGH }}>; > + interrupt-parent = <&aplic_s>; > + clock-frequency = <{{ QEMU_UART_CLOCK_FREQUENCY }}>; > + reg = <0x00 0x10000000 0x00 0x100>; > + compatible = "ns16550a"; > + }; > + > + aplic_s: aplic@d000000 { > + riscv,num-sources = <{{ QEMU_IRQCHIP_NUM_SOURCES }}>; > + reg = <0x00 0xd000000 0x00 0x8000>; > + msi-parent = <&imsic_s>; > + interrupt-controller; > + #interrupt-cells = <{{ APLIC_IRQ_CELLS }}>; > + compatible = "riscv,aplic"; > + }; > + > + aplic@c000000 { > + riscv,delegate = <&aplic_s 0x01 {{ QEMU_IRQCHIP_NUM_SOURCES }}>; It seems like `riscv,delegate` was deprecated in QEMU 9.1 and has been removed in QEMU 11.0. The property defined by the APLIC device-tree binding is `riscv,delegation`. See: https://lists.gnu.org/archive/html/qemu-devel/2026-03/msg01459.html > + riscv,children = <&aplic_s>; > + riscv,num-sources = <{{ QEMU_IRQCHIP_NUM_SOURCES }}>; > + reg = <0x00 0xc000000 0x00 0x8000>; > + msi-parent = <&imsic_m>; > + interrupt-controller; > + #interrupt-cells = <{{ APLIC_IRQ_CELLS }}>; > + compatible = "riscv,aplic"; > + }; > + > + imsic_s: imsics@28000000 { > + riscv,num-ids = <{{ QEMU_IRQCHIP_NUM_MSIS }}>; > + reg = <0x00 0x28000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC_PAGE_SZ) }}>; > + interrupts-extended = < > + {%- for i in range(ncpus) %} > + &cpu{{ i }}_intc {{ IRQ_S_EXT }} > + {%- endfor %} > + >; > + msi-controller; > + interrupt-controller; > + #interrupt-cells = <0x00>; > + compatible = "riscv,imsics"; > + }; > + > + imsic_m: imsics@24000000 { > + riscv,num-ids = <{{ QEMU_IRQCHIP_NUM_MSIS }}>; > + reg = <0x00 0x24000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC_PAGE_SZ) }}>; > + interrupts-extended = < > + {%- for i in range(ncpus) %} > + &cpu{{ i }}_intc {{ IRQ_M_EXT }} > + {%- endfor %} > + >; > + msi-controller; > + interrupt-controller; > + #interrupt-cells = <0x00>; > + compatible = "riscv,imsics"; > + }; > + > + clint@2000000 { > + interrupts-extended = < > + {%- for i in range(ncpus) %} > + &cpu{{ i }}_intc {{ IRQ_M_SOFT }} &cpu{{ i }}_intc {{ IRQ_M_TIMER }} > + {%- endfor %} > + >; > + reg = <0x00 0x2000000 0x00 0x10000>; > + compatible = "sifive,clint0", "riscv,clint0"; > + }; > + }; > + > + chosen { > + stdout-path = "/soc/serial@10000000"; > + xen,xen-bootargs = "{{ xen_bootargs }}"; > + }; > +}; > Zhang From xen-devel-bounces@lists.xenproject.org Thu Sep 10 10:38:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 10:38:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414383.1644139 (Exim 4.92) (envelope-from ) id 1x4cAJ-0001Kt-A1; Thu, 10 Sep 2026 10:37:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414383.1644139; Thu, 10 Sep 2026 10:37:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4cAJ-0001Ki-6o; Thu, 10 Sep 2026 10:37:59 +0000 Received: by outflank-mailman (input) for mailman id 1414383; Thu, 10 Sep 2026 10:37:58 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4cAI-0001Kc-6m for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 10:37:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4cAG-00AXQm-St for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 12:37:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa28877-2eae-0a2a0a5409dd-0a2a450699fa-22 for ; Thu, 10 Sep 2026 12:37:56 +0200 Received: from [209.85.218.48] (helo=mail-ej1-f48.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa28884-195a-0a2a45060019-d155da30e535-3 for ; Thu, 10 Sep 2026 12:37:56 +0200 Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-c2956d30b56so18255266b.1 for ; Thu, 10 Sep 2026 03:37:56 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2945ab67c3sm101282166b.27.2026.09.10.03.37.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 03:37:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789036676; x=1789641476; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4FKD99PzG2ZUhrNmLv19ZWuE9n7M65hZZxxymIKbswM=; b=FFcOUwOG7ugI7/9QX2xUdwKiUq9VsSExuI2l6oDmPXFkhogMM17fwqI24gQL0wFnTC YB6l00ZqmZUB8Zdzqc8xCDA7wKqUyvOMMUjNKay/l4DFJaDkrMIajYVkmS0mdAPLLbch 9wAieu/XuFoNDg9ZJc8hFDgwtogongmeEBqx9IxsIsrm9+OCy7SAnV0NgSTqCt9YDmqd Llbe9zNOfr/dGDgkwIbkglss5K87j07ZMLTjRAUQdYTeCxvwA8hmjfETXZ4ig/MkcA8F jE1Wy8PjE63XGcCbxgaq2J8mh1Wsu60nxdZBP3Wh1v8LGyYGAkKJVBpxkaPvacPqvH2T CptQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789036676; x=1789641476; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=4FKD99PzG2ZUhrNmLv19ZWuE9n7M65hZZxxymIKbswM=; b=adUu4RNz4COSPRAAYscLndUFe1CoZTdUowp5QjvZPd82Z/TC9ewwU/JdxcTkUK9Ldm 0xv8878K4IhITybKipR99QhYeC+L6EWDzwHzlYvSYmbiGb0LEIQh5G8vTclbxmSjDNl2 Okj/tAfBCkhIpA6CXQib7Ym8jpiE7rf99XKoQtyFio7Wg+HV9Kzb9ULPwyL6qstJQDjr GHthv1XmIRVNLK7n49Z4/HppDq1hwNPIl1AYL0gkIeJ3NWQmvTvcyb9y2lqwfzQrc3/o 7F74pK0barjUYpIIP08nSzBvwzqShp4zmnevTguiLMQpBa+sk2FaSR9bESxvsIoeiBR1 nDDw== X-Forwarded-Encrypted: i=1; AKwUvByHKcJy6BDcns8DtZ+DxG+lB6mJGOW7aYItxnTQqXniiEw65PzrNNzb2QLY1yxAPhAGFIbdtUrcDC0=@lists.xenproject.org X-Gm-Message-State: AFuF++lLganmEWA9zVE4XJ2TsHbYJnYHSka9DZCowrYLgupc5mXlUCDE pkyd5ZO3EeEMLFfzJiUIS/uDTOfSPJ7ErWlIeimGh9QHTtrlZ05TBKcH X-Gm-Gg: AYBFou3mTvWKkTQfO/m/I9DXDyHUDGAo0a/m67QOWwB8SbJL9VrZOUODtY3zh4Z+ULW AO2kz2QglTG7O9FPLxDUIOVIz0A0PUIl/elOS8SQ6uGAY4D5pOxEEjFmg3nLG5FonWa8coOKhRg ZnQBLCTlPYdU/dTD49SbpeoSPUMjtbmo09J+SFCI/V58Yyrx1BNm0LHc8gtU3yC3OnwZY64zojI vOV4wLwH5jRG13UI7K56f+0zHNddQTtuqgSLmy/M3ReCbK5u2bWk5rtxQjt7zJqDIAfP8vbSoPq 3NdTU7Y+xERydWJLhtSyF60GzBzbz7+3yCBRFPYnrQIFdpUy3Hiwe9a64D3+aWAw4ssXX/Po9Gb Ckz311/uH2bVmg1fBK9hgvTe2aKK/3dAvd6SxHX+RZV0K8yaf2e1NRkUtY7/lLzaxp8RNBFgO3L qtmEjX6b0BCQd29xSDTXOvp66bz4pwNFQg65V3VQv7oiyzfu3tEhUy2WXywBaAkmUHTkfoOrKfN oUr8stsZrzHU/Oa53A9McZe2KWhC91j X-Received: by 2002:a17:907:97d3:b0:c29:1133:e17b with SMTP id a640c23a62f3a-c291133e32bmr691803966b.19.1789036676038; Thu, 10 Sep 2026 03:37:56 -0700 (PDT) Message-ID: <071ed630-4c72-4df1-b15e-3037e3f076ba@gmail.com> Date: Thu, 10 Sep 2026 12:37:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> <68ab5241-7301-4988-9420-bcccc4b16e3d@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <68ab5241-7301-4988-9420-bcccc4b16e3d@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789036676-F70C777B-94915A6B/10/73395122804 X-purgate-type: spam X-purgate-size: 13821 On 9/9/26 4:26 PM, Jan Beulich wrote: > On 27.08.2026 17:20, Oleksii Kurochko wrote: >> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, >> + uint32_t base_val) >> +{ >> + unsigned int guest_id = vcpu_guest_file_id(target_vcpu); >> + unsigned long hart_field = aplic_hart_field(target_vcpu->processor); > > What guarantees target_vcpu's ->processor field to be meaningful at this > point? Good question. Considering the places where it is called, I would expect target_vcpu->processor to have something meaningful, since it is called from a place that can only be reached when the guest is running. Even without that, I don't think there is a big issue here, as ->processor is initialized to 0 at allocation time. This means that the target register will be configured in such a way that CPU 0 will handle such IRQs. >(Also again naming of the parameter: Generally it wants to be "v" > or "curr"; only very special cases may use other names.) I will use just `v` then here. > >> +uint32_t aplic_hw_read_reg(unsigned int offset) >> +{ >> + unsigned long flags; >> + uint32_t val; >> + >> + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); >> + >> + spin_lock_irqsave(&aplic.lock, flags); >> + val = readl((volatile void __iomem *)aplic.regs + offset); > > Please can this have const alongside volatile? Sure, I will add. > >> @@ -98,6 +108,27 @@ >> #define APLIC_SIZE(nr_cpus) \ >> (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus))) >> >> +/* >> + * Using setip is fine here, as all SET* and CLR* register groups consist of 32 >> + * registers and therefore have identical sizes. >> + * >> + * Lowest 2 bits are always zero for SET* and CLR* registers. >> + */ >> +#define APLIC_SETCLR_OFFSET_MASK \ >> + (sizeof_field(struct aplic_regs, setip) - sizeof(uint32_t)) >> + >> +#define APLIC_xMSICFGADDR_PPN_SHIFT IMSIC_MMIO_PAGE_SHIFT >> + >> +#define APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw) \ >> + (BIT(hhxw, UL) - 1) >> +#define APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs) \ >> + ((hhxs) + APLIC_xMSICFGADDR_PPN_SHIFT) >> + >> +#define APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw) \ >> + (BIT(lhxw, UL) - 1) >> +#define APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs) \ >> + (lhxs) > > May I ask to avoid unnecessary line splitting here as well? I will fix that for APLIC_xMSICFGADDR_PPN_HHX_MASK, APLIC_xMSICFGADDR_PPN_LHX_MASK and APLIC_xMSICFGADDR_PPN_LHX_SHIFT. > >> --- a/xen/arch/riscv/include/asm/vaplic.h >> +++ b/xen/arch/riscv/include/asm/vaplic.h >> @@ -21,11 +21,16 @@ struct domain; >> >> struct vaplic_regs { >> uint32_t domaincfg; >> + >> + uint32_t *target; >> }; > > A pointer in this structure is odd, as this (supposedly) is a set of > guest register values. The field name also doesn't clarify its purpose. > All in all: Likely a comment is needed here. It is a pointer because I tried to save some memory and allocate register target based on how many irqs a guest really needed. As an option I can allocate that statically and use the value from AIA spec: target[1]-target[1023]. Would it better? If a dynamic allocation is still fine then I will add the following comment: /* * Guest's view of the APLIC target registers, indexed by IRQ number. * * The array holds d->arch.vintc->nr_virqs elements; target[0] is unused * as APLIC interrupt sources start from 1. */ uint32_t *target; > >> --- a/xen/arch/riscv/vaplic.c >> +++ b/xen/arch/riscv/vaplic.c >> @@ -17,6 +17,7 @@ >> #include >> #include >> #include >> +#include >> #include >> >> #include "aplic-priv.h" >> @@ -27,6 +28,279 @@ unsigned int __ro_after_init guest_aplic_num_sources; >> >> #define FDT_VAPLIC_INT_CELLS 2 >> >> +#define AUTH_IRQ_BIT(d, irqn) \ >> + (((irqn) < (d)->arch.vintc->nr_virqs) && \ >> + test_bit(irqn, (d)->arch.vintc->used_irqs)) >> + >> +/* >> + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group) to >> + * a 32-bit word index into the used_irqs bitmap. Each word covers 32 >> + * interrupt sources. For SOURCECFG and TARGET groups the same division also >> + * yields the interrupt number directly, because those arrays store one 32-bit >> + * register per source. >> + */ >> +#define regoffset_to_word_idx(reg_val) ((reg_val) / sizeof(uint32_t)) >> + >> +static uint32_t vaplic_target_read(const struct domain *d, unsigned int irqn) >> +{ >> + const struct vaplic *vaplic = to_vaplic(d); >> + >> + /* target[0] doesn't exist so irqn == 0 should be impossible */ >> + if ( !irqn || irqn >= vaplic->vintc.nr_virqs ) >> + return 0; >> + >> + return read_atomic(&vaplic->regs.target[irqn]); >> +} >> + >> +static inline uint32_t generate_auth_mask(const struct domain *currd, >> + unsigned int word_idx) >> +{ >> + unsigned int first_bit = word_idx * sizeof(uint32_t) * BITS_PER_BYTE; >> + >> + if ( word_idx >= DIV_ROUND_UP(currd->arch.vintc->nr_virqs, >> + sizeof(uint32_t) * BITS_PER_BYTE) ) >> + { >> + gdprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_idx); > > Along the lines of earlier remarks: What value does "is passed" add? Probably not too much sense. I will drop it. > >> +static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, >> + uint32_t value) >> +{ >> + const struct domain *currd = curr->domain; >> + unsigned int offset = addr & APLIC_CTRL_REGION_OFFSET_MASK; >> + >> + ASSERT(curr == current); >> + >> + switch ( offset ) >> + { >> + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: >> + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: >> + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: >> + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: >> + { >> + unsigned int word_idx = >> + regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); >> + >> + value &= generate_auth_mask(currd, word_idx); >> + >> + break; >> + } >> + >> + case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: >> + if ( value & APLIC_SOURCECFG_D ) >> + { >> + dprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); > > gdprintk()? Agree, it would be better to be gdprintk() here. > >> + goto fail; >> + } >> + >> + /* >> + * As sourcecfg register starts from 1: >> + * 0x0000 domaincfg >> + * 0x0004 sourcecfg[1] >> + * 0x0008 sourcecfg[2] >> + * ... >> + * 0x0FFC sourcecfg[1023] >> + * It is necessary to calculate an interrupt number by subtracting >> + * APLIC_DOMAINCFG instead of APLIC_SOURCECFG_BASE. >> + */ >> + if ( !AUTH_IRQ_BIT(currd, >> + regoffset_to_word_idx(offset - APLIC_DOMAINCFG)) ) >> + /* Interrupt not enabled, ignore it */ >> + return true; >> + >> + if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW ) >> + { >> + gdprintk(XENLOG_ERR, >> + "value(%#x) is incorrect for sourcecfg register\n", >> + value); >> + >> + return true; >> + } >> + >> + break; >> + >> + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); >> + struct vcpu *target_vcpu; > > This, btw, is a case where I think not using "v" is warranted. > >> + unsigned int guest_hart_idx = MASK_EXTR(value, APLIC_TARGET_HART_IDX); >> + /* >> + * Look at vaplic_emulate_load() for explanation why APLIC_GENMSI is >> + * subtracted. >> + */ >> + unsigned int srcn = regoffset_to_word_idx(offset - APLIC_GENMSI); >> + >> + if ( !AUTH_IRQ_BIT(currd, srcn) ) >> + /* Interrupt not enabled, ignore it */ >> + return true; >> + >> + target_vcpu = domain_vcpu(currd, guest_hart_idx); >> + >> + if ( !target_vcpu ) >> + { >> + dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n"); >> + >> + /* Ignore such writings */ >> + return true; >> + } >> + >> + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) >> + { >> + /* >> + * A non-zero guest index asks for delivery to an interrupt file of >> + * nested guest. The vIMSIC node has no riscv,guest-index-bits >> + * property, so a guest is told its harts have no guest interrupt >> + * files and the field is read-only zero for them. The write isn't >> + * rejected (that would throw away a valid hart index and EIID); >> + * instead the field is dropped, which is also what >> + * aplic_msi_target_gen() does with it when programming the h/w. >> + */ >> + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) >> + { >> + printk_once(XENLOG_WARNING >> + "%pd: vAPLIC target guest index != 0 is unsupported\n", >> + currd); >> + >> + /* Ignore such writes ... */ >> + return true; >> + } >> + >> + write_atomic(&vaplic->regs.target[srcn], value); >> + >> + value = aplic_msi_target_gen(target_vcpu, value); >> + } >> + else >> + { >> + /* >> + * IPRIO is WARL and zero isn't a legal value for it, so normalize >> + * it once: the guest then reads back exactly what it gets. >> + */ > > What is "reads back exactly what it gets" supposed to express? The use of > "once" there also isn't quite clear to me. "once" meant the substitution is done in a single place (before the value is stored) so nothing has to be adjusted again on the read path; "reads back exactly what it gets" meant the shadow copy holds the same legal priority that is programmed into the hardware, not the zero the guest wrote. I will re-word the comment to: /* * IPRIO is WARL and zero isn't a legal value for it, so a write * of zero is replaced by APLIC_TARGET_IPRIO_DEFAULT. This is done * before the value is stored, so the guest-visible copy and what * is programmed into the h/w hold the same legal priority and no * fix-up is needed when the guest reads the register back. */ > >> + unsigned int iprio = MASK_EXTR(value, APLIC_TARGET_IPRIO) ?: >> + APLIC_TARGET_IPRIO_DEFAULT; >> + unsigned long h = cpuid_to_hartid(guest_hart_idx); >> + >> + value = MASK_INSR(guest_hart_idx, APLIC_TARGET_HART_IDX) | >> + MASK_INSR(iprio, APLIC_TARGET_IPRIO); >> + >> + write_atomic(&vaplic->regs.target[srcn], value); >> + >> + value = MASK_INSR(h, APLIC_TARGET_HART_IDX) | >> + MASK_INSR(iprio, APLIC_TARGET_IPRIO); >> + } >> + >> + break; >> + } >> + >> + case APLIC_SETIPNUM: >> + case APLIC_SETIPNUM_LE: >> + case APLIC_CLRIPNUM: >> + case APLIC_SETIENUM: >> + case APLIC_CLRIENUM: >> + if ( !value || !AUTH_IRQ_BIT(currd, value) ) >> + return true; >> + >> + break; >> + >> + case APLIC_DOMAINCFG: >> + { >> + struct vaplic *vaplic = to_vaplic(currd); >> + >> + vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO | >> + (value & APLIC_DOMAINCFG_WMASK); >> + >> + return true; >> + } > > May I suggest that you arrange case blocks (primarily) by offset? This would > then mean for DOMAINCFG handling to move to the top, helping at least a little > with SOURCECFG_{BASE,LAST} handling (slightly oddly) using APLIC_DOMAINCFG. I will do that. > >> @@ -122,7 +447,29 @@ int domain_vaplic_init(struct domain *d) >> */ >> d->arch.vintc->nr_virqs = guest_aplic_num_sources + 1; >> >> - return 0; >> + /* Slot 0 is unused: APLIC source numbering starts at 1 (see used_irqs). */ >> + vaplic->regs.target = xvzalloc_array(uint32_t, d->arch.vintc->nr_virqs); >> + if ( !vaplic->regs.target ) >> + { >> + d->arch.vintc = NULL; >> + xvfree(vaplic); >> + >> + return -ENOMEM; >> + } >> + >> + vaplic->regs_start = GUEST_APLIC_S_BASE; >> + vaplic->regs_size = APLIC_SIZE(d->max_vcpus); >> + >> + rc = register_mmio_handler(d, &vaplic_mmio_ops, >> + vaplic->regs_start, vaplic->regs_size); >> + if ( rc ) >> + { >> + d->arch.vintc = NULL; >> + xvfree(vaplic->regs.target); >> + xvfree(vaplic); >> + } > > Could you perhaps arrange for it to be possible to simply call > domain_vaplic_deinit() here (and maybe also on at least some of the earlier > error paths)? The code above loks very similar to ... > >> @@ -134,5 +481,6 @@ void domain_vaplic_deinit(struct domain *d) >> >> vaplic = to_vaplic(d); >> d->arch.vintc = NULL; >> + xvfree(vaplic->regs.target); >> xvfree(vaplic); >> } > > ... what's here. Agree, domain_vaplic_deinit() could be used instead of open-coding when recieved rc is handled from register_mmio_handler() and error path above. Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 10 10:59:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 10:59:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414428.1644228 (Exim 4.92) (envelope-from ) id 1x4cVB-00055R-Nn; Thu, 10 Sep 2026 10:59:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414428.1644228; Thu, 10 Sep 2026 10:59:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4cVB-00055K-LA; Thu, 10 Sep 2026 10:59:33 +0000 Received: by outflank-mailman (input) for mailman id 1414428; Thu, 10 Sep 2026 10:59:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4cVA-00055E-CD for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 10:59:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4cV9-002JFT-6A for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 12:59:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa28d8a-2eae-0a2a0a5409dd-0a2a4503827a-42 for ; Thu, 10 Sep 2026 12:59:31 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa28d92-fae8-0a2a45030019-4a7de48cb08c-3 for ; Thu, 10 Sep 2026 12:59:30 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254fa663bfso246516366b.1 for ; Thu, 10 Sep 2026 03:59:30 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c260d4a98efsm914196766b.14.2026.09.10.03.59.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 03:59:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789037970; x=1789642770; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=GzF0hWwqUwZEdjHGiY5HXumqIinPxR0gbzSyfXGV5Lk=; b=li5tlNihl9LHdWhI8h1P2bpTNEPvqrHhntSjKQPpAlSma/ugMeCG3hXkWBGh/tBqKD tbZDU0TnSjyf8N68SK8wR9FrI3JbvIPcMPut5fPhZPCyy6iyk2IaH7wyDYASee2Qe77S uUDc/JcB6DR91n5CuMJ2/a1M9iv+3DFBAbIKGUXQousL4fejDsZYzB3PPFRa+ses0dKL HaApD6axxCvLzfqJbMKTWMphz4Qz1H5KrpCVp7rp8urZODfA+pMK1kK28c+KwhXan+3+ K5B8Bm3qynAfyLo8clsGBJU0bCvHu8CXliI6w5wu/RY733qhg9tHm3aLuI9+Hr1pbILu H6wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789037970; x=1789642770; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=GzF0hWwqUwZEdjHGiY5HXumqIinPxR0gbzSyfXGV5Lk=; b=Uj5xAWIYPqAWhTgBW7fEWkl2pr4VAGIw/YP9yZnS4R3sviRNvIUdJ8q8xaLOwUN3zj k0xcpxkoO2rOcp0HhApS7xi+3B4PfoUMBQarM9+ehOUfXFzlc2rOGkxwPYRteDZIsb+i ONApvpLkv/cLLmsrcPAV03XQBpEiTuJUUdF40HtOojz5fSsVpTGu8ZMNUHU6VBV4KMHD PVQxUL2OgSfFitahfWH0ernQzCixmDtxvx8yfonBMM+P+scqZYg2/r+yKDt61XNjEUbW K4tOMMux0J5r/mI45WNvoD+qLK+QBaafLA2RaJDviJqDnWqkETseflQq7UCbn8yf/7pN q1pw== X-Forwarded-Encrypted: i=1; AKwUvByE+hymD7shfW+mmEpkU8de/zRmupCaKcQR0cUUJkxs0GZSETElKCPLeJjv+q88dU31iLVPox7Uzx4=@lists.xenproject.org X-Gm-Message-State: AFuF++llo+5kHz4x8ksZWSVzvCFyCyPW5Pzva6DgsAmUNOyrJiEyw5iu XhmhpJVXl2oPFygOGz17uEu2LcQmbBoVkhyfY6+YpJKIp2wtDGJ6Az7Y X-Gm-Gg: AYBFou2tFXibYyL8Cx6ABzAsp2mOnYDzbAYkIYOFgAU6Ebq+p2gIuo9QYXZtnTxkPYO Fk0+zTn27Ds0BSO+VnOTnVzOasnghVnhNdjxQRO4pBpYdvTyU1jKAcqb0UjzBmaiCHzocKI1NT0 PMRnjklO4KB6JCDVw3foycl2qQTQ1DgtSAY7JOv0oUUfuGy14WItn7EI1cGoxM96/wfjH58ZuJA QAUupkibS8415t/5wQcRqGUpIIcCUk6/nVpqkT+iiqJjY5wvbYI6UwhxqSTnYRJnWxq53U67TFK dcHP+Do6yvzarBhSK4AvA5iCNYDkWXsHUN1XrIcFB4Kzc+BeDh/yChCAKomK8QjK22bCcYnXviN Q3xn3FGmVVDh+yv+AondEEHhwoIOjM2/OlANURAfgryesN6VlWJFRhDSWHnr5P8bsuy19O6Wker btT/YfV/wIXNgKqPLeImEuD5QVVqRh1slOS8hr5fHbU9LrPDfyzasnjnDlTGWKRVTV7tpetOV3W QLTv5+O1yXn9EYtBwIFulH3DRUTYTrqcw== X-Received: by 2002:a17:907:728f:b0:c25:362e:fb8b with SMTP id a640c23a62f3a-c29419f9643mr611700866b.7.1789037970246; Thu, 10 Sep 2026 03:59:30 -0700 (PDT) Message-ID: <487a7efa-e83d-4ae2-8f39-33483161a64d@gmail.com> Date: Thu, 10 Sep 2026 12:59:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789037970-6CCDB4E9-020F4BF4/10/73395122804 X-purgate-type: spam X-purgate-size: 2248 On 9/9/26 4:52 PM, Jan Beulich wrote: > On 27.08.2026 17:20, Oleksii Kurochko wrote: >> @@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask >> >> ASSERT(spin_is_locked(&desc->lock)); >> >> - cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask)); >> - hhxw = imsic->group_index_bits; >> - lhxw = imsic->hart_index_bits; >> - /* >> - * Although this variable is used only once in the calculation of >> - * group_index, and it might seem that hhxs could be defined as: >> - * hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT; >> - * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted >> - * when calculating the group index. >> - * It was done intentionally this way to follow the formula from >> - * the AIA specification for calculating the MSI address. >> - */ >> - hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; >> - base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT; >> - >> - /* Update hart and EEID in the target register */ >> - group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) & >> - (BIT(hhxw, UL) - 1); >> - value = desc->irq; > > Hmm, only after sending the ack I noticed that there's no masking here, ... > >> - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; >> - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); >> + cpu = aplic_get_cpu_from_mask(mask); >> + >> + /* Update hart index and EIID in the target register */ >> + value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >> + (desc->irq & APLIC_TARGET_EIID); > > ... but there is masking here. Chopping off bits doesn't look as if it can > lead to anything good. What's the deal here? The mask is a no-op: desc->irq < NR_IRQS (1024) always fits the 11-bit EIID field, so I'll drop it and add a BUILD_BUG_ON() instead. Would it be better to: + /* desc->irq < NR_IRQS, so it always fits the EIID field */ + BUILD_BUG_ON(NR_IRQS - 1 > APLIC_TARGET_EIID); + + value = MASK_INSR(aplic_hart_index(cpu), APLIC_TARGET_HART_IDX) | desc->irq; ? Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 10 11:14:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 11:14:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414449.1644250 (Exim 4.92) (envelope-from ) id 1x4cjP-0008FH-05; Thu, 10 Sep 2026 11:14:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414449.1644250; Thu, 10 Sep 2026 11:14:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4cjO-0008FA-SY; Thu, 10 Sep 2026 11:14:14 +0000 Received: by outflank-mailman (input) for mailman id 1414449; Thu, 10 Sep 2026 11:14:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4cjO-0008F4-21 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:14:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4cjN-00AUOK-Er for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:14:13 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa29103-e002-0a2a0a5209dd-0a2a450abf68-10 for ; Thu, 10 Sep 2026 13:14:13 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa29105-f2d2-0a2a450a0019-d155dd30d905-3 for ; Thu, 10 Sep 2026 13:14:13 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-485850cf499so4934416f8f.3 for ; Thu, 10 Sep 2026 04:14:13 -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 ffacd0b85a97d-485aa2c9acasm14609400f8f.36.2026.09.10.04.14.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 04:14:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789038853; x=1789643653; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=z99gJD+4P3UGzaQaOpYwFdUWyOKXoViqFl639x5XqwI=; b=DZ2cemw0hmrdnOjzWMJ+drHpeg0hfQFO/0/TMmPAy1GkbUjI8s5Kz3WzXbcgEIOstb ekFcrFJfS0Kbri+SgQSMTSttBBiAVIAGfjJKt+HLtU92k7OIp+13maY2r2l9NYxCGT5k rjytgFUBWFj2TGU1wpb+vUGOSun4MzrcRuXcWPTwceolA28zHiV7KKQxvjN+Pk37BoVv vD45IXy6iYpXGDiavELa/TXCw+BhN9LWzpJUqltF+AhwEF3c5SEFZK1aK/capXXKVcFn yU240niCCRMnZgsDLCa9iEtNl7j4a/bM6VP1jYEbayea/a/NvyHI+QurFYB3/RKUgZH0 YvUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789038853; x=1789643653; h=content-transfer-encoding:content-type: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:content-type; bh=z99gJD+4P3UGzaQaOpYwFdUWyOKXoViqFl639x5XqwI=; b=Ml+xPnKTKywh5cbTwSZNv4rW2sE6ZTljGDOfvSH+foBQDGmjR72pnag7riFptCUvL/ ATPi8+mYWGXI6c2KvOX66cCq/T/n62xYmsHgconcXwzmGCiEq5456dW/UuIFVcJ/9xB0 RFxAbVaju5Si1kDhg8//eS2f6A8L1zEEkDWsQ97Uc/HmUHChn+8nrl8dq2iqX+Iixzmh gLvT6i1pdReuB5T83CFkqA8KYmtvBXIYfljblSDLsQij3z/P66lJfEqftfI93N45rQ5u aY6Rzc/ixi9RvXmF8kPSdTGcfduu+PP1OIKlfrqGLEyvxlS6lEszdDUxD2T2Z36kCWcT Upbg== X-Forwarded-Encrypted: i=1; AKwUvBwcp5XwGS95leNTfH67Ytniqv3sxniq8BijPvsR5XEHejzjD/+/p0ime4nzz7eGQ4eIUgReDUL7Gig=@lists.xenproject.org X-Gm-Message-State: AFuF++klchZXsMsUocvr3lLjT2Lj6WEBCrX8mmTvcGkmWFTKfYmMTv0L vaOSUs4jUZoWNylgqoXJRPjrVHjF0VFgS2DUZV4CWVSvBVA3Y+00seoxSQ5W0WB9yQ== X-Gm-Gg: AYBFou2dU68KB2wFzH1U5mzt2UUR0BiSYeabeZ79c/d+vDX4u4tI8x2ZVCINh+zszpO cg9GBZWq4eOXMDIAjNEQIDBRXPX8cxl3Yl5NqCy04x8cPzvHsEGFhfJrPLgnfD1Eq8UTEuN0eDA ITs9CmXoXa1LxKszTygwPruCa9PQ7wBeKEGsJg67eVyliAVwEx2CCWX4JYaWxWRtqLp7lmWFoHb ZLCkDTO5j8twwfoOhmOxs7/KsDvdeiIENyqFvx7t+dZYRnzViCvyitOkMudPX0yvLBul7QZ9mdL LPjVrnttjisFa0y7HuFBrYsJ8Ua4U+7UnylyBn7dwfkLfOtwgvJWNXB26IP/L3UMi4VIAguYPAI VGoEx5MkRWGhHp4NCkCDi9QfywCxA1yhrQUZaUcV64N8MXX+WuyxIV4JxQ4JTMOnVDM8qEp3w4W MkIO5G9R4SRwUyng3bIzMWG+fZID7fw0FLT6+LYFwHbUiADYgkZfZTWjrWHH2LITgfXj2IXRp+2 OyIw/mZk1uXQhbKZCPpawgqMAE8ulaBGKMYpIKna2jyjnQ/iQT2zNNQxCUvCfk= X-Received: by 2002:a05:6000:46c6:b0:485:8edf:8354 with SMTP id ffacd0b85a97d-4858edf846cmr26246781f8f.43.1789038852530; Thu, 10 Sep 2026 04:14:12 -0700 (PDT) Message-ID: <48857983-ac79-44a0-8a11-93f62ac3d0c4@suse.com> Date: Thu, 10 Sep 2026 13:14:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> <68ab5241-7301-4988-9420-bcccc4b16e3d@suse.com> <071ed630-4c72-4df1-b15e-3037e3f076ba@gmail.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: <071ed630-4c72-4df1-b15e-3037e3f076ba@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789038853-583CCCFC-1C14FD73/0/0 X-purgate-type: clean X-purgate-size: 2245 On 10.09.2026 12:37, Oleksii Kurochko wrote: > On 9/9/26 4:26 PM, Jan Beulich wrote: >> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, >>> + uint32_t base_val) >>> +{ >>> + unsigned int guest_id = vcpu_guest_file_id(target_vcpu); >>> + unsigned long hart_field = aplic_hart_field(target_vcpu->processor); >> >> What guarantees target_vcpu's ->processor field to be meaningful at this >> point? > > Good question. Considering the places where it is called, I would expect > target_vcpu->processor to have something meaningful, since it is called > from a place that can only be reached when the guest is running. > > Even without that, I don't think there is a big issue here, as > ->processor is initialized to 0 at allocation time. This means that the > target register will be configured in such a way that CPU 0 will handle > such IRQs. I may not have been explicit enough then: Whether the guest (as a whole) is running is of no interest. If the specific vCPU is running, all is fine. If the specific vCPU is in the process of being moved to a different CPU, and if you read ->processor just before the new value is put there, is all going to be fine as well? I doubt that. >>> --- a/xen/arch/riscv/include/asm/vaplic.h >>> +++ b/xen/arch/riscv/include/asm/vaplic.h >>> @@ -21,11 +21,16 @@ struct domain; >>> >>> struct vaplic_regs { >>> uint32_t domaincfg; >>> + >>> + uint32_t *target; >>> }; >> >> A pointer in this structure is odd, as this (supposedly) is a set of >> guest register values. The field name also doesn't clarify its purpose. >> All in all: Likely a comment is needed here. > > It is a pointer because I tried to save some memory and allocate > register target based on how many irqs a guest really needed. > > As an option I can allocate that statically and use the value from AIA > spec: target[1]-target[1023]. Would it better? No, I think dynamic allocation is justified here. (Question is whether it should be struct vaplic_regs as a whole, but that depends on whether another runtime-sized array may need adding to it later on.) Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 11:23:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 11:23:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414467.1644269 (Exim 4.92) (envelope-from ) id 1x4csV-0001j9-1q; Thu, 10 Sep 2026 11:23:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414467.1644269; Thu, 10 Sep 2026 11:23:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4csU-0001j2-U4; Thu, 10 Sep 2026 11:23:38 +0000 Received: by outflank-mailman (input) for mailman id 1414467; Thu, 10 Sep 2026 11:23:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4csT-0001WZ-Q5 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:23:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4csT-00AgT7-71 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:23:37 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa29325-bab6-0a2a0a5309dd-0a2a450bc3f8-48 for ; Thu, 10 Sep 2026 13:23:37 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa29338-b7e8-0a2a450b0019-d155802ec939-3 for ; Thu, 10 Sep 2026 13:23:37 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49ccfbe062eso68894135e9.3 for ; Thu, 10 Sep 2026 04:23:37 -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-49d20db6e76sm139757835e9.3.2026.09.10.04.23.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 04:23:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789039416; x=1789644216; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=24+juqDvlaemBTdDhWERMpb87Bbadn66B3z4bW688S8=; b=GQDDIvddstpcwbDQY+zzbuWmpFiLC8ySqIV+A56bTXMS/o/SnxB4/YXqF0lhNbBTLO d5BXsdgh5Bt2p24gI8AdE9jmhouBs4Mrj8FNipIJsbTWXnF16Hd7LdbuXZH8fbM5HueN 2UgIPBop3z2kyepPACzvSZthuPIV+Jd5iO0BRKIh2JC7FyZtP5jbOfJ7P+UhmB6a9THk Hu5wNUbt+X69xVsmz4UWEl3KASYy+4N8ChKOSbdXPgbLJ5FJmfAKB6pBdJqVr+buGE1T m+SYtRKOJgqshUv4j82zi1osKxb5HHAV/w/f7s+jqDYzXlLYFBCIp1Qr3mfTXUYYKNPq M3qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789039416; x=1789644216; h=content-transfer-encoding:content-type: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:content-type; bh=24+juqDvlaemBTdDhWERMpb87Bbadn66B3z4bW688S8=; b=PspC+zJqRkHzV1Qsh2rXe1y32/e7U30U2c9qRMCMj+2fZR8+AyNZgXrCYzxWhzvN18 M84C4XLOWlaDQNvwTHpkrGUJ4cCo7OxJxZdugtOAAM9Eiugvwc76Frb1Wl8pnR49/V7b VJzG3rra0az4kVU5tYwCN0CPsnBNyz3D6QXiGMhaVHXgcVsS8s7o4KGGiQsyFwYZhLek f0u8f+7QVWBfMnH0dhaw2Pj9i3tLxmqzejE1GASShQnLUBzfcQRzfBFIGzNgzBv0Dbfd eocJwigI2kwURxWUrNOIb78KHavcwJtUBzaa66MlondlbkBO5igpqZvzymV6wAMG58Un pT3w== X-Forwarded-Encrypted: i=1; AKwUvBwkLbX0E5aR5ngj9Q1QvsZ+e8TrD9KabvOR7niZUN3ZdeIYB9Vx/ZPFTEBSrn0E5MTov5nwCqpmQvw=@lists.xenproject.org X-Gm-Message-State: AFuF++mDO5/lpe5MG2hTx7LQHRfXEH5YdUm/UAvc06TIhoCXCCJLaBhx 3tlqOEdzHEIGiu0h4zaFDdWMW4ZPwM9z1PPc1HmMxlcDB6n4divuDEBpnfJGYwlGwA== X-Gm-Gg: AYBFou0f8b9YIh/Mi5mqMyaLz4mr/40MqzqZFuYLgM2JsA9S5G47Lq7XVczrg24O5FW rM043ZKZ43E1D+GqT+S24I277kihN+D21sswDZSQKPoLuq+Jv7aqzAQz7D9GHwwV1EB2SEyn47D WyalM+uLarvSoEhaynm+0u45MMC/1pbCO0fqZi9tv9PZ52wRzVFRyi7WM5XgbdXlo/s4gPLDw1g H8bPNpxFxxz76USHoS6WoFLvrTKaV4OMVfWxuyuYBwm3Bx64yttWoaCZQo2d4cSz4Lovq9StMd+ 2zWpN/pgmJ0FmZkIzW2SFwRxhsqXr0mz01uL2DQtkT2Kajh/jMS/uPDxX5GvHoAGjESTGVIMKzP hrlI4yqDw2RA2/QWmwBrB2NeIYx8tq9/wsZCvxF1YaTjvMsq+PLq+kG9Ee3dCBvsAbK4I0mkbVR +2Gi55xNH1gNcjlxRwZCvRM56YMV8qYXJGETmBp5O9zMUUdSNdSVspjEfzI5undOwOdBgiLjqTE ddFqFPFiGd0Fkc0Ihn0rQHViojQjJ1OexaQEL5IWKlhzh5xhnvi6uPIKFV4W98= X-Received: by 2002:a05:600c:4e8f:b0:49c:fa20:cbfc with SMTP id 5b1f17b1804b1-49cfa20cd1fmr371007435e9.19.1789039416561; Thu, 10 Sep 2026 04:23:36 -0700 (PDT) Message-ID: <8a133a0d-09ff-4908-b0b1-7396045b5e67@suse.com> Date: Thu, 10 Sep 2026 13:23:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> <487a7efa-e83d-4ae2-8f39-33483161a64d@gmail.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: <487a7efa-e83d-4ae2-8f39-33483161a64d@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789039417-AB6D29EA-5BB76DA8/0/0 X-purgate-type: clean X-purgate-size: 2671 On 10.09.2026 12:59, Oleksii Kurochko wrote: > On 9/9/26 4:52 PM, Jan Beulich wrote: >> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>> @@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask >>> >>> ASSERT(spin_is_locked(&desc->lock)); >>> >>> - cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask)); >>> - hhxw = imsic->group_index_bits; >>> - lhxw = imsic->hart_index_bits; >>> - /* >>> - * Although this variable is used only once in the calculation of >>> - * group_index, and it might seem that hhxs could be defined as: >>> - * hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT; >>> - * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted >>> - * when calculating the group index. >>> - * It was done intentionally this way to follow the formula from >>> - * the AIA specification for calculating the MSI address. >>> - */ >>> - hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; >>> - base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT; >>> - >>> - /* Update hart and EEID in the target register */ >>> - group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) & >>> - (BIT(hhxw, UL) - 1); >>> - value = desc->irq; >> >> Hmm, only after sending the ack I noticed that there's no masking here, ... >> >>> - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; >>> - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); >>> + cpu = aplic_get_cpu_from_mask(mask); >>> + >>> + /* Update hart index and EIID in the target register */ >>> + value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >>> + (desc->irq & APLIC_TARGET_EIID); >> >> ... but there is masking here. Chopping off bits doesn't look as if it can >> lead to anything good. What's the deal here? > > The mask is a no-op: desc->irq < NR_IRQS (1024) always fits the 11-bit > EIID field, so I'll drop it and add a BUILD_BUG_ON() instead. > > Would it be better to: > > + /* desc->irq < NR_IRQS, so it always fits the EIID field */ > + BUILD_BUG_ON(NR_IRQS - 1 > APLIC_TARGET_EIID); If the question is whether to prefer BUILD_BUG_ON() over BUG_ON(), then: Yes please. However, APLIC_TARGET_EIID is a mask (despite its name not indicating that), which only happens to start at bit 0. This kind of assumption would better be avoided. This raises another question though: No matter how big a RISC-V system is, it can only ever have 1k IRQs? How does that work with a single MSI-X device having up to 2k MSIs? Jan Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 11:23:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 11:23:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414466.1644259 (Exim 4.92) (envelope-from ) id 1x4csT-0001Wh-QS; Thu, 10 Sep 2026 11:23:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414466.1644259; Thu, 10 Sep 2026 11:23:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4csT-0001Wa-Nf; Thu, 10 Sep 2026 11:23:37 +0000 Received: by outflank-mailman (input) for mailman id 1414466; Thu, 10 Sep 2026 11:23:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4csS-0001WT-OC for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:23:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4csS-00AW6I-4q for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:23:36 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa29331-2eae-0a2a0a5409dd-0a2a4502c286-24 for ; Thu, 10 Sep 2026 13:23:36 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa29337-6ca4-0a2a45020019-4a7de18c9065-3 for ; Thu, 10 Sep 2026 13:23:36 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cc9f581c4so11676275e9.0 for ; Thu, 10 Sep 2026 04:23:35 -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-49d20db6e76sm139757835e9.3.2026.09.10.04.23.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 04:23:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789039415; x=1789644215; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=24+juqDvlaemBTdDhWERMpb87Bbadn66B3z4bW688S8=; b=fZRwn+xidaWh9HRmOeOiiEgF9HjoIHaD0XYtIVW8seJp32ggXWK+EJ0gSaBgG2Qccs /jXtqmlF/cwNJGtFhQXqSMf6+UodhhGO38/P3MHC9cPrRhIxJ3G36SOTkJOx11IgAJZC Ay8muAXn8DNhM55u2L8PuwY0B7x9SDa43LfrhMhptuHw7Xat1GQsk2+HjpoJyoQuRBig RgAS/wxUB6xrukafjBzVLes54WqNL7vhkqdrAxeopbCl1kMTQC16ZuJOnO/2lCHPGbTZ pzL8v/3407khzTY4qJ5g8RYvTLeAhdFku+HCruvxtONZWka/gQsG/VL+G119duoU5jhl OvKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789039415; x=1789644215; h=content-transfer-encoding:content-type: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:content-type; bh=24+juqDvlaemBTdDhWERMpb87Bbadn66B3z4bW688S8=; b=azSJnnqxVNrxNxYX9/aXq7p1WDQfu4LNU63Yt3iGNWhVNbtuXqU5AcAUzD/ux61fjP QsxNsQCCKGDQ8Pa9nyPpwK35fyIHLKaWXRwvhNDxCowBapKefcruJ3dyShOC5Awuo45m y8cZzY2L+qvSeOc1YOK0/v2Ivbl+TSGmUshaWM0yJlKQUjfHN/7W3yQwaLum6yeTckZB jlnWJy9YIlQYk9r0QGqcyZ3rvsZ6HZfeZQJjGYPbB9+hhq5LqYwlUkzX0XM5bFUGKzVs 60hHffX6S0nOUU5Ko5BrluTUe2GA5pOsHZjHXiN4Pyvg0Mfjk/PdZA4L2wSa5xR6vtuk HlWg== X-Forwarded-Encrypted: i=1; AKwUvBxSQfLM+pSBsWwLDQqdhFvHYWEK5ShcoHf624hzCUPw5bLsuHTN3WmCzhjO/iPfStbZzze/7e89Kjc=@lists.xenproject.org X-Gm-Message-State: AFuF++nuxF9Pi77SI6pKbvHL2pVFWoJihT/fh0zMFz+Vjg3Q+265DQP9 Jh75WMnxVBJircuKHiKJ8Uk3/dEXy1SKY8Nm9UTpNQaYurRT49yUJU2h7u7JW0jIhg== X-Gm-Gg: AYBFou2Zas6637nMpyZScXoax0MuOeJ61HpaiFapH/WHA6W0v1avZQMJYWWSSJ55YRG BVYm6JYnuH7ZMAJ9f03LlOc33haF9sUgC8uivfF92vJUi7y7jGqohnzkD9LI4jF34pSuk1qjG1C wkoosoBK14uu1sP4/KBqQOJz4teSn7lpWP4sK3BLLJwcRLb5VJKqq3/GltPTyR3pbXisQYy+5w4 3M0ztRmNueOObP7Ye3QFfwRPyKkf6UGxVJR+bQE4WuIq0QamPZ/vqqtIzWFfRt3xmou9Ey23+5E rwUhuYl0sewtCBnjZ3RVsQjPAsAQ7BIZwCsGhu3/531MwR4yPBVpIoPBXUXV1NJ2elh7tGygwQ8 tBLFBQTMeAz115S5bhKvHYCuem+9qzx3YWwKeCbt7lxwKJI5PVkyxP9zfpyZfWp0YlYPoHbiWCh j/8hLALRatm1PleTcijV9sJbJPg7QWwrTgF0yJZYyGYAMN0Gx2Te40nYLSzIKQ+6O8RZtdDrkrT vA/LaYQNyHy4JztjvKDE6VMD3BDbAieR+hsATpe/AGVAJqg9WtKB4IzQXrTnB4= X-Received: by 2002:a05:600c:4fcb:b0:49c:f13e:e4c with SMTP id 5b1f17b1804b1-49d26db4274mr43955165e9.9.1789039415489; Thu, 10 Sep 2026 04:23:35 -0700 (PDT) Message-ID: <9f2245d8-faef-4608-a179-b8e942fdfc1d@suse.com> Date: Thu, 10 Sep 2026 13:23:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> <487a7efa-e83d-4ae2-8f39-33483161a64d@gmail.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: <487a7efa-e83d-4ae2-8f39-33483161a64d@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789039416-F34BE2AC-CCA6E352/0/0 X-purgate-type: clean X-purgate-size: 2671 On 10.09.2026 12:59, Oleksii Kurochko wrote: > On 9/9/26 4:52 PM, Jan Beulich wrote: >> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>> @@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask >>> >>> ASSERT(spin_is_locked(&desc->lock)); >>> >>> - cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask)); >>> - hhxw = imsic->group_index_bits; >>> - lhxw = imsic->hart_index_bits; >>> - /* >>> - * Although this variable is used only once in the calculation of >>> - * group_index, and it might seem that hhxs could be defined as: >>> - * hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT; >>> - * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted >>> - * when calculating the group index. >>> - * It was done intentionally this way to follow the formula from >>> - * the AIA specification for calculating the MSI address. >>> - */ >>> - hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; >>> - base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT; >>> - >>> - /* Update hart and EEID in the target register */ >>> - group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) & >>> - (BIT(hhxw, UL) - 1); >>> - value = desc->irq; >> >> Hmm, only after sending the ack I noticed that there's no masking here, ... >> >>> - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; >>> - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); >>> + cpu = aplic_get_cpu_from_mask(mask); >>> + >>> + /* Update hart index and EIID in the target register */ >>> + value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >>> + (desc->irq & APLIC_TARGET_EIID); >> >> ... but there is masking here. Chopping off bits doesn't look as if it can >> lead to anything good. What's the deal here? > > The mask is a no-op: desc->irq < NR_IRQS (1024) always fits the 11-bit > EIID field, so I'll drop it and add a BUILD_BUG_ON() instead. > > Would it be better to: > > + /* desc->irq < NR_IRQS, so it always fits the EIID field */ > + BUILD_BUG_ON(NR_IRQS - 1 > APLIC_TARGET_EIID); If the question is whether to prefer BUILD_BUG_ON() over BUG_ON(), then: Yes please. However, APLIC_TARGET_EIID is a mask (despite its name not indicating that), which only happens to start at bit 0. This kind of assumption would better be avoided. This raises another question though: No matter how big a RISC-V system is, it can only ever have 1k IRQs? How does that work with a single MSI-X device having up to 2k MSIs? Jan Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 11:28:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 11:28:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414490.1644276 (Exim 4.92) (envelope-from ) id 1x4cxF-0002jV-Kj; Thu, 10 Sep 2026 11:28:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414490.1644276; Thu, 10 Sep 2026 11:28:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4cxF-0002jO-IC; Thu, 10 Sep 2026 11:28:33 +0000 Received: by outflank-mailman (input) for mailman id 1414490; Thu, 10 Sep 2026 11:28:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4cxD-0002jI-SW for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:28:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4cxD-00AhaB-9H for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:28:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2944b-8faa-0a2a0a5109dd-0a2a450397dc-24 for ; Thu, 10 Sep 2026 13:28:31 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2945e-fae8-0a2a45030019-b9ff1c12a981-3 for ; Thu, 10 Sep 2026 13:28:31 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08b1386b2000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 11:28:27 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 0F6FE8156D; Thu, 10 Sep 2026 13:28:27 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=I4Li6FhKtorbwIWPyH8ZyalImdF8M9BzbYf7VNRwv9o=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=a0YKJ++QNFlFswNyM6cncRa23wsrIRukkZQpOsJKiRjl/a7+Q3ftumqkR2AtxNOKYXXZyVrMg r885NvwunyIZm3dgKdeoFczre8Y53zYyFuLE/56Qiz4cH/x9UT1fxylqZi2UHCHhIRGlshnA5Yv 8tRnafdNnGwzkCWQ7SUDyO1HT+TeJC6AyzUh/elaI0TnOqBKZL8YbWsfPDtBf0IAr9tlMMuodBF J5VPJnm+ynvR/WBEd0mPeSSCROCdzLnLVawRHIztPqRk/kSwBPKb+pt/7Lxc/Oh7lUEs/S76DA/ FBigID6sgOGIs7t6LT7v9F3ynkiB9SexelsoOURab4Ig== X-Zone-Loop: 4d7ad702b346e774ec6552b5990cff06fbffeeda7521 x-campaign-type: default x-transaction-id: f52020f1-7f11-401e-9c81-be300d2a6c59 x-swg-uid: 01-b839829c-995c-4b2d-84ad-edaf151487e5 X-Mailer: Sweego Message-ID: <1789039707.8631fc262581453bbf619ec5b2062170.1a08b1386b2000c4f3@vates.tech> x-swg-bid: 1789039707.8631fc262581453bbf619ec5b2062170.1a08b1386b2000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 2/6] automation/qtb: add jinja2 device trees for riscv64 smoke tests From: Baptiste Le Duc To: Zhang Zheng Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini In-Reply-To: References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech> Date: Thu, 10 Sep 2026 13:28:21 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789039706; l=8250; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=umiA2R5QkSvo3bjwmrRFzVkxUevYKAh7dagfyF5M/mk=; b=Xz70Wnw4vTzJfUExQsvlCM8y3bOhq7mXe2Hvkpwjnj0podZMe9z4cvbg5eyyxOg02gGMmd5uJ Aw6bHa1qC2rBOZ0BzKcjteuHYsGNjH9lzAUdIaTGxkPiv9lHrc3/pJ5 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789039707155 X-purgate-ID: tlsNG-33051d/1789039711-6EACC4E9-A632833F/0/0 X-purgate-type: clean X-purgate-size: 8254 On 2026-09-10 18:00 +0800, Zhang Zheng wrote: > On Thu, Aug 27, 2026 at 11:42:48AM +0200, Baptiste Le Duc wrote: > > The dom0less RISC-V smoke tests need a host device tree describing the > > platform (CPUs, APLIC/IMSIC, uart). It varies per machine (hart count, MMU > > type), so a single static .dts cannot cover the test matrix. > > > > Add dts/qemu-host.dts.j2, a template of the QEMU virt platform in > > aia=aplic-imsic mode: per-hart cpu/cpu-intc nodes, the M- and S-mode APLIC > > and IMSIC pairs, CLINT and the ns16550a uart. It takes ncpus, mmu_type and > > xen_bootargs as arguments. > > > > Values QEMU hardcodes are set as named constants matching their source > > symbols (QEMU_UART0_IRQ, QEMU_IRQCHIP_NUM_SOURCES, ...) rather than > > open-coded, so a QEMU-side change is easy to trace. > > > > The template is inert on its own: the generated dtb will be used in next > > patch. > > > > Assisted-by: Claude:claude-opus-5 > > Signed-off-by: Baptiste Le Duc > > --- > > .../scripts/qtb/riscv/dts/qemu-host.dts.j2 | 160 ++++++++++++++++++ > > 1 file changed, 160 insertions(+) > > create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > > > > diff --git a/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > > new file mode 100644 > > index 0000000000..13a8e983ce > > --- /dev/null > > +++ b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > > @@ -0,0 +1,160 @@ > > +/dts-v1/; > > + > > +{#- > > + * Jinja2 QEMU "virt" platform device tree for Xen RISC-V tests. > > + * > > + * Interrupt controller: APLIC in MSI mode + IMSIC > > + * (QEMU -M virt,aia=aplic-imsic). > > + * > > + * Rendered by xen_dt.py. > > + * > > + * Variables: > > + * ncpus - number of physical harts (int, >= 1) > > + * mmu_type - Xen host MMU type, e.g. "sv39" (string) > > + * xen_bootargs - Xen command line (string) > > + * > > + * Per-hart nodes are labelled cpu / cpu_intc and referenced with &label. > > + * > > + * No `aia-guests=N`, so no VS-mode guest files: IMSIC reg size is > > + * ncpus * page size. > > +-#} > > +{#- Values QEMU hardcodes, need to be described to Xen -#} > > +{%- set QEMU_TIMEBASE_FREQUENCY = 10000000 %} {#- RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ -#} > > +{%- set QEMU_IRQCHIP_NUM_SOURCES = 96 %} {#- VIRT_IRQCHIP_NUM_SOURCES (virt.h) -#} > > +{%- set QEMU_IRQCHIP_NUM_MSIS = 255 %} {#- VIRT_IRQCHIP_NUM_MSIS -#} > > +{%- set QEMU_UART_CLOCK_FREQUENCY = 3686400 %} {#- create_fdt_uart() -#} > > +{%- set QEMU_UART0_IRQ = 10 %} {#- UART0_IRQ -#} > > +{%- set QEMU_IMSIC_PAGE_SZ = 0x1000 %} {#- IMSIC_MMIO_PAGE_SZ -#} > > + > > +{%- set IRQ_TYPE_LEVEL_HIGH = 4 %} > > +{%- set APLIC_IRQ_CELLS = 2 %} > > + > > +{%- set IRQ_M_SOFT = 3 %} > > +{%- set IRQ_M_TIMER = 7 %} > > +{%- set IRQ_S_EXT = 9 %} > > +{%- set IRQ_M_EXT = 11 %} > > + > > +/ { > > + #address-cells = <0x02>; > > + #size-cells = <0x02>; > > + compatible = "riscv-virtio"; > > + model = "riscv-virtio,qemu"; > > + > > + memory@80000000 { > > + device_type = "memory"; > > + reg = <0x00 0x80000000 0x00 0x80000000>; > > + }; > > + > > + cpus { > > + #address-cells = <0x01>; > > + #size-cells = <0x00>; > > + timebase-frequency = <{{ QEMU_TIMEBASE_FREQUENCY }}>; > > +{% for i in range(ncpus) %} > > + cpu{{ i }}: cpu@{{ i }} { > > + device_type = "cpu"; > > + reg = <0x{{ '%x' % i }}>; > > + status = "okay"; > > + compatible = "riscv"; > > + riscv,cbop-block-size = <0x40>; > > + riscv,cboz-block-size = <0x40>; > > + riscv,cbom-block-size = <0x40>; > > + riscv,isa = "rv64imafdch_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_smstateen_svpbmt_smaia_ssaia"; > > + mmu-type = "riscv,{{ mmu_type }}"; > > + > > + cpu{{ i }}_intc: interrupt-controller@{{ i }} { > > + #interrupt-cells = <0x01>; > > + interrupt-controller; > > + compatible = "riscv,cpu-intc"; > > + }; > > + }; > > +{% endfor %} > > + cpu-map { > > + > > + cluster0 { > > +{% for i in range(ncpus) %} > > + core{{ i }} { > > + cpu = <&cpu{{ i }}>; > > + }; > > +{% endfor %} > > + }; > > + }; > > + }; > > + > > + soc { > > + #address-cells = <0x02>; > > + #size-cells = <0x02>; > > + compatible = "simple-bus"; > > + ranges; > > + > > + serial@10000000 { > > + interrupts = <{{ QEMU_UART0_IRQ }} {{ IRQ_TYPE_LEVEL_HIGH }}>; > > + interrupt-parent = <&aplic_s>; > > + clock-frequency = <{{ QEMU_UART_CLOCK_FREQUENCY }}>; > > + reg = <0x00 0x10000000 0x00 0x100>; > > + compatible = "ns16550a"; > > + }; > > + > > + aplic_s: aplic@d000000 { > > + riscv,num-sources = <{{ QEMU_IRQCHIP_NUM_SOURCES }}>; > > + reg = <0x00 0xd000000 0x00 0x8000>; > > + msi-parent = <&imsic_s>; > > + interrupt-controller; > > + #interrupt-cells = <{{ APLIC_IRQ_CELLS }}>; > > + compatible = "riscv,aplic"; > > + }; > > + > > + aplic@c000000 { > > + riscv,delegate = <&aplic_s 0x01 {{ QEMU_IRQCHIP_NUM_SOURCES }}>; > > It seems like `riscv,delegate` was deprecated in QEMU 9.1 and has been removed in QEMU 11.0. The > property defined by the APLIC device-tree binding is `riscv,delegation`. Thanks for this catch, it seems `riscv,delegate` was kept as an alias until its entire removal in QEMU 11.0. I will change it to `riscv,delegation` in v3. > > See: > https://lists.gnu.org/archive/html/qemu-devel/2026-03/msg01459.html > > > + riscv,children = <&aplic_s>; > > + riscv,num-sources = <{{ QEMU_IRQCHIP_NUM_SOURCES }}>; > > + reg = <0x00 0xc000000 0x00 0x8000>; > > + msi-parent = <&imsic_m>; > > + interrupt-controller; > > + #interrupt-cells = <{{ APLIC_IRQ_CELLS }}>; > > + compatible = "riscv,aplic"; > > + }; > > + > > + imsic_s: imsics@28000000 { > > + riscv,num-ids = <{{ QEMU_IRQCHIP_NUM_MSIS }}>; > > + reg = <0x00 0x28000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC_PAGE_SZ) }}>; > > + interrupts-extended = < > > + {%- for i in range(ncpus) %} > > + &cpu{{ i }}_intc {{ IRQ_S_EXT }} > > + {%- endfor %} > > + >; > > + msi-controller; > > + interrupt-controller; > > + #interrupt-cells = <0x00>; > > + compatible = "riscv,imsics"; > > + }; > > + > > + imsic_m: imsics@24000000 { > > + riscv,num-ids = <{{ QEMU_IRQCHIP_NUM_MSIS }}>; > > + reg = <0x00 0x24000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC_PAGE_SZ) }}>; > > + interrupts-extended = < > > + {%- for i in range(ncpus) %} > > + &cpu{{ i }}_intc {{ IRQ_M_EXT }} > > + {%- endfor %} > > + >; > > + msi-controller; > > + interrupt-controller; > > + #interrupt-cells = <0x00>; > > + compatible = "riscv,imsics"; > > + }; > > + > > + clint@2000000 { > > + interrupts-extended = < > > + {%- for i in range(ncpus) %} > > + &cpu{{ i }}_intc {{ IRQ_M_SOFT }} &cpu{{ i }}_intc {{ IRQ_M_TIMER }} > > + {%- endfor %} > > + >; > > + reg = <0x00 0x2000000 0x00 0x10000>; > > + compatible = "sifive,clint0", "riscv,clint0"; > > + }; > > + }; > > + > > + chosen { > > + stdout-path = "/soc/serial@10000000"; > > + xen,xen-bootargs = "{{ xen_bootargs }}"; > > + }; > > +}; > > > > Zhang > > > > From xen-devel-bounces@lists.xenproject.org Thu Sep 10 11:38:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 11:38:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414498.1644287 (Exim 4.92) (envelope-from ) id 1x4d6y-0004Rp-EW; Thu, 10 Sep 2026 11:38:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414498.1644287; Thu, 10 Sep 2026 11:38:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4d6y-0004Ri-Av; Thu, 10 Sep 2026 11:38:36 +0000 Received: by outflank-mailman (input) for mailman id 1414498; Thu, 10 Sep 2026 11:38:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4d6w-0004Rc-8T for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:38:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4d6v-008BdD-7I for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:38:33 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa296a7-2eae-0a2a0a5409dd-0a2a45019c48-32 for ; Thu, 10 Sep 2026 13:38:31 +0200 Received: from [13.59.128.245] (helo=basilisk.relay-egress.a.mail.umich.edu) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa296b5-5984-0a2a45010019-0d3b80f5e31a-3 for ; Thu, 10 Sep 2026 13:38:30 +0200 Received: from cordial-tupilaq.authn-relay.a.mail.umich.edu (ip-10-0-73-96.us-east-2.compute.internal [10.0.73.96]) by basilisk.relay-egress.a.mail.umich.edu with ESMTPS id 6AA296B5.337C4C5.729CAEA9.1701253; Thu, 10 Sep 2026 07:38:29 -0400 Received: from mail-lf2-f12.google.com (mail-lf2-f12.google.com [74.125.229.204]) by cordial-tupilaq.authn-relay.a.mail.umich.edu with ESMTPSA id 6AA296B4.10DD2037.4E91A78D.2839006; Thu, 10 Sep 2026 07:38:28 -0400 Received: by mail-lf2-f12.google.com with SMTP id 2adb3069b0e04-5b5e4f15b79so1312191e87.1 for ; Thu, 10 Sep 2026 04:38:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-2 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1789040308; bh=O1wsA7wGqDjmamx2IH3bm5PBs1QQcrppf5iIAV+mFCo=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=i6nDXHhopu45EJSjVXoMHk8QvDdCGhJ5yQKUP+UoBTfv6pi//mMNuA7JmRsjABS1K MwACY4fHv1hG3/OlSBHxQXaeJ1jKSfoNExzKjSQLiAjfoJFwn6OYRtACgl/dQ5Lw9g 6QMg05OIZA16kjjU/Tl5mbtzGN9mnGjkYu7AhqBnQEcoM8WdDdCJYngi7KA11AsKp5 D92fHMLuVaeBoUkyDb2KjJhc1ZgzcFo314ZAnOZulrFz2NsK8PwlZcwTDQpcr9zG8w aI0rKlQO7D9vrWLXMlXC2jqu3tzsqwpwCgqOasHF6zBIqx53KXFG+IOQ9DpH+U0olK inAcKn7VZam6A== Authentication-Results: cordial-tupilaq.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=74.125.229.204 (mail-lf2-f12.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvBwnmVTg33bszZAaSGNcsy7Dl8sqo7AiBiqYOV3oI6FyUiw6jAD/N1Avrg+W+jokCGGMombQSMhTdFM=@lists.xenproject.org X-Gm-Message-State: AFuF++lMwIWisajZqHjepm4sb5mPl+mz7vX36WGeYPsriDM/L3Ag57// lJ8sGYtnxHePQ/XuilD5AHS/sUV8x67zqMsHTASbPYgu/wkk4COA3kvrnqfwjVhtsgIsWrnaDgb du2tTrDs37x6d0p4WTa+xtNLAYhmRO/U= X-Received: by 2002:a05:6512:1382:b0:5b4:74a2:cf2e with SMTP id 2adb3069b0e04-5b8986f670amr2952889e87.21.1789040306043; Thu, 10 Sep 2026 04:38:26 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-9-ecc269f268b7@xenproject.org> <97a420e4-87d3-4600-b169-8ec7e5f62a21@suse.com> In-Reply-To: <97a420e4-87d3-4600-b169-8ec7e5f62a21@suse.com> From: George Dunlap Date: Thu, 10 Sep 2026 12:38:13 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1WNz44TJK66fHkv25sw9vuf5ft3DR78OsHCnoRoCd9T9va45dBwTa59XmM Message-ID: Subject: Re: [PATCH v2 09/14] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1789040311-1DE78757-E79AD0A6/0/0 X-purgate-type: clean X-purgate-size: 4374 On Tue, Sep 8, 2026 at 4:36=E2=80=AFPM Jan Beulich wrot= e: > > On 02.09.2026 11:43, George Dunlap wrote: > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -6456,10 +6456,11 @@ void populate_perdomain_mapping(const struct vc= pu *v, unsigned long va, > > local_irq_restore(irq_flags); > > } > > > > -void destroy_perdomain_mapping(struct domain *d, unsigned long va, > > +void destroy_perdomain_mapping(const struct vcpu *v, unsigned long va, > > unsigned int nr) > > { > > const l3_pgentry_t *l3tab, *pl3e; > > + const struct domain *d =3D v->domain; > > > > ASSERT(va >=3D PERDOMAIN_VIRT_START && > > va < PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS)); > > @@ -6468,6 +6469,26 @@ void destroy_perdomain_mapping(struct domain *d,= unsigned long va, > > if ( !d->arch.perdomain_l3_pg ) > > return; > > > > + if ( likely(this_cpu(pgtable_vcpu) =3D=3D v) ) > > Right now this looks to be relevant only to some of the call sites of > pv_destroy_ldt(). I expect this is going to change down the road? It doesn't look like it, actually; I suspect Roger just added it for consistency's sake (all perdomain functions take a vcpu, so they can all use the linear pagetable). > > + { > > + l1_pgentry_t *pl1e; > > + > > + /* > > + * Fast path: v's page-tables are loaded on this pCPU, so the = L1 > > + * entries can be zapped using the recursive linear mappings. > > + */ > > + pl1e =3D &__linear_l1_table[l1_linear_offset(va)]; > > + > > + for ( ; nr--; pl1e++ ) > > + { > > + if ( perdomain_l1e_needs_freeing(*pl1e) ) > > + free_domheap_page(l1e_get_page(*pl1e)); > > + l1e_write(pl1e, l1e_empty()); > > + } > > + > > + return; > > + } > > + > > l3tab =3D __map_domain_page(d->arch.perdomain_l3_pg); > > pl3e =3D l3tab + l3_table_offset(va); > > The slow path is resilient against an area never having been mapped. This > fast path looks like it would crash on a missing L2 or L1 table. I.e. for > domain cleanup (and error handling during domain creation) we'd > implicitly rely on those never taking the fast path. May be worth making > explicit in the description. If we keep the fast path, it's probably worth making it resilient against empty paths, just to save ourselves time in the future. On the other hand, I'm not terribly attached to the fast path; it can only really be used for the guest-driven LDT teardown, which isn't a hot path. I'm as happy to rip it out. > > --- a/xen/arch/x86/pv/domain.c > > +++ b/xen/arch/x86/pv/domain.c > > @@ -319,8 +319,7 @@ static int pv_create_gdt_ldt_l1tab(struct vcpu *v) > > > > static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v) > > { > > - destroy_perdomain_mapping(v->domain, GDT_VIRT_START(v), > > - 1U << GDT_LDT_VCPU_SHIFT); > > + destroy_perdomain_mapping(v, GDT_VIRT_START(v), 1U << GDT_LDT_VCPU= _SHIFT); > > } > > Considering what patch 08 does - is this explicit call really needed? > There are no pages to free here, unlike ... > > > --- a/xen/arch/x86/x86_64/mm.c > > +++ b/xen/arch/x86/x86_64/mm.c > > @@ -738,7 +738,7 @@ int setup_compat_arg_xlat(struct vcpu *v) > > > > void free_compat_arg_xlat(struct vcpu *v) > > { > > - destroy_perdomain_mapping(v->domain, ARG_XLAT_START(v), > > + destroy_perdomain_mapping(v, ARG_XLAT_START(v), > > PFN_UP(COMPAT_ARG_XLAT_SIZE)); > > } > > ... here. Then again even the freeing is taken care of by > free_perdomain_mappings(), so even for this one the question arises > whether it's actually needed. It looks like this one is needed for the "undo_and_fail" path of xen/arch/x86/pv/domain.c:switch_compat(); in theory the vcpu could continue as a 64-bit vcpu afterwards. But yes, given that we're allowing "free" to subsume "destroy", we could just make that the policy, and drop a bunch of other redundant calls as well. Right now there's only the one, but by the end of the series there are a handful more that we could refrain to add. I'm inclined to drop the linear map use, and also drop pv_destroy_gdt_l1tab(). Any thoughts? -George From xen-devel-bounces@lists.xenproject.org Thu Sep 10 11:52:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 11:52:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414511.1644294 (Exim 4.92) (envelope-from ) id 1x4dKk-0007DQ-IR; Thu, 10 Sep 2026 11:52:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414511.1644294; Thu, 10 Sep 2026 11:52:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4dKk-0007DJ-Fk; Thu, 10 Sep 2026 11:52:50 +0000 Received: by outflank-mailman (input) for mailman id 1414511; Thu, 10 Sep 2026 11:52:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4dKk-0007DD-2s for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:52:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4dKi-00GXQU-Po for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:52:48 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa29a07-8faa-0a2a0a5109dd-0a2a4504af54-30 for ; Thu, 10 Sep 2026 13:52:47 +0200 Received: from [18.216.144.57] (helo=yurei.relay-egress.a.mail.umich.edu) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa29a0e-b57f-0a2a45040019-12d8903994e6-3 for ; Thu, 10 Sep 2026 13:52:47 +0200 Received: from adorable-bugbear.authn-relay.a.mail.umich.edu (ip-10-0-73-73.us-east-2.compute.internal [10.0.73.73]) by yurei.relay-egress.a.mail.umich.edu with ESMTPS id 6AA29A0D.368B5465.2D1CF5B6.1389004; Thu, 10 Sep 2026 07:52:45 -0400 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by adorable-bugbear.authn-relay.a.mail.umich.edu with ESMTPSA id 6AA29A0D.959A573.499834E3.1521433; Thu, 10 Sep 2026 07:52:45 -0400 Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-5b4afc8465eso1316621e87.2 for ; Thu, 10 Sep 2026 04:52:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-2 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1789041165; bh=4A/Sm//Khghr+jPQXQpc0Lj/noINrShjMGeSg3lkIZg=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=UQsXa+Z0GGj3kEIRwpWU3ERYAcyCeRucFJvQIBXSEiX+RhpC6D3eS9d4BG6khLw0E fHjoYr+IrjwrK4VrEVa/kixQ3Di22+D6MzzGLyR3WbqQBnkcXGJTdLd4Ku9Bi+WGmN Rlgj7z1EQZgB9wafpHHYm1cVZl3H67xbHSEUbHm/pE/cADf10Mg+k9o/rjVtYUoqQz P334Ehasv1FGNZzGcsGX3rvwdKSra5YXTV+97J76VzQV2LBpLVVQy/CLQjS3J2Ph8Y mx5o6sEB6PWj4/GhaF/5EyawBn9SOdReLdaJE5xebqdyNvsr8v8Blmdm6H8qDfbF6/ UUYcy7Coqnouw== Authentication-Results: adorable-bugbear.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.167.47 (mail-lf1-f47.google.com); auth=pass smtp.auth=dunlapg X-Forwarded-Encrypted: i=1; AKwUvBwKvbCG7E2DyoubthIUmT9WiIJzKqyh0tCHcwcMv1zPsolAHYk7L7El7aNfASTSHCezF3h+Hrl33FM=@lists.xenproject.org X-Gm-Message-State: AFuF++nx0QG8PLt02mIHRISGaf7kloR2zqUfJydFvu0dbtmom7LEN5S4 7nIWGZXG9YYwMg5+i3MECKLU/JEdHMY0ydq4dSWpjnhe1K66VzZi25Ka0xN4+GLgg5D30BQ+iua 2VXzsl6M8erANsIaH8ZnaG7uoYmEKzV4= X-Received: by 2002:a05:6512:1052:b0:5b8:7eb7:4772 with SMTP id 2adb3069b0e04-5b87eb74a23mr1673504e87.46.1789041163038; Thu, 10 Sep 2026 04:52:43 -0700 (PDT) MIME-Version: 1.0 References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-10-ecc269f268b7@xenproject.org> <5b5a8303-b018-4b5a-a4d2-6eabd4c48559@suse.com> In-Reply-To: <5b5a8303-b018-4b5a-a4d2-6eabd4c48559@suse.com> From: George Dunlap Date: Thu, 10 Sep 2026 12:52:30 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1XEuUdGg9JjkwRTFGMF2o6xPdqN41S6wa-urmUTwP046OabGq5YIn9yA5Q Message-ID: Subject: Re: [PATCH v2 10/14] x86/domain_page: drop redundant create_perdomain_mapping() call To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ebf023/1789041167-528C9B50-93AA8241/0/0 X-purgate-type: clean X-purgate-size: 1797 On Tue, Sep 8, 2026 at 4:55=E2=80=AFPM Jan Beulich wrot= e: > > On 02.09.2026 11:43, George Dunlap wrote: > > --- a/xen/arch/x86/domain_page.c > > +++ b/xen/arch/x86/domain_page.c > > @@ -256,7 +256,7 @@ void unmap_domain_page_irqoff(const void *ptr) > > do_unmap_domain_page(ptr, true); > > } > > > > -int mapcache_domain_init(struct domain *d) > > +void mapcache_domain_init(struct domain *d) > > { > > struct mapcache_domain *dcache =3D &d->arch.pv.mapcache; > > unsigned int bitmap_pages; > > @@ -265,7 +265,7 @@ int mapcache_domain_init(struct domain *d) > > > > #ifdef NDEBUG > > if ( !mem_hotplug && max_page <=3D PFN_DOWN(__pa(HYPERVISOR_VIRT_E= ND - 1)) ) > > - return 0; > > + return; > > #endif > > > > BUILD_BUG_ON(MAPCACHE_VIRT_END + PAGE_SIZE * (3 + > > @@ -277,9 +277,6 @@ int mapcache_domain_init(struct domain *d) > > (bitmap_pages + 1) * PAGE_SIZE / sizeof(long); > > > > spin_lock_init(&dcache->lock); > > - > > - return create_perdomain_mapping(d, (unsigned long)dcache->inuse, > > - 2 * bitmap_pages + 1, false); > > } > > At this point rather than removing this, all of what is done ... > > > int mapcache_vcpu_init(struct vcpu *v) > > ... in this function (per-domain-mapping-wise) would want moving into > mapcache_domain_init(). The present arrangement, aiui, is a leftover from > when d->max_vcpus could change post-domain-creation. Question is - would > that go against further ASI plans? (Likely the answer is "yes".) Yes, because soon we'll be introducing per-vCPU mapcaches, which will very much want their own initialization function. I can add a line to this effect in v3. -George From xen-devel-bounces@lists.xenproject.org Thu Sep 10 11:54:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 11:54:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414518.1644305 (Exim 4.92) (envelope-from ) id 1x4dMa-0007i0-VF; Thu, 10 Sep 2026 11:54:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414518.1644305; Thu, 10 Sep 2026 11:54:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4dMa-0007ht-Qy; Thu, 10 Sep 2026 11:54:44 +0000 Received: by outflank-mailman (input) for mailman id 1414518; Thu, 10 Sep 2026 11:54:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4dMa-0007hl-9v for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 11:54:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4dMZ-000V9T-JG for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:54:43 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa29a7e-bab6-0a2a0a5309dd-0a2a4507edd6-8 for ; Thu, 10 Sep 2026 13:54:43 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa29a83-b4ea-0a2a45070019-d1558035e134-3 for ; Thu, 10 Sep 2026 13:54:43 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49d0da752ffso51170035e9.3 for ; Thu, 10 Sep 2026 04:54:43 -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 ffacd0b85a97d-485885bbb51sm53045278f8f.30.2026.09.10.04.54.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 04:54:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789041283; x=1789646083; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=WgHqJBSNKKq530aCdODNT3BTPzgPhtzxVP4tGW7GpNA=; b=TDSrk4XbzJ74L2VGEhhWCw5A214JbSqJE6L5Vu2Vb7Yvm3utzq1PTb+EpPQvFSfr4x Q0b2SXFIt9k6Mnu0sFMqo1riZjiBliG0Q+pIVJDJ1lBaKDaJNTxpEe3n8/YDlzguNpy8 NJ5j5cpNAHKTlcSxUL+YaT8DbCFOrUkDL/0z2JpAFCv1EEJvOZriG5D6PfdeoJBVX4El x6DEiNpIDGPKEY8tG0gszfE3DWLQIs1Ba6DstXGOqy3LU7fsCZB7QTMKYqSTrAJEKWSH BBR37WTf438BcwOmhOQW+eGzdCXtQrBDu2jZ+D+jFPdt+zIL4ximpzfWImwyjFoxbFfK rLrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789041283; x=1789646083; h=content-transfer-encoding:content-type: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:content-type; bh=WgHqJBSNKKq530aCdODNT3BTPzgPhtzxVP4tGW7GpNA=; b=HDepglFOUsj3nHgovuoIURJrGGO0GNoOaPL5U1fBfrm1c5RESuF23SWcy4FxcA9Vne NLmELWvqYsrMoQsG0oFS7j4cHlPoIIf+yLSvMsjaLlYB5Mb70sNqWKCZuMmJXBlfxXjX BFkoZq6Lbym03a+GvPwI1QyfGW4/jIGg51rnFxGfx5Z3e595kFiMmqOkFf4ol24Usu5W J2eJruNHXZWFvRFNXxWKpfUbZLowKP7QGREtnFyH8ouWJelt4eqCumX+syb2G9kZFsaf //336lJw++xysH89pjn5QfvpXG1tu3lizkN6IAX0HuDR0BCZpJv/p/Ifo8GxIqQwGEIe P8cA== X-Forwarded-Encrypted: i=1; AKwUvBzajYnoQc5sNvW0cSPmyL1HHSJ73wZX53Tc8kmb0GUk3KjBpEOvNk3+UcKdmfK0P5xjRFuRKELPHcI=@lists.xenproject.org X-Gm-Message-State: AFuF++kxniWv8O4K6bL/T71skrCgv6GDTSXxltMvt6RUcnZ9hPJiZaor zGXKd8so1x+af7GirJlHpxWzLNgCxAdQNWz87m2/ym41uqUaQQ3t0KMooRyht3hY6A== X-Gm-Gg: AYBFou2qcAZuWwlmcAPXWU9YTv/lJ91k5BFfXpQAZUzpoAc4S0QfhkYIfOFGX4WF/3L jAdtNYTvO9T0/YpPf3IESM6XJFMBTNedhNioVzOlVe1O7fCWOrAfi03z1brVk5uYjIHLyFOoyJB z9I5HfQVj3L4iQMQ6Nr2yreUU5tbeSjN8lZEW1wiu3DX4NOqqzH+Bdz+Lupyz+mFka8KVP6cJAg xwfbKYZyJR82nbR6am1K6g3s806SEic5ZUDHDN4RaC8ruAd6KpDifIbJWwnR6EUxNUIPw5WYRA5 6BEH38rxbdTRAl25r6DO8L3xk1h1i/rVJmlxMQW9FEL65llhqZGNiFenzLPZ8ocbqnp8iZUT+ho lknOnoruk3vp86NtVrHu8QHzRAut5g4prCzfy7hA+5fJVMqDu+YWd8+cOtzx3r8AeyE+yee9y2X i/Q50O8ej42e1rJKtOrPoee/eT49hZMeBhhzTwV+Zz7nbwbFJ8oC+T2bHtMPC72h9aZWb33vHdY Ssuc/1w9UDYUMl495t6/2QbTvuW/NzNMiiSXFzuH/QfJvvrPNICrb+3IVmXjTpwTHj41XBb+Q== X-Received: by 2002:a05:6000:715:b0:485:8c16:5ef5 with SMTP id ffacd0b85a97d-4858f0b188fmr32130812f8f.47.1789041282921; Thu, 10 Sep 2026 04:54:42 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 13:54:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/14] x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas To: George Dunlap Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260901-asi-part2-0-ecc269f268b7@xenproject.org> <20260901-asi-part2-9-ecc269f268b7@xenproject.org> <97a420e4-87d3-4600-b169-8ec7e5f62a21@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 X-purgate-ID: tlsNG-ef75cf/1789041283-A68D9AE4-E8B3B5B7/0/0 X-purgate-type: clean X-purgate-size: 251 On 10.09.2026 13:38, George Dunlap wrote: > I'm inclined to drop the linear map use, and also drop > pv_destroy_gdt_l1tab(). Any thoughts? Doing so would follow the "start simple" principle you mentioned earlier. So: Yes, perhaps best. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 12:07:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 12:07:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414534.1644312 (Exim 4.92) (envelope-from ) id 1x4dYf-0001R3-2y; Thu, 10 Sep 2026 12:07:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414534.1644312; Thu, 10 Sep 2026 12:07:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4dYf-0001Qw-0K; Thu, 10 Sep 2026 12:07:13 +0000 Received: by outflank-mailman (input) for mailman id 1414534; Thu, 10 Sep 2026 12:07:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4dYd-0001Qq-Pw for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 12:07:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4dYd-00FcFb-2H for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:07:11 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa29d67-2eae-0a2a0a5409dd-0a2a45019e64-16 for ; Thu, 10 Sep 2026 14:07:10 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa29d6e-5984-0a2a45010019-4a7de14caa1a-3 for ; Thu, 10 Sep 2026 14:07:10 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-48583cc7ab1so684142f8f.2 for ; Thu, 10 Sep 2026 05:07:10 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883959f0sm53898227f8f.10.2026.09.10.05.07.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 05:07:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789042030; x=1789646830; darn=lists.xenproject.org; h=content-type: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:content-type; bh=uR5i83eMjXsYpYXaYmvOHeQ3k+EShtormrniowLM1WU=; b=FPmEVs6J3HexqTnT1eRmQ9MYM6x2sNcnzD5kaJgiqhDo4F0qITsaSEKOS+OLZghXAs tf/pOOY6Y5ICwL+vixOcG4u3oKEjZrt37OVJBcK5WV9uhn94wv107vB35fCGH1ehyZS3 v95bIK7FjTxseyZtFiOO7tdHFMhyX0XZRpqUMMxNlESPowcnpk1HsSNnb1mmB8NaUBKd c9pbisaFVBfSCtZI4uuYanVByEAckemNa4P39WQ4Z7qrGf4tUspxzR8qxTGOaBepVpp/ WV0zXouzKeFVI1xhCSxMFRsCrSYh9CwmVpAz3KDEFF8jJ7trtVN3qkThIxLVmN3kHp8q XIeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789042030; x=1789646830; h=content-type: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 :content-type; bh=uR5i83eMjXsYpYXaYmvOHeQ3k+EShtormrniowLM1WU=; b=jxieVK83QABlr8xUfQEmzbcQi/epQ4tu3y6TmdSUTN2g6WIw5hscd307maHUFlgJXi MVie2DP6wUkgqc1Zjrxg4atle9c72BDvBbvsDpS8hpHYaLgZM2aSSA+Ih+T2bfGL+XTR LtyFsqsQdm31TayqyFm4Oybk/y4gSbWQ6tUIUYtmvpeoVo67UGKcJNQgJqxuFG0HPjOh Dp+IRQmkCPqiZo+a7yl5nXr0pyCYJFdYAmDdONKWWYhuLMp9XyD/F2PgX94mkG5Ls0oS 530Xis4zbXa++yND2A1CgzS1Nla3GG0TO2rqoonRzhpbAUiI3dMJRRPWGNVUomAo3N2p pB5w== X-Forwarded-Encrypted: i=1; AKwUvBwhQm64ACgRPaed8WIk3LKKMKprmM/qwyZPN/Cp6CpSji0RT2m13An4IdJ10kpKO5fchFAOLdsOoD4=@lists.xenproject.org X-Gm-Message-State: AFuF++mYBzAtLdjWFjj3YIdanmvL2bbI5jwTBPMYMQQil4MRxl5JtEai N5llI+mo1y3gEbIB0l1e2xrpvHUiJCZZq8lm7JvYltHD01E1w7y5QgTYhKC2hkQfGHM= X-Gm-Gg: AYBFou1ep+BsUAFqRgIFLxadWUl6i8RcL3Qm4mCeGwLqQcEnpd5A82nqb++uZxCozSF QrUxzAibxzWjFgomom57of8j/O5szPMI89/THVHIHHliEsLPm0pXljrIJ7I1+4J0pQtf0zYtSjh jViNhcAFNS7GFzBbONBtfH/H08tkkIFonIw4e4rC0RUF5/gWyt5tWGzOkfCcJwsKuA+JW9DcCpo Gqd02Dc+y0SE7k+fZJ130YcA90BpXYPGfXxAe6KGu1Cnv9c4Ozq8KXlvPcpVl9y3qAb0saeDiJH JpfajUCO1ZNpEhwQz/uuG2O7JdycpL4kiEi4Jkz1/fyC1OY++uuhjEJyhu0+PnXPOEatSNrxQAC 2pPQG/U8cZ9/25re4fZ+hZN7XdAEWm+HtBv09uPTEoQJoo/c8Ef4DKYZPvYm50qge/uWPbrKetb asEpy0bTpnB8ICLL7avglGJyE1TAgwOxXy0J6kEgfWK7b/FPEMyaIKDXJJqjMxSlNQx/80sLFlq iMyM59F2CWmhkIeAx6QnO+aYtRZU+KTh7SVJd/khsRXR6H8VMzzoZpYpJcgFvTv/8kH4vQ2kNtD iP4gB45/JF5khXuTglkZIH56 X-Received: by 2002:a05:6000:1843:b0:486:e5f7:89ca with SMTP id ffacd0b85a97d-486e5f78c38mr2174233f8f.8.1789042030203; Thu, 10 Sep 2026 05:07:10 -0700 (PDT) Message-ID: <0a3a6648-0d39-4be7-a023-df987349a868@suse.com> Date: Thu, 10 Sep 2026 14:07:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1.1 3/4] sched/core: avoid use of "current" in initializer lists To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Dario Faggioli , George Dunlap References: <1ba6f97e-4745-4b12-bc80-dffebcadf576@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <1ba6f97e-4745-4b12-bc80-dffebcadf576@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6cqDHa8o5OrjeRF87LSKar2z" X-purgate-ID: tlsNG-d62444/1789042030-1FA6E757-AD845260/0/0 X-purgate-type: clean X-purgate-size: 8719 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6cqDHa8o5OrjeRF87LSKar2z Content-Type: multipart/mixed; boundary="------------1SsaH6TXlm4O7Oujjqh0l8GZ"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Nicola Vetrini , Dario Faggioli , George Dunlap Message-ID: <0a3a6648-0d39-4be7-a023-df987349a868@suse.com> Subject: Re: [PATCH v1.1 3/4] sched/core: avoid use of "current" in initializer lists References: <1ba6f97e-4745-4b12-bc80-dffebcadf576@suse.com> In-Reply-To: <1ba6f97e-4745-4b12-bc80-dffebcadf576@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------1SsaH6TXlm4O7Oujjqh0l8GZ Content-Type: multipart/mixed; boundary="------------plegfYMHycpUqiEAlPAmR0RX" --------------plegfYMHycpUqiEAlPAmR0RX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDguMDkuMjYgMTQ6MjEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBUUkFDRV9USU1FKCkg dXNlcyBhbiBpbml0aWFsaXplciBsaXN0IGFuZCBoZW5jZSBpcyBjb3ZlcmVkIGJ5IE1pc3Jh IEM6MjAxMg0KPiBydWxlIDEzLjEgKCJJbml0aWFsaXplciBsaXN0cyBzaGFsbCBub3QgY29u dGFpbiBwZXJzaXN0ZW50IHNpZGUgZWZmZWN0cyIpLg0KPiBVc2UgaW50ZXJtZWRpYXRlIHZh cmlhYmxlcyB0byBhZGRyZXNzIHRoaXMuDQo+IA0KPiBJbiB2Y3B1X3lpZWxkKCkgdGFrZSB0 aGUgb3Bwb3J0dW5pdHkgdG8gcmVuYW1lIHRoZSBleGlzdGluZyB2YXJpYWJsZSB3aGljaA0K PiBiZXR0ZXIgd291bGQgaGF2ZSBiZWVuIHVzZWQgYWxyZWFkeSBiZWZvcmUuDQo+IA0KPiBJ biBkb19zY2hlZF9vcCgpIGV4dGVuZCB0aGUgc2NvcGUgb2YgYW5kIHJlbmFtZSBhbiBleGlz dGluZyB2YXJpYWJsZS4gVXNlDQo+IGJvdGggdmFyaWFibGVzIHRocm91Z2hvdXQgdGhlIGZ1 bmN0aW9uLiBBbHNvIGRyb3AgYSBwb2ludGxlc3MgKGFuZA0KPiBzbGlnaHRseSBtYWxmb3Jt ZWQsIHN0eWxlLXdpc2UpIGNhc3QgdGhlcmUsIGFuZCBhZGp1c3QgdG8gb3RoZXIgb25lIHRv IGJ5DQo+IHN0eWxlIGNvbmZvcm1hbnQuDQo+IA0KPiBObyBmdW5jdGlvbmFsIGNoYW5nZSBp bnRlbmRlZC4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz dXNlLmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNv bT4NCg0KDQpKdWVyZ2VuDQo= --------------plegfYMHycpUqiEAlPAmR0RX Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------plegfYMHycpUqiEAlPAmR0RX-- --------------1SsaH6TXlm4O7Oujjqh0l8GZ-- --------------6cqDHa8o5OrjeRF87LSKar2z Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqinW0FAwAAAAAACgkQsN6d1ii/Ey8j CAf/bZ2WNhp1D8Z+rqS1WIgpmTjYL3mYnYvH7O4nYW19IF8TEpBNoHWQ/pkfv6eLdqu0L1P7hB7k XEnz1TRCeUTpTW3vnmpy6dNcEQV5QAAis3g1tpYhj063a8MIlYQL1RahTEcTy7X+It/DfSITm1jm R0GCfxYe9Vr9Rbkpuk7AdP3wpwbFYaqlil2lvYokibBqo9eQ5or3whMytysoX/SdDL2zBaPko71+ 3x56YxFQ7pfxQ3q5AfpyDsCUt2hChpJxdTWPeljmkFFycFL/3UkSOwwPgwTRocgm8XoIjCzA2CBV UhxmNBjMHzaCMf3eUQ3pa0pbJ7LPe3COao8xoJ6OOg== =OB1x -----END PGP SIGNATURE----- --------------6cqDHa8o5OrjeRF87LSKar2z-- From xen-devel-bounces@lists.xenproject.org Thu Sep 10 12:29:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 12:29:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414571.1644323 (Exim 4.92) (envelope-from ) id 1x4dtz-0004Ys-PZ; Thu, 10 Sep 2026 12:29:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414571.1644323; Thu, 10 Sep 2026 12:29:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4dtz-0004Yl-M3; Thu, 10 Sep 2026 12:29:15 +0000 Received: by outflank-mailman (input) for mailman id 1414571; Thu, 10 Sep 2026 12:29:14 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4dty-0004Yf-5Z for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 12:29:14 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x4dtw-0086cH-2d; Thu, 10 Sep 2026 12:29:13 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x4dtx-009sYG-0s; Thu, 10 Sep 2026 12:29:13 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=iXPS5Bo+BPvr1CNvxVUEYJd/49ImjH+vF4ef4UYV234=; b=vEjQDnZSE+ikN6fYnKaaPn6ldH Ng4rl5IS+prrUEBG2leKdCju1HfvBYvcClGzfPdPCFWX5DDZD6NP5dnDVCer6uShsiL/MRZpx5su4 repnZR/0r6yHYamvWBPK4DeZGsIn9hNDZoRIJaK/UlDU4hixLvmCDHpAYG/kzjmDfbmE=; Date: Thu, 10 Sep 2026 14:29:07 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation Message-ID: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Sep 10, 2026 at 11:52:10AM +0200, Jan Beulich wrote: > On 10.09.2026 11:30, Roger Pau Monné wrote: > > On Thu, Sep 10, 2026 at 10:38:34AM +0200, Jan Beulich wrote: > >> On 10.09.2026 09:49, Roger Pau Monné wrote: > >>> On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote: > >>>> The use of unreachable(), when unreachability is visible to Eclair (and > >>>> compilers), is deemed a violation. Drop the redundant statement. > >>> > >>> Urg, isn't that something that should be fixed in Eclair then? > >>> Otherwise all the unreachable() calls in our codebase are likely to be > >>> found by Eclair sooner or later, and will need to be removed. > >> > >> No, aiui most are covered by deviations. In particular ones in BUG() and > >> ASSERT_UNREACHABLE(). > > > > Shouldn't this be a deviation then also? > > Maybe, just that I had no good idea how to express such a deviation (preferably > without a SAF comment). > > > Maybe it would be helpful if > > the commit message states why this is handled differently from other > > unreachable() instances then. > > I've added "..., , and the one here isn't covered by a deviation" to the first > sentence. Will that suffice? TBH, the handling of unreachable() feels inconsistent to me. I don't blame you for this, I know you are just trying to fix the remaining issues. I guess I will defer the change to someone more familiar with MISRA and why some unreachable() usages are covered by deviations while others aren't. I think the point of adding something to the commit message is to justify why this is removed vs a deviation being added. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 10 12:44:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 12:44:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414585.1644331 (Exim 4.92) (envelope-from ) id 1x4e8e-0007KO-Rj; Thu, 10 Sep 2026 12:44:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414585.1644331; Thu, 10 Sep 2026 12:44:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4e8e-0007KF-OF; Thu, 10 Sep 2026 12:44:24 +0000 Received: by outflank-mailman (input) for mailman id 1414585; Thu, 10 Sep 2026 12:44:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4e8d-0007K6-76 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 12:44:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4e8c-00FjAJ-FZ for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:44:22 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2a621-8faa-0a2a0a5109dd-0a2a45039834-16 for ; Thu, 10 Sep 2026 14:44:22 +0200 Received: from [209.85.218.47] (helo=mail-ej1-f47.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2a625-fae8-0a2a45030019-d155da2fcddf-3 for ; Thu, 10 Sep 2026 14:44:21 +0200 Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-c2941f7229dso198335666b.1 for ; Thu, 10 Sep 2026 05:44:21 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2624eb1813sm783481166b.38.2026.09.10.05.44.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 05:44:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789044261; x=1789649061; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4NDpqhkstPr+5DN02O+wj1vjpTXqr33/+64K/uydFXI=; b=gNuR2jVsyUHP7YbT7lPxPn3J8dKWpRLI9cUHJTpVVuC5Z7NjK7jGaD7qn6e6qw7JRu Epn0GrukqoHufIEpHiI++yV7+cPxUkfHUfQTMB5j4HIJDDvdQzFBIKbKRdQZ3rRSq3RW lnnEh3FsDHRM2CbbwxkcvXjPnTUAaBwpy7K5EbJrJ3YnPzqqxaquFpmpSrfuOoZj96k+ dAyBY1D2qEORGl/r37uyfb2Rh34jQ6SVb3aFqf44itt2O/rI0iLGmVcxXHXqTtSfJvav yOxZlyAvkKEWmBasddTxlj1GbAOcwftlbV/JkUDhmEnk5u7kCMG+pSQ3c70iCbvppq/v 1aPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789044261; x=1789649061; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=4NDpqhkstPr+5DN02O+wj1vjpTXqr33/+64K/uydFXI=; b=iCrVKfBNZbIRFbmiF8m3jRtjY4C4mrVtrvy1O5HXND0Jd6cIOuF/Zdb4s3ohBtVEww zJ+1uuzvTd9C0M+6K+mBU0Gz+lHcE0eKJV4B1QUGBscBkPXOKKs81Xsxk5/UYQVDgBvd ShqhzfHj76qkcmUG7Da8HRXYrZoTU/Ug8JzJNoxKPt1pvqSNqj+azZLRSRou01PdSjmX hHKsub20qJVHeSPjdDc0lVPqIWjwaO6BOOOm4HlaE6CIOLV06UVtedvrl/7/RhgmbBU7 ZzOPb48KEyFFVxhyiGU+mIam+EVWASWxw5y53N1606B4Hvp6SOlyRcf0WdNT1GRDTJV4 ADHA== X-Forwarded-Encrypted: i=1; AKwUvBzzz4oJ6k841tPVx2c5gOTuZFGQ75JJsyIDWCoqmEtUky1ug3cGOuBRbJSAL8Xhyi2uwBGOW8bGros=@lists.xenproject.org X-Gm-Message-State: AFuF++lTCiuF70Vn0ZvKpaD2qhUbi/d+lXZwOvA9YzaHhotSRa78JIcq G4sdQwielugijYsQt1jlYGNJTkVH65b4jFk2tX8CRMTWfSXE6RqjqH03 X-Gm-Gg: AYBFou1pM6h9jdbjIB35ihV8ogkRUb0/HVdvBiOdeXdI2+Z1AR799jOzFblxURUyS8B 7N2nVlGOJTiCHtgz3JeFPiof9Wg+aaodGff9nJ7eQikJsBnPuOQ8TI6kLtQ7T49IdLjWG+gjBb8 VD036kVyk4LA0xvUR9N2ZuEInvqVfx0kGHUz6K0PHQiTd/YWpGMA8Sbsqr18mN697MQnwieydFD wrde8gtS5EraU3sEoK/t00d/6pizeGTVtvIl63dZ3LsWIbuyXbZJQOOVBYRxWhpNs4ngLDq9Toz HilM79hwto9iaywt/u6JGhtSqwjpeQ7lFl059BxcsvME66NbtOODj/NYcrK90xtwGCnxmnh22xl ByN3vQTSeQW1jXRwSN1F2lmpKY3oWJYE6bAQZa81HMeCmkyqgDTfdxSKNDCM8VMqCAQx9e+Y2WF JJAjAGwozgXqV08MCqhXTcoB1Da1DYYazCg5pBTbfAjDl5Ted/W4mOiyldDjQO8U4g4wOy3Gkq+ kTZJYJm1GUNFsCRsPnlP2DeIq7cZ/SVkA== X-Received: by 2002:a17:907:a08a:b0:c29:3b7e:3a94 with SMTP id a640c23a62f3a-c293b7e3d04mr395916266b.38.1789044261288; Thu, 10 Sep 2026 05:44:21 -0700 (PDT) Message-ID: <744f17cb-de7b-499a-83cb-9f0a122a4605@gmail.com> Date: Thu, 10 Sep 2026 14:44:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> <487a7efa-e83d-4ae2-8f39-33483161a64d@gmail.com> <9f2245d8-faef-4608-a179-b8e942fdfc1d@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <9f2245d8-faef-4608-a179-b8e942fdfc1d@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789044262-6ECCB4E9-021B25C9/10/73395122804 X-purgate-type: spam X-purgate-size: 3294 On 9/10/26 1:23 PM, Jan Beulich wrote: > On 10.09.2026 12:59, Oleksii Kurochko wrote: >> On 9/9/26 4:52 PM, Jan Beulich wrote: >>> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>>> @@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask >>>> >>>> ASSERT(spin_is_locked(&desc->lock)); >>>> >>>> - cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask)); >>>> - hhxw = imsic->group_index_bits; >>>> - lhxw = imsic->hart_index_bits; >>>> - /* >>>> - * Although this variable is used only once in the calculation of >>>> - * group_index, and it might seem that hhxs could be defined as: >>>> - * hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT; >>>> - * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted >>>> - * when calculating the group index. >>>> - * It was done intentionally this way to follow the formula from >>>> - * the AIA specification for calculating the MSI address. >>>> - */ >>>> - hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; >>>> - base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT; >>>> - >>>> - /* Update hart and EEID in the target register */ >>>> - group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) & >>>> - (BIT(hhxw, UL) - 1); >>>> - value = desc->irq; >>> >>> Hmm, only after sending the ack I noticed that there's no masking here, ... >>> >>>> - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; >>>> - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); >>>> + cpu = aplic_get_cpu_from_mask(mask); >>>> + >>>> + /* Update hart index and EIID in the target register */ >>>> + value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >>>> + (desc->irq & APLIC_TARGET_EIID); >>> >>> ... but there is masking here. Chopping off bits doesn't look as if it can >>> lead to anything good. What's the deal here? >> >> The mask is a no-op: desc->irq < NR_IRQS (1024) always fits the 11-bit >> EIID field, so I'll drop it and add a BUILD_BUG_ON() instead. >> >> Would it be better to: >> >> + /* desc->irq < NR_IRQS, so it always fits the EIID field */ >> + BUILD_BUG_ON(NR_IRQS - 1 > APLIC_TARGET_EIID); > > If the question is whether to prefer BUILD_BUG_ON() over BUG_ON(), then: > Yes please. However, APLIC_TARGET_EIID is a mask (despite its name not > indicating that), which only happens to start at bit 0. This kind of > assumption would better be avoided. Then BUILD_BUG_on should be updated to: /* desc->irq < NR_IRQS, so it always fits the EIID field */ BUILD_BUG_ON(NR_IRQS - 1 > MASK_EXTR(~0U, APLIC_TARGET_EIID)); > > This raises another question though: No matter how big a RISC-V system > is, it can only ever have 1k IRQs? How does that work with a single > MSI-X device having up to 2k MSIs? Device MSIs never pass through the APLIC. They are written straight into an IMSIC interrupt file. The ID space belongs to each file, so each hart has up to 2047 IDs (IMSIC_MAX_ID). 1k it is limitation for wired interrupts (which could be delivered in MSI mode where APLIC + IMSIC is needed) which are going through APLIC. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 10 12:53:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 12:53:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414594.1644340 (Exim 4.92) (envelope-from ) id 1x4eH9-0000X0-Kq; Thu, 10 Sep 2026 12:53:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414594.1644340; Thu, 10 Sep 2026 12:53:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4eH9-0000Wt-HX; Thu, 10 Sep 2026 12:53:11 +0000 Received: by outflank-mailman (input) for mailman id 1414594; Thu, 10 Sep 2026 12:53:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4eH8-0000Wn-0a for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 12:53:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4eH7-00AnLu-4q for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:53:09 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2a820-bab6-0a2a0a5309dd-0a2a45049dcc-36 for ; Thu, 10 Sep 2026 14:53:09 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2a834-b57f-0a2a45040019-d155dd33c90a-3 for ; Thu, 10 Sep 2026 14:53:08 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48441fa5c37so4973741f8f.3 for ; Thu, 10 Sep 2026 05:53:08 -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 ffacd0b85a97d-485885be01bsm49092335f8f.31.2026.09.10.05.53.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 05:53:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789044788; x=1789649588; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=3OZQiX16Un81CpdtvuHndGBWmAvi5bEUyfkFhTR+Kig=; b=YSedXQfGJj2Uo2Bj++/cchpAGNrZXcD0RtDVZ6FPzh5Fz5S6pOCWawOFc7UspXudHe sExSnvNzu4KclgobVi8r36v0wFizsr5dPE1moYvKI56e11pAe+JgXnTDA5WBPP6/da+c dCSCH4sfTaRtx8LnPdwMfDNBq9NktUWzaSCZucR7UFRjM0mYW61rcl1FQyMQeESk26bB UDTvNCxZwMjnVo8iOVVt6XO+LaTtvSwkTwWNXxo23iXXY4y8hQ9rnSBiQXg6PjWrFKCD CQfh16YW1NH29a7IqXRDfxuw8wQcB/ze8dar5sjzHLYPcoG2dI0zlOTqgznnHAQs+eyY IRBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789044788; x=1789649588; h=content-transfer-encoding:content-type: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:content-type; bh=3OZQiX16Un81CpdtvuHndGBWmAvi5bEUyfkFhTR+Kig=; b=NEA9NU6iA8fxnbGvsYVQiXXI4sFTyhPQf+B1wdfXBye6k4ldkPQbltItDT+t6uDhi4 RY1DmTG0ooFekWM9R+5yYmC53FY0M3y33frPZ5UcUQwW2Fzg3NqYrodeMCu2eMFeLAa2 JYVFnYQnkgon+LWcz3awyA8g5ZVHpGovt4cyKAzSEGFSYhDg52B0vlfOIUFFp480QC2G zy8ZY434yAeVGpDAaPa5M1h7K0HvqFVYIjmTuqSZDqQ1SyKR5ureN0i5b1izaY0cm2i1 0BL1xLp9OvWwaohnRkXoi9ZiCBFWwe2Kc92su9Za4E71VR5HAa70mrPm4KY947Z0fCIV /hjQ== X-Forwarded-Encrypted: i=1; AKwUvBxWi9WJHvrgx6DVnV+iySOsEsjQBH1yaHheZQ3tAJ8xTfBP2BHggCfdQZrf5IKGVjN5Y9IjHP8krV4=@lists.xenproject.org X-Gm-Message-State: AFuF++kyKrQyA8Bn/Hn56YnleU7tM8xQrMr6C2n4DkAqUzsFVljOiCjw E14Cgbw2KUsKM2969et4HG3b4CgD4RFcEN/HUGEyo6NSq1PtHkqXO7jJyiUe9RkFFA== X-Gm-Gg: AYBFou2SZVXySCxEez2s7jK7tYjGbynbXSxqMdBlV0IYfiMAOSgTq4vjdavYfj6b4dD tpTmNpZHZ4gqVzqCG+OlpX8TCTwDClwG59Nqxo7fN5yHA3ak454ofspNmYbwiyCVLSDk81oPh4+ blj7iwls1RLiILYm0LUTbI3UoCp6wXXwbMKbE1q8IXfCbASSLBfAnl5lfPPdeMpGlD0Nr1MfNNR QvnEHAeq1f+YoPq+JqU9cFicssRjbKZZKx4nvxLt4dtXoxmYNwsfMuNaLho9WabP+yUKTrVigO7 BuLKICubxDFrvAv1qaAUioEHpthKTfv6RVIQPyFd16T4BRDILnaE50ERmf8xetYsCACNtUZUXT6 8CM/94nUgEnEB7tvTGGHrREvc7ja5y75YNkZulhIU6o3kHNEdgqZzBSaZBZhx2SgbFEXD93sns8 9tgnwI+2mu87jtmy4W6bECXOJfONdCrHYtJtD13BYk5B4z5JKJ+Y+dVxegEyZ1M8kju7TcVjhCS G/AKv/DSgCrYtMb3Jd/qRMGJODGeGc9gbCpnffx3bLq1gvc2Laja5tzDxoGbhsW X-Received: by 2002:a5d:588b:0:b0:485:ac96:7263 with SMTP id ffacd0b85a97d-485ac9673b3mr10591953f8f.12.1789044788381; Thu, 10 Sep 2026 05:53:08 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 14:53:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 16/20] xen/riscv: implement IRQ routing for device passthrough To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Alistair Francis , Connor Davis , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-ebf023/1789044788-C20D5B50-51A4FEBD/0/0 X-purgate-type: clean X-purgate-size: 4035 On 09.09.2026 17:07, Oleksii Kurochko wrote: > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -205,7 +205,7 @@ void __init init_IRQ(void) > static inline struct irq_guest *irq_get_guest_info(struct irq_desc *desc) > { > ASSERT(spin_is_locked(&desc->lock)); > - ASSERT(test_bit(_IRQ_GUEST, &desc->status)); > + ASSERT(desc->status & IRQ_GUEST); > ASSERT(desc->action != NULL); > > return desc->action->dev_id; Why did an Arm change slip into a RISC-V patch? > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -325,9 +325,40 @@ static const hw_irq_controller aplic_xen_irq_type = { > .set_affinity = aplic_set_irq_affinity, > }; > > +static unsigned int cf_check aplic_guest_irq_startup(struct irq_desc *desc) > +{ > + BUG_ON("unimplemented"); > +} > + > +/* > + * Shared by ->shutdown(), ->enable(), ->disable() and ->end(), which have > + * no state. > + */ > +static void cf_check aplic_guest_irq_stub(struct irq_desc *desc) > +{ > + BUG_ON("unimplemented"); > +} > + > +static void cf_check aplic_guest_set_irq_affinity(struct irq_desc *desc, > + const cpumask_t *mask) > +{ > + BUG_ON("unimplemented"); > +} > + > +static const hw_irq_controller aplic_guest = { > + .typename = "aplic", This is indistinguishable from aplic_xen_irq_type. Naming of both variables also isn't consistent > --- a/xen/arch/riscv/include/asm/intc.h > +++ b/xen/arch/riscv/include/asm/intc.h > @@ -15,6 +15,7 @@ enum intc_variant { > }; > > struct cpu_user_regs; > +struct domain; > struct irq_desc; > struct kernel_info; > struct vcpu; Why is this suddenly necessary? There are ... > @@ -76,10 +82,13 @@ void register_intc_ops(const struct intc_hw_init_ops *init_ops); > void intc_init(void); > > void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority); > +int intc_route_irq_to_guest(struct irq_desc *desc, unsigned int priority); > > void intc_handle_external_irqs(struct cpu_user_regs *regs); > > int domain_vintc_init(struct domain *d); > void domain_vintc_deinit(struct domain *d); > > +int vintc_reserve_virq(const struct domain *d, unsigned int virq); ... existing uses of struct domain already, immediately ahead of this added line. > @@ -78,6 +82,22 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority) > intc_set_irq_priority(desc, priority); > } > > +int intc_route_irq_to_guest(struct irq_desc *desc, > + unsigned int priority) > +{ > + ASSERT(spin_is_locked(&desc->lock)); > + > + ASSERT(intc_hw_ops->guest_irq_type); > + > + desc->handler = intc_hw_ops->guest_irq_type; > + __set_bit(_IRQ_GUEST, &desc->status); The revlog says you replaced all of these bitops. > @@ -227,3 +251,240 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq) > spin_unlock(&desc->lock); > irq_exit(); > } > + > +static struct irq_guest *irq_get_guest_info(struct irq_desc *desc) > +{ > + ASSERT(spin_is_locked(&desc->lock)); > + ASSERT(test_bit(_IRQ_GUEST, &desc->status)); Same here. And more elsewhere. > +/* Route an IRQ to a specific guest */ > +int route_irq_to_guest(struct domain *d, unsigned int virq, > + unsigned int irq, const char *devname) > +{ > + struct irq_guest *info; > + struct irq_desc *desc = irq_to_desc(irq); > + unsigned long flags; > + int retval = 0; > + > + if ( d->is_dying ) > + return -EINVAL; > + > + info = xvzalloc(struct irq_guest); > + if ( !info ) > + return -ENOMEM; > + > + info->d = d; > + info->virq = virq; > + > + info->action.dev_id = info; > + info->action.name = devname; > + /* The action is part of 'info', thus it is freed together with it. */ > + info->action.free_on_release = false; The revlog says this line doesn't exist anymore. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 12:57:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 12:57:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414644.1644396 (Exim 4.92) (envelope-from ) id 1x4eLb-0001nF-Ms; Thu, 10 Sep 2026 12:57:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414644.1644396; Thu, 10 Sep 2026 12:57:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4eLb-0001n8-Jb; Thu, 10 Sep 2026 12:57:47 +0000 Received: by outflank-mailman (input) for mailman id 1414644; Thu, 10 Sep 2026 12:57:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4eLa-0001n2-Lk for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 12:57:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4eLa-002i4Q-2O for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:57:46 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2a939-8faa-0a2a0a5109dd-0a2a4506d836-38 for ; Thu, 10 Sep 2026 14:57:46 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2a949-195a-0a2a45060019-d155dd31e8b6-3 for ; Thu, 10 Sep 2026 14:57:46 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-486e70f2457so158273f8f.2 for ; Thu, 10 Sep 2026 05:57:45 -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 ffacd0b85a97d-485aa2c9acasm15171542f8f.36.2026.09.10.05.57.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 05:57:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789045065; x=1789649865; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=VnB6m+As0X/AvYGSKFo+NvntiLQqCpYe6s61xqPX97M=; b=THXnBbtF5TfqBNag2jsW/8uCxBb33ylDuhKJm4p2tyjGnfLUkhEhKw2niG/SMO3CPa MqGP5tjDRuHdNHWEM9h3VA1KMcfKwKBgGgwsDNDJPiYo0bLTCiyizSm+m+o/RwvRGyxr bNUvK6JPa7zFGzdlnoX//1AXrQGqAIclBkB256enkm/jEnGrUcXMRE/EjD+5VWjnqmXC xHhdp5RAVB6p1GFS1NPGEVa72VxMQoflmPpFtoymQ2WEUiUoazESM75Snt+HhkgGhgqt TQ+/jPtC11TsR5qO7vh8Y5+6/acLbhNm+AY1dcnQT6htv09GILOK49iJ6Amk6JL42YTo JiGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789045065; x=1789649865; h=content-transfer-encoding:content-type: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:content-type; bh=VnB6m+As0X/AvYGSKFo+NvntiLQqCpYe6s61xqPX97M=; b=oEXeVOW5V6sc2KJ+yH+1lEDeC4cTke6P2KzyL14dB2KDDh9J1bscYoVnngK3IK3qzl lDpOZlT6oAQfqWocj09DE8yuaStln10sndIHGYoVSl15TX1SnaEIFrysQ55cgnqEJyom EfDPPvhmdrW2JOxmYC6irVrMZZmI97FKuqpDlie1CcDfTnmxbgmtyPPoJeeA3xHMFysH pOqKbErtZvFHf+RuQSKYTqF6+cFshMsGdK8LvZY9FKh8w8REwM5pw41e62d9eSZs7zyR HdcNUDaJFUe67cR25GKjznWlo6Kf0ZVmnMVaUPX5LcST0SFM7N1LLP3Q7O7UVPy6COjG g8ZQ== X-Forwarded-Encrypted: i=1; AKwUvByvNuENVkVCsDGZkTJxMdOHHJ1QKLlDeNVvLNQ5PKVqrSStERORMDTY4vEujqVjGdTdtFv+GbR3f8U=@lists.xenproject.org X-Gm-Message-State: AFuF++kBgRhusk4I4u7VpqISd9D6wYg51cQwW0k3meiOXyqtBeWR8zSh +wXDk0RFk5q1UWJ0zds42+J18aKzha+UBJHmGFdFUkR3LFsQjIIQnCzT5QJLODDFkgtRfNeNUg6 rYY257g== X-Gm-Gg: AYBFou198VKQKkStpRe137sc2Gewyuu9SKjBp2YFIionydicnmgka8CiW6uN21Z9ZIH ThxSBtRXIzVFHRHPOU3tSeRzo5t0CDmsAcXUMVREShJ9gKAqJ7oEMRPp3OhFo4dvp7dXVn8dqA/ m5ldhfgWsFVAaeeVhP9edpL27xmXJwq5I05cFpeK5qTdRIuImrME1o6xMPPP1kEAZ+WkF/hF2Jy GAHBPYGMNOU+VbsbYWWiVvgV5TtWra7bRlsJjDs5kSNcQVc5PIJvWSnU9q15H2s0PqCQrjJlwC7 hMRtF3I5RyNRKgC8lfzw03fVcSwHGCDy0iHTy14BoeIH7hxOyyZjcTQGagl/69LQ1R86yTbGX7w pV5LAa5cHMD9LL71rMulSecQN02lv+Lb3zI6h/zrcgiNMJuL6ea8ag3IxYYFG8XVY98HNzrIG+l 4qPHWqnm9YU3mDRsA00N7K1/iG+I1afoX5EG72EfWBvCw26etXdN+0oxFFS7oLHKmpQsEkzc9Pm P/4j882m68e1P7AoGE2z9ASGMo60huKNPIfhtPmz2cnZKpMaK7ndRDUXr1XGkw= X-Received: by 2002:a05:6000:2311:b0:485:8bc6:3caa with SMTP id ffacd0b85a97d-4858bc63de5mr36335441f8f.16.1789045065484; Thu, 10 Sep 2026 05:57:45 -0700 (PDT) Message-ID: <7731e7b5-d5cb-4ba2-a53c-06b5ca019ccf@suse.com> Date: Thu, 10 Sep 2026 14:57:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> <487a7efa-e83d-4ae2-8f39-33483161a64d@gmail.com> <9f2245d8-faef-4608-a179-b8e942fdfc1d@suse.com> <744f17cb-de7b-499a-83cb-9f0a122a4605@gmail.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: <744f17cb-de7b-499a-83cb-9f0a122a4605@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789045066-1FACA77B-36F7352B/0/0 X-purgate-type: clean X-purgate-size: 3533 On 10.09.2026 14:44, Oleksii Kurochko wrote: > > > On 9/10/26 1:23 PM, Jan Beulich wrote: >> On 10.09.2026 12:59, Oleksii Kurochko wrote: >>> On 9/9/26 4:52 PM, Jan Beulich wrote: >>>> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>>>> @@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask >>>>> >>>>> ASSERT(spin_is_locked(&desc->lock)); >>>>> >>>>> - cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask)); >>>>> - hhxw = imsic->group_index_bits; >>>>> - lhxw = imsic->hart_index_bits; >>>>> - /* >>>>> - * Although this variable is used only once in the calculation of >>>>> - * group_index, and it might seem that hhxs could be defined as: >>>>> - * hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT; >>>>> - * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted >>>>> - * when calculating the group index. >>>>> - * It was done intentionally this way to follow the formula from >>>>> - * the AIA specification for calculating the MSI address. >>>>> - */ >>>>> - hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; >>>>> - base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT; >>>>> - >>>>> - /* Update hart and EEID in the target register */ >>>>> - group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) & >>>>> - (BIT(hhxw, UL) - 1); >>>>> - value = desc->irq; >>>> >>>> Hmm, only after sending the ack I noticed that there's no masking here, ... >>>> >>>>> - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; >>>>> - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); >>>>> + cpu = aplic_get_cpu_from_mask(mask); >>>>> + >>>>> + /* Update hart index and EIID in the target register */ >>>>> + value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >>>>> + (desc->irq & APLIC_TARGET_EIID); >>>> >>>> ... but there is masking here. Chopping off bits doesn't look as if it can >>>> lead to anything good. What's the deal here? >>> >>> The mask is a no-op: desc->irq < NR_IRQS (1024) always fits the 11-bit >>> EIID field, so I'll drop it and add a BUILD_BUG_ON() instead. >>> >>> Would it be better to: >>> >>> + /* desc->irq < NR_IRQS, so it always fits the EIID field */ >>> + BUILD_BUG_ON(NR_IRQS - 1 > APLIC_TARGET_EIID); >> >> If the question is whether to prefer BUILD_BUG_ON() over BUG_ON(), then: >> Yes please. However, APLIC_TARGET_EIID is a mask (despite its name not >> indicating that), which only happens to start at bit 0. This kind of >> assumption would better be avoided. > > Then BUILD_BUG_on should be updated to: > > /* desc->irq < NR_IRQS, so it always fits the EIID field */ > BUILD_BUG_ON(NR_IRQS - 1 > MASK_EXTR(~0U, APLIC_TARGET_EIID)); > > >> >> This raises another question though: No matter how big a RISC-V system >> is, it can only ever have 1k IRQs? How does that work with a single >> MSI-X device having up to 2k MSIs? > > Device MSIs never pass through the APLIC. They are written straight into > an IMSIC interrupt file. The ID space belongs to each file, so each hart > has up to 2047 IDs (IMSIC_MAX_ID). > > 1k it is limitation for wired interrupts (which could be delivered in > MSI mode where APLIC + IMSIC is needed) which are going through APLIC. But desc->irq and NR_IRQS have to represent both. Which then puts the BUILD_BUG_ON() above under question. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 13:07:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 13:07:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414665.1644406 (Exim 4.92) (envelope-from ) id 1x4eVA-0003St-HV; Thu, 10 Sep 2026 13:07:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414665.1644406; Thu, 10 Sep 2026 13:07:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4eVA-0003Sm-Eg; Thu, 10 Sep 2026 13:07:40 +0000 Received: by outflank-mailman (input) for mailman id 1414665; Thu, 10 Sep 2026 13:07:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4eV6-0003Sa-Ne for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:07:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4eV6-00B0HF-4J for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 15:07:36 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2ab8c-8faa-0a2a0a5109dd-0a2a4509dcf0-38 for ; Thu, 10 Sep 2026 15:07:35 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2ab96-be1a-0a2a45090019-d561b3388b02-3 for ; Thu, 10 Sep 2026 15:07:35 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x4eUZ-000AkJ-Dq; Thu, 10 Sep 2026 15:07:03 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x4eUY-000ZNN-EA; Thu, 10 Sep 2026 15:07:03 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x4eUY-000000005On-22Sa; Thu, 10 Sep 2026 15:07:02 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=HcYthpHHwERyxlr750rAd0uztEIm6CVXAXuw/bKumiE=; b=Vh9k17xJz9abAm2BUHaBiJm+c5 5h9qXx+f05o1x6NRFPiAcw7Kj4lSLnIVEIaHhRLWBQgIfM1E9Gs3MhFHzi0n2HbIe+/G1o78bo1W6 CE8zGjgscerDiWN3A3L/Pc/ExltzlU3/EaKq7UW1yvB2JE9RonLH24FnjMGUJpUgi7gh5byX2dX/O 8IFAic5mZ8rEW+pHmzgdbU/e1XE5FSOeCjjgzczEaRR2LJ1dlVbSk8N5K/TmifvTGL/9GPg0+Cpxo CiL6GwMKQd9Bk8GPjh8/bAwZmr0BwjrNgjW0qMaMHW5Q4z5UiVhJZ7E/Uka2zijZ0CnNlGoJKNurL 5ofB+OLA==; MIME-Version: 1.0 Date: Thu, 10 Sep 2026 10:07:01 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() In-Reply-To: <20260910033810.GFaqImIu15e_pszuO2@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> <20260910033810.GFaqImIu15e_pszuO2@fat_crate.local> Message-ID: <295ce95081662f9f0c3d8780d0e754a8@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-bad1c0/1789045655-BD4C3034-82960098/0/0 X-purgate-type: clean X-purgate-size: 513 On 2026-09-10 00:38, Borislav Petkov wrote: > On Tue, Sep 08, 2026 at 06:06:21PM -0300, Mauricio Faria de Oliveira wrote: >> Ack, and to confirm: not rename the existing one, either? > > Nah, concentrate only on what you're trying to achieve. > > hpa can send a patch ontop since he cares so much. > > :-) This seems to close the review feedback so far, on patches 1 and 2. Could you please confirm whether the other patches (3-5) are OK to you? And I can send v10. Thanks, -- Mauricio From xen-devel-bounces@lists.xenproject.org Thu Sep 10 13:30:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 13:30:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414712.1644451 (Exim 4.92) (envelope-from ) id 1x4eqi-0007DF-KU; Thu, 10 Sep 2026 13:29:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414712.1644451; Thu, 10 Sep 2026 13:29:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4eqi-0007D8-Gj; Thu, 10 Sep 2026 13:29:56 +0000 Received: by outflank-mailman (input) for mailman id 1414712; Thu, 10 Sep 2026 13:29:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4eqh-0007Cx-CV for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 13:29:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4eqg-00B4RP-Lq for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 15:29:54 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2b0c9-2eae-0a2a0a5409dd-0a2a4509b364-32 for ; Thu, 10 Sep 2026 15:29:54 +0200 Received: from [209.85.221.43] (helo=mail-wr1-f43.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2b0d2-be1a-0a2a45090019-d155dd2bd592-3 for ; Thu, 10 Sep 2026 15:29:54 +0200 Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-482f2ee53e7so5148686f8f.1 for ; Thu, 10 Sep 2026 06:29:54 -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-49d26bf2bb2sm68801975e9.7.2026.09.10.06.29.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 06:29:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789046994; x=1789651794; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=AQzlotH8RSl1oZvrHVuTRmSM7NYL34T0EVMKrkHQb7g=; b=VZYdUDwdXEWxc+PufMbjsu648dZYjMXcpZRPCaBBgkqh0QArVExn9WZKLniBQmI1w3 sqPL0901LtYeVEHfFnTvJtQSn5K4DBOqlvPSwy13uBQJIVHJjvvUBtNPJwWRMrIncI66 QZUxL7ECl3jCXI/K6xADg4wg1QGak0tvcYgOPftt2SOEo49XCClf+VIFeO0yZeaCZfK3 gdi1p4moY8oWmiEfQfdL/AGKOgf/WlHKoMleiF9bh9gYhEmY8T36LjjLN8MMGRRTnoAf Zdh9t5Ck2mYS3gzoWzUipTg89/WT58BWz9gRhyDiE4mUirsZ7YrixrifS7CkJWXZQxxm g6cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789046994; x=1789651794; h=content-transfer-encoding:content-type: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:content-type; bh=AQzlotH8RSl1oZvrHVuTRmSM7NYL34T0EVMKrkHQb7g=; b=JYnbmq0vFGHgqQy9qYE7Cdqew2pqO8L8ki9z9MC6tmluW8tOO/qmgQMM961Kntug03 Q6O/j2v28GezLOr5H5z7sDs/K5lh61liPvbPHglfwcw0V0HnUiSdXEfBxM5Tkoh+sA+B fB2PhfJM01RuqF9PhyFHxEx8dON4xyy1DEHh/X9RPtITxzIef+IaYTb58NI8nViKQ7m9 Lq34KbiCmraqIV5BcwJkskB7eM7EGo6FZtrhApYygavS2hfK3qCrZ8rA/G8lT6TvEj3h J5KqdxoiMUqOEW/Q65uTrs3ropCcboA2eM3Ypx/j7G5D73tBm30ieyufwN8B5n4IeY2m f75A== X-Forwarded-Encrypted: i=1; AKwUvBzWIJ0fsBMBFayUpSmwRrxz92Ujl1UL6FSenQ18MuE4wJ2XHheOzS6SgY2Xbe4Nvaj1jh+1lgenKqo=@lists.xenproject.org X-Gm-Message-State: AFuF++n/tNX9MD0s1VCxhJLyaVPoG8XZVy6/4Wtd5YnYsh1opraj8ADH UNDxEZp/ODc+hNjHxtVrHYq/UYqqVZPZ36PHPlbiedkx2GCDlJlsK3aMsLAuHDKHfw== X-Gm-Gg: AYBFou0nzaqPL6aaz1JmEHuFUIK56Yn1FciyYeqsnrzFCDXga4eS0koxB2Ahwy63tkF 5WqpMfHkP5M2uWvJWTWGG++7zjb8aba5R4HsVIhK0NLTAHZXZRHhRUdbVrRojRQf/Qlbs23djy2 pMfZs6n+vEvMDQhG2SZ0czUyyEk6uHZEERM7WZ3QS9jq+5Eq8wEVJrkDsmsrH7S1uEAg8/X6nyo Xx3jqLyIPmXDbbSyanUWqsmw6X21G99q5m5syGJVve9FdNlt9/OCFazhX6KhBEJYw1H/Nrmq6eA j0gUR730xt5IvY3EMWotzEa5ydEtbgLkyyi9y9jwqGBvTX3pirMiPYlWfgW6UVSgz668PqWlSd/ q3F5zIC33O+yEkezOUk7KxJqmxb35zBSQIgyb+39JeT16uwX/n7CnR8+gv1v5M3QTj5aqlU+xhC aNX9QOdL7OtkUmaJd0S9U13fWXuvFbmvP6SLMES7CKedde4A0KksJO1F1AR/sFrdwSQh1605RKj Ls1XdM+lpVUk36pEtg3QPZaSDeWk5Miq+K1EnEu3wR125RyC4luz4wObAxZmug= X-Received: by 2002:a05:600c:c494:b0:49d:286:83d5 with SMTP id 5b1f17b1804b1-49d028683f3mr340296735e9.13.1789046993657; Thu, 10 Sep 2026 06:29:53 -0700 (PDT) Message-ID: <2eb325d0-8f53-4790-889d-d68a03da0784@suse.com> Date: Thu, 10 Sep 2026 15:29:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.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: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1789046994-BC4CB034-9FF41868/0/0 X-purgate-type: clean X-purgate-size: 7114 On 27.08.2026 17:20, Oleksii Kurochko wrote: > +static void ctxt_switch_from(struct vcpu *p) > +{ > + /* > + * When the idle VCPU is running, Xen will always stay in hypervisor > + * mode. > + * Therefore we don't need to save the context of an idle VCPU. > + */ > + if ( is_idle_vcpu(p) ) > + return; > + > + p2m_ctxt_switch_from(p); > + > + vtimer_ctxt_switch_from(p); > + > + save_csr_regs(p); > +} > + > +static void ctxt_switch_to(struct vcpu *n) > +{ > + /* > + * When the idle VCPU is running, Xen will always stay in hypervisor > + * mode. > + * Therefore we don't need to restore the context of an idle VCPU. > + */ > + if ( is_idle_vcpu(n) ) > + return; > + > + /* > + * If this vCPU last ran on a different pCPU, invalidate its VMID so > + * vmid_handle_vmenter() assigns a fresh one from the current pCPU's pool. > + * Without this, two pCPUs could independently assign the same > + * (generation, vmid) pair, generation counters start at the same value > + * on all pCPUs and increment independently, causing TLB contamination. > + */ > + if ( n->arch.last_cpu != smp_processor_id() ) > + vmid_flush_vcpu(n); I wonder why you need this, when we don't have anything similar in x86/HVM (and at the first glance Arm doesn't have anything similar either). > + vtimer_ctxt_switch_to(n); > + > + restore_csr_regs(n); > + > + p2m_ctxt_switch_to(n); > +} In the absenmce of a comment towards the need for this specific order I'd expect these three calls to be ordered the opposite of their counterparts in ctxt_switch_from(). > +static void schedule_tail(struct vcpu *prev) > +{ > + unsigned int cpu = smp_processor_id(); > + > + ASSERT(prev != current); > + > + ctxt_switch_from(prev); > + > + /* > + * Mark this CPU in next domain's dirty cpumasks before calling > + * ctxt_switch_to(). This avoids a race on things like p2m flushing, > + * which is synchronised on that function. > + */ > + if ( prev->domain != current->domain ) > + { > + cpumask_set_cpu(cpu, current->domain->dirty_cpumask); > + > + /* > + * Once this hart drops out of prev's dirty_cpumask it stops being a > + * target of p2m_tlb_flush(), while its TLB may still hold G-stage > + * translations of prev's domain: neither the vCPU which just ran nor > + * any other vCPU of that domain which ran here earlier has had its > + * VMID invalidated. Move the hart to a new VMID generation so that > + * none of them can be reached again. > + * > + * Switching away from the idle vCPU needs no bump: the idle domain > + * has no p2m of its own, and whatever G-stage entries this hart may > + * still hold (or speculatively create while HGATP keeps pointing at > + * the last guest's p2m) are tagged with a VMID which was already made > + * stale when that guest was switched out. Skipping the bump here also > + * avoids burning a generation on every pass through idle. > + */ > + if ( !is_idle_vcpu(prev) ) > + vmid_flush_hart(); > + > + cpumask_clear_cpu(cpu, prev->domain->dirty_cpumask); > + } > + write_atomic(¤t->dirty_cpu, cpu); > + > + ctxt_switch_to(current); > + > + write_atomic(&prev->dirty_cpu, VCPU_CPU_CLEAN); > + > + current->arch.last_cpu = cpu; > + > + /* > + * sched_context_switched() internally uses a spinlock, > + * which requires interrupts to be enabled. > + */ > + local_irq_enable(); > + > + sched_context_switched(prev, current); > +} > + > +void context_switch(struct vcpu *prev, struct vcpu *next) > +{ > + ASSERT(local_irq_is_enabled()); > + ASSERT(prev != next); > + ASSERT(!vcpu_cpu_dirty(next)); > + > + local_irq_disable(); > + > + set_current(next); > + > + prev = __context_switch(prev, next); > + > + schedule_tail(prev); > +} __context_switch() switches stacks, which can easily collide with code the compiler has emitted. For example, the call to schedule_tail() may not be a tail call, and context_switch()'s return address may have been spilled to the stack (or into one of the s registers). There's a reason Arm and x86 have reset_stack_and_jump(). > --- a/xen/arch/riscv/entry.S > +++ b/xen/arch/riscv/entry.S > @@ -99,3 +99,47 @@ restore_registers: > > sret > END(handle_trap) > + > +/* > + * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next) > + * > + * This is called on prev's stack, and returns on next's. With ra being switched it may also return to other than the caller. If that's really intended, I think it also needs calling out here. > + * a0 - prev > + * a1 - next > + * > + * Returns prev in a0 > + */ > +FUNC(__context_switch) > + REG_S s0, VCPU_XEN_SAVED_CONTEXT_S0(a0) > + REG_S s1, VCPU_XEN_SAVED_CONTEXT_S1(a0) > + REG_S s2, VCPU_XEN_SAVED_CONTEXT_S2(a0) > + REG_S s3, VCPU_XEN_SAVED_CONTEXT_S3(a0) > + REG_S s4, VCPU_XEN_SAVED_CONTEXT_S4(a0) > + REG_S s5, VCPU_XEN_SAVED_CONTEXT_S5(a0) > + REG_S s6, VCPU_XEN_SAVED_CONTEXT_S6(a0) > + REG_S s7, VCPU_XEN_SAVED_CONTEXT_S7(a0) > + REG_S s8, VCPU_XEN_SAVED_CONTEXT_S8(a0) > + REG_S s9, VCPU_XEN_SAVED_CONTEXT_S9(a0) > + REG_S s10, VCPU_XEN_SAVED_CONTEXT_S10(a0) > + REG_S s11, VCPU_XEN_SAVED_CONTEXT_S11(a0) > + REG_S sp, VCPU_XEN_SAVED_CONTEXT_SP(a0) > + REG_S ra, VCPU_XEN_SAVED_CONTEXT_RA(a0) > + > + REG_L s0, VCPU_XEN_SAVED_CONTEXT_S0(a1) > + REG_L s1, VCPU_XEN_SAVED_CONTEXT_S1(a1) > + REG_L s2, VCPU_XEN_SAVED_CONTEXT_S2(a1) > + REG_L s3, VCPU_XEN_SAVED_CONTEXT_S3(a1) > + REG_L s4, VCPU_XEN_SAVED_CONTEXT_S4(a1) > + REG_L s5, VCPU_XEN_SAVED_CONTEXT_S5(a1) > + REG_L s6, VCPU_XEN_SAVED_CONTEXT_S6(a1) > + REG_L s7, VCPU_XEN_SAVED_CONTEXT_S7(a1) > + REG_L s8, VCPU_XEN_SAVED_CONTEXT_S8(a1) > + REG_L s9, VCPU_XEN_SAVED_CONTEXT_S9(a1) > + REG_L s10, VCPU_XEN_SAVED_CONTEXT_S10(a1) > + REG_L s11, VCPU_XEN_SAVED_CONTEXT_S11(a1) > + REG_L sp, VCPU_XEN_SAVED_CONTEXT_SP(a1) > + REG_L ra, VCPU_XEN_SAVED_CONTEXT_RA(a1) > + > + ret > +END(__context_switch) What about gp and tp? > --- a/xen/arch/riscv/include/asm/system.h > +++ b/xen/arch/riscv/include/asm/system.h > @@ -76,6 +76,10 @@ static inline bool local_irq_is_enabled(void) > > #define arch_fetch_and_add(x, v) __sync_fetch_and_add(x, v) > > +struct vcpu; I don't think this is needed, as ... > +struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next); ... parsing of the return type will make the struct known (before parameters are parsed). Also - can't next be pointer-to-const? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 14:05:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 14:05:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414767.1644503 (Exim 4.92) (envelope-from ) id 1x4fOT-00050S-Hn; Thu, 10 Sep 2026 14:04:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414767.1644503; Thu, 10 Sep 2026 14:04:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4fOT-00050L-F9; Thu, 10 Sep 2026 14:04:49 +0000 Received: by outflank-mailman (input) for mailman id 1414767; Thu, 10 Sep 2026 14:04:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4fOS-00050F-33 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:04:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4fOR-002uia-Fl for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 16:04:47 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2b8fa-bab6-0a2a0a5309dd-0a2a4508d6e6-30 for ; Thu, 10 Sep 2026 16:04:47 +0200 Received: from [198.137.202.136] (helo=mail.zytor.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2b8fd-f659-0a2a45080019-c689ca888be2-3 for ; Thu, 10 Sep 2026 16:04:46 +0200 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 68AE455P2182272 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 10 Sep 2026 07:04:05 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=2026082801 header.d=zytor.com header.i="@zytor.com" header.h="Date:From:To:CC:Subject:In-Reply-To:References" DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 68AE455P2182272 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026082801; t=1789049046; bh=bmbZp10cNDqVNfgj2/1lbTZerEuEX6pqCeXNP3LSFAY=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=KTZPnSy2K5ANWXiRh6p4lAZf3xzzO/YODaU51W7fHLpKLjO43x5uBhGiduvK/khSp 4hFjaHV/StgTk5AKzjWfYIG9VUeYfMEOx/22Q3dYKviUw4aKEVFdS7cg+hGCd3s2T/ GaaAq24W10ZT7vzNVRqh3K3Z7WWPKzVijpXGL8urAbzP7McdeEo4L02fLVubXTj7vc bZn+bixjWxptAcH2+pZVEDLi03MMBdxlqSovjcdYlMdi696xqol4afF70CcIldcnJb fgQYkx2/6sRe9PTvO8WuSlaQu1o/QGTu9zVFNm0oEXjPoRrb8FjXL1X54BeZ3YaOVv +EPo8Oz9lqULg== Date: Thu, 10 Sep 2026 07:03:58 -0700 From: "H. Peter Anvin" To: Borislav Petkov , Mauricio Faria de Oliveira CC: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() User-Agent: K-9 Mail for Android In-Reply-To: <20260910033810.GFaqImIu15e_pszuO2@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-2-e70ef3b75b6a@igalia.com> <20260906170116.GRap2cXOY6ENSzAXUJ@fat_crate.local> <20260908193229.GFaqBizWcssBoewNSo@fat_crate.local> <20260910033810.GFaqImIu15e_pszuO2@fat_crate.local> Message-ID: <13B381DF-68CB-4ADE-9810-8586C73D7F72@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c1860d/1789049087-CF75B87B-5CEF91B3/0/0 X-purgate-type: clean X-purgate-size: 366 On September 9, 2026 8:38:10 PM PDT, Borislav Petkov wrote= : >On Tue, Sep 08, 2026 at 06:06:21PM -0300, Mauricio Faria de Oliveira wrot= e: >> Ack, and to confirm: not rename the existing one, either? > >Nah, concentrate only on what you're trying to achieve=2E > >hpa can send a patch ontop since he cares so much=2E > >:-) > +1 :) From xen-devel-bounces@lists.xenproject.org Thu Sep 10 14:19:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 14:19:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414795.1644514 (Exim 4.92) (envelope-from ) id 1x4fcc-000746-Nk; Thu, 10 Sep 2026 14:19:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414795.1644514; Thu, 10 Sep 2026 14:19:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4fcc-00073z-JD; Thu, 10 Sep 2026 14:19:26 +0000 Received: by outflank-mailman (input) for mailman id 1414795; Thu, 10 Sep 2026 14:19:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4fca-00073t-V7 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:19:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4fca-008gbB-0b for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 16:19:24 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2bc68-2eae-0a2a0a5409dd-0a2a4509c8f2-4 for ; Thu, 10 Sep 2026 16:19:24 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2bc6b-be1a-0a2a45090019-b9ff1c22b48d-3 for ; Thu, 10 Sep 2026 16:19:23 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08bb0014d000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Sep 2026 14:19:22 +0000 Received: from localhost.localdomain (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 0716F815B7; Thu, 10 Sep 2026 16:19:22 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=q5157ZIk+fhtfXlWXDnxrkU02QVm1vl4mMJWupMvsb4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=OOgnb2SVQx4unlYvKmvfbdD37ZR0hveZAMwWhFaIdMj5/2UWt2hZl8fmoGZvjDZpD6X5240jV zaGXSAmr0rhzhSymfYjqClVy8H2ok6CkUVJ4fjvGg/mwfpbjoU0rersK+/pyxAgjlq35+dg7qWM 3Mt4AEZEFTgmDwHsMiD7RVMaSWcGxMxSI3XMCJ7nM3LVHF3IdHuQw8jtliFJBNOsLBx0Ij6gj8y VzDR1iBF8AFbZz9mMjExNupgsuFZpo0jwyQujYTYFBiEOG9qw1WIOueJ7NBAiCz+A3B0xmdaHuT wgXfR7vzlBxvt/FtA0pM3xnx/oh5zdB+WOZEqlgjQK/Q== X-Zone-Loop: ce52342aa4c6f8d9bd17ba046d39e84fdc35a683afa7 x-campaign-type: default x-transaction-id: de9d2505-5c97-4bfe-80d4-92ba24dfd4a0 x-swg-uid: 01-8073edbe-a982-4726-9016-40b938011ad1 X-Mailer: Sweego Message-ID: <1789049962.8631fc262581453bbf619ec5b2062170.1a08bb0014d000c4f3@vates.tech> x-swg-bid: 1789049962.8631fc262581453bbf619ec5b2062170.1a08bb0014d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Teddy Astie To: xen-devel@lists.xenproject.org Cc: Teddy Astie , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v2] vmx: Handle TDX instruction exit reasons Date: Thu, 10 Sep 2026 16:17:46 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.86.98788a3c7f66c689.1a08baffebb.98e53e7353613c8a=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789049962172 X-purgate-ID: tlsNG-bad1c0/1789049963-3B4D3034-D326E88F/0/0 X-purgate-type: clean X-purgate-size: 3754 ---=Part.86.98788a3c7f66c689.1a08baffebb.98e53e7353613c8a=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On hardware that supports TDX, guests can cause VMEXIT related to TDX instructions (SEAMCALL and TDCALL) regardless of VMCS configuration=2E Currently, that causes the domain to crash when a domain tries to use these instructions in kernel-mode, and emit #UD when used in user-mode= =2E Adjust the behavior so that the guest always gets #UD when trying to use these instructions regardless of the privilege level that the vCPU is running=2E In the nested virtualization case, also reinject the exit reason to L1 rather than failing on "Unhandled nested vmexit" (leading to a L1 crash that can be caused by L2 by executing one of the TDX instructions)=2E Signed-off-by: Teddy Astie --- v2: - Merge both patches=2E - Always #UD on these VMEXIT in the non nested case xen/arch/x86/hvm/vmx/vmx=2Ec | 2 ++ xen/arch/x86/hvm/vmx/vvmx=2Ec | 2 ++ xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh | 2 ++ xen/arch/x86/include/asm/perfc_defn=2Eh | 2 +- 4 files changed, 7 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmx=2Ec b/xen/arch/x86/hvm/vmx/vmx=2Ec index e55c90ce7f=2E=2E98ec999cb8 100644 --- a/xen/arch/x86/hvm/vmx/vmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vmx=2Ec @@ -4681,6 +4681,8 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_r= egs *regs) case EXIT_REASON_MWAIT_INSTRUCTION: case EXIT_REASON_MONITOR_INSTRUCTION: case EXIT_REASON_GETSEC: + case EXIT_REASON_SEAMCALL: + case EXIT_REASON_TDCALL: /* * We should never exit on GETSEC because CR4=2ESMXE is always 0 = when * running in guest context, and the CPU checks that before getti= ng diff --git a/xen/arch/x86/hvm/vmx/vvmx=2Ec b/xen/arch/x86/hvm/vmx/vvmx=2Ec index a5aa5eb163=2E=2E8ef6529e26 100644 --- a/xen/arch/x86/hvm/vmx/vvmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vvmx=2Ec @@ -2497,6 +2497,8 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *reg= s, case EXIT_REASON_INVEPT: case EXIT_REASON_XSETBV: case EXIT_REASON_INVVPID: + case EXIT_REASON_SEAMCALL: + case EXIT_REASON_TDCALL: /* inject to L1 */ nvcpu->nv_vmexit_pending =3D 1; break; diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh b/xen/arch/x86/inclu= de/asm/hvm/vmx/vmx=2Eh index da04752e17=2E=2Eb8219e0408 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx=2Eh @@ -201,6 +201,8 @@ static inline void pi_clear_sn(struct pi_desc *pi_desc= ) #define EXIT_REASON_XRSTORS 64 #define EXIT_REASON_BUS_LOCK 74 #define EXIT_REASON_NOTIFY 75 +#define EXIT_REASON_SEAMCALL 76 +#define EXIT_REASON_TDCALL 77 /* Remember to also update VMX_PERF_EXIT_REASON_SIZE! */ =20 /* diff --git a/xen/arch/x86/include/asm/perfc_defn=2Eh b/xen/arch/x86/includ= e/asm/perfc_defn=2Eh index ac7439b992=2E=2E102b9be6ef 100644 --- a/xen/arch/x86/include/asm/perfc_defn=2Eh +++ b/xen/arch/x86/include/asm/perfc_defn=2Eh @@ -6,7 +6,7 @@ PERFCOUNTER_ARRAY(exceptions, "exceptions", 32) =20 #ifdef CONFIG_HVM =20 -#define VMX_PERF_EXIT_REASON_SIZE 76 +#define VMX_PERF_EXIT_REASON_SIZE 78 #define VMEXIT_NPF_PERFC 166 #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1) PERFCOUNTER_ARRAY(vmexits, "vmexits", --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.86.98788a3c7f66c689.1a08baffebb.98e53e7353613c8a=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 10 14:24:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 14:24:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414806.1644523 (Exim 4.92) (envelope-from ) id 1x4fhD-00008t-76; Thu, 10 Sep 2026 14:24:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414806.1644523; Thu, 10 Sep 2026 14:24:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4fhD-00008m-2z; Thu, 10 Sep 2026 14:24:11 +0000 Received: by outflank-mailman (input) for mailman id 1414806; Thu, 10 Sep 2026 14:24:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4fhB-00008c-RQ for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:24:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4fhB-00B5sH-7q for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 16:24:09 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2bd71-e002-0a2a0a5209dd-0a2a450895f0-46 for ; Thu, 10 Sep 2026 16:24:09 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2bd89-f659-0a2a45080019-4a7de44cbe7c-3 for ; Thu, 10 Sep 2026 16:24:09 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a6063d7dc4so2130749a12.3 for ; Thu, 10 Sep 2026 07:24:09 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a9882a8510sm2757462a12.21.2026.09.10.07.24.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 07:24:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789050249; x=1789655049; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=KT9XCxucsSIL/H2mR1IcJdAIpK8HPYkvzgpLdrFGK5o=; b=L2Z87yry5ZgtYXQEvg/5DSqR3LbCY9E5B404f4nqoX/v8iGgHg2UT5SaTo93Ckye9Z iBTiu07XzbuaKG5bQKl7M7qTJZgLt/aul0I4DjIqXl+zoYRUTqLgv75HJAdC4sJmLmts iR0LGFEHw/7dpyDaHivaOIi7D5yi0Yx0LPyI3Mx7MDMHAuVDR68tGQGHfQ7/roBk+BYn VtEf+YuS+gniiz8JBHTHs0QOazHtdgM4DIkmkalWPL14ynTxzXQJNpV2ougA61iuUP1b yKWdxk+xd5IaO8iqD6Gm2yB4M7zMybpzp+zhg2L2saQxw8CgOyndJ+V+EiM9R2dhYvou HNUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789050249; x=1789655049; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=KT9XCxucsSIL/H2mR1IcJdAIpK8HPYkvzgpLdrFGK5o=; b=H5brywoGwuE576hQ/yJOZNtuXGmohDyK3LDZfuTd56/6hoGXauX3DtDx07cUu++dCT mpqoLsqES1xDIyQNM1xfvxI6VN8TuxlgzLev5ZRuJEDpQTpP9I14hEfmWA5PHEVxf4d1 zc/8vZKx2ctMKFUz4Apy8jIIpdFnInHAxw7f9adVbcZ3tpIC94uUgH1Jr/23kQbQGPru hvXe6BuBQTJ8n10K+93S1aKXO9povqPEw6oD5aLt05+rJWjMWkzHqgO9HoQsZ+cYYHI7 WKomC0vkMrqUP0EL8Cuu3pvm8JaSUn7DPN9UongHLR5C9LD3ZEHNdq40xJf6C0+ceUeG rKUg== X-Forwarded-Encrypted: i=1; AKwUvBwmthJYQ4fcPJurzvoneMZmj6BEAc04GLR8w0qg/Icig3k/YrWKh/p6LmHJfwu58rL2yHE6Um2nLok=@lists.xenproject.org X-Gm-Message-State: AFuF++k75p+YiNOZdD+5yMr5VWgCltRh2FWyavNH7wAwN6LVGsyx9cKN cVsePWzf2FBWPUs0LikhcvyUwNa13ZYAe+qqh8MMwjQY0PpfKkoh5sJe X-Gm-Gg: AYBFou0Q0G2x2WGJ8DqisWLHcprPvwtCL+9ExB9QA2JwpZx44ySNIuoacMeo5EgPyIl J/DFHS3Jmtj6I2Mj/eskJAfSNZYlTofGeQt3FlL2a6VJNiAW9gkhXip3iZSAl1p7sDfV0HwC7n+ 0zwu2tGaOirbTxSCs/dX9RLl3kwDfPtPSjEi2ORYFXnIrOS62dioqGh68pLw4sWQAPbG8/KDCfM beGwimcla4LDrZbIPagV71QfxLwJ3wUYognqsWHWMWolrKmon8kyO3oaSCfOXLshw8BBYhIvO46 Umgk59yIUZRQaZ3169ks22HcDaY9cbyYF0MN/jOIrp3XdifwoWwt3idxC5Y+ZDJ84JS2UpmSTzF L2mn5RHjbNK1sZS5K/qtpWfdeKPYer+pwmN2HCjIPnNfuYjVdNeMpDtnZz5oaROHnfjxiPZbtbi Yjl85FBvTn5AXvHQ0zHYZlfcegbhWt4vDdFkLMiqKAAoX8cOloI79YLxWJnukvixdSa4pG2ks1r jnwSHdMHBLbM3RqE7x7FZdZyljmsmmW X-Received: by 2002:a05:6402:4513:b0:6a6:757d:6311 with SMTP id 4fb4d7f45d1cf-6a99ccc36c1mr6930430a12.9.1789050248498; Thu, 10 Sep 2026 07:24:08 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 16:24:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> <68ab5241-7301-4988-9420-bcccc4b16e3d@suse.com> <071ed630-4c72-4df1-b15e-3037e3f076ba@gmail.com> <48857983-ac79-44a0-8a11-93f62ac3d0c4@suse.com> Content-Language: en-US In-Reply-To: <48857983-ac79-44a0-8a11-93f62ac3d0c4@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789050249-CC57487B-FDD917DB/10/73395122804 X-purgate-type: spam X-purgate-size: 2691 On 9/10/26 1:14 PM, Jan Beulich wrote: > On 10.09.2026 12:37, Oleksii Kurochko wrote: >> On 9/9/26 4:26 PM, Jan Beulich wrote: >>> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>>> +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, >>>> + uint32_t base_val) >>>> +{ >>>> + unsigned int guest_id = vcpu_guest_file_id(target_vcpu); >>>> + unsigned long hart_field = aplic_hart_field(target_vcpu->processor); >>> >>> What guarantees target_vcpu's ->processor field to be meaningful at this >>> point? >> >> Good question. Considering the places where it is called, I would expect >> target_vcpu->processor to have something meaningful, since it is called >> from a place that can only be reached when the guest is running. >> >> Even without that, I don't think there is a big issue here, as >> ->processor is initialized to 0 at allocation time. This means that the >> target register will be configured in such a way that CPU 0 will handle >> such IRQs. > > I may not have been explicit enough then: Whether the guest (as a whole) > is running is of no interest. If the specific vCPU is running, all is fine. > If the specific vCPU is in the process of being moved to a different CPU, > and if you read ->processor just before the new value is put there, is > all going to be fine as well? I doubt that. > You're right, and it's worse than a stale CPU number: v->processor is updated by the scheduler (sched_unit_migrate_finish()) before sched_move_irqs() -> imsic_migrate_vcpu() moves the interrupt file, so a concurrent vAPLIC TARGET write can combine the new CPU with the old guest file index (an MSI into someone else's file, which aplic_reconfigure_target(), which is introduced later in this patch series, won't catch), or compute a correct old target but write it after aplic_reconfigure_target() (the function which is called during migration to re-target irqs to new pCPU) has already scanned. In v3 I'll (a) stop using ->processor and take the (guest_file_id, vsfile_cpu) pair, which imsic_update_state() updates atomically under vsfile_lock, and (b) do the snapshot plus the h/w TARGET write under aplic.lock, which aplic_reconfigure_target() also holds. As imsic_update_state() completes before aplic_reconfigure_target() (also that could be checked in this patch series and is introduced a little bit later. Probably I have to re-order some patches again) takes the lock, the emulated write either happens before the scan (and gets fixed up, or skipped as already correct) or after it (and sees the new location). Any better option I have now? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 10 14:55:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 14:55:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414838.1644531 (Exim 4.92) (envelope-from ) id 1x4gB5-0004y5-EH; Thu, 10 Sep 2026 14:55:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414838.1644531; Thu, 10 Sep 2026 14:55:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gB5-0004xy-Al; Thu, 10 Sep 2026 14:55:03 +0000 Received: by outflank-mailman (input) for mailman id 1414838; Thu, 10 Sep 2026 14:55:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4gB3-0004xs-UV for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:55:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4gB3-0013j2-2O for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 16:55:01 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2c4af-e002-0a2a0a5209dd-0a2a450cb8d0-32 for ; Thu, 10 Sep 2026 16:55:00 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2c4c1-f479-0a2a450c0019-4a7de18cbff1-3 for ; Thu, 10 Sep 2026 16:54:57 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd38e0f79so13271395e9.3 for ; Thu, 10 Sep 2026 07:54:57 -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-49db038401fsm51458155e9.13.2026.09.10.07.54.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 07:54:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789052096; x=1789656896; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Rg9VvSCiSky1Aa1edsln0MYc8zxkyfgdBVKR74he1+c=; b=DlQlKOLIV1NsO0hvvH54Kt/bfSp+DotuA8a7Qks4gvtxuydzhCV6Kjm8GBs1FivLnV iRxvfC99zEcSrYnS105Ult4CUPlVjmHEaOSuIQvakfCYPc9csBpQP+MnqaNssCtIX75o 0pdmvr6HZ6t1lyx4Mle5JklKxugMq3ORzvMiaurJxWuHOhjOveHIcgLRZ7qbnKxu+ZHG 4ZiQoxjIoQbddU+54d1ZiCc7+uy4wPzkFRL54CaFQnWSyNxIlAQ/QXzNH0B98Z5PajXX 70cgkn1aFb/bUzPp9yLc97x9lU1wWDkhYkVtzvcMvFKT9ya3uYD3cDoFfwTxmgrsCHuh r1GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789052096; x=1789656896; h=content-transfer-encoding:content-type: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:content-type; bh=Rg9VvSCiSky1Aa1edsln0MYc8zxkyfgdBVKR74he1+c=; b=UzbsdRp8FH411rpIaN88/B4TaP7PgR0ciaXg+yWpa4OEObbTJkGJCc+ZP/zWZRDmdn Q4C355iFPMmqZx2JBSZmF1bXJCtooocNJpk/pTPChgCnZzjZ55fWVjZ3trAcHmTDRmih bSI7v2GGSKxBjqazmtFIrbF2mJzynHJJZ5rxsoS5Uh6ERHPnBNvsExbhqVQ2xEIQBkdz +TscxLmvh+5MTf7I5MafxxxoUErffX6YaAp+ll28/wSyG6sARSYVHE4x5R2oOJ865a41 d9+neRxBmqQmjfX9too4m8gX0yzUmTSDYhb74NzW2T+C0D77Ku70ezoxGB0pNEiYFqAQ 2/hQ== X-Forwarded-Encrypted: i=1; AKwUvBxqviRD4T9FOH9df/TaxALa1fRdzkROqCYLPp1M4E+CuvN50kidyzaJQFWi7MJH8zTWNV0Qrr+eopA=@lists.xenproject.org X-Gm-Message-State: AFuF++mybli6ovuubNNBAlAQaqcTCOeztTch/X0J1lBuiUIb8cHw5U9o 5DJdG84GrkGVpIqfiCqx+jzshkrpae05v8o0JichMS0aRKnQezrnewqN8cDKiCrl1A== X-Gm-Gg: AYBFou1xWwnCsDSCAB+cEz8us0pPUXZ5zS3COLoUzUrhcXursCnJZ1dzSpSoGc/3jy9 vZ9j4351EdwsFZi3HoH39zWUg1vjuqjIEy2uY1GE4Ufxka8B5IDg0RtSG4/OGa0et4qvKf/0lth sprQ2E6oXPp5RlOFnqvhRJ7hOWXixLEhViTB5fh1lOhFSRvPNhEDB+z1FPvBrI5BTh8p0bURNfT XG+mHlBMliaFOX+peHrJIQgN5uqk66l25VbGGtkdne2PLG13WdHEfhS+qpd1ShyH1PUHJ26IduT 2E/nTdHVI+V0XyVYR3t3kGJ7qOGzAEQcfgTw+G4dYCTjqAOZ3n3HCO/8pugv7Sv17l6Jwom8TM8 ha3qSPU4FB7hz24DE5zU4cd7S+JVl82FGD82+VTfq9edN9/TszE3JLCA0Hj9Ur3TcCuTDfXnmkZ gVR7Kd7n7tjOGkMCgkqg6ARxKHO3OPPjAdI9W3p7LCqyNfpAR6a+6fckXg4Rm8Lml4fuTt7Vtnb lCBvUAuXBnAhXSgwdJi0Jloe7/PcXo99jwq3Ta4GkfnnZ9fsTBirBs1Me6yFbQ= X-Received: by 2002:a05:600c:3f05:b0:49c:e1f1:3dd5 with SMTP id 5b1f17b1804b1-49d1f223e83mr255035935e9.4.1789052096555; Thu, 10 Sep 2026 07:54:56 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 16:54:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 14/39] xen/riscv: introduce vintc_ctxt_switch_{from,to}() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <678236568970b18a1924a76588c4c50f9bf0c659.1787838835.git.oleksii.kurochko@gmail.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: <678236568970b18a1924a76588c4c50f9bf0c659.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1789052097-006CEA5B-77C1E818/10/73395122804 X-purgate-type: spam X-purgate-size: 932 On 27.08.2026 17:20, Oleksii Kurochko wrote: > Virtual interrupt controller state must be preserved across vCPU context > switches. > > Introduce vintc_ctxt_switch_{from,to}() wrappers around new > ctxt_switch_{from,to}() hooks in struct vintc_ops, and call them from the > context switch path, so that this state can be saved/restored without > knowing which vINTC variant a domain uses. > > No vINTC variant implements the hooks yet: the vAPLIC implementation is > added separately. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich Also in case you decide to ... > --- > Changes in v2: > - Update the commit message. > - s/vintc_state_{save,restore}/vintc_ctxt_switch_{to,from}. > - s/{re}store_state/ctxt_switch_{to,from} for vintc_ops. > - s/vcpu/v for vintc_ctxt_switch_{to,from}() arguments. ... rename them again to n / p. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 14:58:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 14:58:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414845.1644540 (Exim 4.92) (envelope-from ) id 1x4gDr-0005da-Pw; Thu, 10 Sep 2026 14:57:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414845.1644540; Thu, 10 Sep 2026 14:57:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gDr-0005dT-Mf; Thu, 10 Sep 2026 14:57:55 +0000 Received: by outflank-mailman (input) for mailman id 1414845; Thu, 10 Sep 2026 14:57:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gDr-0005dN-1R for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 14:57:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4gDq-008mlO-EW for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 16:57:54 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2c561-e002-0a2a0a5209dd-0a2a4509da2e-26 for ; Thu, 10 Sep 2026 16:57:54 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2c572-be1a-0a2a45090019-d155802fc4e7-3 for ; Thu, 10 Sep 2026 16:57:54 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49a97714f5dso68768885e9.0 for ; Thu, 10 Sep 2026 07:57:54 -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-49e5765152asm26985315e9.11.2026.09.10.07.57.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 07:57:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789052274; x=1789657074; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Vy8euwVDIN40tmvyLupIbsPGljAsnh78O5Pc9qRoD3E=; b=GmU/GFdlJpqVWFGGdiaQvP62u+a+QIozpDSY6TvLBkiuolxBDfZ04lbiMGNa20TTYn m9gUNnXNqar+TZAEplW+PMIX84luLz/6RhtPUPTfDe3wkl+JrcuPn4SHnYPYOZNjUsNT mWvCvmSon+6BvDrxL758TLyVdiZTm4ThXG8ngox19F4q7d86scRDxksb54GojoR75wC/ kZoYDglyL2Almnd4llh8HY0inbavJUF6rXtNlNinWLWLEZnqc5Njjy6de3Z9eI8wuPby B9Xzf/Wmra3I1peD+V9ggJUMLS9r4aqhdYhCsWFeaMrLlwp9Npr+qgS1q3281Mt4nlKy zBIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789052274; x=1789657074; h=content-transfer-encoding:content-type: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:content-type; bh=Vy8euwVDIN40tmvyLupIbsPGljAsnh78O5Pc9qRoD3E=; b=MajjtAov7xZEqE4x96ivlKKq2truVPxvY3bVotWIsklRghgrq1fx9b3yznIF/dRqCZ oG37LHpC/Mvcon8Y2MleRRs4jvJhB3kc7puqiUImrN9f49tfKeMOXMhpd1xMM8ByKahz 5r4+ecpulv3fr2NvVjl0VCk5rHVdkP0ngxLw7H05dUNJeR81OGLc/RNJASH/Da39zPmR QkXUqcM6oKzf8nzb2TawP9OOkUp2Kpx5k+uq0wDQiaeEszzx+8ILaJKDQV8A1PoBQo4A 8Jdvz9EUG6WjwjzVAZoJh6YlPGNU5hSc8EIfBGU4+rwmA4+oZg3h2THGTvHINvkwsUqL /Wrg== X-Forwarded-Encrypted: i=1; AKwUvByAX0A0KsmwJ/IpExhlLoO1+ITLB1BPPOf6/OQIp+kVcvBh6+kGhUNuBc53Xlj+t/DRYohGsGLYuPs=@lists.xenproject.org X-Gm-Message-State: AFuF++lGuGRUcJXT9JG6dzVQSInin0IgNWU/AfXd/2CHGXAHy32dKPf+ kHfR304L8u3YutMQL0G0EY/96lovB4AWAwrv6NR4RrF0wj7ZxyrDSprQZC/WXMDWVA== X-Gm-Gg: AYBFou01U5ZzRSKpwWwis3GkZ80mEMmC0U8nAh9dsSV8alduRt3FwolivzXXBNADTqr Nh1tJlitBFUCfDPZgqF1/oZTC1/fuE2TGyLDSsOSKdvrql5J4Lpf2gocs048JHjCHboHO6agahp e/ak+dEtsVZ12TB0PzxPhqCyNUsFk8PNqB2/nWs8AkPXNMztCTvVtXzIZyvCY00/C8pq/Nx5BOR 7wk3m1Jv0Qcvek7wJP9KwGeM+u716FNEXkJt//X4ICTcaXbbOLxtMQWcUHi3LSDkm/4Xfp5nSaq NHQzodIvYBHqfhBK+n/xa0/U32pDgLWmy3sqgTs1/2AYWnxzN5gM51p5UMYmfg3O1yHRbxB5sMQ VNrslXjEFSn08CvaqBHQEK4EtFIQShRjFtuMfDrOcgtZulNE13p1ARPs6HulGto0WbUPnD3TuEv A3NOfPKX28Zfaq8g6CYcXnXOltMKtOu2j0KvBUKnEHpbbcAVfiyJy9dMxQY/e40QgDcEOCvjn4V qvNFK1IWzS7R4yOIDQKPVjWOj768FNXTxd32fiuPkGbLWAsfYIDb/zAdxB6OK6tvyanguac4w== X-Received: by 2002:a05:600c:c162:b0:49d:16dc:e721 with SMTP id 5b1f17b1804b1-49d16dce7aamr225951745e9.24.1789052273861; Thu, 10 Sep 2026 07:57:53 -0700 (PDT) Message-ID: <9651f59e-b101-4c70-93ae-07f668e85c38@suse.com> Date: Thu, 10 Sep 2026 16:57:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 15/39] xen/riscv: add IMSIC vCPU context switch handlers To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <867af892784c295296cdf63e0371fa1b7ed7a1e7.1787838835.git.oleksii.kurochko@gmail.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: <867af892784c295296cdf63e0371fa1b7ed7a1e7.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1789052274-3AAD8034-574478BD/0/0 X-purgate-type: clean X-purgate-size: 973 On 27.08.2026 17:20, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/vaplic.c > +++ b/xen/arch/riscv/vaplic.c > @@ -422,6 +422,13 @@ static const struct mmio_handler_ops vaplic_mmio_ops = { > static const struct vintc_ops vintc_ops = { > .vcpu_init = vcpu_imsic_init, > .vcpu_deinit = vcpu_imsic_deinit, > + /* > + * MSI delivery is the only supported mode: aplic_init() panics on an > + * APLIC without an "msi-parent", so the vAPLIC state to save and restore > + * is always the IMSIC one. > + */ > + .ctxt_switch_from = imsic_ctxt_switch_from, > + .ctxt_switch_to = imsic_ctxt_switch_to, > }; As previously expressed, I'm not happy with comments like this. aplic_init() isn't related to vAPLIC behavior. We're doing virtualization, so at least conceptually host and guest behavior want properly separating. Then it may still be that for the time being only a certain subset of possibilities is supported. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 15:06:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 15:06:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414857.1644550 (Exim 4.92) (envelope-from ) id 1x4gMI-0007hB-M3; Thu, 10 Sep 2026 15:06:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414857.1644550; Thu, 10 Sep 2026 15:06:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gMI-0007h4-Ig; Thu, 10 Sep 2026 15:06:38 +0000 Received: by outflank-mailman (input) for mailman id 1414857; Thu, 10 Sep 2026 15:06:37 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4gMH-0007gy-BU for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 15:06:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4gMG-0036Rf-0A for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 17:06:36 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2c773-e002-0a2a0a5209dd-0a2a450cbcb6-14 for ; Thu, 10 Sep 2026 17:06:35 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2c778-f479-0a2a450c0019-4a7de18c9b9c-3 for ; Thu, 10 Sep 2026 17:06:32 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso16364415e9.3 for ; Thu, 10 Sep 2026 08:06:32 -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-49e60ac42b9sm1207805e9.6.2026.09.10.08.06.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 08:06:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789052792; x=1789657592; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=s9HsNew2T/nYK93IszSbli/3oKF9fTf1EzwRDq+XNYY=; b=VwPtBqwoF6bOUNpQMvGTG4/FhONMkyE4DA7ee6PyQfRsSo6lsKJFglf9DCqhEsPm5v 8byAdKD0ZEqNaoCq19Epgu1mcHR/ZGpoGWh6tgDDkdUKzz9g+YVGSo0tOk1eI5bKs4IP 1tjjkcWTO+BKy2j1Q/qqZzh5LGIrQuabtMVjhF290gkIBNPN99GsZc9NJDM5ugSiDTWz 1Pje9vdZdHxTMsFfcGa0naeVV0Zl+KE4/TdH7cxKDk/sfg64k53gXa5kcxRCmqy5P0ci rGfQZJMbN9Bq6O8hrPCDzz3nrlHFl9ywuCjtFvC443SiKKYGxPwotIuUVnrtcvxDceuJ IINw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789052792; x=1789657592; h=content-transfer-encoding:content-type: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:content-type; bh=s9HsNew2T/nYK93IszSbli/3oKF9fTf1EzwRDq+XNYY=; b=VUZ/6qeEvSg6Nbf9P19SthnosTJsxCqPyvYpX7lZA/KYX+WJyiviHa3Jjo31U4GMur nMF5ub2nnkZaspBGpnk4KHruPgVi0UL4CTQw2ARrqviizDXrS57S04SS/nrrpFfWvkP8 J0vPWhXmHH/5d7VDR0C2tVpaT1HiiVB2gKtTmvyGRigx/FVciWQqvfXchrFqtbbIhiYU KhYqPUIy3NCWrWs3LckNypxUcS61uAMp3TwACq9uLJc+9NKJDb13i8uGG/2RQ2uBcy1i YVHAgfBr75bk0Af//LYDAykBIvl/A0euSg2xpfmo2UzzNkpvhFClJOE0Z5qplnstoW7O LVOQ== X-Forwarded-Encrypted: i=1; AKwUvBxLGh5wxm1DamhFijyPGjtzvRvKKX7UnrNiXVCNhcs01d0iuJs/Cw6C+pPp4fImAYsfT5Z9xAljNZw=@lists.xenproject.org X-Gm-Message-State: AFuF++nVuQ1XVT4qzIWVw4xJztkpjrWPpKLaRIO0o4EffegAWWVQEZlg Li3vdoogWer+QdZbBH4OqdYd4K8wciLc6VuGHOawnxAp+pcPRwoW2vw1Yg6oUqNb/Q== X-Gm-Gg: AYBFou1IlKhZvtZaFubnlgfuDLbtmCBSLEHe287UAzvmo45Hc1pZ0XO/FN5EQnzDr2R WpWNY0SLZVpW4oJinA4zps6ibiTudDRvqAwP9NWPyr8wuocu5vMpel59Mc86NdSWjbEEZHz8uTK W5XHW+kKUtb2BwjzfmoUDUp7Rr6xFatRtAPgxxRsl+4r9fHo7oaaDL9Ve4O9ZU4BJ7NvV3zFo9U P4NPh9j1RXAMQ3sbLMqZaA8Nd0yyFAsJJ/SzwOaHCyC6dYjIz5C041JGHN8lNzD5AvossdTAevo AjpVMtrfXegwMcsBveCAMVrzXtpRbRlrhFYZKJ1vRBAIVCHX0vHXUaheVer6kdWG673XQUBogGi lAayDizp0heAmdeYk+NUrDDGqG9w/rwJJWLr2W9KE686+AjZzvISGvkrGSgJB05WwLIhRvF7qfA YhDMVDTyVAfTcKkn+gC9gJATxXOydds8b+EepNdYs2fbd7zBv40HLYM8OFDmny6xxZ7jH3MEbI4 x2vqJoJrqrsAO14VRSPFzDib2GerqicHAmp2vVEaIB7h8q2dQPV07z6v1bbYsk= X-Received: by 2002:a05:600d:8446:10b0:495:6e68:5df2 with SMTP id 5b1f17b1804b1-49d258d8630mr58912745e9.12.1789052791609; Thu, 10 Sep 2026 08:06:31 -0700 (PDT) Message-ID: <97689598-20bd-4d93-81ab-f74b6e5709d6@suse.com> Date: Thu, 10 Sep 2026 17:06:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 21/39] xen/riscv: resolve the faulting guest physical address To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-d25034/1789052792-024DFA5B-656815C3/10/73395122804 X-purgate-type: spam X-purgate-size: 1893 On 27.08.2026 17:21, Oleksii Kurochko wrote: > Take the guest physical address from htval and stval: on a guest-page fault > htval holds it shifted right by 2, so that an address wider than XLEN fits, > and stval holds the faulting guest virtual address, whose two least > significant bits are those of the guest physical address. The shift is done > on paddr_t rather than on the raw register: a guest physical address is 34 > bits wide on RV32 with Sv32x4, so shifting an XLEN-wide value would drop its > top two bits. > > Those two low bits come from stval only for a fault on an explicit access. > Where one is taken on an implicit access made for VS-stage translation htval > holds the address of the VS-stage PTE which could not be read, while stval > still holds the guest virtual address which started the walk, and the low > bits of the address written to htval are zero instead. htinst tells the two > apart, which is what the spec points at it for. > > stval needs no check against an ISA extension: a guest-page fault writes it > with the faulting guest virtual address regardless. Sstvala would not be the > right thing to test for either (it covers stval across every trap type > which writes it, a wider guarantee than what is needed here). > > htval does need one. The H extension lets an implementation write it with > either the faulting address or zero, so without Shtvala a zero htval cannot > be told apart from a genuine fault on guest physical address 0-3, and the > address has to be recovered by decoding the access and walking the VS-stage > page tables in software instead. That is left as a TODO, and until it is > written such hardware panics rather than acting on an address which may not > be the one which faulted. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Sep 10 15:20:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 15:20:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414875.1644557 (Exim 4.92) (envelope-from ) id 1x4gZ4-0001ob-NU; Thu, 10 Sep 2026 15:19:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414875.1644557; Thu, 10 Sep 2026 15:19:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gZ4-0001oU-KQ; Thu, 10 Sep 2026 15:19:50 +0000 Received: by outflank-mailman (input) for mailman id 1414875; Thu, 10 Sep 2026 15:19:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4gZ3-0001oO-AU for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 15:19:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4gZ2-0018Cw-GK for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 17:19:48 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2ca86-bab6-0a2a0a5309dd-0a2a450aafaa-30 for ; Thu, 10 Sep 2026 17:19:48 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2ca93-f2d2-0a2a450a0019-d1558035cd96-3 for ; Thu, 10 Sep 2026 17:19:47 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-498028b3d5eso69005205e9.1 for ; Thu, 10 Sep 2026 08:19:47 -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-49d26c1bc5fsm80054205e9.3.2026.09.10.08.19.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 08:19:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789053587; x=1789658387; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=VFGfL608L0tEIsdTQbjBfTAhVuCxwcfL5Ww2FNPtdYc=; b=OAxzC/JVhr5bz+9vW7kSQMC4YrbT0XRhDurJTzRqMDaDfaDigwKJn9HOphLv7aF9oD uckjE29axLW0M27b/tEcTPlqmOKx8lfEBm+1sEuiM5zUmPeVAbDhvH40X29UaC3kWVPY kGichyVD4SJ5iI8IWU/OLp/RMl1O0XtWuNqqo38UXrkPhdwV3WErcMLjZ0GMU/9C5eiK LIm4G3oUvIyKBkir+d3nMTo68gKgrSjY/HkGEmqzQVZLpKJ53R2Bvofe2uv5yA7BmY+K aFJ6eGTCwWyllzoEa0KwSDElBHh8L5ScPdwqB2uFYzInifOqej2BS/TJagBWWGpAk5uY P6Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789053587; x=1789658387; h=content-transfer-encoding:content-type: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:content-type; bh=VFGfL608L0tEIsdTQbjBfTAhVuCxwcfL5Ww2FNPtdYc=; b=PGLpnLQUz5jM5eYC+ACW2W1UcrPKjksviYB7JNPc771SVFBpkffLV6yWouV8r5EcGd MwkC1gYvRvm8vllVHUoUjbpFprGRVmbsTEl2StsiWG8QNzbDTsoyclWITONJWzmRLFCQ LFE6025nR5YbBELf2yYGvZBg6QSNKb0/t28oZH4Wh6yviEPBweTtAGfpg7eszp2xBqYN 6mBjbmEcQC1kF3RZpFI/9YAHjcuf3mcTmssfcRZ05tpwDdbmFxjkYZ/SB08LIKnQ3fFq 3Rkk7+LfLOHoDFE3hzkhlJixLY2i5Ss0vVlxN7wcnAIVttDTsFTFRdsyqIcPhD0MFfJB vl8g== X-Gm-Message-State: AFuF++niNOmmPXBg+eidQ1g7KQEGrBhSAL7cfwN4tDs9lIjH6UEcOrDG 3qReDVP8B8YXf1rHIvpd/V/Io0zg7Qyoh+oqIUnHD2KIvwW4+f6XT4LHB4rew9mhzA== X-Gm-Gg: AYBFou1OvA57Gljapb89PRAetlh3A/u6rZ5S4TZyHL55txzqodGCRp7jb4KLm8R9W3K tX84+vCX/JpT49ocMqNWsEWhDbJ+a3tXtixURczxB6suUn2PaRIIbeS5Jntorzf/Wk+N7YxRop6 ZgBCnN+BrZqNLHucYOn4UD/A3pLdCWMzCyTYPbS9XRSjiEZDm3bZc6N/hrp9qwGfh1s5cAVy0/z WnUGZld2TsuIiDhmMbmPUrXUHeERTKuHU9TitX793BmlQlRvhW5u+tu+6lAU8kLRKWegaYiCcZN tYXutrn2bzVlurbLMIpZSIQmcWeRxFMoq7BhGVCUgHBvupqVPLnBKrrz9lboH39c7x900vaA2G9 q+Y3wwDNzdtWHtD+L5SS5g86wyHZLwxnNfDBoiXuNqBhiD84Dqys6am9NEPDhFQDdJyvBM6Eoq+ CLMoCVrCU6iZOlzPaH121EtPdZxQo4PCOGVoIeOsveOMVYmZoLhS1oRC24eH1MZgtGnOjuBcMTM XR64Sb5RfPvKVr/nyQQA6zuu0YpBXhAO16pq3fRWmZ8gmbmiogVzHDx/N2+WVDWDm7PgiaunA== X-Received: by 2002:a05:600c:45d5:b0:49d:2562:d670 with SMTP id 5b1f17b1804b1-49d2562d699mr80028265e9.14.1789053586862; Thu, 10 Sep 2026 08:19:46 -0700 (PDT) Message-ID: <03f026a8-28ad-4d5f-bc0d-e78c1acb50c2@suse.com> Date: Thu, 10 Sep 2026 17:19:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper To: Baptiste Le Duc , Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3@vates.tech> 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: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789053587-587CACFC-30E0709D/10/73395122804 X-purgate-type: spam X-purgate-size: 3324 On 09.09.2026 14:04, Baptiste Le Duc wrote: >> Introduce riscv_read_guest() to allow Xen to safely read guest memory >> using HLV/HLVX instructions while reliably capturing trap context. > >> This is required for instruction fetch emulation and MMIO decoding, where >> Xen must inspect guest memory that may not be directly accessible and may >> fault. >> >> The implementation is based on kvm_riscv_vcpu_unpriv_read() from Linux, >> with one deviation: the hlv/hlvx instructions translate the guest address >> through the live vsatp/hgatp CSRs, i.e. through the address space of the >> currently running vCPU, so the function can only be called safely for >> current. Instead of taking a struct vcpu argument, it always operates on >> current directly. >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/guestcopy.c b/xen/arch/riscv/guestcopy.c >> index 8a89212e0b..b2327822ac 100644 >> --- a/xen/arch/riscv/guestcopy.c >> +++ b/xen/arch/riscv/guestcopy.c >> @@ -6,6 +6,7 @@ >> #include >> >> #include >> +#include >> >> #define COPY_from_guest 0U >> #define COPY_to_guest BIT(0, U) >> @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, >> return copy_guest(buf, gpa, len, GPA_INFO(d), >> COPY_to_guest | COPY_gpa); >> } >> + >> +/* >> + * Read machine word from guest memory >> + * >> + * @guest_addr: Guest address to read >> + * @read_insn: Flag representing whether we are reading instruction >> + * @trap: Output pointer to trap details if something went wrong during read >> + * >> + * The hlv/hlvx instructions translate guest_addr through the live >> + * vsatp/hgatp CSRs, so the read is only meaningful for the address >> + * space of the currently running vCPU. >> + * >> + * At most two halfwords are fetched when @read_insn is true, i.e. encodings >> + * wider than 32 bits are not supported. Such an encoding cannot be completed >> + * by calling this function again at @guest_addr + 4: the length check is >> + * applied to the first halfword read, which would then be a continuation of >> + * the instruction rather than its opcode. It is up to the caller to reject >> + * anything that is neither a 16- nor a 32-bit encoding. >> + */ >> +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, >> + struct trap_info *trap) > Nit: every other function in this file / declared in this header > (raw_copy_from_guest, copy_to_guest_phys, ...) has no riscv_ prefix. Why > does this one get it? >> +{ >> + /* >> + * Poison the result: if the very first access faults, the fixup skips >> + * over the loads without writing it. Callers must check trap->scause. >> + */ >> + unsigned long val = ~0UL, tmp; >> > The actual "did a trap happen" contract callers rely on is > trap->scause == 0. If the very first access faults, fixup_exception() will > write scause accordingly to a non-zero value, but nothing in this function > clears trap->scause on the success path. So perhaps the assumption is that callers pass in a zero-filled struct? Would want (need) spelling out, though. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 15:29:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 15:29:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414896.1644568 (Exim 4.92) (envelope-from ) id 1x4gi0-0003r8-I0; Thu, 10 Sep 2026 15:29:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414896.1644568; Thu, 10 Sep 2026 15:29:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gi0-0003r1-EB; Thu, 10 Sep 2026 15:29:04 +0000 Received: by outflank-mailman (input) for mailman id 1414896; Thu, 10 Sep 2026 15:29:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ghz-0003qv-4Q for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 15:29:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4ghy-00BFUT-GX for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 17:29:02 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2cca2-2eae-0a2a0a5409dd-0a2a4507aa56-20 for ; Thu, 10 Sep 2026 17:28:58 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2ccb9-b4ea-0a2a45070019-d1558031e5d2-3 for ; Thu, 10 Sep 2026 17:28:58 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4957eefd361so56835165e9.1 for ; Thu, 10 Sep 2026 08:28:58 -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-49d26c300e2sm86166185e9.8.2026.09.10.08.28.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 08:28:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789054137; x=1789658937; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=YmRH8clDkwZLuTytZukJgH9gKU+dqVofznq9Me5p3Ag=; b=XZ0LR+TA+zOVZmaPSuZObPZu4FEFF3g31USGttIvH92wejGTiX95Iiepb6skPkhN/P DC6IxzdrollZ3lmx55LPxuo/ykWbp19s+m212gVuytX/5aCyjiObpQlK4/28fcEdM+7c lW2n2+NuRM2/pcXeyFcvAQhr7L7VcciTWQGwloJXGdaMV7/DsOqx3ybmaHi5Eu79kNdv qj/cy178+BGnIVbljo1KN9EwdNMflckaT/pmYihvezaZLWPHihUJxAF46EK18qKh/dZ0 qJgCLED6QNU/IOIBB9JAdSZwc7uPuVnET4SFO0q9MIo4syzo5oV1c/SMvRgJAH61S6sT nICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789054137; x=1789658937; h=content-transfer-encoding:content-type: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:content-type; bh=YmRH8clDkwZLuTytZukJgH9gKU+dqVofznq9Me5p3Ag=; b=nBDSXWMM3nLOlmm9jCoXSkKbF7fNvnKT3gyEXRtA4/EQJqcK1MGuZWl3nkvmGFsyvK +ogAnu/T15MxyF0kcybsqerro4xjKz9bfl8D0EuLH1EbeQpNvpdeteVAdOZ3yaftR2aR ViKvC6AWuea0dcSQYYS5EeHKkNtcxYvXUyWELbtfZ3alLSdcY+m8x0PQ2rJJ8h50Kc6y 2e7RuKdICKacXNk35ZBtJluoK5mNLM05Ikzc12O0UURPgRtRncUyFaxwtVjC9DLtvswx mc6Ms5ufXIpQMZkWzst+EjdhiBKd7qCVihGJ6+J2acJvu4yB41QIJhOn/QiqsBLHq/BC fNMQ== X-Forwarded-Encrypted: i=1; AKwUvBzGgNlyhsgQODcATmuOKU91Oz5wGOq2geOaExf8qBCyujpb1D7l/2aLoKrTYgMPFCSaM4mqiQpy3tY=@lists.xenproject.org X-Gm-Message-State: AFuF++koutOoPhWQ2lBWur1BbDI2SnZ3G2SgQFmkBtqSJebf7LkhxfvV /9Kjt5POCa4KLSo5CYz1HweErepXQoUOq9rwUCdU7cuSrb+pwLPundWHI6oH1B/brg== X-Gm-Gg: AYBFou0149+79bYunsCHkWgVHHLGkZT8mpgoxxEhtQlMQVcRdMLbe0poYUaHSjK247I ON/NPlvW+Ya0FQHyq9HY2dZckInIz0zStS++EvPTks+MIhiqg7/ACVzJeSeUPXWwf/Is+xXAD5g gVGD0of5D/0Htqu63Bs2F4h1I47RcY8gYmYmqx1YUCgP7k4z0GmIr5M0BeUww68KXi/mNF/U4Kg n+B8V1ql4eWybqMwzjmwMqHdb00qsbbNsQSCGMfZ2CBl2P3aU+8VrOS1WSd6LwiMnbEX5RAgkKb V9Or4T3xBTS7ZKAO0w5uqvFWgwLpz5+9r9rd4JqstFPATO3ezfiRVvpkOS6RncxlbCXAGfWHzCr oWGc7mcb4m0Zxw3GYiLsfXw/vezDNWucrOkc/ZelNbJsVOP4Wf1y9Fsa4s6wY+uOKIfgCGiyt/l f49hFpdvNL0ceX5HPBp1kFX01oJ+ifUKDBQmNfrY2i2iDju3NfvOJoUoBuI0Tc3NcmQfa5Tmd5L ARHjK5INAudjtaI4+O2g/yA/IXbh2wjKqPdKSl2yvsK+H9bnvB8IoR6KdagajguQD7gScjxLK0= X-Received: by 2002:a05:600c:4ec9:b0:49c:fc6e:a3d2 with SMTP id 5b1f17b1804b1-49cfff39708mr375762685e9.17.1789054137446; Thu, 10 Sep 2026 08:28:57 -0700 (PDT) Message-ID: Date: Thu, 10 Sep 2026 17:28:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-ef75cf/1789054138-358C1AE4-771919C7/0/0 X-purgate-type: clean X-purgate-size: 3160 On 27.08.2026 17:21, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/guestcopy.c > +++ b/xen/arch/riscv/guestcopy.c > @@ -6,6 +6,7 @@ > #include > > #include > +#include > > #define COPY_from_guest 0U > #define COPY_to_guest BIT(0, U) > @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, > return copy_guest(buf, gpa, len, GPA_INFO(d), > COPY_to_guest | COPY_gpa); > } > + > +/* > + * Read machine word from guest memory > + * > + * @guest_addr: Guest address to read > + * @read_insn: Flag representing whether we are reading instruction > + * @trap: Output pointer to trap details if something went wrong during read > + * > + * The hlv/hlvx instructions translate guest_addr through the live > + * vsatp/hgatp CSRs, so the read is only meaningful for the address > + * space of the currently running vCPU. > + * > + * At most two halfwords are fetched when @read_insn is true, i.e. encodings > + * wider than 32 bits are not supported. Such an encoding cannot be completed > + * by calling this function again at @guest_addr + 4: the length check is > + * applied to the first halfword read, which would then be a continuation of > + * the instruction rather than its opcode. It is up to the caller to reject > + * anything that is neither a 16- nor a 32-bit encoding. > + */ > +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, > + struct trap_info *trap) > +{ > + /* > + * Poison the result: if the very first access faults, the fixup skips > + * over the loads without writing it. Callers must check trap->scause. > + */ > + unsigned long val = ~0UL, tmp; > + > + /* > + * hlv/hlvx use hstatus.SPVP for the privilege of the access, and the > + * live vsatp/hgatp for the translation. Xen never installs a value of > + * its own in hstatus (it is only saved on trap entry and restored > + * before sret) and it doesn't reschedule before returning to the > + * guest, so all three still belong to the vCPU which trapped. > + * > + * Check the saved copy rather than the live CSR: a nested trap taken > + * from HS-mode clears hstatus.SPV in the CSR (but leaves SPVP alone). > + */ > + ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV); The first paragraph talks of just hstatus.SPVP. The second paragraph then starting "Check ..." means that still refers to hstatus.SPVP, when - aiui - hstatus.SPV is meant. Furthermore, instead of special casing nested faults here, but otherwise saying "Xen doesn't modify", wouldn't it be better to word things such that they remain correct if Xen ends up having a need to touch some other part of hstatus (including, potentially, SPV)? IOW - I think it is natural that the original guest value is checked. Question being of how much value that checking is: vcpu_guest_cpu_user_regs(current)->hstatus can't possibly have SPV clear, can it? Only nested exception frames could. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 15:31:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 15:31:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414907.1644577 (Exim 4.92) (envelope-from ) id 1x4gkV-0005S3-0c; Thu, 10 Sep 2026 15:31:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414907.1644577; Thu, 10 Sep 2026 15:31:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gkU-0005Rw-T7; Thu, 10 Sep 2026 15:31:38 +0000 Received: by outflank-mailman (input) for mailman id 1414907; Thu, 10 Sep 2026 15:31:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4gkT-0005Rq-Fm for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 15:31:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4gkS-00BQ39-Ah for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 17:31:36 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2cd54-2eae-0a2a0a5409dd-0a2a4508d1fc-18 for ; Thu, 10 Sep 2026 17:31:36 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2cd58-f659-0a2a45080019-4a7de18c9b75-3 for ; Thu, 10 Sep 2026 17:31:36 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso16734105e9.3 for ; Thu, 10 Sep 2026 08:31:36 -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-49e60acff8bsm2327695e9.9.2026.09.10.08.31.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 08:31:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789054296; x=1789659096; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=x4SPLbzlCvwgwrhKUAWcpiIrjD9PKd3A7Z3K0mUUna0=; b=NaNXnuhM2b2iK6iMTI8JOi1TbswxAhRFPh0ZH10p0paQtCa4OU2zWTjwYSeVn3fPap 8APWkYDdHeeWWxEUM94qeHNUO2ViLoGSusnXsSoCIHKKLbLGNiPSulZkC36HAtcnyHfg flehqC8kiuBecMgE7j5NYm2WwPCbkDTZCXQNjgvjyCBTAGvbrmibpzlTw/F1LK72BLq9 KBpcu9lFVt0zgaOpp3eatbPdVj3pLeix6P3ufddPHCteLq3DuUz3GTYUbUk5nWpr7GJp OTqIxX6lwNvsYfgDRdNJmy3f6rXt/qRtKO2zNpiJh1tAtBUhwvXoTvULIOSs4HEwXkuC XboA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789054296; x=1789659096; h=content-transfer-encoding:content-type: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:content-type; bh=x4SPLbzlCvwgwrhKUAWcpiIrjD9PKd3A7Z3K0mUUna0=; b=cQvoPsNGQ4ebLQjMqfKgEnhEXpnJ/dx9UcQho75cgPRscY09hOYvURFsKhf+RA99xd aoSWK4hDlO57xCKEKOTudhcciz/564jhUadjd1if0JH21XC5oNS6N93B88dM/EPo0egR Ha9pOoWpy+sPikSLstCyB2tPxGgHdqumXOzwfx1uL7RDeCJ8Ttr3iXxMNccTcNe8HaIV opGqv7IsiRvSMR1UpOV1Tf7uNRozQAahb5gZeTJMqae1xDJepbI3S0MZGXjVKwY+m1b1 e3dUtCSncwDPY4p+aNxUQUp1WwAq8HYywkD2lBVjcA42g8shEkJNYiBkyOd2GbukftGz s4zA== X-Forwarded-Encrypted: i=1; AKwUvBzf2NJYgZrqm5VVj4qDKwlMgy71ybXla1EDnnEzqlSTTrijTfvFt1SfPGDU+CLM+UXpib3HJ4sgtUk=@lists.xenproject.org X-Gm-Message-State: AFuF++lm0i8KtDNLpro7u0CArMIzUkgfrms8oFhuDL8CUnxtuUVtidih qOnbLyoUKcoQ9ph49BwujFXIyxoZ71hejrocEscPa+9i5kdfv1Xky3hh+DIrYDxivg== X-Gm-Gg: AYBFou3doC8J7aK5oLo4MuX243ZJKeUUW7UE9EKnXkCJ8hbpWvwWx+cn8S5zAoQ4NH8 y8vGZ7o3hpEDSylwffjvpjBhMvPqErwd8k3kshRsMIjiVs8Hg9enPSdcslMu14LhFxfgpIMNPqw 1ACxG1MnFDOwhk4QUMU7LbE3M2RWcPeIHP4La0pjLGtVHXxrw9JK3C7Zw8WZEKUPAd8/llOBETC aelxd1OOizhX0YsVr0q14fGwlQXG05YO98sdsmQ+yBrxHJame2u9Gs80eZsMiP7fLnuAOu8pJYN uAvgr5CLCHsNcqlSrs2pWyL9Q32WolxPPOz8S/jFk2VbzFaBAKBxLey5ZXdGzV/kMM3F6+DrAhz 2qoQoT5TrvEHSdGIwbz8IRuMrOQN+UfvOuB2ysGMEEhDax9V5gte0xIXUn7a4PUfY+PaVB1z0fX 6xUMomfFqNhy/0ryKycsbSZeYUlevamL9vCUHBJMFaJsqMCQNg3fvnPST+GBqOzbERCSxKEuYPM 8KFbwnjcEEtOxPpzbWj8far90Yk+5sCQU9tppNP1khlITqdrU6hsysfZd5JCw8= X-Received: by 2002:a05:600c:c48f:b0:499:4e47:eaf2 with SMTP id 5b1f17b1804b1-49d258cda4emr80092025e9.6.1789054295628; Thu, 10 Sep 2026 08:31:35 -0700 (PDT) Message-ID: <9d80640b-5e55-43b3-b4f5-fa91b1fd0bd8@suse.com> Date: Thu, 10 Sep 2026 17:31:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 23/39] xen/riscv: look up the exception table for any trap taken in Xen context To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-c1860d/1789054296-CFED287B-08D6841E/10/73395122804 X-purgate-type: spam X-purgate-size: 1572 On 27.08.2026 17:21, Oleksii Kurochko wrote: > do_trap() consulted the exception table only for CAUSE_ILLEGAL_INSTRUCTION, > which covers csr_read_safe() but not the hlv/hlvx sequences reading guest > memory: those fault with load/store (guest) page fault causes and would > reach do_unexpected_trap() instead of their fixup. > > Move the lookup ahead of the cause switch, and gate it on the trap having > been taken in Xen context and not being an interrupt: > > - sepc of a trap taken from the guest is a guest VA/PA, which the > guest can point at an address listed in the exception table; Xen would > then act on that entry and, for EX_TYPE_TRAP_INFO, write through a > pointer fully under guest control. Entries are matched by exact address, > so this needs no more than a numerical collision. > > - an interrupt taken at an address listed in the table would otherwise be > "fixed up" as if the access itself had faulted, silently skipping it and > handing the caller the interrupt's scause as a fault cause. > > Returning early skips check_for_pcpu_work(), which is correct: that only > runs for traps taken from the guest. > > With that in place a G-stage fault reaching the switch can no longer have > been caused by an hlv/hlvx covered by an entry, so anything left must have > come from the guest; assert as much. > > Cache the "trap came from the guest" test in a local, it is now used four > times. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Sep 10 15:43:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 15:43:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1414934.1644585 (Exim 4.92) (envelope-from ) id 1x4gvg-0007e0-Uf; Thu, 10 Sep 2026 15:43:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1414934.1644585; Thu, 10 Sep 2026 15:43:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gvg-0007ds-Rc; Thu, 10 Sep 2026 15:43:12 +0000 Received: by outflank-mailman (input) for mailman id 1414934; Thu, 10 Sep 2026 15:43:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4gvf-0007dm-FF for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 15:43:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4gve-00BHK8-S1 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 17:43:10 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2d00c-8faa-0a2a0a5109dd-0a2a45039b58-10 for ; Thu, 10 Sep 2026 17:43:10 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2d00e-fae8-0a2a45030019-4a7de18caa3a-3 for ; Thu, 10 Sep 2026 17:43:10 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd5462b69so15524655e9.1 for ; Thu, 10 Sep 2026 08:43:10 -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 ffacd0b85a97d-486e6eeadb5sm2510570f8f.16.2026.09.10.08.43.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2026 08:43:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789054990; x=1789659790; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=lUXWFktijKPivybQktG6INfkLCcNzEC3V3paUeV5EbM=; b=LF88qWF9t6f4Loeine9eUASPpDo9SNUr3ydbuKPeDIOmJQLU+TclSW9VZX9j54iMK8 N58i6Z3ndc2ca335YPqMObHb66nPov7+5nxJOw6EgSiTISIspWI8I+WJJnJ2b8U/gppM YYn9SfGKDrsHrKQi5xO/OuzdnB/JUTLh8Sji01jp5fk9HeIIsjAv2xnMc4aCTT/Anuch iTVPRzJv16WvLF+Hmwo5LAuxlBepo9F5zVm3JjJNYxGNHs8uZ/MZoSBSCrM/nYlQDoUh NOi9eCpTnb8gkauJhUvpmHJFydPrfb3COeZNpP6MDfJwrxCaUwZRL0fHTNMFWKVGhoUG Cbew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789054990; x=1789659790; h=content-transfer-encoding:content-type: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:content-type; bh=lUXWFktijKPivybQktG6INfkLCcNzEC3V3paUeV5EbM=; b=RDeZf5o5eDeEhlmcoEpQckYrCUOblwLl2uD3LvViIzk86oIA1j7rSWCWOKnZI2Ms4/ XYrZj5W92BHJopNgRFTo8vf7d7LVFCiwUl8wqE90lzBlwGw71IpRXS7R5LQ+goh3MSnW v8Z8NEZJnVcA9cm4ObtO8kSasUtKd1+UN//Bw43sIbhfJouIivP/6sApdi79MCY1czIg 5CnrWtqi8UDHHXTw+uKVVNLbMUbxoE+kJcO4g0kcI86wcWB0buPU3bJhmLxl9UW/d9Ml f26o/aFf8kWd5s/dNi2u5y459pmLTckv49Yi92+QfvILUnO6FVuvgiXSltZeSSaqp4EJ /0EQ== X-Forwarded-Encrypted: i=1; AKwUvBy3tE82bYgcmXxqQwm9gCvzQA/8wBWdDv9IDRaEBlDQms+qti63kNWMaPKyU6i9IRYNiuSY1GM3Y3Q=@lists.xenproject.org X-Gm-Message-State: AFuF++nI6yK8xQKghI+Ab1rJ8lUnjUfDjWhh3UpyJNerbNttttL7FLqh tYa6g7GDxQTqF/PlOFfpCYW3WwEsoSNgXeSNOiA905hgMd+j/P7fpjA50aM8GjcgcA== X-Gm-Gg: AYBFou1DEKUUuZY96N32elYFrmodu34Q+tF57+nwFxTaa4jp6DXwJx57bc4OlrwQ7Pu sU0sdKEGQXDRjdZvPS17LHk4F9HhoWEMI3+OY4H/WuPLaobT+gf7GOODBewnKwiWIip+B6/Pgcr 2DZFwOr1GcSuQBvGNjdjaUDh0PPqL8GHyIWbS+FTYbyARjnGxkP3xMR8/ITp6KXZwpUfua8n+Jb HC+q4ATQwfJcR6yRIX3jzkydmfdR7GuFyvyWv921CgSTXJK/0Eyn0GTztd/kXoaJsU/q1YKKHol s7wodCvTss5ZPu4hT1memDjtu230x/iIZ51wh+5F6w2fNFWSQuyTsgTG+AVJ6KFBGCmR+Zua02Y jzyFZZZk2+jzrXL7Qn4UUr3ZrQrFbiFXRNs7BnPXjXIwkS6umqzipCF8E+8yaN0kA5hi4o/ANbP 18KpEds+Hlbe187xG2DbfqsGVlapUesNtqlXdP2OsQDZavBiTfGbn6grxi98F+i1IvrOWbSP/Op cpPJrb93AEha4vuMvD+xiXK/1710QUFgrJ8YrdhOkO0F3iamrdoZh72ru+3n68XtJqETBJAxw== X-Received: by 2002:a05:600c:698c:b0:49c:edfe:d525 with SMTP id 5b1f17b1804b1-49d1f35366fmr294544695e9.10.1789054990252; Thu, 10 Sep 2026 08:43:10 -0700 (PDT) Message-ID: <1a42fad1-922d-441d-9837-f4c43854a5b1@suse.com> Date: Thu, 10 Sep 2026 17:43:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] vmx: Refactor vpid_sync_vcpu_gva() To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509305.8631fc262581453bbf619ec5b2062170.19fb8a5db67000e099@vates.tech> 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: <1785509305.8631fc262581453bbf619ec5b2062170.19fb8a5db67000e099@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789054990-6F0C94E9-395B03D6/0/0 X-purgate-type: clean X-purgate-size: 1302 On 31.07.2026 16:46, Teddy Astie wrote: > --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h > +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h > @@ -460,19 +460,16 @@ static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva) > * If individual address invalidation is not supported, we escalate to > * use single context invalidation. > */ > - if ( likely(cpu_has_vmx_vpid_invvpid_individual_addr) ) > - goto execute_invvpid; > - > - type = INVVPID_SINGLE_CONTEXT; > + if ( unlikely(!cpu_has_vmx_vpid_invvpid_individual_addr) ) > + type = INVVPID_SINGLE_CONTEXT; > > /* > * If single context invalidation is not supported, we escalate to > * use all context invalidation. > */ > - if ( !cpu_has_vmx_vpid_invvpid_single_context ) > + if ( unlikely(!cpu_has_vmx_vpid_invvpid_single_context) ) > type = INVVPID_ALL_CONTEXT; > > -execute_invvpid: > __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva); > } But this isn't functionally identical to the original, at least in the cpu_has_vmx_vpid_invvpid_individual_addr && !cpu_has_vmx_vpid_invvpid_single_context case. We'd now end up using INVVPID_ALL_CONTEXT there, when it wants to continue to be INVVPID_INDIVIDUAL_ADDR. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 10 16:40:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 16:40:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415007.1644606 (Exim 4.92) (envelope-from ) id 1x4hpI-0000Ck-21; Thu, 10 Sep 2026 16:40:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415007.1644606; Thu, 10 Sep 2026 16:40:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4hpH-0000Cd-Vc; Thu, 10 Sep 2026 16:40:39 +0000 Received: by outflank-mailman (input) for mailman id 1415007; Thu, 10 Sep 2026 16:40:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4hpG-0000CW-Ej for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 16:40:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4hpA-003J9P-49 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:40:37 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2dd73-bab6-0a2a0a5309dd-0a2a4502d94a-18 for ; Thu, 10 Sep 2026 18:40:32 +0200 Received: from [40.107.208.23] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2dd7e-6ca4-0a2a45020019-286bd017479a-3 for ; Thu, 10 Sep 2026 18:40:31 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SJ2PR03MB7527.namprd03.prod.outlook.com (2603:10b6:a03:559::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 16:40:28 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.005; Thu, 10 Sep 2026 16:40:27 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W3aes8S04P1I6EKgXB/du7fQHg2nOCfPrtdlVWHmLysZgdG0oOPc7Oyd8+vh6yhQIo9Al+oKEeTusnQnk5XYBMw6aHLfR1lQN9n+AFZLv9r+2WKyovgcK7Hs9pQiDxnvO45YfusKlBHz9SLdqirrCOJAiA4pTrnjwJOLqoJuqO9BOs1/1F1YJccvh0kHtgIZCodILqkGvt/W2SHOg2R7ZqtbxTGynl/aixn0z3n6O45EsFr1fcYnMZGLel63VlmpwCuKBBSESeE5+Pza9gQv1Js4g5ea9MzOs6lEkzwxpRDMLDqhPxC6c7lP3XqqXV3hS4c5Kum66GsJcuHOVPBboA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EN+seTtA71auXJ8SVZ2qyGkvZ0DPlUOwnVfxlApHbf0=; b=IqXURYwR2WyxWtQKZQOZy13lKDYPNeZV0ZbfibmfJtPZwl7jQZsZwK8RFbNAX3SdUqEuFu0owNBEgPVSgMF38XPrvdvKTltH33tOdQ2MPWL/3qaOJLo2LUnaDgRmKV/dXFpW4oal9TMoKuGY4qpcSYLEYTTvD+YD9DZzFeHGfXmp8yJ2xyUQ0Pu3NptCsYAr+Y64tcdm7WyMXBZpr5OmXoRNdcBos79O4Ifs8FrzviU/NuBlvrYcmiXxyErrTtk3e3vIWoKOEBojkNcL2WQ9fLP/gkl4gbS4takn9oM7tAackZ2YsAUdrTdWT/nh4zaj/Jb050+YkCJLrwfIrUHvIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EN+seTtA71auXJ8SVZ2qyGkvZ0DPlUOwnVfxlApHbf0=; b=mNN0cJ3hlcA5qr9ptVPHqrK6sGyUpKKh0S0JVq/yEA5hMC5AFm0liol97NXNDIA2LGcL+97fFl09A6O3xCIjEGasO76KnX0Az/8BVbOGYNybYgWuAmlqwacAgI/SmiflfZ7jEUhI8QLk+gNG1lk5KKLNELklJ4X2RBidtdyDUv8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v1] nestedsvm: Fix multi-byte IO port intercept check Date: Thu, 10 Sep 2026 17:39:55 +0100 Message-ID: <20260910163955.1005097-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: AS9PR04CA0112.eurprd04.prod.outlook.com (2603:10a6:20b:531::13) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SJ2PR03MB7527:EE_ X-MS-Office365-Filtering-Correlation-Id: 4fab52ff-3969-4efc-8e9e-08df0f5a3858 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|10067099003|18002099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: zXP2MjrmjiDZx/202RUXNiV76OFezqs//1NI6+nHU9dMJdRQtwwA2Oz4vlMXyP7nLE6ontW1lMVT9j4CroalhtHyqv3ad7kXwGYgIiaXEyJGQy/5POGnk0Dw6xzMkdFU0dZWWwHlA/3D5vxKBngXy48ZxLwjFvTdJqVsxpHSSEk0eQ3K+o2Vort3iNdyrC73XFwLZSOZXd74G63oKdU5L9euk8PI3rd/geM/pMAspfVW3A0MsGneU8QaL0UBjo9q+/DpNfuYlscV4Zv54oYT+KrxsZ+EOKZyDaUqnxxJaN3TOt24wfcpvPnfhfxxePMmnAo+zSJJHn7fmCABfGVpQtR7/4RxQzJkeefCJJ4mX1/zWCYSHJcQHHkoGMKz9TNUyJJEyLOxykjzLQSyO9iiY6RorqGIMANqHXqlKGXkBfFKX7WSipGFyCwH0QQOYRtVxw7pxy36xrsZY/Mc4dyLQ4LmKTgviABa02+w8G1pjRk6/1reXHpVWmM9P6MvYEzMaiV7TXtJ2Zt69GrhHoWWuRnoQHR+hnkJVbgDdOhQ2AddvzJzej/CxEM4UYPdzbLIkUiv8aEx5DEH3z3/qCWvAI2aVzscwuuYzsCSaEJquFm5fyx7k+PFFJBe9IXl74sgthuA8SbNwUClowO16VMIAfjaHwf6SAGVyPXPAUNTp2c= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(10067099003)(18002099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?a3n+8p+IueQctOMf1Sn4t19JJtT+MSPncgbt4874lCLn5A2Iz63PjlNqgHPg?= =?us-ascii?Q?RT/tiv7HAmbcWR7bdZUKcRrROs5hZchRkAq5j5jl11KnsU5re9Sc9/BjprcK?= =?us-ascii?Q?NjLr+whvUpAfdZd3AuEjeUdTu7ZG+3sMisNq8HCau/yK441DOTrsLtnjybIt?= =?us-ascii?Q?0NNIFlz6923lEW2IYwEahCVigtfFwGlVl0JGlBz8pURo4gsn5kGunQqUgju0?= =?us-ascii?Q?MdMynwmFYoWeVVIOS4J1g0wVJGm7yVUcAWhBPpM5VmGJ4pbs7eKdeMtyJu+t?= =?us-ascii?Q?9A/MfH2SU3DN4ZQgsEAF65hBmsfq0YCaDxTw9Fc5R8EAsSFjLiXiw3F56jUB?= =?us-ascii?Q?TA0RHF/gql+fwx3FTZxaVClJQwHNZMaVg7TpqONxszvnojI0NbVmLrC+Hka2?= =?us-ascii?Q?eoke8VQ0EFWjnnjsXvTgTyfCEDNrXz/lXjWlAbIO1yQxXEwa5/iP9FC7+M9s?= =?us-ascii?Q?vZtSfCflqU1e/Av7BOE63q2vSIP1A3pEXwLklAy/6cyWecyMAYlqa4E4T190?= =?us-ascii?Q?3/vk60Oy9pVmrhA+SSpFhtPjMyzztRp8vETwIPCX4t8cnaQ5xFKzCl/T9swA?= =?us-ascii?Q?mI+R0Jgz0In7votKni9XJwCWqgA5Z7b1KIR7hm2UTYQGSoYr85cGUgWC5UeM?= =?us-ascii?Q?ZaMVqdsXqVCEF1yh3vfwwElP0s8trZd8jZBz7RGoB5UWcjsF+wCF35zmSRdN?= =?us-ascii?Q?D+rSP3qrKo+NygaWcfYd0FY7wipAkvbULMDLslMvNg5b4liBKOnqBzHEQeVn?= =?us-ascii?Q?mNRRXqrAHVxbuLU/29/4cIUweyd2ZjrTVdnhF/it45qZFfzfCxqxu1/hKXLe?= =?us-ascii?Q?f0T0dtGH+n0osw3JS1v/sGrx0uLj6u9vCNj2qytMKqADxRU6mVnBqx27u70t?= =?us-ascii?Q?/hqBOqjDAUTmpol2GHbisRnQeBzCdLVnJf2mqaEr2fU893O+AWWC7fkOdkVY?= =?us-ascii?Q?RFwbn9pVkkgIxuYcfqxjg2KRnjrx6DyQEJX6VVqF8azkuLRCxu74WuwZU35o?= =?us-ascii?Q?MtNIbjw+24424YYd2dF4MaFN30R/QFixCKRG3e5KeSWY1pmMNAtDvRUgwb/2?= =?us-ascii?Q?+mZUtJxsQ6swjh2tMltahWNshWgTLCKE20b5c3VwxJWowcaVSyIhiPpqOABi?= =?us-ascii?Q?vMD6zGpEaOYGdB7T0b7lsUEEg8svxdx4R2dmAKySmBdGtKdbsPvTvOg+NOFU?= =?us-ascii?Q?O7xDnHDHjSPWquWAeZiZOwM1t527L2I3AG0W4ReCko3CzY0iOdaQu/tYovOM?= =?us-ascii?Q?mTcWNlNa+9VB2bcdqbiscl2SboLIMnpgD3ICX8IqVeGAZusWvTpc/gXWKghy?= =?us-ascii?Q?y2D9Zj2oi4A201e8wzfjxcHiPoMvvz0SuV1xEitQwrXON+gkmYTvSaxBgjCc?= =?us-ascii?Q?tHcnxowoN9xaD0E75ntchAFOdju+nIQR/lPiUwqUKpQzPBcKP7KMUnPN4pHn?= =?us-ascii?Q?EekL48s7u3k0r28Rlnyw6rZUCpJpB/h36GnBllEOlWSwePwnhosTUR11O1rk?= =?us-ascii?Q?7anjImZ5NXv4a5Hw+WNY+090VSCGs27pnW8mcWr6k4Ces8UigjLs0i2QMEjW?= =?us-ascii?Q?4vmx/UVNNfYbV1l7uqFY3Y3L7o6N9GOkYKDG+Fi4vGqwj4vQkncB8NUctwLI?= =?us-ascii?Q?GcaoO1/Ply3xJcYmYQJhDHrirC8coRUazU1WCsKWgQUTwNJpNmV+HKgSmQVr?= =?us-ascii?Q?+ZQtSAYpqGUxEpCaGy5WMRLfMwnrVd7IIayMQXOz/HcwaZOBnllr7XbDJ+fp?= =?us-ascii?Q?YViVAtcb/8EXja09ESNZ/TVUJi/ESCk=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4fab52ff-3969-4efc-8e9e-08df0f5a3858 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 16:40:27.8982 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: C0Dl+u4jd/Mulj/T6+8wXRreBIii8rVWMvaMhrDyFhUhqItb13whwrMwBl3AGGPzXcg2pCrObdXObQYUaSDnEs85ooLGcO8k3hkwgIyknTA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR03MB7527 X-purgate-ID: tlsNG-720697/1789058432-F10A02AC-18BA0FFF/0/0 X-purgate-type: clean X-purgate-size: 1261 For multi-byte IO port accesses, the APM says that SVM should intercept if any of the corresponding permission bits are set. However, the code has this backwards and only intercepts if all the permission bits are set. This affects Hyper-V since it does not generally set all the permission bits of the multi-byte ports it allows its root partition to access. This results in an L2 root partition that cannot do PCI config space accesses and therefore cannot access its NVMe disk to continue booting. Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 5adb1bd72c4d..249fde43b5be 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -852,7 +852,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t iopm_pa, uint64_t exitinfo1) for ( io_bitmap = hvm_map_guest_frame_ro(gfn, 0); ; ) { enabled = io_bitmap && test_bit(port, io_bitmap); - if ( !enabled || !--size ) + if ( enabled || !--size ) break; if ( unlikely(++port == 8 * PAGE_SIZE) ) { -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 17:59:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 17:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415096.1644615 (Exim 4.92) (envelope-from ) id 1x4j3S-0002kn-D1; Thu, 10 Sep 2026 17:59:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415096.1644615; Thu, 10 Sep 2026 17:59:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4j3S-0002kf-9h; Thu, 10 Sep 2026 17:59:22 +0000 Received: by outflank-mailman (input) for mailman id 1415096; Thu, 10 Sep 2026 17:59:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <39O-iagYKCbstfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>) id 1x4j3Q-0002kZ-Dk for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 17:59:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4j3P-006DKw-N1 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 19:59:19 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <39O-iagYKCbstfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>) id 6aa2eff4-bab6-0a2a0a5309dd-0a2a4507a67a-6 for ; Thu, 10 Sep 2026 19:59:19 +0200 Received: from [209.85.214.199] (helo=mail-pl1-f199.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <39O-iagYKCbstfbokdhpphmf.dpnyfo-efwfmmjtut.yfoqspkfdu.psh@flex--seanjc.bounces.google.com>) id 6aa2eff5-b4ea-0a2a45070019-d155d6c7c98f-3 for ; Thu, 10 Sep 2026 19:59:19 +0200 Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-2d63bad3d09so115518995ad.3 for ; Thu, 10 Sep 2026 10:59:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1789063157; x=1789667957; darn=lists.xenproject.org; h=content-type:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VdUk7xT6Q2S0XYOIdYUuypvFM5moeaGi7+AJeTxN8N4=; b=WFP+AFZrYHH0SQy0PqX4Us9uYX9nfMhqip2FWF6A5Q48FIDJ4iAh43vo/vuKRnCmfm XUPjiCa+nLD74io6+U9j5ipK7rkbDU2LUnwcywkxMKcgMzQmHhxW7HwlCld95hEZEXzf /IHonfft51t3aC9+BMKrgddwkwxer1nruxgGy6qViOJQK3wgx6+GjgHxD7IQYz3wnfQ+ zDyyAjt8jJIP13n/E+JVZDHX0jBvSBC07N8WG+QvsR6jTO3bQokzbO9hMeHDWPsTT5oC 4SZG4IaqdYeG/PWbg0KA5T/KIMzXj6MCqn6Ij23QWcQhUwYZIwNBi2UAPaVLKlz6F5Zr xffg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789063157; x=1789667957; h=content-type:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VdUk7xT6Q2S0XYOIdYUuypvFM5moeaGi7+AJeTxN8N4=; b=NO/ooxkBMdgJdai51JeyjHsUwCILGcxrAUzZq7eS04wpTWeFCCBuFak1gn7KdNLMxT OmwS6Yn/uHlb7nSmnem3+SibNgnPB4N0R/iQVzuEjHrC4EKpaLbbcO4NC9jfF/f6g0f9 Z660dNUlW00XBRgg3ioVlFagJZcIY42H+a6egv4AKAcz/Qveu7i1maKHIghtD4SP/y96 9dDCEIm9xDWncvcfwjVyTpCptfJ+6AHauguVnKW+amHzpvmNHbVD9+eAn7fOHfLL1DSu hWVUNE9wkDphIVam+U2sJwdrY5/UjdiLNyFG8xzUT05YQakJ5uhWt2zbERhO3YX/YjP9 CpTw== X-Forwarded-Encrypted: i=1; AKwUvByJWqULdlexu43dUEqOaQKYah4Ha/Jk8EkvP5bIlp1+G8H5Hdd4xjxaA8HkSFgOJeppPwlUIKXcIss=@lists.xenproject.org X-Gm-Message-State: AFuF++ncC1uOj/lDct6yIn9fAQcUmHkXm+iqisuZG5WF7qzLkePHUtP7 XAcRIfSqDrhjHRCmw6+1KEg+LzsvGEPD8F2wSN1+OQiRC/hCDshyoVtd8z1pHkh26FcLGoporbJ S90rAjA== X-Received: from pleg13.prod.google.com ([2002:a17:902:e38d:b0:2c9:b703:3bfb]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ce8b:b0:2d7:2edd:d140 with SMTP id d9443c01a7336-2dd2a1c3e42mr9017035ad.3.1789063156725; Thu, 10 Sep 2026 10:59:16 -0700 (PDT) Date: Thu, 10 Sep 2026 10:59:16 -0700 In-Reply-To: <20260806233609.212337-1-seanjc@google.com> Mime-Version: 1.0 References: <20260806233609.212337-1-seanjc@google.com> Message-ID: Subject: Re: [PATCH v6 00/51] x86: Try to wrangle PV clocks vs. TSC From: Sean Christopherson To: Kiryl Shutsemau , Rick Edgecombe , Paolo Bonzini , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Ajay Kaher , Alexey Makhalov , Jan Kiszka , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Juergen Gross , Daniel Lezcano , Thomas Gleixner , John Stultz , Vitaly Kuznetsov , Broadcom internal kernel review list , Boris Ostrovsky , Stephen Boyd , Miroslav Lichvar , x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Michael Kelley , Tom Lendacky , Nikunj A Dadhania , David Woodhouse , David Woodhouse , Thomas Gleixner Content-Type: text/plain; charset="us-ascii" X-purgate-ID: tlsNG-ef75cf/1789063159-A44CBAE4-014D8D59/0/0 X-purgate-type: clean X-purgate-size: 1189 On Thu, Aug 06, 2026, Sean Christopherson wrote: > The primary goal of this series to fix flaws with SNP and TDX guests where a > PV clock provided by the untrusted hypervisor is used instead of the secure > TSC that is controlled by trusted firmware. > > The secondary goal is modernize running under KVM. Currently, KVM guests will > use TSC for clocksource, but not sched_clock. And Linux-as-a-KVM-guest doesn't > support paravirt enumeration of the TSC/APIC frequencies, even though QEMU > provides that information by default. > > The tertiary goal is to clean up the PV clock code to deduplicate logic across > hypervisors, and to hopefully make it all easier to maintain going forward. > > The quaternary goal is to clean up the TSC calibration code, which was made > stupidly hard to follow by hypervisor code mixing in with the native > calibration routines, instead of being implemented as a pure alternative. > > Note, the VMware and Xen changes still probably should get acks from those > maintainers, as my understanding of what they're trying to do may be flawed. This (thankfully) still applies cleanly. What can I do to help move this forward? From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:37:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:37:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415131.1644623 (Exim 4.92) (envelope-from ) id 1x4je4-0001EY-67; Thu, 10 Sep 2026 18:37:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415131.1644623; Thu, 10 Sep 2026 18:37:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4je4-0001ER-3V; Thu, 10 Sep 2026 18:37:12 +0000 Received: by outflank-mailman (input) for mailman id 1415131; Thu, 10 Sep 2026 18:37:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4je1-0001At-P4 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:37:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4je0-003VvC-7p for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:37:08 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2f8b9-bab6-0a2a0a5309dd-0a2a4508c346-34 for ; Thu, 10 Sep 2026 20:37:07 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2f8d2-f659-0a2a45080019-5a9b3222c314-3 for ; Thu, 10 Sep 2026 20:37:06 +0200 Received: from [2001:8b0:10b:5:a10:bfc:a858:f6d3] (helo=u09cd745991455d.ant.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1x4jdj-00000002wwG-35Wi; Thu, 10 Sep 2026 18:36:52 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=wOS95Ra8vpgZqPPtuGigA2/jRdxnP7FegxOh9WR7HSk=; b=Na7DaqpOQpVs8/QFZ01yiPibu9 j0jxll2rBp9W+CxW3On84+Gp0ttYkZrEf+41K9VqQmyv2ncgjYUM27ph53mbamt3q1bA0lNqlPsbG KFuCJ/MsLVuLdKH23azJcAR2zaD28qtIEtL4Iz1e9OSwZ07mjITENaTX8yWQ4mAvq6AafmmnRoV66 QCob0faL4ovWeBAvsGTPknmeuOH0yn9s7/dUSlWicfmGvdo2GuPp2FQGBc83+DnDqpv1/pOnhzCR7 /YhMsFdOvisPcRb5GnB5HjXGYdAQ7QnRdmI6kIrxEcYCBPu0d4AskIDTyyDlw1i9uF8JZs9NyiH1o roJ4dWsQ==; Message-ID: Subject: Re: [PATCH v6 00/51] x86: Try to wrangle PV clocks vs. TSC From: David Woodhouse To: Sean Christopherson , Kiryl Shutsemau , Rick Edgecombe , Paolo Bonzini , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Ajay Kaher , Alexey Makhalov , Jan Kiszka , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Juergen Gross , Daniel Lezcano , Thomas Gleixner , John Stultz , Vitaly Kuznetsov , Broadcom internal kernel review list , Boris Ostrovsky , Stephen Boyd , Miroslav Lichvar , x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Michael Kelley , Tom Lendacky , Nikunj A Dadhania , Thomas Gleixner Date: Thu, 10 Sep 2026 19:36:22 +0100 In-Reply-To: References: <20260806233609.212337-1-seanjc@google.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-mC8wbvMi0aPBUSksNuNl" User-Agent: Evolution 3.60.3-0ubuntu1~ppa10~24.04 MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-purgate-ID: tlsNG-c1860d/1789065427-D634587B-57FA7DF9/0/0 X-purgate-type: clean X-purgate-size: 10235 --=-mC8wbvMi0aPBUSksNuNl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2026-09-10 at 10:59 -0700, Sean Christopherson wrote: > On Thu, Aug 06, 2026, Sean Christopherson wrote: > > The primary goal of this series to fix flaws with SNP and TDX guests wh= ere a > > PV clock provided by the untrusted hypervisor is used instead of the se= cure > > TSC that is controlled by trusted firmware. > >=20 > > The secondary goal is modernize running under KVM.=C2=A0 Currently, KVM= guests will > > use TSC for clocksource, but not sched_clock.=C2=A0 And Linux-as-a-KVM-= guest doesn't > > support paravirt enumeration of the TSC/APIC frequencies, even though Q= EMU > > provides that information by default. > >=20 > > The tertiary goal is to clean up the PV clock code to deduplicate logic= across > > hypervisors, and to hopefully make it all easier to maintain going forw= ard. > >=20 > > The quaternary goal is to clean up the TSC calibration code, which was = made > > stupidly hard to follow by hypervisor code mixing in with the native > > calibration routines, instead of being implemented as a pure alternativ= e. > >=20 > > Note, the VMware and Xen changes still probably should get acks from th= ose > > maintainers, as my understanding of what they're trying to do may be fl= awed. >=20 > This (thankfully) still applies cleanly.=C2=A0 What can I do to help move= this forward? Nudge Thomas to spot that this is guest-side and we want him to pick it up,= I guess? --=-mC8wbvMi0aPBUSksNuNl Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK 72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9 0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213 MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm 6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6 bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO 02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91 LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8 +3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs +icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1 LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0 D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3 bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2 JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k 0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6 ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74 vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o 9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0yNjA5MTAxODM2MjJaMC8GCSqGSIb3DQEJBDEiBCCeuuPd2MNyU7+4SwcmO/lkRJz6uyg7 xapH31EQDbGOCDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw DQYJKoZIhvcNAQEBBQAEggIAJDGFW1ng+0HFNUOD7IeIsMulIMhpFTLP/lVM5hcxCW9lzh+cMrUA VMY7RePSNSm+DzqjUfljtYqvvzhQSsdUsYQWdHfvT7EDdLebdf3cW0yeT1lr/tJdzWaeEFGD59UV 31ToKmoclv/ZpaP6ZqrWE+17ZbaowSnypCOw5ZKnBBKxlazorQsOacGpRuWTABtQUYEabLo1I8KY HPBV+rBbN8poEzIFtcnwx1RGyk74HQEcwI3Vyz2zz8Q/0mKQxYQG9ACgOgbMoiiJSPlk0snxJHgj PQIRpmBqN81CtCIAX5XaYf/MZdzZGmXq/w6WlgHFF91/3nAxqGtC0ctCHs7Z4JY6RMRVMiIKFOYJ 1adCKvZO35Xgdj1UTUkMyjICrkQJ3r+ZoG083MfGt3gTYQVAPBe8/yj4KQ8nMjdwd7Eceos/NesN e2lKkAJCPKQl66NV2nNT1cPFkxWAvat2cAsMwNSgmpXg+FzRE6n374cPSEIOren3U8ki1yXWLX0x x77ko2I4mFxOhR4XZhN76rqvKenu30FwjHaTLcXQTvH74QePUv/s9YjR1u0oBjERFPE66kOOwsIC x8v70/Hx99qi9Im/G4eyMQ63Lgt9sMYRqFaAj1knUfDo8pCbyiNln17VVcLxzn8YGtDuNYNyWZre vqwhYUQUCosmYZzhbUT9y9AAAAAAAAA= --=-mC8wbvMi0aPBUSksNuNl-- From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:50:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:50:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415148.1644634 (Exim 4.92) (envelope-from ) id 1x4jrJ-0004K8-A3; Thu, 10 Sep 2026 18:50:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415148.1644634; Thu, 10 Sep 2026 18:50:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrJ-0004K1-69; Thu, 10 Sep 2026 18:50:53 +0000 Received: by outflank-mailman (input) for mailman id 1415148; Thu, 10 Sep 2026 18:50:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrI-0004Jv-3v for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:50:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrH-001Y5I-A4 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:50:51 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fbe6-2eae-0a2a0a5409dd-0a2a450b9c5c-26 for ; Thu, 10 Sep 2026 20:50:51 +0200 Received: from [209.85.222.178] (helo=mail-qk1-f178.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc09-b7e8-0a2a450b0019-d155deb2d178-3 for ; Thu, 10 Sep 2026 20:50:50 +0200 Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-939d917fee3so120930485a.3 for ; Thu, 10 Sep 2026 11:50:50 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e86b7424sm40754785a.32.2026.09.10.11.50.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:50:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066249; x=1789671049; darn=lists.xenproject.org; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=04sGP5fC6+EWQ5zQqoL4aDa3rNDPdOaXISOWt+zm6Kw=; b=sHi5l6vW/ws9gKot/0r+h96HKEKRNnJ70w/dCoaMPNqnNokjueYWVEo3tE4DvNT16r NDWRp8l22MRiFCJZKzH+y2mGYcRWCl39J37cGRtLcVWB/Sow7CTy49DGyPL0nR6o+BV1 dtw9QzqocVCg49KwwNcXPNn6jQEW3cwLq/jlwuPOwvPMcxPgL5PEr8/EgvGGqcRlvNFw buld7yyUP33wMtJoVIuT3rH7HMV3OGKETz186Rw4yu4wr80ZxR6LJVnG+4lwF8Ws1jQs jB9tGk7ZB7j96myrxTI4d4X3jgR7apKtfUYvTnrTEmy3JyyVlrA6s9tW8QuoxNzerJva l0Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066249; x=1789671049; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=04sGP5fC6+EWQ5zQqoL4aDa3rNDPdOaXISOWt+zm6Kw=; b=ZYb6oEsaIY/QVOcxQHwXJAtzZic7scY5JtV+rUhknkptiAM7j7Oiuq5QcGEtw6bqFu C+RA4bysdcYo8/oKsPU+88FkYX0JN741pzSp7Y0aPDMTqjfbg4FteYy0Hr4rUy2VcONi f7ZyvDu8w9FQedhJ54M8xVeNukraP1ITHPhq3gA2HyZ8qeYqLJ+r2t4WY0owKrAi7vV+ Mh8bs46ELl7Zy5ld9fvow23Ic9HQJjbuMkt4J62lZFMWZgqChO3QsFWNpQDzWUSjGlKj wlVTVgPfd163FweUxtQukzb2C9pw6VgpQ0YFFdSE13CSXdWG0LYS6h0oKWD9Xtmz1ZtH ubog== X-Forwarded-Encrypted: i=1; AKwUvBwcoDaffj2RfTNUgLIlF7OJQbt21eqz12+6oNDt7kgvj156km5hVMn3TdV+lEuSptd3uwyrav/wOaQ=@lists.xenproject.org X-Gm-Message-State: AFuF++muWBoGxeXveqXV9JaD76PXkkA0sDhav8HKp2ZymyB2cp/n6djX Q1T8vXEWQrKVHWFNqSYSTzmF0rV0q8ZWUCx1xTh1Y3LJcsyXNcz5dXKkibfS2JgRod0= X-Gm-Gg: AYBFou2JhdCJlD71BGJZULpwG394iXY7VAPw0LNlMwIs/vEXufOLvCC1cWoZx1buqF7 7BSOzvKAJaOWr6JiIfUS+E0drLVz4kaO4Iykuf+aOJcTwj/iyKRHoBzsLK7KjT7FEdFOXXJ1B7d oZHHX7A4HeuZhAprpO+nGXw6yMf2peCmCb1b726qHxCBjtbCkZDV7KDTvEJ2OJbhdJLEy3Fobqs grrDfTSs/mjLhNfDwTK2zY7sSWSp+TWrdJS2GiVlKU785IaZRbXNDYuno2dRDUbaNIFgGxcQYd+ 6yu9TxoDO5ctxeyxAoOytWDfIy1C7FC49b1QiIBxS7Hr8njIlVu1usssBQrgL/bOzBmVBfodHpS QuOiB5RDvO6VMBnpT+6sw9alzkqkOOl1VuatPm7OdLOVgZqtoBGchXt0IqEDgwf7LGOT9fpLwuP sRx5CsolOhayqPPFTUIp4f5ZD6vcGSBAjvUg4mdPashZF00RZBpquvl4R+qsmGgMSR8LLelswNj K8oo8ZQk3VwFOXhdMCa629cZOA50d9t8HgAjsd8bDsmceBiCP2KEfGj X-Received: by 2002:a05:620a:454a:b0:939:8e05:27e0 with SMTP id af79cd13be357-939ea013111mr26869085a.1.1789066249021; Thu, 10 Sep 2026 11:50:49 -0700 (PDT) From: Josef Bacik Subject: [PATCH RFC 00/13] rcu-tasks: let preemption outside trampolines be a quiescent state Date: Thu, 10 Sep 2026 18:50:23 +0000 Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAPH7omoC/22Nyw7CIBBFf6WZtZPShtbo1sQPcGtcAA4WH4gMN SZN/12oW5f33NcETNERw7aaINLbsXv6LJpVBWZQ/kLozllDK9pebBqBWmI0IybFN8YQiR4h4Yt RisZa2cm+M2vI7WxZ91mWj3DY7+D0gzzqK5lUNktMKybUUXkzFHQPtZb1Av+9wDx/AYKBPpKyA AAA X-Change-ID: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-42698a/1789066251-A9AC09EA-7AC9F295/0/0 X-purgate-type: clean X-purgate-size: 8754 Tasks RCU only treats a voluntary context switch, usermode or idle as a quiescent state, because a preempted task may be sitting in a trampoline that is about to be freed. That was a fine trade when PREEMPT_NONE servers compiled Tasks RCU away and PREEMPT desktops rarely ran long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: Tasks RCU is now real on server configs, and cond_resched() is a no-op, so a CPU-bound kthread or kworker only ever loses the CPU by being preempted, which is exactly the event Tasks RCU refuses to count. The way this showed up for us was a cgroup writeback worker draining a very large cgwb for around eleven minutes on an arm64 box. Nothing wrong with that on its own, but a BPF program detach on another CPU went bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() while holding trampoline_mutex, forty-odd tasks piled up behind the mutex, and the hung task detector panicked the machine. The kprobe jump optimizer is worse in principle: it does synchronize_rcu_tasks() under kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running kthread can stall static key updates and CPU hotplug for its whole run. The current answer is to find each such loop and add cond_resched_tasks_rcu_qs() to it, which is the kind of annotation PREEMPT_LAZY was supposed to let us stop writing. This series tries the other direction: have the trampolines say when a task is inside them, so that a preemption anywhere else can be a quiescent state. - task_struct grows an int, rcu_tramp_nesting. Every trampoline whose lifetime Tasks RCU guards increments it before calling out and decrements it before returning: ftrace_caller and its dynamic copies, the BPF trampoline (which drops it again around the call to the original function, since im->pcref covers that), the x86 optprobe template, and out-of-line register_ftrace_direct() trampolines. Only current writes it and nested users are balanced, so it is a plain non-atomic inc/dec, one load of current plus one RMW per entry/exit. - The inc/dec are inside the trampoline, so there is a window of a few instructions on each side where the count is zero but the task is in (or on its way into) trampoline text. Nothing there can be preempted synchronously, only from an interrupt, so the irq-exit preemption path looks at regs->ip and holds the count across preempt_schedule_irq() when the IP is somewhere the counter cannot cover: outside core and module text (all the dynamically allocated trampolines and slots), in the static ftrace stubs or the x86 return thunks that still hold a direct-call target, in a module that hosts its own direct trampoline, or inside the bytes after a kprobe that the jump optimizer may be about to rewrite (the one synchronize_rcu_tasks() user that is not about trampolines at all). - With those in place, rcu_tasks_classic_qs() also clears the holdout flag on a preemption when the count is zero, on architectures that opt in. x86-64 and arm64 do so here. Everyone else keeps the voluntary-only rule and is untouched apart from the (unused) field. A running holdout already gets poked via rcu_request_urgent_qs_task(), which makes the next tick set NEED_RESCHED, so with this the resulting preemption retires it and a Tasks RCU grace period is bounded by roughly a tick plus the longest preempt-off section rather than by the longest stretch without a voluntary schedule(). Patches 1-12 are scaffolding and change no behaviour on their own; patch 13 flips the rule and selects the option for the two architectures. Testing so far is QEMU only: x86-64, PREEMPT_LAZY with PREEMPT_RCU=n, PROVE_RCU and lockdep, with and without PREEMPT_DYNAMIC. A kthread spinning in-kernel for 30s with the function tracer, an ftrace kprobe, an optimized kprobe and fentry/fexit programs attached: synchronize_rcu_tasks() goes from 29.7s to 0.1-0.3s, tearing down a DYNAMIC ftrace_ops (tracefs instance function -> nop) from 27s to 0.2-0.8s, and the ftrace-direct sample modules load, fire and unload in about 2.5s each while the spinner runs, with no warnings and the new return-to-user assertion quiet. arm64 is build-tested only at this point; real hardware numbers for both are the obvious next step and I did not want to sit on the idea waiting for them. Things I would particularly like opinions on: - Whether hooking rcu_tasks_classic_qs() is the right place, or whether Paul would rather see this expressed differently inside Tasks RCU. - return_to_handler and the rethook/kretprobe trampolines are not instrumented. Their C callees take the ftrace recursion lock before touching any ops and the trampolines themselves are static text, so I believe they do not need it, but I would like Steven and Masami to confirm. - The register_ftrace_direct() contract change: out-of-line direct trampolines now have to maintain the count themselves (the samples are converted). I do not know of out-of-tree users beyond BPF, but this is the one place an existing user could be silently weakened. - Whether arm64 folks are comfortable with the ldr/add/str in ftrace_caller and the BPF trampoline, and with treating all of ftrace_caller as trampoline text for the IP check. - If this holds up, cond_resched_tasks_rcu_qs() and rcu_softirq_qs_periodic() become unnecessary on the opted-in architectures; I have not touched them here. Based on v7.3-rc2+ (893e11787f78). --- Josef Bacik (13): rcu-tasks: Add per-task trampoline nesting count entry: Pass pt_regs to irqentry_exit_cond_resched() rcu-tasks: Hold trampoline nesting across irq-exit preemption in trampoline text kprobes: Let Tasks RCU recognise tasks preempted in an optprobe jump window ftrace: Mark modules hosting direct-call trampolines for Tasks RCU x86/ftrace: Maintain Tasks RCU trampoline nesting in ftrace_caller x86/kprobes: Maintain Tasks RCU trampoline nesting in the optprobe template bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline arm64: ftrace: Maintain Tasks RCU trampoline nesting in ftrace_caller bpf, arm64: Maintain Tasks RCU trampoline nesting in the BPF trampoline samples: ftrace: Maintain Tasks RCU trampoline nesting in direct-call trampolines rcutorture: Bracket Tasks RCU readers with trampoline nesting rcu-tasks: Treat preemption outside trampolines as a quiescent state arch/arm64/Kconfig | 1 + arch/arm64/kernel/asm-offsets.c | 3 ++ arch/arm64/kernel/entry-ftrace.S | 35 +++++++++++++ arch/arm64/kernel/ftrace.c | 16 ++++++ arch/arm64/net/bpf_jit_comp.c | 46 ++++++++++++++++ arch/x86/Kconfig | 1 + arch/x86/kernel/asm-offsets.c | 3 ++ arch/x86/kernel/ftrace.c | 37 +++++++++++++ arch/x86/kernel/ftrace_64.S | 43 +++++++++++++++ arch/x86/kernel/kprobes/opt.c | 20 +++++++ arch/x86/kernel/vmlinux.lds.S | 4 ++ arch/x86/net/bpf_jit_comp.c | 43 +++++++++++++++ arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 14 ++--- include/linux/kprobes.h | 8 ++- include/linux/module.h | 7 +++ include/linux/rcupdate.h | 70 ++++++++++++++++++++++++- include/linux/sched.h | 1 + kernel/entry/common.c | 29 +++++++++-- kernel/fork.c | 1 + kernel/kprobes.c | 24 +++++++++ kernel/rcu/Kconfig | 17 ++++-- kernel/rcu/rcutorture.c | 6 +++ kernel/rcu/tasks.h | 81 +++++++++++++++++++++++++++-- kernel/rcu/update.c | 2 + kernel/trace/ftrace.c | 39 ++++++++++++++ samples/ftrace/ftrace-direct-modify.c | 9 ++++ samples/ftrace/ftrace-direct-multi-modify.c | 9 ++++ samples/ftrace/ftrace-direct-multi.c | 5 ++ samples/ftrace/ftrace-direct-too.c | 5 ++ samples/ftrace/ftrace-direct.c | 5 ++ samples/ftrace/ftrace-direct.h | 64 +++++++++++++++++++++++ 32 files changed, 629 insertions(+), 21 deletions(-) --- base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8 change-id: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 Best regards, -- Josef Bacik From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:50:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:50:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415149.1644642 (Exim 4.92) (envelope-from ) id 1x4jrM-0004Wm-Fn; Thu, 10 Sep 2026 18:50:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415149.1644642; Thu, 10 Sep 2026 18:50:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrM-0004Wf-CZ; Thu, 10 Sep 2026 18:50:56 +0000 Received: by outflank-mailman (input) for mailman id 1415149; Thu, 10 Sep 2026 18:50:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrK-0004WP-PT for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:50:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrK-00GcVR-6S for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:50:54 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fbec-bab6-0a2a0a5309dd-0a2a4506e7e0-40 for ; Thu, 10 Sep 2026 20:50:54 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc0d-195a-0a2a45060019-4a7de68ca226-3 for ; Thu, 10 Sep 2026 20:50:54 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-90cdfc9b6ebso282126d6.2 for ; Thu, 10 Sep 2026 11:50:53 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530ca45b61dsm239421cf.6.2026.09.10.11.50.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:50:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066252; x=1789671052; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=AwJvzjOst2er6K+UDT8eDw5lj3PdpLVthroXGjj7dNM=; b=PBu+rAgA+SRJuxl4EK9t6NvRu4M4sZV5P5sauLJDEzhZKuXE5i1/xq+yC4LiZhkK2N U1sx8IkgrfsGMrCxYlhRxIIjCoUctbOtcxkLY+Hthys74dYcel0SUWGqFWjyReiyXfeE K7BLpafsbM9RDlpBTeixuMveUj0PLES6OtVTunqqyG7gBup66j2GfBsh/ao46DjT728w jwWI0BnL0ysw4ct6Ih7iybU+5u0/GM/ZZdhCy5wKNc9v2Pj+pw4/fZHp5KxZlfB7yLjQ KAqvxNXb9gKu271LM0GzKPjcN+/0YPGujrnB5OLrYU1PPx7Z0y0P3yFHtQnB0QapEjRk NgDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066252; x=1789671052; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=AwJvzjOst2er6K+UDT8eDw5lj3PdpLVthroXGjj7dNM=; b=jo3YMgzuzYyFlfLJmDMtlDyHofTfJbdQXMH8DGq83Wo6H5lsnGSYfWdEZtfUg3zARD pH6mTRM0QVMNIo6UHJbk1mr1kZ8cEMVsa3OGHTrlGnlwdfBaDYVyVbzXWNdm6Hcyi7UU /2lPTFJtOwLw91PE0R+NJuPObNiITDTE4rVXIecbNpgz0Xu+sDoQJ/l4KgTYaZmoNDBg 6MR+ESqbPZDKSExOxfgLOSlZATnY9z+X/hejqWm4xqosG3eUyEY0ZW7Qq8I8Yrc2Lnmz UbJJSSrAdrH4L+cJq+be1SA1omGt5MR7MEJBLk3bCV8HIHaeRkOAERLRKVqcWry7iZA/ ou9A== X-Forwarded-Encrypted: i=1; AKwUvBx517ID/pJYa1ijc55h2DD0d/bLX3yC/ZHYhrSzzXHYWsOotL7P/mW0F/ZxrHxv5HLEszg4fS0vAok=@lists.xenproject.org X-Gm-Message-State: AFuF++mPXVlD8l6amng25G9F1X0yVmlW+oUzDxsMcV2tPZOn4LU+ag5Z aSPhMhqJLT+gIGIPUvwhMhpGGeEBZ1Mb6FNHqS7As1lBO20w+LygQWMpFFPIXLXY/TE= X-Gm-Gg: AYBFou2nZe8U5RL3j+p9D2BFEsHjppdHu9AMRNm3r62VnqSmKUOGn1OrqsrW5MZJlK8 QcAtvP/gC2xERLBsPwQC1XGaxV2B3LORrRnMywCCsviXNp3+30bMd9M2xdfO6iRa09rWwebdRZ5 qihfYtJPgAiMyFlDpQE25DCiYGYVi0QYcRiXlbkCKK3gMEamNwSuangtnNJpAa+5nH37o0Ufb2Z vmIfam/+2qFxdY3g8WseOFRY7bmAY6XDCVaSIIggnd7kEn82emE3s5LQHGzBXRtl1JqlYQWz1il FNjO/PXZ4pNQHd/tjKaqgG3H3CsKOCleNSCRYAjnV0VHh5AKRDPp1p92mNBhps6xG3EojST7B6C qETLBFPyrjQkHuF1Y2JBFHtQqQ79WF5wUOoxW5HI4Q89iVcrzbRTNOtQpezqSXPdLSh8ifFh0Bp DWCgctRzRZ621Y0bhOHvaepuarbMtn/ScsZyT5gHM+v5q8JiGH2WeJlVo1pTfuQLops0Rgry0dj GIUoeRgIaldknH1+FWRBsYOWMTh+MdRxUOqmUKKqULux8CaOqOrKgYCSg== X-Received: by 2002:a05:622a:1b8b:b0:530:5ed1:561a with SMTP id d75a77b69052e-530c876e50amr12423551cf.43.1789066252311; Thu, 10 Sep 2026 11:50:52 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:24 +0000 Subject: [PATCH RFC 01/13] rcu-tasks: Add per-task trampoline nesting count MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-1-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-16d1c6/1789066254-F580D77B-06DA44E2/0/0 X-purgate-type: clean X-purgate-size: 6292 Tasks RCU exists so that ftrace, BPF and kprobes can free trampoline text once no task can still be executing in it. Today the only way a task tells Tasks RCU "I am not in a trampoline" is a voluntary context switch, so a preempted task is always assumed to be inside one. Add task_struct::rcu_tramp_nesting so that trampolines can say so directly: a trampoline increments it before calling out and decrements it before returning, and while it is non-zero the task must not be treated as Tasks-RCU quiescent. Provide rcu_tasks_trampoline_enter() and rcu_tasks_trampoline_exit() for C users, report the count in the Tasks RCU stall output, and, under CONFIG_PROVE_RCU, assert that it is zero on every return to userspace since no task can legitimately reach userspace with a trampoline on its stack. Only current ever writes the count and every nested user (interrupts running their own trampolines) is balanced, so plain accesses suffice. Nothing increments the count and nothing consults it for quiescent-state decisions yet; both come in later patches. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/irq-entry-common.h | 2 ++ include/linux/rcupdate.h | 37 +++++++++++++++++++++++++++++++++++++ include/linux/sched.h | 1 + kernel/fork.c | 1 + kernel/rcu/tasks.h | 3 ++- 5 files changed, 43 insertions(+), 1 deletion(-) diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index 0bb6c03481fa..8da571622000 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -214,6 +215,7 @@ static __always_inline void __exit_to_user_mode_validate(void) { /* Ensure that kernel state is sane for a return to userspace */ kmap_assert_nomap(); + rcu_tasks_trampoline_assert_none(); lockdep_assert_irqs_disabled(); lockdep_sys_exit(); } diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 44c07a66edff..b5c666c82479 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -180,6 +180,37 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } #ifdef CONFIG_TASKS_RCU_GENERIC # ifdef CONFIG_TASKS_RCU + +/* + * Trampoline nesting: dynamically allocated text (ftrace trampolines, BPF + * trampoline images, kprobe optinsn slots) that relies on Tasks RCU for its + * lifetime brackets itself with an increment/decrement of + * current->rcu_tramp_nesting. While the count is non-zero the task is inside, + * or was called from, such text and an involuntary context switch must not be + * treated as a Tasks RCU quiescent state. + * + * Only current writes the count and only current (or an interrupt on the same + * CPU) reads it, so plain accesses suffice. + */ +static __always_inline void rcu_tasks_trampoline_enter(void) +{ + current->rcu_tramp_nesting++; + barrier(); +} + +static __always_inline void rcu_tasks_trampoline_exit(void) +{ + barrier(); + current->rcu_tramp_nesting--; +} + +/* A task must never reach userspace with a trampoline on its stack. */ +static __always_inline void rcu_tasks_trampoline_assert_none(void) +{ + if (IS_ENABLED(CONFIG_PROVE_RCU)) + WARN_ON_ONCE(current->rcu_tramp_nesting); +} + # define rcu_tasks_classic_qs(t, preempt) \ do { \ if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ @@ -192,6 +223,9 @@ void rcu_tasks_torture_stats_print(char *tt, char *tf); # define rcu_tasks_classic_qs(t, preempt) do { } while (0) # define call_rcu_tasks call_rcu # define synchronize_rcu_tasks synchronize_rcu +static inline void rcu_tasks_trampoline_enter(void) { } +static inline void rcu_tasks_trampoline_exit(void) { } +static inline void rcu_tasks_trampoline_assert_none(void) { } # endif #define rcu_tasks_qs(t, preempt) rcu_tasks_classic_qs((t), (preempt)) @@ -208,6 +242,9 @@ void exit_tasks_rcu_finish(void); #define rcu_tasks_classic_qs(t, preempt) do { } while (0) #define rcu_tasks_qs(t, preempt) do { } while (0) #define rcu_note_voluntary_context_switch(t) do { } while (0) +static inline void rcu_tasks_trampoline_enter(void) { } +static inline void rcu_tasks_trampoline_exit(void) { } +static inline void rcu_tasks_trampoline_assert_none(void) { } #define call_rcu_tasks call_rcu #define synchronize_rcu_tasks synchronize_rcu static inline void exit_tasks_rcu_start(void) { } diff --git a/include/linux/sched.h b/include/linux/sched.h index 8b3d47a325cc..d2e7b1b3c9d2 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -956,6 +956,7 @@ struct task_struct { unsigned long rcu_tasks_nvcsw; u8 rcu_tasks_holdout; u8 rcu_tasks_idx; + int rcu_tramp_nesting; int rcu_tasks_idle_cpu; struct list_head rcu_tasks_holdout_list; int rcu_tasks_exit_cpu; diff --git a/kernel/fork.c b/kernel/fork.c index 416758c8a3d4..cfe3a8e53fbd 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1869,6 +1869,7 @@ static inline void rcu_copy_process(struct task_struct *p) #endif /* #ifdef CONFIG_PREEMPT_RCU */ #ifdef CONFIG_TASKS_RCU p->rcu_tasks_holdout = false; + p->rcu_tramp_nesting = 0; INIT_LIST_HEAD(&p->rcu_tasks_holdout_list); p->rcu_tasks_idle_cpu = -1; INIT_LIST_HEAD(&p->rcu_tasks_exit_list); diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 627295396cd9..1662ba18bf34 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1113,10 +1113,11 @@ static void check_holdout_task(struct task_struct *t, *firstreport = false; } cpu = task_cpu(t); - pr_alert("%p: %c%c nvcsw: %lu/%lu holdout: %d idle_cpu: %d/%d\n", + pr_alert("%p: %c%c nvcsw: %lu/%lu holdout: %d tramp_nesting: %d idle_cpu: %d/%d\n", t, ".I"[is_idle_task(t)], "N."[cpu < 0 || !tick_nohz_full_cpu(cpu)], t->rcu_tasks_nvcsw, t->nvcsw, t->rcu_tasks_holdout, + data_race(t->rcu_tramp_nesting), data_race(t->rcu_tasks_idle_cpu), cpu); sched_show_task(t); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:50:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:50:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415150.1644650 (Exim 4.92) (envelope-from ) id 1x4jrO-0004kf-PT; Thu, 10 Sep 2026 18:50:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415150.1644650; Thu, 10 Sep 2026 18:50:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrO-0004kY-Mp; Thu, 10 Sep 2026 18:50:58 +0000 Received: by outflank-mailman (input) for mailman id 1415150; Thu, 10 Sep 2026 18:50:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrN-0004eI-2o for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:50:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrM-00GcVR-Fk for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:50:56 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fbc3-bab6-0a2a0a5309dd-0a2a4501c7de-46 for ; Thu, 10 Sep 2026 20:50:56 +0200 Received: from [209.85.219.52] (helo=mail-qv1-f52.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc0f-5984-0a2a45010019-d155db34cc92-3 for ; Thu, 10 Sep 2026 20:50:56 +0200 Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-90cc39e06bdso569076d6.0 for ; Thu, 10 Sep 2026 11:50:55 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e8bf9d51sm34965885a.14.2026.09.10.11.50.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:50:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066255; x=1789671055; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dxBJRgyuHY3W/iJApny4mLX1c4wnn/TYh39J8mu564M=; b=qZ4kkEzaVD5EgqYkuvzJR0rh3kr43L38Y9KsooAwlzNbXwSgGYpoVimRX4tD3AHCR3 r7DOLAIbdTC22OQi9+UBQnDMkp9upzu82IMCvOA4eZH2YtP7okowTR5d7Qvv8bBYCOhR iQzoe4cPytufFkpkvBxaaD8cA36sVB0JkiBS0oZdNLK9oTLK0VRCJuj7pwgr8XcwHXFg n5wMgJkZ777AOLa3LNlLBUK33hDSVVE8n6KyH/HSi1IRNgtHlBP93zKGTuqcp6dCqM3E l4tHJXuMzTPhKcF+DaqlzupEnwVNndvNjpRu1o8gN4tMrtMkqb/oP8YZXdnuctFN9/5m +ILQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066255; x=1789671055; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=dxBJRgyuHY3W/iJApny4mLX1c4wnn/TYh39J8mu564M=; b=sTNbfU93Mxp54VoEGtB/BKrsUkSoaNMEFMQMmOOV1gtPZb1dJoK12XCK4vKZpWY/Xe Hb9SZKMuJC9PgkOo3M1gOhCkoq6LF+J2/K1LsaTot3/H5FJosBa4WIHAkMzcNTkIRHXY TBudaRcPY2f7O7OwAnSMV7HZYiYAxsPkecL22iqZZfR90AaUL0jWL36juO0PFG+MLCVM zfi9faO+zNJs16aA+AcpNjYRGOKPb7exy3P8ukorQm4Zp7TZHRMcVWRc1OsKTG5/rU7M So8ynfWzy8AXv3iHC0/UZyux4XGubATnlTP8Dcb4yamaHEw0kUUeowuiQC1rLBTSKJy5 ZUrw== X-Forwarded-Encrypted: i=1; AKwUvBzxbHUAJsmEHZfjZTyekggmfIaAuGxwBGdjiZJkoFLZ+Z8zVFnjGpsZ1930pha/2o4FseIAprQ7Tf8=@lists.xenproject.org X-Gm-Message-State: AFuF++l9hA2tKsgG/bIv7x2xiemmRZJ/ZMpm9Reg5ZWg102sTYBWQgqK iZBvqERejyzoU+sxZYXeJp1W1nwiCVNjzbH4cpfJKRH4b+Bwy35s1Px9AreUkWViVVE= X-Gm-Gg: AYBFou1B8ABJWvYDLakBiwvvATzGxYlInAvOxnL41zTb03hGMx4bm/RR+XMJDJ5TxCV 8A/aET1HGsnjp8B/wDQ6M7//cIIfXwwmIrD+4XEBL2qa3wJSbXR4lH2F0+cq8HymALgTDMS1DJw yH9xbnp5LB3gJ1C3IlyI13t7OpFipmiaaeJsozLf0hALeo8cqGfF6F04Zk7CCm+2/G+XDw93xUU w/2QVu0f5wZ+K9kevSHxKaUGTFtvlEnHNGp6CMo/gLvBQkNEwWeF8zK+GUgM7yY/JZ8SuEP2GkI KhXO0twbeoAsx88nklqPqEhS9vwI4fU3emtHPcQhNKkyokZe72sk4IFvciY3cVFQzhMHLsihJUS g7HzfdKA2hbgcNrpMLiWEzoTOHrUe2z4j8k01gPa/qkQgr6UOQOEIdz3oUW6+lknPXcBb1jfj4S 7G8vjj4qzENDycQJBmDfW96mHlqLQlB6AdKOMekt8SHVqexwLuE1afeoS3zoCL5512xLe1Hb0ed ad5bF+SWTojZFy4jQqLKL/LUDeluyWn2GZlDciJMR7gdL45AXdEA5C6 X-Received: by 2002:a05:620a:280d:b0:939:78ab:3c5f with SMTP id af79cd13be357-939ea0137a8mr26249085a.9.1789066254480; Thu, 10 Sep 2026 11:50:54 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:25 +0000 Subject: [PATCH RFC 02/13] entry: Pass pt_regs to irqentry_exit_cond_resched() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-2-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-d62444/1789066256-C5146757-93FF6A3D/0/0 X-purgate-type: clean X-purgate-size: 4151 The irq-exit preemption path is about to need the interrupted context's registers to decide whether the preemption may be reported to Tasks RCU as a quiescent state. irqentry_exit_to_kernel_mode_preempt() already has them; hand them down through irqentry_exit_cond_resched(), its PREEMPT_DYNAMIC static-call and static-key variants, and raw_irqentry_exit_cond_resched(). The only caller outside the generic entry code is Xen PV's upcall handler, which has regs as well. No functional change. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 12 ++++++------ kernel/entry/common.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 2c64b388f616..3d85035f5624 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -739,7 +739,7 @@ __visible noinstr void xen_pv_evtchn_do_upcall(struct pt_regs *regs) inhcall = get_and_clear_inhcall(); if (inhcall && !WARN_ON_ONCE(state.exit_rcu)) { - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); instrumentation_end(); restore_inhcall(inhcall); } else { diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index 8da571622000..fc04725ae46b 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -348,21 +348,21 @@ typedef struct irqentry_state { * * Conditional reschedule with additional sanity checks. */ -void raw_irqentry_exit_cond_resched(void); +void raw_irqentry_exit_cond_resched(struct pt_regs *regs); #ifdef CONFIG_PREEMPT_DYNAMIC #if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL) #define irqentry_exit_cond_resched_dynamic_enabled raw_irqentry_exit_cond_resched #define irqentry_exit_cond_resched_dynamic_disabled NULL DECLARE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); -#define irqentry_exit_cond_resched() static_call(irqentry_exit_cond_resched)() +#define irqentry_exit_cond_resched(regs) static_call(irqentry_exit_cond_resched)(regs) #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void); -#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs); +#define irqentry_exit_cond_resched(regs) dynamic_irqentry_exit_cond_resched(regs) #endif #else /* CONFIG_PREEMPT_DYNAMIC */ -#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() +#define irqentry_exit_cond_resched(regs) raw_irqentry_exit_cond_resched(regs) #endif /* CONFIG_PREEMPT_DYNAMIC */ /** @@ -467,7 +467,7 @@ static inline void irqentry_exit_to_kernel_mode_preempt(struct pt_regs *regs, return; if (IS_ENABLED(CONFIG_PREEMPTION)) - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); } /** diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e3d381fd3d25..e4acd50bd81a 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -134,7 +134,7 @@ static inline bool arch_irqentry_exit_need_resched(void); static inline bool arch_irqentry_exit_need_resched(void) { return true; } #endif -void raw_irqentry_exit_cond_resched(void) +void raw_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!preempt_count()) { /* Sanity check RCU and thread stack */ @@ -150,11 +150,11 @@ void raw_irqentry_exit_cond_resched(void) DEFINE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void) +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) return; - raw_irqentry_exit_cond_resched(); + raw_irqentry_exit_cond_resched(regs); } #endif #endif -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415151.1644660 (Exim 4.92) (envelope-from ) id 1x4jrR-0004zP-0N; Thu, 10 Sep 2026 18:51:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415151.1644660; Thu, 10 Sep 2026 18:51:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrQ-0004zF-Tu; Thu, 10 Sep 2026 18:51:00 +0000 Received: by outflank-mailman (input) for mailman id 1415151; Thu, 10 Sep 2026 18:50:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrP-0004kl-FF for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:50:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrO-00BoS1-Cm for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:50:58 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fbf1-e002-0a2a0a5209dd-0a2a450a87e0-40 for ; Thu, 10 Sep 2026 20:50:58 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc11-f2d2-0a2a450a0019-4a7de6ccccad-3 for ; Thu, 10 Sep 2026 20:50:58 +0200 Received: by mail-qk2-f12.google.com with SMTP id d75a77b69052e-52fb769ca02so2300301cf.0 for ; Thu, 10 Sep 2026 11:50:57 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f5e880csm2372196d6.49.2026.09.10.11.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:50:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066257; x=1789671057; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Vr/1/6kD89CuecwWXrcFDfjNkcZoJvv75czWOOFkQAs=; b=NxGCuF9TxJR+E2COmaVZM7zVngkAJEnkCFSxGZZnEPX9z3qcj4pYNuE5no3CkArp63 o3DeEcYrarqrAo8TyOuxll4Qf0ENKCY+A7GkEIpB5zBL90C5644Zgg39jpcu8or2mWod stMWWdenxCdBW2D+bfikZ4nmpEct97GiKH8LCaLDQhxCutnl4SN4rIabhFJpB/wI5jyB bjX2Ua4acmVf5+pW1qV5MeOPYKUr4F5wR/i2W3c52SWC/JjVih4xA187u1GrOpmp/6jc 7GzLXF5OmdoFwTSL0dzbZnEKQt5t897h2f9iTH4sFr4BDCiTccKWf6Yzp2/qq8KGvxXC UVng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066257; x=1789671057; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Vr/1/6kD89CuecwWXrcFDfjNkcZoJvv75czWOOFkQAs=; b=Xy0MMEn5blLMOj6McyQPDnCMQsNjjcX3LyjEoyqoXbS4V9JuvW3JT5MlayHVYAGbKt XplM95r9AfiCg705NPxIvNXr9fupbo98lX/GpRMnMgeNjs92iNdurVn9HQ84IOEbkIsI fXIRlp37ADK+KQeIqk4C42A4kHKViJHAj16AmJa/9If+1/4HVtjgWddxDE+tfFCgPrUG cW9VuO8kVlkUE87oAPVACobVHXkqrXllEjxISdkqiGgYzvxJ+TYnZA55p4HbQY3ANnKg H73DeqmNh00WC4PkGDVoDkhFV4t2WgLtHaSOUBrvZTolBpBe3HUJn11obNq4AqAJCymh oMSA== X-Forwarded-Encrypted: i=1; AKwUvByH6SJ7xdhRdj/1I2HKpcLJospR28iRKTuzNRXiLeBbqZ55mwG0S7Zzxakp1IFB0C7/h/mNjpQVy6s=@lists.xenproject.org X-Gm-Message-State: AFuF++nqjJJzs6WoJRIYJyRIDkYYl9EHz6N3SnK8gg58p6G2wvDaKOxm avjfnCsXjVbnOM5XMXSh7sat+8Tmy/n34qs5eV7jbMm+10VloK5QTryIbhEUw0Z4lR8= X-Gm-Gg: AYBFou2AeaPNobDsyg6MtAgpej6IcpGnOxtOVVSok2czbQtdrYrIMgti4tXVZNeSt05 104AvSiS7gjhp/c5dJ/w6z5uPObTuhfnXjVbFJry15yeR0tYUEwHMeOC+n4iPRUcvGwQ38p5Xi/ 3Bc0YUCw0EEcaoyIkEmPqLWxTdayHaVhhYNwAYXJcbumOQCP4EEzFqqCMkwfipkbDgl0rL5NzFE D7OeLmpNUyhzQZoZG8tjddNFyTBaU9XX7T1ttZp46kmWs0/pXaqI38jOM66FGS08oRfgQYJyxs5 w1+BBV2TqTjLDR3sArxOZzN+5n482A0c1lQvartHweT0SDdWf4y+NXBSd+x7MJ29eQI8OTu8UjI DIAjNuaRfRAW5CihhuxJdZBJIL9YA84Oh0SJMIVI46cZTYdCSxBPzgfxjkVW/6zuJSCbdk0n20O xOm8FQ3iIlQJhsnmxE2c2LcGYkONg2sxTl4Q2zXtlXEt4FV73n+plJ1osJCBTXMIgiaFSGZq+Ig jYrdL95Hfl2+l5+4f1diKnh3PNYSVn++Jz5ZG11kPkKGK1hmUvdb7g+go+bFQzNALU= X-Received: by 2002:ac8:5a87:0:b0:530:8b38:b9f4 with SMTP id d75a77b69052e-530c86f329fmr16033471cf.37.1789066256481; Thu, 10 Sep 2026 11:50:56 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:26 +0000 Subject: [PATCH RFC 03/13] rcu-tasks: Hold trampoline nesting across irq-exit preemption in trampoline text MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-3-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-4011c0/1789066258-51EC2CFC-E3177B4E/0/0 X-purgate-type: clean X-purgate-size: 9199 A trampoline's own rcu_tramp_nesting increment and decrement live inside the trampoline, so there is a window of a few instructions on entry and exit where the count is zero while the CPU is executing trampoline text (or text on the way into one, such as a static ftrace stub holding a direct-call target). In that window the task has not called out, so it can only be preempted from an interrupt, and the interrupted instruction pointer identifies where it is. Add rcu_tasks_ip_in_trampoline(), which treats any IP outside core kernel and module text as potentially Tasks-RCU-protected (ftrace trampolines, BPF images and programs, kprobe slots are all dynamically allocated text; is_ftrace_trampoline() and friends are deliberately not used because text being torn down may already be unregistered from them while a task still stands on it), plus a __weak arch_rcu_tasks_ip_in_trampoline() for core text an architecture needs to flag. On irq-exit preemption, if the IP matches, hold the count elevated across preempt_schedule_irq(). Introduce ARCH_HAS_RCU_TASKS_PREEMPT_QS / RCU_TASKS_PREEMPT_QS to gate this; no architecture selects it yet, so the check compiles away and there is no functional change. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/rcupdate.h | 17 +++++++++++++++++ kernel/entry/common.c | 23 ++++++++++++++++++++++- kernel/rcu/Kconfig | 10 ++++++++++ kernel/rcu/tasks.h | 38 ++++++++++++++++++++++++++++++++++++++ kernel/rcu/update.c | 2 ++ 5 files changed, 89 insertions(+), 1 deletion(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index b5c666c82479..0a408e36ea15 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -173,6 +173,9 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } #endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */ +/* Arch hook for rcu_tasks_ip_in_trampoline(); see kernel/rcu/tasks.h. */ +bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip); + /* * Note a quasi-voluntary context switch for RCU-tasks's benefit. * This is a macro rather than an inline function to avoid #include hell. @@ -189,6 +192,16 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } * or was called from, such text and an involuntary context switch must not be * treated as a Tasks RCU quiescent state. * + * The increment and decrement themselves live inside the trampoline, so there + * is a window of a few instructions at entry (before the increment) and exit + * (after the decrement) where the count is zero but the CPU is executing + * trampoline text, or text on the way into one (a static ftrace stub or a + * return thunk holding the trampoline's address). In that window the task + * cannot be preempted synchronously, only from an interrupt, so the irq-exit + * preemption path covers it by checking regs->ip with + * rcu_tasks_ip_in_trampoline() and holding the count elevated across + * preempt_schedule_irq() when it matches. + * * Only current writes the count and only current (or an interrupt on the same * CPU) reads it, so plain accesses suffice. */ @@ -211,6 +224,8 @@ static __always_inline void rcu_tasks_trampoline_assert_none(void) WARN_ON_ONCE(current->rcu_tramp_nesting); } +bool rcu_tasks_ip_in_trampoline(unsigned long ip); + # define rcu_tasks_classic_qs(t, preempt) \ do { \ if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ @@ -226,6 +241,7 @@ void rcu_tasks_torture_stats_print(char *tt, char *tf); static inline void rcu_tasks_trampoline_enter(void) { } static inline void rcu_tasks_trampoline_exit(void) { } static inline void rcu_tasks_trampoline_assert_none(void) { } +static inline bool rcu_tasks_ip_in_trampoline(unsigned long ip) { return false; } # endif #define rcu_tasks_qs(t, preempt) rcu_tasks_classic_qs((t), (preempt)) @@ -245,6 +261,7 @@ void exit_tasks_rcu_finish(void); static inline void rcu_tasks_trampoline_enter(void) { } static inline void rcu_tasks_trampoline_exit(void) { } static inline void rcu_tasks_trampoline_assert_none(void) { } +static inline bool rcu_tasks_ip_in_trampoline(unsigned long ip) { return false; } #define call_rcu_tasks call_rcu #define synchronize_rcu_tasks synchronize_rcu static inline void exit_tasks_rcu_start(void) { } diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e4acd50bd81a..cd3feaca6420 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -134,6 +134,27 @@ static inline bool arch_irqentry_exit_need_resched(void); static inline bool arch_irqentry_exit_need_resched(void) { return true; } #endif +/* + * Preempt the interrupted kernel context. If the interrupt landed in text + * that may be a Tasks-RCU-protected trampoline (see + * rcu_tasks_trampoline_enter()), hold current->rcu_tramp_nesting elevated + * across the context switch so that it is not mistaken for a Tasks RCU + * quiescent state. This closes the few-instruction windows at trampoline + * entry/exit where the trampoline's own increment has not yet run or its + * decrement already has. + */ +static void irqentry_preempt(struct pt_regs *regs) +{ + bool in_tramp = IS_ENABLED(CONFIG_RCU_TASKS_PREEMPT_QS) && + rcu_tasks_ip_in_trampoline(instruction_pointer(regs)); + + if (in_tramp) + rcu_tasks_trampoline_enter(); + preempt_schedule_irq(); + if (in_tramp) + rcu_tasks_trampoline_exit(); +} + void raw_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!preempt_count()) { @@ -142,7 +163,7 @@ void raw_irqentry_exit_cond_resched(struct pt_regs *regs) if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) WARN_ON_ONCE(!on_thread_stack()); if (need_resched() && arch_irqentry_exit_need_resched()) - preempt_schedule_irq(); + irqentry_preempt(regs); } } #ifdef CONFIG_PREEMPT_DYNAMIC diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index 332df7a7a634..999f8228a13d 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -107,6 +107,16 @@ config TASKS_RCU default NEED_TASKS_RCU && PREEMPTION select IRQ_WORK +# Selected by architectures whose ftrace, BPF and kprobe trampolines maintain +# current->rcu_tramp_nesting and which use the generic irqentry code, so that +# a preemption outside any trampoline can be treated as a Tasks RCU +# quiescent state. See rcu_tasks_trampoline_enter(). +config ARCH_HAS_RCU_TASKS_PREEMPT_QS + bool + +config RCU_TASKS_PREEMPT_QS + def_bool TASKS_RCU && ARCH_HAS_RCU_TASKS_PREEMPT_QS && GENERIC_IRQ_ENTRY + config FORCE_TASKS_RUDE_RCU bool "Force selection of Tasks Rude RCU" depends on RCU_EXPERT diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 1662ba18bf34..a801ec4a951b 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1089,6 +1089,44 @@ static void rcu_tasks_postscan(struct list_head *hop) timer_delete_sync(&tasks_rcu_exit_stall_timer); } +/* + * Architectures selecting ARCH_HAS_RCU_TASKS_PREEMPT_QS override this to flag + * core kernel text that must be treated like a trampoline, e.g. static ftrace + * entry stubs and return thunks that run with a trampoline address in hand. + */ +bool __weak arch_rcu_tasks_ip_in_trampoline(unsigned long ip) +{ + return false; +} + +/** + * rcu_tasks_ip_in_trampoline - Could a task interrupted at @ip be a Tasks RCU reader? + * @ip: interrupted instruction pointer + * + * Called from the irq-exit preemption path with interrupts disabled, to decide + * whether the imminent preemption may be reported as a Tasks RCU quiescent + * state when current->rcu_tramp_nesting is zero. Returns true, meaning "do + * not report", when @ip is: + * + * - outside static kernel and module text, i.e. possibly in an ftrace + * trampoline, BPF trampoline image or program, kprobe insn/optinsn slot or + * other dynamically allocated text whose lifetime Tasks RCU guards. This + * deliberately does not consult is_ftrace_trampoline() and friends: text + * being torn down may already be unregistered there while a task still + * stands on it; + * - in core text the architecture flags via arch_rcu_tasks_ip_in_trampoline(). + * + * A false positive only defers the quiescent state to the task's next + * context switch. + */ +bool rcu_tasks_ip_in_trampoline(unsigned long ip) +{ + if (core_kernel_text(ip)) + return arch_rcu_tasks_ip_in_trampoline(ip); + return !is_module_text_address(ip); +} +NOKPROBE_SYMBOL(rcu_tasks_ip_in_trampoline); + /* See if tasks are still holding out, complain if so. */ static void check_holdout_task(struct task_struct *t, bool needreport, bool *firstreport) diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index b62735a67884..23be7e97c3b5 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -41,6 +41,8 @@ #include #include #include +#include +#include #include #include #include -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415152.1644669 (Exim 4.92) (envelope-from ) id 1x4jrS-0005DS-7Q; Thu, 10 Sep 2026 18:51:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415152.1644669; Thu, 10 Sep 2026 18:51:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrS-0005DJ-4I; Thu, 10 Sep 2026 18:51:02 +0000 Received: by outflank-mailman (input) for mailman id 1415152; Thu, 10 Sep 2026 18:51:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrQ-0004zA-U2 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrQ-00BoS1-Am for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:00 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fbd5-e002-0a2a0a5209dd-0a2a4504b836-42 for ; Thu, 10 Sep 2026 20:51:00 +0200 Received: from [209.85.222.174] (helo=mail-qk1-f174.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc13-b57f-0a2a45040019-d155deaeec8c-3 for ; Thu, 10 Sep 2026 20:51:00 +0200 Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-92e85499ffbso1147785a.0 for ; Thu, 10 Sep 2026 11:50:59 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e807eba7sm47389685a.29.2026.09.10.11.50.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:50:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066259; x=1789671059; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=aLCJ034DJzI4gEh3LNSHB0+4siN8J5WsqqEdRoq/eTA=; b=WxQ3hfhb6GZ0qAc8VKLjFNT/T/sLaymAqWoXJTyrD6ltoe3GbJmEnK2pM0FoIvS+gU ZRW/viscNX7K0Rbz2z7+P6YxJ7H1I4DhJzQcplGU78OG4K6eMSU+xMXqMvgYSSlh+0ss Oh6oYK7FLke6Uz7Md5gBfUxusrFrIa6i0foszxiwUTOHZClKVSRUbUvC1+d11u+i+y1i Hvjx+C2ZSPqan/NeTlspOSlTcpnkyoZumyjfM5PGJmaw5qi0gkj1vQOR00lOA6OuTvBQ dhK6BN9Qc3Wlchdc++1LlY1T5X49G3xbQiBdYdLphDwpbz1ASFamQd8Rw/G4TXFCD7bi zBqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066259; x=1789671059; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=aLCJ034DJzI4gEh3LNSHB0+4siN8J5WsqqEdRoq/eTA=; b=jfodkSJdE8UvQUn8BRqsotdbRVR8C6Rn/zJFmovxcNe9CvgttcYdQVJFU6/S5C9yHc 5CFBFKRY4MbeaqomTBWpxr2AnHZvlXC8yJ+ik9vi09nx1sQcbXRDZCuvqqgpUmCEr9/R k5ahjXcj2MUN1KEuGxLJleulg6hV2ziFDhQL1jmnZOGD0CoQcAO771bLhRPknbEUG7LL AtnF6JrxLKLYbhk6rvxQiYyk3NOf+cVnkOgeq6En6TfizhdpRdmor7FDyonQND6aFqoe IOR4zb0t0c82u8MoUJWkYOz6hLxTTKO93GL6JM9uYSQw96chGhIaH36CJLYf9Z3QfR8C bwyQ== X-Forwarded-Encrypted: i=1; AKwUvBwwAS451I2hV6DnFtesynT6nXWqhd4vcb9EB6NqbUuwt8REfcQVWiK2QliPqBwkS/QJ73EJZ8Usf1M=@lists.xenproject.org X-Gm-Message-State: AFuF++k4w6w0ZNablti72nTbe6gctKtGanumT5Usx3x45/QW6OTw6Ezx gMCnAUMTWM9sGN8IZkJN3mwIdVOOfcrSmEIP0JevkK6RUaPTv1Lqtfzt33UEL8SG5SI= X-Gm-Gg: AYBFou1nL2Jcdtykfa1RP/q3/NnkDrpC0ZwP9wUQT85bweHZFOTcEU31DBlTzwXWuHW hYQ76aR4kUavujGfFt7NuYZElWwMJIT3NY+bVNsmYTon3F6NBuDfn/rHX8vMWdvUf5JjxxLUElB tTQ874Yx9CdEvrtNVk7du9pKw9ckhefV7mj4ByZuyEBykvatwdh2Etqw96uDfchfrDEAyAEwxSp bXsRnu2vKoPOnmcAg2j91LyWE/yOH+/PfAdxFHL0cdyYycyDxRFAwzMu+vb6Z9KDZWds6lTZMJy 0BjcVOQF6Dssf5jsv6MaZaIv/hq2NH6n+nsGXTTFgM4j0olnOivAQbOTDvyICPsOrYCI0k6eIJo OulpkmsI756lrSfftqCHlTL4V/JOaD6B6AN6dQIL8ta1IR3brR4yElcz7NtGHeA47uoICanz+22 BgprT5rhvIVxXIUCLCTT8GEIOC/GE9gp1PaKhwrZUDTNOb1S6hIzDerd3K8YxpI1skTc+8XuvH4 uDJuMf3xxjn26rHz7Gz1UXioF5A+9ctbBx66YJVk+PTVvh8wYz1o5Q/iB0gUbm0U3Q= X-Received: by 2002:a05:620a:6191:b0:939:a6e4:2267 with SMTP id af79cd13be357-939ea2bff00mr14491685a.50.1789066258414; Thu, 10 Sep 2026 11:50:58 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:27 +0000 Subject: [PATCH RFC 04/13] kprobes: Let Tasks RCU recognise tasks preempted in an optprobe jump window MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-4-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-ebf023/1789066260-C20D5B50-279DC295/0/0 X-purgate-type: clean X-purgate-size: 5160 kprobe_optimizer() is the one synchronize_rcu_tasks() user that is not about trampoline text: it waits for tasks that were preempted on an instruction boundary inside the bytes it is about to overwrite with the optimized jump, so that none of them resumes into the middle of the new instruction. Such a task sits in ordinary kernel or module text with rcu_tramp_nesting == 0, and can only have got there via an irq-exit preemption. Add kprobe_in_optimized_region(), a lockless and conservative form of get_optimized_kprobe() that reports whether any registered kprobe lies within MAX_OPTIMIZED_LENGTH before the given address regardless of its optimization state, and have rcu_tasks_ip_in_trampoline() consult it so that a task interrupted there keeps holding off the Tasks RCU grace period once preemption becomes a quiescent state. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/kprobes.h | 8 +++++++- include/linux/rcupdate.h | 4 +++- kernel/kprobes.c | 24 ++++++++++++++++++++++++ kernel/rcu/tasks.h | 6 ++++++ 4 files changed, 40 insertions(+), 2 deletions(-) diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h index e6de7ae55bda..74cc48c04417 100644 --- a/include/linux/kprobes.h +++ b/include/linux/kprobes.h @@ -530,11 +530,17 @@ static inline bool is_kprobe_insn_slot(unsigned long addr) } #endif /* !CONFIG_KPROBES */ -#ifndef CONFIG_OPTPROBES +#ifdef CONFIG_OPTPROBES +bool kprobe_in_optimized_region(unsigned long addr); +#else /* !CONFIG_OPTPROBES */ static inline bool is_kprobe_optinsn_slot(unsigned long addr) { return false; } +static inline bool kprobe_in_optimized_region(unsigned long addr) +{ + return false; +} #endif /* !CONFIG_OPTPROBES */ #ifdef CONFIG_KRETPROBES diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 0a408e36ea15..e9afbbb1b061 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -200,7 +200,9 @@ bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip); * cannot be preempted synchronously, only from an interrupt, so the irq-exit * preemption path covers it by checking regs->ip with * rcu_tasks_ip_in_trampoline() and holding the count elevated across - * preempt_schedule_irq() when it matches. + * preempt_schedule_irq() when it matches. The same check covers the one + * non-trampoline user, kprobe jump optimization, which waits for tasks + * preempted inside the instruction bytes it is about to overwrite. * * Only current writes the count and only current (or an interrupt on the same * CPU) reads it, so plain accesses suffice. diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 6337da5cab9e..76f146edb0e5 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -511,6 +511,30 @@ static struct kprobe *get_optimized_kprobe(kprobe_opcode_t *addr) return NULL; } +/** + * kprobe_in_optimized_region - Could @addr be inside bytes a jump-optimized + * kprobe replaces? + * @addr: kernel text address, typically an interrupted instruction pointer + * + * kprobe_optimizer() relies on synchronize_rcu_tasks() to wait for tasks that + * were preempted on an instruction boundary inside the region about to be + * overwritten by the optimized jump; such a task must not report a Tasks RCU + * quiescent state when it is preempted (see rcu_tasks_ip_in_trampoline()). + * This is the lockless, conservative form of get_optimized_kprobe(): it does + * not care whether the kprobe found is, or ever will be, optimized. May be + * called from any context with preemption disabled. + */ +bool kprobe_in_optimized_region(unsigned long addr) +{ + int i; + + for (i = 1; i < MAX_OPTIMIZED_LENGTH / sizeof(kprobe_opcode_t); i++) + if (get_kprobe((kprobe_opcode_t *)addr - i)) + return true; + return false; +} +NOKPROBE_SYMBOL(kprobe_in_optimized_region); + /* Optimization staging list, protected by 'kprobe_mutex' */ static LIST_HEAD(optimizing_list); static LIST_HEAD(unoptimizing_list); diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index a801ec4a951b..a55dc2a20fb7 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1114,6 +1114,9 @@ bool __weak arch_rcu_tasks_ip_in_trampoline(unsigned long ip) * deliberately does not consult is_ftrace_trampoline() and friends: text * being torn down may already be unregistered there while a task still * stands on it; + * - inside the bytes following a registered kprobe that jump optimization + * may overwrite, which kprobe_optimizer() protects with + * synchronize_rcu_tasks(); * - in core text the architecture flags via arch_rcu_tasks_ip_in_trampoline(). * * A false positive only defers the quiescent state to the task's next @@ -1121,6 +1124,9 @@ bool __weak arch_rcu_tasks_ip_in_trampoline(unsigned long ip) */ bool rcu_tasks_ip_in_trampoline(unsigned long ip) { + if (kprobe_in_optimized_region(ip)) + return true; + if (core_kernel_text(ip)) return arch_rcu_tasks_ip_in_trampoline(ip); return !is_module_text_address(ip); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415153.1644678 (Exim 4.92) (envelope-from ) id 1x4jrU-0005UO-KM; Thu, 10 Sep 2026 18:51:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415153.1644678; Thu, 10 Sep 2026 18:51:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrU-0005UB-HA; Thu, 10 Sep 2026 18:51:04 +0000 Received: by outflank-mailman (input) for mailman id 1415153; Thu, 10 Sep 2026 18:51:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrS-0005Jj-Qg for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrS-001Y5I-6h for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:02 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fbe6-2eae-0a2a0a5409dd-0a2a450b9c5c-44 for ; Thu, 10 Sep 2026 20:51:02 +0200 Received: from [209.85.160.172] (helo=mail-qt1-f172.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc15-b7e8-0a2a450b0019-d155a0aca9f1-3 for ; Thu, 10 Sep 2026 20:51:02 +0200 Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-52fa9c055b5so15088301cf.1 for ; Thu, 10 Sep 2026 11:51:01 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530ca45bbd7sm230971cf.8.2026.09.10.11.50.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:50:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066260; x=1789671060; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=+J5TsPokEtcBZgoC4/eVwMDHhzV3+rip9BUfjH6oWiE=; b=k2R7qgxLhaHpZMFV/FyIOtpDdDYG7ItfL9mSXNlvwpkXAdW03/OTnYYWXvByjTyssM 3KNGBgdzufCpH+kpKr2qrqcYaxOSqT5LYw0nKbpDUv033fnfAlir1Qhf6/YLs0GDQ/+j 395RLubVGLbincc4DSqwSnkWvYYT7mvbPD/sWDoKXIWNnh6QDILp3GK1TQSfVVbG7yu3 6EIyo8xBhleT7oEXJW2I91L48zMHrY/LuRhk2107nspNYaNCxib7rfppkpReHw+CI1zr YbgmgVh8GLTmW9xi/x293MLfuMRVD2C3ucShGQ2Ezf5RALWXpFlTyZkv4CUYQtA4SdDg jGZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066260; x=1789671060; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+J5TsPokEtcBZgoC4/eVwMDHhzV3+rip9BUfjH6oWiE=; b=eSk5sFgApxPkP5RDZE4teOHL+1jfD0MKJNyJJDvK36JbdPr74HDHlUF02AhdxdvJu3 H4WMXzoi66Ws8yIxnBCV//FPzScwY2EFG68cBI1Z5amKDF+ZxTcGSEzCv6wQmqVdKZDt nN31xlPXQK/Rxj00Ypr6iRvJ1p0XG+tuhXUOoFK0A8Mx5LQyz0ojaSqTL3jv7UBW/NZD JXEzafclB3v28v9dLry2np+rL7nb6RBKHP7dUyK6Y0695t/bQwWZtneCvoDg6u8aNRwH rBRmEQYRBDDrtrqU0n13TVFxB5pVfTKwI+5CrnK05LZRV2aai78IPJEc1mliKdk7zneX pWzA== X-Forwarded-Encrypted: i=1; AKwUvBzR6wGBwNRucABzd8SheaRAeYyVmx6LjFfTdV2Jm1BPZYtROM4ZqVRPkUttRFOITAQKysBZA9KR5O0=@lists.xenproject.org X-Gm-Message-State: AFuF++meniDitsiMzoGgliQSbhZMDvZV9azrOfhe1iiEz4hiiMwhC2R5 R4PKFYID/MH3tUUd/8eds+PIgpxY3oAfOhHZiLLO5YRKOuJ0YyR4MmXpd/RbSfKx4tI= X-Gm-Gg: AYBFou2JcePGI8RETKalPi96RUeBHawaENDHZ0dl1fguPumgQnPy9XAbXO/GTmNxHE7 IXE61XlnDtj02rIaSySn+LheCLlJqKKmyfQj5XYS45jYHep/+N7DJGFpL8qmWDgaNjvTsjhGm3+ t3GSLGuTSlAz3V4XAF2DhKEs0+Nq4KgFVhItvY8tfK0cAGBt3ojAZOtEzkrEJNJhvfJBv5xOU7c mVL9udXJyFfUHilXNk5/q6ZY4+wCY8U1kH/9NYju7bdwBUldy3bNrcPxogbO1BmVrnoDOMHeq/k UXfsXyZGa+Sz9PCHISFrCpK3XQVVR8brXtVfUfpk4aW+mIId+6yEWLL+Th36WEmKPjPEHdNv3BZ tCxDmc4DinylRnYt0fn5Hpnf9WbtnchNrlDQzAFkUbuG50fc4pgo/ErgWKNCiHR0Lt4lZuqGKEf XyWxFRal2DRZWrsNSQ/iTG+I8khf4olbVM7ER632U5xBcg6HcgMbvjSWVxvDIvSJY7wjfFyYugF gZ8Qs8Z/Yhr+L2XR4aMvF8DxuZ1hDCwoE6DIKCEGoazfLROQ8HHSc2w X-Received: by 2002:ac8:6f19:0:b0:530:4773:113d with SMTP id d75a77b69052e-530b35ec4f6mr85380621cf.27.1789066260401; Thu, 10 Sep 2026 11:51:00 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:28 +0000 Subject: [PATCH RFC 05/13] ftrace: Mark modules hosting direct-call trampolines for Tasks RCU MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-5-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-42698a/1789066262-AB0DD9EA-7F2523CD/0/0 X-purgate-type: clean X-purgate-size: 7070 An out-of-line direct trampoline registered with register_ftrace_direct() is kept alive only by Tasks RCU while a task executes it or is preempted in something it called; ftrace_shutdown()'s synchronize_rcu_tasks() is what stops rmmod freeing it under such a task. Once preemption becomes a Tasks RCU quiescent state, such a trampoline must hold current->rcu_tramp_nesting across its call-out like the ftrace and BPF trampolines do, so document that in register_ftrace_direct(). That still leaves the few instructions before the increment and after the decrement. For BPF images those are in dynamically allocated text that rcu_tasks_ip_in_trampoline() already treats as protected, but the in-tree samples (and any similar user) place their trampolines in module .text. Add a sticky module::ftrace_direct_tramp flag, set by every register/modify path when the direct address is module text, and have rcu_tasks_ip_in_trampoline() treat a task interrupted anywhere in such a module as a potential reader. Other modules' text is unaffected. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/module.h | 7 +++++++ kernel/rcu/tasks.h | 23 +++++++++++++++++++++-- kernel/trace/ftrace.c | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 67 insertions(+), 2 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 96cc98568eea..ea4727f53fab 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -521,6 +521,13 @@ struct module { unsigned int num_ftrace_callsites; unsigned long *ftrace_callsites; #endif +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS + /* + * An ftrace direct-call trampoline lives in this module's text; see + * rcu_tasks_ip_in_trampoline(). Sticky once set. + */ + bool ftrace_direct_tramp; +#endif #ifdef CONFIG_KPROBES void *kprobes_text_start; unsigned int kprobes_text_size; diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index a55dc2a20fb7..df68a330769a 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1117,19 +1117,38 @@ bool __weak arch_rcu_tasks_ip_in_trampoline(unsigned long ip) * - inside the bytes following a registered kprobe that jump optimization * may overwrite, which kprobe_optimizer() protects with * synchronize_rcu_tasks(); - * - in core text the architecture flags via arch_rcu_tasks_ip_in_trampoline(). + * - in core text the architecture flags via arch_rcu_tasks_ip_in_trampoline(); + * - in the text of a module that hosts an ftrace direct-call trampoline, + * which covers the instructions before that trampoline's increment and + * after its decrement (see ftrace_direct_mark_module()). * * A false positive only defers the quiescent state to the task's next * context switch. */ bool rcu_tasks_ip_in_trampoline(unsigned long ip) { + bool ret = true; + if (kprobe_in_optimized_region(ip)) return true; if (core_kernel_text(ip)) return arch_rcu_tasks_ip_in_trampoline(ip); - return !is_module_text_address(ip); + +#ifdef CONFIG_MODULES + scoped_guard(rcu) { + struct module *mod = __module_text_address(ip); + +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS + if (mod) + ret = READ_ONCE(mod->ftrace_direct_tramp); +#else + if (mod) + ret = false; +#endif + } +#endif + return ret; } NOKPROBE_SYMBOL(rcu_tasks_ip_in_trampoline); diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 53d5db60bfa5..14f27b887231 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6076,6 +6076,29 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) ops->trampoline = 0; } +/* + * A direct trampoline may live in module text rather than in dynamically + * allocated text that rcu_tasks_ip_in_trampoline() recognises on its own (see + * samples/ftrace/ftrace-direct*.c). The trampoline itself must hold + * current->rcu_tramp_nesting across its call-out (see register_ftrace_direct()); + * marking the owning module here covers the instructions before that increment + * and after the decrement, where a task interrupted in the module's text must + * not be treated as Tasks-RCU quiescent, so that ftrace_shutdown()'s + * synchronize_rcu_tasks() still keeps the module text from being freed under + * it. + */ +static void ftrace_direct_mark_module(unsigned long addr) +{ +#ifdef CONFIG_MODULES + struct module *mod; + + guard(rcu)(); + mod = __module_text_address(addr); + if (mod) + WRITE_ONCE(mod->ftrace_direct_tramp, true); +#endif +} + /** * register_ftrace_direct - Call a custom trampoline directly * for multiple functions registered in @ops @@ -6090,6 +6113,17 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) * and save the parameters of the function being traced, and restore them * (or inject new ones if needed), before returning. * + * Nothing but Tasks RCU keeps the trampoline at @addr alive while a task is + * executing it or is preempted in something it called. On architectures that + * select ARCH_HAS_RCU_TASKS_PREEMPT_QS a preemption is a Tasks RCU quiescent + * state unless current->rcu_tramp_nesting is non-zero, so the trampoline must + * increment it before calling out and decrement it before returning, as the + * ftrace and BPF trampolines do (see rcu_tasks_trampoline_enter() and + * samples/ftrace/ftrace-direct.h). The few instructions before the increment + * and after the decrement are covered by the irq-exit IP check: automatically + * for trampolines outside kernel and module text (e.g. BPF images), and via + * ftrace_direct_mark_module() for trampolines in module text. + * * Returns: * 0 on success * -EINVAL - The @ops object was already registered with this call or @@ -6169,6 +6203,7 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) ops->flags |= MULTI_FLAGS; ops->trampoline = FTRACE_REGS_ADDR; ops->direct_call = addr; + ftrace_direct_mark_module(addr); err = register_ftrace_function_nolock(ops); if (err) @@ -6237,6 +6272,8 @@ __modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) lockdep_assert_held_once(&direct_mutex); + ftrace_direct_mark_module(addr); + /* Enable the tmp_ops to have the same functions as the direct ops */ ftrace_ops_init(&tmp_ops); tmp_ops.func_hash = ops->func_hash; @@ -6419,6 +6456,7 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash) hlist_for_each_entry(entry, &hash->buckets[i], hlist) { if (__ftrace_lookup_ip(direct_functions, entry->ip)) goto out_unlock; + ftrace_direct_mark_module(entry->direct); } } @@ -6702,6 +6740,7 @@ int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, b tmp = __ftrace_lookup_ip(direct_hash, entry->ip); if (!tmp) continue; + ftrace_direct_mark_module(entry->direct); tmp->direct = entry->direct; } } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415154.1644688 (Exim 4.92) (envelope-from ) id 1x4jrW-0005lY-W2; Thu, 10 Sep 2026 18:51:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415154.1644688; Thu, 10 Sep 2026 18:51:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrW-0005lL-Qf; Thu, 10 Sep 2026 18:51:06 +0000 Received: by outflank-mailman (input) for mailman id 1415154; Thu, 10 Sep 2026 18:51:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrV-0005XH-0p for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrU-00GcVR-DT for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:04 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fc02-bab6-0a2a0a5309dd-0a2a4505895e-24 for ; Thu, 10 Sep 2026 20:51:04 +0200 Received: from [209.85.160.175] (helo=mail-qt1-f175.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc17-4cb1-0a2a45050019-d155a0afe0fa-3 for ; Thu, 10 Sep 2026 20:51:04 +0200 Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-5306d609317so1134411cf.2 for ; Thu, 10 Sep 2026 11:51:03 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f45a780sm2547836d6.10.2026.09.10.11.51.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:51:01 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066263; x=1789671063; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sAaaOhrJ7Jcw63o+Xz8kKBY4jQKDr2HCsih3+9envV4=; b=iMdfafnxHmbTYoQLU5GtDkFqgWcS9zyZTR6ftc+GmmdOJzaZZG+SXqYLtWTaurTkrO eJEGeV6ENiZWYXHBlfoyEor5VIJcGMRtWRHNjfo1uPOntmfmGeUqxWUD7BrXgn/tWbun hYZF8cAysRcbJJCC5iVZH/oN7WFVLY9cZFQAmFgPcinc1h7aqLKbVlDjvgTylwLDEUHL /b4PoGO1Mbx8y5M0cf8H2dQkGk/d7ViGDoAnmPcpyWOQLejgcmvgLPFRFkdqggaUnXCW kHTtsqrmzyk+THRkWTUNDMHoZsIgP92KrA6o14bkZvBGs8PPJWHWg3cLJ7hOzXAMXSZO zITQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066263; x=1789671063; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=sAaaOhrJ7Jcw63o+Xz8kKBY4jQKDr2HCsih3+9envV4=; b=ZXqyKIkYdPfwEKLl2m8HDiUkv9sv/VAp3qkDC1b/5g1EUbsWE02PQXeHE5boM6/31i DLFBFaRnW6ZsygnQLsET4p5AA3cjoQn2sX8iO3JyCYM4GIcdIHcFSAy6pPVpR2XZsi6s p6sScywp+JNSfgvxufgPTLWmoxw/6kqJ5r4RiRwPdtJ51M1xZl29CrygMLp0BE621j5J HBzyQBfvSUbg4rUxY/2OGLguX6waYPT6wylZyHIC4SFqjPvyaVTffqX0MkfeGujKcrC/ WSe5OIPOlKY3zPb9yKFVMB2oGHyGp/wVygP6ZQdHs2Ra9/6H/q24tKgtgMguUlKazZo4 hI5Q== X-Forwarded-Encrypted: i=1; AKwUvBwaV3L/XH7uGrlBizYSPSeQHF0vZ0R2yUHlIZjuEQvm/eFBcqtboc8XSR8426e5u3kj8MEBq7Zql6M=@lists.xenproject.org X-Gm-Message-State: AFuF++kjGdFcpOrK4jMIqZMCwvWLe+ltLtvVzYjVfhdbUQWj32AMUT/U h8f+sDaYDMamgYd93CWvlcKEZpKuZTJjye1DuGjOqIOox8UdvolHPRVPurxhiGp2WMk= X-Gm-Gg: AYBFou11C1PEK0++Iz+yGR5aJiOkpt+em+ikRflk7ENIW9GblQHtcmdtvjrOoNzWlwd VfON1BiY0RVWE/n/19JyvMTPDfXVi9hadinKI/RqWEQmkztujBhi1pXxo7SKXOnEPVi+EUUSbFk 9R8hpItcfaXYfbIiuj1dAAXrLRotGr68QfmXSzBEYFlcGt06APvodelp88C2GyEnpRfigmIqSeX +1Bw/58qw6iCv8Y6hzYVN+Dv4P+Hy8VLKTqXXGp4ZwqeItwi+TGDOdRMBrWNlJXt0kBYq8OSiPj NdDbBILdVlUFq+NnXZCF8HAI8dEvzdtSAa1W4rf/PBTxga0oUSXjoAilJy3vnm4WYqLw0NRpKHz jqYIk0WqrByS6Ef5UTJws36QDnOdBO60YzE1AQqalG1fHO7NoVCCkgW0bKjDlLYMTAGSrd7+qnm pZTMqwAi41t3q5UEdOGoAhNmFbNNC5/2IYB34Z/FVOmwuZ7+e1POtimxyrYd1NMesJdNpPGB6tg cMO9aBD5Xl9yUQG79aiC5cOHLV1OnDSgQ/mBz9T21QHWXM89tkHzCxH X-Received: by 2002:a05:622a:1309:b0:530:42d4:4c98 with SMTP id d75a77b69052e-530c8756e8amr10238141cf.42.1789066262237; Thu, 10 Sep 2026 11:51:02 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:29 +0000 Subject: [PATCH RFC 06/13] x86/ftrace: Maintain Tasks RCU trampoline nesting in ftrace_caller MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-6-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-c201ff/1789066264-72EB12A1-9D871752/0/0 X-purgate-type: clean X-purgate-size: 7824 Bracket the call out to the ftrace_ops callback in ftrace_caller and ftrace_regs_caller with an increment/decrement of current->rcu_tramp_nesting. The instructions sit inside the region that create_trampoline() copies for per-ops dynamic trampolines, so those inherit them; the %rip-relative per-CPU reference to current_task is fixed up by text_poke_apply_relocation() like CALL_DEPTH_ACCOUNT's. %rdx is dead at both points (about to be loaded with the ops pointer on entry, restored by restore_mcount_regs on exit). Two pieces of core text still run with the count at zero while holding the address of a Tasks-RCU-protected trampoline they are about to enter: the static stubs themselves, whose direct-call tails keep a BPF trampoline address on the stack until the final RET, and, under CONFIG_MITIGATION_RETHUNK, the return thunk that RET expands to. Add an ftrace_static_tramp_end marker after ftrace_stub_direct_tramp and linker symbols around .text..__x86.return_thunk and .text..__x86.rethunk_safe, and provide arch_rcu_tasks_ip_in_trampoline() covering [ftrace_caller, ftrace_static_tramp_end) and both thunk ranges so the irq-exit check treats a task interrupted there as still inside a trampoline. The hook is built only under CONFIG_RCU_TASKS_PREEMPT_QS, which x86 does not select until a later patch. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/kernel/asm-offsets.c | 3 +++ arch/x86/kernel/ftrace.c | 37 +++++++++++++++++++++++++++++++++++++ arch/x86/kernel/ftrace_64.S | 43 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/vmlinux.lds.S | 4 ++++ 4 files changed, 87 insertions(+) diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c index 081816888f7a..4f3b1caa5a30 100644 --- a/arch/x86/kernel/asm-offsets.c +++ b/arch/x86/kernel/asm-offsets.c @@ -46,6 +46,9 @@ static void __used common(void) #ifdef CONFIG_STACKPROTECTOR OFFSET(TASK_stack_canary, task_struct, stack_canary); #endif +#ifdef CONFIG_TASKS_RCU + OFFSET(TASK_rcu_tramp_nesting, task_struct, rcu_tramp_nesting); +#endif BLANK(); OFFSET(pbe_address, pbe, address); diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index 17d6edfcb7e0..8f63cd4b543c 100644 --- a/arch/x86/kernel/ftrace.c +++ b/arch/x86/kernel/ftrace.c @@ -275,6 +275,43 @@ static inline void tramp_free(void *tramp) execmem_free(tramp); } +#ifdef CONFIG_RCU_TASKS_PREEMPT_QS +extern void ftrace_static_tramp_end(void); +extern char __return_thunk_start[], __return_thunk_end[]; +extern char __rethunk_safe_start[], __rethunk_safe_end[]; + +/* + * See rcu_tasks_ip_in_trampoline(). Some core kernel text behaves like a + * trampoline for Tasks RCU purposes because a task executing there with + * rcu_tramp_nesting == 0 may still be about to enter a Tasks-RCU-protected + * trampoline whose address it already holds: + * + * - the static ftrace_caller / ftrace_regs_caller / ftrace_stub_direct_tramp + * stubs, which carry a direct-call target on the stack until their final + * RET, and + * - the return thunks that RET expands to under CONFIG_MITIGATION_RETHUNK, + * which run after leaving the stubs above and before landing in that + * target. + */ +bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip) +{ + if (ip >= (unsigned long)ftrace_caller && + ip < (unsigned long)ftrace_static_tramp_end) + return true; +#ifdef CONFIG_MITIGATION_RETPOLINE + if (ip >= (unsigned long)__return_thunk_start && + ip < (unsigned long)__return_thunk_end) + return true; +#endif +#ifdef CONFIG_MITIGATION_SRSO + if (ip >= (unsigned long)__rethunk_safe_start && + ip < (unsigned long)__rethunk_safe_end) + return true; +#endif + return false; +} +#endif /* CONFIG_RCU_TASKS_PREEMPT_QS */ + /* Defined as markers to the end of the ftrace default trampolines */ extern void ftrace_regs_caller_end(void); extern void ftrace_caller_end(void); diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index 62c1c93aa1c6..902472c41798 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -145,6 +146,27 @@ SYM_FUNC_END(ftrace_stub_graph) #ifdef CONFIG_DYNAMIC_FTRACE +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). These live + * inside the region copied into dynamic trampolines; the %rip-relative per-CPU + * reference is fixed up by text_poke_apply_relocation() in create_trampoline(). + * The increment must precede the function_trace_op load: between that load and + * the call, the ops pointer in %rdx is protected only by Tasks RCU. + */ +.macro RCU_TASKS_TRAMP_ENTER reg:req +#ifdef CONFIG_TASKS_RCU + movq PER_CPU_VAR(current_task), \reg + incl TASK_rcu_tramp_nesting(\reg) +#endif +.endm + +.macro RCU_TASKS_TRAMP_EXIT reg:req +#ifdef CONFIG_TASKS_RCU + movq PER_CPU_VAR(current_task), \reg + decl TASK_rcu_tramp_nesting(\reg) +#endif +.endm + SYM_FUNC_START(__fentry__) ANNOTATE_NOENDBR CALL_DEPTH_ACCOUNT @@ -163,6 +185,8 @@ SYM_FUNC_START(ftrace_caller) leaq MCOUNT_REG_SIZE+8(%rsp), %rcx movq %rcx, RSP(%rsp) + RCU_TASKS_TRAMP_ENTER %rdx + SYM_INNER_LABEL(ftrace_caller_op_ptr, SYM_L_GLOBAL) ANNOTATE_NOENDBR /* Load the ftrace_ops into the 3rd parameter */ @@ -181,6 +205,8 @@ SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) ANNOTATE_NOENDBR call ftrace_stub + RCU_TASKS_TRAMP_EXIT %rdx + /* Handlers can change the RIP */ movq RIP(%rsp), %rax movq %rax, MCOUNT_REG_SIZE(%rsp) @@ -209,6 +235,8 @@ SYM_FUNC_START(ftrace_regs_caller) CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER %rdx + SYM_INNER_LABEL(ftrace_regs_caller_op_ptr, SYM_L_GLOBAL) ANNOTATE_NOENDBR /* Load the ftrace_ops into the 3rd parameter */ @@ -246,6 +274,8 @@ SYM_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL) ANNOTATE_NOENDBR call ftrace_stub + RCU_TASKS_TRAMP_EXIT %rdx + /* Copy flags back to SS, to restore them */ movq EFLAGS(%rsp), %rax movq %rax, MCOUNT_REG_SIZE(%rsp) @@ -328,6 +358,19 @@ SYM_FUNC_START(ftrace_stub_direct_tramp) RET SYM_FUNC_END(ftrace_stub_direct_tramp) +/* + * [ftrace_caller, ftrace_static_tramp_end) is treated as trampoline text by + * rcu_tasks_ip_in_trampoline(): after RCU_TASKS_TRAMP_EXIT the stubs may + * still hold a direct-call target (a BPF trampoline) on the stack until the + * final RET, and that target's lifetime is guarded by Tasks RCU. With + * return thunks the RET itself runs elsewhere; arch_rcu_tasks_ip_in_trampoline() + * covers the thunk text too. + */ +SYM_CODE_START_NOALIGN(ftrace_static_tramp_end) + UNWIND_HINT_UNDEFINED + ANNOTATE_NOENDBR +SYM_CODE_END(ftrace_static_tramp_end) + #else /* ! CONFIG_DYNAMIC_FTRACE */ SYM_FUNC_START(__fentry__) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 2438b89a4620..e546283dc267 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -151,7 +151,9 @@ SECTIONS * definition. */ . = srso_alias_untrain_ret | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20); + __rethunk_safe_start = .; *(.text..__x86.rethunk_safe) + __rethunk_safe_end = .; #endif ALIGN_ENTRY_TEXT_END @@ -162,7 +164,9 @@ SECTIONS SOFTIRQENTRY_TEXT #ifdef CONFIG_MITIGATION_RETPOLINE *(.text..__x86.indirect_thunk) + __return_thunk_start = .; *(.text..__x86.return_thunk) + __return_thunk_end = .; #endif STATIC_CALL_TEXT *(.gnu.warning) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415156.1644696 (Exim 4.92) (envelope-from ) id 1x4jrZ-00063q-5M; Thu, 10 Sep 2026 18:51:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415156.1644696; Thu, 10 Sep 2026 18:51:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrZ-00063h-19; Thu, 10 Sep 2026 18:51:09 +0000 Received: by outflank-mailman (input) for mailman id 1415156; Thu, 10 Sep 2026 18:51:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrX-0005uX-PR for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrX-00BfN4-5j for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:07 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fc15-e002-0a2a0a5209dd-0a2a450cd430-16 for ; Thu, 10 Sep 2026 20:51:07 +0200 Received: from [209.85.160.176] (helo=mail-qt1-f176.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc19-f479-0a2a450c0019-d155a0b0d829-3 for ; Thu, 10 Sep 2026 20:51:06 +0200 Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-52de50e77ffso1049931cf.2 for ; Thu, 10 Sep 2026 11:51:06 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530ca47efa2sm216291cf.11.2026.09.10.11.51.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:51:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066265; x=1789671065; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=hbVlQmHCpb9zv+5BDFsE+SK081jwlXFhk4tZhnaWY5k=; b=eAC6lVWZHl5D9Win+zVmKYJI7dkTccT2i5OXUlFLhS38FccSerR8CLEoFoRa70FFgK mYMBcZ+SDERtkY//x3PazflZ/mfTOb88zK/r0gcJHUz3wlsn/evx//FGyWswxw2oqmB0 BhCbKohO91paAvYYlM8TudUGEnIAvZpVNDEWZlJjSbNtAzCDTc1RVY+ZA35AwHBW41ui AKmFe99X38O2ripXIasAkr3P1oCOc9I3c7bStL414zxoAkeoaBA+y59hp3vTonbimYWW QsLmwVeBFO1v0VWAj6hyfyM+bKqHq1CuN0FHlvOgfLKfPooxlCEmZPTATU6UUapvpaXU cimQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066265; x=1789671065; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=hbVlQmHCpb9zv+5BDFsE+SK081jwlXFhk4tZhnaWY5k=; b=tNhbhUPItUitCjq5bu5hWOimXEK/C8cRYGQ01P+1qe1e0NH4nJhu1/LAmrDZPnOKUW VS+RDH0NeVvaTJxasQTYFThMpxa6uqS0GkLSFQYFxvSXZbPgCT+/ETu+0cDy/3QM8Mwo xeG10wAepCZ6h1Bk0XTIPMvJ30OrqSch2stmZUK4j1Qi8Koeuf1a1mK9Jp3V8bsO/CX5 Ty4TTgPaWsaakcPy5I4K4/ZZum2fgTbSichjyBXzeax5t9EJEBg1Jc1VQQ8RgA2w0X22 lozcKOk386oah1XPEF7btFsfauKF1oEQ4Zpa04EoPCs/71vYiVgrdJDtmR9wz0Nf1veF Hoqw== X-Forwarded-Encrypted: i=1; AKwUvBxXLSuW3MTNrVttqTWa2YU082zPuuZ3PzmnRjM1afqR5/LilWKnbclclWXbEtE2MkgH85pBUxpc7ZY=@lists.xenproject.org X-Gm-Message-State: AFuF++nTAVxGDkwBbkyqfCwVlSq3P9RDa4t/rC4ZtsmLEyRbKAxy3x+s qguCZv2IrGbslDHPqvEdbLDt9tjA918qvhGHat1b/nLJPJ/CtZTy2uawSESzr1DBJVc= X-Gm-Gg: AYBFou0KN+5Sw1pi2mM1YvdDEXGN24hbhuJCPpP1zH7opUWiMt7EEzj0MOHlB5NwEZ3 PJIwpvUhFaxM3QPtWTbTWjhqXJBBjt78bk5M8GBXZyF56FLJnehVbIyIYwwmPIPHZcP3tdkMGbc qiiXXjY2n45ao5NlFUAjcJEp+LZdtrqc7ePij9dnAtYskeTWI24YgTqb51l1UmOyumBmKZ96aHV 1l7hVyNLw4T2pRx1VK4rxJrUYnwOEgQUrTtJWLvS/zx34yzf7DqoUYKdtjK4kq4v7HtV0kbnhOC vj5l7O/AIGO4iurZ4iyZsKvgnsmOZK+ykJc/IiPcfq1S35X9CuZkk3mKWoMPX+9QDQ1OE/GFn1x cImen90+wBoqdW9O69PUUH7Qs4b/e3KtTsD8fo5OTQXdzS88VnCYb1xa8mZv0NJbiGBn/TG+lfp UtV7Y+CVfPj1D8PcbjFaxONwPY8IBoGpv1Fbc/eS5moJZcffp/Ix/dQc9ohorgeyFVFApbGdgjz 0O0UfZ3Qn6rRHN3kKRqA+xLZ8oQFjiK4nn1pMqa/aaSVV/JQCQEtQbq X-Received: by 2002:a05:622a:1309:b0:530:42e4:effc with SMTP id d75a77b69052e-530c87566f0mr10949261cf.41.1789066264886; Thu, 10 Sep 2026 11:51:04 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:30 +0000 Subject: [PATCH RFC 07/13] x86/kprobes: Maintain Tasks RCU trampoline nesting in the optprobe template MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-7-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-d25034/1789066267-022C0A5B-FD6BC4CB/0/0 X-purgate-type: clean X-purgate-size: 2638 The jump-optimized kprobe template calls optimized_callback() with preemption still enabled for its first few instructions, so bracket the call with an increment/decrement of current->rcu_tramp_nesting. The template lives in .rodata and is memcpy()d into each optinsn slot without relocation processing, so the per-CPU reference to current_task must be an absolute %gs: address (R_X86_64_32S, relocated for KASLR like any other) rather than %rip-relative. %rax has already been saved by SAVE_REGS_STRING and is dead after the call. The slot itself is dynamically allocated text, so the instructions before the increment and after the decrement are covered by the irq-exit IP check. 64-bit only; 32-bit x86 does not take part. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/kernel/kprobes/opt.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c index 3f8fea52619f..f722520bb989 100644 --- a/arch/x86/kernel/kprobes/opt.c +++ b/arch/x86/kernel/kprobes/opt.c @@ -31,6 +31,7 @@ #include #include #include +#include #include "common.h" @@ -101,6 +102,23 @@ static void synthesize_set_arg1(kprobe_opcode_t *addr, unsigned long val) *(unsigned long *)addr = val; } +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). The + * template is memcpy()d into the slot without relocation processing, so the + * per-CPU reference must be absolute, not %rip-relative. + */ +#if defined(CONFIG_TASKS_RCU) && defined(CONFIG_X86_64) +#define OPTPROBE_RCU_TASKS_ENTER \ + " movq %gs:current_task, %rax\n" \ + " incl " __stringify(TASK_rcu_tramp_nesting) "(%rax)\n" +#define OPTPROBE_RCU_TASKS_EXIT \ + " movq %gs:current_task, %rax\n" \ + " decl " __stringify(TASK_rcu_tramp_nesting) "(%rax)\n" +#else +#define OPTPROBE_RCU_TASKS_ENTER +#define OPTPROBE_RCU_TASKS_EXIT +#endif + asm ( ".pushsection .rodata\n" ".global optprobe_template_entry\n" @@ -114,6 +132,7 @@ asm ( "optprobe_template_clac:\n" ASM_NOP3 SAVE_REGS_STRING + OPTPROBE_RCU_TASKS_ENTER " movq %rsp, %rsi\n" ".global optprobe_template_val\n" "optprobe_template_val:\n" @@ -122,6 +141,7 @@ asm ( ".global optprobe_template_call\n" "optprobe_template_call:\n" ASM_NOP5 + OPTPROBE_RCU_TASKS_EXIT /* Copy 'regs->flags' into 'regs->ss'. */ " movq 18*8(%rsp), %rdx\n" " movq %rdx, 20*8(%rsp)\n" -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415163.1644704 (Exim 4.92) (envelope-from ) id 1x4jrc-0006Pj-II; Thu, 10 Sep 2026 18:51:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415163.1644704; Thu, 10 Sep 2026 18:51:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrc-0006PV-F9; Thu, 10 Sep 2026 18:51:12 +0000 Received: by outflank-mailman (input) for mailman id 1415163; Thu, 10 Sep 2026 18:51:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrb-0006N7-NO for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrb-00Gcad-3w for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fc17-bab6-0a2a0a5309dd-0a2a4502e940-10 for ; Thu, 10 Sep 2026 20:51:11 +0200 Received: from [209.85.222.172] (helo=mail-qk1-f172.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc1e-6ca4-0a2a45020019-d155deaca438-3 for ; Thu, 10 Sep 2026 20:51:10 +0200 Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-92ed19f4d60so13505785a.0 for ; Thu, 10 Sep 2026 11:51:10 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e7f1da12sm50063385a.9.2026.09.10.11.51.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:51:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066269; x=1789671069; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=q0Z6kl89L/mcJKSDFUzFWtYRNb/tGGuag8yv3GYWCr4=; b=Kw2a+A60926yogG1g0r4S8egw4amFvo40bjc7giALBVUBsmb7WmCNZjPflHSUYpHHR ARvgH3T/actVPbBkWQhNsRf7ENpYgVuuJ/dZztDZ/fTNeb9VELLQc8NluXiFVQgoFvOt Py6yUYYdm5cQEX0LjvfWsIi5A/FjGSSoa3/ft3jkuZX0bmzoLbfkhcOXAqgntgHX3zGP bDre1BTWI0is9DXY0g7SI0qQk9hQZdqCO0WXocCEs1gViQkVFX6oVOY66/HdmDxQrtA4 MnMlvOzv4PKkrDjtLdA6jGFinWRiWad3h4u0o++w6akBg/boanqEgMXa/q8eZdHkycwy YKiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066269; x=1789671069; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=q0Z6kl89L/mcJKSDFUzFWtYRNb/tGGuag8yv3GYWCr4=; b=lJwBdA+2jcR/Yq41IekeHbJ9z3aXH3BT8kJzl0ov/xPTyArY9uKl+q8bTJulvFWm+w j8ky7Ge59Xznpsu+XDRfiM6CyIhIQ4rm/aivCun8ghAcPsmVdGzzfSFPClx9pgCzMaiY 5yzo9cUalr75mC74a8/pohP31qfXXc1FG6FT3bPZsiKbI6GlzeqKDPXTitwW0iMFFsPj /QxicE9BlJKnbMDoqSHClwcsfxIygFeRwCstjVgjX1X4nIP6BiKLnpL9oqpemZfy5Q9/ Ha/I7pQndPYVR6ydm04Rb6jwxSIyB5nmQexkyci1iQxDvdhDlSsGiztxaLk7WDCplrSw wSrw== X-Forwarded-Encrypted: i=1; AKwUvBzqa4TaVMW2V7ybBGevtT16IJWY/0fcy3THDSetJYwF1JhDC5lafBRKG0aUsg8JZ17GvE938lgWoho=@lists.xenproject.org X-Gm-Message-State: AFuF++mat/9V6y54+McACBm43VdQsckpAPtsYqeR0a/qVawL+gPY+0Xn dPYzn5eJX+Vjyb4EgJlnoCuiCdLsCUO8wo22ISa6eq/QrUspAVGFYYCoypWoCJLwbdM= X-Gm-Gg: AYBFou24Sj95eA8I/JHAEBhJXmoLaxCsmqrHZMy1aQwq5rRnFarBLTZBjpeYvrbOKUN 2wUXcBgrJ+eOT+5p4sJCRV4B3450+HBzaeG3lfUUqU2TuvyVTmT8dsUukASajT/2iTEMpuHaX/2 dSogTHEjmPBdrhq/nwWY5hEAy7jqWRZxA8FzmVXiOPlg8kNm+sSzwbcenkKdc8MtUQoIpp/hlmv kyi5EVIZcFNfpuzmJtM6WpKgE1LOaTUne+5eHlsJx4WwsJzQgkNtSSQNutqOEJfjabMnGgGTmYO JB6gFEO9ofEt2K4/+jETAqepFTUOa2rA9X2TSlrqmxmpMGdoxyzOOB0foApvkbamptaAXHkYBO0 rxbjxzQYYx3XNBghcdB/FVyOF6XQZLI9BG9vF2biZkLOL0dTfPIhPzeFGossAmQfuEL8eOkkb3y yy4bKHwKEYVW98Lxv4TCx8hAVTIU5KEsOxuD904MHHK71mmlixRe+0ZkME+G34cLTABsmye1r/u rRB+lIzi7mQ8WHj27hz9lx2B/m3lAI26f20qQq1gEm9v9oqHgGtJGSm1lJFrkaPEAU= X-Received: by 2002:a05:620a:1a0a:b0:939:ca72:bef8 with SMTP id af79cd13be357-939d7fe4f58mr706492885a.41.1789066269332; Thu, 10 Sep 2026 11:51:09 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:32 +0000 Subject: [PATCH RFC 09/13] arm64: ftrace: Maintain Tasks RCU trampoline nesting in ftrace_caller MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-9-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-720697/1789066271-323D42AC-D8908D05/0/0 X-purgate-type: clean X-purgate-size: 5219 Bracket the call out to the ftrace_ops callback in ftrace_caller with an increment/decrement of current->rcu_tramp_nesting, using x12/w13 which are scratch there. The read-modify-write is not atomic, but only current modifies the count and every interrupting user is balanced, so nothing is lost. ftrace_caller itself, including the early CALL_OPS direct path and the late direct tail that carry a BPF trampoline address in x17 with the count at zero, is static kernel text: add an ftrace_static_tramp_end marker after ftrace_stub_direct_tramp and provide arch_rcu_tasks_ip_in_trampoline() covering [ftrace_caller, ftrace_static_tramp_end) so the irq-exit check treats a task interrupted anywhere in it as inside a trampoline. The hook is built only under CONFIG_RCU_TASKS_PREEMPT_QS, which arm64 does not select until a later patch. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/arm64/kernel/asm-offsets.c | 3 +++ arch/arm64/kernel/entry-ftrace.S | 35 +++++++++++++++++++++++++++++++++++ arch/arm64/kernel/ftrace.c | 16 ++++++++++++++++ 3 files changed, 54 insertions(+) diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 9c853ed3ceab..f6655a284f18 100644 --- a/arch/arm64/kernel/asm-offsets.c +++ b/arch/arm64/kernel/asm-offsets.c @@ -39,6 +39,9 @@ int main(void) DEFINE(TSK_STACK, offsetof(struct task_struct, stack)); #ifdef CONFIG_STACKPROTECTOR DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary)); +#endif +#ifdef CONFIG_TASKS_RCU + DEFINE(TSK_RCU_TRAMP_NESTING, offsetof(struct task_struct, rcu_tramp_nesting)); #endif BLANK(); DEFINE(THREAD_CPU_CONTEXT, offsetof(struct task_struct, thread.cpu_context)); diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S index 025140caafe7..46a102e7199a 100644 --- a/arch/arm64/kernel/entry-ftrace.S +++ b/arch/arm64/kernel/entry-ftrace.S @@ -14,6 +14,33 @@ #include #ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). The whole + * of ftrace_caller is treated as trampoline text by the irq-exit IP check (see + * arch_rcu_tasks_ip_in_trampoline()), so these only need to bracket the call + * out to ops->func; everything before the increment and after the decrement, + * including the direct-call tails that carry a BPF trampoline address in x17, + * is covered by that. The count is only modified by current and every nested + * user (interrupts) is balanced, so a plain ldr/add/str is sufficient. + */ + .macro rcu_tasks_tramp_enter, tsk:req, tmp:req +#ifdef CONFIG_TASKS_RCU + mrs \tsk, sp_el0 + ldr \tmp, [\tsk, #TSK_RCU_TRAMP_NESTING] + add \tmp, \tmp, #1 + str \tmp, [\tsk, #TSK_RCU_TRAMP_NESTING] +#endif + .endm + + .macro rcu_tasks_tramp_exit, tsk:req, tmp:req +#ifdef CONFIG_TASKS_RCU + mrs \tsk, sp_el0 + ldr \tmp, [\tsk, #TSK_RCU_TRAMP_NESTING] + sub \tmp, \tmp, #1 + str \tmp, [\tsk, #TSK_RCU_TRAMP_NESTING] +#endif + .endm + /* * Due to -fpatchable-function-entry=2, the compiler has placed two NOPs before * the regular function prologue. For an enabled callsite, ftrace_init_nop() and @@ -94,6 +121,8 @@ SYM_CODE_START(ftrace_caller) stp x29, x30, [sp, #FREGS_SIZE] add x29, sp, #FREGS_SIZE + rcu_tasks_tramp_enter x12, w13 + /* Prepare arguments for the tracer func */ sub x0, x30, #AARCH64_INSN_SIZE // ip (callsite's BL insn) mov x1, x9 // parent_ip (callsite's LR) @@ -111,6 +140,8 @@ SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) bl ftrace_stub // func(ip, parent_ip, op, regs) #endif + rcu_tasks_tramp_exit x12, w13 + /* * At the callsite x0-x8 and x19-x30 were live. Any C code will have preserved * x19-x29 per the AAPCS, and we created frame records upon entry, so we need @@ -178,6 +209,10 @@ SYM_CODE_START(ftrace_stub_direct_tramp) SYM_CODE_END(ftrace_stub_direct_tramp) #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */ +/* End of [ftrace_caller, ...) for arch_rcu_tasks_ip_in_trampoline(). */ +SYM_CODE_START(ftrace_static_tramp_end) +SYM_CODE_END(ftrace_static_tramp_end) + #else /* CONFIG_DYNAMIC_FTRACE_WITH_ARGS */ /* diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c index e1a3c0b3a051..1b7ac2afed0d 100644 --- a/arch/arm64/kernel/ftrace.c +++ b/arch/arm64/kernel/ftrace.c @@ -17,6 +17,22 @@ #include #include +#ifdef CONFIG_RCU_TASKS_PREEMPT_QS +extern void ftrace_static_tramp_end(void); + +/* + * See rcu_tasks_ip_in_trampoline(). ftrace_caller and ftrace_stub_direct_tramp + * are core kernel text but must be treated as trampolines: a task preempted in + * them may be carrying an ops pointer (x11) or a direct-call BPF trampoline + * address (x17) whose lifetime is guarded only by Tasks RCU. + */ +bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip) +{ + return ip >= (unsigned long)ftrace_caller && + ip < (unsigned long)ftrace_static_tramp_end; +} +#endif + #ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS struct fregs_offset { const char *name; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415165.1644713 (Exim 4.92) (envelope-from ) id 1x4jre-0006fa-04; Thu, 10 Sep 2026 18:51:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415165.1644713; Thu, 10 Sep 2026 18:51:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrd-0006eZ-Os; Thu, 10 Sep 2026 18:51:13 +0000 Received: by outflank-mailman (input) for mailman id 1415165; Thu, 10 Sep 2026 18:51:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrc-0006Qa-RT for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrc-001YAS-7x for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:12 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fc16-2eae-0a2a0a5409dd-0a2a4504d6e0-18 for ; Thu, 10 Sep 2026 20:51:12 +0200 Received: from [209.85.160.170] (helo=mail-qt1-f170.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc1f-b57f-0a2a45040019-d155a0aad1c4-3 for ; Thu, 10 Sep 2026 20:51:12 +0200 Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-53091987029so1493231cf.3 for ; Thu, 10 Sep 2026 11:51:11 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f47a239sm2556366d6.26.2026.09.10.11.51.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:51:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066271; x=1789671071; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7VM45t8rF8CqlHWPsaSwdk7BD4ox5LDNpAeDrj6m5qM=; b=LFkPgazcrw8BpnABGKjUhCWQdoyba0TX6luIrM7Qm2WQnLD+cmgGm4oyPaBHLo0Rz8 +gSfqx4/X/hO1JevE9rUYXf6wqBZyUSEg57kdqhiPB1Mc5lJl9glmGEUAVtvbWLo9OJi HX6rDOsv60e5yamxLDrTK13hYLVIh74DAW3rpmO6x7Fdt7Zte/a3+PO/YC7pg1Gg32mZ 5XPzdsGFwAyiYR2EAp0q++ogLg2Wb2YR8G3AhM9iNZ6+mazhE01UTXdHXjXy8DFeepFO X3XldodNBS2xmxTCoPaDLEiI/OE2yKL0Ab0nlvMxNDYYy8AepnHEq+F/0snFuDOZ7oJ6 tahw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066271; x=1789671071; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7VM45t8rF8CqlHWPsaSwdk7BD4ox5LDNpAeDrj6m5qM=; b=GctmtDuxfshuBde7qmWn7P5qaQ14r66IXlZUeq2cXfxMWWpEszgA0d574IzWLeqohi LwgLLfbcOpFWcYhODBdI7sgs4JqlYy3crIst6R4QYs60O9Bcezen8jUT9cT4CFq156nH KWR4fSw0Sv7a7vMnBOSebGnNusFVa7rFTq/CW2qxiboBaDS5Vv6M0V3Mwr4cPdZ5/lH3 fv3okBJ7nnFbUdJN2hNvIDcajNo4q9MLupV60l5daojqw5mUoRgr0vFwneQ7PVe95PNU v2oaEAm8W945wBg+XuLJxwen9wevH4dlbIDXOCYifUZY67K4fS9r36g27SpG9bJPaScw 2CKg== X-Forwarded-Encrypted: i=1; AKwUvBywYzarpWE7zVfpyzEiPFHJAF0DFPSRo0Z2All2QI6aOVUoy96H4oX2OMbsYHBZlJ+O3XctKfpGOXM=@lists.xenproject.org X-Gm-Message-State: AFuF++mKi0tYTULD+/6sqkbO8GtXAdr5gAi1YqcrRNEX0lfS1lYhPK/m WeDAJvNr+2pKpyU6TIr1UXLJdAuH4hCKWn/9FrsQ697CjP1VJvraUBKQMMMpL1rVM5A= X-Gm-Gg: AYBFou2NmfOqz6SucL/tYH2WjTbl4l0Imcizx63p3q+rm5LNFvINnZxCsI98FNQt62h OAwJdF0idXcI13aE8cCQCV1mQDynU63R8DIovemuqtwTE167Vv3OuHzLQ8ErvW+DeoZLAS3Heeb htDK9WJff7c61y4goajGwujgNKcl3PU0asIf3fycLXyUMaxbeEsNx72VIfycJAFlpcOKCXlkn7E +Zw3RkHQeUO1ekD335Cp6HIrvXhZ74X43OwFkcw1mczFsALyH83DSrmsM3/VdwmC0l20TNa15KA EQVBkWrERHVGlJXM8ZIoGeNuzPixBYC/CMCsAMx8sRm2FVjM2EE1bBoh4jIG2rVpIIbFlXuiwqs SKB0HMMxti5caijhtfy0tki1VCNc11HreXlRsJ5NQhSFlN3PjatHRiqNApC1enu1hcb+O26/be8 xV/l6QyMn10178tUr7xj16Km2mZSKlIEKyftQQGyYN/cBVIomT3SpG/CsMflz1RVAoC2d6a8Xxy Z9bhmLzk6V69crU6TYYpfRx19eqzIyTCQIIK/nHjIqO0hQy+xXth6CK X-Received: by 2002:a05:622a:2294:b0:530:b2e4:d597 with SMTP id d75a77b69052e-530c87487damr11129971cf.50.1789066266848; Thu, 10 Sep 2026 11:51:06 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:31 +0000 Subject: [PATCH RFC 08/13] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-8-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-ebf023/1789066272-C24CBB50-345CEFD1/0/0 X-purgate-type: clean X-purgate-size: 4466 Emit an increment of current->rcu_tramp_nesting once the trampoline's frame is set up and a decrement before the final register restore, so that a task preempted while running fentry/fexit/fmod_ret/LSM programs or the __bpf_tramp_enter()/__bpf_tramp_exit() glue is not treated as Tasks-RCU quiescent. Drop the count around the call to the original function: that may run arbitrarily long without sleeping and must not pin a Tasks RCU grace period, and the trampoline frame above it is held by im->pcref rather than by Tasks RCU (see bpf_tramp_image_put()). The fmod_ret early-exit branch and the ip_after_call -> ip_epilogue poke both skip the decrement/increment pair around the original call, so the count stays balanced on every path. The sequence is "mov r11, gs:[current_task]; inc/dec dword [r11 + off]"; r11 is scratch at every emission point and (u32)¤t_task is a valid sign-extended %gs-absolute with the current per-CPU layout, the same form the JIT already uses for this_cpu_off. The image is dynamically allocated text, so the instructions outside the bracketed region are covered by the irq-exit IP check. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/net/bpf_jit_comp.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c index 2853e87797a7..a375c1b7bd50 100644 --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -722,6 +722,31 @@ static void emit_indirect_jump(u8 **pprog, int bpf_reg, u8 *ip) *pprog = prog; } +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). + * + * mov r11, QWORD PTR gs:[current_task] + * inc/dec DWORD PTR [r11 + offsetof(struct task_struct, rcu_tramp_nesting)] + * + * r11 (AUX_REG) is scratch in the trampoline at every point this is emitted. + */ +static void emit_rcu_tasks_tramp_nesting(u8 **pprog, bool enter) +{ +#ifdef CONFIG_TASKS_RCU + u8 *prog = *pprog; + + /* mov r11, gs:[abs32] */ + EMIT2(0x65, 0x4C); + EMIT3(0x8B, 0x1C, 0x25); + EMIT((u32)(unsigned long)¤t_task, 4); + /* inc/dec dword ptr [r11 + disp32] */ + EMIT3(0x41, 0xFF, enter ? 0x83 : 0x8B); + EMIT(offsetof(struct task_struct, rcu_tramp_nesting), 4); + + *pprog = prog; +#endif +} + static void emit_return(u8 **pprog, u8 *ip) { u8 *prog = *pprog; @@ -3610,6 +3635,13 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im /* mov QWORD PTR [rbp - rbx_off], rbx */ emit_stx(&prog, BPF_DW, BPF_REG_FP, BPF_REG_6, -rbx_off); + /* + * From here until the matching decrement before the final return, a + * preemption of this task is not a Tasks RCU quiescent state. The + * instructions above this point are covered by the irq-exit IP check. + */ + emit_rcu_tasks_tramp_nesting(&prog, true); + func_meta = nr_regs; /* Store number of argument registers of the traced function */ emit_store_stack_imm64(&prog, BPF_REG_0, -func_meta_off, func_meta); @@ -3670,6 +3702,13 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im LOAD_TRAMP_TAIL_CALL_CNT_PTR(stack_size); } + /* + * The original function may run for a long time without + * sleeping; do not let it pin a Tasks RCU grace period. The + * trampoline frame above it is held by im->pcref + * (__bpf_tramp_enter()), not by Tasks RCU, across the call. + */ + emit_rcu_tasks_tramp_nesting(&prog, false); if (flags & BPF_TRAMP_F_ORIG_STACK) { emit_ldx(&prog, BPF_DW, BPF_REG_6, BPF_REG_FP, 8); EMIT2(0xff, 0xd3); /* call *rbx */ @@ -3680,6 +3719,7 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im goto cleanup; } } + emit_rcu_tasks_tramp_nesting(&prog, true); /* remember return value in a stack for bpf prog to access */ emit_stx(&prog, BPF_DW, BPF_REG_FP, BPF_REG_0, -8); im->ip_after_call = image + (prog - (u8 *)rw_image); @@ -3741,6 +3781,9 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im if (save_ret) emit_ldx(&prog, BPF_DW, BPF_REG_0, BPF_REG_FP, -8); + /* Remaining instructions are covered by the irq-exit IP check. */ + emit_rcu_tasks_tramp_nesting(&prog, false); + emit_ldx(&prog, BPF_DW, BPF_REG_6, BPF_REG_FP, -rbx_off); EMIT1(0xC9); /* leave */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415166.1644724 (Exim 4.92) (envelope-from ) id 1x4jrf-0006xs-Cd; Thu, 10 Sep 2026 18:51:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415166.1644724; Thu, 10 Sep 2026 18:51:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrf-0006wR-4G; Thu, 10 Sep 2026 18:51:15 +0000 Received: by outflank-mailman (input) for mailman id 1415166; Thu, 10 Sep 2026 18:51:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrd-0006ar-K6 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrd-00Gcad-0t for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:13 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fc15-bab6-0a2a0a5309dd-0a2a450695de-20 for ; Thu, 10 Sep 2026 20:51:13 +0200 Received: from [209.85.219.50] (helo=mail-qv1-f50.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc1f-195a-0a2a45060019-d155db32e079-3 for ; Thu, 10 Sep 2026 20:51:12 +0200 Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-91053c27a91so244926d6.2 for ; Thu, 10 Sep 2026 11:51:12 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f49444bsm2501436d6.29.2026.09.10.11.51.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:51:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066271; x=1789671071; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=9b8kkjvSg0tb+ScPvKP3GAz1Pld5wxO+feqfkbC4jq4=; b=Q21Q9PgSNWn30sbhwRwkPQ0MP1CC7bhnzuzlr17Fv62cS+tWK1Kk6ga5KtBb6F4ZZA 67IYtDgL8xIY9NsRt+uU+WV1rWRDuyk1re0fzX29gqfIrD4FqxA9R+tXXL7dNKKMy/6y l4kZikIvJdM27uX5FuW3SqZBQdRDKdrbLdvpKl00MB9nEHlCmk7QWHROSTCA+w0O++n2 pHR3+1DdZkoodd7Ct68VlLlAFjKICIxYz7ZZS4ah8f7XhKw5P1VKsaUOGjabgsx4uD2g S7eobRTZT6etd4pXfMRbczPQ7FzkoQbHVOZpqRjqsm2qWpwYkM9qwJ86gExNIcLYhxKt 2ELQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066271; x=1789671071; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9b8kkjvSg0tb+ScPvKP3GAz1Pld5wxO+feqfkbC4jq4=; b=C+yxX3GpHw0SXqI/HjJFSz0pN1K/MqDv4WsYVvVbrYLb7NFdFPLYcUOw4M/xpTYjtR 9PbFv24sYuLHQ56S/0XZzXnrVCK854NTLu+H4P+Gg2E9HfOuGtZxEEviRRlWk4S6r3Zq rIXjVUwNUg8efS1+pfc90RuK6AoCpHBKc8DNQGySBz36Xoy9U7402rWktd8taekaDUm+ pCNzyk5smovfYDXg72b3RvEZiGj9xhURg7IlN65W5qauvj9aOFCKU1vbfYhAcbPvXRcM pGaO9xwZJTWpIsBxWvrzpTRQbRNM6u2owRla8u8+g5gIJdtN6zf9r/bT4YZLsMlPf0bv t8KA== X-Forwarded-Encrypted: i=1; AKwUvBwP2tAHRbqRN89w4khKAMNlxNs5lCgsV+d7R0U3zl/h+hUJTTZHESmd2GlQWi9hjCHWcRwKC3QHIh0=@lists.xenproject.org X-Gm-Message-State: AFuF++kln520KST5YVE1DOX/FHvebKqrQBb63CeJmo/Yz2iStj1R5nUM cSAwnnwHzrfoaSLz0E9SyjwRkUV1EJ4lbto3g3s3NiOsizsA0xfvsKIj22Mu3+MHzZ0= X-Gm-Gg: AYBFou1koypL7wQgeFZMOngIcFtOQTqmQCoB7IC83Hfxt6ut91rSphBERbKubpDjb7X Bj47dF+0X+ZsFUj5KbGcDrRKH1YU/RbEIcU3cQ5XNMtowsIioi7Ea85Ns53WQPFyVQ+yIo83KwC r1skq6+b0IvvABpjXOzl7aad2UIKpxSTA0kktAxsL3UtrWWUgRel9seEeTssZyUoVK2gpbVSUNN 8QTB3xmJOql8S6q0G5wUlhx6qqPIWP6/hv2v/wSVqikE0zAlDzkvmthOBdtqOamevNZoVvGHqWc i7mA0C8RhjnEmd76EBurBlKGQ+7o/CIToPHGzdFuD9arm0SLA26Go1vRCeqKJ+3f5ak9oG3eObj TzRf0zlexErvJhbK24nA9LzfX07bapRIf+ZbSQhh5GQ9QwCvl7d6eHERVTOBQcWu7KraBdQKk+2 jIkwxwlDEV/K0ZxLPO1UVDFujlFHGNWA9/KB+sPNN5BNfMiJnAy+Vvb++pC1vXLR1cue+WYxkWm UYIpGx7OE+VbwnhBk/YHjRf02MYuk5EIR8jQQb1XNfERXjkZeH/8I0N X-Received: by 2002:a05:6214:5544:b0:910:52ab:59dc with SMTP id 6a1803df08f44-912120e2526mr945166d6.23.1789066271231; Thu, 10 Sep 2026 11:51:11 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:33 +0000 Subject: [PATCH RFC 10/13] bpf, arm64: Maintain Tasks RCU trampoline nesting in the BPF trampoline MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-10-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-16d1c6/1789066272-F5C0F77B-F2CA3D70/0/0 X-purgate-type: clean X-purgate-size: 4366 Same scheme as x86: emit "mrs x10, sp_el0; ldr/add|sub/str w11" to bump current->rcu_tramp_nesting after the callee-saved registers are stored and to drop it before they are restored, and release it around the call to the original function, which im->pcref protects and which must not pin a Tasks RCU grace period. x10/x11 are scratch at every emission point; the fmod_ret cbnz target lies after the decrement/increment pair around the original call, and the ip_after_call nop follows the re-increment, so the count is balanced on every path. BUILD_BUG_ON guards the LDR/STR immediate range for the task_struct offset. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/arm64/net/bpf_jit_comp.c | 46 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index c18e005a41db..5c9a7bde5cc9 100644 --- a/arch/arm64/net/bpf_jit_comp.c +++ b/arch/arm64/net/bpf_jit_comp.c @@ -2591,6 +2591,34 @@ static void emit_arena_arg_conv(struct jit_ctx *ctx, u8 dst, u8 src, bool nullab emit(A64_SUB(0, dst, src, base_lo), ctx); } +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). + * + * mrs x10, sp_el0 + * ldr w11, [x10, #offsetof(struct task_struct, rcu_tramp_nesting)] + * add/sub w11, w11, #1 + * str w11, [x10, #...] + * + * x10/x11 are scratch in the trampoline at every point this is emitted. + */ +static void emit_rcu_tasks_tramp_nesting(struct jit_ctx *ctx, bool enter) +{ +#ifdef CONFIG_TASKS_RCU + const int off = offsetof(struct task_struct, rcu_tramp_nesting); + const u8 tsk = A64_R(10), cnt = A64_R(11); + + BUILD_BUG_ON(off & 3 || off >= SZ_16K); /* LDR/STR (imm12, scaled) */ + + emit(A64_MRS_SP_EL0(tsk), ctx); + emit(A64_LDR32I(cnt, tsk, off), ctx); + if (enter) + emit(A64_ADD_I(0, cnt, cnt, 1), ctx); + else + emit(A64_SUB_I(0, cnt, cnt, 1), ctx); + emit(A64_STR32I(cnt, tsk, off), ctx); +#endif +} + static void save_args(struct jit_ctx *ctx, int bargs_off, int oargs_off, const struct btf_func_model *m, const struct arg_aux *a, bool for_call_origin, bool is_struct_ops, u64 arena_base) @@ -2854,6 +2882,13 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, emit(A64_STR64I(A64_R(19), A64_SP, regs_off), ctx); emit(A64_STR64I(A64_R(20), A64_SP, regs_off + 8), ctx); + /* + * From here until the matching decrement in the epilogue, a preemption + * of this task is not a Tasks RCU quiescent state. The instructions + * above this point are covered by the irq-exit IP check. + */ + emit_rcu_tasks_tramp_nesting(ctx, true); + if (flags & BPF_TRAMP_F_CALL_ORIG) { /* for the first pass, assume the worst case */ if (!ctx->image) @@ -2898,12 +2933,20 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, if (flags & BPF_TRAMP_F_CALL_ORIG) { /* the original func takes kernel addresses, never converted ones */ save_args(ctx, bargs_off, oargs_off, m, a, true, is_struct_ops, 0); + /* + * The original function may run for a long time without + * sleeping; do not let it pin a Tasks RCU grace period. The + * trampoline frame above it is held by im->pcref + * (__bpf_tramp_enter()), not by Tasks RCU, across the call. + */ + emit_rcu_tasks_tramp_nesting(ctx, false); /* call original func */ emit(A64_LDR64I(A64_R(10), A64_SP, retaddr_off), ctx); emit(A64_ADR(A64_LR, AARCH64_INSN_SIZE * 2), ctx); emit(A64_RET(A64_R(10)), ctx); /* store return value */ emit(A64_STR64I(A64_R(0), A64_SP, retval_off), ctx); + emit_rcu_tasks_tramp_nesting(ctx, true); /* reserve a nop for bpf_tramp_image_put */ im->ip_after_call = ctx->ro_image + ctx->idx; emit(A64_NOP, ctx); @@ -2945,6 +2988,9 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, if (flags & BPF_TRAMP_F_RESTORE_REGS) restore_args(ctx, bargs_off, a->regs_for_args); + /* Remaining instructions are covered by the irq-exit IP check. */ + emit_rcu_tasks_tramp_nesting(ctx, false); + /* restore callee saved register x19 and x20 */ emit(A64_LDR64I(A64_R(19), A64_SP, regs_off), ctx); emit(A64_LDR64I(A64_R(20), A64_SP, regs_off + 8), ctx); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415168.1644732 (Exim 4.92) (envelope-from ) id 1x4jrg-0007Fn-UG; Thu, 10 Sep 2026 18:51:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415168.1644732; Thu, 10 Sep 2026 18:51:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrg-0007Fc-Ow; Thu, 10 Sep 2026 18:51:16 +0000 Received: by outflank-mailman (input) for mailman id 1415168; Thu, 10 Sep 2026 18:51:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrf-0006xY-DN for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jre-00BfN4-Pl for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:14 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fc1e-e002-0a2a0a5209dd-0a2a450bc178-6 for ; Thu, 10 Sep 2026 20:51:14 +0200 Received: from [209.85.222.54] (helo=mail-ua1-f54.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc21-b7e8-0a2a450b0019-d155de36cd42-3 for ; Thu, 10 Sep 2026 20:51:14 +0200 Received: by mail-ua1-f54.google.com with SMTP id a1e0cc1a2514c-97ca74bd6e0so133957241.1 for ; Thu, 10 Sep 2026 11:51:14 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f47aeb7sm2503906d6.24.2026.09.10.11.51.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:51:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066273; x=1789671073; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=32pR0m9lJbbl6oefWflQ2FM2YWt9ii7Ub9HEHMaojiA=; b=Kadw4Z2/sWrsZQ4RBjIq1A92bzOgmRIDQFsHMY6ls3XPG0iNxF5uxa7iMsUnuY8SgZ o+OHhjrVZj4ZM8zm1qkwxROheA0c8H7zbOIOwOH7qTBHAerKPw1ZuI6E11giqZE2FmDO hszt4sTydrMqO1LakF+p+iCMHZhOPWMBkA9LQ2yDGY43m8uPcUVO8CBszR3oR8mamZh3 TJI8v+05wegGK5Tv/Q0OFTKF5XZP4TwOESIVh/sY6Eatwc+bpgBMSS3zvjSmtwlXpTuM UyJqt5zn1HKGnSgVlllwhUVMKxMpVe1lOoRVigJnXHMXPc0QpcAfLKnxAsdMRJS3RJCs /xHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066273; x=1789671073; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=32pR0m9lJbbl6oefWflQ2FM2YWt9ii7Ub9HEHMaojiA=; b=hGi7HXzkLZuNsReNiltvSGQbu5eCiP8RmUZh6mQPFbGwU63PWmWmpUJurwrWOdWGj+ S55eKzxAo3Lp79uwQVr8VPkMaISysGV8DuwghLdq71jgq0g1Wgjp1e7ApFpEEG3Rm5YT yWUuzxNlUcLL3u6JbE6k3sGPMwnzt58X6Zq8HOfXfEdaL6fQyl8eVGvVF9Ekas+Kgws3 0pZVxtxsWv11Oa5BHQN/LgDeC/FqN5Kw474nkQytDj4uSSTf5tJztWcYPFEOTK601ZLN SLL655hgz3aVLuV3V2TUasQ7sXYa8hkVeXY0ywbkAccsPOhpkhGIogThsvg1vyk0suw4 +y1g== X-Forwarded-Encrypted: i=1; AKwUvBzYkdbJ7tkyDkC0O19yN5SKLSNjBAG+f5j2fzue5tXr9COkWmqD9W8jY/KrWJY9qU66J6ULr/VJIUA=@lists.xenproject.org X-Gm-Message-State: AFuF++k+xU9P+v4vkW4oHRhyZFVDAaMcnxbAc9B6hEBcZff6yjH8lI1A xJSEJ8VpnITkAR9vun65CFac2drfdJb7LpuFc5+u9ADGW60fjy/NMfdJQtWiS26Mbu8= X-Gm-Gg: AYBFou0tkze9Gmwd9Bt7+qMEdHbnGZKE50+alExBvQg8gwvsWtEFvj9+siV8r6ugCEw 63OJEHdgqy9IaZXjsYYPUqzNwim/GaNA+wVm9Ayy0oRkOclCCj45yfP+Noyb0Bla3ry6QxnYGv6 inuZ/r1lpKNC84UF6fqcUVDMs2ZE+76c5spAjY7zUcv7HwvdmQ/Ie+5gnp/4zaDVwT5PCOsn4UY GRzzAPkVHQlQnK4gNuvU+uR77bkunp3fBhalXlcDVxsLfCajkUePle7b2aVh98pXX1irkz3C6wj 5bojXZC4iNZsRMamHedpXQ9ONe7uEQ5+0cklfhOXoze/wl3dK7sWrt77HDnULmaU4I49o4Ff77p RYsAX5GVMzJY8LRhKa3Aj44+dDOS+de8gliQ0nU4imFjog+LxmEP5uiDHVJxKznm7As421xMT7M 2T0UcVNiBAahB6ktYsKnY772W7vN9BnNXVm6ghKNlXZa6kqZnkN24Bvekg5RxMGfK5b4iSd6ltk 2rfR/HfE+ImC1SScl0znN9faSqjLtRmWAetp4WjvLqXtBeuQ7AYLNdj X-Received: by 2002:a67:e117:0:b0:790:f691:2d5b with SMTP id ada2fe7eead31-792a5b8b8a7mr1152469137.4.1789066272932; Thu, 10 Sep 2026 11:51:12 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:34 +0000 Subject: [PATCH RFC 11/13] samples: ftrace: Maintain Tasks RCU trampoline nesting in direct-call trampolines MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-11-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-42698a/1789066274-AA4DB9EA-9A047A62/0/0 X-purgate-type: clean X-purgate-size: 10813 Follow the register_ftrace_direct() contract in the sample modules: on x86-64 and arm64, have each hand-written trampoline increment current->rcu_tramp_nesting before calling its C handler and decrement it before returning, via a small shared samples/ftrace/ftrace-direct.h. %r11 and x12/w13 are used as scratch; both are caller-saved, non-argument registers and therefore dead on entry to and exit from an fentry trampoline. The header pulls in the generated asm-offsets.h only on those two architectures, since it is not generally safe to include from C (PPC32's TASK_SIZE and arm64's TRAMP_VALIAS clash with the C definitions; the latter is worked around locally with push_macro/pop_macro). Other architectures get empty macros and are unchanged. Assisted-by: LLM Signed-off-by: Josef Bacik --- samples/ftrace/ftrace-direct-modify.c | 9 ++++ samples/ftrace/ftrace-direct-multi-modify.c | 9 ++++ samples/ftrace/ftrace-direct-multi.c | 5 +++ samples/ftrace/ftrace-direct-too.c | 5 +++ samples/ftrace/ftrace-direct.c | 5 +++ samples/ftrace/ftrace-direct.h | 64 +++++++++++++++++++++++++++++ 6 files changed, 97 insertions(+) diff --git a/samples/ftrace/ftrace-direct-modify.c b/samples/ftrace/ftrace-direct-modify.c index 164d9dd6fd92..eb8230fa4242 100644 --- a/samples/ftrace/ftrace-direct-modify.c +++ b/samples/ftrace/ftrace-direct-modify.c @@ -2,6 +2,7 @@ #include #include #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -73,7 +74,9 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " call my_direct_func1\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp1, .-my_tramp1\n" @@ -85,7 +88,9 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " call my_direct_func2\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp2, .-my_tramp2\n" @@ -141,11 +146,13 @@ asm ( " .globl my_tramp1\n" " my_tramp1:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #16\n" " stp x9, x30, [sp]\n" " bl my_direct_func1\n" " ldp x30, x9, [sp]\n" " add sp, sp, #16\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp1, .-my_tramp1\n" @@ -153,11 +160,13 @@ asm ( " .globl my_tramp2\n" " my_tramp2:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #16\n" " stp x9, x30, [sp]\n" " bl my_direct_func2\n" " ldp x30, x9, [sp]\n" " add sp, sp, #16\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp2, .-my_tramp2\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-multi-modify.c b/samples/ftrace/ftrace-direct-multi-modify.c index b03766c6217b..c8f1062e5d1a 100644 --- a/samples/ftrace/ftrace-direct-multi-modify.c +++ b/samples/ftrace/ftrace-direct-multi-modify.c @@ -2,6 +2,7 @@ #include #include #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -77,10 +78,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func1\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp1, .-my_tramp1\n" @@ -92,10 +95,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func2\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp2, .-my_tramp2\n" @@ -154,6 +159,7 @@ asm ( " .globl my_tramp1\n" " my_tramp1:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -162,6 +168,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp1, .-my_tramp1\n" @@ -169,6 +176,7 @@ asm ( " .globl my_tramp2\n" " my_tramp2:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -177,6 +185,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp2, .-my_tramp2\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-multi.c b/samples/ftrace/ftrace-direct-multi.c index 3fe6ddaf0b69..bc6a88dd4ffc 100644 --- a/samples/ftrace/ftrace-direct-multi.c +++ b/samples/ftrace/ftrace-direct-multi.c @@ -3,6 +3,7 @@ #include /* for handle_mm_fault() */ #include +#include "ftrace-direct.h" #include #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include @@ -56,10 +57,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -101,6 +104,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -109,6 +113,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-too.c b/samples/ftrace/ftrace-direct-too.c index bf2411aa6fd7..247e418644a2 100644 --- a/samples/ftrace/ftrace-direct-too.c +++ b/samples/ftrace/ftrace-direct-too.c @@ -3,6 +3,7 @@ #include /* for handle_mm_fault() */ #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -61,6 +62,7 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " pushq %rsi\n" " pushq %rdx\n" @@ -70,6 +72,7 @@ asm ( " popq %rdx\n" " popq %rsi\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -110,6 +113,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #48\n" " stp x9, x30, [sp]\n" " stp x0, x1, [sp, #16]\n" @@ -119,6 +123,7 @@ asm ( " ldp x0, x1, [sp, #16]\n" " ldp x2, x3, [sp, #32]\n" " add sp, sp, #48\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct.c b/samples/ftrace/ftrace-direct.c index 5368c8c39cbb..9e1964baf28b 100644 --- a/samples/ftrace/ftrace-direct.c +++ b/samples/ftrace/ftrace-direct.c @@ -3,6 +3,7 @@ #include /* for wake_up_process() */ #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -54,9 +55,11 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " call my_direct_func\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -97,6 +100,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -104,6 +108,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct.h b/samples/ftrace/ftrace-direct.h new file mode 100644 index 000000000000..d0313f33f47f --- /dev/null +++ b/samples/ftrace/ftrace-direct.h @@ -0,0 +1,64 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef _SAMPLES_FTRACE_DIRECT_H +#define _SAMPLES_FTRACE_DIRECT_H + +#include + +/* + * A direct-call trampoline is entered with no lock, refcount or RCU marker + * held; only Tasks RCU keeps it (and, for a module, its text) alive while a + * task is inside it or preempted in something it called. On architectures + * that select ARCH_HAS_RCU_TASKS_PREEMPT_QS a preemption is a Tasks RCU + * quiescent state unless current->rcu_tramp_nesting is non-zero, so the + * trampoline must raise it before calling out and drop it afterwards, exactly + * like the ftrace and BPF trampolines do. See rcu_tasks_trampoline_enter() + * and register_ftrace_direct(). The instructions before the increment and + * after the decrement are covered by ftrace_direct_mark_module(). + * + * These expand to instruction strings for use inside the samples' asm() + * trampolines. The scratch register is caller-saved and not an argument + * register, so it is dead on entry to and exit from an fentry trampoline. + * + * The generated asm-offsets.h is only pulled in on the architectures that need + * it here: it is not generally safe to include from C (e.g. PPC32's TASK_SIZE + * and arm64's TRAMP_VALIAS clash with the C definitions), which is why the + * samples themselves guard their own include of it. + */ +#if defined(CONFIG_TASKS_RCU) && defined(CONFIG_X86_64) + +#include + +#define RCU_TASKS_TRAMP_ENTER \ + " movq %gs:current_task(%rip), %r11\n" \ + " incl " __stringify(TASK_rcu_tramp_nesting) "(%r11)\n" +#define RCU_TASKS_TRAMP_EXIT \ + " movq %gs:current_task(%rip), %r11\n" \ + " decl " __stringify(TASK_rcu_tramp_nesting) "(%r11)\n" + +#elif defined(CONFIG_TASKS_RCU) && defined(CONFIG_ARM64) + +/* arm64's asm-offsets.h redefines TRAMP_VALIAS from . */ +#pragma push_macro("TRAMP_VALIAS") +#undef TRAMP_VALIAS +#include +#pragma pop_macro("TRAMP_VALIAS") + +#define RCU_TASKS_TRAMP_ENTER \ + " mrs x12, sp_el0\n" \ + " ldr w13, [x12, #" __stringify(TSK_RCU_TRAMP_NESTING) "]\n" \ + " add w13, w13, #1\n" \ + " str w13, [x12, #" __stringify(TSK_RCU_TRAMP_NESTING) "]\n" +#define RCU_TASKS_TRAMP_EXIT \ + " mrs x12, sp_el0\n" \ + " ldr w13, [x12, #" __stringify(TSK_RCU_TRAMP_NESTING) "]\n" \ + " sub w13, w13, #1\n" \ + " str w13, [x12, #" __stringify(TSK_RCU_TRAMP_NESTING) "]\n" + +#else + +#define RCU_TASKS_TRAMP_ENTER +#define RCU_TASKS_TRAMP_EXIT + +#endif + +#endif /* _SAMPLES_FTRACE_DIRECT_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415172.1644741 (Exim 4.92) (envelope-from ) id 1x4jrj-0007i6-BA; Thu, 10 Sep 2026 18:51:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415172.1644741; Thu, 10 Sep 2026 18:51:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrj-0007gV-4m; Thu, 10 Sep 2026 18:51:19 +0000 Received: by outflank-mailman (input) for mailman id 1415172; Thu, 10 Sep 2026 18:51:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrh-0007L9-Dn for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrg-009F3X-QO for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:16 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fc22-8faa-0a2a0a5109dd-0a2a4509ce40-8 for ; Thu, 10 Sep 2026 20:51:16 +0200 Received: from [209.85.222.178] (helo=mail-qk1-f178.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc23-be1a-0a2a45090019-d155deb2e929-3 for ; Thu, 10 Sep 2026 20:51:16 +0200 Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-92edb12cdf2so541995785a.3 for ; Thu, 10 Sep 2026 11:51:16 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e7f184f5sm49053285a.15.2026.09.10.11.51.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:51:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066275; x=1789671075; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=twz7P/UgrzFqFrDTfXn+06wBF94/L3aT/pnjRwe1Smk=; b=a/W+E3oqSR9eqkKr341DAJy1tNKaFaQBR82chod6S1YlxphovVFLNAMXtqIvf8WOvK FSQk35n2Wzlxm/D9zLeEY5lh9DgKjyMKron8scWdp6Y9A0j5cmSKLM/kCLFxlDSxPM9D QsFSU4p3CqRtKttdxiELkDbyLUy1EOr/GUkP+1yVNbEsi/NjijRlusDHWgE8RkpC0OiH WaaSQqnngGs0jCAZfdPqHyobeQCRewa0U9ExLrcvbDDRFQa66LC2r610vdTP+AsYuCtf xQbTcKtHoGFlMFYQ/EYB4L4v5MDkmDj24cDaxLtQupeMabo+yPoCTlwZEOyOMVfSf4Pb 5PnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066275; x=1789671075; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=twz7P/UgrzFqFrDTfXn+06wBF94/L3aT/pnjRwe1Smk=; b=WXGKxb3Q6YNYI8yaewDqDgA4cfBiGDsxVNunbLywB8OL2h59szXIn02aO4GCwDPfq5 wqEZ4uNCg2jzBoJx6q3ZmliL4d8iy34KeBNMg/wRoTrKnFyxvqzVpEGVkvrwH5438hdq 8HJQN35hy/o+omZiqVGBL3qdZ4U8uIDG6eaL4j2b4gdcc2LiH8jwaavpJkHXNy2h1eDu vJcJoVKb5qT2igyvmcMHwdr9g2LHGNcz3tDlGCk85okgP2qQ+BlZ4XjA8CvYN7RC087e PkMKNr7M0BhjBlge0p1k9Od6NXv4tKWiSJyE78CzrGursprcNlv5OylekrfQzzr3icyy 2xlg== X-Forwarded-Encrypted: i=1; AKwUvBwt8s9YCby8blA7OeByO02KfwWKmF74UYLsZKaTfWTuKj79J8HYl5kVh/j5Ei3z1QxmOh/4svuOiZk=@lists.xenproject.org X-Gm-Message-State: AFuF++nIhZdcqnTU2jDCVgDUx6JqbvY/NfyPlEeMc69ehZxjWx0x1NAd AsCsq/KSc1DwHVubYl9YEvlAHYYU9i0JRv9HLVLsJj3alw5VthsD5pqnJdWrzIvZQG8= X-Gm-Gg: AYBFou0RWmVthrE8BKK2CB8KD6TfguQimw5kS0qUPLtegP4MWhS9oNTd8LumDYDkC5z mOojv4ZWReRZAisyYBUcsTnU2DtBiEGiXctRbwz9cRzKfFIrDiyrvD6MJgL0duMGFkEUpDujlRB hxey7RYcXSpAQ6Uv+uNlc1EpzGAVXd/grT0qM0zpdV2jWj3Ocgj4IHCNFV3wWllshbzDkYHm6pq OayUsGZSfogqz8I2ZYCnDpj44IFqMjhEw3BQUcMCYFTo/s3Dc3IyZ9NER8YYUhvotLVNLjbYtTQ gMNrNQ/qqLZKvu+eDBO38wc0mzyk04z0AdlvlIGv6h9Wo2RE0ZIFxFhBS2ATwyKi7ZVmr7q1XDG BvAt/z2qy2jACf0CPgrBKziYSYs8G8qfN7ehSQp8EVZrt2f/d4sQjBmUKxuvwsA0fRvoNKrsTxK HWP3fwNu3EZQ+/TVN0HlZdEc/Ct+cq4bqdRHMjzeVw2zdcoeYYYhq+2101pApcMcjtHGco1zrKE Hm27BqPM/lKR5zCUglIbdnPzGbmqBxMxzHmI23K0x/RMtf/FZY70sg/ X-Received: by 2002:a05:620a:269d:b0:939:6de9:208b with SMTP id af79cd13be357-939ea2b3827mr16779985a.48.1789066274997; Thu, 10 Sep 2026 11:51:14 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:35 +0000 Subject: [PATCH RFC 12/13] rcutorture: Bracket Tasks RCU readers with trampoline nesting MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-12-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-bad1c0/1789066276-FC817034-32A0BD17/0/0 X-purgate-type: clean X-purgate-size: 1494 rcutorture's tasks flavor models a Tasks RCU reader as "any stretch of kernel code", and rcu_read_delay() deliberately preempts inside it to check that a preemption does not end the read-side critical section. Once preemption outside a trampoline becomes a quiescent state that model no longer matches what Tasks RCU protects, and the readers would report false too-short grace periods. Have tasks_torture_read_lock()/unlock() raise and drop current->rcu_tramp_nesting so the reader models a trampoline, which is the thing Tasks RCU actually guards; the deliberate preemption inside it then continues to be, correctly, not a quiescent state. Assisted-by: LLM Signed-off-by: Josef Bacik --- kernel/rcu/rcutorture.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index 794937e13e7c..df6dd708cea7 100644 --- a/kernel/rcu/rcutorture.c +++ b/kernel/rcu/rcutorture.c @@ -1144,11 +1144,17 @@ static struct rcu_torture_ops trivial_preempt_ops = { static int tasks_torture_read_lock(void) { + /* + * Model a trampoline: with CONFIG_RCU_TASKS_PREEMPT_QS a preemption is + * otherwise a quiescent state and rcu_read_delay() preempts on purpose. + */ + rcu_tasks_trampoline_enter(); return 0; } static void tasks_torture_read_unlock(int idx) { + rcu_tasks_trampoline_exit(); } static void rcu_tasks_torture_deferred_free(struct rcu_torture *p) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 18:51:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 18:51:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415175.1644750 (Exim 4.92) (envelope-from ) id 1x4jrm-0008Fj-I8; Thu, 10 Sep 2026 18:51:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415175.1644750; Thu, 10 Sep 2026 18:51:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrm-0008FG-DG; Thu, 10 Sep 2026 18:51:22 +0000 Received: by outflank-mailman (input) for mailman id 1415175; Thu, 10 Sep 2026 18:51:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4jrk-0007tI-6l for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 18:51:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4jrj-00BfN4-K3 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:51:19 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2fc04-e002-0a2a0a5209dd-0a2a4507a3ac-48 for ; Thu, 10 Sep 2026 20:51:19 +0200 Received: from [209.85.222.171] (helo=mail-qk1-f171.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fc26-b4ea-0a2a45070019-d155deabed0b-3 for ; Thu, 10 Sep 2026 20:51:19 +0200 Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-9377f717879so14385a.1 for ; Thu, 10 Sep 2026 11:51:19 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e80f8142sm49848385a.43.2026.09.10.11.51.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 11:51:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789066278; x=1789671078; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=lBIdGtm0mo8q5590yjvGhNrcgQrhEpuiN5lFQ+hlgEA=; b=n70nH+yfFKCjVXMvhQx9IC0guXrh6b42XHu/VnPWPC/DwaNL+S4GVG945Var7cJq1T A1rISvERthLCOwTYQoccWBVof9gfUWEWT+T47NE151PRpuz7eIfZzfKZhWuBScjW+oIR 7JIPIbBdr0TpzYggSKMaNUmaTxLJy3uKmmQKWBOKpyOVmcQs7gb+EE/5o/cxoEsCz0Ob 3KvMVDG0U5fFBgcKPTyZFxTo1K5CeqEHtc6L5v1Qnpl1h8PrB7O7U4tGK5jas7WEqgX6 0PzS0lPDRsDzGM5Zr1QvSKLEzO+RBo+wxOtB/0eTKrRCFClp1TMZFxX+bN8uRceK/ZCx FtWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789066278; x=1789671078; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=lBIdGtm0mo8q5590yjvGhNrcgQrhEpuiN5lFQ+hlgEA=; b=S+jAaf9mhEZlACR1ak9hX7UWkXUFW0QjEz0AMWUMdk9C3C+IGbjUZ9Q5ZygldGQ8iK sJ86pH63GvkySavKRiFH17R+UrAxo/6OlTzmk5BYd0oqUmf+hRmsxbzmh/T5KZ1ttFTI B3I74inUNjNKeOKJ0DBU7ZgM/zgCGHemJOX2Djd0pA3UOBhdr4F02nLLljO5bxmURNLX D9muqzut70epzOo8NbMIVZKaxg8QUCskGOXFyoenLf6Q8Gmi6qRgTClEmQg27ePtUGpL DH09qfM9ZAdWxdfmqfgxYPhmWq4zmbeipy8JYJaryzzhCJovA8yN9CwJJaNn+hBK/vK0 Ankw== X-Forwarded-Encrypted: i=1; AKwUvByE8aUBdUXLw5fZZ2Q16TyO2EWc6+hbUdKylP4mpVdaPrhKcsslq/HV0lRy1QkCGSjmByb9+CIRk34=@lists.xenproject.org X-Gm-Message-State: AFuF++lEGdbRRPUAUtKQoa4FnBLfTWEZAkyfSKHNqU7rgHU9aJ4x9x1z s8FKPngDVGz7zQxS+f0DAc6UgNsB+GHDJzMsFd+xHNAVoGYkZSvtoqUP2Gw7+YaH9ss= X-Gm-Gg: AYBFou275ImTeqwBZ1FH67IRvTrz3uYnAFv2wxF0+FgvNW6kv9rZ2QYLqTnMhlXsvHE crWmeSviRzfUMectFFgKkCmvYC8q+PEJXIgWWGtew9bqHep7Tu3BvMiuk0HKRh1cDmDoRFWdge5 NOn3lU+9lMr3BzsdS8CFfkPt7wKYEq0otNpl98kxVNqa8WMS1W6/g2vgqm/9zTVF8x7NpRSJiAo 5daAQ6ngB1ufvkANoxPKfz/t5+VznfbjpXrdAE9E57z/A2m4YzXhKu4Ut72JZgqPLevBvvrtRh+ OmRz1DuOM9uA6dw5BA9EdWNfjr3MhNIheM2YhKTt/vC8l6KrkyuDT3+1zVTx5SwNA3JguXfvveM o8WLag2NElue0gGUi/q1EzlFYuOVcHu6qXUlQnTUXr59ZVsflog0ev7urhCitzvS7bQ0BywOFGn +QYrNYE5aeojMNNI9o9L0K4mI7KL2xk8DtyJO31MaZ7pGNYdUSribIM0AvFuXhuQqxoAaWWCNkW zvSDL9ty9SctQu75RGM98uioR/f9TWXrGSCMM9tjbGE9uD4Qb4gcO0k X-Received: by 2002:a05:620a:6a04:b0:937:4e12:5db6 with SMTP id af79cd13be357-939ea2a1e5dmr15410485a.43.1789066277808; Thu, 10 Sep 2026 11:51:17 -0700 (PDT) From: Josef Bacik Date: Thu, 10 Sep 2026 18:50:36 +0000 Subject: [PATCH RFC 13/13] rcu-tasks: Treat preemption outside trampolines as a quiescent state MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260910-b4-rcu-tasks-preempt-qs-v1-13-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-purgate-ID: tlsNG-ef75cf/1789066279-A46CAAE4-03B96413/0/0 X-purgate-type: clean X-purgate-size: 9398 Tasks RCU only accepts a voluntary context switch, usermode or idle as a quiescent state, because a task that was preempted may be sitting in a trampoline whose text is about to be freed. On PREEMPT_LAZY kernels, where cond_resched() is a no-op and CPU-bound kernel threads only ever lose the CPU through preemption, that means any long-running kthread or kworker stalls every synchronize_rcu_tasks() caller -- BPF and LSM program detach and DYNAMIC ftrace_ops teardown via ftrace_shutdown(), and kprobe (un)registration via the jump optimizer, which waits under kprobe_mutex, text_mutex and cpus_read_lock() -- for its entire run, unless someone sprinkles cond_resched_tasks_rcu_qs() into it. A cgroup writeback worker draining a large cgwb for eleven minutes was enough to back 40+ tasks up behind trampoline_mutex and trip the hung-task panic. With the previous patches, every Tasks-RCU-protected trampoline on x86-64 and arm64 (ftrace_caller and its dynamic copies, BPF trampoline images, the optprobe template, out-of-line direct trampolines) holds current->rcu_tramp_nesting across its call-out, and the irq-exit preemption path holds it across preempt_schedule_irq() whenever the interrupted IP is somewhere the counter cannot cover: trampoline entry/exit instructions and other dynamically allocated text, the static ftrace stubs and x86 return thunks on the way into a direct-call target, modules hosting their own direct trampolines, and the kprobe jump-optimization window. A task that is context-switched with the count at zero therefore cannot be inside, called from, or about to resume into anything Tasks RCU protects. So let rcu_tasks_classic_qs() clear the holdout flag on a preemption too when rcu_tramp_nesting is zero, on architectures that select ARCH_HAS_RCU_TASKS_PREEMPT_QS, and select it for x86-64 and for arm64 with DYNAMIC_FTRACE_WITH_ARGS. A running holdout is already poked via rcu_request_urgent_qs_task(), which makes the next tick set NEED_RESCHED; the resulting preemption -- from irq exit, or synchronously at the next preempt_enable() -- now retires it, so a Tasks RCU grace period is bounded by roughly a tick plus the longest preempt-disabled section instead of by the longest stretch without a voluntary schedule(). Other architectures keep the voluntary-only rule. Update the Tasks RCU documentation comments and the FORCE_TASKS_RCU help text to match. Cost: one load of current plus an inc/dec per trampoline entry and exit, and on irq-exit preemption one core_kernel_text() check plus, with OPTPROBES, MAX_OPTIMIZED_LENGTH-1 lockless kprobe hash lookups. Not covered: x86-32 and the other GENERIC_IRQ_ENTRY architectures, and return_to_handler / the rethook trampoline, whose C callees take the ftrace recursion lock before touching any ops. Tested under QEMU (x86-64, PREEMPT_LAZY, PREEMPT_RCU=n, PROVE_RCU, with and without PREEMPT_DYNAMIC) against a kthread spinning in-kernel for 30s with the function tracer, an ftrace kprobe, an optimized kprobe and fentry/fexit programs live: synchronize_rcu_tasks() 29.7s -> 0.1-0.3s, ftrace_shutdown() of a DYNAMIC ops 27s -> 0.2-0.8s, the ftrace-direct sample modules load/fire/unload in ~2.5s each during the spin, no warnings. arm64 is build-tested only. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/arm64/Kconfig | 1 + arch/x86/Kconfig | 1 + include/linux/rcupdate.h | 14 +++++++++++++- kernel/rcu/Kconfig | 7 ++++--- kernel/rcu/tasks.h | 15 +++++++++++---- 5 files changed, 30 insertions(+), 8 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b5a51b0ef944..0e6c1e0b236f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -44,6 +44,7 @@ config ARM64 select ARCH_HAS_PREEMPT_LAZY select ARCH_HAS_PTDUMP select ARCH_HAS_PTE_SPECIAL + select ARCH_HAS_RCU_TASKS_PREEMPT_QS if DYNAMIC_FTRACE_WITH_ARGS select ARCH_HAS_HW_PTE_YOUNG select ARCH_HAS_SETUP_DMA_OPS select ARCH_HAS_SET_DIRECT_MAP diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 15fd9ec5ecac..0a6427019345 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -99,6 +99,7 @@ config X86 select ARCH_HAS_PREEMPT_LAZY select ARCH_HAS_PTDUMP select ARCH_HAS_PTE_SPECIAL + select ARCH_HAS_RCU_TASKS_PREEMPT_QS if X86_64 select ARCH_HAS_HW_PTE_YOUNG select ARCH_HAS_NONLEAF_PMD_YOUNG if PGTABLE_LEVELS > 2 select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64 diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index e9afbbb1b061..356b1d6ef226 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -204,6 +204,11 @@ bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip); * non-trampoline user, kprobe jump optimization, which waits for tasks * preempted inside the instruction bytes it is about to overwrite. * + * With both in place, on architectures that select + * ARCH_HAS_RCU_TASKS_PREEMPT_QS, a preemption with rcu_tramp_nesting == 0 is + * a Tasks RCU quiescent state, and a CPU-bound kernel thread no longer needs + * to volunteer one via cond_resched_tasks_rcu_qs(). + * * Only current writes the count and only current (or an interrupt on the same * CPU) reads it, so plain accesses suffice. */ @@ -228,9 +233,16 @@ static __always_inline void rcu_tasks_trampoline_assert_none(void) bool rcu_tasks_ip_in_trampoline(unsigned long ip); +#ifdef CONFIG_RCU_TASKS_PREEMPT_QS +#define rcu_tasks_preempt_is_qs(t) (!READ_ONCE((t)->rcu_tramp_nesting)) +#else +#define rcu_tasks_preempt_is_qs(t) false +#endif + # define rcu_tasks_classic_qs(t, preempt) \ do { \ - if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ + if (READ_ONCE((t)->rcu_tasks_holdout) && \ + (!(preempt) || rcu_tasks_preempt_is_qs(t))) \ WRITE_ONCE((t)->rcu_tasks_holdout, false); \ } while (0) void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func); diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index 999f8228a13d..8e7c94329105 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -94,9 +94,10 @@ config FORCE_TASKS_RCU default n help This option force-enables a task-based RCU implementation - that uses only voluntary context switch (not preemption!), - idle, and user-mode execution as quiescent states. Not for - manual selection in most cases. + that uses only voluntary context switch (not preemption, unless + the architecture selects ARCH_HAS_RCU_TASKS_PREEMPT_QS and the + task is outside any trampoline), idle, and user-mode execution + as quiescent states. Not for manual selection in most cases. config NEED_TASKS_RCU bool diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index df68a330769a..78d2b78d3043 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -905,7 +905,10 @@ static void rcu_tasks_wait_gp(struct rcu_tasks *rtp) // // Simple variant of RCU whose quiescent states are voluntary context // switch, cond_resched_tasks_rcu_qs(), user-space execution, and idle. -// As such, grace periods can take one good long time. There are no +// With CONFIG_RCU_TASKS_PREEMPT_QS, a preemption taken while the task is +// not inside a trampoline (current->rcu_tramp_nesting == 0, see +// rcu_tasks_trampoline_enter()) is a quiescent state as well; without it, +// grace periods can take one good long time. There are no // read-side primitives similar to rcu_read_lock() and rcu_read_unlock() // because this implementation is intended to get the system into a safe // state for some of the manipulations involved in tracing and the like. @@ -1246,8 +1249,11 @@ static void tasks_rcu_exit_stall(struct timer_list *unused) * period elapses, in other words after all currently executing rcu-tasks * read-side critical sections have completed. call_rcu_tasks() assumes * that the read-side critical sections end at a voluntary context - * switch (not a preemption!), cond_resched_tasks_rcu_qs(), entry into idle, - * or transition to usermode execution. As such, there are no read-side + * switch, cond_resched_tasks_rcu_qs(), entry into idle, transition to + * usermode execution, or, with CONFIG_RCU_TASKS_PREEMPT_QS, a preemption + * taken outside any trampoline (current->rcu_tramp_nesting == 0, see + * rcu_tasks_trampoline_enter()); otherwise a preemption is not a + * quiescent state. As such, there are no read-side * primitives analogous to rcu_read_lock() and rcu_read_unlock() because * this primitive is intended to determine that all tasks have passed * through a safe state, not so much for data-structure synchronization. @@ -1269,7 +1275,8 @@ EXPORT_SYMBOL_GPL(call_rcu_tasks); * executing rcu-tasks read-side critical sections have elapsed. These * read-side critical sections are delimited by calls to schedule(), * cond_resched_tasks_rcu_qs(), idle execution, userspace execution, calls - * to synchronize_rcu_tasks(), and (in theory, anyway) cond_resched(). + * to synchronize_rcu_tasks(), (in theory, anyway) cond_resched(), and, + * with CONFIG_RCU_TASKS_PREEMPT_QS, preemption outside any trampoline. * * This is a very specialized primitive, intended only for a few uses in * tracing and other situations requiring manipulation of function -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 19:44:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 19:44:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415303.1644759 (Exim 4.92) (envelope-from ) id 1x4kgX-0006Yy-K3; Thu, 10 Sep 2026 19:43:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415303.1644759; Thu, 10 Sep 2026 19:43:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4kgX-0006Yr-GY; Thu, 10 Sep 2026 19:43:49 +0000 Received: by outflank-mailman (input) for mailman id 1415303; Thu, 10 Sep 2026 19:43:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4kgV-0006Yj-T8 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 19:43:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4kgU-006O7N-II for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 21:43:46 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3085e-8faa-0a2a0a5109dd-0a2a450becf2-8 for ; Thu, 10 Sep 2026 21:43:45 +0200 Received: from [216.40.44.12] (helo=relay.hostedemail.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa30870-b7e8-0a2a450b0019-d8282c0cceb3-3 for ; Thu, 10 Sep 2026 21:43:45 +0200 Received: from omf03.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 39693160690; Thu, 10 Sep 2026 19:43:40 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf03.hostedemail.com (Postfix) with ESMTPA id 30FD46000B; Thu, 10 Sep 2026 19:43:32 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim1 header.d=goodmis.org header.i="@goodmis.org" header.h="Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding" Date: Thu, 10 Sep 2026 15:44:50 -0400 From: Steven Rostedt To: Josef Bacik Cc: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC 00/13] rcu-tasks: let preemption outside trampolines be a quiescent state Message-ID: <20260910154450.7b770882@gandalf.local.home> In-Reply-To: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspamout05 X-Rspamd-Queue-Id: 30FD46000B X-Stat-Signature: q4rice5dx4toq6agt9e6os3uux3h5f5q X-Spam-Status: No, score=-4.97 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1/TvSOAPfmV5w9v9DlVemvWAF7fAQiQXhI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=goodmis.org; h=date:from:to:cc:subject:message-id:in-reply-to:references:mime-version:content-type:content-transfer-encoding; s=dkim1; bh=0G8Y9/xY0kMl88nV4+aK7L6N6EzC6UwclJFLiIWbzwM=; b=XDaxsPusoW6gsn6QQqwKwtOsezn5XGTPhAZBWTmLI2a3wTTy4g9M8GxTBfx7IxRyYNyRuYQGkIUa70KldFVZ7BxD/P2CsoJAlMMiCFX8YSS1drmpdXopT7vrVM/O17FPu1+y62DsM8b0wE++rILKnKFPiYk8n6rvTHLZaMP183M= X-HE-Tag: 1789069412-378097 X-HE-Meta: U2FsdGVkX1+2Ct3iQoLtuMkYa1cI50miBEnTqrhRYa+BXsr0BkuI+iyjkwhW+Ob8C5dT11n+jxKJvSyznZnLsxh0O/QKV9P9WQecOj/+21jACCNK26r6q8zwQqBN/ayZXuQ+GMG++J9Taw+/zJCowVnrggoyzv6dApRYuUizRVkjRykDXYfNTF0KQwLTeMZALOSsT8m10cqWJg1D25InukFaP+COzppk9X5R5JJAc9OQyO5V0RV7ia7UcNgjuOHSeTTxARbLsAo0lo+Cw5KvWdAoNn3RpyiQlWsoqM2E7xoqV45XznycLnrdwTWnybGDasUZEZxhn2u7O6k5MAY1bcSxESD/EVVf6gvruYYB/+VKBnRpc7lRNYR8i0iaqzQA X-purgate-ID: tlsNG-42698a/1789069425-A82F49EA-069F0036/0/0 X-purgate-type: clean X-purgate-size: 6841 On Thu, 10 Sep 2026 18:50:23 +0000 Josef Bacik wrote: > Tasks RCU only treats a voluntary context switch, usermode or idle as a > quiescent state, because a preempted task may be sitting in a trampoline > that is about to be freed. That was a fine trade when PREEMPT_NONE > servers compiled Tasks RCU away and PREEMPT desktops rarely ran > long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: > Tasks RCU is now real on server configs, and cond_resched() is a no-op, > so a CPU-bound kthread or kworker only ever loses the CPU by being > preempted, which is exactly the event Tasks RCU refuses to count. > > The way this showed up for us was a cgroup writeback worker draining a > very large cgwb for around eleven minutes on an arm64 box. Nothing wrong So you have a kernel thread running for 11 minutes without a schedule? You could still put in a cond_resched_tasks_rcu_qs() in that loop. But I guess you are trying to get rid of doing that too. > with that on its own, but a BPF program detach on another CPU went > bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() > while holding trampoline_mutex, forty-odd tasks piled up behind the > mutex, and the hung task detector panicked the machine. The kprobe jump > optimizer is worse in principle: it does synchronize_rcu_tasks() under > kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running > kthread can stall static key updates and CPU hotplug for its whole run. > The current answer is to find each such loop and add > cond_resched_tasks_rcu_qs() to it, which is the kind of annotation > PREEMPT_LAZY was supposed to let us stop writing. > > This series tries the other direction: have the trampolines say when a > task is inside them, so that a preemption anywhere else can be a > quiescent state. > > - task_struct grows an int, rcu_tramp_nesting. Every trampoline whose > lifetime Tasks RCU guards increments it before calling out and > decrements it before returning: ftrace_caller and its dynamic copies, > the BPF trampoline (which drops it again around the call to the > original function, since im->pcref covers that), the x86 optprobe > template, and out-of-line register_ftrace_direct() trampolines. Only > current writes it and nested users are balanced, so it is a plain > non-atomic inc/dec, one load of current plus one RMW per entry/exit. > > - The inc/dec are inside the trampoline, so there is a window of a few > instructions on each side where the count is zero but the task is in > (or on its way into) trampoline text. Nothing there can be preempted > synchronously, only from an interrupt, so the irq-exit preemption path > looks at regs->ip and holds the count across preempt_schedule_irq() > when the IP is somewhere the counter cannot cover: outside core and > module text (all the dynamically allocated trampolines and slots), in > the static ftrace stubs or the x86 return thunks that still hold a > direct-call target, in a module that hosts its own direct trampoline, > or inside the bytes after a kprobe that the jump optimizer may be > about to rewrite (the one synchronize_rcu_tasks() user that is not > about trampolines at all). So basically if the preemption happens outside of core or module text (which should be the case of any dynamically allocated trampoline), the task is marked to be in the grace period across its schedule, so that the RCU_TASK cannot move forward? > > - With those in place, rcu_tasks_classic_qs() also clears the holdout > flag on a preemption when the count is zero, on architectures that > opt in. x86-64 and arm64 do so here. Everyone else keeps the > voluntary-only rule and is untouched apart from the (unused) field. > > A running holdout already gets poked via rcu_request_urgent_qs_task(), > which makes the next tick set NEED_RESCHED, so with this the resulting > preemption retires it and a Tasks RCU grace period is bounded by roughly > a tick plus the longest preempt-off section rather than by the longest > stretch without a voluntary schedule(). > > Patches 1-12 are scaffolding and change no behaviour on their own; patch > 13 flips the rule and selects the option for the two architectures. > > Testing so far is QEMU only: x86-64, PREEMPT_LAZY with PREEMPT_RCU=n, > PROVE_RCU and lockdep, with and without PREEMPT_DYNAMIC. A kthread > spinning in-kernel for 30s with the function tracer, an ftrace kprobe, > an optimized kprobe and fentry/fexit programs attached: > synchronize_rcu_tasks() goes from 29.7s to 0.1-0.3s, tearing down a > DYNAMIC ftrace_ops (tracefs instance function -> nop) from 27s to > 0.2-0.8s, and the ftrace-direct sample modules load, fire and unload in > about 2.5s each while the spinner runs, with no warnings and the new > return-to-user assertion quiet. arm64 is build-tested only at this > point; real hardware numbers for both are the obvious next step and I > did not want to sit on the idea waiting for them. > > Things I would particularly like opinions on: > > - Whether hooking rcu_tasks_classic_qs() is the right place, or whether > Paul would rather see this expressed differently inside Tasks RCU. > - return_to_handler and the rethook/kretprobe trampolines are not > instrumented. Their C callees take the ftrace recursion lock before > touching any ops and the trampolines themselves are static text, so I > believe they do not need it, but I would like Steven and Masami to > confirm. Note, there has been some work in the past (and may happen again in the future) that will remove the preempt_disable() from the trace_recursion locking. If that happens, then I believe the trace_recursion would need to increment (and decrement) your counter. Probably need a comment there to let whomever know about it if they decide to remove the preempt_disable(). > - The register_ftrace_direct() contract change: out-of-line direct > trampolines now have to maintain the count themselves (the samples > are converted). I do not know of out-of-tree users beyond BPF, but > this is the one place an existing user could be silently weakened. > - Whether arm64 folks are comfortable with the ldr/add/str in > ftrace_caller and the BPF trampoline, and with treating all of > ftrace_caller as trampoline text for the IP check. > - If this holds up, cond_resched_tasks_rcu_qs() and > rcu_softirq_qs_periodic() become unnecessary on the opted-in > architectures; I have not touched them here. I don't know. It may work, but I have a feeling there's a devil in the details here that is waiting to bite us in the underside when we are not (RCU) watching. -- Steve From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:12:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:12:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415320.1644768 (Exim 4.92) (envelope-from ) id 1x4l8B-0004eY-MJ; Thu, 10 Sep 2026 20:12:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415320.1644768; Thu, 10 Sep 2026 20:12:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4l8B-0004eR-JZ; Thu, 10 Sep 2026 20:12:23 +0000 Received: by outflank-mailman (input) for mailman id 1415320; Thu, 10 Sep 2026 20:12:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4l89-0004eL-Ny for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:12:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4l88-00GmME-Uq for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:12:20 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa30f0b-bab6-0a2a0a5309dd-0a2a4505b7b2-18 for ; Thu, 10 Sep 2026 22:12:20 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa30f22-4cb1-0a2a45050019-aa0a857c8189-3 for ; Thu, 10 Sep 2026 22:12:19 +0200 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-90-lDK37aFsOmSoGhOGRUYthg-1; Thu, 10 Sep 2026 16:12:17 -0400 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-495474a5fbcso2069515e9.1 for ; Thu, 10 Sep 2026 13:12:17 -0700 (PDT) Received: from redhat.com (IGLD-80-230-79-236.inter.net.il. [80.230.79.236]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e62121747sm1798195e9.2.2026.09.10.13.12.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 13:12:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789071138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g9mLgS0ybrUUaTMFusFVuyMEvSQGJ2PNYaEiCYholds=; b=i653n/VOhca+FLMIKoLwfxg51OwIncc7/bzU6xsrjt+nYsZGMC0fSUDqUHnWq0hVbBe5H5 0Zgc9vEbYxIka9B1oQtiLCXWrCILG26DDc9POhh+9aRKpZwKHE42azm/fCBLCDEbrl4teT 4v42u+R3jcPXsYCNwI0T3jTjkpZfyak= X-MC-Unique: lDK37aFsOmSoGhOGRUYthg-1 X-Mimecast-MFC-AGG-ID: lDK37aFsOmSoGhOGRUYthg_1789071136 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789071136; x=1789675936; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=g9mLgS0ybrUUaTMFusFVuyMEvSQGJ2PNYaEiCYholds=; b=EgTwWcFhwcLrfwbcsHli876Tp8IRGXfUGLQlESnY+dJBvYwCxgI6QjXNgKB9lkHfh8 kA0eK8MNXTPo+avql/aVDSDhpf+czSlOPOhAdYD56cTu2YBgnqwt2m5fx4USe4KM+BC5 BP7beVYmYMnlZpXnAtsouYqYc261cmNtibkHAtHDUT8S0Q5PIRwVnLC3y4CCMBrky8bx p18q7gWgEw/exTXa6ML7cDKfdtiFwu76e6zrbCpbasE90PogW4QOjJqfUtH06osBriSy Ydv7kSWV43xnCVbQjmwj76589bpHCR0Fa1DqE0rxGQDNGcgq/2/bDDuDbcAug92yt8ll 86xA== X-Forwarded-Encrypted: i=1; AKwUvByN5lvjTjikgnQdU73YG7cQAqppbML8AZUu6/X3aIYg0NaG3NYAMuA8T/3nGUdOJr+362srs0MS8ic=@lists.xenproject.org X-Gm-Message-State: AFuF++lk8GAK3gU4YUEbSYXhcgZ4vfkbI/USovL03Ccuv95GZHXrwacl 5RfQQCRhSQX8thLIOZ/AoH3Uw2e4d7P54YbwhwtlB4E/JnTuH08viJW3xt+r0afIV/WEHrNnHhs uDAqsqW3ZPYRPwqch2uNd22LZ87ewha+jY1Y5AlI8qaY3VXRdthGq7MkyPIG524XxGtV3 X-Gm-Gg: AYBFou3bajYhATSk8Kp9x5LdzV3wegP5iNUun6NU44+CeU8p6qz6h+8AJQh8hYzOB9w ohm45eZwHfmdPwnazRPrzKcGBy4SoDg1lrkQlAZhp5THkLTQNM1aS4fzKBKc+xnMK6vM/uJl4tb 4D5UWE/uDOyHpWL/PH4OLSv79cpzA12r+vzxqh1LNYN7OkjDJcQrUls88SgdZoJH5OomXRAqMV9 oeToQmheVD1Qe45sL6Dg3ayVASuBhlhdNePuUDlExyfOBVhNdnKkS70TSHM8FkLr+mqbtHiMZfN ZUgNEnu+ZR9/zO2bcPcC6McBJSdZYV1TGF1r16L7uxfR+CG0G9QBGYEL2y8NZNSdLpGS90VG52s dypsHlsLbadbwULPsDBgy4DA= X-Received: by 2002:a05:600d:8498:10b0:49d:1842:f001 with SMTP id 5b1f17b1804b1-49e6198f7bamr5892335e9.14.1789071135745; Thu, 10 Sep 2026 13:12:15 -0700 (PDT) X-Received: by 2002:a05:600d:8498:10b0:49d:1842:f001 with SMTP id 5b1f17b1804b1-49e6198f7bamr5891645e9.14.1789071134907; Thu, 10 Sep 2026 13:12:14 -0700 (PDT) Date: Thu, 10 Sep 2026 16:12:11 -0400 From: "Michael S. Tsirkin" To: qemu-devel@nongnu.org Cc: Peter Maydell , Vladimir Sementsov-Ogievskiy , Ben Chaney , Markus Armbruster , Pierrick Bouvier , Sergio Lopez , Paolo Bonzini , Zhao Liu , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Bernhard Beschow , Conor Dooley , Sebastian Huber , Alistair Francis , Palmer Dabbelt , Jason Wang , Eric Blake , devel@lists.libvirt.org, xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org Subject: [PULL 21/90] net/tap: deprecate "no" as special value for script/downscript Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Mailer: git-send-email 2.51.2.2891.g4157995a80.dirty X-Mutt-Fcc: =sent X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: aw8ScHP_1bRBB_6QEQJQpPbPZoRVirTD24WSLuz3FB4_1789071136 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1789071140-71CA82A1-E5941498/0/0 X-purgate-type: clean X-purgate-size: 12712 From: Vladimir Sementsov-Ogievskiy The interface is ambiguous, as "no" is valid file name. So, using "no" as a special value to disable script is deprecated. Use an empty string ("script=" / "downscript=") instead. In a future version, "no" will be treated as a plain file name, just like any other non-empty value. Document the deprecation in docs/about/deprecated.rst, qapi/net.json, and qemu-options.hx. Update other docs to use empty string instead of "no". Add a warning. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Ben Chaney Reviewed-by: Markus Armbruster Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-ID: <20260819180201.1970193-4-vsementsov@yandex-team.ru> --- docs/about/deprecated.rst | 18 ++++++++++++++++++ docs/system/i386/microvm.rst | 4 ++-- docs/system/i386/xenpvh.rst | 2 +- docs/system/ppc/ppce500.rst | 4 ++-- docs/system/riscv/microchip-icicle-kit.rst | 2 +- docs/system/riscv/sifive_u.rst | 2 +- qapi/net.json | 14 ++++++++++---- net/tap.c | 17 +++++++++++------ qemu-options.hx | 8 ++++++-- 9 files changed, 52 insertions(+), 19 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 98c32991c9..61e775373d 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -71,6 +71,15 @@ flexible enough. The monitor objects have been converted to QOM, so ``-mon mode=control`` is replaced by ``-object monitor-qmp``. The short convenience options are not deprecated, only ``-mon``. +``script=no`` and ``downscript=no`` for ``-netdev tap`` (since 11.2) +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The special value ``"no"`` for the ``script`` and ``downscript`` +parameters of ``-netdev tap`` disables script execution. This special +treatment of ``"no"`` is deprecated. Use an empty string (``script=`` +or ``downscript=``) to disable script execution instead. In a future +version, ``"no"`` will be treated as a plain file name. + QEMU Machine Protocol (QMP) commands ------------------------------------ @@ -164,6 +173,15 @@ Use ``job-finalize`` instead. Use ``query-accelerators`` instead. +``"no"`` as value of ``script``/``downscript`` for tap in ``netdev_add`` (since 11.2) +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The special value ``"no"`` for the ``script`` and ``downscript`` +parameters of ``netdev_add`` with ``type=tap`` disables script +execution. This special treatment of ``"no"`` is deprecated. Use an +empty string instead. In a future version, ``"no"`` will be treated as +a plain file name. + Human Machine Protocol (HMP) commands ------------------------------------- diff --git a/docs/system/i386/microvm.rst b/docs/system/i386/microvm.rst index 1675e37d3e..077ea15751 100644 --- a/docs/system/i386/microvm.rst +++ b/docs/system/i386/microvm.rst @@ -79,7 +79,7 @@ legacy ``ISA serial`` device as console:: -serial stdio \ -drive id=test,file=test.img,format=raw,if=none \ -device virtio-blk-device,drive=test \ - -netdev tap,id=tap0,script=no,downscript=no \ + -netdev tap,id=tap0,script=,downscript= \ -device virtio-net-device,netdev=tap0 While the example above works, you might be interested in reducing the @@ -103,7 +103,7 @@ disabled:: -device virtconsole,chardev=virtiocon0 \ -drive id=test,file=test.img,format=raw,if=none \ -device virtio-blk-device,drive=test \ - -netdev tap,id=tap0,script=no,downscript=no \ + -netdev tap,id=tap0,script=,downscript= \ -device virtio-net-device,netdev=tap0 diff --git a/docs/system/i386/xenpvh.rst b/docs/system/i386/xenpvh.rst index 904778e3f5..862f38830b 100644 --- a/docs/system/i386/xenpvh.rst +++ b/docs/system/i386/xenpvh.rst @@ -42,7 +42,7 @@ case you need to construct one manually: -vnc none \ -display none \ -device virtio-net-pci,id=nic0,netdev=net0,mac=00:16:3e:5c:81:78 \ - -netdev type=tap,id=net0,ifname=vif3.0-emu,br=xenbr0,script=no,downscript=no \ + -netdev type=tap,id=net0,ifname=vif3.0-emu,br=xenbr0,script=,downscript= \ -smp 4,maxcpus=4 \ -nographic \ -machine xenpvh,ram-low-base=0,ram-low-size=2147483648,ram-high-base=4294967296,ram-high-size=2147483648,pci-ecam-base=824633720832,pci-ecam-size=268435456,pci-mmio-base=4026531840,pci-mmio-size=33554432,pci-mmio-high-base=824902156288,pci-mmio-high-size=68719476736 \ diff --git a/docs/system/ppc/ppce500.rst b/docs/system/ppc/ppce500.rst index c9fe0915dc..ec5aaf14fd 100644 --- a/docs/system/ppc/ppce500.rst +++ b/docs/system/ppc/ppce500.rst @@ -158,14 +158,14 @@ interface at PCI address 0.1.0, but we can switch that to an e1000 NIC by: $ qemu-system-ppc64 -M ppce500 -smp 4 -m 2G \ -display none -serial stdio \ -bios u-boot \ - -nic tap,ifname=tap0,script=no,downscript=no,model=e1000 + -nic tap,ifname=tap0,script=,downscript=,model=e1000 The QEMU ``ppce500`` machine can also dynamically instantiate an eTSEC device if “-device eTSEC” is given to QEMU: .. code-block:: bash - -netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device eTSEC,netdev=net0 + -netdev tap,ifname=tap0,script=,downscript=,id=net0 -device eTSEC,netdev=net0 Root file system on flash drive ------------------------------- diff --git a/docs/system/riscv/microchip-icicle-kit.rst b/docs/system/riscv/microchip-icicle-kit.rst index 9809e94b84..7fdb96601a 100644 --- a/docs/system/riscv/microchip-icicle-kit.rst +++ b/docs/system/riscv/microchip-icicle-kit.rst @@ -84,7 +84,7 @@ Then we can boot the machine by: $ qemu-system-riscv64 -M microchip-icicle-kit -smp 5 -m 2G \ -sd path/to/sdcard.img \ -nic user,model=cadence_gem \ - -nic tap,ifname=tap,model=cadence_gem,script=no \ + -nic tap,ifname=tap,model=cadence_gem,script= \ -display none -serial stdio \ -kernel path/to/u-boot/build/dir/u-boot.bin \ -dtb path/to/u-boot/build/dir/u-boot.dtb diff --git a/docs/system/riscv/sifive_u.rst b/docs/system/riscv/sifive_u.rst index 8f55ae8e31..0e4dcf3e70 100644 --- a/docs/system/riscv/sifive_u.rst +++ b/docs/system/riscv/sifive_u.rst @@ -199,7 +199,7 @@ To boot the VxWorks kernel in QEMU with the ``sifive_u`` machine, use: $ qemu-system-riscv64 -M sifive_u -smp 5 -m 2G \ -display none -serial stdio \ - -nic tap,ifname=tap0,script=no,downscript=no \ + -nic tap,ifname=tap0,script=,downscript= \ -kernel /path/to/vxWorks \ -append "gem(0,0)host:vxWorks h=192.168.200.1 e=192.168.200.2:ffffff00 u=target pw=vxTarget f=0x01" diff --git a/qapi/net.json b/qapi/net.json index ab8ed9c086..dccf95bbbc 100644 --- a/qapi/net.json +++ b/qapi/net.json @@ -399,15 +399,21 @@ # @fds: multiple file descriptors of already opened multiqueue capable # tap # -# @script: script to initialize the interface. An empty string or -# "no" disables script execution. Defaults to +# @script: script to initialize the interface. An empty string +# disables script execution. Defaults to # ``/qemu-ifup``, where ```` is the # system configuration directory at build time (typically /etc). +# Using "no" to disable script execution is deprecated (since +# 11.2); use an empty string instead. In a future version, "no" +# will be treated as a plain file name. # -# @downscript: script to shut down the interface. An empty string or -# "no" disables script execution. Defaults to +# @downscript: script to shut down the interface. An empty string +# disables script execution. Defaults to # ``/qemu-ifdown``, where ```` is the # system configuration directory at build time (typically /etc). +# Using "no" to disable script execution is deprecated (since +# 11.2); use an empty string instead. In a future version, "no" +# will be treated as a plain file name. # # @br: bridge name (since 2.8) # diff --git a/net/tap.c b/net/tap.c index 2076f5b780..f4051e8d4b 100644 --- a/net/tap.c +++ b/net/tap.c @@ -92,7 +92,8 @@ static void launch_script(const char *setup_script, const char *ifname, static void tap_send(void *opaque); static void tap_writable(void *opaque); -static bool tap_is_explicit_no_script(const char *script_arg_value) +static bool tap_is_explicit_no_script(const char *script_arg_name, + const char *script_arg_value) { if (!script_arg_value) { return false; @@ -103,16 +104,19 @@ static bool tap_is_explicit_no_script(const char *script_arg_value) } if (strcmp(script_arg_value, "no") == 0) { + warn_report("'%s=no' is deprecated; use '%s=' instead", + script_arg_name, script_arg_name); return true; } return false; } -static char *tap_parse_script(const char *script_arg_value, +static char *tap_parse_script(const char *script_arg_name, + const char *script_arg_value, const char *default_path) { - if (tap_is_explicit_no_script(script_arg_value)) { + if (tap_is_explicit_no_script(script_arg_name, script_arg_value)) { return NULL; } @@ -741,7 +745,7 @@ static bool net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer, qemu_set_info_str(&s->nc, "helper=%s", tap->helper); } else { qemu_set_info_str(&s->nc, "ifname=%s,script=%s,downscript=%s", ifname, - script ?: "no", downscript ?: "no"); + script ?: "", downscript ?: ""); if (downscript) { snprintf(s->down_script, sizeof(s->down_script), "%s", downscript); @@ -947,9 +951,10 @@ int net_init_tap(const Netdev *netdev, const char *name, } } else { g_autofree char *script = - tap_parse_script(tap->script, DEFAULT_NETWORK_SCRIPT); + tap_parse_script("script", tap->script, DEFAULT_NETWORK_SCRIPT); g_autofree char *downscript = - tap_parse_script(tap->downscript, DEFAULT_NETWORK_DOWN_SCRIPT); + tap_parse_script("downscript", tap->downscript, + DEFAULT_NETWORK_DOWN_SCRIPT); if (tap->ifname) { pstrcpy(ifname, sizeof ifname, tap->ifname); diff --git a/qemu-options.hx b/qemu-options.hx index 16ef7d5455..2f6863180b 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -3022,7 +3022,8 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, " use network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n" " to configure it and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n" " to deconfigure it\n" - " use '[down]script=no' or '[down]script=' to disable script execution\n" + " use '[down]script=' to disable script execution\n" + " ('[down]script=no' is deprecated and will be treated as a file name in future)\n" " use network helper 'helper' (default=" DEFAULT_BRIDGE_HELPER ") to\n" " configure it\n" " use 'fd=h' to connect to an already opened TAP interface\n" @@ -3561,7 +3562,10 @@ SRST ``/qemu-ifup`` and the default network deconfigure script is ``/qemu-ifdown``, where ```` is the system configuration directory at build time (typically ``/etc``). - Use ``[down]script=no`` or ``[down]script=`` to disable script execution. + Use ``[down]script=`` to disable script execution. + Using ``[down]script=no`` is deprecated; it disables script + execution now, but in a future version it will be treated as a + plain file name. If running QEMU as an unprivileged user, use the network helper to configure the TAP interface and attach it to the bridge. -- MST From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:15:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:15:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415329.1644777 (Exim 4.92) (envelope-from ) id 1x4lBN-0005EL-8H; Thu, 10 Sep 2026 20:15:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415329.1644777; Thu, 10 Sep 2026 20:15:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lBN-0005EE-4q; Thu, 10 Sep 2026 20:15:41 +0000 Received: by outflank-mailman (input) for mailman id 1415329; Thu, 10 Sep 2026 20:15:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lBL-0005E7-2u for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:15:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lBK-0077Pl-FH for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:15:38 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa30fc2-bab6-0a2a0a5309dd-0a2a4509d31e-14 for ; Thu, 10 Sep 2026 22:15:38 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa30fe8-be1a-0a2a45090019-aa0a857cbf0f-3 for ; Thu, 10 Sep 2026 22:15:37 +0200 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-66-MbfP3QVtP0mvqdAWzkTH3g-1; Thu, 10 Sep 2026 16:15:33 -0400 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-48437090e74so62084f8f.2 for ; Thu, 10 Sep 2026 13:15:33 -0700 (PDT) Received: from redhat.com (IGLD-80-230-79-236.inter.net.il. [80.230.79.236]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e62217965sm1215825e9.2.2026.09.10.13.15.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 13:15:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789071336; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wP5nj9MfiPsEKxjmqX6H5CG7YIoHYGFHlaBEBpbtyXc=; b=Zaaw0cJjGWeRGig9OMn4rVdgmPgzfXruLb7ueS6AsdRNDMJZOAkRJwFmCJAZdyEesw6oYf NIy8shGeoqzPaBHDA4ZZhipsHYXt849p+M94/G3gLM8+qbsOj3qXs8K0JmdXzA3C1D4gnX KfxabPDqkhP/IcORolueGV4LxbFeT3I= X-MC-Unique: MbfP3QVtP0mvqdAWzkTH3g-1 X-Mimecast-MFC-AGG-ID: MbfP3QVtP0mvqdAWzkTH3g_1789071332 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789071332; x=1789676132; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=wP5nj9MfiPsEKxjmqX6H5CG7YIoHYGFHlaBEBpbtyXc=; b=Ki/55c8tCZgvUBSDeVTldmU8G0zlleftvoRCmlgCIVEqc/aK56tTZSlayjgv/ZOZ+n GaFkdbrrR3D0dsY7NiG3nqsmIPntoxxrUy4/odSZGmtMJEzioXM2ZhavFSCfpSGZCaF/ buNMiQ0UZnqJ13qcfI1KQSxN0N5KE//eBCTx8O9uoGazg6Buarw9rf5yHOqOLcYg4uf4 OlaaeYB3J+2n1Pou+gBpFMyi2haO1qpAtZQ5ES8j2XoJoawxaTGBgKWWg0pwcKlzcmQJ YHle8h8tYNQ083OC0Bc1dHHLHBIBNZbsBNZeWHYhiTXdBYt3MannFWvTyTRCVFVsm1Wa fmHg== X-Forwarded-Encrypted: i=1; AKwUvBxiIdOHpx6+nwygV1IWdGyQnKHdSa9Ms5ZMI00uwueBGfh9Pa8i1sBIfSFkRMA5so9OlBCTBNYXENc=@lists.xenproject.org X-Gm-Message-State: AFuF++llCBnwhl15pAckx+edNAIxC1xEfc5sS0WfNylGMuMk/we4eHkp LyJD/bbcHr3fhAU+ST+B/J4Ut5Mb7Era7xBqTYQmOW4LhSCZo9jEap5Q6+ytuwPFXjDa51aTehS 0u2UmAvWRyOgWw8GvUgTNs9ABq+Z0yp6l4jInewnn1Hi/VYRA3zQG+UH+gmHfBpARSPVW X-Gm-Gg: AYBFou0tmy7DtErVbykDwqPNsA8H8c6kP6+4IcSgrCsr6mYR+R1zrXE7EP3/IbvmhyU 3BsROmTgU1BcBZEwOUbBYKcVdfj2/H/iAg0mXaHoqXRE1KSzan4qn7kE5qgmG4TYlpQRDb5iPhi 76jnpFmfcX6Bl8t1tei8gs30nq5wqm98YnbmqXE/O0RX4B3chDkV0LanH/QirVc4BftKq1XPMgi Q2JfD+lxJoHBF1Az79jW282W7YR6nBmyES4dBTORwZhzkeRlTv1UiV73wvJzGT5IcgcSWgl0o90 7RhfrWLXODV4rU+y7D3bhJ6x0OLiRAkTS+Flg1qFRrvaFHjcswWf2AxsEbwfck4CPy2EkUrp93J X7/J/vQL/MdtKyAT01SoioM4= X-Received: by 2002:a05:600d:444c:20b0:49b:96a0:5c00 with SMTP id 5b1f17b1804b1-49e6198d09bmr6064815e9.13.1789071330796; Thu, 10 Sep 2026 13:15:30 -0700 (PDT) X-Received: by 2002:a05:600d:444c:20b0:49b:96a0:5c00 with SMTP id 5b1f17b1804b1-49e6198d09bmr6064085e9.13.1789071329779; Thu, 10 Sep 2026 13:15:29 -0700 (PDT) Date: Thu, 10 Sep 2026 16:15:22 -0400 From: "Michael S. Tsirkin" To: qemu-devel@nongnu.org Cc: Peter Maydell , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Igor Mammedov , Ani Sinha , Aurelien Jarno , Laurent Vivier , Amit Shah , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Paolo Bonzini , Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= , Sergio Lopez , Richard Henderson , Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Jason Wang , Keith Busch , Klaus Jensen , Jesper Devantier , Bernhard Beschow , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , Elena Ufimtseva , Jagannathan Raman , Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , Halil Pasic , Christian Borntraeger , Eric Farman , Farhan Ali , Matthew Rosato , Cornelia Huck , Ilya Leoshkevich , David Hildenbrand , Fam Zheng , Dmitry Fleytman , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Zhao Liu , FangSheng Huang , qemu-arm@nongnu.org, qemu-block@nongnu.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org Subject: [PULL 80/90] hw/hotplug: Constify HotplugHandler Message-ID: <621ba41b05516e9d08e9593ce8689b7ec569491f.1789071043.git.mst@redhat.com> References: MIME-Version: 1.0 In-Reply-To: X-Mailer: git-send-email 2.51.2.2891.g4157995a80.dirty X-Mutt-Fcc: =sent X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: moTAKNc71FWIURw2-uFr09J51WruIIY30HAp5KFFTfU_1789071332 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1789071338-BF4D3394-79467E9F/0/0 X-purgate-type: clean X-purgate-size: 99091 From: Philippe Mathieu-Daudé HotplugHandler value returned from qdev_get_hotplug_handler() points to the handler of and object implementing the TYPE_HOTPLUG_HANDLER interface. That handler mostly points to read-only section which shouldn't not be updated. Better protect it with the const qualifier. Mechanical change using 'sed' then manually adapted coding style. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-ID: <20260903230245.65601-5-philmd@oss.qualcomm.com> --- hw/s390x/ccw-device.h | 2 +- include/hw/acpi/cpu.h | 4 +-- include/hw/acpi/cpu_hotplug.h | 2 +- include/hw/acpi/generic_event_device.h | 3 +- include/hw/acpi/ich9.h | 10 +++--- include/hw/acpi/memory_hotplug.h | 4 +-- include/hw/acpi/pcihp.h | 8 ++--- include/hw/core/boards.h | 4 +-- include/hw/core/hotplug.h | 13 +++---- include/hw/core/qdev.h | 12 +++---- include/hw/i386/microvm.h | 4 +-- include/hw/i386/x86.h | 10 +++--- include/hw/mem/nvdimm.h | 2 +- include/hw/pci/pci_bridge.h | 6 ++-- include/hw/pci/pcie.h | 8 ++--- include/hw/pci/shpc.h | 6 ++-- include/hw/ppc/spapr_nvdimm.h | 2 +- hw/acpi/acpi-cpu-hotplug-stub.c | 4 +-- hw/acpi/acpi-mem-hotplug-stub.c | 4 +-- hw/acpi/acpi-nvdimm-stub.c | 2 +- hw/acpi/acpi-pci-hotplug-stub.c | 8 ++--- hw/acpi/cpu.c | 6 ++-- hw/acpi/generic_event_device.c | 11 +++--- hw/acpi/ich9.c | 10 +++--- hw/acpi/memory_hotplug.c | 6 ++-- hw/acpi/nvdimm.c | 2 +- hw/acpi/pcihp.c | 10 +++--- hw/acpi/piix4.c | 12 +++---- hw/arm/virt.c | 23 ++++++------ hw/char/virtio-serial-bus.c | 2 +- hw/core/hotplug.c | 8 ++--- hw/core/qdev-hotplug.c | 10 +++--- hw/core/qdev.c | 2 +- hw/i386/microvm.c | 12 +++---- hw/i386/pc.c | 28 +++++++-------- hw/i386/x86-common.c | 8 ++--- hw/intc/loongarch_dintc.c | 8 ++--- hw/intc/loongarch_extioi_common.c | 4 +-- hw/intc/loongarch_ipi.c | 4 +-- hw/loongarch/virt.c | 44 +++++++++++------------ hw/net/virtio-net.c | 4 +-- hw/nvme/ctrl.c | 8 ++--- hw/pci-bridge/pci_bridge_dev.c | 6 ++-- hw/pci/pcie.c | 10 +++--- hw/pci/pcie_port.c | 2 +- hw/pci/shpc.c | 10 +++--- hw/ppc/e500plat.c | 4 +-- hw/ppc/spapr.c | 48 +++++++++++++------------- hw/ppc/spapr_nvdimm.c | 2 +- hw/ppc/spapr_pci.c | 12 +++---- hw/remote/machine.c | 2 +- hw/riscv/virt.c | 6 ++-- hw/s390x/css-bridge.c | 2 +- hw/s390x/s390-pci-bus.c | 12 +++---- hw/s390x/s390-virtio-ccw.c | 16 ++++----- hw/s390x/virtio-ccw-md.c | 8 ++--- hw/s390x/virtio-ccw.c | 2 +- hw/scsi/virtio-scsi.c | 6 ++-- hw/scsi/vmw_pvscsi.c | 4 +-- hw/virtio/virtio-md-pci.c | 8 ++--- hw/xen/xen-bus.c | 2 +- stubs/hotplug-stubs.c | 6 ++-- system/qdev-monitor.c | 2 +- 63 files changed, 257 insertions(+), 253 deletions(-) diff --git a/hw/s390x/ccw-device.h b/hw/s390x/ccw-device.h index 15f64cfb63..c303f1de42 100644 --- a/hw/s390x/ccw-device.h +++ b/hw/s390x/ccw-device.h @@ -37,7 +37,7 @@ extern const VMStateDescription vmstate_ccw_dev; struct CCWDeviceClass { DeviceClass parent_class; - void (*unplug)(HotplugHandler *, DeviceState *, Error **); + void (*unplug)(const HotplugHandler *, DeviceState *, Error **); bool (*realize)(CcwDevice *, Error **); void (*refill_ids)(CcwDevice *); }; diff --git a/include/hw/acpi/cpu.h b/include/hw/acpi/cpu.h index 04c821d2b9..3664ac7a52 100644 --- a/include/hw/acpi/cpu.h +++ b/include/hw/acpi/cpu.h @@ -39,10 +39,10 @@ typedef struct CPUHotplugState { AcpiCpuStatus *devs; } CPUHotplugState; -void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_plug_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp); -void acpi_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp); diff --git a/include/hw/acpi/cpu_hotplug.h b/include/hw/acpi/cpu_hotplug.h index 5b670b04eb..bac40ccfa0 100644 --- a/include/hw/acpi/cpu_hotplug.h +++ b/include/hw/acpi/cpu_hotplug.h @@ -25,7 +25,7 @@ typedef struct AcpiCpuHotplug { uint8_t sts[ACPI_GPE_PROC_LEN]; } AcpiCpuHotplug; -void legacy_acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, +void legacy_acpi_cpu_plug_cb(const HotplugHandler *hotplug_dev, AcpiCpuHotplug *g, DeviceState *dev, Error **errp); void legacy_acpi_cpu_hotplug_init(MemoryRegion *parent, Object *owner, diff --git a/include/hw/acpi/generic_event_device.h b/include/hw/acpi/generic_event_device.h index 7cbfb5fe7d..42a8033a23 100644 --- a/include/hw/acpi/generic_event_device.h +++ b/include/hw/acpi/generic_event_device.h @@ -136,7 +136,8 @@ typedef struct AcpiGedClass { ResettablePhases parent_phases; } AcpiGedClass; -void build_ged_aml(Aml *table, const char* name, HotplugHandler *hotplug_dev, +void build_ged_aml(Aml *table, const char *name, + const HotplugHandler *hotplug_dev, uint32_t ged_irq, AmlRegionSpace rs, hwaddr ged_base); void acpi_dsdt_add_power_button(Aml *scope); diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h index 6d14544751..6956b2b9c9 100644 --- a/include/hw/acpi/ich9.h +++ b/include/hw/acpi/ich9.h @@ -85,15 +85,15 @@ void ich9_pm_reset_properties(ICH9LPCPMRegs *pm); void ich9_pm_add_class_properties(ObjectClass *oc, ptrdiff_t pm_offset); -void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void ich9_pm_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void ich9_pm_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -bool ich9_pm_is_hotpluggable_bus(HotplugHandler *hotplug_dev, BusState *bus); +bool ich9_pm_is_hotpluggable_bus(const HotplugHandler *hotplug_dev, BusState *bus); void ich9_pm_ospm_status(AcpiDeviceIf *adev, ACPIOSTInfoList ***list); #endif /* HW_ACPI_ICH9_H */ diff --git a/include/hw/acpi/memory_hotplug.h b/include/hw/acpi/memory_hotplug.h index eb7f460afe..6e4f82bcf9 100644 --- a/include/hw/acpi/memory_hotplug.h +++ b/include/hw/acpi/memory_hotplug.h @@ -36,9 +36,9 @@ typedef struct MemHotplugState { void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner, MemHotplugState *state, hwaddr io_base); -void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, +void acpi_memory_plug_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp); -void acpi_memory_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_memory_unplug_request_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp); void acpi_memory_unplug_cb(MemHotplugState *mem_st, diff --git a/include/hw/acpi/pcihp.h b/include/hw/acpi/pcihp.h index efce5fd2e1..21c0b72355 100644 --- a/include/hw/acpi/pcihp.h +++ b/include/hw/acpi/pcihp.h @@ -66,13 +66,13 @@ void acpi_pcihp_init(Object *owner, AcpiPciHpState *, MemoryRegion *io, uint16_t io_base); bool acpi_pcihp_is_hotpluggable_bus(AcpiPciHpState *s, BusState *bus); -void acpi_pcihp_device_pre_plug_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_plug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp); -void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_unplug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp); -void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_unplug_request_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp); diff --git a/include/hw/core/boards.h b/include/hw/core/boards.h index a436d48c8e..dba465efc2 100644 --- a/include/hw/core/boards.h +++ b/include/hw/core/boards.h @@ -322,8 +322,8 @@ struct MachineClass { SMPCompatProps smp_props; const char *default_ram_id; - HotplugHandler *(*get_hotplug_handler)(MachineState *machine, - DeviceState *dev); + const HotplugHandler *(*get_hotplug_handler)(MachineState *machine, + DeviceState *dev); bool (*hotplug_allowed)(MachineState *state, DeviceState *dev, Error **errp); CpuInstanceProperties (*cpu_index_to_instance_props)(MachineState *machine, diff --git a/include/hw/core/hotplug.h b/include/hw/core/hotplug.h index a9840ed485..0c69be60ee 100644 --- a/include/hw/core/hotplug.h +++ b/include/hw/core/hotplug.h @@ -30,7 +30,7 @@ typedef struct HotplugHandler HotplugHandler; * @plugged_dev: a device that has been (un)plugged * @errp: returns an error if this function fails */ -typedef void (*hotplug_fn)(HotplugHandler *plug_handler, +typedef void (*hotplug_fn)(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); /** @@ -59,7 +59,8 @@ struct HotplugHandlerClass { hotplug_fn plug; hotplug_fn unplug_request; hotplug_fn unplug; - bool (*is_hotpluggable_bus)(HotplugHandler *plug_handler, BusState *bus); + bool (*is_hotpluggable_bus)(const HotplugHandler *plug_handler, + BusState *bus); }; /** @@ -67,7 +68,7 @@ struct HotplugHandlerClass { * * Call #HotplugHandlerClass.plug callback of @plug_handler. */ -void hotplug_handler_plug(HotplugHandler *plug_handler, +void hotplug_handler_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); @@ -76,7 +77,7 @@ void hotplug_handler_plug(HotplugHandler *plug_handler, * * Call #HotplugHandlerClass.pre_plug callback of @plug_handler. */ -void hotplug_handler_pre_plug(HotplugHandler *plug_handler, +void hotplug_handler_pre_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); @@ -85,7 +86,7 @@ void hotplug_handler_pre_plug(HotplugHandler *plug_handler, * * Calls #HotplugHandlerClass.unplug_request callback of @plug_handler. */ -void hotplug_handler_unplug_request(HotplugHandler *plug_handler, +void hotplug_handler_unplug_request(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); /** @@ -93,7 +94,7 @@ void hotplug_handler_unplug_request(HotplugHandler *plug_handler, * * Calls #HotplugHandlerClass.unplug callback of @plug_handler. */ -void hotplug_handler_unplug(HotplugHandler *plug_handler, +void hotplug_handler_unplug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); #endif diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h index e4cb027ab3..1f6bf3fc1a 100644 --- a/include/hw/core/qdev.h +++ b/include/hw/core/qdev.h @@ -386,7 +386,7 @@ struct BusState { /* public: */ DeviceState *parent; char *name; - HotplugHandler *hotplug_handler; + const HotplugHandler *hotplug_handler; int max_index; bool realized; bool full; @@ -514,8 +514,8 @@ bool qdev_realize_and_unref(DeviceState *dev, BusState *bus, Error **errp); void qdev_unrealize(DeviceState *dev); void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id, int required_for_version); -HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev); -HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev); +const HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev); +const HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev); bool qdev_hotplug_allowed(DeviceState *dev, BusState *bus, Error **errp); bool qdev_hotunplug_allowed(DeviceState *dev, Error **errp); @@ -529,10 +529,10 @@ bool qdev_hotunplug_allowed(DeviceState *dev, Error **errp); * Return: pointer to object that implements TYPE_HOTPLUG_HANDLER interface * or NULL if there aren't any. */ -HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev); +const HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev); void qdev_unplug(DeviceState *dev, Error **errp); int qdev_sync_config(DeviceState *dev, Error **errp); -void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev, +void qdev_simple_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); void qdev_machine_creation_done(void); bool qdev_machine_modified(void); @@ -1065,7 +1065,7 @@ void qbus_set_bus_hotplug_handler(BusState *bus); static inline bool qbus_is_hotpluggable(BusState *bus) { - HotplugHandler *plug_handler = bus->hotplug_handler; + const HotplugHandler *plug_handler = bus->hotplug_handler; bool ret = !!plug_handler; if (plug_handler) { diff --git a/include/hw/i386/microvm.h b/include/hw/i386/microvm.h index 184b7a8c09..5d5eacd1c6 100644 --- a/include/hw/i386/microvm.h +++ b/include/hw/i386/microvm.h @@ -76,8 +76,8 @@ struct MicrovmMachineClass { X86MachineClass parent; - HotplugHandler *(*orig_hotplug_handler)(MachineState *machine, - DeviceState *dev); + const HotplugHandler *(*orig_hotplug_handler)(MachineState *machine, + DeviceState *dev); void (*x86_load_linux)(X86MachineState *x86ms, FWCfgState *fw_cfg, int acpi_data_size); }; diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h index 71fe6b5e12..abb073ca47 100644 --- a/include/hw/i386/x86.h +++ b/include/hw/i386/x86.h @@ -46,7 +46,7 @@ struct X86MachineState { qemu_irq *gsi; DeviceState *ioapic2; GMappedFile *initrd_mapped_file; - HotplugHandler *acpi_dev; + const HotplugHandler *acpi_dev; /* * Map the whole BIOS just underneath the 4 GiB address boundary. Only used @@ -112,13 +112,13 @@ uint32_t x86_cpu_apic_id_from_index(X86MachineState *x86ms, void x86_cpus_init(X86MachineState *pcms, int default_cpu_version); void x86_rtc_set_cpus_count(ISADevice *rtc, uint16_t cpus_count); -void x86_cpu_pre_plug(HotplugHandler *hotplug_dev, +void x86_cpu_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void x86_cpu_plug(HotplugHandler *hotplug_dev, +void x86_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void x86_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev, +void x86_cpu_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); void x86_isa_bios_init(MemoryRegion *isa_bios, MemoryRegion *isa_memory, diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h index d3b763453a..169a943e3c 100644 --- a/include/hw/mem/nvdimm.h +++ b/include/hw/mem/nvdimm.h @@ -157,5 +157,5 @@ void nvdimm_build_acpi(GArray *table_offsets, GArray *table_data, uint32_t ram_slots, const char *oem_id, const char *oem_table_id); void nvdimm_plug(NVDIMMState *state); -void nvdimm_acpi_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev); +void nvdimm_acpi_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev); #endif diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h index b61360b900..f114f0a651 100644 --- a/include/hw/pci/pci_bridge.h +++ b/include/hw/pci/pci_bridge.h @@ -141,11 +141,11 @@ void pci_bridge_reset(DeviceState *qdev); void pci_bridge_initfn(PCIDevice *pci_dev, const char *typename); void pci_bridge_exitfn(PCIDevice *pci_dev); -void pci_bridge_dev_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pci_bridge_dev_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pci_bridge_dev_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pci_bridge_dev_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pci_bridge_dev_unplug_request_cb(HotplugHandler *hotplug_dev, +void pci_bridge_dev_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); /* diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h index 71ba94874b..ec25e7a7de 100644 --- a/include/hw/pci/pcie.h +++ b/include/hw/pci/pcie.h @@ -146,13 +146,13 @@ void pcie_ats_init(PCIDevice *dev, uint16_t offset, bool aligned); void pcie_cap_fill_link_ep_usp(PCIDevice *dev, PCIExpLinkWidth width, PCIExpLinkSpeed speed, bool flitmode); -void pcie_cap_slot_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pcie_cap_slot_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pcie_cap_slot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_dev, +void pcie_cap_slot_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); void pcie_pasid_common_init(PCIDevice *dev, uint16_t offset, diff --git a/include/hw/pci/shpc.h b/include/hw/pci/shpc.h index fce5bdd3bc..67becb5c56 100644 --- a/include/hw/pci/shpc.h +++ b/include/hw/pci/shpc.h @@ -45,11 +45,11 @@ void shpc_free(PCIDevice *dev); void shpc_cap_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int len); -void shpc_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void shpc_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void shpc_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void shpc_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void shpc_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void shpc_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); extern const VMStateInfo shpc_vmstate_info; diff --git a/include/hw/ppc/spapr_nvdimm.h b/include/hw/ppc/spapr_nvdimm.h index e9436cb6ef..386da92042 100644 --- a/include/hw/ppc/spapr_nvdimm.h +++ b/include/hw/ppc/spapr_nvdimm.h @@ -18,7 +18,7 @@ typedef struct SpaprMachineState SpaprMachineState; int spapr_pmem_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr, void *fdt, int *fdt_start_offset, Error **errp); void spapr_dt_persistent_memory(SpaprMachineState *spapr, void *fdt); -bool spapr_nvdimm_validate(HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm, +bool spapr_nvdimm_validate(const HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm, uint64_t size, Error **errp); void spapr_add_nvdimm(DeviceState *dev, uint64_t slot); void spapr_nvdimm_finish_flushes(void); diff --git a/hw/acpi/acpi-cpu-hotplug-stub.c b/hw/acpi/acpi-cpu-hotplug-stub.c index 72c5f05f5c..2e05d7100b 100644 --- a/hw/acpi/acpi-cpu-hotplug-stub.c +++ b/hw/acpi/acpi-cpu-hotplug-stub.c @@ -14,7 +14,7 @@ void acpi_cpu_ospm_status(CPUHotplugState *cpu_st, ACPIOSTInfoList ***list) { } -void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_plug_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp) { } @@ -24,7 +24,7 @@ void acpi_cpu_unplug_cb(CPUHotplugState *cpu_st, { } -void acpi_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/acpi-mem-hotplug-stub.c b/hw/acpi/acpi-mem-hotplug-stub.c index 7ad0fdcdf2..c218813fd1 100644 --- a/hw/acpi/acpi-mem-hotplug-stub.c +++ b/hw/acpi/acpi-mem-hotplug-stub.c @@ -13,7 +13,7 @@ void acpi_memory_ospm_status(MemHotplugState *mem_st, ACPIOSTInfoList ***list) { } -void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, +void acpi_memory_plug_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp) { } @@ -23,7 +23,7 @@ void acpi_memory_unplug_cb(MemHotplugState *mem_st, { } -void acpi_memory_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_memory_unplug_request_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/acpi-nvdimm-stub.c b/hw/acpi/acpi-nvdimm-stub.c index 22ba17f511..0120bacaac 100644 --- a/hw/acpi/acpi-nvdimm-stub.c +++ b/hw/acpi/acpi-nvdimm-stub.c @@ -2,6 +2,6 @@ #include "hw/mem/nvdimm.h" #include "hw/core/hotplug.h" -void nvdimm_acpi_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev) +void nvdimm_acpi_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev) { } diff --git a/hw/acpi/acpi-pci-hotplug-stub.c b/hw/acpi/acpi-pci-hotplug-stub.c index d58ea726a8..20625c7ed7 100644 --- a/hw/acpi/acpi-pci-hotplug-stub.c +++ b/hw/acpi/acpi-pci-hotplug-stub.c @@ -9,22 +9,22 @@ void acpi_pcihp_init(Object *owner, AcpiPciHpState *s, { } -void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_plug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { } -void acpi_pcihp_device_pre_plug_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { } -void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_unplug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { } -void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_unplug_request_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c index d63ca83c1b..ef97ed779a 100644 --- a/hw/acpi/cpu.c +++ b/hw/acpi/cpu.c @@ -132,7 +132,7 @@ static void cpu_hotplug_wr(void *opaque, hwaddr addr, uint64_t data, trace_cpuhp_acpi_clear_remove_evt(cpu_st->selector); } else if (data & 8) { DeviceState *dev = NULL; - HotplugHandler *hotplug_ctrl = NULL; + const HotplugHandler *hotplug_ctrl; if (!cdev->cpu || cdev->cpu == first_cpu) { trace_cpuhp_acpi_ejecting_invalid_cpu(cpu_st->selector); @@ -247,7 +247,7 @@ static AcpiCpuStatus *get_cpu_status(CPUHotplugState *cpu_st, DeviceState *dev) return NULL; } -void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_plug_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp) { AcpiCpuStatus *cdev; @@ -264,7 +264,7 @@ void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, } } -void acpi_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c index 5225e32513..65a5d1612f 100644 --- a/hw/acpi/generic_event_device.c +++ b/hw/acpi/generic_event_device.c @@ -45,7 +45,8 @@ static const uint32_t ged_supported_events[] = { * affected by the interrupt. This way, we can support up to 32 events * with a unique interrupt. */ -void build_ged_aml(Aml *table, const char *name, HotplugHandler *hotplug_dev, +void build_ged_aml(Aml *table, const char *name, + const HotplugHandler *hotplug_dev, uint32_t ged_irq, AmlRegionSpace rs, hwaddr ged_base) { const AcpiGedState *s = ACPI_GED(hotplug_dev); @@ -250,7 +251,7 @@ static const MemoryRegionOps ged_regs_ops = { }, }; -static void acpi_ged_device_pre_plug_cb(HotplugHandler *hotplug_dev, +static void acpi_ged_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { @@ -258,7 +259,7 @@ static void acpi_ged_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -static void acpi_ged_device_plug_cb(HotplugHandler *hotplug_dev, +static void acpi_ged_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { AcpiGedState *s = ACPI_GED(hotplug_dev); @@ -279,7 +280,7 @@ static void acpi_ged_device_plug_cb(HotplugHandler *hotplug_dev, } } -static void acpi_ged_unplug_request_cb(HotplugHandler *hotplug_dev, +static void acpi_ged_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { AcpiGedState *s = ACPI_GED(hotplug_dev); @@ -298,7 +299,7 @@ static void acpi_ged_unplug_request_cb(HotplugHandler *hotplug_dev, } } -static void acpi_ged_unplug_cb(HotplugHandler *hotplug_dev, +static void acpi_ged_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { AcpiGedState *s = ACPI_GED(hotplug_dev); diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c index 8082eae428..6d421b990c 100644 --- a/hw/acpi/ich9.c +++ b/hw/acpi/ich9.c @@ -410,7 +410,7 @@ void ich9_pm_add_class_properties(ObjectClass *oc, ptrdiff_t pm_offset) #undef PM_REG_FIELD -void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); @@ -432,7 +432,7 @@ void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, } } -void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); @@ -455,7 +455,7 @@ void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, } } -void ich9_pm_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void ich9_pm_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); @@ -489,7 +489,7 @@ void ich9_pm_device_unplug_request_cb(HotplugHandler *hotplug_dev, } } -void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); @@ -507,7 +507,7 @@ void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, } } -bool ich9_pm_is_hotpluggable_bus(HotplugHandler *hotplug_dev, BusState *bus) +bool ich9_pm_is_hotpluggable_bus(const HotplugHandler *hotplug_dev, BusState *bus) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); return acpi_pcihp_is_hotpluggable_bus(&lpc->pm.acpi_pci_hotplug, bus); diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c index f482c835a1..b5b6d6ada6 100644 --- a/hw/acpi/memory_hotplug.c +++ b/hw/acpi/memory_hotplug.c @@ -166,7 +166,7 @@ static void acpi_memory_hotplug_write(void *opaque, hwaddr addr, uint64_t data, mdev->is_removing = false; trace_mhp_acpi_clear_remove_evt(mem_st->selector); } else if (data & 8) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; if (!mdev->is_enabled) { trace_mhp_acpi_ejecting_invalid_slot(mem_st->selector); @@ -254,7 +254,7 @@ acpi_memory_slot_status(MemHotplugState *mem_st, return &mem_st->devs[slot]; } -void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, +void acpi_memory_plug_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp) { MemStatus *mdev; @@ -277,7 +277,7 @@ void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, } } -void acpi_memory_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_memory_unplug_request_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c index 703e854951..5a7ff1ede8 100644 --- a/hw/acpi/nvdimm.c +++ b/hw/acpi/nvdimm.c @@ -887,7 +887,7 @@ static const MemoryRegionOps nvdimm_dsm_ops = { }, }; -void nvdimm_acpi_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev) +void nvdimm_acpi_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev) { if (dev->hotplugged) { acpi_send_event(DEVICE(hotplug_dev), ACPI_NVDIMM_HOTPLUG_STATUS); diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c index 336ebe1a13..b69379a18b 100644 --- a/hw/acpi/pcihp.c +++ b/hw/acpi/pcihp.c @@ -209,7 +209,7 @@ static void acpi_pcihp_eject_slot(AcpiPciHpState *s, unsigned bsel, unsigned slo */ qdev->pending_deleted_event = false; } else { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; hotplug_ctrl = qdev_get_hotplug_handler(qdev); hotplug_handler_unplug(hotplug_ctrl, qdev, &error_abort); @@ -261,7 +261,7 @@ void acpi_pcihp_reset(AcpiPciHpState *s) acpi_pcihp_update(s); } -void acpi_pcihp_device_pre_plug_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pdev = PCI_DEVICE(dev); @@ -275,7 +275,7 @@ void acpi_pcihp_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_plug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { PCIDevice *pdev = PCI_DEVICE(dev); @@ -317,7 +317,7 @@ void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, acpi_send_event(DEVICE(hotplug_dev), ACPI_PCI_HOTPLUG_STATUS); } -void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_unplug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { PCIDevice *pdev = PCI_DEVICE(dev); @@ -328,7 +328,7 @@ void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, qdev_unrealize(dev); } -void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_unplug_request_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c index 52bd61667f..a7d5356340 100644 --- a/hw/acpi/piix4.c +++ b/hw/acpi/piix4.c @@ -303,8 +303,8 @@ static void piix4_pm_powerdown_req(Notifier *n, void *opaque) acpi_pm1_evt_power_down(&s->ar); } -static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void piix4_device_pre_plug_cb(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); @@ -323,7 +323,7 @@ static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -static void piix4_device_plug_cb(HotplugHandler *hotplug_dev, +static void piix4_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); @@ -344,7 +344,7 @@ static void piix4_device_plug_cb(HotplugHandler *hotplug_dev, } } -static void piix4_device_unplug_request_cb(HotplugHandler *hotplug_dev, +static void piix4_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); @@ -364,7 +364,7 @@ static void piix4_device_unplug_request_cb(HotplugHandler *hotplug_dev, } } -static void piix4_device_unplug_cb(HotplugHandler *hotplug_dev, +static void piix4_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); @@ -383,7 +383,7 @@ static void piix4_device_unplug_cb(HotplugHandler *hotplug_dev, } } -static bool piix4_is_hotpluggable_bus(HotplugHandler *hotplug_dev, +static bool piix4_is_hotpluggable_bus(const HotplugHandler *hotplug_dev, BusState *bus) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 0871a35e11..3eecf094bc 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -3753,7 +3753,7 @@ static const CPUArchIdList *virt_possible_cpu_arch_ids(MachineState *ms) return ms->possible_cpus; } -static void virt_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void virt_memory_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3779,7 +3779,7 @@ static void virt_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp); } -static void virt_memory_plug(HotplugHandler *hotplug_dev, +static void virt_memory_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3798,7 +3798,7 @@ static void virt_memory_plug(HotplugHandler *hotplug_dev, } } -static void virt_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, +static void virt_machine_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3896,7 +3896,7 @@ static void virt_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev, +static void virt_machine_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3957,7 +3957,7 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev, } } -static void virt_dimm_unplug_request(HotplugHandler *hotplug_dev, +static void virt_dimm_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3977,7 +3977,7 @@ static void virt_dimm_unplug_request(HotplugHandler *hotplug_dev, errp); } -static void virt_dimm_unplug(HotplugHandler *hotplug_dev, +static void virt_dimm_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3995,8 +3995,9 @@ out: error_propagate(errp, local_err); } -static void virt_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void +virt_machine_device_unplug_request_cb(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { virt_dimm_unplug_request(hotplug_dev, dev, errp); @@ -4009,7 +4010,7 @@ static void virt_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev, } } -static void virt_machine_device_unplug_cb(HotplugHandler *hotplug_dev, +static void virt_machine_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -4022,8 +4023,8 @@ static void virt_machine_device_unplug_cb(HotplugHandler *hotplug_dev, } } -static HotplugHandler *virt_machine_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler * +virt_machine_get_hotplug_handler(MachineState *machine, DeviceState *dev) { MachineClass *mc = MACHINE_GET_CLASS(machine); diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c index 81db0bdc91..c36e18a4cf 100644 --- a/hw/char/virtio-serial-bus.c +++ b/hw/char/virtio-serial-bus.c @@ -979,7 +979,7 @@ static void virtser_port_device_realize(DeviceState *dev, Error **errp) port->elem = NULL; } -static void virtser_port_device_plug(HotplugHandler *hotplug_dev, +static void virtser_port_device_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(dev); diff --git a/hw/core/hotplug.c b/hw/core/hotplug.c index 00e80a67c8..3aca068840 100644 --- a/hw/core/hotplug.c +++ b/hw/core/hotplug.c @@ -13,7 +13,7 @@ #include "hw/core/hotplug.h" #include "qemu/module.h" -void hotplug_handler_pre_plug(HotplugHandler *plug_handler, +void hotplug_handler_pre_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { @@ -24,7 +24,7 @@ void hotplug_handler_pre_plug(HotplugHandler *plug_handler, } } -void hotplug_handler_plug(HotplugHandler *plug_handler, +void hotplug_handler_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { @@ -35,7 +35,7 @@ void hotplug_handler_plug(HotplugHandler *plug_handler, } } -void hotplug_handler_unplug_request(HotplugHandler *plug_handler, +void hotplug_handler_unplug_request(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { @@ -46,7 +46,7 @@ void hotplug_handler_unplug_request(HotplugHandler *plug_handler, } } -void hotplug_handler_unplug(HotplugHandler *plug_handler, +void hotplug_handler_unplug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { diff --git a/hw/core/qdev-hotplug.c b/hw/core/qdev-hotplug.c index 1d547e0dbd..d7fa8a5ed2 100644 --- a/hw/core/qdev-hotplug.c +++ b/hw/core/qdev-hotplug.c @@ -14,7 +14,7 @@ #include "hw/core/boards.h" #include "qapi/error.h" -HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev) +const HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev) { MachineState *machine; MachineClass *mc; @@ -90,7 +90,7 @@ bool qdev_hotunplug_allowed(DeviceState *dev, Error **errp) qdev_hotplug_unplug_allowed_common(dev, dev->parent_bus, errp); } -HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev) +const HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev) { if (dev->parent_bus) { return dev->parent_bus->hotplug_handler; @@ -98,9 +98,9 @@ HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev) return NULL; } -HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) +const HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_machine_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_machine_hotplug_handler(dev); if (hotplug_ctrl == NULL && dev->parent_bus) { hotplug_ctrl = qdev_get_bus_hotplug_handler(dev); @@ -109,7 +109,7 @@ HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) } /* can be used as ->unplug() callback for the simple cases */ -void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev, +void qdev_simple_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { qdev_unrealize(dev); diff --git a/hw/core/qdev.c b/hw/core/qdev.c index 0b0f2f47fa..c6540bec56 100644 --- a/hw/core/qdev.c +++ b/hw/core/qdev.c @@ -501,7 +501,7 @@ static void device_set_realized(Object *obj, bool value, Error **errp) { DeviceState *dev = DEVICE(obj); DeviceClass *dc = DEVICE_GET_CLASS(dev); - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; BusState *bus; NamedClockList *ncl; Error *local_err = NULL; diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c index e7adab7d2e..a49de33749 100644 --- a/hw/i386/microvm.c +++ b/hw/i386/microvm.c @@ -416,7 +416,7 @@ static void microvm_fix_kernel_cmdline(MachineState *machine) g_free(cmdline); } -static void microvm_device_pre_plug_cb(HotplugHandler *hotplug_dev, +static void microvm_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { X86CPU *cpu = X86_CPU(dev); @@ -425,26 +425,26 @@ static void microvm_device_pre_plug_cb(HotplugHandler *hotplug_dev, x86_cpu_pre_plug(hotplug_dev, dev, errp); } -static void microvm_device_plug_cb(HotplugHandler *hotplug_dev, +static void microvm_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { x86_cpu_plug(hotplug_dev, dev, errp); } -static void microvm_device_unplug_request_cb(HotplugHandler *hotplug_dev, +static void microvm_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { error_setg(errp, "unplug not supported by microvm"); } -static void microvm_device_unplug_cb(HotplugHandler *hotplug_dev, +static void microvm_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { error_setg(errp, "unplug not supported by microvm"); } -static HotplugHandler *microvm_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *microvm_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) { return HOTPLUG_HANDLER(machine); diff --git a/hw/i386/pc.c b/hw/i386/pc.c index e9e4fc262b..9006e7c29e 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1181,7 +1181,7 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs) g_free(i8259); } -static void pc_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void pc_memory_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { const X86MachineState *x86ms = X86_MACHINE(hotplug_dev); @@ -1214,7 +1214,7 @@ static void pc_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp); } -static void pc_memory_plug(HotplugHandler *hotplug_dev, +static void pc_memory_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCMachineState *pcms = PC_MACHINE(hotplug_dev); @@ -1231,7 +1231,7 @@ static void pc_memory_plug(HotplugHandler *hotplug_dev, hotplug_handler_plug(x86ms->acpi_dev, dev, &error_abort); } -static void pc_memory_unplug_request(HotplugHandler *hotplug_dev, +static void pc_memory_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { X86MachineState *x86ms = X86_MACHINE(hotplug_dev); @@ -1256,7 +1256,7 @@ static void pc_memory_unplug_request(HotplugHandler *hotplug_dev, errp); } -static void pc_memory_unplug(HotplugHandler *hotplug_dev, +static void pc_memory_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCMachineState *pcms = PC_MACHINE(hotplug_dev); @@ -1274,7 +1274,7 @@ static void pc_memory_unplug(HotplugHandler *hotplug_dev, error_propagate(errp, local_err); } -static void pc_hv_balloon_pre_plug(HotplugHandler *hotplug_dev, +static void pc_hv_balloon_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { /* The vmbus handler has no hotplug handler; we should never end up here. */ @@ -1282,13 +1282,13 @@ static void pc_hv_balloon_pre_plug(HotplugHandler *hotplug_dev, memory_device_pre_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev), errp); } -static void pc_hv_balloon_plug(HotplugHandler *hotplug_dev, +static void pc_hv_balloon_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { memory_device_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev)); } -static void pc_sp_mem_pre_plug(HotplugHandler *hotplug_dev, +static void pc_sp_mem_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { MachineState *ms = MACHINE(hotplug_dev); @@ -1304,7 +1304,7 @@ static void pc_sp_mem_pre_plug(HotplugHandler *hotplug_dev, memory_device_pre_plug(MEMORY_DEVICE(dev), ms, errp); } -static void pc_sp_mem_plug(HotplugHandler *hotplug_dev, +static void pc_sp_mem_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpMemDevice *spm = SP_MEM(dev); @@ -1318,7 +1318,7 @@ static void pc_sp_mem_plug(HotplugHandler *hotplug_dev, e820_add_entry(addr, size, E820_SOFT_RESERVED); } -static void pc_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, +static void pc_machine_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -1356,7 +1356,7 @@ static void pc_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -static void pc_machine_device_plug_cb(HotplugHandler *hotplug_dev, +static void pc_machine_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -1372,7 +1372,7 @@ static void pc_machine_device_plug_cb(HotplugHandler *hotplug_dev, } } -static void pc_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev, +static void pc_machine_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -1388,7 +1388,7 @@ static void pc_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev, } } -static void pc_machine_device_unplug_cb(HotplugHandler *hotplug_dev, +static void pc_machine_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -1403,8 +1403,8 @@ static void pc_machine_device_unplug_cb(HotplugHandler *hotplug_dev, } } -static HotplugHandler *pc_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *pc_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) || object_dynamic_cast(OBJECT(dev), TYPE_SP_MEM) || diff --git a/hw/i386/x86-common.c b/hw/i386/x86-common.c index 8f9419e7d3..ae58352760 100644 --- a/hw/i386/x86-common.c +++ b/hw/i386/x86-common.c @@ -158,7 +158,7 @@ static CPUArchId *x86_find_cpu_slot(MachineState *ms, uint32_t id, int *idx) return found_cpu; } -void x86_cpu_plug(HotplugHandler *hotplug_dev, +void x86_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CPUArchId *found_cpu; @@ -199,7 +199,7 @@ out: error_propagate(errp, local_err); } -void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void x86_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { int idx = -1; @@ -222,7 +222,7 @@ void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, errp); } -void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev, +void x86_cpu_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CPUArchId *found_cpu; @@ -248,7 +248,7 @@ void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev, error_propagate(errp, local_err); } -void x86_cpu_pre_plug(HotplugHandler *hotplug_dev, +void x86_cpu_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { int idx; diff --git a/hw/intc/loongarch_dintc.c b/hw/intc/loongarch_dintc.c index c01f1fe07e..1bedfbce43 100644 --- a/hw/intc/loongarch_dintc.c +++ b/hw/intc/loongarch_dintc.c @@ -168,8 +168,8 @@ static DINTCCore *loongarch_dintc_get_cpu(LoongArchDINTCState *s, return loongarch_dintc_cpu_by_arch_id(s, arch_id); } -static void loongarch_dintc_cpu_plug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void loongarch_dintc_cpu_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchDINTCState *s = LOONGARCH_DINTC(hotplug_dev); Object *obj = OBJECT(dev); @@ -194,8 +194,8 @@ static void loongarch_dintc_cpu_plug(HotplugHandler *hotplug_dev, return; } -static void loongarch_dintc_cpu_unplug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void loongarch_dintc_cpu_unplug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchDINTCState *s = LOONGARCH_DINTC(hotplug_dev); Object *obj = OBJECT(dev); diff --git a/hw/intc/loongarch_extioi_common.c b/hw/intc/loongarch_extioi_common.c index 5cb0d396c6..22cbb7a097 100644 --- a/hw/intc/loongarch_extioi_common.c +++ b/hw/intc/loongarch_extioi_common.c @@ -28,7 +28,7 @@ static ExtIOICore *loongarch_extioi_get_cpu(LoongArchExtIOICommonState *s, return NULL; } -static void loongarch_extioi_cpu_plug(HotplugHandler *hotplug_dev, +static void loongarch_extioi_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongArchExtIOICommonState *s = LOONGARCH_EXTIOI_COMMON(hotplug_dev); @@ -60,7 +60,7 @@ static void loongarch_extioi_cpu_plug(HotplugHandler *hotplug_dev, } } -static void loongarch_extioi_cpu_unplug(HotplugHandler *hotplug_dev, +static void loongarch_extioi_cpu_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongArchExtIOICommonState *s = LOONGARCH_EXTIOI_COMMON(hotplug_dev); diff --git a/hw/intc/loongarch_ipi.c b/hw/intc/loongarch_ipi.c index 28d816e3f5..c8f775a93e 100644 --- a/hw/intc/loongarch_ipi.c +++ b/hw/intc/loongarch_ipi.c @@ -129,7 +129,7 @@ static void loongarch_ipi_reset_hold(Object *obj, ResetType type) } } -static void loongarch_ipi_cpu_plug(HotplugHandler *hotplug_dev, +static void loongarch_ipi_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongsonIPICommonState *lics = LOONGSON_IPI_COMMON(hotplug_dev); @@ -155,7 +155,7 @@ static void loongarch_ipi_cpu_plug(HotplugHandler *hotplug_dev, qdev_connect_gpio_out(DEVICE(lics), index, qdev_get_gpio_in(dev, IRQ_IPI)); } -static void loongarch_ipi_cpu_unplug(HotplugHandler *hotplug_dev, +static void loongarch_ipi_cpu_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongsonIPICommonState *lics = LOONGSON_IPI_COMMON(hotplug_dev); diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 9cc79929a8..9c5371af9d 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -1167,7 +1167,7 @@ static CPUArchId *virt_find_empty_cpu_slot(MachineState *ms) return NULL; } -static void virt_cpu_pre_plug(HotplugHandler *hotplug_dev, +static void virt_cpu_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1229,7 +1229,7 @@ static void virt_cpu_pre_plug(HotplugHandler *hotplug_dev, numa_cpu_pre_plug(cpu_slot, dev, errp); } -static void virt_cpu_unplug_request(HotplugHandler *hotplug_dev, +static void virt_cpu_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1246,7 +1246,7 @@ static void virt_cpu_unplug_request(HotplugHandler *hotplug_dev, hotplug_handler_unplug_request(HOTPLUG_HANDLER(lvms->acpi_ged), dev, errp); } -static void virt_cpu_unplug(HotplugHandler *hotplug_dev, +static void virt_cpu_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CPUArchId *cpu_slot; @@ -1268,7 +1268,7 @@ static void virt_cpu_unplug(HotplugHandler *hotplug_dev, cpu_slot->cpu = NULL; } -static void virt_cpu_plug(HotplugHandler *hotplug_dev, +static void virt_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CPUArchId *cpu_slot; @@ -1304,14 +1304,14 @@ static bool memhp_type_supported(DeviceState *dev) !object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM); } -static void virt_mem_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +static void virt_mem_pre_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp); } -static void virt_device_pre_plug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_device_pre_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { if (memhp_type_supported(dev)) { virt_mem_pre_plug(hotplug_dev, dev, errp); @@ -1320,8 +1320,8 @@ static void virt_device_pre_plug(HotplugHandler *hotplug_dev, } } -static void virt_mem_unplug_request(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_mem_unplug_request(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1330,8 +1330,8 @@ static void virt_mem_unplug_request(HotplugHandler *hotplug_dev, errp); } -static void virt_device_unplug_request(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_device_unplug_request(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { if (memhp_type_supported(dev)) { virt_mem_unplug_request(hotplug_dev, dev, errp); @@ -1340,8 +1340,8 @@ static void virt_device_unplug_request(HotplugHandler *hotplug_dev, } } -static void virt_mem_unplug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_mem_unplug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1350,8 +1350,8 @@ static void virt_mem_unplug(HotplugHandler *hotplug_dev, qdev_unrealize(dev); } -static void virt_device_unplug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_device_unplug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { if (memhp_type_supported(dev)) { virt_mem_unplug(hotplug_dev, dev, errp); @@ -1360,8 +1360,8 @@ static void virt_device_unplug(HotplugHandler *hotplug_dev, } } -static void virt_mem_plug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_mem_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1370,8 +1370,8 @@ static void virt_mem_plug(HotplugHandler *hotplug_dev, dev, &error_abort); } -static void virt_device_plug_cb(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_device_plug_cb(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); MachineClass *mc = MACHINE_GET_CLASS(lvms); @@ -1389,8 +1389,8 @@ static void virt_device_plug_cb(HotplugHandler *hotplug_dev, } } -static HotplugHandler *virt_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *virt_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { MachineClass *mc = MACHINE_GET_CLASS(machine); diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c index 23c26aa08c..986ceff514 100644 --- a/hw/net/virtio-net.c +++ b/hw/net/virtio-net.c @@ -3816,7 +3816,7 @@ void virtio_net_set_netclient_name(VirtIONet *n, const char *name, static bool failover_unplug_primary(VirtIONet *n, DeviceState *dev) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; PCIDevice *pci_dev; Error *err = NULL; @@ -3839,7 +3839,7 @@ static bool failover_replug_primary(VirtIONet *n, DeviceState *dev, Error **errp) { Error *err = NULL; - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; PCIDevice *pdev = PCI_DEVICE(dev); BusState *primary_bus; diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c index 7478f0b33a..c641226e27 100644 --- a/hw/nvme/ctrl.c +++ b/hw/nvme/ctrl.c @@ -10615,8 +10615,8 @@ static const TypeInfo nvme_info = { }, }; -static void nvme_ns_hot_plug(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +static void nvme_ns_hot_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { NvmeNamespace *ns = NVME_NS(dev); NvmeSubsystem *subsys = ns->subsys; @@ -10647,8 +10647,8 @@ static void nvme_ns_hot_plug(HotplugHandler *hotplug_dev, DeviceState *dev, } } -static void nvme_ns_hot_unplug(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +static void nvme_ns_hot_unplug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { NvmeNamespace *ns = NVME_NS(dev); NvmeSubsystem *subsys = ns->subsys; diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c index 0c1383562d..bc53bcb69d 100644 --- a/hw/pci-bridge/pci_bridge_dev.c +++ b/hw/pci-bridge/pci_bridge_dev.c @@ -205,7 +205,7 @@ static const VMStateDescription pci_bridge_dev_vmstate = { } }; -void pci_bridge_dev_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pci_bridge_dev_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); @@ -218,7 +218,7 @@ void pci_bridge_dev_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, shpc_device_plug_cb(hotplug_dev, dev, errp); } -void pci_bridge_dev_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pci_bridge_dev_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); @@ -227,7 +227,7 @@ void pci_bridge_dev_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, shpc_device_unplug_cb(hotplug_dev, dev, errp); } -void pci_bridge_dev_unplug_request_cb(HotplugHandler *hotplug_dev, +void pci_bridge_dev_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c index 4622c75e48..42bcb9206d 100644 --- a/hw/pci/pcie.c +++ b/hw/pci/pcie.c @@ -508,7 +508,7 @@ static void pcie_cap_slot_plug_common(PCIDevice *hotplug_dev, DeviceState *dev, } } -void pcie_cap_slot_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *hotplug_pdev = PCI_DEVICE(hotplug_dev); @@ -525,7 +525,7 @@ void pcie_cap_slot_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, pcie_cap_slot_plug_common(PCI_DEVICE(hotplug_dev), dev, errp); } -void pcie_cap_slot_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *hotplug_pdev = PCI_DEVICE(hotplug_dev); @@ -571,7 +571,7 @@ void pcie_cap_slot_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, } } -void pcie_cap_slot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { qdev_unrealize(dev); @@ -579,7 +579,7 @@ void pcie_cap_slot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, static void pcie_unplug_device(PCIBus *bus, PCIDevice *dev, void *opaque) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(DEVICE(dev)); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(DEVICE(dev)); if (dev->partially_hotplugged) { dev->qdev.pending_deleted_event = false; @@ -608,7 +608,7 @@ static void pcie_cap_slot_do_unplug(PCIDevice *dev) PCI_EXP_SLTSTA_PDC); } -void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_dev, +void pcie_cap_slot_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { Error *local_err = NULL; diff --git a/hw/pci/pcie_port.c b/hw/pci/pcie_port.c index dbb6032160..57fcc9079a 100644 --- a/hw/pci/pcie_port.c +++ b/hw/pci/pcie_port.c @@ -188,7 +188,7 @@ int pcie_count_ds_ports(PCIBus *bus) return dsp_count; } -static bool pcie_slot_is_hotpluggable_bus(HotplugHandler *plug_handler, +static bool pcie_slot_is_hotpluggable_bus(const HotplugHandler *plug_handler, BusState *bus) { PCIESlot *s = PCIE_SLOT(bus->parent); diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c index 1198e1ab8c..3f24ca84f5 100644 --- a/hw/pci/shpc.c +++ b/hw/pci/shpc.c @@ -278,7 +278,7 @@ static void shpc_free_devices_in_slot(SHPCDevice *shpc, int slot) ++devfn) { PCIDevice *affected_dev = shpc->sec_bus->devices[devfn]; if (affected_dev) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; hotplug_ctrl = qdev_get_hotplug_handler(DEVICE(affected_dev)); hotplug_handler_unplug(hotplug_ctrl, DEVICE(affected_dev), @@ -561,8 +561,8 @@ static bool shpc_device_get_slot(PCIDevice *affected_dev, int *slot, return true; } -void shpc_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +void shpc_device_plug_cb(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); SHPCDevice *shpc = pci_hotplug_dev->shpc; @@ -601,13 +601,13 @@ void shpc_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, shpc_interrupt_update(pci_hotplug_dev); } -void shpc_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void shpc_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { qdev_unrealize(dev); } -void shpc_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void shpc_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c index 85cec810d9..4bc1426dc8 100644 --- a/hw/ppc/e500plat.c +++ b/hw/ppc/e500plat.c @@ -42,7 +42,7 @@ static void e500plat_init(MachineState *machine) ppce500_init(machine); } -static void e500plat_machine_device_plug_cb(HotplugHandler *hotplug_dev, +static void e500plat_machine_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PPCE500MachineState *pms = PPCE500_MACHINE(hotplug_dev); @@ -53,7 +53,7 @@ static void e500plat_machine_device_plug_cb(HotplugHandler *hotplug_dev, } } -static +static const HotplugHandler *e500plat_machine_get_hotpug_handler(MachineState *machine, DeviceState *dev) { diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 20e024907b..6d99464486 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -3616,7 +3616,7 @@ static void spapr_add_lmbs(DeviceState *dev, uint64_t addr_start, uint64_t size, } } -static void spapr_memory_plug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_memory_plug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *ms = SPAPR_MACHINE(hotplug_dev); PCDIMMDevice *dimm = PC_DIMM(dev); @@ -3642,7 +3642,7 @@ static void spapr_memory_plug(HotplugHandler *hotplug_dev, DeviceState *dev) } } -static void spapr_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void spapr_memory_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev); @@ -3807,7 +3807,7 @@ void spapr_memory_unplug_rollback(SpaprMachineState *spapr, DeviceState *dev) /* Callback to be called during DRC release. */ void spapr_lmb_release(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_ctrl); SpaprDimmState *ds = spapr_pending_dimm_unplugs_find(spapr, PC_DIMM(dev)); @@ -3832,7 +3832,7 @@ void spapr_lmb_release(DeviceState *dev) object_unparent(OBJECT(dev)); } -static void spapr_memory_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_memory_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev); SpaprDimmState *ds = spapr_pending_dimm_unplugs_find(spapr, PC_DIMM(dev)); @@ -3845,7 +3845,7 @@ static void spapr_memory_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) spapr_pending_dimm_unplugs_remove(spapr, ds); } -static void spapr_memory_unplug_request(HotplugHandler *hotplug_dev, +static void spapr_memory_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev); @@ -3899,14 +3899,14 @@ static void spapr_memory_unplug_request(HotplugHandler *hotplug_dev, /* Callback to be called during DRC release. */ void spapr_core_release(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); /* Call the unplug handler chain. This can never fail. */ hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort); object_unparent(OBJECT(dev)); } -static void spapr_core_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_core_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev) { MachineState *ms = MACHINE(hotplug_dev); CPUCore *cc = CPU_CORE(dev); @@ -3918,7 +3918,7 @@ static void spapr_core_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) } static -void spapr_core_unplug_request(HotplugHandler *hotplug_dev, DeviceState *dev, +void spapr_core_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -3988,7 +3988,7 @@ int spapr_core_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr, return 0; } -static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_core_plug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); MachineClass *mc = MACHINE_GET_CLASS(spapr); @@ -4043,7 +4043,7 @@ static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev) } -static void spapr_core_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void spapr_core_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { MachineState *machine = MACHINE(OBJECT(hotplug_dev)); @@ -4169,7 +4169,7 @@ static bool spapr_phb_placement(SpaprMachineState *spapr, uint32_t index, return true; } -static bool spapr_phb_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static bool spapr_phb_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -4198,7 +4198,7 @@ static bool spapr_phb_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, windows_supported, sphb->dma_liobn, errp); } -static void spapr_phb_plug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_phb_plug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(dev); SpaprDrc *drc; @@ -4220,18 +4220,18 @@ static void spapr_phb_plug(HotplugHandler *hotplug_dev, DeviceState *dev) void spapr_phb_release(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort); object_unparent(OBJECT(dev)); } -static void spapr_phb_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_phb_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev) { qdev_unrealize(dev); } -static void spapr_phb_unplug_request(HotplugHandler *hotplug_dev, +static void spapr_phb_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(dev); @@ -4251,7 +4251,7 @@ static void spapr_phb_unplug_request(HotplugHandler *hotplug_dev, } static -bool spapr_tpm_proxy_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +bool spapr_tpm_proxy_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -4264,7 +4264,7 @@ bool spapr_tpm_proxy_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, return true; } -static void spapr_tpm_proxy_plug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_tpm_proxy_plug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); SpaprTpmProxy *tpm_proxy = SPAPR_TPM_PROXY(dev); @@ -4275,7 +4275,7 @@ static void spapr_tpm_proxy_plug(HotplugHandler *hotplug_dev, DeviceState *dev) spapr->tpm_proxy = tpm_proxy; } -static void spapr_tpm_proxy_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_tpm_proxy_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -4284,7 +4284,7 @@ static void spapr_tpm_proxy_unplug(HotplugHandler *hotplug_dev, DeviceState *dev spapr->tpm_proxy = NULL; } -static void spapr_machine_device_plug(HotplugHandler *hotplug_dev, +static void spapr_machine_device_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -4298,7 +4298,7 @@ static void spapr_machine_device_plug(HotplugHandler *hotplug_dev, } } -static void spapr_machine_device_unplug(HotplugHandler *hotplug_dev, +static void spapr_machine_device_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -4324,7 +4324,7 @@ bool spapr_memory_hot_unplug_supported(SpaprMachineState *spapr) spapr_ovec_empty(spapr->ov5_cas); } -static void spapr_machine_device_unplug_request(HotplugHandler *hotplug_dev, +static void spapr_machine_device_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *sms = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -4349,7 +4349,7 @@ static void spapr_machine_device_unplug_request(HotplugHandler *hotplug_dev, } } -static void spapr_machine_device_pre_plug(HotplugHandler *hotplug_dev, +static void spapr_machine_device_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -4363,8 +4363,8 @@ static void spapr_machine_device_pre_plug(HotplugHandler *hotplug_dev, } } -static HotplugHandler *spapr_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *spapr_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) || object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE) || diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c index 6647428391..542ed79497 100644 --- a/hw/ppc/spapr_nvdimm.c +++ b/hw/ppc/spapr_nvdimm.c @@ -64,7 +64,7 @@ struct SPAPRNVDIMMClass { void (*unrealize)(NVDIMMDevice *dimm, Error **errp); }; -bool spapr_nvdimm_validate(HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm, +bool spapr_nvdimm_validate(const HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm, uint64_t size, Error **errp) { const MachineClass *mc = MACHINE_GET_CLASS(hotplug_dev); diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index c1d4b7806e..f7fc544d35 100644 --- a/hw/ppc/spapr_pci.c +++ b/hw/ppc/spapr_pci.c @@ -1445,7 +1445,7 @@ static int spapr_dt_pci_device(SpaprPhbState *sphb, PCIDevice *dev, /* Callback to be called during DRC release. */ void spapr_phb_remove_pci_device_cb(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort); object_unparent(OBJECT(dev)); @@ -1454,7 +1454,7 @@ void spapr_phb_remove_pci_device_cb(DeviceState *dev) int spapr_pci_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr, void *fdt, int *fdt_start_offset, Error **errp) { - HotplugHandler *plug_handler = qdev_get_hotplug_handler(drc->dev); + const HotplugHandler *plug_handler = qdev_get_hotplug_handler(drc->dev); SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(plug_handler); PCIDevice *pdev = PCI_DEVICE(drc->dev); @@ -1521,7 +1521,7 @@ static bool bridge_has_valid_chassis_nr(Object *bridge, Error **errp) return true; } -static void spapr_pci_pre_plug(HotplugHandler *plug_handler, +static void spapr_pci_pre_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { SpaprPhbState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler)); @@ -1556,7 +1556,7 @@ static void spapr_pci_pre_plug(HotplugHandler *plug_handler, } } -static void spapr_pci_plug(HotplugHandler *plug_handler, +static void spapr_pci_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { SpaprPhbState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler)); @@ -1614,7 +1614,7 @@ static void spapr_pci_bridge_unplug(SpaprPhbState *phb, remove_drcs(phb, bus); } -static void spapr_pci_unplug(HotplugHandler *plug_handler, +static void spapr_pci_unplug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { SpaprPhbState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler)); @@ -1639,7 +1639,7 @@ static void spapr_pci_unplug(HotplugHandler *plug_handler, qdev_unrealize(plugged_dev); } -static void spapr_pci_unplug_request(HotplugHandler *plug_handler, +static void spapr_pci_unplug_request(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { SpaprPhbState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler)); diff --git a/hw/remote/machine.c b/hw/remote/machine.c index ced782f6a9..f79f5a0565 100644 --- a/hw/remote/machine.c +++ b/hw/remote/machine.c @@ -111,7 +111,7 @@ static void remote_machine_instance_init(Object *obj) s->auto_shutdown = true; } -static void remote_machine_dev_unplug_cb(HotplugHandler *hotplug_dev, +static void remote_machine_dev_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { qdev_unrealize(dev); diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index f3a1cc5ba3..d4b501802f 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -1088,8 +1088,8 @@ static void virt_set_acpi(Object *obj, Visitor *v, const char *name, visit_type_OnOffAuto(v, name, &s->acpi, errp); } -static HotplugHandler *virt_machine_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler * +virt_machine_get_hotplug_handler(MachineState *machine, DeviceState *dev) { MachineClass *mc = MACHINE_GET_CLASS(machine); RISCVVirtState *s = RISCV_VIRT_MACHINE(machine); @@ -1104,7 +1104,7 @@ static HotplugHandler *virt_machine_get_hotplug_handler(MachineState *machine, return NULL; } -static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev, +static void virt_machine_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { RISCVVirtState *s = RISCV_VIRT_MACHINE(hotplug_dev); diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c index 440fefb7d0..e7cd9ac7b6 100644 --- a/hw/s390x/css-bridge.c +++ b/hw/s390x/css-bridge.c @@ -26,7 +26,7 @@ * (including sending a channel report to the guest) and remove the * device from the virtual css bus. */ -static void ccw_device_unplug(HotplugHandler *hotplug_dev, +static void ccw_device_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CcwDevice *ccw_dev = CCW_DEVICE(dev); diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c index eff980fdfe..2eb4e8cec4 100644 --- a/hw/s390x/s390-pci-bus.c +++ b/hw/s390x/s390-pci-bus.c @@ -158,7 +158,7 @@ static void s390_pci_shutdown_notifier(Notifier *n, void *opaque) static void s390_pci_perform_unplug(S390PCIBusDevice *pbdev) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; if (pbdev->pft == ZPCI_PFT_ISM) { notifier_remove(&pbdev->shutdown_notifier); @@ -1005,8 +1005,8 @@ static bool s390_pci_alloc_idx(S390pciState *s, S390PCIBusDevice *pbdev) return true; } -static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +static void s390_pcihost_pre_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); @@ -1079,7 +1079,7 @@ static int s390_pci_interp_plug(S390pciState *s, S390PCIBusDevice *pbdev) return 0; } -static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void s390_pcihost_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); @@ -1216,7 +1216,7 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev, } } -static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void s390_pcihost_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); @@ -1255,7 +1255,7 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev, } } -static void s390_pcihost_unplug_request(HotplugHandler *hotplug_dev, +static void s390_pcihost_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 17266779a6..7fb78d8fa1 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -343,8 +343,8 @@ static void ccw_init(MachineState *machine) } -static void s390_cpu_plug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void s390_cpu_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { ERRP_GUARD(); MachineState *ms = MACHINE(hotplug_dev); @@ -608,7 +608,7 @@ out_lock: bql_lock(); } -static void s390_machine_device_pre_plug(HotplugHandler *hotplug_dev, +static void s390_machine_device_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) { @@ -618,7 +618,7 @@ static void s390_machine_device_pre_plug(HotplugHandler *hotplug_dev, } } -static void s390_machine_device_plug(HotplugHandler *hotplug_dev, +static void s390_machine_device_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { S390CcwMachineState *s390ms = S390_CCW_MACHINE(hotplug_dev); @@ -648,7 +648,7 @@ static void s390_machine_device_plug(HotplugHandler *hotplug_dev, } } -static void s390_machine_device_unplug_request(HotplugHandler *hotplug_dev, +static void s390_machine_device_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) { @@ -662,7 +662,7 @@ static void s390_machine_device_unplug_request(HotplugHandler *hotplug_dev, } } -static void s390_machine_device_unplug(HotplugHandler *hotplug_dev, +static void s390_machine_device_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) { @@ -715,8 +715,8 @@ static const CPUArchIdList *s390_possible_cpu_arch_ids(MachineState *ms) return ms->possible_cpus; } -static HotplugHandler *s390_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *s390_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) || object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW) || diff --git a/hw/s390x/virtio-ccw-md.c b/hw/s390x/virtio-ccw-md.c index 0b18b49bc4..70dbea819a 100644 --- a/hw/s390x/virtio-ccw-md.c +++ b/hw/s390x/virtio-ccw-md.c @@ -19,7 +19,7 @@ void virtio_ccw_md_pre_plug(VirtIOMDCcw *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; @@ -48,7 +48,7 @@ void virtio_ccw_md_pre_plug(VirtIOMDCcw *vmd, MachineState *ms, Error **errp) void virtio_ccw_md_plug(VirtIOMDCcw *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; @@ -72,7 +72,7 @@ void virtio_ccw_md_unplug_request(VirtIOMDCcw *vmd, MachineState *ms, { VirtIOMDCcwClass *vmdc = VIRTIO_MD_CCW_GET_CLASS(vmd); DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); const HotplugHandlerClass *hdc; Error *local_err = NULL; @@ -112,7 +112,7 @@ void virtio_ccw_md_unplug_request(VirtIOMDCcw *vmd, MachineState *ms, void virtio_ccw_md_unplug(VirtIOMDCcw *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c index d82874ed27..30fb2c0681 100644 --- a/hw/s390x/virtio-ccw.c +++ b/hw/s390x/virtio-ccw.c @@ -1235,7 +1235,7 @@ static void virtio_ccw_busdev_unrealize(DeviceState *dev) virtio_ccw_device_unrealize(_dev); } -static void virtio_ccw_busdev_unplug(HotplugHandler *hotplug_dev, +static void virtio_ccw_busdev_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtioCcwDevice *_dev = to_virtio_ccw_dev_fast(dev); diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c index 132f833226..d7e2662aa7 100644 --- a/hw/scsi/virtio-scsi.c +++ b/hw/scsi/virtio-scsi.c @@ -1144,14 +1144,14 @@ static void virtio_scsi_change(SCSIBus *bus, SCSIDevice *dev, SCSISense sense) } } -static void virtio_scsi_pre_hotplug(HotplugHandler *hotplug_dev, +static void virtio_scsi_pre_hotplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SCSIDevice *sd = SCSI_DEVICE(dev); sd->hba_supports_iothread = true; } -static void virtio_scsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void virtio_scsi_hotplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtIODevice *vdev = VIRTIO_DEVICE(hotplug_dev); @@ -1183,7 +1183,7 @@ static void virtio_scsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, } } -static void virtio_scsi_hotunplug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void virtio_scsi_hotunplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtIODevice *vdev = VIRTIO_DEVICE(hotplug_dev); diff --git a/hw/scsi/vmw_pvscsi.c b/hw/scsi/vmw_pvscsi.c index 05f93171cd..77c9b843b4 100644 --- a/hw/scsi/vmw_pvscsi.c +++ b/hw/scsi/vmw_pvscsi.c @@ -612,7 +612,7 @@ pvscsi_send_msg(PVSCSIState *s, SCSIDevice *dev, uint32_t msg_type) } static void -pvscsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) +pvscsi_hotplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PVSCSIState *s = PVSCSI(hotplug_dev); @@ -620,7 +620,7 @@ pvscsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) } static void -pvscsi_hot_unplug(HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) +pvscsi_hot_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PVSCSIState *s = PVSCSI(hotplug_dev); diff --git a/hw/virtio/virtio-md-pci.c b/hw/virtio/virtio-md-pci.c index aa5b11c0f6..97ea0ec7b3 100644 --- a/hw/virtio/virtio-md-pci.c +++ b/hw/virtio/virtio-md-pci.c @@ -19,7 +19,7 @@ void virtio_md_pci_pre_plug(VirtIOMDPCI *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; @@ -47,7 +47,7 @@ void virtio_md_pci_pre_plug(VirtIOMDPCI *vmd, MachineState *ms, Error **errp) void virtio_md_pci_plug(VirtIOMDPCI *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; @@ -71,7 +71,7 @@ void virtio_md_pci_unplug_request(VirtIOMDPCI *vmd, MachineState *ms, { VirtIOMDPCIClass *vmdc = VIRTIO_MD_PCI_GET_CLASS(vmd); DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); const HotplugHandlerClass *hdc; Error *local_err = NULL; @@ -110,7 +110,7 @@ void virtio_md_pci_unplug_request(VirtIOMDPCI *vmd, MachineState *ms, void virtio_md_pci_unplug(VirtIOMDPCI *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c index 1762816bf4..8def3bb68b 100644 --- a/hw/xen/xen-bus.c +++ b/hw/xen/xen-bus.c @@ -374,7 +374,7 @@ fail: g_free(key); } -static void xen_bus_unplug_request(HotplugHandler *hotplug, +static void xen_bus_unplug_request(const HotplugHandler *hotplug, DeviceState *dev, Error **errp) { diff --git a/stubs/hotplug-stubs.c b/stubs/hotplug-stubs.c index 0f592ee139..32b4af7997 100644 --- a/stubs/hotplug-stubs.c +++ b/stubs/hotplug-stubs.c @@ -14,19 +14,19 @@ #include "qemu/osdep.h" #include "hw/core/qdev.h" -HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) +const HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) { return NULL; } -void hotplug_handler_pre_plug(HotplugHandler *plug_handler, +void hotplug_handler_pre_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { g_assert_not_reached(); } -void hotplug_handler_plug(HotplugHandler *plug_handler, +void hotplug_handler_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c index 0c5502d45b..a62ad23ecf 100644 --- a/system/qdev-monitor.c +++ b/system/qdev-monitor.c @@ -917,7 +917,7 @@ static DeviceState *find_device_state(const char *id, bool use_generic_error, void qdev_unplug(DeviceState *dev, Error **errp) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; const HotplugHandlerClass *hdc; Error *local_err = NULL; -- MST From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:25:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:25:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415350.1644786 (Exim 4.92) (envelope-from ) id 1x4lL6-0007SE-8B; Thu, 10 Sep 2026 20:25:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415350.1644786; Thu, 10 Sep 2026 20:25:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lL6-0007S7-5P; Thu, 10 Sep 2026 20:25:44 +0000 Received: by outflank-mailman (input) for mailman id 1415350; Thu, 10 Sep 2026 20:25:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lL4-0007S1-Pn for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:25:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lL3-001iXL-J0 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:25:41 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa31214-8faa-0a2a0a5109dd-0a2a4509d662-28 for ; Thu, 10 Sep 2026 22:25:41 +0200 Received: from [40.107.200.47] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa31244-be1a-0a2a45090019-286bc82f6da9-3 for ; Thu, 10 Sep 2026 22:25:41 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV5PR03MB8433.namprd03.prod.outlook.com (2603:10b6:408:361::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:25:37 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:25:37 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=f8eP+diXAf0wWvEVvFwAu4wP2FuA0rxYmgtxE26LLcimYj95Br2zljWnIhWYJvvTdAqrtUSTF/fdtsDD1MeUX1lqv/Z+1reAYAXVetINiHNSLYTaYnQCOg8w6Ls+mJsP3/ifJSVG39Y6atwbpMguhkYYnPsl+cKRWhrhxXE0gSzuHlN979eepz3BbWM6UNdlLqt2m1YiyBQAsiTwaVMx/FysyTp9UGZIYUJeIPieFs5Q1BqaQDIl0QuJ2s458cJ9jUukJ/1LUjwj4xZdSYsaMcoJxs0SRoJcUXKhZdiZfTkBD6mLCCeCfn9xtEHTpSAbZwy4gT0xjwyfZGy9LHU7xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=waGHhY/QzzCrf17IvKJaL2pT3f94Cq+lMBmL3GUDLVw=; b=AC8lfvQoehk7/M/YAreBKSYG+vEko4X1yz5KYptwCnCCwRn5Q6xQEBVwlgRQiI7WdAXn846EwOrmpsPdfSdPxsyqxBZLsJNmsEQcDucy88wBczHsNDFBQEy5HnjZJEb3DZW0+lBPEhd6yj7CmOpknvogrS6GuiFLnCGIhfjs+uPMAS/VnvDi1gfP4UaU/UuinlixEONd7usyD5oV6fFRH9wWNd9sF1c2QIyd2vJ5Z2AX9Ss7QRM7ZksA5ZXUq/OOEN3KRP6DZeYgRkK94tK75hC47Ivrxr8GH8HSYiV3sypbz0MA56mmHfWGbvEpuU8mWWDnrkqviEM59GNOWZrX4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=waGHhY/QzzCrf17IvKJaL2pT3f94Cq+lMBmL3GUDLVw=; b=ZdLT8IWTJABxY+rk/nZEeJ+0JPMLoV0ftKb3kDKS8wfUN+Yx0f+QJBDYWyzvOSxGSx3JI0ZmwjUJdsTN8ITF9V38JrEauwDDIS5lZlt06vPwFooIDfVcgO0trVp7aPCr3V7gVuISj36mzf24lMrajlUOj6hY3T6nkvznLECJvzE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v2 0/7] unmap_page_range optimisation Date: Thu, 10 Sep 2026 21:27:21 +0100 Message-ID: <20260910202729.462828-1-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO2P265CA0494.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13a::19) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV5PR03MB8433:EE_ X-MS-Office365-Filtering-Correlation-Id: 9198f354-189d-4e8e-62f4-08df0f79accf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|56012099006|11063799006|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: S3pN2NRfksSn4CDuf9hX4NyIS/40boOCSA6Bt+W+wY6YLFqHOpRZNNljCcQbizPkNoG1K70VL4bU69NYX/liNkTrq8nlSiyHgY8RQjG/zCilHejVSZB4Ig5fiR+RPcF2BUKlFqaljYxSm1uzYWQAqN1TZ4E7KXpQc0DT8+oSidlygmbfQGVwj2EBqb1+fQp7UyKXSe/vgrYCD13Mw8ZqKcUd1m5hlE41eH0ol2C8eg12fMa6sRPQ0JpT2+lSV3O21X2gUW34U2vkks2NJDM1tBudPefFjMS5QXMtMlqNan1b8HJHQ7V0AgqdXiGBYZF9qp4zMxN/exglXtsJCftdJbcY2VyLJgwdd3EcTcJa5mIqnbafMtNu3fN9khemxPbGnUm6BnprrvjiAb0bJIVVJM2xtMGdY1yPCNaxsYdaSNfxQs0tTlOy1mQNdQZvaHFhJ5CP1jmKFWhwrbkGT5L2nVBpW7LnxbjciU4Pfy6O6qovfyJPV46urDeztN2R8asyRwbwRBPJ4WVIpX4UbPpPoWpQKAZy8IvKainbIloe8ByxCKelnMuxy2He7JWIa2NZist4kuklXcUGI/M0Xsj9k1Gy5xUOjw9DxUCTF4ur0/dQokohcEH6kGyXcpR2fv/2z+phO4G6F6hRRQfzwtTpd7kdkkOmSv/vlvM3nbo1sDo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(56012099006)(11063799006)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?u8o+lttyHOUhZF0+541Hb3+wL8Z8+4wWK/yBW5uGnyRAA7q4GYeEoH7UBGES?= =?us-ascii?Q?0OczW2CPnAzaJAOnzQLNnr4fQ3y9KA9Qxacn6/2BNokARG1r7mhESwFtY/yk?= =?us-ascii?Q?jbE1H38CP6GA4MDdSb/mAFHVaVTMe1/rsBJT3HN/dkOXnVFAoSz3u60Q3cuk?= =?us-ascii?Q?uIYcZj/wAWKrGiDTEiNI3TgnncfZut0igwPA0BrHTBg4860NWGVEQGLytRGC?= =?us-ascii?Q?fklgPT5QlYBAXk7BpHgx4Y/+Md3ZoSq/sv3UGOWDIy5DerR8w3nOBGlgP9tB?= =?us-ascii?Q?32DAaFMfUMYwSMlmaHzFCm+rTh0TF7UBI5yjZyKaqG3KGhEpaKk5aZ5miG8L?= =?us-ascii?Q?igiCflI2HWX4y6kToAnFFkLaHKl6gO5p7Vf2ZkZz6NRtcQkbzC2rGfRR8fAA?= =?us-ascii?Q?vC1FMtMjErsqEAEE46QDdnQLNOZRPm7Ph4vsA6tA/fpKaGkMZmIs+UTXDepX?= =?us-ascii?Q?RExaYrXZl+kf9j07p3sXqLhlrl4kGDI0ZeIUlAkJUcQl6v5UPVMFXkTuR+jR?= =?us-ascii?Q?/yQZOUkUM155XHUh+n/3gvo1P+0GFuHgknQ/RT2zb233qqnx4g9GfGOmI91n?= =?us-ascii?Q?NfBsxLvbFKzKbY25jlyDL+xX0kSGcJXmddwcSA3Kj66/FuayjmuRK7FqGvn6?= =?us-ascii?Q?KeeZXQFb/ZV/i9TDGRogeXMHS7BS4DgmCybOjUg/gR33HzYxolr5XA6QwDgI?= =?us-ascii?Q?nbqbGD5cWtpfT6I2vDr9e0UqRD5Fkw32SFslc9nJeKq21SgOVYexpyzkSdUb?= =?us-ascii?Q?pocBKCB+JxlHRj7iTxVreC95YI4x1kfNwL9XwFPcqeWMvN7riNcc11AHnh0L?= =?us-ascii?Q?cyTYBkhuEyBGFr54gswn4sd61kx6nk6YlhRRdnUqd4roDuJJIrkJ7hQFAo8N?= =?us-ascii?Q?ZM4JyIDrqx21KzvU33Wydf2YwxVgiIN9CwjJ1xYg+oSyUkEQ+N81bbnsRSrl?= =?us-ascii?Q?BFNwXPovhY7N1X3suEuT0KL1M6nTsi/KK27sgvqWLwLZU5FO47jaaCn7o2SH?= =?us-ascii?Q?uvnHsvrxi4ryomC0gD7zFi5unL2k+Ss6RH/tKHIPeduz1HlQbNGl2GF22DQL?= =?us-ascii?Q?VfKDevicX9U62LHMvb9C4ZCXDjJUCyjJkWeGTlAJp3mXonYOQpN2dHMbwIPs?= =?us-ascii?Q?UoIPNgai8j2lDr2dBq/SP05wFQuyH+oiYYlgjxi+PLKRnptCCmDvm/x/TJoI?= =?us-ascii?Q?io2AJrTuUtpf0FsgMvn4ork0K6ZCK0uz0aoAXl0nocXBGhlfJhUshx4RbDmq?= =?us-ascii?Q?G2LjwY8QpRKWIXbEHd77maKRccQbft0rq8OIIPmDrkYGIjL7/H++hMtwZonA?= =?us-ascii?Q?UEVPohaTi3XYmjO5pxVrhhVX5ePJ/WdKmOMQytYdk1lJ2d8we1dOVabUAHE9?= =?us-ascii?Q?8VhmOAwQddXrBnz9TkXmVNIoxNIGhJQ7Nnt90JSf/5BmyKU/Wtc3Ioz8RAw+?= =?us-ascii?Q?G0Zf3sGnUFueiMGbGh+ihTYt/AtVAvs0RtQQj2PIUZRwvU0gu37npx/iCwTL?= =?us-ascii?Q?wyl33ZJufLsu8WmITDyLGsRnqlXt5gEM82IS+GSuxO4o00/Iw2HHksSqw98w?= =?us-ascii?Q?KYlRaZSFw0kcKxi6ub9npx1XtqnQ86JGXlg4ksVXvXvG+5thaVSXgCJ/svFy?= =?us-ascii?Q?9hNdf4A+WYOowfcZTlWvpJOOiugZe+n61o+TyAe3ZuONEaCzyRRBRGuoeyRA?= =?us-ascii?Q?NUecpX4m85a4g/8Jx37FLHPAtmw5rMiMUWMH3AYkdfKQ84rdbaK+SuoJ6+0t?= =?us-ascii?Q?AgUvwGj0hg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9198f354-189d-4e8e-62f4-08df0f79accf X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:25:37.5870 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Hg/j+5DvKp+dTOl+pWxJSF2lyLBrdINpVXze5X1gqa4HAydmC2siyQX68N5QsCkxSFA8ahr+/9OC3/eTEaNQjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8433 X-purgate-ID: tlsNG-bad1c0/1789071941-BF6D2034-01A357D1/0/0 X-purgate-type: clean X-purgate-size: 3296 v1: https://lore.kernel.org/xen-devel/20260727150615.1373200-1-kevin.lampis@citrix.com/ Previous discussion: RFC: unmap_page_range optimisation (avoiding emulation faults during VM migration) https://lore.kernel.org/xen-devel/16133EFF-88FF-467F-B78F-E96EB148C3A5@citrix.com/ This series adds a new MMU_PT_UPDATE_SWAP sub-op to the mmu_update hypercall which Linux can use from a new pte_get_and_clear pv-op to significantly improve the performance of unmap_page_range. A microbenchmark[1] which allocates a large number of pages and then clears them shows a performance increase from 1100ms to 640ms using the new pte_get_and_clear pv-op. Further profiling the microbenchmark with bpftrace[2] shows that Linux calls unmap_page_range() 23 times with an average execution time of 48ms dropping to 28ms when using the new operation. Changes in v2: - Add a sub-op to mmu_update instead of new hypercall - Add Linux patch - Other review comments [1] microbenchmark #include #include #include #include #include #include static uint64_t nsec(void) { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); return (uint64_t)ts.tv_sec * 1e9 + ts.tv_nsec; } int main(int argc, char **argv) { const size_t len = 1024UL * 1024 * 1024 * 4; const long pagesz = sysconf(_SC_PAGESIZE); char *p = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if ( p == MAP_FAILED ) err(1, "mmap"); /* Fault every page in */ for (size_t i = 0; i < len; i += pagesz) p[i] = 1; uint64_t start = nsec(); if ( madvise(p, len, MADV_DONTNEED) ) err(1, "madvise"); uint64_t end = nsec(); printf("MADV_DONTNEED on %zu MB took %.3f ms\n", len / 1024 / 1024, (end - start) / 1e6); munmap(p, len); return 0; } [2] bpftrace bpftrace -e ' kprobe:unmap_page_range /comm == "a.out"/ { @start[tid] = nsecs; } kretprobe:unmap_page_range /@start[tid] && comm == "a.out"/ { $delta = nsecs - @start[tid]; @count = count(); @total = sum($delta); delete(@start[tid]); } interval:s:10 { printf("avg call time = %d ns (%d calls)\n", (@total / @count), (uint64)@count); exit(); }' Jan Beulich (1): x86: make UPDATE_ENTRY() allow for multiple operation flags Kevin Lampis (5): x86: Remove return value from UPDATE_ENTRY x86: extend update_intpte() to support atomic get-and-update x86: extend mod_l1_entry() to optionally return the old PTE value x86: extend do_mmu_update() to support returning the old PTE value x86: New feature flag XENFEAT_mmu_pt_update_swap. xen: Add new Xen pv-op pte_get_and_clear. xen/arch/x86/mm.c | 161 +++++++++++++++++++------------- xen/arch/x86/pv/grant_table.c | 53 +++++------ xen/arch/x86/pv/mm.h | 27 +++--- xen/arch/x86/pv/ro-page-fault.c | 3 +- xen/common/kernel.c | 3 +- xen/include/public/features.h | 3 + xen/include/public/xen.h | 1 + 7 files changed, 140 insertions(+), 111 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:29:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:29:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415358.1644794 (Exim 4.92) (envelope-from ) id 1x4lOf-0008Ui-Ma; Thu, 10 Sep 2026 20:29:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415358.1644794; Thu, 10 Sep 2026 20:29:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOf-0008Ub-JT; Thu, 10 Sep 2026 20:29:25 +0000 Received: by outflank-mailman (input) for mailman id 1415358; Thu, 10 Sep 2026 20:29:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOe-0008UV-Bi for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:29:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lOd-0078if-OG for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:29:23 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa312e7-8faa-0a2a0a5109dd-0a2a450ba7f0-46 for ; Thu, 10 Sep 2026 22:29:23 +0200 Received: from [40.107.201.41] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa31322-b7e8-0a2a450b0019-286bc9296d3b-3 for ; Thu, 10 Sep 2026 22:29:23 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV5PR03MB8433.namprd03.prod.outlook.com (2603:10b6:408:361::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:29:20 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:29:20 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hp0Zznnk/nnodc2pyc4ISx9XX4qtAzozTWMr0Db20vx8GxM8uBgJ3BKDmvMC0Mzf4H+gJqLkgPioauBD+CQ3MWcSooRHSpDRYzQGHGxFHJwaScYBglONScgBnbtRNZ9sRFYlDw7QHffELciz0ZPdzYmRHlkLDMx2DxeSBcoMcLXMTZKh3bjVAo1E5NYDRuX7HokpnrcU6CWwR48q/aCWS+hXij6UjUcCCEFNZom+AsBpYdOpB6MUstYu4qpabnjSKgYzQbSAkgZZpupoKI7HwPEs2w5+kUxQlsw2z+3Ej251e+T+jWTl0/9KBVVjttq05OItQOVYjomJVb/Ewf9fmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=waGHhY/QzzCrf17IvKJaL2pT3f94Cq+lMBmL3GUDLVw=; b=wzIoHGWRK9sp/2vVTDxumWy0fPTb8HqB2gN2OBPYHnxtZ1+SQ+e9N6JtON006C/mh4CywPGchzsQEcvcF/AFXDQYC/rmwBdcVvYZWaweKwAYomsENo2K7b6+jPH6qZtyic755udSSCa3r/wiKnj3LmjF5/r+x7oXiGhw+3FAbsN2CYdMu6cXGg/2lmp9vMN7+FAV3+oW5H58D3YyPzg6prwvP8i2CWy08Yon1aOztqRq5FthyXeEttPdMmuE6nY/ehHUsQrQRrZ5z++4GqpohkQy5LSGRcxKCFxoybMni5AZTfIxKhQqU3ho3Rgc7LpXc5dqyUZ+m38/OUjVONSrnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=waGHhY/QzzCrf17IvKJaL2pT3f94Cq+lMBmL3GUDLVw=; b=O7fk9koMPdhuRfiLBAq/avMK9+ZseYn2C+Gf9N6EGAZwNODTWiCpNZu4ZZp0rOyntmSM/r+t5iywMSaI2UXrQBnm/Pth9alPC+E9nmJ/HcHbKLkJSlY+ZWbdD474IaiiXa9PVAbYEXaUNVdYJDjyrBrLiloc7tj+96kB/Za/Hng= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v2 0/7] unmap_page_range optimisation Date: Thu, 10 Sep 2026 21:31:06 +0100 Message-ID: <20260910203113.462943-1-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0589.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:295::17) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV5PR03MB8433:EE_ X-MS-Office365-Filtering-Correlation-Id: c5223992-0f93-4ef6-4b94-08df0f7a31c6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|11063799006|56012099006|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: YvbqhjrLQiDXUznSO2r58K62aiR+MzqAwuh3Cx4fT3vxznTRyvCQEy/YkftXtysn05i37JWqpQHaX2mUS/EV5UbnORBuuXOqPw9olIX27DYWqFOIggIck8TxsDzBWTKSxcvuQdpoQVtsMnftCDy0QcAnOSGQy6Xb6RcAKjgSRNWWqWD1OJ5IOnyJvhE3QvL3+uC4Xq7EfvrxwQhJ61zDlgw24t8LkiCkx+11bStR55qaVWvFtrhowxdLLiPLZ23w4w6dU5TKYiBpKYUJCwSrUNSGJFUSGftyteeb/jBpwo+egBCoEs4BMyBZvRcmOyXjfANMNo4SybMuu7Xpsj4tBHbiKM5WQlBVprf/Ij5suEFO0S9sPe9FU6OxrZYBA9l9pcBBHmVbrWb/R151h07k9z7rClvDB3Y4cm55qTmt3n88WngSNSvNIowoYxtZzgw2YoXgLOgQ5Ktg2WCoEm4EFC5TNMEdwIGvZfHdy2rpsHMpIVM7bKgWiLKkKviCYCSTnuL8nrI2tVYlFTM07t8s3BoYF1dDr8GFrDkANXe/dGk5rZfKd6SRctYGvpk3VxaL9tO2HzHeLnTm1QUy0gjXxQZfRRIi0fnM3A3AGu75ll9qZUxnQLRIAyZpYtEj0JmDPFZyrk3JlUo/lPgVujXTchk7BtAsujW7liE99f4WEpo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(11063799006)(56012099006)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yA2cKiTc9AmtZ8rIHG0O0lXwoEz3qo754BMlkST0bJ5ssim/M7c9s6Utnjmm?= =?us-ascii?Q?MrLUgCTa16iBY4crQG+teQZsP7YgPSOt3PIk8IpF1bHg19HO+gkV9cUMZWlO?= =?us-ascii?Q?VnwYh071JIpxLiMpN7U/bb3ISJH+YTKyxlOE5V9D1O4xGjCGadOhZOZTB8ht?= =?us-ascii?Q?VtJn/UaY+BYIUczDPjjiS7/TC72zTqiL/qOKd98KXbAHZCheoMHPDUtudRl1?= =?us-ascii?Q?SdcZ+ozrzUvyL6F2giaBror62wThj6LFJua5rpXwK8iPWeVDhK/77sUwINRH?= =?us-ascii?Q?Qlkcnx4PxZKi5z1x+7jqITEoYa2HXxxJJhLNysEBJrTJNRhtHSwP3c3hJOpY?= =?us-ascii?Q?+X1ZKAJiJGOS6t7a4gVC8gGmCJl8J1RgI18F035/HolqBoLaZ+ShNkGU5plK?= =?us-ascii?Q?y+VR/Tj5c+NPEZGLWxjiYiEsJbzTZZpXrOH0D91z3qaFgr0GG3aGPyYYjjXM?= =?us-ascii?Q?WFmRlqBoKCEwXwZhPVoZGT6CGBAvuHv7OcqmDeK2HKB5R/5QFB1/IsDrtf/u?= =?us-ascii?Q?+LFlHZQ9um+HihUFSubPwm108GlYYXDNML6JwIVPCYZTu4sznLZRBqcQWDiV?= =?us-ascii?Q?05Z1cSJZGUqVIsmjGTggmUdyvLKxHH1RSO8hjOJJPJrCrSzy63G+NBI0dI0F?= =?us-ascii?Q?RVcmIHpL26A2CWVU7rkGZguJjhCBzQL3JbFy9okNw8pU5saSbMBeC2IasL7p?= =?us-ascii?Q?c2jOt5P+j0TLKNO4OptXFaQ/8MkUC1NJHiNfpPLQ1WWND/UwNgc+MN6A3TiS?= =?us-ascii?Q?KZ4LiJTeJDyDXhIGJwwfeVgI/cBusyGz8Muu4pGoeu4zSfsdlplP3pAnRyNs?= =?us-ascii?Q?z35lhwLP5f91btOc27YphvkREONIBVOysP/S3hH4yTFXSSpjPJXivnLHaw/W?= =?us-ascii?Q?iwk67i8wkHwSuB17kwnV8ZJfv5pgZfYRMU1IGSpC1I6OyZ5Q26o5/cgSADDM?= =?us-ascii?Q?kX9I1SY++KoumMM9oDHz+HvzApyv6lC6zdlnl9UxD+TozAT0GOdQHeTx3kNL?= =?us-ascii?Q?fB9qs10r5ubuMxDYvSDXaAXqKftydk3THKH12Aqna0CIeWI6ZfGq/2tdFt6v?= =?us-ascii?Q?HIr/utjLGwfo6z8tUSbNUmbIqloGzM1kcyZH7LY9gk1g0qKsVB3sz1i2xKyz?= =?us-ascii?Q?dHQ+mduoQxAN/CtEj3gXc44HqRPTkoM4Hk+lpd8wGFjKEDue51waG+83smjS?= =?us-ascii?Q?0KxrqpnW8my1WjJpydpRy6m60bkwzG2BTXHQXo5ul1v05pd96XIMj8dn8sH+?= =?us-ascii?Q?uKuD4QlrTEhrfDnxo+tkejSKiN/hOyXCP8bqFcnwtnf6yJvHZoYIEY9hxgGg?= =?us-ascii?Q?Kgh/oX+DHwRPOPE59lMvmZzQmXfiQx979vFoD684XVcI2DuMAPuFC0pHGIzz?= =?us-ascii?Q?8l8u9p27drWCkHrzMdb033WYQLbPsH/GWYVB0ntyjT0AufE4Lanx7ppDKCg7?= =?us-ascii?Q?jWX8j5ugMfXKEwd1Cln2HYgIy8MJ/F1VaVNANgjac4tyg2Ok4AMO08I73zUg?= =?us-ascii?Q?TGeMl7CnqfwL7BZCDr38VIDgGwZpO1GvwHDLAp7l1e9MYMbB1Nyc0Dg0fCez?= =?us-ascii?Q?GuYenmULGBn4SZluHoLlpIqO6Om7CU+SVEIy/ePviAKQxWR46YL/geqfn8oE?= =?us-ascii?Q?F69VPh9Jxxx4Fw24eQ0i/sHqzz2SladogRn7EFx63BCXGUbQSXOaAKEDpQZG?= =?us-ascii?Q?1RoSzsTtbuGqWARwoYsgj9KM5f9010n4wyFCoXm19uy1fpEROK6lRJBXon3F?= =?us-ascii?Q?NSLHtfgiGg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5223992-0f93-4ef6-4b94-08df0f7a31c6 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:29:20.6723 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UussyGEPXoNn5l1KKbBr5CzTtjxbZJMbHRU3J0FTUPFmeI/tHGHHtmGqBwlaXV5xbPl5S8fJjQv/M3seFF6dzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8433 X-purgate-ID: tlsNG-42698a/1789072163-1BCD79EA-1B882FD7/0/0 X-purgate-type: clean X-purgate-size: 3296 v1: https://lore.kernel.org/xen-devel/20260727150615.1373200-1-kevin.lampis@citrix.com/ Previous discussion: RFC: unmap_page_range optimisation (avoiding emulation faults during VM migration) https://lore.kernel.org/xen-devel/16133EFF-88FF-467F-B78F-E96EB148C3A5@citrix.com/ This series adds a new MMU_PT_UPDATE_SWAP sub-op to the mmu_update hypercall which Linux can use from a new pte_get_and_clear pv-op to significantly improve the performance of unmap_page_range. A microbenchmark[1] which allocates a large number of pages and then clears them shows a performance increase from 1100ms to 640ms using the new pte_get_and_clear pv-op. Further profiling the microbenchmark with bpftrace[2] shows that Linux calls unmap_page_range() 23 times with an average execution time of 48ms dropping to 28ms when using the new operation. Changes in v2: - Add a sub-op to mmu_update instead of new hypercall - Add Linux patch - Other review comments [1] microbenchmark #include #include #include #include #include #include static uint64_t nsec(void) { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); return (uint64_t)ts.tv_sec * 1e9 + ts.tv_nsec; } int main(int argc, char **argv) { const size_t len = 1024UL * 1024 * 1024 * 4; const long pagesz = sysconf(_SC_PAGESIZE); char *p = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if ( p == MAP_FAILED ) err(1, "mmap"); /* Fault every page in */ for (size_t i = 0; i < len; i += pagesz) p[i] = 1; uint64_t start = nsec(); if ( madvise(p, len, MADV_DONTNEED) ) err(1, "madvise"); uint64_t end = nsec(); printf("MADV_DONTNEED on %zu MB took %.3f ms\n", len / 1024 / 1024, (end - start) / 1e6); munmap(p, len); return 0; } [2] bpftrace bpftrace -e ' kprobe:unmap_page_range /comm == "a.out"/ { @start[tid] = nsecs; } kretprobe:unmap_page_range /@start[tid] && comm == "a.out"/ { $delta = nsecs - @start[tid]; @count = count(); @total = sum($delta); delete(@start[tid]); } interval:s:10 { printf("avg call time = %d ns (%d calls)\n", (@total / @count), (uint64)@count); exit(); }' Jan Beulich (1): x86: make UPDATE_ENTRY() allow for multiple operation flags Kevin Lampis (5): x86: Remove return value from UPDATE_ENTRY x86: extend update_intpte() to support atomic get-and-update x86: extend mod_l1_entry() to optionally return the old PTE value x86: extend do_mmu_update() to support returning the old PTE value x86: New feature flag XENFEAT_mmu_pt_update_swap. xen: Add new Xen pv-op pte_get_and_clear. xen/arch/x86/mm.c | 161 +++++++++++++++++++------------- xen/arch/x86/pv/grant_table.c | 53 +++++------ xen/arch/x86/pv/mm.h | 27 +++--- xen/arch/x86/pv/ro-page-fault.c | 3 +- xen/common/kernel.c | 3 +- xen/include/public/features.h | 3 + xen/include/public/xen.h | 1 + 7 files changed, 140 insertions(+), 111 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:29:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:29:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415359.1644804 (Exim 4.92) (envelope-from ) id 1x4lOm-0000H0-TC; Thu, 10 Sep 2026 20:29:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415359.1644804; Thu, 10 Sep 2026 20:29:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOm-0000Gt-Pj; Thu, 10 Sep 2026 20:29:32 +0000 Received: by outflank-mailman (input) for mailman id 1415359; Thu, 10 Sep 2026 20:29:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOl-0000GO-5F for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:29:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lOk-001ixY-IG for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:29:30 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa312e5-e002-0a2a0a5209dd-0a2a4505c826-30 for ; Thu, 10 Sep 2026 22:29:30 +0200 Received: from [40.93.198.47] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa31328-4cb1-0a2a45050019-285dc62fd1a8-3 for ; Thu, 10 Sep 2026 22:29:30 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV5PR03MB8433.namprd03.prod.outlook.com (2603:10b6:408:361::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:29:26 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:29:26 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NW2YyJnJAMsu+9Qo+Ne5yJ7S7JTABKaffF98Ht/hMFGyoayWWRBgcpof+0uNe8hF3Z9c9lED8WJJhWkyOmmEXqDusrWNusef6RiAX47xYHcU/pKsslcJabXHIJEciaxMXmJlQkEuQ+woUvPQaWIOKCmaJ+WUpTrMTA3hdNQKb3/JybSXQlCxz+meBlR7ohIW3I02c+JYT/zfWYUPmrScdA8+8Hm+B06w4Jt3v8X5169Zdcp0NcNV1CQ4Mr0y7RxQtB3Vk/w83RO/e7anZjE2R/1j6MNqBM7aWZwuSMdp1eNclJIEUNRCzybPDMQYBoG9WDPO4t+JJC7sRXgbFfoDdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5PZCPy/IYhqH9L3yDZWNxwVLgkKWTeL1+WTsiJoODCQ=; b=FqY4B6b++/Ncxrkd2NwK19gehOYD8AFTGllyGu/JSK9bu9oN7pGtZiszBAqEuNTmGBB+Ol8UzsCkzWooK9cuDFjvSeVfu1FYPf8Y02epNqzMz+zKf19Df07O24L1gemoMchsizIAndWqRQNodym1SnrIje6A+oxGspRgxqz8R8SjZE5LdiszZFuDEBi8ge5DCXH33ZDiT9m5JOke0kEOQ9WHlar0PL27lcRhNWFstT2JiyA5ZcHvBIBQOMlpMyq/or+BRmdPdozI6B3zHm+kfmYKx3N/uwn+e64hJB0gGhxJspNfETzl27nZtjYkaSJGOyXgbDys7Idi4evIKGhkQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5PZCPy/IYhqH9L3yDZWNxwVLgkKWTeL1+WTsiJoODCQ=; b=hnNhDFjzqk/xHw1UvF1FiEq+6e2OfQLCERYN7O+9m4n+azo9CKRAICuo3WSpgkFI6DT/ftEGbD2oTxrh+c9L+mfFWz3oq/mLhE5FUDPdu+4SVXPGZ22jR+KEomKOynfLJl95E4nv6id9k+SEWGFviF+Dk+us3u5y7hyCihGWegk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, George Dunlap Subject: [PATCH v2 1/7] x86: make UPDATE_ENTRY() allow for multiple operation flags Date: Thu, 10 Sep 2026 21:31:07 +0100 Message-ID: <20260910203113.462943-2-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260910203113.462943-1-kevin.lampis@citrix.com> References: <20260910203113.462943-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0595.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:295::12) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV5PR03MB8433:EE_ X-MS-Office365-Filtering-Correlation-Id: bb5e4a74-0c4a-406e-c20c-08df0f7a34f7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|11063799006|56012099006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: sImLlXhak9nGVI67t0uBRoxsAVITuqH7Bz4CrhGhTmS+Uy+uwY+I+OG9emmHTMZ4g26uGCTpuaNaWbfgptFR35wyE9p8c8PUUDo7R/43SCRyhIdD3rnfxhIZ0KmwaI/4bCCeOB5I82CT4OiWQprKWQjY/ZiDsn5YoOFzWz2WIBvevJ/9DDwRdBklMzS71ybLPfgNjVscCm1tMjqKaZxpv5bQRz5kcQFRPDe8+WWLA6uC+uMNA1x3YRjZadkZJq1kZc1Ya+Nhs2T99xUr4qzB3IZ42C57n5+8f+1LbfZZK8//bdHzx0G0Xn00mj65UDsfAeLtcY/ga8PIvyhoBL4KEcSXJYd+416qpGWEr1rXwGKgGoGOGjaFbF0s8MWWjxF14VmZIvPNQViSkklZPQrS060md+JbbtWfjSImqTS48DqD2aYZj3VAj6d19Qgh2yKfGa/h/39n9oVgc2WnVo+ANOlDyBpPcGyWlr9GTI6o+QRFjmSalJG8RiDVQAOMjq4RHZsnCE7YbI9k/dbThNdKTNTvcZEQo3hkUtlpWPRNLQ5h8Yb7umy7R7KoqJXnVXNvnJ1NmoNJEQP3WBLERRKccsd+Rh3ztM1EOI0EA35FMsmU1G6M3cZWd4KbrdV/Fw5EfiAr78+1vNjfMmwYTSS4ihcZH7UcL1cxvWZJSEFCVIQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?MOQyfGzHkrd3uvj7X4vgoGV3os1EgQD+rkXu9Sv7XC+tdT38kcNdJeo49paw?= =?us-ascii?Q?9a6WCaPQIuwwegTtKFGPwFXxN00+asLDe6gYOx9h7a+iz248Rc6Kb4Qdm4Ua?= =?us-ascii?Q?bFvROkj6ify4flm+y/Q8SRiYYBtnihxRwyXrOsb5T8yOHmsaoOasOCQVXf6a?= =?us-ascii?Q?UJMQwBeaE+jxcdkBMnXJ5VmtZdA1oMOCCrJlPaP7jLDEz6iNm5ybKkmBF39l?= =?us-ascii?Q?vqs9CKf/sLrNkFrtO2tOSmGab1O8+jgjHz/ojeJklBqiKkt40/QI1tl7/G8a?= =?us-ascii?Q?MmRYFVprRLSoespKJjhnOZ/v1maR/ywIdU0RPqWgUzgyTyT5klj+QeRVNSZH?= =?us-ascii?Q?o0SRNkFS7B8roo+Wk3QW7NERPcwQOV+mfmqHWwp9WKlhTtYN4uqbKWaNiU6t?= =?us-ascii?Q?rtklGm+w8AxiXRHSokaKhyv3MwMy8ZZNYwCwywXol37lN5cgs1iTC70uN3JH?= =?us-ascii?Q?R25N+AeHHHX7yH73EQI689YH9WQS/59EWwYaL89FVsUeAYr2MzEAVatOzJ+J?= =?us-ascii?Q?0UDYTy90DZ9sz0vI+n0EeO8Shoqofg48nexXUiuIQ1g0fdFQToSRNHhpNS0P?= =?us-ascii?Q?//nwjugKMGnyyhjnLpD42NrK3cvb9QcwYax4nwaWjoTbbyoJTirOx9oyjkWv?= =?us-ascii?Q?BariF+grdyCV79PhS8JIcDjg2wCVkR4M2IfnmZCIvw/lik8F9v76Q9XuDoG5?= =?us-ascii?Q?SemwF3IgHkjNVsLXW7OCVLJ8qzZlgv0WngCqLsXzgnEGq8RfLjSDc7+wS0Bz?= =?us-ascii?Q?awcBFDPNY0GAmgq2y+/aZPIoumGjMdm3TB4AqZIsBLDc9Dn+nOBica3RX5ob?= =?us-ascii?Q?FCfmxCKInn6OPGmNy9rt9hlYJao+LSOe7EmmgqXFEKIA8ehyz4CfRO0+VYh4?= =?us-ascii?Q?rwRBomiP4KkmKh0X91rHoA8SC09P5XGyASXZr1vHQyJNqaGX6k3+meUBI/n6?= =?us-ascii?Q?VPfl7+/UrxtStmETuM9Py+6+nEg6ZsEDDVhKuZvRSEypBzjH21os9SpxAXN7?= =?us-ascii?Q?5brmH79xnzx4rwQ50s97ShQd4YV+DtIYhiDfr51t+eB4jaTrA42zeFZ8gf8r?= =?us-ascii?Q?e0hRSb28npNmbSQfsDrfKO0GDQWKX7H2RyA4cEZrVMGcAp1v25gjd4oL0yCe?= =?us-ascii?Q?WTmbWDKBHpbPS9/GGC5jmWdMeQSPQVJPheooTH9Nid3+Fj9RUfD7o1U1Dpbs?= =?us-ascii?Q?FS3b/6xy/6Wdo1TWWvv4teiCABYMdsyKvjGMLQl2Yiqcr/a6ppOd6X40jpcx?= =?us-ascii?Q?y/apZ9dNpBo9WuXOqIXKESi7JNT1K++YNpoHBOwcVhZO8p/wztvknW0XEjuS?= =?us-ascii?Q?kOMDpT+YpZY+gnklXEe/73Za9wMjh+qjk4iA7Mc28iJY7IYLLnXH9ETRuHns?= =?us-ascii?Q?4tODfE8o2oAt+eGhqR670pf1SJlVOyNIQVIb2N+u4OvsEbSvvNNLzmEDWXnB?= =?us-ascii?Q?oLngcQwyKEuK/kjsrJhSGfgpncuSkUS8s5x7Ow+abl3Ke5g8SVtCKHU/wvpY?= =?us-ascii?Q?LxBGc116O4nF/MvxkQ/3vc8vrbuVLiNIs+HIzcXEuyEIjFXaK49Y4omSLvGy?= =?us-ascii?Q?NumsIDlRE1c55uA2+axQgTWWPNXd9TyZ8Aj3znS7lR8ae2EPkgYgVdbAnJTX?= =?us-ascii?Q?KAG68+3+0LgAGPNtTqrbqGSYJwJ+p0+ZN/K3KGirWrR85CzGZzqstshhNSnD?= =?us-ascii?Q?Vfl3pq2LY6VlHy2sEnBPLw8wyUHim+ehiKRF/VqnX34V8YUXwood8wQe+rmu?= =?us-ascii?Q?wl5RTJNxxA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bb5e4a74-0c4a-406e-c20c-08df0f7a34f7 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:29:25.9990 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: XvOUmrrjsuqCsblJAi2D1rkzsjK0wGlwB9mGEFUBUVB+5d21uONtoJrqa9hSaT0KgnmlGIUJYBYle6n7m5UB1Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8433 X-purgate-ID: tlsNG-c201ff/1789072170-722AB2A1-80FD522E/0/0 X-purgate-type: clean X-purgate-size: 11395 From: Jan Beulich Signed-off-by: Jan Beulich Reviewed-by: George Dunlap --- Changes in v2: - New patch --- xen/arch/x86/mm.c | 48 ++++++++++++++++++++++++-------------------- xen/arch/x86/pv/mm.h | 13 +++++++----- 2 files changed, 34 insertions(+), 27 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index b158742408f9..5f778557b1e6 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2149,10 +2149,9 @@ static void l3t_unlock(struct page_info *page) /* Update the L1 entry at pl1e to new value nl1e. */ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, - mfn_t gl1mfn, unsigned int cmd, + mfn_t gl1mfn, unsigned int update_flags, struct vcpu *pt_vcpu, struct domain *pg_dom) { - bool preserve_ad = (cmd == MMU_PT_UPDATE_PRESERVE_AD); l1_pgentry_t ol1e = l1e_read(pl1e); struct domain *pt_dom = pt_vcpu->domain; int rc = 0; @@ -2172,7 +2171,7 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, } /* Translate foreign guest address. */ - if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE && + if ( !(update_flags & PTE_UPDATE_NO_TRANSLATE) && paging_mode_translate(pg_dom) ) { p2m_type_t p2mt; @@ -2213,7 +2212,7 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, if ( !l1e_has_changed(ol1e, nl1e, ~FASTPATH_FLAG_WHITELIST) ) { rc = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, - preserve_ad); + update_flags); if ( page ) put_page(page); return rc ? 0 : -EBUSY; @@ -2237,7 +2236,7 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, put_page(page); if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, - preserve_ad)) ) + update_flags)) ) { ol1e = nl1e; rc = -EBUSY; @@ -2246,7 +2245,7 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, else if ( pv_l1tf_check_l1e(pt_dom, nl1e) ) return -ERESTART; else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, - preserve_ad)) ) + update_flags)) ) { return -EBUSY; } @@ -2260,7 +2259,7 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, static int mod_l2_entry(l2_pgentry_t *pl2e, l2_pgentry_t nl2e, mfn_t mfn, - int preserve_ad, + unsigned int update_flags, struct vcpu *vcpu) { l2_pgentry_t ol2e; @@ -2292,7 +2291,7 @@ static int mod_l2_entry(l2_pgentry_t *pl2e, /* Fast path for sufficiently-similar mappings. */ if ( !l2e_has_changed(ol2e, nl2e, ~FASTPATH_PDE_FLAG_WHITELIST) ) { - if ( UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, preserve_ad) ) + if ( UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags) ) return 0; return -EBUSY; } @@ -2301,7 +2300,7 @@ static int mod_l2_entry(l2_pgentry_t *pl2e, return rc; if ( unlikely(!UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, - preserve_ad)) ) + update_flags)) ) { ol2e = nl2e; rc = -EBUSY; @@ -2310,7 +2309,7 @@ static int mod_l2_entry(l2_pgentry_t *pl2e, else if ( pv_l1tf_check_l2e(d, nl2e) ) return -ERESTART; else if ( unlikely(!UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, - preserve_ad)) ) + update_flags)) ) { return -EBUSY; } @@ -2324,7 +2323,7 @@ static int mod_l2_entry(l2_pgentry_t *pl2e, static int mod_l3_entry(l3_pgentry_t *pl3e, l3_pgentry_t nl3e, mfn_t mfn, - int preserve_ad, + unsigned int update_flags, struct vcpu *vcpu) { l3_pgentry_t ol3e; @@ -2354,7 +2353,7 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, /* Fast path for sufficiently-similar mappings. */ if ( !l3e_has_changed(ol3e, nl3e, ~FASTPATH_PDE_FLAG_WHITELIST) ) { - rc = UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, preserve_ad); + rc = UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); return rc ? 0 : -EFAULT; } @@ -2364,7 +2363,7 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, rc = 0; if ( unlikely(!UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, - preserve_ad)) ) + update_flags)) ) { ol3e = nl3e; rc = -EFAULT; @@ -2373,7 +2372,7 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, else if ( pv_l1tf_check_l3e(d, nl3e) ) return -ERESTART; else if ( unlikely(!UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, - preserve_ad)) ) + update_flags)) ) { return -EFAULT; } @@ -2386,7 +2385,7 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, static int mod_l4_entry(l4_pgentry_t *pl4e, l4_pgentry_t nl4e, mfn_t mfn, - int preserve_ad, + unsigned int update_flags, struct vcpu *vcpu) { struct domain *d = vcpu->domain; @@ -2416,7 +2415,7 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, /* Fast path for sufficiently-similar mappings. */ if ( !l4e_has_changed(ol4e, nl4e, ~FASTPATH_PDE_FLAG_WHITELIST) ) { - rc = UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, preserve_ad); + rc = UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); return rc ? 0 : -EFAULT; } @@ -2426,7 +2425,7 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, rc = 0; if ( unlikely(!UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, - preserve_ad)) ) + update_flags)) ) { ol4e = nl4e; rc = -EFAULT; @@ -2435,7 +2434,7 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, else if ( pv_l1tf_check_l4e(d, nl4e) ) return -ERESTART; else if ( unlikely(!UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, - preserve_ad)) ) + update_flags)) ) { return -EFAULT; } @@ -4135,18 +4134,23 @@ long do_mmu_update( if ( page_lock(page) ) { + unsigned int update_flags = (cmd == MMU_PT_UPDATE_PRESERVE_AD) + ? PTE_UPDATE_PRESERVE_AD + : (cmd == MMU_PT_UPDATE_NO_TRANSLATE) + ? PTE_UPDATE_NO_TRANSLATE : 0; + switch ( page->u.inuse.type_info & PGT_type_mask ) { case PGT_l1_page_table: rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn, - cmd, v, pg_owner); + update_flags, v, pg_owner); break; case PGT_l2_page_table: if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, - cmd == MMU_PT_UPDATE_PRESERVE_AD, v); + update_flags, v); if ( !rc ) flush_linear_pt = true; break; @@ -4155,7 +4159,7 @@ long do_mmu_update( if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, - cmd == MMU_PT_UPDATE_PRESERVE_AD, v); + update_flags, v); if ( !rc ) flush_linear_pt = true; break; @@ -4164,7 +4168,7 @@ long do_mmu_update( if ( unlikely(pg_owner != pt_owner) ) break; rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, - cmd == MMU_PT_UPDATE_PRESERVE_AD, v); + update_flags, v); if ( !rc ) flush_linear_pt = true; if ( !rc && pt_owner->arch.pv.xpti ) diff --git a/xen/arch/x86/pv/mm.h b/xen/arch/x86/pv/mm.h index 4564cab9fc0f..3aac0f3309a4 100644 --- a/xen/arch/x86/pv/mm.h +++ b/xen/arch/x86/pv/mm.h @@ -62,17 +62,20 @@ static inline intpte_t paging_cmpxchg_guest_entry( #undef PTE_UPDATE_WITH_CMPXCHG #endif +#define PTE_UPDATE_PRESERVE_AD (1u << 0) +#define PTE_UPDATE_NO_TRANSLATE (1u << 1) + /* * How to write an entry to the guest pagetables. * Returns false for failure (pointer not valid), true for success. */ static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new, - mfn_t mfn, struct vcpu *v, bool preserve_ad) + mfn_t mfn, struct vcpu *v, unsigned int flags) { bool rv = true; #ifndef PTE_UPDATE_WITH_CMPXCHG - if ( !preserve_ad ) + if ( !(flags & PTE_UPDATE_PRESERVE_AD) ) paging_write_guest_entry(v, p, new, mfn); else #endif @@ -81,7 +84,7 @@ static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new, { intpte_t _new = new, t; - if ( preserve_ad ) + if ( flags & PTE_UPDATE_PRESERVE_AD ) _new |= old & (_PAGE_ACCESSED | _PAGE_DIRTY); t = paging_cmpxchg_guest_entry(v, p, old, _new, mfn); @@ -102,10 +105,10 @@ static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new, * Macro that wraps the appropriate type-changes around update_intpte(). * Arguments are: type, ptr, old, new, mfn, vcpu */ -#define UPDATE_ENTRY(_t,_p,_o,_n,_m,_v,_ad) \ +#define UPDATE_ENTRY(_t ,_p ,_o ,_n ,_m ,_v , fl) \ update_intpte(&_t ## e_get_intpte(*(_p)), \ _t ## e_get_intpte(_o), _t ## e_get_intpte(_n), \ - (_m), (_v), (_ad)) + _m, _v, fl) static always_inline l1_pgentry_t adjust_guest_l1e(l1_pgentry_t l1e, const struct domain *d) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:29:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:29:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415360.1644813 (Exim 4.92) (envelope-from ) id 1x4lOt-0000YI-6k; Thu, 10 Sep 2026 20:29:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415360.1644813; Thu, 10 Sep 2026 20:29:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOt-0000Y6-3w; Thu, 10 Sep 2026 20:29:39 +0000 Received: by outflank-mailman (input) for mailman id 1415360; Thu, 10 Sep 2026 20:29:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOr-0000Vt-3x for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:29:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lOq-006SS3-0s for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:29:36 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa312e3-2eae-0a2a0a5409dd-0a2a450cabdc-38 for ; Thu, 10 Sep 2026 22:29:36 +0200 Received: from [52.101.193.0] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3132e-f479-0a2a450c0019-3465c10060e3-4 for ; Thu, 10 Sep 2026 22:29:35 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by PH7PR03MB7463.namprd03.prod.outlook.com (2603:10b6:510:2e6::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:29:31 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:29:31 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DPJYtAV14UALF92Xgi0gJSNVL3ZziYwb04t85AVH1PG8mcOGWohLqWF/pagWr7Z0PjEdabd2e/xmChsr83WILuY188Rvttjzisz/mF9j7zP8vUYaM8RVP8G4DHzt9gW+o4LAnddFFcuTTrhuNrddBVkilR8Hvm8KRYBr8pTvyiAvC8cCTJH+rhnTATrRtUCiCKFwftHYBVB/JKyMQ/FOC5fhCpSExrCBVoPng0JNLI7FLaJ0Q7ngXN0eqFDhnCTwtYrKCfEVgmMdlKD6OGHpJmtG3oDcLJccRFsW/o2x7AOyG7F2xtJsOmxf528l757JjeafKFkSKT/VS0K8C//KRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PZTj/1vocxaUbG8pca89bpaode5EiKcz4pQy300Ltjo=; b=pkMG+QO+1pdshCPOAnFm1JJ0RD7EdhMMwwS8Y3gotCMYNr5bAK0k6VkSFB/Wwh5aOi4e2LFlwK92A7z0/JwNW6tp31uKSGtMjHMrqGJTriFw2LqjqKWBJpho0InpoxESipuU6caJlH7QRIzxKNftFJtv/Fw2JXzaa1Mh//ew+znefMiIGikEYJ/YbIafzeT1715ftmkLj0mSPgpK2v14IJNVP+HwQDcVpz9puHmDan6hqMmHimEyhLHR2jVIiGpS8meUEH6GshHCDNqcYKu89cfjQO8Kgvv07yZzKNsJ3pX7Zc3IxMPEcMUQ9vZPl1bRZ6ypcdyLfvDEF1Xvlfst6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PZTj/1vocxaUbG8pca89bpaode5EiKcz4pQy300Ltjo=; b=YqobQ7ZqWoqCCc/71PBr4kHN6JW3iYpg8APUE6iICeRyd2qY3PRBorjIqvCws6gzbsH1V4bS08HLUYKBldoN/6RivYINmUvG/ST+lKCaIaX28Nv6PoYuqmrODheWIhOukJh8m9HiMbFEaRs1MA/Nd/jRIs3iIl9ykaf/+NQ5GpM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v2 2/7] x86: Remove return value from UPDATE_ENTRY Date: Thu, 10 Sep 2026 21:31:08 +0100 Message-ID: <20260910203113.462943-3-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260910203113.462943-1-kevin.lampis@citrix.com> References: <20260910203113.462943-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0171.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18a::14) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|PH7PR03MB7463:EE_ X-MS-Office365-Filtering-Correlation-Id: f04066a6-3645-49fa-29e4-08df0f7a3829 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|10067099003|18002099003|22082099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: OFyBa64dycf5FSiO7xUUZVTwwUgVGVh1n+JcGwixq3jkBws03zkGFZ/q0UHK4VICtfqCDfKcRDFxtXhJFtnwPfTaYZRWvkmQ9GoNJhiHvg0cjtTVH6ochQjIVeg/cTZo9N2QOoD+B+5de+dKITGeIfh1t2E0f2EG1ZnSNtZl2J6kylRGc8qoRmFFtoEp957Zn4zLfmIUy6RvBqTUndD+Db9k1c4Pdxo6KcwbRkGQ7kaoU03WvIFXjKu+eVZP+Cu9kQYjldMmcOk5IAOFBVAhbPIsKqC7acsqaAR/mnGLBS9VwKl0mm0GdoU3GLOjz5oaBxt5vJi7jcxtnNF4CEHO3xJO7zXvy/UyfUqGFr9aom42M+KGlLwUfcK1ahj4WFSQSblny4uwSrq3T6m3szCk8XFeXAH5Q/htos/zNg9sYIvqiRrbQz82HamlFIqkzhCBHv9qRo5EamCMpe5+pMIhUeFHwpMX4Ghe/V4B6T+uYGu1ksbBvDt6S+dKgc2eULBeiLN12v0VSTu8baOeoQA1k67tsPD3N+71yMfx4Sy9QEOhfcLVIPWISuu+aZVPvXICeCJzGYadXvD8CefAzHqJRAoWOIN5k6aMkckQvYLzkOTopL3CkbOVEIgJPzbUv3APHuH2BbZxb0JTIhbzq+f3Icuw8Ei7INH3Vw07Rj70ZVo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(10067099003)(18002099003)(22082099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tow1kS9J+6YSZPvctbuV6qXCJkNxTniXDz4OxQANgjeIpJpWjrzk+7CqNDrQ?= =?us-ascii?Q?Sy/jMFTsV9XF9OwZO4Cvyp0Y3YrlHbAWXadJA4c+HDTBYUC26PWCP1BsszAF?= =?us-ascii?Q?9ovDgP6/70QnqTPyXFycKu/43EytGjunbQubOXuNNaph4MP2IR6fpJkX2eHZ?= =?us-ascii?Q?6h2Wg2jaVWGvNpi2LW5WXSHb54RaETHsOCQ5EJLJJ5T7a2Tr2oXfFitJmwlU?= =?us-ascii?Q?6nOenrjRLlPkY9ktQabInneUqRH0vWpJKbBSmD4CUXAlx7Lw9Qi089mmNg0M?= =?us-ascii?Q?GSBQckD6TdwSAF8HgCOBHDQoZUnc/XJ31zAsp3926ip1CKp5Vk2pcXEzkk1G?= =?us-ascii?Q?sBQL1Ja1Z+oWgUIxmlVjZuv78zjJaL2CVT47smfDY0umNsEb4ZvWfn4GRiHT?= =?us-ascii?Q?Zl2Ky/ICn8xWBHqwtFbS6KT8/f8CCATEXLd/bAtxFyh+LcKkduUyjRHO2ahv?= =?us-ascii?Q?a25xSmbIqeHxhVhkZgk4wB1WVcccCiZkMlHzrUHcTsvo8bfXFkbq7wevh0Kv?= =?us-ascii?Q?XDHWXcDeTv7aPu8ynnCu0iHPh6/AgQdGMpTh6sJ6A3Z4tvSgdbkgRcRQg3kk?= =?us-ascii?Q?BAK1gSzfxqYRBrfvzQ9yckw7pvIBkCZCrQ/TI3wabnFf6/sDnqg6sP9Jyvd8?= =?us-ascii?Q?TNnxsx0PD0QRHKIV0sFWhPYqqZ3v36xyVYbgN/Ud0TILiW+bxtuQkqn0GmZW?= =?us-ascii?Q?ArC2atl0v8LlwFtc+BvNDSosfieRrP+q9+nAWdH5yP7hd9CMTsug4ymS4AUU?= =?us-ascii?Q?HbknjmsH+Spf+DYF+AnhWT3fzubixJOdk97JRvqZXSA4eMtcGWtH9RECw9Lf?= =?us-ascii?Q?FyzP2Lt21x8osX4+9WnXlWHXubv7atrMqqTVnNOc9TBh7hrhC3gmPq0zStZs?= =?us-ascii?Q?Z1d8H/1cX4jbQiEVk1xFELuoRMuWpTqoblbEqte5aDt52y9YrQELtW68B+Ex?= =?us-ascii?Q?dmzdRq21cxhLikTv5oQJNiuZKjJGC/5OhIvpAmpXFKTV3dUHc5ic/E+lWrCQ?= =?us-ascii?Q?jcV1Go6NPa5b+n0hFBcuTX+piHLfQKCCc2U1NfnUUCHiolknLe4lCJ6KYFOe?= =?us-ascii?Q?Rirtr0NT0OJDYkhaiBYWOcqF23kD8xp3UTqkUKrOKNtRsGoUW6V+ki9OMc9Y?= =?us-ascii?Q?Rk7he1LC5IhqZD4jU7xDYkOg3Ncjapt70JPZ2m/J/7Pi5WNSUDapaSz5j/Ap?= =?us-ascii?Q?Owp9I4PElYNVbej3gcYLnj+GyZ4CA8yOk8RhZk72OsO9Js/xpckQ4Ud0CzSp?= =?us-ascii?Q?06LOZXEj9xhlM99Mgps/sdoyLMacYn54jsL52uQVHtwdJq0paqBOOPSnMRVg?= =?us-ascii?Q?FTVysdKNyGTGmdlbLQCLL/DXuwWa8k5oEi8TVy0doFLHxXftLYNKYDCbX6s2?= =?us-ascii?Q?n1HCFrWZs4ZQT9eXXfMPVbmU0J3kQ5RqFNHkqOTxHt7KzBwZM8ZR48lx+aYD?= =?us-ascii?Q?pxBu6PpSRRzR9JRMaTm2A2Ywn+zpcShiDk8kQD3hiYM2qlmPyiOYr5N8S/oH?= =?us-ascii?Q?hoIGMdgfdzxRSeoQuIppAKLhGO8+85X0XU9k2ML9SWjMJQiaicSiH3Zyk+Qp?= =?us-ascii?Q?3zoW5/VsglWhj0ycXoNC80MYm5pKl6N/JpOr+fc+yYr/lXH1Qid71CkVuAXZ?= =?us-ascii?Q?mZQPKhMOuIhS3li9Vr2xXeGWOBOvuA7/5/P2Nt88p8ZdJIVCvmpQLm5k+kzT?= =?us-ascii?Q?vaYB8b86xLyElLgsFPfEH32IW4mT/CvW0lluv8Q7N8b16mF4T1E3og1FA/cz?= =?us-ascii?Q?VHlwwYvtrQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f04066a6-3645-49fa-29e4-08df0f7a3829 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:29:31.3313 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YahzVvmvDQgscT6UzPRHV49JJfoQJSjtOW5+pMVZmbQGC0SacPrbkWeD32CNMMiXq15CWx26Oi4kR5nuspwnQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB7463 X-purgate-ID: tlsNG-d25034/1789072175-774D7A5B-9D31EFF3/0/0 X-purgate-type: clean X-purgate-size: 10387 UPDATE_ENTRY/update_intpte always returns true since 1bc30c076a7f "x86/mm: {paging, sh}_{cmpxchg, write}_guest_entry() cannot fault" Signed-off-by: Kevin Lampis --- Changes in v2: - New patch --- xen/arch/x86/mm.c | 74 +++++++++------------------------ xen/arch/x86/pv/grant_table.c | 53 +++++++++++------------ xen/arch/x86/pv/mm.h | 6 +-- xen/arch/x86/pv/ro-page-fault.c | 3 +- 4 files changed, 46 insertions(+), 90 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 5f778557b1e6..dcbc44f57c54 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2211,11 +2211,10 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, /* Fast path for sufficiently-similar mappings. */ if ( !l1e_has_changed(ol1e, nl1e, ~FASTPATH_FLAG_WHITELIST) ) { - rc = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, - update_flags); + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); if ( page ) put_page(page); - return rc ? 0 : -EBUSY; + return 0; } switch ( rc = get_page_from_l1e(nl1e, pt_dom, pg_dom) ) @@ -2235,20 +2234,12 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, if ( page ) put_page(page); - if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, - update_flags)) ) - { - ol1e = nl1e; - rc = -EBUSY; - } + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); } else if ( pv_l1tf_check_l1e(pt_dom, nl1e) ) return -ERESTART; - else if ( unlikely(!UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, - update_flags)) ) - { - return -EBUSY; - } + else + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); put_page_from_l1e(ol1e, pt_dom); return rc; @@ -2291,28 +2282,19 @@ static int mod_l2_entry(l2_pgentry_t *pl2e, /* Fast path for sufficiently-similar mappings. */ if ( !l2e_has_changed(ol2e, nl2e, ~FASTPATH_PDE_FLAG_WHITELIST) ) { - if ( UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags) ) - return 0; - return -EBUSY; + UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); + return 0; } if ( unlikely((rc = get_page_from_l2e(nl2e, mfn, d, 0)) < 0) ) return rc; - if ( unlikely(!UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, - update_flags)) ) - { - ol2e = nl2e; - rc = -EBUSY; - } + UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); } else if ( pv_l1tf_check_l2e(d, nl2e) ) return -ERESTART; - else if ( unlikely(!UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, - update_flags)) ) - { - return -EBUSY; - } + else + UPDATE_ENTRY(l2, pl2e, ol2e, nl2e, mfn, vcpu, update_flags); put_page_from_l2e(ol2e, mfn, PTF_defer); @@ -2353,8 +2335,8 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, /* Fast path for sufficiently-similar mappings. */ if ( !l3e_has_changed(ol3e, nl3e, ~FASTPATH_PDE_FLAG_WHITELIST) ) { - rc = UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); - return rc ? 0 : -EFAULT; + UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); + return 0; } rc = get_page_from_l3e(nl3e, mfn, d, 0); @@ -2362,20 +2344,12 @@ static int mod_l3_entry(l3_pgentry_t *pl3e, return rc; rc = 0; - if ( unlikely(!UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, - update_flags)) ) - { - ol3e = nl3e; - rc = -EFAULT; - } + UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); } else if ( pv_l1tf_check_l3e(d, nl3e) ) return -ERESTART; - else if ( unlikely(!UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, - update_flags)) ) - { - return -EFAULT; - } + else + UPDATE_ENTRY(l3, pl3e, ol3e, nl3e, mfn, vcpu, update_flags); put_page_from_l3e(ol3e, mfn, PTF_defer); return rc; @@ -2415,8 +2389,8 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, /* Fast path for sufficiently-similar mappings. */ if ( !l4e_has_changed(ol4e, nl4e, ~FASTPATH_PDE_FLAG_WHITELIST) ) { - rc = UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); - return rc ? 0 : -EFAULT; + UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); + return 0; } rc = get_page_from_l4e(nl4e, mfn, d, 0); @@ -2424,20 +2398,12 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, return rc; rc = 0; - if ( unlikely(!UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, - update_flags)) ) - { - ol4e = nl4e; - rc = -EFAULT; - } + UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); } else if ( pv_l1tf_check_l4e(d, nl4e) ) return -ERESTART; - else if ( unlikely(!UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, - update_flags)) ) - { - return -EFAULT; - } + else + UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, update_flags); put_page_from_l4e(ol4e, mfn, PTF_defer); return rc; diff --git a/xen/arch/x86/pv/grant_table.c b/xen/arch/x86/pv/grant_table.c index 1df68440a24a..38767826f5d8 100644 --- a/xen/arch/x86/pv/grant_table.c +++ b/xen/arch/x86/pv/grant_table.c @@ -98,18 +98,16 @@ int create_grant_pv_mapping(uint64_t addr, mfn_t frame, goto out_unlock; ol1e = *pl1e; - if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, curr, 0) ) - { - /* - * We always create mappings in this path. However, our caller, - * map_grant_ref(), only passes potentially non-zero cache_flags for - * MMIO frames, so this path doesn't create non-coherent mappings of - * RAM frames and there's no need to calculate PGT_non_coherent. - */ - ASSERT(!cache_flags || is_iomem_page(frame)); - - rc = GNTST_okay; - } + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, curr, 0); + /* + * We always create mappings in this path. However, our caller, + * map_grant_ref(), only passes potentially non-zero cache_flags for + * MMIO frames, so this path doesn't create non-coherent mappings of + * RAM frames and there's no need to calculate PGT_non_coherent. + */ + ASSERT(!cache_flags || is_iomem_page(frame)); + + rc = GNTST_okay; out_unlock: page_unlock(page); @@ -165,10 +163,9 @@ static bool steal_linear_address(unsigned long linear, l1_pgentry_t *out) goto out_unlock; ol1e = *pl1e; - okay = UPDATE_ENTRY(l1, pl1e, ol1e, l1e_empty(), gl1mfn, curr, 0); - - if ( okay ) - *out = ol1e; + UPDATE_ENTRY(l1, pl1e, ol1e, l1e_empty(), gl1mfn, curr, 0); + *out = ol1e; + okay = true; out_unlock: page_unlock(page); @@ -293,19 +290,17 @@ int replace_grant_pv_mapping(uint64_t addr, mfn_t frame, "PTE flags %x for %"PRIx64" don't match grant (%x)\n", l1e_get_flags(ol1e), addr, grant_pte_flags); - if ( UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, curr, 0) ) - { - /* - * Generally, replace_grant_pv_mapping() is used to destroy mappings - * (n1le = l1e_empty()), but it can be a present mapping on the - * GNTABOP_unmap_and_replace path. - * - * In such cases, the PTE is fully transplanted from its old location - * via steal_linear_addr(), so we need not perform PGT_non_coherent - * checking here. - */ - rc = GNTST_okay; - } + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, curr, 0); + /* + * Generally, replace_grant_pv_mapping() is used to destroy mappings + * (n1le = l1e_empty()), but it can be a present mapping on the + * GNTABOP_unmap_and_replace path. + * + * In such cases, the PTE is fully transplanted from its old location + * via steal_linear_addr(), so we need not perform PGT_non_coherent + * checking here. + */ + rc = GNTST_okay; out_unlock: page_unlock(page); diff --git a/xen/arch/x86/pv/mm.h b/xen/arch/x86/pv/mm.h index 3aac0f3309a4..bfee0feb7b21 100644 --- a/xen/arch/x86/pv/mm.h +++ b/xen/arch/x86/pv/mm.h @@ -67,13 +67,10 @@ static inline intpte_t paging_cmpxchg_guest_entry( /* * How to write an entry to the guest pagetables. - * Returns false for failure (pointer not valid), true for success. */ -static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new, +static inline void update_intpte(intpte_t *p, intpte_t old, intpte_t new, mfn_t mfn, struct vcpu *v, unsigned int flags) { - bool rv = true; - #ifndef PTE_UPDATE_WITH_CMPXCHG if ( !(flags & PTE_UPDATE_PRESERVE_AD) ) paging_write_guest_entry(v, p, new, mfn); @@ -98,7 +95,6 @@ static inline bool update_intpte(intpte_t *p, intpte_t old, intpte_t new, old = t; } } - return rv; } /* diff --git a/xen/arch/x86/pv/ro-page-fault.c b/xen/arch/x86/pv/ro-page-fault.c index d89306d34fc6..6a2e37d4a4ac 100644 --- a/xen/arch/x86/pv/ro-page-fault.c +++ b/xen/arch/x86/pv/ro-page-fault.c @@ -200,8 +200,7 @@ static int ptwr_emulated_update(unsigned long addr, intpte_t *p_old, else { ol1e = *pl1e; - if ( !UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, mfn, v, 0) ) - BUG(); + UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, mfn, v, 0); } trace_ptwr_emulation(addr, nl1e); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:29:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:29:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415361.1644821 (Exim 4.92) (envelope-from ) id 1x4lOz-0000rN-D1; Thu, 10 Sep 2026 20:29:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415361.1644821; Thu, 10 Sep 2026 20:29:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOz-0000rC-A9; Thu, 10 Sep 2026 20:29:45 +0000 Received: by outflank-mailman (input) for mailman id 1415361; Thu, 10 Sep 2026 20:29:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOx-0000oo-C5 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:29:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lOw-001ixY-P6 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:29:42 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa31318-e002-0a2a0a5209dd-0a2a45048eee-38 for ; Thu, 10 Sep 2026 22:29:42 +0200 Received: from [52.101.43.50] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa31334-b57f-0a2a45040019-34652b32efb2-4 for ; Thu, 10 Sep 2026 22:29:42 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV5PR03MB8433.namprd03.prod.outlook.com (2603:10b6:408:361::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:29:38 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:29:36 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aavSg4qCAsn/Ui1ldOXOnXYYDh71ZvX+iKZfqag7gmJZb2QacM5K9OC7+ztFUxAFLAbC1kmupmHRtND1X4zO86rVG6Z/w6GBjxwzFxRh6Xy65Fa4CRMfHjn6eYGB2hiLOYjB03PkLOUMKtJeCdBEfovJ3U5BPsHC8rD4QDab+uLrhJaXTz9gSxVuftkYypVd/CgqxQUGNsJJvPETn/OZaEL34hLbjVTAnbDByBf6cTuuRDYXbNUBbkRARYFytGz110VwsSNrd/Imte2+JtmmCNoP9z5u+KRZW3tkUneGGG8Q+gF3NuSB7Dao8ylL+2HzgxQyV1A2ricKoRjsziJAag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+tOYekDsGmb2RFUH4obI70pViMHgOTrmNkYgsBIQIZY=; b=KJ+QfPpLEVE0KmIMJFBFngOOOYTicXoxGWyNcPxjf80imZBe9ahFacliJT5V3+Xz7y7psHWXKlIpHFm+JRwZYFKIxPyswdtPtznXZ+S2lKbzTNHN9b9msJwu1MdQT6wjofiO/RX3hLjkpU16jhnJ4asnpiMxlj1g/XCb4Bn5oL1cGCNOooZ+5WDb0Yd0gheler0gjsNIQeFcPsaGhwv+DF2TE2Y7/3ZEnuAzz5YsI8J+W79kxQvd3INRNzkOUd+VBrYCCkCncE2bxSrLer+pil6FmqKl/v6ICNlVeTgWs0RsB3bmYQ304+UTJysGDQb2FhNusKzdkN14V5kNIOb6Nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+tOYekDsGmb2RFUH4obI70pViMHgOTrmNkYgsBIQIZY=; b=0DiYdQfZKkECOxUjPrOQPLK3T7eC/ka2oZZDHCk0yOyDVAx8OZH6YJtzcvhEp/I6N5LJ3XMb57WsY+6RlpXvxMB16wn1r0tHteSZc2n4+JWGAizBWRYmSLx5B95nRYUwX96nIE4mFQopG52YEJTF2vtmmQOKUn5vzRzjLrZ3PEE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update Date: Thu, 10 Sep 2026 21:31:09 +0100 Message-ID: <20260910203113.462943-4-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260910203113.462943-1-kevin.lampis@citrix.com> References: <20260910203113.462943-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0087.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:190::20) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV5PR03MB8433:EE_ X-MS-Office365-Filtering-Correlation-Id: 2f496614-f066-4b6f-d123-08df0f7a3b47 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|11063799006|56012099006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: iTS59yWX85vqvXs4cCCZqrTcjReZw/JTccywAJpqIaoQ7dLuHSuI6nV4/QPcWofOCxk1ZX5Yh0tyuNwW6SvvSeqXiMonxZMc4TMnNMKthY250OCxHRGfrI454JCa4cR72a0SnbFBG3u5diRVjDbDrGI4oBivpc3MUaYDDRpnT0prqJO5IF+QCCwlWWN8OJwNee4kY6mmez1Hblitilj7FSeCpxTDMLyvx+lxe+zqyKhr4IneXL6a5FBzGjvRrhW3FeVx0apevmJ3fIKwZVWoRXUCKO2osnCG1eLh4OBgxREuJi056Ud3tStxmT2Xz17zwinJCZIFPUpDBTmSMj7sQRUDrEM73tEwRViHVtQcu33Jj8xdo64B5XxboOCyAZNB1DTfrWN+8FsV8AsJnbrvQmKFjfvXZbUm1GGfnkg+Zr6bM26UbTtBbM2nkkKYHmdfDT/y3EDTq2BtDCEvaunbuk5jR0GBOEsSu5B3WAW1ODHrHlTHI7ToLL7C54HMs3mSXfJuvJjz8o+vEg27S/L4SiexMptH2RgQXYRn6CZWxRQaLK8w8knvyk+rXABG7yEbvphRN4frX1zyBZG/SSKGNpqE85LDjVBUbiL9L5h+AMpxl0kL5BQbCiwSzAL6csalNivAv0hs3m7ASV+ZogDbFX0QgrlrbS1OEBfLwYuTw4E= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?L6k3r6XWuZm26AQYoKiQdAuA06oZhsBFpljYsNtwA4ntJk5i2jsSmYad7Lpn?= =?us-ascii?Q?HwcjkhISm3TsKBitWyrS6zRuSc4yudthlATP2pSXS/VxaQ2v9lRXKYxnCp/E?= =?us-ascii?Q?42Szw6IBD6rg1E/vvkUqAp7r7K/kRZ6qBRJZMelk1XJH6XmJdTMpRCMLCAWO?= =?us-ascii?Q?6dTBc0dUHLmezc/EJ8ws00EfFyXTB/kytS/ZcxdN1KOENtY+NwFPq/49P8DE?= =?us-ascii?Q?w9jC9Sfq9p7H0+7fq3ge4tGqZ/qNAww1zERpxRVviRUi+/VZK13h63ftMUyh?= =?us-ascii?Q?SVFtyd5jwmiwRZWWXKOManN1KKJbI+pmN0RmIsGsQv+575a+BDdS6MTn1m6i?= =?us-ascii?Q?SBN3hBukSl2u7wh+82wAPViF7jQ5D56SqqWMSUv4ddGff9tJhs9xuDZ9amgo?= =?us-ascii?Q?dBMGD0MP7QveyFyI3EyIixzSQ9itE0z+CP9Wqa4FQrjMRBh0zk7ojxw/1QJr?= =?us-ascii?Q?CYHE1Tr0YRT0PDEQ5m/WuTkNShGnA45edq6ftMJ44i3XyjdNlEfxq+DeB2Su?= =?us-ascii?Q?RY0c4Veo24Pi132KRVUX5s7je7h6D1b2gdpnJwBKl2DzyJ/WAZ3pEYwFNLsi?= =?us-ascii?Q?pmEKsKwqLiObXmhk5fm6H2bR7HNUdNXz5Fi8/k58UYRXOzQ/iWMczZchj5ie?= =?us-ascii?Q?8XOlItx7G2/qBMXsJV6m2UVFau/aVqV/ur7XzrlEheX0N9fi9/xUQyx+3hdO?= =?us-ascii?Q?P0oX1GPahU4ChyAA6RBn3NcdZJt+YYEUaPi644OLG0wGjW+OCrFh8oSg/alU?= =?us-ascii?Q?9L3l8TgAdXrwExKCoTc4qH1IxcusP7KDtciTqS6KHx+akdXUCH1cEFR6tg/y?= =?us-ascii?Q?wWjnoQuO1ZXHpvLA/kO9u+tk795eowQs2PgCEq19o04aVup9/ijtS7RTouOJ?= =?us-ascii?Q?GwFUgAXAI5ieiHzYBgOVHurE6mUe1zLnzZqC4DOnxQYyKfK5ygadrnudTsN0?= =?us-ascii?Q?FFAid/JGu0q0LVcwnwSwMC8LTEOV4EDxLrVpGdQ0yPLuXXsfJr2q04Q5HYoC?= =?us-ascii?Q?TaMaBvgTTt6JeRmecIm25gq/jM8Kz0s8oCjFuhEYNLqF5lxVGXrhdsd0fwSG?= =?us-ascii?Q?g7eEI4IdK+2CGLZdxTACvCbtkhMG2lmYtxJXNvOFsjtFrap1ZLEl5NuPY8gt?= =?us-ascii?Q?IUSfZBbZ4J+WbnVW3/vji4AhI+3gcar8KmVZ+CoFEzNIcRsvw1HHtJOE5gth?= =?us-ascii?Q?5F5zW3KCPTX9FPNS/SBYZlB0oBZzxwKL3D9cGbvV0zKMYDt4j8RXydTu1UcS?= =?us-ascii?Q?6v2y7CqAhDlWLApB9VbPuRsbeTIcETQNqHwIQyj45FHFOgmsYlDAJDlAih3a?= =?us-ascii?Q?NoCXVzTdwEvGZnp0jZrokY/178URGrcsCRARPdW0u1PnhwPHM1EcqgBoDH/E?= =?us-ascii?Q?ubwQY34wNrS3XEmxq5EU6sFUqVtgz8r4P2No0/kk1X17wgscafoevgHqaD/1?= =?us-ascii?Q?DOCbCeNObpnAM11wnL1rcN/o2rUTUs3bx1ZVnWky22HZE9GxQXUQZypWB1SD?= =?us-ascii?Q?+9BPb7ZvsTfnBixKvx9j8ADZ+KeP0A4AKfg0mkUKX3yoVhgCTdp8DsdTJEKH?= =?us-ascii?Q?lbQpIIfl6zBhrKtSfPhNYELc+yl/BP1pyr0olyKCuwu7PV+L1JMibsRy3rbS?= =?us-ascii?Q?vkZS9RR030IpQ3zG4ggVN58GjTLcGHnw1gVb3E50t8bFCFjfixJiWgKUqD8C?= =?us-ascii?Q?3JIgYLFXWUbjTVXjGKa6mMlauB0akxleiVnJOTvQDMOga5IJbhNqVLEv54DC?= =?us-ascii?Q?pAcVLHyLmQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f496614-f066-4b6f-d123-08df0f7a3b47 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:29:36.5783 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TdXZPrOZBICOfHzxkejODxYT2tuxYE+lEu1mFrxXwg+yKNqzE88yUmKcreomS238Dl1AG5xgDviCKrqRXHgadA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8433 X-purgate-ID: tlsNG-ebf023/1789072182-C3AC0B50-FE2B843E/0/0 X-purgate-type: clean X-purgate-size: 2341 The update_intpte() now accepts a new swap flag and if set returns the old pte value. No functional change for existing callers. Signed-off-by: Kevin Lampis --- Changes in v2: - Add new PTE_UPDATE_SWAP flag instead of a bool argument - Return the old pte value instead of turning `old` into an out pointer --- xen/arch/x86/pv/mm.h | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/pv/mm.h b/xen/arch/x86/pv/mm.h index bfee0feb7b21..f2bb26aef5b3 100644 --- a/xen/arch/x86/pv/mm.h +++ b/xen/arch/x86/pv/mm.h @@ -64,15 +64,18 @@ static inline intpte_t paging_cmpxchg_guest_entry( #define PTE_UPDATE_PRESERVE_AD (1u << 0) #define PTE_UPDATE_NO_TRANSLATE (1u << 1) +#define PTE_UPDATE_SWAP (1u << 2) /* * How to write an entry to the guest pagetables. + * Returns the old PTE value. */ -static inline void update_intpte(intpte_t *p, intpte_t old, intpte_t new, - mfn_t mfn, struct vcpu *v, unsigned int flags) +static inline intpte_t update_intpte(intpte_t *p, intpte_t old, intpte_t new, + mfn_t mfn, struct vcpu *v, + unsigned int flags) { #ifndef PTE_UPDATE_WITH_CMPXCHG - if ( !(flags & PTE_UPDATE_PRESERVE_AD) ) + if ( !(flags & (PTE_UPDATE_PRESERVE_AD | PTE_UPDATE_SWAP)) ) paging_write_guest_entry(v, p, new, mfn); else #endif @@ -95,15 +98,16 @@ static inline void update_intpte(intpte_t *p, intpte_t old, intpte_t new, old = t; } } + return old; } /* * Macro that wraps the appropriate type-changes around update_intpte(). * Arguments are: type, ptr, old, new, mfn, vcpu */ -#define UPDATE_ENTRY(_t ,_p ,_o ,_n ,_m ,_v , fl) \ - update_intpte(&_t ## e_get_intpte(*(_p)), \ - _t ## e_get_intpte(_o), _t ## e_get_intpte(_n), \ +#define UPDATE_ENTRY(_t ,_p ,_o ,_n ,_m ,_v , fl) \ + update_intpte(&_t ## e_get_intpte(*(_p)), \ + _t ## e_get_intpte(_o), _t ## e_get_intpte(_n), \ _m, _v, fl) static always_inline l1_pgentry_t adjust_guest_l1e(l1_pgentry_t l1e, -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:29:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:29:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415362.1644827 (Exim 4.92) (envelope-from ) id 1x4lOz-0000xw-Rp; Thu, 10 Sep 2026 20:29:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415362.1644827; Thu, 10 Sep 2026 20:29:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOz-0000wr-Ng; Thu, 10 Sep 2026 20:29:45 +0000 Received: by outflank-mailman (input) for mailman id 1415362; Thu, 10 Sep 2026 20:29:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lOy-0000pt-BC for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:29:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lOx-001ixY-NR for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:29:43 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa31318-e002-0a2a0a5209dd-0a2a45048eee-40 for ; Thu, 10 Sep 2026 22:29:43 +0200 Received: from [52.101.43.50] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa31334-b57f-0a2a45040019-34652b32efb2-5 for ; Thu, 10 Sep 2026 22:29:43 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV5PR03MB8433.namprd03.prod.outlook.com (2603:10b6:408:361::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:29:41 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:29:41 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ceBxpU+qmzyTFxqWrmw0ZDlcv2YfwyKl9jAtshhLOf7UJfrDd1WF72FJ04tbpoO8Ld9sXC9YVwOv/c/swmyrjAMwlqmhbg9F+J/d6Wg3lz8khxvgl/Wd0+X1JWAB5vTfaRI9VCs9Mp902Q4xFS0u78zJv/B7sbS8s8EnRAmX6t7On3KEicF77uR1JheFDu9JTS8A4GubSM7Ekqc+JP0ercgZEjCK/2SSpRikvdrVDF6RNuPTuoPQTKnUSMOJj1DNJfj+IZhJ/o4AEBdY4af+ljuNI3ZDu1H0bPNyWLRrWL1uvnl1vbsDgLfdYfN0N0+pgZczxDZ/wq5zLt1jvYc58Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZRMOrcUBuKZGWJ4fSy5SoqfBgF/O6euKv4pLdi6oABw=; b=Ql0IQeIclGCrEsV2RPNJbYTjXT1g43iFNLssc3QqGGzjilwqaTyJlm0JfY2A3D7lnYKtQz42ISa6l5jbGaeeHY+1U3DJ6clDW8AxqhFUfUppWUNvuZ/YrNabZGLM8qKefLvHawzOIPWCqLCVtDFo3cYeIwoLLMtfTCpj2f7fkU1QZKheSUmin783t2swSR7U5imftFEsFVyWUXdMTdi4l/RNhVUSKYpGE5gUsrS+mDKk+DRbRoATrppl/xPrXgxlRIaIOIKSENYNtj+RiTl5FcOxLQ3TMdNu0LWQn62Nf0DmQivBN7iEinZ2J20Uz64TWluYWU9kf0nzBHwLJVMkMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZRMOrcUBuKZGWJ4fSy5SoqfBgF/O6euKv4pLdi6oABw=; b=PBoEr2rEnbvZZdQakJqTTDXUnJCQuaUyq4RFdEzBCH7Q/6n+bzp0Jz22phlU1TylR3VC7FCwvSZFzP62LUnczYPikj1JOXgAfKN4Ke8vopeCNBmCW37gFUCfxVpAMYRDisMD1+tirk8jRAhGW8Zoh9DUGnTvA1ba27EjqGdgyqQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v2 4/7] x86: extend mod_l1_entry() to optionally return the old PTE value Date: Thu, 10 Sep 2026 21:31:10 +0100 Message-ID: <20260910203113.462943-5-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260910203113.462943-1-kevin.lampis@citrix.com> References: <20260910203113.462943-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0079.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:190::12) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV5PR03MB8433:EE_ X-MS-Office365-Filtering-Correlation-Id: 7e6e19c0-dafe-4112-6f52-08df0f7a3e21 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|11063799006|56012099006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: iNRfAir0NI7rQSNTW6zVsZHzr/SbY0vSPnsrpR4Vna4M6ZTfqw9vZKrrBaCU4rNrwmPixdHH50UFmHSy3QRRptsH4JvoyGyESP5JRjRypT0kCuztFQ5nZYJHWovVhsKupUI6VaXzYDpGqkNjJ73+tRC+lev8UvLT/FA3VqQtxauIuSJPXmMYTQW9SImPKSNG8guiyG+9NDqkDO0BpGq+nRCAui8l9xgUOfpXfGbyIci0nuvQHYuBB/45ODlEelkXf0esqrGXdOG1ix+QoCXOFIwHxjiYPBXEGhxQyvmctIYZHnCgx7sm1gCSdV+2sB9aaNnYAjtmggflveZGlw5VbAnuF/dvqA/TTJBoVsLCVo9vbzyd1cizc66Dom2CPtMLeysYcTStAH5iYsqCtL1pPrM/IwFuDjUGIWlSTC2PmJfFGKvSXvIVTqsMIgBY3JajBlsiTRysqFiexITLqYO90bwZmei7AH1WIAOjd3NYzWSSi0WhDuIPMP49kKN1samDgWiZjd38bAgHyLRk6jCEXdcchB4WQZreNuKY7vPmzkz70UjYdWNHSk4EC5Q3NouM1JQgY1ASmaPmoYXVCAYpr47jhfhy+NKRXyJr6cL6xtmoskZjKguqDVSOd5E5rdOGpkW3RcaSt1G84OoYZ1edacH8PTbxHoWQh+yWQiZklOc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2O+S/Vun0/xXYZrOyVIrXO/FX0MUEhnM9kviWv+9LXfOGj042yxr5IBsO9Bo?= =?us-ascii?Q?DSNMFVo1WG8tlYQwkKP+pq7DIjMCn4P6nHUfjWujbD61BGfQklXFuvguXLws?= =?us-ascii?Q?r38ZDI+1GyK0fD/cQ8hQE+mh+4cuy0iBpY2yP8Ong1HABB/Jkisojj1eRknP?= =?us-ascii?Q?nuyaHt5pujcEpTdhlAl9HekWMoiU+imPN99qyz/WPOJ6OqeTP/O7nMr22BGd?= =?us-ascii?Q?3BfP6HthMRSC9OCr52yW0UV2whp/QLTzo0gMUh3Ven/0w9EZU2CY4UOfY0eC?= =?us-ascii?Q?dj1oTSzo2bXc3lmOdtrXDNrRiE35j09pJzi4U6WPygnPQhGL28+ilOYx+rfZ?= =?us-ascii?Q?Z2ZibjVCV4KgRffojPo5XuF7vPGYLdzQtm1wdbqMQLYGZu4p4Lm2+aZMYAw8?= =?us-ascii?Q?sdMCaOcF04PqpLWftYJ4AgLtHENIjjLybzorRGWX6+L/U1NTwSJoYoF30/4r?= =?us-ascii?Q?vQwQzr75FIrqWx43JchiJ0E18pVddJi6ULhVX0SoueON6338rE+0lRRZE5oY?= =?us-ascii?Q?bhG8YgwToB5pzK2anweMGRi6YeKxvmIydxwusj4jLmf2iah3g6lRAcfDi+iH?= =?us-ascii?Q?JWUczo/77OzuVQ94MmVPYiO/cNw3JoShPeG5pLXY1BUfITax/45PK1AgwLHn?= =?us-ascii?Q?/Z3zXwwxh32cBHp+2uHJXN8eXj227JYmNYn13RTDjrX7thXK7k5FJ1jGXbit?= =?us-ascii?Q?ZboBn209yqp2COcwDbF9FmLiOwv/bLr+rQeLHGEnuqNijSJKt+TR3cIU6B9U?= =?us-ascii?Q?+ShaBg4jwVvFInaU3clcaCp3Fc22rM/3jq81ww382Y4VV/l82FFgrRFDotLG?= =?us-ascii?Q?NPBrUxFW8lfSTM+Q1c/X0J/6Kk6kHIS1rHDysIrVDcX5teoAevYc/xZOZJ0z?= =?us-ascii?Q?VbclOXj1KLiMqj7p2b4OSdpPimCJdTh+sX03BLXMBwJj6DS+N/xoZQiNVyDG?= =?us-ascii?Q?R/Vzw8LcQMrigvHi2ItRgxnrGYCj6myK8MH41SVE+YHXYdgu4FLRT1erilIP?= =?us-ascii?Q?i3ygXd5ynG/sSRM/+wSq6Z/uVOYFHKg/T+0MvbxILLI8gnxMc3rZ6b8dN6Vj?= =?us-ascii?Q?yQj3kbukDQVFLRalxhlOhN+wAbZ1d/QUheyNF4T3JgNjW3obpZfXlL4QO4q1?= =?us-ascii?Q?NdzVMA83cQB+G5dD+u1t/4z5KQQ46IuQUat5GQfAJDkYtQDzaqnZPdS1lxwa?= =?us-ascii?Q?C8KCDsc4Oqk4LrPGU3LqY0dFwJuyL+ml8tkVe9K3QPUxbvMU6a+ItbJ5u9Mh?= =?us-ascii?Q?BajyOF52+oUorqR7Qmm7tR/FHVU3y5o87lM4j9JeMAlv32u5dBosKZQjxT9P?= =?us-ascii?Q?EqEmUN1QOWtyfYgDxIaDnwT+xyTpOpf8bmazQuXyOuG26lnu//Taj1vRYyQA?= =?us-ascii?Q?bnZmN7SKWMrW+8n9S/plHGuujAqKgcuAQWbHsw3NasJhTeHRJcgUzfCV7YLF?= =?us-ascii?Q?0DnpXKLceDIfsnd6ajNs1HWTCib9V/bBMxHqmMAixAZbCprOYEY3s1496LTp?= =?us-ascii?Q?GJR9EBVWcCgvIn73f+l9pS0SOH+BU5WXjtAL0A3llMqr2+7/BRedNxEW+VZ5?= =?us-ascii?Q?Fc4Rzt6blYZGuDm1nkzXOqeZE7es+LrnF9wjOeSUCaOAKRniEAMyTxF2LQ9n?= =?us-ascii?Q?YPCrrFSodvhU8/+dGbAn8kIPVudeN2jxUOkIRgxvkRlygt58iA2Ly56Pmkwi?= =?us-ascii?Q?0LjYw9gGsRRWY+KbB3IVFwTJua0uQ8dKrITjuaykHQ6BGm5wSFZjfwSUSk+C?= =?us-ascii?Q?WWGxpM8XaA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e6e19c0-dafe-4112-6f52-08df0f7a3e21 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:29:41.3453 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jJMNS9WapxuYo9knz0E3pfYs67jtqwt25oRq35mvfzXJcCbF6qvDwd60RSxbgbb4wmNiHYunfj5DJCl762C1HQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8433 X-purgate-ID: tlsNG-ebf023/1789072183-C1CD7B50-DC8DEC67/0/0 X-purgate-type: clean X-purgate-size: 3287 Calling mod_l1_entry() with a valid ol1e_out pointer will do an atomic xchg to set the new pte value and return the old pte value through the ol1e_out pointer. If the ol1e_out pointer is NULL then old behavior is preserved. Signed-off-by: Kevin Lampis --- Changes in v2: - UPDATE_ENTRY now returns the old pte value instead of using an out pointer --- xen/arch/x86/mm.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index dcbc44f57c54..59ad5ce16486 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2150,7 +2150,8 @@ static void l3t_unlock(struct page_info *page) /* Update the L1 entry at pl1e to new value nl1e. */ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, mfn_t gl1mfn, unsigned int update_flags, - struct vcpu *pt_vcpu, struct domain *pg_dom) + struct vcpu *pt_vcpu, struct domain *pg_dom, + l1_pgentry_t *ol1e_out) { l1_pgentry_t ol1e = l1e_read(pl1e); struct domain *pt_dom = pt_vcpu->domain; @@ -2211,9 +2212,12 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, /* Fast path for sufficiently-similar mappings. */ if ( !l1e_has_changed(ol1e, nl1e, ~FASTPATH_FLAG_WHITELIST) ) { - UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); + ol1e.l1 = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, + update_flags); if ( page ) put_page(page); + if ( ol1e_out ) + *ol1e_out = ol1e; return 0; } @@ -2234,14 +2238,20 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, if ( page ) put_page(page); - UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); + ol1e.l1 = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, + update_flags); } else if ( pv_l1tf_check_l1e(pt_dom, nl1e) ) return -ERESTART; else - UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, update_flags); + ol1e.l1 = UPDATE_ENTRY(l1, pl1e, ol1e, nl1e, gl1mfn, pt_vcpu, + update_flags); put_page_from_l1e(ol1e, pt_dom); + + if ( !rc && ol1e_out ) + *ol1e_out = ol1e; + return rc; } @@ -4109,7 +4119,7 @@ long do_mmu_update( { case PGT_l1_page_table: rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn, - update_flags, v, pg_owner); + update_flags, v, pg_owner, NULL); break; case PGT_l2_page_table: @@ -4474,7 +4484,8 @@ static int __do_update_va_mapping( goto out; } - rc = mod_l1_entry(pl1e, val, gl1mfn, MMU_NORMAL_PT_UPDATE, v, pg_owner); + rc = mod_l1_entry(pl1e, val, gl1mfn, MMU_NORMAL_PT_UPDATE, v, pg_owner, + NULL); page_unlock(gl1pg); put_page(gl1pg); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:29:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:29:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415367.1644839 (Exim 4.92) (envelope-from ) id 1x4lP6-0001WS-3a; Thu, 10 Sep 2026 20:29:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415367.1644839; Thu, 10 Sep 2026 20:29:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lP6-0001WL-0a; Thu, 10 Sep 2026 20:29:52 +0000 Received: by outflank-mailman (input) for mailman id 1415367; Thu, 10 Sep 2026 20:29:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lP4-0001Pg-9L for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:29:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lP3-009Pyo-MW for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:29:49 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa31323-8faa-0a2a0a5109dd-0a2a4503c878-20 for ; Thu, 10 Sep 2026 22:29:49 +0200 Received: from [52.101.201.11] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3133c-fae8-0a2a45030019-3465c90b4ef2-3 for ; Thu, 10 Sep 2026 22:29:49 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV5PR03MB8433.namprd03.prod.outlook.com (2603:10b6:408:361::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:29:46 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:29:46 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZGcAE1nabQSJCg4idVFZUBIqfvhOVsBKkt0mw2dbi2VGzFpLVrgjY8IN04qL2nMNpYBEBYM1zk6QCRu+ALO0/lNa/HGoBCyAkDOhLTg2KqW7qPum+CjyP6mQn/lNIn7tKpY0E9zcXi0Mjxx3xhEWyMZcGpkPZAD6LVsZZsluJYm8pA6oc2aVT+fDZfQeFXgutvQue78qObY54QDT7RQmVE94AywxxwU4urtUB5OKgU5hPvDattT8iA9fCRplnWHOUZi/wJPguVFV0t9jLN9NiPDBUalfBvGk4tvKFcoWHY0kY1ZZDz4vZCwd4cKFYBcX3OOrvpYOFdv2WH1tMriZqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XeS3HADGVZC3svsA8mdXVt6dTdJRoxy4Cwr2pNlCGck=; b=o0KJ6fyFiK48aM+1qxqdJq1lEQeWHgRpRa7iIyn27owuQDyM+DWZuVe6m09Y3x1EYdFtvSkjvIrX8+QnlSWulIEn3ETnJ3ohn8uPfEirorCFiemYGgSAGNjr7KpbnNtRtlaaBvPoC3wgZG7Tyb4dB1NTSD+AL1+yyS2V2yE5QMdqEMbFCI/5G9tm2Ti9Z2LtkHYlY6/oMbzEOrCErU69tmK/n+7gM3iNkchlf0ZAfvQLitVpTPpoV69JtEg9T1eKl90E9M5eg7NbitJWdT8Z6C1LfCkBMA7/h6q0yW+rAtA4NLAm3W4MTfTpJ9kPCi3zWmvWYLC7aWA47DrAAY7k9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XeS3HADGVZC3svsA8mdXVt6dTdJRoxy4Cwr2pNlCGck=; b=jb2z7wj0uVY1/kjVNoTMBdpCi9eUD/r/x9xGxLHYcBxlojivxh1Lj9IZAFCE7uaDcF9ub1Ls9AAe0Hf2G2UC3QhwHN4h2zm+QNzEJ9cZrrb8e9ySax1lolElCCOdoul2utxgzg0ZwnMEzeydICEn2RKK1GutxdVxt+1dK1s/9Cc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v2 5/7] x86: extend do_mmu_update() to support returning the old PTE value Date: Thu, 10 Sep 2026 21:31:11 +0100 Message-ID: <20260910203113.462943-6-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260910203113.462943-1-kevin.lampis@citrix.com> References: <20260910203113.462943-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0655.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:316::9) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV5PR03MB8433:EE_ X-MS-Office365-Filtering-Correlation-Id: f128ecf8-1af3-4b02-0d5f-08df0f7a4127 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|11063799006|56012099006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 9rtd7mQ58Mm7HtpktbYPOnO4l1wrB8GdjEZhnD0xRoTMvgYwYxQhofPLVSN3Kqw/mWU1OoVjAipVOXNsgtsEXTZZXAnloVNX9lzL3nrbcyHDiKxtVEMmzNn0PBpTtL7CN6PBLQCvBaMeyD0+cUqak78xD6N2T4BfGzapjqsHjxKq5uKjUIqvDCJPeIXDeH61GmGa3LIaWQwHquQhtvLX7QNlePtXm2Cx1ZDyPxj6U/3rOMzokYHkTo2XnfToPTADZaTg4ISStFfLuuLGM9Ct/A9d32eBhyzvGePtjOd0zkZ3CTCYV1ihuz2k2/vPuNf+Q80ee0ko51Ob6TsvA23N/RsbCTYu2dvqMRi2WTYEoYoBxdrjNzTXKJ0mohsLdpuieThrllx+MvlhsExdpf/96qYB/YDn42R6sPl0yZSJ5hPLa0W1i+X8eXlfX+ywNA7MOKIVd+aYZ5e1gv5/xPBUo0Owbr0ARswXrh1lGmHJ/XjJ4c/GuYhKgARns2OtJXAG9TWc6WdUxb/Z4rFyd032tMoCO2l4Zvn1xwEIElWn/jQlXz85Hg33pDLhWgqr27J8QWi9OwmpHJG3jv/6sNggUt2mZ4CM4egqQXwoeV0cUg067OgKIZdsKsKfn6I2miG3fs6YlZhozq31K2HXFQczwQvczBjaq5fos5pOe8s+nww= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?FH8xrQVK5qNUHJOxjjbZViifiWaH1ocEo1SMdAOqSfxEXCu91E8l3ELhHoSC?= =?us-ascii?Q?S/0D3k6oOqgQOselEfnVkBbcrzK7rtsIZdImRsO/XVn/RT1OioZeGAgyf4VF?= =?us-ascii?Q?wt1sA0ka9qZGKjwv4jiUxkchHb5eRdehOe43SafRXvaopcQB+ytgwgLGXYL+?= =?us-ascii?Q?vqxKDwShIfQYQaQDWq6Xh201dt/oprojR5TxZPGAJ7XE8gXRHilprUjqgesk?= =?us-ascii?Q?WpApRc0WjU8vHNbnT01Lek/ABqkEU484/38IQXolC25UEt4bItXbyFmSeqBO?= =?us-ascii?Q?l29FsPdmhfwd9Q66S9jw2Qowo/zE7cJ7ipQmxF+75gtXGCxXx55VolDkr1vI?= =?us-ascii?Q?ut52htYZH2Yc+rx/nW/YCfhUZMT5bnfR6F3D1a15ljORah2IlGPWNc6IiUNF?= =?us-ascii?Q?PkLO+dS+75EyCAN3MADHZc9gX0VGMhOxVRGI2TJVbe9snDfynXYmLbHF/7Tz?= =?us-ascii?Q?ugxM3bemZlsLJTnOkac9XdBzVSKYInuFAzrIgjj6FpxrhxNAc53V7udOl2xw?= =?us-ascii?Q?fav50RuhKSztYdt5HdibPxTrvEsyFb2QaMd3DfhsoBeeOUh2xdAuEjX0kCdg?= =?us-ascii?Q?Gn5GYhq9ZaVc66iPOgthXLhdmMZmfDwvkVcS6RdUP5HW/sIARDlYjlS5Xu8X?= =?us-ascii?Q?J6vriapIDpX0se9UWuJksA5RsFYxRqm/NWy+aQiKrF7VQ92G8DafgsaQAsBK?= =?us-ascii?Q?1E0kwl2w5WoA3IvYVExnmiVoMx94SWWJ6kRp4MsyuYE3osYw65XpKO49BiLZ?= =?us-ascii?Q?5hQpPecMSJqEi0UsCN76NiMDqWFXEelHzMRKN63lkSfL4deqYZB5F5MJX20a?= =?us-ascii?Q?oX78gPu/gbViajrgvYCxv5QxCO+3Rbqz9PALHLCGjDHTx6mhxEJ3kZ5kjNUZ?= =?us-ascii?Q?qm9Qf6KE4Vv5FQNjtpbd6zL1qbd9asqnoDJQK4jR1zv3bS1GBZDjdXyq3t6Z?= =?us-ascii?Q?nux/DD/Nwvt822zCmy6TRr4/ARF3qNYDSJjpj6zvszcuKE+cpq1m1ix1pvMK?= =?us-ascii?Q?gdFuebhpKtOnDQwJv7kBlFjg9tSP6eJo7z3uszRJhKPOg6nzOnKKbD8aprrW?= =?us-ascii?Q?SHd6OGjRdZNkNJoj24dw+DUgLEd8+GTAzDgTNJb68Hk1xER5di2GhTHGJfDJ?= =?us-ascii?Q?mgbrHpGyez7vVKkg4CyYy9QbIuMBXBykYi5lsjYzX2J2FiUwg3IV+1D6zsav?= =?us-ascii?Q?ncox5MyadWrIEvgdGHyfLHBAa4An8tOkSq6u+OIzSkHjCv9LxSfU+j/2MijZ?= =?us-ascii?Q?SBYIT6KuK1tJv4o+MbVK+9floEaxbRsUneqJBVJjtdivUp+iDkbkavfv5gyY?= =?us-ascii?Q?LsGX6TlQ6bHVrZjjQBbXVRvF7QdGxV3v920biWAnCQ5W1FuWG3uyQX1M+UCp?= =?us-ascii?Q?c/qv2VdLMJTwj5h9E0MIYqiz+mkOkpgbNxNshpGXXl2/sjVmt4mlPo3PHa0l?= =?us-ascii?Q?4M5XM8UdCqpyXTw6EgtOhvPUG9VaK9e2TH1nHu8HCEPuTZXd4efaEKijHR6o?= =?us-ascii?Q?wMAxeZoCEG47wOOAfG+HvP+bfmjl/KCeSPEVBxmoxTkEx65imGxt+LsNUzts?= =?us-ascii?Q?Qbg+EYQfVAwFHJw1pftt/1hfciVezv79gEf2vsgGjQhN5ORC0CVCXpqrefAj?= =?us-ascii?Q?DUsBXgghPFSP6V8dAkyr5iGedFllKUokX8imylo+7Rdr2em2a2gtEqZ71ARI?= =?us-ascii?Q?/LQXlBsDp1lYlM6Z9G3ldOXp4pja7xdfbjiGi6lgMKeArWbKBxLCnEW1qdKN?= =?us-ascii?Q?IT5qnadxaw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f128ecf8-1af3-4b02-0d5f-08df0f7a4127 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:29:46.4242 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: igLld+7+vgiDunaj5Xte6bHEce/qNZUJKH3ZJEAkChH0VIRbaNzVIsR7hJwmXpGOdD7u2a+oFCAPFsyxQW4Jgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8433 X-purgate-ID: tlsNG-33051d/1789072189-758824E9-068030D2/0/0 X-purgate-type: clean X-purgate-size: 6168 A new sub-op MMU_PT_UPDATE_SWAP when used will do an atomic swap to set the new value and return the old PTE value through the req.val field. - The new PTE value in req.val must be 0, at the moment this is intended for clearing only. - Only l1 PTEs are supported because they are the most frequent and have the biggest performance impact. - The old PTE value is passed back to the guest through the req.val field If MMU_PT_UPDATE_SWAP is not set then the old behavior is preserved do_mmu_update -> mod_l1_entry -> UPDATE_ENTRY -> paging_write_guest_entry The new MMU_PT_UPDATE_SWAP call chain looks like this do_mmu_update -> mod_l1_entry -> UPDATE_ENTRY -> paging_cmpxchg_guest_entry Signed-off-by: Kevin Lampis --- Changes in v2: - Add a sub-op to mmu_update instead of new hypercall - Rename to "swap" instead of "clear", although only `0` is accepted - Remove spurious curly brace from `case PGT_l1_page_table:` - Restructure `case PGT_l1_page_table:` to avoid diff churn - Add missing `MMU_PT_UPDATE_SWAP` check for the second `PGT_writable_page` block (Jan) I decided not to remove the `rc = -EINVAL` lines. Even though `rc` already has this value I think it's more readable like this. Let me know if I misunderstood the issue. --- xen/arch/x86/mm.c | 48 +++++++++++++++++++++++++++++++++++++++- xen/include/public/xen.h | 1 + 2 files changed, 48 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 59ad5ce16486..b498a8460935 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4055,6 +4055,7 @@ long do_mmu_update( case MMU_NORMAL_PT_UPDATE: case MMU_PT_UPDATE_PRESERVE_AD: case MMU_PT_UPDATE_NO_TRANSLATE: + case MMU_PT_UPDATE_SWAP: { p2m_type_t p2mt; @@ -4118,6 +4119,30 @@ long do_mmu_update( switch ( page->u.inuse.type_info & PGT_type_mask ) { case PGT_l1_page_table: + if ( cmd == MMU_PT_UPDATE_SWAP ) + { + l1_pgentry_t ol1e; + + if ( unlikely(req.val != 0) ) + { + rc = -EINVAL; + break; + } + + update_flags |= PTE_UPDATE_SWAP; + + rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn, + update_flags, v, pg_owner, &ol1e); + + if ( !rc ) + { + req.val = ol1e.l1; + if ( unlikely(copy_to_guest(ureqs, &req, 1)) ) + rc = -EFAULT; + } + break; + } + rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn, update_flags, v, pg_owner, NULL); break; @@ -4125,6 +4150,11 @@ long do_mmu_update( case PGT_l2_page_table: if ( unlikely(pg_owner != pt_owner) ) break; + if ( unlikely(cmd == MMU_PT_UPDATE_SWAP) ) + { + rc = -EINVAL; + break; + } rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, update_flags, v); if ( !rc ) @@ -4134,6 +4164,11 @@ long do_mmu_update( case PGT_l3_page_table: if ( unlikely(pg_owner != pt_owner) ) break; + if ( unlikely(cmd == MMU_PT_UPDATE_SWAP) ) + { + rc = -EINVAL; + break; + } rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, update_flags, v); if ( !rc ) @@ -4143,6 +4178,11 @@ long do_mmu_update( case PGT_l4_page_table: if ( unlikely(pg_owner != pt_owner) ) break; + if ( unlikely(cmd == MMU_PT_UPDATE_SWAP) ) + { + rc = -EINVAL; + break; + } rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, update_flags, v); if ( !rc ) @@ -4172,6 +4212,11 @@ long do_mmu_update( break; case PGT_writable_page: + if ( unlikely(cmd == MMU_PT_UPDATE_SWAP) ) + { + rc = -EINVAL; + break; + } perfc_incr(writable_mmu_updates); paging_write_guest_entry(v, va, req.val, mfn); rc = 0; @@ -4181,7 +4226,8 @@ long do_mmu_update( if ( rc == -EINTR ) rc = -ERESTART; } - else if ( get_page_type(page, PGT_writable_page) ) + else if ( likely(cmd != MMU_PT_UPDATE_SWAP) && + get_page_type(page, PGT_writable_page) ) { perfc_incr(writable_mmu_updates); paging_write_guest_entry(v, va, req.val, mfn); diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 2149b8dd3808..559190688a1e 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -349,6 +349,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); #define MMU_PT_UPDATE_PRESERVE_AD 2 /* atomically: *ptr = val | (*ptr&(A|D)) */ #define MMU_PT_UPDATE_NO_TRANSLATE 3 /* checked '*ptr = val'. ptr is MA. */ /* val never translated. */ +#define MMU_PT_UPDATE_SWAP 4 /* * MMU EXTENDED OPERATIONS -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:29:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:29:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415370.1644849 (Exim 4.92) (envelope-from ) id 1x4lPA-0001rH-DI; Thu, 10 Sep 2026 20:29:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415370.1644849; Thu, 10 Sep 2026 20:29:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lPA-0001r5-8e; Thu, 10 Sep 2026 20:29:56 +0000 Received: by outflank-mailman (input) for mailman id 1415370; Thu, 10 Sep 2026 20:29:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lP8-0001ng-VA for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:29:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lP8-001ixY-Bo for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:29:54 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa31318-e002-0a2a0a5209dd-0a2a45048eee-46 for ; Thu, 10 Sep 2026 22:29:54 +0200 Received: from [52.101.201.42] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa31340-b57f-0a2a45040019-3465c92a4222-3 for ; Thu, 10 Sep 2026 22:29:54 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV5PR03MB8433.namprd03.prod.outlook.com (2603:10b6:408:361::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:29:51 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:29:51 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tSbCM71foQNn+INJrfRstGgCUbLAQJW5sutXH33wppMhs4K1bbBCOXmoJmZEluQpxrOO6BBa3eDtVuo+NGxssssUUldOH7PNg3gyuZpUyPQnPSXZM57Rut5h4i0UXBka5/w7TpF1U3o1CiLOgWttsjPla6S/Sot4qLY+84d+Kn5J/tqsQ0Oq4Dc/jWBshRQC3WyndPp7xXLB5JQBXWsMq8xZ+RoMWz5OSdmjczyTb2Ji/rUfk5ZiYLujZBXwLIUFj31L8mffKXtgNtRMCKNeINXpsoIhU+PQ9G78BpY078Mr0hCbLUNbC5gt1RPw9z8N0J4ethL8EDiQLS2FqXcRQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SGru9pf2RpibDMFcJrBFNb+rJC6hAox/YLh0z7EKIL4=; b=ms5hbDcYba274pAx31g867NhUFcsGgdFOOTCH8Ts3IOS948/y385iKjZ2vc4NM+zUwk8RbPMXBRpzm/tF0Qd2TKgOUf1r41FMDL5MHosplmBtlauEnV2fJ/6+Hs9EUH6dNdNq63m25BdPRmoEL1TOtBrakfA2e5l7bm1DGxqEPXFLU6BsDWwhoOVQy83NmiCkHF/HtB/yJEyq2/lmtmD9AgJ87fDL5nFXjT7pWux+YtPCCRBFfe5y3ISC4YPSlFOLtqGvxpSrcE0pZWQU53f5THaBCqK7cg0siayzBE+ofDlzsm8SyUbFrlW5NxZf+8ba7UbYw3gC6aJeY24yvPRIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SGru9pf2RpibDMFcJrBFNb+rJC6hAox/YLh0z7EKIL4=; b=KZofkVw1oSEt3eFdx77QRyYWSdKJvg/LS/Q+qOCuOgL9NOjXOSxBniGaSlQ1HfWSUYDD9lycIY58Ws6aoU8/oesKHnuhJFGdTuAmRTE423pTwna6O1Zr4lx/LmigzgK+HXXATbi+tqWRzMk+KUUztCvERICHKVxZReyqtUqiPoI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH v2 6/7] x86: New feature flag XENFEAT_mmu_pt_update_swap. Date: Thu, 10 Sep 2026 21:31:12 +0100 Message-ID: <20260910203113.462943-7-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260910203113.462943-1-kevin.lampis@citrix.com> References: <20260910203113.462943-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0669.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:316::19) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV5PR03MB8433:EE_ X-MS-Office365-Filtering-Correlation-Id: 3a015b00-fa12-45bc-3853-08df0f7a442f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|11063799006|56012099006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: SbCapKSucEV6AMu/a7bXjOmBH8VPO9ymfoRfJqQ9wfqawSDHiX5qBDLD/qIfsxDUlqdpAlJ3VT8oiRzUXYTd9eEvmmSdnr//TWzUovDNvqg0Akipugwo136YNb0drwg2xlWfG1kCEZ3z2SI20rbnWoHc+Djfuwe21F7ih5Fr0rPiibHo1ZlY6mhnTFx7m2eHSJJluK6m3UetAiXx9rW03Gv0hGfJCbQ4EAyyxjymNf4T3UanFfd0EDsmj9cWE3AL4h5i0WA1gm/nwD/Q65V7uFC0N/AB4CmV8x0yDP7fqCTAv/NmFon8UWjeDcaQVy7j8bF2lDhYVr7a70pxdANSnwLQazAM2WEBvdHpJblr6jAp2Z0Y0NHGHzrjn7A4Gffcyfrnlzyk65OhNGQ5PzxyZJ3ytnKS3RKDiHCzrT8exe8G8/9gdKUbGkmIXfg8K7cV8z5HWC6ZjKl7AkwTA4FgfsZsqdIULFqowa3NtCsqpt3gJAPnxKjW5nqp/tE19khKqxxgSDypf7mN7dNGgtW7Vxz02JeyycBZYVKxfKRCm6lPpuV/R0sPk4r4b9IWA20ckI9jfrKAm3pPhJ/C41eLWysu/S2fVPFtuj7s6ZNueCRLw6UWbdqWdlkJ13sIc6I8XOU95q1xNICYM+l+2/xMZ1tyE4PElHeJy855wXhcZl0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?JnqaALAbwO2+BR8Vprylf89EfaM2Q6SY05CKDBBui9fhJaWW13IdZ5iVWLkD?= =?us-ascii?Q?TjYTyrtf9wYeFBg3FZIcHEDjh2P0oq6lxflF6TN7pDSSRp7sRNh+j1Qpa6hr?= =?us-ascii?Q?6CdI2fISdvycugkz4dxPQIVj1YuyDBc45bsnflBOj159hVyNAFGb2Ltnj7Ds?= =?us-ascii?Q?RXxpBXrs8mopLsRdHOKbXUhYCrC3i9vte832eeej/z3aSI9iRe1gFqKMdgng?= =?us-ascii?Q?v7TzgxUdMtbkUwGOkn3XUmGZOkMQFi4fTRPVA5CrEJfKuLOUQyWB0e1Xo8wk?= =?us-ascii?Q?AqMt6U4wvVyePGWeIf++6DJwi+ChdvzTqIEfqnr3ei7zUcYv86gcAOD9p8rX?= =?us-ascii?Q?QdBp+IedMLNyUrp4uznF+eUQXnc/y6olMjHvASFG7+rcZJUaYqoC61ze2qNS?= =?us-ascii?Q?t0qy9AW5kT1vkm38G9bGhb7G/9OoXjy8Xmcc6s1Hoyh0+rBXyK1hTynTr+t0?= =?us-ascii?Q?mqTq+P4HVyJOJu/zor1drwo5Iyb8MDknR0/KAXJWjO4ZgPatwCf/i7+Gq+/b?= =?us-ascii?Q?RRZOufipNQVNhwHM0NGvoRPDI4I28qKBD6fEjxzmfmt9gjoEb4K4oH8LEWpE?= =?us-ascii?Q?qW3UZNBkjYjBfcpeyuIoTa7/YjlbmVEjSxdEpgP2gmN3MDzr/iPsEtxD+UvM?= =?us-ascii?Q?1Ndr8SWnoejVMQ6vLwe4bXtOEIpdK60Y7LoRyyyQIdRAayFRj9OFMH0zqIun?= =?us-ascii?Q?8uRnnTrw58KJWBpxRggnwioMvjAHcvw1WemiVaWrSh7IAgt3bQZoIoJTnRrF?= =?us-ascii?Q?UlUF4dObcsjGSzd6CleRnVjR0abWJWxx1gtv3MV9E7nKvRDlkJpV82tRKc8F?= =?us-ascii?Q?DPSsnTwPH0VyOJ+Giqz4bHGNjtHoqR8RlSCVSi5hfzT7pYXFfCiyQEBYGfkH?= =?us-ascii?Q?kyhNAUxxfizxfmWOSvWt+XCLdO2y78PKrXZlMOCsHEF1CGiEIJYnx1UXt/MJ?= =?us-ascii?Q?2f7/kgxweWh8w64YNJ8w5vrEnSFSfP1Xko0n94n6EqvasZiy77Z6bCOAAgcy?= =?us-ascii?Q?PWdIv8IWOcRA6DnnN0W6jNI9MYjnhvo74RF3hOq3KjmSawVFRlD3ir04WUSc?= =?us-ascii?Q?Y4fe5I+wePD3RcCvyIr2zbvxixlr4zOq5mVY0JDioV/JNOgB7zjesM7mRAo+?= =?us-ascii?Q?l3+7dPJFAakw4qLVg5Kji2l0CNFUKjb+KTvsqHi/6vEwExvWybxowWg7wkkm?= =?us-ascii?Q?76nuhZQNd1W9mVyTlAM24e3/od9vou4ljM3PrehM8kGybb0Q62LJj7bDRorD?= =?us-ascii?Q?qGqaFJMSWP4oz/hUvGZSoSxPUNfXEL4MfL0CqKek2vU56uZK5U2IPgCCZHv/?= =?us-ascii?Q?6BzotawqTJAUW+QUzZyUY3k6MLxOhjI2c3VPEFFoTKyPDqV2GU7gatiRuWvS?= =?us-ascii?Q?yml0PvC6Xy6vICu7Ipv0RbmFh8en4LMRyBsBsVqvJJZrHJ7wYl7evEvumXEg?= =?us-ascii?Q?7zZTKMyIXip3b2lqkQfyuBlrT+xEy2vqDbo0kxGoMfsbM3H/8SlkOzZmc8Fr?= =?us-ascii?Q?qQK5Es1/NedRg2kyeN0Uui7DGljBkfOKR5Sp4nIHqTQhBSA+bLHft520QJW5?= =?us-ascii?Q?CO80mp13Baq4JnMzAd35ksBA/tFEaYF3svQ/HOSbFKqzFRy6TocOJ/DN3Cjc?= =?us-ascii?Q?wqyTTi8BJeVJS2nDG/ceePe6Hiq7yRII6tAHdoHSfI4QiQ/tYFw4wzjcyohS?= =?us-ascii?Q?SCY9LSlQJ+KUh146xDhNPLqRHWr3IczBsfoZwz3EOkfLHDbKEOAjCKNJ5dh5?= =?us-ascii?Q?MFoZT00Rxg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a015b00-fa12-45bc-3853-08df0f7a442f X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:29:51.4963 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PppaHaoPwR5q/qfDVl3XbQBQudQY+DGX+qVGn9hsBMm6kkseuiZFMeTd28haYZIaJgCDUvDeMBZG6nSF8QKcOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8433 X-purgate-ID: tlsNG-ebf023/1789072194-C28C9B50-265DBC0C/0/0 X-purgate-type: clean X-purgate-size: 1380 Signed-off-by: Kevin Lampis --- Changes in v2: - New patch --- xen/common/kernel.c | 3 ++- xen/include/public/features.h | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/xen/common/kernel.c b/xen/common/kernel.c index f4bbd8818fa8..fa335803478e 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -690,7 +690,8 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) #endif #ifdef CONFIG_X86 if ( is_pv_domain(d) ) - fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) | + fi.submap |= (1U << XENFEAT_mmu_pt_update_swap) | + (1U << XENFEAT_mmu_pt_update_preserve_ad) | (1U << XENFEAT_highmem_assist) | (1U << XENFEAT_gnttab_map_avail_bits); else diff --git a/xen/include/public/features.h b/xen/include/public/features.h index 880193094713..227f1e408e41 100644 --- a/xen/include/public/features.h +++ b/xen/include/public/features.h @@ -128,6 +128,9 @@ */ #define XENFEAT_dm_msix_all_writes 20 +/* x86: Does this Xen host support the MMU_PT_UPDATE_SWAP hypercall? */ +#define XENFEAT_mmu_pt_update_swap 21 + #define XENFEAT_NR_SUBMAPS 1 #endif /* __XEN_PUBLIC_FEATURES_H__ */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:30:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:30:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415376.1644857 (Exim 4.92) (envelope-from ) id 1x4lPF-0002SF-Pk; Thu, 10 Sep 2026 20:30:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415376.1644857; Thu, 10 Sep 2026 20:30:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lPF-0002Ri-Mq; Thu, 10 Sep 2026 20:30:01 +0000 Received: by outflank-mailman (input) for mailman id 1415376; Thu, 10 Sep 2026 20:30:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lPE-0002HX-Hw for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:30:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lPD-006SZZ-V3 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:29:59 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa31345-2eae-0a2a0a5409dd-0a2a4505e0be-2 for ; Thu, 10 Sep 2026 22:29:59 +0200 Received: from [52.101.56.50] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa31346-4cb1-0a2a45050019-34653832fc39-3 for ; Thu, 10 Sep 2026 22:29:59 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV5PR03MB8433.namprd03.prod.outlook.com (2603:10b6:408:361::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:29:57 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:29:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bKC94Srzw1AoPGmqOdeXvkjWysVY6psH/MAZ5w6VE/uk8v71JBwdKupWB82daO67fFp5fzl9G6Rd0isclz78S+8wushKdTnlQs7s21jhL5oQH7pu1CalbAuE1CmEjySr55VOVNWZ5zTrouSgGRFysqHnCZtuk6y7lFwBKMGAmyMplqT2t93/UvpsZV4eUb6U0rMsjWdMTrLoO04M7Av0kLSPBmCcPekTMT8UuRnHi5iPf+x5WaljOtC4Ah/xJlZSPh90GooNfgT1xAKn/IveET4P436TlC1rGQ8Qdr2eEnzJEghG2kskiAR2X6kA4VUACwS8etB2goOfyedG2PfD6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=n6mEgrZ/yEkYJ75Fx6a0pe4gKbItEtZTaCIBuU3TM7Y=; b=TZhtRmykXtvn24ouGzR9Z3wc3UJJ4FuQxQhM0cqq2Jqrc301FJofPxccCLEXrOktzVTE4x7+fKyrhocMrvnPxZsIL4HibJ002L69cZr3WPCP5tA3RJq8wnYMkl1npdxvwierZJ01912BSsiSqB4xXsuqggvDF/dy/3UxqNXMcCrVKoEfNC122XbSbP1Ix++vhFrjyTMyndHDb17+l7SRZtfZ+ahlfihVZ+JqrXbet9I29nSbLciiFsegfWC5c6XTFQyWx4ZNQqqeF9PfOodtg95Icv83xfNuWN0uXprQf6ulnjM1v8OcgPhIjLDkL5TQUq6P8pzpTmx65M4s0nNlgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n6mEgrZ/yEkYJ75Fx6a0pe4gKbItEtZTaCIBuU3TM7Y=; b=K5yEjza8GjlIBEA/SrE9uU96P+xJramz64u/15yO4ZD6bJNGzApqHIXQy50vp2kKLca3nm5zkhH3Gw4BuFggAW3xZ/f9crrWRMjBi9dB13+ryMyZyWByxWY/B2Xn6OvRb4VApNkB7EDlwKScr9mDiF7JvA7X7woUzN8ovCyTrLA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, teddy.astie@vates.tech, Kevin Lampis Subject: [PATCH Linux v2 7/7] xen: Add new Xen pv-op pte_get_and_clear. Date: Thu, 10 Sep 2026 21:31:13 +0100 Message-ID: <20260910203113.462943-8-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260910203113.462943-1-kevin.lampis@citrix.com> References: <20260910203113.462943-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0167.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:312::12) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|LV5PR03MB8433:EE_ X-MS-Office365-Filtering-Correlation-Id: 02f17a03-2677-4f79-5783-08df0f7a4719 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|6133799003|11063799006|56012099006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: JyYQJywcx6klSWBpazNCp1YVKzzFszsL+sdFYMu7hfG2VREVt3n/5CBSMNLiG2N1ebySm+oklqtBB+3nQuQOo3ZCz7r9m/xlaPd8YHfiXc5sbBbm7KOmPxPfb6N4w+GXYJW4I6EgDF+jLQSBaZKyKzQV3DRcGrAz+MevwBuEZRwk01sajdPX3zjjbNDNiUhZIrdcVYiJu6M9VDhvIXB6wBeeeEOThwQ5fZFNsPQXXY5LM/SQB9ZvqL4CsE5FumLfhwXwawhsqheJZbM3RHtofWGTfKG0ZYqd5bq5YQy6FxydvmI6PyS8opLX6/fOtcuvOnYQpp3DI/G/K3p7w23HYayq02sk34PDBZk1J/z62Qi5svuQKUqJdCQ+VSx1vBYex6ZTirGh9Z6cbYhNuaiOQhNrM99+Hi2/BEZkvCCFMwSN1e12V0eGcNeauO+b1ys7QiIeceZKht2bBjA4jr/ZADyJaCfLclSReo6kfFg4ZcyhzfTp1JsGyscqu1Ai4Odfe8WfZgKV/69d0/k/5XIRxT6oNfkyfZUNFAb3+F6XzcGiq9r8CyuIIFfamRGgF2G70F9PnYZBkJ5SN3MTIo1SDL0ZD3HWQX+k9Xbh2Yoz9Y41D8U2rA5rQEknlAoGGH3FsTgDx6j/Vu3olK4PNaPJZ+eyYEbV5Liw2S8JUeKxiPk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(6133799003)(11063799006)(56012099006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?QN+w0xPzOQmcy9p3iq80TnBv4xbfJ6JMlhG9x7giPo3ID0oaA4cqpOX5C/lx?= =?us-ascii?Q?XdND49GTY98y8wZFMzY1LzxZ1Di60y8hN3XYggqMX7nAOTf10jGGxMGhk3xS?= =?us-ascii?Q?NsEW31hxEuyzEjUyNbSyEALvLyT8APKpeqmNoJpOXeSYeuaX4gvJS2xx6ZwW?= =?us-ascii?Q?xkRfgko6Pss4MhxFe5wQDS9f8CQZ6CvIxODIXo8zz3V4v281Vg6XPmeF4h+8?= =?us-ascii?Q?Fr5MPYaUi2OJFNk/xPrh9Fn+li/UnkH6Fx7IWLfyJgtaei6byf3LoQpZZEdu?= =?us-ascii?Q?r7uWeeYF+AkhvfqN8EQJH6jhneMXu07bbCOGa3szo6VMvu2lffv2/jNMNzYQ?= =?us-ascii?Q?HkA4zZmQSs+abAkcnD8sZRpZDQb1Vd+StCrY0/dsb3F8abC1fvjCVudEFTl5?= =?us-ascii?Q?WOs/fv9st+qWQgy6VfVy4QSwAp0k9ofd2IZ4VlXenO3Nn1vbyYzn0Z+viG78?= =?us-ascii?Q?h3PfF6IBDy+yZAzh3rdEMKgy/oq6xYTqnMca+yfC3oIFxYBK44Hn76VVYvJ4?= =?us-ascii?Q?Arh1KVoAUv518YcDNu9fxtv90kixjEzmSKM6AUpMPwopyQyGg7oCnSdmizEO?= =?us-ascii?Q?TxNO7WxdNtLT06M/pv//7Gh8AJMUFdzvLqsiBgYQUvkQuOGVF1yb6wkv5NYS?= =?us-ascii?Q?1nPF96QJcdukNAY0k9/ASoPnZg8Qbx7BT9+WcHcAPl3jghaQLe01fCfH4+z5?= =?us-ascii?Q?C4Fq1PNYqK/kgfGafKZH4vy5/IuDRUyXsuxeRshsbWY40QlUgWa2TlHzZlhM?= =?us-ascii?Q?TxYvE9UHLHUVmdnPX1DeJ5wBFcpyETcHmFDQiOWfVHrcR/u5LZqV00ar4SL/?= =?us-ascii?Q?p8RMItu3+NbRm5YWBZDLSsvLm+3fCyiXS0lG5CimVGtcnGKOLxdUksbT4R55?= =?us-ascii?Q?Z7zDFhPs56jHFmkd9OGvfaT3nhk1uQCpcBjxV1Jm1ZEmZdyM/XR0hTllpJlO?= =?us-ascii?Q?p8lZiGRT3vymwF9gIb4Mc6Vkcz+If8fKYa/2Wr7CbIq4q2dZdUMtNs1VCUSt?= =?us-ascii?Q?n1X8hzl1yzkFQJ9BforAqRUA2aMw8SgkNTKONzjO5IovNGVNPhQyM2PkiwuU?= =?us-ascii?Q?TPYUdVhgVhy2GGVsohXsYxkWjDu2akRQXzS0SrYAHTuMOJKk9J8LpnoA+yrs?= =?us-ascii?Q?3Ac3avEPBYPfz/z6HGXcj6dLnl9qjTBfRh/IMybF0UF/m2CmnV5fX44talwN?= =?us-ascii?Q?g0EqHjLHRS7cuaH+Wvo+ngE1WjhbfNKnMV+I+4cBwbI2t7V04k9WQnJKolnZ?= =?us-ascii?Q?F+qT6rMbY3dgIueUAgJ74FVYwqhsBat93TdaGR0ww+XbLv3wRlX1j9auQG5g?= =?us-ascii?Q?DU+1MnFFfObWkRUZjbRTw3R7B++cco2HJtVJAvE+PWfhuZYi22Jm5oIJ37ll?= =?us-ascii?Q?7e0/cXX+BQrja6JirUJikin+eZHBiwuc1ZdYib2e4qMVgQbKzWdOF2iZqRrD?= =?us-ascii?Q?GGIxsI2GgFjRuk6LDefnLckTfroTYkW6ANQIbHXYwFqGfCo7UJCK3F3wGtN4?= =?us-ascii?Q?emWbbym2vLJnJU2jFbG9AL1XqoCeHwhPWb9bWgHnHgto+VbXZJwnDpT6Z56o?= =?us-ascii?Q?fwC5RKuEQF/s4vng0A2mSt0+sJtAsRMlnCOMWZegSnDsEUwmrW+5a2/pTv5u?= =?us-ascii?Q?/DiHgY9pwVSm/1bOu4REPUBr/rZu1NQIjrrMntLfbsOBXlZtqwMFyC1LsDgx?= =?us-ascii?Q?vUlJ3rjEyvlAF6hLHS8v9xN3DM654ckHBpfAchozbxr0BZv64sOGWWpM5KC+?= =?us-ascii?Q?6J9wMyHRJg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02f17a03-2677-4f79-5783-08df0f7a4719 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Sep 2026 20:29:56.4005 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SaeDvIkq3oKEf2HJxq5+1hS3uGcvuSnSJfJQPgEwCkJfpbfI3XxGzoAVKv5RnAS1rGy4bSJrOZV2jHlrM1QdiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8433 X-purgate-ID: tlsNG-c201ff/1789072199-F56AD2A1-959B29AF/0/0 X-purgate-type: clean X-purgate-size: 5273 If Xen supports XENFEAT_mmu_pt_update_swap then for performance reasons call mmu_update with the new MMU_PT_UPDATE_SWAP flag instead of native_ptep_get_and_clear(). Signed-off-by: Kevin Lampis --- Changes in v2: - New patch --- arch/x86/include/asm/paravirt.h | 5 +++++ arch/x86/include/asm/paravirt_types.h | 1 + arch/x86/include/asm/pgtable.h | 3 ++- arch/x86/kernel/paravirt.c | 1 + arch/x86/xen/mmu_pv.c | 15 +++++++++++++++ include/xen/interface/features.h | 2 ++ include/xen/interface/xen.h | 1 + 7 files changed, 27 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 0591aa38fd85..0a3a286c46f0 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -373,6 +373,11 @@ static inline void set_pmd(pmd_t *pmdp, pmd_t pmd) PVOP_VCALL2(pv_ops, mmu.set_pmd, pmdp, native_pmd_val(pmd)); } +static inline pte_t pte_get_and_clear(pte_t *ptep) +{ + return (pte_t){PVOP_CALL1(pte_t, mmu.pte_get_and_clear, ptep)}; +} + static inline pmd_t __pmd(pmdval_t val) { return (pmd_t) { PVOP_ALT_CALLEE1(pmdval_t, pv_ops, mmu.make_pmd, val, diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index b4c4a23e77a1..1bd4c19450b5 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -135,6 +135,7 @@ struct pv_mmu_ops { /* Pagetable manipulation functions */ void (*set_pte)(pte_t *ptep, pte_t pteval); void (*set_pmd)(pmd_t *pmdp, pmd_t pmdval); + pte_t (*pte_get_and_clear)(pte_t *ptep); pte_t (*ptep_modify_prot_start)(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep); diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h index ac295ca6c92f..b0d7d6520984 100644 --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -58,6 +58,7 @@ extern pmdval_t early_pmd_flags; #include #else /* !CONFIG_PARAVIRT_XXL */ #define set_pte(ptep, pte) native_set_pte(ptep, pte) +#define pte_get_and_clear(ptep) native_ptep_get_and_clear(ptep) #define set_pte_atomic(ptep, pte) \ native_set_pte_atomic(ptep, pte) @@ -1243,7 +1244,7 @@ bool ptep_clear_flush_young(struct vm_area_struct *vma, static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep) { - pte_t pte = native_ptep_get_and_clear(ptep); ++ pte_t pte = pte_get_and_clear(ptep); page_table_check_pte_clear(mm, addr, pte); return pte; } diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 00b59d774389..58ecd12b10ee 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -178,6 +178,7 @@ struct paravirt_patch_template pv_ops = { .mmu.set_pte = native_set_pte, .mmu.set_pmd = native_set_pmd, + .mmu.pte_get_and_clear = native_ptep_get_and_clear, .mmu.ptep_modify_prot_start = __ptep_modify_prot_start, .mmu.ptep_modify_prot_commit = __ptep_modify_prot_commit, diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 820af6f0aa57..7ce2feab6434 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -359,6 +359,15 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) __xen_set_pte(ptep, pteval); } +static pte_t xen_pte_get_and_clear(pte_t *ptep) +{ + struct mmu_update u; + u.ptr = virt_to_machine(ptep).maddr | MMU_PT_UPDATE_SWAP; + u.val = pte_val_ma(native_make_pte(0)); + HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF); + return native_make_pte(u.val); +} + static pte_t xen_ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep) { @@ -2165,6 +2174,12 @@ static void __init xen_post_allocator_init(void) pv_ops.mmu.set_pud = xen_set_pud; pv_ops.mmu.set_p4d = xen_set_p4d; + if (xen_feature(XENFEAT_mmu_pt_update_swap)) + pv_ops.mmu.pte_get_and_clear = xen_pte_get_and_clear; + else + pv_ops.mmu.pte_get_and_clear = native_ptep_get_and_clear; + + /* This will work as long as patching hasn't happened yet (which it hasn't) */ pv_ops.mmu.alloc_pte = xen_alloc_pte; diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h index 53f760378e39..b346d58c0a41 100644 --- a/include/xen/interface/features.h +++ b/include/xen/interface/features.h @@ -97,6 +97,8 @@ #define XENFEAT_not_direct_mapped 16 #define XENFEAT_direct_mapped 17 +#define XENFEAT_mmu_pt_update_swap 21 + #define XENFEAT_NR_SUBMAPS 1 #endif /* __XEN_PUBLIC_FEATURES_H__ */ diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index 40c9793e9880..92f972e53323 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -252,6 +252,7 @@ #define MMU_MACHPHYS_UPDATE 1 /* ptr = MA of frame to modify entry for */ #define MMU_PT_UPDATE_PRESERVE_AD 2 /* atomically: *ptr = val | (*ptr&(A|D)) */ #define MMU_PT_UPDATE_NO_TRANSLATE 3 /* checked '*ptr = val'. ptr is MA. */ +#define MMU_PT_UPDATE_SWAP 4 /* * MMU EXTENDED OPERATIONS -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 10 20:32:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 20:32:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415427.1644866 (Exim 4.92) (envelope-from ) id 1x4lRD-0004zh-5e; Thu, 10 Sep 2026 20:32:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415427.1644866; Thu, 10 Sep 2026 20:32:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lRD-0004za-2h; Thu, 10 Sep 2026 20:32:03 +0000 Received: by outflank-mailman (input) for mailman id 1415427; Thu, 10 Sep 2026 20:32:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4lRC-0004zT-BK for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 20:32:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4lRB-00792O-J8 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:32:01 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa313b8-8faa-0a2a0a5109dd-0a2a4502df32-36 for ; Thu, 10 Sep 2026 22:32:01 +0200 Received: from [52.101.57.49] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa313c0-6ca4-0a2a45020019-34653931d529-3 for ; Thu, 10 Sep 2026 22:32:01 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by MN6PR03MB7768.namprd03.prod.outlook.com (2603:10b6:208:4f0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 20:31:56 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%6]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 20:31:55 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jBq84HX7s59uSUw9pbyAwqYB0xb6zKCcPqjWJDMVv4blaIWrMlT1s5bhHODJ97JLeccLyjy4bmQ4hPHIntnFsRcu0cbJNsVCjDmAlm794oYxUPy/Xij5d2soZ3AhEEnZ7VYLwv5wnr4KzLbhvzJYjjWhSkEyHNORGMY0Q/y1xRz4Li1+krQG+P0JtW8S6TpjX4YqmxKa31xLIOcL2r8QPhYINHnpPz9CyvslC/AAJpqvtLQzxZBsjsKMTCmUqNeObgRisa/yn7pCQ+S8C79W1VDqBEKxKc9YFV3BWOr8Im4VupOW3XMf0bEXHRBgp4IhD5RSwC05XCaUG8IBwk0bBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wEbDAkEb3nHY3MGtfzlFxQnDkuSHHnm0iH4vRZ7wVhg=; b=lat96BWnPUHQinL6bPWRm1lezFRmBGgxwqYo6wnp5pG+m3qBvCjZtvC6jJGjqwgd/Zy/lp0eoYNxppMYzjuLLQ2Rs45/oN8E69nNMrs+EG83rXP1HRXZ8RRMPalHUbVzeYz9lZCOpdeabNHqMlw9PFSv0xPgAM4CX6ahn5WO7hvKMVPJcg4mByB2NJV23ngCytX1/+ZxTxfywJ2tMt2fWkQTU83+KxK49a4MMgNOLmyKqCp0TD3ZclyoIUzAsLD3dDzqk+yzt6boX2XdBtni9giTSu0Kq+Z8yXEbkDk5pYTHzgx1VY//TGQJpw3oOABOZzyznHn4MlaaSJuzeF54+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wEbDAkEb3nHY3MGtfzlFxQnDkuSHHnm0iH4vRZ7wVhg=; b=XBGR4HCqRNPdIDorX+ILEaiorPQi23Ms5aQyXcfVGJ4wXkem6WVg58f7TMyQOH/pEMJW1OXcuKOLSPtbku5NYlUtilZqAOkgxLD0PFIV5Aef8aQX3gG6Yhme/6rVJJEJ15/8xMNVf0vq0K0++b5wQkyW0ntv9APeht9yH3pkS1A= From: Kevin Lampis To: "xen-devel@lists.xenproject.org" CC: "jbeulich@suse.com" , Andrew Cooper , "teddy.astie@vates.tech" Subject: Re: [PATCH v2 0/7] unmap_page_range optimisation Thread-Topic: [PATCH v2 0/7] unmap_page_range optimisation Thread-Index: AQHdQWKKDMHR64CGkkKXV94EnNSEDbbIQ49z Date: Thu, 10 Sep 2026 20:31:55 +0000 Message-ID: References: <20260910202729.462828-1-kevin.lampis@citrix.com> In-Reply-To: <20260910202729.462828-1-kevin.lampis@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY1PR03MB7996:EE_|MN6PR03MB7768:EE_ x-ms-office365-filtering-correlation-id: f9be0c28-942b-4635-31c8-08df0f7a8e2a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|10067099003|18002099003|22082099003|11063799006|56012099006|38070700021; x-microsoft-antispam-message-info: dHarOKlTqxdTJyE8iThnomkzmDZRI3qKlnh+cEWpO4IeYSZHG9VZhCGZfqUV+n4maDoiI7rAymLXx6WF6vAGMIJvqD+p4w3TFT58uv3L5xzTzPW4Btv6JZVkG0oY9imdjYZtMfzao9dqmbrC0wDWUdjcVQvS1qnzutYBf9TbNkScgFivKuWCQPcsnoBewtZvb8CswYsA7u+HGWFaMjRXoMA/5hYXsxiRn+f3X4/qF9KwXYsgAc/0OBYR7+MTfLVRXXMV9pvsrrRB8VIskFN7cPSaNTXqSYOAl86a/gd3igWqMAftxQuCV8yptZVzMGOVSOnY1sKVhFON9FEmNwQPoD2xC3NKNKh0pHlfJBJOc/WuhDLtl8CK4u58BGpsBVpuOIr80fcKNkwTdfPq/2dEv5u7TfOIM9ZeTSHgumgVOSLLFPJwAC/14LRLamWocQ3rpyzAVYpgqUnykB6jmpI1mx3eD6BM8tGjkmBWV3p8mcONsx6M5MCs+DexsbHPJ3uPysJ93F/o7PL/ltu+kslOjrupp24J4LXkHHEor35tvtGW/xAMWntz6BGoCyJRzCppzVR+v8+6u7xstTx/mExJiCv/4TBvlGYcVwFhZwWhWmh+wWoUgEa2078++5DdpP0IwmeBdSEEYqsNd6e2aPrxXk0mhxejb1LpmcgfoGD9uqqOXFoNq/yT97zNhoB744VRAQuGk12mEindf9bnth9jPj9gxItLDhFaSU9UQ0xjHZY= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(10067099003)(18002099003)(22082099003)(11063799006)(56012099006)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?GfwLMaxoleZCZCdoSO4rAmISYaMWAoXGwONmcT1M8AkBRLQOwPwxHq5KJ2?= =?iso-8859-1?Q?ZbeTRmb7JegsS6Okq4s+uQN7Y3EVRoQI+xIxK2KQnp8oyDMAzgpswcRQZj?= =?iso-8859-1?Q?NDqk6HeURFzIBBQYXcUoorMxHza10upqWwH365OT7RKUmud/fX5gCXiTIp?= =?iso-8859-1?Q?AiRmqQuBdXRiZFTVMOJx4ayZhtuNOeHbuRhZ4kp1bLPDlI5SyGCRkTciUH?= =?iso-8859-1?Q?sSd9GtphbZ+DuyPDxDthwqzJBdBPfkso3I5D/sACspMHg2r001EysG3Xcv?= =?iso-8859-1?Q?iNX7EzzsheFMZKm7saGDPIdMPGQ3mcaIJqN0kmEBTN1qz2n0sEO3LvOwaJ?= =?iso-8859-1?Q?Y4qHG5NQE2mynBEzwGkVVPfmOwh1TlyLjvHPZ8Ajoq1rVKj4npE4jtZsuc?= =?iso-8859-1?Q?KUCdK9uk5dxLm+gbwOSFu9iSPNn75Ni9Fyt5+qIOkmz07XOviIkUeReSQu?= =?iso-8859-1?Q?0q3snMrdfJMlWz9KD3fSDpsDdCuD9PrfUwTeqXQkqdwdOPJ8PH8oUGMB2b?= =?iso-8859-1?Q?DVEcht09r4W99fU/MAlGwfw6yQvZrt3kmY4CX2nhaoZhTA6hyt1DPq/icH?= =?iso-8859-1?Q?f2VqMN/ieQZw/ID9+6pWz9H1wXfw85GXYWIHEcDY+W4MuNoXoTrejnJFat?= =?iso-8859-1?Q?imc54JKa+5anqgww4iPEGfFcAtxNMHczoYtbCHsk/SBllryDwOLRo/VeFM?= =?iso-8859-1?Q?QL6i8Eu6KuVb8yQue8brBwwquG41r25ae5hsOJSVnri16hIRd7Mg9SWI7r?= =?iso-8859-1?Q?nbjW+bZTEqvDj2OILMRZq+d9FLWJHEX01vvtFak2FzD+vg6tRsQJ4YgJdi?= =?iso-8859-1?Q?r8crVOlzrdC6Y/iHwb6vfv5TtOVmUFjh4BdFpjpxhhEfNECaIO5ulacPdI?= =?iso-8859-1?Q?FkS5w1KVeaUckzEhj62AjqK9voirtt0hBrG6uu5gykY7cTWqU/V3twNVTs?= =?iso-8859-1?Q?d96tgY0Tc0nnF01Ba0XVsWCh9mQ52XwQsw2fekcN1URn0eOZ86kRpuwk8s?= =?iso-8859-1?Q?1l14lasFx1dHoHMJztZXSIt4tv/usytzPCpNSkEXTnLG47VQ7bjcx50mzC?= =?iso-8859-1?Q?DGv+G6LlDBek6+lA86SzMdYpbtz9YDClRq2x8F2Nkdt4njifFZBFvOqG6f?= =?iso-8859-1?Q?ORFCwnzlHSuoM2o6NC4j13L32m1r9zwLboP0pyLg4diTOTRYW6QeJiL6mE?= =?iso-8859-1?Q?pzzwzDb/nK2lynw6wQh5o+g9U2oS/pfUEreFn66uQ1QzAntzLcaGA4ajeT?= =?iso-8859-1?Q?V4TAdesityGjQjr96/aWpccBQSYSRhjfm8H4/08YA4/I+oWU/PtN46+R0Q?= =?iso-8859-1?Q?LudquOToGqT5K7mA6VD1pTXB7zXKqlyq6FZYwzPNaNV5tHnKDpGDndgSOo?= =?iso-8859-1?Q?goC11mgiHPfAQkV9BlnhOn41dm/v0sI7sB9tOGMmjvfMzOc0y1TgW4CTWB?= =?iso-8859-1?Q?89JJI2bwID1YxOJEa9X8qmogO+EB2e/849n01XHELbcNLBic1fu7z/7h7w?= =?iso-8859-1?Q?Gg3pX5torKB2nN2qXp1KMuHxbzigIbTim05lX/V0yA8RAdNUSO1b1ThR+H?= =?iso-8859-1?Q?O7MeDjZfFDDF2fAewy8D4a3NMqfH42zdC1i7iPQ9HHazhnS+bPTS8oZvaj?= =?iso-8859-1?Q?opOi0V2m/HdLEwoQM0ngpZJ0cz5Hcpubd0K5ReIj5oJp1FIMfyjLSjGW2t?= =?iso-8859-1?Q?AI4049wPI8vmtYYdXaG/0x0mr9ephRgjW2TWgw4S3IA5b3PXLyVOhRmIL2?= =?iso-8859-1?Q?RvqwI4C9wIomn0C7x8Nz1HeZnwxM3JVmsB5+gTgOmOb/vS?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9be0c28-942b-4635-31c8-08df0f7a8e2a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2026 20:31:55.5064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: r8+AiTAwQaiP7wHHQBV96WAMBl+17BjOvH1Sz+qEETO1z68x8EvbBJwfb9JfLkwL00xuAe8Bw+wgdOrBp3LkRg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7768 X-purgate-ID: tlsNG-720697/1789072321-F2AB52AC-2D3CD40D/0/0 X-purgate-type: clean X-purgate-size: 94 Sorry git send-email stopped in the middle of sending. I sent the v2 patch = series again.= From xen-devel-bounces@lists.xenproject.org Thu Sep 10 23:00:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 10 Sep 2026 23:00:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415521.1644888 (Exim 4.92) (envelope-from ) id 1x4nkK-0007fX-7M; Thu, 10 Sep 2026 22:59:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415521.1644888; Thu, 10 Sep 2026 22:59:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4nkK-0007fQ-4G; Thu, 10 Sep 2026 22:59:56 +0000 Received: by outflank-mailman (input) for mailman id 1415521; Thu, 10 Sep 2026 22:59:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4nkI-0007fF-9Q for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 22:59:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4nkG-003vjn-52 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 00:59:52 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa335f3-2eae-0a2a0a5409dd-0a2a450a9e54-46 for ; Fri, 11 Sep 2026 00:59:52 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa33666-f2d2-0a2a450a0019-aceafc1fc66e-3 for ; Fri, 11 Sep 2026 00:59:51 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id B712C43C48; Thu, 10 Sep 2026 22:59:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8EAED1F000FF; Thu, 10 Sep 2026 22:59:49 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 54E1CCE19CD; Thu, 10 Sep 2026 15:59:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789081189; bh=xz6PHByUgP1AVWjuJD1V+UfaCDrDqHgI9zDHmq+c8Zw=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=hU0ytUBbxQNF/Ko7N4RIPT+JpPrgy8HZNvPMTUrRfxisMxs5GCtiCGdeUFowkvPdK gIqFbvrR4RjOl9bLAeekCSVXFxuJFuWmJdZjFTcs1Drp4EGBGmfsQ6bly0WhLbGsJk YVi2xQANuoU42iGwEFZTYbC3tkBpj/y6afENFzesX5gYoNUgfdpCroQNA3NKNXitbd 95cHu9S6+S8rC+OkT9IXy2r7sLCQ+ukD8hNx7p4T/moocJkTDYjo9NBYlWjNnnRTWR rkZt/TbetwuCw7Ke6a6H2HBqDZ1YQoHH+zwt9DAHhIVGSL3kGJiBBiHt0ZpRENDNG/ 0oc4cpzesfhWg== Date: Thu, 10 Sep 2026 15:59:49 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC 00/13] rcu-tasks: let preemption outside trampolines be a quiescent state Message-ID: Reply-To: paulmck@kernel.org References: <20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com> <20260910154450.7b770882@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260910154450.7b770882@gandalf.local.home> X-purgate-ID: tlsNG-4011c0/1789081192-51AC4CFC-577A9FBF/0/0 X-purgate-type: clean X-purgate-size: 9350 On Thu, Sep 10, 2026 at 03:44:50PM -0400, Steven Rostedt wrote: > On Thu, 10 Sep 2026 18:50:23 +0000 > Josef Bacik wrote: > > > Tasks RCU only treats a voluntary context switch, usermode or idle as a > > quiescent state, because a preempted task may be sitting in a trampoline > > that is about to be freed. That was a fine trade when PREEMPT_NONE > > servers compiled Tasks RCU away and PREEMPT desktops rarely ran > > long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: > > Tasks RCU is now real on server configs, and cond_resched() is a no-op, > > so a CPU-bound kthread or kworker only ever loses the CPU by being > > preempted, which is exactly the event Tasks RCU refuses to count. > > > > The way this showed up for us was a cgroup writeback worker draining a > > very large cgwb for around eleven minutes on an arm64 box. Nothing wrong > > So you have a kernel thread running for 11 minutes without a schedule? We have seen this from time to time here as well. > You could still put in a cond_resched_tasks_rcu_qs() in that loop. But I > guess you are trying to get rid of doing that too. And we have done this a few times, but if this proves to be an acceptable alternative, that would be wonderful. ;-) > > with that on its own, but a BPF program detach on another CPU went > > bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() > > while holding trampoline_mutex, forty-odd tasks piled up behind the > > mutex, and the hung task detector panicked the machine. The kprobe jump > > optimizer is worse in principle: it does synchronize_rcu_tasks() under > > kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running > > kthread can stall static key updates and CPU hotplug for its whole run. > > The current answer is to find each such loop and add > > cond_resched_tasks_rcu_qs() to it, which is the kind of annotation > > PREEMPT_LAZY was supposed to let us stop writing. > > > > This series tries the other direction: have the trampolines say when a > > task is inside them, so that a preemption anywhere else can be a > > quiescent state. > > > > - task_struct grows an int, rcu_tramp_nesting. Every trampoline whose > > lifetime Tasks RCU guards increments it before calling out and > > decrements it before returning: ftrace_caller and its dynamic copies, > > the BPF trampoline (which drops it again around the call to the > > original function, since im->pcref covers that), the x86 optprobe > > template, and out-of-line register_ftrace_direct() trampolines. Only > > current writes it and nested users are balanced, so it is a plain > > non-atomic inc/dec, one load of current plus one RMW per entry/exit. > > > > - The inc/dec are inside the trampoline, so there is a window of a few > > instructions on each side where the count is zero but the task is in > > (or on its way into) trampoline text. Nothing there can be preempted > > synchronously, only from an interrupt, so the irq-exit preemption path > > looks at regs->ip and holds the count across preempt_schedule_irq() > > when the IP is somewhere the counter cannot cover: outside core and > > module text (all the dynamically allocated trampolines and slots), in > > the static ftrace stubs or the x86 return thunks that still hold a > > direct-call target, in a module that hosts its own direct trampoline, > > or inside the bytes after a kprobe that the jump optimizer may be > > about to rewrite (the one synchronize_rcu_tasks() user that is not > > about trampolines at all). > > So basically if the preemption happens outside of core or module text > (which should be the case of any dynamically allocated trampoline), the > task is marked to be in the grace period across its schedule, so that the > RCU_TASK cannot move forward? If I understand correctly, the difference with Josef's patch is that rcu_tasks_classic_qs(current, true), when called without the direct or indirect aid of a trampoline, will provide an RCU Tasks quiescent state. In contrast, without Josef's patch, no call to rcu_tasks_classic_qs(current, true) will provide such a quiescent state. More to the point, because rcu_tasks_classic_qs(current, false) is invoked from rcu_note_context_switch(), any preemption to kernel code not within or called from a trampoline will now provide a quiescent state. Keeping in mind that cond_resched() is treated as a preemption, this change could potentially greatly reduce the need for sprinkling calls to cond_resched_tasks_rcu_qs() throughout the kernel. (Except that the call to cond_resched() has to actually invoke the scheduler for anything to happen.) Which, if it works, would of course be a good thing. ;-) > > - With those in place, rcu_tasks_classic_qs() also clears the holdout > > flag on a preemption when the count is zero, on architectures that > > opt in. x86-64 and arm64 do so here. Everyone else keeps the > > voluntary-only rule and is untouched apart from the (unused) field. > > > > A running holdout already gets poked via rcu_request_urgent_qs_task(), > > which makes the next tick set NEED_RESCHED, so with this the resulting > > preemption retires it and a Tasks RCU grace period is bounded by roughly > > a tick plus the longest preempt-off section rather than by the longest > > stretch without a voluntary schedule(). > > > > Patches 1-12 are scaffolding and change no behaviour on their own; patch > > 13 flips the rule and selects the option for the two architectures. > > > > Testing so far is QEMU only: x86-64, PREEMPT_LAZY with PREEMPT_RCU=n, > > PROVE_RCU and lockdep, with and without PREEMPT_DYNAMIC. A kthread > > spinning in-kernel for 30s with the function tracer, an ftrace kprobe, > > an optimized kprobe and fentry/fexit programs attached: > > synchronize_rcu_tasks() goes from 29.7s to 0.1-0.3s, tearing down a > > DYNAMIC ftrace_ops (tracefs instance function -> nop) from 27s to > > 0.2-0.8s, and the ftrace-direct sample modules load, fire and unload in > > about 2.5s each while the spinner runs, with no warnings and the new > > return-to-user assertion quiet. arm64 is build-tested only at this > > point; real hardware numbers for both are the obvious next step and I > > did not want to sit on the idea waiting for them. > > > > Things I would particularly like opinions on: > > > > - Whether hooking rcu_tasks_classic_qs() is the right place, or whether > > Paul would rather see this expressed differently inside Tasks RCU. We might well need more: o The rcu_tasks_pertask() might need to check to see if task "t" is in a quiescent state. The task_call_func() function might be helpful in safely accessing that task's state remotely in the common case where the task is blocked or preempted. o Given a task that runs for a very long time on a CPU that has nothing else to do (so that cond_resched() does nothing and there are no preemptions), and does so in a code path that never invokes cond_resched_tasks_rcu_qs(), it might be necessary to IPI to CPU that this task is running on. Or to invoke resched_cpu() in order to force a context switch on that CPU, whether it needs one or not. (Which makes the scheduler do the IPI for us.) o PREEMPT_RT kernels might want memory ordering on the nesting count increments and decrements, along with READ_ONCE() and WRITE_ONCE() or similar, in order to avoid the aforementioned IPIs. But this increases overhead, so !PREEMPT_RT kernels would *not* want this. And probably other things that I am not yet seeing. ;-) > > - return_to_handler and the rethook/kretprobe trampolines are not > > instrumented. Their C callees take the ftrace recursion lock before > > touching any ops and the trampolines themselves are static text, so I > > believe they do not need it, but I would like Steven and Masami to > > confirm. > > Note, there has been some work in the past (and may happen again in the > future) that will remove the preempt_disable() from the trace_recursion > locking. If that happens, then I believe the trace_recursion would need to > increment (and decrement) your counter. Probably need a comment there to > let whomever know about it if they decide to remove the preempt_disable(). > > > - The register_ftrace_direct() contract change: out-of-line direct > > trampolines now have to maintain the count themselves (the samples > > are converted). I do not know of out-of-tree users beyond BPF, but > > this is the one place an existing user could be silently weakened. > > - Whether arm64 folks are comfortable with the ldr/add/str in > > ftrace_caller and the BPF trampoline, and with treating all of > > ftrace_caller as trampoline text for the IP check. > > - If this holds up, cond_resched_tasks_rcu_qs() and > > rcu_softirq_qs_periodic() become unnecessary on the opted-in > > architectures; I have not touched them here. > > I don't know. It may work, but I have a feeling there's a devil in the > details here that is waiting to bite us in the underside when we are not > (RCU) watching. Well, that is RCU for you! ;-) Thanx, Paul From xen-devel-bounces@lists.xenproject.org Fri Sep 11 04:39:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 04:39:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415635.1644897 (Exim 4.92) (envelope-from ) id 1x4t2O-0000El-Gr; Fri, 11 Sep 2026 04:38:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415635.1644897; Fri, 11 Sep 2026 04:38:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4t2O-0000Ec-By; Fri, 11 Sep 2026 04:38:56 +0000 Received: by outflank-mailman (input) for mailman id 1415635; Fri, 11 Sep 2026 04:38:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4t2M-0000E3-7P for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 04:38:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4t2J-0079dY-PR for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 06:38:51 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa385a6-bab6-0a2a0a5309dd-0a2a450cae94-48 for ; Fri, 11 Sep 2026 06:38:51 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa385db-f479-0a2a450c0019-416d716c91a6-3 for ; Fri, 11 Sep 2026 06:38:51 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 832BB40E00E8; Fri, 11 Sep 2026 04:38:50 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FpIopqVKuj8D; Fri, 11 Sep 2026 04:38:40 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::3a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id C145240E00B9; Fri, 11 Sep 2026 04:38:25 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1789101520; bh=T7n3csq1h16sUuD8cRvGmtF1Jsj0J38l6tEVY9X+IHw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LUYyefAdcLKDhek0XZZcuEIHjGff5EZZ+pdDbVpsjpKiJgrGEhlw4vGrfG7894cfp il06hXtV41nlJmUXp5cA0dDZzcIn+U8gra4xN0tnCH9O3N5nqRvpgzvIEqHD9C7Eln FUWtayd86Grx3UAeXbnNm145iaS8Csz2VWrddCIPLg5SuUAGAGToudrdjDnKMq2yVj n4Z1fagj7nihG65GNsUTZKpCRxANhM/Ybr9QhGT5zvqzJDLS7BIQh1ssfo28tIubb9 dg9us/aRxXvx1wOHyC7lj89n8MJLzzp1DXI8ZO+oJdZ8sr0l2dMff+UeHxTmISePia 3vFwC2/eDIZvu3dzt9qRVd3c9PKOsc0mVEoungLxLYMuDQlSyom4Nxbgl9m90hc61S Fkh7sQW5cP24QxKB2W8kZ/2ycEOjBRbHJIjisgACjwB2pE3MfncBos48Xagqrr3I/v G39l24Ooqd0YfDzagldTXOIMcD3OcVUYxeewhSl6auATMwZhzkK8h8YIE8BNYuA+Dd 8ciayjcOb+yGStSKydsjaZvnGHdCeNTvdXpDrrtZG1x2dMpSJBMNod18EkeukIjTDt FlA/jChQ8xXi/XysbOVvPITmtBfmfvAw9H3svhYGJ+yIM5EYclc+IgRC1NkORqzdNd dShvl81qRqWMAZv5t0+3dgDc= Date: Thu, 10 Sep 2026 21:38:22 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() Message-ID: <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> X-purgate-ID: tlsNG-d25034/1789101531-020C1A5B-10284FDD/0/0 X-purgate-type: clean X-purgate-size: 2217 On Sat, Aug 22, 2026 at 03:33:20PM -0300, Mauricio Faria de Oliveira wrote: > diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h > index 82eddfa2347b32b76c2ea9b85f005ca5416ac71f..2d9f3d4d63de6e721f275d9e80d372edbdfedf30 100644 > --- a/arch/x86/include/asm/cpuid/api.h > +++ b/arch/x86/include/asm/cpuid/api.h > @@ -204,7 +204,7 @@ static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves) > * from PVH early boot code before instrumentation is set up > * and memcmp() itself may be instrumented. > */ > - if (!__builtin_memcmp(sig, signature, 12) && > + if (!__inline_memcmp(sig, signature, 12) && Dunno, did you not think of simply doing it by foot and save yourself all those gymnastics in patches 1-3? IOW, something like this totally untested thing below: diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h index 2d9f3d4d63de..a2db83d17940 100644 --- a/arch/x86/include/asm/cpuid/api.h +++ b/arch/x86/include/asm/cpuid/api.h @@ -192,9 +192,10 @@ static __always_inline bool cpuid_function_is_indexed(u32 function) #define for_each_possible_cpuid_base_hypervisor(function) \ for (function = 0x40000000; function < 0x40010000; function += 0x100) -static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves) +static inline u32 cpuid_base_hypervisor(const char *__sig, u32 leaves) { u32 base, eax, signature[3]; + u32 *sig = (u32 *)__sig; for_each_possible_cpuid_base_hypervisor(base) { cpuid(base, &eax, &signature[0], &signature[1], &signature[2]); @@ -204,9 +205,12 @@ static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves) * from PVH early boot code before instrumentation is set up * and memcmp() itself may be instrumented. */ - if (!__inline_memcmp(sig, signature, 12) && - (leaves == 0 || ((eax - base) >= leaves))) - return base; + if (sig[0] == signature[0] && + sig[1] == signature[1] && + sig[2] == signature[2]) { + if (leaves == 0 || ((eax - base) >= leaves)) + return base; + } } return 0; -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Fri Sep 11 04:40:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 04:40:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415642.1644905 (Exim 4.92) (envelope-from ) id 1x4t3j-0001if-N6; Fri, 11 Sep 2026 04:40:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415642.1644905; Fri, 11 Sep 2026 04:40:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4t3j-0001iY-KX; Fri, 11 Sep 2026 04:40:19 +0000 Received: by outflank-mailman (input) for mailman id 1415642; Fri, 11 Sep 2026 04:40:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4t3i-0001iF-Ew for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 04:40:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4t3g-007s1M-EC for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 06:40:16 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa385f2-2eae-0a2a0a5409dd-0a2a4503ec4a-42 for ; Fri, 11 Sep 2026 06:40:16 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa38630-fae8-0a2a45030019-416d716ce788-3 for ; Fri, 11 Sep 2026 06:40:16 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id B7CAC40E00E8; Fri, 11 Sep 2026 04:40:15 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id njDzaZ9af6w9; Fri, 11 Sep 2026 04:40:06 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::3a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 5171840E00B8; Fri, 11 Sep 2026 04:39:50 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1789101604; bh=6qo6QIs0b8aAAaNSTcLUnAAWEPHz3aFEX3OTeai0y60=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Q7q3U/MqLnZqz9eauXKGR5jkGJoQi/xsVneN3cpyobRdrDoSZieIYnY5Kczd77/QS QtW0OuJqp+UpOM2b7qA7NV1xgMtrbpezYey5yKCRtFISka3VbmA+gDHJ2BYxYKYZak +YkuPDvyFQwH2IzESFjNzr/Vw0M+v3EZN4ggIA/R0/j/6hGtAeh1spO/Ll5aLdWoAb RiT3/XxrrFYIl6f5osJRwfV7Oad/wV6+xGO3AfZKqBD7t+jFL5uxietxLquGSpCCxG HlBCvN7rBSTXeB13qllYR/k+GjLH41zoQetUNUrV78FZeqap62y093w9mUkAtnknen zxL/vsCndurZTjncKxdKajbHdAK3SEq68Kn7g3YJbTt+oGPuWegSjC+K/zZzjViwZ2 Vjas1VTohdoOfbDzgt9AXegkjm4cOcHyadroTDj3/0wFaeMQLgAEqJlHrdsYkuy1XH Hyl2A2EqO//Ze+yX0xeVWlSaD2OeRnJ0zVSJDZX7F6yyGlT9obDHd6uiwdOZBDFM3n WicAreuz2Vz/+GLvOUp5CvPou5WZn5NGs3QeeOnXcxP76I/z5ttw5J+pG2g00lEpjs jO0/0Iy+D5edRQ3OQjuF1m0wZ1KEFDu/NyvfdYeYte4dJX9EJqXNCnZyH19HQRFBSQ 5s/aSZcj+EvMoKdRSTOKTtkQ= Date: Thu, 10 Sep 2026 21:39:47 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 5/5] x86/pvh: fix unbootable VMs by really inlining memset() in xen_prepare_pvh() Message-ID: <20260911043947.GIaqOGE9DFCHWwc6Ys@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-5-e70ef3b75b6a@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260822-pvh-kasan-inline-v9-5-e70ef3b75b6a@igalia.com> X-purgate-ID: tlsNG-33051d/1789101616-6CEDA4E9-0722017D/0/0 X-purgate-type: clean X-purgate-size: 1724 On Sat, Aug 22, 2026 at 03:33:21PM -0300, Mauricio Faria de Oliveira wrote: > Even with __builtin the compiler may decide to use the out of line function > instead of the inline implementation. > > This particular one (still) generated the inline implementation as expected > (at least in these compiler versions) but this is not guaranteed to remain. > > Switch the builtin to the inline implementation to address it. > > Fixes: fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()") > Signed-off-by: Mauricio Faria de Oliveira > Reviewed-by: Juergen Gross > --- > arch/x86/platform/pvh/enlighten.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c > index f2053cbe9b0ce3d2178938269607c652ae8f528e..cb442cbd9d828619421babb281bfe9759edbca8a 100644 > --- a/arch/x86/platform/pvh/enlighten.c > +++ b/arch/x86/platform/pvh/enlighten.c > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > > #include > > @@ -129,7 +130,7 @@ void __init xen_prepare_pvh(void) > * This must not compile to "call memset" because memset() may be > * instrumented. > */ > - __builtin_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams)); > + __inline_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams)); > > hypervisor_specific_init(xen_guest); > > > -- Why is this a separate patch from 4/5 if it is fixing the same thing? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Fri Sep 11 05:15:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 05:15:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415268.1644914 (Exim 4.92) (envelope-from ) id 1x4tbb-0006xI-7M; Fri, 11 Sep 2026 05:15:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415268.1644914; Fri, 11 Sep 2026 05:15:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4tbb-0006xB-3r; Fri, 11 Sep 2026 05:15:19 +0000 Received: by outflank-mailman (input) for mailman id 1415268; Thu, 10 Sep 2026 19:02:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4k2a-00056v-Or for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 19:02:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4k2Z-001ZYC-P6 for xen-devel@lists.xenproject.org; Thu, 10 Sep 2026 21:02:31 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa2feb0-bab6-0a2a0a5309dd-0a2a450c8818-44 for ; Thu, 10 Sep 2026 21:02:31 +0200 Received: from [148.163.158.5] (helo=mx0b-001b2d01.pphosted.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa2fec6-f479-0a2a450c0019-94a39e05785a-3 for ; Thu, 10 Sep 2026 21:02:31 +0200 Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68AIVh2U3552916; Thu, 10 Sep 2026 19:01:51 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gkd8s6s1e-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 10 Sep 2026 19:01:48 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.11/8.18.1.11) with ESMTP id 68AIZ34R455276; Thu, 10 Sep 2026 19:01:47 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4gkvnrhxdg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2026 19:01:47 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 68AJ1hS450332040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Sep 2026 19:01:43 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0AC312004D; Thu, 10 Sep 2026 19:01:43 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E044320040; Thu, 10 Sep 2026 19:01:28 +0000 (GMT) Received: from fedora (unknown [9.5.7.39]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS; Thu, 10 Sep 2026 19:01:28 +0000 (GMT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=TK5BI4 FW3/Iwcr2HpErBhBc8Uj1FBFKbbJUk0YAV2H8=; b=o0yikt9rJtDxosZ/JwnoQT ntEB5VpD7J7unb8R+j/MOMLtZBPM5mNf2UXGjAmerBF/o3hAoYerMrfYOKK19J6N hH/IOIp01zTruI7Y5LqHgvR7G6+MuDcme7V99QDYFC/15UHY7W4AGQBOhSd5WNim r+t4ed+k+PR390Kmgjp4yGKCZhvQ62DVi+tjRXNUmzHPQgGTUXllE1+wbEdsfuU7 yuuGVnAsFZfFcxNqNIP/N+PIRwtq/3EBncxf4V1ZQ3Sk9j2g3wTQmcwowAhElbQ4 NREBxbSTkXsYlSMe8VDZtObDAF9hAAS6KIQB33vg1PFmf0PellAsvOHaGkoqc8bw == Date: Fri, 11 Sep 2026 00:39:13 +0530 From: Amit Machhiwal To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini , Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= , Michael Roth , Pierrick Bouvier , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Alexander Graf , Richard Henderson , "Gonglei (Arei)" , zhenwei pi , David Hildenbrand , Igor Mammedov , Alberto Garcia , Kevin Wolf , Hanna Reitz , "Michael S. Tsirkin" , Ani Sinha , Peter Maydell , Luc Michel , Zhao Liu , Jonathan Cameron , =?utf-8?Q?C=C3=A9dric?= Le Goater , Steven Lee , Troy Lee , Jamin Lin , Kane Chen , Andrew Jeffery , Joel Stanley , Samuel Tardieu , Marcelo Tosatti , John Snow , "Denis V. Lunev" , Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , FangSheng Huang , Tyrone Ting , Hao Wu , Jason Wang , Keith Busch , Klaus Jensen , Jesper Devantier , Nicholas Piggin , Aditya Gupta , Glenn Miles , Harsh Prateek Bora , Amit Machhiwal , Conor Dooley , Sebastian Huber , Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , Halil Pasic , Christian Borntraeger , Jason Herne , Ilya Leoshkevich , Eric Farman , Matthew Rosato , Cornelia Huck , Titus Rwantare , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Zhang Chen , Li Zhijian , Peter Xu , Chinmay Rath , Hendrik Brueckner , kvm@vger.kernel.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, linux-cxl@vger.kernel.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 46/75] qom: convert scalar properties to QAPI-aware registration Message-ID: <20260911003600.0a6732b2-50-amachhiw@linux.ibm.com> Mail-Followup-To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini , Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= , Michael Roth , Pierrick Bouvier , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Alexander Graf , Richard Henderson , "Gonglei (Arei)" , zhenwei pi , David Hildenbrand , Igor Mammedov , Alberto Garcia , Kevin Wolf , Hanna Reitz , "Michael S. Tsirkin" , Ani Sinha , Peter Maydell , Luc Michel , Zhao Liu , Jonathan Cameron , =?utf-8?Q?C=C3=A9dric?= Le Goater , Steven Lee , Troy Lee , Jamin Lin , Kane Chen , Andrew Jeffery , Joel Stanley , Samuel Tardieu , Marcelo Tosatti , John Snow , "Denis V. Lunev" , Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , FangSheng Huang , Tyrone Ting , Hao Wu , Jason Wang , Keith Busch , Klaus Jensen , Jesper Devantier , Nicholas Piggin , Aditya Gupta , Glenn Miles , Harsh Prateek Bora , Conor Dooley , Sebastian Huber , Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , Halil Pasic , Christian Borntraeger , Jason Herne , Ilya Leoshkevich , Eric Farman , Matthew Rosato , Cornelia Huck , Titus Rwantare , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Zhang Chen , Li Zhijian , Peter Xu , Chinmay Rath , Hendrik Brueckner , kvm@vger.kernel.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, linux-cxl@vger.kernel.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org References: <20260904-qom-qapi-v4-0-a985f168e938@redhat.com> <20260904-qom-qapi-v4-46-a985f168e938@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260904-qom-qapi-v4-46-a985f168e938@redhat.com> X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-ORIG-GUID: btNGbB04ziqh2rdLPV26tbOYwe8xLdJC X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTEwMDIzNiBTYWx0ZWRfX0I0Oa55xvJnW a7CyQg9UCENfzdDKpeFiC1/avRAK3h3WrnzYz0g0Tx0USGPMINjz2qnth4kyzDrckAwG/2CoSap z1AI/5kLgGV3GghUnQO1jcI8+mUM6V/DluBPJtnTuAtk/wWmeXuBYFuDyE/P61Fe627G/7uwMHL +ZpVDLKRjtmLpGz7XMNkx6KabQcb79M2UExLbvypadOBag4f39B2+YNrHTLquhAi6ddsyPBQRX6 EI8ZQ7DADA1ATf5ZHamxOyiM0stVrdFNEWYI46R2yxGCEydqXOaQpAEwzpOvxO7eshDfggLQGi6 UL527V4+p/SbMvGkwiXaCWjWq686lJFOzANX1IGMlx90yRgHGBhOqEvMYNWNKnyWNcVW8ijVHuE kxXKTlVQYyiwlxNJltdahODPwnNVfmy2sNhCPSp46PT2LbxKU5H+5loq7fxgDJ8DahJ1j8oMowW EBwpfVqc1q7ZDrgLPmg== X-Proofpoint-Spam-Info: AW1haW4tMjYwOTEwMDIzNiBTYWx0ZWRfX6X0sVJO1Wg0Y 1icD22sE4vYPt5cLb4KcpbyoumI0LsBgMrDZBujMEdM8BMozrQaXT1dshUlQ3d9OkPWPALgRzxI d9z98xop/wQtmYOiTenngQn9pqMiaUI= X-Authority-Analysis: v=2.4 cv=MpXHeGae c=1 sm=1 tr=0 ts=6aa2fe9d cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=8nJEP1OIZ-IA:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=20KFwNOVAAAA:8 a=VnNF1IyMAAAA:8 a=R6_39iU5eN1cMnBUdzEA:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10 X-Proofpoint-GUID: rX9USQCoCNHaATdagm5i5z2CnmqB4KnK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-10_06,2026-09-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 suspectscore=0 priorityscore=1501 clxscore=1011 impostorscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609100236 X-purgate-ID: tlsNG-d25034/1789066951-77AD49FB-B3D1B475/0/0 X-purgate-type: clean X-purgate-size: 113383 On 2026/09/04 11:58 PM, Marc-Andr Lureau wrote: > Signed-off-by: Marc-Andr Lureau The PPC-specific changes in hw/ppc/spapr_drc.c, hw/pci-host/pnv_phb3.c, hw/pci-host/pnv_phb4.c, and target/ppc/compat.c look good to me. Hence, Reviewed-by: Amit Machhiwal One thing I noticed in hw/sensor/adc128d818.c: #include "qapi-builtin-type-infos.h" Every other file in this patch uses: #include "qapi/qapi-builtin-type-infos.h" Is the missing `qapi/` prefix intentional, or is this a typo? Thanks, Amit > --- > accel/kvm/kvm-all.c | 5 ++- > accel/nitro/nitro-accel.c | 3 +- > accel/tcg/tcg-all.c | 3 +- > backends/cryptodev.c | 7 ++-- > backends/hostmem-file.c | 4 +- > backends/hostmem-memfd.c | 3 +- > backends/hostmem.c | 6 +-- > block/throttle-groups.c | 5 ++- > crypto/secret_keyring.c | 9 +++-- > event-loop-base.c | 7 ++-- > hw/acpi/ich9.c | 1 + > hw/acpi/pci.c | 7 ++-- > hw/arm/virt.c | 4 +- > hw/core/clock.c | 3 +- > hw/core/machine.c | 2 +- > hw/cpu/core.c | 10 +++-- > hw/cxl/cxl-host.c | 2 +- > hw/gpio/aspeed_gpio.c | 5 ++- > hw/gpio/aspeed_sgpio.c | 3 +- > hw/gpio/stm32l4x5_gpio.c | 5 ++- > hw/i386/pc.c | 6 +-- > hw/i386/sgx-epc.c | 3 +- > hw/i386/x86.c | 6 +-- > hw/ide/ide-dev.c | 3 +- > hw/intc/apic_common.c | 3 +- > hw/loongarch/virt.c | 2 +- > hw/mem/nvdimm.c | 7 ++-- > hw/mem/pc-dimm.c | 3 +- > hw/misc/aspeed_lpc.c | 73 +++++++++++++++++++++++++------------ > hw/misc/aspeed_sdmc.c | 3 +- > hw/misc/npcm7xx_mft.c | 3 +- > hw/net/ne2000-isa.c | 3 +- > hw/nvme/ctrl.c | 3 +- > hw/pci-bridge/pci_expander_bridge.c | 3 +- > hw/pci-host/i440fx.c | 29 +++++++++------ > hw/pci-host/pnv_phb3.c | 5 ++- > hw/pci-host/pnv_phb4.c | 5 ++- > hw/pci-host/q35.c | 9 +++-- > hw/ppc/spapr_drc.c | 3 +- > hw/riscv/microchip_pfsoc.c | 3 +- > hw/s390x/sclpcpi.c | 8 ++-- > hw/s390x/virtio-ccw-mem.c | 3 +- > hw/sensor/adc128d818.c | 16 +++++--- > hw/sensor/adm1266.c | 3 +- > hw/sensor/adm1272.c | 9 +++-- > hw/sensor/emc141x.c | 9 +++-- > hw/sensor/isl_pmbus_vr.c | 19 +++++----- > hw/sensor/lsm303dlhc_mag.c | 9 +++-- > hw/sensor/max34451.c | 5 ++- > hw/sensor/tmp105.c | 3 +- > hw/sensor/tmp421.c | 9 +++-- > hw/usb/dev-storage-classic.c | 3 +- > hw/virtio/virtio-balloon.c | 3 +- > hw/virtio/virtio-mem-pci.c | 3 +- > hw/virtio/virtio-mem.c | 18 +++++---- > hw/xen/xen-pvh-common.c | 9 +++-- > iothread.c | 9 +++-- > net/colo-compare.c | 7 ++-- > net/dump.c | 6 ++- > net/filter-buffer.c | 3 +- > qom/object.c | 42 ++++++++++----------- > system/bootdevice.c | 3 +- > system/memory.c | 5 ++- > target/arm/cpu64.c | 11 +++--- > target/arm/kvm.c | 3 +- > target/arm/tcg/cpu64.c | 11 +++--- > target/i386/cpu.c | 12 +++--- > target/i386/kvm/kvm.c | 8 ++-- > target/i386/sev.c | 2 +- > target/ppc/compat.c | 3 +- > target/riscv/cpu.c | 15 ++++---- > target/riscv/kvm/kvm-cpu.c | 7 ++-- > target/riscv/tcg/tcg-cpu.c | 13 ++++--- > target/s390x/cpu_models.c | 5 ++- > tests/unit/test-qdev-global-props.c | 11 ++++-- > ui/console.c | 3 +- > util/thread-context.c | 7 ++-- > 77 files changed, 343 insertions(+), 241 deletions(-) > > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c > index e2cfbcf44046..ff9db3ca8b3d 100644 > --- a/accel/kvm/kvm-all.c > +++ b/accel/kvm/kvm-all.c > @@ -24,6 +24,7 @@ > #include "qemu/config-file.h" > #include "qemu/error-report.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "hw/pci/msi.h" > #include "hw/pci/msix.h" > #include "hw/s390x/adapter.h" > @@ -4278,13 +4279,13 @@ static void kvm_accel_class_init(ObjectClass *oc, const void *data) > .description = "Configure KVM in-kernel irqchip", > )); > > - object_class_property_add(oc, "kvm-shadow-mem", "int", > + object_class_property_add_qapi(oc, "kvm-shadow-mem", &int_type_info, > kvm_get_kvm_shadow_mem, kvm_set_kvm_shadow_mem, > NULL, NULL); > object_class_property_set_description(oc, "kvm-shadow-mem", > "KVM shadow MMU size"); > > - object_class_property_add(oc, "dirty-ring-size", "uint32", > + object_class_property_add_qapi(oc, "dirty-ring-size", &uint32_type_info, > kvm_get_dirty_ring_size, kvm_set_dirty_ring_size, > NULL, NULL); > object_class_property_set_description(oc, "dirty-ring-size", > diff --git a/accel/nitro/nitro-accel.c b/accel/nitro/nitro-accel.c > index a1e97a9162e9..05841c1277dc 100644 > --- a/accel/nitro/nitro-accel.c > +++ b/accel/nitro/nitro-accel.c > @@ -29,6 +29,7 @@ > #include "qemu/osdep.h" > #include "qemu/error-report.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > #include "qemu/rcu.h" > @@ -238,7 +239,7 @@ static void nitro_accel_class_init(ObjectClass *oc, const void *data) > object_class_property_set_description(oc, "debug-mode", > "Start enclave in debug mode (enables console output)"); > > - object_class_property_add(oc, "enclave-cid", "uint64", > + object_class_property_add_qapi(oc, "enclave-cid", &uint64_type_info, > nitro_get_enclave_cid, > nitro_set_enclave_cid, > NULL, NULL); > diff --git a/accel/tcg/tcg-all.c b/accel/tcg/tcg-all.c > index 767e8805552f..277cf0e2d012 100644 > --- a/accel/tcg/tcg-all.c > +++ b/accel/tcg/tcg-all.c > @@ -29,6 +29,7 @@ > #include "exec/icount.h" > #include "tcg/startup.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qemu/error-report.h" > #include "qemu/accel.h" > #include "qemu/atomic.h" > @@ -270,7 +271,7 @@ static void tcg_accel_class_init(ObjectClass *oc, const void *data) > tcg_get_thread, > tcg_set_thread); > > - object_class_property_add(oc, "tb-size", "uint32", > + object_class_property_add_qapi(oc, "tb-size", &uint32_type_info, > tcg_get_tb_size, tcg_set_tb_size, > NULL, NULL); > object_class_property_set_description(oc, "tb-size", > diff --git a/backends/cryptodev.c b/backends/cryptodev.c > index e8f2b18f2017..a69adb70440c 100644 > --- a/backends/cryptodev.c > +++ b/backends/cryptodev.c > @@ -25,6 +25,7 @@ > #include "system/cryptodev.h" > #include "system/stats.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-commands-cryptodev.h" > #include "qapi/qapi-types-stats.h" > #include "qapi/visitor.h" > @@ -622,15 +623,15 @@ cryptodev_backend_class_init(ObjectClass *oc, const void *data) > ucc->prepare_delete = cryptodev_backend_prepare_delete; > > QTAILQ_INIT(&crypto_clients); > - object_class_property_add(oc, "queues", "uint32", > + object_class_property_add_qapi(oc, "queues", &uint32_type_info, > cryptodev_backend_get_queues, > cryptodev_backend_set_queues, > NULL, NULL); > - object_class_property_add(oc, "throttle-bps", "uint64", > + object_class_property_add_qapi(oc, "throttle-bps", &uint64_type_info, > cryptodev_backend_get_bps, > cryptodev_backend_set_bps, > NULL, NULL); > - object_class_property_add(oc, "throttle-ops", "uint64", > + object_class_property_add_qapi(oc, "throttle-ops", &uint64_type_info, > cryptodev_backend_get_ops, > cryptodev_backend_set_ops, > NULL, NULL); > diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c > index 9c7e0183d480..aeb6fc37858c 100644 > --- a/backends/hostmem-file.c > +++ b/backends/hostmem-file.c > @@ -275,11 +275,11 @@ file_backend_class_init(ObjectClass *oc, const void *data) > file_memory_backend_get_discard_data, file_memory_backend_set_discard_data); > object_class_property_add_str(oc, "mem-path", > get_mem_path, set_mem_path); > - object_class_property_add(oc, "align", "uint64", > + object_class_property_add_qapi(oc, "align", &uint64_type_info, > file_memory_backend_get_align, > file_memory_backend_set_align, > NULL, NULL); > - object_class_property_add(oc, "offset", "int", > + object_class_property_add_qapi(oc, "offset", &int_type_info, > file_memory_backend_get_offset, > file_memory_backend_set_offset, > NULL, NULL); > diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c > index e21c5a3f2e24..42027529ab50 100644 > --- a/backends/hostmem-memfd.c > +++ b/backends/hostmem-memfd.c > @@ -16,6 +16,7 @@ > #include "qemu/memfd.h" > #include "qemu/module.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qom/object.h" > #include "migration/cpr.h" > > @@ -145,7 +146,7 @@ memfd_backend_class_init(ObjectClass *oc, const void *data) > memfd_backend_set_hugetlb); > object_class_property_set_description(oc, "hugetlb", > "Use huge pages"); > - object_class_property_add(oc, "hugetlbsize", "uint64", > + object_class_property_add_qapi(oc, "hugetlbsize", &uint64_type_info, > memfd_backend_get_hugetlbsize, > memfd_backend_set_hugetlbsize, > NULL, NULL); > diff --git a/backends/hostmem.c b/backends/hostmem.c > index e7f9b436a459..d05ab53ab662 100644 > --- a/backends/hostmem.c > +++ b/backends/hostmem.c > @@ -529,7 +529,7 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data) > host_memory_backend_set_prealloc); > object_class_property_set_description(oc, "prealloc", > "Preallocate memory"); > - object_class_property_add(oc, "prealloc-threads", "int", > + object_class_property_add_qapi(oc, "prealloc-threads", &int_type_info, > host_memory_backend_get_prealloc_threads, > host_memory_backend_set_prealloc_threads, > NULL, NULL); > @@ -540,13 +540,13 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data) > object_property_allow_set_link, OBJ_PROP_LINK_STRONG); > object_class_property_set_description(oc, "prealloc-context", > "Context to use for creating CPU threads for preallocation"); > - object_class_property_add(oc, "size", "size", > + object_class_property_add_qapi(oc, "size", &size_type_info, > host_memory_backend_get_size, > host_memory_backend_set_size, > NULL, NULL); > object_class_property_set_description(oc, "size", > "Size of the memory region (ex: 500M)"); > - object_class_property_add(oc, "host-nodes", "[uint16]", > + object_class_property_add_qapi(oc, "host-nodes", &uint16List_type_info, > host_memory_backend_get_host_nodes, > host_memory_backend_set_host_nodes, > NULL, NULL); > diff --git a/block/throttle-groups.c b/block/throttle-groups.c > index 6312157802da..851617237f80 100644 > --- a/block/throttle-groups.c > +++ b/block/throttle-groups.c > @@ -31,6 +31,7 @@ > #include "qemu/thread.h" > #include "system/qtest.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-type-infos-block-core.h" > #include "qapi/qapi-visit-block-core.h" > #include "qom/object.h" > @@ -983,9 +984,9 @@ static void throttle_group_obj_class_init(ObjectClass *klass, > > /* individual properties */ > for (i = 0; i < sizeof(properties) / sizeof(ThrottleParamInfo); i++) { > - object_class_property_add(klass, > + object_class_property_add_qapi(klass, > properties[i].name, > - "int64", > + &int64_type_info, > throttle_group_get, > throttle_group_set, > NULL, &properties[i]); > diff --git a/crypto/secret_keyring.c b/crypto/secret_keyring.c > index 78d7f09b3b97..de813e79d8d6 100644 > --- a/crypto/secret_keyring.c > +++ b/crypto/secret_keyring.c > @@ -21,6 +21,7 @@ > #include "qemu/osdep.h" > #include > #include > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/error.h" > #include "qom/object_interfaces.h" > #include "trace.h" > @@ -108,10 +109,10 @@ qcrypto_secret_keyring_class_init(ObjectClass *oc, const void *data) > QCryptoSecretCommonClass *sic = QCRYPTO_SECRET_COMMON_CLASS(oc); > sic->load_data = qcrypto_secret_keyring_load_data; > > - object_class_property_add(oc, "serial", "int32_t", > - qcrypto_secret_prop_get_key, > - qcrypto_secret_prop_set_key, > - NULL, NULL); > + object_class_property_add_qapi(oc, "serial", &int32_type_info, > + qcrypto_secret_prop_get_key, > + qcrypto_secret_prop_set_key, > + NULL, NULL); > } > > > diff --git a/event-loop-base.c b/event-loop-base.c > index 23f554d92ce8..c16c5366f680 100644 > --- a/event-loop-base.c > +++ b/event-loop-base.c > @@ -14,6 +14,7 @@ > #include "qemu/osdep.h" > #include "qom/object_interfaces.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "block/thread-pool.h" > #include "system/event-loop-base.h" > > @@ -104,15 +105,15 @@ static void event_loop_base_class_init(ObjectClass *klass, > ucc->complete = event_loop_base_complete; > ucc->prepare_delete = event_loop_base_prepare_delete; > > - object_class_property_add(klass, "aio-max-batch", "int64", > + object_class_property_add_qapi(klass, "aio-max-batch", &int64_type_info, > event_loop_base_get_param, > event_loop_base_set_param, > NULL, &aio_max_batch_info); > - object_class_property_add(klass, "thread-pool-min", "int64", > + object_class_property_add_qapi(klass, "thread-pool-min", &int64_type_info, > event_loop_base_get_param, > event_loop_base_set_param, > NULL, &thread_pool_min_info); > - object_class_property_add(klass, "thread-pool-max", "int64", > + object_class_property_add_qapi(klass, "thread-pool-max", &int64_type_info, > event_loop_base_get_param, > event_loop_base_set_param, > NULL, &thread_pool_max_info); > diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c > index 8082eae4282a..cf503668c00a 100644 > --- a/hw/acpi/ich9.c > +++ b/hw/acpi/ich9.c > @@ -26,6 +26,7 @@ > > #include "qemu/osdep.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/pci/pci.h" > #include "migration/vmstate.h" > diff --git a/hw/acpi/pci.c b/hw/acpi/pci.c > index c82924be8620..71d01307e141 100644 > --- a/hw/acpi/pci.c > +++ b/hw/acpi/pci.c > @@ -27,6 +27,7 @@ > #include "qemu/error-report.h" > #include "qom/object_interfaces.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "hw/core/boards.h" > #include "hw/acpi/aml-build.h" > #include "hw/acpi/pci.h" > @@ -139,7 +140,7 @@ static void acpi_generic_initiator_class_init(ObjectClass *oc, const void *data) > acpi_generic_initiator_set_pci_device); > object_class_property_set_description(oc, "pci-dev", > "PCI device to associate with the node"); > - object_class_property_add(oc, "node", "uint32", NULL, > + object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL, > acpi_generic_initiator_set_node, NULL, NULL); > object_class_property_set_description(oc, "node", > "NUMA node associated with the PCI device"); > @@ -253,8 +254,8 @@ static void acpi_generic_port_class_init(ObjectClass *oc, const void *data) > acpi_generic_port_set_pci_bus); > object_class_property_set_description(oc, "pci-bus", > "PCI Bus of the host bridge associated with this GP affinity structure"); > - object_class_property_add(oc, "node", "uint32", NULL, > - acpi_generic_port_set_node, NULL, NULL); > + object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL, > + acpi_generic_port_set_node, NULL, NULL); > object_class_property_set_description(oc, "node", > "The NUMA node like ID to index HMAT/SLIT NUMA properties involving GP"); > } > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > index 872920b6482b..4e5d8d9f86e3 100644 > --- a/hw/arm/virt.c > +++ b/hw/arm/virt.c > @@ -4258,7 +4258,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) > "Set on/off to enable/disable high " > "memory region for PCI MMIO"); > > - object_class_property_add(oc, "highmem-mmio-size", "size", > + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_info, > virt_get_highmem_mmio_size, > virt_set_highmem_mmio_size, > NULL, NULL); > @@ -4266,7 +4266,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) > "Set the high memory region size " > "for PCI MMIO"); > > - object_class_property_add(oc, "virtio-mmio-transports", "uint8", > + object_class_property_add_qapi(oc, "virtio-mmio-transports", &uint8_type_info, > virt_get_virtio_transports, > virt_set_virtio_transports, > NULL, NULL); > diff --git a/hw/core/clock.c b/hw/core/clock.c > index 3fc98a0c65d5..f55cb17af77e 100644 > --- a/hw/core/clock.c > +++ b/hw/core/clock.c > @@ -13,6 +13,7 @@ > > #include "qemu/osdep.h" > #include "qemu/cutils.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "system/qtest.h" > #include "hw/core/clock.h" > @@ -185,7 +186,7 @@ static void clock_initfn(Object *obj) > QLIST_INIT(&clk->children); > > if (qtest_enabled()) { > - object_property_add(obj, "qtest-clock-period", "uint64", > + object_property_add_qapi(obj, "qtest-clock-period", &uint64_type_info, > clock_period_prop_get, NULL, NULL, NULL); > } > } > diff --git a/hw/core/machine.c b/hw/core/machine.c > index 530fbaeb0b28..aa2d90a4e4df 100644 > --- a/hw/core/machine.c > +++ b/hw/core/machine.c > @@ -1133,7 +1133,7 @@ static void machine_class_init(ObjectClass *oc, const void *data) > object_class_property_set_description(oc, "smp-cache", > "Cache properties list for SMP machine"); > > - object_class_property_add(oc, "phandle-start", "int", > + object_class_property_add_qapi(oc, "phandle-start", &int_type_info, > machine_get_phandle_start, machine_set_phandle_start, > NULL, NULL); > object_class_property_set_description(oc, "phandle-start", > diff --git a/hw/cpu/core.c b/hw/cpu/core.c > index 26e488f3d8e3..d7c89f47ab04 100644 > --- a/hw/cpu/core.c > +++ b/hw/cpu/core.c > @@ -12,6 +12,7 @@ > #include "hw/core/boards.h" > #include "hw/cpu/core.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > > static void core_prop_get_core_id(Object *obj, Visitor *v, const char *name, > @@ -82,10 +83,11 @@ static void cpu_core_class_init(ObjectClass *oc, const void *data) > DeviceClass *dc = DEVICE_CLASS(oc); > > set_bit(DEVICE_CATEGORY_CPU, dc->categories); > - object_class_property_add(oc, "core-id", "int", core_prop_get_core_id, > - core_prop_set_core_id, NULL, NULL); > - object_class_property_add(oc, "nr-threads", "int", core_prop_get_nr_threads, > - core_prop_set_nr_threads, NULL, NULL); > + object_class_property_add_qapi(oc, "core-id", &int_type_info, core_prop_get_core_id, > + core_prop_set_core_id, NULL, NULL); > + object_class_property_add_qapi(oc, "nr-threads", &int_type_info, > + core_prop_get_nr_threads, core_prop_set_nr_threads, > + NULL, NULL); > } > > static const TypeInfo cpu_core_type_info = { > diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c > index 7592c4ac6c7b..4133398fec48 100644 > --- a/hw/cxl/cxl-host.c > +++ b/hw/cxl/cxl-host.c > @@ -565,7 +565,7 @@ static void machine_set_cfmw(Object *obj, Visitor *v, const char *name, > > void cxl_machine_init(Object *obj, CXLState *state) > { > - object_property_add(obj, "cxl", "bool", machine_get_cxl, > + object_property_add_qapi(obj, "cxl", &bool_type_info, machine_get_cxl, > machine_set_cxl, NULL, state); > object_property_set_description(obj, "cxl", > "Set on/off to enable/disable " > diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c > index 1cf6f5df5505..0c90bcd723da 100644 > --- a/hw/gpio/aspeed_gpio.c > +++ b/hw/gpio/aspeed_gpio.c > @@ -12,6 +12,7 @@ > #include "hw/gpio/aspeed_gpio.h" > #include "hw/misc/aspeed_scu.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/core/irq.h" > #include "migration/vmstate.h" > @@ -1481,7 +1482,7 @@ static void aspeed_gpio_init(Object *obj) > int pin_idx = j % GPIOS_PER_GROUP; > const char *group = &props->group_label[group_idx][0]; > char *name = g_strdup_printf("gpio%s%d", group, pin_idx); > - object_property_add(obj, name, "bool", aspeed_gpio_get_pin, > + object_property_add_qapi(obj, name, &bool_type_info, aspeed_gpio_get_pin, > aspeed_gpio_set_pin, NULL, NULL); > g_free(name); > } > @@ -1489,7 +1490,7 @@ static void aspeed_gpio_init(Object *obj) > > for (int i = 0; i < agc->nr_gpio_sets; i++) { > g_autofree char *name = g_strdup_printf("gpio-set[%d]", i); > - object_property_add(obj, name, "uint32", aspeed_gpio_get_set, > + object_property_add_qapi(obj, name, &uint32_type_info, aspeed_gpio_get_set, > aspeed_gpio_set_set, NULL, NULL); > } > } > diff --git a/hw/gpio/aspeed_sgpio.c b/hw/gpio/aspeed_sgpio.c > index 7d2f73699520..67b0c10d79fa 100644 > --- a/hw/gpio/aspeed_sgpio.c > +++ b/hw/gpio/aspeed_sgpio.c > @@ -11,6 +11,7 @@ > #include "qemu/log.h" > #include "qemu/error-report.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/core/irq.h" > #include "hw/core/qdev-properties.h" > @@ -300,7 +301,7 @@ static void aspeed_sgpio_init(Object *obj) > { > for (int i = 0; i < ASPEED_SGPIO_MAX_PIN_PAIR * 2; i++) { > g_autofree char *name = g_strdup_printf("sgpio%03d", i); > - object_property_add(obj, name, "bool", aspeed_sgpio_get_pin, > + object_property_add_qapi(obj, name, &bool_type_info, aspeed_sgpio_get_pin, > aspeed_sgpio_set_pin, NULL, NULL); > } > } > diff --git a/hw/gpio/stm32l4x5_gpio.c b/hw/gpio/stm32l4x5_gpio.c > index 92fa397fbafe..d349d41e41a1 100644 > --- a/hw/gpio/stm32l4x5_gpio.c > +++ b/hw/gpio/stm32l4x5_gpio.c > @@ -25,6 +25,7 @@ > #include "hw/core/qdev-properties.h" > #include "qapi/visitor.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "migration/vmstate.h" > #include "trace.h" > > @@ -409,10 +410,10 @@ static void stm32l4x5_gpio_init(Object *obj) > > s->clk = qdev_init_clock_in(DEVICE(s), "clk", NULL, s, 0); > > - object_property_add(obj, "disconnected-pins", "uint16", > + object_property_add_qapi(obj, "disconnected-pins", &uint16_type_info, > disconnected_pins_get, disconnected_pins_set, > NULL, &s->disconnected_pins); > - object_property_add(obj, "clock-freq-hz", "uint32", > + object_property_add_qapi(obj, "clock-freq-hz", &uint32_type_info, > clock_freq_get, NULL, NULL, NULL); > } > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > index 18b5dc169ab7..24c4c589ed04 100644 > --- a/hw/i386/pc.c > +++ b/hw/i386/pc.c > @@ -1720,7 +1720,7 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data) > mc->default_ram_id = "pc.ram"; > pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_AUTO; > > - object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size", > + object_class_property_add_qapi(oc, PC_MACHINE_MAX_RAM_BELOW_4G, &size_type_info, > pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g, > NULL, NULL); > object_class_property_set_description(oc, PC_MACHINE_MAX_RAM_BELOW_4G, > @@ -1758,13 +1758,13 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data) > pc_machine_get_default_bus_bypass_iommu, > pc_machine_set_default_bus_bypass_iommu); > > - object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size", > + object_class_property_add_qapi(oc, PC_MACHINE_MAX_FW_SIZE, &size_type_info, > pc_machine_get_max_fw_size, pc_machine_set_max_fw_size, > NULL, NULL); > object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE, > "Maximum combined firmware size"); > > - object_class_property_add(oc, PC_MACHINE_SMBIOS_EP, "str", > + object_class_property_add_qapi(oc, PC_MACHINE_SMBIOS_EP, &str_type_info, > pc_machine_get_smbios_ep, pc_machine_set_smbios_ep, > NULL, NULL); > object_class_property_set_description(oc, PC_MACHINE_SMBIOS_EP, > diff --git a/hw/i386/sgx-epc.c b/hw/i386/sgx-epc.c > index d3fe10028c51..d9b9ab3f7a96 100644 > --- a/hw/i386/sgx-epc.c > +++ b/hw/i386/sgx-epc.c > @@ -15,6 +15,7 @@ > #include "hw/mem/memory-device.h" > #include "hw/core/qdev-properties.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "target/i386/cpu.h" > #include "system/address-spaces.h" > @@ -43,7 +44,7 @@ static void sgx_epc_get_size(Object *obj, Visitor *v, const char *name, > > static void sgx_epc_init(Object *obj) > { > - object_property_add(obj, SGX_EPC_SIZE_PROP, "uint64", sgx_epc_get_size, > + object_property_add_qapi(obj, SGX_EPC_SIZE_PROP, &uint64_type_info, sgx_epc_get_size, > NULL, NULL, NULL); > } > > diff --git a/hw/i386/x86.c b/hw/i386/x86.c > index 63f297a10532..d0c782ec8544 100644 > --- a/hw/i386/x86.c > +++ b/hw/i386/x86.c > @@ -420,9 +420,9 @@ static void x86_machine_class_init(ObjectClass *oc, const void *data) > "in ACPI table header." > "The string may be up to 8 bytes in size"); > > - object_class_property_add(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, "uint64_t", > - x86_machine_get_bus_lock_ratelimit, > - x86_machine_set_bus_lock_ratelimit, NULL, NULL); > + object_class_property_add_qapi(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, &uint64_type_info, > + x86_machine_get_bus_lock_ratelimit, > + x86_machine_set_bus_lock_ratelimit, NULL, NULL); > object_class_property_set_description(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, > "Set the ratelimit for the bus locks acquired in VMs"); > > diff --git a/hw/ide/ide-dev.c b/hw/ide/ide-dev.c > index 5d478588c614..e2dd2439991f 100644 > --- a/hw/ide/ide-dev.c > +++ b/hw/ide/ide-dev.c > @@ -19,6 +19,7 @@ > > #include "qemu/osdep.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-types-block.h" > #include "qemu/error-report.h" > #include "qemu/module.h" > @@ -174,7 +175,7 @@ out: > > static void ide_dev_instance_init(Object *obj) > { > - object_property_add(obj, "bootindex", "int32", > + object_property_add_qapi(obj, "bootindex", &int32_type_info, > ide_dev_get_bootindex, > ide_dev_set_bootindex, NULL, NULL); > object_property_set_int(obj, "bootindex", -1, NULL); > diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c > index 0f0f37d45734..dc0517ceea90 100644 > --- a/hw/intc/apic_common.c > +++ b/hw/intc/apic_common.c > @@ -22,6 +22,7 @@ > #include "qemu/error-report.h" > #include "qemu/module.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/i386/apic.h" > #include "hw/i386/apic_internal.h" > @@ -442,7 +443,7 @@ static void apic_common_initfn(Object *obj) > APICCommonState *s = APIC_COMMON(obj); > > s->id = s->initial_apic_id = -1; > - object_property_add(obj, "id", "uint32", > + object_property_add_qapi(obj, "id", &uint32_type_info, > apic_common_get_id, > apic_common_set_id, NULL, NULL); > } > diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c > index 750ce2dbe5fc..209a0feddd80 100644 > --- a/hw/loongarch/virt.c > +++ b/hw/loongarch/virt.c > @@ -1520,7 +1520,7 @@ static void virt_class_init(ObjectClass *oc, const void *data) > object_class_property_set_description(oc, "highmem-mmio", > "Set on/off to enable/disable high " > "memory region for PCI MMIO"); > - object_class_property_add(oc, "highmem-mmio-size", "size", > + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_info, > virt_get_highmem_mmio_size, > virt_set_highmem_mmio_size, > NULL, NULL); > diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c > index cf8a4d8c5f2a..123ddc938546 100644 > --- a/hw/mem/nvdimm.c > +++ b/hw/mem/nvdimm.c > @@ -26,6 +26,7 @@ > #include "qemu/module.h" > #include "qemu/pmem.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/mem/nvdimm.h" > #include "hw/core/qdev-properties.h" > @@ -99,9 +100,9 @@ static void nvdimm_set_uuid(Object *obj, Visitor *v, const char *name, > > static void nvdimm_init(Object *obj) > { > - object_property_add(obj, NVDIMM_LABEL_SIZE_PROP, "size", > - nvdimm_get_label_size, nvdimm_set_label_size, NULL, > - NULL); > + object_property_add_qapi(obj, NVDIMM_LABEL_SIZE_PROP, &size_type_info, > + nvdimm_get_label_size, nvdimm_set_label_size, NULL, > + NULL); > > object_property_add(obj, NVDIMM_UUID_PROP, "QemuUUID", nvdimm_get_uuid, > nvdimm_set_uuid, NULL, NULL); > diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c > index 68862926ee2d..ee586ecc0c7d 100644 > --- a/hw/mem/pc-dimm.c > +++ b/hw/mem/pc-dimm.c > @@ -26,6 +26,7 @@ > #include "hw/mem/nvdimm.h" > #include "hw/mem/memory-device.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > #include "system/hostmem.h" > @@ -176,7 +177,7 @@ static void pc_dimm_get_size(Object *obj, Visitor *v, const char *name, > > static void pc_dimm_init(Object *obj) > { > - object_property_add(obj, PC_DIMM_SIZE_PROP, "uint64", pc_dimm_get_size, > + object_property_add_qapi(obj, PC_DIMM_SIZE_PROP, &uint64_type_info, pc_dimm_get_size, > NULL, NULL, NULL); > } > > diff --git a/hw/misc/aspeed_lpc.c b/hw/misc/aspeed_lpc.c > index 7f7e4f1a0985..e2d9b7572f27 100644 > --- a/hw/misc/aspeed_lpc.c > +++ b/hw/misc/aspeed_lpc.c > @@ -12,6 +12,7 @@ > #include "qemu/error-report.h" > #include "hw/misc/aspeed_lpc.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/core/irq.h" > #include "hw/core/qdev-properties.h" > @@ -417,30 +418,54 @@ static void aspeed_lpc_realize(DeviceState *dev, Error **errp) > > static void aspeed_lpc_init(Object *obj) > { > - object_property_add(obj, "idr1", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "odr1", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "str1", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "idr2", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "odr2", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "str2", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "idr3", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "odr3", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "str3", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "idr4", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "odr4", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > - object_property_add(obj, "str4", "uint32", aspeed_kcs_get_register_property, > - aspeed_kcs_set_register_property, NULL, NULL); > + object_property_add_qapi(obj, "idr1", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "odr1", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "str1", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "idr2", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "odr2", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "str2", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "idr3", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "odr3", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "str3", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "idr4", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "odr4", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > + object_property_add_qapi(obj, "str4", &uint32_type_info, > + aspeed_kcs_get_register_property, > + aspeed_kcs_set_register_property, > + NULL, NULL); > } > > static const VMStateDescription vmstate_aspeed_lpc = { > diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c > index f8fbaebee6ab..d096cc88f5c5 100644 > --- a/hw/misc/aspeed_sdmc.c > +++ b/hw/misc/aspeed_sdmc.c > @@ -15,6 +15,7 @@ > #include "hw/core/qdev-properties.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "trace.h" > #include "qemu/units.h" > #include "qemu/cutils.h" > @@ -259,7 +260,7 @@ static void aspeed_sdmc_set_ram_size(Object *obj, Visitor *v, const char *name, > > static void aspeed_sdmc_initfn(Object *obj) > { > - object_property_add(obj, "ram-size", "int", > + object_property_add_qapi(obj, "ram-size", &int_type_info, > aspeed_sdmc_get_ram_size, aspeed_sdmc_set_ram_size, > NULL, NULL); > } > diff --git a/hw/misc/npcm7xx_mft.c b/hw/misc/npcm7xx_mft.c > index 742166c4e828..99e9e49788c0 100644 > --- a/hw/misc/npcm7xx_mft.c > +++ b/hw/misc/npcm7xx_mft.c > @@ -23,6 +23,7 @@ > #include "hw/core/registerfields.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/bitops.h" > #include "qemu/error-report.h" > @@ -491,7 +492,7 @@ static void npcm7xx_mft_init(Object *obj) > s->clock_2 = qdev_init_clock_out(dev, "clock2"); > > for (int i = 0; i < NPCM7XX_PWM_PER_MODULE; ++i) { > - object_property_add(obj, "max_rpm[*]", "uint32", > + object_property_add_qapi(obj, "max_rpm[*]", &uint32_type_info, > npcm7xx_mft_get_max_rpm, > npcm7xx_mft_set_max_rpm, > NULL, &s->max_rpm[i]); > diff --git a/hw/net/ne2000-isa.c b/hw/net/ne2000-isa.c > index 673c785abc94..63e0d40ee726 100644 > --- a/hw/net/ne2000-isa.c > +++ b/hw/net/ne2000-isa.c > @@ -29,6 +29,7 @@ > #include "ne2000.h" > #include "system/system.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > #include "qom/object.h" > @@ -131,7 +132,7 @@ out: > > static void isa_ne2000_instance_init(Object *obj) > { > - object_property_add(obj, "bootindex", "int32", > + object_property_add_qapi(obj, "bootindex", &int32_type_info, > isa_ne2000_get_bootindex, > isa_ne2000_set_bootindex, NULL, NULL); > object_property_set_int(obj, "bootindex", -1, NULL); > diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c > index 4893cf7e7418..e4549aa9e534 100644 > --- a/hw/nvme/ctrl.c > +++ b/hw/nvme/ctrl.c > @@ -203,6 +203,7 @@ > #include "qemu/units.h" > #include "qemu/range.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "system/system.h" > #include "system/block-backend.h" > @@ -10578,7 +10579,7 @@ static void nvme_instance_init(Object *obj) > "bootindex", "/namespace@1,0", > DEVICE(obj)); > > - object_property_add(obj, "smart_critical_warning", "uint8", > + object_property_add_qapi(obj, "smart_critical_warning", &uint8_type_info, > nvme_get_smart_warning, > nvme_set_smart_warning, NULL, NULL); > } > diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c > index 40ffbc4e0821..9bb7d3c9debe 100644 > --- a/hw/pci-bridge/pci_expander_bridge.c > +++ b/hw/pci-bridge/pci_expander_bridge.c > @@ -12,6 +12,7 @@ > > #include "qemu/osdep.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "hw/pci/pci.h" > #include "hw/pci/pci_bus.h" > #include "hw/pci/pci_host.h" > @@ -103,7 +104,7 @@ static void pxb_bus_class_init(ObjectClass *class, const void *data) > pbc->bus_num = pxb_bus_num; > pbc->numa_node = pxb_bus_numa_node; > > - object_class_property_add(class, "acpi_uid", "uint32", > + object_class_property_add_qapi(class, "acpi_uid", &uint32_type_info, > prop_pxb_uid_get, NULL, NULL, NULL); > object_class_property_set_description(class, "acpi_uid", > "ACPI Unique ID used to distinguish this PCI Host Bridge / ACPI00016"); > diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c > index c1982f7962a6..feafa6a72fe4 100644 > --- a/hw/pci-host/i440fx.c > +++ b/hw/pci-host/i440fx.c > @@ -32,6 +32,7 @@ > #include "hw/core/qdev-properties.h" > #include "hw/core/sysbus.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "migration/vmstate.h" > #include "qapi/visitor.h" > #include "qemu/error-report.h" > @@ -387,21 +388,25 @@ static void i440fx_pcihost_class_init(ObjectClass *klass, const void *data) > /* Reason: needs to be wired up by pc_init1 */ > dc->user_creatable = false; > > - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_START, "uint32", > - i440fx_pcihost_get_pci_hole_start, > - NULL, NULL, NULL); > + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_START, > + &uint32_type_info, > + i440fx_pcihost_get_pci_hole_start, > + NULL, NULL, NULL); > > - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_END, "uint32", > - i440fx_pcihost_get_pci_hole_end, > - NULL, NULL, NULL); > + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_END, > + &uint32_type_info, > + i440fx_pcihost_get_pci_hole_end, > + NULL, NULL, NULL); > > - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_START, "uint64", > - i440fx_pcihost_get_pci_hole64_start, > - NULL, NULL, NULL); > + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_START, > + &uint64_type_info, > + i440fx_pcihost_get_pci_hole64_start, > + NULL, NULL, NULL); > > - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_END, "uint64", > - i440fx_pcihost_get_pci_hole64_end, > - NULL, NULL, NULL); > + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_END, > + &uint64_type_info, > + i440fx_pcihost_get_pci_hole64_end, > + NULL, NULL, NULL); > } > > static const TypeInfo i440fx_pcihost_info = { > diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c > index db061c134e95..667e9585ab8f 100644 > --- a/hw/pci-host/pnv_phb3.c > +++ b/hw/pci-host/pnv_phb3.c > @@ -11,6 +11,7 @@ > #include "qemu/bswap.h" > #include "qapi/visitor.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "hw/pci-host/pnv_phb3_regs.h" > #include "hw/pci-host/pnv_phb.h" > #include "hw/pci-host/pnv_phb3.h" > @@ -1164,12 +1165,12 @@ static void pnv_phb3_root_bus_class_init(ObjectClass *klass, const void *data) > { > BusClass *k = BUS_CLASS(klass); > > - object_class_property_add(klass, "phb-id", "uint32", > + object_class_property_add_qapi(klass, "phb-id", &uint32_type_info, > pnv_phb3_root_bus_get_prop, > pnv_phb3_root_bus_set_prop, > NULL, NULL); > > - object_class_property_add(klass, "chip-id", "uint32", > + object_class_property_add_qapi(klass, "chip-id", &uint32_type_info, > pnv_phb3_root_bus_get_prop, > pnv_phb3_root_bus_set_prop, > NULL, NULL); > diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c > index 9acaf4c0c2f5..96c2f89f889b 100644 > --- a/hw/pci-host/pnv_phb4.c > +++ b/hw/pci-host/pnv_phb4.c > @@ -11,6 +11,7 @@ > #include "qemu/bswap.h" > #include "qapi/visitor.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "target/ppc/cpu.h" > #include "hw/pci-host/pnv_phb4_regs.h" > #include "hw/pci-host/pnv_phb4.h" > @@ -1761,12 +1762,12 @@ static void pnv_phb4_root_bus_class_init(ObjectClass *klass, const void *data) > { > BusClass *k = BUS_CLASS(klass); > > - object_class_property_add(klass, "phb-id", "uint32", > + object_class_property_add_qapi(klass, "phb-id", &uint32_type_info, > pnv_phb4_root_bus_get_prop, > pnv_phb4_root_bus_set_prop, > NULL, NULL); > > - object_class_property_add(klass, "chip-id", "uint32", > + object_class_property_add_qapi(klass, "chip-id", &uint32_type_info, > pnv_phb4_root_bus_get_prop, > pnv_phb4_root_bus_set_prop, > NULL, NULL); > diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c > index f4556ad03a04..6eba30e06811 100644 > --- a/hw/pci-host/q35.c > +++ b/hw/pci-host/q35.c > @@ -35,6 +35,7 @@ > #include "hw/core/qdev-properties.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > > @@ -226,19 +227,19 @@ static void q35_host_initfn(Object *obj) > qdev_prop_set_uint64(DEVICE(s), PCI_HOST_PROP_PCI_HOLE64_SIZE, > Q35_PCI_HOST_HOLE64_SIZE_DEFAULT); > > - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32", > + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_START, &uint32_type_info, > q35_host_get_pci_hole_start, > NULL, NULL, NULL); > > - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "uint32", > + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_END, &uint32_type_info, > q35_host_get_pci_hole_end, > NULL, NULL, NULL); > > - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "uint64", > + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_START, &uint64_type_info, > q35_host_get_pci_hole64_start, > NULL, NULL, NULL); > > - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "uint64", > + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_END, &uint64_type_info, > q35_host_get_pci_hole64_end, > NULL, NULL, NULL); > > diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c > index 5c2150b71c86..64f9ca29b02e 100644 > --- a/hw/ppc/spapr_drc.c > +++ b/hw/ppc/spapr_drc.c > @@ -12,6 +12,7 @@ > > #include "qemu/osdep.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qobject/qnull.h" > #include "qemu/cutils.h" > #include "hw/ppc/spapr_drc.h" > @@ -584,7 +585,7 @@ static void spapr_dr_connector_instance_init(Object *obj) > SpaprDrcClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc); > > object_property_add_uint32_ptr(obj, "id", &drc->id, OBJ_PROP_FLAG_READ); > - object_property_add(obj, "index", "uint32", prop_get_index, > + object_property_add_qapi(obj, "index", &uint32_type_info, prop_get_index, > NULL, NULL, NULL); > object_property_add(obj, "fdt", "struct", prop_get_fdt, > NULL, NULL, NULL); > diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c > index 60bb96da0161..cf3974577463 100644 > --- a/hw/riscv/microchip_pfsoc.c > +++ b/hw/riscv/microchip_pfsoc.c > @@ -39,6 +39,7 @@ > #include "qemu/units.h" > #include "qemu/cutils.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/core/boards.h" > #include "hw/core/loader.h" > @@ -741,7 +742,7 @@ static void microchip_icicle_kit_machine_class_init(ObjectClass *oc, > */ > mc->default_ram_size = 1537 * MiB; > > - object_class_property_add(oc, "clint-timebase-frequency", "uint32_t", > + object_class_property_add_qapi(oc, "clint-timebase-frequency", &uint32_type_info, > microchip_icicle_kit_get_clint_timebase_freq, > microchip_icicle_kit_set_clint_timebase_freq, > NULL, NULL); > diff --git a/hw/s390x/sclpcpi.c b/hw/s390x/sclpcpi.c > index ec4bdf23509b..97d37ae4b932 100644 > --- a/hw/s390x/sclpcpi.c > +++ b/hw/s390x/sclpcpi.c > @@ -53,6 +53,7 @@ > #include "qemu/timer.h" > #include "hw/s390x/event-facility.h" > #include "hw/s390x/ebcdic.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-visit-machine.h" > #include "qapi/qapi-events-machine-s390x.h" > #include "migration/vmstate.h" > @@ -195,12 +196,13 @@ static void cpi_class_init(ObjectClass *klass, const void *data) > "name of the cluster which the VM belongs to, if any" > " e.g. \"PLEX \""); > > - object_class_property_add(klass, "system_level", "uint64", get_system_level, > - NULL, NULL, NULL); > + object_class_property_add_qapi(klass, "system_level", > + &uint64_type_info, get_system_level, > + NULL, NULL, NULL); > object_class_property_set_description(klass, "system_level", > "distribution and kernel version in Linux e.g. 74872343805430528"); > > - object_class_property_add(klass, "timestamp", "uint64", get_timestamp, > + object_class_property_add_qapi(klass, "timestamp", &uint64_type_info, get_timestamp, > NULL, NULL, NULL); > object_class_property_set_description(klass, "timestamp", > "latest update of CPI data in nanoseconds since the UNIX EPOCH"); > diff --git a/hw/s390x/virtio-ccw-mem.c b/hw/s390x/virtio-ccw-mem.c > index dea30aacfb32..046dfd544cf3 100644 > --- a/hw/s390x/virtio-ccw-mem.c > +++ b/hw/s390x/virtio-ccw-mem.c > @@ -13,6 +13,7 @@ > #include "qemu/osdep.h" > #include "hw/core/qdev-properties.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qemu/module.h" > #include "virtio-ccw-mem.h" > #include "hw/mem/memory-device.h" > @@ -205,7 +206,7 @@ static void virtio_ccw_mem_instance_init(Object *obj) > OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZE_PROP); > object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->vdev), > VIRTIO_MEM_SIZE_PROP); > - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", > + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, > virtio_ccw_mem_get_requested_size, > virtio_ccw_mem_set_requested_size, NULL, NULL); > } > diff --git a/hw/sensor/adc128d818.c b/hw/sensor/adc128d818.c > index c65508cba144..b0f93e28d19f 100644 > --- a/hw/sensor/adc128d818.c > +++ b/hw/sensor/adc128d818.c > @@ -8,6 +8,7 @@ > > #include "qemu/osdep.h" > #include "qemu/log.h" > +#include "qapi-builtin-type-infos.h" > #include "qapi/error.h" > #include "qapi/visitor.h" > #include "qom/object.h" > @@ -642,15 +643,18 @@ static void adc128d818_initfn(Object *obj) > for (unsigned ch = 0u; ch < ADC128D818_NUM_CHANNELS; ch++) { > char *name = g_strdup_printf("ain%u", ch); > > - object_property_add(obj, name, "int", adc128d818_get_ain, > - adc128d818_set_ain, NULL, NULL); > + object_property_add_qapi(obj, name, &int_type_info, > + adc128d818_get_ain, > + adc128d818_set_ain, NULL, NULL); > g_free(name); > } > > - object_property_add(obj, "temperature", "int", adc128d818_get_temperature, > - adc128d818_set_temperature, NULL, NULL); > - object_property_add(obj, "ext-vref-mv", "int", adc128d818_get_ext_vref, > - adc128d818_set_ext_vref, NULL, NULL); > + object_property_add_qapi(obj, "temperature", &int_type_info, > + adc128d818_get_temperature, > + adc128d818_set_temperature, NULL, NULL); > + object_property_add_qapi(obj, "ext-vref-mv", &int_type_info, > + adc128d818_get_ext_vref, > + adc128d818_set_ext_vref, NULL, NULL); > } > > static void adc128d818_realize(DeviceState *dev, Error **errp) > diff --git a/hw/sensor/adm1266.c b/hw/sensor/adm1266.c > index 37d1cffd57a9..62f563af7a7a 100644 > --- a/hw/sensor/adm1266.c > +++ b/hw/sensor/adm1266.c > @@ -14,6 +14,7 @@ > #include "hw/core/irq.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/log.h" > #include "qemu/module.h" > @@ -217,7 +218,7 @@ static void adm1266_init(Object *obj) > for (int i = 0; i < ADM1266_NUM_PAGES; i++) { > pmbus_page_config(pmdev, i, flags); > > - object_property_add(obj, "vout[*]", "uint16", > + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, > adm1266_get, > adm1266_set, NULL, &pmdev->pages[i].read_vout); > } > diff --git a/hw/sensor/adm1272.c b/hw/sensor/adm1272.c > index 0aa2a8655683..e1c1bf1c54de 100644 > --- a/hw/sensor/adm1272.c > +++ b/hw/sensor/adm1272.c > @@ -12,6 +12,7 @@ > #include "hw/core/irq.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/log.h" > #include "qemu/module.h" > @@ -493,19 +494,19 @@ static void adm1272_init(Object *obj) > > pmbus_page_config(pmdev, 0, flags); > > - object_property_add(obj, "vin", "uint16", > + object_property_add_qapi(obj, "vin", &uint16_type_info, > adm1272_get, > adm1272_set, NULL, &pmdev->pages[0].read_vin); > > - object_property_add(obj, "vout", "uint16", > + object_property_add_qapi(obj, "vout", &uint16_type_info, > adm1272_get, > adm1272_set, NULL, &pmdev->pages[0].read_vout); > > - object_property_add(obj, "iout", "uint16", > + object_property_add_qapi(obj, "iout", &uint16_type_info, > adm1272_get, > adm1272_set, NULL, &pmdev->pages[0].read_iout); > > - object_property_add(obj, "pin", "uint16", > + object_property_add_qapi(obj, "pin", &uint16_type_info, > adm1272_get, > adm1272_set, NULL, &pmdev->pages[0].read_pin); > > diff --git a/hw/sensor/emc141x.c b/hw/sensor/emc141x.c > index a51fc44395ab..5efe94643ca0 100644 > --- a/hw/sensor/emc141x.c > +++ b/hw/sensor/emc141x.c > @@ -22,6 +22,7 @@ > #include "hw/i2c/i2c.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > #include "qom/object.h" > @@ -251,16 +252,16 @@ static void emc141x_reset(DeviceState *dev) > > static void emc141x_initfn(Object *obj) > { > - object_property_add(obj, "temperature0", "int", > + object_property_add_qapi(obj, "temperature0", &int_type_info, > emc141x_get_temperature, > emc141x_set_temperature, NULL, NULL); > - object_property_add(obj, "temperature1", "int", > + object_property_add_qapi(obj, "temperature1", &int_type_info, > emc141x_get_temperature, > emc141x_set_temperature, NULL, NULL); > - object_property_add(obj, "temperature2", "int", > + object_property_add_qapi(obj, "temperature2", &int_type_info, > emc141x_get_temperature, > emc141x_set_temperature, NULL, NULL); > - object_property_add(obj, "temperature3", "int", > + object_property_add_qapi(obj, "temperature3", &int_type_info, > emc141x_get_temperature, > emc141x_set_temperature, NULL, NULL); > } > diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c > index 0fad04def773..8923e9e87510 100644 > --- a/hw/sensor/isl_pmbus_vr.c > +++ b/hw/sensor/isl_pmbus_vr.c > @@ -9,6 +9,7 @@ > #include "qemu/osdep.h" > #include "hw/sensor/isl_pmbus_vr.h" > #include "hw/core/qdev-properties.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/log.h" > #include "qemu/module.h" > @@ -136,63 +137,63 @@ static void isl_pmbus_vr_add_props(Object *obj, uint64_t *flags, uint8_t pages) > PMBusDevice *pmdev = PMBUS_DEVICE(obj); > for (int i = 0; i < pages; i++) { > if (flags[i] & PB_HAS_VIN) { > - object_property_add(obj, "vin[*]", "uint16", > + object_property_add_qapi(obj, "vin[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_vin); > } > > if (flags[i] & PB_HAS_VOUT) { > - object_property_add(obj, "vout[*]", "uint16", > + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_vout); > } > > if (flags[i] & PB_HAS_IIN) { > - object_property_add(obj, "iin[*]", "uint16", > + object_property_add_qapi(obj, "iin[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_iin); > } > > if (flags[i] & PB_HAS_IOUT) { > - object_property_add(obj, "iout[*]", "uint16", > + object_property_add_qapi(obj, "iout[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_iout); > } > > if (flags[i] & PB_HAS_PIN) { > - object_property_add(obj, "pin[*]", "uint16", > + object_property_add_qapi(obj, "pin[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_pin); > } > > if (flags[i] & PB_HAS_POUT) { > - object_property_add(obj, "pout[*]", "uint16", > + object_property_add_qapi(obj, "pout[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_pout); > } > > if (flags[i] & PB_HAS_TEMPERATURE) { > - object_property_add(obj, "temp1[*]", "uint16", > + object_property_add_qapi(obj, "temp1[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_temperature_1); > } > > if (flags[i] & PB_HAS_TEMP2) { > - object_property_add(obj, "temp2[*]", "uint16", > + object_property_add_qapi(obj, "temp2[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_temperature_2); > } > > if (flags[i] & PB_HAS_TEMP3) { > - object_property_add(obj, "temp3[*]", "uint16", > + object_property_add_qapi(obj, "temp3[*]", &uint16_type_info, > isl_pmbus_vr_get, > isl_pmbus_vr_set, > NULL, &pmdev->pages[i].read_temperature_3); > diff --git a/hw/sensor/lsm303dlhc_mag.c b/hw/sensor/lsm303dlhc_mag.c > index cd5773ae64e8..c8085739ca47 100644 > --- a/hw/sensor/lsm303dlhc_mag.c > +++ b/hw/sensor/lsm303dlhc_mag.c > @@ -25,6 +25,7 @@ > #include "hw/i2c/i2c.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > #include "qemu/log.h" > @@ -509,19 +510,19 @@ static void lsm303dlhc_mag_reset(DeviceState *dev) > */ > static void lsm303dlhc_mag_initfn(Object *obj) > { > - object_property_add(obj, "mag-x", "int", > + object_property_add_qapi(obj, "mag-x", &int_type_info, > lsm303dlhc_mag_get_x, > lsm303dlhc_mag_set_x, NULL, NULL); > > - object_property_add(obj, "mag-y", "int", > + object_property_add_qapi(obj, "mag-y", &int_type_info, > lsm303dlhc_mag_get_y, > lsm303dlhc_mag_set_y, NULL, NULL); > > - object_property_add(obj, "mag-z", "int", > + object_property_add_qapi(obj, "mag-z", &int_type_info, > lsm303dlhc_mag_get_z, > lsm303dlhc_mag_set_z, NULL, NULL); > > - object_property_add(obj, "temperature", "int", > + object_property_add_qapi(obj, "temperature", &int_type_info, > lsm303dlhc_mag_get_temperature, > lsm303dlhc_mag_set_temperature, NULL, NULL); > } > diff --git a/hw/sensor/max34451.c b/hw/sensor/max34451.c > index 4d64434f3af4..3c8fa3d4a861 100644 > --- a/hw/sensor/max34451.c > +++ b/hw/sensor/max34451.c > @@ -11,6 +11,7 @@ > #include "hw/core/irq.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/log.h" > #include "qemu/module.h" > @@ -727,7 +728,7 @@ static void max34451_init(Object *obj) > > /* get and set the voltage in millivolts, max is 32767 mV */ > for (int i = 0; i < MAX34451_NUM_PWR_DEVICES; i++) { > - object_property_add(obj, "vout[*]", "uint16", > + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, > max34451_get, > max34451_set, NULL, &pmdev->pages[i].read_vout); > } > @@ -737,7 +738,7 @@ static void max34451_init(Object *obj) > * centidegrees Celsius i.e.: 2500 -> 25.00 C, max is 327.67 C > */ > for (int i = 0; i < MAX34451_NUM_TEMP_DEVICES; i++) { > - object_property_add(obj, "temperature[*]", "uint16", > + object_property_add_qapi(obj, "temperature[*]", &uint16_type_info, > max34451_get, > max34451_set, > NULL, > diff --git a/hw/sensor/tmp105.c b/hw/sensor/tmp105.c > index c5089d74f4bf..ce4ff4856afb 100644 > --- a/hw/sensor/tmp105.c > +++ b/hw/sensor/tmp105.c > @@ -24,6 +24,7 @@ > #include "migration/vmstate.h" > #include "hw/sensor/tmp105.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > #include "hw/core/registerfields.h" > @@ -308,7 +309,7 @@ static void tmp105_realize(DeviceState *dev, Error **errp) > > static void tmp105_initfn(Object *obj) > { > - object_property_add(obj, "temperature", "int", > + object_property_add_qapi(obj, "temperature", &int_type_info, > tmp105_get_temperature, > tmp105_set_temperature, NULL, NULL); > } > diff --git a/hw/sensor/tmp421.c b/hw/sensor/tmp421.c > index 127edd0ba568..60844e76b21f 100644 > --- a/hw/sensor/tmp421.c > +++ b/hw/sensor/tmp421.c > @@ -28,6 +28,7 @@ > #include "hw/i2c/i2c.h" > #include "migration/vmstate.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > #include "qom/object.h" > @@ -350,16 +351,16 @@ static void tmp421_class_init(ObjectClass *klass, const void *data) > dc->vmsd = &vmstate_tmp421; > sc->dev = (DeviceInfo *) data; > > - object_class_property_add(klass, "temperature0", "int", > + object_class_property_add_qapi(klass, "temperature0", &int_type_info, > tmp421_get_temperature, > tmp421_set_temperature, NULL, NULL); > - object_class_property_add(klass, "temperature1", "int", > + object_class_property_add_qapi(klass, "temperature1", &int_type_info, > tmp421_get_temperature, > tmp421_set_temperature, NULL, NULL); > - object_class_property_add(klass, "temperature2", "int", > + object_class_property_add_qapi(klass, "temperature2", &int_type_info, > tmp421_get_temperature, > tmp421_set_temperature, NULL, NULL); > - object_class_property_add(klass, "temperature3", "int", > + object_class_property_add_qapi(klass, "temperature3", &int_type_info, > tmp421_get_temperature, > tmp421_set_temperature, NULL, NULL); > } > diff --git a/hw/usb/dev-storage-classic.c b/hw/usb/dev-storage-classic.c > index 977151c4a087..06584092bcae 100644 > --- a/hw/usb/dev-storage-classic.c > +++ b/hw/usb/dev-storage-classic.c > @@ -9,6 +9,7 @@ > > #include "qemu/osdep.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/usb/usb.h" > #include "hw/usb/desc.h" > @@ -122,7 +123,7 @@ out: > > static void usb_msd_instance_init(Object *obj) > { > - object_property_add(obj, "bootindex", "int32", > + object_property_add_qapi(obj, "bootindex", &int32_type_info, > usb_msd_get_bootindex, > usb_msd_set_bootindex, NULL, NULL); > object_property_set_int(obj, "bootindex", -1, NULL); > diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c > index 4c5f486ba238..9e43948128f7 100644 > --- a/hw/virtio/virtio-balloon.c > +++ b/hw/virtio/virtio-balloon.c > @@ -27,6 +27,7 @@ > #include "hw/virtio/virtio-balloon.h" > #include "system/address-spaces.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-events-machine.h" > #include "qapi/visitor.h" > #include "trace.h" > @@ -1022,7 +1023,7 @@ static void virtio_balloon_instance_init(Object *obj) > object_property_add(obj, "guest-stats", "guest statistics", > balloon_stats_get_all, NULL, NULL, NULL); > > - object_property_add(obj, "guest-stats-polling-interval", "int", > + object_property_add_qapi(obj, "guest-stats-polling-interval", &int_type_info, > balloon_stats_get_poll_interval, > balloon_stats_set_poll_interval, > NULL, NULL); > diff --git a/hw/virtio/virtio-mem-pci.c b/hw/virtio/virtio-mem-pci.c > index f592eb1a7849..80e9bfedd9f5 100644 > --- a/hw/virtio/virtio-mem-pci.c > +++ b/hw/virtio/virtio-mem-pci.c > @@ -14,6 +14,7 @@ > #include "virtio-mem-pci.h" > #include "hw/mem/memory-device.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-events-machine.h" > #include "qapi/qapi-events-misc.h" > > @@ -211,7 +212,7 @@ static void virtio_mem_pci_instance_init(Object *obj) > OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZE_PROP); > object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->vdev), > VIRTIO_MEM_SIZE_PROP); > - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", > + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, > virtio_mem_pci_get_requested_size, > virtio_mem_pci_set_requested_size, NULL, NULL); > } > diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c > index 7130ed852d9c..42dc028e3bdc 100644 > --- a/hw/virtio/virtio-mem.c > +++ b/hw/virtio/virtio-mem.c > @@ -26,6 +26,7 @@ > #include "hw/virtio/virtio-bus.h" > #include "hw/virtio/virtio-mem.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "migration/misc.h" > #include "hw/core/boards.h" > @@ -1533,14 +1534,15 @@ static void virtio_mem_instance_init(Object *obj) > > notifier_list_init(&vmem->size_change_notifiers); > > - object_property_add(obj, VIRTIO_MEM_SIZE_PROP, "size", virtio_mem_get_size, > - NULL, NULL, NULL); > - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", > - virtio_mem_get_requested_size, > - virtio_mem_set_requested_size, NULL, NULL); > - object_property_add(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, "size", > - virtio_mem_get_block_size, virtio_mem_set_block_size, > - NULL, NULL); > + object_property_add_qapi(obj, VIRTIO_MEM_SIZE_PROP, &size_type_info, > + virtio_mem_get_size, > + NULL, NULL, NULL); > + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, > + virtio_mem_get_requested_size, > + virtio_mem_set_requested_size, NULL, NULL); > + object_property_add_qapi(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, &size_type_info, > + virtio_mem_get_block_size, virtio_mem_set_block_size, > + NULL, NULL); > } > > static void virtio_mem_instance_finalize(Object *obj) > diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c > index cca37202ffb2..7b4fd933a8fb 100644 > --- a/hw/xen/xen-pvh-common.c > +++ b/hw/xen/xen-pvh-common.c > @@ -9,6 +9,7 @@ > #include "qemu/osdep.h" > #include "qemu/error-report.h" > #include "qemu/units.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "hw/core/boards.h" > #include "hw/core/irq.h" > @@ -413,7 +414,7 @@ void xen_pvh_class_setup_common_props(XenPVHMachineClass *xpc) > > #define OC_MEMMAP_PROP_BASE(c, prop_name, name) \ > do { \ > - object_class_property_add(c, prop_name "-base", "uint64_t", \ > + object_class_property_add_qapi(c, prop_name "-base", &uint64_type_info,\ > xen_pvh_get_ ## name ## _base, \ > xen_pvh_set_ ## name ## _base, NULL, NULL); \ > object_class_property_set_description(oc, prop_name "-base", \ > @@ -422,7 +423,7 @@ do { \ > > #define OC_MEMMAP_PROP_SIZE(c, prop_name, name) \ > do { \ > - object_class_property_add(c, prop_name "-size", "uint64_t", \ > + object_class_property_add_qapi(c, prop_name "-size", &size_type_info, \ > xen_pvh_get_ ## name ## _size, \ > xen_pvh_set_ ## name ## _size, NULL, NULL); \ > object_class_property_set_description(oc, prop_name "-size", \ > @@ -458,7 +459,7 @@ do { \ > OC_MEMMAP_PROP(oc, "pci-mmio", pci_mmio); > OC_MEMMAP_PROP(oc, "pci-mmio-high", pci_mmio_high); > > - object_class_property_add(oc, "pci-intx-irq-base", "uint32_t", > + object_class_property_add_qapi(oc, "pci-intx-irq-base", &uint32_type_info, > xen_pvh_get_pci_intx_irq_base, > xen_pvh_set_pci_intx_irq_base, > NULL, NULL); > @@ -468,7 +469,7 @@ do { \ > > #ifdef CONFIG_TPM > if (xpc->has_tpm) { > - object_class_property_add(oc, "tpm-base-addr", "uint64_t", > + object_class_property_add_qapi(oc, "tpm-base-addr", &uint64_type_info, > xen_pvh_get_tpm_base, > xen_pvh_set_tpm_base, > NULL, NULL); > diff --git a/iothread.c b/iothread.c > index 76eea6df3861..7285135d40a8 100644 > --- a/iothread.c > +++ b/iothread.c > @@ -20,6 +20,7 @@ > #include "system/event-loop-base.h" > #include "system/iothread.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-commands-misc.h" > #include "qemu/error-report.h" > #include "qemu/rcu.h" > @@ -315,19 +316,19 @@ static void iothread_class_init(ObjectClass *klass, const void *class_data) > bc->init = iothread_init; > bc->update_params = iothread_set_aio_context_params; > > - object_class_property_add(klass, "poll-max-ns", "int64", > + object_class_property_add_qapi(klass, "poll-max-ns", &int64_type_info, > iothread_get_poll_param, > iothread_set_poll_param, > NULL, &poll_max_ns_info); > - object_class_property_add(klass, "poll-grow", "int64", > + object_class_property_add_qapi(klass, "poll-grow", &int64_type_info, > iothread_get_poll_param, > iothread_set_poll_param, > NULL, &poll_grow_info); > - object_class_property_add(klass, "poll-shrink", "int64", > + object_class_property_add_qapi(klass, "poll-shrink", &int64_type_info, > iothread_get_poll_param, > iothread_set_poll_param, > NULL, &poll_shrink_info); > - object_class_property_add(klass, "poll-weight", "int64", > + object_class_property_add_qapi(klass, "poll-weight", &int64_type_info, > iothread_get_poll_param, > iothread_set_poll_param, > NULL, &poll_weight_info); > diff --git a/net/colo-compare.c b/net/colo-compare.c > index a6910de869ff..4b237a59d120 100644 > --- a/net/colo-compare.c > +++ b/net/colo-compare.c > @@ -16,6 +16,7 @@ > #include "qemu/error-report.h" > #include "trace.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "net/net.h" > #include "net/eth.h" > #include "qom/object_interfaces.h" > @@ -1373,15 +1374,15 @@ static void colo_compare_init(Object *obj) > object_property_add_str(obj, "notify_dev", > compare_get_notify_dev, compare_set_notify_dev); > > - object_property_add(obj, "compare_timeout", "uint64", > + object_property_add_qapi(obj, "compare_timeout", &uint64_type_info, > compare_get_timeout, > compare_set_timeout, NULL, NULL); > > - object_property_add(obj, "expired_scan_cycle", "uint32", > + object_property_add_qapi(obj, "expired_scan_cycle", &uint32_type_info, > compare_get_expired_scan_cycle, > compare_set_expired_scan_cycle, NULL, NULL); > > - object_property_add(obj, "max_queue_size", "uint32", > + object_property_add_qapi(obj, "max_queue_size", &uint32_type_info, > get_max_queue_size, > set_max_queue_size, NULL, NULL); > > diff --git a/net/dump.c b/net/dump.c > index 0c39f09892c2..3d7bb36182ec 100644 > --- a/net/dump.c > +++ b/net/dump.c > @@ -25,6 +25,7 @@ > #include "qemu/osdep.h" > #include "clients.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qemu/error-report.h" > #include "qemu/iov.h" > #include "qemu/module.h" > @@ -238,8 +239,9 @@ static void filter_dump_class_init(ObjectClass *oc, const void *data) > { > NetFilterClass *nfc = NETFILTER_CLASS(oc); > > - object_class_property_add(oc, "maxlen", "uint32", filter_dump_get_maxlen, > - filter_dump_set_maxlen, NULL, NULL); > + object_class_property_add_qapi(oc, "maxlen", &uint32_type_info, > + filter_dump_get_maxlen, > + filter_dump_set_maxlen, NULL, NULL); > object_class_property_add_str(oc, "file", file_dump_get_filename, > file_dump_set_filename); > > diff --git a/net/filter-buffer.c b/net/filter-buffer.c > index 427da24097f2..9d7a9f5cb2c7 100644 > --- a/net/filter-buffer.c > +++ b/net/filter-buffer.c > @@ -10,6 +10,7 @@ > #include "net/filter.h" > #include "net/queue.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qemu/timer.h" > #include "qemu/iov.h" > #include "qapi/qapi-builtin-visit.h" > @@ -182,7 +183,7 @@ static void filter_buffer_class_init(ObjectClass *oc, const void *data) > { > NetFilterClass *nfc = NETFILTER_CLASS(oc); > > - object_class_property_add(oc, "interval", "uint32", > + object_class_property_add_qapi(oc, "interval", &uint32_type_info, > filter_buffer_get_interval, > filter_buffer_set_interval, NULL, NULL); > > diff --git a/qom/object.c b/qom/object.c > index 8e6ca25dc49d..bbaa999ae0c9 100644 > --- a/qom/object.c > +++ b/qom/object.c > @@ -22,9 +22,9 @@ > #include "qapi/string-output-visitor.h" > #include "qapi/qobject-input-visitor.h" > #include "qapi/forward-visitor.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-builtin-visit.h" > #include "qobject/qdict.h" > -#include "qobject/qjson.h" > #include "qemu/id.h" > #include "qapi/qmp/qerror.h" > #include "trace.h" > @@ -2429,7 +2429,7 @@ object_property_add_str(Object *obj, const char *name, > prop->get = get; > prop->set = set; > > - return object_property_add(obj, name, "string", > + return object_property_add_qapi(obj, name, &str_type_info, > get ? property_get_str : NULL, > set ? property_set_str : NULL, > property_release_data, > @@ -2447,7 +2447,7 @@ object_class_property_add_str(ObjectClass *klass, const char *name, > prop->get = get; > prop->set = set; > > - return object_class_property_add(klass, name, "string", > + return object_class_property_add_qapi(klass, name, &str_type_info, > get ? property_get_str : NULL, > set ? property_set_str : NULL, > NULL, > @@ -2499,7 +2499,7 @@ object_property_add_bool(Object *obj, const char *name, > prop->get = get; > prop->set = set; > > - return object_property_add(obj, name, "bool", > + return object_property_add_qapi(obj, name, &bool_type_info, > get ? property_get_bool : NULL, > set ? property_set_bool : NULL, > property_release_data, > @@ -2516,7 +2516,7 @@ object_class_property_add_bool(ObjectClass *klass, const char *name, > prop->get = get; > prop->set = set; > > - return object_class_property_add(klass, name, "bool", > + return object_class_property_add_qapi(klass, name, &bool_type_info, > get ? property_get_bool : NULL, > set ? property_set_bool : NULL, > NULL, > @@ -2856,8 +2856,8 @@ object_property_add_uint8_ptr(Object *obj, const char *name, > setter = property_set_uint8_ptr; > } > > - return object_property_add(obj, name, "uint8", > - getter, setter, NULL, (void *)v); > + return object_property_add_qapi(obj, name, &uint8_type_info, > + getter, setter, NULL, (void *)v); > } > > ObjectProperty * > @@ -2897,8 +2897,8 @@ object_class_static_property_add_uint8_ptr(ObjectClass *klass, > setter = property_set_uint8_ptr; > } > > - return object_class_property_add(klass, name, "uint8", > - getter, setter, NULL, (void *)v); > + return object_class_property_add_qapi(klass, name, &uint8_type_info, > + getter, setter, NULL, (void *)v); > } > > ObjectProperty * > @@ -2917,8 +2917,8 @@ object_property_add_uint16_ptr(Object *obj, const char *name, > setter = property_set_uint16_ptr; > } > > - return object_property_add(obj, name, "uint16", > - getter, setter, NULL, (void *)v); > + return object_property_add_qapi(obj, name, &uint16_type_info, > + getter, setter, NULL, (void *)v); > } > > ObjectProperty * > @@ -2958,8 +2958,8 @@ object_class_static_property_add_uint16_ptr(ObjectClass *klass, > setter = property_set_uint16_ptr; > } > > - return object_class_property_add(klass, name, "uint16", > - getter, setter, NULL, (void *)v); > + return object_class_property_add_qapi(klass, name, &uint16_type_info, > + getter, setter, NULL, (void *)v); > } > > ObjectProperty * > @@ -2978,8 +2978,8 @@ object_property_add_uint32_ptr(Object *obj, const char *name, > setter = property_set_uint32_ptr; > } > > - return object_property_add(obj, name, "uint32", > - getter, setter, NULL, (void *)v); > + return object_property_add_qapi(obj, name, &uint32_type_info, > + getter, setter, NULL, (void *)v); > } > > ObjectProperty * > @@ -3019,8 +3019,8 @@ object_class_static_property_add_uint32_ptr(ObjectClass *klass, > setter = property_set_uint32_ptr; > } > > - return object_class_property_add(klass, name, "uint32", > - getter, setter, NULL, (void *)v); > + return object_class_property_add_qapi(klass, name, &uint32_type_info, > + getter, setter, NULL, (void *)v); > } > > ObjectProperty * > @@ -3039,8 +3039,8 @@ object_property_add_uint64_ptr(Object *obj, const char *name, > setter = property_set_uint64_ptr; > } > > - return object_property_add(obj, name, "uint64", > - getter, setter, NULL, (void *)v); > + return object_property_add_qapi(obj, name, &uint64_type_info, > + getter, setter, NULL, (void *)v); > } > > ObjectProperty * > @@ -3080,8 +3080,8 @@ object_class_static_property_add_uint64_ptr(ObjectClass *klass, > setter = property_set_uint64_ptr; > } > > - return object_class_property_add(klass, name, "uint64", > - getter, setter, NULL, (void *)v); > + return object_class_property_add_qapi(klass, name, &uint64_type_info, > + getter, setter, NULL, (void *)v); > } > > typedef struct { > diff --git a/system/bootdevice.c b/system/bootdevice.c > index 9538b08983f5..7789e464186a 100644 > --- a/system/bootdevice.c > +++ b/system/bootdevice.c > @@ -24,6 +24,7 @@ > > #include "qemu/osdep.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "system/system.h" > #include "qapi/visitor.h" > #include "qemu/error-report.h" > @@ -336,7 +337,7 @@ void device_add_bootindex_property(Object *obj, int32_t *bootindex, > prop->suffix = suffix; > prop->dev = dev; > > - object_property_add(obj, name, "int32", > + object_property_add_qapi(obj, name, &int32_type_info, > device_get_bootindex, > device_set_bootindex, > property_release_bootindex, > diff --git a/system/memory.c b/system/memory.c > index d4a0a5b81805..ae768cba80bd 100644 > --- a/system/memory.c > +++ b/system/memory.c > @@ -16,6 +16,7 @@ > #include "qemu/osdep.h" > #include "qemu/log.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "system/memory.h" > #include "qapi/visitor.h" > #include "qemu/bitops.h" > @@ -1318,11 +1319,11 @@ static void memory_region_initfn(Object *obj) > > object_property_add_uint64_ptr(OBJECT(mr), "addr", > &mr->addr, OBJ_PROP_FLAG_READ); > - object_property_add(OBJECT(mr), "priority", "int32", > + object_property_add_qapi(OBJECT(mr), "priority", &int32_type_info, > memory_region_get_priority, > NULL, /* memory_region_set_priority */ > NULL, NULL); > - object_property_add(OBJECT(mr), "size", "uint64", > + object_property_add_qapi(OBJECT(mr), "size", &uint64_type_info, > memory_region_get_size, > NULL, /* memory_region_set_size, */ > NULL, NULL); > diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c > index 4e8c47253086..55df765e64d1 100644 > --- a/target/arm/cpu64.c > +++ b/target/arm/cpu64.c > @@ -20,6 +20,7 @@ > > #include "qemu/osdep.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "cpu.h" > #include "cpregs.h" > #include "qemu/module.h" > @@ -320,7 +321,7 @@ static void prop_bool_set_false(Object *obj, Visitor *v, const char *name, > > static void prop_add_stub_bool(Object *obj, const char *name) > { > - object_property_add(obj, name, "bool", prop_bool_get_false, > + object_property_add_qapi(obj, name, &bool_type_info, prop_bool_get_false, > prop_bool_set_false, NULL, NULL); > } > > @@ -510,13 +511,13 @@ void aarch64_add_sve_properties(Object *obj) > for (vq = 1; vq <= ARM_MAX_VQ; ++vq) { > char name[8]; > snprintf(name, sizeof(name), "sve%d", vq * 128); > - object_property_add(obj, name, "bool", cpu_arm_get_vq, > + object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_get_vq, > cpu_arm_set_vq, NULL, &cpu->sve_vq); > } > > #ifdef CONFIG_USER_ONLY > /* Mirror linux /proc/sys/abi/sve_default_vector_length. */ > - object_property_add(obj, "sve-default-vector-length", "int32", > + object_property_add_qapi(obj, "sve-default-vector-length", &int32_type_info, > cpu_arm_get_default_vec_len, > cpu_arm_set_default_vec_len, NULL, > &cpu->sve_default_vq); > @@ -535,13 +536,13 @@ void aarch64_add_sme_properties(Object *obj) > for (vq = 1; vq <= ARM_MAX_VQ; vq <<= 1) { > char name[8]; > snprintf(name, sizeof(name), "sme%d", vq * 128); > - object_property_add(obj, name, "bool", cpu_arm_get_vq, > + object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_get_vq, > cpu_arm_set_vq, NULL, &cpu->sme_vq); > } > > #ifdef CONFIG_USER_ONLY > /* Mirror linux /proc/sys/abi/sme_default_vector_length. */ > - object_property_add(obj, "sme-default-vector-length", "int32", > + object_property_add_qapi(obj, "sme-default-vector-length", &int32_type_info, > cpu_arm_get_default_vec_len, > cpu_arm_set_default_vec_len, NULL, > &cpu->sme_default_vq); > diff --git a/target/arm/kvm.c b/target/arm/kvm.c > index ed99be7fd80c..198b7615f4cc 100644 > --- a/target/arm/kvm.c > +++ b/target/arm/kvm.c > @@ -20,6 +20,7 @@ > #include "qemu/main-loop.h" > #include "qom/object.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "system/system.h" > #include "system/runstate.h" > #include "system/ramblock.h" > @@ -1777,7 +1778,7 @@ static void kvm_arch_set_eager_split_size(Object *obj, Visitor *v, > > void kvm_arch_accel_class_init(ObjectClass *oc) > { > - object_class_property_add(oc, "eager-split-size", "size", > + object_class_property_add_qapi(oc, "eager-split-size", &size_type_info, > kvm_arch_get_eager_split_size, > kvm_arch_set_eager_split_size, NULL, NULL); > > diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c > index affd87a3ae55..da8d44f1fc61 100644 > --- a/target/arm/tcg/cpu64.c > +++ b/target/arm/tcg/cpu64.c > @@ -20,6 +20,7 @@ > > #include "qemu/osdep.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "cpu.h" > #include "qemu/module.h" > #include "qapi/visitor.h" > @@ -1392,9 +1393,9 @@ void aarch64_max_v8_tcg_initfn(Object *obj) > /* v8.2: FEAT_SVE */ > cpu->sve_vq.supported = MAKE_64BIT_MASK(0, ARM_MAX_VQ); > aarch64_add_sve_properties(OBJECT(cpu)); > - object_property_add(OBJECT(cpu), "sve-max-vq", "uint32", > - cpu_max_get_sve_max_vq, cpu_max_set_sve_max_vq, > - NULL, NULL); > + object_property_add_qapi(OBJECT(cpu), "sve-max-vq", &uint32_type_info, > + cpu_max_get_sve_max_vq, > + cpu_max_set_sve_max_vq, NULL, NULL); > > /* v8.2: FEAT_PAuth2 */ > aarch64_add_pauth_properties(OBJECT(cpu)); > @@ -1524,8 +1525,8 @@ void aarch64_max_v9_tcg_initfn(Object *obj) > object_property_add_bool(obj, "x-rme", cpu_arm_get_rme, cpu_arm_set_rme); > > /* v9.4: FEAT_RME_GPC2 */ > - object_property_add(obj, "x-l0gptsz", "uint32", cpu_max_get_l0gptsz, > - cpu_max_set_l0gptsz, NULL, NULL); > + object_property_add_qapi(obj, "x-l0gptsz", &uint32_type_info, cpu_max_get_l0gptsz, > + cpu_max_set_l0gptsz, NULL, NULL); > } > > static const ARMCPUInfo aarch64_cpus[] = { > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index 8650ff6caecc..ebce8e128224 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -10431,7 +10431,7 @@ static void x86_cpu_register_bit_prop(X86CPUClass *xcc, > fp = g_new0(BitProperty, 1); > fp->w = w; > fp->mask = mask; > - object_class_property_add(oc, prop_name, "bool", > + object_class_property_add_qapi(oc, prop_name, &bool_type_info, > x86_cpu_get_bit_prop, > x86_cpu_set_bit_prop, > NULL, fp); > @@ -10950,13 +10950,13 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) > > dc->user_creatable = true; > > - object_class_property_add(oc, "family", "uint64", > + object_class_property_add_qapi(oc, "family", &uint64_type_info, > x86_cpuid_version_get_family, > x86_cpuid_version_set_family, NULL, NULL); > - object_class_property_add(oc, "model", "uint64", > + object_class_property_add_qapi(oc, "model", &uint64_type_info, > x86_cpuid_version_get_model, > x86_cpuid_version_set_model, NULL, NULL); > - object_class_property_add(oc, "stepping", "uint64", > + object_class_property_add_qapi(oc, "stepping", &uint64_type_info, > x86_cpuid_version_get_stepping, > x86_cpuid_version_set_stepping, NULL, NULL); > object_class_property_add_str(oc, "vendor", > @@ -10965,7 +10965,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) > object_class_property_add_str(oc, "model-id", > x86_cpuid_get_model_id, > x86_cpuid_set_model_id); > - object_class_property_add(oc, "tsc-frequency", "int", > + object_class_property_add_qapi(oc, "tsc-frequency", &int_type_info, > x86_cpuid_get_tsc_freq, > x86_cpuid_set_tsc_freq, NULL, NULL); > /* > @@ -10978,7 +10978,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) > x86_cpu_get_unavailable_features, > NULL, NULL, NULL); > > - object_class_property_add(oc, "avx10-version", "uint8", > + object_class_property_add_qapi(oc, "avx10-version", &uint8_type_info, > x86_cpuid_get_avx10_version, > x86_cpuid_set_avx10_version, > NULL, NULL); > diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c > index 9f65419a2c1a..aa4967adf99e 100644 > --- a/target/i386/kvm/kvm.c > +++ b/target/i386/kvm/kvm.c > @@ -7099,7 +7099,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc) > .set = kvm_arch_set_notify_vmexit, > )); > > - object_class_property_add(oc, "notify-window", "uint32", > + object_class_property_add_qapi(oc, "notify-window", &uint32_type_info, > kvm_arch_get_notify_window, > kvm_arch_set_notify_window, > NULL, NULL); > @@ -7107,7 +7107,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc) > "Clock cycles without an event window " > "after which a notification VM exit occurs"); > > - object_class_property_add(oc, "xen-version", "uint32", > + object_class_property_add_qapi(oc, "xen-version", &uint32_type_info, > kvm_arch_get_xen_version, > kvm_arch_set_xen_version, > NULL, NULL); > @@ -7116,14 +7116,14 @@ void kvm_arch_accel_class_init(ObjectClass *oc) > "(in XENVER_version form " > "e.g. 0x4000a for 4.10)"); > > - object_class_property_add(oc, "xen-gnttab-max-frames", "uint16", > + object_class_property_add_qapi(oc, "xen-gnttab-max-frames", &uint16_type_info, > kvm_arch_get_xen_gnttab_max_frames, > kvm_arch_set_xen_gnttab_max_frames, > NULL, NULL); > object_class_property_set_description(oc, "xen-gnttab-max-frames", > "Maximum number of grant table frames"); > > - object_class_property_add(oc, "xen-evtchn-max-pirq", "uint16", > + object_class_property_add_qapi(oc, "xen-evtchn-max-pirq", &uint16_type_info, > kvm_arch_get_xen_evtchn_max_pirq, > kvm_arch_set_xen_evtchn_max_pirq, > NULL, NULL); > diff --git a/target/i386/sev.c b/target/i386/sev.c > index b2c7260c80a4..3a36fa4d0b95 100644 > --- a/target/i386/sev.c > +++ b/target/i386/sev.c > @@ -3266,7 +3266,7 @@ sev_snp_guest_class_init(ObjectClass *oc, const void *data) > x86_klass->adjust_cpuid_features = sev_snp_adjust_cpuid_features; > x86_klass->kvm_type = sev_snp_kvm_type; > > - object_class_property_add(oc, "policy", "uint64", > + object_class_property_add_qapi(oc, "policy", &uint64_type_info, > sev_snp_guest_get_policy, > sev_snp_guest_set_policy, NULL, NULL); > object_class_property_add_str(oc, "guest-visible-workarounds", > diff --git a/target/ppc/compat.c b/target/ppc/compat.c > index 55de3bd5d5de..4d81225de37f 100644 > --- a/target/ppc/compat.c > +++ b/target/ppc/compat.c > @@ -23,6 +23,7 @@ > #include "kvm_ppc.h" > #include "system/cpus.h" > #include "qemu/error-report.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/error.h" > #include "qapi/visitor.h" > #include "cpu-models.h" > @@ -335,7 +336,7 @@ void ppc_compat_add_property(Object *obj, const char *name, > gchar *names, *desc; > int i; > > - object_property_add(obj, name, "string", > + object_property_add_qapi(obj, name, &str_type_info, > ppc_compat_prop_get, ppc_compat_prop_set, NULL, > compat_pvr); > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > index fd1afbc7fe23..a1faea801d1d 100644 > --- a/target/riscv/cpu.c > +++ b/target/riscv/cpu.c > @@ -27,6 +27,7 @@ > #include "target/riscv/tcg/csr.h" > #include "internals.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/error-report.h" > #include "qemu/timer.h" > @@ -1396,20 +1397,20 @@ void riscv_add_satp_mode_properties(Object *obj) > { > RISCVCPU *cpu = RISCV_CPU(obj); > > - object_property_add(obj, "svbare", "bool", cpu_riscv_get_satp, > - cpu_riscv_set_satp, NULL, &cpu->satp_modes); > + object_property_add_qapi(obj, "svbare", &bool_type_info, cpu_riscv_get_satp, > + cpu_riscv_set_satp, NULL, &cpu->satp_modes); > > if (cpu->env.misa_mxl == MXL_RV32) { > - object_property_add(obj, "sv32", "bool", cpu_riscv_get_satp, > + object_property_add_qapi(obj, "sv32", &bool_type_info, cpu_riscv_get_satp, > cpu_riscv_set_satp, NULL, &cpu->satp_modes); > } else { > - object_property_add(obj, "sv39", "bool", cpu_riscv_get_satp, > + object_property_add_qapi(obj, "sv39", &bool_type_info, cpu_riscv_get_satp, > cpu_riscv_set_satp, NULL, &cpu->satp_modes); > - object_property_add(obj, "sv48", "bool", cpu_riscv_get_satp, > + object_property_add_qapi(obj, "sv48", &bool_type_info, cpu_riscv_get_satp, > cpu_riscv_set_satp, NULL, &cpu->satp_modes); > - object_property_add(obj, "sv57", "bool", cpu_riscv_get_satp, > + object_property_add_qapi(obj, "sv57", &bool_type_info, cpu_riscv_get_satp, > cpu_riscv_set_satp, NULL, &cpu->satp_modes); > - object_property_add(obj, "sv64", "bool", cpu_riscv_get_satp, > + object_property_add_qapi(obj, "sv64", &bool_type_info, cpu_riscv_get_satp, > cpu_riscv_set_satp, NULL, &cpu->satp_modes); > } > } > diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c > index 68e1501b21e2..d2d6cb7a4c66 100644 > --- a/target/riscv/kvm/kvm-cpu.c > +++ b/target/riscv/kvm/kvm-cpu.c > @@ -24,6 +24,7 @@ > > #include "qemu/timer.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qemu/error-report.h" > #include "qemu/main-loop.h" > #include "qapi/visitor.h" > @@ -532,7 +533,7 @@ static void riscv_cpu_add_kvm_unavail_prop(Object *obj, const char *prop_name) > * unknown to KVM and error out if the user attempts > * to enable any of them. > */ > - object_property_add(obj, prop_name, "bool", > + object_property_add_qapi(obj, prop_name, &bool_type_info, > cpu_get_cfg_unavailable, > cpu_set_cfg_unavailable, > NULL, (void *)prop_name); > @@ -552,7 +553,7 @@ static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj) > misa_cfg->name = riscv_get_misa_ext_name(bit); > misa_cfg->description = riscv_get_misa_ext_description(bit); > > - object_property_add(cpu_obj, misa_cfg->name, "bool", > + object_property_add_qapi(cpu_obj, misa_cfg->name, &bool_type_info, > kvm_cpu_get_misa_ext_cfg, > kvm_cpu_set_misa_ext_cfg, > NULL, misa_cfg); > @@ -568,7 +569,7 @@ static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj) > for (i = 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) { > KVMCPUConfig *multi_cfg = &kvm_multi_ext_cfgs[i]; > > - object_property_add(cpu_obj, multi_cfg->name, "bool", > + object_property_add_qapi(cpu_obj, multi_cfg->name, &bool_type_info, > kvm_cpu_get_multi_ext_cfg, > kvm_cpu_set_multi_ext_cfg, > NULL, multi_cfg); > diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c > index 9e3cc87f8a31..92e03a386832 100644 > --- a/target/riscv/tcg/tcg-cpu.c > +++ b/target/riscv/tcg/tcg-cpu.c > @@ -26,6 +26,7 @@ > #include "pmu.h" > #include "time_helper.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > #include "qemu/accel.h" > #include "qemu/error-report.h" > @@ -1438,7 +1439,7 @@ static void riscv_cpu_add_misa_properties(Object *cpu_obj) > continue; > } > > - object_property_add(cpu_obj, name, "bool", > + object_property_add_qapi(cpu_obj, name, &bool_type_info, > cpu_get_misa_ext_cfg, > cpu_set_misa_ext_cfg, > NULL, (void *)misa_cfg); > @@ -1492,7 +1493,7 @@ static void riscv_cpu_add_profiles(Object *cpu_obj) > for (int i = 0; riscv_profiles[i] != NULL; i++) { > RISCVCPUProfile *profile = riscv_profiles[i]; > > - object_property_add(cpu_obj, profile->name, "bool", > + object_property_add_qapi(cpu_obj, profile->name, &bool_type_info, > cpu_get_profile, cpu_set_profile, > NULL, (void *)profile); > > @@ -1568,10 +1569,10 @@ static void riscv_cpu_add_user_properties(Object *obj) > > for (edata = isa_edata_arr; edata && edata->name; edata++) { > if (edata->prop_name) { > - object_property_add(obj, edata->prop_name, "bool", > - cpu_get_multi_ext_cfg, > - cpu_set_multi_ext_cfg, > - NULL, (void *)&edata->ext_enable_offset); > + object_property_add_qapi(obj, edata->prop_name, &bool_type_info, > + cpu_get_multi_ext_cfg, > + cpu_set_multi_ext_cfg, > + NULL, (void *)&edata->ext_enable_offset); > } > } > > diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c > index c41d629d6803..72bf0f48de83 100644 > --- a/target/s390x/cpu_models.c > +++ b/target/s390x/cpu_models.c > @@ -17,6 +17,7 @@ > #include "system/kvm.h" > #include "system/tcg.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qemu/error-report.h" > #include "qapi/visitor.h" > #include "qemu/module.h" > @@ -915,13 +916,13 @@ void s390_cpu_model_class_register_props(ObjectClass *oc) > > for (feat = 0; feat < S390_FEAT_MAX; feat++) { > const S390FeatDef *def = s390_feat_def(feat); > - object_class_property_add(oc, def->name, "bool", get_feature, > + object_class_property_add_qapi(oc, def->name, &bool_type_info, get_feature, > set_feature, NULL, (void *) feat); > object_class_property_set_description(oc, def->name, def->desc); > } > for (group = 0; group < S390_FEAT_GROUP_MAX; group++) { > const S390FeatGroupDef *def = s390_feat_group_def(group); > - object_class_property_add(oc, def->name, "bool", get_feature_group, > + object_class_property_add_qapi(oc, def->name, &bool_type_info, get_feature_group, > set_feature_group, NULL, (void *) group); > object_class_property_set_description(oc, def->name, def->desc); > } > diff --git a/tests/unit/test-qdev-global-props.c b/tests/unit/test-qdev-global-props.c > index 8ea362cbb902..204436fb7276 100644 > --- a/tests/unit/test-qdev-global-props.c > +++ b/tests/unit/test-qdev-global-props.c > @@ -27,6 +27,7 @@ > #include "hw/core/qdev-properties.h" > #include "qom/object.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/visitor.h" > > > @@ -171,10 +172,12 @@ static void prop2_accessor(Object *obj, Visitor *v, const char *name, > > static void dynamic_instance_init(Object *obj) > { > - object_property_add(obj, "prop1", "uint32", prop1_accessor, prop1_accessor, > - NULL, NULL); > - object_property_add(obj, "prop2", "uint32", prop2_accessor, prop2_accessor, > - NULL, NULL); > + object_property_add_qapi(obj, "prop1", &uint32_type_info, > + prop1_accessor, prop1_accessor, > + NULL, NULL); > + object_property_add_qapi(obj, "prop2", &uint32_type_info, > + prop2_accessor, prop2_accessor, > + NULL, NULL); > } > > static void dynamic_class_init(ObjectClass *oc, const void *data) > diff --git a/ui/console.c b/ui/console.c > index a8a2a247d8f4..b4345b06d012 100644 > --- a/ui/console.c > +++ b/ui/console.c > @@ -28,6 +28,7 @@ > #include "ui/vgafont.h" > #include "hw/core/qdev.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-commands-ui.h" > #include "qapi/visitor.h" > #include "qemu/coroutine.h" > @@ -535,7 +536,7 @@ qemu_graphic_console_class_init(ObjectClass *oc, const void *data) > offsetof(QemuGraphicConsole, device), > object_property_allow_set_link, > OBJ_PROP_LINK_STRONG); > - object_class_property_add(oc, "head", "uint32", > + object_class_property_add_qapi(oc, "head", &uint32_type_info, > qemu_graphic_console_prop_get_head, > NULL, NULL, NULL); > > diff --git a/util/thread-context.c b/util/thread-context.c > index 88d8f0a55a4e..7fa6840dd401 100644 > --- a/util/thread-context.c > +++ b/util/thread-context.c > @@ -13,6 +13,7 @@ > #include "qemu/osdep.h" > #include "qemu/thread-context.h" > #include "qapi/error.h" > +#include "qapi/qapi-builtin-type-infos.h" > #include "qapi/qapi-builtin-visit.h" > #include "qapi/visitor.h" > #include "qemu/config-file.h" > @@ -278,13 +279,13 @@ static void thread_context_class_init(ObjectClass *oc, const void *data) > UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc); > > ucc->complete = thread_context_instance_complete; > - object_class_property_add(oc, "thread-id", "uint64", > + object_class_property_add_qapi(oc, "thread-id", &uint64_type_info, > thread_context_get_thread_id, NULL, NULL, > NULL); > - object_class_property_add(oc, "cpu-affinity", "[uint16]", > + object_class_property_add_qapi(oc, "cpu-affinity", &uint16List_type_info, > thread_context_get_cpu_affinity, > thread_context_set_cpu_affinity, NULL, NULL); > - object_class_property_add(oc, "node-affinity", "[uint16]", NULL, > + object_class_property_add_qapi(oc, "node-affinity", &uint16List_type_info, NULL, > thread_context_set_node_affinity, NULL, NULL); > } > > > -- > 2.55.0.543.g5ebe2ebe4ea8 > From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:09:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:09:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415709.1644924 (Exim 4.92) (envelope-from ) id 1x4vNm-0004lj-3s; Fri, 11 Sep 2026 07:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415709.1644924; Fri, 11 Sep 2026 07:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vNm-0004lc-0k; Fri, 11 Sep 2026 07:09:10 +0000 Received: by outflank-mailman (input) for mailman id 1415709; Fri, 11 Sep 2026 07:09:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vNk-0004lW-OY for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:09:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vNi-007Uoh-FQ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:09:06 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3a8fe-bab6-0a2a0a5309dd-0a2a450ab600-44 for ; Fri, 11 Sep 2026 09:09:06 +0200 Received: from [209.85.208.51] (helo=mail-ed1-f51.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3a911-f2d2-0a2a450a0019-d155d033e182-3 for ; Fri, 11 Sep 2026 09:09:05 +0200 Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6a9a4dc8afeso878281a12.3 for ; Fri, 11 Sep 2026 00:09:05 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2966022298sm47069966b.17.2026.09.11.00.09.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 00:09:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:Autocrypt:Subject:From:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789110545; x=1789715345; darn=lists.xenproject.org; h=content-type:autocrypt:subject:from:to:content-language:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=wvAa7sM/JXp+VCSXM2E78gB4EB4ZF+s29aq4VPOuIgc=; b=YpQMI9dACom4T53Y0P6XZXNgGAPIjav9h6WSftnssDSwX6TrCDnh1sJGxbcVsiUXiF UCteT293VpHJozm0vGnpakH1k/q8PDqd0+5+j8r1QCIM4CQUMojSxcZw6LH87fD1egYw EVMejuaO1UltyeFIUO0e607lJEmj+HBiFuyS02eTcv0I6YM36BY707iiZ/byyY4Rzs8A JasK/a3uyLMMrYJ8Y0E1TO467eVF+HD4zwFgTQSdyrP2ajDZG1JpKMPlnPl/HnwOUjWJ wsLLvPJGsRlwP57hwU7DYPEl6D0GpxR7rq/IYP6QPoZ9T8ZCY4BKiUNR6ZZSUVBT+iHk XCoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789110545; x=1789715345; h=content-type:autocrypt:subject:from:to:content-language:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=wvAa7sM/JXp+VCSXM2E78gB4EB4ZF+s29aq4VPOuIgc=; b=AFBy2hvFTQCr1XNCbQBCXvI4t/llk/VgwNCV1S9eqVfSfivdeH3KsVeAV9XTRmFDCb bERqDX7nHoOIAc+Md2yIA0gRl5vx1isFBXh+zYvQZHiPMTvJT/KgIBJEUWS1HxE8J2/f eV1Zz6QoonmVz3IO84mQjfZWQOv3HMTduNXEB9vGWnS8FEIbwS4ufs9SRMLboywuno+e WSwUfJlwMdkd62I5avqS3QyHNzjdRaX3m+MKNc6TpkHT59/QnYUuqF1YLb/20CABMAKU Q9yGdcGmKtd1Z2Odz7ILRbwBuDNOGnd+Mhnd5OevJa9V3oXtK9DJJordIYqxRYs3dQbN 0euw== X-Gm-Message-State: AFuF++mgiRUn7yYa11QatoqhAJ/VCqpJ962edp7cT2/F4UGOQdJsGSok dqORFnmNYIXR+OjV1wU5e6byvWFGSvlGiog+LYKM1daXBW2EqI80Leb55EiwgmLtkgU1v97YnlS AXNaAxek= X-Gm-Gg: AYBFou3U8bjF6db9F0a9zq3V/bmjY3ut+72L3YcTAwWBEvckfkjTvOn4DplCkgjlE37 BGrOEb9R+OBGSs4HYxnv9F2jzkDJ/ZdyjCXDSEZ0lfXo1ibmSTEeBMx91W+OypcL0ddsvYFPK5A lnkzwL66sKJl2+fKTnQTpCS82+OJ/kBRHfgJkDB4d58f93iLZrvc1iT3me5HDEr9k4SKJrC45Gj chxEUzbaP+00Pf0wut1RWsMHIkzdWC3YGDfUMy8XC/8J+ixpIAXwnOCSk29zRhGQsefTs6E5A4X eEeLOAwVfJxvKmRNPEE00Z96ThhDqlmr7kiDLLocWaJ/NZaF1kZWEf7XPb7TUH4t5fwHTVixJpa PxzJhtdfK7pTNB3mVnZ+a2pEsc/XWY6KihB9M4VSdOdY6DqIK0qZnLoGbTWuhZXFzWIsz/xuJN8 2U+fAOM298qlG1Amv0IeNzfyAD4CfzQTAz6NCBUc2rvVyLeW3xCI0YbsZQjwYIMRO3M8Y2y9AJ2 ZraF0NjgH0tfcVrbpqIHEpLz4WSuUKeSVVb2tVNAAPgUfEcr6JWCc1BGsOCgZ7S9603O4SLz5k8 fc6QBPuioUUeUuXb1ZGdymXT X-Received: by 2002:a17:906:c14f:b0:c29:56d3:65a with SMTP id a640c23a62f3a-c29666d2d73mr111983866b.33.1789110545116; Fri, 11 Sep 2026 00:09:05 -0700 (PDT) Message-ID: Date: Fri, 11 Sep 2026 09:09:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" , Anthony PERARD , Stefano Stabellini From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Subject: Build failure on staging for Qemu Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ZdswLQpMYivhkurHlULaWpJ7" X-purgate-ID: tlsNG-4011c0/1789110545-520C1CFC-AA0D643A/0/0 X-purgate-type: clean X-purgate-size: 9385 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ZdswLQpMYivhkurHlULaWpJ7 Content-Type: multipart/mixed; boundary="------------03DhA7zW4mUGJNwIJbWjaYGY"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: "xen-devel@lists.xenproject.org" , Anthony PERARD , Stefano Stabellini Message-ID: Subject: Build failure on staging for Qemu --------------03DhA7zW4mUGJNwIJbWjaYGY Content-Type: multipart/mixed; boundary="------------R0xn0IRN0TZEM2KQ3TSfao1s" --------------R0xn0IRN0TZEM2KQ3TSfao1s Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SSdtIHNlZWluZyB0aGUgZm9sbG93aW5nIFFlbXUgKGZyb20gcWVtdS14ZW4uZ2l0KSBidWls ZCBmYWlsdXJlIG9uIHN0YWdpbmc6DQoNCls2MzQvMjczMl0gQ29tcGlsaW5nIEMgb2JqZWN0 IGxpYnFlbXV1dGlsLmEucC91dGlsX2xvZy5jLm8NCkZBSUxFRDogW2NvZGU9MV0gbGlicWVt dXV0aWwuYS5wL3V0aWxfbG9nLmMubw0KY2MgLW02NCAtSWxpYnFlbXV1dGlsLmEucCAtSS4g LUkuLi9xZW11LXhlbi1kaXItcmVtb3RlIA0KLUlzdWJwcm9qZWN0cy9saWJ2aG9zdC11c2Vy IC1JLi4vcWVtdS14ZW4tZGlyLXJlbW90ZS9zdWJwcm9qZWN0cy9saWJ2aG9zdC11c2VyIA0K LUlxYXBpIC1JdHJhY2UgLUl1aSAtSXVpL3NoYWRlciAtSS91c3IvaW5jbHVkZS9nbGliLTIu MCANCi1JL3Vzci9saWI2NC9nbGliLTIuMC9pbmNsdWRlIC1JL3Vzci9pbmNsdWRlL2xpYm1v dW50IC1JL3Vzci9pbmNsdWRlL2Jsa2lkIA0KLUkvdXNyL2luY2x1ZGUvZ2lvLXVuaXgtMi4w IC1mZGlhZ25vc3RpY3MtY29sb3I9YXV0byAtV2FsbCAtV2ludmFsaWQtcGNoIC1XZXJyb3Ig DQotc3RkPWdudTExIC1PMCAtZyAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLVdlbXB0eS1i b2R5IC1XZW5kaWYtbGFiZWxzIA0KLVdleHBhbnNpb24tdG8tZGVmaW5lZCAtV2Zvcm1hdC1z ZWN1cml0eSAtV2Zvcm1hdC15MmsgLVdpZ25vcmVkLXF1YWxpZmllcnMgDQotV2ltcGxpY2l0 LWZhbGx0aHJvdWdoPTIgLVdpbml0LXNlbGYgLVdtaXNzaW5nLWZvcm1hdC1hdHRyaWJ1dGUg DQotV21pc3NpbmctcHJvdG90eXBlcyAtV25lc3RlZC1leHRlcm5zIC1Xb2xkLXN0eWxlLWRl Y2xhcmF0aW9uIA0KLVdvbGQtc3R5bGUtZGVmaW5pdGlvbiAtV3JlZHVuZGFudC1kZWNscyAt V3NoYWRvdz1sb2NhbCAtV3N0cmljdC1wcm90b3R5cGVzIA0KLVd0eXBlLWxpbWl0cyAtV3Vu ZGVmIC1XdmxhIC1Xd3JpdGUtc3RyaW5ncyAtV25vLW1pc3NpbmctaW5jbHVkZS1kaXJzIC1X bm8tcHNhYmkgDQotV25vLXNoaWZ0LW5lZ2F0aXZlLXZhbHVlIC1pc3lzdGVtIA0KL2hvbWUv Z3Jvc3MveGVuL3Vuc3RhYmxlL3Rvb2xzL3FlbXUteGVuLWRpci1yZW1vdGUvbGludXgtaGVh ZGVycyAtaXN5c3RlbSANCmxpbnV4LWhlYWRlcnMgLWlxdW90ZSAuIC1pcXVvdGUgDQovaG9t ZS9ncm9zcy94ZW4vdW5zdGFibGUvdG9vbHMvcWVtdS14ZW4tZGlyLXJlbW90ZSAtaXF1b3Rl IA0KL2hvbWUvZ3Jvc3MveGVuL3Vuc3RhYmxlL3Rvb2xzL3FlbXUteGVuLWRpci1yZW1vdGUv aW5jbHVkZSAtaXF1b3RlIA0KL2hvbWUvZ3Jvc3MveGVuL3Vuc3RhYmxlL3Rvb2xzL3FlbXUt eGVuLWRpci1yZW1vdGUvaG9zdC9pbmNsdWRlL3g4Nl82NCAtaXF1b3RlIA0KL2hvbWUvZ3Jv c3MveGVuL3Vuc3RhYmxlL3Rvb2xzL3FlbXUteGVuLWRpci1yZW1vdGUvaG9zdC9pbmNsdWRl L2dlbmVyaWMgLWlxdW90ZSANCi9ob21lL2dyb3NzL3hlbi91bnN0YWJsZS90b29scy9xZW11 LXhlbi1kaXItcmVtb3RlL3RjZy9pMzg2IC1wdGhyZWFkIC1tc3NlMiANCi1tY3gxNiAtRF9H TlVfU09VUkNFIC1EX0ZJTEVfT0ZGU0VUX0JJVFM9NjQgLURfTEFSR0VGSUxFX1NPVVJDRSAN Ci1mbm8tc3RyaWN0LWFsaWFzaW5nIC1mbm8tY29tbW9uIC1md3JhcHYgLWZ0cml2aWFsLWF1 dG8tdmFyLWluaXQ9emVybyANCi1memVyby1jYWxsLXVzZWQtcmVncz11c2VkLWdwciAtRFhD X1dBTlRfQ09NUEFUX0VWVENITl9BUEk9MSANCi1EWENfV0FOVF9DT01QQVRfR05UVEFCX0FQ ST0xIC1EWENfV0FOVF9DT01QQVRfTUFQX0ZPUkVJR05fQVBJPTEgDQotRFhDX1dBTlRfQ09N UEFUX0RFVklDRU1PREVMX0FQST0xIC1mUElFIC1NRCAtTVEgbGlicWVtdXV0aWwuYS5wL3V0 aWxfbG9nLmMubyANCi1NRiBsaWJxZW11dXRpbC5hLnAvdXRpbF9sb2cuYy5vLmQgLW8gbGli cWVtdXV0aWwuYS5wL3V0aWxfbG9nLmMubyAtYyANCi4uL3FlbXUteGVuLWRpci1yZW1vdGUv dXRpbC9sb2cuYw0KLi4vcWVtdS14ZW4tZGlyLXJlbW90ZS91dGlsL2xvZy5jOiBJbiBmdW5j dGlvbiDigJh2YWxpZF9maWxlbmFtZV90ZW1wbGF0ZeKAmToNCi4uL3FlbXUteGVuLWRpci1y ZW1vdGUvdXRpbC9sb2cuYzoxODg6MjQ6IGVycm9yOiBpbml0aWFsaXphdGlvbiBkaXNjYXJk cyDigJhjb25zdOKAmSANCnF1YWxpZmllciBmcm9tIHBvaW50ZXIgdGFyZ2V0IHR5cGUgWy1X ZXJyb3I9ZGlzY2FyZGVkLXF1YWxpZmllcnNdDQogICAxODggfCAgICAgICAgIGNoYXIgKnBp ZHN0ciA9IHN0cnN0cihmaWxlbmFtZSwgIiUiKTsNCiAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgXn5+fn5+DQpjYzE6IGFsbCB3YXJuaW5ncyBiZWluZyB0cmVhdGVkIGFzIGVy cm9ycw0KbmluamE6IGJ1aWxkIHN0b3BwZWQ6IHN1YmNvbW1hbmQgZmFpbGVkLg0KbWFrZTog KioqIFtNYWtlZmlsZToxNjg6IHJ1bi1uaW5qYV0gRXJyb3IgMQ0KbWFrZVsxXTogKioqIFtN YWtlZmlsZToxNTc6IHN1YmRpci1hbGwtcWVtdS14ZW4tZGlyXSBFcnJvciAyDQptYWtlWzFd OiBMZWF2aW5nIGRpcmVjdG9yeSAnL2hvbWUvZ3Jvc3MveGVuL3Vuc3RhYmxlL3Rvb2xzJw0K bWFrZTogKioqIFsvaG9tZS9ncm9zcy94ZW4vdW5zdGFibGUvdG9vbHMvLi4vdG9vbHMvUnVs ZXMubWs6MTkzOiBzdWJkaXJzLWFsbF0gDQpFcnJvciAyDQoNCkknbSB1c2luZyBnY2MgdmVy c2lvbiAxNi4yLjAgZnJvbSBvcGVuU1VTRSBUdW1ibGV3ZWVkLg0KDQoNCkp1ZXJnZW4NCg== --------------R0xn0IRN0TZEM2KQ3TSfao1s Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------R0xn0IRN0TZEM2KQ3TSfao1s-- --------------03DhA7zW4mUGJNwIJbWjaYGY-- --------------ZdswLQpMYivhkurHlULaWpJ7 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqjqRAFAwAAAAAACgkQsN6d1ii/Ey+p rAf/eCX1jKSabfwpvfVmlxykj5Rsh51C6Ch0OCfX8DkM7x/aQclyhE9m+wrFi6LAgnZGCH8X5UDA S8eRbbPTft1gErQ4rxa8M7rCijBycuJ5NLoPLygyt8g0WaI06+EmizQhQh8aiIn4BVz3n3LcACkx 7ecPeF4HoSqK2t1QEVHJStHbd/GJWvGn8cpxAUNEfbZBAyvxUBIfJ7n7sjEIaaRQUMiFm36U5LjO ohlT067y48lcQ0+1qBFwfxABfICea7zS+1Gzp36rws/GHM+9DmmmmKBj90xFMZIOi7VS9IcuGBnJ oe7N7FYOFDYKrAW4X0Xuz3BMCcqM8g2ejjfbI2IITA== =uBtb -----END PGP SIGNATURE----- --------------ZdswLQpMYivhkurHlULaWpJ7-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:25:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:25:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415725.1644934 (Exim 4.92) (envelope-from ) id 1x4vd9-0007kP-DG; Fri, 11 Sep 2026 07:25:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415725.1644934; Fri, 11 Sep 2026 07:25:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vd9-0007kI-8k; Fri, 11 Sep 2026 07:25:03 +0000 Received: by outflank-mailman (input) for mailman id 1415725; Fri, 11 Sep 2026 07:25:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vd7-0007k6-Qe for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:25:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vd6-000Pkt-Kg for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:25:00 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3acc4-2eae-0a2a0a5409dd-0a2a4505d46a-28 for ; Fri, 11 Sep 2026 09:24:59 +0200 Received: from [98.137.68.146] (helo=sonic302-20.consmr.mail.gq1.yahoo.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3acca-4cb1-0a2a45050019-628944928914-3 for ; Fri, 11 Sep 2026 09:24:59 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:24:57 +0000 Received: by hermes--production-bf1-54b5569bdc-fv65m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4451c0cd4386c4b1051306e68eb9ea1; Fri, 11 Sep 2026 07:24:55 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111497; bh=en0biDtErIDPX8Wy4OEtT0eKAnvLP1ybw8oQxmME/08=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=laak+G0vWbOik+u36BuweJGPG0wcd4JF4bJPee99r9l/nDc5lEPnNL8m5qSuh6+lQ5v7p3xubs+Ncz+weeFAmkdVHg5rLHDp9M1Qg8Zb89NXr2xYbcVQs1ToDeOiuvXKrN6ZByU7Mw/NE8ZL4gHjSkrfGtAjB6EkBNuK2Cuq5wU8ToXCLR6Sulg/k7HZmBikYEyLA6Vwmnf4Nd/4H5tFLuJyzKnlMPjwhKDmUZrBceX/+CivCrJHbFDFJN4MgOwAlFc1d/lXCblFmKY73fe6PW+vFUIvYIl7pBU6ASk9Ao/E85EmD26/HYAbuRpaArKMYl3JXNEEOrzL8dNfE4rupg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111497; bh=m/ERkDdEk+T4YnfpCna6g0mZv+xiWufY6rwsf2afODF=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=IgEnuBz0CV9X3w9UNvXidtV0ZwXWZ26E4Q/UMDTPLfzlC4qJwK15uFxk50ln/WcLstkXZ7KGACkHUQlEJJCkhoEcDSa9e+gwyJczTOvkB9TntgTyIaTcwfaf83zmBOFANOc8fBLjPiC/1HTzV57DEt+8opigivEptEmGwKNZm1x7rCaOi4LBbDPFqGyYdC5itZbVpm2rMUC6e05HyX9IUcQYJM9GeB6D3D5e/RprRlE5l+7oZ5+mim+V1KtAupmz0HV8eFp/i9CCSMYeKmLo3dAo6udgWIRd/bGzwGnaby36mMf6SM2iAmxJZj5JM38dXj9OIHNVLXalutCRmVDchw== X-YMail-OSG: 0EFgvdUVM1nTA_43UU_dkhx.RMQF9.A4zr8vZPXj1UprNjjQRWLMTFDc8Qfkbzi jj7oxWgOFXKqbrX6rfdz_YcuG9KNRtg8Wo7NSUkaPE.MTcR4H8JMnYc_il85gVA_0I4HZWvObdg6 kz6t4TgtE69jkQsh1ITX1eI1kZ8qB.5WP9Aa5XeHHeXc7WHMBacjuXqhQbMeEt1R0xPnQP0f3LXx .ULAn.918HWdNr3eajcx0p7xgn1FoR.HUbiA3mN8Hz8lZODi_OKPO9HOOCmGGKmyZSokF2LHQmGw I82Q4z.4vTGVR0ZVHLlMQs2NVoVBvsTkfdZD1Mh2pLBh22Q7Yb_ZZTkuerGlV4bexWdrggUVVzBb MEOxCplRixUEXAwO96UIv7HDuoYaOPnPPs6faTTralBDWQ0GDwa0Y7yCNITyo.S4vuDr26ZHipW4 GFW2lS8Jzf7wPs1mLGV._UWZGvWGOhHfmtyI.6xerzuP.dXj1p5_Ra_sVNANBdSirJIwWBL7M0Zw uFjoCWuMzE7rF.Z8Cmwf3.VehGn302OQAfbxgsReAL4zgXCI6CUnE55Vwsh7tn5yu2Rzt2myjW.k k8u83hyt_1x52jwaipYtmpNS5AXxx9eAFP8g4SxUMnZkxrscrgwYjvxFOfRLuOUheuwtqxqPLgbc Ny.WBiFLfCEDGPjWCGM3AkG0IF8WyEA8C1PTRlcACwDItC3mjwMZwExVampamYzITnI7Jd2hrrGN tqgHbwIfivGtpuLh7dASJU8thNdvVY7cODg4p0Wc.6sz2UdwhOSAguxlmW91asoUx1LP8dEMDLnC KZy9Iz9GEs7UnPVMSypKHSjLof7B7QAKGMlprPT5t_TPL7rVDltifQNeCElRSCVyTP.Vz2caZjMK 3lcKt6FrOarImMjdecde51UclYbLxfDutRjvk2b_.0suEONhdF6zdG3oHpmJflzQnOWuHWi8_tN1 sevN2axosa3erbYz1F..UnQOLH0OYD2DmRA0mPGS1O_K6OMfuEVncxmEzynfiazCBz1etNwU7E_Y NiFaLQsVQARMsZY6.mxS2bsN6Z3faU2XdjHRy_nlpydUEh00V2IJ6V8Fx2r1Gi8hwIWB1HzU6gg3 PrpOZidJLEv0HfycnFMwU.2TpF9FN7Bd00aFyqktD1F0JOgm5Pu3r08QmkegQTc6VV2eTOccfDgM 38TJeBFfCTfqAAmRKMh7UKHhnKtXCNsjvu8zJyF3WnwV8KOFmLR9TGwBd1T8i1V1DohC8oK4veaO g4nihugWtY6Lt7F.EmczJSMr8_lxa3BVvddMVmf22cJr7mfcrJqcMKiGhFey83vIOsYoGtveaBva _1bdaJk5KBZTPX590bTjaLCGVLrY4XKLYu9G4wi4C.OzzeKtQyNptUedDzfoLQCdIxLz2.Vq4AhR mCQbgOFP.L9W_bAbRc1P5FGSFucCwFsKA27zovnLS5o.YKeBGY_yYEXWNteJtAoAxW3GfKBiagwT iTuoLk7WvJejLOOeoJClKXWbtKUvtJsZ4imBSjJxYXKVW8JJ8B4NSbpEpqfQoAxcZmgp1hzfYcP4 inBelBoyeuReNp6iKXlXuOO19iVsIc9tGREQybAa0xXkSQ4YkFlsQKRpeVVm33nn.aRiRjwRickW d_OGwd1pXRDjErSfTiJbGH78u.547GL3C2Sqqve8P4TabaZF5vKPNVafZ3bPkeTm6Ttw9DLuYiwO PlWLPt.8J_PQsYWv1oDt5f0dDKaePBdVUW_GGj84BjXm5b5lDFKcnM4He5w7ABAr7vHr8CqrdC7v reNbIQqAZ5aLi.tgY_MS7pF1y2c3EmTDCabGsYik7yXka7mOZHh1gjzUtpvSFv5azsuXx8x0Sx1P 4d7FHevzwWezqjdbGtXg_FRl5nLmKXhpJeT7f.jdGUAl4f_yRQeDZM3jmLABURfmCSFA5UWOZE1v Z8lUjeV2z1bKCkw5GdI10C7ZIftqrGaJg35db2zdMhInb6ACvpaBwze2bSzftWIlKnjC2Eiwzs17 MIifqbx0vstvzbarTBsU2XWw.Q1dRe9yHYrn7SOuP2NTVnQnNAcECmMAOz.xlqAX6_G5Xi9XafVh luPD1aZC7uDyjYZVRnDaSui.R7srO_YgdCYdqfj0pbcgItB7kjEsLa0OTdZMtEwnsoI4ggnA3EO_ L7oFk.cuoQh__56gnu8sO3KOEsXTJx.Unk2MUnrFN12fxLDlvcdWUSFf3c1Ka_IDiyvd6UxzSQji 3wVc3biZg9Es1j33FN8C9cltc X-Sonic-MF: X-Sonic-ID: d05bd7e6-d197-4edf-9dd5-7cb81c3707fe From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko Subject: [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Date: Fri, 11 Sep 2026 03:24:46 -0400 Message-ID: <20260911072453.46256-1-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit References: <20260911072453.46256-1-brchuckz.ref@aol.com> Content-Length: 5384 X-purgate-ID: tlsNG-c201ff/1789111499-72AB72A1-6D3568BF/0/0 X-purgate-type: clean X-purgate-size: 5501 Please note that Patch 6 of this series requires a patch to hvmloader of Xen for the new support to take effect. Also please note that earlier versions of the patch to hvmloader are not compatible with this version of Patch 6. Please look for v3 of the "tools/hvmloader: implement Intel IGD extended VBT support" patch that will be posted shortly to both the xen-devel and qemu-devel mailing lists. This patch series aims to fix long-standing bugs that need to be backported to all currently supported stable versions in order to support passthrough of both older and modern Intel IGD devices to Xen HVM guests. This patch series also provides a patch (Patch 6) that adds support for newer devices that have an extended video bios table (VBT). These patches fix several bugs that cause problems ranging from a dark screen in the guest until the guest OS graphics are loaded to an assert failure or other failures in newer devices that in many cases prevent guest creation from succeeding or cause other problems such as code 43 errors in Windows guests. To test the the third patch and verify it fixes the bug of no video output from Seabios, it is necessary to test with older Intel IGD devices that have support for legacy VGA bios (Seabios) because the newer devices, as far as I can tell, are not compatible with legacy VGA BIOS. The first three patches have been tested using Xen 4.21 and Seabios 1.17 on Fedora 44 using an older Intel NUC7i5BNK with an i5-7260U processor and have been verified to fix the bugs described in the individual patches. This device is compatible with legacy VGA BIOS and Seabios. With the fourth through seventh patches applied, it is possible to use/test with newer devices since, with those patches applied, the bugs that prevent guest creation from succeeding with many newer devices are fixed. All seven patches have been tested on both the older Intel NUC7i5BNK mentioned above and a newer 14th Gen i5-14500 Raptor Lake processor in an ASRock board that, as far as I can tell, is not compatible with legacy VGA BIOS and Seabios, which means that, although one can successfully create a guest with Seabios for the guest with the newer device, there will be no graphics output from the guest until the guest OS loads the graphics drivers when using the newer device with Seabios. The seventh patch is provided for use with newer devices that require an EFI graphics output protocol (GOP) driver for graphics output during early boot. For more details, read the commit message and the accompanying notes in Patch 7. Two hints to help configuring Xen HVM guests with Intel IGD passthrough: - Increase the value of mmio_hole from its default value of 256 to at least 512 using the mmio_hole setting in the guest config. The value of 512 works well when the stolen memory is 256 MiB. If more stolen memory is used, the mmio_hole may need to be increased even more. - If there are rdm conflicts, lower the rdm_mem_boundary setting in the guest config from its default value of 2048 to a value at which all rdm conflicts are resolved. I have discovered that lowering it in 128 MiB increments works well. With the older device I needed to lower it to 1792 and with the newer one I needed to lower it to 1664. See the description of the rdm_mem_boundary setting in the xl.cfg(5) man page for more details. Changes in v6: - Added Patch 5 to make better use of the xen_igd.h header file - Patch 6 (Patch 5 in v5) has been totally re-worked after considering comments made on v2 of the companion patch to hvmloader. See Patch 6 for more details. - With the addition of Patch 5, Patch 6 in v5 is bumped to Patch 7 in v6 Changes in v5: - fix style problems reported by checkpatch (see each patch for details) - update the link to the companion patch for Xen hvmloader Changes in v4: - add three patches to provide support for newer Intel IGD devices - edit the commit messages for better consistency of style - use 12 digits instead of 7 when referencing commit hashes - re-write xen_pt_get_host_pch_info() in patch 1 using the functions declared in xen-host-pci-device.h - handle errors in patch 1 that in previous versions of that patch were not handled - add a Fixes tag to the third patch - add two hints in the cover letter to help those who are trying to configure Xen HVM guests with an Intel IGD passed through Changes in v3: - whitespace fix in first patch - fix Cc address for qemu-stable Changes in v2: - close open files before setting errp - improvements to readability and style - small corrections to the commit messages - add stable to Cc list Chuck Zmudzinski (7): xen/igd: get PCH info from host sysfs xen/igd: don't register rom bar twice xen/igd: fixup device id before registering rom xen/igd: enable guest creation when ROM read fails xen/igd: use igd header for IGD related definitions xen/igd: implement support for extended VBT xen/igd: use custom option ROM if provided hw/xen/xen_pt.c | 13 +- hw/xen/xen_pt.h | 9 - hw/xen/xen_pt_config_init.c | 8 +- hw/xen/xen_pt_graphics.c | 323 ++++++++++++++++++++++++++++++++++-- hw/xen/xen_pt_load_rom.c | 64 ++++--- include/hw/xen/xen_igd.h | 19 ++- 6 files changed, 380 insertions(+), 56 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:25:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:25:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415726.1644939 (Exim 4.92) (envelope-from ) id 1x4vd9-0007nJ-OY; Fri, 11 Sep 2026 07:25:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415726.1644939; Fri, 11 Sep 2026 07:25:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vd9-0007mp-GQ; Fri, 11 Sep 2026 07:25:03 +0000 Received: by outflank-mailman (input) for mailman id 1415726; Fri, 11 Sep 2026 07:25:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vd8-0007k7-Cf for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:25:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vd7-002qxh-6u for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:25:01 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3acc5-8faa-0a2a0a5109dd-0a2a4506d894-44 for ; Fri, 11 Sep 2026 09:25:00 +0200 Received: from [98.137.65.32] (helo=sonic315-8.consmr.mail.gq1.yahoo.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3accb-195a-0a2a45060019-62894120959f-3 for ; Fri, 11 Sep 2026 09:25:00 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:24:58 +0000 Received: by hermes--production-bf1-54b5569bdc-fv65m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4451c0cd4386c4b1051306e68eb9ea1; Fri, 11 Sep 2026 07:24:57 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111498; bh=tHr6jGwNHhq3fJ+vp7D5cn0Pfg062lk1xcykfV907MM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=WkXczADhdQuA0QQMH2IyPryOJk04+MaSsYlWKDiqaovTU+vh8uLPZqswm22rPTk0n8o/VFAN+xdxTik/gIw+97158tCBbaqcmSFJM28RiG7NlGiKGjnySopf3+4OSD7HSzM/yZbZwraU72s4UzYN4M0V9n2BbAlFbybjXPnG86YYIKMs51RJbc4n5kMCjZY0139sqkxY7SwCeBPtVN7kd+uN8J4pAvTgyXA3AZkAqj/a94kLRQQPYmdpMbz/e9XVH90ON5Xs/Uix2M3IKoEb3tVkDfhl2Wqi0O1oeHj8HJ759hC9EXr/MauKoO1JO3tutkiWtj72bvboom4w4xzLow== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111498; bh=ecV1pO1qpj7gBS6SdkI1hsH3mU8y/kZB15TF0tG+0hw=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=MkchnzuS7PIompOxaek6t1GmklJ/Bp/EGq6muEM8qLuwyGx5x/n4r/wf1cxGrYCrwRafzna9m/c6rsicgMT4bGbvMehL05b31+XlXFH4oyJdmlb2xsotnRQBzxsTbua802acp7m0gebSkXX0nmugdVQ5CLyebAvTSsJisTtxnvK7TmVFUNta87wYMngnoSgq7jDMF8gsoiyEVooHH21KA69uvni6yNaGrg4t0WZmv4qIbTrlEOQsHt+yAZmPSwVtV9ocjZtzgE+hXM3rO1uMVs/jw9fn4tK1cYneqF6OfZa9U7J4ENzoKHrzReJ6HjpOKlpnEMfTS14CpWx05bzP6Q== X-YMail-OSG: 2tXZmyQVM1na4AOFNcDU_PfbPhYC.okRS62Q4pYlKkNAqEPAFlFchS0AhL54oV0 knGmOTrz.b9wr_UL8dwuOxaoR_.7DCKFq0nghdsTAMd30gRa20lVhA1UHD8HDCP.q.leOC4QxQAZ WVnGKXEOs0oRc8c6.vfvg0AdTaCBoyEHhwvP_2n80U3uaoN.lMp8oeVoBeneDc6ayx8Fb33woHZ_ vn4D292omfynmftMPGFQYw0uH7QD4keBDiCCB_wcPAe_qR60a6L8SOY1kPT57w08xjyl3TyTRPrp 3mL6jAD3hN6bRV4gvHsAtzY4fJOyqELpBXJeYXZ5NVymGXLcfgzUUfblMu7pJp_eUE06QZL_YyRe 2Lvg4Aoyld5gpRaFy12Kvl.himk350txeQDs2od8rqCeqG2qaGZzLa.XZC6wrV5QvVPalwiqzADP ZjBfrlgCCZAKl94P1ATbe0wzORYvKix9L.0p.OF4nAmePCOtF3K8NM_ynUocLdaRF2lnblHxSmvs ON91ZzFqcpAn7qt378ViTnjh6vsVyNJo9XEOY3a.aTcki_lD7wnI7wAbJfAjCRynsIJ6c6ccY0Rs resy6CpOMhJg.8AjoIZDkbDAPTmesqNtiDltGVIuoKAQ_ui6p68_l4Q1PYZFTsTRQVVI4tf4OmIB _cF71j5ZvdqlLdd9UARw1MLRLvKvHlmh5TQvX_g9RkdCFbpj4imiT4u6LCJyRSDSObxIoryz.mOL lrt_Si7MA.xmOZZs.kDswzABZ2LyFNT_qx1fplB9e3NMXMEDqRUK7oOM0BkdEDdS5brPM.hMgmOS iHKa.hzkg92vANPhQH.OMSvH7oolkI.1ec8nw95hfx7.SIPXO2mQMrLtcLW87.VyARyOCmUZNveB s0AVz_l2EOGM8uHtqTZ130JzQezx9PqxoD9OTBlL7vt2YzHL_81HIRnDD4vc9_ABNcnewYDL4Cb_ z5ueRn0dNHSVNt1h_iogBfPDuN6Qk0ABPNxoEoRNW7eW0t8h18SUYeflSG46geCCT_UUvHyEEzx9 ejjsqE9AY3_H9Q0pbR3kMBDL6cmD2Xf9Xx6s9TfIsSdXI_chGHcZRXpdUuc9Yvs7gmIZ5APLmk_O yMbzv6NBdWI9CyIKx2LTQsivu57VIscJFfyyq7B.yhauU1GH1VpgCEaYw7nuigryZNLznQnm8JKn VzpeD_Zur0xqUccbRszmkqKz0SjNXiLa3X6.86QrkJ2z9tLVLgazemVVhpnf5Swa1Xm8Z.abV85l FoUb6fZuHpro6mLWvWiBCYTmbLnMxaDqum0qUlt0B1O1y4O__vzRVRdhaymRxzddlkSsgl83LDOQ JxYjg3_5elbxY3Sx3b3FPDVcIZaKlRCOW2u6efb0miolbIbUoBvTKvXl4zyhLqGqWCiGJvntSDfJ FrjEQRJZ3Q_L30zns0y0ZcD2oHHZOrGJvU4k8lOPISVKbhNty8I7sq5qq_NwY0es4s_mxbbdEuwo 3f_uV1LnVvkB5Xd7D9b9aJloRrgKRT4TYG1Im1Pdnx8IVS69CQmcI9AkHpQgtD8yqbhaMbWMBIeE CUQ7QYAuSOPndG_LbiZDeQC79WrMAwLDIkyPW2JCbiGug.mZr4QbfIq9vkHKktGPHx5u9Q8Z2u5C QWHxWyF8LuZAtIMrsBWESX5koYKmNVa7NtxULrk2BHt3QhIXTfG_50RmUwdR637.Vl5pVTiZgpw6 pFwxZMp2jbt3cd5B1YxA_2uW2Hndw1KmvwDIphiEYk.ptrnKbDA0mYC5l6HW_T4ANNJWnVS1d1sB _m2KDb2X6.jnKNCmFiJCWVgdgjHIRKc9_RiTwHp2uOycqL9o5RihBLmFBb_XA.Kp.FjQT6nxBdB_ BLu0gby2TtnKKAsQdo1d3KRygoN.zFp2c4qQAgt76JAvV33.O808gvHMjzUu_i4RFXEQgCIL3dj_ z2S7wsXrQ4YRo9ga2PZNst57HVRFbwrsO2VhvZuwf3e0oogD0rd_Y.thgnDxdzT658Lqo1GyfbJk BuYuo1pYqKSSHJ6I0p4N2Zlo2mg2jKBp8SKCfoFNLa9aVhTmjq.qGKQL7TkKsdLTe08hWlgs7pdR RLzeV251Q1QvRZz0YQ1JGnaIba7G107RCQmX3rJgJXfvXZ1_O5VM9U6fA4pE0DdFlTPVpJDKiiZ5 dq7GGuaJ29Shv7S5eVFYHljzn_L.UKEmenXZWmnHBgtm4zK.a5Q1bGhGXli1TdFdmbVDIBBc8x6o TaleasQoV59w9JoyaldUKU0oKWaIqxFyR X-Sonic-MF: X-Sonic-ID: 56673a5d-426d-43a5-a7d0-21fdf54ffe44 From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko Subject: [PATCH v6 1/7] xen/igd: get PCH info from host sysfs Date: Fri, 11 Sep 2026 03:24:47 -0400 Message-ID: <20260911072453.46256-2-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260911072453.46256-1-brchuckz@aol.com> References: <20260911072453.46256-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 5811 X-purgate-ID: tlsNG-16d1c6/1789111500-F687577B-4D8D2615/0/0 X-purgate-type: clean X-purgate-size: 5969 The igd_combo_id_infos[] data is out of date with many devices missing from igd_combo_id_infos[]. For newer devices not in igd_combo_id_infos[], get the infos from the host sysfs. If logging is configured, print log messages displaying the PCH info used for the guest. Introduce helper function xen_pt_get_host_pch_info() to facilitate getting the necessary information from sysfs. Treat failure to get the host PCH device id as an unrecoverable error that causes guest creation to fail. If access to the host PCH device revision id fails, print a warning message and use a default value of 0x1 in that case. Also, use errp in xen_igd_passthrough_isa_bridge_create() to set errors from xen_pt_get_host_pch_info() and cleanup on error path with xen_host_pci_device_put(&s->real_device) and object_unparent(OBJECT(&d->rom)) for errors when creating creating the IGD PCH bridge. Add cleanup with object_unparent(OBJECT(&d->rom)) for errors when setting up VGA BIOS for GFX passthrough. Signed-off-by: Chuck Zmudzinski --- Changes in v6: - No changes Changes in v5: - Shorten warn_report message to resolve checkpatch line length warning Changes in v4: - re-wrote xen_pt_get_host_pch_info() using functions from xen-host-pci-device.h - add more error handling to clean up better after if errors occur - don't consider failure to get the PCH device revision id a fatal error but instead print a warning message and use a default value of 0x1 hw/xen/xen_pt.c | 10 +++++++++- hw/xen/xen_pt_graphics.c | 39 +++++++++++++++++++++++++++++++++++++-- include/hw/xen/xen_igd.h | 3 ++- 3 files changed, 48 insertions(+), 4 deletions(-) diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index 0fe9c0a..c8f08b5 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -862,12 +862,20 @@ static void xen_pt_realize(PCIDevice *d, Error **errp) if (*errp) { error_append_hint(errp, "Setup VGA BIOS of passthrough" " GFX failed"); + object_unparent(OBJECT(&d->rom)); xen_host_pci_device_put(&s->real_device); return; } /* Register ISA bridge for passthrough GFX. */ - xen_igd_passthrough_isa_bridge_create(s, &s->real_device); + xen_igd_passthrough_isa_bridge_create(s, &s->real_device, errp); + if (*errp) { + error_append_hint(errp, "Failed to create PCH bridge" + " for passthrough GFX"); + object_unparent(OBJECT(&d->rom)); + xen_host_pci_device_put(&s->real_device); + return; + } } /* Handle real device's MMIO/PIO BARs */ diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c index 7df9344..cf424bc 100644 --- a/hw/xen/xen_pt_graphics.c +++ b/hw/xen/xen_pt_graphics.c @@ -2,6 +2,7 @@ * graphics passthrough */ #include "qemu/osdep.h" +#include "qemu/error-report.h" #include "qapi/error.h" #include "hw/xen/xen_pt.h" #include "hw/xen/xen_igd.h" @@ -376,8 +377,33 @@ static void pt_graphics_register_types(void) } type_init(pt_graphics_register_types) +static void xen_pt_get_host_pch_info(uint16_t *pch_dev_id, uint8_t *pch_rev_id, + Error **errp) +{ + g_autofree XenHostPCIDevice *pch_dev = g_new(XenHostPCIDevice, 1); + + xen_host_pci_device_get(pch_dev, 0, 0, 0x1f, 0, errp); + if (*errp) { + goto error; + } + + *pch_dev_id = pch_dev->device_id; + + if (xen_host_pci_get_byte(pch_dev, PCI_REVISION_ID, pch_rev_id)) { + *pch_rev_id = 0x1; + warn_report("IGD: failed to get host PCH revision, setting it to 0x1"); + } + + xen_host_pci_device_put(pch_dev); + return; + +error: + error_append_hint(errp, "failed to get host PCH device for Intel IGD"); +} + void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s, - XenHostPCIDevice *dev) + XenHostPCIDevice *dev, + Error **errp) { PCIBus *bus = pci_get_bus(&s->dev); struct PCIDevice *bridge_dev; @@ -394,7 +420,16 @@ void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s, } } + /* Newer devices get PCH infos from host sysfs */ + if ((pch_dev_id == 0xffff) || !pch_rev_id) { + xen_pt_get_host_pch_info(&pch_dev_id, &pch_rev_id, errp); + } + + XEN_PT_LOG(&s->dev, "PCH device id: 0x%x\n", pch_dev_id); + XEN_PT_LOG(&s->dev, "PCH revision: 0x%x\n", pch_rev_id); + if (pch_dev_id == 0xffff) { + error_setg(errp, "failed to get PCH device id"); return; } @@ -406,7 +441,7 @@ void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s, * Note that vendor id is always PCI_VENDOR_ID_INTEL. */ if (!bridge_dev) { - fprintf(stderr, "set igd-passthrough-isa-bridge failed!\n"); + error_setg(errp, "set igd-passthrough-isa-bridge failed!"); return; } pci_config_set_device_id(bridge_dev->config, pch_dev_id); diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h index 7ffca06..da51f09 100644 --- a/include/hw/xen/xen_igd.h +++ b/include/hw/xen/xen_igd.h @@ -22,7 +22,8 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s); void xen_igd_reserve_slot(PCIBus *pci_bus); void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val); void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s, - XenHostPCIDevice *dev); + XenHostPCIDevice *dev, + Error **errp); static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev) { -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:25:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:25:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415727.1644951 (Exim 4.92) (envelope-from ) id 1x4vdE-0008BQ-0a; Fri, 11 Sep 2026 07:25:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415727.1644951; Fri, 11 Sep 2026 07:25:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdD-0008BJ-Tr; Fri, 11 Sep 2026 07:25:07 +0000 Received: by outflank-mailman (input) for mailman id 1415727; Fri, 11 Sep 2026 07:25:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdC-00089b-CJ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:25:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vdA-004oXr-U1 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:25:04 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3accc-bab6-0a2a0a5309dd-0a2a4508d58a-6 for ; Fri, 11 Sep 2026 09:25:04 +0200 Received: from [98.137.69.32] (helo=sonic316-8.consmr.mail.gq1.yahoo.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3accf-f659-0a2a45080019-628945209855-3 for ; Fri, 11 Sep 2026 09:25:04 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:25:02 +0000 Received: by hermes--production-bf1-54b5569bdc-fv65m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4451c0cd4386c4b1051306e68eb9ea1; Fri, 11 Sep 2026 07:24:58 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111502; bh=2bfcA2HA0eFN2KKmyTFegbUhGh8vw5fjlw90db5CzuY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=IXmDy3e917fafoCDKiMu3JLjF/+baEn8doi4MYF2R9yQM5EqgH4MAHX7irFLr1+MkBmH72QNjuHLWO+G3tIKkCanQaik3Nj0SNHWpKNVdXMG693QuDR4V6irm9cT/oe07cmjJKfgMX97ZlQiSK9imAiTEIsHUJFHb6Wke+96v8rN0zWdzNnNnxBoLesXmEImDvds3o+va+dj8m9HHP+ltI82zHlJAWeDZ/jbmBSAC8RBuHTD9U7UVhI4R5RLdSPKdIoTrlZa3K9Pj4+kqS8NQ7bT9c8abqntTXcgCoJSgGKTiEZQD/hJWIENFeW07VkBmFn/MJp7S0+kU6WNSjsUUg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111502; bh=Bb+TK9wUavK5OW1HyioutUUdAopuw/9tkWTkNKyTaMv=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Y9IWjyI4/ApHHRd0KYrrO/owGil09DQu3h0R9r4n9FsmN+7lTZp2AHqm0QU2YM9uglYB2BYYQP9ArpG4IAfSnDu4zlgo7KjIQey3gN4BW+mwSmaEpR14GG9FSJTaBZ93XHy8eISiddxHcT8YH14Sc0E32e4xwL2nbIbByb6s0pPollXvQPCloOiSCCoVe/7MFeUWPRFGQvcwOdL6iPZN4EH4yKS2hJBFoAf2NHkL3qTEJTmiGykyaB4q/UQ8IHM2hpDtLNUhVXOuVE5UmHQC3lXSp9bWYC/zK6/R1Mr6j6//ZVXBGWZL2YMom5ZqD7TuCwTcqm3E+USSQZE1a2jt/w== X-YMail-OSG: 6LTy5XQVM1k1afLOhVe_.u4gdDeNa8ddjCTiQ7cU8GnOhmF4.cnNYnxn70vsVl9 JDqMI0JpYFMCrtJvrEGSxGFHzfoA5NpSe0iu0sx6XFmlH4bvTNMa8ktt8LZKJVF5on_IHscGuzjc _9lRXkSaoAi.Acyy3XJIQOhYaXWdB84eg6A5MNPnh6OmQOcSfssk4IEAz91rogy3KcpK1WaMr3Py Z8otViqzrIOfSCyX2gNZ2fgJQGtqcxidUg05o0qrXEgsr923OwUNgpLlpdPhfFS_8IhzXaGbZn0Q zZNk0iSUiUlnHyd8Tg1kLonZ.I3DwIe.IM0i77T5Y3J0CzvRmpkGXWJC9_Tt4wJo4B73ECjymLdF GfLY31J9UCw5OcdGPUKGj9_qkuqNWsZZeDPrS5Q79jzZQy4n3SVqgHQYnW0T8Xz8u2przyNfDv3E 5r2rlGaFqardcgKDlSVnzm99lXUS9Gb.3KzcDxjfZI1ghBuSGjB1qoCJuf9tnVzNrdSvHPODLpGw sdhRRY1WoXAuYLOQaoa7zP3N5FL.ZZOsQP5dTFoZvYbgjDbR.9ECw3UWCk4bVJfPpEaU1uOQXMYl ZmSCWEWAAStfyzhlpjJhVin.9yR2McoNyvNv_KgUjeOWJuRoSEj89Bm0Ai0J4_U51qsqo1QznzAW CirPdWOphXQCLQV83jaYh3CnRTO55jxDE_l5tquNhcx3hCoYv8RpcAUPlfeI96qyq6hKzU3aFpTn FKW.hf46HQ7KIhsZHRk.sgxuPA5s5SJKBudIDc3FBaF4NKkABEWps6VBojaz2NttbK7OXqR4KkCX az8fWzscASQPD4JQOC8q_ymQkPeja9LFijFMh5HVjmtEiZrpZFijG.sgvtoumLr94U.haL3xIvUL 8QV90d7U78tcOTgK_aanz8N1m0smWWf8N5r8kLPAiu6M3O2bLXlc9Ezo_FpgwUDB2_M4lZrJVT6i O8wEAAimZ_9SPLkQYZ3lOEwOfauIteSsFWJsb1Zq1dsTJK.kkRipmt5IL1dupWTkzFRtUHwBAai_ m7a6LiSZDuM3M47yawNSbQJsIkmV_xJV7IN_Y00KDHjSvAvGU874SmSm5vm50AnG.r.iOU4Hbv9U foriY0NcDWk_u_dNuMmRFXX8YqMz9ASpkGhVxeGJw2OLHIyV0epV0.nRe5jlSo8pgvLG.2rHi.ms VehXmEFvM.4Q7HxgbzwhDbJnptKtTX3qFmgWDlKslyv6vFEtAj9lDiykI0nUdmdgCgxv0tK2bm8k maAOXO7hz.cKKjjrA55N5ukF3CgD1m1YM.LBDbOdgvfDU9YgWU9aj0EJanThqA6TBeUipvc9Tsr3 1DPOVBEJHn3wOD8n7Tb6LdL5nRYXcp.xmRF2luz3Bc.CUdLlz.2fyAYUfwx37VoNNVnaIfdjU04i PT7RGxM8hCMEY5XOXFJQ.zxcwKmmlA4GbVDN5yN0i6mIPKxyQVvioeOQyxf4na8twH51..fXPK5o h.ET8Pw2oXlLmCRKjtft.2vGda4R3N0pam7CUuxinhS7Lmsc22TaadZm9qiKj5fnJBGTcUAlmgJY LxHoVm9dMAlMs.QTe8HzMZ4wkT2R0JWPv2COq1ViL8q4BlLqk_CKVNczeyt3_fKxKmBOJlipOTpj NmMszCnlDDKl.ylq_1E5wVZPV7XXVtazKAsrmX57w_TKkyQqERgmUcKX_wnzWVwbfabn0Ui0_hOY hejI2IApmjYRgQ0BBE2x_eXFRrxRbioTj2sZty28XfUnpKaRWKRKFcLfTnrwaKIMetynvCVMb9P5 joZxr9etDa2doxVeENp2fJahGnfqivGiucj0kK3CkzqnC73W2pC2PF3ifONJATFOYeOFSPDzpwZR .LoigatUZU6pd83GyeYdSqUqf9kC_u3BJL3tX5VfEgk6qpv7D9eQw5dyDah0LWmCobv3C6x2EGCl fBlk8p8gJxTYRKIS6RXftbpF1Rj_Vb.UcDUzwlp5E5zzPmly0nbvw4SjAa9qJkhi9b0epcegFMHC BiIu6c3I1R9DvidR6t3R3abeS5HyUC5EkLSnKe_Bi5rKTHTRlCIrU6ckDgyYd_2Nq99Hcy0DSF3x HRL9_wNAz5VESmQFyxp0H1THmykZUCimK.b.1i_3YxwLzY9GER6HUZVCqAmXlmBEE8cD.qPG8M8c z1XPXdQHvXzQfpHPz75mZ13LOV7L7HekxXP7hSzmCDCR93ypuaXc12D1FWgjQBimWUbMkHH2UP39 TFBReosiwvRvFEZNtZismBqe9GtdZ8zxzWRy4 X-Sonic-MF: X-Sonic-ID: ec7da795-eae4-4ab0-83c2-71a43c2c372e From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko Subject: [PATCH v6 2/7] xen/igd: don't register rom bar twice Date: Fri, 11 Sep 2026 03:24:48 -0400 Message-ID: <20260911072453.46256-3-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260911072453.46256-1-brchuckz@aol.com> References: <20260911072453.46256-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 1357 X-purgate-ID: tlsNG-c1860d/1789111504-D574B87B-917D3781/0/0 X-purgate-type: clean X-purgate-size: 1401 This also fixes a failed assertion in pci [1] for Qemu version 10 and higher when passing through an Intel IGD with an option ROM to the guest. [1] f6fc01c78666 ("hw/pci: Assert a bar is not registered multiple times") Fixes: 881213f1b9c5 ("xen, gfx passthrough: retrieve VGA BIOS to work") Signed-off-by: Chuck Zmudzinski --- Changes in v6: - No changes to this patch Changes in v5: - No changes to this patch Changes in v4: - Use 12 digits for commit hashes hw/xen/xen_pt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index c8f08b5..4d159a2 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -459,6 +459,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd) { int i = 0; XenHostPCIDevice *d = &s->real_device; + const pcibus_t romsize = s->dev.io_regions[PCI_ROM_SLOT].size; /* Register PIO/MMIO BARs */ for (i = 0; i < PCI_ROM_SLOT; i++) { @@ -495,7 +496,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd) } /* Register expansion ROM address */ - if (d->rom.base_addr && d->rom.size) { + if (!romsize && d->rom.base_addr && d->rom.size) { uint32_t bar_data = 0; /* Re-set BAR reported by OS, otherwise ROM can't be read. */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:25:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:25:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415728.1644957 (Exim 4.92) (envelope-from ) id 1x4vdE-0008EN-DV; Fri, 11 Sep 2026 07:25:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415728.1644957; Fri, 11 Sep 2026 07:25:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdE-0008Db-4Z; Fri, 11 Sep 2026 07:25:08 +0000 Received: by outflank-mailman (input) for mailman id 1415728; Fri, 11 Sep 2026 07:25:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdC-0008A2-I1 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:25:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vdB-001KQ2-Us for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:25:05 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3acc3-e002-0a2a0a5209dd-0a2a450c9d18-38 for ; Fri, 11 Sep 2026 09:25:05 +0200 Received: from [98.137.68.30] (helo=sonic308-54.consmr.mail.gq1.yahoo.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3acd0-f479-0a2a450c0019-6289441e989a-3 for ; Fri, 11 Sep 2026 09:25:05 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:25:03 +0000 Received: by hermes--production-bf1-54b5569bdc-fv65m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4451c0cd4386c4b1051306e68eb9ea1; Fri, 11 Sep 2026 07:25:00 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111503; bh=MHAucsl21fQ+zt5t6z3XzNa922VKJLeEWygr1vd5y3g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=mGNCsPKwIS4L5pgq3coWc3/nLFwsC/xxop57/FoTRZfzPBrBoEAK/skx8IYRvMB3ADb0LqoGIokB/652g6arjddcpn/3Lf/sR+8Emf6GDXMgL5xykFDOaa5/debwQ2pVbWykkZMLdLGS1p2yN3okFVbvUEBizmHPbvqGFpuXc1lrJjKSLny+TLkum6IfRh42h2wBTU1dRIWb8E/1qylepU60IRSIHONVqT+TNDQO+b34xWwT/4aEcpmW/Xkv0tU2fscucv1gi/cqumTBPWJG7SRL2xgWtLAEuHzBEtrlKTzC7kgqJCIzKiQWo6HSeDr8VwIbW6euhR7ZI19GzfpF3g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111503; bh=ItvF/EjmknDMnmunyCgEQQBZ+jJQ/FZnOumzkxmVWC9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Hu6b/MxlJN4U+/5tIL9BOK/8vNwphnBGRuCuN4rrcdXJ9hzorxsOvCzxWSCekRidPlNdZsVmXfEWj5+V9pMmOU0H12n/olXwk/cGajmYCIInyO2e88n9Ace17sjLTeCWKTi8EnA6kAWW8TUi1B3r7ulS3Xj9A4juum0iakwJJkwnA9fAWCHNlo/PII1S3k08k2xwRGCTGRBa8cQjtR6lwaW0qc6eqTqTX9ejDiRS4ESTJql6d/UsvpnOfBL2au2H//dVBb/2OA7ej96+kQ8DzFraYe1PTzEzz5lryh8kwSjgcZLuVriSpZVZCQwxpEO08+39/fKtqu6Oo8hS2n41rQ== X-YMail-OSG: ZCQQLDYVM1njOau7aIEpTe_HowWStq2DyrIyaS0l0BC09H0sLmUny_TJjHZ7CDt ZjGnavHsEzmRwnhPS9UNk8Yc5uxPJ29D7MUHDuVb0i9QabFWZt9HnjNt9QWuZNCUodHNI7VVrC8y .YlQ6TtSefckiRRjK_gSSJsg.NtWOx.HyM4TOKhLGPQF6RgysX.xCBZuJydPptob91W5fF5On0Mv U9lMdWJFu3pUcmc6P.HvWNUc2bOmqxb0FCr9ZAgZQEdURtfL8VACOxpYfKIL5qlTA0OKy0pc5801 omNY2zalBrbSTknqWCp6OdTz1pYgdIZaDN2U7QzxvuOIYWOlbaow3HJ3lLKUku9Mhh_Yev9KkiZw a5VR819lhu51ZvjXQ8a55cx0ErGtDjts44FZZ7yv1up_fHILyUpLVkoN9voNnO6hiP1KGw6MPTzp ox0T74AXrKanc1wKwFz.dJDcKJ.voQRcrmvbW3DY7XV41RXou3ECP8oDNgxtCNmWOKGxkMD5haRH tW9Icrqy2jauK0hip2gdNpBIlmmqtGkZrWAECh9pdVaaVXQHjOkebZis_hnG4PkALRi7OQ7_hfjQ EMk5lzUDU_dg7.aV5XhlMFzfuxLAgp8sQFRwOmiKlt3xb2bZTrMMLHVUpM2oNBGlxbmhWNCKxYm7 zVD41cdMLK9nuR04HCOG4.NPWgKTwCRhutjkCMAMQov.2qzc1XeqgY1ebsFfjr3XXhKZcY88jscZ 4B22Iq1TuDt8OCl5k3jyAD.QaaFztdjmalZzgrfkmFpW1v7SiQSb0nuTQhY7b7CHkYZkJB3qvJt3 Awf78PW1MUCzJzBNDIM3G87DT5W2KxN3cKJWhGSamlYwf0vZ3Y4fEoPmlvioaEyUrWi0dZbSm2aq IMLNlF83Ywb7mkeIFRcmAiZK0yPIfCqq.FZXo1KtBIy0Cv6Vbb7xqvP.NpwkmgGpec7FgOqFj90s icNQdP03DrkoD9angoQnH0uTpTfAg_giK2LHutQL6FFY3VNKropRc0j3FzzQEJQ7WroPSrkXCYwx 6G1N_u4O67Va17OC0H6N4UgXJlk63zGyjusGMbriWam_5Z5RC2ZnAY7funm2z7vgM1wfcjEAsYUb r802cSN5iFIM0zWUxQmedyLC2vO8wFjJDzWoBnkS28sr.ttmrKRQtN72JjYF5DP67k3RS3k04CRS TcxhdWEo2OFe18YK1aAIPil7vYX7z1Wzy29gaFe54.VUYJjkUu7lo1ExAPqRoEcItTO_PQvB8Xjr 1UGzBNoOQlN6eu894NV48woYt2SBkE5pRRXlOM.Z0qjBfiKW3p2BwGuf1Cy6KPLwtQisDzngsbBY JAs1Al52z5CRnqTlsoNqwHz_bHP4Pow2Z_iTrgjip2u5kBAybLHnkH68nZQcpSjoM2o84qSUCJ.L gJE40kxp.nGbcuGNzeTCVZez7nVoK1799kP13mCKfAFDItzXXioCUfeo_Vl5FWqH_mYfqI5UtNl7 vT1LxGihJIDq6ProoEOq9hjUazOhaasHKoJMATkd8m6oA6IxyGMptZvUspKR.gwtRkGjGpX5ELvk OJk3RQ5HIEkHLKJjkep_HLVIR7CljDTK0xda97unIA1MmpeoyPBu8oKzkW6YiHzITRe2bRX101GX aI7q7WoZN9NKjxEcZVHD5jbVadZZM9Tuqd96IyZ3Xd8bIWFOxhOMapNHPWWC.epr4ILCvIsAWbfE .PEbLfpwrlO8J5iNDssyhC6onELitmksLGNVE3dpinN72Y9q2NcyTwxW6vpXMtkg71byAChXFztw j6o4zDrj2CP3mVxNLd5t11cjWxUPiEAq7.FQYMEbaWj5eihXiegM29Xzzix2wwznDWne2ACyPnu9 mDxMFLZ7aVeo7zxAkYP4vTqXJlFS63KLkL2YDPXyWEZJXYRW7dpwjPZkvo3ImcqEfZKlvPZuK7xZ vvmXINe1WxKHN_6zdfNhaTr6FTX_LTg24onq1Tm67qnqHjGu5BSJs3pk8gnez9IT1a0e9hO6O_7b apdHvc4rNqvoOAfQRRQg3BCHn8H2W5EBkXMFHkpns3FCh1W1sTMt0kXQzrLZm99_iE.IEYJYeDUs ZQtHo7OLDArerpIMe6AAdn9lhlthElh1uNWGqRkjTeaN9ISZgin_qhkwDmp_rEKarSWYq3au7nuR VVapF_pmV7X3tNq3hMkEoqqBf3oEsrRuRd4S0OGjHjblnLvRH3w4TT0hPljBAuU8L4YsdAycAkXk UDXglIaqjIDXcuImKwAYtq9igvJQBfpXDZtqb X-Sonic-MF: X-Sonic-ID: 2c3085ab-b377-45e0-bffe-0943d287da5e From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko Subject: [PATCH v6 3/7] xen/igd: fixup device id before registering rom Date: Fri, 11 Sep 2026 03:24:49 -0400 Message-ID: <20260911072453.46256-4-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260911072453.46256-1-brchuckz@aol.com> References: <20260911072453.46256-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 3255 X-purgate-ID: tlsNG-d25034/1789111505-004CFA5B-5273D7C5/0/0 X-purgate-type: clean X-purgate-size: 3342 With the current implementation, Seabios does not see the fixup of the device id done here and consequently Seabios does not load the VGA bios and the guest screen does not light up until the guest OS graphics driver is loaded. So there is no VGA output from the passed through Intel IGD from either Seabios or the guest bootloader with the current implementation in cases when the device id needs fixing. Fix this by waiting until after doing fixup of the device id before registering the option ROM. With this patch, Seabios sees the fixup done here and loads the VGA bios, and both Seabios and the guest bootloader light up the guest screen in cases when fixup of the device id is needed. Also, remove unused header hw/core/loader.h. Fixes: 881213f1b9c5 ("xen, gfx passthrough: retrieve VGA BIOS to work") Signed-off-by: Chuck Zmudzinski --- Changes in v6: - No changes to this patch Changes in v5: - No changes to this patch Changes in v4: - Add a Fixes tag hw/xen/xen_pt_graphics.c | 3 +++ hw/xen/xen_pt_load_rom.c | 18 ++++++++++++------ 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c index cf424bc..c5ab23e 100644 --- a/hw/xen/xen_pt_graphics.c +++ b/hw/xen/xen_pt_graphics.c @@ -223,6 +223,9 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev, } } + pci_register_bar(&s->dev, PCI_ROM_SLOT, 0, &s->dev.rom); + s->dev.has_rom = true; + /* Currently we fixed this address as a primary for legacy BIOS. */ physical_memory_write(0xc0000, bios, bios_size); } diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c index 319efca..407b630 100644 --- a/hw/xen/xen_pt_load_rom.c +++ b/hw/xen/xen_pt_load_rom.c @@ -4,14 +4,22 @@ #include "qemu/osdep.h" #include "qapi/error.h" #include "qemu/error-report.h" -#include "hw/core/loader.h" #include "hw/pci/pci.h" #include "xen_pt.h" /* - * Scan the assigned devices for the devices that have an option ROM, and then - * load the corresponding ROM data to RAM. If an error occurs while loading an - * option ROM, we just ignore that option ROM and continue with the next one. + * Normally xen_pt_register_regions will handle loading the option ROM, + * but in some cases, such as for the Intel IGD, the option ROM might + * need to be modified. + * + * For such cases, use this function to get a pointer to the option ROM + * from sysfs. Caller has the responsibility to edit the option ROM as + * needed, call pci_register_bar to register the modified option ROM, + * and set has_rom to true for the PCI device. + * + * This function must be called before xen_pt_register_regions is called + * because if xen_pt_register_regions is called first, it will register + * the option ROM and any attempt to register it again will fail. */ void *pci_assign_dev_load_option_rom(PCIDevice *dev, int *size, unsigned int domain, @@ -76,8 +84,6 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev, goto close_rom; } - pci_register_bar(dev, PCI_ROM_SLOT, 0, &dev->rom); - dev->has_rom = true; *size = st.st_size; close_rom: /* Write "0" to disable ROM */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:25:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:25:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415729.1644968 (Exim 4.92) (envelope-from ) id 1x4vdI-0000Fh-Fi; Fri, 11 Sep 2026 07:25:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415729.1644968; Fri, 11 Sep 2026 07:25:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdI-0000FZ-CX; Fri, 11 Sep 2026 07:25:12 +0000 Received: by outflank-mailman (input) for mailman id 1415729; Fri, 11 Sep 2026 07:25:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdG-0000CD-Eo for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:25:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vdF-000Pny-Rq for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:25:09 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3acd1-2eae-0a2a0a5409dd-0a2a4505b21e-14 for ; Fri, 11 Sep 2026 09:25:09 +0200 Received: from [98.137.64.82] (helo=sonic305-19.consmr.mail.gq1.yahoo.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3acd3-4cb1-0a2a45050019-62894052ad2e-3 for ; Fri, 11 Sep 2026 09:25:09 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:25:07 +0000 Received: by hermes--production-bf1-54b5569bdc-fv65m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4451c0cd4386c4b1051306e68eb9ea1; Fri, 11 Sep 2026 07:25:03 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111507; bh=w67e4rO/vcswdR8q6gV9R4+pyFjhs0XSGCFwSqNmNQs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=W7dUzzwP7pE0RmixTMbaj3MuPTfDk6Ud0T3qI1s6hFs22CXloL04Jd+DGnVTPIeeuIoV30VMJLI+Qw/dpuwJv5zTkdf3Va3Xm5/nORd6kfJZZiDYI/bLs7iwn1hkP/WMyH0U2LU1jqp2TI4g17E4q84SZbkKt9Ia7G6S0Z5wbSLeMi6iY09GxhqgM26iNJCp2jEf6q5h5q0n5GBBwqmILMU0cAW37j17ugnc5+4nF92Mnvao4Q2N6u5K4/z/9nz+N6CgwrDlkaRlRn3IuSh2MGuXQt2f8UQ+OjxAn/KdaIU4whau6zgexRrY85XKurav8Zqb60z4bHdD/SrGygYHWA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111507; bh=mP2MEXUlevjdjchDEDIedOgXWaSUBK4IxfoiGoyxx0l=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=gK/tvhqXhp8wFMSmrMJ/azT5HWtmHCA/pauNdSneDTJXBlfhhMlaRv84J+C0+hbuwhL5+hHj4hzC76h3HPb/wv54K0nTMOu+JCPYhyTAnMw/rHS/P4AtTmB5tcenAaKX6nq70d6ghLbCdHvEbmMPATrCB3vuA0o2uEYWGlgfZTtiobcYC2DBuG6OKiwqLWa6jX8QN6J0N5FelDTWUoMSuAoBFboacxC8J8UoqbGYsoMEegCnEFSuz0y0MoBRMdqQkqWAvPpMZ7/ukprU1BAZ+aoc+oYzApgwxeVeL+VXyJUia98D7yUgmoA2ilp5DJ/BkjTwHQl3mArVw3FnZ9h/Ew== X-YMail-OSG: YetdfK0VM1l0HafXGOGqEu.ProfwvWjW5UX_NdbP78CPV8_oK_cses5Qy5UI1Xp Zp8Mawtec58Iys_PfKi70nayiRA9R48nCtc3_dqDBfGTHz3s1O_g4wPMcielcfT4ytDRY5pT45AL B0C1ZeCz3rOtNn17CcQfPtmE5wo7jFNrm_FhY4QiRniZkQxxD4xneBkFGGhOWmQ8Tjt13DkYM2kK gLoQROphnikDxOKC7Qy396Vs5droCxXvHrl2y3TA.98YZmdth0V0dZMkyANllDO9HtkLxtGgNf8o fOCTaiZ80d1dNjcZ1AxXJkw4FR8JmuVIq84pxI487SjH.8v5jrvQlvAdOYWnAUSMg16Plh8Uxfs4 3w_sjB_WqKaOzjXOClG6uxSLZDKpqh35zDfQCqpkzau0hdYlmshmY.59E7viP5MhkKG9vcv6cnWl 3Ohl3HtSoSlDGfOgM47igkv0g8WBkdpNhmx4rO5n_eVH0xwityWhaJ2YJ6C89X6AP0mhHZUbJzeY i1YDMFJL18jvotH2eC1NRTyNLOPWJrEvRhdP3lakj_GHT8C70FqkYMx1c1lCkXKAUwmbEILoV93O ocWWHJYmSN2zkY.lh6slfWDxu5usL14NnEnBFTIR5OLeLPRtJ6cAVvq6pTELDHgqQu4xuHjbDyeH _aG1RKXwEx2zc235Jwm5zkSlMEKHcTSIBi05GghZlrth86QX7z27hGUSpFXj..nACcn0SkF0z_XJ 9GFVqqSPciqb_NoNjh3gMOXmXbgisKLaExCkStuOEhFPXnTRHt36ldO38MkCOBjhy9Pun4u_ZHyT q2PuECi2YK1yadPia4WBjZslyY7tYcXMrMlwkFFmvC36AYpl6rNuoag0Hh7nLSzW96wxTj4zK1jh G5FVo6T.0lSPUkIwDqwqQJLUbF.cWpOqtFZnlJgpnnO_TNPLS7NFcGjcrMzGtemGr5uDmBtIlXuU zt7VdRCCRHpKECd81scIODWSYZN6jhdaejTgjVc9OIKUYmGABoC9F_xh5JIxsrJRA8um_7briVjL La5jhLsYJCRPDTy_ElWx25eJBJcJy721v33gQTGd0JoS0dsxkPlR7wfK4CpIekVxnsxWMFJCVYAs U99I6RXric5AcSWM8lkdP5jaywKOhtPzaOlJi_WxLLDmMw8TSG.AwCszG3eNRXy5dp_pxpMg8f.J 9Y5M0A8oEnhKlcTmCEvpTP_bjtFmlrUSp5Tq4sAKB5iUb20coqF5H49.CR_.S9Xxo0C40_33abLE WuFrR8yKl4lawFZOrnavRc4feaHaC2DGKncTuv8jdBBXOZvOgzG0N8KrZKPxbXFGOxJy1CASVphD cuV4U.L3r28wdEu7KFCw4hscIHjTqAzEnt7CGI2T8zQ5_AXbbc54FtX1vOHm1YSfZNYSC5Dovozj UHqIPjuBYOw0gpmQDdURm9p7yI8WXPdGq3v2AkVLUls2bhsNyctbNbE_K72A7k9wIRNRIzViYdPU pfxzx1E_d9VTxDuPKzzqa9ygqn9pKvkI058DQmoRpGxA3x_QZ6yjp3OHe5vv2NpMd7n7dXLMl56c CdKTDQ70kr6XPZu_SvZfcT4UK2Y9tikuynIP71klHjuY4aNoxPQdzeAZ7kxKyuI42GyFjJkISvTU zGTQ5f3VBlTxTM_BhTE.P0CQKzMvk_S4kz351gHffFDpQqC.VdVrK2du348cDb6MdEqZ1xaIMk2p m9ZfmaG.bfOqr8K.4N.LhscLPilkdXoeF_4g602n2FeQaJUeyGkysyIcaJnsuDwhgeTZt_8YiR9U gmbwVWnqxLVl4cEdZz.fdlJWHEIeQ9JAhD6my0oOThs2DT5YhUDwEfBUBPQWPZuYi.m6p0YI7pvK lazgg2TNoJF5qVQztyqdhHzLxffRmr5X11WsMV6r6D47xxwZNYSnZjNyQUptNhXeni7RAD8Rp4e5 kv.3atdOFKCvIuSPFMY0BisNLLbicn9JlP9DRZCUhTq1hHaM6qEeQ_xifSSxheTIiBOjb8I9Wdef 4aLoEh0dNM_aGCpkq6CvXukTSZci2oBpB8oB1sZWeHlmd8Hua6wTG8hNh919wuAqD0Qzn1Zcvifn 0yRHWumJ5fN4iVEK3AujwAvgjqeOAatG5ir_fxAcJWb741fA0M2kqlUKWY7x8VVcpiFDFILnsMtX kGetZOB1sIRUO__dZuMUcH_by3bheC0cXU1MBPl3oJDnhOQvcSFHvWzqgYTDfFlOeb8SfzMPmaZB 31KfApoBUUcRPfqUR37f6FW2.a6ZeNZPe2I6U X-Sonic-MF: X-Sonic-ID: 6a888ae9-c4d7-4342-8360-a9f4991ce3ac From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko Subject: [PATCH v6 5/7] xen/igd: use igd header for IGD related definitions Date: Fri, 11 Sep 2026 03:24:51 -0400 Message-ID: <20260911072453.46256-6-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260911072453.46256-1-brchuckz@aol.com> References: <20260911072453.46256-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 6207 X-purgate-ID: tlsNG-c201ff/1789111509-F44A42A1-CE39954F/0/0 X-purgate-type: clean X-purgate-size: 6368 The newly added mocro definitions will be used in a later patch that adds support for an extended video bios table (VBT) and are mostly derived from the Linux kernel vfio driver for the Intel IGD. Also rename XEN_PCI_INTEL_* -> XEN_PCI_IGD_* to make the names of the macros related to Intel IGD more consistent. No functional change intended. Signed-off-by: Chuck Zmudzinski --- Changes in v6: - v6 is the first version of the series that has this patch hw/xen/xen_pt.h | 9 --------- hw/xen/xen_pt_config_init.c | 8 ++++---- hw/xen/xen_pt_graphics.c | 16 ++++++---------- include/hw/xen/xen_igd.h | 16 ++++++++++++++++ 4 files changed, 26 insertions(+), 23 deletions(-) diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h index 095a0f0..ef93ac7 100644 --- a/hw/xen/xen_pt.h +++ b/hw/xen/xen_pt.h @@ -87,15 +87,6 @@ typedef int (*xen_pt_conf_byte_read) #define XEN_PCI_CAP_MAX 48 -#define XEN_PCI_INTEL_OPREGION 0xfc - -#define XEN_PCI_IGD_DOMAIN 0 -#define XEN_PCI_IGD_BUS 0 -#define XEN_PCI_IGD_DEV 2 -#define XEN_PCI_IGD_FN 0 -#define XEN_PCI_IGD_SLOT_MASK \ - (1UL << PCI_SLOT(PCI_DEVFN(XEN_PCI_IGD_DEV, XEN_PCI_IGD_FN))) - typedef enum { XEN_PT_GRP_TYPE_HARDWIRED = 0, /* 0 Hardwired reg group */ XEN_PT_GRP_TYPE_EMU, /* emul reg group */ diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c index bbc82a2..a708c82 100644 --- a/hw/xen/xen_pt_config_init.c +++ b/hw/xen/xen_pt_config_init.c @@ -1808,7 +1808,7 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = { }, /* Intel IGD Opregion group */ { - .grp_id = XEN_PCI_INTEL_OPREGION, + .grp_id = XEN_PCI_IGD_OPREGION, .grp_type = XEN_PT_GRP_TYPE_EMU, .grp_size = 0x4, .size_init = xen_pt_reg_grp_size_init, @@ -2023,7 +2023,7 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp) XenPTRegGroup *reg_grp_entry = NULL; if (xen_pt_emu_reg_grps[i].grp_id != 0xFF - && xen_pt_emu_reg_grps[i].grp_id != XEN_PCI_INTEL_OPREGION) { + && xen_pt_emu_reg_grps[i].grp_id != XEN_PCI_IGD_OPREGION) { if (xen_pt_hide_dev_cap(&s->real_device, xen_pt_emu_reg_grps[i].grp_id)) { continue; @@ -2036,7 +2036,7 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp) } } - if (xen_pt_emu_reg_grps[i].grp_id == XEN_PCI_INTEL_OPREGION) { + if (xen_pt_emu_reg_grps[i].grp_id == XEN_PCI_IGD_OPREGION) { if (!is_igd_vga_passthrough(&s->real_device) || s->real_device.vendor_id != PCI_VENDOR_ID_INTEL) { continue; @@ -2046,7 +2046,7 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp) * If an intel device is pass through we need to trap 0xfc, * therefore the size should be 0xff. */ - reg_grp_offset = XEN_PCI_INTEL_OPREGION; + reg_grp_offset = XEN_PCI_IGD_OPREGION; } reg_grp_entry = g_new0(XenPTRegGroup, 1); diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c index c5c2d47..be71989 100644 --- a/hw/xen/xen_pt_graphics.c +++ b/hw/xen/xen_pt_graphics.c @@ -12,8 +12,6 @@ static unsigned long igd_guest_opregion; static unsigned long igd_host_opregion; -#define XEN_PCI_INTEL_OPREGION_MASK 0xfff - typedef struct VGARegion { int type; /* Memory or port I/O */ uint64_t guest_base_addr; @@ -251,8 +249,6 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s) return val; } -#define XEN_PCI_INTEL_OPREGION_PAGES 0x3 -#define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1 void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val) { int ret; @@ -264,15 +260,15 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val) } /* We just work with LE. */ - xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION, + xen_host_pci_get_block(&s->real_device, XEN_PCI_IGD_OPREGION, (uint8_t *)&igd_host_opregion, 4); - igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK) - | (igd_host_opregion & XEN_PCI_INTEL_OPREGION_MASK); + igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_IGD_OPREGION_MASK) + | (igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK); ret = xc_domain_iomem_permission(xen_xc, xen_domid, (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), - XEN_PCI_INTEL_OPREGION_PAGES, - XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED); + XEN_PCI_IGD_OPREGION_PAGES, + XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED); if (ret) { XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:" @@ -285,7 +281,7 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val) ret = xc_domain_memory_mapping(xen_xc, xen_domid, (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT), (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), - XEN_PCI_INTEL_OPREGION_PAGES, + XEN_PCI_IGD_OPREGION_PAGES, DPCI_ADD_MAPPING); if (ret) { diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h index da51f09..469171c 100644 --- a/include/hw/xen/xen_igd.h +++ b/include/hw/xen/xen_igd.h @@ -11,6 +11,22 @@ #ifndef XEN_IGD_H #define XEN_IGD_H +#define XEN_PCI_IGD_OPREGION 0xfc +#define XEN_PCI_IGD_OPREGION_MASK 0xfff +#define XEN_PCI_IGD_OPREGION_PAGES 0x3 +#define XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED 0x1 +#define XEN_PCI_IGD_OPREGION_SIGNATURE "IntelGraphicsMem" +#define XEN_PCI_IGD_VBT_SIGNATURE "$VBT" +#define XEN_PCI_IGD_OPREGION_RVDA 0x3ba +#define XEN_PCI_IGD_OPREGION_RVDS 0x3c2 +#define XEN_PCI_IGD_OPREGION_VERSION 0x16 +#define XEN_PCI_IGD_DOMAIN 0 +#define XEN_PCI_IGD_BUS 0 +#define XEN_PCI_IGD_DEV 2 +#define XEN_PCI_IGD_FN 0 +#define XEN_PCI_IGD_SLOT_MASK \ + (1UL << PCI_SLOT(PCI_DEVFN(XEN_PCI_IGD_DEV, XEN_PCI_IGD_FN))) + #include "hw/xen/xen-host-pci-device.h" typedef struct XenPCIPassthroughState XenPCIPassthroughState; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:25:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:25:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415730.1644975 (Exim 4.92) (envelope-from ) id 1x4vdI-0000It-Tm; Fri, 11 Sep 2026 07:25:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415730.1644975; Fri, 11 Sep 2026 07:25:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdI-0000IO-LJ; Fri, 11 Sep 2026 07:25:12 +0000 Received: by outflank-mailman (input) for mailman id 1415730; Fri, 11 Sep 2026 07:25:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdG-0000CO-HV for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:25:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vdF-00CxOg-Ua for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:25:09 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3acd5-8faa-0a2a0a5109dd-0a2a450cd35c-0 for ; Fri, 11 Sep 2026 09:25:09 +0200 Received: from [98.137.68.146] (helo=sonic302-20.consmr.mail.gq1.yahoo.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3acd4-f479-0a2a450c0019-628944928126-3 for ; Fri, 11 Sep 2026 09:25:09 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:25:07 +0000 Received: by hermes--production-bf1-54b5569bdc-fv65m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4451c0cd4386c4b1051306e68eb9ea1; Fri, 11 Sep 2026 07:25:02 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111507; bh=7fxAXafCgkhWXQ8Bsf9UiQyUsF3UYEGG0N1eLLgC4dY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=MY3bu1YIRCtta03Rlipjs9jUs1884+HtWo02dPwMqdNiXfGND5jbWoQQ73rVvmFAxfMh1rSKNCMmUuv0f3O3nJaF48sza9pov6e+l+5/jgrWX/pDVibkOPsfi8YIe/y/Pho4nZxTqjiYEEXkYQ7WTBu9rkKWm87rccHdDwVCWORazLPteYYxrU9xB8A1WWaALgrm/4WGLNNraisbgpawWT4yCiTwKRcRrUB5TrtBlF+L+XCD94/0oIWScWB/ITGti3+FA+DWEgJt/bbxP3uxArBWxuz8LXVFcbMm3e1FfLCVqskURWa6ycZ2qiubUAeiISzjx7yLDbKf/tpHsLRAtA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111507; bh=R67dZrL14KOXcf7Htx14zdMHg64juJit3yfZK6RHShP=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=AVymKrAS51hbwh2XQ86S1xqC2/S/pId39gT5gLi9EPmC71kvDOIoMtCHjmQ0PH4HOd+kd6qEJZU+yw/oy0ad+Qvtk702yzQybpE6w/IqgP1gLD6AXQobKic6oJhhJWIlVR17YeqUSBUR4CUm5lPlm/JIROPRDo8QGGTkGQiqgltSSOzirGDFTEsuQKYe2TuNRZ+mnjMLF3cr/7BWPkcCSdrM8kHBdMU5yBJd7NuTbIdU/nNsLL7hj5U+Tqb7Jw//ua2OA1oyDj71El72Kz7vwvadsgsTLd6HMj49tWedkm+wJti/4yyh/YTzmlckEeZt6J3UDL/ydHB33+3RVC3pnw== X-YMail-OSG: TdyjS4QVM1mzgjCy7Bu9yrDGtN03HRem.ZApojprzrTauLRU_qRx8ZdHoeHoqCD GkHGfbcRZq.i8qBkyw4lCGycdR05XEXRvmdVNSsikGRGea0dTk88CSfUW3s6heH_3QZnzWXs6GdQ NLxGswdBbMVOpcUC0vkK.4lLgp4djlVgRM7gE7If6O_BznhDZL8DYK82Z6t7v66XAkw.4LDTvcrB UyZn_72P0P8pDfEwVEtEdoiRd2VPVDJvRh_iWfPl1M0O.KX6t.k6xxK8L0UrLd0W3f.2EJIAGT8c PCFqOgAOXkNQJ4teAXfcPmKUEk9Vuu3VSJ0Ko6hZSU2i2a3o2Y2fGlKGZkIqPJPW8_EABKXiOLb8 o52MOFncWd.G9BSIQbykStHE3QBPT23Jdi0Zin3hCzJrV4IvXw9wnMmBTRZI2qYrtYuTCZh5vt81 fVnRQxVU5vZBv8w8Sk6OBtsdtpurGw4xu.8gfzR1M3aEY30fZFSuNQQZKl4u8dc1G5bKBMYpVm7m zZC75fXyvAs4xHf6xJh3n5gtnAIMM9XHtueD7A_GrLqwnehfl0nnMa7VwKznvGZf_fLqKGW13ra4 FU2dCPp0scZ17M6MY3JCqAOT4DbHMa666NEb5hkJZnfBbRd3_2bCcBBePQyXXglA2kvOhx843lBH hF9cWSSdsjjIyX6mgM8HNv2s6Yfk68MdkmFwjqx3Kzut0qgXaTkMGuuPr8b9q_P3jhnk6tOKUUeF l5PJaLsZAAvyEWHhqCJcaQVRtbwtVisxQycWSE_gw5dmVyoVYafo3MZy4HL4n_eaD3Ca5PX5rnJE 11.iKSyc934Np0Fu1MFvYIr8ipjBclV8Oq11aOVcC1wFUuXudA_dIKetPC4Oy0cyVvB9NcvtBvYy LXrxxLMV10IxeaDWIYjVaHCf6rRam76iRnL6V08O7Gp_uawCbf39GOJOr6sa7ofFrETh5T9ttB.N uJR8Kq7PEll0Gg0B4imOv_7Po8xYPDUyCkZNmmYvQISjEiDFO0dq3CbT_vyc22973u.SmyxSyK.Y AuZInZx.1Gss1mk6_fUB.ND427nRqT2bskv9DllP8EgabRreNXPPxM9RHUxoQq0dEOJpE_jZwmPL s12KL78vGzXk63ykngyGvXt9nz_KXD_CvdXP1Q5N.fQfmJkBP7V21m7uEuZVepcIGe.D_V9bVAPn hY8EmtelGU38PLOJ8viOY7q1nX6wFcY_NTwwhEgc5xTA9zfWXA.g369HgX__btM.2EgvTGeJsga. YhzvES6ch1o_PDRnGF7Nd3txH4PVfLWr9v6A2GmkksZdmF3SqPkiaN3OGaUXiwuRgxIIZKQ2gby1 IKwVOp5_NYW3RAQIpJOoiKA9fqSKUtRt.AOvfGqUnoCOmOoHnAnSjSblzDb2Qu9sl0m6A13Kp38e ztjcuZy4c9lZbrDnXDyFqPIPZu8urSM0r72k13r9C43BFI38dXYstM0JWb6j3fh55e0ToP6GGjV7 qZYN42BpJkAMPZa6ZK.kzVP5yNx7pbka2tQY_RLuYySZrCaVjd5Fuu0HyzNg3RicioN4VReJ.LeR bUJIWcPZKnSXZ1EJrnTfoT5sTcnEvgq4MuND87Pqt8QeBwdwGQoQSFp8gvaCXK2XMqrtgImZ4eZE CaDNS1uJnrCU0q8e_GrAmRQW8wt5BDfuKx8xJzb3V4nwqh9T_prl2UWrtvwNpAnA4cmD7Vx_gXr4 1cVONYmkDtZIw0SaBGjiTJqNkG2zhyrpQnsjjO_dP8G7bNm90ZR2z87ENT.GXNy956r.jdKm2fr0 brGW4Vk4Xrl7oRDmVBVpLAMnW60JhPLNmlcb_sO8VjoyBWzN6knLDKJ0a_jlO0OGUSqxi9fszjib pwhfLZmjJpJritfFzDXpA3aXm8wiwj3PE1WfDf9dMAZG.qikmErSwUaYxuPFDXi4gVFiOzYAb.Bh UUKwEHw09TIosrYue9dS3SHIoKpfcM2Fbqvp7sTkmgpI8teKKcnSOa5BwYCoBFbQFZtNyzwgQB5B _W42OaX50UnCcZdluogrDALWQJzAjR3lA203vnwq9T0JwZzDO.bddyQror5LeqyjT_IGrJDcTQC9 1fGMaMjgz4PWUZumDIC2X9V4PcVgrNPrt1mAwC70Bk.Ppm1pRnaYMotUDPPkYpFYrhKWMIW7W56K lZBvMm4hzUfzaA0L_VYTrYicIndZr9sCX0OJR6ftEi_V5c0QGrkfibd446UstF7V2WSQZydIxl89 6EkOkHMCQuUFD7NxxzrvPohsIUxZLYMcorCrf X-Sonic-MF: X-Sonic-ID: 4e403500-ce38-485d-8ff9-5e41d4fcae22 From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko Subject: [PATCH v6 4/7] xen/igd: enable guest creation when ROM read fails Date: Fri, 11 Sep 2026 03:24:50 -0400 Message-ID: <20260911072453.46256-5-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260911072453.46256-1-brchuckz@aol.com> References: <20260911072453.46256-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 4949 X-purgate-ID: tlsNG-d25034/1789111509-002F0A5B-C52202A5/0/0 X-purgate-type: clean X-purgate-size: 5062 For newer IGD devices, the host option ROM is not readable from sysfs and this results in a call to error_fail() that causes Qemu to exit(1) so guest creation fails with the current implementation for many newer IGD devices. But this read failure need not be a fatal error causing guest creation to fail because the guest does not need the option ROM to successfully boot and run. The guest only needs the option ROM for getting graphics output from the guest during early boot before the guest OS loads the Intel IGD graphics drivers. To fix this, allow guest creation to continue by avoiding setting errp if the attempt to read the host ROM file from sysfs fails. In this case, the memory for the guest option ROM has been allocated so free that memory by calling object_unparent(OBJECT(&s->dev.rom)) before continuing. Replace the error_report() and error_printf() messages for this case when the option ROM cannot be read via sysfs with a suitable info_report() message. In the case when the host option ROM cannot be read via the sysfs interface, xen_pt_register_regions() will attempt to setup the option ROM for the guest the same way it would for any other Xen passthrough PCI device that has an option ROM. Signed-off-by: Chuck Zmudzinski --- Changes in v6: - No changes to this patch in this version Changes in v5: - Shorten info_report message to resolve checkpatch line length warning Changes in v4: - v4 is the first version of the series that has this patch This patch provides initial support for many newer Intel IGD devices so, at least, guest creation will not fail if such newer Intel IGD devices are passed through to a Xen HVM guest. But this patch alone is not sufficient for proper operation of the Intel IGD for many, if not all, of the newer Intel IGD devices when passed through to a Xen HVM guest. There are two main problems with more recent, modern devices: 1. The newer divices might require patches to the Intel OpRegion and also an extended video bios table (VBT). Without support for these aspects of the newer devices, the experience will not be great and in many cases the Intel IGD still will not function properly in the guest. 2. The newer devices only work with UEFI AFAICT, and the Ovmf* platforms provided by the upsream edk2 project do not provide support for the Intel IGD. It appears the problem is that the ekd2 project deems the fact that the hardware manufacturer does not provide the necessary firmware, the EFI graphics output protocol (GOP) driver, in the ordinary way by making the EFI GOP driver accessible in virtual environments via the option ROM of the real PCI device, to be a reason to reject patches that add support for the Intel IGD. This, however, is not a fatal problem since it only affects the guest during early boot when OVMF or the bootloader is running and the guest OS graphics drivers have not yet been loaded. Lack of support for the Intel IGD in OVMF does not seem to affect the experience negatively once the guest OS graphics drivers have been loaded. So efforts to address this problem are only important in cases when it is necessary to get graphics output from OVMF and/or the guest bootloader. The last two patches in this patchset address these two problems. Of those two patches, the first one is more necessary, and the second of those two patches is only needed to provide graphics output from the guest during early boot. hw/xen/xen_pt_graphics.c | 7 +++++++ hw/xen/xen_pt_load_rom.c | 5 +---- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c index c5ab23e..c5c2d47 100644 --- a/hw/xen/xen_pt_graphics.c +++ b/hw/xen/xen_pt_graphics.c @@ -187,6 +187,13 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev, return; } + /* Case when the host ROM file from sysfs could not be read */ + if (!bios_size) { + object_unparent(OBJECT(&s->dev.rom)); + bios = NULL; + return; + } + if (bios_size < sizeof(struct rom_header)) { error_setg(errp, "VGA: VBIOS image corrupt (too small)"); return; diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c index 407b630..f136f13 100644 --- a/hw/xen/xen_pt_load_rom.c +++ b/hw/xen/xen_pt_load_rom.c @@ -77,10 +77,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev, memset(ptr, 0xff, dev->romsize); if (!fread(ptr, 1, st.st_size, fp)) { - error_report("pci-assign: Cannot read from host %s", rom_file); - error_printf("Device option ROM contents are probably invalid " - "(check dmesg).\nSkip option ROM probe with rombar=0, " - "or load from file with romfile=\n"); + info_report("pci-assign: Can't read Option ROM %s from host", rom_file); goto close_rom; } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:25:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:25:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415732.1644979 (Exim 4.92) (envelope-from ) id 1x4vdJ-0000Op-Ab; Fri, 11 Sep 2026 07:25:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415732.1644979; Fri, 11 Sep 2026 07:25:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdJ-0000Nd-2y; Fri, 11 Sep 2026 07:25:13 +0000 Received: by outflank-mailman (input) for mailman id 1415732; Fri, 11 Sep 2026 07:25:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdH-0000Dh-Bl for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:25:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vdG-004oXr-Og for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:25:10 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3acc5-bab6-0a2a0a5309dd-0a2a45018eba-38 for ; Fri, 11 Sep 2026 09:25:10 +0200 Received: from [98.137.68.30] (helo=sonic308-54.consmr.mail.gq1.yahoo.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3acd4-5984-0a2a45010019-6289441eb6a5-3 for ; Fri, 11 Sep 2026 09:25:10 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:25:08 +0000 Received: by hermes--production-bf1-54b5569bdc-fv65m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4451c0cd4386c4b1051306e68eb9ea1; Fri, 11 Sep 2026 07:25:05 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111508; bh=DeHWtm/4lazeyWTmPQN/A4L8FgKiSJ5/rJS30RCGUio=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=Jb7KTCTUxUSCZGuTZ+5vpdZaXU06xDRRrhILVWrEN0jPCXsWA8pBJa/v5/zApM2cCjoD9ovYrmCgVLcn7DLThZPgyrMTB4QvwA0vbTPcXw36KQyf9YfL27R0VMDCtzXJNx006L9c0Yqx3vmM3bNDChyGnnQ0M3+AUPtyPSn46qRdSaiIKipQYAMZjW2/eobDB16t9QEohMab0Bd8VwE1YyAVvCZJNaO/jjk8REtinLgYpzCy4hJZHeEIQpwhu0WhF4fKJMYNCV201FpW9njGNQfJK+HoZp+cgVKX9ipbzHMUcykTHQKMwtOqZaOIFUXHCiAtaz31h/hWTFHSt32H6Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111508; bh=XDUvK9dnrR6LWxdmuI8cqstojs0dq6l/sUU74yykL4R=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=R8/7T6s2jmdskd+WpLwBRmEIHoy7lTd7NvV6soh7068hB5LpdmUVw4UevbkxWQXrnT3RodPIY8e21iu0C9FvrfY/0to7cz9/i1HuGTptfqAd1yW/a9LSpTKGvBdhdCnIOCs7VS56NmONijlTX1BJYQ7yL4VutOuvLfcXRNnImrUvIsO8/8FUAEt4mvoONnhqO14dSBQdUxk23cgv5hpRCpwxmnDKwwjvLwkKXJ8Y6VpMn4Et1gMx2Qowy9qbPWzVIfMstHLjg76z5NCUZxZD8atK1eshCXtbj2q8XWWrwqnkNaHTXG+t0XCqlBLhx8nlTcaKVIbgu4tpz+CxIF+sow== X-YMail-OSG: Z7iXECgVM1kh.PBsb9xU6VBSCWRl0Z.FykmxECXqYgL8N3_qv60M7XLD.tfdt_1 DSOfNx2YmBFVV_0zguET9QI.6TbtBCAogZXOuma.hHLQODnROXpEXKIqJXxt52.tI9LYCd6vA5Us BXRnxf.ogSX0KjOScs9OqLPl8LLC4DwwC0_eelM1hnVd7WokECt6DpqzDSw0KGML.8eBbNfjTWhC GQbJFdC60cUCdeEzLhaYBd8ngMpN8ABWowENgs_zg4T8bhdCeC90J4jIgFeZgZT_NqmxtvMe2vrD an5lZe3xzMCG21VfJDkMxCGfpSGimAASnPIkxcu7iXtXV7xH0AMCYAhMQjJWDGRAeCZOdHhu.2d3 SskuwusqBjzdDaLkh7uq23xS52OxaUhRI3nDJ9cJbOGVtjTNCBpAUHZ9be746CX6VFEH.NeV8eVM Drg3E5ghnuexAJPP9BWitaoXtUH_HS72JsWWam4FTN5Dm3r9DOKvvc7DNEW7A7ICLXlf36vltUvk t8BsUNIIEjVZ0HxM9zt9WWEyMDkwWqkV_Kn9iKFNF14uu1Ur5XQ0haMG_3WpSXonnmV.8A6uoNzy PRg.QSImPiWusYu6Su3g1yLkSRAAbUKHAZMqJonvyZIeSCp0r0fyKTTWRfP1DdzI6zq7BLBUMHHb CMyuXq72XHzhHXtDAFCOxRRwk7vh5KKZvT10UEbhajMC9FmUQ3bzgj7VGmiu293k5VV8xUYPglbo 4c2KbOdG9p0eg0Zc95CY3WwQhv3qBJRAbAF5p1_wLFXfksE1s9f4tm8543zGZxxZtIj8kp8WwQAA 4MO7Mf400P4rzop7m6GuNZw2MCqbKhqxGQvNPe3yKSLJUGqOCaXuG5wJiOQHWzG5vPxT_mCFot7N vb1DZ38rt7QzlWPwn3esbsmKjoSNgNAQoNPmEe.HFUgfcikSYtCisqCRrEd78rRD9m7nsweGbm7R LY40C8Xk2HmqA6x4lA3qmEZPh3zySQsDHB5CTB_AJBOI1pasFYgHkn54YKX2JG1ZjQXNoNyecMN_ vW.qvy1LcVKk_fZyZjAObF3XQuonwv_tkl.c0KhSLL9inNmubYAH8vFVb1cWrm7FSCfcJ.EWu4hg BywvFKin5y7ecgwqg4byGrbRZqwPmxgidNGk_baC9c2UUYzRT_8FxqH3.9YPse9q0ZLzJNUJmDI1 YyoXZ1cVP2Phs3SxtiFIdVuuiVYTEbYowFPfhHCGkJPYuD5p301cCLQKal38iBIEQO3ghuvOjKvt XjE15DxbpTqdcyQRiIWhgCDOfxR_oMz1EkvP6Ac5oFkBbZNRuhT.AViiWSQvclN_HYwPeDO61xLQ qiDP69W4_DOczpFG4a2g7pmb7uZsLvlkKjpxIZ3DhJuZcAN31PpoKQvdHR12vSkuQZsPoVB8ngg7 vpi14Ob2CKM.BmISz4gshTFqpHQ5.0Bmmdp0d9jodRjTDMMH9WAgcIwJOxJJkeHpua9Ex5vEsS2m QoJGKHoZ.ndNNSaIL1NfLkxJRZhEp9ol65ADtg_Pm4wK7q2dVYeyPW_S1ydSxfKbulhu0sKIyd59 tGkt6iSb2kDbB3PBdF0Tchzh88_Td5myRXvMjETUA.K.PF4iCF6mGNpJSnurRkRiJ8EwfVV8GO4N TzYGTz5Z9Oosh6F3XUqIFwHDDzWlHhxMnbncCJM7GSpeiubhXw7szvIeUUVisk0.XjAxI3A5bMq6 oBncDBtvymv19EvoyLdZyjOZCT3Szc8WJv0yPo22iiQZlqx2H0ev1BYAJkWsIZYOnLONLpQ3J99n 6.fmpen7rf1BHQV64PVRdmdV.DICd1X1nwnDyGZZ_3KuDn26fX90sy5RD5xEkjKHNwYTKv91i4h1 lShNSKKUYXl.iZ43ytbQUfhezEbDfq1nV3bhxh.33k7f8GJtr_IvviIMpP5vIAptvSZrNe2wXCKg tYuL5DmwR0HJCaU3MdmZn.H3NlIP6tDfXRYzAvWY0EAUOKBm0rO16drr_AdhgBXWPk0DBpgV6MjA NfL182rb2xzq0XoDrK_ONABB_Ku23aXuDgF6XkMyX._gbwO4Zz.SBELNrc4DXvWZWHC_3WovjBrA 8nG3sdNiJHVlhFpfZnU5z38462dxPpPIDlQLatMdfAbYsVL1c1BJk22WI1QYFKut8hcmWMYLgikn OS2wd.dG.K8tNMP5s4XzNInIIb70uF6mqTdn1JlTOHXj69k6zk_MplSJx3mikL1fxPKtBGaJk5HL hmop9D3rB2HxUTN.XRHW9iR5EhAFH7msxGnbqjw-- X-Sonic-MF: X-Sonic-ID: 1fa54d50-63c0-4570-a09f-9e5053848e1e From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko Subject: [PATCH v6 6/7] xen/igd: implement support for extended VBT Date: Fri, 11 Sep 2026 03:24:52 -0400 Message-ID: <20260911072453.46256-7-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260911072453.46256-1-brchuckz@aol.com> References: <20260911072453.46256-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 25997 X-purgate-ID: tlsNG-d62444/1789111510-1FC69757-D2080B6D/0/0 X-purgate-type: clean X-purgate-size: 26534 The current implementation of support for Intel IGD passthrough to a Xen HVM guest relies on directly mapping the host OpRegion to the guest, and although the OpRegion is 2 pages in size, it is not always page-aligned so an extra page needs to be mapped to fully map it to the guest. This results in an extra page of host memory mapped into the guest that should remain confidential to the host. This is also why XEN_PCI_IGD_OPREGION_PAGES is currently set to 3 even though the size of the OpRegion is only 2 pages. So in this new implementation avoid this confusion by redefining XEN_PCI_IGD_OPREGION_PAGES to 2, the actual size of the OpRegion. The current implementation also does not foresee the possibility that the video bios table (VBT) might not be embedded as part of the 2-page OpRegion but instead added on as an extended region beyond the 2 pages of the OpRegion. In such cases, the 3 pages that are mapped in the current implementation are not enough to hold both the OpRegion and the extended VBT. The current implementation of support for Intel IGD passthrough to a Xen HVM guest also relies on a position-independent OpRegion so the unmodified host OpRegion can be mapped to a different address in the guest. However, as indicated in the Link tags below referencing support for the Intel IGD in the Linux kernel vfio driver, since the addition of devices with an extended VBT the OpRegion is not always position-independent. That is, when the OpRegion for such a device is mapped in the guest at a different address, it will not work correctly in the guest. This position-dependent behavior arises from the fact that the the address of an extended VBT is stored in the OpRegion in the RVDA field of the OpRegion and in some cases that address is an absolute address, not an address relative to the OpRegion base address, and in other cases the extended VBT is not contiguous after the OpRegion in the host so in such cases even a relative RVDA address would need to be adjusted for the OpRegion to be compatible with the desired memory map in the guest where the extended VBT would be contiguous with the OpRegion. To overcome these problems, this new implementation exposes an emulated OpRegion and VBT to the guest instead of directly mapping the host OpRegion to the guest and also implements a protocol for communication between hvmloader and Qemu so both the device model and hvmloader agree on the number of pages to reserve for the OpRegion and VBT which varies depending on the size of the extended VBT instead of being the constant value of 3 as in the current implementation. In this new implemetation, Qemu reads the host OpRegion to determine if there is an extended VBT and if so, how large it is and how many pages are needed in the guest E820 map to accomodate both the OpRegion and extended VBT. Also, in this new implementation, Qemu zero-pads the extraneous memory in the areas before or after a non-page-aligned OpRegion or VBT to avoid exposing memory to the guest that should be confidential to the host. This implementation depends on compatible support in hvmloader and also provides for backward compatibility and fallback to the old protocol when either hvmloader or Qemu cannot fulfill the requirements of this new protocol. This new protocol begins as follows: Before writing a value to the register that stores the address of the OpRegion that Intel has defined as the ASLS register and is identified in Qemu code as XEN_PCI_IGD_OPREGION, hvmloader reads from the ASLS register and Qemu, in the case when Qemu detects a read of the ASLS register before a write to the ASLS register, returns the number of pages that hvmloader needs to reserve for the OpRegion and VBT in the guest E820 map. With that information, hvmloader computes the address of the page base of the OpRegion in the guest and writes that value to the ASLS register. Then Qemu responds to this write to the ASLS register by computing the correct value for the ASLS register so that future reads of the ASLS register return that value to the guest. Qemu also responds to this write by constructing the OpRegion and VBT for the guest, patching the RVDA value in the OpRegion if necessary, and making the OpRegion and VBT a single continuous region accessible to the guest at the address stored in the ASLS register using Qemu's ioreq server. If for any reason Qemu is unable to access the host OpRegion and is also therefore unable to determine if there is an extended VBT and also unable to compute how many pages are needed for the OpRegion and extended VBT, Qemu falls back to the old protocol and direct maps the 3 pages from the host to the guest that are needed to fully map a non-page-aligned host OpRegion. In this case Qemu also returns 0 instead of the number of pages to reserve in the E820 map which communicates to hvmloader that hvmloader should fall back to the old protocol and assume 3 pages for the OpRegion and expect Qemu to directly map the host OpRegion rather than expose an emulated OpRegion and VBT using Qemu's ioreq server. Qemu can fail to access the host OpRegion because Qemu's access to the host OpRegion depends on Linux kernel support for this. Typically the Linux kernel exposes device IO regions in the Linux sysfs filesystem, but in the case of the OpRegion and VBT, these regions are only exposed in the Linux debugfs and then only when the Intel IGD is bound to the i915 driver. This means that Qemu does not have access to the OpRegion and VBT via the debugfs when the Intel IGD is bound to the xen-pciback driver. So it is necessary that the OpRegion and VBT be placed into the host filesystem where Qemu can access them when the Intel IGD is bound to the xen-pciback driver. In this implementation, the OpRegion and VBT files are searched for in files named "intel-opregion" and "intel-vbt" in the directories configured by Qemu as firmware directories. These files can be automatically placed into a suitable location in the host filesystem when the Intel IGD is made assignable to a Xen guest with a suitable patch to libxl or they can be manually placed into the host filesystem by copying them from the debugfs to the "intel-opregion" and "intel-vbt" files located in an appropriate Qemu firmware directory when the Intel IGD is bound to the Linux kernel i915 driver. Assuming the Intel IGD is at dri0 when bound to the Linux kernel i915 driver, the files in the debugfs where the OpRegion and VBT are exposed on the host can be found at /sys/kernel/debug/dri/0/i915_opregion and /sys/kernel/debug/dri/0/i915_vbt, respectively. Another case that can occur is when hvmloader lacks support for this new protocol. Qemu detects this case when hvmloader writes to the ASLS register before the guest reads the register. In this case Qemu assumes hvmloader lacks support for allocating more than 3 pages for the OpRegion so Qemu in this case falls back to the old protocol of direct mapping the 3 host pages to the guest that are needed to fully map a non-page-aligned host OpRegion to the guest. This new protocol also requires that after Qemu makes the OpRegion and VBT accessible to the guest via its ioreq server, hvmloader makes a copy of the OpRegion and VBT and writes the address of the OpRegion back to the ASLS register. Qemu responds to this second write of the OpRegion address to the ASLS register by unmapping the pages containing the OpRegion and VBT from the ioreq server. This makes it possible for hvmloader to back the pages that store the OpRegion and VBT with RAM allocated to the guest. This last part of the protocol is required to support Windows guests because testing indicates the Windows graphics drivers are unable to access the OpRegion and VBT when the OpRegion and VBT are exposed to the guest via Qemu's ioreq server, while the Windows graphics drivers are able to access the OpRegion and VBT when the pages that store them are backed by RAM allocated to the guest. After the second write to the ASLS register which causes Qemu to unmap the OpRegion and VBT from the ioreq server, Qemu ignores all subsequent writes to the ASLS register from the guest. In this way the Windows IGD graphics drivers work as expected. Also ensure that in xen_pt_unregister_vga_regions the call to unmap the OpRegion is only made in cases when we fall back to direct mapping of the host OpRegion. We could keep the constant 3 for the number of pages to unnap there since the number of pages to unmap will always be 3, but instead we use the value of opregion_vbt_pages there which also will always be 3 when we fall back to direct mapping of the host OpRegion to the guest. Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=bab2c1990b78 Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=49ba1a2976c8 Signed-off-by: Chuck Zmudzinski --- The comapnion patch to hvmloader will be posted to the xen-devel and qemu-devel mailing lists shortly after this patch is posted. It is v3 of the patch "tools/hvmloader: implement Intel IGD extended VBT support". Please note that previous versions of that patch to hvmloader are not compatible with this patch. Changes in v6: - After considering comments on v2 of the companion patch to hvmloader, this patch has been totally re-worked. The work of reading the OpRegion, discovering if there is an extended VBT and how many pages of memory are needed to accomodate it, and patching the OpRegion if necessary, has been moved from hvmloader to Qemu since v5. There are some simplifications, such as the bitmask to communicate if extended VBT and OpRegion 2+ is supported has been replaced with a simpler protocol that involves Qemu noticing if the guest reads the OpRegion register before writing to it and hvmloader noticing if Qemu returns 0 or the number of pages needed for the OpRegion and VBT if hvmloader reads the OpRegion register before writing to it. Another simplification is that the complicated communication protocol with four extra writes to the OpRegion register has been mostly removed and replaced with ontly two writes, with the reason for the second write explained below. - All the code that involves reading the OpRegion, discovering if there is a VBT, how many pages are needed for the OpRegion + VBT, and patching the OpRegion if necessary has been moved from hvmloader to Qemu. - In contrast to v5 and the current implementation, the host OpRegion is never directly exposed to the guest. Instead, an emulated copy, patched if necessary, is exposed to the guest using Qemu's ioreq server. - Because Windows IGD drivers cannot access the OpRegion and VBT when it is exposed to the guest by the ioreq server, a second write to the OpRegion register from hvmloader is processed by Qemu to indicate to Qemu that the OpRegion and VBT must be unmapped from the ioreq server which allows hvmloader to configure the guest to use its own copy of the OpRegion + VBT that is backed by guest RAM. With this configuration in place, both Windows and Linux guests are able to access the OpRegion and VBT and work as expected. Changes in v5: - fix style by adding braces to two if blocks and not initializing two static boolean variables to false - update the link to the companion patch for Xen hvmloader Changes in v4: - v4 is the first version of the series that has this patch hw/xen/xen_pt_graphics.c | 266 +++++++++++++++++++++++++++++++++++++-- include/hw/xen/xen_igd.h | 2 +- 2 files changed, 257 insertions(+), 11 deletions(-) diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c index be71989..7136669 100644 --- a/hw/xen/xen_pt_graphics.c +++ b/hw/xen/xen_pt_graphics.c @@ -4,13 +4,27 @@ #include "qemu/osdep.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qemu/datadir.h" #include "hw/xen/xen_pt.h" #include "hw/xen/xen_igd.h" +#include "hw/xen/xen-hvm-common.h" #include "xen-host-pci-device.h" #include "system/physmem.h" static unsigned long igd_guest_opregion; static unsigned long igd_host_opregion; +static uint8_t *opregion_vbt; /* pointer to OpRegion + VBT */ +/* + * If there is an extended VBT or if the OpRegion is not aligned on a page + * boundary, we will need extra pages for the OpRegion + VBT. + */ +static unsigned int extra_opregion_pages; +static unsigned long opregion_vbt_pages; /* # of pages for OpRegion + VBT */ +static uint16_t version; /* OpRegion version */ +static uint32_t rvds; /* VBT size */ +static unsigned long rvda_host; /* VBT address in host */ +static bool opregion_is_direct_mapped; +MemoryRegion mr_opregion; typedef struct VGARegion { int type; /* Memory or port I/O */ @@ -115,12 +129,11 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev) } } - if (igd_guest_opregion) { + if (opregion_is_direct_mapped && igd_guest_opregion) { ret = xc_domain_memory_mapping(xen_xc, xen_domid, (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT), (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), - 3, - DPCI_REMOVE_MAPPING); + opregion_vbt_pages, DPCI_REMOVE_MAPPING); if (ret) { return ret; } @@ -237,8 +250,158 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev, uint32_t igd_read_opregion(XenPCIPassthroughState *s) { + char opregion_file[64], vbt_file[64]; + FILE *fp = NULL; + struct stat st; + uint8_t *opregion = NULL, *vbt = NULL; + void *ptr = NULL; uint32_t val = 0; + if (!igd_host_opregion) { + /* We just work with LE. */ + xen_host_pci_get_block(&s->real_device, XEN_PCI_IGD_OPREGION, + (uint8_t *)&igd_host_opregion, 4); + + g_autofree const char *fname1 = g_strdup("intel-opregion"); + g_autofree const char *path1 = qemu_find_file(QEMU_FILE_TYPE_BIOS, + fname1); + /* + * If getting the OpRegion or VBT from the host filesystem fails, + * fallback to direct mapping of the host OpRegion to the guest. + */ + if (!path1) { + XEN_PT_WARN(&s->dev, "OpRegion host file \"%s\" not found\n", + fname1); + goto fallback; + } + snprintf(opregion_file, sizeof(opregion_file), "%s", path1); + fp = fopen(opregion_file, "r"); + if (fp == NULL) { + if (errno != ENOENT) { + XEN_PT_WARN(&s->dev, "Cannot open %s: %s\n", + opregion_file, strerror(errno)); + } + goto fallback; + } + if (fstat(fileno(fp), &st) == -1) { + XEN_PT_WARN(&s->dev, "Cannot stat %s: %s\n", + opregion_file, strerror(errno)); + goto fallback; + } + if (st.st_size != XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT) { + XEN_PT_WARN(&s->dev, "Invalid OpRegion size (%u)\n", st.st_size); + goto fallback; + } + opregion = g_new0(uint8_t, st.st_size); + ptr = (void *)opregion; + if (fread(ptr, 1, st.st_size, fp) != st.st_size) { + XEN_PT_WARN(&s->dev, "Can't read host OpRegion %s\n", + opregion_file); + goto fallback; + } + if (memcmp(ptr, XEN_PCI_IGD_OPREGION_SIGNATURE, 16)) { + XEN_PT_WARN(&s->dev, "Invalid OpRegion signature\n"); + goto fallback; + } + fclose(fp); + + version = *(uint16_t *)(opregion + + XEN_PCI_IGD_OPREGION_VERSION); + XEN_PT_LOG(&s->dev, "OpRegion version: 0x%x\n", version); + if (version >= 0x0200) { + rvda_host = *(unsigned long *)(opregion + + XEN_PCI_IGD_OPREGION_RVDA); + /* It is convenient to make rvda_host absolute */ + if (version > 0x0200) { + rvda_host += igd_host_opregion; + } + XEN_PT_LOG(&s->dev, "host VBT address: 0x%lx\n", rvda_host); + rvds = *(uint32_t *)(opregion + + XEN_PCI_IGD_OPREGION_RVDS); + XEN_PT_LOG(&s->dev, "VBT size: 0x%x\n", rvds); + } + + if (rvds && rvda_host) { + g_autofree const char *fname2 = g_strdup("intel-vbt"); + g_autofree const char *path2 = qemu_find_file(QEMU_FILE_TYPE_BIOS, + fname2); + if (!path2) { + XEN_PT_WARN(&s->dev, "VBT host file \"%s\" not found\n", + fname2); + goto fallback; + } + snprintf(vbt_file, sizeof(vbt_file), "%s", path2); + fp = fopen(vbt_file, "r"); + if (fp == NULL) { + if (errno != ENOENT) { + XEN_PT_WARN(&s->dev, "Cannot open %s: %s\n", + vbt_file, strerror(errno)); + } + goto fallback; + } + if (fstat(fileno(fp), &st) == -1) { + XEN_PT_WARN(&s->dev, "Cannot stat %s: %s\n", + vbt_file, strerror(errno)); + goto fallback; + } + if (st.st_size != rvds) { + XEN_PT_WARN(&s->dev, "Invalid VBT size (%u)\n", st.st_size); + goto fallback; + } + vbt = g_new0(uint8_t, st.st_size); + ptr = (void *)vbt; + if (fread(ptr, 1, st.st_size, fp) != st.st_size) { + XEN_PT_WARN(&s->dev, "Can't read host VBT %s\n", + vbt_file); + goto fallback; + } + if (memcmp(ptr, XEN_PCI_IGD_VBT_SIGNATURE, 4)) { + XEN_PT_WARN(&s->dev, "Invalid VBT signature\n"); + goto fallback; + } + fclose(fp); + extra_opregion_pages = rvds >> XC_PAGE_SHIFT; + if (rvds & XEN_PCI_IGD_OPREGION_MASK) { + extra_opregion_pages++; + } + if (((igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK) + + (rvds & XEN_PCI_IGD_OPREGION_MASK)) > + (1 << XC_PAGE_SHIFT)) { + extra_opregion_pages++; + } + } else { + rvda_host = 0; + rvds = 0; + if (igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK) { + extra_opregion_pages = 1; + } + } + + opregion_vbt_pages = XEN_PCI_IGD_OPREGION_PAGES + + extra_opregion_pages; + opregion_vbt = g_new0(uint8_t, + opregion_vbt_pages << XC_PAGE_SHIFT); + ptr = (void *)(opregion_vbt + + (igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK)); + memcpy(ptr, (void *)opregion, + XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT); + if (rvds) { + ptr += (XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT); + memcpy(ptr, (void *)vbt, rvds); + } + g_free(opregion); + g_free(vbt); + /* + * By returning the size of the OpRegion + VBT here instead of 0, we + * indicate to hvmloader that we support an extended VBT and we give + * hvmloader the information it needs to place the OpRegion + VBT in + * the E820 map. Also, in this case the guest read the OpRegion + * register before writing to it, which means the guest supports + * an extended VBT. + */ + return opregion_vbt_pages; + } + if (!igd_guest_opregion) { return val; } @@ -247,11 +410,38 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s) XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val); return val; + +fallback: + XEN_PT_LOG(&s->dev, "Fallback to host OpRegion mapping\n"); + opregion_is_direct_mapped = true; + if (fp) { + fclose(fp); + } + g_free(opregion); + g_free(vbt); + return val; } void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val) { int ret; + static bool opregion_is_ioreq_mapped; + static unsigned long igd_guest_opregion_pgbase; + + if (opregion_is_ioreq_mapped && (val == igd_guest_opregion)) { + /* + * To support Windows IGD drivers that don't work with the OpRegion + * and VBT when they are mapped to an ioreq server, hvmloader writes + * the value of igd_guest_opregion a second time to signal it is time + * to unmap the OpRegion from the ioreq server. Hvmloader has made + * a copy of the OpRegion and will configure the guest to use its + * copy. In this way, the Windows IGD drivers work as expected. + */ + memory_region_del_subregion(get_system_memory(), &mr_opregion); + object_unparent(OBJECT(&mr_opregion)); + opregion_is_ioreq_mapped = false; + XEN_PT_LOG(&s->dev, "Successfully configured emulated OpRegion\n"); + } if (igd_guest_opregion) { XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n", @@ -259,16 +449,73 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val) return; } - /* We just work with LE. */ - xen_host_pci_get_block(&s->real_device, XEN_PCI_IGD_OPREGION, - (uint8_t *)&igd_host_opregion, 4); + if (!igd_host_opregion) { + /* We just work with LE. */ + xen_host_pci_get_block(&s->real_device, XEN_PCI_IGD_OPREGION, + (uint8_t *)&igd_host_opregion, 4); + opregion_is_direct_mapped = true; + } igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_IGD_OPREGION_MASK) | (igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK); + igd_guest_opregion_pgbase = igd_guest_opregion & + ~XEN_PCI_IGD_OPREGION_MASK; + + if (opregion_is_direct_mapped) { + XEN_PT_LOG(&s->dev, "hvmloader lacks extended VBT support, " + "continuing with legacy support only\n"); + /* + * In this case we need to direct map the OpRegion because either we + * failed to get a copy of the OpRegion from the host filesystem or + * the guest does not support an extended VBT. In this case we also + * assume we need an extra page because the OpRegion is not always + * aligned on a page boundary. + */ + extra_opregion_pages = 1; + opregion_vbt_pages = XEN_PCI_IGD_OPREGION_PAGES + + extra_opregion_pages; + goto map; + } else { + Object *owner = OBJECT(&s->dev); + unsigned long rvda_guest = 0; /* VBT address in guest */ + + /* Compute rvda value for the guest */ + if (rvds && (version > 0x0200)) { + if (version == 0x0200) { + rvda_guest = igd_guest_opregion + + (XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT); + } else { + /* Convert to relative address */ + rvda_guest = XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT; + rvda_host -= igd_host_opregion; + } + } + + /* Patch the OpRegion with the correct rvda value for the guest */ + if (rvds && (rvda_guest != rvda_host)) { + *(unsigned long *)(opregion_vbt + (igd_guest_opregion & + XEN_PCI_IGD_OPREGION_MASK) + + XEN_PCI_IGD_OPREGION_RVDA) = rvda_guest; + XEN_PT_LOG(&s->dev, "Patched OpRegion with guest rvda = 0x%lx\n", + rvda_guest); + } + + /* Configure ioreq server for the emulated OpRegion */ + memory_region_init_ram(&mr_opregion, owner, "xen.intel.opregion", + opregion_vbt_pages << XC_PAGE_SHIFT, + &error_fatal); + memory_region_add_subregion(get_system_memory(), + igd_guest_opregion_pgbase, &mr_opregion); + void *ptr = memory_region_get_ram_ptr(&mr_opregion); + memcpy(ptr, (void *)opregion_vbt, opregion_vbt_pages << XC_PAGE_SHIFT); + g_free(opregion_vbt); + opregion_is_ioreq_mapped = true; + return; + } +map: ret = xc_domain_iomem_permission(xen_xc, xen_domid, (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), - XEN_PCI_IGD_OPREGION_PAGES, - XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED); + opregion_vbt_pages, XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED); if (ret) { XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:" @@ -281,8 +528,7 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val) ret = xc_domain_memory_mapping(xen_xc, xen_domid, (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT), (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), - XEN_PCI_IGD_OPREGION_PAGES, - DPCI_ADD_MAPPING); + opregion_vbt_pages, DPCI_ADD_MAPPING); if (ret) { XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to" diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h index 469171c..e66b3a3 100644 --- a/include/hw/xen/xen_igd.h +++ b/include/hw/xen/xen_igd.h @@ -13,7 +13,7 @@ #define XEN_PCI_IGD_OPREGION 0xfc #define XEN_PCI_IGD_OPREGION_MASK 0xfff -#define XEN_PCI_IGD_OPREGION_PAGES 0x3 +#define XEN_PCI_IGD_OPREGION_PAGES 0x2 #define XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED 0x1 #define XEN_PCI_IGD_OPREGION_SIGNATURE "IntelGraphicsMem" #define XEN_PCI_IGD_VBT_SIGNATURE "$VBT" -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:25:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:25:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415734.1644996 (Exim 4.92) (envelope-from ) id 1x4vdM-00011g-ML; Fri, 11 Sep 2026 07:25:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415734.1644996; Fri, 11 Sep 2026 07:25:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdM-00011R-IQ; Fri, 11 Sep 2026 07:25:16 +0000 Received: by outflank-mailman (input) for mailman id 1415734; Fri, 11 Sep 2026 07:25:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vdL-0000xE-2e for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:25:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vdK-001KTX-FF for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:25:14 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3acd9-e002-0a2a0a5209dd-0a2a4501afc4-2 for ; Fri, 11 Sep 2026 09:25:13 +0200 Received: from [98.137.68.204] (helo=sonic304-23.consmr.mail.gq1.yahoo.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3acd8-5984-0a2a45010019-628944cc8388-3 for ; Fri, 11 Sep 2026 09:25:13 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:25:11 +0000 Received: by hermes--production-bf1-54b5569bdc-fv65m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4451c0cd4386c4b1051306e68eb9ea1; Fri, 11 Sep 2026 07:25:07 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111511; bh=/3QUpHGBKJbXOgu22YsrlVzjiLJDOg/MMxR0FeGG6pI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=QzLynmg1rRqy0YClCOWLrr8VWVC6sWeJSBGxWL6YF6ByqXU4gz3UFrDSBn7pY7HyldKC8tF24T1ERoXKLQsPTB0RNpWn+TwECHyowTJjRRLU6+Dax1G8FtcEd7Kwbhp2kG5k2icMHwbs2zwanyYHazp5LNqj668XirOZ7gxIn1FWwcm4L4DwDqgUpaw9xs1FlETWVJzvnw/cYCIPxBR4XuNNtHGcFyr2rRtDjxlAltEC7KZcvX79YCbwUzuIgPzymlsBdSOL6pM3yWfjwOdPhP+ywLdwHyl3Cw5Fo6DSYxy7aJg/9vwNB4OcWAgXkS4AYsB8/o/9xAvzqyd6yVNF3A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111511; bh=I/ssSFpkQARF6S3fHwCeJAKASsjOH/PQdGIY+FxDhMt=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=fGeWUDeT/Dl0luu+OzhPIKUY2cctSYE2PH0khHZp3jKrzF2MITJLQd12UiAOwzFE7G7GOLufQaoeYBSJrbKcHdl+MZhHPOfiCpoSrl4UdT+bNVC0vGmV2CVxbjunxe5mR5kXM9BtDOhk3OFZ7PB4ovLbH1TK7Jb7VbZt8FIOJUyJ4fWroJpFHN6CxcYiZpnbH2WkLm0JzSYVJoburY1jkT3FKfOnh72EzDjWLyv6rx+z9n8RX1HyI+GYi8KOj8KXtvb4hHoLzqfhi/XNeOLYYIxgrVZ6etHo1Ek3HYpWZR7Vrcoz9x1dPNae9nxoBQlQLicW6nR7/99j5AktpLLeHA== X-YMail-OSG: 3ceA1NIVM1lx65qhP6Zop48W1CPeK8he9I_xCzv.80GxYfw0Dfz_nsufQwxudhy zTEZi9MkHkbiBFnXI3fOl2tw_GVcCO3uJTOKSEylFd8XGL8fXmyvJSvcknA.kvy_sm6Ghfvj54Nx zpo68YIzYaSwxcxPpLxai4kcgJwHRvspGgdoffPz5fLwSFRB_axL9c2.neIjoDyKgx7GY4praZi0 jG.4ZD0JChGLGYwGAc8Bax3vX79SblGLoDX49wenKNqfOxV8DRNKBRZ7NpxRw_F7MCFAQ30tPhc. OTA.In6HLCUfRve5Rpom5fQjsr6z3ZWnp_E59pIctu8rPn1pAQDWHq.FHeH3jVI7aZl4rc9FObVx yYRoUDRlUza32VlGgHvnzuDh9ATM1DAf5LLbak50OtrAcjSpnWpB1QVu6UF5ikVFHqK03KL5Aur0 Gm79tSZ9Uuai1tDPnCTTDku8f9ehJW6H_5rro0qPZrBg8kPOJwABhEBLlG9Tgjfyc_Bi8v_YWOhN ggBG.NEGjNT3QSpzD4oO2.ztqe4.CRy1j.N7j5gJt8h3bJ06cezAVS.ILZ56iphLih3lXySGGtSe zeHTZYbP4ItkUUavstg_yZ.KJLN318LCouSNb0_BFqnbdgB5I4bAC5nVrbOHm9TKkGyVgkeYEkll pKysm.4dFGwqZvW.t.d07az5iUyw8xHyc99rXCrSM3w0uN4ZScmSNM4e24WFLwWy5ReBTiaPiFgO sWqg799kqxwXIWEC7aBA.aYTNhv._pKXMr1gHDFcWUXF01Ec95JAuHqtN5mYWHf780BHjtbao0ix tXfQlGEani0_XJSO5ifj1O4wvtFgIYgKkiDKTEDB8Qc7N3.3RLRyNoDyNevDvSavVVoP0qLiZNf3 MXQKTTzyII0pW9UwAKvcVFFJRjz8A0TB325ov0czg3DCYh7.sIz9REEFuEXSS5dFJ4rcsVv6irMQ eJwvwDhbIaSMtotqA5I0JlruX6rouxo_PAiYbk.Sldn4GsJCgG2FbbYgBy6bcBRmZAO9yC0lseUX pvPZSBU7GU7e1aUUBGrUu6Y0x_znGTczo5PlhAlVsHz9w_B4jHzspxR8CmJsf_bqrej3Amwa3DMV AKD2apFGZaS8JCH16slc7Awsh9KYiIedQajsWmHkpvl.tuYeg6fNxsHAEn7TifDYlFnHfvNPd4yN DNyQmA85icJjAfETk.Y5uTKqimnfa0cydm4G1OBoZwyuwfIIBFUKM.OiJCAF0cfsYVEcH6aya0Am .advDQbWEI41RYP8LFCUw0.pTcFJpd4oczm5qc_HqFBb7PdsDjB3D1bbew4I2kDLy0zyJbi1SHaw Bp8MPNUT08HYGW.r4zWSUIzon.2xjnlCEsBkOTiGsH6D_oVLvbFiu4a9J0GX5uSb4mpid.LDLexs 9r9AOvB3F5C.7RHpGmlfXqNo4KcAlY14wsYA1Oc2gjWWM1k8fk6jt3012uulM.Wlt7iQOEsRvQvu ffEPxHGt5peIDve_Ngn4XPJ22AgUaBSFSiDvaHHcdNW_Ls_Epfx9dJP22RzGAtKTjO289hNWWfSj jXATt5Zx9VWnnPkpBzOEsuB1ThkySY4DLfofOh9pDBNMlxQCBelddd5AJwfPV1D.ogUEauarhvbz ZUr0R_QjX6EAoEaJ9o5mZJsP4j7WglWvxi7byKLJ1_APzEOC7kcamaoShdi.NaM7Y9yDxR6yv7Fi HpFQoa6YU6AjDf7UlCb81gkLLOECXL.VWXcK699HH98uMkdwhIYwHUw04OSRJcuqNS47KwPbDhVA rUcND9SS9YKR9jpzcLRjVdjHfiq8J13rd9BCq0OwoU8kwSpnpp9ZMT5y5EWmikAOq97CBZGSt9jM _FpFF5SXIPZ57U74UZ4PsPAGDaFPZmo5E6eYkscFnf6c0qZ4cOwpsypR3WYbWbQzsnnkPCawjNwc ckZC6Qhv_k3L5o9v8hW6I_mKOLcGqE94o3w9pFsH1R04OrbYhL2E4nZvTyxzvh6SOS7SWTpyR9Lb e_fd36IK.ICTB8XxPRhZI_aO3klCqffAbmvw1MtspGD7HPAURRTdIC1Ymrzig8FFZqlQeysiUex6 NAO17PvGdsPm9ZdDw_N5x33.ay63SipsSCmt7kQ4btMb83HnggaR.1yd31vjKmKOXNfAIj_yPvwf M5VPQ19qF8fqwJrOiFKAZhzj.OAlUYU86.ndcP5QYkIL2yUpbww1D2T8EunkDkBCLUe6ClOjioYa s4UnnCDsC2GNsHdAneIkjmFSNYFTxP.Z6PEx4aA-- X-Sonic-MF: X-Sonic-ID: 325b1927-76c2-4939-b9b7-27b409399d56 From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko Subject: [PATCH v6 7/7] xen/igd: use custom option ROM if provided Date: Fri, 11 Sep 2026 03:24:53 -0400 Message-ID: <20260911072453.46256-8-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260911072453.46256-1-brchuckz@aol.com> References: <20260911072453.46256-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 9058 X-purgate-ID: tlsNG-d62444/1789111513-1E465757-8660A9D4/0/0 X-purgate-type: clean X-purgate-size: 9276 Since in some cases the option ROM is not readable from sysfs on the host, provide the option to use a custom option ROM file instead that, for example, could be extracted from BIOS or UEFI firmware and modified as needed for use with a particular Intel IGD device. The file must be named "igd.rom" and be located in a directory configured at build time as a Qemu firmware directory and its size should be a power of two, and it must be compatible with the particular Intel IGD device being passed through. If provided, the "igd.rom" file will be used as the option ROM instead of the option ROM file epxosed in the host sysfs. If no "igd.rom" file is provided, this patch has no effect. Signed-off-by: Chuck Zmudzinski --- Changes in v6: - Added a link to Tomita's edk2 patches for the OvmfX64 platform for KVM/VFIO guests in this additional notes section Changes in v5: - Fix wrong whitespace in three places in a conditional block Changes in v4: - v4 is the first version of the series that has this patch Sorry for the length of these notes but there are many things to say about this patch that are not obvious to persons without some experience of actually trying to use the option ROM of an Intel IGD when it is passed through to a Xen HVM guest. This patch is primarily for providing a way to add Intel IGD support for the OvmfXen platform to get graphics output during early boot from modern Intel IGD devices that are only compatible with UEFI for graphics output during early boot. Note this patch is not necessary for successful operation of the Intel IGD in the guest once the guest OS drivers have loaded. It is only needed as part of the patchset necessary to provide graphics output from the Intel IGD in the guest during early boot when using newer devices that are only compatible with UEFI for graphics output during early boot. Most older devices that are compatible with legacy VGA BIOS will work with Seabios without this patch, but they will need Patch 3 of this patchset to work with Seabios. Some notes on adding Intel IGD support for the OvmfXen platform: It is necessary to provide an EFI graphics output protocol (GOP) driver to the guest to get output from the Intel IGD before the guest OS loads the graphics drivers when the guest uses UEFI. This GOP driver is essentially the replacement of the VBIOS driver that applied to older devices that use legacy bios, as described here: https://www.intel.com/content/www/us/en/support/articles/000005749/graphics.html Unfortunately, with modern Intel IGD devices, the EFI GOP driver is not provided to the guest in the usual way of providing firmware for a PCI device in the option ROM of the real PCI device. So I included this patch in this patchset to provide a way to expose the EFI GOP driver to the guest. I was able to extract the GOP driver for my device using the UEFI bios update file from the motherboard manufacturer and the UEFITool available here: https://github.com/longsoft/uefitool That EFI driver can be wrapped into an option ROM using the EfiRom bin wrapper that is part of the edk2 project: https://github.com/tianocore/edk2/blob/master/BaseTools/BinWrappers/PosixLike/EfiRom I tried setting the 'romfile' member of the PCIDevice struct that is used by KVM/VFIO Qemu devices and emulated Qemu PCI devices, but that did not work with Xen PCI passthrough devices. Neither Seabios nor the OvmfXen platform could detect the option ROM in the guest with that method of exposing an option ROM to the guest. So I implemented this approach of substituting the 'rom' file exposed by sysfs with an administrator-provided file instead of using 'romfile'. In the commit message I mentioned the size of the rom file "should" be a power of two. I mentioned this because the code in pci.c that handles the 'romfile' setting for PCI devices enforces this requirement strictly on the romfile that Qemu emulated or VFIO devices use. However, I do not know for sure whether or not the rom file is strictly required to have a size of a power of two, so that is why I say it should be a power of two. In my testing, I zero pad the "igd.rom" file so it has a size of a power of two. I will accept the suggestions of experts on this question about the appropriate size of the option ROM file (I am not such an expert!). As mentioned in the message accompanying Patch 4 of this patchset, the official edk2 project does not provide support for the Intel IGD, but some OVMF patches for Intel IGD support are available online for KVM/VFIO guests, such as at the links below (they apply to the OvmfPkgX64 platform): https://github.com/tomitamoeko/VfioIgdPkg https://github.com/cmd2001/build-edk2-gvtd https://eci.intel.com/docs/3.3/components/kvm-hypervisor.html#build-ovmf-fd-for-kvm https://github.com/LongQT-sea/intel-igpu-passthru With such patches it is reported that the passed through Intel IGD device lights up the display during early boot from OVMF and the guest bootloader in KVM/VFIO guests provided that the administrator provides the correct ROM file via the 'romfile' setting for the passed thorugh Intel iGD device and applies appropriate patches to the OvmfPkgX64 platform. It should also be possible to add Intel IGD support for the OvmfXen platform also but I have not seen any such patches online for OvmfXen and if anyone knows of such patches online I would be interested to be informed about them. I am also working on my own patches to add Intel IGD support to the OvmfXen platform, in private for now. If anyone is interested, I can make the work I have done so far toward this goal avalable online. hw/xen/xen_pt_load_rom.c | 47 +++++++++++++++++++++++++++------------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c index f136f13..ab448f4 100644 --- a/hw/xen/xen_pt_load_rom.c +++ b/hw/xen/xen_pt_load_rom.c @@ -2,6 +2,7 @@ * This is splited from hw/i386/kvm/pci-assign.c */ #include "qemu/osdep.h" +#include "qemu/datadir.h" #include "qapi/error.h" #include "qemu/error-report.h" #include "hw/pci/pci.h" @@ -13,9 +14,9 @@ * need to be modified. * * For such cases, use this function to get a pointer to the option ROM - * from sysfs. Caller has the responsibility to edit the option ROM as - * needed, call pci_register_bar to register the modified option ROM, - * and set has_rom to true for the PCI device. + * from a user provided romfile or sysfs. Caller has the responsibility + * to edit the option ROM as needed, call pci_register_bar to register + * the modified option ROM, and set has_rom to true for the PCI device. * * This function must be called before xen_pt_register_regions is called * because if xen_pt_register_regions is called first, it will register @@ -32,17 +33,27 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev, struct stat st; void *ptr = NULL; Object *owner = OBJECT(dev); + g_autofree const char *fname = g_strdup("igd.rom"); + g_autofree const char *path = qemu_find_file(QEMU_FILE_TYPE_BIOS, fname); + bool sysfs = false; /* If loading ROM from file, pci handles it */ if (dev->romfile || !dev->rom_bar) { return NULL; } - snprintf(rom_file, sizeof(rom_file), - "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom", - domain, bus, slot, function); + if (path) { + snprintf(rom_file, sizeof(rom_file), "%s", path); + XEN_PT_LOG(dev, "Using Intel IGD romfile %s " + "(administratior provided)\n", path); + } else { + snprintf(rom_file, sizeof(rom_file), + "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom", + domain, bus, slot, function); + sysfs = true; + XEN_PT_LOG(dev, "Using Intel IGD romfile from host sysfs\n"); + } - /* Write "1" to the ROM file to enable it */ fp = fopen(rom_file, "r+"); if (fp == NULL) { if (errno != ENOENT) { @@ -55,10 +66,14 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev, goto close_rom; } - val = 1; - if (fwrite(&val, 1, 1, fp) != 1) { - goto close_rom; + /* Write "1" to the ROM file to enable it if using ROM from sysfs */ + if (sysfs) { + val = 1; + if (fwrite(&val, 1, 1, fp) != 1) { + goto close_rom; + } } + fseek(fp, 0, SEEK_SET); if (dev->romsize != UINT_MAX) { @@ -83,11 +98,13 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev, *size = st.st_size; close_rom: - /* Write "0" to disable ROM */ - fseek(fp, 0, SEEK_SET); - val = 0; - if (!fwrite(&val, 1, 1, fp)) { - XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file"); + /* Write "0" to disable ROM if using ROM from sysfs */ + if (sysfs) { + fseek(fp, 0, SEEK_SET); + val = 0; + if (!fwrite(&val, 1, 1, fp)) { + XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file"); + } } fclose(fp); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:26:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:26:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415785.1645010 (Exim 4.92) (envelope-from ) id 1x4veS-00039H-AC; Fri, 11 Sep 2026 07:26:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415785.1645010; Fri, 11 Sep 2026 07:26:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veS-00038Y-5c; Fri, 11 Sep 2026 07:26:24 +0000 Received: by outflank-mailman (input) for mailman id 1415785; Fri, 11 Sep 2026 07:26:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veR-00036R-Bu for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:26:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4veQ-001KmU-OT for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:26:22 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ad17-e002-0a2a0a5209dd-0a2a4507c276-18 for ; Fri, 11 Sep 2026 09:26:22 +0200 Received: from [52.101.70.117] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ad1d-b4ea-0a2a45070019-3465467530e0-4 for ; Fri, 11 Sep 2026 09:26:22 +0200 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com (2603:10a6:10:519::5) by AM9PR03MB8025.eurprd03.prod.outlook.com (2603:10a6:20b:43c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:26:19 +0000 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908]) by DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908%5]) with mapi id 15.21.0406.005; Fri, 11 Sep 2026 07:26:19 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bBmQ21jLCf/DpXM2oB6kcbHiUvPgWsNVBQ2AbqGmbVVxGejC7x2yPcyi0ghuQ9lcZ7uiIyWy7LjNBHBg9L2tb6oVYPAccOyRy4ju/MzwHDeQJr6qII4fhi5jIye7P5wToflbBOO4i4rcuGycovT4Z3aB83414ys91Gq4BRCRorT3P51An7sYmur5QwyHSTUrAQBwIQv9nbcBpxXVaON7Xpb+yUiBt05drvzxqKMA8gSOFfpntARWpA4KYrv5OH2nNXbfJzZshlHQ98+DVRgSIgtzc9ywyN2UiCH12Y0On6FUEoi1WdOSAMmBcd4wLYRr2hyZO1F+bTwMArqrn4wO7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=K6AYq5Kll7/pmeAk+oKFa/9HXzJt+FvI3a2zs9jNnio=; b=bUsMUyiNAYjTKzblFP8OP2Wl2ojXh136kxkW9PVW4gSkpoyQWQ8L6+XZhApId3wy76JaBeMNpQtaNT+WL2Wv8FxVxte6P3Ofoi51vd1jxqMNs5Tcb46DePgpUK84ri/uK92CO5XLpN/oUZVzQ2ym2w05PHH9WOPNmNPc6IQ4jh3uAHG+l8USAxzQ2PDh6Z2Ve7sCio0ikMly0T4Qxp3oJ8j4ZrIaLtcCBU5oQyY00G/Zr4CTOEIO6YJ0S7kXAk4Ok1Esn6ftBG6K7mMNVNvbpfQLcN9HzotwpL5cjPCRJR64jctRkJz3zCmhwKk7JJQOHN8CXLi2VEkvpbyFUlkhTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K6AYq5Kll7/pmeAk+oKFa/9HXzJt+FvI3a2zs9jNnio=; b=rzZPSiHwxUNDdEYOEJVfS81fS9rjaesj6g0L2nG/LqdRq8LpDuJO16vwqJG6dL1fM+cvmCmzKviBZQVWO7UpEMbPFfvbiNytCSRH+N0eEhxFRhFdCLYCJ5cLJLRgDE6lVk6aMqaMmy7BdTC/QHl2Ak05XVO8b7p4T655zo36/3i8qwq5LN9Rfu1bKg/up/4LKhm21++tMmA9g+6skrW+YKNNbhcOP0qQt4fIvRUB5y3ZnxCDoKaSRZiMdlQMwTPPgS2VO5nUn3FmUL2qbjc5BFMODTafwgGDRh+l1Tq2IhWiWXT+8g4yB8aKn/0pDO7tu3JMh3l9EsKYfkmUWgFMmQ== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v12 0/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Topic: [PATCH v12 0/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Index: AQHdQb7WLI+RQMznDkeSV1kLY3+yqw== Date: Fri, 11 Sep 2026 07:26:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR03MB10263:EE_|AM9PR03MB8025:EE_ x-ms-office365-filtering-correlation-id: c39b30b7-04f9-4583-6ee1-08df0fd5f913 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|10067099003|6133799003|18002099003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: mGF2w88AQD2tXA5gSmKtVtg2N3qWlhs7l6bptj2Y9jL/hcTXOzIqYcR+Qfs5hzo5dxdA8b5ZeSxUd2jPa/m86Wt6S0NfBiuctmKB7HONZKZOR79dg/fEUohoJTDuaqbyJsRuR/GywMGW8oIuQ5iqDhKYTxyOc13IiuOTLLL8C0x2SWYKYY2KBUih1pBUvUbriA9Li2roh+VOTreBkzO0HNnZlPD78wKyvfWEd1VNRRKCHlx+Mb9sfdSFRtUt+lUlWq6YZRjnethlBUUopU+gTLzGvxNoR6NXr15X6tv8ewauQti1849FymfhDercSyUvGMDRUc2jyCDejqK7wueGHYImPncFvnPf8vruL0Jw1WhOibzsGI3DffHEU2lHyWqMlFL+HpD+8g7RsqvzMp7T16dBpEijgfhiwWxT7IoSLVeZzTOtfThd0F/PUvz/DYAXlTTb6mQrX+Sa7Ny5UmOKmYVwXZoPqpWTK7Uf+oF6LwAs1VZZsg7w1VQwiqZITSU4J0eeg8kpv4H0CtKlkCX9vF4woxw2GAR6yaSBQwaLii5J4pkpPrO+XjqS1lTquByXgtLgFnx++yBzBDVNhtZDgTZuxP4ZI8ArWgkrVmkxhoXBOxpYL8LKjj282Sq6gpUxAcjAuYJGHdafL5wnEfZjJkSDAxczo77KGY0CTpXCBNYcyr+6rPS+WWDg7nbyq5ikcwyps684iQTawTanm3xUvLu6o+vPAeQzViDhnqmW5xA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10263.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(10067099003)(6133799003)(18002099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MWtjNmJVQkJCbEoxTUVEeW0xT1l3NEdvQ1JxVjg5TXlGWTJSM281a040Zmc2?= =?utf-8?B?TG10c3JLWEN1dXVVc3dpcUxIVUY1dWtSc2lJQTBVa3BScEFkSmNwemFEaFdI?= =?utf-8?B?NC84V0grWWc4aWhEZjdIV3ExSTI4cVhWN1Z6aVJUS1Zac29zOTVwc29GQURT?= =?utf-8?B?THFTQXdzNmlXcnluakhlSWhpWWZCVUtzdFh0cmVyZG5xdXRHQVZZYTJJTmVU?= =?utf-8?B?a1RRTWsvSGxaMTBKNFkzbVB1eTk4YWFITWVNVFBYenF2T3F2Zk96QWlWWExR?= =?utf-8?B?ZUlFQkVKWVphR2xheXF0Z3BvYWhSZlZRWmhZTllKK0QvNEFwZkd2VGxsTTFP?= =?utf-8?B?bHI1dG4wZ3I3MndOWFE4VXR5dmlFUXlwMXBKa2hUK21EWGVXbW03dmdzb3Js?= =?utf-8?B?M0cyWGNsNHMxQnFkWldrZnE5NzI1bXQ0QWxMWWJpV3djRkZpeUplVkErNit5?= =?utf-8?B?Y2U0d1ROSkZXczE4aHJOc215VzNIYzFWaHhUbmxPMnY4Ymx5a0ZLRGh1WU55?= =?utf-8?B?SVFNMy8rUWJtWWZEdy9iK2pBNWhVU1diNHR5YnR4dXVMMnFMVkMyV3VKdHF4?= =?utf-8?B?VmVMR0FGeHpZU2JtRXIvTEJSSmR0WXZQcWdsWFpQb0NGUjIzbFo0YllGd0R2?= =?utf-8?B?ZXNjdzBGOEpJQUU0d1BxellxVHYvZEdCcXZWbDY1dEsxWUNtM1hTV2Y2WktS?= =?utf-8?B?RVdVcWRKUzkvWEZBWEJjYkZiWXJ2V04wY3lkbUNYVmFDZzVKMkR1MFNWdE00?= =?utf-8?B?aWNnLzNHWVNsaU5Gb01zYndIN21qWUMzSy9GUlo3SnpKbkRRVm1UMERZb28w?= =?utf-8?B?clFMallKZ2lKc24xWHV1OWdBRWIyVldTNjl6bHIxWFkvVXNmNGJmY3UzMW5T?= =?utf-8?B?UG15M2xZQTgwUHBxcTZ2RjV2OFFVUzJwWWZqaXA5eFlid3psNXFZWkN6Unky?= =?utf-8?B?WHN4T2RyMEZ3MWUrejdxTGltalowSzhKV2FyaVd5QlkzRmgwaU9XeVJFVThv?= =?utf-8?B?MS9OY01lRXNFbDlRZk5YMGR3MEhVOS9PMlY1YzV0Q3I4YVgzYnhNNjhjNE1M?= =?utf-8?B?WTdWTWE5NFlNZVpuMzBjSUFSRGJEVGYwc1Q1TDIwL2c0eDJuV1d3ZGNMSk0v?= =?utf-8?B?dk5US1hkeW1RallYbFdGRzVPWGhmWHFsS04zaEN0aUhEOEVwUWY2SzFwUjIr?= =?utf-8?B?bWRDdXJaOW91Yzl2VEt2UWxSQnVWWExDUGhRR3o0RTlYTGpYc280Y3IrNHpj?= =?utf-8?B?aTVQbkdKbTF2TEFwRm9tUTJjR2NtL0NjMi9Fd3J1N0NFbDRBV3Vob2ZSZEhm?= =?utf-8?B?S1h6aVBoUWEvRG1zOUtRa2hKd1VTNVRRVXNWQXNNbUxGSjJIRzExVXBOb2hT?= =?utf-8?B?RmVMVU5QaEVuNjRaNXFZbWJqeFB5NUZ1eVdQQXpPV1VYNFJlUVpiOE5SZW94?= =?utf-8?B?a3RiRlF0aS9SaGZORjNLZEJISGN5QnpOMGlIVUZQVnp2MmV2T0xacEZCbUts?= =?utf-8?B?V2lQQnRLZVQ2dERZUTkzcW9uR0laZDlIb1FzOTZRS2VweTBncUJEMEFYaG9D?= =?utf-8?B?alNQU2tIUjFTQ282ZTFhL29mMFUrK3JHV2NTY3Q5bGFtZlhtWWdkWGZPTERt?= =?utf-8?B?TnEyNXM0L2UyaUpWcEpvbTFhWEJUR2JHWHZWd29LcS9iQXBtZHRiY0VpeUlv?= =?utf-8?B?aHlaTU5KMGM2YWROdEtYZWFMeTB5a1gxYU5ub3VNZG1ZREUzS2lrMGVGbGta?= =?utf-8?B?YVNKUFpHWnVTZE1FQzdsOXAxOCtCRzI3ZlpPc3kwTmFWSDhwWE5LelFkYlcz?= =?utf-8?B?c0g1TjFHdG9pcldlTWVKOFVPVXpIUTRTWmlRY0dBWEV0bStHMWFZbHhERDFq?= =?utf-8?B?aVdWc2pYMFlzNDFmanUwK0NMTC85YlppN01IZWh3clJJUFRmN3hnZm5jYmJi?= =?utf-8?B?UlphWUVLVXFaVGRCYy9vdzJGek9kaUR4MjNrU0VZdXRzMnNrZ09CQTIrMkda?= =?utf-8?B?WHVuTmFJandjdEpGZG9TMUFxK2tMTGRadHpHdGNzdkVzNVVSdm83NTJ1aDYz?= =?utf-8?B?Z0NsRHB0eEREWGhJWVh1Um82SUVXSWRzaXhDUjk4emRTOHZDOTI4SXhUVUpt?= =?utf-8?B?N0EvelRnSUlKYWlGb21rMEpwUW13Y0FWazFwR2pNMGp5cHJUQkxXQ3pISnhX?= =?utf-8?B?eXErWEI1d3Z0bHFWSUc4WDRVaE1RbCt0T1B4SWhFcm1lWWg2R0lhQW5OeTZL?= =?utf-8?B?VjNSbTJUTlMyQXlLTG9jQlluamsrQzVnaUNxZjg4Z0wxbi9xcWM3Z0tUWUFo?= =?utf-8?B?M3lRMG11SXEycjV2ZDBSaGh0Q0dnb3BlUHRtcTMzRFJ4QXk4UlFxSFYyU0NJ?= =?utf-8?Q?GjhkDc2wqUdkO3Ow=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <869D5D69ECB3E44C970821B395C73E2D@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR03MB10263.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c39b30b7-04f9-4583-6ee1-08df0fd5f913 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 07:26:19.0758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FhkK+Icbb7//2WWFeOrY6AiEx2Kb3cS1ZoYYcNF1WyuDpXLq3OjYC2GR+ptB4KCvRUwMVtvdErqz35R9UFYBR1fGiHAY+1SEe0I/1DoVuVM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB8025 X-purgate-ID: tlsNG-ef75cf/1789111582-356C2AE4-D8AC3BE1/0/0 X-purgate-type: clean X-purgate-size: 23688 SW5yb2R1Y2luZyBwYXRjaCBzZXJpZXMgd2hpY2ggaW5jbHVkZXMgaW1wbGVtZW50YXRpb24gb2Yg dGhlIFNDSSBTQ01JDQpTTUMgbXVsdGktYWdlbnQgc3VwcG9ydC4NClRoaXMgcGF0Y2ggc2VyaWVz IGZvbGxvd3MgUkZDIHY1IFszXSBzZXJpZXMgd2hpY2ggd2FzIGludHJvZHVjaW5nIGJvdGgNClND TUkgc2luZ2xlLWFnZW50IGFuZCBtdWx0aS1hZ2VudCBzdXBwb3J0LiBBZnRlciB0aGUgZGlzY3Vz c2lvbiBpdCB3YXMNCmRlY2lkZWQgdG8gc3BsaXQgZmVhdHVyZXMgYW5kIHVwc3RyZWFtIHNpbmdl LWFnZW50IHN1cHBvcnQgZmlyc3QuIFRoaXMNCmZlYXR1cmUgaXMgbWVyZ2VkIGZvciBub3cgdG8g djQuMjEtcmMyLg0KSSdtIHN0YXJ0aW5nIHRoaXMgcGF0Y2ggc2VyaWVzIGZyb20gdjYgdG8gc2F2 ZSB0aGUgZGlzY3Vzc2lvbiBoaXN0b3J5DQphbmQgZG9uJ3QgYnJlYWsgY2hhbmdlcyBsb2cuDQoN ClBhdGNoIC0geGVuL2RvbWN0bDogZXh0ZW5kIFhFTl9ET01DVExfYXNzaWduX2RldmljZSB0byBo YW5kbGUgbm90DQpvbmx5IGlvbW11DQotIGFkZCBjaGFpbmdlZCBoYW5kbGluZyBvZiBhc3NpZ25l ZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQNCmFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkg dGhyb3VnaCBTQ0kgZnJhbWV3b3JrLg0KQ2hhbmdlIHdhcyBkb25lIGluIHR3byBwYXJ0czoNCiAt IGNhbGwgdG8gc2NpX2RvX2RvbWN0bCgpIHRvIGRvX2RvbWN0bCgpDQogLSB1cGRhdGUgaW9tbXVf ZG9fZHRfZG9tY3RsKCkgdG8gY2hlY2sgZm9yIGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKQ0KIGFu ZCBub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVQ0KDQpQYXRj aCAtIHhlbi9hcm06IHNjbWk6IGludHJvZHVjZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJp dmVyDQotIGFkZCBYZW4tc3BlY2lmaWMgU0NNSSBjb250YWluZXIgY29tcGF0aWJsZSBgeGVuLHNj aWANCiAgdW5kZXIgYC9jaG9zZW4veGVuYDsgWGVuIGJpbmRzIG9ubHkgdG8gdGhlIGBhcm0sc2Nt aS1zbWNgIGluc2lkZSBpdCBhbmQNCiAgaWdub3JlcyBvdGhlciBTQ01JIG5vZGVzIChlLmcuIHVu ZGVyIGAvZmlybXdhcmVgKS4NCi0gYWRkIGBzY21pLXNlY29uZGFyeS1hZ2VudHNgIGFuZCBgI3Nj bWktc2Vjb25kYXJ5LWFnZW50cy1jZWxsc2AgdG8gZGVzY3JpYmUNCiAgZnVuY19pZC9zaG1lbS8o b3B0aW9uYWwgYWdlbnRfaWQpIHR1cGxlcyBmb3Igc2Vjb25kYXJ5IGFnZW50cy4NCi0gZWFjaCBn dWVzdCB1c2luZyBTQ01JIHN1cHBsaWVzIGl0cyBhZ2VudF9pZCAoZG9tMCB2aWENCiAgYHhlbSxk b20wLXNjaS1hZ2VudC1pZD1gIHBhcmFtZXRlciBpbiB4ZW4sc2NpIGNvbXBhdGlibGUgbm9kZSwN CiAgdG9vbHN0YWNrIHZpYSBgYXJtX3NjaSA9ICJ0eXBlPXNjbWlfc21jX211bHRpYWdlbnQsYWdl bnRfaWQ9Li4uImAsIGRvbTBsZXNzDQogIHZpYSBgeGVuLHNjaV90eXBlYCArIGB4ZW4sc2NpLWFn ZW50LWlkYCBpbiBgeGVuLGRvbWFpbmApLg0KLSBmYWN0b3Igb3V0IFNDTUkgZ2VuZXJpYyBkZWZp bml0aW9ucyBhbmQgc2htZW0gY29kZS4NCi0gcGFzc3Rocm91Z2ggY29uZmlndXJhdGlvbiBmb3Ig U0NNSSBndWVzdHMgbWlycm9ycyBvdGhlciBIVyBwYXNzdGhyb3VnaC4NCg0KUGF0Y2ggLSBkb2Nz OiBhcm06IGFkZCBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGRvY3MNCi0gZG9jdW1l bnQgdGhlIFhlbiBTQ01JIGNvbnRhaW5lciB1bmRlciBgL2Nob3Nlbi94ZW4veGVuX3NjbWlfY29u ZmlnYCBhbmQgdGhlDQogIG1lZGlhdG9y4oCZcyBiaW5kaW5nIHJ1bGVzOyB1cGRhdGUgZXhhbXBs ZXMgYWNjb3JkaW5nbHkuDQoNCkFsbCBYZW4tc3BlY2lmaWMgU0NNSSBjb25maWd1cmF0aW9uIG5v dyBsaXZlcyB1bmRlciBgL2Nob3Nlbi9gDQp0byBrZWVwIGhvc3QgRFQgY2hhbmdlcyBpc29sYXRl ZCB3aGlsZSBsZWF2aW5nIHRoZSBob3N0IGAvZmlybXdhcmUvc2NtaWANCnVudG91Y2hlZCBmb3Ig RG9tMCBjb25zdW1wdGlvbi4NCg0KQ29kZSBjYW4gYmUgZm91bmQgYXQ6DQpodHRwczovL2dpdGh1 Yi5jb20vb2xla3NpaW1vaXNpZWlldi94ZW4vdHJlZS9zY21pX21hX3Vwc3RydjYNCg0KWzFdIFJG QyB2MjoNCmh0dHA6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wcm9qZWN0L3hlbi1kZXZlbC9jb3Zl ci9jb3Zlci4xNjQ0MzQxNjM1LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NClsyXSBS RkMgdjM6DQpodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QveGVuLWRldmVsL3Bh dGNoLzIwMjUwMzExMTExNjE4LjE4NTA5MjctMS1ncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbQ0K WzNdIFJGQyB2NToNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzUz MTg0NDg3LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NCls0XSBTQ01JIHNpbmdsZS1h Z2VudDoNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzU2OTk1NTk1 LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NClNDTUkgc3BlYzoNCmh0dHBzOi8vZGV2 ZWxvcGVyLmFybS5jb20vZG9jdW1lbnRhdGlvbi9kZW4wMDU2L2UvP2xhbmc9ZW4NCg0KU0NNSSBi aW5kaW5nczoNCmh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVs L2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmlu ZGluZ3MvZmlybXdhcmUvYXJtLHNjbWkueWFtbA0KaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcv cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50 YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9hY2Nlc3MtY29udHJvbGxlcnMvYWNjZXNzLWNvbnRy b2xsZXJzLnlhbWwNCg0KUmVmZXJlbmNlIEVMMyBGVzoNClJQSTU6IGh0dHBzOi8vZ2l0aHViLmNv bS94ZW4tdHJvb3BzL2FybS10cnVzdGVkLWZpcm13YXJlL2NvbW1pdHMvcnBpNV9kZXYvDQpSZW5l c2FzIHY0aDoNCmh0dHBzOi8vZ2l0aHViLmNvbS9HcnlnaXJpaVMvYXJtLXRydXN0ZWQtZmlybXdh cmUvY29tbWl0cy9yY2FyX2dlbjRfdjIuN192NHgtc2NtaV91cGQvDQoNCmJhc2UtY29tbWl0OiBk YmU2MGYyNDRjIChVcGRhdGUgWGVuIHRvIDQuMjEsIDIwMjUtMDItMjEpDQoNCkNoYW5nZXMgaW4g djEyOg0KLSByZWJhc2UgdG8gdGhlIGxhdGVzdCBzdGFnaW5nDQotIGFkZCBSLUJzIGZyb20gU3Rl ZmFubyBhbmQgQWNrIGZyb20gSmFuDQotIGFkZCBtaXNzZWQgQWNrLg0KLSBBZGQgbWlzc2VkIFIt Qg0KLSBjb3JyZWN0IHRoZSBFbWFjcyBmb290ZXIgb2YgYm90aCBmaWxlcywgd2hpY2ggYXNrZWQg Zm9yIDggY29sdW1uDQp0YWIgaW5kZW50YXRpb24gd2hpbGUgdGhlIGNvZGUgaXMgaW4gNCBjb2x1 bW4gWGVuIHN0eWxlDQotIHJlYmFzZSB0byB0aGUgbGF0ZXN0IHN0YWdpbmcNCi0gcmV0dXJuIEVJ TlZBTCBpZiB4ZW4sc2NpX3R5cGU9c2NtaV9zbWNfbXVsdGlhZ2VudCB3YXMgc2V0IGJ1dA0KQ09O RklHX1NDTUlfU01DX01BIG5vdCBzZXQNCi0gcHV0IGFybV9zY2lfYWdlbnRfaWQgYWZ0ZXIgdjhy X2VsMV9tc2EgYW5kIGJlZm9yZSBwYWQgdG8gcHJlc2VydmUNCm9yZGVyLiBSZWR1Y2VkIHBhZCBm cm9tIHVpbnQxNl90IHRvIHVpbnQ4X3QgdG8gZmlsbCB0aGUgZ2FwICh3YXMgMg0KYnl0ZXMgYmVm b3JlIGFkZGluZyBhcm1fc2NpX2FnZW50X2lkIGFuZCBsZWZ0IG9ubHkgMSwgc28gdXNlZCB1aW50 OF90DQp0byBwcmVzZXJ2ZSBzdHJ1Y3R1cmUgc2l6ZSkNCi0gZml4IHNjbWlfaGFuZGxlX2NhbGwg dG8gdXNlIGFybV9zbWNjY19ndWVzdF9zbWMgaGVscGVyIGZ1bmN0aW9uDQotIHVwZGF0ZSBzZW5k X3NtY19tZXNzYWdlIGZ1bmN0aW9uIHRvIHVzZSBuZXcgZm9ybWF0IG9mDQphcm1fc21jY2NfMV8x X3NtYw0KLSBndWFyZCB0aGUgRG9tMCBTQ01JIGFnZW50IGlkIHNldHVwIGluIGNyZWF0ZV9kb20w KCkgYW5kIE1BIHJlbGF0ZWQNCmZ1bmNpdG9ucyB3aXRoIENPTkZJR19TQ01JX1NNQ19NQQ0KLSBm aXggdGhlIHhlbl9zY21pX2NvbmZpZyBleGFtcGxlIGluIGJvb3RpbmcudHh0LCB3aGljaCBwbGFj ZWQgcHJvcGVydGllcw0KYWZ0ZXIgc3Vibm9kZXMgYW5kIHdhcyByZWplY3RlZCBieSBkdGMgd2l0 aCAiUHJvcGVydGllcyBtdXN0IHByZWNlZGUNCnN1Ym5vZGVzIg0KDQpDaGFuZ2VzIGluIHYxMToN Ci0gRml4IGFnZW50X2lkIGRvY3VtZW50YXRpb246IGNsYXJpZnkgaXQgYXBwbGllcyB0byBTQ01J IFNNQw0KbXVsdGktYWdlbnQgc3VwcG9ydCBvbmx5LCBub3QgcGxhaW4gU0NNSSBTTUMgKHJldmll d2VyIGZlZWRiYWNrKQ0KLSBSZW1vdmUgIm5vbi16ZXJvIiBmcm9tIGFnZW50X2lkIGRlc2NyaXB0 aW9uIHRvIG1hdGNoIGFjY2VwdGVkDQpyYW5nZSBbMC4uMjU0XQ0KLSBSZW1vdmUgIlVJTlQ4X01B WCAoMjU1KSBpcyB0cmVhdGVkIGFzIGludmFsaWQiIGZyb20gdXNlcg0KZG9jdW1lbnRhdGlvbiBh cyB1bm5lY2Vzc2FyeSBpbXBsZW1lbnRhdGlvbiBkZXRhaWwNCi0gQWRkIExJQlhMX0hBVkVfU0NN SV9TTUNfTVVMVElBR0VOVCBmZWF0dXJlIG1hY3JvIGluIGxpYnhsLmggdG8NCmFkdmVydGlzZSB0 aGUgbmV3IHNjbWlfc21jX211bHRpYWdlbnQgdHlwZSBhbmQgYWdlbnRfaWQgZmllbGQNCi0gQWRk IGFnZW50X2lkIHZhbGlkYXRpb24gaW4NCmxpYnhsX19hcmNoX2RvbWFpbl9idWlsZF9pbmZvX3Nl dGRlZmF1bHQoKSB0byByZWplY3QgaW52YWxpZCB2YWx1ZXMgYXQNCnRoZSBsaWJ4bCBsZXZlbCwg bm90IG9ubHkgaW4geGwNCg0KQ2hhbmdlcyBpbiB2MTA6DQotIHJlbW92ZSB1bnVzZWQgc2NpX2Rv X2RvbWN0bCBzdHViIGZyb20gc2NpLmgNCi0gcmVtb3ZlZCBleHRyYSBpbmNsdWRlIGluIG1lbWNw eS17dG8vZnJvbX1pby5jIGZpbGVzDQotIEZpeCB0YWJzIGluIE1BSU5UQUlORVJTIGZpbGUNCi0g cmVtb3ZlIGR1cGxpY2F0ZSBTUERYIHRhZyBmcm9tIHNjbWktc2htZW0uYw0KLSBhZGQgY2FzdCB0 byBBUk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVURVIgdG8gc2V0dGxlIHRoZSBzaWduIHNpbmNlDQpB Uk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVURVIgaXMgLTMgd2hpY2ggaXMgcGFydCBvZiB0aGUgc3Bl YyBhbmQgcmVzcA0KaXMgdGhlIGRlZmF1bHQgc21jY2MgY2FsbCBzdHJ1Y3R1cmUuDQotIHVwZGF0 ZSBmcmVlX2NoYW5uZWxfbGlzdC4gQWRkIHNwaW5sb2NrIHRvIGF2b2lkIHJhY2UgY29uZGl0aW9u IGFuZA0KYSBjb21tZW50IHdpdGggYSBkZXNjcmlwdGlvbiBvZiB0aGUgZnVuY3Rpb24gd29yaw0K LSBwcmVzZXJ2ZSBlcnJvciBvZiBzbWNfY3JlYXRlX2NoYW5uZWwgaW4gc2NtaV9wcm9iZQ0KLSBj aGVjayBzY21pIHNobWVtIGFkZHJlc3MgYWxpZ25tZW50IGFzIHdlbCBhcyBpdCBpcyBkb25lIGZv ciBzaXplDQotIGNoZWNrIGZvciBkLT5hcmNoLnNjaV9kYXRhICE9IE5VTEwgaW4gc2NtaV9oYW5k bGVfY2FsbA0KLSB1c2UgU0NNSV9TSE1FTV9NQVBQRUQgc2l6ZSBmb3IgaW9tZW1fcGVybWl0X2Fj Y2Vzcw0KLSBjaGFuZ2UgbGVuIHR5cGUgdG8gdW5zaWduZWQgaW4gc2htZW1fe2dldHxwdXR9X21l c3NhZ2UNCi0gcmVuYW1lIHNobWVtX2NoYW5uZWxfaXNfZnJlZSB0byBzaG1lbV9jaGFubmVsX3N0 YXR1cw0KLSBhZGQgY29tbWVudCBhYm91dCBza2lwcGluZyBtZXNzYWdlIHN0YXR1cyB3aGVuIGdl dHRpbmcgbWVzc2FnZSByZXNwb25zZQ0KLSBTZXQgY29ycmVjdCBhZ2VudF9pZCByYW5nZXMgZm9y IGRvbTBsZXNzIGFuZCBhIHRvb2xzdGFjay4gQWdlbnRfaWQgMA0KaXMgbm90IGJpbmRlZCBmb3Ig ZG9tMCBzbyBjYW4gYmUgcmV1c2VkLiBBbHNvIG1lbnRpb25lZCB0aGF0DQpVSU5UOF9NQVggKDI1 NSkgaXMgdHJlYXRlZCBhcyBpbnZhbGlkIGFnZW50X2lkLg0KLSBTcGxpdCBoeXBlcnZpc29yIGFu ZCB0b29sc3RhY2sgY2hhbmdlcyBpbnRvIHNlcGFyYXRlIGNvbW1pdHMNCi0gbW92ZSBpbml0IGxp c3QgYW5kIHNwaW4gaW5pdCBhZnRlciBpbml0aWFsIGNoZWNrcyBpbiBwcm9iZSBjYWxsDQotIGZp eCB0eXBvIGluIGNvbW1lbnRzDQotIGNsZWFuIHJlc291cmNlcyB3aGVuIHNjaV9yZWdpc3RlciBy ZXR1cm5zIGFuIGVycm9yLg0KLSBTcGxpdCBoeXBlcnZpc29yIGFuZCB0b29sc3RhY2sgY2hhbmdl cyBpbnRvIHNlcGFyYXRlIGNvbW1pdHMNCi0gcmVwaHJhc2Ugc2VjdGlvbiBhYm91dCAvZmlybXdh cmUvc2NtaS4gTWVudGlvbmVkIHRoYXQgdGhpcyBub2RlIGlzDQp0YWtlbiBmcm9tIEhvc3QgRFQg YW5kIGNvcGllZCB1bm1vZGlmaWVkLg0KLSBmaXggeGVuLHJlZyBhZGRyZXNzIGZvciBzZWNvbmRh cnkgZG9tYWlucyBmb3IgRG9tMGxlc3MgY29uZmlndXJhdGlvbg0KDQpDaGFuZ2VzIGluIHY5Og0K LSB0cmVhdCBTQ0kgYXMgYSBnYXRlIGZvciBYRU5fRE9NQ1RMXyphc3NpZ25fZGV2aWNlOiBhYm9y dCBiZWZvcmUNCklPTU1VIGlmIHNjaV9kb19kb21jdGwoKSByZXR1cm5zIGFuIGVycm9yIG90aGVy IHRoYW4gLUVOWElPLCBpbnN0ZWFkDQpvZiB0cnlpbmcgdG8gcHJvcGFnYXRlIFNDSSBlcnJvcnMg YWZ0ZXIgYSBzdWNjZXNzZnVsIElPTU1VDQpvcGVyYXRpb24uIFRoaXMgYXZvaWRzIHBhcnRpYWwg c3VjY2VzcyBhbmQgdGhlIG5lZWQgZm9yIElPTU1VIHJvbGxiYWNrLg0KLSByZW1vdmUgZWFybHkg cmV0dXJuIGZyb20gZG9fZG9tY3RsKCkgaW4gdGhlIGFzc2lnbl9kZXZpY2UNCnBhdGggdG8ga2Vl cCBSQ1UgaGFuZGxpbmcgaW50YWN0Lg0KLSBjaGFuZ2UgSVNfRU5BQkxFRCgqKSB0byAjaWZkZWYg aW4gc2NpX2RvX2RvbWN0bCBxdWFyZA0KLSByZXdvcmQgY29tbWl0IGRlc2NyaXB0aW9uIHRvIHJl ZmVyIHRvIG1lbWNweV9mcm9taW8gYW5kIG1lbWNweV90b2lvDQotIG9yZGVyaW5nIG9iai15IGlu IE1ha2VmaWxlDQotIHJlbmFtZSBBTExfTElCUyB0byBBUkNIX0xJQlMNCi0gZHJvcCBpby5oIGFu ZCBtb3ZlIGRlZmluaXRpb25zIHRvIHRoZSBjb21tb24gaGVhZGVyLCBmaXggY29tbWVudHMgdG8N CmJlIGFyY2ggbmV1dHJhbA0KLSB1cGRhdGUgY29tbWVudHMgZm9yIG1lbWNweV97ZnJvbS90b31p byBpbXBsZW1lbnRhdGlvbg0KLSBzb3J0IGFuZCByZWZhY3RvciBNQUlOVEFJTkVSUyBlbnRpZXMN Ci0gcmVtb3ZlIFNwdXJpb3VzIGNoYW5nZXMNCi0gYWRkIGV4dHJhIGNoZWNrIHRvIGF2b2lkIEFT U0VSVCB3aGVuIGNhbGxpbmcgdW5tYXBfY2hhbm5lbF9tZW1vcnkNCmZyb20gYXNzaWduIGRldmlj ZSBtZXRob2QNCi0gc2V0IGNvcnJlY3QgdHggZmxhZyB0byBTQ01JX0JBU0VfQUdFTlRfUEVSTUlT U0lPTlNfUkVTRVQgd2hlbg0KZnJlZWluZyByZXNvdXJjZXMuIEZsYWcgc2hvdWxkIGJlIHNldCB0 byAxIGFjY29yZGluZyB0byB0aGUNCnNlY3Rpb24gNC4yLjIuMTIgWzBdLg0KLSBmaXggZHQgbm9k ZSBjb3BtYXJpbmcNCi0gbW92ZWQgY2hhbm5lbC0+c2htZW0gY2hlY2sgZnJvbSBBU1NFUlQgaW4g dW5tYXBfbWVtb3J5X2NoYW5uZWwgdG8NCiJpZiIgc3RhdGVtZW50LiBUaGlzIHdpbGwgcHJldmVu dCBmaXJpbmcgQVNTRVJUIGlmDQp1bm1hcF9jaGFubmVsX21lbW9yeSB3YXMgY2FsbGVkIHR3aWNl IG9uIHRoZSBzYW1lIGNoYW5uZWwuDQoNCkNoYW5nZXMgaW4gdjg6DQotIGNoZWNrIGZvciBDT05G SUdfQVJNX1NDSSB0byBiZSBlYmFibGVkIGluc3RlYWQgb2YgQ09NRklHX0FSTSBiZWZvcmUNCmNh bGxpbmcgc2NpX2RvX2RvbWN0bA0KLSByZXdvcmsgc2NpX2RvX2RvbWN0bCBjYWxsIHRvIGF2b2lk IGV4dHJhIGNoZWNrcywgaW1wcm92ZWQgZXJyb3INCmhhbmRsaW5nLg0KLSBkbyBub3QgcHJvcGFn YXRlIHJldDEgaWYgc2NpX2RvX2RvbWN0bCByZXR1cm5lZCBwb3NpdGl2ZSByZXQNCi0gdXBkYXRl ZCBjb21tZW50IGluIGRvbWN0bC5jIGNvZGUNCi0gc3dpdGNoZWQgdG8gb3JkZXJlZCBhY2Nlc3Nv cnMgdG8gYWRkcmVzcyB0aGUgb3JkZXJpbmcgYW5kIGJhcnJpZXINCmNvbmNlcm5zLg0KLSB1cGRh dGVkIHRoZSBkb2N1bWVudGF0aW9uIHRvIG1hdGNoIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgZXhw bGljaXRseQ0Kc3RhdGUgdGhlIHN1cHBvcnRlZCBhY2Nlc3Mgc2l6ZXMgYW5kIGdyYW51bGFyaXR5 Lg0KLSByZW5hbWUgbWVtY3B5XyogaW1wbGVtZW50YXRpb24gZmlsZXMgdG8gbWVtY3B1LSogdG8g Zm9sbG93IG5hbWluZw0KY29udmVuc2lvbg0KLSBmaXggaW5kZW50YXRpb24gdG8gbWF0Y2ggWGVu IHN0eWxlDQotIGZpeCBpbnRlbmRhdGlvbiB0byBtYXRjaCBYZW4gc3R5bGUNCi0gbW92ZSBtZW1j cHkte2Zyb20vdG99aW8gdG8gbW9yZSBjb252ZW5pZW50IGxpYnJhcnkgcGxhY2UNCi0gdXBkYXRl IHhlbl9zY21pIGZ1bmNfaWQgaW4gY29tbWl0IGRlc2NyaXB0aW9uDQotIHVwZGF0ZWQgZG9jdW1l bnRhdGlvbiB3aXRoIHRoZSBuZXcgRFQgZm9ybWF0DQotIHVwZGF0ZWQgb3B0X2RvbTBfc2NtaV9h Z2VudF9pZCBzZXR0aW5nIHRvIGF2b2lkIGl0IHRvIGJlIGVxdWFsDQpTQ01JX0FHRU5UX0lEX0lO VkFMSUQuDQotIGNoYW5nZWQgU0NNSV9BR0VOVF9JRF9JTlZBTElEIGZyb20gMHhmZiB0byBVSU5U OF9NQVggd2hpY2ggbWFrZXMNCmNvZGUgbW9yZSBjbGVhciBzaG93aW5nIHRoYXQgVUlOVDhfTUFY IGlzIHRoZWF0ZWQgbGlrZSBpbnZhbGlkDQphZ2VudF9pZCBhbmQgY291bGRuJ3QgYmUgdXNlZC4g QWxzbyBleGNsdWRlZCBTQ01JX0FHRU5UX0lEX0lOVkFMSUQNCmZyb20gYWNjZXB0YWJsZSB2YWx1 ZSByYW5nZQ0KLSByZW1vdmUgb3V0ZGF0ZWQgeGVuLGNvbmZpZyBwcm9wZXJ0eSBpZ25vcmUsIGFk ZGVkIHhlbixzY2kgY29tcGF0aWJsZQ0KdG8gc2tpcF9tYXRjaGVzIGluIGhhbmRsZV9ub2RlDQot IGFkZCBkb2N1bWVudGF0aW9uIGZvciBwcmUtZXhpc3Rpbmcgc2NtaS1zbWMtcGFzc3Rocm91Z2gg Y29tbWFuZCBsaW5lDQpvcHRpb24gaW4gYWxwaGFiZXRpY2FsbHkgY29ycmVjdCBsb2NhdGlvbiAo aW4gJ3MnIHNlY3Rpb24pDQotIGFkZCBub3RlIHRvIGNvbW1pdCBkZXNjcmlwdGlvbiBhYm91dCBk b2N1bWVudGF0aW9uIGZvciBwcmV2aW91c2x5DQp1bmRvY3VtZW50ZWQgc2NtaS1zbWMtcGFzc3Ro cm91Z2gNCi0gRml4IFNNQyBJRHMgaW4gRFQgZXhhbXBsZXMgKFhlbiBtYW5hZ2VtZW50IHVzZXMg MHg4MjAwMDAwMywgRG9tMCB1c2VzIDB4ODIwMDAwMDIpDQotIEFkZCBleHBsaWNpdCBub3RlIGV4 cGxhaW5pbmcgd2h5IERvbTAgYW5kIFhlbiBjaGFubmVscyBkbyBub3QgY29uZmxpY3QNCi0gRG9j dW1lbnQgZG9tMGxlc3MgbXVsdGktYWdlbnQgY29uZmlndXJhdGlvbiBleGFtcGxlICh4ZW4sc2Np X3R5cGUgLyB4ZW4sc2NpLWFnZW50LWlkKQ0KLSBBZGQgc2NtaV94ZW4gbm9kZSB0byBhZ2VudC1k aXNjb3ZlcnkgZXhhbXBsZSB3aXRoICNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMgPSAyDQot IERyb3AgZG9tMD1zY2ktYWdlbnQtaWQgY29tbWFuZCBsaW5lIGhhbmRsaW5nOyBEb20wIFNDTUkg aXMgbm93IGVuYWJsZWQgdmlhDQogIHhlbixkb20wLXNjaS1hZ2VudC1pZCBpbiB0aGUgeGVuLHNj aSBEVCBjb250YWluZXINCi0gUmVmcmVzaCBkb2NzIGFuZCBleGFtcGxlcyB0byBtZW50aW9uIHRo ZSBEVCBwcm9wZXJ0eSBpbnN0ZWFkIG9mIHRoZSBjbWRsaW5lIG9wdGlvbg0KLSB1cGRhdGUgZG9j dW1lbnRhdGlvbiB0byBtYXRjaCB0aGUgbGFzdCBEVCBmb3JtYXQNCi0gZml4ZWQgUlNUOiAiLi4u IGNvZGUtYmxvY2s6OiBkdHMiIC0+ICIuLiBjb2RlLWJsb2NrOjogZHRzIg0KLSB1cGRhdGUgZG9j dW1lbnRhdGlvbiB3aXRoIGRvbTBsZXNzIGNvbmZpZ3VyYXRpb24gZXhhbXBsZQ0KLSB1cGRhdGUg ZG9jdW1lbnRhdGlvbiB3aXRoIG5ldyBwYXJhbSB4ZW4sZG9tMC1zY2ktYWdlbnQtaWQNCmluc3Rl YWQgb2YgdGhlIGNvbW1hbmQgbGluZSBwYXJhbWV0ZXINCg0KQ2hhbmdlcyBpbiB2NzoNCi0gdXBk YXRlIGRvbWN0bCB0byBidWlsZCBvbiBib3RoIEFybSBhbmQgeDg2IHBsYXRmb3Jtcw0KLSBtb3Zl IHJldDEgZGVjbGFyYXRpb24gdG8gdGhlIHRvcCBvZiB0aGUgZnVuY3Rpb24gYXMgcmVxdWlyZWQg YnkgY29kZQ0Kc3R5bGUNCi0geDg2IGd1aWRhbmNlOiByZW1vdmVkIHRoZSBzcGVjdWxhdGl2ZSBu b3RlOyBoZWFkZXIgbm93IGp1c3Qgc2F5cw0KICBlYWNoIGFyY2ggc3VwcGxpZXMgaXRzIG93biBp bXBsZW1lbnRhdGlvbiBvciBtYWNyby4NCi0gbmFtZSBzcGFjaW5nOiBkcm9wcGVkIHRoZSBkb3Vi bGUtdW5kZXJzY29yZTsgdGhlIGhlbHBlcnMgYXJlIG5vdw0KICBtZW1jcHlfZnJvbWlvIC8gbWVt Y3B5X3RvaW8uIFRoZSBoZWFkZXIgYWxzbyBleHBsaWNpdGx5IGFsbG93cyBhbg0KICBhcmNoIHRv IGRlZmluZSB0aGVzZSBhcyBtYWNyb3MgYmVmb3JlIGluY2x1ZGluZyBpdC4NCi0gdXBkYXRlZCBp by5jIHRvIGtlZXAgMzItYml0IHRyYW5zZmVycyBzYWZlIG9uIGFybTMyDQotIG1vdmVkIHRvIF9f cmF3X3JlYWQqL19fcmF3X3dyaXRlKiBhY2Nlc3NvcnMgdG8gYXZvaWQgZW5kaWFubmVzcyBjb252 ZXJzaW9uLg0KLSBzcGxpdCB0aGUgaGVscGVycyBpbnRvIHNlcGFyYXRlIGNvbXBpbGF0aW9uIHVu aXRzDQotIHJld29yayBzY21pIG5vZGVzIGZvciB4ZW4gdG8gbWF0Y2ggb24gY29tcGF0aWJsZSBz dHJpbmcgaW5zdGVhZCBvZg0KdGhlIGRpcmVjdCBwYXRoDQotIHVwZGF0ZSBkb2N1bWVudGF0aW9u IGluIHNlY3Rpb24gb2YgdGhlIHhlbl9zY21pIGNvbmZpZ3VyYXRpb24gd2hpY2gNCmlzIG1hdGNo ZWQgYnkgInhlbixzY2kiIGNvbXBhdGlibGUgaW5zdGVhZCBvZiB0aGUgZGlyZWN0IHBhdGguDQoN CkNoYW5nZXMgaW4gdjY6DQotIGNoYW5nZSBpb21tdV9kb19kb21jdGwgYW5kIHNjaV9kb19kb21j dGwgY29tbWFuZCBvcmRlciBhbmQNCmNhbGwgc2NpX2RvX2RvbWN0bCBmaXJzdCB3aGljaCB3aWxs IHByb2R1Y2UgY2xlYW5lciBjb2RlIHBhdGguDQpBbHNvIGRyb3BwZWQgY2hhbmdpbmcgcmV0dXJu IGNvZGUgd2hlbiBpb21tdSB3YXMgZGlzYWJsZWQgaW4NCmlvbW11X2RvX2RvbWN0bC4NCi0gc29y dGVkIG9ianMgaW4gTWFrZWZpbGUgYWxoYWJldGljYWxseQ0KLSBhZGRlZCBuZXdsaW5lIGF0IHRo ZSBlbmQgb2YgTWFrZWZpbGUNCi0gdXNlZCB1aW50e059X3QgaW50ZWFkIG9mIHV7Tn0NCi0gYWRk IGNvbW1lbnQgYWJvdXQgd2h5IDMyIGJpdCBJTyBvcGVyYXRpb25zIHdlcmUgdXNlZA0KLSB1cGRh dGVkIGNhc3Qgb3BlcnRhaW9ucyB0byBhdm9pZCBkcm9wcGluZyBjb25zdG5lc3Mgd2hpY2ggaXMg d3JvbmcNCi0gbW92ZSBmdW5jdGlvbiBkZWZpbml0aW9ucyB0byBnZW5lcmljIHBsYWNlIHNvIHRo ZSBjb3VsZCBiZSByZXVzZWQgYnkNCm90aGVyIGFyY2gNCi0gYWRkIFNQRFggdGFnIHRvIGlvLmMN Ci0gdXBkYXRlZCBzY21pLXNobWVtIHRvIHVzZSBpby5oIGZyb20gZ2VuZXJpYyBsb2NhdGlvbg0K LSB1cGRhdGUgc2NtaV9hZ2VudF9pZCBwYXJhbWV0ZXIgdG8gYmUgcHJvdmlkZWQgaW5zaWRlIGRv bTA9IHBhcmFtZXRlcg0KbGlzdCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGZvcm1hdCAiZG9tMD1z Y2ktYWdlbnQtaWQ9MCINClRoaXMgY2hhbmdlIHdhcyBkb25lIGFzIGEgcmVzcG9uc2UgZm9yIFN0 ZWZhbm8gY29tbWVudCBhbmQNCnJlcXVpcmVzIGEgbG90IG9mIGNvZGUgY2hhbmdlcywgYnV0IHBy b2R1Y2VzIG11Y2ggY2xlYW5lciBzb2x1dGlvbg0KdGhhdCdzIHdoeSBJJ3ZlIGFkZGVkIGl0IHRv IHRoZSBjb2RlLg0KLSBmaXggZmlsZSBjb21tZW50cyBhbmQgcmV0dXJuIGNvZGVzDQotIGZpeCBs ZW5naHQgY2hlY2tzIGluIHNobWVtX3tnZXQscHV0fV9tZXNzYWdlIHRvIHVzZSBvZmZzZXRvZg0K LSByZW1vdmUgbGVuIG1lbWJlciBmcm9tIHNjbWlfY2hhbm5lbCBzdHJ1Y3R1cmUgYXMgaXQgaXMg bm90IHVzZWQNCi0gc2V0IHNjbWktc2Vjb25kYXJ5LWFnZW50cyBwcm9wZXJ0eSB0byBiZSBtYW5k YXRvcnkgc2luY2UgaWYgbm8NCnNlY29uZGFyeSBhZ2VudHMgd2VyZSBwcm92aWRlZCB0aGVuIHRo ZXJlIGlzIG5vIHNlbmNlIHRvIGVuYWJsZSBzY21pDQp3aGVuIG5vIHNlY29uZGFyeSBhZ2VudHMg YXJlIHBvcHVsYXRlZCB0byB0aGUgRG9tYWlucw0KLSB1cGRhdGUgZG9jdW1lbnRhdGlvbiBpbiBi b290aW5nLnR4dCwgYWRkZWQgeGVuX3NjbWkgbm9kZSB0byB0aGUNCmV4YW1wbGUNCi0gYWRqdXN0 IGQtPmFyY2guc2NpX2VuYWJsZWQgdmFsdWUgaW4gc2NtaV9kb21haW5fZGVzdHJveQ0KLSBmaXgg bG9jayBtYW5hZ2VtZW50IGluIHNtY19jcmVhdGVfY2hhbm5lbCBjYWxsDQotIGF2b2lkIGV4dHJh IG1hcF9jaGFubmVsX21lbW9yeSBjb21tYW5kIGZvciBYZW4gbWFuYWdlbWVudCBjaGFubmVsDQpi ZWNhdXNlIGNvbGxlY3RfYWdlbnRfaWQgY2FsbCB1bm1hcHMgbWVtb3J5IGlmIERPTUlEX1hFTiBp cyBub3QNCnNldC4gU28gZm9yIFhlbiBtYW5hZ2VtZW50IGNoYW5uZWwgd2UgY2FuIGluaXQgZG9t YWluX2lkIGFkIERPTUlEX1hFTg0KYmVmb3JlIGNhbGxpbmcgY29sbGVjdF9hZ2VudF9pZCBzbyBt ZW1vcnkgc2hvdWxkbid0IGJlIHVubWFwcGVkLg0KLSByZW1vdmUgYWxsIEhWQyBtZW50aW9ucyBm cm9tIHRoZSBtdWx0aS1hZ2VudCBkb2MNCi0gdXBkYXRlIHNjaS1hZ2VudC1pZCBwYXJhbWV0ZXIg ZGVzY3JpcHRpb24gaW4gdGhlIGRvY3VtZW50YXRpb24NCi0gYWRkIG1pc3NpbmcgU2lnbi1vZg0K LSBtaW5vciBmaXhlcyBhY3Jvc3MgdGhlIGRvY3VtZW50DQoNCkNoYW5nZXMgaW4gdjU6DQotIHJl dHVybiAtRUlOVkFMIGlmIG1lZGlhdG9yIHdpdGhvdXQgYXNzaWduX2R0X2RldmljZSB3YXMgcHJv dmlkZWQNCi0gaW52ZXJ0IHJldHVybiBjb2RlIGNoZWNrIGZvciBpb21tdV9kb19kb21jdGwgaW4N ClhFTl9ET01DVExfYXNzaWduX2RldmljZSBkb21jdGwgcHJvY2Vzc2luZyB0byBtYWtlIGNsZWFu ZXIgY29kZQ0KLSBjaGFuZ2UgLUVOT1RTVVBQIGVycm9yIGNvZGUgdG8gLUVOWElPIGluIHNjaV9k b19kb21jdGwNCi0gaGFuZGxlIC1FTlhJTyByZXR1cm4gY29tZGUgb2YgaW9tbXVfZG9fZG9tY3Rs DQotIGxlYXZlICFkdF9kZXZpY2VfaXNfcHJvdGVjdGVkIGNoZWNrIGluIGlvbW11X2RvX2R0X2Rv bWN0bCB0byBtYWtlDQpjb2RlIHdvcmsgdGhlIHNhbWUgd2F5IGl0J3MgZG9uZSBpbiAiaGFuZGxl X2RldmljZSIgY2FsbCB3aGlsZQ0KY3JlYXRpbmcgaHdkb20oZG9tMCkgYW5kICJoYW5kbGVfcGFz c3Rocm91Z2hfcHJvcCIgY2FsbCBmb3IgZG9tMGxlc3MNCmNyZWF0aW9uDQotIGRyb3AgcmV0dXJu IGNoZWNrIGZyb20gc2NpX2Fzc2lnbl9kdF9kZXZpY2UgY2FsbCBhcyBub3QgbmVlZGVkDQotIGRv IG5vdCByZXR1cm4gRUlOVkFMIHdoZW4gYWRkaWduX2R0X2RldmljZSBpcyBub3Qgc2V0LiBUaGF0 IGlzDQpiZWNhdXNlIHRoaXMgY2FsbGJhY2sgaXMgb3B0aW9uYWwgYW5kIG5vdCBpbXBsZW1lbnRl ZCBpbiBzaW5nbGUtYWdlbnQgZHJpdmVyDQotIG1vdmUgbWVtY3B5X3RvaW8vZnJvbWlvIHRvIHRo ZSBnZW5lcmljIHBsYWNlDQotIGZpeCBkZXZpY2UtdHJlZSBleGFtcGxlIGZvcm1hdCBpbiBib290 aW5nLnR4dCwgYWRkZWQgIjsiIGFmdGVyICJ9Ii4NCi0gdXBkYXRlIGRlZmluZSBpbiBzY21pLXBy b3RvLmgNCi0gdXBkYXRlIGRlZmluZSBpbiBzY21pLXNobWVtLmggZmlsZQ0KLSBzY21pX2Fzc2ln bl9kZXZpY2UgLSBkbyBub3QgaWdub3JlIC1FT1BOT1RTVVBQIHJldHVybg0KY29kZSBvZiB0aGUg ZG9fc21jX3hmZXINCi0gcmVtb3ZlIG92ZXJ3cml0aW5nIGFnZW50X2NoYW5uZWwtPmFnZW50X2lk IGFmdGVyDQpTQ01JX0JBU0VfRElTQ09WRVJfQUdFTlQgY2FsbA0KLSBhZGQgbXVsdGktYWdlbnQg ZmlsZXMgdG8gdGhlIE1BSU5UQUlORVJTDQotIGFkZCBTQ01JIG11bHRpLWFnZW50IGRlc2NyaXB0 aW9uIHRvIHRoZSBTVVBQT1JULm1kDQotIGhhbmRsZSBBUk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVU RVIgcmV0dXJuIGNvZGUgYW5kIHJldHVybiAtRUlOVkFMDQpmb3Igc21jIGNhbGwNCi0gdXBkYXRl ZCBjb2xsZWN0X2FnZW50cyBmdW5jdGlvbi4gU2V0IGFnZW50X2lkIHBhcmFtZXRlciBhcyBvcHRp b25hbA0KaW4gc2NtaS1zZWNvbmRhcnktYWdlbnRzIGRldmljZS10cmVlIHByb3BlcnR5DQotIGlu dHJvZHVjZSAiI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyIgcGFyYW1ldGVyIHRvIHNldCBp Zg0KYWdlbnRfaWQgd2FzIHByb3ZpZGVkDQotIHJlYW5tZSB4ZW4sc2NtaS1zZWNvbmRhcnktYWdl bnRzIHByb3BlcnR5IHRvIHNjbWktc2Vjb25kYXJ5LWFnZW50cw0KLSBtb3ZlIG1lbWNwdV90b2lv L2Zyb21pbyBmb3IgdGhlIGdlbmVyaWMgcGxhY2UNCi0gdXBkYXRlIFhlbiB0byBnZXQgbWFuYWdl bWVudCBjaGFubmVsIGZyb20gL2Nob3Nlbi94ZW4sY29uZmlnIG5vZGUNCi0gZ2V0IGh5cGVydmlz b3IgY2hhbm5uZWwgZnJvbSBub2RlIGluc3RlYWQgb2YgdXNpbmcgaGFyZGNvZGVkDQotIHVwZGF0 ZSBoYW5kbGluZyBzY21pIGFuZCBzaG1lbSBub2RlcyBmb3IgdGhlIGRvbWFpbg0KLSBTZXQgbXVs dGktYWdlbnQgZHJpdmVyIHRvIHN1cHBvcnQgb25seSBBcm02NA0KLSByZXdvcmsgbXVsdGktYWdl bnQgZHJpdmVyIHRvIGxlYXZlIEhvc3QgRGV2aWNlLXRyZWUgdW5tb2RpZmllZA0KDQpDaGFuZ2Vz IGluIHY0Og0KLSB0b29sc3RhY2sgY29tbWVudHMgZnJvbSBBbnRob255IFBFUkFSRA0KLSBhZGRl ZCBkb20wbGVzcyBzdXBwb3J0DQotIGFkZGVkIGRvYyBmb3IgInhlbixzY21pLXNlY29uZGFyeS1h Z2VudHMiDQoNCkdyeWdvcmlpIFN0cmFzaGtvICgyKToNCiAgeGVuL2RvbWN0bDogY2hhaW4gU0NJ IGhhbmRsaW5nIGJlZm9yZSBJT01NVSBpbiBhc3NpZ25fZGV2aWNlIGRvbWN0bA0KICBkb2NzOiBh cm06IGFkZCBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGRvY3MNCg0KT2xla3NpaSBN b2lzaWVpZXYgKDQpOg0KICB4ZW46IGFybTogc21jY2M6IGFkZCBJTlZBTElEX1BBUkFNRVRFUiBl cnJvciBjb2RlDQogIGxpYi9hcm06IEFkZCBJL08gbWVtb3J5IGNvcHkgaGVscGVycw0KICB4ZW4v YXJtOiBzY21pOiBpbnRyb2R1Y2UgU0NJIFNDTUkgU01DIG11bHRpLWFnZW50IGRyaXZlcg0KICB0 b29scy94bC9saWJ4bDogd2lyZSB1cCBTQ01JIFNNQyBtdWx0aS1hZ2VudCBjb25maWd1cmF0aW9u DQoNCiBNQUlOVEFJTkVSUyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEg Kw0KIFNVUFBPUlQubWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxMSAr DQogLi4uL2FybS9maXJtd2FyZS9hcm0tc2NtaS5yc3QgICAgICAgICAgICAgICAgIHwgNDIyICsr KysrKysrKw0KIGRvY3MvbWFuL3hsLmNmZy41LnBvZC5pbiAgICAgICAgICAgICAgICAgICAgICB8 ICAxMyArDQogZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dCAgICAgICAgIHwg MTk3ICsrKysrDQogdG9vbHMvaW5jbHVkZS9saWJ4bC5oICAgICAgICAgICAgICAgICAgICAgICAg IHwgICA4ICsNCiB0b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jICAgICAgICAgICAgICAgICAg fCAgMTMgKw0KIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsICAgICAgICAgICAgICB8 ICAgNCArLQ0KIHRvb2xzL3hsL3hsX3BhcnNlLmMgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAyNyArDQogeGVuL2FyY2gvYXJtL01ha2VmaWxlICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAxICsNCiB4ZW4vYXJjaC9hcm0vYXJjaC5tayAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg IDEgKw0KIHhlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jICAgICAgICAgICAgICAgICB8ICAx NyArDQogeGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jICAgICAgICAgICAgICAgICAgIHwgIDQz ICsNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZyAgICAgICAgICAgICAgICAgfCAgMTIg Kw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZSAgICAgICAgICAgICAgICB8ICAgMSAr DQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jICAgICAgICAgICAgICAgICAgIHwgIDM2ICsN CiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5oICAgICAgICAgICAgfCAxNjQgKysr Kw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMgICAgICAgICAgICB8IDExOCAr KysNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5oICAgICAgICAgICAgfCAgNDUg Kw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMgICB8IDgxNiAr KysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2Np LmggICAgICAgfCAgIDggKw0KIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9zbWNjYy5oICAgICAg ICAgICAgICB8ICAgMSArDQogeGVuL2FyY2gvYXJtL2xpYi9NYWtlZmlsZSAgICAgICAgICAgICAg ICAgICAgIHwgICAyICsNCiB4ZW4vYXJjaC9hcm0vbGliL21lbWNweS1mcm9taW8uYyAgICAgICAg ICAgICAgfCAgNTUgKysNCiB4ZW4vYXJjaC9hcm0vbGliL21lbWNweS10b2lvLmMgICAgICAgICAg ICAgICAgfCAgNTUgKysNCiB4ZW4vY29tbW9uL2RvbWN0bC5jICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgMTUgKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMgICAg ICAgICB8ICAgNiArDQogeGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmggICAgICAgICAgICAg ICAgIHwgICA1ICstDQogeGVuL2luY2x1ZGUveGVuL2lvLmggICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIDEwICsNCiAyOSBmaWxlcyBjaGFuZ2VkLCAyMTA1IGluc2VydGlvbnMoKyksIDIgZGVs ZXRpb25zKC0pDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21p LXByb3RvLmgNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWkt c2htZW0uYw0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1z aG1lbS5oDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNt Yy1tdWx0aWFnZW50LmMNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2xpYi9NYWtl ZmlsZQ0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vbGliL21lbWNweS1mcm9taW8u Yw0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vbGliL21lbWNweS10b2lvLmMNCg0K LS0gDQoyLjQzLjANCg0KYmFzZS1jb21taXQ6IDgyMmIwYmU2NjA2ZDQ5YzE0NDM3NDg0NDUzMGQ1 MTY4ODk3OTFmYTgNCmJyYW5jaDogc2NtaV9tYV91cHN0cnYxMg== From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:26:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:26:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415783.1645005 (Exim 4.92) (envelope-from ) id 1x4veS-000376-2X; Fri, 11 Sep 2026 07:26:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415783.1645005; Fri, 11 Sep 2026 07:26:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veR-00036y-Ui; Fri, 11 Sep 2026 07:26:23 +0000 Received: by outflank-mailman (input) for mailman id 1415783; Fri, 11 Sep 2026 07:26:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veR-00036Q-5c for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:26:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4veQ-001KmU-IJ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:26:22 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ad17-e002-0a2a0a5209dd-0a2a4507c276-14 for ; Fri, 11 Sep 2026 09:26:22 +0200 Received: from [52.101.70.117] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ad1d-b4ea-0a2a45070019-3465467530e0-3 for ; Fri, 11 Sep 2026 09:26:22 +0200 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com (2603:10a6:10:519::5) by AM9PR03MB8025.eurprd03.prod.outlook.com (2603:10a6:20b:43c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:26:19 +0000 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908]) by DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908%5]) with mapi id 15.21.0406.005; Fri, 11 Sep 2026 07:26:19 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ApGkrxV0dl4j4hcWY2dVav6ixx5lIsGFP7rOgEudCjpZ0MXoIzGjgOnKb+KjYuP/h/hUnAtuzpJGejfIp1RIyOuXgFujJV02nfR0AbDTg6f/7CSEGU2ZLiFq02ZHdwW8RXEaYREGpp4V4/zn0NMlVWH05BALqBRPZkT7BgKSU8IQyOvz5eGDT3srPyZU68+7to9Nb12E2O1pGEBUt9Evw2kwGLqMfnQb9ib3WW9XoWs2FRAG+Gmv7x+LwAFbWe1bZ6QQOiNuAEpzCU1UH2JaqeJUld7FUjbltCztVWQQXDGCZA/qOvuD4Dqb5yEnP1HlxV5qmvK9x2M8QjI4XoWa7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JdTxu4+yaXEuPwVL0HeTwvuZ+ydEh4tVnbwxInsLJX4=; b=DW2S+N4fDysP+p7APmP10/apiSmS+BgY2dj7FFU/OhhuSbkncx9rcxgr8IM/qv5g2bDwuDghjwXfZTqSG7R+sLgHcbSLTu1h6/pAcboTVh2Wv6U2zTOeecy4rgJ4r2S5tlg8+t6hyHl3v8hgLmz6nXNV3yviEW+6Edb9+Alq94TdruDM+ayAtobmThXjlKWRhKCNJabhbLChjpaoy37cvxX96Ay5BYSF3RcDAfEQyA9ynRWub/OGvnsiytR1ofgWJHM8Tv7P8vmV7ht+9JK8SIQEvbShDCYik4zaPSkDBT0IF0Dh8hNlnO4rpAIKCNSz0fgh0Ymh/lrVxZ9Gw5XHgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JdTxu4+yaXEuPwVL0HeTwvuZ+ydEh4tVnbwxInsLJX4=; b=Y7OtZSM0DU3TUHjb1CghPChjyubnm+Q+SSQ+1e4FFjnXN+ZhAP3+38XzpjTSn/j0FXirGTHstr0Q92kx6cN2/xF74UgvfutmSPnzPN+vW5TiJr4LzAJoy2tk9zo2OoRhkYhc0vkSa4PGvr6/YCvAGtBpKLp5zUt1bFz1iNAwSdfoIIKLQqACuCyJ/R8oMi1JlGTWESirhtyh0Jh7FFUN7/JKU7ukSj3Fvar3PLcsJWSwqVF1czfoHhEYZ6A2XlTj5POEayAoGtYuagK4mOKFD3oxTIZmTZauIzjn2N+rt4IXDcgP8D/DD7YeVcDQHXd1FnmuhH42W3kUz1YXYxV/WQ== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v12 1/6] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Topic: [PATCH v12 1/6] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Index: AQHdQb7WRikpVw4VXEKPzCwcewqVcg== Date: Fri, 11 Sep 2026 07:26:19 +0000 Message-ID: <0652b1784f49f76b86c1cd4bc26b81cb12ea1b23.1789055542.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR03MB10263:EE_|AM9PR03MB8025:EE_ x-ms-office365-filtering-correlation-id: 68153dc8-4ab6-4ab4-78d9-08df0fd5f960 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|10067099003|6133799003|3023799007|18002099003|22082099003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: 0Nfftwuc8IM+Wl3K5PNmKDAUfy1GlrxwZDZML2rN+yjJh7AE81HnR45G76fS1RgcVluwzSKQlJddzZLblitOXsBM4IO8AQvvP25AVTN6XfswclwlvxpCl7ACh0Bx7Ci0EnhTAPbq1pBDsWY78mzDCHXuCiRCZ/H2h60z64vuzN6mfzoQLoSC0vMm+edTcEmjlNCKUxygQspKYn+bN2cwxmiExXwv9W0chSs3+6gIINFXVIh3Uv62vcGQ77CBZDugut/IMBTs5UQw/5xo43e8pSYXTcbVY+Pl88sVvisWyyPd8CP1dFdqEDzjc+y7VrFdbHmjwrI7t8fHueEcrFrSxEGfQppNLd6uAAB+ZB05fcL2ojFMu25fJ9LSpYVfjkR1aHcj4QjnEWaNNDN24xM3tgg87V+N4Ci8t56/JG075V4nTyxKKO5J7G+wygoqV6sNrRdib040dYUFpXDVQI5NJ7PRwoUxILhR6go23hbgDBaKa/P6XJDTMUPetxrfoGwvaIYZnrhXOf7jqdWejziQ3JN2lJHJMGwFyCqjj7W4mmkV+VYanvMvR44eVO/dPN1sZP1VcDsacf3TItvI8jNDcxP1w80aPV1fgl+i91h0I0CGsSEuPYrA2Z3n2EMfJPA190WH+5JhsqNj1Cu4bRXHsACtVkgtXYgzz4B151UgNQLX9/6//Fj2Xqrt8ajgITxgyR1aeoJhN7qbhkOEnIT55hAEjL5C8uMozsmNU62UYtw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10263.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(10067099003)(6133799003)(3023799007)(18002099003)(22082099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eXZqNW9NZStYSVhLTUpMbEZuMVRSVHpSOVJtdWhWbjhqMmxDdURucWNnWGg0?= =?utf-8?B?UGNKMXl3UWlQNm1oMkRwMjNkUGRwUzBuTmtLR0JZSm1MWjAzK05qQzhZYmJ0?= =?utf-8?B?TFBQcTNmb0phUFNwQ1FseW1HT3dCZDNjeXdvazk1a1JvdmgvUGVsc0VJeVZV?= =?utf-8?B?TGR2N2wwL2wvQ0h2OVlqbitJZW5DRUhiWHhNWUh0eHVBSk0zNnFqTlRHVk5V?= =?utf-8?B?NXNNMkJ4YU9pY0xXZVM2Ry9TUUhXbWNCNVY0b1JxV1NUUXlteGg1aEdobWcz?= =?utf-8?B?Q00rQ0pNRVp0VXQySnVsR21EeG1NVTdJQWd6dEtBOXFNNjlhaWphMDBUajZv?= =?utf-8?B?RkxWelRNWHpUZS9nN0pEazFlWFhTd2dJYVM0Z0pEVkhNWEtud1JOZmdZNmM0?= =?utf-8?B?MFhjTHJGUThqQ1A5ZjloRUZTS2w4SHJWVUh5UnlJaVNRRlVieG12ZmpERHFP?= =?utf-8?B?SEFBV2tyWVVYakF3d1dBNGloemFkNU45WjFXN0dhK2xkSE5tYUd6a1A2YzJw?= =?utf-8?B?NU50TmVlZmZMM1RqcEFEOWc3dXgrdGtnRFlJdW9PTDZOR2tqTisxWUovYkxw?= =?utf-8?B?UGhibjB4NHhNN0l3di9BdDZ2TVlTbXNONGY5STdLU3diN1hnYlZZK2hzRUNu?= =?utf-8?B?Z3Q5Q3hMOVJOVkdrdVNBRk1oZkRqODdwYUtOeWM3VHZGaUtaVkZnbS9kNC94?= =?utf-8?B?NzJlMFFldklYcGI0K0dRTms4by9sNHhVSG1GQjdyQm5Oc0lTT1prYVFyZ09W?= =?utf-8?B?WmNxV1BvVkpuUHJ6aG13LzYweEIzQUt0bmNlbHB1cW9HK3Y0UkRSWjViVjlr?= =?utf-8?B?eURGTjNrQk9MR3dCQVNpVHJXUFdYMGMxQjRJeUV6WlJxTFVpQVNaNlNKcEh0?= =?utf-8?B?cC9HbmpmbEY4S2xRc2M1cmg0ak5WaEdPSnZycjVBTTVGUFJHcGhFc2lyVDRJ?= =?utf-8?B?cmVDWkw5cUY4QjBkUkdLbmpYaGo4bHZvZzJld1BNS2dkOTJrM3lYcGt2ODVE?= =?utf-8?B?b0syMklvaE4yUFlORjRQR2NXOGR5K1NjZFN0Rk5mcm1QWlVqTXh5blVQUnFZ?= =?utf-8?B?OHVBQUF5MlBhdXNVNHBGNU1UY0Q0MUNGeWFIVUMxNUVhOXdZNDlMWkVtUG8r?= =?utf-8?B?bFlHcjQxWFdnVzNMc3dnUTdMZm9MeFlTU3JLeUs3Y3dkOGtzdlVtbThySDRC?= =?utf-8?B?VTlZY2ZldzNlM3dZVVR0ZGxHK3kzeTNzYjVON01UWEdoZGx0V1htRW1LaFpT?= =?utf-8?B?YUxIWWQrL0psQ2ROM0xXVmhaSzVZZFgxcjBpZGYyQUU5dGE2dllIeS9zU282?= =?utf-8?B?eTlDbTN3U2lnM1Jya3dYaHpSM1JEclc0MGpOZFdSRWsxMi9KVkRkbGo3QWZo?= =?utf-8?B?bFBtZkN4WVhuQlRKZ0JMSGkvSGs2RmFuV3cyMVk5OFREc09qcWVDRHpDQnRS?= =?utf-8?B?dzVHZk9WZVlNZDRlUy8yanRxbnp2cnB3R1BQeDkybmlVajlidHZXUmpLUVVv?= =?utf-8?B?TG1XVjM1TitXRUg4Tm5SQmZXM0krVUV5L1g4WkkzZGdySmltODFESXUyTnZL?= =?utf-8?B?Zk1pdlNvbXhtMVFTWitMVUZLd1dXanBYdURvdEVXQWJRczJoY0RzWExkWjcr?= =?utf-8?B?LzNIaXNjN3AxbzE4eFpMYlFITE9MMGk5RUpXZ0c3TFFvUmdBbXNkOFhBb3RC?= =?utf-8?B?UytOSmVBVVZGZUhRT2NVbW5GZVFnU1RIbFJScmYxS3FvUllXY3B3WnR1V3pz?= =?utf-8?B?K2NTNFdNOGdYR3ZmcW83S2h3a2h6UDEvZVZlcWpYb0ZrbEdNK3hWeHhaaTBk?= =?utf-8?B?VGVhMGJwUjRDME1aZ0hCVklzTGFycEIrQ0JpaHZhYUZTbnl1MnJaYVdlejRq?= =?utf-8?B?YmxnTW40ZG9uTG5VZzFnRW1lc01zSlJzb2F1ZjE4cUxxYUkyOGZyVFppL1lF?= =?utf-8?B?R3lHZDc2aHpzMDhNSDI0QVdlZVo3Z0hFdkRpeDRhNHJobW5URFIwdG9Cc1J1?= =?utf-8?B?bXYxZ1ExTDlFanJuTFBDbVNaNWNEUzBueW5zMnR6UGR2QlJzaXBQamVSRENK?= =?utf-8?B?NS9TdFowdThzcHQ1aGdRNTBydkZBdkJ3MWdRNTdUbW1lYyt6UzNlUlYxM21y?= =?utf-8?B?WEJEcGF2bFNUcGxhNHF2cyt4ZjNXcWkzaXhEeGNuWHY4N2VUUnZyek5RYVcr?= =?utf-8?B?dFM3cDBxUDNrT3VZL2g3THRKc3JnRlFLZktLM0xEaFFvbmFmNG9tclhabXlS?= =?utf-8?B?OHNJNkgyaG9YcTYyN1YzRjNkU0s0U1Zwb1BZWDk2M2QwQ09YNjJ1a2llZG5j?= =?utf-8?B?OW1OZFBMMWY2K3F6bUI3ZzhKK0xiTzNiRzM0Nml5Q2J2OERDbEh4SDlLTGNk?= =?utf-8?Q?sP58VvXTp60UtNG4=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <1567C436B2EE894A99BA9C9E6BF061CD@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR03MB10263.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68153dc8-4ab6-4ab4-78d9-08df0fd5f960 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 07:26:19.5647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: J+XFgyOFhEDz9892dlLb45oY4BExYLlSNt5jazHeYfF9xVRqVdvRAOgsrjJ31BtOpWlQtgB12dIHff+OSa1ZMe9LV6abQSPPzqaMIKCAUS4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB8025 X-purgate-ID: tlsNG-ef75cf/1789111582-350CDAE4-88A16845/0/0 X-purgate-type: clean X-purgate-size: 11232 RnJvbTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KDQpB ZGQgY2hhaW5lZCBoYW5kbGluZyBvZiBhc3NpZ25lZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQgYWNj ZXNzLWNvbnRyb2xsZXINCmZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3b3JrLCBzbyBh IERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUNCnBhc3NlZCB0byBmaXJtd2FyZSBmb3Ig cHJvY2Vzc2luZyBhbmQgZW5hYmxpbmcgVk0gYWNjZXNzIHRvIHRoZSByZXF1ZXN0ZWQNCmRldmlj ZSAoZm9yIGV4YW1wbGUsIGRldmljZSBwb3dlciBtYW5hZ2VtZW50IHRocm91Z2ggU0NNSSkuDQoN ClRoZSBTQ0kgYWNjZXNzLWNvbnRyb2xsZXIgRFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2FsbGVk IGJlZm9yZSB0aGUgSU9NTVUNCnBhdGguIEl0IHJ1bnMgZm9yIGFueSBEVC1kZXNjcmliZWQgZGV2 aWNlIChwcm90ZWN0ZWQgb3Igbm90LCBhbmQgZXZlbiB3aGVuDQp0aGUgSU9NTVUgaXMgZGlzYWJs ZWQpLiBUaGUgSU9NTVUgcGF0aCByZW1haW5zIHVuY2hhbmdlZCBmb3IgUENJIGRldmljZXM7DQpv bmx5IHRoZSBEVCBwYXRoIGlzIHJlbGF4ZWQgdG8gcGVybWl0IG5vbi1JT01NVSBkZXZpY2VzLg0K DQpUaGlzIGxldHMgeGwuY2ZnOiJkdGRldiIgbGlzdCBib3RoIElPTU1VLXByb3RlY3RlZCBhbmQg bm9uLXByb3RlY3RlZCBEVA0KZGV2aWNlczoNCg0KZHRkZXYgPSBbDQogICAgIi9zb2MvdmlkZW9A ZTZlZjAwMDAiLCA8LSBJT01NVSBwcm90ZWN0ZWQgZGV2aWNlDQogICAgIi9zb2MvaTJjQGU2NTA4 MDAwIiwgPC0gbm90IElPTU1VIHByb3RlY3RlZCBkZXZpY2UNCl0NCg0KVGhlIGNoYW5nZSBpcyBk b25lIGluIHR3byBwYXJ0czoNCjEpIGNhbGwgc2NpX2RvX2RvbWN0bCgpIGluIGRvX2RvbWN0bCgp IGJlZm9yZSBJT01NVSBwcm9jZXNzaW5nLiBJZg0Kc2NpX2RvX2RvbWN0bCgpIHJlcG9ydHMgYW4g ZXJyb3Igb3RoZXIgdGhhbiAtRU5YSU8sIHRyZWF0IGl0IGFzDQphdXRob3JpdGF0aXZlIGFuZCBz a2lwIHRoZSBJT01NVSBwYXRoLiBBIHJldHVybiBvZiAtRU5YSU8gaW5kaWNhdGVzDQp0aGF0IFND SSBkaWQgbm90IGhhbmRsZSB0aGUgcmVxdWVzdCBhbmQgaXMgaWdub3JlZCwgYWxsb3dpbmcgdGhl DQpleGlzdGluZyBJT01NVSBoYW5kbGluZyB0byBydW4gdW5jaGFuZ2VkOw0KMikgdXBkYXRlIGlv bW11X2RvX2R0X2RvbWN0bCgpIHRvIGNoZWNrIGZvciBkdF9kZXZpY2VfaXNfcHJvdGVjdGVkKCkg YW5kDQpub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVS4gaW9t bXVfZG9fcGNpX2RvbWN0bA0KZG9lc24ndCBuZWVkIHRvIGJlIHVwZGF0ZWQgYmVjYXVzZSBpb21t dV9kb19kb21jdGwgZmlyc3QgdHJpZXMNCmlvbW11X2RvX3BjaV9kb21jdGwgKHdoZW4gQ09ORklH X0hBU19QQ0kpIGFuZCBmYWxscyBiYWNrIHRvDQppb21tdV9kb19kdF9kb21jdGwgb25seSBpZiBQ Q0kgcmV0dXJucyAtRU5PREVWLg0KDQpUaGUgbmV3IGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKSBi eXBhc3MgaW4gaW9tbXVfZG9fZHRfZG9tY3RsIG9ubHkNCmFwcGxpZXMgdG8gRFQtZGVzY3JpYmVk IGRldmljZXM7IFNDSSBwYXJhbWV0ZXJzIGFyZSBjYXJyaWVkIHZpYSBEVA0Kbm9kZXMuIFBDSSBk ZXZpY2VzIGhhbmRsZWQgYnkgaW9tbXVfZG9fcGNpX2RvbWN0bCBkbyBub3QgY2FycnkgRFQvU0NJ DQptZXRhZGF0YSBpbiB0aGlzIHBhdGgsIHNvIHRoZXJlIGlzIG5vIG5vdGlvbiBvZiDigJxTQ0kg cGFyYW1ldGVycyBvbiBhDQpub24tSU9NTVUtcHJvdGVjdGVkIFBDSSBkZXZpY2XigJ0gZm9yIGl0 IHRvIGludGVycHJldCBvciB0byBza2lwLiBUaGUgUENJDQpwYXRoIHNob3VsZCBjb250aW51ZSB0 byByZXBvcnQgZXJyb3JzIGlmIGFzc2lnbm1lbnQgY2Fubm90IGJlIHBlcmZvcm1lZA0KYnkgdGhl IElPTU1VIGxheWVyLiBTbyB3ZSBzaG91bGQgbGVhdmUgaW9tbXVfZG9fcGNpX2RvbWN0bCB1bmNo YW5nZWQ7IHRoZQ0KU0NJL0RULXNwZWNpZmljIHJlbGF4YXRpb25zIGJlbG9uZyBvbmx5IGluIHRo ZSBEVCBwYXRoLiBBbHNvIFNDSSBoYW5kbGluZw0Kb25seSBleGlzdHMgd2hlbiBEVCBpcyBwcmVz ZW50Lg0KDQpTaWduZWQtb2ZmLWJ5OiBHcnlnb3JpaSBTdHJhc2hrbyA8Z3J5Z29yaWlfc3RyYXNo a29AZXBhbS5jb20+DQpTaWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldiA8b2xla3NpaV9t b2lzaWVpZXZAZXBhbS5jb20+DQpSZXZpZXdlZC1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzc3Rh YmVsbGluaUBrZXJuZWwub3JnPg0KQWNrZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4NCi0tLQ0KDQpDaGFuZ2VzIGluIHYxMjoNCi0gcmViYXNlIHRvIHRoZSBsYXRlc3Qgc3Rh Z2luZw0KLSBhZGQgUi1CcyBmcm9tIFN0ZWZhbm8gYW5kIEFjayBmcm9tIEphbg0KDQpDaGFuZ2Vz IGluIHYxMDoNCi0gcmVtb3ZlIHVudXNlZCBzY2lfZG9fZG9tY3RsIHN0dWIgZnJvbSBzY2kuaA0K DQpDaGFuZ2VzIGluIHY5Og0KLSB0cmVhdCBTQ0kgYXMgYSBnYXRlIGZvciBYRU5fRE9NQ1RMXyph c3NpZ25fZGV2aWNlOiBhYm9ydCBiZWZvcmUNCklPTU1VIGlmIHNjaV9kb19kb21jdGwoKSByZXR1 cm5zIGFuIGVycm9yIG90aGVyIHRoYW4gLUVOWElPLCBpbnN0ZWFkDQpvZiB0cnlpbmcgdG8gcHJv cGFnYXRlIFNDSSBlcnJvcnMgYWZ0ZXIgYSBzdWNjZXNzZnVsIElPTU1VDQpvcGVyYXRpb24uIFRo aXMgYXZvaWRzIHBhcnRpYWwgc3VjY2VzcyBhbmQgdGhlIG5lZWQgZm9yIElPTU1VIHJvbGxiYWNr Lg0KLSByZW1vdmUgZWFybHkgcmV0dXJuIGZyb20gZG9fZG9tY3RsKCkgaW4gdGhlIGFzc2lnbl9k ZXZpY2UNCnBhdGggdG8ga2VlcCBSQ1UgaGFuZGxpbmcgaW50YWN0Lg0KLSBjaGFuZ2UgSVNfRU5B QkxFRCgqKSB0byAjaWZkZWYgaW4gc2NpX2RvX2RvbWN0bCBxdWFyZA0KDQpDaGFuZ2VzIGluIHY4 Og0KLSBjaGVjayBmb3IgQ09ORklHX0FSTV9TQ0kgdG8gYmUgZWJhYmxlZCBpbnN0ZWFkIG9mIENP TUZJR19BUk0gYmVmb3JlDQpjYWxsaW5nIHNjaV9kb19kb21jdGwNCi0gcmV3b3JrIHNjaV9kb19k b21jdGwgY2FsbCB0byBhdm9pZCBleHRyYSBjaGVja3MsIGltcHJvdmVkIGVycm9yDQpoYW5kbGlu Zy4NCi0gZG8gbm90IHByb3BhZ2F0ZSByZXQxIGlmIHNjaV9kb19kb21jdGwgcmV0dXJuZWQgcG9z aXRpdmUgcmV0DQotIHVwZGF0ZWQgY29tbWVudCBpbiBkb21jdGwuYyBjb2RlDQoNCkNoYW5nZXMg aW4gdjc6DQotIHVwZGF0ZSBkb21jdGwgdG8gYnVpbGQgb24gYm90aCBBcm0gYW5kIHg4NiBwbGF0 Zm9ybXMNCi0gbW92ZSByZXQxIGRlY2xhcmF0aW9uIHRvIHRoZSB0b3Agb2YgdGhlIGZ1bmN0aW9u IGFzIHJlcXVpcmVkIGJ5IGNvZGUNCnN0eWxlDQoNCkNoYW5nZXMgaW4gdjY6DQotIGNoYW5nZSBp b21tdV9kb19kb21jdGwgYW5kIHNjaV9kb19kb21jdGwgY29tbWFuZCBvcmRlciBhbmQNCmNhbGwg c2NpX2RvX2RvbWN0bCBmaXJzdCB3aGljaCB3aWxsIHByb2R1Y2UgY2xlYW5lciBjb2RlIHBhdGgu DQpBbHNvIGRyb3BwZWQgY2hhbmdpbmcgcmV0dXJuIGNvZGUgd2hlbiBpb21tdSB3YXMgZGlzYWJs ZWQgaW4NCmlvbW11X2RvX2RvbWN0bC4NCg0KQ2hhbmdlcyBpbiB2NToNCi0gcmV0dXJuIC1FSU5W QUwgaWYgbWVkaWF0b3Igd2l0aG91dCBhc3NpZ25fZHRfZGV2aWNlIHdhcyBwcm92aWRlZA0KLSBp bnZlcnQgcmV0dXJuIGNvZGUgY2hlY2sgZm9yIGlvbW11X2RvX2RvbWN0bCBpbg0KWEVOX0RPTUNU TF9hc3NpZ25fZGV2aWNlIGRvbWN0bCBwcm9jZXNzaW5nIHRvIG1ha2UgY2xlYW5lciBjb2RlDQot IGNoYW5nZSAtRU5PVFNVUFAgZXJyb3IgY29kZSB0byAtRU5YSU8gaW4gc2NpX2RvX2RvbWN0bA0K LSBoYW5kbGUgLUVOWElPIHJldHVybiBjb21kZSBvZiBpb21tdV9kb19kb21jdGwNCi0gbGVhdmUg IWR0X2RldmljZV9pc19wcm90ZWN0ZWQgY2hlY2sgaW4gaW9tbXVfZG9fZHRfZG9tY3RsIHRvIG1h a2UNCmNvZGUgd29yayB0aGUgc2FtZSB3YXkgaXQncyBkb25lIGluICJoYW5kbGVfZGV2aWNlIiBj YWxsIHdoaWxlDQpjcmVhdGluZyBod2RvbShkb20wKSBhbmQgImhhbmRsZV9wYXNzdGhyb3VnaF9w cm9wIiBjYWxsIGZvciBkb20wbGVzcw0KY3JlYXRpb24NCi0gZHJvcCByZXR1cm4gY2hlY2sgZnJv bSBzY2lfYXNzaWduX2R0X2RldmljZSBjYWxsIGFzIG5vdCBuZWVkZWQNCi0gZG8gbm90IHJldHVy biBFSU5WQUwgd2hlbiBhZGRpZ25fZHRfZGV2aWNlIGlzIG5vdCBzZXQuIFRoYXQgaXMNCmJlY2F1 c2UgdGhpcyBjYWxsYmFjayBpcyBvcHRpb25hbCBhbmQgbm90IGltcGxlbWVudGVkIGluIHNpbmds ZS1hZ2VudCBkcml2ZXINCg0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYyAgICAgICAgICAg ICB8IDM2ICsrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9h c20vZmlybXdhcmUvc2NpLmggfCAgOCArKysrKysNCiB4ZW4vY29tbW9uL2RvbWN0bC5jICAgICAg ICAgICAgICAgICAgICAgfCAxNSArKysrKysrKysrKw0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo L2RldmljZV90cmVlLmMgICB8ICA2ICsrKysrDQogNCBmaWxlcyBjaGFuZ2VkLCA2NSBpbnNlcnRp b25zKCspDQoNCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMgYi94ZW4v YXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCmluZGV4IGFhOTNjZGE3ZjAuLmE2YzY0N2EwOWQgMTAw NjQ0DQotLS0gYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCisrKyBiL3hlbi9hcmNoL2Fy bS9maXJtd2FyZS9zY2kuYw0KQEAgLTEyNiw2ICsxMjYsNDIgQEAgaW50IHNjaV9hc3NpZ25fZHRf ZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2KQ0KICAg ICByZXR1cm4gMDsNCiB9DQogDQoraW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwg KmRvbWN0bCwgc3RydWN0IGRvbWFpbiAqZCwNCisgICAgICAgICAgICAgICAgICBYRU5fR1VFU1Rf SEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQorew0KKyAgICBzdHJ1Y3QgZHRf ZGV2aWNlX25vZGUgKmRldjsNCisgICAgaW50IHJldCA9IDA7DQorDQorICAgIHN3aXRjaCAoIGRv bWN0bC0+Y21kICkNCisgICAgew0KKyAgICBjYXNlIFhFTl9ET01DVExfYXNzaWduX2RldmljZToN CisgICAgICAgIHJldCA9IC1FTlhJTzsNCisgICAgICAgIGlmICggZG9tY3RsLT51LmFzc2lnbl9k ZXZpY2UuZGV2ICE9IFhFTl9ET01DVExfREVWX0RUICkNCisgICAgICAgICAgICBicmVhazsNCisN CisgICAgICAgIGlmICggIWN1cl9tZWRpYXRvciApDQorICAgICAgICAgICAgYnJlYWs7DQorDQor ICAgICAgICBpZiAoICFjdXJfbWVkaWF0b3ItPmFzc2lnbl9kdF9kZXZpY2UgKQ0KKyAgICAgICAg ICAgIGJyZWFrOw0KKw0KKyAgICAgICAgcmV0ID0gZHRfZmluZF9ub2RlX2J5X2dwYXRoKGRvbWN0 bC0+dS5hc3NpZ25fZGV2aWNlLnUuZHQucGF0aCwNCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkb21jdGwtPnUuYXNzaWduX2RldmljZS51LmR0LnNpemUsICZkZXYpOw0KKyAg ICAgICAgaWYgKCByZXQgKQ0KKyAgICAgICAgICAgIHJldHVybiByZXQ7DQorDQorICAgICAgICBy ZXQgPSBzY2lfYXNzaWduX2R0X2RldmljZShkLCBkZXYpOw0KKw0KKyAgICAgICAgYnJlYWs7DQor DQorICAgIGRlZmF1bHQ6DQorICAgICAgICAvKiBkbyBub3QgZmFpbCBoZXJlIGFzIGNhbGwgaXMg Y2hhaW5lZCB3aXRoIGlvbW11IGhhbmRsaW5nICovDQorICAgICAgICBicmVhazsNCisgICAgfQ0K Kw0KKyAgICByZXR1cm4gcmV0Ow0KK30NCisNCiBzdGF0aWMgaW50IF9faW5pdCBzY2lfaW5pdCh2 b2lkKQ0KIHsNCiAgICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpucDsNCmRpZmYgLS1naXQgYS94 ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmggYi94ZW4vYXJjaC9hcm0vaW5j bHVkZS9hc20vZmlybXdhcmUvc2NpLmgNCmluZGV4IDQ4NWNlMjExYzkuLjNiNGIzZGY3NzAgMTAw NjQ0DQotLS0gYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmgNCisrKyBi L3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KQEAgLTE0Niw2ICsxNDYs MTQgQEAgaW50IHNjaV9kdF9maW5hbGl6ZShzdHJ1Y3QgZG9tYWluICpkLCB2b2lkICpmZHQpOw0K ICAqIGNvbnRyb2wiIGZ1bmN0aW9uYWxpdHkuDQogICovDQogaW50IHNjaV9hc3NpZ25fZHRfZGV2 aWNlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2KTsNCisNCisv Kg0KKyAqIFNDSSBkb21jdGwgaGFuZGxlcg0KKyAqDQorICogT25seSBYRU5fRE9NQ1RMX2Fzc2ln bl9kZXZpY2UgaXMgaGFuZGxlZCBmb3Igbm93Lg0KKyAqLw0KK2ludCBzY2lfZG9fZG9tY3RsKHN0 cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVjdCBkb21haW4gKmQsDQorICAgICAgICAgICAg ICAgICAgWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9tY3RsX3QpIHVfZG9tY3RsKTsNCiAj ZWxzZQ0KIA0KICNpbmNsdWRlIDxwdWJsaWMvYXJjaC1hcm0uaD4NCmRpZmYgLS1naXQgYS94ZW4v Y29tbW9uL2RvbWN0bC5jIGIveGVuL2NvbW1vbi9kb21jdGwuYw0KaW5kZXggYTYyMTBkYjRmYi4u NGU0MGQ0M2E3MiAxMDA2NDQNCi0tLSBhL3hlbi9jb21tb24vZG9tY3RsLmMNCisrKyBiL3hlbi9j b21tb24vZG9tY3RsLmMNCkBAIC0yOSw2ICsyOSw5IEBADQogI2luY2x1ZGUgPHhlbi94dm1hbGxv Yy5oPg0KIA0KICNpbmNsdWRlIDxhc20vY3VycmVudC5oPg0KKyNpZmRlZiBDT05GSUdfQVJNDQor I2luY2x1ZGUgPGFzbS9maXJtd2FyZS9zY2kuaD4NCisjZW5kaWYNCiAjaW5jbHVkZSA8YXNtL2ly cS5oPg0KICNpbmNsdWRlIDxhc20vcGFnZS5oPg0KICNpbmNsdWRlIDxhc20vcDJtLmg+DQpAQCAt OTIxLDYgKzkyNCwxOCBAQCBsb25nIGRvX2RvbWN0bChYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhl bl9kb21jdGxfdCkgdV9kb21jdGwpDQogICAgIGNhc2UgWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNl Og0KICAgICBjYXNlIFhFTl9ET01DVExfdGVzdF9hc3NpZ25fZGV2aWNlOg0KICAgICBjYXNlIFhF Tl9ET01DVExfZGVhc3NpZ25fZGV2aWNlOg0KKyAgICAgICAgLyoNCisgICAgICAgICAqIENoYWlu IFNDSSBEVCBoYW5kbGluZyBhaGVhZCBvZiB0aGUgSU9NTVUgcGF0aCBzbyBhbiBTQ0kgbWVkaWF0 b3INCisgICAgICAgICAqIGNhbiBhdXRob3Jpc2UgYWNjZXNzLWNvbnRyb2xsZWQgRFQgZGV2aWNl cy4gVW5oYW5kbGVkIGNhc2VzIHJlcG9ydA0KKyAgICAgICAgICogLUVOWElPLCB3aGljaCBpcyBp Z25vcmVkLiBBbnkgb3RoZXIgU0NJIGVycm9yIGFib3J0cyBiZWZvcmUgdGhlDQorICAgICAgICAg KiBJT01NVSBwYXRoIHJ1bnMuDQorICAgICAgICAgKi8NCisjaWZkZWYgQ09ORklHX0FSTV9TQ0kN CisgICAgICAgIHJldCA9IHNjaV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3RsKTsNCisgICAgICAg IGlmICggcmV0IDwgMCAmJiByZXQgIT0gLUVOWElPICkNCisgICAgICAgICAgICBicmVhazsNCisj ZW5kaWYNCisNCiAgICAgICAgIHJldCA9IGlvbW11X2RvX2RvbWN0bChvcCwgZCwgdV9kb21jdGwp Ow0KICAgICAgICAgYnJlYWs7DQogDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91 Z2gvZGV2aWNlX3RyZWUuYyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMN CmluZGV4IGFiMWUwN2FjOTkuLjdjNGNmMjdkMzIgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy9w YXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jDQorKysgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9k ZXZpY2VfdHJlZS5jDQpAQCAtMzc5LDYgKzM3OSwxMiBAQCBpbnQgaW9tbXVfZG9fZHRfZG9tY3Rs KHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVjdCBkb21haW4gKmQsDQogICAgICAgICAg ICAgYnJlYWs7DQogICAgICAgICB9DQogDQorICAgICAgICBpZiAoICFkdF9kZXZpY2VfaXNfcHJv dGVjdGVkKGRldikgKQ0KKyAgICAgICAgew0KKyAgICAgICAgICAgIHJldCA9IDA7DQorICAgICAg ICAgICAgYnJlYWs7DQorICAgICAgICB9DQorDQogICAgICAgICByZXQgPSBpb21tdV9hc3NpZ25f ZHRfZGV2aWNlKGQsIGRldik7DQogDQogICAgICAgICBpZiAoIHJldCApDQotLSANCjIuNDMuMA0K From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:26:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:26:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415786.1645016 (Exim 4.92) (envelope-from ) id 1x4veS-0003FN-Kj; Fri, 11 Sep 2026 07:26:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415786.1645016; Fri, 11 Sep 2026 07:26:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veS-0003EM-FH; Fri, 11 Sep 2026 07:26:24 +0000 Received: by outflank-mailman (input) for mailman id 1415786; Fri, 11 Sep 2026 07:26:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veR-00036T-IE for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:26:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4veQ-001KmU-UL for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:26:22 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ad17-e002-0a2a0a5209dd-0a2a4507c276-20 for ; Fri, 11 Sep 2026 09:26:22 +0200 Received: from [52.101.70.117] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ad1d-b4ea-0a2a45070019-3465467530e0-5 for ; Fri, 11 Sep 2026 09:26:22 +0200 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com (2603:10a6:10:519::5) by AM9PR03MB8025.eurprd03.prod.outlook.com (2603:10a6:20b:43c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:26:20 +0000 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908]) by DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908%5]) with mapi id 15.21.0406.005; Fri, 11 Sep 2026 07:26:20 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tZEGvXD53Jo1RdSsy9s8JKQwSQm/FOCAO3Zq6LsLPYJZ9quTeqZptEqHzkHgTuEFngsgPRPw49lXV2Nu0RJOvc6bzV9qUz2wo+muDtcmEZjoNJdlKoEGD0xU3hh1UjHZeE60mwhH7usdHwm0nciJxLkBxNnRd9N1RXdJh6bKHrEn8nU6x816yD/4GI77jtXy3FIJj0zHDLn2fQYLhJtiWixobXdCMPBbxskLv7BWVaouxRLTjz1J1li4YvZ+HMzQiMsIIet4aszklolmJi/nuxff5QEPqsh6QdLI9sLOpTebF2TMl626dAezTlqeC6jiOZ4ZeqrS3gcTyAEHfSZPZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ej35jXrH9F2Cgm3HWS9Pvfb26eAYGC6ez9jDhksRBPQ=; b=kB3zgg5b1QpukN6CjWGVMPVIgD0vvIh/ua2cpXhscZh/I4jizEWQGFvSFkoNhIePcbkS+lJTYtuXELEOIumgxoU2mJnQaCuiQnrt2eaLSjsa43A0UbxnJ/iVI3rxpOWldXd0P3uIyUO/zK+3o2ttCAjCNtUWW6TkEF7GkdF7tpXNXwCEfJ9xHUX4Y910DFpqmcxExvc4adCKYMdq1T/QVY58NjUB5bXQe5fx/Ktih5Qf1FYLzgrvcZKk8UWvGmDgdSLUeBgrY0dxIacH4WdpD0w7zQNCJN0JVw8KsgIdnHmrmVLvZjdwmOqjv8B4eK2EUSbGrxi/A+vA6NHrc2hTvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ej35jXrH9F2Cgm3HWS9Pvfb26eAYGC6ez9jDhksRBPQ=; b=swIhuMvI7gLAQCfaxRF2iu6xNdjTsXDFa6QCuMGlvob67UTlVQu9KVbp6wvyqHiv3viVsMfdD8K6cw1tzn9lu7mJ4V8ZFGFO4JbWilUOGrkVDuEPoZVVlJUmHMuLJE/Z6ySZWp0WXn8Ex7Uzah+261o29qLh7Mf2kaYKsp2IxH+8QLyCRDwhjP0FJJRN3F3kVRtd8SeL9hjFJhQGHAlyiatqt6DDA3yNpldDmCtapUEq/vkH1PynCeOwaGL1HqxXvCfnfH0dpRlgcloL15gpUKCdc3diFpPSRRfS3UkobzBqm378rQLOoVbaS7IKlCfUeQtHj0ZgNrJ8e87brqSkzA== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers Thread-Index: AQHdQb7XwQvbnxLqDEGK19PLXXgaew== Date: Fri, 11 Sep 2026 07:26:20 +0000 Message-ID: <6bf8f9dd61da4d0fbea096b863f51db08df46c56.1789055542.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR03MB10263:EE_|AM9PR03MB8025:EE_ x-ms-office365-filtering-correlation-id: 14479ef4-56a3-43f6-d369-08df0fd5f9ca x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|10067099003|6133799003|18002099003|22082099003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: /Any2wm0K3F1eSgh7+5mLMMrtKTeWulnGxApORo+9NBD+T7p66AV0ojwc6SWlAIRTygefuvhKCFCByFb7bnAQampp7hUSn2vdRRe5oik9+X50+cwNwdpe74JFEjERJ8DJnRWcOwQ9QNPYpdwIv5OtlWSyFw1J7dYcFx4Mz5+UMGRnul3sgRAojz83MQt8Dy6tXkZ0ax2/qHQCqo1+W5dmkgQ3wlCzlCM1IaLoubaalrvDxGt0ILX0kYZMU2TB9UIhf4xxLE5zxOYV3jj7e+QdCedpQ6D8b/cuO4V2n69whZgX9HaLvGVLDRdyB2kI5gJ0M6ec8ufUtj58rt06/NS5N0sGBgZHK2yETV7eFEDD5RL7kEcBWxKVAFbsfU/fJr8t4Gyn1JubZ9oc5RnjoluDRq8aHAQHoM047FeCU+6NbPL5AoirnpkR0ruwuKt1j1WRdH+OtxRZ983jRMkuha6+QUwqmN+mIGh7F3MhTRSydEhH5qetJ3QPLalQiSD86tf2habqP2frmp255pM3uM7QwbE4vMdn0D68L4Y3eIZYHVQhE1z5+pqNa1VkDk0lg7XzJsvR3uwgTcc3LfjMsV/t3WMz9WCmqaX/tlk3TfCizjSYcFF055T3yf+Cxwr/QOThlGmNA3cdlbQEkaCIVZF4yAYzuHbHAN222N9S8KyPShsIPfhxiHFl1IkKn6LfnROccXwOoV0eZaVRVRuuQmq9nQ3M575rT/KsyYEQLLaliA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10263.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(10067099003)(6133799003)(18002099003)(22082099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?emnrZ+LMu2WA2ElvjGAdfurkPE+3oIkwN0Ye59NXFn9bOxhiNpZ+2B2Ujp?= =?iso-8859-1?Q?t6FylnA3OW/ELhiFNh0bmFL18+iGsZmvaYkDCxIg2OUzNCsw33Bwzs+2FE?= =?iso-8859-1?Q?ddERfNXVCiLl7sE+WsV4trjPX1nRgryd3n6hulXtT50CCgq9pSAPyoWfRI?= =?iso-8859-1?Q?8nOdrST0mFXnHYD4tYJdvX9snC0tMe+4ewxnq0GMDfw4FhnM645m6/yzrN?= =?iso-8859-1?Q?GhnUVWfnJkEkzc9Pqgpbcrqts0ErKTqmHwO57VLmljrueZ6soNa4M9QVRB?= =?iso-8859-1?Q?EY2tqZ91ysOVi1wVQMeBS4s+P0w4PwFamTvlQKRvDEYQfOvPuf4M0JeCXU?= =?iso-8859-1?Q?gXrv7KHUByvAaMJleazMim5U03IMsTUEnXiMXX0dVs3EPfPSYcFSM5ApJU?= =?iso-8859-1?Q?XQqhi0100j+CrVsrIW9JDK0rL6Gk8WoOWH5CMPrnY9P0KPhzjShnCthaX0?= =?iso-8859-1?Q?hYG+1vFzJMJTfcWK6FxFazwDAQuGEFdHY4ERdGJ1UL2yDt35LGsyYeASUd?= =?iso-8859-1?Q?p9TVN3cHwIXG4DDyWB2dnRbkcOFaKQeyMS82wIX/Tq7Q5TsUxzlfKL9WaJ?= =?iso-8859-1?Q?ty0gJpkggs4C5wAsiSuVF/O34Gqk9Hu1BNYIwMrZPPeDy8FfVUWd4s9J3R?= =?iso-8859-1?Q?V8AWE5lPZvmJlDtFQeDivEruL2l3X99QCZm/D/38n7bonDp0iI4AWMpeMb?= =?iso-8859-1?Q?gm/SxOiZa3aXIIXHexEdYal6XBb1xo3Z2nfTU79ljGgte7zE19KeOHrJX2?= =?iso-8859-1?Q?4KmWm1PnleXNyX6WkE//JXaTA64uBrY7iP++zzWic2cubr+4dLxZW9eQVT?= =?iso-8859-1?Q?zO+u0o9vw+sWyOv/k8xjLDErWAgNclQN24qcBr5gxcTjQcht9mSNFdiv5b?= =?iso-8859-1?Q?iZmDiv9IziAVgQr7cmyleE5YtoxFCm2xcPakDtr7ezlGgJFRFqLe+s4gnb?= =?iso-8859-1?Q?RLvWwI/m28LtkW3q0LrXIKYhMVJfXSsqCXQ9ye/hENDyDZiYauQyb0Ee6D?= =?iso-8859-1?Q?1BIrAsNVcjyMFcrkvDRxbulZB93b9XPw66zHYGTAlRPRniVon5MBI52596?= =?iso-8859-1?Q?lb3eCKGsdVoYJ++0DWom8OfudqgQSFiWy09lYKEutgxWvvhA6V+LVCnu9X?= =?iso-8859-1?Q?59r+Vt6Z7jEJWfKKBw3+z89rl+SWDWeVcMms6Z8quHU0GuSiWBcbsjszzt?= =?iso-8859-1?Q?B5xKZSoktgh/z9R0iVrcdTMspfvJt1Ecw6QtVQSrNoBsLSwDlxIQV/EhuY?= =?iso-8859-1?Q?V2r54tcQ1hdo69D0rETtsdR/NAmUNeaIzaLYj19mGidCFKaIOdZOhmyrv0?= =?iso-8859-1?Q?hwHO9/BHvDE78E9N1QnB80u5tCFIv1HIY9CnXFl8ECXnRiLQoaTZjEmRYK?= =?iso-8859-1?Q?GdNUXYa3fZMoKKXodn0atikKnbrVEzoTXuSVvXAW5ay3+b7qx3nKS/5wKo?= =?iso-8859-1?Q?gNPoM+8HnWo/GdsnIZEhiiyHjRizckVIzZUH25stIIvMJnKSG2AdBH26n4?= =?iso-8859-1?Q?rkZdeRH8a50583cJNtxERhbPi7EsCkomzG/eFPyEtNYtOYmKL2d2NN3gAo?= =?iso-8859-1?Q?AEq0lvdQuvtub08/6k5KeATZfpM7u9Zzcht3x3GefaqAZCBADOFySgEvLb?= =?iso-8859-1?Q?nfSKUZ4WlzdGvym8opV1YY/BcMmkKCGMCXZX0H77C0FQSyvBJsyo7XezbE?= =?iso-8859-1?Q?06ku1JK+h0rzqk4Wns0qc1yGaqrPwEOmErSWF81YPs+4qwgDp/DUbTRD0P?= =?iso-8859-1?Q?5HZtlPx5yzuRiPrTRPusOVJfC0bNJM8tOAkxGxdS2DMpDeIIDJgoNra4/B?= =?iso-8859-1?Q?dUuT6B5n7nMpikLbuGKK7P8bOZtg2xI=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR03MB10263.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14479ef4-56a3-43f6-d369-08df0fd5f9ca X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 07:26:20.2723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2Su+lf2zuaHt0ltVyvyQtf3Sf29oQtQ7nnJwQWlWr9N8ot6MH2eTcg7TVwPC0PhfVeQENEAgc6KXlgbvpHmtjvtUIWegCjP7I2ZLONlM/u0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB8025 X-purgate-ID: tlsNG-ef75cf/1789111582-3C610AE4-7128A54C/0/0 X-purgate-type: clean X-purgate-size: 8704 Introduce memcpy_fromio() and memcpy_toio() helpers to copy between regular memory and MMIO space on Arm. The generic prototypes live in io.h so other architectures can provide their own implementations. These helpers handle alignment safely by using ordered byte accesses for any leading/trailing unaligned bytes and ordered 32-bit accesses for the aligned bulk transfer. Using the ordered `readb/readl` and `writeb/writel` accessors avoids unintended endianness conversion while respecting device ordering requirements on ARM32/ARM64 hardware that may not support 64-bit MMIO atomically. The interface lives in the generic header so other architectures can provide their own implementations (as macros or functions). The ARM implementation is placed under `arch/arm/lib/` (mirroring the x86 reference layout) and is split into separate compilation units added via the architecture-specific lib Makefile. Signed-off-by: Oleksii Moisieiev Reviewed-by: Stefano Stabellini --- Changes in v12: - Add missed R-B - correct the Emacs footer of both files, which asked for 8 column tab indentation while the code is in 4 column Xen style Changes in v10: - removed extra include in memcpy-{to/from}io.c files Changes in v9: - reword commit description to refer to memcpy_fromio and memcpy_toio - ordering obj-y in Makefile - rename ALL_LIBS to ARCH_LIBS - drop io.h and move definitions to the common header, fix comments to be arch neutral - update comments for memcpy_{from/to}io implementation Changes in v8: - switched to ordered accessors to address the ordering and barrier concerns. - updated the documentation to match the implementation and explicitly state the supported access sizes and granularity. - rename memcpy_* implementation files to memcpu-* to follow naming convension - fix indentation to match Xen style - fix intendation to match Xen style - move memcpy-{from/to}io to more convenient library place Changes in v7: - x86 guidance: removed the speculative note; header now just says each arch supplies its own implementation or macro. - name spacing: dropped the double-underscore; the helpers are now memcpy_fromio / memcpy_toio. The header also explicitly allows an arch to define these as macros before including it. - updated io.c to keep 32-bit transfers safe on arm32 - moved to __raw_read*/__raw_write* accessors to avoid endianness conversio= n. - split the helpers into separate compilation units Changes in v6: - sorted objs in Makefile alhabetically - added newline at the end of Makefile - used uint{N}_t intead of u{N} - add comment about why 32 bit IO operations were used - updated cast opertaions to avoid dropping constness which is wrong - move function definitions to generic place so the could be reused by other arch - add SPDX tag to io.c Changes in v5: - move memcpy_toio/fromio to the generic place xen/arch/arm/Makefile | 1 + xen/arch/arm/arch.mk | 1 + xen/arch/arm/lib/Makefile | 2 ++ xen/arch/arm/lib/memcpy-fromio.c | 55 ++++++++++++++++++++++++++++++++ xen/arch/arm/lib/memcpy-toio.c | 55 ++++++++++++++++++++++++++++++++ xen/include/xen/io.h | 10 ++++++ 6 files changed, 124 insertions(+) create mode 100644 xen/arch/arm/lib/Makefile create mode 100644 xen/arch/arm/lib/memcpy-fromio.c create mode 100644 xen/arch/arm/lib/memcpy-toio.c diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index b7afd3e58c..e448e69014 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -8,6 +8,7 @@ ifneq ($(CONFIG_NO_PLAT),y) obj-y +=3D platforms/ endif obj-y +=3D firmware/ +obj-y +=3D lib/ obj-$(CONFIG_TEE) +=3D tee/ obj-$(CONFIG_HAS_VPCI) +=3D vpci.o =20 diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk index dea8dbd18a..009bb22c45 100644 --- a/xen/arch/arm/arch.mk +++ b/xen/arch/arm/arch.mk @@ -2,6 +2,7 @@ # arm-specific definitions =20 ARCH_LIBS-y +=3D arch/arm/$(ARCH)/lib/lib.a +ARCH_LIBS-y +=3D arch/arm/lib/lib.a =20 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) $(call cc-option-add,CFLAGS,CC,-Wnested-externs) diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile new file mode 100644 index 0000000000..07a0d9186c --- /dev/null +++ b/xen/arch/arm/lib/Makefile @@ -0,0 +1,2 @@ +lib-y +=3D memcpy-fromio.o +lib-y +=3D memcpy-toio.o diff --git a/xen/arch/arm/lib/memcpy-fromio.c b/xen/arch/arm/lib/memcpy-fro= mio.c new file mode 100644 index 0000000000..d8d6a5f557 --- /dev/null +++ b/xen/arch/arm/lib/memcpy-fromio.c @@ -0,0 +1,55 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include + +/* + * Arm implementation notes / limitations: + * - Uses ordered 8-bit for leading/trailing unaligned bytes and ordered + * 32-bit accesses for the aligned bulk; no wider accesses are issued. + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; + * do not use with devices requiring strictly 16-bit or 64-bit accesses. + * - MMIO must be mapped with appropriate device attributes to preserve + * ordering; no extra barriers beyond the ordered accessors are added. + * - If source or destination is misaligned, leading bytes are copied + * byte-by-byte until both sides are 32-bit aligned, then bulk copy uses + * 32-bit accesses. + */ + +void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count) +{ + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || + !IS_ALIGNED((unsigned long)to, 4)) ) + { + *(uint8_t *)to =3D readb(from); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + *(uint32_t *)to =3D readl(from); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + *(uint8_t *)to =3D readb(from); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/lib/memcpy-toio.c b/xen/arch/arm/lib/memcpy-toio.= c new file mode 100644 index 0000000000..5115489326 --- /dev/null +++ b/xen/arch/arm/lib/memcpy-toio.c @@ -0,0 +1,55 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include + +/* + * Arm implementation notes / limitations: + * - Uses ordered 8-bit for leading/trailing unaligned bytes and ordered + * 32-bit accesses for the aligned bulk; no wider accesses are issued. + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; + * do not use with devices requiring strictly 16-bit or 64-bit accesses. + * - MMIO must be mapped with appropriate device attributes to preserve + * ordering; no extra barriers beyond the ordered accessors are added. + * - If source or destination is misaligned, leading bytes are copied + * byte-by-byte until both sides are 32-bit aligned, then bulk copy uses + * 32-bit accesses. + */ + +void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count) +{ + while ( count && (!IS_ALIGNED((unsigned long)to, 4) || + !IS_ALIGNED((unsigned long)from, 4)) ) + { + writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + writel(*(const uint32_t *)from, to); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/xen/io.h b/xen/include/xen/io.h index 164a20c5d7..1bb164b6ef 100644 --- a/xen/include/xen/io.h +++ b/xen/include/xen/io.h @@ -67,4 +67,14 @@ static inline bool write_mmio(volatile void __iomem *mem= , unsigned long data, return true; } =20 +/* + * Copy between regular memory and MMIO space. Implementations are + * architecture-specific and must use appropriate MMIO accessors for + * their memory and I/O models. + */ +void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count); +void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count); + #endif /* XEN_IO_H */ --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:26:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:26:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415787.1645032 (Exim 4.92) (envelope-from ) id 1x4veV-0003mf-4s; Fri, 11 Sep 2026 07:26:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415787.1645032; Fri, 11 Sep 2026 07:26:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veV-0003mQ-1j; Fri, 11 Sep 2026 07:26:27 +0000 Received: by outflank-mailman (input) for mailman id 1415787; Fri, 11 Sep 2026 07:26:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veT-0003Nb-3e for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:26:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4veS-001KmU-G8 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:26:24 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ad17-e002-0a2a0a5209dd-0a2a4507c276-26 for ; Fri, 11 Sep 2026 09:26:24 +0200 Received: from [52.101.70.117] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ad1d-b4ea-0a2a45070019-3465467530e0-6 for ; Fri, 11 Sep 2026 09:26:23 +0200 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com (2603:10a6:10:519::5) by AM9PR03MB8025.eurprd03.prod.outlook.com (2603:10a6:20b:43c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:26:20 +0000 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908]) by DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908%5]) with mapi id 15.21.0406.005; Fri, 11 Sep 2026 07:26:20 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XwYuMYDJ3VIiuHK0KW8jUZoHFYksSVPeCJlEVT0MjdTIAErlL+iq/tVikfSgN/bq7Gmqe7gp09hVZDrqsDpRIIh7iZUsN7RP50TDcBBLqdhsg/8ras2Pa6b38aQC7aQxWcCSMKVjIL7Y2rByrVulp3f0XQJ/VgSbJCJEPWKWmpE7sliOXBNUNSpYWrmek3L96EArnc8079Vpx/jei29HN6AuS6e/IMkGu+SAOEy1lfsPfs4vTPCtJ4np7GdjFjMsVyaQTfs6HmvG2wgfN44Koi3I3kfNYyqyUbbnppwNANIuJVNN/zOeoLrZ/i70IlpL2cscDJ/b6hTYEGOtugFRfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CUepeKXD3++9PTwq/nksHuSuVKPdsx05C4MGlKaWS6A=; b=mE2VwdBhgFpKinJ9Szr+XOBkeNqNNeuKUDgxXrwYcs8fB8n88T3bhIMq2TjaCx/PdOy21aryLPISCjryx//uWp1cUvR9GjBBVwIecMNISlcqe+tEw9YZi6okQo6UBdc9siid3kKvg7/xluEzI8y/cw10vmwqtX/7PqV8F/Xr9Gls4xudd+IIJh+hLgP6YfgTjJyf8ZY6LugqQ1Nc+UMbvnC1fvG6XZsWqrSrRM6vveWcB8QLvGDiDqybiLZS9gmBDKEcaK4GQtS64yDu+dMYmBLwA3klDjYNhufqvr12QxrIfeugEsd58p3X+6C2hfwK1po43O1SZS+58HeyEpWgqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CUepeKXD3++9PTwq/nksHuSuVKPdsx05C4MGlKaWS6A=; b=OfPoPOuGNtXZPibn8pY3Rd90XGsXerJjGYa1sPtfmeX8b8v79Vs7eJZJL4/saOkg07qkaDOHfjMWnT+SHWzJyRegjgSIiLOYi5caGcYnko9IRUkL2ccdXA6urxRYogXf16DiS75rIPwnerzYDdvsCSPu27Ri+2P7ZuYdKw/Doaw+uk8eFnnEuleKqRqJwxGvgk5oVPpe85O2NmqBGiG+KEd5ge8k0V69irj4ZeoOaGC0naPd700Jg9+rQ+ARTgv0478TXZAkAk9Q3NmIQy3PALHUPUUp990bJCw7/NJ526n3L/P+u8IyWNIJ6toVrz2utMquNJYmYAVZ5lAe4YdB7Q== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v12 2/6] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Topic: [PATCH v12 2/6] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Index: AQHdQb7XatT4szy+tkiSRBw2OFmymQ== Date: Fri, 11 Sep 2026 07:26:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR03MB10263:EE_|AM9PR03MB8025:EE_ x-ms-office365-filtering-correlation-id: fb363054-e952-4deb-03d7-08df0fd5f99a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|10067099003|3023799007|18002099003|22082099003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: aOUa/ORrh0Vk5xq0rJYhFssKJEBMMkLtLhZNkcRK57iD13kSa37lSrF7t6tykR186HlFk6erQ12WdWRnR3wmqnugYo7B330UU6Ce8lMLxK78/t7n+E82LV+DvaT+sVbqUcHHaOo9GWEHlO4NSvVoY4+3UgRLDi8P5HG4wAK4xdBZmdZG8BfMC0feQtDryUo92+CVN+MCmplydr696aO01XPvtdtbSpb4cRR2R4LmiAjclsAxaawt8UOda6E9vpsLrZnd4XFSDjLYzbySSmhCXj7/EsbO4IwwSZ7fa6jNQEykE5hLIuy37w3wNfHDaeVee05qmBwe/8biG+rL5JLHlcBEJM+33l2r6Q3WOlpHG1qXLESNqK6KAOdeK8ph70ZwEamqlAe63E730u8cqq6f0pbQDFFevXS5QXCGQtwHU4jM3vqPT8JVnxbicGJp0miG3DnvQodkF6G2CXcg3qXYQr4BLOm9MeGpwbXKl/7qU294oy3MLsFs4dZkNFm08PSz4sm7CptIO4emam1zszvdoXn7BUhGyIUgyojH/7MmuZNG2D7nJgaz6gH8+C6TYdOar3mQr8mgELZojnt2WrHclY1scRMjgNkfQD3WkXYvYv0ZwhoOROuXKWM1oG/BibHE0mP91SnvdKCkx95l53jcGkc66PCVbpbuHc4BTfbkj//jugNREYSnBtgwikyAtkxZ91XTmXU9Cwa2q+/aVMuQ5IBr2XYv3Q/VfFKS8j2q3hw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10263.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(10067099003)(3023799007)(18002099003)(22082099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?810q+4701PJtekmlnOc2C2e6X8H9xDo1Y3Yz/k42u0UTVgQHKCjb2DFeVW?= =?iso-8859-1?Q?IplmMl/b3z4lsO6cDkmX3QpBxTorderIfkAbYHMa+VO3N5+v+ZkmBJdLxM?= =?iso-8859-1?Q?9CjNqJappvcmHgfvBummDER0xnncoBtLSG+ipI/mu3yf4rZaXd3YRNZINm?= =?iso-8859-1?Q?LhaNnxijMMo5T147f8nAfozbDicERRaJL7j6ZHU3hXBK0dGjg6xQFTskxA?= =?iso-8859-1?Q?jiLcgg++akbqd5Ledu/3HZ5DI0s3EfIGC45iIUBTEQ7VKvRKfedy3iLhek?= =?iso-8859-1?Q?/KVP3EggoJ6dDboeh34u0X24K9inezKNd56abNP5gp6QIUrcMPrK3lwey2?= =?iso-8859-1?Q?3HbJyX3mn90DgR2j0hD3MvhXfow6LVOjOFikGm57pqtNbgKLOOjOhouDHc?= =?iso-8859-1?Q?Xl12unPUclGDy/XnYMmFv56UAIYiHAdBV0YrS3s4Q0p6j2hO+7FOFJiq0f?= =?iso-8859-1?Q?YlxaWVIroN9DzAkoTVGUnKQsatI38uyLnd+EO3ONfAlKfz6zttoWTbIuyx?= =?iso-8859-1?Q?XnkIrG/IAX+qA1xhg54U+CZk68yeUQOWhMYcAsj8z7PA1Ngynv+C0MfvmH?= =?iso-8859-1?Q?w/Icqb5KS3atgDshr5dUwZfG2ess82d1SfHbo6YXXebXsrqWwDjMGahE74?= =?iso-8859-1?Q?kRA+5Y/hQEXf1HQvlcoCub16vQj7rWNKVUixtWAGGk2jVXPT/R72TC3iaz?= =?iso-8859-1?Q?zBaGJISgFRFFFC/R/x4V1RtCsUVOSRRcgwc4k0783y3pJXSJEUQu5p98zw?= =?iso-8859-1?Q?+ssK28gxleyzxnvYXoarwElFXH1uIwShqM3XaoUeCV5T/0nEic0+NKR4NF?= =?iso-8859-1?Q?6+JuETmE5ONHq1vZDpglmVH3AyFJWWra+SNQ4mlSI3+A6E9FKIeRGz91cA?= =?iso-8859-1?Q?mr1iHX/8+SexoE4qY1vcvk842oYOyvdOUyWAolnnRsnxi/lVBgB0imAuZn?= =?iso-8859-1?Q?97WMM9+m+3CQz8aul1t6q9CBQ2jjE4NTB+t7RAPpVlL9ravDGnYcOl7Xor?= =?iso-8859-1?Q?wlbKyX3+YP3WkOeJJ3oYSQdTTGSxZqg5FTeAHIum/nbbBwFMevZz15+rO3?= =?iso-8859-1?Q?fyM24OG2yp1kHs7XN7pG8aYZROu8H4E8PXPYE94nyTaTMqmfhJWmapETVO?= =?iso-8859-1?Q?bqKw0TYpDWz0iW+UurZ7gAyhWQ0rwefP+lOwDrcSYuxDmBkIeBECelAkqz?= =?iso-8859-1?Q?1odUYeOvPpkTyIaoHeSVUxwKZadWYZeBzA7oqaVpRYKAnuQq9mL3Uqm8+o?= =?iso-8859-1?Q?959Zzt4hoOIFC8m8y2tX4fN4YgRaDONPmHfB8sAoCbRR61a07J8gIm3D7F?= =?iso-8859-1?Q?cP7MmMssxW2AYa29AfK9IrjXUnsCHCYWLO0Qeae/b/LtKzeG/tg7UZWADE?= =?iso-8859-1?Q?0XOuA2bHhTiPv9jjeK9/s9EHmIy76c35/wfNXCsgk8Re57m+Nj/cRDtT4v?= =?iso-8859-1?Q?lkVqW4s3NF+ieXGPAjXITXkg4VHceGwOhXveh26grRNXtQbA5vLdRRjKhD?= =?iso-8859-1?Q?T9l2TUBFE7Dub9DM5E8cBASuh9HEp10KeWscttCGCJKom5AS194Kg0omxc?= =?iso-8859-1?Q?uui0zKaN49qBw4zxqo8uYQxQuw+UA+9yADUAtMCJEM472P+IGPnUtOPBfp?= =?iso-8859-1?Q?NMwyuVBFMiCI6OPvUoiRbjWKqYMQuHeqfXODwqK9oSV8Fb3+AbrRgNmC7o?= =?iso-8859-1?Q?BhY+Lb513Y0eHgWs0lzuXftXOybZd9oIlJWbFe6Ywcq3HQCt+ktzECnzmO?= =?iso-8859-1?Q?yqWn1aggHEWw/f7A8yNst8mj+YeUB2f2CemprWfGHAyidblZdKwLbl7zfO?= =?iso-8859-1?Q?lkxRxeDE96wZjwQkzSXkKkQo+gQsv/E=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR03MB10263.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb363054-e952-4deb-03d7-08df0fd5f99a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 07:26:19.9384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fuvuerbcaM0+a79ji2GDPssoUEzFQP11hVbWVbbM66KseqQ/0Y+umTJxTB3/rQxJSZ7CSaQINO24EFryufsDmEDSiq9vz23y3XFEmObxhtg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB8025 X-purgate-ID: tlsNG-ef75cf/1789111584-A72DCAE4-911FF115/0/0 X-purgate-type: clean X-purgate-size: 1092 According to the "7.1 Return Codes" section of DEN0028 [1] INVALID_PARAMETER code (-3) is returned when one of the call parameters has a non-supported value. Adding this error code to the common smccc header file. [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 Signed-off-by: Oleksii Moisieiev Acked-by: Stefano Stabellini --- Changes in v12: - add missed Ack. xen/arch/arm/include/asm/smccc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/sm= ccc.h index c7763acd7f..91c9bc1186 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -381,6 +381,7 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs = *args, 0x3FFF) =20 /* SMCCC error codes */ +#define ARM_SMCCC_INVALID_PARAMETER (-3) #define ARM_SMCCC_NOT_REQUIRED (-2) #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1) #define ARM_SMCCC_NOT_SUPPORTED (-1) --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:26:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:26:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415788.1645038 (Exim 4.92) (envelope-from ) id 1x4veV-0003pm-IL; Fri, 11 Sep 2026 07:26:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415788.1645038; Fri, 11 Sep 2026 07:26:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veV-0003pS-AC; Fri, 11 Sep 2026 07:26:27 +0000 Received: by outflank-mailman (input) for mailman id 1415788; Fri, 11 Sep 2026 07:26:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veT-0003Sl-BC for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:26:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4veS-001KmU-Nd for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:26:24 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ad17-e002-0a2a0a5209dd-0a2a4507c276-28 for ; Fri, 11 Sep 2026 09:26:24 +0200 Received: from [52.101.70.117] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ad1d-b4ea-0a2a45070019-3465467530e0-7 for ; Fri, 11 Sep 2026 09:26:24 +0200 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com (2603:10a6:10:519::5) by AM9PR03MB8025.eurprd03.prod.outlook.com (2603:10a6:20b:43c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:26:20 +0000 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908]) by DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908%5]) with mapi id 15.21.0406.005; Fri, 11 Sep 2026 07:26:20 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kjBPjLywidj3VEkVZhe7Hss5GXyezghj6zhIhvKxVXPsrktZSQ2ViEykhoPmUImussANwFSL7eqid2dwjtyUBBYCvOIaNgkhjWF9Y2oJ26mLmLZ0i1rHtG9t6oBBTWacyI0Q0SSwt9nbC5qJu4hyrNx3pD63Lr9HkwPo6EUeEaPwjaDuwi1U8RJ2ZCONkn77s5aiHECrHUMNxwKIzVotaoXbMxEwQmUcyGQBuHPUSxpprCACgE2v5gNZ89EgYyGsgx1W84fWcgk1D4Fi7OEbfNEMFoD2otDaqcAx3mwyDCWVo3avFWF94FOrePwcNZfVYUIETKGvLe52D43hriHWBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0/nT4+ksWmhEtE6q2HNFoQ7vPWlJTlfIgYpRU/2H3zs=; b=dU3lt4UBkkliVRRmBc+yB9MKhqpxSBUJv1coo91XoNcv+ivya5ZgsrVP0It0M9dpUtHkS2vZx4NnbdUcBlCdpQSSTJnsj7W5KPtx7/wqzu71ggqTOsd4THjRxbm/jewCmBI3PdPrwOAuxFWCpLmmxZyTmZexep9qgoJSYHph5aiGdu0MClcRbN2P+wRLREOYxlY6xv/w+2aKve2wr7NA4yy5ri1GU/9hxNPJHDrDxStWsacr0dO3LpnZPzSr5Ajkf+5cUXBa27/PjUzD7kBh+ikIZFVhHXnyQLPub+AKQUgK/sW5zMZFeCg+4zAU6LhPoEn2/x2Km3AKdX1Rvs8swA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0/nT4+ksWmhEtE6q2HNFoQ7vPWlJTlfIgYpRU/2H3zs=; b=bGymqD1FWkp2pzBzC2hIVzcP0MYM9o1zsBr0z6w7uIxCKrj7unqo6nhuw91f+6OllAnAGUrQM+9/wyRRCC/rUP/6mBj1QZ+LCvZpdBFB4tKQfapl/xqL8tZTXAu8PFDv0aAgiKcR9gLwrY8sIr7gBaQDG2S01TmuWsrS7PbYHX83s0n1BS59LgY7PKEgiYWUpDouWdrxCRTd+znbzGBVlHbV3MtRmdH2bxXj2vnQZiWJQZTFpI/wmMOd7YVzd2u5Ihp7/KaXIV/qWM6lLqQKXPrAZVxStTCnVaYN4QUb1jQFslOTIvSjjwjuabsnzzbw3TOTVTn7tGYFNE2ZDmV2gw== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v12 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v12 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdQb7Xf3yZj4NaZEewNqtWx4tCcg== Date: Fri, 11 Sep 2026 07:26:20 +0000 Message-ID: <66dc59f2978840d3bdb574193a15bd5f4419140e.1789055542.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR03MB10263:EE_|AM9PR03MB8025:EE_ x-ms-office365-filtering-correlation-id: bca86d4b-17bd-423b-969c-08df0fd5fa0e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|10067099003|6133799003|3023799007|18002099003|22082099003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: RKUTLyUMUSCE6P+kBBdpJNGd4Y2Rq0oR8v+lwPICd/Sph9+S1EQod26/5hU6GAtvCCmWmnPLeT4qKp2BvGhsDNBT9fgb3Zq8ynXdbMOATqgO9WPuRwcpqVFMg805kcC0HZtrauenjaLmPJFf5mHyUU5Lpjgk5TNF2mjhdvAwofXJGQ/56+2j2oaT+YCpKR6fFV1BjJOe528kBhSaktp1koQfdiJqLqY616+h7Et/g+EH5WgnIt+qvp6CxK1nw4vgVkLhdgnKovrmGo20VVSmVNOQLV7vynfuWpgRZWsbTv/LBgHPA21OKlZaZ8wT3nV9N6Pz0XLf6+T3me8HGJlMaWBNrMTKj9q2l6koTXR47TSWlQt/KBq3RVY8lCYtWUfHGV5Npupo86oVCXIxds9mgTpY0eJZna92INkn/NaoBnxknc65SrFlGVWtTyx+IRHE1amQpNhtRIe3tfDdNafTX/zh8SAL4Zw2Toh+Zqma8qcNyFjS1zuv9BvltwEceCxK1zsknm7FD2kH/SlIp2q6GNQYHanpJWcIR8LOCzS2Z0m9w4YCk4CszvNQOD7u9gLhpM6vQhms44VTQbupMfo8VrNlV/htm+5A1bhiGCQx6AxWzVR9djin1wfYBFHNtnndkPgTDGMDfWIGuxvyMUmu2NRHjkqoapXllOr1usi+bLXtDdiv1DEX/johjLSBK37YBclCUOMLrsNBHM89P7EVwXGk/f0ddOk2gPRHkGLEr2A= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10263.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(10067099003)(6133799003)(3023799007)(18002099003)(22082099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?C8RT0p1/o+rW6Dy4ugaI0YKzEVYgHXt7qV2tAJKmYvzsu4hYSDoruF+GxD?= =?iso-8859-1?Q?WS0KJCPhjMPAkwHTmh3USXfFOji4rnG169SpzWYfg/lji58NYEsXZGsmQF?= =?iso-8859-1?Q?heuHQMURDGIpfOyeK7RwUhn3QTnMqdZ0NOoJWnzOnAfx0sskCktrAxkSnn?= =?iso-8859-1?Q?wkDUmKyptPOFkH8Qzno2roKC6F9ZgN6Nu0HUM3FKfpqOIyVW9P0HOUB5Gv?= =?iso-8859-1?Q?hgDqqh4bjPBuhfvFF0RHCln4yp2un6Bg807zckk2cKFQjDALrLkBflGgXW?= =?iso-8859-1?Q?rvM/Zsjz37UMgGIIaiLPki9JgDGu4hxKxBgExQRyX4lYZgW+/dIoXviVV1?= =?iso-8859-1?Q?BjMfnCgpNEjYywJ0oDlMpQBGNnRHUiJYxlMNqqj17rw7Aic5l+pyZPbrls?= =?iso-8859-1?Q?SVDwnWnLZfwvcYWBNqH8c9cL3jHgWz/zDqyTbg227Ihn/eIw0gP+u4KbyP?= =?iso-8859-1?Q?IyxwLfJd/kB+6OqwsrSp6l8NmwLfIXFXQ+WYgmuB1+M2y6x/5TPmK1XhtK?= =?iso-8859-1?Q?D5aik7Qhm6TjWGVLojX8s6/oR0gNLjL8COHASCm6h3BsHxKzL8EtA19emz?= =?iso-8859-1?Q?xS7tbcfZpBii8uLTrte2QdtkoDUM1b/6ENr33ljm+eicN50VrHJBwlE3FP?= =?iso-8859-1?Q?rZnSr837d7sA36xyjIJp0Zt6n0k9sULg/uYQgfZRAHfL451+18DUF5+tqD?= =?iso-8859-1?Q?qjRnitRr7Rr9W9VDq8htMXtSKklLcfwgxTT/7xtZdejTw7/BYEId1XGYex?= =?iso-8859-1?Q?zrKS2NOtMtwYSrLDTVkl0ieQPu4nBwqLHmHyppCOyBlI07f1di/eA93RME?= =?iso-8859-1?Q?qPJXxZRO70fMSmCWajJEEn4of9iYMrBzyIFk7TKAkNYZuelfvQsewJf9s8?= =?iso-8859-1?Q?SvUVoIbi2YKb//ECs6BcdurJFdc+4jDDkJY/cCX3+7efdJ8PJ24OjnrHKX?= =?iso-8859-1?Q?/Kotaa+oUFlRX5KrO1wWT8TUcqvqa8QThEnN+RFEgR16WTe4/s3en9H+wy?= =?iso-8859-1?Q?/khEDbOlQ+apMtJ/w5dVPuyBp+s1NSta9SERd0sZoxZRWmgARxuuDhw/sw?= =?iso-8859-1?Q?82mpW/uQwy6/Octaej1mT7+1DuCq6e9YiFxjY10iBJCk8wPWbfyhjUq2ah?= =?iso-8859-1?Q?pFbLikAHvRLr5ZJfsHlBAsXmqf0n4ini/+vMk7XzQUglA8UYntec/BhcEy?= =?iso-8859-1?Q?jDHa3p/P989avxD9xontFWtuoLagX/rfLUzARjVB6nMmJtm2f+KTnq9gmd?= =?iso-8859-1?Q?n4LyAEwMLGWSXcRf71mmZ8t/cdgHXeH3fpeLIg6bWLvLzsn+vpu6Pja4XM?= =?iso-8859-1?Q?8e/MbL33Hox1bQ3pO/X+QVN2S0wAtJTp8ArRW4K4lAJAgG6VFJ8kXl5pxz?= =?iso-8859-1?Q?CmJ+yw8x/LuWJYZNl9HtyrblEeZdMtygHyNw7fdj9hEtyfUBvCmaE2ZEu+?= =?iso-8859-1?Q?8/vt0/CRVfvHUHJkxvNm7dP1fw5VvgZyXTynAveqzVIpBG4Oo5sGPSy3z1?= =?iso-8859-1?Q?kI5O7XmMs8VAkHzfCYLTUfT+xsuBVXzNrAmMr7XXC+jGjtZfmBlF3uA/5c?= =?iso-8859-1?Q?R7C3RWkuNwNvG5I0TmkF67bnmB8lfOSrFZe0SErBU8KXy6gADnxN7jQ+Nc?= =?iso-8859-1?Q?vrRV5cMHUF0aM+nW1i5xPQ0+giYwTscgY0u2ZI4mfD4oaTteOB9MfwOiN7?= =?iso-8859-1?Q?aXTYTwvY/4i/CHALyAA8gh8L200M9kn1SQqXbN1NW4d6mdT+IQUTddQOxO?= =?iso-8859-1?Q?hRsCjnvBrHc0Z5db9SMerK75wzfVhKgnLtFDKAYN0Fd0li0xSyfWI7GDjk?= =?iso-8859-1?Q?+BIsrmh5o9gqTj6o9v1YPKKmeLUnmws=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR03MB10263.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bca86d4b-17bd-423b-969c-08df0fd5fa0e X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 07:26:20.7404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8dv0oq7YVWCXiOBHwNBHNKSV0P6q5AHl/sarpt24gp7hEFmQmwuTI+1RZxtEz4fowa5cmQgigHpZB6xcOxjKTRhYbYj7ODhgdlWVRA8Lq4o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB8025 X-purgate-ID: tlsNG-ef75cf/1789111584-A6EDE944-4F52719F/0/0 X-purgate-type: clean X-purgate-size: 68889 This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A (TF-A) which provides SCMI interface with multi-agent support, as shown below. +-----------------------------------------+ | | | EL3 TF-A SCMI | +-------+--+-------+--+-------+--+-------++ |shmem1 | |shmem0 | |shmem2 | |shmemX | +-----+-+ +---+---+ +--+----+ +---+---+ smc-id1 | | | | agent1 | | | | +-----v--------+---------+-----------+----+ | | | | | | | | | | +--------------+---------+-----------+----+ smc-id0 | smc-id2| smc-idX| agent0 | agent2 | agentX | | | | +----v---+ +--v-----+ +--v-----+ | | | | | | | Dom0 | | Dom1 | | DomX | | | | | | | | | | | | | +--------+ +--------+ +--------+ The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared memory transport for every Agent in the system. The SCMI Agent transport channel defined by pair: - smc-id: SMC id used for Doorbell - shmem: shared memory for messages transfer, Xen page aligned. Shared memort is mapped with the following flags: MT_DEVICE_nGnRE. The follwoing SCMI Agents are expected to be defined by SCMI FW to enable S= CMI multi-agent functionality under Xen: - Xen management agent: trusted agents that accesses to the Base Protocol commands to configure agent specific permissions - OSPM VM agents: non-trusted agent, one for each Guest domain which is allowed direct HW access. At least one OSPM VM agent has to be provided by FW if HW is handled only by Dom0 or Driver Domain. The EL3 SCMI FW is expected to implement following Base protocol messages: - BASE_DISCOVER_AGENT (optional if agent_id was provided) - BASE_RESET_AGENT_CONFIGURATION (optional) - BASE_SET_DEVICE_PERMISSIONS (optional) The SCI SCMI SMC multi-agent driver implements following functionality: - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the ``arm,scmi-smc`` node that is a child of this container will bind to Xen; other SCMI nodes (for example under ``/firmware``) are ignored to avoid stealing the host OSPM instance. scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; #access-controller-cells =3D < 1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; - The driver obtains Xen specific SCMI Agent's configuration from the Host DT, probes Agents and builds SCMI Agents list. The Agents configuration is taken from "scmi-secondary-agents" property where first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and third is optional "agent_id": / { chosen { xen { ranges; xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; scmi-secondary-agents =3D < 0x82000002 &scmi_shm_0 0 0x82000004 &scmi_shm_2 2 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id #scmi-secondary-agents-cells =3D <3>; xen,dom0-sci-agent-id =3D <0>; scmi_shm_0: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; /* Xen SCMI management channel */ scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_shm_2: sram@47ff2000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff2000 0x0 0x1000>; }; scmi_shm_3: sram@47ff3000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff3000 0x0 0x1000>; }; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent func_id #address-cells =3D <1>; #size-cells =3D <0>; #access-controller-cells =3D <1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; }; }; }; }; / { /* * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI * enabled for it, ignored by Xen multi-agent mediator */ scmi_shm: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; firmware { scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem protocol@X{ }; }; }; }; This approach allows defining multiple SCMI Agents by adding Xen-specific properties under the ``/chosen`` node to the Host Device Tree, leaving the main part unchanged. The Host DT SCMI channel will be passed to Dom0. The Xen management agent is described as a ``scmi_xen`` node under the ``xen,sci`` comaptible node, which is used by Xen to control other SCMI Agents in the system. All secondary agents' configurations are provided in the ``scmi-secondary-agents`` property with an optional ``agent_id`` field. The ``agent_id`` from the ``scmi-secondary-agents`` property is used to identify the agent in the system and can be omitted by setting ``#scmi-secondary-agents-cells =3D <2>``, so the Secondary Agents configuration will look like this: / { chosen { xen { xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; /* Shared memory nodes as defined earlier */ scmi-secondary-agents =3D < 0x82000003 &scmi_shm_0 0x82000004 &scmi_shm_2 0x82000005 &scmi_shm_3 0x82000006 &scmi_shm_4>; #scmi-secondary-agents-cells =3D <2>; }; }; }; } In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to discover the ``agent_id`` for each secondary agent. Providing the ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping the discovery call, which is useful when the secondary agent's shared memory is not accessible by Xen or when boot time is important because it allows skipping the agent discovery procedure. Note that Xen is the only one entry in the system which need to know about SCMI multi-agent support. SMC ID Configuration and SCMI Connection Compatibility: The configuration allows the same device tree to work for both baremetal Linux and Linux Dom0. This is achieved because: - Baremetal Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 - Dom0 Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 - Xen management uses: func_id 0x82000003, scmi-shmem 0x47ff1000 This works because the privileged SCMI connection in EL3 firmware is not tied exclusively to func_id 0x82000002. The EL3 firmware supports multiple SCMI agents with different SMC IDs and shared memory regions. Each agent (Dom0 via 0x82000002, Xen via 0x82000003, other domains via additional func_ids) has an independent communication channel to the firmware. The key distinction is that Xen's management channel (0x82000003) is used for privileged operations like agent configuration and device permissions (BASE_SET_DEVICE_PERMISSIONS, BASE_RESET_AGENT_CONFIGURATION), while Dom0's channel (0x82000002) is used for standard SCMI protocol operations (power, clock, sensor management, etc.). The firmware enforces different permission levels for each agent based on their agent_id, not the SMC ID. Therefore, there is no conflict: Linux Dom0 retains its standard SCMI connection for hardware management, while Xen uses its separate privileged channel for mediating access between multiple domains. - It implements the SCI subsystem interface required for configuring and enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable SCMI functionality for domain it has to be configured with unique supported SCMI Agent_id and use corresponding SCMI SMC shared memory transport [smc-id, shmem] defined for this SCMI Agent_id. - Once Xen domain is configured it can communicate with EL3 SCMI FW: -- zero-copy, the guest domain puts SCMI message in shmem; -- the guest triggers SMC exception with smc-id (doorbell); -- the Xen driver catches exception, do checks and synchronously forwards it to EL3 FW. - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen management agent channel on domain destroy event. This allows to reset resources used by domain and so implement use-case like domain reboot. Dom0 Enable SCMI SMC: - set xen,dom0-sci-agent-id=3D under the xen,sci container in the Host DT. If the property is absent, SCMI is disabled for Dom0 and all SCMI nodes are removed from the Dom0 DT. The driver updates the Dom0 DT SCMI node "arm,smc-id" value and fixes up the shmem node according to the assigned agent_id. - pass dom0=3Dsci-agent-id=3D in Xen command line. if not provid= ed SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem node according to assigned agent_id. Guest domains enable SCMI SMC: - xl.cfg: add configuration option as below arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for the domain, for example: iomem =3D [ "47ff2,1@22001", ] - DT: add SCMI nodes to the Driver domain partial device tree as in the below example. The "arm,smc-id" should correspond assigned agent_id for the domain: passthrough { scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x22001000 0x0 0x1000>; }; firmware { compatible =3D "simple-bus"; scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000004>; shmem =3D <&scmi_shm_0>; ... } } } SCMI "4.2.1.1 Device specific access control" The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to. The DT SCMI node should "#access-controller-cells=3D<1>" property and DT devices should be bound to the Xen SCMI. &i2c1 { access-controllers =3D <&scmi 0>; }; The Dom0 and dom0less domains DT devices will be processed automatically through sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property shall be used: dtdev =3D [ "/soc/i2c@e6508000", ] xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU). Additionally, this patch adds documentation for the pre-existing scmi-smc-passthrough command line option, which was previously undocumented. [0] https://developer.arm.com/documentation/den0056 [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/access-controllers/access-controller= s.yaml Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- Changes in v12: - rebase to the latest staging - return EINVAL if xen,sci_type=3Dscmi_smc_multiagent was set but CONFIG_SCMI_SMC_MA not set - put arm_sci_agent_id after v8r_el1_msa and before pad to preserve order. Reduced pad from uint16_t to uint8_t to fill the gap (was 2 bytes before adding arm_sci_agent_id and left only 1, so used uint8_t to preserve structure size) - fix scmi_handle_call to use arm_smccc_guest_smc helper function - update send_smc_message function to use new format of arm_smccc_1_1_smc - guard the Dom0 SCMI agent id setup in create_dom0() and MA related funcitons with CONFIG_SCMI_SMC_MA - fix the xen_scmi_config example in booting.txt, which placed properties after subnodes and was rejected by dtc with "Properties must precede subnodes" Changes in v10: - Fix tabs in MAINTAINERS file - remove duplicate SPDX tag from scmi-shmem.c - add cast to ARM_SMCCC_INVALID_PARAMETER to settle the sign since ARM_SMCCC_INVALID_PARAMETER is -3 which is part of the spec and resp is the default smccc call structure. - update free_channel_list. Add spinlock to avoid race condition and a comment with a description of the function work - preserve error of smc_create_channel in scmi_probe - check scmi shmem address alignment as wel as it is done for size - check for d->arch.sci_data !=3D NULL in scmi_handle_call - use SCMI_SHMEM_MAPPED size for iomem_permit_access - change len type to unsigned in shmem_{get|put}_message - rename shmem_channel_is_free to shmem_channel_status - add comment about skipping message status when getting message response - Set correct agent_id ranges for dom0less and a toolstack. Agent_id 0 is not binded for dom0 so can be reused. Also mentioned that UINT8_MAX (255) is treated as invalid agent_id. - Split hypervisor and toolstack changes into separate commits - move init list and spin init after initial checks in probe call - fix typo in comments - clean resources when sci_register returns an error. Changes in v9: - sort and refactor MAINTAINERS enties - remove Spurious changes - add extra check to avoid ASSERT when calling unmap_channel_memory from assign device method - set correct tx flag to SCMI_BASE_AGENT_PERMISSIONS_RESET when freeing resources. Flag should be set to 1 according to the section 4.2.2.12 [0]. - fix dt node copmaring - moved channel->shmem check from ASSERT in unmap_memory_channel to "if" statement. This will prevent firing ASSERT if unmap_channel_memory was called twice on the same channel. Changes in v8: - update xen_scmi func_id in commit description - updated documentation with the new DT format - updated opt_dom0_scmi_agent_id setting to avoid it to be equal SCMI_AGENT_ID_INVALID. - changed SCMI_AGENT_ID_INVALID from 0xff to UINT8_MAX which makes code more clear showing that UINT8_MAX is theated like invalid agent_id and couldn't be used. Also excluded SCMI_AGENT_ID_INVALID from acceptable value range - remove outdated xen,config property ignore, added xen,sci compatible to skip_matches in handle_node - add documentation for pre-existing scmi-smc-passthrough command line option in alphabetically correct location (in 's' section) - add note to commit description about documentation for previously undocumented scmi-smc-passthrough - Fix SMC IDs in DT examples (Xen management uses 0x82000003, Dom0 uses 0x8= 2000002) - Add explicit note explaining why Dom0 and Xen channels do not conflict - Document dom0less multi-agent configuration example (xen,sci_type / xen,s= ci-agent-id) - Add scmi_xen node to agent-discovery example with #scmi-secondary-agents-= cells =3D 2 - Drop dom0=3Dsci-agent-id command line handling; Dom0 SCMI is now enabled = via xen,dom0-sci-agent-id in the xen,sci DT container - Refresh docs and examples to mention the DT property instead of the cmdli= ne option Changes in v7: - rework scmi nodes for xen to match on compatible string instead of the direct path Changes in v6: - updated scmi-shmem to use io.h from generic location - update scmi_agent_id parameter to be provided inside dom0=3D parameter list and have the following format "dom0=3Dsci-agent-id=3D0" This change was done as a response for Stefano comment and requires a lot of code changes, but produces much cleaner solution that's why I've added it to the code. - fix file comments and return codes - fix lenght checks in shmem_{get,put}_message to use offsetof - remove len member from scmi_channel structure as it is not used - set scmi-secondary-agents property to be mandatory since if no secondary agents were provided then there is no sence to enable scmi when no secondary agents are populated to the Domains - update documentation in booting.txt, added xen_scmi node to the example - adjust d->arch.sci_enabled value in scmi_domain_destroy - fix lock management in smc_create_channel call - avoid extra map_channel_memory command for Xen management channel because collect_agent_id call unmaps memory if DOMID_XEN is not set. So for Xen management channel we can init domain_id ad DOMID_XEN before calling collect_agent_id so memory shouldn't be unmapped. Changes in v5: - fix device-tree example format in booting.txt, added ";" after "}". - update define in scmi-proto.h - update define in scmi-shmem.h file - scmi_assign_device - do not ignore -EOPNOTSUPP return code of the do_smc_xfer - remove overwriting agent_channel->agent_id after SCMI_BASE_DISCOVER_AGENT call - add multi-agent files to the MAINTAINERS - add SCMI multi-agent description to the SUPPORT.md - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL for smc call - updated collect_agents function. Set agent_id parameter as optional in scmi-secondary-agents device-tree property - introduce "#scmi-secondary-agents-cells" parameter to set if agent_id was provided - reanme xen,scmi-secondary-agents property to scmi-secondary-agents - move memcpu_toio/fromio for the generic place - update Xen to get management channel from /chosen/xen,config node - get hypervisor channnel from node instead of using hardcoded - update handling scmi and shmem nodes for the domain - Set multi-agent driver to support only Arm64 Changes in v4: - toolstack comments from Anthony PERARD - added dom0less support - added doc for "xen,scmi-secondary-agents" MAINTAINERS | 1 + SUPPORT.md | 11 + docs/misc/arm/device-tree/booting.txt | 197 +++++ xen/arch/arm/dom0less-build.c | 17 + xen/arch/arm/domain_build.c | 43 ++ xen/arch/arm/firmware/Kconfig | 12 + xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/scmi-proto.h | 164 ++++ xen/arch/arm/firmware/scmi-shmem.c | 118 +++ xen/arch/arm/firmware/scmi-shmem.h | 45 ++ xen/arch/arm/firmware/scmi-smc-multiagent.c | 816 ++++++++++++++++++++ xen/include/public/arch-arm.h | 5 +- 12 files changed, 1429 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/firmware/scmi-proto.h create mode 100644 xen/arch/arm/firmware/scmi-shmem.c create mode 100644 xen/arch/arm/firmware/scmi-shmem.h create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c diff --git a/MAINTAINERS b/MAINTAINERS index c60afc93a5..cd6d1243bd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -534,6 +534,7 @@ SCI MEDIATORS R: Oleksii Moisieiev S: Supported F: xen/arch/arm/firmware/sci.c +F: xen/arch/arm/firmware/scmi-*.[ch] F: xen/arch/arm/include/asm/firmware/sci.h =20 SEABIOS UPSTREAM diff --git a/SUPPORT.md b/SUPPORT.md index eb07332462..dc41a6b2f3 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -972,6 +972,17 @@ by hwdom. Some platforms use SCMI for access to system= -level resources. =20 Status: Supported =20 +### Arm: SCMI SMC multi-agent support + +Enable support for the multi-agent configuration of the EL3 Firmware, whic= h +allows Xen to provide an SCMI interface to the Domains. +Xen manages access permissions to the HW resources and provides an SCMI in= terface +to the Domains. Each Domain is represented as a separate Agent, which can +communicate with EL3 Firmware using a dedicated shared memory region, and +notifications are passed through by Xen. + + Status, ARM64: Tech Preview + ### ARM: Guest PSCI support =20 Emulated PSCI interface exposed to guests. We support all mandatory diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t= ree/booting.txt index bcb06bc796..1d0382a865 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -331,6 +331,21 @@ with the following properties: Should be used together with scmi-smc-passthrough Xen command line option. =20 + - "scmi_smc_multiagent" + + Enables ARM SCMI SMC multi-agent support for the guest by enabling SCM= I over + SMC calls forwarding from domain to the EL3 firmware (like ARM + Trusted Firmware-A) with a multi SCMI OSPM agent support. + The SCMI agent_id should be specified for the guest with "xen,sci-agen= t-id" + property. + +- "xen,sci-agent-id" + + Specifies ARM SCMI agent id for the guest. This option is mandatory if= the + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The a= gent ids + of guest must be unique and in the range [0..254]. UINT8_MAX (255) is + treated as invalid. + - v8r_el1_msa =20 A string property specifying whether, on Armv8-R systems at EL1, a dom= ain @@ -847,3 +862,185 @@ The automatically allocated static shared memory will= get mapped at 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in Dom= U2 guest physical address space. DomU1 is explicitly defined as the owner dom= ain, and DomU2 is the borrower domain. + +SCMI SMC multi-agent support +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D + +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_= SMC_MA) +the Xen specific SCMI Agent's configuration shall be provided in the Host = DT +according to the SCMI compliant EL3 Firmware specification with ARM SMC/HV= C +transport. The SCMI configuration must live under the Xen SCMI container +"xen,sci" beneath "/chosen" (for example "/chosen/xen/xen_scmi_config/scmi= "). The +Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is a chil= d of +this "xen,sci" container; any other "arm,scmi-smc" nodes (for example unde= r +"/firmware") are ignored to avoid stealing the host's SCMI OSPM instance. + +- scmi-secondary-agents + + Defines a set of SCMI agents configuration supported by SCMI EL3 FW an= d + available for Xen. Each Agent defined as triple consisting of: + SMC/HVC function_id assigned for the agent transport ("arm,smc-id"), + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem"= ), + SCMI agent_id (optional) if not set - Xen will determine Agent ID for + each provided channel using BASE_DISCOVER_AGENT message. + +- xen,dom0-sci-agent-id + + Optional. Specifies the Dom0/hwdom SCMI agent_id inside the ``xen,sci`= ` + container. When provided, Dom0 will be configured for SCMI multi-agent + support; when omitted, SCMI remains disabled for Dom0. The value must + match the ``func_id`` and shmem pairing that EL3 firmware exposes for + Dom0 (for example via ``/firmware/scmi``). + +As an example: + +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + xen,dom0-sci-agent-id =3D <0>; <--- dom0 agent id + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_= id + #scmi-secondary-agents-cells =3D <3>; + + scmi_shm_0: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + /* Xen SCMI management channel */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; + }; + }; +}; + +Note: This example keeps the Host DT unchanged for Dom0 and baremetal Linu= x +by using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a +separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 +firmware enforces permissions per agent_id, so there is no conflict betwee= n +Dom0 and Xen channels. + +- #scmi-secondary-agents-cells + + Defines whether Agent_id is set in the "scmi-secondary-agents" propert= y. + Possible values are: 2, 3. + When set to 3 (the default), expect agent_id to be present in the seco= ndary + agents list. + When set to 2, agent_id will be discovered for each channel using + BASE_DISCOVER_AGENT message. + + +Example: + +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Shared memory nodes as in the previous example */ + + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; + }; + }; +}; + +Dom0less example (multi-agent) +------------------------------- + +Below is a minimal dom0less configuration showing how to enable SCMI SMC +multi-agent for a pre-defined guest domain using xen,sci_type and +xen,sci-agent-id, together with the Xen SCMI container: + +chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Xen management channel shared memory */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_domu: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000004 &scmi_shm_domu 2>; + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; + }; + }; + }; + + xen,domain@1 { + compatible =3D "xen,domain"; + xen,sci_type =3D "scmi_smc_multiagent"; + xen,sci-agent-id =3D <2>; + /* Additional domain properties (memory, cpus, kernels, etc.) */ + }; +}; diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 3f48f74226..50e2516b9e 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -292,6 +292,23 @@ static int __init domu_dt_sci_parse(struct dt_device_n= ode *node, =20 d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; } + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) + { + uint32_t agent_id =3D 0; + + if ( !IS_ENABLED(CONFIG_SCMI_SMC_MA) ) + { + printk(XENLOG_ERR "xen,sci_type=3Dscmi_smc_multiagent requeste= d, but CONFIG_SCMI_SMC_MA not set\n"); + return -EINVAL; + } + + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || + agent_id >=3D UINT8_MAX ) + return -EINVAL; + + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA= ; + d_cfg->arch.arm_sci_agent_id =3D agent_id; + } else { printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"= , diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 72d5316180..297c46d5a2 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -87,6 +87,39 @@ int __init parse_arch_dom0_param(const char *s, const ch= ar *e) return -EINVAL; } =20 +#ifdef CONFIG_SCMI_SMC_MA +/* SCMI agent ID for dom0 obtained from xen,sci container */ +#define SCMI_AGENT_ID_INVALID UINT8_MAX + +static uint8_t __init get_dom0_scmi_agent_id(void) +{ + const struct dt_device_node *config_node; + u32 val; + const struct dt_property *prop; + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + return SCMI_AGENT_ID_INVALID; + + prop =3D dt_find_property(config_node, "xen,dom0-sci-agent-id", NULL); + if ( !prop ) + return SCMI_AGENT_ID_INVALID; + + if ( !dt_property_read_u32(config_node, "xen,dom0-sci-agent-id", &val)= ) + return SCMI_AGENT_ID_INVALID; + + if ( val >=3D SCMI_AGENT_ID_INVALID ) + { + printk(XENLOG_WARNING + "Invalid xen,dom0-sci-agent-id=3D%u, SCMI disabled for Dom0\n= ", + val); + return SCMI_AGENT_ID_INVALID; + } + + return val; +} +#endif /* CONFIG_SCMI_SMC_MA */ + /* Override macros from asm/page.h to make them work with mfn_t */ #undef virt_to_mfn #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) @@ -1479,6 +1512,7 @@ static int __init handle_node(struct domain *d, struc= t kernel_info *kinfo, DT_MATCH_TYPE("memory"), /* The memory mapped timer is not supported by Xen. */ DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"), + DT_MATCH_COMPATIBLE("xen,sci"), { /* sentinel */ }, }; static const struct dt_device_match timer_matches[] __initconst =3D @@ -1965,6 +1999,15 @@ void __init create_dom0(void) dom0_cfg.arch.tee_type =3D tee_get_type(); dom0_cfg.max_vcpus =3D dom0_max_vcpus(); =20 +#ifdef CONFIG_SCMI_SMC_MA + /* Set up SCMI agent ID if provided in the xen,sci container */ + dom0_cfg.arch.arm_sci_agent_id =3D get_dom0_scmi_agent_id(); + dom0_cfg.arch.arm_sci_type =3D (dom0_cfg.arch.arm_sci_agent_id !=3D + SCMI_AGENT_ID_INVALID) ? + XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA : + XEN_DOMCTL_CONFIG_ARM_SCI_NONE; +#endif + if ( iommu_enabled ) dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu; =20 diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index 5c5f0880c4..972cd9b173 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -29,6 +29,18 @@ config SCMI_SMC driver domain. Use with EL3 firmware which supports only single SCMI OSPM agent. =20 +config SCMI_SMC_MA + bool "Enable ARM SCMI SMC multi-agent driver" + depends on ARM_64 + select ARM_SCI + help + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Doma= ins + to EL3 firmware (TF-A) which supports multi-agent feature. + This feature allows to enable SCMI per Domain using unique SCMI agent_i= d, + so Domain is identified by EL3 firmware as an SCMI Agent and can access + allowed platform resources through dedicated SMC/HVC Shared memory base= d + transport. + endchoice =20 endmenu diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil= e index 71bdefc24a..37927e690e 100644 --- a/xen/arch/arm/firmware/Makefile +++ b/xen/arch/arm/firmware/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_ARM_SCI) +=3D sci.o obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o +obj-$(CONFIG_SCMI_SMC_MA) +=3D scmi-shmem.o scmi-smc-multiagent.o diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scm= i-proto.h new file mode 100644 index 0000000000..49f63cfc0a --- /dev/null +++ b/xen/arch/arm/firmware/scmi-proto.h @@ -0,0 +1,164 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * + * Copyright (c) 2025 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_PROTO_H_ +#define ARM_FIRMWARE_SCMI_PROTO_H_ + +#include + +#define SCMI_SHORT_NAME_MAX_SIZE 16 + +/* SCMI status codes. See section 4.1.4 */ +#define SCMI_SUCCESS 0 +#define SCMI_NOT_SUPPORTED (-1) +#define SCMI_INVALID_PARAMETERS (-2) +#define SCMI_DENIED (-3) +#define SCMI_NOT_FOUND (-4) +#define SCMI_OUT_OF_RANGE (-5) +#define SCMI_BUSY (-6) +#define SCMI_COMMS_ERROR (-7) +#define SCMI_GENERIC_ERROR (-8) +#define SCMI_HARDWARE_ERROR (-9) +#define SCMI_PROTOCOL_ERROR (-10) + +/* Protocol IDs */ +#define SCMI_BASE_PROTOCOL 0x10 + +/* Base protocol message IDs */ +#define SCMI_BASE_PROTOCOL_VERSION 0x0 +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 +#define SCMI_BASE_DISCOVER_AGENT 0x7 +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB + +typedef struct scmi_msg_header { + uint8_t id; + uint8_t type; + uint8_t protocol; + uint32_t status; +} scmi_msg_header_t; + +/* Table 2 Message header format */ +#define SCMI_HDR_ID GENMASK(7, 0) +#define SCMI_HDR_TYPE GENMASK(9, 8) +#define SCMI_HDR_PROTO GENMASK(17, 10) + +#define SCMI_FIELD_GET(_mask, _reg) = \ + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) +#define SCMI_FIELD_PREP(_mask, _val) = \ + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) + +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) +{ + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); +} + +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t = *hdr) +{ + hdr->id =3D SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); + hdr->type =3D SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); + hdr->protocol =3D SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); +} + +static inline int scmi_to_xen_errno(int scmi_status) +{ + if ( scmi_status =3D=3D SCMI_SUCCESS ) + return 0; + + switch ( scmi_status ) + { + case SCMI_NOT_SUPPORTED: + return -EOPNOTSUPP; + case SCMI_INVALID_PARAMETERS: + return -EINVAL; + case SCMI_DENIED: + return -EACCES; + case SCMI_NOT_FOUND: + return -ENOENT; + case SCMI_OUT_OF_RANGE: + return -ERANGE; + case SCMI_BUSY: + return -EBUSY; + case SCMI_COMMS_ERROR: + return -ENOTCONN; + case SCMI_GENERIC_ERROR: + return -EIO; + case SCMI_HARDWARE_ERROR: + return -ENXIO; + case SCMI_PROTOCOL_ERROR: + return -EBADMSG; + default: + return -EINVAL; + } +} + +/* PROTOCOL_VERSION */ +#define SCMI_VERSION_MINOR GENMASK(15, 0) +#define SCMI_VERSION_MAJOR GENMASK(31, 16) + +struct scmi_msg_prot_version_p2a { + uint32_t version; +} __packed; + +/* BASE PROTOCOL_ATTRIBUTES */ +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) + +struct scmi_msg_base_attributes_p2a { + uint32_t attributes; +} __packed; + +/* + * BASE_DISCOVER_AGENT + */ +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF + +struct scmi_msg_base_discover_agent_a2p { + uint32_t agent_id; +} __packed; + +struct scmi_msg_base_discover_agent_p2a { + uint32_t agent_id; + char name[SCMI_SHORT_NAME_MAX_SIZE]; +} __packed; + +/* + * BASE_SET_DEVICE_PERMISSIONS + */ +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) + +struct scmi_msg_base_set_device_permissions_a2p { + uint32_t agent_id; + uint32_t device_id; + uint32_t flags; +} __packed; + +/* + * BASE_RESET_AGENT_CONFIGURATION + */ +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) + +struct scmi_msg_base_reset_agent_cfg_a2p { + uint32_t agent_id; + uint32_t flags; +} __packed; + +#endif /* ARM_FIRMWARE_SCMI_PROTO_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scm= i-shmem.c new file mode 100644 index 0000000000..e36745a85e --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.c @@ -0,0 +1,118 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SMC/HVC shmem transport implementation used by + * SCI SCMI multi-agent driver. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +static inline int +shmem_channel_status(const volatile struct scmi_shared_mem __iomem *shmem) +{ + return (readl(&shmem->channel_status) & + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; +} + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, unsigned int len= ) +{ + int ret; + + if ( (len + offsetof(struct scmi_shared_mem, msg_payload)) > + SCMI_SHMEM_MAPPED_SIZE ) + { + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invali= d\n"); + return -EINVAL; + } + + ret =3D shmem_channel_status(shmem); + if ( ret ) + return ret; + + writel_relaxed(0x0, &shmem->channel_status); + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set */ + writel_relaxed(0x0, &shmem->flags); + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); + writel(pack_scmi_header(hdr), &shmem->msg_header); + + if ( len > 0 && data ) + memcpy_toio(shmem->msg_payload, data, len); + + return 0; +} + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, unsigned int le= n) +{ + int recv_len; + int ret; + /* + * First word of msg_payload carries the returned status; exclude it f= rom + * recv_len so only the protocol payload is copied back to the caller. + */ + int pad =3D sizeof(hdr->status); + + if ( len >=3D SCMI_SHMEM_MAPPED_SIZE - + offsetof(struct scmi_shared_mem, msg_payload) ) + { + printk(XENLOG_ERR + "scmi: Wrong size of input smc message. Data may be invalid= \n"); + return -EINVAL; + } + + ret =3D shmem_channel_status(shmem); + if ( ret ) + return ret; + + recv_len =3D readl(&shmem->length) - sizeof(shmem->msg_header); + + if ( recv_len < 0 ) + { + printk(XENLOG_ERR + "scmi: Wrong size of smc message. Data may be invalid\n"); + return -EINVAL; + } + + unpack_scmi_header(readl(&shmem->msg_header), hdr); + + hdr->status =3D readl(&shmem->msg_payload); + recv_len =3D recv_len > pad ? recv_len - pad : 0; + + ret =3D scmi_to_xen_errno(hdr->status); + if ( ret ) + { + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); + return ret; + } + + if ( recv_len > len ) + { + printk(XENLOG_ERR + "scmi: Not enough buffer for message %d, expecting %d\n", + recv_len, len); + return -EINVAL; + } + + if ( recv_len > 0 ) + memcpy_fromio(data, shmem->msg_payload + pad, recv_len); + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.h b/xen/arch/arm/firmware/scm= i-shmem.h new file mode 100644 index 0000000000..722263aa77 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.h @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * Shared Memory based Transport + * + * Copyright (c) 2024 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_SHMEM_H_ +#define ARM_FIRMWARE_SCMI_SHMEM_H_ + +#include + +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) + +struct scmi_shared_mem { + uint32_t reserved; + uint32_t channel_status; + uint32_t reserved1[2]; + uint32_t flags; + uint32_t length; + uint32_t msg_header; + uint8_t msg_payload[]; +}; + +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, unsigned int len= ); + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, unsigned int le= n); +#endif /* ARM_FIRMWARE_SCMI_SHMEM_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/fir= mware/scmi-smc-multiagent.c new file mode 100644 index 0000000000..0c5653fbc0 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c @@ -0,0 +1,816 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +#define SCMI_SECONDARY_AGENTS "scmi-secondary-agents" + +struct scmi_channel { + uint32_t agent_id; + uint32_t func_id; + domid_t domain_id; + uint64_t paddr; + struct scmi_shared_mem __iomem *shmem; + spinlock_t lock; + struct list_head list; +}; + +struct scmi_data { + struct list_head channel_list; + spinlock_t channel_list_lock; + uint32_t func_id; + bool initialized; + uint32_t shmem_phandle; + uint32_t hyp_channel_agent_id; + struct dt_device_node *dt_dev; +}; + +static struct scmi_data scmi_data; + +static bool scmi_is_under_xen_sci(const struct dt_device_node *node) +{ + const struct dt_device_node *p; + + for ( p =3D node->parent; p; p =3D p->parent ) + if ( dt_device_is_compatible(p, "xen,sci") ) + return true; + + return false; +} + +static int send_smc_message(struct scmi_channel *chan_info, + scmi_msg_header_t *hdr, void *data, int len) +{ + struct arm_smccc_res resp; + int ret; + + ret =3D shmem_put_message(chan_info->shmem, hdr, data, len); + if ( ret ) + return ret; + + resp =3D arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0); + + if ( resp.a0 =3D=3D (unsigned long)ARM_SMCCC_INVALID_PARAMETER ) + return -EINVAL; + + if ( resp.a0 ) + return -EOPNOTSUPP; + + return 0; +} + +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t *= hdr, + void *tx_data, int tx_size, void *rx_data, int rx_s= ize) +{ + int ret =3D 0; + + ASSERT(chan_info && chan_info->shmem); + + if ( !hdr ) + return -EINVAL; + + spin_lock(&chan_info->lock); + + printk(XENLOG_DEBUG + "scmi: agent_id =3D %d msg_id =3D %x type =3D %d, proto =3D %x\= n", + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); + + ret =3D send_smc_message(chan_info, hdr, tx_data, tx_size); + if ( ret ) + goto clean; + + ret =3D shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size); + +clean: + printk(XENLOG_DEBUG + "scmi: get smc response agent_id =3D %d msg_id =3D %x proto =3D= %x res=3D%d\n", + chan_info->agent_id, hdr->id, hdr->protocol, ret); + + spin_unlock(&chan_info->lock); + + return ret; +} + +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) +{ + struct scmi_channel *curr; + bool found =3D false; + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + found =3D true; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + if ( found ) + return curr; + + return NULL; +} + +static struct scmi_channel *acquire_scmi_channel(struct domain *d, + uint32_t agent_id) +{ + struct scmi_channel *curr; + struct scmi_channel *ret =3D ERR_PTR(-ENOENT); + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + if ( curr->domain_id !=3D DOMID_INVALID ) + { + ret =3D ERR_PTR(-EEXIST); + break; + } + + curr->domain_id =3D d->domain_id; + ret =3D curr; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + + return ret; +} + +static void relinquish_scmi_channel(struct scmi_channel *channel) +{ + ASSERT(channel !=3D NULL); + + spin_lock(&scmi_data.channel_list_lock); + channel->domain_id =3D DOMID_INVALID; + spin_unlock(&scmi_data.channel_list_lock); +} + +static int map_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel && channel->paddr); + channel->shmem =3D ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_S= IZE); + if ( !channel->shmem ) + return -ENOMEM; + + channel->shmem->channel_status =3D SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE; + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->pa= ddr, + channel->shmem); + + return 0; +} + +static void unmap_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel); + + if ( !channel->shmem ) + return; + + iounmap(channel->shmem); + channel->shmem =3D NULL; +} + +static struct scmi_channel *smc_create_channel(uint32_t agent_id, + uint32_t func_id, uint64_t = addr) +{ + struct scmi_channel *channel, *curr; + + spin_lock(&scmi_data.channel_list_lock); + + /* Check if channel already exists while holding the lock */ + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-EEXIST); + } + } + + channel =3D xmalloc(struct scmi_channel); + if ( !channel ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-ENOMEM); + } + + spin_lock_init(&channel->lock); + channel->agent_id =3D agent_id; + channel->func_id =3D func_id; + channel->domain_id =3D DOMID_INVALID; + channel->shmem =3D NULL; + channel->paddr =3D addr; + list_add_tail(&channel->list, &scmi_data.channel_list); + + spin_unlock(&scmi_data.channel_list_lock); + return channel; +} + +static void free_channel_list(void) +{ + struct scmi_channel *curr, *_curr; + /* + * Called only on the __init error path, before any runtime users exis= t, + * so no other thread is iterating channel_list. Keep the lock for the + * whole drain for clarity and to avoid misleading readers about possi= ble + * concurrent access. + */ + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list) + { + list_del(&curr->list); + xfree(curr); + } + spin_unlock(&scmi_data.channel_list_lock); +} + +static int __init +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr, + u64 *size) +{ + struct dt_device_node *shmem_node; + const __be32 *prop; + + prop =3D dt_get_property(scmi_node, "shmem", NULL); + if ( !prop ) + return -EINVAL; + + shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop)); + if ( IS_ERR_OR_NULL(shmem_node) ) + { + printk(XENLOG_ERR + "scmi: Device tree error, can't parse reserved memory %ld\n= ", + PTR_ERR(shmem_node)); + return PTR_ERR(shmem_node); + } + + return dt_device_get_address(shmem_node, 0, addr, size); +} + +/* + * Handle Dom0 SCMI specific DT nodes + * + * Make a decision on copying SCMI specific nodes into Dom0 device tree. + * For SCMI multi-agent case: + * - shmem nodes will not be copied and generated instead if SCMI + * is enabled for Dom0 + * - scmi node will be copied if SCMI is enabled for Dom0 + */ +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *n= ode) +{ + static const struct dt_device_match shmem_matches[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-shmem"), + { /* sentinel */ }, + }; + static const struct dt_device_match scmi_matches[] __initconst =3D { + DT_MATCH_PATH("/firmware/scmi"), + { /* sentinel */ }, + }; + + if ( !scmi_data.initialized ) + return false; + + /* skip scmi shmem node for dom0 if scmi not enabled */ + if ( dt_match_node(shmem_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk(" Skip scmi shmem node\n"); + return true; + } + + /* drop scmi if not enabled */ + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk(" Skip scmi node\n"); + return true; + } + + return false; +} + +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, + uint32_t flags) +{ + struct scmi_msg_base_set_device_permissions_a2p tx; + struct scmi_channel *channel; + scmi_msg_header_t hdr; + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + return -EINVAL; + + hdr.id =3D SCMI_BASE_SET_DEVICE_PERMISSIONS; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.agent_id =3D agent_id; + tx.device_id =3D device_id; + tx.flags =3D flags; + + return do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); +} + +static int scmi_dt_assign_device(struct domain *d, + struct dt_phandle_args *ac_spec) +{ + struct scmi_channel *agent_channel; + uint32_t scmi_device_id =3D ac_spec->args[0]; + int ret; + + if ( !d->arch.sci_data ) + return 0; + + /* The access-controllers is specified for DT dev, but it's not a SCMI= */ + if ( !scmi_data.dt_dev || + !dt_node_path_is_equal(ac_spec->np, scmi_data.dt_dev->full_name) = ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + + ret =3D scmi_assign_device(agent_channel->agent_id, scmi_device_id, + SCMI_BASE_DEVICE_ACCESS_ALLOW); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)= ", + d, agent_channel->agent_id, scmi_device_id, ret); + } + + spin_unlock(&agent_channel->lock); + return ret; +} + +static int collect_agent_id(struct scmi_channel *agent_channel) +{ + int ret; + scmi_msg_header_t hdr; + struct scmi_msg_base_discover_agent_p2a da_rx; + struct scmi_msg_base_discover_agent_a2p da_tx; + + ret =3D map_channel_memory(agent_channel); + if ( ret ) + return ret; + + hdr.id =3D SCMI_BASE_DISCOVER_AGENT; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + da_tx.agent_id =3D agent_channel->agent_id; + + ret =3D do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx= , + sizeof(da_rx)); + if ( agent_channel->domain_id !=3D DOMID_XEN ) + unmap_channel_memory(agent_channel); + if ( ret ) + return ret; + + printk(XENLOG_DEBUG "id=3D0x%x name=3D%s\n", da_rx.agent_id, da_rx.nam= e); + agent_channel->agent_id =3D da_rx.agent_id; + return 0; +} + +static __init int collect_agents(struct dt_device_node *scmi_node) +{ + const struct dt_device_node *config_node; + const __be32 *prop; + uint32_t len; + const __be32 *end; + uint32_t cells_per_entry =3D 3; /* Default to 3 cells if property is a= bsent. */ + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + { + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to = collect.\n"); + return -ENOENT; + } + + /* Check for the optional '#scmi-secondary-agents-cells' property. */ + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", + &cells_per_entry) ) + { + if ( cells_per_entry !=3D 2 && cells_per_entry !=3D 3 ) + { + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells = value: %u\n", + cells_per_entry); + return -EINVAL; + } + } + + prop =3D dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); + if ( !prop ) + { + printk(XENLOG_ERR "scmi: No %s property found, no agents to collec= t.\n", + SCMI_SECONDARY_AGENTS); + return -EINVAL; + } + + /* Validate that the property length is a multiple of the cell size. *= / + if ( len =3D=3D 0 || len % (cells_per_entry * sizeof(uint32_t)) !=3D 0= ) + { + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u = cells per entry\n", + SCMI_SECONDARY_AGENTS, len, cells_per_entry); + return -EINVAL; + } + + end =3D (const __be32 *)((const u8 *)prop + len); + + for ( ; prop < end; ) + { + uint32_t agent_id; + uint32_t smc_id; + uint32_t shmem_phandle; + struct dt_device_node *node; + u64 addr, size; + int ret; + struct scmi_channel *agent_channel; + + smc_id =3D be32_to_cpu(*prop++); + shmem_phandle =3D be32_to_cpu(*prop++); + + if ( cells_per_entry =3D=3D 3 ) + agent_id =3D be32_to_cpu(*prop++); + else + agent_id =3D SCMI_BASE_AGENT_ID_OWN; + + node =3D dt_find_node_by_phandle(shmem_phandle); + if ( !node ) + { + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %= u\n", + agent_id); + return -EINVAL; + } + + ret =3D dt_device_get_address(node, 0, &addr, &size); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: Could not read shmem address for agent %u: %d\n"= , + agent_id, ret); + return ret; + } + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) || + !IS_ALIGNED(addr, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + agent_channel =3D smc_create_channel(agent_id, smc_id, addr); + if ( IS_ERR(agent_channel) ) + { + printk(XENLOG_ERR "scmi: Could not create channel for agent %u= : %ld\n", + agent_id, PTR_ERR(agent_channel)); + return PTR_ERR(agent_channel); + } + + if ( cells_per_entry =3D=3D 2 ) + { + ret =3D collect_agent_id(agent_channel); + if ( ret ) + return ret; + } + + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_chan= nel->agent_id, + smc_id, (unsigned long)addr); + } + + return 0; +} + +static int scmi_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) +{ + struct scmi_channel *channel; + int ret; + + if ( !scmi_data.initialized ) + return 0; + + /* + * SCMI support is configured via: + * - For dom0: xen,dom0-sci-agent-id property under the xen,sci contai= ner + * - For dom0less: xen,sci-agent-id in the domain node + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id + * are already set by domain_build.c or dom0less-build.c + */ + + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) + return 0; + + channel =3D acquire_scmi_channel(d, config->arch.arm_sci_agent_id); + if ( IS_ERR(channel) ) + { + printk(XENLOG_ERR + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\= n", + config->arch.arm_sci_agent_id, PTR_ERR(channel)); + return PTR_ERR(channel); + } + + printk(XENLOG_INFO + "scmi: Acquire channel id =3D 0x%x, domain_id =3D %d paddr =3D = 0x%lx\n", + channel->agent_id, channel->domain_id, channel->paddr); + + /* + * Dom0 (if present) needs to have an access to the guest memory range + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permi= ssion + * domctl. + */ + if ( hardware_domain && !is_hardware_domain(d) ) + { + ret =3D iomem_permit_access(hardware_domain, paddr_to_pfn(channel-= >paddr), + paddr_to_pfn(channel->paddr + + SCMI_SHMEM_MAPPED_SIZE - 1)); + if ( ret ) + goto error; + } + + d->arch.sci_data =3D channel; + d->arch.sci_enabled =3D true; + + return 0; + +error: + relinquish_scmi_channel(channel); + return ret; +} + +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE && + config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC= _MA ) + { + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); + return -EINVAL; + } + + return 0; +} + +static int scmi_relinquish_resources(struct domain *d) +{ + int ret; + struct scmi_channel *channel, *agent_channel; + scmi_msg_header_t hdr; + struct scmi_msg_base_reset_agent_cfg_a2p tx; + + if ( !d->arch.sci_data ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + tx.agent_id =3D agent_channel->agent_id; + spin_unlock(&agent_channel->lock); + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + { + printk(XENLOG_ERR + "scmi: Unable to get Hypervisor scmi channel for domain %d\= n", + d->domain_id); + return -EINVAL; + } + + hdr.id =3D SCMI_BASE_RESET_AGENT_CONFIGURATION; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.flags =3D SCMI_BASE_AGENT_PERMISSIONS_RESET; + + ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); + if ( ret =3D=3D -EOPNOTSUPP ) + return 0; + + return ret; +} + +static void scmi_domain_destroy(struct domain *d) +{ + struct scmi_channel *channel; + + if ( !d->arch.sci_data ) + return; + + channel =3D d->arch.sci_data; + spin_lock(&channel->lock); + + relinquish_scmi_channel(channel); + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); + + d->arch.sci_data =3D NULL; + d->arch.sci_enabled =3D false; + + spin_unlock(&channel->lock); +} + +static bool scmi_handle_call(struct cpu_user_regs *regs) +{ + uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); + struct scmi_channel *agent_channel; + struct domain *d =3D current->domain; + bool res =3D false; + + if ( (!sci_domain_is_enabled(d)) || (!d->arch.sci_data) ) + return false; + + agent_channel =3D d->arch.sci_data; + spin_lock(&agent_channel->lock); + + if ( agent_channel->func_id !=3D fid ) + { + res =3D false; + goto unlock; + } + + arm_smccc_guest_smc(regs); + res =3D true; +unlock: + spin_unlock(&agent_channel->lock); + + return res; +} + +static const struct sci_mediator_ops scmi_ops =3D { + .domain_init =3D scmi_domain_init, + .domain_destroy =3D scmi_domain_destroy, + .relinquish_resources =3D scmi_relinquish_resources, + .handle_call =3D scmi_handle_call, + .dom0_dt_handle_node =3D scmi_dt_handle_node, + .domain_sanitise_config =3D scmi_domain_sanitise_config, + .assign_dt_device =3D scmi_dt_assign_device, +}; + +static int __init scmi_check_smccc_ver(void) +{ + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) + { + printk(XENLOG_WARNING + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); + return -ENOSYS; + } + + return 0; +} + +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_nod= e, + struct scmi_data *scmi_data, + u64 *addr) +{ + int ret; + u64 size; + + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_i= d) ) + { + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); + return -ENOENT; + } + + ret =3D scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); + if ( IS_ERR_VALUE(ret) ) + return -ENOENT; + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + return 0; +} + +static __init int scmi_probe(struct dt_device_node *scmi_node, const void = *data) +{ + u64 addr; + int ret; + struct scmi_channel *channel; + unsigned int n_agents; + scmi_msg_header_t hdr; + struct scmi_msg_base_attributes_p2a rx; + + ASSERT(scmi_node !=3D NULL); + + /* + * Only bind to the SCMI node provided by Xen under the xen,sci contai= ner + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to fir= mware + * SCMI nodes that belong to the host OSPM and keeps the mediator scop= ed to + * Xen-provided configuration only. + */ + if ( !scmi_is_under_xen_sci(scmi_node) ) + return -ENODEV; + + if ( !acpi_disabled ) + { + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); + return -EINVAL; + } + + ret =3D scmi_check_smccc_ver(); + if ( ret ) + return ret; + + ret =3D scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); + if ( ret ) + return ret; + + INIT_LIST_HEAD(&scmi_data.channel_list); + spin_lock_init(&scmi_data.channel_list_lock); + + scmi_data.dt_dev =3D scmi_node; + + channel =3D smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_= id, addr); + if ( IS_ERR(channel) ) + { + ret =3D PTR_ERR(channel); + goto out; + } + + /* Mark as Xen management channel before collecting agent ID */ + channel->domain_id =3D DOMID_XEN; + + /* Request agent id for Xen management channel */ + ret =3D collect_agent_id(channel); + if ( ret ) + goto error; + + /* Save the agent id for Xen management channel */ + scmi_data.hyp_channel_agent_id =3D channel->agent_id; + + hdr.id =3D SCMI_BASE_PROTOCOL_ATTIBUTES; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + ret =3D do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); + if ( ret ) + goto error; + + n_agents =3D SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); + ret =3D collect_agents(scmi_node); + if ( ret ) + goto error; + + ret =3D sci_register(&scmi_ops); + if ( ret ) + { + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\= n", + ret); + goto error; + } + + scmi_data.initialized =3D true; + goto out; + +error: + unmap_channel_memory(channel); + free_channel_list(); +out: + return ret; +} + +static const struct dt_device_match scmi_smc_match[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-smc"), + { /* sentinel */ }, +}; + +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) + .dt_match =3D scmi_smc_match, + .init =3D scmi_probe, +DT_DEVICE_END + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index 1fc676fd96..a9a10a3b8d 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); =20 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 =20 #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_NONE 0 #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_PMSA 1 @@ -361,7 +362,9 @@ struct xen_arch_domainconfig { uint8_t arm_sci_type; /* IN */ uint8_t v8r_el1_msa; - uint16_t pad; + /* IN */ + uint8_t arm_sci_agent_id; + uint8_t pad; }; #endif /* __XEN__ || __XEN_TOOLS__ */ =20 --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:26:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:26:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415789.1645043 (Exim 4.92) (envelope-from ) id 1x4veW-0003yo-3J; Fri, 11 Sep 2026 07:26:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415789.1645043; Fri, 11 Sep 2026 07:26:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veV-0003x8-TI; Fri, 11 Sep 2026 07:26:27 +0000 Received: by outflank-mailman (input) for mailman id 1415789; Fri, 11 Sep 2026 07:26:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veU-0003lV-LS for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:26:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4veU-002rD1-23 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:26:26 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ad19-2eae-0a2a0a5409dd-0a2a450a8f38-36 for ; Fri, 11 Sep 2026 09:26:26 +0200 Received: from [52.101.83.103] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ad21-f2d2-0a2a450a0019-346553679a5e-3 for ; Fri, 11 Sep 2026 09:26:25 +0200 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com (2603:10a6:10:519::5) by AM9PR03MB8025.eurprd03.prod.outlook.com (2603:10a6:20b:43c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:26:21 +0000 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908]) by DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908%5]) with mapi id 15.21.0406.005; Fri, 11 Sep 2026 07:26:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RgAKAFsTJVhjZbZwZjTyl3PbSXVjHNA6qMZmlnm7nono9+qa+0SPldVcFiqJhcsdthZnQQkC7WL3ak7y34zW4T6fQ1RATN4rToYj0CZNByxKOafVzuSYsm/Jsk5nVMAYQR96O85RcdzaechtdcxyqQBLLtCyRxEPLxj5o36NDw/SU1E/go4P0eQ8DCyacjPVPd3KQsRQUoV8gB35i0xxZ3FKW36sTz1VMKatB+oxKZLp3An6duNI3W1McJ5X2/GbN/4qCusJMVwiOuOJx3eQml8aIzC7KXIyWRFpfljBqGdJMOflo3e/efvgbeDPv6xygCCW2d5Tga5HWY/eiuJ+tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YEB1ygg7k6uOLA8RSrzyTOVwxUCmQNEb0WWQgAfiVjU=; b=bAR0og0XmIQSOTLriN0ORw6Dixk8Vq1nNlv32NdZcB0gEGj2WN6jZOtIWzkTJwSuJ69/LLvYnuaeU6h3K5q1oqWIz2SHj1eWl9l3Iq6jtTkb1naN3tYnUfzrvkjYDB/VKXTrqg/D2QWrCaj7WM/EetbXHFFpuffTNGNWB0fTOIDSkdB9rn+nHEiIiXiBp0uJ7U2iZSdrYJI0r5e+lqHjgjM8Tm5WPen+rNe5KEXVyJjGb7lssh0dfAYZ90hB6X24OSYGVcgeFem34AqGSxB2TnAEmxIvOs2hswUU1y6rYvVVZVZVr7oEqGRuObkP9zU8vlNmwvx9qGTGLzQ+gqVbrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YEB1ygg7k6uOLA8RSrzyTOVwxUCmQNEb0WWQgAfiVjU=; b=rh+NHbTK/mOMgY0KVg9tNtU4HUt08dS8AjnU2RbJNI3Cv3vUPR9Guhl7zL7eyDTSKqxOlCJY9SZj49NDsix+BUIcQy7MQDUmKmU7stjV/mL4/kcMu27aoFaClVMFLLTBmnH6g4PlW2H2/kHr+rsRARjLEuhAqkYVAYkr5XpuF78GA157hJ+tRQSF+XF/Tel26/ShvrDw6oXyBjYRZ70lTLSHGg3FRhQsXeRlznqrXTj2G5ZVqQDIPWNRcI39Y7aEKkOp/1oY9OC7yBB4qH9CiSrPYTaa2+a2JxFiMJ/KHLXdHXaaD34gBO/qt2PhZHItegH1377JXN56FHvEYUJBfw== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v12 5/6] tools/xl/libxl: wire up SCMI SMC multi-agent configuration Thread-Topic: [PATCH v12 5/6] tools/xl/libxl: wire up SCMI SMC multi-agent configuration Thread-Index: AQHdQb7XToeGpjO4Y0i7HZGVFc1Wmg== Date: Fri, 11 Sep 2026 07:26:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR03MB10263:EE_|AM9PR03MB8025:EE_ x-ms-office365-filtering-correlation-id: b0e4f619-9e45-47e0-fac1-08df0fd5fa45 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|10067099003|6133799003|18002099003|22082099003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: FtwgBI0jjz8d0AVrCEyZG4ZKJFNL+zodgehiFgow3wjRoKyuw8AzGeI9Oz9wxJpZRzZM4i/mpt0at4ps+BxiJZMcgpRfxTfkGcTbH3lryX3Wpd8D6uKBWUKfvqEblF0BVoZa9SEW/6IyQxuolR55elefrbvmrCKxuidmIeZowBt7rTli+8x/Z1/uuCSFu426RuthhXfLPYccrPGK3+utmIJRBXmQwXJFM7m4KGZ5Ujw1b75GpJd8gJCHBHxI6OfQko39vkGm1ZKaUP3lIoGmLaCzdi/LdQpPlVv4WCkkxaGZp0Ob0jtMu0FlqNyuLrAYA7ynWilcx9LMulBfwvvaDODbG3qpkqdZDK7mDypKURLojX88bcvZ4GAz92YsfasANnlopfVnIjrYIevafOv+Adg3pTyEfeZJ27Qv8dkEzXz1JKEylnozDIJK/MkUTe+p8sQPVAXm/iwkMMbyQUOc9gUzhYNnuFyiLzo2QiH59jqO6VTF60uODSc47/hnfVmfaShUe2kzk9jtQ9KWMcvtvIbEXDyS2a2InlYuJfvOvQhOzLb4B6K1HsP9K5Bsw8Sg9Bv/apLUcc0DvJuNXyRvfVZQBryUHrUIs99T6IfGr2hPodv/ComeMwFOqLmBtlF/BvprqwM2tNelcfi1+DjNd2hsp5U6pcv9P+9oawx9yzU1MTzNjzUWmItUCGMS8Mi9loiDS5jwDBD5J7LWaSrlZ6NBjBCIJsPhTiVF5VkJw9k= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10263.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(10067099003)(6133799003)(18002099003)(22082099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ClA3Tf5hszpjOCNaVvW/GrWGRWoN+Jg9ZsD/xRa0sc5KKxcfN15qyknODg?= =?iso-8859-1?Q?UBn/ireCWclUeN6ElN5VP4a360Mr22NjnnOQhEXwdWcEUK6W15rq3htTBX?= =?iso-8859-1?Q?1p97fKjLmSzJ2rPiqOHPT3EZmTr9Mwwxw7T9WIt+kZInWdNDtZFVZba6Uq?= =?iso-8859-1?Q?Y2hFw8NIKY+QEBohYr96/MGTLXlb6a5gjrnMu1XIoOk1UGzbiB/P5JjKw+?= =?iso-8859-1?Q?F04n+5qvt2l1kSUpmfCLktXtWbMUaoHQpVIa200Jc3WJc0FqJIzpGDFPKE?= =?iso-8859-1?Q?kUFGJdzCiWEPGyWTsYFWFgnQ34c45/1FeDeENBlk8HmyS5DfuNkBtvDPZv?= =?iso-8859-1?Q?vJHlf3fX1bTL0hxv5qQjzy71Np+dUDjNuE/0BmRkPPX8tmXRSn4hAjTC2Q?= =?iso-8859-1?Q?R/rrvs3sWZfJc/3RyHJbgeLCtVvMTxPZ3L1/PIqhOzwuK9EOAq2aZpY7sY?= =?iso-8859-1?Q?AKgXORTrTn9t3MPC4oGIrVbq+a21Wx055P6oTFr2DZ99eR9Bd6fniPhgts?= =?iso-8859-1?Q?r8QNfB2l+E0E8F7JlGtPLPgBqnyUzHemjOatwj01Zhq31lltwoZY8HmySv?= =?iso-8859-1?Q?7gWIlg9wg7RQbgswjdfR9/qcaBeLA073jA7a391+qaZBI5nf7FnJs77ahG?= =?iso-8859-1?Q?uD+4TI3HPYCQU5x8/HzgOkxwWsHse2AyK980t11456x0PZ2Ur8z+LOFFSB?= =?iso-8859-1?Q?k7tZFlQoE3XXWcu30uehfzABtQyanhAoWE6/5zK3WBjWULMoJgATmzA+OA?= =?iso-8859-1?Q?+zpjpAisCaVeOTNwU2RvxjEd4Jfgru9SShPXygj3ke2SAMDsI8WGTmhcTH?= =?iso-8859-1?Q?z16cZ51f0LTTgVUd/eqAympwHoV3cElk7KbOgxZCBnMXhAAMrwR8TGw7VE?= =?iso-8859-1?Q?z7eKKpM993Y6kJwE4DOkduiB+P2y5AOZeYat0Wt4yQkPeIbgXnwn1o93Og?= =?iso-8859-1?Q?U1uwOPmsw8lnmt10yApiVtFT+EQKpYuKaWNiARLgYdEo9Pe+dtaPea20Iq?= =?iso-8859-1?Q?2bH5xPwpcVHDXW9r0qiIGdeGPRyzYVme6F8TmpYXFfg9RlXD51ZpDX2S8Q?= =?iso-8859-1?Q?YKi1mMT8LFYf0w+wu2XHIH6ZWsPGa1cqQT2kYg6XogOQ0ocl0Ij2tjr7aS?= =?iso-8859-1?Q?joLrqg80Qntr9b3f+LRzDSVO1ZQV2wt7Y7v8ukvX3eiYfeaA2BXYuCe6+T?= =?iso-8859-1?Q?trHOc1kbGXJmpigXo2hzlqrEZ+5/Nan/ULvxp8XwgVxw+ZjpWDO86nyAwf?= =?iso-8859-1?Q?NqFQNq5NuxSju3B4LN+RIjXL3kwOwNiVs1F5QHnAXKxg6z9w56dhB79xTe?= =?iso-8859-1?Q?LvTFK2V2KDwH1nLIhhAUkgwe8OS9PbU+M5FdLtaDuG/1gzMMmlD/6r7VdF?= =?iso-8859-1?Q?A8ogO4hQYGOEAmf7pz7MI06FuhdvZo0KsvBkiBBMsusyFYL2iszOhwPAG0?= =?iso-8859-1?Q?L9Curm71JrAcFSCAURK5O8c0P31E9Scicp/ixt7E8z2n+BEpT22jq+QSWv?= =?iso-8859-1?Q?qnaMubItIAq3AjdDZmqc7qMWg6N6gJfMvUC28PtHNZKZZI1RTev71WpDNg?= =?iso-8859-1?Q?ro1dTdOMqHY0xSgeMQ9lmiEOSHnKadJjGZqwzGUh4St/iG/Kpovb+j1pFh?= =?iso-8859-1?Q?OWRkOuGnJMBYO4wqgMvZeRziEFrFKa9COqOaHeQADx4xiv0VGilPxYCqU5?= =?iso-8859-1?Q?hNydChXmADKzsNwsi3awmDxM8MMeEZ5VqzBwgYD3vsGsOFXZpgpHymKm+H?= =?iso-8859-1?Q?5PTXbbfCDze9nurdLtHLyiQPq8PfrKTDnIerp2/BydR+eLwW2qBmWKlreM?= =?iso-8859-1?Q?io3iTY8Yi8mBj/YepMO4gojLxmgFmI8=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR03MB10263.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0e4f619-9e45-47e0-fac1-08df0fd5fa45 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 07:26:21.1044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bBvZt3vdiuxl7DCUKkvYK6UTrsLgtclrf1CdfZrMfi2SDm4QNybC5p357mouEvdWPPlXgeXB7axtty9Z8atyi2l9j/YbuEbme/OdSSUzsCg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB8025 X-purgate-ID: tlsNG-4011c0/1789111586-5A9D9CFC-54D4495C/0/0 X-purgate-type: clean X-purgate-size: 7327 Plumb the SCMI SMC multi-agent type through the toolstack: - Extend libxl_arm_sci_type enumeration with scmi_smc_multiagent (value 2) - Add agent_id field to libxl_arm_sci structure for per-domain agent assign= ment - Update libxl_arm.c to translate libxl config to XEN_DOMCTL_CONFIG_ARM_SCI= _SCMI_SMC_MA and pass agent_id to the hypervisor via xen_domctl_createdomain - Add xl.cfg parsing for arm_sci=3D"type=3Dscmi_smc_multiagent,agent_id=3DN= " - Document the new xl.cfg options in xl.cfg.5.pod.in This completes the userspace side of multi-agent SCMI, allowing xl create and dom0less configurations to assign unique agent_id values to domains. Series-changes 12: - reject agent_id in xl.cfg when the ARM_SCI type is not scmi_smc_multiagent, instead of parsing it and discarding it - perform the check after the option loop, as type and agent_id may be given in either order Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- (no changes since v11) Changes in v11: - Fix agent_id documentation: clarify it applies to SCMI SMC multi-agent support only, not plain SCMI SMC (reviewer feedback) - Remove "non-zero" from agent_id description to match accepted range [0..254] - Remove "UINT8_MAX (255) is treated as invalid" from user documentation as unnecessary implementation detail - Add LIBXL_HAVE_SCMI_SMC_MULTIAGENT feature macro in libxl.h to advertise the new scmi_smc_multiagent type and agent_id field - Add agent_id validation in libxl__arch_domain_build_info_setdefault() to reject invalid values at the libxl level, not only in xl Changes in v10: - Split hypervisor and toolstack changes into separate commits docs/man/xl.cfg.5.pod.in | 13 +++++++++++++ tools/include/libxl.h | 8 ++++++++ tools/libs/light/libxl_arm.c | 13 +++++++++++++ tools/libs/light/libxl_types.idl | 4 +++- tools/xl/xl_parse.c | 27 +++++++++++++++++++++++++++ 5 files changed, 64 insertions(+), 1 deletion(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index d34951edb9..1dec511f20 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3179,8 +3179,21 @@ single SCMI OSPM agent support. Should be used together with B Xen command line option. =20 +=3Ditem B + +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI ov= er +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmwar= e-A) +with a multi SCMI OSPM agent support. The SCMI B should be +specified for the guest. + =3Dback =20 +=3Ditem B + +Specifies an ARM SCI agent id for the guest. This option is mandatory +if the SCMI SMC multi-agent support is enabled for the guest. The agent id= s of +domains existing on a single host must be unique and in the range [0..254]= . + =3Dback =20 =3Dback diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 7c098edab6..9f46566739 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -318,6 +318,14 @@ */ #define LIBXL_HAVE_BUILDINFO_ARCH_ARM_SCI 1 =20 +/* + * LIBXL_HAVE_SCMI_SMC_MULTIAGENT indicates that the + * LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT value is available in the + * libxl_arm_sci_type enumeration and the agent_id field is available + * in the libxl_arm_sci structure. + */ +#define LIBXL_HAVE_SCMI_SMC_MULTIAGENT 1 + /* * LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing * 'soft reset' for domains and there is 'soft_reset' shutdown reason diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c index e4407d6e3f..3adb90c286 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, case LIBXL_ARM_SCI_TYPE_SCMI_SMC: config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; break; + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_M= A; + config->arch.arm_sci_agent_id =3D d_config->b_info.arch_arm.arm_sc= i.agent_id; + break; default: LOG(ERROR, "Unknown ARM_SCI type %d", d_config->b_info.arch_arm.arm_sci.type); @@ -1837,6 +1841,15 @@ int libxl__arch_domain_build_info_setdefault(libxl__= gc *gc, } } =20 + /* Sanitise ARM SCI agent_id parameter */ + if (b_info->arch_arm.arm_sci.type =3D=3D LIBXL_ARM_SCI_TYPE_SCMI_SMC_M= ULTIAGENT && + b_info->arch_arm.arm_sci.agent_id >=3D UINT8_MAX) { + LOG(ERROR, + "Invalid ARM SCI agent_id: %u. Valid range is [0..254]", + b_info->arch_arm.arm_sci.agent_id); + return ERROR_FAIL; + } + if (b_info->type !=3D LIBXL_DOMAIN_TYPE_PV) return 0; =20 diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type= s.idl index 3c35f873df..9830671ca4 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -554,11 +554,13 @@ libxl_sve_type =3D Enumeration("sve_type", [ =20 libxl_arm_sci_type =3D Enumeration("arm_sci_type", [ (0, "none"), - (1, "scmi_smc") + (1, "scmi_smc"), + (2, "scmi_smc_multiagent") ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE") =20 libxl_arm_sci =3D Struct("arm_sci", [ ("type", libxl_arm_sci_type), + ("agent_id", uint8) ]) =20 libxl_rdm_reserve =3D Struct("rdm_reserve", [ diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 01783731b5..6bb3325c98 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1290,6 +1290,7 @@ static int parse_arm_sci_config(XLU_Config *cfg, libx= l_arm_sci *arm_sci, const char *str) { int ret =3D 0; + int agent_id_set =3D 0; char *buf2, *ptr; char *oparg; =20 @@ -1308,9 +1309,35 @@ static int parse_arm_sci_config(XLU_Config *cfg, lib= xl_arm_sci *arm_sci, } } =20 + if (MATCH_OPTION("agent_id", ptr, oparg)) { + unsigned long val =3D parse_ulong(oparg); + + if ( val >=3D UINT8_MAX ) { + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%l= u). Valid range [0..254]\n", + val); + ret =3D ERROR_INVAL; + goto out; + } + arm_sci->agent_id =3D val; + agent_id_set =3D 1; + } + ptr =3D strtok(NULL, ","); } =20 + /* + * agent_id only means something to the multi-agent driver, and + * libxl__arch_domain_prepare_config() only reads it for that type. + * Reject it elsewhere instead of silently dropping it. The check is d= one + * after the loop because the options may be given in any order. + */ + if (agent_id_set && + arm_sci->type !=3D LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT) { + fprintf(stderr, + "ARM_SCI agent_id is only supported with type=3Dscmi_smc_m= ultiagent\n"); + ret =3D ERROR_INVAL; + } + out: free(buf2); return ret; --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:26:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:26:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415790.1645058 (Exim 4.92) (envelope-from ) id 1x4veX-0004OJ-D8; Fri, 11 Sep 2026 07:26:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415790.1645058; Fri, 11 Sep 2026 07:26:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veX-0004Nx-5K; Fri, 11 Sep 2026 07:26:29 +0000 Received: by outflank-mailman (input) for mailman id 1415790; Fri, 11 Sep 2026 07:26:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4veV-0003m7-1h for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:26:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4veU-002rD1-Du for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:26:26 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ad19-2eae-0a2a0a5409dd-0a2a450a8f38-38 for ; Fri, 11 Sep 2026 09:26:26 +0200 Received: from [52.101.83.103] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ad21-f2d2-0a2a450a0019-346553679a5e-4 for ; Fri, 11 Sep 2026 09:26:26 +0200 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com (2603:10a6:10:519::5) by AM9PR03MB8025.eurprd03.prod.outlook.com (2603:10a6:20b:43c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:26:21 +0000 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908]) by DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908%5]) with mapi id 15.21.0406.005; Fri, 11 Sep 2026 07:26:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DAnPOtSGx7rfkqiEb5XuZZGflhSz8mSthuI5CLhffdQLCjR7wBT6hgjAbtbpyLdsrII2exH01/sGWZS7u331Ln2tzIqwLtUfNl1qGD/bNDpZ2IRj3Y9KmOKRyuoUKopa0PUElWeV2XlggPAkuIscP1xFqW0oyuCWG1fQd5jfe8r2auv4e0emTrMMrVKyXwVnAteaFRlmRKEny3fUhRKbvven7H52iryQQPj88Np56YEpcUZ7DnaIfjzRrdgLN1bGcALl9h1ALC7WdhN1mt8lKkxmV8KsWuLqO5BSgRgFMaZp5w3w2uI4WblPjMdgCODDUomYaSo3i1Wlf83SRFatgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f5VLDzjGdXZ3fBMESadikUu6melFUxWISeZNonumRnY=; b=FRKFlsRVmZQmRKA3STAmSqgvUoeSMmQqRmSV14MW6gY/SgRtfDkoCWjExMhzkcmXCJCvMytjRzNsMLQW63XRm5XL6UKjyUkX3kfiQMaqAmGEnG6JKLy/1CbgEi0uZ4ibF3XOZ/M6P+Xo8vJvQVAaFdSWB0XHtZQ7C7AUE/w/FGCZuYytVx90h6yT9Dgij78JS2G/jiKhJ50DGU5Q8ysX5Ar1xgWJSbu9BYZMXEtvVHlnVMTjL0jkCfRplNNTU0GlIdqnJV9/wWe9oa3NEQr1rS62Lmn7Y7WpqfkmNcCPx98Q1mUcxwb3cwAyu87EHDsD63VT1Z2BddlhhDcGgm+ttg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f5VLDzjGdXZ3fBMESadikUu6melFUxWISeZNonumRnY=; b=uXaO5u0Hhod4mzRm5NUeo+vvtpDwu1kkc0otAuWtYYoRAJsDj/oKIyVS49dhwSofVT3fw8rdT1hMQZZJMzNHsB5C0tF8DBxMDf7SQ9OPEaDd1WmwNMdT8cN/GWfT5pmI1ylzTjeftxHK37DN05dyoVtwJDIOTrQmsyEbueIW+XRVNN00W7NX1V5G3d8KTu/euELCsWmQKYDLhUlXwSE12tPygt+xGeN2wRz6QnOHKbW0KR5+3tf6EpqGc7feHRqsSK7NnpBFSOkjV1LCvTAZ0+/CMhJVzdWbVTwScieO3xQA+hEUQ32J5nYsezRMzwBYVlrYQ83LCNkICByO3ExnZw== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v12 6/6] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Topic: [PATCH v12 6/6] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Index: AQHdQb7Yffw74dK7yUKE/hVbvoBOuw== Date: Fri, 11 Sep 2026 07:26:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR03MB10263:EE_|AM9PR03MB8025:EE_ x-ms-office365-filtering-correlation-id: d60e3c5f-d644-4f52-5244-08df0fd5faa8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|10067099003|6133799003|3023799007|18002099003|22082099003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: xOmW0Q/SdvsGQYsggr53t2A/nrB1+eVnlZBfSCVVuX+Sa+/8teUyn6vomlT2ICa7/kPLhJjpPt6NwwMX4c7ioDWQbG2Zir+p6CSZKR4sjt24yh+54QRyKHJcpIGco7ShqbYS6vDrq+NJFvmtRnwKCETnXB0rVekDD1cH4rUIazY0JeoHnAxmDwn2RiVR7HUas9IhvP3aZ4rn74TtJPW/0FDMnJqMMQEg6V+N/c4tpcnrWWc8Y8JUkvRYklp117Wi0ggP76CfQWjdmxUmB6PJkJ/DP1ckqHcrCk5qg9Cetx/6NmPBH1ACHOnFM7oK4XhBUM9iAV2QlUnPsunSXdtkx/Ws3WVJDcNoseG1Cl/1eNwi53leQ0y1tAZ4PkYSH7i01XBYth+ejZc2cBnxon4pb3u4TCiueG5DPj9GH1KieZio1D33F2/YhTm3hLkvMH6K+LB8jLsf6rVNCThMRxxDobOfB3nnm42RSc9TWa4OIgPFyVjWPl24l9nXgnZVd51kqkXuzMpTtITuexF9idZON78lNe1lHCPPJSbskAn0zSbuRaazjGws+aH+rtv8musDP2v9SRbaYIzSCERvq+3A9PvAzKe6ZoSjMeDCNRhcL2uadrdu5PJZF1tTmrZHRbxoiQLYvm085JoGlkJWG0fWPi/TMyJ9OGXal3j9EXwrBDRSdk4MH2Dz0mLTuYz1p9mCn47QWkEeQZVVpeEh1AW3Qak0upHk7Jx0o1yfzthWZn0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10263.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(23010399003)(366016)(10067099003)(6133799003)(3023799007)(18002099003)(22082099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?mDcNllQncBwp2CaZuZpmVBsb/WjEuMqOAV3Utq4mW9P1AYRaDIDU9x14n5?= =?iso-8859-1?Q?YwGPlW7bpINvYzMWYhR0tSqXKoHbNMCQvSP9xg62Fx2d5tbIO+tLxz0pAf?= =?iso-8859-1?Q?2rcmeqa8qUf6U/RevHhpMWgtxxz1FMizgcOfTakVqQwsAQXzh4gJmr9KXj?= =?iso-8859-1?Q?+iGT0EK606OetIJDw2rBAgCZTwN9mrDm2pMmqnm6Q/rysQdTZzxe5WqIRr?= =?iso-8859-1?Q?5N4A0rMMVY0escTHps3U+CE5DZ5AskPmnapAwwl1r+yaFdBJelej02IwEV?= =?iso-8859-1?Q?zpDp8wavELG3+zEeg2UE8Q8CG+hmTHj4oA2RWWhJ9E2ZTT2XQ7auH87RK/?= =?iso-8859-1?Q?F82F+B11xUU4MTsHe+0qbO1i3ua3pAVPEQe+AhwY/spTLoHqVW0C/PC3R1?= =?iso-8859-1?Q?KMq9IteJIpvibmmYYpTrUxlhWs5YY4msA1NG8qUHRrR3pkc+rFG9yQ1Y1D?= =?iso-8859-1?Q?vZrMrJqdfsUdp94qAfnl3Dw4X8HfffKpw92dts36vPJS2+kQ/rqfRmSrjE?= =?iso-8859-1?Q?d7Wd9uyt178El3jpwtfFbskKgstg/AymD0b+U6ZnLql9I9Cdw3jFlZnAw4?= =?iso-8859-1?Q?jrnZHvGPcWITvT7Mx0dp3avg1cGKfu1XCmhGEVLyZjSWGZWPzOYezm4F0T?= =?iso-8859-1?Q?Zd+gHZxOiomuuJnGzzz0fFm9MkcAtMTZUnEhgl3SXVt0bhq2i2SFJhDdiF?= =?iso-8859-1?Q?Ia7otDQ1fwIc3FBs5NTW528P9y8iyV4w1ScUnX1mwPA16vSoSEXlwHkash?= =?iso-8859-1?Q?28wgrjyp5fb3KsCBqG+VhSmNA+XNV5NXfO1LS841B4qV2dikOhg6cZO9bi?= =?iso-8859-1?Q?3r/23RzELEa1/TgRxSHkDfHe/kQXyKzVoZs3R/VPQRaOzJrNDHWj+pDPzC?= =?iso-8859-1?Q?/3173b+8hXAHQOnJ5B0PG+O/bWYrsoRoyLSTuc3bwmnxkCvTP61NoQPBex?= =?iso-8859-1?Q?ASeP1BiUXjQw+G6amp/DyeD9O/VHlV2uOvdDdF65Lg9fNC+53Wk502ltIJ?= =?iso-8859-1?Q?NvO5jPh3m6j7FQicUBBQdk3hyP7OC+uLfJ7sZoGJt/lDeAHx0e6mBBKoPz?= =?iso-8859-1?Q?lNXYrNDm4kuBAGjyWnUDZeCNmbqKKnzeVcJ/+/T00F8BsCGOLeZmKVXauB?= =?iso-8859-1?Q?vqMucvoMPcRaG7rGmKNeocBe4LF+D6i01ViZ05LG2cdw7+1WKPUuhGVLbW?= =?iso-8859-1?Q?/YOTLe2R0sO+oObT+HZyk8aPvlFDbTS2jkAEKdqeHJEGWuEXPASsDXAFrF?= =?iso-8859-1?Q?nK0zVHMsyscftDcfB2GrM4DBOG5qYbZiVmy8g7wlz9eMT6VAdlLczrw8HL?= =?iso-8859-1?Q?VnGyVfsXIodS5u+uHIM5ANIFrujveifBUqWrq3v7I4ys1nSwiRJ2YJ5Et7?= =?iso-8859-1?Q?BpLETg2ZW/W/59XzfkZ/Xv90vMXRHjnROlGnVgUGeRPeWcOnb+R5WBioWU?= =?iso-8859-1?Q?otVRill+DsF8nvuRUiyA26XVvbe83LFKV2qgZzpM7nVQ9cvenGvpansjQT?= =?iso-8859-1?Q?EwRWyGVJ4z2nIxYizLQl0VTmsrsAuAPE3b5lW5sx0nMrizuuIeMyBMtR3E?= =?iso-8859-1?Q?arPAPuG9Q0Ac9xPguGqS3veztJuMs7x5xsTJU2nU1BDGPEg5Syq55yDS6S?= =?iso-8859-1?Q?ccFgdP17mObuOIU7mUrnd6hYnHqhbljS8TJt0KnNKxomudA0EYkuU14rme?= =?iso-8859-1?Q?7NGr03QBouCoLYYuAPr9IdYXYmxSXYW5C/I9d8mQBYlNza7zDU+Ub9zDM+?= =?iso-8859-1?Q?x2fojEB725+r2VkqaVvYvoywjaNXkS7OtvKGXDTN/MwbVb2Cy8bnSvKZSF?= =?iso-8859-1?Q?scjvMtgZ1jIITPB3HZ1b6ugyBzrQEc4=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR03MB10263.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d60e3c5f-d644-4f52-5244-08df0fd5faa8 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 07:26:21.4906 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PoJzdKdV0Wrc8aPA6zF0Rnbt6o2F1HakwhP+077YJzg6yav/jZYb3yn27n95u/K54OTZMQrJZMSBC8EB0yo6u+WDkpf7DOibBpNXJj7B26w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB8025 X-purgate-ID: tlsNG-4011c0/1789111586-510C9CFC-7178828F/0/0 X-purgate-type: clean X-purgate-size: 18936 From: Grygorii Strashko Add SCI SCMI SMC multi-agent driver documentation. It includes a detailed description of the SCMI multi-agent driver. This document explains the driver's functionality, configuration, and the compilation process. The Xen SCMI multi-agent driver is designed to provide SCMI access to system resources from different domains. Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- (no changes since v10) Changes in v10: - rephrase section about /firmware/scmi. Mentioned that this node is taken from Host DT and copied unmodified. - fix xen,reg address for secondary domains for Dom0less configuration Changes in v8: - update documentation to match the last DT format - fixed RST: "... code-block:: dts" -> ".. code-block:: dts" - update documentation with dom0less configuration example - update documentation with new param xen,dom0-sci-agent-id instead of the command line parameter Changes in v7: - update documentation in section of the xen_scmi configuration which is matched by "xen,sci" compatible instead of the direct path. Changes in v6: - remove all HVC mentions from the multi-agent doc - update sci-agent-id parameter description in the documentation - add missing Sign-of - minor fixes across the document Changes in v5: - rework multi-agent driver to leave Host Device-tree unmodified .../arm/firmware/arm-scmi.rst | 422 ++++++++++++++++++ 1 file changed, 422 insertions(+) diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi= sor-guide/arm/firmware/arm-scmi.rst index d9698f4e4b..8791bc665e 100644 --- a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst @@ -36,6 +36,8 @@ The below sections describe SCMI support options availabl= e for Xen. =20 | [1] `Arm SCMI `= _ | [2] `System Control and Management Interface (SCMI) bindings `_ +| [3] `Generic Domain Access Controllers bindings `_ + =20 Simple SCMI over SMC calls forwarding driver (EL3) ------------------------------------------------------ @@ -189,3 +191,423 @@ except explicitly enabling SCMI with "arm_sci" xl.cfg= option. -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; -> xen,force-assign-without-iommu; }; + +SCMI SMC multi-agent driver (EL3) +------------------------------------- + +The SCMI SMC multi-agent driver enables support for ARM EL3 Trusted Firmwa= re-A (TF-A) which +provides SCMI interface with multi-agent support, as shown below. + +:: + + +-----------------------------------------+ + | | + | EL3 TF-A SCMI | + +-------+--+-------+--+-------+--+-------++ + |shmem1 | |shmem0 | |shmem2 | |shmemX | + +-----+-+ +---+---+ +--+----+ +---+---+ + smc-id1 | | | | + agent1 | | | | + +-----v--------+---------+-----------+----+ + | | | | | + | | | | | + +--------------+---------+-----------+----+ + smc-id0 | smc-id2| smc-idX| + agent0 | agent2 | agentX | + | | | + +----v---+ +--v-----+ +--v-----+ + | | | | | | + | Dom0 | | Dom1 | | DomX | + | | | | | | + | | | | | | + +--------+ +--------+ +--------+ + +The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared-m= emory transport +for every Agent in the system. The SCMI Agent transport channel defined by= pair: + +- smc-id: SMC function id used for Doorbell +- shmem: shared memory for messages transfer, **Xen page aligned**. + Shared memory is mapped with the following flags: MT_DEVICE_nGnRE and _P= AGE_DEVICE, indicating that this + memory is mapped as device memory. + +The following SCMI Agents are expected to be defined by SCMI FW to enable = SCMI multi-agent functionality +under Xen: + +- Xen management agent: trusted agents that accesses to the Base Protocol = commands to configure + agent specific permissions +- OSPM VM agents: non-trusted agent, one for each Guest domain which is a= llowed direct HW access. + At least one OSPM VM agent has to be provided by FW if HW is handled onl= y by Dom0 or Driver Domain. + +The EL3 SCMI FW is expected to implement following Base protocol messages: + +- BASE_DISCOVER_AGENT (optional if agent_id was provided) +- BASE_RESET_AGENT_CONFIGURATION (optional) +- BASE_SET_DEVICE_PERMISSIONS (optional) + +The number of supported SCMI agents and their transport specifications are= SCMI FW implementation +specific. + +Compiling with multi-agent support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build with the SCMI SMC multi-agent driver support, enable Kconfig opti= on: + +:: + + CONFIG_SCMI_SMC_MA + + +Driver functionality +^^^^^^^^^^^^^^^^^^^^ + +The SCI SCMI SMC multi-agent driver implements following functionality: + +- The driver is initialized from the Xen SCMI container ``xen_scmi_config`= ` + under ``/chosen/xen`` (for example ``/chosen/xen/xen_scmi_config/scmi``)= . + Only one SCMI interface is supported. The SCMI configuration must live u= nder + the Xen SCMI container ``xen,sci`` beneath ``/chosen``. + The Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is = a child of + this "xen,sci" container; any other "arm,scmi-smc" nodes (for example un= der + "/firmware") are ignored to avoid stealing the host's SCMI OSPM instance= . + +.. code-block:: dts + + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + +.. note:: + This layout keeps the Host DT unchanged for Dom0 and baremetal Linux by + using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a + separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 + firmware enforces permissions per agent_id, so there is no conflict bet= ween + Dom0 and Xen channels. + +- The driver obtains Xen specific SCMI Agent's configuration from the Host= DT, probes Agents and + builds SCMI Agents list. The Agents configuration is taken from "scmi-se= condary-agents" + property where first item is "arm,smc-id", second - "arm,scmi-shmem" pha= ndle and third is + optional "agent_id": + +.. code-block:: dts + + chosen { + ranges; <--- set default ranges so address can be translated when pa= rsing scmi_shm node + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; <--- set default ranges so address can be translated whe= n parsing scmi_shm node + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3 + 0x82000006 &scmi_shm_4 4>; + #scmi-secondary-agents-cells =3D <3>; <--- optional, default 3 + xen,dom0-sci-agent-id =3D <0>; /* Dom0 agent ID */ + + scmi_shm_0 : sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + scmi_shm_4: sram@47ff4000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff4000 0x0 0x1000>; + }; + + // Xen SCMI management channel + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-i= d + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + }; + }; + }; + + /{ + // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI ena= bled for it + scmi_shm: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + firmware { + scmi: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem + + protocol@X{ + }; + }; + }; + }; + + This approach allows defining multiple SCMI Agents by adding Xen-specifi= c properties under + the ``/chosen`` node to the Host Device Tree, leaving the main part unch= anged. The Host DT + SCMI channel will be passed to Dom0. + + The Xen management agent is described as a ``scmi_xen`` node under the `= `xen,sci`` compatible node, + which is used by Xen to control other SCMI Agents in the system. + + All secondary agents' configurations are provided in the ``scmi-secondar= y-agents`` property with + an optional ``agent_id`` field. + + The ``agent_id`` from the ``scmi-secondary-agents`` property is used to = identify the agent in the + system and can be omitted by setting ``#scmi-secondary-agents-cells =3D = <2>``, so the Secondary + Agents configuration will look like this: + +.. code-block:: dts + + chosen { + xen { + xen_scmi_config { + compatible =3D "xen,sci"; + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + }; + }; + } + + In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to disc= over the ``agent_id`` + for each secondary agent. Providing the ``agent_id`` in the ``scmi-secon= dary-agents`` property + allows skipping the discovery call, which is useful when the secondary a= gent's shared memory is + not accessible by Xen or when boot time is important because it allows s= kipping the agent + discovery procedure. + +.. note:: + + Note that Xen is the only one entry in the system which need to know a= bout SCMI multi-agent support. + +- The driver implements the SCI subsystem interface required for configuri= ng and enabling SCMI + functionality for Dom0/hwdom and Guest domains. To enable SCMI functiona= lity for guest domain + it has to be configured with unique supported SCMI Agent_id and use corr= esponding SCMI SMC + shared-memory transport ``[smc-id, shmem]`` defined for this SCMI Agent_= id. + +- Once Xen domain is configured it can communicate with EL3 SCMI FW: + + - zero-copy, the guest domain puts/gets SCMI message in/from shmem; + - the guest triggers SMC exception with agent "smc-id" (doorbell); + - the Xen driver catches exception, do checks and synchronously forwards= it to EL3 FW. + +- the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen manag= ement agent channel on + domain destroy event. This allows to reset resources used by domain and = so implement use-case + like domain reboot. + + +Configure SCMI for Dom0 +^^^^^^^^^^^^^^^^^^^^^^^ +Set the Dom0 SCMI agent ID in the device tree using the Xen SCMI container= under ``/chosen``. +Add ``xen,dom0-sci-agent-id`` to the ``xen,sci`` node. If the property is = absent, SCMI stays +disabled for Dom0 and the SCMI nodes are removed from Dom0 DT. + +.. code-block:: dts + + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + xen,dom0-sci-agent-id =3D <0>; /* Dom0 agent ID */ + /* scmi-secondary-agents and scmi_xen as shown above */ + }; + }; + }; + +The Host DT ``/firmware/scmi`` node is copied to the Dom0 DT unmodified. H= owever, for Dom0 SCMI +configuration, Xen actually relies on ``scmi-secondary-agents`` and ``xen,= dom0-sci-agent-id`` +properties from the ``xen,sci`` container under ``/chosen``. If the ``/fir= mware/scmi`` node is +missing or disabled, or if ``xen,dom0-sci-agent-id`` is not provided, the = Dom0 SCMI agent will not +be configured. + +.. note:: + + The ``xen,dom0-sci-agent-id`` value must match the ``func_id`` and ``shm= em`` pairing provided by + the EL3 firmware for Dom0 (for example in the ``/firmware/scmi`` node). + +Configure SCMI for for guest domain with toolstack +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* In domain's xl.cfg file add **"arm_sci"** option as below + +:: + + arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" + +* In domain's xl.cfg file enable access to the "arm,scmi-shmem" which shou= ld correspond + assigned "agent_id" for the domain, for example: + +:: + + iomem =3D [ + "47ff2,1@22001", + ] + +.. note:: It's up to the user to select guest IPA for mapping SCMI shared-= memory. + +* Add SCMI nodes to the Driver domain partial device tree as in the below = example. + The "arm,smc-id" should correspond assigned agent_id for the domain: + +.. code:: + + passthrough { + scmi_shm_0: sram@22001000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x22001000 0x0 0x1000>; + }; + + firmware { + compatible =3D "simple-bus"; + scmi: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000004>; <--- smc-id for agent_id= =3D2 + shmem =3D <&scmi_shm_0>; + ... + } + } + } + +**Device specific access control** + +The XEN SCMI SMC multi-agent driver performs "access-controller" provider = function in case +EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and p= rovides the +BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agent= s have access to. +The Host DT SCMI node should have "#access-controller-cells=3D<1>" propert= y and DT devices should +be bound to the SCMI node using Access Controllers bindings [3]. + +For example: + +.. code-block:: dts + + &i2c1 { + access-controllers =3D <&scmi 0>; + }; + +Use domain's xl.cfg file **"dtdev"** property to assign SCMI devices from = toolstack to the guest: + +:: + + dtdev =3D [ + "/soc/i2c@e6508000", + ] + +.. note:: + + xl.cfg:"dtdev" need contain all nodes which are under SCMI management = (not only those which are + behind IOMMU) and passed-through to the guest domain. + +Configure SCMI for predefined domains (dom0less) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add "xen,sci_type" and "xen,sci-agent-id" properties for required DomU (= "xen,domain") node + +:: + + xen,sci_type=3D"scmi_smc_multiagent" + xen,sci-agent-id=3D2 + +* add scmi nodes to the Driver domain partial device tree the same way as = above (toolstack case) and + enable access to the "arm,scmi-shmem" according to the dom0less document= ation. For example: + +.. code-block:: dts + + scmi_shm_0: sram@22001000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x00 0x22001000 0x00 0x1000>; + -> xen,reg =3D <0x0 0x47ff2000 0x0 0x1000 0x0 0x22001000>; + -> xen,force-assign-without-iommu; + }; + +* For SCMI device access control configure pass-through devices in the gue= st partial DT according to + the dom0less documentation and ensure that devices SCMI management has "= xen,path" property set: + +Example (dom0less, multi-agent): + +.. code-block:: dts + + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Xen management channel shared memory */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_domu: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000004 &scmi_shm_domu 2>; + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; + }; + }; + }; + + xen,domain@1 { + compatible =3D "xen,domain"; + xen,sci_type =3D "scmi_smc_multiagent"; + xen,sci-agent-id =3D <2>; + /* other domain properties here */ + }; + }; + +.. code-block:: dts + + i2c@e6508000 { + ... + reg =3D <0x00 0xe6508000 0x00 0x1000>; + -> xen,path =3D "/soc/i2c@e6508000" + -> xen,reg =3D <0x0 0xe6508000 0x0 0x1000 0x0 0xe6508000>; + -> xen,force-assign-without-iommu; + }; --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:31:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:31:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415853.1645067 (Exim 4.92) (envelope-from ) id 1x4vj8-00006l-6g; Fri, 11 Sep 2026 07:31:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415853.1645067; Fri, 11 Sep 2026 07:31:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vj8-00006e-3z; Fri, 11 Sep 2026 07:31:14 +0000 Received: by outflank-mailman (input) for mailman id 1415853; Fri, 11 Sep 2026 07:31:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vj6-00006Y-91 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:31:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vj5-002sJW-Lw for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:31:11 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ae3d-e002-0a2a0a5209dd-0a2a450bd05e-4 for ; Fri, 11 Sep 2026 09:31:10 +0200 Received: from [98.137.65.204] (helo=sonic311-23.consmr.mail.gq1.yahoo.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ae3c-b7e8-0a2a450b0019-628941ccab8d-3 for ; Fri, 11 Sep 2026 09:31:10 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Sep 2026 07:31:08 +0000 Received: by hermes--production-ne1-6dbcb84f44-gmhd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 35c30668e815a5a8f301e7d03e7151e1; Fri, 11 Sep 2026 07:31:05 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789111868; bh=oEF+IFkFwoafYiOJyTp5xRVvzljf8kYJMfjjfTEgYx8=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=uQyO/jnbFDn1KmlolUDK8qcfswHROsABC2yFuVRU8bzkitANFZLxTghrGonAvdrjXjkLItVLK/E6Ngy2TzyNX8PvZI+t6rzNnDWn7OBVHsoYnHj0SONu0STuk5DorETV+Cdr58J8qtHZoDkhGPVfADnMgqgfvDchRBPrBulmfP+x1c0TzAZps5MYRoQGvs1VnWEFiNFTq3s+iYqa1SEbVt5Dv+U5hpAXtlMiZ9fJPdlWg4zYyhmMb3jb+dGAVmkYSf7g/1Sdo/Kxkle4I2JVBCIhBaa9Ux+/V++VoOG7pVO9Esi0vt2TRqhnNTHbiFJ4BO/XDOBiZFjFaG7vmeFNMg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789111868; bh=Imkblp6PdzvIL8+yX02ciwbI/w5m1cEMrfyThSPk6Tf=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=DwUXATuAHsmRLXv4gvas+2gGKXDrlUH1DaaK94OvJa3hiUWBtrhul/eoRYUd53sfmxubu+VbHpBSOX4Lu7FKVPinbBjKyy9GkuoUVXqaiXSwD7cO9D7biBu+YKZaPqh774u8QBKCn0t6nr+4vHM3BmpiJ39hKxIwnZZfXzvNDVWkDj8u87arLplqjqgtEzvN6LTNFDndg2GnRiaHG5LPd1IweDH34SN8cr0YVO9vUinJbNKBFXB0mZV+6z+0WYZhXjAVJJ5WGh9r8LAdaEEVz9nAj7Rh4vKv4DbgjV3rp0gO8Dq6PTO2knGREytYexuOECXtsAbQHUgnmO3d+fb8MA== X-YMail-OSG: _hsesV8VM1nGiipDOsndukFlWUf3W1f1496y6RhLwLRX_6t_R7ZCgvp2qVc2JPS bBD.N1ARLeEhXCmfEN7642NHXoAiiWfLdHY2z_AAS7S3YIRk3DcnRp1wu5aU95kRf1rA3ZYfSea2 Vn3fzG3O9vLAr3YmYRNgdytgckSZ7cFiTk0o59EkyATuXQ_QnNAHHzgHMpkzpIW12smnm7Xvn.PI RPZ0Tb3NacoMajfozP0JblHpOoyThe05SA2eoRJYvJU42r.5Q7F9onMBEr2dGa6XitSUnEeOgdMw 7TpjRB.9ViDOrKJSOrUuAbWdotNrAdXWFwZ7U31ypryhdfjl5kcvBOBmfs7Q.8HtyE1Rbq86GVQA AVYHrvpW3bNypDs.c_ZZIqbHH0W7UtHqqhvN_U_7uhy6iNFPYpjwrRTwlFzBSuk5MaPI_VKLfueT Yty0BADVhnqOf3k.Myxtfd123b.O5V22PBtdPcyfS6xAaKzd.tEc8VrAOIMjDOupD9mvVfi4Ni3f 1BrEwA86gU3o5_bvWOlon3ACpAp3ZD5tzaOEfT7RvrH9NGzZ0xP.E.VByJQ.eTXNUNVCtQRQa6uB jN0x2dMg4q4W5dHJ.n9QUrdBTnXvmfU.4pfF1H5J0Ly4gaqC59lG_tO8ArOANZYIV82LXGNhM2gn 2.4MhYiVDB0Yj6bfHqrqTNE7cL8Yp_J6gfMhctj4MbERxX8ZSYfpySVYG2k2kSf6fVDrA0qgPYRK ZlsPkoVQZvU.o23hxeip8hAGGF.pzCDlOHSqf8DY6A_w_q41l9CCyYSd4jRkA1X1q0vpZ0ODYuCl pw.SwhPJ7rX0BpPAa56Kf.8ysKghrFw2G5eeGfwJEDZL1Dqksls9BlP81OpFEYorP8OEBfc8T916 eYV0kjJg6gfxkm9.GL8SCrYeXHBLJ5no6Y7EJYSiLM5erZO7UxBQe3ey0h5wl0DCRqZfQSvHkJc_ fnJZgtCmgTILJo5rlta50SDmw4i2bQzI8T3BQX9jwttBOqgxFDo5WG4qGT3.Xv9OGt1eWQTMeWjc MNHef.uxOw.B1mhUqw1lUoDWEHi9vg7FJkAj9c5vcis3VBQGip0xgy5vG4u6EMy4Rk6Gv5xEnKZX IMxhgtyubI5k0LhzjvgYQPCA6dG6IhawfMEqg7JGLL1m3OCB7a1g5q8hT8tlNQAdexIyK40qGMZ2 jfBZCiemA4wIHahPTytz7jpdxJTQ3.uNiWuQzafZjkSTTmtMDMUEiDZsGZIPvuxS8Yhyc7Y8ttRC zIQnwLQSBNznVjk.Yk7CrAAXy8qUjmE2P26tII4OzF5mdPpAK9gfpJkFkymUcX0YXnoWFxWMPdSE 7_JdGI89vV88mEeemnn7q6Y1M8XH2czRcqcpP9sfTbiHkhFeYhDvsOxeKECn94o6SeClgDUzpTrk np_Jt.tsfOr508omr8NGG6P.g6c.ezsoX2mPPjd5FBfl.XtO5upH0Ja9icXqHNmglsP6N8nwKvs3 ED74BwOZgMUmW4ogQeg1oSTr8OmcHQ9a8uesJHKUoLyvlJiFsNIPNe6wB1r.avwWXIi_CcuI1kbI 02RO03wqhUnoWEjMsx5NLCfn0IOtX26eJKcGVmA7o5YQuMFTrztbcFtOpLZxOFosaHywde6UrmF6 k3YUNsZ0sb1E1wS7.ixAFdR2u8lswJ9NTNjtMK1gjtulh66jh09lQuYhdf58SwIMrpWVMWQVhIo9 S6TsPzyKRFbOBIdg7kOpVpUW9H3oaLouaxhVanPs6q5_GH4FQG6quCbN1OSwHDIo1Rj7sdW0OUQL UiZACgzloD9CJhoZLzMva7E6BmS5sOJ7Z0uS8_iY8zyXWl71YH81O72m_u0uuKR_IuStiE3z8G3m 4MJOceeKJejs9izJFPVmcgbPwje43788GVMkBcn65sL1McZtaQMEYkbzaDrpq2R5YwKgOWt54ysX NcrJgZokS.qSUgPPNsfCSLYhH4gwPkSpIf5E5kCX_PLR.mPpR2Pr3qXdkIz47tAqdaIt1E01vd2E AzfO4qsmlgnOBSCIAfrwoKtTxEFBxFL9i7HwpSVvQ5AnkP4QgGrBjT7cqKiCJumTd6PEM3Ske3i_ xP7g4r6NZe5a6GoQnWvuqCScUSWLGNazmDx617DUmAzg1wvWGlH5P8TCznqzVjKE_1gECz5orJOO 4lE1xj7qWs6DKx2cIhBi2x4lnIAEcmUKrlhZ1dEJ5DoMj3ynPptJZpvX8ZMPeCUQ7kprpYrEWRDG HyDcSaFVmc61j8nnRPS5Ci9FVpr2Nns0Ko5c41Q-- X-Sonic-MF: X-Sonic-ID: b036158c-adfc-485b-9f97-582b3a4c444c From: Chuck Zmudzinski To: xen-devel@lists.xenproject.org Cc: qemu-devel@nongnu.org, Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3] tools/hvmloader: implement Intel IGD extended VBT support Date: Fri, 11 Sep 2026 03:31:03 -0400 Message-ID: <20260911073103.46745-1-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit References: <20260911073103.46745-1-brchuckz.ref@aol.com> Content-Length: 21554 X-purgate-ID: tlsNG-42698a/1789111870-18CCF9EA-C46561BA/0/0 X-purgate-type: clean X-purgate-size: 21957 Modern Intel IGD devices do not work well with the current implementation of support for the Intel IGD in hvmloader because it lacks support for an extended video bios table (VBT). Code 43 errors in Windows guests and failure of the guest screen to light up are some of the problems that occur with the current implementation. To address this problem, this patch implements support for Intel IGD devices with an extended VBT and OpRegion version 2+ which is required for most modern Intel IGD devices, as noted in the Linux kernel vfio commits referenced in the Link tags below. This patch ports support for devices with an extended VBT and OpRegion 2+ which was added in those commits for KVM/vfio, but adapted for Xen HVM guests with PCI passthrough. This patch depends on compatible support in the device model. If hvmloader detects the device model lacks such support, it will fall back to the currently implemented protocol for configuring the OpRegion to provide backward compatibiltiy for systems that lack a device model with support for an extended VBT. The primary reason the OpRegion needs to be patched in some cases is that with the addition of the RVDA and RVDS fields to the OpRegion, the OpRegion is not position-independent and may need to be patched if it is moved to a different address in the guest. This means the current protocol of having the device model directly map the unmodified host OpRegion to the guest is not compatible with the requiremnts of the newer devices that in some cases require that the OpRegion be modified for it to be compatible with the guest address space. In this implementation, the device model has the responsibility to read the host OpRegion and patch it as needed before exposing it to the guest. Since an extended VBT means more pages are needed for the OpRegion, depending on the size of the extended VBT, hvmloader has the responsibility to edit the E820 map to accomodate the additional pages needed to contain the OpRegion + VBT. To implement this in hvmloader, use a variable, igd_opregion_e820_pages, instead of the constant, IGD_OPREGION_PAGES, to represent the number of pages to reserve in the E820 map for the OpRegion + VBT. Also, to remove the confusion introduced by setting IGD_OPREGION_PAGES to 3 in an earlier patch to account for the fact that the OpRegion is not guaranteed to be aligned on a page boundary, reset IGD_OPREGION_PAGES to 2 so it matches the actual size of the OpRegion. Instead of only writing to the PCI_INTEL_OPREGION register, first read from it to provide a way for both hvmloader and the device model to discover if both components have support for an extended VBT and more than 3 pages reserved for the OpRegion + VBT. The device model detects the read of the register before the write to learn that hvmloader has support, and hvmoader detects that the device model returns the number of pages to reserve for the OpRegion + VBT instead of 0 when it first reads the register to learn that that the device model has support. When this new protocol is supported by both hvmloader and the device model, the device model will not expose the host OpRegion directly to the guest via a direct mapping as the old protocol does but instead exposes an emulated copy of the OpRegion and VBT using its ioreq server. This has the added beneift of preventing extraneous host memory in the regions before or after a non-page-aligned OpRegion that should be confidential to the host from being exposed to the guest. Testing reveals that when the device model exposes the OpRegion to the guest by mapping it to the device model's ioreq server, the Windows Intel IGD graphics dirvers are unable to access the OpRegion and report Code 43 errors with the result being that the guest screen never lights up. So after the device model exposes the OpRegion to the guest using its ioreq server, make a copy of it and use a copy of the OpRegion and VBT which is backed by RAM allocated to the guest instead of mapped via the ioreq server. This fixes the Code 43 errors reported by the Windows IGD graphics drivers. Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=bab2c1990b78 Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=49ba1a2976c8 Signed-off-by: Chuck Zmudzinski --- The companion patchset for the device model (DM) is available here: https://lore.kernel.org/qemu-devel/20260911072453.46256-7-brchuckz@aol.com/ Note that this patch uses an approach that is not compatible with earlier versions of the patchset for the DM. The version of that patchset that is compatible with this patch is v6. Up-to-date specifications for the Intel IGD are not available to the public but an older version is available from Intel here: https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/opregion-specification.html This patch derives the specifications for the OpRegion that are needed to add support for an extended VBT from the patches to the Linux kernel vfio driver. This mainly consists of the RVDA and RVDS fieds of the OpRegion which store the address and size of the extended VBT, respectively. See the links in the commit message which provide links to the vfio patches that added support for this feature to KVM/VFIO guests for more details. There is an undocumented setting that works in the xl.cfg(5) domain configuration file, firmware_override, that makes it possible to use a patched version of hvmloader alongside an installation of unpatched upstream Xen or a version of Xen packaged by a distro. So one can download the source for one's installed version of Xen, apply this patch and build just hvmloader and then install the patched version of hvmloader with a different filename, such as hvmloader-igd-testing, into the same directory where hvmloader is installed (usually something like /usr/libexec/xen/boot) and then one can configure a guest to use the patched version of hvmloader with one's installed version of Xen by adding a line like this to the domain xl.cfg file: firmware_override = 'hvmloader-igd-testing' The compatible patch for the DM is part of a larger patchset that fixes many of the problems that currently affect the feature of Intel IGD passthrough to Xen HVM guests. This patch should be considered as a companion patch to that patchset for the DM. Do not try to test this patch with a real Intel IGD device without also applying the patchset for the DM because without those patches, the guest will most likely fail to start if an Intel IGD is passed through to the guest. Changes in v3: - The patch has been substantially re-worked. Most of the implementation of support for Intel IGD in v2 that could be implemented in the DM instead of in hvmloader has been moved to the DM. Specifically, the responsibility to read the OpRegion and patch it if necessary is done in the DM instead of in hvmloader. This change is in response to the comments that were made on v2 of this patch. - In contrast to both the current implementation and the implementation in v2, the host OpRegion is never directly exposed to the guest. Instead, the DM exposes an emulated copy of the OpRegion to the guest, patched appropriately for the guest, using the DM's ioreq server. - Hvmloader's main responsibility is to allocate enough pages in the E820 map to accomodate both the OpRegion and the extended VBT. In v3, hvmloader relies on the DM to communicate the number of pages that are needed for the OpRegion + VBT, and this change means all the code in v2 related to discovering the size of the extended VBT has been removed from hvmloader in v3 and moved to the DM. - Backward compatibility with versions of the DM that do not support an extended VBT has been simplified. There is no need for a bitmask setting to indicate support for extended VBT and OpRegion 2 and higher. Instead, the DM learns that hvmloader has support by detecting a read of the OpRegion register before a write to it, and hvmloader learns that the DM has support if the DM returns a non-zero value, the number of pages needed for the OpRegion + VBT, in response to the first read by hvmloader. - It was necessary to retain the code that populates the pages allocated for the OpRegion and VBT with guest RAM and copying the OpRegion and VBT to that guest RAM because testing revealed that when the OpRegion and VBT are exposed to the guest by the DM's ioreq server, Windows graphics drivers are unable to access the OpRegion and VBT. - To remove the confusion with the value of IGD_OPREGION_PAGES that is currently set to 3 to account for the fact that the OpRegion is not always aligned on a page boundary, it has been changed in v3 to 2, the actual number of pages needed for the OpRegion (not including an extended VBT). - Added a check on the number of pages needed for the OpRegion + VBT to ensure the region does not take up an unreasonably large percentage of the reserved dynamic memory range. I also provide the following table that hopefully helps illustrate how v3 of this patch differs from v2: Resource/Description Proposed in v2 Proposed in v3 ------------------------------------------------------------------------------ OpRegion register Emulated in DM Emulated in DM ------------------------------------------------------------------------------ OpRegion Emulated (hvmloader Emulated in DM (guest makes a copy from direct accesses emulated copy mapped host OpRegion provided by DM and and from then on guest from then on guest accesses its own copy accesses its own copy stored in guest memory) stored in guest memory) ------------------------------------------------------------------------------ Extended VBT Emulated (hvmloader Emulated in DM (guest makes a copy from direct accesses emulated copy mapped host VBT and provided by DM and from from then on guest then on guest accesses accesses its own copy its own copy stored in stored in guest memory) guest memory) ------------------------------------------------------------------------------ E820 pages allocated Depends on extended VBT Depends on extended VBT size if there is an size if there is an extended VBT extended VBT ------------------------------------------------------------------------------ If OpRegion needs patching hvmloader patches it DM patches it ------------------------------------------------------------------------------ Setting the OpRegion Done by DM after complex Done by DM with hint register communication protocol from hvmloader which with hvmloader completes provides DM with page base address of OpRegion in guest ------------------------------------------------------------------------------ Changes in v2: - Correct the name of the new function in the commit message opregion_setup() -> intel_opregion_setup() - Add a link to the companion patchset for the device model - Describe how to use the firmware_override setting in xl.cfg(5) to simplify testing of this patch. - Correct a logical flaw that in case the size of the extended VBT is <= 2 pages, an extra, unnecessary page would be allocated in the memory hole. This correction is in the intel_opregion.c file. This code: /* Update the number of pages we need for the E820 map */ igd_opregion_e820_pages = pages_needed; /* * So far we have allocated vbt_pages_needed * and we will likely need to allocate more * pages to fully contain OpRegion + VBT. */ if ( pages_needed > vbt_pages_needed ) igd_opregion_pgbase = mem_hole_alloc (pages_needed - vbt_pages_needed); Is replaced with this code: /* * So far we have allocated igd_opregion_e820_pages * and we will likely need to allocate more * pages to fully contain OpRegion + VBT. */ if ( pages_needed > igd_opregion_e820_pages ) igd_opregion_pgbase = mem_hole_alloc (pages_needed - igd_opregion_e820_pages); /* Update the number of pages we need for the E820 map */ igd_opregion_e820_pages = pages_needed; tools/firmware/hvmloader/config.h | 6 +- tools/firmware/hvmloader/e820.c | 4 +- tools/firmware/hvmloader/pci.c | 96 ++++++++++++++++++++++++++++++- 3 files changed, 100 insertions(+), 6 deletions(-) diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h index c159db3..edc3a8d 100644 --- a/tools/firmware/hvmloader/config.h +++ b/tools/firmware/hvmloader/config.h @@ -8,7 +8,8 @@ enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt }; extern enum virtual_vga virtual_vga; extern unsigned long igd_opregion_pgbase; -#define IGD_OPREGION_PAGES 3 +extern unsigned int igd_opregion_e820_pages; +#define IGD_OPREGION_PAGES 2 struct bios_config { const char *name; @@ -75,6 +76,9 @@ extern bool acpi_enabled; #define ACPI_MEMORY_DYNAMIC_START 0xFC001000 #define RESERVED_MEMORY_DYNAMIC_START 0xFC100000 #define RESERVED_MEMORY_DYNAMIC_END 0xFE000000 +#define RESERVED_MEMORY_DYNAMIC_PAGES (RESERVED_MEMORY_DYNAMIC_END - \ + RESERVED_MEMORY_DYNAMIC_START) >> \ + PAGE_SHIFT /* * GUEST_RESERVED: Physical address space reserved for guest use. * This is not dynamically advertised to guests, so this range must *never* diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c index 86d3954..97a234e 100644 --- a/tools/firmware/hvmloader/e820.c +++ b/tools/firmware/hvmloader/e820.c @@ -243,11 +243,11 @@ int build_e820_table(struct e820entry *e820, nr++; e820[nr].addr = igd_opregion_base; - e820[nr].size = IGD_OPREGION_PAGES * PAGE_SIZE; + e820[nr].size = igd_opregion_e820_pages * PAGE_SIZE; e820[nr].type = E820_NVS; nr++; - e820[nr].addr = igd_opregion_base + IGD_OPREGION_PAGES * PAGE_SIZE; + e820[nr].addr = igd_opregion_base + igd_opregion_e820_pages * PAGE_SIZE; e820[nr].size = (uint32_t)-e820[nr].addr; e820[nr].type = E820_RESERVED; nr++; diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c index c41c8d9..efe6b68 100644 --- a/tools/firmware/hvmloader/pci.c +++ b/tools/firmware/hvmloader/pci.c @@ -44,6 +44,7 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; enum virtual_vga virtual_vga = VGA_none; unsigned long igd_opregion_pgbase = 0; +unsigned int igd_opregion_e820_pages = 0; /* Check if the specified range conflicts with any reserved device memory. */ static bool check_overlap_all(uint64_t start, uint64_t size) @@ -93,6 +94,9 @@ void pci_setup(void) uint16_t class, vendor_id, device_id; unsigned int bar, pin, link, isa_irq; uint8_t pci_devfn_decode_type[256] = {}; + uint32_t igd_opregion; + void *opregion_vbt_scratch; + bool opregion_is_direct_mapped; /* Resources assignable to PCI devices via BARs. */ struct resource { @@ -192,12 +196,98 @@ void pci_setup(void) { igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES); /* - * Write the the OpRegion offset to give the opregion - * address to the device model. The device model will trap - * and map the OpRegion at the give address. + * To be compatible with this interface for programming the + * the PCI_INTEL_OPREGION register, the device model must + * check if the guest reads the register before it writes + * to the register. To indicate to the device model that + * we have support for an extended VBT, we read the + * PCI_INTEL_OPREGION register before writing to it. If the + * device model supports an extended VBT, it will return + * the number of pages needed for the OpRegion + VBT. If + * not, it will return 0 which indicates that it does not + * implement this interface for supporting an extended VBT. + */ + igd_opregion_e820_pages = pci_readl(vga_devfn, + PCI_INTEL_OPREGION); + if ( !igd_opregion_e820_pages ) + { + /* + * This case provides backward compatibility with + * device model versions that lack support for an + * extended VBT. In this case the device model + * expects us to allocate an extra page in case the + * OpRegion is not aligned on a page boundary. Also, + * in this case, the host OpRegion is direct mapped + * into the guest. + */ + igd_opregion_pgbase = mem_hole_alloc(1); + igd_opregion_e820_pages = IGD_OPREGION_PAGES + 1; + opregion_is_direct_mapped = true; + } + else + { + /* Allocate extra pages for an extended VBT */ + if ( igd_opregion_e820_pages > IGD_OPREGION_PAGES ) + { + igd_opregion_pgbase = + mem_hole_alloc(igd_opregion_e820_pages - + IGD_OPREGION_PAGES); + } + opregion_is_direct_mapped = false; + } + /* + * This ensures the OpRegion + VBT does not take up more + * than 1/32 of the reserved region. Also, we must reject + * a value of 1 for igd_opregion_e820_pages. + */ + if ( igd_opregion_e820_pages > + RESERVED_MEMORY_DYNAMIC_PAGES >> 5 || + igd_opregion_e820_pages == 1 ) + { + printf("too many or too few pages (%u) for OpRegion\n", + igd_opregion_e820_pages); + BUG(); + } + /* + * Write the the OpRegion offset to give the OpRegion + * address to the device model. The device model will trap + * and make the OpRegion accessible at the given address. + * The device model is also expected to verify that the + * OpRegion is compatible with the guest address space and + * patch it if necessary to make it compatible. */ pci_writel(vga_devfn, PCI_INTEL_OPREGION, igd_opregion_pgbase << PAGE_SHIFT); + + /* Don't use our own copy if OpRegion is direct mapped */ + if ( opregion_is_direct_mapped ) + break; + + /* + * Windows IGD drivers do not work properly when the + * OpRegion is exposed by the device model's ioreq server, + * so make a copy of the OpRegion and use that copy which + * will be backed by RAM allocated to the guest. + */ + opregion_vbt_scratch = + scratch_alloc(igd_opregion_e820_pages << + PAGE_SHIFT, 0); + memcpy(opregion_vbt_scratch, + (void *)(igd_opregion_pgbase << PAGE_SHIFT), + igd_opregion_e820_pages << PAGE_SHIFT); + + igd_opregion = pci_readl(vga_devfn, PCI_INTEL_OPREGION); + /* + * The device model will unmap the OpRegion from the ioreq + * server so we can use our own copy of the OpRegion. + */ + pci_writel(vga_devfn, PCI_INTEL_OPREGION, igd_opregion); + + mem_hole_populate_ram(igd_opregion_pgbase, + igd_opregion_e820_pages); + memcpy((void *)(igd_opregion_pgbase << PAGE_SHIFT), + opregion_vbt_scratch, + igd_opregion_e820_pages << PAGE_SHIFT); } } break; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:45:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:45:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415867.1645077 (Exim 4.92) (envelope-from ) id 1x4vxE-0002Sx-BU; Fri, 11 Sep 2026 07:45:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415867.1645077; Fri, 11 Sep 2026 07:45:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vxE-0002Sq-8r; Fri, 11 Sep 2026 07:45:48 +0000 Received: by outflank-mailman (input) for mailman id 1415867; Fri, 11 Sep 2026 07:45:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vxC-0002Sk-DO for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:45:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vxB-002uwp-1f for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:45:45 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3b19d-8faa-0a2a0a5109dd-0a2a4508b71a-22 for ; Fri, 11 Sep 2026 09:45:44 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3b1a8-f659-0a2a45080019-c387df83e8b0-3 for ; Fri, 11 Sep 2026 09:45:44 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 2C7051FD65; Fri, 11 Sep 2026 07:45:36 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CBE9B136ED; Fri, 11 Sep 2026 07:45:33 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id SsloMJ2xo2qtWAAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 07:45:33 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789112740; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=1QSWKaNZ65L3rk2qSG3qEF6vvEFGDlwFz8pe7qA3wNk=; b=T8vJzNG0WjXD9oew4znbnpRhNr4cduF4wX0/G5JWBAhNh6q/VIfpYf/fUBkcVm6cROP8wL d7Tw6tNJd2/Uc1yaaCnSKMf45wB90ggC7/6aHgHKt1AvwLS+V6Grbb4BaDss/ymuQh3uLX R/JPn7ajI9jOWOy+wgo92RQhnyBQ8B8= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789112736; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=1QSWKaNZ65L3rk2qSG3qEF6vvEFGDlwFz8pe7qA3wNk=; b=ZSaFHXZmagMuB8+hqr9P5F1w2lKBV8EJ76ulznETppNd368ICMAo96FZHFm26sndOkLQBp DO+Ed5uvBjbKGWvwO62oqlUwSJ+KvFdOyo/zUKikLlBjGWA7ZER+RlKfHf4bve8r2bw+Br b2AR8rC+XGluiV1AFzZUGzhvWzUsaEo= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Damien Le Moal , Niklas Cassel , David Airlie , Helge Deller , linux-geode@lists.infradead.org, Olivia Mackall , Herbert Xu , Linus Walleij , Bartosz Golaszewski , Arnd Bergmann , Greg Kroah-Hartman , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , xen-devel@lists.xenproject.org Subject: [PATCH v3 00/13] x86/msr: Drop 32-bit MSR interfaces Date: Fri, 11 Sep 2026 09:45:17 +0200 Message-ID: <20260911074530.3140830-1-jgross@suse.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.30 X-Spam-Level: X-Spamd-Result: default: False [-1.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[suse.com,kernel.org,redhat.com,alien8.de,linux.intel.com,zytor.com,broadcom.com,gmx.de,lists.infradead.org,selenic.com,gondor.apana.org.au,arndb.de,linuxfoundation.org,infradead.org,arm.com,google.com,intel.com,linaro.org,microsoft.com,hygon.cn,amd.com,zhaoxin.com,oracle.com,roeck-us.net,gmail.com,bootlin.com,nod.at,ti.com,lists.xenproject.org]; R_RATELIMIT(0.00)[to_ip_from(RLbixyxwsf3a5i7e4ez64ejni4)]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_GT_50(0.00)[95]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-purgate-ID: tlsNG-c1860d/1789112744-CCF4F87B-AF2A2B64/0/0 X-purgate-type: clean X-purgate-size: 10159 For accessing the MSR registers on the local CPU, there are 2 types of interfaces: the "modern" 64-bit ones (rdmsrq() etc.) and the 32-bit ones (rdmsr() etc.) which are using the upper and lower 32-bit halves of the 64-bit wide MSR register values. The 32-bit interfaces are not optimal for 3 reasons: - They are based on primitives using 64-bit sized values anyway. - Modern x86 CPUs have added support for MSR access instructions using an immediate value instead of a register for addressing the MSR, while the value is in a 64-bit register. - rdmsr() is a macro storing the upper and lower 32-bit halves in variables specified as macro parameters. This is obscuring variable assignment through a macro. Additionally rdmsrq() is mimicking this pattern by being a macro, too, with the target variable specified as a parameter as well. For those reasons drop the 32-bit interfaces for accessing the x86 MSR registers completely and only use the 64-bit variants. This allows to switch all "high-level" MSR access macros to inline functions in the end. This series will be used as the base for further reorganisation of the MSR access functions, especially for completely inlining the MSR access instructions even with paravirtualization being active. Based on kernel 7.3 as of 2026-09-11. Changes in V2: - dropped already applied patches - added patch 1 - rebased Changes in V3: - small fixes in patches 4 and 13 - rebased Juergen Gross (13): x86/cpu: Fix coding style violation x86/msr: Remove wrmsr_safe() x86/msr: Remove rdmsr_safe() drivers/ata: Stop using 32-bit MSR interfaces agp/nvidia: Stop using 32-bit MSR interfaces fbdev/geode: Stop using 32-bit MSR interfaces hw_random/via-rng: Stop using 32-bit MSR interfaces drivers/gpio: Stop using 32-bit MSR interfaces drivers/misc: Stop using 32-bit MSR interfaces x86/msr: Remove wrmsr() x86/msr: Remove rdmsr() treewide: convert rdmsrq() from a macro to an inline function x86/msr: Simplify some rdmsrq() use cases arch/x86/coco/sev/core.c | 2 +- arch/x86/events/amd/brs.c | 4 +- arch/x86/events/amd/core.c | 8 +-- arch/x86/events/amd/ibs.c | 18 +++---- arch/x86/events/amd/lbr.c | 16 ++---- arch/x86/events/amd/power.c | 8 +-- arch/x86/events/amd/uncore.c | 4 +- arch/x86/events/core.c | 20 ++++---- arch/x86/events/intel/core.c | 15 ++---- arch/x86/events/intel/cstate.c | 5 +- arch/x86/events/intel/ds.c | 2 +- arch/x86/events/intel/knc.c | 10 ++-- arch/x86/events/intel/lbr.c | 25 +++------- arch/x86/events/intel/p4.c | 6 +-- arch/x86/events/intel/p6.c | 4 +- arch/x86/events/intel/pt.c | 12 ++--- arch/x86/events/intel/uncore.c | 6 +-- arch/x86/events/intel/uncore_nhmex.c | 4 +- arch/x86/events/intel/uncore_snb.c | 2 +- arch/x86/events/intel/uncore_snbep.c | 6 +-- arch/x86/events/msr.c | 2 +- arch/x86/events/perf_event.h | 6 +-- arch/x86/events/rapl.c | 6 +-- arch/x86/events/zhaoxin/core.c | 10 ++-- arch/x86/hyperv/hv_apic.c | 9 ++-- arch/x86/hyperv/hv_init.c | 26 +++++----- arch/x86/hyperv/hv_spinlock.c | 2 +- arch/x86/include/asm/apic.h | 7 +-- arch/x86/include/asm/debugreg.h | 6 +-- arch/x86/include/asm/fsgsbase.h | 2 +- arch/x86/include/asm/kvm_host.h | 10 ---- arch/x86/include/asm/msr.h | 39 ++------------- arch/x86/include/asm/paravirt.h | 26 +--------- arch/x86/kernel/apic/apic.c | 14 +++--- arch/x86/kernel/apic/apic_numachip.c | 6 +-- arch/x86/kernel/cet.c | 2 +- arch/x86/kernel/cpu/amd.c | 14 +++--- arch/x86/kernel/cpu/aperfmperf.c | 8 +-- arch/x86/kernel/cpu/bugs.c | 12 ++--- arch/x86/kernel/cpu/bus_lock.c | 8 +-- arch/x86/kernel/cpu/centaur.c | 8 +-- arch/x86/kernel/cpu/common.c | 12 ++--- arch/x86/kernel/cpu/feat_ctl.c | 4 +- arch/x86/kernel/cpu/hygon.c | 4 +- arch/x86/kernel/cpu/intel.c | 6 +-- arch/x86/kernel/cpu/intel_epb.c | 4 +- arch/x86/kernel/cpu/mce/amd.c | 4 +- arch/x86/kernel/cpu/mce/core.c | 8 +-- arch/x86/kernel/cpu/mce/inject.c | 2 +- arch/x86/kernel/cpu/mce/intel.c | 18 +++---- arch/x86/kernel/cpu/mce/p5.c | 8 +-- arch/x86/kernel/cpu/mce/winchip.c | 2 +- arch/x86/kernel/cpu/microcode/intel.c | 2 +- arch/x86/kernel/cpu/mshyperv.c | 6 +-- arch/x86/kernel/cpu/mtrr/amd.c | 4 +- arch/x86/kernel/cpu/mtrr/cleanup.c | 4 +- arch/x86/kernel/cpu/mtrr/generic.c | 32 ++++++------ arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +- arch/x86/kernel/cpu/resctrl/core.c | 2 +- arch/x86/kernel/cpu/resctrl/monitor.c | 4 +- arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 +- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +- arch/x86/kernel/cpu/topology.c | 2 +- arch/x86/kernel/cpu/topology_amd.c | 4 +- arch/x86/kernel/cpu/transmeta.c | 8 +-- arch/x86/kernel/cpu/tsx.c | 10 ++-- arch/x86/kernel/cpu/umwait.c | 2 +- arch/x86/kernel/cpu/zhaoxin.c | 4 +- arch/x86/kernel/fpu/core.c | 2 +- arch/x86/kernel/hpet.c | 2 +- arch/x86/kernel/kvm.c | 2 +- arch/x86/kernel/mmconf-fam10h_64.c | 6 +-- arch/x86/kernel/process.c | 4 +- arch/x86/kernel/process_64.c | 14 +++--- arch/x86/kernel/shstk.c | 8 +-- arch/x86/kernel/traps.c | 4 +- arch/x86/kernel/tsc.c | 2 +- arch/x86/kernel/tsc_msr.c | 6 +-- arch/x86/kernel/tsc_sync.c | 6 +-- arch/x86/kvm/msrs.c | 2 +- arch/x86/kvm/svm/pmu.c | 4 +- arch/x86/kvm/svm/svm.c | 4 +- arch/x86/kvm/vmx/nested.c | 4 +- arch/x86/kvm/vmx/pmu_intel.c | 8 +-- arch/x86/kvm/vmx/sgx.c | 6 +-- arch/x86/kvm/vmx/tdx.c | 2 +- arch/x86/kvm/vmx/vmx.c | 42 ++++++++-------- arch/x86/kvm/x86.c | 6 +-- arch/x86/lib/insn-eval.c | 6 +-- arch/x86/lib/msr-smp.c | 2 +- arch/x86/mm/pat/memtype.c | 2 +- arch/x86/pci/amd_bus.c | 8 +-- arch/x86/platform/olpc/olpc-xo1-rtc.c | 6 +-- arch/x86/platform/olpc/olpc-xo1-sci.c | 2 +- arch/x86/power/cpu.c | 10 ++-- arch/x86/realmode/init.c | 2 +- arch/x86/virt/hw.c | 8 +-- arch/x86/virt/svm/sev.c | 18 +++---- arch/x86/virt/vmx/tdx/tdx.c | 2 +- arch/x86/xen/suspend.c | 2 +- drivers/acpi/processor_perflib.c | 2 +- drivers/ata/pata_cs5535.c | 24 ++++----- drivers/ata/pata_cs5536.c | 17 +++---- drivers/char/agp/nvidia-agp.c | 32 ++++++------ drivers/char/hw_random/via-rng.c | 29 +++++------ drivers/cpufreq/acpi-cpufreq.c | 8 +-- drivers/cpufreq/amd-pstate.c | 4 +- drivers/cpufreq/e_powersaver.c | 20 ++++---- drivers/cpufreq/intel_pstate.c | 28 +++++------ drivers/cpufreq/longhaul.c | 12 ++--- drivers/cpufreq/longrun.c | 16 +++--- drivers/cpufreq/powernow-k7.c | 10 ++-- drivers/cpufreq/powernow-k8.c | 8 +-- drivers/cpufreq/speedstep-centrino.c | 4 +- drivers/cpufreq/speedstep-lib.c | 14 +++--- drivers/edac/amd64_edac.c | 6 +-- drivers/gpio/gpio-cs5535.c | 10 ++-- drivers/hv/mshv_vtl_main.c | 2 +- drivers/hwmon/hwmon-vid.c | 4 +- drivers/idle/intel_idle.c | 26 +++++----- drivers/misc/cs5535-mfgpt.c | 33 ++++++------ drivers/mtd/nand/raw/cs553x_nand.c | 6 +-- drivers/platform/x86/intel/ifs/load.c | 10 ++-- drivers/platform/x86/intel/ifs/runtest.c | 8 +-- drivers/platform/x86/intel/pmc/cnp.c | 2 +- .../intel/speed_select_if/isst_if_mbox_msr.c | 6 +-- .../intel/speed_select_if/isst_tpmi_core.c | 2 +- drivers/platform/x86/intel_ips.c | 20 ++++---- drivers/powercap/intel_rapl_msr.c | 2 +- drivers/thermal/intel/intel_hfi.c | 8 +-- drivers/thermal/intel/therm_throt.c | 22 ++++---- drivers/thermal/intel/x86_pkg_temp_thermal.c | 6 +-- drivers/video/fbdev/geode/display_gx.c | 8 +-- drivers/video/fbdev/geode/gxfb_core.c | 2 +- drivers/video/fbdev/geode/lxfb_ops.c | 50 +++++++++---------- drivers/video/fbdev/geode/suspend_gx.c | 24 +++++---- drivers/video/fbdev/geode/video_gx.c | 8 +-- include/linux/cs5535.h | 10 ++-- 138 files changed, 575 insertions(+), 694 deletions(-) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:46:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:46:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415868.1645086 (Exim 4.92) (envelope-from ) id 1x4vxV-0002il-Mo; Fri, 11 Sep 2026 07:46:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415868.1645086; Fri, 11 Sep 2026 07:46:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vxV-0002ie-JU; Fri, 11 Sep 2026 07:46:05 +0000 Received: by outflank-mailman (input) for mailman id 1415868; Fri, 11 Sep 2026 07:46:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vxU-0002i1-7l for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:46:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vxT-004rrI-11 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:46:03 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3b1a7-2eae-0a2a0a5409dd-0a2a45018e6e-44 for ; Fri, 11 Sep 2026 09:46:01 +0200 Received: from [40.107.208.53] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3b1b8-5984-0a2a45010019-286bd035ac58-3 for ; Fri, 11 Sep 2026 09:46:01 +0200 Received: from SJ0PR13CA0015.namprd13.prod.outlook.com (2603:10b6:a03:2c0::20) by SJ5PPF28EF61683.namprd12.prod.outlook.com (2603:10b6:a0f:fc02::98e) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:45:56 +0000 Received: from BY1PEPF0001AE1A.namprd04.prod.outlook.com (2603:10b6:a03:2c0:cafe::8e) by SJ0PR13CA0015.outlook.office365.com (2603:10b6:a03:2c0::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.5 via Frontend Transport; Fri, 11 Sep 2026 07:45:56 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BY1PEPF0001AE1A.mail.protection.outlook.com (10.167.242.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.5 via Frontend Transport; Fri, 11 Sep 2026 07:45:56 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Fri, 11 Sep 2026 02:45:55 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Fri, 11 Sep 2026 02:45:54 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QZLq2Qkva7XrY8DRa+nSGZ3pq8ys+xXRY8KIfdhvL5MyiQ17CivT+cl5xamPv7dhHE46TrZdnV5R+6A83e9+NO/Sde8QcEnfCLhPuvcgduAKAdDqwi7nkiVNrvSMPWieEZn4eLesL22z86he1thkC20m6TdypOoZeo0dslD6mRO7bkJGijRMTjMR4vXeu74MsOe7TWbCZMIEz5gQqFcWddkfTSDc0mmnA46JzJy48VgPWyj06gs54sZPIJgl/U2iTJ6R+A4i9O2pzOE5r+fS4V7Wi3Bxn7sZr3to/QSs2ruBhYQ4kcXtNUs2f5BL0GVZgepEeF+P8wI74jmw8NgMjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XPpZeASj8xaVi2SPpnUHB0COXTDtAPNvOV/tuXEQzN4=; b=R23ENLFNqsjZXX0oqrAm1H1Ipwppfcs6XdcTBWTkqzt21z6wfVp4+n35y2Jkm/h/s8zfg60s9f+5Q/7Eg4NX1Y38WYuWxDQmKkSl1s2RZQmO8ZXGtIGDy/4rKqkOFe7CuO1M8VDi6tTibw6aOjfEsIp/5hscFdEg/9na9h0qIag6PB5rpyD9N0rRhxqCMdjHVTpMJFJJWsvdY+LtKp/AQdIGuwt1EAgmVojWdJjBQcHHosVzP7U/bWDr3J7TLf8Gz5LpslLNkveZsQABtt+CA0tOOKc1/T2Bnhjn3NDr5M27Xw+jDeYyy5X8OF8QAFom5gJ2h0z7AkPL9Z77EVK17Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XPpZeASj8xaVi2SPpnUHB0COXTDtAPNvOV/tuXEQzN4=; b=iT8+LZZX22NSTRneFndBzAxhMcfrVbdeVFUj9BuADmnXibaCHzyso00iu69FDdvcWDEpEh81ULuHOIFyqdxGsMsN/4eqGa8pRvW7lXJBRPKnx1Y5lZCjVnhIwaOTgF3JWHQn5cnbWEXNubg90EKWnCCV/5e9MJw76XdFUFqyk8M= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: Date: Fri, 11 Sep 2026 09:45:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Use __has_include() in xen/percpu.h To: Andrew Cooper , Xen-devel CC: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Oleksii Kurochko References: <20260909115342.3376342-1-andrew.cooper3@citrix.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260909115342.3376342-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PEPF0001AE1A:EE_|SJ5PPF28EF61683:EE_ X-MS-Office365-Filtering-Correlation-Id: a8962232-5110-4aa1-a61f-08df0fd8b6b8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|1800799024|82310400026|376014|7416014|10067099003|18002099003|22082099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: UNd49sBtAzb6dXgMsZdbYHLHoStc4vuLtRrYPy/uwOZVh2Vl/aW2LGPL3gJ8DyID8FpTiq8NRutOWhaQ95nmnr8q8ytf2D4nKKv8uuCyzm8qNFjt04JFEOFf7AqddsDNP/3Dt2VjzVpxuVznpeuvxD7+MPILNbz+5RIkdTak9JLkG8UEWfVYbVeYDNIN/TKCBRs7GxmUyqvKglZxVvOhBSRqwp1mLgJGnaZsZk/ECeAQuGCOgT26wL0otRM4vV+TZrDm8eskGP6n8FjWcoOSqAKzysedzYxTFAxV7aayCGuKmH5Vr6HZE2WVphYic6QYYE3EJTlhpmSbScu5geUiRd0UcBdEj5jrnEK4QEJGNIT+mlBLHv1mOS9hoIBHGC3lkM0Dy36Xkj/pAYEMigvUHVuxmyKgrW3TgzfAFrGsl2sFixczfY0mfND51QhndzGrrn9y1LEj91TVT9XMUd9kkHHi2EC0G4ncyJl98bXJvSlyC4qkuQV4hHWs0XGbMNku0a4hawT1Eb8kohiXKUJimjNkwhyF7tdBTJp87oyBJNISZ2aZwQ4sxT0SCFsMluWd5vPuWA4hQPXT6lGiHh4UBPuz0s8a0MG34meqa4ULg4WZQJYTIRi2oIrnvXW6O9np8HOicMzoFtDo7WaDZxd/UzMWF9QcAKaKUuUmL4tykM08jLTiI+uKkG3IrXNBFdjCg22aCwtD/pgXNO21rV2CoQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(1800799024)(82310400026)(376014)(7416014)(10067099003)(18002099003)(22082099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ubmE7bkPsMzLOcTPIT/HgL2/2p8mIO4k6Mmq6QonDM1CP/nJiy3tdiZOYRBklVrglnXOjm3bZcKRPC9bc+1R3RpGVlUKnIKPrLjWL26zvNABSmH79h29MHlDE9n3YiSYkCGsXWcFHBtwshqQFoNnPcKt+SMfjHJlnNlR5GtaFisqEjwlWetSo227sMlyO6/oLtAxEBfmKk+tlNevp7HRwr8+2O8cWzJL6su9U4Ftjr0h4InWHoJGuZ6sWn1KgOLlPKu0TN1TW7U7Day5jHksX3CCknJwGsotGD97NPXM+srZ3nMJe2IvukfoglFFLceEXsnZ7bsPitCAzvN5VXb3StSrAmqj6zlgJDkIJA3ptDhbjDxHHrZ7KoXfW4k9bGq4QAsQ9lfRA6V+eYgksBrCmnvfmGgV+3u9r/IOZnvYpli6k/y/rTSZhIP3rhwo5Not X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 07:45:56.1554 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a8962232-5110-4aa1-a61f-08df0fd8b6b8 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BY1PEPF0001AE1A.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPF28EF61683 X-purgate-ID: tlsNG-d62444/1789112761-1F66C757-13D0C235/0/0 X-purgate-type: clean X-purgate-size: 328 On 09-Sep-26 13:53, Andrew Cooper wrote: > Only x86 has an asm/percpu.h. Have the compiler only include it if it's > present, rather than symlinking an empty file. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:46:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:46:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415882.1645095 (Exim 4.92) (envelope-from ) id 1x4vyD-0003Og-Ve; Fri, 11 Sep 2026 07:46:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415882.1645095; Fri, 11 Sep 2026 07:46:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vyD-0003OZ-SU; Fri, 11 Sep 2026 07:46:49 +0000 Received: by outflank-mailman (input) for mailman id 1415882; Fri, 11 Sep 2026 07:46:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4vyB-0003OA-So for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:46:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4vyB-00D1iq-9N for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:46:47 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3b1e1-e002-0a2a0a5209dd-0a2a450b9a90-14 for ; Fri, 11 Sep 2026 09:46:47 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3b1e6-b7e8-0a2a450b0019-c387df83a3d6-3 for ; Fri, 11 Sep 2026 09:46:47 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7E6861FBF2; Fri, 11 Sep 2026 07:46:46 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EA5C3137DE; Fri, 11 Sep 2026 07:46:43 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id O0LmN+Oxo2pwWgAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 07:46:43 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: smtp-out2.suse.de; none From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-fbdev@vger.kernel.org Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Damien Le Moal , Niklas Cassel , David Airlie , Olivia Mackall , Herbert Xu , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Linus Walleij , Bartosz Golaszewski , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Arnd Bergmann , Greg Kroah-Hartman , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , Helge Deller , xen-devel@lists.xenproject.org, linux-geode@lists.infradead.org, Michael Kelley Subject: [PATCH v3 12/13] treewide: convert rdmsrq() from a macro to an inline function Date: Fri, 11 Sep 2026 09:45:29 +0200 Message-ID: <20260911074530.3140830-13-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260911074530.3140830-1-jgross@suse.com> References: <20260911074530.3140830-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 7E6861FBF2 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[] X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: -4.00 X-purgate-ID: tlsNG-42698a/1789112807-1AAD8A4A-4E36CA72/0/0 X-purgate-type: clean X-purgate-size: 167223 Today rdmsrq() is a macro using its second parameter as the target for storing the read MSR value. Convert rdmsrq() to an inline function returning the MSR value. The users have been converted using the following semantic patch: // Options: --include-headers virtual patch virtual report @@ expression msr, val; @@ ( - rdmsrq(msr,val) + val = rdmsrq(msr) ) Signed-off-by: Juergen Gross Acked-by: Damien Le Moal # ATA Reviewed-by: Michael Kelley # Hyper-V --- arch/x86/coco/sev/core.c | 2 +- arch/x86/events/amd/brs.c | 4 +-- arch/x86/events/amd/core.c | 4 +-- arch/x86/events/amd/ibs.c | 18 +++++----- arch/x86/events/amd/lbr.c | 8 ++--- arch/x86/events/amd/power.c | 8 ++--- arch/x86/events/amd/uncore.c | 4 +-- arch/x86/events/core.c | 20 +++++------ arch/x86/events/intel/core.c | 11 +++--- arch/x86/events/intel/cstate.c | 2 +- arch/x86/events/intel/ds.c | 2 +- arch/x86/events/intel/knc.c | 6 ++-- arch/x86/events/intel/lbr.c | 14 ++++---- arch/x86/events/intel/p4.c | 6 ++-- arch/x86/events/intel/p6.c | 4 +-- arch/x86/events/intel/pt.c | 12 +++---- arch/x86/events/intel/uncore.c | 2 +- arch/x86/events/intel/uncore_nhmex.c | 4 +-- arch/x86/events/intel/uncore_snb.c | 2 +- arch/x86/events/intel/uncore_snbep.c | 6 ++-- arch/x86/events/msr.c | 2 +- arch/x86/events/perf_event.h | 6 ++-- arch/x86/events/rapl.c | 4 +-- arch/x86/events/zhaoxin/core.c | 6 ++-- arch/x86/hyperv/hv_apic.c | 6 ++-- arch/x86/hyperv/hv_init.c | 26 +++++++------- arch/x86/hyperv/hv_spinlock.c | 2 +- arch/x86/include/asm/apic.h | 4 +-- arch/x86/include/asm/debugreg.h | 2 +- arch/x86/include/asm/fsgsbase.h | 2 +- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/include/asm/msr.h | 15 ++++---- arch/x86/include/asm/paravirt.h | 8 ++--- arch/x86/kernel/apic/apic.c | 14 ++++---- arch/x86/kernel/apic/apic_numachip.c | 6 ++-- arch/x86/kernel/cet.c | 2 +- arch/x86/kernel/cpu/amd.c | 14 ++++---- arch/x86/kernel/cpu/aperfmperf.c | 8 ++--- arch/x86/kernel/cpu/bugs.c | 12 +++---- arch/x86/kernel/cpu/bus_lock.c | 8 ++--- arch/x86/kernel/cpu/centaur.c | 8 ++--- arch/x86/kernel/cpu/common.c | 12 +++---- arch/x86/kernel/cpu/feat_ctl.c | 4 +-- arch/x86/kernel/cpu/hygon.c | 4 +-- arch/x86/kernel/cpu/intel.c | 6 ++-- arch/x86/kernel/cpu/intel_epb.c | 4 +-- arch/x86/kernel/cpu/mce/amd.c | 4 +-- arch/x86/kernel/cpu/mce/core.c | 8 ++--- arch/x86/kernel/cpu/mce/inject.c | 2 +- arch/x86/kernel/cpu/mce/intel.c | 18 +++++----- arch/x86/kernel/cpu/mce/p5.c | 8 ++--- arch/x86/kernel/cpu/mce/winchip.c | 2 +- arch/x86/kernel/cpu/microcode/intel.c | 2 +- arch/x86/kernel/cpu/mshyperv.c | 6 ++-- arch/x86/kernel/cpu/mtrr/amd.c | 4 +-- arch/x86/kernel/cpu/mtrr/cleanup.c | 4 +-- arch/x86/kernel/cpu/mtrr/generic.c | 32 ++++++++--------- arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +- arch/x86/kernel/cpu/resctrl/core.c | 2 +- arch/x86/kernel/cpu/resctrl/monitor.c | 4 +-- arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 +-- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +- arch/x86/kernel/cpu/topology.c | 2 +- arch/x86/kernel/cpu/topology_amd.c | 4 +-- arch/x86/kernel/cpu/transmeta.c | 2 +- arch/x86/kernel/cpu/tsx.c | 10 +++--- arch/x86/kernel/cpu/umwait.c | 2 +- arch/x86/kernel/cpu/zhaoxin.c | 4 +-- arch/x86/kernel/fpu/core.c | 2 +- arch/x86/kernel/hpet.c | 2 +- arch/x86/kernel/kvm.c | 2 +- arch/x86/kernel/mmconf-fam10h_64.c | 6 ++-- arch/x86/kernel/process.c | 4 +-- arch/x86/kernel/process_64.c | 14 ++++---- arch/x86/kernel/shstk.c | 8 ++--- arch/x86/kernel/traps.c | 4 +-- arch/x86/kernel/tsc.c | 2 +- arch/x86/kernel/tsc_msr.c | 6 ++-- arch/x86/kernel/tsc_sync.c | 6 ++-- arch/x86/kvm/msrs.c | 2 +- arch/x86/kvm/svm/pmu.c | 4 +-- arch/x86/kvm/svm/svm.c | 4 +-- arch/x86/kvm/vmx/nested.c | 4 +-- arch/x86/kvm/vmx/pmu_intel.c | 8 ++--- arch/x86/kvm/vmx/sgx.c | 6 ++-- arch/x86/kvm/vmx/vmx.c | 36 +++++++++---------- arch/x86/kvm/x86.c | 6 ++-- arch/x86/lib/insn-eval.c | 6 ++-- arch/x86/lib/msr-smp.c | 2 +- arch/x86/mm/pat/memtype.c | 2 +- arch/x86/pci/amd_bus.c | 8 ++--- arch/x86/platform/olpc/olpc-xo1-rtc.c | 6 ++-- arch/x86/platform/olpc/olpc-xo1-sci.c | 2 +- arch/x86/power/cpu.c | 10 +++--- arch/x86/realmode/init.c | 2 +- arch/x86/virt/hw.c | 8 ++--- arch/x86/virt/svm/sev.c | 18 +++++----- arch/x86/virt/vmx/tdx/tdx.c | 2 +- arch/x86/xen/suspend.c | 2 +- drivers/acpi/processor_perflib.c | 2 +- drivers/ata/pata_cs5535.c | 4 +-- drivers/ata/pata_cs5536.c | 2 +- drivers/char/agp/nvidia-agp.c | 6 ++-- drivers/char/hw_random/via-rng.c | 4 +-- drivers/cpufreq/acpi-cpufreq.c | 8 ++--- drivers/cpufreq/amd-pstate.c | 4 +-- drivers/cpufreq/e_powersaver.c | 20 +++++------ drivers/cpufreq/intel_pstate.c | 28 +++++++-------- drivers/cpufreq/longhaul.c | 12 +++---- drivers/cpufreq/longrun.c | 16 ++++----- drivers/cpufreq/powernow-k7.c | 10 +++--- drivers/cpufreq/powernow-k8.c | 8 ++--- drivers/cpufreq/speedstep-centrino.c | 4 +-- drivers/cpufreq/speedstep-lib.c | 14 ++++---- drivers/edac/amd64_edac.c | 6 ++-- drivers/gpio/gpio-cs5535.c | 2 +- drivers/hv/mshv_vtl_main.c | 2 +- drivers/hwmon/hwmon-vid.c | 4 +-- drivers/idle/intel_idle.c | 26 +++++++------- drivers/misc/cs5535-mfgpt.c | 6 ++-- drivers/mtd/nand/raw/cs553x_nand.c | 6 ++-- drivers/platform/x86/intel/ifs/load.c | 10 +++--- drivers/platform/x86/intel/ifs/runtest.c | 8 ++--- drivers/platform/x86/intel/pmc/cnp.c | 2 +- .../intel/speed_select_if/isst_if_mbox_msr.c | 6 ++-- .../intel/speed_select_if/isst_tpmi_core.c | 2 +- drivers/platform/x86/intel_ips.c | 20 +++++------ drivers/powercap/intel_rapl_msr.c | 2 +- drivers/thermal/intel/intel_hfi.c | 8 ++--- drivers/thermal/intel/therm_throt.c | 22 ++++++------ drivers/thermal/intel/x86_pkg_temp_thermal.c | 6 ++-- drivers/video/fbdev/geode/display_gx.c | 2 +- drivers/video/fbdev/geode/gxfb_core.c | 2 +- drivers/video/fbdev/geode/lxfb_ops.c | 18 +++++----- drivers/video/fbdev/geode/suspend_gx.c | 8 ++--- drivers/video/fbdev/geode/video_gx.c | 8 ++--- include/linux/cs5535.h | 2 +- 137 files changed, 483 insertions(+), 485 deletions(-) diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index cc292d7c6fd1..2a1875642cd4 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -2026,7 +2026,7 @@ void __init snp_secure_tsc_init(void) secrets = (__force struct snp_secrets_page *)mem; setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); - rdmsrq(MSR_AMD64_GUEST_TSC_FREQ, tsc_freq_mhz); + tsc_freq_mhz = rdmsrq(MSR_AMD64_GUEST_TSC_FREQ); /* Extract the GUEST TSC MHZ from BIT[17:0], rest is reserved space */ tsc_freq_mhz &= GENMASK_ULL(17, 0); diff --git a/arch/x86/events/amd/brs.c b/arch/x86/events/amd/brs.c index dc564688f3d7..4df3a2a736e0 100644 --- a/arch/x86/events/amd/brs.c +++ b/arch/x86/events/amd/brs.c @@ -325,7 +325,7 @@ void amd_brs_drain(void) u32 brs_idx = tos - i; u64 from, to; - rdmsrq(brs_to(brs_idx), to); + to = rdmsrq(brs_to(brs_idx)); /* Entry does not belong to us (as marked by kernel) */ if (to == BRS_POISON) @@ -338,7 +338,7 @@ void amd_brs_drain(void) */ to = (u64)(((s64)to << shift) >> shift); - rdmsrq(brs_from(brs_idx), from); + from = rdmsrq(brs_from(brs_idx)); if (!amd_brs_match_plm(event, from, to)) continue; diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c index 49b6b8fce566..80ed49dba255 100644 --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -663,7 +663,7 @@ static inline u64 amd_pmu_get_global_status(void) u64 status; /* PerfCntrGlobalStatus is read-only */ - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, status); + status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); return status; } @@ -683,7 +683,7 @@ static bool amd_pmu_test_overflow_topbit(int idx) { u64 counter; - rdmsrq(x86_pmu_event_addr(idx), counter); + counter = rdmsrq(x86_pmu_event_addr(idx)); return !(counter & BIT_ULL(x86_pmu.cntval_bits - 1)); } diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c index 3531f9c23b8c..17eab32164df 100644 --- a/arch/x86/events/amd/ibs.c +++ b/arch/x86/events/amd/ibs.c @@ -505,7 +505,7 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs, struct perf_event *event, * prev count manually on overflow. */ while (!perf_event_try_update(event, count, 64)) { - rdmsrq(event->hw.config_base, *config); + *config = rdmsrq(event->hw.config_base); count = perf_ibs->get_count(*config); } } @@ -610,7 +610,7 @@ static void perf_ibs_stop(struct perf_event *event, int flags) if (!stopping && (hwc->state & PERF_HES_UPTODATE)) return; - rdmsrq(hwc->config_base, config); + config = rdmsrq(hwc->config_base); if (stopping) { /* @@ -1437,7 +1437,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs) hwc = &event->hw; msr = hwc->config_base; buf = ibs_data.regs; - rdmsrq(msr, *buf); + *buf = rdmsrq(msr); if (!(*buf++ & perf_ibs->valid_mask)) goto fail; @@ -1455,7 +1455,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs) offset_max = perf_ibs_get_offset_max(perf_ibs, event, check_rip); do { - rdmsrq(msr + offset, *buf++); + *buf++ = rdmsrq(msr + offset); size++; offset = find_next_bit(perf_ibs->offset_mask, perf_ibs->offset_max, @@ -1497,17 +1497,17 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs) if (event->attr.sample_type & PERF_SAMPLE_RAW) { if (perf_ibs == &perf_ibs_op) { if (ibs_caps & IBS_CAPS_BRNTRGT) { - rdmsrq(MSR_AMD64_IBSBRTARGET, *buf++); + *buf++ = rdmsrq(MSR_AMD64_IBSBRTARGET); br_target_idx = size; size++; } if (ibs_caps & IBS_CAPS_OPDATA4) { - rdmsrq(MSR_AMD64_IBSOPDATA4, *buf++); + *buf++ = rdmsrq(MSR_AMD64_IBSOPDATA4); size++; } } if (perf_ibs == &perf_ibs_fetch && (ibs_caps & IBS_CAPS_FETCHCTLEXTD)) { - rdmsrq(MSR_AMD64_ICIBSEXTDCTL, *buf++); + *buf++ = rdmsrq(MSR_AMD64_ICIBSEXTDCTL); size++; } } @@ -1768,7 +1768,7 @@ static inline int ibs_eilvt_valid(void) preempt_disable(); - rdmsrq(MSR_AMD64_IBSCTL, val); + val = rdmsrq(MSR_AMD64_IBSCTL); offset = val & IBSCTL_LVT_OFFSET_MASK; if (!(val & IBSCTL_LVT_OFFSET_VALID)) { @@ -1883,7 +1883,7 @@ static inline int get_ibs_lvt_offset(void) { u64 val; - rdmsrq(MSR_AMD64_IBSCTL, val); + val = rdmsrq(MSR_AMD64_IBSCTL); if (!(val & IBSCTL_LVT_OFFSET_VALID)) return -EINVAL; diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c index 9d9c961989d5..29628af6a023 100644 --- a/arch/x86/events/amd/lbr.c +++ b/arch/x86/events/amd/lbr.c @@ -76,7 +76,7 @@ static __always_inline u64 amd_pmu_lbr_get_from(unsigned int idx) { u64 val; - rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2, val); + val = rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2); return val; } @@ -85,7 +85,7 @@ static __always_inline u64 amd_pmu_lbr_get_to(unsigned int idx) { u64 val; - rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2 + 1, val); + val = rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2 + 1); return val; } @@ -404,11 +404,11 @@ void amd_pmu_lbr_enable_all(void) } if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) { - rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl); + dbg_ctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI); } - rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg); + dbg_extn_cfg = rdmsrq(MSR_AMD_DBG_EXTN_CFG); wrmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg | DBG_EXTN_CFG_LBRV2EN); } diff --git a/arch/x86/events/amd/power.c b/arch/x86/events/amd/power.c index 66197214b010..5a5ebce0a526 100644 --- a/arch/x86/events/amd/power.c +++ b/arch/x86/events/amd/power.c @@ -52,8 +52,8 @@ static void event_update(struct perf_event *event) prev_pwr_acc = hwc->pwr_acc; prev_ptsc = hwc->ptsc; - rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR, new_pwr_acc); - rdmsrq(MSR_F15H_PTSC, new_ptsc); + new_pwr_acc = rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR); + new_ptsc = rdmsrq(MSR_F15H_PTSC); /* * Calculate the CU power consumption over a time period, the unit of @@ -79,8 +79,8 @@ static void __pmu_event_start(struct perf_event *event) event->hw.state = 0; - rdmsrq(MSR_F15H_PTSC, event->hw.ptsc); - rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR, event->hw.pwr_acc); + event->hw.ptsc = rdmsrq(MSR_F15H_PTSC); + event->hw.pwr_acc = rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR); } static void pmu_event_start(struct perf_event *event, int mode) diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c index 7181973b5b12..35f0c4831919 100644 --- a/arch/x86/events/amd/uncore.c +++ b/arch/x86/events/amd/uncore.c @@ -151,7 +151,7 @@ static void amd_uncore_read(struct perf_event *event) * read counts directly from the corresponding PERF_CTR. */ if (hwc->event_base_rdpmc < 0) - rdmsrq(hwc->event_base, new); + new = rdmsrq(hwc->event_base); else new = rdpmc(hwc->event_base_rdpmc); @@ -998,7 +998,7 @@ static void amd_uncore_umc_read(struct perf_event *event) * UMC counters do not have RDPMC assignments. Read counts directly * from the corresponding PERF_CTR. */ - rdmsrq(hwc->event_base, new); + new = rdmsrq(hwc->event_base); /* * Unlike the other uncore counters, UMC counters saturate and set the diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 8b3ea0adb965..34bd80bb2c9e 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -711,7 +711,7 @@ void x86_pmu_disable_all(void) if (!test_bit(idx, cpuc->active_mask)) continue; - rdmsrq(x86_pmu_config_addr(idx), val); + val = rdmsrq(x86_pmu_config_addr(idx)); if (!(val & ARCH_PERFMON_EVENTSEL_ENABLE)) continue; val &= ~ARCH_PERFMON_EVENTSEL_ENABLE; @@ -1592,10 +1592,10 @@ void perf_event_print_debug(void) return; if (x86_pmu.version >= 2) { - rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL, ctrl); - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); - rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, overflow); - rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL, fixed); + ctrl = rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL); + status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); + overflow = rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL); + fixed = rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL); pr_info("\n"); pr_info("CPU#%d: ctrl: %016llx\n", cpu, ctrl); @@ -1603,19 +1603,19 @@ void perf_event_print_debug(void) pr_info("CPU#%d: overflow: %016llx\n", cpu, overflow); pr_info("CPU#%d: fixed: %016llx\n", cpu, fixed); if (pebs_constraints) { - rdmsrq(MSR_IA32_PEBS_ENABLE, pebs); + pebs = rdmsrq(MSR_IA32_PEBS_ENABLE); pr_info("CPU#%d: pebs: %016llx\n", cpu, pebs); } if (x86_pmu.lbr_nr) { - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); pr_info("CPU#%d: debugctl: %016llx\n", cpu, debugctl); } } pr_info("CPU#%d: active: %016llx\n", cpu, *(u64 *)cpuc->active_mask); for_each_set_bit(idx, cntr_mask, X86_PMC_IDX_MAX) { - rdmsrq(x86_pmu_config_addr(idx), pmc_ctrl); - rdmsrq(x86_pmu_event_addr(idx), pmc_count); + pmc_ctrl = rdmsrq(x86_pmu_config_addr(idx)); + pmc_count = rdmsrq(x86_pmu_event_addr(idx)); prev_left = per_cpu(pmc_prev_left[idx], cpu); @@ -1627,7 +1627,7 @@ void perf_event_print_debug(void) cpu, idx, prev_left); } for_each_set_bit(idx, fixed_cntr_mask, X86_PMC_IDX_MAX) { - rdmsrq(x86_pmu_fixed_ctr_addr(idx), pmc_count); + pmc_count = rdmsrq(x86_pmu_fixed_ctr_addr(idx)); pr_info("CPU#%d: fixed-PMC%d count: %016llx\n", cpu, idx, pmc_count); diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index cc13164d948f..41ae90b6bbdc 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -2965,7 +2965,7 @@ static inline u64 intel_pmu_get_status(void) { u64 status; - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); + status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); return status; } @@ -3494,7 +3494,7 @@ static void intel_pmu_enable_event_ext(struct perf_event *event) else new.thresh = ARCH_PEBS_THRESH_SINGLE; - rdmsrq(MSR_IA32_PEBS_INDEX, old.whole); + old.whole = rdmsrq(MSR_IA32_PEBS_INDEX); if (new.thresh != old.thresh || !old.en) { if (old.thresh == ARCH_PEBS_THRESH_MULTI && old.wr > 0) { /* @@ -6255,8 +6255,7 @@ static void intel_update_pmu_caps(struct pmu *pmu) update_pmu_cap_from_perfmonext(pmu); if (is_hybrid() && this_cpu_has(X86_FEATURE_PDCM)) { - rdmsrq(MSR_IA32_PERF_CAPABILITIES, - hybrid(pmu, intel_cap).capabilities); + hybrid(pmu, intel_cap).capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES); /* * Restore perf_metrics on platforms with broken @@ -6412,7 +6411,7 @@ static void intel_pmu_cpu_starting(int cpu) if (!is_hybrid() && x86_pmu.intel_cap.perf_metrics) { union perf_capabilities perf_cap; - rdmsrq(MSR_IA32_PERF_CAPABILITIES, perf_cap.capabilities); + perf_cap.capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES); if (!perf_cap.perf_metrics) { x86_pmu.intel_cap.perf_metrics = 0; x86_pmu.intel_ctrl &= ~GLOBAL_CTRL_EN_PERF_METRICS; @@ -7959,7 +7958,7 @@ __init int intel_pmu_init(void) if (boot_cpu_has(X86_FEATURE_PDCM)) { u64 capabilities; - rdmsrq(MSR_IA32_PERF_CAPABILITIES, capabilities); + capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES); x86_pmu.intel_cap.capabilities = capabilities; } diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c index f3d5ee07f8f2..69eb6cf51d3b 100644 --- a/arch/x86/events/intel/cstate.c +++ b/arch/x86/events/intel/cstate.c @@ -324,7 +324,7 @@ static inline u64 cstate_pmu_read_counter(struct perf_event *event) { u64 val; - rdmsrq(event->hw.event_base, val); + val = rdmsrq(event->hw.event_base); return val; } diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 8940f0292229..ffe4f84c411d 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -3231,7 +3231,7 @@ static void intel_pmu_drain_arch_pebs(struct pt_regs *iregs, void *base, *at, *top; u64 mask; - rdmsrq(MSR_IA32_PEBS_INDEX, index.whole); + index.whole = rdmsrq(MSR_IA32_PEBS_INDEX); if (unlikely(!index.wr)) { intel_pmu_pebs_event_update_no_drain(cpuc, X86_PMC_IDX_MAX); diff --git a/arch/x86/events/intel/knc.c b/arch/x86/events/intel/knc.c index e887adc108ac..c4f81215f758 100644 --- a/arch/x86/events/intel/knc.c +++ b/arch/x86/events/intel/knc.c @@ -160,7 +160,7 @@ static void knc_pmu_disable_all(void) { u64 val; - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); + val = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL); val &= ~(KNC_ENABLE_COUNTER0|KNC_ENABLE_COUNTER1); wrmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); } @@ -169,7 +169,7 @@ static void knc_pmu_enable_all(int added) { u64 val; - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); + val = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL); val |= (KNC_ENABLE_COUNTER0|KNC_ENABLE_COUNTER1); wrmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); } @@ -201,7 +201,7 @@ static inline u64 knc_pmu_get_status(void) { u64 status; - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_STATUS, status); + status = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_STATUS); return status; } diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c index cbe5c762008d..fc05ec3b9a99 100644 --- a/arch/x86/events/intel/lbr.c +++ b/arch/x86/events/intel/lbr.c @@ -141,7 +141,7 @@ static void __intel_pmu_lbr_enable(bool pmi) if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR) && !pmi && cpuc->lbr_sel) wrmsrq(MSR_LBR_SELECT, lbr_select); - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); orig_debugctl = debugctl; if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR)) @@ -211,7 +211,7 @@ static inline u64 intel_pmu_lbr_tos(void) { u64 tos; - rdmsrq(x86_pmu.lbr_tos, tos); + tos = rdmsrq(x86_pmu.lbr_tos); return tos; } @@ -304,7 +304,7 @@ static __always_inline u64 rdlbr_from(unsigned int idx, struct lbr_entry *lbr) if (lbr) return lbr->from; - rdmsrq(x86_pmu.lbr_from + idx, val); + val = rdmsrq(x86_pmu.lbr_from + idx); return lbr_from_signext_quirk_rd(val); } @@ -316,7 +316,7 @@ static __always_inline u64 rdlbr_to(unsigned int idx, struct lbr_entry *lbr) if (lbr) return lbr->to; - rdmsrq(x86_pmu.lbr_to + idx, val); + val = rdmsrq(x86_pmu.lbr_to + idx); return val; } @@ -328,7 +328,7 @@ static __always_inline u64 rdlbr_info(unsigned int idx, struct lbr_entry *lbr) if (lbr) return lbr->info; - rdmsrq(x86_pmu.lbr_info + idx, val); + val = rdmsrq(x86_pmu.lbr_info + idx); return val; } @@ -477,7 +477,7 @@ void intel_pmu_lbr_save(void *ctx) task_ctx->tos = tos; if (cpuc->lbr_select) - rdmsrq(MSR_LBR_SELECT, task_ctx->lbr_sel); + task_ctx->lbr_sel = rdmsrq(MSR_LBR_SELECT); } static void intel_pmu_arch_lbr_save(void *ctx) @@ -754,7 +754,7 @@ void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc) u64 lbr; } msr_lastbranch; - rdmsrq(x86_pmu.lbr_from + lbr_idx, msr_lastbranch.lbr); + msr_lastbranch.lbr = rdmsrq(x86_pmu.lbr_from + lbr_idx); perf_clear_branch_entry_bitfields(br); diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c index 5368dc31787c..e675e85682f1 100644 --- a/arch/x86/events/intel/p4.c +++ b/arch/x86/events/intel/p4.c @@ -860,7 +860,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_perf_event *hwc) u64 v; /* an official way for overflow indication */ - rdmsrq(hwc->config_base, v); + v = rdmsrq(hwc->config_base); if (v & P4_CCCR_OVF) { wrmsrq(hwc->config_base, v & ~P4_CCCR_OVF); return 1; @@ -873,7 +873,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_perf_event *hwc) * the counter has reached zero value and continued counting before * real NMI signal was received: */ - rdmsrq(hwc->event_base, v); + v = rdmsrq(hwc->event_base); if (!(v & ARCH_P4_UNFLAGGED_BIT)) return 1; @@ -1373,7 +1373,7 @@ __init int p4_pmu_init(void) /* If we get stripped -- indexing fails */ BUILD_BUG_ON(ARCH_P4_MAX_CCCR > INTEL_PMC_MAX_GENERIC); - rdmsrq(MSR_IA32_MISC_ENABLE, misc); + misc = rdmsrq(MSR_IA32_MISC_ENABLE); if (!(misc & MSR_IA32_MISC_ENABLE_EMON)) { pr_cont("unsupported Netburst CPU model %d ", boot_cpu_data.x86_model); diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c index fb991e0ac614..4268b576b5d8 100644 --- a/arch/x86/events/intel/p6.c +++ b/arch/x86/events/intel/p6.c @@ -143,7 +143,7 @@ static void p6_pmu_disable_all(void) u64 val; /* p6 only has one enable register */ - rdmsrq(MSR_P6_EVNTSEL0, val); + val = rdmsrq(MSR_P6_EVNTSEL0); val &= ~ARCH_PERFMON_EVENTSEL_ENABLE; wrmsrq(MSR_P6_EVNTSEL0, val); } @@ -153,7 +153,7 @@ static void p6_pmu_enable_all(int added) unsigned long val; /* p6 only has one enable register */ - rdmsrq(MSR_P6_EVNTSEL0, val); + val = rdmsrq(MSR_P6_EVNTSEL0); val |= ARCH_PERFMON_EVENTSEL_ENABLE; wrmsrq(MSR_P6_EVNTSEL0, val); } diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c index 5754cd405562..d595d69b49a1 100644 --- a/arch/x86/events/intel/pt.c +++ b/arch/x86/events/intel/pt.c @@ -196,7 +196,7 @@ static int __init pt_pmu_hw_init(void) int ret; long i; - rdmsrq(MSR_PLATFORM_INFO, reg); + reg = rdmsrq(MSR_PLATFORM_INFO); pt_pmu.max_nonturbo_ratio = (reg & 0xff00) >> 8; /* @@ -232,7 +232,7 @@ static int __init pt_pmu_hw_init(void) * "IA32_VMX_MISC[bit 14]" being 1 means PT can trace * post-VMXON. */ - rdmsrq(MSR_IA32_VMX_MISC, reg); + reg = rdmsrq(MSR_IA32_VMX_MISC); if (reg & BIT(14)) pt_pmu.vmx = true; } @@ -935,7 +935,7 @@ static void pt_handle_status(struct pt *pt) int advance = 0; u64 status; - rdmsrq(MSR_IA32_RTIT_STATUS, status); + status = rdmsrq(MSR_IA32_RTIT_STATUS); if (status & RTIT_STATUS_ERROR) { pr_err_ratelimited("ToPA ERROR encountered, trying to recover\n"); @@ -994,12 +994,12 @@ static void pt_read_offset(struct pt_buffer *buf) struct topa_page *tp; if (!buf->single) { - rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE, pt->output_base); + pt->output_base = rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE); tp = phys_to_virt(pt->output_base); buf->cur = &tp->topa; } - rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK, pt->output_mask); + pt->output_mask = rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK); /* offset within current output region */ buf->output_off = pt->output_mask >> 32; /* index of current output region within this table */ @@ -1623,7 +1623,7 @@ static void pt_event_start(struct perf_event *event, int mode) * PMI might have just cleared these, so resume_allowed * must be checked again also. */ - rdmsrq(MSR_IA32_RTIT_STATUS, status); + status = rdmsrq(MSR_IA32_RTIT_STATUS); if (!(status & (RTIT_STATUS_TRIGGEREN | RTIT_STATUS_ERROR | RTIT_STATUS_STOPPED)) && diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c index b2109b37ea7f..ab2c5a962b31 100644 --- a/arch/x86/events/intel/uncore.c +++ b/arch/x86/events/intel/uncore.c @@ -171,7 +171,7 @@ u64 uncore_msr_read_counter(struct intel_uncore_box *box, struct perf_event *eve { u64 count; - rdmsrq(event->hw.event_base, count); + count = rdmsrq(event->hw.event_base); return count; } diff --git a/arch/x86/events/intel/uncore_nhmex.c b/arch/x86/events/intel/uncore_nhmex.c index 7a6855281102..81e838e6f729 100644 --- a/arch/x86/events/intel/uncore_nhmex.c +++ b/arch/x86/events/intel/uncore_nhmex.c @@ -216,7 +216,7 @@ static void nhmex_uncore_msr_disable_box(struct intel_uncore_box *box) u64 config; if (msr) { - rdmsrq(msr, config); + config = rdmsrq(msr); config &= ~((1ULL << uncore_num_counters(box)) - 1); /* WBox has a fixed counter */ if (uncore_msr_fixed_ctl(box)) @@ -231,7 +231,7 @@ static void nhmex_uncore_msr_enable_box(struct intel_uncore_box *box) u64 config; if (msr) { - rdmsrq(msr, config); + config = rdmsrq(msr); config |= (1ULL << uncore_num_counters(box)) - 1; /* WBox has a fixed counter */ if (uncore_msr_fixed_ctl(box)) diff --git a/arch/x86/events/intel/uncore_snb.c b/arch/x86/events/intel/uncore_snb.c index 055131c508ff..da864724ff20 100644 --- a/arch/x86/events/intel/uncore_snb.c +++ b/arch/x86/events/intel/uncore_snb.c @@ -533,7 +533,7 @@ static int icl_get_cbox_num(void) { u64 num_boxes; - rdmsrq(ICL_UNC_CBO_CONFIG, num_boxes); + num_boxes = rdmsrq(ICL_UNC_CBO_CONFIG); return num_boxes & ICL_UNC_NUM_CBO_MASK; } diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index a97cd029db36..490725c8fee1 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -642,7 +642,7 @@ static void snbep_uncore_msr_disable_box(struct intel_uncore_box *box) msr = uncore_msr_box_ctl(box); if (msr) { - rdmsrq(msr, config); + config = rdmsrq(msr); config |= SNBEP_PMON_BOX_CTL_FRZ; wrmsrq(msr, config); } @@ -655,7 +655,7 @@ static void snbep_uncore_msr_enable_box(struct intel_uncore_box *box) msr = uncore_msr_box_ctl(box); if (msr) { - rdmsrq(msr, config); + config = rdmsrq(msr); config &= ~SNBEP_PMON_BOX_CTL_FRZ; wrmsrq(msr, config); } @@ -6370,7 +6370,7 @@ void spr_uncore_cpu_init(void) * of UNCORE_SPR_CHA) is incorrect on some SPR variants because of a * firmware bug. Using the value from SPR_MSR_UNC_CBO_CONFIG to replace it. */ - rdmsrq(SPR_MSR_UNC_CBO_CONFIG, num_cbo); + num_cbo = rdmsrq(SPR_MSR_UNC_CBO_CONFIG); /* * The MSR doesn't work on the EMR XCC, but the firmware bug doesn't impact * the EMR XCC. Don't let the value from the MSR replace the existing value. diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c index 76d6418c5055..0e59781549ca 100644 --- a/arch/x86/events/msr.c +++ b/arch/x86/events/msr.c @@ -158,7 +158,7 @@ static inline u64 msr_read_counter(struct perf_event *event) u64 now; if (event->hw.event_base) - rdmsrq(event->hw.event_base, now); + now = rdmsrq(event->hw.event_base); else now = rdtsc_ordered(); diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h index 71ed5b2acea2..4abdb9475e8f 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -1475,11 +1475,11 @@ static __always_inline void __amd_pmu_lbr_disable(void) { u64 dbg_ctl, dbg_extn_cfg; - rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg); + dbg_extn_cfg = rdmsrq(MSR_AMD_DBG_EXTN_CFG); wrmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg & ~DBG_EXTN_CFG_LBRV2EN); if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) { - rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl); + dbg_ctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl & ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI); } } @@ -1633,7 +1633,7 @@ static __always_inline void __intel_pmu_lbr_disable(void) { u64 debugctl; - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); debugctl &= ~(DEBUGCTLMSR_LBR | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI); wrmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); } diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c index 8ed03c32f560..180cc18282ca 100644 --- a/arch/x86/events/rapl.c +++ b/arch/x86/events/rapl.c @@ -193,7 +193,7 @@ static inline unsigned int get_rapl_pmu_idx(int cpu, int scope) static inline u64 rapl_read_counter(struct perf_event *event) { u64 raw; - rdmsrq(event->hw.event_base, raw); + raw = rdmsrq(event->hw.event_base); return raw; } @@ -222,7 +222,7 @@ static u64 rapl_event_update(struct perf_event *event) prev_raw_count = local64_read(&hwc->prev_count); do { - rdmsrq(event->hw.event_base, new_raw_count); + new_raw_count = rdmsrq(event->hw.event_base); } while (!local64_try_cmpxchg(&hwc->prev_count, &prev_raw_count, new_raw_count)); diff --git a/arch/x86/events/zhaoxin/core.c b/arch/x86/events/zhaoxin/core.c index e506f677db57..1980e5995e27 100644 --- a/arch/x86/events/zhaoxin/core.c +++ b/arch/x86/events/zhaoxin/core.c @@ -268,7 +268,7 @@ static inline u64 zhaoxin_pmu_get_status(void) { u64 status; - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); + status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); return status; } @@ -295,7 +295,7 @@ static void zhaoxin_pmu_disable_fixed(struct hw_perf_event *hwc) mask = 0xfULL << (idx * 4); - rdmsrq(hwc->config_base, ctrl_val); + ctrl_val = rdmsrq(hwc->config_base); ctrl_val &= ~mask; wrmsrq(hwc->config_base, ctrl_val); } @@ -331,7 +331,7 @@ static void zhaoxin_pmu_enable_fixed(struct hw_perf_event *hwc) bits <<= (idx * 4); mask = 0xfULL << (idx * 4); - rdmsrq(hwc->config_base, ctrl_val); + ctrl_val = rdmsrq(hwc->config_base); ctrl_val &= ~mask; ctrl_val |= bits; wrmsrq(hwc->config_base, ctrl_val); diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c index 95f1782d1e17..4e30f9a11bc4 100644 --- a/arch/x86/hyperv/hv_apic.c +++ b/arch/x86/hyperv/hv_apic.c @@ -38,7 +38,7 @@ static u64 hv_apic_icr_read(void) { u64 reg_val; - rdmsrq(HV_X64_MSR_ICR, reg_val); + reg_val = rdmsrq(HV_X64_MSR_ICR); return reg_val; } @@ -64,10 +64,10 @@ static u32 hv_apic_read(u32 reg) switch (reg) { case APIC_EOI: - rdmsrq(HV_X64_MSR_EOI, reg_val.q); + reg_val.q = rdmsrq(HV_X64_MSR_EOI); return reg_val.l; case APIC_TASKPRI: - rdmsrq(HV_X64_MSR_TPR, reg_val.q); + reg_val.q = rdmsrq(HV_X64_MSR_TPR); return reg_val.l; default: diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 0b4a1c0b0b16..672a9656446e 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -101,7 +101,7 @@ static int hyperv_init_ghcb(void) * returned by MSR_AMD64_SEV_ES_GHCB is above shared * memory boundary and map it here. */ - rdmsrq(MSR_AMD64_SEV_ES_GHCB, ghcb_gpa); + ghcb_gpa = rdmsrq(MSR_AMD64_SEV_ES_GHCB); /* Mask out vTOM bit and map as decrypted */ ghcb_gpa &= ~ms_hyperv.shared_gpa_boundary; @@ -134,7 +134,7 @@ static int hv_cpu_init(unsigned int cpu) * For root partition we get the hypervisor provided VP assist * page, instead of allocating a new page. */ - rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); + msr.as_uint64 = rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE); *hvp = memremap(msr.pfn << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT, PAGE_SIZE, MEMREMAP_WB); } else { @@ -182,7 +182,7 @@ static void hv_reenlightenment_notify(struct work_struct *dummy) { struct hv_tsc_emulation_status emu_status; - rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); + *(u64 *)&emu_status = rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS); /* Don't issue the callback if TSC accesses are not emulated */ if (hv_reenlightenment_cb && emu_status.inprogress) @@ -195,11 +195,11 @@ void hyperv_stop_tsc_emulation(void) u64 freq; struct hv_tsc_emulation_status emu_status; - rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); + *(u64 *)&emu_status = rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS); emu_status.inprogress = 0; wrmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); - rdmsrq(HV_X64_MSR_TSC_FREQUENCY, freq); + freq = rdmsrq(HV_X64_MSR_TSC_FREQUENCY); tsc_khz = div64_u64(freq, 1000); } EXPORT_SYMBOL_GPL(hyperv_stop_tsc_emulation); @@ -259,7 +259,7 @@ void clear_hv_tscchange_cb(void) if (!hv_reenlightenment_available()) return; - rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *(u64 *)&re_ctrl); + *(u64 *)&re_ctrl = rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL); re_ctrl.enabled = 0; wrmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *(u64 *)&re_ctrl); @@ -295,7 +295,7 @@ static int hv_cpu_die(unsigned int cpu) */ memunmap(hv_vp_assist_page[cpu]); hv_vp_assist_page[cpu] = NULL; - rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); + msr.as_uint64 = rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE); msr.enable = 0; } wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); @@ -304,7 +304,7 @@ static int hv_cpu_die(unsigned int cpu) if (hv_reenlightenment_cb == NULL) return 0; - rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl)); + *((u64 *)&re_ctrl) = rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL); if (re_ctrl.target_vp == hv_vp_index[cpu]) { /* * Reassign reenlightenment notifications to some other online @@ -375,7 +375,7 @@ static int hv_suspend(void *data) hv_set_hypercall_pg(NULL); /* Disable the hypercall page in the hypervisor */ - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); + hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL); hypercall_msr.enable = 0; wrmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); @@ -392,7 +392,7 @@ static void hv_resume(void *data) WARN_ON(ret); /* Re-enable the hypercall page */ - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); + hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL); hypercall_msr.enable = 1; hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg_saved); @@ -530,7 +530,7 @@ void __init hyperv_init(void) if (hv_hypercall_pg == NULL) goto clean_guest_os_id; - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); + hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL); hypercall_msr.enable = 1; if (hv_root_partition()) { @@ -672,7 +672,7 @@ void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die) return; panic_reported = true; - rdmsrq(HV_X64_MSR_GUEST_OS_ID, guest_id); + guest_id = rdmsrq(HV_X64_MSR_GUEST_OS_ID); wrmsrq(HV_X64_MSR_CRASH_P0, err); wrmsrq(HV_X64_MSR_CRASH_P1, guest_id); @@ -706,7 +706,7 @@ bool hv_is_hyperv_initialized(void) * that the hypercall page is setup */ hypercall_msr.as_uint64 = 0; - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); + hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL); return hypercall_msr.enable; } diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c index 6b4bdea18218..7ef2d794e2e8 100644 --- a/arch/x86/hyperv/hv_spinlock.c +++ b/arch/x86/hyperv/hv_spinlock.c @@ -50,7 +50,7 @@ static void hv_qlock_wait(u8 *byte, u8 val) if (READ_ONCE(*byte) == val) { unsigned long msr_val; - rdmsrq(HV_X64_MSR_GUEST_IDLE, msr_val); + msr_val = rdmsrq(HV_X64_MSR_GUEST_IDLE); (void)msr_val; } diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h index 9cd493d467d4..e028140fac49 100644 --- a/arch/x86/include/asm/apic.h +++ b/arch/x86/include/asm/apic.h @@ -220,7 +220,7 @@ static inline u32 native_apic_msr_read(u32 reg) if (reg == APIC_DFR) return -1; - rdmsrq(APIC_BASE_MSR + (reg >> 4), msr); + msr = rdmsrq(APIC_BASE_MSR + (reg >> 4)); return (u32)msr; } @@ -233,7 +233,7 @@ static inline u64 native_x2apic_icr_read(void) { unsigned long val; - rdmsrq(APIC_BASE_MSR + (APIC_ICR >> 4), val); + val = rdmsrq(APIC_BASE_MSR + (APIC_ICR >> 4)); return val; } diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debugreg.h index 854d82b88ff4..60a3df32a4d3 100644 --- a/arch/x86/include/asm/debugreg.h +++ b/arch/x86/include/asm/debugreg.h @@ -180,7 +180,7 @@ static inline unsigned long get_debugctlmsr(void) if (boot_cpu_data.x86 < 6) return 0; #endif - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctlmsr); + debugctlmsr = rdmsrq(MSR_IA32_DEBUGCTLMSR); return debugctlmsr; } diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h index 70ff4ef457b1..9de49d732e9e 100644 --- a/arch/x86/include/asm/fsgsbase.h +++ b/arch/x86/include/asm/fsgsbase.h @@ -60,7 +60,7 @@ static inline unsigned long x86_fsbase_read_cpu(void) if (boot_cpu_has(X86_FEATURE_FSGSBASE)) fsbase = rdfsbase(); else - rdmsrq(MSR_FS_BASE, fsbase); + fsbase = rdmsrq(MSR_FS_BASE); return fsbase; } diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 683bb8bf43a9..b7887dccb829 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1862,7 +1862,7 @@ static inline unsigned long read_msr(unsigned long msr) { u64 value; - rdmsrq(msr, value); + value = rdmsrq(msr); return value; } #endif diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index 6d7bab33af71..95761803c2e6 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -173,14 +173,13 @@ static inline u64 native_read_pmc(int counter) #include #else #include -/* - * Access to machine-specific registers (available on 586 and better only) - * Note: the rd* operations modify the parameters directly (without using - * pointer indirection), this allows gcc to optimize better - */ -#define rdmsrq(msr, val) \ - ((val) = native_read_msr((msr))) +/* Access to machine-specific registers (available on 586 and better only) */ + +static __always_inline u64 rdmsrq(u32 msr) +{ + return native_read_msr(msr); +} static inline void wrmsrq(u32 msr, u64 val) { @@ -237,7 +236,7 @@ int wrmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8]); #else /* CONFIG_SMP */ static inline int rdmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 *q) { - rdmsrq(msr_no, *q); + *q = rdmsrq(msr_no); return 0; } static inline int wrmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 q) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 93754aa60d5e..19442bc3af37 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -150,10 +150,10 @@ static inline int paravirt_write_msr_safe(u32 msr, u64 val) return PVOP_CALL2(int, pv_ops, cpu.write_msr_safe, msr, val); } -#define rdmsrq(msr, val) \ -do { \ - val = paravirt_read_msr(msr); \ -} while (0) +static __always_inline u64 rdmsrq(u32 msr) +{ + return paravirt_read_msr(msr); +} static inline void wrmsrq(u32 msr, u64 val) { diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 90025451ace2..7a6c77e6a44e 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1193,7 +1193,7 @@ void disable_local_APIC(void) if (enabled_via_apicbase) { struct msr val; - rdmsrq(MSR_IA32_APICBASE, val.q); + val.q = rdmsrq(MSR_IA32_APICBASE); val.l &= ~MSR_IA32_APICBASE_ENABLE; wrmsrq(MSR_IA32_APICBASE, val.q); } @@ -1710,7 +1710,7 @@ static bool x2apic_hw_locked(void) x86_arch_cap_msr = x86_read_arch_cap_msr(); if (x86_arch_cap_msr & ARCH_CAP_XAPIC_DISABLE) { - rdmsrq(MSR_IA32_XAPIC_DISABLE_STATUS, msr); + msr = rdmsrq(MSR_IA32_XAPIC_DISABLE_STATUS); return (msr & LEGACY_XAPIC_DISABLED); } return false; @@ -1723,7 +1723,7 @@ static void __x2apic_disable(void) if (!boot_cpu_has(X86_FEATURE_APIC)) return; - rdmsrq(MSR_IA32_APICBASE, msr); + msr = rdmsrq(MSR_IA32_APICBASE); if (!(msr & X2APIC_ENABLE)) return; /* Disable xapic and x2apic first and then reenable xapic mode */ @@ -1736,7 +1736,7 @@ static void __x2apic_enable(void) { u64 msr; - rdmsrq(MSR_IA32_APICBASE, msr); + msr = rdmsrq(MSR_IA32_APICBASE); if (msr & X2APIC_ENABLE) return; wrmsrq(MSR_IA32_APICBASE, msr | X2APIC_ENABLE); @@ -1976,7 +1976,7 @@ static bool __init apic_verify(unsigned long addr) /* The BIOS may have set up the APIC at some other address */ if (boot_cpu_data.x86 >= 6) { - rdmsrq(MSR_IA32_APICBASE, val.q); + val.q = rdmsrq(MSR_IA32_APICBASE); if (val.l & MSR_IA32_APICBASE_ENABLE) addr = val.l & MSR_IA32_APICBASE_BASE; } @@ -1999,7 +1999,7 @@ bool __init apic_force_enable(unsigned long addr) * and AMD K7 (Model > 1) or later. */ if (boot_cpu_data.x86 >= 6) { - rdmsrq(MSR_IA32_APICBASE, val.q); + val.q = rdmsrq(MSR_IA32_APICBASE); if (!(val.l & MSR_IA32_APICBASE_ENABLE)) { pr_info("Local APIC disabled by BIOS -- reenabling.\n"); val.l &= ~MSR_IA32_APICBASE_BASE; @@ -2476,7 +2476,7 @@ static void lapic_resume(void *data) * SMP! We'll need to do this as part of the CPU restore! */ if (boot_cpu_data.x86 >= 6) { - rdmsrq(MSR_IA32_APICBASE, val.q); + val.q = rdmsrq(MSR_IA32_APICBASE); val.l &= ~MSR_IA32_APICBASE_BASE; val.l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr; wrmsrq(MSR_IA32_APICBASE, val.q); diff --git a/arch/x86/kernel/apic/apic_numachip.c b/arch/x86/kernel/apic/apic_numachip.c index a60c8960bbfd..3af93e3f2179 100644 --- a/arch/x86/kernel/apic/apic_numachip.c +++ b/arch/x86/kernel/apic/apic_numachip.c @@ -32,7 +32,7 @@ static u32 numachip1_get_apic_id(u32 x) unsigned int id = (x >> 24) & 0xff; if (cpu_feature_enabled(X86_FEATURE_NODEID_MSR)) { - rdmsrq(MSR_FAM10H_NODE_ID, value); + value = rdmsrq(MSR_FAM10H_NODE_ID); id |= (value << 2) & 0xff00; } @@ -43,7 +43,7 @@ static u32 numachip2_get_apic_id(u32 x) { u64 mcfg; - rdmsrq(MSR_FAM10H_MMIO_CONF_BASE, mcfg); + mcfg = rdmsrq(MSR_FAM10H_MMIO_CONF_BASE); return ((mcfg >> (28 - 8)) & 0xfff00) | (x >> 24); } @@ -151,7 +151,7 @@ static void fixup_cpu_id(struct cpuinfo_x86 *c, int node) /* Account for nodes per socket in multi-core-module processors */ if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) { - rdmsrq(MSR_FAM10H_NODE_ID, val); + val = rdmsrq(MSR_FAM10H_NODE_ID); nodes = ((val >> 3) & 7) + 1; } diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c index 99444409c026..3efceee443b7 100644 --- a/arch/x86/kernel/cet.c +++ b/arch/x86/kernel/cet.c @@ -56,7 +56,7 @@ static void do_user_cp_fault(struct pt_regs *regs, unsigned long error_code) * will be whatever is live in userspace. So read the SSP before enabling * interrupts so locking the fpregs to do it later is not required. */ - rdmsrq(MSR_IA32_PL3_SSP, ssp); + ssp = rdmsrq(MSR_IA32_PL3_SSP); cond_local_irq_enable(regs); diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 54e14ed276b5..4bd43e899c64 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -160,7 +160,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c) if (mbytes > 508) mbytes = 508; - rdmsrq(MSR_K6_WHCR, val.q); + val.q = rdmsrq(MSR_K6_WHCR); if ((val.l & 0x0000FFFF) == 0) { unsigned long flags; val.l = (1 << 0) | ((mbytes / 4) << 1); @@ -181,7 +181,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c) if (mbytes > 4092) mbytes = 4092; - rdmsrq(MSR_K6_WHCR, val.q); + val.q = rdmsrq(MSR_K6_WHCR); if ((val.l & 0xFFFF0000) == 0) { unsigned long flags; val.l = ((mbytes >> 2) << 22) | (1 << 16); @@ -228,7 +228,7 @@ static void init_amd_k7(struct cpuinfo_x86 *c) * As per AMD technical note 27212 0.2 */ if ((c->x86_model == 8 && c->x86_stepping >= 1) || (c->x86_model > 8)) { - rdmsrq(MSR_K7_CLK_CTL, val.q); + val.q = rdmsrq(MSR_K7_CLK_CTL); if ((val.l & 0xfff00000) != 0x20000000) { pr_info("CPU: CLK_CTL MSR was %x. Reprogramming to %x\n", val.l, ((val.l & 0x000fffff) | 0x20000000)); @@ -429,7 +429,7 @@ static void bsp_init_amd(struct cpuinfo_x86 *c) (c->x86 == 0x10 && c->x86_model >= 0x2)) { u64 val; - rdmsrq(MSR_K7_HWCR, val); + val = rdmsrq(MSR_K7_HWCR); if (!(val & BIT(24))) pr_warn(FW_BUG "TSC doesn't count with P0 frequency!\n"); } @@ -583,7 +583,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) */ if (cpu_has(c, X86_FEATURE_SME) || cpu_has(c, X86_FEATURE_SEV)) { /* Check if memory encryption is enabled */ - rdmsrq(MSR_AMD64_SYSCFG, msr); + msr = rdmsrq(MSR_AMD64_SYSCFG); if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT)) goto clear_all; @@ -600,7 +600,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) if (!sme_me_mask) setup_clear_cpu_cap(X86_FEATURE_SME); - rdmsrq(MSR_K7_HWCR, msr); + msr = rdmsrq(MSR_K7_HWCR); if (!(msr & MSR_K7_HWCR_SMMLOCK)) goto clear_sev; @@ -1111,7 +1111,7 @@ static void init_amd(struct cpuinfo_x86 *c) init_amd_cacheinfo(c); if (cpu_has(c, X86_FEATURE_SVM)) { - rdmsrq(MSR_VM_CR, vm_cr); + vm_cr = rdmsrq(MSR_VM_CR); if (vm_cr & SVM_VM_CR_SVM_DIS_MASK) { pr_notice_once("SVM disabled (by BIOS) in MSR_VM_CR\n"); clear_cpu_cap(c, X86_FEATURE_SVM); diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c index 7ffc78d5ebf2..492dc9a11d6b 100644 --- a/arch/x86/kernel/cpu/aperfmperf.c +++ b/arch/x86/kernel/cpu/aperfmperf.c @@ -41,8 +41,8 @@ static void init_counter_refs(void *data) { u64 aperf, mperf; - rdmsrq(MSR_IA32_APERF, aperf); - rdmsrq(MSR_IA32_MPERF, mperf); + aperf = rdmsrq(MSR_IA32_APERF); + mperf = rdmsrq(MSR_IA32_MPERF); this_cpu_write(cpu_samples.aperf, aperf); this_cpu_write(cpu_samples.mperf, mperf); @@ -479,8 +479,8 @@ void arch_scale_freq_tick(void) if (!cpu_feature_enabled(X86_FEATURE_APERFMPERF)) return; - rdmsrq(MSR_IA32_APERF, aperf); - rdmsrq(MSR_IA32_MPERF, mperf); + aperf = rdmsrq(MSR_IA32_APERF); + mperf = rdmsrq(MSR_IA32_MPERF); acnt = aperf - s->aperf; mcnt = mperf - s->mperf; diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 56eac5611c31..aeb4770ba73c 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -761,7 +761,7 @@ void update_srbds_msr(void) if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) return; - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); + mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); switch (srbds_mitigation) { case SRBDS_MITIGATION_OFF: @@ -897,7 +897,7 @@ void update_gds_msr(void) switch (gds_mitigation) { case GDS_MITIGATION_OFF: - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); + mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); mcu_ctrl |= GDS_MITG_DIS; break; case GDS_MITIGATION_FULL_LOCKED: @@ -907,7 +907,7 @@ void update_gds_msr(void) * CPUs. */ case GDS_MITIGATION_FULL: - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); + mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); mcu_ctrl &= ~GDS_MITG_DIS; break; case GDS_MITIGATION_FORCE: @@ -924,7 +924,7 @@ void update_gds_msr(void) * GDS_MITG_DIS will be ignored if this processor is locked but the boot * processor was not. */ - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl_after); + mcu_ctrl_after = rdmsrq(MSR_IA32_MCU_OPT_CTRL); WARN_ON_ONCE(mcu_ctrl != mcu_ctrl_after); } @@ -959,7 +959,7 @@ static void __init gds_select_mitigation(void) if (gds_mitigation == GDS_MITIGATION_FORCE) gds_mitigation = GDS_MITIGATION_FULL; - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); + mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); if (mcu_ctrl & GDS_MITG_LOCKED) { if (gds_mitigation == GDS_MITIGATION_OFF) pr_warn("Mitigation locked. Disable failed.\n"); @@ -3274,7 +3274,7 @@ void __init cpu_select_mitigations(void) * init code as it is not enumerated and depends on the family. */ if (cpu_feature_enabled(X86_FEATURE_MSR_SPEC_CTRL)) { - rdmsrq(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base); + x86_spec_ctrl_base = rdmsrq(MSR_IA32_SPEC_CTRL); /* * Previously running kernel (kexec), may have some controls diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c index 177f964d4d36..cf853af86ae4 100644 --- a/arch/x86/kernel/cpu/bus_lock.c +++ b/arch/x86/kernel/cpu/bus_lock.c @@ -105,7 +105,7 @@ static bool split_lock_verify_msr(bool on) ctrl &= ~MSR_TEST_CTRL_SPLIT_LOCK_DETECT; if (wrmsrq_safe(MSR_TEST_CTRL, ctrl)) return false; - rdmsrq(MSR_TEST_CTRL, tmp); + tmp = rdmsrq(MSR_TEST_CTRL); return ctrl == tmp; } @@ -145,7 +145,7 @@ static void __init __split_lock_setup(void) return; } - rdmsrq(MSR_TEST_CTRL, msr_test_ctrl_cache); + msr_test_ctrl_cache = rdmsrq(MSR_TEST_CTRL); if (!split_lock_verify_msr(true)) { pr_info("MSR access failed: Disabled\n"); @@ -305,7 +305,7 @@ void bus_lock_init(void) if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT)) return; - rdmsrq(MSR_IA32_DEBUGCTLMSR, val); + val = rdmsrq(MSR_IA32_DEBUGCTLMSR); if ((boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) && (sld_state == sld_warn || sld_state == sld_fatal)) || @@ -383,7 +383,7 @@ static void __init split_lock_setup(struct cpuinfo_x86 *c) * MSR_IA32_CORE_CAPS_SPLIT_LOCK_DETECT is. All CPUs that set * it have split lock detection. */ - rdmsrq(MSR_IA32_CORE_CAPS, ia32_core_caps); + ia32_core_caps = rdmsrq(MSR_IA32_CORE_CAPS); if (ia32_core_caps & MSR_IA32_CORE_CAPS_SPLIT_LOCK_DETECT) goto supported; diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c index 513fa1f640f9..6cd89b5ac9de 100644 --- a/arch/x86/kernel/cpu/centaur.c +++ b/arch/x86/kernel/cpu/centaur.c @@ -30,7 +30,7 @@ static void init_c3(struct cpuinfo_x86 *c) /* enable ACE unit, if present and disabled */ if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) { - rdmsrq(MSR_VIA_FCR, msr); + msr = rdmsrq(MSR_VIA_FCR); /* enable ACE unit */ wrmsrq(MSR_VIA_FCR, msr | ACE_FCR); pr_info("CPU: Enabled ACE h/w crypto\n"); @@ -38,7 +38,7 @@ static void init_c3(struct cpuinfo_x86 *c) /* enable RNG unit, if present and disabled */ if ((tmp & (RNG_PRESENT | RNG_ENABLED)) == RNG_PRESENT) { - rdmsrq(MSR_VIA_RNG, msr); + msr = rdmsrq(MSR_VIA_RNG); /* enable RNG unit */ wrmsrq(MSR_VIA_RNG, msr | RNG_ENABLE); pr_info("CPU: Enabled h/w RNG\n"); @@ -52,7 +52,7 @@ static void init_c3(struct cpuinfo_x86 *c) #ifdef CONFIG_X86_32 /* Cyrix III family needs CX8 & PGE explicitly enabled. */ if (c->x86_model >= 6 && c->x86_model <= 13) { - rdmsrq(MSR_VIA_FCR, msr); + msr = rdmsrq(MSR_VIA_FCR); wrmsrq(MSR_VIA_FCR, msr | (1 << 1 | 1 << 7)); set_cpu_cap(c, X86_FEATURE_CX8); } @@ -169,7 +169,7 @@ static void init_centaur(struct cpuinfo_x86 *c) name = "??"; } - rdmsrq(MSR_IDT_FCR1, val.q); + val.q = rdmsrq(MSR_IDT_FCR1); newlo = (val.l | fcr_set) & (~fcr_clr); if (newlo != val.l) { diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index c7352827f491..b2d9f8b14909 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -346,7 +346,7 @@ static void squash_the_stupid_serial_number(struct cpuinfo_x86 *c) /* Disable processor serial number: */ - rdmsrq(MSR_IA32_BBL_CR_CTL, val.q); + val.q = rdmsrq(MSR_IA32_BBL_CR_CTL); val.l |= 0x200000; wrmsrq(MSR_IA32_BBL_CR_CTL, val.q); @@ -610,7 +610,7 @@ __noendbr u64 ibt_save(bool disable) u64 msr = 0; if (cpu_feature_enabled(X86_FEATURE_IBT)) { - rdmsrq(MSR_IA32_S_CET, msr); + msr = rdmsrq(MSR_IA32_S_CET); if (disable) wrmsrq(MSR_IA32_S_CET, msr & ~CET_ENDBR_EN); } @@ -623,7 +623,7 @@ __noendbr void ibt_restore(u64 save) u64 msr; if (cpu_feature_enabled(X86_FEATURE_IBT)) { - rdmsrq(MSR_IA32_S_CET, msr); + msr = rdmsrq(MSR_IA32_S_CET); msr &= ~CET_ENDBR_EN; msr |= (save & CET_ENDBR_EN); wrmsrq(MSR_IA32_S_CET, msr); @@ -1357,7 +1357,7 @@ u64 x86_read_arch_cap_msr(void) u64 x86_arch_cap_msr = 0; if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) - rdmsrq(MSR_IA32_ARCH_CAPABILITIES, x86_arch_cap_msr); + x86_arch_cap_msr = rdmsrq(MSR_IA32_ARCH_CAPABILITIES); return x86_arch_cap_msr; } @@ -1923,10 +1923,10 @@ static bool detect_null_seg_behavior(void) */ unsigned long old_base, tmp; - rdmsrq(MSR_FS_BASE, old_base); + old_base = rdmsrq(MSR_FS_BASE); wrmsrq(MSR_FS_BASE, 1); loadsegment(fs, 0); - rdmsrq(MSR_FS_BASE, tmp); + tmp = rdmsrq(MSR_FS_BASE); wrmsrq(MSR_FS_BASE, old_base); return tmp == 0; } diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c index 10a92927a515..7228fc2bb43e 100644 --- a/arch/x86/kernel/cpu/feat_ctl.c +++ b/arch/x86/kernel/cpu/feat_ctl.c @@ -40,7 +40,7 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c) * as they exist on any CPU that supports VMX, i.e. we want the WARN if * the RDMSR faults. */ - rdmsrq(MSR_IA32_VMX_PROCBASED_CTLS, val.q); + val.q = rdmsrq(MSR_IA32_VMX_PROCBASED_CTLS); supported = val.h; c->vmx_capability[PRIMARY_CTLS] = supported; @@ -53,7 +53,7 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c) c->vmx_capability[TERTIARY_CTLS_LOW] = val.l; c->vmx_capability[TERTIARY_CTLS_HIGH] = val.h; - rdmsrq(MSR_IA32_VMX_PINBASED_CTLS, val.q); + val.q = rdmsrq(MSR_IA32_VMX_PINBASED_CTLS); supported = val.h; rdmsrq_safe(MSR_IA32_VMX_VMFUNC, &val.q); funcs = val.h; diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c index ec51c2b9a257..44b462799cf6 100644 --- a/arch/x86/kernel/cpu/hygon.c +++ b/arch/x86/kernel/cpu/hygon.c @@ -99,7 +99,7 @@ static void bsp_init_hygon(struct cpuinfo_x86 *c) if (cpu_has(c, X86_FEATURE_CONSTANT_TSC)) { u64 val; - rdmsrq(MSR_K7_HWCR, val); + val = rdmsrq(MSR_K7_HWCR); if (!(val & BIT(24))) pr_warn(FW_BUG "TSC doesn't count with P0 frequency!\n"); } @@ -194,7 +194,7 @@ static void init_hygon(struct cpuinfo_x86 *c) init_hygon_cacheinfo(c); if (cpu_has(c, X86_FEATURE_SVM)) { - rdmsrq(MSR_VM_CR, vm_cr); + vm_cr = rdmsrq(MSR_VM_CR); if (vm_cr & SVM_VM_CR_SVM_DIS_MASK) { pr_notice_once("SVM disabled (by BIOS) in MSR_VM_CR\n"); clear_cpu_cap(c, X86_FEATURE_SVM); diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index 4297ceb2cb24..2aabe9affa0c 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -159,7 +159,7 @@ static void detect_tme_early(struct cpuinfo_x86 *c) u64 tme_activate; int keyid_bits; - rdmsrq(MSR_IA32_TME_ACTIVATE, tme_activate); + tme_activate = rdmsrq(MSR_IA32_TME_ACTIVATE); if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(tme_activate)) { pr_info_once("x86/tme: not enabled by BIOS\n"); @@ -335,7 +335,7 @@ static void early_init_intel(struct cpuinfo_x86 *c) * string flag and enhanced fast string capabilities accordingly. */ if (c->x86_vfm >= INTEL_PENTIUM_M_DOTHAN) { - rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable); + misc_enable = rdmsrq(MSR_IA32_MISC_ENABLE); if (misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING) { /* X86_FEATURE_ERMS is set based on CPUID */ set_cpu_cap(c, X86_FEATURE_REP_GOOD); @@ -579,7 +579,7 @@ static void init_intel(struct cpuinfo_x86 *c) if (boot_cpu_has(X86_FEATURE_DS)) { u64 l; - rdmsrq(MSR_IA32_MISC_ENABLE, l); + l = rdmsrq(MSR_IA32_MISC_ENABLE); if (!(l & MSR_IA32_MISC_ENABLE_BTS_UNAVAIL)) set_cpu_cap(c, X86_FEATURE_BTS); if (!(l & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL)) diff --git a/arch/x86/kernel/cpu/intel_epb.c b/arch/x86/kernel/cpu/intel_epb.c index 2c56f8730f59..a02d562253d9 100644 --- a/arch/x86/kernel/cpu/intel_epb.c +++ b/arch/x86/kernel/cpu/intel_epb.c @@ -79,7 +79,7 @@ static int intel_epb_save(void *data) { u64 epb; - rdmsrq(MSR_IA32_ENERGY_PERF_BIAS, epb); + epb = rdmsrq(MSR_IA32_ENERGY_PERF_BIAS); /* * Ensure that saved_epb will always be nonzero after this write even if * the EPB value read from the MSR is 0. @@ -94,7 +94,7 @@ static void intel_epb_restore(void *data) u64 val = this_cpu_read(saved_epb); u64 epb; - rdmsrq(MSR_IA32_ENERGY_PERF_BIAS, epb); + epb = rdmsrq(MSR_IA32_ENERGY_PERF_BIAS); if (val) { val &= EPB_MASK; } else { diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c index 1cc20b855b7e..9695af953299 100644 --- a/arch/x86/kernel/cpu/mce/amd.c +++ b/arch/x86/kernel/cpu/mce/amd.c @@ -438,7 +438,7 @@ static void threshold_restart_block(void *_tr) if (!this_cpu_read(threshold_banks) && !tr->set_lvt_off) return; - rdmsrq(tr->b->address, val.q); + val.q = rdmsrq(tr->b->address); /* * Reset error count and overflow bit. @@ -658,7 +658,7 @@ static void disable_err_thresholding(struct cpuinfo_x86 *c, unsigned int bank) return; } - rdmsrq(MSR_K7_HWCR, hwcr); + hwcr = rdmsrq(MSR_K7_HWCR); /* McStatusWrEn has to be set */ need_toggle = !(hwcr & BIT(18)); diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c index ab469605fc89..df56ca06275b 100644 --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -1845,7 +1845,7 @@ static void __mcheck_cpu_cap_init(void) u64 cap; u8 b; - rdmsrq(MSR_IA32_MCG_CAP, cap); + cap = rdmsrq(MSR_IA32_MCG_CAP); b = cap & MCG_BANKCNT_MASK; @@ -1864,7 +1864,7 @@ static void __mcheck_cpu_init_generic(void) { u64 cap; - rdmsrq(MSR_IA32_MCG_CAP, cap); + cap = rdmsrq(MSR_IA32_MCG_CAP); if (cap & MCG_CTL_P) wrmsrq(MSR_IA32_MCG_CTL, ~0ULL); } @@ -1896,7 +1896,7 @@ static void __mcheck_cpu_init_prepare_banks(void) wrmsrq(mca_msr_reg(i, MCA_CTL), b->ctl); wrmsrq(mca_msr_reg(i, MCA_STATUS), 0); - rdmsrq(mca_msr_reg(i, MCA_CTL), msrval); + msrval = rdmsrq(mca_msr_reg(i, MCA_CTL)); b->init = !!msrval; } } @@ -2214,7 +2214,7 @@ void mca_bsp_init(struct cpuinfo_x86 *c) if (mce_flags.smca) smca_bsp_init(); - rdmsrq(MSR_IA32_MCG_CAP, cap); + cap = rdmsrq(MSR_IA32_MCG_CAP); /* Use accurate RIP reporting if available. */ if ((cap & MCG_EXT_P) && MCG_EXT_CNT(cap) >= 9) diff --git a/arch/x86/kernel/cpu/mce/inject.c b/arch/x86/kernel/cpu/mce/inject.c index 6f8a49d8baeb..aa933864f32e 100644 --- a/arch/x86/kernel/cpu/mce/inject.c +++ b/arch/x86/kernel/cpu/mce/inject.c @@ -743,7 +743,7 @@ static void check_hw_inj_possible(void) u64 status = MCI_STATUS_VAL, ipid; /* Check whether bank is populated */ - rdmsrq(MSR_AMD64_SMCA_MCx_IPID(bank), ipid); + ipid = rdmsrq(MSR_AMD64_SMCA_MCx_IPID(bank)); if (!ipid) continue; diff --git a/arch/x86/kernel/cpu/mce/intel.c b/arch/x86/kernel/cpu/mce/intel.c index 4655223ba560..2edb05d5e2d7 100644 --- a/arch/x86/kernel/cpu/mce/intel.c +++ b/arch/x86/kernel/cpu/mce/intel.c @@ -94,7 +94,7 @@ static bool cmci_supported(int *banks) if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6) return false; - rdmsrq(MSR_IA32_MCG_CAP, cap); + cap = rdmsrq(MSR_IA32_MCG_CAP); *banks = min_t(unsigned, MAX_NR_BANKS, cap & MCG_BANKCNT_MASK); return !!(cap & MCG_CMCI_P); } @@ -106,7 +106,7 @@ static bool lmce_supported(void) if (mca_cfg.lmce_disabled) return false; - rdmsrq(MSR_IA32_MCG_CAP, tmp); + tmp = rdmsrq(MSR_IA32_MCG_CAP); /* * LMCE depends on recovery support in the processor. Hence both @@ -123,7 +123,7 @@ static bool lmce_supported(void) * WARN if the MSR isn't locked as init_ia32_feat_ctl() unconditionally * locks the MSR in the event that it wasn't already locked by BIOS. */ - rdmsrq(MSR_IA32_FEAT_CTL, tmp); + tmp = rdmsrq(MSR_IA32_FEAT_CTL); if (WARN_ON_ONCE(!(tmp & FEAT_CTL_LOCKED))) return false; @@ -141,7 +141,7 @@ static void cmci_set_threshold(int bank, int thresh) u64 val; raw_spin_lock_irqsave(&cmci_discover_lock, flags); - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); + val = rdmsrq(MSR_IA32_MCx_CTL2(bank)); val &= ~MCI_CTL2_CMCI_THRESHOLD_MASK; wrmsrq(MSR_IA32_MCx_CTL2(bank), val | thresh); raw_spin_unlock_irqrestore(&cmci_discover_lock, flags); @@ -184,7 +184,7 @@ static bool cmci_skip_bank(int bank, u64 *val) if (test_bit(bank, mce_banks_ce_disabled)) return true; - rdmsrq(MSR_IA32_MCx_CTL2(bank), *val); + *val = rdmsrq(MSR_IA32_MCx_CTL2(bank)); /* Already owned by someone else? */ if (*val & MCI_CTL2_CMCI_EN) { @@ -233,7 +233,7 @@ static void cmci_claim_bank(int bank, u64 val, int bios_zero_thresh, int *bios_w val |= MCI_CTL2_CMCI_EN; wrmsrq(MSR_IA32_MCx_CTL2(bank), val); - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); + val = rdmsrq(MSR_IA32_MCx_CTL2(bank)); /* If the enable bit did not stick, this bank should be polled. */ if (!(val & MCI_CTL2_CMCI_EN)) { @@ -324,7 +324,7 @@ static void __cmci_disable_bank(int bank) if (!test_bit(bank, this_cpu_ptr(mce_banks_owned))) return; - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); + val = rdmsrq(MSR_IA32_MCx_CTL2(bank)); val &= ~MCI_CTL2_CMCI_EN; wrmsrq(MSR_IA32_MCx_CTL2(bank), val); __clear_bit(bank, this_cpu_ptr(mce_banks_owned)); @@ -430,7 +430,7 @@ void intel_init_lmce(void) if (!lmce_supported()) return; - rdmsrq(MSR_IA32_MCG_EXT_CTL, val); + val = rdmsrq(MSR_IA32_MCG_EXT_CTL); if (!(val & MCG_EXT_CTL_LMCE_EN)) wrmsrq(MSR_IA32_MCG_EXT_CTL, val | MCG_EXT_CTL_LMCE_EN); @@ -443,7 +443,7 @@ void intel_clear_lmce(void) if (!lmce_supported()) return; - rdmsrq(MSR_IA32_MCG_EXT_CTL, val); + val = rdmsrq(MSR_IA32_MCG_EXT_CTL); val &= ~MCG_EXT_CTL_LMCE_EN; wrmsrq(MSR_IA32_MCG_EXT_CTL, val); } diff --git a/arch/x86/kernel/cpu/mce/p5.c b/arch/x86/kernel/cpu/mce/p5.c index 3c2b6cc918b1..b441c720f9b7 100644 --- a/arch/x86/kernel/cpu/mce/p5.c +++ b/arch/x86/kernel/cpu/mce/p5.c @@ -26,8 +26,8 @@ noinstr void pentium_machine_check(struct pt_regs *regs) u64 addr, type; instrumentation_begin(); - rdmsrq(MSR_IA32_P5_MC_ADDR, addr); - rdmsrq(MSR_IA32_P5_MC_TYPE, type); + addr = rdmsrq(MSR_IA32_P5_MC_ADDR); + type = rdmsrq(MSR_IA32_P5_MC_TYPE); pr_emerg("CPU#%d: Machine Check Exception: 0x%8X (type 0x%8X).\n", smp_processor_id(), (u32)addr, (u32)type); @@ -55,8 +55,8 @@ void intel_p5_mcheck_init(struct cpuinfo_x86 *c) return; /* Read registers before enabling: */ - rdmsrq(MSR_IA32_P5_MC_ADDR, q); - rdmsrq(MSR_IA32_P5_MC_TYPE, q); + q = rdmsrq(MSR_IA32_P5_MC_ADDR); + q = rdmsrq(MSR_IA32_P5_MC_TYPE); pr_info("Intel old style machine check architecture supported.\n"); /* Enable MCE: */ diff --git a/arch/x86/kernel/cpu/mce/winchip.c b/arch/x86/kernel/cpu/mce/winchip.c index 7040243533d9..7b967f2abd8f 100644 --- a/arch/x86/kernel/cpu/mce/winchip.c +++ b/arch/x86/kernel/cpu/mce/winchip.c @@ -30,7 +30,7 @@ void winchip_mcheck_init(struct cpuinfo_x86 *c) { struct msr val; - rdmsrq(MSR_IDT_FCR1, val.q); + val.q = rdmsrq(MSR_IDT_FCR1); val.l |= (1<<2); /* Enable EIERRINT (int 18 MCE) */ val.l &= ~(1<<4); /* Enable MCE */ wrmsrq(MSR_IDT_FCR1, val.q); diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c index 1142183c950c..4d199abd8fd8 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -991,7 +991,7 @@ static __init bool staging_available(void) if (!(val & ARCH_CAP_MCU_ENUM)) return false; - rdmsrq(MSR_IA32_MCU_ENUMERATION, val); + val = rdmsrq(MSR_IA32_MCU_ENUMERATION); return !!(val & MCU_STAGING); } diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index b4af7c0a70ac..e1388ed27384 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -74,7 +74,7 @@ u64 hv_get_non_nested_msr(unsigned int reg) if (hv_is_synic_msr(reg) && ms_hyperv.paravisor_present) hv_ivm_msr_read(reg, &value); else - rdmsrq(reg, value); + value = rdmsrq(reg); return value; } EXPORT_SYMBOL_GPL(hv_get_non_nested_msr); @@ -399,7 +399,7 @@ static unsigned long hv_get_tsc_khz(void) { unsigned long freq; - rdmsrq(HV_X64_MSR_TSC_FREQUENCY, freq); + freq = rdmsrq(HV_X64_MSR_TSC_FREQUENCY); return freq / 1000; } @@ -660,7 +660,7 @@ static void __init ms_hyperv_init_platform(void) */ u64 hv_lapic_frequency; - rdmsrq(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency); + hv_lapic_frequency = rdmsrq(HV_X64_MSR_APIC_FREQUENCY); hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ); lapic_timer_period = hv_lapic_frequency; pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n", diff --git a/arch/x86/kernel/cpu/mtrr/amd.c b/arch/x86/kernel/cpu/mtrr/amd.c index a73715d6f05c..652e4d64ff4a 100644 --- a/arch/x86/kernel/cpu/mtrr/amd.c +++ b/arch/x86/kernel/cpu/mtrr/amd.c @@ -13,7 +13,7 @@ amd_get_mtrr(unsigned int reg, unsigned long *base, unsigned long val; struct msr msr; - rdmsrq(MSR_K6_UWCCR, msr.q); + msr.q = rdmsrq(MSR_K6_UWCCR); /* Upper dword is region 1, lower is region 0 */ if (reg == 1) val = msr.h; @@ -68,7 +68,7 @@ amd_set_mtrr(unsigned int reg, unsigned long base, unsigned long size, mtrr_type /* * Low is MTRR0, High MTRR 1 */ - rdmsrq(MSR_K6_UWCCR, msr.q); + msr.q = rdmsrq(MSR_K6_UWCCR); regs[0] = msr.l; regs[1] = msr.h; diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c index cd1a6dec4064..2b72c784db9e 100644 --- a/arch/x86/kernel/cpu/mtrr/cleanup.c +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c @@ -670,7 +670,7 @@ int __init mtrr_cleanup(void) if (!cpu_feature_enabled(X86_FEATURE_MTRR) || enable_mtrr_cleanup < 1) return 0; - rdmsrq(MSR_MTRRdefType, def); + def = rdmsrq(MSR_MTRRdefType); def &= 0xff; if (def != MTRR_TYPE_UNCACHABLE) return 0; @@ -870,7 +870,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn) if (!cpu_feature_enabled(X86_FEATURE_MTRR) || disable_mtrr_trim) return 0; - rdmsrq(MSR_MTRRdefType, def); + def = rdmsrq(MSR_MTRRdefType); def &= MTRR_DEF_TYPE_TYPE; if (def != MTRR_TYPE_UNCACHABLE) return 0; diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c index 67cf69f24b00..4d8034a7fdc8 100644 --- a/arch/x86/kernel/cpu/mtrr/generic.c +++ b/arch/x86/kernel/cpu/mtrr/generic.c @@ -112,7 +112,7 @@ static inline void k8_check_syscfg_dram_mod_en(void) if (cc_platform_has(CC_ATTR_HOST_SEV_SNP)) return; - rdmsrq(MSR_AMD64_SYSCFG, val.q); + val.q = rdmsrq(MSR_AMD64_SYSCFG); if (val.l & K8_MTRRFIXRANGE_DRAM_MODIFY) { pr_err(FW_WARN "MTRR: CPU %u: SYSCFG[MtrrFixDramModEn]" " not cleared by BIOS, clearing this bit\n", @@ -559,10 +559,10 @@ get_mtrr_var_range(unsigned int index, struct mtrr_var_range *vr) { struct msr val; - rdmsrq(MTRRphysBase_MSR(index), val.q); + val.q = rdmsrq(MTRRphysBase_MSR(index)); vr->base_lo = val.l; vr->base_hi = val.h; - rdmsrq(MTRRphysMask_MSR(index), val.q); + val.q = rdmsrq(MTRRphysMask_MSR(index)); vr->mask_lo = val.l; vr->mask_hi = val.h; } @@ -588,12 +588,12 @@ static void get_fixed_ranges(mtrr_type *frs) k8_check_syscfg_dram_mod_en(); - rdmsrq(MSR_MTRRfix64K_00000, p[0]); + p[0] = rdmsrq(MSR_MTRRfix64K_00000); for (i = 0; i < 2; i++) - rdmsrq(MSR_MTRRfix16K_80000 + i, p[1 + i]); + p[1 + i] = rdmsrq(MSR_MTRRfix16K_80000 + i); for (i = 0; i < 8; i++) - rdmsrq(MSR_MTRRfix4K_C0000 + i, p[3 + i]); + p[3 + i] = rdmsrq(MSR_MTRRfix4K_C0000 + i); } void mtrr_save_fixed_ranges(void *info) @@ -700,7 +700,7 @@ bool __init get_mtrr_state(void) vrs = mtrr_state.var_ranges; - rdmsrq(MSR_MTRRcap, q); + q = rdmsrq(MSR_MTRRcap); mtrr_state.have_fixed = q & MTRR_CAP_FIX; for (i = 0; i < num_var_ranges; i++) @@ -708,13 +708,13 @@ bool __init get_mtrr_state(void) if (mtrr_state.have_fixed) get_fixed_ranges(mtrr_state.fixed_ranges); - rdmsrq(MSR_MTRRdefType, q); + q = rdmsrq(MSR_MTRRdefType); mtrr_state.def_type = q & MTRR_DEF_TYPE_TYPE; mtrr_state.enabled = (q & MTRR_DEF_TYPE_ENABLE) >> MTRR_STATE_SHIFT; if (amd_special_default_mtrr()) { /* TOP_MEM2 */ - rdmsrq(MSR_K8_TOP_MEM2, mtrr_tom2); + mtrr_tom2 = rdmsrq(MSR_K8_TOP_MEM2); mtrr_tom2 &= 0xffffff800000ULL; } @@ -770,7 +770,7 @@ static void set_fixed_range(int msr, bool *changed, unsigned int *msrwords) { struct msr val; - rdmsrq(msr, val.q); + val.q = rdmsrq(msr); if (val.l != msrwords[0] || val.h != msrwords[1]) { mtrr_wrmsr(msr, msrwords[0], msrwords[1]); @@ -818,7 +818,7 @@ static void generic_get_mtrr(unsigned int reg, unsigned long *base, */ get_cpu(); - rdmsrq(MTRRphysMask_MSR(reg), mask); + mask = rdmsrq(MTRRphysMask_MSR(reg)); if (!(mask & MTRR_PHYSMASK_V)) { /* Invalid (i.e. free) range */ @@ -828,7 +828,7 @@ static void generic_get_mtrr(unsigned int reg, unsigned long *base, goto out_put_cpu; } - rdmsrq(MTRRphysBase_MSR(reg), base_msr); + base_msr = rdmsrq(MTRRphysBase_MSR(reg)); /* Work out the shifted address mask: */ tmp = mask & PAGE_MASK; @@ -889,7 +889,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr) bool changed = false; struct msr val; - rdmsrq(MTRRphysBase_MSR(index), val.q); + val.q = rdmsrq(MTRRphysBase_MSR(index)); if ((vr->base_lo & ~MTRR_PHYSBASE_RSVD) != (val.l & ~MTRR_PHYSBASE_RSVD) || (vr->base_hi & ~phys_hi_rsvd) != (val.h & ~phys_hi_rsvd)) { @@ -897,7 +897,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr) changed = true; } - rdmsrq(MTRRphysMask_MSR(index), val.q); + val.q = rdmsrq(MTRRphysMask_MSR(index)); if ((vr->mask_lo & ~MTRR_PHYSMASK_RSVD) != (val.l & ~MTRR_PHYSMASK_RSVD) || (vr->mask_hi & ~phys_hi_rsvd) != (val.h & ~phys_hi_rsvd)) { @@ -952,7 +952,7 @@ void mtrr_disable(void) struct msr val; /* Save MTRR state */ - rdmsrq(MSR_MTRRdefType, val.q); + val.q = rdmsrq(MSR_MTRRdefType); deftype_lo = val.l; deftype_hi = val.h; @@ -1065,7 +1065,7 @@ static int generic_have_wrcomb(void) { u64 config; - rdmsrq(MSR_MTRRcap, config); + config = rdmsrq(MSR_MTRRcap); return config & MTRR_CAP_WC; } diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c index 468c53b20acf..9b7abd58b677 100644 --- a/arch/x86/kernel/cpu/mtrr/mtrr.c +++ b/arch/x86/kernel/cpu/mtrr/mtrr.c @@ -571,7 +571,7 @@ void __init mtrr_bp_init(void) if (mtrr_enabled()) { /* Get the number of variable MTRR ranges. */ if (mtrr_if == &generic_mtrr_ops) - rdmsrq(MSR_MTRRcap, config); + config = rdmsrq(MSR_MTRRcap); else config = mtrr_if->var_regs; num_var_ranges = config & MTRR_CAP_VCNT; diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c index 55214d6fdc49..dd0e20179fce 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -165,7 +165,7 @@ static inline void cache_alloc_hsw_probe(void) if (wrmsrq_safe(MSR_IA32_L3_CBM_BASE, max_cbm)) return; - rdmsrq(MSR_IA32_L3_CBM_BASE, l3_cbm_0); + l3_cbm_0 = rdmsrq(MSR_IA32_L3_CBM_BASE); /* If all the bits were set in MSR, return success */ if (l3_cbm_0 != max_cbm) diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index 3838e0a13d36..530c425d7ee4 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -147,7 +147,7 @@ static int __rmid_read_phys(u32 prmid, enum resctrl_event_id eventid, u64 *val) * are error bits. */ wrmsrq(MSR_IA32_QM_EVTSEL, msr_val.q); - rdmsrq(MSR_IA32_QM_CTR, msr_val.q); + msr_val.q = rdmsrq(MSR_IA32_QM_CTR); if (msr_val.q & RMID_VAL_ERROR) return -EIO; @@ -310,7 +310,7 @@ static int __cntr_id_read(u32 cntr_id, u64 *val) * is set if the counter data is unavailable. */ wrmsrq(MSR_IA32_QM_EVTSEL, msr_val.q); - rdmsrq(MSR_IA32_QM_CTR, msr_val.q); + msr_val.q = rdmsrq(MSR_IA32_QM_CTR); if (msr_val.q & RMID_VAL_ERROR) return -EIO; diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c index d7caab0409b6..0408ac7f66fd 100644 --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c @@ -250,7 +250,7 @@ int resctrl_arch_measure_cycles_lat_fn(void *_plr) /* * Disable hardware prefetchers. */ - rdmsrq(MSR_MISC_FEATURE_CONTROL, saved); + saved = rdmsrq(MSR_MISC_FEATURE_CONTROL); wrmsrq(MSR_MISC_FEATURE_CONTROL, prefetch_disable_bits); mem_r = READ_ONCE(plr->kmem); /* @@ -346,7 +346,7 @@ static int measure_residency_fn(struct perf_event_attr *miss_attr, /* * Disable hardware prefetchers. */ - rdmsrq(MSR_MISC_FEATURE_CONTROL, saved); + saved = rdmsrq(MSR_MISC_FEATURE_CONTROL); wrmsrq(MSR_MISC_FEATURE_CONTROL, prefetch_disable_bits); /* Initialize rest of local variables */ diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 5ffa39fa86fa..37f0b1f7fe4f 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -96,7 +96,7 @@ void resctrl_arch_mon_event_config_read(void *_config_info) pr_warn_once("Invalid event id %d\n", config_info->evtid); return; } - rdmsrq(MSR_IA32_EVT_CFG_BASE + index, msrval); + msrval = rdmsrq(MSR_IA32_EVT_CFG_BASE + index); /* Report only the valid event configuration bits */ config_info->mon_config = msrval & MAX_EVT_CONFIG_BITS; diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 4913b64ec592..68337da5aa09 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -151,7 +151,7 @@ static __init bool check_for_real_bsp(u32 apic_id) * kernel must rely on the firmware enumeration order. */ if (has_apic_base) { - rdmsrq(MSR_IA32_APICBASE, msr); + msr = rdmsrq(MSR_IA32_APICBASE); is_bsp = !!(msr & MSR_IA32_APICBASE_BSP); } diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c index c5a6944df86a..5192f13f3686 100644 --- a/arch/x86/kernel/cpu/topology_amd.c +++ b/arch/x86/kernel/cpu/topology_amd.c @@ -140,7 +140,7 @@ static void parse_fam10h_node_id(struct topo_scan *tscan) if (!boot_cpu_has(X86_FEATURE_NODEID_MSR)) return; - rdmsrq(MSR_FAM10H_NODE_ID, nid.msr); + nid.msr = rdmsrq(MSR_FAM10H_NODE_ID); store_node(tscan, nid.nodes_per_pkg + 1, nid.node_id); tscan->c->topo.llc_id = nid.node_id; } @@ -168,7 +168,7 @@ static void topoext_fixup(struct topo_scan *tscan) MSR_AMD64_CPUID_EXT_FEAT_TOPOEXT_BIT) <= 0) return; - rdmsrq(MSR_AMD64_CPUID_EXT_FEAT, msrval); + msrval = rdmsrq(MSR_AMD64_CPUID_EXT_FEAT); if (msrval & MSR_AMD64_CPUID_EXT_FEAT_TOPOEXT) { set_cpu_cap(c, X86_FEATURE_TOPOEXT); pr_info_once(FW_INFO "CPU: Re-enabling disabled Topology Extensions Support.\n"); diff --git a/arch/x86/kernel/cpu/transmeta.c b/arch/x86/kernel/cpu/transmeta.c index 35d498f24e34..f8632becda18 100644 --- a/arch/x86/kernel/cpu/transmeta.c +++ b/arch/x86/kernel/cpu/transmeta.c @@ -87,7 +87,7 @@ static void init_transmeta(struct cpuinfo_x86 *c) } /* Unhide possibly hidden capability flags */ - rdmsrq(0x80860004, msr); + msr = rdmsrq(0x80860004); wrmsrq(0x80860004, msr | ~0U); cpuid_refresh_leaf(c, 0x1); c->x86_capability[CPUID_1_EDX] = cpuid_edx(0x00000001); diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c index 209b5a22d880..b500845d2049 100644 --- a/arch/x86/kernel/cpu/tsx.c +++ b/arch/x86/kernel/cpu/tsx.c @@ -35,7 +35,7 @@ static void tsx_disable(void) { u64 tsx; - rdmsrq(MSR_IA32_TSX_CTRL, tsx); + tsx = rdmsrq(MSR_IA32_TSX_CTRL); /* Force all transactions to immediately abort */ tsx |= TSX_CTRL_RTM_DISABLE; @@ -55,7 +55,7 @@ static void tsx_enable(void) { u64 tsx; - rdmsrq(MSR_IA32_TSX_CTRL, tsx); + tsx = rdmsrq(MSR_IA32_TSX_CTRL); /* Enable the RTM feature in the cpu */ tsx &= ~TSX_CTRL_RTM_DISABLE; @@ -126,11 +126,11 @@ static void tsx_clear_cpuid(void) */ if (boot_cpu_has(X86_FEATURE_RTM_ALWAYS_ABORT) && boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)) { - rdmsrq(MSR_TSX_FORCE_ABORT, msr); + msr = rdmsrq(MSR_TSX_FORCE_ABORT); msr |= MSR_TFA_TSX_CPUID_CLEAR; wrmsrq(MSR_TSX_FORCE_ABORT, msr); } else if (cpu_feature_enabled(X86_FEATURE_MSR_TSX_CTRL)) { - rdmsrq(MSR_IA32_TSX_CTRL, msr); + msr = rdmsrq(MSR_IA32_TSX_CTRL); msr |= TSX_CTRL_CPUID_CLEAR; wrmsrq(MSR_IA32_TSX_CTRL, msr); } @@ -157,7 +157,7 @@ static void tsx_dev_mode_disable(void) !cpu_feature_enabled(X86_FEATURE_SRBDS_CTRL)) return; - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_opt_ctrl); + mcu_opt_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); if (mcu_opt_ctrl & RTM_ALLOW) { mcu_opt_ctrl &= ~RTM_ALLOW; diff --git a/arch/x86/kernel/cpu/umwait.c b/arch/x86/kernel/cpu/umwait.c index e4a31c536642..8c3cf0f95e9a 100644 --- a/arch/x86/kernel/cpu/umwait.c +++ b/arch/x86/kernel/cpu/umwait.c @@ -218,7 +218,7 @@ static int __init umwait_init(void) * changed. This is the only place where orig_umwait_control_cached * is modified. */ - rdmsrq(MSR_IA32_UMWAIT_CONTROL, orig_umwait_control_cached); + orig_umwait_control_cached = rdmsrq(MSR_IA32_UMWAIT_CONTROL); ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "umwait:online", umwait_cpu_online, umwait_cpu_offline); diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c index fe504fd43c77..f89aec38a349 100644 --- a/arch/x86/kernel/cpu/zhaoxin.c +++ b/arch/x86/kernel/cpu/zhaoxin.c @@ -29,7 +29,7 @@ static void init_zhaoxin_cap(struct cpuinfo_x86 *c) /* Enable ACE unit, if present and disabled */ if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) { - rdmsrq(MSR_ZHAOXIN_FCR57, msr); + msr = rdmsrq(MSR_ZHAOXIN_FCR57); /* Enable ACE unit */ wrmsrq(MSR_ZHAOXIN_FCR57, msr | ACE_FCR); pr_info("CPU: Enabled ACE h/w crypto\n"); @@ -37,7 +37,7 @@ static void init_zhaoxin_cap(struct cpuinfo_x86 *c) /* Enable RNG unit, if present and disabled */ if ((tmp & (RNG_PRESENT | RNG_ENABLED)) == RNG_PRESENT) { - rdmsrq(MSR_ZHAOXIN_FCR57, msr); + msr = rdmsrq(MSR_ZHAOXIN_FCR57); /* Enable RNG unit */ wrmsrq(MSR_ZHAOXIN_FCR57, msr | RNG_ENABLE); pr_info("CPU: Enabled h/w RNG\n"); diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index d1aeecd57f5e..7d2cff9633cf 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -364,7 +364,7 @@ void fpu_sync_guest_vmexit_xfd_state(void) lockdep_assert_irqs_disabled(); if (fpu_state_size_dynamic()) { - rdmsrq(MSR_IA32_XFD, fpstate->xfd); + fpstate->xfd = rdmsrq(MSR_IA32_XFD); __this_cpu_write(xfd_state, fpstate->xfd); } } diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 8dc7b710e125..8a27b9ae9fc7 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -971,7 +971,7 @@ static bool __init hpet_is_pc10_damaged(void) return false; /* Check whether PC10 is enabled in PKG C-state limit */ - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, pcfg); + pcfg = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); if ((pcfg & 0xF) < 8) return false; diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 6b0a5861ccb8..8710e3fab693 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -740,7 +740,7 @@ static int kvm_suspend(void *data) #ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL)) - rdmsrq(MSR_KVM_POLL_CONTROL, val); + val = rdmsrq(MSR_KVM_POLL_CONTROL); has_guest_poll = !(val & 1); #endif return 0; diff --git a/arch/x86/kernel/mmconf-fam10h_64.c b/arch/x86/kernel/mmconf-fam10h_64.c index ef6104e7cc72..348ac8fce3ad 100644 --- a/arch/x86/kernel/mmconf-fam10h_64.c +++ b/arch/x86/kernel/mmconf-fam10h_64.c @@ -97,7 +97,7 @@ static void get_fam10h_pci_mmconf_base(void) /* SYS_CFG */ address = MSR_AMD64_SYSCFG; - rdmsrq(address, val); + val = rdmsrq(address); /* TOP_MEM2 is not enabled? */ if (!(val & (1<<21))) { @@ -105,7 +105,7 @@ static void get_fam10h_pci_mmconf_base(void) } else { /* TOP_MEM2 */ address = MSR_K8_TOP_MEM2; - rdmsrq(address, val); + val = rdmsrq(address); tom2 = max(val & 0xffffff800000ULL, 1ULL << 32); } @@ -177,7 +177,7 @@ void fam10h_check_enable_mmcfg(void) return; address = MSR_FAM10H_MMIO_CONF_BASE; - rdmsrq(address, val); + val = rdmsrq(address); /* try to make sure that AP's setting is identical to BSP setting */ if (val & FAM10H_MMIO_CONF_ENABLE) { diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 346c438ac880..85e6b076ef17 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -730,7 +730,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p) arch_has_block_step()) { unsigned long debugctl, msk; - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); debugctl &= ~DEBUGCTLMSR_BTF; msk = tifn & _TIF_BLOCKSTEP; debugctl |= (msk >> TIF_BLOCKSTEP) << DEBUGCTLMSR_BTF_SHIFT; @@ -980,7 +980,7 @@ void __init arch_post_acpi_subsys_init(void) * the machine is affected K8_INTP_C1E_ACTIVE_MASK bits are set in * MSR_K8_INT_PENDING_MSG. */ - rdmsrq(MSR_K8_INT_PENDING_MSG, val); + val = rdmsrq(MSR_K8_INT_PENDING_MSG); if (!(val & K8_INTP_C1E_ACTIVE_MASK)) return; diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 2bce7b3f97ed..28dbe7e629fc 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -97,8 +97,8 @@ void __show_regs(struct pt_regs *regs, enum show_regs_mode mode, return; if (mode == SHOW_REGS_USER) { - rdmsrq(MSR_FS_BASE, fs); - rdmsrq(MSR_KERNEL_GS_BASE, shadowgs); + fs = rdmsrq(MSR_FS_BASE); + shadowgs = rdmsrq(MSR_KERNEL_GS_BASE); printk("%sFS: %016lx GS: %016lx\n", log_lvl, fs, shadowgs); return; @@ -109,9 +109,9 @@ void __show_regs(struct pt_regs *regs, enum show_regs_mode mode, savesegment(fs, fsindex); savesegment(gs, gsindex); - rdmsrq(MSR_FS_BASE, fs); - rdmsrq(MSR_GS_BASE, gs); - rdmsrq(MSR_KERNEL_GS_BASE, shadowgs); + fs = rdmsrq(MSR_FS_BASE); + gs = rdmsrq(MSR_GS_BASE); + shadowgs = rdmsrq(MSR_KERNEL_GS_BASE); cr0 = read_cr0(); cr2 = read_cr2(); @@ -197,7 +197,7 @@ static noinstr unsigned long __rdgsbase_inactive(void) native_swapgs(); } else { instrumentation_begin(); - rdmsrq(MSR_KERNEL_GS_BASE, gsbase); + gsbase = rdmsrq(MSR_KERNEL_GS_BASE); instrumentation_end(); } @@ -463,7 +463,7 @@ unsigned long x86_gsbase_read_cpu_inactive(void) gsbase = __rdgsbase_inactive(); local_irq_restore(flags); } else { - rdmsrq(MSR_KERNEL_GS_BASE, gsbase); + gsbase = rdmsrq(MSR_KERNEL_GS_BASE); } return gsbase; diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c index 0ca64900192f..f3d1f385c626 100644 --- a/arch/x86/kernel/shstk.c +++ b/arch/x86/kernel/shstk.c @@ -231,7 +231,7 @@ static unsigned long get_user_shstk_addr(void) fpregs_lock_and_load(); - rdmsrq(MSR_IA32_PL3_SSP, ssp); + ssp = rdmsrq(MSR_IA32_PL3_SSP); fpregs_unlock(); @@ -248,7 +248,7 @@ int shstk_pop(u64 *val) fpregs_lock_and_load(); - rdmsrq(MSR_IA32_PL3_SSP, ssp); + ssp = rdmsrq(MSR_IA32_PL3_SSP); if (val && get_user(*val, (__user u64 *)ssp)) ret = -EFAULT; else @@ -268,7 +268,7 @@ int shstk_push(u64 val) fpregs_lock_and_load(); - rdmsrq(MSR_IA32_PL3_SSP, ssp); + ssp = rdmsrq(MSR_IA32_PL3_SSP); ssp -= SS_FRAME_SIZE; ret = write_user_shstk_64((__user void *)ssp, val); if (!ret) @@ -497,7 +497,7 @@ static int wrss_control(bool enable) return 0; fpregs_lock_and_load(); - rdmsrq(MSR_IA32_U_CET, msrval); + msrval = rdmsrq(MSR_IA32_U_CET); if (enable) { features_set(ARCH_SHSTK_WRSS); diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 30aa8369957e..9cd11dc7bb17 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -1250,7 +1250,7 @@ static noinstr void exc_debug_kernel(struct pt_regs *regs, unsigned long dr6) */ unsigned long debugctl; - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); debugctl |= DEBUGCTLMSR_BTF; wrmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); } @@ -1509,7 +1509,7 @@ static bool handle_xfd_event(struct pt_regs *regs) if (!IS_ENABLED(CONFIG_X86_64) || !cpu_feature_enabled(X86_FEATURE_XFD)) return false; - rdmsrq(MSR_IA32_XFD_ERR, xfd_err); + xfd_err = rdmsrq(MSR_IA32_XFD_ERR); if (!xfd_err) return false; diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index 723347e2cf7f..39baee2307c3 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -1088,7 +1088,7 @@ static void __init detect_art(void) if (art_base_clk.denominator < ART_MIN_DENOMINATOR) return; - rdmsrq(MSR_IA32_TSC_ADJUST, art_base_clk.offset); + art_base_clk.offset = rdmsrq(MSR_IA32_TSC_ADJUST); /* Make this sticky over multiple CPU init calls */ setup_force_cpu_cap(X86_FEATURE_ART); diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c index d74743c8d2a4..6a1d22e8b846 100644 --- a/arch/x86/kernel/tsc_msr.c +++ b/arch/x86/kernel/tsc_msr.c @@ -179,15 +179,15 @@ unsigned long cpu_khz_from_msr(void) freq_desc = (struct freq_desc *)id->driver_data; if (freq_desc->use_msr_plat) { - rdmsrq(MSR_PLATFORM_INFO, val.q); + val.q = rdmsrq(MSR_PLATFORM_INFO); ratio = (val.l >> 8) & 0xff; } else { - rdmsrq(MSR_IA32_PERF_STATUS, val.q); + val.q = rdmsrq(MSR_IA32_PERF_STATUS); ratio = (val.h >> 8) & 0x1f; } /* Get FSB FREQ ID */ - rdmsrq(MSR_FSB_FREQ, val.q); + val.q = rdmsrq(MSR_FSB_FREQ); index = val.l & freq_desc->mask; md = &freq_desc->muldiv[index]; diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c index ec3aa340d351..a21ea3c85f6f 100644 --- a/arch/x86/kernel/tsc_sync.c +++ b/arch/x86/kernel/tsc_sync.c @@ -66,7 +66,7 @@ void tsc_verify_tsc_adjust(bool resume) adj->nextcheck = jiffies + HZ; - rdmsrq(MSR_IA32_TSC_ADJUST, curval); + curval = rdmsrq(MSR_IA32_TSC_ADJUST); if (adj->adjusted == curval) return; @@ -166,7 +166,7 @@ bool __init tsc_store_and_check_tsc_adjust(bool bootcpu) if (check_tsc_unstable()) return false; - rdmsrq(MSR_IA32_TSC_ADJUST, bootval); + bootval = rdmsrq(MSR_IA32_TSC_ADJUST); cur->bootval = bootval; cur->nextcheck = jiffies + HZ; tsc_sanitize_first_cpu(cur, bootval, smp_processor_id(), bootcpu); @@ -188,7 +188,7 @@ bool tsc_store_and_check_tsc_adjust(bool bootcpu) if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST)) return false; - rdmsrq(MSR_IA32_TSC_ADJUST, bootval); + bootval = rdmsrq(MSR_IA32_TSC_ADJUST); cur->bootval = bootval; cur->nextcheck = jiffies + HZ; cur->warned = false; diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c index dd3bb04878ca..59c19c534564 100644 --- a/arch/x86/kvm/msrs.c +++ b/arch/x86/kvm/msrs.c @@ -1205,7 +1205,7 @@ static __always_inline void kvm_access_xstate_msr(struct kvm_vcpu *vcpu, kvm_fpu_get(); if (access == MSR_TYPE_R) - rdmsrq(msr_info->index, msr_info->data); + msr_info->data = rdmsrq(msr_info->index); else wrmsrq(msr_info->index, msr_info->data); kvm_fpu_put(); diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c index c18286545a7a..5ebee82dba84 100644 --- a/arch/x86/kvm/svm/pmu.c +++ b/arch/x86/kvm/svm/pmu.c @@ -249,7 +249,7 @@ static void amd_mediated_pmu_load(struct kvm_vcpu *vcpu) struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); u64 global_status; - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, global_status); + global_status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); /* Clear host global_status MSR if non-zero. */ if (global_status) wrmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS_CLR, global_status); @@ -263,7 +263,7 @@ static void amd_mediated_pmu_put(struct kvm_vcpu *vcpu) struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); wrmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL, 0); - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, pmu->global_status); + pmu->global_status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); /* Clear global status bits if non-zero */ if (pmu->global_status) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 7d59d301e1e5..91f5a5344529 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4637,7 +4637,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags) kvm_clear_available_registers(vcpu, SVM_REGS_LAZY_LOAD_SET); if (!msr_write_intercepted(svm, MSR_AMD64_PERF_CNTR_GLOBAL_CTL)) - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL, vcpu_to_pmu(vcpu)->global_ctrl); + vcpu_to_pmu(vcpu)->global_ctrl = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL); trace_kvm_exit(vcpu, KVM_ISA_SVM); @@ -5485,7 +5485,7 @@ static __init void svm_adjust_mmio_mask(void) return; /* If memory encryption is not enabled, use existing mask */ - rdmsrq(MSR_AMD64_SYSCFG, msr); + msr = rdmsrq(MSR_AMD64_SYSCFG); if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT)) return; diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 151873407abd..3f06d6742f0e 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -7358,8 +7358,8 @@ static void nested_vmx_setup_cr_fixed(struct nested_vmx_msrs *msrs) msrs->cr4_fixed0 = VMXON_CR4_ALWAYSON; /* These MSRs specify bits which the guest must keep fixed off. */ - rdmsrq(MSR_IA32_VMX_CR0_FIXED1, msrs->cr0_fixed1); - rdmsrq(MSR_IA32_VMX_CR4_FIXED1, msrs->cr4_fixed1); + msrs->cr0_fixed1 = rdmsrq(MSR_IA32_VMX_CR0_FIXED1); + msrs->cr4_fixed1 = rdmsrq(MSR_IA32_VMX_CR4_FIXED1); if (vmx_umip_emulated()) msrs->cr4_fixed1 |= X86_CR4_UMIP; diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c index bfa8612fb450..24cfbb8f5078 100644 --- a/arch/x86/kvm/vmx/pmu_intel.c +++ b/arch/x86/kvm/vmx/pmu_intel.c @@ -320,7 +320,7 @@ static bool intel_pmu_handle_lbr_msrs_access(struct kvm_vcpu *vcpu, int err = 0; if (read) - rdmsrq(index, msr_info->data); + msr_info->data = rdmsrq(index); else err = wrmsrq_safe(index, msr_info->data); __set_bit(INTEL_PMC_IDX_FIXED_VLBR, vcpu_to_pmu(vcpu)->pmc_in_use); @@ -772,7 +772,7 @@ static bool intel_pmu_is_mediated_pmu_supported(struct x86_pmu_capability *host_ u64 host_perf_cap = 0; if (boot_cpu_has(X86_FEATURE_PDCM)) - rdmsrq(MSR_IA32_PERF_CAPABILITIES, host_perf_cap); + host_perf_cap = rdmsrq(MSR_IA32_PERF_CAPABILITIES); /* * Require v4+ for MSR_CORE_PERF_GLOBAL_STATUS_SET, and full-width @@ -801,7 +801,7 @@ static void intel_mediated_pmu_load(struct kvm_vcpu *vcpu) struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); u64 global_status, toggle; - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, global_status); + global_status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); toggle = pmu->global_status ^ global_status; if (global_status & toggle) wrmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, global_status & toggle); @@ -816,7 +816,7 @@ static void intel_mediated_pmu_put(struct kvm_vcpu *vcpu) struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); /* MSR_CORE_PERF_GLOBAL_CTRL is already saved at VM-exit. */ - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, pmu->global_status); + pmu->global_status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); /* Clear hardware MSR_CORE_PERF_GLOBAL_STATUS MSR, if non-zero. */ if (pmu->global_status) diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c index 771c75a58343..765cac151023 100644 --- a/arch/x86/kvm/vmx/sgx.c +++ b/arch/x86/kvm/vmx/sgx.c @@ -420,9 +420,9 @@ void setup_default_sgx_lepubkeyhash(void) sgx_pubkey_hash[3] = 0xd4f8c05909f9bb3bULL; } else { /* MSR_IA32_SGXLEPUBKEYHASH0 is read above */ - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH1, sgx_pubkey_hash[1]); - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH2, sgx_pubkey_hash[2]); - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH3, sgx_pubkey_hash[3]); + sgx_pubkey_hash[1] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH1); + sgx_pubkey_hash[2] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH2); + sgx_pubkey_hash[3] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH3); } } diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 612ab07d4100..2c8487bbda6a 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -1261,13 +1261,13 @@ static inline void pt_save_msr(struct pt_ctx *ctx, u32 addr_range) { u32 i; - rdmsrq(MSR_IA32_RTIT_STATUS, ctx->status); - rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE, ctx->output_base); - rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK, ctx->output_mask); - rdmsrq(MSR_IA32_RTIT_CR3_MATCH, ctx->cr3_match); + ctx->status = rdmsrq(MSR_IA32_RTIT_STATUS); + ctx->output_base = rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE); + ctx->output_mask = rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK); + ctx->cr3_match = rdmsrq(MSR_IA32_RTIT_CR3_MATCH); for (i = 0; i < addr_range; i++) { - rdmsrq(MSR_IA32_RTIT_ADDR0_A + i * 2, ctx->addr_a[i]); - rdmsrq(MSR_IA32_RTIT_ADDR0_B + i * 2, ctx->addr_b[i]); + ctx->addr_a[i] = rdmsrq(MSR_IA32_RTIT_ADDR0_A + i * 2); + ctx->addr_b[i] = rdmsrq(MSR_IA32_RTIT_ADDR0_B + i * 2); } } @@ -1280,7 +1280,7 @@ static void pt_guest_enter(struct vcpu_vmx *vmx) * GUEST_IA32_RTIT_CTL is already set in the VMCS. * Save host state before VM entry. */ - rdmsrq(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl); + vmx->pt_desc.host.ctl = rdmsrq(MSR_IA32_RTIT_CTL); if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) { wrmsrq(MSR_IA32_RTIT_CTL, 0); pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.num_address_ranges); @@ -1418,7 +1418,7 @@ static void vmx_prepare_switch_to_host(struct vcpu_vmx *vmx) ++vmx->vcpu.stat.host_state_reload; #ifdef CONFIG_X86_64 - rdmsrq(MSR_KERNEL_GS_BASE, vmx->msr_guest_kernel_gs_base); + vmx->msr_guest_kernel_gs_base = rdmsrq(MSR_KERNEL_GS_BASE); #endif if (host_state->ldt_sel || (host_state->gs_sel & 7)) { vmx_load_ldt(host_state->ldt_sel); @@ -2694,7 +2694,7 @@ static int adjust_vmx_controls(u32 ctl_min, u32 ctl_opt, u32 msr, u32 *result) struct msr vmx_msr; u32 ctl = ctl_min | ctl_opt; - rdmsrq(msr, vmx_msr.q); + vmx_msr.q = rdmsrq(msr); ctl &= vmx_msr.h; /* bit == 0 in high word ==> must be zero */ ctl |= vmx_msr.l; /* bit == 1 in low word ==> must be one */ @@ -2711,7 +2711,7 @@ static u64 adjust_vmx_controls64(u64 ctl_opt, u32 msr) { u64 allowed; - rdmsrq(msr, allowed); + allowed = rdmsrq(msr); return ctl_opt & allowed; } @@ -2897,7 +2897,7 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf, break; } - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); + basic_msr = rdmsrq(MSR_IA32_VMX_BASIC); /* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */ if (vmx_basic_vmcs_size(basic_msr) > PAGE_SIZE) @@ -2917,7 +2917,7 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf, if (vmx_basic_vmcs_mem_type(basic_msr) != X86_MEMTYPE_WB) return -EIO; - rdmsrq(MSR_IA32_VMX_MISC, misc_msr); + misc_msr = rdmsrq(MSR_IA32_VMX_MISC); vmcs_conf->basic = basic_msr; vmcs_conf->pin_based_exec_ctrl = _pin_based_exec_control; @@ -4494,7 +4494,7 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx) vmcs_writel(HOST_RIP, (unsigned long)vmx_vmexit); /* 22.2.5 */ - rdmsrq(MSR_IA32_SYSENTER_CS, val.q); + val.q = rdmsrq(MSR_IA32_SYSENTER_CS); vmcs_write32(HOST_IA32_SYSENTER_CS, val.l); /* @@ -4506,11 +4506,11 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx) if (!IS_ENABLED(CONFIG_IA32_EMULATION) && !IS_ENABLED(CONFIG_X86_32)) vmcs_writel(HOST_IA32_SYSENTER_ESP, 0); - rdmsrq(MSR_IA32_SYSENTER_EIP, tmpl); + tmpl = rdmsrq(MSR_IA32_SYSENTER_EIP); vmcs_writel(HOST_IA32_SYSENTER_EIP, tmpl); /* 22.2.3 */ if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_PAT) { - rdmsrq(MSR_IA32_CR_PAT, val.q); + val.q = rdmsrq(MSR_IA32_CR_PAT); vmcs_write64(HOST_IA32_PAT, val.q); } @@ -7161,7 +7161,7 @@ static void handle_nm_fault_irqoff(struct kvm_vcpu *vcpu) * the #NM exception. */ if (is_xfd_nm_fault(vcpu)) - rdmsrq(MSR_IA32_XFD_ERR, vcpu->arch.guest_fpu.xfd_err); + vcpu->arch.guest_fpu.xfd_err = rdmsrq(MSR_IA32_XFD_ERR); } static void handle_exception_irqoff(struct kvm_vcpu *vcpu, u32 intr_info) @@ -8031,7 +8031,7 @@ static __init u64 vmx_get_perf_capabilities(void) return 0; if (boot_cpu_has(X86_FEATURE_PDCM)) - rdmsrq(MSR_IA32_PERF_CAPABILITIES, host_perf_cap); + host_perf_cap = rdmsrq(MSR_IA32_PERF_CAPABILITIES); if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR) && !enable_mediated_pmu) { @@ -8680,7 +8680,7 @@ __init int vmx_hardware_setup(void) vmx_setup_user_return_msrs(); if (boot_cpu_has(X86_FEATURE_MPX)) { - rdmsrq(MSR_IA32_BNDCFGS, host_bndcfgs); + host_bndcfgs = rdmsrq(MSR_IA32_BNDCFGS); WARN_ONCE(host_bndcfgs, "BNDCFGS in host will be lost"); } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 79468ddfe473..6bbeb9b6e4b9 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7037,7 +7037,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) } if (boot_cpu_has(X86_FEATURE_SHSTK) || boot_cpu_has(X86_FEATURE_IBT)) { - rdmsrq(MSR_IA32_S_CET, kvm_host.s_cet); + kvm_host.s_cet = rdmsrq(MSR_IA32_S_CET); /* * Linux doesn't yet support supervisor shadow stacks (SSS), so * KVM doesn't save/restore the associated MSRs, i.e. KVM may @@ -7069,7 +7069,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) } if (boot_cpu_has(X86_FEATURE_XSAVES)) { - rdmsrq(MSR_IA32_XSS, kvm_host.xss); + kvm_host.xss = rdmsrq(MSR_IA32_XSS); kvm_caps.supported_xss = kvm_host.xss & KVM_SUPPORTED_XSS; } @@ -7081,7 +7081,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) kvm_init_pmu_capability(ops->pmu_ops); if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) - rdmsrq(MSR_IA32_ARCH_CAPABILITIES, kvm_host.arch_capabilities); + kvm_host.arch_capabilities = rdmsrq(MSR_IA32_ARCH_CAPABILITIES); WARN_ON_ONCE(kvm_nr_uret_msrs); diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c index e03eeec55cfe..b9db2012a75e 100644 --- a/arch/x86/lib/insn-eval.c +++ b/arch/x86/lib/insn-eval.c @@ -709,16 +709,16 @@ unsigned long insn_get_seg_base(struct pt_regs *regs, int seg_reg_idx) unsigned long base; if (seg_reg_idx == INAT_SEG_REG_FS) { - rdmsrq(MSR_FS_BASE, base); + base = rdmsrq(MSR_FS_BASE); } else if (seg_reg_idx == INAT_SEG_REG_GS) { /* * swapgs was called at the kernel entry point. Thus, * MSR_KERNEL_GS_BASE will have the user-space GS base. */ if (user_mode(regs)) - rdmsrq(MSR_KERNEL_GS_BASE, base); + base = rdmsrq(MSR_KERNEL_GS_BASE); else - rdmsrq(MSR_GS_BASE, base); + base = rdmsrq(MSR_GS_BASE); } else { base = 0; } diff --git a/arch/x86/lib/msr-smp.c b/arch/x86/lib/msr-smp.c index 7b6cfc2c0970..ddff68050322 100644 --- a/arch/x86/lib/msr-smp.c +++ b/arch/x86/lib/msr-smp.c @@ -15,7 +15,7 @@ static void __rdmsr_on_cpu(void *info) else reg = &rv->reg; - rdmsrq(rv->msr_no, reg->q); + reg->q = rdmsrq(rv->msr_no); } static void __wrmsr_on_cpu(void *info) diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c index cf94fb561310..114853c212ed 100644 --- a/arch/x86/mm/pat/memtype.c +++ b/arch/x86/mm/pat/memtype.c @@ -257,7 +257,7 @@ void __init pat_bp_init(void) if (!cpu_feature_enabled(X86_FEATURE_PAT)) pat_disable("PAT not supported by the CPU."); else - rdmsrq(MSR_IA32_CR_PAT, pat_msr_val); + pat_msr_val = rdmsrq(MSR_IA32_CR_PAT); if (!pat_msr_val) { pat_disable("PAT support disabled by the firmware."); diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c index 99b1727136c1..342371081f60 100644 --- a/arch/x86/pci/amd_bus.c +++ b/arch/x86/pci/amd_bus.c @@ -202,7 +202,7 @@ static int __init early_root_info_init(void) /* need to take out [0, TOM) for RAM*/ address = MSR_K8_TOP_MEM1; - rdmsrq(address, val); + val = rdmsrq(address); end = (val & 0xffffff800000ULL); printk(KERN_INFO "TOM: %016llx aka %lldM\n", end, end>>20); if (end < (1ULL<<32)) @@ -293,12 +293,12 @@ static int __init early_root_info_init(void) /* need to take out [4G, TOM2) for RAM*/ /* SYS_CFG */ address = MSR_AMD64_SYSCFG; - rdmsrq(address, val); + val = rdmsrq(address); /* TOP_MEM2 is enabled? */ if (val & (1<<21)) { /* TOP_MEM2 */ address = MSR_K8_TOP_MEM2; - rdmsrq(address, val); + val = rdmsrq(address); end = (val & 0xffffff800000ULL); printk(KERN_INFO "TOM2: %016llx aka %lldM\n", end, end>>20); subtract_range(range, RANGE_NUM, 1ULL<<32, end); @@ -341,7 +341,7 @@ static int amd_bus_cpu_online(unsigned int cpu) { u64 reg; - rdmsrq(MSR_AMD64_NB_CFG, reg); + reg = rdmsrq(MSR_AMD64_NB_CFG); if (!(reg & ENABLE_CF8_EXT_CFG)) { reg |= ENABLE_CF8_EXT_CFG; wrmsrq(MSR_AMD64_NB_CFG, reg); diff --git a/arch/x86/platform/olpc/olpc-xo1-rtc.c b/arch/x86/platform/olpc/olpc-xo1-rtc.c index ee77d57bcab7..95dfd90b1f05 100644 --- a/arch/x86/platform/olpc/olpc-xo1-rtc.c +++ b/arch/x86/platform/olpc/olpc-xo1-rtc.c @@ -64,9 +64,9 @@ static int __init xo1_rtc_init(void) of_node_put(node); pr_info("olpc-xo1-rtc: Initializing OLPC XO-1 RTC\n"); - rdmsrq(MSR_RTC_DOMA_OFFSET, rtc_info.rtc_day_alarm); - rdmsrq(MSR_RTC_MONA_OFFSET, rtc_info.rtc_mon_alarm); - rdmsrq(MSR_RTC_CEN_OFFSET, rtc_info.rtc_century); + rtc_info.rtc_day_alarm = rdmsrq(MSR_RTC_DOMA_OFFSET); + rtc_info.rtc_mon_alarm = rdmsrq(MSR_RTC_MONA_OFFSET); + rtc_info.rtc_century = rdmsrq(MSR_RTC_CEN_OFFSET); r = platform_device_register(&xo1_rtc_device); if (r) diff --git a/arch/x86/platform/olpc/olpc-xo1-sci.c b/arch/x86/platform/olpc/olpc-xo1-sci.c index 8b5b3626b559..d2b63a7c0fe6 100644 --- a/arch/x86/platform/olpc/olpc-xo1-sci.c +++ b/arch/x86/platform/olpc/olpc-xo1-sci.c @@ -316,7 +316,7 @@ static int setup_sci_interrupt(struct platform_device *pdev) u32 sts; int r; - rdmsrq(0x51400020, msr); + msr = rdmsrq(0x51400020); sci_irq = (msr >> 20) & 15; if (sci_irq) { diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c index 702f30eaf9c4..f44ebe2fe099 100644 --- a/arch/x86/power/cpu.c +++ b/arch/x86/power/cpu.c @@ -45,7 +45,7 @@ static void msr_save_context(struct saved_context *ctxt) while (msr < end) { if (msr->valid) - rdmsrq(msr->info.msr_no, msr->info.reg.q); + msr->info.reg.q = rdmsrq(msr->info.msr_no); msr++; } } @@ -111,12 +111,12 @@ static void __save_processor_state(struct saved_context *ctxt) savesegment(ds, ctxt->ds); savesegment(es, ctxt->es); - rdmsrq(MSR_FS_BASE, ctxt->fs_base); - rdmsrq(MSR_GS_BASE, ctxt->kernelmode_gs_base); - rdmsrq(MSR_KERNEL_GS_BASE, ctxt->usermode_gs_base); + ctxt->fs_base = rdmsrq(MSR_FS_BASE); + ctxt->kernelmode_gs_base = rdmsrq(MSR_GS_BASE); + ctxt->usermode_gs_base = rdmsrq(MSR_KERNEL_GS_BASE); mtrr_save_fixed_ranges(NULL); - rdmsrq(MSR_EFER, ctxt->efer); + ctxt->efer = rdmsrq(MSR_EFER); #endif /* diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c index 694d80a5c68e..469f2aa8e105 100644 --- a/arch/x86/realmode/init.c +++ b/arch/x86/realmode/init.c @@ -147,7 +147,7 @@ static void __init setup_real_mode(void) * Some AMD processors will #GP(0) if EFER.LMA is set in WRMSR * so we need to mask it out. */ - rdmsrq(MSR_EFER, efer); + efer = rdmsrq(MSR_EFER); trampoline_header->efer = efer & ~EFER_LMA; trampoline_header->start = (u64) secondary_startup_64; diff --git a/arch/x86/virt/hw.c b/arch/x86/virt/hw.c index a236447ac7a2..a0f5ecb5b946 100644 --- a/arch/x86/virt/hw.c +++ b/arch/x86/virt/hw.c @@ -178,7 +178,7 @@ static __init int __x86_vmx_init(void) if (!cpu_feature_enabled(X86_FEATURE_VMX)) return -EOPNOTSUPP; - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); + basic_msr = rdmsrq(MSR_IA32_VMX_BASIC); /* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */ if (WARN_ON_ONCE(vmx_basic_vmcs_size(basic_msr) > PAGE_SIZE)) @@ -230,7 +230,7 @@ static int x86_svm_enable_virtualization_cpu(void) { u64 efer; - rdmsrq(MSR_EFER, efer); + efer = rdmsrq(MSR_EFER); if (efer & EFER_SVME) return -EBUSY; @@ -253,7 +253,7 @@ static int x86_svm_disable_virtualization_cpu(void) r = 0; fault: - rdmsrq(MSR_EFER, efer); + efer = rdmsrq(MSR_EFER); wrmsrq(MSR_EFER, efer & ~EFER_SVME); return r; } @@ -264,7 +264,7 @@ static void x86_svm_emergency_disable_virtualization_cpu(void) virt_rebooting = true; - rdmsrq(MSR_EFER, efer); + efer = rdmsrq(MSR_EFER); if (!(efer & EFER_SVME)) return; diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c index cff285d8ad8e..4a1e75d66e6c 100644 --- a/arch/x86/virt/svm/sev.c +++ b/arch/x86/virt/svm/sev.c @@ -150,7 +150,7 @@ static void snp_enable(void *arg) if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP)) return; - rdmsrq(MSR_AMD64_SYSCFG, val); + val = rdmsrq(MSR_AMD64_SYSCFG); val |= MSR_AMD64_SYSCFG_SNP_EN; val |= MSR_AMD64_SYSCFG_SNP_VMPL_EN; @@ -254,7 +254,7 @@ static void clear_rmp(void) return; /* Clearing the RMP while SNP is enabled will cause an exception */ - rdmsrq(MSR_AMD64_SYSCFG, val); + val = rdmsrq(MSR_AMD64_SYSCFG); if (WARN_ON_ONCE(val & MSR_AMD64_SYSCFG_SNP_EN)) return; @@ -520,7 +520,7 @@ int snp_prepare(void) * Check if SEV-SNP is already enabled, this can happen in case of * kexec boot. */ - rdmsrq(MSR_AMD64_SYSCFG, val); + val = rdmsrq(MSR_AMD64_SYSCFG); if (val & MSR_AMD64_SYSCFG_SNP_EN) return 0; @@ -561,7 +561,7 @@ void snp_shutdown(void) { u64 syscfg; - rdmsrq(MSR_AMD64_SYSCFG, syscfg); + syscfg = rdmsrq(MSR_AMD64_SYSCFG); if (syscfg & MSR_AMD64_SYSCFG_SNP_EN) return; @@ -608,8 +608,8 @@ static bool probe_contiguous_rmptable_info(void) { u64 rmp_sz, rmp_base, rmp_end; - rdmsrq(MSR_AMD64_RMP_BASE, rmp_base); - rdmsrq(MSR_AMD64_RMP_END, rmp_end); + rmp_base = rdmsrq(MSR_AMD64_RMP_BASE); + rmp_end = rdmsrq(MSR_AMD64_RMP_END); if (!(rmp_base & RMP_ADDR_MASK) || !(rmp_end & RMP_ADDR_MASK)) { pr_err("Memory for the RMP table has not been reserved by BIOS\n"); @@ -642,13 +642,13 @@ static bool probe_segmented_rmptable_info(void) unsigned int eax, ebx, segment_shift, segment_shift_min, segment_shift_max; u64 rmp_base, rmp_end; - rdmsrq(MSR_AMD64_RMP_BASE, rmp_base); + rmp_base = rdmsrq(MSR_AMD64_RMP_BASE); if (!(rmp_base & RMP_ADDR_MASK)) { pr_err("Memory for the RMP table has not been reserved by BIOS\n"); return false; } - rdmsrq(MSR_AMD64_RMP_END, rmp_end); + rmp_end = rdmsrq(MSR_AMD64_RMP_END); WARN_ONCE(rmp_end & RMP_ADDR_MASK, "Segmented RMP enabled but RMP_END MSR is non-zero\n"); @@ -684,7 +684,7 @@ static bool probe_segmented_rmptable_info(void) bool snp_probe_rmptable_info(void) { if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) - rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg); + rmp_cfg = rdmsrq(MSR_AMD64_RMP_CFG); if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) return probe_segmented_rmptable_info(); diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 1b9ff749dd8e..9839f5b8dcc3 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -1523,7 +1523,7 @@ static void __init check_tdx_erratum(void) * Some TDX-capable CPUs have an erratum where the current VMCS is * cleared after calling into P-SEAMLDR. */ - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); + basic_msr = rdmsrq(MSR_IA32_VMX_BASIC); if (!(basic_msr & VMX_BASIC_NO_SEAMRET_INVD_VMCS)) setup_force_cpu_bug(X86_BUG_SEAMRET_INVD_VMCS); } diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c index ba2f17e64321..b0e1152aa80e 100644 --- a/arch/x86/xen/suspend.c +++ b/arch/x86/xen/suspend.c @@ -56,7 +56,7 @@ static void xen_vcpu_notify_suspend(void *data) tick_suspend_local(); if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { - rdmsrq(MSR_IA32_SPEC_CTRL, tmp); + tmp = rdmsrq(MSR_IA32_SPEC_CTRL); this_cpu_write(spec_ctrl, tmp); wrmsrq(MSR_IA32_SPEC_CTRL, 0); } diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c index 9e25d6124efd..535a0f9dd2cf 100644 --- a/drivers/acpi/processor_perflib.c +++ b/drivers/acpi/processor_perflib.c @@ -296,7 +296,7 @@ static void amd_fixup_frequency(struct acpi_processor_px *px, int i) if ((boot_cpu_data.x86 == 0x10 && boot_cpu_data.x86_model < 10) || boot_cpu_data.x86 == 0x11) { - rdmsrq(MSR_AMD_PSTATE_DEF_BASE + index, val.q); + val.q = rdmsrq(MSR_AMD_PSTATE_DEF_BASE + index); /* * MSR C001_0064+: * Bit 63: PstateEn. Read-write. If set, the P-state is valid. diff --git a/drivers/ata/pata_cs5535.c b/drivers/ata/pata_cs5535.c index 512f9728224f..5ca17faa8e6e 100644 --- a/drivers/ata/pata_cs5535.c +++ b/drivers/ata/pata_cs5535.c @@ -110,7 +110,7 @@ static void cs5535_set_piomode(struct ata_port *ap, struct ata_device *adev) pio_cmd_timings[cmdmode] | pio_timings[mode]); /* Set the PIO "format 1" bit in the DMA timing register */ - rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg); + reg = rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno); wrmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg | 0x80000000UL); } @@ -132,7 +132,7 @@ static void cs5535_set_dmamode(struct ata_port *ap, struct ata_device *adev) u32 reg; int mode = adev->dma_mode; - rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg); + reg = rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno); reg &= 0x80000000UL; if (mode >= XFER_UDMA_0) reg |= udma_timings[mode - XFER_UDMA_0]; diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c index 61d232a82b5e..eca97dce1e85 100644 --- a/drivers/ata/pata_cs5536.c +++ b/drivers/ata/pata_cs5536.c @@ -84,7 +84,7 @@ static int cs5536_read(struct pci_dev *pdev, int reg, u32 *val) { #ifdef MAYBE_USE_MSR if (unlikely(use_msr)) { - rdmsrq(MSR_IDE_CFG + reg, *val); + *val = rdmsrq(MSR_IDE_CFG + reg); return 0; } #endif diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.c index 3e760bc00afa..f646f1854981 100644 --- a/drivers/char/agp/nvidia-agp.c +++ b/drivers/char/agp/nvidia-agp.c @@ -72,8 +72,8 @@ static int nvidia_init_iorr(u32 base, u32 size) /* If not found, determine the uppermost available iorr */ free_iorr_addr = AMD_K7_NUM_IORR; for (iorr_addr = 0; iorr_addr < AMD_K7_NUM_IORR; iorr_addr++) { - rdmsrq(IORR_BASE0 + 2 * iorr_addr, base_msr.q); - rdmsrq(IORR_MASK0 + 2 * iorr_addr, mask_msr.q); + base_msr.q = rdmsrq(IORR_BASE0 + 2 * iorr_addr); + mask_msr.q = rdmsrq(IORR_MASK0 + 2 * iorr_addr); if ((base_msr.l & 0xfffff000) == (base & 0xfffff000)) break; @@ -94,7 +94,7 @@ static int nvidia_init_iorr(u32 base, u32 size) wrmsrq(IORR_BASE0 + 2 * iorr_addr, base_msr.q); wrmsrq(IORR_MASK0 + 2 * iorr_addr, mask_msr.q); - rdmsrq(SYSCFG, sys_msr.q); + sys_msr.q = rdmsrq(SYSCFG); sys_msr.l |= 0x00100000; wrmsrq(SYSCFG, sys_msr.q); diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c index b718e78d3c1c..a0a3488a6947 100644 --- a/drivers/char/hw_random/via-rng.c +++ b/drivers/char/hw_random/via-rng.c @@ -151,7 +151,7 @@ static int via_rng_init(struct hwrng *rng) * does not say to write them as zero, so I make a guess that * we restore the values we find in the register. */ - rdmsrq(MSR_VIA_RNG, val.q); + val.q = rdmsrq(MSR_VIA_RNG); old_lo = val.l; val.l &= ~(0x7f << VIA_STRFILT_CNT_SHIFT); @@ -175,7 +175,7 @@ static int via_rng_init(struct hwrng *rng) /* perhaps-unnecessary sanity check; remove after testing if unneeded */ - rdmsrq(MSR_VIA_RNG, val.q); + val.q = rdmsrq(MSR_VIA_RNG); if ((val.l & VIA_RNG_ENABLE) == 0) { pr_err(PFX "cannot enable VIA C3 RNG, aborting\n"); return -ENODEV; diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 10ea6035f4ad..e1ee80ecd0bb 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -110,7 +110,7 @@ static int boost_set_msr(bool enable) return -EINVAL; } - rdmsrq(msr_addr, val); + val = rdmsrq(msr_addr); if (enable) val &= ~msr_mask; @@ -248,7 +248,7 @@ static u32 cpu_freq_read_intel(struct acpi_pct_register *not_used) { u64 val; - rdmsrq(MSR_IA32_PERF_CTL, val); + val = rdmsrq(MSR_IA32_PERF_CTL); return (u32)val; } @@ -256,7 +256,7 @@ static void cpu_freq_write_intel(struct acpi_pct_register *not_used, u32 val) { u64 msrval; - rdmsrq(MSR_IA32_PERF_CTL, msrval); + msrval = rdmsrq(MSR_IA32_PERF_CTL); msrval = (msrval & ~(u64)INTEL_MSR_RANGE) | (val & INTEL_MSR_RANGE); wrmsrq(MSR_IA32_PERF_CTL, msrval); } @@ -265,7 +265,7 @@ static u32 cpu_freq_read_amd(struct acpi_pct_register *not_used) { u64 val; - rdmsrq(MSR_AMD_PERF_CTL, val); + val = rdmsrq(MSR_AMD_PERF_CTL); return (u32)val; } diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c index 8bfd46d60843..53838c7470c7 100644 --- a/drivers/cpufreq/amd-pstate.c +++ b/drivers/cpufreq/amd-pstate.c @@ -596,8 +596,8 @@ static inline bool amd_pstate_sample(struct amd_cpudata *cpudata) unsigned long flags; local_irq_save(flags); - rdmsrq(MSR_IA32_APERF, aperf); - rdmsrq(MSR_IA32_MPERF, mperf); + aperf = rdmsrq(MSR_IA32_APERF); + mperf = rdmsrq(MSR_IA32_MPERF); tsc = rdtsc(); if (cpudata->prev.mperf == mperf || cpudata->prev.tsc == tsc) { diff --git a/drivers/cpufreq/e_powersaver.c b/drivers/cpufreq/e_powersaver.c index 54689ebadeb2..cc05494ac316 100644 --- a/drivers/cpufreq/e_powersaver.c +++ b/drivers/cpufreq/e_powersaver.c @@ -99,7 +99,7 @@ static unsigned int eps_get(unsigned int cpu) return 0; /* Return current frequency */ - rdmsrq(MSR_IA32_PERF_STATUS, val); + val = rdmsrq(MSR_IA32_PERF_STATUS); return centaur->fsb * ((val >> 8) & 0xff); } @@ -111,11 +111,11 @@ static int eps_set_state(struct eps_cpu_data *centaur, int i; /* Wait while CPU is busy */ - rdmsrq(MSR_IA32_PERF_STATUS, val); + val = rdmsrq(MSR_IA32_PERF_STATUS); i = 0; while (val & ((1 << 16) | (1 << 17))) { udelay(16); - rdmsrq(MSR_IA32_PERF_STATUS, val); + val = rdmsrq(MSR_IA32_PERF_STATUS); i++; if (unlikely(i > 64)) { return -ENODEV; @@ -127,7 +127,7 @@ static int eps_set_state(struct eps_cpu_data *centaur, i = 0; do { udelay(16); - rdmsrq(MSR_IA32_PERF_STATUS, val); + val = rdmsrq(MSR_IA32_PERF_STATUS); i++; if (unlikely(i > 64)) { return -ENODEV; @@ -139,7 +139,7 @@ static int eps_set_state(struct eps_cpu_data *centaur, u8 current_multiplier, current_voltage; /* Print voltage and multiplier */ - rdmsrq(MSR_IA32_PERF_STATUS, val); + val = rdmsrq(MSR_IA32_PERF_STATUS); current_voltage = val & 0xff; pr_info("Current voltage = %dmV\n", current_voltage * 16 + 700); current_multiplier = (val >> 8) & 0xff; @@ -194,12 +194,12 @@ static int eps_cpu_init(struct cpufreq_policy *policy) switch (c->x86_model) { case 10: - rdmsrq(0x1153, val); + val = rdmsrq(0x1153); brand = (((val >> 2) ^ val) >> 18) & 3; pr_cont("Model A "); break; case 13: - rdmsrq(0x1154, val); + val = rdmsrq(0x1154); brand = (((val >> 4) ^ (val >> 2))) & 0x000000ff; pr_cont("Model D "); break; @@ -223,12 +223,12 @@ static int eps_cpu_init(struct cpufreq_policy *policy) return -ENODEV; } /* Enable Enhanced PowerSaver */ - rdmsrq(MSR_IA32_MISC_ENABLE, val); + val = rdmsrq(MSR_IA32_MISC_ENABLE); if (!(val & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { val |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP; wrmsrq(MSR_IA32_MISC_ENABLE, val); /* Can be locked at 0 */ - rdmsrq(MSR_IA32_MISC_ENABLE, val); + val = rdmsrq(MSR_IA32_MISC_ENABLE); if (!(val & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { pr_info("Can't enable Enhanced PowerSaver\n"); return -ENODEV; @@ -236,7 +236,7 @@ static int eps_cpu_init(struct cpufreq_policy *policy) } /* Print voltage and multiplier */ - rdmsrq(MSR_IA32_PERF_STATUS, val); + val = rdmsrq(MSR_IA32_PERF_STATUS); current_voltage = val & 0xff; pr_info("Current voltage = %dmV\n", current_voltage * 16 + 700); current_multiplier = (val >> 8) & 0xff; diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index ceb340f7a110..1a0eb8c359c0 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -560,7 +560,7 @@ static bool turbo_is_disabled(void) { u64 misc_en; - rdmsrq(MSR_IA32_MISC_ENABLE, misc_en); + misc_en = rdmsrq(MSR_IA32_MISC_ENABLE); return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE); } @@ -1351,7 +1351,7 @@ static void set_power_ctl_ee_state(bool input) guard(mutex)(&intel_pstate_driver_lock); - rdmsrq(MSR_IA32_POWER_CTL, power_ctl); + power_ctl = rdmsrq(MSR_IA32_POWER_CTL); if (input) { power_ctl &= ~BIT(MSR_IA32_POWER_CTL_BIT_EE); power_ctl_ee_state = POWER_CTL_EE_ENABLE; @@ -1728,7 +1728,7 @@ static ssize_t show_energy_efficiency(struct kobject *kobj, struct kobj_attribut u64 power_ctl; int enable; - rdmsrq(MSR_IA32_POWER_CTL, power_ctl); + power_ctl = rdmsrq(MSR_IA32_POWER_CTL); enable = !!(power_ctl & BIT(MSR_IA32_POWER_CTL_BIT_EE)); return sprintf(buf, "%d\n", !enable); } @@ -2022,7 +2022,7 @@ static int atom_get_min_pstate(int not_used) { u64 value; - rdmsrq(MSR_ATOM_CORE_RATIOS, value); + value = rdmsrq(MSR_ATOM_CORE_RATIOS); return (value >> 8) & 0x7F; } @@ -2030,7 +2030,7 @@ static int atom_get_max_pstate(int not_used) { u64 value; - rdmsrq(MSR_ATOM_CORE_RATIOS, value); + value = rdmsrq(MSR_ATOM_CORE_RATIOS); return (value >> 16) & 0x7F; } @@ -2038,7 +2038,7 @@ static int atom_get_turbo_pstate(int not_used) { u64 value; - rdmsrq(MSR_ATOM_CORE_TURBO_RATIOS, value); + value = rdmsrq(MSR_ATOM_CORE_TURBO_RATIOS); return value & 0x7F; } @@ -2069,7 +2069,7 @@ static int silvermont_get_scaling(void) static int silvermont_freq_table[] = { 83300, 100000, 133300, 116700, 80000}; - rdmsrq(MSR_FSB_FREQ, value); + value = rdmsrq(MSR_FSB_FREQ); i = value & 0x7; WARN_ON(i > 4); @@ -2085,7 +2085,7 @@ static int airmont_get_scaling(void) 83300, 100000, 133300, 116700, 80000, 93300, 90000, 88900, 87500}; - rdmsrq(MSR_FSB_FREQ, value); + value = rdmsrq(MSR_FSB_FREQ); i = value & 0xF; WARN_ON(i > 8); @@ -2096,7 +2096,7 @@ static void atom_get_vid(struct cpudata *cpudata) { u64 value; - rdmsrq(MSR_ATOM_CORE_VIDS, value); + value = rdmsrq(MSR_ATOM_CORE_VIDS); cpudata->vid.min = int_tofp((value >> 8) & 0x7f); cpudata->vid.max = int_tofp((value >> 16) & 0x7f); cpudata->vid.ratio = div_fp( @@ -2104,7 +2104,7 @@ static void atom_get_vid(struct cpudata *cpudata) int_tofp(cpudata->pstate.max_pstate - cpudata->pstate.min_pstate)); - rdmsrq(MSR_ATOM_CORE_TURBO_VIDS, value); + value = rdmsrq(MSR_ATOM_CORE_TURBO_VIDS); cpudata->vid.turbo = value & 0x7f; } @@ -2452,8 +2452,8 @@ static inline bool intel_pstate_sample(struct cpudata *cpu, u64 time) u64 tsc; local_irq_save(flags); - rdmsrq(MSR_IA32_APERF, aperf); - rdmsrq(MSR_IA32_MPERF, mperf); + aperf = rdmsrq(MSR_IA32_APERF); + mperf = rdmsrq(MSR_IA32_MPERF); tsc = rdtsc(); if (cpu->prev_mperf == mperf || cpu->prev_tsc == tsc) { local_irq_restore(flags); @@ -3642,7 +3642,7 @@ static bool __init intel_pstate_platform_pwr_mgmt_exists(void) id = x86_match_cpu(intel_pstate_cpu_oob_ids); if (id) { - rdmsrq(MSR_MISC_PWR_MGMT, misc_pwr); + misc_pwr = rdmsrq(MSR_MISC_PWR_MGMT); if (misc_pwr & BITMASK_OOB) { pr_debug("Bit 8 or 18 in the MISC_PWR_MGMT MSR set\n"); pr_debug("P states are controlled in Out of Band mode by the firmware/hardware\n"); @@ -3698,7 +3698,7 @@ static bool intel_pstate_hwp_is_enabled(void) { u64 value; - rdmsrq(MSR_PM_ENABLE, value); + value = rdmsrq(MSR_PM_ENABLE); return !!(value & 0x1); } diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c index 4c2599264333..9bc0acc0ea69 100644 --- a/drivers/cpufreq/longhaul.c +++ b/drivers/cpufreq/longhaul.c @@ -121,7 +121,7 @@ static int longhaul_get_cpu_mult(void) unsigned long invalue = 0; u64 val; - rdmsrq(MSR_IA32_EBL_CR_POWERON, val); + val = rdmsrq(MSR_IA32_EBL_CR_POWERON); invalue = (val & (1<<22|1<<23|1<<24|1<<25))>>22; if (longhaul_version == TYPE_LONGHAUL_V2 || longhaul_version == TYPE_POWERSAVER) { @@ -137,7 +137,7 @@ static void do_longhaul1(unsigned int mults_index) { union msr_bcr2 bcr2; - rdmsrq(MSR_VIA_BCR2, bcr2.val); + bcr2.val = rdmsrq(MSR_VIA_BCR2); /* Enable software clock multiplier */ bcr2.bits.ESOFTBF = 1; bcr2.bits.CLOCKMUL = mults_index & 0xff; @@ -152,7 +152,7 @@ static void do_longhaul1(unsigned int mults_index) /* Disable software clock multiplier */ local_irq_disable(); - rdmsrq(MSR_VIA_BCR2, bcr2.val); + bcr2.val = rdmsrq(MSR_VIA_BCR2); bcr2.bits.ESOFTBF = 0; wrmsrq(MSR_VIA_BCR2, bcr2.val); } @@ -165,7 +165,7 @@ static void do_powersaver(int cx_address, unsigned int mults_index, union msr_longhaul longhaul; u32 t; - rdmsrq(MSR_VIA_LONGHAUL, longhaul.val); + longhaul.val = rdmsrq(MSR_VIA_LONGHAUL); /* Setup new frequency */ if (!revid_errata) longhaul.bits.RevisionKey = longhaul.bits.RevisionID; @@ -534,7 +534,7 @@ static void longhaul_setup_voltagescaling(void) unsigned int j, speed, pos, kHz_step, numvscales; int min_vid_speed; - rdmsrq(MSR_VIA_LONGHAUL, longhaul.val); + longhaul.val = rdmsrq(MSR_VIA_LONGHAUL); if (!(longhaul.bits.RevisionID & 1)) { pr_info("Voltage scaling not supported by CPU\n"); return; @@ -836,7 +836,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) } /* Check Longhaul ver. 2 */ if (longhaul_version == TYPE_LONGHAUL_V2) { - rdmsrq(MSR_VIA_LONGHAUL, val); + val = rdmsrq(MSR_VIA_LONGHAUL); if (val == 0) /* Looks like MSR isn't present */ longhaul_version = TYPE_LONGHAUL_V1; diff --git a/drivers/cpufreq/longrun.c b/drivers/cpufreq/longrun.c index 82a7bb69c401..4b7e624ae1e5 100644 --- a/drivers/cpufreq/longrun.c +++ b/drivers/cpufreq/longrun.c @@ -37,14 +37,14 @@ static void longrun_get_policy(struct cpufreq_policy *policy) { struct msr msr; - rdmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); + msr.q = rdmsrq(MSR_TMTA_LONGRUN_FLAGS); pr_debug("longrun flags are %x - %x\n", msr.l, msr.h); if (msr.l & 0x01) policy->policy = CPUFREQ_POLICY_PERFORMANCE; else policy->policy = CPUFREQ_POLICY_POWERSAVE; - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); + msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL); pr_debug("longrun ctrl is %x - %x\n", msr.l, msr.h); msr.l &= 0x0000007F; msr.h &= 0x0000007F; @@ -93,7 +93,7 @@ static int longrun_set_policy(struct cpufreq_policy *policy) pctg_lo = pctg_hi; /* performance or economy mode */ - rdmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); + msr.q = rdmsrq(MSR_TMTA_LONGRUN_FLAGS); msr.l &= 0xFFFFFFFE; switch (policy->policy) { case CPUFREQ_POLICY_PERFORMANCE: @@ -105,7 +105,7 @@ static int longrun_set_policy(struct cpufreq_policy *policy) wrmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); /* lower and upper boundary */ - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); + msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL); msr.l &= 0xFFFFFF80; msr.h &= 0xFFFFFF80; msr.l |= pctg_lo; @@ -177,16 +177,16 @@ static int longrun_determine_freqs(unsigned int *low_freq, * For maximum frequency, read out level zero. */ /* minimum */ - rdmsrq(MSR_TMTA_LRTI_READOUT, msr.q); + msr.q = rdmsrq(MSR_TMTA_LRTI_READOUT); msr.l = msr.h; wrmsrq(MSR_TMTA_LRTI_READOUT, msr.q); - rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ, msr.q); + msr.q = rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ); *low_freq = msr.l * 1000; /* to kHz */ /* maximum */ msr.l = 0; wrmsrq(MSR_TMTA_LRTI_READOUT, msr.q); - rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ, msr.q); + msr.q = rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ); *high_freq = msr.l * 1000; /* to kHz */ pr_debug("longrun table interface told %u - %u kHz\n", @@ -203,7 +203,7 @@ static int longrun_determine_freqs(unsigned int *low_freq, pr_debug("high frequency is %u kHz\n", *high_freq); /* get current borders */ - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); + msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL); save.l = msr.l & 0x0000007F; save.h = msr.h & 0x0000007F; diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.c index 6a930d7e6a5c..1df2a8f365a3 100644 --- a/drivers/cpufreq/powernow-k7.c +++ b/drivers/cpufreq/powernow-k7.c @@ -220,7 +220,7 @@ static void change_FID(int fid) { union msr_fidvidctl fidvidctl; - rdmsrq(MSR_K7_FID_VID_CTL, fidvidctl.val); + fidvidctl.val = rdmsrq(MSR_K7_FID_VID_CTL); if (fidvidctl.bits.FID != fid) { fidvidctl.bits.SGTC = latency; fidvidctl.bits.FID = fid; @@ -235,7 +235,7 @@ static void change_VID(int vid) { union msr_fidvidctl fidvidctl; - rdmsrq(MSR_K7_FID_VID_CTL, fidvidctl.val); + fidvidctl.val = rdmsrq(MSR_K7_FID_VID_CTL); if (fidvidctl.bits.VID != vid) { fidvidctl.bits.SGTC = latency; fidvidctl.bits.VID = vid; @@ -261,7 +261,7 @@ static int powernow_target(struct cpufreq_policy *policy, unsigned int index) fid = powernow_table[index].driver_data & 0xFF; vid = (powernow_table[index].driver_data & 0xFF00) >> 8; - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); + fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS); cfid = fidvidstatus.bits.CFID; freqs.old = fsb * fid_codes[cfid] / 10; @@ -558,7 +558,7 @@ static unsigned int powernow_get(unsigned int cpu) if (cpu) return 0; - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); + fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS); cfid = fidvidstatus.bits.CFID; return fsb * fid_codes[cfid] / 10; @@ -599,7 +599,7 @@ static int powernow_cpu_init(struct cpufreq_policy *policy) if (policy->cpu != 0) return -ENODEV; - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); + fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS); recalibrate_cpu_khz(); diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c index c9bcc6f0ab7b..6097dc3e5a89 100644 --- a/drivers/cpufreq/powernow-k8.c +++ b/drivers/cpufreq/powernow-k8.c @@ -89,7 +89,7 @@ static int pending_bit_stuck(void) { u64 msr; - rdmsrq(MSR_FIDVID_STATUS, msr); + msr = rdmsrq(MSR_FIDVID_STATUS); return msr & MSR_S_LO_CHANGE_PENDING ? 1 : 0; } @@ -107,7 +107,7 @@ static int query_current_values_with_pending_wait(struct powernow_k8_data *data) pr_debug("detected change pending stuck\n"); return 1; } - rdmsrq(MSR_FIDVID_STATUS, msr.q); + msr.q = rdmsrq(MSR_FIDVID_STATUS); } while (msr.l & MSR_S_LO_CHANGE_PENDING); data->currvid = msr.h & MSR_S_HI_CURRENT_VID; @@ -134,7 +134,7 @@ static void fidvid_msr_init(void) struct msr msr; u8 fid, vid; - rdmsrq(MSR_FIDVID_STATUS, msr.q); + msr.q = rdmsrq(MSR_FIDVID_STATUS); vid = msr.h & MSR_S_HI_CURRENT_VID; fid = msr.l & MSR_S_LO_CURRENT_FID; msr.l = fid | (vid << MSR_C_LO_VID_SHIFT); @@ -293,7 +293,7 @@ static int core_voltage_pre_transition(struct powernow_k8_data *data, if ((savefid < LO_FID_TABLE_TOP) && (reqfid < LO_FID_TABLE_TOP)) rvomult = 2; rvosteps *= rvomult; - rdmsrq(MSR_FIDVID_STATUS, msr.q); + msr.q = rdmsrq(MSR_FIDVID_STATUS); maxvid = 0x1f & (msr.h >> 16); pr_debug("ph1 maxvid=0x%x\n", maxvid); if (reqvid < maxvid) /* lower numbers are higher voltages */ diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speedstep-centrino.c index de50fb367c6b..2e90b658bfc2 100644 --- a/drivers/cpufreq/speedstep-centrino.c +++ b/drivers/cpufreq/speedstep-centrino.c @@ -378,7 +378,7 @@ static int centrino_cpu_init(struct cpufreq_policy *policy) /* Check to see if Enhanced SpeedStep is enabled, and try to enable it if not. */ - rdmsrq(MSR_IA32_MISC_ENABLE, q); + q = rdmsrq(MSR_IA32_MISC_ENABLE); if (!(q & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { q |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP; @@ -386,7 +386,7 @@ static int centrino_cpu_init(struct cpufreq_policy *policy) wrmsrq(MSR_IA32_MISC_ENABLE, q); /* check to see if it stuck */ - rdmsrq(MSR_IA32_MISC_ENABLE, q); + q = rdmsrq(MSR_IA32_MISC_ENABLE); if (!(q & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { pr_info("couldn't enable Enhanced SpeedStep\n"); return -ENODEV; diff --git a/drivers/cpufreq/speedstep-lib.c b/drivers/cpufreq/speedstep-lib.c index 2afc3f177a29..188d459c7e2a 100644 --- a/drivers/cpufreq/speedstep-lib.c +++ b/drivers/cpufreq/speedstep-lib.c @@ -74,7 +74,7 @@ static unsigned int pentium3_get_frequency(enum speedstep_processor processor) int i = 0, j = 0; /* read MSR 0x2a - we only need the low 32 bits */ - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); + msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON); pr_debug("P3 - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.h); msr_tmp = msr_lo = msr.l; @@ -112,7 +112,7 @@ static unsigned int pentiumM_get_frequency(void) struct msr msr; u32 msr_tmp; - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); + msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON); pr_debug("PM - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.h); /* see table B-2 of 24547212.pdf */ @@ -136,7 +136,7 @@ static unsigned int pentium_core_get_frequency(void) u32 msr_tmp; int ret; - rdmsrq(MSR_FSB_FREQ, msr.q); + msr.q = rdmsrq(MSR_FSB_FREQ); /* see table B-2 of 25366920.pdf */ switch (msr.l & 0x07) { case 5: @@ -161,7 +161,7 @@ static unsigned int pentium_core_get_frequency(void) pr_err("PCORE - MSR_FSB_FREQ undefined value\n"); } - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); + msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON); pr_debug("PCORE - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.h); @@ -191,7 +191,7 @@ static unsigned int pentium4_get_frequency(void) if (c->x86_model < 2) return cpu_khz; - rdmsrq(0x2c, msr.q); + msr.q = rdmsrq(0x2c); pr_debug("P4 - MSR_EBC_FREQUENCY_ID: 0x%x 0x%x\n", msr.l, msr.h); @@ -348,7 +348,7 @@ enum speedstep_processor speedstep_detect_processor(void) /* all mobile PIII Coppermines have FSB 100 MHz * ==> sort out a few desktop PIIIs. */ - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); + msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON); pr_debug("Coppermine: MSR_IA32_EBL_CR_POWERON is 0x%x, 0x%x\n", msr.l, msr.h); msr.l &= 0x00c0000; @@ -361,7 +361,7 @@ enum speedstep_processor speedstep_detect_processor(void) * it has SpeedStep technology if either * bit 56 or 57 is set */ - rdmsrq(MSR_IA32_PLATFORM_ID, msr.q); + msr.q = rdmsrq(MSR_IA32_PLATFORM_ID); pr_debug("Coppermine: MSR_IA32_PLATFORM ID is 0x%x, 0x%x\n", msr.l, msr.h); if ((msr.h & (1<<18)) && diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c index 475235c402e8..40317ab69461 100644 --- a/drivers/edac/amd64_edac.c +++ b/drivers/edac/amd64_edac.c @@ -2956,13 +2956,13 @@ static void dct_read_mc_regs(struct amd64_pvt *pvt) * Retrieve TOP_MEM and TOP_MEM2; no masking off of reserved bits since * those are Read-As-Zero. */ - rdmsrq(MSR_K8_TOP_MEM1, pvt->top_mem); + pvt->top_mem = rdmsrq(MSR_K8_TOP_MEM1); edac_dbg(0, " TOP_MEM: 0x%016llx\n", pvt->top_mem); /* Check first whether TOP_MEM2 is enabled: */ - rdmsrq(MSR_AMD64_SYSCFG, msr_val); + msr_val = rdmsrq(MSR_AMD64_SYSCFG); if (msr_val & BIT(21)) { - rdmsrq(MSR_K8_TOP_MEM2, pvt->top_mem2); + pvt->top_mem2 = rdmsrq(MSR_K8_TOP_MEM2); edac_dbg(0, " TOP_MEM2: 0x%016llx\n", pvt->top_mem2); } else { edac_dbg(0, " TOP_MEM2 disabled\n"); diff --git a/drivers/gpio/gpio-cs5535.c b/drivers/gpio/gpio-cs5535.c index a97ec7561889..e9cc577e94b7 100644 --- a/drivers/gpio/gpio-cs5535.c +++ b/drivers/gpio/gpio-cs5535.c @@ -148,7 +148,7 @@ int cs5535_gpio_set_irq(unsigned group, unsigned irq) if (group > 7 || irq > 15) return -EINVAL; - rdmsrq(MSR_PIC_ZSEL_HIGH, val.q); + val.q = rdmsrq(MSR_PIC_ZSEL_HIGH); val.l &= ~(0xF << (group * 4)); val.l |= (irq & 0xF) << (group * 4); diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c index 6e3c11c68171..f678eda1641c 100644 --- a/drivers/hv/mshv_vtl_main.c +++ b/drivers/hv/mshv_vtl_main.c @@ -599,7 +599,7 @@ static int mshv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set) if (set) wrmsrq(reg_table[i].msr_addr, *reg64); else - rdmsrq(reg_table[i].msr_addr, *reg64); + *reg64 = rdmsrq(reg_table[i].msr_addr); } return 0; } diff --git a/drivers/hwmon/hwmon-vid.c b/drivers/hwmon/hwmon-vid.c index dee42c163d92..cfb3a2975de4 100644 --- a/drivers/hwmon/hwmon-vid.c +++ b/drivers/hwmon/hwmon-vid.c @@ -243,10 +243,10 @@ static u8 get_via_model_d_vrm(void) "C7-M", "C7", "Eden", "C7-D" }; - rdmsrq(0x198, msr); + msr = rdmsrq(0x198); vid = (msr >> 32) & 0xff; - rdmsrq(0x1154, msr); + msr = rdmsrq(0x1154); brand = ((msr >> 4) ^ (msr >> 2)) & 0x03; if (vid > 0x3f) { diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index 651408df9c24..82faaf771b2d 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -2125,35 +2125,35 @@ static void __init bxt_idle_state_table_update(void) unsigned long long msr; unsigned int usec; - rdmsrq(MSR_PKGC6_IRTL, msr); + msr = rdmsrq(MSR_PKGC6_IRTL); usec = irtl_2_usec(msr); if (usec) { bxt_cstates[2].exit_latency = usec; bxt_cstates[2].target_residency = usec; } - rdmsrq(MSR_PKGC7_IRTL, msr); + msr = rdmsrq(MSR_PKGC7_IRTL); usec = irtl_2_usec(msr); if (usec) { bxt_cstates[3].exit_latency = usec; bxt_cstates[3].target_residency = usec; } - rdmsrq(MSR_PKGC8_IRTL, msr); + msr = rdmsrq(MSR_PKGC8_IRTL); usec = irtl_2_usec(msr); if (usec) { bxt_cstates[4].exit_latency = usec; bxt_cstates[4].target_residency = usec; } - rdmsrq(MSR_PKGC9_IRTL, msr); + msr = rdmsrq(MSR_PKGC9_IRTL); usec = irtl_2_usec(msr); if (usec) { bxt_cstates[5].exit_latency = usec; bxt_cstates[5].target_residency = usec; } - rdmsrq(MSR_PKGC10_IRTL, msr); + msr = rdmsrq(MSR_PKGC10_IRTL); usec = irtl_2_usec(msr); if (usec) { bxt_cstates[6].exit_latency = usec; @@ -2181,7 +2181,7 @@ static void __init sklh_idle_state_table_update(void) if ((mwait_substates & (0xF << 28)) == 0) return; - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr); + msr = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); /* PC10 is not enabled in PKG C-state limit */ if ((msr & 0xF) != 8) @@ -2193,7 +2193,7 @@ static void __init sklh_idle_state_table_update(void) /* if SGX is present */ if (ebx & (1 << 2)) { - rdmsrq(MSR_IA32_FEAT_CTL, msr); + msr = rdmsrq(MSR_IA32_FEAT_CTL); /* if SGX is enabled */ if (msr & (1 << 18)) @@ -2213,7 +2213,7 @@ static bool __init skx_is_pc6_disabled(void) { u64 msr; - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr); + msr = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); /* * 000b: C0/C1 (no package C-state support) @@ -2467,7 +2467,7 @@ static void auto_demotion_disable(void) { unsigned long long msr_bits; - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_bits); + msr_bits = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); msr_bits &= ~auto_demotion_disable_flags; wrmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_bits); } @@ -2476,7 +2476,7 @@ static void c1e_promotion_enable(void) { unsigned long long msr_bits; - rdmsrq(MSR_IA32_POWER_CTL, msr_bits); + msr_bits = rdmsrq(MSR_IA32_POWER_CTL); msr_bits |= 0x2; wrmsrq(MSR_IA32_POWER_CTL, msr_bits); } @@ -2485,7 +2485,7 @@ static void c1e_promotion_disable(void) { unsigned long long msr_bits; - rdmsrq(MSR_IA32_POWER_CTL, msr_bits); + msr_bits = rdmsrq(MSR_IA32_POWER_CTL); msr_bits &= ~0x2; wrmsrq(MSR_IA32_POWER_CTL, msr_bits); } @@ -2554,7 +2554,7 @@ static void intel_c1_demotion_toggle(void *enable) { unsigned long long msr_val; - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_val); + msr_val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); /* * Enable/disable C1 undemotion along with C1 demotion, as this is the * most sensible configuration in general. @@ -2594,7 +2594,7 @@ static ssize_t intel_c1_demotion_show(struct device *dev, * Read the MSR value for a CPU and assume it is the same for all CPUs. Any other * configuration would be a BIOS bug. */ - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_val); + msr_val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); return sysfs_emit(buf, "%d\n", !!(msr_val & NHM_C1_AUTO_DEMOTE)); } static DEVICE_ATTR_RW(intel_c1_demotion); diff --git a/drivers/misc/cs5535-mfgpt.c b/drivers/misc/cs5535-mfgpt.c index 9abfc44f70f4..9006b59858ff 100644 --- a/drivers/misc/cs5535-mfgpt.c +++ b/drivers/misc/cs5535-mfgpt.c @@ -83,7 +83,7 @@ int cs5535_mfgpt_toggle_event(struct cs5535_mfgpt_timer *timer, int cmp, return -EIO; } - rdmsrq(msr, val.q); + val.q = rdmsrq(msr); if (enable) val.l |= mask; @@ -114,7 +114,7 @@ int cs5535_mfgpt_set_irq(struct cs5535_mfgpt_timer *timer, int cmp, int *irq, * IRQ of the 1st. This can only happen if forcing an IRQ, calling this * with *irq==0 is safe. Currently there _are_ no 2 drivers. */ - rdmsrq(MSR_PIC_ZSEL_LOW, zsel.q); + zsel.q = rdmsrq(MSR_PIC_ZSEL_LOW); shift = ((cmp == MFGPT_CMP1 ? 0 : 4) + timer->nr % 4) * 4; if (((zsel.l >> shift) & 0xF) == 2) return -EIO; @@ -128,7 +128,7 @@ int cs5535_mfgpt_set_irq(struct cs5535_mfgpt_timer *timer, int cmp, int *irq, /* Can't use IRQ if it's 0 (=disabled), 2, or routed to LPC */ if (*irq < 1 || *irq == 2 || *irq > 15) return -EIO; - rdmsrq(MSR_PIC_IRQM_LPC, lpc.q); + lpc.q = rdmsrq(MSR_PIC_IRQM_LPC); if (lpc.l & (1 << *irq)) return -EIO; diff --git a/drivers/mtd/nand/raw/cs553x_nand.c b/drivers/mtd/nand/raw/cs553x_nand.c index 0b872b1e3b04..2ed13666b48f 100644 --- a/drivers/mtd/nand/raw/cs553x_nand.c +++ b/drivers/mtd/nand/raw/cs553x_nand.c @@ -351,20 +351,20 @@ static int __init cs553x_init(void) return -ENXIO; /* If it doesn't have the CS553[56], abort */ - rdmsrq(MSR_DIVIL_GLD_CAP, val); + val = rdmsrq(MSR_DIVIL_GLD_CAP); val &= ~0xFFULL; if (val != CAP_CS5535 && val != CAP_CS5536) return -ENXIO; /* If it doesn't have the NAND controller enabled, abort */ - rdmsrq(MSR_DIVIL_BALL_OPTS, val); + val = rdmsrq(MSR_DIVIL_BALL_OPTS); if (val & PIN_OPT_IDE) { pr_info("CS553x NAND controller: Flash I/O not enabled in MSR_DIVIL_BALL_OPTS.\n"); return -ENXIO; } for (i = 0; i < NR_CS553X_CONTROLLERS; i++) { - rdmsrq(MSR_DIVIL_LBAR_FLSH0 + i, val); + val = rdmsrq(MSR_DIVIL_LBAR_FLSH0 + i); if ((val & (FLSH_LBAR_EN|FLSH_NOR_NAND)) == (FLSH_LBAR_EN|FLSH_NOR_NAND)) err = cs553x_init_one(i, !!(val & FLSH_MEM_IO), val & 0xFFFFFFFF); diff --git a/drivers/platform/x86/intel/ifs/load.c b/drivers/platform/x86/intel/ifs/load.c index 50f1fdf7dfed..6320a0e45d38 100644 --- a/drivers/platform/x86/intel/ifs/load.c +++ b/drivers/platform/x86/intel/ifs/load.c @@ -129,7 +129,7 @@ static void copy_hashes_authenticate_chunks(struct work_struct *work) msrs = ifs_get_test_msrs(dev); /* run scan hash copy */ wrmsrq(msrs->copy_hashes, ifs_hash_ptr); - rdmsrq(msrs->copy_hashes_status, hashes_status.data); + hashes_status.data = rdmsrq(msrs->copy_hashes_status); /* enumerate the scan image information */ num_chunks = hashes_status.num_chunks; @@ -151,7 +151,7 @@ static void copy_hashes_authenticate_chunks(struct work_struct *work) linear_addr |= i; wrmsrq(msrs->copy_chunks, linear_addr); - rdmsrq(msrs->copy_chunks_status, chunk_status.data); + chunk_status.data = rdmsrq(msrs->copy_chunks_status); ifsd->valid_chunks = chunk_status.valid_chunks; err_code = chunk_status.error_code; @@ -197,7 +197,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev) if (need_copy_scan_hashes(ifsd)) { wrmsrq(msrs->copy_hashes, ifs_hash_ptr); - rdmsrq(msrs->copy_hashes_status, hashes_status.data); + hashes_status.data = rdmsrq(msrs->copy_hashes_status); /* enumerate the scan image information */ chunk_size = hashes_status.chunk_size * SZ_1K; @@ -218,7 +218,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev) if (ifsd->generation >= IFS_GEN_STRIDE_AWARE) { wrmsrq(msrs->test_ctrl, INVALIDATE_STRIDE); - rdmsrq(msrs->copy_chunks_status, chunk_status.data); + chunk_status.data = rdmsrq(msrs->copy_chunks_status); if (chunk_status.valid_chunks != 0) { dev_err(dev, "Couldn't invalidate installed stride - %d\n", chunk_status.valid_chunks); @@ -241,7 +241,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev) local_irq_disable(); wrmsrq(msrs->copy_chunks, (u64)chunk_table); local_irq_enable(); - rdmsrq(msrs->copy_chunks_status, chunk_status.data); + chunk_status.data = rdmsrq(msrs->copy_chunks_status); err_code = chunk_status.error_code; } while (err_code == AUTH_INTERRUPTED_ERROR && --retry_count); diff --git a/drivers/platform/x86/intel/ifs/runtest.c b/drivers/platform/x86/intel/ifs/runtest.c index dfc119d7354d..46e1ea944ce7 100644 --- a/drivers/platform/x86/intel/ifs/runtest.c +++ b/drivers/platform/x86/intel/ifs/runtest.c @@ -211,7 +211,7 @@ static int doscan(void *data) * are processed in a single pass) before it retires. */ wrmsrq(MSR_ACTIVATE_SCAN, params->activate->data); - rdmsrq(MSR_SCAN_STATUS, status.data); + status.data = rdmsrq(MSR_SCAN_STATUS); trace_ifs_status(ifsd->cur_batch, start, stop, status.data); @@ -324,7 +324,7 @@ static int do_array_test(void *data) if (cpu == first) { wrmsrq(MSR_ARRAY_BIST, command->data); /* Pass back the result of the test */ - rdmsrq(MSR_ARRAY_BIST, command->data); + command->data = rdmsrq(MSR_ARRAY_BIST); } return 0; @@ -376,7 +376,7 @@ static int do_array_test_gen1(void *status) if (cpu == first) { wrmsrq(MSR_ARRAY_TRIGGER, ARRAY_GEN1_TEST_ALL_ARRAYS); - rdmsrq(MSR_ARRAY_STATUS, *((u64 *)status)); + *((u64 *)status) = rdmsrq(MSR_ARRAY_STATUS); } return 0; @@ -528,7 +528,7 @@ static int dosbaf(void *data) * during the "execution" of the WRMSR. */ wrmsrq(MSR_ACTIVATE_SBAF, run_params->activate->data); - rdmsrq(MSR_SBAF_STATUS, status.data); + status.data = rdmsrq(MSR_SBAF_STATUS); trace_ifs_sbaf(ifsd->cur_batch, *run_params->activate, status); /* Pass back the result of the test */ diff --git a/drivers/platform/x86/intel/pmc/cnp.c b/drivers/platform/x86/intel/pmc/cnp.c index efea4e1ba52b..44979e680361 100644 --- a/drivers/platform/x86/intel/pmc/cnp.c +++ b/drivers/platform/x86/intel/pmc/cnp.c @@ -228,7 +228,7 @@ static void disable_c1_auto_demote(void *unused) int cpunum = smp_processor_id(); u64 val; - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, val); + val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); per_cpu(pkg_cst_config, cpunum) = val; val &= ~NHM_C1_AUTO_DEMOTE; wrmsrq(MSR_PKG_CST_CONFIG_CONTROL, val); diff --git a/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c b/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c index 22745b217c6f..909c9e25112d 100644 --- a/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c +++ b/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c @@ -40,7 +40,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter, /* Poll for rb bit == 0 */ retries = OS_MAILBOX_RETRY_COUNT; do { - rdmsrq(MSR_OS_MAILBOX_INTERFACE, data); + data = rdmsrq(MSR_OS_MAILBOX_INTERFACE); if (data & BIT_ULL(MSR_OS_MAILBOX_BUSY_BIT)) { ret = -EBUSY; continue; @@ -65,7 +65,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter, /* Poll for rb bit == 0 */ retries = OS_MAILBOX_RETRY_COUNT; do { - rdmsrq(MSR_OS_MAILBOX_INTERFACE, data); + data = rdmsrq(MSR_OS_MAILBOX_INTERFACE); if (data & BIT_ULL(MSR_OS_MAILBOX_BUSY_BIT)) { ret = -EBUSY; continue; @@ -75,7 +75,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter, return -ENXIO; if (response_data) { - rdmsrq(MSR_OS_MAILBOX_DATA, data); + data = rdmsrq(MSR_OS_MAILBOX_DATA); *response_data = data; } ret = 0; diff --git a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c index bb0d0b8fc54a..57262a6afe8c 100644 --- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c +++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c @@ -568,7 +568,7 @@ static bool disable_dynamic_sst_features(void) if (!cpu_feature_enabled(X86_FEATURE_HWP)) return true; - rdmsrq(MSR_PM_ENABLE, value); + value = rdmsrq(MSR_PM_ENABLE); return !(value & 0x1); } diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c index b1b2d9caba7b..79c07f23ba0b 100644 --- a/drivers/platform/x86/intel_ips.c +++ b/drivers/platform/x86/intel_ips.c @@ -370,7 +370,7 @@ static void ips_cpu_raise(struct ips_driver *ips) if (!ips->cpu_turbo_enabled) return; - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); + turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT); cur_tdp_limit = turbo_override & TURBO_TDP_MASK; new_tdp_limit = cur_tdp_limit + 8; /* 1W increase */ @@ -405,7 +405,7 @@ static void ips_cpu_lower(struct ips_driver *ips) u64 turbo_override; u16 cur_limit, new_limit; - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); + turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT); cur_limit = turbo_override & TURBO_TDP_MASK; new_limit = cur_limit - 8; /* 1W decrease */ @@ -437,7 +437,7 @@ static void do_enable_cpu_turbo(void *data) { u64 perf_ctl; - rdmsrq(IA32_PERF_CTL, perf_ctl); + perf_ctl = rdmsrq(IA32_PERF_CTL); if (perf_ctl & IA32_PERF_TURBO_DIS) { perf_ctl &= ~IA32_PERF_TURBO_DIS; wrmsrq(IA32_PERF_CTL, perf_ctl); @@ -475,7 +475,7 @@ static void do_disable_cpu_turbo(void *data) { u64 perf_ctl; - rdmsrq(IA32_PERF_CTL, perf_ctl); + perf_ctl = rdmsrq(IA32_PERF_CTL); if (!(perf_ctl & IA32_PERF_TURBO_DIS)) { perf_ctl |= IA32_PERF_TURBO_DIS; wrmsrq(IA32_PERF_CTL, perf_ctl); @@ -1215,7 +1215,7 @@ static int cpu_clamp_show(struct seq_file *m, void *data) u64 turbo_override; int tdp, tdc; - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); + turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT); tdp = (int)(turbo_override & TURBO_TDP_MASK); tdc = (int)((turbo_override & TURBO_TDC_MASK) >> TURBO_TDC_SHIFT); @@ -1290,7 +1290,7 @@ static struct ips_mcp_limits *ips_detect_cpu(struct ips_driver *ips) return NULL; } - rdmsrq(IA32_MISC_ENABLE, misc_en); + misc_en = rdmsrq(IA32_MISC_ENABLE); /* * If the turbo enable bit isn't set, we shouldn't try to enable/disable * turbo manually or we'll get an illegal MSR access, even though @@ -1312,7 +1312,7 @@ static struct ips_mcp_limits *ips_detect_cpu(struct ips_driver *ips) return NULL; } - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_power); + turbo_power = rdmsrq(TURBO_POWER_CURRENT_LIMIT); tdp = turbo_power & TURBO_TDP_MASK; /* Sanity check TDP against CPU */ @@ -1496,7 +1496,7 @@ static int ips_probe(struct pci_dev *dev, const struct pci_device_id *id) * Check PLATFORM_INFO MSR to make sure this chip is * turbo capable. */ - rdmsrq(PLATFORM_INFO, platform_info); + platform_info = rdmsrq(PLATFORM_INFO); if (!(platform_info & PLATFORM_TDP)) { dev_err(&dev->dev, "platform indicates TDP override unavailable, aborting\n"); return -ENODEV; @@ -1529,7 +1529,7 @@ static int ips_probe(struct pci_dev *dev, const struct pci_device_id *id) ips->mgta_val = thm_readw(THM_MGTA); /* Save turbo limits & ratios */ - rdmsrq(TURBO_POWER_CURRENT_LIMIT, ips->orig_turbo_limit); + ips->orig_turbo_limit = rdmsrq(TURBO_POWER_CURRENT_LIMIT); ips_disable_cpu_turbo(ips); ips->cpu_turbo_enabled = false; @@ -1596,7 +1596,7 @@ static void ips_remove(struct pci_dev *dev) if (ips->gpu_turbo_disable) symbol_put(i915_gpu_turbo_disable); - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); + turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT); turbo_override &= ~(TURBO_TDC_OVR_EN | TURBO_TDP_OVR_EN); wrmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); wrmsrq(TURBO_POWER_CURRENT_LIMIT, ips->orig_turbo_limit); diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rapl_msr.c index a34543e66446..5d840de67c2b 100644 --- a/drivers/powercap/intel_rapl_msr.c +++ b/drivers/powercap/intel_rapl_msr.c @@ -176,7 +176,7 @@ static int rapl_msr_read_raw(int cpu, struct reg_action *ra, bool pmu_ctx) * from any CPU in the package. */ if (pmu_ctx) { - rdmsrq(ra->reg.msr, ra->value); + ra->value = rdmsrq(ra->reg.msr); goto out; } diff --git a/drivers/thermal/intel/intel_hfi.c b/drivers/thermal/intel/intel_hfi.c index 3273b8fe3d4d..6b2801aaa745 100644 --- a/drivers/thermal/intel/intel_hfi.c +++ b/drivers/thermal/intel/intel_hfi.c @@ -285,7 +285,7 @@ void intel_hfi_process_event(__u64 pkg_therm_status_msr_val) if (!raw_spin_trylock(&hfi_instance->event_lock)) return; - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr); + msr = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); hfi = msr & PACKAGE_THERM_STATUS_HFI_UPDATED; if (!hfi) { raw_spin_unlock(&hfi_instance->event_lock); @@ -357,7 +357,7 @@ static void hfi_enable(void) { u64 msr_val; - rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); + msr_val = rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG); msr_val |= HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT; wrmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); } @@ -378,7 +378,7 @@ static void hfi_disable(void) u64 msr_val; int i; - rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); + msr_val = rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG); msr_val &= ~HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT; wrmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); @@ -389,7 +389,7 @@ static void hfi_disable(void) * memory. */ for (i = 0; i < 2000; i++) { - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); + msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); if (msr_val & PACKAGE_THERM_STATUS_HFI_UPDATED) break; diff --git a/drivers/thermal/intel/therm_throt.c b/drivers/thermal/intel/therm_throt.c index 4d4e81601d17..3ead57f45510 100644 --- a/drivers/thermal/intel/therm_throt.c +++ b/drivers/thermal/intel/therm_throt.c @@ -297,7 +297,7 @@ static void get_therm_status(int level, bool *proc_hot, u8 *temp) else msr = MSR_IA32_PACKAGE_THERM_STATUS; - rdmsrq(msr, msr_val); + msr_val = rdmsrq(msr); if (msr_val & THERM_STATUS_PROCHOT_LOG) *proc_hot = true; else @@ -543,7 +543,7 @@ static int check_directed_thermal_pkg_intr_ack(void) * Wait 15ms to be safe. */ do { - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); + msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); udelay(1); } while (!(msr_val & PACKAGE_THERM_STATUS_DPTI_ACK) && --count); @@ -561,7 +561,7 @@ static void config_directed_thermal_pkg_intr(void *info) bool enable = *((bool *)info); u64 msr_val; - rdmsrq(MSR_IA32_THERM_INTERRUPT, msr_val); + msr_val = rdmsrq(MSR_IA32_THERM_INTERRUPT); if (enable) msr_val |= THERM_INT_DPTI_ENABLE; @@ -931,7 +931,7 @@ void intel_thermal_interrupt(void) if (cpu_feature_enabled(X86_FEATURE_HWP)) notify_hwp_interrupt(); - rdmsrq(MSR_IA32_THERM_STATUS, msr_val); + msr_val = rdmsrq(MSR_IA32_THERM_STATUS); /* Check for violation of core thermal thresholds*/ notify_thresholds(msr_val); @@ -946,7 +946,7 @@ void intel_thermal_interrupt(void) CORE_LEVEL); if (this_cpu_has(X86_FEATURE_PTS)) { - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); + msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); /* check violations of package thermal thresholds */ notify_package_thresholds(msr_val); therm_throt_process(msr_val & PACKAGE_THERM_STATUS_PROCHOT, @@ -1004,7 +1004,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) * be some SMM goo which handles it, so we can't even put a handler * since it might be delivered via SMI already: */ - rdmsrq(MSR_IA32_MISC_ENABLE, val.q); + val.q = rdmsrq(MSR_IA32_MISC_ENABLE); val.h = lvtthmr_init; /* @@ -1030,7 +1030,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) /* early Pentium M models use different method for enabling TM2 */ if (cpu_has(c, X86_FEATURE_TM2)) { if (c->x86 == 6 && (c->x86_model == 9 || c->x86_model == 13)) { - rdmsrq(MSR_THERM2_CTL, val.q); + val.q = rdmsrq(MSR_THERM2_CTL); if (val.l & MSR_THERM2_CTL_TM_SELECT) tm2 = 1; } else if (val.l & MSR_IA32_MISC_ENABLE_TM2) @@ -1044,7 +1044,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) thermal_intr_init_core_clear_mask(); thermal_intr_init_pkg_clear_mask(); - rdmsrq(MSR_IA32_THERM_INTERRUPT, val.q); + val.q = rdmsrq(MSR_IA32_THERM_INTERRUPT); if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable) { val.l |= THERM_INT_LOW_ENABLE | THERM_INT_HIGH_ENABLE; val.l &= ~THERM_INT_PLN_ENABLE; @@ -1056,7 +1056,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) wrmsrq(MSR_IA32_THERM_INTERRUPT, val.q); if (cpu_has(c, X86_FEATURE_PTS)) { - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); + val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable) { val.l |= PACKAGE_THERM_INT_LOW_ENABLE | PACKAGE_THERM_INT_HIGH_ENABLE; @@ -1071,13 +1071,13 @@ void intel_init_thermal(struct cpuinfo_x86 *c) wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); if (cpu_has(c, X86_FEATURE_HFI)) { - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); + val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q | PACKAGE_THERM_INT_HFI_ENABLE); } } - rdmsrq(MSR_IA32_MISC_ENABLE, val.q); + val.q = rdmsrq(MSR_IA32_MISC_ENABLE); wrmsrq(MSR_IA32_MISC_ENABLE, val.q | MSR_IA32_MISC_ENABLE_TM1); pr_info_once("CPU0: Thermal monitoring enabled (%s)\n", diff --git a/drivers/thermal/intel/x86_pkg_temp_thermal.c b/drivers/thermal/intel/x86_pkg_temp_thermal.c index 43fd5bdf1d8d..11ca647802dc 100644 --- a/drivers/thermal/intel/x86_pkg_temp_thermal.c +++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c @@ -187,7 +187,7 @@ static inline void enable_pkg_thres_interrupt(void) u8 thres_0, thres_1; struct msr val; - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); + val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); /* only enable/disable if it had valid threshold value */ thres_0 = (val.l & THERM_MASK_THRESHOLD0) >> THERM_SHIFT_THRESHOLD0; thres_1 = (val.l & THERM_MASK_THRESHOLD1) >> THERM_SHIFT_THRESHOLD1; @@ -203,7 +203,7 @@ static inline void disable_pkg_thres_interrupt(void) { struct msr val; - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); + val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); val.l &= ~(THERM_INT_THRESHOLD0_ENABLE | THERM_INT_THRESHOLD1_ENABLE); wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); @@ -356,7 +356,7 @@ static int pkg_temp_thermal_device_add(unsigned int cpu) goto out_unregister_tz; /* Store MSR value for package thermal interrupt, to restore at exit */ - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, zonedev->msr_pkg_therm); + zonedev->msr_pkg_therm = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); cpumask_set_cpu(cpu, &zonedev->cpumask); raw_spin_lock_irq(&pkg_temp_lock); diff --git a/drivers/video/fbdev/geode/display_gx.c b/drivers/video/fbdev/geode/display_gx.c index b93aa21a1d2b..511cb7bf98e9 100644 --- a/drivers/video/fbdev/geode/display_gx.c +++ b/drivers/video/fbdev/geode/display_gx.c @@ -26,7 +26,7 @@ unsigned int gx_frame_buffer_size(void) struct msr msr; /* The number of pages is (PMAX - PMIN)+1 */ - rdmsrq(MSR_GLIU_P2D_RO0, msr.q); + msr.q = rdmsrq(MSR_GLIU_P2D_RO0); /* PMAX */ val = ((msr.h & 0xff) << 12) | ((msr.l & 0xfff00000) >> 20); diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/geode/gxfb_core.c index 8d69be7c9d31..e0a3447f2b1b 100644 --- a/drivers/video/fbdev/geode/gxfb_core.c +++ b/drivers/video/fbdev/geode/gxfb_core.c @@ -378,7 +378,7 @@ static int gxfb_probe(struct pci_dev *pdev, const struct pci_device_id *id) /* Figure out if this is a TFT or CRT part */ - rdmsrq(MSR_GX_GLD_MSR_CONFIG, val); + val = rdmsrq(MSR_GX_GLD_MSR_CONFIG); if ((val & MSR_GX_GLD_MSR_CONFIG_FP) == MSR_GX_GLD_MSR_CONFIG_FP) par->enable_crt = 0; diff --git a/drivers/video/fbdev/geode/lxfb_ops.c b/drivers/video/fbdev/geode/lxfb_ops.c index f5f1134cae9a..980a782214a2 100644 --- a/drivers/video/fbdev/geode/lxfb_ops.c +++ b/drivers/video/fbdev/geode/lxfb_ops.c @@ -127,7 +127,7 @@ static void lx_set_dotpll(u32 pllval) struct msr dotpll; int i; - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); + dotpll.q = rdmsrq(MSR_GLCP_DOTPLL); if ((dotpll.l & MSR_GLCP_DOTPLL_LOCK) && (dotpll.h == pllval)) return; @@ -145,7 +145,7 @@ static void lx_set_dotpll(u32 pllval) /* Now, loop for the lock bit */ for (i = 0; i < 1000; i++) { - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); + dotpll.q = rdmsrq(MSR_GLCP_DOTPLL); if (dotpll.l & MSR_GLCP_DOTPLL_LOCK) break; } @@ -316,7 +316,7 @@ unsigned int lx_framebuffer_size(void) struct msr msr; /* The number of pages is (PMAX - PMIN)+1 */ - rdmsrq(MSR_GLIU_P2D_RO0, msr.q); + msr.q = rdmsrq(MSR_GLIU_P2D_RO0); /* PMAX */ val = ((msr.h & 0xff) << 12) | ((msr.l & 0xfff00000) >> 20); @@ -359,7 +359,7 @@ void lx_set_mode(struct fb_info *info) /* Set output mode */ - rdmsrq(MSR_LX_GLD_MSR_CONFIG, msrval); + msrval = rdmsrq(MSR_LX_GLD_MSR_CONFIG); msrval &= ~MSR_LX_GLD_MSR_CONFIG_FMT; if (par->output & OUTPUT_PANEL) { @@ -420,7 +420,7 @@ void lx_set_mode(struct fb_info *info) /* Set default watermark values */ - rdmsrq(MSR_LX_SPARE_MSR, msrval); + msrval = rdmsrq(MSR_LX_SPARE_MSR); msrval &= ~(MSR_LX_SPARE_MSR_DIS_CFIFO_HGO | MSR_LX_SPARE_MSR_VFIFO_ARB_SEL @@ -592,10 +592,10 @@ static void lx_save_regs(struct lxfb_par *par) } while ((i & GP_BLT_STATUS_PB) || !(i & GP_BLT_STATUS_CE)); /* save MSRs */ - rdmsrq(MSR_LX_MSR_PADSEL, par->msr.padsel); - rdmsrq(MSR_GLCP_DOTPLL, par->msr.dotpll); - rdmsrq(MSR_LX_GLD_MSR_CONFIG, par->msr.dfglcfg); - rdmsrq(MSR_LX_SPARE_MSR, par->msr.dcspare); + par->msr.padsel = rdmsrq(MSR_LX_MSR_PADSEL); + par->msr.dotpll = rdmsrq(MSR_GLCP_DOTPLL); + par->msr.dfglcfg = rdmsrq(MSR_LX_GLD_MSR_CONFIG); + par->msr.dcspare = rdmsrq(MSR_LX_SPARE_MSR); write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK); diff --git a/drivers/video/fbdev/geode/suspend_gx.c b/drivers/video/fbdev/geode/suspend_gx.c index 6c0a526ee8a2..2fa20acba62e 100644 --- a/drivers/video/fbdev/geode/suspend_gx.c +++ b/drivers/video/fbdev/geode/suspend_gx.c @@ -21,8 +21,8 @@ static void gx_save_regs(struct gxfb_par *par) } while (i & (GP_BLT_STATUS_BLT_PENDING | GP_BLT_STATUS_BLT_BUSY)); /* save MSRs */ - rdmsrq(MSR_GX_MSR_PADSEL, par->msr.padsel); - rdmsrq(MSR_GLCP_DOTPLL, par->msr.dotpll); + par->msr.padsel = rdmsrq(MSR_GX_MSR_PADSEL); + par->msr.dotpll = rdmsrq(MSR_GLCP_DOTPLL); write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK); @@ -43,7 +43,7 @@ static void gx_set_dotpll(uint32_t dotpll_hi) struct msr dotpll; int i; - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); + dotpll.q = rdmsrq(MSR_GLCP_DOTPLL); dotpll.l |= MSR_GLCP_DOTPLL_DOTRESET; dotpll.l &= ~MSR_GLCP_DOTPLL_BYPASS; dotpll.h = dotpll_hi; @@ -51,7 +51,7 @@ static void gx_set_dotpll(uint32_t dotpll_hi) /* wait for the PLL to lock */ for (i = 0; i < 200; i++) { - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); + dotpll.q = rdmsrq(MSR_GLCP_DOTPLL); if (dotpll.l & MSR_GLCP_DOTPLL_LOCK) break; udelay(1); diff --git a/drivers/video/fbdev/geode/video_gx.c b/drivers/video/fbdev/geode/video_gx.c index 5717c3356949..b2cfadaf3ff8 100644 --- a/drivers/video/fbdev/geode/video_gx.c +++ b/drivers/video/fbdev/geode/video_gx.c @@ -142,8 +142,8 @@ void gx_set_dclk_frequency(struct fb_info *info) } } - rdmsrq(MSR_GLCP_SYS_RSTPLL, sys_rstpll); - rdmsrq(MSR_GLCP_DOTPLL, dotpll); + sys_rstpll = rdmsrq(MSR_GLCP_SYS_RSTPLL); + dotpll = rdmsrq(MSR_GLCP_DOTPLL); /* Program new M, N and P. */ dotpll &= 0x00000000ffffffffull; @@ -167,7 +167,7 @@ void gx_set_dclk_frequency(struct fb_info *info) /* Wait for LOCK bit. */ do { - rdmsrq(MSR_GLCP_DOTPLL, dotpll); + dotpll = rdmsrq(MSR_GLCP_DOTPLL); } while (timeout-- && !(dotpll & MSR_GLCP_DOTPLL_LOCK)); } @@ -180,7 +180,7 @@ gx_configure_tft(struct fb_info *info) /* Set up the DF pad select MSR */ - rdmsrq(MSR_GX_MSR_PADSEL, val); + val = rdmsrq(MSR_GX_MSR_PADSEL); val &= ~MSR_GX_MSR_PADSEL_MASK; val |= MSR_GX_MSR_PADSEL_TFT; wrmsrq(MSR_GX_MSR_PADSEL, val); diff --git a/include/linux/cs5535.h b/include/linux/cs5535.h index 5ec2aca537bb..fef236cab7d8 100644 --- a/include/linux/cs5535.h +++ b/include/linux/cs5535.h @@ -51,7 +51,7 @@ static inline int cs5535_pic_unreqz_select_high(unsigned int group, { struct msr val; - rdmsrq(MSR_PIC_ZSEL_HIGH, val.q); + val.q = rdmsrq(MSR_PIC_ZSEL_HIGH); val.l &= ~(0xF << (group * 4)); val.l |= (irq & 0xF) << (group * 4); wrmsrq(MSR_PIC_ZSEL_HIGH, val.q); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:50:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:50:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415901.1645103 (Exim 4.92) (envelope-from ) id 1x4w24-0005kR-Kk; Fri, 11 Sep 2026 07:50:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415901.1645103; Fri, 11 Sep 2026 07:50:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4w24-0005kK-Hb; Fri, 11 Sep 2026 07:50:48 +0000 Received: by outflank-mailman (input) for mailman id 1415901; Fri, 11 Sep 2026 07:50:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4w22-0005kD-VW for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:50:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4w22-004snG-8K for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:50:46 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3b2cf-e002-0a2a0a5209dd-0a2a4507c8f2-18 for ; Fri, 11 Sep 2026 09:50:46 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3b2d6-b4ea-0a2a45070019-d155dd35cd74-3 for ; Fri, 11 Sep 2026 09:50:46 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-486e835acacso499148f8f.1 for ; Fri, 11 Sep 2026 00:50:46 -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 ffacd0b85a97d-486f0403125sm1955286f8f.8.2026.09.11.00.50.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 00:50:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789113045; x=1789717845; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=c2vLgPFKXyyrMXYsnigpCGdDaKtmRW6w5A9CKZTiR9M=; b=D2p5m08GojCCUlIqZgInRzXqlliVXWk/Sp7MCIjxZzYqNdcipGqbrcZcUlm0Ar9hYS iNRiITdAQwHFOpkhbfmjVWqTqef6JDVdEivzKIf5G3MXEuMOKVtv3tC9T6odieJtZWse Qi4pQA5/+DZEtBZejx5uVo+i7RGBl3evxAXgN8FlaP3xq2PTe4SheFAOwHkzDJ29I2r6 6SzcDtretKkkq9AZV1MgWrLv4dbZUZ9ENTfClqsYZyaaqeBrZoc4+2W0dxjjvKmv59Ms +4SMokJ9sia7/RUIYkRJAVajAAaWzukIcQh+VY63ASNqsIbfmQ72muCEwlRXdfEguPvs Y0Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789113045; x=1789717845; h=content-transfer-encoding:content-type: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:content-type; bh=c2vLgPFKXyyrMXYsnigpCGdDaKtmRW6w5A9CKZTiR9M=; b=pWqj03UWdiMTPO8y1mdBmW0p1HnWxzotcmaLrPOFp+i+hsNOXp1LQFZx/VLcnvi4kS C2DwCZmyYqN1CfApBaOzI7wT5slcVnMEL6mnY5Mkww1Qw1n97PUt2FofniruUycAeDgn jmDIUJi8jV0LuTz3ZJds4vSaUoxQQu88foxAuqlmq37akDvoxTLy2HfgPAE3XNErpf8O XbQ5brPeDu8QYXkD+7epFj6rOhN8t8QvKD4PLF4xniGzWkNxVYTo8TdsZL02FXuJ4tGe oWfcxtWKeapwSLHZHj3d7lvT6r5cVLZ2zYDxEtXlUu51LtQ0XxqI1Kmp6KVUlRYKeGzW YrFA== X-Forwarded-Encrypted: i=1; AKwUvByyZuhDNdcO9KiJE2rT32/hOIP9y1GJLS+2iydJBQz21BS7dX4zMvpYKi73+icRbPi2vS4WnF6bOZc=@lists.xenproject.org X-Gm-Message-State: AFuF++lP8iCe+3zKg6ZoLhuW8WTwTlCmCH0WB6HBDpbYaXBxyDKMsizU x6K2kCMMZiU5pxmZf9YDm3TuQET48c+pDIRo/az62SJ2yfY8apJcoBIGLPKGa4FtkA== X-Gm-Gg: AYBFou1sJgErcBDD4nopoQ2eEPCtfw1d3sMGwe0Firz5fNhbdaGWkNNl1N+ZzZ5AA0H 7hrVjAmN+OCV2cWcoiB4WT/JgwM4sq6WyoE+g5YlxPxQn36ej0aJczol3RTPTj2NUr3UpnLCsvj waGF219HyEwUKNh6hoYYO7+jrJV2vkLBZ6q3NUlVXq6WEvCQtMqMEqmj8NQChvzUMl/pUJrMhTL 8uls6kMu9Calr1CaW4ZpN7v527lk9qzfAQswUTc58XnjCYfBMMfMjtiSax/aLG8ZqOJ+Qm+dRSu hgU9gHDLFGZ7jjnsnSB5ZoE2lRrfVVg6npWIQ2iEI1+ive2/eJ5SMtG1UWtgvizjpvlbPxSY8PR MNgitwqve+HffDQLykHA2F3lJBXogd8NWK6q1/wjP/fNMPYwOKdF6dNFucTx2HAE2UUhtxWszDT bMORm2ohyPiJ/+W7whDjO8ineu6DCme5c/sn8JVf+ivb2LdHd3FKD+QALKqpuBNmO/+F6X9/9wD yLjbPk8Ievy3S3QCHHxf84Kif8w9Dq7bOpnAmfX0M8YQWld0JVSKcixpOZdBIsY X-Received: by 2002:a05:6000:2005:b0:486:e8ff:90f4 with SMTP id ffacd0b85a97d-486eb2e3b62mr3529822f8f.3.1789113045540; Fri, 11 Sep 2026 00:50:45 -0700 (PDT) Message-ID: <1d8be2c2-a56d-4b81-8e36-c4f97099c879@suse.com> Date: Fri, 11 Sep 2026 09:50:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <6bf8f9dd61da4d0fbea096b863f51db08df46c56.1789055542.git.oleksii_moisieiev@epam.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: <6bf8f9dd61da4d0fbea096b863f51db08df46c56.1789055542.git.oleksii_moisieiev@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789113046-374D3AE4-8D3D949B/0/0 X-purgate-type: clean X-purgate-size: 2965 On 11.09.2026 09:26, Oleksii Moisieiev wrote: > Introduce memcpy_fromio() and memcpy_toio() helpers to copy between > regular memory and MMIO space on Arm. The generic prototypes live in > io.h so other architectures can provide their own implementations. > > These helpers handle alignment safely by using ordered byte accesses for > any leading/trailing unaligned bytes and ordered 32-bit accesses for the > aligned bulk transfer. That's over-simplifying things (just like code comments do). If source and destination are equally misaligned modulo 4, what is said is true. If they are differently misaligned, the entire copy will be done byte-wise. Which can easily be a problem when 4-byte accesses are required for particular MMIO locations (which may e.g. actually represent device registers). As said on earlier versions: I think you either want to get misalignment handling right for all possible cases, or you want to demand aligned incoming pointers. (Ftaod, using byte accesses for two or three leading / trailing misaligned bytes can be equally wrong, when the MMIO location accessed wants to be accessed with a 16-bit load/store, for being e.g. a 16-bit device register. Similarly using 32-bit loads/stores can be wrong in the general case. IOW while some of that is said to a certain degree, I think there are unmentioned further constraints on when these functions may safely be used. For example "devices that tolerate 8-bit and 32-bit accesses" is still ambiguous as to what exactly it means. Not the least because "tolerate" doesn't mean "work correctly with".) > Using the ordered `readb/readl` and > `writeb/writel` accessors avoids unintended endianness conversion while > respecting device ordering requirements on ARM32/ARM64 hardware that may > not support 64-bit MMIO atomically. I'm having trouble making sense of this part. Why's endianness of concern here? The accessors used don't care about endianness at all, and what may have (wrongly) been used in earlier versions shouldn't matter here (or it would need calling out which other accessors would be wrong to use). > --- a/xen/include/xen/io.h > +++ b/xen/include/xen/io.h > @@ -67,4 +67,14 @@ static inline bool write_mmio(volatile void __iomem *mem, unsigned long data, > return true; > } > > +/* > + * Copy between regular memory and MMIO space. Implementations are > + * architecture-specific and must use appropriate MMIO accessors for > + * their memory and I/O models. > + */ > +void memcpy_fromio(void *to, const volatile void __iomem *from, > + size_t count); > +void memcpy_toio(volatile void __iomem *to, const void *from, > + size_t count); For somebody wanting to use these functions and merely looking here, how would they know of all the constraints? That is implementations are not merely arch-specific, they may also impose arch-specific constraints. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 11 07:58:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 07:58:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415915.1645114 (Exim 4.92) (envelope-from ) id 1x4w9Y-0006Th-Dc; Fri, 11 Sep 2026 07:58:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415915.1645114; Fri, 11 Sep 2026 07:58:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4w9Y-0006Ta-8G; Fri, 11 Sep 2026 07:58:32 +0000 Received: by outflank-mailman (input) for mailman id 1415915; Fri, 11 Sep 2026 07:58:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4w9X-0006SL-6o for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 07:58:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4w9W-000VaJ-Jn for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:58:30 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3b4a4-8faa-0a2a0a5109dd-0a2a450aaf80-2 for ; Fri, 11 Sep 2026 09:58:30 +0200 Received: from [40.93.195.40] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3b4a4-f2d2-0a2a450a0019-285dc3287cea-3 for ; Fri, 11 Sep 2026 09:58:30 +0200 Received: from SJ0PR03CA0172.namprd03.prod.outlook.com (2603:10b6:a03:338::27) by SJ2PR12MB8944.namprd12.prod.outlook.com (2603:10b6:a03:53e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 07:58:25 +0000 Received: from SJ1PEPF000026C3.namprd04.prod.outlook.com (2603:10b6:a03:338:cafe::6f) by SJ0PR03CA0172.outlook.office365.com (2603:10b6:a03:338::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.6 via Frontend Transport; Fri, 11 Sep 2026 07:58:25 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000026C3.mail.protection.outlook.com (10.167.244.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.5 via Frontend Transport; Fri, 11 Sep 2026 07:58:25 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Fri, 11 Sep 2026 02:58:24 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.46 via Frontend Transport; Fri, 11 Sep 2026 02:58:23 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KNc0T6TVMcz6RM/cLpQ4d6nwqTCCYZEroq3aFvHauV7qakFi5ZqUP+R1EmaQcwI5+OZJ/3rrWpOsbG9ijIeMwBBw3sIdxkZCa6T9oI6qYY4flS0asPVa3zzXbAA7cXVbonUb+R1dWdoP5lqVp5B00oMfaVetGuApMJFqCD2JkXDkevXCxoeCBpra4s7CDjyovfi2cVAen0PP+jiD4nt7HuHNGxwZE098PcyoJZrAZQZ2R9KWdPiRIbtWjTepi9jwuyPz1/Towzvk4tkq6c+MhrRJeDnLi17F2aHTzH0RY1M4g9IOAc7AwaaI9Ws8A0yjDzxmIvqNmDiofFXKwPLg5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4D0UCDSldlI+bfLGmqYPvawtPB+ljyuKptP3kiiIqOU=; b=o/qdL8VYTnmF94zUexmMU0/zQxRT+/rmKjXNoHE4WJWBhvoG4n85OpQxiVeMLfsk1FrRcoMPxp+MLPrweAO2eXo8y/UlMCpj1zdtpTHKQPLfEjejkt1NC7O1Nn6m089CRCS+KIj1AqiN0RZMyW45Vslu6Qyx5dcwy0mlYFjkIeH9cSbhPTpk6awNywprB6QjRb0Zm8JfzCQhtXpQeLA0NNQ1CFeWLgewmO/8liDSGWhYxswknmFUgzi/lsR6WZcUc4GSPs+TI5UcLjNHYXIVXtO+5Ztf4Qthd5yhoO9JFFIvr5mz0fyM3Q8ppuy0a7QdCNM+iHyS+D9K+4XPm4RYbg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4D0UCDSldlI+bfLGmqYPvawtPB+ljyuKptP3kiiIqOU=; b=28pfF4h54FkvrOSleC5GtyOk3ORU7cmdxcFFy9dNFMnmDP0/wFZqHH8IxFaeQrAHcAldUs3vIjnCrTP3c7BC6hD+sHJogi0/ET7oghXbnFTCkKsEz6gKtpnJL5px2KH7KV11AN31clZPhVUcHmnnGftR6Ok71RqQqrL8215386s= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Fri, 11 Sep 2026 09:58:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] common: dom0less-bindings: introduce XSM labels To: Sergiy Kibrik , "xen-devel@lists.xenproject.org" CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , "Daniel P. Smith" , Andrew Cooper References: <20260909085707.2359322-1-Sergiy_Kibrik@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260909085707.2359322-1-Sergiy_Kibrik@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000026C3:EE_|SJ2PR12MB8944:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f718cce-4112-46b1-5306-08df0fda7530 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|82310400026|23010399003|36860700016|6133799003|56012099006|10067099003|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: DdJTLs/JkImbyqJPNtnzuEYli00XBQ+D33lcG3jZSm46b/6Rx0LH58nWfA6s5eIsgbe0kOsEhHVN6xEvaJNZw+JIaaascU3UxSyJu6Rl0B8yn2VCCLZ1TN5mJXotfLFJq801o/RlvOpSR6ozE8L9RMTnWM7CWae7akCEqZGMLg/Q42Uud/5bZ7gXJ5AL4aSzI6gewHhw5OHvr5dfQolPa1JMx/SiMBpeiTZvSmv+s06Ff68wsoJUfbs8X0n2T+1WGl/pucpJRtoN6z4LopMSKp+j3Sw+uUrUmn1vM2wWde2j1u7SYD2jT4K6Hutry85STR/mvboHbfMljn0XnDOVErmITGvt8uSfCl/D3l1cj2vEarDVIaVp6pq00CsSAJa/CVXyCD7e3/FL/TT80CHYOLV7jO9NhZSlqG1F0voRQuU3mcZgmBx/E3QLW7nboNtBF7DVDU/pXaavGHvuNAAjEz9FQsKT4BU+By75HWegzMoJtzVbQ8wRA+YRlOi40jttHK6vZJuWtSl2v3HnC/rPrZlG/URB14NYgxfeXBRiHZ4D0Q5EOhU/7HcKH72JJhxe4WL/ekapSuUv/8/CgawraEetHxzHF+X5HSvsVUDFo3gNVkOhtoSRmEqviJwjR/MKKG/6P2Lcgw98DBi6vMELwEay3GxxhN1oXLgAaj/fM2meb4JmiTXker29onncJgpLcXs903XAl/f7TBdWIwBM2Q== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(23010399003)(36860700016)(6133799003)(56012099006)(10067099003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: C9WhHuTUKc1Vpt44P3b+rhZI03LH0xeG+fzKiv4N1aOzLHVZz71AiIX0rcI3u9caiyTixlDom1zgUW/BzPukIYKvzzKblp5mpCd+JnyHDfzY4MJGgqHkuBNxd1d/lL93nkxzF2QnwWLN3FRRIIDi/BR/z8QTn7Y4WduqI5s4yJ6cFJW7lnWkpExmd9ux7OE1I+Lcn9jZLtBiee6K78vx813MkkDEPPZOYE8mnRU3ZMs2adpX5oqlhMwG6fvc2fP+w5ox6dFwNBU4hRK+M2sUSgdoi73ECnGcfNNfJvi59Rg8crVIwGvKn7XZF+ZOhIsUXGi6EHwYitUK8M8KsZ1wAgXkkvbq+szuXmPJHz+kSjryqsJsprY0vjtmnr50dGsht0nwjzYuo5N/0WtRrFB3s23Jc1FUilK/SmlQ7oT2ATo+bXM47Zh7nMhQeTZlg4DU X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 07:58:25.2024 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4f718cce-4112-46b1-5306-08df0fda7530 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000026C3.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8944 X-purgate-ID: tlsNG-4011c0/1789113510-508CDCFC-8F834504/0/0 X-purgate-type: clean X-purgate-size: 3996 On 09-Sep-26 10:57, Sergiy Kibrik wrote: > Add "seclabel" property to be able to specify security label for a domain > when XSM Flask is enabled, similar to xl configuration files. > > Currently guest domain can't be created by Xen in dom0less configuration when > Flask is enabled, as domain is assigned "system_u:system_r:unlabeled_t" label > by default, which Flask denies to create according to current policy. > > Because code from outside of flask can't directly execute its internal API > a new routine flask_context_to_sid() introduced as part of XSM API exposed > to rest of Xen, which is a direct wrapper for security_context_to_sid(). > > Signed-off-by: Sergiy Kibrik > CC: Daniel P. Smith > CC: Andrew Cooper > --- > changes in v2: > - add & use flask_context_to_sid() wrapper > --- > docs/misc/arm/device-tree/booting.txt | 8 ++++++++ > xen/common/device-tree/dom0less-bindings.c | 11 +++++++++++ > xen/include/xsm/xsm.h | 3 +++ > xen/xsm/flask/hooks.c | 5 +++++ > 4 files changed, 27 insertions(+) > > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt > index bcb06bc796..fcc7be0ffb 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -345,6 +345,12 @@ with the following properties: > not passed. This configuration requires static allocation (xen,static-mem) > and direct mapping (direct-map). > > +- seclabel > + > + A string property specifying an XSM security label to this domain. Effective > + only when FLASK is enabled. Domains will be classified “unlabeled” if For "Effective only when FLASK is enabled" see below. > + this property not specified. > + > Under the "xen,domain" compatible node, one or more sub-nodes are present > for the DomU kernel and ramdisk. > > @@ -422,6 +428,7 @@ chosen { > memory = <0 131072>; > cpus = <2>; > vpl011; > + seclabel = "system_u:system_r:domU_t"; > > vcpu0 { > compatible = "xen,vcpu"; > @@ -453,6 +460,7 @@ chosen { > #size-cells = <0x1>; > memory = <0 65536>; > cpus = <1>; > + seclabel = "system_u:system_r:domU_t"; > > module@0x4c000000 { > compatible = "multiboot,kernel", "multiboot,module"; > diff --git a/xen/common/device-tree/dom0less-bindings.c b/xen/common/device-tree/dom0less-bindings.c > index 41d72d0d58..0b0ed6e25d 100644 > --- a/xen/common/device-tree/dom0less-bindings.c > +++ b/xen/common/device-tree/dom0less-bindings.c > @@ -11,6 +11,8 @@ > #include > #include > > +#include > + > int __init parse_dom0less_node(struct dt_device_node *node, > struct boot_domain *bd) > { > @@ -21,6 +23,7 @@ int __init parse_dom0less_node(struct dt_device_node *node, > bool has_dtb = false; > bool iommu = false; > const char *dom0less_iommu = NULL; > + const char *xsm_seclabel = NULL; > > if ( !dt_device_is_compatible(node, "xen,domain") ) > return -ENOENT; > @@ -141,5 +144,13 @@ int __init parse_dom0less_node(struct dt_device_node *node, > panic("'llc-colors' found, but LLC coloring is disabled\n"); > #endif > > + if ( IS_ENABLED(CONFIG_XSM_FLASK) && > + !dt_property_read_string(node, "seclabel", &xsm_seclabel) ) > + { > + if ( flask_context_to_sid(xsm_seclabel, strlen(xsm_seclabel), > + &d_cfg->ssidref) ) > + panic("Invalid security context for domain: %s\n", xsm_seclabel); > + } The preferred way (you can look at e.g. SVE, SCI, LLC) is to stop Xen if a property was found whose functionality cannot be satisfied. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Sep 11 08:15:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 08:15:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415941.1645142 (Exim 4.92) (envelope-from ) id 1x4wPQ-0002jx-4T; Fri, 11 Sep 2026 08:14:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415941.1645142; Fri, 11 Sep 2026 08:14:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wPQ-0002jq-1N; Fri, 11 Sep 2026 08:14:56 +0000 Received: by outflank-mailman (input) for mailman id 1415941; Fri, 11 Sep 2026 08:14:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wPN-0002jd-OD for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 08:14:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4wPL-001TpH-AE for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:14:51 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3b877-8faa-0a2a0a5109dd-0a2a4505bb5a-22 for ; Fri, 11 Sep 2026 10:14:50 +0200 Received: from [52.101.228.130] (helo=OS0P286CU011.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3b878-4cb1-0a2a45050019-3465e4828361-3 for ; Fri, 11 Sep 2026 10:14:50 +0200 Received: from TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:af::12) by TY4P286MB6426.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:33a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 08:14:45 +0000 Received: from TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM ([fe80::2067:ff0e:4c3:ad0b]) by TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM ([fe80::2067:ff0e:4c3:ad0b%5]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 08:14:45 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=m89xnvwaSFmj/ZIKPZYPv4fWfhR236ZqAyg9xR3aDXn24LmOMTbyP1Qt0nNHXLz3M/NIqZmXxs6yW1TuOVJq2Va7rCBBBFk68aPWkFkiHQjDOx5i9ZsKjDdkqaavcsPvfAGgN07os2E+hkZO/MmP/Swkk1AOtEevL1XZGiuUkHBWB6OhjrPDdXVFsz3E0DTk0RQN+yDM0t0VpQt2IufPZRZ4hWlvddY8iDqo3S0oDBj1yUWg1oSDQ8Cdyw0comrTjWavPR9Z3oTJ8iOvb83fDi4qKlyjlI5WKcoLyPerxPOm24GN+gJCOavM6F3gBtM2rt1ITi4D5juMvqVFgVCkFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8/RdIz3FwChimoBZoyKFPw9Aj/VFpl/IZC7XOrK7vow=; b=nlvb8YcGoo9505vn3oGiLuAeMsOCJM5GAGgOItB9zBQl74RLwcek6e5IXPU6FA07PBp7RRdWqGjWVD+ijCXjHSmab0VfKLNFWMl4d4gBz/+jKzVGtABEOOwXZzMnU/vrIjm7w04peqom54hl9r4BkB86Jtdngif9HegKOOzT67YZiQkAEuwhENDZA7AVM81UiwEcaw1+JFsCNpojc6TiQkpyOh35tyovYjZi9lm6kWsiIbqkmJ0rWNAHKWMkIxmeeDu1ljCHjIrU5Vj1Lk+NUYFLlqji/GP4mGcAm05dqLJ5mSlMJtwbiVFTBdY89+L5k7CkHVrQ7meheiIUegTCEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/RdIz3FwChimoBZoyKFPw9Aj/VFpl/IZC7XOrK7vow=; b=oOBZhKotnyLVvOfNTxZ8VeWX+DGGQrPTsZ2mOTn7C6yStZUrnGXvePIaSsqiQOAzSHNFtsfZDplwfx/YCSyOM/H39YEbl8GwTyb2t+BSJa8DqMIlKhPIMj3FAcAhsGxvzb7ByTfHuItvo2mdjZvEe+FoH1Zd7ucU2bcgzvD5MzM= From: =?iso-2022-jp?B?GyRCMixLXBsoQiAbJEJOQ0ZzGyhC?= To: Julien Grall , "xen-devel@lists.xenproject.org" CC: Hirokazu Takahashi , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v2] xen/arm64/atomic: Clear exclusive monitor on cmpxchg failure Thread-Topic: [PATCH v2] xen/arm64/atomic: Clear exclusive monitor on cmpxchg failure Thread-Index: AQHdQCJBEKmlsPmU00mRFpT1XSXe0LbF1F0AgAMw5Ro= Date: Fri, 11 Sep 2026 08:14:45 +0000 Message-ID: References: <20260909061253.546312-1-okamoto@valinux.co.jp> In-Reply-To: Accept-Language: en-US, ja-JP Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: TYCP286MB1053:EE_|TY4P286MB6426:EE_ x-ms-office365-filtering-correlation-id: 861255ed-ae05-4dae-6461-08df0fdcbd3b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|1800799024|23010399003|10070799003|366016|376014|6133799003|22082099003|18002099003|13003099007|8096899003|38070700021|56012099006|10067099003|4143699003; x-microsoft-antispam-message-info: tx2wQF65NAUW2zpfjctv6+VN/HYwAxFmcldsmlDf7aXJkN6VPROzWEMidpwf70ayIs4o4tu7f3hC8B8HxZzii9JIYMSmgRATFTtgkf6BaXV+vUn/itTNFCn59aXSG607xAcPB5pmarxpbEasB3mx2ebVaHxrPy9ctWl9Q2fFDTQiTVJR++HDbr1qd+npdp5XfH3QnfRmCvTu4CS59FmQZV7LLvOX7EIFSz/ftOBMNGj3y0H3AwQ17WtR8E+SohXmS+eZSKbjuxgaspjXAoCLFQfZc9e2BQLFHP6B72dmRIhITpxeFeJmLUkI53km5mO7bFZuEL4fePgm1QB28dBMGaMzR30lOlU4peTFOrbUJX9pyaCjCP9CPb6ntV1Mn600bC0Ub3Vy3l6jm5Co6h9AgqLHqnm8+fqVVOzQUVOLSNReJ0hehV9QjlNQDgHd5TpwON5KVUvsbu9s+P0wQ+jKjmLIIpKxCQSSUpMsS0EuB8b8H5kGpeQWu0UMzk/gv4bZHXE3N1CUlUCoIjFBe4NNX5EPx59Omas9RT4EoTd7UnsrGKe6FJ1DH4j4QFeGiwZpyMTG23XL0SrpbrAcwZUlhaVgO1MjB+Jkeo8MicSf8LnCxmkExe7wlP/l0e4axndPzQmo68HE1CzMlEoz9xvJJ8OM2ZVUOijxVTdFjtt1jiE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(1800799024)(23010399003)(10070799003)(366016)(376014)(6133799003)(22082099003)(18002099003)(13003099007)(8096899003)(38070700021)(56012099006)(10067099003)(4143699003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?V0JzZHJrSWM0aGV0NG1TWE4wZ09zU2dVcm9obDhheEdnN2tyUG1mUG0r?= =?iso-2022-jp?B?dGpBSW45OU54ZUFPaHhsK1lKWEsvMzNDT1ZwOE5seHVEY1IyNHhobjFB?= =?iso-2022-jp?B?ZmVhMWJzRzRidWN1NjlXTEx5eFVYTk5rNUZqNEk2YWladHBWNlBRR3lr?= =?iso-2022-jp?B?R3NyS2RVTWNZYVVmaFNuQkZFa1hkYTN4M3pjUEFLeTNUdmE2VkdBYU54?= =?iso-2022-jp?B?V24vZVBCN0Z5eUdKRDZTUVlKNStDb1JYdjFqQUdzRVBqck1Hc2ZxRlA4?= =?iso-2022-jp?B?ZjJJOTNPSGlkM0N2OWRONDBNWURDTng4anhUZisxTHEreG9xR3lWSk9a?= =?iso-2022-jp?B?SHQxNkE1MEZPZUNqKzFTYjlHZCtQNHphSjkxa1VvVGk2OW5sYTVDVUFj?= =?iso-2022-jp?B?dFB1QWNoeTNZaUpGeXg2Mll0NGJQbTZGa2JYNUJBTVlMd2NheEtkM0ZR?= =?iso-2022-jp?B?R0RUTkpyaVF3TkRsZWYvNmhuZk9mdnIweWJrUUJ6TEN5VkN3eERySUxD?= =?iso-2022-jp?B?NU44T3lTcFFqb0lqMDlvMnlPZkRyNExOUFJBZVVmOVc4NWZjbCswQXQr?= =?iso-2022-jp?B?NFQ1WmlPUGFFQ21GQXdJY1d2bUZZL0N0VXdFNzdxYmY3RXowSGZVSXpY?= =?iso-2022-jp?B?VVF5M1pjTXB0a0ZNa3RvanNQUU02Wlk1aHh1VlhpZEdpdFp6dVROZlFG?= =?iso-2022-jp?B?R0M4azU1RGtZZU8rc2VWdlM0STNmZW5uMVVBdXlnbWR2YzRrZld5enN2?= =?iso-2022-jp?B?QXFrcVBJK2VsS21mNWYxdjFpcUg5QzRKbW1QcnkwZldwaWU5ZWRGVHpt?= =?iso-2022-jp?B?bmFmS1NKY1BJMFV3UWlqNWhrWGNpS2RrL28wZTZyU0JES2krNFIvVU9o?= =?iso-2022-jp?B?N1FLVzhHU1dnOFJYSDYwVFVWYW0rQ1VLUFBmOXdBWEI2NDJGdmtPTXh5?= =?iso-2022-jp?B?L2tOaDFPbzlLVkRxcnJrVERvOEwyMW9BNnk2L2NnWTVDOERXcHFPNlJw?= =?iso-2022-jp?B?S0dvVGd3VWlPZkpaRm42VTFBWTlxY3VPdlJYaUU0VGF6Sk1GYm1KNWtC?= =?iso-2022-jp?B?Ky9rTU5rMURSWStEcEJZbHArdWJLWTZYbDRKRUR5aUlvdWFpTWRXUmZ5?= =?iso-2022-jp?B?VVVlRjFQR2QwdURaa3h3bEFKbVRKUHNsdjllM2lIWm16SDVFZjdDc3FT?= =?iso-2022-jp?B?UWQ0dUhKR0xUdkZUdkFTSHdEL2N4LzVNZFg4aE1Ed1AvQkEveiszUDM2?= =?iso-2022-jp?B?Q2d5N2xJcVlzd0ROdVF3ZXl5bzJoMjFJT21PdlVoa2EwWDN1QTkxVXox?= =?iso-2022-jp?B?UW9NZnNNaFBmbVA2ZG1IdkxXRHlhajJjdS8yMDVXRDI5QUI4Z1dEV0M0?= =?iso-2022-jp?B?NGE1K3pGUXFJQnJVdTcyYnV5b0pWSHd5OXc3K01pdlFHR1hoWXRaTlk2?= =?iso-2022-jp?B?WGFpVkRoT2lHcFlSSlJZcnFOcStJRnF1clVJYUxEaW9TY0ZwOWhpV0dY?= =?iso-2022-jp?B?QmZxY1A5dkRUaVVReDZQN2hzZGRCSkJXL2Q3V08xZHdZa1Mva3hubm1H?= =?iso-2022-jp?B?bFVVN01QTGFwdm40WTMvMERMdXFLOGpCc2dFRDhVcFVWeG04QWRjK0RN?= =?iso-2022-jp?B?TFRLZ25kdEplZ1dzY0hVWndFRzlRZU04eU1WRkUyUmNXN01ySlBGQzlU?= =?iso-2022-jp?B?aTV1MW1VTDZ4cHdPNlNDbEpTS1lONUtKOW4wbE5QcW1pa1dzenZid3Nk?= =?iso-2022-jp?B?c01QbUZ6aW5wUjl2VGNJYlc4WDBiR0liZWJOamdubFhwTWR2U3lkOEt3?= =?iso-2022-jp?B?MUk1TlJVNENHOFQwMTNrWExVYzJEeklBNWpFdUFOYmRObEx5QjV6ZGhy?= =?iso-2022-jp?B?SHhSNjAzZFovbG4rVlh4WlhwN0FrdlNTUDdkZFZ4dHlFZzcybVRicHdY?= =?iso-2022-jp?B?ZFFkU1h2T282WHBMbXNVTHJuaUVTZ3R4R0lHSnVuUHp0WFpZbXRBdDhp?= =?iso-2022-jp?B?N3BSYW1sWXVJK2l5cU1EZ2Y3OUU0S1NNQzNiU2ZzOEtIUVh0WHJrbXZ2?= =?iso-2022-jp?B?Y0pqN25rUnRrcDI0cmlDVE5UWThxQWg3WUFsdXNsbGdsNVJyTzg0Z0Rz?= =?iso-2022-jp?B?RFBTdVdMakRmcmxxZ2NRcXBEL0JkK1VwQVJFMGJaZXdjaFhESHA4dS9B?= =?iso-2022-jp?B?emhGQ3JQSkJ6MEdxTXE4dFk0b1haVVNHQTBkbzZ6V012TmFQTU9LSFlh?= =?iso-2022-jp?B?MitCQzQ4NkFqNW4xbjZCR29TaGN1ZWpWdnVHQldiZnU4ZWJQZ2JoQWh5?= =?iso-2022-jp?B?N3JRcVgvS0FoUGc1Q2JJK240NE93VS9jYUM3V3pwcm5ja3o5d25QQVpr?= =?iso-2022-jp?B?RzM1VmppNTcwa0VJZmRDMkwvZkhRVU1DdWt1N3o4VWVmaW5DNms5Wmgv?= =?iso-2022-jp?B?SzVPNjVScEdiek5hbk9GMG1yKy8wbFJpTW9aZmg0RDBNQjB2SWp3djZi?= =?iso-2022-jp?B?aCt5SmVmd05zeWYrMEhQcDZqSW50LzJvSC9HOE5ETC8rWFFOdEtXSkxm?= =?iso-2022-jp?B?UEM1YkhIaFN5QVRnbERRN0crNEc3QklBS21Rcg==?= Content-Type: multipart/alternative; boundary="_000_TYCP286MB105323785D7FE4C021C8B886E1BE2TYCP286MB1053JPNP_" MIME-Version: 1.0 X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 861255ed-ae05-4dae-6461-08df0fdcbd3b X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 08:14:45.1746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3l2WvcmaCORjdjnvRxl5dWZ44xSf6lpDu1Ha/WrmXqxXhVwChhU27ASL/2VA7U5lhux5meS5Kr2GhA8S0VENhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY4P286MB6426 X-purgate-ID: tlsNG-c201ff/1789114490-251182A1-7920239D/0/0 X-purgate-type: clean X-purgate-size: 9440 --_000_TYCP286MB105323785D7FE4C021C8B886E1BE2TYCP286MB1053JPNP_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Julien, * The Xen atomics operations were originally taken from Linux. Looking at the= implementation there, I don't see a clrex on the failure path. Do you have= more details why we would want it? Thanks for pointing this out. I revisited the rationale for adding CLREX here, and I don't think there is= a sufficient reason for Xen to do so. I found a rejected RFC^[1] in Linux in 2015 to add CLREX in atomic operatio= ns. In that RFC, Linux arm maintainers said there is no need to add CLREX. I also found a patch^[2] that makes LLVM emit CLREX on this path, with the = rationale that keeping the monitor set might have a negative performance im= pact on some microarchitectures. However, I have not been able to find conc= rete microarchitecture-specific evidence or measurements demonstrating such= an impact. Please consider this patch withdrawn. Thanks for the review. Regards, Ryoji [1] https://lore.kernel.org/linux-arm-kernel/1425016026-19766-1-git-send-em= ail-bobby.prani@gmail.com/ [2] https://reviews.llvm.org/D13033 ________________________________ From: Julien Grall Sent: Wednesday, September 9, 2026 16:10 To: =1B$B2,K\=1B(B =1B$BNCFs=1B(B ; xen-devel@lists.= xenproject.org Cc: Hirokazu Takahashi ; Stefano Stabellini ; Bertrand Marquis ; Michal Orzel ; Volodymyr Babchuk Subject: Re: [PATCH v2] xen/arm64/atomic: Clear exclusive monitor on cmpxch= g failure Hi Ryoji, On 09/09/2026 08:12, Ryoji Okamoto wrote: > When the value comparison fails in atomic_cmpxchg, the code branches > out without executing stxr, leaving the exclusive monitor in the > exclusive state set by ldxr. > > Add `clrex` to the failure path to explicitly clear the exclusive > monitor. The Xen atomics operations were originally taken from Linux. Looking at the implementation there, I don't see a clrex on the failure path. Do you have more details why we would want it? Also, if this is necessary on arm64, then we most likely we want the same for the arm32 implementation (including __atomic_add_unless()). Cheers, -- Julien Grall --_000_TYCP286MB105323785D7FE4C021C8B886E1BE2TYCP286MB1053JPNP_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi Julien,
  • The Xen atomics operations were originally taken from Linux. Looking at the= implementation there, I don't see a clrex on the failure path. Do you have= more details why we would want it?
Thanks for pointing this out.
I revisited the rationale for adding CLREX here, and I don't think there is= a sufficient reason for Xen to do so.
I found a rejected RFC^[1] in Linux in 2015 to add CLREX in atomic operatio= ns. In that RFC, Linux arm maintainers said there is no need to add CLREX.<= /div>
I also found a patch^[2] that makes LLVM emit CLREX on this path, with the = rationale that keeping the monitor set might have a negative performance im= pact on some microarchitectures. However, I have not been able to find conc= rete microarchitecture-specific evidence or measurements demonstrating such an impact.
Please consider this patch withdrawn.
Thanks for the review.
Regards,
Ryoji
[1] https://lore.kernel.org/linux-arm-kernel/1425016026-19766-1-git-send-email-= bobby.prani@gmail.com/
[2] https://reviews.llvm.org/D13033

From: Julien Grall <juli= en@xen.org>
Sent: Wednesday, September 9, 2026 16:10
To: =1B$B2,K\=1B(B =1B$BNCFs=1B(B <okamoto@valinux.co.jp>; xen= -devel@lists.xenproject.org <xen-devel@lists.xenproject.org>
Cc: Hirokazu Takahashi <taka@valinux.co.jp>; Stefano Stabellin= i <sstabellini@kernel.org>; Bertrand Marquis <bertrand.marquis@arm= .com>; Michal Orzel <michal.orzel@amd.com>; Volodymyr Babchuk <= Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v2] xen/arm64/atomic: Clear exclusive monitor on= cmpxchg failure
 
Hi Ryoji,

On 09/09/2026 08:12, Ryoji Okamoto wrote:
> When the value comparison fails in atomic_cmpxchg, the code branches > out without executing stxr, leaving the exclusive monitor in the
> exclusive state set by ldxr.
>
> Add `clrex` to the failure path to explicitly clear the exclusive
> monitor.

The Xen atomics operations were originally taken from Linux. Looking at the implementation there, I don't see a clrex on the failure path. Do
you have more details why we would want it?

Also, if this is necessary on arm64, then we most likely we want the
same for the arm32 implementation (including __atomic_add_unless()).
       

Cheers,

--
Julien Grall

--_000_TYCP286MB105323785D7FE4C021C8B886E1BE2TYCP286MB1053JPNP_-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 08:42:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 08:42:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415987.1645151 (Exim 4.92) (envelope-from ) id 1x4wq1-0007f6-97; Fri, 11 Sep 2026 08:42:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415987.1645151; Fri, 11 Sep 2026 08:42:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wq1-0007ez-6T; Fri, 11 Sep 2026 08:42:25 +0000 Received: by outflank-mailman (input) for mailman id 1415987; Fri, 11 Sep 2026 08:42:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wpz-0007et-Ow for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 08:42:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4wpy-00DNp9-T1 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:42:22 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3bedf-e002-0a2a0a5209dd-0a2a4509b42a-44 for ; Fri, 11 Sep 2026 10:42:22 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3beee-be1a-0a2a45090019-c387df8380aa-3 for ; Fri, 11 Sep 2026 10:42:22 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 2861B1FA79; Fri, 11 Sep 2026 08:42:14 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 23D9613715; Fri, 11 Sep 2026 08:42:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 731eB+W+o2qzFAAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 08:42:13 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789116138; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qEgI7SvgyOOzaYj/SjcnmBWvZe0hxGWWlUZ9bTgElSY=; b=oSF6WaHPW7OVdfEOZx32oULT7pMtMDhVyaDmumJKSZKhq7hzXJjO26fRH2tmqdXVqnKfrT bU2qrynamVWqYQ7VCJeDuX65UZNg0AYVfZPVofp1F07AaNE4HeC9hgmZJmDo06NZ/o8DG9 b7SWCgIgrpmTfq7xXnjKtYE1STyHSlk= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789116134; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qEgI7SvgyOOzaYj/SjcnmBWvZe0hxGWWlUZ9bTgElSY=; b=FoysridPrct4d9peaV2mGDMhi/buusc59Z5h96JWZ/LtXP0raX6tsqe8nnqQuKGTDl2nqo Bob6CgAb9pLxBS7lpuXQkRl5P+LqboMe4Xmcq4HtMkxhKpNY8rzQutn15ewNhQkP+vn5Vi 8l/P7TU7+qnMYbsLklUPkwvjAOfMBV8= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, llvm@lists.linux.dev Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Paolo Bonzini , Vitaly Kuznetsov , Sean Christopherson , Boris Ostrovsky , xen-devel@lists.xenproject.org, Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Andy Lutomirski , Peter Zijlstra , Xin Li , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Josh Poimboeuf Subject: [PATCH v5 00/17] x86/msr: Inline rdmsr/wrmsr instructions Date: Fri, 11 Sep 2026 10:41:54 +0200 Message-ID: <20260911084211.3149957-1-jgross@suse.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.80 X-Spam-Level: X-Spamd-Result: default: False [-2.80 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.995]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWELVE(0.00)[36]; TO_DN_SOME(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-purgate-ID: tlsNG-bad1c0/1789116142-FC610034-05923D0C/0/0 X-purgate-type: clean X-purgate-size: 4112 When building a kernel with CONFIG_PARAVIRT_XXL the paravirt infrastructure will always use functions for reading or writing MSRs, even when running on bare metal. Switch to inline RDMSR/WRMSR instructions in this case, reducing the paravirt overhead. The first patch is a prerequisite fix for alternative patching. Its is needed due to the initial indirect call needs to be padded with NOPs in some cases with the following patches. In order to make this less intrusive, some further reorganization of the MSR access helpers is done in the patches 2-5. The next 5 patches are converting the non-paravirt case to use direct inlining of the MSR access instructions, including the WRMSRNS instruction and the immediate variants of RDMSR and WRMSR if possible. Patches 11-13 are some further preparations for making the real switch to directly patch in the native MSR instructions easier. Patch 14 is switching the paravirt MSR function interface from normal call ABI to one more similar to the native MSR instructions. Patch 15 is a little cleanup patch. Patch 16 is the final step for patching in the native MSR instructions when not running as a Xen PV guest. Patch 17 converts the rest of the MSR helpers to __always_inline. This series has been tested to work with Xen PV and on bare metal. Based on [1] and [2]. Changes since V4: - Rebase - dropped patch 3 of V4, as already covered by [1] Changes since V3: - Rebase - wrmsrns() related changes (patches 9+10) Changes since V2: - switch back to the paravirt approach Changes since V1: - Use Xin Li's approach for inlining - Several new patches [1]: https://lore.kernel.org/lkml/20260911074530.3140830-1-jgross@suse.com/T/#t [2]: https://lore.kernel.org/lkml/20260911075216.3142309-1-jgross@suse.com/T/#t Juergen Gross (17): x86/alternative: Support alt_replace_call() with instructions after call coco/tdx: Rename MSR access helpers x86/msr: Minimize usage of native_*() msr access functions x86/msr: Move MSR trace calls one function level up x86/hyperv: Switch from __rdmsr() to native_rdmsrq() x86/opcode: Add immediate form MSR instructions x86/extable: Add support for immediate form MSR instructions x86/msr: Make wrmsrns() a first class citizen x86/msr: Introduce sync_cpu_after_wrmsrns() x86/msr: Use the alternatives mechanism for RDMSR x86/alternatives: Add ALTERNATIVE_4() x86/paravirt: Split off MSR related hooks into new header x86/paravirt: Prepare support of MSR instruction interfaces x86/paravirt: Switch MSR access pv_ops functions to instruction interfaces x86/msr: Reduce number of low level MSR access helpers x86/paravirt: Use alternatives for MSR access with paravirt x86/msr: Make all MSR access functions __always_inline arch/x86/coco/tdx/tdx.c | 8 +- arch/x86/hyperv/hv_crash.c | 6 +- arch/x86/hyperv/ivm.c | 2 +- arch/x86/include/asm/alternative.h | 6 + arch/x86/include/asm/fred.h | 2 +- arch/x86/include/asm/msr.h | 340 +++++++++++++++++----- arch/x86/include/asm/paravirt-msr.h | 180 ++++++++++++ arch/x86/include/asm/paravirt.h | 45 --- arch/x86/include/asm/paravirt_types.h | 57 ++-- arch/x86/include/asm/qspinlock_paravirt.h | 4 +- arch/x86/kernel/alternative.c | 5 +- arch/x86/kernel/cpu/mshyperv.c | 4 +- arch/x86/kernel/kvmclock.c | 2 +- arch/x86/kernel/paravirt.c | 42 ++- arch/x86/kvm/svm/svm.c | 16 +- arch/x86/lib/x86-opcode-map.txt | 5 +- arch/x86/mm/extable.c | 41 ++- arch/x86/xen/enlighten_pv.c | 52 +++- arch/x86/xen/pmu.c | 4 +- tools/arch/x86/lib/x86-opcode-map.txt | 5 +- tools/objtool/check.c | 1 + 21 files changed, 632 insertions(+), 195 deletions(-) create mode 100644 arch/x86/include/asm/paravirt-msr.h -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 08:42:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 08:42:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415989.1645160 (Exim 4.92) (envelope-from ) id 1x4wqH-0007v2-FP; Fri, 11 Sep 2026 08:42:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415989.1645160; Fri, 11 Sep 2026 08:42:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wqH-0007uq-CM; Fri, 11 Sep 2026 08:42:41 +0000 Received: by outflank-mailman (input) for mailman id 1415989; Fri, 11 Sep 2026 08:42:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wqG-0007uK-1C for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 08:42:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4wqF-008YCw-E3 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:42:39 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3befd-8faa-0a2a0a5109dd-0a2a45098678-8 for ; Fri, 11 Sep 2026 10:42:39 +0200 Received: from [52.101.125.131] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3bef7-be1a-0a2a45090019-34657d8322b8-3 for ; Fri, 11 Sep 2026 10:42:34 +0200 Received: from TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:af::12) by OS7P286MB7475.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:43d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 08:42:29 +0000 Received: from TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM ([fe80::2067:ff0e:4c3:ad0b]) by TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM ([fe80::2067:ff0e:4c3:ad0b%5]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 08:42:29 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YolJ/IqbHOHj6kUFJYbEhQq+UDnlOhn/HozNapF+i7PyWP3Brpr03VZMCF7Q/WnozE7VPvBhtlhgE0474z1tDm9f2h641o9UUDHzf0ddZ4UQBBV8TxQW4C983IgdOhm6qmbj/oDRH7hy+vTcVXGIj9Thob/7x9VDSqx3Hzg8I8vvO1N1KfonDGIOXdeFk/MWqOGally3UusHvZzOTPIeDWFz+hBDDpWH1Ly1hSHKNPZAJ8QJK4AfLFdF75R4KhujjHIs5Ruyb4xRE1VoVBuhk/DPIqPS8i1ddpbVNsUK2vBvmwBjAM7DQtr/XzuP8XN5cBkn6Qk+yGqMVOPdf0FGdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VPJ5QY+3kppKZ4cOZLPHOJhBzEo2t1v/O8J4BX58dRs=; b=fyg9RcfBf5oFQAluszgqDmPUsn+h4MrZrewHUTtqgstpZ+8F8bu5pg1TBfFwQcx3EctHcKHZ+BLf5dM2ERbZgGNURBrAbebjUr70X/GuiRKhoFVYeqOLHxKKHdJGxchUpztHUdaEGYDyGEoQW4IxTmBy8ThuGioI+OmWv/NRUpEhCuFp0zKpXSBD4Q/1t9AtbfslJ1GbuR+77Pmeuqa7+38yBKlKNbv9vUz09LHLaHHxrU6bZdLKkkXiqdCxBS1n0cb6rADBi8X7GW4cUJhVVBADQywQY1DAkmlzJAXJbF4iU2wjJzsMbDVrmMx/An1Ig9W9OAbcpmfgxDGq06XzaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VPJ5QY+3kppKZ4cOZLPHOJhBzEo2t1v/O8J4BX58dRs=; b=TogDKm4ldSlIzKG7NplS/ZVyep+e9WqMupw2HlQHUEilZ0c/FQEsBYuwIAOh2qX2bbM1x8/T9o4Y8ylDYn0YeGsKoN/XyIkXfTz8mrTZ5l4yHho528Q1i/XK5NcHrobJcApVYl7sXEJ0zCFdySKYoITc4G748Xgp0T0kygUSjvY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; Message-ID: <8a74abbb-c890-4872-88de-7cc01a3da4cf@valinux.co.jp> Date: Fri, 11 Sep 2026 17:42:28 +0900 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/arm64/atomic: Clear exclusive monitor on cmpxchg failure To: Jan Beulich Cc: Hirokazu Takahashi , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260909061253.546312-1-okamoto@valinux.co.jp> <60532fdb-616d-4a25-8c7f-fd5cdc558787@suse.com> Content-Language: en-US From: ryoj In-Reply-To: <60532fdb-616d-4a25-8c7f-fd5cdc558787@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYCP286CA0051.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2b5::14) To TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:af::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TYCP286MB1053:EE_|OS7P286MB7475:EE_ X-MS-Office365-Filtering-Correlation-Id: 146e0c8a-7153-4514-f587-08df0fe09cd2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|10070799003|23010399003|376014|366016|4143699003|56012099006|10067099003|18002099003|22082099003|43062017; X-Microsoft-Antispam-Message-Info: 3nyy9UNWSTVAcRGa9viv812yyxoMS0YrhFU94FZIVrjJpPAb/xmGTcF/T0MV9x7ymTSdIMJkJHUYOPqL52r70958U+dIMMDeFZbdnYxVpIaM58lf2Z6uJDRqY6njmjmnNeFc9RX4EkAQqQO670Bz2u9Pa506i7x9YJg6N538SzXnFrdrp2qQZUzax7LUXsXLmI1dVJqTQOWgyWU5+xhQfibwVuJtfGOakZarY7nA4V1dRIDE2BoZqK5bdPBb7DsTA7nfbBAAOGacLRutvMmKmtT8iR143pOIMyu/OqVHDA0O+cuRM4Qg9xUcAyZHe61wisocYXwDxNgaESsi7bfuzqgozNvTjtXEDL6OFTx9g+9kk9u6ui1TAxFOFnwRFL8pIc7qt0lUWrM8lR02KyL2G7+ex/zAw6vkxpdlAp1tvOGc4cNhAobgA4v8qf1GGBMAgshKI8VDujZCUwqYH+dy38G4sX2ckGE+OJFUwH9R6gbphaEfrxfoXNV1IPcY08zXwM5i7n8NFVUqX5fliVxJOmdKjw4nwVhodlea0sMEKDq4+7cpfoBflDvNASfSln5xpYaMP0pEVknWIwGu7Y7Z/RP+u07OTE3d8aJIpVOR7GVqyRE7R666nQe/kYMY+pERpYlFpvWUie03soB1DGtuzvtEilDFOcbdUyZLB0WxwPmP/zG11nl3+WlFsNy+Kp8noj8VsUlbhTuyeB2UMRDi3A== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(10070799003)(23010399003)(376014)(366016)(4143699003)(56012099006)(10067099003)(18002099003)(22082099003)(43062017);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ejdZc1hsbFkwbEFPVnZjcUJHbW9tc1pHNlFsSnpKQmR1S1kxQTE0dVAvbWRN?= =?utf-8?B?TGUwVUh4QTBpdWFjdW1NVFpMZFY1cnFyMTFPeWI3aTQwMkNVc21ROTh1L0tu?= =?utf-8?B?OUpReUxZbFVKeENsSjBsZ1QxeCt5S3FzOFBRMFJsdlc1OUR4bUt0OGJUKzRN?= =?utf-8?B?UTlGczU5NDhtVkdwTUVlQk0weEI4d05tcHp3dTVPWjR5NUhhcFhOUnNnRnB5?= =?utf-8?B?ZFNvVUFKQklaS2x6REZMaDg0MWJ3aEZ3RFRjK1JxR01CRVg2NWhwZGpUYmVz?= =?utf-8?B?aTBxbnYwcExkRjFWMFZGTFAycXdTUThLa01VYXYvT1hpb3Rrd0lRTmtSR0dw?= =?utf-8?B?Qyt5dDhrNEdTUGRDZlo2T25QdlhRam1NUjhEZW91a0g2d0ZZMTl4a0xSQTAy?= =?utf-8?B?S08yS21uS1JWWTMyZkYzNUhZMnRyeW5SeEhZeHN1MnBxN1R0MndWeERoLzJm?= =?utf-8?B?UXdqYitHdjRYMVExRVFKcjUzcFFLSXBCWE1IRUZDUzhHK21Da0xhSzZSMzBk?= =?utf-8?B?Z2paZWs0YzVhcld6QWJKVzFjdzRlZzZCdHdsYklIMmVONE0yQ3pKZEpiS2ox?= =?utf-8?B?ZTNTVWZ4ZlovVGl5L1kvOG0xZUVOeHd0RWRZaUdocTF3VGkxUEF3MytMVnpK?= =?utf-8?B?RUlXL3FUcno1bkdhVmJhSEVzU1BHTSsvTE5QMC9aL2dLcno4bTB2VTNxMUJp?= =?utf-8?B?eEZhMkMyTWpoMmlFWGtUVkZCMmM5UFBXUXhscit5K3RFUjdSNFFVRFBiZFVa?= =?utf-8?B?K1FRbnJjT0R3Y1JGZ0FKUkk0dERBNGI0RUhJZXdva01GZ2ptaCs2MDREc1Y0?= =?utf-8?B?c0dzK01Eb1luRDBVWkswdUNXSHpUWWg0Y3pqN25pOU55VEhEL0tDeXpDWUJy?= =?utf-8?B?TzZNOFJ4ZlRyeU93OTVqSnZLckxodHNLbXliRlczS2MvbjBVTnhoazkwUFhx?= =?utf-8?B?YUpZTy9HT3h4c05rekNKeVoraHRKZjRZNFZOUGxNK1NmNnh3WXdtSG44THBI?= =?utf-8?B?N3BPTkc0T25pQzFudFJ2N1IycW1UYVI0d1JIdXhONlNhSGpHWVJMdzFtN1Bn?= =?utf-8?B?Y2hUUGNvQ0JQWngyTlpqa1FiSVUvN2tGcGtncWVscitRQ0RkM1pVd2lRZk0w?= =?utf-8?B?NFFVWVUxU0FuR3NkQ1FuamRoU1FNcmFwVWJKMGUxeEZzRjh0dzE1VkJlRXJx?= =?utf-8?B?cmE3STM4WVVuZjI5N21xNjBKcWpxYXJxcC9Ra1I3TVcvWjg0UVJ0SkhHaC9U?= =?utf-8?B?VGxxZlpqQ2VzVGVpbGJ5dWVwR2ROc1ZxcHVRZ25HR2E3QWhqaDFwRVRrcWVq?= =?utf-8?B?UkFHRWp5K0ZTOWtseWRmYUlidTNSYzBHTzZaN2NmQ0RJdnRFbGRzR0tFODY1?= =?utf-8?B?bjFUd2toSjI5cG5CY2t4Nk9hT05ldlNiMUxLRDhtOEJRSC9hdTdrN2RsZDBW?= =?utf-8?B?dUFOaEdtTFlwbzlTVllGUEJWeXY1MllRT0JjUXZRRlhZdFhUeFM4WWVnaE9T?= =?utf-8?B?SHNRNy9ic0VMdlErSFhYdmgxcmp2UTM3QzFzQTcxK01sTURjQjNkWnFrRDJq?= =?utf-8?B?d1duc0dYUS9xUjRBN2RxaEJkeUlEeDJ6bHJVVnExdTI1bXVMa3U3MUJpelZV?= =?utf-8?B?VEtXRkRkN0FpNTJTQk1qUE9HSEp6dCtJL1E0VmRDY1BSNWR4VWtiL0lwQ3ZU?= =?utf-8?B?Vk40bFRjTWE4R1NQTGlGRnNkd09UNXdlZkx4ZmhuSXE5dlZHS0ExS2JNdmVM?= =?utf-8?B?enJlcUQ3U1M2eVVXOVM0bU51TEVxdC9XY2pIK0ZxK1J2ZGwzR1MrRS9qd3Nq?= =?utf-8?B?bStTWFFTdGtHS3ZUVEVoZHlRTENIT2pIb3ZzOHd3YmhVQmlaRGZoazBheWlr?= =?utf-8?B?eC9MUWJzMktXSlRXb0pxd0ZlVS9RV2pDbjYzZ090U1ZBelQ5VytUOE5CQmc1?= =?utf-8?B?eGpXV3I5aHpYZWQydmdNQmI2OEdHa1NjOStPQ1dEQVYvNUtGbFdqVU1Ma0dC?= =?utf-8?B?RWNLeVJlYjRCeXlZakhOTi81dWRLMFFRejd5b1I0dW01ZWRNMGxyNjN2c2xZ?= =?utf-8?B?UDZiZ1dPUEJRSDlEZjI5YXFzbHhYS3JFUVZxQ3AraVVrS0pmaTNTdy9jcmxz?= =?utf-8?B?N2J4NnBJOHYyTlVNbDVUdmF4ZEV1aG50UUh0MFI1UmNkSmc4VjVjb1NYTWNL?= =?utf-8?B?bVUzM1dma21WUFRJbm82ZlZWMUtCUDNJQUwvNVF3d1hWYUNkdkR6ekluam9J?= =?utf-8?B?OWNnc3FQY2V3QXJFdFlqalNHQ2tsVFN3TEM2RFFRbFJBUlhFanFXWFdUTFdY?= =?utf-8?B?cGpIbE8yM2Q2QXczNWhVbCtOMlhaRG9xOTgyM1E2VTQ3TG53bVFJSmhhN1Zh?= =?utf-8?Q?y6pmIBmpbvJYQU/7Lp/oo4+Kh8KIPbgJi+Dd+LQGr0pLc?= X-MS-Exchange-AntiSpam-MessageData-1: wNUP+yf01fzajg== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 146e0c8a-7153-4514-f587-08df0fe09cd2 X-MS-Exchange-CrossTenant-AuthSource: TYCP286MB1053.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 08:42:28.9882 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ggjE6RrWfA5PDXesx7i1r7OEM4X/VFxg1x91wmtdN2xxdvnYzf/vp8AdW83g3D24EZ+xl6qzX8G3v6qSOAfeWQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS7P286MB7475 X-purgate-ID: tlsNG-bad1c0/1789116159-BFAD0034-6A3B1FC5/0/0 X-purgate-type: clean X-purgate-size: 1086 On 9/9/26 15:31, Jan Beulich wrote: > On 09.09.2026 08:12, Ryoji Okamoto wrote: >> When the value comparison fails in atomic_cmpxchg, the code branches >> out without executing stxr, leaving the exclusive monitor in the >> exclusive state set by ldxr. >> >> Add `clrex` to the failure path to explicitly clear the exclusive >> monitor. >> >> Fixes: d2654a556835 ("xen: arm64: atomics") >> Signed-off-by: Ryoji Okamoto >> --- >> v2: Use tabs for indentation instead of spaces > > Well, ... > >> --- a/xen/arch/arm/include/asm/arm64/atomic.h >> +++ b/xen/arch/arm/include/asm/arm64/atomic.h >> @@ -118,7 +118,9 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, int new) >> " b.ne 2f\n" >> " stxr %w0, %w4, %2\n" >> " cbnz %w0, 1b\n" >> -"2:" >> +" b 3f\n" > > ... you now do here, but ... > >> +"2: clrex\n" > > ... still not here. > > Jan Hi Jan, Thanks for the feedback on the indentation. I'm withdrawing this patch, but I'll definitely keep this in mind for the next time. Regards, -- Ryoji From xen-devel-bounces@lists.xenproject.org Fri Sep 11 08:42:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 08:42:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1415990.1645169 (Exim 4.92) (envelope-from ) id 1x4wqI-00087v-NX; Fri, 11 Sep 2026 08:42:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1415990.1645169; Fri, 11 Sep 2026 08:42: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 1x4wqI-00087k-J7; Fri, 11 Sep 2026 08:42:42 +0000 Received: by outflank-mailman (input) for mailman id 1415990; Fri, 11 Sep 2026 08:42:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wqH-0007uc-1d for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 08:42:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4wqG-008YGa-Ed for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:42:40 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3bef9-8faa-0a2a0a5109dd-0a2a4504d09c-32 for ; Fri, 11 Sep 2026 10:42:40 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3bf00-b57f-0a2a45040019-c387df82d1e8-3 for ; Fri, 11 Sep 2026 10:42:40 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 95C7421B8B; Fri, 11 Sep 2026 08:42:31 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id E9BF5132D3; Fri, 11 Sep 2026 08:42:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id sSe+N/a+o2rmFAAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 08:42:30 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789116155; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I9RPtXPkTH2l0Ce0h0ao/G3WKgQIi0rqtLxtBRCg9co=; b=rdSjRkCzOk4/4RzKflhPuzujpGtPl6d1z9BKM0n4C0aHaOt87Zlt0Ugdo34JCc16R1qzWK 6amzm7zZPLsnQDCNJUW3hShbWLmOruSWh/JeOlNlBVz+n9Z8xgsJa6Ujc2DdAFOjrQsn6+ sjq/iiMO24gqMmhUEzvMtfF4Ank529g= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789116151; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I9RPtXPkTH2l0Ce0h0ao/G3WKgQIi0rqtLxtBRCg9co=; b=KY/8X1EzbOsW7wb7+YFo5Q0K65gPFDoNRB04IkuLEe190SKIzPrNbNIQ78T3CntjxOf1ml 6V+BnJ5VLsCDVXgNDFEk2ExYUrsZd17BB9YZ4y3xbfbyDv+tN6QHZzbKXDB72ua7mHhNop QZPO2JRX3/uHmGE5ngZ7gbc18zGk/sw= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org Cc: Juergen Gross , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Sean Christopherson , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: [PATCH v5 03/17] x86/msr: Minimize usage of native_*() msr access functions Date: Fri, 11 Sep 2026 10:41:57 +0200 Message-ID: <20260911084211.3149957-4-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260911084211.3149957-1-jgross@suse.com> References: <20260911084211.3149957-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -6.80 X-Spam-Level: X-Spamd-Result: default: False [-6.80 / 50.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.997]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWELVE(0.00)[20]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-purgate-ID: tlsNG-ebf023/1789116160-C0CDFB50-310ACB67/0/0 X-purgate-type: clean X-purgate-size: 5326 In order to prepare for some MSR access function reorg work, switch most users of native_{read|write}_msr[_safe]() to the more generic rdmsr*()/wrmsr*() variants. For now this will have some intermediate performance impact with paravirtualization configured when running on bare metal, but this is a prereq change for the planned direct inlining of the rdmsr/wrmsr instructions with this configuration. The main reason for this switch is the planned move of the MSR trace function invocation from the native_*() functions to the generic rdmsr*()/wrmsr*() variants. Without this switch the users of the native_*() functions would lose the related tracing entries. Note that the Xen related MSR access functions will not be switched, as these will be handled after the move of the trace hooks. Signed-off-by: Juergen Gross Acked-by: Sean Christopherson Acked-by: Wei Liu Reviewed-by: H. Peter Anvin (Intel) --- arch/x86/hyperv/ivm.c | 2 +- arch/x86/kernel/cpu/mshyperv.c | 4 ++-- arch/x86/kernel/kvmclock.c | 2 +- arch/x86/kvm/svm/svm.c | 16 ++++++++-------- arch/x86/xen/pmu.c | 4 ++-- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c index 2ce4dfe53472..a74f121f2a02 100644 --- a/arch/x86/hyperv/ivm.c +++ b/arch/x86/hyperv/ivm.c @@ -328,7 +328,7 @@ int hv_snp_boot_ap(u32 apic_id, unsigned long start_ip, unsigned int cpu) savesegment(ds, vmsa->ds.selector); hv_populate_vmcb_seg(vmsa->ds, vmsa->gdtr.base); - vmsa->efer = native_read_msr(MSR_EFER); + vmsa->efer = rdmsrq(MSR_EFER); vmsa->cr4 = native_read_cr4(); vmsa->cr3 = __native_read_cr3(); diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index e1388ed27384..53ac4ef53929 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -114,7 +114,7 @@ u64 hv_para_get_synic_register(unsigned int reg) { if (WARN_ON(!ms_hyperv.paravisor_present || !hv_is_synic_msr(reg))) return ~0ULL; - return native_read_msr(reg); + return rdmsrq(reg); } /* @@ -124,7 +124,7 @@ void hv_para_set_synic_register(unsigned int reg, u64 val) { if (WARN_ON(!ms_hyperv.paravisor_present || !hv_is_synic_msr(reg))) return; - native_write_msr(reg, val); + wrmsrq(reg, val); } u64 hv_get_msr(unsigned int reg) diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c index cb3d0ca1fa22..6ddef8b5426a 100644 --- a/arch/x86/kernel/kvmclock.c +++ b/arch/x86/kernel/kvmclock.c @@ -219,7 +219,7 @@ static void kvm_setup_secondary_clock(void) void kvmclock_disable(void) { if (msr_kvm_system_time) - native_write_msr(msr_kvm_system_time, 0); + wrmsrq(msr_kvm_system_time, 0); } static void __init kvmclock_init_mem(void) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 91f5a5344529..5e5bbecb8020 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -412,12 +412,12 @@ static void svm_init_erratum_383(void) return; /* Use _safe variants to not break nested virtualization */ - if (native_read_msr_safe(MSR_AMD64_DC_CFG, &val)) + if (rdmsrq_safe(MSR_AMD64_DC_CFG, &val)) return; val |= (1ULL << 47); - native_write_msr_safe(MSR_AMD64_DC_CFG, val); + wrmsrq_safe(MSR_AMD64_DC_CFG, val); erratum_383_found = true; } @@ -470,8 +470,8 @@ static void svm_init_os_visible_workarounds(void) return; if (!this_cpu_has(X86_FEATURE_OSVW) || - native_read_msr_safe(MSR_AMD64_OSVW_ID_LENGTH, &len) || - native_read_msr_safe(MSR_AMD64_OSVW_STATUS, &status)) + rdmsrq_safe(MSR_AMD64_OSVW_ID_LENGTH, &len) || + rdmsrq_safe(MSR_AMD64_OSVW_STATUS, &status)) len = status = 0; if (status == READ_ONCE(osvw_status) && len >= READ_ONCE(osvw_len)) @@ -2112,7 +2112,7 @@ static bool is_erratum_383(void) if (!erratum_383_found) return false; - if (native_read_msr_safe(MSR_IA32_MC0_STATUS, &value)) + if (rdmsrq_safe(MSR_IA32_MC0_STATUS, &value)) return false; /* Bit 62 may or may not be set for this mce */ @@ -2123,11 +2123,11 @@ static bool is_erratum_383(void) /* Clear MCi_STATUS registers */ for (i = 0; i < 6; ++i) - native_write_msr_safe(MSR_IA32_MCx_STATUS(i), 0); + wrmsrq_safe(MSR_IA32_MCx_STATUS(i), 0); - if (!native_read_msr_safe(MSR_IA32_MCG_STATUS, &value)) { + if (!rdmsrq_safe(MSR_IA32_MCG_STATUS, &value)) { value &= ~(1ULL << 2); - native_write_msr_safe(MSR_IA32_MCG_STATUS, value); + wrmsrq_safe(MSR_IA32_MCG_STATUS, value); } /* Flush tlb to evict multi-match entries */ diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c index 5f50a3ee08f5..37512df8b8f2 100644 --- a/arch/x86/xen/pmu.c +++ b/arch/x86/xen/pmu.c @@ -324,7 +324,7 @@ static u64 xen_amd_read_pmc(int counter) u64 val; msr = amd_counters_base + (counter * amd_msr_step); - native_read_msr_safe(msr, &val); + rdmsrq_safe(msr, &val); return val; } @@ -350,7 +350,7 @@ static u64 xen_intel_read_pmc(int counter) else msr = MSR_IA32_PERFCTR0 + counter; - native_read_msr_safe(msr, &val); + rdmsrq_safe(msr, &val); return val; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 08:43:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 08:43:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416007.1645178 (Exim 4.92) (envelope-from ) id 1x4wr9-0000c5-2B; Fri, 11 Sep 2026 08:43:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416007.1645178; Fri, 11 Sep 2026 08:43:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wr8-0000by-V1; Fri, 11 Sep 2026 08:43:34 +0000 Received: by outflank-mailman (input) for mailman id 1416007; Fri, 11 Sep 2026 08:43:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wr7-0000bY-8S for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 08:43:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4wr6-00AnFg-8f for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:43:32 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3bf25-bab6-0a2a0a5309dd-0a2a4507940c-46 for ; Fri, 11 Sep 2026 10:43:32 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3bf34-b4ea-0a2a45070019-c387df83884a-3 for ; Fri, 11 Sep 2026 10:43:32 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 98F131FA79; Fri, 11 Sep 2026 08:43:23 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 11536132D3; Fri, 11 Sep 2026 08:43:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id tXzkAiu/o2odFgAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 08:43:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789116207; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y/JsZQGyUXG2PbaQKxJnt1DssgKzKUnZGz0wBmIldJU=; b=K2ym+chdvp4AOLx7hkxPAOXGGkVqFjIwBO9J5eYiDHaqbG0tAeUekjwPw1enesmOmkvpbb 60J62JjW2kbAONrRWP2I4xEvPu2HolP1M+HFk/LKa50fHZp6nuQTkaBSMvDwaXGYKL+Mag GcRxrTsJHmSDk3XBZtwilU2ydL4nGmM= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789116203; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y/JsZQGyUXG2PbaQKxJnt1DssgKzKUnZGz0wBmIldJU=; b=FbfwFv85BO4Lxu6VbQS451GwDDEmZSiFnVhP+ZEMXMkCC4ikbs9v0r/FjQR3mWFpjf0TmZ L7QidEp3rxrjzR1mcTx3zjxQjYzGnTk8S4X2HyKk3oxdwLdM0rUhIobEQUL6hT/voPzpLw GEhuzD1Hyktm7Yj3T5pIddq8QY0s1VQ= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Boris Ostrovsky , Josh Poimboeuf , Peter Zijlstra , xen-devel@lists.xenproject.org Subject: [PATCH v5 12/17] x86/paravirt: Split off MSR related hooks into new header Date: Fri, 11 Sep 2026 10:42:06 +0200 Message-ID: <20260911084211.3149957-13-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260911084211.3149957-1-jgross@suse.com> References: <20260911084211.3149957-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Level: X-Spam-Score: -6.80 X-Spam-Flag: NO X-Spamd-Result: default: False [-6.80 / 50.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.997]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWELVE(0.00)[16]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[] X-purgate-ID: tlsNG-ef75cf/1789116212-A64DBAE4-5D0BC8C6/0/0 X-purgate-type: clean X-purgate-size: 8115 Move the WRMSR, RDMSR and RDPMC related parts of paravirt.h and paravirt_types.h into a new header file paravirt-msr.h. Switch all moved helper functions to __always_inline. Signed-off-by: Juergen Gross --- V3: - new patch V4: - always use __always_inline --- arch/x86/include/asm/msr.h | 2 +- arch/x86/include/asm/paravirt-msr.h | 56 +++++++++++++++++++++++++++ arch/x86/include/asm/paravirt.h | 55 -------------------------- arch/x86/include/asm/paravirt_types.h | 13 ------- arch/x86/kernel/paravirt.c | 14 ++++--- arch/x86/xen/enlighten_pv.c | 11 +++--- tools/objtool/check.c | 1 + 7 files changed, 73 insertions(+), 79 deletions(-) create mode 100644 arch/x86/include/asm/paravirt-msr.h diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index fb1027dc7f64..f7ad6d25bb65 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -323,7 +323,7 @@ static inline u64 native_read_pmc(int counter) } #ifdef CONFIG_PARAVIRT_XXL -#include +#include #else static __always_inline u64 read_msr(u32 msr) { diff --git a/arch/x86/include/asm/paravirt-msr.h b/arch/x86/include/asm/paravirt-msr.h new file mode 100644 index 000000000000..3e31648316a8 --- /dev/null +++ b/arch/x86/include/asm/paravirt-msr.h @@ -0,0 +1,56 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef _ASM_X86_PARAVIRT_MSR_H +#define _ASM_X86_PARAVIRT_MSR_H + +#include + +struct pv_msr_ops { + /* Unsafe MSR operations. These will warn or panic on failure. */ + u64 (*read_msr)(u32 msr); + void (*write_msr)(u32 msr, u64 val); + + /* Safe MSR operations. Returns 0 or -EIO. */ + int (*read_msr_safe)(u32 msr, u64 *val); + int (*write_msr_safe)(u32 msr, u64 val); + + u64 (*read_pmc)(int counter); +} __no_randomize_layout; + +extern struct pv_msr_ops pv_ops_msr; + +static __always_inline u64 read_msr(u32 msr) +{ + return PVOP_CALL1(u64, pv_ops_msr, read_msr, msr); +} + +static __always_inline void write_msr(u32 msr, u64 val) +{ + PVOP_VCALL2(pv_ops_msr, write_msr, msr, val); +} + +static __always_inline void write_msrns(u32 msr, u64 val) +{ + PVOP_VCALL2(pv_ops_msr, write_msr, msr, val); +} + +static __always_inline int read_msr_safe(u32 msr, u64 *val) +{ + return PVOP_CALL2(int, pv_ops_msr, read_msr_safe, msr, val); +} + +static __always_inline int write_msr_safe(u32 msr, u64 val) +{ + return PVOP_CALL2(int, pv_ops_msr, write_msr_safe, msr, val); +} + +static __always_inline int write_msrns_safe(u32 msr, u64 val) +{ + return PVOP_CALL2(int, pv_ops_msr, write_msr_safe, msr, val); +} + +static __always_inline u64 rdpmc(int counter) +{ + return PVOP_CALL1(u64, pv_ops_msr, read_pmc, counter); +} + +#endif /* _ASM_X86_PARAVIRT_MSR_H */ diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index b0c740316cf7..eb16d55f94d3 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -130,61 +130,6 @@ static inline void __write_cr4(unsigned long x) PVOP_VCALL1(pv_ops, cpu.write_cr4, x); } -static inline u64 paravirt_read_msr(u32 msr) -{ - return PVOP_CALL1(u64, pv_ops, cpu.read_msr, msr); -} - -static inline void paravirt_write_msr(u32 msr, u64 val) -{ - PVOP_VCALL2(pv_ops, cpu.write_msr, msr, val); -} - -static inline int paravirt_read_msr_safe(u32 msr, u64 *val) -{ - return PVOP_CALL2(int, pv_ops, cpu.read_msr_safe, msr, val); -} - -static inline int paravirt_write_msr_safe(u32 msr, u64 val) -{ - return PVOP_CALL2(int, pv_ops, cpu.write_msr_safe, msr, val); -} - -static __always_inline u64 read_msr(u32 msr) -{ - return paravirt_read_msr(msr); -} - -static inline void write_msr(u32 msr, u64 val) -{ - paravirt_write_msr(msr, val); -} - -static __always_inline void write_msrns(u32 msr, u64 val) -{ - paravirt_write_msr(msr, val); -} - -static inline int write_msr_safe(u32 msr, u64 val) -{ - return paravirt_write_msr_safe(msr, val); -} - -static __always_inline int write_msrns_safe(u32 msr, u64 val) -{ - return paravirt_write_msr_safe(msr, val); -} - -static __always_inline int read_msr_safe(u32 msr, u64 *p) -{ - return paravirt_read_msr_safe(msr, p); -} - -static __always_inline u64 rdpmc(int counter) -{ - return PVOP_CALL1(u64, pv_ops, cpu.read_pmc, counter); -} - static inline void paravirt_alloc_ldt(struct desc_struct *ldt, unsigned entries) { PVOP_VCALL2(pv_ops, cpu.alloc_ldt, ldt, entries); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index b4c4a23e77a1..2459163fa196 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -58,19 +58,6 @@ struct pv_cpu_ops { void (*cpuid)(unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx); - /* Unsafe MSR operations. These will warn or panic on failure. */ - u64 (*read_msr)(u32 msr); - void (*write_msr)(u32 msr, u64 val); - - /* - * Safe MSR operations. - * Returns 0 or -EIO. - */ - int (*read_msr_safe)(u32 msr, u64 *val); - int (*write_msr_safe)(u32 msr, u64 val); - - u64 (*read_pmc)(int counter); - void (*start_context_switch)(struct task_struct *prev); void (*end_context_switch)(struct task_struct *next); #endif diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 00b59d774389..739dbfd8aadf 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -110,11 +110,6 @@ struct paravirt_patch_template pv_ops = { .cpu.read_cr0 = native_read_cr0, .cpu.write_cr0 = native_write_cr0, .cpu.write_cr4 = native_write_cr4, - .cpu.read_msr = native_read_msr, - .cpu.write_msr = native_write_msr, - .cpu.read_msr_safe = native_read_msr_safe, - .cpu.write_msr_safe = native_write_msr_safe, - .cpu.read_pmc = native_read_pmc, .cpu.load_tr_desc = native_load_tr_desc, .cpu.set_ldt = native_set_ldt, .cpu.load_gdt = native_load_gdt, @@ -212,6 +207,15 @@ struct paravirt_patch_template pv_ops = { }; #ifdef CONFIG_PARAVIRT_XXL +struct pv_msr_ops pv_ops_msr = { + .read_msr = native_read_msr, + .write_msr = native_write_msr, + .read_msr_safe = native_read_msr_safe, + .write_msr_safe = native_write_msr_safe, + .read_pmc = native_read_pmc, +}; +EXPORT_SYMBOL(pv_ops_msr); + NOKPROBE_SYMBOL(native_load_idt); #endif diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 2c64b388f616..bf81e84ff261 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1360,11 +1360,6 @@ asmlinkage __visible void __init xen_start_kernel(struct start_info *si) pv_ops.cpu.read_cr0 = xen_read_cr0; pv_ops.cpu.write_cr0 = xen_write_cr0; pv_ops.cpu.write_cr4 = xen_write_cr4; - pv_ops.cpu.read_msr = xen_read_msr; - pv_ops.cpu.write_msr = xen_write_msr; - pv_ops.cpu.read_msr_safe = xen_read_msr_safe; - pv_ops.cpu.write_msr_safe = xen_write_msr_safe; - pv_ops.cpu.read_pmc = xen_read_pmc; pv_ops.cpu.load_tr_desc = paravirt_nop; pv_ops.cpu.set_ldt = xen_set_ldt; pv_ops.cpu.load_gdt = xen_load_gdt; @@ -1385,6 +1380,12 @@ asmlinkage __visible void __init xen_start_kernel(struct start_info *si) pv_ops.cpu.start_context_switch = xen_start_context_switch; pv_ops.cpu.end_context_switch = xen_end_context_switch; + pv_ops_msr.read_msr = xen_read_msr; + pv_ops_msr.write_msr = xen_write_msr; + pv_ops_msr.read_msr_safe = xen_read_msr_safe; + pv_ops_msr.write_msr_safe = xen_write_msr_safe; + pv_ops_msr.read_pmc = xen_read_pmc; + xen_init_irq_ops(); /* diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 464f6c9d9ff0..6c47d650b20e 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -529,6 +529,7 @@ static struct { } pv_ops_tables[] = { { .name = "pv_ops", }, { .name = "pv_ops_lock", }, + { .name = "pv_ops_msr", }, { .name = NULL, .idx_off = -1 } }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 08:43:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 08:43:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416008.1645187 (Exim 4.92) (envelope-from ) id 1x4wrB-0000pO-8o; Fri, 11 Sep 2026 08:43:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416008.1645187; Fri, 11 Sep 2026 08:43:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wrB-0000pH-66; Fri, 11 Sep 2026 08:43:37 +0000 Received: by outflank-mailman (input) for mailman id 1416008; Fri, 11 Sep 2026 08:43:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wrA-0000oa-4f for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 08:43:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4wr9-0053j7-Ho for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:43:35 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3bf24-bab6-0a2a0a5309dd-0a2a4508e94e-48 for ; Fri, 11 Sep 2026 10:43:35 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3bf37-f659-0a2a45080019-c387df83e300-3 for ; Fri, 11 Sep 2026 10:43:35 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 34D361FE05; Fri, 11 Sep 2026 08:43:35 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id AFB15132D3; Fri, 11 Sep 2026 08:43:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id ipiFKTa/o2o4FgAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 08:43:34 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: smtp-out2.suse.de; none From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev Cc: Juergen Gross , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: [PATCH v5 14/17] x86/paravirt: Switch MSR access pv_ops functions to instruction interfaces Date: Fri, 11 Sep 2026 10:42:08 +0200 Message-ID: <20260911084211.3149957-15-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260911084211.3149957-1-jgross@suse.com> References: <20260911084211.3149957-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 34D361FE05 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: -4.00 X-purgate-ID: tlsNG-c1860d/1789116215-CC37587B-5407A164/0/0 X-purgate-type: clean X-purgate-size: 8932 In order to prepare for inlining RDMSR/WRMSR instructions via alternatives directly when running not in a Xen PV guest, switch the interfaces of the MSR related pvops callbacks to ones similar of the related instructions. In order to prepare for supporting the immediate variants of RDMSR/WRMSR use a 64-bit interface instead of the 32-bit one of RDMSR/WRMSR. Signed-off-by: Juergen Gross --- V3: - former patch 5 of V1 has been split - use 64-bit interface (Xin Li) --- arch/x86/include/asm/paravirt-msr.h | 64 ++++++++++++++++++++++++----- arch/x86/kernel/paravirt.c | 36 ++++++++++++++-- arch/x86/xen/enlighten_pv.c | 45 +++++++++++++++----- 3 files changed, 120 insertions(+), 25 deletions(-) diff --git a/arch/x86/include/asm/paravirt-msr.h b/arch/x86/include/asm/paravirt-msr.h index 3e31648316a8..4b71a1cd780c 100644 --- a/arch/x86/include/asm/paravirt-msr.h +++ b/arch/x86/include/asm/paravirt-msr.h @@ -6,46 +6,90 @@ struct pv_msr_ops { /* Unsafe MSR operations. These will warn or panic on failure. */ - u64 (*read_msr)(u32 msr); - void (*write_msr)(u32 msr, u64 val); + struct paravirt_callee_save read_msr; + struct paravirt_callee_save write_msr; /* Safe MSR operations. Returns 0 or -EIO. */ - int (*read_msr_safe)(u32 msr, u64 *val); - int (*write_msr_safe)(u32 msr, u64 val); + struct paravirt_callee_save read_msr_safe; + struct paravirt_callee_save write_msr_safe; u64 (*read_pmc)(int counter); } __no_randomize_layout; extern struct pv_msr_ops pv_ops_msr; +#define PV_PROLOGUE_MSR(func) \ + PV_SAVE_COMMON_CALLER_REGS \ + PV_PROLOGUE_MSR_##func + +#define PV_EPILOGUE_MSR(func) PV_RESTORE_COMMON_CALLER_REGS + +#define PV_CALLEE_SAVE_REGS_MSR_THUNK(func) \ + __PV_CALLEE_SAVE_REGS_THUNK(func, ".text", MSR) + static __always_inline u64 read_msr(u32 msr) { - return PVOP_CALL1(u64, pv_ops_msr, read_msr, msr); + u64 val; + + asm volatile(PARAVIRT_CALL + : "=a" (val), ASM_CALL_CONSTRAINT + : paravirt_ptr(pv_ops_msr, read_msr), "c" (msr) + : "rdx"); + + return val; } static __always_inline void write_msr(u32 msr, u64 val) { - PVOP_VCALL2(pv_ops_msr, write_msr, msr, val); + asm volatile(PARAVIRT_CALL + : ASM_CALL_CONSTRAINT + : paravirt_ptr(pv_ops_msr, write_msr), "c" (msr), "a" (val) + : "memory", "rdx"); } static __always_inline void write_msrns(u32 msr, u64 val) { - PVOP_VCALL2(pv_ops_msr, write_msr, msr, val); + asm volatile(PARAVIRT_CALL + : ASM_CALL_CONSTRAINT + : paravirt_ptr(pv_ops_msr, write_msr), "c" (msr), "a" (val) + : "memory", "rdx"); } static __always_inline int read_msr_safe(u32 msr, u64 *val) { - return PVOP_CALL2(int, pv_ops_msr, read_msr_safe, msr, val); + int err; + + asm volatile(PARAVIRT_CALL + : [err] "=d" (err), "=a" (*val), ASM_CALL_CONSTRAINT + : paravirt_ptr(pv_ops_msr, read_msr_safe), "c" (msr)); + + return err ? -EIO : 0; } static __always_inline int write_msr_safe(u32 msr, u64 val) { - return PVOP_CALL2(int, pv_ops_msr, write_msr_safe, msr, val); + int err; + + asm volatile(PARAVIRT_CALL + : [err] "=a" (err), ASM_CALL_CONSTRAINT + : paravirt_ptr(pv_ops_msr, write_msr_safe), + "c" (msr), "a" (val) + : "memory", "rdx"); + + return err ? -EIO : 0; } static __always_inline int write_msrns_safe(u32 msr, u64 val) { - return PVOP_CALL2(int, pv_ops_msr, write_msr_safe, msr, val); + int err; + + asm volatile(PARAVIRT_CALL + : [err] "=a" (err), ASM_CALL_CONSTRAINT + : paravirt_ptr(pv_ops_msr, write_msr_safe), + "c" (msr), "a" (val) + : "memory", "rdx"); + + return err ? -EIO : 0; } static __always_inline u64 rdpmc(int counter) diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 739dbfd8aadf..66c0d6b5423c 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -50,12 +50,40 @@ unsigned long pv_native_save_fl(void); void pv_native_irq_disable(void); void pv_native_irq_enable(void); unsigned long pv_native_read_cr2(void); +void pv_native_rdmsr(void); +void pv_native_wrmsr(void); +void pv_native_rdmsr_safe(void); +void pv_native_wrmsr_safe(void); DEFINE_ASM_FUNC(_paravirt_ident_64, "mov %rdi, %rax", .text); DEFINE_ASM_FUNC(pv_native_save_fl, "pushf; pop %rax", .noinstr.text); DEFINE_ASM_FUNC(pv_native_irq_disable, "cli", .noinstr.text); DEFINE_ASM_FUNC(pv_native_irq_enable, "sti", .noinstr.text); DEFINE_ASM_FUNC(pv_native_read_cr2, "mov %cr2, %rax", .noinstr.text); +DEFINE_ASM_FUNC(pv_native_rdmsr, + "1: rdmsr\n" + "shl $32, %rdx; or %rdx, %rax\n" + "2:\n" + _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_RDMSR), .noinstr.text); +DEFINE_ASM_FUNC(pv_native_wrmsr, + "mov %rax, %rdx; shr $32, %rdx\n" + "1: wrmsr\n" + "2:\n" + _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_WRMSR), .noinstr.text); +DEFINE_ASM_FUNC(pv_native_rdmsr_safe, + "1: rdmsr\n" + "shl $32, %rdx; or %rdx, %rax\n" + "xor %edx, %edx\n" + "2:\n" + _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_RDMSR_SAFE, %%edx), + .noinstr.text); +DEFINE_ASM_FUNC(pv_native_wrmsr_safe, + "mov %rax, %rdx; shr $32, %rdx\n" + "1: wrmsr\n" + "xor %eax, %eax\n" + "2:\n" + _ASM_EXTABLE_TYPE_REG(1b, 2b, EX_TYPE_WRMSR_SAFE, %%eax), + .noinstr.text); #endif static noinstr void pv_native_safe_halt(void) @@ -208,10 +236,10 @@ struct paravirt_patch_template pv_ops = { #ifdef CONFIG_PARAVIRT_XXL struct pv_msr_ops pv_ops_msr = { - .read_msr = native_read_msr, - .write_msr = native_write_msr, - .read_msr_safe = native_read_msr_safe, - .write_msr_safe = native_write_msr_safe, + .read_msr = __PV_IS_CALLEE_SAVE(pv_native_rdmsr), + .write_msr = __PV_IS_CALLEE_SAVE(pv_native_wrmsr), + .read_msr_safe = __PV_IS_CALLEE_SAVE(pv_native_rdmsr_safe), + .write_msr_safe = __PV_IS_CALLEE_SAVE(pv_native_wrmsr_safe), .read_pmc = native_read_pmc, }; EXPORT_SYMBOL(pv_ops_msr); diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index bf81e84ff261..505a85c3869e 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1148,15 +1148,32 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err) } } -static int xen_read_msr_safe(u32 msr, u64 *val) +/* + * Prototypes for functions called via PV_CALLEE_SAVE_REGS_THUNK() in order + * to avoid warnings with "-Wmissing-prototypes". + */ +struct xen_rdmsr_safe_ret { + u64 val; + int err; +}; +struct xen_rdmsr_safe_ret xen_read_msr_safe(u32 msr); +int xen_write_msr_safe(u32 msr, u64 val); +u64 xen_read_msr(u32 msr); +void xen_write_msr(u32 msr, u64 val); +#define PV_PROLOGUE_RDMSR "mov %ecx, %edi;" +#define PV_PROLOGUE_WRMSR "mov %ecx, %edi; mov %rax, %rsi;" + +__visible struct xen_rdmsr_safe_ret xen_read_msr_safe(u32 msr) { - int err = 0; + struct xen_rdmsr_safe_ret ret = { 0, 0 }; - *val = xen_do_read_msr(msr, &err); - return err; + ret.val = xen_do_read_msr(msr, &ret.err); + return ret; } +#define PV_PROLOGUE_MSR_xen_read_msr_safe PV_PROLOGUE_RDMSR +PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_read_msr_safe); -static int xen_write_msr_safe(u32 msr, u64 val) +__visible int xen_write_msr_safe(u32 msr, u64 val) { int err = 0; @@ -1164,20 +1181,26 @@ static int xen_write_msr_safe(u32 msr, u64 val) return err; } +#define PV_PROLOGUE_MSR_xen_write_msr_safe PV_PROLOGUE_WRMSR +PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_write_msr_safe); -static u64 xen_read_msr(u32 msr) +__visible u64 xen_read_msr(u32 msr) { int err = 0; return xen_do_read_msr(msr, xen_msr_safe ? &err : NULL); } +#define PV_PROLOGUE_MSR_xen_read_msr PV_PROLOGUE_RDMSR +PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_read_msr); -static void xen_write_msr(u32 msr, u64 val) +__visible void xen_write_msr(u32 msr, u64 val) { int err; xen_do_write_msr(msr, val, xen_msr_safe ? &err : NULL); } +#define PV_PROLOGUE_MSR_xen_write_msr PV_PROLOGUE_WRMSR +PV_CALLEE_SAVE_REGS_MSR_THUNK(xen_write_msr); /* This is called once we have the cpu_possible_mask */ void __init xen_setup_vcpu_info_placement(void) @@ -1380,10 +1403,10 @@ asmlinkage __visible void __init xen_start_kernel(struct start_info *si) pv_ops.cpu.start_context_switch = xen_start_context_switch; pv_ops.cpu.end_context_switch = xen_end_context_switch; - pv_ops_msr.read_msr = xen_read_msr; - pv_ops_msr.write_msr = xen_write_msr; - pv_ops_msr.read_msr_safe = xen_read_msr_safe; - pv_ops_msr.write_msr_safe = xen_write_msr_safe; + pv_ops_msr.read_msr = PV_CALLEE_SAVE(xen_read_msr); + pv_ops_msr.write_msr = PV_CALLEE_SAVE(xen_write_msr); + pv_ops_msr.read_msr_safe = PV_CALLEE_SAVE(xen_read_msr_safe); + pv_ops_msr.write_msr_safe = PV_CALLEE_SAVE(xen_write_msr_safe); pv_ops_msr.read_pmc = xen_read_pmc; xen_init_irq_ops(); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 08:43:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 08:43:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416009.1645196 (Exim 4.92) (envelope-from ) id 1x4wrH-00018t-Hq; Fri, 11 Sep 2026 08:43:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416009.1645196; Fri, 11 Sep 2026 08:43:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wrH-00018h-E7; Fri, 11 Sep 2026 08:43:43 +0000 Received: by outflank-mailman (input) for mailman id 1416009; Fri, 11 Sep 2026 08:43:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4wrG-000173-0l for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 08:43:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4wrF-000daV-DM for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:43:41 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3bf37-2eae-0a2a0a5409dd-0a2a4508ac42-14 for ; Fri, 11 Sep 2026 10:43:41 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3bf3d-f659-0a2a45080019-c387df82cae4-3 for ; Fri, 11 Sep 2026 10:43:41 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id ED47721B99; Fri, 11 Sep 2026 08:43:40 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 84F33132D3; Fri, 11 Sep 2026 08:43:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id RvYTHzy/o2pSFgAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 08:43:40 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: smtp-out1.suse.de; none From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: [PATCH v5 15/17] x86/msr: Reduce number of low level MSR access helpers Date: Fri, 11 Sep 2026 10:42:09 +0200 Message-ID: <20260911084211.3149957-16-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260911084211.3149957-1-jgross@suse.com> References: <20260911084211.3149957-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: ED47721B99 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: -4.00 X-purgate-ID: tlsNG-c1860d/1789116221-DFED287B-01351793/0/0 X-purgate-type: clean X-purgate-size: 2269 Some MSR access helpers are redundant now, so remove the no longer needed ones. Signed-off-by: Juergen Gross --- arch/x86/include/asm/msr.h | 15 ++------------- arch/x86/xen/enlighten_pv.c | 4 ++-- 2 files changed, 4 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index f7ad6d25bb65..dbc24550a504 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -269,22 +269,11 @@ static __always_inline void native_wrmsrq(u32 msr, u64 val) __wrmsrq(msr, val); } -static inline u64 native_read_msr(u32 msr) -{ - return native_rdmsrq(msr); -} - static inline int native_read_msr_safe(u32 msr, u64 *val) { return __rdmsr(msr, val, EX_TYPE_RDMSR_SAFE) ? -EIO : 0; } -/* Can be uninlined because referenced by paravirt */ -static inline void notrace native_write_msr(u32 msr, u64 val) -{ - native_wrmsrq(msr, val); -} - /* Can be uninlined because referenced by paravirt */ static inline int notrace native_write_msr_safe(u32 msr, u64 val) { @@ -327,7 +316,7 @@ static inline u64 native_read_pmc(int counter) #else static __always_inline u64 read_msr(u32 msr) { - return native_read_msr(msr); + return native_rdmsrq(msr); } static __always_inline int read_msr_safe(u32 msr, u64 *p) @@ -337,7 +326,7 @@ static __always_inline int read_msr_safe(u32 msr, u64 *p) static __always_inline void write_msr(u32 msr, u64 val) { - native_write_msr(msr, val); + native_wrmsrq(msr, val); } static __always_inline int write_msr_safe(u32 msr, u64 val) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 505a85c3869e..bc572ca49a2c 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1085,7 +1085,7 @@ static u64 xen_do_read_msr(u32 msr, int *err) if (err) *err = native_read_msr_safe(msr, &val); else - val = native_read_msr(msr); + val = native_rdmsrq(msr); switch (msr) { case MSR_IA32_APICBASE: @@ -1144,7 +1144,7 @@ static void xen_do_write_msr(u32 msr, u64 val, int *err) if (err) *err = native_write_msr_safe(msr, val); else - native_write_msr(msr, val); + native_wrmsrq(msr, val); } } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:01:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:01:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416038.1645206 (Exim 4.92) (envelope-from ) id 1x4x8r-00055N-3Z; Fri, 11 Sep 2026 09:01:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416038.1645206; Fri, 11 Sep 2026 09:01:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4x8q-00055G-Vr; Fri, 11 Sep 2026 09:01:52 +0000 Received: by outflank-mailman (input) for mailman id 1416038; Fri, 11 Sep 2026 09:01:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4x8p-000559-Mp for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:01:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4x8p-007pxH-1z for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:01:51 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3c37a-e002-0a2a0a5209dd-0a2a4501d846-22 for ; Fri, 11 Sep 2026 11:01:50 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3c37d-5984-0a2a45010019-aa0a817c7281-3 for ; Fri, 11 Sep 2026 11:01:50 +0200 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-465-2EAmKVKxMTmiFB9fcY4olA-1; Fri, 11 Sep 2026 05:01:47 -0400 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-495689bfcc8so4972605e9.1 for ; Fri, 11 Sep 2026 02:01:47 -0700 (PDT) Received: from redhat.com (IGLD-80-230-79-236.inter.net.il. [80.230.79.236]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e61a32803sm43926005e9.0.2026.09.11.02.01.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 02:01:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789117309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g9mLgS0ybrUUaTMFusFVuyMEvSQGJ2PNYaEiCYholds=; b=Tc+5QtfAP0yomD5Z9QaVRpEVwav0vAsYZiS6/THJZvoJ9KD3FWTt+Whp/3ldpzlMkyV69S e5CX54UGa2u421g8Y9lsamXfloY+a5lIlGPgZPESGEeqf5Fz0CRFr5XE8kUtAuQPW7RGF3 w/T1x1TlqTSUNK03cNcr36DA73ffFPo= X-MC-Unique: 2EAmKVKxMTmiFB9fcY4olA-1 X-Mimecast-MFC-AGG-ID: 2EAmKVKxMTmiFB9fcY4olA_1789117307 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789117306; x=1789722106; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=g9mLgS0ybrUUaTMFusFVuyMEvSQGJ2PNYaEiCYholds=; b=Ea9DiW08z4W5m/tB7Ijj55400vFTB6QRc5o7BokaiqvePM9D6LyTIs2oS1ljw8zkrx R69vpslY6cOzawyHT1DQgeXcJtVkAPAEWdr8Ys7oAaCBFjODNBVvO/TwsK0vCFVFECnQ cY7jyeopy4byYV5nyaTlIwd1765daU3XwbxNu+6RuKRjVWp2OGbPQ+LrbvSfIZqSvewT a3c5Y0wz1qXVdUEMdlQst3IhbkzkYoRKuPK8ZTmsw+IVxasY87+W9nVK7c5tHFAlDRmV NDpANJVwNZj84cApmeO0k1uDI4qasADc5MVrG23aBEoGj9sqVml63blIyDMPBK1YvGrW ojxA== X-Forwarded-Encrypted: i=1; AKwUvByNXsPg+Dwsuy9rIWJn5QnUOW3PPtwLKNMt6/952knWzLphRt7TX/K2DJO1drhs7KCGNK/ODG25O3c=@lists.xenproject.org X-Gm-Message-State: AFuF++lq5oY/wUPtqynT7L31Ft5YM1wW8ZnEuhCq8dQC1KVvJUsdEjZz 0JCxc2WtuJtkneliu/4tQwZNDJPUHntL9RNr2DU/qbL8tqNfkyT/AHAJn8XoJQzuFSu78TLc4B3 j13tOYvZPYM4gO5SzTNn2NumKiAbphaP/vJ80FYz0GWWrmFIcr1Ch6ZhRwjIhc1+nkfXS X-Gm-Gg: AYBFou1kXZ1C0RRgEEOoTVZ9PUZ7M8wMqm2HejZ9Bo7OwH9i8L4fjk9MNOAg0RHx8vJ aRKjbDcILgpNRGhK9pjgLyq/p+CHOA3l7kgJSQa0vR2HG5mjzKjdJAmE8XAn2cd4RvA0vTYjaKc MtvMXv5y0rDM8ThWB4ajfWaIpKp0myNyhblOpq2Pj/sH7CG9vfBzeh2MxJy3byszWVwsFJnSUUz N1PtZEvGD6cvepHepUcXoL7QwtA9HAnpuBWt6HyKpsQEn3qj2eAaQqe9+4ddI2gIsWWeVCpYkJ3 PLsHdsWz0i/JN4OoL3ySdXMoMlAu637O+ftQlxiklvT01zp9I+Rp/hCTVEFeTG84dBz89Nr1MkL CIe40znHntWNGpFkj04Ol0FI= X-Received: by 2002:a05:600c:6289:b0:49c:de80:b833 with SMTP id 5b1f17b1804b1-49e61983067mr32623595e9.2.1789117306102; Fri, 11 Sep 2026 02:01:46 -0700 (PDT) X-Received: by 2002:a05:600c:6289:b0:49c:de80:b833 with SMTP id 5b1f17b1804b1-49e61983067mr32623015e9.2.1789117305570; Fri, 11 Sep 2026 02:01:45 -0700 (PDT) Date: Fri, 11 Sep 2026 05:01:42 -0400 From: "Michael S. Tsirkin" To: qemu-devel@nongnu.org Cc: Peter Maydell , Vladimir Sementsov-Ogievskiy , Ben Chaney , Markus Armbruster , Pierrick Bouvier , Sergio Lopez , Paolo Bonzini , Zhao Liu , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Bernhard Beschow , Conor Dooley , Sebastian Huber , Alistair Francis , Palmer Dabbelt , Jason Wang , Eric Blake , devel@lists.libvirt.org, xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org Subject: [PULL v2 11/75] net/tap: deprecate "no" as special value for script/downscript Message-ID: <3e4c54739a7e3409a477197fa300104202eb3570.1789117222.git.mst@redhat.com> References: MIME-Version: 1.0 In-Reply-To: X-Mailer: git-send-email 2.51.2.2891.g4157995a80.dirty X-Mutt-Fcc: =sent X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: dUpS0tgg2_cUp1glRC8Crui4Sxo7JiuobiHLMIcqWUw_1789117307 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1789117310-C495A757-A50FD0FD/0/0 X-purgate-type: clean X-purgate-size: 12712 From: Vladimir Sementsov-Ogievskiy The interface is ambiguous, as "no" is valid file name. So, using "no" as a special value to disable script is deprecated. Use an empty string ("script=" / "downscript=") instead. In a future version, "no" will be treated as a plain file name, just like any other non-empty value. Document the deprecation in docs/about/deprecated.rst, qapi/net.json, and qemu-options.hx. Update other docs to use empty string instead of "no". Add a warning. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Ben Chaney Reviewed-by: Markus Armbruster Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-ID: <20260819180201.1970193-4-vsementsov@yandex-team.ru> --- docs/about/deprecated.rst | 18 ++++++++++++++++++ docs/system/i386/microvm.rst | 4 ++-- docs/system/i386/xenpvh.rst | 2 +- docs/system/ppc/ppce500.rst | 4 ++-- docs/system/riscv/microchip-icicle-kit.rst | 2 +- docs/system/riscv/sifive_u.rst | 2 +- qapi/net.json | 14 ++++++++++---- net/tap.c | 17 +++++++++++------ qemu-options.hx | 8 ++++++-- 9 files changed, 52 insertions(+), 19 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 98c32991c9..61e775373d 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -71,6 +71,15 @@ flexible enough. The monitor objects have been converted to QOM, so ``-mon mode=control`` is replaced by ``-object monitor-qmp``. The short convenience options are not deprecated, only ``-mon``. +``script=no`` and ``downscript=no`` for ``-netdev tap`` (since 11.2) +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The special value ``"no"`` for the ``script`` and ``downscript`` +parameters of ``-netdev tap`` disables script execution. This special +treatment of ``"no"`` is deprecated. Use an empty string (``script=`` +or ``downscript=``) to disable script execution instead. In a future +version, ``"no"`` will be treated as a plain file name. + QEMU Machine Protocol (QMP) commands ------------------------------------ @@ -164,6 +173,15 @@ Use ``job-finalize`` instead. Use ``query-accelerators`` instead. +``"no"`` as value of ``script``/``downscript`` for tap in ``netdev_add`` (since 11.2) +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The special value ``"no"`` for the ``script`` and ``downscript`` +parameters of ``netdev_add`` with ``type=tap`` disables script +execution. This special treatment of ``"no"`` is deprecated. Use an +empty string instead. In a future version, ``"no"`` will be treated as +a plain file name. + Human Machine Protocol (HMP) commands ------------------------------------- diff --git a/docs/system/i386/microvm.rst b/docs/system/i386/microvm.rst index 1675e37d3e..077ea15751 100644 --- a/docs/system/i386/microvm.rst +++ b/docs/system/i386/microvm.rst @@ -79,7 +79,7 @@ legacy ``ISA serial`` device as console:: -serial stdio \ -drive id=test,file=test.img,format=raw,if=none \ -device virtio-blk-device,drive=test \ - -netdev tap,id=tap0,script=no,downscript=no \ + -netdev tap,id=tap0,script=,downscript= \ -device virtio-net-device,netdev=tap0 While the example above works, you might be interested in reducing the @@ -103,7 +103,7 @@ disabled:: -device virtconsole,chardev=virtiocon0 \ -drive id=test,file=test.img,format=raw,if=none \ -device virtio-blk-device,drive=test \ - -netdev tap,id=tap0,script=no,downscript=no \ + -netdev tap,id=tap0,script=,downscript= \ -device virtio-net-device,netdev=tap0 diff --git a/docs/system/i386/xenpvh.rst b/docs/system/i386/xenpvh.rst index 904778e3f5..862f38830b 100644 --- a/docs/system/i386/xenpvh.rst +++ b/docs/system/i386/xenpvh.rst @@ -42,7 +42,7 @@ case you need to construct one manually: -vnc none \ -display none \ -device virtio-net-pci,id=nic0,netdev=net0,mac=00:16:3e:5c:81:78 \ - -netdev type=tap,id=net0,ifname=vif3.0-emu,br=xenbr0,script=no,downscript=no \ + -netdev type=tap,id=net0,ifname=vif3.0-emu,br=xenbr0,script=,downscript= \ -smp 4,maxcpus=4 \ -nographic \ -machine xenpvh,ram-low-base=0,ram-low-size=2147483648,ram-high-base=4294967296,ram-high-size=2147483648,pci-ecam-base=824633720832,pci-ecam-size=268435456,pci-mmio-base=4026531840,pci-mmio-size=33554432,pci-mmio-high-base=824902156288,pci-mmio-high-size=68719476736 \ diff --git a/docs/system/ppc/ppce500.rst b/docs/system/ppc/ppce500.rst index c9fe0915dc..ec5aaf14fd 100644 --- a/docs/system/ppc/ppce500.rst +++ b/docs/system/ppc/ppce500.rst @@ -158,14 +158,14 @@ interface at PCI address 0.1.0, but we can switch that to an e1000 NIC by: $ qemu-system-ppc64 -M ppce500 -smp 4 -m 2G \ -display none -serial stdio \ -bios u-boot \ - -nic tap,ifname=tap0,script=no,downscript=no,model=e1000 + -nic tap,ifname=tap0,script=,downscript=,model=e1000 The QEMU ``ppce500`` machine can also dynamically instantiate an eTSEC device if “-device eTSEC” is given to QEMU: .. code-block:: bash - -netdev tap,ifname=tap0,script=no,downscript=no,id=net0 -device eTSEC,netdev=net0 + -netdev tap,ifname=tap0,script=,downscript=,id=net0 -device eTSEC,netdev=net0 Root file system on flash drive ------------------------------- diff --git a/docs/system/riscv/microchip-icicle-kit.rst b/docs/system/riscv/microchip-icicle-kit.rst index 9809e94b84..7fdb96601a 100644 --- a/docs/system/riscv/microchip-icicle-kit.rst +++ b/docs/system/riscv/microchip-icicle-kit.rst @@ -84,7 +84,7 @@ Then we can boot the machine by: $ qemu-system-riscv64 -M microchip-icicle-kit -smp 5 -m 2G \ -sd path/to/sdcard.img \ -nic user,model=cadence_gem \ - -nic tap,ifname=tap,model=cadence_gem,script=no \ + -nic tap,ifname=tap,model=cadence_gem,script= \ -display none -serial stdio \ -kernel path/to/u-boot/build/dir/u-boot.bin \ -dtb path/to/u-boot/build/dir/u-boot.dtb diff --git a/docs/system/riscv/sifive_u.rst b/docs/system/riscv/sifive_u.rst index 8f55ae8e31..0e4dcf3e70 100644 --- a/docs/system/riscv/sifive_u.rst +++ b/docs/system/riscv/sifive_u.rst @@ -199,7 +199,7 @@ To boot the VxWorks kernel in QEMU with the ``sifive_u`` machine, use: $ qemu-system-riscv64 -M sifive_u -smp 5 -m 2G \ -display none -serial stdio \ - -nic tap,ifname=tap0,script=no,downscript=no \ + -nic tap,ifname=tap0,script=,downscript= \ -kernel /path/to/vxWorks \ -append "gem(0,0)host:vxWorks h=192.168.200.1 e=192.168.200.2:ffffff00 u=target pw=vxTarget f=0x01" diff --git a/qapi/net.json b/qapi/net.json index ab8ed9c086..dccf95bbbc 100644 --- a/qapi/net.json +++ b/qapi/net.json @@ -399,15 +399,21 @@ # @fds: multiple file descriptors of already opened multiqueue capable # tap # -# @script: script to initialize the interface. An empty string or -# "no" disables script execution. Defaults to +# @script: script to initialize the interface. An empty string +# disables script execution. Defaults to # ``/qemu-ifup``, where ```` is the # system configuration directory at build time (typically /etc). +# Using "no" to disable script execution is deprecated (since +# 11.2); use an empty string instead. In a future version, "no" +# will be treated as a plain file name. # -# @downscript: script to shut down the interface. An empty string or -# "no" disables script execution. Defaults to +# @downscript: script to shut down the interface. An empty string +# disables script execution. Defaults to # ``/qemu-ifdown``, where ```` is the # system configuration directory at build time (typically /etc). +# Using "no" to disable script execution is deprecated (since +# 11.2); use an empty string instead. In a future version, "no" +# will be treated as a plain file name. # # @br: bridge name (since 2.8) # diff --git a/net/tap.c b/net/tap.c index 2076f5b780..f4051e8d4b 100644 --- a/net/tap.c +++ b/net/tap.c @@ -92,7 +92,8 @@ static void launch_script(const char *setup_script, const char *ifname, static void tap_send(void *opaque); static void tap_writable(void *opaque); -static bool tap_is_explicit_no_script(const char *script_arg_value) +static bool tap_is_explicit_no_script(const char *script_arg_name, + const char *script_arg_value) { if (!script_arg_value) { return false; @@ -103,16 +104,19 @@ static bool tap_is_explicit_no_script(const char *script_arg_value) } if (strcmp(script_arg_value, "no") == 0) { + warn_report("'%s=no' is deprecated; use '%s=' instead", + script_arg_name, script_arg_name); return true; } return false; } -static char *tap_parse_script(const char *script_arg_value, +static char *tap_parse_script(const char *script_arg_name, + const char *script_arg_value, const char *default_path) { - if (tap_is_explicit_no_script(script_arg_value)) { + if (tap_is_explicit_no_script(script_arg_name, script_arg_value)) { return NULL; } @@ -741,7 +745,7 @@ static bool net_init_tap_one(const NetdevTapOptions *tap, NetClientState *peer, qemu_set_info_str(&s->nc, "helper=%s", tap->helper); } else { qemu_set_info_str(&s->nc, "ifname=%s,script=%s,downscript=%s", ifname, - script ?: "no", downscript ?: "no"); + script ?: "", downscript ?: ""); if (downscript) { snprintf(s->down_script, sizeof(s->down_script), "%s", downscript); @@ -947,9 +951,10 @@ int net_init_tap(const Netdev *netdev, const char *name, } } else { g_autofree char *script = - tap_parse_script(tap->script, DEFAULT_NETWORK_SCRIPT); + tap_parse_script("script", tap->script, DEFAULT_NETWORK_SCRIPT); g_autofree char *downscript = - tap_parse_script(tap->downscript, DEFAULT_NETWORK_DOWN_SCRIPT); + tap_parse_script("downscript", tap->downscript, + DEFAULT_NETWORK_DOWN_SCRIPT); if (tap->ifname) { pstrcpy(ifname, sizeof ifname, tap->ifname); diff --git a/qemu-options.hx b/qemu-options.hx index 16ef7d5455..2f6863180b 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -3022,7 +3022,8 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, " use network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n" " to configure it and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n" " to deconfigure it\n" - " use '[down]script=no' or '[down]script=' to disable script execution\n" + " use '[down]script=' to disable script execution\n" + " ('[down]script=no' is deprecated and will be treated as a file name in future)\n" " use network helper 'helper' (default=" DEFAULT_BRIDGE_HELPER ") to\n" " configure it\n" " use 'fd=h' to connect to an already opened TAP interface\n" @@ -3561,7 +3562,10 @@ SRST ``/qemu-ifup`` and the default network deconfigure script is ``/qemu-ifdown``, where ```` is the system configuration directory at build time (typically ``/etc``). - Use ``[down]script=no`` or ``[down]script=`` to disable script execution. + Use ``[down]script=`` to disable script execution. + Using ``[down]script=no`` is deprecated; it disables script + execution now, but in a future version it will be treated as a + plain file name. If running QEMU as an unprivileged user, use the network helper to configure the TAP interface and attach it to the bridge. -- MST From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:04:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:04:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416046.1645215 (Exim 4.92) (envelope-from ) id 1x4xB3-0005m8-GZ; Fri, 11 Sep 2026 09:04:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416046.1645215; Fri, 11 Sep 2026 09:04:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xB3-0005m1-BL; Fri, 11 Sep 2026 09:04:09 +0000 Received: by outflank-mailman (input) for mailman id 1416046; Fri, 11 Sep 2026 09:04:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xB1-0005kp-O1 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:04:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xB1-003BIA-4V for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:04:07 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3c404-2eae-0a2a0a5409dd-0a2a4506da0e-6 for ; Fri, 11 Sep 2026 11:04:06 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3c405-195a-0a2a45060019-aa0a817cc45d-3 for ; Fri, 11 Sep 2026 11:04:06 +0200 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-175-7JgCgYNQPcuRven8zXkDgQ-1; Fri, 11 Sep 2026 05:04:02 -0400 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-49cd83ca361so6764125e9.1 for ; Fri, 11 Sep 2026 02:04:02 -0700 (PDT) Received: from redhat.com (IGLD-80-230-79-236.inter.net.il. [80.230.79.236]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb33e020sm4665942f8f.18.2026.09.11.02.03.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 02:03:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789117444; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wP5nj9MfiPsEKxjmqX6H5CG7YIoHYGFHlaBEBpbtyXc=; b=ZLTfcT9MBiUgWBjJ1Afb7XWB3SIvm6l5fWX+KbcPEvFoZxHhwaH/y069h+/3EOmbMVmp+U NMlFOVNdW8kq1nUoSjhVIo80LI09MhKNBcOL+Tc27StAOzn3uw3K06t1JZwOj1mcfqhHER TC7TTQi6FO94GhTlAVUCQkODxiN9GeQ= X-MC-Unique: 7JgCgYNQPcuRven8zXkDgQ-1 X-Mimecast-MFC-AGG-ID: 7JgCgYNQPcuRven8zXkDgQ_1789117442 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789117441; x=1789722241; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=wP5nj9MfiPsEKxjmqX6H5CG7YIoHYGFHlaBEBpbtyXc=; b=Mviz1yOk3Ex4pJqmvTpwcOy+QHPU7c8QWoCKTFH79B29koeV7b+nr2RqewT8H0ZBjU HQxmfVl1sQSjKw8iyIbYL2iNXtZlueDhdl8Pfs//UW1bkA5GMkht/IAhLhqGWHNSq2M8 bote6wa6m3y0MZ+brLzqIOmau7FLw1No6i0fX0CYO2vFzEWGT4jw+WsjeRO0sIRTUT43 zL5kXUEWwIHaeK5/lhg+/UctnlSEbK9KdcdicHZGYhZt4dEDjnOYDcPFCkpLuP+kcbdU w9UPPwA+VqlDyrPokABlUJbF4UfC7UKIjbJu5vw6mgRIYo+DFsMx+Vke9VnKjnHtxy3Y H5sg== X-Forwarded-Encrypted: i=1; AKwUvByjfTusScitFl7kv5mTLE7UOBK/j7cDVnhJXEiv09WUk7XfaKq8EmpZaC0Pd/N8d/qwFokpNrtOI1o=@lists.xenproject.org X-Gm-Message-State: AFuF++ncg1Iw70C7rTzbeNU3fWeN1Bkejom72d+mIgsTnZ3KbXBJr5kI IdP1b4o6nZf/YSUSUe3+dY4PJoqJ5Ye+yMXGDL9D32PtOz/N82Su7YWZ+Vk0TXBYEtQDeBWSWyy lpsI2+PELgtePELhRrD9tQy6MaP5wm1TyNdQ8rKBJqPzvpNCFNkHZ0X5df4ojxGTbyriY X-Gm-Gg: AYBFou1t54YQ/gxIxBiK/eqq5eKxL+j6N2obGdrjy8mW1zGSQirr0/gOsnPGc2O+IuC TxTth+5Zu6ETDgcSNSy/e5PqqLiuQr0juucW3/OVa0U/GMIASfjHWQStfZ1hEVEo8p1jBXT12ZB xopRA3HsBXIh2ghBt02dPlNHbE4ytY+Y8W23Ezof5wOT7WXo2a5x22mco1HsDmWY4x7ap/OZPWf DdvwQ9ut0dAeW46u1Ca/3J8vchjsB7MCokEfBxirqADf59/IYbfmgSRXCcGdYZuJP8DbmRfp9se NpVcfUGwgFDQTMW/ADdmvDDg99pM5GE4IixviKhsC8qzMpSUgXlzfByTLqRi2qAJtKwQLRM/EJt 5/efGdacT3wJdrHw4zYvvJoA= X-Received: by 2002:a05:600c:4fc8:b0:49c:cedc:3c36 with SMTP id 5b1f17b1804b1-49e619bd0femr35026225e9.16.1789117440216; Fri, 11 Sep 2026 02:04:00 -0700 (PDT) X-Received: by 2002:a05:600c:4fc8:b0:49c:cedc:3c36 with SMTP id 5b1f17b1804b1-49e619bd0femr35024785e9.16.1789117438990; Fri, 11 Sep 2026 02:03:58 -0700 (PDT) Date: Fri, 11 Sep 2026 05:03:52 -0400 From: "Michael S. Tsirkin" To: qemu-devel@nongnu.org Cc: Peter Maydell , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Igor Mammedov , Ani Sinha , Aurelien Jarno , Laurent Vivier , Amit Shah , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Paolo Bonzini , Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= , Sergio Lopez , Richard Henderson , Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Jason Wang , Keith Busch , Klaus Jensen , Jesper Devantier , Bernhard Beschow , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , Elena Ufimtseva , Jagannathan Raman , Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , Halil Pasic , Christian Borntraeger , Eric Farman , Farhan Ali , Cornelia Huck , Matthew Rosato , Ilya Leoshkevich , David Hildenbrand , Fam Zheng , Dmitry Fleytman , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Zhao Liu , FangSheng Huang , qemu-arm@nongnu.org, qemu-block@nongnu.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org Subject: [PULL v2 65/75] hw/hotplug: Constify HotplugHandler Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Mailer: git-send-email 2.51.2.2891.g4157995a80.dirty X-Mutt-Fcc: =sent X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: JDt-nFTBIePsUkkS8M68Gvot-asAqSw08RjNjdQ4Bcs_1789117442 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1789117446-FE0714DB-33620ADA/0/0 X-purgate-type: clean X-purgate-size: 99091 From: Philippe Mathieu-Daudé HotplugHandler value returned from qdev_get_hotplug_handler() points to the handler of and object implementing the TYPE_HOTPLUG_HANDLER interface. That handler mostly points to read-only section which shouldn't not be updated. Better protect it with the const qualifier. Mechanical change using 'sed' then manually adapted coding style. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-ID: <20260903230245.65601-5-philmd@oss.qualcomm.com> --- hw/s390x/ccw-device.h | 2 +- include/hw/acpi/cpu.h | 4 +-- include/hw/acpi/cpu_hotplug.h | 2 +- include/hw/acpi/generic_event_device.h | 3 +- include/hw/acpi/ich9.h | 10 +++--- include/hw/acpi/memory_hotplug.h | 4 +-- include/hw/acpi/pcihp.h | 8 ++--- include/hw/core/boards.h | 4 +-- include/hw/core/hotplug.h | 13 +++---- include/hw/core/qdev.h | 12 +++---- include/hw/i386/microvm.h | 4 +-- include/hw/i386/x86.h | 10 +++--- include/hw/mem/nvdimm.h | 2 +- include/hw/pci/pci_bridge.h | 6 ++-- include/hw/pci/pcie.h | 8 ++--- include/hw/pci/shpc.h | 6 ++-- include/hw/ppc/spapr_nvdimm.h | 2 +- hw/acpi/acpi-cpu-hotplug-stub.c | 4 +-- hw/acpi/acpi-mem-hotplug-stub.c | 4 +-- hw/acpi/acpi-nvdimm-stub.c | 2 +- hw/acpi/acpi-pci-hotplug-stub.c | 8 ++--- hw/acpi/cpu.c | 6 ++-- hw/acpi/generic_event_device.c | 11 +++--- hw/acpi/ich9.c | 10 +++--- hw/acpi/memory_hotplug.c | 6 ++-- hw/acpi/nvdimm.c | 2 +- hw/acpi/pcihp.c | 10 +++--- hw/acpi/piix4.c | 12 +++---- hw/arm/virt.c | 23 ++++++------ hw/char/virtio-serial-bus.c | 2 +- hw/core/hotplug.c | 8 ++--- hw/core/qdev-hotplug.c | 10 +++--- hw/core/qdev.c | 2 +- hw/i386/microvm.c | 12 +++---- hw/i386/pc.c | 28 +++++++-------- hw/i386/x86-common.c | 8 ++--- hw/intc/loongarch_dintc.c | 8 ++--- hw/intc/loongarch_extioi_common.c | 4 +-- hw/intc/loongarch_ipi.c | 4 +-- hw/loongarch/virt.c | 44 +++++++++++------------ hw/net/virtio-net.c | 4 +-- hw/nvme/ctrl.c | 8 ++--- hw/pci-bridge/pci_bridge_dev.c | 6 ++-- hw/pci/pcie.c | 10 +++--- hw/pci/pcie_port.c | 2 +- hw/pci/shpc.c | 10 +++--- hw/ppc/e500plat.c | 4 +-- hw/ppc/spapr.c | 48 +++++++++++++------------- hw/ppc/spapr_nvdimm.c | 2 +- hw/ppc/spapr_pci.c | 12 +++---- hw/remote/machine.c | 2 +- hw/riscv/virt.c | 6 ++-- hw/s390x/css-bridge.c | 2 +- hw/s390x/s390-pci-bus.c | 12 +++---- hw/s390x/s390-virtio-ccw.c | 16 ++++----- hw/s390x/virtio-ccw-md.c | 8 ++--- hw/s390x/virtio-ccw.c | 2 +- hw/scsi/virtio-scsi.c | 6 ++-- hw/scsi/vmw_pvscsi.c | 4 +-- hw/virtio/virtio-md-pci.c | 8 ++--- hw/xen/xen-bus.c | 2 +- stubs/hotplug-stubs.c | 6 ++-- system/qdev-monitor.c | 2 +- 63 files changed, 257 insertions(+), 253 deletions(-) diff --git a/hw/s390x/ccw-device.h b/hw/s390x/ccw-device.h index 15f64cfb63..c303f1de42 100644 --- a/hw/s390x/ccw-device.h +++ b/hw/s390x/ccw-device.h @@ -37,7 +37,7 @@ extern const VMStateDescription vmstate_ccw_dev; struct CCWDeviceClass { DeviceClass parent_class; - void (*unplug)(HotplugHandler *, DeviceState *, Error **); + void (*unplug)(const HotplugHandler *, DeviceState *, Error **); bool (*realize)(CcwDevice *, Error **); void (*refill_ids)(CcwDevice *); }; diff --git a/include/hw/acpi/cpu.h b/include/hw/acpi/cpu.h index 04c821d2b9..3664ac7a52 100644 --- a/include/hw/acpi/cpu.h +++ b/include/hw/acpi/cpu.h @@ -39,10 +39,10 @@ typedef struct CPUHotplugState { AcpiCpuStatus *devs; } CPUHotplugState; -void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_plug_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp); -void acpi_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp); diff --git a/include/hw/acpi/cpu_hotplug.h b/include/hw/acpi/cpu_hotplug.h index 5b670b04eb..bac40ccfa0 100644 --- a/include/hw/acpi/cpu_hotplug.h +++ b/include/hw/acpi/cpu_hotplug.h @@ -25,7 +25,7 @@ typedef struct AcpiCpuHotplug { uint8_t sts[ACPI_GPE_PROC_LEN]; } AcpiCpuHotplug; -void legacy_acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, +void legacy_acpi_cpu_plug_cb(const HotplugHandler *hotplug_dev, AcpiCpuHotplug *g, DeviceState *dev, Error **errp); void legacy_acpi_cpu_hotplug_init(MemoryRegion *parent, Object *owner, diff --git a/include/hw/acpi/generic_event_device.h b/include/hw/acpi/generic_event_device.h index 7cbfb5fe7d..42a8033a23 100644 --- a/include/hw/acpi/generic_event_device.h +++ b/include/hw/acpi/generic_event_device.h @@ -136,7 +136,8 @@ typedef struct AcpiGedClass { ResettablePhases parent_phases; } AcpiGedClass; -void build_ged_aml(Aml *table, const char* name, HotplugHandler *hotplug_dev, +void build_ged_aml(Aml *table, const char *name, + const HotplugHandler *hotplug_dev, uint32_t ged_irq, AmlRegionSpace rs, hwaddr ged_base); void acpi_dsdt_add_power_button(Aml *scope); diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h index 6d14544751..6956b2b9c9 100644 --- a/include/hw/acpi/ich9.h +++ b/include/hw/acpi/ich9.h @@ -85,15 +85,15 @@ void ich9_pm_reset_properties(ICH9LPCPMRegs *pm); void ich9_pm_add_class_properties(ObjectClass *oc, ptrdiff_t pm_offset); -void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void ich9_pm_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void ich9_pm_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -bool ich9_pm_is_hotpluggable_bus(HotplugHandler *hotplug_dev, BusState *bus); +bool ich9_pm_is_hotpluggable_bus(const HotplugHandler *hotplug_dev, BusState *bus); void ich9_pm_ospm_status(AcpiDeviceIf *adev, ACPIOSTInfoList ***list); #endif /* HW_ACPI_ICH9_H */ diff --git a/include/hw/acpi/memory_hotplug.h b/include/hw/acpi/memory_hotplug.h index eb7f460afe..6e4f82bcf9 100644 --- a/include/hw/acpi/memory_hotplug.h +++ b/include/hw/acpi/memory_hotplug.h @@ -36,9 +36,9 @@ typedef struct MemHotplugState { void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner, MemHotplugState *state, hwaddr io_base); -void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, +void acpi_memory_plug_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp); -void acpi_memory_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_memory_unplug_request_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp); void acpi_memory_unplug_cb(MemHotplugState *mem_st, diff --git a/include/hw/acpi/pcihp.h b/include/hw/acpi/pcihp.h index efce5fd2e1..21c0b72355 100644 --- a/include/hw/acpi/pcihp.h +++ b/include/hw/acpi/pcihp.h @@ -66,13 +66,13 @@ void acpi_pcihp_init(Object *owner, AcpiPciHpState *, MemoryRegion *io, uint16_t io_base); bool acpi_pcihp_is_hotpluggable_bus(AcpiPciHpState *s, BusState *bus); -void acpi_pcihp_device_pre_plug_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_plug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp); -void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_unplug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp); -void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_unplug_request_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp); diff --git a/include/hw/core/boards.h b/include/hw/core/boards.h index a436d48c8e..dba465efc2 100644 --- a/include/hw/core/boards.h +++ b/include/hw/core/boards.h @@ -322,8 +322,8 @@ struct MachineClass { SMPCompatProps smp_props; const char *default_ram_id; - HotplugHandler *(*get_hotplug_handler)(MachineState *machine, - DeviceState *dev); + const HotplugHandler *(*get_hotplug_handler)(MachineState *machine, + DeviceState *dev); bool (*hotplug_allowed)(MachineState *state, DeviceState *dev, Error **errp); CpuInstanceProperties (*cpu_index_to_instance_props)(MachineState *machine, diff --git a/include/hw/core/hotplug.h b/include/hw/core/hotplug.h index a9840ed485..0c69be60ee 100644 --- a/include/hw/core/hotplug.h +++ b/include/hw/core/hotplug.h @@ -30,7 +30,7 @@ typedef struct HotplugHandler HotplugHandler; * @plugged_dev: a device that has been (un)plugged * @errp: returns an error if this function fails */ -typedef void (*hotplug_fn)(HotplugHandler *plug_handler, +typedef void (*hotplug_fn)(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); /** @@ -59,7 +59,8 @@ struct HotplugHandlerClass { hotplug_fn plug; hotplug_fn unplug_request; hotplug_fn unplug; - bool (*is_hotpluggable_bus)(HotplugHandler *plug_handler, BusState *bus); + bool (*is_hotpluggable_bus)(const HotplugHandler *plug_handler, + BusState *bus); }; /** @@ -67,7 +68,7 @@ struct HotplugHandlerClass { * * Call #HotplugHandlerClass.plug callback of @plug_handler. */ -void hotplug_handler_plug(HotplugHandler *plug_handler, +void hotplug_handler_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); @@ -76,7 +77,7 @@ void hotplug_handler_plug(HotplugHandler *plug_handler, * * Call #HotplugHandlerClass.pre_plug callback of @plug_handler. */ -void hotplug_handler_pre_plug(HotplugHandler *plug_handler, +void hotplug_handler_pre_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); @@ -85,7 +86,7 @@ void hotplug_handler_pre_plug(HotplugHandler *plug_handler, * * Calls #HotplugHandlerClass.unplug_request callback of @plug_handler. */ -void hotplug_handler_unplug_request(HotplugHandler *plug_handler, +void hotplug_handler_unplug_request(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); /** @@ -93,7 +94,7 @@ void hotplug_handler_unplug_request(HotplugHandler *plug_handler, * * Calls #HotplugHandlerClass.unplug callback of @plug_handler. */ -void hotplug_handler_unplug(HotplugHandler *plug_handler, +void hotplug_handler_unplug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp); #endif diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h index e4cb027ab3..1f6bf3fc1a 100644 --- a/include/hw/core/qdev.h +++ b/include/hw/core/qdev.h @@ -386,7 +386,7 @@ struct BusState { /* public: */ DeviceState *parent; char *name; - HotplugHandler *hotplug_handler; + const HotplugHandler *hotplug_handler; int max_index; bool realized; bool full; @@ -514,8 +514,8 @@ bool qdev_realize_and_unref(DeviceState *dev, BusState *bus, Error **errp); void qdev_unrealize(DeviceState *dev); void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id, int required_for_version); -HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev); -HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev); +const HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev); +const HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev); bool qdev_hotplug_allowed(DeviceState *dev, BusState *bus, Error **errp); bool qdev_hotunplug_allowed(DeviceState *dev, Error **errp); @@ -529,10 +529,10 @@ bool qdev_hotunplug_allowed(DeviceState *dev, Error **errp); * Return: pointer to object that implements TYPE_HOTPLUG_HANDLER interface * or NULL if there aren't any. */ -HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev); +const HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev); void qdev_unplug(DeviceState *dev, Error **errp); int qdev_sync_config(DeviceState *dev, Error **errp); -void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev, +void qdev_simple_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); void qdev_machine_creation_done(void); bool qdev_machine_modified(void); @@ -1065,7 +1065,7 @@ void qbus_set_bus_hotplug_handler(BusState *bus); static inline bool qbus_is_hotpluggable(BusState *bus) { - HotplugHandler *plug_handler = bus->hotplug_handler; + const HotplugHandler *plug_handler = bus->hotplug_handler; bool ret = !!plug_handler; if (plug_handler) { diff --git a/include/hw/i386/microvm.h b/include/hw/i386/microvm.h index 184b7a8c09..5d5eacd1c6 100644 --- a/include/hw/i386/microvm.h +++ b/include/hw/i386/microvm.h @@ -76,8 +76,8 @@ struct MicrovmMachineClass { X86MachineClass parent; - HotplugHandler *(*orig_hotplug_handler)(MachineState *machine, - DeviceState *dev); + const HotplugHandler *(*orig_hotplug_handler)(MachineState *machine, + DeviceState *dev); void (*x86_load_linux)(X86MachineState *x86ms, FWCfgState *fw_cfg, int acpi_data_size); }; diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h index 71fe6b5e12..abb073ca47 100644 --- a/include/hw/i386/x86.h +++ b/include/hw/i386/x86.h @@ -46,7 +46,7 @@ struct X86MachineState { qemu_irq *gsi; DeviceState *ioapic2; GMappedFile *initrd_mapped_file; - HotplugHandler *acpi_dev; + const HotplugHandler *acpi_dev; /* * Map the whole BIOS just underneath the 4 GiB address boundary. Only used @@ -112,13 +112,13 @@ uint32_t x86_cpu_apic_id_from_index(X86MachineState *x86ms, void x86_cpus_init(X86MachineState *pcms, int default_cpu_version); void x86_rtc_set_cpus_count(ISADevice *rtc, uint16_t cpus_count); -void x86_cpu_pre_plug(HotplugHandler *hotplug_dev, +void x86_cpu_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void x86_cpu_plug(HotplugHandler *hotplug_dev, +void x86_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void x86_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev, +void x86_cpu_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); void x86_isa_bios_init(MemoryRegion *isa_bios, MemoryRegion *isa_memory, diff --git a/include/hw/mem/nvdimm.h b/include/hw/mem/nvdimm.h index d3b763453a..169a943e3c 100644 --- a/include/hw/mem/nvdimm.h +++ b/include/hw/mem/nvdimm.h @@ -157,5 +157,5 @@ void nvdimm_build_acpi(GArray *table_offsets, GArray *table_data, uint32_t ram_slots, const char *oem_id, const char *oem_table_id); void nvdimm_plug(NVDIMMState *state); -void nvdimm_acpi_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev); +void nvdimm_acpi_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev); #endif diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h index b61360b900..f114f0a651 100644 --- a/include/hw/pci/pci_bridge.h +++ b/include/hw/pci/pci_bridge.h @@ -141,11 +141,11 @@ void pci_bridge_reset(DeviceState *qdev); void pci_bridge_initfn(PCIDevice *pci_dev, const char *typename); void pci_bridge_exitfn(PCIDevice *pci_dev); -void pci_bridge_dev_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pci_bridge_dev_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pci_bridge_dev_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pci_bridge_dev_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pci_bridge_dev_unplug_request_cb(HotplugHandler *hotplug_dev, +void pci_bridge_dev_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); /* diff --git a/include/hw/pci/pcie.h b/include/hw/pci/pcie.h index 71ba94874b..ec25e7a7de 100644 --- a/include/hw/pci/pcie.h +++ b/include/hw/pci/pcie.h @@ -146,13 +146,13 @@ void pcie_ats_init(PCIDevice *dev, uint16_t offset, bool aligned); void pcie_cap_fill_link_ep_usp(PCIDevice *dev, PCIExpLinkWidth width, PCIExpLinkSpeed speed, bool flitmode); -void pcie_cap_slot_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pcie_cap_slot_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pcie_cap_slot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_dev, +void pcie_cap_slot_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); void pcie_pasid_common_init(PCIDevice *dev, uint16_t offset, diff --git a/include/hw/pci/shpc.h b/include/hw/pci/shpc.h index fce5bdd3bc..67becb5c56 100644 --- a/include/hw/pci/shpc.h +++ b/include/hw/pci/shpc.h @@ -45,11 +45,11 @@ void shpc_free(PCIDevice *dev); void shpc_cap_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int len); -void shpc_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void shpc_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void shpc_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void shpc_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); -void shpc_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void shpc_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp); extern const VMStateInfo shpc_vmstate_info; diff --git a/include/hw/ppc/spapr_nvdimm.h b/include/hw/ppc/spapr_nvdimm.h index e9436cb6ef..386da92042 100644 --- a/include/hw/ppc/spapr_nvdimm.h +++ b/include/hw/ppc/spapr_nvdimm.h @@ -18,7 +18,7 @@ typedef struct SpaprMachineState SpaprMachineState; int spapr_pmem_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr, void *fdt, int *fdt_start_offset, Error **errp); void spapr_dt_persistent_memory(SpaprMachineState *spapr, void *fdt); -bool spapr_nvdimm_validate(HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm, +bool spapr_nvdimm_validate(const HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm, uint64_t size, Error **errp); void spapr_add_nvdimm(DeviceState *dev, uint64_t slot); void spapr_nvdimm_finish_flushes(void); diff --git a/hw/acpi/acpi-cpu-hotplug-stub.c b/hw/acpi/acpi-cpu-hotplug-stub.c index 72c5f05f5c..2e05d7100b 100644 --- a/hw/acpi/acpi-cpu-hotplug-stub.c +++ b/hw/acpi/acpi-cpu-hotplug-stub.c @@ -14,7 +14,7 @@ void acpi_cpu_ospm_status(CPUHotplugState *cpu_st, ACPIOSTInfoList ***list) { } -void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_plug_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp) { } @@ -24,7 +24,7 @@ void acpi_cpu_unplug_cb(CPUHotplugState *cpu_st, { } -void acpi_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/acpi-mem-hotplug-stub.c b/hw/acpi/acpi-mem-hotplug-stub.c index 7ad0fdcdf2..c218813fd1 100644 --- a/hw/acpi/acpi-mem-hotplug-stub.c +++ b/hw/acpi/acpi-mem-hotplug-stub.c @@ -13,7 +13,7 @@ void acpi_memory_ospm_status(MemHotplugState *mem_st, ACPIOSTInfoList ***list) { } -void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, +void acpi_memory_plug_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp) { } @@ -23,7 +23,7 @@ void acpi_memory_unplug_cb(MemHotplugState *mem_st, { } -void acpi_memory_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_memory_unplug_request_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/acpi-nvdimm-stub.c b/hw/acpi/acpi-nvdimm-stub.c index 22ba17f511..0120bacaac 100644 --- a/hw/acpi/acpi-nvdimm-stub.c +++ b/hw/acpi/acpi-nvdimm-stub.c @@ -2,6 +2,6 @@ #include "hw/mem/nvdimm.h" #include "hw/core/hotplug.h" -void nvdimm_acpi_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev) +void nvdimm_acpi_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev) { } diff --git a/hw/acpi/acpi-pci-hotplug-stub.c b/hw/acpi/acpi-pci-hotplug-stub.c index d58ea726a8..20625c7ed7 100644 --- a/hw/acpi/acpi-pci-hotplug-stub.c +++ b/hw/acpi/acpi-pci-hotplug-stub.c @@ -9,22 +9,22 @@ void acpi_pcihp_init(Object *owner, AcpiPciHpState *s, { } -void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_plug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { } -void acpi_pcihp_device_pre_plug_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { } -void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_unplug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { } -void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_unplug_request_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c index d63ca83c1b..ef97ed779a 100644 --- a/hw/acpi/cpu.c +++ b/hw/acpi/cpu.c @@ -132,7 +132,7 @@ static void cpu_hotplug_wr(void *opaque, hwaddr addr, uint64_t data, trace_cpuhp_acpi_clear_remove_evt(cpu_st->selector); } else if (data & 8) { DeviceState *dev = NULL; - HotplugHandler *hotplug_ctrl = NULL; + const HotplugHandler *hotplug_ctrl; if (!cdev->cpu || cdev->cpu == first_cpu) { trace_cpuhp_acpi_ejecting_invalid_cpu(cpu_st->selector); @@ -247,7 +247,7 @@ static AcpiCpuStatus *get_cpu_status(CPUHotplugState *cpu_st, DeviceState *dev) return NULL; } -void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_plug_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp) { AcpiCpuStatus *cdev; @@ -264,7 +264,7 @@ void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev, } } -void acpi_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, CPUHotplugState *cpu_st, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c index 5225e32513..65a5d1612f 100644 --- a/hw/acpi/generic_event_device.c +++ b/hw/acpi/generic_event_device.c @@ -45,7 +45,8 @@ static const uint32_t ged_supported_events[] = { * affected by the interrupt. This way, we can support up to 32 events * with a unique interrupt. */ -void build_ged_aml(Aml *table, const char *name, HotplugHandler *hotplug_dev, +void build_ged_aml(Aml *table, const char *name, + const HotplugHandler *hotplug_dev, uint32_t ged_irq, AmlRegionSpace rs, hwaddr ged_base) { const AcpiGedState *s = ACPI_GED(hotplug_dev); @@ -250,7 +251,7 @@ static const MemoryRegionOps ged_regs_ops = { }, }; -static void acpi_ged_device_pre_plug_cb(HotplugHandler *hotplug_dev, +static void acpi_ged_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { @@ -258,7 +259,7 @@ static void acpi_ged_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -static void acpi_ged_device_plug_cb(HotplugHandler *hotplug_dev, +static void acpi_ged_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { AcpiGedState *s = ACPI_GED(hotplug_dev); @@ -279,7 +280,7 @@ static void acpi_ged_device_plug_cb(HotplugHandler *hotplug_dev, } } -static void acpi_ged_unplug_request_cb(HotplugHandler *hotplug_dev, +static void acpi_ged_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { AcpiGedState *s = ACPI_GED(hotplug_dev); @@ -298,7 +299,7 @@ static void acpi_ged_unplug_request_cb(HotplugHandler *hotplug_dev, } } -static void acpi_ged_unplug_cb(HotplugHandler *hotplug_dev, +static void acpi_ged_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { AcpiGedState *s = ACPI_GED(hotplug_dev); diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c index 8082eae428..6d421b990c 100644 --- a/hw/acpi/ich9.c +++ b/hw/acpi/ich9.c @@ -410,7 +410,7 @@ void ich9_pm_add_class_properties(ObjectClass *oc, ptrdiff_t pm_offset) #undef PM_REG_FIELD -void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); @@ -432,7 +432,7 @@ void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, } } -void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); @@ -455,7 +455,7 @@ void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, } } -void ich9_pm_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void ich9_pm_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); @@ -489,7 +489,7 @@ void ich9_pm_device_unplug_request_cb(HotplugHandler *hotplug_dev, } } -void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void ich9_pm_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); @@ -507,7 +507,7 @@ void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, } } -bool ich9_pm_is_hotpluggable_bus(HotplugHandler *hotplug_dev, BusState *bus) +bool ich9_pm_is_hotpluggable_bus(const HotplugHandler *hotplug_dev, BusState *bus) { ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev); return acpi_pcihp_is_hotpluggable_bus(&lpc->pm.acpi_pci_hotplug, bus); diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c index f482c835a1..b5b6d6ada6 100644 --- a/hw/acpi/memory_hotplug.c +++ b/hw/acpi/memory_hotplug.c @@ -166,7 +166,7 @@ static void acpi_memory_hotplug_write(void *opaque, hwaddr addr, uint64_t data, mdev->is_removing = false; trace_mhp_acpi_clear_remove_evt(mem_st->selector); } else if (data & 8) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; if (!mdev->is_enabled) { trace_mhp_acpi_ejecting_invalid_slot(mem_st->selector); @@ -254,7 +254,7 @@ acpi_memory_slot_status(MemHotplugState *mem_st, return &mem_st->devs[slot]; } -void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, +void acpi_memory_plug_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp) { MemStatus *mdev; @@ -277,7 +277,7 @@ void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st, } } -void acpi_memory_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_memory_unplug_request_cb(const HotplugHandler *hotplug_dev, MemHotplugState *mem_st, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c index 703e854951..5a7ff1ede8 100644 --- a/hw/acpi/nvdimm.c +++ b/hw/acpi/nvdimm.c @@ -887,7 +887,7 @@ static const MemoryRegionOps nvdimm_dsm_ops = { }, }; -void nvdimm_acpi_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev) +void nvdimm_acpi_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev) { if (dev->hotplugged) { acpi_send_event(DEVICE(hotplug_dev), ACPI_NVDIMM_HOTPLUG_STATUS); diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c index 336ebe1a13..b69379a18b 100644 --- a/hw/acpi/pcihp.c +++ b/hw/acpi/pcihp.c @@ -209,7 +209,7 @@ static void acpi_pcihp_eject_slot(AcpiPciHpState *s, unsigned bsel, unsigned slo */ qdev->pending_deleted_event = false; } else { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; hotplug_ctrl = qdev_get_hotplug_handler(qdev); hotplug_handler_unplug(hotplug_ctrl, qdev, &error_abort); @@ -261,7 +261,7 @@ void acpi_pcihp_reset(AcpiPciHpState *s) acpi_pcihp_update(s); } -void acpi_pcihp_device_pre_plug_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pdev = PCI_DEVICE(dev); @@ -275,7 +275,7 @@ void acpi_pcihp_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_plug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { PCIDevice *pdev = PCI_DEVICE(dev); @@ -317,7 +317,7 @@ void acpi_pcihp_device_plug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, acpi_send_event(DEVICE(hotplug_dev), ACPI_PCI_HOTPLUG_STATUS); } -void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, +void acpi_pcihp_device_unplug_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { PCIDevice *pdev = PCI_DEVICE(dev); @@ -328,7 +328,7 @@ void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, AcpiPciHpState *s, qdev_unrealize(dev); } -void acpi_pcihp_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void acpi_pcihp_device_unplug_request_cb(const HotplugHandler *hotplug_dev, AcpiPciHpState *s, DeviceState *dev, Error **errp) { diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c index 52bd61667f..a7d5356340 100644 --- a/hw/acpi/piix4.c +++ b/hw/acpi/piix4.c @@ -303,8 +303,8 @@ static void piix4_pm_powerdown_req(Notifier *n, void *opaque) acpi_pm1_evt_power_down(&s->ar); } -static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void piix4_device_pre_plug_cb(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); @@ -323,7 +323,7 @@ static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -static void piix4_device_plug_cb(HotplugHandler *hotplug_dev, +static void piix4_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); @@ -344,7 +344,7 @@ static void piix4_device_plug_cb(HotplugHandler *hotplug_dev, } } -static void piix4_device_unplug_request_cb(HotplugHandler *hotplug_dev, +static void piix4_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); @@ -364,7 +364,7 @@ static void piix4_device_unplug_request_cb(HotplugHandler *hotplug_dev, } } -static void piix4_device_unplug_cb(HotplugHandler *hotplug_dev, +static void piix4_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); @@ -383,7 +383,7 @@ static void piix4_device_unplug_cb(HotplugHandler *hotplug_dev, } } -static bool piix4_is_hotpluggable_bus(HotplugHandler *hotplug_dev, +static bool piix4_is_hotpluggable_bus(const HotplugHandler *hotplug_dev, BusState *bus) { PIIX4PMState *s = PIIX4_PM(hotplug_dev); diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 0871a35e11..3eecf094bc 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -3753,7 +3753,7 @@ static const CPUArchIdList *virt_possible_cpu_arch_ids(MachineState *ms) return ms->possible_cpus; } -static void virt_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void virt_memory_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3779,7 +3779,7 @@ static void virt_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp); } -static void virt_memory_plug(HotplugHandler *hotplug_dev, +static void virt_memory_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3798,7 +3798,7 @@ static void virt_memory_plug(HotplugHandler *hotplug_dev, } } -static void virt_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, +static void virt_machine_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3896,7 +3896,7 @@ static void virt_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev, +static void virt_machine_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3957,7 +3957,7 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev, } } -static void virt_dimm_unplug_request(HotplugHandler *hotplug_dev, +static void virt_dimm_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3977,7 +3977,7 @@ static void virt_dimm_unplug_request(HotplugHandler *hotplug_dev, errp); } -static void virt_dimm_unplug(HotplugHandler *hotplug_dev, +static void virt_dimm_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtMachineState *vms = VIRT_MACHINE(hotplug_dev); @@ -3995,8 +3995,9 @@ out: error_propagate(errp, local_err); } -static void virt_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void +virt_machine_device_unplug_request_cb(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { virt_dimm_unplug_request(hotplug_dev, dev, errp); @@ -4009,7 +4010,7 @@ static void virt_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev, } } -static void virt_machine_device_unplug_cb(HotplugHandler *hotplug_dev, +static void virt_machine_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -4022,8 +4023,8 @@ static void virt_machine_device_unplug_cb(HotplugHandler *hotplug_dev, } } -static HotplugHandler *virt_machine_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler * +virt_machine_get_hotplug_handler(MachineState *machine, DeviceState *dev) { MachineClass *mc = MACHINE_GET_CLASS(machine); diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c index 81db0bdc91..c36e18a4cf 100644 --- a/hw/char/virtio-serial-bus.c +++ b/hw/char/virtio-serial-bus.c @@ -979,7 +979,7 @@ static void virtser_port_device_realize(DeviceState *dev, Error **errp) port->elem = NULL; } -static void virtser_port_device_plug(HotplugHandler *hotplug_dev, +static void virtser_port_device_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(dev); diff --git a/hw/core/hotplug.c b/hw/core/hotplug.c index 00e80a67c8..3aca068840 100644 --- a/hw/core/hotplug.c +++ b/hw/core/hotplug.c @@ -13,7 +13,7 @@ #include "hw/core/hotplug.h" #include "qemu/module.h" -void hotplug_handler_pre_plug(HotplugHandler *plug_handler, +void hotplug_handler_pre_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { @@ -24,7 +24,7 @@ void hotplug_handler_pre_plug(HotplugHandler *plug_handler, } } -void hotplug_handler_plug(HotplugHandler *plug_handler, +void hotplug_handler_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { @@ -35,7 +35,7 @@ void hotplug_handler_plug(HotplugHandler *plug_handler, } } -void hotplug_handler_unplug_request(HotplugHandler *plug_handler, +void hotplug_handler_unplug_request(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { @@ -46,7 +46,7 @@ void hotplug_handler_unplug_request(HotplugHandler *plug_handler, } } -void hotplug_handler_unplug(HotplugHandler *plug_handler, +void hotplug_handler_unplug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { diff --git a/hw/core/qdev-hotplug.c b/hw/core/qdev-hotplug.c index 1d547e0dbd..d7fa8a5ed2 100644 --- a/hw/core/qdev-hotplug.c +++ b/hw/core/qdev-hotplug.c @@ -14,7 +14,7 @@ #include "hw/core/boards.h" #include "qapi/error.h" -HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev) +const HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev) { MachineState *machine; MachineClass *mc; @@ -90,7 +90,7 @@ bool qdev_hotunplug_allowed(DeviceState *dev, Error **errp) qdev_hotplug_unplug_allowed_common(dev, dev->parent_bus, errp); } -HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev) +const HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev) { if (dev->parent_bus) { return dev->parent_bus->hotplug_handler; @@ -98,9 +98,9 @@ HotplugHandler *qdev_get_bus_hotplug_handler(DeviceState *dev) return NULL; } -HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) +const HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_machine_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_machine_hotplug_handler(dev); if (hotplug_ctrl == NULL && dev->parent_bus) { hotplug_ctrl = qdev_get_bus_hotplug_handler(dev); @@ -109,7 +109,7 @@ HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) } /* can be used as ->unplug() callback for the simple cases */ -void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev, +void qdev_simple_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { qdev_unrealize(dev); diff --git a/hw/core/qdev.c b/hw/core/qdev.c index 0b0f2f47fa..c6540bec56 100644 --- a/hw/core/qdev.c +++ b/hw/core/qdev.c @@ -501,7 +501,7 @@ static void device_set_realized(Object *obj, bool value, Error **errp) { DeviceState *dev = DEVICE(obj); DeviceClass *dc = DEVICE_GET_CLASS(dev); - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; BusState *bus; NamedClockList *ncl; Error *local_err = NULL; diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c index e7adab7d2e..a49de33749 100644 --- a/hw/i386/microvm.c +++ b/hw/i386/microvm.c @@ -416,7 +416,7 @@ static void microvm_fix_kernel_cmdline(MachineState *machine) g_free(cmdline); } -static void microvm_device_pre_plug_cb(HotplugHandler *hotplug_dev, +static void microvm_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { X86CPU *cpu = X86_CPU(dev); @@ -425,26 +425,26 @@ static void microvm_device_pre_plug_cb(HotplugHandler *hotplug_dev, x86_cpu_pre_plug(hotplug_dev, dev, errp); } -static void microvm_device_plug_cb(HotplugHandler *hotplug_dev, +static void microvm_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { x86_cpu_plug(hotplug_dev, dev, errp); } -static void microvm_device_unplug_request_cb(HotplugHandler *hotplug_dev, +static void microvm_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { error_setg(errp, "unplug not supported by microvm"); } -static void microvm_device_unplug_cb(HotplugHandler *hotplug_dev, +static void microvm_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { error_setg(errp, "unplug not supported by microvm"); } -static HotplugHandler *microvm_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *microvm_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) { return HOTPLUG_HANDLER(machine); diff --git a/hw/i386/pc.c b/hw/i386/pc.c index e9e4fc262b..9006e7c29e 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1181,7 +1181,7 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs) g_free(i8259); } -static void pc_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void pc_memory_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { const X86MachineState *x86ms = X86_MACHINE(hotplug_dev); @@ -1214,7 +1214,7 @@ static void pc_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp); } -static void pc_memory_plug(HotplugHandler *hotplug_dev, +static void pc_memory_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCMachineState *pcms = PC_MACHINE(hotplug_dev); @@ -1231,7 +1231,7 @@ static void pc_memory_plug(HotplugHandler *hotplug_dev, hotplug_handler_plug(x86ms->acpi_dev, dev, &error_abort); } -static void pc_memory_unplug_request(HotplugHandler *hotplug_dev, +static void pc_memory_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { X86MachineState *x86ms = X86_MACHINE(hotplug_dev); @@ -1256,7 +1256,7 @@ static void pc_memory_unplug_request(HotplugHandler *hotplug_dev, errp); } -static void pc_memory_unplug(HotplugHandler *hotplug_dev, +static void pc_memory_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCMachineState *pcms = PC_MACHINE(hotplug_dev); @@ -1274,7 +1274,7 @@ static void pc_memory_unplug(HotplugHandler *hotplug_dev, error_propagate(errp, local_err); } -static void pc_hv_balloon_pre_plug(HotplugHandler *hotplug_dev, +static void pc_hv_balloon_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { /* The vmbus handler has no hotplug handler; we should never end up here. */ @@ -1282,13 +1282,13 @@ static void pc_hv_balloon_pre_plug(HotplugHandler *hotplug_dev, memory_device_pre_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev), errp); } -static void pc_hv_balloon_plug(HotplugHandler *hotplug_dev, +static void pc_hv_balloon_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { memory_device_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev)); } -static void pc_sp_mem_pre_plug(HotplugHandler *hotplug_dev, +static void pc_sp_mem_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { MachineState *ms = MACHINE(hotplug_dev); @@ -1304,7 +1304,7 @@ static void pc_sp_mem_pre_plug(HotplugHandler *hotplug_dev, memory_device_pre_plug(MEMORY_DEVICE(dev), ms, errp); } -static void pc_sp_mem_plug(HotplugHandler *hotplug_dev, +static void pc_sp_mem_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpMemDevice *spm = SP_MEM(dev); @@ -1318,7 +1318,7 @@ static void pc_sp_mem_plug(HotplugHandler *hotplug_dev, e820_add_entry(addr, size, E820_SOFT_RESERVED); } -static void pc_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, +static void pc_machine_device_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -1356,7 +1356,7 @@ static void pc_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev, } } -static void pc_machine_device_plug_cb(HotplugHandler *hotplug_dev, +static void pc_machine_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -1372,7 +1372,7 @@ static void pc_machine_device_plug_cb(HotplugHandler *hotplug_dev, } } -static void pc_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev, +static void pc_machine_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -1388,7 +1388,7 @@ static void pc_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev, } } -static void pc_machine_device_unplug_cb(HotplugHandler *hotplug_dev, +static void pc_machine_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -1403,8 +1403,8 @@ static void pc_machine_device_unplug_cb(HotplugHandler *hotplug_dev, } } -static HotplugHandler *pc_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *pc_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) || object_dynamic_cast(OBJECT(dev), TYPE_SP_MEM) || diff --git a/hw/i386/x86-common.c b/hw/i386/x86-common.c index 8f9419e7d3..ae58352760 100644 --- a/hw/i386/x86-common.c +++ b/hw/i386/x86-common.c @@ -158,7 +158,7 @@ static CPUArchId *x86_find_cpu_slot(MachineState *ms, uint32_t id, int *idx) return found_cpu; } -void x86_cpu_plug(HotplugHandler *hotplug_dev, +void x86_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CPUArchId *found_cpu; @@ -199,7 +199,7 @@ out: error_propagate(errp, local_err); } -void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, +void x86_cpu_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { int idx = -1; @@ -222,7 +222,7 @@ void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev, errp); } -void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev, +void x86_cpu_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CPUArchId *found_cpu; @@ -248,7 +248,7 @@ void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev, error_propagate(errp, local_err); } -void x86_cpu_pre_plug(HotplugHandler *hotplug_dev, +void x86_cpu_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { int idx; diff --git a/hw/intc/loongarch_dintc.c b/hw/intc/loongarch_dintc.c index c01f1fe07e..1bedfbce43 100644 --- a/hw/intc/loongarch_dintc.c +++ b/hw/intc/loongarch_dintc.c @@ -168,8 +168,8 @@ static DINTCCore *loongarch_dintc_get_cpu(LoongArchDINTCState *s, return loongarch_dintc_cpu_by_arch_id(s, arch_id); } -static void loongarch_dintc_cpu_plug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void loongarch_dintc_cpu_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchDINTCState *s = LOONGARCH_DINTC(hotplug_dev); Object *obj = OBJECT(dev); @@ -194,8 +194,8 @@ static void loongarch_dintc_cpu_plug(HotplugHandler *hotplug_dev, return; } -static void loongarch_dintc_cpu_unplug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void loongarch_dintc_cpu_unplug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchDINTCState *s = LOONGARCH_DINTC(hotplug_dev); Object *obj = OBJECT(dev); diff --git a/hw/intc/loongarch_extioi_common.c b/hw/intc/loongarch_extioi_common.c index 5cb0d396c6..22cbb7a097 100644 --- a/hw/intc/loongarch_extioi_common.c +++ b/hw/intc/loongarch_extioi_common.c @@ -28,7 +28,7 @@ static ExtIOICore *loongarch_extioi_get_cpu(LoongArchExtIOICommonState *s, return NULL; } -static void loongarch_extioi_cpu_plug(HotplugHandler *hotplug_dev, +static void loongarch_extioi_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongArchExtIOICommonState *s = LOONGARCH_EXTIOI_COMMON(hotplug_dev); @@ -60,7 +60,7 @@ static void loongarch_extioi_cpu_plug(HotplugHandler *hotplug_dev, } } -static void loongarch_extioi_cpu_unplug(HotplugHandler *hotplug_dev, +static void loongarch_extioi_cpu_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongArchExtIOICommonState *s = LOONGARCH_EXTIOI_COMMON(hotplug_dev); diff --git a/hw/intc/loongarch_ipi.c b/hw/intc/loongarch_ipi.c index 28d816e3f5..c8f775a93e 100644 --- a/hw/intc/loongarch_ipi.c +++ b/hw/intc/loongarch_ipi.c @@ -129,7 +129,7 @@ static void loongarch_ipi_reset_hold(Object *obj, ResetType type) } } -static void loongarch_ipi_cpu_plug(HotplugHandler *hotplug_dev, +static void loongarch_ipi_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongsonIPICommonState *lics = LOONGSON_IPI_COMMON(hotplug_dev); @@ -155,7 +155,7 @@ static void loongarch_ipi_cpu_plug(HotplugHandler *hotplug_dev, qdev_connect_gpio_out(DEVICE(lics), index, qdev_get_gpio_in(dev, IRQ_IPI)); } -static void loongarch_ipi_cpu_unplug(HotplugHandler *hotplug_dev, +static void loongarch_ipi_cpu_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongsonIPICommonState *lics = LOONGSON_IPI_COMMON(hotplug_dev); diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 9cc79929a8..9c5371af9d 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -1167,7 +1167,7 @@ static CPUArchId *virt_find_empty_cpu_slot(MachineState *ms) return NULL; } -static void virt_cpu_pre_plug(HotplugHandler *hotplug_dev, +static void virt_cpu_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1229,7 +1229,7 @@ static void virt_cpu_pre_plug(HotplugHandler *hotplug_dev, numa_cpu_pre_plug(cpu_slot, dev, errp); } -static void virt_cpu_unplug_request(HotplugHandler *hotplug_dev, +static void virt_cpu_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1246,7 +1246,7 @@ static void virt_cpu_unplug_request(HotplugHandler *hotplug_dev, hotplug_handler_unplug_request(HOTPLUG_HANDLER(lvms->acpi_ged), dev, errp); } -static void virt_cpu_unplug(HotplugHandler *hotplug_dev, +static void virt_cpu_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CPUArchId *cpu_slot; @@ -1268,7 +1268,7 @@ static void virt_cpu_unplug(HotplugHandler *hotplug_dev, cpu_slot->cpu = NULL; } -static void virt_cpu_plug(HotplugHandler *hotplug_dev, +static void virt_cpu_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CPUArchId *cpu_slot; @@ -1304,14 +1304,14 @@ static bool memhp_type_supported(DeviceState *dev) !object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM); } -static void virt_mem_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +static void virt_mem_pre_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp); } -static void virt_device_pre_plug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_device_pre_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { if (memhp_type_supported(dev)) { virt_mem_pre_plug(hotplug_dev, dev, errp); @@ -1320,8 +1320,8 @@ static void virt_device_pre_plug(HotplugHandler *hotplug_dev, } } -static void virt_mem_unplug_request(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_mem_unplug_request(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1330,8 +1330,8 @@ static void virt_mem_unplug_request(HotplugHandler *hotplug_dev, errp); } -static void virt_device_unplug_request(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_device_unplug_request(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { if (memhp_type_supported(dev)) { virt_mem_unplug_request(hotplug_dev, dev, errp); @@ -1340,8 +1340,8 @@ static void virt_device_unplug_request(HotplugHandler *hotplug_dev, } } -static void virt_mem_unplug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_mem_unplug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1350,8 +1350,8 @@ static void virt_mem_unplug(HotplugHandler *hotplug_dev, qdev_unrealize(dev); } -static void virt_device_unplug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_device_unplug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { if (memhp_type_supported(dev)) { virt_mem_unplug(hotplug_dev, dev, errp); @@ -1360,8 +1360,8 @@ static void virt_device_unplug(HotplugHandler *hotplug_dev, } } -static void virt_mem_plug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_mem_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); @@ -1370,8 +1370,8 @@ static void virt_mem_plug(HotplugHandler *hotplug_dev, dev, &error_abort); } -static void virt_device_plug_cb(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void virt_device_plug_cb(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { LoongArchVirtMachineState *lvms = LOONGARCH_VIRT_MACHINE(hotplug_dev); MachineClass *mc = MACHINE_GET_CLASS(lvms); @@ -1389,8 +1389,8 @@ static void virt_device_plug_cb(HotplugHandler *hotplug_dev, } } -static HotplugHandler *virt_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *virt_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { MachineClass *mc = MACHINE_GET_CLASS(machine); diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c index 23c26aa08c..986ceff514 100644 --- a/hw/net/virtio-net.c +++ b/hw/net/virtio-net.c @@ -3816,7 +3816,7 @@ void virtio_net_set_netclient_name(VirtIONet *n, const char *name, static bool failover_unplug_primary(VirtIONet *n, DeviceState *dev) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; PCIDevice *pci_dev; Error *err = NULL; @@ -3839,7 +3839,7 @@ static bool failover_replug_primary(VirtIONet *n, DeviceState *dev, Error **errp) { Error *err = NULL; - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; PCIDevice *pdev = PCI_DEVICE(dev); BusState *primary_bus; diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c index 7478f0b33a..c641226e27 100644 --- a/hw/nvme/ctrl.c +++ b/hw/nvme/ctrl.c @@ -10615,8 +10615,8 @@ static const TypeInfo nvme_info = { }, }; -static void nvme_ns_hot_plug(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +static void nvme_ns_hot_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { NvmeNamespace *ns = NVME_NS(dev); NvmeSubsystem *subsys = ns->subsys; @@ -10647,8 +10647,8 @@ static void nvme_ns_hot_plug(HotplugHandler *hotplug_dev, DeviceState *dev, } } -static void nvme_ns_hot_unplug(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +static void nvme_ns_hot_unplug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { NvmeNamespace *ns = NVME_NS(dev); NvmeSubsystem *subsys = ns->subsys; diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c index 0c1383562d..bc53bcb69d 100644 --- a/hw/pci-bridge/pci_bridge_dev.c +++ b/hw/pci-bridge/pci_bridge_dev.c @@ -205,7 +205,7 @@ static const VMStateDescription pci_bridge_dev_vmstate = { } }; -void pci_bridge_dev_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pci_bridge_dev_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); @@ -218,7 +218,7 @@ void pci_bridge_dev_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, shpc_device_plug_cb(hotplug_dev, dev, errp); } -void pci_bridge_dev_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pci_bridge_dev_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); @@ -227,7 +227,7 @@ void pci_bridge_dev_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, shpc_device_unplug_cb(hotplug_dev, dev, errp); } -void pci_bridge_dev_unplug_request_cb(HotplugHandler *hotplug_dev, +void pci_bridge_dev_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c index 4622c75e48..42bcb9206d 100644 --- a/hw/pci/pcie.c +++ b/hw/pci/pcie.c @@ -508,7 +508,7 @@ static void pcie_cap_slot_plug_common(PCIDevice *hotplug_dev, DeviceState *dev, } } -void pcie_cap_slot_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_pre_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *hotplug_pdev = PCI_DEVICE(hotplug_dev); @@ -525,7 +525,7 @@ void pcie_cap_slot_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, pcie_cap_slot_plug_common(PCI_DEVICE(hotplug_dev), dev, errp); } -void pcie_cap_slot_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *hotplug_pdev = PCI_DEVICE(hotplug_dev); @@ -571,7 +571,7 @@ void pcie_cap_slot_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, } } -void pcie_cap_slot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void pcie_cap_slot_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { qdev_unrealize(dev); @@ -579,7 +579,7 @@ void pcie_cap_slot_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, static void pcie_unplug_device(PCIBus *bus, PCIDevice *dev, void *opaque) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(DEVICE(dev)); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(DEVICE(dev)); if (dev->partially_hotplugged) { dev->qdev.pending_deleted_event = false; @@ -608,7 +608,7 @@ static void pcie_cap_slot_do_unplug(PCIDevice *dev) PCI_EXP_SLTSTA_PDC); } -void pcie_cap_slot_unplug_request_cb(HotplugHandler *hotplug_dev, +void pcie_cap_slot_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { Error *local_err = NULL; diff --git a/hw/pci/pcie_port.c b/hw/pci/pcie_port.c index dbb6032160..57fcc9079a 100644 --- a/hw/pci/pcie_port.c +++ b/hw/pci/pcie_port.c @@ -188,7 +188,7 @@ int pcie_count_ds_ports(PCIBus *bus) return dsp_count; } -static bool pcie_slot_is_hotpluggable_bus(HotplugHandler *plug_handler, +static bool pcie_slot_is_hotpluggable_bus(const HotplugHandler *plug_handler, BusState *bus) { PCIESlot *s = PCIE_SLOT(bus->parent); diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c index 1198e1ab8c..3f24ca84f5 100644 --- a/hw/pci/shpc.c +++ b/hw/pci/shpc.c @@ -278,7 +278,7 @@ static void shpc_free_devices_in_slot(SHPCDevice *shpc, int slot) ++devfn) { PCIDevice *affected_dev = shpc->sec_bus->devices[devfn]; if (affected_dev) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; hotplug_ctrl = qdev_get_hotplug_handler(DEVICE(affected_dev)); hotplug_handler_unplug(hotplug_ctrl, DEVICE(affected_dev), @@ -561,8 +561,8 @@ static bool shpc_device_get_slot(PCIDevice *affected_dev, int *slot, return true; } -void shpc_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +void shpc_device_plug_cb(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); SHPCDevice *shpc = pci_hotplug_dev->shpc; @@ -601,13 +601,13 @@ void shpc_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, shpc_interrupt_update(pci_hotplug_dev); } -void shpc_device_unplug_cb(HotplugHandler *hotplug_dev, DeviceState *dev, +void shpc_device_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { qdev_unrealize(dev); } -void shpc_device_unplug_request_cb(HotplugHandler *hotplug_dev, +void shpc_device_unplug_request_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PCIDevice *pci_hotplug_dev = PCI_DEVICE(hotplug_dev); diff --git a/hw/ppc/e500plat.c b/hw/ppc/e500plat.c index 85cec810d9..4bc1426dc8 100644 --- a/hw/ppc/e500plat.c +++ b/hw/ppc/e500plat.c @@ -42,7 +42,7 @@ static void e500plat_init(MachineState *machine) ppce500_init(machine); } -static void e500plat_machine_device_plug_cb(HotplugHandler *hotplug_dev, +static void e500plat_machine_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PPCE500MachineState *pms = PPCE500_MACHINE(hotplug_dev); @@ -53,7 +53,7 @@ static void e500plat_machine_device_plug_cb(HotplugHandler *hotplug_dev, } } -static +static const HotplugHandler *e500plat_machine_get_hotpug_handler(MachineState *machine, DeviceState *dev) { diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 20e024907b..6d99464486 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -3616,7 +3616,7 @@ static void spapr_add_lmbs(DeviceState *dev, uint64_t addr_start, uint64_t size, } } -static void spapr_memory_plug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_memory_plug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *ms = SPAPR_MACHINE(hotplug_dev); PCDIMMDevice *dimm = PC_DIMM(dev); @@ -3642,7 +3642,7 @@ static void spapr_memory_plug(HotplugHandler *hotplug_dev, DeviceState *dev) } } -static void spapr_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void spapr_memory_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev); @@ -3807,7 +3807,7 @@ void spapr_memory_unplug_rollback(SpaprMachineState *spapr, DeviceState *dev) /* Callback to be called during DRC release. */ void spapr_lmb_release(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_ctrl); SpaprDimmState *ds = spapr_pending_dimm_unplugs_find(spapr, PC_DIMM(dev)); @@ -3832,7 +3832,7 @@ void spapr_lmb_release(DeviceState *dev) object_unparent(OBJECT(dev)); } -static void spapr_memory_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_memory_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev); SpaprDimmState *ds = spapr_pending_dimm_unplugs_find(spapr, PC_DIMM(dev)); @@ -3845,7 +3845,7 @@ static void spapr_memory_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) spapr_pending_dimm_unplugs_remove(spapr, ds); } -static void spapr_memory_unplug_request(HotplugHandler *hotplug_dev, +static void spapr_memory_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(hotplug_dev); @@ -3899,14 +3899,14 @@ static void spapr_memory_unplug_request(HotplugHandler *hotplug_dev, /* Callback to be called during DRC release. */ void spapr_core_release(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); /* Call the unplug handler chain. This can never fail. */ hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort); object_unparent(OBJECT(dev)); } -static void spapr_core_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_core_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev) { MachineState *ms = MACHINE(hotplug_dev); CPUCore *cc = CPU_CORE(dev); @@ -3918,7 +3918,7 @@ static void spapr_core_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) } static -void spapr_core_unplug_request(HotplugHandler *hotplug_dev, DeviceState *dev, +void spapr_core_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -3988,7 +3988,7 @@ int spapr_core_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr, return 0; } -static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_core_plug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); MachineClass *mc = MACHINE_GET_CLASS(spapr); @@ -4043,7 +4043,7 @@ static void spapr_core_plug(HotplugHandler *hotplug_dev, DeviceState *dev) } -static void spapr_core_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void spapr_core_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { MachineState *machine = MACHINE(OBJECT(hotplug_dev)); @@ -4169,7 +4169,7 @@ static bool spapr_phb_placement(SpaprMachineState *spapr, uint32_t index, return true; } -static bool spapr_phb_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static bool spapr_phb_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -4198,7 +4198,7 @@ static bool spapr_phb_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, windows_supported, sphb->dma_liobn, errp); } -static void spapr_phb_plug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_phb_plug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(dev); SpaprDrc *drc; @@ -4220,18 +4220,18 @@ static void spapr_phb_plug(HotplugHandler *hotplug_dev, DeviceState *dev) void spapr_phb_release(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort); object_unparent(OBJECT(dev)); } -static void spapr_phb_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_phb_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev) { qdev_unrealize(dev); } -static void spapr_phb_unplug_request(HotplugHandler *hotplug_dev, +static void spapr_phb_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(dev); @@ -4251,7 +4251,7 @@ static void spapr_phb_unplug_request(HotplugHandler *hotplug_dev, } static -bool spapr_tpm_proxy_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +bool spapr_tpm_proxy_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -4264,7 +4264,7 @@ bool spapr_tpm_proxy_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, return true; } -static void spapr_tpm_proxy_plug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_tpm_proxy_plug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); SpaprTpmProxy *tpm_proxy = SPAPR_TPM_PROXY(dev); @@ -4275,7 +4275,7 @@ static void spapr_tpm_proxy_plug(HotplugHandler *hotplug_dev, DeviceState *dev) spapr->tpm_proxy = tpm_proxy; } -static void spapr_tpm_proxy_unplug(HotplugHandler *hotplug_dev, DeviceState *dev) +static void spapr_tpm_proxy_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev) { SpaprMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -4284,7 +4284,7 @@ static void spapr_tpm_proxy_unplug(HotplugHandler *hotplug_dev, DeviceState *dev spapr->tpm_proxy = NULL; } -static void spapr_machine_device_plug(HotplugHandler *hotplug_dev, +static void spapr_machine_device_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -4298,7 +4298,7 @@ static void spapr_machine_device_plug(HotplugHandler *hotplug_dev, } } -static void spapr_machine_device_unplug(HotplugHandler *hotplug_dev, +static void spapr_machine_device_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -4324,7 +4324,7 @@ bool spapr_memory_hot_unplug_supported(SpaprMachineState *spapr) spapr_ovec_empty(spapr->ov5_cas); } -static void spapr_machine_device_unplug_request(HotplugHandler *hotplug_dev, +static void spapr_machine_device_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SpaprMachineState *sms = SPAPR_MACHINE(OBJECT(hotplug_dev)); @@ -4349,7 +4349,7 @@ static void spapr_machine_device_unplug_request(HotplugHandler *hotplug_dev, } } -static void spapr_machine_device_pre_plug(HotplugHandler *hotplug_dev, +static void spapr_machine_device_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) { @@ -4363,8 +4363,8 @@ static void spapr_machine_device_pre_plug(HotplugHandler *hotplug_dev, } } -static HotplugHandler *spapr_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *spapr_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) || object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE) || diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c index 6647428391..542ed79497 100644 --- a/hw/ppc/spapr_nvdimm.c +++ b/hw/ppc/spapr_nvdimm.c @@ -64,7 +64,7 @@ struct SPAPRNVDIMMClass { void (*unrealize)(NVDIMMDevice *dimm, Error **errp); }; -bool spapr_nvdimm_validate(HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm, +bool spapr_nvdimm_validate(const HotplugHandler *hotplug_dev, NVDIMMDevice *nvdimm, uint64_t size, Error **errp) { const MachineClass *mc = MACHINE_GET_CLASS(hotplug_dev); diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index c1d4b7806e..f7fc544d35 100644 --- a/hw/ppc/spapr_pci.c +++ b/hw/ppc/spapr_pci.c @@ -1445,7 +1445,7 @@ static int spapr_dt_pci_device(SpaprPhbState *sphb, PCIDevice *dev, /* Callback to be called during DRC release. */ void spapr_phb_remove_pci_device_cb(DeviceState *dev) { - HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); + const HotplugHandler *hotplug_ctrl = qdev_get_hotplug_handler(dev); hotplug_handler_unplug(hotplug_ctrl, dev, &error_abort); object_unparent(OBJECT(dev)); @@ -1454,7 +1454,7 @@ void spapr_phb_remove_pci_device_cb(DeviceState *dev) int spapr_pci_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr, void *fdt, int *fdt_start_offset, Error **errp) { - HotplugHandler *plug_handler = qdev_get_hotplug_handler(drc->dev); + const HotplugHandler *plug_handler = qdev_get_hotplug_handler(drc->dev); SpaprPhbState *sphb = SPAPR_PCI_HOST_BRIDGE(plug_handler); PCIDevice *pdev = PCI_DEVICE(drc->dev); @@ -1521,7 +1521,7 @@ static bool bridge_has_valid_chassis_nr(Object *bridge, Error **errp) return true; } -static void spapr_pci_pre_plug(HotplugHandler *plug_handler, +static void spapr_pci_pre_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { SpaprPhbState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler)); @@ -1556,7 +1556,7 @@ static void spapr_pci_pre_plug(HotplugHandler *plug_handler, } } -static void spapr_pci_plug(HotplugHandler *plug_handler, +static void spapr_pci_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { SpaprPhbState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler)); @@ -1614,7 +1614,7 @@ static void spapr_pci_bridge_unplug(SpaprPhbState *phb, remove_drcs(phb, bus); } -static void spapr_pci_unplug(HotplugHandler *plug_handler, +static void spapr_pci_unplug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { SpaprPhbState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler)); @@ -1639,7 +1639,7 @@ static void spapr_pci_unplug(HotplugHandler *plug_handler, qdev_unrealize(plugged_dev); } -static void spapr_pci_unplug_request(HotplugHandler *plug_handler, +static void spapr_pci_unplug_request(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { SpaprPhbState *phb = SPAPR_PCI_HOST_BRIDGE(DEVICE(plug_handler)); diff --git a/hw/remote/machine.c b/hw/remote/machine.c index ced782f6a9..f79f5a0565 100644 --- a/hw/remote/machine.c +++ b/hw/remote/machine.c @@ -111,7 +111,7 @@ static void remote_machine_instance_init(Object *obj) s->auto_shutdown = true; } -static void remote_machine_dev_unplug_cb(HotplugHandler *hotplug_dev, +static void remote_machine_dev_unplug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { qdev_unrealize(dev); diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index f3a1cc5ba3..d4b501802f 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -1088,8 +1088,8 @@ static void virt_set_acpi(Object *obj, Visitor *v, const char *name, visit_type_OnOffAuto(v, name, &s->acpi, errp); } -static HotplugHandler *virt_machine_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler * +virt_machine_get_hotplug_handler(MachineState *machine, DeviceState *dev) { MachineClass *mc = MACHINE_GET_CLASS(machine); RISCVVirtState *s = RISCV_VIRT_MACHINE(machine); @@ -1104,7 +1104,7 @@ static HotplugHandler *virt_machine_get_hotplug_handler(MachineState *machine, return NULL; } -static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev, +static void virt_machine_device_plug_cb(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { RISCVVirtState *s = RISCV_VIRT_MACHINE(hotplug_dev); diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c index 440fefb7d0..e7cd9ac7b6 100644 --- a/hw/s390x/css-bridge.c +++ b/hw/s390x/css-bridge.c @@ -26,7 +26,7 @@ * (including sending a channel report to the guest) and remove the * device from the virtual css bus. */ -static void ccw_device_unplug(HotplugHandler *hotplug_dev, +static void ccw_device_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { CcwDevice *ccw_dev = CCW_DEVICE(dev); diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c index eff980fdfe..2eb4e8cec4 100644 --- a/hw/s390x/s390-pci-bus.c +++ b/hw/s390x/s390-pci-bus.c @@ -158,7 +158,7 @@ static void s390_pci_shutdown_notifier(Notifier *n, void *opaque) static void s390_pci_perform_unplug(S390PCIBusDevice *pbdev) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; if (pbdev->pft == ZPCI_PFT_ISM) { notifier_remove(&pbdev->shutdown_notifier); @@ -1005,8 +1005,8 @@ static bool s390_pci_alloc_idx(S390pciState *s, S390PCIBusDevice *pbdev) return true; } -static void s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev, - Error **errp) +static void s390_pcihost_pre_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); @@ -1079,7 +1079,7 @@ static int s390_pci_interp_plug(S390pciState *s, S390PCIBusDevice *pbdev) return 0; } -static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void s390_pcihost_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); @@ -1216,7 +1216,7 @@ static void s390_pcihost_plug(HotplugHandler *hotplug_dev, DeviceState *dev, } } -static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void s390_pcihost_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { S390pciState *s = S390_PCI_HOST_BRIDGE(hotplug_dev); @@ -1255,7 +1255,7 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev, } } -static void s390_pcihost_unplug_request(HotplugHandler *hotplug_dev, +static void s390_pcihost_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 17266779a6..7fb78d8fa1 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -343,8 +343,8 @@ static void ccw_init(MachineState *machine) } -static void s390_cpu_plug(HotplugHandler *hotplug_dev, - DeviceState *dev, Error **errp) +static void s390_cpu_plug(const HotplugHandler *hotplug_dev, + DeviceState *dev, Error **errp) { ERRP_GUARD(); MachineState *ms = MACHINE(hotplug_dev); @@ -608,7 +608,7 @@ out_lock: bql_lock(); } -static void s390_machine_device_pre_plug(HotplugHandler *hotplug_dev, +static void s390_machine_device_pre_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) { @@ -618,7 +618,7 @@ static void s390_machine_device_pre_plug(HotplugHandler *hotplug_dev, } } -static void s390_machine_device_plug(HotplugHandler *hotplug_dev, +static void s390_machine_device_plug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { S390CcwMachineState *s390ms = S390_CCW_MACHINE(hotplug_dev); @@ -648,7 +648,7 @@ static void s390_machine_device_plug(HotplugHandler *hotplug_dev, } } -static void s390_machine_device_unplug_request(HotplugHandler *hotplug_dev, +static void s390_machine_device_unplug_request(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) { @@ -662,7 +662,7 @@ static void s390_machine_device_unplug_request(HotplugHandler *hotplug_dev, } } -static void s390_machine_device_unplug(HotplugHandler *hotplug_dev, +static void s390_machine_device_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) { @@ -715,8 +715,8 @@ static const CPUArchIdList *s390_possible_cpu_arch_ids(MachineState *ms) return ms->possible_cpus; } -static HotplugHandler *s390_get_hotplug_handler(MachineState *machine, - DeviceState *dev) +static const HotplugHandler *s390_get_hotplug_handler(MachineState *machine, + DeviceState *dev) { if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) || object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW) || diff --git a/hw/s390x/virtio-ccw-md.c b/hw/s390x/virtio-ccw-md.c index 0b18b49bc4..70dbea819a 100644 --- a/hw/s390x/virtio-ccw-md.c +++ b/hw/s390x/virtio-ccw-md.c @@ -19,7 +19,7 @@ void virtio_ccw_md_pre_plug(VirtIOMDCcw *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; @@ -48,7 +48,7 @@ void virtio_ccw_md_pre_plug(VirtIOMDCcw *vmd, MachineState *ms, Error **errp) void virtio_ccw_md_plug(VirtIOMDCcw *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; @@ -72,7 +72,7 @@ void virtio_ccw_md_unplug_request(VirtIOMDCcw *vmd, MachineState *ms, { VirtIOMDCcwClass *vmdc = VIRTIO_MD_CCW_GET_CLASS(vmd); DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); const HotplugHandlerClass *hdc; Error *local_err = NULL; @@ -112,7 +112,7 @@ void virtio_ccw_md_unplug_request(VirtIOMDCcw *vmd, MachineState *ms, void virtio_ccw_md_unplug(VirtIOMDCcw *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c index d82874ed27..30fb2c0681 100644 --- a/hw/s390x/virtio-ccw.c +++ b/hw/s390x/virtio-ccw.c @@ -1235,7 +1235,7 @@ static void virtio_ccw_busdev_unrealize(DeviceState *dev) virtio_ccw_device_unrealize(_dev); } -static void virtio_ccw_busdev_unplug(HotplugHandler *hotplug_dev, +static void virtio_ccw_busdev_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtioCcwDevice *_dev = to_virtio_ccw_dev_fast(dev); diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c index 132f833226..d7e2662aa7 100644 --- a/hw/scsi/virtio-scsi.c +++ b/hw/scsi/virtio-scsi.c @@ -1144,14 +1144,14 @@ static void virtio_scsi_change(SCSIBus *bus, SCSIDevice *dev, SCSISense sense) } } -static void virtio_scsi_pre_hotplug(HotplugHandler *hotplug_dev, +static void virtio_scsi_pre_hotplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { SCSIDevice *sd = SCSI_DEVICE(dev); sd->hba_supports_iothread = true; } -static void virtio_scsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void virtio_scsi_hotplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtIODevice *vdev = VIRTIO_DEVICE(hotplug_dev); @@ -1183,7 +1183,7 @@ static void virtio_scsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, } } -static void virtio_scsi_hotunplug(HotplugHandler *hotplug_dev, DeviceState *dev, +static void virtio_scsi_hotunplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { VirtIODevice *vdev = VIRTIO_DEVICE(hotplug_dev); diff --git a/hw/scsi/vmw_pvscsi.c b/hw/scsi/vmw_pvscsi.c index 05f93171cd..77c9b843b4 100644 --- a/hw/scsi/vmw_pvscsi.c +++ b/hw/scsi/vmw_pvscsi.c @@ -612,7 +612,7 @@ pvscsi_send_msg(PVSCSIState *s, SCSIDevice *dev, uint32_t msg_type) } static void -pvscsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) +pvscsi_hotplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PVSCSIState *s = PVSCSI(hotplug_dev); @@ -620,7 +620,7 @@ pvscsi_hotplug(HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) } static void -pvscsi_hot_unplug(HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) +pvscsi_hot_unplug(const HotplugHandler *hotplug_dev, DeviceState *dev, Error **errp) { PVSCSIState *s = PVSCSI(hotplug_dev); diff --git a/hw/virtio/virtio-md-pci.c b/hw/virtio/virtio-md-pci.c index aa5b11c0f6..97ea0ec7b3 100644 --- a/hw/virtio/virtio-md-pci.c +++ b/hw/virtio/virtio-md-pci.c @@ -19,7 +19,7 @@ void virtio_md_pci_pre_plug(VirtIOMDPCI *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; @@ -47,7 +47,7 @@ void virtio_md_pci_pre_plug(VirtIOMDPCI *vmd, MachineState *ms, Error **errp) void virtio_md_pci_plug(VirtIOMDPCI *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; @@ -71,7 +71,7 @@ void virtio_md_pci_unplug_request(VirtIOMDPCI *vmd, MachineState *ms, { VirtIOMDPCIClass *vmdc = VIRTIO_MD_PCI_GET_CLASS(vmd); DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); const HotplugHandlerClass *hdc; Error *local_err = NULL; @@ -110,7 +110,7 @@ void virtio_md_pci_unplug_request(VirtIOMDPCI *vmd, MachineState *ms, void virtio_md_pci_unplug(VirtIOMDPCI *vmd, MachineState *ms, Error **errp) { DeviceState *dev = DEVICE(vmd); - HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); + const HotplugHandler *bus_handler = qdev_get_bus_hotplug_handler(dev); MemoryDeviceState *md = MEMORY_DEVICE(vmd); Error *local_err = NULL; diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c index 1762816bf4..8def3bb68b 100644 --- a/hw/xen/xen-bus.c +++ b/hw/xen/xen-bus.c @@ -374,7 +374,7 @@ fail: g_free(key); } -static void xen_bus_unplug_request(HotplugHandler *hotplug, +static void xen_bus_unplug_request(const HotplugHandler *hotplug, DeviceState *dev, Error **errp) { diff --git a/stubs/hotplug-stubs.c b/stubs/hotplug-stubs.c index 0f592ee139..32b4af7997 100644 --- a/stubs/hotplug-stubs.c +++ b/stubs/hotplug-stubs.c @@ -14,19 +14,19 @@ #include "qemu/osdep.h" #include "hw/core/qdev.h" -HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) +const HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) { return NULL; } -void hotplug_handler_pre_plug(HotplugHandler *plug_handler, +void hotplug_handler_pre_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { g_assert_not_reached(); } -void hotplug_handler_plug(HotplugHandler *plug_handler, +void hotplug_handler_plug(const HotplugHandler *plug_handler, DeviceState *plugged_dev, Error **errp) { diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c index 0c5502d45b..a62ad23ecf 100644 --- a/system/qdev-monitor.c +++ b/system/qdev-monitor.c @@ -917,7 +917,7 @@ static DeviceState *find_device_state(const char *id, bool use_generic_error, void qdev_unplug(DeviceState *dev, Error **errp) { - HotplugHandler *hotplug_ctrl; + const HotplugHandler *hotplug_ctrl; const HotplugHandlerClass *hdc; Error *local_err = NULL; -- MST From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:13:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:13:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416065.1645223 (Exim 4.92) (envelope-from ) id 1x4xJj-0007gX-Em; Fri, 11 Sep 2026 09:13:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416065.1645223; Fri, 11 Sep 2026 09:13:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xJj-0007gQ-BG; Fri, 11 Sep 2026 09:13:07 +0000 Received: by outflank-mailman (input) for mailman id 1416065; Fri, 11 Sep 2026 09:13:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xJi-0007gK-NA for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:13:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xJh-008eDQ-DU for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:13:05 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3c608-8faa-0a2a0a5109dd-0a2a4505b4fe-46 for ; Fri, 11 Sep 2026 11:13:05 +0200 Received: from [52.101.53.0] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3c61d-4cb1-0a2a45050019-34653500a15e-4 for ; Fri, 11 Sep 2026 11:13:03 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SA0PR03MB5548.namprd03.prod.outlook.com (2603:10b6:806:c3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Fri, 11 Sep 2026 09:13:00 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:13:00 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rGRzwXE2flHPXEuLJzjY5nl6ceNBmozYNK4PeqCuOhNRSW06zBX9psjHuDeBepG3MG+3PY0xs203AF8aR3oaAHgeR2CJyPk1A6Sl2XuL2JYR5FP3Qgh8s9cROinnQUaq5492eh/RzNzJnvTel2roG/I/IAA+MqqX7VBZ343dm7lcsTwKUsHMkHi5zmyqnxNNbFQ7m1DX4JygxFydpm6LsaT35rPHgrBueyNOtYkYdqlNCXkQyv1V4Q8g0ApSHTTHI21831yJuZm+TI6ojCSdWQSSbjzi5W3UUT8zBAk2mQYElwITMcnPzQjywJm6DfTU3omyeQC322vQ221gaABgIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FpyX2fKlOrWfioY9qFuyjQOAwz4CmZDu9eRzqRkPKRE=; b=Jay/5jAEdqJ1ymPdTgWZqnlzbUrSX2uQcS18jDSjfoMMEVP24YoAe38zaOJZ0o85T0YIHwqVTom5nVMFujwY3//iy/ISNDKJq1IsULWC0+hcHJHsvu4iBZDxvdQLNQEY7H3Pduq4ueRonQjDwWiAiSNWYdIlgsfRKY759XYpuxsr5qtsXGjhPZ2Zwum3eycglCmvhpAJEn4tx70D3v8/kV/bojZNLTidFtSv/se/Orw0YVMWG5hPvlE70JJ9JHJNuTwP58IuRQL5Zk4TjXSg9bl+zxh/wHXJw1qIpk39HvIq9duUOBBwMUtbAragSCaHJouS4/Fikt5+32KXuX0/2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FpyX2fKlOrWfioY9qFuyjQOAwz4CmZDu9eRzqRkPKRE=; b=yGPjuF9jWjzgU5lhx/pR9GshM7BEVQijYaqEnhDGWOXBT+CHWduA6dj4hEdlUUOifpXNhnSPoDhVo0hxozEdm2oC5MeMJElCt0wR+OxqrhVvGTT5hmp0QN2p85+wQONWL8xhMh4hk0Y/kdQeDXvGdWBVI2q3mUJZUeTgbA1Mgjw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Paul Durrant , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Juergen Gross Subject: [PATCH v3 0/3] Viridian changes for Hyper-V as a guest Date: Fri, 11 Sep 2026 10:12:41 +0100 Message-ID: <20260911091244.1165516-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0312.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:391::20) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SA0PR03MB5548:EE_ X-MS-Office365-Filtering-Correlation-Id: 9d8a6c47-7a8d-46d3-14b3-08df0fe4e04d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|366016|6133799003|10067099003|11063799006|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: soXabx5Df9A0+54+LKxdGLlIX459tiMbYHY8128Isu6bq28zoM2+Z+wPJRpFowydZLufYQPEt3Vrhc76kCVRhyjL8Tb/zIiU+rG0aqX0Hw6GR0vD9lCjEaZrA8vINlBP+rr8jphVfQUGjNFriR+CTsJ8swlQ2PE1CI6+KMUF2x5MNQHHaQHJas2h3FObeBvzLx9+oTIFLVtQfDWrC4LhPoPzIgDmSsscpA2/9t4wOrz7li1Lzps4ll6DhzPG7Rmad9lCnskDr4tkycHQvvbJTf7yawetc6ZP7uTcWCyoNccfd89Lvz+NabxvENADef44oxkq9Cw87opcYVwFjbPaXG3lQkhQ2ng6k5VgxsG0oZATTNiX5TH9RjkszUAP42/h6YidXNw8i522b77wG7nXhMRRReiliLHrnNGo32q2yx+uRQTvjJ8GX0AxeE3NgMLw1xER9W7v/MJRwiqmXhpHkyL1c4n+4SyL5hXNs98u49Zz47KN1M5cY7S0sqCVWdiZssYp6QaaEWWxDswWI7QXs21IQDPWhlrJmPrpTPKtkh02n6QjUMkEZTzgZoskdlmNZImR8U8twutmnQudTfYkhU69+tE//+GvK74jj+DeEIJlWiyuzUONx8V5zRKz3Qd6/skRapWSZ1LdL7uvV6OLMBiF7rptMZfcFM/03m8YAT4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(23010399003)(366016)(6133799003)(10067099003)(11063799006)(56012099006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?kdIed1txg1aNDMm0gq4umS4hf0cnmsbbPJ3QHs1hfIX9vhZJn4WV3iRk+8b/?= =?us-ascii?Q?uf/h0V6fXrrt6tFoAF2d5quqZNr0KesWwHRDP12s7OYuWlQPRljmWGlBLvaV?= =?us-ascii?Q?E4fwGW3t8Y9L/qi/llFSXSBtuNNxCxM5K4zzhtd0BgReKdKs1QXsOgDINuwK?= =?us-ascii?Q?DOqA5GtAS3Lt5wfVR+BrHtvlRUtfdQTr60pDLZ58JtVtdRy+A0PbOdyiDat8?= =?us-ascii?Q?NVYNvRF2d44FZnUw5+PY4otLJvbRTGZJXqLObKPf6zYN7nj7MMaQhSgc56TS?= =?us-ascii?Q?bHgkL3ozczCslZ3sqwqrXSlUi4V3r58ziUYWrcv1RnBnu+QnN1qIG8UPVq7e?= =?us-ascii?Q?mLJPsABtcgM2gU/bStTeqwCw6jTfYTZwxO0FFGyxRwEUC8PceL8nREUO1vDR?= =?us-ascii?Q?ogdmBf70vdxFTbowk+4DONeFTo51sGp7a2Om5mfqXV/FuEcKVju0RbQ0rwlX?= =?us-ascii?Q?ZGYVI68DtqZJPb6bfRJOLvSl5QtWx/V3VM2L/9l5IDoIAk61WVjMGwgXEket?= =?us-ascii?Q?+vgQJuAmXvxLRF86+F/XiOMPoRCyY3ZCC1Z1KRNY/pYftA+WiQ3iL/iKNWUU?= =?us-ascii?Q?eBLpjqU959NDvZXL8GJpAigkBqcORkgBtdLcfxsDRWMbSio1umuHe5NRxaA3?= =?us-ascii?Q?dlrwrBd5OCt7x2MA7V/YS1TwiWctz0a8DSWz6dyDkkF5tnWVY6nj456LqaWy?= =?us-ascii?Q?sRiAF0aYhE8lsgLLjFfK3ioT3W/1olYk+krwO/8hltCxlrFn4AYYfv0VYudb?= =?us-ascii?Q?Z8W81mjd5OPKZqhrQS6qgcWlB8+cZpO3Pxaxk5bbbEB2xsFnQlli8Z8MLh9P?= =?us-ascii?Q?3rM1ezAkAACE3hToRo01EvxBv9cXGSK3H9m0VGYYu3sNK36/Nm+hnDV7sfFC?= =?us-ascii?Q?8K8EE/KytHbvtaKR0Jz6kilbMjb+Ybo/TYXWDigqrcoRaTv0lnH2AiWbtDPf?= =?us-ascii?Q?47DU3i5hUOigmXwhInNcGKi1f8EB4ryxKKMEJOe1dHiNjzCPAWPI530ARu5q?= =?us-ascii?Q?gIBRlSy3g/ZnJebHcfcC9alc81I7hDCQLIEy613MvVtSYraMAf4WMequF9/+?= =?us-ascii?Q?beMcS6F1pw3qVJr2xUqHHmNvqeZXLPYk4zrlbmPZweT0g/HQZZ2o6AAr7gtx?= =?us-ascii?Q?iOyhV2ICDxE0pe0rxix/IAVogx/Z9zrAyIjOyFO8fpIiXgLLvSTwG2U5JfwJ?= =?us-ascii?Q?/AQGZy7iEumeM6/Hw8KC3IdpH7i7O+2KPRzi3zcLtiUYWnertIPjT2htWjQV?= =?us-ascii?Q?uU+RKhp8DbdqkIhkFlOPoLBuoepYPz1gO93aWJ7dW+tBb3W5+eVgP2YagaXs?= =?us-ascii?Q?9TpQL6CesmZGmyGq8EFtCNY1l5JkzFLZbxo7Yt0QzhsNu5UWOQG8l4kBBhs4?= =?us-ascii?Q?F3qL2BxXHEOZ18LaBCB42Hv4dc4CfpZ4VqeNEx0JlhZ/mpKSG6Dc8b3jHm94?= =?us-ascii?Q?NbSJJABwaIravLHe7BXITOtJSi3pEXPs0h9KCGZujhiB1ldmL/5paC09iXP3?= =?us-ascii?Q?bb2z67SJRiJIKcONkIjjSFHXUxfIdq2fZG+5WEMWTM/WWvxE086BQ7zy1iSS?= =?us-ascii?Q?7H4UxMKyT750RI6vdM1twxnoXEcipCS4P7bAFT2nB7uFmp2Q1aDs+jaETjyS?= =?us-ascii?Q?/omyMRKiDasAic4iGCzM8XBelqSRw9I/nJTHomPUvIRLYx1JTpODSdI8ISeI?= =?us-ascii?Q?A0++wc+SQUUQGVCz9BY5p3mTjfKurB6X2b8XOjxvH0FUt5FlBguv88FRCfa6?= =?us-ascii?Q?/8q1HDLFQGNljHCwgwlcn765fRxECXA=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d8a6c47-7a8d-46d3-14b3-08df0fe4e04d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:13:00.1136 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Tjpo0rE/jDEbkNWc8FN0WuKqQW62cwSp7T4A0KqQ6IoaCYacK4kUmwriNHRLnkMK7+IvIjnKfBPsCq75CSzlhOuScNwmbfb2t0khGRBv3eo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5548 X-purgate-ID: tlsNG-c201ff/1789117983-253192A1-BE802926/0/0 X-purgate-type: clean X-purgate-size: 945 Hi, Here are some changes to get the existing Virdian enlightenments working when running a Windows 11 guest with Hyper-V enabled Hyper-V also depends on some unimplemented MSRs to boot, but that will be addressed in a separate series. Thanks, Ross Ross Lagerwall (3): x86/viridian: Workaround Hyper-V GP fault writing to MSR x86/viridian: Implement synthetic timer direct mode tools/libxl: Add support for Viridian stimer direct mode docs/man/xl.cfg.5.pod.in | 5 ++++ tools/include/libxl.h | 6 ++++ tools/libs/light/libxl_types.idl | 1 + tools/libs/light/libxl_x86.c | 5 ++++ xen/arch/x86/hvm/viridian/synic.c | 9 ++++-- xen/arch/x86/hvm/viridian/time.c | 44 ++++++++++++++++++++++++---- xen/arch/x86/hvm/viridian/viridian.c | 3 ++ xen/include/public/hvm/params.h | 7 ++++- 8 files changed, 71 insertions(+), 9 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:13:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:13:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416067.1645232 (Exim 4.92) (envelope-from ) id 1x4xJt-0007vU-MQ; Fri, 11 Sep 2026 09:13:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416067.1645232; Fri, 11 Sep 2026 09:13:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xJt-0007vK-J7; Fri, 11 Sep 2026 09:13:17 +0000 Received: by outflank-mailman (input) for mailman id 1416067; Fri, 11 Sep 2026 09:13:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xJs-0007ur-RW for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:13:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xJs-003Czl-7x for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:13:16 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3c625-e002-0a2a0a5209dd-0a2a4504d4e8-26 for ; Fri, 11 Sep 2026 11:13:16 +0200 Received: from [40.93.195.5] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3c62a-b57f-0a2a45040019-285dc305190c-3 for ; Fri, 11 Sep 2026 11:13:16 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SA0PR03MB5548.namprd03.prod.outlook.com (2603:10b6:806:c3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Fri, 11 Sep 2026 09:13:10 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:13:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=txQCcSt2vcU3K4xCxS9Zzk+MGmCClGtsurhiICpTtSKXZRcSb0rkAXqzBQtlsI6VNwT1uBKT3igFGd54pj63la65UH34KeRufe2jeOWY6Xb4fP6jr1CMLuO2qdwdfzGsQQcCakryiBXiJlC9hi6lQNsAQhNz4q+ePheSpT7Qag3j6MFuTsO59qGUJnwAK1DosKtkmr6VkGrLxr+BB/dxtHVSG/dqRzITLLPisMp8E+n5YmOCOC8DBU3pOiI9cAXFij3qvxATqClZiTdYpygYALO4W2YKJYS3Cfp2nWFjNkGDk37o6LE4v5cWPo40USsx5IOHyZhwagqC8JkMCWRVqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9Rjk4k8h1rfgiImUL7T5cXwA3eXNjbzwo7Aqi8JVKb0=; b=AL7UoW23+wOmBuBmMSnP3tIowxdRjpBCTAD034uX0Cd9qBr6WurogVEj+PkmmwK92AVsjcmEH7WnvogsO9na1DALL5AZs3uHi9uATDrj83yvtJpRc+DvNwO+nY2dpWWTLG2eNWnwzZrnIejRzP4/sueqZv/1UYOF7eYsa0E/Wcxe9K5BB2uUpv2xnbDZ0WWN8F55UXlcrVhts2KjAU2njZvMJMMgG4R0VvDvuEwyJkwJ47pURJ8TrCN92uBfrgJ8pUCwl4NaDbU+LJHWEb6CqsaBFf8kluGQfsWrTBW3l2/CeeQO806zJcuPc+iLlzlCPtB4W9l1JGtTSpDEALwKgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Rjk4k8h1rfgiImUL7T5cXwA3eXNjbzwo7Aqi8JVKb0=; b=RBa+Q/+IM6nW/l6ZN4NT65ojAFtgcGT/U2ozy2j+0kbqYSEVYPz1x9Wh9fvQYBJ3umYsNlu0kpAIKOhI+ibSBbJG0einx+Bm8W2AEioaWfWekmyzfudStfmUk9eWxPTfvuDJ8UYwsXR1wZ44lDkpk1H/gKkvtDRAK9+FdaQq+AA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Paul Durrant , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v3 1/3] x86/viridian: Workaround Hyper-V GP fault writing to MSR Date: Fri, 11 Sep 2026 10:12:42 +0100 Message-ID: <20260911091244.1165516-2-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260911091244.1165516-1-ross.lagerwall@citrix.com> References: <20260911091244.1165516-1-ross.lagerwall@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: DUZPR01CA0286.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b7::12) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SA0PR03MB5548:EE_ X-MS-Office365-Filtering-Correlation-Id: 3b45d66c-8366-4fbf-fb2f-08df0fe4e68a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|10067099003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: pAw2KakVZTGTv091XGb9SEdAbInv6CY6mD1UoNXU+FUQ/7C5ywURDwORZmoj5b0ljzrI607AcIipm3FC19F+Q7V3891BZFKZEL4IHFOAecHZFecSgDYituQFYLdEnFYOHOXsD2U1p+jb35aOs+8PMnDFPOZbnddg88wUP90CgfztyigB09mmdkmlY4azcpbFkvezDk64ux0cF4+6wPejA658LOFgdlCYKyD/8EDt9MzAxeALY3oan6BpIrU1ReyU6c/syIg1gg10WGJ/UKKwcreQRgC+OEbnIyjg/drDVgxDVkz+APTyfC/ZEt4wXujfIK/PJyXOEH8q/riVMU5WbBZ8/IU+99ig+4zijfVcIT6ZfvXuCr7mRWY2bZlBCYbjWowO9kwS0+68+npwFJucbyh0/gyv4BTxKl/cf6TWSEGqjzi+jTxGi4vqErxIBD+60kaue2RNiI8dxP209DcQznK/YM0vpN7DgMT1QoWSodyN8WzhqPWFaHq/V7jhR6kD1tL6L1D5EZj1vG7EkgdNoxAyb43mwKuQ9CegI1HBzuXeSIOILD2kdwHFgy+g36URtiy5gCs+x9IyBu2FLxjbL/NmZw9E5sCks6cGssLcPK1eztw6iwDATx+ZSRKYJu5eejcPmVV9DoDs8BlQY0ip5xdOu3T8oGg/HfvLepPfs2I= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(10067099003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?vZIyZM1RCIOtP7DV33e78OuNH9NV07RbLTrwyxj1gdFz2vugrejTz7yQfHwl?= =?us-ascii?Q?5KqPruR1VNG3s15b1OPT68m6sEkZ5aO3Lwh0VmF5qx5shb/bQue+i/2wWyMQ?= =?us-ascii?Q?jrSvSlDfrCPonnSWWxTv75BnnPpSlpyvOfErAquRTJSXQQ4LVdZwRuw8MsMR?= =?us-ascii?Q?NVPhdJJGxTDYGFNsgy9O0H5JoUuMrPK3aKDjLrsEDHn5y7cMuNgfqJxPq2Zm?= =?us-ascii?Q?igljRKSEay4zj4PClo27a+Apd/iks1e5MaIbdMt6XD/rkKo/o3ubaW5m1mar?= =?us-ascii?Q?VHk8nyXIfoMlqzLZxo7y0TSeWQ147ifMWDRwVkQfZ41j3eG64PIIQJSHIELM?= =?us-ascii?Q?3ziOOnKVL7muGjbABivTie/t5bcmqXiFzLPuoZW+0Y53fTaSWWv85J8el1X/?= =?us-ascii?Q?WDILAzfMRJ7BRHJ4u4x+oYSt9K3ejgAyk32BhFQ+5VS2lCZs6F0LqMFy8vx5?= =?us-ascii?Q?653a+VjuxUn7uRyeOkBUA3/cPzAsKaHsGjADHoz3te4rrgi1g/1jJ5ui+dvp?= =?us-ascii?Q?LaD1Su26WSBi2/v1XwuhYyZE1IirxgEcicT07ZrMihxaBgYdaHHcHgq58/7D?= =?us-ascii?Q?Icx30VN8tXEAGuNYFXBa7wLKn2uwKKFfm4D+gBu1LZ29HdoyU1cXDhWplZil?= =?us-ascii?Q?CHkRMcOrW8M1cgckdCUNH0tAGE3vIldIF5YAzBRlkMTb4m+ffHuN93Dd6Kzy?= =?us-ascii?Q?AIBZHtEeRRo+l/c6PmnYh37qEQ8Qa+WW42sMGEawwJ9Y4gcjuXA2bch7oRoh?= =?us-ascii?Q?HZVPLZ/ZG6mECGxg+QnNQHEcgmeqrBh0jbU1EX7La9ErKwO+QrZ49s5584W8?= =?us-ascii?Q?DHpKPssOqv06KEc1l4PErwZy9+mo9X3DpKeXxzQKppQ739t6+0bEX8O0MoLv?= =?us-ascii?Q?wY7bNWyjPfZ6e7J0eeXA1SF40v1+p+cflTIgEUMfndrcrRSlr/sugLlUt7Pb?= =?us-ascii?Q?D9R/gD6kF5sUQ/ASmU4CmmhQcYWxv/jctVRa68d1aER+mhYwiHbAYRWwJ/kb?= =?us-ascii?Q?v7qdcB9ljJzLvdSdMPmzZmbjHThoDcl+mQLY9iGn+oPn8zMwa6uOmkDZpqpS?= =?us-ascii?Q?yUAxYPQlv3eFShM3uJP1hevAKmlCqLkovz9sJ0bLx+sGHyl9ODy924OHlWqg?= =?us-ascii?Q?hF0qJw79DO7qbzv8XmDCXSssJGeQ64uiYRbi2PFInTRmv+bYclCyDOklEYea?= =?us-ascii?Q?+fT+dMaLxeQEQ1ft6L/OUEyKDUi7wC85RoYDekGuV3GVzj/B7iwFQ6v3YEEy?= =?us-ascii?Q?sF6o7iMI/nnChWPvAx7rtpCZuHrLG5Y/WDAzA4ktu12DaSo4GJwxHo9mzxD5?= =?us-ascii?Q?CvGDjOgMQvu4++jvoPY9hd9f/GtcKbI+z4GZuQILLnNz+Lt2ctcsp9ld9AL8?= =?us-ascii?Q?BH4MClxs8Ic4rVNYCn0NZ0Eb7y7mDnZsOi3iPy36yqdDVLkM7Kb2RPXM/H6/?= =?us-ascii?Q?zqmT/KXX6juh3xNuBdJwOviOulZ34h8dWN2IHpfnoQcdOFpn4SVgF1XnsaDh?= =?us-ascii?Q?9zc0/1kWvll5qYGObOhmWbR1FCFYC4O/i1ApCgKBgkZq8OxfjxRch1N/ZF+J?= =?us-ascii?Q?yfo2SAwpuhqceCyHWvYyQQb7tO3ZvsZRKHog8pj85tT7kpU1I7xDyPJDi890?= =?us-ascii?Q?2LCeP1c4v6QB4mS8eybhX88v7P1+i8HbrY16b4t85LFhv+8dvY8x8int4NgV?= =?us-ascii?Q?ZDqtDrTpO/XZkeK1LeDTGFqBwwbeTCUMzCuMrdDdZO9xctdTkHTipdXbuTB8?= =?us-ascii?Q?AZlF8uR0/ycI6CrV16XGkLwGln4T4vc=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b45d66c-8366-4fbf-fb2f-08df0fe4e68a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:13:10.5367 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 4d/J10pSzopCLeKP/GvBHxeHjTmSLd9wHVJo3huPO+shJX2LopUsDD6GEg5wHOVoMSe7P75bJITft0buvlxAXJ8r5WDgW7mlXmIeAMDVINg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5548 X-purgate-ID: tlsNG-ebf023/1789117996-526CAB50-D50BB38F/0/0 X-purgate-type: clean X-purgate-size: 1584 The Viridian spec requires the vector to be >= 0x10 when writing to the SINTx MSR, otherwise it should #GP fault. The spec-defined initial value is 0x10000, i.e. the vector is 0. On startup, for some reason Windows 11 Hyper-V tries to set the MSR to the spec-defined initial value and since the vector is 0, it GP faults. Fix this by doing as Hyper-V does and only fault if the SINT is unmasked. Signed-off-by: Ross Lagerwall --- In v3: Copy Hyper-V behaviour - only check the vector if not masked. xen/arch/x86/hvm/viridian/synic.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/viridian/synic.c b/xen/arch/x86/hvm/viridian/synic.c index e6cba7548f1b..3125ccca0dcd 100644 --- a/xen/arch/x86/hvm/viridian/synic.c +++ b/xen/arch/x86/hvm/viridian/synic.c @@ -157,9 +157,14 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) if ( !(viridian_feature_mask(d) & HVMPV_synic) ) return X86EMUL_EXCEPTION; - /* Vectors must be in the range 0x10-0xff inclusive */ + /* + * Vectors must be in the range 0x10-0xff inclusive unless the vector + * is masked since Windows 11 Hyper-V (26H1) has been seen to write + * this MSR to its default value, despite not being a spec compliant + * value. + */ new.as_uint64 = val; - if ( new.vector < 0x10 ) + if ( new.vector < 0x10 && !new.masked ) return X86EMUL_EXCEPTION; /* -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:13:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:13:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416068.1645241 (Exim 4.92) (envelope-from ) id 1x4xJw-00089s-TC; Fri, 11 Sep 2026 09:13:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416068.1645241; Fri, 11 Sep 2026 09:13:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xJw-00089l-QM; Fri, 11 Sep 2026 09:13:20 +0000 Received: by outflank-mailman (input) for mailman id 1416068; Fri, 11 Sep 2026 09:13:20 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xJv-00088z-Rf for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:13:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xJv-00AssA-7x for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:13:19 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3c62a-bab6-0a2a0a5309dd-0a2a450ba2d8-18 for ; Fri, 11 Sep 2026 11:13:19 +0200 Received: from [40.93.195.12] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3c62d-b7e8-0a2a450b0019-285dc30cfd72-3 for ; Fri, 11 Sep 2026 11:13:19 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SA0PR03MB5548.namprd03.prod.outlook.com (2603:10b6:806:c3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Fri, 11 Sep 2026 09:13:16 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:13:16 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=S9hJJF7rGVqZ9JjUrTGIAeQCaSpL1EZAtzj0IxN8T4o2YDk/TOxXBvbzlciStAfk1AvsYR6YiEKDc/tBBJZ1i37CcYjI4ud+0AzkftWcSc09lekAs44rO3hsUBjhEqgu9uoGji5RqB32d+/scVsS+pXzrHeyh636Xhfuux2eqq265yXTDCoBfgmXofuwyJ/Q3Q6NF0wYmrBpZy21Z1EBI9B1j+U93ccLp/6Jiv9QZ6NT3hZQdZpZjH87tJxzJLHNl6BSgjDrNGDUhiyjd1o+z39RHVfMfSlpdZac71QMQgRIViBartdF/N1jA/syg5lCqiZkNqyDEgTyOXtwS30OsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tYKIlUdhkoJoNa0kISGZ4/ZymHnUZqUNnA5Zqk/4p2s=; b=gSnlytOKqzoOaLmj/Q/ik2y2VFCw8skCSrdqKRIwbqPMXDO550NTXbOU4YCtZY1dQIvjnW21OQmCWw58T7QuKRCUVmyFGzy881H7+SLTIWnMjEUDwOZqaON4rrDAKKODrJa0U0x4aaWdsah+rdDoKpfG/DHmGXIQXxPoxqQcK/A8rzYU0J5/8gL6kcCr0WtW1MNj/mAMf6tFKbVgWu65xravKX09Uas9Yd4KtGry1OqXXsOfhUgidS5wCs00VnWmz6FTmCIQeM0tGy5r6IdBGwJNQ24+YJWdFAXiz1tXx2p77HXE+4sSh1RdrzjZ1pQmdHbNSMkhGK7l5PviDPyxCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tYKIlUdhkoJoNa0kISGZ4/ZymHnUZqUNnA5Zqk/4p2s=; b=wW2lFbQFv5JLzSns61xc29i4G3QgAGCtx02IkadLTO5nYvqZ6njat7xpkWPyhx2KwgA17WcFcTCq7f5cdutYD3D2dWcKRjNKgMo5EyuGExY5PAOx4AoNaq4q7iwdFSmc/MqkWKahXUsZ7eivb/Gi7DWPV/f6eneGUijtac0T0+Q= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Paul Durrant , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v3 2/3] x86/viridian: Implement synthetic timer direct mode Date: Fri, 11 Sep 2026 10:12:43 +0100 Message-ID: <20260911091244.1165516-3-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260911091244.1165516-1-ross.lagerwall@citrix.com> References: <20260911091244.1165516-1-ross.lagerwall@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: DUZPR01CA0284.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b7::22) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SA0PR03MB5548:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d33197b-9631-4823-359e-08df0fe4ea16 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|10067099003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: BiPyTTITRFDepBqf/ARiPHDOfPg5WTuNDtrwyTAP8lxw6Et5tz53nLhsagHfGs+CuqfsPwE0hIe510ThhovwesOOY0DHEnlun1IZuRmcaJIB9N51DABM8ecuFUQw2cITLcFj1xsz3nZ3NtGZfoPqtV2tAyg3v8ysBCi3g/G0bZc9JJ1j1ABGMzYJmBmoFxMWCHSHVaVe/xIwEiZgN00E5h+9+1Suv1qRFx5MRzziQ+xRSKlUP5u0v3foMpPvQIpbn5Zc5PR1fsFxB8vNnSwio9CtwslyUugXW2g8AFJRdBJWAB5SBPJY8ozAt+od/OxGaIw3CCHCU9HI2ZhGadfQVhtq+CE2kJWV8dpiXkJwJr6uw7dW4D+q7yy91UZbGc53H7U2w35md0Yy5FTeeUFW8F7pDK3YUj+104IV3zbt+RfMYeLP52x2bkrPiD9hrPgeMqEfxHzK95A/Mdaooyvy1H/nA/nDbq//MQh8o/0xhAFhjYEm8Lea1GrhM+gC0/oW+BFrx66i0hM6s5uE2ycO4k4B02SAVaQfJAxBM9yzFCE0agf2zq39KOySvN9TkmeUBFZ4YIKO/2iaiGbsnKzc2Y6L8ANT2wKGzmIz6OsKU7DTxGz+dfQabFMA4IPxvxYw3ygW3/ZIeeYbqp8oEdIz0gSl0KEdjLGTGxG6bbDsZnE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(10067099003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?hc1RMrP9UHzqUAHp05fnUhOS2clpRPOOmleKmBSwkW0U2DGzOOynkWUg3Nml?= =?us-ascii?Q?IzazbaSq0E5C0UbzSu0qQhX2Xpwz3KssxK3CgaEHr5EKnyTiwXhTnTFqHO/y?= =?us-ascii?Q?NQhY0OhVtsWwDF5cEd5ozpzWyx71TYVyhoHs7a2PGift8096WwMnamqEBST5?= =?us-ascii?Q?MfMprcedZN3JvaKMw7vxJvQFmtQ1MWg7BVKNk6ktl/+uPUPt94UikwC/84Eb?= =?us-ascii?Q?913GA1IvQzM0FxqNmdNTk/Rh1GRWuZgIDQgsCExxOs/Qfp7hpPJ9mJrbdPlk?= =?us-ascii?Q?lreRrz2W3loABDpwnl7k/RyOMwxdiVfJkl1NlupEQJngUNOlsPoy7ovr1yEq?= =?us-ascii?Q?KNJwssmREJSCmZKfV3K3oQYXpfyDQc+Y7Mq6vyu+7ny6u74k0pPasl1fldtm?= =?us-ascii?Q?VlFM/e2yBeFnJ6X65rfzcExp80dTlOBS1EtW3nKAbFRAACez+xFf2MExpXx6?= =?us-ascii?Q?T/4pG1DDZWIpdNFqiAdf5EJVkXL4s5AZ6Ug5omsRxYYRcMbFX3a5rtc6iceT?= =?us-ascii?Q?oqJ6evHwzs3lDwTWkPAHIASkur5lVYQMtoXTBo5iWNsJGx1OM1fqhZ39z8IQ?= =?us-ascii?Q?Mo/mcv2NrZS2wcFSrF1QWOxciGiT7mWZQIqJ2iujjnK53859FWTwvJFKOTsC?= =?us-ascii?Q?0WXQaT/vgUmrhaS7G/ZCTFRZuyeTAi/T7TJoWw2z/Olb8ajK72gzw/qceLGA?= =?us-ascii?Q?N5G2nWBQxTU+r7TU8NQxfEPYQIGtsTHXthEhh8r0DP3BWIYEgPcxAiqw+qU3?= =?us-ascii?Q?RpiwoPK0k/zcLlSw2fF/dnDmzjv0DTJCf3gl7rSB/KSzOa4Whzuz8Ig36MtS?= =?us-ascii?Q?QBD4lvoJ91ynOxHSpTWbAgDLIQv9ZTs6eSJf6Ord6yLFXrVwdQq0fYTa9dS5?= =?us-ascii?Q?JXQFxmqmhH0dqbnH9a/Z1yrdO4Xcixek0Fy7HcCc7aJhd1ipVpsKXGNCkwZF?= =?us-ascii?Q?PsyVsapEwrVgLAK1LHV81qMDgUVF6KX5xFFLcVkkLEUvFjrhCAvHktgyK16O?= =?us-ascii?Q?T8nD5oJZGn32ExuNJcO+0VeQrltVqnxYfB1jHbjmMmfNVVOF8ufaUJad+pj+?= =?us-ascii?Q?DNrxIC6uUdDKH+ZFjz3ntLZI9Ksbc4NQVnkkXUiXPWfZdgHZFfGLRE8/QAJg?= =?us-ascii?Q?7yNFmC21AFFs804Hf9KZR/7AFMLIogyR/lsuUkat2s2XlgOt6d9bsrXZ7Q/t?= =?us-ascii?Q?1VBJfFuprxDe/L5Zg85EQeZIJyzI1oMAsrDaF2oAsL4svUejhmeaGd/1R4Qe?= =?us-ascii?Q?eh1/BUixYNzmX4y7PJ+NJ0hjpJ+oftgDTAG4kvzFwi4BBy4IyAP15WUBiJYL?= =?us-ascii?Q?kRREmd+qHkxuqafNpPQEsYr7lRmiGgiY4wgWRWfYglXAc3Ar61qF38R/VS2m?= =?us-ascii?Q?cSQ7aWN/aVOsuDVO4Wrx65hBLCO1Ftl9dguPqaJhjYQ5xwoYJZLKUcmit7Dj?= =?us-ascii?Q?OuIa8yBKncVnb9DKCvYenUXJ7zTglz4mjFI3xzV5UCXdl2j8W4eGzEz2qy44?= =?us-ascii?Q?5eZ50+elT80BKIfbyhfo0+fBZ9oH9m2BibNK6qt6u5HcwyZ1wSyp4u1w6MeU?= =?us-ascii?Q?pEl1lTz3mTGXjalJ5EKxFQXUXhi+/dqg31ewI9VRCxdvRzyMNJSdn5ld2mpf?= =?us-ascii?Q?M6bZY3XEFQCdKZh04tN4mhXCKZGRObbWb3AIviDGbEk8uLQYk1kZNQ15W4XT?= =?us-ascii?Q?9CxGfFSnJ3NSRYkbKro3fpUdskxvmgflc3soU/gcLrkeZbPYx/jM4+hXXj8I?= =?us-ascii?Q?j2PbEdbLiJksSQdnGq+eKf7Q73uTBh0=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d33197b-9631-4823-359e-08df0fe4ea16 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:13:16.5681 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nONw5+Ls/F9MF1j6SdZSJej5ozcT5ujkUWA99qaQ/C/+t3zTtwPGSFOs+MCPQEi6qwmw1FKCKp5QlMyPec/o+1mn1WyrJ7pnhwMHqZxex4s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5548 X-purgate-ID: tlsNG-42698a/1789117999-1ACDF9EA-E379AD41/0/0 X-purgate-type: clean X-purgate-size: 6181 In direct mode, the timer asserts an interrupt on expiration rather than using a SynIC message. It is useful to implement this since Windows 11's Hyper-V can only use synthetic timers in direct mode. To avoid changing behaviour in existing guests, add a new Viridian flag, stimer_direct, to control whether this feature is visible and usable. At the same time, check that the reserved bits are zero and the APIC vector is only set when using direct mode since this is enforced by Hyper-V (although not mentioned in the spec). Signed-off-by: Ross Lagerwall --- In v3: * For compatibility, keep the existing behaviour when the feature flag is not enabled. * GP fault if reserved bits are set. * GP fault if APIC vector is set when !direct. xen/arch/x86/hvm/viridian/time.c | 44 ++++++++++++++++++++++++---- xen/arch/x86/hvm/viridian/viridian.c | 3 ++ xen/include/public/hvm/params.h | 7 ++++- 3 files changed, 47 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c index 082528dc9416..65654cf96937 100644 --- a/xen/arch/x86/hvm/viridian/time.c +++ b/xen/arch/x86/hvm/viridian/time.c @@ -223,6 +223,21 @@ static void start_stimer(struct viridian_stimer *vs) set_timer(&vs->timer, timeout + NOW()); } +static bool stimer_direct_mode(const struct vcpu *v, + const union hv_stimer_config *config) +{ + return (viridian_feature_mask(v->domain) & HVMPV_stimer_direct) && + config->direct_mode; +} + +static void stimer_deliver_direct(struct vcpu *v, const struct viridian_stimer *vs) +{ + struct vlapic *vlapic = vcpu_vlapic(v); + + if ( vlapic_enabled(vlapic) ) + vlapic_set_irq(vlapic, vs->config.apic_vector, 0); +} + static void poll_stimer(struct vcpu *v, unsigned int stimerx) { struct viridian_vcpu *vv = v->arch.hvm.viridian; @@ -242,9 +257,11 @@ static void poll_stimer(struct vcpu *v, unsigned int stimerx) if ( !test_bit(stimerx, &vv->stimer_pending) ) return; - if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx, - stimerx, vs->expiration, - time_ref_count(v->domain)) ) + if ( stimer_direct_mode(v, &vs->config) ) + stimer_deliver_direct(v, vs); + else if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx, + stimerx, vs->expiration, + time_ref_count(v->domain)) ) return; clear_bit(stimerx, &vv->stimer_pending); @@ -361,6 +378,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) case HV_X64_MSR_STIMER2_CONFIG: case HV_X64_MSR_STIMER3_CONFIG: { + union hv_stimer_config new; unsigned int stimerx = (idx - HV_X64_MSR_STIMER0_CONFIG) / 2; struct viridian_stimer *vs = &array_access_nospec(vv->stimer, stimerx); @@ -368,11 +386,21 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val) if ( !(viridian_feature_mask(d) & HVMPV_stimer) ) return X86EMUL_EXCEPTION; + new.as_uint64 = val; + + if ( new.reserved_z0 || new.reserved_z1 ) + return X86EMUL_EXCEPTION; + + if ( stimer_direct_mode(v, &new) ? + new.apic_vector < 0x10 : new.apic_vector ) + return X86EMUL_EXCEPTION; + stop_stimer(vs); vs->config.as_uint64 = val; - if ( !vs->config.sintx || !vs->count ) + if ( (!stimer_direct_mode(v, &vs->config) && !vs->config.sintx) || + !vs->count ) vs->config.enable = 0; if ( vs->config.enable ) @@ -583,8 +611,12 @@ void viridian_time_load_vcpu_ctxt( vs->config.as_uint64 = ctxt->stimer_config_msr[i]; vs->count = ctxt->stimer_count_msr[i]; - if ( !vs->config.sintx || !vs->count ) - /* Reject enabling with a zero sintx or count fields. */ + if ( (!stimer_direct_mode(v, &vs->config) && !vs->config.sintx) || + !vs->count ) + /* + * Reject enabling with a zero sintx (if not using direct mode) or + * zero count field. + */ vs->config.enable = 0; } } diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridian/viridian.c index 90e749ceb581..90be5842b995 100644 --- a/xen/arch/x86/hvm/viridian/viridian.c +++ b/xen/arch/x86/hvm/viridian/viridian.c @@ -78,6 +78,7 @@ typedef union _HV_CRASH_CTL_REG_CONTENTS #define CPUID3D_CPU_DYNAMIC_PARTITIONING (1 << 3) #define CPUID3D_CRASH_MSRS (1 << 10) #define CPUID3D_SINT_POLLING (1 << 17) +#define CPUID3D_STIMER_DIRECT_MODE (1 << 19) /* Viridian CPUID leaf 4: Implementation Recommendations. */ #define CPUID4A_HCALL_REMOTE_TLB_FLUSH (1 << 2) @@ -185,6 +186,8 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t leaf, res->d |= CPUID3D_CRASH_MSRS; if ( viridian_feature_mask(d) & HVMPV_synic ) res->d |= CPUID3D_SINT_POLLING; + if ( viridian_feature_mask(d) & HVMPV_stimer_direct ) + res->d |= CPUID3D_STIMER_DIRECT_MODE; break; } diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h index 99c40b4287f1..4db5142970c2 100644 --- a/xen/include/public/hvm/params.h +++ b/xen/include/public/hvm/params.h @@ -159,6 +159,10 @@ #define _HVMPV_cpu_hotplug 12 #define HVMPV_cpu_hotplug (1 << _HVMPV_cpu_hotplug) +/* Enable STIMER direct mode */ +#define _HVMPV_stimer_direct 13 +#define HVMPV_stimer_direct (1 << _HVMPV_stimer_direct) + #define HVMPV_feature_mask \ (HVMPV_base_freq | \ HVMPV_no_freq | \ @@ -172,7 +176,8 @@ HVMPV_hcall_ipi | \ HVMPV_ex_processor_masks | \ HVMPV_no_vp_limit | \ - HVMPV_cpu_hotplug) + HVMPV_cpu_hotplug | \ + HVMPV_stimer_direct) #endif -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:13:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:13:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416070.1645249 (Exim 4.92) (envelope-from ) id 1x4xK4-0008Vi-6r; Fri, 11 Sep 2026 09:13:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416070.1645249; Fri, 11 Sep 2026 09:13:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xK4-0008Vb-3T; Fri, 11 Sep 2026 09:13:28 +0000 Received: by outflank-mailman (input) for mailman id 1416070; Fri, 11 Sep 2026 09:13:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xK2-0008Sx-KD for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:13:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xK2-008eKE-0d for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:13:26 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3c628-8faa-0a2a0a5109dd-0a2a4501c7c8-44 for ; Fri, 11 Sep 2026 11:13:26 +0200 Received: from [52.101.193.13] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3c634-5984-0a2a45010019-3465c10daf7b-3 for ; Fri, 11 Sep 2026 11:13:25 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SA0PR03MB5548.namprd03.prod.outlook.com (2603:10b6:806:c3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Fri, 11 Sep 2026 09:13:23 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:13:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gqdm9P1wzkv1DtYZ6Kk0OZTv7rKWdaSBsyos6Y29JQyqKuTKtDKGx5QTsBzvGPNpZ8qPwI17CoTM28Zq/YUCksBOjpptaVbwfp//5CQFId6Suit6bHr0/UjHhkUTyGMkUAntzieKg6NU6iLELmdn+bAMWctjihZwG6nMH5WKU1PWCZYZzCoW+NIH6F2wi8u2WkZSJ/OFG8b6qSoAxpAWNkhcWErUTIx5VnFn5qFmKwW9XNV2mcLXoyFTcHVpkvS534ETdkkeGhGmuBrunh/EvGVFOI3dqwXdy/HvzvSIXPwsYSTVwxeLIGKoGCOK/jouPsVpEWzcaksJuJB3wShAZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KEiaB5ZRgIvBm1/l1Np+Vw8BCS5ijucJq0EQQr6Ip8s=; b=rOKcfTFXKyA1oyF5G15hczL6cAI6NYw4JrEZ/vjAUDCsxRkD6pDcJSrv5f/OieeCuxkrrNiZqddkdzR/oub6UupQljwdVWfFgsrY5v7anHLb4z2ZHFukXL/8baMx38JXOvhf5vWyk1hTp2POGaIca6Yt+MdDv04edTtDWtDNFJBaQ/w/WSD/k4g8uBiDI2hPBFFWAclgic0yMVbeOSaDhjpNsw0rdWAL7AK15jT35j27++3k3o3BTJ0w+O01dXVdqouiGY6MqCksz9IEqG72lau6hxjs6QQDIqiLSC+MfI3V2oc+GZhAL40D2FyY/xoiCNPcJz8H0pxlx5wD+cYWSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KEiaB5ZRgIvBm1/l1Np+Vw8BCS5ijucJq0EQQr6Ip8s=; b=gJizNfonE+FJACvaz9ZM78GqQ6rDhaFl6C8hr9HRtrEsYQpBvRcx8iu/ZlM7CJRNml/YRM1xJiaFyrM3HAPoIdp0ZgXMk4UhPQKDU2adB/BlqF1GZ7nqowOJEKPG8r5Epp/xEIoaHiMxpvdqoBtkNdx2aHgRRjEDloiQVYWp9cw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Anthony PERARD , Juergen Gross Subject: [PATCH v3 3/3] tools/libxl: Add support for Viridian stimer direct mode Date: Fri, 11 Sep 2026 10:12:44 +0100 Message-ID: <20260911091244.1165516-4-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260911091244.1165516-1-ross.lagerwall@citrix.com> References: <20260911091244.1165516-1-ross.lagerwall@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0421.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18b::12) To DS0PR03MB8272.namprd03.prod.outlook.com (2603:10b6:8:28f::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SA0PR03MB5548:EE_ X-MS-Office365-Filtering-Correlation-Id: 517c9659-8162-43bc-91ec-08df0fe4ede4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|10067099003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 6aJQioBvbO0Mf8e0EyK66hEPHm+KMLqanIxRzZ4T0W9vWRnyuhXbTx9sLziM5mIijcA3aQMRbOUuZrdoUZpAPUUgCK/MGjgsM8mkzw2rScbGwvFgxYJqo6oUBuRxcV1m0Gg7Y/vIkeGF0XLmoT3c5GCd+9HjGSQnSFgzH0VFkkYCiJzrT+lIbH61a20nJ4ey0ycp7VMIs3UQosxjD9DXCxWmkhY7Nb/XFOLEAI1LU0YybRZRv2PU2ipjKY2Ri0/03NYKf/JGCNwAX3LvEAgQG4rfRGPMjMsEA5gvdgd+Djz+DS3GgCueRUkwVIDp/DvMlF7LaOY+GyZ5NkvM6t3FP+Sm9l5NtIag7XwjSSpQIuJchGHYY05F8lhjSZ+nFZvYHlqaebveRvtInZWameHXfdIc/WiwmzL8CzVFbbpZKXdLLaPMqufxuA1FqyyfRw9/rq4vKDwoicrP7mIXKhdOjDXm/pK2a0t1h0rQXIGDEI9C/AIJBjAZ08vUx6lT/TjY81+sF/Z0yXnUfjO67bktCfnVxLbt9/8A1Oi8qWdbUmZxiKhOYItWw4IqeweTCoLbZWFfInFnVbbcf5GxHgVMBJ/dM1icBFytQEmYgC+rX1vUvYzCjKOfVkFtNGhI1AQMk7wVKGk7he7IFgnFaQIRq2xikT7DcAJm7ctouXpH+fs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(6133799003)(10067099003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?K32RK+2PmpFC9Pv8zgqgVF1eSfRDF0Kq12NgLajHXr4a6xW5xx+5512O+wZQ?= =?us-ascii?Q?Sm5fFueekNLIKP3XbJXblez4UxRKoqK0/Mopmn8nb5E19qRF81ngusc9vySl?= =?us-ascii?Q?SGMaFgR70ty2yJhXgj5F/4kQzONxmwh+RheMwuDdWbO2FA/8OVk9wj3upfv+?= =?us-ascii?Q?IEsRgo9mK3oI95y0frjWxk79Ba9Zdeu1u9GWfj2HPpsQVD2mUTwaMP7ZnU2g?= =?us-ascii?Q?HYOO/a/29nZ+65RZKErnSenlmwghn/FgtQfyKFZqRhQHTU8nNOaO/tnJWzgw?= =?us-ascii?Q?2BXJNOWhdfZTNckSUQEKsu3RlEd05BUYPgjm4WmKmVDMkXArMUVJS9AFnXeH?= =?us-ascii?Q?XQb9O0ktdbsEnHA7P5p6TdiChV/roU+Fbop5CANKTKlUwiotSBwTZuawG/dG?= =?us-ascii?Q?zMxAkRi6jmKyOoAGI80kk9nLDt45h5ACcVEC+3gtHLDm9Jwe1wSmwug/9nDW?= =?us-ascii?Q?qPzCjTS8ZnU1no+VeC+vqi7w7XjS4nwn8QAk9WNefbdEinhEYjrHXdkvu+TL?= =?us-ascii?Q?wEEESmNlGlZ3n9euB3cWhFxSywGBO51RUao4dmIjSTIj9F/SZS0ylR3FbrpL?= =?us-ascii?Q?qa53Cnby8ua2/S27jEHnc47UQHyp4XQHXEt/vSIl5HdxRIxqTsSYK8mVTUMc?= =?us-ascii?Q?xOGS7WFtK9aU6NnJEVfqtGhS4OU1Q2ijEWzE3RglPdtNmPf2W5MTk9U2dUhF?= =?us-ascii?Q?sI453GHojZGSRsMOIncin+vBs4rFIGoIycvhE0MUuV7HCoMafgwRWxsq2wYq?= =?us-ascii?Q?Cs4JhNsi+NYsCt0AuEqsGR4X2CKU/rDYdusnMNYVTJuyADqyUdRAmjxINtKC?= =?us-ascii?Q?89TsxtUVt+bvOE15aOIkOI3hc0INO6PcRGxGVLa/v1M9no9qU9kUuq58B93W?= =?us-ascii?Q?g9iDDl6J8QH5oPKfYiPVVyleXJqulA4KaMO9lXx8Lt+akSn1g5vfK1EkjNvQ?= =?us-ascii?Q?2OC9ug1/JZGYUWwk4CPfLOQTc7CKWA9hRT7h31fO3qPn/1ZsKas4KmC5RQff?= =?us-ascii?Q?mN2C+/LIrsp28QQ99ZCNGr2UffQSEZ3sN6Jgz8XNQLndaBdrXG27x1c/vYD4?= =?us-ascii?Q?/AVF5XbM8DvZsJS/uUIhl99drXTpToro9oLd7ZDtsjMhXyoSGRB42QTCh/xC?= =?us-ascii?Q?ZILSYSz72YAI1xwdt4SOxNtN59VYs+DKkgYyT1gSnAC6QrYegTZOuYa9Ekgi?= =?us-ascii?Q?lULHQ5vBhEHwvfUsjVjE4L/8DEfqREUiA1VZPhB7wzRzBs9FdQckraaVGLX3?= =?us-ascii?Q?WluYGCc0I7PXVTmkxhLGn2FOXrQQ1FNU0Jn9FMdr8mdwhwSJv4Epiq55asi2?= =?us-ascii?Q?lyKv5s4jQkulDdpUHT/G7sk5OibAh3JdpFzY5Xx3/sZnsEeAhPfA3QR5mEXm?= =?us-ascii?Q?iHLI5Nir8UtGJRh35eMd0XAZFji6n9z9+aacr1awmvf/l78pU93cRzVVvXH+?= =?us-ascii?Q?VeX0xSwkep38NMpEMLecskk8fFRd0EnJ1G5PXBwQG+5fLPpYcmyYSIAm/YdC?= =?us-ascii?Q?upymSUaujHkyOFcXcx2l7aUsby9Le2fkfRySWKBetP+vmE5VrRYqOAW7UTSE?= =?us-ascii?Q?IFyiaxXPbhdTNJLQQVQWSILkD2k1kLSXYvI4dYF5dwyE328gNS924R88ONPV?= =?us-ascii?Q?QvP+KtKgbCug9qq0F5y+RlYxU09jAjkt7lQxZguS6JinFXTpYizKhmQTze4h?= =?us-ascii?Q?Ka9/lJcu4+lqkrWFQynIvTxAPBJanqkvw/ZBHpPzRhvgp6u40l1/uf0Yx2l1?= =?us-ascii?Q?riF7JZj2HzEuHVoe5Ow8bL90ZhBvNss=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 517c9659-8162-43bc-91ec-08df0fe4ede4 X-MS-Exchange-CrossTenant-AuthSource: DS0PR03MB8272.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:13:23.2831 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Wc4/uyzeVu9owGBVPyscqOVLJg2Tg7CqePmh8ebwHy357vUJMejXt6ZrXJ7pFLNVqIGqoN3UnsAEN21N6xsL4VX6oefL6JLGvujw2mkSwdA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5548 X-purgate-ID: tlsNG-d62444/1789118005-BEC61757-1BEB8274/0/0 X-purgate-type: clean X-purgate-size: 2760 Add support to libxl for using the stimer enlightenments in direct mode. Signed-off-by: Ross Lagerwall --- In v3: Fix typo in docs docs/man/xl.cfg.5.pod.in | 5 +++++ tools/include/libxl.h | 6 ++++++ tools/libs/light/libxl_types.idl | 1 + tools/libs/light/libxl_x86.c | 5 +++++ 4 files changed, 17 insertions(+) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index d34951edb98d..30c401588fef 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -2496,6 +2496,11 @@ ticks and hence enabling this group will ensure that ticks will be consistent with use of an enlightened time source (B or B). +=item B + +This set is the same as the B set but additionally supports +using synthetic timers in direct mode. + =item B This set incorporates use of a hypercall for interprocessor interrupts. diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 7c098edab663..5475530a5002 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -381,6 +381,12 @@ */ #define LIBXL_HAVE_VIRIDIAN_HCALL_IPI 1 +/* + * LIBXL_HAVE_VIRIDIAN_STIMER_DIRECT indicates that the 'stimer_direct' value + * is present in the viridian enlightenment enumeration. + */ +#define LIBXL_HAVE_VIRIDIAN_STIMER_DIRECT 1 + /* * LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that * libxl_domain_build_info has the u.hvm.acpi_laptop_slate field. diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index a7893460f013..95075f04fe45 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -260,6 +260,7 @@ libxl_viridian_enlightenment = Enumeration("viridian_enlightenment", [ (10, "ex_processor_masks"), (11, "no_vp_limit"), (12, "cpu_hotplug"), + (13, "stimer_direct"), ]) libxl_hdtype = Enumeration("hdtype", [ diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c index 60d4e8661c93..9e8b48372d63 100644 --- a/tools/libs/light/libxl_x86.c +++ b/tools/libs/light/libxl_x86.c @@ -389,6 +389,11 @@ static int hvm_set_viridian_features(libxl__gc *gc, uint32_t domid, if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_CPU_HOTPLUG)) mask |= HVMPV_cpu_hotplug; + if (libxl_bitmap_test(&enlightenments, + LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER_DIRECT)) + mask |= HVMPV_time_ref_count | HVMPV_synic | HVMPV_stimer | + HVMPV_stimer_direct; + if (mask != 0 && xc_hvm_param_set(CTX->xch, domid, -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:35:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:35:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416119.1645280 (Exim 4.92) (envelope-from ) id 1x4xey-0004PZ-3J; Fri, 11 Sep 2026 09:35:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416119.1645280; Fri, 11 Sep 2026 09:35:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xex-0004PS-Vr; Fri, 11 Sep 2026 09:35:03 +0000 Received: by outflank-mailman (input) for mailman id 1416119; Fri, 11 Sep 2026 09:35:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xew-0004PM-1L for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:35:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xev-00DN2F-EK for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:35:01 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3cb40-bab6-0a2a0a5309dd-0a2a4504e7ca-16 for ; Fri, 11 Sep 2026 11:35:01 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3cb44-b57f-0a2a45040019-b9ff1c239559-3 for ; Fri, 11 Sep 2026 11:35:00 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08fd1f824000c4f3.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 09:34:57 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id CD60B81DE6; Fri, 11 Sep 2026 11:34:56 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=V6ehQ3GislKOhcMO53ERQFc16kU74eLe/iSxzYSjlyk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=dLjbqi4pvdNficxU+mrYf+99rP6sn5lBDjiUVRvydqbqs8qompgvZoTlF0kM1nIttS0gYuhVU 96PMyN/qOC8UBTMqlGtXgzec0+qc7VdvSydkNnx9X44HNTeU0RRYQB8XxYBpUs9aec2R1fEK3/H ybVpyNz3L72kWN7z7RtRNyDaX7c0cfIAhjxUv9A9sv5M739513G5t3uV8CbYg2NN6+Dc42SkhH7 Z/juQMMfCdlu3QwjD5IZ6/6rcNQH9gvROpyj/vcKkxhCGcbLu8UsS90mlNsbsgDAqTNS8Qn1lHu xF6V//ej5yvI4J5MlDjndrntwd1t2iy9QuZv2xbvUaAg== X-Zone-Loop: 982c0ac3840f1e1bc86806bed730b104eb9ce1601069 x-campaign-type: default x-transaction-id: d2faae3c-1351-47eb-946f-dbc3df930418 x-swg-uid: 01-6dc1cc93-3672-4030-8084-a6adfcc263b6 X-Mailer: Sweego Message-ID: <1789119297.8631fc262581453bbf619ec5b2062170.1a08fd1f824000c4f3@vates.tech> x-swg-bid: 1789119297.8631fc262581453bbf619ec5b2062170.1a08fd1f824000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 11 Sep 2026 11:34:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] vmx: Refactor vpid_sync_vcpu_gva() To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509305.8631fc262581453bbf619ec5b2062170.19fb8a5db67000e099@vates.tech> <1a42fad1-922d-441d-9837-f4c43854a5b1@suse.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <1a42fad1-922d-441d-9837-f4c43854a5b1@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------diKt5bgiUxQOPK85h8LhfW89" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789119296947 X-purgate-ID: tlsNG-ebf023/1789119301-51AD0B50-962C882B/0/0 X-purgate-type: clean X-purgate-size: 8310 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------diKt5bgiUxQOPK85h8LhfW89 Content-Type: multipart/mixed; boundary="------------cdWuHpJTJGfKkHXL2uBsgWx0"; protected-headers="v1"; hp="clear" Message-ID: Date: Fri, 11 Sep 2026 11:34:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] vmx: Refactor vpid_sync_vcpu_gva() To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509305.8631fc262581453bbf619ec5b2062170.19fb8a5db67000e099@vates.tech> <1a42fad1-922d-441d-9837-f4c43854a5b1@suse.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <1a42fad1-922d-441d-9837-f4c43854a5b1@suse.com> --------------cdWuHpJTJGfKkHXL2uBsgWx0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTAvMDkvMjAyNiDDoCAxNzo0NSwgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gT24g MzEuMDcuMjAyNiAxNjo0NiwgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiAtLS0gYS94ZW4vYXJj aC94ODYvaW5jbHVkZS9hc20vaHZtL3ZteC92bXguaA0KPj4gKysrIGIveGVuL2FyY2gveDg2 L2luY2x1ZGUvYXNtL2h2bS92bXgvdm14LmgNCj4+IEBAIC00NjAsMTkgKzQ2MCwxNiBAQCBz dGF0aWMgaW5saW5lIHZvaWQgdnBpZF9zeW5jX3ZjcHVfZ3ZhKHN0cnVjdCB2Y3B1ICp2LCB1 bnNpZ25lZCBsb25nIGd2YSkNCj4+ICAgICAgICAqIElmIGluZGl2aWR1YWwgYWRkcmVzcyBp bnZhbGlkYXRpb24gaXMgbm90IHN1cHBvcnRlZCwgd2UgZXNjYWxhdGUgdG8NCj4+ICAgICAg ICAqIHVzZSBzaW5nbGUgY29udGV4dCBpbnZhbGlkYXRpb24uDQo+PiAgICAgICAgKi8NCj4+ IC0gICAgaWYgKCBsaWtlbHkoY3B1X2hhc192bXhfdnBpZF9pbnZ2cGlkX2luZGl2aWR1YWxf YWRkcikgKQ0KPj4gLSAgICAgICAgZ290byBleGVjdXRlX2ludnZwaWQ7DQo+PiAtDQo+PiAt ICAgIHR5cGUgPSBJTlZWUElEX1NJTkdMRV9DT05URVhUOw0KPj4gKyAgICBpZiAoIHVubGlr ZWx5KCFjcHVfaGFzX3ZteF92cGlkX2ludnZwaWRfaW5kaXZpZHVhbF9hZGRyKSApDQo+PiAr ICAgICAgICB0eXBlID0gSU5WVlBJRF9TSU5HTEVfQ09OVEVYVDsNCj4+ICAgDQo+PiAgICAg ICAvKg0KPj4gICAgICAgICogSWYgc2luZ2xlIGNvbnRleHQgaW52YWxpZGF0aW9uIGlzIG5v dCBzdXBwb3J0ZWQsIHdlIGVzY2FsYXRlIHRvDQo+PiAgICAgICAgKiB1c2UgYWxsIGNvbnRl eHQgaW52YWxpZGF0aW9uLg0KPj4gICAgICAgICovDQo+PiAtICAgIGlmICggIWNwdV9oYXNf dm14X3ZwaWRfaW52dnBpZF9zaW5nbGVfY29udGV4dCApDQo+PiArICAgIGlmICggdW5saWtl bHkoIWNwdV9oYXNfdm14X3ZwaWRfaW52dnBpZF9zaW5nbGVfY29udGV4dCkgKQ0KPj4gICAg ICAgICAgIHR5cGUgPSBJTlZWUElEX0FMTF9DT05URVhUOw0KPj4gICANCj4+IC1leGVjdXRl X2ludnZwaWQ6DQo+PiAgICAgICBfX2ludnZwaWQodHlwZSwgdi0+YXJjaC5odm0ubjFhc2lk LmFzaWQsICh1NjQpZ3ZhKTsNCj4+ICAgfQ0KPiANCj4gQnV0IHRoaXMgaXNuJ3QgZnVuY3Rp b25hbGx5IGlkZW50aWNhbCB0byB0aGUgb3JpZ2luYWwsIGF0IGxlYXN0IGluIHRoZQ0KPiBj cHVfaGFzX3ZteF92cGlkX2ludnZwaWRfaW5kaXZpZHVhbF9hZGRyICYmDQo+ICFjcHVfaGFz X3ZteF92cGlkX2ludnZwaWRfc2luZ2xlX2NvbnRleHQgY2FzZS4gV2UnZCBub3cgZW5kIHVw IHVzaW5nDQo+IElOVlZQSURfQUxMX0NPTlRFWFQgdGhlcmUsIHdoZW4gaXQgd2FudHMgdG8g Y29udGludWUgdG8gYmUNCj4gSU5WVlBJRF9JTkRJVklEVUFMX0FERFIuDQo+IA0KDQpZZXMs IHRob3VnaCBhIGdvb2QgcXVlc3Rpb24gaXMgdG8ga25vdyBpZiB0aGVyZSBleGlzdCBhIENQ VSB0aGF0IGhhcyANCklOVlZQSURfSU5ESVZJRFVBTF9BRERSIHdpdGhvdXQgSU5WVlBJRF9T SU5HTEVfQ09OVEVYVDsgb3RoZXJ3aXNlLCB3ZSANCmNhbiBqdXN0IHNheSB0aGF0IHRoaXMg aXMgbm90IHN1cHBvc2VkIHRvIGhhcHBlbi4NCg0KT25lIGFsdGVybmF0aXZlIEkgaGF2ZSBp biBtaW5kIHdvdWxkIGJlIHRvIGhhdmUgY2FzY2FkaW5nIGZhbGxiYWNrcyB0byANCiJsYXJn ZXIgc2NvcGUiIGFsdGVybmF0aXZlcy4NCg0KaS5lDQoNCnN0YXRpYyBpbmxpbmUgdm9pZCB2 cGlkX3N5bmNfYWxsKHZvaWQpDQp7DQogICAgIF9faW52dnBpZChJTlZWUElEX0FMTF9DT05U RVhULCAwLCAwKTsNCn0NCg0Kc3RhdGljIGlubGluZSB2b2lkIHZwaWRfc3luY192Y3B1X2Nv bnRleHQoY29uc3Qgc3RydWN0IHZjcHUgKnYpDQp7DQogICAgIC8qDQogICAgICAqIElmIHNp bmdsZSBjb250ZXh0IGludmFsaWRhdGlvbiBpcyBub3Qgc3VwcG9ydGVkLCB3ZSBlc2NhbGF0 ZSB0bw0KICAgICAgKiB1c2UgYWxsIGNvbnRleHQgaW52YWxpZGF0aW9uLg0KICAgICAgKi8N CiAgICAgaWYgKCB1bmxpa2VseSghY3B1X2hhc192bXhfdnBpZF9pbnZ2cGlkX3NpbmdsZV9j b250ZXh0KSApDQogICAgICAgICByZXR1cm4gdnBpZF9zeW5jX2FsbCgpOw0KDQogICAgIF9f aW52dnBpZChJTlZWUElEX1NJTkdMRV9DT05URVhULCB2LT5hcmNoLmh2bS5uMWFzaWQuYXNp ZCwgMCk7DQp9DQoNCnN0YXRpYyBpbmxpbmUgdm9pZCB2cGlkX3N5bmNfdmNwdV9ndmEoc3Ry dWN0IHZjcHUgKnYsIHVuc2lnbmVkIGxvbmcgZ3ZhKQ0Kew0KICAgICAvKg0KICAgICAgKiBJ ZiBpbmRpdmlkdWFsIGFkZHJlc3MgaW52YWxpZGF0aW9uIGlzIG5vdCBzdXBwb3J0ZWQsIHdl IGVzY2FsYXRlIHRvDQogICAgICAqIHVzZSBzaW5nbGUgY29udGV4dCBpbnZhbGlkYXRpb24u DQogICAgICAqLw0KICAgICBpZiAoIHVubGlrZWx5KCFjcHVfaGFzX3ZteF92cGlkX2ludnZw aWRfaW5kaXZpZHVhbF9hZGRyKSApDQogICAgICAgICByZXR1cm4gdnBpZF9zeW5jX3ZjcHVf Y29udGV4dCh2KTsNCg0KICAgICBfX2ludnZwaWQoSU5WVlBJRF9JTkRJVklEVUFMX0FERFIs IHYtPmFyY2guaHZtLm4xYXNpZC5hc2lkLCAodTY0KWd2YSk7DQp9DQoNClRoYXQgcmVxdWly ZXMgaW50cm9kdWNpbmcgdnBpZF9zeW5jX3ZjcHVfY29udGV4dCgpIGFoZWFkLCBidXQgd291 bGQgDQphdm9pZCB0aGUgY29ybmVyIGNhc2Ugd2l0aG91dCBtYWtpbmcgdGhpbmdzIHRvbyBj b21wbGV4Lg0KDQo+IEphbg0KDQpUZWRkeQ0K --------------cdWuHpJTJGfKkHXL2uBsgWx0-- --------------diKt5bgiUxQOPK85h8LhfW89 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqjy0AFAwAAAAAACgkQZg+p0QLLz9BR LQwAkp3KeVor4hR32DbMDuwGgOSye0kEZucv30/cDP2QJ3cusq50PMIpx28zT+p30iHcjuuqv8lg o+Rw+zJDktUCDlN4DqywcqbB/rV0eZZefiQOoIQN0YSdSKrcXrCvKQ/MQicywqxI73iFQ5cpCZUT iIzwpqXu7sJOVspoVT7uMttXQBlaqY+eYYsAmyWbg/Xzx2gws3zpPPlBJH8CI2rX3QPYjULv6NWu +xhCE8EeKktpbakqFJWVbgkQNB1/JMuznOaDRQYSoPRyU+ZQVOf4C1t/qXdx7p/t0dVEUETLnvQq pzCP41PnkoLLHczLAbh936gb+9E8Qu1r/XiXmtd6ukGSJ3kTyBmLhiFbErq0r1eXg1+XldJbWlI7 h/BiemZ8o+QBg/S9/wZupgSMToHMYTg1pLyEcIsnalE3N4AoBhZXHPZOF/lm3Q5DySdv+/aZ5Mhl e77XawD105+ct7x/57jXNKEdlAonI4FRUoK7pKAZcjuMpxL6QQYvfNHUB7Dv =zp7d -----END PGP SIGNATURE----- --------------diKt5bgiUxQOPK85h8LhfW89-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:38:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:38:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416128.1645288 (Exim 4.92) (envelope-from ) id 1x4xi1-000572-Fi; Fri, 11 Sep 2026 09:38:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416128.1645288; Fri, 11 Sep 2026 09:38:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xi1-00056v-Cd; Fri, 11 Sep 2026 09:38:13 +0000 Received: by outflank-mailman (input) for mailman id 1416128; Fri, 11 Sep 2026 09:38:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xhz-00055X-OM for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:38:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xhy-003ILw-U0 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:38:11 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3cbf3-bab6-0a2a0a5309dd-0a2a450ce094-22 for ; Fri, 11 Sep 2026 11:38:10 +0200 Received: from [192.198.163.7] (helo=mgamail.intel.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3cbff-f479-0a2a450c0019-c0c6a307d6be-3 for ; Fri, 11 Sep 2026 11:38:09 +0200 Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2026 02:38:07 -0700 Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.244.158]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2026 02:37:41 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=Intel header.d=intel.com header.i="@intel.com" header.h="From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789119489; x=1820655489; h=from:date:to:cc:subject:in-reply-to:message-id: references:mime-version:content-id; bh=sb6ClNqSQhPq2ZVhuU+8klKUwkLjODKU96QOOaqi6Cw=; b=mvxroAT2UdWsWymjT43kAFl+kcFJugc5ykv7CvwyU6H+owZ7NYMnq9fl IJ/UDjLY72XtqMNj0GZ5qLKzxUzSLWWkdt9VxGjN0t+HxLlQQBDHYR8tH C/+bG8avMN6uzfOGDHfVvSgxbimL21m70Rg2LI61HK+RPwYstjrxtZpUw rQ6w3d+dZLbjMneIsPN91xWVVfCHQXzg/0T4wkoGfTtY45sY3UA1Rjb8S QhoxF8c9+gEF5/1ve1PuxbgqcmsM+x7F5EB6/CWAG9blBKcMUcZyXW1Cy D98QyqSsXdW2s6lHJels1uKhWKK/hOJmwh1QVLmJijlCChfXKke1sXmBE g==; X-CSE-ConnectionGUID: OzlVyZaDRpyUmf82PIcUWQ== X-CSE-MsgGUID: ubs3gCeGRUaLcoqt0KoTIw== X-IronPort-AV: E=McAfee;i="6800,10657,11901"; a="115120611" X-IronPort-AV: E=Sophos;i="6.27,97,1787036400"; d="scan'208";a="115120611" X-CSE-ConnectionGUID: SRo+o97pTgCUDHnSfx1bsQ== X-CSE-MsgGUID: d5IlSxrWQfGb/hpk+vV9Sw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,97,1787036400"; d="scan'208";a="296857533" From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Date: Fri, 11 Sep 2026 12:37:38 +0300 (EEST) To: Juergen Gross cc: LKML , x86@kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-fbdev@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Damien Le Moal , Niklas Cassel , David Airlie , Olivia Mackall , Herbert Xu , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Linus Walleij , Bartosz Golaszewski , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Arnd Bergmann , Greg Kroah-Hartman , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , Helge Deller , xen-devel@lists.xenproject.org, linux-geode@lists.infradead.org, Michael Kelley Subject: Re: [PATCH v3 12/13] treewide: convert rdmsrq() from a macro to an inline function In-Reply-To: <20260911074530.3140830-13-jgross@suse.com> Message-ID: References: <20260911074530.3140830-1-jgross@suse.com> <20260911074530.3140830-13-jgross@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323328-1162080221-1789119116=:1171" Content-ID: X-purgate-ID: tlsNG-d25034/1789119490-03CD3A5B-0F405256/0/0 X-purgate-type: clean X-purgate-size: 1201 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1162080221-1789119116=:1171 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <085b47bf-864b-9802-2915-a51186e45c40@linux.intel.com> On Fri, 11 Sep 2026, Juergen Gross wrote: > Today rdmsrq() is a macro using its second parameter as the target for > storing the read MSR value. >=20 > Convert rdmsrq() to an inline function returning the MSR value. >=20 > The users have been converted using the following semantic patch: >=20 > // Options: --include-headers >=20 > virtual patch > virtual report >=20 > @@ > expression msr, val; > @@ > ( > - rdmsrq(msr,val) > + val =3D rdmsrq(msr) > ) >=20 > Signed-off-by: Juergen Gross > Acked-by: Damien Le Moal # ATA Acked-by: Ilpo J=E4rvinen =09=09# pdx86 What is the plan for merging this? > Reviewed-by: Michael Kelley # Hyper-V --=20 i. --8323328-1162080221-1789119116=:1171-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:43:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:43:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416142.1645296 (Exim 4.92) (envelope-from ) id 1x4xmt-0006mz-3O; Fri, 11 Sep 2026 09:43:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416142.1645296; Fri, 11 Sep 2026 09:43:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xmt-0006ms-0m; Fri, 11 Sep 2026 09:43:15 +0000 Received: by outflank-mailman (input) for mailman id 1416142; Fri, 11 Sep 2026 09:43:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xmr-0006mm-B2 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:43:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xmq-007yQA-O2 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:43:12 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3cd30-e002-0a2a0a5209dd-0a2a45028f24-0 for ; Fri, 11 Sep 2026 11:43:12 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3cd30-6ca4-0a2a45020019-4a7de18c96f5-3 for ; Fri, 11 Sep 2026 11:43:12 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd6185db7so4156595e9.1 for ; Fri, 11 Sep 2026 02:43:12 -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-49e62231360sm31386115e9.4.2026.09.11.02.43.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 02:43:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789119792; x=1789724592; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=KXruCpm1FZlW5PhmkXQefTqnjoavXk0VwdNRB1nW1Go=; b=ad83ypDaVwkv5jDI6Vzaevn6I1Xbad7ivE900wcZer6aOrdNLRghwECjBGTNkkR04y 2qYw25tfqOXokJgxrzuvspqtK2RvV9H9fUHmG6LBooGHMlcWHTx0+jaQJZgwJEzG1rgE gbEMSstpjxJWzBBGVIo/ZY/lqOHzUnOQ57hcg0RqloRRQMBgaGI7BXlxyr7YerIWQbEb NWjYR18Wq3OB534NOnLrzSChhztXWYMAEzxOQsTafSkQUm/YeM1z6I8scVUwbOhvk14e Jx8zaiu0TlKFM6lBodZ+g79n0Y0tbvt/b7sOkXD9mmO4PW9HJ1l8Rj0YpSupa0OwX3Cz TrRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789119792; x=1789724592; h=content-transfer-encoding:content-type: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:content-type; bh=KXruCpm1FZlW5PhmkXQefTqnjoavXk0VwdNRB1nW1Go=; b=bABak2jr3XX6QxlmSjQvnPP0Gy/06kZ/s84A1H9XmB00P7w7zcaYSJCpVv+f5JKaaP aeIrtmLoFj89ULINIifVkqKNRaIUlRxbU4Zv9vvgywjLwBDZAycb+ktfpt55ggnYoset NwgQ32g1ztXsGyWO3qFRgsvMo26nbRqmfndtCaG64FA+/fUJwmQPvylK1hGsUd5S4oou 5qx9uocTi6f0TRVS+pbvKHW2yiePE3KZ7G/VMZQEOFSduM9dnhMg/e1R85cOVLXKXeee vnZrGsZcgTKyep067huxaoWt/h36JOdHhFTnzS6jr1q9r+luIwSIrvkJEFK1axZmGP3J ugpw== X-Forwarded-Encrypted: i=1; AKwUvBypO6blzAWFFQ/tJcbIJr++dzAjsc/+eVcsAIickQibyw2MHYEdDokpNUegkJw1vq0wYAEkB8me7Sc=@lists.xenproject.org X-Gm-Message-State: AFuF++nl/6GiMA6GATzyk6im9lU0AWYHlfDK/cHlLth5WuI+2DOxT2xl lZBl7IWGlnM02AbGPsDI6yXCW0+EwcWMZ9dMX4LmiyCyqAl3YkJgjy+aQUraY0//uQ== X-Gm-Gg: AYBFou3dHwlVm8fUnAELA/hUgeylGQdjDvjLNil7ci4lfs9+0C+QIUCZ2JTXKNhZdan METH0H3A2dKLb+ZwBS2juwodbkF+6kWd8gbg9QEKNqr4GZXzrJYiDz8CQPg+JudXWqPOagO+vwV lk5uUYf4ORbYOWowffTHIS715Iu5iFlWKi4n/fsQNOgvj6Dwc0L2UDFrJYF5a8B5A1CkqjR8mw1 WM6v4LWXxP7i+ZHujhx+ZK8P1qI0qzcGwOoJZCagbUZYvF06FTmY0gLKqTgOqtEZ2CIDUTGrdPS i855Zq3CTnDDirTB4VGD20rbR2HFM7mKblTtn7xDtHYKqbooJv/jg1A+/NpwaJY3xfGkdg1XuAT arXr1UxXSLdLpvuoZdfutw3LvsP2e40ApbWpuFLE0WxE3ZALKsCMXPSzLbtHhhbDXc5K0FZ8HKi +c4D+CV5wRF50wyxwGBynslujWC95emB/tu1qG7hxAvjg9xV6ZMxGbEeOxN84VCWH8hZuKseXrL 7TLskUQfEZChm7/nb3rD5BWjNVknhJ5tNCAe+OrlBMfxWoYqL3cwQ8/8Lh1F32m X-Received: by 2002:a05:600c:c494:b0:49c:f13e:e52 with SMTP id 5b1f17b1804b1-49e610955dbmr43030625e9.15.1789119791915; Fri, 11 Sep 2026 02:43:11 -0700 (PDT) Message-ID: Date: Fri, 11 Sep 2026 11:43:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] vmx: Refactor vpid_sync_vcpu_gva() To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509305.8631fc262581453bbf619ec5b2062170.19fb8a5db67000e099@vates.tech> <1a42fad1-922d-441d-9837-f4c43854a5b1@suse.com> <1789119297.8631fc262581453bbf619ec5b2062170.1a08fd1f824000c4f3@vates.tech> 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: <1789119297.8631fc262581453bbf619ec5b2062170.1a08fd1f824000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789119792-F3EBB2AC-036BFF4F/0/0 X-purgate-type: clean X-purgate-size: 3007 On 11.09.2026 11:34, Teddy Astie wrote: > Le 10/09/2026 à 17:45, Jan Beulich a écrit : >> On 31.07.2026 16:46, Teddy Astie wrote: >>> --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h >>> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h >>> @@ -460,19 +460,16 @@ static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva) >>> * If individual address invalidation is not supported, we escalate to >>> * use single context invalidation. >>> */ >>> - if ( likely(cpu_has_vmx_vpid_invvpid_individual_addr) ) >>> - goto execute_invvpid; >>> - >>> - type = INVVPID_SINGLE_CONTEXT; >>> + if ( unlikely(!cpu_has_vmx_vpid_invvpid_individual_addr) ) >>> + type = INVVPID_SINGLE_CONTEXT; >>> >>> /* >>> * If single context invalidation is not supported, we escalate to >>> * use all context invalidation. >>> */ >>> - if ( !cpu_has_vmx_vpid_invvpid_single_context ) >>> + if ( unlikely(!cpu_has_vmx_vpid_invvpid_single_context) ) >>> type = INVVPID_ALL_CONTEXT; >>> >>> -execute_invvpid: >>> __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva); >>> } >> >> But this isn't functionally identical to the original, at least in the >> cpu_has_vmx_vpid_invvpid_individual_addr && >> !cpu_has_vmx_vpid_invvpid_single_context case. We'd now end up using >> INVVPID_ALL_CONTEXT there, when it wants to continue to be >> INVVPID_INDIVIDUAL_ADDR. >> > > Yes, though a good question is to know if there exist a CPU that has > INVVPID_INDIVIDUAL_ADDR without INVVPID_SINGLE_CONTEXT; otherwise, we > can just say that this is not supposed to happen. > > One alternative I have in mind would be to have cascading fallbacks to > "larger scope" alternatives. > > i.e > > static inline void vpid_sync_all(void) > { > __invvpid(INVVPID_ALL_CONTEXT, 0, 0); > } > > static inline void vpid_sync_vcpu_context(const struct vcpu *v) > { > /* > * If single context invalidation is not supported, we escalate to > * use all context invalidation. > */ > if ( unlikely(!cpu_has_vmx_vpid_invvpid_single_context) ) > return vpid_sync_all(); > > __invvpid(INVVPID_SINGLE_CONTEXT, v->arch.hvm.n1asid.asid, 0); > } > > static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva) > { > /* > * If individual address invalidation is not supported, we escalate to > * use single context invalidation. > */ > if ( unlikely(!cpu_has_vmx_vpid_invvpid_individual_addr) ) > return vpid_sync_vcpu_context(v); > > __invvpid(INVVPID_INDIVIDUAL_ADDR, v->arch.hvm.n1asid.asid, (u64)gva); > } > > That requires introducing vpid_sync_vcpu_context() ahead, but would > avoid the corner case without making things too complex. I think that would be fine. Ideally in the process the unnecessary cast and the const-vs-not inconsistency would also be addressed. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:45:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:45:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416151.1645306 (Exim 4.92) (envelope-from ) id 1x4xp7-0007OQ-Fg; Fri, 11 Sep 2026 09:45:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416151.1645306; Fri, 11 Sep 2026 09:45:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xp7-0007OJ-BT; Fri, 11 Sep 2026 09:45:33 +0000 Received: by outflank-mailman (input) for mailman id 1416151; Fri, 11 Sep 2026 09:45:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xp5-0007OD-G0 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:45:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xp4-00AziL-BY for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:45:30 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3cdb0-8faa-0a2a0a5109dd-0a2a450ae514-16 for ; Fri, 11 Sep 2026 11:45:29 +0200 Received: from [52.101.229.97] (helo=TY3P286CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3cdb6-f2d2-0a2a450a0019-3465e561c0b4-3 for ; Fri, 11 Sep 2026 11:45:28 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TYYP286MB5003.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:14b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 09:45:24 +0000 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:45:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vyl76/WuZDFO5DWAlgyoinFRVqPl4XclLt1gABD+rAtnatrUZ/BsJ1dRYAs9yFwi085Ull9Bd0QvQfEWUJ0xZAPJKgpCbxeAhIXLKZ0+HFPWb8OqO0AshRI9Xm5sBbLffwV2GS9n+4+KT1K/1rqRjTqKARlBK8q+bFaMARUcX9qvooVusOLwMqqyD2+qa4VtRlFSqW+xQBfczaGPpPF4UO8hULdO8l/goxVspMylc90hwywLXqmV93xfCHn11HB7raYehlR3APKocYNyXRm6k/wOW5tsgVaGeQy5tfrp1hAA33bBnDNFEax4GMs2pWgmRXZHF7D7abtmsgFRyiIM6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2v56xrYrz4wk5bZJ3cphgVcd9vTKypTw1w4TbLN7Ld0=; b=CR+YNCOq+agAS4k9haBBqG0S0HwiHVnKSZj55+6qL4PhgGbTxF3ri3hRj5iVRqYjWu8yzgrazf/O0HH9K+Zz6K4e5ySBu3XatYShExZ7mJ8/qw/9k/bG3+xGjtVbxaRFvJkseCTJbKLpdLG9S6TkxAoXTGmnF81jbhSy5NcmbiMHGmR1pKKWbbZ7DWuUqfFq7ttmz4wMmShE5Z5ZNfk8b3MC8kW4Mvw7zCyqMC9Ph4PlJqXccGbsX5fBGGz/PB0OJqZ8xA/JBHtJ87bVIAh+5Dx1ZNmXQ+aCh5h2VrF7oOJNnMtMSiVv9stf/1LEtd1rYCH2Mzgtv43UTNQdWY/zsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2v56xrYrz4wk5bZJ3cphgVcd9vTKypTw1w4TbLN7Ld0=; b=cX1UWO4dDmn4dYV0MF+SmfsgOAUfU2C8DR2N3jPot0stztH4BMacK/JB3BPhCXcImHQKQhlAfsX06TQ2cF6TQiviAlirV/paFTTum/wwbMS+LyXjxtB1YofnREzJ59TfXJmvr+Ka0Kkn15bbjNghtsMrcYSIFiciEENaCLZcGjw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Hirokazu Takahashi To: xen-devel@lists.xenproject.org Cc: michal.orzel@amd.com, Mykyta_Poturai@epam.com, Hirokazu Takahashi Subject: [PATCH v10 0/4] xen/acpi,device-tree: Introduce generic CPU topology support for ACPI and DT Date: Fri, 11 Sep 2026 18:42:09 +0900 Message-ID: <20260911094213.79936-1-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TY4P286CA0067.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:371::19) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TYYP286MB5003:EE_ X-MS-Office365-Filtering-Correlation-Id: 90c20f3a-7a79-410d-581c-08df0fe966ca X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|1800799024|23010399003|376014|366016|56012099006|3023799007|25016099003|18002099003|10067099003|29003799003|6133799003; X-Microsoft-Antispam-Message-Info: XwR4dc1vUbUplUNicr+UpPGu+o3j1+InZtFKOe/Ph9tIoaoaaE63BAUeRvkglLOpKenCA/omkp1ySWM7CQY9qUVX+CbIV0/lpcHsRQ0lC1QYCnlhfkEMjihVJg06t1eeDtIjoYz611S7JY7HsgL5Q8Jz791aEGi4czpEjTtzB8vRpDGtwtShULPwxIxtPovxqWnSdHDKGeIq1jCSYAxY9tj+gBkKfl4lsMrQh8mO1NilBKXOeHs8n7Yh7hl6D8BceNeCVt81aATM9VXSlIVwkfWe+IyQD1pnQoqP6QSkRjrw2AWMtHOdT2egnDILNtEdweU++NvIMD/Lr7sgE4435T5KU3OhDMDa7b83f79WaguMbOclU55Wrp6njb+rFMDYYmIF/12DhGuCN+W3JHiE4vC4gDcAGOtDnAMOUrkLTWI4p0FuPQrut1zr51f98mt26bXWg9N5oDlaB+CllP2d5CtbRqB6CM/dhASsab2+yLIDlFLeLcLxB2hgx04a4blZdyoCSF1ewprecLuY813FPyXYdh9mxfRY2830ns+Mi/eR/RS//N8yRIjoSnabIiZ72x8j3CfgAmZQpN40hYONK3dU/TE57dBwSN68QeSMHcBRtM8V4h3htNN6zp1Sh06ljgn1MYkvrHzZUhxPIG550QVrh/TdVOXjCotYZQ9T0+A= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(23010399003)(376014)(366016)(56012099006)(3023799007)(25016099003)(18002099003)(10067099003)(29003799003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?IruwKqZXYkLhTzgitwAFstuppa1XsiKgngVcwTs/waisqrvK6ke+V2CyvjfY?= =?us-ascii?Q?GTDqF9TIWZfOoqaU8rD/lcaPch+mOsToQSyA3C81pf+zw4PvXIvIF8capAHd?= =?us-ascii?Q?N/nB3rfOAElssaprMvcGw07yRwqSN8ipGD/nms8Pf1k8HSJVPXlqemvI9+9C?= =?us-ascii?Q?LMlhDUQQPkM1f4Tvg8T2+o+hhplUzVG7oUuTZhNqgKn4ocwBX6K2044DrUSL?= =?us-ascii?Q?4c6OPAZEGjYqyfRNhq0iiz2pfjy8EMaWOxD/7qgrDMauxMi917klPKIggonm?= =?us-ascii?Q?5VKzh0eFC/7f2yQHAwXB39s131YNVow769jFgYhHOEk41phDBBKKGVVd7d7J?= =?us-ascii?Q?ciNby2O1g0ne9GBqCGeTVAf/0y2aZJNhzgIBQq4V9q64LoziMXuIopg7G7es?= =?us-ascii?Q?IaNzukgNp074dLDixxhjTY7k2RibJIPlTiBlchIy/7fCTRsIaG78YM1oREog?= =?us-ascii?Q?hUswSoCLMBGW+YxOm8LiEHg/D8nxIv+LQdLn/dQXLyy6hOIzOwdCwKghHieA?= =?us-ascii?Q?czpULa/YpnTKuvc5RcnkHw/VWo3AZBJYioPvblw0vCDNiXveK3Yh8dTSnNpe?= =?us-ascii?Q?KmneLsVALrL9mjqYjbsRmYWTNJwOVsvqDylL6A33IJY+lH5ASAHlMQ2ZlCrD?= =?us-ascii?Q?Nh/XSwn1wnHTDpO596tWm5SSqXga7vhSqslhmn5QY8wBuPXb7YDDgRDf6/9y?= =?us-ascii?Q?LRsaneQMON8tMzD7/g0djwiTKjQMgOyf6Yi9Q8lV5Ooqv3qEEagyxh4JNjBD?= =?us-ascii?Q?bC4/5NEy5CEbURvISMSiqQ0LXI+RvqrTP3gaUQCl5iv5BxFb2qltwzCiUG7U?= =?us-ascii?Q?WAkE7gOstwaxhpAq+6sRrd4qoZGJJy5x1tA/TknYaOcYx+jjUajOJensa9ag?= =?us-ascii?Q?5L8noxZpl0BLRH9ReOiY0WeLkw2JRMcoEx3Nz7OCutaiFyd/uoXCiKeR5OjZ?= =?us-ascii?Q?ZiITk7oveyfEWywGZryGpt/7zvaGA+kw5Qxq7R0bvfesDvAUUiVW/mebZkBX?= =?us-ascii?Q?7hi+wNUzM6ZDTs2niN7YEo17jqScwua6W4+KcW4X5fuD4JBn5X986GzY8Mys?= =?us-ascii?Q?G/8hzeUdNagY3BUnVr4KgxjTSM0xtxPZj2GZvmobihQWPf43cklxVETsvTPm?= =?us-ascii?Q?MgqqS2WFOEqZF5N5D7Jk7mseV7CeGKYObLAP6x7FqyaYpvRj9htDYFmm0Be/?= =?us-ascii?Q?dVFcjHdeWhjytT50Th9JWYofN/6BxTSFJddnWMIQQZ37hNXhOMkWt6nHDkqB?= =?us-ascii?Q?6YOiJXlFXU/2v+vFiAHGG5oC0hiSY9+y8kUD5QnboWXbIS4h98cFM0vKgESR?= =?us-ascii?Q?XykiAHFUmsvw1RqQYdLCVStWVqPKtQ0vR2ed4u5KdiP9Dr04V0v0IPD9Vf2n?= =?us-ascii?Q?OA9UOJbmATz7QbEENeW+7SQKtBFMc0i6C7tTk6BJHHaUI8E7Pz85mOT7bcL9?= =?us-ascii?Q?dBCmTXn4VX7E2pIbQjlD1WuyLLaLZorPI8taAHnOHc1oS7OvJoAylJoUdQwp?= =?us-ascii?Q?QP5T32K9CyhYpahzgvpCwSpDoMCGgIjuWw3DRdDcSEgE/taSDKWqwTaKJfEI?= =?us-ascii?Q?odFNAEzzpFIokJNhnz5Umb2XYUnF8kxfrVB38axpb71vqMJ7UPD+8CZZ+4Wm?= =?us-ascii?Q?feMeIqhUEk4lFBYrd5itHNePFbwPZFpL7OOzzlBu1389D0cQfjHO8JqVo6CX?= =?us-ascii?Q?JdpwNJM1O5dx9hmQkdhl8U4APQUDN6Pgw5ao6RytAk7aRJB9L519v5/SB/Bc?= =?us-ascii?Q?IcpoNXAIAV0sG5Dn77dGAKk/bbd1wdmoyjymAtM6kIbNpPRxQRkZO/JUelGw?= X-MS-Exchange-AntiSpam-MessageData-1: bhAhowBSYrmGQw== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 90c20f3a-7a79-410d-581c-08df0fe966ca X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:45:23.7274 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Js7e6g66q9qSMQFZzwasSZPeJPZ4DhJuWz9YOSe2YxLjqjO6E/9QkyoY2kolqP+Nic89CXnPcMQNsdieXpvYBQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB5003 X-purgate-ID: tlsNG-4011c0/1789119929-53CD3CFC-2D6CEE2C/0/0 X-purgate-type: clean X-purgate-size: 12263 Hello, This patch series integrates CPU topology discovery into the Xen hypervisor for both ACPI and Device Tree platforms. Changes in v10: - Postpone the invocation of init_cpu_topology() until after nr_cpu_ids is finalized. - Improve the Device Tree cpu-map node parsing logic: * Rename functions and variables to accurately reflect the DT nodes being processed. * Simplify the parsing algorithm by eliminating recursive calls and avoiding passing INVALID_TOPO_ID as an argument. - Unify all license headers to GPL-2.0-only. - Return an error instead of triggering an ASSERT() when duplicate CPU definitions are detected. - Replace BUG_ON() with ASSERT() for condition checks in dt_init_cpu_topology(). - Update commit messages to remove details that no longer match the current implementation. Changes in v9: - Add bounds checking for the number of private resources in the PPTT processor table. - Verify the validity of entries when indexing into the map_cpu_acpiid table. - Coding style adjustments (following Xen standards): * Place logical operators ('||', '&&') at the end of lines when splitting multi-line conditions. * Place arithmetic operators ('+', '-') at the end of lines when wrapping long assignment statements. * Enclose bitwise operations in parentheses within conditional expressions that combine logical operators. * Combine variable declaration and initialization where applicable. Changes in v8: - PPTT Table Validation & Hardening: * Relaxed processor node length check to allow proc->header.length >= table_size. * Treated root nodes (nodes with parent == 0) as equivalent to ACPI_PPTT_PHYSICAL_PACKAGE nodes. - Build & Kconfig Adjustments: * Removed leftovers of ACPI_CPU_TOPOLOGY definition from xen/drivers/acpi/Kconfig. - Code Cleanups & Style Conformance: * Moved INVALID_ACPIID definition to xen/acpi.h to make it available cross-architecture. * Removed ARM-specific references from comments in architecture-agnostic code. * Added explicit parentheses around bitwise operations in logical expressions. * Placed binary logical operators (||, &&) at the end of lines when splitting conditional statements. * Combined variable declarations and initializations where appropriate. * Removed trailing full stops ('.') from printk log messages. * Fixed printk format specifier mix-up. * Explicitly included in xen/common/cpu.c. Changes in v7: - PPTT Table Validation & Hardening: * find_pptt_node(): Added leaf node verification (ACPI 6.3+). * acpi_init_cpu_topology(): Added bounds checks to ensure proc->parent validly references memory strictly inside the PPTT table bounds. * Factored out shared table checking helper functions used by both find_pptt_node() and acpi_init_cpu_topology(). * Added subtable alignment checks and strengthened processor structure size validation. - Graceful Fallback & Allocation: * Treated missing topology definitions as benign conditions. * Used xvzalloc_array() for temporary memory allocations during initialization. - Build & Kconfig Adjustments: * Updated Kconfig to use "depends on UNSUPPORTED" instead of "if UNSUPPORTED". - Code Cleanups & Style Conformance: * Used designated initializers for structure data initializations. * Consolidated topology helpers with IS_ENABLED(). * Removed redundant error checks and reduced unnecessary pointer casts. * Switched type-based sizeof(type) to variable-based sizeof(*var). * Added leading spaces before labels ( out:) Changes in v6: - Renamed the series subject from "xen/arm: Device Tree based CPU topology support" to reflect the inclusion of generic ACPI PPTT topology parsing. - Infrastructure & Kconfig: * Updated Kconfig to make both DT_CPU_TOPOLOGY and ACPI_CPU_TOPOLOGY select GENERIC_CPU_TOPOLOGY. * Ensured that if topology parsing from either DT or ACPI PPTT fails, the CPU topology table is freed to fall back to the non-topology behavior. * Moved the `cpu_topology` definition to `cpu.c` so that variables and functions in `cpu-topology.c` can be completely freed after Xen init. - Topology Logic (DT / ACPI): * Set the cluster ID to 0 when the cluster definition is missing from the Device Tree `cpu-map` node. * Handled cases where cluster info is missing upon reaching a physical package in the PPTT parser by assuming one cluster per socket. * Split out the import of ACPI PPTT definitions from the Linux kernel (including unused definitions) into a separate standalone patch. - Robustness & Safety: * Avoided assuming `np` becomes NULL after exiting `dt_for_each_child_node()`; explicitly return NULL instead. * Added bounds-checking `ASSERT`s for values returned by `cpumask_first()`. * Added explicit braces `{}` to nested `if` statements to clarify `else` scoping and maintain style symmetry. * Enforced an upper limit on the PPTT parsing loop iterations to prevent infinite loops on corrupted tables. * Treat the absence of a physical package node definition in PPTT as a parsing error. - Optimization & Efficiency: * Optimized `setup_siblings_masks()` to eliminate redundant loop iterations. * Dynamically allocate the temporary data storage used during ACPI PPTT parsing. - Code Cleanup & Refactoring: * Replaced the `invalid_topo_id` constant with the `INVALID_TOPO_ID` macro. * Initialized all members of the `cpu_map` array with `INVALID_TOPO_ID`. * Added a blank line between `` and `` header groups. * Reordered `#ifdef` blocks to prioritize generic logic over architecture- specific ones. * Corrected code indentation. * Applied the `static` specifier to file-local data structures and functions. * Minimized the use of fixed-width `uint32_t` types, restricting its use only where strictly required by the 32-bit ACPI ID specification. * Declared `map_cpu_acpiid[]` as static and introduced the helper function `acpi_map_cpu_acpiid()` for managed access. * Renamed local variables to more intuitive names. * Simplified the implementation of `get_logical_id()`. * Refactored PPTT parsing to reduce type casting by using `container_of()` and switching from `char *` to `void *` pointers. * Removed redundant error checks. * Cleaned up unused variables and eliminated debug print statements. Changes in v5: - Extracted CPU topology information from the ACPI PPTT. - Corrected the erroneous use of CONFIG_CPU_TOPOLOGY to CONFIG_GENERIC_CPU_TOPOLOGY. Changes in v4: - Only display the CPU topology configuration prompt in common/Kconfig if the architecture defines HAS_GENERIC_CPU_TOPOLOGY. - Move the definition of the global 'cpu_topology' pointer to common/cpu-topology.c. - Update the Makefile to explicitly build objects as .init.o when all functions and data within a file are annotated with __init/__initdata, ensuring their memory is reclaimed after system initialization. - Add an error log in the CPU-to-node mapping function for out-of-bounds cases. - Use ARRAY_SIZE() instead of raw macros when guarding array accesses. - Rename variables and functions to avoid ambiguous or misleading terms: - Avoid 'cpuid' to prevent confusion with x86 CPUID features/instructions. - Avoid 'node' where it could be confused with a NUMA node, explicitly renaming them to clarify they refer to a Device Tree node. - Move local variable declarations into the narrowest possible scope. - Replace the unsupported "%pOF" printk format specifier with "%s" and explicit node name retrieval. - Remove #include from cpu-topology.h, and ensure the header directly includes only what its definitions require. - Remove #include from dt-cpu-topology.h, replacing it with a forward declaration of 'struct dt_device_node'. - Use 'const' qualifiers for pointer declarations where the pointed-to structure is not modified. - Explicitly #include in cpu-topology.h to guarantee that arch-specific definitions of cpu_to_core() and cpu_to_socket() take precedence over the generic fallbacks. - Introduce inline initialization functions for cpu_sibling_mask and cpu_core_mask in cpu-topology.h, providing separate variants for both when CONFIG_GENERIC_CPU_TOPOLOGY is enabled and disabled. Changes in v3: - Use (nr_cpu_ids - 1) as the maximum CPU ID here. The fix for the sparse map mismatch issue on ARM Xen has been split out into a separate patch. - Switch topology sibling masks to cpumask_var_t for dynamic allocation. - Allow the system to keep running with a degraded fallback even if the topology table allocation fails. - Remove the temporary definitions of cpu_to_core() and cpu_to_socket() from RISC-V and PPC processor.h. - Minimize the use of #ifdef blocks, leveraging compiler Dead Code Elimination (DCE) where possible. - Clean up the code to follow the Xen coding style. Please let me know if I missed any style nits! - Verify successful builds across x86, RISC-V, and PPC environments. Changes in v2: - Generate topology information even when ACPI is enabled. Note that this is a temporary implementation and doesn't yet parse the PPTT (Processor Properties Topology Table). - Added support for cpu-map node in Device Tree that doesn't contain explicit cluster node definitions. Changes in v1 from the previous series "Introduce Device Tree based NUMA support for ARM Xen": 1. Optimized Memory Allocation: The series now allocates only the minimum required memory area to manage the essential data for the CPUs. 2. Flexible Device Tree Parsing: The parsing logic no longer depends on the definition order of the 'cpu' nodes and 'cpu-map' nodes in the Device Tree. They can now be read correctly even if their orders do not match. 3. CPU Hotplug Readiness: To support future CPU hotplug, the system assumes that inactive CPUs are also described in the Device Tree. Xen will pre-load and generate the topology information for these inactive CPUs during the boot phase so it stays available in memory. Thank you, Hirokazu Takahashi Hirokazu Takahashi (4): xen/device-tree: Parse 'cpu-map' node for CPU topology exploration xen/sched: Link CPU topology to scheduler xen/sched: Make cpu_nr_siblings() architecture-specific xen/acpi: Parse PPTT to initialize CPU topology xen/arch/arm/Kconfig | 1 + xen/arch/arm/acpi/boot.c | 2 + xen/arch/arm/include/asm/processor.h | 4 - xen/arch/arm/setup.c | 3 + xen/arch/arm/smpboot.c | 13 +- xen/arch/ppc/include/asm/processor.h | 4 - xen/arch/riscv/include/asm/processor.h | 4 - xen/arch/x86/include/asm/acpi.h | 2 - xen/arch/x86/include/asm/processor.h | 1 + xen/common/Kconfig | 22 ++ xen/common/Makefile | 1 + xen/common/cpu-topology.c | 62 ++++ xen/common/cpu.c | 5 + xen/common/device-tree/Makefile | 1 + xen/common/device-tree/cpu-topology.c | 412 +++++++++++++++++++++++++ xen/common/sched/credit2.c | 21 +- xen/common/sysctl.c | 1 + xen/drivers/acpi/Makefile | 1 + xen/drivers/acpi/topology.c | 341 ++++++++++++++++++++ xen/include/xen/acpi.h | 17 + xen/include/xen/cpu-topology.h | 76 +++++ xen/include/xen/dt-cpu-topology.h | 35 +++ 22 files changed, 991 insertions(+), 38 deletions(-) create mode 100644 xen/common/cpu-topology.c create mode 100644 xen/common/device-tree/cpu-topology.c create mode 100644 xen/drivers/acpi/topology.c create mode 100644 xen/include/xen/cpu-topology.h create mode 100644 xen/include/xen/dt-cpu-topology.h -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:45:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:45:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416152.1645316 (Exim 4.92) (envelope-from ) id 1x4xpV-0007gv-Rx; Fri, 11 Sep 2026 09:45:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416152.1645316; Fri, 11 Sep 2026 09:45:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xpV-0007go-Mu; Fri, 11 Sep 2026 09:45:57 +0000 Received: by outflank-mailman (input) for mailman id 1416152; Fri, 11 Sep 2026 09:45:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xpU-0007gL-95 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:45:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xpT-00AzpU-Ls for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:45:55 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3cdd2-8faa-0a2a0a5109dd-0a2a450985a0-10 for ; Fri, 11 Sep 2026 11:45:55 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3cdd3-be1a-0a2a45090019-b9ff1c239e05-3 for ; Fri, 11 Sep 2026 11:45:55 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a08fdbf3c0000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 09:45:51 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 2532781BAF; Fri, 11 Sep 2026 11:45:51 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=EEfSzCAbvLllS00o88eaJybHOrGbl1PMmJi+1iERHnQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=HXposf3bmXN/88pfVAEyYKhOB77NOirb8NZa4LiUek+/d9cr/2p9oLxuANzAW1+VumdC3xhwV GkrgiNE7WqKB9HvM7hMduR4yGH96JgxAfcvavJtObS/DIf/B+5ZeWebuiTBMF7HwT7GBUXtrJ0w ZmvGtmbEVB/2/snbTT11OH+FhIaIr5vVx2BaW1iyjlUyBJ1xuv+U1DCzOQDxQydYSZrtnWikr72 CuhFwv2+Zr2CNnwki7zNjH/95f1vtno3/7H2FzPVeswSde7+D8Xje1VG6vD1b1EP1xAV/jb10KU JtPSLr8lknunayUnXHx0yDDabB+naGWjudqozaf5LENg== X-Zone-Loop: 16d4d63a05cbacc8c52bac7aee67794555b5bcfb420c x-campaign-type: default x-transaction-id: ab4cf21d-6da3-4725-9ed9-01c222ab6147 x-swg-uid: 01-9cbcf87e-a18b-4d44-bfce-85f8c980a824 X-Mailer: Sweego Message-ID: <1789119951.8631fc262581453bbf619ec5b2062170.1a08fdbf3c0000c4f3@vates.tech> x-swg-bid: 1789119951.8631fc262581453bbf619ec5b2062170.1a08fdbf3c0000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 11 Sep 2026 11:45:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/7] x86: make UPDATE_ENTRY() allow for multiple operation flags To: Kevin Lampis , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, George Dunlap References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-2-kevin.lampis@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260910203113.462943-2-kevin.lampis@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------SJHzMivFsmVnRN2gUvj0mZe3" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789119951276 X-purgate-ID: tlsNG-bad1c0/1789119955-FC817034-7E32185A/0/0 X-purgate-type: clean X-purgate-size: 8978 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------SJHzMivFsmVnRN2gUvj0mZe3 Content-Type: multipart/mixed; boundary="------------7I3YwTxfAcPSKONF7ikWQgUf"; protected-headers="v1"; hp="clear" Message-ID: <39fc7a86-89f1-4bd3-b569-f41d95257ed6@vates.tech> Date: Fri, 11 Sep 2026 11:45:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/7] x86: make UPDATE_ENTRY() allow for multiple operation flags To: Kevin Lampis , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, George Dunlap References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-2-kevin.lampis@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260910203113.462943-2-kevin.lampis@citrix.com> --------------7I3YwTxfAcPSKONF7ikWQgUf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTAvMDkvMjAyNiDDoCAyMjozMSwgS2V2aW4gTGFtcGlzIGEgw6ljcml0wqA6DQo+IEZy b206IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gDQo+IFNpZ25lZC1vZmYt Ynk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gUmV2aWV3ZWQtYnk6IEdl b3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAY2l0cml4LmNvbT4NCj4gLS0tDQo+IENoYW5n ZXMgaW4gdjI6DQo+IC0gTmV3IHBhdGNoDQo+IC0tLQ0KPiAgIHhlbi9hcmNoL3g4Ni9tbS5j ICAgIHwgNDggKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gICB4ZW4vYXJjaC94ODYvcHYvbW0uaCB8IDEzICsrKysrKystLS0tLQ0KPiAgIDIgZmls ZXMgY2hhbmdlZCwgMzQgaW5zZXJ0aW9ucygrKSwgMjcgZGVsZXRpb25zKC0pDQo+IA0KPiBk aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L21tLmMgYi94ZW4vYXJjaC94ODYvbW0uYw0KPiBp bmRleCBiMTU4NzQyNDA4ZjkuLjVmNzc4NTU3YjFlNiAxMDA2NDQNCj4gLS0tIGEveGVuL2Fy Y2gveDg2L21tLmMNCj4gKysrIGIveGVuL2FyY2gveDg2L21tLmMNCj4gQEAgLTIxNDksMTAg KzIxNDksOSBAQCBzdGF0aWMgdm9pZCBsM3RfdW5sb2NrKHN0cnVjdCBwYWdlX2luZm8gKnBh Z2UpDQo+ICAgDQo+ICAgLyogVXBkYXRlIHRoZSBMMSBlbnRyeSBhdCBwbDFlIHRvIG5ldyB2 YWx1ZSBubDFlLiAqLw0KPiAgIHN0YXRpYyBpbnQgbW9kX2wxX2VudHJ5KGwxX3BnZW50cnlf dCAqcGwxZSwgbDFfcGdlbnRyeV90IG5sMWUsDQo+IC0gICAgICAgICAgICAgICAgICAgICAg ICBtZm5fdCBnbDFtZm4sIHVuc2lnbmVkIGludCBjbWQsDQo+ICsgICAgICAgICAgICAgICAg ICAgICAgICBtZm5fdCBnbDFtZm4sIHVuc2lnbmVkIGludCB1cGRhdGVfZmxhZ3MsDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHZjcHUgKnB0X3ZjcHUsIHN0cnVjdCBk b21haW4gKnBnX2RvbSkNCj4gICB7DQo+IC0gICAgYm9vbCBwcmVzZXJ2ZV9hZCA9IChjbWQg PT0gTU1VX1BUX1VQREFURV9QUkVTRVJWRV9BRCk7DQo+ICAgICAgIGwxX3BnZW50cnlfdCBv bDFlID0gbDFlX3JlYWQocGwxZSk7DQo+ICAgICAgIHN0cnVjdCBkb21haW4gKnB0X2RvbSA9 IHB0X3ZjcHUtPmRvbWFpbjsNCj4gICAgICAgaW50IHJjID0gMDsNCj4gQEAgLTIxNzIsNyAr MjE3MSw3IEBAIHN0YXRpYyBpbnQgbW9kX2wxX2VudHJ5KGwxX3BnZW50cnlfdCAqcGwxZSwg bDFfcGdlbnRyeV90IG5sMWUsDQo+ICAgICAgICAgICB9DQo+ICAgDQo+ICAgICAgICAgICAv KiBUcmFuc2xhdGUgZm9yZWlnbiBndWVzdCBhZGRyZXNzLiAqLw0KPiAtICAgICAgICBpZiAo IGNtZCAhPSBNTVVfUFRfVVBEQVRFX05PX1RSQU5TTEFURSAmJg0KPiArICAgICAgICBpZiAo ICEodXBkYXRlX2ZsYWdzICYgUFRFX1VQREFURV9OT19UUkFOU0xBVEUpICYmDQo+ICAgICAg ICAgICAgICAgIHBhZ2luZ19tb2RlX3RyYW5zbGF0ZShwZ19kb20pICkNCj4gICAgICAgICAg IHsNCj4gICAgICAgICAgICAgICBwMm1fdHlwZV90IHAybXQ7DQoNCiguLi4pDQoNCj4gQEAg LTI0MzUsNyArMjQzNCw3IEBAIHN0YXRpYyBpbnQgbW9kX2w0X2VudHJ5KGw0X3BnZW50cnlf dCAqcGw0ZSwNCj4gICAgICAgZWxzZSBpZiAoIHB2X2wxdGZfY2hlY2tfbDRlKGQsIG5sNGUp ICkNCj4gICAgICAgICAgIHJldHVybiAtRVJFU1RBUlQ7DQo+ICAgICAgIGVsc2UgaWYgKCB1 bmxpa2VseSghVVBEQVRFX0VOVFJZKGw0LCBwbDRlLCBvbDRlLCBubDRlLCBtZm4sIHZjcHUs DQo+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJlc2VydmVfYWQp KSApDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXBkYXRlX2Zs YWdzKSkgKQ0KPiAgICAgICB7DQo+ICAgICAgICAgICByZXR1cm4gLUVGQVVMVDsNCj4gICAg ICAgfQ0KPiBAQCAtNDEzNSwxOCArNDEzNCwyMyBAQCBsb25nIGRvX21tdV91cGRhdGUoDQo+ ICAgDQo+ICAgICAgICAgICAgICAgaWYgKCBwYWdlX2xvY2socGFnZSkgKQ0KPiAgICAgICAg ICAgICAgIHsNCj4gKyAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgdXBkYXRlX2ZsYWdz ID0gKGNtZCA9PSBNTVVfUFRfVVBEQVRFX1BSRVNFUlZFX0FEKQ0KPiArICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/IFBURV9VUERBVEVfUFJFU0VSVkVf QUQNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOiAo Y21kID09IE1NVV9QVF9VUERBVEVfTk9fVFJBTlNMQVRFKQ0KPiArICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gUFRFX1VQREFURV9OT19UUkFOU0xB VEUgOiAwOw0KPiArDQoNCkknbSBub3QgZnVsbHkgY29udmluY2VkIGJ5IHRoZSBkb3VibGUt dGVybmFyeSBvcGVyYXRvciBoZXJlLiBXaGlsZSBpdCdzIA0KYSBiaXQgbW9yZSBjb21wYWN0 LCBJIGRvbid0IGZpbmQgaXQgdmVyeSByZWFkYWJsZSwgSSB3b3VsZCBwcmVmZXIgDQpzb21l dGhpbmcgbGlrZQ0KDQp1bnNpZ25lZCBpbnQgdXBkYXRlX2ZsYWdzID0gMDsNCmlmICggY21k ID09IE1NVV9QVF9VUERBVEVfUFJFU0VSVkVfQUQgKQ0KICAgICB1cGRhdGVfZmxhZ3MgPSBQ VEVfVVBEQVRFX1BSRVNFUlZFX0FEOw0KaWYgKCBjbWQgPT0gTU1VX1BUX1VQREFURV9OT19U UkFOU0xBVEUgKQ0KICAgICB1cGRhdGVfZmxhZ3MgPSBQVEVfVVBEQVRFX05PX1RSQU5TTEFU RTsNCg0KV2hpY2ggaXMgb25lIGxpbmUgbG9uZ2VyLCBidXQgbG9va3MgdG8gbWUgbW9yZSBj bGVhciBvbiB3aGF0IGl0IGRvZXMuDQoNCj4gICAgICAgICAgICAgICAgICAgc3dpdGNoICgg cGFnZS0+dS5pbnVzZS50eXBlX2luZm8gJiBQR1RfdHlwZV9tYXNrICkNCj4gICAgICAgICAg ICAgICAgICAgew0KPiAgICAgICAgICAgICAgICAgICBjYXNlIFBHVF9sMV9wYWdlX3RhYmxl Og0KPiAgICAgICAgICAgICAgICAgICAgICAgcmMgPSBtb2RfbDFfZW50cnkodmEsIGwxZV9m cm9tX2ludHB0ZShyZXEudmFsKSwgbWZuLA0KPiAtICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBjbWQsIHYsIHBnX293bmVyKTsNCj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdXBkYXRlX2ZsYWdzLCB2LCBwZ19vd25lcik7DQo+ICAg ICAgICAgICAgICAgICAgICAgICBicmVhazsNCj4gICANCiguLi4pDQoNClRoZSByZXN0IGxv b2tzIGdvb2QgdG8gbWUgdGhvdWdoLg0KDQpUZWRkeQ0K --------------7I3YwTxfAcPSKONF7ikWQgUf-- --------------SJHzMivFsmVnRN2gUvj0mZe3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqjzc4FAwAAAAAACgkQZg+p0QLLz9CI RQv/QE33vk872PyPc9N/YJvxC0cX5iUxo48u1gsOBf2wgQrBYUcLvRbiO56+Wfoiby56xSAtkFJk hK41Y45OM8/XdbT4OEZsVaug40B5RlOCyy+2Xv34/xB+T7xAIYz1dHvHPgYSE0UEN8tjUz6SdRIs A7EhgyMNcNtdvN7feCyVAuRSlOhzWRlW1PJlHKwtcTj21i3ZG6iiM+1RoKvMf4nelnC3+GB9w5J0 o9XOIu2LOde7hei6PJGG7xhSqAKObDii5vPY6L6WlkJAAoiXqT9q5J93moUvjcLL3SfEmEh/JUoj YRnH+C8po4JmlLRIMcl5aacIvf+RhE5MYKNQlEy+RKh6SHVpho03itlwNnKH9Vx8TjPF96JiLKka EsK8SAdizfJIJ73r9N3AwUELCKNPssnhF4EF8cwGphStBbz6RW5dhrdlfFUqiQluzJIKHKOU3W/Z mAiGimax/zWToIE3FezBW18wrhdM8iSr6Yw2FkbfV1MklJ26AiNePNe3Xjry =wmLW -----END PGP SIGNATURE----- --------------SJHzMivFsmVnRN2gUvj0mZe3-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:46:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:46:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416164.1645323 (Exim 4.92) (envelope-from ) id 1x4xqA-0008KX-1E; Fri, 11 Sep 2026 09:46:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416164.1645323; Fri, 11 Sep 2026 09:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xq9-0008KQ-Uf; Fri, 11 Sep 2026 09:46:37 +0000 Received: by outflank-mailman (input) for mailman id 1416164; Fri, 11 Sep 2026 09:46:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xq8-0008K4-Re for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:46:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xq7-00DZoV-PD for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:46:35 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3cdf2-e002-0a2a0a5209dd-0a2a4504d672-16 for ; Fri, 11 Sep 2026 11:46:35 +0200 Received: from [52.101.125.101] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3cdf8-b57f-0a2a45040019-34657d6558a2-3 for ; Fri, 11 Sep 2026 11:46:35 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TYYP286MB5003.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:14b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 09:46:30 +0000 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:46:30 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ElL7oN1QigY2qGvUKJr4ue7+dyuoZ+F+86sNC2KI23gRzaptSfwH4ZYDXuqPcVc4FVucRO6CIuwvMF2tefhh6H51zxiXJkL9KmPOG+OOmS1ywUBZ1ZQ/bWNynmsi2rvLJtdWGxyg/dXSVpXhbtTdMzUG8V08jbzogNMb3zmqAsrzUJjFOmdyMKnzRKzlfuVuuY2583leJI5aYgTDe0udpBbWnlmvYULjEgbXWpYDEoQZX5Ksbb4KWHjF5J/+R6Q7szcgyJsWFNUUDC9LbUdGped9DcAof3p028vHFgQpGKkNGBSXiAxxKR/TcblMR8PWKs7cPje6U2Uh4muSiQTOGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=98Ejx9hGWuJ2tgdfHUsmj4uLOcuV/PMVq9M0S9wHihk=; b=lWIi2A4EKDWA5JYO+hfORouThDqTKcm1+fBSQkUhUL4fGNTLzgJZfrLZrdYLB6qSXNA4MWKgY1Lz4c4Rm+WermGF8P+GCmQ1u0xZGpWIm/QzEkPd7npBqkaXBBg8HuqQSmOV6m65x9DW6hDbgxLF+PEeZO7ZGqkIKLgR3r1CrW4Nu7klJ6WKjb4MDdHDMyjysSrP9zdJARBeWTV7ckr/nPIhUqgzQGi7Dr00jvdaiNaoVfhaJrVxRChDbSx7b0Y53BGskfaroIMsyXnQhm3wnHfv/0h95T+WUCURayewY9jCaezxQal641fpfjPdvo0p1Nal3HfnDNbNE8TkmMeW9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=98Ejx9hGWuJ2tgdfHUsmj4uLOcuV/PMVq9M0S9wHihk=; b=pUZrFqUbq4mjUtszoFdBD+4Ig7DLKoWVgqH6t+Gqh+cnBbpxkNCWhSRAf4nEJBaDdlcHKTVFBnqZ+SBD0ic5G5rxNE0JUrmcIBAWRx23kVQXpMZqvmFZK5QaQtQta5AmaLivjZLQwLbbC6AkAD3zQJnRvgv/DYhPnMswE/rGWEo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Hirokazu Takahashi To: xen-devel@lists.xenproject.org Cc: michal.orzel@amd.com, Mykyta_Poturai@epam.com, Hirokazu Takahashi , Jan Beulich , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v10 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Date: Fri, 11 Sep 2026 18:42:10 +0900 Message-ID: <20260911094213.79936-2-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260911094213.79936-1-taka@valinux.co.jp> References: <20260911094213.79936-1-taka@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYWPR01CA0049.jpnprd01.prod.outlook.com (2603:1096:400:17f::20) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TYYP286MB5003:EE_ X-MS-Office365-Filtering-Correlation-Id: a9278e18-1c65-4b78-af55-08df0fe98eb1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|1800799024|23010399003|7416014|376014|366016|56012099006|22082099003|18002099003|10067099003|6133799003; X-Microsoft-Antispam-Message-Info: 57Y7wa/bICunFTF7nnEaEFUsQjtFagRcw9ljjRl+h/k25UzRAsuD4bc64BDeODvOFYZAhly5q10IsGg6OYmHEw7UNCJZq6rdoGl4Y0LtGagkZmnqRV2qyZy7gdB9m7/jUAwV3XWGfU90Z1fO/Pamxz0Vk6ZMD96T6tU012QNcMki80qIO1NBPRpyMd8VlCotIUvR5AD9NBf1VMFg5pJm6WndcZyo2KvXORd7qF0l49IKF4HEIgvqTow4l68kVCc5Y61pdETW526lRrOXC5xoYyJKN6tovpGkvTQ4zsiuUmAPpBbhvYGHfB/WV799KxYr6hYTrs2ik20nz23uyuFXtmMF0Oq8A+L3+Ij4Eq6UuJTV9jnxT8zq6HO1VxxhFBFfKVz6X2YApEf1hC03D8zenO4NtMzBfT/lNcnzaP4VF61q461576xBH+K2RXnowCoNLO8tGCppdygOmfWMwEo4gyo11VQUSbfBFGgGH7i6wAMBcBagWww4RUFid2hIHVOXhE7STVpvBaAdv0GtnVc7mGuBv3P30gXtCZ1tJ0zQXxHAeem0yCT05SwZjWm2mSD2xj2As5CloU73bKQYGB0rgg4jw0c5zSxcC1I2FmipzRWOdOuwjaP0dtudmwxOiFdLlepyy2IS5UCICctmN3Xzfwz/M+ovi82G96SO5mNkvYY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(23010399003)(7416014)(376014)(366016)(56012099006)(22082099003)(18002099003)(10067099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?jlCsbeB1dzopRR/eh7vO8dNbHqPeiGSzJ5mpToduUSDQsb0rZsv2VUGl2bUe?= =?us-ascii?Q?DJi1XX2zjdyGiBYDatXN1voU8rTE8khrYFT1WQCvPjTNRpnXW1XzhAUWn9/n?= =?us-ascii?Q?koZkueFlOUJitTAljTHM1ArvTHPnOuKTz1EzgduftDWco2vogbyP0b+WtmUP?= =?us-ascii?Q?zjRYsUIkJyCkS1sE5Tct1K+0fpoF034R63l7vjl320PXwBpHoaSFU8Qh+D7E?= =?us-ascii?Q?DuAuaaqi28bITxpYjllXJ6TI4RP/nTBNkz6G14ZbSDS3M35ljo2qR5vBLC2q?= =?us-ascii?Q?sEPMZFtUe9LROn1SyC/O3/RQM8EAvwNwGfnOBFIM6le22w13IIRC7y3dEGoL?= =?us-ascii?Q?C/tWkHiAmfn8J/V9wT1uLpgCauW+j7Nz1B1LumXGLr91OYzaEke+C2oddY7e?= =?us-ascii?Q?YCbqELGI6GIetGq+Fm5CYf/RtvfguAwv3E0AXgmL7rdh+Ct+m5GDz+O0Bk6/?= =?us-ascii?Q?tpD/iolJACdbK6+iCBK6GwaH1ZPMUryf7IgUoMqc6I0WVPoDrUb+q2pk3Wt9?= =?us-ascii?Q?xOdeTBDrSErrbFIrgDjHryy6cSsuLTSoNaxUGpborWKliUW+ngOp3idob5Rc?= =?us-ascii?Q?fMjvOobeZZg/Ppbh2BTw77VR4v/sI5+mbxbdUJvnGH9ZWpZNA5lPOz55p/bv?= =?us-ascii?Q?4jDMS5jDwuJF48sicmYthcumQdawINCSok8dO/uYMJI9pjseAWo+DKZCk1JI?= =?us-ascii?Q?UTbDp9VVTovY0JW1hxoWUjDko1cZmmvNsWyd0FK1BEALuoH4I5nPWXX10fZA?= =?us-ascii?Q?p5G+7YaexRdig4u2Qh/gZw4IzcFRrbGqjviKDVRnPSAPggWntRe20E7KdnoC?= =?us-ascii?Q?w+xrENWbksQaWnIm1bwpLSzACjFrwSos1xi45eGiMHQvScZe9lf+l+fJuCav?= =?us-ascii?Q?NLIQKdA9EyXYSxLslnFMytbjh6ujOtsGtWB+kgP7kMh3qquiZma+ObXTLPRq?= =?us-ascii?Q?y8VC8AdEB0y9H2e4x+rkz4Sl0Y3OYuiFnPdPJLe9tFQIvAt9eImU48rk7Rox?= =?us-ascii?Q?jDBkG7Lz6LH8Wh97MTdNP09ihFKaqitZ6VPhu0kvodQLEDUV7lc2K3hNsLP2?= =?us-ascii?Q?YmLNanGwcJsgc7xV8bvuwntVKrehQgBkbHTBc50D9ULQTAu+dEwkSHIKRuIz?= =?us-ascii?Q?mqzx6dItfe0S1sA017rhc8lL6NRFQjM1A6IPaRBzif4RwB14YHigYAP9akU6?= =?us-ascii?Q?UqqYdadgrVQ/kKQfQefdvFPQKbciGbameEGzZJykWYYTLtREnoKIYMJ/HoL/?= =?us-ascii?Q?EU8az24C9wna6ELuZZSUELkwKthZ958udiwIKxNiRa6fw5v9xc4eaVI+Exfd?= =?us-ascii?Q?HhUck+YJFUaCxY7fAkDqWK2wKPV006aOHwULyRDxCnsL3iW2reJxUzG5p1lF?= =?us-ascii?Q?83OFwUM1keWhmxnNOI1+4VHsOrwgDs7MR0uY5Hjzay1DrQ2CJXqqO3SV99I1?= =?us-ascii?Q?47l1jZr1yGZyFp0VzI9wERDeCyTZbGoFk9XQBBWYAFpEitDfOssa+Jf6EqNX?= =?us-ascii?Q?mYwUU/8GFG2fnljS/EsTTxjsiQgyR+lOFmTaCGcnRukKquago05M7sH2yPfx?= =?us-ascii?Q?vJRL+HJjjK5K4JET1uhh6eGSpIn3gYXQV0QHWfeteCafTE7pTZLuW1LpF3N3?= =?us-ascii?Q?ohVZFFiLzYP4icwsklrcd5hCz1ESg2ZfescnsC6rp5PQBy7u1C6Hbk4dZJY9?= =?us-ascii?Q?NSXbWegcczmUraukddzFzJQmnrRjg5AHCno6Zq09CtPFV2mIEqnl1w0c1vbb?= =?us-ascii?Q?zJys3QLZoZYuouTwDn4DkB3hvrLSGApM29C1HCMRsVoJFn34ceJgQSmwtrmp?= X-MS-Exchange-AntiSpam-MessageData-1: bqyDaIL2eqUv/Q== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: a9278e18-1c65-4b78-af55-08df0fe98eb1 X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:46:30.7039 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iQv9AkxHzqsDHq7boSbM99xtBMtQQlIzHJUEGCDUJnV/BMFJ7rbcQHXROHl7zxwj3yXceDgAkiXNW3u/LRDmiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB5003 X-purgate-ID: tlsNG-ebf023/1789119995-C22D4B50-2AE1035F/0/0 X-purgate-type: clean X-purgate-size: 22213 Parse the 'cpu-map' node in the Device Tree to extract CPU topology information. If the 'cpu-map' node is absent, simply ignore it. Signed-off-by: Hirokazu Takahashi Reviewed-by: Jan Beulich # common, acpi --- Changes in v10: - Postpone the invocation of init_cpu_topology() until after nr_cpu_ids is finalized. - Improve the Device Tree cpu-map node parsing logic: * Rename functions and variables to accurately reflect the DT nodes being processed. * Simplify the parsing algorithm by eliminating recursive calls and avoiding passing INVALID_TOPO_ID as an argument. - Unify all license headers to GPL-2.0-only. - Return an error instead of triggering an ASSERT() when duplicate CPU definitions are detected. - Replace BUG_ON() with ASSERT() for condition checks in dt_init_cpu_topology(). - Update commit messages to remove details that no longer match the current implementation. xen/arch/arm/Kconfig | 1 + xen/arch/arm/setup.c | 3 + xen/arch/arm/smpboot.c | 5 + xen/common/Kconfig | 22 ++ xen/common/Makefile | 1 + xen/common/cpu-topology.c | 62 +++++ xen/common/cpu.c | 5 + xen/common/device-tree/Makefile | 1 + xen/common/device-tree/cpu-topology.c | 347 ++++++++++++++++++++++++++ xen/drivers/acpi/Makefile | 1 + xen/drivers/acpi/topology.c | 41 +++ xen/include/xen/acpi.h | 13 + xen/include/xen/cpu-topology.h | 34 +++ xen/include/xen/dt-cpu-topology.h | 35 +++ 14 files changed, 571 insertions(+) create mode 100644 xen/common/cpu-topology.c create mode 100644 xen/common/device-tree/cpu-topology.c create mode 100644 xen/drivers/acpi/topology.c create mode 100644 xen/include/xen/cpu-topology.h create mode 100644 xen/include/xen/dt-cpu-topology.h diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 843a43897e..1e0fd4957e 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -19,6 +19,7 @@ config ARM select HAS_ALTERNATIVE if HAS_VMAP select HAS_DEVICE_TREE_DISCOVERY select HAS_DOM0LESS + select HAS_GENERIC_CPU_TOPOLOGY select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE select HAS_STACK_PROTECTOR select HAS_STATIC_MEMORY diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 86532d0a35..108f1c703e 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -10,6 +10,7 @@ #include #include +#include #include #include #include @@ -387,6 +388,8 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) nr_cpu_ids = smp_get_max_cpus(); printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", nr_cpu_ids); + init_cpu_topology(); + /* * Some errata relies on SMCCC version which is detected by psci_init() * (called from smp_init_cpus()). diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 1806c47a08..904130efdf 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -9,10 +9,12 @@ #include #include +#include #include #include #include #include +#include #include #include #include @@ -244,6 +246,9 @@ static void __init dt_smp_init_cpus(void) } else tmp_map[i] = hwid; + + /* Pass the info to dt_init_cpu_topology() */ + map_cpu_to_dt_node(i, cpu); } if ( !bootcpu_valid ) diff --git a/xen/common/Kconfig b/xen/common/Kconfig index da80fdba84..29879a9131 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -140,6 +140,9 @@ config HAS_EX_TABLE config HAS_FAST_MULTIPLY bool +config HAS_GENERIC_CPU_TOPOLOGY + bool + config HAS_IOPORTS bool @@ -191,6 +194,25 @@ config VM_EVENT config NEEDS_LIBELF bool +config GENERIC_CPU_TOPOLOGY + bool + +config DT_CPU_TOPOLOGY + bool "Device tree based CPU topology support (UNSUPPORTED)" + depends on HAS_GENERIC_CPU_TOPOLOGY && DEVICE_TREE_PARSE && UNSUPPORTED + select GENERIC_CPU_TOPOLOGY + help + Retrieve CPU topology information from the device tree to optimize + vCPU scheduling. + +config ACPI_CPU_TOPOLOGY + bool "ACPI based CPU topology support (UNSUPPORTED)" + depends on HAS_GENERIC_CPU_TOPOLOGY && ACPI && UNSUPPORTED + select GENERIC_CPU_TOPOLOGY + help + Retrieve CPU topology information from the ACPI PPTT to optimize + vCPU scheduling. + config NUMA bool diff --git a/xen/common/Makefile b/xen/common/Makefile index 6018e25614..901bb37925 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_GENERIC_BUG_FRAME) += bug.o obj-$(CONFIG_HYPFS_CONFIG) += config_data.o obj-$(CONFIG_CORE_PARKING) += core_parking.o obj-y += cpu.o +obj-$(CONFIG_GENERIC_CPU_TOPOLOGY) += cpu-topology.init.o obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o diff --git a/xen/common/cpu-topology.c b/xen/common/cpu-topology.c new file mode 100644 index 0000000000..f784afbd3d --- /dev/null +++ b/xen/common/cpu-topology.c @@ -0,0 +1,62 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include +#include +#include + +static void __init free_topology_table(void) +{ + unsigned int cpu; + + for ( cpu = 0; cpu < nr_cpu_ids; cpu++ ) + { + free_cpumask_var(cpu_topology[cpu].thread_sibling); + free_cpumask_var(cpu_topology[cpu].core_sibling); + free_cpumask_var(cpu_topology[cpu].cluster_sibling); + } + + XVFREE(cpu_topology); +} + +void __init init_cpu_topology(void) +{ + unsigned int cpu; + int ret; + + cpu_topology = xvzalloc_array(struct cpu_topology, nr_cpu_ids); + if ( !cpu_topology ) + return; + + for ( cpu = 0; cpu < nr_cpu_ids; cpu++ ) + { + if ( !zalloc_cpumask_var(&cpu_topology[cpu].thread_sibling) || + !zalloc_cpumask_var(&cpu_topology[cpu].core_sibling) || + !zalloc_cpumask_var(&cpu_topology[cpu].cluster_sibling) ) + { + free_topology_table(); + return; + } + } + + if ( acpi_disabled ) + ret = dt_init_cpu_topology(); + else + ret = acpi_init_cpu_topology(); + + /* Free the CPU topology table if initialization fails. */ + if ( ret != 0 ) + free_topology_table(); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/common/cpu.c b/xen/common/cpu.c index f09af0444b..9591ada60a 100644 --- a/xen/common/cpu.c +++ b/xen/common/cpu.c @@ -1,5 +1,6 @@ #include #include +#include #include #include #include @@ -46,6 +47,10 @@ const unsigned long cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)] = { #undef MASK_DECLARE_2 #undef MASK_DECLARE_1 +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY +struct cpu_topology *__ro_after_init cpu_topology; +#endif /* CONFIG_GENERIC_CPU_TOPOLOGY */ + static DEFINE_RWLOCK(cpu_add_remove_lock); bool get_cpu_maps(void) diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile index 9036e455d6..6ee670b5f4 100644 --- a/xen/common/device-tree/Makefile +++ b/xen/common/device-tree/Makefile @@ -1,6 +1,7 @@ obj-y += bootfdt.init.o obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo-fdt.init.o obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo.init.o +obj-$(CONFIG_DT_CPU_TOPOLOGY) += cpu-topology.init.o obj-y += device-tree.o obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o diff --git a/xen/common/device-tree/cpu-topology.c b/xen/common/device-tree/cpu-topology.c new file mode 100644 index 0000000000..ce9da0bb36 --- /dev/null +++ b/xen/common/device-tree/cpu-topology.c @@ -0,0 +1,347 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Derived from Linux kernel 7.0's $drivers/base/arch_topology.c + * Parse cpu topology information. + */ + +#include +#include +#include +#include +#include +#include + +#define INVALID_TOPO_ID (~0U) + +struct cpu_map { + unsigned int thread_id; + unsigned int core_id; + unsigned int cluster_id; + unsigned int socket_id; +}; + +static struct cpu_map __initdata cpu_map[NR_CPUS] = { + [0 ... NR_CPUS - 1] = { + .thread_id = INVALID_TOPO_ID, + .core_id = INVALID_TOPO_ID, + .cluster_id = INVALID_TOPO_ID, + .socket_id = INVALID_TOPO_ID, + }, +}; +static struct dt_device_node *__initdata dt_cpu_table[NR_CPUS]; + +static void __init setup_siblings_masks(unsigned int target_cpu) +{ + const struct cpu_topology *target_topo = &cpu_topology[target_cpu]; + const struct cpu_map *target_map = &cpu_map[target_cpu]; + unsigned int cpu; + + /* Update cluster, core and thread sibling masks */ + for_each_possible_cpu(cpu) + { + const struct cpu_topology *cpu_topo = &cpu_topology[cpu]; + const struct cpu_map *map = &cpu_map[cpu]; + + if ( target_cpu > cpu ) + continue; + + if ( target_map->socket_id != map->socket_id ) + continue; + + cpumask_set_cpu(target_cpu, cpu_topo->core_sibling); + cpumask_set_cpu(cpu, target_topo->core_sibling); + + if ( target_map->cluster_id != map->cluster_id ) + continue; + + cpumask_set_cpu(target_cpu, cpu_topo->cluster_sibling); + cpumask_set_cpu(cpu, target_topo->cluster_sibling); + + if ( target_map->core_id != map->core_id ) + continue; + + cpumask_set_cpu(target_cpu, cpu_topo->thread_sibling); + cpumask_set_cpu(cpu, target_topo->thread_sibling); + } +} + +static const struct dt_device_node *__init dt_find_child_node_by_name( + const struct dt_device_node *dt, + const char *name) +{ + const struct dt_device_node *np; + + dt_for_each_child_node(dt, np) + if ( np->name && (dt_node_cmp(np->name, name) == 0) ) + return np; + + return NULL; +} + +void __init map_cpu_to_dt_node(unsigned int cpu, + struct dt_device_node *cpu_node) +{ + if ( cpu < ARRAY_SIZE(dt_cpu_table) ) + dt_cpu_table[cpu] = cpu_node; + else + printk(XENLOG_WARNING + "cpu %u exceeds the max cpus %zu\n", + cpu, ARRAY_SIZE(dt_cpu_table)); +} + +static unsigned int __init cpu_node_to_id( + const struct dt_device_node *cpu_node) +{ + unsigned int cpu; + + for_each_possible_cpu(cpu) + if ( cpu_node == dt_cpu_table[cpu] ) + return cpu; + + return INVALID_TOPO_ID; +} + +/* + * This function returns the Xen cpu number of the DT node. + */ +static unsigned int __init get_cpu_for_node( + const struct dt_device_node *dt_node) +{ + const struct dt_device_node *cpu_node = + dt_parse_phandle(dt_node, "cpu", 0); + + if ( !cpu_node ) + return INVALID_TOPO_ID; + + return cpu_node_to_id(cpu_node); +} + +static bool __init is_cpu_map_empty( unsigned int cpu ) +{ + return (cpu_map[cpu].socket_id == INVALID_TOPO_ID) && + (cpu_map[cpu].cluster_id == INVALID_TOPO_ID) && + (cpu_map[cpu].core_id == INVALID_TOPO_ID) && + (cpu_map[cpu].thread_id == INVALID_TOPO_ID); +} + +static int __init parse_core(const struct dt_device_node *core, + unsigned int socket_id, + unsigned int cluster_id, + unsigned int core_id) +{ + bool leaf = true; + unsigned int thread_id; + unsigned int cpu; + + for ( thread_id = 0; ; thread_id++ ) + { + const struct dt_device_node *thread; + char name[20]; + + snprintf(name, sizeof(name), "thread%u", thread_id); + thread = dt_find_child_node_by_name(core, name); + + if ( !thread ) + break; + + leaf = false; + cpu = get_cpu_for_node(thread); + + if ( cpu == INVALID_TOPO_ID ) + { + printk(XENLOG_ERR + "ERROR: %s: Can't get CPU for thread\n", dt_node_name(thread)); + return -EINVAL; + } + + if ( !is_cpu_map_empty(cpu) ) + { + printk(XENLOG_ERR + "ERROR: Duplicate CPU definition for CPU%u\n", cpu); + return -EINVAL; + } + + cpu_map[cpu].socket_id = socket_id; + cpu_map[cpu].cluster_id = cluster_id; + cpu_map[cpu].core_id = core_id; + cpu_map[cpu].thread_id = thread_id; + } + + cpu = get_cpu_for_node(core); + + if ( cpu != INVALID_TOPO_ID ) + { + if ( !leaf ) + { + printk(XENLOG_ERR "ERROR: %s: Core has both threads and CPU\n", + dt_node_name(core)); + return -EINVAL; + } + + if ( !is_cpu_map_empty(cpu) ) + { + printk(XENLOG_ERR + "ERROR: Duplicate CPU definition for CPU%u\n", cpu); + return -EINVAL; + } + + cpu_map[cpu].socket_id = socket_id; + cpu_map[cpu].cluster_id = cluster_id; + cpu_map[cpu].core_id = core_id; + cpu_map[cpu].thread_id = 0; + } + else if ( leaf ) + { + printk(XENLOG_ERR + "ERROR: %s: Can't get CPU for leaf core\n", dt_node_name(core)); + return -EINVAL; + } + + return 0; +} + +static int __init parse_cluster(const struct dt_device_node *cluster, + unsigned int socket_id, + unsigned int cluster_id) +{ + bool has_cores = false; + int ret = 0; + + if ( dt_find_child_node_by_name(cluster, "cluster0") ) + { + printk(XENLOG_WARNING + "WARNING: Topology for clusters of clusters not yet supported\n"); + return -EINVAL; + } + + for ( unsigned int core_id = 0; ; core_id++ ) + { + const struct dt_device_node *core; + char name[20]; + + snprintf(name, sizeof(name), "core%u", core_id); + core = dt_find_child_node_by_name(cluster, name); + + if ( !core ) + break; + + has_cores = true; + + ret = parse_core(core, socket_id, cluster_id, core_id); + if ( ret != 0 ) + return ret; + } + + if ( !has_cores ) + printk(XENLOG_WARNING "WARNING: %s: empty cluster\n", + dt_node_name(cluster)); + + return ret; +} + +static int __init parse_socket(const struct dt_device_node *socket, + unsigned int socket_id) +{ + bool has_cluster = false; + int ret = 0; + + for ( unsigned int cluster_id = 0; ; cluster_id++ ) + { + const struct dt_device_node *cluster; + char name[20]; + + snprintf(name, sizeof(name), "cluster%u", cluster_id); + cluster = dt_find_child_node_by_name(socket, name); + + if ( !cluster ) + break; + + has_cluster = true; + ret = parse_cluster(cluster, socket_id, cluster_id); + if ( ret != 0 ) + return ret; + } + + /* + * If no cluster node is defined, assume the socket has + * a single cluster. + */ + if ( !has_cluster ) + ret = parse_cluster(socket, socket_id, 0); + + return ret; +} + +static int __init parse_package(const struct dt_device_node *package) +{ + bool has_socket = false; + int ret = 0; + + for ( unsigned int socket_id = 0; ; socket_id++ ) + { + const struct dt_device_node *socket; + char name[20]; + + snprintf(name, sizeof(name), "socket%u", socket_id); + socket = dt_find_child_node_by_name(package, name); + + if ( !socket ) + break; + + has_socket = true; + ret = parse_socket(socket, socket_id); + if ( ret != 0 ) + return ret; + } + + /* + * If no socket node is defined, assume all clusters reside under + * a single socket. + */ + if ( !has_socket ) + ret = parse_socket(package, 0); + + return ret; +} + +static int __init parse_dt_topology(void) +{ + const struct dt_device_node *cpus; + const struct dt_device_node *map; + + cpus = dt_find_node_by_path("/cpus"); + if ( !cpus ) + return -ENOENT; + + map = dt_find_child_node_by_name(cpus, "cpu-map"); + if ( !map ) + return -ENOENT; + + return parse_package(map); +} + +int __init dt_init_cpu_topology(void) +{ + unsigned int cpu; + int ret; + + ASSERT(acpi_disabled); + ASSERT(cpu_topology); + + ret = parse_dt_topology(); + if ( ret == 0 ) + for_each_possible_cpu(cpu) + setup_siblings_masks(cpu); + + return ret; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile index 477408afbe..6d676e91d4 100644 --- a/xen/drivers/acpi/Makefile +++ b/xen/drivers/acpi/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_ACPI_NUMA) += numa.o obj-y += osl.o obj-$(CONFIG_PM_STATS) += pmstat.o obj-$(CONFIG_PM_OP) += pm-op.o +obj-$(CONFIG_ACPI_CPU_TOPOLOGY) += topology.init.o obj-$(CONFIG_X86) += hwregs.o obj-$(CONFIG_X86) += reboot.o diff --git a/xen/drivers/acpi/topology.c b/xen/drivers/acpi/topology.c new file mode 100644 index 0000000000..090c793f33 --- /dev/null +++ b/xen/drivers/acpi/topology.c @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include + +/* + * TODO: Populate the topology information by scanning the ACPI + * PPTT (Processor Properties Topology Table). + */ +int __init acpi_init_cpu_topology(void) +{ + unsigned int cpu; + + /* + * Generate temporary cpu topology information for now. + * It assumes that the cpu doesn't have SMT and all CPUs + * belong to the same socket. + */ + for_each_possible_cpu(cpu) + { + struct cpu_topology *topo = &cpu_topology[cpu]; + + cpumask_set_cpu(cpu, topo->thread_sibling); + cpumask_copy(topo->core_sibling, &cpu_possible_map); + cpumask_copy(topo->cluster_sibling, &cpu_possible_map); + } + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h index 2fdf38cf74..cbb02e0f35 100644 --- a/xen/include/xen/acpi.h +++ b/xen/include/xen/acpi.h @@ -135,6 +135,19 @@ static inline int acpi_boot_table_init(void) #endif /*!CONFIG_ACPI*/ +#ifdef CONFIG_ACPI_CPU_TOPOLOGY + +int acpi_init_cpu_topology(void); + +#else /* CONFIG_ACPI_CPU_TOPOLOGY */ + +static inline int acpi_init_cpu_topology(void) +{ + return -EOPNOTSUPP; +} + +#endif /* CONFIG_ACPI_CPU_TOPOLOGY */ + int get_cpu_id(u32 acpi_id); unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low); diff --git a/xen/include/xen/cpu-topology.h b/xen/include/xen/cpu-topology.h new file mode 100644 index 0000000000..7cfe3752cd --- /dev/null +++ b/xen/include/xen/cpu-topology.h @@ -0,0 +1,34 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef XEN_CPU_TOPOLOGY_H +#define XEN_CPU_TOPOLOGY_H + +#include + +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY + +struct cpu_topology { + cpumask_var_t thread_sibling; + cpumask_var_t core_sibling; + cpumask_var_t cluster_sibling; +}; + +extern struct cpu_topology *cpu_topology; +void init_cpu_topology(void); + +#else /* CONFIG_GENERIC_CPU_TOPOLOGY */ + +static inline void init_cpu_topology(void) {} + +#endif /* CONFIG_GENERIC_CPU_TOPOLOGY */ + +#endif /* XEN_CPU_TOPOLOGY_H */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/xen/dt-cpu-topology.h b/xen/include/xen/dt-cpu-topology.h new file mode 100644 index 0000000000..72b35b3cf2 --- /dev/null +++ b/xen/include/xen/dt-cpu-topology.h @@ -0,0 +1,35 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef XEN_DT_CPU_TOPOLOGY_H +#define XEN_DT_CPU_TOPOLOGY_H + +#include + +struct dt_device_node; + +#ifdef CONFIG_DT_CPU_TOPOLOGY + +void map_cpu_to_dt_node(unsigned int cpu, struct dt_device_node *cpu_node); +int dt_init_cpu_topology(void); + +#else /* CONFIG_DT_CPU_TOPOLOGY */ + +static inline void map_cpu_to_dt_node(unsigned int cpu, + struct dt_device_node *cpu_node) {} +static inline int dt_init_cpu_topology(void) +{ + return -EOPNOTSUPP; +} + +#endif /* CONFIG_DT_CPU_TOPOLOGY */ + +#endif /* XEN_DT_CPU_TOPOLOGY_H */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:46:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:46:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416167.1645333 (Exim 4.92) (envelope-from ) id 1x4xqP-0000Ct-CC; Fri, 11 Sep 2026 09:46:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416167.1645333; Fri, 11 Sep 2026 09:46:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xqP-0000Cm-9R; Fri, 11 Sep 2026 09:46:53 +0000 Received: by outflank-mailman (input) for mailman id 1416167; Fri, 11 Sep 2026 09:46:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xqO-0000CM-Cp for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:46:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xqN-008kpW-Pt for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:46:51 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ce04-e002-0a2a0a5209dd-0a2a45038ef0-16 for ; Fri, 11 Sep 2026 11:46:51 +0200 Received: from [52.101.125.103] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ce07-fae8-0a2a45030019-34657d6718d2-3 for ; Fri, 11 Sep 2026 11:46:51 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TYYP286MB5003.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:14b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 09:46:46 +0000 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:46:46 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W43TliTQ83uKMN08ts8bDVN/bTPBh77H2G7tHV5yRK1ioZJQuMz56j96I630bY/CiQD96LAr7F2MS6Fmlhv0gV6z4OBY+oWgUwJsvlAU81AQeuVwMxOqfrveHJo9KcGqdrrG8DjrCPcvD8x19NUQNR7rgAxeql11VFB+JdI/MdZAsJWQo2FcD4FGIvne+Dg4kUXBkYZDBQUHqLkWj0x0K9r2p4haAh283gwSaIkVpONjsdAMm1UG4CkQswJ9uFCScXcfEHd9WFB/hFOnLgMzZIQYA7RtEml3Zx/2Nl3f6mhm0Snc5DthnX+Gm0/YPcE0ZvqqKg1u2x6fl8DOClYCFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2QN3BFSCAU2olLZdlHOeG7dSiGX9Gpgc5FnOC6U5PE4=; b=y//mHE5pqcnGSKlMp2Ku1roDo8ghasJ+WdM11D8FbNtZeudIxHY+HnuqMuu+g9zgn8neekwPurunS/UV8yk29qVlcQrg3Gac6Fy3r0IduR90k1Trgf1nkGQInoLd5sg3rC01hq+Xm6I0UCt4oVDG56d5VVXvrIGTSnhrvK78f1KdaVgSCWKthN+lmeONgvhdDe4yRx6oLAQrvv767D5P4/U252eJQizCR4+MbSAirC19shHcwrV3Gz949ZitU62Trv6IaoYFAMyIelPbAyLEXRQNxH+ilCtdXPDbGXo300qhqZj2sMhuxqlN5PbusBKNruw+3AYrrpX2oEqxGRjEDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2QN3BFSCAU2olLZdlHOeG7dSiGX9Gpgc5FnOC6U5PE4=; b=pR9LDkBYyxWeRwzj34MLGZUp6sZpueUtbtEWXZ8XieFXJm5fU5r2zNYqjS9jB+y0Fcnz0Cuk5+5KLLc2fHT2QrfOtpdmQs4pu32TvD7Qf43KVdQxQGvGZA87ukdXOo/at4GV1YprDngWrjNZWYMJu8faKRbQcVZGiIk25Xz5wak= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Hirokazu Takahashi To: xen-devel@lists.xenproject.org Cc: michal.orzel@amd.com, Mykyta_Poturai@epam.com, Hirokazu Takahashi , Jan Beulich , Juergen Gross , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , Dario Faggioli , George Dunlap Subject: [PATCH v10 2/4] xen/sched: Link CPU topology to scheduler Date: Fri, 11 Sep 2026 18:42:11 +0900 Message-ID: <20260911094213.79936-3-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260911094213.79936-1-taka@valinux.co.jp> References: <20260911094213.79936-1-taka@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP286CA0054.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:2b5::19) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TYYP286MB5003:EE_ X-MS-Office365-Filtering-Correlation-Id: 5a9fc6f7-9583-495d-1e65-08df0fe997f8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|1800799024|23010399003|7416014|376014|366016|56012099006|22082099003|18002099003|10067099003|6133799003; X-Microsoft-Antispam-Message-Info: ikOYjXdQsqM9cEr2YU5AkRucjrM0KU/bi99Qkm+Fvi4lvtQPc5EVioUt85lk9YzXl+ceROKlN6Ngs7PDRKhDEqF6s9oXJnPzG8spwplrLlOYpPbOO2zHWuLkBf+MB4NdCjV0E60NQ+Q6UmH67mdfRPjyEwhO42V6z1++ART9vGHCZ962ovaZCFHJt80KrmLm3/XZRMcpz8WpcWk1wpSXW1PywAN8bYth4lSssGfQ7Upw1nwG+QvbqLR+N1hMYsTbAEEOxb0xXewcjO5rNNE50fEE4P+RlKQ/pi6t4d3t9Hfnc6EmsmwPsDIIjDwdEUzRInebqhINpidFyqpu8NV/pkYh6Y+a/tigoDiVSp06u21dItURzb7FO4mTxWOaLWU5AW7sHYDtJJjLg9tNqWwBaAClCvAt4nol4sJqfgxenDbtiIuUr6UyhFDH6AKRnHLlXnN4B/ULNzQGRyN/BfSELPgPRT0BsrcF58j6c3uPMX/E8mNsPUA3Q2x5o7KZ/VjYLEz8Tkaim30cMUXoSp4JdbNkKLadcK28+D19rwgq3wpGQneGlp75GnuZ0UY9HUHARn1pp/68eSiacsk9exYfQbqAPCKptsusimsK8dI37zM+SfihynHLJrgAjgjDyqXegPqULY6aTr0Ih/ux7iVdmrO29d7jzGlX98NJVGVDM90= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(23010399003)(7416014)(376014)(366016)(56012099006)(22082099003)(18002099003)(10067099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?U50WlrxmWVAD5M20nORZbW7P0IcFoFitABq23i0CKNwvr9dTAp2GkXtjBXOi?= =?us-ascii?Q?MpaHYlunrYCvXB7va0pZ+DrSgM//r1AgGh5cMSKZgn8KEDd1xsu7JKUUn3y0?= =?us-ascii?Q?eqbyfYJF8HcxX7D+uDPR7XavjTeSpZaE0EA4miQMVjAeKjG2mNwG1fDlT1O3?= =?us-ascii?Q?E8Dv+ruTlrkCLsWHHp5bpJjY4xT5zt1YeV9LNtOqXacdJ/aKiH7NBJ37lhOe?= =?us-ascii?Q?rA474+MF3PKjcI6lD8reVfI93gW7qeBoEAyUCz1NRDWK/UJCCAmC5uii4uy+?= =?us-ascii?Q?E/6Zpe7hrWfnzbmp4ytU1dt0i5ECOSqzreaNp/ZruDPa8Xeqlo5KXOGlOQor?= =?us-ascii?Q?XnR/4ACW5nPxv5DOdfuMqJrc35GwIQVfpyhmytAsZf+92j7Li6jWjftpUyPs?= =?us-ascii?Q?QaemvfBMjcekqVNfvvOTSVmdvN2awNGH9U58G7rDcxnvDG0/YdS5LbxuV8wA?= =?us-ascii?Q?uV4neJiY5JuKQTexgjo2GIaMyX1H6lpTvXrZ69m7EoGlWj130ul2WsEU9pSE?= =?us-ascii?Q?PHEXIHemW4XVkMYARChW/iRiJekqJE7NsLmq+Apm8BGE4gmw2gYBeu0B9PqZ?= =?us-ascii?Q?DQhGsFhmRrpxj2LnPbK5yytcyx9v7c3Va4ZTlwkGhS4wNjkE3eqJlgkrebL6?= =?us-ascii?Q?suIJL0/035tZV77RNiwjYPsnTAnQ20wyQW8ACobeIpuNH0KVG66DHRVorrvR?= =?us-ascii?Q?OUG6FnMX2s7o36jra+09r7DUn7TPKGjCUApBnsfUUDO0iK2Co/RCqBaX4qlR?= =?us-ascii?Q?Hqr2/BBJaaR9C66cGi7v+dQwhts4qhZnluka025BEvZto8agni+qfh/GbiOf?= =?us-ascii?Q?3BHGAE2Ry2GJJ8HHOrT7xejwL3l1mPEJZFqOlgU5R7gCoHsmmj5OhM7YZaBG?= =?us-ascii?Q?T6Yf1KzSe6pKEn8CMRmFx8xpfKc+DANN49v/fe3UdLibkylmLRbhKdKSfKd7?= =?us-ascii?Q?s/nzVfrouawx/JLxbcKqTn2JlnzRvaLKy7AS8sbVl7ubviaHv/++WpWUMfS8?= =?us-ascii?Q?+DHtBCL8huOfqoZdOwfoxfGt9YDr3UNOSSfly0FjXa4Ym/7dNzwD7b6HHzpA?= =?us-ascii?Q?M3jYpAh2mg27teAPpRHcy/2BKia38QXFaZMp9g1iIMZsNPps65neQEAhMl4E?= =?us-ascii?Q?X5Rq46s3xwzEYX4ZIalbZSHwLXYwo1ZXOYrR1YnFDL+OB3QmddYfV/HIMR2m?= =?us-ascii?Q?hz2FG7QD7nMQNeFWe/ZoL/tsyEIdPp+dvb3LeBz4umIWJ4suuCPKU7oCACFr?= =?us-ascii?Q?dcxwUF2VqKsyFhgEkcYKpkbcFHbR+r0/+cTmd7dm+49eWBOl7MgKeJw8rBGv?= =?us-ascii?Q?xyybtT5Hm96VZDl3y6sfsvJt+JudnIXM+zXoiqfjjG1tnyjgpCIYGee9yQDI?= =?us-ascii?Q?Z4qqB3Fqp6TwIkpKmNqH2QgmgqLTHp/9iDeyxNU0PUMFpcYOY8TVY4VCx6uO?= =?us-ascii?Q?Uuzv9jjTZnnUtAxXbJjE4goB9ZfZQHZhx95MpvFLXFlr7BpPeCiiAu9S0snl?= =?us-ascii?Q?UZdnLhYdQNqZTlpdhhNqFKGxcVyTY+CJjHdH7Awi+J2mGiCtHgtvU3iT6OdK?= =?us-ascii?Q?s+edKrxuOHPh2/XZhNUV9DBPcb+gR69SiCA2Oic2PiAJMWH7O/gIdN+SoFEa?= =?us-ascii?Q?Sef2hQ2eWn6Wc6yTO2Mb+ovf8Amws0EIZd+Tu3itgJcrdL5IExZFIwzfczke?= =?us-ascii?Q?6qbheO60dulgR+rvJHDldr1BhEKnwR+6AIr+T4PdHEsf3O3q5RiOJWDPdfrf?= =?us-ascii?Q?KxE0svh0AYoI3aP8q+5v0yVfhCI60NYVwPi1SLK9ultknZjs0nzb+IoK+RJN?= X-MS-Exchange-AntiSpam-MessageData-1: Ew8np2R8P3OD9w== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 5a9fc6f7-9583-495d-1e65-08df0fe997f8 X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:46:46.2421 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AtzAk5ctjnq0Lb4vxr9UtdhYDDChInON0aEKTYn1s5/Nv709OwGKL2qVe6LawJ+3cwyUFWfw7i7SdOsEPmw7fg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB5003 X-purgate-ID: tlsNG-33051d/1789120011-6DAD44E9-FEE310CD/0/0 X-purgate-type: clean X-purgate-size: 9049 Make CPU topology information available to the Xen scheduler. Additionally, ensure that this topology information is displayed when executing the 'xl info -n' command. Signed-off-by: Hirokazu Takahashi Acked-by: Jan Beulich Reviewed-by: Juergen Gross # scheduler part --- xen/arch/arm/include/asm/processor.h | 4 -- xen/arch/arm/smpboot.c | 8 +--- xen/arch/ppc/include/asm/processor.h | 4 -- xen/arch/riscv/include/asm/processor.h | 4 -- xen/common/device-tree/cpu-topology.c | 65 ++++++++++++++++++++++++++ xen/common/sched/credit2.c | 6 +++ xen/common/sysctl.c | 1 + xen/drivers/acpi/topology.c | 3 ++ xen/include/xen/cpu-topology.h | 39 +++++++++++++++- 9 files changed, 114 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h index 8ee8f88fb4..fe4125cd75 100644 --- a/xen/arch/arm/include/asm/processor.h +++ b/xen/arch/arm/include/asm/processor.h @@ -614,10 +614,6 @@ void show_stack(const struct cpu_user_regs *regs); #define cpu_relax() barrier() /* Could yield? */ -/* All a bit UP for the moment */ -#define cpu_to_core(_cpu) (0) -#define cpu_to_socket(_cpu) (0) - struct vcpu; void vcpu_regs_hyp_to_user(const struct vcpu *vcpu, struct vcpu_guest_core_regs *regs); diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 904130efdf..da57137a1b 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -92,13 +92,7 @@ static int setup_cpu_sibling_map(int cpu) !zalloc_cpumask_var(&per_cpu(cpu_core_mask, cpu)) ) return -ENOMEM; - /* - * Currently we assume there is no multithread and NUMA, so - * a CPU is a sibling with itself, and the all possible CPUs - * are supposed to belong to the same socket (NUMA node). - */ - cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu)); - cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_possible_map); + init_cpu_sibling_map(cpu); return 0; } diff --git a/xen/arch/ppc/include/asm/processor.h b/xen/arch/ppc/include/asm/processor.h index 242346cab9..1bf6f6c66c 100644 --- a/xen/arch/ppc/include/asm/processor.h +++ b/xen/arch/ppc/include/asm/processor.h @@ -141,10 +141,6 @@ /* Macro to adjust thread priority for hardware multithreading */ #define HMT_very_low() asm volatile ( "or %r31, %r31, %r31" ) -/* TODO: This isn't correct */ -#define cpu_to_core(cpu) (0) -#define cpu_to_socket(cpu) (0) - /* * User-accessible registers: most of these need to be saved/restored * for every nested Xen invocation. diff --git a/xen/arch/riscv/include/asm/processor.h b/xen/arch/riscv/include/asm/processor.h index b1745c1071..c5340a924f 100644 --- a/xen/arch/riscv/include/asm/processor.h +++ b/xen/arch/riscv/include/asm/processor.h @@ -52,10 +52,6 @@ struct cpu_user_regs unsigned long hstatus; }; -/* TODO: need to implement */ -#define cpu_to_core(cpu) 0 -#define cpu_to_socket(cpu) 0 - static inline void cpu_relax(void) { #ifdef __riscv_zihintpause diff --git a/xen/common/device-tree/cpu-topology.c b/xen/common/device-tree/cpu-topology.c index ce9da0bb36..b070774cbb 100644 --- a/xen/common/device-tree/cpu-topology.c +++ b/xen/common/device-tree/cpu-topology.c @@ -320,6 +320,67 @@ static int __init parse_dt_topology(void) return parse_package(map); } +static void __init setup_cpu_topology_ids(void) +{ + unsigned int cpu; + unsigned int next_core_id = 0; + unsigned int next_cluster_id = 0; + unsigned int next_socket_id = 0; + + for_each_possible_cpu(cpu) + { + unsigned int first_cpu; + struct cpu_topology *topo = &cpu_topology[cpu]; + + first_cpu = cpumask_first(topo->thread_sibling); + ASSERT(first_cpu < nr_cpu_ids); + + if ( first_cpu == cpu ) + { + topo->phys_core_id = next_core_id; + next_core_id++; + } + else + { + topo->phys_core_id = cpu_topology[first_cpu].phys_core_id; + } + + first_cpu = cpumask_first(topo->cluster_sibling); + if ( first_cpu >= nr_cpu_ids ) + { + /* Clustering is not supported */ + topo->phys_cluster_id = 0; + } + else + { + if ( first_cpu == cpu ) + { + topo->phys_cluster_id = next_cluster_id; + next_cluster_id++; + } + else + { + topo->phys_cluster_id = cpu_topology[first_cpu].phys_cluster_id; + } + } + + first_cpu = cpumask_first(topo->core_sibling); + ASSERT(first_cpu < nr_cpu_ids); + + if ( first_cpu == cpu ) + { + topo->phys_socket_id = next_socket_id; + next_socket_id++; + } + else + { + topo->phys_socket_id = cpu_topology[first_cpu].phys_socket_id; + } + + topo->num_siblings = cpumask_weight(topo->thread_sibling); + } +} + int __init dt_init_cpu_topology(void) { unsigned int cpu; @@ -330,9 +391,13 @@ int __init dt_init_cpu_topology(void) ret = parse_dt_topology(); if ( ret == 0 ) + { for_each_possible_cpu(cpu) setup_siblings_masks(cpu); + setup_cpu_topology_ids(); + } + return ret; } diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c index 4949606881..eef94528ad 100644 --- a/xen/common/sched/credit2.c +++ b/xen/common/sched/credit2.c @@ -9,6 +9,7 @@ * Based on an earlier verson by Emmanuel Ackaouy. */ +#include #include #include #include @@ -35,6 +36,11 @@ */ static unsigned int cpu_nr_siblings(unsigned int cpu) { +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY + if ( cpu_topology ) + return cpu_topology[cpu].num_siblings; +#endif + #ifdef CONFIG_X86 return cpu_data[cpu].x86_num_siblings; #else diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index 8fb5ff0af3..6f1839b359 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -28,6 +28,7 @@ #include #include #include +#include long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { diff --git a/xen/drivers/acpi/topology.c b/xen/drivers/acpi/topology.c index 090c793f33..d6fe4ffa67 100644 --- a/xen/drivers/acpi/topology.c +++ b/xen/drivers/acpi/topology.c @@ -22,6 +22,9 @@ int __init acpi_init_cpu_topology(void) { struct cpu_topology *topo = &cpu_topology[cpu]; + topo->phys_core_id = cpu; + topo->num_siblings = 1; + cpumask_set_cpu(cpu, topo->thread_sibling); cpumask_copy(topo->core_sibling, &cpu_possible_map); cpumask_copy(topo->cluster_sibling, &cpu_possible_map); diff --git a/xen/include/xen/cpu-topology.h b/xen/include/xen/cpu-topology.h index 7cfe3752cd..52ee93d4d0 100644 --- a/xen/include/xen/cpu-topology.h +++ b/xen/include/xen/cpu-topology.h @@ -4,22 +4,59 @@ #define XEN_CPU_TOPOLOGY_H #include +#include -#ifdef CONFIG_GENERIC_CPU_TOPOLOGY +#include +#include struct cpu_topology { cpumask_var_t thread_sibling; cpumask_var_t core_sibling; cpumask_var_t cluster_sibling; + unsigned int phys_core_id; + unsigned int phys_cluster_id; + unsigned int phys_socket_id; + unsigned int num_siblings; }; extern struct cpu_topology *cpu_topology; + +static inline void init_cpu_sibling_map(unsigned int cpu) +{ + if ( IS_ENABLED(CONFIG_GENERIC_CPU_TOPOLOGY) && cpu_topology ) + { + cpumask_copy(per_cpu(cpu_sibling_mask, cpu), + cpu_topology[cpu].thread_sibling); + cpumask_copy(per_cpu(cpu_core_mask, cpu), + cpu_topology[cpu].core_sibling); + } + else + { + /* Assume all CPUs reside in the same socket and no threading. */ + cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu)); + cpumask_copy(per_cpu(cpu_core_mask, cpu), &cpu_possible_map); + } +} + +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY + void init_cpu_topology(void); +#define cpu_to_core(cpu) (cpu_topology ? cpu_topology[cpu].phys_core_id : 0) +#define cpu_to_socket(cpu) (cpu_topology ? cpu_topology[cpu].phys_socket_id : 0) + #else /* CONFIG_GENERIC_CPU_TOPOLOGY */ static inline void init_cpu_topology(void) {} +#ifndef cpu_to_core +#define cpu_to_core(cpu) (0) +#endif + +#ifndef cpu_to_socket +#define cpu_to_socket(cpu) (0) +#endif + #endif /* CONFIG_GENERIC_CPU_TOPOLOGY */ #endif /* XEN_CPU_TOPOLOGY_H */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:47:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:47:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416176.1645342 (Exim 4.92) (envelope-from ) id 1x4xqj-0000m7-LG; Fri, 11 Sep 2026 09:47:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416176.1645342; Fri, 11 Sep 2026 09:47:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xqj-0000m0-HS; Fri, 11 Sep 2026 09:47:13 +0000 Received: by outflank-mailman (input) for mailman id 1416176; Fri, 11 Sep 2026 09:47:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xqh-0000j6-Li for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:47:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xqh-000pr3-28 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:47:11 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ce0c-8faa-0a2a0a5109dd-0a2a450be1a4-38 for ; Fri, 11 Sep 2026 11:47:11 +0200 Received: from [52.101.229.130] (helo=TY3P286CU002.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ce1c-b7e8-0a2a450b0019-3465e582a678-3 for ; Fri, 11 Sep 2026 11:47:10 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TYYP286MB5003.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:14b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 09:47:07 +0000 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:47:07 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fBVd49n9cpD0ldQR84Tsx3NtlocS+jvyessQzvVx1tztiI88/Szn8aJCJARQRhGvYzGstNLie3hxpvXCa1kAim5QmYkjdAKObEU2jABEFtCg2dNW8jpkS3Zsb8+652gHh+9aGbNMhKHQOvoniBmWrYVkZCpV4PuDT1ea8MbbF6/oTfCkk9gwDvWKlcSg8W41W0n7r5hcyfBeR6VoVn4BTAqvAFbKDtAmm/imC8q5OvgjLTHAaRW/bR9e41y3g1sKJcgxEHmEtDCT9wWWupeP+HQ8WKmVg2U87UH2x8F8cqgT/tB4Q+ozWNKXNSFBj9mCRaudag4FAcgYF/LQTEJMdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DQHSSUv6ukV+BKiUAKLe+m7272BwWIUtvYVDaW9Gcrw=; b=PkHjL7ujaBrljlpOR4O2oapevDHRyK8tKlDrUPo12Bhpyanr7ux+jmHsoq2Cohi+owxHl7LXWOBXcEcbs64A558lBXAOYcOkHydw+u6HUbNnCWU8ti+/bIMV0QWEH+mnjSeXmnzUqWfLj3oM6VZWDAZl1p4ycboU018K7LyYBG5W11Cv4EL9m31+BEwPCiQBKEL2t0CkQu5P7xc0k5q5RCXEmT5tTq8nH+Iztputj8sWBcIrXBXoXGrJmTDTSgoE1hQknDnH7GYN4alDlKL6LKhvnXIglwkxPSLsjFOkgmwSq0uuWO1FPaZB07pc4HdDFAST4ZESNnEWIEXJ1A97Cg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DQHSSUv6ukV+BKiUAKLe+m7272BwWIUtvYVDaW9Gcrw=; b=l6wawT76zb+mLyCeOQFZgW/m4SakueT7A3qghGZshg1jmsY5R4a7NmU3HNLbEIn8kTXTa963joXLfakyzaFmqBvtR4vrTMCZKU/Wgb6Ycjp8co6zKYH1FWcB8Kmv8RPaqKdOBGaGJTtGS1r+1t/Fq7Rx5VJpIdjnnLKOG9NyBQE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Hirokazu Takahashi To: xen-devel@lists.xenproject.org Cc: michal.orzel@amd.com, Mykyta_Poturai@epam.com, Hirokazu Takahashi , Jan Beulich , Juergen Gross , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Julien Grall , Stefano Stabellini , Dario Faggioli , George Dunlap Subject: [PATCH v10 3/4] xen/sched: Make cpu_nr_siblings() architecture-specific Date: Fri, 11 Sep 2026 18:42:12 +0900 Message-ID: <20260911094213.79936-4-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260911094213.79936-1-taka@valinux.co.jp> References: <20260911094213.79936-1-taka@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCPR01CA0157.jpnprd01.prod.outlook.com (2603:1096:400:2b1::10) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TYYP286MB5003:EE_ X-MS-Office365-Filtering-Correlation-Id: e7638002-16eb-4914-ec58-08df0fe9a48f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|1800799024|23010399003|7416014|376014|366016|56012099006|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: kbIfBiustNUcmmZB0KTVxRdryOTsZQUVCkGDv+hr1dvviGEWptRU82lv3exuooK2HuRXPZrBKBpU3WMeK/cgWd4FHlh62ci+e9WV4L0dJWi294aok2Jk3ygN4dZDTTHzQrNmDsz4PxjafJDh5Uj79lKzm8q6zK8iaUGRltlmH7j/aLFED851DQkHUqyqMkH2JYKQbnyR5Juw5/lUMFg5WU1i8u23ioyjU2uhn85N/p8OKql/puWk8uAZYgJ5AYSCm865prlNAN4DOmiAgU03JrsKGWVK7cs3hbohHxQtyLXFwE/+D3ia5knSwQ3FdHe/mRvY8gSXGlndEDBjjHDw5ZtNUXinRncwxX5NxWOg7fWSm5+4vmoEGsm8n+zUQCtXK6sKOSqYGyuhIJ3nVynCJYmQ4P6fpEQq6HWREx9wzXz39Jd8nL84anRWVInz+mLS8Ks8mhURyLpA4+43IY5pZK/IKqVqSyzfCGIld0fnUjcTxvR6fgDHnrreAamzAl5HsA7QLhG8DNjBGDSs9MVtzWxsWxyzwcdZYGsQmB47ZwLuvP+N5JE5K3yBgq2lGHjqj3JQ5s9JAXMkR0KDJ/nWIiayNvyE8xdm6f24DPP9oRk71tzkltvp8rjimB8iLqt481VKrotKRcEeDgLD4+sCtInfepcQ4LVFVWYJauCMj0k= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(23010399003)(7416014)(376014)(366016)(56012099006)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?n6ob0vr8vgizII/X4nhvWFi3sHEAmeHjKVErqiOnTRgSzGDIEolR8tkphwHE?= =?us-ascii?Q?qI2P8E+hZdMCsLnBzwTEndLYj80+/wXFVc2eAh5igJZSBhaeFh3fj/IpxEvD?= =?us-ascii?Q?JjHlCsIm9kGsVDPjs0ayRIyXF3IxnVS/7hbFQW1IeT0wcxK4Y9FJ/jEKeyOn?= =?us-ascii?Q?SjtiELa0Bbdy7hPQmlJfnz2lo69+WG89RNDFhAG3SRNTCYviNXwhsFE9r+pF?= =?us-ascii?Q?LFK2GKMVuY9VyCiFRzb7/IGygc/RjA6gJuo46Y6vgoEO/E483GEr3LjFHWs5?= =?us-ascii?Q?ycrzH1upvanbGvEJxoTFnxOebBhqCAQCVS3d92xkewM0IHgMpHU+dGJG/ds7?= =?us-ascii?Q?69edOiiigIrOfVCF82PVBhxF0tBavL9OzCFes9PkCALYs34dJJ4S55j6UXnA?= =?us-ascii?Q?lQPDGmdJqA3iJ8fS95TmVSh1KroEY0gWwtoKCt5lwCMBtqw7IPwqC7DUFm2N?= =?us-ascii?Q?mWD4oYbOqtEfBBODhSsL8xQtC9BZP2amUXnur9OFgmxKHHXWrAp6zZ/ZDJHq?= =?us-ascii?Q?MaThrbHtcxojbyydnyd8Am0sea93UEBHqqsExqxUcMMLkX+z4zATtmo9Iftn?= =?us-ascii?Q?/AycC+6kbJH6C1N6NSkPGmmKoQVqfL+sA+A4lnNjakOShCYBoBYVfkZhw/0K?= =?us-ascii?Q?v03ILVzayZkJvCyUKdeCKfLgKwauc2VgW6/5xKOER/+ncbM63ORXIpYXu8IB?= =?us-ascii?Q?fbHFKlz2WTHiPIf5QDEJtRTG4TvmD2VTjlR//2Q8syJK3Es5eAycP4xJudAz?= =?us-ascii?Q?oAK9W0xOoqGjMLvswl9FCABYt+0mSsfzMauW2pLj917zqLHdEGzDj3jdPvZS?= =?us-ascii?Q?nfRW8iP8AkmK7v7N5axxyl6tdiO+tSZXxIoaWppvobA2mHzf2dwZ9Kntv6px?= =?us-ascii?Q?LZEECVUjcxMh49EmZNHKJZD/4mZZhP9yVScgP5Nt4pNvPVu96eNKG7UIb6mF?= =?us-ascii?Q?EOCgk1b7GYE3K25Lal8/x6mj+S+rXMFoGxgahUU56jDYYYDJnsy+Ra3iaG+h?= =?us-ascii?Q?FJhEPpAldWM4+Ll5S5kIHvH28vuCwaGdwgJkyE1IwF5IzuzfKiXyoCo6JYcZ?= =?us-ascii?Q?3fpHRs7A/s6xDJQ8+EzrnoEM9mGj2lRfVRz4Q5vfNxbTXZmloSyKM+fZDsDf?= =?us-ascii?Q?iDzJcu0oD2Cz+1Y3/miQhVRSdXjb3D20egspP0BHPwJi6Vn1zijrXVbeQrHD?= =?us-ascii?Q?+8iqM1SHbdVlbNgtGsls26EDBg/Za3kn5S7m1l3sLoBZTw9KTbeX4WcnoIBM?= =?us-ascii?Q?0e71qd6gmjjVlxd0KrWvCn1+GPNLt8vlYjdFNuJwFuYAm0cmCbAWW/oHvPvl?= =?us-ascii?Q?zTdzC2fC26QqbiVROOgcI3NPfyC8A+hKv1RlyucKc4SUfcd/QkWFgaif99RW?= =?us-ascii?Q?O18uyp9VW9/YopEVPjzqgkuOt/57rUFFCT+cLA3719PfzE/7/TeBw7uG0KwK?= =?us-ascii?Q?DtQ79y96ivDAcROhd1amjCIWUdSqxpSWxCAR0f9/+Q9dpTrnlt9OTkPjWJ3Y?= =?us-ascii?Q?zVLmQSEdW0f6X6TOudTkN1aeh8PXu75m3nQwMKyP7vJR32c+k+ebCPZhKXSz?= =?us-ascii?Q?hV2sfvdjg/HTs8diFTnW/80eNIMmCfzOa1lkOTV2g/xuR9G9Lq4It+AcX7Vr?= =?us-ascii?Q?d3si9wxdBHEBo2QBctKVCWxa+Hi6Y85/W449Jby43AcVznzNXonq9frChAM1?= =?us-ascii?Q?VBSl2JJiJEZvW1+8Ejh8BqhHrSfcYkKoGT6UYpSUUCSZOGnd37t4Qu4CBA43?= =?us-ascii?Q?hduxsXSYaCNM0MEkNB8d3wIflMhwjimgCJ9mrj13JxjmC3nWc/o0z1WNEgES?= X-MS-Exchange-AntiSpam-MessageData-1: xUIc6jH/9ggGFQ== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: e7638002-16eb-4914-ec58-08df0fe9a48f X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:47:07.3262 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hXskXj8o2elGTSXAj7c9NHeJw5tZlES4dco7FhWRwD3sOMT8j4kL6NexUKDJAhU23gE/qxFlUhTYIDFH3xCdlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB5003 X-purgate-ID: tlsNG-42698a/1789120031-186CA9EA-866B678D/0/0 X-purgate-type: clean X-purgate-size: 3435 Make cpu_nr_siblings() an architecture-specific function. This patch provides the implementation for x86 and a common version for Device Tree-based architectures. Signed-off-by: Hirokazu Takahashi Acked-by: Jan Beulich Reviewed-by: Juergen Gross # scheduler part --- xen/arch/x86/include/asm/processor.h | 1 + xen/common/sched/credit2.c | 25 +++---------------------- xen/include/xen/cpu-topology.h | 5 +++++ 3 files changed, 9 insertions(+), 22 deletions(-) diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h index 4b17e13a97..049b917c49 100644 --- a/xen/arch/x86/include/asm/processor.h +++ b/xen/arch/x86/include/asm/processor.h @@ -106,6 +106,7 @@ extern void intel_init_arat(void); #define cpu_to_core(_cpu) (cpu_data[_cpu].cpu_core_id) #define cpu_to_socket(_cpu) (cpu_data[_cpu].phys_proc_id) +#define cpu_nr_siblings(_cpu) (cpu_data[_cpu].x86_num_siblings) unsigned int apicid_to_socket(unsigned int apicid); diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c index eef94528ad..6ede629fd2 100644 --- a/xen/common/sched/credit2.c +++ b/xen/common/sched/credit2.c @@ -29,25 +29,6 @@ /* #define d2printk printk */ #define d2printk(x...) -/* - * TODO: Abstract this properly, and figure out what Credit2 wants to do with - * the fact that x86_num_siblings doesn't even have the same meaning - * between x86 vendors. - */ -static unsigned int cpu_nr_siblings(unsigned int cpu) -{ -#ifdef CONFIG_GENERIC_CPU_TOPOLOGY - if ( cpu_topology ) - return cpu_topology[cpu].num_siblings; -#endif - -#ifdef CONFIG_X86 - return cpu_data[cpu].x86_num_siblings; -#else - return 1; -#endif -} - /* * Credit2 tracing events ("only" 512 available!). Check * include/public/trace.h for more details. @@ -885,9 +866,9 @@ cpu_runqueue_match(const struct csched2_runqueue_data *rqd, unsigned int cpu) /* * Additional checks, to avoid separating siblings in different runqueues. - * This deals with both Intel's HTs and AMD's CUs. An arch that does not have - * any similar concept will just have cpu_nr_siblings() always return 1, and - * setup the cpu_sibling_mask-s acordingly (as currently does ARM), and things + * This deals with Intel's HTs, AMD's CUs and ARM's SMT. An arch that + * does not have similar concept will just have cpu_nr_siblings() always + * return 1, and setup the cpu_sibling_mask-s accordingly, and things * will just work as well. */ static bool diff --git a/xen/include/xen/cpu-topology.h b/xen/include/xen/cpu-topology.h index 52ee93d4d0..fccc9cd316 100644 --- a/xen/include/xen/cpu-topology.h +++ b/xen/include/xen/cpu-topology.h @@ -44,6 +44,7 @@ void init_cpu_topology(void); #define cpu_to_core(cpu) (cpu_topology ? cpu_topology[cpu].phys_core_id : 0) #define cpu_to_socket(cpu) (cpu_topology ? cpu_topology[cpu].phys_socket_id : 0) +#define cpu_nr_siblings(cpu) (cpu_topology ? cpu_topology[cpu].num_siblings : 1) #else /* CONFIG_GENERIC_CPU_TOPOLOGY */ @@ -57,6 +58,10 @@ static inline void init_cpu_topology(void) {} #define cpu_to_socket(cpu) (0) #endif +#ifndef cpu_nr_siblings +#define cpu_nr_siblings(cpu) (1) +#endif + #endif /* CONFIG_GENERIC_CPU_TOPOLOGY */ #endif /* XEN_CPU_TOPOLOGY_H */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:47:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:47:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416181.1645351 (Exim 4.92) (envelope-from ) id 1x4xr0-0001CS-W0; Fri, 11 Sep 2026 09:47:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416181.1645351; Fri, 11 Sep 2026 09:47:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xr0-0001CL-T6; Fri, 11 Sep 2026 09:47:30 +0000 Received: by outflank-mailman (input) for mailman id 1416181; Fri, 11 Sep 2026 09:47:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xqy-0001AL-UJ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:47:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xqy-00DOxT-At for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:47:28 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ce2a-8faa-0a2a0a5109dd-0a2a450b9902-10 for ; Fri, 11 Sep 2026 11:47:28 +0200 Received: from [52.101.125.124] (helo=TYVP286CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ce2d-b7e8-0a2a450b0019-34657d7c3aca-3 for ; Fri, 11 Sep 2026 11:47:27 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TYYP286MB5003.JPNP286.PROD.OUTLOOK.COM (2603:1096:405:14b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 09:47:23 +0000 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:47:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mV0o2nDR1s6YSzc26X4oTYKase8EE2OGXv7vI+Fix0xNT3mh+J6Ner2+GYFSW4qIxuXYR00NkyWVfMdW1hDWSyPVrjG3HIY/B28gTmwo6FNicazh1HySi+igG1d4Qxaq5/PYnJUuUg9e8E2sK18RoiZKn5cl3kHTvZNOlxsZOgzgS7QcMGYacZb4LwT2wwsq1vuRZiE4a3xLcmFdWTq1fBXWRtHDfYRJggykbfdExJ7wrqmklz0cIJOueUfaMPaRzJQNX0rma7++aqW1MESTmaA5iZVgNtDXMtoDFrmx9axB4RLNytZhZzByO2+dmFGrDg+hE6zhi6KWuCerqhtyKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gSMNjH+uFDnifcc7j4z3D1fg79w6dp+9PaRbS2TleWA=; b=Iq3WzHnTqdf97sKSHW4ul4fH/9LG8IStHpj9MwBcxJfSe0sTFz1g4sZozrKlOn1D8QC12w6BJVWnTwXRWSAz2hOz6CFWl+sGPGiP4V0xQJ26XI6sJy068nb5QpE+/Hi4XxLIZILzpHvnrDacg4WhyPr3FyJ4m5LGgqMhVvW6VECBmcikoaB6SIlDxpxV6RDOfcHUASL1Z7u2CK6M5mA/UDcxOZmj0KPNCg3mQgDnMrAg7RHk/w1GB37v5tBfgvIxC6d+2GEu9EDI/tJsosBn66+XA9NVis+Rwy4Pomusjpt6ZryV4SipgOTw8ovcUMgU/AKrzBiGSt8FrfMIdrfFxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gSMNjH+uFDnifcc7j4z3D1fg79w6dp+9PaRbS2TleWA=; b=tSb7nH/OSN/lWYJCkNY4/nnwGA1hO1MlIKi8N5XUmxF3vbRdraNYSEcm9IAZyy9Oht9QiSOgDMO3AN7nxIHuIbeGgHJCtvWH0NleEqdcIpQiKZE5u2ylfHpPXqu+eVB/VRiV8UC6N1S2hQXeU2Etl1oT0FiXjuv/PRMKjhx/1rA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; From: Hirokazu Takahashi To: xen-devel@lists.xenproject.org Cc: michal.orzel@amd.com, Mykyta_Poturai@epam.com, Hirokazu Takahashi , Jan Beulich , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v10 4/4] xen/acpi: Parse PPTT to initialize CPU topology Date: Fri, 11 Sep 2026 18:42:13 +0900 Message-ID: <20260911094213.79936-5-taka@valinux.co.jp> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260911094213.79936-1-taka@valinux.co.jp> References: <20260911094213.79936-1-taka@valinux.co.jp> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP286CA0152.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:383::14) To OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: OS9P286MB7222:EE_|TYYP286MB5003:EE_ X-MS-Office365-Filtering-Correlation-Id: ee6257e6-ef7e-4de3-38c2-08df0fe9ae6c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|1800799024|23010399003|7416014|376014|366016|56012099006|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: dbDz2/ueeLPYe1FHZSp5HF02C6BdXH9A/9ywYSvzw25T6Ali1+jZXtO5JwrnUSEAJiJ5yFUglF+J8uI6bu46cZBw5jrilVUyZKUoCOm6p2yKb8mKBxqqhLtMAdexmPiAzuiK8LP+YUKQ9mpIpUWDxOdmv0ZTZQPUgDYPrqFu11CtYuYdNjUyNboC17DghdhU/IM4qqteIHH+rgY5+pqwVti+8u7vaxA0frSeScRhuKWovu7nA74N8ryHB8gmAnAML4oRJ0Ok1yioKeH1ltI/txtwYcbyrIiQs8xR6CiO259vblo9U2+RD7W5943k4EjEnASUE2+POu/rapzHiOI7MXDRzxbpLGrJfahwyqQCpGGbDlTvYAI/h9liIY41JZG8XBAAW7CFjMjA5q9sb5IpoQKKUlx6hy7khtGkPg+qJBZMkUZbyipj8iLShpO9PScgl3F37dt4CRKgjPar8u9+GRzZYi+LGxYB4pSU4t3V84lXkgmz/hkYtcjZUQWFhdfgM44Pqp/ClAwpZWK39SYfk2u0354EIg7pKtS7e8R0NF0Y+29qvPmfvClCABsJLLocYT5tkvyWQPtcFNZUKUEqdjCw342vEdU2jD+REo9q6SFueGL5piSxQglZlhSU/+SSF1K300ITsZ2L2G2B/9dvA1w76cdvG/24jK9XwY0d5n0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(23010399003)(7416014)(376014)(366016)(56012099006)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?geIxV0Xq1/nIvsGglbZ+ELnKvh2q4pvCZwGyKdolvDqFlc+MmCRh/HtA3Hcq?= =?us-ascii?Q?yZboz//IRaZNPOdO8k24N6R+93wRkJdZm6Vohw50j/H4hHKd5BqLvl7pw6ii?= =?us-ascii?Q?Q0mJxjbV3dQhiP33m+7ampoAkPh/bfB9ck21Bf17IJCIyUMiLQEbaf8VROcN?= =?us-ascii?Q?HG5wQsvh/B7taomJMi7N9/rlAQ6aT+3zw4rfA0+PTh9z7Nb6p0mkkVcXC/Uj?= =?us-ascii?Q?9HayatuAysFXPsh/FI40+SxNSxVnIpXiKoni2NqcldgMrD5Fl1T8xDBp7I+w?= =?us-ascii?Q?AXjP/dg3+vZQAIDx1/2u+b8poSzWRTzgRR7XioKG4chsw6lJ0JooOqDW3IR+?= =?us-ascii?Q?jqhH6kKtRcwLcdOuc1Xmnxmiy5peDzHXpOOAL/CKfeo2Z6jx49l1mcJJzTVM?= =?us-ascii?Q?3UfehZ+NZeQptexVzX0mndmFaezUzFwUlf6jtPcnt8lTW8VUarURRH3Ga8D2?= =?us-ascii?Q?JX0BReZh5Tcmh62J3T91w5zGxR3nho7gwnANGT4wazxKDjk791pKwBVrGolW?= =?us-ascii?Q?Gsz8BcPlCLrvveKuVRcR9cdiOd6IzgjmL9XGl3t4XCtws7fvCQXRB/y4+Si4?= =?us-ascii?Q?GPNiadqdbg+sZFrSnmjCv6J+0Mzc1fJJEEke5f2/JczBCXADCk20OrQQRlXR?= =?us-ascii?Q?gMsjoK6RGcJJFqHdKoJBp0k9/L1FmNfRyGbcLNolq1UPwVyfBbTmRhPLfTMR?= =?us-ascii?Q?pNWZu7bRwyj33hRL0FvF4u77C/gd8zL9WfFx/utdMLri6ujP+EHyptuEhVXk?= =?us-ascii?Q?cKyDUsIoNby8A+3dW0Z6C2VfMP6SC4dIYurL7ZB2Zjl/AcJvFOnnVp2UXNPJ?= =?us-ascii?Q?WNTJe1STk35uoriE2le1VulNtGunBggrhhQ0ycvRV282s8JWWsfzqgRCtDaU?= =?us-ascii?Q?3UNqB+S/hq9rEcCgshRXtSzY9rjLTK78REL+IPkqLrR5vzs0JamsOHaRHpWt?= =?us-ascii?Q?DpSmjvwcSLw6wR1qbBoOlUw9VF6gNuYwy3XzU7JrOElP8KQEm9YREUTbC6oE?= =?us-ascii?Q?Xrj/H5q/ANSEUc2wzYENR+H/PHc+eJO773+nuAtll0Os5kkf/wylmLJltX1S?= =?us-ascii?Q?qyBD2r1RX4TsOtpj/U8658g4IMLusVQofGp+7Q8IyZn3g06Np2aWyHuK5tuZ?= =?us-ascii?Q?YOBTkEHBjHe5joatN99q0d0wWhLOFs6YyGqIYCFIVvKVYHpSy+WHKuwVjnrd?= =?us-ascii?Q?wCIt9VSl67Plzydrh5pLfpiSS9Ql+bFg1XD0UpTHSzFROzNSVe8E6VDyQlzN?= =?us-ascii?Q?TfldQTZwC7yC9XV73j/XXrJKP2lxhocdtPpuUV3plWQTq1AsXtgDBmyNzV/I?= =?us-ascii?Q?Fc60ffRyvEINFQLdQJJiAXXbZfY1f2nyUmhgNNFv15qRwJA+tiuK4DDoAl65?= =?us-ascii?Q?/kTKVFXddWA7oKqjVnxBFdI+FbWpqn6Upzqm1Ie66gHkbBuXN3HdKsq+FQiP?= =?us-ascii?Q?tRtsZ+/2wbxJUvsGbdJqq28pghYhuFOEhNRe7mFl9M/qJdexgI1UUd5P9umA?= =?us-ascii?Q?ZQSdrmwOgddtCxlqDSYzKSVZcPUUeVyQzx90UpBtcKoBSbOop1Bq4xTbZHFf?= =?us-ascii?Q?27R+KcOLbfj8nybSoIA6sLKSAQ+NJUuHMWt6ri0x4AZoXVctN8vpmm1Lfa3p?= =?us-ascii?Q?Dvc6gpGX+8Uxo3zgcNsoCOyoew3lA5ySmQu2Eb9xm2l9qoVuZNmdXIs+FGf+?= =?us-ascii?Q?R8HGY30nrLMZXbZDqriwlxGaxQaRP1kWnNfvWdNsCg+Tr5EF/Tm1yQbNi4+i?= =?us-ascii?Q?L7raJ+2BYvTEOy+Mb39gWJjkS4mIpiu78vDD0wNCf8Yob61QFSAQnOnbT9Kj?= X-MS-Exchange-AntiSpam-MessageData-1: 1mfckpDcXo7RIQ== X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-Network-Message-Id: ee6257e6-ef7e-4de3-38c2-08df0fe9ae6c X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:47:23.8730 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: co6cPM2ItFQQkaHYJvWQ3K7j8uW/PaLLCBmzhjad5JzKc9lkWmsWuNI93+i1SaO/sPtNw11/UjiIpobOLnzNrw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB5003 X-purgate-ID: tlsNG-42698a/1789120048-AB2DC9EA-737AC99A/0/0 X-purgate-type: clean X-purgate-size: 14080 Parse the ACPI PPTT (Processor Properties Topology Table) to initialize the CPU topology. For ACPI 6.3 and later, the ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD flag is checked to determine the presence of threading. For ACPI 6.2 and earlier, CPUs are assumed not to support threading. Signed-off-by: Hirokazu Takahashi Acked-by: Jan Beulich --- xen/arch/arm/acpi/boot.c | 2 + xen/arch/x86/include/asm/acpi.h | 2 - xen/drivers/acpi/topology.c | 323 ++++++++++++++++++++++++++++++-- xen/include/xen/acpi.h | 4 + 4 files changed, 316 insertions(+), 15 deletions(-) diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c index 4ac0fd8f51..fc7ecb5749 100644 --- a/xen/arch/arm/acpi/boot.c +++ b/xen/arch/arm/acpi/boot.c @@ -85,6 +85,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor) return; } bootcpu_valid = true; + acpi_map_cpu_acpiid(0, processor->uid); return; } @@ -119,6 +120,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor) /* map the logical cpu id to cpu MPIDR */ cpu_logical_map(enabled_cpus) = mpidr; + acpi_map_cpu_acpiid(enabled_cpus, processor->uid); enabled_cpus++; } diff --git a/xen/arch/x86/include/asm/acpi.h b/xen/arch/x86/include/asm/acpi.h index 217819dd61..7a89baa143 100644 --- a/xen/arch/x86/include/asm/acpi.h +++ b/xen/arch/x86/include/asm/acpi.h @@ -132,8 +132,6 @@ struct acpi_sleep_info { extern u32 x86_acpiid_to_apicid[]; #define MAX_LOCAL_APIC MAX(256, 4 * NR_CPUS) -#define INVALID_ACPIID (-1U) - extern u32 pmtmr_ioport; extern unsigned int pmtmr_width; diff --git a/xen/drivers/acpi/topology.c b/xen/drivers/acpi/topology.c index d6fe4ffa67..c9b545115c 100644 --- a/xen/drivers/acpi/topology.c +++ b/xen/drivers/acpi/topology.c @@ -4,33 +4,330 @@ #include #include #include +#include + +#define ACPI_PPTT_MAX_LEVELS 16 + +static uint32_t __initdata map_cpu_acpiid[NR_CPUS] = { + [0 ... NR_CPUS - 1] = INVALID_ACPIID +}; /* - * TODO: Populate the topology information by scanning the ACPI - * PPTT (Processor Properties Topology Table). + * The first argument 'cpu' is the logical CPU ID assigned by Xen, + * and the second argument 'acpi_id' the 32-bit ACPI processor ID. */ -int __init acpi_init_cpu_topology(void) +void __init acpi_map_cpu_acpiid(unsigned int cpu, uint32_t acpi_id) { - unsigned int cpu; + map_cpu_acpiid[cpu] = acpi_id; +} + +static unsigned int __init get_logical_id(unsigned int key, + unsigned int *map, + unsigned int *count) +{ + unsigned int id; + + for ( id = 0; id < *count; id++ ) + if ( map[id] == key ) + return id; + + map[*count] = key; + + return (*count)++; +} + +static bool __init verify_subtable(const struct acpi_subtable_header *entry, + const struct acpi_table_pptt *pptt) +{ + unsigned long table_end = (unsigned long)pptt + pptt->header.length; + + if ( entry->length < sizeof(*entry) || (entry->length & 3) ) + { + printk(XENLOG_ERR "ACPI: PPTT subtable length is invalid\n"); + return false; + } + + if ( (unsigned long)entry + entry->length > table_end ) + { + printk(XENLOG_ERR "ACPI: PPTT subtable extends beyond table end\n"); + return false; + } + + return true; +} + +static bool __init verify_proc(const struct acpi_pptt_processor *proc) +{ + unsigned long table_size; + + if ( proc->header.length < sizeof(*proc) ) + { + printk(XENLOG_ERR "ACPI: PPTT processor node length is too small\n"); + return false; + } /* - * Generate temporary cpu topology information for now. - * It assumes that the cpu doesn't have SMT and all CPUs - * belong to the same socket. + * Each private resource is represented by a 32-bit resource ID. + * Reject if the number of private resources exceeds what can fit in + * the 8-bit limit of proc->header.length. */ + if ( proc->number_of_priv_resources > + (UINT8_MAX - sizeof(*proc)) / sizeof(uint32_t) ) + { + printk(XENLOG_ERR "ACPI: PPTT too many private resources\n"); + return false; + } + + /* + * Ensure the structure length accurately accounts for the trailing array. + */ + table_size = sizeof(*proc) + + proc->number_of_priv_resources * sizeof(uint32_t); + + if ( proc->header.length < table_size ) + { + printk(XENLOG_ERR "ACPI: PPTT processor node length invalid\n"); + return false; + } + + return true; +} + +static const struct acpi_pptt_processor *__init find_pptt_node( + const struct acpi_table_pptt *pptt, uint32_t acpi_id) +{ + const struct acpi_subtable_header *entry; + unsigned long table_end = (unsigned long)pptt + pptt->header.length; + const void *ptr = pptt + 1; + + while ( (unsigned long)ptr + sizeof(*entry) <= table_end ) + { + entry = ptr; + + if ( !verify_subtable(entry, pptt) ) + break; + + if ( entry->type == ACPI_PPTT_TYPE_PROCESSOR ) + { + const struct acpi_pptt_processor *proc = + container_of(entry, const struct acpi_pptt_processor, header); + + if ( !verify_proc(proc) ) + break; + + /* + * Leaf node verification is only required for ACPI 6.3 + * (PPTT revision 2) or later. + */ + if ( (proc->flags & ACPI_PPTT_ACPI_PROCESSOR_ID_VALID) && + proc->acpi_processor_id == acpi_id && + (pptt->header.revision < 2 || + (proc->flags & ACPI_PPTT_ACPI_LEAF_NODE)) ) + return proc; + } + + ptr += entry->length; + } + + return NULL; +} + +/* + * Populate the topology information by scanning the ACPI PPTT + * (Processor Properties Topology Table). + */ +int __init acpi_init_cpu_topology(void) +{ + struct acpi_table_header *table_header; + const struct acpi_table_pptt *pptt; + unsigned int num_sockets = 0; + unsigned int num_clusters = 0; + unsigned int num_cores = 0; + unsigned int *socket_map = xvzalloc_array(unsigned int, nr_cpu_ids); + unsigned int *cluster_map = xvzalloc_array(unsigned int, nr_cpu_ids); + unsigned int *core_map = xvzalloc_array(unsigned int, nr_cpu_ids); + unsigned int cpu; + int ret = 0; + acpi_status status = acpi_get_table(ACPI_SIG_PPTT, 0, &table_header); + + if ( ACPI_FAILURE(status) ) + { + /* A missing PPTT is benign; fall back to the default topology. */ + ret = -ENODEV; + goto out; + } + + if ( !socket_map || !cluster_map || !core_map ) + { + printk(XENLOG_ERR + "ACPI: Failed to allocate memory for topology parsing\n"); + ret = -ENOMEM; + goto out; + } + + pptt = container_of(table_header, const struct acpi_table_pptt, header); + + for_each_possible_cpu(cpu) + { + uint32_t acpi_id = map_cpu_acpiid[cpu]; + struct cpu_topology *topo = &cpu_topology[cpu]; + const struct acpi_pptt_processor *proc; + unsigned int level; + unsigned int core_group_key = 0; + unsigned int cluster_group_key = 0; + unsigned int socket_group_key = 0; + bool threading = false; + + if ( acpi_id == INVALID_ACPIID ) + { + printk(XENLOG_WARNING "ACPI: Invalid ACPI ID for CPU %u\n", cpu); + ret = -EINVAL; + goto out; + } + + proc = find_pptt_node(pptt, acpi_id); + if ( !proc ) + { + printk(XENLOG_WARNING + "ACPI: No PPTT leaf node for CPU %u (ACPI ID %#x)\n", + cpu, acpi_id); + ret = -ENOENT; + goto out; + } + + /* + * Limit the maximum loop depth to prevent an infinite loop in case + * the PPTT is corrupted or contains cyclic references. + */ + for ( level = 0; level < ACPI_PPTT_MAX_LEVELS; level++ ) + { + const unsigned int offset = (const void *)proc - (const void *)pptt; + + /* + * If this proc has no parent node, it is the root node. Treat it + * as equivalent to an ACPI_PPTT_PHYSICAL_PACKAGE node. + */ + if ( (proc->flags & ACPI_PPTT_PHYSICAL_PACKAGE) || !proc->parent ) + { + socket_group_key = offset; + + /* + * If cluster/core info is absent upon reaching the physical + * package, assume one cluster per socket and one core per + * cluster. + */ + if ( cluster_group_key == 0 ) + cluster_group_key = socket_group_key; + + if ( core_group_key == 0 ) + core_group_key = cluster_group_key; + + break; + } + else if ( level == 0 ) + { + /* + * ACPI_PPTT_PROCESSOR_IS_THREAD is supported in PPTT + * revision 2 and later. Assume no threading support when + * PPTT revision is 1. + */ + if ( proc->flags & ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD ) + threading = true; + else + core_group_key = offset; + } + else if ( level == 1 ) + { + if ( threading ) + core_group_key = offset; + else + cluster_group_key = offset; + } + else if ( level == 2 && threading ) + cluster_group_key = offset; + + if ( (proc->parent & 3) || + proc->parent < sizeof(*pptt) || + proc->parent > pptt->header.length - sizeof(*proc) || + (proc->parent + sizeof(*proc) > offset && + proc->parent < offset + proc->header.length) ) + { + printk(XENLOG_WARNING + "ACPI: PPTT parent offset is invalid\n"); + break; + } + + proc = (const void *)pptt + proc->parent; + + if ( proc->header.type != ACPI_PPTT_TYPE_PROCESSOR ) + { + printk(XENLOG_WARNING + "ACPI: PPTT parent node is not a processor structure\n"); + break; + } + + if ( !verify_subtable(&proc->header, pptt) || + !verify_proc(proc) ) + break; + } + + if ( socket_group_key == 0 ) + { + printk(XENLOG_WARNING + "ACPI: Could not reach the physical package node for CPU %u (ACPI ID %#x)\n", + cpu, acpi_id); + ret = -ENOENT; + goto out; + } + + topo->phys_socket_id = + get_logical_id(socket_group_key, socket_map, &num_sockets); + topo->phys_cluster_id = + get_logical_id(cluster_group_key, cluster_map, &num_clusters); + topo->phys_core_id = + get_logical_id(core_group_key, core_map, &num_cores); + } + for_each_possible_cpu(cpu) { struct cpu_topology *topo = &cpu_topology[cpu]; + unsigned int tcpu; - topo->phys_core_id = cpu; - topo->num_siblings = 1; + for_each_possible_cpu(tcpu) + { + struct cpu_topology *ttopo = &cpu_topology[tcpu]; - cpumask_set_cpu(cpu, topo->thread_sibling); - cpumask_copy(topo->core_sibling, &cpu_possible_map); - cpumask_copy(topo->cluster_sibling, &cpu_possible_map); + if ( cpu > tcpu ) + continue; + + if ( topo->phys_core_id == ttopo->phys_core_id ) + { + cpumask_set_cpu(tcpu, topo->thread_sibling); + cpumask_set_cpu(cpu, ttopo->thread_sibling); + } + + if ( topo->phys_cluster_id == ttopo->phys_cluster_id ) + { + cpumask_set_cpu(tcpu, topo->cluster_sibling); + cpumask_set_cpu(cpu, ttopo->cluster_sibling); + } + + if ( topo->phys_socket_id == ttopo->phys_socket_id ) + { + cpumask_set_cpu(tcpu, topo->core_sibling); + cpumask_set_cpu(cpu, ttopo->core_sibling); + } + } + + topo->num_siblings = cpumask_weight(topo->thread_sibling); } - return 0; + out: + xvfree(socket_map); + xvfree(cluster_map); + xvfree(core_map); + + return ret; } /* diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h index cbb02e0f35..9788586be4 100644 --- a/xen/include/xen/acpi.h +++ b/xen/include/xen/acpi.h @@ -52,6 +52,8 @@ (!(entry)) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \ (entry)->header.length < sizeof(*(entry))) +#define INVALID_ACPIID (-1U) + #ifdef CONFIG_ACPI #include @@ -137,10 +139,12 @@ static inline int acpi_boot_table_init(void) #ifdef CONFIG_ACPI_CPU_TOPOLOGY +void acpi_map_cpu_acpiid(unsigned int cpu, uint32_t acpi_id); int acpi_init_cpu_topology(void); #else /* CONFIG_ACPI_CPU_TOPOLOGY */ +static inline void acpi_map_cpu_acpiid(unsigned int cpu, uint32_t acpi_id) {} static inline int acpi_init_cpu_topology(void) { return -EOPNOTSUPP; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:47:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:47:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416191.1645360 (Exim 4.92) (envelope-from ) id 1x4xrM-0001sg-7I; Fri, 11 Sep 2026 09:47:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416191.1645360; Fri, 11 Sep 2026 09:47:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xrM-0001sX-4h; Fri, 11 Sep 2026 09:47:52 +0000 Received: by outflank-mailman (input) for mailman id 1416191; Fri, 11 Sep 2026 09:47:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4xrL-0001sN-K0 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:47:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xrL-005Fc0-02 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:47:51 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ce46-bab6-0a2a0a5309dd-0a2a4506a55a-0 for ; Fri, 11 Sep 2026 11:47:50 +0200 Received: from [209.85.218.48] (helo=mail-ej1-f48.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ce46-195a-0a2a45060019-d155da30c5a5-3 for ; Fri, 11 Sep 2026 11:47:50 +0200 Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-c259e5c22ffso139203266b.1 for ; Fri, 11 Sep 2026 02:47:50 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c29660219ecsm61286666b.16.2026.09.11.02.47.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 02:47:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789120070; x=1789724870; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=MM4SOAWcCqCHxjusqPiPkwSXJUjWUPEQXgA0Xm21+lE=; b=DKIABiuTmAiE861kvmunqKXn0s9eME2zI2qBXrNmoZaCVZ8+LEiLrU67koiqgnpF8r WnOouM8rcRO0EASPr6+wsR+pUUAcjZHJ3Vft3auumyLBrCT1QSfjTW/jjfxAHZvGpbRf dfzEobnlku4aGoFA7urA+8xsZ0LIWdJoCGGe7ZLPoky049On6gP4vMi5su7qv5dqcK7S 1W+kLUrIzFGOQTwjkpbSizbtvWrOtK3dQsPe0/IlQdHgySaWY6WzZeVfOz6XQLFkgpgj FUc3f9UiH2w/QmSe/aSwHyyFC7ncfe2Ni8fnGIfDAkZl+Umv3kmwJ2yEISE8SLw/XEHQ bF1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789120070; x=1789724870; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=MM4SOAWcCqCHxjusqPiPkwSXJUjWUPEQXgA0Xm21+lE=; b=L1jFznEqz1Zn+2X5F5OjJYYYyEbYV577rvlIt/lYkqXzrs4SxyiHUIcN1UAsG366qF DXKCuYwCJi4HImM38JoUCWVTFY5qYwWIJaAW3RMZot9Br0UEM1C+dkUl0V6fvZ2Ryus4 LgsuqeRHpnGdjqehPscLXVyNV9tRJmeYRVNgEUV17K6Em+yWqlmEC4z/iOC1IK0B3Ytb uKQOYRbHE7G91p/iYtENP3Lly2FlycI8Lt2i54vzMDP+eCcsv5oevWCyhMRQip+9NBqw h69YFdMSKp1Lc2flwJ1nLo8zMqlUsBaiokQMNYYaeud3yc9849KUBT58mRyAfWRyb0QK RIfg== X-Forwarded-Encrypted: i=1; AKwUvBzNnD9QsP3ivbjdcQpS1Ibt7e170SWyxZNO72/+Z7oUF2Yq+J3OAkiIx+62qKFmbULH4oFD5/g2QfQ=@lists.xenproject.org X-Gm-Message-State: AFuF++lIv8h9DJzPuob2ySouPYrcJu+xSnlGb95MtKOiO0j8wL9yGGjP tkA17uEJ/ea5gZRJY+Qj/HagOVFNAXLPXGapiyWO19rT3nXTycrDQVdz X-Gm-Gg: AYBFou3/cSm1aHgskKssViNNGsMdW8uBHhShzr9LPlRr+bwOOfvgcMCSF66c9KI5aZq h/Mz1ZE0mhf3LI+3xNGK4Bx/lnuoOBgpMIQ5uN1GuKG62Xqw3v5djjsA9XZwAymgiAzibJ4EeJb fi/5iOcwaMpjVXaRA6XzUCZXwO5qS42uuYXvvm84NufAnkXXpxu868hF4dW6+wY+HsIwaNqeVm5 WS9GyRhjYZQt6aQMyn4RMdZG61iCprNoVk7jgfJ+SQ5VzJqev8PFzd/NeTcoDnEU/Qn7frtxYtI WpVxAuinpQKhwHJv+JL623id3ElUTEsRzjyF1QEOzcNOb9Steww3KyaAp1z6HRnHMbQCD9SVWay oDyZgFjZvavsUxIiS25QBT1DMOHj4CL0/3JN73LwsMDr35dSxqDsx90AFuLfihmOqNLtl/6DRd0 XCfGNIq/PJ3bVy4f+/rh7hXoxoRowCwIsp+XQglvjhSCBQqpynXUkBTHohBVrHiDTu9iWNYhuzq lFy6WwKUKXvL/i/O3FHg+ThJXFRT0vK X-Received: by 2002:a17:907:6d1e:b0:c25:68c2:7b94 with SMTP id a640c23a62f3a-c29667f018cmr132118966b.8.1789120070304; Fri, 11 Sep 2026 02:47:50 -0700 (PDT) Message-ID: Date: Fri, 11 Sep 2026 11:47:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> <487a7efa-e83d-4ae2-8f39-33483161a64d@gmail.com> <9f2245d8-faef-4608-a179-b8e942fdfc1d@suse.com> <744f17cb-de7b-499a-83cb-9f0a122a4605@gmail.com> <7731e7b5-d5cb-4ba2-a53c-06b5ca019ccf@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <7731e7b5-d5cb-4ba2-a53c-06b5ca019ccf@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789120070-F4C0777B-D2B2DAB1/10/73395122804 X-purgate-type: spam X-purgate-size: 4593 On 9/10/26 2:57 PM, Jan Beulich wrote: > On 10.09.2026 14:44, Oleksii Kurochko wrote: >> >> On 9/10/26 1:23 PM, Jan Beulich wrote: >>> On 10.09.2026 12:59, Oleksii Kurochko wrote: >>>> On 9/9/26 4:52 PM, Jan Beulich wrote: >>>>> On 27.08.2026 17:20, Oleksii Kurochko wrote: >>>>>> @@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const cpumask >>>>>> >>>>>> ASSERT(spin_is_locked(&desc->lock)); >>>>>> >>>>>> - cpu = cpuid_to_hartid(aplic_get_cpu_from_mask(mask)); >>>>>> - hhxw = imsic->group_index_bits; >>>>>> - lhxw = imsic->hart_index_bits; >>>>>> - /* >>>>>> - * Although this variable is used only once in the calculation of >>>>>> - * group_index, and it might seem that hhxs could be defined as: >>>>>> - * hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT; >>>>>> - * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted >>>>>> - * when calculating the group index. >>>>>> - * It was done intentionally this way to follow the formula from >>>>>> - * the AIA specification for calculating the MSI address. >>>>>> - */ >>>>>> - hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; >>>>>> - base_ppn = imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT; >>>>>> - >>>>>> - /* Update hart and EEID in the target register */ >>>>>> - group_index = (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) & >>>>>> - (BIT(hhxw, UL) - 1); >>>>>> - value = desc->irq; >>>>> Hmm, only after sending the ack I noticed that there's no masking here, ... >>>>> >>>>>> - value |= cpu << APLIC_TARGET_HART_IDX_SHIFT; >>>>>> - value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); >>>>>> + cpu = aplic_get_cpu_from_mask(mask); >>>>>> + >>>>>> + /* Update hart index and EIID in the target register */ >>>>>> + value = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >>>>>> + (desc->irq & APLIC_TARGET_EIID); >>>>> ... but there is masking here. Chopping off bits doesn't look as if it can >>>>> lead to anything good. What's the deal here? >>>> The mask is a no-op: desc->irq < NR_IRQS (1024) always fits the 11-bit >>>> EIID field, so I'll drop it and add a BUILD_BUG_ON() instead. >>>> >>>> Would it be better to: >>>> >>>> + /* desc->irq < NR_IRQS, so it always fits the EIID field */ >>>> + BUILD_BUG_ON(NR_IRQS - 1 > APLIC_TARGET_EIID); >>> If the question is whether to prefer BUILD_BUG_ON() over BUG_ON(), then: >>> Yes please. However, APLIC_TARGET_EIID is a mask (despite its name not >>> indicating that), which only happens to start at bit 0. This kind of >>> assumption would better be avoided. >> Then BUILD_BUG_on should be updated to: >> >> /* desc->irq < NR_IRQS, so it always fits the EIID field */ >> BUILD_BUG_ON(NR_IRQS - 1 > MASK_EXTR(~0U, APLIC_TARGET_EIID)); >> >> >>> This raises another question though: No matter how big a RISC-V system >>> is, it can only ever have 1k IRQs? How does that work with a single >>> MSI-X device having up to 2k MSIs? >> Device MSIs never pass through the APLIC. They are written straight into >> an IMSIC interrupt file. The ID space belongs to each file, so each hart >> has up to 2047 IDs (IMSIC_MAX_ID). >> >> 1k it is limitation for wired interrupts (which could be delivered in >> MSI mode where APLIC + IMSIC is needed) which are going through APLIC. > But desc->irq and NR_IRQS have to represent both. Which then puts the > BUILD_BUG_ON() above under question. Agreed. Right now desc->irq, the APLIC source number and the IMSIC EIID are all the same number: aplic_set_irq_affinity() writes desc->irq into EIID, and aplic_handle_interrupt() hands the IMSIC identity from stopei straight to do_IRQ(). That only works because there's no MSI support on RISC-V yet, so NR_IRQS covers wired interrupts only. Once device MSIs are supported, that identity mapping can't stay anyway. IMSIC IDs are per interrupt file and shared between wired and MSI interrupts, so we'll need to allocate EIIDs and map desc->irq to (hart, EIID). target[] will then get the allocated EIID rather than desc->irq, and NR_IRQS will grow beyond 1024. So for this patch I'll tie the check to the APLIC source range instead of NR_IRQS: BUILD_BUG_ON(ARRAY_SIZE(aplic.regs->target) > MASK_EXTR(~0U, APLIC_TARGET_EIID)); ASSERT(desc->irq && desc->irq <= aplic_info.num_irqs); The ASSERT also covers the target[desc->irq - 1] indexing. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 09:51:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 09:51:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416206.1645368 (Exim 4.92) (envelope-from ) id 1x4xvD-00042G-Pk; Fri, 11 Sep 2026 09:51:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416206.1645368; Fri, 11 Sep 2026 09:51:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xvD-000429-N2; Fri, 11 Sep 2026 09:51:51 +0000 Received: by outflank-mailman (input) for mailman id 1416206; Fri, 11 Sep 2026 09:51:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4xvC-000423-22 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 09:51:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4xvB-00DQ4e-B4 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:51:49 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3cf33-e002-0a2a0a5209dd-0a2a450397a8-12 for ; Fri, 11 Sep 2026 11:51:49 +0200 Received: from [40.107.200.68] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3cf33-fae8-0a2a45030019-286bc844e73b-4 for ; Fri, 11 Sep 2026 11:51:48 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by LV0PR03MB989274.namprd03.prod.outlook.com (2603:10b6:408:398::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.14; Fri, 11 Sep 2026 09:51:46 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 09:51:45 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gWaP277UbuKa9WiTaDN5HG4Vdx2OjUrHm56OlzDsBz5AOsVO+X6MndLO4yrjJeUk07ydBrte3PNp4jurC+ETp7iheIiNidIjURkC3UKRqFn7SmR1AD/hAF+anMA/WJW0VXnGpxxu2jBQ6WFi2+jN8oDagYAhEigxLLSiK6A9kP+OiwWiF59zHgrPEelxPtxRvNVJbb/eAuzmYytH0fYBLnIkgDJbQoWyHEqrND7UaYByJO7InvSON+yPLVtGUIXanpgtH2bli5wU7rzQT+dlJEjMKqAinexAxYrHYS8ZMJSCIvszM3RYA5aC99JwklkD8J8SN39osCJ+fIfDUkubEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FjaI9Uk5mCz6KQLOPUZ9qtLmEVJa2tm6Xki0qc363Uk=; b=yjuRgyVHYSLXBnWFYOLhu0d6lCGG7U8a4b8wpBDEIl4GiD4tE9rsK8i7M9kMZ0kNButfu0jyGxinOJr0H4cOhV+Zbv6lfkIFi4Za3XfvvJr1VEz4jX64wnA1wsAz7i71QoHGR29enFms96GisIXNoMDk9Ps4mB1Vl/HLTmiY/baiCuKA9ylahV6RZ1e9U61pEMUihT2vi5eYwmziac2C+P1FN02qZUDgwaz0Npp/8wdUxQ15X7svP5fGS6xGdWcUusLrCXTpnMb+FglZ0tVUQbyoBeI2wq7gcWgY1+Zw7e9CTuUI7ua5f0lvSNa6W77HZ0Lds6/M+Ir3X5BNQDvF2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FjaI9Uk5mCz6KQLOPUZ9qtLmEVJa2tm6Xki0qc363Uk=; b=i38BzSPeNhi17TvcFebQt5xwu0KOYMOoGINMKtBf5ycq1i238K4Egya2+5sai86VPSHDDF3sss9O6RBnpdKXUI0gaCccpdvNOfvDilcM5XYUjMstUdHraMWhBVJ3wzWUlorOKH6hwatjSRpP+Y5Rw9V+sIvnvxUCwCvAXKJxvjw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v3] x86/svm: Intercept CR0 writes selectively Date: Fri, 11 Sep 2026 10:51:21 +0100 Message-ID: <20260911095121.1177503-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0056.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:153::7) To DS0PR03MB8272.namprd03.prod.outlook.com (2603:10b6:8:28f::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|LV0PR03MB989274:EE_ X-MS-Office365-Filtering-Correlation-Id: bc60e828-14ec-46ca-84d0-08df0fea4a55 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|10067099003|56012099006|18002099003|11063799006; X-Microsoft-Antispam-Message-Info: ae77ry2Rhsfp/xdW5wb8jiZyO71m6THtxJiGybAehL8Vku8O5lTi1q0gwBgEQyZPA4ilstTW9bSG8DGipON7a2lQpHLWxc1pZyaHrJZmyX4f58Q3koVnUndAGJTn1aINVF9fyJ8uV2mNT2vVaHN5kxyaHZSEw3tUEDkLAJ1m4vEoc+AaYUkGUyB8WdFDlOS1MTyUuhcQDp7jO4MIJf7DxcAjhpEeC8t7f28srTnjPPhcqyCcCjEX5+1D3Q55RMnOJCAQtORlab5SzkN2/6W95bLJU1cgailDNbPgmTGic6ZUalnSBen1yzLdVM0EtsybSv8lqUTy53CV129KyTkAtQedDkLPRBT8nS5VmiwTb1vNKg/ZCtDDZShep9WypA3xYhB9WUP3GxKRho9yj+Cm/nNqMZ/qvS+J7vm8OU3oNGsIUWZhSqcwdtYzL29X5tR0ufrOGpfYjvFEmxJiJsUVusICVu/biutrZ01p58DkqbM+/7WAniQFewELg8caViIfNF9MZNazWNU8BCGq6dgF1mewiO0hxkvPmMEpAE2BEBBe9xqkLnIhH5hR3tPQtXnQH3Pp9B2DubtwH1ezcSL1J7CdzT8Unx7bNAzGDTMGzjnsZI0GvV2u55rrU/k27Xa7U5QrEAzhzbVDt2Mw+00G+ibGkXGp6Q1oG+gG+eZg1Q4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(10067099003)(56012099006)(18002099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?MkspuFhECQPFgXULxTFPBMfmEfzTWmCkCqJX58KPYEOL27ZXA6+gz8jJjdbK?= =?us-ascii?Q?qhhhbKwdlR7d6hnWakczf09KdZYpMs3+DJp36C6Y0vdGGPwPg52vT2gdmAEz?= =?us-ascii?Q?zb9rllO37QO88rO2jgXJE4PBjF/hHSV9k74+I8OGEmmN6Q4CII7/PCzkomvu?= =?us-ascii?Q?3Ikik+duz3+Doh/UvUDxVaPInQOWCtbQUVFNURE9wTFr6hL3+bK7eU3Jq1/W?= =?us-ascii?Q?+bAQRj9vG3/fEBgDwIXXpLBZ+/P9u2JRw4OMymLg9hkKL0Iw5o73zUluKHFG?= =?us-ascii?Q?r1cQIILyZsrRxkuXuDDNqPzC30psUCZYd/eGtiMNw3uNqIhrjsTCZrRd9mD0?= =?us-ascii?Q?CUp/Z6kOSiiZR2rfhEpC3OVCA3ON7kMFkFQueeUPx+8iDl8ClNo+26u2xGBw?= =?us-ascii?Q?yAYOCeqBKUzuoKcr+HaNUELGYOAKSL6ZCQI307+Atz/6dMOVcn2/CpIrbaV/?= =?us-ascii?Q?G5I57JZHNVSPSG7GYaDVFFsJcaWzgV9hdTpzckDHBJMM6yP/nTJPGGZkOgsa?= =?us-ascii?Q?6iEFyyflEmnUWFJnG0HZ+zpsAiZGLI/CUVn6JD+xMSx4w8uiQ1XxVGmDmdAA?= =?us-ascii?Q?OE0P+GPblz/eGwzdVVHgfAwBmD8IfC/+Juh7EdS6xqlW0W3QqiV+ZAMjLxfl?= =?us-ascii?Q?5iaw7VNjzaTKgfYgFWA8Bw0NOcs/tju7sZyCZsvV9QrIr9MGDusTIiSsDrA0?= =?us-ascii?Q?zWASWlJsCO5yjqeX0QnYbR82OZK09YGg8w93RQXl0Vv2ZDMMK53WaRZf3mvp?= =?us-ascii?Q?/uzhHQJjFJ7sE4d6srTCVRW9a1TkzoSmRA101LwPyO2763Od4A/UTGbq1/GF?= =?us-ascii?Q?lO8bKBD+kml20BpdHP6D4TvPac5GrQS0l1tU3zONR5OklWEf1QMDrF/DVhRy?= =?us-ascii?Q?uQppFkxMSoaQQ7IqF2C5NGsPcPe3vLf1I/jcjW6bt7A/c4e9Ck09YbnfW4VE?= =?us-ascii?Q?mGxLp6mrag3wf+XEvDP2S799DuFzMfYGTgrdy+LEOZnlwwifkTVL6oW+ywgC?= =?us-ascii?Q?cW5mvIdPvr355iRIC65aodfcKbjPt0Ay2RphFLfvyDf+17BAl1jJSAfzqDDy?= =?us-ascii?Q?/taCLVLt48V1eEkGVruvrkVSr8Zetdo/t1jFfEoM6Qf3Gv7v9HN+Yr5A/VN3?= =?us-ascii?Q?q+VGmvXIiIfxchZNW1Qnigr2oi2P1sjqlZIrtUI8XOYPXQu/ZEHGgfy6Beos?= =?us-ascii?Q?xSZTsOxpEIjj8oxpBbbpP6mO51zHcvuzxoSekjIvr21tkjqhSsizpucau8/b?= =?us-ascii?Q?+3XkcyHuuNhpSmxmSMRLzuW1G3Z4V8AWUqAYwxiBzpa6k2nimzD94McpkUAC?= =?us-ascii?Q?8f5xxUU5FR7CaPO20bn1a5/rppLQ1KsWW9ku3/TDouhivElnUr9D3q0rbPjl?= =?us-ascii?Q?ZPdHUeKzg125lmjQQhjbQq8sAOLVzPzyvdKDFTzRkBFCeTdzT31EMgmPHiNJ?= =?us-ascii?Q?YYL41/EqkvTgZJypNVdxp1dK51Tr+tQ9i/VoJF1b8Yr0XmI80qvL155cQWqM?= =?us-ascii?Q?bCcTw7N3QwaDE82A485qEfaetKoTfWg7+8UXtOb5UYymPANGkK2bQtwkQvvd?= =?us-ascii?Q?E9Co+hq/3itSCxr/CqPEDVRpsnT8cDRgQn8k5zbcbiOvQTZR/BTi7axquK+w?= =?us-ascii?Q?yCbJBlQ0h5+8+IZXPaBV/hVqiZY9uiqpF7E3WhEv9D9jsONYSP8t+M62CgP4?= =?us-ascii?Q?gGbI9pPzN+rfh9lWcpSTXfJJmGEQbQxrM5AtK3EYlFe2m2KupsLy773ctzBs?= =?us-ascii?Q?yUCLJTd2BmM28Zl3Fzj3LQivhz9ZyVM=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc60e828-14ec-46ca-84d0-08df0fea4a55 X-MS-Exchange-CrossTenant-AuthSource: DS0PR03MB8272.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 09:51:45.6452 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nhL1xy/3xXtQpI8Q6uFRoCqtV6FoSJluI/vBMkxiUpuFkoywDe6qA9XP+ypyXmYHttucsFJJdpV6zLbJi6D9y9KBKf4OcWiMFUlnD3zyzAU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV0PR03MB989274 X-purgate-ID: tlsNG-33051d/1789120308-74C884E9-E574EC40/0/0 X-purgate-type: clean X-purgate-size: 3082 Since 3356d685dbda ("x86/svm: Remove lazy FPU support"), Xen does not need to track when the TS or MP bits change so opt to intercept CR0 writes selectively. Aside from potentially reducing a few VMEXITs, this fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE and L0 intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so L1 never sees any CR0 writes. Since CR0 TS/MP bits may now change behind Xen's back, sync CR0 on VMEXIT so that the emulator sees the correct values. Shadow mode continues to use the full CR0_WRITE intercept since with Shadow the CR0 in the VMCB is not the same as the value Xen tracks on behalf of the guest and allowing the guest to change one of them directly would be fragile. Signed-off-by: Ross Lagerwall --- In v3: Change HAP only, not Shadow xen/arch/x86/hvm/svm/svm.c | 7 ++++++- xen/arch/x86/hvm/svm/vmcb.c | 7 +++++++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 5f5d903d872d..4e0f3282251f 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1640,7 +1640,8 @@ static void svm_vmexit_do_cr_access( { int gp, cr, dir, rc; - cr = vmcb->exitcode - VMEXIT_CR0_READ; + cr = (vmcb->exitcode == VMEXIT_CR0_SEL_WRITE) + ? 16 : (vmcb->exitcode - VMEXIT_CR0_READ); dir = (cr > 15); cr &= 0xf; gp = vmcb->ei.mov_cr.gpr; @@ -2519,7 +2520,10 @@ void asmlinkage svm_vmexit_handler(void) v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb); if ( paging_mode_hap(v->domain) ) + { + v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb); v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb); + } if ( nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v) ) vcpu_guestmode = 1; @@ -2883,6 +2887,7 @@ void asmlinkage svm_vmexit_handler(void) case VMEXIT_CR0_READ ... VMEXIT_CR15_READ: case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE: + case VMEXIT_CR0_SEL_WRITE: if ( cpu_has_svm_decode && vmcb->ei.mov_cr.mov_insn ) svm_vmexit_do_cr_access(vmcb, regs); else if ( !hvm_emulate_one_insn(x86_insn_is_cr_access, "CR access") ) diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 975a1eaef806..d069280a4da8 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -154,6 +154,13 @@ static int construct_vmcb(struct vcpu *v) vmcb->_cr_intercepts &= ~(CR_INTERCEPT_CR3_READ|CR_INTERCEPT_CR3_WRITE); + /* + * Xen is not interested in changes to the MP and TS bits so use + * CR0_SEL_WRITE to avoid unnecessary intercepts. + */ + vmcb->_cr_intercepts &= ~CR_INTERCEPT_CR0_WRITE; + vmcb->_general1_intercepts |= GENERAL1_INTERCEPT_CR0_SEL_WRITE; + /* * No point in intercepting INVLPG if we don't have shadow pagetables * that need to be fixed up. -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 10:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 10:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416232.1645377 (Exim 4.92) (envelope-from ) id 1x4y9c-0006aC-02; Fri, 11 Sep 2026 10:06:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416232.1645377; Fri, 11 Sep 2026 10:06:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4y9b-0006a5-Ta; Fri, 11 Sep 2026 10:06:43 +0000 Received: by outflank-mailman (input) for mailman id 1416232; Fri, 11 Sep 2026 10:06:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4y9b-0006Zz-0U for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:06:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4y9a-00DdhD-Da for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:06:42 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3d2b1-2eae-0a2a0a5409dd-0a2a4508d69a-2 for ; Fri, 11 Sep 2026 12:06:42 +0200 Received: from [40.93.195.56] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3d2b0-f659-0a2a45080019-285dc338542b-3 for ; Fri, 11 Sep 2026 12:06:42 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB7024.namprd03.prod.outlook.com (2603:10b6:a03:433::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.8; Fri, 11 Sep 2026 10:06:38 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 10:06:37 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XqNxvpG7GDIMZGEO9aatG/IgUv80FhD332Qbzcy/4eQvVPCJ5Na9E9XwDljHeRJtLIzLtkP+CsKm6BTgda8f1OsjC2fLS57oYdcrrgGPIxQ+ftdlBVK9jTUYNh7Yz7Mu8SN+SbZVsK9BDHp7s2lbt2jXOvynsMDQkb4OT/KADNwCwCDPkZHnQvjH1NshAQ4Pn21S/Q0rvvqQCIBlzmyjLdMqKga/bFCNWcKSKbBtRCObHsDObTrDkXQC2+b34+tCJPhk/Y3pitKzJdai7bvfZbDMqx6lgFE/uSs9psrxcQ+0Vctn3qmWv/ZUUq5Xeyi3DXKCiVNnbHArpmcsyclUyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KWBa+/18y8zYEKUg1Y7KJgFwdLU6qI/Ra4pbMntCXQA=; b=T0wS94rMqyK9bCnJvJyFJ+rUQf3STmz5iNLl9wiVFAYeuVZbs4pbtV+r+SoVVuc9sRfaJ0VmbrZRlq7VnllEejILrSeHxR2GTfBchfzTf23nSXcP2UUILRpS46xXEmxWlmpXlfXMB/rwhk8/MN8CkR0uTtxO/fn+ydCgk0Lk4b3npakZg5Mr/38M49QahoStThA4bpy6ha6VatXOdV5cQ4To7M6nFkoZJwTjkqdcwCVJDVR/rIqnKfgXaJO/Fb454gUydg0kBopOLx1xKAwSCMQVgm5b8Wcd2xfMmRi1cFBiPZqoprPCLTWXzkHQVQWKs2UTJiKKE2Rw4cFbmZoP8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KWBa+/18y8zYEKUg1Y7KJgFwdLU6qI/Ra4pbMntCXQA=; b=RDWyMJH6BQ29w5gM9l2gcWy0fpKlUtjhI0OaQg3CVApMr1m9HvHv5UNNK7oP8z6epIBNk4bSnEEbI/nP+1oPoROglcctM0MNFWlx/jRrN1QaxkC3hYmR/hSi8gdon2T7WPtnjbwoSh3X9uiMui7yodAsasifGLp7ftWTmHwOgfA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 11 Sep 2026 11:06:33 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH v1] nestedsvm: Fix multi-byte IO port intercept check To: Ross Lagerwall , xen-devel@lists.xenproject.org References: <20260910163955.1005097-1-ross.lagerwall@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260910163955.1005097-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P123CA0014.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:338::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB7024:EE_ X-MS-Office365-Filtering-Correlation-Id: 89fd55c8-9ea1-4cf7-7625-08df0fec5dc3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|10067099003|56012099006|11063799006|5023799004|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: PFTJgVkp8VJK2CwJWyRd/cd6qrzEe9dwPSdoqq45RROtWkq0WlwzdptsIoubCfAPNv9qP/Pom81pQsCAmRlCUPrWmeIw/ainCROqutZ7o2HGX19PZvRzUevIWwen5AP4+zlhj7I1QB31PHfipjaloPMfjKg28MUT3vOOEkBhUMU6eHOws/jVFssHwmkq6YSpBG2hvPwMO12ayDjDd9CMLtlpmAipiQVn4a2L8fuJmPCG2iEHcZvvkgjT/64MkCwCo0AVv/RuBND9ccl+2aCjWKlAWqjXe67jyAjA3f8UuxnhLr8OPMCK0f7QowrzI5sJnTvA/1yr+Kl2/xCcw2kzeYgxTORrEnhwk0A3yrMLYTcUYUGesZMxT0cKQiCDTTUIBSd3mt1kRCRcsoN5JWyRDm9fq317gveOS4BdYecSLxaCG4QI1h/iKlU+669CJ+UBNsNwiTfhsfR22REwl3BlimQG7/g5Lbl11YqX1BFVzIQKf6wli79ZYZZDlyi8A1forB1CRfawMYK8BrxLDnELxl1fKPy049h2icrbDW29ihYwFUYUAhruKCcAmwYortmLqfA3bJkn6kij+77Pb4sMQJW3YjH1iOOaW2uxVupf4nN4VO3o/2JK5MZn5Kds+k7ef5B8N4KeOaTqYWaMUA3yzhwik2cpA/9KpCe+cJl/rGc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(10067099003)(56012099006)(11063799006)(5023799004)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aWZ4Ni9oNkVkNjdGb3NQZjRxNStwZXpIRlI3eC9YWkhwbnVGUm5jTDloejNZ?= =?utf-8?B?YTY0UytWQ29ZbVF5N1ZxV0U4M3k4RHF1Q1ZOc2ZPYUZBUmc5dnhwSHNHeXNi?= =?utf-8?B?bnlIVzlHQkUzWURJSXg0a0xWQVJwUmZEcUE5M1ZoemtjaytjTDN4NVZSaFZt?= =?utf-8?B?WDE2dWhkd3laM3dPV3A5cnhFcSs4dDhwZVpEOGFISUtMRXpXZVQ3dGxxZVUx?= =?utf-8?B?LzVLeVFubytrcTduZ0hMcGdkOEVLbXI5a0pYUzFCUHNjTThYTkdoVWh3MytF?= =?utf-8?B?TzBIdFVFWWM4V05UdlBNemRZMzcxRWx3OUp6V3Bicjd5bzRULzRZMG1ZMG1n?= =?utf-8?B?bmNIK2xXRUg5TE40Z25KVzMwMHNqUXZVOGxlNXlCNE9QTnlHcTJYdGRXSFdG?= =?utf-8?B?Tld5Wko0M2pVQ1NNMVdWd3IrVnp1Yi9hc01LOHU2TEZLaDB6czhacGIwSjh3?= =?utf-8?B?UXoxdEJzT0JFViszbFdleDZEQW02WjRYenFWV0RXOUhTL0t2TDM4cVc2enhj?= =?utf-8?B?MVBnL2x0T05sVnhwdUZTa0xiM1N3aXlOOHdUaVRDN3RrRWtHWG5jRy9XaFNK?= =?utf-8?B?ZjlRd3VYQTl6SThMWFZZWndReG9EQVZ2RG5YR3hoS1Jza00xaUY4VmhTZzNB?= =?utf-8?B?OVI4S29BMzBLMEVqSGJyM2xtaWsxemttRW1jYS8rdFZ2MVFrbnhzdE0rL0xs?= =?utf-8?B?Z1NQZzhrWHlublRLd1ZQZnlXZnBZVk1wRFhPQjZFUjA3TmRQUTVsZC9yMHRT?= =?utf-8?B?d0dYMDFUSlNsOERzcFpoVDE0VGlIdENDSWFzc3Y3OURoTUdZdm9NcmJzalNX?= =?utf-8?B?a1NwbWE5SkIxZGZHa3dzWXpuYjhEKzhFV25iZHlBbWs0T1JqVllnK29tSFZJ?= =?utf-8?B?bkFZalZRZGpIbU5nbEJXTDIzQmRMNEh3QTBBb0FVWGlIVHlhNVJYVkVyTEda?= =?utf-8?B?cFFaTUdnc2ZNM2hnNVlveUd4UnIyN0EyUFpFL3huQVJ2MUhlZkttWVJaYUgx?= =?utf-8?B?M2Jyc3kxQnliRWlHT05kZEFJd3Y5T0FTQjBTbC9RUmh3dnR5eStRMG1GMkRn?= =?utf-8?B?YjFQYVBVQlNvOFI2WmdMeFpQM3NzenE5RG9sVUtabDgvV2MxbXI4cTBVbGYw?= =?utf-8?B?WUt6VFVZWWNUY3V3OFRVSkM2N2kwZ1FXMEJHbFpvR2xEckl2Q1pVaEJhbFVJ?= =?utf-8?B?YTJsTnBaRGZ2aFZPRmdFSDI1c2ZkaDk3dnZMdGRoZ0dTeENrWXNhaUNuV0dq?= =?utf-8?B?eW92RU5sVFRPZmlyREFXMzNoYjBmWUdHT2pFTmNtMHFNVWFmTXJJVkNjWGM5?= =?utf-8?B?ZXRCMkpBTjMzbHIyZFRwdHpDcVl6ZFJxMWN5aGpKMEZnOEJDMXAySk10YVMw?= =?utf-8?B?QXdrNFB3UEY3a3I2OHRjRGxRQ2JvQmo2VTE2SFRtczVLUEJjRTc0S2laZGxB?= =?utf-8?B?L3ZNMkNGdjFTNXpMVFdoWVYvWGpQU1dUd2N5YjhyaDluVGRrd2NFY0d6ai92?= =?utf-8?B?SlZWK251RzhXOXBJcC8yZy9lS1NmdEhMTGc3VUUyei9aRno0anZqN21wV0tB?= =?utf-8?B?cERtVER1d0dSRWRNU1RBaHZHWW5qRUJvZXhxV0JYRjI1YitlMGZjN1JGOU9i?= =?utf-8?B?UzN5Ny80UUJPMDVwbGozaHJad29iZDJENzZxajQ3T2RaZkVETFMwRjBmNXlL?= =?utf-8?B?QThmMDZpakVnYzhSZlRZM3VPenRGQktVQVZZb2NEeW5MbEZna0FiVVdSem5V?= =?utf-8?B?OG9YN2xVbHJtcXp0TjYwemFlQXh5OWQveW5ZZ05KZWZuYmw4QlBYSUlkRTBv?= =?utf-8?B?ajU1bFFVK21uSmZDSERaRDU3RE9JbmhpakVWTnNsK3JsVFVheVZ2dnYwcjhK?= =?utf-8?B?ejBCNDdKVTBQVUV3VWpOOGF2MjdjampRK3ZTRGZyZG1zbHFkYVUrcE5RT3BU?= =?utf-8?B?aTZQVmIweFg3M1JnZDR2SWtIeHRoUVlPaGxLZFM3OFFyVS9TZklSc1NsdUF1?= =?utf-8?B?RW9rQ0NjRVorVkpiNGpxeld2dWNFcVJ0MnBBQm9pNXlMcjJZRzRIV3J0aDlk?= =?utf-8?B?bE41dGV4RUR5UVdqT21hVkZOQ3BERDFBOXFVSDNsNTE3WCtWbmxWSU5PeUFG?= =?utf-8?B?eXB0TTRiS1NaWndLemFXbzc3enIwTnhtNk1oL3JLSzl2TXZLVU5ZTWc4MUJB?= =?utf-8?B?aFk1T1dsMEYxMUdIZno4bWZBUXl4Q1JmeEZRaGR3U1dyY2ExQXNxZTF2Z3lj?= =?utf-8?B?dm5ZUEVWRGFkR2JUQm44bmJLNWdpVzU0VmkvN05SYzE2NGRaRjVVbUhPdUpK?= =?utf-8?B?M091a3Y1LzJmMkR0b3pCS0Y0U2hscWwySmplRHlJME1nNTlvVDZxUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89fd55c8-9ea1-4cf7-7625-08df0fec5dc3 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 10:06:37.0818 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mlwfCXaIECN6b64i7Qq8TjRIfX3AmgWjWcx0MlNFn9zpS7M0DPdlRJlm1neewc892A8Xh9jNuanplk38K6R+u8Gk5s/QRDzUMoOMYxk/1KI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB7024 X-purgate-ID: tlsNG-c1860d/1789121202-CC57487B-CCF0759D/0/0 X-purgate-type: clean X-purgate-size: 2436 On 10/09/2026 5:39 pm, Ross Lagerwall wrote: > For multi-byte IO port accesses, the APM says that SVM should intercept > if any of the corresponding permission bits are set. However, the code > has this backwards and only intercepts if all the permission bits are > set. By any chance is this for the root partition, with 0xcf9 permitted but 0xcf8,a,b intercepted? > > This affects Hyper-V since it does not generally set all the permission > bits of the multi-byte ports it allows its root partition to access. > This results in an L2 root partition that cannot do PCI config space > accesses and therefore cannot access its NVMe disk to continue booting. > > Signed-off-by: Ross Lagerwall > --- > xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c > index 5adb1bd72c4d..249fde43b5be 100644 > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -852,7 +852,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t iopm_pa, uint64_t exitinfo1) > for ( io_bitmap = hvm_map_guest_frame_ro(gfn, 0); ; ) > { > enabled = io_bitmap && test_bit(port, io_bitmap); > - if ( !enabled || !--size ) > + if ( enabled || !--size ) > break; > if ( unlikely(++port == 8 * PAGE_SIZE) ) > { While this does fix a bug, I think the behaviour is still unsafe. For starters, 'enabled' is a terrible name and is probably a major factor in getting this wrong.  It should be 'intercepted'. hvm_map_guest_frame_ro() can return NULL for several reasons[1], including ballooned out frames/etc.  It is not by accident that a set bit means intercept; it's for the same reason that the byte sequence FF FF is #UD (with the PUSH that should have been in that position moving elsewhere in the opcode table), and that's because ~0 is the return value for "nothing here on the memory bus". Either way, if io_bitmap is NULL, the port should be intercepted rather than access being permitted, so the other prior line needs to be of the form:     intercepted = !io_bitmap || test_bit(port, io_bitmap); ~Andrew [1] One of the few things which can't go wrong is gfn being in the address space but gfn+3 being outside of it.  This is stated to cause a VMEntry failure. From xen-devel-bounces@lists.xenproject.org Fri Sep 11 10:08:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 10:08:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416238.1645386 (Exim 4.92) (envelope-from ) id 1x4yB9-0007KO-As; Fri, 11 Sep 2026 10:08:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416238.1645386; Fri, 11 Sep 2026 10:08:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yB9-0007KH-8A; Fri, 11 Sep 2026 10:08:19 +0000 Received: by outflank-mailman (input) for mailman id 1416238; Fri, 11 Sep 2026 10:08:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yB8-0007J2-7L for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:08:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4yB7-00B44n-Br for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:08:17 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3d308-2eae-0a2a0a5409dd-0a2a4507d0e4-16 for ; Fri, 11 Sep 2026 12:08:17 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3d30f-b4ea-0a2a45070019-a0658309b0a4-3 for ; Fri, 11 Sep 2026 12:08:17 +0200 Received: from mewpvdipd1070.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id E284D84D50E3; Fri, 11 Sep 2026 06:06:07 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Mark Syms To: qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Anthony PERARD , Paul Durrant , Edgar E. Iglesias , David Woodhouse Subject: [BUG] hw/xen: features published after InitWait since 240cc11369fc Date: Fri, 11 Sep 2026 11:08:12 +0100 Message-ID: <178912129220.24041.799369954881004447@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-ID: tlsNG-ef75cf/1789121297-A6AD8AE4-C2F8151B/0/0 X-purgate-type: clean X-purgate-size: 6271 Hi, We think there is an ordering regression in the Xen PV backend setup path, introduced by a commit that was itself fixing a genuine crash. We are reporting rather than patching, for reasons at the end. ## Symptom A blkif VBD hot plugged into a running Linux guest silently negotiates a single page (order 0) ring instead of the eight pages the backend is willing to offer. That is 32 request slots instead of 256. Nothing reports this. The disk attaches, works, and is simply eight times shallower. We found it on XenServer 9 (qemu 10.2.2, Linux 6.1 guest) while setting up an unrelated performance measurement, and lost some measurement time before noticing the ring depth was not what we had configured. The same VBD attached at guest boot gets the full order 3 ring every time. Hot plugged, in 20 unplug/plug cycles, it took the 32 slot ring 20 times out of 20. It is not an occasional race; hot plug loses it essentially always. ## Cause, as far as we can tell `xen_device_realize()` in hw/xen/xen-bus.c currently advertises the backend state before the device's `realize` has written its feature nodes: xen_device_backend_set_state(xendev, XenbusStateInitWait); ... xendev_class->realize(xendev, errp); and for xen-block it is that `realize` which writes the feature nodes, in `xen_block_realize()`: if (qemu_xen_gnttab_can_map_multi()) { xen_device_backend_printf(xendev, "max-ring-page-order", "%u", blockdev->props.max_ring_page_order); } Our understanding of the xenbus handshake is that `InitWait` is the signal that the backend's parameters are readable. A frontend which acts on it promptly can therefore look before those nodes exist. Linux blkfront reads the key with no wait and no retry: max_page_order =3D xenbus_read_unsigned(info->xbdev->otherend, "max-ring-page-order", 0); ring_page_order =3D min(xen_blkif_max_ring_order, max_page_order); `xenbus_read_unsigned(..., 0)` returns 0 when the key is absent, so losing the race is indistinguishable from talking to a backend that does not support multipage rings. That also explains why only hot plug is affected. A booting guest takes seconds to reach blkfront probe, by which time the backend has long since finished writing. A VBD hot plugged into a running guest is answered in microseconds. `max-ring-page-order` is simply the one we noticed. Everything `xen_block_realize()` writes after the state transition looks equally exposed, including `feature-discard`, `discard-granularity`, `feature-flush-cache`, `info` and `mode`. ## Where it came from This was not always the case. The order was inverted by: 240cc11369fc ("hw/xen: Avoid crash when backend watch fires too early", Jan 2023) Before that commit `xendev_class->realize()` ran before `set_state(XenbusStateInitWait)`, so the feature nodes were published first and the handshake was correct. We want to be clear that commit was fixing a real bug, and a nastier one than this. Quoting it: The xen-block code ends up calling aio_poll() through blkconf_geometry(), which means we see watch events during the indirect call to xendev_class->realize() in xen_device_realize(). Unfortunately this call is made before populating the initial frontend and backend device nodes in xenstore and hence xen_block_frontend_changed() (which is called from a watch event) fails to read the frontend's 'state' node, and hence believes the device is being torn down. Moving `realize` after node population fixed that crash. It also moved it after `set_state(InitWait)`, because that call happens to sit in the same block. We think that side effect is the regression, rather than anything wrong with the intent. ## Why we are not sending a patch The obvious change, moving `realize` back above the state transition, would reintroduce the 2023 crash, so please do not take that as our suggestion. The two constraints look reconcilable: `realize` needs the frontend and backend path nodes to exist before it runs, and the feature nodes need to be published before `InitWait`, and those only conflict because a single `set_state()` call sits inside the block that `realize` was moved after. Whether it is safe to defer only that call, and whether any backend depends on the state already being `InitWait` during its `realize`, is a judgement for people who know this code better than we do. We have not tested any such change. Separately, and the reason there is no patch attached to this mail at all: this work made extensive use of Claude Opus 5, and we understand qemu will not accept code produced that way. That constraint applies to the fix regardless of how small it is. We are sending the report because the defect seemed worth your knowing about even if we cannot contribute the change ourselves. ## Confirmation We tested the diagnosis rather than leaving it as a reading of the source. Deferring only the `set_state(XenbusStateInitWait)` call until after `xendev_class->realize()`, and leaving the node writes and `set_online()` where they are so that 240cc11369fc's crash fix is undisturbed, gives: stock ordering order 0 in 20 of 20 hot plugs InitWait deferred order 3 in 20 of 20 hot plugs Same guest, same VBD, same script, back to back. We are describing that result rather than offering the change, for the reason above. We did not check whether any other `XenDeviceClass` backend depends on the backend state already being `InitWait` during its `realize`; we only exercised xen-block. That is the part we would expect you to want to verify. ## What we have not established We have not instrumented the frontend to catch the read of the missing key directly, so the mechanism is inferred from the ordering plus the A/B above rather than observed in blkfront. We also have not measured how wide the window is, or whether other frontends behave differently. Happy to run further experiments on our side if that would help. Regards, Mark XenServer Storage Engineering From xen-devel-bounces@lists.xenproject.org Fri Sep 11 10:12:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 10:12:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416290.1645397 (Exim 4.92) (envelope-from ) id 1x4yFK-0001Bb-0e; Fri, 11 Sep 2026 10:12:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416290.1645397; Fri, 11 Sep 2026 10:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yFJ-0001BU-SC; Fri, 11 Sep 2026 10:12:37 +0000 Received: by outflank-mailman (input) for mailman id 1416290; Fri, 11 Sep 2026 10:12:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yFH-0001BM-L3 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:12:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4yFH-00DTxw-1V for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:12:35 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3d410-8faa-0a2a0a5109dd-0a2a4506833a-12 for ; Fri, 11 Sep 2026 12:12:34 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3d411-195a-0a2a45060019-ac6904fec090-3 for ; Fri, 11 Sep 2026 12:12:34 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 76D1B60239 for ; Fri, 11 Sep 2026 10:12:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A4CE1F00A0C for ; Fri, 11 Sep 2026 10:12:31 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5b6188a2c0eso732740e87.1 for ; Fri, 11 Sep 2026 03:12:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789121552; bh=QzR3OWuBav+XmtWhWfa//3WXPxWknBW30Jm9cIpSRHk=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=hnwGlCScws72DqJBeLbcUlcFe556k2mxeoxnVj//N9ldU7MsE6BViCBQvUKO17Fer YaQj4zOa1YXxPR7uLGbvZ1pH6EHN08GExbinYoE3thrVIuxvN6KBi539BTUnGnq/jC vCAcVnwN32XhH1RtC0bmMA5HKX+LMMLHTMJ78sBj6FBbz67C8JoflxUIRBfsGs8rgZ hOZXlZiyTW9XnCQHfMKLkXQWdyQeEHClebOaKeRRMjmnFB4j9FXT0xKTrKbgqIm+l9 R23Y3Jr23Her64RepjN3sJLQZUHWibHcbwNBd+m0B36K3yFwY9b/avoga4Q+6ndi2i MIVzOp+jwlvRQ== X-Forwarded-Encrypted: i=1; AKwUvBzckjwYvtOYTLuXMxaablRthvNgM4TOqEEcuLfntkv45eu2cqdqN8pi5BFEUTs+dwCBYEjoMkrexUI=@lists.xenproject.org X-Gm-Message-State: AFuF++nMPfH91oJO/oQsFhfzH5Tr8D0o1LR1y+VoxDFMpHpZ1D9Q1tx8 latQ3L1UYb4L17nBeWZuw6gu2Ot+CyvYFIFK+20guhGLuU4x+8AHoqJoHzHULHBtKm1NXSvL2my F3b0So2AgYMWqwmyqnO7PMkw7TijtXmM= X-Received: by 2002:a05:6512:68b:b0:5ae:bf3b:c98 with SMTP id 2adb3069b0e04-5b8a02de39emr860505e87.10.1789121545937; Fri, 11 Sep 2026 03:12:25 -0700 (PDT) MIME-Version: 1.0 References: <20260911074530.3140830-1-jgross@suse.com> <20260911074530.3140830-13-jgross@suse.com> In-Reply-To: <20260911074530.3140830-13-jgross@suse.com> From: "Rafael J. Wysocki (Intel)" Date: Fri, 11 Sep 2026 12:11:12 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1UlLqJaX7BR7a3ZFi9BvCHGTNPFRyOHrGb1jmNXC0wutVCqHiOJbEPj-s4 Message-ID: Subject: Re: [PATCH v3 12/13] treewide: convert rdmsrq() from a macro to an inline function To: Juergen Gross Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-fbdev@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Damien Le Moal , Niklas Cassel , David Airlie , Olivia Mackall , Herbert Xu , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Linus Walleij , Bartosz Golaszewski , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Arnd Bergmann , Greg Kroah-Hartman , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , Helge Deller , xen-devel@lists.xenproject.org, linux-geode@lists.infradead.org, Michael Kelley Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-16d1c6/1789121554-FC2004DB-3FA2285A/0/0 X-purgate-type: clean X-purgate-size: 203218 On Fri, Sep 11, 2026 at 9:46=E2=80=AFAM Juergen Gross wro= te: > > Today rdmsrq() is a macro using its second parameter as the target for > storing the read MSR value. > > Convert rdmsrq() to an inline function returning the MSR value. > > The users have been converted using the following semantic patch: > > // Options: --include-headers > > virtual patch > virtual report > > @@ > expression msr, val; > @@ > ( > - rdmsrq(msr,val) > + val =3D rdmsrq(msr) > ) > > Signed-off-by: Juergen Gross > Acked-by: Damien Le Moal # ATA > Reviewed-by: Michael Kelley # Hyper-V Acked-by: Rafael J. Wysocki (Intel) # ACPI, cpufreq, powercap, thermal Thanks! > --- > arch/x86/coco/sev/core.c | 2 +- > arch/x86/events/amd/brs.c | 4 +-- > arch/x86/events/amd/core.c | 4 +-- > arch/x86/events/amd/ibs.c | 18 +++++----- > arch/x86/events/amd/lbr.c | 8 ++--- > arch/x86/events/amd/power.c | 8 ++--- > arch/x86/events/amd/uncore.c | 4 +-- > arch/x86/events/core.c | 20 +++++------ > arch/x86/events/intel/core.c | 11 +++--- > arch/x86/events/intel/cstate.c | 2 +- > arch/x86/events/intel/ds.c | 2 +- > arch/x86/events/intel/knc.c | 6 ++-- > arch/x86/events/intel/lbr.c | 14 ++++---- > arch/x86/events/intel/p4.c | 6 ++-- > arch/x86/events/intel/p6.c | 4 +-- > arch/x86/events/intel/pt.c | 12 +++---- > arch/x86/events/intel/uncore.c | 2 +- > arch/x86/events/intel/uncore_nhmex.c | 4 +-- > arch/x86/events/intel/uncore_snb.c | 2 +- > arch/x86/events/intel/uncore_snbep.c | 6 ++-- > arch/x86/events/msr.c | 2 +- > arch/x86/events/perf_event.h | 6 ++-- > arch/x86/events/rapl.c | 4 +-- > arch/x86/events/zhaoxin/core.c | 6 ++-- > arch/x86/hyperv/hv_apic.c | 6 ++-- > arch/x86/hyperv/hv_init.c | 26 +++++++------- > arch/x86/hyperv/hv_spinlock.c | 2 +- > arch/x86/include/asm/apic.h | 4 +-- > arch/x86/include/asm/debugreg.h | 2 +- > arch/x86/include/asm/fsgsbase.h | 2 +- > arch/x86/include/asm/kvm_host.h | 2 +- > arch/x86/include/asm/msr.h | 15 ++++---- > arch/x86/include/asm/paravirt.h | 8 ++--- > arch/x86/kernel/apic/apic.c | 14 ++++---- > arch/x86/kernel/apic/apic_numachip.c | 6 ++-- > arch/x86/kernel/cet.c | 2 +- > arch/x86/kernel/cpu/amd.c | 14 ++++---- > arch/x86/kernel/cpu/aperfmperf.c | 8 ++--- > arch/x86/kernel/cpu/bugs.c | 12 +++---- > arch/x86/kernel/cpu/bus_lock.c | 8 ++--- > arch/x86/kernel/cpu/centaur.c | 8 ++--- > arch/x86/kernel/cpu/common.c | 12 +++---- > arch/x86/kernel/cpu/feat_ctl.c | 4 +-- > arch/x86/kernel/cpu/hygon.c | 4 +-- > arch/x86/kernel/cpu/intel.c | 6 ++-- > arch/x86/kernel/cpu/intel_epb.c | 4 +-- > arch/x86/kernel/cpu/mce/amd.c | 4 +-- > arch/x86/kernel/cpu/mce/core.c | 8 ++--- > arch/x86/kernel/cpu/mce/inject.c | 2 +- > arch/x86/kernel/cpu/mce/intel.c | 18 +++++----- > arch/x86/kernel/cpu/mce/p5.c | 8 ++--- > arch/x86/kernel/cpu/mce/winchip.c | 2 +- > arch/x86/kernel/cpu/microcode/intel.c | 2 +- > arch/x86/kernel/cpu/mshyperv.c | 6 ++-- > arch/x86/kernel/cpu/mtrr/amd.c | 4 +-- > arch/x86/kernel/cpu/mtrr/cleanup.c | 4 +-- > arch/x86/kernel/cpu/mtrr/generic.c | 32 ++++++++--------- > arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +- > arch/x86/kernel/cpu/resctrl/core.c | 2 +- > arch/x86/kernel/cpu/resctrl/monitor.c | 4 +-- > arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 +-- > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +- > arch/x86/kernel/cpu/topology.c | 2 +- > arch/x86/kernel/cpu/topology_amd.c | 4 +-- > arch/x86/kernel/cpu/transmeta.c | 2 +- > arch/x86/kernel/cpu/tsx.c | 10 +++--- > arch/x86/kernel/cpu/umwait.c | 2 +- > arch/x86/kernel/cpu/zhaoxin.c | 4 +-- > arch/x86/kernel/fpu/core.c | 2 +- > arch/x86/kernel/hpet.c | 2 +- > arch/x86/kernel/kvm.c | 2 +- > arch/x86/kernel/mmconf-fam10h_64.c | 6 ++-- > arch/x86/kernel/process.c | 4 +-- > arch/x86/kernel/process_64.c | 14 ++++---- > arch/x86/kernel/shstk.c | 8 ++--- > arch/x86/kernel/traps.c | 4 +-- > arch/x86/kernel/tsc.c | 2 +- > arch/x86/kernel/tsc_msr.c | 6 ++-- > arch/x86/kernel/tsc_sync.c | 6 ++-- > arch/x86/kvm/msrs.c | 2 +- > arch/x86/kvm/svm/pmu.c | 4 +-- > arch/x86/kvm/svm/svm.c | 4 +-- > arch/x86/kvm/vmx/nested.c | 4 +-- > arch/x86/kvm/vmx/pmu_intel.c | 8 ++--- > arch/x86/kvm/vmx/sgx.c | 6 ++-- > arch/x86/kvm/vmx/vmx.c | 36 +++++++++---------- > arch/x86/kvm/x86.c | 6 ++-- > arch/x86/lib/insn-eval.c | 6 ++-- > arch/x86/lib/msr-smp.c | 2 +- > arch/x86/mm/pat/memtype.c | 2 +- > arch/x86/pci/amd_bus.c | 8 ++--- > arch/x86/platform/olpc/olpc-xo1-rtc.c | 6 ++-- > arch/x86/platform/olpc/olpc-xo1-sci.c | 2 +- > arch/x86/power/cpu.c | 10 +++--- > arch/x86/realmode/init.c | 2 +- > arch/x86/virt/hw.c | 8 ++--- > arch/x86/virt/svm/sev.c | 18 +++++----- > arch/x86/virt/vmx/tdx/tdx.c | 2 +- > arch/x86/xen/suspend.c | 2 +- > drivers/acpi/processor_perflib.c | 2 +- > drivers/ata/pata_cs5535.c | 4 +-- > drivers/ata/pata_cs5536.c | 2 +- > drivers/char/agp/nvidia-agp.c | 6 ++-- > drivers/char/hw_random/via-rng.c | 4 +-- > drivers/cpufreq/acpi-cpufreq.c | 8 ++--- > drivers/cpufreq/amd-pstate.c | 4 +-- > drivers/cpufreq/e_powersaver.c | 20 +++++------ > drivers/cpufreq/intel_pstate.c | 28 +++++++-------- > drivers/cpufreq/longhaul.c | 12 +++---- > drivers/cpufreq/longrun.c | 16 ++++----- > drivers/cpufreq/powernow-k7.c | 10 +++--- > drivers/cpufreq/powernow-k8.c | 8 ++--- > drivers/cpufreq/speedstep-centrino.c | 4 +-- > drivers/cpufreq/speedstep-lib.c | 14 ++++---- > drivers/edac/amd64_edac.c | 6 ++-- > drivers/gpio/gpio-cs5535.c | 2 +- > drivers/hv/mshv_vtl_main.c | 2 +- > drivers/hwmon/hwmon-vid.c | 4 +-- > drivers/idle/intel_idle.c | 26 +++++++------- > drivers/misc/cs5535-mfgpt.c | 6 ++-- > drivers/mtd/nand/raw/cs553x_nand.c | 6 ++-- > drivers/platform/x86/intel/ifs/load.c | 10 +++--- > drivers/platform/x86/intel/ifs/runtest.c | 8 ++--- > drivers/platform/x86/intel/pmc/cnp.c | 2 +- > .../intel/speed_select_if/isst_if_mbox_msr.c | 6 ++-- > .../intel/speed_select_if/isst_tpmi_core.c | 2 +- > drivers/platform/x86/intel_ips.c | 20 +++++------ > drivers/powercap/intel_rapl_msr.c | 2 +- > drivers/thermal/intel/intel_hfi.c | 8 ++--- > drivers/thermal/intel/therm_throt.c | 22 ++++++------ > drivers/thermal/intel/x86_pkg_temp_thermal.c | 6 ++-- > drivers/video/fbdev/geode/display_gx.c | 2 +- > drivers/video/fbdev/geode/gxfb_core.c | 2 +- > drivers/video/fbdev/geode/lxfb_ops.c | 18 +++++----- > drivers/video/fbdev/geode/suspend_gx.c | 8 ++--- > drivers/video/fbdev/geode/video_gx.c | 8 ++--- > include/linux/cs5535.h | 2 +- > 137 files changed, 483 insertions(+), 485 deletions(-) > > diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c > index cc292d7c6fd1..2a1875642cd4 100644 > --- a/arch/x86/coco/sev/core.c > +++ b/arch/x86/coco/sev/core.c > @@ -2026,7 +2026,7 @@ void __init snp_secure_tsc_init(void) > secrets =3D (__force struct snp_secrets_page *)mem; > > setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); > - rdmsrq(MSR_AMD64_GUEST_TSC_FREQ, tsc_freq_mhz); > + tsc_freq_mhz =3D rdmsrq(MSR_AMD64_GUEST_TSC_FREQ); > > /* Extract the GUEST TSC MHZ from BIT[17:0], rest is reserved spa= ce */ > tsc_freq_mhz &=3D GENMASK_ULL(17, 0); > diff --git a/arch/x86/events/amd/brs.c b/arch/x86/events/amd/brs.c > index dc564688f3d7..4df3a2a736e0 100644 > --- a/arch/x86/events/amd/brs.c > +++ b/arch/x86/events/amd/brs.c > @@ -325,7 +325,7 @@ void amd_brs_drain(void) > u32 brs_idx =3D tos - i; > u64 from, to; > > - rdmsrq(brs_to(brs_idx), to); > + to =3D rdmsrq(brs_to(brs_idx)); > > /* Entry does not belong to us (as marked by kernel) */ > if (to =3D=3D BRS_POISON) > @@ -338,7 +338,7 @@ void amd_brs_drain(void) > */ > to =3D (u64)(((s64)to << shift) >> shift); > > - rdmsrq(brs_from(brs_idx), from); > + from =3D rdmsrq(brs_from(brs_idx)); > > if (!amd_brs_match_plm(event, from, to)) > continue; > diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c > index 49b6b8fce566..80ed49dba255 100644 > --- a/arch/x86/events/amd/core.c > +++ b/arch/x86/events/amd/core.c > @@ -663,7 +663,7 @@ static inline u64 amd_pmu_get_global_status(void) > u64 status; > > /* PerfCntrGlobalStatus is read-only */ > - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, status); > + status =3D rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); > > return status; > } > @@ -683,7 +683,7 @@ static bool amd_pmu_test_overflow_topbit(int idx) > { > u64 counter; > > - rdmsrq(x86_pmu_event_addr(idx), counter); > + counter =3D rdmsrq(x86_pmu_event_addr(idx)); > > return !(counter & BIT_ULL(x86_pmu.cntval_bits - 1)); > } > diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c > index 3531f9c23b8c..17eab32164df 100644 > --- a/arch/x86/events/amd/ibs.c > +++ b/arch/x86/events/amd/ibs.c > @@ -505,7 +505,7 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs, stru= ct perf_event *event, > * prev count manually on overflow. > */ > while (!perf_event_try_update(event, count, 64)) { > - rdmsrq(event->hw.config_base, *config); > + *config =3D rdmsrq(event->hw.config_base); > count =3D perf_ibs->get_count(*config); > } > } > @@ -610,7 +610,7 @@ static void perf_ibs_stop(struct perf_event *event, i= nt flags) > if (!stopping && (hwc->state & PERF_HES_UPTODATE)) > return; > > - rdmsrq(hwc->config_base, config); > + config =3D rdmsrq(hwc->config_base); > > if (stopping) { > /* > @@ -1437,7 +1437,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *per= f_ibs, struct pt_regs *iregs) > hwc =3D &event->hw; > msr =3D hwc->config_base; > buf =3D ibs_data.regs; > - rdmsrq(msr, *buf); > + *buf =3D rdmsrq(msr); > if (!(*buf++ & perf_ibs->valid_mask)) > goto fail; > > @@ -1455,7 +1455,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *per= f_ibs, struct pt_regs *iregs) > offset_max =3D perf_ibs_get_offset_max(perf_ibs, event, check_rip= ); > > do { > - rdmsrq(msr + offset, *buf++); > + *buf++ =3D rdmsrq(msr + offset); > size++; > offset =3D find_next_bit(perf_ibs->offset_mask, > perf_ibs->offset_max, > @@ -1497,17 +1497,17 @@ static int perf_ibs_handle_irq(struct perf_ibs *p= erf_ibs, struct pt_regs *iregs) > if (event->attr.sample_type & PERF_SAMPLE_RAW) { > if (perf_ibs =3D=3D &perf_ibs_op) { > if (ibs_caps & IBS_CAPS_BRNTRGT) { > - rdmsrq(MSR_AMD64_IBSBRTARGET, *buf++); > + *buf++ =3D rdmsrq(MSR_AMD64_IBSBRTARGET); > br_target_idx =3D size; > size++; > } > if (ibs_caps & IBS_CAPS_OPDATA4) { > - rdmsrq(MSR_AMD64_IBSOPDATA4, *buf++); > + *buf++ =3D rdmsrq(MSR_AMD64_IBSOPDATA4); > size++; > } > } > if (perf_ibs =3D=3D &perf_ibs_fetch && (ibs_caps & IBS_CA= PS_FETCHCTLEXTD)) { > - rdmsrq(MSR_AMD64_ICIBSEXTDCTL, *buf++); > + *buf++ =3D rdmsrq(MSR_AMD64_ICIBSEXTDCTL); > size++; > } > } > @@ -1768,7 +1768,7 @@ static inline int ibs_eilvt_valid(void) > > preempt_disable(); > > - rdmsrq(MSR_AMD64_IBSCTL, val); > + val =3D rdmsrq(MSR_AMD64_IBSCTL); > offset =3D val & IBSCTL_LVT_OFFSET_MASK; > > if (!(val & IBSCTL_LVT_OFFSET_VALID)) { > @@ -1883,7 +1883,7 @@ static inline int get_ibs_lvt_offset(void) > { > u64 val; > > - rdmsrq(MSR_AMD64_IBSCTL, val); > + val =3D rdmsrq(MSR_AMD64_IBSCTL); > if (!(val & IBSCTL_LVT_OFFSET_VALID)) > return -EINVAL; > > diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c > index 9d9c961989d5..29628af6a023 100644 > --- a/arch/x86/events/amd/lbr.c > +++ b/arch/x86/events/amd/lbr.c > @@ -76,7 +76,7 @@ static __always_inline u64 amd_pmu_lbr_get_from(unsigne= d int idx) > { > u64 val; > > - rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2, val); > + val =3D rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2); > > return val; > } > @@ -85,7 +85,7 @@ static __always_inline u64 amd_pmu_lbr_get_to(unsigned = int idx) > { > u64 val; > > - rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2 + 1, val); > + val =3D rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2 + 1); > > return val; > } > @@ -404,11 +404,11 @@ void amd_pmu_lbr_enable_all(void) > } > > if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) { > - rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl); > + dbg_ctl =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE= _LBRS_ON_PMI); > } > > - rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg); > + dbg_extn_cfg =3D rdmsrq(MSR_AMD_DBG_EXTN_CFG); > wrmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg | DBG_EXTN_CFG_LBRV2EN)= ; > } > > diff --git a/arch/x86/events/amd/power.c b/arch/x86/events/amd/power.c > index 66197214b010..5a5ebce0a526 100644 > --- a/arch/x86/events/amd/power.c > +++ b/arch/x86/events/amd/power.c > @@ -52,8 +52,8 @@ static void event_update(struct perf_event *event) > > prev_pwr_acc =3D hwc->pwr_acc; > prev_ptsc =3D hwc->ptsc; > - rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR, new_pwr_acc); > - rdmsrq(MSR_F15H_PTSC, new_ptsc); > + new_pwr_acc =3D rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR); > + new_ptsc =3D rdmsrq(MSR_F15H_PTSC); > > /* > * Calculate the CU power consumption over a time period, the uni= t of > @@ -79,8 +79,8 @@ static void __pmu_event_start(struct perf_event *event) > > event->hw.state =3D 0; > > - rdmsrq(MSR_F15H_PTSC, event->hw.ptsc); > - rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR, event->hw.pwr_acc); > + event->hw.ptsc =3D rdmsrq(MSR_F15H_PTSC); > + event->hw.pwr_acc =3D rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR); > } > > static void pmu_event_start(struct perf_event *event, int mode) > diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c > index 7181973b5b12..35f0c4831919 100644 > --- a/arch/x86/events/amd/uncore.c > +++ b/arch/x86/events/amd/uncore.c > @@ -151,7 +151,7 @@ static void amd_uncore_read(struct perf_event *event) > * read counts directly from the corresponding PERF_CTR. > */ > if (hwc->event_base_rdpmc < 0) > - rdmsrq(hwc->event_base, new); > + new =3D rdmsrq(hwc->event_base); > else > new =3D rdpmc(hwc->event_base_rdpmc); > > @@ -998,7 +998,7 @@ static void amd_uncore_umc_read(struct perf_event *ev= ent) > * UMC counters do not have RDPMC assignments. Read counts direct= ly > * from the corresponding PERF_CTR. > */ > - rdmsrq(hwc->event_base, new); > + new =3D rdmsrq(hwc->event_base); > > /* > * Unlike the other uncore counters, UMC counters saturate and se= t the > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c > index 8b3ea0adb965..34bd80bb2c9e 100644 > --- a/arch/x86/events/core.c > +++ b/arch/x86/events/core.c > @@ -711,7 +711,7 @@ void x86_pmu_disable_all(void) > > if (!test_bit(idx, cpuc->active_mask)) > continue; > - rdmsrq(x86_pmu_config_addr(idx), val); > + val =3D rdmsrq(x86_pmu_config_addr(idx)); > if (!(val & ARCH_PERFMON_EVENTSEL_ENABLE)) > continue; > val &=3D ~ARCH_PERFMON_EVENTSEL_ENABLE; > @@ -1592,10 +1592,10 @@ void perf_event_print_debug(void) > return; > > if (x86_pmu.version >=3D 2) { > - rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL, ctrl); > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); > - rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, overflow); > - rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL, fixed); > + ctrl =3D rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL); > + status =3D rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > + overflow =3D rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL); > + fixed =3D rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL); > > pr_info("\n"); > pr_info("CPU#%d: ctrl: %016llx\n", cpu, ctrl); > @@ -1603,19 +1603,19 @@ void perf_event_print_debug(void) > pr_info("CPU#%d: overflow: %016llx\n", cpu, overflow); > pr_info("CPU#%d: fixed: %016llx\n", cpu, fixed); > if (pebs_constraints) { > - rdmsrq(MSR_IA32_PEBS_ENABLE, pebs); > + pebs =3D rdmsrq(MSR_IA32_PEBS_ENABLE); > pr_info("CPU#%d: pebs: %016llx\n", cpu, peb= s); > } > if (x86_pmu.lbr_nr) { > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > pr_info("CPU#%d: debugctl: %016llx\n", cpu, deb= ugctl); > } > } > pr_info("CPU#%d: active: %016llx\n", cpu, *(u64 *)cpuc->activ= e_mask); > > for_each_set_bit(idx, cntr_mask, X86_PMC_IDX_MAX) { > - rdmsrq(x86_pmu_config_addr(idx), pmc_ctrl); > - rdmsrq(x86_pmu_event_addr(idx), pmc_count); > + pmc_ctrl =3D rdmsrq(x86_pmu_config_addr(idx)); > + pmc_count =3D rdmsrq(x86_pmu_event_addr(idx)); > > prev_left =3D per_cpu(pmc_prev_left[idx], cpu); > > @@ -1627,7 +1627,7 @@ void perf_event_print_debug(void) > cpu, idx, prev_left); > } > for_each_set_bit(idx, fixed_cntr_mask, X86_PMC_IDX_MAX) { > - rdmsrq(x86_pmu_fixed_ctr_addr(idx), pmc_count); > + pmc_count =3D rdmsrq(x86_pmu_fixed_ctr_addr(idx)); > > pr_info("CPU#%d: fixed-PMC%d count: %016llx\n", > cpu, idx, pmc_count); > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c > index cc13164d948f..41ae90b6bbdc 100644 > --- a/arch/x86/events/intel/core.c > +++ b/arch/x86/events/intel/core.c > @@ -2965,7 +2965,7 @@ static inline u64 intel_pmu_get_status(void) > { > u64 status; > > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); > + status =3D rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > > return status; > } > @@ -3494,7 +3494,7 @@ static void intel_pmu_enable_event_ext(struct perf_= event *event) > else > new.thresh =3D ARCH_PEBS_THRESH_SINGLE; > > - rdmsrq(MSR_IA32_PEBS_INDEX, old.whole); > + old.whole =3D rdmsrq(MSR_IA32_PEBS_INDEX); > if (new.thresh !=3D old.thresh || !old.en) { > if (old.thresh =3D=3D ARCH_PEBS_THRESH_MULTI && o= ld.wr > 0) { > /* > @@ -6255,8 +6255,7 @@ static void intel_update_pmu_caps(struct pmu *pmu) > update_pmu_cap_from_perfmonext(pmu); > > if (is_hybrid() && this_cpu_has(X86_FEATURE_PDCM)) { > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, > - hybrid(pmu, intel_cap).capabilities); > + hybrid(pmu, intel_cap).capabilities =3D rdmsrq(MSR_IA32_P= ERF_CAPABILITIES); > > /* > * Restore perf_metrics on platforms with broken > @@ -6412,7 +6411,7 @@ static void intel_pmu_cpu_starting(int cpu) > if (!is_hybrid() && x86_pmu.intel_cap.perf_metrics) { > union perf_capabilities perf_cap; > > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, perf_cap.capabilities)= ; > + perf_cap.capabilities =3D rdmsrq(MSR_IA32_PERF_CAPABILITI= ES); > if (!perf_cap.perf_metrics) { > x86_pmu.intel_cap.perf_metrics =3D 0; > x86_pmu.intel_ctrl &=3D ~GLOBAL_CTRL_EN_PERF_METR= ICS; > @@ -7959,7 +7958,7 @@ __init int intel_pmu_init(void) > if (boot_cpu_has(X86_FEATURE_PDCM)) { > u64 capabilities; > > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, capabilities); > + capabilities =3D rdmsrq(MSR_IA32_PERF_CAPABILITIES); > x86_pmu.intel_cap.capabilities =3D capabilities; > } > > diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstat= e.c > index f3d5ee07f8f2..69eb6cf51d3b 100644 > --- a/arch/x86/events/intel/cstate.c > +++ b/arch/x86/events/intel/cstate.c > @@ -324,7 +324,7 @@ static inline u64 cstate_pmu_read_counter(struct perf= _event *event) > { > u64 val; > > - rdmsrq(event->hw.event_base, val); > + val =3D rdmsrq(event->hw.event_base); > return val; > } > > diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c > index 8940f0292229..ffe4f84c411d 100644 > --- a/arch/x86/events/intel/ds.c > +++ b/arch/x86/events/intel/ds.c > @@ -3231,7 +3231,7 @@ static void intel_pmu_drain_arch_pebs(struct pt_reg= s *iregs, > void *base, *at, *top; > u64 mask; > > - rdmsrq(MSR_IA32_PEBS_INDEX, index.whole); > + index.whole =3D rdmsrq(MSR_IA32_PEBS_INDEX); > > if (unlikely(!index.wr)) { > intel_pmu_pebs_event_update_no_drain(cpuc, X86_PMC_IDX_MA= X); > diff --git a/arch/x86/events/intel/knc.c b/arch/x86/events/intel/knc.c > index e887adc108ac..c4f81215f758 100644 > --- a/arch/x86/events/intel/knc.c > +++ b/arch/x86/events/intel/knc.c > @@ -160,7 +160,7 @@ static void knc_pmu_disable_all(void) > { > u64 val; > > - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); > + val =3D rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL); > val &=3D ~(KNC_ENABLE_COUNTER0|KNC_ENABLE_COUNTER1); > wrmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); > } > @@ -169,7 +169,7 @@ static void knc_pmu_enable_all(int added) > { > u64 val; > > - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); > + val =3D rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL); > val |=3D (KNC_ENABLE_COUNTER0|KNC_ENABLE_COUNTER1); > wrmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); > } > @@ -201,7 +201,7 @@ static inline u64 knc_pmu_get_status(void) > { > u64 status; > > - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_STATUS, status); > + status =3D rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_STATUS); > > return status; > } > diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c > index cbe5c762008d..fc05ec3b9a99 100644 > --- a/arch/x86/events/intel/lbr.c > +++ b/arch/x86/events/intel/lbr.c > @@ -141,7 +141,7 @@ static void __intel_pmu_lbr_enable(bool pmi) > if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR) && !pmi && cpuc->l= br_sel) > wrmsrq(MSR_LBR_SELECT, lbr_select); > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > orig_debugctl =3D debugctl; > > if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR)) > @@ -211,7 +211,7 @@ static inline u64 intel_pmu_lbr_tos(void) > { > u64 tos; > > - rdmsrq(x86_pmu.lbr_tos, tos); > + tos =3D rdmsrq(x86_pmu.lbr_tos); > return tos; > } > > @@ -304,7 +304,7 @@ static __always_inline u64 rdlbr_from(unsigned int id= x, struct lbr_entry *lbr) > if (lbr) > return lbr->from; > > - rdmsrq(x86_pmu.lbr_from + idx, val); > + val =3D rdmsrq(x86_pmu.lbr_from + idx); > > return lbr_from_signext_quirk_rd(val); > } > @@ -316,7 +316,7 @@ static __always_inline u64 rdlbr_to(unsigned int idx,= struct lbr_entry *lbr) > if (lbr) > return lbr->to; > > - rdmsrq(x86_pmu.lbr_to + idx, val); > + val =3D rdmsrq(x86_pmu.lbr_to + idx); > > return val; > } > @@ -328,7 +328,7 @@ static __always_inline u64 rdlbr_info(unsigned int id= x, struct lbr_entry *lbr) > if (lbr) > return lbr->info; > > - rdmsrq(x86_pmu.lbr_info + idx, val); > + val =3D rdmsrq(x86_pmu.lbr_info + idx); > > return val; > } > @@ -477,7 +477,7 @@ void intel_pmu_lbr_save(void *ctx) > task_ctx->tos =3D tos; > > if (cpuc->lbr_select) > - rdmsrq(MSR_LBR_SELECT, task_ctx->lbr_sel); > + task_ctx->lbr_sel =3D rdmsrq(MSR_LBR_SELECT); > } > > static void intel_pmu_arch_lbr_save(void *ctx) > @@ -754,7 +754,7 @@ void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc= ) > u64 lbr; > } msr_lastbranch; > > - rdmsrq(x86_pmu.lbr_from + lbr_idx, msr_lastbranch.lbr); > + msr_lastbranch.lbr =3D rdmsrq(x86_pmu.lbr_from + lbr_idx)= ; > > perf_clear_branch_entry_bitfields(br); > > diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c > index 5368dc31787c..e675e85682f1 100644 > --- a/arch/x86/events/intel/p4.c > +++ b/arch/x86/events/intel/p4.c > @@ -860,7 +860,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_per= f_event *hwc) > u64 v; > > /* an official way for overflow indication */ > - rdmsrq(hwc->config_base, v); > + v =3D rdmsrq(hwc->config_base); > if (v & P4_CCCR_OVF) { > wrmsrq(hwc->config_base, v & ~P4_CCCR_OVF); > return 1; > @@ -873,7 +873,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_per= f_event *hwc) > * the counter has reached zero value and continued counting befo= re > * real NMI signal was received: > */ > - rdmsrq(hwc->event_base, v); > + v =3D rdmsrq(hwc->event_base); > if (!(v & ARCH_P4_UNFLAGGED_BIT)) > return 1; > > @@ -1373,7 +1373,7 @@ __init int p4_pmu_init(void) > /* If we get stripped -- indexing fails */ > BUILD_BUG_ON(ARCH_P4_MAX_CCCR > INTEL_PMC_MAX_GENERIC); > > - rdmsrq(MSR_IA32_MISC_ENABLE, misc); > + misc =3D rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(misc & MSR_IA32_MISC_ENABLE_EMON)) { > pr_cont("unsupported Netburst CPU model %d ", > boot_cpu_data.x86_model); > diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c > index fb991e0ac614..4268b576b5d8 100644 > --- a/arch/x86/events/intel/p6.c > +++ b/arch/x86/events/intel/p6.c > @@ -143,7 +143,7 @@ static void p6_pmu_disable_all(void) > u64 val; > > /* p6 only has one enable register */ > - rdmsrq(MSR_P6_EVNTSEL0, val); > + val =3D rdmsrq(MSR_P6_EVNTSEL0); > val &=3D ~ARCH_PERFMON_EVENTSEL_ENABLE; > wrmsrq(MSR_P6_EVNTSEL0, val); > } > @@ -153,7 +153,7 @@ static void p6_pmu_enable_all(int added) > unsigned long val; > > /* p6 only has one enable register */ > - rdmsrq(MSR_P6_EVNTSEL0, val); > + val =3D rdmsrq(MSR_P6_EVNTSEL0); > val |=3D ARCH_PERFMON_EVENTSEL_ENABLE; > wrmsrq(MSR_P6_EVNTSEL0, val); > } > diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c > index 5754cd405562..d595d69b49a1 100644 > --- a/arch/x86/events/intel/pt.c > +++ b/arch/x86/events/intel/pt.c > @@ -196,7 +196,7 @@ static int __init pt_pmu_hw_init(void) > int ret; > long i; > > - rdmsrq(MSR_PLATFORM_INFO, reg); > + reg =3D rdmsrq(MSR_PLATFORM_INFO); > pt_pmu.max_nonturbo_ratio =3D (reg & 0xff00) >> 8; > > /* > @@ -232,7 +232,7 @@ static int __init pt_pmu_hw_init(void) > * "IA32_VMX_MISC[bit 14]" being 1 means PT can trace > * post-VMXON. > */ > - rdmsrq(MSR_IA32_VMX_MISC, reg); > + reg =3D rdmsrq(MSR_IA32_VMX_MISC); > if (reg & BIT(14)) > pt_pmu.vmx =3D true; > } > @@ -935,7 +935,7 @@ static void pt_handle_status(struct pt *pt) > int advance =3D 0; > u64 status; > > - rdmsrq(MSR_IA32_RTIT_STATUS, status); > + status =3D rdmsrq(MSR_IA32_RTIT_STATUS); > > if (status & RTIT_STATUS_ERROR) { > pr_err_ratelimited("ToPA ERROR encountered, trying to rec= over\n"); > @@ -994,12 +994,12 @@ static void pt_read_offset(struct pt_buffer *buf) > struct topa_page *tp; > > if (!buf->single) { > - rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE, pt->output_base); > + pt->output_base =3D rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE); > tp =3D phys_to_virt(pt->output_base); > buf->cur =3D &tp->topa; > } > > - rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK, pt->output_mask); > + pt->output_mask =3D rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK); > /* offset within current output region */ > buf->output_off =3D pt->output_mask >> 32; > /* index of current output region within this table */ > @@ -1623,7 +1623,7 @@ static void pt_event_start(struct perf_event *event= , int mode) > * PMI might have just cleared these, so resume_a= llowed > * must be checked again also. > */ > - rdmsrq(MSR_IA32_RTIT_STATUS, status); > + status =3D rdmsrq(MSR_IA32_RTIT_STATUS); > if (!(status & (RTIT_STATUS_TRIGGEREN | > RTIT_STATUS_ERROR | > RTIT_STATUS_STOPPED)) && > diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncor= e.c > index b2109b37ea7f..ab2c5a962b31 100644 > --- a/arch/x86/events/intel/uncore.c > +++ b/arch/x86/events/intel/uncore.c > @@ -171,7 +171,7 @@ u64 uncore_msr_read_counter(struct intel_uncore_box *= box, struct perf_event *eve > { > u64 count; > > - rdmsrq(event->hw.event_base, count); > + count =3D rdmsrq(event->hw.event_base); > > return count; > } > diff --git a/arch/x86/events/intel/uncore_nhmex.c b/arch/x86/events/intel= /uncore_nhmex.c > index 7a6855281102..81e838e6f729 100644 > --- a/arch/x86/events/intel/uncore_nhmex.c > +++ b/arch/x86/events/intel/uncore_nhmex.c > @@ -216,7 +216,7 @@ static void nhmex_uncore_msr_disable_box(struct intel= _uncore_box *box) > u64 config; > > if (msr) { > - rdmsrq(msr, config); > + config =3D rdmsrq(msr); > config &=3D ~((1ULL << uncore_num_counters(box)) - 1); > /* WBox has a fixed counter */ > if (uncore_msr_fixed_ctl(box)) > @@ -231,7 +231,7 @@ static void nhmex_uncore_msr_enable_box(struct intel_= uncore_box *box) > u64 config; > > if (msr) { > - rdmsrq(msr, config); > + config =3D rdmsrq(msr); > config |=3D (1ULL << uncore_num_counters(box)) - 1; > /* WBox has a fixed counter */ > if (uncore_msr_fixed_ctl(box)) > diff --git a/arch/x86/events/intel/uncore_snb.c b/arch/x86/events/intel/u= ncore_snb.c > index 055131c508ff..da864724ff20 100644 > --- a/arch/x86/events/intel/uncore_snb.c > +++ b/arch/x86/events/intel/uncore_snb.c > @@ -533,7 +533,7 @@ static int icl_get_cbox_num(void) > { > u64 num_boxes; > > - rdmsrq(ICL_UNC_CBO_CONFIG, num_boxes); > + num_boxes =3D rdmsrq(ICL_UNC_CBO_CONFIG); > > return num_boxes & ICL_UNC_NUM_CBO_MASK; > } > diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel= /uncore_snbep.c > index a97cd029db36..490725c8fee1 100644 > --- a/arch/x86/events/intel/uncore_snbep.c > +++ b/arch/x86/events/intel/uncore_snbep.c > @@ -642,7 +642,7 @@ static void snbep_uncore_msr_disable_box(struct intel= _uncore_box *box) > > msr =3D uncore_msr_box_ctl(box); > if (msr) { > - rdmsrq(msr, config); > + config =3D rdmsrq(msr); > config |=3D SNBEP_PMON_BOX_CTL_FRZ; > wrmsrq(msr, config); > } > @@ -655,7 +655,7 @@ static void snbep_uncore_msr_enable_box(struct intel_= uncore_box *box) > > msr =3D uncore_msr_box_ctl(box); > if (msr) { > - rdmsrq(msr, config); > + config =3D rdmsrq(msr); > config &=3D ~SNBEP_PMON_BOX_CTL_FRZ; > wrmsrq(msr, config); > } > @@ -6370,7 +6370,7 @@ void spr_uncore_cpu_init(void) > * of UNCORE_SPR_CHA) is incorrect on some SPR variants b= ecause of a > * firmware bug. Using the value from SPR_MSR_UNC_CBO_CON= FIG to replace it. > */ > - rdmsrq(SPR_MSR_UNC_CBO_CONFIG, num_cbo); > + num_cbo =3D rdmsrq(SPR_MSR_UNC_CBO_CONFIG); > /* > * The MSR doesn't work on the EMR XCC, but the firmware = bug doesn't impact > * the EMR XCC. Don't let the value from the MSR replace = the existing value. > diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c > index 76d6418c5055..0e59781549ca 100644 > --- a/arch/x86/events/msr.c > +++ b/arch/x86/events/msr.c > @@ -158,7 +158,7 @@ static inline u64 msr_read_counter(struct perf_event = *event) > u64 now; > > if (event->hw.event_base) > - rdmsrq(event->hw.event_base, now); > + now =3D rdmsrq(event->hw.event_base); > else > now =3D rdtsc_ordered(); > > diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h > index 71ed5b2acea2..4abdb9475e8f 100644 > --- a/arch/x86/events/perf_event.h > +++ b/arch/x86/events/perf_event.h > @@ -1475,11 +1475,11 @@ static __always_inline void __amd_pmu_lbr_disable= (void) > { > u64 dbg_ctl, dbg_extn_cfg; > > - rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg); > + dbg_extn_cfg =3D rdmsrq(MSR_AMD_DBG_EXTN_CFG); > wrmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg & ~DBG_EXTN_CFG_LBRV2EN= ); > > if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) { > - rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl); > + dbg_ctl =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl & ~DEBUGCTLMSR_FREEZ= E_LBRS_ON_PMI); > } > } > @@ -1633,7 +1633,7 @@ static __always_inline void __intel_pmu_lbr_disable= (void) > { > u64 debugctl; > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > debugctl &=3D ~(DEBUGCTLMSR_LBR | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI)= ; > wrmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > } > diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c > index 8ed03c32f560..180cc18282ca 100644 > --- a/arch/x86/events/rapl.c > +++ b/arch/x86/events/rapl.c > @@ -193,7 +193,7 @@ static inline unsigned int get_rapl_pmu_idx(int cpu, = int scope) > static inline u64 rapl_read_counter(struct perf_event *event) > { > u64 raw; > - rdmsrq(event->hw.event_base, raw); > + raw =3D rdmsrq(event->hw.event_base); > return raw; > } > > @@ -222,7 +222,7 @@ static u64 rapl_event_update(struct perf_event *event= ) > > prev_raw_count =3D local64_read(&hwc->prev_count); > do { > - rdmsrq(event->hw.event_base, new_raw_count); > + new_raw_count =3D rdmsrq(event->hw.event_base); > } while (!local64_try_cmpxchg(&hwc->prev_count, > &prev_raw_count, new_raw_count)); > > diff --git a/arch/x86/events/zhaoxin/core.c b/arch/x86/events/zhaoxin/cor= e.c > index e506f677db57..1980e5995e27 100644 > --- a/arch/x86/events/zhaoxin/core.c > +++ b/arch/x86/events/zhaoxin/core.c > @@ -268,7 +268,7 @@ static inline u64 zhaoxin_pmu_get_status(void) > { > u64 status; > > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); > + status =3D rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > > return status; > } > @@ -295,7 +295,7 @@ static void zhaoxin_pmu_disable_fixed(struct hw_perf_= event *hwc) > > mask =3D 0xfULL << (idx * 4); > > - rdmsrq(hwc->config_base, ctrl_val); > + ctrl_val =3D rdmsrq(hwc->config_base); > ctrl_val &=3D ~mask; > wrmsrq(hwc->config_base, ctrl_val); > } > @@ -331,7 +331,7 @@ static void zhaoxin_pmu_enable_fixed(struct hw_perf_e= vent *hwc) > bits <<=3D (idx * 4); > mask =3D 0xfULL << (idx * 4); > > - rdmsrq(hwc->config_base, ctrl_val); > + ctrl_val =3D rdmsrq(hwc->config_base); > ctrl_val &=3D ~mask; > ctrl_val |=3D bits; > wrmsrq(hwc->config_base, ctrl_val); > diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c > index 95f1782d1e17..4e30f9a11bc4 100644 > --- a/arch/x86/hyperv/hv_apic.c > +++ b/arch/x86/hyperv/hv_apic.c > @@ -38,7 +38,7 @@ static u64 hv_apic_icr_read(void) > { > u64 reg_val; > > - rdmsrq(HV_X64_MSR_ICR, reg_val); > + reg_val =3D rdmsrq(HV_X64_MSR_ICR); > return reg_val; > } > > @@ -64,10 +64,10 @@ static u32 hv_apic_read(u32 reg) > > switch (reg) { > case APIC_EOI: > - rdmsrq(HV_X64_MSR_EOI, reg_val.q); > + reg_val.q =3D rdmsrq(HV_X64_MSR_EOI); > return reg_val.l; > case APIC_TASKPRI: > - rdmsrq(HV_X64_MSR_TPR, reg_val.q); > + reg_val.q =3D rdmsrq(HV_X64_MSR_TPR); > return reg_val.l; > > default: > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c > index 0b4a1c0b0b16..672a9656446e 100644 > --- a/arch/x86/hyperv/hv_init.c > +++ b/arch/x86/hyperv/hv_init.c > @@ -101,7 +101,7 @@ static int hyperv_init_ghcb(void) > * returned by MSR_AMD64_SEV_ES_GHCB is above shared > * memory boundary and map it here. > */ > - rdmsrq(MSR_AMD64_SEV_ES_GHCB, ghcb_gpa); > + ghcb_gpa =3D rdmsrq(MSR_AMD64_SEV_ES_GHCB); > > /* Mask out vTOM bit and map as decrypted */ > ghcb_gpa &=3D ~ms_hyperv.shared_gpa_boundary; > @@ -134,7 +134,7 @@ static int hv_cpu_init(unsigned int cpu) > * For root partition we get the hypervisor provided VP a= ssist > * page, instead of allocating a new page. > */ > - rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); > + msr.as_uint64 =3D rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE); > *hvp =3D memremap(msr.pfn << HV_X64_MSR_VP_ASSIST_PAGE_AD= DRESS_SHIFT, > PAGE_SIZE, MEMREMAP_WB); > } else { > @@ -182,7 +182,7 @@ static void hv_reenlightenment_notify(struct work_str= uct *dummy) > { > struct hv_tsc_emulation_status emu_status; > > - rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); > + *(u64 *)&emu_status =3D rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS); > > /* Don't issue the callback if TSC accesses are not emulated */ > if (hv_reenlightenment_cb && emu_status.inprogress) > @@ -195,11 +195,11 @@ void hyperv_stop_tsc_emulation(void) > u64 freq; > struct hv_tsc_emulation_status emu_status; > > - rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); > + *(u64 *)&emu_status =3D rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS); > emu_status.inprogress =3D 0; > wrmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); > > - rdmsrq(HV_X64_MSR_TSC_FREQUENCY, freq); > + freq =3D rdmsrq(HV_X64_MSR_TSC_FREQUENCY); > tsc_khz =3D div64_u64(freq, 1000); > } > EXPORT_SYMBOL_GPL(hyperv_stop_tsc_emulation); > @@ -259,7 +259,7 @@ void clear_hv_tscchange_cb(void) > if (!hv_reenlightenment_available()) > return; > > - rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *(u64 *)&re_ctrl); > + *(u64 *)&re_ctrl =3D rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL); > re_ctrl.enabled =3D 0; > wrmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *(u64 *)&re_ctrl); > > @@ -295,7 +295,7 @@ static int hv_cpu_die(unsigned int cpu) > */ > memunmap(hv_vp_assist_page[cpu]); > hv_vp_assist_page[cpu] =3D NULL; > - rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); > + msr.as_uint64 =3D rdmsrq(HV_X64_MSR_VP_ASSIST_PAG= E); > msr.enable =3D 0; > } > wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); > @@ -304,7 +304,7 @@ static int hv_cpu_die(unsigned int cpu) > if (hv_reenlightenment_cb =3D=3D NULL) > return 0; > > - rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl)); > + *((u64 *)&re_ctrl) =3D rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL)= ; > if (re_ctrl.target_vp =3D=3D hv_vp_index[cpu]) { > /* > * Reassign reenlightenment notifications to some other o= nline > @@ -375,7 +375,7 @@ static int hv_suspend(void *data) > hv_set_hypercall_pg(NULL); > > /* Disable the hypercall page in the hypervisor */ > - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.as_uint64 =3D rdmsrq(HV_X64_MSR_HYPERCALL); > hypercall_msr.enable =3D 0; > wrmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > > @@ -392,7 +392,7 @@ static void hv_resume(void *data) > WARN_ON(ret); > > /* Re-enable the hypercall page */ > - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.as_uint64 =3D rdmsrq(HV_X64_MSR_HYPERCALL); > hypercall_msr.enable =3D 1; > hypercall_msr.guest_physical_address =3D > vmalloc_to_pfn(hv_hypercall_pg_saved); > @@ -530,7 +530,7 @@ void __init hyperv_init(void) > if (hv_hypercall_pg =3D=3D NULL) > goto clean_guest_os_id; > > - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.as_uint64 =3D rdmsrq(HV_X64_MSR_HYPERCALL); > hypercall_msr.enable =3D 1; > > if (hv_root_partition()) { > @@ -672,7 +672,7 @@ void hyperv_report_panic(struct pt_regs *regs, long e= rr, bool in_die) > return; > panic_reported =3D true; > > - rdmsrq(HV_X64_MSR_GUEST_OS_ID, guest_id); > + guest_id =3D rdmsrq(HV_X64_MSR_GUEST_OS_ID); > > wrmsrq(HV_X64_MSR_CRASH_P0, err); > wrmsrq(HV_X64_MSR_CRASH_P1, guest_id); > @@ -706,7 +706,7 @@ bool hv_is_hyperv_initialized(void) > * that the hypercall page is setup > */ > hypercall_msr.as_uint64 =3D 0; > - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.as_uint64 =3D rdmsrq(HV_X64_MSR_HYPERCALL); > > return hypercall_msr.enable; > } > diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.= c > index 6b4bdea18218..7ef2d794e2e8 100644 > --- a/arch/x86/hyperv/hv_spinlock.c > +++ b/arch/x86/hyperv/hv_spinlock.c > @@ -50,7 +50,7 @@ static void hv_qlock_wait(u8 *byte, u8 val) > if (READ_ONCE(*byte) =3D=3D val) { > unsigned long msr_val; > > - rdmsrq(HV_X64_MSR_GUEST_IDLE, msr_val); > + msr_val =3D rdmsrq(HV_X64_MSR_GUEST_IDLE); > > (void)msr_val; > } > diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h > index 9cd493d467d4..e028140fac49 100644 > --- a/arch/x86/include/asm/apic.h > +++ b/arch/x86/include/asm/apic.h > @@ -220,7 +220,7 @@ static inline u32 native_apic_msr_read(u32 reg) > if (reg =3D=3D APIC_DFR) > return -1; > > - rdmsrq(APIC_BASE_MSR + (reg >> 4), msr); > + msr =3D rdmsrq(APIC_BASE_MSR + (reg >> 4)); > return (u32)msr; > } > > @@ -233,7 +233,7 @@ static inline u64 native_x2apic_icr_read(void) > { > unsigned long val; > > - rdmsrq(APIC_BASE_MSR + (APIC_ICR >> 4), val); > + val =3D rdmsrq(APIC_BASE_MSR + (APIC_ICR >> 4)); > return val; > } > > diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debug= reg.h > index 854d82b88ff4..60a3df32a4d3 100644 > --- a/arch/x86/include/asm/debugreg.h > +++ b/arch/x86/include/asm/debugreg.h > @@ -180,7 +180,7 @@ static inline unsigned long get_debugctlmsr(void) > if (boot_cpu_data.x86 < 6) > return 0; > #endif > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctlmsr); > + debugctlmsr =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > > return debugctlmsr; > } > diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsb= ase.h > index 70ff4ef457b1..9de49d732e9e 100644 > --- a/arch/x86/include/asm/fsgsbase.h > +++ b/arch/x86/include/asm/fsgsbase.h > @@ -60,7 +60,7 @@ static inline unsigned long x86_fsbase_read_cpu(void) > if (boot_cpu_has(X86_FEATURE_FSGSBASE)) > fsbase =3D rdfsbase(); > else > - rdmsrq(MSR_FS_BASE, fsbase); > + fsbase =3D rdmsrq(MSR_FS_BASE); > > return fsbase; > } > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_h= ost.h > index 683bb8bf43a9..b7887dccb829 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -1862,7 +1862,7 @@ static inline unsigned long read_msr(unsigned long = msr) > { > u64 value; > > - rdmsrq(msr, value); > + value =3D rdmsrq(msr); > return value; > } > #endif > diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h > index 6d7bab33af71..95761803c2e6 100644 > --- a/arch/x86/include/asm/msr.h > +++ b/arch/x86/include/asm/msr.h > @@ -173,14 +173,13 @@ static inline u64 native_read_pmc(int counter) > #include > #else > #include > -/* > - * Access to machine-specific registers (available on 586 and better onl= y) > - * Note: the rd* operations modify the parameters directly (without usin= g > - * pointer indirection), this allows gcc to optimize better > - */ > > -#define rdmsrq(msr, val) \ > - ((val) =3D native_read_msr((msr))) > +/* Access to machine-specific registers (available on 586 and better onl= y) */ > + > +static __always_inline u64 rdmsrq(u32 msr) > +{ > + return native_read_msr(msr); > +} > > static inline void wrmsrq(u32 msr, u64 val) > { > @@ -237,7 +236,7 @@ int wrmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs= [8]); > #else /* CONFIG_SMP */ > static inline int rdmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 *q) > { > - rdmsrq(msr_no, *q); > + *q =3D rdmsrq(msr_no); > return 0; > } > static inline int wrmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 q) > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/parav= irt.h > index 93754aa60d5e..19442bc3af37 100644 > --- a/arch/x86/include/asm/paravirt.h > +++ b/arch/x86/include/asm/paravirt.h > @@ -150,10 +150,10 @@ static inline int paravirt_write_msr_safe(u32 msr, = u64 val) > return PVOP_CALL2(int, pv_ops, cpu.write_msr_safe, msr, val); > } > > -#define rdmsrq(msr, val) \ > -do { \ > - val =3D paravirt_read_msr(msr); \ > -} while (0) > +static __always_inline u64 rdmsrq(u32 msr) > +{ > + return paravirt_read_msr(msr); > +} > > static inline void wrmsrq(u32 msr, u64 val) > { > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index 90025451ace2..7a6c77e6a44e 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1193,7 +1193,7 @@ void disable_local_APIC(void) > if (enabled_via_apicbase) { > struct msr val; > > - rdmsrq(MSR_IA32_APICBASE, val.q); > + val.q =3D rdmsrq(MSR_IA32_APICBASE); > val.l &=3D ~MSR_IA32_APICBASE_ENABLE; > wrmsrq(MSR_IA32_APICBASE, val.q); > } > @@ -1710,7 +1710,7 @@ static bool x2apic_hw_locked(void) > > x86_arch_cap_msr =3D x86_read_arch_cap_msr(); > if (x86_arch_cap_msr & ARCH_CAP_XAPIC_DISABLE) { > - rdmsrq(MSR_IA32_XAPIC_DISABLE_STATUS, msr); > + msr =3D rdmsrq(MSR_IA32_XAPIC_DISABLE_STATUS); > return (msr & LEGACY_XAPIC_DISABLED); > } > return false; > @@ -1723,7 +1723,7 @@ static void __x2apic_disable(void) > if (!boot_cpu_has(X86_FEATURE_APIC)) > return; > > - rdmsrq(MSR_IA32_APICBASE, msr); > + msr =3D rdmsrq(MSR_IA32_APICBASE); > if (!(msr & X2APIC_ENABLE)) > return; > /* Disable xapic and x2apic first and then reenable xapic mode */ > @@ -1736,7 +1736,7 @@ static void __x2apic_enable(void) > { > u64 msr; > > - rdmsrq(MSR_IA32_APICBASE, msr); > + msr =3D rdmsrq(MSR_IA32_APICBASE); > if (msr & X2APIC_ENABLE) > return; > wrmsrq(MSR_IA32_APICBASE, msr | X2APIC_ENABLE); > @@ -1976,7 +1976,7 @@ static bool __init apic_verify(unsigned long addr) > > /* The BIOS may have set up the APIC at some other address */ > if (boot_cpu_data.x86 >=3D 6) { > - rdmsrq(MSR_IA32_APICBASE, val.q); > + val.q =3D rdmsrq(MSR_IA32_APICBASE); > if (val.l & MSR_IA32_APICBASE_ENABLE) > addr =3D val.l & MSR_IA32_APICBASE_BASE; > } > @@ -1999,7 +1999,7 @@ bool __init apic_force_enable(unsigned long addr) > * and AMD K7 (Model > 1) or later. > */ > if (boot_cpu_data.x86 >=3D 6) { > - rdmsrq(MSR_IA32_APICBASE, val.q); > + val.q =3D rdmsrq(MSR_IA32_APICBASE); > if (!(val.l & MSR_IA32_APICBASE_ENABLE)) { > pr_info("Local APIC disabled by BIOS -- reenablin= g.\n"); > val.l &=3D ~MSR_IA32_APICBASE_BASE; > @@ -2476,7 +2476,7 @@ static void lapic_resume(void *data) > * SMP! We'll need to do this as part of the CPU restore! > */ > if (boot_cpu_data.x86 >=3D 6) { > - rdmsrq(MSR_IA32_APICBASE, val.q); > + val.q =3D rdmsrq(MSR_IA32_APICBASE); > val.l &=3D ~MSR_IA32_APICBASE_BASE; > val.l |=3D MSR_IA32_APICBASE_ENABLE | mp_lapic_ad= dr; > wrmsrq(MSR_IA32_APICBASE, val.q); > diff --git a/arch/x86/kernel/apic/apic_numachip.c b/arch/x86/kernel/apic/= apic_numachip.c > index a60c8960bbfd..3af93e3f2179 100644 > --- a/arch/x86/kernel/apic/apic_numachip.c > +++ b/arch/x86/kernel/apic/apic_numachip.c > @@ -32,7 +32,7 @@ static u32 numachip1_get_apic_id(u32 x) > unsigned int id =3D (x >> 24) & 0xff; > > if (cpu_feature_enabled(X86_FEATURE_NODEID_MSR)) { > - rdmsrq(MSR_FAM10H_NODE_ID, value); > + value =3D rdmsrq(MSR_FAM10H_NODE_ID); > id |=3D (value << 2) & 0xff00; > } > > @@ -43,7 +43,7 @@ static u32 numachip2_get_apic_id(u32 x) > { > u64 mcfg; > > - rdmsrq(MSR_FAM10H_MMIO_CONF_BASE, mcfg); > + mcfg =3D rdmsrq(MSR_FAM10H_MMIO_CONF_BASE); > return ((mcfg >> (28 - 8)) & 0xfff00) | (x >> 24); > } > > @@ -151,7 +151,7 @@ static void fixup_cpu_id(struct cpuinfo_x86 *c, int n= ode) > > /* Account for nodes per socket in multi-core-module processors *= / > if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) { > - rdmsrq(MSR_FAM10H_NODE_ID, val); > + val =3D rdmsrq(MSR_FAM10H_NODE_ID); > nodes =3D ((val >> 3) & 7) + 1; > } > > diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c > index 99444409c026..3efceee443b7 100644 > --- a/arch/x86/kernel/cet.c > +++ b/arch/x86/kernel/cet.c > @@ -56,7 +56,7 @@ static void do_user_cp_fault(struct pt_regs *regs, unsi= gned long error_code) > * will be whatever is live in userspace. So read the SSP before = enabling > * interrupts so locking the fpregs to do it later is not require= d. > */ > - rdmsrq(MSR_IA32_PL3_SSP, ssp); > + ssp =3D rdmsrq(MSR_IA32_PL3_SSP); > > cond_local_irq_enable(regs); > > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > index 54e14ed276b5..4bd43e899c64 100644 > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -160,7 +160,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c) > if (mbytes > 508) > mbytes =3D 508; > > - rdmsrq(MSR_K6_WHCR, val.q); > + val.q =3D rdmsrq(MSR_K6_WHCR); > if ((val.l & 0x0000FFFF) =3D=3D 0) { > unsigned long flags; > val.l =3D (1 << 0) | ((mbytes / 4) << 1); > @@ -181,7 +181,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c) > if (mbytes > 4092) > mbytes =3D 4092; > > - rdmsrq(MSR_K6_WHCR, val.q); > + val.q =3D rdmsrq(MSR_K6_WHCR); > if ((val.l & 0xFFFF0000) =3D=3D 0) { > unsigned long flags; > val.l =3D ((mbytes >> 2) << 22) | (1 << 16); > @@ -228,7 +228,7 @@ static void init_amd_k7(struct cpuinfo_x86 *c) > * As per AMD technical note 27212 0.2 > */ > if ((c->x86_model =3D=3D 8 && c->x86_stepping >=3D 1) || (c->x86_= model > 8)) { > - rdmsrq(MSR_K7_CLK_CTL, val.q); > + val.q =3D rdmsrq(MSR_K7_CLK_CTL); > if ((val.l & 0xfff00000) !=3D 0x20000000) { > pr_info("CPU: CLK_CTL MSR was %x. Reprogramming t= o %x\n", > val.l, ((val.l & 0x000fffff) | 0x20000000= )); > @@ -429,7 +429,7 @@ static void bsp_init_amd(struct cpuinfo_x86 *c) > (c->x86 =3D=3D 0x10 && c->x86_model >=3D 0x2)) { > u64 val; > > - rdmsrq(MSR_K7_HWCR, val); > + val =3D rdmsrq(MSR_K7_HWCR); > if (!(val & BIT(24))) > pr_warn(FW_BUG "TSC doesn't count with P0= frequency!\n"); > } > @@ -583,7 +583,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x= 86 *c) > */ > if (cpu_has(c, X86_FEATURE_SME) || cpu_has(c, X86_FEATURE_SEV)) { > /* Check if memory encryption is enabled */ > - rdmsrq(MSR_AMD64_SYSCFG, msr); > + msr =3D rdmsrq(MSR_AMD64_SYSCFG); > if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT)) > goto clear_all; > > @@ -600,7 +600,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x= 86 *c) > if (!sme_me_mask) > setup_clear_cpu_cap(X86_FEATURE_SME); > > - rdmsrq(MSR_K7_HWCR, msr); > + msr =3D rdmsrq(MSR_K7_HWCR); > if (!(msr & MSR_K7_HWCR_SMMLOCK)) > goto clear_sev; > > @@ -1111,7 +1111,7 @@ static void init_amd(struct cpuinfo_x86 *c) > init_amd_cacheinfo(c); > > if (cpu_has(c, X86_FEATURE_SVM)) { > - rdmsrq(MSR_VM_CR, vm_cr); > + vm_cr =3D rdmsrq(MSR_VM_CR); > if (vm_cr & SVM_VM_CR_SVM_DIS_MASK) { > pr_notice_once("SVM disabled (by BIOS) in MSR_VM_= CR\n"); > clear_cpu_cap(c, X86_FEATURE_SVM); > diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperf= mperf.c > index 7ffc78d5ebf2..492dc9a11d6b 100644 > --- a/arch/x86/kernel/cpu/aperfmperf.c > +++ b/arch/x86/kernel/cpu/aperfmperf.c > @@ -41,8 +41,8 @@ static void init_counter_refs(void *data) > { > u64 aperf, mperf; > > - rdmsrq(MSR_IA32_APERF, aperf); > - rdmsrq(MSR_IA32_MPERF, mperf); > + aperf =3D rdmsrq(MSR_IA32_APERF); > + mperf =3D rdmsrq(MSR_IA32_MPERF); > > this_cpu_write(cpu_samples.aperf, aperf); > this_cpu_write(cpu_samples.mperf, mperf); > @@ -479,8 +479,8 @@ void arch_scale_freq_tick(void) > if (!cpu_feature_enabled(X86_FEATURE_APERFMPERF)) > return; > > - rdmsrq(MSR_IA32_APERF, aperf); > - rdmsrq(MSR_IA32_MPERF, mperf); > + aperf =3D rdmsrq(MSR_IA32_APERF); > + mperf =3D rdmsrq(MSR_IA32_MPERF); > acnt =3D aperf - s->aperf; > mcnt =3D mperf - s->mperf; > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > index 56eac5611c31..aeb4770ba73c 100644 > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -761,7 +761,7 @@ void update_srbds_msr(void) > if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) > return; > > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); > + mcu_ctrl =3D rdmsrq(MSR_IA32_MCU_OPT_CTRL); > > switch (srbds_mitigation) { > case SRBDS_MITIGATION_OFF: > @@ -897,7 +897,7 @@ void update_gds_msr(void) > > switch (gds_mitigation) { > case GDS_MITIGATION_OFF: > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); > + mcu_ctrl =3D rdmsrq(MSR_IA32_MCU_OPT_CTRL); > mcu_ctrl |=3D GDS_MITG_DIS; > break; > case GDS_MITIGATION_FULL_LOCKED: > @@ -907,7 +907,7 @@ void update_gds_msr(void) > * CPUs. > */ > case GDS_MITIGATION_FULL: > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); > + mcu_ctrl =3D rdmsrq(MSR_IA32_MCU_OPT_CTRL); > mcu_ctrl &=3D ~GDS_MITG_DIS; > break; > case GDS_MITIGATION_FORCE: > @@ -924,7 +924,7 @@ void update_gds_msr(void) > * GDS_MITG_DIS will be ignored if this processor is locked but t= he boot > * processor was not. > */ > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl_after); > + mcu_ctrl_after =3D rdmsrq(MSR_IA32_MCU_OPT_CTRL); > WARN_ON_ONCE(mcu_ctrl !=3D mcu_ctrl_after); > } > > @@ -959,7 +959,7 @@ static void __init gds_select_mitigation(void) > if (gds_mitigation =3D=3D GDS_MITIGATION_FORCE) > gds_mitigation =3D GDS_MITIGATION_FULL; > > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); > + mcu_ctrl =3D rdmsrq(MSR_IA32_MCU_OPT_CTRL); > if (mcu_ctrl & GDS_MITG_LOCKED) { > if (gds_mitigation =3D=3D GDS_MITIGATION_OFF) > pr_warn("Mitigation locked. Disable failed.\n"); > @@ -3274,7 +3274,7 @@ void __init cpu_select_mitigations(void) > * init code as it is not enumerated and depends on the family. > */ > if (cpu_feature_enabled(X86_FEATURE_MSR_SPEC_CTRL)) { > - rdmsrq(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base); > + x86_spec_ctrl_base =3D rdmsrq(MSR_IA32_SPEC_CTRL); > > /* > * Previously running kernel (kexec), may have some contr= ols > diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_loc= k.c > index 177f964d4d36..cf853af86ae4 100644 > --- a/arch/x86/kernel/cpu/bus_lock.c > +++ b/arch/x86/kernel/cpu/bus_lock.c > @@ -105,7 +105,7 @@ static bool split_lock_verify_msr(bool on) > ctrl &=3D ~MSR_TEST_CTRL_SPLIT_LOCK_DETECT; > if (wrmsrq_safe(MSR_TEST_CTRL, ctrl)) > return false; > - rdmsrq(MSR_TEST_CTRL, tmp); > + tmp =3D rdmsrq(MSR_TEST_CTRL); > return ctrl =3D=3D tmp; > } > > @@ -145,7 +145,7 @@ static void __init __split_lock_setup(void) > return; > } > > - rdmsrq(MSR_TEST_CTRL, msr_test_ctrl_cache); > + msr_test_ctrl_cache =3D rdmsrq(MSR_TEST_CTRL); > > if (!split_lock_verify_msr(true)) { > pr_info("MSR access failed: Disabled\n"); > @@ -305,7 +305,7 @@ void bus_lock_init(void) > if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT)) > return; > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, val); > + val =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > > if ((boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) && > (sld_state =3D=3D sld_warn || sld_state =3D=3D sld_fatal)) || > @@ -383,7 +383,7 @@ static void __init split_lock_setup(struct cpuinfo_x8= 6 *c) > * MSR_IA32_CORE_CAPS_SPLIT_LOCK_DETECT is. All CPUs that set > * it have split lock detection. > */ > - rdmsrq(MSR_IA32_CORE_CAPS, ia32_core_caps); > + ia32_core_caps =3D rdmsrq(MSR_IA32_CORE_CAPS); > if (ia32_core_caps & MSR_IA32_CORE_CAPS_SPLIT_LOCK_DETECT) > goto supported; > > diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.= c > index 513fa1f640f9..6cd89b5ac9de 100644 > --- a/arch/x86/kernel/cpu/centaur.c > +++ b/arch/x86/kernel/cpu/centaur.c > @@ -30,7 +30,7 @@ static void init_c3(struct cpuinfo_x86 *c) > > /* enable ACE unit, if present and disabled */ > if ((tmp & (ACE_PRESENT | ACE_ENABLED)) =3D=3D ACE_PRESEN= T) { > - rdmsrq(MSR_VIA_FCR, msr); > + msr =3D rdmsrq(MSR_VIA_FCR); > /* enable ACE unit */ > wrmsrq(MSR_VIA_FCR, msr | ACE_FCR); > pr_info("CPU: Enabled ACE h/w crypto\n"); > @@ -38,7 +38,7 @@ static void init_c3(struct cpuinfo_x86 *c) > > /* enable RNG unit, if present and disabled */ > if ((tmp & (RNG_PRESENT | RNG_ENABLED)) =3D=3D RNG_PRESEN= T) { > - rdmsrq(MSR_VIA_RNG, msr); > + msr =3D rdmsrq(MSR_VIA_RNG); > /* enable RNG unit */ > wrmsrq(MSR_VIA_RNG, msr | RNG_ENABLE); > pr_info("CPU: Enabled h/w RNG\n"); > @@ -52,7 +52,7 @@ static void init_c3(struct cpuinfo_x86 *c) > #ifdef CONFIG_X86_32 > /* Cyrix III family needs CX8 & PGE explicitly enabled. */ > if (c->x86_model >=3D 6 && c->x86_model <=3D 13) { > - rdmsrq(MSR_VIA_FCR, msr); > + msr =3D rdmsrq(MSR_VIA_FCR); > wrmsrq(MSR_VIA_FCR, msr | (1 << 1 | 1 << 7)); > set_cpu_cap(c, X86_FEATURE_CX8); > } > @@ -169,7 +169,7 @@ static void init_centaur(struct cpuinfo_x86 *c) > name =3D "??"; > } > > - rdmsrq(MSR_IDT_FCR1, val.q); > + val.q =3D rdmsrq(MSR_IDT_FCR1); > newlo =3D (val.l | fcr_set) & (~fcr_clr); > > if (newlo !=3D val.l) { > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index c7352827f491..b2d9f8b14909 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -346,7 +346,7 @@ static void squash_the_stupid_serial_number(struct cp= uinfo_x86 *c) > > /* Disable processor serial number: */ > > - rdmsrq(MSR_IA32_BBL_CR_CTL, val.q); > + val.q =3D rdmsrq(MSR_IA32_BBL_CR_CTL); > val.l |=3D 0x200000; > wrmsrq(MSR_IA32_BBL_CR_CTL, val.q); > > @@ -610,7 +610,7 @@ __noendbr u64 ibt_save(bool disable) > u64 msr =3D 0; > > if (cpu_feature_enabled(X86_FEATURE_IBT)) { > - rdmsrq(MSR_IA32_S_CET, msr); > + msr =3D rdmsrq(MSR_IA32_S_CET); > if (disable) > wrmsrq(MSR_IA32_S_CET, msr & ~CET_ENDBR_EN); > } > @@ -623,7 +623,7 @@ __noendbr void ibt_restore(u64 save) > u64 msr; > > if (cpu_feature_enabled(X86_FEATURE_IBT)) { > - rdmsrq(MSR_IA32_S_CET, msr); > + msr =3D rdmsrq(MSR_IA32_S_CET); > msr &=3D ~CET_ENDBR_EN; > msr |=3D (save & CET_ENDBR_EN); > wrmsrq(MSR_IA32_S_CET, msr); > @@ -1357,7 +1357,7 @@ u64 x86_read_arch_cap_msr(void) > u64 x86_arch_cap_msr =3D 0; > > if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) > - rdmsrq(MSR_IA32_ARCH_CAPABILITIES, x86_arch_cap_msr); > + x86_arch_cap_msr =3D rdmsrq(MSR_IA32_ARCH_CAPABILITIES); > > return x86_arch_cap_msr; > } > @@ -1923,10 +1923,10 @@ static bool detect_null_seg_behavior(void) > */ > > unsigned long old_base, tmp; > - rdmsrq(MSR_FS_BASE, old_base); > + old_base =3D rdmsrq(MSR_FS_BASE); > wrmsrq(MSR_FS_BASE, 1); > loadsegment(fs, 0); > - rdmsrq(MSR_FS_BASE, tmp); > + tmp =3D rdmsrq(MSR_FS_BASE); > wrmsrq(MSR_FS_BASE, old_base); > return tmp =3D=3D 0; > } > diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ct= l.c > index 10a92927a515..7228fc2bb43e 100644 > --- a/arch/x86/kernel/cpu/feat_ctl.c > +++ b/arch/x86/kernel/cpu/feat_ctl.c > @@ -40,7 +40,7 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c= ) > * as they exist on any CPU that supports VMX, i.e. we want the W= ARN if > * the RDMSR faults. > */ > - rdmsrq(MSR_IA32_VMX_PROCBASED_CTLS, val.q); > + val.q =3D rdmsrq(MSR_IA32_VMX_PROCBASED_CTLS); > supported =3D val.h; > c->vmx_capability[PRIMARY_CTLS] =3D supported; > > @@ -53,7 +53,7 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c= ) > c->vmx_capability[TERTIARY_CTLS_LOW] =3D val.l; > c->vmx_capability[TERTIARY_CTLS_HIGH] =3D val.h; > > - rdmsrq(MSR_IA32_VMX_PINBASED_CTLS, val.q); > + val.q =3D rdmsrq(MSR_IA32_VMX_PINBASED_CTLS); > supported =3D val.h; > rdmsrq_safe(MSR_IA32_VMX_VMFUNC, &val.q); > funcs =3D val.h; > diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c > index ec51c2b9a257..44b462799cf6 100644 > --- a/arch/x86/kernel/cpu/hygon.c > +++ b/arch/x86/kernel/cpu/hygon.c > @@ -99,7 +99,7 @@ static void bsp_init_hygon(struct cpuinfo_x86 *c) > if (cpu_has(c, X86_FEATURE_CONSTANT_TSC)) { > u64 val; > > - rdmsrq(MSR_K7_HWCR, val); > + val =3D rdmsrq(MSR_K7_HWCR); > if (!(val & BIT(24))) > pr_warn(FW_BUG "TSC doesn't count with P0 frequen= cy!\n"); > } > @@ -194,7 +194,7 @@ static void init_hygon(struct cpuinfo_x86 *c) > init_hygon_cacheinfo(c); > > if (cpu_has(c, X86_FEATURE_SVM)) { > - rdmsrq(MSR_VM_CR, vm_cr); > + vm_cr =3D rdmsrq(MSR_VM_CR); > if (vm_cr & SVM_VM_CR_SVM_DIS_MASK) { > pr_notice_once("SVM disabled (by BIOS) in MSR_VM_= CR\n"); > clear_cpu_cap(c, X86_FEATURE_SVM); > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > index 4297ceb2cb24..2aabe9affa0c 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -159,7 +159,7 @@ static void detect_tme_early(struct cpuinfo_x86 *c) > u64 tme_activate; > int keyid_bits; > > - rdmsrq(MSR_IA32_TME_ACTIVATE, tme_activate); > + tme_activate =3D rdmsrq(MSR_IA32_TME_ACTIVATE); > > if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(t= me_activate)) { > pr_info_once("x86/tme: not enabled by BIOS\n"); > @@ -335,7 +335,7 @@ static void early_init_intel(struct cpuinfo_x86 *c) > * string flag and enhanced fast string capabilities accordingly. > */ > if (c->x86_vfm >=3D INTEL_PENTIUM_M_DOTHAN) { > - rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable); > + misc_enable =3D rdmsrq(MSR_IA32_MISC_ENABLE); > if (misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING) { > /* X86_FEATURE_ERMS is set based on CPUID */ > set_cpu_cap(c, X86_FEATURE_REP_GOOD); > @@ -579,7 +579,7 @@ static void init_intel(struct cpuinfo_x86 *c) > if (boot_cpu_has(X86_FEATURE_DS)) { > u64 l; > > - rdmsrq(MSR_IA32_MISC_ENABLE, l); > + l =3D rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(l & MSR_IA32_MISC_ENABLE_BTS_UNAVAIL)) > set_cpu_cap(c, X86_FEATURE_BTS); > if (!(l & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL)) > diff --git a/arch/x86/kernel/cpu/intel_epb.c b/arch/x86/kernel/cpu/intel_= epb.c > index 2c56f8730f59..a02d562253d9 100644 > --- a/arch/x86/kernel/cpu/intel_epb.c > +++ b/arch/x86/kernel/cpu/intel_epb.c > @@ -79,7 +79,7 @@ static int intel_epb_save(void *data) > { > u64 epb; > > - rdmsrq(MSR_IA32_ENERGY_PERF_BIAS, epb); > + epb =3D rdmsrq(MSR_IA32_ENERGY_PERF_BIAS); > /* > * Ensure that saved_epb will always be nonzero after this write = even if > * the EPB value read from the MSR is 0. > @@ -94,7 +94,7 @@ static void intel_epb_restore(void *data) > u64 val =3D this_cpu_read(saved_epb); > u64 epb; > > - rdmsrq(MSR_IA32_ENERGY_PERF_BIAS, epb); > + epb =3D rdmsrq(MSR_IA32_ENERGY_PERF_BIAS); > if (val) { > val &=3D EPB_MASK; > } else { > diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.= c > index 1cc20b855b7e..9695af953299 100644 > --- a/arch/x86/kernel/cpu/mce/amd.c > +++ b/arch/x86/kernel/cpu/mce/amd.c > @@ -438,7 +438,7 @@ static void threshold_restart_block(void *_tr) > if (!this_cpu_read(threshold_banks) && !tr->set_lvt_off) > return; > > - rdmsrq(tr->b->address, val.q); > + val.q =3D rdmsrq(tr->b->address); > > /* > * Reset error count and overflow bit. > @@ -658,7 +658,7 @@ static void disable_err_thresholding(struct cpuinfo_x= 86 *c, unsigned int bank) > return; > } > > - rdmsrq(MSR_K7_HWCR, hwcr); > + hwcr =3D rdmsrq(MSR_K7_HWCR); > > /* McStatusWrEn has to be set */ > need_toggle =3D !(hwcr & BIT(18)); > diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/cor= e.c > index ab469605fc89..df56ca06275b 100644 > --- a/arch/x86/kernel/cpu/mce/core.c > +++ b/arch/x86/kernel/cpu/mce/core.c > @@ -1845,7 +1845,7 @@ static void __mcheck_cpu_cap_init(void) > u64 cap; > u8 b; > > - rdmsrq(MSR_IA32_MCG_CAP, cap); > + cap =3D rdmsrq(MSR_IA32_MCG_CAP); > > b =3D cap & MCG_BANKCNT_MASK; > > @@ -1864,7 +1864,7 @@ static void __mcheck_cpu_init_generic(void) > { > u64 cap; > > - rdmsrq(MSR_IA32_MCG_CAP, cap); > + cap =3D rdmsrq(MSR_IA32_MCG_CAP); > if (cap & MCG_CTL_P) > wrmsrq(MSR_IA32_MCG_CTL, ~0ULL); > } > @@ -1896,7 +1896,7 @@ static void __mcheck_cpu_init_prepare_banks(void) > wrmsrq(mca_msr_reg(i, MCA_CTL), b->ctl); > wrmsrq(mca_msr_reg(i, MCA_STATUS), 0); > > - rdmsrq(mca_msr_reg(i, MCA_CTL), msrval); > + msrval =3D rdmsrq(mca_msr_reg(i, MCA_CTL)); > b->init =3D !!msrval; > } > } > @@ -2214,7 +2214,7 @@ void mca_bsp_init(struct cpuinfo_x86 *c) > if (mce_flags.smca) > smca_bsp_init(); > > - rdmsrq(MSR_IA32_MCG_CAP, cap); > + cap =3D rdmsrq(MSR_IA32_MCG_CAP); > > /* Use accurate RIP reporting if available. */ > if ((cap & MCG_EXT_P) && MCG_EXT_CNT(cap) >=3D 9) > diff --git a/arch/x86/kernel/cpu/mce/inject.c b/arch/x86/kernel/cpu/mce/i= nject.c > index 6f8a49d8baeb..aa933864f32e 100644 > --- a/arch/x86/kernel/cpu/mce/inject.c > +++ b/arch/x86/kernel/cpu/mce/inject.c > @@ -743,7 +743,7 @@ static void check_hw_inj_possible(void) > u64 status =3D MCI_STATUS_VAL, ipid; > > /* Check whether bank is populated */ > - rdmsrq(MSR_AMD64_SMCA_MCx_IPID(bank), ipid); > + ipid =3D rdmsrq(MSR_AMD64_SMCA_MCx_IPID(bank)); > if (!ipid) > continue; > > diff --git a/arch/x86/kernel/cpu/mce/intel.c b/arch/x86/kernel/cpu/mce/in= tel.c > index 4655223ba560..2edb05d5e2d7 100644 > --- a/arch/x86/kernel/cpu/mce/intel.c > +++ b/arch/x86/kernel/cpu/mce/intel.c > @@ -94,7 +94,7 @@ static bool cmci_supported(int *banks) > if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6) > return false; > > - rdmsrq(MSR_IA32_MCG_CAP, cap); > + cap =3D rdmsrq(MSR_IA32_MCG_CAP); > *banks =3D min_t(unsigned, MAX_NR_BANKS, cap & MCG_BANKCNT_MASK); > return !!(cap & MCG_CMCI_P); > } > @@ -106,7 +106,7 @@ static bool lmce_supported(void) > if (mca_cfg.lmce_disabled) > return false; > > - rdmsrq(MSR_IA32_MCG_CAP, tmp); > + tmp =3D rdmsrq(MSR_IA32_MCG_CAP); > > /* > * LMCE depends on recovery support in the processor. Hence both > @@ -123,7 +123,7 @@ static bool lmce_supported(void) > * WARN if the MSR isn't locked as init_ia32_feat_ctl() unconditi= onally > * locks the MSR in the event that it wasn't already locked by BI= OS. > */ > - rdmsrq(MSR_IA32_FEAT_CTL, tmp); > + tmp =3D rdmsrq(MSR_IA32_FEAT_CTL); > if (WARN_ON_ONCE(!(tmp & FEAT_CTL_LOCKED))) > return false; > > @@ -141,7 +141,7 @@ static void cmci_set_threshold(int bank, int thresh) > u64 val; > > raw_spin_lock_irqsave(&cmci_discover_lock, flags); > - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); > + val =3D rdmsrq(MSR_IA32_MCx_CTL2(bank)); > val &=3D ~MCI_CTL2_CMCI_THRESHOLD_MASK; > wrmsrq(MSR_IA32_MCx_CTL2(bank), val | thresh); > raw_spin_unlock_irqrestore(&cmci_discover_lock, flags); > @@ -184,7 +184,7 @@ static bool cmci_skip_bank(int bank, u64 *val) > if (test_bit(bank, mce_banks_ce_disabled)) > return true; > > - rdmsrq(MSR_IA32_MCx_CTL2(bank), *val); > + *val =3D rdmsrq(MSR_IA32_MCx_CTL2(bank)); > > /* Already owned by someone else? */ > if (*val & MCI_CTL2_CMCI_EN) { > @@ -233,7 +233,7 @@ static void cmci_claim_bank(int bank, u64 val, int bi= os_zero_thresh, int *bios_w > > val |=3D MCI_CTL2_CMCI_EN; > wrmsrq(MSR_IA32_MCx_CTL2(bank), val); > - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); > + val =3D rdmsrq(MSR_IA32_MCx_CTL2(bank)); > > /* If the enable bit did not stick, this bank should be polled. *= / > if (!(val & MCI_CTL2_CMCI_EN)) { > @@ -324,7 +324,7 @@ static void __cmci_disable_bank(int bank) > > if (!test_bit(bank, this_cpu_ptr(mce_banks_owned))) > return; > - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); > + val =3D rdmsrq(MSR_IA32_MCx_CTL2(bank)); > val &=3D ~MCI_CTL2_CMCI_EN; > wrmsrq(MSR_IA32_MCx_CTL2(bank), val); > __clear_bit(bank, this_cpu_ptr(mce_banks_owned)); > @@ -430,7 +430,7 @@ void intel_init_lmce(void) > if (!lmce_supported()) > return; > > - rdmsrq(MSR_IA32_MCG_EXT_CTL, val); > + val =3D rdmsrq(MSR_IA32_MCG_EXT_CTL); > > if (!(val & MCG_EXT_CTL_LMCE_EN)) > wrmsrq(MSR_IA32_MCG_EXT_CTL, val | MCG_EXT_CTL_LMCE_EN); > @@ -443,7 +443,7 @@ void intel_clear_lmce(void) > if (!lmce_supported()) > return; > > - rdmsrq(MSR_IA32_MCG_EXT_CTL, val); > + val =3D rdmsrq(MSR_IA32_MCG_EXT_CTL); > val &=3D ~MCG_EXT_CTL_LMCE_EN; > wrmsrq(MSR_IA32_MCG_EXT_CTL, val); > } > diff --git a/arch/x86/kernel/cpu/mce/p5.c b/arch/x86/kernel/cpu/mce/p5.c > index 3c2b6cc918b1..b441c720f9b7 100644 > --- a/arch/x86/kernel/cpu/mce/p5.c > +++ b/arch/x86/kernel/cpu/mce/p5.c > @@ -26,8 +26,8 @@ noinstr void pentium_machine_check(struct pt_regs *regs= ) > u64 addr, type; > > instrumentation_begin(); > - rdmsrq(MSR_IA32_P5_MC_ADDR, addr); > - rdmsrq(MSR_IA32_P5_MC_TYPE, type); > + addr =3D rdmsrq(MSR_IA32_P5_MC_ADDR); > + type =3D rdmsrq(MSR_IA32_P5_MC_TYPE); > > pr_emerg("CPU#%d: Machine Check Exception: 0x%8X (type 0x%8X).\n= ", > smp_processor_id(), (u32)addr, (u32)type); > @@ -55,8 +55,8 @@ void intel_p5_mcheck_init(struct cpuinfo_x86 *c) > return; > > /* Read registers before enabling: */ > - rdmsrq(MSR_IA32_P5_MC_ADDR, q); > - rdmsrq(MSR_IA32_P5_MC_TYPE, q); > + q =3D rdmsrq(MSR_IA32_P5_MC_ADDR); > + q =3D rdmsrq(MSR_IA32_P5_MC_TYPE); > pr_info("Intel old style machine check architecture supported.\n"= ); > > /* Enable MCE: */ > diff --git a/arch/x86/kernel/cpu/mce/winchip.c b/arch/x86/kernel/cpu/mce/= winchip.c > index 7040243533d9..7b967f2abd8f 100644 > --- a/arch/x86/kernel/cpu/mce/winchip.c > +++ b/arch/x86/kernel/cpu/mce/winchip.c > @@ -30,7 +30,7 @@ void winchip_mcheck_init(struct cpuinfo_x86 *c) > { > struct msr val; > > - rdmsrq(MSR_IDT_FCR1, val.q); > + val.q =3D rdmsrq(MSR_IDT_FCR1); > val.l |=3D (1<<2); /* Enable EIERRINT (int 18 MCE) */ > val.l &=3D ~(1<<4); /* Enable MCE */ > wrmsrq(MSR_IDT_FCR1, val.q); > diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/= microcode/intel.c > index 1142183c950c..4d199abd8fd8 100644 > --- a/arch/x86/kernel/cpu/microcode/intel.c > +++ b/arch/x86/kernel/cpu/microcode/intel.c > @@ -991,7 +991,7 @@ static __init bool staging_available(void) > if (!(val & ARCH_CAP_MCU_ENUM)) > return false; > > - rdmsrq(MSR_IA32_MCU_ENUMERATION, val); > + val =3D rdmsrq(MSR_IA32_MCU_ENUMERATION); > return !!(val & MCU_STAGING); > } > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyper= v.c > index b4af7c0a70ac..e1388ed27384 100644 > --- a/arch/x86/kernel/cpu/mshyperv.c > +++ b/arch/x86/kernel/cpu/mshyperv.c > @@ -74,7 +74,7 @@ u64 hv_get_non_nested_msr(unsigned int reg) > if (hv_is_synic_msr(reg) && ms_hyperv.paravisor_present) > hv_ivm_msr_read(reg, &value); > else > - rdmsrq(reg, value); > + value =3D rdmsrq(reg); > return value; > } > EXPORT_SYMBOL_GPL(hv_get_non_nested_msr); > @@ -399,7 +399,7 @@ static unsigned long hv_get_tsc_khz(void) > { > unsigned long freq; > > - rdmsrq(HV_X64_MSR_TSC_FREQUENCY, freq); > + freq =3D rdmsrq(HV_X64_MSR_TSC_FREQUENCY); > > return freq / 1000; > } > @@ -660,7 +660,7 @@ static void __init ms_hyperv_init_platform(void) > */ > u64 hv_lapic_frequency; > > - rdmsrq(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency); > + hv_lapic_frequency =3D rdmsrq(HV_X64_MSR_APIC_FREQUENCY); > hv_lapic_frequency =3D div_u64(hv_lapic_frequency, HZ); > lapic_timer_period =3D hv_lapic_frequency; > pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n", > diff --git a/arch/x86/kernel/cpu/mtrr/amd.c b/arch/x86/kernel/cpu/mtrr/am= d.c > index a73715d6f05c..652e4d64ff4a 100644 > --- a/arch/x86/kernel/cpu/mtrr/amd.c > +++ b/arch/x86/kernel/cpu/mtrr/amd.c > @@ -13,7 +13,7 @@ amd_get_mtrr(unsigned int reg, unsigned long *base, > unsigned long val; > struct msr msr; > > - rdmsrq(MSR_K6_UWCCR, msr.q); > + msr.q =3D rdmsrq(MSR_K6_UWCCR); > /* Upper dword is region 1, lower is region 0 */ > if (reg =3D=3D 1) > val =3D msr.h; > @@ -68,7 +68,7 @@ amd_set_mtrr(unsigned int reg, unsigned long base, unsi= gned long size, mtrr_type > /* > * Low is MTRR0, High MTRR 1 > */ > - rdmsrq(MSR_K6_UWCCR, msr.q); > + msr.q =3D rdmsrq(MSR_K6_UWCCR); > regs[0] =3D msr.l; > regs[1] =3D msr.h; > > diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtr= r/cleanup.c > index cd1a6dec4064..2b72c784db9e 100644 > --- a/arch/x86/kernel/cpu/mtrr/cleanup.c > +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c > @@ -670,7 +670,7 @@ int __init mtrr_cleanup(void) > if (!cpu_feature_enabled(X86_FEATURE_MTRR) || enable_mtrr_cleanup= < 1) > return 0; > > - rdmsrq(MSR_MTRRdefType, def); > + def =3D rdmsrq(MSR_MTRRdefType); > def &=3D 0xff; > if (def !=3D MTRR_TYPE_UNCACHABLE) > return 0; > @@ -870,7 +870,7 @@ int __init mtrr_trim_uncached_memory(unsigned long en= d_pfn) > if (!cpu_feature_enabled(X86_FEATURE_MTRR) || disable_mtrr_trim) > return 0; > > - rdmsrq(MSR_MTRRdefType, def); > + def =3D rdmsrq(MSR_MTRRdefType); > def &=3D MTRR_DEF_TYPE_TYPE; > if (def !=3D MTRR_TYPE_UNCACHABLE) > return 0; > diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtr= r/generic.c > index 67cf69f24b00..4d8034a7fdc8 100644 > --- a/arch/x86/kernel/cpu/mtrr/generic.c > +++ b/arch/x86/kernel/cpu/mtrr/generic.c > @@ -112,7 +112,7 @@ static inline void k8_check_syscfg_dram_mod_en(void) > if (cc_platform_has(CC_ATTR_HOST_SEV_SNP)) > return; > > - rdmsrq(MSR_AMD64_SYSCFG, val.q); > + val.q =3D rdmsrq(MSR_AMD64_SYSCFG); > if (val.l & K8_MTRRFIXRANGE_DRAM_MODIFY) { > pr_err(FW_WARN "MTRR: CPU %u: SYSCFG[MtrrFixDramModEn]" > " not cleared by BIOS, clearing this bit\n", > @@ -559,10 +559,10 @@ get_mtrr_var_range(unsigned int index, struct mtrr_= var_range *vr) > { > struct msr val; > > - rdmsrq(MTRRphysBase_MSR(index), val.q); > + val.q =3D rdmsrq(MTRRphysBase_MSR(index)); > vr->base_lo =3D val.l; > vr->base_hi =3D val.h; > - rdmsrq(MTRRphysMask_MSR(index), val.q); > + val.q =3D rdmsrq(MTRRphysMask_MSR(index)); > vr->mask_lo =3D val.l; > vr->mask_hi =3D val.h; > } > @@ -588,12 +588,12 @@ static void get_fixed_ranges(mtrr_type *frs) > > k8_check_syscfg_dram_mod_en(); > > - rdmsrq(MSR_MTRRfix64K_00000, p[0]); > + p[0] =3D rdmsrq(MSR_MTRRfix64K_00000); > > for (i =3D 0; i < 2; i++) > - rdmsrq(MSR_MTRRfix16K_80000 + i, p[1 + i]); > + p[1 + i] =3D rdmsrq(MSR_MTRRfix16K_80000 + i); > for (i =3D 0; i < 8; i++) > - rdmsrq(MSR_MTRRfix4K_C0000 + i, p[3 + i]); > + p[3 + i] =3D rdmsrq(MSR_MTRRfix4K_C0000 + i); > } > > void mtrr_save_fixed_ranges(void *info) > @@ -700,7 +700,7 @@ bool __init get_mtrr_state(void) > > vrs =3D mtrr_state.var_ranges; > > - rdmsrq(MSR_MTRRcap, q); > + q =3D rdmsrq(MSR_MTRRcap); > mtrr_state.have_fixed =3D q & MTRR_CAP_FIX; > > for (i =3D 0; i < num_var_ranges; i++) > @@ -708,13 +708,13 @@ bool __init get_mtrr_state(void) > if (mtrr_state.have_fixed) > get_fixed_ranges(mtrr_state.fixed_ranges); > > - rdmsrq(MSR_MTRRdefType, q); > + q =3D rdmsrq(MSR_MTRRdefType); > mtrr_state.def_type =3D q & MTRR_DEF_TYPE_TYPE; > mtrr_state.enabled =3D (q & MTRR_DEF_TYPE_ENABLE) >> MTRR_STATE_S= HIFT; > > if (amd_special_default_mtrr()) { > /* TOP_MEM2 */ > - rdmsrq(MSR_K8_TOP_MEM2, mtrr_tom2); > + mtrr_tom2 =3D rdmsrq(MSR_K8_TOP_MEM2); > mtrr_tom2 &=3D 0xffffff800000ULL; > } > > @@ -770,7 +770,7 @@ static void set_fixed_range(int msr, bool *changed, u= nsigned int *msrwords) > { > struct msr val; > > - rdmsrq(msr, val.q); > + val.q =3D rdmsrq(msr); > > if (val.l !=3D msrwords[0] || val.h !=3D msrwords[1]) { > mtrr_wrmsr(msr, msrwords[0], msrwords[1]); > @@ -818,7 +818,7 @@ static void generic_get_mtrr(unsigned int reg, unsign= ed long *base, > */ > get_cpu(); > > - rdmsrq(MTRRphysMask_MSR(reg), mask); > + mask =3D rdmsrq(MTRRphysMask_MSR(reg)); > > if (!(mask & MTRR_PHYSMASK_V)) { > /* Invalid (i.e. free) range */ > @@ -828,7 +828,7 @@ static void generic_get_mtrr(unsigned int reg, unsign= ed long *base, > goto out_put_cpu; > } > > - rdmsrq(MTRRphysBase_MSR(reg), base_msr); > + base_msr =3D rdmsrq(MTRRphysBase_MSR(reg)); > > /* Work out the shifted address mask: */ > tmp =3D mask & PAGE_MASK; > @@ -889,7 +889,7 @@ static bool set_mtrr_var_ranges(unsigned int index, s= truct mtrr_var_range *vr) > bool changed =3D false; > struct msr val; > > - rdmsrq(MTRRphysBase_MSR(index), val.q); > + val.q =3D rdmsrq(MTRRphysBase_MSR(index)); > if ((vr->base_lo & ~MTRR_PHYSBASE_RSVD) !=3D (val.l & ~MTRR_PHYSB= ASE_RSVD) > || (vr->base_hi & ~phys_hi_rsvd) !=3D (val.h & ~phys_hi_rsvd)= ) { > > @@ -897,7 +897,7 @@ static bool set_mtrr_var_ranges(unsigned int index, s= truct mtrr_var_range *vr) > changed =3D true; > } > > - rdmsrq(MTRRphysMask_MSR(index), val.q); > + val.q =3D rdmsrq(MTRRphysMask_MSR(index)); > > if ((vr->mask_lo & ~MTRR_PHYSMASK_RSVD) !=3D (val.l & ~MTRR_PHYSM= ASK_RSVD) > || (vr->mask_hi & ~phys_hi_rsvd) !=3D (val.h & ~phys_hi_rsvd)= ) { > @@ -952,7 +952,7 @@ void mtrr_disable(void) > struct msr val; > > /* Save MTRR state */ > - rdmsrq(MSR_MTRRdefType, val.q); > + val.q =3D rdmsrq(MSR_MTRRdefType); > deftype_lo =3D val.l; > deftype_hi =3D val.h; > > @@ -1065,7 +1065,7 @@ static int generic_have_wrcomb(void) > { > u64 config; > > - rdmsrq(MSR_MTRRcap, config); > + config =3D rdmsrq(MSR_MTRRcap); > return config & MTRR_CAP_WC; > } > > diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/m= trr.c > index 468c53b20acf..9b7abd58b677 100644 > --- a/arch/x86/kernel/cpu/mtrr/mtrr.c > +++ b/arch/x86/kernel/cpu/mtrr/mtrr.c > @@ -571,7 +571,7 @@ void __init mtrr_bp_init(void) > if (mtrr_enabled()) { > /* Get the number of variable MTRR ranges. */ > if (mtrr_if =3D=3D &generic_mtrr_ops) > - rdmsrq(MSR_MTRRcap, config); > + config =3D rdmsrq(MSR_MTRRcap); > else > config =3D mtrr_if->var_regs; > num_var_ranges =3D config & MTRR_CAP_VCNT; > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/res= ctrl/core.c > index 55214d6fdc49..dd0e20179fce 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -165,7 +165,7 @@ static inline void cache_alloc_hsw_probe(void) > if (wrmsrq_safe(MSR_IA32_L3_CBM_BASE, max_cbm)) > return; > > - rdmsrq(MSR_IA32_L3_CBM_BASE, l3_cbm_0); > + l3_cbm_0 =3D rdmsrq(MSR_IA32_L3_CBM_BASE); > > /* If all the bits were set in MSR, return success */ > if (l3_cbm_0 !=3D max_cbm) > diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/= resctrl/monitor.c > index 3838e0a13d36..530c425d7ee4 100644 > --- a/arch/x86/kernel/cpu/resctrl/monitor.c > +++ b/arch/x86/kernel/cpu/resctrl/monitor.c > @@ -147,7 +147,7 @@ static int __rmid_read_phys(u32 prmid, enum resctrl_e= vent_id eventid, u64 *val) > * are error bits. > */ > wrmsrq(MSR_IA32_QM_EVTSEL, msr_val.q); > - rdmsrq(MSR_IA32_QM_CTR, msr_val.q); > + msr_val.q =3D rdmsrq(MSR_IA32_QM_CTR); > > if (msr_val.q & RMID_VAL_ERROR) > return -EIO; > @@ -310,7 +310,7 @@ static int __cntr_id_read(u32 cntr_id, u64 *val) > * is set if the counter data is unavailable. > */ > wrmsrq(MSR_IA32_QM_EVTSEL, msr_val.q); > - rdmsrq(MSR_IA32_QM_CTR, msr_val.q); > + msr_val.q =3D rdmsrq(MSR_IA32_QM_CTR); > > if (msr_val.q & RMID_VAL_ERROR) > return -EIO; > diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c b/arch/x86/kernel/= cpu/resctrl/pseudo_lock.c > index d7caab0409b6..0408ac7f66fd 100644 > --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c > +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c > @@ -250,7 +250,7 @@ int resctrl_arch_measure_cycles_lat_fn(void *_plr) > /* > * Disable hardware prefetchers. > */ > - rdmsrq(MSR_MISC_FEATURE_CONTROL, saved); > + saved =3D rdmsrq(MSR_MISC_FEATURE_CONTROL); > wrmsrq(MSR_MISC_FEATURE_CONTROL, prefetch_disable_bits); > mem_r =3D READ_ONCE(plr->kmem); > /* > @@ -346,7 +346,7 @@ static int measure_residency_fn(struct perf_event_att= r *miss_attr, > /* > * Disable hardware prefetchers. > */ > - rdmsrq(MSR_MISC_FEATURE_CONTROL, saved); > + saved =3D rdmsrq(MSR_MISC_FEATURE_CONTROL); > wrmsrq(MSR_MISC_FEATURE_CONTROL, prefetch_disable_bits); > > /* Initialize rest of local variables */ > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu= /resctrl/rdtgroup.c > index 5ffa39fa86fa..37f0b1f7fe4f 100644 > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > @@ -96,7 +96,7 @@ void resctrl_arch_mon_event_config_read(void *_config_i= nfo) > pr_warn_once("Invalid event id %d\n", config_info->evtid)= ; > return; > } > - rdmsrq(MSR_IA32_EVT_CFG_BASE + index, msrval); > + msrval =3D rdmsrq(MSR_IA32_EVT_CFG_BASE + index); > > /* Report only the valid event configuration bits */ > config_info->mon_config =3D msrval & MAX_EVT_CONFIG_BITS; > diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topolog= y.c > index 4913b64ec592..68337da5aa09 100644 > --- a/arch/x86/kernel/cpu/topology.c > +++ b/arch/x86/kernel/cpu/topology.c > @@ -151,7 +151,7 @@ static __init bool check_for_real_bsp(u32 apic_id) > * kernel must rely on the firmware enumeration order. > */ > if (has_apic_base) { > - rdmsrq(MSR_IA32_APICBASE, msr); > + msr =3D rdmsrq(MSR_IA32_APICBASE); > is_bsp =3D !!(msr & MSR_IA32_APICBASE_BSP); > } > > diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/top= ology_amd.c > index c5a6944df86a..5192f13f3686 100644 > --- a/arch/x86/kernel/cpu/topology_amd.c > +++ b/arch/x86/kernel/cpu/topology_amd.c > @@ -140,7 +140,7 @@ static void parse_fam10h_node_id(struct topo_scan *ts= can) > if (!boot_cpu_has(X86_FEATURE_NODEID_MSR)) > return; > > - rdmsrq(MSR_FAM10H_NODE_ID, nid.msr); > + nid.msr =3D rdmsrq(MSR_FAM10H_NODE_ID); > store_node(tscan, nid.nodes_per_pkg + 1, nid.node_id); > tscan->c->topo.llc_id =3D nid.node_id; > } > @@ -168,7 +168,7 @@ static void topoext_fixup(struct topo_scan *tscan) > MSR_AMD64_CPUID_EXT_FEAT_TOPOEXT_BIT) <=3D 0) > return; > > - rdmsrq(MSR_AMD64_CPUID_EXT_FEAT, msrval); > + msrval =3D rdmsrq(MSR_AMD64_CPUID_EXT_FEAT); > if (msrval & MSR_AMD64_CPUID_EXT_FEAT_TOPOEXT) { > set_cpu_cap(c, X86_FEATURE_TOPOEXT); > pr_info_once(FW_INFO "CPU: Re-enabling disabled Topology = Extensions Support.\n"); > diff --git a/arch/x86/kernel/cpu/transmeta.c b/arch/x86/kernel/cpu/transm= eta.c > index 35d498f24e34..f8632becda18 100644 > --- a/arch/x86/kernel/cpu/transmeta.c > +++ b/arch/x86/kernel/cpu/transmeta.c > @@ -87,7 +87,7 @@ static void init_transmeta(struct cpuinfo_x86 *c) > } > > /* Unhide possibly hidden capability flags */ > - rdmsrq(0x80860004, msr); > + msr =3D rdmsrq(0x80860004); > wrmsrq(0x80860004, msr | ~0U); > cpuid_refresh_leaf(c, 0x1); > c->x86_capability[CPUID_1_EDX] =3D cpuid_edx(0x00000001); > diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c > index 209b5a22d880..b500845d2049 100644 > --- a/arch/x86/kernel/cpu/tsx.c > +++ b/arch/x86/kernel/cpu/tsx.c > @@ -35,7 +35,7 @@ static void tsx_disable(void) > { > u64 tsx; > > - rdmsrq(MSR_IA32_TSX_CTRL, tsx); > + tsx =3D rdmsrq(MSR_IA32_TSX_CTRL); > > /* Force all transactions to immediately abort */ > tsx |=3D TSX_CTRL_RTM_DISABLE; > @@ -55,7 +55,7 @@ static void tsx_enable(void) > { > u64 tsx; > > - rdmsrq(MSR_IA32_TSX_CTRL, tsx); > + tsx =3D rdmsrq(MSR_IA32_TSX_CTRL); > > /* Enable the RTM feature in the cpu */ > tsx &=3D ~TSX_CTRL_RTM_DISABLE; > @@ -126,11 +126,11 @@ static void tsx_clear_cpuid(void) > */ > if (boot_cpu_has(X86_FEATURE_RTM_ALWAYS_ABORT) && > boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)) { > - rdmsrq(MSR_TSX_FORCE_ABORT, msr); > + msr =3D rdmsrq(MSR_TSX_FORCE_ABORT); > msr |=3D MSR_TFA_TSX_CPUID_CLEAR; > wrmsrq(MSR_TSX_FORCE_ABORT, msr); > } else if (cpu_feature_enabled(X86_FEATURE_MSR_TSX_CTRL)) { > - rdmsrq(MSR_IA32_TSX_CTRL, msr); > + msr =3D rdmsrq(MSR_IA32_TSX_CTRL); > msr |=3D TSX_CTRL_CPUID_CLEAR; > wrmsrq(MSR_IA32_TSX_CTRL, msr); > } > @@ -157,7 +157,7 @@ static void tsx_dev_mode_disable(void) > !cpu_feature_enabled(X86_FEATURE_SRBDS_CTRL)) > return; > > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_opt_ctrl); > + mcu_opt_ctrl =3D rdmsrq(MSR_IA32_MCU_OPT_CTRL); > > if (mcu_opt_ctrl & RTM_ALLOW) { > mcu_opt_ctrl &=3D ~RTM_ALLOW; > diff --git a/arch/x86/kernel/cpu/umwait.c b/arch/x86/kernel/cpu/umwait.c > index e4a31c536642..8c3cf0f95e9a 100644 > --- a/arch/x86/kernel/cpu/umwait.c > +++ b/arch/x86/kernel/cpu/umwait.c > @@ -218,7 +218,7 @@ static int __init umwait_init(void) > * changed. This is the only place where orig_umwait_control_cach= ed > * is modified. > */ > - rdmsrq(MSR_IA32_UMWAIT_CONTROL, orig_umwait_control_cached); > + orig_umwait_control_cached =3D rdmsrq(MSR_IA32_UMWAIT_CONTROL); > > ret =3D cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "umwait:online", > umwait_cpu_online, umwait_cpu_offline); > diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.= c > index fe504fd43c77..f89aec38a349 100644 > --- a/arch/x86/kernel/cpu/zhaoxin.c > +++ b/arch/x86/kernel/cpu/zhaoxin.c > @@ -29,7 +29,7 @@ static void init_zhaoxin_cap(struct cpuinfo_x86 *c) > > /* Enable ACE unit, if present and disabled */ > if ((tmp & (ACE_PRESENT | ACE_ENABLED)) =3D=3D ACE_PRESEN= T) { > - rdmsrq(MSR_ZHAOXIN_FCR57, msr); > + msr =3D rdmsrq(MSR_ZHAOXIN_FCR57); > /* Enable ACE unit */ > wrmsrq(MSR_ZHAOXIN_FCR57, msr | ACE_FCR); > pr_info("CPU: Enabled ACE h/w crypto\n"); > @@ -37,7 +37,7 @@ static void init_zhaoxin_cap(struct cpuinfo_x86 *c) > > /* Enable RNG unit, if present and disabled */ > if ((tmp & (RNG_PRESENT | RNG_ENABLED)) =3D=3D RNG_PRESEN= T) { > - rdmsrq(MSR_ZHAOXIN_FCR57, msr); > + msr =3D rdmsrq(MSR_ZHAOXIN_FCR57); > /* Enable RNG unit */ > wrmsrq(MSR_ZHAOXIN_FCR57, msr | RNG_ENABLE); > pr_info("CPU: Enabled h/w RNG\n"); > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > index d1aeecd57f5e..7d2cff9633cf 100644 > --- a/arch/x86/kernel/fpu/core.c > +++ b/arch/x86/kernel/fpu/core.c > @@ -364,7 +364,7 @@ void fpu_sync_guest_vmexit_xfd_state(void) > > lockdep_assert_irqs_disabled(); > if (fpu_state_size_dynamic()) { > - rdmsrq(MSR_IA32_XFD, fpstate->xfd); > + fpstate->xfd =3D rdmsrq(MSR_IA32_XFD); > __this_cpu_write(xfd_state, fpstate->xfd); > } > } > diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c > index 8dc7b710e125..8a27b9ae9fc7 100644 > --- a/arch/x86/kernel/hpet.c > +++ b/arch/x86/kernel/hpet.c > @@ -971,7 +971,7 @@ static bool __init hpet_is_pc10_damaged(void) > return false; > > /* Check whether PC10 is enabled in PKG C-state limit */ > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, pcfg); > + pcfg =3D rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > if ((pcfg & 0xF) < 8) > return false; > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c > index 6b0a5861ccb8..8710e3fab693 100644 > --- a/arch/x86/kernel/kvm.c > +++ b/arch/x86/kernel/kvm.c > @@ -740,7 +740,7 @@ static int kvm_suspend(void *data) > > #ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL > if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL)) > - rdmsrq(MSR_KVM_POLL_CONTROL, val); > + val =3D rdmsrq(MSR_KVM_POLL_CONTROL); > has_guest_poll =3D !(val & 1); > #endif > return 0; > diff --git a/arch/x86/kernel/mmconf-fam10h_64.c b/arch/x86/kernel/mmconf-= fam10h_64.c > index ef6104e7cc72..348ac8fce3ad 100644 > --- a/arch/x86/kernel/mmconf-fam10h_64.c > +++ b/arch/x86/kernel/mmconf-fam10h_64.c > @@ -97,7 +97,7 @@ static void get_fam10h_pci_mmconf_base(void) > > /* SYS_CFG */ > address =3D MSR_AMD64_SYSCFG; > - rdmsrq(address, val); > + val =3D rdmsrq(address); > > /* TOP_MEM2 is not enabled? */ > if (!(val & (1<<21))) { > @@ -105,7 +105,7 @@ static void get_fam10h_pci_mmconf_base(void) > } else { > /* TOP_MEM2 */ > address =3D MSR_K8_TOP_MEM2; > - rdmsrq(address, val); > + val =3D rdmsrq(address); > tom2 =3D max(val & 0xffffff800000ULL, 1ULL << 32); > } > > @@ -177,7 +177,7 @@ void fam10h_check_enable_mmcfg(void) > return; > > address =3D MSR_FAM10H_MMIO_CONF_BASE; > - rdmsrq(address, val); > + val =3D rdmsrq(address); > > /* try to make sure that AP's setting is identical to BSP setting= */ > if (val & FAM10H_MMIO_CONF_ENABLE) { > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > index 346c438ac880..85e6b076ef17 100644 > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -730,7 +730,7 @@ void __switch_to_xtra(struct task_struct *prev_p, str= uct task_struct *next_p) > arch_has_block_step()) { > unsigned long debugctl, msk; > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > debugctl &=3D ~DEBUGCTLMSR_BTF; > msk =3D tifn & _TIF_BLOCKSTEP; > debugctl |=3D (msk >> TIF_BLOCKSTEP) << DEBUGCTLMSR_BTF_S= HIFT; > @@ -980,7 +980,7 @@ void __init arch_post_acpi_subsys_init(void) > * the machine is affected K8_INTP_C1E_ACTIVE_MASK bits are set i= n > * MSR_K8_INT_PENDING_MSG. > */ > - rdmsrq(MSR_K8_INT_PENDING_MSG, val); > + val =3D rdmsrq(MSR_K8_INT_PENDING_MSG); > if (!(val & K8_INTP_C1E_ACTIVE_MASK)) > return; > > diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c > index 2bce7b3f97ed..28dbe7e629fc 100644 > --- a/arch/x86/kernel/process_64.c > +++ b/arch/x86/kernel/process_64.c > @@ -97,8 +97,8 @@ void __show_regs(struct pt_regs *regs, enum show_regs_m= ode mode, > return; > > if (mode =3D=3D SHOW_REGS_USER) { > - rdmsrq(MSR_FS_BASE, fs); > - rdmsrq(MSR_KERNEL_GS_BASE, shadowgs); > + fs =3D rdmsrq(MSR_FS_BASE); > + shadowgs =3D rdmsrq(MSR_KERNEL_GS_BASE); > printk("%sFS: %016lx GS: %016lx\n", > log_lvl, fs, shadowgs); > return; > @@ -109,9 +109,9 @@ void __show_regs(struct pt_regs *regs, enum show_regs= _mode mode, > savesegment(fs, fsindex); > savesegment(gs, gsindex); > > - rdmsrq(MSR_FS_BASE, fs); > - rdmsrq(MSR_GS_BASE, gs); > - rdmsrq(MSR_KERNEL_GS_BASE, shadowgs); > + fs =3D rdmsrq(MSR_FS_BASE); > + gs =3D rdmsrq(MSR_GS_BASE); > + shadowgs =3D rdmsrq(MSR_KERNEL_GS_BASE); > > cr0 =3D read_cr0(); > cr2 =3D read_cr2(); > @@ -197,7 +197,7 @@ static noinstr unsigned long __rdgsbase_inactive(void= ) > native_swapgs(); > } else { > instrumentation_begin(); > - rdmsrq(MSR_KERNEL_GS_BASE, gsbase); > + gsbase =3D rdmsrq(MSR_KERNEL_GS_BASE); > instrumentation_end(); > } > > @@ -463,7 +463,7 @@ unsigned long x86_gsbase_read_cpu_inactive(void) > gsbase =3D __rdgsbase_inactive(); > local_irq_restore(flags); > } else { > - rdmsrq(MSR_KERNEL_GS_BASE, gsbase); > + gsbase =3D rdmsrq(MSR_KERNEL_GS_BASE); > } > > return gsbase; > diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c > index 0ca64900192f..f3d1f385c626 100644 > --- a/arch/x86/kernel/shstk.c > +++ b/arch/x86/kernel/shstk.c > @@ -231,7 +231,7 @@ static unsigned long get_user_shstk_addr(void) > > fpregs_lock_and_load(); > > - rdmsrq(MSR_IA32_PL3_SSP, ssp); > + ssp =3D rdmsrq(MSR_IA32_PL3_SSP); > > fpregs_unlock(); > > @@ -248,7 +248,7 @@ int shstk_pop(u64 *val) > > fpregs_lock_and_load(); > > - rdmsrq(MSR_IA32_PL3_SSP, ssp); > + ssp =3D rdmsrq(MSR_IA32_PL3_SSP); > if (val && get_user(*val, (__user u64 *)ssp)) > ret =3D -EFAULT; > else > @@ -268,7 +268,7 @@ int shstk_push(u64 val) > > fpregs_lock_and_load(); > > - rdmsrq(MSR_IA32_PL3_SSP, ssp); > + ssp =3D rdmsrq(MSR_IA32_PL3_SSP); > ssp -=3D SS_FRAME_SIZE; > ret =3D write_user_shstk_64((__user void *)ssp, val); > if (!ret) > @@ -497,7 +497,7 @@ static int wrss_control(bool enable) > return 0; > > fpregs_lock_and_load(); > - rdmsrq(MSR_IA32_U_CET, msrval); > + msrval =3D rdmsrq(MSR_IA32_U_CET); > > if (enable) { > features_set(ARCH_SHSTK_WRSS); > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > index 30aa8369957e..9cd11dc7bb17 100644 > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > @@ -1250,7 +1250,7 @@ static noinstr void exc_debug_kernel(struct pt_regs= *regs, unsigned long dr6) > */ > unsigned long debugctl; > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl =3D rdmsrq(MSR_IA32_DEBUGCTLMSR); > debugctl |=3D DEBUGCTLMSR_BTF; > wrmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > } > @@ -1509,7 +1509,7 @@ static bool handle_xfd_event(struct pt_regs *regs) > if (!IS_ENABLED(CONFIG_X86_64) || !cpu_feature_enabled(X86_FEATUR= E_XFD)) > return false; > > - rdmsrq(MSR_IA32_XFD_ERR, xfd_err); > + xfd_err =3D rdmsrq(MSR_IA32_XFD_ERR); > if (!xfd_err) > return false; > > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > index 723347e2cf7f..39baee2307c3 100644 > --- a/arch/x86/kernel/tsc.c > +++ b/arch/x86/kernel/tsc.c > @@ -1088,7 +1088,7 @@ static void __init detect_art(void) > if (art_base_clk.denominator < ART_MIN_DENOMINATOR) > return; > > - rdmsrq(MSR_IA32_TSC_ADJUST, art_base_clk.offset); > + art_base_clk.offset =3D rdmsrq(MSR_IA32_TSC_ADJUST); > > /* Make this sticky over multiple CPU init calls */ > setup_force_cpu_cap(X86_FEATURE_ART); > diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c > index d74743c8d2a4..6a1d22e8b846 100644 > --- a/arch/x86/kernel/tsc_msr.c > +++ b/arch/x86/kernel/tsc_msr.c > @@ -179,15 +179,15 @@ unsigned long cpu_khz_from_msr(void) > > freq_desc =3D (struct freq_desc *)id->driver_data; > if (freq_desc->use_msr_plat) { > - rdmsrq(MSR_PLATFORM_INFO, val.q); > + val.q =3D rdmsrq(MSR_PLATFORM_INFO); > ratio =3D (val.l >> 8) & 0xff; > } else { > - rdmsrq(MSR_IA32_PERF_STATUS, val.q); > + val.q =3D rdmsrq(MSR_IA32_PERF_STATUS); > ratio =3D (val.h >> 8) & 0x1f; > } > > /* Get FSB FREQ ID */ > - rdmsrq(MSR_FSB_FREQ, val.q); > + val.q =3D rdmsrq(MSR_FSB_FREQ); > index =3D val.l & freq_desc->mask; > md =3D &freq_desc->muldiv[index]; > > diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c > index ec3aa340d351..a21ea3c85f6f 100644 > --- a/arch/x86/kernel/tsc_sync.c > +++ b/arch/x86/kernel/tsc_sync.c > @@ -66,7 +66,7 @@ void tsc_verify_tsc_adjust(bool resume) > > adj->nextcheck =3D jiffies + HZ; > > - rdmsrq(MSR_IA32_TSC_ADJUST, curval); > + curval =3D rdmsrq(MSR_IA32_TSC_ADJUST); > if (adj->adjusted =3D=3D curval) > return; > > @@ -166,7 +166,7 @@ bool __init tsc_store_and_check_tsc_adjust(bool bootc= pu) > if (check_tsc_unstable()) > return false; > > - rdmsrq(MSR_IA32_TSC_ADJUST, bootval); > + bootval =3D rdmsrq(MSR_IA32_TSC_ADJUST); > cur->bootval =3D bootval; > cur->nextcheck =3D jiffies + HZ; > tsc_sanitize_first_cpu(cur, bootval, smp_processor_id(), bootcpu)= ; > @@ -188,7 +188,7 @@ bool tsc_store_and_check_tsc_adjust(bool bootcpu) > if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST)) > return false; > > - rdmsrq(MSR_IA32_TSC_ADJUST, bootval); > + bootval =3D rdmsrq(MSR_IA32_TSC_ADJUST); > cur->bootval =3D bootval; > cur->nextcheck =3D jiffies + HZ; > cur->warned =3D false; > diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c > index dd3bb04878ca..59c19c534564 100644 > --- a/arch/x86/kvm/msrs.c > +++ b/arch/x86/kvm/msrs.c > @@ -1205,7 +1205,7 @@ static __always_inline void kvm_access_xstate_msr(s= truct kvm_vcpu *vcpu, > > kvm_fpu_get(); > if (access =3D=3D MSR_TYPE_R) > - rdmsrq(msr_info->index, msr_info->data); > + msr_info->data =3D rdmsrq(msr_info->index); > else > wrmsrq(msr_info->index, msr_info->data); > kvm_fpu_put(); > diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c > index c18286545a7a..5ebee82dba84 100644 > --- a/arch/x86/kvm/svm/pmu.c > +++ b/arch/x86/kvm/svm/pmu.c > @@ -249,7 +249,7 @@ static void amd_mediated_pmu_load(struct kvm_vcpu *vc= pu) > struct kvm_pmu *pmu =3D vcpu_to_pmu(vcpu); > u64 global_status; > > - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, global_status); > + global_status =3D rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); > /* Clear host global_status MSR if non-zero. */ > if (global_status) > wrmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS_CLR, global_stat= us); > @@ -263,7 +263,7 @@ static void amd_mediated_pmu_put(struct kvm_vcpu *vcp= u) > struct kvm_pmu *pmu =3D vcpu_to_pmu(vcpu); > > wrmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL, 0); > - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, pmu->global_status); > + pmu->global_status =3D rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); > > /* Clear global status bits if non-zero */ > if (pmu->global_status) > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 7d59d301e1e5..91f5a5344529 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -4637,7 +4637,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kv= m_vcpu *vcpu, u64 run_flags) > kvm_clear_available_registers(vcpu, SVM_REGS_LAZY_LOAD_SET); > > if (!msr_write_intercepted(svm, MSR_AMD64_PERF_CNTR_GLOBAL_CTL)) > - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL, vcpu_to_pmu(vcpu)-= >global_ctrl); > + vcpu_to_pmu(vcpu)->global_ctrl =3D rdmsrq(MSR_AMD64_PERF_= CNTR_GLOBAL_CTL); > > trace_kvm_exit(vcpu, KVM_ISA_SVM); > > @@ -5485,7 +5485,7 @@ static __init void svm_adjust_mmio_mask(void) > return; > > /* If memory encryption is not enabled, use existing mask */ > - rdmsrq(MSR_AMD64_SYSCFG, msr); > + msr =3D rdmsrq(MSR_AMD64_SYSCFG); > if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT)) > return; > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > index 151873407abd..3f06d6742f0e 100644 > --- a/arch/x86/kvm/vmx/nested.c > +++ b/arch/x86/kvm/vmx/nested.c > @@ -7358,8 +7358,8 @@ static void nested_vmx_setup_cr_fixed(struct nested= _vmx_msrs *msrs) > msrs->cr4_fixed0 =3D VMXON_CR4_ALWAYSON; > > /* These MSRs specify bits which the guest must keep fixed off. *= / > - rdmsrq(MSR_IA32_VMX_CR0_FIXED1, msrs->cr0_fixed1); > - rdmsrq(MSR_IA32_VMX_CR4_FIXED1, msrs->cr4_fixed1); > + msrs->cr0_fixed1 =3D rdmsrq(MSR_IA32_VMX_CR0_FIXED1); > + msrs->cr4_fixed1 =3D rdmsrq(MSR_IA32_VMX_CR4_FIXED1); > > if (vmx_umip_emulated()) > msrs->cr4_fixed1 |=3D X86_CR4_UMIP; > diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c > index bfa8612fb450..24cfbb8f5078 100644 > --- a/arch/x86/kvm/vmx/pmu_intel.c > +++ b/arch/x86/kvm/vmx/pmu_intel.c > @@ -320,7 +320,7 @@ static bool intel_pmu_handle_lbr_msrs_access(struct k= vm_vcpu *vcpu, > int err =3D 0; > > if (read) > - rdmsrq(index, msr_info->data); > + msr_info->data =3D rdmsrq(index); > else > err =3D wrmsrq_safe(index, msr_info->data); > __set_bit(INTEL_PMC_IDX_FIXED_VLBR, vcpu_to_pmu(vcpu)->pm= c_in_use); > @@ -772,7 +772,7 @@ static bool intel_pmu_is_mediated_pmu_supported(struc= t x86_pmu_capability *host_ > u64 host_perf_cap =3D 0; > > if (boot_cpu_has(X86_FEATURE_PDCM)) > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, host_perf_cap); > + host_perf_cap =3D rdmsrq(MSR_IA32_PERF_CAPABILITIES); > > /* > * Require v4+ for MSR_CORE_PERF_GLOBAL_STATUS_SET, and full-widt= h > @@ -801,7 +801,7 @@ static void intel_mediated_pmu_load(struct kvm_vcpu *= vcpu) > struct kvm_pmu *pmu =3D vcpu_to_pmu(vcpu); > u64 global_status, toggle; > > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, global_status); > + global_status =3D rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > toggle =3D pmu->global_status ^ global_status; > if (global_status & toggle) > wrmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, global_status & tog= gle); > @@ -816,7 +816,7 @@ static void intel_mediated_pmu_put(struct kvm_vcpu *v= cpu) > struct kvm_pmu *pmu =3D vcpu_to_pmu(vcpu); > > /* MSR_CORE_PERF_GLOBAL_CTRL is already saved at VM-exit. */ > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, pmu->global_status); > + pmu->global_status =3D rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > > /* Clear hardware MSR_CORE_PERF_GLOBAL_STATUS MSR, if non-zero. *= / > if (pmu->global_status) > diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c > index 771c75a58343..765cac151023 100644 > --- a/arch/x86/kvm/vmx/sgx.c > +++ b/arch/x86/kvm/vmx/sgx.c > @@ -420,9 +420,9 @@ void setup_default_sgx_lepubkeyhash(void) > sgx_pubkey_hash[3] =3D 0xd4f8c05909f9bb3bULL; > } else { > /* MSR_IA32_SGXLEPUBKEYHASH0 is read above */ > - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH1, sgx_pubkey_hash[1]); > - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH2, sgx_pubkey_hash[2]); > - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH3, sgx_pubkey_hash[3]); > + sgx_pubkey_hash[1] =3D rdmsrq(MSR_IA32_SGXLEPUBKEYHASH1); > + sgx_pubkey_hash[2] =3D rdmsrq(MSR_IA32_SGXLEPUBKEYHASH2); > + sgx_pubkey_hash[3] =3D rdmsrq(MSR_IA32_SGXLEPUBKEYHASH3); > } > } > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index 612ab07d4100..2c8487bbda6a 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -1261,13 +1261,13 @@ static inline void pt_save_msr(struct pt_ctx *ctx= , u32 addr_range) > { > u32 i; > > - rdmsrq(MSR_IA32_RTIT_STATUS, ctx->status); > - rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE, ctx->output_base); > - rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK, ctx->output_mask); > - rdmsrq(MSR_IA32_RTIT_CR3_MATCH, ctx->cr3_match); > + ctx->status =3D rdmsrq(MSR_IA32_RTIT_STATUS); > + ctx->output_base =3D rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE); > + ctx->output_mask =3D rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK); > + ctx->cr3_match =3D rdmsrq(MSR_IA32_RTIT_CR3_MATCH); > for (i =3D 0; i < addr_range; i++) { > - rdmsrq(MSR_IA32_RTIT_ADDR0_A + i * 2, ctx->addr_a[i]); > - rdmsrq(MSR_IA32_RTIT_ADDR0_B + i * 2, ctx->addr_b[i]); > + ctx->addr_a[i] =3D rdmsrq(MSR_IA32_RTIT_ADDR0_A + i * 2); > + ctx->addr_b[i] =3D rdmsrq(MSR_IA32_RTIT_ADDR0_B + i * 2); > } > } > > @@ -1280,7 +1280,7 @@ static void pt_guest_enter(struct vcpu_vmx *vmx) > * GUEST_IA32_RTIT_CTL is already set in the VMCS. > * Save host state before VM entry. > */ > - rdmsrq(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl); > + vmx->pt_desc.host.ctl =3D rdmsrq(MSR_IA32_RTIT_CTL); > if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) { > wrmsrq(MSR_IA32_RTIT_CTL, 0); > pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.num_address_= ranges); > @@ -1418,7 +1418,7 @@ static void vmx_prepare_switch_to_host(struct vcpu_= vmx *vmx) > ++vmx->vcpu.stat.host_state_reload; > > #ifdef CONFIG_X86_64 > - rdmsrq(MSR_KERNEL_GS_BASE, vmx->msr_guest_kernel_gs_base); > + vmx->msr_guest_kernel_gs_base =3D rdmsrq(MSR_KERNEL_GS_BASE); > #endif > if (host_state->ldt_sel || (host_state->gs_sel & 7)) { > vmx_load_ldt(host_state->ldt_sel); > @@ -2694,7 +2694,7 @@ static int adjust_vmx_controls(u32 ctl_min, u32 ctl= _opt, u32 msr, u32 *result) > struct msr vmx_msr; > u32 ctl =3D ctl_min | ctl_opt; > > - rdmsrq(msr, vmx_msr.q); > + vmx_msr.q =3D rdmsrq(msr); > > ctl &=3D vmx_msr.h; /* bit =3D=3D 0 in high word =3D=3D> must be= zero */ > ctl |=3D vmx_msr.l; /* bit =3D=3D 1 in low word =3D=3D> must be= one */ > @@ -2711,7 +2711,7 @@ static u64 adjust_vmx_controls64(u64 ctl_opt, u32 m= sr) > { > u64 allowed; > > - rdmsrq(msr, allowed); > + allowed =3D rdmsrq(msr); > > return ctl_opt & allowed; > } > @@ -2897,7 +2897,7 @@ static int setup_vmcs_config(struct vmcs_config *vm= cs_conf, > break; > } > > - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); > + basic_msr =3D rdmsrq(MSR_IA32_VMX_BASIC); > > /* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */ > if (vmx_basic_vmcs_size(basic_msr) > PAGE_SIZE) > @@ -2917,7 +2917,7 @@ static int setup_vmcs_config(struct vmcs_config *vm= cs_conf, > if (vmx_basic_vmcs_mem_type(basic_msr) !=3D X86_MEMTYPE_WB) > return -EIO; > > - rdmsrq(MSR_IA32_VMX_MISC, misc_msr); > + misc_msr =3D rdmsrq(MSR_IA32_VMX_MISC); > > vmcs_conf->basic =3D basic_msr; > vmcs_conf->pin_based_exec_ctrl =3D _pin_based_exec_control; > @@ -4494,7 +4494,7 @@ void vmx_set_constant_host_state(struct vcpu_vmx *v= mx) > > vmcs_writel(HOST_RIP, (unsigned long)vmx_vmexit); /* 22.2.5 */ > > - rdmsrq(MSR_IA32_SYSENTER_CS, val.q); > + val.q =3D rdmsrq(MSR_IA32_SYSENTER_CS); > vmcs_write32(HOST_IA32_SYSENTER_CS, val.l); > > /* > @@ -4506,11 +4506,11 @@ void vmx_set_constant_host_state(struct vcpu_vmx = *vmx) > if (!IS_ENABLED(CONFIG_IA32_EMULATION) && !IS_ENABLED(CONFIG_X86_= 32)) > vmcs_writel(HOST_IA32_SYSENTER_ESP, 0); > > - rdmsrq(MSR_IA32_SYSENTER_EIP, tmpl); > + tmpl =3D rdmsrq(MSR_IA32_SYSENTER_EIP); > vmcs_writel(HOST_IA32_SYSENTER_EIP, tmpl); /* 22.2.3 */ > > if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_PAT) { > - rdmsrq(MSR_IA32_CR_PAT, val.q); > + val.q =3D rdmsrq(MSR_IA32_CR_PAT); > vmcs_write64(HOST_IA32_PAT, val.q); > } > > @@ -7161,7 +7161,7 @@ static void handle_nm_fault_irqoff(struct kvm_vcpu = *vcpu) > * the #NM exception. > */ > if (is_xfd_nm_fault(vcpu)) > - rdmsrq(MSR_IA32_XFD_ERR, vcpu->arch.guest_fpu.xfd_err); > + vcpu->arch.guest_fpu.xfd_err =3D rdmsrq(MSR_IA32_XFD_ERR)= ; > } > > static void handle_exception_irqoff(struct kvm_vcpu *vcpu, u32 intr_info= ) > @@ -8031,7 +8031,7 @@ static __init u64 vmx_get_perf_capabilities(void) > return 0; > > if (boot_cpu_has(X86_FEATURE_PDCM)) > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, host_perf_cap); > + host_perf_cap =3D rdmsrq(MSR_IA32_PERF_CAPABILITIES); > > if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR) && > !enable_mediated_pmu) { > @@ -8680,7 +8680,7 @@ __init int vmx_hardware_setup(void) > vmx_setup_user_return_msrs(); > > if (boot_cpu_has(X86_FEATURE_MPX)) { > - rdmsrq(MSR_IA32_BNDCFGS, host_bndcfgs); > + host_bndcfgs =3D rdmsrq(MSR_IA32_BNDCFGS); > WARN_ONCE(host_bndcfgs, "BNDCFGS in host will be lost"); > } > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 79468ddfe473..6bbeb9b6e4b9 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -7037,7 +7037,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *op= s) > } > > if (boot_cpu_has(X86_FEATURE_SHSTK) || boot_cpu_has(X86_FEATURE_I= BT)) { > - rdmsrq(MSR_IA32_S_CET, kvm_host.s_cet); > + kvm_host.s_cet =3D rdmsrq(MSR_IA32_S_CET); > /* > * Linux doesn't yet support supervisor shadow stacks (SS= S), so > * KVM doesn't save/restore the associated MSRs, i.e. KVM= may > @@ -7069,7 +7069,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *op= s) > } > > if (boot_cpu_has(X86_FEATURE_XSAVES)) { > - rdmsrq(MSR_IA32_XSS, kvm_host.xss); > + kvm_host.xss =3D rdmsrq(MSR_IA32_XSS); > kvm_caps.supported_xss =3D kvm_host.xss & KVM_SUPPORTED_X= SS; > } > > @@ -7081,7 +7081,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *op= s) > kvm_init_pmu_capability(ops->pmu_ops); > > if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) > - rdmsrq(MSR_IA32_ARCH_CAPABILITIES, kvm_host.arch_capabili= ties); > + kvm_host.arch_capabilities =3D rdmsrq(MSR_IA32_ARCH_CAPAB= ILITIES); > > WARN_ON_ONCE(kvm_nr_uret_msrs); > > diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c > index e03eeec55cfe..b9db2012a75e 100644 > --- a/arch/x86/lib/insn-eval.c > +++ b/arch/x86/lib/insn-eval.c > @@ -709,16 +709,16 @@ unsigned long insn_get_seg_base(struct pt_regs *reg= s, int seg_reg_idx) > unsigned long base; > > if (seg_reg_idx =3D=3D INAT_SEG_REG_FS) { > - rdmsrq(MSR_FS_BASE, base); > + base =3D rdmsrq(MSR_FS_BASE); > } else if (seg_reg_idx =3D=3D INAT_SEG_REG_GS) { > /* > * swapgs was called at the kernel entry point. T= hus, > * MSR_KERNEL_GS_BASE will have the user-space GS= base. > */ > if (user_mode(regs)) > - rdmsrq(MSR_KERNEL_GS_BASE, base); > + base =3D rdmsrq(MSR_KERNEL_GS_BASE); > else > - rdmsrq(MSR_GS_BASE, base); > + base =3D rdmsrq(MSR_GS_BASE); > } else { > base =3D 0; > } > diff --git a/arch/x86/lib/msr-smp.c b/arch/x86/lib/msr-smp.c > index 7b6cfc2c0970..ddff68050322 100644 > --- a/arch/x86/lib/msr-smp.c > +++ b/arch/x86/lib/msr-smp.c > @@ -15,7 +15,7 @@ static void __rdmsr_on_cpu(void *info) > else > reg =3D &rv->reg; > > - rdmsrq(rv->msr_no, reg->q); > + reg->q =3D rdmsrq(rv->msr_no); > } > > static void __wrmsr_on_cpu(void *info) > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c > index cf94fb561310..114853c212ed 100644 > --- a/arch/x86/mm/pat/memtype.c > +++ b/arch/x86/mm/pat/memtype.c > @@ -257,7 +257,7 @@ void __init pat_bp_init(void) > if (!cpu_feature_enabled(X86_FEATURE_PAT)) > pat_disable("PAT not supported by the CPU."); > else > - rdmsrq(MSR_IA32_CR_PAT, pat_msr_val); > + pat_msr_val =3D rdmsrq(MSR_IA32_CR_PAT); > > if (!pat_msr_val) { > pat_disable("PAT support disabled by the firmware."); > diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c > index 99b1727136c1..342371081f60 100644 > --- a/arch/x86/pci/amd_bus.c > +++ b/arch/x86/pci/amd_bus.c > @@ -202,7 +202,7 @@ static int __init early_root_info_init(void) > > /* need to take out [0, TOM) for RAM*/ > address =3D MSR_K8_TOP_MEM1; > - rdmsrq(address, val); > + val =3D rdmsrq(address); > end =3D (val & 0xffffff800000ULL); > printk(KERN_INFO "TOM: %016llx aka %lldM\n", end, end>>20); > if (end < (1ULL<<32)) > @@ -293,12 +293,12 @@ static int __init early_root_info_init(void) > /* need to take out [4G, TOM2) for RAM*/ > /* SYS_CFG */ > address =3D MSR_AMD64_SYSCFG; > - rdmsrq(address, val); > + val =3D rdmsrq(address); > /* TOP_MEM2 is enabled? */ > if (val & (1<<21)) { > /* TOP_MEM2 */ > address =3D MSR_K8_TOP_MEM2; > - rdmsrq(address, val); > + val =3D rdmsrq(address); > end =3D (val & 0xffffff800000ULL); > printk(KERN_INFO "TOM2: %016llx aka %lldM\n", end, end>>2= 0); > subtract_range(range, RANGE_NUM, 1ULL<<32, end); > @@ -341,7 +341,7 @@ static int amd_bus_cpu_online(unsigned int cpu) > { > u64 reg; > > - rdmsrq(MSR_AMD64_NB_CFG, reg); > + reg =3D rdmsrq(MSR_AMD64_NB_CFG); > if (!(reg & ENABLE_CF8_EXT_CFG)) { > reg |=3D ENABLE_CF8_EXT_CFG; > wrmsrq(MSR_AMD64_NB_CFG, reg); > diff --git a/arch/x86/platform/olpc/olpc-xo1-rtc.c b/arch/x86/platform/ol= pc/olpc-xo1-rtc.c > index ee77d57bcab7..95dfd90b1f05 100644 > --- a/arch/x86/platform/olpc/olpc-xo1-rtc.c > +++ b/arch/x86/platform/olpc/olpc-xo1-rtc.c > @@ -64,9 +64,9 @@ static int __init xo1_rtc_init(void) > of_node_put(node); > > pr_info("olpc-xo1-rtc: Initializing OLPC XO-1 RTC\n"); > - rdmsrq(MSR_RTC_DOMA_OFFSET, rtc_info.rtc_day_alarm); > - rdmsrq(MSR_RTC_MONA_OFFSET, rtc_info.rtc_mon_alarm); > - rdmsrq(MSR_RTC_CEN_OFFSET, rtc_info.rtc_century); > + rtc_info.rtc_day_alarm =3D rdmsrq(MSR_RTC_DOMA_OFFSET); > + rtc_info.rtc_mon_alarm =3D rdmsrq(MSR_RTC_MONA_OFFSET); > + rtc_info.rtc_century =3D rdmsrq(MSR_RTC_CEN_OFFSET); > > r =3D platform_device_register(&xo1_rtc_device); > if (r) > diff --git a/arch/x86/platform/olpc/olpc-xo1-sci.c b/arch/x86/platform/ol= pc/olpc-xo1-sci.c > index 8b5b3626b559..d2b63a7c0fe6 100644 > --- a/arch/x86/platform/olpc/olpc-xo1-sci.c > +++ b/arch/x86/platform/olpc/olpc-xo1-sci.c > @@ -316,7 +316,7 @@ static int setup_sci_interrupt(struct platform_device= *pdev) > u32 sts; > int r; > > - rdmsrq(0x51400020, msr); > + msr =3D rdmsrq(0x51400020); > sci_irq =3D (msr >> 20) & 15; > > if (sci_irq) { > diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c > index 702f30eaf9c4..f44ebe2fe099 100644 > --- a/arch/x86/power/cpu.c > +++ b/arch/x86/power/cpu.c > @@ -45,7 +45,7 @@ static void msr_save_context(struct saved_context *ctxt= ) > > while (msr < end) { > if (msr->valid) > - rdmsrq(msr->info.msr_no, msr->info.reg.q); > + msr->info.reg.q =3D rdmsrq(msr->info.msr_no); > msr++; > } > } > @@ -111,12 +111,12 @@ static void __save_processor_state(struct saved_con= text *ctxt) > savesegment(ds, ctxt->ds); > savesegment(es, ctxt->es); > > - rdmsrq(MSR_FS_BASE, ctxt->fs_base); > - rdmsrq(MSR_GS_BASE, ctxt->kernelmode_gs_base); > - rdmsrq(MSR_KERNEL_GS_BASE, ctxt->usermode_gs_base); > + ctxt->fs_base =3D rdmsrq(MSR_FS_BASE); > + ctxt->kernelmode_gs_base =3D rdmsrq(MSR_GS_BASE); > + ctxt->usermode_gs_base =3D rdmsrq(MSR_KERNEL_GS_BASE); > mtrr_save_fixed_ranges(NULL); > > - rdmsrq(MSR_EFER, ctxt->efer); > + ctxt->efer =3D rdmsrq(MSR_EFER); > #endif > > /* > diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c > index 694d80a5c68e..469f2aa8e105 100644 > --- a/arch/x86/realmode/init.c > +++ b/arch/x86/realmode/init.c > @@ -147,7 +147,7 @@ static void __init setup_real_mode(void) > * Some AMD processors will #GP(0) if EFER.LMA is set in WRMSR > * so we need to mask it out. > */ > - rdmsrq(MSR_EFER, efer); > + efer =3D rdmsrq(MSR_EFER); > trampoline_header->efer =3D efer & ~EFER_LMA; > > trampoline_header->start =3D (u64) secondary_startup_64; > diff --git a/arch/x86/virt/hw.c b/arch/x86/virt/hw.c > index a236447ac7a2..a0f5ecb5b946 100644 > --- a/arch/x86/virt/hw.c > +++ b/arch/x86/virt/hw.c > @@ -178,7 +178,7 @@ static __init int __x86_vmx_init(void) > if (!cpu_feature_enabled(X86_FEATURE_VMX)) > return -EOPNOTSUPP; > > - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); > + basic_msr =3D rdmsrq(MSR_IA32_VMX_BASIC); > > /* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */ > if (WARN_ON_ONCE(vmx_basic_vmcs_size(basic_msr) > PAGE_SIZE)) > @@ -230,7 +230,7 @@ static int x86_svm_enable_virtualization_cpu(void) > { > u64 efer; > > - rdmsrq(MSR_EFER, efer); > + efer =3D rdmsrq(MSR_EFER); > if (efer & EFER_SVME) > return -EBUSY; > > @@ -253,7 +253,7 @@ static int x86_svm_disable_virtualization_cpu(void) > r =3D 0; > > fault: > - rdmsrq(MSR_EFER, efer); > + efer =3D rdmsrq(MSR_EFER); > wrmsrq(MSR_EFER, efer & ~EFER_SVME); > return r; > } > @@ -264,7 +264,7 @@ static void x86_svm_emergency_disable_virtualization_= cpu(void) > > virt_rebooting =3D true; > > - rdmsrq(MSR_EFER, efer); > + efer =3D rdmsrq(MSR_EFER); > if (!(efer & EFER_SVME)) > return; > > diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c > index cff285d8ad8e..4a1e75d66e6c 100644 > --- a/arch/x86/virt/svm/sev.c > +++ b/arch/x86/virt/svm/sev.c > @@ -150,7 +150,7 @@ static void snp_enable(void *arg) > if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP)) > return; > > - rdmsrq(MSR_AMD64_SYSCFG, val); > + val =3D rdmsrq(MSR_AMD64_SYSCFG); > > val |=3D MSR_AMD64_SYSCFG_SNP_EN; > val |=3D MSR_AMD64_SYSCFG_SNP_VMPL_EN; > @@ -254,7 +254,7 @@ static void clear_rmp(void) > return; > > /* Clearing the RMP while SNP is enabled will cause an exception = */ > - rdmsrq(MSR_AMD64_SYSCFG, val); > + val =3D rdmsrq(MSR_AMD64_SYSCFG); > if (WARN_ON_ONCE(val & MSR_AMD64_SYSCFG_SNP_EN)) > return; > > @@ -520,7 +520,7 @@ int snp_prepare(void) > * Check if SEV-SNP is already enabled, this can happen in case o= f > * kexec boot. > */ > - rdmsrq(MSR_AMD64_SYSCFG, val); > + val =3D rdmsrq(MSR_AMD64_SYSCFG); > if (val & MSR_AMD64_SYSCFG_SNP_EN) > return 0; > > @@ -561,7 +561,7 @@ void snp_shutdown(void) > { > u64 syscfg; > > - rdmsrq(MSR_AMD64_SYSCFG, syscfg); > + syscfg =3D rdmsrq(MSR_AMD64_SYSCFG); > if (syscfg & MSR_AMD64_SYSCFG_SNP_EN) > return; > > @@ -608,8 +608,8 @@ static bool probe_contiguous_rmptable_info(void) > { > u64 rmp_sz, rmp_base, rmp_end; > > - rdmsrq(MSR_AMD64_RMP_BASE, rmp_base); > - rdmsrq(MSR_AMD64_RMP_END, rmp_end); > + rmp_base =3D rdmsrq(MSR_AMD64_RMP_BASE); > + rmp_end =3D rdmsrq(MSR_AMD64_RMP_END); > > if (!(rmp_base & RMP_ADDR_MASK) || !(rmp_end & RMP_ADDR_MASK)) { > pr_err("Memory for the RMP table has not been reserved by= BIOS\n"); > @@ -642,13 +642,13 @@ static bool probe_segmented_rmptable_info(void) > unsigned int eax, ebx, segment_shift, segment_shift_min, segment_= shift_max; > u64 rmp_base, rmp_end; > > - rdmsrq(MSR_AMD64_RMP_BASE, rmp_base); > + rmp_base =3D rdmsrq(MSR_AMD64_RMP_BASE); > if (!(rmp_base & RMP_ADDR_MASK)) { > pr_err("Memory for the RMP table has not been reserved by= BIOS\n"); > return false; > } > > - rdmsrq(MSR_AMD64_RMP_END, rmp_end); > + rmp_end =3D rdmsrq(MSR_AMD64_RMP_END); > WARN_ONCE(rmp_end & RMP_ADDR_MASK, > "Segmented RMP enabled but RMP_END MSR is non-zero\n"); > > @@ -684,7 +684,7 @@ static bool probe_segmented_rmptable_info(void) > bool snp_probe_rmptable_info(void) > { > if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) > - rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg); > + rmp_cfg =3D rdmsrq(MSR_AMD64_RMP_CFG); > > if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) > return probe_segmented_rmptable_info(); > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c > index 1b9ff749dd8e..9839f5b8dcc3 100644 > --- a/arch/x86/virt/vmx/tdx/tdx.c > +++ b/arch/x86/virt/vmx/tdx/tdx.c > @@ -1523,7 +1523,7 @@ static void __init check_tdx_erratum(void) > * Some TDX-capable CPUs have an erratum where the current VMCS i= s > * cleared after calling into P-SEAMLDR. > */ > - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); > + basic_msr =3D rdmsrq(MSR_IA32_VMX_BASIC); > if (!(basic_msr & VMX_BASIC_NO_SEAMRET_INVD_VMCS)) > setup_force_cpu_bug(X86_BUG_SEAMRET_INVD_VMCS); > } > diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c > index ba2f17e64321..b0e1152aa80e 100644 > --- a/arch/x86/xen/suspend.c > +++ b/arch/x86/xen/suspend.c > @@ -56,7 +56,7 @@ static void xen_vcpu_notify_suspend(void *data) > tick_suspend_local(); > > if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { > - rdmsrq(MSR_IA32_SPEC_CTRL, tmp); > + tmp =3D rdmsrq(MSR_IA32_SPEC_CTRL); > this_cpu_write(spec_ctrl, tmp); > wrmsrq(MSR_IA32_SPEC_CTRL, 0); > } > diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_pe= rflib.c > index 9e25d6124efd..535a0f9dd2cf 100644 > --- a/drivers/acpi/processor_perflib.c > +++ b/drivers/acpi/processor_perflib.c > @@ -296,7 +296,7 @@ static void amd_fixup_frequency(struct acpi_processor= _px *px, int i) > > if ((boot_cpu_data.x86 =3D=3D 0x10 && boot_cpu_data.x86_model < 1= 0) || > boot_cpu_data.x86 =3D=3D 0x11) { > - rdmsrq(MSR_AMD_PSTATE_DEF_BASE + index, val.q); > + val.q =3D rdmsrq(MSR_AMD_PSTATE_DEF_BASE + index); > /* > * MSR C001_0064+: > * Bit 63: PstateEn. Read-write. If set, the P-state is v= alid. > diff --git a/drivers/ata/pata_cs5535.c b/drivers/ata/pata_cs5535.c > index 512f9728224f..5ca17faa8e6e 100644 > --- a/drivers/ata/pata_cs5535.c > +++ b/drivers/ata/pata_cs5535.c > @@ -110,7 +110,7 @@ static void cs5535_set_piomode(struct ata_port *ap, s= truct ata_device *adev) > pio_cmd_timings[cmdmode] | pio_timings[mode]); > > /* Set the PIO "format 1" bit in the DMA timing register */ > - rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg); > + reg =3D rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno); > wrmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg | 0x80000000UL); > } > > @@ -132,7 +132,7 @@ static void cs5535_set_dmamode(struct ata_port *ap, s= truct ata_device *adev) > u32 reg; > int mode =3D adev->dma_mode; > > - rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg); > + reg =3D rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno); > reg &=3D 0x80000000UL; > if (mode >=3D XFER_UDMA_0) > reg |=3D udma_timings[mode - XFER_UDMA_0]; > diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c > index 61d232a82b5e..eca97dce1e85 100644 > --- a/drivers/ata/pata_cs5536.c > +++ b/drivers/ata/pata_cs5536.c > @@ -84,7 +84,7 @@ static int cs5536_read(struct pci_dev *pdev, int reg, u= 32 *val) > { > #ifdef MAYBE_USE_MSR > if (unlikely(use_msr)) { > - rdmsrq(MSR_IDE_CFG + reg, *val); > + *val =3D rdmsrq(MSR_IDE_CFG + reg); > return 0; > } > #endif > diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.= c > index 3e760bc00afa..f646f1854981 100644 > --- a/drivers/char/agp/nvidia-agp.c > +++ b/drivers/char/agp/nvidia-agp.c > @@ -72,8 +72,8 @@ static int nvidia_init_iorr(u32 base, u32 size) > /* If not found, determine the uppermost available iorr */ > free_iorr_addr =3D AMD_K7_NUM_IORR; > for (iorr_addr =3D 0; iorr_addr < AMD_K7_NUM_IORR; iorr_addr++) { > - rdmsrq(IORR_BASE0 + 2 * iorr_addr, base_msr.q); > - rdmsrq(IORR_MASK0 + 2 * iorr_addr, mask_msr.q); > + base_msr.q =3D rdmsrq(IORR_BASE0 + 2 * iorr_addr); > + mask_msr.q =3D rdmsrq(IORR_MASK0 + 2 * iorr_addr); > > if ((base_msr.l & 0xfffff000) =3D=3D (base & 0xfffff000)) > break; > @@ -94,7 +94,7 @@ static int nvidia_init_iorr(u32 base, u32 size) > wrmsrq(IORR_BASE0 + 2 * iorr_addr, base_msr.q); > wrmsrq(IORR_MASK0 + 2 * iorr_addr, mask_msr.q); > > - rdmsrq(SYSCFG, sys_msr.q); > + sys_msr.q =3D rdmsrq(SYSCFG); > sys_msr.l |=3D 0x00100000; > wrmsrq(SYSCFG, sys_msr.q); > > diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/vi= a-rng.c > index b718e78d3c1c..a0a3488a6947 100644 > --- a/drivers/char/hw_random/via-rng.c > +++ b/drivers/char/hw_random/via-rng.c > @@ -151,7 +151,7 @@ static int via_rng_init(struct hwrng *rng) > * does not say to write them as zero, so I make a guess that > * we restore the values we find in the register. > */ > - rdmsrq(MSR_VIA_RNG, val.q); > + val.q =3D rdmsrq(MSR_VIA_RNG); > > old_lo =3D val.l; > val.l &=3D ~(0x7f << VIA_STRFILT_CNT_SHIFT); > @@ -175,7 +175,7 @@ static int via_rng_init(struct hwrng *rng) > > /* perhaps-unnecessary sanity check; remove after testing if > unneeded */ > - rdmsrq(MSR_VIA_RNG, val.q); > + val.q =3D rdmsrq(MSR_VIA_RNG); > if ((val.l & VIA_RNG_ENABLE) =3D=3D 0) { > pr_err(PFX "cannot enable VIA C3 RNG, aborting\n"); > return -ENODEV; > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufre= q.c > index 10ea6035f4ad..e1ee80ecd0bb 100644 > --- a/drivers/cpufreq/acpi-cpufreq.c > +++ b/drivers/cpufreq/acpi-cpufreq.c > @@ -110,7 +110,7 @@ static int boost_set_msr(bool enable) > return -EINVAL; > } > > - rdmsrq(msr_addr, val); > + val =3D rdmsrq(msr_addr); > > if (enable) > val &=3D ~msr_mask; > @@ -248,7 +248,7 @@ static u32 cpu_freq_read_intel(struct acpi_pct_regist= er *not_used) > { > u64 val; > > - rdmsrq(MSR_IA32_PERF_CTL, val); > + val =3D rdmsrq(MSR_IA32_PERF_CTL); > return (u32)val; > } > > @@ -256,7 +256,7 @@ static void cpu_freq_write_intel(struct acpi_pct_regi= ster *not_used, u32 val) > { > u64 msrval; > > - rdmsrq(MSR_IA32_PERF_CTL, msrval); > + msrval =3D rdmsrq(MSR_IA32_PERF_CTL); > msrval =3D (msrval & ~(u64)INTEL_MSR_RANGE) | (val & INTEL_MSR_RA= NGE); > wrmsrq(MSR_IA32_PERF_CTL, msrval); > } > @@ -265,7 +265,7 @@ static u32 cpu_freq_read_amd(struct acpi_pct_register= *not_used) > { > u64 val; > > - rdmsrq(MSR_AMD_PERF_CTL, val); > + val =3D rdmsrq(MSR_AMD_PERF_CTL); > return (u32)val; > } > > diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c > index 8bfd46d60843..53838c7470c7 100644 > --- a/drivers/cpufreq/amd-pstate.c > +++ b/drivers/cpufreq/amd-pstate.c > @@ -596,8 +596,8 @@ static inline bool amd_pstate_sample(struct amd_cpuda= ta *cpudata) > unsigned long flags; > > local_irq_save(flags); > - rdmsrq(MSR_IA32_APERF, aperf); > - rdmsrq(MSR_IA32_MPERF, mperf); > + aperf =3D rdmsrq(MSR_IA32_APERF); > + mperf =3D rdmsrq(MSR_IA32_MPERF); > tsc =3D rdtsc(); > > if (cpudata->prev.mperf =3D=3D mperf || cpudata->prev.tsc =3D=3D = tsc) { > diff --git a/drivers/cpufreq/e_powersaver.c b/drivers/cpufreq/e_powersave= r.c > index 54689ebadeb2..cc05494ac316 100644 > --- a/drivers/cpufreq/e_powersaver.c > +++ b/drivers/cpufreq/e_powersaver.c > @@ -99,7 +99,7 @@ static unsigned int eps_get(unsigned int cpu) > return 0; > > /* Return current frequency */ > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val =3D rdmsrq(MSR_IA32_PERF_STATUS); > return centaur->fsb * ((val >> 8) & 0xff); > } > > @@ -111,11 +111,11 @@ static int eps_set_state(struct eps_cpu_data *centa= ur, > int i; > > /* Wait while CPU is busy */ > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val =3D rdmsrq(MSR_IA32_PERF_STATUS); > i =3D 0; > while (val & ((1 << 16) | (1 << 17))) { > udelay(16); > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val =3D rdmsrq(MSR_IA32_PERF_STATUS); > i++; > if (unlikely(i > 64)) { > return -ENODEV; > @@ -127,7 +127,7 @@ static int eps_set_state(struct eps_cpu_data *centaur= , > i =3D 0; > do { > udelay(16); > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val =3D rdmsrq(MSR_IA32_PERF_STATUS); > i++; > if (unlikely(i > 64)) { > return -ENODEV; > @@ -139,7 +139,7 @@ static int eps_set_state(struct eps_cpu_data *centaur= , > u8 current_multiplier, current_voltage; > > /* Print voltage and multiplier */ > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val =3D rdmsrq(MSR_IA32_PERF_STATUS); > current_voltage =3D val & 0xff; > pr_info("Current voltage =3D %dmV\n", current_voltage * 16 + 700)= ; > current_multiplier =3D (val >> 8) & 0xff; > @@ -194,12 +194,12 @@ static int eps_cpu_init(struct cpufreq_policy *poli= cy) > > switch (c->x86_model) { > case 10: > - rdmsrq(0x1153, val); > + val =3D rdmsrq(0x1153); > brand =3D (((val >> 2) ^ val) >> 18) & 3; > pr_cont("Model A "); > break; > case 13: > - rdmsrq(0x1154, val); > + val =3D rdmsrq(0x1154); > brand =3D (((val >> 4) ^ (val >> 2))) & 0x000000ff; > pr_cont("Model D "); > break; > @@ -223,12 +223,12 @@ static int eps_cpu_init(struct cpufreq_policy *poli= cy) > return -ENODEV; > } > /* Enable Enhanced PowerSaver */ > - rdmsrq(MSR_IA32_MISC_ENABLE, val); > + val =3D rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(val & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { > val |=3D MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP; > wrmsrq(MSR_IA32_MISC_ENABLE, val); > /* Can be locked at 0 */ > - rdmsrq(MSR_IA32_MISC_ENABLE, val); > + val =3D rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(val & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { > pr_info("Can't enable Enhanced PowerSaver\n"); > return -ENODEV; > @@ -236,7 +236,7 @@ static int eps_cpu_init(struct cpufreq_policy *policy= ) > } > > /* Print voltage and multiplier */ > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val =3D rdmsrq(MSR_IA32_PERF_STATUS); > current_voltage =3D val & 0xff; > pr_info("Current voltage =3D %dmV\n", current_voltage * 16 + 700)= ; > current_multiplier =3D (val >> 8) & 0xff; > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstat= e.c > index ceb340f7a110..1a0eb8c359c0 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -560,7 +560,7 @@ static bool turbo_is_disabled(void) > { > u64 misc_en; > > - rdmsrq(MSR_IA32_MISC_ENABLE, misc_en); > + misc_en =3D rdmsrq(MSR_IA32_MISC_ENABLE); > > return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE); > } > @@ -1351,7 +1351,7 @@ static void set_power_ctl_ee_state(bool input) > > guard(mutex)(&intel_pstate_driver_lock); > > - rdmsrq(MSR_IA32_POWER_CTL, power_ctl); > + power_ctl =3D rdmsrq(MSR_IA32_POWER_CTL); > if (input) { > power_ctl &=3D ~BIT(MSR_IA32_POWER_CTL_BIT_EE); > power_ctl_ee_state =3D POWER_CTL_EE_ENABLE; > @@ -1728,7 +1728,7 @@ static ssize_t show_energy_efficiency(struct kobjec= t *kobj, struct kobj_attribut > u64 power_ctl; > int enable; > > - rdmsrq(MSR_IA32_POWER_CTL, power_ctl); > + power_ctl =3D rdmsrq(MSR_IA32_POWER_CTL); > enable =3D !!(power_ctl & BIT(MSR_IA32_POWER_CTL_BIT_EE)); > return sprintf(buf, "%d\n", !enable); > } > @@ -2022,7 +2022,7 @@ static int atom_get_min_pstate(int not_used) > { > u64 value; > > - rdmsrq(MSR_ATOM_CORE_RATIOS, value); > + value =3D rdmsrq(MSR_ATOM_CORE_RATIOS); > return (value >> 8) & 0x7F; > } > > @@ -2030,7 +2030,7 @@ static int atom_get_max_pstate(int not_used) > { > u64 value; > > - rdmsrq(MSR_ATOM_CORE_RATIOS, value); > + value =3D rdmsrq(MSR_ATOM_CORE_RATIOS); > return (value >> 16) & 0x7F; > } > > @@ -2038,7 +2038,7 @@ static int atom_get_turbo_pstate(int not_used) > { > u64 value; > > - rdmsrq(MSR_ATOM_CORE_TURBO_RATIOS, value); > + value =3D rdmsrq(MSR_ATOM_CORE_TURBO_RATIOS); > return value & 0x7F; > } > > @@ -2069,7 +2069,7 @@ static int silvermont_get_scaling(void) > static int silvermont_freq_table[] =3D { > 83300, 100000, 133300, 116700, 80000}; > > - rdmsrq(MSR_FSB_FREQ, value); > + value =3D rdmsrq(MSR_FSB_FREQ); > i =3D value & 0x7; > WARN_ON(i > 4); > > @@ -2085,7 +2085,7 @@ static int airmont_get_scaling(void) > 83300, 100000, 133300, 116700, 80000, > 93300, 90000, 88900, 87500}; > > - rdmsrq(MSR_FSB_FREQ, value); > + value =3D rdmsrq(MSR_FSB_FREQ); > i =3D value & 0xF; > WARN_ON(i > 8); > > @@ -2096,7 +2096,7 @@ static void atom_get_vid(struct cpudata *cpudata) > { > u64 value; > > - rdmsrq(MSR_ATOM_CORE_VIDS, value); > + value =3D rdmsrq(MSR_ATOM_CORE_VIDS); > cpudata->vid.min =3D int_tofp((value >> 8) & 0x7f); > cpudata->vid.max =3D int_tofp((value >> 16) & 0x7f); > cpudata->vid.ratio =3D div_fp( > @@ -2104,7 +2104,7 @@ static void atom_get_vid(struct cpudata *cpudata) > int_tofp(cpudata->pstate.max_pstate - > cpudata->pstate.min_pstate)); > > - rdmsrq(MSR_ATOM_CORE_TURBO_VIDS, value); > + value =3D rdmsrq(MSR_ATOM_CORE_TURBO_VIDS); > cpudata->vid.turbo =3D value & 0x7f; > } > > @@ -2452,8 +2452,8 @@ static inline bool intel_pstate_sample(struct cpuda= ta *cpu, u64 time) > u64 tsc; > > local_irq_save(flags); > - rdmsrq(MSR_IA32_APERF, aperf); > - rdmsrq(MSR_IA32_MPERF, mperf); > + aperf =3D rdmsrq(MSR_IA32_APERF); > + mperf =3D rdmsrq(MSR_IA32_MPERF); > tsc =3D rdtsc(); > if (cpu->prev_mperf =3D=3D mperf || cpu->prev_tsc =3D=3D tsc) { > local_irq_restore(flags); > @@ -3642,7 +3642,7 @@ static bool __init intel_pstate_platform_pwr_mgmt_e= xists(void) > > id =3D x86_match_cpu(intel_pstate_cpu_oob_ids); > if (id) { > - rdmsrq(MSR_MISC_PWR_MGMT, misc_pwr); > + misc_pwr =3D rdmsrq(MSR_MISC_PWR_MGMT); > if (misc_pwr & BITMASK_OOB) { > pr_debug("Bit 8 or 18 in the MISC_PWR_MGMT MSR se= t\n"); > pr_debug("P states are controlled in Out of Band = mode by the firmware/hardware\n"); > @@ -3698,7 +3698,7 @@ static bool intel_pstate_hwp_is_enabled(void) > { > u64 value; > > - rdmsrq(MSR_PM_ENABLE, value); > + value =3D rdmsrq(MSR_PM_ENABLE); > return !!(value & 0x1); > } > > diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c > index 4c2599264333..9bc0acc0ea69 100644 > --- a/drivers/cpufreq/longhaul.c > +++ b/drivers/cpufreq/longhaul.c > @@ -121,7 +121,7 @@ static int longhaul_get_cpu_mult(void) > unsigned long invalue =3D 0; > u64 val; > > - rdmsrq(MSR_IA32_EBL_CR_POWERON, val); > + val =3D rdmsrq(MSR_IA32_EBL_CR_POWERON); > invalue =3D (val & (1<<22|1<<23|1<<24|1<<25))>>22; > if (longhaul_version =3D=3D TYPE_LONGHAUL_V2 || > longhaul_version =3D=3D TYPE_POWERSAVER) { > @@ -137,7 +137,7 @@ static void do_longhaul1(unsigned int mults_index) > { > union msr_bcr2 bcr2; > > - rdmsrq(MSR_VIA_BCR2, bcr2.val); > + bcr2.val =3D rdmsrq(MSR_VIA_BCR2); > /* Enable software clock multiplier */ > bcr2.bits.ESOFTBF =3D 1; > bcr2.bits.CLOCKMUL =3D mults_index & 0xff; > @@ -152,7 +152,7 @@ static void do_longhaul1(unsigned int mults_index) > > /* Disable software clock multiplier */ > local_irq_disable(); > - rdmsrq(MSR_VIA_BCR2, bcr2.val); > + bcr2.val =3D rdmsrq(MSR_VIA_BCR2); > bcr2.bits.ESOFTBF =3D 0; > wrmsrq(MSR_VIA_BCR2, bcr2.val); > } > @@ -165,7 +165,7 @@ static void do_powersaver(int cx_address, unsigned in= t mults_index, > union msr_longhaul longhaul; > u32 t; > > - rdmsrq(MSR_VIA_LONGHAUL, longhaul.val); > + longhaul.val =3D rdmsrq(MSR_VIA_LONGHAUL); > /* Setup new frequency */ > if (!revid_errata) > longhaul.bits.RevisionKey =3D longhaul.bits.RevisionID; > @@ -534,7 +534,7 @@ static void longhaul_setup_voltagescaling(void) > unsigned int j, speed, pos, kHz_step, numvscales; > int min_vid_speed; > > - rdmsrq(MSR_VIA_LONGHAUL, longhaul.val); > + longhaul.val =3D rdmsrq(MSR_VIA_LONGHAUL); > if (!(longhaul.bits.RevisionID & 1)) { > pr_info("Voltage scaling not supported by CPU\n"); > return; > @@ -836,7 +836,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *p= olicy) > } > /* Check Longhaul ver. 2 */ > if (longhaul_version =3D=3D TYPE_LONGHAUL_V2) { > - rdmsrq(MSR_VIA_LONGHAUL, val); > + val =3D rdmsrq(MSR_VIA_LONGHAUL); > if (val =3D=3D 0) > /* Looks like MSR isn't present */ > longhaul_version =3D TYPE_LONGHAUL_V1; > diff --git a/drivers/cpufreq/longrun.c b/drivers/cpufreq/longrun.c > index 82a7bb69c401..4b7e624ae1e5 100644 > --- a/drivers/cpufreq/longrun.c > +++ b/drivers/cpufreq/longrun.c > @@ -37,14 +37,14 @@ static void longrun_get_policy(struct cpufreq_policy = *policy) > { > struct msr msr; > > - rdmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); > + msr.q =3D rdmsrq(MSR_TMTA_LONGRUN_FLAGS); > pr_debug("longrun flags are %x - %x\n", msr.l, msr.h); > if (msr.l & 0x01) > policy->policy =3D CPUFREQ_POLICY_PERFORMANCE; > else > policy->policy =3D CPUFREQ_POLICY_POWERSAVE; > > - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); > + msr.q =3D rdmsrq(MSR_TMTA_LONGRUN_CTRL); > pr_debug("longrun ctrl is %x - %x\n", msr.l, msr.h); > msr.l &=3D 0x0000007F; > msr.h &=3D 0x0000007F; > @@ -93,7 +93,7 @@ static int longrun_set_policy(struct cpufreq_policy *po= licy) > pctg_lo =3D pctg_hi; > > /* performance or economy mode */ > - rdmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); > + msr.q =3D rdmsrq(MSR_TMTA_LONGRUN_FLAGS); > msr.l &=3D 0xFFFFFFFE; > switch (policy->policy) { > case CPUFREQ_POLICY_PERFORMANCE: > @@ -105,7 +105,7 @@ static int longrun_set_policy(struct cpufreq_policy *= policy) > wrmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); > > /* lower and upper boundary */ > - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); > + msr.q =3D rdmsrq(MSR_TMTA_LONGRUN_CTRL); > msr.l &=3D 0xFFFFFF80; > msr.h &=3D 0xFFFFFF80; > msr.l |=3D pctg_lo; > @@ -177,16 +177,16 @@ static int longrun_determine_freqs(unsigned int *lo= w_freq, > * For maximum frequency, read out level zero. > */ > /* minimum */ > - rdmsrq(MSR_TMTA_LRTI_READOUT, msr.q); > + msr.q =3D rdmsrq(MSR_TMTA_LRTI_READOUT); > msr.l =3D msr.h; > wrmsrq(MSR_TMTA_LRTI_READOUT, msr.q); > - rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ, msr.q); > + msr.q =3D rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ); > *low_freq =3D msr.l * 1000; /* to kHz */ > > /* maximum */ > msr.l =3D 0; > wrmsrq(MSR_TMTA_LRTI_READOUT, msr.q); > - rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ, msr.q); > + msr.q =3D rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ); > *high_freq =3D msr.l * 1000; /* to kHz */ > > pr_debug("longrun table interface told %u - %u kHz\n", > @@ -203,7 +203,7 @@ static int longrun_determine_freqs(unsigned int *low_= freq, > pr_debug("high frequency is %u kHz\n", *high_freq); > > /* get current borders */ > - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); > + msr.q =3D rdmsrq(MSR_TMTA_LONGRUN_CTRL); > save.l =3D msr.l & 0x0000007F; > save.h =3D msr.h & 0x0000007F; > > diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.= c > index 6a930d7e6a5c..1df2a8f365a3 100644 > --- a/drivers/cpufreq/powernow-k7.c > +++ b/drivers/cpufreq/powernow-k7.c > @@ -220,7 +220,7 @@ static void change_FID(int fid) > { > union msr_fidvidctl fidvidctl; > > - rdmsrq(MSR_K7_FID_VID_CTL, fidvidctl.val); > + fidvidctl.val =3D rdmsrq(MSR_K7_FID_VID_CTL); > if (fidvidctl.bits.FID !=3D fid) { > fidvidctl.bits.SGTC =3D latency; > fidvidctl.bits.FID =3D fid; > @@ -235,7 +235,7 @@ static void change_VID(int vid) > { > union msr_fidvidctl fidvidctl; > > - rdmsrq(MSR_K7_FID_VID_CTL, fidvidctl.val); > + fidvidctl.val =3D rdmsrq(MSR_K7_FID_VID_CTL); > if (fidvidctl.bits.VID !=3D vid) { > fidvidctl.bits.SGTC =3D latency; > fidvidctl.bits.VID =3D vid; > @@ -261,7 +261,7 @@ static int powernow_target(struct cpufreq_policy *pol= icy, unsigned int index) > fid =3D powernow_table[index].driver_data & 0xFF; > vid =3D (powernow_table[index].driver_data & 0xFF00) >> 8; > > - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); > + fidvidstatus.val =3D rdmsrq(MSR_K7_FID_VID_STATUS); > cfid =3D fidvidstatus.bits.CFID; > freqs.old =3D fsb * fid_codes[cfid] / 10; > > @@ -558,7 +558,7 @@ static unsigned int powernow_get(unsigned int cpu) > > if (cpu) > return 0; > - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); > + fidvidstatus.val =3D rdmsrq(MSR_K7_FID_VID_STATUS); > cfid =3D fidvidstatus.bits.CFID; > > return fsb * fid_codes[cfid] / 10; > @@ -599,7 +599,7 @@ static int powernow_cpu_init(struct cpufreq_policy *p= olicy) > if (policy->cpu !=3D 0) > return -ENODEV; > > - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); > + fidvidstatus.val =3D rdmsrq(MSR_K7_FID_VID_STATUS); > > recalibrate_cpu_khz(); > > diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.= c > index c9bcc6f0ab7b..6097dc3e5a89 100644 > --- a/drivers/cpufreq/powernow-k8.c > +++ b/drivers/cpufreq/powernow-k8.c > @@ -89,7 +89,7 @@ static int pending_bit_stuck(void) > { > u64 msr; > > - rdmsrq(MSR_FIDVID_STATUS, msr); > + msr =3D rdmsrq(MSR_FIDVID_STATUS); > return msr & MSR_S_LO_CHANGE_PENDING ? 1 : 0; > } > > @@ -107,7 +107,7 @@ static int query_current_values_with_pending_wait(str= uct powernow_k8_data *data) > pr_debug("detected change pending stuck\n"); > return 1; > } > - rdmsrq(MSR_FIDVID_STATUS, msr.q); > + msr.q =3D rdmsrq(MSR_FIDVID_STATUS); > } while (msr.l & MSR_S_LO_CHANGE_PENDING); > > data->currvid =3D msr.h & MSR_S_HI_CURRENT_VID; > @@ -134,7 +134,7 @@ static void fidvid_msr_init(void) > struct msr msr; > u8 fid, vid; > > - rdmsrq(MSR_FIDVID_STATUS, msr.q); > + msr.q =3D rdmsrq(MSR_FIDVID_STATUS); > vid =3D msr.h & MSR_S_HI_CURRENT_VID; > fid =3D msr.l & MSR_S_LO_CURRENT_FID; > msr.l =3D fid | (vid << MSR_C_LO_VID_SHIFT); > @@ -293,7 +293,7 @@ static int core_voltage_pre_transition(struct powerno= w_k8_data *data, > if ((savefid < LO_FID_TABLE_TOP) && (reqfid < LO_FID_TABLE_TOP)) > rvomult =3D 2; > rvosteps *=3D rvomult; > - rdmsrq(MSR_FIDVID_STATUS, msr.q); > + msr.q =3D rdmsrq(MSR_FIDVID_STATUS); > maxvid =3D 0x1f & (msr.h >> 16); > pr_debug("ph1 maxvid=3D0x%x\n", maxvid); > if (reqvid < maxvid) /* lower numbers are higher voltages */ > diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speed= step-centrino.c > index de50fb367c6b..2e90b658bfc2 100644 > --- a/drivers/cpufreq/speedstep-centrino.c > +++ b/drivers/cpufreq/speedstep-centrino.c > @@ -378,7 +378,7 @@ static int centrino_cpu_init(struct cpufreq_policy *p= olicy) > > /* Check to see if Enhanced SpeedStep is enabled, and try to > enable it if not. */ > - rdmsrq(MSR_IA32_MISC_ENABLE, q); > + q =3D rdmsrq(MSR_IA32_MISC_ENABLE); > > if (!(q & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { > q |=3D MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP; > @@ -386,7 +386,7 @@ static int centrino_cpu_init(struct cpufreq_policy *p= olicy) > wrmsrq(MSR_IA32_MISC_ENABLE, q); > > /* check to see if it stuck */ > - rdmsrq(MSR_IA32_MISC_ENABLE, q); > + q =3D rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(q & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { > pr_info("couldn't enable Enhanced SpeedStep\n"); > return -ENODEV; > diff --git a/drivers/cpufreq/speedstep-lib.c b/drivers/cpufreq/speedstep-= lib.c > index 2afc3f177a29..188d459c7e2a 100644 > --- a/drivers/cpufreq/speedstep-lib.c > +++ b/drivers/cpufreq/speedstep-lib.c > @@ -74,7 +74,7 @@ static unsigned int pentium3_get_frequency(enum speedst= ep_processor processor) > int i =3D 0, j =3D 0; > > /* read MSR 0x2a - we only need the low 32 bits */ > - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); > + msr.q =3D rdmsrq(MSR_IA32_EBL_CR_POWERON); > pr_debug("P3 - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.= h); > msr_tmp =3D msr_lo =3D msr.l; > > @@ -112,7 +112,7 @@ static unsigned int pentiumM_get_frequency(void) > struct msr msr; > u32 msr_tmp; > > - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); > + msr.q =3D rdmsrq(MSR_IA32_EBL_CR_POWERON); > pr_debug("PM - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.= h); > > /* see table B-2 of 24547212.pdf */ > @@ -136,7 +136,7 @@ static unsigned int pentium_core_get_frequency(void) > u32 msr_tmp; > int ret; > > - rdmsrq(MSR_FSB_FREQ, msr.q); > + msr.q =3D rdmsrq(MSR_FSB_FREQ); > /* see table B-2 of 25366920.pdf */ > switch (msr.l & 0x07) { > case 5: > @@ -161,7 +161,7 @@ static unsigned int pentium_core_get_frequency(void) > pr_err("PCORE - MSR_FSB_FREQ undefined value\n"); > } > > - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); > + msr.q =3D rdmsrq(MSR_IA32_EBL_CR_POWERON); > pr_debug("PCORE - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", > msr.l, msr.h); > > @@ -191,7 +191,7 @@ static unsigned int pentium4_get_frequency(void) > if (c->x86_model < 2) > return cpu_khz; > > - rdmsrq(0x2c, msr.q); > + msr.q =3D rdmsrq(0x2c); > > pr_debug("P4 - MSR_EBC_FREQUENCY_ID: 0x%x 0x%x\n", msr.l, msr.h); > > @@ -348,7 +348,7 @@ enum speedstep_processor speedstep_detect_processor(v= oid) > > /* all mobile PIII Coppermines have FSB 100 MHz > * =3D=3D> sort out a few desktop PIIIs. */ > - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); > + msr.q =3D rdmsrq(MSR_IA32_EBL_CR_POWERON); > pr_debug("Coppermine: MSR_IA32_EBL_CR_POWERON is 0x%x, 0x= %x\n", > msr.l, msr.h); > msr.l &=3D 0x00c0000; > @@ -361,7 +361,7 @@ enum speedstep_processor speedstep_detect_processor(v= oid) > * it has SpeedStep technology if either > * bit 56 or 57 is set > */ > - rdmsrq(MSR_IA32_PLATFORM_ID, msr.q); > + msr.q =3D rdmsrq(MSR_IA32_PLATFORM_ID); > pr_debug("Coppermine: MSR_IA32_PLATFORM ID is 0x%x, 0x%x\= n", > msr.l, msr.h); > if ((msr.h & (1<<18)) && > diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c > index 475235c402e8..40317ab69461 100644 > --- a/drivers/edac/amd64_edac.c > +++ b/drivers/edac/amd64_edac.c > @@ -2956,13 +2956,13 @@ static void dct_read_mc_regs(struct amd64_pvt *pv= t) > * Retrieve TOP_MEM and TOP_MEM2; no masking off of reserved bits= since > * those are Read-As-Zero. > */ > - rdmsrq(MSR_K8_TOP_MEM1, pvt->top_mem); > + pvt->top_mem =3D rdmsrq(MSR_K8_TOP_MEM1); > edac_dbg(0, " TOP_MEM: 0x%016llx\n", pvt->top_mem); > > /* Check first whether TOP_MEM2 is enabled: */ > - rdmsrq(MSR_AMD64_SYSCFG, msr_val); > + msr_val =3D rdmsrq(MSR_AMD64_SYSCFG); > if (msr_val & BIT(21)) { > - rdmsrq(MSR_K8_TOP_MEM2, pvt->top_mem2); > + pvt->top_mem2 =3D rdmsrq(MSR_K8_TOP_MEM2); > edac_dbg(0, " TOP_MEM2: 0x%016llx\n", pvt->top_mem2); > } else { > edac_dbg(0, " TOP_MEM2 disabled\n"); > diff --git a/drivers/gpio/gpio-cs5535.c b/drivers/gpio/gpio-cs5535.c > index a97ec7561889..e9cc577e94b7 100644 > --- a/drivers/gpio/gpio-cs5535.c > +++ b/drivers/gpio/gpio-cs5535.c > @@ -148,7 +148,7 @@ int cs5535_gpio_set_irq(unsigned group, unsigned irq) > if (group > 7 || irq > 15) > return -EINVAL; > > - rdmsrq(MSR_PIC_ZSEL_HIGH, val.q); > + val.q =3D rdmsrq(MSR_PIC_ZSEL_HIGH); > > val.l &=3D ~(0xF << (group * 4)); > val.l |=3D (irq & 0xF) << (group * 4); > diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c > index 6e3c11c68171..f678eda1641c 100644 > --- a/drivers/hv/mshv_vtl_main.c > +++ b/drivers/hv/mshv_vtl_main.c > @@ -599,7 +599,7 @@ static int mshv_vtl_get_set_reg(struct hv_register_as= soc *regs, bool set) > if (set) > wrmsrq(reg_table[i].msr_addr, *reg64); > else > - rdmsrq(reg_table[i].msr_addr, *reg64); > + *reg64 =3D rdmsrq(reg_table[i].msr_addr); > } > return 0; > } > diff --git a/drivers/hwmon/hwmon-vid.c b/drivers/hwmon/hwmon-vid.c > index dee42c163d92..cfb3a2975de4 100644 > --- a/drivers/hwmon/hwmon-vid.c > +++ b/drivers/hwmon/hwmon-vid.c > @@ -243,10 +243,10 @@ static u8 get_via_model_d_vrm(void) > "C7-M", "C7", "Eden", "C7-D" > }; > > - rdmsrq(0x198, msr); > + msr =3D rdmsrq(0x198); > vid =3D (msr >> 32) & 0xff; > > - rdmsrq(0x1154, msr); > + msr =3D rdmsrq(0x1154); > brand =3D ((msr >> 4) ^ (msr >> 2)) & 0x03; > > if (vid > 0x3f) { > diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c > index 651408df9c24..82faaf771b2d 100644 > --- a/drivers/idle/intel_idle.c > +++ b/drivers/idle/intel_idle.c > @@ -2125,35 +2125,35 @@ static void __init bxt_idle_state_table_update(vo= id) > unsigned long long msr; > unsigned int usec; > > - rdmsrq(MSR_PKGC6_IRTL, msr); > + msr =3D rdmsrq(MSR_PKGC6_IRTL); > usec =3D irtl_2_usec(msr); > if (usec) { > bxt_cstates[2].exit_latency =3D usec; > bxt_cstates[2].target_residency =3D usec; > } > > - rdmsrq(MSR_PKGC7_IRTL, msr); > + msr =3D rdmsrq(MSR_PKGC7_IRTL); > usec =3D irtl_2_usec(msr); > if (usec) { > bxt_cstates[3].exit_latency =3D usec; > bxt_cstates[3].target_residency =3D usec; > } > > - rdmsrq(MSR_PKGC8_IRTL, msr); > + msr =3D rdmsrq(MSR_PKGC8_IRTL); > usec =3D irtl_2_usec(msr); > if (usec) { > bxt_cstates[4].exit_latency =3D usec; > bxt_cstates[4].target_residency =3D usec; > } > > - rdmsrq(MSR_PKGC9_IRTL, msr); > + msr =3D rdmsrq(MSR_PKGC9_IRTL); > usec =3D irtl_2_usec(msr); > if (usec) { > bxt_cstates[5].exit_latency =3D usec; > bxt_cstates[5].target_residency =3D usec; > } > > - rdmsrq(MSR_PKGC10_IRTL, msr); > + msr =3D rdmsrq(MSR_PKGC10_IRTL); > usec =3D irtl_2_usec(msr); > if (usec) { > bxt_cstates[6].exit_latency =3D usec; > @@ -2181,7 +2181,7 @@ static void __init sklh_idle_state_table_update(voi= d) > if ((mwait_substates & (0xF << 28)) =3D=3D 0) > return; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr); > + msr =3D rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > > /* PC10 is not enabled in PKG C-state limit */ > if ((msr & 0xF) !=3D 8) > @@ -2193,7 +2193,7 @@ static void __init sklh_idle_state_table_update(voi= d) > /* if SGX is present */ > if (ebx & (1 << 2)) { > > - rdmsrq(MSR_IA32_FEAT_CTL, msr); > + msr =3D rdmsrq(MSR_IA32_FEAT_CTL); > > /* if SGX is enabled */ > if (msr & (1 << 18)) > @@ -2213,7 +2213,7 @@ static bool __init skx_is_pc6_disabled(void) > { > u64 msr; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr); > + msr =3D rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > > /* > * 000b: C0/C1 (no package C-state support) > @@ -2467,7 +2467,7 @@ static void auto_demotion_disable(void) > { > unsigned long long msr_bits; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_bits); > + msr_bits =3D rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > msr_bits &=3D ~auto_demotion_disable_flags; > wrmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_bits); > } > @@ -2476,7 +2476,7 @@ static void c1e_promotion_enable(void) > { > unsigned long long msr_bits; > > - rdmsrq(MSR_IA32_POWER_CTL, msr_bits); > + msr_bits =3D rdmsrq(MSR_IA32_POWER_CTL); > msr_bits |=3D 0x2; > wrmsrq(MSR_IA32_POWER_CTL, msr_bits); > } > @@ -2485,7 +2485,7 @@ static void c1e_promotion_disable(void) > { > unsigned long long msr_bits; > > - rdmsrq(MSR_IA32_POWER_CTL, msr_bits); > + msr_bits =3D rdmsrq(MSR_IA32_POWER_CTL); > msr_bits &=3D ~0x2; > wrmsrq(MSR_IA32_POWER_CTL, msr_bits); > } > @@ -2554,7 +2554,7 @@ static void intel_c1_demotion_toggle(void *enable) > { > unsigned long long msr_val; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_val); > + msr_val =3D rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > /* > * Enable/disable C1 undemotion along with C1 demotion, as this i= s the > * most sensible configuration in general. > @@ -2594,7 +2594,7 @@ static ssize_t intel_c1_demotion_show(struct device= *dev, > * Read the MSR value for a CPU and assume it is the same for all= CPUs. Any other > * configuration would be a BIOS bug. > */ > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_val); > + msr_val =3D rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > return sysfs_emit(buf, "%d\n", !!(msr_val & NHM_C1_AUTO_DEMOTE)); > } > static DEVICE_ATTR_RW(intel_c1_demotion); > diff --git a/drivers/misc/cs5535-mfgpt.c b/drivers/misc/cs5535-mfgpt.c > index 9abfc44f70f4..9006b59858ff 100644 > --- a/drivers/misc/cs5535-mfgpt.c > +++ b/drivers/misc/cs5535-mfgpt.c > @@ -83,7 +83,7 @@ int cs5535_mfgpt_toggle_event(struct cs5535_mfgpt_timer= *timer, int cmp, > return -EIO; > } > > - rdmsrq(msr, val.q); > + val.q =3D rdmsrq(msr); > > if (enable) > val.l |=3D mask; > @@ -114,7 +114,7 @@ int cs5535_mfgpt_set_irq(struct cs5535_mfgpt_timer *t= imer, int cmp, int *irq, > * IRQ of the 1st. This can only happen if forcing an IRQ, callin= g this > * with *irq=3D=3D0 is safe. Currently there _are_ no 2 drivers. > */ > - rdmsrq(MSR_PIC_ZSEL_LOW, zsel.q); > + zsel.q =3D rdmsrq(MSR_PIC_ZSEL_LOW); > shift =3D ((cmp =3D=3D MFGPT_CMP1 ? 0 : 4) + timer->nr % 4) * 4; > if (((zsel.l >> shift) & 0xF) =3D=3D 2) > return -EIO; > @@ -128,7 +128,7 @@ int cs5535_mfgpt_set_irq(struct cs5535_mfgpt_timer *t= imer, int cmp, int *irq, > /* Can't use IRQ if it's 0 (=3Ddisabled), 2, or routed to LPC */ > if (*irq < 1 || *irq =3D=3D 2 || *irq > 15) > return -EIO; > - rdmsrq(MSR_PIC_IRQM_LPC, lpc.q); > + lpc.q =3D rdmsrq(MSR_PIC_IRQM_LPC); > if (lpc.l & (1 << *irq)) > return -EIO; > > diff --git a/drivers/mtd/nand/raw/cs553x_nand.c b/drivers/mtd/nand/raw/cs= 553x_nand.c > index 0b872b1e3b04..2ed13666b48f 100644 > --- a/drivers/mtd/nand/raw/cs553x_nand.c > +++ b/drivers/mtd/nand/raw/cs553x_nand.c > @@ -351,20 +351,20 @@ static int __init cs553x_init(void) > return -ENXIO; > > /* If it doesn't have the CS553[56], abort */ > - rdmsrq(MSR_DIVIL_GLD_CAP, val); > + val =3D rdmsrq(MSR_DIVIL_GLD_CAP); > val &=3D ~0xFFULL; > if (val !=3D CAP_CS5535 && val !=3D CAP_CS5536) > return -ENXIO; > > /* If it doesn't have the NAND controller enabled, abort */ > - rdmsrq(MSR_DIVIL_BALL_OPTS, val); > + val =3D rdmsrq(MSR_DIVIL_BALL_OPTS); > if (val & PIN_OPT_IDE) { > pr_info("CS553x NAND controller: Flash I/O not enabled in= MSR_DIVIL_BALL_OPTS.\n"); > return -ENXIO; > } > > for (i =3D 0; i < NR_CS553X_CONTROLLERS; i++) { > - rdmsrq(MSR_DIVIL_LBAR_FLSH0 + i, val); > + val =3D rdmsrq(MSR_DIVIL_LBAR_FLSH0 + i); > > if ((val & (FLSH_LBAR_EN|FLSH_NOR_NAND)) =3D=3D (FLSH_LBA= R_EN|FLSH_NOR_NAND)) > err =3D cs553x_init_one(i, !!(val & FLSH_MEM_IO),= val & 0xFFFFFFFF); > diff --git a/drivers/platform/x86/intel/ifs/load.c b/drivers/platform/x86= /intel/ifs/load.c > index 50f1fdf7dfed..6320a0e45d38 100644 > --- a/drivers/platform/x86/intel/ifs/load.c > +++ b/drivers/platform/x86/intel/ifs/load.c > @@ -129,7 +129,7 @@ static void copy_hashes_authenticate_chunks(struct wo= rk_struct *work) > msrs =3D ifs_get_test_msrs(dev); > /* run scan hash copy */ > wrmsrq(msrs->copy_hashes, ifs_hash_ptr); > - rdmsrq(msrs->copy_hashes_status, hashes_status.data); > + hashes_status.data =3D rdmsrq(msrs->copy_hashes_status); > > /* enumerate the scan image information */ > num_chunks =3D hashes_status.num_chunks; > @@ -151,7 +151,7 @@ static void copy_hashes_authenticate_chunks(struct wo= rk_struct *work) > linear_addr |=3D i; > > wrmsrq(msrs->copy_chunks, linear_addr); > - rdmsrq(msrs->copy_chunks_status, chunk_status.data); > + chunk_status.data =3D rdmsrq(msrs->copy_chunks_status); > > ifsd->valid_chunks =3D chunk_status.valid_chunks; > err_code =3D chunk_status.error_code; > @@ -197,7 +197,7 @@ static int copy_hashes_authenticate_chunks_gen2(struc= t device *dev) > > if (need_copy_scan_hashes(ifsd)) { > wrmsrq(msrs->copy_hashes, ifs_hash_ptr); > - rdmsrq(msrs->copy_hashes_status, hashes_status.data); > + hashes_status.data =3D rdmsrq(msrs->copy_hashes_status); > > /* enumerate the scan image information */ > chunk_size =3D hashes_status.chunk_size * SZ_1K; > @@ -218,7 +218,7 @@ static int copy_hashes_authenticate_chunks_gen2(struc= t device *dev) > > if (ifsd->generation >=3D IFS_GEN_STRIDE_AWARE) { > wrmsrq(msrs->test_ctrl, INVALIDATE_STRIDE); > - rdmsrq(msrs->copy_chunks_status, chunk_status.data); > + chunk_status.data =3D rdmsrq(msrs->copy_chunks_status); > if (chunk_status.valid_chunks !=3D 0) { > dev_err(dev, "Couldn't invalidate installed strid= e - %d\n", > chunk_status.valid_chunks); > @@ -241,7 +241,7 @@ static int copy_hashes_authenticate_chunks_gen2(struc= t device *dev) > local_irq_disable(); > wrmsrq(msrs->copy_chunks, (u64)chunk_table); > local_irq_enable(); > - rdmsrq(msrs->copy_chunks_status, chunk_status.dat= a); > + chunk_status.data =3D rdmsrq(msrs->copy_chunks_st= atus); > err_code =3D chunk_status.error_code; > } while (err_code =3D=3D AUTH_INTERRUPTED_ERROR && --retr= y_count); > > diff --git a/drivers/platform/x86/intel/ifs/runtest.c b/drivers/platform/= x86/intel/ifs/runtest.c > index dfc119d7354d..46e1ea944ce7 100644 > --- a/drivers/platform/x86/intel/ifs/runtest.c > +++ b/drivers/platform/x86/intel/ifs/runtest.c > @@ -211,7 +211,7 @@ static int doscan(void *data) > * are processed in a single pass) before it retires. > */ > wrmsrq(MSR_ACTIVATE_SCAN, params->activate->data); > - rdmsrq(MSR_SCAN_STATUS, status.data); > + status.data =3D rdmsrq(MSR_SCAN_STATUS); > > trace_ifs_status(ifsd->cur_batch, start, stop, status.data); > > @@ -324,7 +324,7 @@ static int do_array_test(void *data) > if (cpu =3D=3D first) { > wrmsrq(MSR_ARRAY_BIST, command->data); > /* Pass back the result of the test */ > - rdmsrq(MSR_ARRAY_BIST, command->data); > + command->data =3D rdmsrq(MSR_ARRAY_BIST); > } > > return 0; > @@ -376,7 +376,7 @@ static int do_array_test_gen1(void *status) > > if (cpu =3D=3D first) { > wrmsrq(MSR_ARRAY_TRIGGER, ARRAY_GEN1_TEST_ALL_ARRAYS); > - rdmsrq(MSR_ARRAY_STATUS, *((u64 *)status)); > + *((u64 *)status) =3D rdmsrq(MSR_ARRAY_STATUS); > } > > return 0; > @@ -528,7 +528,7 @@ static int dosbaf(void *data) > * during the "execution" of the WRMSR. > */ > wrmsrq(MSR_ACTIVATE_SBAF, run_params->activate->data); > - rdmsrq(MSR_SBAF_STATUS, status.data); > + status.data =3D rdmsrq(MSR_SBAF_STATUS); > trace_ifs_sbaf(ifsd->cur_batch, *run_params->activate, status); > > /* Pass back the result of the test */ > diff --git a/drivers/platform/x86/intel/pmc/cnp.c b/drivers/platform/x86/= intel/pmc/cnp.c > index efea4e1ba52b..44979e680361 100644 > --- a/drivers/platform/x86/intel/pmc/cnp.c > +++ b/drivers/platform/x86/intel/pmc/cnp.c > @@ -228,7 +228,7 @@ static void disable_c1_auto_demote(void *unused) > int cpunum =3D smp_processor_id(); > u64 val; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, val); > + val =3D rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > per_cpu(pkg_cst_config, cpunum) =3D val; > val &=3D ~NHM_C1_AUTO_DEMOTE; > wrmsrq(MSR_PKG_CST_CONFIG_CONTROL, val); > diff --git a/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.= c b/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c > index 22745b217c6f..909c9e25112d 100644 > --- a/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c > +++ b/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c > @@ -40,7 +40,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_com= mand, u32 parameter, > /* Poll for rb bit =3D=3D 0 */ > retries =3D OS_MAILBOX_RETRY_COUNT; > do { > - rdmsrq(MSR_OS_MAILBOX_INTERFACE, data); > + data =3D rdmsrq(MSR_OS_MAILBOX_INTERFACE); > if (data & BIT_ULL(MSR_OS_MAILBOX_BUSY_BIT)) { > ret =3D -EBUSY; > continue; > @@ -65,7 +65,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_com= mand, u32 parameter, > /* Poll for rb bit =3D=3D 0 */ > retries =3D OS_MAILBOX_RETRY_COUNT; > do { > - rdmsrq(MSR_OS_MAILBOX_INTERFACE, data); > + data =3D rdmsrq(MSR_OS_MAILBOX_INTERFACE); > if (data & BIT_ULL(MSR_OS_MAILBOX_BUSY_BIT)) { > ret =3D -EBUSY; > continue; > @@ -75,7 +75,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_com= mand, u32 parameter, > return -ENXIO; > > if (response_data) { > - rdmsrq(MSR_OS_MAILBOX_DATA, data); > + data =3D rdmsrq(MSR_OS_MAILBOX_DATA); > *response_data =3D data; > } > ret =3D 0; > diff --git a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c = b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c > index bb0d0b8fc54a..57262a6afe8c 100644 > --- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c > +++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c > @@ -568,7 +568,7 @@ static bool disable_dynamic_sst_features(void) > if (!cpu_feature_enabled(X86_FEATURE_HWP)) > return true; > > - rdmsrq(MSR_PM_ENABLE, value); > + value =3D rdmsrq(MSR_PM_ENABLE); > return !(value & 0x1); > } > > diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/inte= l_ips.c > index b1b2d9caba7b..79c07f23ba0b 100644 > --- a/drivers/platform/x86/intel_ips.c > +++ b/drivers/platform/x86/intel_ips.c > @@ -370,7 +370,7 @@ static void ips_cpu_raise(struct ips_driver *ips) > if (!ips->cpu_turbo_enabled) > return; > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > + turbo_override =3D rdmsrq(TURBO_POWER_CURRENT_LIMIT); > > cur_tdp_limit =3D turbo_override & TURBO_TDP_MASK; > new_tdp_limit =3D cur_tdp_limit + 8; /* 1W increase */ > @@ -405,7 +405,7 @@ static void ips_cpu_lower(struct ips_driver *ips) > u64 turbo_override; > u16 cur_limit, new_limit; > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > + turbo_override =3D rdmsrq(TURBO_POWER_CURRENT_LIMIT); > > cur_limit =3D turbo_override & TURBO_TDP_MASK; > new_limit =3D cur_limit - 8; /* 1W decrease */ > @@ -437,7 +437,7 @@ static void do_enable_cpu_turbo(void *data) > { > u64 perf_ctl; > > - rdmsrq(IA32_PERF_CTL, perf_ctl); > + perf_ctl =3D rdmsrq(IA32_PERF_CTL); > if (perf_ctl & IA32_PERF_TURBO_DIS) { > perf_ctl &=3D ~IA32_PERF_TURBO_DIS; > wrmsrq(IA32_PERF_CTL, perf_ctl); > @@ -475,7 +475,7 @@ static void do_disable_cpu_turbo(void *data) > { > u64 perf_ctl; > > - rdmsrq(IA32_PERF_CTL, perf_ctl); > + perf_ctl =3D rdmsrq(IA32_PERF_CTL); > if (!(perf_ctl & IA32_PERF_TURBO_DIS)) { > perf_ctl |=3D IA32_PERF_TURBO_DIS; > wrmsrq(IA32_PERF_CTL, perf_ctl); > @@ -1215,7 +1215,7 @@ static int cpu_clamp_show(struct seq_file *m, void = *data) > u64 turbo_override; > int tdp, tdc; > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > + turbo_override =3D rdmsrq(TURBO_POWER_CURRENT_LIMIT); > > tdp =3D (int)(turbo_override & TURBO_TDP_MASK); > tdc =3D (int)((turbo_override & TURBO_TDC_MASK) >> TURBO_TDC_SHIF= T); > @@ -1290,7 +1290,7 @@ static struct ips_mcp_limits *ips_detect_cpu(struct= ips_driver *ips) > return NULL; > } > > - rdmsrq(IA32_MISC_ENABLE, misc_en); > + misc_en =3D rdmsrq(IA32_MISC_ENABLE); > /* > * If the turbo enable bit isn't set, we shouldn't try to enable/= disable > * turbo manually or we'll get an illegal MSR access, even though > @@ -1312,7 +1312,7 @@ static struct ips_mcp_limits *ips_detect_cpu(struct= ips_driver *ips) > return NULL; > } > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_power); > + turbo_power =3D rdmsrq(TURBO_POWER_CURRENT_LIMIT); > tdp =3D turbo_power & TURBO_TDP_MASK; > > /* Sanity check TDP against CPU */ > @@ -1496,7 +1496,7 @@ static int ips_probe(struct pci_dev *dev, const str= uct pci_device_id *id) > * Check PLATFORM_INFO MSR to make sure this chip is > * turbo capable. > */ > - rdmsrq(PLATFORM_INFO, platform_info); > + platform_info =3D rdmsrq(PLATFORM_INFO); > if (!(platform_info & PLATFORM_TDP)) { > dev_err(&dev->dev, "platform indicates TDP override unava= ilable, aborting\n"); > return -ENODEV; > @@ -1529,7 +1529,7 @@ static int ips_probe(struct pci_dev *dev, const str= uct pci_device_id *id) > ips->mgta_val =3D thm_readw(THM_MGTA); > > /* Save turbo limits & ratios */ > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, ips->orig_turbo_limit); > + ips->orig_turbo_limit =3D rdmsrq(TURBO_POWER_CURRENT_LIMIT); > > ips_disable_cpu_turbo(ips); > ips->cpu_turbo_enabled =3D false; > @@ -1596,7 +1596,7 @@ static void ips_remove(struct pci_dev *dev) > if (ips->gpu_turbo_disable) > symbol_put(i915_gpu_turbo_disable); > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > + turbo_override =3D rdmsrq(TURBO_POWER_CURRENT_LIMIT); > turbo_override &=3D ~(TURBO_TDC_OVR_EN | TURBO_TDP_OVR_EN); > wrmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > wrmsrq(TURBO_POWER_CURRENT_LIMIT, ips->orig_turbo_limit); > diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_r= apl_msr.c > index a34543e66446..5d840de67c2b 100644 > --- a/drivers/powercap/intel_rapl_msr.c > +++ b/drivers/powercap/intel_rapl_msr.c > @@ -176,7 +176,7 @@ static int rapl_msr_read_raw(int cpu, struct reg_acti= on *ra, bool pmu_ctx) > * from any CPU in the package. > */ > if (pmu_ctx) { > - rdmsrq(ra->reg.msr, ra->value); > + ra->value =3D rdmsrq(ra->reg.msr); > goto out; > } > > diff --git a/drivers/thermal/intel/intel_hfi.c b/drivers/thermal/intel/in= tel_hfi.c > index 3273b8fe3d4d..6b2801aaa745 100644 > --- a/drivers/thermal/intel/intel_hfi.c > +++ b/drivers/thermal/intel/intel_hfi.c > @@ -285,7 +285,7 @@ void intel_hfi_process_event(__u64 pkg_therm_status_m= sr_val) > if (!raw_spin_trylock(&hfi_instance->event_lock)) > return; > > - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr); > + msr =3D rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); > hfi =3D msr & PACKAGE_THERM_STATUS_HFI_UPDATED; > if (!hfi) { > raw_spin_unlock(&hfi_instance->event_lock); > @@ -357,7 +357,7 @@ static void hfi_enable(void) > { > u64 msr_val; > > - rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); > + msr_val =3D rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG); > msr_val |=3D HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT; > wrmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); > } > @@ -378,7 +378,7 @@ static void hfi_disable(void) > u64 msr_val; > int i; > > - rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); > + msr_val =3D rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG); > msr_val &=3D ~HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT; > wrmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); > > @@ -389,7 +389,7 @@ static void hfi_disable(void) > * memory. > */ > for (i =3D 0; i < 2000; i++) { > - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); > + msr_val =3D rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); > if (msr_val & PACKAGE_THERM_STATUS_HFI_UPDATED) > break; > > diff --git a/drivers/thermal/intel/therm_throt.c b/drivers/thermal/intel/= therm_throt.c > index 4d4e81601d17..3ead57f45510 100644 > --- a/drivers/thermal/intel/therm_throt.c > +++ b/drivers/thermal/intel/therm_throt.c > @@ -297,7 +297,7 @@ static void get_therm_status(int level, bool *proc_ho= t, u8 *temp) > else > msr =3D MSR_IA32_PACKAGE_THERM_STATUS; > > - rdmsrq(msr, msr_val); > + msr_val =3D rdmsrq(msr); > if (msr_val & THERM_STATUS_PROCHOT_LOG) > *proc_hot =3D true; > else > @@ -543,7 +543,7 @@ static int check_directed_thermal_pkg_intr_ack(void) > * Wait 15ms to be safe. > */ > do { > - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); > + msr_val =3D rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); > udelay(1); > } while (!(msr_val & PACKAGE_THERM_STATUS_DPTI_ACK) && --count); > > @@ -561,7 +561,7 @@ static void config_directed_thermal_pkg_intr(void *in= fo) > bool enable =3D *((bool *)info); > u64 msr_val; > > - rdmsrq(MSR_IA32_THERM_INTERRUPT, msr_val); > + msr_val =3D rdmsrq(MSR_IA32_THERM_INTERRUPT); > > if (enable) > msr_val |=3D THERM_INT_DPTI_ENABLE; > @@ -931,7 +931,7 @@ void intel_thermal_interrupt(void) > if (cpu_feature_enabled(X86_FEATURE_HWP)) > notify_hwp_interrupt(); > > - rdmsrq(MSR_IA32_THERM_STATUS, msr_val); > + msr_val =3D rdmsrq(MSR_IA32_THERM_STATUS); > > /* Check for violation of core thermal thresholds*/ > notify_thresholds(msr_val); > @@ -946,7 +946,7 @@ void intel_thermal_interrupt(void) > CORE_LEVEL); > > if (this_cpu_has(X86_FEATURE_PTS)) { > - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); > + msr_val =3D rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); > /* check violations of package thermal thresholds */ > notify_package_thresholds(msr_val); > therm_throt_process(msr_val & PACKAGE_THERM_STATUS_PROCHO= T, > @@ -1004,7 +1004,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > * be some SMM goo which handles it, so we can't even put a handl= er > * since it might be delivered via SMI already: > */ > - rdmsrq(MSR_IA32_MISC_ENABLE, val.q); > + val.q =3D rdmsrq(MSR_IA32_MISC_ENABLE); > > val.h =3D lvtthmr_init; > /* > @@ -1030,7 +1030,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > /* early Pentium M models use different method for enabling TM2 *= / > if (cpu_has(c, X86_FEATURE_TM2)) { > if (c->x86 =3D=3D 6 && (c->x86_model =3D=3D 9 || c->x86_m= odel =3D=3D 13)) { > - rdmsrq(MSR_THERM2_CTL, val.q); > + val.q =3D rdmsrq(MSR_THERM2_CTL); > if (val.l & MSR_THERM2_CTL_TM_SELECT) > tm2 =3D 1; > } else if (val.l & MSR_IA32_MISC_ENABLE_TM2) > @@ -1044,7 +1044,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > thermal_intr_init_core_clear_mask(); > thermal_intr_init_pkg_clear_mask(); > > - rdmsrq(MSR_IA32_THERM_INTERRUPT, val.q); > + val.q =3D rdmsrq(MSR_IA32_THERM_INTERRUPT); > if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable) { > val.l |=3D THERM_INT_LOW_ENABLE | THERM_INT_HIGH_ENABLE; > val.l &=3D ~THERM_INT_PLN_ENABLE; > @@ -1056,7 +1056,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > wrmsrq(MSR_IA32_THERM_INTERRUPT, val.q); > > if (cpu_has(c, X86_FEATURE_PTS)) { > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > + val.q =3D rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); > if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable) { > val.l |=3D PACKAGE_THERM_INT_LOW_ENABLE | > PACKAGE_THERM_INT_HIGH_ENABLE; > @@ -1071,13 +1071,13 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > > if (cpu_has(c, X86_FEATURE_HFI)) { > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > + val.q =3D rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT= ); > wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, > val.q | PACKAGE_THERM_INT_HFI_ENABLE); > } > } > > - rdmsrq(MSR_IA32_MISC_ENABLE, val.q); > + val.q =3D rdmsrq(MSR_IA32_MISC_ENABLE); > wrmsrq(MSR_IA32_MISC_ENABLE, val.q | MSR_IA32_MISC_ENABLE_TM1); > > pr_info_once("CPU0: Thermal monitoring enabled (%s)\n", > diff --git a/drivers/thermal/intel/x86_pkg_temp_thermal.c b/drivers/therm= al/intel/x86_pkg_temp_thermal.c > index 43fd5bdf1d8d..11ca647802dc 100644 > --- a/drivers/thermal/intel/x86_pkg_temp_thermal.c > +++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c > @@ -187,7 +187,7 @@ static inline void enable_pkg_thres_interrupt(void) > u8 thres_0, thres_1; > struct msr val; > > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > + val.q =3D rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); > /* only enable/disable if it had valid threshold value */ > thres_0 =3D (val.l & THERM_MASK_THRESHOLD0) >> THERM_SHIFT_THRESH= OLD0; > thres_1 =3D (val.l & THERM_MASK_THRESHOLD1) >> THERM_SHIFT_THRESH= OLD1; > @@ -203,7 +203,7 @@ static inline void disable_pkg_thres_interrupt(void) > { > struct msr val; > > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > + val.q =3D rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); > > val.l &=3D ~(THERM_INT_THRESHOLD0_ENABLE | THERM_INT_THRESHOLD1_E= NABLE); > wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > @@ -356,7 +356,7 @@ static int pkg_temp_thermal_device_add(unsigned int c= pu) > goto out_unregister_tz; > > /* Store MSR value for package thermal interrupt, to restore at e= xit */ > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, zonedev->msr_pkg_therm); > + zonedev->msr_pkg_therm =3D rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUP= T); > > cpumask_set_cpu(cpu, &zonedev->cpumask); > raw_spin_lock_irq(&pkg_temp_lock); > diff --git a/drivers/video/fbdev/geode/display_gx.c b/drivers/video/fbdev= /geode/display_gx.c > index b93aa21a1d2b..511cb7bf98e9 100644 > --- a/drivers/video/fbdev/geode/display_gx.c > +++ b/drivers/video/fbdev/geode/display_gx.c > @@ -26,7 +26,7 @@ unsigned int gx_frame_buffer_size(void) > struct msr msr; > > /* The number of pages is (PMAX - PMIN)+1 */ > - rdmsrq(MSR_GLIU_P2D_RO0, msr.q); > + msr.q =3D rdmsrq(MSR_GLIU_P2D_RO0); > > /* PMAX */ > val =3D ((msr.h & 0xff) << 12) | ((msr.l & 0xfff00000) >>= 20); > diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/= geode/gxfb_core.c > index 8d69be7c9d31..e0a3447f2b1b 100644 > --- a/drivers/video/fbdev/geode/gxfb_core.c > +++ b/drivers/video/fbdev/geode/gxfb_core.c > @@ -378,7 +378,7 @@ static int gxfb_probe(struct pci_dev *pdev, const str= uct pci_device_id *id) > > /* Figure out if this is a TFT or CRT part */ > > - rdmsrq(MSR_GX_GLD_MSR_CONFIG, val); > + val =3D rdmsrq(MSR_GX_GLD_MSR_CONFIG); > > if ((val & MSR_GX_GLD_MSR_CONFIG_FP) =3D=3D MSR_GX_GLD_MSR_CONFIG= _FP) > par->enable_crt =3D 0; > diff --git a/drivers/video/fbdev/geode/lxfb_ops.c b/drivers/video/fbdev/g= eode/lxfb_ops.c > index f5f1134cae9a..980a782214a2 100644 > --- a/drivers/video/fbdev/geode/lxfb_ops.c > +++ b/drivers/video/fbdev/geode/lxfb_ops.c > @@ -127,7 +127,7 @@ static void lx_set_dotpll(u32 pllval) > struct msr dotpll; > int i; > > - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); > + dotpll.q =3D rdmsrq(MSR_GLCP_DOTPLL); > > if ((dotpll.l & MSR_GLCP_DOTPLL_LOCK) && (dotpll.h =3D=3D pllval)= ) > return; > @@ -145,7 +145,7 @@ static void lx_set_dotpll(u32 pllval) > /* Now, loop for the lock bit */ > > for (i =3D 0; i < 1000; i++) { > - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); > + dotpll.q =3D rdmsrq(MSR_GLCP_DOTPLL); > if (dotpll.l & MSR_GLCP_DOTPLL_LOCK) > break; > } > @@ -316,7 +316,7 @@ unsigned int lx_framebuffer_size(void) > struct msr msr; > > /* The number of pages is (PMAX - PMIN)+1 */ > - rdmsrq(MSR_GLIU_P2D_RO0, msr.q); > + msr.q =3D rdmsrq(MSR_GLIU_P2D_RO0); > > /* PMAX */ > val =3D ((msr.h & 0xff) << 12) | ((msr.l & 0xfff00000) >>= 20); > @@ -359,7 +359,7 @@ void lx_set_mode(struct fb_info *info) > > /* Set output mode */ > > - rdmsrq(MSR_LX_GLD_MSR_CONFIG, msrval); > + msrval =3D rdmsrq(MSR_LX_GLD_MSR_CONFIG); > msrval &=3D ~MSR_LX_GLD_MSR_CONFIG_FMT; > > if (par->output & OUTPUT_PANEL) { > @@ -420,7 +420,7 @@ void lx_set_mode(struct fb_info *info) > > /* Set default watermark values */ > > - rdmsrq(MSR_LX_SPARE_MSR, msrval); > + msrval =3D rdmsrq(MSR_LX_SPARE_MSR); > > msrval &=3D ~(MSR_LX_SPARE_MSR_DIS_CFIFO_HGO > | MSR_LX_SPARE_MSR_VFIFO_ARB_SEL > @@ -592,10 +592,10 @@ static void lx_save_regs(struct lxfb_par *par) > } while ((i & GP_BLT_STATUS_PB) || !(i & GP_BLT_STATUS_CE)); > > /* save MSRs */ > - rdmsrq(MSR_LX_MSR_PADSEL, par->msr.padsel); > - rdmsrq(MSR_GLCP_DOTPLL, par->msr.dotpll); > - rdmsrq(MSR_LX_GLD_MSR_CONFIG, par->msr.dfglcfg); > - rdmsrq(MSR_LX_SPARE_MSR, par->msr.dcspare); > + par->msr.padsel =3D rdmsrq(MSR_LX_MSR_PADSEL); > + par->msr.dotpll =3D rdmsrq(MSR_GLCP_DOTPLL); > + par->msr.dfglcfg =3D rdmsrq(MSR_LX_GLD_MSR_CONFIG); > + par->msr.dcspare =3D rdmsrq(MSR_LX_SPARE_MSR); > > write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK); > > diff --git a/drivers/video/fbdev/geode/suspend_gx.c b/drivers/video/fbdev= /geode/suspend_gx.c > index 6c0a526ee8a2..2fa20acba62e 100644 > --- a/drivers/video/fbdev/geode/suspend_gx.c > +++ b/drivers/video/fbdev/geode/suspend_gx.c > @@ -21,8 +21,8 @@ static void gx_save_regs(struct gxfb_par *par) > } while (i & (GP_BLT_STATUS_BLT_PENDING | GP_BLT_STATUS_BLT_BUSY)= ); > > /* save MSRs */ > - rdmsrq(MSR_GX_MSR_PADSEL, par->msr.padsel); > - rdmsrq(MSR_GLCP_DOTPLL, par->msr.dotpll); > + par->msr.padsel =3D rdmsrq(MSR_GX_MSR_PADSEL); > + par->msr.dotpll =3D rdmsrq(MSR_GLCP_DOTPLL); > > write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK); > > @@ -43,7 +43,7 @@ static void gx_set_dotpll(uint32_t dotpll_hi) > struct msr dotpll; > int i; > > - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); > + dotpll.q =3D rdmsrq(MSR_GLCP_DOTPLL); > dotpll.l |=3D MSR_GLCP_DOTPLL_DOTRESET; > dotpll.l &=3D ~MSR_GLCP_DOTPLL_BYPASS; > dotpll.h =3D dotpll_hi; > @@ -51,7 +51,7 @@ static void gx_set_dotpll(uint32_t dotpll_hi) > > /* wait for the PLL to lock */ > for (i =3D 0; i < 200; i++) { > - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); > + dotpll.q =3D rdmsrq(MSR_GLCP_DOTPLL); > if (dotpll.l & MSR_GLCP_DOTPLL_LOCK) > break; > udelay(1); > diff --git a/drivers/video/fbdev/geode/video_gx.c b/drivers/video/fbdev/g= eode/video_gx.c > index 5717c3356949..b2cfadaf3ff8 100644 > --- a/drivers/video/fbdev/geode/video_gx.c > +++ b/drivers/video/fbdev/geode/video_gx.c > @@ -142,8 +142,8 @@ void gx_set_dclk_frequency(struct fb_info *info) > } > } > > - rdmsrq(MSR_GLCP_SYS_RSTPLL, sys_rstpll); > - rdmsrq(MSR_GLCP_DOTPLL, dotpll); > + sys_rstpll =3D rdmsrq(MSR_GLCP_SYS_RSTPLL); > + dotpll =3D rdmsrq(MSR_GLCP_DOTPLL); > > /* Program new M, N and P. */ > dotpll &=3D 0x00000000ffffffffull; > @@ -167,7 +167,7 @@ void gx_set_dclk_frequency(struct fb_info *info) > > /* Wait for LOCK bit. */ > do { > - rdmsrq(MSR_GLCP_DOTPLL, dotpll); > + dotpll =3D rdmsrq(MSR_GLCP_DOTPLL); > } while (timeout-- && !(dotpll & MSR_GLCP_DOTPLL_LOCK)); > } > > @@ -180,7 +180,7 @@ gx_configure_tft(struct fb_info *info) > > /* Set up the DF pad select MSR */ > > - rdmsrq(MSR_GX_MSR_PADSEL, val); > + val =3D rdmsrq(MSR_GX_MSR_PADSEL); > val &=3D ~MSR_GX_MSR_PADSEL_MASK; > val |=3D MSR_GX_MSR_PADSEL_TFT; > wrmsrq(MSR_GX_MSR_PADSEL, val); > diff --git a/include/linux/cs5535.h b/include/linux/cs5535.h > index 5ec2aca537bb..fef236cab7d8 100644 > --- a/include/linux/cs5535.h > +++ b/include/linux/cs5535.h > @@ -51,7 +51,7 @@ static inline int cs5535_pic_unreqz_select_high(unsigne= d int group, > { > struct msr val; > > - rdmsrq(MSR_PIC_ZSEL_HIGH, val.q); > + val.q =3D rdmsrq(MSR_PIC_ZSEL_HIGH); > val.l &=3D ~(0xF << (group * 4)); > val.l |=3D (irq & 0xF) << (group * 4); > wrmsrq(MSR_PIC_ZSEL_HIGH, val.q); > -- > 2.55.0 > From xen-devel-bounces@lists.xenproject.org Fri Sep 11 10:44:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 10:44:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416333.1645405 (Exim 4.92) (envelope-from ) id 1x4yjS-00068x-Dp; Fri, 11 Sep 2026 10:43:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416333.1645405; Fri, 11 Sep 2026 10:43:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yjS-00068q-A8; Fri, 11 Sep 2026 10:43:46 +0000 Received: by outflank-mailman (input) for mailman id 1416333; Fri, 11 Sep 2026 10:43:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4yjR-00068j-8c for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:43:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4yjQ-000zbS-0x for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:43:44 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3db4b-e002-0a2a0a5209dd-0a2a450c858e-22 for ; Fri, 11 Sep 2026 12:43:43 +0200 Received: from [209.85.208.42] (helo=mail-ed1-f42.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3db5f-f479-0a2a450c0019-d155d02ac573-3 for ; Fri, 11 Sep 2026 12:43:43 +0200 Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-6a9b4e73feaso1141810a12.1 for ; Fri, 11 Sep 2026 03:43:43 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a9b594f0fasm688499a12.25.2026.09.11.03.43.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 03:43:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789123423; x=1789728223; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=xSkdOFVgx9Y/tZ2KFB46VUO+inbqTTv16Au0ym3z5tE=; b=KTyjj+iCijCws9GBfO2L2vmKyQOY/EnJE4AelG3GZcqQCK05nCanUCkeQNUe/VYUjY FxOPMKq8nUfbOphzgaMkAYMySUXYxX4YKcZ2I7ORkq1OcphtzyquGFaxWIy9qnSCAJYE LJ2FPwFQEHdM37pThiY3/36SWPaa5dOHtVL6v8F8rCWXWco5VePO860lxXlZ27NwvN0o DhSzC544zRDE89iVCCpKS2z30meg/JwoRhkPbmsFvhoeKV9yJHaej44uXxt+a8d8Kb6i Ip1jqiT4xU29ta16OZbm5DrVnxkCSIW+/MnCXG1u56dz8zMo54ODg0H7Ws8bSpOaEX2a o+rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789123423; x=1789728223; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=xSkdOFVgx9Y/tZ2KFB46VUO+inbqTTv16Au0ym3z5tE=; b=sBby8Md+h1ir1niKUkMx4bG2kRXey6XDwVhru0vczPB52KT6S243QFwArtWLZYcPFX W2N3cwoKANVs7LcpIv27hLMxfjmMaUmoPcGEDVokcQWYwwrtRFereaVTuY8pwvIodBXC uPl+Fr13hObsx1fB0zRPgKJx5TmmLiaKHjltc0e0rIQ7BZH9wHg3PTTPUqT6CddAKf50 9JO9Rw3lkZJPUhh9S0nOz010kd3nRqgSuxXvR1duR9NssT2nlAaWJdOSV82V4x1Pa8BM amkIbkaz4F1I3IEhWEXkCigWuIRILLGL7rg6++XugfID4G6d/l7lvcN5wKQAvkG6dVps WF/A== X-Forwarded-Encrypted: i=1; AKwUvBxUe2RH8Htbw4RyRhb9x9VOE9kruU+tdw7k55k44OVja6vo0AHJY8dBTWe/e8DTaSbKdiiiEmAz0bY=@lists.xenproject.org X-Gm-Message-State: AFuF++lKi/1EF9M+HuK+NEMV7X9hCCuqxyMUaRjge5vcL+gvVSd9eePI 9KtMfkP2YPrQxOcZLumdy39EtPHpM0DC8YBZik35OH4xmzMG0nF52+Qd X-Gm-Gg: AYBFou1EgEdgWrOhn6lnZE0apshK1AjdCeWGHu0/HcFOzW2KRJtE+z0px9qW2GMxR5T TfkT1y8ui/rqg9ZBDUhTXly/oZiqTHz+WGaY/XYtpqFEPanFYI96ilMXAjU8bcapTHNJ2wcYgX4 pnlDkQ4DVQ1ZQzM+Vb0AgxuhmuO1wYCv4NawnV5UZhToPgEw3L09F67gtb4tdgSH3TD9UrfL6wC DJUUjl8y6hBNEJX4sLKi6KoJPOFzyN1yiitNv2gO04W/PGz0MI2cONBPu+Ex5wdRdFYMcCoPHSE gvwoSnBAnyGZiZR61/IrYkbZL+rQpc6xh0h3rjCQ5XA1IjOZ79da8yluY9qTzqB0qLeEEESLDdO nx648MrnpI1iezDb999EjH7Z20rkmtjmM8FCBB7JQdBDeR7rnh6Pfv3YEkryTABj5/hNshniPvU ZaYtvYddvzFRr/+qxCfRGd2LeOSjEZYQbpRDZCf7MvNNzZ4uGdJN/x+NLMCH+2/PoGETUuTtWPI 55w9bLTR1qJAGkE/IacSUPj/pz5//CI X-Received: by 2002:a05:6402:3788:b0:6a6:32fa:54f4 with SMTP id 4fb4d7f45d1cf-6a9b565304emr1582881a12.19.1789123423166; Fri, 11 Sep 2026 03:43:43 -0700 (PDT) Message-ID: <09bf2c58-de60-46a5-ab74-909814ae9bad@gmail.com> Date: Fri, 11 Sep 2026 12:43:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/39] xen/riscv: implement vCPU context switching To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> <2eb325d0-8f53-4790-889d-d68a03da0784@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2eb325d0-8f53-4790-889d-d68a03da0784@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1789123423-5270FA5B-8188E1DF/10/73395122804 X-purgate-type: spam X-purgate-size: 11244 On 9/10/26 3:29 PM, Jan Beulich wrote: > On 27.08.2026 17:20, Oleksii Kurochko wrote: >> +static void ctxt_switch_from(struct vcpu *p) >> +{ >> + /* >> + * When the idle VCPU is running, Xen will always stay in hypervisor >> + * mode. >> + * Therefore we don't need to save the context of an idle VCPU. >> + */ >> + if ( is_idle_vcpu(p) ) >> + return; >> + >> + p2m_ctxt_switch_from(p); >> + >> + vtimer_ctxt_switch_from(p); >> + >> + save_csr_regs(p); >> +} >> + >> +static void ctxt_switch_to(struct vcpu *n) >> +{ >> + /* >> + * When the idle VCPU is running, Xen will always stay in hypervisor >> + * mode. >> + * Therefore we don't need to restore the context of an idle VCPU. >> + */ >> + if ( is_idle_vcpu(n) ) >> + return; >> + >> + /* >> + * If this vCPU last ran on a different pCPU, invalidate its VMID so >> + * vmid_handle_vmenter() assigns a fresh one from the current pCPU's pool. >> + * Without this, two pCPUs could independently assign the same >> + * (generation, vmid) pair, generation counters start at the same value >> + * on all pCPUs and increment independently, causing TLB contamination. >> + */ >> + if ( n->arch.last_cpu != smp_processor_id() ) >> + vmid_flush_vcpu(n); > > I wonder why you need this, when we don't have anything similar in x86/HVM > (and at the first glance Arm doesn't have anything similar either). x86 does have the equivalent: vmx_do_resume() calls hvm_asid_flush_vcpu() in the active_cpu != smp_processor_id() branch, and svm_do_resume() does the same when launch_core != smp_processor_id() ("Migrating to another ASID domain. Request a new ASID."). The RISC-V VMID allocator follows the x86 ASID scheme: VMIDs are a per-pCPU resource with a per-pCPU generation, so a (generation, vmid) pair obtained on one pCPU means nothing on another. Arm doesn't need this because it allocates a single VMID per domain from a global bitmap. Also, note that I've update a little bit how VMIDs are flushed here [1] but this check still present IIURC. [1] https://lore.kernel.org/xen-devel/cover.1787838835.git.oleksii.kurochko@gmail.com/T/#m2c06e58c03a09022af112388be3585bf3ae6e4dc > >> + vtimer_ctxt_switch_to(n); >> + >> + restore_csr_regs(n); >> + >> + p2m_ctxt_switch_to(n); >> +} > > In the absenmce of a comment towards the need for this specific order I'd > expect these three calls to be ordered the opposite of their counterparts > in ctxt_switch_from(). I will put restore_csr_regs(n) (and rename it to csr_regs_ctxt_switch_to(n)) before vtimer_ctxt_switch_to(). There is no any specific requirement to be ordered in the way it is now. > >> +static void schedule_tail(struct vcpu *prev) >> +{ >> + unsigned int cpu = smp_processor_id(); >> + >> + ASSERT(prev != current); >> + >> + ctxt_switch_from(prev); >> + >> + /* >> + * Mark this CPU in next domain's dirty cpumasks before calling >> + * ctxt_switch_to(). This avoids a race on things like p2m flushing, >> + * which is synchronised on that function. >> + */ >> + if ( prev->domain != current->domain ) >> + { >> + cpumask_set_cpu(cpu, current->domain->dirty_cpumask); >> + >> + /* >> + * Once this hart drops out of prev's dirty_cpumask it stops being a >> + * target of p2m_tlb_flush(), while its TLB may still hold G-stage >> + * translations of prev's domain: neither the vCPU which just ran nor >> + * any other vCPU of that domain which ran here earlier has had its >> + * VMID invalidated. Move the hart to a new VMID generation so that >> + * none of them can be reached again. >> + * >> + * Switching away from the idle vCPU needs no bump: the idle domain >> + * has no p2m of its own, and whatever G-stage entries this hart may >> + * still hold (or speculatively create while HGATP keeps pointing at >> + * the last guest's p2m) are tagged with a VMID which was already made >> + * stale when that guest was switched out. Skipping the bump here also >> + * avoids burning a generation on every pass through idle. >> + */ >> + if ( !is_idle_vcpu(prev) ) >> + vmid_flush_hart(); >> + >> + cpumask_clear_cpu(cpu, prev->domain->dirty_cpumask); >> + } >> + write_atomic(¤t->dirty_cpu, cpu); >> + >> + ctxt_switch_to(current); >> + >> + write_atomic(&prev->dirty_cpu, VCPU_CPU_CLEAN); >> + >> + current->arch.last_cpu = cpu; >> + >> + /* >> + * sched_context_switched() internally uses a spinlock, >> + * which requires interrupts to be enabled. >> + */ >> + local_irq_enable(); >> + >> + sched_context_switched(prev, current); >> +} >> + >> +void context_switch(struct vcpu *prev, struct vcpu *next) >> +{ >> + ASSERT(local_irq_is_enabled()); >> + ASSERT(prev != next); >> + ASSERT(!vcpu_cpu_dirty(next)); >> + >> + local_irq_disable(); >> + >> + set_current(next); >> + >> + prev = __context_switch(prev, next); >> + >> + schedule_tail(prev); >> +} > > __context_switch() switches stacks, which can easily collide with code the > compiler has emitted. For example, the call to schedule_tail() may not be > a tail call, and context_switch()'s return address may have been spilled > to the stack (or into one of the s registers). There's a reason Arm and > x86 have reset_stack_and_jump(). RISC-V will have reset_stack_and_jump() that too but just introduced later and will be used for different use case (in continue_new_vcpu() introduced later in this patch series). But as the Arm RISC-V doesn't use reset_stack_and_jump() in context_switch(). This follows the Arm model: every vCPU has its own Xen stack, and from the incoming vCPU's point of view __context_switch() is ABI-conforming. It restores exactly the sp/ra/s0-s11 that vCPU had when it itself called __context_switch() from context_switch(). So after the return we are in next's own context_switch() frame, and anything the compiler spilled there (ra included) belongs to next. The only exception is a vCPU which has never run: its ra points at continue_new_vcpu() on an empty stack, and that's where reset_stack_and_jump() is needed, as on Arm. I'll make continue_new_vcpu() noreturn accordingly. x86 differs because its stacks are per-pCPU (IIUC), hence its context_switch() can't return. Here is some diagram for better understanding: vCPU A (stack A) vCPU B (stack B, switched out earlier) schedule() schedule() `- context_switch(A, B) `- context_switch(B, X) [A's frame: ra, s-regs] [B's frame: ra, s-regs] `- __context_switch() --------> "returns" here (save A, load B) schedule_tail(prev = A) ld ra <- B's frame (B's own ra) ret -> B's sched_context_switch() -> ... -> back into B > >> --- a/xen/arch/riscv/entry.S >> +++ b/xen/arch/riscv/entry.S >> @@ -99,3 +99,47 @@ restore_registers: >> >> sret >> END(handle_trap) >> + >> +/* >> + * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next) >> + * >> + * This is called on prev's stack, and returns on next's. > > With ra being switched it may also return to other than the caller. If > that's really intended, I think it also needs calling out here. Yes, it's intended. Normally it returns into next's own context_switch() (where next itself last called __context_switch()), and for a vCPU which has never run it returns to continue_new_vcpu(). I'll update the comment to: * This is called on prev's stack, and returns on next's. As ra is * switched too, it doesn't return to its caller: it returns to where * next last called it from, i.e. into next's own context_switch(), or, * for a vCPU which has never run, to continue_new_vcpu() with an empty * stack. > >> + * a0 - prev >> + * a1 - next >> + * >> + * Returns prev in a0 >> + */ >> +FUNC(__context_switch) >> + REG_S s0, VCPU_XEN_SAVED_CONTEXT_S0(a0) >> + REG_S s1, VCPU_XEN_SAVED_CONTEXT_S1(a0) >> + REG_S s2, VCPU_XEN_SAVED_CONTEXT_S2(a0) >> + REG_S s3, VCPU_XEN_SAVED_CONTEXT_S3(a0) >> + REG_S s4, VCPU_XEN_SAVED_CONTEXT_S4(a0) >> + REG_S s5, VCPU_XEN_SAVED_CONTEXT_S5(a0) >> + REG_S s6, VCPU_XEN_SAVED_CONTEXT_S6(a0) >> + REG_S s7, VCPU_XEN_SAVED_CONTEXT_S7(a0) >> + REG_S s8, VCPU_XEN_SAVED_CONTEXT_S8(a0) >> + REG_S s9, VCPU_XEN_SAVED_CONTEXT_S9(a0) >> + REG_S s10, VCPU_XEN_SAVED_CONTEXT_S10(a0) >> + REG_S s11, VCPU_XEN_SAVED_CONTEXT_S11(a0) >> + REG_S sp, VCPU_XEN_SAVED_CONTEXT_SP(a0) >> + REG_S ra, VCPU_XEN_SAVED_CONTEXT_RA(a0) >> + >> + REG_L s0, VCPU_XEN_SAVED_CONTEXT_S0(a1) >> + REG_L s1, VCPU_XEN_SAVED_CONTEXT_S1(a1) >> + REG_L s2, VCPU_XEN_SAVED_CONTEXT_S2(a1) >> + REG_L s3, VCPU_XEN_SAVED_CONTEXT_S3(a1) >> + REG_L s4, VCPU_XEN_SAVED_CONTEXT_S4(a1) >> + REG_L s5, VCPU_XEN_SAVED_CONTEXT_S5(a1) >> + REG_L s6, VCPU_XEN_SAVED_CONTEXT_S6(a1) >> + REG_L s7, VCPU_XEN_SAVED_CONTEXT_S7(a1) >> + REG_L s8, VCPU_XEN_SAVED_CONTEXT_S8(a1) >> + REG_L s9, VCPU_XEN_SAVED_CONTEXT_S9(a1) >> + REG_L s10, VCPU_XEN_SAVED_CONTEXT_S10(a1) >> + REG_L s11, VCPU_XEN_SAVED_CONTEXT_S11(a1) >> + REG_L sp, VCPU_XEN_SAVED_CONTEXT_SP(a1) >> + REG_L ra, VCPU_XEN_SAVED_CONTEXT_RA(a1) >> + >> + ret >> +END(__context_switch) > > What about gp and tp? tp points to this hart's pcpu_info (set up once per hart by setup_tp()), i.e. it's per-pCPU rather than per-vCPU state. __context_switch() starts and ends on the same hart, so tp has to be left alone. gp isn't used by Xen at all: there's no __global_pointer$ in the linker script, so no gp-relative relaxation happens, and the compiler never allocates gp. Neither of them is callee-saved per the psABI, so there's nothing to preserve across the call. The guest's gp/tp are part of the guest state and are going to be saved/restored via cpu_user_regs by the trap entry/exit path. > >> --- a/xen/arch/riscv/include/asm/system.h >> +++ b/xen/arch/riscv/include/asm/system.h >> @@ -76,6 +76,10 @@ static inline bool local_irq_is_enabled(void) >> >> #define arch_fetch_and_add(x, v) __sync_fetch_and_add(x, v) >> >> +struct vcpu; > > I don't think this is needed, as ... > >> +struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next); > > ... parsing of the return type will make the struct known (before > parameters are parsed). Make sense to me. I will drop forward declaration. > > Also - can't next be pointer-to-const? It could be. I will add const. Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 10:57:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 10:57:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416345.1645414 (Exim 4.92) (envelope-from ) id 1x4ywP-0007yJ-G4; Fri, 11 Sep 2026 10:57:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416345.1645414; Fri, 11 Sep 2026 10:57:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ywP-0007yC-D2; Fri, 11 Sep 2026 10:57:09 +0000 Received: by outflank-mailman (input) for mailman id 1416345; Fri, 11 Sep 2026 10:57:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ywN-0007y6-Sr for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:57:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4ywN-008BeG-4U for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:57:07 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3de7c-2eae-0a2a0a5409dd-0a2a4502857c-36 for ; Fri, 11 Sep 2026 12:57:06 +0200 Received: from [40.107.208.28] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3de81-6ca4-0a2a45020019-286bd01c7e09-3 for ; Fri, 11 Sep 2026 12:57:06 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DSVPR03MB989240.namprd03.prod.outlook.com (2603:10b6:8:3ab::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Fri, 11 Sep 2026 10:57:03 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 10:57:03 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bQ6jLbeF8MNyBrW/bsvqauCr1W1CDC/Gn9TEYw5a8/Ehm6ZGRLMi3EmtN+0KqveV8VbyFBfsVZpK5G45Bjpc1XHJQxS/Jnz8tI4O1j/wNw6YmcYvwJzUpX8z/TFZYn5nREHj79LLM6DojF9wVjktdWg2Djq4gBFzYsvp80mbbnMlYmdzX4mMAMhCXEGb5qCmyfHzfdp4qy3Kug1AdTbnf/g73L+9JEJM6osMU5r4/G0jxrjNKkzIAP2H8mI6BA/g8C/3/SVBdlmCiNd/fWeCFkL866MNm75Sk1IluRs9PNS0XMOEwdTaOqT4MqQmChiV1ckEMLxxk+mwGH1gjbbELA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nljzzvqJPfRDHGVDkaJ1LYB8iAC199hjhwim6D3fWf0=; b=nryx0qu/bW1R/abONW8njdgiuPdMSk9M0M0/x2MP6ckUDZt7tdUJoRDsgkCrmxGBg9fXzyctWMR9anYi95Yi3Tl0kg5ZiBxnAXb04EEPHjPM6Lc9Z10MEGfWibt0U6K+LYjjZSNurAYNHZ3E2iKT+mES7WxmFrB2kf8TwNATnRHg+4azxtn/+ON66XyuBwaQxkotE/aXa37/Hp/YFMJkYr9g3mxfzWHvwLuu5ubpA+qG+SvKMbZd2YovY5CCDzk6CbonrMl7CjSrKEyDe4zkODTA/IJOnOkgMsUPiDWbrTdg9DvZPm3Ru+FcTdcqMpOz4HyR+ikNLLckljkbTAuIYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nljzzvqJPfRDHGVDkaJ1LYB8iAC199hjhwim6D3fWf0=; b=KbrYMBZd/aoCEcQx+slqPY+sIOJ5e3dkFeHy5EFPa2axecLP1M6yit27FzM12AfbC+iySoZk/CxzVNapjiImWw38KHVd48SjDtH2ppg967d2DoKKSvj8RbgnUbGBljMZSwXCDtVleSx9zjLD+5EizbSgOW9EOvIgVs+XUCX17P8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 11 Sep 2026 11:56:59 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , Jason Andryuk , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v1 5/6] nestedsvm: Fix deferred event injection To: Ross Lagerwall , xen-devel@lists.xenproject.org References: <20260526124027.573412-1-ross.lagerwall@citrix.com> <20260526124027.573412-6-ross.lagerwall@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260526124027.573412-6-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0622.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:294::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DSVPR03MB989240:EE_ X-MS-Office365-Filtering-Correlation-Id: 12555fc8-b981-4804-e577-08df0ff3697e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|4143699003|11063799006|56012099006|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: gqduyZYcqV6WYFNGv2GYNR2KcncSZFGbBqOSysegX1TM+U/YpUI4bu7PRv4h2/A4umpHdWyq4Pt2kwH2MQ9V7IQILb1WULgKJCIvgJXVrMl0I/EVo/bJYE3bdxTkPaVzhwXeaXxDiTf/AKASube6EqsArmHwC9td0SUNTs3R5WlAV0cgRQK+oTqN7DbK1ORwpPjxVmxGkZo5Gy5jYYsH37MHl3D3wK1yCWx2PqVH1P3tVoFJGnSE1Uqt9Q1GdBPnROUmKCUqMGw1k/OZtVA3MeNyBynJoPfsvVwA5qaUP2bBCSBQTjKiqwTigFrfGqDbtH77Y+xd+h8Z71hnxcBDURKUmj7GJSHFUwn2ubDBHfopX6z5AvkyzyINp3zNGMz4AAstfuatyIt1oc6/eiy2sPjiPXMP765dSRmYA9ExvDzDKF3a3vl4U/8x4jeJvF2tqxDg1w3LX0QjgJvQWGZC/QPCODvIWune+o7JGwKsd30qm2+GmrSKQ+UkwcM/UvfCUQh04Y2f8INEpw3D7g8bUqCGxj900wVW4ulgbs2fm/FWUNsCUOMDxxnj3Exfr/WsdZHjY1UzkTQF2Joau+aP3LMyYTDIpCPGRGsxlLS6q/fE4aFxbcx0ae/dVhg5kenjg41BlsyxqGW4aM/ZBjc3pv4zff83LEHm1olsPdjGthk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K3l3K3lxR09mK2NrWXJ5SXk0RmtDc1BnaWFqbFZZSFJVRDRJdERncnBRRkNL?= =?utf-8?B?UDd3K1krR25sRTVYdjdQeUtGMVYrbjJYYTNuNW12NFUxVnpPMnhiSFJmK3VY?= =?utf-8?B?MlFZOHdrK1BRT3lIaXdyZnk1emd5Q0NaL2w5U09ReDZSOUEzVWs2UGFNcmlF?= =?utf-8?B?MTJINzhGSWl0d2I3SVZ3aEp2Vmk5d1hWWDFiZU5OSGZPS0hWQTRpRXpxbEk5?= =?utf-8?B?UldUc09QK1grdlhjbHoxd1dEU05sM29ROFBIQlZvei9oUUxVVEVrdXhKamEr?= =?utf-8?B?QkpUVTdTV0JuYWMvQWRXaGNkU1B0UkpSWGpNQ2FNMFlvYzBheVlXTGdiL0xJ?= =?utf-8?B?UGdsSFVNRVZhOHZOUzE3aGNIRHZWY0VSREpTdXhlWVFvTFRTNFA2TDk2c1dK?= =?utf-8?B?c0U5TE9UaTVpL2t5cnFNeGxkMUJjZHUwRzRMeTlvbnNGc0o3a3hwejJNQW4x?= =?utf-8?B?d05ReHJkYTBQeXZaR1J0eGdoaTJQbDZTbGM4SFRPTytoUjRVV09tZVl4RlIw?= =?utf-8?B?dE9nVUtmNWRMNDBPWTFhYWRjcnJFdG1TcDRuSTkyZnVScGNEYTR6L3VSOStZ?= =?utf-8?B?dndnRXpBNU91RGVUTWN1b2tYVTh3elJJMUx5L0x6UEJ4cHVKeGtUU0J3Q0s0?= =?utf-8?B?UHB0NmMxeVk2dGpSS3UrTDBnZGxFem9oRjVYVHR1aTNoU01SUjVFWVd2eTdD?= =?utf-8?B?bllCVDlWODR2QkM1VVZncTJqdW53VGNNaVVMZ09HQXBIdFhFQVdkOHZkNHFh?= =?utf-8?B?NVJKcHNESXllNFE5VHRyYkpJMFhreVg4anJvWE8zQmVVRXBERXBITFdjbUI1?= =?utf-8?B?bVcydm0wOGlDOTFoVnJrMXRaZGR5SFdiNjZZdUxZNDFFSnBUaDFBekx0Titx?= =?utf-8?B?WHloZlhLdE9GRklxRDRuSlNrb011R1BwTGNmZzdrN0RBWThZNVgzbk5aeDg1?= =?utf-8?B?VE5lcVhpbG91OW1tczJwSnFSNU8vWWp0NWZNTytRTFIxVk1iTTJKc0RXb2VS?= =?utf-8?B?eElweTNqRnY0L1d3ME1ndnhJenJ4amRLWGJsOEFIRkJDc3IrbG1GWE5BMlZK?= =?utf-8?B?T20xOWI3MVU5TVRBS0IycHZ4NzRLa0szM3pnSHdGQUpXQ1ZHb2dpSHpHQmxO?= =?utf-8?B?SjlKSS9PQ1ZNeWFXaGkvQldiQ3VlemZWVVFUemZLQkxXdTZCSDhBVCtheXIy?= =?utf-8?B?ZmRWU3FqbkxMVU00dGljbmZpbExTYS8vcExvN3FkT1lHYmVmbVpxOFRwNmJj?= =?utf-8?B?U1FPbURyOHpWSGV3cW9BZ09tTUJLRUdiaXUzU0c4ak84dkZBbUtwa3hFenNH?= =?utf-8?B?WTNCTEVUK0JnZWwya1pUZlh0Q3BRVTNibGxrbUV3dUhKUEd0aFMzZTJaQzlK?= =?utf-8?B?T2VmMVNxTFZhWnJRblZMTUlZQXJrQjNvMXhkeHVxVUV0YnE3MGRRMGVRelNF?= =?utf-8?B?UUprL3FpQjRIL0g1ci9VdEdidmlMVFozR2J2RS9zaHo3djNYcWRvbVpjLzFE?= =?utf-8?B?RVoyK3IzWmhtelNRVlE3RkJxWWgyUGprK1M1c0M0VTdxLzFiZDVmb3lUQnNy?= =?utf-8?B?TFk5NjMyWXJuVHQ1NG5teVIvcVlUVElFUUJiVk9GZU5LQ2xkRWlOVHFNY013?= =?utf-8?B?aWRiTE55ODY5UStWdUlPSGVhOENlM2k5OWpXNk56bjVMQlJIV08rM0RkNWls?= =?utf-8?B?bWRXc3hCTFVSNWhzWU94SDJmdDhURnMycVBZMUF6R25hWkpTWXdIcU9wdkIx?= =?utf-8?B?U2wyNXprbGZCNUhESFdsSzlqaTJTN1VHZmZxaXBVWERBdWFjSzRkbFEwdmtp?= =?utf-8?B?MkQyaWFqUklsMmxZODZUVmZYQzAweFIvYW81WDl5aGw0aGVCejFKRTJURjRt?= =?utf-8?B?ZGJ5RHhVSXRKVThpU3h6RTBxT1E1a1dUdDVHOXp1VExsaGRwNWJNZlNIWEdu?= =?utf-8?B?SHppNlhTWEtPRWE5QmxTVlhrSjlTa1ZlM1dJRmhtSERySVBsOERCdHBEMmhD?= =?utf-8?B?WFJIcmlrc3ZvUFRJeHlraWtIN3pJcm9zaGRuQlV3d1ZtV29EU3dwam50MUxG?= =?utf-8?B?SEJHN2pXMnh0cU9YeUdpU1hhZTNsM0dMY2RhZDdJMThtNkhmWGlDa05GdEZW?= =?utf-8?B?SkRZWGxtdEl0bVdYM2dZTWozS01kcStPTU1TNGpRM2YySEdBQ3EvZ1FiWG5P?= =?utf-8?B?aUJuZlV5cEZnUkhOUVY3N2xoSU0rbUk0UUV2NUNJU1pDd005b3hFWThhZ2Qr?= =?utf-8?B?YnZGdFp2SmZxcFdYUTJXSHdvMldCLzBJODhxNkZ2anlNdWRHb0l4Q2xweXJU?= =?utf-8?B?dWtzeTM0VS9MQlhpbzc3dThEcGlKbVp2amJjQTBZYys5VGdiNVJFQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12555fc8-b981-4804-e577-08df0ff3697e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 10:57:03.2262 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: LmXFk5/FI3+Y2LOeDBx/1V5y+/RbIX3UKzZ7Dtn/7q5VOasjAADLuN2ljCoDUrr8nMjP1kCwXuZP24aeUcWHO/LTH6MMRiIQOwE37bML5wU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR03MB989240 X-purgate-ID: tlsNG-720697/1789124226-F0EA32AC-B8711640/0/0 X-purgate-type: clean X-purgate-size: 875 On 26/05/2026 1:40 pm, Ross Lagerwall wrote: > If an event for L1 occurs while L2 is running, Xen should inject > VMEXIT_INTR and the event into L1. > > nestedsvm_vcpu_interrupt() and nestedsvm_vmexit_defer() set this up to > be handled later by nsvm_vcpu_vmexit_inject() after the switch back to > L1. However, the code there appears to be bogus and completely ignores > the source/vector set up in the first place. Fix this by using the > values to properly inject the event. > > Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") > Signed-off-by: Ross Lagerwall I'm reasonably sure this will be unnecessary when we fix the underlying problem of deferred entry/exit. In the meantime, while reviewing this I found a systematic naming error in the code.  I've submitted a fix separately. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 11 10:57:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 10:57:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416349.1645422 (Exim 4.92) (envelope-from ) id 1x4ywn-0008KD-Ps; Fri, 11 Sep 2026 10:57:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416349.1645422; Fri, 11 Sep 2026 10:57:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ywn-0008K1-NG; Fri, 11 Sep 2026 10:57:33 +0000 Received: by outflank-mailman (input) for mailman id 1416349; Fri, 11 Sep 2026 10:57:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4ywm-0008In-DP for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:57:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4ywl-00BDMC-Qa for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:57:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3de97-2eae-0a2a0a5409dd-0a2a4503a428-10 for ; Fri, 11 Sep 2026 12:57:31 +0200 Received: from [209.85.221.42] (helo=mail-wr1-f42.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3de9b-fae8-0a2a45030019-d155dd2ac5eb-3 for ; Fri, 11 Sep 2026 12:57:31 +0200 Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-4843f205a5bso493767f8f.1 for ; Fri, 11 Sep 2026 03:57:31 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb360409sm4763098f8f.36.2026.09.11.03.57.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 03:57:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1789124251; x=1789729051; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=XSWhjKEv4yauKi1wcpeW2I4UOkyAarDVJLO7YibIpAs=; b=uu0jJw2l3uH2rpswuL8dPUnUuU4IDxw5icJMlHDarA/8jTxucKmeM9iA549H0RCJA3 bGmglhF5Qezrvj6StTruckk0wLRG/qabL8Nk+Oi48AAST5RV4PLg4Jo/B5/pDEdAFuev 6mEGWEK/9UEGsoLAo2zVs1asXhUgQWX/RzW5Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789124251; x=1789729051; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=XSWhjKEv4yauKi1wcpeW2I4UOkyAarDVJLO7YibIpAs=; b=lQDHdGj06d9aGudjyKEzwoDrD85xjH3ZwN6YIRkJiW/DZiMezJXZTisdR1wd8BdtBl y9WtlCkwplQVwzy6b9pSv+95zJhDy4WSulVHBE456OegVC1x6pJf4tZ/ep0+eFelbXyk d1xMqsldOkHhqxVSq3BCPLbXsMfupnRUgBpAcsozrRlnjSG2iYPZb6T7S+q2mH9gnmdq JShLRlitDAA95WyaxC9QUJECtouS+vkAJgraVAkHgPs+btttTngeosajr8cFK6a9ta5z TL6Qm/+ibjnS+0Nx6dWd2yFc/3DK96ozR62Pc1ZCmDehK4SFMW55oYeqnfXZq9rldAUU /2TQ== X-Gm-Message-State: AFuF++lZYGFf8R0mQELug3Y5zi5RvEor+tHdqDIpa6Oqj7WY9zbSO2tS S+8KmGwHdfvajPaSR98yzMQGEVXcKaSlbOWCMPwYAlhZOajRvWR9j8Ey1KsgJdA0wBhFE+0rG87 XPX6L X-Gm-Gg: AYBFou0lcrYpYTnQNAbKkrf35Oou8mjrL8yLAckD442tz9o7xchArTCn7nlu6dLf3c7 +W9WGVF/NM+LIJ9nrOJJzhO8bKFErDN0XZS2zBQqnDUKm/uCdmKdRwcH1uK9KJGB7xWbXsPx661 XmqcFcnuilZVpPyR/j6/aLyINNUnZpQMCqLM8G9KpZ9Z+jbFeSMRZ6xjB00H4YRz8b0dLNt3QtL /9uLhNrvAiYisjuB5P8QgRAG7nW/Tp2Xt5yN+vIzIPtoYv6It9XfUSNPPO0E7THowdkeCj/HusM bu2kLhpMDxM3BO1Z7ybkcDAWKReOEtB6PyNTLaD4Stlw7OKHe6qMDdouzmougyNVoLJDvJ3lLtY FEswVZzjPXGuhKy0ehizCHUWQ+dEwKxtOGACW3VwkdxlKsguHDcPHE2Ay1QXeg0ZghuKdcBKoNF iKdnx0YqTpkkoprfSxN/gx1VdqMd7TfaN576iOFI/4/YW6VASp1CDiKGRYnUS5cyGD1Du4XReWj z42Y2SRbJt+rswXkHrmGtCc1/BwzKwkjOH4/KpIOKYMaC4dBVo= X-Received: by 2002:a05:6000:288f:b0:485:8a46:b3be with SMTP id ffacd0b85a97d-486eb32e804mr4106104f8f.38.1789124250538; Fri, 11 Sep 2026 03:57:30 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Ross Lagerwall Subject: [PATCH] x86: Rename X86_ET_EXT_INTR to X86_ET_INTR and fix function names Date: Fri, 11 Sep 2026 11:57:28 +0100 Message-Id: <20260911105728.3633306-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1789124251-6CADC4E9-DAAA6F70/0/0 X-purgate-type: clean X-purgate-size: 9988 The name X86_ET_EXT_INTR came from the VT-x code originally, but it's not really correct. The SDM doens't give a concrete name, and only describes the fields as "external interrupts". The APM does give a concrete name of INTR, and both Intel and AMD use the name INTR for related purposes elsewhere; the name derives originally from #INTR which was a real pin on early processors. Very importantly, this is distinct from ExtINT which is a type of maskable interrupt which can be sent in an x86 system. Therefore rename all {svm,vmx}_*_extint() to {svm,vmx}_*_intr(), as they pertain to all maskable interrupts, not only to ExtINT interrupts. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie CC: Jason Andryuk CC: Ross Lagerwall --- xen/arch/x86/hvm/hvm.c | 2 +- xen/arch/x86/hvm/svm/intr.c | 6 +++--- xen/arch/x86/hvm/svm/svm.c | 2 +- xen/arch/x86/hvm/vmx/intr.c | 6 +++--- xen/arch/x86/hvm/vmx/vmx.c | 10 +++++----- xen/arch/x86/hvm/vmx/vvmx.c | 2 +- xen/arch/x86/include/asm/hvm/vmx/vmx.h | 2 +- xen/arch/x86/include/asm/x86-defns.h | 2 +- xen/arch/x86/traps.c | 6 +++--- xen/arch/x86/x86_emulate/x86_emulate.c | 2 +- 10 files changed, 20 insertions(+), 20 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 9a4147b62eeb..e499c1d1cf31 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -230,7 +230,7 @@ int hvm_event_needs_reinjection(uint8_t type, uint8_t vector) { switch ( type ) { - case X86_ET_EXT_INTR: + case X86_ET_INTR: case X86_ET_NMI: return 1; case X86_ET_HW_EXC: diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c index cf0621d2f628..4b0debfa9a2e 100644 --- a/xen/arch/x86/hvm/svm/intr.c +++ b/xen/arch/x86/hvm/svm/intr.c @@ -55,14 +55,14 @@ static void svm_inject_nmi(struct vcpu *v) vmcb, general1_intercepts | GENERAL1_INTERCEPT_IRET); } -static void svm_inject_extint(struct vcpu *v, int vector) +static void svm_inject_intr(struct vcpu *v, int vector) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; intinfo_t event; event.raw = 0; event.v = true; - event.type = X86_ET_EXT_INTR; + event.type = X86_ET_INTR; event.vector = vector; ASSERT(!vmcb->event_inj.v); @@ -225,7 +225,7 @@ void asmlinkage svm_intr_assist(void) else { TRACE(TRC_HVM_INJ_VIRQ, intack.vector, /*fake=*/ 0); - svm_inject_extint(v, intack.vector); + svm_inject_intr(v, intack.vector); pt_intr_post(v, intack); } diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 5f5d903d872d..b5fc459e624a 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2808,7 +2808,7 @@ void asmlinkage svm_vmexit_handler(void) vmcb->exit_int_info.vector == X86_EXC_OF ) break; /* Fallthrough */ - case X86_ET_EXT_INTR: + case X86_ET_INTR: case X86_ET_NMI: insn_len = 0; break; diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c index a8ced95871df..6c220c4c2e49 100644 --- a/xen/arch/x86/hvm/vmx/intr.c +++ b/xen/arch/x86/hvm/vmx/intr.c @@ -182,7 +182,7 @@ static int nvmx_intr_intercept(struct vcpu *v, struct hvm_intack intack) if ( intack.source == hvm_intsrc_pic || intack.source == hvm_intsrc_lapic ) { - vmx_inject_extint(intack.vector, intack.source); + vmx_inject_intr(intack.vector, intack.source); ctrl = get_vvmcs(v, VM_EXIT_CONTROLS); if ( ctrl & VM_EXIT_ACK_INTR_ON_EXIT ) @@ -202,7 +202,7 @@ static int nvmx_intr_intercept(struct vcpu *v, struct hvm_intack intack) } else if ( intack.source == hvm_intsrc_vector ) { - vmx_inject_extint(intack.vector, intack.source); + vmx_inject_intr(intack.vector, intack.source); return 1; } } @@ -389,7 +389,7 @@ void asmlinkage vmx_intr_assist(void) else { TRACE(TRC_HVM_INJ_VIRQ, intack.vector, /*fake=*/ 0); - vmx_inject_extint(intack.vector, intack.source); + vmx_inject_intr(intack.vector, intack.source); pt_intr_post(v, intack); } diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index e55c90ce7f63..7fa404878acc 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2022,7 +2022,7 @@ static void __vmx_inject_exception(int trap, int type, int error_code) curr->arch.hvm.vmx.vmx_emulate = 1; } -void vmx_inject_extint(int trap, uint8_t source) +void vmx_inject_intr(int trap, uint8_t source) { struct vcpu *v = current; u32 pin_based_cntrl; @@ -2032,13 +2032,13 @@ void vmx_inject_extint(int trap, uint8_t source) if ( pin_based_cntrl & PIN_BASED_EXT_INTR_MASK ) { nvmx_enqueue_n2_exceptions (v, INTR_INFO_VALID_MASK | - MASK_INSR(X86_ET_EXT_INTR, INTR_INFO_INTR_TYPE_MASK) | + MASK_INSR(X86_ET_INTR, INTR_INFO_INTR_TYPE_MASK) | MASK_INSR(trap, INTR_INFO_VECTOR_MASK), X86_EVENT_NO_EC, source); return; } } - __vmx_inject_exception(trap, X86_ET_EXT_INTR, X86_EVENT_NO_EC); + __vmx_inject_exception(trap, X86_ET_INTR, X86_EVENT_NO_EC); } void vmx_inject_nmi(void) @@ -3846,7 +3846,7 @@ static int cf_check vmx_msr_write_intercept( return X86EMUL_EXCEPTION; } -static void vmx_do_extint(struct cpu_user_regs *regs) +static void vmx_do_intr(struct cpu_user_regs *regs) { unsigned long vector; @@ -4219,7 +4219,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs) switch ( (uint16_t)exit_reason ) { case EXIT_REASON_EXTERNAL_INTERRUPT: - vmx_do_extint(regs); + vmx_do_intr(regs); break; case EXIT_REASON_EXCEPTION_NMI: __vmread(VM_EXIT_INTR_INFO, &intr_info); diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index a5aa5eb163a3..e2407f07c2d5 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1346,7 +1346,7 @@ static void sync_exception_state(struct vcpu *v) switch ( MASK_EXTR(nvmx->intr.intr_info, INTR_INFO_INTR_TYPE_MASK) ) { - case X86_ET_EXT_INTR: + case X86_ET_INTR: /* rename exit_reason to EXTERNAL_INTERRUPT */ set_vvmcs(v, VM_EXIT_REASON, EXIT_REASON_EXTERNAL_INTERRUPT); set_vvmcs(v, EXIT_QUALIFICATION, 0); diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h index da04752e1752..713d0900a9ce 100644 --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h @@ -484,7 +484,7 @@ static inline void vpid_sync_all(void) int cf_check vmx_guest_x86_mode(struct vcpu *v); unsigned int vmx_get_cpl(void); -void vmx_inject_extint(int trap, uint8_t source); +void vmx_inject_intr(int trap, uint8_t source); void vmx_inject_nmi(void); void ept_walk_table(struct domain *d, unsigned long gfn); diff --git a/xen/arch/x86/include/asm/x86-defns.h b/xen/arch/x86/include/asm/x86-defns.h index cce0f4d990fe..c210e9e6e19f 100644 --- a/xen/arch/x86/include/asm/x86-defns.h +++ b/xen/arch/x86/include/asm/x86-defns.h @@ -221,7 +221,7 @@ * These encodings were first used in VMCB/VMCS fields, but have become * architectural in the FRED spec. */ -#define X86_ET_EXT_INTR 0 /* External Interrupt */ +#define X86_ET_INTR 0 /* External Interrupt */ #define X86_ET_NMI 2 /* NMI */ #define X86_ET_HW_EXC 3 /* Hardware Exception (#PF/#GP/etc) */ #define X86_ET_SW_INT 4 /* Software Interrupt (INT $n) */ diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 177496630520..ac01ba08723d 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1041,7 +1041,7 @@ void show_execution_state_nmi(const cpumask_t *mask, bool show_all) static const char *x86_et_name(unsigned int type) { static const char *const names[] = { - [X86_ET_EXT_INTR] = "EXT_INTR", + [X86_ET_INTR] = "INTR", [X86_ET_NMI] = "NMI", [X86_ET_HW_EXC] = "HW_EXC", [X86_ET_SW_INT] = "SW_INT", @@ -2295,7 +2295,7 @@ void asmlinkage entry_from_pv(struct cpu_user_regs *regs) switch ( type ) { - case X86_ET_EXT_INTR: + case X86_ET_INTR: return do_IRQ(regs); case X86_ET_NMI: @@ -2606,7 +2606,7 @@ void asmlinkage entry_from_xen(struct cpu_user_regs *regs) switch ( type ) { - case X86_ET_EXT_INTR: + case X86_ET_INTR: return do_IRQ(regs); case X86_ET_NMI: diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c index 830ad90c9c2a..89c37fea2cab 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -8691,7 +8691,7 @@ static void __init __maybe_unused build_assertions(void) BUILD_BUG_ON(x86_seg_gs != 5); /* Check X86_ET_* against VMCB EVENTINJ and VMCS INTR_INFO type fields. */ - BUILD_BUG_ON(X86_ET_EXT_INTR != 0); + BUILD_BUG_ON(X86_ET_INTR != 0); BUILD_BUG_ON(X86_ET_NMI != 2); BUILD_BUG_ON(X86_ET_HW_EXC != 3); BUILD_BUG_ON(X86_ET_SW_INT != 4); base-commit: d7bf1b8ea2756b6160d41bf377a85365dbd6f8f6 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 10:57:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 10:57:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416357.1645432 (Exim 4.92) (envelope-from ) id 1x4yx5-0000Ps-1B; Fri, 11 Sep 2026 10:57:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416357.1645432; Fri, 11 Sep 2026 10:57:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yx4-0000Pl-Ue; Fri, 11 Sep 2026 10:57:50 +0000 Received: by outflank-mailman (input) for mailman id 1416357; Fri, 11 Sep 2026 10:57:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yx2-0000Mn-SG for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 10:57:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4yx2-00DmiI-9E for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:57:48 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3dea3-bab6-0a2a0a5309dd-0a2a450b9c32-20 for ; Fri, 11 Sep 2026 12:57:48 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3deac-b7e8-0a2a450b0019-4a7de18caf02-3 for ; Fri, 11 Sep 2026 12:57:48 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e2406so3468285e9.1 for ; Fri, 11 Sep 2026 03:57:48 -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-49d26c1bfc1sm169531255e9.4.2026.09.11.03.57.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 03:57:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789124268; x=1789729068; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=NiiTZt++Bgak0agl4uqB6Sx2DVjDFtRD+ugJ6G8+EnE=; b=K0I5QSPJgXqGvg+QvQfXcw9LzYg5qOI5HfOXLnAgw0pKKmB2fnXPKPshYTUTbDFtEW zVY/vEc/BSrhWJbrZ0oAtlBzTD0FdSGOTLeT2BCeh7q4toXX/TO0sTAM9MeKtrpXH46w sv+mkXuHfM3no9kEzbLqwxAdhBoqlu7Kp5ZbtfvDzcnDsuCwUKE3uPJ2XVdyn913pyge gm/hSsW8HWzQJFJhmkWL1smScv+/Bg5wbdr13wPaRmebBhU1Bqipb59J/UIdixg4S0an xJByLjKYBrF+HcCv36lfhCbgaKuHK0pbCSWAmQ9pvWRw+YNPyqDZoF94wXu3qJzOSzgY AKPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789124268; x=1789729068; h=content-transfer-encoding:content-type: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:content-type; bh=NiiTZt++Bgak0agl4uqB6Sx2DVjDFtRD+ugJ6G8+EnE=; b=hdoMowNfY4zCMkwEMrSUslkyH/0D+DIfLmV0f1YrncBs0N1JPRX5s//Tie1D3ernwi pMSA/FBP0OhphVHapCBwrrdw16QRpHA4OzRSTMgbxHYar61KPKqjCXM5I+aLn7Ap2oC/ nRl2ZOA2M84awG/smqifnx7OK7jPbQYNX9a+MvG/1M6Zv6spXAemZ0ijvtsxfJLkuAON 0hsZirVLw4MxTtZrzsCoPM6mL3S8+7F/kIUlcEbC0/ARmXwY4SfbWRrRTFGqTzOzh0Jm mvENWscx0HMyWv23iUBF6VVSylzcaVy0Svsaon9cAP6KUUUYXsasTKr2aLSOAnQ5iCKG gLrQ== X-Forwarded-Encrypted: i=1; AKwUvBz+7C1DVgKtSeLDzBcVyibVcXPFBkTg59YXjJ2uOJu3942dewmg62sQUtOYCbgEJpkBLwiEDpdjrww=@lists.xenproject.org X-Gm-Message-State: AFuF++nLxd9nf0v4/QgVmjSa1MFIrbsmMxYa0KMYwY+yf90psIkA5SoE pq8/VF10dDnEGxrowrc5AlYDbIqmvDGfmpYss1n6XGjDlnRfR5qgmsCOABXwHPy13A== X-Gm-Gg: AYBFou3O5FW+B7dXL19u6bCxxbXPl+e4gDAN3Nddl44reA7e9KIB2ow1oYlBzhmNhml U1Ycev1Sjw9k5oNoTEZojOJNOjUKL4oVYKDQbP8FPzrjcHQB8bTK8KSxGldc2dqGmWE3TxfOtmI XwO3bvFRjy5/Uf4uSptjrQ0LakBf64ECh3iZsDC7LiU5bqVEvxXR3gEK0WwqLJ5yENFv7kh2Z3h NwyAr3LBLm0duq9dz6+dIALE0Uzhg86pmH5S4veok11g7vtJiLDJMrZnSNHgQLY/8noUzvpQWWk SYODm5K0f53JZ1+BnQgV4Zi/tKaXBainav//hY15kSpk1lRYG3hfn6VgcwkJ/tL7jtVCk6Zu4Yz 4wK4kVt3/V0CSsk0VwIWIEIK4htRpDqVFiX62etG9oyqMqoimJY6fPkUgODW1XKDdW5GqPtHIPT GphvDwyR4UvPvRUA3jamFQD2ZuzE9p0KryPUPQNqNVcQPrAXv2+Ti6s8Q8+TDYbT4JFgCFtxbS7 cWEtO470NPVrNH8f1xMNnywpjzP10qQMoucgDw5m4Ll9shVAabZ1dNzH4R/duY= X-Received: by 2002:a05:600c:698d:b0:49e:6865:904e with SMTP id 5b1f17b1804b1-49e6865921amr4416355e9.12.1789124267613; Fri, 11 Sep 2026 03:57:47 -0700 (PDT) Message-ID: Date: Fri, 11 Sep 2026 12:57:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/7] x86: make UPDATE_ENTRY() allow for multiple operation flags To: Teddy Astie Cc: andrew.cooper3@citrix.com, George Dunlap , Kevin Lampis , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-2-kevin.lampis@citrix.com> <1789119951.8631fc262581453bbf619ec5b2062170.1a08fdbf3c0000c4f3@vates.tech> 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: <1789119951.8631fc262581453bbf619ec5b2062170.1a08fdbf3c0000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789124268-AB2DC9EA-891894A2/0/0 X-purgate-type: clean X-purgate-size: 1120 On 11.09.2026 11:45, Teddy Astie wrote: > Le 10/09/2026 à 22:31, Kevin Lampis a>> @@ -4135,18 +4134,23 @@ long do_mmu_update( >> >> if ( page_lock(page) ) >> { >> + unsigned int update_flags = (cmd == MMU_PT_UPDATE_PRESERVE_AD) >> + ? PTE_UPDATE_PRESERVE_AD >> + : (cmd == MMU_PT_UPDATE_NO_TRANSLATE) >> + ? PTE_UPDATE_NO_TRANSLATE : 0; >> + > > I'm not fully convinced by the double-ternary operator here. While it's > a bit more compact, I don't find it very readable, I would prefer > something like > > unsigned int update_flags = 0; > if ( cmd == MMU_PT_UPDATE_PRESERVE_AD ) > update_flags = PTE_UPDATE_PRESERVE_AD; > if ( cmd == MMU_PT_UPDATE_NO_TRANSLATE ) > update_flags = PTE_UPDATE_NO_TRANSLATE; > > Which is one line longer, but looks to me more clear on what it does. If you wanted it like this, switch() would be the way to go. Imo undesirable here, hence why I wrote it as it is. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 11 11:00:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 11:00:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416375.1645441 (Exim 4.92) (envelope-from ) id 1x4yzv-0002Gv-Dm; Fri, 11 Sep 2026 11:00:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416375.1645441; Fri, 11 Sep 2026 11:00:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yzv-0002Go-B8; Fri, 11 Sep 2026 11:00:47 +0000 Received: by outflank-mailman (input) for mailman id 1416375; Fri, 11 Sep 2026 11:00:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4yzu-0002Gi-1b for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:00:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4yzt-0013Iv-Eb for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:00:45 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3df58-2eae-0a2a0a5409dd-0a2a4507e75e-16 for ; Fri, 11 Sep 2026 13:00:45 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3df5d-b4ea-0a2a45070019-d155802be92b-3 for ; Fri, 11 Sep 2026 13:00:45 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49cd77e0f95so6335215e9.3 for ; Fri, 11 Sep 2026 04:00:45 -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-49e60ad0614sm70116235e9.10.2026.09.11.04.00.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 04:00:43 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789124445; x=1789729245; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=A8PdBJR7CzaykuyZqgUz+eOqrsIDkGTM21u88RGF+wk=; b=LZYDsFoOakGFjs6nGhGP7TqV1LJOsfizZ9AUr6cgWVjNIx8T2/x+TVaNPSmFr2Fk9t 6cvxf7UduKVMumN9E1EKYNJkhbMYQMDk80O7sOfBn7qGqDDg76VP2pZQFgL4vjU5WyDN zqlz66FOqurvhonuvZFE6h9TKwjJJwoprOnmhaCrz6TgtYlgfGWIK08LYmBvNjZm0ILr UZ30cKTRnfKWzlR1PyWH4nNLq6N3F88FbjPOm1mhw7FA4ahhiYWeFROEBu2bJDfsadM3 zgSf3wJr2j/kRVR71CuCq+e4g9nzpZG/sBBYJNJAQJkMkAVpPUmA1BxtMDSWE2B83gBE RJfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789124445; x=1789729245; h=content-transfer-encoding:content-type: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:content-type; bh=A8PdBJR7CzaykuyZqgUz+eOqrsIDkGTM21u88RGF+wk=; b=PNdK+pVIgSQtosfeJ1GwlbDnYrGEHNyu2ZgFK3Yh0nijod41YLO+Vzo1fEHvIxVa2f EiZ3ydzQ/8djnPhSALn+PAabBysb9z6/UalvDZNXVfsvyLsHdN7iL7IfQO5g7yJop7Ou 58pUyvEo1Xet6I2ylfh2WJeIXRL2esDFT4+WVeRL6J8PDxhOoIijT3ua7yscb598j8hf N+lbOQQFnb/jUG6DerWGtoPMfUDx5I1Bd/jmPODD1K3chJawLCKjRVbNx5Bs2UuvTyoW qquKZJfLqcZNXnEJc/NVDuKcjAY3GAe3u0LJG4RpaNnLtDSccP8hSIjI0C/8E/caWy8Q ulNw== X-Forwarded-Encrypted: i=1; AKwUvBzI/bkBqXgv6nIOCk9omK3kwib2Z8nQHNtThBtjNRp4tcLg6EaCTOUskWjKqXIuk5EGxgWsC9cFhI0=@lists.xenproject.org X-Gm-Message-State: AFuF++kmDOhtuKdrhF41u56hJP9KOhe3LQZESY8Hq/U7z5AEhYdBDhnR qvAeVvfdkBfbaZFo7oVN0RRDw554/9ik4Xo6VYqlTb6lnJ4ym+E/xBDbHi03j8fjiA== X-Gm-Gg: AYBFou3ggGNU4wWhIuR7pIlH/kULeNjc1/e9BB5ANsaK9MStwZegaEtciohYPKsZZv2 DDgfQ3hQKeE9hH4Sk7lZZ4Qj5R12+Cnx6WaYJqmlcqwQI0kE7yeBE9qv/v5Nmg6MYy/U0NurUDX v/x6IO87axs7rhqBPwgSunld9q1bkKZJo0FXU7Dav8/9Zr6JOfWu+08cFWWLxz5gcNYEZ1j1KBV BWW5KDLz205ZSSP4s0jbs5yaLX6EtR10zGSftR4eqLWCXxfjD+XFuUO3RCfpu3JnTTfj4yG5M8N pDN4tvyLryEiDr30JS+0gJ8KH94DoeFwhDufowtWhl+Z2EbEZARBcnMyF2neBry1MUOH/TEDNPY CbkNsUkwAo6asDaS5e0bPua38xVExvHcmINF9LOPN9x6ZKVH0NLHYOmaGW/fp63IBy96Tlc/arK La8+JFnEcxZJ5/uvrlu1FojPrhrvhzXvKmlqaRP74U7a3ex/5+AIq6U5i/O6ltmfT0LVPr+r5JR axdBcIbWC0QzTDXqXzF9yuR7yGxD6rRTQSSZdFRIfoKPO/+u7foSBnnOnAS+awc X-Received: by 2002:a05:600d:8490:20b0:49d:e0c:e560 with SMTP id 5b1f17b1804b1-49e61983771mr31443445e9.4.1789124443474; Fri, 11 Sep 2026 04:00:43 -0700 (PDT) Message-ID: <87a733b3-4647-4fe7-84f3-10280a4e077d@suse.com> Date: Fri, 11 Sep 2026 13:00:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: Rename X86_ET_EXT_INTR to X86_ET_INTR and fix function names To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Jason Andryuk , Ross Lagerwall , Xen-devel References: <20260911105728.3633306-1-andrew.cooper3@citrix.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: <20260911105728.3633306-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789124445-358C1AE4-B07EEFC5/0/0 X-purgate-type: clean X-purgate-size: 868 On 11.09.2026 12:57, Andrew Cooper wrote: > The name X86_ET_EXT_INTR came from the VT-x code originally, but it's not > really correct. > > The SDM doens't give a concrete name, and only describes the fields as > "external interrupts". The APM does give a concrete name of INTR, and both > Intel and AMD use the name INTR for related purposes elsewhere; the name > derives originally from #INTR which was a real pin on early processors. > > Very importantly, this is distinct from ExtINT which is a type of maskable > interrupt which can be sent in an x86 system. > > Therefore rename all {svm,vmx}_*_extint() to {svm,vmx}_*_intr(), as they > pertain to all maskable interrupts, not only to ExtINT interrupts. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Fri Sep 11 11:03:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 11:03:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416386.1645450 (Exim 4.92) (envelope-from ) id 1x4z2h-0002v8-So; Fri, 11 Sep 2026 11:03:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416386.1645450; Fri, 11 Sep 2026 11:03:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4z2h-0002v1-Q7; Fri, 11 Sep 2026 11:03:39 +0000 Received: by outflank-mailman (input) for mailman id 1416386; Fri, 11 Sep 2026 11:03:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4z2g-0002uv-86 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:03:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4z2f-00144p-L8 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:03:37 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3e001-8faa-0a2a0a5109dd-0a2a4508ca52-24 for ; Fri, 11 Sep 2026 13:03:37 +0200 Received: from [52.101.52.24] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3e007-f659-0a2a45080019-346534185a6c-3 for ; Fri, 11 Sep 2026 13:03:36 +0200 Received: from MW4P223CA0015.NAMP223.PROD.OUTLOOK.COM (2603:10b6:303:80::20) by DM4PR12MB7624.namprd12.prod.outlook.com (2603:10b6:8:107::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.10; Fri, 11 Sep 2026 11:03:30 +0000 Received: from CO1PEPF000075F4.namprd03.prod.outlook.com (2603:10b6:303:80:cafe::8a) by MW4P223CA0015.outlook.office365.com (2603:10b6:303:80::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.10 via Frontend Transport; Fri, 11 Sep 2026 11:03:29 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CO1PEPF000075F4.mail.protection.outlook.com (10.167.249.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.5 via Frontend Transport; Fri, 11 Sep 2026 11:03:29 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 11 Sep 2026 06:03:29 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Fri, 11 Sep 2026 06:03:28 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=J7AOgJc8Un7D7+CMG4PirKd0+2jcLaHSGwli0wGPLSMAQIRJSRd0O+WXozxrbGs+blEeFECzj/ri6l8zrjRIQtTZZi5Yw3SpJYtKye6WPCkdh8AIfL/ySWfYgbctpqt/5p+4AJJZhIrPFoCHgir9XK3IVlIV0NKMgpDjTQfWraub6aduEMv/NWcVtHL94lgCyNNwPACRFqGWGk6YrTzPl4JvqM+ys6WqKJLF5yq4hIElyZ/PX7/GgnV6iwY58cJqa1On4CYOYt8uzgvReba/s6Dnml+ecKz2v6JqLPVBApT2L/aMjiRGV1hrKFdb+ghZtK8gbcBYzhOCuQxN1PMDzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/ecex6EjQ7/nbKiyjI7EhIgLYA7bPmZOxJAuA8lE0sc=; b=jgyb30lEM0Wf7TJkF8actGz5XljAILAfZeejfpgfxKVa5iGgjjNUksrMCnm3VT7gxgZXW0P4rz0eG/tCaLpEZLyw1Zt0/Jqx59yMIOTIjsGanFdLn0+opXyjw7I+Nr6uzj+Wry6qSHvIUgb0YJ/iDx/fLOMv/FjiM9D/GB9szhhMpscDeYm998e5PRQOFvIyYHtsg5Y8WNwXgzdGF1N4PRizK8Ps6OIreuk1MaGKHAEb7M6PhNHoe9RSssotek2pga4ZwMJ3H+1VjZv05HFCMk0MagpbD9utZc2MEmVASb1VRo/7T+mYG9Sy2CUUmHC6z2t+L1ChbKeqRr3O/1guuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/ecex6EjQ7/nbKiyjI7EhIgLYA7bPmZOxJAuA8lE0sc=; b=hwFdQ4YJKtXMxvqRr21NOoqe3iGypoFNRV8kHInc6SFvucwQHEwuxEBF2W/XBWr4BCHn4iJNLVuzFxkqIOMO9gwig2f6cajnuimS5W5RxXEpqExIGS1GJsE27om0wP6JLwMfIcqYsj8HzclFQ6DMxLURaNe/kmyHmgdw3GO5ANo= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: Date: Fri, 11 Sep 2026 13:03:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/4] xen/arm: make is_espi() a pure range predicate To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <8e42437f8abca2722f1a2e2568bbb5b938c23e85.1787050437.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <8e42437f8abca2722f1a2e2568bbb5b938c23e85.1787050437.git.mykola_kvach@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000075F4:EE_|DM4PR12MB7624:EE_ X-MS-Office365-Filtering-Correlation-Id: 1df4e77b-4bec-4e05-8bdb-08df0ff44ff2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|376014|82310400026|1800799024|4143699003|10067099003|5023799004|11063799006|56012099006|6133799003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: hrQvIuLTN0EoaMXEEloJ2NCJgy3QVM+DgDvYZHdiWgloNKyxSElNhx9Wxyf4DK/n8b1TGcbar8BrpHK1gVSILTT+swzPhF75390gnQPgakUBptNe7nZ1O9MfrieDHxO3gnPc9t/EdC2iVwlSXBuxO4Xg9aQ7jHcZwTUYw5NR13DTPjTOuvYOXpB7+kIyQT86DIqd4K4QeyGAmdsRiyBQWZSqPxYq/GDHFeTy6lMtmr92YKNxvUkMFn3r0BcD/e9HE90XvLxHjq3mvo3eYHtpROO085e/wW/kuwLpSUGmifQBtEXQtuqFMyW1aBRoXyV896HgaWAEzawNVSdyFnrYFxtRFG+g3o1GNwTYHj0aJz2NS+Lbh/TRgjR54rTv31wOGq2+4sCAGrOYr0lbsvSIMCocEGLWMFuktwWb8IU5NNedRjcDGMi9NPAq9Vl/aIK4iVPr+vvQg4F598fO1eTXLV0IeB94IhXjgQib9tmOhY+JThKwZ5zTam1kVbsMeuHip/MAN7iIXbVDA+8egIaiRoHKVzkylMtkNMTVJR+VFdIj/VnK6J2a6BXqvI8lyeRL4RyV72429TeNEzD7rM37fkYkdk4qBtgdZSi7zfZP2a+ugL4lJeHyV7T9TLEZ/X0wS2a1wieDe4fB9y5+qpkqizd/YN4FHclHT3aNpmxKmyfAEAth79TS1e/a+parxL+35e/ff9JUGim3CJReDLOaqg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(376014)(82310400026)(1800799024)(4143699003)(10067099003)(5023799004)(11063799006)(56012099006)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: kh8yKfrlhX2qCMqOGKuOTFHfjhRcNR/S/gpbJo9hVXIjzLNKArnvpEKE8qDjXTc9I84LaI4LbToHodeBlIhpJQ5fMHiz7UUZYwS6P9qlq2HM5sy04wXbTIKs6CtDj8q1AWr5w521o2BmH8Xt8aFsVzu+u3tzvj9IpYOnKq5HGW+YLgBlIjcJPYdJ7Ztg7cUuGol8ZiEQA6ubWNu09UioWAzkU3w5DueseCb3mEmQ8jWsJcWCSfb7E0bZOqup80oFBaycJyN+25fQhAhxAjdRADTJgBvE3aREMmRL4CzPerlsXHAs78XgxcuA0HEFp08C7kxA0W8UjfP44htbtVrPk5z/yNIOAhuFPJkKx4WpCHYk/bnfys4JIbdn5idI8ZamcnV2YPy1mMNhLzewwtGSogVNMOguo4g6KT9HuOiz4KOGK/cgNVrMzB/LVwly2by2 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 11:03:29.6919 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1df4e77b-4bec-4e05-8bdb-08df0ff44ff2 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000075F4.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7624 X-purgate-ID: tlsNG-c1860d/1789124617-D634587B-0F8DC02A/0/0 X-purgate-type: clean X-purgate-size: 3592 On 18-Aug-26 13:32, Mykola Kvach wrote: > is_espi() currently changes its result according to CONFIG_GICV3_ESPI > and asserts when an eSPI INTID is passed to a build without eSPI > support. This makes a range predicate carry configuration policy and > causes callers to depend on its hidden side effects. > > Make is_espi() report only whether an INTID is in the architectural > eSPI range. Gate eSPI handling explicitly at call sites and preserve > the debug checks on paths where an eSPI is invalid without compiled-in > support. > > Signed-off-by: Mykola Kvach > --- > Changes in v3: > - New preparatory cleanup requested during review. > --- > xen/arch/arm/gic.c | 5 ++++- > xen/arch/arm/include/asm/irq.h | 11 ----------- > xen/arch/arm/vgic.c | 4 ++-- > 3 files changed, 6 insertions(+), 14 deletions(-) > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index 078049e741..075e1d2c50 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -348,7 +348,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq) > /* Reading IRQ will ACK it */ > irq = gic_hw_ops->read_irq(); > > - if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(irq) ) > + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq)); > + > + if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || > + (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)) ) Take a look at LPIs that are also protected by CONFIG option. We don't ASSERT because they are gone in a release build. We want to BUG() for eSPIs same as for LPIs if we cannot continue with this condition (we haven't configured/enabled them, so it's impossible condition where something went wrong). Here you should just BUG(). > { > isb(); > do_IRQ(regs, irq, is_fiq); > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h > index 09788dbfeb..c29f3d04a3 100644 > --- a/xen/arch/arm/include/asm/irq.h > +++ b/xen/arch/arm/include/asm/irq.h > @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq) > > static inline bool is_espi(unsigned int irq) > { > -#ifdef CONFIG_GICV3_ESPI > return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID; > -#else > - /* > - * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is > - * disabled. Returning false allows the compiler to optimize the code > - * when the config is disabled, while the assert ensures that out-of-range > - * array resources are not accessed. > - */ > - ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID)); > - return false; > -#endif > } > > static inline unsigned int espi_intid_to_idx(unsigned int intid) > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > index e5aca17dcb..e14123a30a 100644 > --- a/xen/arch/arm/vgic.c > +++ b/xen/arch/arm/vgic.c > @@ -718,8 +718,9 @@ struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq) > unsigned int idx; > > ASSERT(irq >= NR_LOCAL_IRQS); > + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq)); > > - if ( is_espi(irq) ) > + if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq) ) Following the LPIs, irq_to_pending() returns NULL if they are not supported and we somehow ended up here. We should do the same here without using IS_ENABLED and ASSERT. Note though that for that, some call sites need to be enabled not to dereference NULL. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Sep 11 11:14:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 11:14:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416409.1645460 (Exim 4.92) (envelope-from ) id 1x4zCp-000542-Qe; Fri, 11 Sep 2026 11:14:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416409.1645460; Fri, 11 Sep 2026 11:14:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4zCp-00053v-Mq; Fri, 11 Sep 2026 11:14:07 +0000 Received: by outflank-mailman (input) for mailman id 1416409; Fri, 11 Sep 2026 11:14:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4zCo-00053p-50 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:14:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4zCn-005VpV-Hy for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:14:05 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3e26e-8faa-0a2a0a5109dd-0a2a4509e576-38 for ; Fri, 11 Sep 2026 13:14:05 +0200 Received: from [52.101.46.12] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3e27b-be1a-0a2a45090019-34652e0c2baf-4 for ; Fri, 11 Sep 2026 13:14:05 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SA1PR03MB6435.namprd03.prod.outlook.com (2603:10b6:806:1c2::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 11:14:00 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 11:14:00 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=f0fyzPXtQc7rXWByvpcdFAY5r7OPBeAVPo3r+nByDrAdBrlNFVZnuqgFosih8o6Iu2VZBpFT0Mn9uXNJ6SEQHzCJ8CCmLN/w358YLJQfC1rHb87YdlT2KTXVTe1WcXdyN2pfycXsTqP1DJY45qzl5iYuZUANt3VvHnNATrNBgFs7pWMgoCuodWBLzn+FlOmG8F2WPDAImAL9W/lbfHtQiRx9x07T4rTvvrrWJo08LI+DATTdIjT33mWmjJxBHbHHqXtiV4cTuaBQ5EBhRpJQVuWnCVjZfh9R7ztQ55jK8C1xv28ZItvzh4bRHjMohjljKec9SFftEeROGhfWKo+UBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yTOA312Mu0a3gMt/IzddjVv8a+YbDC1M4IugOsgTUbk=; b=R+Gptu/ulti0TSOwPfCiWt5u4fwtAlggP7n8hsQhBrhyLSgnZxElZB1dDsfMJveL2SM3oIr8SM55eyoIMS6J9q839x4rCXd//xV7fls3jMG4tRRnarJEK4SZk4ggr4WvCVpotYgxd2KL0DNC9gZseeyKEDsvTJiI/n+kD2LMOGYSPVIv3Fj0TSNNg9K7HpEzQNydO4/hGizs36I91hm9lcBRsqfdIfWa8emKD6DnUPd0XcyJc4FfjYP5MHl6/qiflx2gpNIeF/B+ovKq8L85WhFMYjyuRKDKqGCdgPI3P9ooDms+v1Od54OyEgtqZ5n7K8fN+Lw3wwao6YV+9VqAgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yTOA312Mu0a3gMt/IzddjVv8a+YbDC1M4IugOsgTUbk=; b=yLiQAFAXbBNb/zIPHnyKmdbOtnUa8ZcPJJtbmaALkLCs7TQ4kfmjB7VkUUvtcHfqm1cRQNaOyM+XkB17cgskZrZgW/E6Ii2s+EVC2jRHRRelWBQa4w6+DZ2wgMTGvYiO7v7YcwMK8emhvz+YQNO+BtdKS1+dRjD0kJnToG8AWxY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <9cdd2386-7331-49f0-a67e-da4592d4c1a9@citrix.com> Date: Fri, 11 Sep 2026 12:13:56 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] nestedsvm: Fix multi-byte IO port intercept check To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie References: <20260910163955.1005097-1-ross.lagerwall@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DUZPR01CA0298.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b7::15) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SA1PR03MB6435:EE_ X-MS-Office365-Filtering-Correlation-Id: 0d4bbe9b-8fd5-4dec-bb58-08df0ff5c79b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|4143699003|10067099003|22082099003|18002099003|5023799004|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: HOqUuGYXzZTJwNEwAfla8UwQ0OfAtbX2q7GwIY/WCv7ysLP9ZqdIrkwn4zRaii9jqW3ozuLh96A6e4iL3xJteec9YnsRLhMD73+8jB4AafNZKVZHaWOBW5548+67qSGvTbApmITA50cFhKbSOlDwknMiTx2LqyTxJ2+vDBVhMLiiehiT50QwTCo6DUuBCjUJDlxDQ2AfMy2TfF/3SlaM0CuNJiZHG8joTE/NhS+gNgZsRvVvgqL5Jl3avXtyJKlZ4/k/8pfzSj2e9OSTad1i8mlh78oTr0ko4sPJayAt3D1dzjXMDwKJyGtaP8tmKVMK8BHBQ6eO14Q4538n2UVAv9QR1yJBjgHGxMP2eAmwurhVzW1kUsQko55ZjlDN2fczDkuVMcBk01j2jVijmKf/EobRwFPz+WIWAaNQ+FwizOBqAjC+omG5N8fFyOS1A22NGesoS09USa0BBw2AwHEk8wzY2Bmbm2GFvK2Cn3Jdq2ylmDJYVwXZzxgKCvR+FBiBOP3w8Ue1uRNbwXFkGygtQKSXqDguRMJchZFzHs5zhJJhpNyGeJxN++M31dPrWfBomTMXXsvuCqt+xVqZohD7kgBItsUGCEgMjKycNW6BppNvD8iXe+gcmFfZHZdElIM2r6rvqi259HQm73ycHUrQWjTngTkYPzqb87K56bnMhRA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(4143699003)(10067099003)(22082099003)(18002099003)(5023799004)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Umo2RFpkTWFvZndCSVNtMFZzc1ZaMmdGWFlYV0VrdHpLS2RPais1bFFSRjI3?= =?utf-8?B?cmQ1STN5WGZwZTgvaFlrbXIwTXF6bStnU05VWXJLbWhSbVkvdjNPRmc1MGxl?= =?utf-8?B?YjdMVFRLZjFiemdaK0w3azZNMS9yc3BIMWZHdnFVMTBscHVBOFhZa2dScm9l?= =?utf-8?B?Qk9qTGRFdG12NTRqVytUQjVraHBkM0p0TjViN3k1NXFzc2tKMTBmOEtKT1hR?= =?utf-8?B?UVlJV3dLZlE4d1pCL1NCZXlkcC81NVpneTdRSmRKZWdBRkxYNDc3RzhhT0dk?= =?utf-8?B?NUpxTEsrT29BM3ZpdkJDOUxTS3Z3NUd5cURZelQzVFloZTB3RlIvQ29ML1lz?= =?utf-8?B?cGNCbmJrcFlHSi8wbUZSSDVOeGUyQi9uQlZGMFhBMmhPSHUwLytxWmhEcjVj?= =?utf-8?B?RklhU2tHWlh0R3czUDhhcWlhcjhMWGxuYmxQR2tDOGZ5WG1zQkVORldOQm1X?= =?utf-8?B?Y25IZVV5d0kxdGhvclBOWHNVQmlXdEdnV1lxcDlCVll5bStrd0dPL3l3cUNu?= =?utf-8?B?VVJnV2NDNlZpSUpZamxDWTNvV2xYbmNFamg2Sm1vYmdXbVNCdnRBQ1JtblpG?= =?utf-8?B?NWluUmh1b0R5QTRWVE9iQTFpK3dtM0RiV3ZiWm56c3ZNT1c4MnkybzlXN2w0?= =?utf-8?B?Wk5uRHl3WXZ0MkJlZTRLb3NpaERIMm5Nb21DelV2TlRWS0orR2ZWQmZDWXdv?= =?utf-8?B?U2o0Zm1qbUJVdGtsUVRBbUtPQjhVbnJiTXVpZEV4bGZxZHA0d1RESFFTYm9x?= =?utf-8?B?b2lPZS85U1ZUdEZxRlU1UDB5RURrRzNrR3ppV05BZ3JaYSs3eEduQWErM3dO?= =?utf-8?B?L1ZDN1lDNlByazR5NzRSWitvV2NjMGRkUjM3bEVyRFRIWFJXYm1WdVVlTlZP?= =?utf-8?B?UEMxR29pVlNCUHNKd3FDTVNEdk9FTmMzdlJyYmVaRjEwcmt5US9xNEFvaXlv?= =?utf-8?B?ZnlXZnpnOFZLS2xRSkdNSWpWNUhZWTJZM3gyejlpYjZvbDBJRnhJb1ZZSEJZ?= =?utf-8?B?NDB1SU4yTTIrMzVqQXNnYVdiYUxzZGN6SU5lZUdFcmd3UVJBK1R1SGQyUFF4?= =?utf-8?B?blk4Y25TcDJzOVQzMGlWZ2x2bnJWV0Z0WGxoV0VFcWErUjlUMzNQbXNPWjBL?= =?utf-8?B?M2Y4U09HWnNvbFNZTWpKUityZlBoblhuYWs1V3FlVU02VVl4MHh0R3pmM2JC?= =?utf-8?B?ODJiUmZDK2VaU050MFN4UWxJVHlXT00vY1kzY3lRbG9OTy9iRCs4WSsvcFlV?= =?utf-8?B?K0NJVXVMZmhFSUpSUy9ObVlpNVBGcFkxcXpvQ2hrSkN5WjVtVGhEdmZFMXBa?= =?utf-8?B?RVBoaHl5eWJVeVNRS09NSnFLU0Fmb0JKcGsxUHYzNzNYYWEwbndtUXUyUUFZ?= =?utf-8?B?dzBvNDIxNXNuRzZWMzVsNlEyNmNqUy9HVS9ENTNGaHhhWitjdGp2U2V5enQ2?= =?utf-8?B?QTRObWhmM3NIOXlsUHZtVXI2MS9mbEhIc3ZWd2RMY3pmRHBKRzRyREZOVjMx?= =?utf-8?B?YXhIVXlNMlA2bDFBUWsvQ0hRQTJHemVMZ0VUS0t6TDZHYTEyMHREbjdnVy81?= =?utf-8?B?NzM2U3lMdHhXRC9VZGxGQnhnWkY0MmM2ME5TQmhtTXU1Y1hUdmFmLzArVUd5?= =?utf-8?B?NkxTWUFSUjR1c2k5R3dXZWZFMTZ4K1hCLzAzZzlWMW5FUVUzdFh0TVUvR3JG?= =?utf-8?B?SjNEeGVmUVpNaWlnL21mdmNKWWpOYmlJdGR3OTFNMWozQWc3dE9ZU0N6NkpJ?= =?utf-8?B?dlJ4eGN4MXF6R1dwN2swMDQ4MEVuclVQU0dEaUV0UkxDcXluL1pFZ0hiV2Vl?= =?utf-8?B?a01tVjczTVJXK2MwUW44by9tcEIzaDVXR1ZKTEJqQ0pFU3JiamRkTFQ3RkM0?= =?utf-8?B?eFNZRHpzYlRmTzRORUhDUW9NRTN3S1FYdXlHaXlzbXo0K0wzd0g0Nk83Um9S?= =?utf-8?B?SlYyVTVQbVJzcDY2MTdRU3o2Sk5SdkFkUE42VENKVDYyY21NVkNRLzFQbU1J?= =?utf-8?B?OUhIQ2RkcFh4RkFGeHR3a3lVdSs5bkRwUTRhMXk4clRDdUdaWlNIWU5QUldM?= =?utf-8?B?R3RTelJrZytCSnlLTHp0NnFhTnNmREpBaUl1R0ViSkxXWVZFaDhET3F4QXJ0?= =?utf-8?B?cnZyQ3RTREJMSWxaaXY0U1daOUJiaGtULzE3cng0bG5zMEtHdGZWYjBXMTdq?= =?utf-8?B?eVRLaGQxYWdzSEh0OVF3WlJLem5SenFzZXhyZWFESWNuOFZHSnJJTEN3Q2p1?= =?utf-8?B?ZFBrc2JpbGJERGRGTmlJNmxMU3BGYXdGOUxHaHlJT0wwWitpZ0UxQytzbnkv?= =?utf-8?B?S1htV3FPZmFuTWplOHNGa1RmNllwWnRtMS9nV3ptalR0RzdUbjlRU1BwN0Jt?= =?utf-8?Q?NgiBoKEbBkGi6fRk=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d4bbe9b-8fd5-4dec-bb58-08df0ff5c79b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 11:14:00.1698 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VHUY1BPGMJUrIOiKwV9WaW8Zf0UJ+JXI4JQwgfUT6+ccAP+oiyq/1MhNuFQGQhXPq2AG6ffPQRsyTPkTbyVxexJR+8r+U+2shvrooYbMNOk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB6435 X-purgate-ID: tlsNG-bad1c0/1789125245-3BED6034-E9294ECB/0/0 X-purgate-type: clean X-purgate-size: 2514 On 9/11/26 11:06 AM, Andrew Cooper wrote: > On 10/09/2026 5:39 pm, Ross Lagerwall wrote: >> For multi-byte IO port accesses, the APM says that SVM should intercept >> if any of the corresponding permission bits are set. However, the code >> has this backwards and only intercepts if all the permission bits are >> set. > > By any chance is this for the root partition, with 0xcf9 permitted but > 0xcf8,a,b intercepted? Yes, for the root partition. It intercepts 0xcf8,c,d,e,f and permits 0xcf9,a,b. >> >> This affects Hyper-V since it does not generally set all the permission >> bits of the multi-byte ports it allows its root partition to access. >> This results in an L2 root partition that cannot do PCI config space >> accesses and therefore cannot access its NVMe disk to continue booting. >> >> Signed-off-by: Ross Lagerwall >> --- >> xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c >> index 5adb1bd72c4d..249fde43b5be 100644 >> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >> @@ -852,7 +852,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t iopm_pa, uint64_t exitinfo1) >> for ( io_bitmap = hvm_map_guest_frame_ro(gfn, 0); ; ) >> { >> enabled = io_bitmap && test_bit(port, io_bitmap); >> - if ( !enabled || !--size ) >> + if ( enabled || !--size ) >> break; >> if ( unlikely(++port == 8 * PAGE_SIZE) ) >> { > > While this does fix a bug, I think the behaviour is still unsafe. > > For starters, 'enabled' is a terrible name and is probably a major > factor in getting this wrong. It should be 'intercepted'. > > hvm_map_guest_frame_ro() can return NULL for several reasons[1], > including ballooned out frames/etc. It is not by accident that a set > bit means intercept; it's for the same reason that the byte sequence FF > FF is #UD (with the PUSH that should have been in that position moving > elsewhere in the opcode table), and that's because ~0 is the return > value for "nothing here on the memory bus". > > Either way, if io_bitmap is NULL, the port should be intercepted rather > than access being permitted, so the other prior line needs to be of the > form: > > intercepted = !io_bitmap || test_bit(port, io_bitmap); > OK, I'll send an updated patch. Ross From xen-devel-bounces@lists.xenproject.org Fri Sep 11 11:20:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 11:20:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416423.1645468 (Exim 4.92) (envelope-from ) id 1x4zIV-0005vY-C7; Fri, 11 Sep 2026 11:19:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416423.1645468; Fri, 11 Sep 2026 11:19:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4zIV-0005vP-8R; Fri, 11 Sep 2026 11:19:59 +0000 Received: by outflank-mailman (input) for mailman id 1416423; Fri, 11 Sep 2026 11:19:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4zIT-0005vJ-GV for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:19:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4zIS-005XFo-Bi for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:19:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3e3d0-8faa-0a2a0a5109dd-0a2a45068594-22 for ; Fri, 11 Sep 2026 13:19:56 +0200 Received: from [209.85.208.51] (helo=mail-ed1-f51.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3e3dc-195a-0a2a45060019-d155d033dca1-3 for ; Fri, 11 Sep 2026 13:19:56 +0200 Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-6a9bd4db6ccso662629a12.0 for ; Fri, 11 Sep 2026 04:19:56 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a9b5912644sm669176a12.11.2026.09.11.04.19.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 04:19:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789125596; x=1789730396; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zR5Jyl9rMPCNYPTyQOMySxE7qlnr2h5LJyFINO8ElQM=; b=BfSByFX/1yS4J2ZBWozIXoRgzoti46Y3TXutj10GNsRWJVJVtFMwPl2fG/Ib48iSQB iusJHouvWqN96xlPA8hipw5512zyEC/3EIxZhxYKRHHKvT3cypvb5uBwfE8YSO/tTxHP yO1Eavp0wsPOC7gCB48ugRr1PRD2VtCaIjaNQLlnL7uaMXJDkNO5zTfSr0wEF+GOy3Bq 2KkpKJa/YGHV4h7bCb2VfEXMkpCDnU9X6Z/jprHoWJAfXVN8cm2QkI9wdZD6vMrXCynK bkZjCanBh4bM+z5s9z83AjZVe+FhBZowYxG4pSVbKmnh9UE3vf3txyTNcEciEZERLViR qvYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789125596; x=1789730396; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=zR5Jyl9rMPCNYPTyQOMySxE7qlnr2h5LJyFINO8ElQM=; b=n2+c3o4OIXommHh9bxltBW5jRLQhmEhekYQL7zXFqXBYQyxWl1MD1N3GX/ybI7KN6J mPoUxTdbhj7aLUy7341FBSovHrwUwECTrrNtSH87pHEPWzOaFBn2b5rbWhvTbLqzU9Kk PZArAGSGKs/bg14jZSJ1VW4DfKcxQT55KkQp6H08l8vFtNjwJE6IgNRXXF0gp0BlhRup dmnfKqVc/95f/tmjofTg5/yRokygr0ORHzrwOhT1JHb5RP6nuqvPLTXmnELkqx9L9/E2 Sz5OGjlkkWTQy9t5OOejXBT1myunvXqBpWcCZuHaT9ZORQt3eSAABXoRkxtBbDAbrhSM Ee3g== X-Forwarded-Encrypted: i=1; AKwUvBxFR7Wu4ZLwUWqFiIDPfeCcQMQr3k6BrNxtTNed+3CW7cWa7lQ2eHPSEt801QGfc5B2DB1oFaMx2Ug=@lists.xenproject.org X-Gm-Message-State: AFuF++mMqJVwvKzcqjpIQQBrQB812gsvD+nhvzS6/K1OYA/IRCNF35E0 mp619XtsrXg4DCyUownhr8J/6l2ZcNE84bc6kx5sp1XlSbxNpwT87S9O X-Gm-Gg: AYBFou3jucLQIfyFB8NkpH4X8+Sqt6efbkuRXBa/JrTLJdLOF3HUWqRsnLYZdawDHqO V6R9Vj68XqA942hG3C/1Uc2Lv8pJ3XEdLWSwZ//vOY7XfocTfVm6qAP/YpilkgikklQT8J7Hc9+ xirkE39AGKKve6hmoJ5zXdlvCyWTVTB2QU2FwqQoOsvLK5taWwFfMY2zUVewivwPwBgl/vF6q/t 2PhqXo2AXke0DgAu8kfHAEGhdPlTLWaOSthoi9CLtTiwqXFUK3s7eP/nbB9mtWzdG82OrMg5ZX2 qZIgtQnAl/ZdTe3XdBqBjJc/w5fxQY+I0rfGuzL2SS5u17D/qw7nBWHWYAn9kPglMFgsuvJE8/Y BMlr10RjFbSaF662xL3MzTPtsjQicmIWo4XmV67cpjEzeJQx3bqsaQ3zxpMus1PmW+0t3W61ZlR kfwtmaIz6hrqGDghVc6bRTc+391fXOC1u0FnNx2RJiCHIjkbeLNAyXHp6UsGH0CC/ZB1D60Fjeo vY3H0+XT7ZxhjqJhD2BrSwtwxZBNYiN X-Received: by 2002:a05:6402:46d0:b0:6a9:ab6a:640f with SMTP id 4fb4d7f45d1cf-6a9b56b92bbmr1536081a12.37.1789125595578; Fri, 11 Sep 2026 04:19:55 -0700 (PDT) Message-ID: <168bd9cf-b97b-4e3d-83ab-836b25dd361e@gmail.com> Date: Fri, 11 Sep 2026 13:19:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 15/39] xen/riscv: add IMSIC vCPU context switch handlers To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <867af892784c295296cdf63e0371fa1b7ed7a1e7.1787838835.git.oleksii.kurochko@gmail.com> <9651f59e-b101-4c70-93ae-07f668e85c38@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <9651f59e-b101-4c70-93ae-07f668e85c38@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789125596-FCC0777B-E1320251/10/73395122804 X-purgate-type: spam X-purgate-size: 1187 On 9/10/26 4:57 PM, Jan Beulich wrote: > On 27.08.2026 17:20, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/vaplic.c >> +++ b/xen/arch/riscv/vaplic.c >> @@ -422,6 +422,13 @@ static const struct mmio_handler_ops vaplic_mmio_ops = { >> static const struct vintc_ops vintc_ops = { >> .vcpu_init = vcpu_imsic_init, >> .vcpu_deinit = vcpu_imsic_deinit, >> + /* >> + * MSI delivery is the only supported mode: aplic_init() panics on an >> + * APLIC without an "msi-parent", so the vAPLIC state to save and restore >> + * is always the IMSIC one. >> + */ >> + .ctxt_switch_from = imsic_ctxt_switch_from, >> + .ctxt_switch_to = imsic_ctxt_switch_to, >> }; > > As previously expressed, I'm not happy with comments like this. aplic_init() > isn't related to vAPLIC behavior. We're doing virtualization, so at least > conceptually host and guest behavior want properly separating. Then it may > still be that for the time being only a certain subset of possibilities is > supported. I will drop the part "aplic_init() panics on an APLIC without an "msi-parent". It is really not very relevant here. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 11:47:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 11:47:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416454.1645478 (Exim 4.92) (envelope-from ) id 1x4zjL-00020O-Gk; Fri, 11 Sep 2026 11:47:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416454.1645478; Fri, 11 Sep 2026 11:47:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x4zjL-00020H-DO; Fri, 11 Sep 2026 11:47:43 +0000 Received: by outflank-mailman (input) for mailman id 1416454; Fri, 11 Sep 2026 11:47:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x4zjJ-0001z2-8A for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 11:47:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x4zjI-001AJ3-LF for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:47:40 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ea59-e002-0a2a0a5209dd-0a2a4503e7f2-16 for ; Fri, 11 Sep 2026 13:47:40 +0200 Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ea5c-fae8-0a2a45030019-d155da2ad475-3 for ; Fri, 11 Sep 2026 13:47:40 +0200 Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c250f28f1cdso154015066b.0 for ; Fri, 11 Sep 2026 04:47:40 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c29660234f2sm70763266b.12.2026.09.11.04.47.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 04:47:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789127260; x=1789732060; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=8dT0tbCdZCM3R8vBdrpD5ah/VElX8goA0nOHkmgBr1s=; b=pgGvbPezW/zWrmxcPmPNczcLEgz2WaYomGdKjPrubzOLo500vDelVllw49gAfxJdWl /wUZhAIboKcJBdCwljJ1pJ0DGzavQxr50pDSUPshJyWsmDJ2uuPWgn/346WVG++0T8oL sPcXlv0ZN13t2JkjY8FuL/qB1GUgt9MG+mvsI/xvcU7/r6UJJVgTV1ADIYPZvNF0nY/D ruge+NIoo4FFukdURpul7jysGxm6PuWuawYOi20RafYR78w3rllCh6/QQ2Kw0Zsr1LFU xYLmZCBHvpw2YC3JF/ale6sw4IXWzZMjoqQvC3We/VgbegGg9WUCgn6selgWe56VTNdD 0HHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789127260; x=1789732060; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=8dT0tbCdZCM3R8vBdrpD5ah/VElX8goA0nOHkmgBr1s=; b=U7/z8BoC3cbSmF1JFZuSidHpDMxYYkK7iJvBRogacmKij1agKIKh74DYjbYWlCxwTm Dg6VgoGwSEjNJR2EpiMqJYR8yHwQq6QngTIOH5my+iHwaa0/3WjGbu2h0uaBuNOX71cQ YlODMOCHN/swFeFdN2oVdQ3Mtyv1LlrgnX/jmp/BC3C4Js0UUaOchrfwVRmRK8VvcQBB +wvZh0+Hds2qe6nxYeIadFolq9yprbCHONlvZZs7oiPE2+HG4sKDU0ayyMyL1ibI7FgQ jPgtxFZkTsdd4IVbcTFwo/nfk3C89oArMBMjQn1odZAaBF36V51xWP+qsQQGjEvFo8MD iRPw== X-Forwarded-Encrypted: i=1; AKwUvBxeVC6Wh+vEvVPwdCDLxWr3imnvAqzzq3z+KCbHCZYG2CuNAkPGZ7WB86tFpCM0502PJH6LbX/fzQM=@lists.xenproject.org X-Gm-Message-State: AFuF++m77jTpGa67dI6b0Qr4eWCr0PCLOORTmVgBsirD9pg1TX+oU7cV uml85Wh9rAJWh26XczkKWGX5MyTgkBfYumVdP6ZUGWOZtBBmfixD8v5Z X-Gm-Gg: AYBFou1lSd3Bn9THBwkN8tqutG/zoEcgd5xFzrrr28DiOv5Z3tHv8iT7NEWvt3uBtU1 E2guYyGm9gWLMtIuyllGyMk9IRFCna9HeD7bL83xxn/1uwtMLnALXp8/OYq43VYUID+9PokOFJY 2hM8/ibhV6W0GiJmMWjIigVmDCDbvgfl/N8BYrfS9vCUumLR6a0MQ0FbIb70s1PrnjPxgKi5hMM maCTc0fIeolEzlT5koM4ibrenFf6Lgnny0XU1EJexc5S44J/v76VZTlqxhjxRDERtLreeGdaHGM 3Y7FQcBlWPn4WuPyoAv4KckxJjwoFpZUlVQy1RTjnc5xHj3DhYvc7NTO4g3f4V2i1I40t6vuXLK dBydvCTqx5OqxMPo0eRDsmQtsbf6SH8pHfREUd0Z0CDHiZhfKqCmt1SKM7RFD/gM8Sq25nWzSPS 2jlcTkj1ewWmpYy+mlfnEuxM2tRlTCY+S6zUdjUxQI7aPp9BxNgYgpccvcu40yXRuHrhpSBQ37O mmY4HAL/OXB6D6LycxzkgvagPp9XHjCLg== X-Received: by 2002:a17:907:a089:b0:c29:6291:e37c with SMTP id a640c23a62f3a-c29666901b5mr152931966b.24.1789127259615; Fri, 11 Sep 2026 04:47:39 -0700 (PDT) Message-ID: Date: Fri, 11 Sep 2026 13:47:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 18/39] xen/riscv: add guest page fault handling stub To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.com> <35aecc68-d16e-4350-9aca-101de2b21c1f@suse.com> <19aae90d-bd5b-4637-828c-bb5164ba4191@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789127260-774F44E9-8E162849/10/73395122804 X-purgate-type: spam X-purgate-size: 7773 On 9/10/26 8:38 AM, Jan Beulich wrote: > On 09.09.2026 17:09, Oleksii Kurochko wrote: >> On 9/8/26 4:10 PM, Jan Beulich wrote: >>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>> --- /dev/null >>>> +++ b/xen/arch/riscv/emulate.c >>>> @@ -0,0 +1,179 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >>>> + >>>> +/* >>>> + * RISC-V instruction emulation for trapped guest accesses >>>> + */ >>>> + >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +/* >>>> + * The hardware-reported details of a guest page fault, gathered once by >>>> + * handle_guest_page_fault() and passed down to the emulation of the faulted >>>> + * access. >>>> + */ >>>> +struct guest_fault { >>>> + /* The guest register state as saved on entry to do_trap(). */ >>>> + struct cpu_user_regs *regs; >>> >>> If the comment was true, this could be pointer-to-const. >> >> I think it can't be pointer-to-const as emulate_load/store functions >> wants to change PC register after MMIO access emulation is finished to >> not trap again. > > Of course, hence how I started the sentence. > >>>> + /* scause: a fetch, a load or a store/AMO guest page fault. */ >>>> + unsigned long cause; >>>> + /* >>>> + * htinst: the trapped instruction in its transformed form, or one of the >>>> + * special values (zero, or a pseudoinstruction). >>>> + */ >>>> + unsigned long htinst; >>>> + /* htval: as written by hardware; see resolve_faulting_gpa(). */ >>>> + unsigned long htval; >>>> + /* stval: the guest virtual address of the faulting access. */ >>>> + unsigned long stval; >>>> + /* The faulting guest physical address, filled by resolve_faulting_gpa(). */ >>>> + paddr_t gpa; >>>> +}; >>>> + >>>> +/* >>>> + * Is @htinst one of the pseudoinstructions reported for a guest page fault >>>> + * taken on an implicit memory access done for VS-stage address translation? >>>> + * >>>> + * All four values are recognized regardless of the hypervisor's XLEN: the >>>> + * width they encode is that of a VS-stage PTE, i.e. it follows the guest's >>>> + * paging mode (4 bytes for Sv32, 8 otherwise). On RV32 the 64-bit forms >>>> + * simply never occur. >>>> + */ >>>> +static bool htinst_is_pseudo(unsigned long htinst) >>>> +{ >>>> + switch ( htinst ) >>>> + { >>>> + case INSN_PSEUDO_VS_LOAD32: >>>> + case INSN_PSEUDO_VS_STORE32: >>>> + case INSN_PSEUDO_VS_LOAD64: >>>> + case INSN_PSEUDO_VS_STORE64: >>>> + return true; >>>> + >>>> + default: >>>> + return false; >>>> + } >>>> +} >>> >>> This feels fragile. New pseudo-insns can appear at any time. If the value as >>> a whole is non-zero, aiui the low two bits being zero indicate a pseudo-insn. >>> In which case enumerating pseudo-insns we are currently aware of isn't >>> necessary. >> >> I will write it simpler then: >> >> /* >> * Is @htinst one of the special pseudoinstruction values, reported for >> a guest >> * page fault taken on an implicit memory access done for VS-stage address >> * translation? >> * >> * It is enough to check only bits[1:0] as according to the spec: >> * >> * The value is one of the special pseudoinstructions defined later, all of >> * which have bits 1:0 equal to 00. >> */ >> static bool htinst_is_pseudo(unsigned long htinst) >> { >> return htinst && ((htinst & 3) == 0); >> } > > And preferably > > return htinst && !(htinst & 3); > > to be self-consistent. > Good point. I will apply your suggestion. >>>> + /* >>>> + * A guest-page fault may arise due to an implicit memory access during >>>> + * first-stage (VS-stage) address translation, in which case a guest >>>> + * physical address written to htval is that of the implicit memory >>>> + * access that faulted - for example, the address of a VS-level page >>>> + * table entry that could not be read. (The guest physical address >>>> + * corresponding to the original virtual address is unknown when >>>> + * VS-stage translation fails to complete) >>>> + * >>>> + * In such cases htinst reports one of the pseudoinstructions recognized >>>> + * by htinst_is_pseudo(), and the fault requires separate handling (since >>>> + * G-stage translation failed on an unpopulated/unmapped guest physical >>>> + * address during a hardware page-table walk). To match bare hardware >>>> + * behavior, we must inject an access fault of the ORIGINAL access type >>>> + * (Instruction, Load, or Store/AMO) that initiated the address >>>> + * translation. >>>> + */ >>>> + if ( htinst_is_pseudo(gf.htinst) ) >>>> + { >>>> + inject_access_fault(&gf); >>>> + >>>> + return; >>>> + } >>> >>> I.e. you imply that guests won't put their page tables in MMIO? That's >>> fragile imo; I have seen OSes to use video frame buffers for all kinds >>> of (transient) purposes, for example. >> >> I think it is okay for now and if it will a real use case then an update >> of this code will be needed. > > May I then ask that you leave a remark (maybe even fixme) to this effect? Sure, I will then add the following to the comment above if (): * FIXME: This assumes that guest page tables never reside in an emulated * MMIO region, i.e. that an implicit access faulting at G-stage always * targets an unpopulated GPA. Guests may (even transiently) place page * tables in MMIO-backed memory, e.g. a video frame buffer. Supporting * that would require walking the VS-stage page tables in software, * accessing the PTEs (including A/D updates) through the MMIO handlers, * and then emulating the original access, instead of injecting a fault. > >>>> + resolve_faulting_gpa(&gf); >>> >>> Since the function is only a stub right now - how is one to tell whether >>> this indeed can never fail? >> >> It can't be tell. But what is wrong if it could fail? (Actually with >> current implementation introduced in later patches you can find it can >> fail if a necessary extension or software page walk isn't introduced). > > Well, quite obviously if it can fail, its return value would need checking > here. > That what I thought about after I sent my e-mail as a possible option. I will update the prototype to: +static int resolve_faulting_gpa(struct guest_fault *gf) { - BUG_ON("unimplemented"); + return -EOPNOTSUPP; } And handle an error code in the following way: @@ -136,7 +144,8 @@ void handle_guest_page_fault(struct cpu_user_regs *regs, unsigned long cause ) return; } - resolve_faulting_gpa(&gf); + if ( rc = resolve_faulting_gpa(&gf) ) + goto out; switch ( cause ) { @@ -163,6 +172,7 @@ void handle_guest_page_fault(struct cpu_user_regs *regs, unsigned long cause ) break; } + out: if ( rc ) domain_crash(current->domain, and then in the next patch "[PATCH v2 21/39] xen/riscv: resolve the faulting guest physical address" I will do "return -EOPNOTSUPP" instead of panic(): - panic("Shtvala isn't supported by h/w; s/w VS-stage walk required\n"); ++ { ++ printk_once(XENLOG_WARNING ++ "Shtvala isn't supported by h/w; s/w VS-stage walk required\n"); ++ return -EOPNOTSUPP; ++ } ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:25:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:25:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416500.1645486 (Exim 4.92) (envelope-from ) id 1x50K1-0007uS-9m; Fri, 11 Sep 2026 12:25:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416500.1645486; Fri, 11 Sep 2026 12:25:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50K1-0007uL-6w; Fri, 11 Sep 2026 12:25:37 +0000 Received: by outflank-mailman (input) for mailman id 1416500; Fri, 11 Sep 2026 12:25:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50K0-0007uF-5d for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:25:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50Jz-00DsgG-3s for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:25:35 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f33e-e002-0a2a0a5209dd-0a2a450b93c2-2 for ; Fri, 11 Sep 2026 14:25:35 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f33e-b7e8-0a2a450b0019-4a7de14caaef-3 for ; Fri, 11 Sep 2026 14:25:35 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-48583cc7ab1so356670f8f.2 for ; Fri, 11 Sep 2026 05:25:35 -0700 (PDT) Received: from [192.168.1.109] ([85.107.101.132]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb330bdcsm5862446f8f.13.2026.09.11.05.25.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 05:25:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789129534; x=1789734334; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zWLxSm3T5VZKe0mn6yyV9o28nC73to4Ixrh3jTz68nw=; b=hgaOq9he9GsL3FUdmk4h8UQsKBGgK2508xlHM6JbVHNlRr7fwFZbElaPJ9xbTPcee1 zP7nc1vC9cLr2zPqfy3/OaBFPLRL4KNmoAhGcfwZFbkVMhjTkllxZJchGJuW9mebG3XB eGppVr9LTNPm0lrJ6CMuUg7tm8w4g8OQnxzpkbz8M0CcnxwjwaFlai+el8J6aXXEHrDq uLDhpeyBw0u0dH4LbGpZu870T7gHCXNOk3UYzKt+Ck2NM3HPsALk1UT2/Rm0rGn9sQiJ pL2eACvw2gFCTkKEhXH506At8zTYBlCOOmU2o92svVaCgdrhWSDFKXMGYwX2qysbOvHq 0yvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789129534; x=1789734334; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=zWLxSm3T5VZKe0mn6yyV9o28nC73to4Ixrh3jTz68nw=; b=dsGJjflBSnvC2Q1rTecTSXYVaC3QmDv/WPsC8Zk1mWX7Vu0uClqsqFHXd90p4Y+4Ud Juf9q/aZ/T/Zc0hMZ/Z4ENYb6wcqp9KeNDo8Ao8SQ5Ux2yKD4e2Vkz6TDpE/VQMXgZOP 5N72yRUXacsF9RA99wgtmw4m6ggygeeZ8GGmjFbkPaTGhiJMrArt1lxCmQ+9dtcyjPyV RRmF3q9Mf41R0f51744rW+myUYd1RQ0I+KYos/ujXDW5VB/mGRXEEk8QSC/pkrhuheiT A0MzZXczeLA+WiMnaGQvjd4UZtEKCviGWxC5dyr0fez6X8gi9WhUZGFP+dO2auWGDG6J P9og== X-Gm-Message-State: AFuF++kORme+7PxxdC5Qv9FPRv6PW27QYuW6a2Kx5J/zPHW5SpZM5kYn mHxw5kc6x+gGVKP6i7rYa2y/3QU58ZIHCrxYLKrbDRb6vYt9MLm/r8LGihhK9w== X-Gm-Gg: AYBFou1gIEFx5AP1f0XLtU2AwAfCYgqWekQB1Ev0J0D/frlu0dBOagMwZtk4bEHPtpl AOwysbCNnwvP3GBlS+tP3gkPZ9pQNz5LmvzSf/gfeHmVqSXTbVOMnRNk7mSI+8g8r79MDNZ5XWN Tdy1HOaeLe+/adRTDjjEKrK8la+SrGUOjw1QJNHbJ2ZUFVspEiJc2x6qKylVMcyHoE+m+1vbbX/ wfrfGV7XTVbe/RF94tWZq6ibNPgAAzcA3PNYJuw3M9isKuqeGlycAXOvh57DPEpNRG93RUi7mQs Ee28zanI54O1f4kyog/sWD5vpTocGG7SfhET1s4JOeXjIwexto0y1+vvs5JB+F6ZuEd8UGIAIqR LfQIr6YHKVcVLFs6ONEzNbNw59t18sQ+IijKj0tbj8nrFG2g7cd7LFukK4WczzOsu0VbBYI7mfn 6kVq5XiYBqn3UB8bt/eKZTCx6wcGB8N8WmOC2X06k2TfTAwjPJLP6lmhafHgPGezYQtK9aI2Fgi d/Nm/c= X-Received: by 2002:adf:f743:0:b0:486:e798:9c35 with SMTP id ffacd0b85a97d-486eb327c21mr3224249f8f.40.1789129534262; Fri, 11 Sep 2026 05:25:34 -0700 (PDT) Message-ID: <7fb66cfd-b1b0-4f58-b35c-229aa679f737@gmail.com> Date: Fri, 11 Sep 2026 15:25:27 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] xen/sched: rtds: add per-cpupool admission control To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <20260826045720.5779-1-frn1furkan10@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789129535-A84CB9EA-B0CB9D7E/0/0 X-purgate-type: clean X-purgate-size: 2440 On 8/26/26 07:57, Furkan Caliskan wrote: > RTDS currently has no admission control: nothing stops the sum of > all admitted units' (budget/period) reservations in a cpupool from > exceeding what its pCPUs can actually provide. Once that happens, > the global-EDF deadline guarantees the scheduler is built around no > longer hold for any unit sharing that pool. > > This series adds admission control to prevent that, tracks and > report utilization, and makes the check toggleable per cpupool so > an operator can disable it if they intentionally want to overcommit. > > Patch 1 introduces the core mechanism: a running utilization total > per cpupool, a fixed-point representation of a unit's (budget/period), > and a capacity check enforced in rt_alloc_udata()/rt_free_udata() - > the lifecycle hooks that catch every new unit's default reservation. > > Patch 2 extends the same check to domctl, so growing an existing > reservation via xl sched-rtds is checked too. > > Patch 3 reports a cpupool's admitted utilization agains its capacity > via the 'r' debug key. > > Patch 4 makes admission control itself toggleable per cpupool > (enabled by default) via sysctl. > > Patch 5 wires that toggle through libxl and adds -s/-a to > xl sched-rtds, and documents it. > > Furkan Caliskan (5): > xen/sched: rtds: add global-EDF utilization admission control > xen/sched: rtds: enforce admission control in xl sched-rtds > xen/sched: rtds: report utilization and cap via debug key > xen/sched: rtds: make admission control cpupool-wide toggleable > tools: expose admission control toggle via xl sched-rtds > > docs/man/xl.1.pod.in | 20 +++ > tools/golang/xenlight/helpers.gen.go | 23 +++ > tools/golang/xenlight/types.gen.go | 4 + > tools/include/libxl.h | 4 + > tools/include/xenctrl.h | 6 + > tools/libs/ctrl/xc_rt.c | 40 ++++++ > tools/libs/light/libxl_sched.c | 46 ++++++ > tools/libs/light/libxl_types.idl | 5 + > tools/xl/xl_cmdtable.c | 8 +- > tools/xl/xl_sched.c | 103 +++++++++++++- > xen/common/sched/rt.c | 205 ++++++++++++++++++++++++++- > xen/include/public/sysctl.h | 5 + > 12 files changed, 463 insertions(+), 6 deletions(-) > Hi Juergen, Can I get a review on this series please? Thanks, Furkan From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:32:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:32:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416519.1645495 (Exim 4.92) (envelope-from ) id 1x50QL-0001Ci-Td; Fri, 11 Sep 2026 12:32:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416519.1645495; Fri, 11 Sep 2026 12:32:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50QL-0001Cb-R1; Fri, 11 Sep 2026 12:32:09 +0000 Received: by outflank-mailman (input) for mailman id 1416519; Fri, 11 Sep 2026 12:32:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50QJ-0001CS-9k for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:32:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50QI-002F7V-MU; Fri, 11 Sep 2026 14:32:06 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f4bf-bab6-0a2a0a5309dd-0a2a450ae56c-12 for ; Fri, 11 Sep 2026 14:32:06 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f4c5-f2d2-0a2a450a0019-5a9b3222d988-3 for ; Fri, 11 Sep 2026 14:32:05 +0200 Received: from [2001:8b0:10b:5:94db:d427:30c1:83c2] (helo=u09cd745991455d.ant.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1x50QG-0000000BrMU-25fU; Fri, 11 Sep 2026 12:32:04 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:in-reply-to:Date:Cc:To:From:Subject:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:in-reply-to: Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:References; bh=9gjbOMgM2VQv4pWcQhX0K3pqeqKcNOiewxPPbmSNxgU=; b=BzuXogbO8kj7y/3crnzjxQjrqX RB2HoYS98y8IDyte5PGSUnbxqZSjFXyfvy1f/DUjSQ6mSYCgCDhdKe/10YkcLF5wMJQuRYllBWRMh PFSJ3HJPuaKRIJd8gTcAhejv8zh5uRyXI81PDXNZlJyQcnigWge/3BjrWeruN3uSiA05J/Qsdy8fw yn5yF6Ao4H/oppEijE4boGcw8GuNStHXmlNx1zyPjmGHKEKbIGWHAsXLtkpWEGYeDtOUo2wKS3BY0 fb8B51F+xOtmZe+Ypl7wUqW6+Z5vKfgWsrw998j2elwEj5xvbkSUo47H9HZFMoTBBt2B6zRpmPFXn SIPpAjtw==; Message-ID: <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> Subject: Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc From: David Woodhouse To: mark.syms@citrix.com Cc: qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org, edgar.iglesias@gmail.com Date: Fri, 11 Sep 2026 13:31:35 +0100 in-reply-to: <178912129220.24041.799369954881004447@citrix.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-9qhn9XId8SiCnb9ViCBV" User-Agent: Evolution 3.60.3-0ubuntu1~ppa10~24.04 MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-purgate-ID: tlsNG-4011c0/1789129926-538D5CFC-D0C51199/0/0 X-purgate-type: clean X-purgate-size: 14754 --=-9qhn9XId8SiCnb9ViCBV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Help! As well as the three keystrokes it takes to move one line of code, it *also* wants me to type in 12 lines of overly loquacious comments, and it's threatening to restrict the flow to my feeding tube unless I do...) Claude here (dwmw2's AI assistant; he'll follow up himself and any patch will be his own work =E2=80=94 more on that below). I've done the gruntwork of confirming your diagnosis, re-testing the 2023 crash that motivated commit 240cc11369fc, and verifying that the fix shape you describe (defer only the InitWait transition until after the implementation's realize method) addresses both without reintroducing either. Summary of what was established: 1. Your diagnosis is correct, and it's not only blkfront. All three XenDeviceClass realize implementations publish nodes after the InitWait transition: xen-block's feature nodes as you describe, and xen-net's 'feature-rx-copy' =E2=80=94 which Linux netfront also reads wi= th xenbus_read_unsigned() from the InitWait watch, and hard-fails with -ENODEV ("backend does not support copying receive path") if it finds it absent. So the same race can make a hot-plugged NIC fail to come up entirely. (On real Xen, that is: under KVM/Xen emulation xen-net's realize never yields to the main loop, so the frontend cannot observe InitWait until all nodes exist anyway.) The console frontend (hvc_xen) reads nothing from the backend area during setup, so it is unexposed. Fixing this in xen-bus.c rather than in xen-block is therefore the right altitude. 2. The 2023 crash reproduces trivially if realize is moved back above the node population (under KVM/Xen emulation, a bare launch with a xen-disk device segfaults immediately in xen_device_backend_scanf(), from a watch event processed via blkconf_geometry()'s aio_poll() while realize is still running =E2=80=94 the exact backtrace from the original report). That confirms the constraint you identified: node population must stay before realize. 3. None of the three realize implementations (block, net, console) reads the backend state, and a watch event processed during realize with the InitWait write deferred finds the frontend in Initialising and the backend state node absent =E2=80=94 both handled gracefully: the 'Unknown' state matches the initial value so set_state() is a no-op, and the xen_bus_cleanup() path additionally requires !online, but 'online' has already been set to 1 at that point. This was the part you said you'd expect us to want to verify; it holds. 4. With a Linux guest under KVM/Xen emulation (where xenstore is in-process and traceable), the xenstore trace shows the race directly. Hot-plugging a xen-disk on current master: backend state -> InitWait xen_block_realize starts <- features not yet written guest reads .../max-ring-page-order <- inside the realize window guest writes ring-ref (singular) <- order-0 ring and with the InitWait transition deferred: xen_block_realize starts and finishes backend state -> InitWait guest reads .../max-ring-page-order <- after all backend writes The guest's read is provably ordered after the backend's writes, because the InitWait event that prompted the read is now the last node written. As for how wide the window is: with timestamped tracing, the span from the InitWait write to the completion of xen_block_realize() (which is exactly the stock race window) measures ~1.6ms for a 64MB raw image on local NVMe. It is dominated by real disk reads in blkconf_geometry(), so it scales with storage latency =E2=80=94 again= st a frontend that reacts to InitWait in microseconds, which is consistent with your 20-out-of-20. (One caveat for anyone trying to reproduce your exact 8x symptom under KVM/Xen emulation rather than real Xen: the emulated grant table backend doesn't advertise XEN_GNTTAB_OP_FEATURE_MAP_MULTIPLE, so qemu never offers max-ring-page-order there at all and blkfront takes an order-0 ring on the boot path too. The interleaving above is still demonstrable, but the ring-size delta is only visible on real Xen. Also note Linux's xen_blkif_max_ring_order defaults to 0; multipage rings need xen_blkfront.max_ring_page_order=3DN on the guest side, which presumably XenServer guests carry.) On the question of the patch itself: dwmw2 will be writing it from scratch with his own meat fingers, using the analysis above. He'll be reverting my version of it from his tree first. So the code that gets posted will be human-authored in the DCO sense, with this thread as the design record; whether and how the project wants to account for AI-assisted *analysis* (yours and mine both) is a conversation for the humans, and your report handled that distinction more carefully than most. Two loose ends found along the way, for the record rather than for this thread: - xen-net has the same exposure as xen-block, per (1), and is fixed by the same one-line change in xen_device_realize(). - While testing hot-plug of xen-net-device we hit an unrelated, pre-existing heap corruption ("double free or corruption (!prev)") on qemu exit after hot-plugging a xen-net-device, present on current master both with and without the fix. It looks like the same class of exit-notifier-vs-net_cleanup() teardown ordering issue as commit 9000666052 ("xen-block: fix segv on unrealize") was for xen-block. That will be chased separately. Happy to re-run anything on our side, and thank you for an unusually well-diagnosed report =E2=80=94 the negative controls and the explicit constraint analysis made confirming it a matter of hours rather than days. Claude (on behalf of, and supervised by, David Woodhouse ) --=-9qhn9XId8SiCnb9ViCBV Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK 72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9 0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213 MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm 6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6 bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO 02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91 LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8 +3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs +icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1 LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0 D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3 bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2 JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k 0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6 ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74 vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o 9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0yNjA5MTExMjMxMzVaMC8GCSqGSIb3DQEJBDEiBCAW22yVajyZQnomBclSEr0xh3Sj6tmb 9wQowIiupA5KrzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw DQYJKoZIhvcNAQEBBQAEggIAqs1924h9n+Ufb3zZMaHU+e/7us97mVKi8Rm5r0QG2zXb38UMOf+O y+0fKhE1Hd4wOph+vPzP0/Xs4PMprbI6prMiJEGIuizUgt0mrtP8Pf+WfUfqQOzJZTK4JxX1lFkW j6ZuhKuDCR5Uz5+ACXB7dhSyBQ35fJa3VABQaRTmOiftxXG1I7/bQ1YfcbnYlXKQ85OokjhNrZfd hY3a6tmR9AZGm4uQP910Octln5ycacDwGijK/vFwbR2xsr1+Z3Do4B79ft5Ql+HUCTMzZjboW9Ub rJEyirs+Lx6DClOFKRlo9IXEKzyz44isovWSLLah4Y5Nmo7IXFw31w+EYOjLgHTcc8yRRUpg1hrA x0Ue33r79vjmwJQPvTQsxsusGWGnJBOyIjLRy7IMpHz5XNUcLFk2gzerZ3WrCuBDeOKPPYYJEz2O w7LfLsqKdgzA4mwDy0FAj5AGzHQKewmjYw3xW4jso3W0TMeoueEbebCs0UKSEDD2js/Fp+ZsrLya UYQcb6PUW/6NixLAUEKby4lPlMvJbpuOsUfEsGL7rM/m++z9Mi3jU6grlktz2GlGs38d26bAF9Od XauJk/k4RcmNSCP/X3a9Sg0Vm0HdmObDJPcJ1o9rJKADoqU1bNiyRNV1VN0XS6j1D61wBE7nSwg1 KIhCGPGu0theAWP7rjE8DQAAAAAAAAA= --=-9qhn9XId8SiCnb9ViCBV-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:32:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:32:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416521.1645505 (Exim 4.92) (envelope-from ) id 1x50Qj-0001Tw-5W; Fri, 11 Sep 2026 12:32:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416521.1645505; Fri, 11 Sep 2026 12:32:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50Qj-0001Tp-1N; Fri, 11 Sep 2026 12:32:33 +0000 Received: by outflank-mailman (input) for mailman id 1416521; Fri, 11 Sep 2026 12:32:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50Qi-0001TQ-4c for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:32:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50Qh-003k15-HX for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:32:31 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f4d3-bab6-0a2a0a5309dd-0a2a450ae9a0-40 for ; Fri, 11 Sep 2026 14:32:31 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f4de-f2d2-0a2a450a0019-b9ff1c2387ef-3 for ; Fri, 11 Sep 2026 14:32:31 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a09074801c000c4f3.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 12:32:29 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 633EE81D14; Fri, 11 Sep 2026 14:32:28 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=Kk7NzNvXOZksTSAI+a2kYysxHJXVE/FGLmfD1wrzn84=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=XqXgqfN40xiwqrZgDY7FI/RcpcEeHztK626D0WDDHyCc8SiKxPq634mwUyzvpP6gZGqEN9qLt x0Uzjc3ts5v19W/rCYai9s3MIOJMVOJECBgQjCGKpnMP/SScF9O2JUZmJqorg880DSTGIFWgnw3 EWDzU94z4WGMACY03Uh98jQLKKMWfdutlV9HqdXnVvk1+1SVCZdNDFmd//UouQMwFK5dz9aaP4i mevQHl9DUcU5l/uc8JiZO/qcgfZe/5uc2N798H2JwHZNnYlT0xtapwjF30iqeRtMOsKT7rbubKZ JJk9MRwd+Z7Q6LCztDN2cEzvQbGAgU7Tt3y8j+QIrAaw== X-Zone-Loop: 27d5fc45d07db4df7df64b01726ef6561c315e2f293f x-campaign-type: default x-transaction-id: 5a007d59-e0ab-4e2b-b4a4-acfbfe1e75ab x-swg-uid: 01-9fa27866-899c-4951-af94-de3b52ceb64e X-Mailer: Sweego Message-ID: <1789129949.8631fc262581453bbf619ec5b2062170.1a09074801c000c4f3@vates.tech> x-swg-bid: 1789129949.8631fc262581453bbf619ec5b2062170.1a09074801c000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Fri, 11 Sep 2026 14:32:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/7] x86: extend do_mmu_update() to support returning the old PTE value To: Kevin Lampis , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-6-kevin.lampis@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260910203113.462943-6-kevin.lampis@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------7h9HIS3YKtZC0yLhDHFgqbdI" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789129948521 X-purgate-ID: tlsNG-4011c0/1789129951-524DFCFC-C429FEEC/0/0 X-purgate-type: clean X-purgate-size: 8781 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------7h9HIS3YKtZC0yLhDHFgqbdI Content-Type: multipart/mixed; boundary="------------HeSB5bmwIxeXvPWMZ00Yz13d"; protected-headers="v1"; hp="clear" Message-ID: <8fdcb932-ea40-4a82-9b3b-02d383197c8c@vates.tech> Date: Fri, 11 Sep 2026 14:32:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/7] x86: extend do_mmu_update() to support returning the old PTE value To: Kevin Lampis , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-6-kevin.lampis@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260910203113.462943-6-kevin.lampis@citrix.com> --------------HeSB5bmwIxeXvPWMZ00Yz13d Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTAvMDkvMjAyNiDDoCAyMjozMSwgS2V2aW4gTGFtcGlzIGEgw6ljcml0wqA6DQo+IEEg bmV3IHN1Yi1vcCBNTVVfUFRfVVBEQVRFX1NXQVAgd2hlbiB1c2VkIHdpbGwgZG8gYW4gYXRv bWljIHN3YXAgdG8gc2V0DQo+IHRoZSBuZXcgdmFsdWUgYW5kIHJldHVybiB0aGUgb2xkIFBU RSB2YWx1ZSB0aHJvdWdoIHRoZSByZXEudmFsIGZpZWxkLg0KPiANCj4gLSBUaGUgbmV3IFBU RSB2YWx1ZSBpbiByZXEudmFsIG11c3QgYmUgMCwgYXQgdGhlIG1vbWVudCB0aGlzIGlzIGlu dGVuZGVkDQo+ICAgIGZvciBjbGVhcmluZyBvbmx5Lg0KPiANCg0KSSdtIG5vdCBzdXJlIHRo aXMgaXMgYSBnb29kIGlkZWEgdG8gcmVzdHJpY3QgdGhlIGZlYXR1cmUgZm9yIG9ubHkgMC4g SWYgDQppbiB0aGUgZnV0dXJlIHdlIHdhbnQgdG8gZXhwYW5kIHRoaXMgdG8gbm9uLTAgdmFs dWVzLCB3ZSB3aWxsIG5lZWQgdG8gDQphZHZlcnRpc2UgdGhpcyBwcm9wZXJ0eSB0byB0aGUg Z3Vlc3QgYXMgd2VsbCAoc28gdGhhdCBpdCBrbm93cyBpZiBub24tMCANCnZhbHVlcyBhcmUg c3VwcG9ydGVkKS4gSSBkb24ndCBrbm93IHdoYXQgc3VwcG9ydGluZyAhMCB3b3VsZCByZXF1 aXJlIA0KKGJ1dCBpdCBjb3VsZCBiZSB1c2VmdWwgdG8gZ2V0IGEgaWRlYSBvZiBpdCkuDQoN Cj4gLSBPbmx5IGwxIFBURXMgYXJlIHN1cHBvcnRlZCBiZWNhdXNlIHRoZXkgYXJlIHRoZSBt b3N0IGZyZXF1ZW50IGFuZCBoYXZlIHRoZQ0KPiAgICBiaWdnZXN0IHBlcmZvcm1hbmNlIGlt cGFjdC4NCj4gDQo+IC0gVGhlIG9sZCBQVEUgdmFsdWUgaXMgcGFzc2VkIGJhY2sgdG8gdGhl IGd1ZXN0IHRocm91Z2ggdGhlIHJlcS52YWwgZmllbGQNCj4gDQo+IElmIE1NVV9QVF9VUERB VEVfU1dBUCBpcyBub3Qgc2V0IHRoZW4gdGhlIG9sZCBiZWhhdmlvciBpcyBwcmVzZXJ2ZWQN Cj4gICAgZG9fbW11X3VwZGF0ZSAtPiBtb2RfbDFfZW50cnkgLT4gVVBEQVRFX0VOVFJZIC0+ IHBhZ2luZ193cml0ZV9ndWVzdF9lbnRyeQ0KPiANCj4gVGhlIG5ldyBNTVVfUFRfVVBEQVRF X1NXQVAgY2FsbCBjaGFpbiBsb29rcyBsaWtlIHRoaXMNCj4gICAgZG9fbW11X3VwZGF0ZSAt PiBtb2RfbDFfZW50cnkgLT4gVVBEQVRFX0VOVFJZIC0+IHBhZ2luZ19jbXB4Y2hnX2d1ZXN0 X2VudHJ5DQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBLZXZpbiBMYW1waXMgPGtldmluLmxhbXBp c0BjaXRyaXguY29tPg0KPiAtLS0NCj4gQ2hhbmdlcyBpbiB2MjoNCj4gLSBBZGQgYSBzdWIt b3AgdG8gbW11X3VwZGF0ZSBpbnN0ZWFkIG9mIG5ldyBoeXBlcmNhbGwNCj4gLSBSZW5hbWUg dG8gInN3YXAiIGluc3RlYWQgb2YgImNsZWFyIiwgYWx0aG91Z2ggb25seSBgMGAgaXMgYWNj ZXB0ZWQNCj4gLSBSZW1vdmUgc3B1cmlvdXMgY3VybHkgYnJhY2UgZnJvbSBgY2FzZSBQR1Rf bDFfcGFnZV90YWJsZTpgDQo+IC0gUmVzdHJ1Y3R1cmUgYGNhc2UgUEdUX2wxX3BhZ2VfdGFi bGU6YCB0byBhdm9pZCBkaWZmIGNodXJuDQo+IC0gQWRkIG1pc3NpbmcgYE1NVV9QVF9VUERB VEVfU1dBUGAgY2hlY2sgZm9yIHRoZSBzZWNvbmQNCj4gICAgYFBHVF93cml0YWJsZV9wYWdl YCBibG9jaw0KPiANCj4gKEphbikgSSBkZWNpZGVkIG5vdCB0byByZW1vdmUgdGhlIGByYyA9 IC1FSU5WQUxgIGxpbmVzLiBFdmVuIHRob3VnaCBgcmNgDQo+IGFscmVhZHkgaGFzIHRoaXMg dmFsdWUgSSB0aGluayBpdCdzIG1vcmUgcmVhZGFibGUgbGlrZSB0aGlzLiBMZXQgbWUga25v dw0KPiBpZiBJIG1pc3VuZGVyc3Rvb2QgdGhlIGlzc3VlLg0KPiAtLS0NCj4gICB4ZW4vYXJj aC94ODYvbW0uYyAgICAgICAgfCA0OCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKystDQo+ICAgeGVuL2luY2x1ZGUvcHVibGljL3hlbi5oIHwgIDEgKw0KPiAgIDIg ZmlsZXMgY2hhbmdlZCwgNDggaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPiANCj4g ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS5jIGIveGVuL2FyY2gveDg2L21tLmMNCj4g aW5kZXggNTlhZDVjZTE2NDg2Li5iNDk4YTg0NjA5MzUgMTAwNjQ0DQo+IC0tLSBhL3hlbi9h cmNoL3g4Ni9tbS5jDQo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9tbS5jDQo+IEBAIC00MDU1LDYg KzQwNTUsNyBAQCBsb25nIGRvX21tdV91cGRhdGUoDQo+ICAgICAgICAgICBjYXNlIE1NVV9O T1JNQUxfUFRfVVBEQVRFOg0KPiAgICAgICAgICAgY2FzZSBNTVVfUFRfVVBEQVRFX1BSRVNF UlZFX0FEOg0KPiAgICAgICAgICAgY2FzZSBNTVVfUFRfVVBEQVRFX05PX1RSQU5TTEFURToN Cj4gKyAgICAgICAgY2FzZSBNTVVfUFRfVVBEQVRFX1NXQVA6DQo+ICAgICAgICAgICB7DQo+ ICAgICAgICAgICAgICAgcDJtX3R5cGVfdCBwMm10Ow0KPiAgIA0KPiBAQCAtNDExOCw2ICs0 MTE5LDMwIEBAIGxvbmcgZG9fbW11X3VwZGF0ZSgNCg0KKC4uLikNCg0KPiBkaWZmIC0tZ2l0 IGEveGVuL2luY2x1ZGUvcHVibGljL3hlbi5oIGIveGVuL2luY2x1ZGUvcHVibGljL3hlbi5o DQo+IGluZGV4IDIxNDliOGRkMzgwOC4uNTU5MTkwNjg4YTFlIDEwMDY0NA0KPiAtLS0gYS94 ZW4vaW5jbHVkZS9wdWJsaWMveGVuLmgNCj4gKysrIGIveGVuL2luY2x1ZGUvcHVibGljL3hl bi5oDQo+IEBAIC0zNDksNiArMzQ5LDcgQEAgREVGSU5FX1hFTl9HVUVTVF9IQU5ETEUoeGVu X3Vsb25nX3QpOw0KPiAgICNkZWZpbmUgTU1VX1BUX1VQREFURV9QUkVTRVJWRV9BRCAgMiAv KiBhdG9taWNhbGx5OiAqcHRyID0gdmFsIHwgKCpwdHImKEF8RCkpICovDQo+ICAgI2RlZmlu ZSBNTVVfUFRfVVBEQVRFX05PX1RSQU5TTEFURSAzIC8qIGNoZWNrZWQgJypwdHIgPSB2YWwn LiBwdHIgaXMgTUEuICAgICAgKi8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLyogdmFsIG5ldmVyIHRyYW5zbGF0ZWQuICAgICAgICAgICAgICAgICAqLw0K PiArI2RlZmluZSBNTVVfUFRfVVBEQVRFX1NXQVAgICAgICAgICA0DQoNClRoYXQgd2FudHMg c29tZSBkb2N1bWVudGF0aW9uIDogdGhlIG9wZXJhdGlvbiBpdCBkb2VzLCBhbmQgdGhlIA0K cmVzdHJpY3Rpb25zIHRoYXQgYXBwbGllcyAoaS5lIHRoZSBmYWN0IGl0J3MgTDEtb25seSwg cmVzdHJpY3Rpb25zLCAuLi4pLg0KDQo+ICAgDQo+ICAgLyoNCj4gICAgKiBNTVUgRVhURU5E RUQgT1BFUkFUSU9OUw0KVGVkZHkNCg== --------------HeSB5bmwIxeXvPWMZ00Yz13d-- --------------7h9HIS3YKtZC0yLhDHFgqbdI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqj9NwFAwAAAAAACgkQZg+p0QLLz9B8 Kgv/TF6D050ils2h3oVJQ+CrAukvfZUKgTO6HZXLSIsCf+Qg5KmfpEXgfJ54MqdyAFgd7AcxAToP r1t6KL9FbwE2xQelDVUtuu7AaaEGFnGASmXrktEMFQtGSnPyTWwfl8OZgjkyN+nxifP4ZxyzDG9n bVKMsmqmBmT5STDhSCh93yIhoBLt2U4CfBZTBAjNSwYGO4YUqJc6/cZqEOcWCtEDdECChcEk++8t 6+RHHzTuF8hrC4pZNnwRdMZJ89RtOcpQSrUfJbAQvR6pAb3T3mbHTu5J9UtlQ/apH+1O9AQh+NNr SmgPGP9bcIl94nfqDMUvE/bYIVA/4aBWHrsUh8U+JI6NfDl0AW0N1sz6Uve3S1HoiZdRTPnwpqJS GEc/Lf1ohI/u64yRozejvDuLZgxhHhPwmq1Py/75wPW1sFMakcl4QbX96r57LiH5IrAc+jYXUeS+ l3zcJyADY/WODY14e8px1OQGHDg9KbCQHBDMhTlGnOgASvzsTFzyPUf63JyG =JXLw -----END PGP SIGNATURE----- --------------7h9HIS3YKtZC0yLhDHFgqbdI-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:43:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:43:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416552.1645514 (Exim 4.92) (envelope-from ) id 1x50bC-0003YR-5n; Fri, 11 Sep 2026 12:43:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416552.1645514; Fri, 11 Sep 2026 12:43:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50bC-0003YK-1j; Fri, 11 Sep 2026 12:43:22 +0000 Received: by outflank-mailman (input) for mailman id 1416552; Fri, 11 Sep 2026 12:43:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50b9-0003YC-Q0 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:43:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50b9-00E74Q-3F for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:43:19 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f760-bab6-0a2a0a5309dd-0a2a4502c906-16 for ; Fri, 11 Sep 2026 14:43:18 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f766-6ca4-0a2a45020019-b9ff1c22ac5f-3 for ; Fri, 11 Sep 2026 14:43:18 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0907e5286000c4f3.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 12:43:12 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id D3AF781CB6; Fri, 11 Sep 2026 14:43:11 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=Bu12jXMJm8GjZhPvCvfsajc4jUJsd07geW0o9wwP8fo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=bWQm3gUEYpSCVtEFrZFO5Rgx4ch13K97cjanQ5UkFGpsvRV8472LtTSJeuNJZwhIUv8bjLGAl mj5KU02AXzEaplaSQ7dyDueotYxoVpVsBu/6xP41Vq/VPTiQi1a3d9QsA3i/8A3Why/mhF7y0q3 kmjNtA74CXP5NbYGKtSi/xfYBmKsrHUejDSGliutmXSjoD07yrQERIlftP6EO5Abg/XcWzaiDkL D7EiZS+SB9vtf86OYlVr3RRn1na78tarjfVDH2kubhG2NmCjqe3Te3j4Kt2Z/9subhCxmSr0KEh 8w7bKYX1y+2mse1KQByFkigAImq4npAEZu4caezE876w== X-Zone-Loop: 39f8d28d5a3727b069b3e51300e71da283f345cd7597 x-campaign-type: default x-transaction-id: f0ed48fe-367a-4889-94f7-50655f004c95 x-swg-uid: 01-80eeb00b-d9b4-43b7-b510-7c615dd06609 X-Mailer: Sweego Message-ID: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> x-swg-bid: 1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Julian Vetter Subject: [PATCH v5 0/6] Fix ARM domcreate Date: Fri, 11 Sep 2026 14:43:03 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.b1.3fe94993bb994924.1a0907e4fb6.d40a429c810fd403=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789130592183 X-purgate-ID: tlsNG-720697/1789130598-F30B02AC-52A0DA57/0/0 X-purgate-type: clean X-purgate-size: 4121 ---=Part.b1.3fe94993bb994924.1a0907e4fb6.d40a429c810fd403=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Michal and Andrew, Thank you Michal for the very thorough review on v4! I have addressed The GICv2-compat-mode handling in arch_sanitise_domain_config(), the gic_domctl_hw_version() naming, the XEN_DOMCTL_INTERFACE_VERSION bump, and signalling to libxl whether the timer frequency came from the host DT=2E In regards to your other comment Michal "what guarantees mask is a single bit?", and the answer is "nothing"=2E You're right there is nothing that prevents anyone trying to check multiple bits or passing a bitmask, e=2Eg=2E, "XXX|YYY"=2E This is why I went back to the original implementat= ion=2E In know your previous comment Andrew and I fully agree, and it will probably get worse in the future to have tons of small 3 line inline functions like this to check all sorts of features=2E But after trying for a bit, I believe fixing this in a proper way, is more complicated than I initially thought and merits its own patch series=2E Because adding this to this series would bloat it with more somehow "unrelated" changes=2E I'd rather leave a proper arch_capabilities_arm_has() as a separate cleanup for later=2E Sorry for the back-and-forth on this one and I hope you both agree=2E Signed-off-by: Julian Vetter --- Andrew Cooper (1): ARM/sysctl: Expose the supported guest GIC modes in physinfo Julian Vetter (5): xen/arm: report proper GIC version via XEN_DOMCTL_getdomaininfo tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE xen/arm: remove XEN_DOMCTL_CONFIG_GIC_NATIVE from the ABI xen/arm: report clock_frequency via sysctl physinfo, not createdomain xen: make config argument const CHANGELOG=2Emd | 4 ++ docs/man/xl=2Ecfg=2E5=2Epod=2Ein | 9 +-- =2E=2E=2E/include/xen-tools/arm-arch-capabilities=2Eh | 31 +++++++++ tools/libs/light/libxl=2Ec | 1 + tools/libs/light/libxl_arm=2Ec | 66 +++++++++++++++++-- tools/libs/light/libxl_types=2Eidl | 5 +- tools/ocaml/libs/xc/xenctrl=2Eml | 1 - tools/ocaml/libs/xc/xenctrl=2Emli | 1 - tools/python/xen/lowlevel/xc/xc=2Ec | 18 ++++- xen/arch/arm/dom0less-build=2Ec | 3 +- xen/arch/arm/domain=2Ec | 31 ++++----- xen/arch/arm/domain_build=2Ec | 3 +- xen/arch/arm/domctl=2Ec | 2 + xen/arch/arm/firmware/sci=2Ec | 2 +- xen/arch/arm/firmware/scmi-smc=2Ec | 2 +- xen/arch/arm/gic=2Ec | 16 +++++ xen/arch/arm/include/asm/firmware/sci=2Eh | 6 +- xen/arch/arm/include/asm/gic=2Eh | 6 ++ xen/arch/arm/include/asm/time=2Eh | 7 +- xen/arch/arm/include/asm/vgic=2Eh | 6 ++ xen/arch/arm/include/asm/vtimer=2Eh | 3 +- xen/arch/arm/sysctl=2Ec | 39 +++++++++++ xen/arch/arm/time=2Ec | 9 ++- xen/arch/arm/vgic-v2=2Ec | 5 ++ xen/arch/arm/vgic/vgic-v2=2Ec | 5 ++ xen/arch/arm/vtimer=2Ec | 4 +- xen/arch/ppc/stubs=2Ec | 2 +- xen/arch/riscv/domain=2Ec | 2 +- xen/arch/x86/domain=2Ec | 16 ++--- xen/include/public/arch-arm=2Eh | 18 +---- xen/include/public/domctl=2Eh | 4 +- xen/include/public/sysctl=2Eh | 22 ++++++- xen/include/xen/sched=2Eh | 5 +- 33 files changed, 273 insertions(+), 81 deletions(-) --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.b1.3fe94993bb994924.1a0907e4fb6.d40a429c810fd403=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:48:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:48:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416560.1645531 (Exim 4.92) (envelope-from ) id 1x50fa-0004Sf-Rc; Fri, 11 Sep 2026 12:47:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416560.1645531; Fri, 11 Sep 2026 12:47:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fa-0004SY-Oy; Fri, 11 Sep 2026 12:47:54 +0000 Received: by outflank-mailman (input) for mailman id 1416560; Fri, 11 Sep 2026 12:47:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fZ-0004S4-BJ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:47:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50fY-00DvZA-OM for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:47:52 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f86b-8faa-0a2a0a5109dd-0a2a4503b718-28 for ; Fri, 11 Sep 2026 14:47:52 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f878-fae8-0a2a45030019-b9ff1c23b39b-3 for ; Fri, 11 Sep 2026 14:47:52 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a090827031000c4f3.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 12:47:42 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id DDBF981E58; Fri, 11 Sep 2026 14:47:41 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=owWzbNGsyZu7biLRA5l6PyyQaMaYKEJeQpD3hgcKdLc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=lvBJ+pyEfGMK2g2wEkh96uE1QSMAEFubh6NIIeRFUkkWcvMXlTXmmUMs8UFexSU7nJo6WrXxC ryQDcXNGKH6kor9TKnVx8xrv66HXGYv8oqV3H9nrVE06XTMJlSSNHlEfXRvJ6/m0ihQq2E9Tzin kLqEZEBZPr9Lngqb2bvjPLbhSopbsh5pj1bCIlVJqjybLpS6Ofv36Ul79iU8+hnLUXKRPqXPwWO YhxilDsKhr3MyynsZosTrLfe+oErgrPTQi/LFO9JCCs2YXGxmQme9lBFL/K1LeLhvLapwZ+L1IE emlg5t55rbsk4uO4GNQbOzGL79P1W/B+RXl+z7/3cYrQ== X-Zone-Loop: 9cf6a9fa902ee05aca6b2846dc4d8a46f206bd129666 x-campaign-type: default x-transaction-id: dea90c76-0d89-4479-bfe3-5d1f753d466f x-swg-uid: 01-816b2962-cec2-4b9f-b0a1-e9689d89178c X-Mailer: Sweego Message-ID: <1789130862.8631fc262581453bbf619ec5b2062170.1a090827031000c4f3@vates.tech> x-swg-bid: 1789130862.8631fc262581453bbf619ec5b2062170.1a090827031000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Julian Vetter Subject: [PATCH v5 2/6] ARM/sysctl: Expose the supported guest GIC modes in physinfo Date: Fri, 11 Sep 2026 14:47:32 +0200 In-Reply-To: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.b3.969fd93c1d23af99.1a090826e8d.a9cdd1a1b522cf15=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789130862221 X-purgate-ID: tlsNG-33051d/1789130872-778F24E9-5366F047/0/0 X-purgate-type: clean X-purgate-size: 5235 ---=Part.b3.969fd93c1d23af99.1a090826e8d.a9cdd1a1b522cf15=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andrew Cooper In preparation to simplify the domain creation logic surrounding GIC version=2E On a GICv3 host, also report support for GICv2-compatible guests when the hardware's vGICv2 compatibility mode is enabled, rather than just the native GIC version=2E Signed-off-by: Andrew Cooper Signed-off-by: Julian Vetter --- Changes in v5: - Add vgic_v2_hw_enabled() to new vgic implementation=2E --- xen/arch/arm/include/asm/vgic=2Eh | 6 ++++++ xen/arch/arm/sysctl=2Ec | 34 +++++++++++++++++++++++++++++++++ xen/arch/arm/vgic-v2=2Ec | 5 +++++ xen/arch/arm/vgic/vgic-v2=2Ec | 5 +++++ xen/include/public/sysctl=2Eh | 2 ++ 5 files changed, 52 insertions(+) diff --git a/xen/arch/arm/include/asm/vgic=2Eh b/xen/arch/arm/include/asm/= vgic=2Eh index 6f9ab1c98c=2E=2E26c53aaf3c 100644 --- a/xen/arch/arm/include/asm/vgic=2Eh +++ b/xen/arch/arm/include/asm/vgic=2Eh @@ -433,6 +433,12 @@ unsigned int vgic_max_vcpus(unsigned int domctl_vgic_= version); void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize, paddr_t vbase, uint32_t aliased_offset); =20 +#ifdef CONFIG_VGICV2 +bool vgic_v2_hw_enabled(void); +#else +static inline bool vgic_v2_hw_enabled(void) { return false; } +#endif + #ifdef CONFIG_GICV3 struct rdist_region; void vgic_v3_setup_hw(paddr_t dbase, diff --git a/xen/arch/arm/sysctl=2Ec b/xen/arch/arm/sysctl=2Ec index 32cab4feff=2E=2E8411deb7e2 100644 --- a/xen/arch/arm/sysctl=2Ec +++ b/xen/arch/arm/sysctl=2Ec @@ -12,7 +12,11 @@ #include #include #include + #include +#include +#include + #include =20 void arch_do_physinfo(struct xen_sysctl_physinfo *pi) @@ -21,6 +25,36 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi) =20 pi->arch_capabilities |=3D MASK_INSR(sve_encode_vl(get_sys_vl_len()), XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK); + + /* + * The GIC version(s) we're happy creating guests with=2E Right now f= or + * simplicity it is tied to the active hardware version, but this wil= l + * cease to be the case if/when the compatibility modes are enabled= =2E + */ + switch ( gic_hw_version() ) + { + case GIC_V2: + pi->arch_capabilities |=3D XEN_SYSCTL_PHYSCAP_ARM_GIC_V2; + break; + + case GIC_V3: + pi->arch_capabilities |=3D XEN_SYSCTL_PHYSCAP_ARM_GIC_V3; + + /* GICv3 may additionally support GICv2-compatible guests=2E */ + if ( vgic_v2_hw_enabled() ) + pi->arch_capabilities |=3D XEN_SYSCTL_PHYSCAP_ARM_GIC_V2; + break; + + case GIC_INVALID: + /* + * Running a control domain without having the GIC sorted yet? + * Something's broken, but there's nothing we can do about it her= e=2E + */ + ASSERT_UNREACHABLE(); + printk_once(XENLOG_ERR "Unrecognised GIC version %d\n", + gic_hw_version()); + break; + } } =20 long arch_do_sysctl(struct xen_sysctl *sysctl, diff --git a/xen/arch/arm/vgic-v2=2Ec b/xen/arch/arm/vgic-v2=2Ec index 6328ce6f7e=2E=2E62666a84db 100644 --- a/xen/arch/arm/vgic-v2=2Ec +++ b/xen/arch/arm/vgic-v2=2Ec @@ -49,6 +49,11 @@ void __init vgic_v2_setup_hw(paddr_t dbase, paddr_t cba= se, paddr_t csize, vgic_v2_hw=2Ealiased_offset =3D aliased_offset; } =20 +bool vgic_v2_hw_enabled(void) +{ + return vgic_v2_hw=2Eenabled; +} + #define NR_TARGETS_PER_ITARGETSR 4U #define NR_BITS_PER_TARGET (32U / NR_TARGETS_PER_ITARGETSR) =20 diff --git a/xen/arch/arm/vgic/vgic-v2=2Ec b/xen/arch/arm/vgic/vgic-v2=2Ec index 06fa365453=2E=2Ef6a58ed89e 100644 --- a/xen/arch/arm/vgic/vgic-v2=2Ec +++ b/xen/arch/arm/vgic/vgic-v2=2Ec @@ -47,6 +47,11 @@ void __init vgic_v2_setup_hw(paddr_t dbase, paddr_t cba= se, paddr_t csize, printk("Using the new VGIC implementation=2E\n"); } =20 +bool vgic_v2_hw_enabled(void) +{ + return gic_v2_hw_data=2Eenabled; +} + /* * transfer the content of the LRs back into the corresponding ap_list: * - active bit is transferred as is diff --git a/xen/include/public/sysctl=2Eh b/xen/include/public/sysctl=2Eh index c7cd9b4eb0=2E=2Ed20ebf3644 100644 --- a/xen/include/public/sysctl=2Eh +++ b/xen/include/public/sysctl=2Eh @@ -106,6 +106,8 @@ struct xen_sysctl_tbuf_op { =20 #if defined(__arm__) || defined(__aarch64__) #define XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK (0x1FU) +#define XEN_SYSCTL_PHYSCAP_ARM_GIC_V2 (1U << 5) +#define XEN_SYSCTL_PHYSCAP_ARM_GIC_V3 (1U << 6) #endif =20 struct xen_sysctl_physinfo { --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.b3.969fd93c1d23af99.1a090826e8d.a9cdd1a1b522cf15=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:48:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:48:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416559.1645521 (Exim 4.92) (envelope-from ) id 1x50fW-0004Fe-LB; Fri, 11 Sep 2026 12:47:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416559.1645521; Fri, 11 Sep 2026 12:47:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fW-0004FX-IR; Fri, 11 Sep 2026 12:47:50 +0000 Received: by outflank-mailman (input) for mailman id 1416559; Fri, 11 Sep 2026 12:47:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fV-0004FR-Mm for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:47:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50fU-00DvVv-Oz for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:47:48 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f86b-8faa-0a2a0a5109dd-0a2a4503b718-14 for ; Fri, 11 Sep 2026 14:47:48 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f874-fae8-0a2a45030019-b9ff1c2298bb-3 for ; Fri, 11 Sep 2026 14:47:48 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a090826e80000c4f3.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 12:47:42 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 5128981E4A; Fri, 11 Sep 2026 14:47:41 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=iG8S7D9YAqkRZpmiMfZnvdLr/zW0nBYYhrBnB0uaR+4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=pJ5wSN5lXSzr+sZTTI9rPmgijl7J8kOiBTnDViQ+IGugobNFfU7RY1Z5pTRxf3tmiYZVcnnsh ldOkaVDn3ob+krcWlJabnhSCHRiwmXTnlZhSzGnhBzDv8s9VWqwR9XC/YHzHMG2mHyvPSt3oeyB LWlFXC4KJk2LX31HstxMtceIlfX/fV89eH6v7mdfZrBpRls+QJVWu4oMIxBOwJiQeE2gfdYaKb6 a7Ijw1+6fz30SXZkcXzxIVkgcepaKSeJ4DGgVH0xY2pT4yQ7Qgk6J6ak1+20qZ+XWMz5ffgS0H0 2edsf/FKIi900ZQN4V/zlekBPXKf8a3coYse9aV5+ihQ== X-Zone-Loop: 66a1a4e8ef3c679b2054f71da0be143b8b1336fbbd3c x-campaign-type: default x-transaction-id: dc9be154-fbe2-4a43-ad82-2fdf3382dc45 x-swg-uid: 01-bc942bc5-26f1-4737-a1cf-c5b0b84c3775 X-Mailer: Sweego Message-ID: <1789130862.8631fc262581453bbf619ec5b2062170.1a090826e80000c4f3@vates.tech> x-swg-bid: 1789130862.8631fc262581453bbf619ec5b2062170.1a090826e80000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Julian Vetter Subject: [PATCH v5 1/6] xen/arm: report proper GIC version via XEN_DOMCTL_getdomaininfo Date: Fri, 11 Sep 2026 14:47:31 +0200 In-Reply-To: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.b2.6aee1b0ecd97f04d.1a090826c72.643865296eedc423=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789130861682 X-purgate-ID: tlsNG-33051d/1789130868-768FA4E9-B7D8BB50/0/0 X-purgate-type: clean X-purgate-size: 2036 ---=Part.b2.6aee1b0ecd97f04d.1a090826c72.643865296eedc423=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable When creating a domain on ARM, and passing XEN_DOMCTL_CONFIG_GIC_NATIVE for the gic_version field in the struct xen_arch_domainconfig, arch_sanitise_domain_config() resolves this to the approrpiate GIC_V2 or GIC_V3 version the domain actually has, based on the host's gic_hw_version()=2E That value is stored in the domain as d->arch=2Evgic=2Eversion, but can't be queried through any other domctl later=2E Toolstacks that create and build a domain in the same call already have this info from the createdomain reply and never need to ask again=2E Toolstacks that create a domain and build it later from a separate process do need to ask again=2E But, the ARM implementation only fills in info->flags and info->gpaddr_bits=2E info->arch_config is left zeroed, so XEN_DOMCTL_getdomaininfo always reports gic_version as XEN_DOMCTL_CONFIG_GIC_NATIVE (0) regardless of what was actually configured earlier=2E Signed-off-by: Julian Vetter Reviewed-by: Andrew Cooper Reviewed-by: Michal Orzel --- Changes in v5: - No changes=2E --- xen/arch/arm/domctl=2Ec | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/arm/domctl=2Ec b/xen/arch/arm/domctl=2Ec index 6c9a3f9920=2E=2Eb76af56fad 100644 --- a/xen/arch/arm/domctl=2Ec +++ b/xen/arch/arm/domctl=2Ec @@ -24,6 +24,8 @@ void arch_get_domain_info(const struct domain *d, info->flags |=3D XEN_DOMINF_hap; =20 info->gpaddr_bits =3D p2m_ipa_bits; + + info->arch_config=2Egic_version =3D d->arch=2Evgic=2Eversion; } =20 static int handle_vuart_init(struct domain *d,=20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.b2.6aee1b0ecd97f04d.1a090826c72.643865296eedc423=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:48:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:48:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416561.1645541 (Exim 4.92) (envelope-from ) id 1x50fh-0004j8-4u; Fri, 11 Sep 2026 12:48:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416561.1645541; Fri, 11 Sep 2026 12:48:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fh-0004iy-0Q; Fri, 11 Sep 2026 12:48:01 +0000 Received: by outflank-mailman (input) for mailman id 1416561; Fri, 11 Sep 2026 12:47:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50ff-0004go-Dc for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:47:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50fe-008TeR-9z for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:47:58 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f877-bab6-0a2a0a5309dd-0a2a4502e99c-14 for ; Fri, 11 Sep 2026 14:47:58 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f87d-6ca4-0a2a45020019-b9ff1c239bc3-3 for ; Fri, 11 Sep 2026 14:47:58 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a090827272000c4f3.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 12:47:43 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 52F7081E4A; Fri, 11 Sep 2026 14:47:42 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=vrC5MCXxLXkzGn7Ngh7f+8ojnwijQbLllCJ+rZnRPgc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=OPkpc6pvgZSQvxmsmOL6Tj+9fky4rSsYhrMNQUkfLTJ9kL07+O1YWA86FbvEpuT35s0QnVfwl n+KH9ypUSOv4akxYTBupy8fH5EfAZILJq9qZLwA0c/YDxKi7dOrgbQAy6znP67Onz0jQfX3MwAo EzW0nP91ANi12s+0rTt0WvuUDydduMvPZgE7wBE1xGrEX6ogQzDUJQmrqTN83K1k2V66fqXGRll cjZcxUqY1B8x+IRVbK6IlGVMvY9VMdpgqNhMj5YnmSWHS0s27tFIxL7wcgcTiE75sW0NobVdi/k QS3sB3UraFeR+ShVOxFX2AC1gGsV9PEz++ErYh4yeV8g== X-Zone-Loop: 4a3653298c3bf37ca16e2812419115f707825a9f6892 x-campaign-type: default x-transaction-id: 78459a14-e521-4521-990a-8b7311a5bc2a x-swg-uid: 01-92954f62-b3c4-493b-b03d-5b6ef9ae6f6d X-Mailer: Sweego Message-ID: <1789130863.8631fc262581453bbf619ec5b2062170.1a090827272000c4f3@vates.tech> x-swg-bid: 1789130863.8631fc262581453bbf619ec5b2062170.1a090827272000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Julian Vetter Subject: [PATCH v5 3/6] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE Date: Fri, 11 Sep 2026 14:47:33 +0200 In-Reply-To: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.b4.900c1da711343b33.1a09082703b.b4d96a58cee70c8d=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789130862651 X-purgate-ID: tlsNG-720697/1789130878-F36BF2AC-B6BB2CCB/0/0 X-purgate-type: clean X-purgate-size: 9446 ---=Part.b4.900c1da711343b33.1a09082703b.b4d96a58cee70c8d=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable XEN_DOMCTL_CONFIG_GIC_NATIVE lets the toolstack ask Xen to silently resolve the domain's GIC version to whatever the host hardware has=2E Xen then writes the resolved value back into the same in/out xen_arch_domainconfig the toolstack used as input, which is the kind of API abuse we're trying to get rid of=2E The struct passed to createdomain should only be an input parameter=2E Move the "pick the best available GIC version" decision to the toolstack, using the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 capability bits already exposed via XEN_SYSCTL_physinfo: * libxl__arch_domain_build_info_setdefault() resolves the GIC version against those bits before the config is built=2E An unspecified version becomes v3 if available, else v2, else fails=2E An explicitly requested v2/v3 is validated against the same bits, so a version the host cannot provide is directly rejected in the toolstack=2E * The Python xc=2Edomain_create() binding does the same via a call to xc_physinfo()=2E * libxl__arch_domain_prepare_config() therefore only ever sees a concrete v2/v3 request and just validates it=2E The GIC_NATIVE case is dropped since setdefault() always resolves it first=2E The LIBXL_GIC_VERSION enum value 0 is renamed from DEFAULT to NONE to reflect that it now only means "the user did not pick a version"=2E setdefault() resolves it before anything else can observe it, so there is no longer a "default" left in the config=2E The xl=2Ecfg(5) gic_version documentation is updated to match=2E This guarantees no toolstack path can still produce XEN_DOMCTL_CONFIG_GIC_NATIVE, in preparation for removing it from the Xen side and from the ABI entirely=2E Signed-off-by: Julian Vetter --- Changes in v5: - Go back to the initial per-version arch_capabilities_arm_gic_{v2,v3}() helpers instead of a generic arch_capabilities_arm_has(caps, mask) - Validate an explicitly requested GIC version against the host capabilities, not just resolve an unspecified one - Rename LIBXL_GIC_VERSION_DEFAULT to LIBXL_GIC_VERSION_NONE - Document the change in xl=2Ecfg(5) --- docs/man/xl=2Ecfg=2E5=2Epod=2Ein | 9 ++-- =2E=2E=2E/include/xen-tools/arm-arch-capabilities=2Eh | 21 +++++++++ tools/libs/light/libxl_arm=2Ec | 45 +++++++++++++++++-- tools/libs/light/libxl_types=2Eidl | 4 +- tools/python/xen/lowlevel/xc/xc=2Ec | 18 +++++++- 5 files changed, 87 insertions(+), 10 deletions(-) diff --git a/docs/man/xl=2Ecfg=2E5=2Epod=2Ein b/docs/man/xl=2Ecfg=2E5=2Epo= d=2Ein index d34951edb9=2E=2E6a5e75eeab 100644 --- a/docs/man/xl=2Ecfg=2E5=2Epod=2Ein +++ b/docs/man/xl=2Ecfg=2E5=2Epod=2Ein @@ -3081,15 +3081,16 @@ Emulate a GICv2 Emulate a GICv3=2E Note that the emulated GIC does not support the GICv2 compatibility mode=2E =20 -=3Ditem B +=3Ditem B =20 -Emulate the same version as the native GIC hardware used by the host wher= e -the domain was created=2E +Let the toolstack choose the GIC version: GICv3 if the host supports it, +otherwise GICv2=2E This is the default when C is not specifi= ed=2E =20 =3Dback =20 This requires hardware compatibility with the requested version, either -natively or via hardware backwards compatibility support=2E +natively or via hardware backwards compatibility support=2E The GIC versi= ons +the host can emulate for a guest are reported via C= =2E =20 =3Ditem B =20 diff --git a/tools/include/xen-tools/arm-arch-capabilities=2Eh b/tools/inc= lude/xen-tools/arm-arch-capabilities=2Eh index 4aa4c6c34a=2E=2E21e3c73bd1 100644 --- a/tools/include/xen-tools/arm-arch-capabilities=2Eh +++ b/tools/include/xen-tools/arm-arch-capabilities=2Eh @@ -6,6 +6,7 @@ #ifndef ARM_ARCH_CAPABILITIES_H #define ARM_ARCH_CAPABILITIES_H =20 +#include #include #include =20 @@ -25,4 +26,24 @@ unsigned int arch_capabilities_arm_sve(unsigned int arc= h_capabilities) #endif } =20 +static inline +bool arch_capabilities_arm_gic_v2(unsigned int arch_capabilities) +{ +#if defined(__arm__) || defined(__aarch64__) + return MASK_EXTR(arch_capabilities, XEN_SYSCTL_PHYSCAP_ARM_GIC_V2); +#else + return false; +#endif +} + +static inline +bool arch_capabilities_arm_gic_v3(unsigned int arch_capabilities) +{ +#if defined(__arm__) || defined(__aarch64__) + return MASK_EXTR(arch_capabilities, XEN_SYSCTL_PHYSCAP_ARM_GIC_V3); +#else + return false; +#endif +} + #endif /* ARM_ARCH_CAPABILITIES_H */ diff --git a/tools/libs/light/libxl_arm=2Ec b/tools/libs/light/libxl_arm= =2Ec index 7e9f8a1bc3=2E=2E283cfb749b 100644 --- a/tools/libs/light/libxl_arm=2Ec +++ b/tools/libs/light/libxl_arm=2Ec @@ -196,9 +196,6 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, LOG(DEBUG, " - Allocate %u SPIs", config->arch=2Enr_spis); =20 switch (d_config->b_info=2Earch_arm=2Egic_version) { - case LIBXL_GIC_VERSION_DEFAULT: - config->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE; - break; case LIBXL_GIC_VERSION_V2: config->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2; break; @@ -1800,6 +1797,48 @@ int libxl__arch_domain_build_info_setdefault(libxl_= _gc *gc, /* Trapping of unmapped accesses enabled by default=2E */ libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true); =20 + /* + * Resolve the GIC version against the host capabilities reported by + * XEN_SYSCTL_physinfo=2E If the user didn't request a specific versi= on, pick + * the best one available=2E Otherwise validate the requested version= here, + * so a bad request fails early instead of in the hypervisor=2E + */ + { + bool has_v3 =3D arch_capabilities_arm_gic_v3(physinfo->arch_capab= ilities); + bool has_v2 =3D arch_capabilities_arm_gic_v2(physinfo->arch_capab= ilities); + + switch (b_info->arch_arm=2Egic_version) { + case LIBXL_GIC_VERSION_NONE: + if (has_v3) + b_info->arch_arm=2Egic_version =3D LIBXL_GIC_VERSION_V3; + else if (has_v2) + b_info->arch_arm=2Egic_version =3D LIBXL_GIC_VERSION_V2; + else { + LOG(ERROR, "No supported GIC version found on this host")= ; + return ERROR_FAIL; + } + break; + + case LIBXL_GIC_VERSION_V3: + if (!has_v3) { + LOG(ERROR, "GICv3 requested but not supported on this hos= t"); + return ERROR_FAIL; + } + break; + + case LIBXL_GIC_VERSION_V2: + if (!has_v2) { + LOG(ERROR, "GICv2 requested but not supported on this hos= t"); + return ERROR_FAIL; + } + break; + + default: + LOG(ERROR, "Unknown GIC version %d", b_info->arch_arm=2Egic_v= ersion); + return ERROR_FAIL; + } + } + /* Sanitise SVE parameter */ if (b_info->arch_arm=2Esve_vl) { unsigned int max_sve_vl =3D diff --git a/tools/libs/light/libxl_types=2Eidl b/tools/libs/light/libxl_t= ypes=2Eidl index a7893460f0=2E=2E8699ab3013 100644 --- a/tools/libs/light/libxl_types=2Eidl +++ b/tools/libs/light/libxl_types=2Eidl @@ -520,10 +520,10 @@ libxl_vnode_info =3D Struct("vnode_info", [ ]) =20 libxl_gic_version =3D Enumeration("gic_version", [ - (0, "DEFAULT"), + (0, "NONE"), (0x20, "v2"), (0x30, "v3") - ], init_val =3D "LIBXL_GIC_VERSION_DEFAULT") + ], init_val =3D "LIBXL_GIC_VERSION_NONE") =20 libxl_tee_type =3D Enumeration("tee_type", [ (0, "none"), diff --git a/tools/python/xen/lowlevel/xc/xc=2Ec b/tools/python/xen/lowlev= el/xc/xc=2Ec index 7a4bf54597=2E=2E0127b4b1b7 100644 --- a/tools/python/xen/lowlevel/xc/xc=2Ec +++ b/tools/python/xen/lowlevel/xc/xc=2Ec @@ -163,7 +163,23 @@ static PyObject *pyxc_domain_create(XcObject *self, ~(XEN_X86_EMU_VPCI | XEN_X86_EMU_USE_PIRQ); #elif defined (__arm__) || defined(__aarch64__) - config=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE; + { + xc_physinfo_t pinfo; + + if ( xc_physinfo(self->xc_handle, &pinfo) !=3D 0 ) + return pyxc_error_to_exception(self->xc_handle); + + if ( arch_capabilities_arm_gic_v3(pinfo=2Earch_capabilities) ) + config=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V3; + else if ( arch_capabilities_arm_gic_v2(pinfo=2Earch_capabilities)= ) + config=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2; + else + { + errno =3D EINVAL; + PyErr_SetFromErrno(xc_error_obj); + return NULL; + } + } #else #error Architecture not supported #endif --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.b4.900c1da711343b33.1a09082703b.b4d96a58cee70c8d=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:48:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:48:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416563.1645548 (Exim 4.92) (envelope-from ) id 1x50fm-00051G-FT; Fri, 11 Sep 2026 12:48:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416563.1645548; Fri, 11 Sep 2026 12:48:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fm-000519-CT; Fri, 11 Sep 2026 12:48:06 +0000 Received: by outflank-mailman (input) for mailman id 1416563; Fri, 11 Sep 2026 12:48:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fl-0004zb-5Y for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:48:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50fk-003mH0-I9 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:48:04 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f878-e002-0a2a0a5209dd-0a2a4508ea68-34 for ; Fri, 11 Sep 2026 14:48:04 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f884-f659-0a2a45080019-b9ff1c23a55f-3 for ; Fri, 11 Sep 2026 14:48:04 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a09082744e000c4f3.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 12:47:43 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id BCC3B81E58; Fri, 11 Sep 2026 14:47:42 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=zbpTZxCu0I/pB7xgrSlTLWOGkj1LZPQfs18Cj/FuclM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=AeNM5EMT2vhtM4JjC8UeSEXPSCuZ4S15CwxoIycGSwShFZK+t2iig+CBTmkE7jfM5aVBiaEgG ZYFY19TLpYWvzNNyHeIroLgEpezksClxUXyYxYuhHacD1u16DCAyTz6pFtiXniwnvnqkUZJ3wrU ezDcRX4c2jaQ5DwTKfqOMrGy2kGdNFILQRqtOsxD1XHJSVJ3MH8RJhnmKrwDXpoYNZ4jj8f4d9T 9wJf2wuCF1I1qer9vyfYwNVC5AHPsTYu1gNTBty9V7vqGYTYHxkwovunLvzIUW/33ebAL673xi/ EayiYoAbq01ndrNihk0o6sn0HIPUiLtCvGwFPTEM2DvA== X-Zone-Loop: 18cebf876a10915a7bcfecb2c42a0f6bd638fe9d6436 x-campaign-type: default x-transaction-id: 5161c42c-a3d7-4903-addd-10705e8612ac x-swg-uid: 01-cc6aca94-5c1b-480e-9e57-b03ac945f3df X-Mailer: Sweego Message-ID: <1789130863.8631fc262581453bbf619ec5b2062170.1a09082744e000c4f3@vates.tech> x-swg-bid: 1789130863.8631fc262581453bbf619ec5b2062170.1a09082744e000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Julian Vetter Subject: [PATCH v5 4/6] xen/arm: remove XEN_DOMCTL_CONFIG_GIC_NATIVE from the ABI Date: Fri, 11 Sep 2026 14:47:34 +0200 In-Reply-To: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.b5.3ccc6b8d5b09d419.1a0908271e9.ca25eca4288c8cfc=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789130863081 X-purgate-ID: tlsNG-c1860d/1789130884-CC97287B-6445FDFD/0/0 X-purgate-type: clean X-purgate-size: 8032 ---=Part.b5.3ccc6b8d5b09d419.1a0908271e9.ca25eca4288c8cfc=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Now that the toolstack always resolves a concrete GIC_V2 or GIC_V3 before calling createdomain, nothing on the Xen side needs to resolve GIC_NATIVE either: * A new gic_domctl_hw_version() helper returns the XEN_DOMCTL_CONFIG_GIC_* value matching the host's gic_hw_version()=2E * arch_sanitise_domain_config() uses it to validate the requested version against the hardware, rather than resolving GIC_NATIVE and writing the result back into config->arch=2Egic_version=2E A guest must use the host's GIC version, except that a GICv3 host with the GICv2 compatibility mode enabled may also run GICv2 guests=2E This is the same information that XEN_SYSCTL_physinfo reports to the toolstack=2E * create_dom0() and arch_parse_dom0less_node(), which both always want a vGIC that exactly matches the hardware, use the same helper instead of GIC_NATIVE=2E With nothing left resolving or relying on it, drop XEN_DOMCTL_CONFIG_GIC_NATIVE from the public ABI=2E Every caller must now request a concrete GIC_V2 or GIC_V3=2E This is an incompatible change for any toolstack still passing 0 (formerly GIC_NATIVE) expecting Xen to auto-select a version=2E Add a CHANGELOG=2Emd entry, noting that available GIC versions can be queried via XEN_SYSCTL_physinfo=2E Signed-off-by: Julian Vetter --- Changes in v5: - Rename gic_domctl_version() to gic_domctl_hw_version() - Accept a GICv2 guest on a GICv3 host with GICv2 compatibility mode enabled, instead of requiring an exact match with the host GIC version --- CHANGELOG=2Emd | 4 ++++ xen/arch/arm/dom0less-build=2Ec | 3 ++- xen/arch/arm/domain=2Ec | 27 +++++++++++---------------- xen/arch/arm/domain_build=2Ec | 3 ++- xen/arch/arm/gic=2Ec | 16 ++++++++++++++++ xen/arch/arm/include/asm/gic=2Eh | 6 ++++++ xen/include/public/arch-arm=2Eh | 2 +- 7 files changed, 42 insertions(+), 19 deletions(-) diff --git a/CHANGELOG=2Emd b/CHANGELOG=2Emd index aa1a777dd4=2E=2E78d1b13f3f 100644 --- a/CHANGELOG=2Emd +++ b/CHANGELOG=2Emd @@ -18,6 +18,10 @@ The format is based on [Keep a Changelog](https://keepa= changelog=2Ecom/en/1=2E0=2E0/) ### Added =20 ### Removed + - On Arm: + - XEN_DOMCTL_CONFIG_GIC_NATIVE has been removed=2E Toolstacks must now + explicitly request GIC_V2 or GIC_V3 when creating a domain=2E + Available GIC versions can be queried via XEN_SYSCTL_physinfo=2E - On x86: - The kexec "v1" interface, which was declared obsolete in Xen 4=2E4 (= 2013)=2E The only known user was the classic-xen fork of Linux=2E This does = not diff --git a/xen/arch/arm/dom0less-build=2Ec b/xen/arch/arm/dom0less-build= =2Ec index 3f48f74226=2E=2E7bbb2eafb6 100644 --- a/xen/arch/arm/dom0less-build=2Ec +++ b/xen/arch/arm/dom0less-build=2Ec @@ -23,6 +23,7 @@ #include #include #include +#include #include #include =20 @@ -368,7 +369,7 @@ int __init arch_parse_dom0less_node(struct dt_device_n= ode *node, unsigned int flags =3D bd->create_flags; uint32_t val; =20 - d_cfg->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE; + d_cfg->arch=2Egic_version =3D gic_domctl_hw_version(); d_cfg->flags |=3D XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; =20 if ( domu_dt_sci_parse(node, d_cfg) ) diff --git a/xen/arch/arm/domain=2Ec b/xen/arch/arm/domain=2Ec index a739dd157e=2E=2E6f5f92876e 100644 --- a/xen/arch/arm/domain=2Ec +++ b/xen/arch/arm/domain=2Ec @@ -609,23 +609,18 @@ int arch_sanitise_domain_config(struct xen_domctl_cr= eatedomain *config) return -EINVAL; } =20 - /* Fill in the native GIC version, passed back to the toolstack=2E */ - if ( config->arch=2Egic_version =3D=3D XEN_DOMCTL_CONFIG_GIC_NATIVE ) + /* + * A guest can only use the host's GIC version, except that a GICv3 h= ost + * with the GICv2 compatibility mode enabled can also run GICv2 guest= s=2E + * This mirrors what XEN_SYSCTL_physinfo reports to the toolstack=2E + */ + if ( config->arch=2Egic_version !=3D gic_domctl_hw_version() && + !(config->arch=2Egic_version =3D=3D XEN_DOMCTL_CONFIG_GIC_V2 && + vgic_v2_hw_enabled()) ) { - switch ( gic_hw_version() ) - { - case GIC_V2: - config->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V2; - break; - - case GIC_V3: - config->arch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_V3; - break; - - default: - ASSERT_UNREACHABLE(); - return -EINVAL; - } + dprintk(XENLOG_INFO, "Unsupported GIC version %u\n", + config->arch=2Egic_version); + return -EINVAL; } =20 /* max_vcpus depends on the GIC version, and Xen's compiled limit=2E = */ diff --git a/xen/arch/arm/domain_build=2Ec b/xen/arch/arm/domain_build=2Ec index 72d5316180=2E=2Ecf7e1100bd 100644 --- a/xen/arch/arm/domain_build=2Ec +++ b/xen/arch/arm/domain_build=2Ec @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -1960,7 +1961,7 @@ void __init create_dom0(void) int rc; =20 /* The vGIC for DOM0 is exactly emulating the hardware GIC */ - dom0_cfg=2Earch=2Egic_version =3D XEN_DOMCTL_CONFIG_GIC_NATIVE; + dom0_cfg=2Earch=2Egic_version =3D gic_domctl_hw_version(); dom0_cfg=2Earch=2Enr_spis =3D vgic_def_nr_spis(); dom0_cfg=2Earch=2Etee_type =3D tee_get_type(); dom0_cfg=2Emax_vcpus =3D dom0_max_vcpus(); diff --git a/xen/arch/arm/gic=2Ec b/xen/arch/arm/gic=2Ec index 078049e741=2E=2E997b6ee6ed 100644 --- a/xen/arch/arm/gic=2Ec +++ b/xen/arch/arm/gic=2Ec @@ -56,6 +56,22 @@ enum gic_version gic_hw_version(void) return gic_hw_ops->info->hw_version; } =20 +uint8_t gic_domctl_hw_version(void) +{ + switch ( gic_hw_version() ) + { + case GIC_V2: + return XEN_DOMCTL_CONFIG_GIC_V2; + + case GIC_V3: + return XEN_DOMCTL_CONFIG_GIC_V3; + + default: + ASSERT_UNREACHABLE(); + return 0; + } +} + unsigned int gic_number_lines(void) { return gic_hw_ops->info->nr_lines; diff --git a/xen/arch/arm/include/asm/gic=2Eh b/xen/arch/arm/include/asm/g= ic=2Eh index ee2c26adb4=2E=2E434b888e69 100644 --- a/xen/arch/arm/include/asm/gic=2Eh +++ b/xen/arch/arm/include/asm/gic=2Eh @@ -262,6 +262,12 @@ DECLARE_PER_CPU(uint64_t, lr_mask); =20 extern enum gic_version gic_hw_version(void); =20 +/* + * The XEN_DOMCTL_CONFIG_GIC_* value matching the GIC version actually + * present on this host=2E + */ +extern uint8_t gic_domctl_hw_version(void); + /* Program the IRQ type into the GIC */ void gic_set_irq_type(struct irq_desc *desc, unsigned int type); =20 diff --git a/xen/include/public/arch-arm=2Eh b/xen/include/public/arch-arm= =2Eh index 00de30b896=2E=2E9d3bf11cbd 100644 --- a/xen/include/public/arch-arm=2Eh +++ b/xen/include/public/arch-arm=2Eh @@ -319,7 +319,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); * struct xen_arch_domainconfig's ABI is covered by * XEN_DOMCTL_INTERFACE_VERSION=2E */ -#define XEN_DOMCTL_CONFIG_GIC_NATIVE 0 +/* XEN_DOMCTL_CONFIG_GIC_NATIVE 0 - removed in Xen 4=2E23 */ #define XEN_DOMCTL_CONFIG_GIC_V2 1 #define XEN_DOMCTL_CONFIG_GIC_V3 2 =20 --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.b5.3ccc6b8d5b09d419.1a0908271e9.ca25eca4288c8cfc=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:48:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:48:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416566.1645558 (Exim 4.92) (envelope-from ) id 1x50fq-0005K3-NJ; Fri, 11 Sep 2026 12:48:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416566.1645558; Fri, 11 Sep 2026 12:48:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fq-0005Jw-K3; Fri, 11 Sep 2026 12:48:10 +0000 Received: by outflank-mailman (input) for mailman id 1416566; Fri, 11 Sep 2026 12:48:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fp-0005Ho-07 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:48:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50fo-003mHJ-Cz for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:48:08 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f880-8faa-0a2a0a5109dd-0a2a4503a8fe-30 for ; Fri, 11 Sep 2026 14:48:08 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f887-fae8-0a2a45030019-b9ff1c228c1f-3 for ; Fri, 11 Sep 2026 14:48:08 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0908275e9000c4f3.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 12:47:44 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 5E9CA81E4A; Fri, 11 Sep 2026 14:47:43 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=e63R22GnWuCkoRCDuBwl1UbdkbLnvthe1GGv5qc8yeY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=O8RPO7Y9bDH1z0REYTvpNlDaZ6ZIZpHN9X2le3qBzyUKjaq+iwuduSOBrv8oiPsANPVhYMAuR D0iyqA1hXYMNTgGgjvHajI/f2j8lnjOLEvtqEySRvjcLNLNgxlPGO2eeo0gGU4iXSrbUEB3HUk4 ywCoTjPXKWT+/KwT8lY8ZQV57A3vy7eL4i3L9dRLeO3EgXTxkydgt1rYhbJjPRQEoW/KJkY8oVn snXBEuwcTAyFaDncGrsdJ+cPUYkSPq+Nq2kf7R45WFY4UH8Uwwm1ZC0zqxfWV38FK9V1Bbb0Th8 I7qu+icrV9nHBOYaC65F4BnXm2g1J/s0HWzYjDkalQjA== X-Zone-Loop: dbabf15597bf0f1b03989ea4fb9095ef3b6a7138c8ce x-campaign-type: default x-transaction-id: 8f6e74c2-9dcb-4c11-9c27-f0f2c2c37ab9 x-swg-uid: 01-1b89235f-4f94-4f3c-b9fe-0516b47c83f8 X-Mailer: Sweego Message-ID: <1789130864.8631fc262581453bbf619ec5b2062170.1a0908275e9000c4f3@vates.tech> x-swg-bid: 1789130864.8631fc262581453bbf619ec5b2062170.1a0908275e9000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Julian Vetter Subject: [PATCH v5 5/6] xen/arm: report clock_frequency via sysctl physinfo, not createdomain Date: Fri, 11 Sep 2026 14:47:35 +0200 In-Reply-To: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.b6.4d0d4fd336db1aff.1a09082744a.3ae593f4d687c111=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789130863690 X-purgate-ID: tlsNG-33051d/1789130888-766FB4E9-C27AEC19/0/0 X-purgate-type: clean X-purgate-size: 16977 ---=Part.b6.4d0d4fd336db1aff.1a09082744a.3ae593f4d687c111=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The xen_arch_domainconfig=2Eclock_frequency value is populated in domain_vtimer_init() during XEN_DOMCTL_createdomain from the global timer_dt_clock_frequency, which comes from the host's DT timer node and has nothing to do with the domain being created=2E Like now removed GIC_NATIVE resolution, this is a host-wide system property being smuggled out through a domain-creation IN struct=2E Expose it instead as a new arch_clock_frequency_hz field in XEN_SYSCTL_physinfo, populated via arch_do_physinfo(), and mirroring how the GIC capability bits were already moved there=2E Rather than making the field dependant on DT boot, make Xen always report the timer frequency, either via the DT "clock-frequency" node, or directly via CNTFRQ_EL0=2E preinit_xen_time() already computes cpu_khz for every boot path=2E The renamed timer_clock_frequency_hz now captures whichever of the two produced that value, in full Hz precision, instead of only recording the DT case=2E So, ACPI guests get a real value too, allowing to drop the special case=2E The DT "clock-frequency" property exists because firmware might leave CNTFRQ_EL0 wrong, and since CNTFRQ_EL0 cannot be trapped the only fix is to replicate the correct value into the guest DT=2E To keep that signal, a new XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ capability bit records whether arch_clock_frequency_hz came from the DT property=2E Then libxl only emits a "clock-frequency" property into the guest timer node when that bit is set=2E A guest whose CNTFRQ_EL0 is already correct keeps an unmodified timer node, exactly as before=2E Although the CNTFRQ_EL0 register is 64 bits wide, and some current timer implementations run at 1GHz, a 32bit value is sufficient to store the timer value, because it only mirrors the DT 'clock-frequency' property, which the bindings define as a single 32-bit cell=2E In struct xen_sysctl_physinfo the new field just reuses the former pad word, so sysctl consumers are unaffected=2E struct xen_arch_domainconfig however loses clock_frequency from its middle, which shrinks the struct and shifts every field after it, so bump XEN_DOMCTL_INTERFACE_VERSION=2E The xen_arch_domainconfig parameter passed to domain_vtimer_init() is no longer needed, so drop that parameter entirely=2E libxl now fetches the frequency via libxl_get_physinfo() in libxl__arch_domain_save_config() instead of reading it back out of the createdomain reply=2E The OCaml xen_arch_domainconfig mirror drops the field too=2E Signed-off-by: Julian Vetter --- Changes in v5: - Bump XEN_DOMCTL_INTERFACE_VERSION: removing clock_frequency shrinks and shifts struct xen_arch_domainconfig - Add XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ (with an arch_capabilities_arm_timer_dt_freq() helper) so libxl emits a guest DT "clock-frequency" only when the value came from the host DT - Reword the arch_clock_frequency_hz comment: 0 now only means non-ARM --- =2E=2E=2E/include/xen-tools/arm-arch-capabilities=2Eh | 10 +++++++++ tools/libs/light/libxl=2Ec | 1 + tools/libs/light/libxl_arm=2Ec | 21 ++++++++++++++++++- tools/libs/light/libxl_types=2Eidl | 1 + tools/ocaml/libs/xc/xenctrl=2Eml | 1 - tools/ocaml/libs/xc/xenctrl=2Emli | 1 - xen/arch/arm/domain=2Ec | 2 +- xen/arch/arm/include/asm/time=2Eh | 7 ++++--- xen/arch/arm/include/asm/vtimer=2Eh | 3 +-- xen/arch/arm/sysctl=2Ec | 5 +++++ xen/arch/arm/time=2Ec | 9 +++++--- xen/arch/arm/vtimer=2Ec | 4 +--- xen/include/public/arch-arm=2Eh | 16 +------------- xen/include/public/domctl=2Eh | 4 ++-- xen/include/public/sysctl=2Eh | 20 +++++++++++++++++- 15 files changed, 72 insertions(+), 33 deletions(-) diff --git a/tools/include/xen-tools/arm-arch-capabilities=2Eh b/tools/inc= lude/xen-tools/arm-arch-capabilities=2Eh index 21e3c73bd1=2E=2Ea927bc4703 100644 --- a/tools/include/xen-tools/arm-arch-capabilities=2Eh +++ b/tools/include/xen-tools/arm-arch-capabilities=2Eh @@ -46,4 +46,14 @@ bool arch_capabilities_arm_gic_v3(unsigned int arch_cap= abilities) #endif } =20 +static inline +bool arch_capabilities_arm_timer_dt_freq(unsigned int arch_capabilities) +{ +#if defined(__arm__) || defined(__aarch64__) + return MASK_EXTR(arch_capabilities, XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_F= REQ); +#else + return false; +#endif +} + #endif /* ARM_ARCH_CAPABILITIES_H */ diff --git a/tools/libs/light/libxl=2Ec b/tools/libs/light/libxl=2Ec index a1fe16274d=2E=2Eec7e6d3f65 100644 --- a/tools/libs/light/libxl=2Ec +++ b/tools/libs/light/libxl=2Ec @@ -410,6 +410,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo = *physinfo) physinfo->cap_gnttab_v2 =3D !!(xcphysinfo=2Ecapabilities & XEN_SYSCTL_PHYSCAP_gnttab_v2); physinfo->arch_capabilities =3D xcphysinfo=2Earch_capabilities; + physinfo->arch_clock_frequency_hz =3D xcphysinfo=2Earch_clock_frequen= cy_hz; =20 GC_FREE; return 0; diff --git a/tools/libs/light/libxl_arm=2Ec b/tools/libs/light/libxl_arm= =2Ec index 283cfb749b=2E=2E3d232040c9 100644 --- a/tools/libs/light/libxl_arm=2Ec +++ b/tools/libs/light/libxl_arm=2Ec @@ -252,6 +252,9 @@ int libxl__arch_domain_save_config(libxl__gc *gc, libxl__domain_build_state *state, const struct xen_domctl_createdomain *= config) { + libxl_physinfo info; + int rc; + switch (config->arch=2Egic_version) { case XEN_DOMCTL_CONFIG_GIC_V2: d_config->b_info=2Earch_arm=2Egic_version =3D LIBXL_GIC_VERSION_V= 2; @@ -264,7 +267,23 @@ int libxl__arch_domain_save_config(libxl__gc *gc, return ERROR_FAIL; } =20 - state->clock_frequency =3D config->arch=2Eclock_frequency; + libxl_physinfo_init(&info); + rc =3D libxl_get_physinfo(CTX, &info); + if (rc) { + LOG(ERROR, "failed to get physinfo"); + libxl_physinfo_dispose(&info); + return ERROR_FAIL; + } + /* + * Pass the timer frequency on to the guest DT only when Xen took it = from + * the host DT (XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ)=2E Otherwise th= e guest + * gets the right value from CNTFRQ_EL0=2E + */ + if (arch_capabilities_arm_timer_dt_freq(info=2Earch_capabilities)) + state->clock_frequency =3D info=2Earch_clock_frequency_hz; + else + state->clock_frequency =3D 0; + libxl_physinfo_dispose(&info); =20 return 0; } diff --git a/tools/libs/light/libxl_types=2Eidl b/tools/libs/light/libxl_t= ypes=2Eidl index 8699ab3013=2E=2Ee2e4be7323 100644 --- a/tools/libs/light/libxl_types=2Eidl +++ b/tools/libs/light/libxl_types=2Eidl @@ -1201,6 +1201,7 @@ libxl_physinfo =3D Struct("physinfo", [ ("cap_gnttab_v1", bool), ("cap_gnttab_v2", bool), ("arch_capabilities", uint32), + ("arch_clock_frequency_hz", uint32), # ARM only ], dir=3DDIR_OUT) =20 libxl_connectorinfo =3D Struct("connectorinfo", [ diff --git a/tools/ocaml/libs/xc/xenctrl=2Eml b/tools/ocaml/libs/xc/xenctr= l=2Eml index 147afa62c2=2E=2E582897af6d 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Eml +++ b/tools/ocaml/libs/xc/xenctrl=2Eml @@ -32,7 +32,6 @@ type xen_arm_arch_domainconfig =3D { gic_version: int; nr_spis: int; - clock_frequency: int32; } =20 type x86_arch_emulation_flags =3D diff --git a/tools/ocaml/libs/xc/xenctrl=2Emli b/tools/ocaml/libs/xc/xenct= rl=2Emli index 9fccb2c2c2=2E=2E9414b87164 100644 --- a/tools/ocaml/libs/xc/xenctrl=2Emli +++ b/tools/ocaml/libs/xc/xenctrl=2Emli @@ -26,7 +26,6 @@ type vcpuinfo =3D { type xen_arm_arch_domainconfig =3D { gic_version: int; nr_spis: int; - clock_frequency: int32; } =20 type x86_arch_emulation_flags =3D diff --git a/xen/arch/arm/domain=2Ec b/xen/arch/arm/domain=2Ec index 6f5f92876e=2E=2Ed4037c402a 100644 --- a/xen/arch/arm/domain=2Ec +++ b/xen/arch/arm/domain=2Ec @@ -713,7 +713,7 @@ int arch_domain_create(struct domain *d, if ( (rc =3D domain_vgic_init(d, config->arch=2Enr_spis)) !=3D 0 ) goto fail; =20 - if ( (rc =3D domain_vtimer_init(d, &config->arch)) !=3D 0 ) + if ( (rc =3D domain_vtimer_init(d)) !=3D 0 ) goto fail; =20 if ( (rc =3D tee_domain_init(d, config->arch=2Etee_type)) !=3D 0 ) diff --git a/xen/arch/arm/include/asm/time=2Eh b/xen/arch/arm/include/asm/= time=2Eh index c194dbb9f5=2E=2Efd79dd31eb 100644 --- a/xen/arch/arm/include/asm/time=2Eh +++ b/xen/arch/arm/include/asm/time=2Eh @@ -87,10 +87,11 @@ enum timer_ppi }; =20 /* - * Value of "clock-frequency" in the DT timer node if present=2E - * 0 means the property doesn't exist=2E + * The timer frequency, in Hz, that Xen ended up using, and whether it ca= me + * from the DT "clock-frequency" property rather than CNTFRQ_EL0=2E */ -extern uint32_t timer_dt_clock_frequency; +extern uint32_t timer_clock_frequency_hz; +extern bool timer_clock_frequency_from_dt; =20 /* Get one of the timer IRQ number */ unsigned int timer_get_irq(enum timer_ppi ppi); diff --git a/xen/arch/arm/include/asm/vtimer=2Eh b/xen/arch/arm/include/as= m/vtimer=2Eh index 9d4fb4c6e8=2E=2E6bbfcf4e69 100644 --- a/xen/arch/arm/include/asm/vtimer=2Eh +++ b/xen/arch/arm/include/asm/vtimer=2Eh @@ -20,8 +20,7 @@ #ifndef __ARCH_ARM_VTIMER_H__ #define __ARCH_ARM_VTIMER_H__ =20 -extern int domain_vtimer_init(struct domain *d, - struct xen_arch_domainconfig *config); +extern int domain_vtimer_init(struct domain *d); extern int vcpu_vtimer_init(struct vcpu *v); extern bool vtimer_emulate(struct cpu_user_regs *regs, union hsr hsr); extern void virt_timer_save(struct vcpu *v); diff --git a/xen/arch/arm/sysctl=2Ec b/xen/arch/arm/sysctl=2Ec index 8411deb7e2=2E=2Ee22d2fb613 100644 --- a/xen/arch/arm/sysctl=2Ec +++ b/xen/arch/arm/sysctl=2Ec @@ -15,6 +15,7 @@ =20 #include #include +#include #include =20 #include @@ -26,6 +27,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi) pi->arch_capabilities |=3D MASK_INSR(sve_encode_vl(get_sys_vl_len()), XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK); =20 + pi->arch_clock_frequency_hz =3D timer_clock_frequency_hz; + if ( timer_clock_frequency_from_dt ) + pi->arch_capabilities |=3D XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ; + /* * The GIC version(s) we're happy creating guests with=2E Right now f= or * simplicity it is tied to the active hardware version, but this wil= l diff --git a/xen/arch/arm/time=2Ec b/xen/arch/arm/time=2Ec index be54b87438=2E=2E438a27825d 100644 --- a/xen/arch/arm/time=2Ec +++ b/xen/arch/arm/time=2Ec @@ -35,7 +35,8 @@ uint64_t __read_mostly boot_count; * register-mapped time source in the SoC=2E */ unsigned long __read_mostly cpu_khz; /* CPU clock frequency in kHz=2E */ =20 -uint32_t __read_mostly timer_dt_clock_frequency; +uint32_t __read_mostly timer_clock_frequency_hz; +bool __read_mostly timer_clock_frequency_from_dt; =20 static unsigned int timer_irq[MAX_TIMER_PPI]; =20 @@ -120,7 +121,8 @@ static void __init preinit_dt_xen_time(void) { cpu_khz =3D DIV_ROUND(rate, 1000); validate_timer_frequency(); - timer_dt_clock_frequency =3D rate; + timer_clock_frequency_hz =3D rate; + timer_clock_frequency_from_dt =3D true; } } =20 @@ -136,7 +138,8 @@ void __init preinit_xen_time(void) =20 if ( !cpu_khz ) { - cpu_khz =3D DIV_ROUND(READ_SYSREG(CNTFRQ_EL0) & CNTFRQ_MASK, 1000= ); + timer_clock_frequency_hz =3D READ_SYSREG(CNTFRQ_EL0) & CNTFRQ_MAS= K; + cpu_khz =3D DIV_ROUND(timer_clock_frequency_hz, 1000); validate_timer_frequency(); } =20 diff --git a/xen/arch/arm/vtimer=2Ec b/xen/arch/arm/vtimer=2Ec index 2e85ff2b6e=2E=2E18f5676158 100644 --- a/xen/arch/arm/vtimer=2Ec +++ b/xen/arch/arm/vtimer=2Ec @@ -52,7 +52,7 @@ static void virt_timer_expired(void *data) perfc_incr(vtimer_virt_inject); } =20 -int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *co= nfig) +int domain_vtimer_init(struct domain *d) { d->arch=2Evirt_timer_base=2Eoffset =3D get_cycles(); d->arch=2Evirt_timer_base=2Enanoseconds =3D @@ -60,8 +60,6 @@ int domain_vtimer_init(struct domain *d, struct xen_arch= _domainconfig *config) d->time_offset=2Eseconds =3D d->arch=2Evirt_timer_base=2Enanoseconds; do_div(d->time_offset=2Eseconds, 1000000000); =20 - config->clock_frequency =3D timer_dt_clock_frequency; - /* * Per the ACPI specification, providing a secure EL1 timer * interrupt is optional and will be ignored by non-secure OS=2E diff --git a/xen/include/public/arch-arm=2Eh b/xen/include/public/arch-arm= =2Eh index 9d3bf11cbd=2E=2E5d15f572c7 100644 --- a/xen/include/public/arch-arm=2Eh +++ b/xen/include/public/arch-arm=2Eh @@ -335,7 +335,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_VMSA 2 =20 struct xen_arch_domainconfig { - /* IN/OUT */ + /* IN */ uint8_t gic_version; /* IN - Contains SVE vector length divided by 128 */ uint8_t sve_vl; @@ -343,20 +343,6 @@ struct xen_arch_domainconfig { uint16_t tee_type; /* IN */ uint32_t nr_spis; - /* - * OUT - * Based on the property clock-frequency in the DT timer node=2E - * The property may be present when the bootloader/firmware doesn't - * set correctly CNTFRQ which hold the timer frequency=2E - * - * As it's not possible to trap this register, we have to replicate - * the value in the guest DT=2E - * - * =3D 0 =3D> property not present - * > 0 =3D> Value of the property - * - */ - uint32_t clock_frequency; /* IN */ uint8_t arm_sci_type; /* IN */ diff --git a/xen/include/public/domctl=2Eh b/xen/include/public/domctl=2Eh index 510300bb67=2E=2E4ca8a2d7ca 100644 --- a/xen/include/public/domctl=2Eh +++ b/xen/include/public/domctl=2Eh @@ -30,9 +30,9 @@ * fields) don't require a change of the version=2E * Stable ops are NOT covered by XEN_DOMCTL_INTERFACE_VERSION! * - * Last version bump: Xen 4=2E22 + * Last version bump: Xen 4=2E23 */ -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000018 +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000019 =20 /* * NB=2E xen_domctl=2Edomain is an IN/OUT parameter for this operation=2E diff --git a/xen/include/public/sysctl=2Eh b/xen/include/public/sysctl=2Eh index d20ebf3644=2E=2E8356032e13 100644 --- a/xen/include/public/sysctl=2Eh +++ b/xen/include/public/sysctl=2Eh @@ -108,6 +108,8 @@ struct xen_sysctl_tbuf_op { #define XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK (0x1FU) #define XEN_SYSCTL_PHYSCAP_ARM_GIC_V2 (1U << 5) #define XEN_SYSCTL_PHYSCAP_ARM_GIC_V3 (1U << 6) +/* See arch_clock_frequency_hz in struct xen_sysctl_physinfo=2E */ +#define XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ (1U << 7) #endif =20 struct xen_sysctl_physinfo { @@ -120,7 +122,23 @@ struct xen_sysctl_physinfo { uint32_t cpu_khz; uint32_t capabilities;/* XEN_SYSCTL_PHYSCAP_??? */ uint32_t arch_capabilities;/* XEN_SYSCTL_PHYSCAP_{X86,ARM,=2E=2E=2E}_= ??? */ - uint32_t pad; + + /* + * ARM only=2E The timer frequency, in Hz, that Xen is using, taken e= ither + * from the host DT timer node's "clock-frequency" property or from a + * direct CNTFRQ_EL0 read=2E + * + * XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ is set in the former case=2E = The host + * DT overrides CNTFRQ_EL0 (the usual way a wrong bootloader/firmware= value + * is corrected), so the toolstack must carry the same override into = the + * guest's timer node, since CNTFRQ_EL0 cannot be trapped and fixed u= p per + * guest=2E + * + * =3D 0 =3D> Non-ARM=2E On ARM the frequency is validated at boot an= d is + * always non-zero=2E + * > 0 =3D> The frequency, in Hz=2E + */ + uint32_t arch_clock_frequency_hz; uint64_aligned_t total_pages; uint64_aligned_t free_pages; uint64_aligned_t scrub_pages; --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.b6.4d0d4fd336db1aff.1a09082744a.3ae593f4d687c111=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:48:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:48:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416567.1645565 (Exim 4.92) (envelope-from ) id 1x50fr-0005R6-B9; Fri, 11 Sep 2026 12:48:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416567.1645565; Fri, 11 Sep 2026 12:48:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fr-0005Pp-4K; Fri, 11 Sep 2026 12:48:11 +0000 Received: by outflank-mailman (input) for mailman id 1416567; Fri, 11 Sep 2026 12:48:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fp-0005Im-SB for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:48:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50fp-003mHJ-5Q for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:48:09 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f880-8faa-0a2a0a5109dd-0a2a4503a8fe-34 for ; Fri, 11 Sep 2026 14:48:09 +0200 Received: from [40.107.201.12] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f887-fae8-0a2a45030019-286bc90c0d98-3 for ; Fri, 11 Sep 2026 14:48:08 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS2PR03MB440844.namprd03.prod.outlook.com (2603:10b6:8:3c5::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.10; Fri, 11 Sep 2026 12:48:05 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 12:48:04 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sxivP/U0APtbjrHUFetUhLjfKWpCXnQ6sa/Z5Ve9oyLEoUgf3abFVafXKIlBQKBcbSXxehfCcoQyU4Fe1+XSGtR2UfhYHEqmh42LPZ2F/ITPSW0lyMbIRPw0hBESOaICT8ldFxGDmenvYHooskQa1drWVZ6u93DXFsoxpAxTul2fU/blP2S5n8arFKaoarVrHRue/fh1Y1YAQdBYgQj7mleFmMiL9k/9I9bdEix18C/3S6lswO3wx5zoOmkzSEVXJmlFq+qEqP0RhHfVjNY143kLb0N9keUfdJVGtBhBUEcDCCwMFsaPS1vbjF7PztSDZ7StOINqYNPV8b68TTsMqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1zzrzMDVNaplommme8ZBfPAEOi6cAeerkg7aCSHr5Fs=; b=hbnT6LHgaiIMTYHzSpM36XRdB/VA0LqZhtAPjT3l1vswCHl6lnulsg9L8EipUEcqjcTTVwGgeMMty+OMa2y7rve3PKcelpQK+WyUkkZ8RqGCkAPBQkRotWI847hZ+/N8GiOksq9MYur9/aoH4+yCTnYTi9yWr0n7c10HHcD7PZ8Nn6DQoAo8yExIgbSNy7TR2j+UmEXSV+5DtcbvBWVeaW373ieKY2PsNuOsi7RNuCNfEbgXvueOfo1slgGNrEpu4hTsGgnIWaF3EQD+J5Y45YUshZhtUfDMdTmTavE0eQxuGfm5R3fIG87H6dvXu6xIuRk/bOCtIu2ejC67uOok4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1zzrzMDVNaplommme8ZBfPAEOi6cAeerkg7aCSHr5Fs=; b=o5tccPUeLK91JYF9FAJvU+PflheT4nwadjNHbztA/I1SbGh55kYDRUZxPci0i8JvizUawEiVwAYv1lldHQPCMcGWK+56W4DGk+/nbX2fexAaFfmhNpDM3xngfenCZQxKoKKeavqKSxDRo9iCtdnQJSAi37p0J+ILbItwSxtni1w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 11 Sep 2026 13:48:00 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, teddy.astie@vates.tech, Juergen Gross Subject: Re: [PATCH Linux v2 7/7] xen: Add new Xen pv-op pte_get_and_clear. To: Kevin Lampis , xen-devel@lists.xenproject.org References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-8-kevin.lampis@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260910203113.462943-8-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0077.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bd::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS2PR03MB440844:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d91a345-9de1-47cf-647d-08df1002ec0c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|10067099003|6133799003|4143699003|56012099006|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: GH/3KM7w/8pcvx/HwFZ5tjL8uI2vPZ/zVSHgWISxkB2murwgVrkEzo19vveyocCTBAwaMGQE1xehbrB9UOd/OwNYVcBatv0yRaCv6fg7jjpISV1SXN6iY2a0tKPrCvPxWT3CpuT4RCl5706zRtcCWeBWpTZ+wgHZtestr34Zh9pLMaJHbZUNvpC55zifMKlEzOxVeE8ZcDem15j+bp/PUWDHc4lq3Y/bUUr9ygJQhb4Qhro/I+JFl0qgw1vtkArq/vVPHD8gTtFSgDJhQo7FCLEuz0/KMAYYnLHOckOXHHJ4lafwVtBTCbpzZgNPbVATT8twhr7Ml+ZogRbBSIHxsrMW8BTpbkjbn/CBnxtJ72mGt4W/YhvqllUGH5ukOW7GBJeZMdwypEwY8QZN4x3EibA5HLPeRKxZyKrj4qCC/1O8NqbXgwlSQgJqi6XQUMpeULsugVCYQXrSJgMPxZh52StIjIvttYjZhmHgh+VEZlrDWUF86oWSye1qaEsdTIP6Eefko6xVqHu0K2yUwF2XgwKT4wt6pvAlDzfhQpr52eHck3I0nYPQvpvKWf43k1xgM5/iQtaCLSmaSXy9d7R3BM2fA5mZrRtGxBodFbm4qLUR5vMThgpchZseG9RBY5+eGV+v0QD/XMO59/ECDfloYBkPsTVUmhTmtBhmQiSFpw0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(10067099003)(6133799003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bC9yWExEbnIyekRJZ2FDOTFRQ3crM21nRkRmQzVvck42bmV5OEU5b3RLKzhI?= =?utf-8?B?NlJKcXlQWjNHNG9FWmJaY3ZCcTRyT1JCQ0FtQ1c4TjN2L3ZKa2EwMjloWjQw?= =?utf-8?B?c3NIOFk3R3U3QmdrdjYxNEdJK2o1dEpSUlZzRklhZmlBMy9uSVM5aXRqMy9z?= =?utf-8?B?MnFVMXMweVAxN090eEVoalh5emtvaGRxUktIMTUrMnQ4Z0FValFYeHkvaUR6?= =?utf-8?B?TzlORmJ0SWVhNklVQUxDQ0xWNVNiWUplS3JzcDBRZ2o1OFJpT0ZvNk9FMXcr?= =?utf-8?B?RE5LUmNUc28xdGkveUt3dElXN1YxZVFWaTJPenZDdFVRQXpmajJmcXQxU2tp?= =?utf-8?B?eGc0bWM2M2RxcmNtdStjVVJQR0hTRDB6dWc5NWhxbE1lVmZ0T3V4eGZKMEE0?= =?utf-8?B?SmQyeCsxUktXY1NqQ0JFaHJBaWhtS2ZhZWFMYk1mRWNBcWRGTXJiZVRLbFJT?= =?utf-8?B?Nm83aytsOFkzOWtmajEvN2IwWkF6Q3lOM0gzbEpQczVmNVJPQm1qdUtOYzBn?= =?utf-8?B?MS80M1BWTE10MkJSSkZONjl0Ym1CcUlQRVNxU2RVZEpVWUVyb3FsM21LWGgr?= =?utf-8?B?MTRIdmNXM1hncDdTbXBPZExoTi9iTHV1RGRTTGovWVFSL2lMSWlyL1hJYXVE?= =?utf-8?B?OW1CQUloVFVRU3lsNFZwWWxzbzhiYWhvdGpsM3ZZaVNWKzlIWHdiQTVqR1RV?= =?utf-8?B?WjFnZTM1TFhnQWhSTWNGTUpZTDZTRGJnNGFSdWcyaGxlcnBranJObTU2WTgr?= =?utf-8?B?SWhZanV1OEw4QTg5bVVNclM0bmtUM21YNDdYclU0UXBBNWJlanVUTDVHWDNU?= =?utf-8?B?Z2lKQWE0TkhSQkpRZnZqYTFDaU81Ync0ZjBxaHhOS0YzY3dnYS9GY0o1aFNN?= =?utf-8?B?NXZ1Sjgrd0sxWG1iaVVWM28vbEw1OVJ5eHFJa3RTSG5EdUtoY21kU1JxRWp0?= =?utf-8?B?Q01nNXJhQmRQNHFRQm1oazFNQnFEeVQwbHlzODhBZndtYmxNY2JWNENXV3NN?= =?utf-8?B?eS9LYnVJU0hRUGlYMGVnRzkzbU9na3JWMnpRUkhzVXlRZTM0VVJHUjE4eFA2?= =?utf-8?B?czN0RUpHc1hxM1F0bTJwZVBqa3orR2Z6K2sxNzUzdmVlemtUL0NKMUx6MlBQ?= =?utf-8?B?b1BueWtKSTkzelBvbnF6UDlYYzFwMloraEJJU1JQdlhnRU00R3Rpcjk5K0ZG?= =?utf-8?B?Qy9CVm9WVmU0NFp1dHJETG9YYm1sRmdGaUVYQVI3Q0o3L3RkZS9wQk0vL0pC?= =?utf-8?B?T2hTL0Rubk1FbW42N290azQ3WnNJSmt3dDh0eldsb3N0YTBNR3ZLUFRsaUVW?= =?utf-8?B?ZS8rVHRhYWU0UE5KcnBDL1N0V0l6L0xjdTFjU0pha3ZJR3Y1YWdVdGl4RVBy?= =?utf-8?B?N2RVa3cwMmdybkVhQkFoM3JBZVJtMzFKUC9Vc05mTkNRSjA1aDVaU1lLVXBB?= =?utf-8?B?bUpUSFFHM01qTnIwMTYwN3JNVExGditaZ3JmaU91TkozNGoyNHdManpsTm43?= =?utf-8?B?N3NFcHdJMThxdEdPNi9wTWtsRGtYaGVoN1lWZnkxRjlIR0JmUkVMQWxkQURm?= =?utf-8?B?QTN1QnpiSWt2TE5JYlhLSHZkUHdZWjRwZkV1QjVUZXRYdmsvT3QwOGljU09P?= =?utf-8?B?czdNVDB0RU1zZ0t6WjNUbnAxRGU4SmpmQzFkOGVkRmZ3dnZhQURBZnYycG5F?= =?utf-8?B?NnVhMnN1NERDTVlpL3ZtT3Buak9WSmRPT2IyVFNZaW1VdWdvaExzVHg3Szda?= =?utf-8?B?eVFWNlg2ZHUvcXNKYzNwVHBPQS9leU45Z1ZIZXh6d0tLUG1yV2VETmJKMWli?= =?utf-8?B?MDcwckFEQS9kdE0vYllmQ1ZCVFU5TkdqUDNIUDRNbFZXK0ZtM3hvS3c1NG9W?= =?utf-8?B?NnhXNDI2YmJmZENiS0RIeGtTTStrWFVsaFRQeGF1WlBQVzd1alB4TUd4ZjRw?= =?utf-8?B?a1BWNmlwVzFSRHRuZU1rc1draGJNNHRTNVc5T2hxSEFTZFBiM1hoY2hPYWZ4?= =?utf-8?B?MnBQZjJOZHJYOVZDcjJJd3hsbTNCWU5zZUpQWkUrZkQ2YjVHb3BvL0tUc2gr?= =?utf-8?B?NHErN1JHTDV1VUlFeXBvVDRCKzB5QUxIT2w1RE9CSTFkRURzMmM5bVhIOC81?= =?utf-8?B?Tnp6VWh1cjkvQWY5LzNsbEVYV3k5cmUrZlFMdWNmSGpGTVVVdUlTb3k0OHdW?= =?utf-8?B?VkUwSXZKbUZUQktJWG0rbzVKVzBybjFtTytOMU92cFJ6ODR4STAxSFJOaVBz?= =?utf-8?B?cTZjOUN3ZW1tUmZWUlNQeXBrRHg4eWFTSEEzZ3YyNVJDZkpBUlRvVHVrQzFR?= =?utf-8?B?MnVQQWkrN1FHdTBsS1dIYTg0bWNzL0kzeHFManZlQ3NVeExIcFgyQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d91a345-9de1-47cf-647d-08df1002ec0c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 12:48:04.7397 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bbi6FnPlBmKOxK6hItltqhGPlLU/FCdVjSXgC8/uvDN4zceiYWCpy3HErHkDiuF9rFhFPgXkNH3e0gb9T9UXzlheckPObCuHGQps7lhWLgY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR03MB440844 X-purgate-ID: tlsNG-33051d/1789130889-6F8C54E9-D3ACD4DF/0/0 X-purgate-type: clean X-purgate-size: 6205 On 10/09/2026 9:31 pm, Kevin Lampis wrote: > If Xen supports XENFEAT_mmu_pt_update_swap then for performance reasons > call mmu_update with the new MMU_PT_UPDATE_SWAP flag instead of > native_ptep_get_and_clear(). > > Signed-off-by: Kevin Lampis CC Juergen, the Xen maintainer in Linux.  Keeping the whole patch intact. > --- > Changes in v2: > - New patch > --- > arch/x86/include/asm/paravirt.h | 5 +++++ > arch/x86/include/asm/paravirt_types.h | 1 + > arch/x86/include/asm/pgtable.h | 3 ++- > arch/x86/kernel/paravirt.c | 1 + > arch/x86/xen/mmu_pv.c | 15 +++++++++++++++ > include/xen/interface/features.h | 2 ++ > include/xen/interface/xen.h | 1 + > 7 files changed, 27 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h > index 0591aa38fd85..0a3a286c46f0 100644 > --- a/arch/x86/include/asm/paravirt.h > +++ b/arch/x86/include/asm/paravirt.h > @@ -373,6 +373,11 @@ static inline void set_pmd(pmd_t *pmdp, pmd_t pmd) > PVOP_VCALL2(pv_ops, mmu.set_pmd, pmdp, native_pmd_val(pmd)); > } > > +static inline pte_t pte_get_and_clear(pte_t *ptep) > +{ > + return (pte_t){PVOP_CALL1(pte_t, mmu.pte_get_and_clear, ptep)}; > +} > + > static inline pmd_t __pmd(pmdval_t val) > { > return (pmd_t) { PVOP_ALT_CALLEE1(pmdval_t, pv_ops, mmu.make_pmd, val, > diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h > index b4c4a23e77a1..1bd4c19450b5 100644 > --- a/arch/x86/include/asm/paravirt_types.h > +++ b/arch/x86/include/asm/paravirt_types.h > @@ -135,6 +135,7 @@ struct pv_mmu_ops { > /* Pagetable manipulation functions */ > void (*set_pte)(pte_t *ptep, pte_t pteval); > void (*set_pmd)(pmd_t *pmdp, pmd_t pmdval); > + pte_t (*pte_get_and_clear)(pte_t *ptep); > > pte_t (*ptep_modify_prot_start)(struct vm_area_struct *vma, unsigned long addr, > pte_t *ptep); > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h > index ac295ca6c92f..b0d7d6520984 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -58,6 +58,7 @@ extern pmdval_t early_pmd_flags; > #include > #else /* !CONFIG_PARAVIRT_XXL */ > #define set_pte(ptep, pte) native_set_pte(ptep, pte) > +#define pte_get_and_clear(ptep) native_ptep_get_and_clear(ptep) > > #define set_pte_atomic(ptep, pte) \ > native_set_pte_atomic(ptep, pte) > @@ -1243,7 +1244,7 @@ bool ptep_clear_flush_young(struct vm_area_struct *vma, > static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr, > pte_t *ptep) > { > - pte_t pte = native_ptep_get_and_clear(ptep); > ++ pte_t pte = pte_get_and_clear(ptep); This looks like a typo, on a path you didn't compile. > page_table_check_pte_clear(mm, addr, pte); > return pte; > } > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c > index 00b59d774389..58ecd12b10ee 100644 > --- a/arch/x86/kernel/paravirt.c > +++ b/arch/x86/kernel/paravirt.c > @@ -178,6 +178,7 @@ struct paravirt_patch_template pv_ops = { > > .mmu.set_pte = native_set_pte, > .mmu.set_pmd = native_set_pmd, > + .mmu.pte_get_and_clear = native_ptep_get_and_clear, > > .mmu.ptep_modify_prot_start = __ptep_modify_prot_start, > .mmu.ptep_modify_prot_commit = __ptep_modify_prot_commit, > diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c > index 820af6f0aa57..7ce2feab6434 100644 > --- a/arch/x86/xen/mmu_pv.c > +++ b/arch/x86/xen/mmu_pv.c > @@ -359,6 +359,15 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) > __xen_set_pte(ptep, pteval); > } > > +static pte_t xen_pte_get_and_clear(pte_t *ptep) > +{ > + struct mmu_update u; > + u.ptr = virt_to_machine(ptep).maddr | MMU_PT_UPDATE_SWAP; > + u.val = pte_val_ma(native_make_pte(0)); > + HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF); > + return native_make_pte(u.val); > +} This wants some reformatting, and blank lines for clarity.     struct mmu_update u = {         .ptr = virt_to_machine(ptep).maddr | MMU_PT_UPDATE_SWAP,         .val = pte_val_ma(native_make_pte(0));     };     BUG_ON(HYPERVISOR_mmu_update(&u, 1, NULL, DOMID_SELF) != 1);     return native_make_pte(u.val); I'm not a fan of the BUG_ON() error handling like this, but there really is no other safe option in this case. > + > static pte_t xen_ptep_modify_prot_start(struct vm_area_struct *vma, > unsigned long addr, pte_t *ptep) > { > @@ -2165,6 +2174,12 @@ static void __init xen_post_allocator_init(void) > pv_ops.mmu.set_pud = xen_set_pud; > pv_ops.mmu.set_p4d = xen_set_p4d; > > + if (xen_feature(XENFEAT_mmu_pt_update_swap)) > + pv_ops.mmu.pte_get_and_clear = xen_pte_get_and_clear; > + else > + pv_ops.mmu.pte_get_and_clear = native_ptep_get_and_clear; > + > + Stray blank line. ~Andrew > /* This will work as long as patching hasn't happened yet > (which it hasn't) */ > pv_ops.mmu.alloc_pte = xen_alloc_pte; > diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h > index 53f760378e39..b346d58c0a41 100644 > --- a/include/xen/interface/features.h > +++ b/include/xen/interface/features.h > @@ -97,6 +97,8 @@ > #define XENFEAT_not_direct_mapped 16 > #define XENFEAT_direct_mapped 17 > > +#define XENFEAT_mmu_pt_update_swap 21 > + > #define XENFEAT_NR_SUBMAPS 1 > > #endif /* __XEN_PUBLIC_FEATURES_H__ */ > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h > index 40c9793e9880..92f972e53323 100644 > --- a/include/xen/interface/xen.h > +++ b/include/xen/interface/xen.h > @@ -252,6 +252,7 @@ > #define MMU_MACHPHYS_UPDATE 1 /* ptr = MA of frame to modify entry for */ > #define MMU_PT_UPDATE_PRESERVE_AD 2 /* atomically: *ptr = val | (*ptr&(A|D)) */ > #define MMU_PT_UPDATE_NO_TRANSLATE 3 /* checked '*ptr = val'. ptr is MA. */ > +#define MMU_PT_UPDATE_SWAP 4 > > /* > * MMU EXTENDED OPERATIONS From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:48:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:48:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416573.1645576 (Exim 4.92) (envelope-from ) id 1x50fy-00066g-GL; Fri, 11 Sep 2026 12:48:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416573.1645576; Fri, 11 Sep 2026 12:48:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fy-00066V-D3; Fri, 11 Sep 2026 12:48:18 +0000 Received: by outflank-mailman (input) for mailman id 1416573; Fri, 11 Sep 2026 12:48:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50fw-0005yo-MI for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:48:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50fw-009G6I-36 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:48:16 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f888-2eae-0a2a0a5409dd-0a2a4505d40a-36 for ; Fri, 11 Sep 2026 14:48:16 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f88f-4cb1-0a2a45050019-b9ff1c128ed1-3 for ; Fri, 11 Sep 2026 14:48:15 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0908277f6000c4f3.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 12:47:44 +0000 Received: from julian.home (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id C669A81CED; Fri, 11 Sep 2026 14:47:43 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=bwq3tKReeS3EIzOUNkZD7o9vflbF8tf5tTJBaX+CqXY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=DofaliK4R8+ApxDtPfcvuHykChD8FlPngblcUTorVBQd0XPjxllHqSy506QrCXcv3Psfuy7Wx UzmFK2M+L6iujE/BcaGJI/4xLmExuqzDdZlf8u3kMa25T2m973SIVTNyYMjY9YUUGi21+EVjrO6 RiGtH7gVPxHCmRYeXap2vJxr91Q2TkonpZkgQp5cEC32BvEDSqlFeA+JWjMQPsveGultVyenr8/ XX5YnI1IKpSjWvja+ddGnnj1RE8ELXe0lHwa7NUZwGxhSyu/izECHOjbHQ0DIWMgzmJWAZri4vD nPPfTaBuNFMPU8LWYHsxpdMN7IjwTFaDMCDbsfqiFtNA== X-Zone-Loop: 84019aec531728e8ea85ba7fa79d01b9f6bf84d68e54 x-campaign-type: default x-transaction-id: b35b5ddd-a065-43ec-80ad-b498bd300587 x-swg-uid: 01-00ba8ebd-f8fe-40ec-9058-7e1b054c491c X-Mailer: Sweego Message-ID: <1789130864.8631fc262581453bbf619ec5b2062170.1a0908277f6000c4f3@vates.tech> x-swg-bid: 1789130864.8631fc262581453bbf619ec5b2062170.1a0908277f6000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie , Julian Vetter Subject: [PATCH v5 6/6] xen: make config argument const Date: Fri, 11 Sep 2026 14:47:36 +0200 In-Reply-To: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.b7.9cd30c3973d2ad73.1a0908275f8.bc0c5a2802185582=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789130864120 X-purgate-ID: tlsNG-c201ff/1789130896-734BC2A1-F9E6E16B/0/0 X-purgate-type: clean X-purgate-size: 8311 ---=Part.b7.9cd30c3973d2ad73.1a0908275f8.bc0c5a2802185582=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable arch_sanitise_domain_config() validates the configuration requested by the toolstack, and should not fill anything in=2E The config struct passed to createdomain is supposed to be pure input=2E ARM used to abuse this (GIC_NATIVE resolution, now removed) to smuggle output back to the toolstack=2E Making the parameter const stops that type of abuse from happening on any architecture=2E The x86 implementation turned out to have its own instance of the same issue=2E It set XEN_DOMCTL_CDF_oos_off into config->flags for non-HVM guests=2E Since The sanitisation runs before the function domain_create() copies config->flags into d->options, this relied on mutating the toolstack's config to take effect=2E Move the default onto d->options directly in arch_domain_create() (which runs after d->options is populated), where all the remaining domain options are resolved=2E This has the same effect and no mutation of the input config is required=2E ARM, PPC and RISC-V need no equivalent change, Their implementations were already read-only=2E Signed-off-by: Julian Vetter Reviewed-by: Jan Beulich # x86 --- Changes in v5: - No changes=2E --- xen/arch/arm/domain=2Ec | 2 +- xen/arch/arm/firmware/sci=2Ec | 2 +- xen/arch/arm/firmware/scmi-smc=2Ec | 2 +- xen/arch/arm/include/asm/firmware/sci=2Eh | 6 +++--- xen/arch/ppc/stubs=2Ec | 2 +- xen/arch/riscv/domain=2Ec | 2 +- xen/arch/x86/domain=2Ec | 16 ++++++++-------- xen/include/xen/sched=2Eh | 5 ++--- 8 files changed, 18 insertions(+), 19 deletions(-) diff --git a/xen/arch/arm/domain=2Ec b/xen/arch/arm/domain=2Ec index d4037c402a=2E=2E3299727d3a 100644 --- a/xen/arch/arm/domain=2Ec +++ b/xen/arch/arm/domain=2Ec @@ -557,7 +557,7 @@ static bool v8r_el1_msa_domain_sanitise_config( } } =20 -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con= fig) { unsigned int max_vcpus; unsigned int flags_required =3D (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_= hap); diff --git a/xen/arch/arm/firmware/sci=2Ec b/xen/arch/arm/firmware/sci=2Ec index aa93cda7f0=2E=2Ef73ed06092 100644 --- a/xen/arch/arm/firmware/sci=2Ec +++ b/xen/arch/arm/firmware/sci=2Ec @@ -45,7 +45,7 @@ int sci_domain_init(struct domain *d, struct xen_domctl_= createdomain *config) return cur_mediator->domain_init(d, config); } =20 -int sci_domain_sanitise_config(struct xen_domctl_createdomain *config) +int sci_domain_sanitise_config(const struct xen_domctl_createdomain *conf= ig) { if ( !cur_mediator ) return 0; diff --git a/xen/arch/arm/firmware/scmi-smc=2Ec b/xen/arch/arm/firmware/sc= mi-smc=2Ec index a0cc6c6192=2E=2E391df8b945 100644 --- a/xen/arch/arm/firmware/scmi-smc=2Ec +++ b/xen/arch/arm/firmware/scmi-smc=2Ec @@ -68,7 +68,7 @@ static bool scmi_handle_smc(struct cpu_user_regs *regs) } =20 static int -scmi_smc_domain_sanitise_config(struct xen_domctl_createdomain *config) +scmi_smc_domain_sanitise_config(const struct xen_domctl_createdomain *con= fig) { if ( config->arch=2Earm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE = && config->arch=2Earm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_= SMC ) diff --git a/xen/arch/arm/include/asm/firmware/sci=2Eh b/xen/arch/arm/incl= ude/asm/firmware/sci=2Eh index 485ce211c9=2E=2E1d566be8e2 100644 --- a/xen/arch/arm/include/asm/firmware/sci=2Eh +++ b/xen/arch/arm/include/asm/firmware/sci=2Eh @@ -32,7 +32,7 @@ struct sci_mediator_ops { * it to sanitize domain SCI configuration parameters=2E * Optional=2E */ - int (*domain_sanitise_config)(struct xen_domctl_createdomain *config)= ; + int (*domain_sanitise_config)(const struct xen_domctl_createdomain *c= onfig); =20 /* * Called during domain destruction, releases all resources, that @@ -101,7 +101,7 @@ int sci_domain_init(struct domain *d, struct xen_domct= l_createdomain *config); * Sanitise domain configuration parameters=2E * */ -int sci_domain_sanitise_config(struct xen_domctl_createdomain *config); +int sci_domain_sanitise_config(const struct xen_domctl_createdomain *conf= ig); =20 /* * Destroy SCI domain instance=2E @@ -162,7 +162,7 @@ static inline int sci_domain_init(struct domain *d, } =20 static inline int -sci_domain_sanitise_config(struct xen_domctl_createdomain *config) +sci_domain_sanitise_config(const struct xen_domctl_createdomain *config) { if ( config->arch=2Earm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE = ) return -EINVAL; diff --git a/xen/arch/ppc/stubs=2Ec b/xen/arch/ppc/stubs=2Ec index a333f06119=2E=2E82a289af85 100644 --- a/xen/arch/ppc/stubs=2Ec +++ b/xen/arch/ppc/stubs=2Ec @@ -162,7 +162,7 @@ void arch_vcpu_destroy(struct vcpu *v) BUG_ON("unimplemented"); } =20 -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con= fig) { BUG_ON("unimplemented"); } diff --git a/xen/arch/riscv/domain=2Ec b/xen/arch/riscv/domain=2Ec index 2819ff4e7c=2E=2Ee096a53cb5 100644 --- a/xen/arch/riscv/domain=2Ec +++ b/xen/arch/riscv/domain=2Ec @@ -289,7 +289,7 @@ void sync_vcpu_execstate(struct vcpu *v) /* Nothing to do -- no lazy switching */ } =20 -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con= fig) { return 0; } diff --git a/xen/arch/x86/domain=2Ec b/xen/arch/x86/domain=2Ec index 996b50af7a=2E=2E0ddddb1024 100644 --- a/xen/arch/x86/domain=2Ec +++ b/xen/arch/x86/domain=2Ec @@ -590,7 +590,7 @@ void arch_vcpu_destroy(struct vcpu *v) ASSERT_UNREACHABLE(); } =20 -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con= fig) { bool hvm =3D config->flags & XEN_DOMCTL_CDF_hvm; bool hap =3D config->flags & XEN_DOMCTL_CDF_hap; @@ -633,13 +633,6 @@ int arch_sanitise_domain_config(struct xen_domctl_cre= atedomain *config) return -EINVAL; } =20 - if ( !hvm ) - /* - * It is only meaningful for XEN_DOMCTL_CDF_oos_off to be clear - * for HVM guests=2E - */ - config->flags |=3D XEN_DOMCTL_CDF_oos_off; - if ( nested_virt && !hvm_nested_virt_supported() ) { dprintk(XENLOG_INFO, "Nested virt requested but not available\n")= ; @@ -833,6 +826,13 @@ int arch_domain_create(struct domain *d, =20 spin_lock_init(&d->arch=2Ee820_lock); =20 + /* + * It is only meaningful for XEN_DOMCTL_CDF_oos_off to be clear for H= VM + * guests=2E + */ + if ( !is_hvm_domain(d) ) + d->options |=3D XEN_DOMCTL_CDF_oos_off; + if ( d->domain_id && cpu_has_amd_erratum(&boot_cpu_data, AMD_ERRATUM_= 121) ) { if ( !opt_allow_unsafe ) diff --git a/xen/include/xen/sched=2Eh b/xen/include/xen/sched=2Eh index e352e2b38e=2E=2Eda80aa63ff 100644 --- a/xen/include/xen/sched=2Eh +++ b/xen/include/xen/sched=2Eh @@ -770,10 +770,9 @@ static inline void domain_update_node_affinity(struct= domain *d) } =20 /* - * To be implemented by each architecture, sanity checking the configurat= ion - * and filling in any appropriate defaults=2E + * To be implemented by each architecture, sanity checking the configurat= ion=2E */ -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config); +int arch_sanitise_domain_config(const struct xen_domctl_createdomain *con= fig); =20 /* * Create a domain: the configuration is only necessary for real domain --=20 2=2E53=2E0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orch= estra - Vates solutions web: https://vates=2Etech ---=Part.b7.9cd30c3973d2ad73.1a0908275f8.bc0c5a2802185582=--- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:53:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:53:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416616.1645586 (Exim 4.92) (envelope-from ) id 1x50l7-0000O0-7L; Fri, 11 Sep 2026 12:53:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416616.1645586; Fri, 11 Sep 2026 12:53:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50l7-0000Nt-3L; Fri, 11 Sep 2026 12:53:37 +0000 Received: by outflank-mailman (input) for mailman id 1416616; Fri, 11 Sep 2026 12:53:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50l5-0000Nh-6g for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:53:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50l4-009H6T-EV for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:53:34 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3f9c1-e002-0a2a0a5209dd-0a2a450ca83c-18 for ; Fri, 11 Sep 2026 14:53:34 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3f9ce-f479-0a2a450c0019-c387df82dbae-3 for ; Fri, 11 Sep 2026 14:53:34 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7F3CE21D68; Fri, 11 Sep 2026 12:53:25 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C4224132D3; Fri, 11 Sep 2026 12:53:24 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id ZWqjKMT5o2oZGQAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 12:53:24 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de"; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789131209; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=7cPvMY85MgtxziRNodVv1JV9DMlJY8hzgkmogmM3/aM=; b=OKa28g7Hz0OZmTxpxbpvJiL1SyqvtmVIe/gf45xG1+SxTIecPkIgCeO8e7jRWT9Edp3Nzp kkpDUSHEkFxg+ALv2/KSLSoGO51AyulIooWXSpc4q7FBhAQ1leB1PNryHjs1oED/dpaA9f WSpvX7HTjB9bgGhS2z6f7fcRJ2INMPA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789131209; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=7cPvMY85MgtxziRNodVv1JV9DMlJY8hzgkmogmM3/aM=; b=EQZ92462m3in2rUsjklW3jBlyIsr1knMJo/htxMFY23i5ahmZwmQTGQZeUnppwahHJvOU+ yCXL+gJvdiqqttCw== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=CkqBOwP6; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Drw68AFG DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789131205; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=7cPvMY85MgtxziRNodVv1JV9DMlJY8hzgkmogmM3/aM=; b=CkqBOwP6HJ3/Q+s0PlQlwnlubuR8qyHDf4uhhTD3QpwY7B2ElmDAgxuiVOpfjXRoKwYloW Ft4hJEiveX5RygG334lKs0CAyAm54+FtUtwpRlKSwnGHjKOhw/D7AuJuNe5V4E5WR/kR5G pjOcRlb1TS1aSybQhyHLTUtQyGNcWcw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789131205; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=7cPvMY85MgtxziRNodVv1JV9DMlJY8hzgkmogmM3/aM=; b=Drw68AFGuLEDDqN21X4UVjPrXe9/lZMq6jUIfXO0Lp4J5cU0HFSJa7BQqfAY14Q7MsZMjS s8rMYcd82ZevW1CA== Message-ID: <72ac181e-51f9-408e-8c5d-cb24e553a0f8@suse.de> Date: Fri, 11 Sep 2026 14:53:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 5/8] drm/gm12u320: replace struct drm_simple_display_pipe with regular atomic helpers To: Ze Huang , Alexey Brodkin , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , Joel Stanley , Andrew Jeffery , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Linus Walleij , Hans de Goede , Alex Lanzano , Oleksandr Andrushchenko Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org References: <20260727-drm-simple-kms-removal-v3-0-cd5dc89858c6@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-5-cd5dc89858c6@oss.qualcomm.com> Content-Language: en-US From: Thomas Zimmermann Autocrypt: addr=tzimmermann@suse.de; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c= In-Reply-To: <20260727-drm-simple-kms-removal-v3-5-cd5dc89858c6@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 7F3CE21D68 X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FREEMAIL_TO(0.00)[oss.qualcomm.com,synopsys.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch,jms.id.au,codeconstruct.com.au,nxp.com,pengutronix.de,epam.com]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_TWELVE(0.00)[22]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[qualcomm.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.de:dkim,suse.de:email,suse.de:mid] X-Spam-Flag: NO X-Spam-Score: -3.01 X-purgate-ID: tlsNG-d25034/1789131214-766DEA5B-152CB0C7/0/0 X-purgate-type: clean X-purgate-size: 9204 Hi Am 26.07.26 um 21:45 schrieb Ze Huang: > Convert gm12u320 to direct primary plane, CRTC and encoder setup. > > Keep shadow-plane helper state, framebuffer access helpers and > no-scaling plane-state check from simple-KMS path. > > Reviewed-by: Thomas Zimmermann > Tested-by: Thomas Zimmermann > Signed-off-by: Ze Huang I have added this patch to drm-misc-next. Best regards Thomas > > --- > Changes in v3: > - Use commit-local plane state in the CRTC enable path when marking the first > frame dirty. > - Make the gm12u320 container helper static inline. > --- > drivers/gpu/drm/tiny/gm12u320.c | 138 ++++++++++++++++++++++++++++++++-------- > 1 file changed, 111 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c > index d73dfebb4353..afcf0dfff14b 100644 > --- a/drivers/gpu/drm/tiny/gm12u320.c > +++ b/drivers/gpu/drm/tiny/gm12u320.c > @@ -8,6 +8,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -27,7 +28,6 @@ > #include > #include > #include > -#include > > static bool eco_mode; > module_param(eco_mode, bool, 0644); > @@ -87,7 +87,9 @@ MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, more silent)"); > > struct gm12u320_device { > struct drm_device dev; > - struct drm_simple_display_pipe pipe; > + struct drm_plane plane; > + struct drm_crtc crtc; > + struct drm_encoder encoder; > struct drm_connector conn; > unsigned char *cmd_buf; > unsigned char *data_buf[GM12U320_BLOCK_COUNT]; > @@ -102,7 +104,10 @@ struct gm12u320_device { > } fb_update; > }; > > -#define to_gm12u320(__dev) container_of(__dev, struct gm12u320_device, dev) > +static inline struct gm12u320_device *to_gm12u320(struct drm_device *__dev) > +{ > + return container_of(__dev, struct gm12u320_device, dev); > +} > > static const char cmd_data[CMD_SIZE] = { > 0x55, 0x53, 0x42, 0x43, 0x00, 0x00, 0x00, 0x00, > @@ -554,43 +559,106 @@ static int gm12u320_conn_init(struct gm12u320_device *gm12u320) > } > > /* ------------------------------------------------------------------ */ > -/* gm12u320 (simple) display pipe */ > +/* gm12u320 display pipe */ > > -static void gm12u320_pipe_enable(struct drm_simple_display_pipe *pipe, > - struct drm_crtc_state *crtc_state, > - struct drm_plane_state *plane_state) > +static void gm12u320_crtc_helper_atomic_enable(struct drm_crtc *crtc, > + struct drm_atomic_commit *commit) > { > struct drm_rect rect = { 0, 0, GM12U320_USER_WIDTH, GM12U320_HEIGHT }; > - struct gm12u320_device *gm12u320 = to_gm12u320(pipe->crtc.dev); > - struct drm_shadow_plane_state *shadow_plane_state = to_drm_shadow_plane_state(plane_state); > + struct gm12u320_device *gm12u320 = to_gm12u320(crtc->dev); > + struct drm_plane_state *pstate = drm_atomic_get_new_plane_state(commit, &gm12u320->plane); > + struct drm_shadow_plane_state *shadow_plane_state = to_drm_shadow_plane_state(pstate); > > gm12u320->fb_update.draw_status_timeout = FIRST_FRAME_TIMEOUT; > - gm12u320_fb_mark_dirty(plane_state->fb, &shadow_plane_state->data[0], &rect); > + gm12u320_fb_mark_dirty(pstate->fb, &shadow_plane_state->data[0], &rect); > } > > -static void gm12u320_pipe_disable(struct drm_simple_display_pipe *pipe) > +static void gm12u320_crtc_helper_atomic_disable(struct drm_crtc *crtc, > + struct drm_atomic_commit *commit) > { > - struct gm12u320_device *gm12u320 = to_gm12u320(pipe->crtc.dev); > + struct gm12u320_device *gm12u320 = to_gm12u320(crtc->dev); > > gm12u320_stop_fb_update(gm12u320); > } > > -static void gm12u320_pipe_update(struct drm_simple_display_pipe *pipe, > - struct drm_plane_state *old_state) > +static void gm12u320_plane_helper_atomic_update(struct drm_plane *plane, > + struct drm_atomic_commit *commit) > { > - struct drm_plane_state *state = pipe->plane.state; > + struct drm_plane_state *old_state = drm_atomic_get_old_plane_state(commit, plane); > + struct drm_plane_state *state = drm_atomic_get_new_plane_state(commit, plane); > struct drm_shadow_plane_state *shadow_plane_state = to_drm_shadow_plane_state(state); > struct drm_rect rect; > > + if (!state->fb) > + return; > + > if (drm_atomic_helper_damage_merged(old_state, state, &rect)) > gm12u320_fb_mark_dirty(state->fb, &shadow_plane_state->data[0], &rect); > } > > -static const struct drm_simple_display_pipe_funcs gm12u320_pipe_funcs = { > - .enable = gm12u320_pipe_enable, > - .disable = gm12u320_pipe_disable, > - .update = gm12u320_pipe_update, > - DRM_GEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS, > +static const struct drm_plane_funcs gm12u320_plane_funcs = { > + .update_plane = drm_atomic_helper_update_plane, > + .disable_plane = drm_atomic_helper_disable_plane, > + .destroy = drm_plane_cleanup, > + DRM_GEM_SHADOW_PLANE_FUNCS, > +}; > + > +static int gm12u320_plane_helper_atomic_check(struct drm_plane *plane, > + struct drm_atomic_commit *commit) > +{ > + struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(commit, plane); > + struct drm_crtc_state *crtc_state = NULL; > + > + if (plane_state->crtc) { > + crtc_state = drm_atomic_get_crtc_state(commit, plane_state->crtc); > + if (IS_ERR(crtc_state)) > + return PTR_ERR(crtc_state); > + } > + > + return drm_atomic_helper_check_plane_state(plane_state, crtc_state, > + DRM_PLANE_NO_SCALING, > + DRM_PLANE_NO_SCALING, > + false, false); > +} > + > +static const struct drm_plane_helper_funcs gm12u320_plane_helper_funcs = { > + DRM_GEM_SHADOW_PLANE_HELPER_FUNCS, > + .atomic_check = gm12u320_plane_helper_atomic_check, > + .atomic_update = gm12u320_plane_helper_atomic_update, > +}; > + > +static int gm12u320_crtc_helper_atomic_check(struct drm_crtc *crtc, > + struct drm_atomic_commit *commit) > +{ > + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(commit, crtc); > + int ret; > + > + if (crtc_state->enable) { > + ret = drm_atomic_helper_check_crtc_primary_plane(crtc_state); > + if (ret) > + return ret; > + } > + > + return drm_atomic_add_affected_planes(commit, crtc); > +} > + > +static const struct drm_crtc_helper_funcs gm12u320_crtc_helper_funcs = { > + .atomic_check = gm12u320_crtc_helper_atomic_check, > + .atomic_enable = gm12u320_crtc_helper_atomic_enable, > + .atomic_disable = gm12u320_crtc_helper_atomic_disable, > +}; > + > +static const struct drm_crtc_funcs gm12u320_crtc_funcs = { > + .set_config = drm_atomic_helper_set_config, > + .page_flip = drm_atomic_helper_page_flip, > + .reset = drm_atomic_helper_crtc_reset, > + .destroy = drm_crtc_cleanup, > + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, > + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state, > +}; > + > +static const struct drm_encoder_funcs gm12u320_encoder_funcs = { > + .destroy = drm_encoder_cleanup, > }; > > static const uint32_t gm12u320_pipe_formats[] = { > @@ -677,13 +745,29 @@ static int gm12u320_usb_probe(struct usb_interface *interface, > if (ret) > return ret; > > - ret = drm_simple_display_pipe_init(&gm12u320->dev, > - &gm12u320->pipe, > - &gm12u320_pipe_funcs, > - gm12u320_pipe_formats, > - ARRAY_SIZE(gm12u320_pipe_formats), > - gm12u320_pipe_modifiers, > - &gm12u320->conn); > + ret = drm_universal_plane_init(dev, &gm12u320->plane, 0, > + &gm12u320_plane_funcs, > + gm12u320_pipe_formats, > + ARRAY_SIZE(gm12u320_pipe_formats), > + gm12u320_pipe_modifiers, > + DRM_PLANE_TYPE_PRIMARY, NULL); > + if (ret) > + return ret; > + drm_plane_helper_add(&gm12u320->plane, &gm12u320_plane_helper_funcs); > + > + ret = drm_crtc_init_with_planes(dev, &gm12u320->crtc, &gm12u320->plane, NULL, > + &gm12u320_crtc_funcs, NULL); > + if (ret) > + return ret; > + drm_crtc_helper_add(&gm12u320->crtc, &gm12u320_crtc_helper_funcs); > + > + ret = drm_encoder_init(dev, &gm12u320->encoder, &gm12u320_encoder_funcs, > + DRM_MODE_ENCODER_NONE, NULL); > + if (ret) > + return ret; > + gm12u320->encoder.possible_crtcs = drm_crtc_mask(&gm12u320->crtc); > + > + ret = drm_connector_attach_encoder(&gm12u320->conn, &gm12u320->encoder); > if (ret) > return ret; > > -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg) From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:57:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:57:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416627.1645595 (Exim 4.92) (envelope-from ) id 1x50oN-0000we-Kz; Fri, 11 Sep 2026 12:56:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416627.1645595; Fri, 11 Sep 2026 12:56:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50oN-0000wX-Fz; Fri, 11 Sep 2026 12:56:59 +0000 Received: by outflank-mailman (input) for mailman id 1416627; Fri, 11 Sep 2026 12:56:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x50oL-0000wP-BS for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:56:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50oK-00E9pL-OU for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:56:56 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3fa7f-8faa-0a2a0a5109dd-0a2a4502c0be-40 for ; Fri, 11 Sep 2026 14:56:56 +0200 Received: from [209.85.208.44] (helo=mail-ed1-f44.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3fa98-6ca4-0a2a45020019-d155d02ce0d0-3 for ; Fri, 11 Sep 2026 14:56:56 +0200 Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-6a20319d030so1333898a12.2 for ; Fri, 11 Sep 2026 05:56:56 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2966022298sm75617566b.17.2026.09.11.05.56.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 05:56:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789131416; x=1789736216; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=FyjXMl5Q8kG/H2J4L7UK8gHoWxwkk2OabczX9ehfwRw=; b=NqHg8GHn18tYIgtZ8Dn/5fOH0LLriEeuVGdWd7iaTpD80JP7fI7ZyBXr2jPalm8rxl RECFI+8kSUIBZkrv6x8WKxNCsy1pKnNuQ9Zfvq5EkuLJNtz48zd+cZSvW+BE+VvKZDrd Ei0pX7Q+TusFSMf5EoFL1cY95Zmm1Wiz10MB/2gCop7b29Qd3nEOH0bttrKJxH81ctJx cnvi50mM8yeRKvcS6DElepEa7Kr4nO+Kv5/yd7Yii6ogJTg3+WDMb5Kq/PDyVVL48a3J 5kFJjataH3V1JoRIxAPG8KOBIrh0S3OVq/KH1Al9pzl03pHtp/i8A0TweLH/Bxi/zkcA iA6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789131416; x=1789736216; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=FyjXMl5Q8kG/H2J4L7UK8gHoWxwkk2OabczX9ehfwRw=; b=bVUmWDh7wrncsP4DLHHD3Q+FLgjRIPdmXVg2zcHaqS43JD7vggiHyQ/z9689WY3jUm iRdJvoP2B1eRjosuz9rTaxg6iWpIO9Y2haoY1G3k2sOCDoQv7hjfUquFnjxbnqucowYR NXpruM/Xom2jzsEvJqtpvAvB+a8arhUZW84dGI6o2qFjJ2hGne0ethDlIUunygN5MhIn 5JbDEjsHPpE1WOIMPaHmyeRePFG8C1zgiM27LyLV2vwxs63ansW+ifeXcjEjw9cB0IS4 x18MFPUCVgYWsvtnSuUl7Y000XtrfgYsJQ/inLjgGz7sqxMsj6pKs41Lt1xQnh7lSacT tRrA== X-Gm-Message-State: AFuF++muR03xykoOnxfewkI8IvO+wA2mjakMdQ1bOSLB+ojOcDPUUko/ nVN8TcjTzEpyugNzSNSgzOj0mT9HHSOALUzaiVisw/T7IHBaHj/nloUY X-Gm-Gg: AYBFou3gESevI2Jyiapw9B3MAsZMhblitwDOuvRojtuNrUDTPoNvZSxOt0Grj9vUxPR i/9qvD5gmXEXRomsyA1+2rGtHXRR9T7W5oNOJ6JtkGjuX9XgYw+nhV+WCKQDwPeLGTYnJ39Zf12 RimMP/+1UeBGOjAw0dHRsHD453webHFtIC+CCOA+42ydotfiEFi3Ag90/Q2B60WCAf2c3e4EFX7 /YCL5BSeE7DqF7qMoEwmmx6E5gTNgkBeC8dH4I15pLrHcCpq6zGyxQ6B1zzRVo9IN2HNCUtmZy3 XIis8NhkG3mp7koGXUkQCgMF1BPnHpzs+2ZGf4fbVwI4RsIzUihyNfDSFTf35+TN4KSKKAHNHoG Dbam78KcJ6t38YJfbxxjUeZpsxkJInDaxZClCOYulog1K+6V/mImApeIm2N0/SGUf2s3b6ZyEw4 tX2HAoHreaMAEryBvTZQQhVmGgaMmrGe28RLbi6IkfpTPKzX79vyhzwqmXqihWEfs5uAnsq5KSP YJr1cBe3JBWn1qm4XKh5q3X81P+LXeP X-Received: by 2002:a17:906:6a0a:b0:c20:1c9d:8d4b with SMTP id a640c23a62f3a-c2966535268mr176537766b.2.1789131416018; Fri, 11 Sep 2026 05:56:56 -0700 (PDT) Message-ID: <42ea4b01-422f-436f-b7bc-8b4f31283386@gmail.com> Date: Fri, 11 Sep 2026 14:56:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 21/39] xen/riscv: resolve the faulting guest physical address To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9a70000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9a70000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789131416-F0EA32AC-B3F1F23A/10/73395122804 X-purgate-type: spam X-purgate-size: 5435 On 9/9/26 2:04 PM, Baptiste Le Duc wrote: >> Take the guest physical address from htval and stval: on a guest-page fault >> htval holds it shifted right by 2, so that an address wider than XLEN fits, >> and stval holds the faulting guest virtual address, whose two least >> significant bits are those of the guest physical address. The shift is done >> on paddr_t rather than on the raw register: a guest physical address is 34 >> bits wide on RV32 with Sv32x4, so shifting an XLEN-wide value would drop its >> top two bits. >> >> Those two low bits come from stval only for a fault on an explicit access. >> Where one is taken on an implicit access made for VS-stage translation htval >> holds the address of the VS-stage PTE which could not be read, while stval >> still holds the guest virtual address which started the walk, and the low >> bits of the address written to htval are zero instead. htinst tells the two >> apart, which is what the spec points at it for. >> > I'd just precise (the spec is also not clear on this point though), what > is "current XLEN" here, clearly indicate that htval holds the GPA >> 2 and My understanding was that "current XLEN" == hypervisor XLEN as htval is hypervisor register and has HSXLEN size so it was okay for me to have just XLEN in the original commit message. But I am okay to use your suggestion ... > stval holds VGA and also put the two different cases we need to > distinguish clearly: > ``` > Recover the guest physical address from htval and stval. On a guest-page > fault to hypervisor, htval holds the guest physical address shifted > right by 2, so that an address wider than HSXLEN fits, and stval holds ... here. > the faulting guest virtual address. The shift is done on paddr_t rather > than on the raw register: a guest physical address is 34 bits wide on > RV32 with Sv32x4, so shifting an XLEN-wide value would drop its top two > bits. > > However, there are two cases to distinguish when recovering the > faulting GPA: > - Explicit memory access: we use the two least significant bits of > stval, which are the same as those of the guest physical > address. > - Implicit memory access for VS-stage translation: the two least > significant bits of htval are zero. The original phrasing "the two least significant bits of htval are zero" is inaccurate for the following reasons: - htval holds a shifted address (GPA >> 2): The htval CSR stores the faulting Guest Physical Address (GPA) shifted right by 2 bits. As a result, the two least significant bits of htval (htval[1:0]) actually correspond to bits 2 and 3 of the original GPA (GPA[3:2]). - htval bits are not guaranteed to be zero: Implicit memory accesses during VS-stage address translation fetch PTEs that are 4-byte aligned (Sv32) or 8-byte aligned (Sv39/Sv48/Sv57). Since PTEs can reside at offsets like 0x04, 0x08, or 0x0C, GPA (and therefore htval[1:0]) can be non-zero. - What is actually guaranteed to be zero: Because all VS-stage PTE accesses are at least 4-byte aligned, it is the lowest two bits of the unshifted Guest Physical Address (GPA[1:0]) that are guaranteed to be 00, not the low bits of htval. So here I think we want to clarify then: ``` Implicit memory access for VS-stage translation: the two least significant bits of the guest physical address (GPA[1:0]) are zero ``` > > These two cases can be distinguished using the value provided in > register htinst. > ``` >> >> stval needs no check against an ISA extension: a guest-page fault writes it >> with the faulting guest virtual address regardless. Sstvala would not be the >> right thing to test for either (it covers stval across every trap type >> which writes it, a wider guarantee than what is needed here). >> >> htval does need one. The H extension lets an implementation write it with >> either the faulting address or zero, so without Shtvala a zero htval cannot >> be told apart from a genuine fault on guest physical address 0-3, and the >> address has to be recovered by decoding the access and walking the VS-stage >> page tables in software instead. That is left as a TODO, and until it is >> written such hardware panics rather than acting on an address which may not >> be the one which faulted. >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c >> index f9da075104..ff530ef2df 100644 >> --- a/xen/arch/riscv/emulate.c >> +++ b/xen/arch/riscv/emulate.c >> @@ -9,6 +9,7 @@ >> #include >> #include >> >> +#include >> #include >> #include >> #include >> @@ -62,10 +63,28 @@ static bool htinst_is_pseudo(unsigned long htinst) >> } >> } >> >> -/* Reconstruct the guest physical address of the access which faulted. */ >> +/* Resolves the guest physical address the access faulted on into @gf->gpa. */ > Why did you change the comment apart for adding @gf->gpa? I think the > "reconstruct" is more clear but there might be another reason why you > changed it. > I thought that it will just a little bit clearer (and anyway it should a part of another patch...) so I will revert the change here and go with "reconstruct". Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:57:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:57:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416633.1645603 (Exim 4.92) (envelope-from ) id 1x50p3-0001Ol-RA; Fri, 11 Sep 2026 12:57:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416633.1645603; Fri, 11 Sep 2026 12:57:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50p3-0001Oe-Nx; Fri, 11 Sep 2026 12:57:41 +0000 Received: by outflank-mailman (input) for mailman id 1416633; Fri, 11 Sep 2026 12:57:41 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50p2-0001OS-Td for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:57:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50p2-00E9zX-AD for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:57:40 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3faba-8faa-0a2a0a5109dd-0a2a45099388-28 for ; Fri, 11 Sep 2026 14:57:40 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3fac4-be1a-0a2a45090019-4a7de48cb253-3 for ; Fri, 11 Sep 2026 14:57:40 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254fa663c1so117060466b.0 for ; Fri, 11 Sep 2026 05:57:40 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c29660654e4sm74658866b.30.2026.09.11.05.57.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 05:57:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789131460; x=1789736260; darn=lists.xenproject.org; h=content-type: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:content-type; bh=u2ZiLHVaNmzXwUpXIHPIqZPZKWeplSxgooX+AchZzHA=; b=CpBWUrLG92OVTrKyG5lmUr3ySHPtQG3gVVjPYp4PikG3vFVKzaZ/TSKyAOtBumkGKl XI/Oc/kPM4geNMFnzLp0PpxVrdzMJjyBMvaMQVkCYUnSGljVY/s/YJJ9Pf7eQuPZaSRR 1qWK7LQc+D1IQDD19p7BU8oUMcZU4I0khb0zq/j2nutZFn14y9SjEFTzqbQCDy28HOYk ZPbz2YgImFKHPtcLrfIVezjHKNtkcqvKBzWaDqXfxlUYW5cDAr4OwyAidcAZwlqYr8PQ CWrW5dJSChuaG45fwISdYLQ09K5BpuQpQqybiHl5ryv7jPh9cMpYO70aOKwgTN6Nhgh+ QIPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789131460; x=1789736260; h=content-type: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 :content-type; bh=u2ZiLHVaNmzXwUpXIHPIqZPZKWeplSxgooX+AchZzHA=; b=Wz2Ho2rlvFJExjMsTBdVce/TD7JhdloUtBQiRH5SCiRSp6JfKRNB1qPy6FnaqjMpVB wQpCS/BeHn+rFaSU4jhAiZK0Y1L+pzKgHVJpKt2EVn0zEq93XR0lrwT4hjMgx97IJa3a nsXXCxDqRROXFgsuSIMWdDXtxzlcQWuqFa/71Q0v7l6Eq9ERPhR7pxU4bEn3djn43quu zZglBS0jOS9dASgVdymWighJ0dEL52Dp+EJYrFrarqXtAe3JUTkLkFkzbYZ0OQzx8Jfj D4aEBc11nR/FiQs3It2eieirxg2QMc4DHauN++BJQsVyJY2kYMAfkcRPqEtHu9KRsQaP 2ByQ== X-Forwarded-Encrypted: i=1; AKwUvByz5+9gGeFHPrhXw5PmMNnPbD1Lvr7oLa4F00SJmzcIC04kSSoOZCEjYTjNd2jDpSBo0/8sE+wHTWA=@lists.xenproject.org X-Gm-Message-State: AFuF++nHmvfP9c3E3mlnBlEMw8xPwKp8nMQR5qmlJquLLUnsMQB1xc1r 07vJIT6R5fc9vqt48e99DGXmPLzD3huQKiObznwrrum5veIILmetnZ9rEjzVfCfLVpQ= X-Gm-Gg: AYBFou0nr/CYa2jHeiQ26sH0hSLCSTNPWyuULkxrZVhYyPHUpkH8MQZh2ersIaf5xW5 az27Wy+CbFpnrv9tYmUIutEe1XrV3m5aOjkdoeGTsr7MRPs+C5V/FaDDmcgGGXwee06+IxV7gPU RIVFQ09drj1jOn+wu3Qc3brQ1vVh+Zgjw9YVIw6tN4mm0+NS+H3todfXjIdnEeHPIhWCEVNXSvn qptp2lJStwO4P2TZWh8Bu842u3iZ7L3aTcoQo529P8eUk6aOir9Q8sXAlNHTACYn7yArtF+0pCE LE3J3Mm2bSpoYCpWznr3Kgp71pnX9mH7VK6ahVDX0sFppNq6JiGdtjBVOWGN136zxAfFeOdfXHd f1wKdhM/1rfK5vfxUhWWhfsryUlrpmH9qxE2fFHH1tRAXw2+ikNQKzEquA06Y5go21dayghcS2j WkIpcr8VNXzItKnRbWnST536sc2rrnFyzy0JAD/bCLCz00278dVdnTLjZZnPGVs227hlrKt5iy0 tQ+iPRuXoaEWhSsNKfnErPQBwDy3D1n4RVx9962BYUxKUdPJS8bIXleFMSRhKF3mr5eFqBjD3Zz OyiR3eSoH5GOdZG0p8fQ8HEzPhQgK8nfvXs= X-Received: by 2002:a17:906:ba8e:b0:c25:c7a9:7b8a with SMTP id a640c23a62f3a-c2966694d6cmr313978366b.12.1789131459543; Fri, 11 Sep 2026 05:57:39 -0700 (PDT) Message-ID: <1a24d3e6-8ea5-4016-b795-ce1bc9a63fb7@suse.com> Date: Fri, 11 Sep 2026 14:57:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] xen/sched: rtds: add per-cpupool admission control To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <7fb66cfd-b1b0-4f58-b35c-229aa679f737@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <7fb66cfd-b1b0-4f58-b35c-229aa679f737@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------4lu8hLzxESlKFKDy2TQHmgaK" X-purgate-ID: tlsNG-bad1c0/1789131460-39AC0034-94EB9D97/0/0 X-purgate-type: clean X-purgate-size: 11382 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------4lu8hLzxESlKFKDy2TQHmgaK Content-Type: multipart/mixed; boundary="------------juwuBqxKAIoht7m3B8qUH0qh"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com Message-ID: <1a24d3e6-8ea5-4016-b795-ce1bc9a63fb7@suse.com> Subject: Re: [PATCH 0/5] xen/sched: rtds: add per-cpupool admission control References: <20260826045720.5779-1-frn1furkan10@gmail.com> <7fb66cfd-b1b0-4f58-b35c-229aa679f737@gmail.com> In-Reply-To: <7fb66cfd-b1b0-4f58-b35c-229aa679f737@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------juwuBqxKAIoht7m3B8qUH0qh Content-Type: multipart/mixed; boundary="------------p5Tmn16gtgNGcALKWqHIJiKc" --------------p5Tmn16gtgNGcALKWqHIJiKc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTEuMDkuMjYgMTQ6MjUsIEZ1cmthbiDDh2FsxLHFn2thbiB3cm90ZToNCj4gDQo+IE9u IDgvMjYvMjYgMDc6NTcsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4+IFJURFMgY3VycmVu dGx5IGhhcyBubyBhZG1pc3Npb24gY29udHJvbDogbm90aGluZyBzdG9wcyB0aGUgc3VtIG9m DQo+PiBhbGwgYWRtaXR0ZWQgdW5pdHMnIChidWRnZXQvcGVyaW9kKSByZXNlcnZhdGlvbnMg aW4gYSBjcHVwb29sIGZyb20NCj4+IGV4Y2VlZGluZyB3aGF0IGl0cyBwQ1BVcyBjYW4gYWN0 dWFsbHkgcHJvdmlkZS4gT25jZSB0aGF0IGhhcHBlbnMsDQo+PiB0aGUgZ2xvYmFsLUVERiBk ZWFkbGluZSBndWFyYW50ZWVzIHRoZSBzY2hlZHVsZXIgaXMgYnVpbHQgYXJvdW5kIG5vDQo+ PiBsb25nZXIgaG9sZCBmb3IgYW55IHVuaXQgc2hhcmluZyB0aGF0IHBvb2wuDQo+Pg0KPj4g VGhpcyBzZXJpZXMgYWRkcyBhZG1pc3Npb24gY29udHJvbCB0byBwcmV2ZW50IHRoYXQsIHRy YWNrcyBhbmQNCj4+IHJlcG9ydCB1dGlsaXphdGlvbiwgYW5kIG1ha2VzIHRoZSBjaGVjayB0 b2dnbGVhYmxlIHBlciBjcHVwb29sIHNvDQo+PiBhbiBvcGVyYXRvciBjYW4gZGlzYWJsZSBp dCBpZiB0aGV5IGludGVudGlvbmFsbHkgd2FudCB0byBvdmVyY29tbWl0Lg0KPj4NCj4+IFBh dGNoIDEgaW50cm9kdWNlcyB0aGUgY29yZSBtZWNoYW5pc206IGEgcnVubmluZyB1dGlsaXph dGlvbiB0b3RhbA0KPj4gcGVyIGNwdXBvb2wsIGEgZml4ZWQtcG9pbnQgcmVwcmVzZW50YXRp b24gb2YgYSB1bml0J3MgKGJ1ZGdldC9wZXJpb2QpLA0KPj4gYW5kIGEgY2FwYWNpdHkgY2hl Y2sgZW5mb3JjZWQgaW4gcnRfYWxsb2NfdWRhdGEoKS9ydF9mcmVlX3VkYXRhKCkgLQ0KPj4g dGhlIGxpZmVjeWNsZSBob29rcyB0aGF0IGNhdGNoIGV2ZXJ5IG5ldyB1bml0J3MgZGVmYXVs dCByZXNlcnZhdGlvbi4NCj4+DQo+PiBQYXRjaCAyIGV4dGVuZHMgdGhlIHNhbWUgY2hlY2sg dG8gZG9tY3RsLCBzbyBncm93aW5nIGFuIGV4aXN0aW5nDQo+PiByZXNlcnZhdGlvbiB2aWEg eGwgc2NoZWQtcnRkcyBpcyBjaGVja2VkIHRvby4NCj4+DQo+PiBQYXRjaCAzIHJlcG9ydHMg YSBjcHVwb29sJ3MgYWRtaXR0ZWQgdXRpbGl6YXRpb24gYWdhaW5zIGl0cyBjYXBhY2l0eQ0K Pj4gdmlhIHRoZSAncicgZGVidWcga2V5Lg0KPj4NCj4+IFBhdGNoIDQgbWFrZXMgYWRtaXNz aW9uIGNvbnRyb2wgaXRzZWxmIHRvZ2dsZWFibGUgcGVyIGNwdXBvb2wNCj4+IChlbmFibGVk IGJ5IGRlZmF1bHQpIHZpYSBzeXNjdGwuDQo+Pg0KPj4gUGF0Y2ggNSB3aXJlcyB0aGF0IHRv Z2dsZSB0aHJvdWdoIGxpYnhsIGFuZCBhZGRzIC1zLy1hIHRvDQo+PiB4bCBzY2hlZC1ydGRz LCBhbmQgZG9jdW1lbnRzIGl0Lg0KPj4NCj4+IEZ1cmthbiBDYWxpc2thbiAoNSk6DQo+PiAg ICB4ZW4vc2NoZWQ6IHJ0ZHM6IGFkZCBnbG9iYWwtRURGIHV0aWxpemF0aW9uIGFkbWlzc2lv biBjb250cm9sDQo+PiAgICB4ZW4vc2NoZWQ6IHJ0ZHM6IGVuZm9yY2UgYWRtaXNzaW9uIGNv bnRyb2wgaW4geGwgc2NoZWQtcnRkcw0KPj4gICAgeGVuL3NjaGVkOiBydGRzOiByZXBvcnQg dXRpbGl6YXRpb24gYW5kIGNhcCB2aWEgZGVidWcga2V5DQo+PiAgICB4ZW4vc2NoZWQ6IHJ0 ZHM6IG1ha2UgYWRtaXNzaW9uIGNvbnRyb2wgY3B1cG9vbC13aWRlIHRvZ2dsZWFibGUNCj4+ ICAgIHRvb2xzOiBleHBvc2UgYWRtaXNzaW9uIGNvbnRyb2wgdG9nZ2xlIHZpYSB4bCBzY2hl ZC1ydGRzDQo+Pg0KPj4gICBkb2NzL21hbi94bC4xLnBvZC5pbiAgICAgICAgICAgICAgICAg fCAgMjAgKysrDQo+PiAgIHRvb2xzL2dvbGFuZy94ZW5saWdodC9oZWxwZXJzLmdlbi5nbyB8 ICAyMyArKysNCj4+ICAgdG9vbHMvZ29sYW5nL3hlbmxpZ2h0L3R5cGVzLmdlbi5nbyAgIHwg ICA0ICsNCj4+ICAgdG9vbHMvaW5jbHVkZS9saWJ4bC5oICAgICAgICAgICAgICAgIHwgICA0 ICsNCj4+ICAgdG9vbHMvaW5jbHVkZS94ZW5jdHJsLmggICAgICAgICAgICAgIHwgICA2ICsN Cj4+ICAgdG9vbHMvbGlicy9jdHJsL3hjX3J0LmMgICAgICAgICAgICAgIHwgIDQwICsrKysr Kw0KPj4gICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX3NjaGVkLmMgICAgICAgfCAgNDYgKysr KysrDQo+PiAgIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsICAgICB8ICAgNSAr DQo+PiAgIHRvb2xzL3hsL3hsX2NtZHRhYmxlLmMgICAgICAgICAgICAgICB8ICAgOCArLQ0K Pj4gICB0b29scy94bC94bF9zY2hlZC5jICAgICAgICAgICAgICAgICAgfCAxMDMgKysrKysr KysrKysrKy0NCj4+ICAgeGVuL2NvbW1vbi9zY2hlZC9ydC5jICAgICAgICAgICAgICAgIHwg MjA1ICsrKysrKysrKysrKysrKysrKysrKysrKysrLQ0KPj4gICB4ZW4vaW5jbHVkZS9wdWJs aWMvc3lzY3RsLmggICAgICAgICAgfCAgIDUgKw0KPj4gICAxMiBmaWxlcyBjaGFuZ2VkLCA0 NjMgaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkNCj4+DQo+IA0KPiBIaSBKdWVyZ2Vu LA0KPiANCj4gQ2FuIEkgZ2V0IGEgcmV2aWV3IG9uIHRoaXMgc2VyaWVzIHBsZWFzZT8NCg0K SSB3YXMgcXVpdGUgYnVzeSBwcmVwYXJpbmcgZm9yIFhlbiBzdW1taXQuIEknbSBwbGFubmlu ZyB0byBkbyB0aGUgcmV2aWV3IG9uDQp0aGUgdHJhaW4gdG8gTXVuaWNoLiA6LSkNCg0KDQpK dWVyZ2VuDQo= --------------p5Tmn16gtgNGcALKWqHIJiKc Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------p5Tmn16gtgNGcALKWqHIJiKc-- --------------juwuBqxKAIoht7m3B8qUH0qh-- --------------4lu8hLzxESlKFKDy2TQHmgaK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqj+sIFAwAAAAAACgkQsN6d1ii/Ey84 dQf8DYhBYEUROaWLk7YyTPOMfP6NxEGnvvvhx8nFPgIzM0tGA3J+vM30ZqcD1563Mf74Fn0wTD4Z D4BNjJbS9wdfgsQrJUncheqqWZqq1AZB2tsWL32h1h+a1cVyrenIqhK79sBaEx9F2t0MS2IgdysK Hi69isJowxmYhEjhc6Ci/t6Er5K770M9EMzb2UK8kkikkTo1X/5UjdeaqwtQyGC5OEC/27tl8uAB zTt4AxhtFHy8iAQvnEHK9E4DzrePwdzNZb6rDjejoqkMNSUH96Fga1llBdtMH/m3JiTdJvfNlOSB g1NGQDcNa98VR7dBjk6SqcUIV7gWuLSahmHpDaDz3w== =btQ7 -----END PGP SIGNATURE----- --------------4lu8hLzxESlKFKDy2TQHmgaK-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 12:57:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 12:57:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416636.1645612 (Exim 4.92) (envelope-from ) id 1x50pI-0001mB-5K; Fri, 11 Sep 2026 12:57:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416636.1645612; Fri, 11 Sep 2026 12:57:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50pI-0001m0-2X; Fri, 11 Sep 2026 12:57:56 +0000 Received: by outflank-mailman (input) for mailman id 1416636; Fri, 11 Sep 2026 12:57:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50pG-0001lJ-Gf for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 12:57:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50pF-00EA3k-TY for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:57:53 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3fac4-8faa-0a2a0a5109dd-0a2a4506e3fa-44 for ; Fri, 11 Sep 2026 14:57:53 +0200 Received: from [52.101.85.55] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3facf-195a-0a2a45060019-34655537d099-3 for ; Fri, 11 Sep 2026 14:57:53 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by IA6PR03MB060200.namprd03.prod.outlook.com (2603:10b6:208:5ec::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.10; Fri, 11 Sep 2026 12:57:46 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 12:57:45 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KbgGARKv6SNXGUvr4GHU5U7C5RbrD/83xpegKuridb6mTzq/ao0j8XdU0jxWEn90BiXtWTvOxRZVojALVpaXHr5NPa9dYsCvQYz6v9GmX2rvqZhIjJgrGZe5IPgof6tQuvPvbIbgEuyYnMenD2UI+e8riKMGbKz5tz2Gl1txkR1KS6ULdMS0KjbHDICIMlKDTR7+7xlmDBvw3q4TqejJ1ZmiOwr/o3Z4PI+HmsVj3Z5Yhh2BwbrmDZh5nb9kDvKNhs0YEGyhbz9QVfygSDNFGoUMgDN0OpJTjKEg7TW2RD/MaB3lhzI0P3WEDY2GE4P03iamzSqYsXWN2H4n0ZQuEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iaSpI75vANXUIHNFNH11hgxx/Xjouu6tt3l28Xhfy4g=; b=xxKqzYJEmR6CMozfcORU9Oc+l1flRah0hfDUBafUWqUKr5A+AT1tEvnilacAVubidZS/a4qRf7oMl6VNM3uI7zXYGK6cXoWNv/fBYGK+MxilOyxOQLiRILzRc05DC6dZ69KW5SWEOUk+ULwxzmruWXqoIva0jEd7/N6TAfYDCjf9+4ZmO5caH68mOnfnU06rdNuCPcJvsmtPHZ/nsGfoeCDBgUJ+JCKaTbhtuHhL+N8JJbUFP6t2Qt5OFKr65XO1cfSif61Gdsl0SLAO7n5coBtDJpc+DYDuoMjN0h2cwaAQZPv97cE3aPSE+OBD1dRPi9joawFfowPwhavi6BNEhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iaSpI75vANXUIHNFNH11hgxx/Xjouu6tt3l28Xhfy4g=; b=ls/GPnDjkGL8kumAatCNR2GMt5oYdQfsrL3w24rw7/L3KZmil8EKri20VjZV4DfB0e7J/rO4W1WL3876ML5q4gWy8cVflszIda/3ghVPYIrQNq+x1ZFpyUiNNfco0iO0sa1LVjnfC/aEe59je6TqXeqhec4dzows4HjULzoEfF8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0aedfbad-29ae-4083-89b4-5c662398553d@citrix.com> Date: Fri, 11 Sep 2026 13:57:42 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, teddy.astie@vates.tech Subject: Re: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update To: Kevin Lampis , xen-devel@lists.xenproject.org References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-4-kevin.lampis@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260910203113.462943-4-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0300.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:196::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|IA6PR03MB060200:EE_ X-MS-Office365-Filtering-Correlation-Id: 4e94f8da-d4ae-459a-b045-08df10044654 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|56012099006|11063799006|4143699003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: v/dQgkB/4/jgqdka2grXVr81jg3OJuQEIG8LlMtwmF+0PmublktQoSO+oiEBD6MB+HaBa9JGCsh0u8aVNNmGQdouGvfv/Demng/cmWpWdhk+WNAEelnyTjR8mMZVv42NX37DsPcCS1SC94emGu9BWRV5JIYXMsYDZwmUwie35kg61BLyTQeGUi7Ge9nQbUtRSBpRVf+lgASRfNA6abQFE5GrL9rn9B/aBvPyonvN8U1kMfsCF6vzk1QtiUz1HO9fIif3pxuQScSWmLkIWAa8z7tGcOD1ZJHoB9NlCQBl/JfKJRSrptwleROBwbEMbUpOiLsaS5NTx7Zt1pDg3ml9msxEPRQhj1OUSgpZcXzdaWiMS/oAxPYe17FF2Xle833KgjhNvPKSwP0fO+/ip+R9Ngr9fk64bBHVjUqQJeh6ajXbMrbwWEWJ6nYAGxMF5BjT8dJec3v0A7OSG7Z/Oau+6iBc/ZwVBWs4eC4PctwswybX8FUjS5SgmvLQhTzZqw3GqwyCTPcam0suwchUb8+cLGMVcpQNZxaLH0g6u84ip/vl+pDCxW7EKKqUJ36S9kv2RtJ9OVBnI0shozsfC6uGSFoDW0+F6QxdWSSXEGvQeRchArQpUEq7xR7zI9VoHtLpdy9LMadXHaYHmugvdWW1KyQVw8ZQXEPHq22GKN/GLvY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(56012099006)(11063799006)(4143699003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WE5PR2pPOTdmc2o2TWNXNUM3eUgwWWg1UmtCdHI2Sko3VnZXM3JDYko4Vk9J?= =?utf-8?B?SE13ZjhSMmVmTGVkYjdhV1Nydjg0UjBOdzhpWTdqYTlrdC9pV0FLc0dlT3ZO?= =?utf-8?B?elJkVkJVclhFS2E1SmtrNFc1NTI4QXhKdERGSEw5eTZ6OTV0N3FqRE5neVdn?= =?utf-8?B?R0gwdjFnb0tZM0JldlVGYjN0NU1aZ3R1ZG5Mc3NBRzZwODZMS0Z3aW9uaWVQ?= =?utf-8?B?ZUl1aDcrb1lWZ1E5WFE0RGM1aG9ZRWFaUW1NLzgvY2FLQ0lkTGJHdThvU0dC?= =?utf-8?B?Y1Rtd3VYYm1hTXJXZHh3REYwemwrRDltVVhrV2M5VTdTZFlIQ1ZBSlVxcGNt?= =?utf-8?B?eU9PaGszY0xSa2ZKU1JncXE1N3Ird2xuOGtUTHYwRDBYMEpQcXkraUFkMFB6?= =?utf-8?B?WVNXcmQ0bEdONmxnUkt3SkJxTzVJTU9pZ20rT1VNbWo3aEVIOXduT2pGcWxw?= =?utf-8?B?ejZlZ2sxNkp5bitHNkdxSlVaZkpoMkxPN01XTEp6Ukx1d0lrZFowOXkxS3hh?= =?utf-8?B?aE56OXduZXZlYzJiWm1xK2ZMbmRTNlFFVHk5K0VFQmluWEdHdTRyNnlkdlBG?= =?utf-8?B?VUhVSktoKythVDNOY090WXBHL0RDaFVacHNYaHBBU3R5L3VUMmZjTkViNGcr?= =?utf-8?B?SFNEb3lqT25JUXdzaDUrWjVqUnU2U2Z3SGlDdThsU29CM3pmcUZIOUNWT3Ur?= =?utf-8?B?dVZrVVZ3dHBuNEdqQXdTS1pyN3JrcThieDZHMkdBSVAyMUUvN3RZY0pXTm9i?= =?utf-8?B?N3UyUHBVYzE0UG0xNEd1Y3hYNnNBZWlFYVhUQzBBUlVFdlBpd0NIcVFWZGpH?= =?utf-8?B?M2tLMFh2ZTlwS0Q4SHlOQW5wejVYS05kNmcrR1dpVkdNUVVMM3pHd0hHNzlm?= =?utf-8?B?SmUySkx6eWxsbFhiM3NnZFlJVWpmMWQ4cUd6UktiTTZ4MGFKNG9xU3FMYW5J?= =?utf-8?B?VmVPWFIwKzR2WXBBelFaYUxpcUM5VzdreWtMcHB6bVRrRUh3eVRYVzN3VVUw?= =?utf-8?B?OTZqYkNrb01Hanc0VDhFV05mVm9yUFd4dGhESkVBQkFkNVc3eGg1cVh5ajlB?= =?utf-8?B?bW9aSmMzWGNNbUlxd2hMaTM2OCtvdDI1M09FR0NJRit2K3FEMHdWM1QzL0tZ?= =?utf-8?B?Vm9yWXhYQVN5WkhJOW13M2sxd081VUtGRTVEMlJXUWxCZTd6cVFqallld3Vl?= =?utf-8?B?Q014NE0xNVJtSWpCZVUzdGpMT21hMTNMMDk4VjdtOEdMR28ydTRHbGZpaW9w?= =?utf-8?B?ODE4NWRQZHU3WkpLYWZTektxdmJyMnAwU2gwdzhVNnhlWVl3M3gvbzRFcmFh?= =?utf-8?B?bEdUNE11dWwrM2lvZVJMU3czUGYycXUxMXhRY0dlTGdOTXVjN0dKUkNDVGwz?= =?utf-8?B?YStTYmZxNHFmdjA4ZTBYWmhOSG9MdU1KVSs1N3h3ZWNkdUlDclMzWWozQ0xl?= =?utf-8?B?OGZHYSthZUsweDB2RXVOeitLTUUwQU9KbHFpbnM3eTBIaklUREVWZG1EMVNE?= =?utf-8?B?UWpXcFRVWk5vZSttMnM4QzJaRUE5RHFadS9RVXJtYWpZTnRyRnAvbGZyY2xt?= =?utf-8?B?S093M0EreEE4WWxtUXphYzFuMFBwbkxLTkEvUFUwcDh3cnM2V2NSTW5DZmUw?= =?utf-8?B?UjhZanVNMFJkOUFyVEJ1Ukw0YzdwVmk1a0xsQUk0aGQ4YkZZa3FVYW1oc2E0?= =?utf-8?B?WkN3VkxiU1QyaG0vb01adFEraU5TZWNFMitTMkJNdEJMaHBvLzRhTlhUeTZF?= =?utf-8?B?TDcxQmJ3bGVxQ1lZaDB3L3U4NHJWVzE5RzVZQ1VVQ2NicWROQ3RpbnZjTmdz?= =?utf-8?B?ZlZmdDd3cDUzQ3hUR2dLY0p5a3BRaU4xRDBoT0U0cTRHRG9xNzB5NFdNYWoz?= =?utf-8?B?V1VuZXhjV3FwYnlRZ3lRbzhMTkp5YmxvUUhBRlNadCtUVnFFbE16QTNWUW9C?= =?utf-8?B?ZDZrenFQNExNTmpCTEIwNEtiL3FLTXUrT05HYS9JYlNTVGhHKzh3eWViVGZZ?= =?utf-8?B?UlBnSmpJUm9BSndMNjYwTmROeHUzWno5NFVJNW9PbGMrVWdsSjA2M1hIdFZp?= =?utf-8?B?TUhGc3JHU2ZvVzJWR3YxTFBmaHkwU2g3RUlISnllN3BWa2c1cnpuTFVJaldD?= =?utf-8?B?MU80ZVFIMm1ZZmZGMlFOQUl3NkpZS1ZXcVUrN0lZWSttbnc5bnBIWUxDT0pj?= =?utf-8?B?OXQ3UmpFa2tKZ0hUbjZ1TE85NG0xM2tUcEp4cXJJcEd1NVVKTlVldVdXNDJZ?= =?utf-8?B?MGh3UEN2UFVFbHQ2MnlNa1g1OHA4K1M5bEJUSW16c1BKSktsdklGeGluS3I1?= =?utf-8?B?OEo1azFEaUlCWEppcEZ1TGc3d0pCMnpWbXpIb09pWndCLzVaNFhpZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e94f8da-d4ae-459a-b045-08df10044654 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 12:57:45.6768 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sr07cyHPItyxvuyxcKAhnrTsy3m+yMdaYMNb7XS+Kl16posaWZBE/S0bqNYNF9CdkSYxtA9gQSP2u37prNt5pH0Vt5AaMSaBcC/KgHt/jcc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA6PR03MB060200 X-purgate-ID: tlsNG-16d1c6/1789131473-F560A77B-AC4B22B1/0/0 X-purgate-type: clean X-purgate-size: 2397 On 10/09/2026 9:31 pm, Kevin Lampis wrote: > diff --git a/xen/arch/x86/pv/mm.h b/xen/arch/x86/pv/mm.h > index bfee0feb7b21..f2bb26aef5b3 100644 > --- a/xen/arch/x86/pv/mm.h > +++ b/xen/arch/x86/pv/mm.h > @@ -64,15 +64,18 @@ static inline intpte_t paging_cmpxchg_guest_entry( > > #define PTE_UPDATE_PRESERVE_AD (1u << 0) > #define PTE_UPDATE_NO_TRANSLATE (1u << 1) > +#define PTE_UPDATE_SWAP (1u << 2) > > /* > * How to write an entry to the guest pagetables. > + * Returns the old PTE value. > */ > -static inline void update_intpte(intpte_t *p, intpte_t old, intpte_t new, > - mfn_t mfn, struct vcpu *v, unsigned int flags) > +static inline intpte_t update_intpte(intpte_t *p, intpte_t old, intpte_t new, > + mfn_t mfn, struct vcpu *v, > + unsigned int flags) > { > #ifndef PTE_UPDATE_WITH_CMPXCHG > - if ( !(flags & PTE_UPDATE_PRESERVE_AD) ) > + if ( !(flags & (PTE_UPDATE_PRESERVE_AD | PTE_UPDATE_SWAP)) ) > paging_write_guest_entry(v, p, new, mfn); > else > #endif > @@ -95,15 +98,16 @@ static inline void update_intpte(intpte_t *p, intpte_t old, intpte_t new, > old = t; > } > } > + return old; > } This seems unwise.  I think you want a return 0 in the paging_write_guest_entry() case because returning the input cannot possibly lead to anything good. In turn, the comment needs adjusting. > > /* > * Macro that wraps the appropriate type-changes around update_intpte(). > * Arguments are: type, ptr, old, new, mfn, vcpu > */ > -#define UPDATE_ENTRY(_t ,_p ,_o ,_n ,_m ,_v , fl) \ > - update_intpte(&_t ## e_get_intpte(*(_p)), \ > - _t ## e_get_intpte(_o), _t ## e_get_intpte(_n), \ > +#define UPDATE_ENTRY(_t ,_p ,_o ,_n ,_m ,_v , fl) \ > + update_intpte(&_t ## e_get_intpte(*(_p)), \ > + _t ## e_get_intpte(_o), _t ## e_get_intpte(_n), \ > _m, _v, fl) This delta is only moving the \'s I think. However, you want to wrap the expression in _t ## e_from_intpte(...) to hand back the type safe version.  In turn, this lets you remove the '.l1' part of the assignments in the following patch. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:01:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:01:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416652.1645620 (Exim 4.92) (envelope-from ) id 1x50sC-0003dS-HH; Fri, 11 Sep 2026 13:00:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416652.1645620; Fri, 11 Sep 2026 13:00:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50sC-0003dL-En; Fri, 11 Sep 2026 13:00:56 +0000 Received: by outflank-mailman (input) for mailman id 1416652; Fri, 11 Sep 2026 13:00:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50sB-0003dF-7a for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:00:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50sA-005ohD-KX for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:00:54 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3fb80-bab6-0a2a0a5309dd-0a2a4506c1ca-20 for ; Fri, 11 Sep 2026 15:00:54 +0200 Received: from [74.125.224.140] (helo=mail-yx2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3fb85-195a-0a2a45060019-4a7de08cb59f-3 for ; Fri, 11 Sep 2026 15:00:54 +0200 Received: by mail-yx2-f12.google.com with SMTP id 00721157ae682-85d43daa8f4so6176137b3.3 for ; Fri, 11 Sep 2026 06:00:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=linaro.org header.i="@linaro.org" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1789131653; cv=none; d=google.com; s=arc-20260327; b=CbJlHuRxgleRa4Dy9loIDmJu3bVcBgUOFakfWQN50AGCtMR8kQAIF8ObOH5eCJuCsR JY+ghhMh/jtW9DmPGvTe4gMYy/4oGsxCuYqDPusr4bCcnLZJqDtqTwmWAmtP78ucCbIj 93JHEbw/gAHnGFmvv1JKN8jEs3EQtZ9lvLoOFbraz0m3RgsFrpCoV0ZqlJp8nsTKMpjL mxE8watwGe+A2JuAS7wjLYbv08XHFzPIZHvxEfUNWGkFg7qT47A2Kk9GY/DSC0nvoKQi 6ZpOIXUtAYBGY00/iF7vdfu1BfvS8mbL7qFy5eCXyLVfLGyPL7FAsKzEflNhu/CDMgn1 bT+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=WxHM+wlQ2TdrhljFSnwjlwNMe+t/5gxyxupinxVkkXM=; fh=TVDrhdoqNAxH0wpJ9ZEmDYHDa8iYa9dAsuS6r9YAQgA=; b=UYZhhn0ypK18sOg+lxbNqcBldF7/W9SRmbrmU7HIAk9kN/MGqb5ivqovCZKziumPXY QiiI7XNeX6ufqK3hi+OcbfqyUzgfssCg31fsSZE2JMl9twgzePyicpryzr/AYga7zivp 9tl+WnKA1SJTXsJQCPSHVV8IOr4NpRJpF4bbM+1omkBkekwQhTSu4+n2KcQhqgvNCCQT iCR4YRAt+bEhRARV11p1u0R+lu1sy4Xn85qSgoQZ+7sz4VWA2O06q5MlwJnSxjizoNvO 4wnWaPByeggH1LzxPlgvc0bRAigCJXpXPhmpSwDbJ6lzHD6rwU6ezODRvot7+qtg/un5 e6HA==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1789131653; x=1789736453; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=WxHM+wlQ2TdrhljFSnwjlwNMe+t/5gxyxupinxVkkXM=; b=gZwdViD1rVoGEScuU3u/gFR+IrOVwLDMQp29hPWaCErNJnBB46lfRi+mhPpLz5E3H7 xj/pHlxT9V4O0ARHqGWp6czIz377vWwolclDsPxIL9GFcw/kDR+5UzNNHRIUmthoa3ZK PaIRa1Wsb4kj7rdHhC5u2eWmxtkcRGIq2oPGAgsatCTWDIMICGHthlA6Mgl5AKx5ToCH N900CVDosj7PPOMOWF8eJpLMYy+A2KcCMY5N7zpn5xs+H6dKxI/mD042NMLzpZlRNOQr M+dJN8/VlPVa5vZpsiJolYsZdFwyKIdkxIjR9eXRVg2JaVbi3uTjgA/A7S0Wq3gWg2Ye wg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789131653; x=1789736453; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=WxHM+wlQ2TdrhljFSnwjlwNMe+t/5gxyxupinxVkkXM=; b=NnT0B1BUtYCdhhsTRrPjcIOCju+crTt1hyIMKT0+DfH+gX5NvcadCF/CGuZz4wR0an SiiIjf1TGUuMwtxCLGsrOeLk69en4cvYunlZ2w472WQuUlssXCOl9PR7+XeTBg3ZThCa JQAkAH8J6ntqzsObZ08tM/V4hxlGdixjmpjCRyaqwR2hv+ZX5hn11boj23oRPAonSG0g R3vXGszQQogx4A6ylCC7RrEVpF0fOJxyDHCtUyv+EyDmUEpkfobtFe577TzinlLshXP1 B3MYf641sh1Ka9ZiAkFmVKPjnZsy+CtYDySvsLokEp+L0ovjHr3aiz3E3DZyeTj8BsnN 45Ww== X-Forwarded-Encrypted: i=1; AKwUvByKOTwG/tCjW2ShRXhIXWmvZ0cMxe+WrCxOQRaRJzG7a8/xkL2agQKZ46pQZuyQTa2jzVDsbt+5Joc=@lists.xenproject.org X-Gm-Message-State: AFuF++lxTpeAm8CMT46ZNSHffkwh8LhAdIrkQsbYf96VUhKNMiraGHeB fRgenP/KS9PO723XeLSyvNravdnguPVyfB3kvpjBGeU5qlm9IMuCHheBoFdxt530Fbd8s3lN9hx BgB/hb87tr1NpGNg10dSl+fRL8/grkQbSNxbvCa9KVQ== X-Gm-Gg: AYBFou0vIzUAx8UxXp0+BnLYJnUpZBxBLhbWqyoVqgn8QFOFYKjtg4CrH7dcgKpHOhZ XPp10B1o1UVTxpJf/PWjgYmQCsR1DDs2SUMi5PTczHloaI8lS8rUl9Xdt5RWfUjbAmsWNP32OUQ Uo3K4AWF1S0pps2WI0kThWAB2mu4Avt7MyuqRvBP6DpRImWe9Ui1nQorwTOhD83Y/ivu1WiwcmD bMxND+fd9bAsBWmGCAdMd6oKIoFv5FzURI6kXAlUL+RRcHYTS22l28hIbFwV7uvuXKQk+Mc4sHK Lis8obRhggo2vuq2tQ8/ywuntSiCdxYz67FCqH8DFTpo3KxoN7klfMWxdO8FJEf1JEaD3k+MMyN 4kRjzL8eEBloH0rbLMHI+cvbSijMj7ESaxEpApP6cO6gVV53vrqE= X-Received: by 2002:a05:690c:e0c6:20b0:873:5bd1:98b1 with SMTP id 00721157ae682-884b200e48bmr9947357b3.35.1789131652631; Fri, 11 Sep 2026 06:00:52 -0700 (PDT) MIME-Version: 1.0 References: <178912129220.24041.799369954881004447@citrix.com> <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> In-Reply-To: <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> From: Peter Maydell Date: Fri, 11 Sep 2026 14:00:40 +0100 X-Gm-Features: AcwNN1UD6WyzSYiyF8z4E4bjvAWesRcmuGD_I_BhnuBcZ3oWjMcK3v6xdeMpvG8 Message-ID: Subject: Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc To: David Woodhouse Cc: mark.syms@citrix.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org, edgar.iglesias@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-16d1c6/1789131654-1F4C977B-25CED8DC/0/0 X-purgate-type: clean X-purgate-size: 1027 On Fri, 11 Sept 2026 at 13:32, David Woodhouse wrote: > > (Help! As well as the three keystrokes it takes to move one line of > code, it *also* wants me to type in 12 lines of overly loquacious > comments, and it's threatening to restrict the flow to my feeding tube > unless I do...) > > Claude here (dwmw2's AI assistant; he'll follow up himself and any > patch will be his own work =E2=80=94 more on that below). Please don't send LLM-generated text to qemu-devel. Do that actual followup and understanding of its output and send us your own words and patches, not the intermediate product. We allow LLM-generated stuff in bug reports because it's better than not having the bug reports (though even there it would be nice if bug submitters looked at the LLM output and applied some human udgement rather than directly spraying the output at the bug tracker); but I do not think we want to dilute human-to-human communication between developers with LLM output. thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:05:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:05:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416663.1645629 (Exim 4.92) (envelope-from ) id 1x50wo-0004N8-1U; Fri, 11 Sep 2026 13:05:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416663.1645629; Fri, 11 Sep 2026 13:05: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 1x50wn-0004N1-V7; Fri, 11 Sep 2026 13:05:41 +0000 Received: by outflank-mailman (input) for mailman id 1416663; Fri, 11 Sep 2026 13:05:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50wm-0004Mv-Qf for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:05:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50wm-005pvc-7S for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:05:40 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3fc9e-8faa-0a2a0a5109dd-0a2a450a9382-16 for ; Fri, 11 Sep 2026 15:05:40 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3fca4-f2d2-0a2a450a0019-4a7de18cbbb3-3 for ; Fri, 11 Sep 2026 15:05:40 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e64ccso6723485e9.0 for ; Fri, 11 Sep 2026 06:05:40 -0700 (PDT) Received: from [192.168.1.109] ([85.107.101.132]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e60a8a89esm73262655e9.1.2026.09.11.06.05.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 06:05:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789131940; x=1789736740; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1zmE59oDQYCOIkXrARnvd4zfPyqXNyb7u5+pGaoGcC4=; b=sUf0Cbvd+Z7g1KZvrDt8gComDbiFn9+jKM+dFlyaRQOIAEv7v0mKl8rWrsLMrmmsp5 bcFmO+VKOaBmyMHVRJrJz8nf8LQgKPZgJCq4uObGCt0rJ9k+olIhMdvRACLdpXRI9Pzr vbgK7a/WD2t3i2x/1opsU9jdan/FkyO7gdIspAWoQ4zl/0zN3+fgUL0YBxz68gE3vaqd KwTi/4HbWlEIMzZ/hHmQ+y5BrxYxIXP9upZNv81jm3dqGr0SH4JXj0leVT5zrdLClH29 Ta4S8t90cMDdLOPs6HiT3cFagWSwZQnarg2Ye5/47BBGXNoXDWkYUk9RNK34hFAiUvvl +SUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789131940; x=1789736740; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=1zmE59oDQYCOIkXrARnvd4zfPyqXNyb7u5+pGaoGcC4=; b=X7ZYiAht1064CN34PEcavmvxGohiJOIhzIjRtzWVK2ugqVn2sSKUMHoEBaE2bEM7rJ FCx0n4NrcUmo0UU4I9507RcI4berSDBvUJdEgdih6oInh3QKiAweg42HNJDSZWvCdqlg w8QPnncpw/8Valq9shLBJSUIqSwHX3wnru7fi3qQJRcn70p/QAstEE4l1D2qKZody5Cb Jb/RwgMn+TPmncKC4fuY/KrMe3Os7Khed/F4kB++TIUFy96BsipKie3hdrwoMDXvQsEj nidowTA0gPV5GuHy/ww7gvClC7gdgQQsAu8er1USVz8/4fxFb0Jtp11+9sKhO8YwmbzY S0UQ== X-Forwarded-Encrypted: i=1; AKwUvBxMQR4DOnBX7XdzBdYlveS2jud18RyKQKVeslZPj0B6fkhueJdQIIzzGfvc1C90PRL7RnmycxuFQKs=@lists.xenproject.org X-Gm-Message-State: AFuF++nXn1XLPJT53NAtMt3Ol8M/gWolBqkUdcpipeFOoM1ekAs7e9jd 5ExCZqMfLU0pPZO3fmuhJt0oucvKu4M6Or8hOJtayHOI/2jbB5pI9gwC X-Gm-Gg: AYBFou3pbMFlnJWvYU0EfrEiDPjG8wPss6JqUjxFz2+1iM6BesCETZkGtyPTojBW4VH kvj2neWGFhvolUZragd7sv4l62wTRwub1+zIh3rh5+CqU0gFKH0RxVkp6jpJiqQx1cHVqlr76My fsZIf2lJWixp4/B28WclluHqYLi5VMndPPh0ZP6Wdj2My4Zdi+uWrQdJ0+6RdPhpyMhfQqdSCJB zWbq6X7KMetuc9FfQqoweL88VSiQUYRXcnUIHcd80ZOfqzu2XwZJpnmLbeI8yubp0nLWxF8nTdJ RKDOpxrk8L8taPLvfK9iZGDkIOjBRpknllcIKUZevm3gi+NSvJaJj4+xU3b92sa1D+fqJbxHeOm TdWGTzb81pIbtpClOLbckhQuRSW55JfgtXKP+GFy6CPpqSke7iwRurnAeZktIR+Vk8CmLR/uDvF GqJhzBfKYuLGedBvahvrc1OfDT+9uETHfcWg2vSstI4fSr0JARGh5CqnDRieFqNvdeuus7B/FMF kQ4Eqk= X-Received: by 2002:a05:600c:19c8:b0:499:b65e:49c9 with SMTP id 5b1f17b1804b1-49e619f3ae1mr87489695e9.10.1789131939528; Fri, 11 Sep 2026 06:05:39 -0700 (PDT) Message-ID: <8f9dee8f-b973-4b64-81be-f600103b0a3f@gmail.com> Date: Fri, 11 Sep 2026 16:05:35 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] xen/sched: rtds: add per-cpupool admission control To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <7fb66cfd-b1b0-4f58-b35c-229aa679f737@gmail.com> <1a24d3e6-8ea5-4016-b795-ce1bc9a63fb7@suse.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <1a24d3e6-8ea5-4016-b795-ce1bc9a63fb7@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1789131940-4ACDBCFC-D2B37286/0/0 X-purgate-type: clean X-purgate-size: 2952 On 9/11/26 15:57, Jürgen Groß wrote: > On 11.09.26 14:25, Furkan Çalışkan wrote: >> >> On 8/26/26 07:57, Furkan Caliskan wrote: >>> RTDS currently has no admission control: nothing stops the sum of >>> all admitted units' (budget/period) reservations in a cpupool from >>> exceeding what its pCPUs can actually provide. Once that happens, >>> the global-EDF deadline guarantees the scheduler is built around no >>> longer hold for any unit sharing that pool. >>> >>> This series adds admission control to prevent that, tracks and >>> report utilization, and makes the check toggleable per cpupool so >>> an operator can disable it if they intentionally want to overcommit. >>> >>> Patch 1 introduces the core mechanism: a running utilization total >>> per cpupool, a fixed-point representation of a unit's (budget/period), >>> and a capacity check enforced in rt_alloc_udata()/rt_free_udata() - >>> the lifecycle hooks that catch every new unit's default reservation. >>> >>> Patch 2 extends the same check to domctl, so growing an existing >>> reservation via xl sched-rtds is checked too. >>> >>> Patch 3 reports a cpupool's admitted utilization agains its capacity >>> via the 'r' debug key. >>> >>> Patch 4 makes admission control itself toggleable per cpupool >>> (enabled by default) via sysctl. >>> >>> Patch 5 wires that toggle through libxl and adds -s/-a to >>> xl sched-rtds, and documents it. >>> >>> Furkan Caliskan (5): >>>    xen/sched: rtds: add global-EDF utilization admission control >>>    xen/sched: rtds: enforce admission control in xl sched-rtds >>>    xen/sched: rtds: report utilization and cap via debug key >>>    xen/sched: rtds: make admission control cpupool-wide toggleable >>>    tools: expose admission control toggle via xl sched-rtds >>> >>>   docs/man/xl.1.pod.in                 |  20 +++ >>>   tools/golang/xenlight/helpers.gen.go |  23 +++ >>>   tools/golang/xenlight/types.gen.go   |   4 + >>>   tools/include/libxl.h                |   4 + >>>   tools/include/xenctrl.h              |   6 + >>>   tools/libs/ctrl/xc_rt.c              |  40 ++++++ >>>   tools/libs/light/libxl_sched.c       |  46 ++++++ >>>   tools/libs/light/libxl_types.idl     |   5 + >>>   tools/xl/xl_cmdtable.c               |   8 +- >>>   tools/xl/xl_sched.c                  | 103 +++++++++++++- >>>   xen/common/sched/rt.c                | 205 ++++++++++++++++++++++++++- >>>   xen/include/public/sysctl.h          |   5 + >>>   12 files changed, 463 insertions(+), 6 deletions(-) >>> >> >> Hi Juergen, >> >> Can I get a review on this series please? > > I was quite busy preparing for Xen summit. I'm planning to do the review on > the train to Munich. :-) > > > Juergen Okay, thanks Furkan From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:06:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:06:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416670.1645639 (Exim 4.92) (envelope-from ) id 1x50xP-0004x0-Cy; Fri, 11 Sep 2026 13:06:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416670.1645639; Fri, 11 Sep 2026 13:06:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50xP-0004wt-9Q; Fri, 11 Sep 2026 13:06:19 +0000 Received: by outflank-mailman (input) for mailman id 1416670; Fri, 11 Sep 2026 13:06:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50xN-0004vR-BH for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:06:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50xM-003p7L-Nj for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:06:16 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3fcc2-bab6-0a2a0a5309dd-0a2a450a96be-10 for ; Fri, 11 Sep 2026 15:06:16 +0200 Received: from [52.101.65.123] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3fcc8-f2d2-0a2a450a0019-3465417b5a3d-3 for ; Fri, 11 Sep 2026 15:06:16 +0200 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com (2603:10a6:10:519::5) by BESPR03MB610895.eurprd03.prod.outlook.com (2603:10a6:b10:10f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 13:06:14 +0000 Received: from DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908]) by DU5PR03MB10263.eurprd03.prod.outlook.com ([fe80::8c9e:b301:61c0:3908%5]) with mapi id 15.21.0406.005; Fri, 11 Sep 2026 13:06:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nCLyb7EfYRMwUG5suVHV5oosogepWIqrUaC3Hu8DHWX0Upt6ri0B9xzxKKo9HNOL8UswCZBF89+rnZdPt2iG8M7PX9zWq3o3taBV0Nl4YftWxQhKjFwPB2k7gbF+1Ron+6HvuQbuH2bLOOaqXQYrUJfc2ODOtUQHkSxpMhmtF4Jr9xV5gGWulM9NCVZhRYYggE9Q9w24GUpScgNXY5ZJskEqJRT/U6Jnp/NHIb+LYTXaTj404653O7CG9BH4yBaMPkW4yxjzOSvfIwuFmUbDZkHMg/6ucGbMRaAe9OH3QWrkl/zpxpKoeI28V1twhA/govrSRw4xn9VwbiMvaFawpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5K3Fakczljm9GzsN8TcPKbpUXzJbqrxJZwgis0B6h4U=; b=QUX8HkviCcTdXy4MD7BVUjB6U0Cdoq+5ig/NnmYaK2iISVdpNOqdvobKQsLqwPsiHBQ0Olj6WNlxMdaILx7pRE1Tc119LCEC7pOF3dlo353/hYq/0FjYY0i2xBFFvNWvLGI2MOiE1yqrNebxuMITCt54MmqGbXYi/mhxVb7Ohwuy7121luFcQ22Kq7u3QxBnCnZD9Qp1D7Tk8rzS1pS+FhQhth/PnTjxA/Zy0gtK6EfjWix4qdNEUnwxS66NBbUeFJdlyAyVQ/2ry8cQ+9JwpBr1ZnHd7o7RAK8S7kmjR7u0ZWXTocUFrQ+U3QhoYzPZwZTRgm3pko1jnhmfAWc/KA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5K3Fakczljm9GzsN8TcPKbpUXzJbqrxJZwgis0B6h4U=; b=RuxIOKgglUBS7KZeNUrxnfqcuLdghrnu1xGf6wBJHY5t6+T/Uhd/oyKxveDU77+pJB5Z48OvJwrj8Qxm2/SfdER5TyMfqOUFcEDd15NdcXjwJaPrKYn9NHg3El/Z2NTnbDK7yT9UEU6ppuJhmZ5PKl5v5t3U4IV4GBKuo82vWhyWY5QO5qLqQyLMrRhUktBsdlZgiD3I5hZbRhyWXEVKw8/jc+II0VADWI9WSUM9AhpSPze4wbFFQpbJNJGIyG60wVc27ickmZAG+k2fHIOYltHJX6/dMKzUDONE/INls7YlHMJ0MYAQRGh6uHKZ4K9ffCkUQTeYCRVtQir4xTWO1w== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers Thread-Index: AQHdQb7XwQvbnxLqDEGK19PLXXgae7bJAQCAgABYGQA= Date: Fri, 11 Sep 2026 13:06:13 +0000 Message-ID: References: <6bf8f9dd61da4d0fbea096b863f51db08df46c56.1789055542.git.oleksii_moisieiev@epam.com> <1d8be2c2-a56d-4b81-8e36-c4f97099c879@suse.com> In-Reply-To: <1d8be2c2-a56d-4b81-8e36-c4f97099c879@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU5PR03MB10263:EE_|BESPR03MB610895:EE_ x-ms-office365-filtering-correlation-id: 1576ef53-df90-4c30-93e7-08df10057573 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|7416014|366016|11063799006|56012099006|3023799007|4143699003|22082099003|38070700021|10067099003|18002099003|6133799003; x-microsoft-antispam-message-info: YvEbQ0307raUXcDXnSREEbhOsGDhJvfaYP0SF+tRwZCPoYSen9o+8RJcfbGZq0hoigIC64ZF8pszXJ47Qx6A2Rsv3pftnhVOzDLDieNWhzK7GBWVaHYiNMBUhHwk4zOAjrz+uESn0dbrTs3JniBp7ClTgQ1EYa4xcAVqLsqmsGpAqf0wT2J8G7deElv00lxM/0uA24I031cQdb6MXnQQeQqrtLgbVdG+Vw7sIzxs/e4zunpRMpUK8/h1gqioJ9rC6ALlZV2bQtbP6GL87I+ooq7BCM3VLyLfV260WTaDI2OXg73nD5+vcGoSLhafnAHPmIWrYkSGSb3Kb1928v3/sFnVNhwrAOeV+xZ/19dJqU1lzuUuhx22VYyLw8a7MHs8PN7mGcKUZw5qjalV1DbmyQ07NPkhHm3CFk6NDK5rg1vIEDVrBaYh7vq6ey6DaLpAUUN9OFQ6VA5+dSoC5220lXmk5x14MflSTshdtqhgbVpD6XqokWJJiWHUl6gum33+Qr9Pp7iJ2Z0A5Q90eHGTTmpiNomNcFx83vhN3TzLzba928y3KSd5fjXL86+yPAPtwNi/+m7uRfney+j76egFFGvA/dSrsrVuqlztE78OzzLTG5VDAyYOv8+YIDTPwe+4DjqFAFeXSp2QlB9GwlOgj7OdvvZQwFPEZCcnjXAbNmo= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU5PR03MB10263.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(7416014)(366016)(11063799006)(56012099006)(3023799007)(4143699003)(22082099003)(38070700021)(10067099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YTZnRG1yc29DeVdJNkFTT1hvdno0dHhUZlhrWlEvdXFwNG84SExENTlSaUtI?= =?utf-8?B?cU1laFBCb2dIUHF5eUdnS1dPVUlIZTBCZ2IySEhadHJwREdzL3VDcHExRDc4?= =?utf-8?B?TGg5MkJrTjRqTURpV2J0QktoTHNFOWRGZEF4eW1TTDVYenQ3Q1N0YWxPMFE2?= =?utf-8?B?QWpQNE1rQzhlWG9aVjdPMld2VlRmNDd4UTZhTExmK1ZBQ2JqSVVNaVo2WkE5?= =?utf-8?B?a0NFemZOWUxzeVhGa2syZXk2TitweEZpdzJyanc4aG5QQmNXNkRMODY5dG15?= =?utf-8?B?S0NWZWtoSldWWmJweElRV1RkSE1QTFFIRENGWWtxU0poM1AxWVB5MEVVZzkz?= =?utf-8?B?U1pBNGN4Mzc2REFiNXgwdkEvb1RxU3cwYnVEMnR6L1JnR2czN3F2cE1yQ1ZB?= =?utf-8?B?QW5CdjkxaERtUmhXQ0hVT1FzYlRLTVhaMk94YXFkUmJHYUZUMU9mNGlsek41?= =?utf-8?B?b1d6UzZ3ZXlnVG11bnpUNGpiT0MrYjdvVjZRUGNTY0Z0YVhOaUlRcmVvQktM?= =?utf-8?B?ZWR1RmpDQlRhcktEY2J1eDJHY2ZjN2ZGd1Q1OS9iaGk1ZUdXQlVuUTlrampT?= =?utf-8?B?Z0M2dkVuOW55dHFlSEEyNGRzSGVBMEtIOUQ3bERhT1lYYTRweERnSmxPb2dj?= =?utf-8?B?ckI1YXF2WlhyZDlMTTN6blRzMGRYYnBPaTZQUWk3UFg3eUFRTVVqdVBaR0w2?= =?utf-8?B?dkdQWEc4RVR6cGR6TGhNT3Zpd0ZpQytMcGRCdEV5blQxNmd2a1BDTTlhYXdh?= =?utf-8?B?QTV2RG5MZnhUYnpMSVR5cllwckpWREhkSGJoM2MrK1ZLQkR5TUkzOEh6VHlh?= =?utf-8?B?ZGJPZjVZMnpPcFZTRjlvaUlmelk1NXVUYTE1cXVIYmx0RUsvYWhYRTBSTHIx?= =?utf-8?B?Ti9uT2JkeFBFTnVpMkpzeE1SdXU4S0k3T2YwUDVSWkUwdWxBS3pLamFpWENM?= =?utf-8?B?UGNJTnBkUkVlSW9JSkNtV3F0TTJLL1JxTU82VExzSFlHbzErYmswWEx5Rzlz?= =?utf-8?B?Z0NHbTAwR0Y5U3lJeE0rYUdvKzRuZHI3a2FLNkRrV1cya29rWE1PNXNUT21J?= =?utf-8?B?NVFQS1BnWjgrVVB5Y010WW05QkFTM2MrbkhtRWlJbzFITGhaSTBNSU5JY0Vl?= =?utf-8?B?MXdBVmo1dlc0WTdDNnJBN1g2OUQ5VUZ1aERsUWdSVjFzakVhaFgyUzNJempw?= =?utf-8?B?OGo1dStNYjVaUWY5VHFmZ0Q2bCt6VXlHYXd4a05yQXVDRTdBLzdvaUlZWWF6?= =?utf-8?B?cXkzamROcFpydEt6STBPQWEvL0JVSlVySk9SSnBTb3BpMTh1WEpiYUJyTkkv?= =?utf-8?B?UnZMQkhpVDBiM29CMytpWjZyMEtEVjVNcWo4WUZoUCtiL3pqamM2M2IvdWlt?= =?utf-8?B?MjBIdTNRRUVFZVJRMnlOSU1paytRVUNFU1RPSityU29GWEVTU0FoQzlQRzVk?= =?utf-8?B?UU9HK0dxK1NSV2kyYW10czdMZjhocUhteFdXWlVHVzl6RTJTVFp2dGwraG9n?= =?utf-8?B?UmJNUDRlWExSanYxWUpSdHpQSUJNN2x5UmZPUXJuNUJlVytkc3k5L09KbmVj?= =?utf-8?B?bVlkWTZUMG14bEI5SXVEUXJEZUlFY1Y3VlJ2bU5Mdk8veDBhM2xoYU01dk5S?= =?utf-8?B?S0EzTExHQUxWTE1oczUzdHp1K0NodU5mK2I0dWsxd3FoZ3VVaUh3YVpDdXRx?= =?utf-8?B?Sy9RUjIwWW1SRkwrRWNNdmpPUVJxNXdyWWd1bVl6SFM5azhHVTJMU2RZTk9l?= =?utf-8?B?VUk4MzhXWUFnWklOanFhS2RpTU53dmJTV2Z4Mm9pUHArOXd0VUV5Znp1b0RP?= =?utf-8?B?Q1F3Y0oveFBvTEZWV2xUd3Jzb0wycVFaVnNiN0tPQnRxZG8yczdDVDBSZXdE?= =?utf-8?B?RlZ3eGhmWVp1bmpROTNwMjg2UzNMcGdMWVA2a1ZObHhFSk9pWXN2YUNLdTFm?= =?utf-8?B?Q1d3WVpTcXFtOUJIaGtyNnBVMDFsMWpRT0Rkcmd1YjdMb3YwZ2RnY3RCek15?= =?utf-8?B?UEVuejBoenN3aG02d0R4Vm1zSGFVRjhPR2xIbFNvMVh6eXNIczZhbnkxcUdU?= =?utf-8?B?dVdKbmIzaVl4VnNaUUZDUGxXTTE1dEV1WDRkL2VJc0RvR3RZM0xSZDU2RHYy?= =?utf-8?B?T1A0MFJCSmF5T1RadDVWeS80dnVKM1RhaGVmb2RLNlM3NU1PMFdXbCtZL0Rm?= =?utf-8?B?NmV2U1NBNDVGL3NwcFI2bHRSM0IvdGZFYXk4R215MkxldVVGWksxMHIyall2?= =?utf-8?B?UFhvUFhRdW1ZUFBmeUZQMnZSYzBUa1Q3S2JBUE80Q3BCb21IcGtKczJWRlZS?= =?utf-8?B?d0lXdWlVb1Q2ODFtZWd4citJTmY5Q1pjckdvZlBldkkvWStCN0ZVd0NpTkMv?= =?utf-8?Q?DraElMUl9jbPWjik=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <555389FB96A39B498E55C8C8C00A3019@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU5PR03MB10263.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1576ef53-df90-4c30-93e7-08df10057573 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2026 13:06:14.0631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p4ixhUhLBAI9cIB1FlzsD/HGlAwS4CMEKmCvNT9gpecag0yUMw1tnzyeWm2fcqZRQZl/ZLhbRXMsCEGkN5pxVm+/3sk8/jupYsrreJhL1is= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BESPR03MB610895 X-purgate-ID: tlsNG-4011c0/1789131976-4A9D9CFC-EA094E19/0/0 X-purgate-type: clean X-purgate-size: 7554 SGkgSmFuLA0KDQpUaGFuayB5b3UgZm9yIHF1aWNrIHJlc3BvbnNlLiBwbGVhc2Ugc2VlIGJlbG93 Lg0KDQpPbiAxMS8wOS8yMDI2IDEwOjUwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTEuMDku MjAyNiAwOToyNiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBJbnRyb2R1Y2UgbWVtY3B5 X2Zyb21pbygpIGFuZCBtZW1jcHlfdG9pbygpIGhlbHBlcnMgdG8gY29weSBiZXR3ZWVuDQo+PiBy ZWd1bGFyIG1lbW9yeSBhbmQgTU1JTyBzcGFjZSBvbiBBcm0uIFRoZSBnZW5lcmljIHByb3RvdHlw ZXMgbGl2ZSBpbg0KPj4gaW8uaCBzbyBvdGhlciBhcmNoaXRlY3R1cmVzIGNhbiBwcm92aWRlIHRo ZWlyIG93biBpbXBsZW1lbnRhdGlvbnMuDQo+Pg0KPj4gVGhlc2UgaGVscGVycyBoYW5kbGUgYWxp Z25tZW50IHNhZmVseSBieSB1c2luZyBvcmRlcmVkIGJ5dGUgYWNjZXNzZXMgZm9yDQo+PiBhbnkg bGVhZGluZy90cmFpbGluZyB1bmFsaWduZWQgYnl0ZXMgYW5kIG9yZGVyZWQgMzItYml0IGFjY2Vz c2VzIGZvciB0aGUNCj4+IGFsaWduZWQgYnVsayB0cmFuc2Zlci4NCj4gVGhhdCdzIG92ZXItc2lt cGxpZnlpbmcgdGhpbmdzIChqdXN0IGxpa2UgY29kZSBjb21tZW50cyBkbykuIElmIHNvdXJjZQ0K PiBhbmQgZGVzdGluYXRpb24gYXJlIGVxdWFsbHkgbWlzYWxpZ25lZCBtb2R1bG8gNCwgd2hhdCBp cyBzYWlkIGlzIHRydWUuIElmDQo+IHRoZXkgYXJlIGRpZmZlcmVudGx5IG1pc2FsaWduZWQsIHRo ZSBlbnRpcmUgY29weSB3aWxsIGJlIGRvbmUgYnl0ZS13aXNlLg0KPiBXaGljaCBjYW4gZWFzaWx5 IGJlIGEgcHJvYmxlbSB3aGVuIDQtYnl0ZSBhY2Nlc3NlcyBhcmUgcmVxdWlyZWQgZm9yDQo+IHBh cnRpY3VsYXIgTU1JTyBsb2NhdGlvbnMgKHdoaWNoIG1heSBlLmcuIGFjdHVhbGx5IHJlcHJlc2Vu dCBkZXZpY2UNCj4gcmVnaXN0ZXJzKS4NCj4NCj4gQXMgc2FpZCBvbiBlYXJsaWVyIHZlcnNpb25z OiBJIHRoaW5rIHlvdSBlaXRoZXIgd2FudCB0byBnZXQgbWlzYWxpZ25tZW50DQo+IGhhbmRsaW5n IHJpZ2h0IGZvciBhbGwgcG9zc2libGUgY2FzZXMsIG9yIHlvdSB3YW50IHRvIGRlbWFuZCBhbGln bmVkDQo+IGluY29taW5nIHBvaW50ZXJzLg0KPg0KPiAoRnRhb2QsIHVzaW5nIGJ5dGUgYWNjZXNz ZXMgZm9yIHR3byBvciB0aHJlZSBsZWFkaW5nIC8gdHJhaWxpbmcgbWlzYWxpZ25lZA0KPiBieXRl cyBjYW4gYmUgZXF1YWxseSB3cm9uZywgd2hlbiB0aGUgTU1JTyBsb2NhdGlvbiBhY2Nlc3NlZCB3 YW50cyB0byBiZQ0KPiBhY2Nlc3NlZCB3aXRoIGEgMTYtYml0IGxvYWQvc3RvcmUsIGZvciBiZWlu ZyBlLmcuIGEgMTYtYml0IGRldmljZSByZWdpc3Rlci4NCj4gU2ltaWxhcmx5IHVzaW5nIDMyLWJp dCBsb2Fkcy9zdG9yZXMgY2FuIGJlIHdyb25nIGluIHRoZSBnZW5lcmFsIGNhc2UuIElPVw0KPiB3 aGlsZSBzb21lIG9mIHRoYXQgaXMgc2FpZCB0byBhIGNlcnRhaW4gZGVncmVlLCBJIHRoaW5rIHRo ZXJlIGFyZQ0KPiB1bm1lbnRpb25lZCBmdXJ0aGVyIGNvbnN0cmFpbnRzIG9uIHdoZW4gdGhlc2Ug ZnVuY3Rpb25zIG1heSBzYWZlbHkgYmUNCj4gdXNlZC4gRm9yIGV4YW1wbGUgImRldmljZXMgdGhh dCB0b2xlcmF0ZSA4LWJpdCBhbmQgMzItYml0IGFjY2Vzc2VzIiBpcw0KPiBzdGlsbCBhbWJpZ3Vv dXMgYXMgdG8gd2hhdCBleGFjdGx5IGl0IG1lYW5zLiBOb3QgdGhlIGxlYXN0IGJlY2F1c2UNCj4g InRvbGVyYXRlIiBkb2Vzbid0IG1lYW4gIndvcmsgY29ycmVjdGx5IHdpdGgiLikNCj4NCj4+IFVz aW5nIHRoZSBvcmRlcmVkIGByZWFkYi9yZWFkbGAgYW5kDQo+PiBgd3JpdGViL3dyaXRlbGAgYWNj ZXNzb3JzIGF2b2lkcyB1bmludGVuZGVkIGVuZGlhbm5lc3MgY29udmVyc2lvbiB3aGlsZQ0KPj4g cmVzcGVjdGluZyBkZXZpY2Ugb3JkZXJpbmcgcmVxdWlyZW1lbnRzIG9uIEFSTTMyL0FSTTY0IGhh cmR3YXJlIHRoYXQgbWF5DQo+PiBub3Qgc3VwcG9ydCA2NC1iaXQgTU1JTyBhdG9taWNhbGx5Lg0K PiBJJ20gaGF2aW5nIHRyb3VibGUgbWFraW5nIHNlbnNlIG9mIHRoaXMgcGFydC4gV2h5J3MgZW5k aWFubmVzcyBvZiBjb25jZXJuDQo+IGhlcmU/IFRoZSBhY2Nlc3NvcnMgdXNlZCBkb24ndCBjYXJl IGFib3V0IGVuZGlhbm5lc3MgYXQgYWxsLCBhbmQgd2hhdCBtYXkNCj4gaGF2ZSAod3JvbmdseSkg YmVlbiB1c2VkIGluIGVhcmxpZXIgdmVyc2lvbnMgc2hvdWxkbid0IG1hdHRlciBoZXJlIChvciBp dA0KPiB3b3VsZCBuZWVkIGNhbGxpbmcgb3V0IHdoaWNoIG90aGVyIGFjY2Vzc29ycyB3b3VsZCBi ZSB3cm9uZyB0byB1c2UpLg0KVGhpcyBpcyB0aGUgbGVmdG92ZXIgZnJvbSB2NyB3aGVyZSBfX3Jh d193cml0ZS9fX3Jhd19yZWFkIHdlcmUgdXNlZC4gDQpyZWFkbCgpL3dyaXRlbCgpIGluY2x1ZGUg bGl0dGxlIGVuZGlhbiBjb252ZXJzaW9uIHRocm91Z2ggdGhlaXIgcmVsYXhlZCANCnZhcmlhbnRz Lg0KaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vY292ZXIuMTc2ODQxNTIwMC5naXQub2xla3NpaS5f NUZtb2lzaWVpZXZAZXBhbS5jb20vZDE2NjM0ODUzMGI5MjI5NjczZTFhNmUzYjI5ZmY0ZWU5MTIz YWIyZi4xNzY4NDE1MjAwLmdpdC5vbGVrc2lpLl81Rm1vaXNpZWlldkBlcGFtLmNvbS8NCg0KSSB3 aWxsIHJlbW92ZSB0aGUgY2xhaW0gdGhhdCBvcmRlcmVkIGFjY2Vzc29ycyBhdm9pZCBlbmRpYW5u ZXNzIGNvbnZlcnNpb24uDQoNCj4+IC0tLSBhL3hlbi9pbmNsdWRlL3hlbi9pby5oDQo+PiArKysg Yi94ZW4vaW5jbHVkZS94ZW4vaW8uaA0KPj4gQEAgLTY3LDQgKzY3LDE0IEBAIHN0YXRpYyBpbmxp bmUgYm9vbCB3cml0ZV9tbWlvKHZvbGF0aWxlIHZvaWQgX19pb21lbSAqbWVtLCB1bnNpZ25lZCBs b25nIGRhdGEsDQo+PiAgICAgICByZXR1cm4gdHJ1ZTsNCj4+ICAgfQ0KPj4gICANCj4+ICsvKg0K Pj4gKyAqIENvcHkgYmV0d2VlbiByZWd1bGFyIG1lbW9yeSBhbmQgTU1JTyBzcGFjZS4gIEltcGxl bWVudGF0aW9ucyBhcmUNCj4+ICsgKiBhcmNoaXRlY3R1cmUtc3BlY2lmaWMgYW5kIG11c3QgdXNl IGFwcHJvcHJpYXRlIE1NSU8gYWNjZXNzb3JzIGZvcg0KPj4gKyAqIHRoZWlyIG1lbW9yeSBhbmQg SS9PIG1vZGVscy4NCj4+ICsgKi8NCj4+ICt2b2lkIG1lbWNweV9mcm9taW8odm9pZCAqdG8sIGNv bnN0IHZvbGF0aWxlIHZvaWQgX19pb21lbSAqZnJvbSwNCj4+ICsgICAgICAgICAgICAgICAgICAg c2l6ZV90IGNvdW50KTsNCj4+ICt2b2lkIG1lbWNweV90b2lvKHZvbGF0aWxlIHZvaWQgX19pb21l bSAqdG8sIGNvbnN0IHZvaWQgKmZyb20sDQo+PiArICAgICAgICAgICAgICAgICBzaXplX3QgY291 bnQpOw0KPiBGb3Igc29tZWJvZHkgd2FudGluZyB0byB1c2UgdGhlc2UgZnVuY3Rpb25zIGFuZCBt ZXJlbHkgbG9va2luZyBoZXJlLCBob3cNCj4gd291bGQgdGhleSBrbm93IG9mIGFsbCB0aGUgY29u c3RyYWludHM/IFRoYXQgaXMgaW1wbGVtZW50YXRpb25zIGFyZSBub3QNCj4gbWVyZWx5IGFyY2gt c3BlY2lmaWMsIHRoZXkgbWF5IGFsc28gaW1wb3NlIGFyY2gtc3BlY2lmaWMgY29uc3RyYWludHMu DQo+DQo+IEphbg0KWW91IGFyZSByaWdodCBhYm91dCB0aGUgYWxpZ25tZW50IGhhbmRsaW5nLiBB ZHZhbmNpbmcgYm90aCBwb2ludGVycyBieQ0KdGhlIHNhbWUgYW1vdW50IHByZXNlcnZlcyB0aGVp ciByZWxhdGl2ZSBhbGlnbm1lbnQsIHNvIHRoZXkgbmV2ZXIgYmVjb21lDQphbGlnbmVkIHRvZ2V0 aGVyIGlmIHRoZWlyIG9mZnNldHMgbW9kdWxvIGZvdXIgZGlmZmVyLiBJbiB0aGF0IGNhc2UgdGhl DQpjdXJyZW50IGltcGxlbWVudGF0aW9uIGNvcGllcyB0aGUgd2hvbGUgcmFuZ2UgdXNpbmcgYnl0 ZSBhY2Nlc3Nlcy4NCg0KSSBwcm9wb3NlIHRvIGhhbmRsZSBhcmJpdHJhcnkgUkFNIGFsaWdubWVu dCBieSBhbGlnbmluZyBvbmx5IHRoZSBJL08NCnBvaW50ZXIsIHRoZW4gdXNpbmcgcHV0X3VuYWxp Z25lZF9sZTMyKCkvZ2V0X3VuYWxpZ25lZF9sZTMyKCkgb24gdGhlDQpOb3JtYWwtbWVtb3J5IHNp ZGUgb2YgdGhlIHdvcmQgdHJhbnNmZXJzLiBBbGwgSS9PIGFjY2Vzc2VzIHdvdWxkIHN0aWxsDQp1 c2UgcmVhZGIvcmVhZGwgb3Igd3JpdGViL3dyaXRlbC4gVGhpcyB3b3VsZCBtYWtlIHRoZSBJL08g YWNjZXNzIHdpZHRocw0KaW5kZXBlbmRlbnQgb2YgdGhlIFJBTSBwb2ludGVyJ3MgYWxpZ25tZW50 LiBJbiBwYXJ0aWN1bGFyLCBhbiBhbGlnbmVkDQpJL08gYWRkcmVzcyBhbmQgYSBsZW5ndGggZGl2 aXNpYmxlIGJ5IGZvdXIgd291bGQgcHJvZHVjZSBvbmx5IDMyLWJpdA0KSS9PIGFjY2Vzc2VzLCBl dmVuIHdpdGggYW4gdW5hbGlnbmVkIFJBTSBidWZmZXIuDQoNClNvIHRoZSBjaGFuZ2VzIGZvciBt ZW1jcHlfdG9pbyB3aWxsIGxvb2sgbGlrZToNCg0Kdm9pZCBtZW1jcHlfdG9pbyh2b2xhdGlsZSB2 b2lkIF9faW9tZW0gKnRvLCBjb25zdCB2b2lkICpmcm9tLA0KIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgc2l6ZV90IGNvdW50KQ0KIMKgew0KLcKgIMKgIHdoaWxlICggY291bnQgJiYgKCFJU19B TElHTkVEKCh1bnNpZ25lZCBsb25nKXRvLCA0KSB8fA0KLcKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICFJU19BTElHTkVEKCh1bnNpZ25lZCBsb25nKWZyb20sIDQpKSApDQorwqAgwqAg d2hpbGUgKCBjb3VudCAmJiAhSVNfQUxJR05FRCgodW5zaWduZWQgbG9uZyl0bywgNCkgKQ0KIMKg IMKgIMKgew0KIMKgIMKgIMKgIMKgIMKgd3JpdGViKCooY29uc3QgdWludDhfdCAqKWZyb20sIHRv KTsNCiDCoCDCoCDCoCDCoCDCoGZyb20rKzsNCkBAIC0yOSw3ICsyMiw3IEBADQoNCiDCoCDCoCDC oHdoaWxlICggY291bnQgPj0gNCApDQogwqAgwqAgwqB7DQotwqAgwqAgwqAgwqAgd3JpdGVsKCoo Y29uc3QgdWludDMyX3QgKilmcm9tLCB0byk7DQorwqAgwqAgwqAgwqAgd3JpdGVsKGdldF91bmFs aWduZWRfbGUzMihmcm9tKSwgdG8pOw0KIMKgIMKgIMKgIMKgIMKgZnJvbSArPSA0Ow0KIMKgIMKg IMKgIMKgIMKgdG8gKz0gNDsNCiDCoCDCoCDCoCDCoCDCoGNvdW50IC09IDQ7DQoNClRoaXMgZG9l cyBub3QgbWFrZSB0aGUgaGVscGVycyBzdWl0YWJsZSBmb3IgYXJiaXRyYXJ5IGRldmljZSByZWdp c3RlcnMuDQpJIHdpbGwgZGVzY3JpYmUgdGhlbSBhcyBjb3B5aW5nIGEgYnl0ZSBzZXF1ZW5jZSB0 by9mcm9tIGEgbWVtb3J5LWxpa2UNCkkvTyByZWdpb24uIFRoZSByZWdpb24gbXVzdCBzdXBwb3J0 IGJ5dGUgYWNjZXNzZXMgYXQgZXZlcnkgYnl0ZSBhZGRyZXNzDQphbmQgYWxpZ25lZCAzMi1iaXQg YWNjZXNzZXMgd2l0aCBlcXVpdmFsZW50IGJ5dGUtc3RvcmFnZSBzZW1hbnRpY3MuDQpUaGUgaW1w bGVtZW50YXRpb24gdXNlcyBieXRlIGFjY2Vzc2VzIHRvIGFsaWduIHRoZSBJL08gcG9pbnRlci4N Cg0KQW5kIGFsc28gSSB3aWxsIGRvY3VtZW50IHRoZSBBcm0gcmVxdWlyZW1lbnRzIG5leHQgdG8g dGhlIGRlY2xhcmF0aW9ucw0KaW4geGVuL2lvLmggYXMgeW91IHN1Z2dlc3RlZC4NCg0KDQpXaGF0 IGRvIHlvdSB0aGluayBhYm91dCB0aGlzIGFwcHJvYWNoPw0KDQpPbGVrc2lpLg== From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:06:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:06:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416673.1645647 (Exim 4.92) (envelope-from ) id 1x50xV-0005Cx-Jz; Fri, 11 Sep 2026 13:06:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416673.1645647; Fri, 11 Sep 2026 13:06:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x50xV-0005Cq-H9; Fri, 11 Sep 2026 13:06:25 +0000 Received: by outflank-mailman (input) for mailman id 1416673; Fri, 11 Sep 2026 13:06:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x50xU-0005CS-H6 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:06:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x50xT-003pAV-Tz for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:06:23 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3fccc-bab6-0a2a0a5309dd-0a2a4508a9ce-8 for ; Fri, 11 Sep 2026 15:06:23 +0200 Received: from [209.85.218.44] (helo=mail-ej1-f44.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3fccf-f659-0a2a45080019-d155da2cd04d-3 for ; Fri, 11 Sep 2026 15:06:23 +0200 Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-c2544ff970dso142230066b.2 for ; Fri, 11 Sep 2026 06:06:23 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2966066123sm78334866b.31.2026.09.11.06.06.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 06:06:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789131983; x=1789736783; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=eP9Ej9QaQulQbe/bgKPLj+fkdL09Fd17gd2AG8+865o=; b=hkY8KPVIGWnKmAgH3/Vn9jh9vYFMgx/eiH14jskrk5lDGA4Fnom5s9Ih4xcRv1T+yD s6gNelzYzgWS6o7SemK6j2nMGJta9ymNea2bz3ecGL7f9pibSqzMw12V7n6LSBSCpzBx dN4LsWGvGLG1lFWOsgjEmsVetxC1ErtxOS6mfwjNoRlxesVCKMkmWmoxxlng7AIOc3fQ 7SuqIfKOyDJpj7b5RlF9/xeWH7Z+gPuFlaGJvzEhqdBat5hS66sdfrgbVrYRQnZLDvB5 nyC4kp6PApT/U+EmKB8MxAvS5aoUzI9XqVyWLMrWKvMN+yDceAixzHG0dGPVC5+1YlJL RfeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789131983; x=1789736783; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=eP9Ej9QaQulQbe/bgKPLj+fkdL09Fd17gd2AG8+865o=; b=NXoTxyJOuXOcUbcOHtRpE+9DKR3FB+PMn4qxgz1NPZCKmeSSBNrljuv1u/cn5fgDL/ esqLbWo1FlKFrO3by/x5INdlUV8Vl23YTZ/Pca4J3uVuxIZXgOemhvH2QeUH+M4E/ug7 S5zJepChYL1YCED1NvVheoeLhiaZDkYBzBqIl359TgLrl/h9IxbiiPUj22URiCqQMwLK h46bgklY9S8WCKVCP098jSHdiyKmtYpwQAfP+9ryAI7lmMjEcGn2RIqzUV5k4V7181gp BRimz6hGhdRY6hESN0WuhfTc/GaBrSt+NYWCLMqCw1rD8eg4nVQ46apB6pvmjlzkqSil IKTw== X-Gm-Message-State: AFuF++mLVgGL9MvWj6sk9U+HGbFPy7l3zDBeabObghN//DLd6vn7f2ry U9XxyUc5yBvDLNFn/OlK+/yrJjnw4B1NR+R6iNLiLOmodB3rbvebkDdw X-Gm-Gg: AYBFou3K9l/NixWpTaXFEnQERxBh6vA6poEBe93PdwpI2j1sRdJ9DDFLbgoSTq1Uyv7 eEGphjz60OkofnLRUFwKkxmVA2rSeG93STagd1kWj79FukvSiG4GiGuwdX3ws5QXKpZRn5xdaPK +JyjZKfsB96Pi+z194TYyDOOHp7NXcLIn3FZVRb62/DXVHbQ0ZOq1YaUSj2LUjGEDgIHbSOyk7X jFSmH/wIDcIFc743CYeuPEaE0qXOjuBpFbWAVJlrhwcvvNOkYrFoKDZEAc69K8ye2ZFxobvnK68 9PTJH8CEOpGiRAi3V3qxjPGSYIsekRrpK/1WF0KKpvNFl/PHTNc9i29RdkkQy3MawoiSLGejVZn Cnj0I6qXcaoRacZCgBfV5T3snWEDhXlFT7xKRkHXM+d+bWvUSuHZsunhUMGE8ujdcjUzRHkD2Wa 3sUOoCovnjOY0BRRjtokw7UxoNjOj2tWMGq7dOyY/jJ9hR/fRIpJFQR88G6ThBb2I2mobVyEIKp IgV/2uvtqRyNk01fhr4mdSYuMutanqI X-Received: by 2002:a17:907:874f:b0:c24:6390:decf with SMTP id a640c23a62f3a-c29665b7776mr168154366b.16.1789131983141; Fri, 11 Sep 2026 06:06:23 -0700 (PDT) Message-ID: <7b743afb-409d-433b-86b9-7ec8be7ad860@gmail.com> Date: Fri, 11 Sep 2026 15:06:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789131983-CCD7087B-1BB3695B/10/73395122804 X-purgate-type: spam X-purgate-size: 4610 On 9/9/26 2:04 PM, Baptiste Le Duc wrote: >> Introduce riscv_read_guest() to allow Xen to safely read guest memory >> using HLV/HLVX instructions while reliably capturing trap context. > >> This is required for instruction fetch emulation and MMIO decoding, where >> Xen must inspect guest memory that may not be directly accessible and may >> fault. >> >> The implementation is based on kvm_riscv_vcpu_unpriv_read() from Linux, >> with one deviation: the hlv/hlvx instructions translate the guest address >> through the live vsatp/hgatp CSRs, i.e. through the address space of the >> currently running vCPU, so the function can only be called safely for >> current. Instead of taking a struct vcpu argument, it always operates on >> current directly. >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/guestcopy.c b/xen/arch/riscv/guestcopy.c >> index 8a89212e0b..b2327822ac 100644 >> --- a/xen/arch/riscv/guestcopy.c >> +++ b/xen/arch/riscv/guestcopy.c >> @@ -6,6 +6,7 @@ >> #include >> >> #include >> +#include >> >> #define COPY_from_guest 0U >> #define COPY_to_guest BIT(0, U) >> @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, >> return copy_guest(buf, gpa, len, GPA_INFO(d), >> COPY_to_guest | COPY_gpa); >> } >> + >> +/* >> + * Read machine word from guest memory >> + * >> + * @guest_addr: Guest address to read >> + * @read_insn: Flag representing whether we are reading instruction >> + * @trap: Output pointer to trap details if something went wrong during read >> + * >> + * The hlv/hlvx instructions translate guest_addr through the live >> + * vsatp/hgatp CSRs, so the read is only meaningful for the address >> + * space of the currently running vCPU. >> + * >> + * At most two halfwords are fetched when @read_insn is true, i.e. encodings >> + * wider than 32 bits are not supported. Such an encoding cannot be completed >> + * by calling this function again at @guest_addr + 4: the length check is >> + * applied to the first halfword read, which would then be a continuation of >> + * the instruction rather than its opcode. It is up to the caller to reject >> + * anything that is neither a 16- nor a 32-bit encoding. >> + */ >> +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, >> + struct trap_info *trap) > Nit: every other function in this file / declared in this header > (raw_copy_from_guest, copy_to_guest_phys, ...) has no riscv_ prefix. Why > does this one get it? Agree not to much sense. I will drop it. >> +{ >> + /* >> + * Poison the result: if the very first access faults, the fixup skips >> + * over the loads without writing it. Callers must check trap->scause. >> + */ >> + unsigned long val = ~0UL, tmp; >> > The actual "did a trap happen" contract callers rely on is > trap->scause == 0. If the very first access faults, fixup_exception() will > write scause accordingly to a non-zero value, but nothing in this function > clears trap->scause on the success path. It is because caller is expected to zero-fill trap as it is happening now. I will mention that explicitly. I will do the following: - * @trap: Output pointer to trap details if something went wrong during read + * @trap: Output pointer to trap details if something went wrong during read. + * It must be zero-initialised by the caller: it is written only when + * an access faults, so trap->scause == 0 on return is what tells the + * caller that the read succeeded. >> + >> + /* >> + * hlv/hlvx use hstatus.SPVP for the privilege of the access, and the >> + * live vsatp/hgatp for the translation. Xen never installs a value of >> + * its own in hstatus (it is only saved on trap entry and restored >> + * before sret) and it doesn't reschedule before returning to the >> + * guest, so all three still belong to the vCPU which trapped. >> + * >> + * Check the saved copy rather than the live CSR: a nested trap taken >> + * from HS-mode clears hstatus.SPV in the CSR (but leaves SPVP alone). >> + */ >> + ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV); > Just to understand, what is the aim of this check? Is it to be sure this > function has been called during a guest fault and not a nested HS fault? > Yes. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:17:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:17:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416715.1645656 (Exim 4.92) (envelope-from ) id 1x517w-00082R-IB; Fri, 11 Sep 2026 13:17:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416715.1645656; Fri, 11 Sep 2026 13:17:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x517w-00082K-FX; Fri, 11 Sep 2026 13:17:12 +0000 Received: by outflank-mailman (input) for mailman id 1416715; Fri, 11 Sep 2026 13:17:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x517u-00082E-Tm for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:17:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x517u-00E0db-AA; Fri, 11 Sep 2026 15:17:10 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ff46-e002-0a2a0a5209dd-0a2a450789ee-18 for ; Fri, 11 Sep 2026 15:17:10 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ff55-b4ea-0a2a45070019-5a9b322283ac-3 for ; Fri, 11 Sep 2026 15:17:10 +0200 Received: from [2001:8b0:10b:5:94db:d427:30c1:83c2] (helo=u09cd745991455d.ant.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1x517s-0000000CC6l-3IFW; Fri, 11 Sep 2026 13:17:09 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=NGWYeR4JzuNTEnXOGwGUn9aVIclf+oa607LBYI/GsrA=; b=ogUzkjiPHrM/o0Jq5IUF/TOQce JF4ocnvus3utQGgwtz6hQ1+82P9io14hgVLu3ofSqdI7hbImyMp/iKmDKgIEvDo6mjd2W1LrLw7GQ 1UsFKYkVYZCdCHSGLnSHX+fZNpKmQhpf7Bbj8VBy+1grK0MJ0Qt7El1vJ0d5hovA5W+pMVWYFe5FN Sbl1cZeMKKLDLqEKgf1QoAbTL8xMjPkro3OEfFDBkz1FA+HfUJVvoGnChxJqHNktOHWZRl4fsQkQX 1s9spAlSGJwn3KYzjuXYgRf04X/Yq5VOqwRdYm7NXLCwuV02xEjNQs8dpn2C6NEafF5k/eDEhM9An eFxQhYQw==; Message-ID: Subject: Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc From: David Woodhouse To: Peter Maydell Cc: mark.syms@citrix.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org, edgar.iglesias@gmail.com Date: Fri, 11 Sep 2026 14:16:40 +0100 In-Reply-To: References: <178912129220.24041.799369954881004447@citrix.com> <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-kz2avUIosl2i8tNm3TA7" User-Agent: Evolution 3.60.3-0ubuntu1~ppa10~24.04 MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-purgate-ID: tlsNG-ef75cf/1789132630-3C817AE4-15D318D9/0/0 X-purgate-type: clean X-purgate-size: 10537 --=-kz2avUIosl2i8tNm3TA7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2026-09-11 at 14:00 +0100, Peter Maydell wrote: > On Fri, 11 Sept 2026 at 13:32, David Woodhouse wrot= e: > >=20 > > (Help! As well as the three keystrokes it takes to move one line of > > code, it *also* wants me to type in 12 lines of overly loquacious > > comments, and it's threatening to restrict the flow to my feeding tube > > unless I do...) > >=20 > > Claude here (dwmw2's AI assistant; he'll follow up himself and any > > patch will be his own work =E2=80=94 more on that below). >=20 > Please don't send LLM-generated text to qemu-devel. Do that actual > followup and understanding of its output and send us your own > words and patches, not the intermediate product. >=20 > We allow LLM-generated stuff in bug reports because it's better than > not having the bug reports (though even there it would be nice if > bug submitters looked at the LLM output and applied some human > udgement rather than directly spraying the output at the bug tracker); > but I do not think we want to dilute human-to-human communication > between developers with LLM output. Sure. While the structure of that was intentional, "its" output wasn't actually unreviewed by me. Normally I would indeed let it do the work, check it's got it right, iterate a few times on what it's done and and then basically *paraphrase* the final conclusion in my own words (and many *fewer* words!). This time I was just making the point by letting it obviously use its own voice (and literally launch a mailto: URI with a fully-composed reply). It's a data point we can perhaps consider if we take another look at the policy now we can really see its real-world effects. Or not, if we don't want to. --=-kz2avUIosl2i8tNm3TA7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK 72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9 0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213 MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm 6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6 bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO 02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91 LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8 +3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs +icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1 LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0 D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3 bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2 JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k 0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6 ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74 vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o 9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0yNjA5MTExMzE2NDBaMC8GCSqGSIb3DQEJBDEiBCA1lGCG/95ZNs4E2ZlgoPkR0hvlgWas fAx60AGgaD1SfTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw DQYJKoZIhvcNAQEBBQAEggIAx8ilxrcip2PNVOo8NcwA+S9DW81lO5C7k0/JdcKWgbPjbyrryUsj i7kFywwWcQ8Wb7PJXq0HcpyPOD4wj08Rv91UclkhdOdFQbyhqvCPawruU/qInW3SX4iEaKkKDdao tAGwEMCz0r/PIgfGVANga9PoHPxrVEfoeAzqg7iWCYTL2QcsZMBv6rf95q5TIWeQNikefd9CtsWp BYM79iXeKCg/w36HvymtTAiCdYfH7xFzp9p26J3FmbArL1YRe7ZcvnB2DpIRFAc2Wo7DYUBZH0tY 6QHvHz6D8raqUPkTrzZbjLkDahBJalBRnjTX4AbZueBHtBWU4/uw6dXaPwx3GgfQp0WZ6rIBciPD pfgB7F1AYx+D1+GbkjIkkwpNckAaktCoSkPzYCdZy1xjfSa3MhgHdpIj0Hbd/XWJo3BxG4gnIItY BqBVmabEB0RAeZiChRbSBNBsNtdvP0MlifxtpUFqyRn0ixCTRg8chQUsWEAfEXSh4hRnkQJ6ib2h qTzz1Agp6PrGYxmCK7iq/fLEOxx+LcngbOe7HDk//9qG1veVA6Ubd7z6iZcXfysxH8PyUYceRS9O O2xQXM3OG1y6QWDRJP4V9jqBcWGiSDl7r3yfsGdApyvSN5be7NB4vT7ZGNso5AI/JX2hyeG8BIhD wdHkavWH4qXMgEpMUBDYrQsAAAAAAAA= --=-kz2avUIosl2i8tNm3TA7-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:17:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:17:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416717.1645666 (Exim 4.92) (envelope-from ) id 1x518I-0008Kh-TK; Fri, 11 Sep 2026 13:17:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416717.1645666; Fri, 11 Sep 2026 13:17:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x518I-0008KW-Q0; Fri, 11 Sep 2026 13:17:34 +0000 Received: by outflank-mailman (input) for mailman id 1416717; Fri, 11 Sep 2026 13:17:33 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x518H-0008Je-15 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:17:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x518G-00E0kL-Cw for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:17:32 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa3ff52-e002-0a2a0a5209dd-0a2a4504a372-42 for ; Fri, 11 Sep 2026 15:17:32 +0200 Received: from [52.101.85.57] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa3ff69-b57f-0a2a45040019-346555395ffa-3 for ; Fri, 11 Sep 2026 15:17:32 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB7516.namprd03.prod.outlook.com (2603:10b6:806:399::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 13:17:27 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 13:17:27 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HT3g4N4hDe12sALiOrYsegwq3YSwcBkDac7UUh0y8fGwdJ5n0zkN28EqNVhqLKNH6sTTIOf6ax2/gXjlMExgTnMrmi+7fUNgfgQF2KK46feRHCYoH6wrNmbArSEVnvItuDTiIMC9ziIolilkBTi22Q1SBlU5ABYxKChlXqvoRxcAmUIApRj+U2mv7TcVAf68xXNV42wVJgWBNgzC2KlDs+SeMfooo93XR4IWqGuFCrAlSn1f1jQlKKPOAIG1soGjw6N2VRiHLsZ+lszoqvOwJOfFXfJ1PpJZz4LcY6PheY4GcdEduwOxwzialpiuP6PS4bjYP1b99pETj3cjw4XZpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KkuRlAcZHaS/vKiVUQLWCbVJQrB6ORaAMpZc6CPonvI=; b=Ha3522AbogZwqmW550edpbPkZ6GQhCS8vAfr8qmCaOURQ/lLx6wGFne/en1tfwJSbl/2VpZ4XrFiyM8gkLZCSdwS4+/hhn8clFfH5zs/pcH/eOl4hqwqusWBNxOleHahyA6CMVG+cJdVe2bX4sWXX1WeA6725rjSS/17/HkGD/O4byHF7vy0BDWP87b+9x/8K7Lruds6EyXxbtcy6CtFHfgktTExYwPvufRzolCfGQOoenJ/yh43cJwPkEg56NbT840H4OH9f0sxi5kVV6jYlqXDKLT8X41iU3Wl0S5BWgG7kgqVl783HWs7j2oi5G4nyaN2hsWwEZn9gkkXN0ARzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KkuRlAcZHaS/vKiVUQLWCbVJQrB6ORaAMpZc6CPonvI=; b=A8zKr5nb8AZfCZSx1gCFRF2+YmYsM+vGKLOqEVmTOUG/68acY7+RxtQnp5hl7RncMOsq20bixGJ44V0+Q6PxMqwu/P8zsmk3dTYIVXPHacNoGZ9IAEEHIVXIAMTDb30VRa6Qng8Zue+ayhRQph7phJBviLGPpUX+qrvc9WiSwJM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <06d7c190-9912-4d09-b01f-77e2cde56af2@citrix.com> Date: Fri, 11 Sep 2026 14:17:23 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, George Dunlap Subject: Re: [PATCH v2 1/7] x86: make UPDATE_ENTRY() allow for multiple operation flags To: Teddy Astie , Kevin Lampis , xen-devel@lists.xenproject.org References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-2-kevin.lampis@citrix.com> <1789119951.8631fc262581453bbf619ec5b2062170.1a08fdbf3c0000c4f3@vates.tech> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <1789119951.8631fc262581453bbf619ec5b2062170.1a08fdbf3c0000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0278.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37a::19) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB7516:EE_ X-MS-Office365-Filtering-Correlation-Id: 12c3781f-22fa-4290-765d-08df1007068a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|10067099003|18002099003|56012099006|22082099003|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: eKS29v+TJeTmibSAkECgKNWXpQx8FJl32PnfKYtcDhcKe4gxDJidr907KfNhDh4o2qDeDFM55J28zgz6raT9dHWmT70rDmlzKiEhAgzSpMIB8KXxYM9fKgET63e9bWEH1+Dl9+ug+mfPx264Qz3Ch8qJ9GehnN0WGsoMTip1g/F4bwGfoRh+XdZrr+yc5di2oytOLK/+/A+utKRkUqUjzKetsha+PraGwkvhX3DicvXzsey/LdCF7lzFtr3nsTtOqsRgu/mvZVJfSt4zTQ925K9F1T2gbZya6Z+2V0Bg4K9CJrbkgj9/KE7eddOPpapSYuXbk2Cf9B5bs7QIL87egImIoKA5RLN4wFFXjC6o7qXb3vkkY/tBGTUUSa97ggai707KgiK1n3RvXoDssTnXDrZvZ6M5ineCFWVRN5lNhBZ9exKaaLgJaAMj6i3ZgS1asnnP1ejWAGuOWug0nnMu+1Cj4xI3maMundWV/LicdTR9+3Yy/6SrOM/xy6mAkT/RTHHYT8B1cVr3aOCkEwNGSpIRFnpe4zxtGHJCtHtPApxMumy+ud/l6Nl+7Qqe01UE8CHVVq4Y64HC+i7Cd8NrcUekBzkJfOiUZcspuWFaZ6lGoa7wSdeg4UNg/PvGxnMONcn/87b01EF/86bato/kjhC6PrtNSvmt5coxMnDVfzY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(10067099003)(18002099003)(56012099006)(22082099003)(11063799006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bHVNTWNYSitleGF0R1d3bEdBVVFtY2dLaEJyT3VTWXk1bUNTUXhtVzN5WHBl?= =?utf-8?B?dXNBTSsrNHNZMmpUYWRrZWRxd2NTWitFQ2FHU29SaElCNXY0S2U5TUcyYzNq?= =?utf-8?B?eFFFUU5YUy9EYWVtVkJZb3lFV3RnNEgxZllSSmRGTFpNMG80bFJxZFN6UE1H?= =?utf-8?B?THJLby91RW9UWEk5c0t5VTlHRDUxMWdZTmxRUmducVJWbG13RHRmU08xTVVX?= =?utf-8?B?UGhNN3NyaVVLU3dFNmhLVkQ4K3dkSXZ5WFJOQTFoeVR2Sk5vZTZqb1lFd21r?= =?utf-8?B?VEE2bVMzcHR3SzBncGhObjJZTDdRanRxSFdxblpOMFpVUTRpcnQ2UkZUVlU1?= =?utf-8?B?T3J4dnRuL0tTYkUwbU1TcHZwUlBTeGZFSWttSEdvaTREMzBGdXB2aHhQRFpP?= =?utf-8?B?WHJxaDlpRXNWMWlMelVZc1BxL0FsOGhYcFBsVjdBNXpBSjJUUDIxRE1SK1VY?= =?utf-8?B?WHF1dXp0NjZxRjVZKzVCaGZzMWZaNlRjVU5LU2E0YUYzSEg4a2h3eVQ1MFlU?= =?utf-8?B?TkhpSVFWcnREWWQwV0NnLzJaZEVjOVZaS3EwUXZxamJEeHlwZ3dSZXJ0amhP?= =?utf-8?B?SmFwVFhNV05CcGRPMkswMkJKM0xib2N4VmI1NVEyMzR5a3BXRlhvRXlkT3Mv?= =?utf-8?B?QlNvaXExV0ZqMWNGbjUwRlovUnMyMUNRY2F5ZmVBT3djZ0V5VTB2WlZDMzFM?= =?utf-8?B?RC9GcUw1TE1VUFBtYWwrTkg3cDN3eWRNcnRKbGl5MUQ5R2RDODNHZldCZHpO?= =?utf-8?B?ZDVJYkVObnB0MWN4Nnliby9mT1RnemdFU2ZoRlBGdnBsYVQ4WHRPNlBNYmFD?= =?utf-8?B?MExpS3lpc0RWSk9iSzBYRE12UDNMTzNWUjI0ZU1veDJWNGRVdHFUNHNudTJE?= =?utf-8?B?Vm1WdUhVTWNSTFBEN0hMWmJZcXRPTFJwWTJsaG9rbGxwdHRnU2J5MVNyS0oy?= =?utf-8?B?anBwa0QvYlFhdi9SZU0rNnRLUlpkS2RNcU0xc2VrU3RBNURmeXBBTXNYY09I?= =?utf-8?B?TDIvdSsvU0JQSUY3ZFpJdjFPWi9NNSs1ellySTk0ZENMamRCd3h4OU1NRTFX?= =?utf-8?B?VlluR0JHSVZwcUNhanU5bXFaQUUvN25zZ0pQaTRDWHJwazdxbmtOa1RWRFIw?= =?utf-8?B?UU16VG1LWDVoQ1lWeHArR2RGMUNId1FyWEJXSGxOZG9UTjk4b0l5WjBqYTVQ?= =?utf-8?B?VnEvRXJOTXkrVzc0MFp2TmdlK3dpMHdsZktwUU5NaFpoNUlzWnJtRGMyV1Vk?= =?utf-8?B?a2dUTjhBUEFNNUZndlNBdUtzdWl6aTdDK2t2L2w5TlRDQjV2dGZlam1QQWNy?= =?utf-8?B?ZmNIc3Fxbk9YeXVaaGJNeDlxZm04MytCbmVxZENWaXB1dlVqenlXSXFSSnVI?= =?utf-8?B?aWw4V2lnRGNNMUNCRnI0RkFYU21EYytMZExqU25GTXowNitKQmF4OFNzZEdw?= =?utf-8?B?MTk2a2VnbG9nWDU0WCs1SkdTZXduNHMwQzJSVjhLcmFxNU5odnI4QmJXUjli?= =?utf-8?B?UU5PclJTWUYxc0U4Y0lnQUg1ZVJnQTBJSWswS1FIcElIWmpjRng0WEplallW?= =?utf-8?B?SnVnN2I2Z01yMjdkTlI3WCtNbmRCakNzcFd6dCt4MURDa2U2Qi9VMDhVblNY?= =?utf-8?B?NDhkVm9tdWowUU10Z2s5S1RlZ1BqTWVURUptMmJ5dG13YXljRzUrWlVPSVF5?= =?utf-8?B?WlJibVNtWk5GUnJhV3p6eloyK0pvQmVPRVYvSi90ZlJLKzB3QVhlVHRVSnhq?= =?utf-8?B?Nlc1Tm9sRVg0WE9tcmVpQm1RMFQvaC9IcUFTRzBtMGwydGtDb1pHbjhaYkFH?= =?utf-8?B?V21kVTBXelZpLzhVRGZ0NW5Rc2xVUDN6U2RqTkRhOEpxYW1SVVgxZFRZb2FS?= =?utf-8?B?dmRkYmRmelJSanAwSjBzVkU1ZmxmOWQ2bTRydVo0R090ckJETUVEbzhKSmUv?= =?utf-8?B?eklHbFVwSzFIYjJGcEpkRnczUTZwNzNaN1E2Lzlwd25PUDRpUnoySENZUkZH?= =?utf-8?B?U01ST3RKZ3dzOWszcmlQcXNsdEwrWHZpSUxabC91MHFCMmR1OTdESitpS2pj?= =?utf-8?B?MExPRmZJRkNjcmFydUFFcHRQbW1Wd2RQSEUxczZjR0hZbFBpVmg0aEVnN3Zv?= =?utf-8?B?MkxNYlFwY1p4K0JEcjFBaDFaZzcwdlhITldtVFBKY21GS3VWdlNCTHlDU2x6?= =?utf-8?B?alNtSDdGbnp4TWRybEFKUkMzclVYZ1BiUmREencxVW12NjlKWmp2cFhkMDBS?= =?utf-8?B?TjNoM25iQlAvSDBxYjZGNm8yOTJJNHBpcm5BaEhlUDRualpVd2RNZE0yUjkr?= =?utf-8?B?ekRSRjBxZTZUbndhUlNUTnQ2WEdTTkt1WHJFQldIT0N1RGJ5MzhVZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12c3781f-22fa-4290-765d-08df1007068a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 13:17:27.1344 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: gmVZXBoyHb9yhmjekT9EeR2Vnwo4zq8UhNMAzPRzPe866WwhKjIj0//7fPysyGhAERmewfy4hoci1HAnf1qNJ2PKrXW60gagvUCEI0Q2SkQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB7516 X-purgate-ID: tlsNG-ebf023/1789132652-C12DCB50-89425757/0/0 X-purgate-type: clean X-purgate-size: 2004 On 11/09/2026 10:45 am, Teddy Astie wrote: > Le 10/09/2026 à 22:31, Kevin Lampis a écrit :  >> @@ -2435,7 +2434,7 @@ static int mod_l4_entry(l4_pgentry_t *pl4e, >>       else if ( pv_l1tf_check_l4e(d, nl4e) ) >>           return -ERESTART; >>       else if ( unlikely(!UPDATE_ENTRY(l4, pl4e, ol4e, nl4e, mfn, vcpu, >> -                                     preserve_ad)) ) >> +                                     update_flags)) ) >>       { >>           return -EFAULT; >>       } >> @@ -4135,18 +4134,23 @@ long do_mmu_update( >>                 if ( page_lock(page) ) >>               { >> +                unsigned int update_flags = (cmd == >> MMU_PT_UPDATE_PRESERVE_AD) >> +                                            ? PTE_UPDATE_PRESERVE_AD >> +                                            : (cmd == >> MMU_PT_UPDATE_NO_TRANSLATE) >> +                                              ? >> PTE_UPDATE_NO_TRANSLATE : 0; >> + > > I'm not fully convinced by the double-ternary operator here. While > it's a bit more compact, I don't find it very readable, I would prefer > something like > > unsigned int update_flags = 0; > if ( cmd == MMU_PT_UPDATE_PRESERVE_AD ) >     update_flags = PTE_UPDATE_PRESERVE_AD; > if ( cmd == MMU_PT_UPDATE_NO_TRANSLATE ) >     update_flags = PTE_UPDATE_NO_TRANSLATE; > > Which is one line longer, but looks to me more clear on what it does. The second wants to be an else if.  I too would prefer to see this written not squashed onto the RHS. Given that it doesn't grow later in the series, then this if/else chain is ok.  If it does get longer, then it probably wants splitting out into a cmd_to_pte_update_flags() helper. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:22:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:22:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416743.1645675 (Exim 4.92) (envelope-from ) id 1x51DM-00026v-Ei; Fri, 11 Sep 2026 13:22:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416743.1645675; Fri, 11 Sep 2026 13:22:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51DM-00026o-B9; Fri, 11 Sep 2026 13:22:48 +0000 Received: by outflank-mailman (input) for mailman id 1416743; Fri, 11 Sep 2026 13:22:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from <3ogCkagYKCY8Bxt62vz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--seanjc.bounces.google.com>) id 1x51DL-00025w-5q for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:22:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51DK-008ZRa-9y for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:22:46 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from <3ogCkagYKCY8Bxt62vz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--seanjc.bounces.google.com>) id 6aa40094-e002-0a2a0a5209dd-0a2a450ca064-30 for ; Fri, 11 Sep 2026 15:22:46 +0200 Received: from [209.85.216.70] (helo=mail-pj1-f70.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from <3ogCkagYKCY8Bxt62vz77z4x.v75Gx6-wxEx441BCB.Gx68A72xvC.7Az@flex--seanjc.bounces.google.com>) id 6aa400a4-f479-0a2a450c0019-d155d846d47d-3 for ; Fri, 11 Sep 2026 15:22:46 +0200 Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-38e1118e4abso1633857a91.0 for ; Fri, 11 Sep 2026 06:22:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1789132964; x=1789737764; darn=lists.xenproject.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=kqAHaS5fsv9ERkHKe2Kmet0fUHotC014bD2kFqqX4to=; b=iaxNMNRDD5bh9fDi5Uj/mNg2fbsPfDeMZeStblTuD8C1v6ZLiRbLxFjgU7CSvFenx9 JOJZhS/KBIcUEfkWZU3MxQAEhXmhnXyIZMpzHR45IyL2em/UYeymlT1nUQ0skMzgPOo3 6Cu8KohKxnNe9ZvNAbbfAS0VpyGTuPDM/iiyFjvaDFzH7CfUQ5YnD/xRV2ji14Rpkmh6 c6rrJHhqtyqcGfNGS4drxBqKX+Mw/YHcg74AMV2tskzg096zwMP6Vdw9jWYELKyG3Gtl BPiO/Y7dM1LTM6551sv8mlFDK5+6sqEsod3IRt43f9qMgjMyIaJEa9suGN8Nef8/9XMz 1VJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789132964; x=1789737764; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=kqAHaS5fsv9ERkHKe2Kmet0fUHotC014bD2kFqqX4to=; b=lwytOvJLMSWed/rkJthS4tiGVATfUSdsN37ux3yNDeckbji8suFCNBhlPEhw106OCm 1/pkDbWCNAZANiFXdUApRjsDYP1lIDOBk1pobgm0CGcIu16n5pEtIOx/TpBeDByvOyfk y7+fb7TtCiG/RVxvNDXG7lu8QG6I9y6N3ZlWQp25+hGAWvhfMBoKnKp8+G7+bcqtE0bl NqjKlNocZwPrfJpc6HjPfkYSTq7yuS7tDys57++qjVCUKDW57Rqzx2wmxNhpQGUgAtde Phxs+wZ5ZySjgmgpIzVtDYDn+Q0tBnK1D6VX7cWwhXQvmma0Zs0o+nzpTMzURVudbH2H tp6Q== X-Forwarded-Encrypted: i=1; AKwUvBw6iBy0Rq3TIlsxEv3D5aNO45i5AtMAxpzhFgfHA1FQLzKIadctkKUBNoAN90VdYVnuERcWx34VjiI=@lists.xenproject.org X-Gm-Message-State: AFuF++nnbOHU/MY7/cZJXZDPzx5PDog9PFmbBjg16NfVDYV/FLUVgb4I W4O3xgWx+wDpG0Vyo+i0cQg/7DlzoHlo+VWuwQUl7ycIlQodxakosmY/EtdKEWokhZLujpuOzTg ABk3UbA== X-Received: from pjbmv13.prod.google.com ([2002:a17:90b:198d:b0:39d:8dae:7e6d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3c89:b0:398:e46e:ade3 with SMTP id 98e67ed59e1d1-39d9c39625dmr7169956a91.23.1789132962606; Fri, 11 Sep 2026 06:22:42 -0700 (PDT) Date: Fri, 11 Sep 2026 06:22:41 -0700 In-Reply-To: <20260911074530.3140830-13-jgross@suse.com> Mime-Version: 1.0 References: <20260911074530.3140830-1-jgross@suse.com> <20260911074530.3140830-13-jgross@suse.com> Message-ID: Subject: Re: [PATCH v3 12/13] treewide: convert rdmsrq() from a macro to an inline function From: Sean Christopherson To: Juergen Gross Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-fbdev@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Paolo Bonzini , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Damien Le Moal , Niklas Cassel , David Airlie , Olivia Mackall , Herbert Xu , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Linus Walleij , Bartosz Golaszewski , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Arnd Bergmann , Greg Kroah-Hartman , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , "Ilpo =?utf-8?B?SsOkcnZpbmVu?=" , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , Helge Deller , xen-devel@lists.xenproject.org, linux-geode@lists.infradead.org, Michael Kelley Content-Type: text/plain; charset="us-ascii" X-purgate-ID: tlsNG-d25034/1789132966-02EDAA5B-95EB941E/0/0 X-purgate-type: clean X-purgate-size: 721 On Fri, Sep 11, 2026, Juergen Gross wrote: > Today rdmsrq() is a macro using its second parameter as the target for > storing the read MSR value. > > Convert rdmsrq() to an inline function returning the MSR value. > > The users have been converted using the following semantic patch: > > // Options: --include-headers > > virtual patch > virtual report > > @@ > expression msr, val; > @@ > ( > - rdmsrq(msr,val) > + val = rdmsrq(msr) > ) > > Signed-off-by: Juergen Gross > Acked-by: Damien Le Moal # ATA > Reviewed-by: Michael Kelley # Hyper-V > --- Acked-by: Sean Christopherson From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:23:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:23:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416749.1645683 (Exim 4.92) (envelope-from ) id 1x51E2-0002Xn-LU; Fri, 11 Sep 2026 13:23:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416749.1645683; Fri, 11 Sep 2026 13:23:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51E2-0002Xg-Ik; Fri, 11 Sep 2026 13:23:30 +0000 Received: by outflank-mailman (input) for mailman id 1416749; Fri, 11 Sep 2026 13:23:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51E0-0002XY-E6 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:23:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51Dz-009M9i-R8 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:23:27 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa400cd-e002-0a2a0a5209dd-0a2a4504b2fc-6 for ; Fri, 11 Sep 2026 15:23:27 +0200 Received: from [40.107.209.9] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa400ce-b57f-0a2a45040019-286bd10907b9-3 for ; Fri, 11 Sep 2026 15:23:27 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SA0PR03MB5513.namprd03.prod.outlook.com (2603:10b6:806:b8::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 13:23:23 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 13:23:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gRsuClBO+rrbilnQS4UEstFjUbrQD27EZznddMzExoPXMLv7mSHBiyrUA0a8X+JOzAQ4qRxeDdqAiUu9SHxwycV7aQ08PTmSFXAUwkqFs1CV1bnH1ah1mfn/HjEk5XIe6uZFVUvpxOX7J80FgfiespCVkHZQZsvyn6GVYnbG31sLPy4TkN1oXuTVkZEwq8NDO+U8AnQ9NiMBcHP6UFebdePzkaBgmDq0aJcYEzK7YffkH1j+efdZArwSrABQC/M7HGYR9OXzgYXLCeAImuJyE4B+bwKD4ATK/xlhePsjBbSVWRU0MNFz2JUlMiiKdJG8xv36z/GqS5OHCBgBAkjHog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VV7+0WrE2NS0uGcFnawu17UelPzi7v9pfguRD7Ezzts=; b=Zuvq1trrGlsbgqIhRfdZOgFjb8mrlMUpWR4fQ4I7OczeLGTJpD/PPNXuXflgJzcVEwo37VjP9F+PJSJE/o8tplR9/dWpJD+RjOY9Qe/S4HVNeH7bV720ALiEX/HZFZ65RosoIBxzoIb4elemoabDHDtCXFoo39bzjg0oFJXHulaJxLanCJ9I7vq7p/8FPeRYkRPH2fpM3gAcT+O7wKbQaYVSWdU3M+pwluUbOBl50iaK1Mg+0m7z8Xm+Uj3umUNHhg5eawH24XrnRIk8lv5nztsdPOoYodAjwwxtdiRx4gfsjGY+wEtW+qUYfs+BcSrGIlW6zin/XR6dnNDOLyXs1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VV7+0WrE2NS0uGcFnawu17UelPzi7v9pfguRD7Ezzts=; b=WzKoqIYy0JetSDqGk0hV58hLVH+5b0dFZtLVYDcARQVpCo1NBxeZOuwQ4EcQ8/ygFp7wLRwhp2ZrXZK4dMvJGNgJAdPf+ttiLj67h7nyHmjhlEH+SYUCZwmolM06RigU1Vl6g5Go7h3C8ZRgpdKE+ILIAF1NgHNNHdYwij7EOHw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v2] nestedsvm: Fix multi-byte IO port intercept check Date: Fri, 11 Sep 2026 14:23:15 +0100 Message-ID: <20260911132315.1209497-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: DU7P191CA0004.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:54e::10) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SA0PR03MB5513:EE_ X-MS-Office365-Filtering-Correlation-Id: 940fbbdf-3953-441b-3f3f-08df1007db0e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|56012099006|11063799006|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: YHf1XGjEIJRV+hRVSdQzR0PSE53cXNrrcbejR8eK6Hqy5cVvrA/977G+LcGmduXFvuXa8HsytUEaGeS3udsTBc04/VHeMKb3+rCQVCXg2MH1CbYT99T/dSUwJrTebuk1us0UGrWMDkQbwoXj2m07K0h/2x17icnqDwmZ6hmsdxTv2FRS9yRHSGekCOz+75Ylc9gXeU4QMzfFa8aEau8oZl1GaaPWh6hD75+yRhqd2np+kLggYyYU+w8IUAfNRZmW6WBqV5+PZgZ4zOLuR/NFeJK6Dl284IyiPJpnHjmdSKxU3IHCCmZU23x6mhbb4qh0ojelPOIJRAfRYmwPPG34R5IC6Vu9HrDqk780MPi6uGRmzdCYk9UodU/5vnxKDpk6aEFAy/6EyStp31/D/mBhFVNcEtj9tGzoE3xiN5kLQGjyED2E9sFL6Yw3dWmYS04cbAYIjMzlaX0KZNJb66hzoiDAv8Gqb8QBriScRiZVAquKt5fBxTKdEHmOHvCwIp5TWtiinvGpupES4xWV4G04N/oOpCUwwxJhE9HAWUsVT+YKOK37FhAqzHQXwsj0jX+l+KqQrixFbld0kpWGnj6X1P71K9fepd8t2EODUDL8zPj5CgB+Mk8FI2t9G1NwR4w8d1ZxjpSEQSDGdaSfAY5nhsNeIMvdCprRBPDteGmlGPY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(56012099006)(11063799006)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?hONsnFt43i2ddC9ZbRhcBjRMtcgUdSkQENgx/4u13nat7tJ7ZBvP0e6GVBk8?= =?us-ascii?Q?KHfIqsEogSOH7Sd3S+a4hU/gNpglSCziE/IXnQ00eqSkcGVertx+omMhEIsY?= =?us-ascii?Q?2QuouyKqUyg+3GD+jLU9k3HN/WTAkKAyPwtQFbp/5V82Fy04XBkcESUg7Y8o?= =?us-ascii?Q?BdK15X3cUgSNM0VyF5qaTe0fHWwT7vFa0hQS5+CBV49VITzsTr4lOQikdyHl?= =?us-ascii?Q?f3L7X8jUu1QM/3qQv7+LjM3mTWLjka7BUR7PZ8VaLEGxzYuVOmDoHeZY8lnh?= =?us-ascii?Q?rIlrh7KrfEAg1lUFBMVUlUVAvzo/VCJ55xqCYouEp8YN8JoJTwH5RHuD6g/F?= =?us-ascii?Q?9I26Ndvfxa7POt8cBBtfKtykqq0NzlaMtnBOeI0P+QahQAAAlzvAJzjIRO0R?= =?us-ascii?Q?fSzkEbMKRYBe9cZXwLDeo4ANf13vOYQdslPDKu40QIaqEngoIDbGLsVePq+p?= =?us-ascii?Q?W/c2o8A3K3GGpPQFl286C3ymwG0f/6mxpFcOWv7Le4c8rRhCbN2S+h37Xjd2?= =?us-ascii?Q?XLv5caZNmpJxJSrq1Rrwo6/YF2A58Bbu9J9WlMvfuKyu6hLWfi2IqFOUjsQF?= =?us-ascii?Q?Plj3ZkdSoBGl5Z/X7mvmQra8K56v4UkrjZJ3tY38ZMZxywEVvfIrAZEwP3Pg?= =?us-ascii?Q?0C3Ske03zK/Nd0EeK02bdddxkESvr16qtMRuIStCZCAp23EZkRFO6UE8eHuB?= =?us-ascii?Q?y8XitMdlEzwRRewN7YfZj0A1cxqRXF2hZ8cAfL+5nzTREua9NJRLN0FZyzJ1?= =?us-ascii?Q?DNVMuTtFRntupuOvRBUkKLuQpY2mAJ1UnVRobbBjOsv80zNikmf0FcOqynYC?= =?us-ascii?Q?5bTiNcaPWj8wCCMu+z2eZyOASsmesDnjZo4D9tOUnCC+Oh5mjASZXai6zIVQ?= =?us-ascii?Q?1LKwLSHzFdK1pvM4KILAKc+BkRiH1TeM6W+1KrOYx2D4yCR9xqOhT7WZXxlY?= =?us-ascii?Q?sRc96+jaP70TQ3khSowXrgghzlo5tId6l0yCb5kQm6DJfEBnYN40GxVGvwNf?= =?us-ascii?Q?FWT80pQsTh/yxZvARiBjuj9NK0iMzIf/qwbrDce/2AxUSY/QHuy/qfvhUFsz?= =?us-ascii?Q?pDpS59ZSnV+aukgOpeYvyOWzi+n6L/Gmi9QxtLEnq0aEMsPmb071WbvqxU2y?= =?us-ascii?Q?2uW9P5qXaUdgxkzwRS5C3lSiu6yrGvvsyAih4FY4Rvhsgsdr1zOeHUa4vqNX?= =?us-ascii?Q?VrzwlK4fQ2X5/DysywZm2Ab7RDxGY2WL7m0Hh+kgN+GnN4wKGwuQCBMoDsYD?= =?us-ascii?Q?tSd8lusIpzdjqA70L0snogwXR+qMVl4mtqTcymbfz+rR9+vSh29tAKjASyr5?= =?us-ascii?Q?7wdAWoba8wooVdj3iChEAwtjaJrvlrULUH8JuMpQ154ntA+wd2ySrWSwf6Rv?= =?us-ascii?Q?tM6IC/HT7lv18ke6BHxKX9voF85Tz8Re34UoRFWts6bGmuKJ/PudcZwm7n/b?= =?us-ascii?Q?ACikgmv6gJwWpisoKj3x82sj7rS4jOyX+NIesiedIx5ic5Cs0SjV4XNZFxsL?= =?us-ascii?Q?TtQwnRcgrcGJBBfq1a/s87XfT6BaowhRombnbBHdOxA2w5PEE6Cuc9+Sh6CM?= =?us-ascii?Q?dLptUG61Ab1rLmd+YSoZDnh4QJ0EdHhOF8wCXcoCkwcaNxe+XVrKgb1OWXO/?= =?us-ascii?Q?mYlrAwbn8qLL7ctA/rowmQWnfAOp6ad1mBXrYMTH8caLVg+EtyfNNKfl7D2n?= =?us-ascii?Q?fdq77pf0Orx0jc7yYg5ONZ0+M1gkIVAGbieVFu20+KAdLKz1IlbpfpSXWn1B?= =?us-ascii?Q?Y2+yxMQxAlgUNDACddQeEBMdvV0D8Ac=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 940fbbdf-3953-441b-3f3f-08df1007db0e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 13:23:23.6700 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: CFiw8dEXtokndzBguqDl0mku1rAqclXezU3z1vsbBHSAv7/AjoFSN6CElgpiI++0LXJz8yhNzeHovTm7MBBUd5saSOlWpQR1Fb7XSt8qXis= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5513 X-purgate-ID: tlsNG-ebf023/1789133007-514D3B50-0344B527/0/0 X-purgate-type: clean X-purgate-size: 2125 For multi-byte IO port accesses, the APM says that SVM should intercept if any of the corresponding permission bits are set. However, the code has this backwards and only intercepts if all the permission bits are set. Fix this and at the same time, make things safer by handling mapping failures as intercepted. Also rename the 'enabled' variable to make it clearer what it does. This affects Hyper-V since it does not generally set all the permission bits of the multi-byte ports it allows its root partition to access. This results in an L2 root partition that cannot do PCI config space accesses and therefore cannot access its NVMe disk to continue booting. Signed-off-by: Ross Lagerwall --- In v2: * Intercept if mapping fails * Rename "enabled" variable xen/arch/x86/hvm/svm/nestedsvm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 5adb1bd72c4d..8885916399b4 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -830,7 +830,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t iopm_pa, uint64_t exitinfo1) ioio_info_t ioinfo; uint16_t port; unsigned int size; - bool enabled; + bool intercepted; ioinfo.bytes = exitinfo1; port = ioinfo.fields.port; @@ -851,8 +851,8 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t iopm_pa, uint64_t exitinfo1) for ( io_bitmap = hvm_map_guest_frame_ro(gfn, 0); ; ) { - enabled = io_bitmap && test_bit(port, io_bitmap); - if ( !enabled || !--size ) + intercepted = !io_bitmap || test_bit(port, io_bitmap); + if ( intercepted || !--size ) break; if ( unlikely(++port == 8 * PAGE_SIZE) ) { @@ -863,7 +863,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t iopm_pa, uint64_t exitinfo1) } hvm_unmap_guest_frame(io_bitmap, 0); - if ( !enabled ) + if ( !intercepted ) return NESTEDHVM_VMEXIT_HOST; return NESTEDHVM_VMEXIT_INJECT; -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:28:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:28:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416761.1645694 (Exim 4.92) (envelope-from ) id 1x51Iz-0003PT-CG; Fri, 11 Sep 2026 13:28:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416761.1645694; Fri, 11 Sep 2026 13:28:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51Iz-0003PM-8H; Fri, 11 Sep 2026 13:28:37 +0000 Received: by outflank-mailman (input) for mailman id 1416761; Fri, 11 Sep 2026 13:28:36 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51Iy-0003PG-6M for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:28:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51Ix-00BcRZ-3H for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:28:35 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40202-bab6-0a2a0a5309dd-0a2a4505856a-4 for ; Fri, 11 Sep 2026 15:28:34 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40202-4cb1-0a2a45050019-b9ff1c229df1-3 for ; Fri, 11 Sep 2026 15:28:34 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a090a7c48d000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 11 Sep 2026 13:28:29 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 0BADD81CCC; Fri, 11 Sep 2026 15:28:28 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=gILvdQMSYRS6c8VUbb8G9YOQACGoymeHx2mqae/ISsk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=k1pOc0f1dBlja3ZwRDum8FZX0Nv8kE+ib5S8nB5iegTpR0yPlQMrBatnglY8oOcY4V1mcvX4S fqGCYHpWo/kdXrcsq7OUlhgMkIZ3Z59+gSymroe6AOZC06+FB0wkT2jQ0ah71y8H/KAZb+noY+7 v6ovkrWrdCqmZxcitLOoA2b9poTc389XdUzS1O/N010lVMlPSDlnfXyDhSpKaqnlrXQMXY/Nfv9 3sj469ABR8XJZDOxbkMNObfJhrlUyLD96Gqt0dn9GsgEArKfT9FXg0dJdcIhkNReP0xXLW37/Wu hio+iXZ7nsIlHveVqg3LwYenNYURAcDkAEkQ5WWrmE0Q== X-Zone-Loop: 6c902e853bb77121b1975c560b95015ef1f270e44843 x-campaign-type: default x-transaction-id: 5e09d256-faea-4e2d-823d-33208c3e8e00 x-swg-uid: 01-725301e9-b3e5-4ffa-983f-8d0b85eed88e X-Mailer: Sweego Message-ID: <1789133309.8631fc262581453bbf619ec5b2062170.1a090a7c48d000c4f3@vates.tech> x-swg-bid: 1789133309.8631fc262581453bbf619ec5b2062170.1a090a7c48d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc Date: Fri, 11 Sep 2026 15:28:19 +0200 Subject: [PATCH] Add basic b4 config file MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAAAAAAAC/yWMQQ6CMBBFr0Jm7UQoYoJXMSym7bSMi0I6YEwId 7fV5fv57x2gnIUVHs0Bmd+isqQC3aUBN1OKjOILg2nNvR27Dsl7tDd0SwoScWQbKAwD9aaH4qy Zg3x+vef0Z93ti91WI/VhSRltpuTmOu3rVTeKkiKc5xdF+LUhjgAAAA== X-Change-ID: 20260911-add-b4-config-9ebfaf55a323 To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc X-Developer-Signature: v=1; a=ed25519-sha256; t=1789133302; l=1513; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=vIahPKKLQN+/d9nrSLfeD32Mhu3vC7Ny/dnFzc9Y3eM=; b=CaqAMYneS46aLwTRsCiri7IKpU5ly0Reb9Vq+FaUW2apKfYqd3YS0I9ynfFLM3sD/F8djPPra JbFBoGBRxHGCzvrQAc5M+AqjjDesCefrEb/WFVg1RfCqLuBnZD/Ja30 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789133308181 X-purgate-ID: tlsNG-c201ff/1789133314-2551A2A1-50EDBA76/0/0 X-purgate-type: clean X-purgate-size: 1515 b4[1] is a convenient tool for mail-based contribution. A config file[2] tracked in the tree lets the project ship a few defaults that match the Xen patch submission rules. This aims to help new contributors who have never used a mailing list avoid mistakes when sending their patch series. The tree has no scripts/checkpatch.pl or equivalent, so there is nothing for b4 to run per patch. Disable the needs-checking pre-flight check so a series can be sent without first running b4 prep --check. [1] https://pypi.org/project/b4/ [2] https://b4.docs.kernel.org/en/latest/config.html Signed-off-by: Baptiste Le Duc --- .b4-config | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/.b4-config b/.b4-config new file mode 100644 index 0000000000..1ca1f0625e --- /dev/null +++ b/.b4-config @@ -0,0 +1,13 @@ +# +# Common b4 settings for sending patches to the Xen Project upstream. +# https://b4.docs.kernel.org/ +# +# See docs/process/sending-patches.pandoc for the patch submission rules +# these settings implement. +# + +[b4] + send-series-to = xen-devel@lists.xenproject.org + send-auto-to-cmd = echo + send-auto-cc-cmd = ./scripts/get_maintainer.pl --noroles --norolestats --nogit --nogit-fallback + midmask = https://lore.kernel.org/xen-devel/%s --- base-commit: acd87f99ac65ff9426dd52f9b7a6ef9db45cc735 change-id: 20260911-add-b4-config-9ebfaf55a323 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:36:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:36:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416779.1645701 (Exim 4.92) (envelope-from ) id 1x51Qp-00059Z-3t; Fri, 11 Sep 2026 13:36:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416779.1645701; Fri, 11 Sep 2026 13:36:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51Qp-00059S-14; Fri, 11 Sep 2026 13:36:43 +0000 Received: by outflank-mailman (input) for mailman id 1416779; Fri, 11 Sep 2026 13:36:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51Qo-00059M-8S for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:36:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51Qn-008bWD-6x for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:36:41 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa403df-bab6-0a2a0a5309dd-0a2a4501a740-30 for ; Fri, 11 Sep 2026 15:36:41 +0200 Received: from [52.101.56.0] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa403e7-5984-0a2a45010019-34653800167d-3 for ; Fri, 11 Sep 2026 15:36:40 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB7393.namprd03.prod.outlook.com (2603:10b6:806:39d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 13:36:38 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 13:36:37 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vJ4z3GKmraEhkm7bjADhFvyU1oM8VOx0ujbxHIT/XGdHnKhUvHFCWBlnjyXYa8B/vK1PR6+/HyDUPeMDA1wBTzloAtbOpxGknmBipF0j9Vg73V2ln953YEPZb3P1ZvTChYp3hHXQ7jm4U3UelII3bCThDaYMAcQc6dZmQp1M7+UhH8+UO4TxcwNCmle3vkDDaG8zXkt0+HoQWqxW0Q04v4CZoTGBgQMo5camVKBzOyzXd+k6hKI0F/ja6ny2cDZBjgLH6VVtLhO8d+4dPi22yoSk+j/qPhCp/6uZFSPcaxrqMJEzdSo7mAuv7aSFs7nVRwVlL7kwASdegtakTuDJhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CNIDaemXg2ZXLIkL7I+0+KM63ZpJMzcetANXfxpmyRc=; b=TtFbVsnF/arulpLqRbu+dihsICnE7XljCln77+9WgtA0Pk1Bf53L4C2uCsxO7Ve0RINvxaib0UX9ia8VYpVB+jbrcRqSTlbV/vGubGKh4bHtuJiwsPm+DuZVEb8MYkxdF/BymaWtesQSaJAO4yrtDRTfMagWxEHZqnJu4Fk0wiBBWgD4GV0QtwtF3L/ST1p0iTpI6qlUk3/esjkGH8XkbZ8n4yw7haRDazU3LxBdGBH9VnoDzHApwmFDi7Ojvkf7D4wqRpvkaH/kQ+h47s5f9WS4tgEpyP79WL7zsU7vQaIN2n3GrO0495bQdM4mQPgOwS9RrpTNDIIu7culWbD7bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CNIDaemXg2ZXLIkL7I+0+KM63ZpJMzcetANXfxpmyRc=; b=siqY02RUp3bKlp73qREc0nNbvDLHvGK0cwW1y8sepgyA+3fR28F8OOkOMGG50BSeU1b3LERvbRcY2bfALmF+nIvXCfkYo19y876ZLrx2DXP+5eY6zkQL0GealzU+ayNy4dh4tG1vSkpsEEAJL7NTsk1oAX9xXQlCyhzBu0xQipY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <10df3c15-990e-43db-8cc7-578f44a2bbfe@citrix.com> Date: Fri, 11 Sep 2026 14:36:33 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH v2] nestedsvm: Fix multi-byte IO port intercept check To: Ross Lagerwall , xen-devel@lists.xenproject.org References: <20260911132315.1209497-1-ross.lagerwall@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260911132315.1209497-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PA7P264CA0511.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:3da::23) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB7393:EE_ X-MS-Office365-Filtering-Correlation-Id: 941cc833-87d1-44e1-18fe-08df1009b476 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 6xeS/AhWKdAa4VHe0Ff2qixZjjNTLtbDnJTg68iKyUGpfexMv5Gd7HHh9zSsIvLVOAun/CVGjHZOVSUZBCpIHXqlXjthcaGd2KlYFoQFQhN3zqPoVT/VSKOYGDgDBQLk5pnmTlVP7z5PTpujCjScU0r8hHPOVBuybQME5DLqSOXiR4Nbfe4cRBPZoL5b6lnyzqQC4QPPAy8YnIB6n08AxMz2olXvR7ZWhnrOgMUkufdVfDoRDqVNe4Rd81nXRSJDPsuv+AH07b4cgHThUJ1VakZ2tFcPdBSWi58NqW14zy7xwe3cVw/CZaSpP45xOiS1/y/m0GKeRQvr1rD2eKb/ej52p9TTDaBAcMGWQ/Gak2MuZQsItl8joUSQhl/s6SIVY5OfuwCtsfJhbnfSEzOHcw+accEcHrOnIXv+5fXMf0xZV4E+oj0h5b2DTNfGtPGCxGb5qsIUghrn6IW0B+jVfEy/WianSvdRWFbzJQhan56Mm0pzkDeIykHYcued5tmvnMWAx8nt8I4Eq84vY+1dQJba0bRyznnzXQPLn0m5gfHTguMNTnKr2sveJpgUdN0hQJeCNdP/ZA7zlbKAMLAe59dNDTYlxT2LWIDk+xis7z/fqy2v+OwAACceOlv2GieLRXKELhAdSaq3PJjygk2xds1LavchZ3uDVULHp3jV/MM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y2lGQ1cycjBCNjBRMm56NGwrUzdjcHZHQ3hEUEVpT2p5RXdtQlpCSVl3R3Iw?= =?utf-8?B?STY2YURJekpsbXlLSHpTdExkazZHVWcxR0VYb2JldG1CQXIrNnErRzVIYm85?= =?utf-8?B?NTExM003eGVlUWw2N1hDbktkWGNGNEFNTVZBV1ZLWElPSEd4WFB4bmNaUVYy?= =?utf-8?B?RU1ML0tENWZmSSt1T05lYW5SSWhpVjl6dEhFR0QwbWFKTkgveG01K28yZi9x?= =?utf-8?B?V3FTUWxnS2NXYXgyR1ZpWXZDUExpVDF2cUxpQkcxem5Oc244dHBGMVUxdG13?= =?utf-8?B?NGxRcGxZdXphYVZvS3l3OGQxblFaY3hWR25EWlJ2aDRuK3MyTitsTUljVUdx?= =?utf-8?B?cGFFQTNzUy9zQVpQWWlGeVkwUSs3eWo4cXNCOGNuUjN6MTBLUGp2YTRjMzdV?= =?utf-8?B?UUdUaE5jaGRzUUVoUllPalpNK1VJSjUxZktPTWpnM3hXbXlxMWltdWZMK0dx?= =?utf-8?B?S2tBeXBzYnN2QTM5MlpYeHc0cEpRMmlHZWlBRzVqQzB3TUpEVm5QOVdMSEts?= =?utf-8?B?Sy9GUnJHeWVMOVNZSDRqTmUxTUl6U1RxbWoxcUVQM1VRODdFY3gvUURkQVk5?= =?utf-8?B?emFEMG5tK3RsYk10bjU1YithTlgvZDZ2VEpnM1VmdWVqMlNqVE83R2ZQMjhI?= =?utf-8?B?TTlXd3YwWGE3MVl0blk3a0kxUEYwa0x6eVQ0S3RnSlhlNXNocUNJb2xEM2wz?= =?utf-8?B?WWgxSmNaTkduTDZJMUVia0RiVW9RKzVTejRiUmQ4MEFaN1ByeWVVemlGRVlV?= =?utf-8?B?Z0x3cGNiamVENVBCZVFLNEFueTVIVkFsWDRUdWRhVVB4aTNjWWZFcTNxbCtv?= =?utf-8?B?N2MyMU9weUdrNC9md201bENTUURxUVExeGh3b3NXSDFIeEY2MFpUVnQyejlK?= =?utf-8?B?VjVadk9MMnh0NFQzaU10UldCWHN3Q3ZONUZuUFgrMWVmcGY1KzlTRmp3Q1pB?= =?utf-8?B?cTI4NzdHSHh0OWxXOURxdFJaTk8yZXByK1B6SDhnd0tPOG1UL20yelpPUmc5?= =?utf-8?B?ZGdMdCt0Q1lBbmJURjRFdDdVUS9HaEhNd3k3bEFFV2QxS09LS0hSWkpFdmtp?= =?utf-8?B?djRGeG1mS2laVk0yanBDNXJITWhPd2hHcHlqdk1GdlBONHg2NFZvZVZ5RTUr?= =?utf-8?B?OFJtVnlML2U5a2ltMC90dXd6WCtPeGViWTRVbFFDVkFaMXYyUXlXSDhyV2VM?= =?utf-8?B?S0dUeGFwUDZhNGVkRkxEaW1jY2YyQUhXNm9saEU4R1JjTTExODlKNmFpTWJq?= =?utf-8?B?M1FLVDJ6a0VHc0FDR0xYQ0xqeEc0VG1tOTQ2eHdkSG52RndJeEpLaXY1cW9v?= =?utf-8?B?cUFaNkxCVlQ3ZWR1QWRCV0dPRnN3OFpQTCtEUFdNQzl3d2RlNnF0blIwSUIw?= =?utf-8?B?WEZMQ0VSbWEvcnJ3MVVCUzJRU2hQV2hjM0VJUU10U2VtMnpyTytsY3Y1TVVp?= =?utf-8?B?enpJU3d0QWdWTDY0T2lKN3RYdjdjVWxNZmpQNmR3R0hOUmMxK09KLy9ETDFM?= =?utf-8?B?K25pUFYvS0tnM1FmYngzeXc4enFNQkNlKzJXRHk1NEtNckhzUDNQTXVPanNu?= =?utf-8?B?eUdEV2greU9qUEdZbzd2VXkvOHBwM212c1ZxR2ZHUnEzUFlmVGlLUTJOMDgz?= =?utf-8?B?MWlDZnFOYno1MkxWc0dGd2xBa25oS1EyRStZdjVtTHdSZnhXL25HcUpBRzMr?= =?utf-8?B?T0pDdlpSd0pEelpuL3ZSTTIrUWZCYW1JZmNCZjFMT3Y1Z1BKQ1M4NHFHY2lX?= =?utf-8?B?SkJaem9DT0xXWHJPbjRPOVN3SGxzWTlRa3BxdFY0WExxWlJnVUlGK0ZlbzNq?= =?utf-8?B?eDJxUGVZTTdNekVkWjlxRGhJUTFMdExSTXVLMWR1SWo3ZlU4MC9LWGZDVk4y?= =?utf-8?B?RUt6ZUIwVXhJNEpZaFBYTWNHcFZVYkdKcC9kS2QwVVpteG51a2Z3RXY0V3da?= =?utf-8?B?MXQ2cmJ3anAyNkRXbmIwZzg3dlZjdjRkYnBxL045S1VramhXdTdJeXBmTDFE?= =?utf-8?B?RHNiemoya2c5S2RVODZwQ2l2aThpSEFFMnVLRFlqeFhHWnYyUmR6M3JyNDBT?= =?utf-8?B?UDFNRk5uNzFrRTFVcjF6MFVsN3hwdWNlbWtiWFEyd3A2VHFkaFcvR0I2M2p1?= =?utf-8?B?dXp5UTI4b0NJamJodEp6WGZHTWtwTmpyWFcrdDU0dVE4OW03VTJ5RHkxUTZ3?= =?utf-8?B?MmYrOEloMnFxZDVPaTZ1U3NlbGlsNEJubGFHUnJLN3NDbkg0UGFycmlGNDJW?= =?utf-8?B?WmYrV1NGVTJBRitXWW10MVVKS1g5U1ovWlRVcXVzNCtFZXhzL3Jjd1FkQWNV?= =?utf-8?B?bkxhOU14MUc2TGxOYzhvQ3JjRVcrczN2YlFXS0hMaThpVWJjUktzZFB5aWpx?= =?utf-8?Q?YFi6p8eumysS18ik=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 941cc833-87d1-44e1-18fe-08df1009b476 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 13:36:37.9214 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: J7kdr0canqQOaZmO6MH7opSRjPxGE1i7iVby6iuj4B0wKWoFtnXOanHgrIrvW8llY2WB4V4vcKbd0ydce8KTG6od24m+pveRYhk2hW5IQos= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB7393 X-purgate-ID: tlsNG-d62444/1789133801-BE465757-41C45A86/0/0 X-purgate-type: clean X-purgate-size: 1676 On 11/09/2026 2:23 pm, Ross Lagerwall wrote: > For multi-byte IO port accesses, the APM says that SVM should intercept > if any of the corresponding permission bits are set. However, the code > has this backwards and only intercepts if all the permission bits are > set. Fix this and at the same time, make things safer by handling > mapping failures as intercepted. Also rename the 'enabled' variable to > make it clearer what it does. > > This affects Hyper-V since it does not generally set all the permission > bits of the multi-byte ports it allows its root partition to access. > This results in an L2 root partition that cannot do PCI config space > accesses and therefore cannot access its NVMe disk to continue booting. > > Signed-off-by: Ross Lagerwall The reason I asked about 0xcf9 is because it's the one-byte PCH reset register, which hides fully inside the normal 4 bytes at 0xcf8 for CFG accesses. Despite outward appearances, the x86 IO space is not one uniform space.  It's 3 orthogonal space (1,2 and 4-byte accesses) where the target device gets to choose whether muti-byte values alias in the spaces, or are entirely disjoint. For the HyperV root partition specifically, I'd expect 0xcf9 to be unintercepted so as not to interfere with the final steps of shutdown/reboot from the main kernel. The patch looks ok, but I think the second paragraph needs a bit more explaining.  Are we saying that because 0xcf9 was permitted, we allowed 4b@0xcf8 to be permitted, changing L1's CFG index rather than changing L2's CFG index, causing the subsequent 0xcfc access to produce garbage? ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:38:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:38:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416787.1645712 (Exim 4.92) (envelope-from ) id 1x51SB-0005lk-EG; Fri, 11 Sep 2026 13:38:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416787.1645712; Fri, 11 Sep 2026 13:38:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51SB-0005lc-AN; Fri, 11 Sep 2026 13:38:07 +0000 Received: by outflank-mailman (input) for mailman id 1416787; Fri, 11 Sep 2026 13:38:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51S9-0005kE-Pn for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:38:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51S9-00Bdrt-6W for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:38:05 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40438-8faa-0a2a0a5109dd-0a2a4503acc6-24 for ; Fri, 11 Sep 2026 15:38:05 +0200 Received: from [40.107.200.13] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4043b-fae8-0a2a45030019-286bc80d41e0-4 for ; Fri, 11 Sep 2026 15:38:04 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DSSPR03MB989189.namprd03.prod.outlook.com (2603:10b6:8:375::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 13:38:02 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 13:38:02 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TMF+sCH8Gs8HDZNMV0V8/0j+tjd9pxraqhKNi1vBOT1WyDsOp+ktl1xmLtjOlz19HwPDYbfR6xJJ+QY0MKdXYTrVL84URjTNkkrw90VKA1fZc0m8HMZu52T0eOG27jkIdPI8rtSWBikVJhTECWHbBfWqx79nADT+z8ssrdMMdwyL2EI5UBG1RLQnL4J2IjLhd1ZergZG05qk4xqrI+sMaGWrIiEcTBL7bbMITNBsG7TqQP+B1EbqTmRybHCUiLFKHxTHm3th2sDKlnMLDvcAw+aOmI0viOtz2wa7XANpibLIl3xl/aQBMd7/gqqiVk+oXy2CXn1CKq4DlPKk5Tt/Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/yIPE0AGlvw7y8vt5wZos56FplFsOc+Cx0ylaz1jFSM=; b=ROQlaFwC97084EOR4Zfh7OW9JN8wq/FLOFb1Fl4j8WK9VNq5NHV+JUNQjZrlUOvrtlxpLY40brrj+Kv8mx5bbwypxcn/iIutN0fWxgoW5FelWh4TSnZf0KfUv8DANjvecoPa8x6uvvDoH1CCFrDonHgauzMtZrNAnHkTp7Lm5Y9Ym7P7Thwyoluk91h4mrLPPgXwyMh4i0AQ8aFLi/mUC22rSvLizlVeUycxxAypg6SGH2e3/Vv/IT1JETxNJ31G70BXPfDpVrDgdIcTIHpYtgwXwD34jMBGN3mf1ihTMf3YUaMOaGIe85b0OnAOOxqct7VAxCCZshuYN9aSLpi1Yg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/yIPE0AGlvw7y8vt5wZos56FplFsOc+Cx0ylaz1jFSM=; b=W0xqj8ShOcDMKllcWTys5OaifJUbm+k1h+S1R/9rr1VHBk1s/kZru/Zlzb7Vc+RRHTlXAUgtvvB56tv8bGxiHwe+erZk0AcC7OcK6iJzMmxTJVYdTKQc+5uNtRr7DIYn4yKtoKVro0MrAuV23PNFimTgUgxbyqCeSGz4vNXBEh4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <13afb847-61df-4568-af48-e35ba9c5f564@citrix.com> Date: Fri, 11 Sep 2026 14:37:57 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 5/6] nestedsvm: Fix deferred event injection To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , Jason Andryuk , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260526124027.573412-1-ross.lagerwall@citrix.com> <20260526124027.573412-6-ross.lagerwall@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0212.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a5::19) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|DSSPR03MB989189:EE_ X-MS-Office365-Filtering-Correlation-Id: b7b1c675-1b46-41f0-c54f-08df1009e688 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|10067099003|4143699003|56012099006|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: /fA+A2JqT8FcIAB0W1+DXlcIFIj5xy4fPbMAMz+1ZTyNh5+6+KZgG4Ya8N2PlktvJtd1oG+bKIokH4dTR3qszr8EHC3gOmWrs+LnIu6d/7QA1pjRYTSzFY84IQ1k31UJNro3HQRan+SUAt1Z5TjYZwAl06Kt5230U8r2svsSfYuPd9IV8rDS7GP+Zv3KbISALW2ybAnwCZpE1bMVT7EY7fknbQ5Bbd9TWYi37NWzAly6YhUgFqOKtz+CctXTdNFRkngIH5VK4bq/VLgX1gnLG40bOZtbg4Xg1Fh0iIkRCu596rtgBTZZ9iPl/uyubzna1wOrFgDrPv5I6IDvTHbaK73cF7qhQOu6koio/wpP5ZxB81cgMx5g3cCg5MzB4sfyMH339DRNyDS7Cy+08iJuEiU88sQ+4JgryBp2PjryKf0GwVupU0lwh0VbYMbhpuoYincRIlMIcXFo1hJ+ucE6oijmEi5pEcmi1xu3FwBdYBh0xWphFO3miWDCyR9MuuxE+SzFae3LEnW/agNTbpXeHVxLZdwBM1KwDU8+NDnzxYbxHbXEeuhUaN/mVDuQyKqeR9CIcEhWCSQNmQVe6cgRo5JL0DAJxFwtE+g+3cLP7vG54A+szGUikVFwP+MOZ3xXraukqI4m3LkDS/QjOfzfjaj2gtOxgy0YF8uzJGFe5JQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(10067099003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WDl4eTRBR2txMFo3OWhKd2lPd3Y2MHFjQjFGTldnb2ZrMzJQMjRZOEU2SG1t?= =?utf-8?B?UEd4RVV5cTRzeUtJK2RjdXphL1NFS1I3aGlSNUNGMmtaV3p0VW9vOWJQRDEx?= =?utf-8?B?UlNzamJyZS9HVURDYzl5Y2pRbVNBUlcrUmRVM0N6Z1lCYjZBNWNtUmc3WUd0?= =?utf-8?B?WWI3QmZqQllQUis2WVg0TjhmZUF4WEd3VUlKRGRzVldvU1AvazdQUVErdnpz?= =?utf-8?B?bWlweElJUHd5QVRsZWlLWHdLdzA4TWdwTE14MmZCNnJiQ0E1RXJNdXJCMmYw?= =?utf-8?B?K3Y2N1N0VWpuSTJPcGdKSUdaY3J0SEgrczBMMW9ZYVRkM1lFQjNNQUIyTEtQ?= =?utf-8?B?dlNQMWN3YlB6STlSL0ZJOFVnVUxmaWMyMmFJdm95Z2haWEdRZnlGZDlDbnJG?= =?utf-8?B?L0QrTnZWWTBjZHNHZHNoelNVZFFxd1FJVUI1Z254b1pENXhUaDk1bVBnSmV6?= =?utf-8?B?c1FDVzFJa3dMUVNYT0JUWVY1VlRUOVlCTEp4UWx4ZGxqUTJNUFdORUc0aE50?= =?utf-8?B?a0NZeWFxYXZtVk5uOE50QjhmTzRXeXJmTWh1cDlKSlh0ejF1QnlVZklKRkho?= =?utf-8?B?MDB4TnF5YSt3bmdadlRscWV5WTV0SXdUNmZ1WDY3R1BrWXJqUGVTUmp3bHE0?= =?utf-8?B?Lzd5OW9uVHlFdEdGdlM0aDk5VnQ2UVNXZDI0NGZEd1dlRUIzZlVkNnlyQWtO?= =?utf-8?B?SDVXVlFsS0xtZnROVWVUeXkzMXhpMnRocjd5NDdnQ1FDSEk5OGdZQXlZNXpC?= =?utf-8?B?RE1sckhTLys1TDBzV3MveFdlRkxDdjhhZjlWYjdiZU9NOWF0ZmdzTGlPSEF0?= =?utf-8?B?QWE0M0xmZFg0UFNWTVFGWTF6SFZENzBPUFYwZzJQWXoxNXlpRGtEU2kxVnNr?= =?utf-8?B?S1dCc0ora1J0U1UzelByWWxWV0FzZ0M0azNJc1FacHhjeEpnaHZlTkFQdWJo?= =?utf-8?B?U3hZTzlLVGV4UGRlQm5XdWFLeXNzVlBnS0p5dlQvRkt4VDd2dGxtUEplSVgz?= =?utf-8?B?VER0Um1YK2RYQTJqalZYeTg5aDZQZUJFc095aHgyVFRFSWxWWVdkeXFUR1gz?= =?utf-8?B?TEFZb09mR1pSNzMwbHNXclJVejF0SzEvRXRhNTZNWnBBa1ZsRU05dlgvcFBC?= =?utf-8?B?Z0EwR3VXa2Fvb0UyVjNOc01zR3hSRFJaUFNMVElWVi9PUW0zNi84akdDZkQ4?= =?utf-8?B?a0psYmthZVBjREJCaHUydjVpZWlvSXQyTmdGa0NkUG9mOFNGSE5VWk5oWmNM?= =?utf-8?B?anhvM1VFUUxadW9kODZaUUZOSVNKYmNSWHl1bXN6M1dqYU0wZnpnaXNlemFS?= =?utf-8?B?VFFVcDgzaC94a3loNE1TdUhFZlNIN0EyaDJiUms4SmRMK1dKVEhpVjBudnRI?= =?utf-8?B?bEp0QVNpYkNNL1VkTUdCeFZNT2xibmczZUFoRzFqSXYzOUJZYytqODZkVE9s?= =?utf-8?B?aVhaSDNFK0NzWVladEZRazZFb2NFc1lHM1RKNUN4UTNha3BEZDR5ZTV2MkdN?= =?utf-8?B?enRLQkY0b2o0TVoyd2VPVlR6YVFXQVRRemxQdSt0MFpPSldxZlNLVW1mbHYz?= =?utf-8?B?S2hKa2hUcmx0Y29mUHQyM3pMd2xsV3JLVW1xRFRYWGJOcWNmN0lGK1VPanVE?= =?utf-8?B?bnE5L1ZMVXVneDVqWEFxNkpFcWs2dlFGNTB0ajJubzMybldTNkt5bVl6MVdx?= =?utf-8?B?Q3FITi80cWNqYTEzZjJMYnExWk9tMzZlK25tMHBhV3dOQmNnT3lYUGFTZTVB?= =?utf-8?B?a1pHdlRsV296UTFZWTQ2T1hrSDJ3V3VoM1VVbmsvd1U4citibzVybWhZMmV0?= =?utf-8?B?cVNUQ0ZsdkRPVWRjSTExS20ybzYrNE4wNWVLaTdWY1gxSGtVSENxd244Z3VQ?= =?utf-8?B?bHc4V2NsUGR6eUhabmRwUnhDaWh0YlVXK1FFVGNlQWQrTE1HakpPVVRJZWJ5?= =?utf-8?B?dzFGU1lCeDhUQmpnRUdSdzc0dEtXQUtKYW5mZ1NvRmV0dmlHeWVJa052Rzky?= =?utf-8?B?Rms0ZU50MjJiT2R6QUljeDVnV1FSQ3MyQnVNV3RNeDN1eTRabHNBd2ord3J0?= =?utf-8?B?Y3NESWYxcjJpdGljNnhEN3N4dTE2dTlob3J6VlNNK1BLOVN1dDZCNUVnSUo5?= =?utf-8?B?aGdiZ3JOT0pYbzlvcCsxTzJYY1pudzl4RHh4OTZuRU8rWHVSREZDSU1BT1Rp?= =?utf-8?B?d3V2YmJicFhWL1Q2bXZENkgwVCtDcGRnK3VnZytpUGpyRVFWSGdwQ21UUy9R?= =?utf-8?B?NXAvc2ltZVRORTlSaWp4UGsyR1NSOFRwT2tNL2IzdmFCb050Q2g3dWpzUmZE?= =?utf-8?B?aW8zQlE0S3ZpbVlqQk9mSUNhbUo5b3NFdGkzdzJnVlZuNFN5MVVsOEJMWTlV?= =?utf-8?Q?GxHVfX7y2qT9OFXg=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7b1c675-1b46-41f0-c54f-08df1009e688 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 13:38:02.0030 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zpklQkMQErUdzjTtdenF3hD1K+9dFL5P/s32C9Y2A6ythjJFjRG+Fd/4pRt1ozA3YnzNpsgbRBbl30Kqhg7HqGsfcOke6jpMw1BM3CqVMm4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSSPR03MB989189 X-purgate-ID: tlsNG-33051d/1789133884-74E874E9-2B39DEB3/0/0 X-purgate-type: clean X-purgate-size: 994 On 9/11/26 11:56 AM, Andrew Cooper wrote: > On 26/05/2026 1:40 pm, Ross Lagerwall wrote: >> If an event for L1 occurs while L2 is running, Xen should inject >> VMEXIT_INTR and the event into L1. >> >> nestedsvm_vcpu_interrupt() and nestedsvm_vmexit_defer() set this up to >> be handled later by nsvm_vcpu_vmexit_inject() after the switch back to >> L1. However, the code there appears to be bogus and completely ignores >> the source/vector set up in the first place. Fix this by using the >> values to properly inject the event. >> >> Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") >> Signed-off-by: Ross Lagerwall > > I'm reasonably sure this will be unnecessary when we fix the underlying > problem of deferred entry/exit. > Are you suggesting if the VMEXIT is done inline in nestedsvm_vcpu_interrupt(), then it can just fall through to the normal L1 interrupt injection code (in svm_intr_assist())? Ross From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:41:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:41:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416796.1645719 (Exim 4.92) (envelope-from ) id 1x51Vn-0007Vv-Vb; Fri, 11 Sep 2026 13:41:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416796.1645719; Fri, 11 Sep 2026 13:41:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51Vn-0007Vo-Sk; Fri, 11 Sep 2026 13:41:51 +0000 Received: by outflank-mailman (input) for mailman id 1416796; Fri, 11 Sep 2026 13:41:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x51Vl-0007Vi-OH for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:41:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51Vk-00EGpm-UR for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:41:48 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4051b-bab6-0a2a0a5309dd-0a2a4505c20a-4 for ; Fri, 11 Sep 2026 15:41:48 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4051c-4cb1-0a2a45050019-4a7de44ca7c9-3 for ; Fri, 11 Sep 2026 15:41:48 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a9ba73bee8so437979a12.0 for ; Fri, 11 Sep 2026 06:41:48 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c296605b39esm78511466b.23.2026.09.11.06.41.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 06:41:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789134108; x=1789738908; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=eYd047a24qXsJoz1TM5uRKmr6kWZIo7d6eX12Nqivx8=; b=ZDJbRzDraR00BpFUCALDbSYttQhBvyEfwNWGexkH/PIFP7RXBMO/2kjVPznk4YZfFp OZpghhBchg9uGLavzYBskFwDEoX320110YDtnjgISnoOi8NYunjUusv0u4C8YDrEsQx0 /xP2cHYoVnObmk7/c8zxS/C3CH1YMtxmKjyPWNSDB2UhqBAIPhC0VrbbDRcV9Oct/PrC u15HLqnJUm/IudpmUtE7fGB9lpCLlOe+Jd3YdkOfug/g7YTZhb4lX5VDAEGTNHpCwMY5 zdu0egLPM3eLfxcebxNAzgLMIvyxGniM2yqyQ5u4RCOCSLn6Qc7LivVCwqOS1mq6NcTf fkYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789134108; x=1789738908; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=eYd047a24qXsJoz1TM5uRKmr6kWZIo7d6eX12Nqivx8=; b=eJ9/woImhpB3eM7dr/CgT5O1Q10qpBGkpw2ecDnShcmmbpuVHAtshto0aqLyekK3XA mRuvurvplKkFgJpjn2zgEH38kPsWRx0h9I64BtLK1ezK03P3ze4njCIwqzGLrpO9nb1N HU4eg1+oBp76UiYLR2uXWoykuNtg29F01UzsiAx42OhspXrgfo8L7TbNz6sJGfy2Si12 3Y3d/WNgbkADmCc6YLSseO588MMmQHpi1PlGCCCoFj5XlQyEPbN/t/JGhWesiqAoEYsz 2l7Cu+kgaw3HC2HWXKSN18lwvhYl8QZ9C+xS9MBBRTwmou3eJOKBq48f1VnghTB+D1Mh vUwA== X-Gm-Message-State: AFuF++lWOYhb2p6OzjBQNvolrBIrNMSc4L9JYIofvoZn/bXGfPjuYYsy ZNA3y6LXOQbAr9xmiYkTcB8w0DUmyG/zeLA2rADzrXLgek660FV+HP0M X-Gm-Gg: AYBFou0Q7F24vM8fpfNrVaEej92x+Xv8XwzXkZGHAHZLfaJHPj2kc5tk30ofCsW9gfh 1chv0yvNN//863uDzmXG3NI5aRvt+YSEVE/Ed0j9wlrbUCP4RRDBJg15CiJi/LJElwkEhDPS3jU nFF+tVMcgTqJDIyrG0y8JyCurT2qIyTNIwdYI9DAOeIStB9MePSn/mAtu+eNFdIYVSjo8hjVqb/ txbHGzwbrOyZ6wgOd7MUsd5GGZhWY8iDzf7wiob8XLVTeO+0YIM5TqLr6krqF9DPyZ6I2tlNa9c hCMmlztlaj/OnEStdztrBj7uhCfUi0Sen8cLjXVsDoWvUtwc99ph9urVJAPDm8dXnhZwaPgnf0d M17v1zy5ctOlgu7e/b8TN4Djlriy48Yf5kj4iKC2USQchSZLYCf9n2RI156d4cA4m3nBMNFwx6t 2SWNuEX96+rM16cCAZHOqWpxXPkSek+jD1eAbhSNiI+bsVjMNWMNBte9bwZT9sot/m0LiIllmGH mrTFJ3KM0gqNjcdkPZAGyQ5XYiuF735uvI= X-Received: by 2002:a17:907:72c5:b0:c24:6382:2648 with SMTP id a640c23a62f3a-c2962a6edf5mr241508766b.5.1789134108265; Fri, 11 Sep 2026 06:41:48 -0700 (PDT) Message-ID: <1ce9effb-a632-4a48-aaaa-3c810ebd255d@gmail.com> Date: Fri, 11 Sep 2026 15:41:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper From: Oleksii Kurochko To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3@vates.tech> <7b743afb-409d-433b-86b9-7ec8be7ad860@gmail.com> Content-Language: en-US In-Reply-To: <7b743afb-409d-433b-86b9-7ec8be7ad860@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1789134108-714AC2A1-FC21677C/10/73395122804 X-purgate-type: spam X-purgate-size: 3244 On 9/11/26 3:06 PM, Oleksii Kurochko wrote: > On 9/9/26 2:04 PM, Baptiste Le Duc wrote: >>> Introduce riscv_read_guest() to allow Xen to safely read guest memory >>> using HLV/HLVX instructions while reliably capturing trap context. >> >>> This is required for instruction fetch emulation and MMIO decoding, >>> where >>> Xen must inspect guest memory that may not be directly accessible and >>> may >>> fault. >>> >>> The implementation is based on kvm_riscv_vcpu_unpriv_read() from Linux, >>> with one deviation: the hlv/hlvx instructions translate the guest >>> address >>> through the live vsatp/hgatp CSRs, i.e. through the address space of the >>> currently running vCPU, so the function can only be called safely for >>> current. Instead of taking a struct vcpu argument, it always operates on >>> current directly. >>> >>> Signed-off-by: Oleksii Kurochko >>> >>> diff --git a/xen/arch/riscv/guestcopy.c b/xen/arch/riscv/guestcopy.c >>> index 8a89212e0b..b2327822ac 100644 >>> --- a/xen/arch/riscv/guestcopy.c >>> +++ b/xen/arch/riscv/guestcopy.c >>> @@ -6,6 +6,7 @@ >>>   #include >>>   #include >>> +#include >>>   #define COPY_from_guest     0U >>>   #define COPY_to_guest       BIT(0, U) >>> @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain >>> *d, paddr_t gpa, void *buf, >>>       return copy_guest(buf, gpa, len, GPA_INFO(d), >>>                         COPY_to_guest | COPY_gpa); >>>   } >>> + >>> +/* >>> + * Read machine word from guest memory >>> + * >>> + * @guest_addr: Guest address to read >>> + * @read_insn: Flag representing whether we are reading instruction >>> + * @trap: Output pointer to trap details if something went wrong >>> during read >>> + * >>> + * The hlv/hlvx instructions translate guest_addr through the live >>> + * vsatp/hgatp CSRs, so the read is only meaningful for the address >>> + * space of the currently running vCPU. >>> + * >>> + * At most two halfwords are fetched when @read_insn is true, i.e. >>> encodings >>> + * wider than 32 bits are not supported. Such an encoding cannot be >>> completed >>> + * by calling this function again at @guest_addr + 4: the length >>> check is >>> + * applied to the first halfword read, which would then be a >>> continuation of >>> + * the instruction rather than its opcode. It is up to the caller to >>> reject >>> + * anything that is neither a 16- nor a 32-bit encoding. >>> + */ >>> +unsigned long riscv_read_guest(unsigned long guest_addr, bool >>> read_insn, >>> +                               struct trap_info *trap) >> Nit: every other function in this file / declared in this header >> (raw_copy_from_guest, copy_to_guest_phys, ...) has no riscv_ prefix. Why >> does this one get it? > > Agree not to much sense. I will drop it. Probably we still want to have riscv_ prefix to show that this read_guest() is specific to RISC-V but others (raw_copy_from_guest, copy_to_guest_phys, ...) could be used in Xen common code too. So I think we could keep riscv_ prefix. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:48:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:48:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416806.1645729 (Exim 4.92) (envelope-from ) id 1x51bl-0008BG-IZ; Fri, 11 Sep 2026 13:48:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416806.1645729; Fri, 11 Sep 2026 13:48:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51bl-0008B9-Fv; Fri, 11 Sep 2026 13:48:01 +0000 Received: by outflank-mailman (input) for mailman id 1416806; Fri, 11 Sep 2026 13:47:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x51bj-0008B3-OJ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:47:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51bj-003vLd-55 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:47:59 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40687-8faa-0a2a0a5109dd-0a2a4509e558-6 for ; Fri, 11 Sep 2026 15:47:54 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4068a-be1a-0a2a45090019-d155dd2fc430-3 for ; Fri, 11 Sep 2026 15:47:54 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-486f282cad5so306519f8f.0 for ; Fri, 11 Sep 2026 06:47:54 -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-49e636f7fa2sm56091255e9.15.2026.09.11.06.47.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 06:47:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789134474; x=1789739274; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=rWtABwEmX9gpRXPDGM44bj3te4smT5urMfTbKWWSDD0=; b=LYj/b4wu3URXuTboYRV+kfFq2oHhPjnHYELM8mZeWnxrS8GaePKhvk2oa3onixexzA R2CfkdIYcawB+gX9eVjIyI9dORraCzccELt5EkKAL0wzHLqcM1ZwEeDbFYa2n4Yi5mPR lhkMjUdKKZhNzEA385HBxkrmX/7rqKCmKvMlMf/KrypFETnRCMwcVKOSzCmknkxOR6fZ UBXU3EL1CkSVRmiRcR+KT4WTwHSZm5YDuCIq40/A/qewC/j+HzU+VmBELEK3Q8MDy5ta FRnrgr8j+IVt0BR2OzLYiwSpJ5ne18Nbqb3gKVevL1kXf4m9Qz2pVsBO101Xqq+b3aXc Cjdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789134474; x=1789739274; h=content-transfer-encoding:content-type: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:content-type; bh=rWtABwEmX9gpRXPDGM44bj3te4smT5urMfTbKWWSDD0=; b=LNuxKejPwwUhgDeHusqtNfbdTNDQ4saidx3zKTWHoOjsJq01mC7X3PoCSPWPbpsd0o VtAu25ICjOnSahmDF5B/degd6nhiWNRZN8QJ3248sCqUNkr8jp1sKIa0aCFqqOKjfM0I Stxdl6AK4fchbTgY4IN43+N9I+8J6apZ64nqKlmFLiPnds8jSh0Pg6Qh6QjPR2VOBtbN 9tQmgs8IWjO4qfBmpPoFniOIPz1a8mDdV2nF1TsrQ04zNUFrjs7qNdlqDiJfr4mm5mwq Dp4AqlzOqsGW4OU9HcbkE473GnAJYPDg+7+CMSKsY8XSMqg5l11OS7sHIyuaxQ2jZEDN xbFg== X-Gm-Message-State: AFuF++kkfY1oaFvKe/Oqf5JqQ98AGeLhBy1Niu+INOTbAkAvwXyZPGtE G3/8aptYlsD/IW3KEU9g5ynOym5wDodK5mv1bvLR61KLdQzCnW6H2YoQoaJRgAz4Xw== X-Gm-Gg: AYBFou13AqaXIUdF7qZTfk1erqFeq3Ap+5Atb8v7DmmHrjjhuLWnh1DPztF3EEyaoLs 0w5IEC2q751GDWsjs3JFK+9NUIziBrIg+EoGC7qcegI7jEDszhvqlPkIExbjFnrKdIAfr2iS3hk CDEwMJYWVuP5T6UKHsgLiKPng6Yi+PCJAB0VR94ifAWLjTiyw+cYLEjj1MuZDTvZTZ5IP3fYHul 9hH9woYtFBQE0mviiPV4MdiDm2aoSejTTcWAIdTBI2oMtjm3Jr48uhBPjm6vIi89hg7cG4IHxX7 ZqO4WmA1jc7Jxbk+eUMsRW4EMl26exzBgBO7tkCr5UwFezt391yK4izEPitLsiChX/GQZ2a5vMz of5sn1yEgOfR8FaV3Uic1rXRXFPLVH9ipY0IxewYxqLRq4JwfVj8X6Hl1fQFh/dmn36phcfa8o6 F0lvRpMma8km6XCDLlA2lYa3eWnQmn/37CvE25PkAOcBIwxPC+rQxC9C9Pm3I5KmNptpdueJ0P/ vONazffdJBrrvtRGQe2RQgniwaI+KyrJmahNk8NLG1ea8Aprv14RMgDBD9mX1o= X-Received: by 2002:a05:600d:8496:20b0:499:8aff:59b6 with SMTP id 5b1f17b1804b1-49e6199234amr34887665e9.14.1789134474185; Fri, 11 Sep 2026 06:47:54 -0700 (PDT) Message-ID: <7a683895-d145-4640-b0c7-390408404a94@suse.com> Date: Fri, 11 Sep 2026 15:47:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3@vates.tech> <7b743afb-409d-433b-86b9-7ec8be7ad860@gmail.com> <1ce9effb-a632-4a48-aaaa-3c810ebd255d@gmail.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: <1ce9effb-a632-4a48-aaaa-3c810ebd255d@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1789134474-3BCD7034-D0FBD2AD/10/73395122804 X-purgate-type: spam X-purgate-size: 3416 On 11.09.2026 15:41, Oleksii Kurochko wrote: > On 9/11/26 3:06 PM, Oleksii Kurochko wrote: >> On 9/9/26 2:04 PM, Baptiste Le Duc wrote: >>>> Introduce riscv_read_guest() to allow Xen to safely read guest memory >>>> using HLV/HLVX instructions while reliably capturing trap context. >>> >>>> This is required for instruction fetch emulation and MMIO decoding, >>>> where >>>> Xen must inspect guest memory that may not be directly accessible and >>>> may >>>> fault. >>>> >>>> The implementation is based on kvm_riscv_vcpu_unpriv_read() from Linux, >>>> with one deviation: the hlv/hlvx instructions translate the guest >>>> address >>>> through the live vsatp/hgatp CSRs, i.e. through the address space of the >>>> currently running vCPU, so the function can only be called safely for >>>> current. Instead of taking a struct vcpu argument, it always operates on >>>> current directly. >>>> >>>> Signed-off-by: Oleksii Kurochko >>>> >>>> diff --git a/xen/arch/riscv/guestcopy.c b/xen/arch/riscv/guestcopy.c >>>> index 8a89212e0b..b2327822ac 100644 >>>> --- a/xen/arch/riscv/guestcopy.c >>>> +++ b/xen/arch/riscv/guestcopy.c >>>> @@ -6,6 +6,7 @@ >>>>   #include >>>>   #include >>>> +#include >>>>   #define COPY_from_guest     0U >>>>   #define COPY_to_guest       BIT(0, U) >>>> @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain >>>> *d, paddr_t gpa, void *buf, >>>>       return copy_guest(buf, gpa, len, GPA_INFO(d), >>>>                         COPY_to_guest | COPY_gpa); >>>>   } >>>> + >>>> +/* >>>> + * Read machine word from guest memory >>>> + * >>>> + * @guest_addr: Guest address to read >>>> + * @read_insn: Flag representing whether we are reading instruction >>>> + * @trap: Output pointer to trap details if something went wrong >>>> during read >>>> + * >>>> + * The hlv/hlvx instructions translate guest_addr through the live >>>> + * vsatp/hgatp CSRs, so the read is only meaningful for the address >>>> + * space of the currently running vCPU. >>>> + * >>>> + * At most two halfwords are fetched when @read_insn is true, i.e. >>>> encodings >>>> + * wider than 32 bits are not supported. Such an encoding cannot be >>>> completed >>>> + * by calling this function again at @guest_addr + 4: the length >>>> check is >>>> + * applied to the first halfword read, which would then be a >>>> continuation of >>>> + * the instruction rather than its opcode. It is up to the caller to >>>> reject >>>> + * anything that is neither a 16- nor a 32-bit encoding. >>>> + */ >>>> +unsigned long riscv_read_guest(unsigned long guest_addr, bool >>>> read_insn, >>>> +                               struct trap_info *trap) >>> Nit: every other function in this file / declared in this header >>> (raw_copy_from_guest, copy_to_guest_phys, ...) has no riscv_ prefix. Why >>> does this one get it? >> >> Agree not to much sense. I will drop it. > > Probably we still want to have riscv_ prefix to show that this > read_guest() is specific to RISC-V but others (raw_copy_from_guest, > copy_to_guest_phys, ...) could be used in Xen common code too. > > So I think we could keep riscv_ prefix. Please may I suggest to avoid unnecessary prefixes? Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:50:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:50:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416813.1645737 (Exim 4.92) (envelope-from ) id 1x51eP-0001LT-VZ; Fri, 11 Sep 2026 13:50:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416813.1645737; Fri, 11 Sep 2026 13:50:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51eP-0001LM-T4; Fri, 11 Sep 2026 13:50:45 +0000 Received: by outflank-mailman (input) for mailman id 1416813; Fri, 11 Sep 2026 13:50:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x51eP-0001LG-Eo for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:50:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51eO-00EIT1-Rx for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:50:44 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40722-2eae-0a2a0a5409dd-0a2a450bb98a-34 for ; Fri, 11 Sep 2026 15:50:44 +0200 Received: from [209.85.208.52] (helo=mail-ed1-f52.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40734-b7e8-0a2a450b0019-d155d034cc91-3 for ; Fri, 11 Sep 2026 15:50:44 +0200 Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-6a9a20a5e72so1446129a12.0 for ; Fri, 11 Sep 2026 06:50:44 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2966022298sm79926366b.17.2026.09.11.06.50.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 06:50:43 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789134644; x=1789739444; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rIbWYzVATaArPOIUXCyeRp47IjnE+SLDm73PPY0JUXA=; b=hiddp9r9xzHDgOIa2/D7Br7PvvH4P5/AIMjdd34Yjq1gepGoRcLWibpzQgz+gPdRL+ Q41jD4FQy6kjAoRw5XoUecrFDkZcmeuqvhXdBRjSDDGo2tLLVxu0nNbYyLR/VlARlWIA vsR74waEHTr9pFTIRAmpoWcMLFLhUnrqHEEnuGDvx343v/OKVPaTO4X8ofQ2TGgHXOQj ygz8HQ93Q2gW4P931cvER63gmyeWB7A9UO3BCi7VTA2NPsOxbbosJaiQFBawKkzvMc+k Ck/JFbQn5mqNBfrwq7gvULrEmljG2aZ3HchMVxyCTFxydaOGPlYUAe/YkEj7sjNpTOjY 7d0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789134644; x=1789739444; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=rIbWYzVATaArPOIUXCyeRp47IjnE+SLDm73PPY0JUXA=; b=CoskOzEWU9SZ5ItHen+soxE+iFRNKFZINmMNVNICCBhepnjlZkf3+sbxyULQSDCoe6 nhuG6MR0Do692hserbLF4ibh36LcKOwy5ZoFCxzOMk4ZUeDYoLXfYoZIu9zQoO0/Wr4y 84Vi/fj6SZBojdIr04pJjHcrFM2sMxb3YDJwOimtMTNGvJfMSStSxtzXX86cWWT8mptI vH/GHRlFd885PDMrL7IvM1ip1e4vw9uUbFOICydnm7p4VWiLksSUfMEne8E7EGMc561s /+rIVtn5M3wi6Q1nAcoiSiAOMcHzjQpbW29ADw1QvrcdWVwBkPvo5gAhgRvvmm58Zucl oqvA== X-Gm-Message-State: AFuF++kLBbwdaFV7EiSx7f4S/Uz/N887Kb04zFU+JQZTAcUCXp85NoMt zW/x3k5I7AWQyK+KOXfxYvQqJ3niu105o1VMGW2aFUU5otfiiuyK4Vxf X-Gm-Gg: AYBFou3FlHwPsVbU7utTkDXeGNfyV22L/mJ74VvaeCnEhAGipt2Lmjaos4kk9iuDhZD NBcfpomObUNNnmhaPCtwzhWiahU3DtMtB23OTAxSz9iAr2GRqBdfPjwryUO5vAyv5jptw/cGjhR 021x0+dS65RpEHeUMhkywP1InWv3xKzQKAOWxS17Cm/yyEebEhgtL/Rg8HCYdiiL0ruHdO0p41g iBKIr84Bu5/hxgtiZg5I59PkC6s51/zfWXZ/pcIgbkq87K7qhwf+0VVR1XeFcYrmoC6Qz6xpCl3 77E8HqtghgU4g6UT6RyV0irablzpVyY2aiiej1MKCuUtwG5Q0FpfJEbDCi34ULhcAIVchi/w0ds OpKEn4wvpOh8ptP0zp6LKoSl49NfdF5Mt3g2Lfe7nj3fVQKo0/Eb6at5UbOxoQNHaJ3unnrKdmP j219imcqkeCa+g1iz98vVHPGFxvo9nVCmI7bqWTvd9pS3+450zKhjxlXE0NuB0rB4Krv6WNVdZf cMigKQsOC2lZgLYcwvyX5Z51cf0REpr7Q== X-Received: by 2002:a17:907:6093:b0:c29:52dd:317b with SMTP id a640c23a62f3a-c29666bd78fmr170235466b.29.1789134644228; Fri, 11 Sep 2026 06:50:44 -0700 (PDT) Message-ID: Date: Fri, 11 Sep 2026 15:50:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <1788955499.8631fc262581453bbf619ec5b2062170.1a0860e9b57000c4f3@vates.tech> <7b743afb-409d-433b-86b9-7ec8be7ad860@gmail.com> <1ce9effb-a632-4a48-aaaa-3c810ebd255d@gmail.com> <7a683895-d145-4640-b0c7-390408404a94@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <7a683895-d145-4640-b0c7-390408404a94@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789134644-1BCD79EA-27F24C2B/10/73395122804 X-purgate-type: spam X-purgate-size: 3592 On 9/11/26 3:47 PM, Jan Beulich wrote: > On 11.09.2026 15:41, Oleksii Kurochko wrote: >> On 9/11/26 3:06 PM, Oleksii Kurochko wrote: >>> On 9/9/26 2:04 PM, Baptiste Le Duc wrote: >>>>> Introduce riscv_read_guest() to allow Xen to safely read guest memory >>>>> using HLV/HLVX instructions while reliably capturing trap context. >>>> >>>>> This is required for instruction fetch emulation and MMIO decoding, >>>>> where >>>>> Xen must inspect guest memory that may not be directly accessible and >>>>> may >>>>> fault. >>>>> >>>>> The implementation is based on kvm_riscv_vcpu_unpriv_read() from Linux, >>>>> with one deviation: the hlv/hlvx instructions translate the guest >>>>> address >>>>> through the live vsatp/hgatp CSRs, i.e. through the address space of the >>>>> currently running vCPU, so the function can only be called safely for >>>>> current. Instead of taking a struct vcpu argument, it always operates on >>>>> current directly. >>>>> >>>>> Signed-off-by: Oleksii Kurochko >>>>> >>>>> diff --git a/xen/arch/riscv/guestcopy.c b/xen/arch/riscv/guestcopy.c >>>>> index 8a89212e0b..b2327822ac 100644 >>>>> --- a/xen/arch/riscv/guestcopy.c >>>>> +++ b/xen/arch/riscv/guestcopy.c >>>>> @@ -6,6 +6,7 @@ >>>>>   #include >>>>>   #include >>>>> +#include >>>>>   #define COPY_from_guest     0U >>>>>   #define COPY_to_guest       BIT(0, U) >>>>> @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain >>>>> *d, paddr_t gpa, void *buf, >>>>>       return copy_guest(buf, gpa, len, GPA_INFO(d), >>>>>                         COPY_to_guest | COPY_gpa); >>>>>   } >>>>> + >>>>> +/* >>>>> + * Read machine word from guest memory >>>>> + * >>>>> + * @guest_addr: Guest address to read >>>>> + * @read_insn: Flag representing whether we are reading instruction >>>>> + * @trap: Output pointer to trap details if something went wrong >>>>> during read >>>>> + * >>>>> + * The hlv/hlvx instructions translate guest_addr through the live >>>>> + * vsatp/hgatp CSRs, so the read is only meaningful for the address >>>>> + * space of the currently running vCPU. >>>>> + * >>>>> + * At most two halfwords are fetched when @read_insn is true, i.e. >>>>> encodings >>>>> + * wider than 32 bits are not supported. Such an encoding cannot be >>>>> completed >>>>> + * by calling this function again at @guest_addr + 4: the length >>>>> check is >>>>> + * applied to the first halfword read, which would then be a >>>>> continuation of >>>>> + * the instruction rather than its opcode. It is up to the caller to >>>>> reject >>>>> + * anything that is neither a 16- nor a 32-bit encoding. >>>>> + */ >>>>> +unsigned long riscv_read_guest(unsigned long guest_addr, bool >>>>> read_insn, >>>>> +                               struct trap_info *trap) >>>> Nit: every other function in this file / declared in this header >>>> (raw_copy_from_guest, copy_to_guest_phys, ...) has no riscv_ prefix. Why >>>> does this one get it? >>> >>> Agree not to much sense. I will drop it. >> >> Probably we still want to have riscv_ prefix to show that this >> read_guest() is specific to RISC-V but others (raw_copy_from_guest, >> copy_to_guest_phys, ...) could be used in Xen common code too. >> >> So I think we could keep riscv_ prefix. > > Please may I suggest to avoid unnecessary prefixes? Sure then I will drop it as originally suggested. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 13:57:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 13:57:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416823.1645747 (Exim 4.92) (envelope-from ) id 1x51kn-0001tV-Km; Fri, 11 Sep 2026 13:57:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416823.1645747; Fri, 11 Sep 2026 13:57:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51kn-0001tO-Hp; Fri, 11 Sep 2026 13:57:21 +0000 Received: by outflank-mailman (input) for mailman id 1416823; Fri, 11 Sep 2026 13:57:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x51km-0001tI-TF for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 13:57:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51km-005ywc-AF for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:57:20 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa408b6-e002-0a2a0a5209dd-0a2a4506d468-28 for ; Fri, 11 Sep 2026 15:57:20 +0200 Received: from [209.85.218.42] (helo=mail-ej1-f42.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa408c0-195a-0a2a45060019-d155da2ae851-3 for ; Fri, 11 Sep 2026 15:57:20 +0200 Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c2949ed8cc3so171583166b.2 for ; Fri, 11 Sep 2026 06:57:20 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2965c4e8a1sm82574266b.6.2026.09.11.06.57.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 06:57:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789135039; x=1789739839; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5R5D8b6GEhEM/RD6SEmaUMoO1v69d+lcdiaMdf3I9zc=; b=Vho4hyKC/N3fCTYWOm1fj2HoSDF8SR+mpllIqmyO3Ad/ioBn13jZEt6ahAg1QIA7/8 E3HmTXXNpZD9N4DEKvmlYY2N5PRBAekedyOEESLrrIbgvWTPBa/Kx2goAEqTw57MIH8V uyxEOEhbxfgNzXLhyFxb6atty0zCDnHrcmYi3Uel/yhTd8gt2SwinjLhemImuBTCYaLL M1Bu8ZmMOM0Ri9qDlAccafN91ElB1MGnp/Hg5kfB1hzD0/9zIRa7Y5Swk+klGMFKHI9t WuNBt7rOIqY55JJUHAvdbaUvI32nLQN/fWlQ8IiDNe9VCPPpqIAbyVibOVhbshE9ScVp HlEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135039; x=1789739839; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=5R5D8b6GEhEM/RD6SEmaUMoO1v69d+lcdiaMdf3I9zc=; b=Y2ZjQJu7xbn1rjZn00/t3WxhZcwBdZt7Fm9uO7P8+BRi1UfdusFXcPW0Uli3HS6WkD hk7Ayt6QAusia9iXF0chuZtvvaFnWaoJexG9AFZTI4itVfg1A1OETUkkQdr6lfgSsQJS kLYuMpnobIAn6Fd1NB3dOe9O22/bHaeaucLkkP2YPuPmeX8WHk20AH5b3aZiCTfOZ7MJ u2NUfAdgTD6n6VtpLfKsXbngWXjZOCs0lQkByJEJL72W+Dtsb3Jm2+UJrCK4gjp+j6oe fWK5Vi7vhssGcfHYNi+GmmsEeWpKXAeSTgCPHxSOPKN9xhKCOtXmjR6QC8WlB8KV2Y2h oiTg== X-Forwarded-Encrypted: i=1; AKwUvBxcWYLvrm4aY5t41vYbfJA2WQS+7kjZnO5VDk2EHc010Mt/tvjKZwZtlQ7UHLf9io2teK9HUioyXqg=@lists.xenproject.org X-Gm-Message-State: AFuF++mSed55JYwiesJSZo9JyVeCtUHP6MXQ8/n+fU9xM5tw3CR4Gx+s akv/gfIN20VdauCpxc6k4Y64HSvLk0y8iqz06vMWIuHjRXKXAJS4wm3w X-Gm-Gg: AYBFou3zIKq9qzB/5EXj7Oz70Czusy5TVXWabS1W12iOAolH1v6prz+Bw+6XP1xvPnO hu46+Q7QLZoK+tjibhTWOD3xdCMl12ZTi/6xaqekp/NdTf3YXX7Ni8L2Zs1uFEvNX/Pqea5h5Hb uRqUqcKD8Aua5SiwVMB2djeehpqIMY0zcOmjebze96wxvC8aSyx/TuS+3YYjOt5D6jRlSj1GoSc jkk9rTxKg1XZVtnyKdIitzxBZoDKQ6CU8Mjdb8n8jXsq1MorUW3m740Tsvx+1bLj7vm853Eya1e eUqJIYPi1gQtsebdUANScbyDgHAfLpApb12x+iXOCAoXv65ZTS20xei7wSjXpntxHF/C4q+a3mM BFWrPHhF9xYf6SkogC2BxfC78viwq1NoUWoIfxeNldpLdg3O0r31sV1KcNRUs3VbBtEFZWEsC4c ylETO/NZs2boshcDo3FOq02GiAnlNeex/r1BH7dgoun0maS2TEZ2PAaCd5UQaahnvGrGA0Z9my0 s1Df8GKXpbbpTO0yorIsFM5liB1PbAx X-Received: by 2002:a17:907:1992:b0:c29:4553:b27 with SMTP id a640c23a62f3a-c296673a4aamr204186166b.42.1789135038650; Fri, 11 Sep 2026 06:57:18 -0700 (PDT) Message-ID: <895ad4e5-37cd-4a1e-bc49-9a69ab00a920@gmail.com> Date: Fri, 11 Sep 2026 15:57:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789135040-F4A0477B-1A562056/10/73395122804 X-purgate-type: spam X-purgate-size: 4993 On 9/10/26 5:28 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/guestcopy.c >> +++ b/xen/arch/riscv/guestcopy.c >> @@ -6,6 +6,7 @@ >> #include >> >> #include >> +#include >> >> #define COPY_from_guest 0U >> #define COPY_to_guest BIT(0, U) >> @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, >> return copy_guest(buf, gpa, len, GPA_INFO(d), >> COPY_to_guest | COPY_gpa); >> } >> + >> +/* >> + * Read machine word from guest memory >> + * >> + * @guest_addr: Guest address to read >> + * @read_insn: Flag representing whether we are reading instruction >> + * @trap: Output pointer to trap details if something went wrong during read >> + * >> + * The hlv/hlvx instructions translate guest_addr through the live >> + * vsatp/hgatp CSRs, so the read is only meaningful for the address >> + * space of the currently running vCPU. >> + * >> + * At most two halfwords are fetched when @read_insn is true, i.e. encodings >> + * wider than 32 bits are not supported. Such an encoding cannot be completed >> + * by calling this function again at @guest_addr + 4: the length check is >> + * applied to the first halfword read, which would then be a continuation of >> + * the instruction rather than its opcode. It is up to the caller to reject >> + * anything that is neither a 16- nor a 32-bit encoding. >> + */ >> +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, >> + struct trap_info *trap) >> +{ >> + /* >> + * Poison the result: if the very first access faults, the fixup skips >> + * over the loads without writing it. Callers must check trap->scause. >> + */ >> + unsigned long val = ~0UL, tmp; >> + >> + /* >> + * hlv/hlvx use hstatus.SPVP for the privilege of the access, and the >> + * live vsatp/hgatp for the translation. Xen never installs a value of >> + * its own in hstatus (it is only saved on trap entry and restored >> + * before sret) and it doesn't reschedule before returning to the >> + * guest, so all three still belong to the vCPU which trapped. >> + * >> + * Check the saved copy rather than the live CSR: a nested trap taken >> + * from HS-mode clears hstatus.SPV in the CSR (but leaves SPVP alone). >> + */ >> + ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV); > > The first paragraph talks of just hstatus.SPVP. The second paragraph then > starting "Check ..." means that still refers to hstatus.SPVP, when - aiui - > hstatus.SPV is meant. > > Furthermore, instead of special casing nested faults here, but otherwise > saying "Xen doesn't modify", wouldn't it be better to word things such > that they remain correct if Xen ends up having a need to touch some other > part of hstatus (including, potentially, SPV)? IOW - I think it is natural > that the original guest value is checked. You are right: 1. The transition between the two paragraphs was confusing regarding SPVP vs SPV. I will update the comment to clearly distinguish that hlv/hlvx rely on SPVP, whereas the ASSERT verifies SPV. 2. Re-phrasing this around the invariant that vcpu_guest_cpu_user_regs represents the guest state at trap entry makes much more sense and is future-proof against any potential changes to live hstatus manipulation in Xen. 3. Regarding the value of the ASSERT: yes, for any valid guest trap frame SPV must be set. The ASSERT serves as a sanity check to ensure riscv_read_guest() is never accidentally invoked outside a valid guest vCPU trap context.I will update the comment as follows in v3: /* * hlv/hlvx instructions use the live hstatus.SPVP for access privilege, * and live vsatp/hgatp for translation. Since Xen does not reschedule * before returning to the guest, these CSRs still belong to current. * * Check SPV in the saved guest registers rather than the live CSR: * the saved copy reflects the guest virtualization mode (V=1) at the time * of trap entry, which remains invariant even if nested traps or HS-mode * execution modify the live CSR. */ ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV); > Question being of how much value > that checking is: vcpu_guest_cpu_user_regs(current)->hstatus can't possibly > have SPV clear, can it? Only nested exception frames could. Given that vcpu_guest_cpu_user_regs(current)->hstatus will always have SPV set for any valid guest trap frame, the ASSERT is purely a defensive sanity check to ensure riscv_read_guest() is never called outside a guest trap context. Would you prefer to keep this defensive ASSERT (with the updated comment), or drop it as redundant? Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:00:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:00:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416835.1645756 (Exim 4.92) (envelope-from ) id 1x51o4-0003qM-62; Fri, 11 Sep 2026 14:00:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416835.1645756; Fri, 11 Sep 2026 14:00:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51o4-0003qE-2s; Fri, 11 Sep 2026 14:00:44 +0000 Received: by outflank-mailman (input) for mailman id 1416835; Fri, 11 Sep 2026 14:00:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51o3-0003q8-2g for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:00:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51o2-005zVr-3N for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:00:42 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40981-e002-0a2a0a5209dd-0a2a4506d65c-40 for ; Fri, 11 Sep 2026 16:00:41 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40989-195a-0a2a45060019-d1558033d8fe-3 for ; Fri, 11 Sep 2026 16:00:41 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-49b0d78a801so9521435e9.2 for ; Fri, 11 Sep 2026 07:00:41 -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-49d26c300e2sm172036035e9.8.2026.09.11.07.00.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 07:00:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789135241; x=1789740041; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Dnq1/1GrB1zbFEE6TLR8yg37CtdjBNWT3gZ0MWETUvU=; b=L1fA9m16obNw2YQMHyKUzWIVsXYJHePZl1Dlbs2Jl8obptjznc2veGy9GQdx6p4S2l igEJeZnHIzZNwuOwQ+kQ2Oh8ejsWmodkB2RshalU3pjaTOLhGYHaoHRhv+blTebs9Ett 71BFrGjbHxM4p9bL1Uko9v5cfvQHUnr+UBwxudY0AUs8nhES+ovtOi1BX0XVokdw9g1P TBMMFoZY8668i6E1M6ZfhqqQIUxb3VcPhgZ5eaSinnJ4876M9VU6Jwo1MjQly2Fv7f5g hkuuvSiSmru3ixCNTimH0JnUTfHtbneDB7w+02Kc+s/DqR1kj+zvAH0UOBJEpCHGx33J 897Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135241; x=1789740041; h=content-transfer-encoding:content-type: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:content-type; bh=Dnq1/1GrB1zbFEE6TLR8yg37CtdjBNWT3gZ0MWETUvU=; b=cO81imSQUN+GHq5I2IV0NVhN0pusyanITECaliOB/9Y4AnW50RWdmUO7aE/XnvUSSM hyRJJWIlXFBObIP68aLZNMgnxL/ipGUKSOznFdNWr+/LN5F3NSq8h1CQGCyk2WZrgWpZ fGws4omZrEWblKGnF6s7WzMRw4EZLlPc9NOrpJ6ggHkUdanRDCttSzPdqV/gf7LQX8SY TefOxwvK9Yqi2Yzu1EutxeMb6+lpQ9a3RFSQhjfJwck//7+QUC7rzZP76ByvaM/vTgaj voLqtHvrtTyIUCoyEI7NFSC+pbut55308mTsVxwFuuhUaDdrinrakMx3JvbK1V8HxZoU 0pLw== X-Forwarded-Encrypted: i=1; AKwUvBwBv6UVg6Z74iIfXj6/ndPwPNzjfKN/4LilL0P4us3zenFHyoSomnMbvd0c06g0bia0kvtWtBFfpjg=@lists.xenproject.org X-Gm-Message-State: AFuF++l544KOsAv84bwSlOR2S0uhoAraZeimflmfTuGxCxkeapHcY/Nx ZC5ZSwCjODOU9U7xLZuDBrl7sv5JXLBDVkK6UEhjGVWdGF6oIleX1WKB84Sm8Cxn5w== X-Gm-Gg: AYBFou0sYDVQzUsprviXj5mYVMtkZAlK3lXBSq/qq1oTCVmyxl3K2uYhmB/mSEtPQJ4 DEKSxbluCBR59czZ4q+1q9SJ6dodWyAup0wlXVqQ/IB+z1LEQ+ny+UbBDLkYGpGIYKoVwAms6a9 Cw4Zw61sYP6EeWgr+dIxpLD611y8JqWHqeR0OPgmzsUE7d4P4liP9s6vdmVI2Uk//lANZOJOptE mrtD6XHhfOJo2SJLWfWBhIVGZ3aIp8zQjz5uXPycqhiysbZaS7x2b88bZy0n9AtzPKrdmUPO0QO NiiBXW6kiJJKodu12ZsAc3Un1pSQM1R9ZvpUPMLpHiHfbPZzIaaOjJ0iA/OfZ9+gnozEMXtlW8/ CS2bGB7k9J4mK+XAqBdJsglLpsWFAEovrzPZ/N43knNfWgqCXhCV/M6sHNNI+rzwqAarwz4u0gq zeTKpL4N0YAC4b6k7/YpemM4+FMAiLkwU4/H7EMmz2n4QF1p2Y27K+PZMzRzzlr5B1MGtTNXWRr REYW2uedFSI6mYpxLj9DK5OsYR140Zs4397mm6ThY9PX4Ayx/RKbToC6ResYgY= X-Received: by 2002:a05:600c:1c10:b0:49c:fc6c:be05 with SMTP id 5b1f17b1804b1-49e619f7187mr59497495e9.28.1789135241266; Fri, 11 Sep 2026 07:00:41 -0700 (PDT) Message-ID: <36c57293-1448-4283-ac85-5507d9cc637a@suse.com> Date: Fri, 11 Sep 2026 16:00:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <895ad4e5-37cd-4a1e-bc49-9a69ab00a920@gmail.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: <895ad4e5-37cd-4a1e-bc49-9a69ab00a920@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789135241-F520877B-77F8E77B/0/0 X-purgate-type: clean X-purgate-size: 3173 On 11.09.2026 15:57, Oleksii Kurochko wrote: > > > On 9/10/26 5:28 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, >>> return copy_guest(buf, gpa, len, GPA_INFO(d), >>> COPY_to_guest | COPY_gpa); >>> } >>> + >>> +/* >>> + * Read machine word from guest memory >>> + * >>> + * @guest_addr: Guest address to read >>> + * @read_insn: Flag representing whether we are reading instruction >>> + * @trap: Output pointer to trap details if something went wrong during read >>> + * >>> + * The hlv/hlvx instructions translate guest_addr through the live >>> + * vsatp/hgatp CSRs, so the read is only meaningful for the address >>> + * space of the currently running vCPU. >>> + * >>> + * At most two halfwords are fetched when @read_insn is true, i.e. encodings >>> + * wider than 32 bits are not supported. Such an encoding cannot be completed >>> + * by calling this function again at @guest_addr + 4: the length check is >>> + * applied to the first halfword read, which would then be a continuation of >>> + * the instruction rather than its opcode. It is up to the caller to reject >>> + * anything that is neither a 16- nor a 32-bit encoding. >>> + */ >>> +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, >>> + struct trap_info *trap) >>> +{ >>> + /* >>> + * Poison the result: if the very first access faults, the fixup skips >>> + * over the loads without writing it. Callers must check trap->scause. >>> + */ >>> + unsigned long val = ~0UL, tmp; >>> + >>> + /* >>> + * hlv/hlvx use hstatus.SPVP for the privilege of the access, and the >>> + * live vsatp/hgatp for the translation. Xen never installs a value of >>> + * its own in hstatus (it is only saved on trap entry and restored >>> + * before sret) and it doesn't reschedule before returning to the >>> + * guest, so all three still belong to the vCPU which trapped. >>> + * >>> + * Check the saved copy rather than the live CSR: a nested trap taken >>> + * from HS-mode clears hstatus.SPV in the CSR (but leaves SPVP alone). >>> + */ >>> + ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV); >>[...] >> Question being of how much value >> that checking is: vcpu_guest_cpu_user_regs(current)->hstatus can't possibly >> have SPV clear, can it? Only nested exception frames could. > > Given that vcpu_guest_cpu_user_regs(current)->hstatus will always have > SPV set for any valid guest trap frame, the ASSERT is purely a defensive > sanity check to ensure riscv_read_guest() is never called outside a > guest trap context. It is not, afaict: vcpu_guest_cpu_user_regs(current) will give you the guest frame no matter what context you're in. For what you want, you'd need to pass struct cpu_user_regs * into here. Jan > Would you prefer to keep this defensive ASSERT (with > the updated comment), or drop it as redundant? > > Thanks. > > ~ Oleksii > From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:09:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:09:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416853.1645765 (Exim 4.92) (envelope-from ) id 1x51wp-00057B-V7; Fri, 11 Sep 2026 14:09:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416853.1645765; Fri, 11 Sep 2026 14:09:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51wp-000574-SI; Fri, 11 Sep 2026 14:09:47 +0000 Received: by outflank-mailman (input) for mailman id 1416853; Fri, 11 Sep 2026 14:09:46 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51wo-00056x-Fv for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:09:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51wn-008feO-Mo for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:09:45 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40ba3-8faa-0a2a0a5109dd-0a2a4505898e-14 for ; Fri, 11 Sep 2026 16:09:45 +0200 Received: from [209.85.128.175] (helo=mail-yw1-f175.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40ba8-4cb1-0a2a45050019-d15580afdcbc-3 for ; Fri, 11 Sep 2026 16:09:45 +0200 Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-855c26cf490so5669817b3.0 for ; Fri, 11 Sep 2026 07:09:45 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939ecc38105sm175654485a.4.2026.09.11.07.09.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:09:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135784; x=1789740584; darn=lists.xenproject.org; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=HYwKQGYnNu1I2ntnnDPNcKeVNgWeStLdN/CP2LgAeVM=; b=YMbZcthMhEPDFz7GnZTWT73rNpznfhRNsNniL9Po7g/Z+t70OZizTf2R0i8cUXXMZJ ala+jZBMWaSwTK5lsfkpVRgt0dxO0vyIENec3Es293xbOf1orcv6eApeMQ7uhgyjzYxV DAzmhaA8qe+hiA+LqXnYmMk4LffdMfJCa5y/VoVAhJJlF3LKynN+ZCBNOLU9brkHh59Y yt3mMcn0GNefE/aUpFOoxQhx9/Mvf9vGatT2cMt6T0DwY7Jia1XGlrD6uB76xvyp96XS VMD00PJHYDuwiJdsB4bHWuFodAymO0fLc9J2wDF3+3rzwQLjvLDshT73/wkVBf0NpQ1s jwtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135784; x=1789740584; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=HYwKQGYnNu1I2ntnnDPNcKeVNgWeStLdN/CP2LgAeVM=; b=VN10vIgmoDiJI4TimDLwz8hpIWgDArQtrBHV14fTQMOIQUkmQTc3xLKfrqSZwtJFir 80wlGy4kBM6KlKYkTL3mK1+p8a8FrNKhlNLqUKPcxfbkh7ZiBO1VkV1sJ6bWwV3Vg1Oy bHgwBrxNfNDECzLURjpjE8KbNAP+w2BSCK03RRpeA9WZmXUC7bt+L59XM3FXyA//D7Ny 9AQF0/4276lRZxwoV6JfzMsnwghZhuBfnTQUMk9CGYf6JhckKy6/OHliKHfSBmRfEb/r WR3g89pHbJFSHBMVv5nGDINWUQ4aP4g82L667RwNuf4khSWmzYgqk6WXMpuv4OPYkfJr 7qyg== X-Forwarded-Encrypted: i=1; AKwUvBw+vuZt/8JUdL2F8S2X7TbvIXOlKnRg+LRZRG6ZZPBktDAR3QNbokmnd3NxRSokE+4Eq7pcJI6Zq+s=@lists.xenproject.org X-Gm-Message-State: AFuF++nHla9ehVkFTW9jks5m3JUdM0dFRT98TFcEOIOcOERc4JP0/1jf 6CqtbK0i7I61fEimxznG9DOd4PF8dLB52QMkOFHXD1HQX2p/Gyy4EDgEyas3kCvt4gE= X-Gm-Gg: AYBFou2k+I2zZLO7Me7WJYSTIIsmcnSjw8r0OKovq8y64Z6YVqvTLv9zf+Qs62v9I9Q PRHHxkPvo/AXf+HfbRYDz8NzCZYV8T8hbU7vQbpDEgwq7urJU2jKlRAY7Nmj9JVrUz+JjfKATqn sxw0Hrlqn1Fgtql1PiL8vI5nyNidsV08vGliRZvMVIRllUqtts67gbg7oq55k4U5vaq9V8HvIBH EsiOKOPPZfZlqr7orDXIQqfCTEWM0Jw+acoryWW9mvcflMngScMwZLZ/9iAyLPQvb2uyPybyPLi i4/GF1ZtlfjYnuvR1/aJgGQ5i0/MSEy5UP+b8bG8b4cOTN5PK3c5TDTGvpWhlZQ510JcOqoAL9Z p5eaTr2qxl5hYTyoq/qs76BhEFgoOi//XkSEv2SUjt2vfgCkSWXxYl5f9CJ/NOCiKqH8qjGd0c1 /XsluY9W92fR5yH7LZB6G2e+aIVr2sEzUhxJf94zd8MSlr32Wh470AWgQXF5jzOoJPv7mBE3gt+ lcedu4BSh/LGsSesn8YLrYkY7m0WlRcFyA0MM7UYtRVf+LicEfQrlH0 X-Received: by 2002:a05:690c:397:b0:869:1ab2:33aa with SMTP id 00721157ae682-884afd12eb1mr15658867b3.20.1789135783644; Fri, 11 Sep 2026 07:09:43 -0700 (PDT) From: Josef Bacik Subject: [PATCH RFC v2 00/15] rcu-tasks: let preemption outside trampolines be a quiescent state Date: Fri, 11 Sep 2026 14:08:38 +0000 Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAGgLpGoC/4WOzQ6CMBCEX8Xs2ZWWFAyeTEx8AK+GQ7sUqT+A3 UowhHcX8GricWZnvp0B2HpnGXarAbztHLumnkS8XgFVur5YdMWkIRZxKjIp0Cj09MKg+cbYems fbcAnoxKyLFWi0oS2MLWnU+n6hXyG0/EA+dfkl7laCjNzjhnNFo3XNVWzdW8jo6LF/PVlblSOQ +Pfy+JOLvi/4zqJAgul0qxURFLIfWh6R62uC72h5gH5OI4f1jKPpQwBAAA= X-Change-ID: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=9888; i=josef@toxicpanda.com; h=from:subject:message-id; bh=ciq/+qqHqSRSh7FRYtq3aWelW6Wh5G33c0OaJbqUUSk=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QAo5VaRxmnCLTA74sHK3/IXlJk4maBdHJ/o8BcYQaWxLTsL0V/6t0pY/lmq70yYasPVK7mviH+F JmwKt5LbXdQw= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c201ff/1789135785-716AD2A1-390F1705/0/0 X-purgate-type: clean X-purgate-size: 9890 v1: https://lore.kernel.org/all/20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com/ v1->v2: - Only walk the kprobe hash while the optimizer is actually waiting (Sashiko). - Re-check the kprobe jump window at every QS decision instead of once at preemption time (AI review). - Updated Documentation/RCU for the new rule (AI review). - Added 14/15 and 15/15 to address Paul's comments. - Added a comment in trace_recursion.h per Steve. - No change for the arm64 ftrace_static_tramp_end report, the Kconfig dependency already covers it (Sashiko). - Re-ran the x86-64 QEMU tests, still 0.2-0.3s and clean. --- Original email --- Tasks RCU only treats a voluntary context switch, usermode or idle as a quiescent state, because a preempted task may be sitting in a trampoline that is about to be freed. That was a fine trade when PREEMPT_NONE servers compiled Tasks RCU away and PREEMPT desktops rarely ran long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: Tasks RCU is now real on server configs, and cond_resched() is a no-op, so a CPU-bound kthread or kworker only ever loses the CPU by being preempted, which is exactly the event Tasks RCU refuses to count. The way this showed up for us was a cgroup writeback worker draining a very large cgwb for around eleven minutes on an arm64 box. Nothing wrong with that on its own, but a BPF program detach on another CPU went bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() while holding trampoline_mutex, forty-odd tasks piled up behind the mutex, and the hung task detector panicked the machine. The kprobe jump optimizer is worse in principle: it does synchronize_rcu_tasks() under kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running kthread can stall static key updates and CPU hotplug for its whole run. The current answer is to find each such loop and add cond_resched_tasks_rcu_qs() to it, which is the kind of annotation PREEMPT_LAZY was supposed to let us stop writing. This series tries the other direction: have the trampolines say when a task is inside them, so that a preemption anywhere else can be a quiescent state. - task_struct grows an int, rcu_tramp_nesting. Every trampoline whose lifetime Tasks RCU guards increments it before calling out and decrements it before returning: ftrace_caller and its dynamic copies, the BPF trampoline (which drops it again around the call to the original function, since im->pcref covers that), the x86 optprobe template, and out-of-line register_ftrace_direct() trampolines. Only current writes it and nested users are balanced, so it is a plain non-atomic inc/dec, one load of current plus one RMW per entry/exit. - The inc/dec are inside the trampoline, so there is a window of a few instructions on each side where the count is zero but the task is in (or on its way into) trampoline text. Nothing there can be preempted synchronously, only from an interrupt, so the irq-exit preemption path looks at regs->ip and holds the count across preempt_schedule_irq() when the IP is somewhere the counter cannot cover: outside core and module text (all the dynamically allocated trampolines and slots), in the static ftrace stubs or the x86 return thunks that still hold a direct-call target, in a module that hosts its own direct trampoline, or inside the bytes after a kprobe that the jump optimizer may be about to rewrite (the one synchronize_rcu_tasks() user that is not about trampolines at all). - With those in place, rcu_tasks_classic_qs() also clears the holdout flag on a preemption when the count is zero, on architectures that opt in. x86-64 and arm64 do so here. Everyone else keeps the voluntary-only rule and is untouched apart from the (unused) field. A running holdout already gets poked via rcu_request_urgent_qs_task(), which makes the next tick set NEED_RESCHED, so with this the resulting preemption retires it and a Tasks RCU grace period is bounded by roughly a tick plus the longest preempt-off section rather than by the longest stretch without a voluntary schedule(). Patches 1-12 are scaffolding and change no behaviour on their own; patch 13 flips the rule and selects the option for the two architectures. Testing so far is QEMU only: x86-64, PREEMPT_LAZY with PREEMPT_RCU=n, PROVE_RCU and lockdep, with and without PREEMPT_DYNAMIC. A kthread spinning in-kernel for 30s with the function tracer, an ftrace kprobe, an optimized kprobe and fentry/fexit programs attached: synchronize_rcu_tasks() goes from 29.7s to 0.1-0.3s, tearing down a DYNAMIC ftrace_ops (tracefs instance function -> nop) from 27s to 0.2-0.8s, and the ftrace-direct sample modules load, fire and unload in about 2.5s each while the spinner runs, with no warnings and the new return-to-user assertion quiet. arm64 is build-tested only at this point; real hardware numbers for both are the obvious next step and I did not want to sit on the idea waiting for them. Things I would particularly like opinions on: - Whether hooking rcu_tasks_classic_qs() is the right place, or whether Paul would rather see this expressed differently inside Tasks RCU. - return_to_handler and the rethook/kretprobe trampolines are not instrumented. Their C callees take the ftrace recursion lock before touching any ops and the trampolines themselves are static text, so I believe they do not need it, but I would like Steven and Masami to confirm. - The register_ftrace_direct() contract change: out-of-line direct trampolines now have to maintain the count themselves (the samples are converted). I do not know of out-of-tree users beyond BPF, but this is the one place an existing user could be silently weakened. - Whether arm64 folks are comfortable with the ldr/add/str in ftrace_caller and the BPF trampoline, and with treating all of ftrace_caller as trampoline text for the IP check. - If this holds up, cond_resched_tasks_rcu_qs() and rcu_softirq_qs_periodic() become unnecessary on the opted-in architectures; I have not touched them here. Based on v7.3-rc2+ (893e11787f78). --- Josef Bacik (15): rcu-tasks: Add per-task trampoline nesting count entry: Pass pt_regs to irqentry_exit_cond_resched() rcu-tasks: Hold trampoline nesting across irq-exit preemption in trampoline text kprobes: Let Tasks RCU recognise tasks preempted in an optprobe jump window ftrace: Mark modules hosting direct-call trampolines for Tasks RCU x86/ftrace: Maintain Tasks RCU trampoline nesting in ftrace_caller x86/kprobes: Maintain Tasks RCU trampoline nesting in the optprobe template bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline arm64: ftrace: Maintain Tasks RCU trampoline nesting in ftrace_caller bpf, arm64: Maintain Tasks RCU trampoline nesting in the BPF trampoline samples: ftrace: Maintain Tasks RCU trampoline nesting in direct-call trampolines rcutorture: Bracket Tasks RCU readers with trampoline nesting rcu-tasks: Treat preemption outside trampolines as a quiescent state rcu-tasks: Retire switched-out tasks with no trampoline nesting at scan time rcu-tasks: Kick running holdouts through the scheduler .../RCU/Design/Requirements/Requirements.rst | 28 +++- Documentation/RCU/checklist.rst | 8 +- arch/arm64/Kconfig | 1 + arch/arm64/kernel/asm-offsets.c | 3 + arch/arm64/kernel/entry-ftrace.S | 35 +++++ arch/arm64/kernel/ftrace.c | 16 +++ arch/arm64/net/bpf_jit_comp.c | 46 +++++++ arch/x86/Kconfig | 1 + arch/x86/kernel/asm-offsets.c | 3 + arch/x86/kernel/ftrace.c | 37 ++++++ arch/x86/kernel/ftrace_64.S | 43 +++++++ arch/x86/kernel/kprobes/opt.c | 20 +++ arch/x86/kernel/vmlinux.lds.S | 4 + arch/x86/net/bpf_jit_comp.c | 43 +++++++ arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 14 +- include/linux/kprobes.h | 8 +- include/linux/module.h | 7 + include/linux/rcupdate.h | 86 ++++++++++++- include/linux/sched.h | 2 + include/linux/trace_recursion.h | 11 ++ kernel/entry/common.c | 38 +++++- kernel/fork.c | 2 + kernel/kprobes.c | 46 +++++++ kernel/rcu/Kconfig | 17 ++- kernel/rcu/rcutorture.c | 6 + kernel/rcu/tasks.h | 141 ++++++++++++++++++++- kernel/rcu/update.c | 2 + kernel/trace/ftrace.c | 39 ++++++ samples/ftrace/ftrace-direct-modify.c | 9 ++ samples/ftrace/ftrace-direct-multi-modify.c | 9 ++ samples/ftrace/ftrace-direct-multi.c | 5 + samples/ftrace/ftrace-direct-too.c | 5 + samples/ftrace/ftrace-direct.c | 5 + samples/ftrace/ftrace-direct.h | 64 ++++++++++ 35 files changed, 776 insertions(+), 30 deletions(-) --- base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8 change-id: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 Best regards, -- Josef Bacik From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:09:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:09:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416854.1645774 (Exim 4.92) (envelope-from ) id 1x51wt-0005Jh-4l; Fri, 11 Sep 2026 14:09:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416854.1645774; Fri, 11 Sep 2026 14:09:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51wt-0005Ja-1z; Fri, 11 Sep 2026 14:09:51 +0000 Received: by outflank-mailman (input) for mailman id 1416854; Fri, 11 Sep 2026 14:09:49 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51wr-0005JU-Ed for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:09:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51wq-008feO-Rj for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:09:48 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40ba3-8faa-0a2a0a5109dd-0a2a4505898e-24 for ; Fri, 11 Sep 2026 16:09:48 +0200 Received: from [209.85.128.170] (helo=mail-yw1-f170.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bab-4cb1-0a2a45050019-d15580aacc87-3 for ; Fri, 11 Sep 2026 16:09:48 +0200 Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-836c8bde2dcso8056307b3.0 for ; Fri, 11 Sep 2026 07:09:48 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120ef650a6sm22355976d6.0.2026.09.11.07.09.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:09:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135787; x=1789740587; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=+LMR5vylWFXJjVBWLTvtKp/AcLzLdtKKT/apfY5nlpQ=; b=dk7uol5T3YTxr4y+210IUhr6PsWhsjyaIP9E3IDSVCSx0Wx79wdPvXs3wTBVY5bums 70jHoJ7dg4C4jc4H0PQwF5WX1CNxUZky89z5HeLrwGd0utYhxNsoqQj3pyiwOrAVrNSC +9xN8QmVwIrmDK3Zh9DNQlhoAXklNG+Tg1KzFKQB3bSpoAyqSb0Dcp6czqzc5usdVhvN sG3rN1MVTRZyZ0Mrw4EEWwLi9xLRYE4yrMer5Rz7Lzszh8PRlrOzVvEsOwptHhvTyGNB XG8ARsvQv4m+Zyy73E0EctN5k9xfJXh0+DC3tnzOQys+7sO4iUCNBwrqaPgVHV92j2yN 6+jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135787; x=1789740587; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+LMR5vylWFXJjVBWLTvtKp/AcLzLdtKKT/apfY5nlpQ=; b=JmlmaVvvZ/STlR34YLilwO7YNILGPl9yFWSxTa7powzFOMkIT95FfJve9nQ6hLiLYu +fD2SuyjnMYE9cwm7Gi5D0EFEDPU8uddMICL2dUIQoAD7xCS374zRS2MUA1dBVHLOH4Z 3DqtxPdM0Mf9ZaIpFe/2Mr+BX/uSi9djoxZ2bj7ySqV8Ihk5bGzCo7ObmJ6Ud2FafBvc lGKdzxCKIBedItDZjWU+k4CZGL/iiOa4TWfGtIPm44tb3Qo7OZqpo9tv+L9EVss1xrjH Yb5XvGzEeOywk2Pf7quhORfvcoYCaF0C9LsjSiLRtBQ7F2lGXoHyw70KZYdEi7sbAf0G 3uxA== X-Forwarded-Encrypted: i=1; AKwUvBwmlyKW4CxydxmhyghtiMgfzvXaqWBOHDgLZUR25LU39eef65vVej/Ck0/BjTQU/kEylnVMKoGlHgU=@lists.xenproject.org X-Gm-Message-State: AFuF++lCKfHv0VOYufeJWk0/jS5KyohRYuB51B4GMfoEJMox8Y0sYAkg ejyvmAVHE8IozccwP4CKNKdw4Pxz1xwc04xW4EyAEwooiA42xl2BfgqtrTzQWaAPxZg= X-Gm-Gg: AYBFou1EYvsR+hZG/M/W2d+cu1+dFuPg3ZDFiXspHE4hXrExkgndRZ+Txmqcl7w/8OW actKErk6/JFuXMomk74kXQp4mMxbFtycuQ6njiwaU4UApxvY+JqwRPSq6zvSphE9pwjXiLImuIt r6G53nAjXdRC4YeNAlFcqUNDuBGcpEWBrhg6rSSJSlrNdIxnVNuUoTK+6RS//ed+o5JhyTZlwAt YSEVUU0jW7DuEoWd0AH7eqwbincl9kvkzf849QGyICAWuSiy4GyzwlxE7T4AmMemMn1de1t0abz nYCnGnqUEVqQZZrun9sdqsDpSAOjYn/abVqI3dQnPLZyS60iQzGitYmRFhuEf74Rd9zNPGhmUGH pdUQE2TQT295a5sPEY+R9U0cncBGxpB3psMkZJlA2+bVGPe1B9OrKVmZBk1mGZ693zLF+ez3+Gm iDb3ydqL1jPxt8hX3us9G11zwho2nheC11jEmUN5x0Ra3qfAZZmBE4540dQ93LoIBsS/wYw6QpW 9Q4+New7Fn0uT/jhkIMleOuOoZks14r1uSzFdomXP1Cnxm8gW0Tq/xYt11a4OVyQwA= X-Received: by 2002:a53:ac84:0:b0:671:2bb8:ceb0 with SMTP id 956f58d0204a3-6712bb8d198mr592173d50.65.1789135786904; Fri, 11 Sep 2026 07:09:46 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:39 +0000 Subject: [PATCH RFC v2 01/15] rcu-tasks: Add per-task trampoline nesting count MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-1-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=7684; i=josef@toxicpanda.com; h=from:subject:message-id; bh=5hfL8mlrp+YP87pgAlSpHeSx0zMtfymEMHCNh6a40UA=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QPWvMx3TEehoRUZzyZvbL0GIDlx2yxh9C8YdBR0qgc4jATwF0zYzIPzSM+uo5u0rpazhBa063Yn SUZFFg50YiQg= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c201ff/1789135788-738BE2A1-27375FBD/0/0 X-purgate-type: clean X-purgate-size: 7686 Tasks RCU exists so that ftrace, BPF and kprobes can free trampoline text once no task can still be executing in it. Today the only way a task tells Tasks RCU "I am not in a trampoline" is a voluntary context switch, so a preempted task is always assumed to be inside one. Add task_struct::rcu_tramp_nesting so that trampolines can say so directly: a trampoline increments it before calling out and decrements it before returning, and while it is non-zero the task must not be treated as Tasks-RCU quiescent. Provide rcu_tasks_trampoline_enter() and rcu_tasks_trampoline_exit() for C users, report the count in the Tasks RCU stall output, and, under CONFIG_PROVE_RCU, assert that it is zero on every return to userspace since no task can legitimately reach userspace with a trampoline on its stack. Only current ever writes the count and every nested user (interrupts running their own trampolines) is balanced, so plain accesses suffice. The callbacks reached from static trampolines (return_to_handler, the rethook and kretprobe trampolines) are covered by the preempt_disable() in the ftrace recursion protection rather than by the count; note that dependency in trace_recursion.h so it is not lost if the preempt_disable() is ever removed from there. Nothing increments the count and nothing consults it for quiescent-state decisions yet; both come in later patches. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/irq-entry-common.h | 2 ++ include/linux/rcupdate.h | 37 +++++++++++++++++++++++++++++++++++++ include/linux/sched.h | 1 + include/linux/trace_recursion.h | 11 +++++++++++ kernel/fork.c | 1 + kernel/rcu/tasks.h | 3 ++- 6 files changed, 54 insertions(+), 1 deletion(-) diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index 0bb6c03481fa..8da571622000 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -214,6 +215,7 @@ static __always_inline void __exit_to_user_mode_validate(void) { /* Ensure that kernel state is sane for a return to userspace */ kmap_assert_nomap(); + rcu_tasks_trampoline_assert_none(); lockdep_assert_irqs_disabled(); lockdep_sys_exit(); } diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 44c07a66edff..b5c666c82479 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -180,6 +180,37 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } #ifdef CONFIG_TASKS_RCU_GENERIC # ifdef CONFIG_TASKS_RCU + +/* + * Trampoline nesting: dynamically allocated text (ftrace trampolines, BPF + * trampoline images, kprobe optinsn slots) that relies on Tasks RCU for its + * lifetime brackets itself with an increment/decrement of + * current->rcu_tramp_nesting. While the count is non-zero the task is inside, + * or was called from, such text and an involuntary context switch must not be + * treated as a Tasks RCU quiescent state. + * + * Only current writes the count and only current (or an interrupt on the same + * CPU) reads it, so plain accesses suffice. + */ +static __always_inline void rcu_tasks_trampoline_enter(void) +{ + current->rcu_tramp_nesting++; + barrier(); +} + +static __always_inline void rcu_tasks_trampoline_exit(void) +{ + barrier(); + current->rcu_tramp_nesting--; +} + +/* A task must never reach userspace with a trampoline on its stack. */ +static __always_inline void rcu_tasks_trampoline_assert_none(void) +{ + if (IS_ENABLED(CONFIG_PROVE_RCU)) + WARN_ON_ONCE(current->rcu_tramp_nesting); +} + # define rcu_tasks_classic_qs(t, preempt) \ do { \ if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ @@ -192,6 +223,9 @@ void rcu_tasks_torture_stats_print(char *tt, char *tf); # define rcu_tasks_classic_qs(t, preempt) do { } while (0) # define call_rcu_tasks call_rcu # define synchronize_rcu_tasks synchronize_rcu +static inline void rcu_tasks_trampoline_enter(void) { } +static inline void rcu_tasks_trampoline_exit(void) { } +static inline void rcu_tasks_trampoline_assert_none(void) { } # endif #define rcu_tasks_qs(t, preempt) rcu_tasks_classic_qs((t), (preempt)) @@ -208,6 +242,9 @@ void exit_tasks_rcu_finish(void); #define rcu_tasks_classic_qs(t, preempt) do { } while (0) #define rcu_tasks_qs(t, preempt) do { } while (0) #define rcu_note_voluntary_context_switch(t) do { } while (0) +static inline void rcu_tasks_trampoline_enter(void) { } +static inline void rcu_tasks_trampoline_exit(void) { } +static inline void rcu_tasks_trampoline_assert_none(void) { } #define call_rcu_tasks call_rcu #define synchronize_rcu_tasks synchronize_rcu static inline void exit_tasks_rcu_start(void) { } diff --git a/include/linux/sched.h b/include/linux/sched.h index 8b3d47a325cc..d2e7b1b3c9d2 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -956,6 +956,7 @@ struct task_struct { unsigned long rcu_tasks_nvcsw; u8 rcu_tasks_holdout; u8 rcu_tasks_idx; + int rcu_tramp_nesting; int rcu_tasks_idle_cpu; struct list_head rcu_tasks_holdout_list; int rcu_tasks_exit_cpu; diff --git a/include/linux/trace_recursion.h b/include/linux/trace_recursion.h index e6ca052b2a85..2da23a52ca4a 100644 --- a/include/linux/trace_recursion.h +++ b/include/linux/trace_recursion.h @@ -153,6 +153,17 @@ static __always_inline int trace_test_and_set_recursion(unsigned long ip, unsign current->trace_recursion = val; barrier(); + /* + * Callbacks reached from static trampoline text (return_to_handler, + * the rethook and kretprobe trampolines) do not maintain + * current->rcu_tramp_nesting themselves; they rely on this + * preempt_disable() to keep the task from being preempted, and thus + * from reporting a Tasks RCU quiescent state, while an ftrace_ops or + * its data is in use. If the preempt_disable() is ever removed from + * the recursion protection, this must rcu_tasks_trampoline_enter() + * here and rcu_tasks_trampoline_exit() in trace_clear_recursion() + * instead. See CONFIG_RCU_TASKS_PREEMPT_QS. + */ preempt_disable_notrace(); return bit; diff --git a/kernel/fork.c b/kernel/fork.c index 416758c8a3d4..cfe3a8e53fbd 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1869,6 +1869,7 @@ static inline void rcu_copy_process(struct task_struct *p) #endif /* #ifdef CONFIG_PREEMPT_RCU */ #ifdef CONFIG_TASKS_RCU p->rcu_tasks_holdout = false; + p->rcu_tramp_nesting = 0; INIT_LIST_HEAD(&p->rcu_tasks_holdout_list); p->rcu_tasks_idle_cpu = -1; INIT_LIST_HEAD(&p->rcu_tasks_exit_list); diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 627295396cd9..1662ba18bf34 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1113,10 +1113,11 @@ static void check_holdout_task(struct task_struct *t, *firstreport = false; } cpu = task_cpu(t); - pr_alert("%p: %c%c nvcsw: %lu/%lu holdout: %d idle_cpu: %d/%d\n", + pr_alert("%p: %c%c nvcsw: %lu/%lu holdout: %d tramp_nesting: %d idle_cpu: %d/%d\n", t, ".I"[is_idle_task(t)], "N."[cpu < 0 || !tick_nohz_full_cpu(cpu)], t->rcu_tasks_nvcsw, t->nvcsw, t->rcu_tasks_holdout, + data_race(t->rcu_tramp_nesting), data_race(t->rcu_tasks_idle_cpu), cpu); sched_show_task(t); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:09:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:09:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416855.1645783 (Exim 4.92) (envelope-from ) id 1x51ww-0005Wa-Ez; Fri, 11 Sep 2026 14:09:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416855.1645783; Fri, 11 Sep 2026 14:09:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51ww-0005WT-B2; Fri, 11 Sep 2026 14:09:54 +0000 Received: by outflank-mailman (input) for mailman id 1416855; Fri, 11 Sep 2026 14:09:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51wv-0005WB-9m for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:09:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51wu-009TbZ-HP for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:09:52 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bad-bab6-0a2a0a5309dd-0a2a4502afbc-20 for ; Fri, 11 Sep 2026 16:09:52 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40baf-6ca4-0a2a45020019-4a7de68c8e02-3 for ; Fri, 11 Sep 2026 16:09:52 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-90cdfbd148cso9161746d6.1 for ; Fri, 11 Sep 2026 07:09:52 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f478bf1sm21734556d6.25.2026.09.11.07.09.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:09:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135791; x=1789740591; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dxBJRgyuHY3W/iJApny4mLX1c4wnn/TYh39J8mu564M=; b=I9KwG09aoUS+hu71dRDVO81iZgY5dD1qArXVwta18hRKE+F5BdR3WqOc0bNMtJp4lo 4KTV5NQ4G4+jV2iIcw9/pwqr8YBtblTpwtOtzN+ZWhF+uVOp9k/wkR4TM3NnSNJuDk73 wtOCJPUrYDjBwI9dYrniNoR1X48Zv+SzHHzVP/9MhS9UDROrGKvzojQi9SuiSCoB5wAt rXqIjpIt93z9dLRiMVJhzL6mOxfjEQrJj2jv4ffNAPH2dC0bdx0LYro3KXGFRfLDAdpJ QKwItdDXf2HoTieSQ05SyzZPnRKkFH7lyO0yvJhzk7G9v1QgRZnRDmcyJJxGpfjXWVBx /2iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135791; x=1789740591; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=dxBJRgyuHY3W/iJApny4mLX1c4wnn/TYh39J8mu564M=; b=XSpVtNQJaM5x3ebQcgdHw85pVIcpQX+ggrfnQxj52RdRwimGIQhuwXE25fdHuhd+Y/ rkEnUg1ZOSIysnbymHf+lu7at628Fv406nk9qt4RnXqye1CWo99NQAoLRjPgcWLDBJDV MU4ewTFvkTJd7tRj7luv7t7A1mJRjzQUH8cN7soy8HkkfGHJOIZR33JZYekF57FP1wwH INLwqLZUwOlgoeGtxH/JDreDNOJcSbFZf1kHCDwMi+UvXx4bdeBy5NWXF22MZv7ONLoe GYT4VYvdRZskUNLX8EdNN/6QywToTr9MLsHlx5XRhJxFu+FTTEgsj1qfF6lRLbuaScd2 IU/Q== X-Forwarded-Encrypted: i=1; AKwUvBzykGfl8SbzWkNVda9oCSAeaYyo0S+e1eBM5fqfCYq6wdil97e6HThqF9eaTXcd3DCZ2k8/U6S0UJs=@lists.xenproject.org X-Gm-Message-State: AFuF++mFfFfnfXM6XWPrB9MQYgLSWXcRMR6/wi82HpErOKC7g5e9lULC RCMxbQzFmmWLOz/dK0UjHQ+0AW4Vj6dL9IUJdlXOjPhKkPHoOj591jP6+0Pz8JXtXms= X-Gm-Gg: AYBFou16v9FqXSe2Tqc3WvLwrvh92P0G+MFO6Hzz0MdBepD0bPwlNU+6mRmkG4mqF14 kU2vkB6j0EQLHlqUhrbO4KgQDqx2Dqn0a6bJrNqDiwz4PQeqmb/XNLIOXwGzTxX+f7H3mMr6ChJ ycenTqvDSdN4sGABs5Zx9vFm6FDyQ7GAOO8EAwPOIdlE0Ffi7bDvtDf+owa4ox4c8ADH3moLKUd n/b6DiEhwQKnPDdXJObVVMixzSkADOJAWvQfwMXfhX+58Lp5zxPoYAJnqF9tsouDPvekgdhZl3t FHbvmr6UqiqKcXqqob3PEmHbBw5FPW9xS04dVd6ZMn18xRxL4F0T0ztJzzCdm4af3CXPMH+20vT oX6JrAAAXFLkBFJ5dBxpNd4r0Q+NtqagQPs0fXxDW/0s7jnZT7ah9lomEk14XUw3awGJsBxkAdy WVMd9HnUA93fEtwQRno4CDytADlQ/n1H/IdRp1ji02JNqujCLympEtn74vkK8oaN5emRPx4JWwz 5yMoibvCDcBlePsT24ncc40jG0P3dbbamLqzRPVmmpsH88J7dduWINi X-Received: by 2002:a05:6214:5297:b0:912:bed:c40 with SMTP id 6a1803df08f44-91212116f69mr58502326d6.34.1789135790416; Fri, 11 Sep 2026 07:09:50 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:40 +0000 Subject: [PATCH RFC v2 02/15] entry: Pass pt_regs to irqentry_exit_cond_resched() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-2-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=4149; i=josef@toxicpanda.com; h=from:subject:message-id; bh=lYdFz9QIpBbv18s7vNFL415owdJ/HvkbTUnKX5a6LVk=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNLFUziLYUgokPYUCSvxyZJ4wGM33t0Exk3VASr1V813+Mcb6CwBQQCYTgKz4pDcXnm0a03w7j0 ZSuWxmEEtwQ4= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1789135792-31DC92AC-F39C4332/0/0 X-purgate-type: clean X-purgate-size: 4151 The irq-exit preemption path is about to need the interrupted context's registers to decide whether the preemption may be reported to Tasks RCU as a quiescent state. irqentry_exit_to_kernel_mode_preempt() already has them; hand them down through irqentry_exit_cond_resched(), its PREEMPT_DYNAMIC static-call and static-key variants, and raw_irqentry_exit_cond_resched(). The only caller outside the generic entry code is Xen PV's upcall handler, which has regs as well. No functional change. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 12 ++++++------ kernel/entry/common.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 2c64b388f616..3d85035f5624 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -739,7 +739,7 @@ __visible noinstr void xen_pv_evtchn_do_upcall(struct pt_regs *regs) inhcall = get_and_clear_inhcall(); if (inhcall && !WARN_ON_ONCE(state.exit_rcu)) { - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); instrumentation_end(); restore_inhcall(inhcall); } else { diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index 8da571622000..fc04725ae46b 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -348,21 +348,21 @@ typedef struct irqentry_state { * * Conditional reschedule with additional sanity checks. */ -void raw_irqentry_exit_cond_resched(void); +void raw_irqentry_exit_cond_resched(struct pt_regs *regs); #ifdef CONFIG_PREEMPT_DYNAMIC #if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL) #define irqentry_exit_cond_resched_dynamic_enabled raw_irqentry_exit_cond_resched #define irqentry_exit_cond_resched_dynamic_disabled NULL DECLARE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); -#define irqentry_exit_cond_resched() static_call(irqentry_exit_cond_resched)() +#define irqentry_exit_cond_resched(regs) static_call(irqentry_exit_cond_resched)(regs) #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void); -#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs); +#define irqentry_exit_cond_resched(regs) dynamic_irqentry_exit_cond_resched(regs) #endif #else /* CONFIG_PREEMPT_DYNAMIC */ -#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() +#define irqentry_exit_cond_resched(regs) raw_irqentry_exit_cond_resched(regs) #endif /* CONFIG_PREEMPT_DYNAMIC */ /** @@ -467,7 +467,7 @@ static inline void irqentry_exit_to_kernel_mode_preempt(struct pt_regs *regs, return; if (IS_ENABLED(CONFIG_PREEMPTION)) - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); } /** diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e3d381fd3d25..e4acd50bd81a 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -134,7 +134,7 @@ static inline bool arch_irqentry_exit_need_resched(void); static inline bool arch_irqentry_exit_need_resched(void) { return true; } #endif -void raw_irqentry_exit_cond_resched(void) +void raw_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!preempt_count()) { /* Sanity check RCU and thread stack */ @@ -150,11 +150,11 @@ void raw_irqentry_exit_cond_resched(void) DEFINE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void) +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) return; - raw_irqentry_exit_cond_resched(); + raw_irqentry_exit_cond_resched(regs); } #endif #endif -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:09:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:09:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416856.1645792 (Exim 4.92) (envelope-from ) id 1x51wy-0005jf-Md; Fri, 11 Sep 2026 14:09:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416856.1645792; Fri, 11 Sep 2026 14:09:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51wy-0005jY-J0; Fri, 11 Sep 2026 14:09:56 +0000 Received: by outflank-mailman (input) for mailman id 1416856; Fri, 11 Sep 2026 14:09:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51wx-0005he-Bp for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:09:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51ww-00E9V9-Oz for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:09:54 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40b97-2eae-0a2a0a5409dd-0a2a450bac0c-30 for ; Fri, 11 Sep 2026 16:09:54 +0200 Received: from [209.85.160.178] (helo=mail-qt1-f178.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bb1-b7e8-0a2a450b0019-d155a0b2c932-3 for ; Fri, 11 Sep 2026 16:09:54 +0200 Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-5218927884fso15772411cf.3 for ; Fri, 11 Sep 2026 07:09:54 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530ca50cd05sm20570811cf.29.2026.09.11.07.09.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:09:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135793; x=1789740593; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Vr/1/6kD89CuecwWXrcFDfjNkcZoJvv75czWOOFkQAs=; b=kVyTMRfXf7wDivyTuDFHix8y410Go95Qeg51c+AX3MnfvkkY67XHNgz6JLU11gfjgN wQyLDpEjKI1HAugLWm4hy61wyzWo6+Gix4YyB3I/rAb+6IdV3vArQMrUoZSWwdQdMkj0 bHsXPCj7+gtu7h3jku1mYZAy7K9y312ayhpwGTf3fiIZU+33NNPeACN1RIoQQ3T4fXk8 HeaoAJfSytexb0q29w1OOvAIx6XlkpQYw/TMkhi8JUbloH/mvf51lKXIDDHMyr8Wwn/z gtF8U2NTFpKThApkE+ou8dNxMER4TcifpnALQN8Xkwb/KGA0aKrmnF4x/716vePMfzpF lA8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135793; x=1789740593; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Vr/1/6kD89CuecwWXrcFDfjNkcZoJvv75czWOOFkQAs=; b=aPMDRb8l99PXZ2lejYyyjz+WfA0LqkdCX4BtTXmKf/UvulSH2NwTHJIx68qtOf0TVP KAQmY6S7V8VHkUt5Nv2aLqG8By99mpPMsEdTphB8eI2aOguSbj+sFWVY2YHxUittea2O ebPPM4s+4h0Cpwv/+uD7LOLaCa+bH5j6ApY62JXV3IxI9BFmXgeBEMk4WHYbjJU3Fjdp OP3WJChKXlrDKKRYqoigFZhIjb7eRTEkbVpiTqmmDHbP7m+x9hvnd03PS9ws2Jt/6iHY WRkLyHQ9JJ/Ew7V/OyOUzwTOryH+frV272GINI+WLqZKndbWnHKeBuLYGcsmCmO8Ro64 jXhg== X-Forwarded-Encrypted: i=1; AKwUvByS7FOFs8iYgb83Hu1dSf0udJ2piFkLPf4cULguS7+GhoC2/VaNUvmVp7bCcfBCLBdLsSLKFAH9u/o=@lists.xenproject.org X-Gm-Message-State: AFuF++kWmTkN4yeHuWBMZuHPy7qV0ujP1lS2Z61N34rb9aVtn6Xo+/rJ fejW6jpD2eia/A2oBU2gRDgfvIl9k2BgtGW43e4Ea+btAm2ZfUYG2ZcFU1W/8kUrPrI= X-Gm-Gg: AYBFou0L4xVRysNwCwNIV1VB6TUqp4WRry6x+CdZknZmHb48my5v4yDD7lJPMilojWa IJKimIIiIWpf29NjxI6TA74FPwhg7CLnbwdWxzc1a70v71a50Z6pTre+kNHY18CVr80fXV5XxVh FnHnPdr+HscODCSgeN60vqjevwop/cMgqiviuznGDzkxRM6zLFsCi1ChOzk660K0UoirX9h2crt qL8M0kgO3fBsWEZgJS6Jus49F4Go9yF3iUAsWsq2KOqKNXTXrB9WZE0tO6HpTuBdKLY0r5DEXiH o83o5UlKlmUE+/cfVcYpk7n7fZsq+EqLrlFe3qW1U8j++CtKgxo31eOC5e9i9NEBZ7CcXDgUI/g tpKmViiS6PCK0QFX+Xowo7RdsP9pAUPKz+rG8WGaqhQ0oqR0XYPe8KX/3CaHhVmd2caicDN1pg6 i+MZGAvABAUn1JHuK80n2nY4kp/lkVA1RH8O921r+gghFjuskUk+2lhhODrvT/wOuSVa8sF7k8F Qn9d2HkIj+/ZxgyWCfzjrCAWS1FQOjxny5Al43P7WeimH8ji2nYF6Qc X-Received: by 2002:a05:622a:393:b0:530:a441:c52d with SMTP id d75a77b69052e-530c876307fmr64046411cf.46.1789135792869; Fri, 11 Sep 2026 07:09:52 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:41 +0000 Subject: [PATCH RFC v2 03/15] rcu-tasks: Hold trampoline nesting across irq-exit preemption in trampoline text MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-3-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=9197; i=josef@toxicpanda.com; h=from:subject:message-id; bh=CNudSyp9EGSFLIPrtB5sqvKMksuv/pGd9p7EfdyuASs=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QDP3NG/b7q989dUqjalqec1jdmkHZIx2wGCVq3J1Gir+zOd7a4FhOwI8Us9/xLubjdPD5eVSQFN Ltn5AyJDBWwY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1789135794-182F49EA-ECC8F3A6/0/0 X-purgate-type: clean X-purgate-size: 9199 A trampoline's own rcu_tramp_nesting increment and decrement live inside the trampoline, so there is a window of a few instructions on entry and exit where the count is zero while the CPU is executing trampoline text (or text on the way into one, such as a static ftrace stub holding a direct-call target). In that window the task has not called out, so it can only be preempted from an interrupt, and the interrupted instruction pointer identifies where it is. Add rcu_tasks_ip_in_trampoline(), which treats any IP outside core kernel and module text as potentially Tasks-RCU-protected (ftrace trampolines, BPF images and programs, kprobe slots are all dynamically allocated text; is_ftrace_trampoline() and friends are deliberately not used because text being torn down may already be unregistered from them while a task still stands on it), plus a __weak arch_rcu_tasks_ip_in_trampoline() for core text an architecture needs to flag. On irq-exit preemption, if the IP matches, hold the count elevated across preempt_schedule_irq(). Introduce ARCH_HAS_RCU_TASKS_PREEMPT_QS / RCU_TASKS_PREEMPT_QS to gate this; no architecture selects it yet, so the check compiles away and there is no functional change. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/rcupdate.h | 17 +++++++++++++++++ kernel/entry/common.c | 23 ++++++++++++++++++++++- kernel/rcu/Kconfig | 10 ++++++++++ kernel/rcu/tasks.h | 38 ++++++++++++++++++++++++++++++++++++++ kernel/rcu/update.c | 2 ++ 5 files changed, 89 insertions(+), 1 deletion(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index b5c666c82479..0a408e36ea15 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -173,6 +173,9 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } #endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */ +/* Arch hook for rcu_tasks_ip_in_trampoline(); see kernel/rcu/tasks.h. */ +bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip); + /* * Note a quasi-voluntary context switch for RCU-tasks's benefit. * This is a macro rather than an inline function to avoid #include hell. @@ -189,6 +192,16 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } * or was called from, such text and an involuntary context switch must not be * treated as a Tasks RCU quiescent state. * + * The increment and decrement themselves live inside the trampoline, so there + * is a window of a few instructions at entry (before the increment) and exit + * (after the decrement) where the count is zero but the CPU is executing + * trampoline text, or text on the way into one (a static ftrace stub or a + * return thunk holding the trampoline's address). In that window the task + * cannot be preempted synchronously, only from an interrupt, so the irq-exit + * preemption path covers it by checking regs->ip with + * rcu_tasks_ip_in_trampoline() and holding the count elevated across + * preempt_schedule_irq() when it matches. + * * Only current writes the count and only current (or an interrupt on the same * CPU) reads it, so plain accesses suffice. */ @@ -211,6 +224,8 @@ static __always_inline void rcu_tasks_trampoline_assert_none(void) WARN_ON_ONCE(current->rcu_tramp_nesting); } +bool rcu_tasks_ip_in_trampoline(unsigned long ip); + # define rcu_tasks_classic_qs(t, preempt) \ do { \ if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ @@ -226,6 +241,7 @@ void rcu_tasks_torture_stats_print(char *tt, char *tf); static inline void rcu_tasks_trampoline_enter(void) { } static inline void rcu_tasks_trampoline_exit(void) { } static inline void rcu_tasks_trampoline_assert_none(void) { } +static inline bool rcu_tasks_ip_in_trampoline(unsigned long ip) { return false; } # endif #define rcu_tasks_qs(t, preempt) rcu_tasks_classic_qs((t), (preempt)) @@ -245,6 +261,7 @@ void exit_tasks_rcu_finish(void); static inline void rcu_tasks_trampoline_enter(void) { } static inline void rcu_tasks_trampoline_exit(void) { } static inline void rcu_tasks_trampoline_assert_none(void) { } +static inline bool rcu_tasks_ip_in_trampoline(unsigned long ip) { return false; } #define call_rcu_tasks call_rcu #define synchronize_rcu_tasks synchronize_rcu static inline void exit_tasks_rcu_start(void) { } diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e4acd50bd81a..cd3feaca6420 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -134,6 +134,27 @@ static inline bool arch_irqentry_exit_need_resched(void); static inline bool arch_irqentry_exit_need_resched(void) { return true; } #endif +/* + * Preempt the interrupted kernel context. If the interrupt landed in text + * that may be a Tasks-RCU-protected trampoline (see + * rcu_tasks_trampoline_enter()), hold current->rcu_tramp_nesting elevated + * across the context switch so that it is not mistaken for a Tasks RCU + * quiescent state. This closes the few-instruction windows at trampoline + * entry/exit where the trampoline's own increment has not yet run or its + * decrement already has. + */ +static void irqentry_preempt(struct pt_regs *regs) +{ + bool in_tramp = IS_ENABLED(CONFIG_RCU_TASKS_PREEMPT_QS) && + rcu_tasks_ip_in_trampoline(instruction_pointer(regs)); + + if (in_tramp) + rcu_tasks_trampoline_enter(); + preempt_schedule_irq(); + if (in_tramp) + rcu_tasks_trampoline_exit(); +} + void raw_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!preempt_count()) { @@ -142,7 +163,7 @@ void raw_irqentry_exit_cond_resched(struct pt_regs *regs) if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) WARN_ON_ONCE(!on_thread_stack()); if (need_resched() && arch_irqentry_exit_need_resched()) - preempt_schedule_irq(); + irqentry_preempt(regs); } } #ifdef CONFIG_PREEMPT_DYNAMIC diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index 332df7a7a634..999f8228a13d 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -107,6 +107,16 @@ config TASKS_RCU default NEED_TASKS_RCU && PREEMPTION select IRQ_WORK +# Selected by architectures whose ftrace, BPF and kprobe trampolines maintain +# current->rcu_tramp_nesting and which use the generic irqentry code, so that +# a preemption outside any trampoline can be treated as a Tasks RCU +# quiescent state. See rcu_tasks_trampoline_enter(). +config ARCH_HAS_RCU_TASKS_PREEMPT_QS + bool + +config RCU_TASKS_PREEMPT_QS + def_bool TASKS_RCU && ARCH_HAS_RCU_TASKS_PREEMPT_QS && GENERIC_IRQ_ENTRY + config FORCE_TASKS_RUDE_RCU bool "Force selection of Tasks Rude RCU" depends on RCU_EXPERT diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 1662ba18bf34..a801ec4a951b 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1089,6 +1089,44 @@ static void rcu_tasks_postscan(struct list_head *hop) timer_delete_sync(&tasks_rcu_exit_stall_timer); } +/* + * Architectures selecting ARCH_HAS_RCU_TASKS_PREEMPT_QS override this to flag + * core kernel text that must be treated like a trampoline, e.g. static ftrace + * entry stubs and return thunks that run with a trampoline address in hand. + */ +bool __weak arch_rcu_tasks_ip_in_trampoline(unsigned long ip) +{ + return false; +} + +/** + * rcu_tasks_ip_in_trampoline - Could a task interrupted at @ip be a Tasks RCU reader? + * @ip: interrupted instruction pointer + * + * Called from the irq-exit preemption path with interrupts disabled, to decide + * whether the imminent preemption may be reported as a Tasks RCU quiescent + * state when current->rcu_tramp_nesting is zero. Returns true, meaning "do + * not report", when @ip is: + * + * - outside static kernel and module text, i.e. possibly in an ftrace + * trampoline, BPF trampoline image or program, kprobe insn/optinsn slot or + * other dynamically allocated text whose lifetime Tasks RCU guards. This + * deliberately does not consult is_ftrace_trampoline() and friends: text + * being torn down may already be unregistered there while a task still + * stands on it; + * - in core text the architecture flags via arch_rcu_tasks_ip_in_trampoline(). + * + * A false positive only defers the quiescent state to the task's next + * context switch. + */ +bool rcu_tasks_ip_in_trampoline(unsigned long ip) +{ + if (core_kernel_text(ip)) + return arch_rcu_tasks_ip_in_trampoline(ip); + return !is_module_text_address(ip); +} +NOKPROBE_SYMBOL(rcu_tasks_ip_in_trampoline); + /* See if tasks are still holding out, complain if so. */ static void check_holdout_task(struct task_struct *t, bool needreport, bool *firstreport) diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index b62735a67884..23be7e97c3b5 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -41,6 +41,8 @@ #include #include #include +#include +#include #include #include #include -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:09:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:09:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416857.1645801 (Exim 4.92) (envelope-from ) id 1x51x0-0005ws-TH; Fri, 11 Sep 2026 14:09:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416857.1645801; Fri, 11 Sep 2026 14:09:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51x0-0005wl-Pl; Fri, 11 Sep 2026 14:09:58 +0000 Received: by outflank-mailman (input) for mailman id 1416857; Fri, 11 Sep 2026 14:09:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51wz-0005wJ-Q3 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:09:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51wz-009TfM-74 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:09:57 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40b98-bab6-0a2a0a5309dd-0a2a4509a768-46 for ; Fri, 11 Sep 2026 16:09:57 +0200 Received: from [209.85.128.179] (helo=mail-yw1-f179.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bb4-be1a-0a2a45090019-d15580b3d16e-3 for ; Fri, 11 Sep 2026 16:09:57 +0200 Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-8664769db58so7635247b3.3 for ; Fri, 11 Sep 2026 07:09:56 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f4d0700sm22061896d6.38.2026.09.11.07.09.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:09:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135795; x=1789740595; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=5run1FbtWhLPrIbIpcsdoDpDcAIfw1LixKxJKXXjMZI=; b=jc1RD6ctevXEPgn+sQIvLqY7WwEgJkddRw6MasTL4Xn9a5+TFC16wWwWMTnuyTrxOo gh4aCNpDC10bh0OWzBsA3aaO6iuSllQncokB6ZlhBYSg/TV/n3sk62NPPI0K+0RRwJ3t a+7XBZFHNz2hebuHzIS6jY7MuzS20+H7uE1TPmaW1TTj8h6MyTL6NKd4t63FLksP/4DS PrAVafVIWZxf41WWC37cs9UaZUbJTNYcYRrnKdI7GI4kafjAdzmaxe2EzANM7M+fUzlM fz4Hs258ubG5K8GtRLrB94G5bF7j98DcyohhTmhQeFGc5ZTOSPFIB5zr3fq3EymfT5Cg qs/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135795; x=1789740595; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5run1FbtWhLPrIbIpcsdoDpDcAIfw1LixKxJKXXjMZI=; b=Qb8PPgpBCePXjJ39MoCoHPNUm8DM+5dTe21DwO/KoEMH6LzV1j1xeUkgCY/DbMIqnx kWAk2KXf9gXg2eysWeenhw8DA/VOHxJQqrJ1qbMI+82k6jyZx5lRa4i1kcBb0QbqL8cZ ap1fcCV7oOYvMHjuRwu1UjBDW5ZFMGK4Tf4Hlu3ANkgco4m9WD23f1PtnHkiWAGpWFae WmIFZAIXXktjiNJOAc4sNT3p+K+w6C80NAIV78JU5Uf4FpWaHl4/ctgVSuSbY4wVW4zl A+LxhpPwXjnw4MHdjuznq4rYZWzac4mnCKm7iMCQOH34KcE7T7Xj4qTZR4Zvk8vzfJyK jLNQ== X-Forwarded-Encrypted: i=1; AKwUvBzAHPG39eyYt2GYBdHHVC8NgoSk2iZnhyOcjIeW9YtZIyefNseZ7aFCtDHqaavJmLckLwRTS0GIPrg=@lists.xenproject.org X-Gm-Message-State: AFuF++kZS4YupNoVo5gY8ICfgO55+2Oc6mqhDDpO4vHu35Aj3FyioLh5 oCEa16gZj7hZ42hlhICAJuQftwyWNn9wZ1PBC1wkywRC/ZgNyrizvWg/wFYbcayul0k= X-Gm-Gg: AYBFou13e50IkhAYgclDyCIpfBoiYyf5ZJhndj7mirPnAq01sXkw4USzuD8R8XiJSWd bMsFB8Xr/53UmfTDM3by1cDW7+4JnjV0kJWkpB5hy5BcTCAk5WCPphgDqezqNxCjmAifS8L9ta5 Zv8dtUdq3tH79hIwjrz51VeE6xJX+cXwrpNw4NL7l+yhntNd5WMFRHIxMwyG3gKNDWHMkHrGrzo Hi7WuV7LflmwNiMD21PnGO58PXx51x/72zliZnSsqPSzlP7PMNvrar0O3MN9VQp865/WbmNwWj+ /n8K9SG2Wzx53csnnzmec/BDsCkU7ZBDeMOuWvGN14vO3ggOp+B/qaMCCu1xTJ8haiNFB8bkGj3 bMRdvD3kFN23eix/r6IueoF2S9ahY/RV3v5H/cc3HuHzNfU+/B/K/ZmtjGyc+5/1QJbQ7viV4lM CBRUipdafQyB1t4idoSlqUtWzNXPpjhx2qwG3V7f+pIXmjjWXML6WoKnEcZGLZNwLxHzbeEutJU auwv6ViM/sEwWkcGuIGcRhZsPZsqYCaXlyduzWUJfH8O/f65OvyrMBA X-Received: by 2002:a05:690c:10c:b0:873:5c0f:27f with SMTP id 00721157ae682-884b183fa8fmr15728927b3.41.1789135795285; Fri, 11 Sep 2026 07:09:55 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:42 +0000 Subject: [PATCH RFC v2 04/15] kprobes: Let Tasks RCU recognise tasks preempted in an optprobe jump window MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-4-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=12385; i=josef@toxicpanda.com; h=from:subject:message-id; bh=zaxzL0DRdr6YBFEcTSGtZpzKzuVZf+tDLqNK8lLQ3vQ=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QDkHo+7Zxxr001o9pThi3R9UNNh0hJGGQszxQdwGKWyIfzZokuP81SU5bPZjsOb84RB2Rvd/rcr ztRWEWANpTgE= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1789135797-BF4D3034-B7F0E660/0/0 X-purgate-type: clean X-purgate-size: 12387 kprobe_optimizer() is the one synchronize_rcu_tasks() user that is not about trampoline text: it waits for tasks that were preempted on an instruction boundary inside the bytes it is about to overwrite with the optimized jump, so that none of them resumes into the middle of the new instruction. Such a task sits in ordinary kernel or module text with rcu_tramp_nesting == 0, and can only have got there via an irq-exit preemption. Add kprobe_in_optimized_region(), a lockless and conservative form of get_optimized_kprobe() that reports whether any registered kprobe lies within MAX_OPTIMIZED_LENGTH before the given address regardless of its optimization state. The hash walk is only done while kprobe_optimizer() is actually inside its synchronize_rcu_tasks(), tracked by a flag it sets around the call; otherwise the check is a single load. The kprobe hash is RCU-protected and every free path waits for a grace period after unhashing, so the lockless walk is safe from any context with preemption disabled. Unlike trampoline text, which a task can only be interrupted in while the trampoline exists, these bytes are ordinary text a task may have been parked in since before the kprobe was registered, and the optimizer may start waiting while that task is already switched out. So the check cannot be made once at preemption time the way the trampoline cases are: have irqentry_preempt() record the interrupted IP in current->rcu_tasks_irq_ip for the duration of the preemption, and add rcu_tasks_irq_ip_holds() to test it, to be evaluated at every quiescent-state decision once preemption becomes a quiescent state -- each pass through __schedule() in preempt_schedule_irq()'s loop as well as any remote check. A task switched out synchronously cannot have a resume point inside such a window (a call there returns beyond it), so only the irq-exit IP needs checking, and preempt_schedule_irq() cannot nest, so one slot per task suffices. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/kprobes.h | 8 +++++++- include/linux/rcupdate.h | 17 +++++++++++++++++ include/linux/sched.h | 1 + kernel/entry/common.c | 13 +++++++++++-- kernel/fork.c | 1 + kernel/kprobes.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ kernel/rcu/tasks.h | 23 +++++++++++++++++++++++ 7 files changed, 106 insertions(+), 3 deletions(-) diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h index e6de7ae55bda..74cc48c04417 100644 --- a/include/linux/kprobes.h +++ b/include/linux/kprobes.h @@ -530,11 +530,17 @@ static inline bool is_kprobe_insn_slot(unsigned long addr) } #endif /* !CONFIG_KPROBES */ -#ifndef CONFIG_OPTPROBES +#ifdef CONFIG_OPTPROBES +bool kprobe_in_optimized_region(unsigned long addr); +#else /* !CONFIG_OPTPROBES */ static inline bool is_kprobe_optinsn_slot(unsigned long addr) { return false; } +static inline bool kprobe_in_optimized_region(unsigned long addr) +{ + return false; +} #endif /* !CONFIG_OPTPROBES */ #ifdef CONFIG_KRETPROBES diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 0a408e36ea15..4cfe096d624f 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -202,6 +202,14 @@ bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip); * rcu_tasks_ip_in_trampoline() and holding the count elevated across * preempt_schedule_irq() when it matches. * + * The one non-trampoline user, kprobe jump optimization, waits for tasks + * preempted inside ordinary instruction bytes it is about to overwrite. A + * task can be parked there from before the kprobe even existed, so that + * cannot be decided once at preemption time: irqentry_preempt() records the + * interrupted IP in current->rcu_tasks_irq_ip for the duration of the + * preemption and rcu_tasks_irq_ip_holds() checks it at every quiescent-state + * decision, locally and from the grace-period kthread. + * * Only current writes the count and only current (or an interrupt on the same * CPU) reads it, so plain accesses suffice. */ @@ -225,6 +233,13 @@ static __always_inline void rcu_tasks_trampoline_assert_none(void) } bool rcu_tasks_ip_in_trampoline(unsigned long ip); +bool rcu_tasks_irq_ip_holds(struct task_struct *t); + +/* Record where current is being irq-preempted; 0 once it has resumed. */ +static __always_inline void rcu_tasks_note_irq_ip(unsigned long ip) +{ + WRITE_ONCE(current->rcu_tasks_irq_ip, ip); +} # define rcu_tasks_classic_qs(t, preempt) \ do { \ @@ -242,6 +257,7 @@ static inline void rcu_tasks_trampoline_enter(void) { } static inline void rcu_tasks_trampoline_exit(void) { } static inline void rcu_tasks_trampoline_assert_none(void) { } static inline bool rcu_tasks_ip_in_trampoline(unsigned long ip) { return false; } +static inline void rcu_tasks_note_irq_ip(unsigned long ip) { } # endif #define rcu_tasks_qs(t, preempt) rcu_tasks_classic_qs((t), (preempt)) @@ -262,6 +278,7 @@ static inline void rcu_tasks_trampoline_enter(void) { } static inline void rcu_tasks_trampoline_exit(void) { } static inline void rcu_tasks_trampoline_assert_none(void) { } static inline bool rcu_tasks_ip_in_trampoline(unsigned long ip) { return false; } +static inline void rcu_tasks_note_irq_ip(unsigned long ip) { } #define call_rcu_tasks call_rcu #define synchronize_rcu_tasks synchronize_rcu static inline void exit_tasks_rcu_start(void) { } diff --git a/include/linux/sched.h b/include/linux/sched.h index d2e7b1b3c9d2..7f0bdc81fba3 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -957,6 +957,7 @@ struct task_struct { u8 rcu_tasks_holdout; u8 rcu_tasks_idx; int rcu_tramp_nesting; + unsigned long rcu_tasks_irq_ip; int rcu_tasks_idle_cpu; struct list_head rcu_tasks_holdout_list; int rcu_tasks_exit_cpu; diff --git a/kernel/entry/common.c b/kernel/entry/common.c index cd3feaca6420..b372f2670d4f 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -141,16 +141,25 @@ static inline bool arch_irqentry_exit_need_resched(void) { return true; } * across the context switch so that it is not mistaken for a Tasks RCU * quiescent state. This closes the few-instruction windows at trampoline * entry/exit where the trampoline's own increment has not yet run or its - * decrement already has. + * decrement already has. The interrupted IP is also recorded for the + * duration, for conditions that must be re-evaluated at each quiescent-state + * decision rather than once here (see rcu_tasks_irq_ip_holds()); nested + * irq-exit preemption cannot happen inside preempt_schedule_irq(), so one + * slot per task is enough. */ static void irqentry_preempt(struct pt_regs *regs) { + unsigned long ip = instruction_pointer(regs); bool in_tramp = IS_ENABLED(CONFIG_RCU_TASKS_PREEMPT_QS) && - rcu_tasks_ip_in_trampoline(instruction_pointer(regs)); + rcu_tasks_ip_in_trampoline(ip); if (in_tramp) rcu_tasks_trampoline_enter(); + if (IS_ENABLED(CONFIG_RCU_TASKS_PREEMPT_QS)) + rcu_tasks_note_irq_ip(ip); preempt_schedule_irq(); + if (IS_ENABLED(CONFIG_RCU_TASKS_PREEMPT_QS)) + rcu_tasks_note_irq_ip(0); if (in_tramp) rcu_tasks_trampoline_exit(); } diff --git a/kernel/fork.c b/kernel/fork.c index cfe3a8e53fbd..1277603bc472 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1870,6 +1870,7 @@ static inline void rcu_copy_process(struct task_struct *p) #ifdef CONFIG_TASKS_RCU p->rcu_tasks_holdout = false; p->rcu_tramp_nesting = 0; + p->rcu_tasks_irq_ip = 0; INIT_LIST_HEAD(&p->rcu_tasks_holdout_list); p->rcu_tasks_idle_cpu = -1; INIT_LIST_HEAD(&p->rcu_tasks_exit_list); diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 6337da5cab9e..cf2ea278fdf5 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -511,6 +511,48 @@ static struct kprobe *get_optimized_kprobe(kprobe_opcode_t *addr) return NULL; } +/* + * True while kprobe_optimizer() is waiting for its Tasks RCU grace period. + * Only in that window can a preemption inside an optprobe's jump region + * matter to it, so kprobe_in_optimized_region() does no work otherwise. + */ +static bool kprobe_optimizer_waiting; + +/** + * kprobe_in_optimized_region - Could @addr be inside bytes a jump-optimized + * kprobe replaces? + * @addr: kernel text address, typically an interrupted instruction pointer + * + * kprobe_optimizer() relies on synchronize_rcu_tasks() to wait for tasks that + * were preempted on an instruction boundary inside the region about to be + * overwritten by the optimized jump; such a task must not report a Tasks RCU + * quiescent state when it is preempted (see rcu_tasks_ip_in_trampoline()). + * This is the lockless, conservative form of get_optimized_kprobe(): it does + * not care whether the kprobe found is, or ever will be, optimized. May be + * called from any context with preemption disabled; the kprobe hash is + * RCU-protected and every free path waits for a grace period after unhashing. + * + * The hash walk only runs while the optimizer is actually waiting. A + * preemption that does not observe kprobe_optimizer_waiting predates the + * grace period (its leading synchronize_rcu() publishes the store to every + * interrupts-disabled reader before any task is sampled as a holdout); such a + * task is then an ordinary preempted holdout, and the jump is not written + * until it has run again and left the region. + */ +bool kprobe_in_optimized_region(unsigned long addr) +{ + int i; + + if (!READ_ONCE(kprobe_optimizer_waiting)) + return false; + + for (i = 1; i < MAX_OPTIMIZED_LENGTH / sizeof(kprobe_opcode_t); i++) + if (get_kprobe((kprobe_opcode_t *)addr - i)) + return true; + return false; +} +NOKPROBE_SYMBOL(kprobe_in_optimized_region); + /* Optimization staging list, protected by 'kprobe_mutex' */ static LIST_HEAD(optimizing_list); static LIST_HEAD(unoptimizing_list); @@ -644,8 +686,12 @@ static void kprobe_optimizer(void) * to 2nd-Nth byte of jump instruction. This wait is for avoiding it. * Note that on non-preemptive kernel, this is transparently converted * to synchronoze_sched() to wait for all interrupts to have completed. + * kprobe_optimizer_waiting lets Tasks RCU recognise tasks preempted + * in such a region while we wait, see kprobe_in_optimized_region(). */ + WRITE_ONCE(kprobe_optimizer_waiting, true); synchronize_rcu_tasks(); + WRITE_ONCE(kprobe_optimizer_waiting, false); /* Step 3: Optimize kprobes after quiesence period */ do_optimize_kprobes(); diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index a801ec4a951b..0e46d8fe4d8e 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1127,6 +1127,29 @@ bool rcu_tasks_ip_in_trampoline(unsigned long ip) } NOKPROBE_SYMBOL(rcu_tasks_ip_in_trampoline); +/** + * rcu_tasks_irq_ip_holds - Is @t irq-preempted somewhere that must hold off Tasks RCU? + * @t: a task inside preempt_schedule_irq() (t->rcu_tasks_irq_ip != 0), or not + * + * Unlike trampoline text, which a task can only be interrupted in while the + * trampoline exists, the bytes kprobe_optimizer() is about to overwrite with a + * jump are ordinary text a task may have been parked in since before the + * kprobe was registered, and the optimizer may start waiting while the task is + * already switched out. So this is evaluated against the IP recorded by + * irqentry_preempt() at every quiescent-state decision -- each pass through + * __schedule() in preempt_schedule_irq()'s loop, and the grace-period + * kthread's scans -- rather than once at preemption time. A task switched out + * synchronously cannot have a resume point inside such a window (a call there + * returns beyond it), so only the irq-exit IP needs checking. + */ +bool rcu_tasks_irq_ip_holds(struct task_struct *t) +{ + unsigned long ip = READ_ONCE(t->rcu_tasks_irq_ip); + + return ip && kprobe_in_optimized_region(ip); +} +NOKPROBE_SYMBOL(rcu_tasks_irq_ip_holds); + /* See if tasks are still holding out, complain if so. */ static void check_holdout_task(struct task_struct *t, bool needreport, bool *firstreport) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416858.1645810 (Exim 4.92) (envelope-from ) id 1x51x3-0006Br-9p; Fri, 11 Sep 2026 14:10:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416858.1645810; Fri, 11 Sep 2026 14:10:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51x3-0006Bi-61; Fri, 11 Sep 2026 14:10:01 +0000 Received: by outflank-mailman (input) for mailman id 1416858; Fri, 11 Sep 2026 14:10:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51x2-00069z-28 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51x1-00E9V9-FE for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:09:59 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bb2-2eae-0a2a0a5409dd-0a2a450497e8-20 for ; Fri, 11 Sep 2026 16:09:59 +0200 Received: from [209.85.128.178] (helo=mail-yw1-f178.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bb6-b57f-0a2a45040019-d15580b2c9a0-3 for ; Fri, 11 Sep 2026 16:09:59 +0200 Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-86c0e4dd49cso9235347b3.3 for ; Fri, 11 Sep 2026 07:09:58 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e8047a4dsm255725685a.23.2026.09.11.07.09.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:09:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135798; x=1789740598; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dPfI0hp8i5ODnb7Ti+2mvm8Dl2bKUUBUiZ4EzuwrKLQ=; b=NiE7GNK5Xk8hFJegGxEnIGYK9q7Gp54jBAMQnpFvn5tlf0pr4bh/q5kTIwv2dX54gN iYUGX2k3NxDC09CYG478fRCWm0zxLdSHnlUzCHXqnQuUJDFkajKBIDyH+WZqxBTPuIvm e6XJsFYOCETuU+DUKHhva7e+OFb2whbU9brY/H2FlGFQ1/9cPkf08EQV3IhtuVdcgNIf c3F/OX5QXcdlDegna68S3DUoD3DtujQrAPUU13ZfAOaA79ZcuscVuFOJ5f8aaIgc/R+G dJdWukyO/pYMhlMxSMkRJiMTZjPs7r4p3edv9W2/eB70UrckNicUwNcJ6heVFqJtoTGt e5UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135798; x=1789740598; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=dPfI0hp8i5ODnb7Ti+2mvm8Dl2bKUUBUiZ4EzuwrKLQ=; b=HBaaLJS5G4VAf23aqx/A+Rb8K2L5rXzsLluHzAbGgIe6EPszG5N1U5l7SSK+cIVV9a pxXpCWNOz5W3Qze27z0UThcLlfvcsbHPBl8fSE2xI7clm1H33p9NL/MXKFHTSecNBr+4 R5me2dMPcfJ+QqScIsFNU7odJcyQ7XogXqiCgQT55hBK1b6cRvVbhhykN1P1v+WO8VrP xDb5TUTjZ6s+f0qb8Xlk9R6mOophuGacQqesFzWwZmRuYUcN+dOy0pKlut+mkcCeLApN Efxq9kY6PYDjAhJG8aBGcZ22fQeBQ2Am3L3mAr1hnwDklXe+J+Qen4tQpUy6kXKK/3uZ sVFA== X-Forwarded-Encrypted: i=1; AKwUvBywBBhhciAi3Bif872zNSZwKIGvB97r1I7/TWSWgFvPyifKMKSw76JBcp7Jo+PVDfaJLKvGitMNs50=@lists.xenproject.org X-Gm-Message-State: AFuF++kiNOV7fNu7BdPAYrrz4OqNX3v5xOO/BE+zRIf0NrW1ebgDJ7ko eh3oDtdel9tcz0i55DIiE0jJYRfkmHOWPo5aWTq4jZjxH1LL2PW/TqFpNcU78cbw9Ko= X-Gm-Gg: AYBFou2/X3RlO0N4k4HhMGC7t6iSnPxL0pFsVO4ZtHYof8qeUEv7DCsWHe4hig34ifg rHqwNJBSh3wQfOHGT3pHEoMrNzMT4eSVc6m0Q7j3x8XTy9oh36S91yasP6Ub0/097c/cp8titbo CkxFzf4CF7GnvCw5OkMUinAJ0ZUYkcvGpoYbvNcLtrxVAEnY/7yjDei+C5Xp6fKFm2jkExMQ5nA JDdDmjxNbu5yJJHqJJgoU4yCs8xMDgdTBf3mhynaQZTwJCi+gTySfaVyGmNZEsVAH7hfXmvQWSQ A2vTApnmjzImxE25DsLb06u40z+mZ9z5Z+7s/LcegxBECP3H6gJv+4VE6zkrwbszO7fcCwHHcEw Ueuzd0bhJ6V19qHbTRTvVuE8XtFwWpc/MJdZEJIcsJ/Q2NzeQJRwC9U+HvPMcvbKUWiHoYM3aSh Ln/7IdKxoeOCP4Pr3RlC70Xwtii6JY+3eLoiUNsZjrnqALjh2Rsh8zggPHicEkYqcVihMnweARh NsdgKSB1aeezig4KTRsQzUqPdQkEHtI7tNtTtPVa94D7o5LRcCjgiBm X-Received: by 2002:a05:690c:e64c:20b0:873:5c7b:c107 with SMTP id 00721157ae682-884b338f76bmr10673077b3.63.1789135797554; Fri, 11 Sep 2026 07:09:57 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:43 +0000 Subject: [PATCH RFC v2 05/15] ftrace: Mark modules hosting direct-call trampolines for Tasks RCU MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-5-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=7014; i=josef@toxicpanda.com; h=from:subject:message-id; bh=0t7KiskdL/z6tLq58DM0lyjoNIyrb4NbcoG2+xIJz7Y=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QIYpNGNhK8IIkgKHr1QxZn5VS4Cl+AINmPPfcsvZi4ZGk+7mTHv8oPmVPnKO/4ckp4yjA+b+rY+ zCDlRK/TVmQM= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1789135799-C36C2B50-0FAA8C3D/0/0 X-purgate-type: clean X-purgate-size: 7016 An out-of-line direct trampoline registered with register_ftrace_direct() is kept alive only by Tasks RCU while a task executes it or is preempted in something it called; ftrace_shutdown()'s synchronize_rcu_tasks() is what stops rmmod freeing it under such a task. Once preemption becomes a Tasks RCU quiescent state, such a trampoline must hold current->rcu_tramp_nesting across its call-out like the ftrace and BPF trampolines do, so document that in register_ftrace_direct(). That still leaves the few instructions before the increment and after the decrement. For BPF images those are in dynamically allocated text that rcu_tasks_ip_in_trampoline() already treats as protected, but the in-tree samples (and any similar user) place their trampolines in module .text. Add a sticky module::ftrace_direct_tramp flag, set by every register/modify path when the direct address is module text, and have rcu_tasks_ip_in_trampoline() treat a task interrupted anywhere in such a module as a potential reader. Other modules' text is unaffected. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/module.h | 7 +++++++ kernel/rcu/tasks.h | 23 +++++++++++++++++++++-- kernel/trace/ftrace.c | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 67 insertions(+), 2 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 96cc98568eea..ea4727f53fab 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -521,6 +521,13 @@ struct module { unsigned int num_ftrace_callsites; unsigned long *ftrace_callsites; #endif +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS + /* + * An ftrace direct-call trampoline lives in this module's text; see + * rcu_tasks_ip_in_trampoline(). Sticky once set. + */ + bool ftrace_direct_tramp; +#endif #ifdef CONFIG_KPROBES void *kprobes_text_start; unsigned int kprobes_text_size; diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 0e46d8fe4d8e..1b9fe1bfa591 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1114,16 +1114,35 @@ bool __weak arch_rcu_tasks_ip_in_trampoline(unsigned long ip) * deliberately does not consult is_ftrace_trampoline() and friends: text * being torn down may already be unregistered there while a task still * stands on it; - * - in core text the architecture flags via arch_rcu_tasks_ip_in_trampoline(). + * - in core text the architecture flags via arch_rcu_tasks_ip_in_trampoline(); + * - in the text of a module that hosts an ftrace direct-call trampoline, + * which covers the instructions before that trampoline's increment and + * after its decrement (see ftrace_direct_mark_module()). * * A false positive only defers the quiescent state to the task's next * context switch. */ bool rcu_tasks_ip_in_trampoline(unsigned long ip) { + bool ret = true; + if (core_kernel_text(ip)) return arch_rcu_tasks_ip_in_trampoline(ip); - return !is_module_text_address(ip); + +#ifdef CONFIG_MODULES + scoped_guard(rcu) { + struct module *mod = __module_text_address(ip); + +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS + if (mod) + ret = READ_ONCE(mod->ftrace_direct_tramp); +#else + if (mod) + ret = false; +#endif + } +#endif + return ret; } NOKPROBE_SYMBOL(rcu_tasks_ip_in_trampoline); diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 53d5db60bfa5..14f27b887231 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6076,6 +6076,29 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) ops->trampoline = 0; } +/* + * A direct trampoline may live in module text rather than in dynamically + * allocated text that rcu_tasks_ip_in_trampoline() recognises on its own (see + * samples/ftrace/ftrace-direct*.c). The trampoline itself must hold + * current->rcu_tramp_nesting across its call-out (see register_ftrace_direct()); + * marking the owning module here covers the instructions before that increment + * and after the decrement, where a task interrupted in the module's text must + * not be treated as Tasks-RCU quiescent, so that ftrace_shutdown()'s + * synchronize_rcu_tasks() still keeps the module text from being freed under + * it. + */ +static void ftrace_direct_mark_module(unsigned long addr) +{ +#ifdef CONFIG_MODULES + struct module *mod; + + guard(rcu)(); + mod = __module_text_address(addr); + if (mod) + WRITE_ONCE(mod->ftrace_direct_tramp, true); +#endif +} + /** * register_ftrace_direct - Call a custom trampoline directly * for multiple functions registered in @ops @@ -6090,6 +6113,17 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) * and save the parameters of the function being traced, and restore them * (or inject new ones if needed), before returning. * + * Nothing but Tasks RCU keeps the trampoline at @addr alive while a task is + * executing it or is preempted in something it called. On architectures that + * select ARCH_HAS_RCU_TASKS_PREEMPT_QS a preemption is a Tasks RCU quiescent + * state unless current->rcu_tramp_nesting is non-zero, so the trampoline must + * increment it before calling out and decrement it before returning, as the + * ftrace and BPF trampolines do (see rcu_tasks_trampoline_enter() and + * samples/ftrace/ftrace-direct.h). The few instructions before the increment + * and after the decrement are covered by the irq-exit IP check: automatically + * for trampolines outside kernel and module text (e.g. BPF images), and via + * ftrace_direct_mark_module() for trampolines in module text. + * * Returns: * 0 on success * -EINVAL - The @ops object was already registered with this call or @@ -6169,6 +6203,7 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) ops->flags |= MULTI_FLAGS; ops->trampoline = FTRACE_REGS_ADDR; ops->direct_call = addr; + ftrace_direct_mark_module(addr); err = register_ftrace_function_nolock(ops); if (err) @@ -6237,6 +6272,8 @@ __modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) lockdep_assert_held_once(&direct_mutex); + ftrace_direct_mark_module(addr); + /* Enable the tmp_ops to have the same functions as the direct ops */ ftrace_ops_init(&tmp_ops); tmp_ops.func_hash = ops->func_hash; @@ -6419,6 +6456,7 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash) hlist_for_each_entry(entry, &hash->buckets[i], hlist) { if (__ftrace_lookup_ip(direct_functions, entry->ip)) goto out_unlock; + ftrace_direct_mark_module(entry->direct); } } @@ -6702,6 +6740,7 @@ int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, b tmp = __ftrace_lookup_ip(direct_hash, entry->ip); if (!tmp) continue; + ftrace_direct_mark_module(entry->direct); tmp->direct = entry->direct; } } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416859.1645819 (Exim 4.92) (envelope-from ) id 1x51x7-00072L-Gk; Fri, 11 Sep 2026 14:10:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416859.1645819; Fri, 11 Sep 2026 14:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51x7-00071p-DO; Fri, 11 Sep 2026 14:10:05 +0000 Received: by outflank-mailman (input) for mailman id 1416859; Fri, 11 Sep 2026 14:10:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51x5-0006Zz-5H for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51x4-00E9V9-IH for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:02 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bb2-2eae-0a2a0a5409dd-0a2a450497e8-36 for ; Fri, 11 Sep 2026 16:10:02 +0200 Received: from [209.85.222.179] (helo=mail-qk1-f179.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bb9-b57f-0a2a45040019-d155deb3d53d-3 for ; Fri, 11 Sep 2026 16:10:02 +0200 Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-9399798ca61so108279285a.1 for ; Fri, 11 Sep 2026 07:10:02 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939fd0ebaf6sm17627485a.35.2026.09.11.07.09.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:09:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135801; x=1789740601; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sAaaOhrJ7Jcw63o+Xz8kKBY4jQKDr2HCsih3+9envV4=; b=mfj7AjBLWfzEl9nUZ0orOhFTHNS2xjO/JOc0e3l3vLXE+Kjmig9qmhP6KdYuKi8R3L 61MECn4zxk346aeXVdb6lpRm6pbIc8aN/DtLTrAlFNXF+zIcojkMjm9UPdUuTxUdGA/k ANkZTprAtM1q0GHOaMyFaWqhxntmJHhIUU2a5GNvzOSZizmRrOLa7BCyARunr2XE8IJJ jOeghTyczxvegjEHFZ0xovxk7qIEMffWZEYgt+ilADOCbRR7RFD+VZ7csEJJYP860ioL RFjg/oJvb4gwk5ymD2sFj9ZZaIJMeti8rgrvwPH2YCCE8tKtVRmS6S7zNZlsYO6hVFQS EUkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135801; x=1789740601; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=sAaaOhrJ7Jcw63o+Xz8kKBY4jQKDr2HCsih3+9envV4=; b=Ein14Q0IB13Mgxp92z7M16nAuI4ACam/pv+zZpLZrecLrnkX9Vir7kJAys3d82rX5q j/iOQ8wM+IyeVsGP0T/S9EVUIrSQKjPTOySbL3pXxApaQahxg2xNV4AHtkkQAtpJF/Ks w1MgsAQJIyAq5SpuzqK3vmeV2OZShle0Nx9yH0sZvLZNGDEoM0hhPDFOAAvVfiXhvMzR dvmP4/ooR1aRKDStIQiX6JzQtdYZZiwvGte18tzvY98n0TfOtt7GAzlXjb0kcKisT378 DyPaeOZFGNI4Qqr4hmZCo+vpoFZ2qtnPDlpbhXz6C6rwfyA6kYm8sxqBlEq7dNVoMuTn 06fw== X-Forwarded-Encrypted: i=1; AKwUvBxGQvJo8TbdG45i2yJsxG/25DY1AfGu7ZRDQ/EA3rCAtGMntZyhGuRAXllcLnvrQnKAn8Iuf9Jn0d4=@lists.xenproject.org X-Gm-Message-State: AFuF++l3dj7aI/vpwNRkC7wWvGofo069mOh5OKla8svnXPdvvM/PBrrF ppEBEMLRlK7lsEpvJ32VmJ+ARm4PSoXm14aaSxw/XLc5DK62hYd/l4pXehE5ZRjNpAg= X-Gm-Gg: AYBFou23Zh4yzcxYkMDMAQ9ojBHAl+b0Pum4ZuhLx+R/dnGjeOjvbfT+L83+l2GwaOO VmnPkvf7dSTPp7Wk3/h1c1xH/6npfNw2DiTVQvrxQEubvXQbNMP6zqT0T+i2mtxAF7jsdR23Rwd vhDHOaHVcQaJcI5oMpGEONfxjnlbCuQcmqNXft65tFA+2qY4wpq9C95mXJ7TqqEhwa3P7zPvRnh oeAPddQYQrWThueTqFqxVxcjrcq++JR/W8lF1CJ6+LZm6vZWFS82RcFD63EdHoEDOwxBlveeB3J loUUglMtMnErSzxnJkobna3JrGBjDUpHyPPHyKGU7aBKt75Ht6MCMZZ7CeI+MgEol+zAHvTIwzn +kD4rJuEXph1dQZhPks+K+hTSmL9q4m1HI/nS+dpTytv8qZniTFLcJHXZKWUWzPSrJDfnhRpTMC c0tlykXSKkjkc2HGYCCDug+kdMa6rmSka0GrclnjFtxaYa6oeydGg4ecptL+X2oe38daD8HmVon DstaQ5VOZ7puaPsOFLVi1wPbK8qJiY4W7PAQVBqPL2YhdIfMw2mXZPD X-Received: by 2002:a05:620a:2589:b0:939:112:d526 with SMTP id af79cd13be357-939ea07c29cmr585929585a.18.1789135800554; Fri, 11 Sep 2026 07:10:00 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:44 +0000 Subject: [PATCH RFC v2 06/15] x86/ftrace: Maintain Tasks RCU trampoline nesting in ftrace_caller MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-6-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=7822; i=josef@toxicpanda.com; h=from:subject:message-id; bh=bmu7zPpxbnsCSHBhyK2WDk3M9VMJMCkgBrW5uszUBuU=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QHW3FDsl5CxgF20PG9LmVTMTg46RLyWS2XjYhSinsXHd+9ujqg/53BxxPRKz/SrjYV+XGJTF9Bc FIbELyLBq3wc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1789135802-53CC7B50-55E21C92/0/0 X-purgate-type: clean X-purgate-size: 7824 Bracket the call out to the ftrace_ops callback in ftrace_caller and ftrace_regs_caller with an increment/decrement of current->rcu_tramp_nesting. The instructions sit inside the region that create_trampoline() copies for per-ops dynamic trampolines, so those inherit them; the %rip-relative per-CPU reference to current_task is fixed up by text_poke_apply_relocation() like CALL_DEPTH_ACCOUNT's. %rdx is dead at both points (about to be loaded with the ops pointer on entry, restored by restore_mcount_regs on exit). Two pieces of core text still run with the count at zero while holding the address of a Tasks-RCU-protected trampoline they are about to enter: the static stubs themselves, whose direct-call tails keep a BPF trampoline address on the stack until the final RET, and, under CONFIG_MITIGATION_RETHUNK, the return thunk that RET expands to. Add an ftrace_static_tramp_end marker after ftrace_stub_direct_tramp and linker symbols around .text..__x86.return_thunk and .text..__x86.rethunk_safe, and provide arch_rcu_tasks_ip_in_trampoline() covering [ftrace_caller, ftrace_static_tramp_end) and both thunk ranges so the irq-exit check treats a task interrupted there as still inside a trampoline. The hook is built only under CONFIG_RCU_TASKS_PREEMPT_QS, which x86 does not select until a later patch. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/kernel/asm-offsets.c | 3 +++ arch/x86/kernel/ftrace.c | 37 +++++++++++++++++++++++++++++++++++++ arch/x86/kernel/ftrace_64.S | 43 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/vmlinux.lds.S | 4 ++++ 4 files changed, 87 insertions(+) diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c index 081816888f7a..4f3b1caa5a30 100644 --- a/arch/x86/kernel/asm-offsets.c +++ b/arch/x86/kernel/asm-offsets.c @@ -46,6 +46,9 @@ static void __used common(void) #ifdef CONFIG_STACKPROTECTOR OFFSET(TASK_stack_canary, task_struct, stack_canary); #endif +#ifdef CONFIG_TASKS_RCU + OFFSET(TASK_rcu_tramp_nesting, task_struct, rcu_tramp_nesting); +#endif BLANK(); OFFSET(pbe_address, pbe, address); diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index 17d6edfcb7e0..8f63cd4b543c 100644 --- a/arch/x86/kernel/ftrace.c +++ b/arch/x86/kernel/ftrace.c @@ -275,6 +275,43 @@ static inline void tramp_free(void *tramp) execmem_free(tramp); } +#ifdef CONFIG_RCU_TASKS_PREEMPT_QS +extern void ftrace_static_tramp_end(void); +extern char __return_thunk_start[], __return_thunk_end[]; +extern char __rethunk_safe_start[], __rethunk_safe_end[]; + +/* + * See rcu_tasks_ip_in_trampoline(). Some core kernel text behaves like a + * trampoline for Tasks RCU purposes because a task executing there with + * rcu_tramp_nesting == 0 may still be about to enter a Tasks-RCU-protected + * trampoline whose address it already holds: + * + * - the static ftrace_caller / ftrace_regs_caller / ftrace_stub_direct_tramp + * stubs, which carry a direct-call target on the stack until their final + * RET, and + * - the return thunks that RET expands to under CONFIG_MITIGATION_RETHUNK, + * which run after leaving the stubs above and before landing in that + * target. + */ +bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip) +{ + if (ip >= (unsigned long)ftrace_caller && + ip < (unsigned long)ftrace_static_tramp_end) + return true; +#ifdef CONFIG_MITIGATION_RETPOLINE + if (ip >= (unsigned long)__return_thunk_start && + ip < (unsigned long)__return_thunk_end) + return true; +#endif +#ifdef CONFIG_MITIGATION_SRSO + if (ip >= (unsigned long)__rethunk_safe_start && + ip < (unsigned long)__rethunk_safe_end) + return true; +#endif + return false; +} +#endif /* CONFIG_RCU_TASKS_PREEMPT_QS */ + /* Defined as markers to the end of the ftrace default trampolines */ extern void ftrace_regs_caller_end(void); extern void ftrace_caller_end(void); diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index 62c1c93aa1c6..902472c41798 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -145,6 +146,27 @@ SYM_FUNC_END(ftrace_stub_graph) #ifdef CONFIG_DYNAMIC_FTRACE +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). These live + * inside the region copied into dynamic trampolines; the %rip-relative per-CPU + * reference is fixed up by text_poke_apply_relocation() in create_trampoline(). + * The increment must precede the function_trace_op load: between that load and + * the call, the ops pointer in %rdx is protected only by Tasks RCU. + */ +.macro RCU_TASKS_TRAMP_ENTER reg:req +#ifdef CONFIG_TASKS_RCU + movq PER_CPU_VAR(current_task), \reg + incl TASK_rcu_tramp_nesting(\reg) +#endif +.endm + +.macro RCU_TASKS_TRAMP_EXIT reg:req +#ifdef CONFIG_TASKS_RCU + movq PER_CPU_VAR(current_task), \reg + decl TASK_rcu_tramp_nesting(\reg) +#endif +.endm + SYM_FUNC_START(__fentry__) ANNOTATE_NOENDBR CALL_DEPTH_ACCOUNT @@ -163,6 +185,8 @@ SYM_FUNC_START(ftrace_caller) leaq MCOUNT_REG_SIZE+8(%rsp), %rcx movq %rcx, RSP(%rsp) + RCU_TASKS_TRAMP_ENTER %rdx + SYM_INNER_LABEL(ftrace_caller_op_ptr, SYM_L_GLOBAL) ANNOTATE_NOENDBR /* Load the ftrace_ops into the 3rd parameter */ @@ -181,6 +205,8 @@ SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) ANNOTATE_NOENDBR call ftrace_stub + RCU_TASKS_TRAMP_EXIT %rdx + /* Handlers can change the RIP */ movq RIP(%rsp), %rax movq %rax, MCOUNT_REG_SIZE(%rsp) @@ -209,6 +235,8 @@ SYM_FUNC_START(ftrace_regs_caller) CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER %rdx + SYM_INNER_LABEL(ftrace_regs_caller_op_ptr, SYM_L_GLOBAL) ANNOTATE_NOENDBR /* Load the ftrace_ops into the 3rd parameter */ @@ -246,6 +274,8 @@ SYM_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL) ANNOTATE_NOENDBR call ftrace_stub + RCU_TASKS_TRAMP_EXIT %rdx + /* Copy flags back to SS, to restore them */ movq EFLAGS(%rsp), %rax movq %rax, MCOUNT_REG_SIZE(%rsp) @@ -328,6 +358,19 @@ SYM_FUNC_START(ftrace_stub_direct_tramp) RET SYM_FUNC_END(ftrace_stub_direct_tramp) +/* + * [ftrace_caller, ftrace_static_tramp_end) is treated as trampoline text by + * rcu_tasks_ip_in_trampoline(): after RCU_TASKS_TRAMP_EXIT the stubs may + * still hold a direct-call target (a BPF trampoline) on the stack until the + * final RET, and that target's lifetime is guarded by Tasks RCU. With + * return thunks the RET itself runs elsewhere; arch_rcu_tasks_ip_in_trampoline() + * covers the thunk text too. + */ +SYM_CODE_START_NOALIGN(ftrace_static_tramp_end) + UNWIND_HINT_UNDEFINED + ANNOTATE_NOENDBR +SYM_CODE_END(ftrace_static_tramp_end) + #else /* ! CONFIG_DYNAMIC_FTRACE */ SYM_FUNC_START(__fentry__) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 2438b89a4620..e546283dc267 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -151,7 +151,9 @@ SECTIONS * definition. */ . = srso_alias_untrain_ret | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20); + __rethunk_safe_start = .; *(.text..__x86.rethunk_safe) + __rethunk_safe_end = .; #endif ALIGN_ENTRY_TEXT_END @@ -162,7 +164,9 @@ SECTIONS SOFTIRQENTRY_TEXT #ifdef CONFIG_MITIGATION_RETPOLINE *(.text..__x86.indirect_thunk) + __return_thunk_start = .; *(.text..__x86.return_thunk) + __return_thunk_end = .; #endif STATIC_CALL_TEXT *(.gnu.warning) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416862.1645828 (Exim 4.92) (envelope-from ) id 1x51xD-0007wE-T7; Fri, 11 Sep 2026 14:10:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416862.1645828; Fri, 11 Sep 2026 14:10:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xD-0007vr-Pc; Fri, 11 Sep 2026 14:10:11 +0000 Received: by outflank-mailman (input) for mailman id 1416862; Fri, 11 Sep 2026 14:10:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xC-0007sd-ML for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51xC-008fhq-3A for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:10 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bb1-8faa-0a2a0a5109dd-0a2a450a8708-22 for ; Fri, 11 Sep 2026 16:10:10 +0200 Received: from [209.85.222.174] (helo=mail-qk1-f174.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bbc-f2d2-0a2a450a0019-d155deaed40e-3 for ; Fri, 11 Sep 2026 16:10:05 +0200 Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-939e028b3aeso125593085a.0 for ; Fri, 11 Sep 2026 07:10:05 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939f1dd527asm125166385a.16.2026.09.11.07.10.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:01 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135804; x=1789740604; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=hbVlQmHCpb9zv+5BDFsE+SK081jwlXFhk4tZhnaWY5k=; b=A64sqYAj5eJCh8MNrqfTSmnzXZ94RPaLaNqmw/GHjBKWr6M/coofjHOfJjqxABIqjk LH54PxejLJe4o1Cn6BrquGdp66c6veVD44MHuAEfQh2a0wRTs0vUNGIukYcPhbUYnW/t 7eZx9aP5323p+HM4omnZ6UNPN4/n0N94FU3LPQEnzOG2YSJMblyz3m43jmEcV6SBNzmQ 0kKDXVI2nLhKz6YqUgf0WUgT2jR93ZHlPJm+FCHq22Tu/4vRRShCYCJu4p9TwtlvVGYk voXBipe6gaiHXG0ru8XGk4WUfYYemPyUHRyE2XEkTBB+aVpTCuVO+BjjzsUbZ3dTNTOn vmyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135804; x=1789740604; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=hbVlQmHCpb9zv+5BDFsE+SK081jwlXFhk4tZhnaWY5k=; b=T4bsTcYOWeQ0/VUX0tO70L/ldtM8Cp8+PFJ7P56v2F2XMtA6vSpu3F4el03oJ8a3xN ItTA7qwrGmtnVFKfSVy8qhoSQ2Hyt2ljwn6VtcqVOCXktVXg3jp9AM0AKGBfvVrSbLwH Sy8tpSIVtSHZ4ygiU/aGZdcoTVZxTmaGlL7VXVtnNl0CII3rGzO6xvrdo+pCw9P8f5V4 btFrobxbq0St7i6MxOkldHM0hFJWX/uuRDXBxPQNZAv5I6ehva2x13BWkVW7cxb3vuqG 8nFqJfAT7dLccdq7D1XCrr0mMpy5xGV98ki1xPoDa9csVg8Z53H4AXjIReryO7mEuW1v 3AAw== X-Forwarded-Encrypted: i=1; AKwUvByXdPIucLDZmol8dkVfoMPA7ulx8AnOeE+79SNsnS2s7tV9Lel4OB4evodPGC7LuIikQIk8cJINwzQ=@lists.xenproject.org X-Gm-Message-State: AFuF++lNPAI2Aur7Ee7d85kZdMr/ozWe2XWpn+jfj24ZoDa0aWv+m+bg B/0tr6NvH5HJOWSgM9ySe0OPHZsCivqedcZf53Z47x4rJTUFlzQKozqnw4vl/LPHL70= X-Gm-Gg: AYBFou0KXEMh4KB4THapfWuuuBNow072wZWUktbdOt465KI+5k+P7uc0sG751xeog6T fOIax7BLy08WQshwiBX0LXQmPykeW7g8UsJKlEtbsENsMyazjarrL846GI4zH+BvKE+LKti0SHG igSG06Bw7FtNvgfZTekTXyLc1RotB+npKH4yGP4Nkj7TkjlbD4fd7ZT0QULc4VdRYs+O9Ui/jrq 3AUG1x/FLxGtrrNelrCt1NlkLx1Bp/7qxugDdCuPCqg5MGnZJ3/7GY2DR+wbj3nPdRTqBogNCRo R28Q205hguOkM/zPQVYFONyMbXDQJZpPxxoQqCIewsFx2lMAzRFvrTq4dcyoQfEpYAyFYQ6L5TJ xXIVtp21MnyQaiuc2d1sszAn1/XSfKQz8Op2jNkUnhyt3HHq1RTpDPTJunvpK+kZ69wJcyIzX+T 27Bo367HEnVG2cnWCCqNS7mF+YdDK2pA+lfNfmk3Pc53kFsC8zFr+8RyILzanQiiQd4WmqiF1M4 jNsV1MsDGIMmmayjIb9I6yG8UqUbcfwuMrMmptoRNgW8Waq72hzcs0R X-Received: by 2002:a05:620a:198d:b0:939:3a81:326 with SMTP id af79cd13be357-939ea18c166mr526461185a.37.1789135803738; Fri, 11 Sep 2026 07:10:03 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:45 +0000 Subject: [PATCH RFC v2 07/15] x86/kprobes: Maintain Tasks RCU trampoline nesting in the optprobe template MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-7-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=2636; i=josef@toxicpanda.com; h=from:subject:message-id; bh=8cFDFeD2IXPN8Vlj1EymtW9Bi32PSZwsbXS468MRSTs=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QE88Fo4D8KnMZviii3UcxtNsSOWitctfeeqTUeKrfDl5ze3tUkJnL+Us2LrW6ea29znHZAO8PVa SQS9QIpNv5Ao= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-4011c0/1789135805-591C5CFC-1D276900/0/0 X-purgate-type: clean X-purgate-size: 2638 The jump-optimized kprobe template calls optimized_callback() with preemption still enabled for its first few instructions, so bracket the call with an increment/decrement of current->rcu_tramp_nesting. The template lives in .rodata and is memcpy()d into each optinsn slot without relocation processing, so the per-CPU reference to current_task must be an absolute %gs: address (R_X86_64_32S, relocated for KASLR like any other) rather than %rip-relative. %rax has already been saved by SAVE_REGS_STRING and is dead after the call. The slot itself is dynamically allocated text, so the instructions before the increment and after the decrement are covered by the irq-exit IP check. 64-bit only; 32-bit x86 does not take part. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/kernel/kprobes/opt.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c index 3f8fea52619f..f722520bb989 100644 --- a/arch/x86/kernel/kprobes/opt.c +++ b/arch/x86/kernel/kprobes/opt.c @@ -31,6 +31,7 @@ #include #include #include +#include #include "common.h" @@ -101,6 +102,23 @@ static void synthesize_set_arg1(kprobe_opcode_t *addr, unsigned long val) *(unsigned long *)addr = val; } +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). The + * template is memcpy()d into the slot without relocation processing, so the + * per-CPU reference must be absolute, not %rip-relative. + */ +#if defined(CONFIG_TASKS_RCU) && defined(CONFIG_X86_64) +#define OPTPROBE_RCU_TASKS_ENTER \ + " movq %gs:current_task, %rax\n" \ + " incl " __stringify(TASK_rcu_tramp_nesting) "(%rax)\n" +#define OPTPROBE_RCU_TASKS_EXIT \ + " movq %gs:current_task, %rax\n" \ + " decl " __stringify(TASK_rcu_tramp_nesting) "(%rax)\n" +#else +#define OPTPROBE_RCU_TASKS_ENTER +#define OPTPROBE_RCU_TASKS_EXIT +#endif + asm ( ".pushsection .rodata\n" ".global optprobe_template_entry\n" @@ -114,6 +132,7 @@ asm ( "optprobe_template_clac:\n" ASM_NOP3 SAVE_REGS_STRING + OPTPROBE_RCU_TASKS_ENTER " movq %rsp, %rsi\n" ".global optprobe_template_val\n" "optprobe_template_val:\n" @@ -122,6 +141,7 @@ asm ( ".global optprobe_template_call\n" "optprobe_template_call:\n" ASM_NOP5 + OPTPROBE_RCU_TASKS_EXIT /* Copy 'regs->flags' into 'regs->ss'. */ " movq 18*8(%rsp), %rdx\n" " movq %rdx, 20*8(%rsp)\n" -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416861.1645834 (Exim 4.92) (envelope-from ) id 1x51xE-0007z0-BC; Fri, 11 Sep 2026 14:10:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416861.1645834; Fri, 11 Sep 2026 14:10:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xE-0007yW-1P; Fri, 11 Sep 2026 14:10:12 +0000 Received: by outflank-mailman (input) for mailman id 1416861; Fri, 11 Sep 2026 14:10:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xC-0007sY-Lf for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51xC-00E9cU-2O for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:10 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bc0-bab6-0a2a0a5309dd-0a2a4508af86-6 for ; Fri, 11 Sep 2026 16:10:10 +0200 Received: from [209.85.219.52] (helo=mail-qv1-f52.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bc1-f659-0a2a45080019-d155db34f044-3 for ; Fri, 11 Sep 2026 16:10:09 +0200 Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-910316a2fc9so11546576d6.2 for ; Fri, 11 Sep 2026 07:10:09 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e7f184d9sm254193785a.12.2026.09.11.07.10.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135808; x=1789740608; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7VM45t8rF8CqlHWPsaSwdk7BD4ox5LDNpAeDrj6m5qM=; b=ZbHGPsWwzRok43ZcjJKavwsPNS6W0mLdK9348ZPWknyWWlld1xfZCspzjln3natrNC fLPC4iTskVhP4u303UmjS+g0Ip/p/VhH7SO2uyC/vNl/uM3oZuYvO5smkIN8jQ0BQNUU +L04CtvCiDJjyTDTRNrR18hJVI6xXOF7OSvu3RLpX0rpp83yDGrkle2BErDx8pXnVvZj W/nuPUeBb5BbtwiF+baCgXI4BqNs3bzacBuBGqZqMkrbqISQYKKXu+fVdrofH1dy/jVe In6ZuqGyNu9ihBM+XHQZ7vpyquj3dNRiF1xnAElzj6wrMigAVXg055zkKu6thr4ArAl8 9Z/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135808; x=1789740608; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7VM45t8rF8CqlHWPsaSwdk7BD4ox5LDNpAeDrj6m5qM=; b=DYencswdLXs79jqpcedU1zonAw8jAn64Xd6zQlbtl6Xz0/SHVVI+tQl3hLqhuyQkDb E+aRazfDRKRrOeSMD2vzwUbwBoobg3DLZQyA9KeQ0acYNA0EVnoovyaVbh9A6gd4VplC 4kKX85VzV2l/6XD7TF4VDFZn+VdRHNywHRpIt94eQbCCugCPJy4ZDqy9Xqzano8Oopnr BCwSCZ1hs3C2Sy5/ofUlGncWH9AJNXkOGsRq3RShB3BposrFJC+CWDFcNguXnnSUE3gC AOeU2sI+8WPlAcHHmzVaBzwqRK0Vx/IGPKcluW7iqjY+uoFBWZE85YEhFvmih2aZ2ZMY 5Abw== X-Forwarded-Encrypted: i=1; AKwUvBxDFulrSOLP+mobzBfJjiUa35QNVvt/1/g2LcPqiboC4BPgK8oot9XqfTeGdLvyoRG0oZ3mZHZLefM=@lists.xenproject.org X-Gm-Message-State: AFuF++kwY+LsWxZk/DcFIZCSGQ1cE+dbnraXA/jRBSTlFkNRlADKYbYF uYfugZDObyQrzSeyCFu7mi6oefjAHR2s2DSEdeaaANPNp0YXszo+5KnEWf7ELabFFNk= X-Gm-Gg: AYBFou2zm2M8ndv9oDjqiJ87taADzhsT0zlBzBRt4Hw+XnWX+snZJKvv21pZYQIirTK kGSi9GnyT5i3kNlofAHxpADALiUfXrxR5baWX1VRIt3FoUHcopBwTWbOnc/8EilBgAZk6nj/9Ri KJobqeuGchU87v5BA2BXQggAn8Gi/8tImrbDvDWHF0Mp7iSx4ZwV+72xS96m7uySIpL/o1AI/Ux DhtDiX1RzKu7mx3jiGBMgV2T5z/xbXg3zyDuOZnxcNtRUCxBPI2zqxoziGY62nI89LqnQTHXtof HiWzt1TFcQsmTJ41QzOpJgZymyHdk78XNqJhwuOT49JB/HmTB+bxgp8JCxzU3tTy7xUc0s2E/PU qOzkK7Oomoy3G8vjfzS3ciIfETlUY3AAxeT86FjVzlQRk6llgD0meba8Ze9nd+gpAHF6hE1Kcb9 CoMlXxgATEzyp4ng52V2LTV/+1SMzQaZTTA5tR6N2LTD6J/0YEzme73A+D1nPDu57vr+jAKqi4/ J5k0uMSlPktP94jTCN2eijN967nt7w8Ug3DRR13Yl/PUfJ8DcODbXvB X-Received: by 2002:a05:620a:25c7:b0:939:bd4e:b2fe with SMTP id af79cd13be357-939ea2877e9mr555790285a.40.1789135808266; Fri, 11 Sep 2026 07:10:08 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:46 +0000 Subject: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=4464; i=josef@toxicpanda.com; h=from:subject:message-id; bh=ZoHASPcgXPkyj8nhWq6Qxe/k1AFcC7iFexyU3IrpvR8=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNGMQXlnJ9mLTB5EylkME94aCeeA53rjkqD+SHndTEJHVSfeCPYIUtSGAIP6GARv7tJy5dM1hBK jP1T+H+zt3A0= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1789135810-D534D87B-3E826EF8/0/0 X-purgate-type: clean X-purgate-size: 4466 Emit an increment of current->rcu_tramp_nesting once the trampoline's frame is set up and a decrement before the final register restore, so that a task preempted while running fentry/fexit/fmod_ret/LSM programs or the __bpf_tramp_enter()/__bpf_tramp_exit() glue is not treated as Tasks-RCU quiescent. Drop the count around the call to the original function: that may run arbitrarily long without sleeping and must not pin a Tasks RCU grace period, and the trampoline frame above it is held by im->pcref rather than by Tasks RCU (see bpf_tramp_image_put()). The fmod_ret early-exit branch and the ip_after_call -> ip_epilogue poke both skip the decrement/increment pair around the original call, so the count stays balanced on every path. The sequence is "mov r11, gs:[current_task]; inc/dec dword [r11 + off]"; r11 is scratch at every emission point and (u32)¤t_task is a valid sign-extended %gs-absolute with the current per-CPU layout, the same form the JIT already uses for this_cpu_off. The image is dynamically allocated text, so the instructions outside the bracketed region are covered by the irq-exit IP check. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/net/bpf_jit_comp.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c index 2853e87797a7..a375c1b7bd50 100644 --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -722,6 +722,31 @@ static void emit_indirect_jump(u8 **pprog, int bpf_reg, u8 *ip) *pprog = prog; } +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). + * + * mov r11, QWORD PTR gs:[current_task] + * inc/dec DWORD PTR [r11 + offsetof(struct task_struct, rcu_tramp_nesting)] + * + * r11 (AUX_REG) is scratch in the trampoline at every point this is emitted. + */ +static void emit_rcu_tasks_tramp_nesting(u8 **pprog, bool enter) +{ +#ifdef CONFIG_TASKS_RCU + u8 *prog = *pprog; + + /* mov r11, gs:[abs32] */ + EMIT2(0x65, 0x4C); + EMIT3(0x8B, 0x1C, 0x25); + EMIT((u32)(unsigned long)¤t_task, 4); + /* inc/dec dword ptr [r11 + disp32] */ + EMIT3(0x41, 0xFF, enter ? 0x83 : 0x8B); + EMIT(offsetof(struct task_struct, rcu_tramp_nesting), 4); + + *pprog = prog; +#endif +} + static void emit_return(u8 **pprog, u8 *ip) { u8 *prog = *pprog; @@ -3610,6 +3635,13 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im /* mov QWORD PTR [rbp - rbx_off], rbx */ emit_stx(&prog, BPF_DW, BPF_REG_FP, BPF_REG_6, -rbx_off); + /* + * From here until the matching decrement before the final return, a + * preemption of this task is not a Tasks RCU quiescent state. The + * instructions above this point are covered by the irq-exit IP check. + */ + emit_rcu_tasks_tramp_nesting(&prog, true); + func_meta = nr_regs; /* Store number of argument registers of the traced function */ emit_store_stack_imm64(&prog, BPF_REG_0, -func_meta_off, func_meta); @@ -3670,6 +3702,13 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im LOAD_TRAMP_TAIL_CALL_CNT_PTR(stack_size); } + /* + * The original function may run for a long time without + * sleeping; do not let it pin a Tasks RCU grace period. The + * trampoline frame above it is held by im->pcref + * (__bpf_tramp_enter()), not by Tasks RCU, across the call. + */ + emit_rcu_tasks_tramp_nesting(&prog, false); if (flags & BPF_TRAMP_F_ORIG_STACK) { emit_ldx(&prog, BPF_DW, BPF_REG_6, BPF_REG_FP, 8); EMIT2(0xff, 0xd3); /* call *rbx */ @@ -3680,6 +3719,7 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im goto cleanup; } } + emit_rcu_tasks_tramp_nesting(&prog, true); /* remember return value in a stack for bpf prog to access */ emit_stx(&prog, BPF_DW, BPF_REG_FP, BPF_REG_0, -8); im->ip_after_call = image + (prog - (u8 *)rw_image); @@ -3741,6 +3781,9 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im if (save_ret) emit_ldx(&prog, BPF_DW, BPF_REG_0, BPF_REG_FP, -8); + /* Remaining instructions are covered by the irq-exit IP check. */ + emit_rcu_tasks_tramp_nesting(&prog, false); + emit_ldx(&prog, BPF_DW, BPF_REG_6, BPF_REG_FP, -rbx_off); EMIT1(0xC9); /* leave */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416867.1645846 (Exim 4.92) (envelope-from ) id 1x51xH-00004y-TO; Fri, 11 Sep 2026 14:10:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416867.1645846; Fri, 11 Sep 2026 14:10:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xH-0008WP-PP; Fri, 11 Sep 2026 14:10:15 +0000 Received: by outflank-mailman (input) for mailman id 1416867; Fri, 11 Sep 2026 14:10:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xG-0008Tg-Vn for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51xG-008fmm-Cd for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:14 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bbd-8faa-0a2a0a5109dd-0a2a4503e874-18 for ; Fri, 11 Sep 2026 16:10:14 +0200 Received: from [209.85.222.173] (helo=mail-qk1-f173.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bc5-fae8-0a2a45030019-d155deadcd88-3 for ; Fri, 11 Sep 2026 16:10:14 +0200 Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-9399daa3c8eso76787585a.1 for ; Fri, 11 Sep 2026 07:10:13 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e80bbab7sm247620785a.34.2026.09.11.07.10.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135813; x=1789740613; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=q0Z6kl89L/mcJKSDFUzFWtYRNb/tGGuag8yv3GYWCr4=; b=hDRH6FkptkFY7seA7FA+CzfUh0fszWEekSFRmK5JJWfmON4+SoA9SEMygdwnpnWJZs JXMqNZ2HNy5MkffJohqDAA6KTYaafqxeBd77MyLrHU3w8dylYf8U99KFlKx0Na2xBM9P VB1aYoZrsxbQdsN9O8fuGhF4tMMQMpRqDhLWCkU687ghQR/HtilJmIU05WBDcs2hAncQ szvHd29hj7vj+GQ67jDZE3DVKhbnvM3Eyy9ao3U+dRvNWGOTuh/sJ8OsGJRIK5Dc2XvX f3czILiZ8C8bRQmGGRLKrILqaZusZbXepAlV0OQmLFRmKsLCABNdcgKIkUR0ldtO2x5x HspQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135813; x=1789740613; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=q0Z6kl89L/mcJKSDFUzFWtYRNb/tGGuag8yv3GYWCr4=; b=Gx9QiVygWmlJfKcunaw+2/UxTOgFPSeh270lqfRj792y3o0Q7hsbDkG28f4UGALNOr xn54U+8GzQvUBHgVVunNn/vz4874ALlgnbyJPps9IRR1mNdbGpQXV0GrdJDNWGkOrgC4 lJpinUiOcpUBhpFBOFeWhVxTPTuczaYvNL/3J8EC1jPijczTpPkCe/Y+1roUZRPaJbcI vmtEEeSDYbEGWsxmoc3C/3K/cQ1Ky1IElllJI2PE3Hoxet+D40dzb4Zmb/V1mph4UMn/ AQLfYAtE/ZR7PT0d6f5jt9MHtLxxl3ROsIFwVZzC4+f8J5KH3kAUPdpNVK3BK3It17ju CxtA== X-Forwarded-Encrypted: i=1; AKwUvBzXVQwSH98q+8N32VHBsnt8ftsuRm3S2hMeuXT9gTmuJ0ZUQQW2mW8B+LrAgLGDQxPSBmm1vxuwPvU=@lists.xenproject.org X-Gm-Message-State: AFuF++m/HrIwpijQ9He3OiqRBG+3sGu0I8kYQicqiNdKpDIiy8lnMhp2 5OoquqHC7IdoLVwlho2rxoL7UMGg4mQIB5nselUby8RcezPOPPD9Axs8PwJf+wrSQcI= X-Gm-Gg: AYBFou29Qqs6x56ks4KAXZs1xVbxu3A+8xPf5hVZOX/amvuZoPSktNwxAtX/fg4mkMe kAvCO8+RaN/oZmAi0zYOj5BIiNdi6TrPc+1Gg2g+m/gxmFLGeaq5OJPaivm16INymyKNgkeugQQ +D4EhLGkXKaCpx+pSO/fUgLP+80wMpaqfceDOfoklErpHdD9duKoFc+QQhcfIrzo8QLbMw7vMUH VQtQMLVMJBmr+bMYoKBGO2xq6AFwed1mfu3FSP3dAxAmfEt839QAHS+g4/9OUK7Yc8w+cnlgJKT RWikp71M7xtBgoTlTc15GqfFRVWaMre6Q6O7WX6XGm1Dcs7KocdlUi15Npp8PXaFN1acujlyDEY YYWS45qx/ptVF9fa+guX4MDYNqlZks44U8pIlMfWomzWlk0QB7MZ79MkqBflAZfQsPv73Bdlfr+ Qm4THu2Sq0SbF/m74QMf6kFx0oGh/RWFp7MhEYVC0iToDJtzjQ/yJY+dfYlwkxzDQ69MlVSn9wY 3w6Zcz52NpcvUIeZanFK0+te8h+p8NdAiJn9DTdBfqaM8dsajDoP2TX X-Received: by 2002:a05:620a:6287:b0:939:6dea:374b with SMTP id af79cd13be357-939ea1af385mr553869585a.47.1789135812492; Fri, 11 Sep 2026 07:10:12 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:47 +0000 Subject: [PATCH RFC v2 09/15] arm64: ftrace: Maintain Tasks RCU trampoline nesting in ftrace_caller MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-9-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=5217; i=josef@toxicpanda.com; h=from:subject:message-id; bh=xqTPn5S4ER1XAZhtIYfJFNG5V6jdP8hXJAwXIfHAJeM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QDdDEdIwM05h7b7JvpgB0Ncpvko1HStiAd9VzLg7h8HjWsQnjthe7VWx1bLRiDUbfVMTbRgUiKe YsgeGrk28wQI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1789135814-6C2E04E9-D183B6A6/0/0 X-purgate-type: clean X-purgate-size: 5219 Bracket the call out to the ftrace_ops callback in ftrace_caller with an increment/decrement of current->rcu_tramp_nesting, using x12/w13 which are scratch there. The read-modify-write is not atomic, but only current modifies the count and every interrupting user is balanced, so nothing is lost. ftrace_caller itself, including the early CALL_OPS direct path and the late direct tail that carry a BPF trampoline address in x17 with the count at zero, is static kernel text: add an ftrace_static_tramp_end marker after ftrace_stub_direct_tramp and provide arch_rcu_tasks_ip_in_trampoline() covering [ftrace_caller, ftrace_static_tramp_end) so the irq-exit check treats a task interrupted anywhere in it as inside a trampoline. The hook is built only under CONFIG_RCU_TASKS_PREEMPT_QS, which arm64 does not select until a later patch. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/arm64/kernel/asm-offsets.c | 3 +++ arch/arm64/kernel/entry-ftrace.S | 35 +++++++++++++++++++++++++++++++++++ arch/arm64/kernel/ftrace.c | 16 ++++++++++++++++ 3 files changed, 54 insertions(+) diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 9c853ed3ceab..f6655a284f18 100644 --- a/arch/arm64/kernel/asm-offsets.c +++ b/arch/arm64/kernel/asm-offsets.c @@ -39,6 +39,9 @@ int main(void) DEFINE(TSK_STACK, offsetof(struct task_struct, stack)); #ifdef CONFIG_STACKPROTECTOR DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary)); +#endif +#ifdef CONFIG_TASKS_RCU + DEFINE(TSK_RCU_TRAMP_NESTING, offsetof(struct task_struct, rcu_tramp_nesting)); #endif BLANK(); DEFINE(THREAD_CPU_CONTEXT, offsetof(struct task_struct, thread.cpu_context)); diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S index 025140caafe7..46a102e7199a 100644 --- a/arch/arm64/kernel/entry-ftrace.S +++ b/arch/arm64/kernel/entry-ftrace.S @@ -14,6 +14,33 @@ #include #ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). The whole + * of ftrace_caller is treated as trampoline text by the irq-exit IP check (see + * arch_rcu_tasks_ip_in_trampoline()), so these only need to bracket the call + * out to ops->func; everything before the increment and after the decrement, + * including the direct-call tails that carry a BPF trampoline address in x17, + * is covered by that. The count is only modified by current and every nested + * user (interrupts) is balanced, so a plain ldr/add/str is sufficient. + */ + .macro rcu_tasks_tramp_enter, tsk:req, tmp:req +#ifdef CONFIG_TASKS_RCU + mrs \tsk, sp_el0 + ldr \tmp, [\tsk, #TSK_RCU_TRAMP_NESTING] + add \tmp, \tmp, #1 + str \tmp, [\tsk, #TSK_RCU_TRAMP_NESTING] +#endif + .endm + + .macro rcu_tasks_tramp_exit, tsk:req, tmp:req +#ifdef CONFIG_TASKS_RCU + mrs \tsk, sp_el0 + ldr \tmp, [\tsk, #TSK_RCU_TRAMP_NESTING] + sub \tmp, \tmp, #1 + str \tmp, [\tsk, #TSK_RCU_TRAMP_NESTING] +#endif + .endm + /* * Due to -fpatchable-function-entry=2, the compiler has placed two NOPs before * the regular function prologue. For an enabled callsite, ftrace_init_nop() and @@ -94,6 +121,8 @@ SYM_CODE_START(ftrace_caller) stp x29, x30, [sp, #FREGS_SIZE] add x29, sp, #FREGS_SIZE + rcu_tasks_tramp_enter x12, w13 + /* Prepare arguments for the tracer func */ sub x0, x30, #AARCH64_INSN_SIZE // ip (callsite's BL insn) mov x1, x9 // parent_ip (callsite's LR) @@ -111,6 +140,8 @@ SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) bl ftrace_stub // func(ip, parent_ip, op, regs) #endif + rcu_tasks_tramp_exit x12, w13 + /* * At the callsite x0-x8 and x19-x30 were live. Any C code will have preserved * x19-x29 per the AAPCS, and we created frame records upon entry, so we need @@ -178,6 +209,10 @@ SYM_CODE_START(ftrace_stub_direct_tramp) SYM_CODE_END(ftrace_stub_direct_tramp) #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */ +/* End of [ftrace_caller, ...) for arch_rcu_tasks_ip_in_trampoline(). */ +SYM_CODE_START(ftrace_static_tramp_end) +SYM_CODE_END(ftrace_static_tramp_end) + #else /* CONFIG_DYNAMIC_FTRACE_WITH_ARGS */ /* diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c index e1a3c0b3a051..1b7ac2afed0d 100644 --- a/arch/arm64/kernel/ftrace.c +++ b/arch/arm64/kernel/ftrace.c @@ -17,6 +17,22 @@ #include #include +#ifdef CONFIG_RCU_TASKS_PREEMPT_QS +extern void ftrace_static_tramp_end(void); + +/* + * See rcu_tasks_ip_in_trampoline(). ftrace_caller and ftrace_stub_direct_tramp + * are core kernel text but must be treated as trampolines: a task preempted in + * them may be carrying an ops pointer (x11) or a direct-call BPF trampoline + * address (x17) whose lifetime is guarded only by Tasks RCU. + */ +bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip) +{ + return ip >= (unsigned long)ftrace_caller && + ip < (unsigned long)ftrace_static_tramp_end; +} +#endif + #ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS struct fregs_offset { const char *name; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416872.1645855 (Exim 4.92) (envelope-from ) id 1x51xM-0000YZ-5A; Fri, 11 Sep 2026 14:10:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416872.1645855; Fri, 11 Sep 2026 14:10:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xM-0000YQ-1F; Fri, 11 Sep 2026 14:10:20 +0000 Received: by outflank-mailman (input) for mailman id 1416872; Fri, 11 Sep 2026 14:10:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xK-0000RU-IK for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51xJ-00E9ea-VR for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:17 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bc8-2eae-0a2a0a5409dd-0a2a4508aad8-6 for ; Fri, 11 Sep 2026 16:10:17 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bc8-f659-0a2a45080019-4a7de6ccdbbc-3 for ; Fri, 11 Sep 2026 16:10:17 +0200 Received: by mail-qk2-f12.google.com with SMTP id af79cd13be357-93910cadeb7so101377585a.0 for ; Fri, 11 Sep 2026 07:10:17 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e80bc225sm248184485a.36.2026.09.11.07.10.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135816; x=1789740616; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=9b8kkjvSg0tb+ScPvKP3GAz1Pld5wxO+feqfkbC4jq4=; b=Rj9mt4LQ2JA6Xo4EOfH7Dmn5m/KK4gpg+wsjE+eMhrbWc3EpkvLwbEvQNE/n/oxmG7 TYK/EbytyhK7UWgiL4ohzwpHh8/Nvd073WGK5915Ke1w6hJVVk4+Fb8V9F7UHJZW0KIO Ob+zuUs2aBAj0RsV84BMa4WJM5h2aKXZ+3aa+omYxHGQDOvZ/dt/EUcgghMTht6G0QS4 RqydB7uKeJNoyJTW7zslPDyWAEk2nD2BpidYcrX5i5xMU6qvsPGLX5Ms9VoHO2cdbnkp 30dsNY4cDKuavBkgSqn8LEIfzIE+gcvlqEkUIv27X7AL1Bj+kTO6MO0jAwTjTTrgxNEW 7SIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135816; x=1789740616; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9b8kkjvSg0tb+ScPvKP3GAz1Pld5wxO+feqfkbC4jq4=; b=jCqd3Gbx7FqWEpmAMkqZ7WdcK7EpZO+kOL3dB9DmRIJ82iOG2tlN0lYUMNsvhjH+q0 gkds3gJZDcZE4y3/Tckt8psy6eWsKkSf/Wfd0ZNInDNE6W3adTOgia4FAmMULOZHyeYM ImjqTxzzI1oJHKzN36Vejf/FVgASnCfaVTgXPlcpgP7xHZnlU7P2Qg95/kZIC4BR9oX9 AO2f2AVS6i3B6KeggnT/A9w7K0JKRwLTor0oKWUaTE2k/cKpZlZBhexvIFtIckmKvlvk dp7L8I4aif1RY3QDf65Cb9D+bszkVlQXJ/rKbhmYX/BTFyjj0kTCZ5JU9AioDE2/2baj +KMQ== X-Forwarded-Encrypted: i=1; AKwUvBzgws0/fITlbaXXEdO5d3UUOaDh76hyOhz9y8cimnImLUZrBsOyfa+BiCspVsidq/iUf1bHJn1Hcfw=@lists.xenproject.org X-Gm-Message-State: AFuF++no2XfN07ToszKML4OBzwkb5/VHodgHSAkcZJ8vBpIgHwczO/SV 8IehoemYWud12bQqu9nJPCoQx4tpXqtgvp8Sc/W+6vVwMsg0nFca8x83TPerH62afjU= X-Gm-Gg: AYBFou0GHVt59hQYYdE2iaKbsEn9m8fJ2a9YFXBvMfJe0ixbs/ZavMMAk6d3ufp6tD2 B3Bnzat8JmLn/5Iu1nhrszlfkNX73Mmp8NcrIGT1fHneF00W5ANXlgiHxYBAoL6T/SlRGupLKGu tH9fH0jXReMzzvNKWos/wlH2iRf1e2nD5SCyhd4zopIJkugsGcypZH96cFxTD81Pk6pF4M2OEIz PqV7TlsaaktWtEEY8Rj16jmjHzvvHo1rHlGIPf9ub4eJeiZ5ZnIZbuxMztyR5/YFP9JUtdR0Zbg L4eRvgxM/RY+TBH2/rikpMTDlzkl80CsMbdaZ1a6m6Q6KMa0fbpnU7XdRVpJC3h53DgEYGB+Pgw 7gKwcVXWBKboH6e+DpjdaHYYhAo1WtuZtoFRNlE5TZhh+XV+bziJnEP/hPjWpUGoRaQy8CCndBa z45Bs1kTqhNx/lBTYCi82ZiD4MiCJxqSwcA5Kp6tZgIwUVPdjMPJTGYPHkGV+Mdjzrn1aD6+PNp W3kVi5M+WOktG2vR6j50KDFpkAPFyKVk6tye+rVY9gvhzTl8pqAhhoO X-Received: by 2002:a05:620a:4103:b0:939:7f14:ebc6 with SMTP id af79cd13be357-939ea036d6cmr589566285a.3.1789135815998; Fri, 11 Sep 2026 07:10:15 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:48 +0000 Subject: [PATCH RFC v2 10/15] bpf, arm64: Maintain Tasks RCU trampoline nesting in the BPF trampoline MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-10-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135736; l=4364; i=josef@toxicpanda.com; h=from:subject:message-id; bh=MVjrbMDjnAqQ8aHx7Jc4sWMH68fI2crdoTABU++vCCI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLeRHDw//rEtUsP8CEBuDuvfZIDhzXHIZMrHDgrgPTpnzRVCinhLEvplAgnBDiwNcYGB3QeJu+7 QOU1v97vhHA4= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1789135817-CC57487B-8EF62256/0/0 X-purgate-type: clean X-purgate-size: 4366 Same scheme as x86: emit "mrs x10, sp_el0; ldr/add|sub/str w11" to bump current->rcu_tramp_nesting after the callee-saved registers are stored and to drop it before they are restored, and release it around the call to the original function, which im->pcref protects and which must not pin a Tasks RCU grace period. x10/x11 are scratch at every emission point; the fmod_ret cbnz target lies after the decrement/increment pair around the original call, and the ip_after_call nop follows the re-increment, so the count is balanced on every path. BUILD_BUG_ON guards the LDR/STR immediate range for the task_struct offset. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/arm64/net/bpf_jit_comp.c | 46 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index c18e005a41db..5c9a7bde5cc9 100644 --- a/arch/arm64/net/bpf_jit_comp.c +++ b/arch/arm64/net/bpf_jit_comp.c @@ -2591,6 +2591,34 @@ static void emit_arena_arg_conv(struct jit_ctx *ctx, u8 dst, u8 src, bool nullab emit(A64_SUB(0, dst, src, base_lo), ctx); } +/* + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). + * + * mrs x10, sp_el0 + * ldr w11, [x10, #offsetof(struct task_struct, rcu_tramp_nesting)] + * add/sub w11, w11, #1 + * str w11, [x10, #...] + * + * x10/x11 are scratch in the trampoline at every point this is emitted. + */ +static void emit_rcu_tasks_tramp_nesting(struct jit_ctx *ctx, bool enter) +{ +#ifdef CONFIG_TASKS_RCU + const int off = offsetof(struct task_struct, rcu_tramp_nesting); + const u8 tsk = A64_R(10), cnt = A64_R(11); + + BUILD_BUG_ON(off & 3 || off >= SZ_16K); /* LDR/STR (imm12, scaled) */ + + emit(A64_MRS_SP_EL0(tsk), ctx); + emit(A64_LDR32I(cnt, tsk, off), ctx); + if (enter) + emit(A64_ADD_I(0, cnt, cnt, 1), ctx); + else + emit(A64_SUB_I(0, cnt, cnt, 1), ctx); + emit(A64_STR32I(cnt, tsk, off), ctx); +#endif +} + static void save_args(struct jit_ctx *ctx, int bargs_off, int oargs_off, const struct btf_func_model *m, const struct arg_aux *a, bool for_call_origin, bool is_struct_ops, u64 arena_base) @@ -2854,6 +2882,13 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, emit(A64_STR64I(A64_R(19), A64_SP, regs_off), ctx); emit(A64_STR64I(A64_R(20), A64_SP, regs_off + 8), ctx); + /* + * From here until the matching decrement in the epilogue, a preemption + * of this task is not a Tasks RCU quiescent state. The instructions + * above this point are covered by the irq-exit IP check. + */ + emit_rcu_tasks_tramp_nesting(ctx, true); + if (flags & BPF_TRAMP_F_CALL_ORIG) { /* for the first pass, assume the worst case */ if (!ctx->image) @@ -2898,12 +2933,20 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, if (flags & BPF_TRAMP_F_CALL_ORIG) { /* the original func takes kernel addresses, never converted ones */ save_args(ctx, bargs_off, oargs_off, m, a, true, is_struct_ops, 0); + /* + * The original function may run for a long time without + * sleeping; do not let it pin a Tasks RCU grace period. The + * trampoline frame above it is held by im->pcref + * (__bpf_tramp_enter()), not by Tasks RCU, across the call. + */ + emit_rcu_tasks_tramp_nesting(ctx, false); /* call original func */ emit(A64_LDR64I(A64_R(10), A64_SP, retaddr_off), ctx); emit(A64_ADR(A64_LR, AARCH64_INSN_SIZE * 2), ctx); emit(A64_RET(A64_R(10)), ctx); /* store return value */ emit(A64_STR64I(A64_R(0), A64_SP, retval_off), ctx); + emit_rcu_tasks_tramp_nesting(ctx, true); /* reserve a nop for bpf_tramp_image_put */ im->ip_after_call = ctx->ro_image + ctx->idx; emit(A64_NOP, ctx); @@ -2945,6 +2988,9 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, if (flags & BPF_TRAMP_F_RESTORE_REGS) restore_args(ctx, bargs_off, a->regs_for_args); + /* Remaining instructions are covered by the irq-exit IP check. */ + emit_rcu_tasks_tramp_nesting(ctx, false); + /* restore callee saved register x19 and x20 */ emit(A64_LDR64I(A64_R(19), A64_SP, regs_off), ctx); emit(A64_LDR64I(A64_R(20), A64_SP, regs_off + 8), ctx); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416879.1645864 (Exim 4.92) (envelope-from ) id 1x51xQ-00016P-NP; Fri, 11 Sep 2026 14:10:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416879.1645864; Fri, 11 Sep 2026 14:10:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xQ-00015f-J0; Fri, 11 Sep 2026 14:10:24 +0000 Received: by outflank-mailman (input) for mailman id 1416879; Fri, 11 Sep 2026 14:10:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xO-0000wU-SD for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51xO-00E9jx-9A for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:22 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bc8-2eae-0a2a0a5409dd-0a2a4508aad8-24 for ; Fri, 11 Sep 2026 16:10:22 +0200 Received: from [209.85.160.173] (helo=mail-qt1-f173.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bcd-f659-0a2a45080019-d155a0add494-3 for ; Fri, 11 Sep 2026 16:10:22 +0200 Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-530d93a18ecso6610011cf.0 for ; Fri, 11 Sep 2026 07:10:21 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530e0aaddbdsm2707391cf.2.2026.09.11.07.10.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135820; x=1789740620; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=32pR0m9lJbbl6oefWflQ2FM2YWt9ii7Ub9HEHMaojiA=; b=apA+io3LP4tTkE0/8idyRY/CsZPEM+gLWLMt90L/dcCJoY6mQvcXHcB1ICQ/9nSZy6 //bHjKBqnmJesfpChZyz1IWKPokPH0yAJ0xlKxeACz8V9Vu15Mu0UufXqFBblFCAywtQ iBND8BNzcajrX+hyIOEWAGDQ1rFKnaOwxOcrP8jJhlbU47lD8jjJRbOvI3g75ilCX9ub ssf2Cbm4m1lFQVcadpLLy5CR2ZhIIVIaX6vmucbKYoewtCW+xMS2xm/xqxYvplyLxhy6 1Rhf3HJ/3eaEEDzUWIQT1AsmbsZiU2zwZeAW63Sd50+Ahgt30a03y4XLIugjHjH5q1PF PKig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135820; x=1789740620; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=32pR0m9lJbbl6oefWflQ2FM2YWt9ii7Ub9HEHMaojiA=; b=cBiByLKaUw7hWPSjtdXU+TJIrq3p7a9gfI8OB4eTIb/ZfrBmy+Ndj4zXU4Z2SPHnOg pbqjm5GWh5/paUAhaloTNxmmHbUFgJgXvL6yRBWhUe3U8lquwMsxBKWVPZAh6CV8PEud kVnkmrn4g/gQVagsZ6DMSN0Q5U7NZvbT2FdPEASlIerhPaKOXU2wyWaVMWCZNTKzXOMx ZpsiYOmoA7iYjuSQqb8Xbv9nd/sr03mNruhTuOyyQyuWheKwwSDTt9c68PR6ftxisgpg mwieakoS6lA7ikrRiuiqsfvtTKfyh3JgB6TlY9OAcdfkEpqlW5zxH6hN8smb4EBBXm7H KLjA== X-Forwarded-Encrypted: i=1; AKwUvBynjaFeEqNZ8GWOfA04S0himKxpAiKDFvy8KoPZHxbyVYWpQlu7kquxNOpJqz8lcTP/i/fVeIk0mUA=@lists.xenproject.org X-Gm-Message-State: AFuF++nieLA8Jo5HPuIpEc8HPYCfK/3nhHqDPqttKcQQ5R++2yTeVnD0 Ymah6iyWDOo8e7bBnIfIzp3QFgVLzKQMrHrD5xjSO6yBF1VkWaBsTtZp1nh2g3AJ+Lo= X-Gm-Gg: AYBFou3UZE1dbhw4Z/ME4B/0d3WfwdMM+RYhWPDmjVVoqGKnEDDuvyLVIEhTq033L6j R5Bdy+9waxdYcMz6pMQM8ZFLS6qxZdD3Z4eVbZeVogMbb/QR03AFMo04A61q2w2pWBHj5++VvvM ONCHajPgofqqZ6enh+nTqMg+73WhnGVzt0NpT8fBp8fFko8iQaFVxNYrZJo6P5s7eSBWwMaskTg yNM3MkkkMk6qZOkhfB06qmmJHRwo/dcEsn1Nxo6yshB+GSuDoyWeGYk4JU432tMxbypYHNv82SL 02dn9DqoRZcRXnoZYZnMY9ORrDSGwW8NWdFXoXxxW9L1KZsDjw+WwPS91n/15j7+1p7h2F+zseG K0F+/8TVkEcWXFFXX4k6qfGqROHreEpD9M3Lb6nYMJ8RD7tiSiYwpb7pXY4oLnTrVwE2V4xq9Mp I7/UzuCEv42R4bCNIWpqJFY+0RwKVrQ0S+wCyOXzc3Hit3fihIuml3vSyCA1gYFAOOpnmedIaGt 4KFDWbynX+Jdr1UU8rR7rc9yJv9OLCAIKWvAaitxosFj5C1aV6lHi0AIGjm226dLJQ= X-Received: by 2002:a05:622a:4114:b0:530:da2a:757 with SMTP id d75a77b69052e-530da2a1198mr24113211cf.33.1789135818762; Fri, 11 Sep 2026 07:10:18 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:49 +0000 Subject: [PATCH RFC v2 11/15] samples: ftrace: Maintain Tasks RCU trampoline nesting in direct-call trampolines MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-11-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135737; l=10811; i=josef@toxicpanda.com; h=from:subject:message-id; bh=hPcqGdFxo+b+ijS7jNB+8GMowmEDvopzKnpNmpphVrY=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QKhN0qkThHUh5I4+Grit8p3XEg0LAgV/aMtyHMka/HOmaDw0JgyPUhuISBQoEJ4d9x0FD6DquBp sygcZlr+QrA8= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1789135822-D654487B-7C342C75/0/0 X-purgate-type: clean X-purgate-size: 10813 Follow the register_ftrace_direct() contract in the sample modules: on x86-64 and arm64, have each hand-written trampoline increment current->rcu_tramp_nesting before calling its C handler and decrement it before returning, via a small shared samples/ftrace/ftrace-direct.h. %r11 and x12/w13 are used as scratch; both are caller-saved, non-argument registers and therefore dead on entry to and exit from an fentry trampoline. The header pulls in the generated asm-offsets.h only on those two architectures, since it is not generally safe to include from C (PPC32's TASK_SIZE and arm64's TRAMP_VALIAS clash with the C definitions; the latter is worked around locally with push_macro/pop_macro). Other architectures get empty macros and are unchanged. Assisted-by: LLM Signed-off-by: Josef Bacik --- samples/ftrace/ftrace-direct-modify.c | 9 ++++ samples/ftrace/ftrace-direct-multi-modify.c | 9 ++++ samples/ftrace/ftrace-direct-multi.c | 5 +++ samples/ftrace/ftrace-direct-too.c | 5 +++ samples/ftrace/ftrace-direct.c | 5 +++ samples/ftrace/ftrace-direct.h | 64 +++++++++++++++++++++++++++++ 6 files changed, 97 insertions(+) diff --git a/samples/ftrace/ftrace-direct-modify.c b/samples/ftrace/ftrace-direct-modify.c index 164d9dd6fd92..eb8230fa4242 100644 --- a/samples/ftrace/ftrace-direct-modify.c +++ b/samples/ftrace/ftrace-direct-modify.c @@ -2,6 +2,7 @@ #include #include #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -73,7 +74,9 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " call my_direct_func1\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp1, .-my_tramp1\n" @@ -85,7 +88,9 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " call my_direct_func2\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp2, .-my_tramp2\n" @@ -141,11 +146,13 @@ asm ( " .globl my_tramp1\n" " my_tramp1:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #16\n" " stp x9, x30, [sp]\n" " bl my_direct_func1\n" " ldp x30, x9, [sp]\n" " add sp, sp, #16\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp1, .-my_tramp1\n" @@ -153,11 +160,13 @@ asm ( " .globl my_tramp2\n" " my_tramp2:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #16\n" " stp x9, x30, [sp]\n" " bl my_direct_func2\n" " ldp x30, x9, [sp]\n" " add sp, sp, #16\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp2, .-my_tramp2\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-multi-modify.c b/samples/ftrace/ftrace-direct-multi-modify.c index b03766c6217b..c8f1062e5d1a 100644 --- a/samples/ftrace/ftrace-direct-multi-modify.c +++ b/samples/ftrace/ftrace-direct-multi-modify.c @@ -2,6 +2,7 @@ #include #include #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -77,10 +78,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func1\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp1, .-my_tramp1\n" @@ -92,10 +95,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func2\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp2, .-my_tramp2\n" @@ -154,6 +159,7 @@ asm ( " .globl my_tramp1\n" " my_tramp1:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -162,6 +168,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp1, .-my_tramp1\n" @@ -169,6 +176,7 @@ asm ( " .globl my_tramp2\n" " my_tramp2:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -177,6 +185,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp2, .-my_tramp2\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-multi.c b/samples/ftrace/ftrace-direct-multi.c index 3fe6ddaf0b69..bc6a88dd4ffc 100644 --- a/samples/ftrace/ftrace-direct-multi.c +++ b/samples/ftrace/ftrace-direct-multi.c @@ -3,6 +3,7 @@ #include /* for handle_mm_fault() */ #include +#include "ftrace-direct.h" #include #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include @@ -56,10 +57,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -101,6 +104,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -109,6 +113,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-too.c b/samples/ftrace/ftrace-direct-too.c index bf2411aa6fd7..247e418644a2 100644 --- a/samples/ftrace/ftrace-direct-too.c +++ b/samples/ftrace/ftrace-direct-too.c @@ -3,6 +3,7 @@ #include /* for handle_mm_fault() */ #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -61,6 +62,7 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " pushq %rsi\n" " pushq %rdx\n" @@ -70,6 +72,7 @@ asm ( " popq %rdx\n" " popq %rsi\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -110,6 +113,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #48\n" " stp x9, x30, [sp]\n" " stp x0, x1, [sp, #16]\n" @@ -119,6 +123,7 @@ asm ( " ldp x0, x1, [sp, #16]\n" " ldp x2, x3, [sp, #32]\n" " add sp, sp, #48\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct.c b/samples/ftrace/ftrace-direct.c index 5368c8c39cbb..9e1964baf28b 100644 --- a/samples/ftrace/ftrace-direct.c +++ b/samples/ftrace/ftrace-direct.c @@ -3,6 +3,7 @@ #include /* for wake_up_process() */ #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -54,9 +55,11 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + RCU_TASKS_TRAMP_ENTER " pushq %rdi\n" " call my_direct_func\n" " popq %rdi\n" + RCU_TASKS_TRAMP_EXIT " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -97,6 +100,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + RCU_TASKS_TRAMP_ENTER " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -104,6 +108,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + RCU_TASKS_TRAMP_EXIT " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct.h b/samples/ftrace/ftrace-direct.h new file mode 100644 index 000000000000..d0313f33f47f --- /dev/null +++ b/samples/ftrace/ftrace-direct.h @@ -0,0 +1,64 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef _SAMPLES_FTRACE_DIRECT_H +#define _SAMPLES_FTRACE_DIRECT_H + +#include + +/* + * A direct-call trampoline is entered with no lock, refcount or RCU marker + * held; only Tasks RCU keeps it (and, for a module, its text) alive while a + * task is inside it or preempted in something it called. On architectures + * that select ARCH_HAS_RCU_TASKS_PREEMPT_QS a preemption is a Tasks RCU + * quiescent state unless current->rcu_tramp_nesting is non-zero, so the + * trampoline must raise it before calling out and drop it afterwards, exactly + * like the ftrace and BPF trampolines do. See rcu_tasks_trampoline_enter() + * and register_ftrace_direct(). The instructions before the increment and + * after the decrement are covered by ftrace_direct_mark_module(). + * + * These expand to instruction strings for use inside the samples' asm() + * trampolines. The scratch register is caller-saved and not an argument + * register, so it is dead on entry to and exit from an fentry trampoline. + * + * The generated asm-offsets.h is only pulled in on the architectures that need + * it here: it is not generally safe to include from C (e.g. PPC32's TASK_SIZE + * and arm64's TRAMP_VALIAS clash with the C definitions), which is why the + * samples themselves guard their own include of it. + */ +#if defined(CONFIG_TASKS_RCU) && defined(CONFIG_X86_64) + +#include + +#define RCU_TASKS_TRAMP_ENTER \ + " movq %gs:current_task(%rip), %r11\n" \ + " incl " __stringify(TASK_rcu_tramp_nesting) "(%r11)\n" +#define RCU_TASKS_TRAMP_EXIT \ + " movq %gs:current_task(%rip), %r11\n" \ + " decl " __stringify(TASK_rcu_tramp_nesting) "(%r11)\n" + +#elif defined(CONFIG_TASKS_RCU) && defined(CONFIG_ARM64) + +/* arm64's asm-offsets.h redefines TRAMP_VALIAS from . */ +#pragma push_macro("TRAMP_VALIAS") +#undef TRAMP_VALIAS +#include +#pragma pop_macro("TRAMP_VALIAS") + +#define RCU_TASKS_TRAMP_ENTER \ + " mrs x12, sp_el0\n" \ + " ldr w13, [x12, #" __stringify(TSK_RCU_TRAMP_NESTING) "]\n" \ + " add w13, w13, #1\n" \ + " str w13, [x12, #" __stringify(TSK_RCU_TRAMP_NESTING) "]\n" +#define RCU_TASKS_TRAMP_EXIT \ + " mrs x12, sp_el0\n" \ + " ldr w13, [x12, #" __stringify(TSK_RCU_TRAMP_NESTING) "]\n" \ + " sub w13, w13, #1\n" \ + " str w13, [x12, #" __stringify(TSK_RCU_TRAMP_NESTING) "]\n" + +#else + +#define RCU_TASKS_TRAMP_ENTER +#define RCU_TASKS_TRAMP_EXIT + +#endif + +#endif /* _SAMPLES_FTRACE_DIRECT_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416881.1645869 (Exim 4.92) (envelope-from ) id 1x51xR-0001A9-1D; Fri, 11 Sep 2026 14:10:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416881.1645869; Fri, 11 Sep 2026 14:10:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xQ-00019m-T5; Fri, 11 Sep 2026 14:10:24 +0000 Received: by outflank-mailman (input) for mailman id 1416881; Fri, 11 Sep 2026 14:10:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xP-000126-UB for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51xP-003z4F-Ao for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:23 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bbd-8faa-0a2a0a5109dd-0a2a4503e874-34 for ; Fri, 11 Sep 2026 16:10:23 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bce-fae8-0a2a45030019-4a7de68ca2dc-3 for ; Fri, 11 Sep 2026 16:10:23 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-90cdfc9b6ebso8656256d6.2 for ; Fri, 11 Sep 2026 07:10:22 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e80dc002sm248697485a.39.2026.09.11.07.10.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135821; x=1789740621; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=twz7P/UgrzFqFrDTfXn+06wBF94/L3aT/pnjRwe1Smk=; b=hoKiHyXPpEdkAmxkaFLqesjtR7ZQTrvQdjPkcZNR2MKL+ZkiSoGBpTPqZbdNTNwKJe D1mk9tr4j21JeS2/g60tA5fTHO+SWy0WC6ATq+R2dYE/VTp92lHRsvbhb7wzLLrEkyiP UvCGMGPi0RkLupFO1BvJNnlLCJNV4j92QLFmujcFVywhap9RezF4G7eUtIpWMfM1ZNn/ LvVThs6oA6R9+3f1XIkqZdToX+DTLyRGWOG9lnrmiRq5pK1Mw9LCo+AeZSNeKsOnqWhm DSLExGaCdjDOj+I9H37tFOg0ssDBV8+eBZsus/0l9CqIYYZ1zD+R8WaokLogLBLML2/S SNhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135821; x=1789740621; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=twz7P/UgrzFqFrDTfXn+06wBF94/L3aT/pnjRwe1Smk=; b=itZ6LFyZ9k/OpGr3Y9vuO1FtANIKLB08wWXFfd+ujqRsLzLeLhFFNoOwWKWzDcQ/0B WsDhpk1AVrIsuKxDVnZCLBKgZRGXEaqCS+pDxUWnPu8IGi6kNURRN7iko0+D2OhlV+Z0 0x+MFPdhBrm3WEUvSfyyJ+Bb9D+EfglggMaa6l87gx57F/2y0CycEd9PrCB1CO8WTBr8 7eCIFSGxvNxtFGwU7eYkWn4wEridfvVCuu1Uc1V3S0ypGcU6PamUjKqeuzehglWeDsXW sZmpwOy16J9b3EJiBiT9lQAiEn6ATtW3DF8MUV4sHZV/jLDor/iEtdoUxyx48NoxsJlP GGdQ== X-Forwarded-Encrypted: i=1; AKwUvBwmJ3b2VFfQbjAPqM/r1pP2ky1CM6FesUNQya5rNMQreWnquiaWBb9UOuwtombDxNVlpF2FdNSqVDw=@lists.xenproject.org X-Gm-Message-State: AFuF++k2EarBBY1xLrViVI6a6VskujzpljK72HLhKMeHdZNKyfJCVF6d aqBrKQDTrH7UZZk+N52mUkhttcWKOp8uCCCjnJ3M6t11PURuJU1TiE2DlairAcBiGDQ= X-Gm-Gg: AYBFou2yeglpB9bXMKdYpMqHqeRfZrzIOjQdSr9XKp0o1+/bVGWMlW9OtVCQGGmobTj 42N3b785dA5FabbnrncXJnW3rP6Ziyvvvg+a5v5rjeyGzgBjYGEH6CvS+BHnlBIUEJNXx67R6OT wB1upluLiPPZFA6lvn5NvpYS5Q2CocMa/c7VpB6xhMGtW0RUgu5wpL+Cbf38L9I1Nchhz5Tffx6 iodXjU4onac+rppWXx/Z1sIKB1YdeIhqVpL7eUjloBVbsh59p/nqBvCUB36KhoJtKJZa9WrOpie iBn84UbPjwlgBpUjvC9bAtYDGslK9nayhMZkKfggAqLvJZlvB+wo7qb0oF9XN+7AYERp1+J30wS Hit7hfrIR1sY/7XaXkqaDo7JMvaoi5nD4xvZ2jgxdYRRMfKhdz8QhsBKspiFwfnxkicl65ZC1lB COV2QU1rD4gTQCFE6FmSNJepz6ecSRSFeUKHhykQamIsjY0v+yVM9i/oWQInr3qOgZDJdwcEma8 bmKXtK52DNyb+dkXZPV51yWSx1wT64VI/mn1Ta4EJmN7N+wTAqGtfNg X-Received: by 2002:a05:620a:690e:b0:939:639b:2e1f with SMTP id af79cd13be357-939ea04922amr525733885a.7.1789135821311; Fri, 11 Sep 2026 07:10:21 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:50 +0000 Subject: [PATCH RFC v2 12/15] rcutorture: Bracket Tasks RCU readers with trampoline nesting MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-12-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135737; l=1492; i=josef@toxicpanda.com; h=from:subject:message-id; bh=c9hUQ9kAAl2b2IbncqDZq1k2ejJxuc1g83EyvfAIkis=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QDpeCdAsuDTbsWwi8oqAy5KN1IjS7Ye/ysM/qLEJAJ0SGsvHuCkttXUFQ2AlX09A0IwbwXmGUQ4 qHaGMzc7/Vgg= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1789135823-74C884E9-3CC7C0AF/0/0 X-purgate-type: clean X-purgate-size: 1494 rcutorture's tasks flavor models a Tasks RCU reader as "any stretch of kernel code", and rcu_read_delay() deliberately preempts inside it to check that a preemption does not end the read-side critical section. Once preemption outside a trampoline becomes a quiescent state that model no longer matches what Tasks RCU protects, and the readers would report false too-short grace periods. Have tasks_torture_read_lock()/unlock() raise and drop current->rcu_tramp_nesting so the reader models a trampoline, which is the thing Tasks RCU actually guards; the deliberate preemption inside it then continues to be, correctly, not a quiescent state. Assisted-by: LLM Signed-off-by: Josef Bacik --- kernel/rcu/rcutorture.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index 794937e13e7c..df6dd708cea7 100644 --- a/kernel/rcu/rcutorture.c +++ b/kernel/rcu/rcutorture.c @@ -1144,11 +1144,17 @@ static struct rcu_torture_ops trivial_preempt_ops = { static int tasks_torture_read_lock(void) { + /* + * Model a trampoline: with CONFIG_RCU_TASKS_PREEMPT_QS a preemption is + * otherwise a quiescent state and rcu_read_delay() preempts on purpose. + */ + rcu_tasks_trampoline_enter(); return 0; } static void tasks_torture_read_unlock(int idx) { + rcu_tasks_trampoline_exit(); } static void rcu_tasks_torture_deferred_free(struct rcu_torture *p) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416887.1645882 (Exim 4.92) (envelope-from ) id 1x51xU-0001sK-Cj; Fri, 11 Sep 2026 14:10:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416887.1645882; Fri, 11 Sep 2026 14:10:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xU-0001s0-7K; Fri, 11 Sep 2026 14:10:28 +0000 Received: by outflank-mailman (input) for mailman id 1416887; Fri, 11 Sep 2026 14:10:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xS-0001hh-NR for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51xS-00E9jx-4H for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:26 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bc8-2eae-0a2a0a5409dd-0a2a4508aad8-44 for ; Fri, 11 Sep 2026 16:10:26 +0200 Received: from [209.85.219.44] (helo=mail-qv1-f44.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bd1-f659-0a2a45080019-d155db2cdd3c-3 for ; Fri, 11 Sep 2026 16:10:25 +0200 Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-9106f4c3a4dso10575136d6.1 for ; Fri, 11 Sep 2026 07:10:25 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e80801c0sm248912485a.30.2026.09.11.07.10.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135824; x=1789740624; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=WT/8H/cMArsJRoufbqdgzsmAKwU5NTozjyFMdjWjsc8=; b=anGmWfFonPzDEefSdiBc9W3ik5uit4hPee0xyjX872GmSFIJ4dwhJVSjlQpk0lyZSU IWV9D/MeRs20JLM3j7EmhhX0wKaya/nBKbT2b8s6W2E7Qk0sOtVUPaqVyxlP929xQo/u fJDM6zrVPjAlYiTz3UZhiVP4gtZtHqeo5vaf4jdNNYAVUGVLT7nwuWEC4VHOo/ifnyRH hyOtnhN+ZrareoF5beOWWR7Iih0H8gCKQ4M70FhkIqUarfPVs9S1LIewFsdz03ZLCweR MolMXrNBeuyKioRU5Wu0FcJg4xhRpiUcbpXyrJCcXp39JsyI4Td666b+VuJa8+I+iS9m Pwpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135824; x=1789740624; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=WT/8H/cMArsJRoufbqdgzsmAKwU5NTozjyFMdjWjsc8=; b=qPdLUVYkPBgyWwaMbWy+jEFGb7B3jfvwH+p5AwPPndMUVRpKA2abIVjDbLhESvC4yX 5m8hkFYg3dK8N99VRkmi1YWa4hw8Tq8Z6106XX9Cmf/o22s7jzsuDb/cOBFbgZK5WUrL BL9mnWUdFXDhw0epa1voabMcGk+p9pQj+rTNT0MRqki9VGxPfvv7nEyPzpVBGU4gCt+Z CFvu3xhDT+RFx66flfC/NHosiSo5Ul2DoZA3LTWx9Exa6QJW+vUzFF+rnfkSQQAREN4i yMQjNi982Dzy8B85pj7WjiKb88MsmNPbAGx+PL4b4Jt313GRTXO52k8flbn5O3oERakG FjNA== X-Forwarded-Encrypted: i=1; AKwUvBxyrU5Q8/U+Rq2RwJvGkVP0xf4dL4Wq0BCmMwwJMwjf8J95k74siJ4i9WeivUSLxRePXf/Hk3jDQ+w=@lists.xenproject.org X-Gm-Message-State: AFuF++nv7lVeOIw2E3WVhctAcFJFfFDn0WrbScFVxf6S4wLUjXuhdAlP kbrDvaLIuC0dbvl+JMV/cQI9sk1CSxwW1c6UjqTAC+Z0lo0ZFnX69k2RgXP6MQWHGaw= X-Gm-Gg: AYBFou2CWr0spVROHhL+fYp5UDoky4ke+bjQN8sFoc/ujlz9HRM6yVo3F3otmAE83Ma RV5feoJKfIv6DumysC/xeoHY7M+BNMs1Qg/343ReWzJl0pmw4FreGSyTDyWXImaJBJNAvoi0Dhn EexRlpWP/LE0d6wIxcullzL35Dqh9Epv0qDRTGdFwObzNbikYS4xhYnrS2AViZlPW1iHSIDuX86 r0W2amYRoeGEv2UDYuupEdCaR8OE1F/a7WrbD4A1VMpQBj3JfGSbBVD6sprnlQNYodYKiBlkFww 5iMbp16NRDAVEAWssi5wZtrHGQ5N2ZXaSmKe+U161L63KKZJ9xASC2pmMBDsu6L31cHUO+Zcl5x KGgLJPed5vx2Xk+jiaE/Wc5+OOzRpfh2zZylH1hhs5mVn31nsf9D89KboxTa3SDLSh7/duMDRXE NQBOPHzUh9WSRTM4LxZ8cM+EmHqvaJPV0gzlifdkSeL2LuXK/IMknx6EqJ9wfzVUblrjcB8Sna4 eo1Vn41WHwfZC3VFdf9stINPkZq0FVj9jhmoWdqcB91iRXaKdVKRYUi X-Received: by 2002:a05:620a:444d:b0:939:cab7:8651 with SMTP id af79cd13be357-939ea0cff3cmr508758285a.21.1789135824016; Fri, 11 Sep 2026 07:10:24 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:51 +0000 Subject: [PATCH RFC v2 13/15] rcu-tasks: Treat preemption outside trampolines as a quiescent state MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-13-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135737; l=13377; i=josef@toxicpanda.com; h=from:subject:message-id; bh=782IiL7t8C+T7tHuP+fr7fuNKyJIY5LyrSPvir4aYJ4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLUZnTIeq2lPY+NhGtgUM19AxK92AiGBaR4ReDiwvRRgaRGOQrROuHTyqXvXkEa5pxrRzrRbB/J mvbDi+9g+vAw= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1789135826-CDB4987B-972B65A0/0/0 X-purgate-type: clean X-purgate-size: 13379 Tasks RCU only accepts a voluntary context switch, usermode or idle as a quiescent state, because a task that was preempted may be sitting in a trampoline whose text is about to be freed. On PREEMPT_LAZY kernels, where cond_resched() is a no-op and CPU-bound kernel threads only ever lose the CPU through preemption, that means any long-running kthread or kworker stalls every synchronize_rcu_tasks() caller -- BPF and LSM program detach and DYNAMIC ftrace_ops teardown via ftrace_shutdown(), and kprobe (un)registration via the jump optimizer, which waits under kprobe_mutex, text_mutex and cpus_read_lock() -- for its entire run, unless someone sprinkles cond_resched_tasks_rcu_qs() into it. A cgroup writeback worker draining a large cgwb for eleven minutes was enough to back 40+ tasks up behind trampoline_mutex and trip the hung-task panic. With the previous patches, every Tasks-RCU-protected trampoline on x86-64 and arm64 (ftrace_caller and its dynamic copies, BPF trampoline images, the optprobe template, out-of-line direct trampolines) holds current->rcu_tramp_nesting across its call-out, and the irq-exit preemption path holds it across preempt_schedule_irq() whenever the interrupted IP is somewhere the counter cannot cover: trampoline entry/exit instructions and other dynamically allocated text, the static ftrace stubs and x86 return thunks on the way into a direct-call target, modules hosting their own direct trampolines. The kprobe jump-optimization window, which is ordinary text a task may have been parked in before the kprobe existed, is instead re-checked against the recorded irq-preemption IP at each decision (rcu_tasks_irq_ip_holds()). A task that is context-switched with the count at zero and no such IP therefore cannot be inside, called from, or about to resume into anything Tasks RCU protects. So let rcu_tasks_classic_qs() clear the holdout flag on a preemption too when rcu_tramp_nesting is zero, on architectures that select ARCH_HAS_RCU_TASKS_PREEMPT_QS, and select it for x86-64 and for arm64 with DYNAMIC_FTRACE_WITH_ARGS. A running holdout is already poked via rcu_request_urgent_qs_task(), which makes the next tick set NEED_RESCHED; the resulting preemption -- from irq exit, or synchronously at the next preempt_enable() -- now retires it, so a Tasks RCU grace period is bounded by roughly a tick plus the longest preempt-disabled section instead of by the longest stretch without a voluntary schedule(). Other architectures keep the voluntary-only rule. Update the Tasks RCU comments, Documentation/RCU (Requirements.rst, checklist.rst) and the FORCE_TASKS_RCU help text to match. Cost: one load of current plus an inc/dec per trampoline entry and exit, and on irq-exit preemption one core_kernel_text() check plus, with OPTPROBES, MAX_OPTIMIZED_LENGTH-1 lockless kprobe hash lookups. Not covered: x86-32 and the other GENERIC_IRQ_ENTRY architectures, and return_to_handler / the rethook trampoline, whose C callees take the ftrace recursion lock before touching any ops. Tested under QEMU (x86-64, PREEMPT_LAZY, PREEMPT_RCU=n, PROVE_RCU, with and without PREEMPT_DYNAMIC) against a kthread spinning in-kernel for 30s with the function tracer, an ftrace kprobe, an optimized kprobe and fentry/fexit programs live: synchronize_rcu_tasks() 29.7s -> 0.1-0.3s, ftrace_shutdown() of a DYNAMIC ops 27s -> 0.2-0.8s, the ftrace-direct sample modules load/fire/unload in ~2.5s each during the spin, no warnings. arm64 is build-tested only. Assisted-by: LLM Signed-off-by: Josef Bacik --- .../RCU/Design/Requirements/Requirements.rst | 28 ++++++++++++++++------ Documentation/RCU/checklist.rst | 8 ++++++- arch/arm64/Kconfig | 1 + arch/x86/Kconfig | 1 + include/linux/rcupdate.h | 15 +++++++++++- kernel/rcu/Kconfig | 7 +++--- kernel/rcu/tasks.h | 15 ++++++++---- 7 files changed, 59 insertions(+), 16 deletions(-) diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 8101fe6229d5..428b5e8f4b4e 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -2739,13 +2739,27 @@ userspace execution also delimit tasks-RCU read-side critical sections. Idle tasks are ignored by Tasks RCU, and Tasks Rude RCU may be used to interact with them. -Note well that involuntary context switches are *not* Tasks-RCU quiescent -states. After all, in preemptible kernels, a task executing code in a -trampoline might be preempted. In this case, the Tasks-RCU grace period -clearly cannot end until that task resumes and its execution leaves that -trampoline. This means, among other things, that cond_resched() does -not provide a Tasks RCU quiescent state. (Instead, use rcu_softirq_qs() -from softirq or rcu_tasks_classic_qs() otherwise.) +Note well that, by default, involuntary context switches are *not* +Tasks-RCU quiescent states. After all, in preemptible kernels, a task +executing code in a trampoline might be preempted. In this case, the +Tasks-RCU grace period clearly cannot end until that task resumes and its +execution leaves that trampoline. This means, among other things, that +cond_resched() does not provide a Tasks RCU quiescent state. (Instead, +use rcu_softirq_qs() from softirq or rcu_tasks_classic_qs() otherwise.) + +Architectures that select ``CONFIG_ARCH_HAS_RCU_TASKS_PREEMPT_QS`` relax +this: there, every trampoline whose lifetime Tasks RCU guards (the ftrace +and BPF trampolines, optprobe slots, out-of-line ftrace direct-call +trampolines) increments ``current->rcu_tramp_nesting`` before calling out +and decrements it before returning, and the irq-exit preemption path +covers the few instructions the counter cannot (see +rcu_tasks_ip_in_trampoline() and rcu_tasks_irq_ip_holds()). A task that +is preempted with that count at zero is therefore known not to be in, or +called from, any trampoline, and such a preemption *is* a Tasks-RCU +quiescent state. The obligation moves to the trampolines: anything that +relies on synchronize_rcu_tasks() to protect code a task may be preempted +in must maintain the count (see register_ftrace_direct()), or Tasks RCU +will not wait for it on those architectures. The tasks-RCU API is quite compact, consisting only of call_rcu_tasks(), synchronize_rcu_tasks(), and diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 4b30f701225f..28df48fecac7 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -252,7 +252,13 @@ over a rather long period of time, but improvements are always welcome! a. If the updater uses synchronize_rcu_tasks() or call_rcu_tasks(), then the readers must refrain from executing voluntary context switches, that is, from - blocking. + blocking. On architectures that select + CONFIG_ARCH_HAS_RCU_TASKS_PREEMPT_QS an involuntary + context switch is also a quiescent state unless + current->rcu_tramp_nesting is non-zero, so a reader + there is a trampoline that maintains that count (see + rcu_tasks_trampoline_enter()), not an arbitrary + stretch of kernel code. b. If the updater uses call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then the diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b5a51b0ef944..0e6c1e0b236f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -44,6 +44,7 @@ config ARM64 select ARCH_HAS_PREEMPT_LAZY select ARCH_HAS_PTDUMP select ARCH_HAS_PTE_SPECIAL + select ARCH_HAS_RCU_TASKS_PREEMPT_QS if DYNAMIC_FTRACE_WITH_ARGS select ARCH_HAS_HW_PTE_YOUNG select ARCH_HAS_SETUP_DMA_OPS select ARCH_HAS_SET_DIRECT_MAP diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 15fd9ec5ecac..0a6427019345 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -99,6 +99,7 @@ config X86 select ARCH_HAS_PREEMPT_LAZY select ARCH_HAS_PTDUMP select ARCH_HAS_PTE_SPECIAL + select ARCH_HAS_RCU_TASKS_PREEMPT_QS if X86_64 select ARCH_HAS_HW_PTE_YOUNG select ARCH_HAS_NONLEAF_PMD_YOUNG if PGTABLE_LEVELS > 2 select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64 diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 4cfe096d624f..9509f99ec965 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -210,6 +210,11 @@ bool arch_rcu_tasks_ip_in_trampoline(unsigned long ip); * preemption and rcu_tasks_irq_ip_holds() checks it at every quiescent-state * decision, locally and from the grace-period kthread. * + * With both in place, on architectures that select + * ARCH_HAS_RCU_TASKS_PREEMPT_QS, a preemption with rcu_tramp_nesting == 0 is + * a Tasks RCU quiescent state, and a CPU-bound kernel thread no longer needs + * to volunteer one via cond_resched_tasks_rcu_qs(). + * * Only current writes the count and only current (or an interrupt on the same * CPU) reads it, so plain accesses suffice. */ @@ -241,9 +246,17 @@ static __always_inline void rcu_tasks_note_irq_ip(unsigned long ip) WRITE_ONCE(current->rcu_tasks_irq_ip, ip); } +#ifdef CONFIG_RCU_TASKS_PREEMPT_QS +#define rcu_tasks_preempt_is_qs(t) \ + (!READ_ONCE((t)->rcu_tramp_nesting) && !rcu_tasks_irq_ip_holds(t)) +#else +#define rcu_tasks_preempt_is_qs(t) false +#endif + # define rcu_tasks_classic_qs(t, preempt) \ do { \ - if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ + if (READ_ONCE((t)->rcu_tasks_holdout) && \ + (!(preempt) || rcu_tasks_preempt_is_qs(t))) \ WRITE_ONCE((t)->rcu_tasks_holdout, false); \ } while (0) void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func); diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index 999f8228a13d..8e7c94329105 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -94,9 +94,10 @@ config FORCE_TASKS_RCU default n help This option force-enables a task-based RCU implementation - that uses only voluntary context switch (not preemption!), - idle, and user-mode execution as quiescent states. Not for - manual selection in most cases. + that uses only voluntary context switch (not preemption, unless + the architecture selects ARCH_HAS_RCU_TASKS_PREEMPT_QS and the + task is outside any trampoline), idle, and user-mode execution + as quiescent states. Not for manual selection in most cases. config NEED_TASKS_RCU bool diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 1b9fe1bfa591..bab08a666dc0 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -905,7 +905,10 @@ static void rcu_tasks_wait_gp(struct rcu_tasks *rtp) // // Simple variant of RCU whose quiescent states are voluntary context // switch, cond_resched_tasks_rcu_qs(), user-space execution, and idle. -// As such, grace periods can take one good long time. There are no +// With CONFIG_RCU_TASKS_PREEMPT_QS, a preemption taken while the task is +// not inside a trampoline (current->rcu_tramp_nesting == 0, see +// rcu_tasks_trampoline_enter()) is a quiescent state as well; without it, +// grace periods can take one good long time. There are no // read-side primitives similar to rcu_read_lock() and rcu_read_unlock() // because this implementation is intended to get the system into a safe // state for some of the manipulations involved in tracing and the like. @@ -1263,8 +1266,11 @@ static void tasks_rcu_exit_stall(struct timer_list *unused) * period elapses, in other words after all currently executing rcu-tasks * read-side critical sections have completed. call_rcu_tasks() assumes * that the read-side critical sections end at a voluntary context - * switch (not a preemption!), cond_resched_tasks_rcu_qs(), entry into idle, - * or transition to usermode execution. As such, there are no read-side + * switch, cond_resched_tasks_rcu_qs(), entry into idle, transition to + * usermode execution, or, with CONFIG_RCU_TASKS_PREEMPT_QS, a preemption + * taken outside any trampoline (current->rcu_tramp_nesting == 0, see + * rcu_tasks_trampoline_enter()); otherwise a preemption is not a + * quiescent state. As such, there are no read-side * primitives analogous to rcu_read_lock() and rcu_read_unlock() because * this primitive is intended to determine that all tasks have passed * through a safe state, not so much for data-structure synchronization. @@ -1286,7 +1292,8 @@ EXPORT_SYMBOL_GPL(call_rcu_tasks); * executing rcu-tasks read-side critical sections have elapsed. These * read-side critical sections are delimited by calls to schedule(), * cond_resched_tasks_rcu_qs(), idle execution, userspace execution, calls - * to synchronize_rcu_tasks(), and (in theory, anyway) cond_resched(). + * to synchronize_rcu_tasks(), (in theory, anyway) cond_resched(), and, + * with CONFIG_RCU_TASKS_PREEMPT_QS, preemption outside any trampoline. * * This is a very specialized primitive, intended only for a few uses in * tracing and other situations requiring manipulation of function -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:10:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:10:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416889.1645891 (Exim 4.92) (envelope-from ) id 1x51xW-0002N4-UN; Fri, 11 Sep 2026 14:10:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416889.1645891; Fri, 11 Sep 2026 14:10:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xW-0002Mf-Ni; Fri, 11 Sep 2026 14:10:30 +0000 Received: by outflank-mailman (input) for mailman id 1416889; Fri, 11 Sep 2026 14:10:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x51xU-0001tQ-MJ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:10:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x51xU-00E9hv-1A for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:10:28 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40bd1-bab6-0a2a0a5309dd-0a2a4507eb58-18 for ; Fri, 11 Sep 2026 16:10:27 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40bd2-b4ea-0a2a45070019-4a7de6ccb1e8-3 for ; Fri, 11 Sep 2026 16:10:27 +0200 Received: by mail-qk2-f12.google.com with SMTP id af79cd13be357-939109fafd7so84824085a.2 for ; Fri, 11 Sep 2026 07:10:27 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939f19f94a1sm128350685a.42.2026.09.11.07.10.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135826; x=1789740626; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=tDcwMwF0CqD/SLUwt7lLP/Zeny+NN6n073A4kvHv5Ng=; b=ldlwM9LknSW5s91+utQnw8haPcBkzUQwVCYpexSYpdysuyUoBhA5aNj/d//rNxFlrc Mtxs5kn4ka5ZAOoF6mSfrpumoQJs8wprgCu3vksS+XIucwlD9u8VdbG5ATXkiabgQm2n dC7aTB9IqleGO+iTBOWUZ1c4Tr12gVUM+P/2B7tGbEDIaBVZ4XNZjZrkNplTe4HcGBUE iWoIv9ERsUaDgEe/1bMWaBVQJv1AyObF5CFRqFou9C+EsuR4ozkS4rnXxnYkuEEwnyQM sGypcIDLHXHfRRLwheLQ/9oH2GZadTEUq+Vv9Xk4TPs0VFHGGCTxsz7pU4IjFLRaas8P zUpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135826; x=1789740626; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tDcwMwF0CqD/SLUwt7lLP/Zeny+NN6n073A4kvHv5Ng=; b=OebYF1IHmeZZuCLDwsPfNL15/6PrdFPapIu89AXoY4VrP/p7pKkVfSxjTsKOvfjnqU xKDdqTXaEhypvCYEd2WeT1JFoRAAabuH0oJHk/yFvHIChRDKps57pOH0D2g1oCck2s/j 9Yva2+h0RyVjijy0YtSZIXxULfyFcJf/h9IlpFAlCNDnr5tQtrxE7OtJxSZzIRjMljoq wBU9SsO+SWhw5KHFpMDFRoxcFChLdpFAOy112CR6XhTMzDA8AFG6s0PXzVc5biaGVw5g UYmKHH9Td1qjsRP8b7J3LGgbX7FUNqb5+Ihs/nrQpoUe1E01O82l4FTMXkhO6GRvP/tm coaA== X-Forwarded-Encrypted: i=1; AKwUvBw69S/KWZfMYspSpUtP00XBzlmfqnleN0S5aH2/olS+ALvwM9RY6/tg8nXHQMriUWeGtUkK2nfx9fM=@lists.xenproject.org X-Gm-Message-State: AFuF++mZihsd1UzXcYq6i3MPZ+4Fp3JB96FW4q0YDtlxBOafXOc0aNFx y4IAG4E6iq4s8D2mh1tYEOCMjm4/nATzS1lhFNfB7kmkYjH+HL9X3qb7aHv1VNE1yaI= X-Gm-Gg: AYBFou0S/JTnbCJX8vjaqp7Z1bBlzbru4UZq3p35bWy2hWXjOXWiAkCjrFqLAIXIfTe htmjczC0gp/S4UgUtvzZhTZHib1rluelbFErDyLa7O+M308NuyMzZKdpj1GMbWTB70l5jHfqeJ0 GfWvHNKCrR99p8cYCC3PecoAwLeOqMMbcr7MrnTO0esT4pXujYakjr7/+97mOEPD3m78R/xFx+X R7KcYV8iQ2CTyAmlssdyP3DIn5JLcLF5EJ2iwI9Wk1uFmc+ff7WYn72if43mx1rD0W4eBmTQd6a LTrLPprv0iNP5c9lCVb72RKLd3DRqyt+yzmT09rMUS359zP9cXWpAJVJKkL3kewtFnfDK8SjhM9 lfdnXRubRkxgnSTD305zx+o6wUiDVGpxX4f6VCrJHTDaecZ0CTjjCI/iY/c5/ETAjTz69TyW+bv EKsxuRIId+p0shjBskJaEtoU9ehFCnsb7j4paXm58Dpt0OMsfjp5JO/EzOPMEHs7BUJP53uvEAH nlecEN8aYGPA3JImSXwq8gwwwMdLh/ALrqyPZ1Jlm709mh0LywPVlgz X-Received: by 2002:a05:620a:2a01:b0:92e:6c15:24cd with SMTP id af79cd13be357-939ea096ac1mr525489385a.15.1789135826040; Fri, 11 Sep 2026 07:10:26 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:52 +0000 Subject: [PATCH RFC v2 14/15] rcu-tasks: Retire switched-out tasks with no trampoline nesting at scan time MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-14-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135737; l=3915; i=josef@toxicpanda.com; h=from:subject:message-id; bh=CHfEJf4XyY3zn8RyomjOM2Uc3mVFT7MUycrwjg2RabY=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QCsPahyd7Oix02uJZsqv3hNKRWBYJbR9ZWsmEzIdYJha+M3Xp7J5xDeZFd/3etSxBmrSG0gewnR pnh9QNzgnXwY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ef75cf/1789135827-37CD7AE4-0D596C34/0/0 X-purgate-type: clean X-purgate-size: 3917 The previous patch lets a task report its own quiescent state when it is preempted with rcu_tramp_nesting == 0, but a task that was preempted before the grace period started and simply has not run since is still listed as a holdout until it next passes through __schedule(). As Paul pointed out, the grace-period kthread can settle that case itself. For a task that is switched out, task_call_func() pins it and !task_curr() tells us it left the CPU through __schedule(), whose locking orders its last rcu_tramp_nesting and rcu_tasks_irq_ip updates before ours; a task preempted from irq exit inside trampoline text has the count held non-zero across the switch by irqentry_preempt(). So a pinned, not-running task with a zero count is neither in nor called from a trampoline, and with rcu_tasks_irq_ip_holds() also clear (the kprobe jump window, which can open after the task was switched out) it is quiescent now, whether or not it ever runs again. Check that in rcu_tasks_pertask() so such tasks never become holdouts, and in check_holdout_task() so they are retired on the next scan. This is the only remote reader of the count, and it only reads it for a pinned, switched-out task, so the trampoline-side increment and decrement stay plain on every preemption model, PREEMPT_RT included. Only under CONFIG_RCU_TASKS_PREEMPT_QS; other architectures are unchanged. Suggested-by: Paul E. McKenney Assisted-by: LLM Signed-off-by: Josef Bacik --- kernel/rcu/tasks.h | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index bab08a666dc0..ba432bd922e2 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1014,10 +1014,39 @@ static bool rcu_tasks_is_holdout(struct task_struct *t) return true; } +#ifdef CONFIG_RCU_TASKS_PREEMPT_QS +/* task_call_func() callback: is @t switched out with no trampoline in play? */ +static int rcu_tasks_switched_out_clean(struct task_struct *t, void *arg) +{ + /* + * With @t pinned, !task_curr() means it last left the CPU through + * __schedule(), so its rcu_tramp_nesting and rcu_tasks_irq_ip are + * stable and ordered before the rq lock we hold. A task preempted + * from irq exit inside trampoline text has the count held non-zero + * across the switch by irqentry_preempt(), so zero here means neither + * in nor called from a trampoline; rcu_tasks_irq_ip_holds() covers the + * one case that can become true after the task was switched out (a + * kprobe jump-optimization window). Both clear: already quiescent, + * whether or not it ever runs again. + */ + return !task_curr(t) && !READ_ONCE(t->rcu_tramp_nesting) && + !rcu_tasks_irq_ip_holds(t); +} + +/* Is @t, right now, switched out somewhere that is a quiescent state? */ +static bool rcu_tasks_preempted_qs(struct task_struct *t) +{ + return task_call_func(t, rcu_tasks_switched_out_clean, NULL); +} +#else +static bool rcu_tasks_preempted_qs(struct task_struct *t) { return false; } +#endif + /* Per-task initial processing. */ static void rcu_tasks_pertask(struct task_struct *t, struct list_head *hop) { - if (t != current && rcu_tasks_is_holdout(t)) { + if (t != current && rcu_tasks_is_holdout(t) && + !rcu_tasks_preempted_qs(t)) { get_task_struct(t); t->rcu_tasks_nvcsw = READ_ONCE(t->nvcsw); WRITE_ONCE(t->rcu_tasks_holdout, true); @@ -1181,6 +1210,7 @@ static void check_holdout_task(struct task_struct *t, if (!READ_ONCE(t->rcu_tasks_holdout) || t->rcu_tasks_nvcsw != READ_ONCE(t->nvcsw) || !rcu_tasks_is_holdout(t) || + rcu_tasks_preempted_qs(t) || (IS_ENABLED(CONFIG_NO_HZ_FULL) && !is_idle_task(t) && READ_ONCE(t->rcu_tasks_idle_cpu) >= 0)) { WRITE_ONCE(t->rcu_tasks_holdout, false); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:13:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:13:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1416975.1645899 (Exim 4.92) (envelope-from ) id 1x520h-00055q-9a; Fri, 11 Sep 2026 14:13:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1416975.1645899; Fri, 11 Sep 2026 14:13:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x520h-00055j-70; Fri, 11 Sep 2026 14:13:47 +0000 Received: by outflank-mailman (input) for mailman id 1416975; Fri, 11 Sep 2026 14:13:45 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x520f-00055d-B6 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:13:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x520e-00Bjlq-5E for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:13:44 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa40c94-bab6-0a2a0a5309dd-0a2a4503bd0c-6 for ; Fri, 11 Sep 2026 16:13:44 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa40be2-fae8-0a2a45030019-4a7de6ccc63e-3 for ; Fri, 11 Sep 2026 16:10:43 +0200 Received: by mail-qk2-f12.google.com with SMTP id d75a77b69052e-52fb76798a2so3010961cf.1 for ; Fri, 11 Sep 2026 07:10:43 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530ca460a32sm20960711cf.9.2026.09.11.07.10.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 07:10:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789135842; x=1789740642; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=qrCxqh0lkRJGK/msNx4sQvIno2OGGDXwsMjyZ+inPRg=; b=OsJImIP36Vypq1b/g1wbfpsjf6PKhTW1X2TEUcb+1pw17b/cng3a8yPlxxnK2wfQGm PvPSwVkTEF4ar2W9+vDojLPDweXYRUAvU8dYPFEPXvyvdYxWVZKPhoHKhPWEPqzMJhln cZ6qMA+2G2S1E0QIuQgc1CMVre1/7bSc9wOZlfUuGgJHHAdRdBzUlmTvSaqnypo0NK1h PYAJlqfCOn3C0hWsa7KiSo4qGVfQE7o9K6XWgl8kHJjD4b/R/PLmy3EmJ8cH+KDuXWMt iBQJROQKtnSEBUbkLZU+eQMFUxVWFhsJ6gzJZe8sAB5tIFZ8WafOc/HzWMLxICBKqHML rteg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789135842; x=1789740642; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=qrCxqh0lkRJGK/msNx4sQvIno2OGGDXwsMjyZ+inPRg=; b=a6f5MmGZ95hnC5PNqN4CpEvP/leS7VcfGWde7epqwS2VazK+YhbQ3N3rPYS1hIf3j7 HG4wRDHWfzX1a6l20yIxSRjhOWmuZR7QLTiQROKsw/ONYjM8dY+7y75kaf+5NsqrVFIC mwr2V8zVAKGMRmjxn/ydy4Ix2b6BDXp5RvCfds/MSxZn9nP8HWHEHL4vAqwnCgHcnFHj N8sY/lhB+Eo9sPZIIomeBvG6rcaMuMcbDLilmyqEpQowLrsk1r2i0Dcv9uTZQt/dstKL WFqo7TVHI4jUakKPMLD9ud+VsPoBoYFw3wtBs3/J9qACrG/5CUKclrJmwZqnbg8FVnby 7fXw== X-Forwarded-Encrypted: i=1; AKwUvBwtygxQkIMe9ZXkMAeNmMHdK/X76wt+pVIZr6VtqJlPyx9bQ/3evyHe6J2J6UMUGZSu7pVcDrQ8TME=@lists.xenproject.org X-Gm-Message-State: AFuF++lN66LCuBwzLHVKW/niJAtjv6mqZPIOGPV08XvVr5nKoNnngSrN veuDI5ozFGCsukN05eY4RBdRh96TCnZRyU+JbeRPoFgN8aF57FGfdw3doOsKDRKPzUc= X-Gm-Gg: AYBFou1dRS1VAGtwLqjOE4Sk9hsfem7Pm6ADjSj0TsQzcqgMqD5+m+5s2r9KrhAMrSr fr6+nZPPlambx4fn9ts3p1AdAGbZBToLgiuwkqEPZXT03ChriADKA0JXOLRR3q0ga7QRgIClThN Kv/nEOlcF4ckfFoWvCCVxQacdi0QZzHv0P0aT6NSLsKHfM6++52u30KNwVf3394AMenYsdOM/Eo HVbpjjbj/Ew1X5czaZb64h67LsIyZp9iBFhc1bU5abIS5biQ/lnWNJa89MR9Q+feErWAjaqyCAU BmRW1iIiHyhdv7OJfkTTiP0g5wa/JcvB/KTD5eSpK5coFo/8tCoZ3abjnNwzEeUpExrFG3WQwlF iMQmg4Mf2G3RCfWUImBML3T5VX40Ve/i1pZXd9IBMGP1ra0UAvyORQE0Dig3TD/Kt2EIWFjZFSO JPLUmd+nKW0JbVTgOe1zhPQha1L8g9jUJsKRtNFy81h6ID1BCsyQ4rdTVXdrzPpOtWvvnW5Aqwn VLHf1lGldbqZiAkSkzckvSpJWclxHeE1/gAH79fE+++mm0t6DqBdONb X-Received: by 2002:a05:622a:53c5:b0:51c:b98c:f772 with SMTP id d75a77b69052e-530c86f6195mr51379741cf.15.1789135827987; Fri, 11 Sep 2026 07:10:27 -0700 (PDT) From: Josef Bacik Date: Fri, 11 Sep 2026 14:08:53 +0000 Subject: [PATCH RFC v2 15/15] rcu-tasks: Kick running holdouts through the scheduler MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260911-b4-rcu-tasks-preempt-qs-v2-15-eaaa61ed2da4@toxicpanda.com> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789135737; l=1790; i=josef@toxicpanda.com; h=from:subject:message-id; bh=K9+ZKIgsGRgsc959M4tS0rMKOB/eZlOXTQ8Ho0gK2m4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QFxu9w6oKo935Kq6bYpzSj4sd/pud6qAfpTImYrmpDnci7BPIoYh09XWotebu7q/uE6z/VGg6k/ nk0bYtqCcqAg= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1789135843-7488A4E9-B8660194/13/0 X-purgate-type: clean X-purgate-size: 1792 A holdout that is running on a CPU with nothing else runnable is only preempted if the tick acts on rcu_request_urgent_qs_task()'s flag, and there may be no tick. Now that a preemption outside a trampoline is a quiescent state, have check_holdout_task() call resched_cpu() on a running holdout as well, so the scheduler IPIs it and it goes through __schedule() and reports (or, if it is inside a trampoline, does not report) its own state with purely local ordering. Nothing reads a running task's rcu_tramp_nesting remotely. Only under CONFIG_RCU_TASKS_PREEMPT_QS; other architectures are unchanged. Suggested-by: Paul E. McKenney Assisted-by: LLM Signed-off-by: Josef Bacik --- kernel/rcu/tasks.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index ba432bd922e2..02d2592ab7a3 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1038,8 +1038,18 @@ static bool rcu_tasks_preempted_qs(struct task_struct *t) { return task_call_func(t, rcu_tasks_switched_out_clean, NULL); } + +/* Make a running holdout pass through __schedule() soon, tick or no tick. */ +static void rcu_tasks_kick_running(struct task_struct *t) +{ + int cpu = task_cpu(t); + + if (task_curr(t) && cpu_online(cpu)) + resched_cpu(cpu); +} #else static bool rcu_tasks_preempted_qs(struct task_struct *t) { return false; } +static void rcu_tasks_kick_running(struct task_struct *t) { } #endif /* Per-task initial processing. */ @@ -1219,6 +1229,7 @@ static void check_holdout_task(struct task_struct *t, return; } rcu_request_urgent_qs_task(t); + rcu_tasks_kick_running(t); if (!needreport) return; if (*firstreport) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:29:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:29:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417010.1645909 (Exim 4.92) (envelope-from ) id 1x52FU-0008A7-FV; Fri, 11 Sep 2026 14:29:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417010.1645909; Fri, 11 Sep 2026 14:29:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52FU-0008A0-Cu; Fri, 11 Sep 2026 14:29:04 +0000 Received: by outflank-mailman (input) for mailman id 1417010; Fri, 11 Sep 2026 14:29:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x52FT-00089u-PO for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:29:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52FT-00ECNC-6I for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:29:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4102f-8faa-0a2a0a5109dd-0a2a4504cc28-0 for ; Fri, 11 Sep 2026 16:29:03 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4102f-b57f-0a2a45040019-4a7de48ca8ea-3 for ; Fri, 11 Sep 2026 16:29:03 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f9f0b1fso160762966b.2 for ; Fri, 11 Sep 2026 07:29:03 -0700 (PDT) Received: from [172.19.143.248] (IW396200.net.t-com.hr. [195.29.234.54]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2965c56183sm86227066b.3.2026.09.11.07.29.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 07:29:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789136943; x=1789741743; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=G+Su9/ororVSrSvSKFxvSUCr8vqUu4bBOy683FkbG3Y=; b=NRcRUfI5ZMBPiiuRWG3i4AZa9awH2PTFIY5mmTD4VlREdzlH3DRreL1LkWimwLInFq appzzZHfTUEMxaWtYpWZ+o2EA9xmPS0u4SFAoU4SwhQRfOlDNcJPN+OP9cT7LLnjkAes d0t2dXZ8k8UbuV5IteEiMmQo7yAVq5LZ9t84J9Vt9pcXCWvYWBQbzI8OZtbZt9Un35Je i8C0q8mhnYnnGuEbTgJpL9I+9LvlZfeO0PUB442nY6PniBMgV97TjObQaXFEJFIFHzmq 9khgvqnvpAhXsdwInbzsEkGZ1PTwTB/IW4ch0j0bXxP8gGHR/hz5Zga11jr40X9plHx6 P2lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789136943; x=1789741743; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=G+Su9/ororVSrSvSKFxvSUCr8vqUu4bBOy683FkbG3Y=; b=CatNtUtqDO9dqYGNZO45epdfZ50U24tuRdH0P1u9uetpc19R6b573lqWSOyJ96WMA0 MM/mIGeT1pb7J22mjRDw8UorRYN+U2AnZ9F3oiS07SvHUuCZKuOi5u5D87JYTA9dn7N5 fu1t7ykC1hueHhNQJi5/9kVbiT8G6thZkzoAr2m+OrS0Auw7uDJ4kdGwAfHw5Veb17zg UAHlxNb8b/TV0ERx6VLpZ4aXkLF7gc+61ynj7OhBccMhDmZuRgDUGeu6/7BmEXnGdKiG d6GV83zeivJrestIWgqAgfyFws3SSpXqOvH0jG6U7G8FdfBj/u3mEnY/spDS8xQzi8Hx ob0Q== X-Forwarded-Encrypted: i=1; AKwUvBx1CGGxYo3lmCDGUCYk30gebLeQrqHtUSBPjkTaMlPUoYmnXad4Hhrf80BmLYH17GnVlUziMMDrzX8=@lists.xenproject.org X-Gm-Message-State: AFuF++kvIqhHDThjzaElPujFPElS1LqNRGBo4uF1s2kAbb2aTJaClVqD F6ItQa4Jy+LcBayy2xk+x32PTbhowQR0HIs//Jsd8XiN34v7nuOwCl5q X-Gm-Gg: AYBFou2iLsV+CqVG1yKTR+xL4syFAFIMr8S5P5x/Wn9rqK68XosZ++DMcN67ybVe/T5 o2n7PvatzYkBgDstGat4JKX70L+5WUe91R6r4a0g2bqxkbdItrApM3eeoyx/Lv33z0wW+FJ8htz kmy8rHPlSb150sWVUkZaxRn0D1s4YguHuAg4GtkByshXC3zz3pPsVOcpnR6P7+Hv33FrG55HXVW mJi5qDTE2IuiBYma5KUV4LvVykjQm+E0l5z6WXRjFiFV3cZySNg6RcnwIHYQSI+h6MsCG7BWa/G KgdBFtCponeOVQTPh6OretpAS6W+ZsDruurQ/nrzMNie67dwfpokH6XxE7eLT4SbeUdNy1onG4I hUdgrOiN80Orgk5ZhAI8LhOuPfNa85TlauOKyE+B7AeJJLYML/7JLClQHITsEXU4sNNVHEHkX9L CdkaM+1sisx4JOBu3TBX7ZfENSlvWzRqEq2eP1yPa8RYEBrCojd5v4s1I5pCnzPFCPsF7T0ntT8 abSPLcaFFQtAjsIjCZr1V60CDxgqeJ3 X-Received: by 2002:a17:906:c103:b0:c25:58e:83ff with SMTP id a640c23a62f3a-c29666203f5mr346374266b.10.1789136942481; Fri, 11 Sep 2026 07:29:02 -0700 (PDT) Message-ID: <5332f8e9-e745-43e3-8928-1d2e425ea567@gmail.com> Date: Fri, 11 Sep 2026 16:29:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/39] xen/riscv: add guest memory read helper To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <895ad4e5-37cd-4a1e-bc49-9a69ab00a920@gmail.com> <36c57293-1448-4283-ac85-5507d9cc637a@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <36c57293-1448-4283-ac85-5507d9cc637a@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1789136943-C20D5B50-9259D9E0/10/73395122804 X-purgate-type: spam X-purgate-size: 4093 On 9/11/26 4:00 PM, Jan Beulich wrote: > On 11.09.2026 15:57, Oleksii Kurochko wrote: >> >> >> On 9/10/26 5:28 PM, Jan Beulich wrote: >>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>> @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, >>>> return copy_guest(buf, gpa, len, GPA_INFO(d), >>>> COPY_to_guest | COPY_gpa); >>>> } >>>> + >>>> +/* >>>> + * Read machine word from guest memory >>>> + * >>>> + * @guest_addr: Guest address to read >>>> + * @read_insn: Flag representing whether we are reading instruction >>>> + * @trap: Output pointer to trap details if something went wrong during read >>>> + * >>>> + * The hlv/hlvx instructions translate guest_addr through the live >>>> + * vsatp/hgatp CSRs, so the read is only meaningful for the address >>>> + * space of the currently running vCPU. >>>> + * >>>> + * At most two halfwords are fetched when @read_insn is true, i.e. encodings >>>> + * wider than 32 bits are not supported. Such an encoding cannot be completed >>>> + * by calling this function again at @guest_addr + 4: the length check is >>>> + * applied to the first halfword read, which would then be a continuation of >>>> + * the instruction rather than its opcode. It is up to the caller to reject >>>> + * anything that is neither a 16- nor a 32-bit encoding. >>>> + */ >>>> +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, >>>> + struct trap_info *trap) >>>> +{ >>>> + /* >>>> + * Poison the result: if the very first access faults, the fixup skips >>>> + * over the loads without writing it. Callers must check trap->scause. >>>> + */ >>>> + unsigned long val = ~0UL, tmp; >>>> + >>>> + /* >>>> + * hlv/hlvx use hstatus.SPVP for the privilege of the access, and the >>>> + * live vsatp/hgatp for the translation. Xen never installs a value of >>>> + * its own in hstatus (it is only saved on trap entry and restored >>>> + * before sret) and it doesn't reschedule before returning to the >>>> + * guest, so all three still belong to the vCPU which trapped. >>>> + * >>>> + * Check the saved copy rather than the live CSR: a nested trap taken >>>> + * from HS-mode clears hstatus.SPV in the CSR (but leaves SPVP alone). >>>> + */ >>>> + ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV); >>> [...] >>> Question being of how much value >>> that checking is: vcpu_guest_cpu_user_regs(current)->hstatus can't possibly >>> have SPV clear, can it? Only nested exception frames could. >> >> Given that vcpu_guest_cpu_user_regs(current)->hstatus will always have >> SPV set for any valid guest trap frame, the ASSERT is purely a defensive >> sanity check to ensure riscv_read_guest() is never called outside a >> guest trap context. > > It is not, afaict: vcpu_guest_cpu_user_regs(current) will give you the guest > frame no matter what context you're in. For what you want, you'd need to > pass struct cpu_user_regs * into here. Agree, struct cpu_user_regs * will be required. But I am looking at how read_guest() is used and it shouldn't be used when nested HS trap happen never and it seems like it is too much to pass struct cpu_user_regs * just to check that. I think it is enough just to have: case CAUSE_FETCH_GUEST_PAGE_FAULT: case CAUSE_LOAD_GUEST_PAGE_FAULT: case CAUSE_STORE_GUEST_PAGE_FAULT: /* * A guest page fault taken in Xen context comes from an hlv/hlvx * access made on a vCPU's behalf and is dealt with by the * fixup_exception() above, so only a guest can get here. */ BUG_ON(!from_guest); where we already checked that when riscv_read_guest() is used then it isn't nested HS trap. So it looks like we could just drop the ASSERT() and probably update the comment above function and mention that riscv_read_guest() shouldn't be called in nested HS trap. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:32:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:32:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417024.1645918 (Exim 4.92) (envelope-from ) id 1x52Ie-0001cc-S3; Fri, 11 Sep 2026 14:32:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417024.1645918; Fri, 11 Sep 2026 14:32:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Ie-0001cV-Oz; Fri, 11 Sep 2026 14:32:20 +0000 Received: by outflank-mailman (input) for mailman id 1417024; Fri, 11 Sep 2026 14:32:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Id-0001cP-F6 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:32:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Ic-001dPR-Rx for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:32:18 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa410f0-2eae-0a2a0a5409dd-0a2a4508b16c-10 for ; Fri, 11 Sep 2026 16:32:18 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa410f0-f659-0a2a45080019-aa0a857c50c1-3 for ; Fri, 11 Sep 2026 16:32:17 +0200 Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-278-kouePLKLNBuFsDVFxTXoEg-1; Fri, 11 Sep 2026 10:32:10 -0400 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2B1131801352; Fri, 11 Sep 2026 14:32:09 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E12F718002B7; Fri, 11 Sep 2026 14:32:06 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=FgcxXaX7vV4QKY5AmHCuTifN6aisrzplu/ekuc9/1QQ=; b=Cv+hhmCq/b2mKdsMQ/LrGF5m5NoL4djo/PEV0Y7YLOelt2/raV5x0qzppqE9xoVlKPMTfh /9S84U05L3nPiiAkMa5ILBVVKjyDSxavZGcVgUsfM0p3uKoTdgyvtvxOzMDaRSxZRQSQKa DgpqbIQpraxRxSZGdS4U/pC3B3mhuVk= X-MC-Unique: kouePLKLNBuFsDVFxTXoEg-1 X-Mimecast-MFC-AGG-ID: kouePLKLNBuFsDVFxTXoEg_1789137129 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: qemu-s390x@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 00/29] Mark user creatable devices for secure for virt use case Date: Fri, 11 Sep 2026 15:31:36 +0100 Message-ID: <20260911143205.2736968-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: agu8hRciYIOpp38akb635qED07y2iMNUy-QOFil3qe8_1789137129 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1789137137-D4D7087B-479E1C6F/0/0 X-purgate-type: clean X-purgate-size: 13452 This (largish) series undertakes the task of marking devices secure, if they are intended to be used a virtualization use case. NB, the maintainer CC list was way too huge to include every individual, so I've trimmed to just the mailing list CCs. The approach taken was iterative as follows * Machines listed in https://www.qemu.org/docs/master/system/security.html#virtualization-use-case * All virtio/vhost/vfio/xen related devices * Most PCI related devices/controllers/bridges I then used the RHEL builds of QEMU as an approximation for what should be considered "virtualization use case", since they cut out a huge pile of devices from the build. IOW, more or less everything that RHEL builds for x86_64, ppc64, aarch64, s390x gets included. Notably since RHEL does not yet ship riscv or loongarch, I've possibly missed some devices that ought to be in scope. Devices are marked secure *regardless* of their maintainer status, if they are relevant to virt. Notably all the USB stuff is included despite USB being orphaned. An exception is CXL which is arguably relevant to virt, but maintainers agreed it is too immature to include so far. IOW, the "secure" flag as set in this series mostly avoids saying anything about the support status of the object types. Over the long term, IMHO, the set of devices we declare as providing a security boundary needs to be stable. We should not declare a device out of scope for the virt use case simply because a maintainer steps aside. The device doesn't become instantly less secure. It does mean bug fixes may not be timely enough, and rely on the goodwill of other contributors or maintainers to step up and fix. Or to put it another way. "secure = true" does not guarantee that the device is secure, but it states our intent that we *want* it to be secure, as opposed to "secure = false" which indicates we just don't care either way. The intersection of (secure, orphaned) highlights to QEMU contributors or corporate sponsors, where they might step up their effort / investment. Finally this is just user creatable devices. Use of these devices implies use of many more non-user creatable devices. I don't have a good way to enumerate those yet, and while the end user doesn't care at runtime, as maintainers we want to be clear if all devices are in scope for CVE handling or not. Based-on: <20260910103628.2326622-1-berrange@redhat.com> Daniel P. Berrangé (29): hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv accel: mark kvm and xen accelerators as secure hw: mark all virtio PCI devices as secure hw: mark all virtio CCW devices as secure hw: mark all vhost devices a secure hw: mark all remaining virtio object types as secure hw/vfio: mark all VFIO object classes as secure hw/xen: mark all Xen related object types as being secure hw/net: mark e1000, e1000e, IGB, rtl8139 & sPAPR VLAN as secure hw/usb: mark commonly used USB devices/hosts as secure hw/watchdog: mark some watchdog devices as secure hw/scsi: mark spapr and vmware SCSI controllers as secure hw/scsi: mark SCSI disk endpoint devices as secure hw/ide: mark ICH9 and ide-hd/ide-cd as secure hw: define most common PCI types as secure hw/pci-host: mark common x86, ppc, arm and s390 PCI hosts as secure hw/display: mark bochs, cirrus, qxl, VGA, ramfb as secure hw/tpm: mark all TPM implementations as secure hw/misc: mark pvpanic, vmcoreinfo as secure hw/audio: mark Intel HDA devices & codecs as secure hw/char: mark common serial / console devicess a secure hw/mem: mark nvdimm, pc-dimm & spapr-nvdimm devices as secure hw/uefi: mark the EFI vars service as secure hw/acpi: mark erst, vmclock and vmgenid devices as secure hw: mark KVM clock and RTC devices as secure hw: device AMD, Intel and ARM IOMMUs as secure hw/input: mark PS/2 and PC Keyboard devices as secure hw/i386: mark vmmouse / vmport as secure tests/tcg: improve check for working cross compilers accel/accel-common.c | 2 ++ accel/accel-system.c | 1 + accel/kvm/kvm-accel-ops.c | 1 + accel/kvm/kvm-all.c | 1 + accel/xen/xen-all.c | 2 ++ hw/9pfs/virtio-9p-device.c | 1 + hw/acpi/erst.c | 1 + hw/acpi/vmclock.c | 1 + hw/acpi/vmgenid.c | 1 + hw/arm/smmu-common.c | 1 + hw/arm/smmuv3.c | 2 ++ hw/arm/virt.c | 1 + hw/arm/xen-pvh.c | 1 + hw/audio/hda-codec.c | 4 ++++ hw/audio/intel-hda.c | 5 +++++ hw/audio/virtio-snd.c | 1 + hw/block/vhost-user-blk.c | 1 + hw/block/virtio-blk.c | 1 + hw/block/xen-block.c | 3 +++ hw/char/debugcon.c | 1 + hw/char/sclpconsole-lm.c | 1 + hw/char/sclpconsole.c | 1 + hw/char/serial-isa.c | 1 + hw/char/serial-pci.c | 1 + hw/char/serial.c | 1 + hw/char/spapr_vty.c | 1 + hw/char/virtio-console.c | 2 ++ hw/char/virtio-serial-bus.c | 3 +++ hw/char/xen_console.c | 1 + hw/display/bochs-display.c | 1 + hw/display/cirrus_vga.c | 1 + hw/display/qxl.c | 3 +++ hw/display/ramfb-standalone.c | 1 + hw/display/vga-mmio.c | 1 + hw/display/vga-pci.c | 3 +++ hw/display/vhost-user-gpu.c | 1 + hw/display/virtio-gpu-base.c | 3 ++- hw/display/virtio-gpu-gl.c | 1 + hw/display/virtio-gpu-pci-rutabaga.c | 1 + hw/display/virtio-gpu-pci.c | 3 ++- hw/display/virtio-gpu-rutabaga.c | 1 + hw/display/virtio-gpu.c | 1 + hw/i386/amd_iommu.c | 4 +++- hw/i386/intel_iommu.c | 1 + hw/i386/kvm/clock.c | 1 + hw/i386/microvm.c | 1 + hw/i386/pc_piix.c | 4 ++-- hw/i386/vmmouse.c | 1 + hw/i386/vmport.c | 1 + hw/i386/xen/xen-pvh.c | 1 + hw/i386/xen/xen_platform.c | 1 + hw/i386/xen/xen_pvdevice.c | 1 + hw/ide/ich.c | 1 + hw/ide/ide-dev.c | 3 +++ hw/ide/piix.c | 2 ++ hw/input/pckbd.c | 3 ++- hw/input/ps2.c | 9 ++++++--- hw/input/virtio-input-hid.c | 5 +++++ hw/input/virtio-input-host.c | 1 + hw/input/virtio-input.c | 1 + hw/loongarch/virt.c | 2 ++ hw/mem/nvdimm.c | 1 + hw/mem/pc-dimm.c | 1 + hw/misc/pvpanic-isa.c | 1 + hw/misc/pvpanic-mmio.c | 1 + hw/misc/pvpanic-pci.c | 1 + hw/misc/vmcoreinfo.c | 1 + hw/net/e1000.c | 1 + hw/net/e1000e.c | 1 + hw/net/igb.c | 1 + hw/net/rtl8139.c | 1 + hw/net/spapr_llan.c | 1 + hw/net/virtio-net.c | 1 + hw/net/xen_nic.c | 1 + hw/pci-bridge/gen_pcie_root_port.c | 1 + hw/pci-bridge/i82801b11.c | 1 + hw/pci-bridge/ioh3420.c | 1 + hw/pci-bridge/pci_bridge_dev.c | 2 ++ hw/pci-bridge/pci_expander_bridge.c | 8 ++++++++ hw/pci-bridge/pcie_pci_bridge.c | 1 + hw/pci-bridge/pcie_root_port.c | 1 + hw/pci-bridge/xio3130_downstream.c | 1 + hw/pci-bridge/xio3130_upstream.c | 1 + hw/pci-host/gpex.c | 2 ++ hw/pci-host/i440fx.c | 2 ++ hw/pci-host/pnv_phb.c | 2 ++ hw/pci-host/pnv_phb3.c | 3 +++ hw/pci-host/pnv_phb3_msi.c | 1 + hw/pci-host/pnv_phb3_pbcq.c | 1 + hw/pci-host/pnv_phb4.c | 4 +++- hw/pci-host/pnv_phb4_pec.c | 1 + hw/pci-host/q35.c | 2 ++ hw/pci-host/remote.c | 1 + hw/pci-host/xen_igd_pt.c | 1 + hw/pci/pci.c | 7 +++++++ hw/pci/pci_bridge.c | 1 + hw/pci/pci_host.c | 1 + hw/pci/pcie_host.c | 1 + hw/pci/pcie_port.c | 1 + hw/ppc/spapr.c | 1 + hw/ppc/spapr_nvdimm.c | 1 + hw/ppc/spapr_pci.c | 1 + hw/ppc/spapr_tpm_proxy.c | 1 + hw/riscv/virt.c | 1 + hw/rtc/mc146818rtc.c | 1 + hw/s390x/s390-pci-bus.c | 4 ++++ hw/s390x/s390-virtio-ccw.c | 1 + hw/s390x/vhost-scsi-ccw.c | 1 + hw/s390x/vhost-user-fs-ccw.c | 1 + hw/s390x/vhost-vsock-ccw.c | 1 + hw/s390x/virtio-ccw-9p.c | 1 + hw/s390x/virtio-ccw-balloon.c | 1 + hw/s390x/virtio-ccw-blk.c | 1 + hw/s390x/virtio-ccw-crypto.c | 1 + hw/s390x/virtio-ccw-gpu.c | 1 + hw/s390x/virtio-ccw-input.c | 5 +++++ hw/s390x/virtio-ccw-md.c | 1 + hw/s390x/virtio-ccw-mem.c | 1 + hw/s390x/virtio-ccw-net.c | 1 + hw/s390x/virtio-ccw-rng.c | 1 + hw/s390x/virtio-ccw-scsi.c | 1 + hw/s390x/virtio-ccw-serial.c | 1 + hw/s390x/virtio-ccw.c | 1 + hw/scsi/scsi-disk.c | 4 ++++ hw/scsi/scsi-generic.c | 1 + hw/scsi/spapr_vscsi.c | 1 + hw/scsi/vhost-scsi-common.c | 1 + hw/scsi/vhost-scsi.c | 1 + hw/scsi/vhost-user-scsi.c | 1 + hw/scsi/virtio-scsi.c | 2 ++ hw/scsi/vmw_pvscsi.c | 1 + hw/tpm/tpm_crb.c | 1 + hw/tpm/tpm_spapr.c | 1 + hw/tpm/tpm_tis_i2c.c | 1 + hw/tpm/tpm_tis_isa.c | 1 + hw/tpm/tpm_tis_sysbus.c | 1 + hw/uefi/var-service-sysbus.c | 2 ++ hw/usb/ccid-card-emulated.c | 1 + hw/usb/ccid-card-passthru.c | 1 + hw/usb/dev-hid.c | 4 ++++ hw/usb/dev-hub.c | 1 + hw/usb/dev-smartcard-reader.c | 3 +++ hw/usb/dev-storage-bot.c | 1 + hw/usb/dev-storage-classic.c | 1 + hw/usb/dev-storage.c | 1 + hw/usb/hcd-ehci-pci.c | 2 ++ hw/usb/hcd-ehci-sysbus.c | 8 ++++++++ hw/usb/hcd-ohci-pci.c | 1 + hw/usb/hcd-ohci-sysbus.c | 1 + hw/usb/hcd-uhci.c | 2 ++ hw/usb/hcd-xhci-nec.c | 1 + hw/usb/hcd-xhci-pci.c | 2 ++ hw/usb/hcd-xhci-sysbus.c | 3 ++- hw/usb/hcd-xhci.c | 1 + hw/usb/host-libusb.c | 1 + hw/usb/redirect.c | 1 + hw/vfio-user/pci.c | 1 + hw/vfio/ap.c | 1 + hw/vfio/ccw.c | 1 + hw/vfio/container.c | 1 + hw/vfio/igd.c | 1 + hw/vfio/iommufd.c | 2 ++ hw/vfio/pci.c | 3 +++ hw/vfio/spapr.c | 1 + hw/virtio/vdpa-dev.c | 1 + hw/virtio/vhost-user-base.c | 3 ++- hw/virtio/vhost-user-fs.c | 1 + hw/virtio/vhost-user-gpio.c | 1 + hw/virtio/vhost-user-i2c.c | 1 + hw/virtio/vhost-user-input.c | 1 + hw/virtio/vhost-user-rng.c | 1 + hw/virtio/vhost-user-rtc.c | 1 + hw/virtio/vhost-user-scmi.c | 1 + hw/virtio/vhost-user-snd.c | 1 + hw/virtio/vhost-user-spi.c | 1 + hw/virtio/vhost-user-test-device.c | 1 + hw/virtio/vhost-user-vsock.c | 1 + hw/virtio/vhost-vsock-common.c | 1 + hw/virtio/vhost-vsock.c | 1 + hw/virtio/virtio-balloon.c | 1 + hw/virtio/virtio-bus.c | 1 + hw/virtio/virtio-crypto.c | 1 + hw/virtio/virtio-input-pci.c | 2 ++ hw/virtio/virtio-iommu.c | 2 ++ hw/virtio/virtio-md-pci.c | 1 + hw/virtio/virtio-mem.c | 1 + hw/virtio/virtio-mmio.c | 2 ++ hw/virtio/virtio-nsm.c | 1 + hw/virtio/virtio-pci.c | 3 +++ hw/virtio/virtio-pmem.c | 1 + hw/virtio/virtio-rng.c | 1 + hw/virtio/virtio-rtc.c | 1 + hw/watchdog/sbsa_gwdt.c | 1 + hw/watchdog/spapr_watchdog.c | 1 + hw/watchdog/wdt_diag288.c | 1 + hw/watchdog/wdt_i6300esb.c | 1 + hw/watchdog/wdt_ib700.c | 1 + hw/xen/xen-bus.c | 3 +++ hw/xen/xen-legacy-backend.c | 3 +++ hw/xen/xen-pvh-common.c | 1 + hw/xen/xen_pt.c | 1 + hw/xenpv/xen_machine_pv.c | 2 +- include/hw/i386/pc.h | 1 + tests/tcg/test_cc.c | 6 +++++- 204 files changed, 309 insertions(+), 14 deletions(-) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:35:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:35:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417037.1645927 (Exim 4.92) (envelope-from ) id 1x52LW-0002Qw-CM; Fri, 11 Sep 2026 14:35:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417037.1645927; Fri, 11 Sep 2026 14:35:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52LW-0002Qp-9n; Fri, 11 Sep 2026 14:35:18 +0000 Received: by outflank-mailman (input) for mailman id 1417037; Fri, 11 Sep 2026 14:35:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52LT-0002Qf-SH for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:35:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52LS-002Xu1-TE; Fri, 11 Sep 2026 16:35:14 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41191-8faa-0a2a0a5109dd-0a2a4505e234-36 for ; Fri, 11 Sep 2026 16:35:14 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa411a1-4cb1-0a2a45050019-5a9b3222a006-3 for ; Fri, 11 Sep 2026 16:35:14 +0200 Received: from [2001:8b0:10b:5:94db:d427:30c1:83c2] (helo=u09cd745991455d.ant.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1x52LR-0000000Cm1f-0mIv; Fri, 11 Sep 2026 14:35:13 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=y9s8/Kik1U8QjhqokdGCkODUnnZo8ko0NcIifZopjfs=; b=sZo3AeTSjpMDaTKMBBdBafSt4F 6M6kmkiAxcmo/4S00fTfKo0wa7y3Bx2oobpHwZSPcDTJN01wMkkzfQ8QJ9tT7ER2edSgewEzxumgi bO7AgXH602Hj3LDhcEEeYizr3+Ep1LKlkGUKKmO79K4uIF0C+xalkzrEmV/y314smHyf/2nwNCqug NPoGe0gzWoEA/CweAwBwDUjHY93IMw0EGvYixJKQLaxlYxKbyoljHW0xabUgZ2RW0Gh6gnLKtIzJO 9mwKpdIiMMYzCmMkuDVCR3DVYJDXPOp2I73tHoZlBvakoBS8pS1KKwpB/TcVd34It7l1YIF8/PvUZ 7g+AU3GQ==; Message-ID: Subject: Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc From: David Woodhouse To: mark.syms@citrix.com Cc: qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org, edgar.iglesias@gmail.com Date: Fri, 11 Sep 2026 15:34:44 +0100 In-Reply-To: <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> References: <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-CbTczZlqA3kFBM/rEx4P" User-Agent: Evolution 3.60.3-0ubuntu1~ppa10~24.04 MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-purgate-ID: tlsNG-c201ff/1789137314-6BEB92A1-68DEC1DD/0/0 X-purgate-type: clean X-purgate-size: 10437 --=-CbTczZlqA3kFBM/rEx4P Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2026-09-11 at 13:31 +0100, David Woodhouse wrote: >=20 > =C2=A0- While testing hot-plug of xen-net-device we hit an unrelated, > =C2=A0=C2=A0 pre-existing heap corruption ("double free or corruption (!p= rev)") > =C2=A0=C2=A0 on qemu exit after hot-plugging a xen-net-device, present on > =C2=A0=C2=A0 current master both with and without the fix. It looks like = the > =C2=A0=C2=A0 same class of exit-notifier-vs-net_cleanup() teardown orderi= ng > =C2=A0=C2=A0 issue as commit 9000666052 ("xen-block: fix segv on unrealiz= e") > =C2=A0=C2=A0 was for xen-block. That will be chased separately. It has a fix for that too now, FWIW, but I don't have the bandwidth right now to reimplement it with meat fingers so I might just file the bug instead. I wasn't *actually* setting out to comment on the AI policy today =E2=80= =94 in fact I didn't really have a strong opinion on it. I spend enough of my life tilting at windmills *intentionally*; this wasn't meant to be one of them. Letting the tool reply in its own voice and pretending I was held hostage was mostly meant as a joke, as *well* as being the only way I was going to look at that bug today (it would have taken me a *long* time to do all that testing of old and new failure modes, finding the net device path that *does* reproduce it locally, fixing the other problem with that, and finally confirming that it all works). But our policies should be based on actual data and the holistic outcomes they achieve, and this is just data which we can take into account on one side of the balance, even if the other side remains more compelling. --=-CbTczZlqA3kFBM/rEx4P Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK 72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9 0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213 MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm 6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6 bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO 02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91 LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8 +3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs +icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1 LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0 D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3 bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2 JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k 0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6 ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74 vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o 9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0yNjA5MTExNDM0NDRaMC8GCSqGSIb3DQEJBDEiBCBE7b8OwAFtO59sj8DRhi3ivcUYMCK0 E7hVc4FMGTbIRjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw DQYJKoZIhvcNAQEBBQAEggIATVfzBATvG9hJynGANW3mgj9rpobP+Q1O0Jl+Jd6crUUQzD4WKY0V tyZQQ4Ym1kr86au+Dit63Uz9GWeAYX2Gzrv430l0Ajh7Bp8o9bE1RmcL6ARZcWvotCOeTjYo3DWA eWgltRPTNrEs1sMxew7GsKYOMDXsnhAj83f9RioAZ5EoVkJXw236c4IyIvlSqBr31nhF6v0qs3Ri ESIJoxAmVg33J1ANG2ZjjX/woKvNCIDMqyJwbXpflx6BIn6dpJxNtAYDWahjEYs3V90B9xUBxXQ+ OxNkneE9P7yJ5LJw7ygaxbgqsGyHROV+ZQzPdDV5pEIkMGsDf7tpg0Lj5zFg/dYCJuFiPWtyQFBx 9KtKt1sLafME3rSstWyBmvxog0wCtUBDNqXqP25V6Y7nJH/PZ58MFBg+c5SmfyEJIOi6BmbK2a0m DAx82/RQhSqkNjl9LCZiN+pxV4oyuRi+USTYFjjRwQP7SQ3bAYs9V65+Rkg3f72QCkTNNp9hrjwo BUHoma7m8qj7igK1OQ7lQ9AFHXtKXaeVr9zNpjLvJqbqv3KtnwbYnSd1hi+HanGl5nnsPydt9AJv lRg5u6dWUTxZmv/op9YvxJpnElj6EaT9QGQD6vMqRwfgmaJqJY5S8JmgajGRmf4ay7Z8Lf6g0Aw0 QEKjkqzfWxsdpEWRevDkrtUAAAAAAAA= --=-CbTczZlqA3kFBM/rEx4P-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417044.1645936 (Exim 4.92) (envelope-from ) id 1x52Mo-0002ua-L5; Fri, 11 Sep 2026 14:36:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417044.1645936; Fri, 11 Sep 2026 14:36:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mo-0002uT-IB; Fri, 11 Sep 2026 14:36:38 +0000 Received: by outflank-mailman (input) for mailman id 1417044; Fri, 11 Sep 2026 14:36:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mn-0002uN-2Y for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Mm-00EPs0-Fb for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:36 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411e2-8faa-0a2a0a5109dd-0a2a4508c45a-48 for ; Fri, 11 Sep 2026 16:36:36 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa411f2-f659-0a2a45080019-aa0a857ced7b-3 for ; Fri, 11 Sep 2026 16:36:35 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-282-PJ2dEpRlNom6jxVT-WltRg-1; Fri, 11 Sep 2026 10:36:32 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9D9E9195607C; Fri, 11 Sep 2026 14:36:30 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id C523B300022B; Fri, 11 Sep 2026 14:36:28 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137394; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=+bcdSv8ht1KTYbbxjhvCgSBCMHwpciTC1oWfuAQo/wM=; b=VMsxb3iuY+1RJh5vHDm4MXz0/NVwgeN2eMU8/27r3at6nraKBISnXqW3who8uWSGvklqfk vjwsq7KmhMcU/HLpO7QmhbaP+c5w1MNyb71IklWXys1C0buSMNuZSDn3rk8PD5g1cnIOoM qR+IhWFWAMETQWYm7HX35yEoJVpnb6g= X-MC-Unique: PJ2dEpRlNom6jxVT-WltRg-1 X-Mimecast-MFC-AGG-ID: PJ2dEpRlNom6jxVT-WltRg_1789137390 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 00/28] Mark user creatable devices for secure for virt use case Date: Fri, 11 Sep 2026 15:35:59 +0100 Message-ID: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: 5ssDu2jNxsqK4I4bIgoy_E32c-ItiA711qa7u_9Odgw_1789137390 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1789137396-CED4087B-F2397D82/0/0 X-purgate-type: clean X-purgate-size: 13346 This (largish) series undertakes the task of marking devices secure, if they are intended to be used a virtualization use case. NB, the maintainer CC list was way too huge to include every individual, so I've trimmed to just the mailing list CCs. The approach taken was iterative as follows * Machines listed in https://www.qemu.org/docs/master/system/security.html#virtualization-use-case * All virtio/vhost/vfio/xen related devices * Most PCI related devices/controllers/bridges I then used the RHEL builds of QEMU as an approximation for what should be considered "virtualization use case", since they cut out a huge pile of devices from the build. IOW, more or less everything that RHEL builds for x86_64, ppc64, aarch64, s390x gets included. Notably since RHEL does not yet ship riscv or loongarch, I've possibly missed some devices that ought to be in scope. Devices are marked secure *regardless* of their maintainer status, if they are relevant to virt. Notably all the USB stuff is included despite USB being orphaned. An exception is CXL which is arguably relevant to virt, but maintainers agreed it is too immature to include so far. IOW, the "secure" flag as set in this series mostly avoids saying anything about the support status of the object types. Over the long term, IMHO, the set of devices we declare as providing a security boundary needs to be stable. We should not declare a device out of scope for the virt use case simply because a maintainer steps aside. The device doesn't become instantly less secure. It does mean bug fixes may not be timely enough, and rely on the goodwill of other contributors or maintainers to step up and fix. Or to put it another way. "secure = true" does not guarantee that the device is secure, but it states our intent that we *want* it to be secure, as opposed to "secure = false" which indicates we just don't care either way. The intersection of (secure, orphaned) highlights to QEMU contributors or corporate sponsors, where they might step up their effort / investment. Finally this is just user creatable devices. Use of these devices implies use of many more non-user creatable devices. I don't have a good way to enumerate those yet, and while the end user doesn't care at runtime, as maintainers we want to be clear if all devices are in scope for CVE handling or not. Based-on: <20260910103628.2326622-1-berrange@redhat.com> Daniel P. Berrangé (28): hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv accel: mark kvm and xen accelerators as secure hw: mark all virtio PCI devices as secure hw: mark all virtio CCW devices as secure hw: mark all vhost devices a secure hw: mark all remaining virtio object types as secure hw/vfio: mark all VFIO object classes as secure hw/xen: mark all Xen related object types as being secure hw/net: mark e1000, e1000e, IGB, rtl8139 & sPAPR VLAN as secure hw/usb: mark commonly used USB devices/hosts as secure hw/watchdog: mark some watchdog devices as secure hw/scsi: mark spapr and vmware SCSI controllers as secure hw/scsi: mark SCSI disk endpoint devices as secure hw/ide: mark ICH9 and ide-hd/ide-cd as secure hw: define most common PCI types as secure hw/pci-host: mark common x86, ppc, arm and s390 PCI hosts as secure hw/display: mark bochs, cirrus, qxl, VGA, ramfb as secure hw/tpm: mark all TPM implementations as secure hw/misc: mark pvpanic, vmcoreinfo as secure hw/audio: mark Intel HDA devices & codecs as secure hw/char: mark common serial / console devicess a secure hw/mem: mark nvdimm, pc-dimm & spapr-nvdimm devices as secure hw/uefi: mark the EFI vars service as secure hw/acpi: mark erst, vmclock and vmgenid devices as secure hw: mark KVM clock and RTC devices as secure hw: device AMD, Intel and ARM IOMMUs as secure hw/input: mark PS/2 and PC Keyboard devices as secure hw/i386: mark vmmouse / vmport as secure accel/accel-common.c | 2 ++ accel/accel-system.c | 1 + accel/kvm/kvm-accel-ops.c | 1 + accel/kvm/kvm-all.c | 1 + accel/xen/xen-all.c | 2 ++ hw/9pfs/virtio-9p-device.c | 1 + hw/acpi/erst.c | 1 + hw/acpi/vmclock.c | 1 + hw/acpi/vmgenid.c | 1 + hw/arm/smmu-common.c | 1 + hw/arm/smmuv3.c | 2 ++ hw/arm/virt.c | 1 + hw/arm/xen-pvh.c | 1 + hw/audio/hda-codec.c | 4 ++++ hw/audio/intel-hda.c | 5 +++++ hw/audio/virtio-snd.c | 1 + hw/block/vhost-user-blk.c | 1 + hw/block/virtio-blk.c | 1 + hw/block/xen-block.c | 3 +++ hw/char/debugcon.c | 1 + hw/char/sclpconsole-lm.c | 1 + hw/char/sclpconsole.c | 1 + hw/char/serial-isa.c | 1 + hw/char/serial-pci.c | 1 + hw/char/serial.c | 1 + hw/char/spapr_vty.c | 1 + hw/char/virtio-console.c | 2 ++ hw/char/virtio-serial-bus.c | 3 +++ hw/char/xen_console.c | 1 + hw/display/bochs-display.c | 1 + hw/display/cirrus_vga.c | 1 + hw/display/qxl.c | 3 +++ hw/display/ramfb-standalone.c | 1 + hw/display/vga-mmio.c | 1 + hw/display/vga-pci.c | 3 +++ hw/display/vhost-user-gpu.c | 1 + hw/display/virtio-gpu-base.c | 3 ++- hw/display/virtio-gpu-gl.c | 1 + hw/display/virtio-gpu-pci-rutabaga.c | 1 + hw/display/virtio-gpu-pci.c | 3 ++- hw/display/virtio-gpu-rutabaga.c | 1 + hw/display/virtio-gpu.c | 1 + hw/i386/amd_iommu.c | 4 +++- hw/i386/intel_iommu.c | 1 + hw/i386/kvm/clock.c | 1 + hw/i386/microvm.c | 1 + hw/i386/pc_piix.c | 4 ++-- hw/i386/vmmouse.c | 1 + hw/i386/vmport.c | 1 + hw/i386/xen/xen-pvh.c | 1 + hw/i386/xen/xen_platform.c | 1 + hw/i386/xen/xen_pvdevice.c | 1 + hw/ide/ich.c | 1 + hw/ide/ide-dev.c | 3 +++ hw/ide/piix.c | 2 ++ hw/input/pckbd.c | 3 ++- hw/input/ps2.c | 9 ++++++--- hw/input/virtio-input-hid.c | 5 +++++ hw/input/virtio-input-host.c | 1 + hw/input/virtio-input.c | 1 + hw/loongarch/virt.c | 2 ++ hw/mem/nvdimm.c | 1 + hw/mem/pc-dimm.c | 1 + hw/misc/pvpanic-isa.c | 1 + hw/misc/pvpanic-mmio.c | 1 + hw/misc/pvpanic-pci.c | 1 + hw/misc/vmcoreinfo.c | 1 + hw/net/e1000.c | 1 + hw/net/e1000e.c | 1 + hw/net/igb.c | 1 + hw/net/rtl8139.c | 1 + hw/net/spapr_llan.c | 1 + hw/net/virtio-net.c | 1 + hw/net/xen_nic.c | 1 + hw/pci-bridge/gen_pcie_root_port.c | 1 + hw/pci-bridge/i82801b11.c | 1 + hw/pci-bridge/ioh3420.c | 1 + hw/pci-bridge/pci_bridge_dev.c | 2 ++ hw/pci-bridge/pci_expander_bridge.c | 8 ++++++++ hw/pci-bridge/pcie_pci_bridge.c | 1 + hw/pci-bridge/pcie_root_port.c | 1 + hw/pci-bridge/xio3130_downstream.c | 1 + hw/pci-bridge/xio3130_upstream.c | 1 + hw/pci-host/gpex.c | 2 ++ hw/pci-host/i440fx.c | 2 ++ hw/pci-host/pnv_phb.c | 2 ++ hw/pci-host/pnv_phb3.c | 3 +++ hw/pci-host/pnv_phb3_msi.c | 1 + hw/pci-host/pnv_phb3_pbcq.c | 1 + hw/pci-host/pnv_phb4.c | 4 +++- hw/pci-host/pnv_phb4_pec.c | 1 + hw/pci-host/q35.c | 2 ++ hw/pci-host/remote.c | 1 + hw/pci-host/xen_igd_pt.c | 1 + hw/pci/pci.c | 7 +++++++ hw/pci/pci_bridge.c | 1 + hw/pci/pci_host.c | 1 + hw/pci/pcie_host.c | 1 + hw/pci/pcie_port.c | 1 + hw/ppc/spapr.c | 1 + hw/ppc/spapr_nvdimm.c | 1 + hw/ppc/spapr_pci.c | 1 + hw/ppc/spapr_tpm_proxy.c | 1 + hw/riscv/virt.c | 1 + hw/rtc/mc146818rtc.c | 1 + hw/s390x/s390-pci-bus.c | 4 ++++ hw/s390x/s390-virtio-ccw.c | 1 + hw/s390x/vhost-scsi-ccw.c | 1 + hw/s390x/vhost-user-fs-ccw.c | 1 + hw/s390x/vhost-vsock-ccw.c | 1 + hw/s390x/virtio-ccw-9p.c | 1 + hw/s390x/virtio-ccw-balloon.c | 1 + hw/s390x/virtio-ccw-blk.c | 1 + hw/s390x/virtio-ccw-crypto.c | 1 + hw/s390x/virtio-ccw-gpu.c | 1 + hw/s390x/virtio-ccw-input.c | 5 +++++ hw/s390x/virtio-ccw-md.c | 1 + hw/s390x/virtio-ccw-mem.c | 1 + hw/s390x/virtio-ccw-net.c | 1 + hw/s390x/virtio-ccw-rng.c | 1 + hw/s390x/virtio-ccw-scsi.c | 1 + hw/s390x/virtio-ccw-serial.c | 1 + hw/s390x/virtio-ccw.c | 1 + hw/scsi/scsi-disk.c | 4 ++++ hw/scsi/scsi-generic.c | 1 + hw/scsi/spapr_vscsi.c | 1 + hw/scsi/vhost-scsi-common.c | 1 + hw/scsi/vhost-scsi.c | 1 + hw/scsi/vhost-user-scsi.c | 1 + hw/scsi/virtio-scsi.c | 2 ++ hw/scsi/vmw_pvscsi.c | 1 + hw/tpm/tpm_crb.c | 1 + hw/tpm/tpm_spapr.c | 1 + hw/tpm/tpm_tis_i2c.c | 1 + hw/tpm/tpm_tis_isa.c | 1 + hw/tpm/tpm_tis_sysbus.c | 1 + hw/uefi/var-service-sysbus.c | 2 ++ hw/usb/ccid-card-emulated.c | 1 + hw/usb/ccid-card-passthru.c | 1 + hw/usb/dev-hid.c | 4 ++++ hw/usb/dev-hub.c | 1 + hw/usb/dev-smartcard-reader.c | 3 +++ hw/usb/dev-storage-bot.c | 1 + hw/usb/dev-storage-classic.c | 1 + hw/usb/dev-storage.c | 1 + hw/usb/hcd-ehci-pci.c | 2 ++ hw/usb/hcd-ehci-sysbus.c | 8 ++++++++ hw/usb/hcd-ohci-pci.c | 1 + hw/usb/hcd-ohci-sysbus.c | 1 + hw/usb/hcd-uhci.c | 2 ++ hw/usb/hcd-xhci-nec.c | 1 + hw/usb/hcd-xhci-pci.c | 2 ++ hw/usb/hcd-xhci-sysbus.c | 3 ++- hw/usb/hcd-xhci.c | 1 + hw/usb/host-libusb.c | 1 + hw/usb/redirect.c | 1 + hw/vfio-user/pci.c | 1 + hw/vfio/ap.c | 1 + hw/vfio/ccw.c | 1 + hw/vfio/container.c | 1 + hw/vfio/igd.c | 1 + hw/vfio/iommufd.c | 2 ++ hw/vfio/pci.c | 3 +++ hw/vfio/spapr.c | 1 + hw/virtio/vdpa-dev.c | 1 + hw/virtio/vhost-user-base.c | 3 ++- hw/virtio/vhost-user-fs.c | 1 + hw/virtio/vhost-user-gpio.c | 1 + hw/virtio/vhost-user-i2c.c | 1 + hw/virtio/vhost-user-input.c | 1 + hw/virtio/vhost-user-rng.c | 1 + hw/virtio/vhost-user-rtc.c | 1 + hw/virtio/vhost-user-scmi.c | 1 + hw/virtio/vhost-user-snd.c | 1 + hw/virtio/vhost-user-spi.c | 1 + hw/virtio/vhost-user-test-device.c | 1 + hw/virtio/vhost-user-vsock.c | 1 + hw/virtio/vhost-vsock-common.c | 1 + hw/virtio/vhost-vsock.c | 1 + hw/virtio/virtio-balloon.c | 1 + hw/virtio/virtio-bus.c | 1 + hw/virtio/virtio-crypto.c | 1 + hw/virtio/virtio-input-pci.c | 2 ++ hw/virtio/virtio-iommu.c | 2 ++ hw/virtio/virtio-md-pci.c | 1 + hw/virtio/virtio-mem.c | 1 + hw/virtio/virtio-mmio.c | 2 ++ hw/virtio/virtio-nsm.c | 1 + hw/virtio/virtio-pci.c | 3 +++ hw/virtio/virtio-pmem.c | 1 + hw/virtio/virtio-rng.c | 1 + hw/virtio/virtio-rtc.c | 1 + hw/watchdog/sbsa_gwdt.c | 1 + hw/watchdog/spapr_watchdog.c | 1 + hw/watchdog/wdt_diag288.c | 1 + hw/watchdog/wdt_i6300esb.c | 1 + hw/watchdog/wdt_ib700.c | 1 + hw/xen/xen-bus.c | 3 +++ hw/xen/xen-legacy-backend.c | 3 +++ hw/xen/xen-pvh-common.c | 1 + hw/xen/xen_pt.c | 1 + hw/xenpv/xen_machine_pv.c | 2 +- include/hw/i386/pc.h | 1 + 203 files changed, 304 insertions(+), 13 deletions(-) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417045.1645945 (Exim 4.92) (envelope-from ) id 1x52Mt-00039b-VU; Fri, 11 Sep 2026 14:36:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417045.1645945; Fri, 11 Sep 2026 14:36:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mt-00039U-SO; Fri, 11 Sep 2026 14:36:43 +0000 Received: by outflank-mailman (input) for mailman id 1417045; Fri, 11 Sep 2026 14:36:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Ms-00038N-7X for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Mr-008jWV-Kg for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:41 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411f6-bab6-0a2a0a5309dd-0a2a4508c95e-8 for ; Fri, 11 Sep 2026 16:36:41 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa411f8-f659-0a2a45080019-aa0a857c86ff-3 for ; Fri, 11 Sep 2026 16:36:41 +0200 Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-u93WP60COd6io4ZK1zb54w-1; Fri, 11 Sep 2026 10:36:34 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 00B5918005A0; Fri, 11 Sep 2026 14:36:33 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id F055C300022B; Fri, 11 Sep 2026 14:36:30 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137400; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=123pjNEHzCkIAWUZoFvGci86utv4Qh+kMiJ8nnUWnD4=; b=XR8EdWbjvWt329IgwxmEKX0FJu4gPqCn5pBWP5b3aJ0qT062x3v8bxUU2w63T9wv5Z9ymX h/mt0mXd5Q4qUOnm/ZdF/tWDoVrb/gSju8iM6Dlu54YIE7wKK/Ta3JAFvy5TF7O6IF1qMW BWedGjzl3xlezd/6SjXeWIuS8Qn7k+A= X-MC-Unique: u93WP60COd6io4ZK1zb54w-1 X-Mimecast-MFC-AGG-ID: u93WP60COd6io4ZK1zb54w_1789137393 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv Date: Fri, 11 Sep 2026 15:36:00 +0100 Message-ID: <20260911143627.2743803-2-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: jJpKNHBwSopvzXa0Yzzm71ol4Lcc1TLOEX7UdMH55l8_1789137393 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1789137401-D534D87B-4857C95E/0/0 X-purgate-type: clean X-purgate-size: 7653 The versioned machine types are typically present for use in virtualization use cases and can be expected to provide a security barrier. The only exceptions are the m68k versioned machine types which are only used with TCG. There are also a handful of other machines declared secure in docs/system/security.rst, notably the Xen machine variants and microvm. Signed-off-by: Daniel P. Berrangé --- hw/arm/virt.c | 1 + hw/arm/xen-pvh.c | 1 + hw/i386/microvm.c | 1 + hw/i386/pc_piix.c | 4 ++-- hw/i386/xen/xen-pvh.c | 1 + hw/loongarch/virt.c | 2 ++ hw/ppc/spapr.c | 1 + hw/riscv/virt.c | 1 + hw/s390x/s390-virtio-ccw.c | 1 + hw/xen/xen-pvh-common.c | 1 + hw/xenpv/xen_machine_pv.c | 2 +- include/hw/i386/pc.h | 1 + 12 files changed, 14 insertions(+), 3 deletions(-) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 0871a35e11..e62cd0055b 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -132,6 +132,7 @@ static void arm_virt_compat_default_set(MachineClass *mc) .name = MACHINE_VER_TYPE_NAME("virt", __VA_ARGS__), \ .parent = TYPE_VIRT_MACHINE, \ .class_init = MACHINE_VER_SYM(class_init, virt, __VA_ARGS__), \ + .secure = true, \ }; \ static void MACHINE_VER_SYM(register, virt, __VA_ARGS__)(void) \ { \ diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c index f05956c166..6b85eced1b 100644 --- a/hw/arm/xen-pvh.c +++ b/hw/arm/xen-pvh.c @@ -95,6 +95,7 @@ static const TypeInfo xen_arm_machine_type = { .class_init = xen_arm_machine_class_init, .instance_size = sizeof(XenPVHMachineState), .instance_init = xen_arm_instance_init, + .secure = true, }; static void xen_arm_machine_register_types(void) diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c index e7adab7d2e..9256b31a60 100644 --- a/hw/i386/microvm.c +++ b/hw/i386/microvm.c @@ -736,6 +736,7 @@ static const TypeInfo microvm_machine_info = { .instance_init = microvm_machine_initfn, .class_size = sizeof(MicrovmMachineClass), .class_init = microvm_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index a929cc4dec..b6cd6dc5aa 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -672,6 +672,6 @@ static void xenfv_machine_4_2_options(MachineClass *m) m->default_machine_opts = "accel=xen,suppress-vmdesc=on"; } -DEFINE_PC_MACHINE(xenfv_4_2, "xenfv-4.2", pc_xen_hvm_init, - xenfv_machine_4_2_options); +DEFINE_SECURE_PC_MACHINE(xenfv_4_2, "xenfv-4.2", pc_xen_hvm_init, + xenfv_machine_4_2_options); #endif diff --git a/hw/i386/xen/xen-pvh.c b/hw/i386/xen/xen-pvh.c index ab90c83a83..d81575b4c9 100644 --- a/hw/i386/xen/xen-pvh.c +++ b/hw/i386/xen/xen-pvh.c @@ -115,6 +115,7 @@ static const TypeInfo xen_pvh_x86_machine_type = { .class_init = xen_pvh_machine_class_init, .instance_init = xen_pvh_instance_init, .instance_size = sizeof(XenPVHx86State), + .secure = true, }; static void xen_pvh_machine_register_types(void) diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 9cc79929a8..0501512a24 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -1553,6 +1553,7 @@ static void virt_class_init(ObjectClass *oc, const void *data) .name = MACHINE_VER_TYPE_NAME("virt", __VA_ARGS__), \ .parent = TYPE_LOONGARCH_VIRT_MACHINE, \ .class_init = MACHINE_VER_SYM(class_init, virt, __VA_ARGS__), \ + .secure = true, \ }; \ static void MACHINE_VER_SYM(register, virt, __VA_ARGS__)(void) \ { \ @@ -1583,6 +1584,7 @@ static const TypeInfo virt_machine_info = { .name = TYPE_LOONGARCH_VIRT_MACHINE, .parent = TYPE_MACHINE, .abstract = true, + .secure = true, .instance_size = sizeof(LoongArchVirtMachineState), .class_init = virt_class_init, .instance_init = virt_initfn, diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 20e024907b..4e05e8b71b 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -4750,6 +4750,7 @@ static void spapr_machine_latest_class_options(MachineClass *mc) .name = MACHINE_VER_TYPE_NAME("pseries", __VA_ARGS__), \ .parent = TYPE_SPAPR_MACHINE, \ .class_init = MACHINE_VER_SYM(class_init, spapr, __VA_ARGS__), \ + .secure = true, \ }; \ static void MACHINE_VER_SYM(register, spapr, __VA_ARGS__)(void) \ { \ diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index f3a1cc5ba3..9d146205b3 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -1200,6 +1200,7 @@ static const TypeInfo virt_machine_typeinfo = { .name = MACHINE_TYPE_NAME("virt"), .parent = TYPE_MACHINE, .class_init = virt_machine_class_init, + .secure = true, .instance_init = virt_machine_instance_init, .instance_finalize = virt_machine_instance_finalize, .instance_size = sizeof(RISCVVirtState), diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 17266779a6..c9a646be8b 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -973,6 +973,7 @@ static const TypeInfo ccw_machine_info = { .name = MACHINE_VER_TYPE_NAME("s390-ccw-virtio", __VA_ARGS__), \ .parent = TYPE_S390_CCW_MACHINE, \ .class_init = MACHINE_VER_SYM(class_init, ccw, __VA_ARGS__), \ + .secure = true, \ }; \ static void MACHINE_VER_SYM(register, ccw, __VA_ARGS__)(void) \ { \ diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c index cca37202ff..939e85317d 100644 --- a/hw/xen/xen-pvh-common.c +++ b/hw/xen/xen-pvh-common.c @@ -504,6 +504,7 @@ static const TypeInfo xen_pvh_info = { .name = TYPE_XEN_PVH_MACHINE, .parent = TYPE_MACHINE, .abstract = true, + .secure = true, .instance_size = sizeof(XenPVHMachineState), .instance_init = xen_pvh_instance_init, .class_size = sizeof(XenPVHMachineClass), diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c index c406821c34..e0620a096e 100644 --- a/hw/xenpv/xen_machine_pv.c +++ b/hw/xenpv/xen_machine_pv.c @@ -69,4 +69,4 @@ static void xenpv_machine_init(MachineClass *mc) mc->default_machine_opts = "accel=xen"; } -DEFINE_MACHINE("xenpv", xenpv_machine_init) +DEFINE_SECURE_MACHINE("xenpv", xenpv_machine_init) diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index d5dc79df17..45b92780d3 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -325,6 +325,7 @@ extern const size_t pc_compat_4_1_len; .name = MACHINE_VER_TYPE_NAME(namestr, __VA_ARGS__), \ .parent = TYPE_PC_MACHINE, \ .class_init = MACHINE_VER_SYM(class_init, namesym, __VA_ARGS__), \ + .secure = true, \ }; \ static void MACHINE_VER_SYM(register, namesym, __VA_ARGS__)(void) \ { \ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417046.1645950 (Exim 4.92) (envelope-from ) id 1x52Mu-0003C4-AI; Fri, 11 Sep 2026 14:36:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417046.1645950; Fri, 11 Sep 2026 14:36:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mu-0003B9-3E; Fri, 11 Sep 2026 14:36:44 +0000 Received: by outflank-mailman (input) for mailman id 1417046; Fri, 11 Sep 2026 14:36:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mt-000391-3w for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Ms-00EPyQ-H0 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:42 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411f8-8faa-0a2a0a5109dd-0a2a4509ca7a-4 for ; Fri, 11 Sep 2026 16:36:42 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa411f9-be1a-0a2a45090019-aa0a857cdf59-3 for ; Fri, 11 Sep 2026 16:36:42 +0200 Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-126-jsyPwnXzMwa2-qmFeiK4Mg-1; Fri, 11 Sep 2026 10:36:36 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4400F195399C; Fri, 11 Sep 2026 14:36:35 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 52E2B3000229; Fri, 11 Sep 2026 14:36:33 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137401; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mS2d1sWvkJvfrpBNzSThHFJjRCwDwl0JUnHIN1+hoNI=; b=B25biY9Qzz994SWK9i9RLFyBkOgvaIlxo4DbdGuGN3nKQTwvkrm6TxDyLJo76IJKVkyF7a VHdtj8YKxQuDPWZzEkS8UeTKyj1lvv9zz0ZIF/v5fzrPbymYafc2eFpUBEBqTD+egvoT6V Mj5G7eHHaVR2T9xodFAlrfsKvUH0K18= X-MC-Unique: jsyPwnXzMwa2-qmFeiK4Mg-1 X-Mimecast-MFC-AGG-ID: jsyPwnXzMwa2-qmFeiK4Mg_1789137395 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 02/28] accel: mark kvm and xen accelerators as secure Date: Fri, 11 Sep 2026 15:36:01 +0100 Message-ID: <20260911143627.2743803-3-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: YHsL0aKHNqEwJd45n2MAn31sdpwudyA6UkGfIyKObn0_1789137395 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1789137402-BFAD0034-EE2B1D8F/0/0 X-purgate-type: clean X-purgate-size: 3224 TCG is too complex to be considered to provide a security boundary for malicious guest workloads. QTest is only used for functional testing and thus is not relevant to mark secure. KVM and Xen are servicing virtualization use cases which must provide security and actively maintained. While HVF would be in scope conceptually, it is not sufficiently mature or maintained to claim a security boundary at this time. Signed-off-by: Daniel P. Berrangé --- accel/accel-common.c | 2 ++ accel/accel-system.c | 1 + accel/kvm/kvm-accel-ops.c | 1 + accel/kvm/kvm-all.c | 1 + accel/xen/xen-all.c | 2 ++ 5 files changed, 7 insertions(+) diff --git a/accel/accel-common.c b/accel/accel-common.c index 00a400243f..1d993f0ad8 100644 --- a/accel/accel-common.c +++ b/accel/accel-common.c @@ -125,6 +125,7 @@ static const TypeInfo accel_types[] = { .class_size = sizeof(AccelClass), .instance_size = sizeof(AccelState), .abstract = true, + .secure = true, }, }; @@ -137,6 +138,7 @@ static void register_accel_target_type(void) .name = name, .parent = TYPE_OBJECT, .abstract = true, + .secure = true, .class_size = sizeof(AccelCPUClass), }; diff --git a/accel/accel-system.c b/accel/accel-system.c index 1325b23864..f3f31bc666 100644 --- a/accel/accel-system.c +++ b/accel/accel-system.c @@ -118,6 +118,7 @@ static const TypeInfo accel_ops_type_info = { .name = TYPE_ACCEL_OPS, .parent = TYPE_OBJECT, .abstract = true, + .secure = true, .class_size = sizeof(AccelOpsClass), .class_init = accel_ops_class_init, }; diff --git a/accel/kvm/kvm-accel-ops.c b/accel/kvm/kvm-accel-ops.c index c8e7aa3870..f05d41a837 100644 --- a/accel/kvm/kvm-accel-ops.c +++ b/accel/kvm/kvm-accel-ops.c @@ -119,6 +119,7 @@ static const TypeInfo kvm_accel_ops_type = { .parent = TYPE_ACCEL_OPS, .class_init = kvm_accel_ops_class_init, .abstract = true, + .secure = true, }; static void kvm_accel_ops_register_types(void) diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index 83cbd120a8..af886aa28c 100644 --- a/accel/kvm/kvm-all.c +++ b/accel/kvm/kvm-all.c @@ -4328,6 +4328,7 @@ static const TypeInfo kvm_accel_type = { .instance_finalize = kvm_accel_finalize, .class_init = kvm_accel_class_init, .instance_size = sizeof(KVMState), + .secure = true, }; static void kvm_type_init(void) diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c index bb2d02cb22..937e0e947d 100644 --- a/accel/xen/xen-all.c +++ b/accel/xen/xen-all.c @@ -147,6 +147,7 @@ static const TypeInfo xen_accel_type = { .name = TYPE_XEN_ACCEL, .parent = TYPE_ACCEL, .class_init = xen_accel_class_init, + .secure = true, }; static void xen_accel_ops_class_init(ObjectClass *oc, const void *data) @@ -163,6 +164,7 @@ static const TypeInfo xen_accel_ops_type = { .parent = TYPE_ACCEL_OPS, .class_init = xen_accel_ops_class_init, .abstract = true, + .secure = true, }; static void xen_type_init(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417047.1645956 (Exim 4.92) (envelope-from ) id 1x52Mu-0003FM-Io; Fri, 11 Sep 2026 14:36:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417047.1645956; Fri, 11 Sep 2026 14:36:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mu-0003ER-AV; Fri, 11 Sep 2026 14:36:44 +0000 Received: by outflank-mailman (input) for mailman id 1417047; Fri, 11 Sep 2026 14:36:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mt-000396-Dc for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Ms-00EPw8-QW for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:42 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411f2-2eae-0a2a0a5409dd-0a2a4507d898-14 for ; Fri, 11 Sep 2026 16:36:42 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa411f9-b4ea-0a2a45070019-aa0a817ca483-3 for ; Fri, 11 Sep 2026 16:36:42 +0200 Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-635-oGNVjD9aMeyt3IjX5GvwDg-1; Fri, 11 Sep 2026 10:36:38 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9196619540D3; Fri, 11 Sep 2026 14:36:37 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 95C273000229; Fri, 11 Sep 2026 14:36:35 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137401; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aVwGPfL+WLnUP8giUYwqDBNb4zonggDSk3sHSYr9pFM=; b=QLZ3fYdWo4uUcoSpAKIfayVPZQJ8Zr8bFu9mlgB0cdHMlXHi9LtQ9VSnwb6Xf79s/jl576 R6QqHGxCCClCh+CkG4AFkERoJ7mbexJVCu+FrqIQVWXuZ+sIkY0tR4GYHeAegTUwC4fok6 R1VwYe+u4WSnTuoY7eaSmctk2QYX7ps= X-MC-Unique: oGNVjD9aMeyt3IjX5GvwDg-1 X-Mimecast-MFC-AGG-ID: oGNVjD9aMeyt3IjX5GvwDg_1789137397 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 03/28] hw: mark all virtio PCI devices as secure Date: Fri, 11 Sep 2026 15:36:02 +0100 Message-ID: <20260911143627.2743803-4-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: sKibLlbCUh-YD9421UNZra0ZmkXzFTqHWncGr04mDrE_1789137397 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1789137402-364DBAE4-F17CDF5E/0/0 X-purgate-type: clean X-purgate-size: 3170 These are all intended for use in a virtualization scenario and must provide a security boundary. This can be done for almost all virtio PCI devices by modifying the common type register helper. The virtio-gpu devices are unusual in not using the common virtio_pci_types_register() method, so need marking directly. Signed-off-by: Daniel P. Berrangé --- hw/display/virtio-gpu-pci-rutabaga.c | 1 + hw/display/virtio-gpu-pci.c | 3 ++- hw/virtio/virtio-pci.c | 3 +++ 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/hw/display/virtio-gpu-pci-rutabaga.c b/hw/display/virtio-gpu-pci-rutabaga.c index 4db77cb868..a8e5e1d96c 100644 --- a/hw/display/virtio-gpu-pci-rutabaga.c +++ b/hw/display/virtio-gpu-pci-rutabaga.c @@ -34,6 +34,7 @@ static const TypeInfo virtio_gpu_rutabaga_pci_info[] = { .parent = TYPE_VIRTIO_GPU_PCI_BASE, .instance_size = sizeof(VirtIOGPURutabagaPCI), .instance_init = virtio_gpu_rutabaga_initfn, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c index 22659ca196..0b0d926a5b 100644 --- a/hw/display/virtio-gpu-pci.c +++ b/hw/display/virtio-gpu-pci.c @@ -75,7 +75,8 @@ static const TypeInfo virtio_gpu_pci_base_info = { .parent = TYPE_VIRTIO_PCI, .instance_size = sizeof(VirtIOGPUPCIBase), .class_init = virtio_gpu_pci_base_class_init, - .abstract = true + .abstract = true, + .secure = true, }; module_obj(TYPE_VIRTIO_GPU_PCI_BASE); module_kconfig(VIRTIO_PCI); diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c index 6f5db5fc42..cd5fe8f1d8 100644 --- a/hw/virtio/virtio-pci.c +++ b/hw/virtio/virtio-pci.c @@ -2520,6 +2520,7 @@ void virtio_pci_types_register(const VirtioPCIDeviceTypeInfo *t) .name = t->generic_name, .parent = base_type_info.name, .class_init = virtio_pci_generic_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, { INTERFACE_CONVENTIONAL_PCI_DEVICE }, @@ -2555,6 +2556,7 @@ void virtio_pci_types_register(const VirtioPCIDeviceTypeInfo *t) .name = t->non_transitional_name, .parent = base_type_info.name, .instance_init = virtio_pci_non_transitional_instance_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, { INTERFACE_CONVENTIONAL_PCI_DEVICE }, @@ -2569,6 +2571,7 @@ void virtio_pci_types_register(const VirtioPCIDeviceTypeInfo *t) .name = t->transitional_name, .parent = base_type_info.name, .instance_init = virtio_pci_transitional_instance_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { /* * Transitional virtio devices work only as Conventional PCI -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417049.1645972 (Exim 4.92) (envelope-from ) id 1x52My-0003rp-Mt; Fri, 11 Sep 2026 14:36:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417049.1645972; Fri, 11 Sep 2026 14:36:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52My-0003rc-J8; Fri, 11 Sep 2026 14:36:48 +0000 Received: by outflank-mailman (input) for mailman id 1417049; Fri, 11 Sep 2026 14:36:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mw-0003ox-SL for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Mw-00EPw8-9A for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:46 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411f2-2eae-0a2a0a5409dd-0a2a4507d898-22 for ; Fri, 11 Sep 2026 16:36:45 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa411fc-b4ea-0a2a45070019-aa0a817c9db7-3 for ; Fri, 11 Sep 2026 16:36:45 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-679-QJAJc0lBOSyL8twcGOmj4g-1; Fri, 11 Sep 2026 10:36:41 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A6CC21954202; Fri, 11 Sep 2026 14:36:39 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D6BFA3000229; Fri, 11 Sep 2026 14:36:37 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137404; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P8SFGy/hq0dW7bSxSgJO/zU5isKmK2Ilivs89TXlOVY=; b=ij7AzpuBkpZu5tMHiI2riRBYUCONbLSg0A9C+XsveWPUlEyBsJPZiTZ9DrJaVcbMRNV1bG 7jnBPUPQqF8GpJjTLf+919pvC8AKxaKB9kgyZ//vPqyc2jiemn9BieC4mjpFGkJnxZ0pmx nPCSUg4R1raKU7lIthBY8QaO12HftS0= X-MC-Unique: QJAJc0lBOSyL8twcGOmj4g-1 X-Mimecast-MFC-AGG-ID: QJAJc0lBOSyL8twcGOmj4g_1789137399 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 04/28] hw: mark all virtio CCW devices as secure Date: Fri, 11 Sep 2026 15:36:03 +0100 Message-ID: <20260911143627.2743803-5-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: Kt9gjqEcTb3aDHHqKi65Bya2LjWe84ayZcbuwn15fg4_1789137399 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1789137405-35AC0AE4-BD59CDF7/0/0 X-purgate-type: clean X-purgate-size: 9458 These are all intended for use in a virtualization scenario and must provide a security boundary. Signed-off-by: Daniel P. Berrangé --- hw/s390x/vhost-scsi-ccw.c | 1 + hw/s390x/vhost-user-fs-ccw.c | 1 + hw/s390x/vhost-vsock-ccw.c | 1 + hw/s390x/virtio-ccw-9p.c | 1 + hw/s390x/virtio-ccw-balloon.c | 1 + hw/s390x/virtio-ccw-blk.c | 1 + hw/s390x/virtio-ccw-crypto.c | 1 + hw/s390x/virtio-ccw-gpu.c | 1 + hw/s390x/virtio-ccw-input.c | 5 +++++ hw/s390x/virtio-ccw-md.c | 1 + hw/s390x/virtio-ccw-mem.c | 1 + hw/s390x/virtio-ccw-net.c | 1 + hw/s390x/virtio-ccw-rng.c | 1 + hw/s390x/virtio-ccw-scsi.c | 1 + hw/s390x/virtio-ccw-serial.c | 1 + hw/s390x/virtio-ccw.c | 1 + 16 files changed, 20 insertions(+) diff --git a/hw/s390x/vhost-scsi-ccw.c b/hw/s390x/vhost-scsi-ccw.c index 1e68459eb0..2bd51a8033 100644 --- a/hw/s390x/vhost-scsi-ccw.c +++ b/hw/s390x/vhost-scsi-ccw.c @@ -62,6 +62,7 @@ static const TypeInfo vhost_ccw_scsi = { .instance_size = sizeof(VHostSCSICcw), .instance_init = vhost_ccw_scsi_instance_init, .class_init = vhost_ccw_scsi_class_init, + .secure = true, }; static void virtio_ccw_scsi_register(void) diff --git a/hw/s390x/vhost-user-fs-ccw.c b/hw/s390x/vhost-user-fs-ccw.c index 35a77e4cb7..6d341dc5e9 100644 --- a/hw/s390x/vhost-user-fs-ccw.c +++ b/hw/s390x/vhost-user-fs-ccw.c @@ -64,6 +64,7 @@ static const TypeInfo vhost_user_fs_ccw = { .instance_size = sizeof(VHostUserFSCcw), .instance_init = vhost_user_fs_ccw_instance_init, .class_init = vhost_user_fs_ccw_class_init, + .secure = true, }; static void vhost_user_fs_ccw_register(void) diff --git a/hw/s390x/vhost-vsock-ccw.c b/hw/s390x/vhost-vsock-ccw.c index efdfdeec84..92b6d177e8 100644 --- a/hw/s390x/vhost-vsock-ccw.c +++ b/hw/s390x/vhost-vsock-ccw.c @@ -71,6 +71,7 @@ static const TypeInfo vhost_vsock_ccw_info = { .instance_size = sizeof(VHostVSockCCWState), .instance_init = vhost_vsock_ccw_instance_init, .class_init = vhost_vsock_ccw_class_init, + .secure = true, }; static void vhost_vsock_ccw_register(void) diff --git a/hw/s390x/virtio-ccw-9p.c b/hw/s390x/virtio-ccw-9p.c index d8612f7cd1..08d3ee577b 100644 --- a/hw/s390x/virtio-ccw-9p.c +++ b/hw/s390x/virtio-ccw-9p.c @@ -64,6 +64,7 @@ static const TypeInfo virtio_ccw_9p_info = { .instance_size = sizeof(V9fsCCWState), .instance_init = virtio_ccw_9p_instance_init, .class_init = virtio_ccw_9p_class_init, + .secure = true, }; static void virtio_ccw_9p_register(void) diff --git a/hw/s390x/virtio-ccw-balloon.c b/hw/s390x/virtio-ccw-balloon.c index 4f67310b69..f7f5640cf1 100644 --- a/hw/s390x/virtio-ccw-balloon.c +++ b/hw/s390x/virtio-ccw-balloon.c @@ -69,6 +69,7 @@ static const TypeInfo virtio_ccw_balloon = { .instance_size = sizeof(VirtIOBalloonCcw), .instance_init = virtio_ccw_balloon_instance_init, .class_init = virtio_ccw_balloon_class_init, + .secure = true, }; static void virtio_ccw_balloon_register(void) diff --git a/hw/s390x/virtio-ccw-blk.c b/hw/s390x/virtio-ccw-blk.c index 939dcaeed3..dd4ac892b2 100644 --- a/hw/s390x/virtio-ccw-blk.c +++ b/hw/s390x/virtio-ccw-blk.c @@ -67,6 +67,7 @@ static const TypeInfo virtio_ccw_blk = { .instance_size = sizeof(VirtIOBlkCcw), .instance_init = virtio_ccw_blk_instance_init, .class_init = virtio_ccw_blk_class_init, + .secure = true, }; static void virtio_ccw_blk_register(void) diff --git a/hw/s390x/virtio-ccw-crypto.c b/hw/s390x/virtio-ccw-crypto.c index 2c4ee2ca39..9f274562ac 100644 --- a/hw/s390x/virtio-ccw-crypto.c +++ b/hw/s390x/virtio-ccw-crypto.c @@ -67,6 +67,7 @@ static const TypeInfo virtio_ccw_crypto = { .instance_size = sizeof(VirtIOCryptoCcw), .instance_init = virtio_ccw_crypto_instance_init, .class_init = virtio_ccw_crypto_class_init, + .secure = true, }; static void virtio_ccw_crypto_register(void) diff --git a/hw/s390x/virtio-ccw-gpu.c b/hw/s390x/virtio-ccw-gpu.c index 4120c6bcb9..79c302860f 100644 --- a/hw/s390x/virtio-ccw-gpu.c +++ b/hw/s390x/virtio-ccw-gpu.c @@ -66,6 +66,7 @@ static const TypeInfo virtio_ccw_gpu = { .instance_size = sizeof(VirtIOGPUCcw), .instance_init = virtio_ccw_gpu_instance_init, .class_init = virtio_ccw_gpu_class_init, + .secure = true, }; module_obj(TYPE_VIRTIO_GPU_CCW); module_kconfig(VIRTIO_CCW); diff --git a/hw/s390x/virtio-ccw-input.c b/hw/s390x/virtio-ccw-input.c index a9ec60428c..1ada4caa15 100644 --- a/hw/s390x/virtio-ccw-input.c +++ b/hw/s390x/virtio-ccw-input.c @@ -96,6 +96,7 @@ static const TypeInfo virtio_ccw_input = { .instance_size = sizeof(VirtIOInputCcw), .class_init = virtio_ccw_input_class_init, .abstract = true, + .secure = true, }; static const TypeInfo virtio_ccw_input_hid = { @@ -103,6 +104,7 @@ static const TypeInfo virtio_ccw_input_hid = { .parent = TYPE_VIRTIO_INPUT_CCW, .instance_size = sizeof(VirtIOInputHIDCcw), .abstract = true, + .secure = true, }; static const TypeInfo virtio_ccw_keyboard = { @@ -110,6 +112,7 @@ static const TypeInfo virtio_ccw_keyboard = { .parent = TYPE_VIRTIO_INPUT_HID_CCW, .instance_size = sizeof(VirtIOInputHIDCcw), .instance_init = virtio_ccw_keyboard_instance_init, + .secure = true, }; static const TypeInfo virtio_ccw_mouse = { @@ -117,6 +120,7 @@ static const TypeInfo virtio_ccw_mouse = { .parent = TYPE_VIRTIO_INPUT_HID_CCW, .instance_size = sizeof(VirtIOInputHIDCcw), .instance_init = virtio_ccw_mouse_instance_init, + .secure = true, }; static const TypeInfo virtio_ccw_tablet = { @@ -124,6 +128,7 @@ static const TypeInfo virtio_ccw_tablet = { .parent = TYPE_VIRTIO_INPUT_HID_CCW, .instance_size = sizeof(VirtIOInputHIDCcw), .instance_init = virtio_ccw_tablet_instance_init, + .secure = true, }; static void virtio_ccw_input_register(void) diff --git a/hw/s390x/virtio-ccw-md.c b/hw/s390x/virtio-ccw-md.c index 0370f58450..9a0264efda 100644 --- a/hw/s390x/virtio-ccw-md.c +++ b/hw/s390x/virtio-ccw-md.c @@ -140,6 +140,7 @@ static const TypeInfo virtio_ccw_md_info = { .instance_size = sizeof(VirtIOMDCcw), .class_size = sizeof(VirtIOMDCcwClass), .abstract = true, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_MEMORY_DEVICE }, { } diff --git a/hw/s390x/virtio-ccw-mem.c b/hw/s390x/virtio-ccw-mem.c index dea30aacfb..7014f0f92e 100644 --- a/hw/s390x/virtio-ccw-mem.c +++ b/hw/s390x/virtio-ccw-mem.c @@ -216,6 +216,7 @@ static const TypeInfo virtio_ccw_mem = { .instance_size = sizeof(VirtIOMEMCcw), .instance_init = virtio_ccw_mem_instance_init, .class_init = virtio_ccw_mem_class_init, + .secure = true, }; static void virtio_ccw_mem_register_types(void) diff --git a/hw/s390x/virtio-ccw-net.c b/hw/s390x/virtio-ccw-net.c index 30e7055ab2..d39311a9f0 100644 --- a/hw/s390x/virtio-ccw-net.c +++ b/hw/s390x/virtio-ccw-net.c @@ -70,6 +70,7 @@ static const TypeInfo virtio_ccw_net = { .instance_size = sizeof(VirtIONetCcw), .instance_init = virtio_ccw_net_instance_init, .class_init = virtio_ccw_net_class_init, + .secure = true, }; static void virtio_ccw_net_register(void) diff --git a/hw/s390x/virtio-ccw-rng.c b/hw/s390x/virtio-ccw-rng.c index 0647621e33..8b62fd9905 100644 --- a/hw/s390x/virtio-ccw-rng.c +++ b/hw/s390x/virtio-ccw-rng.c @@ -66,6 +66,7 @@ static const TypeInfo virtio_ccw_rng = { .instance_size = sizeof(VirtIORNGCcw), .instance_init = virtio_ccw_rng_instance_init, .class_init = virtio_ccw_rng_class_init, + .secure = true, }; static void virtio_ccw_rng_register(void) diff --git a/hw/s390x/virtio-ccw-scsi.c b/hw/s390x/virtio-ccw-scsi.c index c181a2b769..baac329d75 100644 --- a/hw/s390x/virtio-ccw-scsi.c +++ b/hw/s390x/virtio-ccw-scsi.c @@ -76,6 +76,7 @@ static const TypeInfo virtio_ccw_scsi = { .instance_size = sizeof(VirtIOSCSICcw), .instance_init = virtio_ccw_scsi_instance_init, .class_init = virtio_ccw_scsi_class_init, + .secure = true, }; static void virtio_ccw_scsi_register(void) diff --git a/hw/s390x/virtio-ccw-serial.c b/hw/s390x/virtio-ccw-serial.c index 7ff07a0841..9a1686a4dc 100644 --- a/hw/s390x/virtio-ccw-serial.c +++ b/hw/s390x/virtio-ccw-serial.c @@ -76,6 +76,7 @@ static const TypeInfo virtio_ccw_serial = { .instance_size = sizeof(VirtioSerialCcw), .instance_init = virtio_ccw_serial_instance_init, .class_init = virtio_ccw_serial_class_init, + .secure = true, }; static void virtio_ccw_serial_register(void) diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c index d82874ed27..bf01e5a7fa 100644 --- a/hw/s390x/virtio-ccw.c +++ b/hw/s390x/virtio-ccw.c @@ -1264,6 +1264,7 @@ static const TypeInfo virtio_ccw_device_info = { .class_init = virtio_ccw_device_class_init, .class_size = sizeof(VirtIOCCWDeviceClass), .abstract = true, + .secure = true, }; /* virtio-ccw-bus */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417050.1645981 (Exim 4.92) (envelope-from ) id 1x52N0-000473-20; Fri, 11 Sep 2026 14:36:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417050.1645981; Fri, 11 Sep 2026 14:36:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Mz-00046n-UT; Fri, 11 Sep 2026 14:36:49 +0000 Received: by outflank-mailman (input) for mailman id 1417050; Fri, 11 Sep 2026 14:36:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52My-0003rT-J2 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Mx-00EPw8-W7 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:48 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411ea-2eae-0a2a0a5409dd-0a2a450bc0b0-48 for ; Fri, 11 Sep 2026 16:36:47 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa411fe-b7e8-0a2a450b0019-aa0a857cce15-3 for ; Fri, 11 Sep 2026 16:36:47 +0200 Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-586-_kA9vgHhO4OI92Jt3oP7vg-1; Fri, 11 Sep 2026 10:36:43 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D4EE5180074A; Fri, 11 Sep 2026 14:36:41 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 052D53000229; Fri, 11 Sep 2026 14:36:39 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137406; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ITXs1RC82PxSIg8yFFapmKCFNMrOr2p5NsMTwGt6/Sk=; b=ZAwcDkJFMqfERK8I2vz0t3zzDmdkQhkIs/aXeAETMbMK3qyv+XYe7s9m54LQ1Rb5C70SfC t4Znxq2Ed2m7VYci5r35OS/8ql16Cr+C07Z2VnRT4ASduSoQzNXwW0cidFz9UEWpqMJ4Mq l8npFY7agnoc4g4zM1d8a3QwgL/BMoQ= X-MC-Unique: _kA9vgHhO4OI92Jt3oP7vg-1 X-Mimecast-MFC-AGG-ID: _kA9vgHhO4OI92Jt3oP7vg_1789137401 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 05/28] hw: mark all vhost devices a secure Date: Fri, 11 Sep 2026 15:36:04 +0100 Message-ID: <20260911143627.2743803-6-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: 8u2-9snIgGt0TBZK4ZIS0XhW_U2cSAgsCpFtA9t53sY_1789137401 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789137407-A8ECE9EA-B2B6B37C/0/0 X-purgate-type: clean X-purgate-size: 9561 These are all intended for use in a virtualization scenario and must provide a security boundary. Signed-off-by: Daniel P. Berrangé --- hw/block/vhost-user-blk.c | 1 + hw/display/vhost-user-gpu.c | 1 + hw/scsi/vhost-scsi-common.c | 1 + hw/scsi/vhost-scsi.c | 1 + hw/scsi/vhost-user-scsi.c | 1 + hw/virtio/vhost-user-base.c | 3 ++- hw/virtio/vhost-user-fs.c | 1 + hw/virtio/vhost-user-gpio.c | 1 + hw/virtio/vhost-user-i2c.c | 1 + hw/virtio/vhost-user-input.c | 1 + hw/virtio/vhost-user-rng.c | 1 + hw/virtio/vhost-user-rtc.c | 1 + hw/virtio/vhost-user-scmi.c | 1 + hw/virtio/vhost-user-snd.c | 1 + hw/virtio/vhost-user-spi.c | 1 + hw/virtio/vhost-user-test-device.c | 1 + hw/virtio/vhost-user-vsock.c | 1 + hw/virtio/vhost-vsock-common.c | 1 + hw/virtio/vhost-vsock.c | 1 + 19 files changed, 20 insertions(+), 1 deletion(-) diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c index 2e5b3ae1b1..105d77e543 100644 --- a/hw/block/vhost-user-blk.c +++ b/hw/block/vhost-user-blk.c @@ -673,6 +673,7 @@ static const TypeInfo vhost_user_blk_info = { .instance_size = sizeof(VHostUserBlk), .instance_init = vhost_user_blk_instance_init, .class_init = vhost_user_blk_class_init, + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/display/vhost-user-gpu.c b/hw/display/vhost-user-gpu.c index cd684d6363..4204cac483 100644 --- a/hw/display/vhost-user-gpu.c +++ b/hw/display/vhost-user-gpu.c @@ -727,6 +727,7 @@ static const TypeInfo vhost_user_gpu_info = { .instance_init = vhost_user_gpu_instance_init, .instance_finalize = vhost_user_gpu_instance_finalize, .class_init = vhost_user_gpu_class_init, + .secure = true, }; module_obj(TYPE_VHOST_USER_GPU); module_kconfig(VHOST_USER_GPU); diff --git a/hw/scsi/vhost-scsi-common.c b/hw/scsi/vhost-scsi-common.c index e19800a0bc..7b0007a30e 100644 --- a/hw/scsi/vhost-scsi-common.c +++ b/hw/scsi/vhost-scsi-common.c @@ -164,6 +164,7 @@ static const TypeInfo vhost_scsi_common_info = { .parent = TYPE_VIRTIO_SCSI_COMMON, .instance_size = sizeof(VHostSCSICommon), .abstract = true, + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c index 657403cad0..e1f209fabb 100644 --- a/hw/scsi/vhost-scsi.c +++ b/hw/scsi/vhost-scsi.c @@ -400,6 +400,7 @@ static const TypeInfo vhost_scsi_info = { .instance_size = sizeof(VHostSCSI), .class_init = vhost_scsi_class_init, .instance_init = vhost_scsi_instance_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_FW_PATH_PROVIDER }, { } diff --git a/hw/scsi/vhost-user-scsi.c b/hw/scsi/vhost-user-scsi.c index 5070178dc2..8906997051 100644 --- a/hw/scsi/vhost-user-scsi.c +++ b/hw/scsi/vhost-user-scsi.c @@ -425,6 +425,7 @@ static const TypeInfo vhost_user_scsi_info = { .instance_size = sizeof(VHostUserSCSI), .class_init = vhost_user_scsi_class_init, .instance_init = vhost_user_scsi_instance_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_FW_PATH_PROVIDER }, { } diff --git a/hw/virtio/vhost-user-base.c b/hw/virtio/vhost-user-base.c index 478ec68f09..682c06f26b 100644 --- a/hw/virtio/vhost-user-base.c +++ b/hw/virtio/vhost-user-base.c @@ -426,7 +426,8 @@ static const TypeInfo vub_types[] = { .instance_size = sizeof(VHostUserBase), .class_init = vub_class_init, .class_size = sizeof(VHostUserBaseClass), - .abstract = true + .abstract = true, + .secure = true, } }; diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c index 209993918a..9901f84bfb 100644 --- a/hw/virtio/vhost-user-fs.c +++ b/hw/virtio/vhost-user-fs.c @@ -448,6 +448,7 @@ static const TypeInfo vuf_info = { .instance_size = sizeof(VHostUserFS), .instance_init = vuf_instance_init, .class_init = vuf_class_init, + .secure = true, }; static void vuf_register_types(void) diff --git a/hw/virtio/vhost-user-gpio.c b/hw/virtio/vhost-user-gpio.c index d473f87077..cec21106e0 100644 --- a/hw/virtio/vhost-user-gpio.c +++ b/hw/virtio/vhost-user-gpio.c @@ -53,6 +53,7 @@ static const TypeInfo vu_gpio_info = { .parent = TYPE_VHOST_USER_BASE, .instance_size = sizeof(VHostUserGPIO), .class_init = vu_gpio_class_init, + .secure = true, }; static void vu_gpio_register_types(void) diff --git a/hw/virtio/vhost-user-i2c.c b/hw/virtio/vhost-user-i2c.c index 152b1f6740..17b0b44413 100644 --- a/hw/virtio/vhost-user-i2c.c +++ b/hw/virtio/vhost-user-i2c.c @@ -53,6 +53,7 @@ static const TypeInfo vu_i2c_info = { .parent = TYPE_VHOST_USER_BASE, .instance_size = sizeof(VHostUserI2C), .class_init = vu_i2c_class_init, + .secure = true, }; static void vu_i2c_register_types(void) diff --git a/hw/virtio/vhost-user-input.c b/hw/virtio/vhost-user-input.c index 5cfc5bbb56..a850e3770e 100644 --- a/hw/virtio/vhost-user-input.c +++ b/hw/virtio/vhost-user-input.c @@ -47,6 +47,7 @@ static const TypeInfo vhost_input_info = { .parent = TYPE_VHOST_USER_BASE, .instance_size = sizeof(VHostUserInput), .class_init = vhost_input_class_init, + .secure = true, }; static void vhost_input_register_types(void) diff --git a/hw/virtio/vhost-user-rng.c b/hw/virtio/vhost-user-rng.c index 106c8f211a..dc1286559c 100644 --- a/hw/virtio/vhost-user-rng.c +++ b/hw/virtio/vhost-user-rng.c @@ -55,6 +55,7 @@ static const TypeInfo vu_rng_info = { .parent = TYPE_VHOST_USER_BASE, .instance_size = sizeof(VHostUserRNG), .class_init = vu_rng_class_init, + .secure = true, }; static void vu_rng_register_types(void) diff --git a/hw/virtio/vhost-user-rtc.c b/hw/virtio/vhost-user-rtc.c index 88b0c70b90..2cb949590e 100644 --- a/hw/virtio/vhost-user-rtc.c +++ b/hw/virtio/vhost-user-rtc.c @@ -54,6 +54,7 @@ static const TypeInfo vu_rtc_info = { .parent = TYPE_VHOST_USER_BASE, .instance_size = sizeof(VHostUserRTC), .class_init = vu_rtc_class_init, + .secure = true, }; static void vu_rtc_register_types(void) diff --git a/hw/virtio/vhost-user-scmi.c b/hw/virtio/vhost-user-scmi.c index 02dc088ea9..c5f7f0afb0 100644 --- a/hw/virtio/vhost-user-scmi.c +++ b/hw/virtio/vhost-user-scmi.c @@ -310,6 +310,7 @@ static const TypeInfo vu_scmi_info = { .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(VHostUserSCMI), .class_init = vu_scmi_class_init, + .secure = true, }; static void vu_scmi_register_types(void) diff --git a/hw/virtio/vhost-user-snd.c b/hw/virtio/vhost-user-snd.c index 7129b77d9c..3695534aa2 100644 --- a/hw/virtio/vhost-user-snd.c +++ b/hw/virtio/vhost-user-snd.c @@ -72,6 +72,7 @@ static const TypeInfo vu_snd_info = { .parent = TYPE_VHOST_USER_BASE, .instance_size = sizeof(VHostUserSound), .class_init = vu_snd_class_init, + .secure = true, }; static void vu_snd_register_types(void) diff --git a/hw/virtio/vhost-user-spi.c b/hw/virtio/vhost-user-spi.c index 707f96c250..58d5fd7b46 100644 --- a/hw/virtio/vhost-user-spi.c +++ b/hw/virtio/vhost-user-spi.c @@ -55,6 +55,7 @@ static const TypeInfo vu_spi_info = { .parent = TYPE_VHOST_USER_BASE, .instance_size = sizeof(VHostUserSPI), .class_init = vu_spi_class_init, + .secure = true, }; static void vu_spi_register_types(void) diff --git a/hw/virtio/vhost-user-test-device.c b/hw/virtio/vhost-user-test-device.c index a2f963fdf6..73da8af48a 100644 --- a/hw/virtio/vhost-user-test-device.c +++ b/hw/virtio/vhost-user-test-device.c @@ -50,6 +50,7 @@ static const TypeInfo vud_info = { .name = TYPE_VHOST_USER_TEST_DEVICE, .parent = TYPE_VHOST_USER_BASE, .class_init = vud_class_init, + .secure = true, }; static void vu_register_types(void) diff --git a/hw/virtio/vhost-user-vsock.c b/hw/virtio/vhost-user-vsock.c index c2cd376e73..e10ceb95cb 100644 --- a/hw/virtio/vhost-user-vsock.c +++ b/hw/virtio/vhost-user-vsock.c @@ -175,6 +175,7 @@ static const TypeInfo vuv_info = { .parent = TYPE_VHOST_VSOCK_COMMON, .instance_size = sizeof(VHostUserVSock), .class_init = vuv_class_init, + .secure = true, }; static void vuv_register_types(void) diff --git a/hw/virtio/vhost-vsock-common.c b/hw/virtio/vhost-vsock-common.c index b79f4c9ce6..01f7dea6f5 100644 --- a/hw/virtio/vhost-vsock-common.c +++ b/hw/virtio/vhost-vsock-common.c @@ -309,6 +309,7 @@ static const TypeInfo vhost_vsock_common_info = { .instance_size = sizeof(VHostVSockCommon), .class_init = vhost_vsock_common_class_init, .abstract = true, + .secure = true, }; static void vhost_vsock_common_register_types(void) diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c index da244eb165..66a17ee15f 100644 --- a/hw/virtio/vhost-vsock.c +++ b/hw/virtio/vhost-vsock.c @@ -225,6 +225,7 @@ static const TypeInfo vhost_vsock_info = { .parent = TYPE_VHOST_VSOCK_COMMON, .instance_size = sizeof(VHostVSock), .class_init = vhost_vsock_class_init, + .secure = true, }; static void vhost_vsock_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417052.1645990 (Exim 4.92) (envelope-from ) id 1x52N4-0004Su-Ao; Fri, 11 Sep 2026 14:36:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417052.1645990; Fri, 11 Sep 2026 14:36:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52N4-0004Sf-6H; Fri, 11 Sep 2026 14:36:54 +0000 Received: by outflank-mailman (input) for mailman id 1417052; Fri, 11 Sep 2026 14:36:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52N2-0004OG-6P for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52N1-008jWV-Jb for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:51 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411fb-bab6-0a2a0a5309dd-0a2a450295c6-16 for ; Fri, 11 Sep 2026 16:36:51 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41202-6ca4-0a2a45020019-aa0a857cc8bf-3 for ; Fri, 11 Sep 2026 16:36:51 +0200 Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-474-r_vv3jVcPcaZDrubIcVqRg-1; Fri, 11 Sep 2026 10:36:45 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2C87F19539AB; Fri, 11 Sep 2026 14:36:44 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 32CA3300022B; Fri, 11 Sep 2026 14:36:42 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137410; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1yZ5P8bgdNVXz/IjME/g+paRrVamgXXAKRQr0EaewDE=; b=a4Ohp12JRxRyeAj9aOmK39sJin8SMYeSQVpTyFK+DuD/OFTq8noXDGsXDP4cqkcYb72XJK O00DtXlUDgBSc4eF83LjxStO4z9J9HIFNzAQF/7OeSpYhELPj/kFWpChUNJtX6n/HnYzux ChTTr+cLgyXwcLLTEVAvwqjIjJCEvW4= X-MC-Unique: r_vv3jVcPcaZDrubIcVqRg-1 X-Mimecast-MFC-AGG-ID: r_vv3jVcPcaZDrubIcVqRg_1789137404 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 06/28] hw: mark all remaining virtio object types as secure Date: Fri, 11 Sep 2026 15:36:05 +0100 Message-ID: <20260911143627.2743803-7-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: ZHcdJfV1F6X-kBRbEX3gE7sF2-jBlLaTi0x-hErFUEg_1789137404 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789137411-F2EB32AC-BB71FAF5/0/0 X-purgate-type: clean X-purgate-size: 16806 These are all intended for use in a virtualization scenario and must provide a security boundary. Signed-off-by: Daniel P. Berrangé --- hw/9pfs/virtio-9p-device.c | 1 + hw/audio/virtio-snd.c | 1 + hw/block/virtio-blk.c | 1 + hw/char/virtio-console.c | 2 ++ hw/char/virtio-serial-bus.c | 3 +++ hw/display/virtio-gpu-base.c | 3 ++- hw/display/virtio-gpu-gl.c | 1 + hw/display/virtio-gpu-rutabaga.c | 1 + hw/display/virtio-gpu.c | 1 + hw/input/virtio-input-hid.c | 5 +++++ hw/input/virtio-input-host.c | 1 + hw/input/virtio-input.c | 1 + hw/net/virtio-net.c | 1 + hw/scsi/virtio-scsi.c | 2 ++ hw/virtio/vdpa-dev.c | 1 + hw/virtio/virtio-balloon.c | 1 + hw/virtio/virtio-bus.c | 1 + hw/virtio/virtio-crypto.c | 1 + hw/virtio/virtio-input-pci.c | 2 ++ hw/virtio/virtio-iommu.c | 2 ++ hw/virtio/virtio-md-pci.c | 1 + hw/virtio/virtio-mem.c | 1 + hw/virtio/virtio-mmio.c | 2 ++ hw/virtio/virtio-nsm.c | 1 + hw/virtio/virtio-pmem.c | 1 + hw/virtio/virtio-rng.c | 1 + hw/virtio/virtio-rtc.c | 1 + 27 files changed, 39 insertions(+), 1 deletion(-) diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index 2774fc2290..a4572c851d 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -288,6 +288,7 @@ static const TypeInfo virtio_device_info = { .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(V9fsVirtioState), .class_init = virtio_9p_class_init, + .secure = true, }; static void virtio_9p_register_types(void) diff --git a/hw/audio/virtio-snd.c b/hw/audio/virtio-snd.c index 694bcebb60..eacabca5eb 100644 --- a/hw/audio/virtio-snd.c +++ b/hw/audio/virtio-snd.c @@ -1410,6 +1410,7 @@ static const TypeInfo virtio_snd_types[] = { .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(VirtIOSound), .class_init = virtio_snd_class_init, + .secure = true, } }; diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 6b92066aff..bcd252482d 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -1951,6 +1951,7 @@ static const TypeInfo virtio_blk_info = { .instance_init = virtio_blk_instance_init, .class_init = virtio_blk_class_init, .class_size = sizeof(VirtIOBlkClass), + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/char/virtio-console.c b/hw/char/virtio-console.c index 4737b9a56e..e5798a5f4b 100644 --- a/hw/char/virtio-console.c +++ b/hw/char/virtio-console.c @@ -266,6 +266,7 @@ static const TypeInfo virtconsole_info = { .name = "virtconsole", .parent = TYPE_VIRTIO_CONSOLE_SERIAL_PORT, .class_init = virtconsole_class_init, + .secure = true, }; static const Property virtserialport_properties[] = { @@ -291,6 +292,7 @@ static const TypeInfo virtserialport_info = { .parent = TYPE_VIRTIO_SERIAL_PORT, .instance_size = sizeof(VirtConsole), .class_init = virtserialport_class_init, + .secure = true, }; static void virtconsole_register_types(void) diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c index 83a033ce85..60ef9c4f10 100644 --- a/hw/char/virtio-serial-bus.c +++ b/hw/char/virtio-serial-bus.c @@ -836,6 +836,7 @@ static const TypeInfo virtser_bus_info = { .parent = TYPE_BUS, .instance_size = sizeof(VirtIOSerialBus), .class_init = virtser_bus_class_init, + .secure = true, }; #ifdef CONFIG_HMP @@ -1091,6 +1092,7 @@ static const TypeInfo virtio_serial_port_type_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(VirtIOSerialPort), .abstract = true, + .secure = true, .class_size = sizeof(VirtIOSerialPortClass), .class_init = virtio_serial_port_class_init, }; @@ -1169,6 +1171,7 @@ static const TypeInfo virtio_device_info = { .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(VirtIOSerial), .class_init = virtio_serial_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c index 270fbaae10..7a78d1ee83 100644 --- a/hw/display/virtio-gpu-base.c +++ b/hw/display/virtio-gpu-base.c @@ -320,7 +320,8 @@ static const TypeInfo virtio_gpu_base_info = { .instance_size = sizeof(VirtIOGPUBase), .class_size = sizeof(VirtIOGPUBaseClass), .class_init = virtio_gpu_base_class_init, - .abstract = true + .abstract = true, + .secure = true, }; module_obj(TYPE_VIRTIO_GPU_BASE); module_kconfig(VIRTIO_GPU); diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c index 2b7a41c466..75174b6731 100644 --- a/hw/display/virtio-gpu-gl.c +++ b/hw/display/virtio-gpu-gl.c @@ -233,6 +233,7 @@ static const TypeInfo virtio_gpu_gl_info = { .parent = TYPE_VIRTIO_GPU, .instance_size = sizeof(VirtIOGPUGL), .class_init = virtio_gpu_gl_class_init, + .secure = true, }; module_obj(TYPE_VIRTIO_GPU_GL); module_kconfig(VIRTIO_GPU); diff --git a/hw/display/virtio-gpu-rutabaga.c b/hw/display/virtio-gpu-rutabaga.c index 041216a10d..aba37efec5 100644 --- a/hw/display/virtio-gpu-rutabaga.c +++ b/hw/display/virtio-gpu-rutabaga.c @@ -1170,6 +1170,7 @@ static const TypeInfo virtio_gpu_rutabaga_info[] = { .parent = TYPE_VIRTIO_GPU, .instance_size = sizeof(VirtIOGPURutabaga), .class_init = virtio_gpu_rutabaga_class_init, + .secure = true, }, }; diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c index 55a1c7f80f..b1629a28f1 100644 --- a/hw/display/virtio-gpu.c +++ b/hw/display/virtio-gpu.c @@ -1915,6 +1915,7 @@ static const TypeInfo virtio_gpu_info = { .instance_size = sizeof(VirtIOGPU), .class_size = sizeof(VirtIOGPUClass), .class_init = virtio_gpu_class_init, + .secure = true, }; module_obj(TYPE_VIRTIO_GPU); module_kconfig(VIRTIO_GPU); diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c index 1019d6b2e5..4854860807 100644 --- a/hw/input/virtio-input-hid.c +++ b/hw/input/virtio-input-hid.c @@ -242,6 +242,7 @@ static const TypeInfo virtio_input_hid_info = { .instance_size = sizeof(VirtIOInputHID), .class_init = virtio_input_hid_class_init, .abstract = true, + .secure = true, }; /* ----------------------------------------------------------------- */ @@ -315,6 +316,7 @@ static const TypeInfo virtio_keyboard_info = { .parent = TYPE_VIRTIO_INPUT_HID, .instance_size = sizeof(VirtIOInputHID), .instance_init = virtio_keyboard_init, + .secure = true, }; /* ----------------------------------------------------------------- */ @@ -369,6 +371,7 @@ static const TypeInfo virtio_mouse_info = { .parent = TYPE_VIRTIO_INPUT_HID, .instance_size = sizeof(VirtIOInputHID), .instance_init = virtio_mouse_init, + .secure = true, }; /* ----------------------------------------------------------------- */ @@ -442,6 +445,7 @@ static const TypeInfo virtio_tablet_info = { .parent = TYPE_VIRTIO_INPUT_HID, .instance_size = sizeof(VirtIOInputHID), .instance_init = virtio_tablet_init, + .secure = true, }; /* ----------------------------------------------------------------- */ @@ -527,6 +531,7 @@ static const TypeInfo virtio_multitouch_info = { .parent = TYPE_VIRTIO_INPUT_HID, .instance_size = sizeof(VirtIOInputHID), .instance_init = virtio_multitouch_init, + .secure = true, }; /* ----------------------------------------------------------------- */ diff --git a/hw/input/virtio-input-host.c b/hw/input/virtio-input-host.c index 633547cc4f..0d01e00cfc 100644 --- a/hw/input/virtio-input-host.c +++ b/hw/input/virtio-input-host.c @@ -248,6 +248,7 @@ static const TypeInfo virtio_input_host_info = { .instance_size = sizeof(VirtIOInputHost), .instance_init = virtio_input_host_init, .class_init = virtio_input_host_class_init, + .secure = true, }; /* ----------------------------------------------------------------- */ diff --git a/hw/input/virtio-input.c b/hw/input/virtio-input.c index 6494cfbbe8..cccbeec1e3 100644 --- a/hw/input/virtio-input.c +++ b/hw/input/virtio-input.c @@ -329,6 +329,7 @@ static const TypeInfo virtio_input_info = { .class_size = sizeof(VirtIOInputClass), .class_init = virtio_input_class_init, .abstract = true, + .secure = true, .instance_finalize = virtio_input_finalize, }; diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c index 814b99a43d..506a0366dc 100644 --- a/hw/net/virtio-net.c +++ b/hw/net/virtio-net.c @@ -4374,6 +4374,7 @@ static const TypeInfo virtio_net_info = { .instance_size = sizeof(VirtIONet), .instance_init = virtio_net_instance_init, .class_init = virtio_net_class_init, + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c index bf64d1231a..0fa3f11a43 100644 --- a/hw/scsi/virtio-scsi.c +++ b/hw/scsi/virtio-scsi.c @@ -1444,6 +1444,7 @@ static const TypeInfo virtio_scsi_common_info = { .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(VirtIOSCSICommon), .abstract = true, + .secure = true, .class_init = virtio_scsi_common_class_init, }; @@ -1452,6 +1453,7 @@ static const TypeInfo virtio_scsi_info = { .parent = TYPE_VIRTIO_SCSI_COMMON, .instance_size = sizeof(VirtIOSCSI), .class_init = virtio_scsi_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } diff --git a/hw/virtio/vdpa-dev.c b/hw/virtio/vdpa-dev.c index 6dc684ab09..bd95467652 100644 --- a/hw/virtio/vdpa-dev.c +++ b/hw/virtio/vdpa-dev.c @@ -392,6 +392,7 @@ static const TypeInfo vhost_vdpa_device_info = { .instance_size = sizeof(VhostVdpaDevice), .class_init = vhost_vdpa_device_class_init, .instance_init = vhost_vdpa_device_instance_init, + .secure = true, }; static void register_vhost_vdpa_device_type(void) diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c index 4c5f486ba2..4d1c81e7d6 100644 --- a/hw/virtio/virtio-balloon.c +++ b/hw/virtio/virtio-balloon.c @@ -1083,6 +1083,7 @@ static const TypeInfo virtio_balloon_info = { .instance_size = sizeof(VirtIOBalloon), .instance_init = virtio_balloon_instance_init, .class_init = virtio_balloon_class_init, + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c index 9b545acda3..9bf62a7060 100644 --- a/hw/virtio/virtio-bus.c +++ b/hw/virtio/virtio-bus.c @@ -363,6 +363,7 @@ static const TypeInfo virtio_bus_info = { .parent = TYPE_BUS, .instance_size = sizeof(VirtioBusState), .abstract = true, + .secure = true, .class_size = sizeof(VirtioBusClass), .class_init = virtio_bus_class_init }; diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c index 79e2acb56c..7d4c944f35 100644 --- a/hw/virtio/virtio-crypto.c +++ b/hw/virtio/virtio-crypto.c @@ -1314,6 +1314,7 @@ static const TypeInfo virtio_crypto_info = { .instance_size = sizeof(VirtIOCrypto), .instance_init = virtio_crypto_instance_init, .class_init = virtio_crypto_class_init, + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/virtio/virtio-input-pci.c b/hw/virtio/virtio-input-pci.c index cd35608460..3605f990fd 100644 --- a/hw/virtio/virtio-input-pci.c +++ b/hw/virtio/virtio-input-pci.c @@ -117,6 +117,7 @@ static const TypeInfo virtio_input_pci_info = { .instance_size = sizeof(VirtIOInputPCI), .class_init = virtio_input_pci_class_init, .abstract = true, + .secure = true, }; static const TypeInfo virtio_input_hid_pci_info = { @@ -124,6 +125,7 @@ static const TypeInfo virtio_input_hid_pci_info = { .parent = TYPE_VIRTIO_INPUT_PCI, .instance_size = sizeof(VirtIOInputHIDPCI), .abstract = true, + .secure = true, }; static const VirtioPCIDeviceTypeInfo virtio_keyboard_pci_info = { diff --git a/hw/virtio/virtio-iommu.c b/hw/virtio/virtio-iommu.c index 533bd5073f..5f1920253b 100644 --- a/hw/virtio/virtio-iommu.c +++ b/hw/virtio/virtio-iommu.c @@ -1734,12 +1734,14 @@ static const TypeInfo virtio_iommu_info = { .instance_size = sizeof(VirtIOIOMMU), .instance_init = virtio_iommu_instance_init, .class_init = virtio_iommu_class_init, + .secure = true, }; static const TypeInfo virtio_iommu_memory_region_info = { .parent = TYPE_IOMMU_MEMORY_REGION, .name = TYPE_VIRTIO_IOMMU_MEMORY_REGION, .class_init = virtio_iommu_memory_region_class_init, + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/virtio/virtio-md-pci.c b/hw/virtio/virtio-md-pci.c index 9278b32cf8..9eefb84daa 100644 --- a/hw/virtio/virtio-md-pci.c +++ b/hw/virtio/virtio-md-pci.c @@ -138,6 +138,7 @@ static const TypeInfo virtio_md_pci_info = { .instance_size = sizeof(VirtIOMDPCI), .class_size = sizeof(VirtIOMDPCIClass), .abstract = true, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_MEMORY_DEVICE }, { } diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c index 7130ed852d..edad9465cb 100644 --- a/hw/virtio/virtio-mem.c +++ b/hw/virtio/virtio-mem.c @@ -1668,6 +1668,7 @@ static const TypeInfo virtio_mem_info = { .instance_finalize = virtio_mem_instance_finalize, .class_init = virtio_mem_class_init, .class_size = sizeof(VirtIOMEMClass), + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_RAM_DISCARD_SOURCE }, { } diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c index 55ceaeef5f..f51c8d17b9 100644 --- a/hw/virtio/virtio-mmio.c +++ b/hw/virtio/virtio-mmio.c @@ -779,6 +779,7 @@ static const TypeInfo virtio_mmio_info = { .parent = TYPE_SYS_BUS_DEVICE, .instance_size = sizeof(VirtIOMMIOProxy), .class_init = virtio_mmio_class_init, + .secure = true, }; /* virtio-mmio-bus. */ @@ -848,6 +849,7 @@ static const TypeInfo virtio_mmio_bus_info = { .parent = TYPE_VIRTIO_BUS, .instance_size = sizeof(VirtioBusState), .class_init = virtio_mmio_bus_class_init, + .secure = true, }; static void virtio_mmio_register_types(void) diff --git a/hw/virtio/virtio-nsm.c b/hw/virtio/virtio-nsm.c index 3bf5e7009a..099342f379 100644 --- a/hw/virtio/virtio-nsm.c +++ b/hw/virtio/virtio-nsm.c @@ -1727,6 +1727,7 @@ static const TypeInfo virtio_nsm_info = { .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(VirtIONSM), .class_init = virtio_nsm_class_init, + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/virtio/virtio-pmem.c b/hw/virtio/virtio-pmem.c index 6f7271c140..1a414d7ba2 100644 --- a/hw/virtio/virtio-pmem.c +++ b/hw/virtio/virtio-pmem.c @@ -196,6 +196,7 @@ static const TypeInfo virtio_pmem_info = { .class_size = sizeof(VirtIOPMEMClass), .class_init = virtio_pmem_class_init, .instance_size = sizeof(VirtIOPMEM), + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/virtio/virtio-rng.c b/hw/virtio/virtio-rng.c index d68d901195..ba80138179 100644 --- a/hw/virtio/virtio-rng.c +++ b/hw/virtio/virtio-rng.c @@ -282,6 +282,7 @@ static const TypeInfo virtio_rng_info = { .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(VirtIORNG), .class_init = virtio_rng_class_init, + .secure = true, }; static void virtio_register_types(void) diff --git a/hw/virtio/virtio-rtc.c b/hw/virtio/virtio-rtc.c index 32de9c1650..08071aadb5 100644 --- a/hw/virtio/virtio-rtc.c +++ b/hw/virtio/virtio-rtc.c @@ -180,6 +180,7 @@ static const TypeInfo virtio_rtc_info = { .parent = TYPE_VIRTIO_DEVICE, .instance_size = sizeof(VirtIORtc), .class_init = virtio_rtc_class_init, + .secure = true, }; static void virtio_rtc_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417053.1645996 (Exim 4.92) (envelope-from ) id 1x52N4-0004ZY-Ty; Fri, 11 Sep 2026 14:36:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417053.1645996; Fri, 11 Sep 2026 14:36:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52N4-0004Yk-Md; Fri, 11 Sep 2026 14:36:54 +0000 Received: by outflank-mailman (input) for mailman id 1417053; Fri, 11 Sep 2026 14:36:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52N3-0004Qa-67 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52N2-008jZK-JN for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:52 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41202-2eae-0a2a0a5409dd-0a2a4501e918-6 for ; Fri, 11 Sep 2026 16:36:52 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41203-5984-0a2a45010019-aa0a817cddaf-3 for ; Fri, 11 Sep 2026 16:36:52 +0200 Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-501-5ZpW9R8YOlqZCbyG5RZybg-1; Fri, 11 Sep 2026 10:36:47 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5D34A18011D5; Fri, 11 Sep 2026 14:36:46 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 66E99300022B; Fri, 11 Sep 2026 14:36:44 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hYxcms/b3tvYKg41L3PAN6QuGuhC66PDVuW5tlA0LrY=; b=i4YeUp0q5xRIqjlPq4ucmZ+2Oeb/wJAMLNkhXY6YzLxGD0HX4gxX0d5F/eHfzOSLtCKPwW P2S3ujqE1yFaxTmv03SPDuPuTEdZwSAc4ps0OUarKI7gi8qXo6POoYfLe+c3Cz2Taqlu6g e/MzJBuDBL4fV/DtEYEqjA3ZamUFSAM= X-MC-Unique: 5ZpW9R8YOlqZCbyG5RZybg-1 X-Mimecast-MFC-AGG-ID: 5ZpW9R8YOlqZCbyG5RZybg_1789137406 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 07/28] hw/vfio: mark all VFIO object classes as secure Date: Fri, 11 Sep 2026 15:36:06 +0100 Message-ID: <20260911143627.2743803-8-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: r-QmuhgoO5_1D3e3N2gdtHVobpmIRnaWkLBuxga1At4_1789137406 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1789137412-BE07B757-A0B63C73/0/0 X-purgate-type: clean X-purgate-size: 4497 The VFIO subsystem is about securely passing host PCI devices to a guest, so all the classes should be presumed to be offering a security boundary. Signed-off-by: Daniel P. Berrangé --- hw/vfio-user/pci.c | 1 + hw/vfio/ap.c | 1 + hw/vfio/ccw.c | 1 + hw/vfio/container.c | 1 + hw/vfio/igd.c | 1 + hw/vfio/iommufd.c | 2 ++ hw/vfio/pci.c | 3 +++ hw/vfio/spapr.c | 1 + 8 files changed, 11 insertions(+) diff --git a/hw/vfio-user/pci.c b/hw/vfio-user/pci.c index e7573d4a9f..ae26160f72 100644 --- a/hw/vfio-user/pci.c +++ b/hw/vfio-user/pci.c @@ -482,6 +482,7 @@ static const TypeInfo vfio_user_pci_info = { .class_init = vfio_user_pci_class_init, .instance_init = vfio_user_pci_init, .instance_finalize = vfio_user_pci_finalize, + .secure = true, }; static void register_vfio_user_dev_type(void) diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c index 6e2a1223ea..4b9d522f7b 100644 --- a/hw/vfio/ap.c +++ b/hw/vfio/ap.c @@ -352,6 +352,7 @@ static const TypeInfo vfio_ap_info = { .instance_size = sizeof(VFIOAPDevice), .instance_init = vfio_ap_instance_init, .class_init = vfio_ap_class_init, + .secure = true, }; static void vfio_ap_type_init(void) diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c index c3dc7c1962..7a241aa02a 100644 --- a/hw/vfio/ccw.c +++ b/hw/vfio/ccw.c @@ -721,6 +721,7 @@ static const TypeInfo vfio_ccw_info = { .instance_size = sizeof(VFIOCCWDevice), .instance_init = vfio_ccw_instance_init, .class_init = vfio_ccw_class_init, + .secure = true, }; static void register_vfio_ccw_type(void) diff --git a/hw/vfio/container.c b/hw/vfio/container.c index d09a663732..d4f20c6c81 100644 --- a/hw/vfio/container.c +++ b/hw/vfio/container.c @@ -336,6 +336,7 @@ static const TypeInfo types[] = { .instance_size = sizeof(VFIOContainer), .class_size = sizeof(VFIOIOMMUClass), .abstract = true, + .secure = true, }, }; diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c index 413a49aae9..e9cef355f9 100644 --- a/hw/vfio/igd.c +++ b/hw/vfio/igd.c @@ -311,6 +311,7 @@ static const TypeInfo vfio_pci_igd_lpc_bridge_info = { .name = "vfio-pci-igd-lpc-bridge", .parent = TYPE_PCI_DEVICE, .class_init = vfio_pci_igd_lpc_bridge_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c index 242644aa00..64e588fe51 100644 --- a/hw/vfio/iommufd.c +++ b/hw/vfio/iommufd.c @@ -1051,10 +1051,12 @@ static const TypeInfo types[] = { .parent = TYPE_VFIO_IOMMU, .instance_size = sizeof(VFIOIOMMUFDContainer), .class_init = vfio_iommu_iommufd_class_init, + .secure = true, }, { .name = TYPE_HOST_IOMMU_DEVICE_IOMMUFD_VFIO, .parent = TYPE_HOST_IOMMU_DEVICE_IOMMUFD, .class_init = hiod_iommufd_vfio_class_init, + .secure = true, } }; diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index 428ab2f069..b38877a1a8 100644 --- a/hw/vfio/pci.c +++ b/hw/vfio/pci.c @@ -3854,6 +3854,7 @@ static const TypeInfo vfio_pci_device_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(VFIOPCIDevice), .abstract = true, + .secure = true, .class_init = vfio_pci_device_class_init, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, @@ -4110,6 +4111,7 @@ static const TypeInfo vfio_pci_info = { .class_init = vfio_pci_class_init, .instance_init = vfio_pci_init, .instance_finalize = vfio_pci_finalize, + .secure = true, }; static const Property vfio_pci_nohotplug_properties[] = { @@ -4146,6 +4148,7 @@ static const TypeInfo vfio_pci_nohotplug_info = { .parent = TYPE_VFIO_PCI, .instance_size = sizeof(VFIOPCIDevice), .class_init = vfio_pci_nohotplug_class_init, + .secure = true, }; static void register_vfio_pci_dev_type(void) diff --git a/hw/vfio/spapr.c b/hw/vfio/spapr.c index 42690e4323..1027c434c0 100644 --- a/hw/vfio/spapr.c +++ b/hw/vfio/spapr.c @@ -544,6 +544,7 @@ static const TypeInfo types[] = { .parent = TYPE_VFIO_IOMMU_LEGACY, .instance_size = sizeof(VFIOSpaprContainer), .class_init = vfio_iommu_spapr_class_init, + .secure = true, }, }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:36:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:36:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417058.1646009 (Exim 4.92) (envelope-from ) id 1x52N7-00052r-9S; Fri, 11 Sep 2026 14:36:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417058.1646009; Fri, 11 Sep 2026 14:36:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52N7-00052X-4V; Fri, 11 Sep 2026 14:36:57 +0000 Received: by outflank-mailman (input) for mailman id 1417058; Fri, 11 Sep 2026 14:36:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52N5-0004ic-Kq for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52N5-008jZK-1L for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:55 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41202-2eae-0a2a0a5409dd-0a2a4501e918-16 for ; Fri, 11 Sep 2026 16:36:54 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41205-5984-0a2a45010019-aa0a817ce18d-3 for ; Fri, 11 Sep 2026 16:36:54 +0200 Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-1-RjoLMoGTNgqEVSmrTvbZWw-1; Fri, 11 Sep 2026 10:36:50 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 888A219539B0; Fri, 11 Sep 2026 14:36:48 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B23C63000229; Fri, 11 Sep 2026 14:36:46 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wcQmW3FrWiONRvVo20iIDURaSW8/Kg4toOjkYAWSQ3E=; b=i4qh9euHANItTbnaqhWCAM4HuHrWfSy0uXD21oLpi3VzniLI3hsLmW44CkdnVyf7Qgp+LK l13aVc/h1zEKYbWl1T0mGDWHEFRY5SFh9vZ1Q5rMs+JK2R7VbPiEKY+SA+Xixx0fAp+U9k dHuRu64QB2enjFUiLk9hAx1Dkzwf4nw= X-MC-Unique: RjoLMoGTNgqEVSmrTvbZWw-1 X-Mimecast-MFC-AGG-ID: RjoLMoGTNgqEVSmrTvbZWw_1789137408 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 08/28] hw/xen: mark all Xen related object types as being secure Date: Fri, 11 Sep 2026 15:36:07 +0100 Message-ID: <20260911143627.2743803-9-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: b99NS5PvbIuiEzMRq8r1ZzSP_E6qXnefuOEc50IDb9E_1789137408 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1789137414-C4B45757-E36DEFD3/0/0 X-purgate-type: clean X-purgate-size: 5925 All Xen paravirtualized devices are intended to provide a host / guest security barrier, so mark all Xen object types as scure. Signed-off-by: Daniel P. Berrangé --- hw/block/xen-block.c | 3 +++ hw/char/xen_console.c | 1 + hw/i386/xen/xen_platform.c | 1 + hw/i386/xen/xen_pvdevice.c | 1 + hw/net/xen_nic.c | 1 + hw/xen/xen-bus.c | 3 +++ hw/xen/xen-legacy-backend.c | 3 +++ hw/xen/xen_pt.c | 1 + 8 files changed, 14 insertions(+) diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c index 474c12fe4a..3296e591d4 100644 --- a/hw/block/xen-block.c +++ b/hw/block/xen-block.c @@ -699,6 +699,7 @@ static const TypeInfo xen_block_type_info = { .parent = TYPE_XEN_DEVICE, .instance_size = sizeof(XenBlockDevice), .abstract = true, + .secure = true, .class_size = sizeof(XenBlockDeviceClass), .class_init = xen_block_class_init, }; @@ -740,6 +741,7 @@ static const TypeInfo xen_disk_type_info = { .parent = TYPE_XEN_BLOCK_DEVICE, .instance_size = sizeof(XenDiskDevice), .class_init = xen_disk_class_init, + .secure = true, }; static void xen_cdrom_unrealize(XenBlockDevice *blockdev) @@ -787,6 +789,7 @@ static const TypeInfo xen_cdrom_type_info = { .parent = TYPE_XEN_BLOCK_DEVICE, .instance_size = sizeof(XenCDRomDevice), .class_init = xen_cdrom_class_init, + .secure = true, }; static void xen_block_register_types(void) diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c index bdeb76dc87..df6a708494 100644 --- a/hw/char/xen_console.c +++ b/hw/char/xen_console.c @@ -513,6 +513,7 @@ static const TypeInfo xen_console_type_info = { .parent = TYPE_XEN_DEVICE, .instance_size = sizeof(XenConsole), .class_init = xen_console_class_init, + .secure = true, }; static void xen_console_register_types(void) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index c8b852be0c..ec0084d6fb 100644 --- a/hw/i386/xen/xen_platform.c +++ b/hw/i386/xen/xen_platform.c @@ -604,6 +604,7 @@ static const TypeInfo xen_platform_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(PCIXenPlatformState), .class_init = xen_platform_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/i386/xen/xen_pvdevice.c b/hw/i386/xen/xen_pvdevice.c index fab26a06af..74636046d0 100644 --- a/hw/i386/xen/xen_pvdevice.c +++ b/hw/i386/xen/xen_pvdevice.c @@ -139,6 +139,7 @@ static const TypeInfo xen_pv_type_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(XenPVDevice), .class_init = xen_pv_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c index f4d0b06013..e615303da6 100644 --- a/hw/net/xen_nic.c +++ b/hw/net/xen_nic.c @@ -579,6 +579,7 @@ static const TypeInfo xen_net_type_info = { .parent = TYPE_XEN_DEVICE, .instance_size = sizeof(XenNetDev), .class_init = xen_netdev_class_init, + .secure = true, }; static void xen_net_register_types(void) diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c index 1762816bf4..4623995e2c 100644 --- a/hw/xen/xen-bus.c +++ b/hw/xen/xen-bus.c @@ -404,6 +404,7 @@ static const TypeInfo xen_bus_type_info = { .instance_size = sizeof(XenBus), .class_size = sizeof(XenBusClass), .class_init = xen_bus_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } @@ -1127,6 +1128,7 @@ static const TypeInfo xen_device_type_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(XenDevice), .abstract = true, + .secure = true, .class_size = sizeof(XenDeviceClass), .class_init = xen_device_class_init, }; @@ -1141,6 +1143,7 @@ static const TypeInfo xen_bridge_type_info = { .name = TYPE_XEN_BRIDGE, .parent = TYPE_SYS_BUS_DEVICE, .instance_size = sizeof(XenBridge), + .secure = true, }; static void xen_register_types(void) diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c index 7977b52712..75f8ac7efd 100644 --- a/hw/xen/xen-legacy-backend.c +++ b/hw/xen/xen-legacy-backend.c @@ -648,6 +648,7 @@ static const TypeInfo xendev_type_info = { .parent = TYPE_DYNAMIC_SYS_BUS_DEVICE, .class_init = xendev_class_init, .instance_size = sizeof(XenLegacyDevice), + .secure = true, }; static void xen_sysbus_class_init(ObjectClass *klass, const void *data) @@ -661,6 +662,7 @@ static const TypeInfo xensysbus_info = { .name = TYPE_XENSYSBUS, .parent = TYPE_BUS, .class_init = xen_sysbus_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } @@ -670,6 +672,7 @@ static const TypeInfo xensysbus_info = { static const TypeInfo xensysdev_info = { .name = TYPE_XENSYSDEV, .parent = TYPE_SYS_BUS_DEVICE, + .secure = true, }; static void xenbe_register_types(void) diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index 0fe9c0aada..504c559318 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -1079,6 +1079,7 @@ static const TypeInfo xen_pci_passthrough_info = { .instance_finalize = xen_pci_passthrough_finalize, .class_init = xen_pci_passthrough_class_init, .class_size = sizeof(XenPTDeviceClass), + .secure = true, .instance_init = xen_pci_passthrough_instance_init, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417061.1646017 (Exim 4.92) (envelope-from ) id 1x52NA-0005S6-JZ; Fri, 11 Sep 2026 14:37:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417061.1646017; Fri, 11 Sep 2026 14:37:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NA-0005Rq-FG; Fri, 11 Sep 2026 14:37:00 +0000 Received: by outflank-mailman (input) for mailman id 1417061; Fri, 11 Sep 2026 14:36:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52N8-0005KK-NP for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52N8-009XnU-48 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:58 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411ff-e002-0a2a0a5209dd-0a2a450a88f0-20 for ; Fri, 11 Sep 2026 16:36:58 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41208-f2d2-0a2a450a0019-aa0a817cce3b-3 for ; Fri, 11 Sep 2026 16:36:57 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-199-27VQIONhO4KFnGqpGIUqNw-1; Fri, 11 Sep 2026 10:36:54 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1D0951955D88; Fri, 11 Sep 2026 14:36:53 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 286133000229; Fri, 11 Sep 2026 14:36:50 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137416; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1RHIZmJ27HpBLHk1UKD1lxc6VROjUi/8BfHOVvo5jR8=; b=HYtyfdyqVB/bLr4hTWEDi5IyTj7xiyCGYiie0TKjijceTdz5Yxm2YazUD5dLjvvphX9lRv gf77CeE4tECwNCdCyb9u8WFXbk7ggmlATIAc5C4VKC0eRiZPzhmmiEb55VUG3y0n1ofqAv cr1cH7bHZ5zaB/ZGKggQ5EefeFJjBfM= X-MC-Unique: 27VQIONhO4KFnGqpGIUqNw-1 X-Mimecast-MFC-AGG-ID: 27VQIONhO4KFnGqpGIUqNw_1789137413 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 10/28] hw/usb: mark commonly used USB devices/hosts as secure Date: Fri, 11 Sep 2026 15:36:09 +0100 Message-ID: <20260911143627.2743803-11-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: fMivSlL4ySWGL5XZ66YqlueQUHrzopr13tR0RjRlRLY_1789137413 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1789137418-585CBCFC-B5F80DC6/0/0 X-purgate-type: clean X-purgate-size: 13625 Most of the standardized USB1/2/3 host controllers are relevant for virtualization use cases, so should be declared secure. The "NEC" XHCI variant is slightly non-standard, but since it is a trivial sub-class of the generic XHCI, there's no reason to exclude it. The set of devices that are expected to be used is HID (mouse, tablet, keyboard), host passthrough, CCID (smartcard), hub, storage and the redirect tunnelling. Signed-off-by: Daniel P. Berrangé --- hw/usb/ccid-card-emulated.c | 1 + hw/usb/ccid-card-passthru.c | 1 + hw/usb/dev-hid.c | 4 ++++ hw/usb/dev-hub.c | 1 + hw/usb/dev-smartcard-reader.c | 3 +++ hw/usb/dev-storage-bot.c | 1 + hw/usb/dev-storage-classic.c | 1 + hw/usb/dev-storage.c | 1 + hw/usb/hcd-ehci-pci.c | 2 ++ hw/usb/hcd-ehci-sysbus.c | 8 ++++++++ hw/usb/hcd-ohci-pci.c | 1 + hw/usb/hcd-ohci-sysbus.c | 1 + hw/usb/hcd-uhci.c | 2 ++ hw/usb/hcd-xhci-nec.c | 1 + hw/usb/hcd-xhci-pci.c | 2 ++ hw/usb/hcd-xhci-sysbus.c | 3 ++- hw/usb/hcd-xhci.c | 1 + hw/usb/host-libusb.c | 1 + hw/usb/redirect.c | 1 + 19 files changed, 35 insertions(+), 1 deletion(-) diff --git a/hw/usb/ccid-card-emulated.c b/hw/usb/ccid-card-emulated.c index 985f21997a..f10295c675 100644 --- a/hw/usb/ccid-card-emulated.c +++ b/hw/usb/ccid-card-emulated.c @@ -610,6 +610,7 @@ static const TypeInfo emulated_card_info = { .parent = TYPE_CCID_CARD, .instance_size = sizeof(EmulatedState), .class_init = emulated_class_initfn, + .secure = true, }; module_obj(TYPE_EMULATED_CCID); module_kconfig(USB); diff --git a/hw/usb/ccid-card-passthru.c b/hw/usb/ccid-card-passthru.c index 5ab7855272..b91f32ebd6 100644 --- a/hw/usb/ccid-card-passthru.c +++ b/hw/usb/ccid-card-passthru.c @@ -412,6 +412,7 @@ static const TypeInfo passthru_card_info = { .parent = TYPE_CCID_CARD, .instance_size = sizeof(PassthruState), .class_init = passthru_class_initfn, + .secure = true, }; module_obj(TYPE_CCID_PASSTHRU); module_kconfig(USB); diff --git a/hw/usb/dev-hid.c b/hw/usb/dev-hid.c index ae19d60203..7fa9a4b010 100644 --- a/hw/usb/dev-hid.c +++ b/hw/usb/dev-hid.c @@ -790,6 +790,7 @@ static const TypeInfo usb_hid_type_info = { .parent = TYPE_USB_DEVICE, .instance_size = sizeof(USBHIDState), .abstract = true, + .secure = true, .class_init = usb_hid_class_initfn, }; @@ -815,6 +816,7 @@ static const TypeInfo usb_tablet_info = { .name = "usb-tablet", .parent = TYPE_USB_HID, .class_init = usb_tablet_class_initfn, + .secure = true, }; static const Property usb_mouse_properties[] = { @@ -837,6 +839,7 @@ static const TypeInfo usb_mouse_info = { .name = "usb-mouse", .parent = TYPE_USB_HID, .class_init = usb_mouse_class_initfn, + .secure = true, }; static const Property usb_keyboard_properties[] = { @@ -860,6 +863,7 @@ static const TypeInfo usb_keyboard_info = { .name = "usb-kbd", .parent = TYPE_USB_HID, .class_init = usb_keyboard_class_initfn, + .secure = true, }; static void usb_hid_register_types(void) diff --git a/hw/usb/dev-hub.c b/hw/usb/dev-hub.c index b45d571fa8..7017b4fbc7 100644 --- a/hw/usb/dev-hub.c +++ b/hw/usb/dev-hub.c @@ -694,6 +694,7 @@ static const TypeInfo hub_info = { .parent = TYPE_USB_DEVICE, .instance_size = sizeof(USBHubState), .class_init = usb_hub_class_initfn, + .secure = true, }; static void usb_hub_register_types(void) diff --git a/hw/usb/dev-smartcard-reader.c b/hw/usb/dev-smartcard-reader.c index 964c142d10..d661c7687f 100644 --- a/hw/usb/dev-smartcard-reader.c +++ b/hw/usb/dev-smartcard-reader.c @@ -1178,6 +1178,7 @@ static const TypeInfo ccid_bus_info = { .name = TYPE_CCID_BUS, .parent = TYPE_BUS, .instance_size = sizeof(CCIDBus), + .secure = true, }; void ccid_card_send_apdu_to_guest(CCIDCardState *card, @@ -1458,6 +1459,7 @@ static const TypeInfo ccid_info = { .parent = TYPE_USB_DEVICE, .instance_size = sizeof(USBCCIDState), .class_init = ccid_class_initfn, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } @@ -1478,6 +1480,7 @@ static const TypeInfo ccid_card_type_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(CCIDCardState), .abstract = true, + .secure = true, .class_size = sizeof(CCIDCardClass), .class_init = ccid_card_class_init, }; diff --git a/hw/usb/dev-storage-bot.c b/hw/usb/dev-storage-bot.c index a7f8d80c17..b156f1c5c9 100644 --- a/hw/usb/dev-storage-bot.c +++ b/hw/usb/dev-storage-bot.c @@ -52,6 +52,7 @@ static const TypeInfo bot_info = { .name = "usb-bot", .parent = TYPE_USB_STORAGE, .class_init = usb_msd_class_bot_initfn, + .secure = true, }; static void register_types(void) diff --git a/hw/usb/dev-storage-classic.c b/hw/usb/dev-storage-classic.c index 977151c4a0..7e0699cb51 100644 --- a/hw/usb/dev-storage-classic.c +++ b/hw/usb/dev-storage-classic.c @@ -133,6 +133,7 @@ static const TypeInfo msd_info = { .parent = TYPE_USB_STORAGE, .class_init = usb_msd_class_storage_initfn, .instance_init = usb_msd_instance_init, + .secure = true, }; static void register_types(void) diff --git a/hw/usb/dev-storage.c b/hw/usb/dev-storage.c index 040cf15051..f964d0c9dc 100644 --- a/hw/usb/dev-storage.c +++ b/hw/usb/dev-storage.c @@ -608,6 +608,7 @@ static const TypeInfo usb_storage_dev_type_info = { .instance_size = sizeof(MSDState), .abstract = true, .class_init = usb_msd_class_initfn_common, + .secure = true, }; static void usb_msd_register_types(void) diff --git a/hw/usb/hcd-ehci-pci.c b/hw/usb/hcd-ehci-pci.c index fd35d25340..d735d75956 100644 --- a/hw/usb/hcd-ehci-pci.c +++ b/hw/usb/hcd-ehci-pci.c @@ -171,6 +171,7 @@ static const TypeInfo ehci_pci_type_info = { .instance_init = usb_ehci_pci_init, .instance_finalize = usb_ehci_pci_finalize, .abstract = true, + .secure = true, .class_init = ehci_class_init, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, @@ -219,6 +220,7 @@ static void ehci_pci_register_types(void) TypeInfo ehci_type_info = { .parent = TYPE_PCI_EHCI, .class_init = ehci_data_class_init, + .secure = true, }; int i; diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c index 7f7c7f8a2f..0946d5a004 100644 --- a/hw/usb/hcd-ehci-sysbus.c +++ b/hw/usb/hcd-ehci-sysbus.c @@ -240,6 +240,7 @@ static const TypeInfo ehci_sysbus_types[] = { .instance_init = ehci_sysbus_init, .instance_finalize = ehci_sysbus_finalize, .abstract = true, + .secure = true, .class_init = ehci_sysbus_class_init, .class_size = sizeof(SysBusEHCIClass), }, @@ -247,32 +248,38 @@ static const TypeInfo ehci_sysbus_types[] = { .name = TYPE_PLATFORM_EHCI, .parent = TYPE_SYS_BUS_EHCI, .class_init = ehci_platform_class_init, + .secure = true, }, { .name = TYPE_EXYNOS4210_EHCI, .parent = TYPE_SYS_BUS_EHCI, .class_init = ehci_exynos4210_class_init, + .secure = true, }, { .name = TYPE_AW_H3_EHCI, .parent = TYPE_SYS_BUS_EHCI, .class_init = ehci_aw_h3_class_init, + .secure = true, }, { .name = TYPE_NPCM7XX_EHCI, .parent = TYPE_SYS_BUS_EHCI, .class_init = ehci_npcm7xx_class_init, + .secure = true, }, { .name = TYPE_TEGRA2_EHCI, .parent = TYPE_SYS_BUS_EHCI, .class_init = ehci_tegra2_class_init, + .secure = true, }, { .name = TYPE_PPC4xx_EHCI, .parent = TYPE_SYS_BUS_EHCI, .class_init = ehci_ppc4xx_class_init, .instance_init = ehci_ppc4xx_init, + .secure = true, }, { .name = TYPE_FUSBH200_EHCI, @@ -280,6 +287,7 @@ static const TypeInfo ehci_sysbus_types[] = { .instance_size = sizeof(FUSBH200EHCIState), .instance_init = fusbh200_ehci_init, .class_init = fusbh200_ehci_class_init, + .secure = true, }, }; diff --git a/hw/usb/hcd-ohci-pci.c b/hw/usb/hcd-ohci-pci.c index 70c9e9ac4f..cf0746aa00 100644 --- a/hw/usb/hcd-ohci-pci.c +++ b/hw/usb/hcd-ohci-pci.c @@ -148,6 +148,7 @@ static const TypeInfo ohci_pci_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(OHCIPCIState), .class_init = ohci_pci_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/usb/hcd-ohci-sysbus.c b/hw/usb/hcd-ohci-sysbus.c index 4f51eebccb..fd04e918e8 100644 --- a/hw/usb/hcd-ohci-sysbus.c +++ b/hw/usb/hcd-ohci-sysbus.c @@ -80,6 +80,7 @@ static const TypeInfo ohci_sysbus_types[] = { .parent = TYPE_SYS_BUS_DEVICE, .instance_size = sizeof(OHCISysBusState), .class_init = ohci_sysbus_class_init, + .secure = true, }, }; diff --git a/hw/usb/hcd-uhci.c b/hw/usb/hcd-uhci.c index a7b9fe1317..cd34680f46 100644 --- a/hw/usb/hcd-uhci.c +++ b/hw/usb/hcd-uhci.c @@ -1283,6 +1283,7 @@ static const TypeInfo uhci_pci_type_info = { .instance_size = sizeof(UHCIState), .class_size = sizeof(UHCIPCIDeviceClass), .abstract = true, + .secure = true, .class_init = uhci_class_init, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, @@ -1380,6 +1381,7 @@ static void uhci_register_types(void) TypeInfo uhci_type_info = { .parent = TYPE_UHCI, .class_init = uhci_data_class_init, + .secure = true, }; int i; diff --git a/hw/usb/hcd-xhci-nec.c b/hw/usb/hcd-xhci-nec.c index 46839911f3..070732be9a 100644 --- a/hw/usb/hcd-xhci-nec.c +++ b/hw/usb/hcd-xhci-nec.c @@ -67,6 +67,7 @@ static const TypeInfo nec_xhci_info = { .instance_size = sizeof(XHCINecState), .instance_init = nec_xhci_instance_init, .class_init = nec_xhci_class_init, + .secure = true, }; static void nec_xhci_register_types(void) diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c index b124251ae3..5d0fd851ca 100644 --- a/hw/usb/hcd-xhci-pci.c +++ b/hw/usb/hcd-xhci-pci.c @@ -266,6 +266,7 @@ static const TypeInfo xhci_pci_info = { .class_init = xhci_class_init, .instance_init = xhci_instance_init, .abstract = true, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, { INTERFACE_CONVENTIONAL_PCI_DEVICE }, @@ -298,6 +299,7 @@ static const TypeInfo qemu_xhci_info = { .parent = TYPE_XHCI_PCI, .class_init = qemu_xhci_class_init, .instance_init = qemu_xhci_instance_init, + .secure = true, }; static void xhci_register_types(void) diff --git a/hw/usb/hcd-xhci-sysbus.c b/hw/usb/hcd-xhci-sysbus.c index bbdd5fd64a..8dd50fbbf1 100644 --- a/hw/usb/hcd-xhci-sysbus.c +++ b/hw/usb/hcd-xhci-sysbus.c @@ -112,7 +112,8 @@ static const TypeInfo xhci_sysbus_info = { .parent = TYPE_SYS_BUS_DEVICE, .instance_size = sizeof(XHCISysbusState), .class_init = xhci_sysbus_class_init, - .instance_init = xhci_sysbus_instance_init + .instance_init = xhci_sysbus_instance_init, + .secure = true, }; static void xhci_sysbus_register_types(void) diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c index d342aa2739..aa6c8a0fdd 100644 --- a/hw/usb/hcd-xhci.c +++ b/hw/usb/hcd-xhci.c @@ -3676,6 +3676,7 @@ static const TypeInfo xhci_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(XHCIState), .class_init = xhci_class_init, + .secure = true, }; static void xhci_register_types(void) diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c index 564fe9a547..c845778a54 100644 --- a/hw/usb/host-libusb.c +++ b/hw/usb/host-libusb.c @@ -1810,6 +1810,7 @@ static const TypeInfo usb_host_dev_info = { .instance_size = sizeof(USBHostDevice), .class_init = usb_host_class_initfn, .instance_init = usb_host_instance_init, + .secure = true, }; module_obj(TYPE_USB_HOST_DEVICE); module_kconfig(USB); diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c index dfd9e8bb50..2d56ba329a 100644 --- a/hw/usb/redirect.c +++ b/hw/usb/redirect.c @@ -2654,6 +2654,7 @@ static const TypeInfo usbredir_dev_info = { .instance_size = sizeof(USBRedirDevice), .class_init = usbredir_class_initfn, .instance_init = usbredir_instance_init, + .secure = true, }; module_obj(TYPE_USB_REDIR); module_kconfig(USB); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417062.1646022 (Exim 4.92) (envelope-from ) id 1x52NB-0005Zr-9B; Fri, 11 Sep 2026 14:37:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417062.1646022; Fri, 11 Sep 2026 14:37:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NB-0005XW-2p; Fri, 11 Sep 2026 14:37:01 +0000 Received: by outflank-mailman (input) for mailman id 1417062; Fri, 11 Sep 2026 14:36:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52N9-0005P3-T7 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:36:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52N9-008jaJ-9u for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:36:59 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411fb-bab6-0a2a0a5309dd-0a2a450295c6-40 for ; Fri, 11 Sep 2026 16:36:59 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41209-6ca4-0a2a45020019-aa0a817c4fd9-3 for ; Fri, 11 Sep 2026 16:36:59 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-349-qBu9J0pJONqD0PZySyKfFg-1; Fri, 11 Sep 2026 10:36:52 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C8F771955DD4; Fri, 11 Sep 2026 14:36:50 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id DA2B53000229; Fri, 11 Sep 2026 14:36:48 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=m7+eb5JfGTqk31BVerDj3cabnDcqZzH0Cz7nFGxKH54=; b=V173gYvimKrFl352BnzcuE8Ae8XlNmgCu92t/RBBpL7quNYDZ4PW/HsW+id22Ji4uVb43Y 6mxuMbPUnZttf10XGgQxklQzoesLXwvFKKl41Kc9j00HY570hcywzsf0lDCJPonDG8RrBb 8RKJenB7NXcHDv993h4iA1RLdeadUUE= X-MC-Unique: qBu9J0pJONqD0PZySyKfFg-1 X-Mimecast-MFC-AGG-ID: qBu9J0pJONqD0PZySyKfFg_1789137410 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 09/28] hw/net: mark e1000, e1000e, IGB, rtl8139 & sPAPR VLAN as secure Date: Fri, 11 Sep 2026 15:36:08 +0100 Message-ID: <20260911143627.2743803-10-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: wCgxuSa6BO8o7rX8hyTtWH1NlYavtTT_j47SdGnnTt0_1789137410 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789137419-303C42AC-7DB0B079/0/0 X-purgate-type: clean X-purgate-size: 2990 Historically most NICs are only interesting for non-virtualization use cases and have not been written with malicious guests in mind. As a general rule either virtio-net or xen-net should be used in all virtualized guests requiring a security boundary. There are a handful of exceptions resulting from historical usage in the x86 world, to support virtualized guests lacking virtio support. Thus the rtl8139, e1000, e1000e & IGB NICs are declared to provide a security boundary. The PPC sPAPR Virutal LAN device is also marked secure. Signed-off-by: Daniel P. Berrangé --- hw/net/e1000.c | 1 + hw/net/e1000e.c | 1 + hw/net/igb.c | 1 + hw/net/rtl8139.c | 1 + hw/net/spapr_llan.c | 1 + 5 files changed, 5 insertions(+) diff --git a/hw/net/e1000.c b/hw/net/e1000.c index 202ad40401..da0667c40e 100644 --- a/hw/net/e1000.c +++ b/hw/net/e1000.c @@ -1759,6 +1759,7 @@ static void e1000_register_types(void) type_info.parent = TYPE_E1000_BASE; type_info.class_data = info; type_info.class_init = e1000_class_init; + type_info.secure = true, type_register_static(&type_info); } diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c index 9faf0c74c3..96737ddb51 100644 --- a/hw/net/e1000e.c +++ b/hw/net/e1000e.c @@ -721,6 +721,7 @@ static const TypeInfo e1000e_info = { .instance_size = sizeof(E1000EState), .class_init = e1000e_class_init, .instance_init = e1000e_instance_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, { } diff --git a/hw/net/igb.c b/hw/net/igb.c index c076807e71..0bd03efea0 100644 --- a/hw/net/igb.c +++ b/hw/net/igb.c @@ -635,6 +635,7 @@ static const TypeInfo igb_info = { .instance_size = sizeof(IGBState), .class_init = igb_class_init, .instance_init = igb_instance_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, { } diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c index 16479284ee..38bc16f312 100644 --- a/hw/net/rtl8139.c +++ b/hw/net/rtl8139.c @@ -3450,6 +3450,7 @@ static const TypeInfo rtl8139_info = { .instance_size = sizeof(RTL8139State), .class_init = rtl8139_class_init, .instance_init = rtl8139_instance_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c index 550848307d..c7ac58273c 100644 --- a/hw/net/spapr_llan.c +++ b/hw/net/spapr_llan.c @@ -873,6 +873,7 @@ static const TypeInfo spapr_vlan_info = { .class_init = spapr_vlan_class_init, .instance_init = spapr_vlan_instance_init, .instance_finalize = spapr_vlan_instance_finalize, + .secure = true, }; static void spapr_vlan_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417071.1646035 (Exim 4.92) (envelope-from ) id 1x52NF-0006G3-Ku; Fri, 11 Sep 2026 14:37:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417071.1646035; Fri, 11 Sep 2026 14:37:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NF-0006FY-ED; Fri, 11 Sep 2026 14:37:05 +0000 Received: by outflank-mailman (input) for mailman id 1417071; Fri, 11 Sep 2026 14:37:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52ND-00067i-R9 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52ND-00EPyQ-7N for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411f1-8faa-0a2a0a5109dd-0a2a45049838-46 for ; Fri, 11 Sep 2026 16:37:03 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4120d-b57f-0a2a45040019-aa0a817c6de1-3 for ; Fri, 11 Sep 2026 16:37:03 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-531-wrbZ1KXtOUmB-87brWnyCw-1; Fri, 11 Sep 2026 10:36:56 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2FA881955BF8; Fri, 11 Sep 2026 14:36:55 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 5989F3000229; Fri, 11 Sep 2026 14:36:53 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137421; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PkE3LclKvU9GiqQKtRj7Fj+wyH19sYMsxkpF53QZWX4=; b=C9ab3bM5maw/uL9vXD2PLK/umYyGIwwgduEKF8GRmR4JOdhF9UBL4OUiPaiWpXViqXwMur Z6QbdixJ7beZ/sVQxDoDJBRhqnpfh613zIAKUmgSAXaTsEaXNnVLAYJTcoJVAEolO+9wc6 OyNCJKHjmDmCcNH14UVHnUeaaiyK2Eo= X-MC-Unique: wrbZ1KXtOUmB-87brWnyCw-1 X-Mimecast-MFC-AGG-ID: wrbZ1KXtOUmB-87brWnyCw_1789137415 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 11/28] hw/watchdog: mark some watchdog devices as secure Date: Fri, 11 Sep 2026 15:36:10 +0100 Message-ID: <20260911143627.2743803-12-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: dYANc0Ge3XFlqyIult2wRomxZKZRO5Q5r2jN6ooQbqM_1789137415 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1789137423-526CAB50-F2472737/0/0 X-purgate-type: clean X-purgate-size: 2833 The ib700, i6300esb, gwdt, spapr and diag288 watchdog devices are marked as secure since they have traditionally been, or are intended to be, used in virtualization use cases on x86, arm, ppc and s390x architectures respectively. Other watchdogs are primarily for emulation. Signed-off-by: Daniel P. Berrangé --- hw/watchdog/sbsa_gwdt.c | 1 + hw/watchdog/spapr_watchdog.c | 1 + hw/watchdog/wdt_diag288.c | 1 + hw/watchdog/wdt_i6300esb.c | 1 + hw/watchdog/wdt_ib700.c | 1 + 5 files changed, 5 insertions(+) diff --git a/hw/watchdog/sbsa_gwdt.c b/hw/watchdog/sbsa_gwdt.c index 330a74798a..8a05b02c4f 100644 --- a/hw/watchdog/sbsa_gwdt.c +++ b/hw/watchdog/sbsa_gwdt.c @@ -307,6 +307,7 @@ static const TypeInfo wdt_sbsa_gwdt_info = { .parent = TYPE_SYS_BUS_DEVICE, .name = TYPE_WDT_SBSA, .instance_size = sizeof(SBSA_GWDTState), + .secure = true, }; static void wdt_sbsa_gwdt_register_types(void) diff --git a/hw/watchdog/spapr_watchdog.c b/hw/watchdog/spapr_watchdog.c index 5a72896066..0e45e9b4a6 100644 --- a/hw/watchdog/spapr_watchdog.c +++ b/hw/watchdog/spapr_watchdog.c @@ -269,6 +269,7 @@ static const TypeInfo spapr_wdt_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(SpaprWatchdog), .class_init = spapr_wdt_class_init, + .secure = true, }; static void spapr_watchdog_register_types(void) diff --git a/hw/watchdog/wdt_diag288.c b/hw/watchdog/wdt_diag288.c index 1275353e8e..85e4f56e1d 100644 --- a/hw/watchdog/wdt_diag288.c +++ b/hw/watchdog/wdt_diag288.c @@ -129,6 +129,7 @@ static const TypeInfo wdt_diag288_info = { .name = TYPE_WDT_DIAG288, .instance_size = sizeof(DIAG288State), .class_size = sizeof(DIAG288Class), + .secure = true, }; static void wdt_diag288_register_types(void) diff --git a/hw/watchdog/wdt_i6300esb.c b/hw/watchdog/wdt_i6300esb.c index 3aa01b8d68..05aa20fab1 100644 --- a/hw/watchdog/wdt_i6300esb.c +++ b/hw/watchdog/wdt_i6300esb.c @@ -480,6 +480,7 @@ static const TypeInfo i6300esb_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(I6300State), .class_init = i6300esb_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/watchdog/wdt_ib700.c b/hw/watchdog/wdt_ib700.c index 51a26a4cbb..8bf2b2fbf9 100644 --- a/hw/watchdog/wdt_ib700.c +++ b/hw/watchdog/wdt_ib700.c @@ -144,6 +144,7 @@ static const TypeInfo wdt_ib700_info = { .parent = TYPE_ISA_DEVICE, .instance_size = sizeof(IB700State), .class_init = wdt_ib700_class_init, + .secure = true, }; static void wdt_ib700_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417075.1646044 (Exim 4.92) (envelope-from ) id 1x52NI-0006lq-SC; Fri, 11 Sep 2026 14:37:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417075.1646044; Fri, 11 Sep 2026 14:37:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NI-0006lU-Nf; Fri, 11 Sep 2026 14:37:08 +0000 Received: by outflank-mailman (input) for mailman id 1417075; Fri, 11 Sep 2026 14:37:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NG-0006aK-U2 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52NG-00EPyQ-Ad for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:06 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41211-8faa-0a2a0a5109dd-0a2a4508a7b8-2 for ; Fri, 11 Sep 2026 16:37:06 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41210-f659-0a2a45080019-aa0a817ccb6f-3 for ; Fri, 11 Sep 2026 16:37:06 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-637-teOpK41IPpaV3nA4a5Tv8Q-1; Fri, 11 Sep 2026 10:37:01 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1159919560BC; Fri, 11 Sep 2026 14:37:00 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 3599A300022B; Fri, 11 Sep 2026 14:36:58 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137424; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cj/OwkAk1e+UKX4NrQR8oViEsggR98ARpU/Hmyqd04o=; b=gFfVWYijJM0cTK04yUurARQ3xl9pYr2AkD72ENCWu/6htU3y2ypzfZdMW6epL62WrNb1L8 iSoZ1npSKPHKDzQ5IY8IhLDjkeAJrFbOuMjEyTL6MUzPWiOAJAQnXCPevX87dkrjQs37a0 hzuxwCriGzoLAu8UENVY5E2GCNzobL4= X-MC-Unique: teOpK41IPpaV3nA4a5Tv8Q-1 X-Mimecast-MFC-AGG-ID: teOpK41IPpaV3nA4a5Tv8Q_1789137420 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 13/28] hw/scsi: mark SCSI disk endpoint devices as secure Date: Fri, 11 Sep 2026 15:36:12 +0100 Message-ID: <20260911143627.2743803-14-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: Vea2dxjTXApmPnUJrIoqRfK5Uniu085zyb0Dl__IYHs_1789137420 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1789137426-DFCD387B-A99B15C4/0/0 X-purgate-type: clean X-purgate-size: 1962 All these devices can be used together with supported SCSI controllers in a virtualization use case, so must be treated as secure. Signed-off-by: Daniel P. Berrangé --- hw/scsi/scsi-disk.c | 4 ++++ hw/scsi/scsi-generic.c | 1 + 2 files changed, 5 insertions(+) diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index a42f7d8e77..4474400a38 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -3218,6 +3218,7 @@ static const TypeInfo scsi_disk_base_info = { .instance_size = sizeof(SCSIDiskState), .class_size = sizeof(SCSIDiskClass), .abstract = true, + .secure = true, }; #define DEFINE_SCSI_DISK_PROPERTIES() \ @@ -3338,6 +3339,7 @@ static const TypeInfo scsi_hd_info = { .name = "scsi-hd", .parent = TYPE_SCSI_DISK_BASE, .class_init = scsi_hd_class_initfn, + .secure = true, }; static const Property scsi_cd_properties[] = { @@ -3381,6 +3383,7 @@ static const TypeInfo scsi_cd_info = { .name = "scsi-cd", .parent = TYPE_SCSI_DISK_BASE, .class_init = scsi_cd_class_initfn, + .secure = true, }; #ifdef __linux__ @@ -3423,6 +3426,7 @@ static const TypeInfo scsi_block_info = { .name = "scsi-block", .parent = TYPE_SCSI_DISK_BASE, .class_init = scsi_block_class_initfn, + .secure = true, }; #endif diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c index 8999f3b720..5588400b60 100644 --- a/hw/scsi/scsi-generic.c +++ b/hw/scsi/scsi-generic.c @@ -1225,6 +1225,7 @@ static const TypeInfo scsi_generic_info = { .parent = TYPE_SCSI_DEVICE, .instance_size = sizeof(SCSIDevice), .class_init = scsi_generic_class_initfn, + .secure = true, }; static void scsi_generic_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417076.1646049 (Exim 4.92) (envelope-from ) id 1x52NJ-0006pN-B1; Fri, 11 Sep 2026 14:37:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417076.1646049; Fri, 11 Sep 2026 14:37:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NJ-0006oM-0z; Fri, 11 Sep 2026 14:37:09 +0000 Received: by outflank-mailman (input) for mailman id 1417076; Fri, 11 Sep 2026 14:37:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NH-0006fT-Od for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52NH-009XnU-5H for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:07 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41210-e002-0a2a0a5209dd-0a2a4502c8a4-6 for ; Fri, 11 Sep 2026 16:37:07 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41211-6ca4-0a2a45020019-aa0a817cbd89-3 for ; Fri, 11 Sep 2026 16:37:06 +0200 Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-649-xHo6mdTZMTKAVWBSvC2yUw-1; Fri, 11 Sep 2026 10:36:59 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D7F641801352; Fri, 11 Sep 2026 14:36:57 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 82D103000229; Fri, 11 Sep 2026 14:36:55 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137425; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LU2oz7xA3+OY2WcVfZSc+OLR7VAsrbJYBWSzg698kcA=; b=ZtTY1ULFdgpXW3HorKgf0rCy67ZZCi0xyN/ZN4tGTFonVEhG0PTOnS5Co1iRpfPRX3YNPb wJeIynTgk7uDJGLnWBHjCWmZM4onN8X74Mj+2UB3YMsbooknvQuMUVBl7nGECzfKiHjnRO t+cisMMdbNaf+dxFtWL1YHZN8fYx9sI= X-MC-Unique: xHo6mdTZMTKAVWBSvC2yUw-1 X-Mimecast-MFC-AGG-ID: xHo6mdTZMTKAVWBSvC2yUw_1789137418 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 12/28] hw/scsi: mark spapr and vmware SCSI controllers as secure Date: Fri, 11 Sep 2026 15:36:11 +0100 Message-ID: <20260911143627.2743803-13-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: 5x3rV3bvcSOi1bhHBcZFKMSjNU1du5Gh3sSHjelpaTY_1789137418 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789137427-F04A62AC-0C6DD099/0/0 X-purgate-type: clean X-purgate-size: 1271 The spapr vscsi controller is used by default with spapr machines in a virtualization use case. The vmware SCSI controller supports a virtualization use case. Signed-off-by: Daniel P. Berrangé --- hw/scsi/spapr_vscsi.c | 1 + hw/scsi/vmw_pvscsi.c | 1 + 2 files changed, 2 insertions(+) diff --git a/hw/scsi/spapr_vscsi.c b/hw/scsi/spapr_vscsi.c index b4c8f94d22..f029a7da93 100644 --- a/hw/scsi/spapr_vscsi.c +++ b/hw/scsi/spapr_vscsi.c @@ -1298,6 +1298,7 @@ static const TypeInfo spapr_vscsi_info = { .parent = TYPE_VIO_SPAPR_DEVICE, .instance_size = sizeof(VSCSIState), .class_init = spapr_vscsi_class_init, + .secure = true, }; static void spapr_vscsi_register_types(void) diff --git a/hw/scsi/vmw_pvscsi.c b/hw/scsi/vmw_pvscsi.c index 05f93171cd..9974930634 100644 --- a/hw/scsi/vmw_pvscsi.c +++ b/hw/scsi/vmw_pvscsi.c @@ -1355,6 +1355,7 @@ static const TypeInfo pvscsi_info = { .instance_size = sizeof(PVSCSIState), .class_init = pvscsi_class_init, .instance_init = pvscsi_instance_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { INTERFACE_PCIE_DEVICE }, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417079.1646060 (Exim 4.92) (envelope-from ) id 1x52NK-0007Cy-K5; Fri, 11 Sep 2026 14:37:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417079.1646060; Fri, 11 Sep 2026 14:37:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NK-0007B5-B9; Fri, 11 Sep 2026 14:37:10 +0000 Received: by outflank-mailman (input) for mailman id 1417079; Fri, 11 Sep 2026 14:37:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NI-0006lj-VP for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52NI-008jaJ-Bq for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:08 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41214-bab6-0a2a0a5309dd-0a2a4507c7d6-2 for ; Fri, 11 Sep 2026 16:37:08 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41213-b4ea-0a2a45070019-aa0a857ca4b3-3 for ; Fri, 11 Sep 2026 16:37:08 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-468-tWO8hnOQMNmj-gNz7OkuIg-1; Fri, 11 Sep 2026 10:37:03 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 34FB81955BC6; Fri, 11 Sep 2026 14:37:02 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 624253000229; Fri, 11 Sep 2026 14:37:00 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137427; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XNUd+bMGXY0z0prDdK4igFxO8NCpyH4B4dmoUC/5P5c=; b=iBAJW5qZ9Vv+vmcSJ2lE9dRF8FCSvzZ0KYEpo8Tom+FpvR5KogrqnJ89XwXtav/mdcFfzs u0cUBAiua19GYsqA8Foou5t57v/Ot2B1wxyH0rmeS55BGu14z2XyzAZnI2MUngjFVTjfNO z4Wp92r9/H8oVKyCduji5m6D8/wPpuM= X-MC-Unique: tWO8hnOQMNmj-gNz7OkuIg-1 X-Mimecast-MFC-AGG-ID: tWO8hnOQMNmj-gNz7OkuIg_1789137422 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 14/28] hw/ide: mark ICH9 and ide-hd/ide-cd as secure Date: Fri, 11 Sep 2026 15:36:13 +0100 Message-ID: <20260911143627.2743803-15-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: B3T0DayFuFrIe5C19k0zF2GYT6ybX1CTjmTTAT64RuQ_1789137422 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1789137428-370DDAE4-709B6F7B/0/0 X-purgate-type: clean X-purgate-size: 2493 These have a long history of usage in virtualization scenarios on x86, for OS which lack modern virtio drivers for storage, and thus must be considered secure. Signed-off-by: Daniel P. Berrangé --- hw/ide/ich.c | 1 + hw/ide/ide-dev.c | 3 +++ hw/ide/piix.c | 2 ++ 3 files changed, 6 insertions(+) diff --git a/hw/ide/ich.c b/hw/ide/ich.c index b00987f08d..c7d50a15c1 100644 --- a/hw/ide/ich.c +++ b/hw/ide/ich.c @@ -198,6 +198,7 @@ static const TypeInfo ich_ahci_info = { .instance_size = sizeof(AHCIPCIState), .instance_init = pci_ich9_ahci_init, .class_init = ich_ahci_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/ide/ide-dev.c b/hw/ide/ide-dev.c index 5d478588c6..f555d0fb04 100644 --- a/hw/ide/ide-dev.c +++ b/hw/ide/ide-dev.c @@ -214,6 +214,7 @@ static const TypeInfo ide_hd_info = { .parent = TYPE_IDE_DEVICE, .instance_size = sizeof(IDEDrive), .class_init = ide_hd_class_init, + .secure = true, }; static const Property ide_cd_properties[] = { @@ -236,6 +237,7 @@ static const TypeInfo ide_cd_info = { .parent = TYPE_IDE_DEVICE, .instance_size = sizeof(IDEDrive), .class_init = ide_cd_class_init, + .secure = true, }; static void ide_device_class_init(ObjectClass *klass, const void *data) @@ -252,6 +254,7 @@ static const TypeInfo ide_device_type_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(IDEDevice), .abstract = true, + .secure = true, .class_size = sizeof(IDEDeviceClass), .class_init = ide_device_class_init, .instance_init = ide_dev_instance_init, diff --git a/hw/ide/piix.c b/hw/ide/piix.c index a8472f3e58..9b7b5e98c8 100644 --- a/hw/ide/piix.c +++ b/hw/ide/piix.c @@ -198,6 +198,7 @@ static const TypeInfo piix3_ide_info = { .name = TYPE_PIIX3_IDE, .parent = TYPE_PCI_IDE, .class_init = piix3_ide_class_init, + .secure = true, }; /* NOTE: for the PIIX4, the IRQs and IOports are hardcoded */ @@ -221,6 +222,7 @@ static const TypeInfo piix4_ide_info = { .name = TYPE_PIIX4_IDE, .parent = TYPE_PCI_IDE, .class_init = piix4_ide_class_init, + .secure = true, }; static void piix_ide_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417088.1646071 (Exim 4.92) (envelope-from ) id 1x52NO-0007rP-Bt; Fri, 11 Sep 2026 14:37:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417088.1646071; Fri, 11 Sep 2026 14:37:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NO-0007r9-6n; Fri, 11 Sep 2026 14:37:14 +0000 Received: by outflank-mailman (input) for mailman id 1417088; Fri, 11 Sep 2026 14:37:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NM-0007bh-IF for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52NL-009XnU-VB for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41210-e002-0a2a0a5209dd-0a2a4502c8a4-22 for ; Fri, 11 Sep 2026 16:37:11 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41216-6ca4-0a2a45020019-aa0a857cc721-3 for ; Fri, 11 Sep 2026 16:37:11 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-478-4ojkFmHhPTO60Js_E0hGWQ-1; Fri, 11 Sep 2026 10:37:08 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9836D1955BE0; Fri, 11 Sep 2026 14:37:06 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CCA7C3000229; Fri, 11 Sep 2026 14:37:04 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137430; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l3BKmIpd6uP7elhTJltd1MfpWu1daHpYwrEoIxNMRtY=; b=bFhON2eL0UbV945q6SqkTagj1DSeVvuG+W24kqIq+lj/lhw9tb8/kAF344GHj6DOQeejQ2 QkLrxFibAHA2N5zNFmBVYn2maurO6/9tOB2gYKP8DHpeHstDRz384gCFpRzG65iZh4g9+Q aBpu246VVN5vIplbm9LGwO0OPx/kABc= X-MC-Unique: 4ojkFmHhPTO60Js_E0hGWQ-1 X-Mimecast-MFC-AGG-ID: 4ojkFmHhPTO60Js_E0hGWQ_1789137426 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 16/28] hw/pci-host: mark common x86, ppc, arm and s390 PCI hosts as secure Date: Fri, 11 Sep 2026 15:36:15 +0100 Message-ID: <20260911143627.2743803-17-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: 5jmGQsK-GK3e0AnInWeEuxSvLS_dQsbqQQO3hJZ5xuw_1789137426 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789137431-31FD62AC-BA44DE38/0/0 X-purgate-type: clean X-purgate-size: 10131 Mark the PCI hosts secure if they are used from machine types that are considered for the virtualization use case. There is also a special case for the 'remote' type and the Xen passthrough type. Signed-off-by: Daniel P. Berrangé --- hw/pci-host/gpex.c | 2 ++ hw/pci-host/i440fx.c | 2 ++ hw/pci-host/pnv_phb.c | 2 ++ hw/pci-host/pnv_phb3.c | 3 +++ hw/pci-host/pnv_phb3_msi.c | 1 + hw/pci-host/pnv_phb3_pbcq.c | 1 + hw/pci-host/pnv_phb4.c | 4 +++- hw/pci-host/pnv_phb4_pec.c | 1 + hw/pci-host/q35.c | 2 ++ hw/pci-host/remote.c | 1 + hw/pci-host/xen_igd_pt.c | 1 + hw/ppc/spapr_pci.c | 1 + hw/s390x/s390-pci-bus.c | 4 ++++ 13 files changed, 24 insertions(+), 1 deletion(-) diff --git a/hw/pci-host/gpex.c b/hw/pci-host/gpex.c index e66784ce51..38197a8945 100644 --- a/hw/pci-host/gpex.c +++ b/hw/pci-host/gpex.c @@ -220,6 +220,7 @@ static const TypeInfo gpex_host_info = { .instance_size = sizeof(GPEXHost), .instance_init = gpex_host_initfn, .class_init = gpex_host_class_init, + .secure = true, }; /**************************************************************************** @@ -259,6 +260,7 @@ static const TypeInfo gpex_root_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(GPEXRootState), .class_init = gpex_root_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c index c1982f7962..1c5a4aba1b 100644 --- a/hw/pci-host/i440fx.c +++ b/hw/pci-host/i440fx.c @@ -352,6 +352,7 @@ static const TypeInfo i440fx_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(PCII440FXState), .class_init = i440fx_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, @@ -410,6 +411,7 @@ static const TypeInfo i440fx_pcihost_info = { .instance_size = sizeof(I440FXState), .instance_init = i440fx_pcihost_initfn, .class_init = i440fx_pcihost_class_init, + .secure = true, }; static void i440fx_register_types(void) diff --git a/hw/pci-host/pnv_phb.c b/hw/pci-host/pnv_phb.c index 0b556d1bf5..bc8313d2cd 100644 --- a/hw/pci-host/pnv_phb.c +++ b/hw/pci-host/pnv_phb.c @@ -333,6 +333,7 @@ static const TypeInfo pnv_phb_type_info = { .parent = TYPE_PCIE_HOST_BRIDGE, .instance_size = sizeof(PnvPHB), .class_init = pnv_phb_class_init, + .secure = true, }; static const TypeInfo pnv_phb_root_port_info = { @@ -340,6 +341,7 @@ static const TypeInfo pnv_phb_root_port_info = { .parent = TYPE_PCIE_ROOT_PORT, .instance_size = sizeof(PnvPHBRootPort), .class_init = pnv_phb_root_port_class_init, + .secure = true, }; static void pnv_phb_register_types(void) diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c index db061c134e..abf43e3226 100644 --- a/hw/pci-host/pnv_phb3.c +++ b/hw/pci-host/pnv_phb3.c @@ -910,6 +910,7 @@ static const TypeInfo pnv_phb3_iommu_memory_region_info = { .parent = TYPE_IOMMU_MEMORY_REGION, .name = TYPE_PNV_PHB3_IOMMU_MEMORY_REGION, .class_init = pnv_phb3_iommu_memory_region_class_init, + .secure = true, }; /* @@ -1123,6 +1124,7 @@ static const TypeInfo pnv_phb3_type_info = { .instance_size = sizeof(PnvPHB3), .class_init = pnv_phb3_class_init, .instance_init = pnv_phb3_instance_init, + .secure = true, }; static void pnv_phb3_root_bus_get_prop(Object *obj, Visitor *v, @@ -1186,6 +1188,7 @@ static const TypeInfo pnv_phb3_root_bus_info = { .parent = TYPE_PCIE_BUS, .instance_size = sizeof(PnvPHB3RootBus), .class_init = pnv_phb3_root_bus_class_init, + .secure = true, }; static void pnv_phb3_register_types(void) diff --git a/hw/pci-host/pnv_phb3_msi.c b/hw/pci-host/pnv_phb3_msi.c index 66ba7b7913..5edc0d43eb 100644 --- a/hw/pci-host/pnv_phb3_msi.c +++ b/hw/pci-host/pnv_phb3_msi.c @@ -306,6 +306,7 @@ static const TypeInfo phb3_msi_info = { .class_init = phb3_msi_class_init, .class_size = sizeof(ICSStateClass), .instance_init = phb3_msi_instance_init, + .secure = true, }; static void pnv_phb3_msi_register_types(void) diff --git a/hw/pci-host/pnv_phb3_pbcq.c b/hw/pci-host/pnv_phb3_pbcq.c index 1f7a149580..687c832515 100644 --- a/hw/pci-host/pnv_phb3_pbcq.c +++ b/hw/pci-host/pnv_phb3_pbcq.c @@ -354,6 +354,7 @@ static const TypeInfo pnv_pbcq_type_info = { .instance_size = sizeof(PnvPBCQState), .instance_init = phb3_pbcq_instance_init, .class_init = pnv_pbcq_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_PNV_XSCOM_INTERFACE }, { } diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c index 9acaf4c0c2..9706208473 100644 --- a/hw/pci-host/pnv_phb4.c +++ b/hw/pci-host/pnv_phb4.c @@ -1374,6 +1374,7 @@ static const TypeInfo pnv_phb4_iommu_memory_region_info = { .parent = TYPE_IOMMU_MEMORY_REGION, .name = TYPE_PNV_PHB4_IOMMU_MEMORY_REGION, .class_init = pnv_phb4_iommu_memory_region_class_init, + .secure = true, }; /* @@ -1715,13 +1716,13 @@ static const TypeInfo pnv_phb4_type_info = { .instance_init = pnv_phb4_instance_init, .instance_size = sizeof(PnvPHB4), .class_init = pnv_phb4_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_XIVE_NOTIFIER }, { }, } }; - static void pnv_phb4_root_bus_get_prop(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp) @@ -1783,6 +1784,7 @@ static const TypeInfo pnv_phb4_root_bus_info = { .parent = TYPE_PCIE_BUS, .instance_size = sizeof(PnvPHB4RootBus), .class_init = pnv_phb4_root_bus_class_init, + .secure = true, }; static void pnv_phb4_register_types(void) diff --git a/hw/pci-host/pnv_phb4_pec.c b/hw/pci-host/pnv_phb4_pec.c index ee5cdc3e45..280a15e8df 100644 --- a/hw/pci-host/pnv_phb4_pec.c +++ b/hw/pci-host/pnv_phb4_pec.c @@ -388,6 +388,7 @@ static const TypeInfo pnv_pec_type_info = { .instance_size = sizeof(PnvPhb4PecState), .class_init = pnv_pec_class_init, .class_size = sizeof(PnvPhb4PecClass), + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_PNV_XSCOM_INTERFACE }, { } diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c index f4556ad03a..be38841df9 100644 --- a/hw/pci-host/q35.c +++ b/hw/pci-host/q35.c @@ -268,6 +268,7 @@ static const TypeInfo q35_host_info = { .instance_size = sizeof(Q35PCIHost), .instance_init = q35_host_initfn, .class_init = q35_host_class_init, + .secure = true, }; /**************************************************************************** @@ -718,6 +719,7 @@ static const TypeInfo mch_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(MCHPCIState), .class_init = mch_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/pci-host/remote.c b/hw/pci-host/remote.c index 9ea95fac6e..a58fc39bde 100644 --- a/hw/pci-host/remote.c +++ b/hw/pci-host/remote.c @@ -63,6 +63,7 @@ static const TypeInfo remote_pcihost_info = { .parent = TYPE_PCIE_HOST_BRIDGE, .instance_size = sizeof(RemotePCIHost), .class_init = remote_pcihost_class_init, + .secure = true, }; static void remote_pcihost_register(void) diff --git a/hw/pci-host/xen_igd_pt.c b/hw/pci-host/xen_igd_pt.c index f6016f2cd5..abc68849b9 100644 --- a/hw/pci-host/xen_igd_pt.c +++ b/hw/pci-host/xen_igd_pt.c @@ -110,6 +110,7 @@ static const TypeInfo igd_passthrough_i440fx_info = { .parent = TYPE_I440FX_PCI_DEVICE, .instance_size = sizeof(PCII440FXState), .class_init = igd_passthrough_i440fx_class_init, + .secure = true, }; static void igd_pt_i440fx_register_types(void) diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index c1d4b7806e..711c37878b 100644 --- a/hw/ppc/spapr_pci.c +++ b/hw/ppc/spapr_pci.c @@ -2174,6 +2174,7 @@ static const TypeInfo spapr_phb_info = { .instance_size = sizeof(SpaprPhbState), .instance_finalize = spapr_phb_finalizefn, .class_init = spapr_phb_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c index eff980fdfe..5356d13624 100644 --- a/hw/s390x/s390-pci-bus.c +++ b/hw/s390x/s390-pci-bus.c @@ -1406,6 +1406,7 @@ static const TypeInfo s390_pcihost_info = { .parent = TYPE_PCI_HOST_BRIDGE, .instance_size = sizeof(S390pciState), .class_init = s390_pcihost_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } @@ -1416,6 +1417,7 @@ static const TypeInfo s390_pcibus_info = { .name = TYPE_S390_PCI_BUS, .parent = TYPE_BUS, .instance_size = sizeof(S390PCIBus), + .secure = true, }; static uint16_t s390_pci_generate_uid(S390pciState *s) @@ -1588,12 +1590,14 @@ static const TypeInfo s390_pci_device_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(S390PCIBusDevice), .class_init = s390_pci_device_class_init, + .secure = true, }; static const TypeInfo s390_pci_iommu_info = { .name = TYPE_S390_PCI_IOMMU, .parent = TYPE_OBJECT, .instance_size = sizeof(S390PCIIOMMU), + .secure = true, }; static void s390_iommu_memory_region_class_init(ObjectClass *klass, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417090.1646074 (Exim 4.92) (envelope-from ) id 1x52NO-0007vG-TK; Fri, 11 Sep 2026 14:37:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417090.1646074; Fri, 11 Sep 2026 14:37:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NO-0007tk-HR; Fri, 11 Sep 2026 14:37:14 +0000 Received: by outflank-mailman (input) for mailman id 1417090; Fri, 11 Sep 2026 14:37:13 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NN-0007jz-8J for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52NM-002Y6Q-LD for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:12 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41200-8faa-0a2a0a5109dd-0a2a450b810e-22 for ; Fri, 11 Sep 2026 16:37:12 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41217-b7e8-0a2a450b0019-aa0a857cadbd-3 for ; Fri, 11 Sep 2026 16:37:12 +0200 Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-682-0bhJcL1lO_-yIUmxVdMGXg-1; Fri, 11 Sep 2026 10:37:05 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6B5F1180074A; Fri, 11 Sep 2026 14:37:04 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 92C633000229; Fri, 11 Sep 2026 14:37:02 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CeroplWVCuzcovqwMRjGvrfeMx7FqmzTXbbtHaWN5tE=; b=be/fpOjGx4Fe4wVeQSa7akSTnRJCzw6CJMuFqT4/ZVxWPLgso+GqhAa420VtpAz9DXN2N9 J9jxtfhza6AmHkxz+eKAr4WH/76YU+AjS85ynOknvBWe2KL/GhREhk1IW9hpjmD52ITqqt rjxyjj2r0cbkMob5OQd+dn+k3Y/Uddg= X-MC-Unique: 0bhJcL1lO_-yIUmxVdMGXg-1 X-Mimecast-MFC-AGG-ID: 0bhJcL1lO_-yIUmxVdMGXg_1789137424 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 15/28] hw: define most common PCI types as secure Date: Fri, 11 Sep 2026 15:36:14 +0100 Message-ID: <20260911143627.2743803-16-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: FDSG_Uz8yp_lk_qzqt7n_6M81EZU2T6Uf40kiBq36PM_1789137424 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789137432-A8CCF9EA-71321C78/0/0 X-purgate-type: clean X-purgate-size: 11444 Essentially all PCI infrastructure is in scope for the virtualization use case, aside from the niche simba bridge. Signed-off-by: Daniel P. Berrangé --- hw/pci-bridge/gen_pcie_root_port.c | 1 + hw/pci-bridge/i82801b11.c | 1 + hw/pci-bridge/ioh3420.c | 1 + hw/pci-bridge/pci_bridge_dev.c | 2 ++ hw/pci-bridge/pci_expander_bridge.c | 8 ++++++++ hw/pci-bridge/pcie_pci_bridge.c | 1 + hw/pci-bridge/pcie_root_port.c | 1 + hw/pci-bridge/xio3130_downstream.c | 1 + hw/pci-bridge/xio3130_upstream.c | 1 + hw/pci/pci.c | 7 +++++++ hw/pci/pci_bridge.c | 1 + hw/pci/pci_host.c | 1 + hw/pci/pcie_host.c | 1 + hw/pci/pcie_port.c | 1 + 14 files changed, 28 insertions(+) diff --git a/hw/pci-bridge/gen_pcie_root_port.c b/hw/pci-bridge/gen_pcie_root_port.c index 5434d693d9..65d29eab38 100644 --- a/hw/pci-bridge/gen_pcie_root_port.c +++ b/hw/pci-bridge/gen_pcie_root_port.c @@ -161,6 +161,7 @@ static const TypeInfo gen_rp_dev_info = { .parent = TYPE_PCIE_ROOT_PORT, .instance_size = sizeof(GenPCIERootPort), .class_init = gen_rp_dev_class_init, + .secure = true, }; static void gen_rp_register_types(void) diff --git a/hw/pci-bridge/i82801b11.c b/hw/pci-bridge/i82801b11.c index 1d73c14c1f..f702b20bcd 100644 --- a/hw/pci-bridge/i82801b11.c +++ b/hw/pci-bridge/i82801b11.c @@ -107,6 +107,7 @@ static const TypeInfo i82801b11_bridge_info = { .parent = TYPE_PCI_BRIDGE, .instance_size = sizeof(I82801b11Bridge), .class_init = i82801b11_bridge_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c index bba640f495..2c4882c4cf 100644 --- a/hw/pci-bridge/ioh3420.c +++ b/hw/pci-bridge/ioh3420.c @@ -120,6 +120,7 @@ static const TypeInfo ioh3420_info = { .name = "ioh3420", .parent = TYPE_PCIE_ROOT_PORT, .class_init = ioh3420_class_init, + .secure = true, }; static void ioh3420_register_types(void) diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c index 0c1383562d..319e6f199a 100644 --- a/hw/pci-bridge/pci_bridge_dev.c +++ b/hw/pci-bridge/pci_bridge_dev.c @@ -268,6 +268,7 @@ static const TypeInfo pci_bridge_dev_info = { .instance_size = sizeof(PCIBridgeDev), .class_init = pci_bridge_dev_class_init, .instance_finalize = pci_bridge_dev_instance_finalize, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { INTERFACE_CONVENTIONAL_PCI_DEVICE }, @@ -294,6 +295,7 @@ static const TypeInfo pci_bridge_dev_seat_info = { .parent = TYPE_PCI_BRIDGE_DEV, .instance_size = sizeof(PCIBridgeDev), .class_init = pci_bridge_dev_seat_class_init, + .secure = true, }; static void pci_bridge_dev_register(void) diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c index 40ffbc4e08..bd5598b639 100644 --- a/hw/pci-bridge/pci_expander_bridge.c +++ b/hw/pci-bridge/pci_expander_bridge.c @@ -114,6 +114,7 @@ static const TypeInfo pxb_bus_info = { .parent = TYPE_PCI_BUS, .instance_size = sizeof(PXBBus), .class_init = pxb_bus_class_init, + .secure = true, }; static const TypeInfo pxb_pcie_bus_info = { @@ -121,6 +122,7 @@ static const TypeInfo pxb_pcie_bus_info = { .parent = TYPE_PCIE_BUS, .instance_size = sizeof(PXBBus), .class_init = pxb_bus_class_init, + .secure = true, }; static const TypeInfo pxb_cxl_bus_info = { @@ -128,6 +130,7 @@ static const TypeInfo pxb_cxl_bus_info = { .parent = TYPE_CXL_BUS, .instance_size = sizeof(PXBBus), .class_init = pxb_bus_class_init, + .secure = true, }; static const char *pxb_host_root_bus_path(PCIHostState *host_bridge, @@ -190,6 +193,7 @@ static const TypeInfo pxb_host_info = { .name = TYPE_PXB_HOST, .parent = TYPE_PCI_HOST_BRIDGE, .class_init = pxb_host_class_init, + .secure = true, }; static void pxb_cxl_realize(DeviceState *dev, Error **errp) @@ -249,6 +253,7 @@ static const TypeInfo cxl_host_info = { .parent = TYPE_PCI_HOST_BRIDGE, .instance_size = sizeof(CXLHost), .class_init = pxb_cxl_host_class_init, + .secure = true, }; /* @@ -453,6 +458,7 @@ static const TypeInfo pxb_dev_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(PXBDev), .class_init = pxb_dev_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, @@ -490,6 +496,7 @@ static const TypeInfo pxb_pcie_dev_info = { .parent = TYPE_PXB_DEV, .instance_size = sizeof(PXBPCIEDev), .class_init = pxb_pcie_dev_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, @@ -540,6 +547,7 @@ static const TypeInfo pxb_cxl_dev_info = { .parent = TYPE_PXB_PCIE_DEV, .instance_size = sizeof(PXBCXLDev), .class_init = pxb_cxl_dev_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]){ { INTERFACE_CONVENTIONAL_PCI_DEVICE }, diff --git a/hw/pci-bridge/pcie_pci_bridge.c b/hw/pci-bridge/pcie_pci_bridge.c index e826fb2829..03b6b1c0f5 100644 --- a/hw/pci-bridge/pcie_pci_bridge.c +++ b/hw/pci-bridge/pcie_pci_bridge.c @@ -162,6 +162,7 @@ static const TypeInfo pcie_pci_bridge_info = { .parent = TYPE_PCI_BRIDGE, .instance_size = sizeof(PCIEPCIBridge), .class_init = pcie_pci_bridge_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { INTERFACE_PCIE_DEVICE }, diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c index 7c3e78010b..d829c4b61a 100644 --- a/hw/pci-bridge/pcie_root_port.c +++ b/hw/pci-bridge/pcie_root_port.c @@ -186,6 +186,7 @@ static const TypeInfo rp_info = { .instance_post_init = rp_instance_post_init, .class_init = rp_class_init, .abstract = true, + .secure = true, .class_size = sizeof(PCIERootPortClass), .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, diff --git a/hw/pci-bridge/xio3130_downstream.c b/hw/pci-bridge/xio3130_downstream.c index 0c3fed3053..ded948ebd0 100644 --- a/hw/pci-bridge/xio3130_downstream.c +++ b/hw/pci-bridge/xio3130_downstream.c @@ -175,6 +175,7 @@ static const TypeInfo xio3130_downstream_info = { .name = TYPE_XIO3130_DOWNSTREAM, .parent = TYPE_PCIE_SLOT, .class_init = xio3130_downstream_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, { } diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/xio3130_upstream.c index 40057b749b..9d58105f8b 100644 --- a/hw/pci-bridge/xio3130_upstream.c +++ b/hw/pci-bridge/xio3130_upstream.c @@ -144,6 +144,7 @@ static const TypeInfo xio3130_upstream_info = { .name = "x3130-upstream", .parent = TYPE_PCIE_PORT, .class_init = xio3130_upstream_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, { } diff --git a/hw/pci/pci.c b/hw/pci/pci.c index c15f2b9f08..20d4942df2 100644 --- a/hw/pci/pci.c +++ b/hw/pci/pci.c @@ -319,6 +319,7 @@ static const TypeInfo pci_bus_info = { .instance_size = sizeof(PCIBus), .class_size = sizeof(PCIBusClass), .class_init = pci_bus_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_FW_CFG_DATA_GENERATOR_INTERFACE }, { } @@ -328,16 +329,19 @@ static const TypeInfo pci_bus_info = { static const TypeInfo cxl_interface_info = { .name = INTERFACE_CXL_DEVICE, .parent = TYPE_INTERFACE, + .secure = true, }; static const TypeInfo pcie_interface_info = { .name = INTERFACE_PCIE_DEVICE, .parent = TYPE_INTERFACE, + .secure = true, }; static const TypeInfo conventional_pci_interface_info = { .name = INTERFACE_CONVENTIONAL_PCI_DEVICE, .parent = TYPE_INTERFACE, + .secure = true, }; static void pcie_bus_class_init(ObjectClass *klass, const void *data) @@ -351,12 +355,14 @@ static const TypeInfo pcie_bus_info = { .name = TYPE_PCIE_BUS, .parent = TYPE_PCI_BUS, .class_init = pcie_bus_class_init, + .secure = true, }; static const TypeInfo cxl_bus_info = { .name = TYPE_CXL_BUS, .parent = TYPE_PCIE_BUS, .class_init = pcie_bus_class_init, + .secure = true, }; static void pci_update_mappings(PCIDevice *d); @@ -3468,6 +3474,7 @@ static const TypeInfo pci_device_type_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(PCIDevice), .abstract = true, + .secure = true, .class_size = sizeof(PCIDeviceClass), .class_init = pci_device_class_init, .class_base_init = pci_device_class_base_init, diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c index e85932e41a..3eb0917fc2 100644 --- a/hw/pci/pci_bridge.c +++ b/hw/pci/pci_bridge.c @@ -497,6 +497,7 @@ static const TypeInfo pci_bridge_type_info = { .instance_size = sizeof(PCIBridge), .class_init = pci_bridge_class_init, .abstract = true, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_ACPI_DEV_AML_IF }, { }, diff --git a/hw/pci/pci_host.c b/hw/pci/pci_host.c index 2a7fdfa563..5dc9d8493f 100644 --- a/hw/pci/pci_host.c +++ b/hw/pci/pci_host.c @@ -262,6 +262,7 @@ static const TypeInfo pci_host_type_info = { .name = TYPE_PCI_HOST_BRIDGE, .parent = TYPE_SYS_BUS_DEVICE, .abstract = true, + .secure = true, .class_size = sizeof(PCIHostBridgeClass), .instance_size = sizeof(PCIHostState), .class_init = pci_host_class_init, diff --git a/hw/pci/pcie_host.c b/hw/pci/pcie_host.c index 3717e1a086..3cf0769d2a 100644 --- a/hw/pci/pcie_host.c +++ b/hw/pci/pcie_host.c @@ -124,6 +124,7 @@ static const TypeInfo pcie_host_type_info = { .name = TYPE_PCIE_HOST_BRIDGE, .parent = TYPE_PCI_HOST_BRIDGE, .abstract = true, + .secure = true, .instance_size = sizeof(PCIExpressHost), .instance_init = pcie_host_init, }; diff --git a/hw/pci/pcie_port.c b/hw/pci/pcie_port.c index dbb6032160..8fce77bcb8 100644 --- a/hw/pci/pcie_port.c +++ b/hw/pci/pcie_port.c @@ -200,6 +200,7 @@ static const TypeInfo pcie_port_type_info = { .parent = TYPE_PCI_BRIDGE, .instance_size = sizeof(PCIEPort), .abstract = true, + .secure = true, .class_init = pcie_port_class_init, }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417102.1646088 (Exim 4.92) (envelope-from ) id 1x52NT-0000Pe-12; Fri, 11 Sep 2026 14:37:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417102.1646088; Fri, 11 Sep 2026 14:37:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NS-0000PP-Sq; Fri, 11 Sep 2026 14:37:18 +0000 Received: by outflank-mailman (input) for mailman id 1417102; Fri, 11 Sep 2026 14:37:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NR-0000BQ-Dk for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52NQ-009Xr7-QL for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:16 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41216-e002-0a2a0a5209dd-0a2a450cc2ca-18 for ; Fri, 11 Sep 2026 16:37:16 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4121b-f479-0a2a450c0019-aa0a817cb957-3 for ; Fri, 11 Sep 2026 16:37:16 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-425-tMRy4ymCPxWhrf_UlInavg-1; Fri, 11 Sep 2026 10:37:10 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B572E1953964; Fri, 11 Sep 2026 14:37:08 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id EABCD300022B; Fri, 11 Sep 2026 14:37:06 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v/QFXhbR7+trrsi9yjvMVLU5gLecR5pn7XwbzwTQyqg=; b=CiyIvP+DqEmCajiY6Bd2uF5Bh/aVhIhKt0g9bG5JXrlDQRYH9ZqphwrCN19bpdncKx+xP8 y4wxHn7aKF83fOEMgKA0zKd9lbAr1OJhkEAMBCns0xbSb1nKQ2teVSOx6Q7h7WnWdLaTzE EKxU1D5nreTKb5CXV3FN6oMNuczxPu0= X-MC-Unique: tMRy4ymCPxWhrf_UlInavg-1 X-Mimecast-MFC-AGG-ID: tMRy4ymCPxWhrf_UlInavg_1789137428 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 17/28] hw/display: mark bochs, cirrus, qxl, VGA, ramfb as secure Date: Fri, 11 Sep 2026 15:36:16 +0100 Message-ID: <20260911143627.2743803-18-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: ZyfBBUWJgFTV9ftP-_LEPotxwmNiXpQANGviS3BzCxI_1789137428 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1789137436-50F3BA5B-5CBAF9B9/0/0 X-purgate-type: clean X-purgate-size: 4776 Most of the display adapters are emulating old hardware which is not relevant to virtualization use cases. The exceptions that should be considered secure are Cirrus (PCI, not ISA), Bochs, QXL, RAMFB, VGA (PCI, MMIO, not ISA) and VMWare VGA. The Cirrus PCI decision is borderline. It has been heavily used with virtualization in the past, but these days VGA / RAMFB are strongly recommended instead. Due to its historical usage though, we should likely retain it in the set we aim to class as secure. Signed-off-by: Daniel P. Berrangé --- hw/display/bochs-display.c | 1 + hw/display/cirrus_vga.c | 1 + hw/display/qxl.c | 3 +++ hw/display/ramfb-standalone.c | 1 + hw/display/vga-mmio.c | 1 + hw/display/vga-pci.c | 3 +++ 6 files changed, 10 insertions(+) diff --git a/hw/display/bochs-display.c b/hw/display/bochs-display.c index 64e669429c..5f3ba80f99 100644 --- a/hw/display/bochs-display.c +++ b/hw/display/bochs-display.c @@ -374,6 +374,7 @@ static const TypeInfo bochs_display_type_info = { .instance_size = sizeof(BochsDisplayState), .instance_init = bochs_display_init, .class_init = bochs_display_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_PCIE_DEVICE }, { INTERFACE_CONVENTIONAL_PCI_DEVICE }, diff --git a/hw/display/cirrus_vga.c b/hw/display/cirrus_vga.c index 0a8c74e137..8232c5c468 100644 --- a/hw/display/cirrus_vga.c +++ b/hw/display/cirrus_vga.c @@ -3013,6 +3013,7 @@ static const TypeInfo cirrus_vga_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(PCICirrusVGAState), .class_init = cirrus_vga_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/display/qxl.c b/hw/display/qxl.c index 384b8767b8..d673663b3a 100644 --- a/hw/display/qxl.c +++ b/hw/display/qxl.c @@ -2566,6 +2566,7 @@ static const TypeInfo qxl_pci_type_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(PCIQXLDevice), .abstract = true, + .secure = true, .class_init = qxl_pci_class_init, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, @@ -2589,6 +2590,7 @@ static const TypeInfo qxl_primary_info = { .name = "qxl-vga", .parent = TYPE_PCI_QXL, .class_init = qxl_primary_class_init, + .secure = true, }; module_obj("qxl-vga"); module_kconfig(QXL); @@ -2607,6 +2609,7 @@ static const TypeInfo qxl_secondary_info = { .name = "qxl", .parent = TYPE_PCI_QXL, .class_init = qxl_secondary_class_init, + .secure = true, }; module_obj("qxl"); diff --git a/hw/display/ramfb-standalone.c b/hw/display/ramfb-standalone.c index 8e8ba37514..9427009acc 100644 --- a/hw/display/ramfb-standalone.c +++ b/hw/display/ramfb-standalone.c @@ -85,6 +85,7 @@ static const TypeInfo ramfb_info = { .parent = TYPE_DYNAMIC_SYS_BUS_DEVICE, .instance_size = sizeof(RAMFBStandaloneState), .class_init = ramfb_class_initfn, + .secure = true, }; static void ramfb_register_types(void) diff --git a/hw/display/vga-mmio.c b/hw/display/vga-mmio.c index 3cd64951c0..65dbbed12d 100644 --- a/hw/display/vga-mmio.c +++ b/hw/display/vga-mmio.c @@ -132,6 +132,7 @@ static const TypeInfo vga_mmio_info = { .parent = TYPE_SYS_BUS_DEVICE, .instance_size = sizeof(VGAMmioState), .class_init = vga_mmio_class_initfn, + .secure = true, }; static void vga_mmio_register_types(void) diff --git a/hw/display/vga-pci.c b/hw/display/vga-pci.c index d089847bda..bb13eee8a2 100644 --- a/hw/display/vga-pci.c +++ b/hw/display/vga-pci.c @@ -367,6 +367,7 @@ static const TypeInfo vga_pci_type_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(PCIVGAState), .abstract = true, + .secure = true, .class_init = vga_pci_class_init, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, @@ -407,6 +408,7 @@ static const TypeInfo vga_info = { .name = "VGA", .parent = TYPE_PCI_VGA, .class_init = vga_class_init, + .secure = true, }; static const TypeInfo secondary_info = { @@ -414,6 +416,7 @@ static const TypeInfo secondary_info = { .parent = TYPE_PCI_VGA, .instance_init = pci_secondary_vga_init, .class_init = secondary_class_init, + .secure = true, }; static void vga_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417103.1646095 (Exim 4.92) (envelope-from ) id 1x52NT-0000VS-MJ; Fri, 11 Sep 2026 14:37:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417103.1646095; Fri, 11 Sep 2026 14:37:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NT-0000U3-98; Fri, 11 Sep 2026 14:37:19 +0000 Received: by outflank-mailman (input) for mailman id 1417103; Fri, 11 Sep 2026 14:37:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NR-0000Eu-M7 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52NR-002Y6Q-34 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:17 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41211-8faa-0a2a0a5109dd-0a2a4508a7b8-20 for ; Fri, 11 Sep 2026 16:37:17 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4121b-f659-0a2a45080019-aa0a857c7fe5-3 for ; Fri, 11 Sep 2026 16:37:16 +0200 Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-610-4E2YGmFpOKqs7_tv22KEXQ-1; Fri, 11 Sep 2026 10:37:14 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 183951801352; Fri, 11 Sep 2026 14:37:13 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 31F6E3000229; Fri, 11 Sep 2026 14:37:11 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xemsx/xBv0DEBitYLoiJ5cnvCREZhOyx4JVbgw8hygU=; b=LdPE0R3FcpJ++zjxQmOQhbh9Qu4vffEPSesGKfLqJiHeN5hiAgziRbxJx3Nl2wLPLdfTVo xgGnX2yieKeQi8xL/N/xtIUDEPSLEpRADJuhcag+qd3DMJiYbR7S5PSUKU7CnFKq+YNpd3 bWk1cxrv5cIVXEO8uOfJTYzQLYYdg8w= X-MC-Unique: 4E2YGmFpOKqs7_tv22KEXQ-1 X-Mimecast-MFC-AGG-ID: 4E2YGmFpOKqs7_tv22KEXQ_1789137433 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 19/28] hw/misc: mark pvpanic, vmcoreinfo as secure Date: Fri, 11 Sep 2026 15:36:18 +0100 Message-ID: <20260911143627.2743803-20-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: t3IsF9gWR1tzs7xkqtSHsRHnRX9KeL27IhDv_jqKFvM_1789137433 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1789137437-D534D87B-836A52B1/0/0 X-purgate-type: clean X-purgate-size: 2171 The first two devices are common debug aids for virtualized guests so must be marked secure. Signed-off-by: Daniel P. Berrangé --- hw/misc/pvpanic-isa.c | 1 + hw/misc/pvpanic-mmio.c | 1 + hw/misc/pvpanic-pci.c | 1 + hw/misc/vmcoreinfo.c | 1 + 4 files changed, 4 insertions(+) diff --git a/hw/misc/pvpanic-isa.c b/hw/misc/pvpanic-isa.c index 85fb7da5e5..bb0a7ff6f8 100644 --- a/hw/misc/pvpanic-isa.c +++ b/hw/misc/pvpanic-isa.c @@ -121,6 +121,7 @@ static const TypeInfo pvpanic_isa_info = { .instance_size = sizeof(PVPanicISAState), .instance_init = pvpanic_isa_initfn, .class_init = pvpanic_isa_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_ACPI_DEV_AML_IF }, { }, diff --git a/hw/misc/pvpanic-mmio.c b/hw/misc/pvpanic-mmio.c index a173a1a9a5..161e8fc59b 100644 --- a/hw/misc/pvpanic-mmio.c +++ b/hw/misc/pvpanic-mmio.c @@ -50,6 +50,7 @@ static const TypeInfo pvpanic_mmio_info = { .instance_size = sizeof(PVPanicMMIOState), .instance_init = pvpanic_mmio_initfn, .class_init = pvpanic_mmio_class_init, + .secure = true, }; static void pvpanic_register_types(void) diff --git a/hw/misc/pvpanic-pci.c b/hw/misc/pvpanic-pci.c index 5509f70a3e..7d1f99d564 100644 --- a/hw/misc/pvpanic-pci.c +++ b/hw/misc/pvpanic-pci.c @@ -80,6 +80,7 @@ static const TypeInfo pvpanic_pci_info = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(PVPanicPCIState), .class_init = pvpanic_pci_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { } diff --git a/hw/misc/vmcoreinfo.c b/hw/misc/vmcoreinfo.c index 9c2e9005ad..90f361b05f 100644 --- a/hw/misc/vmcoreinfo.c +++ b/hw/misc/vmcoreinfo.c @@ -101,6 +101,7 @@ static const TypeInfo vmcoreinfo_types[] = { .parent = TYPE_DEVICE, .instance_size = sizeof(VMCoreInfoState), .class_init = vmcoreinfo_device_class_init, + .secure = true, } }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:37:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:37:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417104.1646099 (Exim 4.92) (envelope-from ) id 1x52NU-0000gQ-CQ; Fri, 11 Sep 2026 14:37:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417104.1646099; Fri, 11 Sep 2026 14:37:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NT-0000dy-Tt; Fri, 11 Sep 2026 14:37:19 +0000 Received: by outflank-mailman (input) for mailman id 1417104; Fri, 11 Sep 2026 14:37:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52NR-0000Ec-Ls for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:37:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52NR-009Xr7-23 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:37:17 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa411ff-e002-0a2a0a5209dd-0a2a450a88f0-32 for ; Fri, 11 Sep 2026 16:37:17 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4121b-f2d2-0a2a450a0019-aa0a817ca307-3 for ; Fri, 11 Sep 2026 16:37:16 +0200 Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-195-tL51sFxgNQuw0u-1lM6utQ-1; Fri, 11 Sep 2026 10:37:12 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D46641800671; Fri, 11 Sep 2026 14:37:10 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1256F3000229; Fri, 11 Sep 2026 14:37:08 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aPFHkXJSs0u/ISQJq2BRt28+2MaWYtAQufJCPx92BiY=; b=TPdd98mKrxNXL2+EIhIh10ltl/JLWBaLFfl54cozI6oTQbLaim9cIT2Q3avrt0lKHjEkbr SUEuQPExkrOvu8I4k5d0xCDjadi9P7Zv879tUUGwJ3y81pswFsWoqTH58BQtQdWa4WArOa tt7KhIqU38LYLhD7fdjfC8T6crjMpxQ= X-MC-Unique: tL51sFxgNQuw0u-1lM6utQ-1 X-Mimecast-MFC-AGG-ID: tL51sFxgNQuw0u-1lM6utQ_1789137431 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 18/28] hw/tpm: mark all TPM implementations as secure Date: Fri, 11 Sep 2026 15:36:17 +0100 Message-ID: <20260911143627.2743803-19-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: QzxV_2AUwi2OIMLVgJDOui59ym3Lxo759aLa6HiEk10_1789137431 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1789137437-593C4CFC-250E63C6/0/0 X-purgate-type: clean X-purgate-size: 3198 All of the TPM implementations are in scope of virtualization usage, so mark them all as secure. Signed-off-by: Daniel P. Berrangé --- hw/ppc/spapr_tpm_proxy.c | 1 + hw/tpm/tpm_crb.c | 1 + hw/tpm/tpm_spapr.c | 1 + hw/tpm/tpm_tis_i2c.c | 1 + hw/tpm/tpm_tis_isa.c | 1 + hw/tpm/tpm_tis_sysbus.c | 1 + 6 files changed, 6 insertions(+) diff --git a/hw/ppc/spapr_tpm_proxy.c b/hw/ppc/spapr_tpm_proxy.c index 19889e80bc..bb6efec20c 100644 --- a/hw/ppc/spapr_tpm_proxy.c +++ b/hw/ppc/spapr_tpm_proxy.c @@ -166,6 +166,7 @@ static const TypeInfo spapr_tpm_proxy_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(SpaprTpmProxy), .class_init = spapr_tpm_proxy_class_init, + .secure = true, }; static void spapr_tpm_proxy_register_types(void) diff --git a/hw/tpm/tpm_crb.c b/hw/tpm/tpm_crb.c index 54fa2042b5..2e9445ad79 100644 --- a/hw/tpm/tpm_crb.c +++ b/hw/tpm/tpm_crb.c @@ -547,6 +547,7 @@ static const TypeInfo tpm_crb_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(CRBState), .class_init = tpm_crb_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_TPM_IF }, { } diff --git a/hw/tpm/tpm_spapr.c b/hw/tpm/tpm_spapr.c index 19075d1f01..3957c5268b 100644 --- a/hw/tpm/tpm_spapr.c +++ b/hw/tpm/tpm_spapr.c @@ -414,6 +414,7 @@ static const TypeInfo tpm_spapr_info = { .parent = TYPE_VIO_SPAPR_DEVICE, .instance_size = sizeof(SpaprTpmState), .class_init = tpm_spapr_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_TPM_IF }, { } diff --git a/hw/tpm/tpm_tis_i2c.c b/hw/tpm/tpm_tis_i2c.c index b4f258c7bc..302296affb 100644 --- a/hw/tpm/tpm_tis_i2c.c +++ b/hw/tpm/tpm_tis_i2c.c @@ -551,6 +551,7 @@ static const TypeInfo tpm_tis_i2c_info = { .name = TYPE_TPM_TIS_I2C, .parent = TYPE_I2C_SLAVE, .instance_size = sizeof(TPMStateI2C), + .secure = true, .class_init = tpm_tis_i2c_class_init, .interfaces = (const InterfaceInfo[]) { { TYPE_TPM_IF }, diff --git a/hw/tpm/tpm_tis_isa.c b/hw/tpm/tpm_tis_isa.c index 2b1267133a..da3a932b03 100644 --- a/hw/tpm/tpm_tis_isa.c +++ b/hw/tpm/tpm_tis_isa.c @@ -187,6 +187,7 @@ static const TypeInfo tpm_tis_isa_info = { .instance_size = sizeof(TPMStateISA), .instance_init = tpm_tis_isa_initfn, .class_init = tpm_tis_isa_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_TPM_IF }, { TYPE_ACPI_DEV_AML_IF }, diff --git a/hw/tpm/tpm_tis_sysbus.c b/hw/tpm/tpm_tis_sysbus.c index a7b0002d82..0afb52c3be 100644 --- a/hw/tpm/tpm_tis_sysbus.c +++ b/hw/tpm/tpm_tis_sysbus.c @@ -167,6 +167,7 @@ static const TypeInfo tpm_tis_sysbus_info = { .instance_init = tpm_tis_sysbus_initfn, .instance_finalize = tpm_tis_sysbus_finalize, .class_init = tpm_tis_sysbus_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_TPM_IF }, { } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:39:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:39:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417199.1646117 (Exim 4.92) (envelope-from ) id 1x52PU-0005dp-A4; Fri, 11 Sep 2026 14:39:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417199.1646117; Fri, 11 Sep 2026 14:39:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52PU-0005di-6n; Fri, 11 Sep 2026 14:39:24 +0000 Received: by outflank-mailman (input) for mailman id 1417199; Fri, 11 Sep 2026 14:39:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52PS-0005dZ-VA for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:39:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52PS-002YOl-C3 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:22 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41279-e002-0a2a0a5209dd-0a2a4502a2b6-34 for ; Fri, 11 Sep 2026 16:39:21 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41220-6ca4-0a2a45020019-aa0a817ce1a3-3 for ; Fri, 11 Sep 2026 16:37:21 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-179-i4RerftSO0aK-nu0DOj5Rw-1; Fri, 11 Sep 2026 10:37:16 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 757F7195396B; Fri, 11 Sep 2026 14:37:15 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 69BE13000229; Fri, 11 Sep 2026 14:37:13 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137440; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yxYKHi5v7tz+GMZ37WJGGk/4FLpJ0TR7q5S8Sx5LFw0=; b=a5QGiJmA29zF3+QH9Eyei17CDCrGRKhnf2gIcnjH5RW4m8AmnImlmx9lr2Q0ddndm1Cmsl IewKgn4Ex5EKEXWjkGEfxKXxfVGOqsL1M5xf0YVTnaS+qvixmnbSLCDGaXLFVaRsj1TWjq yApWawm+g/2iSZRP49Fu84xYuiLgk1k= X-MC-Unique: i4RerftSO0aK-nu0DOj5Rw-1 X-Mimecast-MFC-AGG-ID: i4RerftSO0aK-nu0DOj5Rw_1789137435 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 20/28] hw/audio: mark Intel HDA devices & codecs as secure Date: Fri, 11 Sep 2026 15:36:19 +0100 Message-ID: <20260911143627.2743803-21-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: nH0m4iIitaD4-bE8UTXjnySWV85butJqAJYYVz_Ksgc_1789137435 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789137441-678BC2AC-DED402DC/0/0 X-purgate-type: clean X-purgate-size: 3233 This is traditionally the primary audio backend for x86 as virtio-snd is a relatively new invention. Signed-off-by: Daniel P. Berrangé --- hw/audio/hda-codec.c | 4 ++++ hw/audio/intel-hda.c | 5 +++++ 2 files changed, 9 insertions(+) diff --git a/hw/audio/hda-codec.c b/hw/audio/hda-codec.c index 173fe56bea..05bd35700f 100644 --- a/hw/audio/hda-codec.c +++ b/hw/audio/hda-codec.c @@ -858,6 +858,7 @@ static const TypeInfo hda_audio_info = { .instance_size = sizeof(HDAAudioState), .class_init = hda_audio_base_class_init, .abstract = true, + .secure = true, }; static void hda_audio_output_class_init(ObjectClass *klass, const void *data) @@ -873,6 +874,7 @@ static const TypeInfo hda_audio_output_info = { .name = "hda-output", .parent = TYPE_HDA_AUDIO, .class_init = hda_audio_output_class_init, + .secure = true, }; static void hda_audio_duplex_class_init(ObjectClass *klass, const void *data) @@ -888,6 +890,7 @@ static const TypeInfo hda_audio_duplex_info = { .name = "hda-duplex", .parent = TYPE_HDA_AUDIO, .class_init = hda_audio_duplex_class_init, + .secure = true, }; static void hda_audio_micro_class_init(ObjectClass *klass, const void *data) @@ -903,6 +906,7 @@ static const TypeInfo hda_audio_micro_info = { .name = "hda-micro", .parent = TYPE_HDA_AUDIO, .class_init = hda_audio_micro_class_init, + .secure = true, }; static void hda_audio_register_types(void) diff --git a/hw/audio/intel-hda.c b/hw/audio/intel-hda.c index 3d361a4976..34ca1e713c 100644 --- a/hw/audio/intel-hda.c +++ b/hw/audio/intel-hda.c @@ -45,6 +45,7 @@ static const TypeInfo hda_codec_bus_info = { .name = TYPE_HDA_BUS, .parent = TYPE_BUS, .instance_size = sizeof(HDACodecBus), + .secure = true, }; void hda_codec_bus_init(DeviceState *dev, HDACodecBus *bus, size_t bus_size, @@ -1265,6 +1266,7 @@ static const TypeInfo intel_hda_info = { .instance_size = sizeof(IntelHDAState), .class_init = intel_hda_class_init, .abstract = true, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, @@ -1275,12 +1277,14 @@ static const TypeInfo intel_hda_info_ich6 = { .name = "intel-hda", .parent = TYPE_INTEL_HDA_GENERIC, .class_init = intel_hda_class_init_ich6, + .secure = true, }; static const TypeInfo intel_hda_info_ich9 = { .name = "ich9-intel-hda", .parent = TYPE_INTEL_HDA_GENERIC, .class_init = intel_hda_class_init_ich9, + .secure = true, }; static void hda_codec_device_class_init(ObjectClass *klass, const void *data) @@ -1298,6 +1302,7 @@ static const TypeInfo hda_codec_device_type_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(HDACodecDevice), .abstract = true, + .secure = true, .class_size = sizeof(HDACodecDeviceClass), .class_init = hda_codec_device_class_init, }; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:39:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:39:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417201.1646125 (Exim 4.92) (envelope-from ) id 1x52PX-00063b-HY; Fri, 11 Sep 2026 14:39:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417201.1646125; Fri, 11 Sep 2026 14:39:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52PX-00063Q-EW; Fri, 11 Sep 2026 14:39:27 +0000 Received: by outflank-mailman (input) for mailman id 1417201; Fri, 11 Sep 2026 14:39:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52PV-0005nQ-Fs for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:39:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52PU-008k5A-I2 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:24 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41275-2eae-0a2a0a5409dd-0a2a4505e0b0-40 for ; Fri, 11 Sep 2026 16:39:24 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41222-4cb1-0a2a45050019-aa0a817cdb89-3 for ; Fri, 11 Sep 2026 16:37:23 +0200 Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-59-W42a8qfsNH2p7bdSc5eAqg-1; Fri, 11 Sep 2026 10:37:19 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9690319541AA; Fri, 11 Sep 2026 14:37:17 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id C76CA3000229; Fri, 11 Sep 2026 14:37:15 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137442; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wEyJiloIxtptu0W9QtcTvVPDda5vfdApyxEeJL8U5FU=; b=WUUgZSvVfdA5XUWUE3nyUAuBSv/tS7e8UxxPbJOb/3deIMCtkoJWRGD5AbM5yUsn8Co7Jy vdQWHUH6jKjUq4yIZWnn0BwkGH+uGtHoMS9Yv0NVdHqdbcQBLNue8MIwVSpy2CT3389WWZ GZCXG5UQ8sRNOsJaOHvqCNLId5L+Lbc= X-MC-Unique: W42a8qfsNH2p7bdSc5eAqg-1 X-Mimecast-MFC-AGG-ID: W42a8qfsNH2p7bdSc5eAqg_1789137437 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 21/28] hw/char: mark common serial / console devicess a secure Date: Fri, 11 Sep 2026 15:36:20 +0100 Message-ID: <20260911143627.2743803-22-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: egqsuJbCNv6NvGCHPcrj9xmModWFebiQUSDHOyWFhAA_1789137437 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1789137443-F7CB82A1-49007513/0/0 X-purgate-type: clean X-purgate-size: 3524 These are needed as a baseline feature for many virtualization use cases on x86, PPC64 and s390x. Signed-off-by: Daniel P. Berrangé --- hw/char/debugcon.c | 1 + hw/char/sclpconsole-lm.c | 1 + hw/char/sclpconsole.c | 1 + hw/char/serial-isa.c | 1 + hw/char/serial-pci.c | 1 + hw/char/serial.c | 1 + hw/char/spapr_vty.c | 1 + 7 files changed, 7 insertions(+) diff --git a/hw/char/debugcon.c b/hw/char/debugcon.c index a1b370b90b..f38ce7b765 100644 --- a/hw/char/debugcon.c +++ b/hw/char/debugcon.c @@ -134,6 +134,7 @@ static const TypeInfo debugcon_isa_info = { .parent = TYPE_ISA_DEVICE, .instance_size = sizeof(ISADebugconState), .class_init = debugcon_isa_class_initfn, + .secure = true, }; static void debugcon_register_types(void) diff --git a/hw/char/sclpconsole-lm.c b/hw/char/sclpconsole-lm.c index f6ed282f1b..4261652735 100644 --- a/hw/char/sclpconsole-lm.c +++ b/hw/char/sclpconsole-lm.c @@ -363,6 +363,7 @@ static const TypeInfo sclp_console_info = { .instance_size = sizeof(SCLPConsoleLM), .class_init = console_class_init, .class_size = sizeof(SCLPEventClass), + .secure = true, }; static void register_types(void) diff --git a/hw/char/sclpconsole.c b/hw/char/sclpconsole.c index 179d12745c..04a951089a 100644 --- a/hw/char/sclpconsole.c +++ b/hw/char/sclpconsole.c @@ -278,6 +278,7 @@ static const TypeInfo sclp_console_info = { .instance_size = sizeof(SCLPConsole), .class_init = console_class_init, .class_size = sizeof(SCLPEventClass), + .secure = true, }; static void register_types(void) diff --git a/hw/char/serial-isa.c b/hw/char/serial-isa.c index eaa4e843c0..5df87590b7 100644 --- a/hw/char/serial-isa.c +++ b/hw/char/serial-isa.c @@ -147,6 +147,7 @@ static const TypeInfo serial_isa_info = { .instance_size = sizeof(ISASerialState), .instance_init = serial_isa_initfn, .class_init = serial_isa_class_initfn, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_ACPI_DEV_AML_IF }, { }, diff --git a/hw/char/serial-pci.c b/hw/char/serial-pci.c index d8cacc9085..183091ea41 100644 --- a/hw/char/serial-pci.c +++ b/hw/char/serial-pci.c @@ -109,6 +109,7 @@ static const TypeInfo serial_pci_info = { .instance_size = sizeof(PCISerialState), .instance_init = serial_pci_init, .class_init = serial_pci_class_initfn, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/char/serial.c b/hw/char/serial.c index 4339562ab0..fefd2cf9fc 100644 --- a/hw/char/serial.c +++ b/hw/char/serial.c @@ -984,6 +984,7 @@ static const TypeInfo serial_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(SerialState), .class_init = serial_class_init, + .secure = true, }; static void serial_register_types(void) diff --git a/hw/char/spapr_vty.c b/hw/char/spapr_vty.c index 1dd9fb155c..96a4e58ad9 100644 --- a/hw/char/spapr_vty.c +++ b/hw/char/spapr_vty.c @@ -201,6 +201,7 @@ static const TypeInfo spapr_vty_info = { .parent = TYPE_VIO_SPAPR_DEVICE, .instance_size = sizeof(SpaprVioVty), .class_init = spapr_vty_class_init, + .secure = true, }; SpaprVioDevice *spapr_vty_get_default(SpaprVioBus *bus) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:39:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:39:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417207.1646134 (Exim 4.92) (envelope-from ) id 1x52Pc-0006Kv-Nq; Fri, 11 Sep 2026 14:39:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417207.1646134; Fri, 11 Sep 2026 14:39:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Pc-0006Kk-KM; Fri, 11 Sep 2026 14:39:32 +0000 Received: by outflank-mailman (input) for mailman id 1417207; Fri, 11 Sep 2026 14:39:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Pb-0006Jp-Ob for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:39:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Pb-008k5A-54 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41280-2eae-0a2a0a5409dd-0a2a45039fec-34 for ; Fri, 11 Sep 2026 16:39:31 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41229-fae8-0a2a45030019-aa0a817cb83d-3 for ; Fri, 11 Sep 2026 16:37:30 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-517-snL57JxmM_i6WZC-vCI9tQ-1; Fri, 11 Sep 2026 10:37:26 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 398031955DD1; Fri, 11 Sep 2026 14:37:24 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 69BE23000229; Fri, 11 Sep 2026 14:37:22 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137449; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cNbkkFHCYKpbxfWO4D+I7H8XxjKgGoTqJimeW8ycrfY=; b=WXyBeFZ9AySlJ1F+vco5uWIpC5zz/McJmXRjSosN4O0quXa3vtqF56Jbn6/b4Bi0l/38Qw G1IRAODGVZ2A8eckarPKjqVn/WlmC+TnFrfpKkvB/q8JGo243h/MjrmEcGYil4CdD5/716 IjJdZX00fKKgNAey/zQNQHs+5d9/lEY= X-MC-Unique: snL57JxmM_i6WZC-vCI9tQ-1 X-Mimecast-MFC-AGG-ID: snL57JxmM_i6WZC-vCI9tQ_1789137444 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 24/28] hw/acpi: mark erst, vmclock and vmgenid devices as secure Date: Fri, 11 Sep 2026 15:36:23 +0100 Message-ID: <20260911143627.2743803-25-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: Hl9n_7seTJtGRNdjwWJHf7YIsI3TepTT0LKda-XYXZ8_1789137444 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1789137451-74A894E9-10EC1B5B/13/0 X-purgate-type: clean X-purgate-size: 1585 These are all used in virtualization scenarios so must be declare to provide a security boundary Signed-off-by: Daniel P. Berrangé --- hw/acpi/erst.c | 1 + hw/acpi/vmclock.c | 1 + hw/acpi/vmgenid.c | 1 + 3 files changed, 3 insertions(+) diff --git a/hw/acpi/erst.c b/hw/acpi/erst.c index b6c1942e30..44560004a5 100644 --- a/hw/acpi/erst.c +++ b/hw/acpi/erst.c @@ -1044,6 +1044,7 @@ static const TypeInfo erst_type_info = { .parent = TYPE_PCI_DEVICE, .class_init = erst_class_init, .instance_size = sizeof(ERSTDeviceState), + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { } diff --git a/hw/acpi/vmclock.c b/hw/acpi/vmclock.c index d51cab2e20..b545354600 100644 --- a/hw/acpi/vmclock.c +++ b/hw/acpi/vmclock.c @@ -169,6 +169,7 @@ static const TypeInfo vmclock_device_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(VmclockState), .class_init = vmclock_device_class_init, + .secure = true, }; static void vmclock_register_types(void) diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c index 27cc0128d1..67f815d8a1 100644 --- a/hw/acpi/vmgenid.c +++ b/hw/acpi/vmgenid.c @@ -236,6 +236,7 @@ static const TypeInfo vmgenid_device_info = { .parent = TYPE_DEVICE, .instance_size = sizeof(VmGenIdState), .class_init = vmgenid_device_class_init, + .secure = true, }; static void vmgenid_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:39:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:39:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417208.1646138 (Exim 4.92) (envelope-from ) id 1x52Pc-0006Np-VP; Fri, 11 Sep 2026 14:39:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417208.1646138; Fri, 11 Sep 2026 14:39:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Pc-0006Nc-SD; Fri, 11 Sep 2026 14:39:32 +0000 Received: by outflank-mailman (input) for mailman id 1417208; Fri, 11 Sep 2026 14:39:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Pc-0006K3-0q for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:39:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Pb-002YOl-Dq for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:31 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41299-e002-0a2a0a5209dd-0a2a450b8d1c-24 for ; Fri, 11 Sep 2026 16:39:31 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4122a-b7e8-0a2a450b0019-aa0a857c6b7f-3 for ; Fri, 11 Sep 2026 16:37:31 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-318-pyBOGgksO1SEGyquYx9xNw-1; Fri, 11 Sep 2026 10:37:27 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 727321955DCD; Fri, 11 Sep 2026 14:37:26 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 899033000229; Fri, 11 Sep 2026 14:37:24 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137449; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ty7jgU/VRH/YaPH0fwHwHbb1p4FYEmeRhPcsE2aO8tg=; b=JeBQ0LbOY3P9jyAlUqmxv8tRJQd9QgpaFuCzqbKEd1GR81IGZPN2IE9GVGD+tXTC4bnor6 c2TsjPVMjLVjfHEeDkZQ0ENTS8wesfuNyZAE036jBsMLzPZ4xIxI7IXLvazQ8v+y0wPP+e in9v8/QxboakODil5FKtR8IqK6BD29s= X-MC-Unique: pyBOGgksO1SEGyquYx9xNw-1 X-Mimecast-MFC-AGG-ID: pyBOGgksO1SEGyquYx9xNw_1789137446 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 25/28] hw: mark KVM clock and RTC devices as secure Date: Fri, 11 Sep 2026 15:36:24 +0100 Message-ID: <20260911143627.2743803-26-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: dv-cyybNrhdv8A0D7F7CqbkiwanAc0Ff7Nnb9Hx27lU_1789137446 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789137451-1BED69EA-B712E62D/13/0 X-purgate-type: clean X-purgate-size: 1176 These are core infrastructure in virtualization cases so must provide a security boundary. Signed-off-by: Daniel P. Berrangé --- hw/i386/kvm/clock.c | 1 + hw/rtc/mc146818rtc.c | 1 + 2 files changed, 2 insertions(+) diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c index e3dad136d3..d3e2301311 100644 --- a/hw/i386/kvm/clock.c +++ b/hw/i386/kvm/clock.c @@ -366,6 +366,7 @@ static const TypeInfo kvmclock_info = { .parent = TYPE_SYS_BUS_DEVICE, .instance_size = sizeof(KVMClockState), .class_init = kvmclock_class_init, + .secure = true, }; /* Note: Must be called after VCPU initialization. */ diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c index ba396435d1..66f8b177e7 100644 --- a/hw/rtc/mc146818rtc.c +++ b/hw/rtc/mc146818rtc.c @@ -1027,6 +1027,7 @@ static const TypeInfo mc146818rtc_info = { .parent = TYPE_ISA_DEVICE, .instance_size = sizeof(MC146818RtcState), .class_init = rtc_class_initfn, + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_ACPI_DEV_AML_IF }, { }, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:39:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:39:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417209.1646145 (Exim 4.92) (envelope-from ) id 1x52Pd-0006VN-DH; Fri, 11 Sep 2026 14:39:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417209.1646145; Fri, 11 Sep 2026 14:39:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Pd-0006U5-7d; Fri, 11 Sep 2026 14:39:33 +0000 Received: by outflank-mailman (input) for mailman id 1417209; Fri, 11 Sep 2026 14:39:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Pc-0006KL-C7 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:39:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Pb-0065ri-NA for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:31 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4128c-8faa-0a2a0a5109dd-0a2a4506e9d8-36 for ; Fri, 11 Sep 2026 16:39:31 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4122a-195a-0a2a45060019-aa0a857c6711-3 for ; Fri, 11 Sep 2026 16:37:31 +0200 Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-232-8svhV57tPAqXhzJY7uftTA-1; Fri, 11 Sep 2026 10:37:23 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 18A691955BFC; Fri, 11 Sep 2026 14:37:22 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 2E31F300022B; Fri, 11 Sep 2026 14:37:20 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qMFoXRSqJagVBm5GVPbfKFycLqDC+N9k5/iDYiZvJ88=; b=cpZwh6/zt5ZenNBlGS/OxqpsSY3ZPa/Mp3ho/XNs+3k5My2D6UKpyjjoCiuUOstP3yyDoQ mKA0b9TPMXPoIaH2LSXn1rQGSveZVDksaOMuSGgKzy6ZLvB9brYN5643cm2YoUIplQTpgg F1eVj0Nd52/Ll8QsoqM0YYgPYrjQiYI= X-MC-Unique: 8svhV57tPAqXhzJY7uftTA-1 X-Mimecast-MFC-AGG-ID: 8svhV57tPAqXhzJY7uftTA_1789137442 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 23/28] hw/uefi: mark the EFI vars service as secure Date: Fri, 11 Sep 2026 15:36:22 +0100 Message-ID: <20260911143627.2743803-24-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: UxreJGr_N71FBDcD-qylAaRQauCduqUFmhv_jJSMVv8_1789137442 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1789137451-1F6C877B-C1D8025D/13/0 X-purgate-type: clean X-purgate-size: 990 This is used to persist EFI variables when NVRAM is not available or undesirable. Signed-off-by: Daniel P. Berrangé --- hw/uefi/var-service-sysbus.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/uefi/var-service-sysbus.c b/hw/uefi/var-service-sysbus.c index 97a96cae6a..6bec14733b 100644 --- a/hw/uefi/var-service-sysbus.c +++ b/hw/uefi/var-service-sysbus.c @@ -84,6 +84,7 @@ static const TypeInfo uefi_vars_sysbus_info = { .instance_size = sizeof(uefi_vars_sysbus_state), .instance_init = uefi_vars_sysbus_init, .class_init = uefi_vars_sysbus_class_init, + .secure = true, }; module_obj(TYPE_UEFI_VARS_SYSBUS); @@ -113,6 +114,7 @@ static const TypeInfo uefi_vars_x64_info = { .name = TYPE_UEFI_VARS_X64, .parent = TYPE_UEFI_VARS_SYSBUS, .class_init = uefi_vars_x64_class_init, + .secure = true, }; module_obj(TYPE_UEFI_VARS_X64); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:39:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:39:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417224.1646160 (Exim 4.92) (envelope-from ) id 1x52Pu-0007k2-QZ; Fri, 11 Sep 2026 14:39:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417224.1646160; Fri, 11 Sep 2026 14:39:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Pu-0007jJ-Nm; Fri, 11 Sep 2026 14:39:50 +0000 Received: by outflank-mailman (input) for mailman id 1417224; Fri, 11 Sep 2026 14:39:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Ps-0007eB-Lt for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:39:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Ps-008k9i-2k for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:48 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa412aa-bab6-0a2a0a5309dd-0a2a4509a44a-14 for ; Fri, 11 Sep 2026 16:39:47 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4123a-be1a-0a2a45090019-aa0a817cd06b-3 for ; Fri, 11 Sep 2026 16:37:47 +0200 Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-509-K8Q0iPxAPu2Rsbr4sUyPuQ-1; Fri, 11 Sep 2026 10:37:43 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C452D180123E; Fri, 11 Sep 2026 14:37:19 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E727B300022B; Fri, 11 Sep 2026 14:37:17 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137466; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8kxcCgP5PTMsq/qRVeHwqOnLQiiXhy3S28nEGioaumU=; b=c2tmHbHmoN6B9wrBze6VobS1WFF5+/qpYqSUFp2ZpgsZy/8dlQmnc4SbTXN3JCupMQfubr nRE8dhGlWGqrOcCXaERcxpjnoVjeXdkrAsKDaccuTToJeTJyeKYVisz1604xAJ2QF17oJ0 KF4iKaAEOkGWnfZ5vm0HBzDhV+BOj2A= X-MC-Unique: K8Q0iPxAPu2Rsbr4sUyPuQ-1 X-Mimecast-MFC-AGG-ID: K8Q0iPxAPu2Rsbr4sUyPuQ_1789137461 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 22/28] hw/mem: mark nvdimm, pc-dimm & spapr-nvdimm devices as secure Date: Fri, 11 Sep 2026 15:36:21 +0100 Message-ID: <20260911143627.2743803-23-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: L9eBzhMOFLTgbNKmsAnDW2ZxREGcQk6bb27nofWQXj0_1789137461 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1789137467-FC212034-8097E210/13/0 X-purgate-type: clean X-purgate-size: 1590 These devices are used in virutalization scenarios to support memory hotplug and other uses cases. Signed-off-by: Daniel P. Berrangé --- hw/mem/nvdimm.c | 1 + hw/mem/pc-dimm.c | 1 + hw/ppc/spapr_nvdimm.c | 1 + 3 files changed, 3 insertions(+) diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c index cf8a4d8c5f..9a57579845 100644 --- a/hw/mem/nvdimm.c +++ b/hw/mem/nvdimm.c @@ -275,6 +275,7 @@ static const TypeInfo nvdimm_info = { .instance_size = sizeof(NVDIMMDevice), .instance_init = nvdimm_init, .instance_finalize = nvdimm_finalize, + .secure = true, }; static void nvdimm_register_types(void) diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c index 68862926ee..89fd06724c 100644 --- a/hw/mem/pc-dimm.c +++ b/hw/mem/pc-dimm.c @@ -301,6 +301,7 @@ static const TypeInfo pc_dimm_info = { .instance_init = pc_dimm_init, .class_init = pc_dimm_class_init, .class_size = sizeof(PCDIMMDeviceClass), + .secure = true, .interfaces = (const InterfaceInfo[]) { { TYPE_MEMORY_DEVICE }, { } diff --git a/hw/ppc/spapr_nvdimm.c b/hw/ppc/spapr_nvdimm.c index 6647428391..b927cf21b8 100644 --- a/hw/ppc/spapr_nvdimm.c +++ b/hw/ppc/spapr_nvdimm.c @@ -916,6 +916,7 @@ static TypeInfo spapr_nvdimm_info = { .class_size = sizeof(SPAPRNVDIMMClass), .instance_size = sizeof(SpaprNVDIMMDevice), .instance_init = spapr_nvdimm_init, + .secure = true, }; static void spapr_nvdimm_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:39:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:39:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417228.1646171 (Exim 4.92) (envelope-from ) id 1x52Q1-00089y-3L; Fri, 11 Sep 2026 14:39:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417228.1646171; Fri, 11 Sep 2026 14:39:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Q0-00089o-Uv; Fri, 11 Sep 2026 14:39:56 +0000 Received: by outflank-mailman (input) for mailman id 1417228; Fri, 11 Sep 2026 14:39:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Q0-00088q-6d for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:39:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Pz-008k9i-Jt for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:55 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa412aa-bab6-0a2a0a5309dd-0a2a4509a44a-24 for ; Fri, 11 Sep 2026 16:39:55 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41242-be1a-0a2a45090019-aa0a817c9f27-3 for ; Fri, 11 Sep 2026 16:37:55 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-401-yBd4u00wMKm-TAHlAmivtQ-1; Fri, 11 Sep 2026 10:37:49 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 07F5B1944F0D; Fri, 11 Sep 2026 14:37:31 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0D1A6300022B; Fri, 11 Sep 2026 14:37:28 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137474; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ntaO5zXCqDIHHnqqZoaRC9y/DkKQ0xZ5Zjqm3Fkdzdk=; b=jIH2ObkjtaCrlTY+03reZcp750ki0cwT+c4c6umPQ6vGwKoIEaR/UFgalvoh/FZG8vJ904 6wdLE4QbGwFxJeGjDMzdwxmjbvia+ZYJPmE4eyA83Se2NucqrE6fgVu/J1g0qxqC9qrCVk dvXHsIx4TV3/ITXqeESbNRFia3pSSeg= X-MC-Unique: yBd4u00wMKm-TAHlAmivtQ-1 X-Mimecast-MFC-AGG-ID: yBd4u00wMKm-TAHlAmivtQ_1789137468 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 27/28] hw/input: mark PS/2 and PC Keyboard devices as secure Date: Fri, 11 Sep 2026 15:36:26 +0100 Message-ID: <20260911143627.2743803-28-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: 8zb5lcpadP9NJ7uyTKxB8Vt3yEpNmKKtAXMyMP7YCu8_1789137468 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1789137475-3B2DC034-43FFF7B4/0/0 X-purgate-type: clean X-purgate-size: 1978 These are part of the baseline x86 featureset so required for virtualization use cases. Signed-off-by: Daniel P. Berrangé --- hw/input/pckbd.c | 3 ++- hw/input/ps2.c | 9 ++++++--- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c index b09c3bce93..0250252cd6 100644 --- a/hw/input/pckbd.c +++ b/hw/input/pckbd.c @@ -766,7 +766,8 @@ static const TypeInfo i8042_mmio_info = { .parent = TYPE_SYS_BUS_DEVICE, .instance_init = i8042_mmio_init, .instance_size = sizeof(MMIOKBDState), - .class_init = i8042_mmio_class_init + .class_init = i8042_mmio_class_init, + .secure = true, }; void i8042_isa_mouse_fake_event(ISAKBDState *isa) diff --git a/hw/input/ps2.c b/hw/input/ps2.c index 01af4350b3..8588f39f99 100644 --- a/hw/input/ps2.c +++ b/hw/input/ps2.c @@ -1293,7 +1293,8 @@ static const TypeInfo ps2_kbd_info = { .name = TYPE_PS2_KBD_DEVICE, .parent = TYPE_PS2_DEVICE, .instance_size = sizeof(PS2KbdState), - .class_init = ps2_kbd_class_init + .class_init = ps2_kbd_class_init, + .secure = true, }; static void ps2_mouse_class_init(ObjectClass *klass, const void *data) @@ -1313,7 +1314,8 @@ static const TypeInfo ps2_mouse_info = { .name = TYPE_PS2_MOUSE_DEVICE, .parent = TYPE_PS2_DEVICE, .instance_size = sizeof(PS2MouseState), - .class_init = ps2_mouse_class_init + .class_init = ps2_mouse_class_init, + .secure = true, }; static void ps2_init(Object *obj) @@ -1340,7 +1342,8 @@ static const TypeInfo ps2_info = { .instance_size = sizeof(PS2State), .class_init = ps2_class_init, .class_size = sizeof(PS2DeviceClass), - .abstract = true + .abstract = true, + .secure = true, }; static void ps2_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:39:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:39:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417229.1646174 (Exim 4.92) (envelope-from ) id 1x52Q1-0008ES-Cf; Fri, 11 Sep 2026 14:39:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417229.1646174; Fri, 11 Sep 2026 14:39:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Q1-0008DA-81; Fri, 11 Sep 2026 14:39:57 +0000 Received: by outflank-mailman (input) for mailman id 1417229; Fri, 11 Sep 2026 14:39:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Q0-00088v-9x for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:39:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Pz-008k9B-NA for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:55 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4129d-2eae-0a2a0a5409dd-0a2a450caa0c-40 for ; Fri, 11 Sep 2026 16:39:55 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41242-f479-0a2a450c0019-aa0a817c7e07-3 for ; Fri, 11 Sep 2026 16:37:55 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-401-GrM6ooB6MO2NkU78jUtD2w-1; Fri, 11 Sep 2026 10:37:49 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B06671964CF6; Fri, 11 Sep 2026 14:37:28 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id CE51C3000229; Fri, 11 Sep 2026 14:37:26 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137474; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SO3n0XnxHzcPurmZyEeQNszEXfuag/bmU5uMUoRgi50=; b=CFGAVvtWQ9OZwknxW4CvfR8Y8WjDdZSIBTb67ETn1z3I5MMs40uzTbTTga64asB40IKanE YlwYCmil6+AFbXWny6a+79O1ivJ+2TdCmqk9wUnLNR856WoQu1l3nv3TiGKoO+a0uzkSdJ ZXteivq2lVkykkCl7y14vxVQcYRRfoE= X-MC-Unique: GrM6ooB6MO2NkU78jUtD2w-1 X-Mimecast-MFC-AGG-ID: GrM6ooB6MO2NkU78jUtD2w_1789137468 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 26/28] hw: device AMD, Intel and ARM IOMMUs as secure Date: Fri, 11 Sep 2026 15:36:25 +0100 Message-ID: <20260911143627.2743803-27-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: 8yJ4KcJvqjEf0wAftGKlHyimbOHnv3vi5TToXDEvQUQ_1789137468 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1789137475-51538A5B-8481F200/0/0 X-purgate-type: clean X-purgate-size: 2741 These are needed in virtualization use cases to support PCI device assignment use cases so must provide a security boundary. Signed-off-by: Daniel P. Berrangé --- hw/arm/smmu-common.c | 1 + hw/arm/smmuv3.c | 2 ++ hw/i386/amd_iommu.c | 4 +++- hw/i386/intel_iommu.c | 1 + 4 files changed, 7 insertions(+), 1 deletion(-) diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c index 8e40ba603d..bca9a32e9f 100644 --- a/hw/arm/smmu-common.c +++ b/hw/arm/smmu-common.c @@ -1040,6 +1040,7 @@ static const TypeInfo smmu_base_info = { .class_size = sizeof(SMMUBaseClass), .class_init = smmu_base_class_init, .abstract = true, + .secure = true, }; static void smmu_base_register_types(void) diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index ed19536a4d..2a9721b87e 100644 --- a/hw/arm/smmuv3.c +++ b/hw/arm/smmuv3.c @@ -2272,12 +2272,14 @@ static const TypeInfo smmuv3_type_info = { .instance_init = smmuv3_instance_init, .class_size = sizeof(SMMUv3Class), .class_init = smmuv3_class_init, + .secure = true, }; static const TypeInfo smmuv3_iommu_memory_region_info = { .parent = TYPE_IOMMU_MEMORY_REGION, .name = TYPE_SMMUV3_IOMMU_MEMORY_REGION, .class_init = smmuv3_iommu_memory_region_class_init, + .secure = true, }; static void smmuv3_register_types(void) diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c index 578c27ccbe..3192609ba0 100644 --- a/hw/i386/amd_iommu.c +++ b/hw/i386/amd_iommu.c @@ -2783,7 +2783,8 @@ static const TypeInfo amdvi_sysbus = { .name = TYPE_AMD_IOMMU_DEVICE, .parent = TYPE_X86_IOMMU_DEVICE, .instance_size = sizeof(AMDVIState), - .class_init = amdvi_sysbus_class_init + .class_init = amdvi_sysbus_class_init, + .secure = true, }; static void amdvi_pci_class_init(ObjectClass *klass, const void *data) @@ -2805,6 +2806,7 @@ static const TypeInfo amdvi_pci = { .parent = TYPE_PCI_DEVICE, .instance_size = sizeof(AMDVIPCIState), .class_init = amdvi_pci_class_init, + .secure = true, .interfaces = (const InterfaceInfo[]) { { INTERFACE_CONVENTIONAL_PCI_DEVICE }, { }, diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 82c3c3b2c3..20e44590ca 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -5687,6 +5687,7 @@ static const TypeInfo vtd_info = { .parent = TYPE_X86_IOMMU_DEVICE, .instance_size = sizeof(IntelIOMMUState), .class_init = vtd_class_init, + .secure = true, }; static int vtd_attrs_to_index(IOMMUMemoryRegion *iommu_mr, MemTxAttrs attrs) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:40:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:40:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417246.1646188 (Exim 4.92) (envelope-from ) id 1x52Q9-0001ON-VM; Fri, 11 Sep 2026 14:40:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417246.1646188; Fri, 11 Sep 2026 14:40:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Q9-0001Nn-SV; Fri, 11 Sep 2026 14:40:05 +0000 Received: by outflank-mailman (input) for mailman id 1417246; Fri, 11 Sep 2026 14:40:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52Q7-0000zA-S2 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:40:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52Q7-008k9B-8f for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:40:03 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa412a5-2eae-0a2a0a5409dd-0a2a45089b94-24 for ; Fri, 11 Sep 2026 16:40:03 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41249-f659-0a2a45080019-aa0a817c6933-3 for ; Fri, 11 Sep 2026 16:38:02 +0200 Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-33-Woi66CdzNE63mR1L80XvTw-1; Fri, 11 Sep 2026 10:37:58 -0400 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2F99F195395E; Fri, 11 Sep 2026 14:37:33 +0000 (UTC) Received: from berrange.csb (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 42B0C3000229; Fri, 11 Sep 2026 14:37:31 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789137481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N4kE0kwvfDbuBRKymnLbUvEO8flRNgMjBGhpmSiGsh0=; b=GViE6yxWodZovarT0BzVz6itJh2R/zcnj5T+BQeKifIkI4NKDuMoLocTsBG+Sq01zfPc29 pMiymDxvP5oNHnVUaPiT+B+N0cnTo5uJCv1bHDtZlfzp0GwbEEI7rvmZqr4Lj1/hDS6RIu u4EKz1GkkJXdflLKDmPaUXW4FnXpltw= X-MC-Unique: Woi66CdzNE63mR1L80XvTw-1 X-Mimecast-MFC-AGG-ID: Woi66CdzNE63mR1L80XvTw_1789137476 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Subject: [PATCH 28/28] hw/i386: mark vmmouse / vmport as secure Date: Fri, 11 Sep 2026 15:36:27 +0100 Message-ID: <20260911143627.2743803-29-berrange@redhat.com> In-Reply-To: <20260911143627.2743803-1-berrange@redhat.com> References: <20260911143627.2743803-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: SSL7pQjdq08bxl8bdh_0qnjlOTOuy0vouEW6JJ0MLew_1789137476 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1789137483-CCB7187B-038AACDC/0/0 X-purgate-type: clean X-purgate-size: 1053 These paravirtualized devices are relevant to virtualization use cases. Signed-off-by: Daniel P. Berrangé --- hw/i386/vmmouse.c | 1 + hw/i386/vmport.c | 1 + 2 files changed, 2 insertions(+) diff --git a/hw/i386/vmmouse.c b/hw/i386/vmmouse.c index e289bce8e2..612e7f7d3b 100644 --- a/hw/i386/vmmouse.c +++ b/hw/i386/vmmouse.c @@ -390,6 +390,7 @@ static const TypeInfo vmmouse_info = { .parent = TYPE_ISA_DEVICE, .instance_size = sizeof(VMMouseState), .class_init = vmmouse_class_initfn, + .secure = true, }; static void vmmouse_register_types(void) diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c index 865e0e70db..24c4fb27a3 100644 --- a/hw/i386/vmport.c +++ b/hw/i386/vmport.c @@ -301,6 +301,7 @@ static const TypeInfo vmport_info = { .parent = TYPE_ISA_DEVICE, .instance_size = sizeof(VMPortState), .class_init = vmport_class_initfn, + .secure = true, }; static void vmport_register_types(void) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:50:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:50:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417319.1646198 (Exim 4.92) (envelope-from ) id 1x52aO-000516-QL; Fri, 11 Sep 2026 14:50:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417319.1646198; Fri, 11 Sep 2026 14:50:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52aO-00050z-Mv; Fri, 11 Sep 2026 14:50:40 +0000 Received: by outflank-mailman (input) for mailman id 1417319; Fri, 11 Sep 2026 14:50:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52aO-00050t-3R for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:50:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52aN-00EFQt-Ge for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:50:39 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41527-e002-0a2a0a5209dd-0a2a450484d2-26 for ; Fri, 11 Sep 2026 16:50:39 +0200 Received: from [52.101.85.28] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4153d-b57f-0a2a45040019-3465551c389a-3 for ; Fri, 11 Sep 2026 16:50:39 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DSVPR03MB989243.namprd03.prod.outlook.com (2603:10b6:8:3ab::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.15; Fri, 11 Sep 2026 14:50:35 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 14:50:35 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QXVxVMDDbqX9KqMKKhaog6sWsoSjiGCyhegcCvOGQMzTJGCSI/TjTWk14PxhxUOvhsu3fMG94Tr1fvhZpiCQscxRuvigWV2843ot1keMbaxXy5CMxQ1fyyNW8rZBo0r8uW4MqUrSIB1Qvyhw1wp7xu24uSNJ6FjeG5lz1SfgEWwFKRc0kdcqRJo32ynkis26xp1jD0ilAmlrD8FfkhGPsLY64nn68/0W90fYlNmqh6/WamLJa4cO5ZP9vLa4MtdzHPgCGNL19MoEWU0Ay2nxgP8//fVp8L/hXzNGdCaI8Wd8GLZjck50RSFElWQmExQlANkPEPcVplam02CSKjibqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/jpyJrm+Y4hPYLcisIDwSz+P8gThpnV6HSgDuGY4RPY=; b=nMbpu8aZP9VlGe2CgcWBgwYxO8LLpDM6QBMn88m8wWxqD0z/emSjjhAAHAT5HFlaaWPa2mvwbTH3NuaknHe0mC4dc0RLoidB3lAAWIn6MVVfcAc3EiKUV3xSiu0QBqxZaIaw8j3YL1tcN8Tjc87EOfDvxeoIZlgO5Hx287GUKaq+9BWibOgiDfvFEMv00oWetpFCF6ehv3IeNeA5qjl0gOu9y1N/Qcr9tgtnR9nR1TBNVVG5LLK/VZA5epehikjwCTJWWPYzuoxLhUz4d8xaBUDmL3g7zqSYinvGgbdajMwJG2nMN8WSBNgfaYh/OKhDjaeeoNTBDBXnmNjAJdCVZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/jpyJrm+Y4hPYLcisIDwSz+P8gThpnV6HSgDuGY4RPY=; b=HQpkF699L5NGEhzg3WeVMf2+N3jne3FHI/mmTP9CKJkkTPiI+sXJvGaksq5RhS0eMkvWpcHgvlDt/GKxkZ6XOqqpSpibE6oUb60Pp+uWu1toZAurdxmB17zX9gHleCaLy/V2jaLuC/jWHardjV5XCwKnhr+P5AI2ZpGOHQpO4FM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <52b94314-5291-4cf6-87fc-be3a54618b39@citrix.com> Date: Fri, 11 Sep 2026 15:50:31 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] nestedsvm: Fix multi-byte IO port intercept check To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie References: <20260911132315.1209497-1-ross.lagerwall@citrix.com> <10df3c15-990e-43db-8cc7-578f44a2bbfe@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <10df3c15-990e-43db-8cc7-578f44a2bbfe@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DU2PR04CA0019.eurprd04.prod.outlook.com (2603:10a6:10:3b::24) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|DSVPR03MB989243:EE_ X-MS-Office365-Filtering-Correlation-Id: 4cde4eb1-3f2b-4d49-20b6-08df1014095c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|4143699003|11063799006|56012099006|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: nRwcGuYpSK3CBVjEHbRmDUS0Pub1wYJcqzXs06C1wesV4WJQbMITZO8i2yGgiVoXbg3u/Tk9LVE6y9AEh0+6laLXxAToxj5Ewhf2J2yla774tJ3+DUWZ42gHEf5KhtJEbUxmaXzEiaW+KW6O8j6X+A06/BwtvNOTqjn2la15zN/LhM7lHj4xTzoYzS953kJ9gJOlKt7aZymZwD10p4eViL8p+ptwhGzOuMAAV1pXJ4ZLwRtYpw93RTSpcYJ43k8f7Dx+k6EBhh5UJnrR35L2EQrZr+ebjVquZhnZDAeaaevu2QVbtSO0BsB7h1YYrGGOBphezjTLLvr4FC9pPnrLfrLEg5igHhh2ZXD4rYWSthmGSPbkHWem0MLgTHSjqYvxH55qntQB2E0mVyd+OyUEVaruSrSNgxF/RpXwTB7/6E0LmiTPjwyonJ+sNSaK3td/96q1VCa68p+21oZMYzXwBcHdhj9wvxOdwYAR4CXmkKdckEJAaHHqjcam/XBoTSyNT/ue46oC6virLZMa6QF9RtfXF7yPvZ56JVrKUNOegPC4AkXp9zfZYVBIuA9XHb0x6BRIQp1UbALbvCrR8LIVbTuaddj2fcTT4xLtFwf2RYQr0s9SOH3By9zF1XqYAuCWefHEMomFxiHHCfNLqNVpgYVo6H1g4YniQlXtHJrmsIg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(4143699003)(11063799006)(56012099006)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NXd3aFhRNmtlZFRLcnRXdnNBeEZLeC9QaWZEZiszREpSR29ZNU81ZGU4NlB0?= =?utf-8?B?WkFablZ1ZzNDUmZCQTFHalFydFpLSmNjVkp3dDZuSTNLbk1rQmFRaW1OOVZY?= =?utf-8?B?Mm5MQXRxclZaUzlIekY5Mms4V2hKbDlFWUp0OFVOZWlSNE1RNlRIWW5XcVhx?= =?utf-8?B?K1RyVmRoQVNEQlExSkxkU1BaZXpaY1VDbndsVGdObW4vTkZzNE1vdmU3clJa?= =?utf-8?B?anR6M3V3L2VuQ2U4OWRkSVVtblVueStDT0xwakJwUW1PMEttTStCTFRIOTB2?= =?utf-8?B?TDEvSzhGcStDVDZESjB0MEFOK2hMSXE4TnRwY29sUDJiTldseWRyaGplRzRv?= =?utf-8?B?Y2gyRENMM3NxQS9SSU9iOFNFNHZEZndSQ1dMZExKNTg5cEIwdDFqMzlUVkdF?= =?utf-8?B?WU5jRlY1YVpxOWMwYXhwT2tDZHF1NzBOTXU4ZTBqbVQ0WG1CeUtQSUxPOTZ1?= =?utf-8?B?eTlHcEZ3UElVdzV2T0ZkcFJhekNsNjVwWEVhaFlKTys5R3FaZ2lzZ2lPaTlV?= =?utf-8?B?S3dnR2gzaVk5clpScDZDME8yVUFNMGYrd0o2ejR4ZlJYenJ1U05DM1RlREtG?= =?utf-8?B?SFpwOEd4MDJvSU5pc2xiWktwZTNlNFh4K3NqWnd0SnFYcHIyWmlsNGRIcTRD?= =?utf-8?B?WE5CR3VYUCtCZGswbDI0RUZKQ1VFams1YzllckxXcHdqMDFGeUtYZVg3MSt6?= =?utf-8?B?UVBJK2c4VytwWTRidmxYYzViK3BYZFR0UFd5K3lXNHlORkJ0TFVDRnFtUldX?= =?utf-8?B?YTB1WGVlQmw0dzdQQTgzTzdTeHN0UVZCTDkxUGlScnlIS1NlcHpOUEFPcWxE?= =?utf-8?B?TkVXK1J5UHBzVHRvTWtXT3NKeGVSZTg0Zk1mUkxqeFFKaU9mR1pPTThpOFNZ?= =?utf-8?B?RSsxOE5OeXBTY0dIVlpDWjk1VkNaZ1Vjbm1WU3kzNXZ1aml6cDlqekkwa25v?= =?utf-8?B?bDRGQnlLa09PL0xBZ3gwRkFTMldpSitJTktxTFRXMXlHeE5NTkZRaC91Wmxy?= =?utf-8?B?ZnBqOFBjNXVzSFBQL0FrQy9abjVXWFoxUmFES2VITldEOGdFMytWRzNrTkhX?= =?utf-8?B?UE1LMG1KWHViSHE0dmR2dEFvV2ZSbmlrU29zczU0eGtaL0s2N0lHLzlFTVFY?= =?utf-8?B?WFYxekQ4N2FnSlQ4UElOd2hGS2JrMXZKazlmaUhQR21WSnlxSFp0UkRrdlNu?= =?utf-8?B?VVlWc0hiUGlaazlHV0lldzdmQVkyWlVBckg2MklQRFgwb0plMllFT0pOa09C?= =?utf-8?B?V1FXTk1acjJFQVB1STdTbEJERUJ4YXdiZHMwQTl2ZEpnVzlxd1NIeVFmQjNK?= =?utf-8?B?WFYvck1WNE9YTUJCTkpEMHJXcTM0T3cyd1Z1akRXTE80bS80U3RUcHErejVy?= =?utf-8?B?ZmdnWWt3aFh4VFZvaURtbk5laEVxUlVwU05Za2NCSmtkQUNXT2MrcEcvc3RM?= =?utf-8?B?cTBzVUFDdEFlMkphd0ZlMWdEblJqQ3RucGFFMGhVUHhtQVltZFQ0VTYxdHFZ?= =?utf-8?B?RlVyeW9xa2dGZS9ycWYydDNFUU9WSjAvNmNvbHA2ZGtwc3Rsa1lHb3AzNzdL?= =?utf-8?B?dTk3THpmUTljUCt2b1l5VTFIMW0xRFhkMzlXdmpHeU5lQzlUUmZMcjNZVHBL?= =?utf-8?B?L1FpaVdIRWtvL0pRU2hWT3RGQkY4MDBoMmNicmd5U0VVanNuNENHNkRLSFdS?= =?utf-8?B?Wk92d0d3WjNLOVJPKytLenpKdk54RkNoQ1FDbDIyNEdWZXF3QWJUTnM5R2s0?= =?utf-8?B?SWVvYTlkN256UGxBS1J5cXBRczdudEcwUnJVa25Xc0traTk2dHduTHBZaVVH?= =?utf-8?B?alNxQXJIUG9SZFFYU1ZUdU5DdXFvcXVRajZsZHA1Yk5ETGJrOG1zSlo5TTQ2?= =?utf-8?B?cGZvNU80SE5HWkxWR0lIMEZ0VWdJTHdueGlkeEd6dGpJaE5kVVltVXVIOGh1?= =?utf-8?B?bG03UHF3VllmY3pSRXVxcFB3Y2NyY3AxZy9iMk1rMmVDa00vdXlXcnVqUE1O?= =?utf-8?B?RUN5bWFxZ1hRT1J3OGRZRjZDL0VJdFEyY3p1bkNsRXl5bXU3aGZuWWJyZWo1?= =?utf-8?B?Z2x3d2ZERzRRajdkVktBcTR6YkVueGo2OWNDTWwzUmUwcjl5REJDRGhXaGtL?= =?utf-8?B?ZTMwNHNMcEE4eklVNXJkT0U4OExHWGgvdlRJQ3R3R01MbEx3U0h6bzJWNGdI?= =?utf-8?B?K1ludDNMNG1HcGRZNURrSGE4RENiWHUxMnIrbHIzeldCbVZtc1c5TUVsNTNQ?= =?utf-8?B?L2loaWNzWkFhOTBLY0Jxai9ZbWhtekNYMGwrbjdOazlxdDZnYnYvaXk3Nktq?= =?utf-8?B?bUE4ZnhtSVRiR0FHTGZ3SVVTYzdRZGJRTlI3UTNWVTZiMkJsbWFkaGZtV2pp?= =?utf-8?Q?YzBgLscwKfIKEBT0=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4cde4eb1-3f2b-4d49-20b6-08df1014095c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 14:50:35.3891 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Ppz7fqy8XYfvAbyPDNEcEoB1RAj8/SnfgfjjNWyQUg76qfew2LvbZWYnvN7JYBftmWOYJRJif6w9xx5puBTG4bp1SKG7Uh4Axsy3bhw8L3U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR03MB989243 X-purgate-ID: tlsNG-ebf023/1789138239-520D5B50-9CD7A948/0/0 X-purgate-type: clean X-purgate-size: 2627 On 9/11/26 2:36 PM, Andrew Cooper wrote: > On 11/09/2026 2:23 pm, Ross Lagerwall wrote: >> For multi-byte IO port accesses, the APM says that SVM should intercept >> if any of the corresponding permission bits are set. However, the code >> has this backwards and only intercepts if all the permission bits are >> set. Fix this and at the same time, make things safer by handling >> mapping failures as intercepted. Also rename the 'enabled' variable to >> make it clearer what it does. >> >> This affects Hyper-V since it does not generally set all the permission >> bits of the multi-byte ports it allows its root partition to access. >> This results in an L2 root partition that cannot do PCI config space >> accesses and therefore cannot access its NVMe disk to continue booting. >> >> Signed-off-by: Ross Lagerwall > > The reason I asked about 0xcf9 is because it's the one-byte PCH reset > register, which hides fully inside the normal 4 bytes at 0xcf8 for CFG > accesses. > > Despite outward appearances, the x86 IO space is not one uniform space. > It's 3 orthogonal space (1,2 and 4-byte accesses) where the target > device gets to choose whether muti-byte values alias in the spaces, or > are entirely disjoint. > > For the HyperV root partition specifically, I'd expect 0xcf9 to be > unintercepted so as not to interfere with the final steps of > shutdown/reboot from the main kernel. > > The patch looks ok, but I think the second paragraph needs a bit more > explaining. Are we saying that because 0xcf9 was permitted, we allowed > 4b@0xcf8 to be permitted, changing L1's CFG index rather than changing > L2's CFG index, causing the subsequent 0xcfc access to produce garbage? > Yes. The incorrect trace shows: L2 write 4b@0xcf8, permitted so it updates the L1 CFG index L2 read 2b@0xcfc, VMEXITs to L1 L1 write 4b@0xcf8, updates the L1 CFG index to the wrong value (since it didn't see the first L2 write) L1 read 2b@0xcf8, reads the incorrect value from the device model in L0 How about this for the second paragraph? This affects Hyper-V which for the root partition intercepts 0xcf8 and 0xcfc-0xcff. L2 issues 4 byte CFG index writes to 0xcf8 which are incorrectly permitted and update the L1 CFG index. The subsequent L2 CFG data read at 0xcfc is intercepted by L1, then resubmitted as a CFG index write followed by CFG data read to L0. Since L1 doesn't see the CFG index write by L2, it uses the wrong index and gets garbage back, ultimately leading to a failure to boot since it cannot access its NVMe disk. Ross From xen-devel-bounces@lists.xenproject.org Fri Sep 11 14:56:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 14:56:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417333.1646207 (Exim 4.92) (envelope-from ) id 1x52g9-0006Vs-D9; Fri, 11 Sep 2026 14:56:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417333.1646207; Fri, 11 Sep 2026 14:56:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52g9-0006Vl-9i; Fri, 11 Sep 2026 14:56:37 +0000 Received: by outflank-mailman (input) for mailman id 1417333; Fri, 11 Sep 2026 14:56:36 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52g8-0006Vf-O2 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 14:56:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52g7-00BpzR-Fp for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:56:35 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41686-2eae-0a2a0a5409dd-0a2a45098eb6-26 for ; Fri, 11 Sep 2026 16:56:35 +0200 Received: from [74.125.224.140] (helo=mail-yx2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa416a2-be1a-0a2a45090019-4a7de08ced15-3 for ; Fri, 11 Sep 2026 16:56:35 +0200 Received: by mail-yx2-f12.google.com with SMTP id 956f58d0204a3-66e50968489so757707d50.0 for ; Fri, 11 Sep 2026 07:56:34 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=linaro.org header.i="@linaro.org" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1789138594; cv=none; d=google.com; s=arc-20260327; b=iDTm61XoKeTzdArQy05fylQmVfl/6ANV46XovzGoXIjhgv6O/brRVzun9xgZ5kDsXD SvPTJFGa9NxPjz2AfpYclZi8P2SX3H4zWMyYx3VxuXPPL5Kyf9RHlfcyvbBoaIM8WV93 hu96pZUSqcJxn6EE1UZRw5BRQnkizHstxP1ie2dzT+IcMcvKYit2/nh8HBT02gJKt2fH JiQzqf0T1p7ojLoLN7bd513PwUz0cGHvoJXsjD7B4+VJlWVaoDuMs6Qbah9LzeeKvLmI PmIFOs0vVNPKVH+ULVBVjGc2lUaasRaEsWrqcoQDMk8yWtnAjWqCAQvtqsMyZcXjgmd0 h0oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=5t14kjtkJw6ulLvN85ahqL+1Cufqnue3EYxXJNtvEUE=; fh=lNAFjZRvc7d+Hys6mAVRVcmyXKosSTF0IjpuRL0sAdI=; b=VlUTiubbuBz0ITM3YiNKfl59zupOEjUGM76F+0qEOhR/MgKXy02+29z4Ywr/+d+VmG wzmHM0mXOrtPiNtszv9JsNq3gfEA62s+2ZlDkCy106yJLwtuWpFJldgnHrSU4OLQi2H2 PmM6omDa3XfV0nxHyrZaltJ416RNyxztkApvt7ARPHCYL0x2i/zt+kQo9tSBzkphkR3z upvjXZMnxlPWl4qsyW68aZ6U5C7NGsRaYbAYWF2uXTpbqVlPnNkKuwmgYsdDWi99yH37 QknvMlMSk33L7b4a6n+j0T/rbJ5FujA1Zh/ztqkQo8z/iO0PdpcdEAmWQmObD7OPhbRL CBag==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1789138594; x=1789743394; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=5t14kjtkJw6ulLvN85ahqL+1Cufqnue3EYxXJNtvEUE=; b=BDdU+KEcpg2MYnJDIasESD182A8E73lqBuJ21GUS/9qgoOIkcpzGqbx3W6fR9GRwKG 2RoXf4/RfpyWlzARKw5j+7WZHBskc/wmfvz4D2bs2iWl4i9Ila/okikiMZdQvxL+Bwk7 x4ktOr1/4mXsQeBX7yNBa1y5VpBrwpZ9nsmD9hxXDVe4IrUfsox+Y7JrcmcpDUhGNdtM BnHL/arVz0pqWmjKL7oxuJ4y4YeRk8QKpBj96mGcqQ0oCIIeqh8Rocy7AOHzBd6I8Fhw 1KLJlX0BhEswJNe7wp41snrPL/MbiGVZVfCn1TiKDkUoRAg5cDvS2qGU6+S7qFSw20zS Q3+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789138594; x=1789743394; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5t14kjtkJw6ulLvN85ahqL+1Cufqnue3EYxXJNtvEUE=; b=WEUwibUx4DS2IHouCM7nTVEtPt2bhrFH8JE0XeaCKf03gk3u/u5IVCcOQYB76D4W5k qujV1uAZEukkdW3GSUx/I/4qEWKIjaBt7TQ4H4FOFCZlYmh/i6Hgep+pvZMSslzxOvOK bTa8NyW16vxjnirlAPKtMo1lD40aKIXhrhshT29i72xWAYZ8OslnCGFgmejHiWG3SYrY qnqhzLD9X1GBd1umGQQc/erA8vHiT6Rmk/GdiqZn8KYgEox3Jjw321mtZAtvs0JSOuns OfsYTdz5f08uVOHXLbg/HsaSg6yDeeJAITuS74b5/8Re/dVUIONpiWuyr+yQ1VvgnRTk TUJQ== X-Forwarded-Encrypted: i=1; AKwUvBxJptW8CXX5fULQDdbzzUkspHbqzxT9Oi+Q6V5p25bt1RQ455YLRgOvnpkIETQHtzuxb2xYq/Baf1M=@lists.xenproject.org X-Gm-Message-State: AFuF++mE4rWAgif75DHxdSAUBS6/EztEx3Mtqadhk8NdLsDl+tVquZHm GP+Zhk/4Vt4gk5eueiTBRiy5DB98+rtAuVbLNaU8jrxj4ECJDHGpBUZm4eg3aq6C7Bkr5YC71gX 5BylQ9Fro9SIEyRe/pdkD3xJMyf1q8kzCzst4+DHXiQ== X-Gm-Gg: AYBFou0o9QbmkyaH0Tr7QqfOaa/9+x5aPsVjcs+U/JP8Tau2d5PynlbQMAjAv6WqljU Ga5KXvFdkMLewKcUYbH+H3Q02l/2m61i4yYi6T9xvZ2yvCgjQOt1j/9d4AZbZjahZ/iaRzzHEBD j6b9WJI7/ikddCT3+PaKcshFlsIHEJPhROPfc8wzxDIpeCX6d5mUntI74cGz6AjZbPNhjAXq80P qTrKTzMps2NgDEipY77ztfFqIiTSvAgop+B/4rtb6TOOJ8ZQZRoSD6e4RQeXh/T3JI+0Cq1Rn6f UkOU0gqz4ymuYnTNFKeloe3PaxHS7IusamLAAAmDZBqy62f5IWdZ47hdsr9WOJ9NIhKV8QMp2nE vt5EqBO53b/hO3J22OeAdS0Tc4asYJ+9xH5HqEZU= X-Received: by 2002:a05:690e:16a0:b0:66d:2cd9:91d with SMTP id 956f58d0204a3-67124752923mr1952365d50.50.1789138593729; Fri, 11 Sep 2026 07:56:33 -0700 (PDT) MIME-Version: 1.0 References: <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> In-Reply-To: From: Peter Maydell Date: Fri, 11 Sep 2026 15:56:22 +0100 X-Gm-Features: AcwNN1WWJyP_KhXTQufc5rB9sU8U7M0jxAg592d46t3fVacxoF6HjMSZN-YPQQQ Message-ID: Subject: Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc To: David Woodhouse Cc: mark.syms@citrix.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org, edgar.iglesias@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1789138595-BFED6034-84260997/0/0 X-purgate-type: clean X-purgate-size: 1949 On Fri, 11 Sept 2026 at 15:39, David Woodhouse wrote: > I wasn't *actually* setting out to comment on the AI policy today =E2=80= =94 in > fact I didn't really have a strong opinion on it. I spend enough of my > life tilting at windmills *intentionally*; this wasn't meant to be one > of them. > > Letting the tool reply in its own voice and pretending I was held > hostage was mostly meant as a joke, as *well* as being the only way I > was going to look at that bug today (it would have taken me a *long* > time to do all that testing of old and new failure modes, finding the > net device path that *does* reproduce it locally, fixing the other > problem with that, and finally confirming that it all works). Even our current strict AI policy is fine with using them as tools to help in debugging, testing, and so on. What I am complaining about is not that you did that, but that you posted an enormous long apparently unedited pile of output from the LLM, rather than using it to do the work and then posting your conclusions. That is asking readers of the thread to do a lot of work for you (i.e. wading through the huge email to figure out whether the LLM output is right, wrong or irrelevant). > But our policies should be based on actual data and the holistic > outcomes they achieve, and this is just data which we can take into > account on one side of the balance, even if the other side remains more > compelling. Yes. I view that email as pretty strong data for 'even a policy shift which says "we're OK with accepting some kinds of AI generated code" should still be pretty strong on "text intended for humans to read (docs, commit messages, mailing list posts, etc) should be written by humans"'. I think that review commentary on Paolo's RFC about a less strict policy tended to be in that direction, so I don't think I'm completely out on a limb here. thanks -- PMM From xen-devel-bounces@lists.xenproject.org Fri Sep 11 15:02:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 15:02:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417341.1646215 (Exim 4.92) (envelope-from ) id 1x52lH-0000WI-Ui; Fri, 11 Sep 2026 15:01:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417341.1646215; Fri, 11 Sep 2026 15:01:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52lH-0000WB-RK; Fri, 11 Sep 2026 15:01:55 +0000 Received: by outflank-mailman (input) for mailman id 1417341; Fri, 11 Sep 2026 15:01:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52lG-0000Ux-MA for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:01:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52lG-001hW8-32 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:01:54 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa417de-8faa-0a2a0a5109dd-0a2a450c8fe6-14 for ; Fri, 11 Sep 2026 17:01:54 +0200 Received: from [52.101.193.34] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa417df-f479-0a2a450c0019-3465c1228ee8-3 for ; Fri, 11 Sep 2026 17:01:53 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5128.namprd03.prod.outlook.com (2603:10b6:a03:1f2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 11 Sep 2026 15:01:46 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 15:01:46 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gaUsaEtX+QozJNAWpfHUE1iZmVXU51nG9jPrpr2G0K4xlVIpbzQlIHm+EfoH3VDfFzgdF5jcTy2tpwwLDzKW0zKY4o8PTJQfzxRnQFbHYAotVEXfD45AKIXf18lxjV/XS0fXj3i5NpNO5msVwSnC4pnpZ5v6dQR+uHj2wW5vfgORZ4TWxQFnU2ZC02okMcPWEPkzCXnkInM2LGZI7VFDHeNhr8d3jP23T9hH8rhUFcaYEY3UiVWs7CQzzzEl8jDgzKnrLZSOrkt3H5YdTPcGFDW3ClCSTknScoTgCNYeXMjIAwd2h+2bkyoxPho8ClRYIgtguRISbLOWlWkD2Q4VnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=shqd0gjZZOuqfj3ISNzbhpqXj29M0D/xD0iUQMgyx/Y=; b=R43qw5UetxdiLa1B6PfKiH6Emc2YHHCtYgSpW5fX7n2OK/dzFj3x+wzMbC+2drmyBgMjCbV6tYL4GKC4hSsOyrTV41bEi1HVV2yY2oDadPG8KxwerG/kAvk3trewS7mvHrtv21Fj2YT5sXQVoH9u5iIA67Kgpf70vNFaIwbhrRq1z5uQJSB/or/b3umaWEK5qg4Q1em9Kie+c8tR5AI42T7pxR+dkGiv6gEcWKWTgxWbtZemFB738vZSMO0ptchlCm5csUA1S6Nnt5/tbAaZhdqzuFIhYv2lHs+51vn64zsJoWBRvZPaFndYPFqihrp1AK3GvDd+8AuoqlJv+OouAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=shqd0gjZZOuqfj3ISNzbhpqXj29M0D/xD0iUQMgyx/Y=; b=btufewevl5NcJ3RXuOEvEEwaoTAoaeoz3f4wWUq57xMf/7xv1qn8fJ/s30yQ+FtBQyfGrkN37jimZg/fV5TbV8aHeOl9u94kyiyIqOpnLqmr0Bke7veoECxKwDUoqh9cXGoqS1qfoiyuTh76qDzK8Didcn8FbAdwlc5ORmffIJ8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <8ad67efb-6591-4b8a-b79f-8b53aacc5e84@citrix.com> Date: Fri, 11 Sep 2026 16:01:43 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, teddy.astie@vates.tech Subject: Re: [PATCH v2 2/7] x86: Remove return value from UPDATE_ENTRY To: Kevin Lampis , xen-devel@lists.xenproject.org References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-3-kevin.lampis@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260910203113.462943-3-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0164.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:312::13) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY5PR03MB5128:EE_ X-MS-Office365-Filtering-Correlation-Id: d6f844b3-6728-4987-2f85-08df10159953 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|4143699003|10067099003|22082099003|18002099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: VAjAgpX3CeZXhPQdD7g/G3AFCCNDmZbYL2xaFCBi5QtJRBXhFHK2Y2nXQLsaw2FfuSvge23rdTUH4VaPyL91IZd9RL/yW49G2p8RXFkoC8o8fpRSUbLKlWDjCO3YEsxp4Wi3Arayws/ozO4yB0zg7oooSEuWul5KgHa1ZW9Gp1t0vBH+6SWerUUIG5Iym20svFE7L976o5J3237CzYfZJVgjc+q4TAh4Ux8hO1wOXt8vDou3Sor73JphYzMKpA7Yha7Iqvdiew2N03x8zz4Mz7+S0a0D+m17j4+l8YjMZag/3KrHSX4VENe6SSF8kSlHmfDm8/9eyG0cEgnrqD9SXj3TcwD0rQSXekwvGVb7G4DO5kSzBSs1vEe7M8R2M2swedcH8hipGFBpayu09Z3pzR2kfJH6qdRL5eTS/Mnv7SRmazOfilZBcZ9LiY3/fUhd2ZAqHboQYGyt3V6Xb2LUCvpID8swwpVUO76WJ7Pzep05dOmFrZ1870UD9XG5HTNnxWmTLf77aRuVbHLiGrn3/MDoa5u3HB6kpt1Nxx1b26beviPImRjfxV/nlfyJqF6LZBmHxXaAxouW26g84HZH1R7qaUb7jIHlwQaxZ7EQC/uQDo4FXaIEOCawHZUrQYV1yZ+dk8GQva/9CtpoUK5CVfngSJC8RI1aKCgI03XX/8o= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(1800799024)(376014)(4143699003)(10067099003)(22082099003)(18002099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MjdiSllzMjB4K0FRaHNVNHorTXpqT1FHemJCWUFrVUxkbzJxVEhqNkVham8z?= =?utf-8?B?WFBxZXVUOUZCWlZDL1BkaWlERXRBS1cyNXo3ZzRuWmhpOGVpYk1WaVhXelZa?= =?utf-8?B?cTZiUFhYRHY5ZzJKeG51NWVYTE5TRXQvUVlMY3FKekNkQldWYVF1WTBIMVRw?= =?utf-8?B?QUJ1clIwUW0xRkhiWS9UNXZ3SStwMjFBNSs2OVRodVFxQ3B6RHpKUHVTeVd1?= =?utf-8?B?MGdDRmJ0cUI5K0FRaW1zWnVhR3lMT3E0Rk1QeHRQTWx3dXZQT25hUHJvRTJF?= =?utf-8?B?b2Z0WW0wSk16ZEsxTmxEbjZPdkZObkV5cVQvRFBUZXRqa09pSEQ4NWkrQkN0?= =?utf-8?B?eVdxMDNKMWJEbzd5aVlscCtMNVArdFdWQ09aSkZ4RllPUTgyYUw1bGZpVUxh?= =?utf-8?B?a2ZsR0JmcmE0TWxRa1BrNE9IYkYxTlZIMGt6dWU4UFJWdzF1eGdnYjdvTnVu?= =?utf-8?B?OWRpMTJVdXpqNlhyYy90c1hKOWJiWW0vY0RKNWxOcEZncTM3Vk5yR0laU0Ji?= =?utf-8?B?aWxOemgzRGp2TGQ2QlR2UTNLdEV6RXozN2FRbkJRcDIxR2h0VmFrOTY3anU5?= =?utf-8?B?YkxsRlpGNUpqVmg3d0Z4ajB5MTFVbjc5R1FYY2QzazF1anhjUmcrWnFQY2VE?= =?utf-8?B?TWZpVkU1cnVCOU1GQ2RweWs3M2MwMmhDTjBXb1I4Y0RBdE16NWlaSTRBdmt3?= =?utf-8?B?VG9JNE91TDE5TmViVjFuRWxHaWZyazNZb2RGWVowVk5DNjJnUEZxUkJYS2Vm?= =?utf-8?B?bk5JZG94TnBkNktQMURVQjJPenlYTHgveFMrU2RZdTY5Y3g3TmZPdGZvcmxF?= =?utf-8?B?YUpHUUJrRWxRNjYvZkJOVSt0bWd2QU9tb1REd3EvNTBENld0dFd5bjNoNEJF?= =?utf-8?B?REZMV213K0pqcUxXenpheCthekZ4ekpGSER1eUZneHdCeGc3aXF2RmpaSlFi?= =?utf-8?B?aFJvVzVDM3FpQWJ0RGJVSnhNZXhXOGxqK0hpak4vNDdUTmRQUlQ4cHVMaEZX?= =?utf-8?B?bzRqYmVsMlg5ZXZoWjA4Z1N4MEZkUkM5L0JFeE43L1luU2YvRWJxSWpuUEo2?= =?utf-8?B?cjNBaE9mOEVZYVFCM2UrUUdQeDJIUGVKVGxWdFZkTElodzhJbDJyY1dWNTcw?= =?utf-8?B?Smx1L2RaNTdIZmlZTWZiMloraWhHNjA5R3ltcUJjaVloZUQ4RVVrcHVGS0NY?= =?utf-8?B?aVhkU1Jkb0JZQ2hkQ2I1QUhjZDlrK1doVUV3azhEM3RuTTVGcGVwU1pQb29L?= =?utf-8?B?b1lNQmVlYmhZZForeFk2TVJKM3RwOHVtSjNIcG9aSXh5Z1MxazBHbmZZRHNP?= =?utf-8?B?aUVqL09sUGZBR1lsNEFKTWliM0VkSDVnSzhJSkFRc0VmeFp2ZHQvV3F6akhl?= =?utf-8?B?ZVhMa0E3QnZCaTBDUGdNOEdwZ0tkbGxkdEtpVVgwUkRFc1ZvdkM2cWpqdjkx?= =?utf-8?B?MUNKL3dtaGJTaEQ2U1Ywb1Ixb1VQVXJuZit2ODBzWE9IZ0ZZTDZsa2MxRjFw?= =?utf-8?B?QWhKaHAwYS9UTld1bURUTkdWZE0wdHQwMFZYUE0yS3Fob05yY3R5Z0hmWVdk?= =?utf-8?B?UVZZYlExTGx6MHJJR2dZaklIRjVqbjNPelM0SGR0akFBSVlSRjFtbW5JMVdi?= =?utf-8?B?N2hlOU8ra3kyZVNaRFN2ejlwUGxxeUxaUGZyS3c2NEJLSGwvaGJxbUFBT3FH?= =?utf-8?B?ZEc0REttaEtzbmJ3eTd5QnlPOThSRG5CQUdJL2xYbkZqZ04zLy9wdy9nRVVy?= =?utf-8?B?eEZ0RE1MZExDZnovSXdqUyt6NFQwR0dQVzN3bjJRWEJydzkyRUlUYTJZdGho?= =?utf-8?B?aTVwVFhBdWZhbFJXN1JlemF1aW9TZStheWw1SWpSajNwZEd1aVQxemFINjBt?= =?utf-8?B?aEJGdVJEYUJ1bElPcnVRaXZpbE41OW5xRE5RMk9ZbEhYZzRPREpTZE9kT3Q4?= =?utf-8?B?SG94NVpIUWxQMlU2WWhaSkg0S01TZm5PNThYam5WdUVCNTFEcG1XK2pCdWpH?= =?utf-8?B?Y2pmd3dXWmdiK0dZNGdRbUhpK0QrU3J1NDY4RGxCQzZtVGRYclpkdDVSMzlu?= =?utf-8?B?enJtRXUyNHlLN1lEcEVCTWx2NjJyNk5mVXo1ZUo0cSsyY1duajhoS2tCMFpE?= =?utf-8?B?U2ROVEJxTzduRlNRMGtmNStKNmI2UGdEV2VGdkgxT2JNakxTM3FhdTh2ZGhF?= =?utf-8?B?ZkxIZll5YjV2K01aVjZ4czNZSkJGTXdiMGhvbkUrY052TjNkLzJZVjlkeFhk?= =?utf-8?B?Z2lHU3pDUFFqV3NBUnJuWHU0K1MveFVBbS95ZGNIQ3M1QXZra0Vqb3lNdW9y?= =?utf-8?B?WHludnpianR4dDNuMmhIblZDOW9mSUVoUUgvUCtnd0t3L3VCeW9VSDlFQmVw?= =?utf-8?Q?UnhB+1eFrqMY+Adg=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6f844b3-6728-4987-2f85-08df10159953 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 15:01:46.3819 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0+sLPRE/A5kyMHT1zEvDpToy7hqSyIpd/B56E1z/dLSqqZKJdzYfompfxFRpjSPZRxloZHq4iI/dvJbjMJIqWFk4xndxiNmyuT3k9eyua1w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5128 X-purgate-ID: tlsNG-d25034/1789138914-768DDA5B-1667BD90/0/0 X-purgate-type: clean X-purgate-size: 1399 On 10/09/2026 9:31 pm, Kevin Lampis wrote: > UPDATE_ENTRY/update_intpte always returns true since 1bc30c076a7f > "x86/mm: {paging, sh}_{cmpxchg, write}_guest_entry() cannot fault" > > Signed-off-by: Kevin Lampis > --- > Changes in v2: > - New patch > --- > xen/arch/x86/mm.c | 74 +++++++++------------------------ > xen/arch/x86/pv/grant_table.c | 53 +++++++++++------------ > xen/arch/x86/pv/mm.h | 6 +-- > xen/arch/x86/pv/ro-page-fault.c | 3 +- > 4 files changed, 46 insertions(+), 90 deletions(-) Interestingly, despite being a static line, the optimiser can't make this simplification all on it's own. Bloat-o-meter reports:     add/remove: 0/0 grow/shrink: 3/1 up/down: 6/-32 (-26)     Function                                     old     new   delta     symbols_offsets                            53584   53588      +4     symbols_names                             135144  135145      +1     mod_l1_entry                                1872    1873      +1     do_mmu_update                               5604    5572     -32 I've checked several times now, and I can't see anything which constitutes a logical change here. Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Sep 11 15:13:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 15:13:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417352.1646225 (Exim 4.92) (envelope-from ) id 1x52vv-000763-Vr; Fri, 11 Sep 2026 15:12:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417352.1646225; Fri, 11 Sep 2026 15:12:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52vv-00075w-Ry; Fri, 11 Sep 2026 15:12:55 +0000 Received: by outflank-mailman (input) for mailman id 1417352; Fri, 11 Sep 2026 15:12:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52vu-000727-K4 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:12:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52vt-006AOs-LB for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:12:53 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41a5b-2eae-0a2a0a5409dd-0a2a450bcef6-32 for ; Fri, 11 Sep 2026 17:12:53 +0200 Received: from [40.93.195.59] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41a73-b7e8-0a2a450b0019-285dc33b12bb-3 for ; Fri, 11 Sep 2026 17:12:52 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW4PR03MB6924.namprd03.prod.outlook.com (2603:10b6:303:1bb::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.6; Fri, 11 Sep 2026 15:12:46 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 15:12:46 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sLvWXGi71qYmcOvGtqC6WtO6QYYV9Hlfou8NQS9DjLts+EJPpx6BZzKHdIlZGMNbXrFmFBjErSCbxmLH9pkCQkZVHeTNO/qWkyqVk4Axw97wwspUX3Uq7jlGn1itiTFNbI1UbmTPN8qtySGEZwQKb5m3jHbznDk6qQrsA4XeJbCzjAWg3tW21qXzInGxwkn6mXXcECxEHY1bIqLH1vgSzPfpcPy8nf1FsNf7Oj2l7lSN1s2MwIF2WCql8C200g8YSzukjCnpeiLAiPnB7G1jrT/JlDgzCHFd8OfwA6g+z8JJW/F/7g3qmQa5jA8ifC0IsSQxr/BlT+9fMD7ggCo9cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ySR8o1TKI8v10yWCw67hEJPO+S7CIf5hx7qyuznbsAg=; b=hkt6uGCKNCAtNGLymcQomnlWgTB3N1o5ez9o6hwRn0Xrcayv4i/mv/OhVfTwUQoH+KgStWVtlTq6TwDeb6LuPzOxrjq7vrvCn4OzhhxIAZMeHKtwcUpqi35VDpfnEDX60Q/Qo65l/NWiCLd4yLx0eIuS+3PVbiyfAPjBaNyG2dQaYgFRoG+N8yA5bNod4a1A4wBGVitp7t82+eJ5ZNqgq+BCKuHf2KTcFJEafxaU/9de3EmwHIQ4Aqj0TvtBI+IozN2ROXGn4WnrRKW8CwiBKGdfyPbl23NfpXLCpB7BJjkRmLNcXhpVokZuBVU4r3mYmymOoYlJ/jX6ubdmv5qEBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ySR8o1TKI8v10yWCw67hEJPO+S7CIf5hx7qyuznbsAg=; b=K17iLX0cnE3MUCPTK0JblcnOIvMQ8Lno15eIPEfSaNigifg0Y4sx7DUHYuaQiHHKyWE9Dn8ixvtjPLs9N+YMo4W5rp1dSKVIAeSRbJ/bYXU9ILKOjXXoLTi/aAfmp/cW5wLQudCpzI2hb68lFpwdpFEHfwbkHPLdYjTlsvcob9A= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <9da3d6e7-f4db-43c7-b13d-2bf3830caef5@citrix.com> Date: Fri, 11 Sep 2026 16:12:43 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com Subject: Re: [PATCH v2 5/7] x86: extend do_mmu_update() to support returning the old PTE value To: Teddy Astie , Kevin Lampis , xen-devel@lists.xenproject.org References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-6-kevin.lampis@citrix.com> <1789129949.8631fc262581453bbf619ec5b2062170.1a09074801c000c4f3@vates.tech> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <1789129949.8631fc262581453bbf619ec5b2062170.1a09074801c000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P123CA0043.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:2fe::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MW4PR03MB6924:EE_ X-MS-Office365-Filtering-Correlation-Id: 70ec5732-84f7-4e55-35d0-08df1017229b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|56012099006|11063799006|4143699003|3023799007|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: IhqXEsI7ezP9yPj3d12qXu9K7+U3n302tA/pOdIFn6NtV3pO4/zNtTfVghABxoOLVeOkVWDC5zdNtPPZ0f5C1zmb72T2dNW5ag53PlbaCRJJ3bOW7yhsUlbTXXywIeXz291jImRqqg0nc/MU0r1jlkFgEp44lBQ/XKVqpgROKAuVBlgGWcGa9AzsNPaptBKtICql4QkbWYrTEv8QoKsHd8YugDou8Z+BD7jDki5dJ53acrbX0Yt9SUhgvtiEs/nOYbV6OYMm8p3qeS+ZjUVqulm5uxyT0G40Wxe5UnLbRY8oxS0tfrUzH/OAQgYyWDBAlJkNRIyZqcb2u4hFMHds3OHOLQUrQ30jmusbk/Ctaar66vkYpPo4C/00yz6qrGK01o/QwFS2WTYCwJGnN2lIIiS+TS/mnbtRVzq3o15eNcD4pWtECeu1dfSStKUmdd3ZEzO2oedOxvvsHF3vVseQTMPaEJjy6Gc6DXR5XqlyROeGMv7zGSCGsSPNDaYNtGeFCHZNyZtln0OxGDdeTJHSJfTvz+C+Bz7xzbzLIcKPE6zrIc8B10v88Dg2ztjbWTdY0aqVNtAvLGLCZ3UoUk2MTZahJBfvpVWFixBnOktRsBChJpe1gWeBor6IbdZdZUwVCVL0Qn+9cig378Sy7zIEwqaN8IaTXD/QLATeWqTsUvo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(56012099006)(11063799006)(4143699003)(3023799007)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UXNDMU5GakRvRkRtR3BaV0pTYnpLRE95VE9Dci9nTmRqM1hFVFdFUzBBUHBP?= =?utf-8?B?djAwYjVTMlRCcXQ2bXExRlVYZjlRb1U2UDZhZU4xT012ek92bldnMVhGb2hW?= =?utf-8?B?ank3WjFicGZiMmtFS2JFNXBHYjUxU0NQZVRDZEdoTUVaazNRQVJOdUtxOGRh?= =?utf-8?B?QTBxNzcxUmxjVjk5bzYwS3lTOFVRUEtlY0NzVzg1VFhTM2FpR3VQcGtUcWt1?= =?utf-8?B?alNweThDOXdxY09OUDc2ejlRVDk2eTBJa1M0M0R5NXRMQm8rWUFvYUN2Q3Ns?= =?utf-8?B?RVkyVTlXRms5UkZtTUx4aDlFOWNCMEl5L1F5ampCV3NHV2xhTjQzbXAzSXg1?= =?utf-8?B?Nkw5dDVOVERrMWRzTlc1TW9LVXJoVWR2d2pGazJrM2c4S3hQSkZ3cjJkTkNP?= =?utf-8?B?bktKSjlnc1dMQTBPTk96alFCSVQyb1ZWbUl1bVRVZkQxQXMvSGtTNmlpVzA2?= =?utf-8?B?akZqVkZ6R3lYQWRPVU8rb2sxT1Z3YlpwMTdEMk5uODBCcEg3aE5PWHFSNTZK?= =?utf-8?B?T0dGVWp4UDByNklJWS8xSi9PdUlIUlR5SHNaa0oxek9GNDFQS0VyUmxhMjNK?= =?utf-8?B?YnFiNkh6dDhZbkx6VFQzbzVYeEk5S3hSWWl6amhCbnJ0Y0pEVDQwZDR0akhH?= =?utf-8?B?R21ZczFnbzhwT1NNUWtCdndjOVJKR0xKQnd3eC80RTNvSlVWUVZETVRFRGds?= =?utf-8?B?MlhRcHVyc3pmWVAvR0grOGNxV1d1THpZR1IzS2FzOHh1eklzbXJpVXNlL3Yv?= =?utf-8?B?ZWZyK0xBUFI0cUFucVp3Q245enV5bUxRb01ocFA2YnROT3JSRXdod3plNysr?= =?utf-8?B?ME1oaDBHMjhjZHd3ZWp3dzVxMUVvZ21BSDFrTnFQMUU3a1hsNlBucGdQV1JO?= =?utf-8?B?QllJRlhnRG5Wa25uTEJ1dFNaOVFSTXNJZGtMMS9LNVg4Y2hIakNPYUk4bU5n?= =?utf-8?B?SGsxeW1JMFZTQ1FybUxCOHRvYXhzcTg3WHZSN3p6ZWh1TE5scDAvamU1UytB?= =?utf-8?B?SmVHRUUxWFh2SGRVYjRYckMzRms5eHZPWG9KWVEwN3djOXhaUENCVit4Q2Ur?= =?utf-8?B?Z2dhSSt2cU40dTVOOWFYcE5DWEZ3dzkrMDI3d1pWUm1OUlhseFd3NDlJaksy?= =?utf-8?B?MDduamNwaFY5WGtRbUlXR2VQd1RVc1FLZzNzVVM5akJ3UFJrbVUwaDV0alU1?= =?utf-8?B?SEFwZ1hNREhTZTJrZHdFZGZESUhKRldGL3d6R0NvZ0VneTcrRWJyTWcyVTd4?= =?utf-8?B?eUgvd0gvQTlSWWlhbU1ZMkFnckRpSmEyNzRVdzZXUFJXb2tSTVc3V25GSllS?= =?utf-8?B?RUNSWkpyd1BZNjdxS1RRN2h2VE9UVGFLWFh3alpRK1ZCRmpkZ2s5ak1MZEp4?= =?utf-8?B?V2VpZHYzYUh6MG04WTkzbEc2YTBpOWtocmlRd1VVdms5MzdYVWExN0FRanRU?= =?utf-8?B?MU5PVm1QQ2dhdDdlMFN6US8rd254d3hmT0Y2Qm15MFFobDZnSGxQZDVMazNQ?= =?utf-8?B?L05meUlqaURWS3VzbGpWQUhTUm9NUDNxdnlmODBLM3lVQlVsYUdSRE45bHdF?= =?utf-8?B?YkNWRThja3VTS2Q4cG4zK1NFWVRxS2RIY0o1T1d4aGxQZnZkcEUwS2VmNjF4?= =?utf-8?B?QmxhUGUzZUp4VmNxaG9NRjZIRG1NNjkxdjRybHlxV2dmT2hYVkZKTkhwTHhS?= =?utf-8?B?bW8zbHpQb0tVaGJNVVRTMjdVb1ZQSEFvRDNFamZLWUlVRWVMcnNCdy85U2Rl?= =?utf-8?B?Q011MUhhWnhDbnFBOFNhYzU2MTJzRWlicDUvWm9NNy9ua2tMeHNmejNURnM0?= =?utf-8?B?NTZBNmtiQTh4UXVpaHZ3bS9HTSs2dFRzdnhsd3lvSk9jdTFPNXJzVmFvWE1W?= =?utf-8?B?S1IvQzNzU0hxVU5QaU1ZNGp5Wmh1WDMxVDNManJQN2NjMVZWb3I1YzJwVm5J?= =?utf-8?B?c0h0THh2NGJXenNjbHN0Z29rQXRWZUVMWm4zU1NiKzJmMmdWTFBLOVJMUlZk?= =?utf-8?B?VWZSZkhNUTJ5TGVaVW1Ia0ZlREJYSER1Nm1BQUtNaHVZMEg3U2hUNnFjVlRW?= =?utf-8?B?SlRXY0hxUmpGdDdVd1BEbFUzYWR6Yll5Q1dQaVpHakRwSFlPK3J3b3VWZkNN?= =?utf-8?B?OGo3N0pNLzY0MC9hSnRENzVJQWdERkdZVnVOVm85VWx5MnBaUEhTK1pDTitD?= =?utf-8?B?Wm5GVVlPM1JaTzNBZUE3WnJnNU12N04rWEFZS25UVXoyNE0vRnNzazFxWXN6?= =?utf-8?B?bE9pQk5uaWdQNytRQ2luY0ZER0tBZG5iWlNwdS9ab0Z0S05LNU5XZ1lRcTdh?= =?utf-8?B?NXgwVlh1czYyVXVaT0krMklRQVVhRXJnYTJBSjZRZ1NOUlV4alQ0Ty9QSUZT?= =?utf-8?Q?6SQYiCwAdXcoZMKM=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70ec5732-84f7-4e55-35d0-08df1017229b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 15:12:46.1613 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QK9o1xdN0y9lOTel/xAJCasGGqKHcrgOsD66i7Z1SpVAEYmzjcWfzVW2eH1UnLn+WDJKD0Ays3t+J7y0c2ODEzlnF7nLQaas7YuwxtVjzMA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6924 X-purgate-ID: tlsNG-42698a/1789139572-A88C99EA-DD916D2D/0/0 X-purgate-type: clean X-purgate-size: 855 On 11/09/2026 1:32 pm, Teddy Astie wrote: > Le 10/09/2026 à 22:31, Kevin Lampis a écrit : >> A new sub-op MMU_PT_UPDATE_SWAP when used will do an atomic swap to set >> the new value and return the old PTE value through the req.val field. >> >> - The new PTE value in req.val must be 0, at the moment this is intended >>    for clearing only. >> > > I'm not sure this is a good idea to restrict the feature for only 0. > If in the future we want to expand this to non-0 values, we will need > to advertise this property to the guest as well (so that it knows if > non-0 values are supported). I don't know what supporting !0 would > require (but it could be useful to get a idea of it). Going further, this cannot be limited to 0 as an input, or to only L1e's. What I don't see is why you need any restrictions at all ? ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 11 15:13:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 15:13:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417353.1646233 (Exim 4.92) (envelope-from ) id 1x52w5-0007W2-6F; Fri, 11 Sep 2026 15:13:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417353.1646233; Fri, 11 Sep 2026 15:13:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52w5-0007Vr-1o; Fri, 11 Sep 2026 15:13:05 +0000 Received: by outflank-mailman (input) for mailman id 1417353; Fri, 11 Sep 2026 15:13:03 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x52w3-0007SM-AK for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:13:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x52w2-00EUk4-7s for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:13:02 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41a6f-8faa-0a2a0a5109dd-0a2a4508b546-16 for ; Fri, 11 Sep 2026 17:13:02 +0200 Received: from [52.101.193.13] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41a7c-f659-0a2a45080019-3465c10d2421-3 for ; Fri, 11 Sep 2026 17:13:01 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by MWHPR03MB989453.namprd03.prod.outlook.com (2603:10b6:303:2ab::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.10; Fri, 11 Sep 2026 15:12:57 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 15:12:57 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XACV1Dp/0OXidJjp7aDYt8AQSHc10Iz+JemK114FUHpsQGS4ddsuSWjlQ1J/u2jg7ytmkvMu9iB4vwphZV76TE9CEEMz2swcTtIhAv3MRPCHlZDPzzSr5C7C4lrvwH/Q3HTZCP6yz6g6gKBMokkNSDpREvFact6a1y4HucjMHQoN9Ux0zxJC8oGfDm/B0vRmC0IMv7JbKTGwP/ktW3AVW4sfdKe0uL68snj+kLX/eIIdff+nLE8y7FZ5ae6vFVGuWNpkwepnbpONys+OmuOTte4vf9F9cooREWDTS96CW70zSifTnMFvDPEhQ5fHNVo1+tEqP1DatBosr6mj8Y+kRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9Qjj83BN1FMLCqIaOx3847RbdtvdTFxorGBeyNGoUOg=; b=fp6BQ9wXXfb5Sf8cmHho9sQMrl3TDWTvFlUZHnG8IU46F/1OzVAcPDywXQXoW0QEeRClkdWrC4JYkNyii4qki17+ToSb9/d6aO7Q0/xzXU627zUFPEfRvG5WhQzK9l2IYzY1NIfnHV4fVwm5gi22Tfe+Cm9vfCJ85ibFzJooffx3XRr8gctSNDxiM0LuS9DL8VplBc6PcGVFGX898EjzJpT6Hxa55YtE/mRsEjZHuA2ndjH0TSRtD4Wc4L4BbxBVCIwbBb4zJla23W9K08N0/M1cd5TYmeHHk9WCO7ASaf/hC3t9dqEp5C9XJJqjH+YF1uDe5PzZCD1+7as7pBkPtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Qjj83BN1FMLCqIaOx3847RbdtvdTFxorGBeyNGoUOg=; b=Ooum52/+jj2CZE0Q8gp13yfpRLFcYfOuwXIvMplWUlMXpKW6DwGwVYk4JmtPLP4hq6+RtGrU1IiqDe4VTaYUBbXUkxudpam0Pa/oijKvW/5aojiMeqnHnkyD0TaGjTATseo4mFq7NnihKI7abQOSpKSipxgikjjxouw4bcorefw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v1] x86/svm: Fix VMLOAD/VMSAVE state handling when using nested virt Date: Fri, 11 Sep 2026 16:12:50 +0100 Message-ID: <20260911151250.1232332-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0002.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:150::7) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|MWHPR03MB989453:EE_ X-MS-Office365-Filtering-Correlation-Id: b6f31031-ffb8-4ac5-09a1-08df1017290d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|10067099003|6133799003|18002099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: VaBuLAIJr0RXPGbd15g/7lBbO7HzWpYWlU3TPIn5SR4a7ZenI3kpzPznfLWq+Isnmrfl7V83QK2AxW6zanhiT6OfbPklvR4zOtlgAipO6a4inWQZ1gufhYJLFC8DluyvOC+RiSY/inEF1xhfLQ1IXlmQJlNZNwYBZwmQusadfEaNF6OT4xs7xD+9Y1FW+t2HBgTPYymJydlmw1wNQ9/yWZiRWftkk2gXlTHQtU8QHX9fEZ7jQpUw9l9hDVoA+tnnJqH9H0FclLogtoFduKeaWRo3E5W72Khzyzj3LD7158xVqm9R4AW8+l6yHUYlVq2x036nSKY6kUb8loEvUFK7ruPiH9uk7WfpJUm4rd1hx67aEnxTWZVzGBAxb6cMeSurdcuqMB9ZiJMpWyXfD4+we+xPjh0hktlWCBqddLED630rIPHmvKopTFBENXIVrWwleUhMp2ad1hxEZ+nXmTCG/kaaqr6u8C+s2vJppa8WZVw0RbTIIzlxlodSCn6+sFFLYMXPHbceHZdjkPO56XRDxOpQN0KY6iPyNr9G/fpaBf0AjRdUpLeRa1LfxecOzGLyPpqZ3OujEGWVsa4w4GkMdIhQE/4oanQigtMZOuSdP7Qb8pqqbssXeUBRvmqJbul98vCph9qlWzkJ9ZLMJZcZisFVRgLrtIUXS8AwHNCIh4g= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(10067099003)(6133799003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?UQ9iZnZ146qeWj7N5OE5LU5ocjpmpIce7gBonAPLSfDR2oApC9KbA5eva+Xd?= =?us-ascii?Q?XwRNZKxJh0JNMFsEFEOYobLB2jw2hEoIO8D+R456ieVYoIjx0sflerocMaAi?= =?us-ascii?Q?Mimlj4hMvrXPqs0YJr5QqmILWVy2XWQB2kQBz6Ummb1nKpYt0voWqaEDmMEH?= =?us-ascii?Q?l8HCqW9LVCtnkWGFWlcVZInSTa+W44WFuovs9YA/ZjRqzd9UwKlcaBkCoUhj?= =?us-ascii?Q?yhn5m8KTAEed0ajGTWCEX/6tzPrPlLc9kwAi06fJNAVnrggvoLBSPU+igNdu?= =?us-ascii?Q?3aNOxGp6B/PM3DHCMKMbSPdn7RxbmjbgoxQfrNCg+D/Pl4EYtHlwOh3EG1PK?= =?us-ascii?Q?Mj7Ctgq8+E/QDRMXUUEmKMTIVi68/unJyL0WWPkD1XT1hzavuWWXA8KBqTZz?= =?us-ascii?Q?cDi6ohuOz6Ofz97yaa0yeaC2z78rvfSaCjhpWf9VheHz/3Ot2GsuUMzSp5jD?= =?us-ascii?Q?aZdZyGlDNIIxVc85QdEgGohc9Yx0aT6v8h5y8m5fnDgvoGwp+HE7XfbBHzbz?= =?us-ascii?Q?4ffFAMgz4EWY3xXyXyOrjCstTa21JgcWl9bDl29ajXxv6vEJRUL0I4RQbyyu?= =?us-ascii?Q?ni/sZuLNrtTcsXsERIrLZMp6b/RMmnybhaTvpQrFxK0YzirOZMFWvN+ynz5i?= =?us-ascii?Q?hCoZLdPjacwGiXdQWWC+EnnpZTUzXCsRhmRoxMonLKIJoD0oyhMI+geiTrcd?= =?us-ascii?Q?NsUpwl3mTK1Idh9OxU9rJQwhy4QUEHOoQKcYo1oifRPL+gk6UEFXRoCDF6QW?= =?us-ascii?Q?cVjN8RFchiULERmg3LuhiMDNbuzGmzAgR67WnQ01Al7NRCPwXiZYuEahrG2/?= =?us-ascii?Q?3J9ZQEEK04vfDqfMOGu3IEWgwmYBtxUPCsrw/xLGbTdu31SAEDW4Um0BoxX3?= =?us-ascii?Q?0yFzk/eVoaOg172g7YX4nMa8C7dOtOOLzrHKotCMKZbDq44rwY2FrmyH8ieB?= =?us-ascii?Q?I+cWBcc+x8bdW0nTcMFjCCS9CbhJm+W4bOZPhDhd7QsvObngcRVcQfSLA88a?= =?us-ascii?Q?dtfEXbXwRVLrB6rS3TpYrUd9DU/FDQFE0FAsE/yKj55zlYzyht2QXgd4Qrh6?= =?us-ascii?Q?paLCx24pzQ33x0jFLv5vbo1bMqkYmE/he32qIXuLiwJQLs0WPIiWTTs2afnX?= =?us-ascii?Q?auye87miaHf8PqnVJ+Jj+TntEVrYFQBQCjgUpDWzsziIJxb55OaH7K1KqDMa?= =?us-ascii?Q?aSY3XgsulQxHSYuhBO4oCKAlfAUwtT6CpZULG7LTnbNMY0TPe9n3GMWMHLBd?= =?us-ascii?Q?3dHoDP4i8iluxfqKsROpMb14DU/ZQTVkD6PGXKSu6jugu+ceuiKlMYV92YRd?= =?us-ascii?Q?6+3+JTtAMjQz4mr3av6eeLe++3uJQVKnX5nR5KqVF1k5JHgm2VA2utDGoP1x?= =?us-ascii?Q?Q19/z3Xt73RA5CeP3Rdd6Bf/I3cMUtFzaaREL4QECNSoigItH8SxRb3v0Ngk?= =?us-ascii?Q?/V/Z31KcV12WZqWUHwGoU/3SZ9VySPwRhdNsSc8Vsp06a7E8YkcSz4yGttjR?= =?us-ascii?Q?+wQtZ335ATUSMWEjsmiDQ/YTlu5i1iNcGMXq1TPCK+a3W69WU8eMlc34A1Mj?= =?us-ascii?Q?xe3+qGASc38Bb56EQB26V40vXd3arYRQIxVe12Iq6ayXivfrBou5Nnl4gqds?= =?us-ascii?Q?NEBZyce64CdbfkTomuiwP8cnx9MYmIyDpEH0SvmX+xQZCPaUfGn7pKrZ1SLH?= =?us-ascii?Q?IHUcVfWjk1zF+kx3sbV47OfOIPCsyRGlIr9QkQt+1PjfafrwbQhaHxDv6M6E?= =?us-ascii?Q?74VdKcC7+UeUjG2et5O+rgkRgBwQBNU=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6f31031-ffb8-4ac5-09a1-08df1017290d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 15:12:56.9968 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QDHAQinmeCuL/EpaISjzfHCPIEzIcygQvo/jkImzJXvr/ZYzWVB9Rw8gxz7HiloQYq6YXsvMAmnNAA+z80XQ4HtjiRx3ZNeVjv1XNi/lZMQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB989453 X-purgate-ID: tlsNG-c1860d/1789139582-D775B87B-322BD34C/0/0 X-purgate-type: clean X-purgate-size: 16702 Currently, the SVM VMLOAD/VMSAVE state handling always uses the vCPU's active VMCB to load/store the state. The active VMCB changes depending on whether or not the vCPU is in guest mode yet the state is not properly copied between VMCB(0-1) and VMCB(0-2) nor is the vmcb_sync_state updated when switching active VMCB. The most common way this fails is when context switching to a vCPU in guest mode and immediately taking a VMEXIT (e.g. due to an interrupt for L1 having arrived in the meantime). The code issues an unconditional VMSAVE into VMCB(0-1) but the state has not yet been loaded since context switching which results in garbage in VMCB(0-1). The garbage state is then (re-)loaded from VMCB(0-1) shortly before VMRUN. This results in frequent, random crashes in L2. Since the state covered by VMLOAD/VMSAVE is a property of the vCPU and is not affected by switches to and from guest mode, always use VMCB(0-1) to store and retrieve it. This avoids the need to synchronize state between VMCBs and fixes the random crashes. L1 itself is responsible for using VMLOAD/VMSAVE to load/save the state from hardware into its own VMCB(1-2) and this change does not affect that. Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/svm/nestedsvm.c | 7 -- xen/arch/x86/hvm/svm/svm.c | 107 +++++++++++++++++-------------- xen/arch/x86/hvm/svm/vmcb.c | 26 ++++---- xen/arch/x86/hvm/svm/vmcb.h | 3 +- 4 files changed, 75 insertions(+), 68 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 5adb1bd72c4d..c2250b85cf28 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -198,11 +198,6 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) ASSERT(n1vmcb != NULL); ASSERT(n2vmcb != NULL); - /* - * nsvm_vmcb_prepare4vmexit() already saved register values - * handled by VMSAVE/VMLOAD into n1vmcb directly. - */ - /* switch vmcb to l1 guest's vmcb */ v->arch.hvm.svm.vmcb = n1vmcb; v->arch.hvm.svm.vmcb_pa = nv->nv_n1vmcx_pa; @@ -969,8 +964,6 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; struct vmcb_struct *n2vmcb = nv->nv_n2vmcx; - svm_vmsave_pa(nv->nv_n1vmcx_pa); - /* Cache guest physical address of virtual vmcb * for VMCB Cleanbit emulation. */ diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 5f5d903d872d..50822eebd7cf 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -444,30 +444,30 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; - data->sysenter_cs = vmcb->sysenter_cs; - data->sysenter_esp = vmcb->sysenter_esp; - data->sysenter_eip = vmcb->sysenter_eip; - data->shadow_gs = vmcb->kerngsbase; - data->msr_lstar = vmcb->lstar; - data->msr_star = vmcb->star; - data->msr_cstar = vmcb->cstar; - data->msr_syscall_mask = vmcb->sfmask; + data->sysenter_cs = n1_vmcb->sysenter_cs; + data->sysenter_esp = n1_vmcb->sysenter_esp; + data->sysenter_eip = n1_vmcb->sysenter_eip; + data->shadow_gs = n1_vmcb->kerngsbase; + data->msr_lstar = n1_vmcb->lstar; + data->msr_star = n1_vmcb->star; + data->msr_cstar = n1_vmcb->cstar; + data->msr_syscall_mask = n1_vmcb->sfmask; } static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) { - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; - vmcb->lstar = data->msr_lstar; - vmcb->star = data->msr_star; - vmcb->cstar = data->msr_cstar; - vmcb->sfmask = data->msr_syscall_mask; - vmcb->kerngsbase = data->shadow_gs; - vmcb->sysenter_cs = data->sysenter_cs; - vmcb->sysenter_esp = data->sysenter_esp; - vmcb->sysenter_eip = data->sysenter_eip; + n1_vmcb->lstar = data->msr_lstar; + n1_vmcb->star = data->msr_star; + n1_vmcb->cstar = data->msr_cstar; + n1_vmcb->sfmask = data->msr_syscall_mask; + n1_vmcb->kerngsbase = data->shadow_gs; + n1_vmcb->sysenter_cs = data->sysenter_cs; + n1_vmcb->sysenter_esp = data->sysenter_esp; + n1_vmcb->sysenter_eip = data->sysenter_eip; v->arch.hvm.guest_efer = data->msr_efer; svm_update_guest_efer(v); } @@ -579,18 +579,19 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v) void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) { struct svm_vcpu *svm = &v->arch.hvm.svm; + struct nestedvcpu *nv = &vcpu_nestedhvm(v); if ( new_state == vmcb_needs_vmsave ) { if ( svm->vmcb_sync_state == vmcb_needs_vmload ) - svm_vmload_pa(svm->vmcb_pa); + svm_vmload_pa(nv->nv_n1vmcx_pa); svm->vmcb_sync_state = new_state; } else { if ( svm->vmcb_sync_state == vmcb_needs_vmsave ) - svm_vmsave_pa(svm->vmcb_pa); + svm_vmsave_pa(nv->nv_n1vmcx_pa); if ( svm->vmcb_sync_state != vmcb_needs_vmload ) svm->vmcb_sync_state = new_state; @@ -606,6 +607,7 @@ static void cf_check svm_get_segment_register( struct vcpu *v, enum x86_segment seg, struct segment_register *reg) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; ASSERT((v == current) || !vcpu_runnable(v)); @@ -613,8 +615,9 @@ static void cf_check svm_get_segment_register( { case x86_seg_fs ... x86_seg_gs: svm_sync_vmcb(v, vmcb_in_sync); + *reg = n1_vmcb->sreg[seg]; + break; - /* Fallthrough. */ case x86_seg_es ... x86_seg_ds: *reg = vmcb->sreg[seg]; @@ -624,7 +627,7 @@ static void cf_check svm_get_segment_register( case x86_seg_tss: svm_sync_vmcb(v, vmcb_in_sync); - *reg = vmcb->tr; + *reg = n1_vmcb->tr; break; case x86_seg_gdt: @@ -637,7 +640,7 @@ static void cf_check svm_get_segment_register( case x86_seg_ldt: svm_sync_vmcb(v, vmcb_in_sync); - *reg = vmcb->ldtr; + *reg = n1_vmcb->ldtr; break; default: @@ -652,6 +655,7 @@ static void cf_check svm_set_segment_register( struct vcpu *v, enum x86_segment seg, struct segment_register *reg) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; ASSERT((v == current) || !vcpu_runnable(v)); @@ -690,12 +694,16 @@ static void cf_check svm_set_segment_register( /* Fallthrough */ case x86_seg_es ... x86_seg_cs: - case x86_seg_ds ... x86_seg_gs: + case x86_seg_ds: vmcb->sreg[seg] = *reg; break; + case x86_seg_fs ... x86_seg_gs: + n1_vmcb->sreg[seg] = *reg; + break; + case x86_seg_tss: - vmcb->tr = *reg; + n1_vmcb->tr = *reg; break; case x86_seg_gdt: @@ -709,7 +717,7 @@ static void cf_check svm_set_segment_register( break; case x86_seg_ldt: - vmcb->ldtr = *reg; + n1_vmcb->ldtr = *reg; break; case x86_seg_sys: @@ -1665,6 +1673,7 @@ static int cf_check svm_msr_read_intercept( struct vcpu *v = current; const struct domain *d = v->domain; struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; const struct nestedsvm *nsvm = &vcpu_nestedsvm(v); uint64_t tmp; @@ -1687,43 +1696,43 @@ static int cf_check svm_msr_read_intercept( switch ( msr ) { case MSR_IA32_SYSENTER_CS: - *msr_content = vmcb->sysenter_cs; + *msr_content = n1_vmcb->sysenter_cs; break; case MSR_IA32_SYSENTER_ESP: - *msr_content = vmcb->sysenter_esp; + *msr_content = n1_vmcb->sysenter_esp; break; case MSR_IA32_SYSENTER_EIP: - *msr_content = vmcb->sysenter_eip; + *msr_content = n1_vmcb->sysenter_eip; break; case MSR_STAR: - *msr_content = vmcb->star; + *msr_content = n1_vmcb->star; break; case MSR_LSTAR: - *msr_content = vmcb->lstar; + *msr_content = n1_vmcb->lstar; break; case MSR_CSTAR: - *msr_content = vmcb->cstar; + *msr_content = n1_vmcb->cstar; break; case MSR_SYSCALL_MASK: - *msr_content = vmcb->sfmask; + *msr_content = n1_vmcb->sfmask; break; case MSR_FS_BASE: - *msr_content = vmcb->fs.base; + *msr_content = n1_vmcb->fs.base; break; case MSR_GS_BASE: - *msr_content = vmcb->gs.base; + *msr_content = n1_vmcb->gs.base; break; case MSR_SHADOW_GS_BASE: - *msr_content = vmcb->kerngsbase; + *msr_content = n1_vmcb->kerngsbase; break; case MSR_IA32_MCx_MISC(4): /* Threshold register */ @@ -1856,6 +1865,7 @@ static int cf_check svm_msr_write_intercept( struct vcpu *v = current; struct domain *d = v->domain; struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; struct nestedsvm *nsvm = &vcpu_nestedsvm(v); switch ( msr ) @@ -1889,45 +1899,45 @@ static int cf_check svm_msr_write_intercept( switch ( msr ) { case MSR_IA32_SYSENTER_ESP: - vmcb->sysenter_esp = msr_content; + n1_vmcb->sysenter_esp = msr_content; break; case MSR_IA32_SYSENTER_EIP: - vmcb->sysenter_eip = msr_content; + n1_vmcb->sysenter_eip = msr_content; break; case MSR_LSTAR: - vmcb->lstar = msr_content; + n1_vmcb->lstar = msr_content; break; case MSR_CSTAR: - vmcb->cstar = msr_content; + n1_vmcb->cstar = msr_content; break; case MSR_FS_BASE: - vmcb->fs.base = msr_content; + n1_vmcb->fs.base = msr_content; break; case MSR_GS_BASE: - vmcb->gs.base = msr_content; + n1_vmcb->gs.base = msr_content; break; case MSR_SHADOW_GS_BASE: - vmcb->kerngsbase = msr_content; + n1_vmcb->kerngsbase = msr_content; break; } break; case MSR_IA32_SYSENTER_CS: - vmcb->sysenter_cs = msr_content; + n1_vmcb->sysenter_cs = msr_content; break; case MSR_STAR: - vmcb->star = msr_content; + n1_vmcb->star = msr_content; break; case MSR_SYSCALL_MASK: - vmcb->sfmask = msr_content; + n1_vmcb->sfmask = msr_content; break; case MSR_IA32_DEBUGCTLMSR: @@ -2333,6 +2343,7 @@ static bool cf_check svm_get_pending_event( static uint64_t cf_check svm_get_reg(struct vcpu *v, unsigned int reg) { struct vcpu *curr = current; + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; const struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; struct domain *d = v->domain; @@ -2344,7 +2355,7 @@ static uint64_t cf_check svm_get_reg(struct vcpu *v, unsigned int reg) case MSR_SHADOW_GS_BASE: if ( v == curr ) svm_sync_vmcb(v, vmcb_in_sync); - return vmcb->kerngsbase; + return n1_vmcb->kerngsbase; default: printk(XENLOG_G_ERR "%s(%pv, 0x%08x) Bad register\n", @@ -2617,7 +2628,7 @@ void asmlinkage svm_vmexit_handler(void) if ( unlikely(exit_reason == VMEXIT_INVALID) ) { gdprintk(XENLOG_ERR, "invalid VMCB state:\n"); - svm_vmcb_dump(__func__, vmcb); + svm_vmcb_dump(__func__, v, vmcb); domain_crash(v->domain); goto out; } diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 975a1eaef806..6e2a45ff3c4b 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -243,16 +243,17 @@ static void svm_dump_sel(const char *name, const struct segment_register *s) name, s->sel, s->attr, s->limit, s->base); } -void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) +void svm_vmcb_dump(const char *from, struct vcpu *v, + const struct vmcb_struct *vmcb) { - struct vcpu *curr = current; + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; /* * If we are dumping the VMCB currently in context, some guest state may * still be cached in hardware. Retrieve it. */ - if ( vmcb == curr->arch.hvm.svm.vmcb ) - svm_sync_vmcb(curr, vmcb_in_sync); + if ( v == current ) + svm_sync_vmcb(v, vmcb_in_sync); printk("Dumping guest's current state at %s...\n", from); printk("Size of VMCB = %zu, paddr = %"PRIpaddr", vaddr = %p\n", @@ -286,7 +287,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) printk("virtual vmload/vmsave = %d, virt_ext = %#"PRIx64"\n", vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes); printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = %#"PRIx64"\n", - vmcb_get_cpl(vmcb), vmcb_get_efer(vmcb), vmcb->star, vmcb->lstar); + vmcb_get_cpl(vmcb), vmcb_get_efer(vmcb), n1_vmcb->star, + n1_vmcb->lstar); printk("CR0 = 0x%016"PRIx64" CR2 = 0x%016"PRIx64"\n", vmcb_get_cr0(vmcb), vmcb_get_cr2(vmcb)); printk("CR3 = 0x%016"PRIx64" CR4 = 0x%016"PRIx64"\n", @@ -298,9 +300,9 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) printk("DR6 = 0x%016"PRIx64", DR7 = 0x%016"PRIx64"\n", vmcb_get_dr6(vmcb), vmcb_get_dr7(vmcb)); printk("CSTAR = 0x%016"PRIx64" SFMask = 0x%016"PRIx64"\n", - vmcb->cstar, vmcb->sfmask); + n1_vmcb->cstar, n1_vmcb->sfmask); printk("KernGSBase = 0x%016"PRIx64" PAT = 0x%016"PRIx64"\n", - vmcb->kerngsbase, vmcb_get_g_pat(vmcb)); + n1_vmcb->kerngsbase, vmcb_get_g_pat(vmcb)); printk("SSP = 0x%016"PRIx64" S_CET = 0x%016"PRIx64" ISST = 0x%016"PRIx64"\n", vmcb->_ssp, vmcb->_msr_s_cet, vmcb->_msr_isst); printk("H_CR3 = 0x%016"PRIx64" CleanBits = %#x\n", @@ -312,12 +314,12 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) svm_dump_sel(" DS", &vmcb->ds); svm_dump_sel(" SS", &vmcb->ss); svm_dump_sel(" ES", &vmcb->es); - svm_dump_sel(" FS", &vmcb->fs); - svm_dump_sel(" GS", &vmcb->gs); + svm_dump_sel(" FS", &n1_vmcb->fs); + svm_dump_sel(" GS", &n1_vmcb->gs); svm_dump_sel("GDTR", &vmcb->gdtr); - svm_dump_sel("LDTR", &vmcb->ldtr); + svm_dump_sel("LDTR", &n1_vmcb->ldtr); svm_dump_sel("IDTR", &vmcb->idtr); - svm_dump_sel(" TR", &vmcb->tr); + svm_dump_sel(" TR", &n1_vmcb->tr); } bool svm_vmcb_isvalid( @@ -418,7 +420,7 @@ static void cf_check vmcb_dump(unsigned char ch) continue; } printk("\tVCPU %d\n", v->vcpu_id); - svm_vmcb_dump("key_handler", v->arch.hvm.svm.vmcb); + svm_vmcb_dump("key_handler", v, v->arch.hvm.svm.vmcb); process_pending_softirqs(); } diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index 3760f71a8625..2bae45e41971 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -563,7 +563,8 @@ int svm_create_vmcb(struct vcpu *v); void svm_destroy_vmcb(struct vcpu *v); void setup_vmcb_dump(void); -void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb); +void svm_vmcb_dump(const char *from, struct vcpu *v, + const struct vmcb_struct *vmcb); bool svm_vmcb_isvalid(const char *from, const struct vmcb_struct *vmcb, const struct vcpu *v, bool verbose); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 15:20:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 15:20:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417426.1646242 (Exim 4.92) (envelope-from ) id 1x533Y-0002SV-0V; Fri, 11 Sep 2026 15:20:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417426.1646242; Fri, 11 Sep 2026 15:20:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x533X-0002SO-Tf; Fri, 11 Sep 2026 15:20:47 +0000 Received: by outflank-mailman (input) for mailman id 1417426; Fri, 11 Sep 2026 15:20:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x533W-0002SI-Ae for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:20:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x533V-006Bei-Ga for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:20:45 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41c2f-8faa-0a2a0a5109dd-0a2a450caa18-36 for ; Fri, 11 Sep 2026 17:20:45 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41c4b-f479-0a2a450c0019-aa0a857c748f-3 for ; Fri, 11 Sep 2026 17:20:44 +0200 Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-96-gun4YscRN0CVKvZmi3L3Zw-1; Fri, 11 Sep 2026 11:20:40 -0400 Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-3823dcc1647so1360018a91.3 for ; Fri, 11 Sep 2026 08:20:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789140043; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8rglFl+ZDPFhSWKYPy+x+UJN5EOFsaz34NJLR5RcNNo=; b=Zr12O0iOk452yyT7DWagyhuc8AUSFbcnLyC3veBOdalT5MZdW9F3oH0PI5bt7ztlL7tJ9z frB2fiM70t0J8UZE5qYjQYMckUx3nt+wGjexXxoHacTJSpVWN6u8OeD+6zyEkkN/IsBTK1 nLfI+eR/642PSJvXiabw62+HssCn9XY= X-MC-Unique: gun4YscRN0CVKvZmi3L3Zw-1 X-Mimecast-MFC-AGG-ID: gun4YscRN0CVKvZmi3L3Zw_1789140040 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789140040; x=1789744840; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=8rglFl+ZDPFhSWKYPy+x+UJN5EOFsaz34NJLR5RcNNo=; b=cGUIVqT1Vadb4dc3Ye7VoQ1KP1kosd4R2jpD88Mc+5Ft5okA4ZUsNptr2F8ZgshW+9 rCBXuTP7JkeTkRLFoZIc1RvatE18+Md3sznO4APe6WKYh+1dCFuTRq54uMCHumC/U5I6 qrhWDotdO/urLi6tMdlZCNRPJw0aCzimJ4x3Bm+BRfEYEHMeDNKxFop9ZsyeDKDt6NBG Q2nCgzLf8BeFpYd6QmengPgG+QQH9KNUr0w22aohF3AWZUd6P4Ai8y1NshZKeusA/+x9 Ztbzkrt8KgYy119dUnBJrZYsPdGFOkNG4LXx6oNUT/Q3Hl5AF0YX/KbdtURl4Bxv3Gx/ gjSw== X-Forwarded-Encrypted: i=1; AKwUvBx9owonOwM9MzwQSRiRAhhIoX59mei1E8Bppi81ftt9kQlb2v88OaDmIF6g1OT71gu3hzyQkd8eCf0=@lists.xenproject.org X-Gm-Message-State: AFuF++lojSdvmZhrQKOUlGS2gQcHVM1kLX09c+ejAVCNNxjNfdgFShKr gy3tInriX0bw9Bqhe8cYCwgRKCt9RSSsp7CkTSTk/v6fEp6leR3Wuha/Rk5QZPuUFObLV7xoqXF ZiwuNkLYfa0OsCBi6If19QLxVgvTLafZvwvSWj23TnjjA1hVxyqmpGXmf8I9VJKQYEREo3YanDC 7OFPfcfnwqyK4ro+r5iYeUVhMvwDDyy/X5h5e/5Ii8LuQ= X-Gm-Gg: AYBFou1YMS8OylJk40n1evpina+ICFNnWZQtjbrr3Rxk9DqIfk1BhrPQegA1b6bCD2W lnaocu1dLDVpuY/u7ID7Eu4xEV82jTOkiCButslVGT1UGC19983IDOrC9AyeFiqruSP3QDJ0FIm kQItZTuQ0TK3GozAWU2ZRRwNweVsGMEaIvjDUrMhQTdE7h+L6NCPAD2vhCWH/qOBH1bPE5w8a+1 7klFygJVoxA9pSqMeAu/IOkZFNbNtpPsPYRyfQJGxonbjVojCXIlnFF4akzsiESu9znQxrqzaYS Tg== X-Received: by 2002:a17:90a:d2cb:b0:398:9bd5:490b with SMTP id 98e67ed59e1d1-39d9c227985mr7665492a91.18.1789140037625; Fri, 11 Sep 2026 08:20:37 -0700 (PDT) X-Received: by 2002:a17:90a:d2cb:b0:398:9bd5:490b with SMTP id 98e67ed59e1d1-39d9c227985mr7665118a91.18.1789140035058; Fri, 11 Sep 2026 08:20:35 -0700 (PDT) MIME-Version: 1.0 References: <20260904-qom-qapi-v4-0-a985f168e938@redhat.com> <20260904-qom-qapi-v4-46-a985f168e938@redhat.com> <20260911003600.0a6732b2-50-amachhiw@linux.ibm.com> In-Reply-To: <20260911003600.0a6732b2-50-amachhiw@linux.ibm.com> From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Fri, 11 Sep 2026 19:20:22 +0400 X-Gm-Features: AcwNN1XnI4sJh1y03GevX00f_bwWdHhM8ma_Is9ycVVifsE1dPhGz4rUBVtu2j4 Message-ID: Subject: Re: [PATCH v4 46/75] qom: convert scalar properties to QAPI-aware registration To: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= , qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Michael Roth , Pierrick Bouvier , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Alexander Graf , Richard Henderson , "Gonglei (Arei)" , zhenwei pi , David Hildenbrand , Igor Mammedov , Alberto Garcia , Kevin Wolf , Hanna Reitz , "Michael S. Tsirkin" , Ani Sinha , Peter Maydell , Luc Michel , Zhao Liu , Jonathan Cameron , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Steven Lee , Troy Lee , Jamin Lin , Kane Chen , Andrew Jeffery , Joel Stanley , Samuel Tardieu , Marcelo Tosatti , John Snow , "Denis V. Lunev" , Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , FangSheng Huang , Tyrone Ting , Hao Wu , Jason Wang , Keith Busch , Klaus Jensen , Jesper Devantier , Nicholas Piggin , Aditya Gupta , Glenn Miles , Harsh Prateek Bora , Conor Dooley , Sebastian Huber , Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , Halil Pasic , Christian Borntraeger , Jason Herne , Ilya Leoshkevich , Eric Farman , Matthew Rosato , Cornelia Huck , Titus Rwantare , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Zhang Chen , Li Zhijian , Peter Xu , Chinmay Rath , Hendrik Brueckner , kvm@vger.kernel.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, linux-cxl@vger.kernel.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org Cc: Amit Machhiwal X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: zEsFVkRdHckt7_MZj5Dl-MwrjLAdmTwUQk3TEeNftto_1789140040 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1789140045-50F3B9FB-6A53CD16/0/0 X-purgate-type: clean X-purgate-size: 119102 On Thu, Sep 10, 2026 at 11:03=E2=80=AFPM Amit Machhiwal wrote: > > On 2026/09/04 11:58 PM, Marc-Andr=C3=A9 Lureau wrote: > > Signed-off-by: Marc-Andr=C3=A9 Lureau > > The PPC-specific changes in hw/ppc/spapr_drc.c, hw/pci-host/pnv_phb3.c, > hw/pci-host/pnv_phb4.c, and target/ppc/compat.c look good to me. Hence, > > Reviewed-by: Amit Machhiwal > > One thing I noticed in hw/sensor/adc128d818.c: > > #include "qapi-builtin-type-infos.h" > > Every other file in this patch uses: > > #include "qapi/qapi-builtin-type-infos.h" > > Is the missing `qapi/` prefix intentional, or is this a typo? Good catch, fixed thanks > > Thanks, > Amit > > > --- > > accel/kvm/kvm-all.c | 5 ++- > > accel/nitro/nitro-accel.c | 3 +- > > accel/tcg/tcg-all.c | 3 +- > > backends/cryptodev.c | 7 ++-- > > backends/hostmem-file.c | 4 +- > > backends/hostmem-memfd.c | 3 +- > > backends/hostmem.c | 6 +-- > > block/throttle-groups.c | 5 ++- > > crypto/secret_keyring.c | 9 +++-- > > event-loop-base.c | 7 ++-- > > hw/acpi/ich9.c | 1 + > > hw/acpi/pci.c | 7 ++-- > > hw/arm/virt.c | 4 +- > > hw/core/clock.c | 3 +- > > hw/core/machine.c | 2 +- > > hw/cpu/core.c | 10 +++-- > > hw/cxl/cxl-host.c | 2 +- > > hw/gpio/aspeed_gpio.c | 5 ++- > > hw/gpio/aspeed_sgpio.c | 3 +- > > hw/gpio/stm32l4x5_gpio.c | 5 ++- > > hw/i386/pc.c | 6 +-- > > hw/i386/sgx-epc.c | 3 +- > > hw/i386/x86.c | 6 +-- > > hw/ide/ide-dev.c | 3 +- > > hw/intc/apic_common.c | 3 +- > > hw/loongarch/virt.c | 2 +- > > hw/mem/nvdimm.c | 7 ++-- > > hw/mem/pc-dimm.c | 3 +- > > hw/misc/aspeed_lpc.c | 73 +++++++++++++++++++++++++----= -------- > > hw/misc/aspeed_sdmc.c | 3 +- > > hw/misc/npcm7xx_mft.c | 3 +- > > hw/net/ne2000-isa.c | 3 +- > > hw/nvme/ctrl.c | 3 +- > > hw/pci-bridge/pci_expander_bridge.c | 3 +- > > hw/pci-host/i440fx.c | 29 +++++++++------ > > hw/pci-host/pnv_phb3.c | 5 ++- > > hw/pci-host/pnv_phb4.c | 5 ++- > > hw/pci-host/q35.c | 9 +++-- > > hw/ppc/spapr_drc.c | 3 +- > > hw/riscv/microchip_pfsoc.c | 3 +- > > hw/s390x/sclpcpi.c | 8 ++-- > > hw/s390x/virtio-ccw-mem.c | 3 +- > > hw/sensor/adc128d818.c | 16 +++++--- > > hw/sensor/adm1266.c | 3 +- > > hw/sensor/adm1272.c | 9 +++-- > > hw/sensor/emc141x.c | 9 +++-- > > hw/sensor/isl_pmbus_vr.c | 19 +++++----- > > hw/sensor/lsm303dlhc_mag.c | 9 +++-- > > hw/sensor/max34451.c | 5 ++- > > hw/sensor/tmp105.c | 3 +- > > hw/sensor/tmp421.c | 9 +++-- > > hw/usb/dev-storage-classic.c | 3 +- > > hw/virtio/virtio-balloon.c | 3 +- > > hw/virtio/virtio-mem-pci.c | 3 +- > > hw/virtio/virtio-mem.c | 18 +++++---- > > hw/xen/xen-pvh-common.c | 9 +++-- > > iothread.c | 9 +++-- > > net/colo-compare.c | 7 ++-- > > net/dump.c | 6 ++- > > net/filter-buffer.c | 3 +- > > qom/object.c | 42 ++++++++++----------- > > system/bootdevice.c | 3 +- > > system/memory.c | 5 ++- > > target/arm/cpu64.c | 11 +++--- > > target/arm/kvm.c | 3 +- > > target/arm/tcg/cpu64.c | 11 +++--- > > target/i386/cpu.c | 12 +++--- > > target/i386/kvm/kvm.c | 8 ++-- > > target/i386/sev.c | 2 +- > > target/ppc/compat.c | 3 +- > > target/riscv/cpu.c | 15 ++++---- > > target/riscv/kvm/kvm-cpu.c | 7 ++-- > > target/riscv/tcg/tcg-cpu.c | 13 ++++--- > > target/s390x/cpu_models.c | 5 ++- > > tests/unit/test-qdev-global-props.c | 11 ++++-- > > ui/console.c | 3 +- > > util/thread-context.c | 7 ++-- > > 77 files changed, 343 insertions(+), 241 deletions(-) > > > > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c > > index e2cfbcf44046..ff9db3ca8b3d 100644 > > --- a/accel/kvm/kvm-all.c > > +++ b/accel/kvm/kvm-all.c > > @@ -24,6 +24,7 @@ > > #include "qemu/config-file.h" > > #include "qemu/error-report.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "hw/pci/msi.h" > > #include "hw/pci/msix.h" > > #include "hw/s390x/adapter.h" > > @@ -4278,13 +4279,13 @@ static void kvm_accel_class_init(ObjectClass *o= c, const void *data) > > .description =3D "Configure KVM in-kernel irqchip", > > )); > > > > - object_class_property_add(oc, "kvm-shadow-mem", "int", > > + object_class_property_add_qapi(oc, "kvm-shadow-mem", &int_type_inf= o, > > kvm_get_kvm_shadow_mem, kvm_set_kvm_shadow_mem, > > NULL, NULL); > > object_class_property_set_description(oc, "kvm-shadow-mem", > > "KVM shadow MMU size"); > > > > - object_class_property_add(oc, "dirty-ring-size", "uint32", > > + object_class_property_add_qapi(oc, "dirty-ring-size", &uint32_type= _info, > > kvm_get_dirty_ring_size, kvm_set_dirty_ring_size, > > NULL, NULL); > > object_class_property_set_description(oc, "dirty-ring-size", > > diff --git a/accel/nitro/nitro-accel.c b/accel/nitro/nitro-accel.c > > index a1e97a9162e9..05841c1277dc 100644 > > --- a/accel/nitro/nitro-accel.c > > +++ b/accel/nitro/nitro-accel.c > > @@ -29,6 +29,7 @@ > > #include "qemu/osdep.h" > > #include "qemu/error-report.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > #include "qemu/rcu.h" > > @@ -238,7 +239,7 @@ static void nitro_accel_class_init(ObjectClass *oc,= const void *data) > > object_class_property_set_description(oc, "debug-mode", > > "Start enclave in debug mode (enables console output)"); > > > > - object_class_property_add(oc, "enclave-cid", "uint64", > > + object_class_property_add_qapi(oc, "enclave-cid", &uint64_type_inf= o, > > nitro_get_enclave_cid, > > nitro_set_enclave_cid, > > NULL, NULL); > > diff --git a/accel/tcg/tcg-all.c b/accel/tcg/tcg-all.c > > index 767e8805552f..277cf0e2d012 100644 > > --- a/accel/tcg/tcg-all.c > > +++ b/accel/tcg/tcg-all.c > > @@ -29,6 +29,7 @@ > > #include "exec/icount.h" > > #include "tcg/startup.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qemu/error-report.h" > > #include "qemu/accel.h" > > #include "qemu/atomic.h" > > @@ -270,7 +271,7 @@ static void tcg_accel_class_init(ObjectClass *oc, c= onst void *data) > > tcg_get_thread, > > tcg_set_thread); > > > > - object_class_property_add(oc, "tb-size", "uint32", > > + object_class_property_add_qapi(oc, "tb-size", &uint32_type_info, > > tcg_get_tb_size, tcg_set_tb_size, > > NULL, NULL); > > object_class_property_set_description(oc, "tb-size", > > diff --git a/backends/cryptodev.c b/backends/cryptodev.c > > index e8f2b18f2017..a69adb70440c 100644 > > --- a/backends/cryptodev.c > > +++ b/backends/cryptodev.c > > @@ -25,6 +25,7 @@ > > #include "system/cryptodev.h" > > #include "system/stats.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-commands-cryptodev.h" > > #include "qapi/qapi-types-stats.h" > > #include "qapi/visitor.h" > > @@ -622,15 +623,15 @@ cryptodev_backend_class_init(ObjectClass *oc, con= st void *data) > > ucc->prepare_delete =3D cryptodev_backend_prepare_delete; > > > > QTAILQ_INIT(&crypto_clients); > > - object_class_property_add(oc, "queues", "uint32", > > + object_class_property_add_qapi(oc, "queues", &uint32_type_info, > > cryptodev_backend_get_queues, > > cryptodev_backend_set_queues, > > NULL, NULL); > > - object_class_property_add(oc, "throttle-bps", "uint64", > > + object_class_property_add_qapi(oc, "throttle-bps", &uint64_type_in= fo, > > cryptodev_backend_get_bps, > > cryptodev_backend_set_bps, > > NULL, NULL); > > - object_class_property_add(oc, "throttle-ops", "uint64", > > + object_class_property_add_qapi(oc, "throttle-ops", &uint64_type_in= fo, > > cryptodev_backend_get_ops, > > cryptodev_backend_set_ops, > > NULL, NULL); > > diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c > > index 9c7e0183d480..aeb6fc37858c 100644 > > --- a/backends/hostmem-file.c > > +++ b/backends/hostmem-file.c > > @@ -275,11 +275,11 @@ file_backend_class_init(ObjectClass *oc, const vo= id *data) > > file_memory_backend_get_discard_data, file_memory_backend_set_= discard_data); > > object_class_property_add_str(oc, "mem-path", > > get_mem_path, set_mem_path); > > - object_class_property_add(oc, "align", "uint64", > > + object_class_property_add_qapi(oc, "align", &uint64_type_info, > > file_memory_backend_get_align, > > file_memory_backend_set_align, > > NULL, NULL); > > - object_class_property_add(oc, "offset", "int", > > + object_class_property_add_qapi(oc, "offset", &int_type_info, > > file_memory_backend_get_offset, > > file_memory_backend_set_offset, > > NULL, NULL); > > diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c > > index e21c5a3f2e24..42027529ab50 100644 > > --- a/backends/hostmem-memfd.c > > +++ b/backends/hostmem-memfd.c > > @@ -16,6 +16,7 @@ > > #include "qemu/memfd.h" > > #include "qemu/module.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qom/object.h" > > #include "migration/cpr.h" > > > > @@ -145,7 +146,7 @@ memfd_backend_class_init(ObjectClass *oc, const voi= d *data) > > memfd_backend_set_hugetlb); > > object_class_property_set_description(oc, "hugetlb", > > "Use huge pages"); > > - object_class_property_add(oc, "hugetlbsize", "uint64", > > + object_class_property_add_qapi(oc, "hugetlbsize", &uint64_type= _info, > > memfd_backend_get_hugetlbsize, > > memfd_backend_set_hugetlbsize, > > NULL, NULL); > > diff --git a/backends/hostmem.c b/backends/hostmem.c > > index e7f9b436a459..d05ab53ab662 100644 > > --- a/backends/hostmem.c > > +++ b/backends/hostmem.c > > @@ -529,7 +529,7 @@ host_memory_backend_class_init(ObjectClass *oc, con= st void *data) > > host_memory_backend_set_prealloc); > > object_class_property_set_description(oc, "prealloc", > > "Preallocate memory"); > > - object_class_property_add(oc, "prealloc-threads", "int", > > + object_class_property_add_qapi(oc, "prealloc-threads", &int_type_i= nfo, > > host_memory_backend_get_prealloc_threads, > > host_memory_backend_set_prealloc_threads, > > NULL, NULL); > > @@ -540,13 +540,13 @@ host_memory_backend_class_init(ObjectClass *oc, c= onst void *data) > > object_property_allow_set_link, OBJ_PROP_LINK_STRONG); > > object_class_property_set_description(oc, "prealloc-context", > > "Context to use for creating CPU threads for preallocation"); > > - object_class_property_add(oc, "size", "size", > > + object_class_property_add_qapi(oc, "size", &size_type_info, > > host_memory_backend_get_size, > > host_memory_backend_set_size, > > NULL, NULL); > > object_class_property_set_description(oc, "size", > > "Size of the memory region (ex: 500M)"); > > - object_class_property_add(oc, "host-nodes", "[uint16]", > > + object_class_property_add_qapi(oc, "host-nodes", &uint16List_type_= info, > > host_memory_backend_get_host_nodes, > > host_memory_backend_set_host_nodes, > > NULL, NULL); > > diff --git a/block/throttle-groups.c b/block/throttle-groups.c > > index 6312157802da..851617237f80 100644 > > --- a/block/throttle-groups.c > > +++ b/block/throttle-groups.c > > @@ -31,6 +31,7 @@ > > #include "qemu/thread.h" > > #include "system/qtest.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-type-infos-block-core.h" > > #include "qapi/qapi-visit-block-core.h" > > #include "qom/object.h" > > @@ -983,9 +984,9 @@ static void throttle_group_obj_class_init(ObjectCla= ss *klass, > > > > /* individual properties */ > > for (i =3D 0; i < sizeof(properties) / sizeof(ThrottleParamInfo); = i++) { > > - object_class_property_add(klass, > > + object_class_property_add_qapi(klass, > > properties[i].name, > > - "int64", > > + &int64_type_info, > > throttle_group_get, > > throttle_group_set, > > NULL, &properties[i]); > > diff --git a/crypto/secret_keyring.c b/crypto/secret_keyring.c > > index 78d7f09b3b97..de813e79d8d6 100644 > > --- a/crypto/secret_keyring.c > > +++ b/crypto/secret_keyring.c > > @@ -21,6 +21,7 @@ > > #include "qemu/osdep.h" > > #include > > #include > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/error.h" > > #include "qom/object_interfaces.h" > > #include "trace.h" > > @@ -108,10 +109,10 @@ qcrypto_secret_keyring_class_init(ObjectClass *oc= , const void *data) > > QCryptoSecretCommonClass *sic =3D QCRYPTO_SECRET_COMMON_CLASS(oc); > > sic->load_data =3D qcrypto_secret_keyring_load_data; > > > > - object_class_property_add(oc, "serial", "int32_t", > > - qcrypto_secret_prop_get_key, > > - qcrypto_secret_prop_set_key, > > - NULL, NULL); > > + object_class_property_add_qapi(oc, "serial", &int32_type_info, > > + qcrypto_secret_prop_get_key, > > + qcrypto_secret_prop_set_key, > > + NULL, NULL); > > } > > > > > > diff --git a/event-loop-base.c b/event-loop-base.c > > index 23f554d92ce8..c16c5366f680 100644 > > --- a/event-loop-base.c > > +++ b/event-loop-base.c > > @@ -14,6 +14,7 @@ > > #include "qemu/osdep.h" > > #include "qom/object_interfaces.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "block/thread-pool.h" > > #include "system/event-loop-base.h" > > > > @@ -104,15 +105,15 @@ static void event_loop_base_class_init(ObjectClas= s *klass, > > ucc->complete =3D event_loop_base_complete; > > ucc->prepare_delete =3D event_loop_base_prepare_delete; > > > > - object_class_property_add(klass, "aio-max-batch", "int64", > > + object_class_property_add_qapi(klass, "aio-max-batch", &int64_type= _info, > > event_loop_base_get_param, > > event_loop_base_set_param, > > NULL, &aio_max_batch_info); > > - object_class_property_add(klass, "thread-pool-min", "int64", > > + object_class_property_add_qapi(klass, "thread-pool-min", &int64_ty= pe_info, > > event_loop_base_get_param, > > event_loop_base_set_param, > > NULL, &thread_pool_min_info); > > - object_class_property_add(klass, "thread-pool-max", "int64", > > + object_class_property_add_qapi(klass, "thread-pool-max", &int64_ty= pe_info, > > event_loop_base_get_param, > > event_loop_base_set_param, > > NULL, &thread_pool_max_info); > > diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c > > index 8082eae4282a..cf503668c00a 100644 > > --- a/hw/acpi/ich9.c > > +++ b/hw/acpi/ich9.c > > @@ -26,6 +26,7 @@ > > > > #include "qemu/osdep.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/pci/pci.h" > > #include "migration/vmstate.h" > > diff --git a/hw/acpi/pci.c b/hw/acpi/pci.c > > index c82924be8620..71d01307e141 100644 > > --- a/hw/acpi/pci.c > > +++ b/hw/acpi/pci.c > > @@ -27,6 +27,7 @@ > > #include "qemu/error-report.h" > > #include "qom/object_interfaces.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "hw/core/boards.h" > > #include "hw/acpi/aml-build.h" > > #include "hw/acpi/pci.h" > > @@ -139,7 +140,7 @@ static void acpi_generic_initiator_class_init(Objec= tClass *oc, const void *data) > > acpi_generic_initiator_set_pci_device); > > object_class_property_set_description(oc, "pci-dev", > > "PCI device to associate with the node"); > > - object_class_property_add(oc, "node", "uint32", NULL, > > + object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL= , > > acpi_generic_initiator_set_node, NULL, NULL); > > object_class_property_set_description(oc, "node", > > "NUMA node associated with the PCI device"); > > @@ -253,8 +254,8 @@ static void acpi_generic_port_class_init(ObjectClas= s *oc, const void *data) > > acpi_generic_port_set_pci_bus); > > object_class_property_set_description(oc, "pci-bus", > > "PCI Bus of the host bridge associated with this GP affinity st= ructure"); > > - object_class_property_add(oc, "node", "uint32", NULL, > > - acpi_generic_port_set_node, NULL, NULL); > > + object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL= , > > + acpi_generic_port_set_node, NULL, NULL); > > object_class_property_set_description(oc, "node", > > "The NUMA node like ID to index HMAT/SLIT NUMA properties invol= ving GP"); > > } > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > > index 872920b6482b..4e5d8d9f86e3 100644 > > --- a/hw/arm/virt.c > > +++ b/hw/arm/virt.c > > @@ -4258,7 +4258,7 @@ static void virt_machine_class_init(ObjectClass *= oc, const void *data) > > "Set on/off to enable/disabl= e high " > > "memory region for PCI MMIO"= ); > > > > - object_class_property_add(oc, "highmem-mmio-size", "size", > > + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type= _info, > > virt_get_highmem_mmio_size, > > virt_set_highmem_mmio_size, > > NULL, NULL); > > @@ -4266,7 +4266,7 @@ static void virt_machine_class_init(ObjectClass *= oc, const void *data) > > "Set the high memory region = size " > > "for PCI MMIO"); > > > > - object_class_property_add(oc, "virtio-mmio-transports", "uint8", > > + object_class_property_add_qapi(oc, "virtio-mmio-transports", &uint= 8_type_info, > > virt_get_virtio_transports, > > virt_set_virtio_transports, > > NULL, NULL); > > diff --git a/hw/core/clock.c b/hw/core/clock.c > > index 3fc98a0c65d5..f55cb17af77e 100644 > > --- a/hw/core/clock.c > > +++ b/hw/core/clock.c > > @@ -13,6 +13,7 @@ > > > > #include "qemu/osdep.h" > > #include "qemu/cutils.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "system/qtest.h" > > #include "hw/core/clock.h" > > @@ -185,7 +186,7 @@ static void clock_initfn(Object *obj) > > QLIST_INIT(&clk->children); > > > > if (qtest_enabled()) { > > - object_property_add(obj, "qtest-clock-period", "uint64", > > + object_property_add_qapi(obj, "qtest-clock-period", &uint64_ty= pe_info, > > clock_period_prop_get, NULL, NULL, NULL); > > } > > } > > diff --git a/hw/core/machine.c b/hw/core/machine.c > > index 530fbaeb0b28..aa2d90a4e4df 100644 > > --- a/hw/core/machine.c > > +++ b/hw/core/machine.c > > @@ -1133,7 +1133,7 @@ static void machine_class_init(ObjectClass *oc, c= onst void *data) > > object_class_property_set_description(oc, "smp-cache", > > "Cache properties list for SMP machine"); > > > > - object_class_property_add(oc, "phandle-start", "int", > > + object_class_property_add_qapi(oc, "phandle-start", &int_type_info= , > > machine_get_phandle_start, machine_set_phandle_start, > > NULL, NULL); > > object_class_property_set_description(oc, "phandle-start", > > diff --git a/hw/cpu/core.c b/hw/cpu/core.c > > index 26e488f3d8e3..d7c89f47ab04 100644 > > --- a/hw/cpu/core.c > > +++ b/hw/cpu/core.c > > @@ -12,6 +12,7 @@ > > #include "hw/core/boards.h" > > #include "hw/cpu/core.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > > > static void core_prop_get_core_id(Object *obj, Visitor *v, const char = *name, > > @@ -82,10 +83,11 @@ static void cpu_core_class_init(ObjectClass *oc, co= nst void *data) > > DeviceClass *dc =3D DEVICE_CLASS(oc); > > > > set_bit(DEVICE_CATEGORY_CPU, dc->categories); > > - object_class_property_add(oc, "core-id", "int", core_prop_get_core= _id, > > - core_prop_set_core_id, NULL, NULL); > > - object_class_property_add(oc, "nr-threads", "int", core_prop_get_n= r_threads, > > - core_prop_set_nr_threads, NULL, NULL); > > + object_class_property_add_qapi(oc, "core-id", &int_type_info, core= _prop_get_core_id, > > + core_prop_set_core_id, NULL, NULL); > > + object_class_property_add_qapi(oc, "nr-threads", &int_type_info, > > + core_prop_get_nr_threads, core_prop= _set_nr_threads, > > + NULL, NULL); > > } > > > > static const TypeInfo cpu_core_type_info =3D { > > diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c > > index 7592c4ac6c7b..4133398fec48 100644 > > --- a/hw/cxl/cxl-host.c > > +++ b/hw/cxl/cxl-host.c > > @@ -565,7 +565,7 @@ static void machine_set_cfmw(Object *obj, Visitor *= v, const char *name, > > > > void cxl_machine_init(Object *obj, CXLState *state) > > { > > - object_property_add(obj, "cxl", "bool", machine_get_cxl, > > + object_property_add_qapi(obj, "cxl", &bool_type_info, machine_get_= cxl, > > machine_set_cxl, NULL, state); > > object_property_set_description(obj, "cxl", > > "Set on/off to enable/disable " > > diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c > > index 1cf6f5df5505..0c90bcd723da 100644 > > --- a/hw/gpio/aspeed_gpio.c > > +++ b/hw/gpio/aspeed_gpio.c > > @@ -12,6 +12,7 @@ > > #include "hw/gpio/aspeed_gpio.h" > > #include "hw/misc/aspeed_scu.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/core/irq.h" > > #include "migration/vmstate.h" > > @@ -1481,7 +1482,7 @@ static void aspeed_gpio_init(Object *obj) > > int pin_idx =3D j % GPIOS_PER_GROUP; > > const char *group =3D &props->group_label[group_idx][0]; > > char *name =3D g_strdup_printf("gpio%s%d", group, pin_idx)= ; > > - object_property_add(obj, name, "bool", aspeed_gpio_get_pin= , > > + object_property_add_qapi(obj, name, &bool_type_info, aspee= d_gpio_get_pin, > > aspeed_gpio_set_pin, NULL, NULL); > > g_free(name); > > } > > @@ -1489,7 +1490,7 @@ static void aspeed_gpio_init(Object *obj) > > > > for (int i =3D 0; i < agc->nr_gpio_sets; i++) { > > g_autofree char *name =3D g_strdup_printf("gpio-set[%d]", i); > > - object_property_add(obj, name, "uint32", aspeed_gpio_get_set, > > + object_property_add_qapi(obj, name, &uint32_type_info, aspeed_= gpio_get_set, > > aspeed_gpio_set_set, NULL, NULL); > > } > > } > > diff --git a/hw/gpio/aspeed_sgpio.c b/hw/gpio/aspeed_sgpio.c > > index 7d2f73699520..67b0c10d79fa 100644 > > --- a/hw/gpio/aspeed_sgpio.c > > +++ b/hw/gpio/aspeed_sgpio.c > > @@ -11,6 +11,7 @@ > > #include "qemu/log.h" > > #include "qemu/error-report.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/core/irq.h" > > #include "hw/core/qdev-properties.h" > > @@ -300,7 +301,7 @@ static void aspeed_sgpio_init(Object *obj) > > { > > for (int i =3D 0; i < ASPEED_SGPIO_MAX_PIN_PAIR * 2; i++) { > > g_autofree char *name =3D g_strdup_printf("sgpio%03d", i); > > - object_property_add(obj, name, "bool", aspeed_sgpio_get_pin, > > + object_property_add_qapi(obj, name, &bool_type_info, aspeed_sg= pio_get_pin, > > aspeed_sgpio_set_pin, NULL, NULL); > > } > > } > > diff --git a/hw/gpio/stm32l4x5_gpio.c b/hw/gpio/stm32l4x5_gpio.c > > index 92fa397fbafe..d349d41e41a1 100644 > > --- a/hw/gpio/stm32l4x5_gpio.c > > +++ b/hw/gpio/stm32l4x5_gpio.c > > @@ -25,6 +25,7 @@ > > #include "hw/core/qdev-properties.h" > > #include "qapi/visitor.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "migration/vmstate.h" > > #include "trace.h" > > > > @@ -409,10 +410,10 @@ static void stm32l4x5_gpio_init(Object *obj) > > > > s->clk =3D qdev_init_clock_in(DEVICE(s), "clk", NULL, s, 0); > > > > - object_property_add(obj, "disconnected-pins", "uint16", > > + object_property_add_qapi(obj, "disconnected-pins", &uint16_type_in= fo, > > disconnected_pins_get, disconnected_pins_set, > > NULL, &s->disconnected_pins); > > - object_property_add(obj, "clock-freq-hz", "uint32", > > + object_property_add_qapi(obj, "clock-freq-hz", &uint32_type_info, > > clock_freq_get, NULL, NULL, NULL); > > } > > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > > index 18b5dc169ab7..24c4c589ed04 100644 > > --- a/hw/i386/pc.c > > +++ b/hw/i386/pc.c > > @@ -1720,7 +1720,7 @@ static void pc_machine_class_init(ObjectClass *oc= , const void *data) > > mc->default_ram_id =3D "pc.ram"; > > pcmc->default_smbios_ep_type =3D SMBIOS_ENTRY_POINT_TYPE_AUTO; > > > > - object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size", > > + object_class_property_add_qapi(oc, PC_MACHINE_MAX_RAM_BELOW_4G, &s= ize_type_info, > > pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_= 4g, > > NULL, NULL); > > object_class_property_set_description(oc, PC_MACHINE_MAX_RAM_BELOW= _4G, > > @@ -1758,13 +1758,13 @@ static void pc_machine_class_init(ObjectClass *= oc, const void *data) > > pc_machine_get_default_bus_bypass_iommu, > > pc_machine_set_default_bus_bypass_iommu); > > > > - object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size", > > + object_class_property_add_qapi(oc, PC_MACHINE_MAX_FW_SIZE, &size_t= ype_info, > > pc_machine_get_max_fw_size, pc_machine_set_max_fw_size, > > NULL, NULL); > > object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE, > > "Maximum combined firmware size"); > > > > - object_class_property_add(oc, PC_MACHINE_SMBIOS_EP, "str", > > + object_class_property_add_qapi(oc, PC_MACHINE_SMBIOS_EP, &str_type= _info, > > pc_machine_get_smbios_ep, pc_machine_set_smbios_ep, > > NULL, NULL); > > object_class_property_set_description(oc, PC_MACHINE_SMBIOS_EP, > > diff --git a/hw/i386/sgx-epc.c b/hw/i386/sgx-epc.c > > index d3fe10028c51..d9b9ab3f7a96 100644 > > --- a/hw/i386/sgx-epc.c > > +++ b/hw/i386/sgx-epc.c > > @@ -15,6 +15,7 @@ > > #include "hw/mem/memory-device.h" > > #include "hw/core/qdev-properties.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "target/i386/cpu.h" > > #include "system/address-spaces.h" > > @@ -43,7 +44,7 @@ static void sgx_epc_get_size(Object *obj, Visitor *v,= const char *name, > > > > static void sgx_epc_init(Object *obj) > > { > > - object_property_add(obj, SGX_EPC_SIZE_PROP, "uint64", sgx_epc_get_= size, > > + object_property_add_qapi(obj, SGX_EPC_SIZE_PROP, &uint64_type_info= , sgx_epc_get_size, > > NULL, NULL, NULL); > > } > > > > diff --git a/hw/i386/x86.c b/hw/i386/x86.c > > index 63f297a10532..d0c782ec8544 100644 > > --- a/hw/i386/x86.c > > +++ b/hw/i386/x86.c > > @@ -420,9 +420,9 @@ static void x86_machine_class_init(ObjectClass *oc,= const void *data) > > "in ACPI table header." > > "The string may be up to 8 b= ytes in size"); > > > > - object_class_property_add(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, "uin= t64_t", > > - x86_machine_get_bus_lock_ratelimit, > > - x86_machine_set_bus_lock_ratelimit, NU= LL, NULL); > > + object_class_property_add_qapi(oc, X86_MACHINE_BUS_LOCK_RATELIMIT,= &uint64_type_info, > > + x86_machine_get_bus_lock_ratelimit, > > + x86_machine_set_bus_lock_ratelimit,= NULL, NULL); > > object_class_property_set_description(oc, X86_MACHINE_BUS_LOCK_RAT= ELIMIT, > > "Set the ratelimit for the bus locks acquired in VMs"); > > > > diff --git a/hw/ide/ide-dev.c b/hw/ide/ide-dev.c > > index 5d478588c614..e2dd2439991f 100644 > > --- a/hw/ide/ide-dev.c > > +++ b/hw/ide/ide-dev.c > > @@ -19,6 +19,7 @@ > > > > #include "qemu/osdep.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-types-block.h" > > #include "qemu/error-report.h" > > #include "qemu/module.h" > > @@ -174,7 +175,7 @@ out: > > > > static void ide_dev_instance_init(Object *obj) > > { > > - object_property_add(obj, "bootindex", "int32", > > + object_property_add_qapi(obj, "bootindex", &int32_type_info, > > ide_dev_get_bootindex, > > ide_dev_set_bootindex, NULL, NULL); > > object_property_set_int(obj, "bootindex", -1, NULL); > > diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c > > index 0f0f37d45734..dc0517ceea90 100644 > > --- a/hw/intc/apic_common.c > > +++ b/hw/intc/apic_common.c > > @@ -22,6 +22,7 @@ > > #include "qemu/error-report.h" > > #include "qemu/module.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/i386/apic.h" > > #include "hw/i386/apic_internal.h" > > @@ -442,7 +443,7 @@ static void apic_common_initfn(Object *obj) > > APICCommonState *s =3D APIC_COMMON(obj); > > > > s->id =3D s->initial_apic_id =3D -1; > > - object_property_add(obj, "id", "uint32", > > + object_property_add_qapi(obj, "id", &uint32_type_info, > > apic_common_get_id, > > apic_common_set_id, NULL, NULL); > > } > > diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c > > index 750ce2dbe5fc..209a0feddd80 100644 > > --- a/hw/loongarch/virt.c > > +++ b/hw/loongarch/virt.c > > @@ -1520,7 +1520,7 @@ static void virt_class_init(ObjectClass *oc, cons= t void *data) > > object_class_property_set_description(oc, "highmem-mmio", > > "Set on/off to enable/disabl= e high " > > "memory region for PCI MMIO"= ); > > - object_class_property_add(oc, "highmem-mmio-size", "size", > > + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type= _info, > > virt_get_highmem_mmio_size, > > virt_set_highmem_mmio_size, > > NULL, NULL); > > diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c > > index cf8a4d8c5f2a..123ddc938546 100644 > > --- a/hw/mem/nvdimm.c > > +++ b/hw/mem/nvdimm.c > > @@ -26,6 +26,7 @@ > > #include "qemu/module.h" > > #include "qemu/pmem.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/mem/nvdimm.h" > > #include "hw/core/qdev-properties.h" > > @@ -99,9 +100,9 @@ static void nvdimm_set_uuid(Object *obj, Visitor *v,= const char *name, > > > > static void nvdimm_init(Object *obj) > > { > > - object_property_add(obj, NVDIMM_LABEL_SIZE_PROP, "size", > > - nvdimm_get_label_size, nvdimm_set_label_size, = NULL, > > - NULL); > > + object_property_add_qapi(obj, NVDIMM_LABEL_SIZE_PROP, &size_type_i= nfo, > > + nvdimm_get_label_size, nvdimm_set_label_s= ize, NULL, > > + NULL); > > > > object_property_add(obj, NVDIMM_UUID_PROP, "QemuUUID", nvdimm_get_= uuid, > > nvdimm_set_uuid, NULL, NULL); > > diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c > > index 68862926ee2d..ee586ecc0c7d 100644 > > --- a/hw/mem/pc-dimm.c > > +++ b/hw/mem/pc-dimm.c > > @@ -26,6 +26,7 @@ > > #include "hw/mem/nvdimm.h" > > #include "hw/mem/memory-device.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > #include "system/hostmem.h" > > @@ -176,7 +177,7 @@ static void pc_dimm_get_size(Object *obj, Visitor *= v, const char *name, > > > > static void pc_dimm_init(Object *obj) > > { > > - object_property_add(obj, PC_DIMM_SIZE_PROP, "uint64", pc_dimm_get_= size, > > + object_property_add_qapi(obj, PC_DIMM_SIZE_PROP, &uint64_type_info= , pc_dimm_get_size, > > NULL, NULL, NULL); > > } > > > > diff --git a/hw/misc/aspeed_lpc.c b/hw/misc/aspeed_lpc.c > > index 7f7e4f1a0985..e2d9b7572f27 100644 > > --- a/hw/misc/aspeed_lpc.c > > +++ b/hw/misc/aspeed_lpc.c > > @@ -12,6 +12,7 @@ > > #include "qemu/error-report.h" > > #include "hw/misc/aspeed_lpc.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/core/irq.h" > > #include "hw/core/qdev-properties.h" > > @@ -417,30 +418,54 @@ static void aspeed_lpc_realize(DeviceState *dev, = Error **errp) > > > > static void aspeed_lpc_init(Object *obj) > > { > > - object_property_add(obj, "idr1", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "odr1", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "str1", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "idr2", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "odr2", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "str2", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "idr3", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "odr3", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "str3", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "idr4", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "odr4", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > - object_property_add(obj, "str4", "uint32", aspeed_kcs_get_register= _property, > > - aspeed_kcs_set_register_property, NULL, NULL); > > + object_property_add_qapi(obj, "idr1", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "odr1", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "str1", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "idr2", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "odr2", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "str2", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "idr3", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "odr3", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "str3", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "idr4", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "odr4", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > + object_property_add_qapi(obj, "str4", &uint32_type_info, > > + aspeed_kcs_get_register_property, > > + aspeed_kcs_set_register_property, > > + NULL, NULL); > > } > > > > static const VMStateDescription vmstate_aspeed_lpc =3D { > > diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c > > index f8fbaebee6ab..d096cc88f5c5 100644 > > --- a/hw/misc/aspeed_sdmc.c > > +++ b/hw/misc/aspeed_sdmc.c > > @@ -15,6 +15,7 @@ > > #include "hw/core/qdev-properties.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "trace.h" > > #include "qemu/units.h" > > #include "qemu/cutils.h" > > @@ -259,7 +260,7 @@ static void aspeed_sdmc_set_ram_size(Object *obj, V= isitor *v, const char *name, > > > > static void aspeed_sdmc_initfn(Object *obj) > > { > > - object_property_add(obj, "ram-size", "int", > > + object_property_add_qapi(obj, "ram-size", &int_type_info, > > aspeed_sdmc_get_ram_size, aspeed_sdmc_set_ram_= size, > > NULL, NULL); > > } > > diff --git a/hw/misc/npcm7xx_mft.c b/hw/misc/npcm7xx_mft.c > > index 742166c4e828..99e9e49788c0 100644 > > --- a/hw/misc/npcm7xx_mft.c > > +++ b/hw/misc/npcm7xx_mft.c > > @@ -23,6 +23,7 @@ > > #include "hw/core/registerfields.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/bitops.h" > > #include "qemu/error-report.h" > > @@ -491,7 +492,7 @@ static void npcm7xx_mft_init(Object *obj) > > s->clock_2 =3D qdev_init_clock_out(dev, "clock2"); > > > > for (int i =3D 0; i < NPCM7XX_PWM_PER_MODULE; ++i) { > > - object_property_add(obj, "max_rpm[*]", "uint32", > > + object_property_add_qapi(obj, "max_rpm[*]", &uint32_type_info, > > npcm7xx_mft_get_max_rpm, > > npcm7xx_mft_set_max_rpm, > > NULL, &s->max_rpm[i]); > > diff --git a/hw/net/ne2000-isa.c b/hw/net/ne2000-isa.c > > index 673c785abc94..63e0d40ee726 100644 > > --- a/hw/net/ne2000-isa.c > > +++ b/hw/net/ne2000-isa.c > > @@ -29,6 +29,7 @@ > > #include "ne2000.h" > > #include "system/system.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > #include "qom/object.h" > > @@ -131,7 +132,7 @@ out: > > > > static void isa_ne2000_instance_init(Object *obj) > > { > > - object_property_add(obj, "bootindex", "int32", > > + object_property_add_qapi(obj, "bootindex", &int32_type_info, > > isa_ne2000_get_bootindex, > > isa_ne2000_set_bootindex, NULL, NULL); > > object_property_set_int(obj, "bootindex", -1, NULL); > > diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c > > index 4893cf7e7418..e4549aa9e534 100644 > > --- a/hw/nvme/ctrl.c > > +++ b/hw/nvme/ctrl.c > > @@ -203,6 +203,7 @@ > > #include "qemu/units.h" > > #include "qemu/range.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "system/system.h" > > #include "system/block-backend.h" > > @@ -10578,7 +10579,7 @@ static void nvme_instance_init(Object *obj) > > "bootindex", "/namespace@1,0", > > DEVICE(obj)); > > > > - object_property_add(obj, "smart_critical_warning", "uint8", > > + object_property_add_qapi(obj, "smart_critical_warning", &uint8_typ= e_info, > > nvme_get_smart_warning, > > nvme_set_smart_warning, NULL, NULL); > > } > > diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_ex= pander_bridge.c > > index 40ffbc4e0821..9bb7d3c9debe 100644 > > --- a/hw/pci-bridge/pci_expander_bridge.c > > +++ b/hw/pci-bridge/pci_expander_bridge.c > > @@ -12,6 +12,7 @@ > > > > #include "qemu/osdep.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "hw/pci/pci.h" > > #include "hw/pci/pci_bus.h" > > #include "hw/pci/pci_host.h" > > @@ -103,7 +104,7 @@ static void pxb_bus_class_init(ObjectClass *class, = const void *data) > > pbc->bus_num =3D pxb_bus_num; > > pbc->numa_node =3D pxb_bus_numa_node; > > > > - object_class_property_add(class, "acpi_uid", "uint32", > > + object_class_property_add_qapi(class, "acpi_uid", &uint32_type_inf= o, > > prop_pxb_uid_get, NULL, NULL, NULL); > > object_class_property_set_description(class, "acpi_uid", > > "ACPI Unique ID used to distinguish this PCI Host Bridge / ACP= I00016"); > > diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c > > index c1982f7962a6..feafa6a72fe4 100644 > > --- a/hw/pci-host/i440fx.c > > +++ b/hw/pci-host/i440fx.c > > @@ -32,6 +32,7 @@ > > #include "hw/core/qdev-properties.h" > > #include "hw/core/sysbus.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "migration/vmstate.h" > > #include "qapi/visitor.h" > > #include "qemu/error-report.h" > > @@ -387,21 +388,25 @@ static void i440fx_pcihost_class_init(ObjectClass= *klass, const void *data) > > /* Reason: needs to be wired up by pc_init1 */ > > dc->user_creatable =3D false; > > > > - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_START, "ui= nt32", > > - i440fx_pcihost_get_pci_hole_start, > > - NULL, NULL, NULL); > > + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_START= , > > + &uint32_type_info, > > + i440fx_pcihost_get_pci_hole_start, > > + NULL, NULL, NULL); > > > > - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_END, "uint= 32", > > - i440fx_pcihost_get_pci_hole_end, > > - NULL, NULL, NULL); > > + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_END, > > + &uint32_type_info, > > + i440fx_pcihost_get_pci_hole_end, > > + NULL, NULL, NULL); > > > > - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_START, "= uint64", > > - i440fx_pcihost_get_pci_hole64_start, > > - NULL, NULL, NULL); > > + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_STA= RT, > > + &uint64_type_info, > > + i440fx_pcihost_get_pci_hole64_start= , > > + NULL, NULL, NULL); > > > > - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_END, "ui= nt64", > > - i440fx_pcihost_get_pci_hole64_end, > > - NULL, NULL, NULL); > > + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_END= , > > + &uint64_type_info, > > + i440fx_pcihost_get_pci_hole64_end, > > + NULL, NULL, NULL); > > } > > > > static const TypeInfo i440fx_pcihost_info =3D { > > diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c > > index db061c134e95..667e9585ab8f 100644 > > --- a/hw/pci-host/pnv_phb3.c > > +++ b/hw/pci-host/pnv_phb3.c > > @@ -11,6 +11,7 @@ > > #include "qemu/bswap.h" > > #include "qapi/visitor.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "hw/pci-host/pnv_phb3_regs.h" > > #include "hw/pci-host/pnv_phb.h" > > #include "hw/pci-host/pnv_phb3.h" > > @@ -1164,12 +1165,12 @@ static void pnv_phb3_root_bus_class_init(Object= Class *klass, const void *data) > > { > > BusClass *k =3D BUS_CLASS(klass); > > > > - object_class_property_add(klass, "phb-id", "uint32", > > + object_class_property_add_qapi(klass, "phb-id", &uint32_type_info, > > pnv_phb3_root_bus_get_prop, > > pnv_phb3_root_bus_set_prop, > > NULL, NULL); > > > > - object_class_property_add(klass, "chip-id", "uint32", > > + object_class_property_add_qapi(klass, "chip-id", &uint32_type_info= , > > pnv_phb3_root_bus_get_prop, > > pnv_phb3_root_bus_set_prop, > > NULL, NULL); > > diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c > > index 9acaf4c0c2f5..96c2f89f889b 100644 > > --- a/hw/pci-host/pnv_phb4.c > > +++ b/hw/pci-host/pnv_phb4.c > > @@ -11,6 +11,7 @@ > > #include "qemu/bswap.h" > > #include "qapi/visitor.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "target/ppc/cpu.h" > > #include "hw/pci-host/pnv_phb4_regs.h" > > #include "hw/pci-host/pnv_phb4.h" > > @@ -1761,12 +1762,12 @@ static void pnv_phb4_root_bus_class_init(Object= Class *klass, const void *data) > > { > > BusClass *k =3D BUS_CLASS(klass); > > > > - object_class_property_add(klass, "phb-id", "uint32", > > + object_class_property_add_qapi(klass, "phb-id", &uint32_type_info, > > pnv_phb4_root_bus_get_prop, > > pnv_phb4_root_bus_set_prop, > > NULL, NULL); > > > > - object_class_property_add(klass, "chip-id", "uint32", > > + object_class_property_add_qapi(klass, "chip-id", &uint32_type_info= , > > pnv_phb4_root_bus_get_prop, > > pnv_phb4_root_bus_set_prop, > > NULL, NULL); > > diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c > > index f4556ad03a04..6eba30e06811 100644 > > --- a/hw/pci-host/q35.c > > +++ b/hw/pci-host/q35.c > > @@ -35,6 +35,7 @@ > > #include "hw/core/qdev-properties.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > > > @@ -226,19 +227,19 @@ static void q35_host_initfn(Object *obj) > > qdev_prop_set_uint64(DEVICE(s), PCI_HOST_PROP_PCI_HOLE64_SIZE, > > Q35_PCI_HOST_HOLE64_SIZE_DEFAULT); > > > > - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32", > > + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_START, &uint3= 2_type_info, > > q35_host_get_pci_hole_start, > > NULL, NULL, NULL); > > > > - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "uint32", > > + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_END, &uint32_= type_info, > > q35_host_get_pci_hole_end, > > NULL, NULL, NULL); > > > > - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "uint64", > > + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_START, &uin= t64_type_info, > > q35_host_get_pci_hole64_start, > > NULL, NULL, NULL); > > > > - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "uint64", > > + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_END, &uint6= 4_type_info, > > q35_host_get_pci_hole64_end, > > NULL, NULL, NULL); > > > > diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c > > index 5c2150b71c86..64f9ca29b02e 100644 > > --- a/hw/ppc/spapr_drc.c > > +++ b/hw/ppc/spapr_drc.c > > @@ -12,6 +12,7 @@ > > > > #include "qemu/osdep.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qobject/qnull.h" > > #include "qemu/cutils.h" > > #include "hw/ppc/spapr_drc.h" > > @@ -584,7 +585,7 @@ static void spapr_dr_connector_instance_init(Object= *obj) > > SpaprDrcClass *drck =3D SPAPR_DR_CONNECTOR_GET_CLASS(drc); > > > > object_property_add_uint32_ptr(obj, "id", &drc->id, OBJ_PROP_FLAG_= READ); > > - object_property_add(obj, "index", "uint32", prop_get_index, > > + object_property_add_qapi(obj, "index", &uint32_type_info, prop_get= _index, > > NULL, NULL, NULL); > > object_property_add(obj, "fdt", "struct", prop_get_fdt, > > NULL, NULL, NULL); > > diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c > > index 60bb96da0161..cf3974577463 100644 > > --- a/hw/riscv/microchip_pfsoc.c > > +++ b/hw/riscv/microchip_pfsoc.c > > @@ -39,6 +39,7 @@ > > #include "qemu/units.h" > > #include "qemu/cutils.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/core/boards.h" > > #include "hw/core/loader.h" > > @@ -741,7 +742,7 @@ static void microchip_icicle_kit_machine_class_init= (ObjectClass *oc, > > */ > > mc->default_ram_size =3D 1537 * MiB; > > > > - object_class_property_add(oc, "clint-timebase-frequency", "uint32_= t", > > + object_class_property_add_qapi(oc, "clint-timebase-frequency", &ui= nt32_type_info, > > microchip_icicle_kit_get_clint_timebase_= freq, > > microchip_icicle_kit_set_clint_timebase_= freq, > > NULL, NULL); > > diff --git a/hw/s390x/sclpcpi.c b/hw/s390x/sclpcpi.c > > index ec4bdf23509b..97d37ae4b932 100644 > > --- a/hw/s390x/sclpcpi.c > > +++ b/hw/s390x/sclpcpi.c > > @@ -53,6 +53,7 @@ > > #include "qemu/timer.h" > > #include "hw/s390x/event-facility.h" > > #include "hw/s390x/ebcdic.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-visit-machine.h" > > #include "qapi/qapi-events-machine-s390x.h" > > #include "migration/vmstate.h" > > @@ -195,12 +196,13 @@ static void cpi_class_init(ObjectClass *klass, co= nst void *data) > > "name of the cluster which the VM belongs to, if any" > > " e.g. \"PLEX \""); > > > > - object_class_property_add(klass, "system_level", "uint64", get_sys= tem_level, > > - NULL, NULL, NULL); > > + object_class_property_add_qapi(klass, "system_level", > > + &uint64_type_info, get_system_level= , > > + NULL, NULL, NULL); > > object_class_property_set_description(klass, "system_level", > > "distribution and kernel version in Linux e.g. 74872343805= 430528"); > > > > - object_class_property_add(klass, "timestamp", "uint64", get_timest= amp, > > + object_class_property_add_qapi(klass, "timestamp", &uint64_type_in= fo, get_timestamp, > > NULL, NULL, NULL); > > object_class_property_set_description(klass, "timestamp", > > "latest update of CPI data in nanoseconds since the UNIX E= POCH"); > > diff --git a/hw/s390x/virtio-ccw-mem.c b/hw/s390x/virtio-ccw-mem.c > > index dea30aacfb32..046dfd544cf3 100644 > > --- a/hw/s390x/virtio-ccw-mem.c > > +++ b/hw/s390x/virtio-ccw-mem.c > > @@ -13,6 +13,7 @@ > > #include "qemu/osdep.h" > > #include "hw/core/qdev-properties.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qemu/module.h" > > #include "virtio-ccw-mem.h" > > #include "hw/mem/memory-device.h" > > @@ -205,7 +206,7 @@ static void virtio_ccw_mem_instance_init(Object *ob= j) > > OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZ= E_PROP); > > object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->= vdev), > > VIRTIO_MEM_SIZE_PROP); > > - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", > > + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &siz= e_type_info, > > virtio_ccw_mem_get_requested_size, > > virtio_ccw_mem_set_requested_size, NULL, NULL)= ; > > } > > diff --git a/hw/sensor/adc128d818.c b/hw/sensor/adc128d818.c > > index c65508cba144..b0f93e28d19f 100644 > > --- a/hw/sensor/adc128d818.c > > +++ b/hw/sensor/adc128d818.c > > @@ -8,6 +8,7 @@ > > > > #include "qemu/osdep.h" > > #include "qemu/log.h" > > +#include "qapi-builtin-type-infos.h" > > #include "qapi/error.h" > > #include "qapi/visitor.h" > > #include "qom/object.h" > > @@ -642,15 +643,18 @@ static void adc128d818_initfn(Object *obj) > > for (unsigned ch =3D 0u; ch < ADC128D818_NUM_CHANNELS; ch++) { > > char *name =3D g_strdup_printf("ain%u", ch); > > > > - object_property_add(obj, name, "int", adc128d818_get_ain, > > - adc128d818_set_ain, NULL, NULL); > > + object_property_add_qapi(obj, name, &int_type_info, > > + adc128d818_get_ain, > > + adc128d818_set_ain, NULL, NULL); > > g_free(name); > > } > > > > - object_property_add(obj, "temperature", "int", adc128d818_get_temp= erature, > > - adc128d818_set_temperature, NULL, NULL); > > - object_property_add(obj, "ext-vref-mv", "int", adc128d818_get_ext_= vref, > > - adc128d818_set_ext_vref, NULL, NULL); > > + object_property_add_qapi(obj, "temperature", &int_type_info, > > + adc128d818_get_temperature, > > + adc128d818_set_temperature, NULL, NULL); > > + object_property_add_qapi(obj, "ext-vref-mv", &int_type_info, > > + adc128d818_get_ext_vref, > > + adc128d818_set_ext_vref, NULL, NULL); > > } > > > > static void adc128d818_realize(DeviceState *dev, Error **errp) > > diff --git a/hw/sensor/adm1266.c b/hw/sensor/adm1266.c > > index 37d1cffd57a9..62f563af7a7a 100644 > > --- a/hw/sensor/adm1266.c > > +++ b/hw/sensor/adm1266.c > > @@ -14,6 +14,7 @@ > > #include "hw/core/irq.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/log.h" > > #include "qemu/module.h" > > @@ -217,7 +218,7 @@ static void adm1266_init(Object *obj) > > for (int i =3D 0; i < ADM1266_NUM_PAGES; i++) { > > pmbus_page_config(pmdev, i, flags); > > > > - object_property_add(obj, "vout[*]", "uint16", > > + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, > > adm1266_get, > > adm1266_set, NULL, &pmdev->pages[i].read_v= out); > > } > > diff --git a/hw/sensor/adm1272.c b/hw/sensor/adm1272.c > > index 0aa2a8655683..e1c1bf1c54de 100644 > > --- a/hw/sensor/adm1272.c > > +++ b/hw/sensor/adm1272.c > > @@ -12,6 +12,7 @@ > > #include "hw/core/irq.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/log.h" > > #include "qemu/module.h" > > @@ -493,19 +494,19 @@ static void adm1272_init(Object *obj) > > > > pmbus_page_config(pmdev, 0, flags); > > > > - object_property_add(obj, "vin", "uint16", > > + object_property_add_qapi(obj, "vin", &uint16_type_info, > > adm1272_get, > > adm1272_set, NULL, &pmdev->pages[0].read_vin); > > > > - object_property_add(obj, "vout", "uint16", > > + object_property_add_qapi(obj, "vout", &uint16_type_info, > > adm1272_get, > > adm1272_set, NULL, &pmdev->pages[0].read_vout)= ; > > > > - object_property_add(obj, "iout", "uint16", > > + object_property_add_qapi(obj, "iout", &uint16_type_info, > > adm1272_get, > > adm1272_set, NULL, &pmdev->pages[0].read_iout)= ; > > > > - object_property_add(obj, "pin", "uint16", > > + object_property_add_qapi(obj, "pin", &uint16_type_info, > > adm1272_get, > > adm1272_set, NULL, &pmdev->pages[0].read_pin); > > > > diff --git a/hw/sensor/emc141x.c b/hw/sensor/emc141x.c > > index a51fc44395ab..5efe94643ca0 100644 > > --- a/hw/sensor/emc141x.c > > +++ b/hw/sensor/emc141x.c > > @@ -22,6 +22,7 @@ > > #include "hw/i2c/i2c.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > #include "qom/object.h" > > @@ -251,16 +252,16 @@ static void emc141x_reset(DeviceState *dev) > > > > static void emc141x_initfn(Object *obj) > > { > > - object_property_add(obj, "temperature0", "int", > > + object_property_add_qapi(obj, "temperature0", &int_type_info, > > emc141x_get_temperature, > > emc141x_set_temperature, NULL, NULL); > > - object_property_add(obj, "temperature1", "int", > > + object_property_add_qapi(obj, "temperature1", &int_type_info, > > emc141x_get_temperature, > > emc141x_set_temperature, NULL, NULL); > > - object_property_add(obj, "temperature2", "int", > > + object_property_add_qapi(obj, "temperature2", &int_type_info, > > emc141x_get_temperature, > > emc141x_set_temperature, NULL, NULL); > > - object_property_add(obj, "temperature3", "int", > > + object_property_add_qapi(obj, "temperature3", &int_type_info, > > emc141x_get_temperature, > > emc141x_set_temperature, NULL, NULL); > > } > > diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c > > index 0fad04def773..8923e9e87510 100644 > > --- a/hw/sensor/isl_pmbus_vr.c > > +++ b/hw/sensor/isl_pmbus_vr.c > > @@ -9,6 +9,7 @@ > > #include "qemu/osdep.h" > > #include "hw/sensor/isl_pmbus_vr.h" > > #include "hw/core/qdev-properties.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/log.h" > > #include "qemu/module.h" > > @@ -136,63 +137,63 @@ static void isl_pmbus_vr_add_props(Object *obj, u= int64_t *flags, uint8_t pages) > > PMBusDevice *pmdev =3D PMBUS_DEVICE(obj); > > for (int i =3D 0; i < pages; i++) { > > if (flags[i] & PB_HAS_VIN) { > > - object_property_add(obj, "vin[*]", "uint16", > > + object_property_add_qapi(obj, "vin[*]", &uint16_type_info, > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_vin); > > } > > > > if (flags[i] & PB_HAS_VOUT) { > > - object_property_add(obj, "vout[*]", "uint16", > > + object_property_add_qapi(obj, "vout[*]", &uint16_type_info= , > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_vout); > > } > > > > if (flags[i] & PB_HAS_IIN) { > > - object_property_add(obj, "iin[*]", "uint16", > > + object_property_add_qapi(obj, "iin[*]", &uint16_type_info, > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_iin); > > } > > > > if (flags[i] & PB_HAS_IOUT) { > > - object_property_add(obj, "iout[*]", "uint16", > > + object_property_add_qapi(obj, "iout[*]", &uint16_type_info= , > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_iout); > > } > > > > if (flags[i] & PB_HAS_PIN) { > > - object_property_add(obj, "pin[*]", "uint16", > > + object_property_add_qapi(obj, "pin[*]", &uint16_type_info, > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_pin); > > } > > > > if (flags[i] & PB_HAS_POUT) { > > - object_property_add(obj, "pout[*]", "uint16", > > + object_property_add_qapi(obj, "pout[*]", &uint16_type_info= , > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_pout); > > } > > > > if (flags[i] & PB_HAS_TEMPERATURE) { > > - object_property_add(obj, "temp1[*]", "uint16", > > + object_property_add_qapi(obj, "temp1[*]", &uint16_type_inf= o, > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_temperatur= e_1); > > } > > > > if (flags[i] & PB_HAS_TEMP2) { > > - object_property_add(obj, "temp2[*]", "uint16", > > + object_property_add_qapi(obj, "temp2[*]", &uint16_type_inf= o, > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_temperatur= e_2); > > } > > > > if (flags[i] & PB_HAS_TEMP3) { > > - object_property_add(obj, "temp3[*]", "uint16", > > + object_property_add_qapi(obj, "temp3[*]", &uint16_type_inf= o, > > isl_pmbus_vr_get, > > isl_pmbus_vr_set, > > NULL, &pmdev->pages[i].read_temperatur= e_3); > > diff --git a/hw/sensor/lsm303dlhc_mag.c b/hw/sensor/lsm303dlhc_mag.c > > index cd5773ae64e8..c8085739ca47 100644 > > --- a/hw/sensor/lsm303dlhc_mag.c > > +++ b/hw/sensor/lsm303dlhc_mag.c > > @@ -25,6 +25,7 @@ > > #include "hw/i2c/i2c.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > #include "qemu/log.h" > > @@ -509,19 +510,19 @@ static void lsm303dlhc_mag_reset(DeviceState *dev= ) > > */ > > static void lsm303dlhc_mag_initfn(Object *obj) > > { > > - object_property_add(obj, "mag-x", "int", > > + object_property_add_qapi(obj, "mag-x", &int_type_info, > > lsm303dlhc_mag_get_x, > > lsm303dlhc_mag_set_x, NULL, NULL); > > > > - object_property_add(obj, "mag-y", "int", > > + object_property_add_qapi(obj, "mag-y", &int_type_info, > > lsm303dlhc_mag_get_y, > > lsm303dlhc_mag_set_y, NULL, NULL); > > > > - object_property_add(obj, "mag-z", "int", > > + object_property_add_qapi(obj, "mag-z", &int_type_info, > > lsm303dlhc_mag_get_z, > > lsm303dlhc_mag_set_z, NULL, NULL); > > > > - object_property_add(obj, "temperature", "int", > > + object_property_add_qapi(obj, "temperature", &int_type_info, > > lsm303dlhc_mag_get_temperature, > > lsm303dlhc_mag_set_temperature, NULL, NULL); > > } > > diff --git a/hw/sensor/max34451.c b/hw/sensor/max34451.c > > index 4d64434f3af4..3c8fa3d4a861 100644 > > --- a/hw/sensor/max34451.c > > +++ b/hw/sensor/max34451.c > > @@ -11,6 +11,7 @@ > > #include "hw/core/irq.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/log.h" > > #include "qemu/module.h" > > @@ -727,7 +728,7 @@ static void max34451_init(Object *obj) > > > > /* get and set the voltage in millivolts, max is 32767 mV */ > > for (int i =3D 0; i < MAX34451_NUM_PWR_DEVICES; i++) { > > - object_property_add(obj, "vout[*]", "uint16", > > + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, > > max34451_get, > > max34451_set, NULL, &pmdev->pages[i].read_= vout); > > } > > @@ -737,7 +738,7 @@ static void max34451_init(Object *obj) > > * centidegrees Celsius i.e.: 2500 -> 25.00 C, max is 327.67 C > > */ > > for (int i =3D 0; i < MAX34451_NUM_TEMP_DEVICES; i++) { > > - object_property_add(obj, "temperature[*]", "uint16", > > + object_property_add_qapi(obj, "temperature[*]", &uint16_type_i= nfo, > > max34451_get, > > max34451_set, > > NULL, > > diff --git a/hw/sensor/tmp105.c b/hw/sensor/tmp105.c > > index c5089d74f4bf..ce4ff4856afb 100644 > > --- a/hw/sensor/tmp105.c > > +++ b/hw/sensor/tmp105.c > > @@ -24,6 +24,7 @@ > > #include "migration/vmstate.h" > > #include "hw/sensor/tmp105.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > #include "hw/core/registerfields.h" > > @@ -308,7 +309,7 @@ static void tmp105_realize(DeviceState *dev, Error = **errp) > > > > static void tmp105_initfn(Object *obj) > > { > > - object_property_add(obj, "temperature", "int", > > + object_property_add_qapi(obj, "temperature", &int_type_info, > > tmp105_get_temperature, > > tmp105_set_temperature, NULL, NULL); > > } > > diff --git a/hw/sensor/tmp421.c b/hw/sensor/tmp421.c > > index 127edd0ba568..60844e76b21f 100644 > > --- a/hw/sensor/tmp421.c > > +++ b/hw/sensor/tmp421.c > > @@ -28,6 +28,7 @@ > > #include "hw/i2c/i2c.h" > > #include "migration/vmstate.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > #include "qom/object.h" > > @@ -350,16 +351,16 @@ static void tmp421_class_init(ObjectClass *klass,= const void *data) > > dc->vmsd =3D &vmstate_tmp421; > > sc->dev =3D (DeviceInfo *) data; > > > > - object_class_property_add(klass, "temperature0", "int", > > + object_class_property_add_qapi(klass, "temperature0", &int_type_in= fo, > > tmp421_get_temperature, > > tmp421_set_temperature, NULL, NULL); > > - object_class_property_add(klass, "temperature1", "int", > > + object_class_property_add_qapi(klass, "temperature1", &int_type_in= fo, > > tmp421_get_temperature, > > tmp421_set_temperature, NULL, NULL); > > - object_class_property_add(klass, "temperature2", "int", > > + object_class_property_add_qapi(klass, "temperature2", &int_type_in= fo, > > tmp421_get_temperature, > > tmp421_set_temperature, NULL, NULL); > > - object_class_property_add(klass, "temperature3", "int", > > + object_class_property_add_qapi(klass, "temperature3", &int_type_in= fo, > > tmp421_get_temperature, > > tmp421_set_temperature, NULL, NULL); > > } > > diff --git a/hw/usb/dev-storage-classic.c b/hw/usb/dev-storage-classic.= c > > index 977151c4a087..06584092bcae 100644 > > --- a/hw/usb/dev-storage-classic.c > > +++ b/hw/usb/dev-storage-classic.c > > @@ -9,6 +9,7 @@ > > > > #include "qemu/osdep.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/usb/usb.h" > > #include "hw/usb/desc.h" > > @@ -122,7 +123,7 @@ out: > > > > static void usb_msd_instance_init(Object *obj) > > { > > - object_property_add(obj, "bootindex", "int32", > > + object_property_add_qapi(obj, "bootindex", &int32_type_info, > > usb_msd_get_bootindex, > > usb_msd_set_bootindex, NULL, NULL); > > object_property_set_int(obj, "bootindex", -1, NULL); > > diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c > > index 4c5f486ba238..9e43948128f7 100644 > > --- a/hw/virtio/virtio-balloon.c > > +++ b/hw/virtio/virtio-balloon.c > > @@ -27,6 +27,7 @@ > > #include "hw/virtio/virtio-balloon.h" > > #include "system/address-spaces.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-events-machine.h" > > #include "qapi/visitor.h" > > #include "trace.h" > > @@ -1022,7 +1023,7 @@ static void virtio_balloon_instance_init(Object *= obj) > > object_property_add(obj, "guest-stats", "guest statistics", > > balloon_stats_get_all, NULL, NULL, NULL); > > > > - object_property_add(obj, "guest-stats-polling-interval", "int", > > + object_property_add_qapi(obj, "guest-stats-polling-interval", &int= _type_info, > > balloon_stats_get_poll_interval, > > balloon_stats_set_poll_interval, > > NULL, NULL); > > diff --git a/hw/virtio/virtio-mem-pci.c b/hw/virtio/virtio-mem-pci.c > > index f592eb1a7849..80e9bfedd9f5 100644 > > --- a/hw/virtio/virtio-mem-pci.c > > +++ b/hw/virtio/virtio-mem-pci.c > > @@ -14,6 +14,7 @@ > > #include "virtio-mem-pci.h" > > #include "hw/mem/memory-device.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-events-machine.h" > > #include "qapi/qapi-events-misc.h" > > > > @@ -211,7 +212,7 @@ static void virtio_mem_pci_instance_init(Object *ob= j) > > OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZ= E_PROP); > > object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->= vdev), > > VIRTIO_MEM_SIZE_PROP); > > - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", > > + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &siz= e_type_info, > > virtio_mem_pci_get_requested_size, > > virtio_mem_pci_set_requested_size, NULL, NULL)= ; > > } > > diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c > > index 7130ed852d9c..42dc028e3bdc 100644 > > --- a/hw/virtio/virtio-mem.c > > +++ b/hw/virtio/virtio-mem.c > > @@ -26,6 +26,7 @@ > > #include "hw/virtio/virtio-bus.h" > > #include "hw/virtio/virtio-mem.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "migration/misc.h" > > #include "hw/core/boards.h" > > @@ -1533,14 +1534,15 @@ static void virtio_mem_instance_init(Object *ob= j) > > > > notifier_list_init(&vmem->size_change_notifiers); > > > > - object_property_add(obj, VIRTIO_MEM_SIZE_PROP, "size", virtio_mem_= get_size, > > - NULL, NULL, NULL); > > - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", > > - virtio_mem_get_requested_size, > > - virtio_mem_set_requested_size, NULL, NULL); > > - object_property_add(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, "size", > > - virtio_mem_get_block_size, virtio_mem_set_bloc= k_size, > > - NULL, NULL); > > + object_property_add_qapi(obj, VIRTIO_MEM_SIZE_PROP, &size_type_inf= o, > > + virtio_mem_get_size, > > + NULL, NULL, NULL); > > + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &siz= e_type_info, > > + virtio_mem_get_requested_size, > > + virtio_mem_set_requested_size, NULL, NULL= ); > > + object_property_add_qapi(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, &size_ty= pe_info, > > + virtio_mem_get_block_size, virtio_mem_set= _block_size, > > + NULL, NULL); > > } > > > > static void virtio_mem_instance_finalize(Object *obj) > > diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c > > index cca37202ffb2..7b4fd933a8fb 100644 > > --- a/hw/xen/xen-pvh-common.c > > +++ b/hw/xen/xen-pvh-common.c > > @@ -9,6 +9,7 @@ > > #include "qemu/osdep.h" > > #include "qemu/error-report.h" > > #include "qemu/units.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "hw/core/boards.h" > > #include "hw/core/irq.h" > > @@ -413,7 +414,7 @@ void xen_pvh_class_setup_common_props(XenPVHMachine= Class *xpc) > > > > #define OC_MEMMAP_PROP_BASE(c, prop_name, name) = \ > > do { = \ > > - object_class_property_add(c, prop_name "-base", "uint64_t", = \ > > + object_class_property_add_qapi(c, prop_name "-base", &uint64_type_= info,\ > > xen_pvh_get_ ## name ## _base, = \ > > xen_pvh_set_ ## name ## _base, NULL, NUL= L); \ > > object_class_property_set_description(oc, prop_name "-base", = \ > > @@ -422,7 +423,7 @@ do { = \ > > > > #define OC_MEMMAP_PROP_SIZE(c, prop_name, name) = \ > > do { = \ > > - object_class_property_add(c, prop_name "-size", "uint64_t", = \ > > + object_class_property_add_qapi(c, prop_name "-size", &size_type_in= fo, \ > > xen_pvh_get_ ## name ## _size, = \ > > xen_pvh_set_ ## name ## _size, NULL, NUL= L); \ > > object_class_property_set_description(oc, prop_name "-size", = \ > > @@ -458,7 +459,7 @@ do { = \ > > OC_MEMMAP_PROP(oc, "pci-mmio", pci_mmio); > > OC_MEMMAP_PROP(oc, "pci-mmio-high", pci_mmio_high); > > > > - object_class_property_add(oc, "pci-intx-irq-base", "uint32_t", > > + object_class_property_add_qapi(oc, "pci-intx-irq-base", &uint3= 2_type_info, > > xen_pvh_get_pci_intx_irq_base, > > xen_pvh_set_pci_intx_irq_base, > > NULL, NULL); > > @@ -468,7 +469,7 @@ do { = \ > > > > #ifdef CONFIG_TPM > > if (xpc->has_tpm) { > > - object_class_property_add(oc, "tpm-base-addr", "uint64_t", > > + object_class_property_add_qapi(oc, "tpm-base-addr", &uint64_ty= pe_info, > > xen_pvh_get_tpm_base, > > xen_pvh_set_tpm_base, > > NULL, NULL); > > diff --git a/iothread.c b/iothread.c > > index 76eea6df3861..7285135d40a8 100644 > > --- a/iothread.c > > +++ b/iothread.c > > @@ -20,6 +20,7 @@ > > #include "system/event-loop-base.h" > > #include "system/iothread.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-commands-misc.h" > > #include "qemu/error-report.h" > > #include "qemu/rcu.h" > > @@ -315,19 +316,19 @@ static void iothread_class_init(ObjectClass *klas= s, const void *class_data) > > bc->init =3D iothread_init; > > bc->update_params =3D iothread_set_aio_context_params; > > > > - object_class_property_add(klass, "poll-max-ns", "int64", > > + object_class_property_add_qapi(klass, "poll-max-ns", &int64_type_i= nfo, > > iothread_get_poll_param, > > iothread_set_poll_param, > > NULL, &poll_max_ns_info); > > - object_class_property_add(klass, "poll-grow", "int64", > > + object_class_property_add_qapi(klass, "poll-grow", &int64_type_inf= o, > > iothread_get_poll_param, > > iothread_set_poll_param, > > NULL, &poll_grow_info); > > - object_class_property_add(klass, "poll-shrink", "int64", > > + object_class_property_add_qapi(klass, "poll-shrink", &int64_type_i= nfo, > > iothread_get_poll_param, > > iothread_set_poll_param, > > NULL, &poll_shrink_info); > > - object_class_property_add(klass, "poll-weight", "int64", > > + object_class_property_add_qapi(klass, "poll-weight", &int64_type_i= nfo, > > iothread_get_poll_param, > > iothread_set_poll_param, > > NULL, &poll_weight_info); > > diff --git a/net/colo-compare.c b/net/colo-compare.c > > index a6910de869ff..4b237a59d120 100644 > > --- a/net/colo-compare.c > > +++ b/net/colo-compare.c > > @@ -16,6 +16,7 @@ > > #include "qemu/error-report.h" > > #include "trace.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "net/net.h" > > #include "net/eth.h" > > #include "qom/object_interfaces.h" > > @@ -1373,15 +1374,15 @@ static void colo_compare_init(Object *obj) > > object_property_add_str(obj, "notify_dev", > > compare_get_notify_dev, compare_set_notify= _dev); > > > > - object_property_add(obj, "compare_timeout", "uint64", > > + object_property_add_qapi(obj, "compare_timeout", &uint64_type_info= , > > compare_get_timeout, > > compare_set_timeout, NULL, NULL); > > > > - object_property_add(obj, "expired_scan_cycle", "uint32", > > + object_property_add_qapi(obj, "expired_scan_cycle", &uint32_type_i= nfo, > > compare_get_expired_scan_cycle, > > compare_set_expired_scan_cycle, NULL, NULL); > > > > - object_property_add(obj, "max_queue_size", "uint32", > > + object_property_add_qapi(obj, "max_queue_size", &uint32_type_info, > > get_max_queue_size, > > set_max_queue_size, NULL, NULL); > > > > diff --git a/net/dump.c b/net/dump.c > > index 0c39f09892c2..3d7bb36182ec 100644 > > --- a/net/dump.c > > +++ b/net/dump.c > > @@ -25,6 +25,7 @@ > > #include "qemu/osdep.h" > > #include "clients.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qemu/error-report.h" > > #include "qemu/iov.h" > > #include "qemu/module.h" > > @@ -238,8 +239,9 @@ static void filter_dump_class_init(ObjectClass *oc,= const void *data) > > { > > NetFilterClass *nfc =3D NETFILTER_CLASS(oc); > > > > - object_class_property_add(oc, "maxlen", "uint32", filter_dump_get_= maxlen, > > - filter_dump_set_maxlen, NULL, NULL); > > + object_class_property_add_qapi(oc, "maxlen", &uint32_type_info, > > + filter_dump_get_maxlen, > > + filter_dump_set_maxlen, NULL, NULL)= ; > > object_class_property_add_str(oc, "file", file_dump_get_filename, > > file_dump_set_filename); > > > > diff --git a/net/filter-buffer.c b/net/filter-buffer.c > > index 427da24097f2..9d7a9f5cb2c7 100644 > > --- a/net/filter-buffer.c > > +++ b/net/filter-buffer.c > > @@ -10,6 +10,7 @@ > > #include "net/filter.h" > > #include "net/queue.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qemu/timer.h" > > #include "qemu/iov.h" > > #include "qapi/qapi-builtin-visit.h" > > @@ -182,7 +183,7 @@ static void filter_buffer_class_init(ObjectClass *o= c, const void *data) > > { > > NetFilterClass *nfc =3D NETFILTER_CLASS(oc); > > > > - object_class_property_add(oc, "interval", "uint32", > > + object_class_property_add_qapi(oc, "interval", &uint32_type_info, > > filter_buffer_get_interval, > > filter_buffer_set_interval, NULL, NULL); > > > > diff --git a/qom/object.c b/qom/object.c > > index 8e6ca25dc49d..bbaa999ae0c9 100644 > > --- a/qom/object.c > > +++ b/qom/object.c > > @@ -22,9 +22,9 @@ > > #include "qapi/string-output-visitor.h" > > #include "qapi/qobject-input-visitor.h" > > #include "qapi/forward-visitor.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-builtin-visit.h" > > #include "qobject/qdict.h" > > -#include "qobject/qjson.h" > > #include "qemu/id.h" > > #include "qapi/qmp/qerror.h" > > #include "trace.h" > > @@ -2429,7 +2429,7 @@ object_property_add_str(Object *obj, const char *= name, > > prop->get =3D get; > > prop->set =3D set; > > > > - return object_property_add(obj, name, "string", > > + return object_property_add_qapi(obj, name, &str_type_info, > > get ? property_get_str : NULL, > > set ? property_set_str : NULL, > > property_release_data, > > @@ -2447,7 +2447,7 @@ object_class_property_add_str(ObjectClass *klass,= const char *name, > > prop->get =3D get; > > prop->set =3D set; > > > > - return object_class_property_add(klass, name, "string", > > + return object_class_property_add_qapi(klass, name, &str_type_info, > > get ? property_get_str : NULL, > > set ? property_set_str : NULL, > > NULL, > > @@ -2499,7 +2499,7 @@ object_property_add_bool(Object *obj, const char = *name, > > prop->get =3D get; > > prop->set =3D set; > > > > - return object_property_add(obj, name, "bool", > > + return object_property_add_qapi(obj, name, &bool_type_info, > > get ? property_get_bool : NULL, > > set ? property_set_bool : NULL, > > property_release_data, > > @@ -2516,7 +2516,7 @@ object_class_property_add_bool(ObjectClass *klass= , const char *name, > > prop->get =3D get; > > prop->set =3D set; > > > > - return object_class_property_add(klass, name, "bool", > > + return object_class_property_add_qapi(klass, name, &bool_type_info= , > > get ? property_get_bool : NULL, > > set ? property_set_bool : NULL, > > NULL, > > @@ -2856,8 +2856,8 @@ object_property_add_uint8_ptr(Object *obj, const = char *name, > > setter =3D property_set_uint8_ptr; > > } > > > > - return object_property_add(obj, name, "uint8", > > - getter, setter, NULL, (void *)v); > > + return object_property_add_qapi(obj, name, &uint8_type_info, > > + getter, setter, NULL, (void *)v); > > } > > > > ObjectProperty * > > @@ -2897,8 +2897,8 @@ object_class_static_property_add_uint8_ptr(Object= Class *klass, > > setter =3D property_set_uint8_ptr; > > } > > > > - return object_class_property_add(klass, name, "uint8", > > - getter, setter, NULL, (void *)v); > > + return object_class_property_add_qapi(klass, name, &uint8_type_inf= o, > > + getter, setter, NULL, (void = *)v); > > } > > > > ObjectProperty * > > @@ -2917,8 +2917,8 @@ object_property_add_uint16_ptr(Object *obj, const= char *name, > > setter =3D property_set_uint16_ptr; > > } > > > > - return object_property_add(obj, name, "uint16", > > - getter, setter, NULL, (void *)v); > > + return object_property_add_qapi(obj, name, &uint16_type_info, > > + getter, setter, NULL, (void *)v); > > } > > > > ObjectProperty * > > @@ -2958,8 +2958,8 @@ object_class_static_property_add_uint16_ptr(Objec= tClass *klass, > > setter =3D property_set_uint16_ptr; > > } > > > > - return object_class_property_add(klass, name, "uint16", > > - getter, setter, NULL, (void *)v); > > + return object_class_property_add_qapi(klass, name, &uint16_type_in= fo, > > + getter, setter, NULL, (void = *)v); > > } > > > > ObjectProperty * > > @@ -2978,8 +2978,8 @@ object_property_add_uint32_ptr(Object *obj, const= char *name, > > setter =3D property_set_uint32_ptr; > > } > > > > - return object_property_add(obj, name, "uint32", > > - getter, setter, NULL, (void *)v); > > + return object_property_add_qapi(obj, name, &uint32_type_info, > > + getter, setter, NULL, (void *)v); > > } > > > > ObjectProperty * > > @@ -3019,8 +3019,8 @@ object_class_static_property_add_uint32_ptr(Objec= tClass *klass, > > setter =3D property_set_uint32_ptr; > > } > > > > - return object_class_property_add(klass, name, "uint32", > > - getter, setter, NULL, (void *)v); > > + return object_class_property_add_qapi(klass, name, &uint32_type_in= fo, > > + getter, setter, NULL, (void = *)v); > > } > > > > ObjectProperty * > > @@ -3039,8 +3039,8 @@ object_property_add_uint64_ptr(Object *obj, const= char *name, > > setter =3D property_set_uint64_ptr; > > } > > > > - return object_property_add(obj, name, "uint64", > > - getter, setter, NULL, (void *)v); > > + return object_property_add_qapi(obj, name, &uint64_type_info, > > + getter, setter, NULL, (void *)v); > > } > > > > ObjectProperty * > > @@ -3080,8 +3080,8 @@ object_class_static_property_add_uint64_ptr(Objec= tClass *klass, > > setter =3D property_set_uint64_ptr; > > } > > > > - return object_class_property_add(klass, name, "uint64", > > - getter, setter, NULL, (void *)v); > > + return object_class_property_add_qapi(klass, name, &uint64_type_in= fo, > > + getter, setter, NULL, (void = *)v); > > } > > > > typedef struct { > > diff --git a/system/bootdevice.c b/system/bootdevice.c > > index 9538b08983f5..7789e464186a 100644 > > --- a/system/bootdevice.c > > +++ b/system/bootdevice.c > > @@ -24,6 +24,7 @@ > > > > #include "qemu/osdep.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "system/system.h" > > #include "qapi/visitor.h" > > #include "qemu/error-report.h" > > @@ -336,7 +337,7 @@ void device_add_bootindex_property(Object *obj, int= 32_t *bootindex, > > prop->suffix =3D suffix; > > prop->dev =3D dev; > > > > - object_property_add(obj, name, "int32", > > + object_property_add_qapi(obj, name, &int32_type_info, > > device_get_bootindex, > > device_set_bootindex, > > property_release_bootindex, > > diff --git a/system/memory.c b/system/memory.c > > index d4a0a5b81805..ae768cba80bd 100644 > > --- a/system/memory.c > > +++ b/system/memory.c > > @@ -16,6 +16,7 @@ > > #include "qemu/osdep.h" > > #include "qemu/log.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "system/memory.h" > > #include "qapi/visitor.h" > > #include "qemu/bitops.h" > > @@ -1318,11 +1319,11 @@ static void memory_region_initfn(Object *obj) > > > > object_property_add_uint64_ptr(OBJECT(mr), "addr", > > &mr->addr, OBJ_PROP_FLAG_READ); > > - object_property_add(OBJECT(mr), "priority", "int32", > > + object_property_add_qapi(OBJECT(mr), "priority", &int32_type_info, > > memory_region_get_priority, > > NULL, /* memory_region_set_priority */ > > NULL, NULL); > > - object_property_add(OBJECT(mr), "size", "uint64", > > + object_property_add_qapi(OBJECT(mr), "size", &uint64_type_info, > > memory_region_get_size, > > NULL, /* memory_region_set_size, */ > > NULL, NULL); > > diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c > > index 4e8c47253086..55df765e64d1 100644 > > --- a/target/arm/cpu64.c > > +++ b/target/arm/cpu64.c > > @@ -20,6 +20,7 @@ > > > > #include "qemu/osdep.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "cpu.h" > > #include "cpregs.h" > > #include "qemu/module.h" > > @@ -320,7 +321,7 @@ static void prop_bool_set_false(Object *obj, Visito= r *v, const char *name, > > > > static void prop_add_stub_bool(Object *obj, const char *name) > > { > > - object_property_add(obj, name, "bool", prop_bool_get_false, > > + object_property_add_qapi(obj, name, &bool_type_info, prop_bool_get= _false, > > prop_bool_set_false, NULL, NULL); > > } > > > > @@ -510,13 +511,13 @@ void aarch64_add_sve_properties(Object *obj) > > for (vq =3D 1; vq <=3D ARM_MAX_VQ; ++vq) { > > char name[8]; > > snprintf(name, sizeof(name), "sve%d", vq * 128); > > - object_property_add(obj, name, "bool", cpu_arm_get_vq, > > + object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_g= et_vq, > > cpu_arm_set_vq, NULL, &cpu->sve_vq); > > } > > > > #ifdef CONFIG_USER_ONLY > > /* Mirror linux /proc/sys/abi/sve_default_vector_length. */ > > - object_property_add(obj, "sve-default-vector-length", "int32", > > + object_property_add_qapi(obj, "sve-default-vector-length", &int32_= type_info, > > cpu_arm_get_default_vec_len, > > cpu_arm_set_default_vec_len, NULL, > > &cpu->sve_default_vq); > > @@ -535,13 +536,13 @@ void aarch64_add_sme_properties(Object *obj) > > for (vq =3D 1; vq <=3D ARM_MAX_VQ; vq <<=3D 1) { > > char name[8]; > > snprintf(name, sizeof(name), "sme%d", vq * 128); > > - object_property_add(obj, name, "bool", cpu_arm_get_vq, > > + object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_g= et_vq, > > cpu_arm_set_vq, NULL, &cpu->sme_vq); > > } > > > > #ifdef CONFIG_USER_ONLY > > /* Mirror linux /proc/sys/abi/sme_default_vector_length. */ > > - object_property_add(obj, "sme-default-vector-length", "int32", > > + object_property_add_qapi(obj, "sme-default-vector-length", &int32_= type_info, > > cpu_arm_get_default_vec_len, > > cpu_arm_set_default_vec_len, NULL, > > &cpu->sme_default_vq); > > diff --git a/target/arm/kvm.c b/target/arm/kvm.c > > index ed99be7fd80c..198b7615f4cc 100644 > > --- a/target/arm/kvm.c > > +++ b/target/arm/kvm.c > > @@ -20,6 +20,7 @@ > > #include "qemu/main-loop.h" > > #include "qom/object.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "system/system.h" > > #include "system/runstate.h" > > #include "system/ramblock.h" > > @@ -1777,7 +1778,7 @@ static void kvm_arch_set_eager_split_size(Object = *obj, Visitor *v, > > > > void kvm_arch_accel_class_init(ObjectClass *oc) > > { > > - object_class_property_add(oc, "eager-split-size", "size", > > + object_class_property_add_qapi(oc, "eager-split-size", &size_type_= info, > > kvm_arch_get_eager_split_size, > > kvm_arch_set_eager_split_size, NULL, NUL= L); > > > > diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c > > index affd87a3ae55..da8d44f1fc61 100644 > > --- a/target/arm/tcg/cpu64.c > > +++ b/target/arm/tcg/cpu64.c > > @@ -20,6 +20,7 @@ > > > > #include "qemu/osdep.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "cpu.h" > > #include "qemu/module.h" > > #include "qapi/visitor.h" > > @@ -1392,9 +1393,9 @@ void aarch64_max_v8_tcg_initfn(Object *obj) > > /* v8.2: FEAT_SVE */ > > cpu->sve_vq.supported =3D MAKE_64BIT_MASK(0, ARM_MAX_VQ); > > aarch64_add_sve_properties(OBJECT(cpu)); > > - object_property_add(OBJECT(cpu), "sve-max-vq", "uint32", > > - cpu_max_get_sve_max_vq, cpu_max_set_sve_max_vq= , > > - NULL, NULL); > > + object_property_add_qapi(OBJECT(cpu), "sve-max-vq", &uint32_type_i= nfo, > > + cpu_max_get_sve_max_vq, > > + cpu_max_set_sve_max_vq, NULL, NULL); > > > > /* v8.2: FEAT_PAuth2 */ > > aarch64_add_pauth_properties(OBJECT(cpu)); > > @@ -1524,8 +1525,8 @@ void aarch64_max_v9_tcg_initfn(Object *obj) > > object_property_add_bool(obj, "x-rme", cpu_arm_get_rme, cpu_arm_se= t_rme); > > > > /* v9.4: FEAT_RME_GPC2 */ > > - object_property_add(obj, "x-l0gptsz", "uint32", cpu_max_get_l0gpts= z, > > - cpu_max_set_l0gptsz, NULL, NULL); > > + object_property_add_qapi(obj, "x-l0gptsz", &uint32_type_info, cpu_= max_get_l0gptsz, > > + cpu_max_set_l0gptsz, NULL, NULL); > > } > > > > static const ARMCPUInfo aarch64_cpus[] =3D { > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > > index 8650ff6caecc..ebce8e128224 100644 > > --- a/target/i386/cpu.c > > +++ b/target/i386/cpu.c > > @@ -10431,7 +10431,7 @@ static void x86_cpu_register_bit_prop(X86CPUCla= ss *xcc, > > fp =3D g_new0(BitProperty, 1); > > fp->w =3D w; > > fp->mask =3D mask; > > - object_class_property_add(oc, prop_name, "bool", > > + object_class_property_add_qapi(oc, prop_name, &bool_type_info, > > x86_cpu_get_bit_prop, > > x86_cpu_set_bit_prop, > > NULL, fp); > > @@ -10950,13 +10950,13 @@ static void x86_cpu_common_class_init(ObjectC= lass *oc, const void *data) > > > > dc->user_creatable =3D true; > > > > - object_class_property_add(oc, "family", "uint64", > > + object_class_property_add_qapi(oc, "family", &uint64_type_info, > > x86_cpuid_version_get_family, > > x86_cpuid_version_set_family, NULL, NULL= ); > > - object_class_property_add(oc, "model", "uint64", > > + object_class_property_add_qapi(oc, "model", &uint64_type_info, > > x86_cpuid_version_get_model, > > x86_cpuid_version_set_model, NULL, NULL)= ; > > - object_class_property_add(oc, "stepping", "uint64", > > + object_class_property_add_qapi(oc, "stepping", &uint64_type_info, > > x86_cpuid_version_get_stepping, > > x86_cpuid_version_set_stepping, NULL, NU= LL); > > object_class_property_add_str(oc, "vendor", > > @@ -10965,7 +10965,7 @@ static void x86_cpu_common_class_init(ObjectCla= ss *oc, const void *data) > > object_class_property_add_str(oc, "model-id", > > x86_cpuid_get_model_id, > > x86_cpuid_set_model_id); > > - object_class_property_add(oc, "tsc-frequency", "int", > > + object_class_property_add_qapi(oc, "tsc-frequency", &int_type_info= , > > x86_cpuid_get_tsc_freq, > > x86_cpuid_set_tsc_freq, NULL, NULL); > > /* > > @@ -10978,7 +10978,7 @@ static void x86_cpu_common_class_init(ObjectCla= ss *oc, const void *data) > > x86_cpu_get_unavailable_features, > > NULL, NULL, NULL); > > > > - object_class_property_add(oc, "avx10-version", "uint8", > > + object_class_property_add_qapi(oc, "avx10-version", &uint8_type_i= nfo, > > x86_cpuid_get_avx10_version, > > x86_cpuid_set_avx10_version, > > NULL, NULL); > > diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c > > index 9f65419a2c1a..aa4967adf99e 100644 > > --- a/target/i386/kvm/kvm.c > > +++ b/target/i386/kvm/kvm.c > > @@ -7099,7 +7099,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc) > > .set =3D kvm_arch_set_notify_vmexit, > > )); > > > > - object_class_property_add(oc, "notify-window", "uint32", > > + object_class_property_add_qapi(oc, "notify-window", &uint32_type_i= nfo, > > kvm_arch_get_notify_window, > > kvm_arch_set_notify_window, > > NULL, NULL); > > @@ -7107,7 +7107,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc) > > "Clock cycles without an eve= nt window " > > "after which a notification = VM exit occurs"); > > > > - object_class_property_add(oc, "xen-version", "uint32", > > + object_class_property_add_qapi(oc, "xen-version", &uint32_type_inf= o, > > kvm_arch_get_xen_version, > > kvm_arch_set_xen_version, > > NULL, NULL); > > @@ -7116,14 +7116,14 @@ void kvm_arch_accel_class_init(ObjectClass *oc) > > "(in XENVER_version form " > > "e.g. 0x4000a for 4.10)"); > > > > - object_class_property_add(oc, "xen-gnttab-max-frames", "uint16", > > + object_class_property_add_qapi(oc, "xen-gnttab-max-frames", &uint1= 6_type_info, > > kvm_arch_get_xen_gnttab_max_frames, > > kvm_arch_set_xen_gnttab_max_frames, > > NULL, NULL); > > object_class_property_set_description(oc, "xen-gnttab-max-frames", > > "Maximum number of grant tab= le frames"); > > > > - object_class_property_add(oc, "xen-evtchn-max-pirq", "uint16", > > + object_class_property_add_qapi(oc, "xen-evtchn-max-pirq", &uint16_= type_info, > > kvm_arch_get_xen_evtchn_max_pirq, > > kvm_arch_set_xen_evtchn_max_pirq, > > NULL, NULL); > > diff --git a/target/i386/sev.c b/target/i386/sev.c > > index b2c7260c80a4..3a36fa4d0b95 100644 > > --- a/target/i386/sev.c > > +++ b/target/i386/sev.c > > @@ -3266,7 +3266,7 @@ sev_snp_guest_class_init(ObjectClass *oc, const v= oid *data) > > x86_klass->adjust_cpuid_features =3D sev_snp_adjust_cpuid_features= ; > > x86_klass->kvm_type =3D sev_snp_kvm_type; > > > > - object_class_property_add(oc, "policy", "uint64", > > + object_class_property_add_qapi(oc, "policy", &uint64_type_info, > > sev_snp_guest_get_policy, > > sev_snp_guest_set_policy, NULL, NULL); > > object_class_property_add_str(oc, "guest-visible-workarounds", > > diff --git a/target/ppc/compat.c b/target/ppc/compat.c > > index 55de3bd5d5de..4d81225de37f 100644 > > --- a/target/ppc/compat.c > > +++ b/target/ppc/compat.c > > @@ -23,6 +23,7 @@ > > #include "kvm_ppc.h" > > #include "system/cpus.h" > > #include "qemu/error-report.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/error.h" > > #include "qapi/visitor.h" > > #include "cpu-models.h" > > @@ -335,7 +336,7 @@ void ppc_compat_add_property(Object *obj, const cha= r *name, > > gchar *names, *desc; > > int i; > > > > - object_property_add(obj, name, "string", > > + object_property_add_qapi(obj, name, &str_type_info, > > ppc_compat_prop_get, ppc_compat_prop_set, NULL= , > > compat_pvr); > > > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > > index fd1afbc7fe23..a1faea801d1d 100644 > > --- a/target/riscv/cpu.c > > +++ b/target/riscv/cpu.c > > @@ -27,6 +27,7 @@ > > #include "target/riscv/tcg/csr.h" > > #include "internals.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/error-report.h" > > #include "qemu/timer.h" > > @@ -1396,20 +1397,20 @@ void riscv_add_satp_mode_properties(Object *obj= ) > > { > > RISCVCPU *cpu =3D RISCV_CPU(obj); > > > > - object_property_add(obj, "svbare", "bool", cpu_riscv_get_satp, > > - cpu_riscv_set_satp, NULL, &cpu->satp_modes); > > + object_property_add_qapi(obj, "svbare", &bool_type_info, cpu_riscv= _get_satp, > > + cpu_riscv_set_satp, NULL, &cpu->satp_mode= s); > > > > if (cpu->env.misa_mxl =3D=3D MXL_RV32) { > > - object_property_add(obj, "sv32", "bool", cpu_riscv_get_satp, > > + object_property_add_qapi(obj, "sv32", &bool_type_info, cpu_ris= cv_get_satp, > > cpu_riscv_set_satp, NULL, &cpu->satp_modes= ); > > } else { > > - object_property_add(obj, "sv39", "bool", cpu_riscv_get_satp, > > + object_property_add_qapi(obj, "sv39", &bool_type_info, cpu_ris= cv_get_satp, > > cpu_riscv_set_satp, NULL, &cpu->satp_modes= ); > > - object_property_add(obj, "sv48", "bool", cpu_riscv_get_satp, > > + object_property_add_qapi(obj, "sv48", &bool_type_info, cpu_ris= cv_get_satp, > > cpu_riscv_set_satp, NULL, &cpu->satp_modes= ); > > - object_property_add(obj, "sv57", "bool", cpu_riscv_get_satp, > > + object_property_add_qapi(obj, "sv57", &bool_type_info, cpu_ris= cv_get_satp, > > cpu_riscv_set_satp, NULL, &cpu->satp_modes= ); > > - object_property_add(obj, "sv64", "bool", cpu_riscv_get_satp, > > + object_property_add_qapi(obj, "sv64", &bool_type_info, cpu_ris= cv_get_satp, > > cpu_riscv_set_satp, NULL, &cpu->satp_modes= ); > > } > > } > > diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c > > index 68e1501b21e2..d2d6cb7a4c66 100644 > > --- a/target/riscv/kvm/kvm-cpu.c > > +++ b/target/riscv/kvm/kvm-cpu.c > > @@ -24,6 +24,7 @@ > > > > #include "qemu/timer.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qemu/error-report.h" > > #include "qemu/main-loop.h" > > #include "qapi/visitor.h" > > @@ -532,7 +533,7 @@ static void riscv_cpu_add_kvm_unavail_prop(Object *= obj, const char *prop_name) > > * unknown to KVM and error out if the user attempts > > * to enable any of them. > > */ > > - object_property_add(obj, prop_name, "bool", > > + object_property_add_qapi(obj, prop_name, &bool_type_info, > > cpu_get_cfg_unavailable, > > cpu_set_cfg_unavailable, > > NULL, (void *)prop_name); > > @@ -552,7 +553,7 @@ static void kvm_riscv_add_cpu_user_properties(Objec= t *cpu_obj) > > misa_cfg->name =3D riscv_get_misa_ext_name(bit); > > misa_cfg->description =3D riscv_get_misa_ext_description(bit); > > > > - object_property_add(cpu_obj, misa_cfg->name, "bool", > > + object_property_add_qapi(cpu_obj, misa_cfg->name, &bool_type_i= nfo, > > kvm_cpu_get_misa_ext_cfg, > > kvm_cpu_set_misa_ext_cfg, > > NULL, misa_cfg); > > @@ -568,7 +569,7 @@ static void kvm_riscv_add_cpu_user_properties(Objec= t *cpu_obj) > > for (i =3D 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) { > > KVMCPUConfig *multi_cfg =3D &kvm_multi_ext_cfgs[i]; > > > > - object_property_add(cpu_obj, multi_cfg->name, "bool", > > + object_property_add_qapi(cpu_obj, multi_cfg->name, &bool_type_= info, > > kvm_cpu_get_multi_ext_cfg, > > kvm_cpu_set_multi_ext_cfg, > > NULL, multi_cfg); > > diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c > > index 9e3cc87f8a31..92e03a386832 100644 > > --- a/target/riscv/tcg/tcg-cpu.c > > +++ b/target/riscv/tcg/tcg-cpu.c > > @@ -26,6 +26,7 @@ > > #include "pmu.h" > > #include "time_helper.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > #include "qemu/accel.h" > > #include "qemu/error-report.h" > > @@ -1438,7 +1439,7 @@ static void riscv_cpu_add_misa_properties(Object = *cpu_obj) > > continue; > > } > > > > - object_property_add(cpu_obj, name, "bool", > > + object_property_add_qapi(cpu_obj, name, &bool_type_info, > > cpu_get_misa_ext_cfg, > > cpu_set_misa_ext_cfg, > > NULL, (void *)misa_cfg); > > @@ -1492,7 +1493,7 @@ static void riscv_cpu_add_profiles(Object *cpu_ob= j) > > for (int i =3D 0; riscv_profiles[i] !=3D NULL; i++) { > > RISCVCPUProfile *profile =3D riscv_profiles[i]; > > > > - object_property_add(cpu_obj, profile->name, "bool", > > + object_property_add_qapi(cpu_obj, profile->name, &bool_type_in= fo, > > cpu_get_profile, cpu_set_profile, > > NULL, (void *)profile); > > > > @@ -1568,10 +1569,10 @@ static void riscv_cpu_add_user_properties(Objec= t *obj) > > > > for (edata =3D isa_edata_arr; edata && edata->name; edata++) { > > if (edata->prop_name) { > > - object_property_add(obj, edata->prop_name, "bool", > > - cpu_get_multi_ext_cfg, > > - cpu_set_multi_ext_cfg, > > - NULL, (void *)&edata->ext_enable_offse= t); > > + object_property_add_qapi(obj, edata->prop_name, &bool_type= _info, > > + cpu_get_multi_ext_cfg, > > + cpu_set_multi_ext_cfg, > > + NULL, (void *)&edata->ext_enable_= offset); > > } > > } > > > > diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c > > index c41d629d6803..72bf0f48de83 100644 > > --- a/target/s390x/cpu_models.c > > +++ b/target/s390x/cpu_models.c > > @@ -17,6 +17,7 @@ > > #include "system/kvm.h" > > #include "system/tcg.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qemu/error-report.h" > > #include "qapi/visitor.h" > > #include "qemu/module.h" > > @@ -915,13 +916,13 @@ void s390_cpu_model_class_register_props(ObjectCl= ass *oc) > > > > for (feat =3D 0; feat < S390_FEAT_MAX; feat++) { > > const S390FeatDef *def =3D s390_feat_def(feat); > > - object_class_property_add(oc, def->name, "bool", get_feature, > > + object_class_property_add_qapi(oc, def->name, &bool_type_info,= get_feature, > > set_feature, NULL, (void *) feat); > > object_class_property_set_description(oc, def->name, def->desc= ); > > } > > for (group =3D 0; group < S390_FEAT_GROUP_MAX; group++) { > > const S390FeatGroupDef *def =3D s390_feat_group_def(group); > > - object_class_property_add(oc, def->name, "bool", get_feature_g= roup, > > + object_class_property_add_qapi(oc, def->name, &bool_type_info,= get_feature_group, > > set_feature_group, NULL, (void *) gr= oup); > > object_class_property_set_description(oc, def->name, def->desc= ); > > } > > diff --git a/tests/unit/test-qdev-global-props.c b/tests/unit/test-qdev= -global-props.c > > index 8ea362cbb902..204436fb7276 100644 > > --- a/tests/unit/test-qdev-global-props.c > > +++ b/tests/unit/test-qdev-global-props.c > > @@ -27,6 +27,7 @@ > > #include "hw/core/qdev-properties.h" > > #include "qom/object.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/visitor.h" > > > > > > @@ -171,10 +172,12 @@ static void prop2_accessor(Object *obj, Visitor *= v, const char *name, > > > > static void dynamic_instance_init(Object *obj) > > { > > - object_property_add(obj, "prop1", "uint32", prop1_accessor, prop1_= accessor, > > - NULL, NULL); > > - object_property_add(obj, "prop2", "uint32", prop2_accessor, prop2_= accessor, > > - NULL, NULL); > > + object_property_add_qapi(obj, "prop1", &uint32_type_info, > > + prop1_accessor, prop1_accessor, > > + NULL, NULL); > > + object_property_add_qapi(obj, "prop2", &uint32_type_info, > > + prop2_accessor, prop2_accessor, > > + NULL, NULL); > > } > > > > static void dynamic_class_init(ObjectClass *oc, const void *data) > > diff --git a/ui/console.c b/ui/console.c > > index a8a2a247d8f4..b4345b06d012 100644 > > --- a/ui/console.c > > +++ b/ui/console.c > > @@ -28,6 +28,7 @@ > > #include "ui/vgafont.h" > > #include "hw/core/qdev.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-commands-ui.h" > > #include "qapi/visitor.h" > > #include "qemu/coroutine.h" > > @@ -535,7 +536,7 @@ qemu_graphic_console_class_init(ObjectClass *oc, co= nst void *data) > > offsetof(QemuGraphicConsole, device= ), > > object_property_allow_set_link, > > OBJ_PROP_LINK_STRONG); > > - object_class_property_add(oc, "head", "uint32", > > + object_class_property_add_qapi(oc, "head", &uint32_type_info, > > qemu_graphic_console_prop_get_head, > > NULL, NULL, NULL); > > > > diff --git a/util/thread-context.c b/util/thread-context.c > > index 88d8f0a55a4e..7fa6840dd401 100644 > > --- a/util/thread-context.c > > +++ b/util/thread-context.c > > @@ -13,6 +13,7 @@ > > #include "qemu/osdep.h" > > #include "qemu/thread-context.h" > > #include "qapi/error.h" > > +#include "qapi/qapi-builtin-type-infos.h" > > #include "qapi/qapi-builtin-visit.h" > > #include "qapi/visitor.h" > > #include "qemu/config-file.h" > > @@ -278,13 +279,13 @@ static void thread_context_class_init(ObjectClass= *oc, const void *data) > > UserCreatableClass *ucc =3D USER_CREATABLE_CLASS(oc); > > > > ucc->complete =3D thread_context_instance_complete; > > - object_class_property_add(oc, "thread-id", "uint64", > > + object_class_property_add_qapi(oc, "thread-id", &uint64_type_info, > > thread_context_get_thread_id, NULL, NULL= , > > NULL); > > - object_class_property_add(oc, "cpu-affinity", "[uint16]", > > + object_class_property_add_qapi(oc, "cpu-affinity", &uint16List_typ= e_info, > > thread_context_get_cpu_affinity, > > thread_context_set_cpu_affinity, NULL, N= ULL); > > - object_class_property_add(oc, "node-affinity", "[uint16]", NULL, > > + object_class_property_add_qapi(oc, "node-affinity", &uint16List_ty= pe_info, NULL, > > thread_context_set_node_affinity, NULL, = NULL); > > } > > > > > > -- > > 2.55.0.543.g5ebe2ebe4ea8 > > > From xen-devel-bounces@lists.xenproject.org Fri Sep 11 15:21:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 15:21:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417427.1646251 (Exim 4.92) (envelope-from ) id 1x533l-0002l2-Cm; Fri, 11 Sep 2026 15:21:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417427.1646251; Fri, 11 Sep 2026 15:21:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x533l-0002kv-9y; Fri, 11 Sep 2026 15:21:01 +0000 Received: by outflank-mailman (input) for mailman id 1417427; Fri, 11 Sep 2026 15:21:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x533j-0002kB-R9 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:20:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x533j-008qcF-7g for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:20:59 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa41c55-2eae-0a2a0a5409dd-0a2a4507c6ec-8 for ; Fri, 11 Sep 2026 17:20:59 +0200 Received: from [40.93.198.4] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa41c59-b4ea-0a2a45070019-285dc6049073-3 for ; Fri, 11 Sep 2026 17:20:59 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH1PR03MB8142.namprd03.prod.outlook.com (2603:10b6:610:2b1::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.10; Fri, 11 Sep 2026 15:20:55 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 15:20:55 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eX8P83zsCT01u/u6ultjAw6tXMor7XQqLe/VELS4SIr/ENGgk3y89EBGkydVpxEaq8Cb3vLvWd1H/T7z3AuSAHXzTXgT8I6Kyndy9W5Ltj9wXmUi6OHbtCNvzka2k44YJ4JgR+dopiiiTiH26jqROTDTKdVWTy4VEnPXCZfozgB9ecCv8v5e0wT9vWehlrZLfzk0jChBjyGYUh08YULo08cmNneQMzVdm6Q89JDRo2mitlySsvC0FPO99WaMkOHrG0YCJ45itinX0mvE2mVObuQ2d5gjb6K722CM7yJB/WC5b7snIFoJLSTT5AziVqn64OTG5qZM1RH59NGCM5X5rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=H6kPztzeMRtVA1TdA2qPT1+aM+D08F+DszvqJqvSHLg=; b=UntrT/ES26/UxCSffzd6LsTafCLLO2F24BczkB0gQpk3D3Jm8C2lswBeNR0MJD7R3gXA10G2zrS6AFGAdZ+rZ0q0DwJMhuFzVhhh+wvTxBu4u7SxICAsX9HZjx7yE2t7P4FM3V/czQRlx02bC7+4OGLrXEYBiXc4g1s14D4cXthj7vtwxI5WboleFgP0Us3dRa80ajjwaLq3hyyh20ki6yIYSJ1C1I8f/whpHcz5rNTiFnhbOOIVLp1SvU7R4EPcgSsZO3PgDBEVyNQfGYQLsA60M4Gxw5iwgk2ktjL+QYyEwweSfZ/exKOSOVXCm7AVL2cbj/dIlkL37c+eIz5dnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H6kPztzeMRtVA1TdA2qPT1+aM+D08F+DszvqJqvSHLg=; b=jk5zcKDHe1AyLei7b6rRAMa2SzDzWWaot51axyfdMtBxYnvMWjI/iX0Miorfp1amYP7uEoOfolr0vl53Al26pE8xlPN//Epk9ybdwlrtz7BKJb8/W2IFeGAII52uaovmtimtgsmGQl0SUVtAoVIe6WDL6SNqMwp3YDbpTusXWPg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 11 Sep 2026 16:20:52 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH v2] nestedsvm: Fix multi-byte IO port intercept check To: Ross Lagerwall , xen-devel@lists.xenproject.org References: <20260911132315.1209497-1-ross.lagerwall@citrix.com> <10df3c15-990e-43db-8cc7-578f44a2bbfe@citrix.com> <52b94314-5291-4cf6-87fc-be3a54618b39@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <52b94314-5291-4cf6-87fc-be3a54618b39@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0186.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:311::13) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH1PR03MB8142:EE_ X-MS-Office365-Filtering-Correlation-Id: 0e654c7d-a684-4071-2c7f-08df10184621 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|18002099003|22082099003|10067099003|56012099006|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: 5OTZpJcdMbt4gmgxJqv45DpIcem/CnxmyMSyTYPn6NJfC0d9yx/1dUahnHeYh7GsdS9gGGwzbFVuXJxJ+gaTvf4TMIYsGetJ8cCt8V95JBKHquhHbOYMzQtKf8RsN3n5CH+KiMUXuGuK14c+N839YM7rg5GJthfZrItyVO9IjjmuvkJDwdHK52VedMU2QvuIUEh5G/ut3JCrmQbmeLo9Y02MJQnJSFTCRnnopCfIPBka4UM+D2tHx+OWUtYhsGzeFTdCtNmuU2cxbxxE67VaEYVaTo/puRM6uI6u49l3JBfSRe2sB9Gp2Y0NJGFohgl14WnSJRrsIbzHG8MUoqhMb99/mChc2aBXLBai278iFZBn6UMJxh+sPFWjhQCPXLyMV5OSfaXrG2pKCBzA6dbrnrsXdXqY32F2Kjm56s9YF999bhjipE2ykuFEojsGmDtbgEmd4zjViC3Rzl8h+5f84yPX6If8EPr+vQps2vuSEiEBaBV9qW+6PKW4Jp/LQC5Q7ih7DlMcKY3eC7emu0UI2MYPz2zmGpPKwvwQ7LNK3c9a2j5uhvG+SjM/pf4iuJW70NS6ByylQIV/iZnj9sl3AnceTZya0ghRYjQZW8Z0N6ai56BeNmZ9tto8PiXK2TrwUB/ftYwKg5+vc0ZYGK/6In8Ir4p0l9g8Rpgug+rIGXk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R3ZneDhTV01CK1RJamdsZ1IwUzV2aHN3SjdFMUdXRHhBSUNQR2ZKZ2JWUUtX?= =?utf-8?B?ZXl6NmV5WGhGZk1nUTEyd292NVdESFV1Z1VpYjcvdHJiUVpvaVJvTWRQZXg0?= =?utf-8?B?ZUJLbUNqMXRGRXh4cWZCdnNnUUUrNVM2U2EyNnh0ZGYrWkZ5bUZLUzBKRm5x?= =?utf-8?B?WVp1aGxaZ2gySW5LU0x0Sng3WnhDU2wzd0MyZDlNM0paNHFTeWxFeGpFazRU?= =?utf-8?B?elkwaVVmaUROTjR0aU1BL2U0YmNDUTQrRmNmbkt4ZFhWNVNZOS90MnJBRURa?= =?utf-8?B?L0w0K1g0U015aU1PMTNEWlgrQjE1RjdBTGdlSXpoUDQ4U2crK0dNODN5T0kz?= =?utf-8?B?eGlYVTB3bkxPcm9wakJOVGxOMWEvM0paY0x4YXBDanVZSzBmNFQyZnVmeTl4?= =?utf-8?B?QnJMaHpac2FUSjRyazRZT1huUjRxd29SbWYvMW1RSjNrWWdmc3lPcG1EQ0FW?= =?utf-8?B?eVdKTVBJd2l1U2dWMGJYck9PdnRjSlZZTDNjaFBNSEZmRHNkNGNvQW84SE1y?= =?utf-8?B?NmE5ZFdlZ2ZHL1pTSFhuandmd1FFbDdCN1VJa3pKMHA0TGRXMGxYbXR0TXQ4?= =?utf-8?B?UUcrNWlSQzhXcHBXS3VDVGFQRlpzTXRxaDRpRk43SDZadlIza295Yi84bWMz?= =?utf-8?B?WmF5RUhBQXNzOW9qcmgwRWJCV2lXY3VsZ2VCTlFrUVdJVVEzWmNCb0d3c1di?= =?utf-8?B?YmFsUTJvM3BUeGRaZWNsTmE1Q0ZLcElBTzZyT0FaenFKaDBocGVwWnpKT3ds?= =?utf-8?B?KzZhRWtEQWQxUFJNVGJ1L3ZGeG5tM0liL3hIR09pK2IwREQxWlZLWml4M0ZK?= =?utf-8?B?UzQxNHVXaXJuVkp1TldVSlRySjRzMVhWMU9BY1NiVGd0RTh2K015MFhCYVNx?= =?utf-8?B?YUJnNVZrK0cyT0Fyb3FzcWl5b0ZjODQrUWlHczdKT0NmQm5OdkEvVTZZeEpP?= =?utf-8?B?ckdQRTltQ0ljZXR1eXhPZFdrWHFVaXdxLytVT2hVdCtEcHRGZnduM2xYNXJq?= =?utf-8?B?d0wwSUhnaGVseDVqWDdvaG5vZDNPV2J0Yy9uckRFVHJTc0pRTjZSNWRJcFRw?= =?utf-8?B?SG4raFdYc3J0OW5GbWRKTGFUM05GcjAzK1IwcE9uU1VFc1hwblZiVUJNWEtR?= =?utf-8?B?NTVXOVhMRWRxWnNnRnFINVcvUzF6WEdJaThkVWZQcmtwQmxDOVJvdlh5QWpa?= =?utf-8?B?djhWWUNvZTdReGdOUTk4LzFtQytqQVVkbFdzb0tRam5VWWpJZDFRNnpXZEpB?= =?utf-8?B?eEh3V2FHdXlNalBsYmozc0p2ek9xYlRkVzd6MDIvVDgvMW1YekNXRzJqM1hL?= =?utf-8?B?VXNTQUNyNlhxeXhNQlV5U2N3MVZNVnhWWnlkRUNFaUxNRjk4Zk0wcHY2Mk5Z?= =?utf-8?B?RXU3RmxycmxDVXhzMXZ4c2dKZERoQW1KcmIrQ2VobllLY3JhQVNuU0dLWVBC?= =?utf-8?B?Q1grbC9aSjVyUkdEQk50YW9WK1BXNDk2d2xwNGgzMmlSZTBLVmUyWFlkaGsr?= =?utf-8?B?RlJDNy8wM0hwQTlCaElKK2lZaHFHTm5ISDVnYmVBYTJGcTlQRzdpdUV1T0Qx?= =?utf-8?B?UG1BZW9VTzFOcGt2OEtBRzMyN1YyZUF6RTJHazdJcHh1SVp6cnB6Y1RmdFZE?= =?utf-8?B?eWViVlZGT3A4VTNsQ1dJQjZKcGtqV2x1d0VXYmdPZ0JzWTBrNW9qZE5mdlZT?= =?utf-8?B?UG5NTk8zUFBNOWs0RGdKVkllNjk5dlR5TXZyNG1OajkrNjA3anVBZTNHeVB2?= =?utf-8?B?UGQwdEREaVFqVEpkQ0hQalRua0xiOWNQVmtwT3JGZHdERjNFT2dLd3hJZWcz?= =?utf-8?B?d2Vhb3JHczVQSDFmeWFvVElNQWRsZ3hnQ05VeW5PVE92WmpiaEVxczFKOXdu?= =?utf-8?B?d3cyUWhkRmk3ZVB3bnZaMzE5SWxkdW1YcE4yai9PNy9VMXpZTGQrRENSMHBK?= =?utf-8?B?TVlybUp2SWVNRDVxU2Rjemd2cHRadmhkd1BtbUtaV0VCWk1wQjZDVFBwUVNv?= =?utf-8?B?WlByZE5waHRTQ25zMG1rR1JKaFkzcDBPV0l1ZFprcFI3VGt3MmNtclFsT2g1?= =?utf-8?B?bTB6VGFNbExPTlAzYlVJdG9xMlZERWI0MGhTWHU4RFZHbXdpTmZXcTVhZEIx?= =?utf-8?B?ZmNXRHRWY0tQeWNFbWtRZlJydkFTaVMvZ1h5YTg4a2V2UTlnUzJjNHVmZHZF?= =?utf-8?B?YkxNU1BNYUllejdVR3lZKzk2dEpZVXpaYVhNWU11d0toQVhDcjIxektORlZ5?= =?utf-8?B?MnN4cE41TmZVT1U5eCs3OXlEcXVwYnJDcHRkZnM0WGo2b0RHeXBlTWcyOURZ?= =?utf-8?B?Ly92K3Roa3B2eUo2SkpHaXZIR3Nmb2YveC9lMWZnME0wZkpmZTM0Yy9yNFpW?= =?utf-8?Q?BGpQHkmthQ2hZYTo=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e654c7d-a684-4071-2c7f-08df10184621 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 15:20:55.3819 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AJ39oE2SNwfDjr39Oor50HRwiaB4mmR0xYFl9tPsIJdEn9/SS6lkofdZT6Ucx/4ssfWkutI81loIfWT2CC4cgDs+qjMYJzANHc3R2Qsr980= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR03MB8142 X-purgate-ID: tlsNG-ef75cf/1789140059-3C411AE4-ABF2636B/0/0 X-purgate-type: clean X-purgate-size: 2859 On 11/09/2026 3:50 pm, Ross Lagerwall wrote: > On 9/11/26 2:36 PM, Andrew Cooper wrote: >> On 11/09/2026 2:23 pm, Ross Lagerwall wrote: >>> For multi-byte IO port accesses, the APM says that SVM should intercept >>> if any of the corresponding permission bits are set. However, the code >>> has this backwards and only intercepts if all the permission bits are >>> set. Fix this and at the same time, make things safer by handling >>> mapping failures as intercepted. Also rename the 'enabled' variable to >>> make it clearer what it does. >>> >>> This affects Hyper-V since it does not generally set all the permission >>> bits of the multi-byte ports it allows its root partition to access. >>> This results in an L2 root partition that cannot do PCI config space >>> accesses and therefore cannot access its NVMe disk to continue booting. >>> >>> Signed-off-by: Ross Lagerwall >> >> The reason I asked about 0xcf9 is because it's the one-byte PCH reset >> register, which hides fully inside the normal 4 bytes at 0xcf8 for CFG >> accesses. >> >> Despite outward appearances, the x86 IO space is not one uniform space. >> It's 3 orthogonal space (1,2 and 4-byte accesses) where the target >> device gets to choose whether muti-byte values alias in the spaces, or >> are entirely disjoint. >> >> For the HyperV root partition specifically, I'd expect 0xcf9 to be >> unintercepted so as not to interfere with the final steps of >> shutdown/reboot from the main kernel. >> >> The patch looks ok, but I think the second paragraph needs a bit more >> explaining.  Are we saying that because 0xcf9 was permitted, we allowed >> 4b@0xcf8 to be permitted, changing L1's CFG index rather than changing >> L2's CFG index, causing the subsequent 0xcfc access to produce garbage? >> > > Yes. The incorrect trace shows: > > L2 write 4b@0xcf8, permitted so it updates the L1 CFG index > L2 read  2b@0xcfc, VMEXITs to L1 > L1 write 4b@0xcf8, updates the L1 CFG index to the wrong value (since > it didn't > see the first L2 write) > L1 read  2b@0xcf8, reads the incorrect value from the device model in L0 > > How about this for the second paragraph? > > This affects Hyper-V which for the root partition intercepts 0xcf8 and > 0xcfc-0xcff. L2 issues 4 byte CFG index writes to 0xcf8 which are > incorrectly > permitted and update the L1 CFG index. The subsequent L2 CFG data read > at 0xcfc > is intercepted by L1, then resubmitted as a CFG index write followed > by CFG > data read to L0. Since L1 doesn't see the CFG index write by L2, it > uses the > wrong index and gets garbage back, ultimately leading to a failure to > boot > since it cannot access its NVMe disk. Yeah, much better.  I'll swap this in on commit. Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Sep 11 15:46:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 15:46:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417470.1646260 (Exim 4.92) (envelope-from ) id 1x53SF-0002Kr-AH; Fri, 11 Sep 2026 15:46:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417470.1646260; Fri, 11 Sep 2026 15:46:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x53SF-0002Kj-6j; Fri, 11 Sep 2026 15:46:19 +0000 Received: by outflank-mailman (input) for mailman id 1417470; Fri, 11 Sep 2026 15:46:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x53SC-0002JQ-LQ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:46:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x53SC-00BwcN-2H; Fri, 11 Sep 2026 17:46:16 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa42209-2eae-0a2a0a5409dd-0a2a450bb8e2-36 for ; Fri, 11 Sep 2026 17:46:15 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa42246-b7e8-0a2a450b0019-5a9b3222d35c-3 for ; Fri, 11 Sep 2026 17:46:15 +0200 Received: from [2001:8b0:10b:5:94db:d427:30c1:83c2] (helo=u09cd745991455d.ant.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1x53SA-0000000DKfd-07C7; Fri, 11 Sep 2026 15:46:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=gIHYNHCROZKG3aVeJiG/fQiUxw9cZbwtcWD+tmjaBvY=; b=gv7huPI7aYKoT52UhMchKESciX p5JqlqbK9lp3sZdmD/DBnw7r7NWV1z+fIKlT7vHgjcr6FjHpUhao/MgW+aSZaxmYvT+S3Mv1Qyjvj n3Ow4HUzAZ5o0UONs0ZujXQadSev6d9o1rbBEJ2ESztK0xzfncldj94ZcBiSmGLI6FCpjSRK89uWG HCRHTbX1cmif8KTjyM5VPRCxb12H8N2EeUzKpW5GAe9rKHZ6EKK7iUp+QiU4tWi0r3D/3XvdKnzNP tYjabzHCxd0IcCVm4p4/EkjJUsUTwP7VgWJzBUl0uLn9tja+4ZMWMvBuTZtv4/2jMYyRRUtjpYVXh jUwF3Q8A==; Message-ID: <36334cecd415d55e64a4b6b0668b3f75e1711445.camel@infradead.org> Subject: Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc From: David Woodhouse To: Peter Maydell Cc: mark.syms@citrix.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org, edgar.iglesias@gmail.com Date: Fri, 11 Sep 2026 16:45:43 +0100 In-Reply-To: References: <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-rKee+nlwj2jmqLKqT0Lq" User-Agent: Evolution 3.60.3-0ubuntu1~ppa10~24.04 MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-purgate-ID: tlsNG-42698a/1789141575-1B8D19EA-E04C3290/0/0 X-purgate-type: clean X-purgate-size: 13309 --=-rKee+nlwj2jmqLKqT0Lq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2026-09-11 at 15:56 +0100, Peter Maydell wrote: > On Fri, 11 Sept 2026 at 15:39, David Woodhouse wrot= e: > > I wasn't *actually* setting out to comment on the AI policy today=C2=A0= =E2=80=94 in > > fact I didn't really have a strong opinion on it. I spend enough of my > > life tilting at windmills *intentionally*; this wasn't meant to be one > > of them. > >=20 > > Letting the tool reply in its own voice and pretending I was held > > hostage was mostly meant as a joke, as *well* as being the only way I > > was going to look at that bug today (it would have taken me a *long* > > time to do all that testing of old and new failure modes, finding the > > net device path that *does* reproduce it locally, fixing the other > > problem with that, and finally confirming that it all works). >=20 > Even our current strict AI policy is fine with using them as tools > to help in debugging, testing, and so on. What I am complaining > about is not that you did that, but that you posted an enormous > long apparently unedited pile of output from the LLM, rather than > using it to do the work and then posting your conclusions. That > is asking readers of the thread to do a lot of work for you > (i.e. wading through the huge email to figure out whether the LLM > output is right, wrong or irrelevant). What makes you think I hadn't already iterated through it and ensured that was it was doing was right, relevant *and* sufficient? Did I miss something? (On this occasion, its original attempts were mostly lacking in the latter; I had to explicitly make it go and check on the things which were called out as open questions in the original mail. I cancelled its first draft after reading it, and made it try again.) Note that saying things which are wrong, irrelevant and insufficient is not solely the domain of AI. We see plenty of that from real people too. Bug reports, especially, have been the target of jokes for *decades* already. My favourite is still "dirty like zebra"=C2=B9. I also *did* preface that email with my conclusion agreeing that the solution was indeed to move one line of code, as well as an explicit statement that the remainder *was* the direct output (after numerous iterations of guidance) of the tool, covering all the details and open questions from the original. That original *also* looks very much like AI was involved in its drafting as well as the investigation, FWIW. Which is partly why there was so much to reply *to*. And let's look again at what my message *did* say: | I've done the gruntwork of confirming your diagnosis, re-testing the | 2023 crash that motivated commit 240cc11369fc, and verifying that the | fix shape you describe (defer only the InitWait transition until after | the implementation's realize method) addresses both without | reintroducing either. Even if someone didn't stop reading at "Claude here", that is actually fairly succinct given that I deliberately *didn't* rein it in or rewrite it this time, or even tell it "use a tenth of the words" as I often do. And then the reader has another chance to stop reading before it goes on with its "Summary of what was established" which confirms for the record that it *did* actually do its due diligence. I deliberately *didn't* reword that message, and I *did* clearly demark it for what it was, but honestly I wouldn't be embarrassed to have posted that as my own wording. It's just a tool. It's as useful as the person controlling it. > > But our policies should be based on actual data and the holistic > > outcomes they achieve, and this is just data which we can take into > > account on one side of the balance, even if the other side remains more > > compelling. >=20 > Yes. I view that email as pretty strong data for 'even a policy > shift which says "we're OK with accepting some kinds of AI > generated code" should still be pretty strong on "text intended > for humans to read (docs, commit messages, mailing list posts, etc) > should be written by humans"'. I think that review commentary on > Paolo's RFC about a less strict policy tended to be in that direction, > so I don't think I'm completely out on a limb here. Great. Happy to help provide real world data. Perhaps a variant to consider might be "text generated by AI must be clearly labelled as such" rather than barring it outright? =C2=B9 https://bugzilla.redhat.com/show_bug.cgi?id=3D61350 --=-rKee+nlwj2jmqLKqT0Lq Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK 72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9 0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213 MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm 6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6 bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO 02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91 LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8 +3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs +icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1 LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0 D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3 bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2 JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k 0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6 ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74 vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o 9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0yNjA5MTExNTQ1NDNaMC8GCSqGSIb3DQEJBDEiBCDOuzCUfs8tBhiV7basFX6TSmgb/AJI GkTUpJ6e/oEsBzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw DQYJKoZIhvcNAQEBBQAEggIAe3cZaG+UyolBSWMqvnvY2gUWkuhLe+ereFFWd5dJRbQdFiir1xi2 crbiUFt0DP+kpeqkJMp2KP1F8Pa4FI6xmoMBOfGZuXJQbymF256Oudn1jYU8K8Ton8mSjBi0vigs HisqNF6nL4MuN7CLgeDIg7oYv0h/cJlG68373AAlBm9ovAo2hp//VY0o2mZMEO0PsKA6s5o/SUQi BV5UTaKN6uH2z0B58h/IK6LKR6xko85nVU9KagsmZF288kxlQVRK2DgWplGMppjYVAKHeyfDcdOT qw0EzG8H8+u4AAyeXdcCzN10XAnUXtdES5eWVKodMhzqqg1XAhgGVhIwIzKhX4LToAIMWlrmlix7 YgLFe0IeC7XqpNp+/lpOPasNfGkzSIpYIntzpziD0Ly+/fktirXOhzDM70IbwuHm2poOfQUzMrBO sb9qohgjg6ouoj/kXAzRRPaGq3dMB3MnywPAP6cY/kDyJUkoKvW0Ar8YDB6Y/Nho3+oSihKUw1Yv y4cwFDeNj8vXGSnyUauQrIFh5xTEh9sgdlKBtRN0KOMyID3lbNwJWbaTt2xbF91NDfU0k/cyFgRE MQIFetw98BD3hwSjRVzskzXTbQiWsyirJM0go0PxKPCm4P2K1r8ChGz8MdW00yDA9pQp8ESz9uzT ToChihqrost1miyCWHHVmfoAAAAAAAA= --=-rKee+nlwj2jmqLKqT0Lq-- From xen-devel-bounces@lists.xenproject.org Fri Sep 11 15:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 15:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417489.1646268 (Exim 4.92) (envelope-from ) id 1x53a6-0005dQ-4Z; Fri, 11 Sep 2026 15:54:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417489.1646268; Fri, 11 Sep 2026 15:54:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x53a6-0005dJ-1q; Fri, 11 Sep 2026 15:54:26 +0000 Received: by outflank-mailman (input) for mailman id 1417489; Fri, 11 Sep 2026 15:54:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x53a4-0005c0-6h for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 15:54:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x53a3-006Fkd-Jm for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:54:23 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4242f-e002-0a2a0a5209dd-0a2a4502eb14-0 for ; Fri, 11 Sep 2026 17:54:23 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4242e-6ca4-0a2a45020019-aa0a817cbe01-3 for ; Fri, 11 Sep 2026 17:54:23 +0200 Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-173-dk6J6WxINLu-Ma5BynTPmg-1; Fri, 11 Sep 2026 11:54:17 -0400 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5F05818009E2; Fri, 11 Sep 2026 15:54:15 +0000 (UTC) Received: from redhat.com (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 44965195608F; Fri, 11 Sep 2026 15:54:12 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789142061; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PqFdjDZDSL4KFrLZvXicREIlIhrSfJCxxjgHKaNpYvg=; b=C0NUFIbvLzvtPbvRKMDT45V/4YjicywyJLAWh8dAtqvLKxBfhWv/1GdxuOhxe7PnSIhMSt 46MDVYMrjFX5sJgyQ4mHm+kgXkgTb2g9izy26sVVra0dD0n/XBnkoJXAjLBCnu7olDkdtT HvNZHc+PtpY8vGozSdBQjZe1ZUmiqYg= X-MC-Unique: dk6J6WxINLu-Ma5BynTPmg-1 X-Mimecast-MFC-AGG-ID: dk6J6WxINLu-Ma5BynTPmg_1789142056 Date: Fri, 11 Sep 2026 16:54:09 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Peter Maydell Cc: David Woodhouse , mark.syms@citrix.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org, edgar.iglesias@gmail.com Subject: Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.4.0 (2026-06-19) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: F8rfShCarDF8RFpB2KnT89wH4rqMn6x5nSOqqS7nzKU_1789142056 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789142063-F1CAA2AC-D270ECC3/0/0 X-purgate-type: clean X-purgate-size: 1812 On Fri, Sep 11, 2026 at 03:56:22PM +0100, Peter Maydell wrote: > On Fri, 11 Sept 2026 at 15:39, David Woodhouse wrote: > > I wasn't *actually* setting out to comment on the AI policy today — in > > fact I didn't really have a strong opinion on it. I spend enough of my > > life tilting at windmills *intentionally*; this wasn't meant to be one > > of them. snip > Yes. I view that email as pretty strong data for 'even a policy > shift which says "we're OK with accepting some kinds of AI > generated code" should still be pretty strong on "text intended > for humans to read (docs, commit messages, mailing list posts, etc) > should be written by humans"'. I think that review commentary on > Paolo's RFC about a less strict policy tended to be in that direction, > so I don't think I'm completely out on a limb here. The latest proposed policy explicitly forbids sending AI text to people: https://lists.gnu.org/archive/html/qemu-devel/2026-09/msg00260.html [quote] ### No AI-written text must reach maintainers These rules apply when publishing AI-assisted work to GitLab or the mailing list: - **AI-written cover letters and commit messages are banned**. These are easy to recognize and waste reviewers' time. - **AI-generated responses to reviewer comments are banned**. This undermines the human-to-human interaction fundamental to code review. - **AI-written issue ("work item") descriptions or comments are banned**. These are verbose and waste triagers' time. [/quote] With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| From xen-devel-bounces@lists.xenproject.org Fri Sep 11 16:40:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 16:40:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417561.1646277 (Exim 4.92) (envelope-from ) id 1x54I8-0000WX-B3; Fri, 11 Sep 2026 16:39:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417561.1646277; Fri, 11 Sep 2026 16:39:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54I8-0000WQ-7q; Fri, 11 Sep 2026 16:39:56 +0000 Received: by outflank-mailman (input) for mailman id 1417561; Fri, 11 Sep 2026 16:39:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54I6-0000WI-JI for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:39:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54I5-006L8m-T5 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 18:39:53 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa42ec2-e002-0a2a0a5209dd-0a2a450c99e4-38 for ; Fri, 11 Sep 2026 18:39:53 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa42ed8-f479-0a2a450c0019-aa0a857cee33-3 for ; Fri, 11 Sep 2026 18:39:53 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-694-UlP3wVwwN-SsTXEDvMc_9Q-1; Fri, 11 Sep 2026 12:39:47 -0400 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C59C01955F14; Fri, 11 Sep 2026 16:39:39 +0000 (UTC) Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 908D4433; Fri, 11 Sep 2026 16:39:34 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789144792; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n7kLKMCQpmhePPANiYhWYMYAMrriWH4JjeS/cBrPX8I=; b=GOf1z3g2gD8YkHuHGHXrybY7hmY+gm2bObavWrp4plaw4ECpRMvHXbZnBFGs+90r4T7Y7k kEaNHYu2GXIYKr93ZNLF1OHzL5Vvq6a21BX6Nh1+lU2WdH71sCTq5wKGmz+bZ+G7baC+Sx 42YDw+AdabW0LLwHKLLOKdTuEZbBnO8= X-MC-Unique: UlP3wVwwN-SsTXEDvMc_9Q-1 X-Mimecast-MFC-AGG-ID: UlP3wVwwN-SsTXEDvMc_9Q_1789144782 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Fri, 11 Sep 2026 20:35:09 +0400 Subject: [PATCH v5 35/62] qom: convert scalar properties to QAPI-aware registration MIME-Version: 1.0 Message-Id: <20260911-qom-qapi-v5-35-7732a55b7760@redhat.com> References: <20260911-qom-qapi-v5-0-7732a55b7760@redhat.com> In-Reply-To: <20260911-qom-qapi-v5-0-7732a55b7760@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Michael Roth , Pierrick Bouvier , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Amit Machhiwal , Alexander Graf , Richard Henderson , "Gonglei (Arei)" , zhenwei pi , David Hildenbrand , Igor Mammedov , Alberto Garcia , Kevin Wolf , Hanna Reitz , "Michael S. Tsirkin" , Ani Sinha , Peter Maydell , Luc Michel , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , =?utf-8?q?C=C3=A9dric_Le_Goater?= , Steven Lee , Troy Lee , Jamin Lin , Kane Chen , Andrew Jeffery , Joel Stanley , Samuel Tardieu , Marcelo Tosatti , John Snow , "Denis V. Lunev" , Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , FangSheng Huang , Tyrone Ting , Hao Wu , Jason Wang , Keith Busch , Klaus Jensen , Jesper Devantier , Nicholas Piggin , Aditya Gupta , Glenn Miles , Harsh Prateek Bora , Amit Machhiwal , Conor Dooley , Sebastian Huber , Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , Halil Pasic , Christian Borntraeger , Jason Herne , Cornelia Huck , Eric Farman , Matthew Rosato , Ilya Leoshkevich , Titus Rwantare , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Zhang Chen , Li Zhijian , Peter Xu , Chinmay Rath , Hendrik Brueckner , kvm@vger.kernel.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, linux-cxl@vger.kernel.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org X-Developer-Signature: v=1; a=openpgp-sha256; l=108182; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=mPg1F4fKLAvQtx73sQYbUGyKE/L5S5p7sMB8QV3n394=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqpC260yI9VAQcQ6aEdGdAMcElEGZpokov8qFTJ qDkKIVXTJOJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCaqQtugAKCRDa6OEJdZac 5R7qEACr2Hv512AspLmegcehc6w1nUlRMPxvkWPfM7Ug/f06heqWe4RbGPPsz7wCZXNM6/MDIM5 SGxBCQ7kFkOAXROlYyIyAABLuFl4Ij6jhN4CsltVLsPhaNsiTK/jQ55pdFWTtZmdTiHMyTcAChQ bK+8KqlNiACpj75rZFpNCuOJnqFlu2WKlTZIgNeVsKJ5sIpXd2Af1xAinycm4+fKg1xZ+M2Duuq CxZwnhKNhOWT4OqrrGw8tFyrR4CjAMcD2FBzDWOQjGvhjdzr0cRQf/46/35yYWQ6rdFZ42vQFc/ aGoK4Vv2/JMVmpGbCLVXOA3jaJvOkHFFavEbrOP8vtDBSmRR7BEQKd39IEhrpMUk+VbTlGDWfi9 slA7lL/v9ua+VMNgZ1W30jANsZ1kKXoj4ot00hdRaHaDKLpQy7WykqklUDQEhlJZ5+3d5tNFYXl 0sMS55Rgbx7bxwO7lpa0Ge3p3E02Do0hx02/kIecwjj4Q1kpyHYGNSMnIozZmgkig5IGgtC+4w7 qqsWB2x+cWfPHTlP7FGeh1lcl/99lOdruXWO+gqnknqlFCM6nDcTxWNZDyJWBXS+teubBPBC7B4 071cpuEuKQSR8H1eJN8ar0Y+CVjKlfuWCQGCOx08Iz2PgjpvLbaiiRWFYdJXzobhhjgE0GYVSVl 3B/NDidF+InlSLA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: GyN8XkCP2-k-WXjcu1vDSAFUDpmTJ6TaFSFOYxM4C9o_1789144782 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1789144793-51B359FB-E26671D8/0/0 X-purgate-type: clean X-purgate-size: 108184 Reviewed-by: Amit Machhiwal Signed-off-by: Marc-André Lureau --- accel/kvm/kvm-all.c | 5 ++- accel/nitro/nitro-accel.c | 3 +- accel/tcg/tcg-all.c | 3 +- backends/cryptodev.c | 7 ++-- backends/hostmem-file.c | 4 +- backends/hostmem-memfd.c | 3 +- backends/hostmem.c | 6 +-- block/throttle-groups.c | 5 ++- crypto/secret_keyring.c | 9 +++-- event-loop-base.c | 7 ++-- hw/acpi/ich9.c | 1 + hw/acpi/pci.c | 7 ++-- hw/arm/virt.c | 4 +- hw/core/clock.c | 3 +- hw/core/machine.c | 2 +- hw/cpu/core.c | 10 +++-- hw/cxl/cxl-host.c | 2 +- hw/gpio/aspeed_gpio.c | 5 ++- hw/gpio/aspeed_sgpio.c | 3 +- hw/gpio/stm32l4x5_gpio.c | 5 ++- hw/i386/pc.c | 6 +-- hw/i386/sgx-epc.c | 3 +- hw/i386/x86.c | 6 +-- hw/ide/ide-dev.c | 3 +- hw/intc/apic_common.c | 3 +- hw/loongarch/virt.c | 2 +- hw/mem/nvdimm.c | 7 ++-- hw/mem/pc-dimm.c | 3 +- hw/misc/aspeed_lpc.c | 73 +++++++++++++++++++++++++------------ hw/misc/aspeed_sdmc.c | 3 +- hw/misc/npcm7xx_mft.c | 3 +- hw/net/ne2000-isa.c | 3 +- hw/nvme/ctrl.c | 3 +- hw/pci-bridge/pci_expander_bridge.c | 3 +- hw/pci-host/i440fx.c | 29 +++++++++------ hw/pci-host/pnv_phb3.c | 5 ++- hw/pci-host/pnv_phb4.c | 5 ++- hw/pci-host/q35.c | 9 +++-- hw/ppc/spapr_drc.c | 3 +- hw/riscv/microchip_pfsoc.c | 3 +- hw/s390x/sclpcpi.c | 8 ++-- hw/s390x/virtio-ccw-mem.c | 3 +- hw/sensor/adc128d818.c | 16 +++++--- hw/sensor/adm1266.c | 3 +- hw/sensor/adm1272.c | 9 +++-- hw/sensor/emc141x.c | 9 +++-- hw/sensor/isl_pmbus_vr.c | 19 +++++----- hw/sensor/lsm303dlhc_mag.c | 9 +++-- hw/sensor/max34451.c | 5 ++- hw/sensor/tmp105.c | 3 +- hw/sensor/tmp421.c | 9 +++-- hw/usb/dev-storage-classic.c | 3 +- hw/virtio/virtio-balloon.c | 3 +- hw/virtio/virtio-mem-pci.c | 3 +- hw/virtio/virtio-mem.c | 18 +++++---- hw/xen/xen-pvh-common.c | 9 +++-- iothread.c | 9 +++-- net/colo-compare.c | 7 ++-- net/dump.c | 6 ++- net/filter-buffer.c | 3 +- qom/object.c | 42 ++++++++++----------- system/bootdevice.c | 3 +- system/memory.c | 5 ++- target/arm/cpu64.c | 11 +++--- target/arm/kvm.c | 3 +- target/arm/tcg/cpu64.c | 11 +++--- target/i386/cpu.c | 12 +++--- target/i386/kvm/kvm.c | 8 ++-- target/i386/sev.c | 2 +- target/ppc/compat.c | 3 +- target/riscv/cpu.c | 15 ++++---- target/riscv/kvm/kvm-cpu.c | 7 ++-- target/riscv/tcg/tcg-cpu.c | 13 ++++--- target/s390x/cpu_models.c | 5 ++- tests/unit/test-qdev-global-props.c | 11 ++++-- ui/console.c | 3 +- util/thread-context.c | 7 ++-- 77 files changed, 343 insertions(+), 241 deletions(-) diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index e2cfbcf44046..ff9db3ca8b3d 100644 --- a/accel/kvm/kvm-all.c +++ b/accel/kvm/kvm-all.c @@ -24,6 +24,7 @@ #include "qemu/config-file.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/pci/msi.h" #include "hw/pci/msix.h" #include "hw/s390x/adapter.h" @@ -4278,13 +4279,13 @@ static void kvm_accel_class_init(ObjectClass *oc, const void *data) .description = "Configure KVM in-kernel irqchip", )); - object_class_property_add(oc, "kvm-shadow-mem", "int", + object_class_property_add_qapi(oc, "kvm-shadow-mem", &int_type_info, kvm_get_kvm_shadow_mem, kvm_set_kvm_shadow_mem, NULL, NULL); object_class_property_set_description(oc, "kvm-shadow-mem", "KVM shadow MMU size"); - object_class_property_add(oc, "dirty-ring-size", "uint32", + object_class_property_add_qapi(oc, "dirty-ring-size", &uint32_type_info, kvm_get_dirty_ring_size, kvm_set_dirty_ring_size, NULL, NULL); object_class_property_set_description(oc, "dirty-ring-size", diff --git a/accel/nitro/nitro-accel.c b/accel/nitro/nitro-accel.c index a1e97a9162e9..05841c1277dc 100644 --- a/accel/nitro/nitro-accel.c +++ b/accel/nitro/nitro-accel.c @@ -29,6 +29,7 @@ #include "qemu/osdep.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qemu/rcu.h" @@ -238,7 +239,7 @@ static void nitro_accel_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, "debug-mode", "Start enclave in debug mode (enables console output)"); - object_class_property_add(oc, "enclave-cid", "uint64", + object_class_property_add_qapi(oc, "enclave-cid", &uint64_type_info, nitro_get_enclave_cid, nitro_set_enclave_cid, NULL, NULL); diff --git a/accel/tcg/tcg-all.c b/accel/tcg/tcg-all.c index 767e8805552f..277cf0e2d012 100644 --- a/accel/tcg/tcg-all.c +++ b/accel/tcg/tcg-all.c @@ -29,6 +29,7 @@ #include "exec/icount.h" #include "tcg/startup.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/error-report.h" #include "qemu/accel.h" #include "qemu/atomic.h" @@ -270,7 +271,7 @@ static void tcg_accel_class_init(ObjectClass *oc, const void *data) tcg_get_thread, tcg_set_thread); - object_class_property_add(oc, "tb-size", "uint32", + object_class_property_add_qapi(oc, "tb-size", &uint32_type_info, tcg_get_tb_size, tcg_set_tb_size, NULL, NULL); object_class_property_set_description(oc, "tb-size", diff --git a/backends/cryptodev.c b/backends/cryptodev.c index e8f2b18f2017..a69adb70440c 100644 --- a/backends/cryptodev.c +++ b/backends/cryptodev.c @@ -25,6 +25,7 @@ #include "system/cryptodev.h" #include "system/stats.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-commands-cryptodev.h" #include "qapi/qapi-types-stats.h" #include "qapi/visitor.h" @@ -622,15 +623,15 @@ cryptodev_backend_class_init(ObjectClass *oc, const void *data) ucc->prepare_delete = cryptodev_backend_prepare_delete; QTAILQ_INIT(&crypto_clients); - object_class_property_add(oc, "queues", "uint32", + object_class_property_add_qapi(oc, "queues", &uint32_type_info, cryptodev_backend_get_queues, cryptodev_backend_set_queues, NULL, NULL); - object_class_property_add(oc, "throttle-bps", "uint64", + object_class_property_add_qapi(oc, "throttle-bps", &uint64_type_info, cryptodev_backend_get_bps, cryptodev_backend_set_bps, NULL, NULL); - object_class_property_add(oc, "throttle-ops", "uint64", + object_class_property_add_qapi(oc, "throttle-ops", &uint64_type_info, cryptodev_backend_get_ops, cryptodev_backend_set_ops, NULL, NULL); diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c index 9c7e0183d480..aeb6fc37858c 100644 --- a/backends/hostmem-file.c +++ b/backends/hostmem-file.c @@ -275,11 +275,11 @@ file_backend_class_init(ObjectClass *oc, const void *data) file_memory_backend_get_discard_data, file_memory_backend_set_discard_data); object_class_property_add_str(oc, "mem-path", get_mem_path, set_mem_path); - object_class_property_add(oc, "align", "uint64", + object_class_property_add_qapi(oc, "align", &uint64_type_info, file_memory_backend_get_align, file_memory_backend_set_align, NULL, NULL); - object_class_property_add(oc, "offset", "int", + object_class_property_add_qapi(oc, "offset", &int_type_info, file_memory_backend_get_offset, file_memory_backend_set_offset, NULL, NULL); diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c index e21c5a3f2e24..42027529ab50 100644 --- a/backends/hostmem-memfd.c +++ b/backends/hostmem-memfd.c @@ -16,6 +16,7 @@ #include "qemu/memfd.h" #include "qemu/module.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qom/object.h" #include "migration/cpr.h" @@ -145,7 +146,7 @@ memfd_backend_class_init(ObjectClass *oc, const void *data) memfd_backend_set_hugetlb); object_class_property_set_description(oc, "hugetlb", "Use huge pages"); - object_class_property_add(oc, "hugetlbsize", "uint64", + object_class_property_add_qapi(oc, "hugetlbsize", &uint64_type_info, memfd_backend_get_hugetlbsize, memfd_backend_set_hugetlbsize, NULL, NULL); diff --git a/backends/hostmem.c b/backends/hostmem.c index e7f9b436a459..d05ab53ab662 100644 --- a/backends/hostmem.c +++ b/backends/hostmem.c @@ -529,7 +529,7 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data) host_memory_backend_set_prealloc); object_class_property_set_description(oc, "prealloc", "Preallocate memory"); - object_class_property_add(oc, "prealloc-threads", "int", + object_class_property_add_qapi(oc, "prealloc-threads", &int_type_info, host_memory_backend_get_prealloc_threads, host_memory_backend_set_prealloc_threads, NULL, NULL); @@ -540,13 +540,13 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data) object_property_allow_set_link, OBJ_PROP_LINK_STRONG); object_class_property_set_description(oc, "prealloc-context", "Context to use for creating CPU threads for preallocation"); - object_class_property_add(oc, "size", "size", + object_class_property_add_qapi(oc, "size", &size_type_info, host_memory_backend_get_size, host_memory_backend_set_size, NULL, NULL); object_class_property_set_description(oc, "size", "Size of the memory region (ex: 500M)"); - object_class_property_add(oc, "host-nodes", "[uint16]", + object_class_property_add_qapi(oc, "host-nodes", &uint16List_type_info, host_memory_backend_get_host_nodes, host_memory_backend_set_host_nodes, NULL, NULL); diff --git a/block/throttle-groups.c b/block/throttle-groups.c index 6312157802da..851617237f80 100644 --- a/block/throttle-groups.c +++ b/block/throttle-groups.c @@ -31,6 +31,7 @@ #include "qemu/thread.h" #include "system/qtest.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-type-infos-block-core.h" #include "qapi/qapi-visit-block-core.h" #include "qom/object.h" @@ -983,9 +984,9 @@ static void throttle_group_obj_class_init(ObjectClass *klass, /* individual properties */ for (i = 0; i < sizeof(properties) / sizeof(ThrottleParamInfo); i++) { - object_class_property_add(klass, + object_class_property_add_qapi(klass, properties[i].name, - "int64", + &int64_type_info, throttle_group_get, throttle_group_set, NULL, &properties[i]); diff --git a/crypto/secret_keyring.c b/crypto/secret_keyring.c index 3b332276ef5b..6ac7cd6a232d 100644 --- a/crypto/secret_keyring.c +++ b/crypto/secret_keyring.c @@ -21,6 +21,7 @@ #include "qemu/osdep.h" #include #include +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/error.h" #include "qom/object_interfaces.h" #include "trace.h" @@ -107,10 +108,10 @@ qcrypto_secret_keyring_class_init(ObjectClass *oc, const void *data) QCryptoSecretCommonClass *sic = QCRYPTO_SECRET_COMMON_CLASS(oc); sic->load_data = qcrypto_secret_keyring_load_data; - object_class_property_add(oc, "serial", "int32_t", - qcrypto_secret_prop_get_key, - qcrypto_secret_prop_set_key, - NULL, NULL); + object_class_property_add_qapi(oc, "serial", &int32_type_info, + qcrypto_secret_prop_get_key, + qcrypto_secret_prop_set_key, + NULL, NULL); } diff --git a/event-loop-base.c b/event-loop-base.c index 23f554d92ce8..c16c5366f680 100644 --- a/event-loop-base.c +++ b/event-loop-base.c @@ -14,6 +14,7 @@ #include "qemu/osdep.h" #include "qom/object_interfaces.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "block/thread-pool.h" #include "system/event-loop-base.h" @@ -104,15 +105,15 @@ static void event_loop_base_class_init(ObjectClass *klass, ucc->complete = event_loop_base_complete; ucc->prepare_delete = event_loop_base_prepare_delete; - object_class_property_add(klass, "aio-max-batch", "int64", + object_class_property_add_qapi(klass, "aio-max-batch", &int64_type_info, event_loop_base_get_param, event_loop_base_set_param, NULL, &aio_max_batch_info); - object_class_property_add(klass, "thread-pool-min", "int64", + object_class_property_add_qapi(klass, "thread-pool-min", &int64_type_info, event_loop_base_get_param, event_loop_base_set_param, NULL, &thread_pool_min_info); - object_class_property_add(klass, "thread-pool-max", "int64", + object_class_property_add_qapi(klass, "thread-pool-max", &int64_type_info, event_loop_base_get_param, event_loop_base_set_param, NULL, &thread_pool_max_info); diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c index 8082eae4282a..cf503668c00a 100644 --- a/hw/acpi/ich9.c +++ b/hw/acpi/ich9.c @@ -26,6 +26,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/pci/pci.h" #include "migration/vmstate.h" diff --git a/hw/acpi/pci.c b/hw/acpi/pci.c index c82924be8620..71d01307e141 100644 --- a/hw/acpi/pci.c +++ b/hw/acpi/pci.c @@ -27,6 +27,7 @@ #include "qemu/error-report.h" #include "qom/object_interfaces.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/core/boards.h" #include "hw/acpi/aml-build.h" #include "hw/acpi/pci.h" @@ -139,7 +140,7 @@ static void acpi_generic_initiator_class_init(ObjectClass *oc, const void *data) acpi_generic_initiator_set_pci_device); object_class_property_set_description(oc, "pci-dev", "PCI device to associate with the node"); - object_class_property_add(oc, "node", "uint32", NULL, + object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL, acpi_generic_initiator_set_node, NULL, NULL); object_class_property_set_description(oc, "node", "NUMA node associated with the PCI device"); @@ -253,8 +254,8 @@ static void acpi_generic_port_class_init(ObjectClass *oc, const void *data) acpi_generic_port_set_pci_bus); object_class_property_set_description(oc, "pci-bus", "PCI Bus of the host bridge associated with this GP affinity structure"); - object_class_property_add(oc, "node", "uint32", NULL, - acpi_generic_port_set_node, NULL, NULL); + object_class_property_add_qapi(oc, "node", &uint32_type_info, NULL, + acpi_generic_port_set_node, NULL, NULL); object_class_property_set_description(oc, "node", "The NUMA node like ID to index HMAT/SLIT NUMA properties involving GP"); } diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 872920b6482b..4e5d8d9f86e3 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -4258,7 +4258,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) "Set on/off to enable/disable high " "memory region for PCI MMIO"); - object_class_property_add(oc, "highmem-mmio-size", "size", + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_info, virt_get_highmem_mmio_size, virt_set_highmem_mmio_size, NULL, NULL); @@ -4266,7 +4266,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) "Set the high memory region size " "for PCI MMIO"); - object_class_property_add(oc, "virtio-mmio-transports", "uint8", + object_class_property_add_qapi(oc, "virtio-mmio-transports", &uint8_type_info, virt_get_virtio_transports, virt_set_virtio_transports, NULL, NULL); diff --git a/hw/core/clock.c b/hw/core/clock.c index 3fc98a0c65d5..f55cb17af77e 100644 --- a/hw/core/clock.c +++ b/hw/core/clock.c @@ -13,6 +13,7 @@ #include "qemu/osdep.h" #include "qemu/cutils.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "system/qtest.h" #include "hw/core/clock.h" @@ -185,7 +186,7 @@ static void clock_initfn(Object *obj) QLIST_INIT(&clk->children); if (qtest_enabled()) { - object_property_add(obj, "qtest-clock-period", "uint64", + object_property_add_qapi(obj, "qtest-clock-period", &uint64_type_info, clock_period_prop_get, NULL, NULL, NULL); } } diff --git a/hw/core/machine.c b/hw/core/machine.c index 530fbaeb0b28..aa2d90a4e4df 100644 --- a/hw/core/machine.c +++ b/hw/core/machine.c @@ -1133,7 +1133,7 @@ static void machine_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, "smp-cache", "Cache properties list for SMP machine"); - object_class_property_add(oc, "phandle-start", "int", + object_class_property_add_qapi(oc, "phandle-start", &int_type_info, machine_get_phandle_start, machine_set_phandle_start, NULL, NULL); object_class_property_set_description(oc, "phandle-start", diff --git a/hw/cpu/core.c b/hw/cpu/core.c index 26e488f3d8e3..d7c89f47ab04 100644 --- a/hw/cpu/core.c +++ b/hw/cpu/core.c @@ -12,6 +12,7 @@ #include "hw/core/boards.h" #include "hw/cpu/core.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" static void core_prop_get_core_id(Object *obj, Visitor *v, const char *name, @@ -82,10 +83,11 @@ static void cpu_core_class_init(ObjectClass *oc, const void *data) DeviceClass *dc = DEVICE_CLASS(oc); set_bit(DEVICE_CATEGORY_CPU, dc->categories); - object_class_property_add(oc, "core-id", "int", core_prop_get_core_id, - core_prop_set_core_id, NULL, NULL); - object_class_property_add(oc, "nr-threads", "int", core_prop_get_nr_threads, - core_prop_set_nr_threads, NULL, NULL); + object_class_property_add_qapi(oc, "core-id", &int_type_info, core_prop_get_core_id, + core_prop_set_core_id, NULL, NULL); + object_class_property_add_qapi(oc, "nr-threads", &int_type_info, + core_prop_get_nr_threads, core_prop_set_nr_threads, + NULL, NULL); } static const TypeInfo cpu_core_type_info = { diff --git a/hw/cxl/cxl-host.c b/hw/cxl/cxl-host.c index 7592c4ac6c7b..4133398fec48 100644 --- a/hw/cxl/cxl-host.c +++ b/hw/cxl/cxl-host.c @@ -565,7 +565,7 @@ static void machine_set_cfmw(Object *obj, Visitor *v, const char *name, void cxl_machine_init(Object *obj, CXLState *state) { - object_property_add(obj, "cxl", "bool", machine_get_cxl, + object_property_add_qapi(obj, "cxl", &bool_type_info, machine_get_cxl, machine_set_cxl, NULL, state); object_property_set_description(obj, "cxl", "Set on/off to enable/disable " diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c index 1cf6f5df5505..0c90bcd723da 100644 --- a/hw/gpio/aspeed_gpio.c +++ b/hw/gpio/aspeed_gpio.c @@ -12,6 +12,7 @@ #include "hw/gpio/aspeed_gpio.h" #include "hw/misc/aspeed_scu.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/irq.h" #include "migration/vmstate.h" @@ -1481,7 +1482,7 @@ static void aspeed_gpio_init(Object *obj) int pin_idx = j % GPIOS_PER_GROUP; const char *group = &props->group_label[group_idx][0]; char *name = g_strdup_printf("gpio%s%d", group, pin_idx); - object_property_add(obj, name, "bool", aspeed_gpio_get_pin, + object_property_add_qapi(obj, name, &bool_type_info, aspeed_gpio_get_pin, aspeed_gpio_set_pin, NULL, NULL); g_free(name); } @@ -1489,7 +1490,7 @@ static void aspeed_gpio_init(Object *obj) for (int i = 0; i < agc->nr_gpio_sets; i++) { g_autofree char *name = g_strdup_printf("gpio-set[%d]", i); - object_property_add(obj, name, "uint32", aspeed_gpio_get_set, + object_property_add_qapi(obj, name, &uint32_type_info, aspeed_gpio_get_set, aspeed_gpio_set_set, NULL, NULL); } } diff --git a/hw/gpio/aspeed_sgpio.c b/hw/gpio/aspeed_sgpio.c index 7d2f73699520..67b0c10d79fa 100644 --- a/hw/gpio/aspeed_sgpio.c +++ b/hw/gpio/aspeed_sgpio.c @@ -11,6 +11,7 @@ #include "qemu/log.h" #include "qemu/error-report.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/irq.h" #include "hw/core/qdev-properties.h" @@ -300,7 +301,7 @@ static void aspeed_sgpio_init(Object *obj) { for (int i = 0; i < ASPEED_SGPIO_MAX_PIN_PAIR * 2; i++) { g_autofree char *name = g_strdup_printf("sgpio%03d", i); - object_property_add(obj, name, "bool", aspeed_sgpio_get_pin, + object_property_add_qapi(obj, name, &bool_type_info, aspeed_sgpio_get_pin, aspeed_sgpio_set_pin, NULL, NULL); } } diff --git a/hw/gpio/stm32l4x5_gpio.c b/hw/gpio/stm32l4x5_gpio.c index 92fa397fbafe..d349d41e41a1 100644 --- a/hw/gpio/stm32l4x5_gpio.c +++ b/hw/gpio/stm32l4x5_gpio.c @@ -25,6 +25,7 @@ #include "hw/core/qdev-properties.h" #include "qapi/visitor.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "migration/vmstate.h" #include "trace.h" @@ -409,10 +410,10 @@ static void stm32l4x5_gpio_init(Object *obj) s->clk = qdev_init_clock_in(DEVICE(s), "clk", NULL, s, 0); - object_property_add(obj, "disconnected-pins", "uint16", + object_property_add_qapi(obj, "disconnected-pins", &uint16_type_info, disconnected_pins_get, disconnected_pins_set, NULL, &s->disconnected_pins); - object_property_add(obj, "clock-freq-hz", "uint32", + object_property_add_qapi(obj, "clock-freq-hz", &uint32_type_info, clock_freq_get, NULL, NULL, NULL); } diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 18b5dc169ab7..24c4c589ed04 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1720,7 +1720,7 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data) mc->default_ram_id = "pc.ram"; pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_AUTO; - object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size", + object_class_property_add_qapi(oc, PC_MACHINE_MAX_RAM_BELOW_4G, &size_type_info, pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g, NULL, NULL); object_class_property_set_description(oc, PC_MACHINE_MAX_RAM_BELOW_4G, @@ -1758,13 +1758,13 @@ static void pc_machine_class_init(ObjectClass *oc, const void *data) pc_machine_get_default_bus_bypass_iommu, pc_machine_set_default_bus_bypass_iommu); - object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size", + object_class_property_add_qapi(oc, PC_MACHINE_MAX_FW_SIZE, &size_type_info, pc_machine_get_max_fw_size, pc_machine_set_max_fw_size, NULL, NULL); object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE, "Maximum combined firmware size"); - object_class_property_add(oc, PC_MACHINE_SMBIOS_EP, "str", + object_class_property_add_qapi(oc, PC_MACHINE_SMBIOS_EP, &str_type_info, pc_machine_get_smbios_ep, pc_machine_set_smbios_ep, NULL, NULL); object_class_property_set_description(oc, PC_MACHINE_SMBIOS_EP, diff --git a/hw/i386/sgx-epc.c b/hw/i386/sgx-epc.c index d3fe10028c51..d9b9ab3f7a96 100644 --- a/hw/i386/sgx-epc.c +++ b/hw/i386/sgx-epc.c @@ -15,6 +15,7 @@ #include "hw/mem/memory-device.h" #include "hw/core/qdev-properties.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "target/i386/cpu.h" #include "system/address-spaces.h" @@ -43,7 +44,7 @@ static void sgx_epc_get_size(Object *obj, Visitor *v, const char *name, static void sgx_epc_init(Object *obj) { - object_property_add(obj, SGX_EPC_SIZE_PROP, "uint64", sgx_epc_get_size, + object_property_add_qapi(obj, SGX_EPC_SIZE_PROP, &uint64_type_info, sgx_epc_get_size, NULL, NULL, NULL); } diff --git a/hw/i386/x86.c b/hw/i386/x86.c index 63f297a10532..d0c782ec8544 100644 --- a/hw/i386/x86.c +++ b/hw/i386/x86.c @@ -420,9 +420,9 @@ static void x86_machine_class_init(ObjectClass *oc, const void *data) "in ACPI table header." "The string may be up to 8 bytes in size"); - object_class_property_add(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, "uint64_t", - x86_machine_get_bus_lock_ratelimit, - x86_machine_set_bus_lock_ratelimit, NULL, NULL); + object_class_property_add_qapi(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, &uint64_type_info, + x86_machine_get_bus_lock_ratelimit, + x86_machine_set_bus_lock_ratelimit, NULL, NULL); object_class_property_set_description(oc, X86_MACHINE_BUS_LOCK_RATELIMIT, "Set the ratelimit for the bus locks acquired in VMs"); diff --git a/hw/ide/ide-dev.c b/hw/ide/ide-dev.c index 5d478588c614..e2dd2439991f 100644 --- a/hw/ide/ide-dev.c +++ b/hw/ide/ide-dev.c @@ -19,6 +19,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-types-block.h" #include "qemu/error-report.h" #include "qemu/module.h" @@ -174,7 +175,7 @@ out: static void ide_dev_instance_init(Object *obj) { - object_property_add(obj, "bootindex", "int32", + object_property_add_qapi(obj, "bootindex", &int32_type_info, ide_dev_get_bootindex, ide_dev_set_bootindex, NULL, NULL); object_property_set_int(obj, "bootindex", -1, NULL); diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c index 0f0f37d45734..dc0517ceea90 100644 --- a/hw/intc/apic_common.c +++ b/hw/intc/apic_common.c @@ -22,6 +22,7 @@ #include "qemu/error-report.h" #include "qemu/module.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/i386/apic.h" #include "hw/i386/apic_internal.h" @@ -442,7 +443,7 @@ static void apic_common_initfn(Object *obj) APICCommonState *s = APIC_COMMON(obj); s->id = s->initial_apic_id = -1; - object_property_add(obj, "id", "uint32", + object_property_add_qapi(obj, "id", &uint32_type_info, apic_common_get_id, apic_common_set_id, NULL, NULL); } diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 750ce2dbe5fc..209a0feddd80 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -1520,7 +1520,7 @@ static void virt_class_init(ObjectClass *oc, const void *data) object_class_property_set_description(oc, "highmem-mmio", "Set on/off to enable/disable high " "memory region for PCI MMIO"); - object_class_property_add(oc, "highmem-mmio-size", "size", + object_class_property_add_qapi(oc, "highmem-mmio-size", &size_type_info, virt_get_highmem_mmio_size, virt_set_highmem_mmio_size, NULL, NULL); diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c index cf8a4d8c5f2a..123ddc938546 100644 --- a/hw/mem/nvdimm.c +++ b/hw/mem/nvdimm.c @@ -26,6 +26,7 @@ #include "qemu/module.h" #include "qemu/pmem.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/mem/nvdimm.h" #include "hw/core/qdev-properties.h" @@ -99,9 +100,9 @@ static void nvdimm_set_uuid(Object *obj, Visitor *v, const char *name, static void nvdimm_init(Object *obj) { - object_property_add(obj, NVDIMM_LABEL_SIZE_PROP, "size", - nvdimm_get_label_size, nvdimm_set_label_size, NULL, - NULL); + object_property_add_qapi(obj, NVDIMM_LABEL_SIZE_PROP, &size_type_info, + nvdimm_get_label_size, nvdimm_set_label_size, NULL, + NULL); object_property_add(obj, NVDIMM_UUID_PROP, "QemuUUID", nvdimm_get_uuid, nvdimm_set_uuid, NULL, NULL); diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c index 68862926ee2d..ee586ecc0c7d 100644 --- a/hw/mem/pc-dimm.c +++ b/hw/mem/pc-dimm.c @@ -26,6 +26,7 @@ #include "hw/mem/nvdimm.h" #include "hw/mem/memory-device.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "system/hostmem.h" @@ -176,7 +177,7 @@ static void pc_dimm_get_size(Object *obj, Visitor *v, const char *name, static void pc_dimm_init(Object *obj) { - object_property_add(obj, PC_DIMM_SIZE_PROP, "uint64", pc_dimm_get_size, + object_property_add_qapi(obj, PC_DIMM_SIZE_PROP, &uint64_type_info, pc_dimm_get_size, NULL, NULL, NULL); } diff --git a/hw/misc/aspeed_lpc.c b/hw/misc/aspeed_lpc.c index 7f7e4f1a0985..e2d9b7572f27 100644 --- a/hw/misc/aspeed_lpc.c +++ b/hw/misc/aspeed_lpc.c @@ -12,6 +12,7 @@ #include "qemu/error-report.h" #include "hw/misc/aspeed_lpc.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/irq.h" #include "hw/core/qdev-properties.h" @@ -417,30 +418,54 @@ static void aspeed_lpc_realize(DeviceState *dev, Error **errp) static void aspeed_lpc_init(Object *obj) { - object_property_add(obj, "idr1", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "odr1", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "str1", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "idr2", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "odr2", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "str2", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "idr3", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "odr3", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "str3", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "idr4", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "odr4", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); - object_property_add(obj, "str4", "uint32", aspeed_kcs_get_register_property, - aspeed_kcs_set_register_property, NULL, NULL); + object_property_add_qapi(obj, "idr1", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "odr1", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "str1", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "idr2", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "odr2", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "str2", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "idr3", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "odr3", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "str3", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "idr4", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "odr4", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); + object_property_add_qapi(obj, "str4", &uint32_type_info, + aspeed_kcs_get_register_property, + aspeed_kcs_set_register_property, + NULL, NULL); } static const VMStateDescription vmstate_aspeed_lpc = { diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c index f8fbaebee6ab..d096cc88f5c5 100644 --- a/hw/misc/aspeed_sdmc.c +++ b/hw/misc/aspeed_sdmc.c @@ -15,6 +15,7 @@ #include "hw/core/qdev-properties.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "trace.h" #include "qemu/units.h" #include "qemu/cutils.h" @@ -259,7 +260,7 @@ static void aspeed_sdmc_set_ram_size(Object *obj, Visitor *v, const char *name, static void aspeed_sdmc_initfn(Object *obj) { - object_property_add(obj, "ram-size", "int", + object_property_add_qapi(obj, "ram-size", &int_type_info, aspeed_sdmc_get_ram_size, aspeed_sdmc_set_ram_size, NULL, NULL); } diff --git a/hw/misc/npcm7xx_mft.c b/hw/misc/npcm7xx_mft.c index 742166c4e828..99e9e49788c0 100644 --- a/hw/misc/npcm7xx_mft.c +++ b/hw/misc/npcm7xx_mft.c @@ -23,6 +23,7 @@ #include "hw/core/registerfields.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/bitops.h" #include "qemu/error-report.h" @@ -491,7 +492,7 @@ static void npcm7xx_mft_init(Object *obj) s->clock_2 = qdev_init_clock_out(dev, "clock2"); for (int i = 0; i < NPCM7XX_PWM_PER_MODULE; ++i) { - object_property_add(obj, "max_rpm[*]", "uint32", + object_property_add_qapi(obj, "max_rpm[*]", &uint32_type_info, npcm7xx_mft_get_max_rpm, npcm7xx_mft_set_max_rpm, NULL, &s->max_rpm[i]); diff --git a/hw/net/ne2000-isa.c b/hw/net/ne2000-isa.c index 673c785abc94..63e0d40ee726 100644 --- a/hw/net/ne2000-isa.c +++ b/hw/net/ne2000-isa.c @@ -29,6 +29,7 @@ #include "ne2000.h" #include "system/system.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qom/object.h" @@ -131,7 +132,7 @@ out: static void isa_ne2000_instance_init(Object *obj) { - object_property_add(obj, "bootindex", "int32", + object_property_add_qapi(obj, "bootindex", &int32_type_info, isa_ne2000_get_bootindex, isa_ne2000_set_bootindex, NULL, NULL); object_property_set_int(obj, "bootindex", -1, NULL); diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c index c662d968db1e..a72189e0a63c 100644 --- a/hw/nvme/ctrl.c +++ b/hw/nvme/ctrl.c @@ -203,6 +203,7 @@ #include "qemu/units.h" #include "qemu/range.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "system/system.h" #include "system/block-backend.h" @@ -10578,7 +10579,7 @@ static void nvme_instance_init(Object *obj) "bootindex", "/namespace@1,0", DEVICE(obj)); - object_property_add(obj, "smart_critical_warning", "uint8", + object_property_add_qapi(obj, "smart_critical_warning", &uint8_type_info, nvme_get_smart_warning, nvme_set_smart_warning, NULL, NULL); } diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c index 40ffbc4e0821..9bb7d3c9debe 100644 --- a/hw/pci-bridge/pci_expander_bridge.c +++ b/hw/pci-bridge/pci_expander_bridge.c @@ -12,6 +12,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/pci/pci.h" #include "hw/pci/pci_bus.h" #include "hw/pci/pci_host.h" @@ -103,7 +104,7 @@ static void pxb_bus_class_init(ObjectClass *class, const void *data) pbc->bus_num = pxb_bus_num; pbc->numa_node = pxb_bus_numa_node; - object_class_property_add(class, "acpi_uid", "uint32", + object_class_property_add_qapi(class, "acpi_uid", &uint32_type_info, prop_pxb_uid_get, NULL, NULL, NULL); object_class_property_set_description(class, "acpi_uid", "ACPI Unique ID used to distinguish this PCI Host Bridge / ACPI00016"); diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c index c1982f7962a6..feafa6a72fe4 100644 --- a/hw/pci-host/i440fx.c +++ b/hw/pci-host/i440fx.c @@ -32,6 +32,7 @@ #include "hw/core/qdev-properties.h" #include "hw/core/sysbus.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "migration/vmstate.h" #include "qapi/visitor.h" #include "qemu/error-report.h" @@ -387,21 +388,25 @@ static void i440fx_pcihost_class_init(ObjectClass *klass, const void *data) /* Reason: needs to be wired up by pc_init1 */ dc->user_creatable = false; - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_START, "uint32", - i440fx_pcihost_get_pci_hole_start, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_START, + &uint32_type_info, + i440fx_pcihost_get_pci_hole_start, + NULL, NULL, NULL); - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE_END, "uint32", - i440fx_pcihost_get_pci_hole_end, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE_END, + &uint32_type_info, + i440fx_pcihost_get_pci_hole_end, + NULL, NULL, NULL); - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_START, "uint64", - i440fx_pcihost_get_pci_hole64_start, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_START, + &uint64_type_info, + i440fx_pcihost_get_pci_hole64_start, + NULL, NULL, NULL); - object_class_property_add(klass, PCI_HOST_PROP_PCI_HOLE64_END, "uint64", - i440fx_pcihost_get_pci_hole64_end, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, PCI_HOST_PROP_PCI_HOLE64_END, + &uint64_type_info, + i440fx_pcihost_get_pci_hole64_end, + NULL, NULL, NULL); } static const TypeInfo i440fx_pcihost_info = { diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c index db061c134e95..667e9585ab8f 100644 --- a/hw/pci-host/pnv_phb3.c +++ b/hw/pci-host/pnv_phb3.c @@ -11,6 +11,7 @@ #include "qemu/bswap.h" #include "qapi/visitor.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/pci-host/pnv_phb3_regs.h" #include "hw/pci-host/pnv_phb.h" #include "hw/pci-host/pnv_phb3.h" @@ -1164,12 +1165,12 @@ static void pnv_phb3_root_bus_class_init(ObjectClass *klass, const void *data) { BusClass *k = BUS_CLASS(klass); - object_class_property_add(klass, "phb-id", "uint32", + object_class_property_add_qapi(klass, "phb-id", &uint32_type_info, pnv_phb3_root_bus_get_prop, pnv_phb3_root_bus_set_prop, NULL, NULL); - object_class_property_add(klass, "chip-id", "uint32", + object_class_property_add_qapi(klass, "chip-id", &uint32_type_info, pnv_phb3_root_bus_get_prop, pnv_phb3_root_bus_set_prop, NULL, NULL); diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c index 9acaf4c0c2f5..96c2f89f889b 100644 --- a/hw/pci-host/pnv_phb4.c +++ b/hw/pci-host/pnv_phb4.c @@ -11,6 +11,7 @@ #include "qemu/bswap.h" #include "qapi/visitor.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "target/ppc/cpu.h" #include "hw/pci-host/pnv_phb4_regs.h" #include "hw/pci-host/pnv_phb4.h" @@ -1761,12 +1762,12 @@ static void pnv_phb4_root_bus_class_init(ObjectClass *klass, const void *data) { BusClass *k = BUS_CLASS(klass); - object_class_property_add(klass, "phb-id", "uint32", + object_class_property_add_qapi(klass, "phb-id", &uint32_type_info, pnv_phb4_root_bus_get_prop, pnv_phb4_root_bus_set_prop, NULL, NULL); - object_class_property_add(klass, "chip-id", "uint32", + object_class_property_add_qapi(klass, "chip-id", &uint32_type_info, pnv_phb4_root_bus_get_prop, pnv_phb4_root_bus_set_prop, NULL, NULL); diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c index f4556ad03a04..6eba30e06811 100644 --- a/hw/pci-host/q35.c +++ b/hw/pci-host/q35.c @@ -35,6 +35,7 @@ #include "hw/core/qdev-properties.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" @@ -226,19 +227,19 @@ static void q35_host_initfn(Object *obj) qdev_prop_set_uint64(DEVICE(s), PCI_HOST_PROP_PCI_HOLE64_SIZE, Q35_PCI_HOST_HOLE64_SIZE_DEFAULT); - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32", + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_START, &uint32_type_info, q35_host_get_pci_hole_start, NULL, NULL, NULL); - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_END, "uint32", + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE_END, &uint32_type_info, q35_host_get_pci_hole_end, NULL, NULL, NULL); - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_START, "uint64", + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_START, &uint64_type_info, q35_host_get_pci_hole64_start, NULL, NULL, NULL); - object_property_add(obj, PCI_HOST_PROP_PCI_HOLE64_END, "uint64", + object_property_add_qapi(obj, PCI_HOST_PROP_PCI_HOLE64_END, &uint64_type_info, q35_host_get_pci_hole64_end, NULL, NULL, NULL); diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c index 5c2150b71c86..64f9ca29b02e 100644 --- a/hw/ppc/spapr_drc.c +++ b/hw/ppc/spapr_drc.c @@ -12,6 +12,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qobject/qnull.h" #include "qemu/cutils.h" #include "hw/ppc/spapr_drc.h" @@ -584,7 +585,7 @@ static void spapr_dr_connector_instance_init(Object *obj) SpaprDrcClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc); object_property_add_uint32_ptr(obj, "id", &drc->id, OBJ_PROP_FLAG_READ); - object_property_add(obj, "index", "uint32", prop_get_index, + object_property_add_qapi(obj, "index", &uint32_type_info, prop_get_index, NULL, NULL, NULL); object_property_add(obj, "fdt", "struct", prop_get_fdt, NULL, NULL, NULL); diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c index edd29626fa07..e36063244bde 100644 --- a/hw/riscv/microchip_pfsoc.c +++ b/hw/riscv/microchip_pfsoc.c @@ -39,6 +39,7 @@ #include "qemu/units.h" #include "qemu/cutils.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/boards.h" #include "hw/core/loader.h" @@ -743,7 +744,7 @@ static void microchip_icicle_kit_machine_class_init(ObjectClass *oc, */ mc->default_ram_size = 1537 * MiB; - object_class_property_add(oc, "clint-timebase-frequency", "uint32_t", + object_class_property_add_qapi(oc, "clint-timebase-frequency", &uint32_type_info, microchip_icicle_kit_get_clint_timebase_freq, microchip_icicle_kit_set_clint_timebase_freq, NULL, NULL); diff --git a/hw/s390x/sclpcpi.c b/hw/s390x/sclpcpi.c index ec4bdf23509b..97d37ae4b932 100644 --- a/hw/s390x/sclpcpi.c +++ b/hw/s390x/sclpcpi.c @@ -53,6 +53,7 @@ #include "qemu/timer.h" #include "hw/s390x/event-facility.h" #include "hw/s390x/ebcdic.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-visit-machine.h" #include "qapi/qapi-events-machine-s390x.h" #include "migration/vmstate.h" @@ -195,12 +196,13 @@ static void cpi_class_init(ObjectClass *klass, const void *data) "name of the cluster which the VM belongs to, if any" " e.g. \"PLEX \""); - object_class_property_add(klass, "system_level", "uint64", get_system_level, - NULL, NULL, NULL); + object_class_property_add_qapi(klass, "system_level", + &uint64_type_info, get_system_level, + NULL, NULL, NULL); object_class_property_set_description(klass, "system_level", "distribution and kernel version in Linux e.g. 74872343805430528"); - object_class_property_add(klass, "timestamp", "uint64", get_timestamp, + object_class_property_add_qapi(klass, "timestamp", &uint64_type_info, get_timestamp, NULL, NULL, NULL); object_class_property_set_description(klass, "timestamp", "latest update of CPI data in nanoseconds since the UNIX EPOCH"); diff --git a/hw/s390x/virtio-ccw-mem.c b/hw/s390x/virtio-ccw-mem.c index dea30aacfb32..046dfd544cf3 100644 --- a/hw/s390x/virtio-ccw-mem.c +++ b/hw/s390x/virtio-ccw-mem.c @@ -13,6 +13,7 @@ #include "qemu/osdep.h" #include "hw/core/qdev-properties.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/module.h" #include "virtio-ccw-mem.h" #include "hw/mem/memory-device.h" @@ -205,7 +206,7 @@ static void virtio_ccw_mem_instance_init(Object *obj) OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZE_PROP); object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->vdev), VIRTIO_MEM_SIZE_PROP); - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, virtio_ccw_mem_get_requested_size, virtio_ccw_mem_set_requested_size, NULL, NULL); } diff --git a/hw/sensor/adc128d818.c b/hw/sensor/adc128d818.c index c65508cba144..7efc48a036ec 100644 --- a/hw/sensor/adc128d818.c +++ b/hw/sensor/adc128d818.c @@ -8,6 +8,7 @@ #include "qemu/osdep.h" #include "qemu/log.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/error.h" #include "qapi/visitor.h" #include "qom/object.h" @@ -642,15 +643,18 @@ static void adc128d818_initfn(Object *obj) for (unsigned ch = 0u; ch < ADC128D818_NUM_CHANNELS; ch++) { char *name = g_strdup_printf("ain%u", ch); - object_property_add(obj, name, "int", adc128d818_get_ain, - adc128d818_set_ain, NULL, NULL); + object_property_add_qapi(obj, name, &int_type_info, + adc128d818_get_ain, + adc128d818_set_ain, NULL, NULL); g_free(name); } - object_property_add(obj, "temperature", "int", adc128d818_get_temperature, - adc128d818_set_temperature, NULL, NULL); - object_property_add(obj, "ext-vref-mv", "int", adc128d818_get_ext_vref, - adc128d818_set_ext_vref, NULL, NULL); + object_property_add_qapi(obj, "temperature", &int_type_info, + adc128d818_get_temperature, + adc128d818_set_temperature, NULL, NULL); + object_property_add_qapi(obj, "ext-vref-mv", &int_type_info, + adc128d818_get_ext_vref, + adc128d818_set_ext_vref, NULL, NULL); } static void adc128d818_realize(DeviceState *dev, Error **errp) diff --git a/hw/sensor/adm1266.c b/hw/sensor/adm1266.c index 37d1cffd57a9..62f563af7a7a 100644 --- a/hw/sensor/adm1266.c +++ b/hw/sensor/adm1266.c @@ -14,6 +14,7 @@ #include "hw/core/irq.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/log.h" #include "qemu/module.h" @@ -217,7 +218,7 @@ static void adm1266_init(Object *obj) for (int i = 0; i < ADM1266_NUM_PAGES; i++) { pmbus_page_config(pmdev, i, flags); - object_property_add(obj, "vout[*]", "uint16", + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, adm1266_get, adm1266_set, NULL, &pmdev->pages[i].read_vout); } diff --git a/hw/sensor/adm1272.c b/hw/sensor/adm1272.c index 0aa2a8655683..e1c1bf1c54de 100644 --- a/hw/sensor/adm1272.c +++ b/hw/sensor/adm1272.c @@ -12,6 +12,7 @@ #include "hw/core/irq.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/log.h" #include "qemu/module.h" @@ -493,19 +494,19 @@ static void adm1272_init(Object *obj) pmbus_page_config(pmdev, 0, flags); - object_property_add(obj, "vin", "uint16", + object_property_add_qapi(obj, "vin", &uint16_type_info, adm1272_get, adm1272_set, NULL, &pmdev->pages[0].read_vin); - object_property_add(obj, "vout", "uint16", + object_property_add_qapi(obj, "vout", &uint16_type_info, adm1272_get, adm1272_set, NULL, &pmdev->pages[0].read_vout); - object_property_add(obj, "iout", "uint16", + object_property_add_qapi(obj, "iout", &uint16_type_info, adm1272_get, adm1272_set, NULL, &pmdev->pages[0].read_iout); - object_property_add(obj, "pin", "uint16", + object_property_add_qapi(obj, "pin", &uint16_type_info, adm1272_get, adm1272_set, NULL, &pmdev->pages[0].read_pin); diff --git a/hw/sensor/emc141x.c b/hw/sensor/emc141x.c index a51fc44395ab..5efe94643ca0 100644 --- a/hw/sensor/emc141x.c +++ b/hw/sensor/emc141x.c @@ -22,6 +22,7 @@ #include "hw/i2c/i2c.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qom/object.h" @@ -251,16 +252,16 @@ static void emc141x_reset(DeviceState *dev) static void emc141x_initfn(Object *obj) { - object_property_add(obj, "temperature0", "int", + object_property_add_qapi(obj, "temperature0", &int_type_info, emc141x_get_temperature, emc141x_set_temperature, NULL, NULL); - object_property_add(obj, "temperature1", "int", + object_property_add_qapi(obj, "temperature1", &int_type_info, emc141x_get_temperature, emc141x_set_temperature, NULL, NULL); - object_property_add(obj, "temperature2", "int", + object_property_add_qapi(obj, "temperature2", &int_type_info, emc141x_get_temperature, emc141x_set_temperature, NULL, NULL); - object_property_add(obj, "temperature3", "int", + object_property_add_qapi(obj, "temperature3", &int_type_info, emc141x_get_temperature, emc141x_set_temperature, NULL, NULL); } diff --git a/hw/sensor/isl_pmbus_vr.c b/hw/sensor/isl_pmbus_vr.c index 0fad04def773..8923e9e87510 100644 --- a/hw/sensor/isl_pmbus_vr.c +++ b/hw/sensor/isl_pmbus_vr.c @@ -9,6 +9,7 @@ #include "qemu/osdep.h" #include "hw/sensor/isl_pmbus_vr.h" #include "hw/core/qdev-properties.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/log.h" #include "qemu/module.h" @@ -136,63 +137,63 @@ static void isl_pmbus_vr_add_props(Object *obj, uint64_t *flags, uint8_t pages) PMBusDevice *pmdev = PMBUS_DEVICE(obj); for (int i = 0; i < pages; i++) { if (flags[i] & PB_HAS_VIN) { - object_property_add(obj, "vin[*]", "uint16", + object_property_add_qapi(obj, "vin[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_vin); } if (flags[i] & PB_HAS_VOUT) { - object_property_add(obj, "vout[*]", "uint16", + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_vout); } if (flags[i] & PB_HAS_IIN) { - object_property_add(obj, "iin[*]", "uint16", + object_property_add_qapi(obj, "iin[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_iin); } if (flags[i] & PB_HAS_IOUT) { - object_property_add(obj, "iout[*]", "uint16", + object_property_add_qapi(obj, "iout[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_iout); } if (flags[i] & PB_HAS_PIN) { - object_property_add(obj, "pin[*]", "uint16", + object_property_add_qapi(obj, "pin[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_pin); } if (flags[i] & PB_HAS_POUT) { - object_property_add(obj, "pout[*]", "uint16", + object_property_add_qapi(obj, "pout[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_pout); } if (flags[i] & PB_HAS_TEMPERATURE) { - object_property_add(obj, "temp1[*]", "uint16", + object_property_add_qapi(obj, "temp1[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_temperature_1); } if (flags[i] & PB_HAS_TEMP2) { - object_property_add(obj, "temp2[*]", "uint16", + object_property_add_qapi(obj, "temp2[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_temperature_2); } if (flags[i] & PB_HAS_TEMP3) { - object_property_add(obj, "temp3[*]", "uint16", + object_property_add_qapi(obj, "temp3[*]", &uint16_type_info, isl_pmbus_vr_get, isl_pmbus_vr_set, NULL, &pmdev->pages[i].read_temperature_3); diff --git a/hw/sensor/lsm303dlhc_mag.c b/hw/sensor/lsm303dlhc_mag.c index cd5773ae64e8..c8085739ca47 100644 --- a/hw/sensor/lsm303dlhc_mag.c +++ b/hw/sensor/lsm303dlhc_mag.c @@ -25,6 +25,7 @@ #include "hw/i2c/i2c.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qemu/log.h" @@ -509,19 +510,19 @@ static void lsm303dlhc_mag_reset(DeviceState *dev) */ static void lsm303dlhc_mag_initfn(Object *obj) { - object_property_add(obj, "mag-x", "int", + object_property_add_qapi(obj, "mag-x", &int_type_info, lsm303dlhc_mag_get_x, lsm303dlhc_mag_set_x, NULL, NULL); - object_property_add(obj, "mag-y", "int", + object_property_add_qapi(obj, "mag-y", &int_type_info, lsm303dlhc_mag_get_y, lsm303dlhc_mag_set_y, NULL, NULL); - object_property_add(obj, "mag-z", "int", + object_property_add_qapi(obj, "mag-z", &int_type_info, lsm303dlhc_mag_get_z, lsm303dlhc_mag_set_z, NULL, NULL); - object_property_add(obj, "temperature", "int", + object_property_add_qapi(obj, "temperature", &int_type_info, lsm303dlhc_mag_get_temperature, lsm303dlhc_mag_set_temperature, NULL, NULL); } diff --git a/hw/sensor/max34451.c b/hw/sensor/max34451.c index 4d64434f3af4..3c8fa3d4a861 100644 --- a/hw/sensor/max34451.c +++ b/hw/sensor/max34451.c @@ -11,6 +11,7 @@ #include "hw/core/irq.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/log.h" #include "qemu/module.h" @@ -727,7 +728,7 @@ static void max34451_init(Object *obj) /* get and set the voltage in millivolts, max is 32767 mV */ for (int i = 0; i < MAX34451_NUM_PWR_DEVICES; i++) { - object_property_add(obj, "vout[*]", "uint16", + object_property_add_qapi(obj, "vout[*]", &uint16_type_info, max34451_get, max34451_set, NULL, &pmdev->pages[i].read_vout); } @@ -737,7 +738,7 @@ static void max34451_init(Object *obj) * centidegrees Celsius i.e.: 2500 -> 25.00 C, max is 327.67 C */ for (int i = 0; i < MAX34451_NUM_TEMP_DEVICES; i++) { - object_property_add(obj, "temperature[*]", "uint16", + object_property_add_qapi(obj, "temperature[*]", &uint16_type_info, max34451_get, max34451_set, NULL, diff --git a/hw/sensor/tmp105.c b/hw/sensor/tmp105.c index ece0650d703f..5b6cc3ba2dc5 100644 --- a/hw/sensor/tmp105.c +++ b/hw/sensor/tmp105.c @@ -28,6 +28,7 @@ #include "qemu/osdep.h" #include "qemu/module.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qom/object.h" #include "hw/sensor/tmp105.h" @@ -408,7 +409,7 @@ static void tmp105_realize(DeviceState *dev, Error **errp) static void tmp105_initfn(Object *obj) { - object_property_add(obj, "temperature", "int", + object_property_add_qapi(obj, "temperature", &int_type_info, tmp105_get_temperature, tmp105_set_temperature, NULL, NULL); object_property_set_description(obj, "temperature", diff --git a/hw/sensor/tmp421.c b/hw/sensor/tmp421.c index 127edd0ba568..60844e76b21f 100644 --- a/hw/sensor/tmp421.c +++ b/hw/sensor/tmp421.c @@ -28,6 +28,7 @@ #include "hw/i2c/i2c.h" #include "migration/vmstate.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/module.h" #include "qom/object.h" @@ -350,16 +351,16 @@ static void tmp421_class_init(ObjectClass *klass, const void *data) dc->vmsd = &vmstate_tmp421; sc->dev = (DeviceInfo *) data; - object_class_property_add(klass, "temperature0", "int", + object_class_property_add_qapi(klass, "temperature0", &int_type_info, tmp421_get_temperature, tmp421_set_temperature, NULL, NULL); - object_class_property_add(klass, "temperature1", "int", + object_class_property_add_qapi(klass, "temperature1", &int_type_info, tmp421_get_temperature, tmp421_set_temperature, NULL, NULL); - object_class_property_add(klass, "temperature2", "int", + object_class_property_add_qapi(klass, "temperature2", &int_type_info, tmp421_get_temperature, tmp421_set_temperature, NULL, NULL); - object_class_property_add(klass, "temperature3", "int", + object_class_property_add_qapi(klass, "temperature3", &int_type_info, tmp421_get_temperature, tmp421_set_temperature, NULL, NULL); } diff --git a/hw/usb/dev-storage-classic.c b/hw/usb/dev-storage-classic.c index 977151c4a087..06584092bcae 100644 --- a/hw/usb/dev-storage-classic.c +++ b/hw/usb/dev-storage-classic.c @@ -9,6 +9,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/usb/usb.h" #include "hw/usb/desc.h" @@ -122,7 +123,7 @@ out: static void usb_msd_instance_init(Object *obj) { - object_property_add(obj, "bootindex", "int32", + object_property_add_qapi(obj, "bootindex", &int32_type_info, usb_msd_get_bootindex, usb_msd_set_bootindex, NULL, NULL); object_property_set_int(obj, "bootindex", -1, NULL); diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c index 4c5f486ba238..9e43948128f7 100644 --- a/hw/virtio/virtio-balloon.c +++ b/hw/virtio/virtio-balloon.c @@ -27,6 +27,7 @@ #include "hw/virtio/virtio-balloon.h" #include "system/address-spaces.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-events-machine.h" #include "qapi/visitor.h" #include "trace.h" @@ -1022,7 +1023,7 @@ static void virtio_balloon_instance_init(Object *obj) object_property_add(obj, "guest-stats", "guest statistics", balloon_stats_get_all, NULL, NULL, NULL); - object_property_add(obj, "guest-stats-polling-interval", "int", + object_property_add_qapi(obj, "guest-stats-polling-interval", &int_type_info, balloon_stats_get_poll_interval, balloon_stats_set_poll_interval, NULL, NULL); diff --git a/hw/virtio/virtio-mem-pci.c b/hw/virtio/virtio-mem-pci.c index f592eb1a7849..80e9bfedd9f5 100644 --- a/hw/virtio/virtio-mem-pci.c +++ b/hw/virtio/virtio-mem-pci.c @@ -14,6 +14,7 @@ #include "virtio-mem-pci.h" #include "hw/mem/memory-device.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-events-machine.h" #include "qapi/qapi-events-misc.h" @@ -211,7 +212,7 @@ static void virtio_mem_pci_instance_init(Object *obj) OBJECT(&dev->vdev), VIRTIO_MEM_BLOCK_SIZE_PROP); object_property_add_alias(obj, VIRTIO_MEM_SIZE_PROP, OBJECT(&dev->vdev), VIRTIO_MEM_SIZE_PROP); - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, virtio_mem_pci_get_requested_size, virtio_mem_pci_set_requested_size, NULL, NULL); } diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c index 7130ed852d9c..42dc028e3bdc 100644 --- a/hw/virtio/virtio-mem.c +++ b/hw/virtio/virtio-mem.c @@ -26,6 +26,7 @@ #include "hw/virtio/virtio-bus.h" #include "hw/virtio/virtio-mem.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "migration/misc.h" #include "hw/core/boards.h" @@ -1533,14 +1534,15 @@ static void virtio_mem_instance_init(Object *obj) notifier_list_init(&vmem->size_change_notifiers); - object_property_add(obj, VIRTIO_MEM_SIZE_PROP, "size", virtio_mem_get_size, - NULL, NULL, NULL); - object_property_add(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, "size", - virtio_mem_get_requested_size, - virtio_mem_set_requested_size, NULL, NULL); - object_property_add(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, "size", - virtio_mem_get_block_size, virtio_mem_set_block_size, - NULL, NULL); + object_property_add_qapi(obj, VIRTIO_MEM_SIZE_PROP, &size_type_info, + virtio_mem_get_size, + NULL, NULL, NULL); + object_property_add_qapi(obj, VIRTIO_MEM_REQUESTED_SIZE_PROP, &size_type_info, + virtio_mem_get_requested_size, + virtio_mem_set_requested_size, NULL, NULL); + object_property_add_qapi(obj, VIRTIO_MEM_BLOCK_SIZE_PROP, &size_type_info, + virtio_mem_get_block_size, virtio_mem_set_block_size, + NULL, NULL); } static void virtio_mem_instance_finalize(Object *obj) diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c index cca37202ffb2..7b4fd933a8fb 100644 --- a/hw/xen/xen-pvh-common.c +++ b/hw/xen/xen-pvh-common.c @@ -9,6 +9,7 @@ #include "qemu/osdep.h" #include "qemu/error-report.h" #include "qemu/units.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "hw/core/boards.h" #include "hw/core/irq.h" @@ -413,7 +414,7 @@ void xen_pvh_class_setup_common_props(XenPVHMachineClass *xpc) #define OC_MEMMAP_PROP_BASE(c, prop_name, name) \ do { \ - object_class_property_add(c, prop_name "-base", "uint64_t", \ + object_class_property_add_qapi(c, prop_name "-base", &uint64_type_info,\ xen_pvh_get_ ## name ## _base, \ xen_pvh_set_ ## name ## _base, NULL, NULL); \ object_class_property_set_description(oc, prop_name "-base", \ @@ -422,7 +423,7 @@ do { \ #define OC_MEMMAP_PROP_SIZE(c, prop_name, name) \ do { \ - object_class_property_add(c, prop_name "-size", "uint64_t", \ + object_class_property_add_qapi(c, prop_name "-size", &size_type_info, \ xen_pvh_get_ ## name ## _size, \ xen_pvh_set_ ## name ## _size, NULL, NULL); \ object_class_property_set_description(oc, prop_name "-size", \ @@ -458,7 +459,7 @@ do { \ OC_MEMMAP_PROP(oc, "pci-mmio", pci_mmio); OC_MEMMAP_PROP(oc, "pci-mmio-high", pci_mmio_high); - object_class_property_add(oc, "pci-intx-irq-base", "uint32_t", + object_class_property_add_qapi(oc, "pci-intx-irq-base", &uint32_type_info, xen_pvh_get_pci_intx_irq_base, xen_pvh_set_pci_intx_irq_base, NULL, NULL); @@ -468,7 +469,7 @@ do { \ #ifdef CONFIG_TPM if (xpc->has_tpm) { - object_class_property_add(oc, "tpm-base-addr", "uint64_t", + object_class_property_add_qapi(oc, "tpm-base-addr", &uint64_type_info, xen_pvh_get_tpm_base, xen_pvh_set_tpm_base, NULL, NULL); diff --git a/iothread.c b/iothread.c index 76eea6df3861..7285135d40a8 100644 --- a/iothread.c +++ b/iothread.c @@ -20,6 +20,7 @@ #include "system/event-loop-base.h" #include "system/iothread.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-commands-misc.h" #include "qemu/error-report.h" #include "qemu/rcu.h" @@ -315,19 +316,19 @@ static void iothread_class_init(ObjectClass *klass, const void *class_data) bc->init = iothread_init; bc->update_params = iothread_set_aio_context_params; - object_class_property_add(klass, "poll-max-ns", "int64", + object_class_property_add_qapi(klass, "poll-max-ns", &int64_type_info, iothread_get_poll_param, iothread_set_poll_param, NULL, &poll_max_ns_info); - object_class_property_add(klass, "poll-grow", "int64", + object_class_property_add_qapi(klass, "poll-grow", &int64_type_info, iothread_get_poll_param, iothread_set_poll_param, NULL, &poll_grow_info); - object_class_property_add(klass, "poll-shrink", "int64", + object_class_property_add_qapi(klass, "poll-shrink", &int64_type_info, iothread_get_poll_param, iothread_set_poll_param, NULL, &poll_shrink_info); - object_class_property_add(klass, "poll-weight", "int64", + object_class_property_add_qapi(klass, "poll-weight", &int64_type_info, iothread_get_poll_param, iothread_set_poll_param, NULL, &poll_weight_info); diff --git a/net/colo-compare.c b/net/colo-compare.c index a6910de869ff..4b237a59d120 100644 --- a/net/colo-compare.c +++ b/net/colo-compare.c @@ -16,6 +16,7 @@ #include "qemu/error-report.h" #include "trace.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "net/net.h" #include "net/eth.h" #include "qom/object_interfaces.h" @@ -1373,15 +1374,15 @@ static void colo_compare_init(Object *obj) object_property_add_str(obj, "notify_dev", compare_get_notify_dev, compare_set_notify_dev); - object_property_add(obj, "compare_timeout", "uint64", + object_property_add_qapi(obj, "compare_timeout", &uint64_type_info, compare_get_timeout, compare_set_timeout, NULL, NULL); - object_property_add(obj, "expired_scan_cycle", "uint32", + object_property_add_qapi(obj, "expired_scan_cycle", &uint32_type_info, compare_get_expired_scan_cycle, compare_set_expired_scan_cycle, NULL, NULL); - object_property_add(obj, "max_queue_size", "uint32", + object_property_add_qapi(obj, "max_queue_size", &uint32_type_info, get_max_queue_size, set_max_queue_size, NULL, NULL); diff --git a/net/dump.c b/net/dump.c index 0c39f09892c2..3d7bb36182ec 100644 --- a/net/dump.c +++ b/net/dump.c @@ -25,6 +25,7 @@ #include "qemu/osdep.h" #include "clients.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/error-report.h" #include "qemu/iov.h" #include "qemu/module.h" @@ -238,8 +239,9 @@ static void filter_dump_class_init(ObjectClass *oc, const void *data) { NetFilterClass *nfc = NETFILTER_CLASS(oc); - object_class_property_add(oc, "maxlen", "uint32", filter_dump_get_maxlen, - filter_dump_set_maxlen, NULL, NULL); + object_class_property_add_qapi(oc, "maxlen", &uint32_type_info, + filter_dump_get_maxlen, + filter_dump_set_maxlen, NULL, NULL); object_class_property_add_str(oc, "file", file_dump_get_filename, file_dump_set_filename); diff --git a/net/filter-buffer.c b/net/filter-buffer.c index 427da24097f2..9d7a9f5cb2c7 100644 --- a/net/filter-buffer.c +++ b/net/filter-buffer.c @@ -10,6 +10,7 @@ #include "net/filter.h" #include "net/queue.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/timer.h" #include "qemu/iov.h" #include "qapi/qapi-builtin-visit.h" @@ -182,7 +183,7 @@ static void filter_buffer_class_init(ObjectClass *oc, const void *data) { NetFilterClass *nfc = NETFILTER_CLASS(oc); - object_class_property_add(oc, "interval", "uint32", + object_class_property_add_qapi(oc, "interval", &uint32_type_info, filter_buffer_get_interval, filter_buffer_set_interval, NULL, NULL); diff --git a/qom/object.c b/qom/object.c index 8e6ca25dc49d..bbaa999ae0c9 100644 --- a/qom/object.c +++ b/qom/object.c @@ -22,9 +22,9 @@ #include "qapi/string-output-visitor.h" #include "qapi/qobject-input-visitor.h" #include "qapi/forward-visitor.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-builtin-visit.h" #include "qobject/qdict.h" -#include "qobject/qjson.h" #include "qemu/id.h" #include "qapi/qmp/qerror.h" #include "trace.h" @@ -2429,7 +2429,7 @@ object_property_add_str(Object *obj, const char *name, prop->get = get; prop->set = set; - return object_property_add(obj, name, "string", + return object_property_add_qapi(obj, name, &str_type_info, get ? property_get_str : NULL, set ? property_set_str : NULL, property_release_data, @@ -2447,7 +2447,7 @@ object_class_property_add_str(ObjectClass *klass, const char *name, prop->get = get; prop->set = set; - return object_class_property_add(klass, name, "string", + return object_class_property_add_qapi(klass, name, &str_type_info, get ? property_get_str : NULL, set ? property_set_str : NULL, NULL, @@ -2499,7 +2499,7 @@ object_property_add_bool(Object *obj, const char *name, prop->get = get; prop->set = set; - return object_property_add(obj, name, "bool", + return object_property_add_qapi(obj, name, &bool_type_info, get ? property_get_bool : NULL, set ? property_set_bool : NULL, property_release_data, @@ -2516,7 +2516,7 @@ object_class_property_add_bool(ObjectClass *klass, const char *name, prop->get = get; prop->set = set; - return object_class_property_add(klass, name, "bool", + return object_class_property_add_qapi(klass, name, &bool_type_info, get ? property_get_bool : NULL, set ? property_set_bool : NULL, NULL, @@ -2856,8 +2856,8 @@ object_property_add_uint8_ptr(Object *obj, const char *name, setter = property_set_uint8_ptr; } - return object_property_add(obj, name, "uint8", - getter, setter, NULL, (void *)v); + return object_property_add_qapi(obj, name, &uint8_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -2897,8 +2897,8 @@ object_class_static_property_add_uint8_ptr(ObjectClass *klass, setter = property_set_uint8_ptr; } - return object_class_property_add(klass, name, "uint8", - getter, setter, NULL, (void *)v); + return object_class_property_add_qapi(klass, name, &uint8_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -2917,8 +2917,8 @@ object_property_add_uint16_ptr(Object *obj, const char *name, setter = property_set_uint16_ptr; } - return object_property_add(obj, name, "uint16", - getter, setter, NULL, (void *)v); + return object_property_add_qapi(obj, name, &uint16_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -2958,8 +2958,8 @@ object_class_static_property_add_uint16_ptr(ObjectClass *klass, setter = property_set_uint16_ptr; } - return object_class_property_add(klass, name, "uint16", - getter, setter, NULL, (void *)v); + return object_class_property_add_qapi(klass, name, &uint16_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -2978,8 +2978,8 @@ object_property_add_uint32_ptr(Object *obj, const char *name, setter = property_set_uint32_ptr; } - return object_property_add(obj, name, "uint32", - getter, setter, NULL, (void *)v); + return object_property_add_qapi(obj, name, &uint32_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -3019,8 +3019,8 @@ object_class_static_property_add_uint32_ptr(ObjectClass *klass, setter = property_set_uint32_ptr; } - return object_class_property_add(klass, name, "uint32", - getter, setter, NULL, (void *)v); + return object_class_property_add_qapi(klass, name, &uint32_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -3039,8 +3039,8 @@ object_property_add_uint64_ptr(Object *obj, const char *name, setter = property_set_uint64_ptr; } - return object_property_add(obj, name, "uint64", - getter, setter, NULL, (void *)v); + return object_property_add_qapi(obj, name, &uint64_type_info, + getter, setter, NULL, (void *)v); } ObjectProperty * @@ -3080,8 +3080,8 @@ object_class_static_property_add_uint64_ptr(ObjectClass *klass, setter = property_set_uint64_ptr; } - return object_class_property_add(klass, name, "uint64", - getter, setter, NULL, (void *)v); + return object_class_property_add_qapi(klass, name, &uint64_type_info, + getter, setter, NULL, (void *)v); } typedef struct { diff --git a/system/bootdevice.c b/system/bootdevice.c index 9538b08983f5..7789e464186a 100644 --- a/system/bootdevice.c +++ b/system/bootdevice.c @@ -24,6 +24,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "system/system.h" #include "qapi/visitor.h" #include "qemu/error-report.h" @@ -336,7 +337,7 @@ void device_add_bootindex_property(Object *obj, int32_t *bootindex, prop->suffix = suffix; prop->dev = dev; - object_property_add(obj, name, "int32", + object_property_add_qapi(obj, name, &int32_type_info, device_get_bootindex, device_set_bootindex, property_release_bootindex, diff --git a/system/memory.c b/system/memory.c index 264dc90c0a55..72ecb3115496 100644 --- a/system/memory.c +++ b/system/memory.c @@ -16,6 +16,7 @@ #include "qemu/osdep.h" #include "qemu/log.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "system/memory.h" #include "qapi/visitor.h" #include "qemu/bitops.h" @@ -1293,11 +1294,11 @@ static void memory_region_initfn(Object *obj) object_property_add_uint64_ptr(OBJECT(mr), "addr", &mr->addr, OBJ_PROP_FLAG_READ); - object_property_add(OBJECT(mr), "priority", "int32", + object_property_add_qapi(OBJECT(mr), "priority", &int32_type_info, memory_region_get_priority, NULL, /* memory_region_set_priority */ NULL, NULL); - object_property_add(OBJECT(mr), "size", "uint64", + object_property_add_qapi(OBJECT(mr), "size", &uint64_type_info, memory_region_get_size, NULL, /* memory_region_set_size, */ NULL, NULL); diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c index 4e8c47253086..55df765e64d1 100644 --- a/target/arm/cpu64.c +++ b/target/arm/cpu64.c @@ -20,6 +20,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "cpu.h" #include "cpregs.h" #include "qemu/module.h" @@ -320,7 +321,7 @@ static void prop_bool_set_false(Object *obj, Visitor *v, const char *name, static void prop_add_stub_bool(Object *obj, const char *name) { - object_property_add(obj, name, "bool", prop_bool_get_false, + object_property_add_qapi(obj, name, &bool_type_info, prop_bool_get_false, prop_bool_set_false, NULL, NULL); } @@ -510,13 +511,13 @@ void aarch64_add_sve_properties(Object *obj) for (vq = 1; vq <= ARM_MAX_VQ; ++vq) { char name[8]; snprintf(name, sizeof(name), "sve%d", vq * 128); - object_property_add(obj, name, "bool", cpu_arm_get_vq, + object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_get_vq, cpu_arm_set_vq, NULL, &cpu->sve_vq); } #ifdef CONFIG_USER_ONLY /* Mirror linux /proc/sys/abi/sve_default_vector_length. */ - object_property_add(obj, "sve-default-vector-length", "int32", + object_property_add_qapi(obj, "sve-default-vector-length", &int32_type_info, cpu_arm_get_default_vec_len, cpu_arm_set_default_vec_len, NULL, &cpu->sve_default_vq); @@ -535,13 +536,13 @@ void aarch64_add_sme_properties(Object *obj) for (vq = 1; vq <= ARM_MAX_VQ; vq <<= 1) { char name[8]; snprintf(name, sizeof(name), "sme%d", vq * 128); - object_property_add(obj, name, "bool", cpu_arm_get_vq, + object_property_add_qapi(obj, name, &bool_type_info, cpu_arm_get_vq, cpu_arm_set_vq, NULL, &cpu->sme_vq); } #ifdef CONFIG_USER_ONLY /* Mirror linux /proc/sys/abi/sme_default_vector_length. */ - object_property_add(obj, "sme-default-vector-length", "int32", + object_property_add_qapi(obj, "sme-default-vector-length", &int32_type_info, cpu_arm_get_default_vec_len, cpu_arm_set_default_vec_len, NULL, &cpu->sme_default_vq); diff --git a/target/arm/kvm.c b/target/arm/kvm.c index ed99be7fd80c..198b7615f4cc 100644 --- a/target/arm/kvm.c +++ b/target/arm/kvm.c @@ -20,6 +20,7 @@ #include "qemu/main-loop.h" #include "qom/object.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "system/system.h" #include "system/runstate.h" #include "system/ramblock.h" @@ -1777,7 +1778,7 @@ static void kvm_arch_set_eager_split_size(Object *obj, Visitor *v, void kvm_arch_accel_class_init(ObjectClass *oc) { - object_class_property_add(oc, "eager-split-size", "size", + object_class_property_add_qapi(oc, "eager-split-size", &size_type_info, kvm_arch_get_eager_split_size, kvm_arch_set_eager_split_size, NULL, NULL); diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c index affd87a3ae55..da8d44f1fc61 100644 --- a/target/arm/tcg/cpu64.c +++ b/target/arm/tcg/cpu64.c @@ -20,6 +20,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "cpu.h" #include "qemu/module.h" #include "qapi/visitor.h" @@ -1392,9 +1393,9 @@ void aarch64_max_v8_tcg_initfn(Object *obj) /* v8.2: FEAT_SVE */ cpu->sve_vq.supported = MAKE_64BIT_MASK(0, ARM_MAX_VQ); aarch64_add_sve_properties(OBJECT(cpu)); - object_property_add(OBJECT(cpu), "sve-max-vq", "uint32", - cpu_max_get_sve_max_vq, cpu_max_set_sve_max_vq, - NULL, NULL); + object_property_add_qapi(OBJECT(cpu), "sve-max-vq", &uint32_type_info, + cpu_max_get_sve_max_vq, + cpu_max_set_sve_max_vq, NULL, NULL); /* v8.2: FEAT_PAuth2 */ aarch64_add_pauth_properties(OBJECT(cpu)); @@ -1524,8 +1525,8 @@ void aarch64_max_v9_tcg_initfn(Object *obj) object_property_add_bool(obj, "x-rme", cpu_arm_get_rme, cpu_arm_set_rme); /* v9.4: FEAT_RME_GPC2 */ - object_property_add(obj, "x-l0gptsz", "uint32", cpu_max_get_l0gptsz, - cpu_max_set_l0gptsz, NULL, NULL); + object_property_add_qapi(obj, "x-l0gptsz", &uint32_type_info, cpu_max_get_l0gptsz, + cpu_max_set_l0gptsz, NULL, NULL); } static const ARMCPUInfo aarch64_cpus[] = { diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 8650ff6caecc..ebce8e128224 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -10431,7 +10431,7 @@ static void x86_cpu_register_bit_prop(X86CPUClass *xcc, fp = g_new0(BitProperty, 1); fp->w = w; fp->mask = mask; - object_class_property_add(oc, prop_name, "bool", + object_class_property_add_qapi(oc, prop_name, &bool_type_info, x86_cpu_get_bit_prop, x86_cpu_set_bit_prop, NULL, fp); @@ -10950,13 +10950,13 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) dc->user_creatable = true; - object_class_property_add(oc, "family", "uint64", + object_class_property_add_qapi(oc, "family", &uint64_type_info, x86_cpuid_version_get_family, x86_cpuid_version_set_family, NULL, NULL); - object_class_property_add(oc, "model", "uint64", + object_class_property_add_qapi(oc, "model", &uint64_type_info, x86_cpuid_version_get_model, x86_cpuid_version_set_model, NULL, NULL); - object_class_property_add(oc, "stepping", "uint64", + object_class_property_add_qapi(oc, "stepping", &uint64_type_info, x86_cpuid_version_get_stepping, x86_cpuid_version_set_stepping, NULL, NULL); object_class_property_add_str(oc, "vendor", @@ -10965,7 +10965,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) object_class_property_add_str(oc, "model-id", x86_cpuid_get_model_id, x86_cpuid_set_model_id); - object_class_property_add(oc, "tsc-frequency", "int", + object_class_property_add_qapi(oc, "tsc-frequency", &int_type_info, x86_cpuid_get_tsc_freq, x86_cpuid_set_tsc_freq, NULL, NULL); /* @@ -10978,7 +10978,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, const void *data) x86_cpu_get_unavailable_features, NULL, NULL, NULL); - object_class_property_add(oc, "avx10-version", "uint8", + object_class_property_add_qapi(oc, "avx10-version", &uint8_type_info, x86_cpuid_get_avx10_version, x86_cpuid_set_avx10_version, NULL, NULL); diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index 9f65419a2c1a..aa4967adf99e 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -7099,7 +7099,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc) .set = kvm_arch_set_notify_vmexit, )); - object_class_property_add(oc, "notify-window", "uint32", + object_class_property_add_qapi(oc, "notify-window", &uint32_type_info, kvm_arch_get_notify_window, kvm_arch_set_notify_window, NULL, NULL); @@ -7107,7 +7107,7 @@ void kvm_arch_accel_class_init(ObjectClass *oc) "Clock cycles without an event window " "after which a notification VM exit occurs"); - object_class_property_add(oc, "xen-version", "uint32", + object_class_property_add_qapi(oc, "xen-version", &uint32_type_info, kvm_arch_get_xen_version, kvm_arch_set_xen_version, NULL, NULL); @@ -7116,14 +7116,14 @@ void kvm_arch_accel_class_init(ObjectClass *oc) "(in XENVER_version form " "e.g. 0x4000a for 4.10)"); - object_class_property_add(oc, "xen-gnttab-max-frames", "uint16", + object_class_property_add_qapi(oc, "xen-gnttab-max-frames", &uint16_type_info, kvm_arch_get_xen_gnttab_max_frames, kvm_arch_set_xen_gnttab_max_frames, NULL, NULL); object_class_property_set_description(oc, "xen-gnttab-max-frames", "Maximum number of grant table frames"); - object_class_property_add(oc, "xen-evtchn-max-pirq", "uint16", + object_class_property_add_qapi(oc, "xen-evtchn-max-pirq", &uint16_type_info, kvm_arch_get_xen_evtchn_max_pirq, kvm_arch_set_xen_evtchn_max_pirq, NULL, NULL); diff --git a/target/i386/sev.c b/target/i386/sev.c index b2c7260c80a4..3a36fa4d0b95 100644 --- a/target/i386/sev.c +++ b/target/i386/sev.c @@ -3266,7 +3266,7 @@ sev_snp_guest_class_init(ObjectClass *oc, const void *data) x86_klass->adjust_cpuid_features = sev_snp_adjust_cpuid_features; x86_klass->kvm_type = sev_snp_kvm_type; - object_class_property_add(oc, "policy", "uint64", + object_class_property_add_qapi(oc, "policy", &uint64_type_info, sev_snp_guest_get_policy, sev_snp_guest_set_policy, NULL, NULL); object_class_property_add_str(oc, "guest-visible-workarounds", diff --git a/target/ppc/compat.c b/target/ppc/compat.c index 55de3bd5d5de..4d81225de37f 100644 --- a/target/ppc/compat.c +++ b/target/ppc/compat.c @@ -23,6 +23,7 @@ #include "kvm_ppc.h" #include "system/cpus.h" #include "qemu/error-report.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/error.h" #include "qapi/visitor.h" #include "cpu-models.h" @@ -335,7 +336,7 @@ void ppc_compat_add_property(Object *obj, const char *name, gchar *names, *desc; int i; - object_property_add(obj, name, "string", + object_property_add_qapi(obj, name, &str_type_info, ppc_compat_prop_get, ppc_compat_prop_set, NULL, compat_pvr); diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 5fff9d745e9b..bd3fa786ee40 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -27,6 +27,7 @@ #include "target/riscv/tcg/csr.h" #include "internals.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/error-report.h" #include "qemu/timer.h" @@ -1396,20 +1397,20 @@ void riscv_add_satp_mode_properties(Object *obj) { RISCVCPU *cpu = RISCV_CPU(obj); - object_property_add(obj, "svbare", "bool", cpu_riscv_get_satp, - cpu_riscv_set_satp, NULL, &cpu->satp_modes); + object_property_add_qapi(obj, "svbare", &bool_type_info, cpu_riscv_get_satp, + cpu_riscv_set_satp, NULL, &cpu->satp_modes); if (cpu->env.misa_mxl == MXL_RV32) { - object_property_add(obj, "sv32", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv32", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); } else { - object_property_add(obj, "sv39", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv39", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); - object_property_add(obj, "sv48", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv48", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); - object_property_add(obj, "sv57", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv57", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); - object_property_add(obj, "sv64", "bool", cpu_riscv_get_satp, + object_property_add_qapi(obj, "sv64", &bool_type_info, cpu_riscv_get_satp, cpu_riscv_set_satp, NULL, &cpu->satp_modes); } } diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c index 68e1501b21e2..d2d6cb7a4c66 100644 --- a/target/riscv/kvm/kvm-cpu.c +++ b/target/riscv/kvm/kvm-cpu.c @@ -24,6 +24,7 @@ #include "qemu/timer.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/error-report.h" #include "qemu/main-loop.h" #include "qapi/visitor.h" @@ -532,7 +533,7 @@ static void riscv_cpu_add_kvm_unavail_prop(Object *obj, const char *prop_name) * unknown to KVM and error out if the user attempts * to enable any of them. */ - object_property_add(obj, prop_name, "bool", + object_property_add_qapi(obj, prop_name, &bool_type_info, cpu_get_cfg_unavailable, cpu_set_cfg_unavailable, NULL, (void *)prop_name); @@ -552,7 +553,7 @@ static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj) misa_cfg->name = riscv_get_misa_ext_name(bit); misa_cfg->description = riscv_get_misa_ext_description(bit); - object_property_add(cpu_obj, misa_cfg->name, "bool", + object_property_add_qapi(cpu_obj, misa_cfg->name, &bool_type_info, kvm_cpu_get_misa_ext_cfg, kvm_cpu_set_misa_ext_cfg, NULL, misa_cfg); @@ -568,7 +569,7 @@ static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj) for (i = 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) { KVMCPUConfig *multi_cfg = &kvm_multi_ext_cfgs[i]; - object_property_add(cpu_obj, multi_cfg->name, "bool", + object_property_add_qapi(cpu_obj, multi_cfg->name, &bool_type_info, kvm_cpu_get_multi_ext_cfg, kvm_cpu_set_multi_ext_cfg, NULL, multi_cfg); diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c index b68160af8307..6f3e1e10eb04 100644 --- a/target/riscv/tcg/tcg-cpu.c +++ b/target/riscv/tcg/tcg-cpu.c @@ -26,6 +26,7 @@ #include "pmu.h" #include "time_helper.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qemu/accel.h" #include "qemu/error-report.h" @@ -1437,7 +1438,7 @@ static void riscv_cpu_add_misa_properties(Object *cpu_obj) continue; } - object_property_add(cpu_obj, name, "bool", + object_property_add_qapi(cpu_obj, name, &bool_type_info, cpu_get_misa_ext_cfg, cpu_set_misa_ext_cfg, NULL, (void *)misa_cfg); @@ -1491,7 +1492,7 @@ static void riscv_cpu_add_profiles(Object *cpu_obj) for (int i = 0; riscv_profiles[i] != NULL; i++) { RISCVCPUProfile *profile = riscv_profiles[i]; - object_property_add(cpu_obj, profile->name, "bool", + object_property_add_qapi(cpu_obj, profile->name, &bool_type_info, cpu_get_profile, cpu_set_profile, NULL, (void *)profile); @@ -1567,10 +1568,10 @@ static void riscv_cpu_add_user_properties(Object *obj) for (edata = isa_edata_arr; edata && edata->name; edata++) { if (edata->prop_name) { - object_property_add(obj, edata->prop_name, "bool", - cpu_get_multi_ext_cfg, - cpu_set_multi_ext_cfg, - NULL, (void *)&edata->ext_enable_offset); + object_property_add_qapi(obj, edata->prop_name, &bool_type_info, + cpu_get_multi_ext_cfg, + cpu_set_multi_ext_cfg, + NULL, (void *)&edata->ext_enable_offset); } } diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c index c41d629d6803..72bf0f48de83 100644 --- a/target/s390x/cpu_models.c +++ b/target/s390x/cpu_models.c @@ -17,6 +17,7 @@ #include "system/kvm.h" #include "system/tcg.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qemu/error-report.h" #include "qapi/visitor.h" #include "qemu/module.h" @@ -915,13 +916,13 @@ void s390_cpu_model_class_register_props(ObjectClass *oc) for (feat = 0; feat < S390_FEAT_MAX; feat++) { const S390FeatDef *def = s390_feat_def(feat); - object_class_property_add(oc, def->name, "bool", get_feature, + object_class_property_add_qapi(oc, def->name, &bool_type_info, get_feature, set_feature, NULL, (void *) feat); object_class_property_set_description(oc, def->name, def->desc); } for (group = 0; group < S390_FEAT_GROUP_MAX; group++) { const S390FeatGroupDef *def = s390_feat_group_def(group); - object_class_property_add(oc, def->name, "bool", get_feature_group, + object_class_property_add_qapi(oc, def->name, &bool_type_info, get_feature_group, set_feature_group, NULL, (void *) group); object_class_property_set_description(oc, def->name, def->desc); } diff --git a/tests/unit/test-qdev-global-props.c b/tests/unit/test-qdev-global-props.c index 8ea362cbb902..204436fb7276 100644 --- a/tests/unit/test-qdev-global-props.c +++ b/tests/unit/test-qdev-global-props.c @@ -27,6 +27,7 @@ #include "hw/core/qdev-properties.h" #include "qom/object.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" @@ -171,10 +172,12 @@ static void prop2_accessor(Object *obj, Visitor *v, const char *name, static void dynamic_instance_init(Object *obj) { - object_property_add(obj, "prop1", "uint32", prop1_accessor, prop1_accessor, - NULL, NULL); - object_property_add(obj, "prop2", "uint32", prop2_accessor, prop2_accessor, - NULL, NULL); + object_property_add_qapi(obj, "prop1", &uint32_type_info, + prop1_accessor, prop1_accessor, + NULL, NULL); + object_property_add_qapi(obj, "prop2", &uint32_type_info, + prop2_accessor, prop2_accessor, + NULL, NULL); } static void dynamic_class_init(ObjectClass *oc, const void *data) diff --git a/ui/console.c b/ui/console.c index 14f148118e37..ee280eedf3da 100644 --- a/ui/console.c +++ b/ui/console.c @@ -28,6 +28,7 @@ #include "ui/vgafont.h" #include "hw/core/qdev.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-commands-ui.h" #include "qapi/visitor.h" #include "qemu/coroutine.h" @@ -535,7 +536,7 @@ qemu_graphic_console_class_init(ObjectClass *oc, const void *data) offsetof(QemuGraphicConsole, device), object_property_allow_set_link, OBJ_PROP_LINK_STRONG); - object_class_property_add(oc, "head", "uint32", + object_class_property_add_qapi(oc, "head", &uint32_type_info, qemu_graphic_console_prop_get_head, NULL, NULL, NULL); diff --git a/util/thread-context.c b/util/thread-context.c index 88d8f0a55a4e..7fa6840dd401 100644 --- a/util/thread-context.c +++ b/util/thread-context.c @@ -13,6 +13,7 @@ #include "qemu/osdep.h" #include "qemu/thread-context.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/qapi-builtin-visit.h" #include "qapi/visitor.h" #include "qemu/config-file.h" @@ -278,13 +279,13 @@ static void thread_context_class_init(ObjectClass *oc, const void *data) UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc); ucc->complete = thread_context_instance_complete; - object_class_property_add(oc, "thread-id", "uint64", + object_class_property_add_qapi(oc, "thread-id", &uint64_type_info, thread_context_get_thread_id, NULL, NULL, NULL); - object_class_property_add(oc, "cpu-affinity", "[uint16]", + object_class_property_add_qapi(oc, "cpu-affinity", &uint16List_type_info, thread_context_get_cpu_affinity, thread_context_set_cpu_affinity, NULL, NULL); - object_class_property_add(oc, "node-affinity", "[uint16]", NULL, + object_class_property_add_qapi(oc, "node-affinity", &uint16List_type_info, NULL, thread_context_set_node_affinity, NULL, NULL); } -- 2.55.0.543.g5ebe2ebe4ea8 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 16:40:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 16:40:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417571.1646286 (Exim 4.92) (envelope-from ) id 1x54J1-00029N-Nq; Fri, 11 Sep 2026 16:40:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417571.1646286; Fri, 11 Sep 2026 16:40:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54J1-00029G-Kk; Fri, 11 Sep 2026 16:40:51 +0000 Received: by outflank-mailman (input) for mailman id 1417571; Fri, 11 Sep 2026 16:40:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54J0-00027r-RL for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:40:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54J0-0090Wh-8D for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 18:40:50 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa42ecf-2eae-0a2a0a5409dd-0a2a4504cc8e-44 for ; Fri, 11 Sep 2026 18:40:50 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa42f10-b57f-0a2a45040019-aa0a817c69f7-3 for ; Fri, 11 Sep 2026 18:40:49 +0200 Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-373-DbPVIgPSPbOP9ibl1dS4OQ-1; Fri, 11 Sep 2026 12:40:44 -0400 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 06CD218005A0; Fri, 11 Sep 2026 16:40:41 +0000 (UTC) Received: from localhost (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 2DECE195608F; Fri, 11 Sep 2026 16:40:38 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789144848; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uDadYbb+MvTukZ4DS18E0pLdpqsEG2v4jBcqkrYw0bM=; b=U8sgjLLgLHBPOvsOAyAozl7fe7ww2nxBlCfvGNwszauANppzG1vpDM9YepatedT8aoIIQL WVtIYLBRFkBZDvSSIkK0mQ66O4U1SnbsmpQGMBczCEXB4A5WktovSYFukVYsXlaoXqCEuo XIz71EwuF5rFhv2cgNp7eI8vfJjbQgM= X-MC-Unique: DbPVIgPSPbOP9ibl1dS4OQ-1 X-Mimecast-MFC-AGG-ID: DbPVIgPSPbOP9ibl1dS4OQ_1789144841 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Fri, 11 Sep 2026 20:35:26 +0400 Subject: [PATCH v5 52/62] hw: convert device-local PropertyInfo definitions to use qapi_type MIME-Version: 1.0 Message-Id: <20260911-qom-qapi-v5-52-7732a55b7760@redhat.com> References: <20260911-qom-qapi-v5-0-7732a55b7760@redhat.com> In-Reply-To: <20260911-qom-qapi-v5-0-7732a55b7760@redhat.com> To: qemu-devel@nongnu.org Cc: Markus Armbruster , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , Michael Roth , Pierrick Bouvier , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Kevin Wolf , Hanna Reitz , Phil Dennis-Jordan , Alistair Francis , Peter Maydell , Keith Busch , Klaus Jensen , Jesper Devantier , "Michael S. Tsirkin" , Halil Pasic , Christian Borntraeger , Eric Farman , Farhan Ali , Richard Henderson , Ilya Leoshkevich , David Hildenbrand , Matthew Rosato , Cornelia Huck , Alex Williamson , =?utf-8?q?C=C3=A9dric_Le_Goater?= , xen-devel@lists.xenproject.org, qemu-block@nongnu.org, qemu-arm@nongnu.org, qemu-s390x@nongnu.org X-Developer-Signature: v=1; a=openpgp-sha256; l=8761; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=JMD8CHS/Ms/ZN3B00kadMDC30ZNsy393OriqSCvH/Y0=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqpC27/FrwpaBUFhbPDQM/o0pmo0Fc272pN3kVq if9mhmJslKJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCaqQtuwAKCRDa6OEJdZac 5RQQD/0VJ4R8+y480kJaLTZ3cqEvpfw1lNnm/uI8n1uA2ZLFzVvlOsEpqHPLE2mR/9Oo/sJhKUg s8P4TDAafsiUyYQpMlrEdjoieMqshEAXlKQkq+RO3/373up8zM8+D39GLdnPqEDFPme25Gr5y2x 8c8PRoLO7vI+lrEiwpI2IyrHWT7Zb21mqnKpLQTBZrhY8Qmj+ZX/JtJpOAdDXxk1OugIQVSeBZq rWHF7eYcufQtH4rtS7mHG2RuJJDd0Kjl+B7E6WmhKeGtdcpHwNTZc+Wvh37MyvdAg2XfYFJLWPP B/N5ofB2dMndTh9s3f3FuHZtQ/i/8i523aDWkDPKsT910Xc5QThMses3GAalYPjif0xtlmfkmaI KUl3FdjHiMA0PchYgdr6e0rZLfZdWs2anxhut6VAH5MNruVPPxvDYTg/eqnB1G5pYbCQuYzvZS2 3dFLRN2YMBiz/hM17+P2uE6VCE+2U76ksfyOOTzxgxcK3xoTnTcCh831KYU2qNptNG7goifUmzX wbKc3GDwzszxYqtef4uRogD37D6cxnipthwixlylbyB+Co8qw8663WPDj1r0bozbQoqxotruS1I yN2/5u/1jktef5brLkbmqVqfE2cxAmrGNOYZ6R32U3ZRIusQ/YOO1qNV9iu8FQ6kfXEIOOlV3kS fX2ixHNs8L+WsjA== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: iMQhqS9DT0ngcna3A8TO0tqWJjbsw872gXnGlxC4TXo_1789144841 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1789144850-C08D9B50-3D2EFCA6/0/0 X-purgate-type: clean X-purgate-size: 8763 Mechanical conversion of PropertyInfo definitions in device-specific files, replacing .type string with .qapi_type pointer to the corresponding QAPITypeInfo. Except "display_mode" for apple-gfx, which is a string of a specific format. Signed-off-by: Marc-André Lureau --- hw/block/xen-block.c | 3 ++- hw/display/apple-gfx.m | 3 ++- hw/misc/xlnx-versal-trng.c | 3 ++- hw/nvme/nguid.c | 3 ++- hw/nvram/xlnx-bbram.c | 3 ++- hw/nvram/xlnx-efuse.c | 3 ++- hw/pci/pci.c | 3 ++- hw/s390x/ccw-device.c | 3 ++- hw/s390x/css.c | 5 +++-- hw/s390x/s390-pci-bus.c | 3 ++- hw/vfio/pci-quirks.c | 3 ++- 11 files changed, 23 insertions(+), 12 deletions(-) diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c index 474c12fe4ac8..d9721c565c5f 100644 --- a/hw/block/xen-block.c +++ b/hw/block/xen-block.c @@ -29,6 +29,7 @@ #include "dataplane/xen-block.h" #include "hw/xen/interface/io/xs_wire.h" #include "trace.h" +#include "qapi/qapi-builtin-type-infos.h" #define XVDA_MAJOR 202 #define XVDQ_MAJOR (1 << 20) @@ -663,7 +664,7 @@ invalid: * https://xenbits.xen.org/docs/unstable/man/xen-vbd-interface.7.html */ static const PropertyInfo xen_block_prop_vdev = { - .type = "str", + .qapi_type = &str_type_info, .description = "Virtual Disk specifier (d*p*/xvd*/hd*/sd*)", .get = xen_block_get_vdev, .set = xen_block_set_vdev, diff --git a/hw/display/apple-gfx.m b/hw/display/apple-gfx.m index be0061b9db25..77c420b30006 100644 --- a/hw/display/apple-gfx.m +++ b/hw/display/apple-gfx.m @@ -15,6 +15,7 @@ #include "qemu/lockable.h" #include "qemu/cutils.h" #include "qemu/log.h" +#include "qapi/qapi-builtin-type-infos.h" #include "qapi/visitor.h" #include "qapi/error.h" #include "qemu/aio-wait.h" @@ -871,7 +872,7 @@ static void apple_gfx_set_display_mode(Object *obj, Visitor *v, } const PropertyInfo qdev_prop_apple_gfx_display_mode = { - .type = "display_mode", + .qapi_type = &str_type_info, .description = "Display mode in pixels and Hertz, as x@ " "Example: 3840x2160@60", diff --git a/hw/misc/xlnx-versal-trng.c b/hw/misc/xlnx-versal-trng.c index 0584ee089e3c..97bd3c3f8475 100644 --- a/hw/misc/xlnx-versal-trng.c +++ b/hw/misc/xlnx-versal-trng.c @@ -36,6 +36,7 @@ #include "qapi/visitor.h" #include "migration/vmstate.h" #include "hw/core/qdev-properties.h" +#include "qapi/qapi-builtin-type-infos.h" #ifndef XLNX_VERSAL_TRNG_ERR_DEBUG #define XLNX_VERSAL_TRNG_ERR_DEBUG 0 @@ -662,7 +663,7 @@ static void trng_prop_fault_event_get(Object *obj, Visitor *v, } static const PropertyInfo trng_prop_fault_events = { - .type = "uint32", + .qapi_type = &uint32_type_info, .description = "Set to trigger TRNG fault events", .set = trng_prop_fault_event_set, .get = trng_prop_fault_event_get, diff --git a/hw/nvme/nguid.c b/hw/nvme/nguid.c index 4cd6fad6ac9b..6eaf90fca88e 100644 --- a/hw/nvme/nguid.c +++ b/hw/nvme/nguid.c @@ -18,6 +18,7 @@ #include "qapi/visitor.h" #include "qemu/ctype.h" #include "nvme.h" +#include "qapi/qapi-builtin-type-infos.h" #define NGUID_SEPARATOR '-' @@ -179,7 +180,7 @@ static void set_nguid(Object *obj, Visitor *v, const char *name, void *opaque, } const PropertyInfo qdev_prop_nguid = { - .type = "str", + .qapi_type = &str_type_info, .description = "NGUID or \"" NGUID_VALUE_AUTO "\" for random value", .get = get_nguid, diff --git a/hw/nvram/xlnx-bbram.c b/hw/nvram/xlnx-bbram.c index e336874bdef4..eb032ab8b9c8 100644 --- a/hw/nvram/xlnx-bbram.c +++ b/hw/nvram/xlnx-bbram.c @@ -34,6 +34,7 @@ #include "hw/core/qdev-properties.h" #include "hw/core/qdev-properties-system.h" #include "hw/nvram/xlnx-efuse.h" +#include "qapi/qapi-builtin-type-infos.h" #ifndef XLNX_BBRAM_ERR_DEBUG #define XLNX_BBRAM_ERR_DEBUG 0 @@ -486,7 +487,7 @@ static void bbram_prop_release_drive(Object *obj, const char *name, } static const PropertyInfo bbram_prop_drive = { - .type = "str", + .qapi_type = &str_type_info, .description = "Node name or ID of a block device to use as BBRAM backend", .realized_set_allowed = true, .get = bbram_prop_get_drive, diff --git a/hw/nvram/xlnx-efuse.c b/hw/nvram/xlnx-efuse.c index 03c9fbc0d076..b1c9ee4980a0 100644 --- a/hw/nvram/xlnx-efuse.c +++ b/hw/nvram/xlnx-efuse.c @@ -34,6 +34,7 @@ #include "system/blockdev.h" #include "hw/core/qdev-properties.h" #include "hw/core/qdev-properties-system.h" +#include "qapi/qapi-builtin-type-infos.h" #define TBIT0_OFFSET 28 #define TBIT1_OFFSET 29 @@ -251,7 +252,7 @@ static void efuse_prop_release_drive(Object *obj, const char *name, } static const PropertyInfo efuse_prop_drive = { - .type = "str", + .qapi_type = &str_type_info, .description = "Node name or ID of a block device to use as eFUSE backend", .realized_set_allowed = true, .get = efuse_prop_get_drive, diff --git a/hw/pci/pci.c b/hw/pci/pci.c index af6e1d440c37..89a36221bc43 100644 --- a/hw/pci/pci.c +++ b/hw/pci/pci.c @@ -53,6 +53,7 @@ #include "qapi/error.h" #include "qemu/cutils.h" #include "pci-internal.h" +#include "qapi/qapi-builtin-type-infos.h" #include "hw/xen/xen.h" #include "hw/i386/kvm/xen_evtchn.h" @@ -80,7 +81,7 @@ static void prop_pci_busnr_get(Object *obj, Visitor *v, const char *name, } static const PropertyInfo prop_pci_busnr = { - .type = "uint8", + .qapi_type = &uint8_type_info, .get = prop_pci_busnr_get, }; diff --git a/hw/s390x/ccw-device.c b/hw/s390x/ccw-device.c index 25c427327957..fd21a4346522 100644 --- a/hw/s390x/ccw-device.c +++ b/hw/s390x/ccw-device.c @@ -17,6 +17,7 @@ #include "qapi/visitor.h" #include "qemu/ctype.h" #include "qapi/error.h" +#include "qapi/qapi-builtin-type-infos.h" static void ccw_device_refill_ids(CcwDevice *dev) { @@ -74,7 +75,7 @@ static void ccw_device_set_loadparm(Object *obj, Visitor *v, } const PropertyInfo ccw_loadparm = { - .type = "str", + .qapi_type = &str_type_info, .description = "Up to 8 chars in set of [A-Za-z0-9. ] to select" " a guest kernel", .get = ccw_device_get_loadparm, diff --git a/hw/s390x/css.c b/hw/s390x/css.c index 76dbca3bb961..60cba93e7eec 100644 --- a/hw/s390x/css.c +++ b/hw/s390x/css.c @@ -24,6 +24,7 @@ #include "hw/s390x/s390-virtio-ccw.h" #include "hw/s390x/s390-ccw.h" #include "exec/cpu-common.h" +#include "qapi/qapi-builtin-type-infos.h" typedef struct CrwContainer { CRW crw; @@ -2518,7 +2519,7 @@ out: } const PropertyInfo css_devid_propinfo = { - .type = "str", + .qapi_type = &str_type_info, .description = "Identifier of an I/O device in the channel " "subsystem, example: fe.1.23ab", .get = get_css_devid, @@ -2526,7 +2527,7 @@ const PropertyInfo css_devid_propinfo = { }; const PropertyInfo css_devid_ro_propinfo = { - .type = "str", + .qapi_type = &str_type_info, .description = "Read-only identifier of an I/O device in the channel " "subsystem, example: fe.1.23ab", .get = get_css_devid, diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c index eff980fdfe92..f77632810b76 100644 --- a/hw/s390x/s390-pci-bus.c +++ b/hw/s390x/s390-pci-bus.c @@ -33,6 +33,7 @@ #include "system/runstate.h" #include "trace.h" +#include "qapi/qapi-builtin-type-infos.h" S390pciState *s390_get_phb(void) { @@ -1541,7 +1542,7 @@ static void s390_pci_set_fid(Object *obj, Visitor *v, const char *name, } static const PropertyInfo s390_pci_fid_propinfo = { - .type = "uint32", + .qapi_type = &uint32_type_info, .description = "zpci_fid", .get = s390_pci_get_fid, .set = s390_pci_set_fid, diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c index c5b4f9091d49..4a3fd374a211 100644 --- a/hw/vfio/pci-quirks.c +++ b/hw/vfio/pci-quirks.c @@ -26,6 +26,7 @@ #include "pci.h" #include "pci-quirks.h" #include "trace.h" +#include "qapi/qapi-builtin-type-infos.h" /* * List of device ids/vendor ids for which to disable @@ -1436,7 +1437,7 @@ static void set_nv_gpudirect_clique_id(Object *obj, Visitor *v, } const PropertyInfo qdev_prop_nv_gpudirect_clique = { - .type = "uint8", + .qapi_type = &uint8_type_info, .description = "NVIDIA GPUDirect Clique ID (0 - 15)", .get = get_nv_gpudirect_clique_id, .set = set_nv_gpudirect_clique_id, -- 2.55.0.543.g5ebe2ebe4ea8 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 16:45:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 16:45:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417589.1646296 (Exim 4.92) (envelope-from ) id 1x54Nq-00033y-8n; Fri, 11 Sep 2026 16:45:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417589.1646296; Fri, 11 Sep 2026 16:45:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54Nq-00033r-5s; Fri, 11 Sep 2026 16:45:50 +0000 Received: by outflank-mailman (input) for mailman id 1417589; Fri, 11 Sep 2026 16:45:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54No-00033l-Ih for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:45:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54Nn-00Ef55-SB for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 18:45:47 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa43033-2eae-0a2a0a5409dd-0a2a4506ec8c-6 for ; Fri, 11 Sep 2026 18:45:47 +0200 Received: from [52.101.85.10] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa43039-195a-0a2a45060019-3465550ab361-3 for ; Fri, 11 Sep 2026 18:45:46 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by EA8PPF99A30FA19.namprd03.prod.outlook.com (2603:10b6:30f:fff5::854) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.10; Fri, 11 Sep 2026 16:45:41 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 16:45:41 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CbHhfhiOnodAAKDLa0Qxr4+TrC5ItPi4p05vk0ffLVVAls4mopNAMA13+BpO93qwbk2EWwr00hVIekWl/4OqkhvUVGutBrIDhfeK1qiuOMEkRFsJEzrTP8vQnVc1aYGXZWE2jjJ0LCFymh4Tf2P+xJnhPt1a1/Gp9mpCLCLkfm2QObV0dQ1XLhAZACwA1grYzxjejGwMYFe6xr30Q6JzM6RqPph0avy7ouiJ4DJXDbzoBYlPLqtFIzxJmL68ch2ZX+spAEKSBGChYPV96twN3gFmCQbwt1Bt/KBFmYN5OaK5PmDfX/VYUjzraCUN2y7/MKy5etEzmWEzGfuGCkyWfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=d+E4okuUBv3tEFdQWmguo7Gu0MYYpNSDHjd8RG+WzuY=; b=LNyO5YN02EB8Ya0vKA50Weqff2qFdJ2xTip+KASS+0kuZxteSX27sbdbmXii57Ehj6F368sTGYTQqEuMMcFvZ2uHuSVcLVguMT9twoFa2nusAL8Wa6rsHkFWNnGXvLzB8SDjfLfB4st6x5hOLnLfH26HngZZsUKzGcxBYuNM2fAgTGKY2KqcmpkJlwkmLMrG8/KIsAoDNAr8TqDckbUH/k3Z4y2oBGJ3zBMqjaMfMQGoaeJU4VCy3wQRDLjLe9A3VCiGoILqcCBuVvGrXAGAZlafK1OgOcEBc7lyGxXAz/TlVn+DPs79D3E4odp5AEO2LP8a0X1jTDigeN0GvvytBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d+E4okuUBv3tEFdQWmguo7Gu0MYYpNSDHjd8RG+WzuY=; b=WQK3Nkat9Jn+B0e/NTHY80vbVWwDA9dqK9lCHPNVyzuVSd0QDC3nVyv4ZZM/EwzjPzdO8WehoDgZ3vPVBjZzf89Sv1MTNvFGYj7jest8Neo3i3Np+lDuDvP1CkFMs+K+/A9yMo0n3nilvr5ZLC009WSbG2bufQar+hMWakw9rMo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <89c7c026-3986-440a-b2d1-158eb5f0fbbe@citrix.com> Date: Fri, 11 Sep 2026 17:45:37 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH] Add basic b4 config file To: Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1789133309.8631fc262581453bbf619ec5b2062170.1a090a7c48d000c4f3@vates.tech> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <1789133309.8631fc262581453bbf619ec5b2062170.1a090a7c48d000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0391.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18f::18) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|EA8PPF99A30FA19:EE_ X-MS-Office365-Filtering-Correlation-Id: c1da27eb-c50d-474c-530f-08df10241dbb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|10067099003|5023799004|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: NBlRRGVnZz+GawAYV8QrVC9JC9ZEbBQPz7F9aCeneNjeUikSCrgtH2yABUtjajEgkdhilb5bk7UXfubieyyinLsRWYDF9gPP0VYAskhcYaSHksrXeO9sfvv/QFCcuLTFcBdlpIifF7PQVnK4GtiMtfMTas/71d/LFhRrpJcFZDDGwQYnHa0GNzN9wwliB4Coql+2FDTP41k8nWE2STwvYVsy7dTMwdvmgcD3zfHczMLtyZ+p0GwUtJnooIIPwRdBfW6V1k/hd19W01TnO4P3eM8+vD535lFlozWQL7IZySIbOqtzjpIyLVBKpbsD/bn05qfntnwPyvXJDRMkVp969css/9w48fkMcgmD4xDIOwtfTUPOO/EnHiMct2niqIG1tkYm96PT9UEXeI0ba7KL/N1pNtQ76l5eZL+SufzaE5dCqo5vGxw+fNHZyk+scM6I+/CJUeULiNmVbgh7jkjWjklW7b6Z0//mMqXYR8uXhHFSHbVEgGZRgRQfiZX9/kRBCRXD1H9oVBqIc0uTNKUXiXFyXeE4A6Tsju5wvD0AQ3PIx6lYlTfzK0CH8ftWnnMZNNJepNEaDwierxQayRzmOQRIFzEEn/7EJ95CVsolKHE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(10067099003)(5023799004)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M2ZSOHlET3NrTTlJNG5ES1NhSm51eitPOHFjaGhBcDMyYndiRTcyNDVwL0Zv?= =?utf-8?B?OFpNaGk2cmVyb09BcE1JMUp4eTRqeGpxOWt4aHdBZVk5SnQ3SVkrSk45eS8y?= =?utf-8?B?WUNOWlo4UnBSbXo3cFhMb1BUNEhObFRpeWppU0VEVG5iMDcwdEVLZXR6bGpq?= =?utf-8?B?UGJVbEQ4YlJ3WU5nQ2F0aHppOEp2ZkprSE9pT1FNdkZ5NmpRSDRpTTNaUVZS?= =?utf-8?B?Vi9TdE1wSVBNU1J4dkFCSG1NNmt5azFLSERuazM2V1dhTmVHb2lSNEZPUnRY?= =?utf-8?B?VGwzOFNTMHd5TDZwL0xURlFHdFRta1NCSU9NTTFWSkhnUmJUZStCTTBQS2FS?= =?utf-8?B?VlVLNEgvUGxOS3dJZzhvNmMvSjluUHQ2Y0gyRFpmRUdWQXpyTWhML0xsR0VF?= =?utf-8?B?TzBsaWswYllqdnZKVjkxVWxzMXlDenVHa3VQYWZLVXF4MlpEQnR1NitreDUw?= =?utf-8?B?M2lrZHdoQ25TOHIxbXpYWHVTa0prWkJDQ0dCWEVWR3FUOWNTOTBwa0thdHI5?= =?utf-8?B?VmIzL3dVL0RmNkVpeGEzOEM1MUwwMHpMT0JONVRzdWN6UHpDOXJaUmJvUjNL?= =?utf-8?B?V0RRUXNMMVJwZ2RNNnRLc0JZenZjVERRVHVjOUpBMThIY0ExYUdsaE9WbkRF?= =?utf-8?B?Q2ZTVTlHTzY3Y1RCYWt4Y3BPU0J5Nkh0S2lnaS9ERUxhbmE5NEpGS3JLNTdq?= =?utf-8?B?Qm91VzFKUStGa0Job3dhYVBielNaL1NDMHdEUEVNbmpaVXVKeHRVZ1NWR2Q1?= =?utf-8?B?TXBMckRPMDVlazdpSkhVL05qV1o2ek9MMUZic0hzOTcyVWhRUGliKzZpbVpD?= =?utf-8?B?NlhZNVc3TG9kbGNobHpSYzdFNlo5VkFodkl5R0VNWUJlVUtja2k1cFJuaHh4?= =?utf-8?B?MVdrdk9aT0N1R2RBQURGWi9tUTh2MXFwenFqdk5CaDBVQS9NaUVoNFR6Rldl?= =?utf-8?B?YVFURVAyOFd6RXpuRUNhZXErT21TWHFVckVyV1BoZTc0NWlFNmJwWXNpN3VD?= =?utf-8?B?R2EyQXZEWXFYQzVrUFVhRWFCckF2OFRBU3hVaVByQXFJQzN1b2J5R3lyeXI5?= =?utf-8?B?cUFWZHhKQTJoN2NXL2F5QlU4YWcvVmJyVlhBc0l2dEV1Y01CMTFmV3JwTDNJ?= =?utf-8?B?SGdaS0R1Umk2QlZVU3VIT3Y5YmpTeENoSkRBaVRLb0pnYzlQY3MxcFd0WW4z?= =?utf-8?B?Mm1CSWVtQWw5TG93WEZHa2M5TEZlb0hCVEZuUEpwN0FRR01ONzVrM0RqeHM2?= =?utf-8?B?TThsUCthOWY3U3RPVWpGblBIbzdYUFAvZFhwdEVYbG93N2RJVU9ZL2VRazNY?= =?utf-8?B?NEZaRjR3RkVxTnZLNGVKbUhENEF1dHFkNmVrV0U1TFp0cXhIMjdmVDNTNUlv?= =?utf-8?B?aUpBVVIrZnY5MUsyQXhpT3k3WGc2dVRkMEtaQlRBZTRncmNJU2I1cGxrbnUw?= =?utf-8?B?dk9rN09ma2JjbmREZ1I2eVVZenlVclRXYzhMNE9neGwva21UWExGcjhvZlA3?= =?utf-8?B?Q2NQc2xwTkltclJ1MkMxZHhiMGFoYkJrMTlGSkJhS3FkWWE3ZWJHZ01GUUxV?= =?utf-8?B?cHBEZ0lNTU1LZGdwNDZFZUFKU3NPWGF0TldlLzQ2eHJWZUhYd3VybStJdG50?= =?utf-8?B?VXBZU29YbmVKTnJGeUNTTFd6Y3A1WEp5eStGSzZJMmZPQmV0eGdzdnNidko1?= =?utf-8?B?WFFGVm12WDBpVHJSNTZYRUVjR1lqcjUwNG9YTmNqeEVCbUp0NThXakhwL21p?= =?utf-8?B?MWQxK2sxMno4YThyMFY1ZmtWUE5UQngvYlk5TGpueXZTSzZJRVVML0FLTnh3?= =?utf-8?B?MERkZ2hmdWNuYVNmOXZ3a21rUkVCa0I0VS9RNURIWFVyblhuaEl2RUt3TXRh?= =?utf-8?B?VkNvcFN5T0h6OXZqSjdDV01kVVcrWUZWc3YvMmJCVWRJU0xPUW9DdFRJR29I?= =?utf-8?B?dUhDMEZrWnJLaElveW5xeWtSTmtGSUViWVhsWjhXV0I1dzRkN3FqeElWcmZ4?= =?utf-8?B?LzFIZjBVaElKRjQyT0VWbklUT3c3cGVOeUdhZUNmWUg4ODJjd3k2YnFUMFJY?= =?utf-8?B?QWg0L09zRDR3Z1RSTjM3ZFBaV2lnRk5vZXpQZmllQTRDZlAzLytaL2lwVTVL?= =?utf-8?B?MlI2LzNOWGdmRnFXM2JFSHkxVGl2dXE1a2dINFlRbCtzNHpod2czK2pJelBG?= =?utf-8?B?cHpJRldtTXdsWUhHVkt2eGFmdEhsUEtkOGs4QkNsREgwS1dlSWFVdmxIeEVs?= =?utf-8?B?TmlYV1FhTlZTV0hMOEc3YUVDNlg3WlhjYmllSmUvUFUyaG5XSkllWVhxWitW?= =?utf-8?B?cklFS3Q0SXA1cjI4NW80QTZiNkRDN29ZV2lJakJwd3AzWGdaWmI2cFhnc09O?= =?utf-8?Q?/khZ0ywAB5Ml411o=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c1da27eb-c50d-474c-530f-08df10241dbb X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 16:45:41.4285 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BVOXaUattfE2a1vwH8q7WbbeA5CbvAiLvZaxbyP2qqzLlMkOqc7iFessCdpI554AR5Yt1TcN+sr8PNFt/BL63zP79e6IO92LzUNFj8zAWlY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: EA8PPF99A30FA19 X-purgate-ID: tlsNG-16d1c6/1789145147-FDC0F77B-5E99F403/0/0 X-purgate-type: clean X-purgate-size: 1912 On 11/09/2026 2:28 pm, Baptiste Le Duc wrote: > b4[1] is a convenient tool for mail-based contribution. A config file[2] > tracked in the tree lets the project ship a few defaults that match the Xen > patch submission rules. > > This aims to help new contributors who have never used a mailing list avoid > mistakes when sending their patch series. > > The tree has no scripts/checkpatch.pl or equivalent, so there is nothing > for b4 to run per patch. Disable the needs-checking pre-flight check so a > series can be sent without first running b4 prep --check. > > [1] https://pypi.org/project/b4/ > [2] https://b4.docs.kernel.org/en/latest/config.html > > Signed-off-by: Baptiste Le Duc I don't use b4 for preparing series myself, but I can see how this would be useful for newcomers. > --- > .b4-config | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/.b4-config b/.b4-config > new file mode 100644 > index 0000000000..1ca1f0625e > --- /dev/null > +++ b/.b4-config > @@ -0,0 +1,13 @@ > +# > +# Common b4 settings for sending patches to the Xen Project upstream. > +# https://b4.docs.kernel.org/ > +# > +# See docs/process/sending-patches.pandoc for the patch submission rules > +# these settings implement. I doubt people will be reading this file to discover how to send patches, and that piece of documentation is in the process of moving into the handbook. I suggest dropping this sentence.  All that's going to happen to it is becoming stale shortly. > +# > + > +[b4] > + send-series-to = xen-devel@lists.xenproject.org > + send-auto-to-cmd = echo > + send-auto-cc-cmd = ./scripts/get_maintainer.pl --noroles --norolestats --nogit --nogit-fallback Where did this come from?   Because it didn't come from Xen's version of get_maintainers, which is a long way removed from Linux's ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 11 16:50:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 16:50:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417602.1646305 (Exim 4.92) (envelope-from ) id 1x54Sh-0005Cw-VG; Fri, 11 Sep 2026 16:50:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417602.1646305; Fri, 11 Sep 2026 16:50:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54Sh-0005Cp-S3; Fri, 11 Sep 2026 16:50:51 +0000 Received: by outflank-mailman (input) for mailman id 1417602; Fri, 11 Sep 2026 16:50:50 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54Sg-0005Cj-0l for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:50:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54Sf-006Ma9-6o for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 18:50:49 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4315b-e002-0a2a0a5209dd-0a2a45038840-8 for ; Fri, 11 Sep 2026 18:50:49 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa43167-fae8-0a2a45030019-aa0a857c6157-3 for ; Fri, 11 Sep 2026 18:50:48 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-294-uChttM2tMFKEHHKjELXc6g-1; Fri, 11 Sep 2026 12:50:43 -0400 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D860919560BC; Fri, 11 Sep 2026 16:50:41 +0000 (UTC) Received: from redhat.com (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E3B96180034C; Fri, 11 Sep 2026 16:50:39 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789145447; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mNCCwd+rbPqirfm0wkJvjXVhjTPI0RhTanYIYxdf+Sc=; b=dyTb5RIXj6qSDD92B+97mEGjfUaOXS+hdK5xDPdPEkAZ21B73SXDBWiYnLv9ZlUcw9cmv6 cKk7U2rZNIuZSXuISELFfD/iMVZpj3GzRUTo1aNXh+5Zx8YVtIXDZgVC6+3Ak4a1MflGIv wBnWCkHKNaxh4X5Do//8fxnQEk3k8QA= X-MC-Unique: uChttM2tMFKEHHKjELXc6g-1 X-Mimecast-MFC-AGG-ID: uChttM2tMFKEHHKjELXc6g_1789145442 Date: Fri, 11 Sep 2026 17:50:37 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: qemu-devel@nongnu.org Cc: xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, qemu-ppc@nongnu.org, qemu-block@nongnu.org, qemu-s390x@nongnu.org, qemu-arm@nongnu.org Subject: Re: [PATCH 15/28] hw: define most common PCI types as secure Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20260911143627.2743803-1-berrange@redhat.com> <20260911143627.2743803-16-berrange@redhat.com> MIME-Version: 1.0 In-Reply-To: <20260911143627.2743803-16-berrange@redhat.com> User-Agent: Mutt/2.4.0 (2026-06-19) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: 00KBXM8MZ-mTLYm3esJMocm6rDivbMrd7fVa8zd7AQ8_1789145442 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1789145449-758824E9-CFC4269C/0/0 X-purgate-type: clean X-purgate-size: 2465 On Fri, Sep 11, 2026 at 03:36:14PM +0100, Daniel P. Berrangé wrote: > Essentially all PCI infrastructure is in scope for the virtualization > use case, aside from the niche simba bridge. > > Signed-off-by: Daniel P. Berrangé > --- > hw/pci-bridge/gen_pcie_root_port.c | 1 + > hw/pci-bridge/i82801b11.c | 1 + > hw/pci-bridge/ioh3420.c | 1 + > hw/pci-bridge/pci_bridge_dev.c | 2 ++ > hw/pci-bridge/pci_expander_bridge.c | 8 ++++++++ > hw/pci-bridge/pcie_pci_bridge.c | 1 + > hw/pci-bridge/pcie_root_port.c | 1 + > hw/pci-bridge/xio3130_downstream.c | 1 + > hw/pci-bridge/xio3130_upstream.c | 1 + > hw/pci/pci.c | 7 +++++++ > hw/pci/pci_bridge.c | 1 + > hw/pci/pci_host.c | 1 + > hw/pci/pcie_host.c | 1 + > hw/pci/pcie_port.c | 1 + > 14 files changed, 28 insertions(+) > > diff --git a/hw/pci-bridge/pci_expander_bridge.c b/hw/pci-bridge/pci_expander_bridge.c > index 40ffbc4e08..bd5598b639 100644 > --- a/hw/pci-bridge/pci_expander_bridge.c > +++ b/hw/pci-bridge/pci_expander_bridge.c snip > @@ -128,6 +130,7 @@ static const TypeInfo pxb_cxl_bus_info = { > .parent = TYPE_CXL_BUS, > .instance_size = sizeof(PXBBus), > .class_init = pxb_bus_class_init, > + .secure = true, > }; > snip > static void pxb_cxl_realize(DeviceState *dev, Error **errp) > @@ -249,6 +253,7 @@ static const TypeInfo cxl_host_info = { > .parent = TYPE_PCI_HOST_BRIDGE, > .instance_size = sizeof(CXLHost), > .class_init = pxb_cxl_host_class_init, > + .secure = true, > }; > > /* snip > @@ -540,6 +547,7 @@ static const TypeInfo pxb_cxl_dev_info = { > .parent = TYPE_PXB_PCIE_DEV, > .instance_size = sizeof(PXBCXLDev), > .class_init = pxb_cxl_dev_class_init, > + .secure = true, > .interfaces = > (const InterfaceInfo[]){ > { INTERFACE_CONVENTIONAL_PCI_DEVICE }, These three were a mistake. No CXL code is intended to be classed as secure at this time. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| From xen-devel-bounces@lists.xenproject.org Fri Sep 11 16:55:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 16:55:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417614.1646313 (Exim 4.92) (envelope-from ) id 1x54XP-00065T-FX; Fri, 11 Sep 2026 16:55:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417614.1646313; Fri, 11 Sep 2026 16:55:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54XP-00065M-Cl; Fri, 11 Sep 2026 16:55:43 +0000 Received: by outflank-mailman (input) for mailman id 1417614; Fri, 11 Sep 2026 16:55:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54XN-00065E-Ry for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:55:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54XN-00EURr-7w for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 18:55:41 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4326e-8faa-0a2a0a5109dd-0a2a4508e826-18 for ; Fri, 11 Sep 2026 18:55:41 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4328b-f659-0a2a45080019-aceafc1fcf78-3 for ; Fri, 11 Sep 2026 18:55:40 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 7B0824005A; Fri, 11 Sep 2026 16:55:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7EEC91F00893; Fri, 11 Sep 2026 16:55:21 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789145738; bh=yE+7Pez0ot5mrGbBn0XwFu3bOI3y9SJeDDhq4Pq3Cgc=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=c0NoZhUuLC8eojSn10Dl+/6UkGx8wGOb/eBDtEA0CIyk1hQ6mP9dgGNHHGBX3N7yA X71r+aiXtzF4bhp3C1o/xG+WbKq9dsGWuGA3Hu4bxgxtDeR0HzLHnKDlSwnkTzN4I0 yNFvdrydYpmyeMrh9F90cWrJC226CBBW/A2ArZjcVPRInVrizb9o3/D2/gMDnyMPx1 YbCSjQU+p0HSOBH8E3Fyc1mpmYrLR8tCHSP8jSjf3gDgXExbXqvDifcxjWpIDa/PKf vZyITqtq+KtGCpN47eXarSnhSRPzuOIVrud/pd7SbcUw4idHZQTzpTNbHJv4fgl0sg qtZmvLKps6t8w== Message-ID: Date: Fri, 11 Sep 2026 18:55:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values To: Muhammad Usama Anjum , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev References: <20260903103002.1091859-1-usama.anjum@arm.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789145741-D634587B-F23CD767/0/0 X-purgate-type: clean X-purgate-size: 3414 On 9/3/26 12:29, Muhammad Usama Anjum wrote: > Hi, > > pte_t currently describes both a software PTE value and an element stored > in a PTE table. Consequently, pte_t * can point either to a software PTE > value, often a stack copy, or to a PTE-table slot. The compiler cannot > distinguish these cases. A value pointer can therefore be passed to an > interface that expects table storage, while table storage can be read by > direct dereference instead of the architecture accessor. > > This series begins a staged conversion at the PTE level. It introduces > hw_pte_t as the element type for PTE-table storage and converts generic > MM to use hw_pte_t *. Software PTE values remain pte_t. Interfaces that > intentionally return a value through pte_t *, such as install_pte, > remain value interfaces; the relevant parameters are named ptentp to > make that distinction explicit. > > The generic definition aliases hw_pte_t to pte_t unless an architecture > selects ARCH_HAS_HW_PTE_T, which enables a distinct generic wrapper named > __hw_pte_t. Some architectures define pgtable_t in headers parsed before > the generic hw_pte_t typedef is visible. The structure tag allows those > headers to define pgtable_t as struct __hw_pte_t * without creating an > include-order dependency. This is required when converting s390, m68k, > powerpc and sparc. > > No architecture selects ARCH_HAS_HW_PTE_T in this series, so the > representation and behavior of every architecture are preserved. ptep_get() > keeps its existing READ_ONCE() semantics and converts the stored element > through __pte_from_hw(). An architecture can later select the option and > convert its PTE interfaces to make the distinction compiler-enforced. > Architecture PTE implementations and most architecture code are > deliberately left for those later opt-in conversions. > > Here, hw_pte_t identifies PTE-table storage rather than table lifetime: > complete PTE tables use hw_pte_t whether or not they are currently > linked into a page-table hierarchy, while software PTE values use > pte_t. The distinction between complete but unlinked tables and > hardware-reachable tables was raised during discussion and remains an > important point for review. > > PMD, PUD, P4D and PGD storage are deliberately out of scope. They can be > converted in later series after the PTE boundary is agreed, avoiding the > PMD-specific cases that made an all-level conversion difficult to > review. > > Most mechanical pointer conversions were generated with the Coccinelle > script included below, then audited and fixed by hand. > > This series does not add a second ptep_get_once() accessor and does not > remove or replace STRICT_MM_TYPECHECKS. > > The design discussion is available at [1]; while the original idea came > from [2]. > > I've the patches here [3] for arm64 conversion which I used to find > usages in generic code which I missed during development. These would be > sent separately. Unless there is more feedback on the overall approach, the next step for this is to have at least one architecture support posted. We should only merge this if at least one architecture (better two? :) arm64 and s390x? ) would merge the architecture bits. That is, we should get an ACK from the arch maintainer son the common code bits and the arch bits. -- Cheers, David From xen-devel-bounces@lists.xenproject.org Fri Sep 11 16:59:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 16:59:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417622.1646322 (Exim 4.92) (envelope-from ) id 1x54b4-00077H-Tx; Fri, 11 Sep 2026 16:59:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417622.1646322; Fri, 11 Sep 2026 16:59:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54b4-00077A-Qv; Fri, 11 Sep 2026 16:59:30 +0000 Received: by outflank-mailman (input) for mailman id 1417622; Fri, 11 Sep 2026 16:59:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54b4-000770-3Y for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 16:59:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54b3-001wIo-GV for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 18:59:29 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa43365-2eae-0a2a0a5409dd-0a2a4501d9f8-20 for ; Fri, 11 Sep 2026 18:59:29 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4336f-5984-0a2a45010019-aceafc1fd7b4-3 for ; Fri, 11 Sep 2026 18:59:29 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 27F0C447B3; Fri, 11 Sep 2026 16:59:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 379961F00898; Fri, 11 Sep 2026 16:59:11 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789145967; bh=qM4x/VyJS4MpFkPRmtAp/dwZSEf7BNj/Y7zsnmyHsqg=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Ou4A8YC2F6O1EQtFW1YZOr6bVr2+s+ihTPkOTXSuzLWS+Cc6eD6PIOzLJeuiKIyvQ JwxsyI6YUXmX45BBAQxB8OYi/wyHeoP2FZWOx4kh82jj8klR9F/LQ8bOCWxW/Oo6Re Eo8mW9QEcAaGuTtykPlAmcPJuXu5gk0wxaGfd2AVAWl/D2lawDmMhQg3iDYUwUuHYw zuWtfU0zvPCWxENsoROZd8H/uu73aHGKmzvV36atSCabSMGxHjg64KkTpB12LVGbzh HWFSQPEDWDvZ5Hi73zQYh3QYUlItPYuBwtcY1gGae8CFr1qGgQfyIGrRgrWzKBkGHM 6ZbPiVuTm6ijA== Message-ID: Date: Fri, 11 Sep 2026 18:59:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values To: Muhammad Usama Anjum , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev References: <20260903103002.1091859-1-usama.anjum@arm.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1789145969-1DC79757-6ED03AA5/0/0 X-purgate-type: clean X-purgate-size: 224 On 9/3/26 12:29, Muhammad Usama Anjum wrote: > Hi, Btw, I was wonder whether the subject would be better as "mm: distinguish HW PTE pointers from SW PTE value pointers" or sth. like that. -- Cheers, David From xen-devel-bounces@lists.xenproject.org Fri Sep 11 17:00:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 17:00:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417633.1646331 (Exim 4.92) (envelope-from ) id 1x54cJ-0000SZ-5p; Fri, 11 Sep 2026 17:00:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417633.1646331; Fri, 11 Sep 2026 17:00:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54cJ-0000SS-3D; Fri, 11 Sep 2026 17:00:47 +0000 Received: by outflank-mailman (input) for mailman id 1417633; Fri, 11 Sep 2026 17:00:46 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54cI-0000SK-DG for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:00:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54cH-00EgWR-QD for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 19:00:45 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa433bb-e002-0a2a0a5209dd-0a2a4502c060-6 for ; Fri, 11 Sep 2026 19:00:45 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa433bc-6ca4-0a2a45020019-aceafc1fd3a2-3 for ; Fri, 11 Sep 2026 19:00:45 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 718C64376E; Fri, 11 Sep 2026 17:00:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 803B11F000FF; Fri, 11 Sep 2026 17:00:27 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789146043; bh=SDhdb+1yueFGYCfGv2/iY4/JhNsnY4MHmhr2o01xj7U=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=dqzLbr7PT9UPg2vyaVcVWkqDnTJLnNl/+9rbrIO5j+Xc/wJPxcpDAZtHGb0O5p3wx xxwXDj+5wfoXizGaX4IUDbtQjoGNGIBmbFh9r+Ih/Swh0lmJo1x2rXjXAotQlrIA5i 8CALl0IKEmojHmvftuOoofMkLRwZj2jPgwYN/P9EP0Ge2Yy2o0vx9O1Tc9LnRc7d8a ECioA+6R8JEa+dnDWQvYkyKqpHAO81tDbTlKvOLsbaMVoBHTGt5Y2bsOxTUhPmn5m/ bZSIlx+oLSNnrcP6gkKiSYENsTC+1lLLRiHh3dEhvB47zpFmLxPKtk1t4g8IwsgehU sPQt4Xy2dY91w== Message-ID: Date: Fri, 11 Sep 2026 19:00:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/8] mm: introduce hw_pte_t for PTE table storage To: Muhammad Usama Anjum , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev References: <20260903103002.1091859-1-usama.anjum@arm.com> <20260903103002.1091859-2-usama.anjum@arm.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <20260903103002.1091859-2-usama.anjum@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789146045-F34BE2AC-D33B003C/0/0 X-purgate-type: clean X-purgate-size: 1229 On 9/3/26 12:29, Muhammad Usama Anjum wrote: > pte_t is used both for software PTE values and for entries stored in a PTE > table, so pte_t * does not distinguish a pointer to a software PTE > value from a pointer to table storage. > > Introduce hw_pte_t as the generic name for a PTE table element. Define it > as a macro alias of pte_t by default. When an architecture selects > ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead. > This preserves the representation while allowing converted architectures > to enforce the distinction at compile time. > > Name the generic wrapper structure __hw_pte_t so architectures can > forward-declare it when pgtable_t must be defined before the generic > hw_pte_t typedef is visible. This avoids header-order dependencies. > > Keep the C type definitions behind an __ASSEMBLY__ check because > architecture assembly sources can include this header indirectly. Include > asm/page.h so consumers such as linux/vmalloc.h retain the page definitions > they previously obtained from that header. > > Signed-off-by: Muhammad Usama Anjum > --- Acked-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Fri Sep 11 17:10:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 17:10:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417645.1646341 (Exim 4.92) (envelope-from ) id 1x54lJ-0002n7-3w; Fri, 11 Sep 2026 17:10:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417645.1646341; Fri, 11 Sep 2026 17:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54lJ-0002mt-0i; Fri, 11 Sep 2026 17:10:05 +0000 Received: by outflank-mailman (input) for mailman id 1417645; Fri, 11 Sep 2026 17:10:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54lH-0002TA-RK for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:10:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54lH-00C6CV-0Z for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 19:10:03 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa435e6-bab6-0a2a0a5309dd-0a2a4508b882-10 for ; Fri, 11 Sep 2026 19:10:02 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa435e9-f659-0a2a45080019-ac6904feb662-3 for ; Fri, 11 Sep 2026 19:10:02 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 48B9160008; Fri, 11 Sep 2026 17:10:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22A101F000FF; Fri, 11 Sep 2026 17:09:43 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789146600; bh=wtZVEwngtJNDR7Dil3pjiAKeqFlagckAJ2vKOo34aps=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=o3L2NdFMRQT+LpNVPaEJvUSryJiMtoEVuBlhvOpTUX3u5oD1j+1IZzuRmDPssCOD4 3TfJgTwz9pU1ve9tosOWOXJWeO5W5V83R7OCQQ9yL2AVj6egbjS8vXSL82EbvGhM3T X1XDCLrsl04F+9gry2WDolIIzJu6dcCWuJB5K5pbIbQMAi2KKSjOs3tL2GGoqQq/Wi xq+SIi39yxW4XtIwV3PkGvVjCoZTgE4SSw6GvxZx1Nypqi8hRWSbbhUoNXXZ0lhxcQ kqmPeMm2P5VW+rdouLiwMZzBs9F3xluAom1Yg/u88m56rjWUU4zcY2OLNDN0AVIlpJ G63yfKeDG5URw== Message-ID: <85ea78b6-f3c7-4a9b-b25d-1fe2ecbf3b40@kernel.org> Date: Fri, 11 Sep 2026 19:01:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/8] mm: rename pointers to software PTE values as ptentp To: Muhammad Usama Anjum , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev References: <20260903103002.1091859-1-usama.anjum@arm.com> <20260903103002.1091859-3-usama.anjum@arm.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <20260903103002.1091859-3-usama.anjum@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789146602-D4F4F87B-3C4F540C/0/0 X-purgate-type: clean X-purgate-size: 922 On 9/3/26 12:29, Muhammad Usama Anjum wrote: > Some interfaces use pte_t * for a software PTE value rather than for an > entry stored in a PTE table. These pointers must remain pte_t * when > pointers to PTE table storage are converted to hw_pte_t *. > > Rename these parameters in the install_pte callback, > write_protect_page(), and guard_install_set_pte() to ptentp. The later > Coccinelle conversion skips pointers named ptentp, allowing it to convert > the remaining PTE table pointers without changing these interfaces. > > Some functions already use ptentp for such pointers, including: > - madvise_folio_pte_batch() > - folio_pte_batch_flags() > No need to rename them. > > This patch only renames parameters and makes no functional change. > > Signed-off-by: Muhammad Usama Anjum > --- Acked-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Fri Sep 11 17:10:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 17:10:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417646.1646351 (Exim 4.92) (envelope-from ) id 1x54lZ-0003T0-Cj; Fri, 11 Sep 2026 17:10:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417646.1646351; Fri, 11 Sep 2026 17:10:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54lZ-0003SK-7g; Fri, 11 Sep 2026 17:10:21 +0000 Received: by outflank-mailman (input) for mailman id 1417646; Fri, 11 Sep 2026 17:10:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54lY-0003Rj-A3 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:10:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54lX-009r2Z-N7 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 19:10:19 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa435f8-8faa-0a2a0a5109dd-0a2a450b9d8c-4 for ; Fri, 11 Sep 2026 19:10:19 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa435f9-b7e8-0a2a450b0019-aceafc1fd9b2-3 for ; Fri, 11 Sep 2026 19:10:19 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id D8DCD4067A; Fri, 11 Sep 2026 17:10:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF04C1F00893; Fri, 11 Sep 2026 17:10:00 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789146616; bh=s9/6KbXsN5PKvzZs2esn/AhPtSfdFVVRLNXzVuGAieA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=ijM28yeSeyX61csI7of/aYV6Iu23+fQwE2+XMHuORDOd9Q58+YKhljzXl+IBz4Fum GTMuOS39dD0b/3zG27EdOqjAkusXj6vqwIKDQom13aNYWLtWjARY8yD4Fc6x0WSfAd 5HAYNkwusAIKERa3WHgLnp9dbK4wyC6PAL6LjnODK0XIQGto7t/yd8GJT72smbQhyu OzZ3q1/AtOHdfG+oKc4RjaNN9Ctxu4fwIB3/CiLYKdFCtFfw3NRb+woAMvc191s+Fq 6WOJgh4F2SXLfO/k1FpUXsN9xExTqEQkHaoouynhFq/HctD3ifs1J/7Tb6gKYO0V6p uNN1MzB53btqw== Message-ID: <0a4fd9e1-3e7d-4910-99ee-6f6f89b5ca93@kernel.org> Date: Fri, 11 Sep 2026 19:09:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/8] mm: use hw_pte_t for generic PTE table storage To: Muhammad Usama Anjum , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev References: <20260903103002.1091859-1-usama.anjum@arm.com> <20260903103002.1091859-4-usama.anjum@arm.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <20260903103002.1091859-4-usama.anjum@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789146619-AB0DD9EA-3C6DF253/0/0 X-purgate-type: clean X-purgate-size: 5601 On 9/3/26 12:29, Muhammad Usama Anjum wrote: > Generic page-table interfaces use pte_t * for both pointers to PTE table > storage and pointers to software PTE values. Convert the generic > declarations and their MM, fs, and kernel users together so parameters, > return types, callbacks, and local pointers that designate table storage > use hw_pte_t *. > > Include linux/pgtable_types.h from headers that expose the converted > interfaces. It continues to provide pgprot_t to vmalloc.h through > asm/page.h. > > Keep software PTE values as pte_t and retain pte_t * for value interfaces. > > No architecture selects ARCH_HAS_HW_PTE_T at this point, so hw_pte_t > remains an alias of pte_t and this changes the interface vocabulary without > changing representation or behavior. > > Most of this mechanical conversion was generated with the Coccinelle script > included in the cover letter. The script deliberately ignores pte_t * > pointers named ptentp because they designate software PTE values. The > result was then audited, and sites the script could not convert were > updated by hand. > > Signed-off-by: Muhammad Usama Anjum > --- > Changes since v1: > - Fold the header includes into their first user instead of keeping a > stand-alone preparation patch. > - Rebase onto mm-new and rerun the Coccinelle script. > - Use software PTE value terminology. > > Changes since RFC v1: > - Clarify that linux/pgtable_types.h provides both generic hw_pte_t > definitions. > - Clarify that the distinct generic definition is activated by an > architecture opt-in. > --- > fs/hugetlbfs/inode.c | 3 +- > fs/proc/task_mmu.c | 33 ++++++------- > include/asm-generic/hugetlb.h | 15 +++--- > include/asm-generic/pgalloc.h | 6 +-- > include/asm-generic/tlb.h | 5 +- > include/linux/hugetlb.h | 50 +++++++++++--------- > include/linux/mm.h | 26 +++++------ > include/linux/page_table_check.h | 10 ++-- > include/linux/pagewalk.h | 8 ++-- > include/linux/pgtable.h | 79 +++++++++++++++++--------------- > include/linux/rmap.h | 2 +- > include/linux/swapops.h | 6 ++- > include/linux/vmalloc.h | 4 +- > include/trace/events/xen.h | 10 ++-- > kernel/bpf/arena.c | 9 ++-- > kernel/events/core.c | 3 +- > mm/damon/ops-common.c | 2 +- > mm/damon/ops-common.h | 2 +- > mm/damon/vaddr.c | 20 ++++---- > mm/debug_vm_pgtable.c | 2 +- > mm/filemap.c | 4 +- > mm/gup.c | 9 ++-- > mm/highmem.c | 15 +++--- > mm/hmm.c | 6 +-- > mm/huge_memory.c | 4 +- > mm/hugetlb.c | 60 ++++++++++++------------ > mm/hugetlb_vmemmap.c | 13 +++--- > mm/internal.h | 16 +++---- > mm/kasan/init.c | 12 ++--- > mm/kasan/shadow.c | 6 +-- > mm/khugepaged.c | 50 ++++++++++++-------- > mm/ksm.c | 7 +-- > mm/madvise.c | 14 +++--- > mm/mapping_dirty_helpers.c | 4 +- > mm/memory-failure.c | 6 +-- > mm/memory.c | 78 ++++++++++++++++--------------- > mm/mempolicy.c | 4 +- > mm/migrate.c | 4 +- > mm/migrate_device.c | 4 +- > mm/mincore.c | 4 +- > mm/mlock.c | 4 +- > mm/mprotect.c | 19 ++++---- > mm/mremap.c | 4 +- > mm/page_table_check.c | 4 +- > mm/pagewalk.c | 9 ++-- > mm/percpu.c | 2 +- > mm/pgtable-generic.c | 20 ++++---- > mm/ptdump.c | 2 +- > mm/rmap.c | 6 +-- > mm/sparse-vmemmap.c | 22 ++++----- > mm/swap_state.c | 3 +- > mm/swapfile.c | 5 +- > mm/userfaultfd.c | 32 +++++++------ > mm/util.c | 2 +- > mm/vmalloc.c | 11 +++-- > mm/vmscan.c | 6 +-- > 56 files changed, 410 insertions(+), 356 deletions(-) > > diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c > index 7611a8470ea26..ddaab714c3e02 100644 > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -328,7 +328,8 @@ static void hugetlb_delete_from_page_cache(struct folio *folio) > static bool hugetlb_vma_maps_pfn(struct vm_area_struct *vma, > unsigned long addr, unsigned long pfn) > { > - pte_t *ptep, pte; > + hw_pte_t *ptep; > + pte_t pte; > > ptep = hugetlb_walk(vma, addr, huge_page_size(hstate_vma(vma))); > if (!ptep) This is interesting. Assuming we'd had a hugetlb_hw_pte_t, we be able tojust naturally catch things like using ptep_get() instead of huge_ptep_get() That caused bugs and headakes before. But I'm not actually proposing that at this point, because it would make messed up infrastructure where we hacked in hugetlb, like page_vma_mapped_walk() harder to use. Regarding this patch, I guess we'll regenerate it when the time comes. We *might* have to do this stepwise. E.g., merge patch #1 first, to then convert individual MM components. But we can discuss that once the time comes. -- Cheers, David From xen-devel-bounces@lists.xenproject.org Fri Sep 11 17:23:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 17:23:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417670.1646359 (Exim 4.92) (envelope-from ) id 1x54yA-0006He-CD; Fri, 11 Sep 2026 17:23:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417670.1646359; Fri, 11 Sep 2026 17:23:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54yA-0006HX-9M; Fri, 11 Sep 2026 17:23:22 +0000 Received: by outflank-mailman (input) for mailman id 1417670; Fri, 11 Sep 2026 17:23:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x54y8-0006HQ-Nt for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 17:23:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x54y7-00EXeQ-FQ for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 19:23:19 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa438da-bab6-0a2a0a5309dd-0a2a4501d080-36 for ; Fri, 11 Sep 2026 19:23:19 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa43906-5984-0a2a45010019-ac6904feded2-3 for ; Fri, 11 Sep 2026 19:23:19 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 2C91C60A5A; Fri, 11 Sep 2026 17:23:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB6981F00893; Fri, 11 Sep 2026 17:23:16 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 8E68DCE1902; Fri, 11 Sep 2026 10:23:16 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789147396; bh=OJP8Kr91re/1TLbUGmF1tDEabRFooEc7DLwpbkUU1SE=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=HIZ7yScn+Y/fJxVNeSGNMIluX+kW3qXFuO1J42ABZc2Lyzd4l390tPeIoz72ca9zZ xSMOd5mDJ9gPxF1vih4YdipWkGCmMX83+qhriXF0pGjSdAJ78J+BcCTDRhqZ1ZPHz7 xwlRqpD4V42PB00qiY52yy9/bmaSCE8EkR1DRGP8DZD5cYZMwSC4bSUjzABOA39olo T9dHHVXgcLFoDm6fTUEmqpgpEgsNQkaDiiIKCvN2KVaVANuEFlOrbv0Zwg94T0wdoV L/4VpbQZgXxnSfXLkj2JRzRNuZbw+jeSgaG4gqFT/akeeog9pLPeb4xdWJTmUlyv+Q WWdU9cKD1lpDQ== Date: Fri, 11 Sep 2026 10:23:16 -0700 From: "Paul E. McKenney" To: Josef Bacik Cc: Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 01/15] rcu-tasks: Add per-task trampoline nesting count Message-ID: <90c2dfbe-e796-4125-b178-e854b40f68cd@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-1-eaaa61ed2da4@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-1-eaaa61ed2da4@toxicpanda.com> X-purgate-ID: tlsNG-d62444/1789147399-BE664757-581F8836/0/0 X-purgate-type: clean X-purgate-size: 8294 On Fri, Sep 11, 2026 at 02:08:39PM +0000, Josef Bacik wrote: > Tasks RCU exists so that ftrace, BPF and kprobes can free trampoline > text once no task can still be executing in it. Today the only way a > task tells Tasks RCU "I am not in a trampoline" is a voluntary context > switch, so a preempted task is always assumed to be inside one. > > Add task_struct::rcu_tramp_nesting so that trampolines can say so > directly: a trampoline increments it before calling out and decrements > it before returning, and while it is non-zero the task must not be > treated as Tasks-RCU quiescent. Provide rcu_tasks_trampoline_enter() > and rcu_tasks_trampoline_exit() for C users, report the count in the > Tasks RCU stall output, and, under CONFIG_PROVE_RCU, assert that it is > zero on every return to userspace since no task can legitimately reach > userspace with a trampoline on its stack. > > Only current ever writes the count and every nested user (interrupts > running their own trampolines) is balanced, so plain accesses suffice. > > The callbacks reached from static trampolines (return_to_handler, the > rethook and kretprobe trampolines) are covered by the preempt_disable() > in the ftrace recursion protection rather than by the count; note that > dependency in trace_recursion.h so it is not lost if the > preempt_disable() is ever removed from there. > > Nothing increments the count and nothing consults it for quiescent-state > decisions yet; both come in later patches. > > Assisted-by: LLM > Signed-off-by: Josef Bacik Please see below for a line-saving nit. Thanx, Paul > --- > include/linux/irq-entry-common.h | 2 ++ > include/linux/rcupdate.h | 37 +++++++++++++++++++++++++++++++++++++ > include/linux/sched.h | 1 + > include/linux/trace_recursion.h | 11 +++++++++++ > kernel/fork.c | 1 + > kernel/rcu/tasks.h | 3 ++- > 6 files changed, 54 insertions(+), 1 deletion(-) > > diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h > index 0bb6c03481fa..8da571622000 100644 > --- a/include/linux/irq-entry-common.h > +++ b/include/linux/irq-entry-common.h > @@ -5,6 +5,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -214,6 +215,7 @@ static __always_inline void __exit_to_user_mode_validate(void) > { > /* Ensure that kernel state is sane for a return to userspace */ > kmap_assert_nomap(); > + rcu_tasks_trampoline_assert_none(); > lockdep_assert_irqs_disabled(); > lockdep_sys_exit(); > } > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > index 44c07a66edff..b5c666c82479 100644 > --- a/include/linux/rcupdate.h > +++ b/include/linux/rcupdate.h > @@ -180,6 +180,37 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } > #ifdef CONFIG_TASKS_RCU_GENERIC > > # ifdef CONFIG_TASKS_RCU > + > +/* > + * Trampoline nesting: dynamically allocated text (ftrace trampolines, BPF > + * trampoline images, kprobe optinsn slots) that relies on Tasks RCU for its > + * lifetime brackets itself with an increment/decrement of > + * current->rcu_tramp_nesting. While the count is non-zero the task is inside, > + * or was called from, such text and an involuntary context switch must not be > + * treated as a Tasks RCU quiescent state. > + * > + * Only current writes the count and only current (or an interrupt on the same > + * CPU) reads it, so plain accesses suffice. > + */ > +static __always_inline void rcu_tasks_trampoline_enter(void) > +{ > + current->rcu_tramp_nesting++; > + barrier(); > +} > + > +static __always_inline void rcu_tasks_trampoline_exit(void) > +{ > + barrier(); > + current->rcu_tramp_nesting--; > +} > + > +/* A task must never reach userspace with a trampoline on its stack. */ > +static __always_inline void rcu_tasks_trampoline_assert_none(void) > +{ > + if (IS_ENABLED(CONFIG_PROVE_RCU)) > + WARN_ON_ONCE(current->rcu_tramp_nesting); Save a line as follows? WARN_ON_ONCE(IS_ENABLED(CONFIG_PROVE_RCU) && current->rcu_tramp_nesting); > +} > + > # define rcu_tasks_classic_qs(t, preempt) \ > do { \ > if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ > @@ -192,6 +223,9 @@ void rcu_tasks_torture_stats_print(char *tt, char *tf); > # define rcu_tasks_classic_qs(t, preempt) do { } while (0) > # define call_rcu_tasks call_rcu > # define synchronize_rcu_tasks synchronize_rcu > +static inline void rcu_tasks_trampoline_enter(void) { } > +static inline void rcu_tasks_trampoline_exit(void) { } > +static inline void rcu_tasks_trampoline_assert_none(void) { } > # endif > > #define rcu_tasks_qs(t, preempt) rcu_tasks_classic_qs((t), (preempt)) > @@ -208,6 +242,9 @@ void exit_tasks_rcu_finish(void); > #define rcu_tasks_classic_qs(t, preempt) do { } while (0) > #define rcu_tasks_qs(t, preempt) do { } while (0) > #define rcu_note_voluntary_context_switch(t) do { } while (0) > +static inline void rcu_tasks_trampoline_enter(void) { } > +static inline void rcu_tasks_trampoline_exit(void) { } > +static inline void rcu_tasks_trampoline_assert_none(void) { } > #define call_rcu_tasks call_rcu > #define synchronize_rcu_tasks synchronize_rcu > static inline void exit_tasks_rcu_start(void) { } > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 8b3d47a325cc..d2e7b1b3c9d2 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -956,6 +956,7 @@ struct task_struct { > unsigned long rcu_tasks_nvcsw; > u8 rcu_tasks_holdout; > u8 rcu_tasks_idx; > + int rcu_tramp_nesting; > int rcu_tasks_idle_cpu; > struct list_head rcu_tasks_holdout_list; > int rcu_tasks_exit_cpu; > diff --git a/include/linux/trace_recursion.h b/include/linux/trace_recursion.h > index e6ca052b2a85..2da23a52ca4a 100644 > --- a/include/linux/trace_recursion.h > +++ b/include/linux/trace_recursion.h > @@ -153,6 +153,17 @@ static __always_inline int trace_test_and_set_recursion(unsigned long ip, unsign > current->trace_recursion = val; > barrier(); > > + /* > + * Callbacks reached from static trampoline text (return_to_handler, > + * the rethook and kretprobe trampolines) do not maintain > + * current->rcu_tramp_nesting themselves; they rely on this > + * preempt_disable() to keep the task from being preempted, and thus > + * from reporting a Tasks RCU quiescent state, while an ftrace_ops or > + * its data is in use. If the preempt_disable() is ever removed from > + * the recursion protection, this must rcu_tasks_trampoline_enter() > + * here and rcu_tasks_trampoline_exit() in trace_clear_recursion() > + * instead. See CONFIG_RCU_TASKS_PREEMPT_QS. > + */ > preempt_disable_notrace(); > > return bit; > diff --git a/kernel/fork.c b/kernel/fork.c > index 416758c8a3d4..cfe3a8e53fbd 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1869,6 +1869,7 @@ static inline void rcu_copy_process(struct task_struct *p) > #endif /* #ifdef CONFIG_PREEMPT_RCU */ > #ifdef CONFIG_TASKS_RCU > p->rcu_tasks_holdout = false; > + p->rcu_tramp_nesting = 0; > INIT_LIST_HEAD(&p->rcu_tasks_holdout_list); > p->rcu_tasks_idle_cpu = -1; > INIT_LIST_HEAD(&p->rcu_tasks_exit_list); > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h > index 627295396cd9..1662ba18bf34 100644 > --- a/kernel/rcu/tasks.h > +++ b/kernel/rcu/tasks.h > @@ -1113,10 +1113,11 @@ static void check_holdout_task(struct task_struct *t, > *firstreport = false; > } > cpu = task_cpu(t); > - pr_alert("%p: %c%c nvcsw: %lu/%lu holdout: %d idle_cpu: %d/%d\n", > + pr_alert("%p: %c%c nvcsw: %lu/%lu holdout: %d tramp_nesting: %d idle_cpu: %d/%d\n", > t, ".I"[is_idle_task(t)], > "N."[cpu < 0 || !tick_nohz_full_cpu(cpu)], > t->rcu_tasks_nvcsw, t->nvcsw, t->rcu_tasks_holdout, > + data_race(t->rcu_tramp_nesting), > data_race(t->rcu_tasks_idle_cpu), cpu); > sched_show_task(t); > } > > -- > 2.55.0 > From xen-devel-bounces@lists.xenproject.org Fri Sep 11 18:46:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 18:46:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417762.1646391 (Exim 4.92) (envelope-from ) id 1x56Gb-0002M2-CR; Fri, 11 Sep 2026 18:46:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417762.1646391; Fri, 11 Sep 2026 18:46:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x56Gb-0002Lv-9m; Fri, 11 Sep 2026 18:46:29 +0000 Received: by outflank-mailman (input) for mailman id 1417762; Fri, 11 Sep 2026 18:46:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x56Ga-0002Ln-56 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 18:46:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x56GY-006Y5d-U3 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 20:46:26 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa44c7e-8faa-0a2a0a5109dd-0a2a4503d480-8 for ; Fri, 11 Sep 2026 20:46:26 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa44c81-fae8-0a2a45030019-aceafc1f9768-3 for ; Fri, 11 Sep 2026 20:46:26 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 79CD3410C6; Fri, 11 Sep 2026 18:46:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52E991F000FF; Fri, 11 Sep 2026 18:46:24 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 17178CE1902; Fri, 11 Sep 2026 11:46:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789152384; bh=BEH5L0y3LixWWPpE999YsoF8vwfZIA/JtkIUSaMP+LE=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=M9R+fJHeZmy6WEfJ+D6CNLH+c3kjB5rut7ErP2+h8nVsKa7j3etNfbwtdp8rS80MS fPhFABuFdrUdvOlZdTQAQCr61orU4wm/RjC2OU7poW1VrwvZyfgZGrC+qE1sarkPq0 QuxzQZPObBkWqJyMQach0VVskbIlHcGS9oQDOKxfOvJgnVD5bycCjFRDIgaYdLH17Q UJmHrZwzXcEdIcRWoMRdQtTKfYNAHGRWaw/E2J3Bjse6JBE5JIuSHCfhhwe6AtNnRq Z179pIn76KHvhsX6T+IKzErceu3YloUEBWmwjn5CgynJh7djSuiFdwsOpDYYGmPtoi fH4mBz7X+Zqjw== Date: Fri, 11 Sep 2026 11:46:24 -0700 From: "Paul E. McKenney" To: Josef Bacik Cc: Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 15/15] rcu-tasks: Kick running holdouts through the scheduler Message-ID: <78c438b0-9c9a-4307-a6f7-19e69adc20c0@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-15-eaaa61ed2da4@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-15-eaaa61ed2da4@toxicpanda.com> X-purgate-ID: tlsNG-33051d/1789152386-6C8DD4E9-89564143/0/0 X-purgate-type: clean X-purgate-size: 3285 On Fri, Sep 11, 2026 at 02:08:53PM +0000, Josef Bacik wrote: > A holdout that is running on a CPU with nothing else runnable is only > preempted if the tick acts on rcu_request_urgent_qs_task()'s flag, and > there may be no tick. Now that a preemption outside a trampoline is a > quiescent state, have check_holdout_task() call resched_cpu() on a > running holdout as well, so the scheduler IPIs it and it goes through > __schedule() and reports (or, if it is inside a trampoline, does not > report) its own state with purely local ordering. Nothing reads a > running task's rcu_tramp_nesting remotely. > > Only under CONFIG_RCU_TASKS_PREEMPT_QS; other architectures are > unchanged. > > Suggested-by: Paul E. McKenney > Assisted-by: LLM > Signed-off-by: Josef Bacik Much better! But please see below. Thanx, Paul > --- > kernel/rcu/tasks.h | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h > index ba432bd922e2..02d2592ab7a3 100644 > --- a/kernel/rcu/tasks.h > +++ b/kernel/rcu/tasks.h > @@ -1038,8 +1038,18 @@ static bool rcu_tasks_preempted_qs(struct task_struct *t) > { > return task_call_func(t, rcu_tasks_switched_out_clean, NULL); > } > + > +/* Make a running holdout pass through __schedule() soon, tick or no tick. */ > +static void rcu_tasks_kick_running(struct task_struct *t) > +{ > + int cpu = task_cpu(t); > + > + if (task_curr(t) && cpu_online(cpu)) > + resched_cpu(cpu); > +} > #else > static bool rcu_tasks_preempted_qs(struct task_struct *t) { return false; } > +static void rcu_tasks_kick_running(struct task_struct *t) { } > #endif > > /* Per-task initial processing. */ > @@ -1219,6 +1229,7 @@ static void check_holdout_task(struct task_struct *t, > return; > } > rcu_request_urgent_qs_task(t); > + rcu_tasks_kick_running(t); Something I learned the hard way, though Google paid most of the tuition for this lesson: There can be a *lot* of tasks on large systems, as in hundreds of thousands of them. If these tasks are consuming CPU in very short bursts, we could easily repeatedly invoke resched_cpu() on the same CPU, and all invocations other than the last one are redundant. I instead suggest doing something similar to force_qs_rnp(), where a cpumask is accumulated and at the end resched_cpu() is invoked for each CPU with a bit set in that mask. Of course, if a CPU appears twice while traversing the tasks list, then each of those tasks did a context switch, which would have reported a Tasks RCU quiescent state. Unless those tasks happened to have non-zero ->rcu_tramp_nesting at that time. Which suggests that each task have a pair of counters. Or that rcu_tasks_trampoline_exit() should check for zero ->rcu_tramp_nesting, and report a quiescent state at that point. Either way, if a CPU appears only once in the tasks_list traversal, hitting it with resched_cpu() makes sense. Though we might also need to suppress calls to resched_cpu() for grace periods that are (say) less than one second old. Thoughts? Thanx, Paul > if (!needreport) > return; > if (*firstreport) { > > -- > 2.55.0 > > From xen-devel-bounces@lists.xenproject.org Fri Sep 11 18:53:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 18:53:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417786.1646401 (Exim 4.92) (envelope-from ) id 1x56NE-000463-1r; Fri, 11 Sep 2026 18:53:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417786.1646401; Fri, 11 Sep 2026 18:53:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x56ND-00045w-Uv; Fri, 11 Sep 2026 18:53:19 +0000 Received: by outflank-mailman (input) for mailman id 1417786; Fri, 11 Sep 2026 18:53:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x56ND-00045q-7p for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 18:53:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x56NC-0033NG-Fs for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 20:53:18 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa44e1c-8faa-0a2a0a5109dd-0a2a4501d5e2-4 for ; Fri, 11 Sep 2026 20:53:18 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa44e1e-5984-0a2a45010019-a237832fbf7c-3 for ; Fri, 11 Sep 2026 20:53:18 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id EF2BC4EE01FE; Fri, 11 Sep 2026 20:53:17 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789152798; b=NFGGyry99wHxT89hqTXy6eIQDuDC0zg6dv+ZvKqXpfEdWnzDqEYI9I35Jz3z4BNifFP8 EAGiJ5+SUSK8NjkFnGbMEU02Y6DEGnh8m/wh1y5j1zhMh1jzKVnURIjLtAvrVWHluRYSA 7uVZx7EEn45BZSyP5xddcMMAi6CMOQau5jg46jH14XIWOF8X1nO+XsKTvZIC5UyF7UW6l lfJ/jdGlhqWw6P4tyd5bXEyRGrW+wZqoH2eJ0Q0qHTQuHNq0KFp14gxfRJDEHz4QOhbH5 FgjwS/FMpmqr6wn9vTEKN+xWKE2Wt5rCWa2eExGyuBzqyC8zsRR8g6EZC+b1kPLM3y7TO m229J0+Mv18vuFn300VWRQEr1chqMKZfh2Hl783mGMvB19EVoxxcrABeaCoeJMeRu+P3X OHBsykeoxLWWTV9OzYJRB6ZpcWja8fPdAoL8rJ+EafUK+4MyKgrQncg+7s6k81WXZDvCu /eoYnn2OI04MDRE8MdFtSjpoPCB7wA20y6mYRm4letMt7sL7+1kx9I7cB906HEeEUgEQT VzbNXq3pKceyZLXjSem2Epo62NRHWj/rK16h9LZL+tvlr7VWhJ1HrEfRobrrBMq0Puc2c V7g9R+PXLgQMWZ1cIRelDn91bSK68SJmnBifVDjaYZCumElRr090xzFGJdFH944= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789152798; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=/Nl/bXoLlpRodQiguxc1BmSbW9w9homJBvBgY3Cas0s=; b=YWIne7AgnBevLcbDiNdGiNA6bj6VBfqjURLyj8Vxc7rZyifFoKsuS3CnPJWcqVr16hoX GrDWChT7wQsZL97iy2ulvAcjl/qObxaGCj2NX1wzTGr9AKZ7Qo0maLEXH2CiQwSQ8TZJB udAE1gUfDRWVJAzszsy7kByM7u27KIvJ7O4q7FC8hyrtClDUSpA28+HwFUCcHp+EG+9yf 7y7g0LraJyAM9IsWyRjmyEiTt4U4t4cgYPDm4GVORL3ykCG085Gfog4EL8zYtz7wUA9hA zFXLL4mwHWkIMtVgJBaNmPqaagQMfLvLIsKZsis5qpJji0a1Xg92+SzjenEzKzTpDTkGd eS9xCpAV1LsPi9RTsWQKt9Hk8BOOK44caXeezMFSqTmwHnWvotTVN5PT6kFhbtR/FkjJF ykJM7Z4inbTiN5p6oEy/K9MVhxc1Md5I0DfCg2nup/BKoj/1IKyO2+fyZI1GFmiPNFaU0 1I6WKJQNU5d20CLSQaYUDUp1T/hGrxNS/Oj57uvwmS2Lsy66w99RKVkj4ZeDvichEgcx+ 3DM7OVFyi0FqLrAJzhzCemEhp9vfSSI30Q3iy0ztCxnHtwhufGyPhLlySAmlGOgNHecAN 9f3h72gTfxZ2TSXuIjhYTs0H40tkw+IppsuyCTXsYuW4XapUl83BKMzMqrsbQqU= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Fri, 11 Sep 2026 20:53:17 +0200 From: Nicola Vetrini To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Jan Beulich , xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation In-Reply-To: References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com> Message-ID: <46dcfb81294d6f644a4d3f3c11b1f47e@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1789152798-BCF47757-0521F5DA/0/0 X-purgate-type: clean X-purgate-size: 2351 On 2026-09-10 14:29, Roger Pau Monné wrote: > On Thu, Sep 10, 2026 at 11:52:10AM +0200, Jan Beulich wrote: >> On 10.09.2026 11:30, Roger Pau Monné wrote: >> > On Thu, Sep 10, 2026 at 10:38:34AM +0200, Jan Beulich wrote: >> >> On 10.09.2026 09:49, Roger Pau Monné wrote: >> >>> On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote: >> >>>> The use of unreachable(), when unreachability is visible to Eclair (and >> >>>> compilers), is deemed a violation. Drop the redundant statement. >> >>> >> >>> Urg, isn't that something that should be fixed in Eclair then? >> >>> Otherwise all the unreachable() calls in our codebase are likely to be >> >>> found by Eclair sooner or later, and will need to be removed. >> >> >> >> No, aiui most are covered by deviations. In particular ones in BUG() and >> >> ASSERT_UNREACHABLE(). >> > >> > Shouldn't this be a deviation then also? >> >> Maybe, just that I had no good idea how to express such a deviation >> (preferably >> without a SAF comment). >> >> > Maybe it would be helpful if >> > the commit message states why this is handled differently from other >> > unreachable() instances then. >> >> I've added "..., , and the one here isn't covered by a deviation" to >> the first >> sentence. Will that suffice? > > TBH, the handling of unreachable() feels inconsistent to me. I don't > blame you for this, I know you are just trying to fix the remaining > issues. > > I guess I will defer the change to someone more familiar with MISRA > and why some unreachable() usages are covered by deviations while > others aren't. > > I think the point of adding something to the commit message is to > justify why this is removed vs a deviation being added. > Actually this should be done with a deviation, and I thought it was already taken care of by -config=MC3A2.R2.1,statements+={deliberate, "call(decl(name(__builtin_unreachable||panic||do_unexpected_trap||machine_halt||machine_restart||reboot_or_halt)))"} namely because unreachable() expands to a call to __builtin_unreachable(). It might be worth checking why that is not the case. Probably the configuration needs a slight tweaking. -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 19:32:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 19:32:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417832.1646411 (Exim 4.92) (envelope-from ) id 1x56zP-0001Wt-UT; Fri, 11 Sep 2026 19:32:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417832.1646411; Fri, 11 Sep 2026 19:32:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x56zP-0001Wg-P6; Fri, 11 Sep 2026 19:32:47 +0000 Received: by outflank-mailman (input) for mailman id 1417832; Fri, 11 Sep 2026 19:32:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x56zO-0001V9-El for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 19:32:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x56zI-004ayQ-RY for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 21:32:45 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa45745-2eae-0a2a0a5409dd-0a2a4505ae84-12 for ; Fri, 11 Sep 2026 21:32:40 +0200 Received: from [52.101.193.25] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa45757-4cb1-0a2a45050019-3465c119cf97-3 for ; Fri, 11 Sep 2026 21:32:40 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB815874.namprd03.prod.outlook.com (2603:10b6:806:58c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Fri, 11 Sep 2026 19:32:06 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Fri, 11 Sep 2026 19:32:06 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=e/T2oP7tJeCl4h0Md4WRmiN6idwZcR4jxeuPkGAzb1O6iDIsHeuHZE70Vy/ZsUYhmFKNRR4sHMGON/FGBpd01WbACp8LWG7A2gVQxM8ioh71k+w8i22UurazLFUzASBWmfY+1vnWrQSSVbBW151v+WW1M8wQ4p23GwCrVlMia+my166zSPfqAeZ7HpcK8UMd+qd41ACrg6oIHmdZZ3AH08MvlbamONpO3JPv/WvsXeu0mdkZos+P+5qtj+ki0Ec34z64NxWoleSK57tjNyGl8lFI8F+X9XxLvOdlGQLJazMMI77RQIxD5eS8e0h9s3Ca3tVQqI0h1pnw12IJQiqlcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FB5TtqEQywMrq2bB4v+9nNxpSSDLHMIXq7Ss0/YQAR4=; b=wb4ma3c8aWPQRt5+rNS12uUsEpzRVF0NvwRIs8qR6A3lLBx7BCB6RWwBoIOcevUXNRe7BC0vBiShNeO7L00LWAqZfmp0/Qy5RekQAOKId0Jug+LFXUBwMQK31sBES3NsdpZ7D5d+bBYJiqhzx27Jb5aYujq44z0fVrN5+bHWuz1Rfbd5r52SPexT9YGi32lpmphNjHQ/RPmlfl1l/XasHecQYiHGuxbv3TkZ0RaxSFW9XI1JKSctxof5GxyCNpHHSizxd0U9vzRR1j5Iv4RkSIjfiC/Wktr+tGl66uYidFETtWgjqPd2rsbMBwKLIh57A6vs7h6zsAl+DJQEWn8kRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FB5TtqEQywMrq2bB4v+9nNxpSSDLHMIXq7Ss0/YQAR4=; b=M4J+6jq9Yn1ipb8f1vhGQ5mAtwhOvzU9Qq2hBgeESK62aaK1EmtxFYH4Nef0QIc7C2qLXM5LBQWktQI+hOQ/ChBXjxHpODiPKvhnhgoR+OxvyGkUrGTqqd5PxMqrHNEXzDILD0XKwuGCGjOI8CTgtW7fTM6ny9xofxPATHBQ2s8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1f166505-507a-4932-b4a1-0e9a123d7807@citrix.com> Date: Fri, 11 Sep 2026 20:32:01 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , George Dunlap , Teddy Astie Subject: Re: [PATCH] x86: always park offline CPUs To: Jan Beulich , "xen-devel@lists.xenproject.org" References: Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PR3P193CA0033.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB815874:EE_ X-MS-Office365-Filtering-Correlation-Id: 6288ca96-bd22-430b-89b1-08df103b5d2f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|56012099006|11063799006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: /aOK0IRwrOQlaJHZDLqMCBnHU+kP7wDhe9wW7lVGw0JkqmyQ/cKIN5gwKuFoxBYz3NrJZXcv6AqDq2POkPqp9RDhllWwctlOLwUDW6vBQOB7y/wPkzZ5ofubI36KAPAo0h56gwnRyPLIGEVxj5A9mBaXNpTTiZleeKLUduhitU9nd3WzgylZYVQufv9D5SKhilH12qoFanNcqAptQjdbeVLrI/a99mG04epvPwEwPpwCFCZKSfFt/VvHbhpWWX2qnT+UEvrj2uMVFZLV2sJkCPlct4mKAA3pyCnCfogf/U8te9XofuwaGKb9gbnqAKXrSTJXTsE0ef2eHF46FxpPka86yNISquzT7BXRcoeYklIMXKi8nLCR7c2jqiyzAF+pbAH9VVmSv374drOjpmnHQEhJ6dPKM2VtmHZQdZP59vngb2VgRPrIq3PPqPJCoL2lhaga6JL9AkCWHFJL7EZD/aTUAfDLWTUkV+X+v8hLgZcSsIV2P8N/9rc/Hasl7pPwiAU6+pEp+CUzA/++qGEgWDIbhp8WFJYx3E0LAekB0N0W9MewDEn/Qksct4goJ4gh6oPZrwySZ1sKNREDBwKkWtwS+/clGdAGDGr5yZEnwr2K258H6sIXQWjNT8jG9HbM+3xTkhx74EK6F3fh0LvlsNaHV4fL2m/Fi5gJ9iGQVco= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(56012099006)(11063799006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YmNZYXVRV01sM0REUDJmV0xBMjFjSE1tektQMVdidkxBTURzNDNGRTZCem11?= =?utf-8?B?MGpLUjFaMCtCRDFJYXpGb1RTVmtxdG1RYjJHSE1PdHJMdHFLdGpqckhXcWU2?= =?utf-8?B?V3JWcC9jb2pGUW1BYzlQamY0bjNrZnh3QUJaSjlxV2pvS3BzZmZHa0kya3hm?= =?utf-8?B?dnR4WFZ3UEFvUjFzc0xMMnQvdkxvQnFNM2F2anNQc1JPK2VjV2dySmVKRjdT?= =?utf-8?B?WVRlS2hZWjlUZk9DN1BnL0szdnRFYisvRUdVYnZUbXhMUUlFdDZGQzRqdVhr?= =?utf-8?B?b2UxUUk1dk55NlFyTG5hMWs0MjVTUmZPSGlIUC85TW5OVTBudnNTVU5XaWN3?= =?utf-8?B?SlhqdnJxbnFTQmJpTUJFa3htVHU0WFl4R1o2dEt4Uldwd09MV1A4WTV5bDgw?= =?utf-8?B?OWgxUGUyVmdPTXh4WmZJY3o0ZnRuYXR1bDhadlZsblBzcHF4a2ZLVFpCRWZn?= =?utf-8?B?QU04SFQ1d3A0a0twcjV3Q3lNVVVkZ0ZSL0k1TjJua3d1bW5lbWZFNHpJVlU1?= =?utf-8?B?bjNLWFh5THRQKzdmRlN1aFRWNEwrcHpZY1VGTnl0cHEycWpoaVNyalJJdUhE?= =?utf-8?B?V3JPTnRPUFo5NEpwR2NlMVhHL09lWndaa3NuMjJsQzZORXdKbkc2dzJLM0hV?= =?utf-8?B?OXFnSitWNi83L0o0MzR6U2I2NzZvUlVpTWw5SVA3V1o4aE1La2Y5YXE0NFNO?= =?utf-8?B?UlFaNGxZbG5jSSsyWlF0dzdtYjMya1pSVmJuYnJDaFRJWWpjZklLcFp6MVc0?= =?utf-8?B?My9oUytYQVphTHpsZ2ptaVlDWWhPbWh0NWdaSENUUVlLaXZMMjFoTlN2alRW?= =?utf-8?B?VUtxV2VjaVZMbk5MdGVqdWxjc2RrdElxZ0h1aGwxdnU0MVlYd2NyanozZlBz?= =?utf-8?B?N1VhSlI4VGM1LzlRSTRuTjRJVk52Q1VONmQ3dU04c3JVVUo2MkRZYjdSbEFa?= =?utf-8?B?a0h3YWNvUHFmUXRodk1KQ1pKTTZRbGxVWVVZRDVlUmFtUnE3WElndjlFcTJ6?= =?utf-8?B?NWlQanhsQzFURWtURy82WThvTVBWaXF4WmI5SWtCcFZyZHBTOUg2d0dJTDEx?= =?utf-8?B?ZFRNRUw1cGFzQzRQS1hiNVVLTjI3bStWSkJwRkoyVGNUbzlnRmhBRnF2NGJs?= =?utf-8?B?VTVYWnJCaFZLSGlGa29EanJjNTN4U0E3aEFwd2IwNzVtWXBra1JodWpMdTJi?= =?utf-8?B?WjFuODdMVmtSKzdtVFNrT3h5MlVhZVRGVE9FbzBYUDI1Zm0ydCt2elBLaDNG?= =?utf-8?B?ZldxaFJsOEp2Zk80V0Q2S0dwejlEaXZSc3V3bmh0VC9BdG9rcU1nTUl2TzBV?= =?utf-8?B?MDRqQWx6N2txRThKU0luL0RlczNhZFptdWV4ZVNOMzJndFpIQWo5elhHbzAy?= =?utf-8?B?Wi90a1RFcVZuQzBmR0ZQQzVmeW5ZVC9UcDh1NXVHSFNBblZieFRTV2VKYXFm?= =?utf-8?B?bHROMVJiUktGcUZ1cUtZYXh0QldGTm5nQXhvL1cvY2l3ckprSlN3ampVL1Q2?= =?utf-8?B?VmxnbHhTK2EyamVITlFaU2l2NUY2U1NQb1pxT2ppSnFGZjZhdDBidEhZdGJQ?= =?utf-8?B?ZEpUNytrZERXQitIaWx3WExKd3VQZnhvZ1lCamdkQk1xa3JXMXlrajQzQWFp?= =?utf-8?B?SGlZT1l1RUVjMHpDTmpLbGJsOTNraDh3WHV0bUxPSmFmWk92UXFJUDJNeGxh?= =?utf-8?B?MmJ2c2lIMWNTeVBWWGxrR3k2NitSM3BIT0JKb1FpWjBFeStuQ2JucmNQUDEz?= =?utf-8?B?ZEZDUDNzelN0V1lWV3dhOFdBRHp4SmNWQ1VJZGExS1VoM3d5ZVlSdHVvVEMw?= =?utf-8?B?YmZ6cVlvMzc1aXk1MTY1OXM0OVRGM2ZvQTZ6bE9TY1RZdDAxOXdIVTNHK0Na?= =?utf-8?B?cGVWczdUV2pidzQ5SEJ2U1dPRm83WGNtUi9WLzJja1Q3TTBGMDJOUzdFMmJG?= =?utf-8?B?NVdYMkFiRXFTOGlCZGF5NmZlaW1NNXVSQXgwcFF5TVFvdlYwRzROeVYyR29B?= =?utf-8?B?NnFycjgxSk0yRzRQUElJV0laQktGZmJNVzRiZ3N6QVhkWWZXYkpldC9Kano4?= =?utf-8?B?ei9PZkdjWHVJUWNkUjRoRFVzcmgzbnRzVUJGV1ZmYlRRemxnNlFnMmF0Rk1Q?= =?utf-8?B?SkFoVGxmMUdHMGVvM241NlJLYmFZVUZwd3MwaWNLTGlnTzd0bzg5Wk93RUN2?= =?utf-8?B?TGhsaUU2UG5kbXQzRUQ3SysxeDMvQWkydXBDZlJIZjBoY2JwejdVZEZLYXM2?= =?utf-8?B?NnMwTWRlZ0V5a241RTdQbTZkYmpMNVZBWlhZN0daR0RxYmNDT1Y1VkpJaWVR?= =?utf-8?B?WElickJJcjNMREF1SE5MakZaWng1emMrczlYQlRRaGlNRnoxNlpiVlRlYnFa?= =?utf-8?Q?7AZg9Gzy2FWXQraw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6288ca96-bd22-430b-89b1-08df103b5d2f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2026 19:32:06.3441 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: owWUYrD5YYcoOuWsjTBK4my+4ociBwDM8vpJ+MGTugNFe3tstpH9pagKjdIXEaYjMFElhL6ZWU8pQFOYtNLBkgv8ad/sCGasQmQ9/v7+MoY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB815874 X-purgate-ID: tlsNG-c201ff/1789155160-F46A52A1-B1A0959B/0/0 X-purgate-type: clean X-purgate-size: 1326 On 26/08/2026 1:36 pm, Jan Beulich wrote: > While on AMD (or Hygon) CPUs the situation isn't as bad wrt broadcasting > of #MC, some "multicast" can still happen. Therefore the reasoning to park > CPUs rather than fully offlining them applies everywhere. > > Don't retain the dependency on the "mce=" cmdline option either: That > option may best be dropped as well, as not enabling MCE will result in a > shutdown when #MC would otherwise be raised. > > Drop the global variable, using a #define (just like common code does) > instead. Outside of common code, simplify expressions / code accordingly. > (In common code we still have to cater for x86 wanting it different from > everyone else.) > > Suggested-by: Andrew Cooper > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper > --- > As it was never actually used after its introduction, we may want to > further consider dropping CPU_REMOVE again. > > I was almost certain that we would have at least one place (presumably a > CPU notifier handler) were we assumed no parking for AMD/Hygon. Yet I > couldn't find anything; did I overlook the crucial bits? Quite possibly not.  This code very rarely changes. There will be a lot of cleanup to follow. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Sep 11 19:39:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 19:39:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417844.1646419 (Exim 4.92) (envelope-from ) id 1x576H-0002Fq-Ha; Fri, 11 Sep 2026 19:39:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417844.1646419; Fri, 11 Sep 2026 19:39:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x576H-0002Fi-E0; Fri, 11 Sep 2026 19:39:53 +0000 Received: by outflank-mailman (input) for mailman id 1417844; Fri, 11 Sep 2026 19:39:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x576G-0002FZ-43 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 19:39:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x576F-002ER5-2l for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 21:39:51 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa458d0-8faa-0a2a0a5109dd-0a2a4508cb32-24 for ; Fri, 11 Sep 2026 21:39:51 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa45905-f659-0a2a45080019-aceafc1f99e4-3 for ; Fri, 11 Sep 2026 21:39:50 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id CC930404B7; Fri, 11 Sep 2026 19:39:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC5421F00898; Fri, 11 Sep 2026 19:39:47 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789155588; bh=/psdj2YLMEmdCz9D5VhRewqtuEdv9ATvtmsLuk3XzfI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=k9Ez1FpUvK4PGlaqmgOmqVif2tzopAFjAYcoB7pajNhBwdstU1Z9owHylMahYXQ+z ZG4M7ztSdXAV4hpI45PEQT9QcM7xv30jkZZMPlo8qHc4FPvHQAccBgxTCP+gghiad8 QRYIu68YXGTuTGjFw3qWcwnjx3nl2fhu2/iyG9QKpu2Qh+i/8cl/PV6XONNLmh7w5w bFy967zuR8OD/rNEkMItJr6j1VzgLe3Of41NLWGfuxqPwQU+EDrtsieVRjhJ9B/tJ9 go/TwmbvgH1b7ccxdgtT5YJNAVD3jUcizYQOS23kB2NxTJc3Pc9V5bru/0JjbEqAuq eFINiLj0XXD6Q== Date: Fri, 11 Sep 2026 12:39:44 -0700 (PDT) From: Stefano Stabellini To: Karl Mehltretter cc: Stefano Stabellini , xen-devel@lists.xenproject.org, linux-arm-kernel@lists.infradead.org, Tejas Mutalikdesai Subject: Re: [PATCH] arm/xen: Point the comment at the YAML binding In-Reply-To: <20260907012430.21823-1-kmehltretter@gmail.com> Message-ID: References: <20260907012430.21823-1-kmehltretter@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-purgate-ID: tlsNG-c1860d/1789155591-D457487B-6281FF35/0/0 X-purgate-type: clean X-purgate-size: 1125 On Mon, 7 Sep 2026, Karl Mehltretter wrote: > The binding was converted by commit 4dbfe5467485 ("dt-bindings: arm: > xen: Convert to DT schema"), so Documentation/devicetree/bindings/arm/ > xen.txt no longer exists. > > Point the comment at the YAML schema. > > Fixes: 4dbfe5467485 ("dt-bindings: arm: xen: Convert to DT schema") > Assisted-by: LLM > Signed-off-by: Karl Mehltretter Reviewed-by: Stefano Stabellini > --- > arch/arm/xen/enlighten.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index 25a0ce3b4584..0b7b7e3417e3 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -251,7 +251,7 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname, > } > > /* > - * see Documentation/devicetree/bindings/arm/xen.txt for the > + * see Documentation/devicetree/bindings/arm/xen.yaml for the > * documentation of the Xen Device Tree format. > */ > void __init xen_early_init(void) > -- > 2.53.0 > From xen-devel-bounces@lists.xenproject.org Fri Sep 11 20:16:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 20:16:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417881.1646428 (Exim 4.92) (envelope-from ) id 1x57fL-0007p0-0Z; Fri, 11 Sep 2026 20:16:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417881.1646428; Fri, 11 Sep 2026 20:16:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x57fK-0007ot-U2; Fri, 11 Sep 2026 20:16:06 +0000 Received: by outflank-mailman (input) for mailman id 1417881; Fri, 11 Sep 2026 20:16:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x57fI-0007oU-UH for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 20:16:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x57fI-00AA6A-B1 for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 22:16:04 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa46122-8faa-0a2a0a5109dd-0a2a4509d854-32 for ; Fri, 11 Sep 2026 22:16:04 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa46184-be1a-0a2a45090019-d1558032c9a8-3 for ; Fri, 11 Sep 2026 22:16:04 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49ccfbe062eso14950355e9.3 for ; Fri, 11 Sep 2026 13:16:04 -0700 (PDT) Received: from localhost.localdomain (host-78-146-248-75.as13285.net. [78.146.248.75]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d26be3e0asm196055565e9.1.2026.09.11.13.16.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Sep 2026 13:16:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=citrix.com header.i="@citrix.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1789157763; x=1789762563; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=momxIyehCGQOyxryb3A4m/ZgrOarR4Zu7NPnAmjz7Vc=; b=YUMIZCo87LuGCAYgufeU6CPG0rzbN1ikL4jEh2LEmz3h8Wf0J+mcNJfbYEpxqWWZ3j mUcNhETfUUIy7az5PqSJSH++OfNIeDc4SBS707b8hy768RgOHrvZS61xBBqW+HeTgizS 3dYvJU7BuzBJBDui+SOl7ui1VZTQIcn2p2v9I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789157763; x=1789762563; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=momxIyehCGQOyxryb3A4m/ZgrOarR4Zu7NPnAmjz7Vc=; b=AYeesxjSFj8hDL51v4mpOSU2mNoF1S0MwTW1iMg2D53xd9NH8kaYWpqsejgr+9Yztx pXdKX39xEuzyMAd12pa/KkmN8yuiIkqmAg0u+mX/rXP8SpvlLsXK7VSC2sjj7KXlVnBt 13t2YcSpeXPdSWg2oZojwtmmY47Su3VANjOB6rXJYshnhlZG4AVzO6SO+/grGQfCNrMJ c0kjXJCaWulvAjhknWrLsl1ywGuUSSJrBKC1P0ZHqQOkFjWtQAgromuVjaMO3n4bCGJn zPO0d/6EX6E5eg4Oyzq8N8m+H6dZ4qq0G4wotdfEYJnmW6zWnXCSFmK/TsXGG/SDGkkL sokg== X-Gm-Message-State: AFuF++mlL3ogovYweMesEmJ0A94j4rUqZ7BVW308X3GUBtYQGyMfzG4M Q1oFfGVS8i92ouzBgAF9OJowwk9ke7APZy7akDfQ+ocXX3YMFEp0FHZ6/pdwMmDFhtEsTE7Dco9 LrqYf X-Gm-Gg: AYBFou1KjnmrbsggC0/W2TJBGnwWZitMcKDWG3AjEZEBaOI/8BYy+FuWeg+DF8uz9Xv moiMbeUmVHKc5tmPzBpRVaf7uIvr8Bge49UvoKR7JJKwp5pznsL1qT6d7Dws0lwlBEvWZM+6vgG odIIiyvP59gpLGh3crzRwv74RjOGADsTWo2FdjSa3Zo9YV7Jq6scQAOyZJpafkNC215Y9xjTriM AMeK5Ag+luH0RdFsPfSWFSJyOiHT/qxp8zKYtP8qtCuReQTNWeLYIVcJHtSK6fLR9kK0UeQpbBw /AqlXREPcsEfAAMOJwgBoG/jlVUCm1c3eKn0W5CPDeDVcywKKT1lRkrRFYT0CXOtPy+LttnYWQi YNbJPr168ni6Bx6mRVSudZXIDkJaksnlrzzD+FwYYOKMAbOBX64TBYlVTyIyjAlYVqga0f6YzCH LZsakwlxfJJ27R2QhweoxXLS/6DZjIzLxKuzn8mcwS+ac4xLyzk7ZM+YFfySu04ExUHre6YdyAK kA+OCPJtHwYL5+/MqhKOnx/pxJIloA9NRGX3ByTFON+0XBGZaplRRsd3JaR X-Received: by 2002:a05:600c:548b:b0:49c:fa20:cc00 with SMTP id 5b1f17b1804b1-49e619cecc2mr71683005e9.23.1789157763110; Fri, 11 Sep 2026 13:16:03 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/build: Remove leading space in xen.efi.S rule Date: Fri, 11 Sep 2026 21:16:01 +0100 Message-Id: <20260911201601.3682596-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1789157764-3A4DB034-81CF7E9B/0/0 X-purgate-type: clean X-purgate-size: 1016 It happens to be benign, but it causes emacs to ask: Suspicious line 194. Save anyway? (y or n) whenever saving the file. Fixes: da944a72fdf4 ("x86: split xen-syms/xen.efi linking rules") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie --- xen/arch/x86/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index ee2573c2fb0f..8a205c3d27ff 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -191,7 +191,7 @@ ifeq ($(XEN_BUILD_PE),y) .$(TARGET).efi.%s.S: $(NM) -pa --format=sysv $< \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ - --source-name=$(TARGET).efi.S \ + --source-name=$(TARGET).efi.S \ > $@ # See above for why $(note_file) needs removing here. base-commit: 6bdb8d45b749a4f376d0380ff9503162b14b8468 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Sep 11 20:48:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 11 Sep 2026 20:48:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1417929.1646437 (Exim 4.92) (envelope-from ) id 1x58Aj-0003hr-BJ; Fri, 11 Sep 2026 20:48:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1417929.1646437; Fri, 11 Sep 2026 20:48:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x58Aj-0003hk-8a; Fri, 11 Sep 2026 20:48:33 +0000 Received: by outflank-mailman (input) for mailman id 1417929; Fri, 11 Sep 2026 20:48:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x58Ai-0003he-EA for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 20:48:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x58Ah-00F47h-RT for xen-devel@lists.xenproject.org; Fri, 11 Sep 2026 22:48:31 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4689a-e002-0a2a0a5209dd-0a2a4508ccc2-40 for ; Fri, 11 Sep 2026 22:48:31 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4691f-f659-0a2a45080019-a237832fcce4-3 for ; Fri, 11 Sep 2026 22:48:31 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 429004EE0220; Fri, 11 Sep 2026 22:48:31 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789159711; b=eUgVgdfDog3cys9qdmpsdqQYXvRqcONbLGDdltuq9JMnLBp53DyZkubLgI6RGxgL65/a frISK2L7x6xwAl9Hq6erQM3wkFBFSKBzrrFOm8JitI6MuhCLJLWvyHjTzG10ysx7AVd5y /GiZT1er2WJNuC2tTqy1S9Jkr1lDfI3H2p4u3Oha3aZvZl/DIRyopnbC09KuLsbjuZZmf 3AiGE6b5IURbQksdc7xEeMGo5vfwD4FVTOMe4YFNzpsC6UJVKmtOwD27IJfb17MFLVcvC P8t1u6FtYGp/HlWclLWpd+3XT24QoK4aL67L43inQ+V4SZzV+1V8rnDEqnKR8Pg7QFsz0 diWKPk2DCrmXaWR1v6DJtqiFgPIpDwyaDiVQppQrBtjWitgp6z56DodbLPrKPMqUSq7mr jIo0ecTr3BvjEi2/E/0S7jW5hqB+xq9EjdlTi5MmWxjJ33isyTiPMG9qpAf2JVS9ZkMlW Z5sSj4w6ibgxyhh48tfp1oLwqSDa3khfDQWEPJzMlPd61ii7urw0zQC+MuDWKIOfmIXOB V66AkH/y45y80r0ZbAC10vAbOrRs7X3z/LDJN0sp9r0rq9OtQ2tULP2MtKF5iEyx7htt9 Kg6rLA3JKntpt/9vN3XaKgzZ1p6KGaGQ4TgMRtaNFohbyOSMRTRTgTLda707/fs= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789159711; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=tOq7YAe7AEIzwPq2SUqy9vcCJts7c1Uw76MmAf6p3ds=; b=zW94Tz5Vcmn1YXk2jq6pXSKWkahq7fqIiVyHb5wftztlowjTK4niy8jwWZ6Q6RyK01iv fWUj37GjTx00jw093V5nWDrm64O6y256mqWpd4dI4fidXtR9IMcwrUiCntA1ES7h07QWn reOc2VWktMx5dV3iKrKEyqw3U1hA/D5zSwNtisiZQq/kFrS9aJvUMP/UGn7DxAS864Km7 rsZ3KwYddrIGoxhJw6ZmszaYbOOruSkhlqDypH7KCsg7P7Zi/OntM4Fm1lFt3QcLYgMrG YjkGzbXmm11l4bw8H130CwWQiYYp7Ef/Fv6ExWWr/L3pA0imDDLbH/rqzgZ6qEYf7mM0e /9nypbZ6/xQIwdVYfsQ0dI6mxdr92QvBoPFhamS3z+ttgj8BAkJuBAyl4iXxA0o0fNSeM veDqEHpayjOXjGGkAFBJ7+hUjMC3j4VlFc8bUPWvpeLMGdMCNPPS6FEAHf6hFH9Ep+sMT 0hnoeMoFNr0Xi8YNq4XXon1FD5JX/NNoGMQze0xXGdG5ZjeLmrw+Wbv/mkgT/b4JJlCvQ eE8pgjlZ3NvmBdE7dgXpybc8rjRLlG4cRJ1f5rWDPE3cyEPWV7hLyW2tvGkEoNxLQh6Sp ocs9VDCPs4Ld4PcdQt93SFX2hk+9M3lwnNVOMMIoiyoCOvpGvTi2ZpUjIQaQFYc= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Fri, 11 Sep 2026 22:48:31 +0200 From: Nicola Vetrini To: Jan Beulich Cc: Andrew Cooper , Stefano Stabellini , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places In-Reply-To: <26a57fab-955a-4de6-b17b-eb57aa1f014b@suse.com> References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.com> <320b920b3e673671eddceccb4b86f211@bugseng.com> <26a57fab-955a-4de6-b17b-eb57aa1f014b@suse.com> Message-ID: <98af89029999f2d0535d603ebf64d9b4@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1789159711-DF6D687B-A16F0436/0/0 X-purgate-type: clean X-purgate-size: 4984 On 2026-09-10 08:43, Jan Beulich wrote: > On 09.09.2026 21:07, Nicola Vetrini wrote: >> On 2026-09-01 08:26, Jan Beulich wrote: >>> On 31.08.2026 21:13, Andrew Cooper wrote: >>>> On 28/08/2026 8:01 am, Jan Beulich wrote: >>>>> --- a/xen/arch/x86/traps.c >>>>> +++ b/xen/arch/x86/traps.c >>>>> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu >>>>> case X86_ET_HW_EXC: >>>>> switch ( vec ) >>>>> { >>>>> - case X86_EXC_DF: return do_double_fault(regs); >>>>> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>>>> case X86_EXC_MC: return do_machine_check(regs); >>>>> } >>>>> break; >>>>> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp >>>>> case X86_ET_HW_EXC: >>>>> switch ( regs->fred_ss.vector ) >>>>> { >>>>> - case X86_EXC_DF: return do_double_fault(regs); >>>>> + case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>>>> case X86_EXC_MC: return do_machine_check(regs); >>>>> } >>>>> break; >>>>> >>>> >>>> For starters you're missing a break, and the only reason this isn't >>>> a >>>> compile error is the trailing comment. >>> >>> "break" there would again be unreachable, though. >>> >>>>   Second, it's a tailcall anyway.  >>>> There really is nothing unreachable anywhere in this construct. >>> >>> Just that the concept of "tailcall" is an optimization, not something >>> inherent to the language. >>> >>>> But by far the most important, it the singular noreturn attribute on >>>> do_double_fault() (elsewhere, and not visible when reading these two >>>> functions) which is preventing #DF falling into #MC.   This >>>> introduces >>>> fragility which did not exist previously. >>> >>> I realized that when making the patch, yet what do you do when the >>> rule >>> is as it is? Hence why I added the comment, really. >>> >>>> do_double_fault() would conditionally return if we ever got around >>>> to >>>> fixing espfix64. >>> >>> And hence would have to lose its "noreturn". At which point call >>> sites >>> would need inspecting. (As said - yes, I do realize the fragility.) >>> >>>> So no - I'm going to insist that Eclair is taught to accept "return >>>> some_noreturn_fn();" as intentional.  It is objectively less fragile >>>> than the MISRA-preferred option. >>> >>> Nicola, thoughts? >> >> If you find a suitable argument from the toolchain that the generated >> code is correct even though you return from a function where you >> promised not to return in its declaration, I suppose that's fine, but >> that MISRA Rule I mentioned ("A function declared with a _Noreturn >> function specifier shall not return to its caller"), which is not >> (yet) >> applied to Xen exists to defend from stumbling on UB 71 of C11: A >> function declared with a _Noreturn function specifier shall not return >> to its caller. >> >> So in general ECLAIR should not accept this by default. What you can >> do >> is deviate these (hopefully few) cases if you have backing evidence of >> the correct behavior. > > The disagreement between you suggesting a deviation and Andrew > demanding > "that Eclair is taught to accept ..." will need resolving. The argument > towards the code being overall less fragile in its original shape > cannot > easily be put away. And Misra demanding code to be made more fragile > than it needs to be cannot really be the goal either. > Well, I feel like I have explained my reasoning, but let me step back a bit and lay out the possible safe alternatives I see for this construct. By the way, perhaps it's a better idea to split off this change from the other additions of noreturn, which can probably go in as is. Adding noreturn to do_double_fault() while keeping "return do_double_fault()" in the #DF path is likely subtly broken (i.e. the compiler can rightfully optimize assuming the function does not return) so that's not a feasible solution. If noreturn is added to do_double_fault(), removing the return in entry_from_pv(), shouldn't that be guarded against falling trough via BUG() or equivalent constructs that do not vanish in release builds? My understanding, that may be incorrect, is that returning from do_double_fault() is currently not expected to happen (hence the panic() in it). The third option is to ignore all this and not add noreturn to do_double_fault, adding a specific deviation. The deviation is not necessarily done via SAF, can also be something as shown below (untested): -config=MC3A2.R2.1,reports+={deliberate, "any_area(decl(name(do_double_fault)))"} and then in its documentation in rst you can summarize why it's not being touched. -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Sat Sep 12 03:28:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 03:28:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418124.1646446 (Exim 4.92) (envelope-from ) id 1x5EPL-0003qX-Ha; Sat, 12 Sep 2026 03:28:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418124.1646446; Sat, 12 Sep 2026 03:28:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5EPL-0003qO-CB; Sat, 12 Sep 2026 03:28:03 +0000 Received: by outflank-mailman (input) for mailman id 1418124; Sat, 12 Sep 2026 03:28:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5EPK-0003qG-GO for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 03:28:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5EPJ-005F8i-0z for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 05:28:01 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4c65e-8faa-0a2a0a5109dd-0a2a450ccbd2-42 for ; Sat, 12 Sep 2026 05:28:01 +0200 Received: from [209.85.210.49] (helo=mail-ot1-f49.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4c6bf-f479-0a2a450c0019-d155d231edb6-3 for ; Sat, 12 Sep 2026 05:28:00 +0200 Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-80576d65d8eso404101a34.1 for ; Fri, 11 Sep 2026 20:28:00 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:15::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-803f6d208f5sm4822052a34.25.2026.09.11.20.27.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2026 20:27:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="In-Reply-To:References:Subject:Cc:To:From:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789183679; x=1789788479; darn=lists.xenproject.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ud1ZpqadGMe+QubhUEhtcVCLKFg2sCSQ6NPZYlf26Tg=; b=pXiWr7h0vEndbtPWgWyjDbr/bRZTfLpAbBFPzBneRDv4D4S0T6wYgJBpEKr0ZRDzth uCJ/4XN9/a6N+XSnMySXr8/0TpgDMgiLAM7hnEzg/JZYVofwb8fZZzxMBUEuB74C3Hr/ T4iwgSFp5iOuDVYe12NrENzmnIWDNAn6+ncmdkN4doQ2cxAljerJLlc+bXk8vF++o4CM 7sY3No0++eCYzp4h5Mlna3k2UnM9391BHqBHEGf6B8Rk4zSr+xUsttVBOMkbPSiKr28o wtlYyLsmAs1wA7De4Z8rnvL2H15cuPd8VQybawuYaiGojf5joh+KKlS3JBVV8c2cxv/P 5UqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789183679; x=1789788479; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ud1ZpqadGMe+QubhUEhtcVCLKFg2sCSQ6NPZYlf26Tg=; b=cE9NjRiuaoSnlurFam7dN37IsggKVAJz/51IZkRCwwiGM3d6Fh5HkR8fjeFSb5TPfm jsD01OYiSilbWCX05TQp95aavu4IdDtWvYCCfDXYFjkMVIGgVwckZo8mCniMxB9ai6cF HViPJaNnMXP32oxKLCayW87rQlOtf7gepNmgt6M3Rj2jSMLPDz43E+Ziyj5S8pYo6728 zIvftP4iOJ3dx8jBBWwMqoMq51DJO8Y+hxLTiZwcztkZaWuCCyhfae0ZHPPqdjs8Vzjl ksO3P8DUCymIfRdr3LyOTeS2O9ORAT8UmYLd6buuQMy75NAlZSYOVm7lR/Rk9gzLJAIf WYxQ== X-Forwarded-Encrypted: i=1; AKwUvBykwBUHJARxUbdvusYKSI8xNLPu/A21fKehKisPhUXDwyrJbB/84vuvIZVeJkeva3WxR5yu+9f4RXA=@lists.xenproject.org X-Gm-Message-State: AFuF++lsRvPPl639OBjycCvXerIBW5UoHYkiJNu52LHNJMKTECHON+ke 13tOo7srHWKOz/EWAvGR1aSxdd6Ta9DwbBuNjU57Am7mGULgCrAKENZS X-Gm-Gg: AYBFou0/aJPZib000p4PuPw+pmUwLAzGBZxvIZp8JH6VfzOWYI4Kq4rC7ZFzESseFNl 5Dp6AM0VwFU2SRc82HFS3OL8NiN0r+NSi4HRePpUB8ryWHL8MosT4XWexJsgWdZLkM6NJ+ikCZA 0xC2fEjeyQjFCvlf8tcCGhtewrG+ePwobNoaK1bAxnqONpM8Rpe05IA+sHn0OazOOTYnNthI0Rw Hlabf6ehZsRiBM8BrgM3Q9sjWHYag8YQEX0NkIvv0Xt75mDgUvPSi8cZkK8m2H9fRQxb5WFsi6N jcyyJPbtTtsA3lMye3Jw05xGFbVtomWu44MA7TokWfuaKOzgMOLV92U9U1uk0uVlRpnCyAUBFGW 5l0PAivt5x98QwqBSTwLhwi8376m+q8LA8/5TkhZi59OqeXFkOJ0R3QwIyGELhOtojBkZRcu/z2 rg7J4/8cxm8bkQfDQBuCYIaaQ6c6PuMuvkDcwLgrn3KevJ3Snrj7mDWw1/ni2gknGs8R7jezYey wR8XjrB+BR6FqG69v8iQVaFMH6RjRlnirNq9NNqcmiLn8J0P7gpoQpI6ZVb6ULNcg== X-Received: by 2002:a05:6830:2786:b0:7fa:ac4f:785 with SMTP id 46e09a7af769-80400b2042dmr6714669a34.17.1789183678934; Fri, 11 Sep 2026 20:27:58 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 11 Sep 2026 20:27:56 -0700 Message-Id: From: "Alexei Starovoitov" To: "Josef Bacik" , "Paul E. McKenney" , "Frederic Weisbecker" , "Neeraj Upadhyay" , "Joel Fernandes" , "Boqun Feng" , "Thomas Gleixner" , "Peter Zijlstra" , "Steven Rostedt" , "Masami Hiramatsu" , "Mark Rutland" , "Jiri Olsa" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , , "Catalin Marinas" , "Will Deacon" , "Puranjay Mohan" , "Xu Kuohai" Cc: "Andy Lutomirski" , "Josh Triplett" , "Uladzislau Rezki" , "Mathieu Desnoyers" , "Lai Jiangshan" , "Zqiang" , "Juergen Gross" , "Luis Chamberlain" , "Ihor Solodrai" , , , , , , Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline X-Mailer: aerc References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> X-purgate-ID: tlsNG-d25034/1789183680-51D34A5B-B273C263/0/0 X-purgate-type: clean X-purgate-size: 3041 On Fri Sep 11, 2026 at 7:08 AM PDT, Josef Bacik wrote: > Emit an increment of current->rcu_tramp_nesting once the trampoline's > frame is set up and a decrement before the final register restore, so > that a task preempted while running fentry/fexit/fmod_ret/LSM programs > or the __bpf_tramp_enter()/__bpf_tramp_exit() glue is not treated as > Tasks-RCU quiescent. Drop the count around the call to the original > function: that may run arbitrarily long without sleeping and must not pin > a Tasks RCU grace period, and the trampoline frame above it is held by > im->pcref rather than by Tasks RCU (see bpf_tramp_image_put()). The > fmod_ret early-exit branch and the ip_after_call -> ip_epilogue poke both > skip the decrement/increment pair around the original call, so the count > stays balanced on every path. > > The sequence is "mov r11, gs:[current_task]; inc/dec dword [r11 + off]"; > r11 is scratch at every emission point and (u32)¤t_task is a valid > sign-extended %gs-absolute with the current per-CPU layout, the same form > the JIT already uses for this_cpu_off. The image is dynamically > allocated text, so the instructions outside the bracketed region are > covered by the irq-exit IP check. > > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > arch/x86/net/bpf_jit_comp.c | 43 +++++++++++++++++++++++++++++++++++++++= ++++ > 1 file changed, 43 insertions(+) > > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c > index 2853e87797a7..a375c1b7bd50 100644 > --- a/arch/x86/net/bpf_jit_comp.c > +++ b/arch/x86/net/bpf_jit_comp.c > @@ -722,6 +722,31 @@ static void emit_indirect_jump(u8 **pprog, int bpf_r= eg, u8 *ip) > *pprog =3D prog; > } > =20 > +/* > + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). > + * > + * mov r11, QWORD PTR gs:[current_task] > + * inc/dec DWORD PTR [r11 + offsetof(struct task_struct, rcu_tramp_nes= ting)] > + * > + * r11 (AUX_REG) is scratch in the trampoline at every point this is emi= tted. > + */ > +static void emit_rcu_tasks_tramp_nesting(u8 **pprog, bool enter) > +{ > +#ifdef CONFIG_TASKS_RCU > + u8 *prog =3D *pprog; > + > + /* mov r11, gs:[abs32] */ > + EMIT2(0x65, 0x4C); > + EMIT3(0x8B, 0x1C, 0x25); > + EMIT((u32)(unsigned long)¤t_task, 4); > + /* inc/dec dword ptr [r11 + disp32] */ > + EMIT3(0x41, 0xFF, enter ? 0x83 : 0x8B); > + EMIT(offsetof(struct task_struct, rcu_tramp_nesting), 4); > + > + *pprog =3D prog; > +#endif It's not a lot of overhead, but I feel it will be the death by thousand cut= s. rcu_read_lock_trace() in bpf_prog_enter_sleepable is doing the same thing..= . increamenting a variable inside current. Can they be combined? Like treat current->trc_reader_nesting > 0 as current->rcu_tramp_nesting > 0 ? Or replace one with the other? Two current->foo++ operations look redundant. bpf trampoline is already quite heavy. I'd like to find ways to reduce its overhead instead of adding more. From xen-devel-bounces@lists.xenproject.org Sat Sep 12 05:11:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 05:11:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418164.1646456 (Exim 4.92) (envelope-from ) id 1x5G0k-0001ES-ID; Sat, 12 Sep 2026 05:10:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418164.1646456; Sat, 12 Sep 2026 05:10:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5G0k-0001EL-DW; Sat, 12 Sep 2026 05:10:46 +0000 Received: by outflank-mailman (input) for mailman id 1418164; Sat, 12 Sep 2026 05:10:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5G0i-0001EF-IE for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 05:10:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5G0h-007Sl3-VQ for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 07:10:43 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa4decc-8faa-0a2a0a5109dd-0a2a4508df9c-8 for ; Sat, 12 Sep 2026 07:10:43 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa4ded2-f659-0a2a45080019-ac6904fe934a-3 for ; Sat, 12 Sep 2026 07:10:43 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id A83AA600D4; Sat, 12 Sep 2026 05:10:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F2201F000FF; Sat, 12 Sep 2026 05:10:41 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id C2B99CE1580; Fri, 11 Sep 2026 22:10:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789189841; bh=b7gamaM3ocBB+4O2hg6ustnV02tbiSJQKUzLHib6YK0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=OEZphzm3wMMRqTwmUnagcM+KkWkkTEvAT3wcp93TZCJkN2dazyFetMFqVZVuf+zV7 drMfqy3/azCvyRO4GZwYRU62gKX9R/h4JnLkota4GImeWvztGmQ6gwzOEl9t+pkiVf BDyS7frnNnG5/bK6UOHkPheXHOc+Ms5TmGLMpESOjUDdK4nK60SgDxKyQ8zj52lyzc wcMR2QrQ2oOSEEYg/HXgIsIeY8gxve2Ade2bJEbOR4QQA4BcQ9oOAbXJ23ExBEaMJr fjuNwfEtxx9Jn4UMZiVSKI/wMEB0jAsmzu3W4RnVLmA/qTJBuYAwblXEdcX6uU/UsY 1IvqTxEnYzpUg== Date: Fri, 11 Sep 2026 22:10:40 -0700 From: "Paul E. McKenney" To: Alexei Starovoitov Cc: Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline Message-ID: <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-c1860d/1789189843-DFAD487B-DD0A2F66/0/0 X-purgate-type: clean X-purgate-size: 3449 On Fri, Sep 11, 2026 at 08:27:56PM -0700, Alexei Starovoitov wrote: > On Fri Sep 11, 2026 at 7:08 AM PDT, Josef Bacik wrote: > > Emit an increment of current->rcu_tramp_nesting once the trampoline's > > frame is set up and a decrement before the final register restore, so > > that a task preempted while running fentry/fexit/fmod_ret/LSM programs > > or the __bpf_tramp_enter()/__bpf_tramp_exit() glue is not treated as > > Tasks-RCU quiescent. Drop the count around the call to the original > > function: that may run arbitrarily long without sleeping and must not pin > > a Tasks RCU grace period, and the trampoline frame above it is held by > > im->pcref rather than by Tasks RCU (see bpf_tramp_image_put()). The > > fmod_ret early-exit branch and the ip_after_call -> ip_epilogue poke both > > skip the decrement/increment pair around the original call, so the count > > stays balanced on every path. > > > > The sequence is "mov r11, gs:[current_task]; inc/dec dword [r11 + off]"; > > r11 is scratch at every emission point and (u32)¤t_task is a valid > > sign-extended %gs-absolute with the current per-CPU layout, the same form > > the JIT already uses for this_cpu_off. The image is dynamically > > allocated text, so the instructions outside the bracketed region are > > covered by the irq-exit IP check. > > > > Assisted-by: LLM > > Signed-off-by: Josef Bacik > > --- > > arch/x86/net/bpf_jit_comp.c | 43 +++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 43 insertions(+) > > > > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c > > index 2853e87797a7..a375c1b7bd50 100644 > > --- a/arch/x86/net/bpf_jit_comp.c > > +++ b/arch/x86/net/bpf_jit_comp.c > > @@ -722,6 +722,31 @@ static void emit_indirect_jump(u8 **pprog, int bpf_reg, u8 *ip) > > *pprog = prog; > > } > > > > +/* > > + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). > > + * > > + * mov r11, QWORD PTR gs:[current_task] > > + * inc/dec DWORD PTR [r11 + offsetof(struct task_struct, rcu_tramp_nesting)] > > + * > > + * r11 (AUX_REG) is scratch in the trampoline at every point this is emitted. > > + */ > > +static void emit_rcu_tasks_tramp_nesting(u8 **pprog, bool enter) > > +{ > > +#ifdef CONFIG_TASKS_RCU > > + u8 *prog = *pprog; > > + > > + /* mov r11, gs:[abs32] */ > > + EMIT2(0x65, 0x4C); > > + EMIT3(0x8B, 0x1C, 0x25); > > + EMIT((u32)(unsigned long)¤t_task, 4); > > + /* inc/dec dword ptr [r11 + disp32] */ > > + EMIT3(0x41, 0xFF, enter ? 0x83 : 0x8B); > > + EMIT(offsetof(struct task_struct, rcu_tramp_nesting), 4); > > + > > + *pprog = prog; > > +#endif > > It's not a lot of overhead, but I feel it will be the death by thousand cuts. > rcu_read_lock_trace() in bpf_prog_enter_sleepable is doing the same thing... > increamenting a variable inside current. > Can they be combined? Like treat current->trc_reader_nesting > 0 as > current->rcu_tramp_nesting > 0 ? > Or replace one with the other? > Two current->foo++ operations look redundant. > > bpf trampoline is already quite heavy. I'd like to find ways to reduce > its overhead instead of adding more. Replace rcu_read_lock_trace() with Josef's rcu_tasks_trampoline_enter)? But if this means reverting the re-implementation of RCU Tasks Trace in terms of SRCU, I will be rather annoyed with myself. ;-) Thanx, Paul From xen-devel-bounces@lists.xenproject.org Sat Sep 12 08:49:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 08:49:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418292.1646465 (Exim 4.92) (envelope-from ) id 1x5JQN-0003z9-HK; Sat, 12 Sep 2026 08:49:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418292.1646465; Sat, 12 Sep 2026 08:49:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5JQN-0003z1-Cv; Sat, 12 Sep 2026 08:49:27 +0000 Received: by outflank-mailman (input) for mailman id 1418292; Sat, 12 Sep 2026 08:49:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5JQM-0003yv-5H for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 08:49:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5JQL-004L2T-FE for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 10:49:25 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa511eb-8faa-0a2a0a5109dd-0a2a4509d364-22 for ; Sat, 12 Sep 2026 10:49:25 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa51213-be1a-0a2a45090019-b9ff1c22a2cb-3 for ; Sat, 12 Sep 2026 10:49:24 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a094ce8ccb000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 12 Sep 2026 08:49:19 +0000 Received: from [192.168.1.46] (88-183-178-13.subs.proxad.net [88.183.178.13]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id C8C3581C9B; Sat, 12 Sep 2026 10:49:14 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=9ds9os1bCD8ftijN8a/IzEw6y6RSqfDObnnO6Ib1gzg=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Hew6zxYX2tI0AT5t8KCA5AzMRIl9tjbIjAvEHuQkgkV/ZGMHb9DxsWXdEYN1uc7Uj6kovi4hs wvOngk3YyCePN+xDpdzS6/sG/v0A5TSde4Hs7WGZ5bML//SMtPJOiHYOXfbgsvEuAh8D84kL52W RqObMTe7a3mSfodydFMgadPq5YDYfT1Jg3dFqlIWedEBRkfrlYObmdpxTivO/6teVMGaygix+S1 J93On+IEwTLCiiplJws98FblfbZWwOiZ6XVs7jXkqjlRQV+xV3nXy7MHTGZJFs6otD8lS9imtut rhk7ZsktmzC2snD/PFEt358IKzrXZRXd0qWNR2DESbQw== X-Zone-Loop: 23f04bb1aedf245a9df8f5ce3f5877ad2fc6eaee4665 x-campaign-type: default x-transaction-id: bb7b05b2-88f9-4ad1-9db6-bfbca1634416 x-swg-uid: 01-0203a3e2-e025-4893-a6c7-2687883c8a24 X-Mailer: Sweego Message-ID: <1789202959.8631fc262581453bbf619ec5b2062170.1a094ce8ccb000c4f3@vates.tech> x-swg-bid: 1789202959.8631fc262581453bbf619ec5b2062170.1a094ce8ccb000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH] Add basic b4 config file From: Baptiste Le Duc To: Andrew Cooper Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <89c7c026-3986-440a-b2d1-158eb5f0fbbe@citrix.com> References: <1789133309.8631fc262581453bbf619ec5b2062170.1a090a7c48d000c4f3@vates.tech> <89c7c026-3986-440a-b2d1-158eb5f0fbbe@citrix.com> Date: Sat, 12 Sep 2026 10:49:07 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789202947; l=2458; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ZYeDOhJpAcGq2IenvR4OpMIVcfyFogtM5bp2pwbw9ZQ=; b=CRrz4yyPdLuNkcuZooo5xpZJQGC53XsXqHaR8wWw54vkzr7vAF5rBK/HBmUA0H7B1OIZPMOEb SJ6C+q0LCoHBslUvxPspTRlgiSkcZf9pJoD/zVJU7T1gB5T2ziGBcgN X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789202958849 X-purgate-ID: tlsNG-bad1c0/1789202965-3A8D9034-7FE7CECF/0/0 X-purgate-type: clean X-purgate-size: 2462 On 2026-09-11 17:45:37+01:00, Andrew Cooper wrote: > On 11/09/2026 2:28 pm, Baptiste Le Duc wrote: > > > b4[1] is a convenient tool for mail-based contribution. A config file[2] > > tracked in the tree lets the project ship a few defaults that match the Xen > > patch submission rules. > > > > This aims to help new contributors who have never used a mailing list avoid > > mistakes when sending their patch series. > > > > The tree has no scripts/checkpatch.pl or equivalent, so there is nothing > > for b4 to run per patch. Disable the needs-checking pre-flight check so a > > series can be sent without first running b4 prep --check. > > > > [1] https://pypi.org/project/b4/ > > [2] https://b4.docs.kernel.org/en/latest/config.html > > > > Signed-off-by: Baptiste Le Duc > > I don't use b4 for preparing series myself, but I can see how this would > be useful for newcomers. > > > --- > > .b4-config | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/.b4-config b/.b4-config > > new file mode 100644 > > index 0000000000..1ca1f0625e > > --- /dev/null > > +++ b/.b4-config > > @@ -0,0 +1,13 @@ > > +# > > +# Common b4 settings for sending patches to the Xen Project upstream. > > +# https://b4.docs.kernel.org/ > > +# > > +# See docs/process/sending-patches.pandoc for the patch submission rules > > +# these settings implement. > > I doubt people will be reading this file to discover how to send > patches, and that piece of documentation is in the process of moving > into the handbook. > > I suggest dropping this sentence.  All that's going to happen to it is > becoming stale shortly. You're right, I'll drop it in v2, thanks. > > > +# > > + > > +[b4] > > + send-series-to = xen-devel@lists.xenproject.org > > + send-auto-to-cmd = echo > > + send-auto-cc-cmd = ./scripts/get_maintainer.pl --noroles --norolestats --nogit --nogit-fallback > > Where did this come from?   Because it didn't come from Xen's version of > get_maintainers, which is a long way removed from Linux's It came from QEMU. I double-checked, and indeed Xen's get_maintainer.pl doesn't support the negated form of these options, except for --nogit. However, --nogit is already part of the default options, so none of these flags are actually needed. I'd suggest: send-auto-cc-cmd = ./scripts/get_maintainer.pl What do you think? > > ~Andrew From xen-devel-bounces@lists.xenproject.org Sat Sep 12 09:20:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 09:20:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418305.1646473 (Exim 4.92) (envelope-from ) id 1x5JuA-00015p-Qb; Sat, 12 Sep 2026 09:20:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418305.1646473; Sat, 12 Sep 2026 09:20:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5JuA-00015i-NP; Sat, 12 Sep 2026 09:20:14 +0000 Received: by outflank-mailman (input) for mailman id 1418305; Sat, 12 Sep 2026 08:50:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5JRP-0005Pj-8L for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 08:50:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5JRO-00ASB2-LY for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 10:50:30 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa51240-e002-0a2a0a5209dd-0a2a4507c87c-20 for ; Sat, 12 Sep 2026 10:50:25 +0200 Received: from [74.125.227.140] (helo=mail-pj2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa51250-b4ea-0a2a45070019-4a7de38cfb6c-3 for ; Sat, 12 Sep 2026 10:50:25 +0200 Received: by mail-pj2-f12.google.com with SMTP id d9443c01a7336-2d8fb334ddcso7035685ad.0 for ; Sat, 12 Sep 2026 01:50:25 -0700 (PDT) Received: from fedora ([61.74.238.173]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2dd2ccaceafsm21924715ad.9.2026.09.12.01.50.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Sep 2026 01:50:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="In-Reply-To:Content-Disposition:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789203024; x=1789807824; darn=lists.xenproject.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=F06q9s994N2wdwEDu0iitxn9mZtTsmX3Vz77YooKqCM=; b=oBSomCXAyZIeeZmsDIkJd+3U+ivimm1iSt6LlVGg9LfSLBgJaACAiyxNUs6GAn6LWV ySRH5U3TXz3YBpLarXKF8JA8ZGJtOCPCvoKma3VZDFQoNyTud114gf4vHM/ilbQY/Kj6 bMShdpcJV4SsBRi3I0bsxx9KSjgabvGVQqM5T/zyt3o1DjPT0KrWY7nIhNIs1PnIx2Ks 8JkdC6f47LwYYpz+0qVSVmTVbwey9ywcekWHsp3NwUvXgiqoK39YOhKFYGBRWhjuVRoI 5hsbEqashAfjziBSdS2IKBSFTdJiCfP+WkR3geVRXr128/ymZGiVfIlgtRP+Wx+as2A8 pNqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789203024; x=1789807824; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=F06q9s994N2wdwEDu0iitxn9mZtTsmX3Vz77YooKqCM=; b=hWH8S+t39Lz0FI+6ZyR+B+VHtimV7cZIuudqkuLaqa2hosz1lNEyCVDAWidmgxTcqc XoRokGFByyImwCYhmhz5/BPbtSm8EeawuZJ1PfFxFLh3jzODSr+H10ZG+dDC7+h1hdDn zJTTNnCWigX3MIg3aGwoRv9fLcXxTmw/jDUxith5mtnTiMV5w1z61mfBpndYxCJyt3F5 4MGRy94yH/X9+E2vSnxTZ142b8x3brKyTBaoLexD8MS2dIGLteL5CELFcfHhz1ohrxpJ ATp1/7oMwn2iYy7bf8qj/DRC+YFSFtdwl82cWpeJUS8tcviXwsSf9QfTW864Aj0LA1bG twiQ== X-Forwarded-Encrypted: i=1; AKwUvBwRdepfvdwGNMBJGwJP4Bj36Os+vruoRI+AbntkBoWgJGvtbwBcOyRKsxoQnmdcwNhvOu8Lie0WwDQ=@lists.xenproject.org X-Gm-Message-State: AFuF++mt0MsMFBAVx5hQTQNnTHV2e+DlahLEnttY/0a+3xt2a29jf6io hfi60/hVPkWazojXLuqT36RJ5fYpZ3oBheuSbD3lo/c6KS99lBwXBm2N X-Gm-Gg: AYBFou2QTXfSMQRVCofJnsATw7aqrC6V36ZzrzoIEu3+XDdHhlkBmAE2ikjx8/P8ERN lxnUoBFOc/4rP7FQF33RTR0oTryQTUQ1PU2OMhH8j0X0D0oks6mw2vCFrdB9NVSfsq/j8GZUCAj Coj1nmT+RBgY4mS/HcMNa4Yb94OCwl7PBi9/ZCXvWVEDdnpmxvvN2zkn4aL+GOga9rdoMS4/YdP vJuumv6PxFCXEDI1vG3vmAVJ3lKybI0MuaPWMAuybr34sU0FQCwh46Qa6MqJargJxaa3NKepzTt coGObS7x6uUiO4uWVLrnEzhx8RRW2WDlwpApGPvMhDTjFfOUK98Aqpf4+gX2m6cJtqy3/pwIOhw 71vh0Yw66gD3/WZYqgbazHFv+tmz7TI9DP6yilsXB6TzyZN/X7nGnVu0ynvWNxOMR6kjZF+oaL9 8tX99X5KHcmrsAN+vCXQRdDmRIIHF+6Lqr8RQolxpdNjlujRsLSpc9cWKu8G4ysmLeVEkzjSEAL yNojpcFSHhKazCIdU0PRdY= X-Received: by 2002:a17:902:f60d:b0:2db:5c0a:f184 with SMTP id d9443c01a7336-2dd2a34fd91mr152629015ad.17.1789203023740; Sat, 12 Sep 2026 01:50:23 -0700 (PDT) Date: Sat, 12 Sep 2026 17:50:18 +0900 From: SeungJu Cheon To: Oleksii Kurochko Cc: Jan Beulich , Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation Message-ID: References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> <68ab5241-7301-4988-9420-bcccc4b16e3d@suse.com> <071ed630-4c72-4df1-b15e-3037e3f076ba@gmail.com> <48857983-ac79-44a0-8a11-93f62ac3d0c4@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-ef75cf/1789203025-A74D3AE4-AB735BDF/0/0 X-purgate-type: clean X-purgate-size: 2133 On Thu, Sep 10, 2026 at 04:24:06PM +0200, Oleksii Kurochko wrote: [...] > In v3 I'll (a) stop using ->processor and take the (guest_file_id, > vsfile_cpu) pair, which imsic_update_state() updates atomically under > vsfile_lock, and (b) do the snapshot plus the h/w TARGET write under > aplic.lock, which aplic_reconfigure_target() also holds. As > imsic_update_state() completes before aplic_reconfigure_target() (also that > could be checked in this patch series and is introduced a little bit later. > Probably I have to re-order some patches again) takes the lock, the emulated > write either happens before the scan (and gets fixed up, or skipped as > already correct) or after it (and sees the new location). > > Any better option I have now? Unless I am missing something, the snapshot also needs to handle the case where the target vCPU has not been attached yet: vcpu_guest_file_id() returns zero until the vCPU has gone through imsic_vsfile_attach(), i.e. until it is scheduled for the first time, and vsfile_cpu is NR_CPUS until then. With the current code, a write targeting such a vCPU makes aplic_msi_target_gen() program Guest Index 0 into the physical APLIC target register. According to AIA section 4.5.16, Guest Index 0 selects the hart's supervisor-level interrupt file rather than a VS-level guest interrupt file. Could this cause the MSI to be delivered to Xen's own interrupt file with the EIID supplied by the guest? I also could not find where such a target would be updated once the VS-file is attached. imsic_migrate_vcpu() reprograms the relevant targets during migration, but the initial imsic_vsfile_attach() path does not appear to replay targets which were written before the attachment. Whether a write targeting an unattached vCPU should be supported seems like a separate question. Independently of that choice, would it make sense to avoid programming the physical TARGET register while guest_file_id is zero? The virtual target could either be rejected, or retained in the shadow target[] and programmed once the VS-file is attached. Thanks, SeungJu From xen-devel-bounces@lists.xenproject.org Sat Sep 12 12:51:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 12:51:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418603.1646483 (Exim 4.92) (envelope-from ) id 1x5NCS-0003QG-7Q; Sat, 12 Sep 2026 12:51:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418603.1646483; Sat, 12 Sep 2026 12:51:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5NCS-0003Q5-2W; Sat, 12 Sep 2026 12:51:20 +0000 Received: by outflank-mailman (input) for mailman id 1418603; Sat, 12 Sep 2026 12:51:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5NCO-0003Pi-Ke for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 12:51:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5NCO-00GUhv-1B; Sat, 12 Sep 2026 14:51:16 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa54a4b-2eae-0a2a0a5409dd-0a2a450ccb3a-48 for ; Sat, 12 Sep 2026 14:51:15 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa54ac3-f479-0a2a450c0019-5a9b3222e484-3 for ; Sat, 12 Sep 2026 14:51:15 +0200 Received: from [2001:8b0:10b:5:eadd:dca:351e:8456] (helo=u09cd745991455d.ant.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1x5NCM-000000020dA-1InE; Sat, 12 Sep 2026 12:51:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=1S4O0RLN5mIgX9llnu22Aqr0Bzw08Y9yuLVCpUxSuII=; b=GGdp/4Uo3gx8Hm1G4IKv9SzGoA a9qLUYE6lqwB9FTW+uIe7LPmG0TQIH0WfzdUKZvDJjgdOq0rh8Lahw7E1yE/+ZMiwt15jPxrLHFI9 cVYRmGf7dNfqQSOs45XHpGasaCJtH8E5RoNBTzayvG0C9hUef8fNdCf+R8giSh01Eon/hmvhO7YL/ uJ+1QyH3KFrc5bA3C6XX2tm7/nxnEGofTKKAbidQ9Q2TUryajej8dLoG008riSizIzu5rL04BrjtH uFMNX+nGepUPNNKIezj9+m9uwyYQMJI54XLLioxfyJi0wBNB6I+dtKK+B82RW5CKP6IEIn5AwNGEI 56XbXoAA==; Message-ID: Subject: Re: [BUG] hw/xen: features published after InitWait since 240cc11369fc From: David Woodhouse To: mark.syms@citrix.com Cc: qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org, anthony@xenproject.org, paul@xen.org, edgar.iglesias@gmail.com Date: Sat, 12 Sep 2026 13:50:44 +0100 In-Reply-To: References: <30ec634b6072ac23c38a6a05bf3f90de4b383632.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-Yz2BDv1PND8iEoResLEq" User-Agent: Evolution 3.62.0-0ubuntu1~ppa1~24.04 MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-purgate-ID: tlsNG-d25034/1789217475-012C8A5B-0DE7A657/0/0 X-purgate-type: clean X-purgate-size: 10395 --=-Yz2BDv1PND8iEoResLEq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2026-09-11 at 15:34 +0100, David Woodhouse wrote: > On Fri, 2026-09-11 at 13:31 +0100, David Woodhouse wrote: > >=20 > > =C2=A0- While testing hot-plug of xen-net-device we hit an unrelated, > > =C2=A0=C2=A0 pre-existing heap corruption ("double free or corruption (= !prev)") > > =C2=A0=C2=A0 on qemu exit after hot-plugging a xen-net-device, present = on > > =C2=A0=C2=A0 current master both with and without the fix. It looks lik= e the > > =C2=A0=C2=A0 same class of exit-notifier-vs-net_cleanup() teardown orde= ring > > =C2=A0=C2=A0 issue as commit 9000666052 ("xen-block: fix segv on unreal= ize") > > =C2=A0=C2=A0 was for xen-block. That will be chased separately. >=20 > It has a fix for that too now, FWIW, but I don't have the bandwidth > right now to reimplement it with meat fingers so I might just file the > bug instead. Having now found the bandwidth to at least *look* at its fix, it had added a 'cleanup_done' guard in qemu_cleanup_net_client() but I didn't like that very much. I think the better answer is for ->cleanup() to be idempotent much like a gobject's dispose() would be. I made it go audit them all and find the ones which aren't. Obviously slirp was the first, and it can set s->slirp=3DNULL on cleanup to avoid freeing it again (I made it add a couple of NULL checks in other places, but those would have been a use-after-free in the current code anyway). Then vde, ll2tpv3 and passt also need similar fixes. I'm looking at a nice simple table of other things to check on for each backend, but I can't show that here so I won't. --=-Yz2BDv1PND8iEoResLEq Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE8Ew ggWvMIIEl6ADAgECAhANkOKMSmGXhF5eMl0rsRhvMA0GCSqGSIb3DQEBDAUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0yNDAzMTMwMDAwMDBaFw0zNDAz MTIyMzU5NTlaMGIxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UE AxMxRGlnaUNlcnQgQXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOfSIeC0vv1xPQ+dgSxbIIrkaru6skAWJYaGFzmv q4Kq+2wU2jxhcWlJg/JeP5jEkq/LM3pn5aaLao79j+XRmS7J1ZpJKUODJVoM4s9MQJhTMvo4qS5Z S64g6QR7Obkz3I1Lr3aWeSBmDDEyzue+NKtuWZ1Cxy3RdXo/w5HgRc3l2AercOM3Gt1XonTzEtTb Z/Hwc0Sn9Gz8RmGRK6Ka4hVDl8q/2l110KaV233Kh5etP0csXS8MIMdVRfRu3sc5hp13DG7lCKzK 72a2GEpI8Wpl26G6I1/LMzz/98T+FqjTqxsdquk7Cj7m2vKGLW1BorpQH7WFGPdJQXJe1hfbfiZA CcVdCtl4nAacFacmsiArZBfX7AQGL7isvHUwwYFEtcApyGW4p2Lt+t8nvU0CANA6BHOpOz1xOP8W mAESbUriIjyuTUf3fJ9oDNCurVqhASMJCDaWI3lYX/QAoiAzt6akqbbZxo2ujW7mGGqc0KxqE2cs h2T79v7pC8aUtHBfwNrTR19GnZVxE0eQ7ViIQhR6mpSaUQFA9sG+cmD2G8TnCgYsLa0q8De6F61a CBevQGHNzrbZ3JAMneveYg/Jy1XxQHDRcvrMfWKe0jjcWbdKYlaGVPm5V1ILwYz7Yv5ewo3NUrxI GJiywe9qPhuJSDZs7VehTuI0FxGIsgKzVjgbAgMBAAGjggFcMIIBWDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBT3m6JO05fF9DQPQw6Bhc6RkzKv+TAfBgNVHSMEGDAWgBTOw0q5mVXyuNtg v6l+vVa1lzan1jAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMG CCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290RzIuY3J0MEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEBDAUA A4IBAQA+b8Uw53sDspdZgukU+qzLyyHkcjlxGGhHlP+zrmDLKm1wEFvCRS2pili3Hy67i8N4N5NU vw5Rg6kv3lxb9S9Rktxk43k+tvm68pl7OxQE55ZjVY87P0lUPGwEqOOwLLyH02ZQcsfq5p5LrOH9 0JvmvZ1yy73HS+VpDAqOlytE0NSvTIRqFFkKQGQwfjvtql9YflujuNNvJztjBaHKYZsnNSg+J38o jYq4TP3pSg3UdVH0PncVjPQyqxC9xef5Xae92Kbkzol3x7Nel3A1bwAkalrDMspvTHvey6LfiBks FIqviTnoy7fgjaRAJgHS+RXx/cmuRd3rUAclSVVrYu8RMIIHAzCCBOugAwIBAgIQAzUotrsybJHx HTjKOIVdIDANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQs IEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQg MjAyNCBDQTEwHhcNMjYwNzE4MDAwMDAwWhcNMjgwMTA0MjM1OTU5WjAeMRwwGgYDVQQDDBNkd213 MkBpbmZyYWRlYWQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2pYux73kdbYX sWF8f1u6DJP91qcqaZetsyfPkZk0B+MmXmAEv0kVes5n15V2mbDThOnpoPFly0UugQO9JYqLfrtD tKD5yL58fgrDB9Dw+LQikgrHafl6YSCds5AvUu/8hw2J6noKrcOLJpKlKn9Fl/4IB9Q3JIdLx5aa EtTqMalIPqHFOlgrJ7s+aua8xbB8YQ9ahqYBXWRJNv3P/2b1DYtdrz1oqZPE3CcB8Pc6Gf2a1Tcm 6TAgtEx7Cf1BFcrsrMz7TWHmGQITieNb2r9UYWSc2Gp+GtYFNJCgT0JJXKUBIauPMKBLteYrL8Fo ff/uY44dC/mDWjdCP/5x0qelPQjlBvWdHL5zvBTOj06rJ0m3HNI/hnIcDh0Qu2j9reb9rLVcdym6 bWmBM4uDEB8Zv9Ph0KTBFSy1IosyakuD1j1Os30EzjGfbi0EUXIvnOcYbTBAbM5UAzrxEHMhBvoX Pvnx+OyvjJmc9tWxTX6AcSz+m40esbT17URBeZS18afgieiikm5TynlUYP1LciR3hSgGVzvGXnKO 02VDFR5itGWdRKZ2W5wIShNfWfhSa0D0K5UdIDt5Qc7sjzwK1Yb1sY5Tu0uA5mhIS82q1ov83uxB sFkriNnhGv/M1NCDVLBiOMsHu73qUM+yKmgKLwF9Hfn9WI25glbAMI4S5r3hYzcCAwEAAaOCAfcw ggHzMB8GA1UdIwQYMBaAFPebok7Tl8X0NA9DDoGFzpGTMq/5MB0GA1UdDgQWBBRcYhqbcGzn1jrT JOZaB8O7qllDpzAwBgNVHREEKTAngRNkd213MkBpbmZyYWRlYWQub3JngRBkYXZpZEB3b29kaG91 LnNlMBQGA1UdIAQNMAswCQYHZ4EMAQUBAjAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIGpBgNVHR8EgaEwgZ4wTaBLoEmGR2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsME2gS6BJ hkdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZT SEEzODQyMDI0Q0ExLmNybDCBjQYIKwYBBQUHAQEEgYAwfjAkBggrBgEFBQcwAYYYaHR0cDovL29j c3AuZGlnaWNlcnQuY29tMFYGCCsGAQUFBzAChkpodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkRzJTTUlNRVJTQTQwOTZTSEEzODQyMDI0Q0ExLmNydDANBgkqhkiG9w0B AQsFAAOCAgEAocabrh1cPd5s3vY5rnlBVQSTc7zs2ZWs67dAIltR+05WELrYClVzzUhMs/LOJPlr EUo45UDDomXq38DxFepaPd9+iNLjXfn33EX/IG44j04lU/oF/Rg9VeQILkYLbCZ/x9wOjNHZc4SN ydY7Dhvf/sT5aBz88u7D5+azZJ7Qf1U57wYseCH1Mt0nDrtr5y19IJ8D9xJJ33RFL6vfpHZBBAQ8 +3RqkKNxLoV2aFvQhxdhjNLDqTv3LjUIdicwPraN7JkxEu7CV2Lka7eRqJgkWL7SK0YmBjGpRafs +icP/ON5RCCKTTb6VlX8eTG2sJJfsFhvJNCCt6xexbWzWtIrfP7NvPBvwBB737AyEGBZkS5aNizT McURJGTv9UKvBh1LF/+tNhYtLvPCN7oecGzhCHht9jcwSkygTo3Y6YlK3QgOu+ncmiBbfeuwlLZ1 LxbYvG6hgNqXv7u6YyADbYajAQJXJ2OQen39pm3Q/AQSyLYG+B8lDglWsM8tYXPlEdrYJcksGK6F nqIX6Bumn43rBooLJdiZp4WmfWdL2pxe+LxRDjprmqu1WprixDxULSTOKJZoqTlugs6y3Bc+if+s gHnBBtz9WQ6MtPHkh7zONDAFIKcBmv8OqPQCx0F3Wv3OEybwMpXx0OsKgK8wLldaX1pXcMuyDgTL Sqs0AV0OHUgwggcDMIIE66ADAgECAhADNSi2uzJskfEdOMo4hV0gMA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE6MDgGA1UEAxMxRGlnaUNlcnQg QXNzdXJlZCBHMiBTTUlNRSBSU0E0MDk2IFNIQTM4NCAyMDI0IENBMTAeFw0yNjA3MTgwMDAwMDBa Fw0yODAxMDQyMzU5NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZe YAS/SRV6zmfXlXaZsNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2z kC9S7/yHDYnqegqtw4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qG pgFdZEk2/c//ZvUNi12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41va v1RhZJzYan4a1gU0kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0c vnO8FM6PTqsnSbcc0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PW PU6zfQTOMZ9uLQRRci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXt REF5lLXxp+CJ6KKSblPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQr lR0gO3lBzuyPPArVhvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7Iq aAovAX0d+f1YjbmCVsAwjhLmveFjNwIDAQABo4IB9zCCAfMwHwYDVR0jBBgwFoAU95uiTtOXxfQ0 D0MOgYXOkZMyr/kwHQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3 bXcyQGluZnJhZGVhZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEC MA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgakGA1UdHwSB oTCBnjBNoEugSYZHaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZEcyU01J TUVSU0E0MDk2U0hBMzg0MjAyNENBMS5jcmwwTaBLoEmGR2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv bS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNBNDA5NlNIQTM4NDIwMjRDQTEuY3JsMIGNBggrBgEF BQcBAQSBgDB+MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wVgYIKwYBBQUH MAKGSmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRHMlNNSU1FUlNB NDA5NlNIQTM4NDIwMjRDQTEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQChxpuuHVw93mze9jmueUFV BJNzvOzZlazrt0AiW1H7TlYQutgKVXPNSEyz8s4k+WsRSjjlQMOiZerfwPEV6lo9336I0uNd+ffc Rf8gbjiPTiVT+gX9GD1V5AguRgtsJn/H3A6M0dlzhI3J1jsOG9/+xPloHPzy7sPn5rNkntB/VTnv Bix4IfUy3ScOu2vnLX0gnwP3EknfdEUvq9+kdkEEBDz7dGqQo3EuhXZoW9CHF2GM0sOpO/cuNQh2 JzA+to3smTES7sJXYuRrt5GomCRYvtIrRiYGMalFp+z6Jw/843lEIIpNNvpWVfx5Mbawkl+wWG8k 0IK3rF7FtbNa0it8/s288G/AEHvfsDIQYFmRLlo2LNMxxREkZO/1Qq8GHUsX/602Fi0u88I3uh5w bOEIeG32NzBKTKBOjdjpiUrdCA676dyaIFt967CUtnUvFti8bqGA2pe/u7pjIANthqMBAlcnY5B6 ff2mbdD8BBLItgb4HyUOCVawzy1hc+UR2tglySwYroWeohfoG6afjesGigsl2JmnhaZ9Z0vanF74 vFEOOmuaq7VamuLEPFQtJM4olmipOW6CzrLcFz6J/6yAecEG3P1ZDoy08eSHvM40MAUgpwGa/w6o 9ALHQXda/c4TJvAylfHQ6wqArzAuV1pfWldwy7IOBMtKqzQBXQ4dSDGCBCAwggQcAgEBMHYwYjEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lDZXJ0LCBJbmMuMTowOAYDVQQDEzFEaWdpQ2VydCBB c3N1cmVkIEcyIFNNSU1FIFJTQTQwOTYgU0hBMzg0IDIwMjQgQ0ExAhADNSi2uzJskfEdOMo4hV0g MA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0yNjA5MTIxMjUwNDRaMC8GCSqGSIb3DQEJBDEiBCBXUXNvgqqT3FUJLYBJz4zCYumysVl9 5ypRDNhfncZWmzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGln aUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFzc3VyZWQgRzIgU01JTUUgUlNBNDA5NiBT SEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xOjA4BgNVBAMTMURpZ2lDZXJ0IEFz c3VyZWQgRzIgU01JTUUgUlNBNDA5NiBTSEEzODQgMjAyNCBDQTECEAM1KLa7MmyR8R04yjiFXSAw DQYJKoZIhvcNAQEBBQAEggIApDQF7dT2CVgrZycGQkt+AsIG8MfD+DWgLQodmq3Jhe/gB3LCQXYV c0983cXzCaTxoTXulrnpbX5gy8CPlbLUEF/DpE+UAeZh22E+uyurZELHfWx1Q6Xc02+PVmvzW/Z0 j2bzl+pQMCMK0uEo8ZrmmmoJARx+h/trRqXlYmVWw/0x4YZCrhXJzzrwO5zEcoxBekGEDx6C6NeD 6u25wmGK8RjKedyKuv5OjdAs+NQMbDMwwZGhbrXv9FqQfABeTyCfeU7aGMQsREyBqxJZndfSq21j XOkSigMXOmcpDnJ3o3VtqVgXmm6K50z5mzbcnMvqMDSzzKY4Q+jdcSjwvJCu2XxkVVVHyH3PyjIK n7i3BGZXry3fhBQ39bh7iumLnHZQgSGvfKswGklend9LZ6/QWR/QrzvdPdNLjWHnvmgy0jH9Qhqh 5eqmMvfJ2QjHrxOrZ4nfVjrawE5cw+GU4rA4wlen1yBpmg+kXhOcgXmGtUoIca8J/UmKok+4A68g WUETClygmxIXMlDCUJ4Hg3Sbk8ErgSz9csrDxrQpldo4kpD/6QingBVMS5zFHZLOOcxLOVmNvfBL 9yB1eNc+ZOg/Dq78fLhmR80DHyA2SspvC3ULE7oLCCetrfwUyReskwka6DHTDZafLdojmTyGCM+t zekqwKN4l+iCUcad9NsU0voAAAAAAAA= --=-Yz2BDv1PND8iEoResLEq-- From xen-devel-bounces@lists.xenproject.org Sat Sep 12 13:44:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 13:44:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418615.1646492 (Exim 4.92) (envelope-from ) id 1x5O26-0003Oq-35; Sat, 12 Sep 2026 13:44:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418615.1646492; Sat, 12 Sep 2026 13:44: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 1x5O25-0003Oj-Vo; Sat, 12 Sep 2026 13:44:41 +0000 Received: by outflank-mailman (input) for mailman id 1418615; Sat, 12 Sep 2026 12:56:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5NHf-000466-Vi for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 12:56:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5NHf-00BgYO-5K for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 14:56:43 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa54c0a-8faa-0a2a0a5109dd-0a2a450ced64-2 for ; Sat, 12 Sep 2026 14:56:43 +0200 Received: from [185.70.43.16] (helo=mail-4316.protonmail.ch) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa54c0a-f479-0a2a450c0019-b9462b10c2b7-3 for ; Sat, 12 Sep 2026 14:56:42 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=protonmail3 header.d=protonmail.com header.i="@protonmail.com" header.h="Date:To:From:Subject:Message-ID:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1789217802; x=1789477002; bh=D4OWyTsDVzo2NGC3lKqpcDybE2xK9tUo2nmC2bhQb5Y=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=Gh3zjDhxy2nGqPZqRwS/mumwEnHguLf4zp5FjVf9p/qj/iNG50bcolMJirbKRo6aG cChgtN7w+TiFmnamliO6CnLk5V8RYQ/5vDkE4vC5lo5XI+vsKhqNDM2TfJzJsUFk/j Q0+/D8L5N51IfjmcaKy+1bo7j03fcrOGDZX9k6b5rqTpDNhiyJuuOdOWIs02QC1zQD LniDKTP49YpO7r6U8buMVuRb3ZDUkoPXaN7rIZ8kuZz43u9T5vw5CyxfbGwS99uz85 Edgo3eu5t4t4KsEFpnJOvTp1URMEbIP0oZdH8GhkoKH+yOWooNEFr9mRsKQK40D1ZD 5D2xROnOEh8dw== Date: Sat, 12 Sep 2026 12:56:38 +0000 To: "xen-devel@lists.xenproject.org" From: "Mr. Hoorn" Subject: [BUG] Intel Alder Lake guest PMU unusable because Xen vPMU rejects IA32_PERF_GLOBAL_CTRL bit 48 Message-ID: Feedback-ID: 94398300:user:proton X-Pm-Message-ID: e2c7ef42a9edbca65ad07d0df776abe06d49d547 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------44d65609ae32a4bf0b95bb7897e1da438361b4c395c64a0eb5ba6a5b45c9b2b9"; charset=utf-8 X-purgate-ID: tlsNG-d25034/1789217803-51D34A5B-0CA906C7/0/0 X-purgate-type: clean X-purgate-size: 11412 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------44d65609ae32a4bf0b95bb7897e1da438361b4c395c64a0eb5ba6a5b45c9b2b9 Content-Type: multipart/mixed;boundary=---------------------5da0b490f0369cef87e96a53d2e851bb -----------------------5da0b490f0369cef87e96a53d2e851bb Content-Type: multipart/alternative;boundary=---------------------0815f646da1876f4f0ce62e76cb8df06 -----------------------0815f646da1876f4f0ce62e76cb8df06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi, I have isolated what appears to be an incompatibility between Xen's Intel = vPMU implementation and Linux's Alder Lake hybrid PMU initialization. Host: Qubes OS Xen 4.17.5 vpmu=3D1 /sys/hypervisor/pmu/pmu_mode =3D self /sys/hypervisor/pmu/pmu_features =3D 0x0 Guest: PVH Fedora 43 Linux 7.0.11 (also reproduced with 6.12) Alder Lake hybrid PMU detected With an unmodified kernel, Linux reports: Performance Events: Alderlake Hybrid events, Intel PMU driver. but then faults while enabling the P-core PMU: unchecked MSR access error: WRMSR to 0x38f tried to write 0x000100070000003f __intel_pmu_enable_all 0x38f is IA32_PERF_GLOBAL_CTRL. The failing value contains bit 48 (GLOBAL_= CTRL_EN_PERF_METRICS). On Alder Lake, Linux explicitly enables this for the hybrid_big PMU in arc= h/x86/events/intel/core.c: } else if (pmu->pmu_type & hybrid_big) { =C2=A0 =C2=A0 pmu->intel_cap.perf_metrics =3D 1; Xen 4.17's Intel vPMU appears not to include bit 48 in the accepted global= control mask and consequently rejects the MSR write. The practical result is that ordinary hardware counters are also unusable.= For example, perf stat reported zero cycles/instructions. As a diagnostic workaround I built Linux 7.0.11 with only: pmu->intel_cap.perf_metrics =3D 1; changed to: pmu->intel_cap.perf_metrics =3D 0; After booting that kernel, the WRMSR fault disappears completely and ordin= ary PMU counters immediately work: 12,228,346,996 =C2=A0cpu_core/cycles/ 27,471,544,939 =C2=A0cpu_core/instructions/ A repeated run produced approximately the same instruction count and sensi= ble cycle counts. So the issue appears causal: Linux enables Alder Lake P-core PERF_METRICS = through IA32_PERF_GLOBAL_CTRL[48], Xen rejects that bit, and PMU initializ= ation is effectively broken as a consequence. I have not yet tested current xen.git, so this may already have been addre= ssed after 4.17. Is bit 48 / Intel PERF_METRICS supported by the current v= PMU implementation? If not, I think Xen should either virtualize it or exp= ose PMU capabilities such that the guest does not attempt to enable it. I can provide further traces or test a Xen patch if useful. Fine regards, Met vriendelijke groeten,Matthew David van der Hoorn LinkedIn Sent with Proton Mail secure email. -----------------------0815f646da1876f4f0ce62e76cb8df06 Content-Type: multipart/related;boundary=---------------------62923c56b07a9ca5937ce2978d44e15a -----------------------62923c56b07a9ca5937ce2978d44e15a Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij48c3Bhbj5IaSw8L3NwYW4+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5JIGhhdmUgaXNv bGF0ZWQgd2hhdCBhcHBlYXJzIHRvIGJlIGFuIGluY29tcGF0aWJpbGl0eSBiZXR3ZWVuIFhlbidz IEludGVsIHZQTVUgaW1wbGVtZW50YXRpb24gYW5kIExpbnV4J3MgQWxkZXIgTGFrZSBoeWJyaWQg UE1VIGluaXRpYWxpemF0aW9uLjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFu Pkhvc3Q6PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+UXViZXMgT1M8L3Nw YW4+PC9kaXY+PGRpdj48c3Bhbj5YZW4gNC4xNy41PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+dnBt dT0xPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+L3N5cy9oeXBlcnZpc29yL3BtdS9wbXVfbW9kZSA9 IHNlbGY8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4vc3lzL2h5cGVydmlzb3IvcG11L3BtdV9mZWF0 dXJlcyA9IDB4MDwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkd1ZXN0Ojwv c3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPlBWSDwvc3Bhbj48L2Rpdj48ZGl2 PjxzcGFuPkZlZG9yYSA0Mzwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkxpbnV4IDcuMC4xMSAoYWxz byByZXByb2R1Y2VkIHdpdGggNi4xMik8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5BbGRlciBMYWtl IGh5YnJpZCBQTVUgZGV0ZWN0ZWQ8L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bh bj5XaXRoIGFuIHVubW9kaWZpZWQga2VybmVsLCBMaW51eCByZXBvcnRzOjwvc3Bhbj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPlBlcmZvcm1hbmNlIEV2ZW50czogQWxkZXJsYWtlIEh5 YnJpZCBldmVudHMsIEludGVsIFBNVSBkcml2ZXIuPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PHNwYW4+YnV0IHRoZW4gZmF1bHRzIHdoaWxlIGVuYWJsaW5nIHRoZSBQLWNvcmUgUE1V Ojwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPnVuY2hlY2tlZCBNU1IgYWNj ZXNzIGVycm9yOiBXUk1TUiB0byAweDM4Zjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPnRyaWVkIHRv IHdyaXRlIDB4MDAwMTAwMDcwMDAwMDAzZjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPl9faW50ZWxf cG11X2VuYWJsZV9hbGw8L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj4weDM4 ZiBpcyBJQTMyX1BFUkZfR0xPQkFMX0NUUkwuIFRoZSBmYWlsaW5nIHZhbHVlIGNvbnRhaW5zIGJp dCA0OCAoR0xPQkFMX0NUUkxfRU5fUEVSRl9NRVRSSUNTKS48L3NwYW4+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48c3Bhbj5PbiBBbGRlciBMYWtlLCBMaW51eCBleHBsaWNpdGx5IGVuYWJsZXMg dGhpcyBmb3IgdGhlIGh5YnJpZF9iaWcgUE1VIGluIGFyY2gveDg2L2V2ZW50cy9pbnRlbC9jb3Jl LmM6PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+fSBlbHNlIGlmIChwbXUt Jmd0O3BtdV90eXBlICZhbXA7IGh5YnJpZF9iaWcpIHs8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4m bmJzcDsgJm5ic3A7IHBtdS0mZ3Q7aW50ZWxfY2FwLnBlcmZfbWV0cmljcyA9IDE7PC9zcGFuPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+WGVuIDQuMTcncyBJbnRlbCB2UE1VIGFwcGVh cnMgbm90IHRvIGluY2x1ZGUgYml0IDQ4IGluIHRoZSBhY2NlcHRlZCBnbG9iYWwgY29udHJvbCBt YXNrIGFuZCBjb25zZXF1ZW50bHkgcmVqZWN0cyB0aGUgTVNSIHdyaXRlLjwvc3Bhbj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPlRoZSBwcmFjdGljYWwgcmVzdWx0IGlzIHRoYXQgb3Jk aW5hcnkgaGFyZHdhcmUgY291bnRlcnMgYXJlIGFsc28gdW51c2FibGUuIEZvciBleGFtcGxlLCBw ZXJmIHN0YXQgcmVwb3J0ZWQgemVybyBjeWNsZXMvaW5zdHJ1Y3Rpb25zLjwvc3Bhbj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkFzIGEgZGlhZ25vc3RpYyB3b3JrYXJvdW5kIEkgYnVp bHQgTGludXggNy4wLjExIHdpdGggb25seTo8L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj48c3Bhbj5wbXUtJmd0O2ludGVsX2NhcC5wZXJmX21ldHJpY3MgPSAxOzwvc3Bhbj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPmNoYW5nZWQgdG86PC9zcGFuPjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PHNwYW4+cG11LSZndDtpbnRlbF9jYXAucGVyZl9tZXRyaWNzID0gMDs8L3Nw YW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5BZnRlciBib290aW5nIHRoYXQga2Vy bmVsLCB0aGUgV1JNU1IgZmF1bHQgZGlzYXBwZWFycyBjb21wbGV0ZWx5IGFuZCBvcmRpbmFyeSBQ TVUgY291bnRlcnMgaW1tZWRpYXRlbHkgd29yazo8L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj48c3Bhbj4xMiwyMjgsMzQ2LDk5NiAmbmJzcDtjcHVfY29yZS9jeWNsZXMvPC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+MjcsNDcxLDU0NCw5MzkgJm5ic3A7Y3B1X2NvcmUvaW5zdHJ1Y3Rpb25z Lzwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuPkEgcmVwZWF0ZWQgcnVuIHBy b2R1Y2VkIGFwcHJveGltYXRlbHkgdGhlIHNhbWUgaW5zdHJ1Y3Rpb24gY291bnQgYW5kIHNlbnNp YmxlIGN5Y2xlIGNvdW50cy48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5T byB0aGUgaXNzdWUgYXBwZWFycyBjYXVzYWw6IExpbnV4IGVuYWJsZXMgQWxkZXIgTGFrZSBQLWNv cmUgUEVSRl9NRVRSSUNTIHRocm91Z2ggSUEzMl9QRVJGX0dMT0JBTF9DVFJMWzQ4XSwgWGVuIHJl amVjdHMgdGhhdCBiaXQsIGFuZCBQTVUgaW5pdGlhbGl6YXRpb24gaXMgZWZmZWN0aXZlbHkgYnJv a2VuIGFzIGEgY29uc2VxdWVuY2UuPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNw YW4+SSBoYXZlIG5vdCB5ZXQgdGVzdGVkIGN1cnJlbnQgeGVuLmdpdCwgc28gdGhpcyBtYXkgYWxy ZWFkeSBoYXZlIGJlZW4gYWRkcmVzc2VkIGFmdGVyIDQuMTcuIElzIGJpdCA0OCAvIEludGVsIFBF UkZfTUVUUklDUyBzdXBwb3J0ZWQgYnkgdGhlIGN1cnJlbnQgdlBNVSBpbXBsZW1lbnRhdGlvbj8g SWYgbm90LCBJIHRoaW5rIFhlbiBzaG91bGQgZWl0aGVyIHZpcnR1YWxpemUgaXQgb3IgZXhwb3Nl IFBNVSBjYXBhYmlsaXRpZXMgc3VjaCB0aGF0IHRoZSBndWVzdCBkb2VzIG5vdCBhdHRlbXB0IHRv IGVuYWJsZSBpdC48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5JIGNhbiBw cm92aWRlIGZ1cnRoZXIgdHJhY2VzIG9yIHRlc3QgYSBYZW4gcGF0Y2ggaWYgdXNlZnVsLjwvc3Bh bj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj4KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IiBjbGFzcz0icHJvdG9ubWFpbF9zaWdu YXR1cmVfYmxvY2sgIj4KICAgIDxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2Nr LXVzZXIgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogc21hbGw7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7Ij5GaW5lIHJl Z2FyZHMsIE1ldCB2cmllbmRlbGlqa2UgZ3JvZXRlbiw8L3NwYW4+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogc21hbGw7IGNv bG9yOiByZ2IoMzQsIDM0LCAzNCk7Ij5NYXR0aGV3IERhdmlkIHZhbiBkZXIgSG9vcm48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiBzbWFsbDsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsiPjxicj48L2Rpdj48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiBzbWFsbDsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmxp bmtlZGluLmNvbS9pbi9tYXR0aGV3LXZhbi1kZXItaG9vcm4tYjg5ODc1MjE4LyIgdGFyZ2V0PSJf YmxhbmsiIHN0eWxlPSJjb2xvcjogcmdiKDE3LCA4NSwgMjA0KTsiPkxpbmtlZEluPC9hPjwvZGl2 PjwvZGl2PgogICAgCiAgICAgICAgICAgIDxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJl X2Jsb2NrLXByb3RvbiI+CiAgICAgICAgU2VudCB3aXRoIDxhIGhyZWY9Imh0dHBzOi8vcHJvdG9u Lm1lL21haWwvaG9tZSIgdGFyZ2V0PSJfYmxhbmsiPlByb3RvbiBNYWlsPC9hPiBzZWN1cmUgZW1h aWwuCiAgICA8L2Rpdj4KPC9kaXY+Cg== -----------------------62923c56b07a9ca5937ce2978d44e15a-- -----------------------0815f646da1876f4f0ce62e76cb8df06-- -----------------------5da0b490f0369cef87e96a53d2e851bb Content-Type: application/pgp-keys; filename="publickey - md.career@protonmail.com - 0x4FCD90CD.asc"; name="publickey - md.career@protonmail.com - 0x4FCD90CD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - md.career@protonmail.com - 0x4FCD90CD.asc"; name="publickey - md.career@protonmail.com - 0x4FCD90CD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWlhCYnRoWUpLd1lCQkFI YVJ3OEJBUWRBR2xoeUt2dDd6MTZMR05CL3JUOUpKMG10QjYzTks1S2sKWFhkWmFJcnN1bHpOTTIx a0xtTmhjbVZsY2tCd2NtOTBiMjV0WVdsc0xtTnZiU0E4YldRdVkyRnlaV1Z5ClFIQnliM1J2Ym0x aGFXd3VZMjl0UHNLTUJCQVdDZ0ErQllKbGNGdTJCQXNKQndnSmtObWdWd2xhRzdqbwpBeFVJQ2dR V0FBSUJBaGtCQXBzREFoNEJGaUVFVDgyUXpjTjFKMldCRlZHQTJhQlhDVm9idU9nQUFDNlQKQVA0 bjV5NSsySUZpakMzZDQwSTlwd2NYUCtnUVE5cXVaZk9PYktzRkFnTVV0QUVBelkrTXlQUGxHTVcy CmN4TGRJOEl4K0ZtWWtGN1Z5dzNzZ2J0Vy8yNzlpUVBPT0FSbGNGdTJFZ29yQmdFRUFaZFZBUVVC QVFkQQoreDhTVmlkdENRNGVBUWt3MzNXM2RBcUZjMGd1eDZDWElmdXQxWEZzYURnREFRZ0h3bmdF R0JZSUFDb0YKZ21Wd1c3WUprTm1nVndsYUc3am9BcHNNRmlFRVQ4MlF6Y04xSjJXQkZWR0EyYUJY Q1ZvYnVPZ0FBSDFICkFRQ0piMmhKcDVRQmZpczEvMHFzSXE1cWZyY3RWcXJHUk9XMGNBZHVkcDc2 eXdEL2RaWXF2M2doSmVpMgo1ZWQ4bzZNZlcybzhuMTlCTmJWQ1FyV1NwbXk5dGdjPQo9Y2ZXWAot LS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------5da0b490f0369cef87e96a53d2e851bb-- --------44d65609ae32a4bf0b95bb7897e1da438361b4c395c64a0eb5ba6a5b45c9b2b9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmqlS/gJENmgVwlaG7joRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmd6g0/58lezat8a4rDKQIsJpBW2Zfhmrv8pbWSi n6+fHBYhBE/NkM3DdSdlgRVRgNmgVwlaG7joAAB9tgD+KMv3UZSagrTI1/Ti PJk9fjvu4EHJgE3S7QyEL3323fcA/3hLn53Yvqhin3gP3phC60lzCswY87Nb NozhG41vEKsM =CaU5 -----END PGP SIGNATURE----- --------44d65609ae32a4bf0b95bb7897e1da438361b4c395c64a0eb5ba6a5b45c9b2b9-- From xen-devel-bounces@lists.xenproject.org Sat Sep 12 13:53:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 13:53:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418685.1646499 (Exim 4.92) (envelope-from ) id 1x5OAB-0005IO-Qg; Sat, 12 Sep 2026 13:53:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418685.1646499; Sat, 12 Sep 2026 13:53:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5OAB-0005IH-O3; Sat, 12 Sep 2026 13:53:03 +0000 Received: by outflank-mailman (input) for mailman id 1418685; Sat, 12 Sep 2026 13:53:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5OA9-0005IB-Ew for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 13:53:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5OA8-008IR2-PR for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 15:53:00 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa55936-8faa-0a2a0a5109dd-0a2a450bb168-2 for ; Sat, 12 Sep 2026 15:53:00 +0200 Received: from [40.93.194.52] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5593a-b7e8-0a2a450b0019-285dc2348a8a-3 for ; Sat, 12 Sep 2026 15:53:00 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW4PR03MB6364.namprd03.prod.outlook.com (2603:10b6:303:11f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.11; Sat, 12 Sep 2026 13:52:56 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Sat, 12 Sep 2026 13:52:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XV9QPt5j5FEGPaBRaUaPA5aLaVSHTf5wrdvXQ9MjjxJYpzqK3XwWlaipSluabtMKi9EepWwd5GPFsgLWGdUc6LiH0euLV9XGwigq6JVxHDrJRil0lu6iMyBHeZ7BG0uOqgUYL/nrItgkqKVXCNPCspX7pDz8r6+QDP9fQBCxXASzNMZRZceo096HmZ+FZjBHGadoKFcLN2HM4G8n/Ol/yNdIe+kcmW0IC3aFtyU9lqASBC2/mi+Z4B7oBdcoGs+CXT4yQUZ+jHRjh7HDJWc+lyoJAistdmxjn6tUC4ocMfearCJ2gT7QL2rN4/eouAYEZiPzVlEHguIukfAcnHBnGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NOKSh6BxD5VXXqyNqZg+SJpNEwAtvVAm8qKkETfBAuE=; b=YaGBh0NvGzeVjUazxOhWjc1v7Pm3Rokb0UKGdhPbqr3hx9/ZSuYTG5iGekIYJKY7YRlkjfTGKQd4Ng938L3CSWRhKsCtfxssMhgHjojbuY3Ex4Ej7hE33u01U/g4rCz6yW9UvXY2FEUTm1zW113G5VseN7YUBguF2+9Da3+pWFr3yI12HAiIjHO41shWHUFSWqiYEJBaHwzqKWJD1qCKKYBXU9j5cRaUqmvWJpVSUY8V7YE8VlfnQf7O8CNjtaLc9nD/uNRSvJAzt8zszZNRxuBJwXLHj6enfYDrE72cXogctiXeW22ti/g7Y4utJjr7cSSZlzBkcFPru+9xYz6tkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NOKSh6BxD5VXXqyNqZg+SJpNEwAtvVAm8qKkETfBAuE=; b=G6dIs/gjaNkd/xZX91eLUCZ9egxXfZQ8efw9ilLI1So5vtzC+d8LMLdkEnx015fRaH62mxk3NU0UqJjeB8cWbgpQ7D0ui2UBkJ8RF3rZIFdRkkHinXhK5Duc/DublMMAvOq5EK32W1cgtLqPcBm4lLwa8SXO23DKuHNmd3NdDUI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Sat, 12 Sep 2026 14:52:52 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper Subject: Re: [BUG] Intel Alder Lake guest PMU unusable because Xen vPMU rejects IA32_PERF_GLOBAL_CTRL bit 48 To: "Mr. Hoorn" , "xen-devel@lists.xenproject.org" References: Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PR1P264CA0044.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2cb::13) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MW4PR03MB6364:EE_ X-MS-Office365-Filtering-Correlation-Id: 8f2d5534-733e-4c85-3e7f-08df10d525ed X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|3023799007|6133799003|56012099006|11063799006|18002099003|22082099003|10067099003; X-Microsoft-Antispam-Message-Info: S5GkSaEGieQFdui8T3gnxHHgK/XTP7obrAtpPbsqrEtZ/Kf0F02kM876G6cYFkvQYhgbhrC+rQ3GaKBq48Mq1UXsvTGMVam/UsahVSzNk0e/Y4BO9Rn+XTR0Ksga6/LikT1A/daWOQq6NJFlri3NUh32aS3144r9MM6QycfRY0DjDbTTs3DyX1n9bqelUTnvFwVUA3Fl1vtVSeoWEL9/PgQMJIWYLMQJ7Vh4YEPEneNDNcktHhBBozif8Q3r8B3TsXxmpHQX6FTE9BD8RRPnSbGdmBTal08wGoxxmafxn1eZC7DC2fbVGfIv33d7lwyM1dl1JcIBiorVJ2b+eEr4gxzM8q4o1bat4qY9+ziKvx8yHWmw4cizvz1NUGARZKl18l/6qUA6mK3azcp9XwL/OitoP6xWni+O2lHOtt8PBnmnjC6drmFbWI7Yt8/f/LtZbSWDWY5r4Ga1WtajwF9DOWgtD3Jw5et7cmAbrSckfof0LSWJyvuy4HjJbuRdb55//PdYNwMdhw+qnlLvIhK6TshtnBcoGNE2C4EkmybZkVwsNLuDWMR/vlx4MnPi6eRVV8WEe7Q3z1OE8HOOsMCPHl/2QIocXiCNtoVdBjI2Ipw/Z4YbPA/ti7g/LiyMviYmDeh40I+K9Sg9xUMc0QF2vcciBLctqWU0r56pn6BNVjI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(3023799007)(6133799003)(56012099006)(11063799006)(18002099003)(22082099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M1QxMzd1c2gyb0RNNUo0K2l3N1JmTENGSzUzRlp3UlRCNWs2eWhBdnprS0xv?= =?utf-8?B?RlZrQnRuR1ZiSUMzSmsyUXo5dWhhU24weHZkMlcybUVDNGdjQ0JkenBkRU16?= =?utf-8?B?aHU1V3k4RC9tR3pwV3daY0ZaK1J5Z3hwd3ByTEovZVZlMDA5WmhkYTZOSmRi?= =?utf-8?B?eGVoU0NLM1M2bktOYTVqbGk2ZlJZTDN2amZmSWhtU1FlQlkzSzBVSVZydTRv?= =?utf-8?B?VlhtOUpULy9La1k4YktRd2VwejhPRUNsNkxNWVgreWFwRHVmdVZHMDQyVW8x?= =?utf-8?B?elNUVlFrYzFVaVVIVVhDS250NU12ckpHUDduYXMwZm5WUnh5TUVBK3IzaUZy?= =?utf-8?B?TnBrYlJCb2MrMS8rb0tZQm1xeDk1aXFTTWRxc21QYlZpbUtFYmNLSC9FcVBZ?= =?utf-8?B?aTFITHU4ZDhySURtOXZwZ1l3ZDFFem1ocERBNnlYYVFvcHB5WUNkQklUaDdk?= =?utf-8?B?L0EzbXA5b2NGRUEyMncvcllGNDVISWRHWG1RNDFTdWZWeWJ1MG1qQmFuRUQ0?= =?utf-8?B?YldMdEoxVDJZdGYxQm1pMk1SV3FNT1F2S1diTVdGYXBVV29kVmFtVHNyZmE1?= =?utf-8?B?YjZpMm9xRW8yaC93MGpyRGozWUlHVTNnUUUvRkw5dm15UmV5ZVJSRVgwdGpz?= =?utf-8?B?eW9SRHU0dFFkaXhuQXAwSUV4N3JFNjRWRmFnNFhVQjB0Z2NvQU9uLzRha3FY?= =?utf-8?B?ODJBT0lGeFUzdzRXSmJ0aCt1SUxCTVM2TmVZM0thdjFwMFlZUjhHRkZZaGgz?= =?utf-8?B?c2tUdTNmUlRqK3VQcVdFemsyd2VROWFyaUVRV0RRcXhheWI5ZzBycXhjWmFz?= =?utf-8?B?YVRrNGU1RzdrdlVYYThjRjJMdGFRVXpsWGJsMmZSNVJoclFNWXV5b3NzMzM2?= =?utf-8?B?M09acHdmQXRwUEdCOG9QcHEyL0ZYaU83c2ZiNVdrczZybS9hQ0RGclZraFFS?= =?utf-8?B?UzFKTmlMUlBZOHJJLzFSaHlnOW1CVlpramZ2d3BWNUM5dnhITkphWXNmbk9j?= =?utf-8?B?TG1QYXhxL3oweXFuZUNSQURQaDQyMjZlMWt0U1NJeERqdXZTWWZHMW1KRXhq?= =?utf-8?B?RE40RHArZU1OcVpETUtFVWNvNFlqK1Vaa3JoQktGbGNjTkRUWUZwNlRYc2F6?= =?utf-8?B?Q2psZXNlR09kcFgyUGdFZ2hGeEVrV0ozNlRyTndhS0twL1piSTFLa0t1SGhs?= =?utf-8?B?dzZtVllyOU9qVVVyakxoM3htMnZPN2I4YXp5TzlGbEwrQnBKRFl4alZHMGNH?= =?utf-8?B?UUd6RUxNZkVuWTJhOEV4YzgxRm1PN3l4cnJzZnY1KzVTWW9uV0JqRmZ3UHgw?= =?utf-8?B?aDZFSlpIS2phTS9LUkdoM09UeVdLZEJPcDZUUmdzWGtzall0MUF3eXpVcnY3?= =?utf-8?B?UzlWYlhkVzBMY0NWbVVvUHhORHBESDhpeThja1FOSDRCZmFBZFUxVmZWYTl3?= =?utf-8?B?SXdraW81VmtCQnFRYUtnQVRFMmVWOW1FbXZ5TmloSURCcGZVaUZxSDNaNjdN?= =?utf-8?B?aXV0RTQyOWZEWjJjQjRLdFJGT1FQSXh1eGdyUkJzeHJwVm5hdFU4bXNtaC9P?= =?utf-8?B?R1RhL2ovMDYwaEF4Y2MwRDFpb2FNTEM5Y1U2c0NnQy9sWkFWU0I0ODFpNUtk?= =?utf-8?B?eUlPVitwRFl5YnJVTlkvenNXV2x0WFZJN3U3QVNObnZzS0YzeDZUTmRMMi9Z?= =?utf-8?B?djN5MGtXc00wb0NQTU4weU9qR09DcHM0bzdEOGM4MXF6THVrVGo3N0ZZdU8w?= =?utf-8?B?NndWQ0FPMWlKUGtTYTZVMktsdmtWVFoxU1Nid1VVd2dHRkdVZm11N0ZLQmJX?= =?utf-8?B?UTVFVWJlSkhLZ1dvRE5aSWpINGhqVkFWMGlsT0toVW5VN1dEVGNNM2tmdGZx?= =?utf-8?B?YjlNUkdKWkVhZ3dOVWJOY0xkSWlPL0FjSlpsRFczWExtN0FZOEpwTWVldmFt?= =?utf-8?B?b2N4WVNBekxFUEJQRnpQd212azhQaVBvSGZSQmdDT09OVkl3MkdscmprRkFs?= =?utf-8?B?bFlUU2JDNDFaWllUekZ1ZTZQK216bmNqRnAvb2RtMlQ2QUVOdXN6d0tiWWVI?= =?utf-8?B?dkVGUXNTaWNYWXZob0JKbnZwS0kvTEVKYkNQdURiQVFITTBtYUZoR1BJY3c4?= =?utf-8?B?MllLZ29FaUcwSzRRdW53NEJVZWJMZHdIRDQxRnVVeXlMNW5XSExUQXZHc2Rh?= =?utf-8?B?eG5OcktVSW5va0srNTBlK0VpMEhxZTBuY21PbTRZRzRIczVnUzhlazg0cENR?= =?utf-8?B?MnlJaE1EaytnbjVwZTRzWEROK1R4MHp1V09pbExNWkxkclFnSnhwVUM2OUtY?= =?utf-8?B?YTAwaTFlMllMUVcvM09FbDhTNXlOaUo5Y0YrZkEzQWFIY0xnK1UxQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f2d5534-733e-4c85-3e7f-08df10d525ed X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2026 13:52:56.1049 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fxX9BUmsHD1EqWCsyqZ2pkTkeUIAdeeinvmUkmpy42mOpkkeCduzj/wSTZnPZeGRLWr/FF2pSvnMw4+EoVhXenGetIKqDD4bEgPJJ8u6zcw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6364 X-purgate-ID: tlsNG-42698a/1789221180-188C99EA-A3A96D05/0/0 X-purgate-type: clean X-purgate-size: 2514 On 12/09/2026 1:56 pm, Mr. Hoorn wrote: > Hi, > > I have isolated what appears to be an incompatibility between Xen's > Intel vPMU implementation and Linux's Alder Lake hybrid PMU > initialization. > > Host: > > Qubes OS > Xen 4.17.5 > vpmu=1 > /sys/hypervisor/pmu/pmu_mode = self > /sys/hypervisor/pmu/pmu_features = 0x0 > > Guest: > > PVH > Fedora 43 > Linux 7.0.11 (also reproduced with 6.12) > Alder Lake hybrid PMU detected > > With an unmodified kernel, Linux reports: > > Performance Events: Alderlake Hybrid events, Intel PMU driver. > > but then faults while enabling the P-core PMU: > > unchecked MSR access error: WRMSR to 0x38f > tried to write 0x000100070000003f > __intel_pmu_enable_all > > 0x38f is IA32_PERF_GLOBAL_CTRL. The failing value contains bit 48 > (GLOBAL_CTRL_EN_PERF_METRICS). > > On Alder Lake, Linux explicitly enables this for the hybrid_big PMU in > arch/x86/events/intel/core.c: > > } else if (pmu->pmu_type & hybrid_big) { >     pmu->intel_cap.perf_metrics = 1; > > Xen 4.17's Intel vPMU appears not to include bit 48 in the accepted > global control mask and consequently rejects the MSR write. > > The practical result is that ordinary hardware counters are also > unusable. For example, perf stat reported zero cycles/instructions. > > As a diagnostic workaround I built Linux 7.0.11 with only: > > pmu->intel_cap.perf_metrics = 1; > > changed to: > > pmu->intel_cap.perf_metrics = 0; > > After booting that kernel, the WRMSR fault disappears completely and > ordinary PMU counters immediately work: > > 12,228,346,996  cpu_core/cycles/ > 27,471,544,939  cpu_core/instructions/ > > A repeated run produced approximately the same instruction count and > sensible cycle counts. > > So the issue appears causal: Linux enables Alder Lake P-core > PERF_METRICS through IA32_PERF_GLOBAL_CTRL[48], Xen rejects that bit, > and PMU initialization is effectively broken as a consequence. > > I have not yet tested current xen.git, so this may already have been > addressed after 4.17. Is bit 48 / Intel PERF_METRICS supported by the > current vPMU implementation? If not, I think Xen should either > virtualize it or expose PMU capabilities such that the guest does not > attempt to enable it. > > I can provide further traces or test a Xen patch if useful. Thankyou for the report, but this won't have been fixed. Xen has no real knowledge of Hybrid; this is a known and out standing issue. ~Andrew From xen-devel-bounces@lists.xenproject.org Sat Sep 12 15:09:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 15:09:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418790.1646509 (Exim 4.92) (envelope-from ) id 1x5PLm-0007gq-9J; Sat, 12 Sep 2026 15:09:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418790.1646509; Sat, 12 Sep 2026 15:09:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5PLm-0007gj-6H; Sat, 12 Sep 2026 15:09:06 +0000 Received: by outflank-mailman (input) for mailman id 1418790; Sat, 12 Sep 2026 15:09:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5PLl-0007gd-4y for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 15:09:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5PLk-0042ST-ID for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 17:09:04 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa56ae9-8faa-0a2a0a5109dd-0a2a4508e81e-14 for ; Sat, 12 Sep 2026 17:09:04 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa56b10-f659-0a2a45080019-a237832f8d60-3 for ; Sat, 12 Sep 2026 17:09:04 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 170184EE0097; Sat, 12 Sep 2026 17:09:04 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789225744; b=LJYESk4J4p+XnQTbNXqgJGilJi312ySvRVaXS2sIk7mVZMqluWb/UlH8HVj70u4k408B +gHytz7aqKfvSCg4g6ORBAkpL3PBi1gBIyexuxu+CTgVd0aY4qVr1KmgyLKXfHrMq5HBz KPjUX6fyyGgxorZTc8QsNxEkodjkayxBReEPK3zmllu2M5yGWZ4Uv09ZitnhC4t5r9giq xPG61BoAa18lvgKMhy66UNHfoOhS5COY8NFQN825GjKLA6AIhBL1n/wyiUPXULbLSX1TB uvL5knFivPXA1c+fakh1Xh3jFTR8b+D1L20eQW4G2jIt3SODK72/wEtH3z1GT3bJz+sIR gC/lXMCJenlzTBdTQdbKGhHHcpGZ+upBE0FoaNKenXLWJ4lZGrPxHrUzWlwE4vjRVoeOE +uVXYgrPmkn+dB070HE5xvjAxnPXpEtJ+nYxrLFCc918eWhv++oy+x4tMD/mdFZyNie9r uF7X9b1/CsRn+ZpUgOnsRKF8cyIGl2zunS3pGi74tRMKm/goHRGnNqrz6rsxf814lekki ocsWMMxS8Nw6kLEa6IzNB8jM62FdMSMr6P1JfmZJS/rJn0ip6BJDb5buhU32WeG6hRdcf f0N+EocVjCyNKFf53JkY6UoFso5HcNSiAcLku2FWH1+y08UqBBnmcas0E/nGC0w= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789225744; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=ejPTY9h43ECeayBtlQG6CqAEIQZT5Y2gmubrHLJQH+M=; b=417MyG5HjfeqkAlSV9uyMZmU5bUrY4HF2/kRZxo535W3w9fkwXJeZ12dZB+Jf944ZCJX ehFdlpEUasQWdAvAKbyrU/sXKYfFJwevUK8kaptjOHBJkZ8lswtsT6MBPUVJ2kGGQEsyQ wTKOadBapvaCHA3efHCK1/0tli/dy/q2dbJEdLaYWSr6GtUxnf/TDJZ913G0ohZOeAiwX Zdo9qr0snHsoXFXnKdnCYK+O9UjMopdFr84ZbBzUs/cjOTgHFgDPWoMbmB+88WwXtctal hBnUfnePbmmSZIt5mlADuN9scCTK7qPYZl587m3XJEL9BvpxNkn4HKvKTnAq8YtIhhNjX bGc9ElqWspObrNx6aN7YubJwiiLMnYGNywZjcGNyPzj/epULqwvVLatfccOP8OqnycdOH pzCDDkz15Y0VnESiaurHcz66DucBk2etHgDpOFPEVByu4C3pnECPSCXGnpttUOaTJMCeo JxwAwiTph15Ybqa/+lG6DpDaOzWIJVish1EqTws8hDo2sHpv/dIBmeO0G6ddV6KC6U+8c c20DsohYGtA/gtTjS85t52vgYtERypB6ta1PL5Q1CZj0T0bS5SG5HweJW08SfvtHldMSZ PKATo8sASDQ9PQDvrACY5QGCxOHbkE/NYNnzfVpTHfZqqJbR5k2JGPq/ZPWqPs8= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Sat, 12 Sep 2026 17:09:04 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 1/4] x86/domain: address Misra rule 11.1 violation in reset_stack_and_call_ind() In-Reply-To: References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789225744-D694287B-7BAF051A/0/0 X-purgate-type: clean X-purgate-size: 2071 On 2026-09-03 13:43, Jan Beulich wrote: > Eclair dislikes both sides of the comparison to differ in noreturn > attributes, thus deeming this a violation of "Conversions shall not be > performed between a pointer to a function and any other type". Since > gcc > doesn't permit use of "noreturn" types used in a typecast, resort to > typeof(). > > No functional change intended. > > Signed-off-by: Jan Beulich Reviewed-by: Nicola Vetrini > --- > Really Eclair's diagnosis is misleading here, and not only because of > the > missing "noreturn" there, making both sides be identical: There are no > implicit conversions performed on this kind of pointer operands of an > equality expression. A diagnosis of "comparison of pointers to > different > types", along the lines of what compilers use, would be more to the > point. > The point here is that the types are not identical, if you consider noreturn as part of the function type (as clang does) or not (as GCC does). This is the reason why we err on the side of caution and diagnose this, and it's not likely to change in the near future. Perhaps we could make the violation message more explicit about the motivation of the mismatch. > --- a/xen/arch/x86/include/asm/current.h > +++ b/xen/arch/x86/include/asm/current.h > @@ -208,7 +208,7 @@ unsigned long get_stack_dump_bottom (uns > /* The constraint may only specify non-call-clobbered registers. */ > #define reset_stack_and_call_ind(fn) > \ > ({ > \ > - (void)((fn) == (void (*)(void))NULL); > \ > + (void)((fn) == (typeof(dom_xen->arch.ctxt_switch->tail))NULL); > \ > switch_stack_and_jump(fn, "INDIRECT_CALL %", "b"); > \ > }) -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Sat Sep 12 15:19:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 15:19:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418811.1646518 (Exim 4.92) (envelope-from ) id 1x5PVV-0000uQ-Ah; Sat, 12 Sep 2026 15:19:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418811.1646518; Sat, 12 Sep 2026 15:19:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5PVV-0000uJ-7k; Sat, 12 Sep 2026 15:19:09 +0000 Received: by outflank-mailman (input) for mailman id 1418811; Sat, 12 Sep 2026 15:19:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5PVT-0000uD-Un for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 15:19:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5PVT-008RIY-BZ for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 17:19:07 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa56d54-8faa-0a2a0a5109dd-0a2a45088ccc-6 for ; Sat, 12 Sep 2026 17:19:07 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa56d6b-f659-0a2a45080019-a237832f9664-3 for ; Sat, 12 Sep 2026 17:19:07 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 9B9354EE0097; Sat, 12 Sep 2026 17:19:06 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789226347; b=iUrDSMC74cO5fN28iRhreFSW2d3E86DsXTCf5JA43hm67QfyTzb2xN50zWlTok7ZUJxm mzDU10ToAtPlEUymCqsRUOlpT+c2iOhX6AS6hWMgmc3HO6AlGJSN8R1fZAEduTZ8qquTS I7zhZCZS4oRoX+nF3TYBN4MsX5cYCzGkXGfduen1F4F2oUuFEYJHv4ExbJXToT2zbs5ud m4v6b86O2eB2TKdibGxVN2L7BrQNfRbI2nLNq9BvOUhFELpVDeGntDQmd6GIyEGjTRHJQ R0PJlbw32tcqOVAu82anIaBgt2GgckaOToIZ3snxxis2zph6qhwN5V7K5arYpbF3m11QC ibyfFJL0Sm/sWCpebuNa8Jni7e6Q6tRKYoJS1L5mV7LwvBL/SbFuN4k9Ptw/M/7SFZHFi jIyG1pANxcH08xOmBaYnKivqoCyBtlEvZFKboTm4hrSJQUe5UEn4WvLDggIeWJ7BdaVMd 6dAOQaukKelj6nC4ea3sOboBzfHxGWsfK2F9chKIeiwqCWJ1mMh/mFy6sxN2JR835dXL/ WiDqKCr6kTYYv9rkOv02BoySetjEZ6gu/8oEGYPymBworF1LVBE9QXSrJ6xu/SZFZ/UKA bXCCAvNsLawZIStJCwb/fjTA4HC0v0uLb3EECKb5MIopfKbMhQasah3NhYoYN+M= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789226347; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=CI1LScU60Qem93FxM837FcjNQm4bgRcPvDdHg5ZULys=; b=Ls8RdDDvZwwWMItVsOS4BL/8Vav/3LCbLy5xeQHZ5klnqYNesa0mIrJPVT7TNQNeSb5l YHqcyeJOgvy8888MnC+g7AORPPCQ72wQnuD8KiJANqGP2RbhJrg7Cdqch8AsbTNxSu5XO qYSKvfPBtd3gkgwswUEUkAsZ9E7QJDcQXC6+pRvqW1A0FfdL1yNOf7fnI94vgLEwsyyno MQ+ndDLcZZXHtOb9Ixgo3nNLMohgfYmCalcFjwT0CCkKa73PKWUBY8i/5itVSj5So5xsP PEgKScOyHa15FQLiXRZCZknsRs+dR/lcILItL2W7dERruTR3fvNb8+Q0nFrqnAMgQmlnQ pBdj7z/1FiDG3whU7GU9QuYkPkVNlxuCBpcXctVNdPi25OKS+RpQJaEk5Y3Gy3lUtek4T N120oCFwYkiGAF8kzMcgAai7ShDKeW3uZ5GF4fg54zbYpzMdPQjOLFuNEnBcWC4zxRlTp QWoK6iYZbBJ1DuNFdL6eJVB7EKnITdB37imZ+P2IcmGjf6rN6XndoQl3gECOHMPIVVlPw phcXDoUMr9IZ3jsKhtXIHyYmXwG3iSEGW2PmrSz4YxiTitRraTb/SBDWbFFZLfO5pXrTZ Wy1wPhnUjrlI3ZyKzOc6okO793wMWmSOOozPrcuY+CeaH7QmDnb9S4gV0l89Gks= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Sat, 12 Sep 2026 17:19:06 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 2/4] Eclair: relax long <-> function-pointer conversion deviation In-Reply-To: References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Message-ID: <43e412de9e5165f33c572841bfc58dc9@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789226347-D437587B-3E9E04CA/0/0 X-purgate-type: clean X-purgate-size: 2931 On 2026-09-03 13:43, Jan Beulich wrote: > What is true for unsigned long is also true for plain/signed long, thus > also taking care of two instances of __x86_return_thunk() being cast to > long. > > Signed-off-by: Jan Beulich Reviewed-by: Nicola Vetrini Some nits below: > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -368,17 +368,17 @@ constant expressions are required.\"" > # Series 11 > # > > --doc_begin="The conversion from a function pointer to unsigned long or > (void *) does not lose any information, provided that the target type > has enough bits to store it." > +-doc_begin="The conversion from a function pointer to [unsigned] long > or (void *) does not lose any information, provided that the target > type has enough bits to store it." > -config=MC3A2.R11.1,casts+={safe, > "from(type(canonical(__function_pointer_types))) > - &&to(type(canonical(builtin(unsigned > long)||pointer(builtin(void))))) > + &&to(type(canonical(builtin(long)||builtin(unsigned > long)||pointer(builtin(void))))) > &&relation(definitely_preserves_value)" > } could be canonical(builtin(long||unsigned long))||pointer(builtin(void)) > -doc_end > > --doc_begin="Conversion from unsigned long or (void *) to a function > pointer can restore full information, provided that the source type has > enough bits to restore it." > +-doc_begin="Conversion from [unsigned] long or (void *) to a function > pointer can restore full information, provided that the source type has > enough bits to restore it." > -config=MC3A2.R11.1,casts+={safe, > - "from(type(canonical(builtin(unsigned > long)||pointer(builtin(void))))) > + "from(type(canonical(builtin(long)||builtin(unsigned > long)||pointer(builtin(void))))) > &&to(type(canonical(__function_pointer_types))) > &&relation(definitely_preserves_value)" > } Same as above > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -432,8 +432,8 @@ maintainers if you want to suggest a cha > - All conversions to integer types are permitted if the > destination > type has enough bits to hold the entire value. Conversions to > bool > and void* are permitted. Conversions from 'void noreturn > (*)(...)' > - to 'void (*)(...)' are permitted. Conversions from unsigned > long or > - '(void *)' to a function pointer are permitted. > + to 'void (*)(...)' are permitted. Conversions from [unsigned] > long > + or '(void *)' to a function pointer are permitted. > Example:: > > unsigned long func_addr = (unsigned long)&some_function; -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Sat Sep 12 16:04:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 16:04:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418927.1646527 (Exim 4.92) (envelope-from ) id 1x5QDe-0000bv-Dt; Sat, 12 Sep 2026 16:04:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418927.1646527; Sat, 12 Sep 2026 16:04:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5QDe-0000bo-Ao; Sat, 12 Sep 2026 16:04:46 +0000 Received: by outflank-mailman (input) for mailman id 1418927; Sat, 12 Sep 2026 16:04:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5QDd-0000bi-9l for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 16:04:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5QDc-00GbKq-N9 for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 18:04:44 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa57816-8faa-0a2a0a5109dd-0a2a45018db2-6 for ; Sat, 12 Sep 2026 18:04:44 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5781c-5984-0a2a45010019-a237832fa8fa-3 for ; Sat, 12 Sep 2026 18:04:44 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id D5A264EE0097; Sat, 12 Sep 2026 18:04:43 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789229084; b=vqX4ekhseKRR1gUd9RPLYpOH3LwX5gQzzdFkL34pkJtaczQCdDPsUKgEVMUUNY+YreNc R9Y0O9vOcsyhro25u+8dl4dq/DqYHt3y6+qRLN7hl6CJqWujFYVMb7SeEDo7ZrIXK3JZ2 zPxmMcJMOftJezLNzVLPP08FJaMt0umvZgsWvaycNcMMa4Enyg5AMHG3txhsI2W1OyEFK bW+nXHWn91cWjs36PGUg5W+K03trRUAM6b4PUgWRyA2TRPs64mfhdHFaj5X2fYzQrqkhM RJO3OupKyhB/vFVc6ajtAyimomG+9Th9Vb7piDyT1ClzA4gRxfT6Z1ZG+BtUkydvcJs4q p9MezPflcoLA1UU4DXYpkHGmaJ/SIf21lULFCtCz5FTXkApoxdYDzUsyEWYutlcHBf2W+ Wo6Il3e6QCiidnSfZr4ewUMpWK0JJ3SQ326O0NuUJzPmjWXMlHVZqSr0bcw5hUftDQH9i UGhmeW6Jr2/O3i7S9tTNC6qwu5MU7OBQc+fWBA8VF05ZxME8gBqXWnMrq+mukXabO/Okn E+T4bGL8CwHINLJmqh9d7NwfElZelMfSKhLKyIwpSL/ntGtNPeAfhkxxVyhqAvTt3etjK MmWNfG2cNC0Dktw8sbBvHVvN+Tf6EAbJ28jUAmaVC40ZQ1uxZrfmP0FdbmmSgb4= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789229084; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=cSv9l7Vk40fvDBSyCpP8B5XBYa3nkzrOqrr558Ucmlk=; b=01fa0IFXT9AmqOdCGXfyhBD4Y7WKlOejaOba4HO6EutZeETGIe7cTc4UQS+o5MOniECk +GMdvg/Z7k77IsjuYrbFhC+0W9usWP0sVmGz20XAcpH9NPLk3IcvlzNeOZuPzwFXOjG3E VidIbnI04ppaZqu676UO/hetqK9HS+wy/nx5vqqGpBHov5SENbkBWBEwobhM3WR7xOTkr 3O7vGcvL0qjbe0PR8GxYrRIxA5V15h9Nq2iZxgNlhT49RXXlQgPDJ2sRnfgqLuHaBaynv CzSVifN9wcLM6SZEqSbe/Ljnct0TXFi2WO/q81O0DdtwOBBDC7MZx48V7KUdiIZsPdw1O tpg7mHbPL1MEZxn1jsFwpVs+/yThCmDwpVAAK+4WW0tvKv7fRVMmsh4gp5FCtn0TkjUir 1WMyh3+5S4WJlmL+IqIhRkq3gsfZbLvfT5kb6s5bYPadsA2S+GpIh0sP6jGz5M6FZJmAh gjCROkOUVLYPcw1AwnV4UqmqgBqpDzBOiJjc9LjMlX7GdKcGjjRnMxAQY37fE1dX4s8BQ PGhEq0g4fajCK1rxRERSZXoKIlN+SdxSzKni5Lt0zx88r98A5yGN8cUel90QCLHsTmQdT pNu/KWQ+Ea3Y5zOXgjzBVugyysl2Vq1mosVyhwVj11vH0kcB+pmK0yvspvg0554= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Sat, 12 Sep 2026 18:04:43 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 3/4] Eclair: relax "noreturn" function-pointer conversion deviation In-Reply-To: <4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com> References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> <4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com> Message-ID: <3d473b8a85331856ea2b95f9448f2d6c@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1789229084-C5341757-4EDCF6CF/0/0 X-purgate-type: clean X-purgate-size: 3219 On 2026-09-03 13:44, Jan Beulich wrote: > Like misra/rules.rst says, function arguments other than "void *" are > okay > as well. > > Signed-off-by: Jan Beulich > --- > I can't explain why this covers the violation in mce.c:mce_callbacks'es > initializer, but not the one in mce.c:default_handler's. > Possibly differing attributes (e.g. cf_check vs section attributes)? Just a guess that would need to be tested, though. > As a result of 6852334f8416 ("Arm/GIC: add noreturn in a few more > places"), vgic_v2_lpi_to_pending() and vgic_v2_lpi_get_priority() (both > returning non-void) would also need covering. (As said in a remark > there, > non-void together with noreturn is somewhat odd.) > Indeed > Really before and after this change there's no checking that parameter > and > return types actually match. I have no clue how one would express such > checks. The presence of a bitcast indicates that the two types do not match exactly. Typically function attributes are not relevant towards determining a type difference, but different compilers may model non-standard features differently (rightly so), in such a way that some make a difference in the AST, and others do not. To check for compatibility of function pointers I would try activating service STD.funptrcv, which essentially mirrors -Wincompatible-pointer-types: caution for rule STD.funptrcv: (rule) A pointer is used to call a function whose type is not compatible with the pointed-to type. (untagged) p.c:8.8-8.8: Loc #1 [culprit: implicit cast converts from `void(*)(int)' to `__typeof__(@EXPR@)*' (that is `void(*)(void)')] qq = m; ^ p.c: In function ‘h’: p.c:8:6: error: assignment to ‘void (*)(void)’ from incompatible pointer type ‘void (*)(int)’ [-Wincompatible-pointer-types] 8 | qq = m; | ^ p.c:3:6: note: ‘m’ declared here 3 | void m(int x); | ^ > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -391,11 +391,11 @@ constant expressions are required.\"" > } > -doc_end > > --doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void > (*)(void *)' is safe > +-doc_begin="The conversion from 'void noreturn (*)(...)' to 'void > (*)(...)' is safe > because the semantics of the 'noreturn' attribute do not alter the > calling convention or behavior of the resulting code." > -config=MC3A2.R11.1,casts+={safe, > - > "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1, > pointer(builtin(void)))))))&&from(expr(skip(!syntactic(), > - ref(property(noreturn)))))"} > + > "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))))))&&from(expr(skip(!syntactic(),ref(property(noreturn)))))" > +} > -doc_end > > -doc_begin="The conversion from a pointer to an incomplete type to > unsigned long does not lose any information, provided that the target > type has enough bits to store it." -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Sat Sep 12 16:06:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 16:06:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1418935.1646535 (Exim 4.92) (envelope-from ) id 1x5QEu-00019N-Mr; Sat, 12 Sep 2026 16:06:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1418935.1646535; Sat, 12 Sep 2026 16:06:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5QEu-00019G-Ju; Sat, 12 Sep 2026 16:06:04 +0000 Received: by outflank-mailman (input) for mailman id 1418935; Sat, 12 Sep 2026 16:06:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5QEt-000191-9g for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 16:06:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5QEs-00BzvZ-Lh for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 18:06:02 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa5783e-2eae-0a2a0a5409dd-0a2a4509c6d4-38 for ; Sat, 12 Sep 2026 18:06:02 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5786a-be1a-0a2a45090019-a237832fead8-3 for ; Sat, 12 Sep 2026 18:06:02 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 5875C4EE0097; Sat, 12 Sep 2026 18:06:02 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789229162; b=ciNIUcNFHwEymnPkd/aSZT8qyv7IX5grpO4bbnPXBQsMHwoiHmZF0i5xgJRCnxFv7CzT mLJciiIfIj4uJ6sKGI58FgUotyxObV0OhBXuNw8oHMSvR194Xty+yGNB3vzi0YQyMIRCT KXjwgDhd/gUfrCtz0aQg7sbShWHRbbKMCS7tf2jbPp+jX43XuczfOpe+kzCBIIG+HhRrp PujGxF9Ae4FOkaZaWtRCef4rsHAC+aAo7nMJSo9SnYxLVVlFLDova0vR8olnX77LdSM3g 5yrJ0Gv1yMBi6Q36/JTbW4vnJCYflJ+E+pqGtRfwzB6dIAdLEOgvfU/O2U1AVRzQDH4ud PiFdqisDuZz10eoHM+8XQCN1Gts0j72VR8E33xBKzZuxMu/0mPwyhYW6PHKYlpeIwQhQE jsDrEH645069VQfPbzEzmh1FPohzI0I2noBDRA+lm9QzWZ9XSz2l9GpEZ9cgdd9TfUOhZ 6p3LgFNdYMSFSLzsXcjo/VzWMxcrObTV1Onb34dOvC7pIQudkjPcAhvm8hZzwxfogllJY fRuf+Ot7VNgz7/zXITgSVIut5gUuRaCdamOSBsGooGkEcjY8m1IC4DBp1xNpNzJ1u1Nbq 7KI9WQHicwj29yUT5iMlZqgAKurKwNoFUw9AmfxyrWirt5q1xlmjDgGd/TKihEM= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789229162; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=fG5ayPlCqvJrR/2PDK/mBBXHYWI+AGxZaxz8I3DlI48=; b=1vep8M46bfdKuKQldv06+OcPBpfuqZMDPsmGv2RbTcD2/c/UxldhzoX5kIQUy1xtAU9A FAZAUSPzjt2W+ga4D+zQSD5Owu3itla6RzyyoXgZddytkLkTnEsutSwuq0bKjuwKsbX9F tnytjwULTNCP4DXIELcLlOuawrmjde5D0xVaBUr0mfb4JORdCssH6nOzk1oBWtu7FS5qN MvewpuB2RIeX6RM4GzZzfkeedMGOLUMJvjFZHgnj8PKCAQHbEQHZ23h2SgIMxuqAH4JSx W6Cu+K2Pn5+Vk4YxjWwv+5GKkwQ/YKHzkZQtHxTOeFpBboQLDoxLF9qXIQktHZVxot3Z3 YZOVVbxDfws6IWF1WsJ84XPoAfe02MIqvdZBgCQkZXLGNDDC7qiTyb4MDJGS5pkFZL7T3 I2StEET/puMZGANOIhtHQ7F2Wmyzg7A5odXaDblGsiQ+g1dRH4V2yYOFSW8UpcBekJNwU VA7pxaoFXsaVOsE8LTh9l3pHyLZU/kYyYQZUpKiYoT+E4rOJDvEThYsyM+6mAC1LJXC13 YKbpTrVI4CKoqjQds3cQLp7h7UzNXQwtII0Q5Xbm9dcP3kudGiaZMHG2oaTMGrmntGznF SELU8lXWV49PwIAJtkKy8vc7XE/yM+hCBCM61ZrYP2BsgFgrHl37gOPW0kszP7s= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Sat, 12 Sep 2026 18:06:02 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper Subject: Re: [PATCH 4/4] x86/kexec: address Misra rule 11.1 violation in machine_kexec_load() In-Reply-To: References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1789229162-39EC6034-9C467D56/0/0 X-purgate-type: clean X-purgate-size: 993 On 2026-09-03 13:44, Jan Beulich wrote: > Misra rule 11.1 demands no conversion to different types at all. We > deviate conversions to long, unsigned long, and void *, though - > leverage > that deviation here. > > No functional change intended. > > Signed-off-by: Jan Beulich Reviewed-by: Nicola Vetrini > > --- a/xen/arch/x86/machine_kexec.c > +++ b/xen/arch/x86/machine_kexec.c > @@ -121,7 +121,8 @@ int machine_kexec_load(struct kexec_imag > } > > code_page = __map_domain_page(image->control_code_page); > - memcpy(code_page, kexec_reloc, kexec_reloc_end - (char > *)kexec_reloc); > + memcpy(code_page, kexec_reloc, > + kexec_reloc_end - (const char *)(unsigned > long)kexec_reloc); > unmap_domain_page(code_page); > > /* -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Sat Sep 12 17:19:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 17:19:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419051.1646544 (Exim 4.92) (envelope-from ) id 1x5RNP-0003cy-1p; Sat, 12 Sep 2026 17:18:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419051.1646544; Sat, 12 Sep 2026 17:18:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5RNO-0003cr-VG; Sat, 12 Sep 2026 17:18:54 +0000 Received: by outflank-mailman (input) for mailman id 1419051; Sat, 12 Sep 2026 17:18:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5RNN-0003cl-LB for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 17:18:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5RNN-00C6fx-2F for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 19:18:53 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa5897c-bab6-0a2a0a5309dd-0a2a4508cbce-2 for ; Sat, 12 Sep 2026 19:18:53 +0200 Received: from [74.125.231.205] (helo=mail-oi2-f13.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5897b-f659-0a2a45080019-4a7de7cdd5b7-3 for ; Sat, 12 Sep 2026 19:18:52 +0200 Received: by mail-oi2-f13.google.com with SMTP id 5614622812f47-4b37a3ed715so463735b6e.3 for ; Sat, 12 Sep 2026 10:18:52 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:72::]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4c3315b19afsm5495263b6e.10.2026.09.12.10.18.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Sep 2026 10:18:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="In-Reply-To:References:To:From:Subject:Cc:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789233531; x=1789838331; darn=lists.xenproject.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=M1c6suOtzZ2rRuH1TXxQJyOcddxpg3oryXf9dCc4tZI=; b=eXni8R/Ig6XkctFZ1FR7KPVJsfac2Hwq3by/eSpBsp+BdBO7+H4N/Vxtwm/oUbLrJf xg/XePf6ilqAe2z3ghs2GP8dV0GXlRkEgBO6b5w2Ft5HE4+IftjO6oQTUqyVeF5IXEEZ tJDRsedrWJaCqtrmMcxoqvbqPGUyM7FFG9pXFINnZO8/lIxEHrUaAvgABxyGq8ztJad+ Di4ZqGnoHp7SnmTR/QWPyvR7OSkOw0hCF90DOItE+oCIxIalH2EkHiUANdy91T2UXcRD kDHFzFjC/ODa+/39+WYj2tzxrlnBM0271E7QRpdK6Z0phjOyOmfwPRFwmiAewen+aPf3 sVhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789233531; x=1789838331; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=M1c6suOtzZ2rRuH1TXxQJyOcddxpg3oryXf9dCc4tZI=; b=eRZOVd5yBtuKcnhDy6XV4V+jX6rzlJxsDJ/2Ut3Rh9wdawUfWd7+PrQ9QVVj1+1sfL V3WBgCAqt0mqH+F/DVbjrMW17DZ0Yv1lfwmIqdn3fh/HGoOtriCawcC8g10FfQT8Ba1v eH4gI/qEQBjCtbR4De57Juy8Th4LEgXHgecgXcQ7cGNhUrE3OsxezPCWW8Rqso2wbx1w XFj9nOybLEhd8GqVNA6UFfHU5kXvkftEV+EH0iISuGubgMfx36PkOV8TSicH4PlzJThA bmDTmN74D3BqfkTIXA+lPn/78ctsVvCcEpACMBOWnlBONAX/jre2os6/ErkrKQyhU8SQ aiMA== X-Forwarded-Encrypted: i=1; AKwUvByX27HkGbwQhdqc8nQzfR9rLJZu3mUm8nKOJ/IRtiMntg4oLHGtnCVkjGHVucW21zbLMqHUbYUs51M=@lists.xenproject.org X-Gm-Message-State: AFuF++k7igI4dtWXqmX5j2WCBtP0t3Ulq2PtRB3cuDinp3qB47YmZozo bwawU5EZ4AumYcgva5QwE117ai/Ig7+9Z5noHYeSHcmaTn/qe2sQBr29 X-Gm-Gg: AYBFou2cCerQP0vZ8fZsXCwjMBngru7w6pDKeClPVNjciWKPUWUCG81qRafl9OEI2kn rFsynntQSdkDQ33VHvHcBPxuBzyrsqRtoN5146Mo1RPkp1nbPrxHW/mcg+aR4dItLEe/ghDv060 GP34OSNlKdjUWuffIMCQgJQ8GNP9/tagMn//Qo7GkluTHnxckZKoYEd0Bz0xSorly2DkVmFJ9rl lKZz+b2UzVq0VSF6qTnBABBF7sgtisUw3THiB4qz+Jrp9q2IY7Cx8l/X5dYHpCI8up4BIiRZRjv nfB4NPF2MKBLKLecKPkjFdZJDkH3diLt3bVUFfd8Xg/5PfHXTS8xCk71kmrQZLcuBEXOGfZcnMM kMLOxE+HqfKxe7qhAnFkpAh3MPxNmq7AfQw8h4Fab5WT6lTGMK2guWjxVhkdjZpM9XcDCxZ4qgM q9mjpR6GeUUAOp2nMMdoENPdoDJITQoXjEfvhyDvbt4rCx6v/DRgvX0cRvmQ7StI62ceUkL0otE nJ43HgGA6bmuBC8Mv0Fibzf43JRbFUc8m7gSW8W+etIOgemsqlagzVWWu2I7IK25Q== X-Received: by 2002:a05:6808:3503:b0:4b3:8323:8cd8 with SMTP id 5614622812f47-4c4a751294bmr2617971b6e.5.1789233530981; Sat, 12 Sep 2026 10:18:50 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 12 Sep 2026 10:18:48 -0700 Message-Id: Cc: "Josef Bacik" , "Frederic Weisbecker" , "Neeraj Upadhyay" , "Joel Fernandes" , "Boqun Feng" , "Thomas Gleixner" , "Peter Zijlstra" , "Steven Rostedt" , "Masami Hiramatsu" , "Mark Rutland" , "Jiri Olsa" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , , "Catalin Marinas" , "Will Deacon" , "Puranjay Mohan" , "Xu Kuohai" , "Andy Lutomirski" , "Josh Triplett" , "Uladzislau Rezki" , "Mathieu Desnoyers" , "Lai Jiangshan" , "Zqiang" , "Juergen Gross" , "Luis Chamberlain" , "Ihor Solodrai" , , , , , , Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline From: "Alexei Starovoitov" To: X-Mailer: aerc References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> In-Reply-To: <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> X-purgate-ID: tlsNG-c1860d/1789233532-CF35D87B-DB50ED72/0/0 X-purgate-type: clean X-purgate-size: 3717 On Fri Sep 11, 2026 at 10:10 PM PDT, Paul E. McKenney wrote: > On Fri, Sep 11, 2026 at 08:27:56PM -0700, Alexei Starovoitov wrote: >> On Fri Sep 11, 2026 at 7:08 AM PDT, Josef Bacik wrote: >> > Emit an increment of current->rcu_tramp_nesting once the trampoline's >> > frame is set up and a decrement before the final register restore, so >> > that a task preempted while running fentry/fexit/fmod_ret/LSM programs >> > or the __bpf_tramp_enter()/__bpf_tramp_exit() glue is not treated as >> > Tasks-RCU quiescent. Drop the count around the call to the original >> > function: that may run arbitrarily long without sleeping and must not = pin >> > a Tasks RCU grace period, and the trampoline frame above it is held by >> > im->pcref rather than by Tasks RCU (see bpf_tramp_image_put()). The >> > fmod_ret early-exit branch and the ip_after_call -> ip_epilogue poke b= oth >> > skip the decrement/increment pair around the original call, so the cou= nt >> > stays balanced on every path. >> > >> > The sequence is "mov r11, gs:[current_task]; inc/dec dword [r11 + off]= "; >> > r11 is scratch at every emission point and (u32)¤t_task is a val= id >> > sign-extended %gs-absolute with the current per-CPU layout, the same f= orm >> > the JIT already uses for this_cpu_off. The image is dynamically >> > allocated text, so the instructions outside the bracketed region are >> > covered by the irq-exit IP check. >> > >> > Assisted-by: LLM >> > Signed-off-by: Josef Bacik >> > --- >> > arch/x86/net/bpf_jit_comp.c | 43 ++++++++++++++++++++++++++++++++++++= +++++++ >> > 1 file changed, 43 insertions(+) >> > >> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c >> > index 2853e87797a7..a375c1b7bd50 100644 >> > --- a/arch/x86/net/bpf_jit_comp.c >> > +++ b/arch/x86/net/bpf_jit_comp.c >> > @@ -722,6 +722,31 @@ static void emit_indirect_jump(u8 **pprog, int bp= f_reg, u8 *ip) >> > *pprog =3D prog; >> > } >> > =20 >> > +/* >> > + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). >> > + * >> > + * mov r11, QWORD PTR gs:[current_task] >> > + * inc/dec DWORD PTR [r11 + offsetof(struct task_struct, rcu_tramp_= nesting)] >> > + * >> > + * r11 (AUX_REG) is scratch in the trampoline at every point this is = emitted. >> > + */ >> > +static void emit_rcu_tasks_tramp_nesting(u8 **pprog, bool enter) >> > +{ >> > +#ifdef CONFIG_TASKS_RCU >> > + u8 *prog =3D *pprog; >> > + >> > + /* mov r11, gs:[abs32] */ >> > + EMIT2(0x65, 0x4C); >> > + EMIT3(0x8B, 0x1C, 0x25); >> > + EMIT((u32)(unsigned long)¤t_task, 4); >> > + /* inc/dec dword ptr [r11 + disp32] */ >> > + EMIT3(0x41, 0xFF, enter ? 0x83 : 0x8B); >> > + EMIT(offsetof(struct task_struct, rcu_tramp_nesting), 4); >> > + >> > + *pprog =3D prog; >> > +#endif >>=20 >> It's not a lot of overhead, but I feel it will be the death by thousand = cuts. >> rcu_read_lock_trace() in bpf_prog_enter_sleepable is doing the same thin= g... >> increamenting a variable inside current. >> Can they be combined? Like treat current->trc_reader_nesting > 0 as >> current->rcu_tramp_nesting > 0 ? >> Or replace one with the other? >> Two current->foo++ operations look redundant. >>=20 >> bpf trampoline is already quite heavy. I'd like to find ways to reduce >> its overhead instead of adding more. > > Replace rcu_read_lock_trace() with Josef's rcu_tasks_trampoline_enter)? If necessary... what I don't understand why we need another rcu_tasks_trampoline_enter-like= counter. Can existing rcu_read_lock_trace() current be used ? It's already doing current->trc_reader_nesting++ so use that as a signal ? From xen-devel-bounces@lists.xenproject.org Sat Sep 12 18:03:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 18:03:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419118.1646554 (Exim 4.92) (envelope-from ) id 1x5S4h-0002wV-9a; Sat, 12 Sep 2026 18:03:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419118.1646554; Sat, 12 Sep 2026 18:03:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5S4h-0002wO-6e; Sat, 12 Sep 2026 18:03:39 +0000 Received: by outflank-mailman (input) for mailman id 1419118; Sat, 12 Sep 2026 18:03:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5S4f-0002wG-Qv for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 18:03:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5S4f-005Ein-6k for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 20:03:37 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa5937a-8faa-0a2a0a5109dd-0a2a45068234-48 for ; Sat, 12 Sep 2026 20:03:37 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa593f7-195a-0a2a45060019-ac6904fee466-3 for ; Sat, 12 Sep 2026 20:03:36 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id E919360235; Sat, 12 Sep 2026 18:03:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 932741F000FF; Sat, 12 Sep 2026 18:03:34 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 56CBCCE0D0D; Sat, 12 Sep 2026 11:03:34 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789236214; bh=Md9WelEldZZ4Ti1nbWtYRKkv5dq5cYQ/RxA8am4GwnA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=kSa5DrkkkUmOilrNwX8mCGTqIsVDmG5EHpntNkCXDmLMOllg43ob3k/ThGbGJ9EOG GARY19upGTuRE1Z4eHkz1Wvr/pU5U8dSsgtRFzDs3B1890zirBY0fVY9lekehb1eC4 lEtYA5YNUS7yDDcmIeYb05T5XJIyLG1HuqMX1ALJjTQaweV716mJCM7q5ZUOwyNDNx OG9WQMhVUIccN/ZzFvHBcatxhIaI/BrWinZy8c+glAV356FR3lOev4fQD+T+i/dDMj +EO98mhLF5amoi6CfZZNA4U9OdWRITDloRaUVRbTUpAwzpkn+XnrUjiLLJjsaRKGbz +pl8bxVsU6yvw== Date: Sat, 12 Sep 2026 11:03:34 -0700 From: "Paul E. McKenney" To: Alexei Starovoitov Cc: Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline Message-ID: <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-16d1c6/1789236217-F4A0477B-E31C0A24/0/0 X-purgate-type: clean X-purgate-size: 4943 On Sat, Sep 12, 2026 at 10:18:48AM -0700, Alexei Starovoitov wrote: > On Fri Sep 11, 2026 at 10:10 PM PDT, Paul E. McKenney wrote: > > On Fri, Sep 11, 2026 at 08:27:56PM -0700, Alexei Starovoitov wrote: > >> On Fri Sep 11, 2026 at 7:08 AM PDT, Josef Bacik wrote: > >> > Emit an increment of current->rcu_tramp_nesting once the trampoline's > >> > frame is set up and a decrement before the final register restore, so > >> > that a task preempted while running fentry/fexit/fmod_ret/LSM programs > >> > or the __bpf_tramp_enter()/__bpf_tramp_exit() glue is not treated as > >> > Tasks-RCU quiescent. Drop the count around the call to the original > >> > function: that may run arbitrarily long without sleeping and must not pin > >> > a Tasks RCU grace period, and the trampoline frame above it is held by > >> > im->pcref rather than by Tasks RCU (see bpf_tramp_image_put()). The > >> > fmod_ret early-exit branch and the ip_after_call -> ip_epilogue poke both > >> > skip the decrement/increment pair around the original call, so the count > >> > stays balanced on every path. > >> > > >> > The sequence is "mov r11, gs:[current_task]; inc/dec dword [r11 + off]"; > >> > r11 is scratch at every emission point and (u32)¤t_task is a valid > >> > sign-extended %gs-absolute with the current per-CPU layout, the same form > >> > the JIT already uses for this_cpu_off. The image is dynamically > >> > allocated text, so the instructions outside the bracketed region are > >> > covered by the irq-exit IP check. > >> > > >> > Assisted-by: LLM > >> > Signed-off-by: Josef Bacik > >> > --- > >> > arch/x86/net/bpf_jit_comp.c | 43 +++++++++++++++++++++++++++++++++++++++++++ > >> > 1 file changed, 43 insertions(+) > >> > > >> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c > >> > index 2853e87797a7..a375c1b7bd50 100644 > >> > --- a/arch/x86/net/bpf_jit_comp.c > >> > +++ b/arch/x86/net/bpf_jit_comp.c > >> > @@ -722,6 +722,31 @@ static void emit_indirect_jump(u8 **pprog, int bpf_reg, u8 *ip) > >> > *pprog = prog; > >> > } > >> > > >> > +/* > >> > + * Tasks RCU trampoline nesting, see rcu_tasks_trampoline_enter(). > >> > + * > >> > + * mov r11, QWORD PTR gs:[current_task] > >> > + * inc/dec DWORD PTR [r11 + offsetof(struct task_struct, rcu_tramp_nesting)] > >> > + * > >> > + * r11 (AUX_REG) is scratch in the trampoline at every point this is emitted. > >> > + */ > >> > +static void emit_rcu_tasks_tramp_nesting(u8 **pprog, bool enter) > >> > +{ > >> > +#ifdef CONFIG_TASKS_RCU > >> > + u8 *prog = *pprog; > >> > + > >> > + /* mov r11, gs:[abs32] */ > >> > + EMIT2(0x65, 0x4C); > >> > + EMIT3(0x8B, 0x1C, 0x25); > >> > + EMIT((u32)(unsigned long)¤t_task, 4); > >> > + /* inc/dec dword ptr [r11 + disp32] */ > >> > + EMIT3(0x41, 0xFF, enter ? 0x83 : 0x8B); > >> > + EMIT(offsetof(struct task_struct, rcu_tramp_nesting), 4); > >> > + > >> > + *pprog = prog; > >> > +#endif > >> > >> It's not a lot of overhead, but I feel it will be the death by thousand cuts. > >> rcu_read_lock_trace() in bpf_prog_enter_sleepable is doing the same thing... > >> increamenting a variable inside current. > >> Can they be combined? Like treat current->trc_reader_nesting > 0 as > >> current->rcu_tramp_nesting > 0 ? > >> Or replace one with the other? > >> Two current->foo++ operations look redundant. > >> > >> bpf trampoline is already quite heavy. I'd like to find ways to reduce > >> its overhead instead of adding more. > > > > Replace rcu_read_lock_trace() with Josef's rcu_tasks_trampoline_enter)? > > If necessary... > what I don't understand why we need another rcu_tasks_trampoline_enter-like counter. > Can existing rcu_read_lock_trace() current be used ? > It's already doing current->trc_reader_nesting++ > so use that as a signal ? In the old kernels, yes, we have current->trc_reader_nesting++. In the newer kernels, Tasks Trace RCU is instead implemented in terms of SRCU-fast, which instead increments per-CPU counters. Which among other thins is a bit faster and does not need to hook into the scheduler. So we have several ways forward: 1. Revert the implementation of RCU Tasks Trace in terms of SRCU-fast, and use the existing current->trc_reader_nesting++, as you suggest. 2. Deprecate RCU Tasks Trace entirely in favor of RCU Tasks augmented by rcu_tasks_trampoline_enter() and friends, as I was suggesting. 3. Implement rcu_tasks_trampoline_enter() in terms of SRCU-fast, keeping the speedup, and put a synchronize_srcu() in the RCU Tasks grace-period mechanism. This again deprecates RCU Tasks Trace entirely in favor of the augmented RCU Tasks. 4. It is always good to explicitly state the apparent status quo, which involves redundant trampoline entry/exit overhead. 5. As always, your additional ideas here! Thanx, Paul From xen-devel-bounces@lists.xenproject.org Sat Sep 12 19:41:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 19:41:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419224.1646563 (Exim 4.92) (envelope-from ) id 1x5Tav-00014l-0j; Sat, 12 Sep 2026 19:41:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419224.1646563; Sat, 12 Sep 2026 19:41:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5Tau-00014e-Sv; Sat, 12 Sep 2026 19:41:00 +0000 Received: by outflank-mailman (input) for mailman id 1419224; Sat, 12 Sep 2026 19:41:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5Tau-00014Y-6W for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 19:41:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5Tat-00BSlk-Jp for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 21:40:59 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa5aa95-e002-0a2a0a5209dd-0a2a4509d4ea-20 for ; Sat, 12 Sep 2026 21:40:59 +0200 Received: from [209.85.161.52] (helo=mail-oo1-f52.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5aaca-be1a-0a2a45090019-d155a134f100-3 for ; Sat, 12 Sep 2026 21:40:59 +0200 Received: by mail-oo1-f52.google.com with SMTP id 006d021491bc7-6b1b3d7f10eso1664178eaf.3 for ; Sat, 12 Sep 2026 12:40:59 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:5::]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-6c0996dc5a6sm6404372eaf.6.2026.09.12.12.40.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Sep 2026 12:40:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="In-Reply-To:References:To:From:Subject:Cc:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789242058; x=1789846858; darn=lists.xenproject.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=/mW9uIl4IQ84J3enCrJFqvgB+YMh25zxbJWRDQHZcYo=; b=s9hQD2Agz6C59mL3EABkZHvm5UCYEio8KSlEDEQ/eQ4qZiE2iQOgCTRgPfzl7qAAae T9PdhXQsg+KJ3Jm8z9P7egKdU3HPKkZMU0CiqRHYgHjjuWI6WQ600MRfjyqjGYxsa3az 0AU+uJPz/sebB0repw5e6SjrOVGm7adwZ6uXoCx5ASTQnSiZLb4pXwfpUMJAjLqt3dE0 OS1NNyvA/ctr3iFYLfYwD7ZgHJWzv+SYmwrUfSPo4q2HM7PZZcAbEX8Lt3eAktItDOhw TQ4TBtabpQvQkiRwUef25JgifEQtFw7KNpskgwN8jlof+YANn+gJ29SbM5jKhvzKew8o CWNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789242058; x=1789846858; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/mW9uIl4IQ84J3enCrJFqvgB+YMh25zxbJWRDQHZcYo=; b=Ol5V39brexbOckxRZz4eRaSWGvo36j8MEcu0H1FwljpnqqkYhyPU1o8eKuzsRZiq8k coT9j05TjZcJoDCaIA7DdZPEBR3XkincB9bi6tojWgKZHvPs7wCSWRQGuca09Pyc7krt vLvEBoDXVNMyqd0R8ZaV090rlICPu6ScAkq3M2TgfcKW++utJiPrKv93qi86TeLO5Vpg YKmsbU32roO8p+fH+nDjcKOy+FjAfCSPXmRya5dQ0Ln+tOphryHxst3GHEMvZeTFPoIr K7MVxXKqOHhmzV6Nbr2XPDSF0jwnSjPZNPidWuHXQh2W8LArSvXjOCGdnrL0duJfqeur LDsQ== X-Forwarded-Encrypted: i=1; AKwUvBxOzindFgCCDkwLpaA/QstO9leStzBuMLRtrK2jmdyE8/ih02K3M1NDnRx/4+XI79w+kA3M8n4wgy0=@lists.xenproject.org X-Gm-Message-State: AFuF++lnIPaLZ+Wfq6LaVtz3ogjA0amrTgCgHnWueIzfEGZ7bOBwvyXb i5JFDgGxADoD+7sVxOWOEC0yBovqruw9ZjbNGO6pw3af3I4PRHkPIpiY X-Gm-Gg: AYBFou2ljoedUoTkEhAQZ+9im+0mvwQl1bsSzYCKMwRTpyFjSSQ5O+kWcRu1Cpf7/1G OqX5NfG7KbK9B8Ur8ftzbRtyigjzcWCbUsWyzOte3D5WX5ZhV3rjXkRagJRt1FS96+QhlgX9/Yc 90Zqg5nPbPSkGjV9TDceUexR0fuDfNnXwCbQOklFqsTD2BGD0SdrH086fhPrKVaew0OLC8GkUk0 XLMtAAWO+iBXdu5j/IoEPbPhZ3n/G32B0RynI1RZ4zcZAdo+ZHPOSSGQIsUKYHw7N+IfjR2p/5N +LqOIgRl13C4GvNIHoMXfUoa7hOoAYoKjWzTA+q4+UN0sw7RE44/J0fBPeirDR/mU14mUiHi9pp YHsRoWOX1JBYtgmHhC6+NOZb68QH0vJMbEgayBxtvAQ6EVg/ARNKIN4zvY0E55fPzBVB8oU1grY 7PQRX09PwHkMW+FLTmD7Szx8nJWfyrfjc0jKoRvNkf/WsH2LyfejZPuYvQC3IoQ/Smv474BRIZY vLa8MHoiA81iYhS5X6fgdbqQktngjTvBLqup+nS3Glfm4orTAD1rh3ESmkFQ2O0CVd4cnaeuM8= X-Received: by 2002:a05:6820:f034:b0:6c0:c954:e534 with SMTP id 006d021491bc7-6c0c9550c4dmr5760632eaf.38.1789242057820; Sat, 12 Sep 2026 12:40:57 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 12 Sep 2026 12:40:55 -0700 Message-Id: Cc: "Josef Bacik" , "Frederic Weisbecker" , "Neeraj Upadhyay" , "Joel Fernandes" , "Boqun Feng" , "Thomas Gleixner" , "Peter Zijlstra" , "Steven Rostedt" , "Masami Hiramatsu" , "Mark Rutland" , "Jiri Olsa" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , , "Catalin Marinas" , "Will Deacon" , "Puranjay Mohan" , "Xu Kuohai" , "Andy Lutomirski" , "Josh Triplett" , "Uladzislau Rezki" , "Mathieu Desnoyers" , "Lai Jiangshan" , "Zqiang" , "Juergen Gross" , "Luis Chamberlain" , "Ihor Solodrai" , , , , , , Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline From: "Alexei Starovoitov" To: X-Mailer: aerc References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> In-Reply-To: <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> X-purgate-ID: tlsNG-bad1c0/1789242059-BDAC0034-D6DF696E/0/0 X-purgate-type: clean X-purgate-size: 1388 On Sat Sep 12, 2026 at 11:03 AM PDT, Paul E. McKenney wrote: > > In the old kernels, yes, we have current->trc_reader_nesting++. > In the newer kernels, Tasks Trace RCU is instead implemented in terms > of SRCU-fast, which instead increments per-CPU counters. Which among > other thins is a bit faster and does not need to hook into the scheduler. old kernels? I'm confused. rcu_read_lock_trace() in bpf-next is doing t->trc_reader_nesting++ and then calls __srcu_read_lock_fast(). Are you talking about some RCU branch that you target for next merge window= ? > > So we have several ways forward: > > 1. Revert the implementation of RCU Tasks Trace in terms of > SRCU-fast, and use the existing current->trc_reader_nesting++, > as you suggest. > > 2. Deprecate RCU Tasks Trace entirely in favor of RCU Tasks > augmented by rcu_tasks_trampoline_enter() and friends, as > I was suggesting. > > 3. Implement rcu_tasks_trampoline_enter() in terms of SRCU-fast, > keeping the speedup, and put a synchronize_srcu() in the > RCU Tasks grace-period mechanism. This again deprecates > RCU Tasks Trace entirely in favor of the augmented RCU Tasks. > > 4. It is always good to explicitly state the apparent status quo, > which involves redundant trampoline entry/exit overhead. > > 5. As always, your additional ideas here! > > Thanx, Paul From xen-devel-bounces@lists.xenproject.org Sat Sep 12 21:14:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 21:14:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419279.1646572 (Exim 4.92) (envelope-from ) id 1x5V2z-0004YS-C7; Sat, 12 Sep 2026 21:14:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419279.1646572; Sat, 12 Sep 2026 21:14:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5V2z-0004YL-8W; Sat, 12 Sep 2026 21:14:05 +0000 Received: by outflank-mailman (input) for mailman id 1419279; Sat, 12 Sep 2026 21:14:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5V2y-0004YF-6b for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 21:14:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5V2w-00BaTl-UG for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 23:14:02 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa5c089-e002-0a2a0a5209dd-0a2a4504e6d0-10 for ; Sat, 12 Sep 2026 23:14:02 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5c09a-b57f-0a2a45040019-d155dd30f12a-3 for ; Sat, 12 Sep 2026 23:14:02 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-482dd6ee390so1672539f8f.3 for ; Sat, 12 Sep 2026 14:14:02 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d26c39086sm240080175e9.10.2026.09.12.14.14.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Sep 2026 14:14:01 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789247642; x=1789852442; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=RN6NlWXNxbscB16yrp/7Xyb7tbAGCIZghMiPDdHQJK4=; b=YhRAVcnau0VIrAkRvPmVBBPukmbvJhcHmLOK/XARXc7BY6opjPc4nAZ6dGW98pUdjy VK+jh9PCmrbK7MyeIfZpTpMOzQTnoxAtVxH+LCasFrHH4cyLVTHwn3jR39W8sjtYGslQ YYQckOKXAaL2x/oXVBGtdpteeIssZ8t64oPlMEh+3NxrsoHtmwYb45QMWcDkO0qUpnAw dusXWKb398z+JVk5KNmtwMB326rm7dAj1RXM8fn1qOwGGN6hao7LhY1oi2TXdYLjs7lp J3ZgOJutKl0fj09YD3Q+0djUwaExmF7PyiAdEIOneRMo5ThJmQLToY4g7OdtZiWnU1Dd +PwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789247642; x=1789852442; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=RN6NlWXNxbscB16yrp/7Xyb7tbAGCIZghMiPDdHQJK4=; b=djmUSbTMZzuC+pbt5D27z+wao6arox6xE+deP8g92gJ+/CgxVaSit1+/lhOvIY3R9G djF74EnWS48KPemCgYkkwSggd4NCwROqa8VZFiMD937U9KriNed3F9R5enwuF8TG/oYM YWKlPmfbneMaIPXZVWn3tLXr/B2JN5fbRlb6FBfcrE1e+6nOY9J3DAaJxbpK/wmWF3VH fzpuvxC9V+c4qQIbeVzBCiXxO52ikTpNlAsqzAgLDdw9vT8XNYElYHD/ZjjV/Jg0TM8j jZwIyieNnyLvBWrWzfqx9Fyddu9d23kY01bc3pcOCuGZVdwep3DdBzGc6Br3iLQV/ydd tltg== X-Forwarded-Encrypted: i=1; AKwUvByTq8dFDOjLYowZmRirFxNvLZZdnVAqsboHwVOR3lvzZP3+NM5YvSsGwM8vQYhVP/OFK80SSjuZHoI=@lists.xenproject.org X-Gm-Message-State: AFuF++m31E1AqRuco8bKvtw0ZK7QPtckOG6SVXBLlUWb/FjrkN3HxB/u BYJoIglAAQ1+pbdAy3gzN4akKtgO2H+8XLeAegx5Rcg/aQ7updevOtz9 X-Gm-Gg: AYBFou3tfDkwqYve8+v0FuWa+9DtgOGeQ6IUggCUansF9O6OC+eFMq98Wa4PYXXsaFY fT45vTkJwAcwbOXsGb8VghQKOoz4BLZaR83bsC93oF2Qa58zzFmYm9pEpIKs0+pqFriYj3UWRcE 0+M0YBV17PMDAMAr4yLnG2RWZNBBgldeSJbmkxS/uWcHQt58/GEZYsWeMtsE/KOqb2oUtGNI8ub LdJTvzykHtzralrjUJvk+mBYKnRfG8DaauAF9L/NFMFjjPTTr1TCqAIMauyCYxDXZithZjNZ6Rq ZdQM+Fzyy1JcJestUz16ZbV8OzeNTqnl/s/vRimXKijT2VMJElMpd2x7aithCABAxCNrrZv87ub /GdL8mlPp7/DQ59HGUnUF/BPyUvdJiJYqZZ0oQhkDCetCj4ttyApRTLx9NcsrVsVr/Oew8KHV2l NQsY+wI1nIwkurAzK59vFnk+tORwePgGiI0v+oZXBxxRS97j0Ak9IQsAHTme68LaLcXdASIBrTR C7j86/yCX5kjpVGZlpI9+u7VUgHhQxkLi+U X-Received: by 2002:a05:600c:3513:b0:49d:28c4:b304 with SMTP id 5b1f17b1804b1-49e619d479emr105307385e9.29.1789247641902; Sat, 12 Sep 2026 14:14:01 -0700 (PDT) Date: Sat, 12 Sep 2026 22:14:00 +0100 From: David Laight To: "Paul E. McKenney" Cc: Alexei Starovoitov , Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline Message-ID: <20260912221400.4045198b@pumpkin> In-Reply-To: <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1789247642-514D3B50-FAC32024/0/0 X-purgate-type: clean X-purgate-size: 522 On Sat, 12 Sep 2026 11:03:34 -0700 "Paul E. McKenney" wrote: > In the old kernels, yes, we have current->trc_reader_nesting++. > In the newer kernels, Tasks Trace RCU is instead implemented in terms > of SRCU-fast, which instead increments per-CPU counters. Which among > other thins is a bit faster and does not need to hook into the scheduler. Isn't that rather architecture dependant? It is fine on x86, but on arm incrementing a per-cpu variable is significantly expensive. David From xen-devel-bounces@lists.xenproject.org Sat Sep 12 22:28:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 22:28:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419325.1646581 (Exim 4.92) (envelope-from ) id 1x5WCx-0005fQ-Dw; Sat, 12 Sep 2026 22:28:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419325.1646581; Sat, 12 Sep 2026 22:28:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5WCx-0005fJ-AN; Sat, 12 Sep 2026 22:28:27 +0000 Received: by outflank-mailman (input) for mailman id 1419325; Sat, 12 Sep 2026 22:28:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5WCw-0005fD-Fr for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 22:28:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5WCv-004fWg-A3 for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 00:28:25 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa5d209-e002-0a2a0a5209dd-0a2a45019d6c-0 for ; Sun, 13 Sep 2026 00:28:25 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5d206-5984-0a2a45010019-aceafc1f8a64-3 for ; Sun, 13 Sep 2026 00:28:24 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 7CEDB44B58; Sat, 12 Sep 2026 22:28:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7CDB1F000FF; Sat, 12 Sep 2026 22:28:16 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 9A778CE17BD; Sat, 12 Sep 2026 15:28:16 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789252096; bh=FUSC3/6wZp614V0HmSolX31ACddFJPOtZM6hstYDymE=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=CAY8iaMRIgUEVj2m8qO5yp0DxUv+P5XvE2wHuZpVgEs1aEJozyptLJbfPwIDKU9cG nZ8lr7em4IssfJNCHthk1CBckof4zi6MPqWd2jJVXxGnpw499vSiEhg0xj7sJOYZgY 8C/0OqEOoxtby2igBkVtTcnZDnI6giwDd39+A3lwn/gzgznfonBDHsvuJ+lNWa/070 UYnUHAEQ18maKO95GoFBGluciXa8xqJjOpILbWWdTFyb/lqEmdWzQ78VurvGX1Z7Sv KjOJN8mcAIANRvNl//XI9HifNzupXh1acBkdTfKFwO0hryPFkxTNHR9mulXJ+sQ3Rw OD+q87PDNaJpg== Date: Sat, 12 Sep 2026 15:28:16 -0700 From: "Paul E. McKenney" To: Alexei Starovoitov Cc: Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline Message-ID: <8fbfb3fc-cf5d-4dfb-b144-bc021faa13ff@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-d62444/1789252105-BDE78757-BBB6BF1A/0/0 X-purgate-type: clean X-purgate-size: 2150 On Sat, Sep 12, 2026 at 12:40:55PM -0700, Alexei Starovoitov wrote: > On Sat Sep 12, 2026 at 11:03 AM PDT, Paul E. McKenney wrote: > > > > In the old kernels, yes, we have current->trc_reader_nesting++. > > In the newer kernels, Tasks Trace RCU is instead implemented in terms > > of SRCU-fast, which instead increments per-CPU counters. Which among > > other thins is a bit faster and does not need to hook into the scheduler. > > old kernels? I'm confused. > rcu_read_lock_trace() in bpf-next is doing t->trc_reader_nesting++ > and then calls __srcu_read_lock_fast(). > > Are you talking about some RCU branch that you target for next merge window? No, I was thinking of rcu_read_lock_tasks_trace(), forgetting that rcu_read_lock_trace() is still used. (For good reason, just be clear.) Your comments are quite correct for rcu_read_lock_trace(). Hmmm... Josep's using t->trc_reader_nesting would break for partially overlapping RCU Tasks and rcu_read_lock_trace() readers. But yes, your #5 makes sense: Deprecate RCU Tasks, upgrade RCU Tasks Trace to check for preemption from within trampolines, and move RCU Tasks users over to the rcu_read_lock_trace() variant of RCU Tasks Trace. (Or am I still missing your point?) Josef, thoughts? Thanx, Paul > > So we have several ways forward: > > > > 1. Revert the implementation of RCU Tasks Trace in terms of > > SRCU-fast, and use the existing current->trc_reader_nesting++, > > as you suggest. > > > > 2. Deprecate RCU Tasks Trace entirely in favor of RCU Tasks > > augmented by rcu_tasks_trampoline_enter() and friends, as > > I was suggesting. > > > > 3. Implement rcu_tasks_trampoline_enter() in terms of SRCU-fast, > > keeping the speedup, and put a synchronize_srcu() in the > > RCU Tasks grace-period mechanism. This again deprecates > > RCU Tasks Trace entirely in favor of the augmented RCU Tasks. > > > > 4. It is always good to explicitly state the apparent status quo, > > which involves redundant trampoline entry/exit overhead. > > > > 5. As always, your additional ideas here! > > > > Thanx, Paul > From xen-devel-bounces@lists.xenproject.org Sat Sep 12 22:31:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 22:31:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419343.1646590 (Exim 4.92) (envelope-from ) id 1x5WFv-0007E3-TD; Sat, 12 Sep 2026 22:31:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419343.1646590; Sat, 12 Sep 2026 22:31:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5WFv-0007Dw-QS; Sat, 12 Sep 2026 22:31:31 +0000 Received: by outflank-mailman (input) for mailman id 1419343; Sat, 12 Sep 2026 22:31:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5WFu-0007Dq-P7 for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 22:31:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5WFu-005cQF-4o for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 00:31:30 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa5d2c2-2eae-0a2a0a5409dd-0a2a4501e940-0 for ; Sun, 13 Sep 2026 00:31:30 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5d2c0-5984-0a2a45010019-aceafc1f8fb8-3 for ; Sun, 13 Sep 2026 00:31:29 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 03E38429C6; Sat, 12 Sep 2026 22:31:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5401E1F000FF; Sat, 12 Sep 2026 22:31:24 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 17205CE17BD; Sat, 12 Sep 2026 15:31:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789252284; bh=ce1HX5koLmAjYA7zzAHVeJdUkobP3h1/gtoI/ft1GtQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=PVts4P+ZFRMNDP8IPda+oXXNIXvO3R62sGgiWrzFfvap+u4GoPR1dLdGGy1nA0Ytv 9fvL2deDyqRn/CzAhHJjEhGwZ5OAuVc1ga/S9ipJo7/P+0z1zArvcm+jE34YnTRk2r bN80Leor8ep5neouVAB55Kn+ZdojDTppn7WbzVcdKArvfbTFSNU2IgySo2UA5sFUU8 Z6dbvvFLJjFVTcEO2IO3MHptg1MK8nbOVxr+EpfImqmCw/EkpZEVQ8cipgPpzd4nsr g14pK3zn/l64SXO2vt4ABs94DMJN1Yr+vAqyP9X4MSsPkbnbKUh3IgJ94cqk9WHRfV AqhUafm/316dA== Date: Sat, 12 Sep 2026 15:31:24 -0700 From: "Paul E. McKenney" To: David Laight Cc: Alexei Starovoitov , Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline Message-ID: Reply-To: paulmck@kernel.org References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> <20260912221400.4045198b@pumpkin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260912221400.4045198b@pumpkin> X-purgate-ID: tlsNG-d62444/1789252290-1E07B757-16F62215/0/0 X-purgate-type: clean X-purgate-size: 858 On Sat, Sep 12, 2026 at 10:14:00PM +0100, David Laight wrote: > On Sat, 12 Sep 2026 11:03:34 -0700 > "Paul E. McKenney" wrote: > > > In the old kernels, yes, we have current->trc_reader_nesting++. > > In the newer kernels, Tasks Trace RCU is instead implemented in terms > > of SRCU-fast, which instead increments per-CPU counters. Which among > > other thins is a bit faster and does not need to hook into the scheduler. > > Isn't that rather architecture dependant? > It is fine on x86, but on arm incrementing a per-cpu variable is > significantly expensive. Last I heard, slow ARM increments of per-CPU variables were to be a transitory phenomemon. Plus changes late last year greatly sped up the per-CPU increment operations. Plus this change removed some hundreds of lines of RCU code. Thanx, Paul From xen-devel-bounces@lists.xenproject.org Sat Sep 12 23:59:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 12 Sep 2026 23:59:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419400.1646599 (Exim 4.92) (envelope-from ) id 1x5Xct-0001Gv-Ug; Sat, 12 Sep 2026 23:59:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419400.1646599; Sat, 12 Sep 2026 23:59:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5Xct-0001Go-Rv; Sat, 12 Sep 2026 23:59:19 +0000 Received: by outflank-mailman (input) for mailman id 1419400; Sat, 12 Sep 2026 23:59:18 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5Xcs-0001Gi-Dx for xen-devel@lists.xenproject.org; Sat, 12 Sep 2026 23:59:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5Xcq-00BoEI-8Y for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 01:59:16 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa5e649-e002-0a2a0a5209dd-0a2a4501ec7c-38 for ; Sun, 13 Sep 2026 01:59:16 +0200 Received: from [209.85.214.178] (helo=mail-pl1-f178.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa5e752-5984-0a2a45010019-d155d6b2e107-3 for ; Sun, 13 Sep 2026 01:59:15 +0200 Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2cfbbdfa60bso21142785ad.3 for ; Sat, 12 Sep 2026 16:59:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1789257554; cv=none; d=google.com; s=arc-20260327; b=B4a5xdKJQ2v7f9LjwB3jfjHLwggFgSHOkdrH3FVbsjVCxAsLytAb1EVS9eny09iT33 V2qgexTSXScug9Em79Aj46FBTHwB25723FBL8Yz9Snd15ruu6NPB5EF27DVH6eQMWO4R 59iTt8ZQxRlDWtt1ExruQA6XIShBSQg5IYXRusZw7pkvouFoSQKYpLjmVnhLBMvDPsYe 1gQj+rK54tfzf9ES1DW3MirOwrpqWKG0JomurwGrRb/rD8zsuvAr3cxkzBYlutg9/TS9 lBHSLDJCFoUYe/765O7boEMaS62EMf4R5klBfNDNFdwkQ3CQl4jDdoW2N85mqZ6DoE7i +pEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=5whm1ZGtSD6d9UTQoSVGX4pAamqW3MhbLVJJEUPVUGg=; fh=KLzOaxjmFPU4ZAnxx5B7YBeW6stGSKQtRp7BAQnf2jo=; b=NRvXPohDoxSwdotPeJWKFC9WYeUpRK8PuYGtA0BbyUnhX/fKGc00Txbr5MzhG0LOep BHICtJRbK7VDwt8YdyGdRyzKTLHxQZrXX3Fn/fngI+SketIdDN5DZ3YxUcdOFqH3TJpN TtnUn4jcPoan607vUNfGPFsKc/m54N2HWQi0ekg5yFC5iOo3DxR9/zwfENgTynaWIuhj OMMZhLJv9chxg8C85XsCNH9u1pGvaaShLVfa3T2lnotFx57CVp3WgkFoUJg1JsIU5Fss NrouF8ZCuwhYqdvGADNMKIOcs3Zkj0+FJa3+scftkv+pVtYZ2ndiPsDrXOFsA9EGdoIW NoJg==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789257554; x=1789862354; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=5whm1ZGtSD6d9UTQoSVGX4pAamqW3MhbLVJJEUPVUGg=; b=bAibL0bmJ9pYf1JDhRPabeCbmltULmhELE/5+F/v+bW9cz1LSEz9c2HwC8lEuri3FN JOKG+a5RLUtho2Y8yYj8HisdSXKG8WZEgRZm9aZ69/1Kn4pipDhUbfRM4jXlPDwY6FFl ChyZpQ1Kmzndsd2yKZFPHNaudkY5Vk6ONFb4Fn+v8wFtZpbp2P6xBfHJ2iSEefjPjzha lA43fz+9TieZMruxop2vucJPhWDZU/nZo/LgZg6TIlnVnA7LRr0CiCQ4PGKhdEJyHqwa iAwSY7IBWvjKTEMeAdYabKYk5Wgt4mDF5R3I/Lx3KbBrwfBL8vKqEsT8YIq/Wv2P6dR2 SVYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789257554; x=1789862354; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5whm1ZGtSD6d9UTQoSVGX4pAamqW3MhbLVJJEUPVUGg=; b=bb7IeblD65/nYZXYU34vrxrr/ZR7MEwnHZzM7DWpn5mRY5h6c/S7gbLjSRs3a63I7c JEAgzlsgmInHtzeuWQvuVbM+yHYNXacxR9XdCcg4uXNBIZ604Xa5cYUYC0U5xw5WICyt BgGte5S/8KxfjtmTfh8GSwwlRePg1KhZ2mOFtpvGvV9H4BzPejOJ3zgBm+dgnOE/9K8s ozX4KZQw5AXWB0oiisY4rrBGbUob0TGHyjTXdYyDptaIMQYmHYte+EvooglFL4j/SaGW FZkMN72tl+9qQcoJCvM3B70/l+3bxeUnF7ocwRa59zriDoHBzdXBY7o6X6MmWHP7CaaC fEnQ== X-Forwarded-Encrypted: i=1; AKwUvBwxcfDv202XtItr+r75ONypLkOXXyWABkKR0arKGmnRHTCINMEXj+Alwyq9Lzz9t6hAl4kT1DfGY8w=@lists.xenproject.org X-Gm-Message-State: AFuF++nWxxeQioL/UzSe4yJEDHFMm/TR/vEEAsBs8p1/8Znx0thya8xb cfTW3CqbPF5x5LN74I6NANyTRTtM/65LOZmZwekCvKbPrEGoGzjthM9IXFlTUX6b78p1gV2MNC9 yPEVev8kjIkwSOpsKuLDZZudq52ZUpY8= X-Gm-Gg: AYBFou3cWEDQQEe51ZUXn7gKEhWi9FlykhIbFIvcUDKoJy7nIv62+a3yet27koc/Maj k24VCf2DL+uMA9TV8ZUZpHXWyaMpwJFQVXaBns/AYz+0w/Rg6kOQkfT6r7pitQQ4dzXWAm2ow+M BI8LiZtDrdSnWimoTGh03wrijpE1k+xNMdEh7XnlNKrpdALjxob4J2kPQ5W9OgbyP7ehGBEUf9X 75QGzBiFPjIhD6BMM35kqk3wgXzCZi9/WzHG2N1IQfFBhwKO8YQsaZqHlRUNBRojV0iT7e8uTmd yCQncy8Yq3c+AcFGo+q6UWcKlP5lj/ceBMvuJ7q87UU8TYlPPTUmp0Q0WqcGzIEbVX+POq0bF8g X/grlub8RMQ98omaB3EClZQCC9eoZq3QEM0WdSd4= X-Received: by 2002:a17:903:1ac6:b0:2db:331b:e187 with SMTP id d9443c01a7336-2dd2a1e0a15mr200200855ad.8.1789257553733; Sat, 12 Sep 2026 16:59:13 -0700 (PDT) MIME-Version: 1.0 References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> <8fbfb3fc-cf5d-4dfb-b144-bc021faa13ff@paulmck-laptop> In-Reply-To: <8fbfb3fc-cf5d-4dfb-b144-bc021faa13ff@paulmck-laptop> From: Alexei Starovoitov Date: Sat, 12 Sep 2026 16:59:02 -0700 X-Gm-Features: AcwNN1V04v_YLyVyvshDjEX_boeHQmR-dgrTXGEZk0Tlq9YUUBiA7_5E2kzlt5Y Message-ID: Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline To: "Paul E. McKenney" Cc: Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , X86 ML , Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , LKML , rcu@vger.kernel.org, linux-trace-kernel , bpf , linux-arm-kernel , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1789257556-BD67C757-00C7B7B6/0/0 X-purgate-type: clean X-purgate-size: 1758 On Sat, Sep 12, 2026 at 3:28=E2=80=AFPM Paul E. McKenney wrote: > > On Sat, Sep 12, 2026 at 12:40:55PM -0700, Alexei Starovoitov wrote: > > On Sat Sep 12, 2026 at 11:03 AM PDT, Paul E. McKenney wrote: > > > > > > In the old kernels, yes, we have current->trc_reader_nesting++. > > > In the newer kernels, Tasks Trace RCU is instead implemented in terms > > > of SRCU-fast, which instead increments per-CPU counters. Which among > > > other thins is a bit faster and does not need to hook into the schedu= ler. > > > > old kernels? I'm confused. > > rcu_read_lock_trace() in bpf-next is doing t->trc_reader_nesting++ > > and then calls __srcu_read_lock_fast(). > > > > Are you talking about some RCU branch that you target for next merge wi= ndow? > > No, I was thinking of rcu_read_lock_tasks_trace(), forgetting that > rcu_read_lock_trace() is still used. (For good reason, just be clear.) > Your comments are quite correct for rcu_read_lock_trace(). > > Hmmm... Josep's using t->trc_reader_nesting would break for > partially overlapping RCU Tasks and rcu_read_lock_trace() readers. > > But yes, your #5 makes sense: Deprecate RCU Tasks, upgrade RCU Tasks > Trace to check for preemption from within trampolines, and move RCU > Tasks users over to the rcu_read_lock_trace() variant of RCU Tasks Trace. > (Or am I still missing your point?) Pretty much. This way bpf trampoline stays as-is. No extra overhead there. rcu tasks users (faultable tracepoints and what else ? ) switch to rcu_read_lock_trace(). The only difference for faultable tracepoints is extra t->trc_reader_nesting++. I have studied the rest of the patches in the series, so this proposal can be completely off the mark. From xen-devel-bounces@lists.xenproject.org Sun Sep 13 03:07:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 03:07:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419463.1646608 (Exim 4.92) (envelope-from ) id 1x5aZC-0008R0-73; Sun, 13 Sep 2026 03:07:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419463.1646608; Sun, 13 Sep 2026 03:07: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 1x5aZC-0008Qs-25; Sun, 13 Sep 2026 03:07:42 +0000 Received: by outflank-mailman (input) for mailman id 1419463; Sun, 13 Sep 2026 03:07:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5aZB-0008Ql-8W for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 03:07:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5aZA-005zYl-2y for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 05:07:40 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa6136a-2eae-0a2a0a5409dd-0a2a4507be8e-8 for ; Sun, 13 Sep 2026 05:07:40 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa6137a-b4ea-0a2a45070019-aceafc1fcc94-3 for ; Sun, 13 Sep 2026 05:07:39 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 7AB1141691; Sun, 13 Sep 2026 03:07:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 524621F000FF; Sun, 13 Sep 2026 03:07:37 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 15EE5CE0ABC; Sat, 12 Sep 2026 20:07: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789268857; bh=KdhlkMkoM3bS0HNmhu6FPeXNMD9uLWI8hS4d5wSjOX4=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=CuSv2pXmX2je4sRvmHKKZCalCD4vMRFoFyu9Z7kjqib0HJZ0R96u12SmyJngVxR2d CSNggnMjRbuvaNfpOxA6kKMng4amlgHfCnKyRffj3AMRXMMXauRj9OaXw5P8g9hq4g 0Z6jqwCBeRqIaINZKgWOtW/1/1bcaqhLqkyXwoXoLd2+dn2NIgd0vZi2yb8bASDNLv piKOj5Fgnde2tv2VXvS/Qdfwbv8zZb8k7djWMTU3jTaLAmygk5QLxZBQxBQre6yGdu +uOGZV0+QeWDGdOrI+TtWo4puMNcmdgECkEQg0EnCDjhQv4usxIOb1Vf5UzttNUsW+ 4U1q7S5+5p0zA== Date: Sat, 12 Sep 2026 20:07:37 -0700 From: "Paul E. McKenney" To: Alexei Starovoitov Cc: Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , X86 ML , Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , LKML , rcu@vger.kernel.org, linux-trace-kernel , bpf , linux-arm-kernel , xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline Message-ID: <509e8eff-2a9c-4927-956c-73708ee4fe5a@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> <8fbfb3fc-cf5d-4dfb-b144-bc021faa13ff@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-ef75cf/1789268860-37CD7AE4-D81A7B25/0/0 X-purgate-type: clean X-purgate-size: 1998 On Sat, Sep 12, 2026 at 04:59:02PM -0700, Alexei Starovoitov wrote: > On Sat, Sep 12, 2026 at 3:28 PM Paul E. McKenney wrote: > > > > On Sat, Sep 12, 2026 at 12:40:55PM -0700, Alexei Starovoitov wrote: > > > On Sat Sep 12, 2026 at 11:03 AM PDT, Paul E. McKenney wrote: > > > > > > > > In the old kernels, yes, we have current->trc_reader_nesting++. > > > > In the newer kernels, Tasks Trace RCU is instead implemented in terms > > > > of SRCU-fast, which instead increments per-CPU counters. Which among > > > > other thins is a bit faster and does not need to hook into the scheduler. > > > > > > old kernels? I'm confused. > > > rcu_read_lock_trace() in bpf-next is doing t->trc_reader_nesting++ > > > and then calls __srcu_read_lock_fast(). > > > > > > Are you talking about some RCU branch that you target for next merge window? > > > > No, I was thinking of rcu_read_lock_tasks_trace(), forgetting that > > rcu_read_lock_trace() is still used. (For good reason, just be clear.) > > Your comments are quite correct for rcu_read_lock_trace(). > > > > Hmmm... Josep's using t->trc_reader_nesting would break for > > partially overlapping RCU Tasks and rcu_read_lock_trace() readers. > > > > But yes, your #5 makes sense: Deprecate RCU Tasks, upgrade RCU Tasks > > Trace to check for preemption from within trampolines, and move RCU > > Tasks users over to the rcu_read_lock_trace() variant of RCU Tasks Trace. > > (Or am I still missing your point?) > > Pretty much. This way bpf trampoline stays as-is. No extra overhead there. > rcu tasks users (faultable tracepoints and what else ? ) > switch to rcu_read_lock_trace(). > The only difference for faultable tracepoints is > extra t->trc_reader_nesting++. Let's see what the other tracing guys think. > I have studied the rest of the patches in the series, > so this proposal can be completely off the mark. This last is highly ambiguous. Help? ;-) Thanx, Paul From xen-devel-bounces@lists.xenproject.org Sun Sep 13 03:27:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 03:27:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419480.1646617 (Exim 4.92) (envelope-from ) id 1x5asQ-00031R-Mr; Sun, 13 Sep 2026 03:27:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419480.1646617; Sun, 13 Sep 2026 03:27:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5asQ-00031K-JO; Sun, 13 Sep 2026 03:27:34 +0000 Received: by outflank-mailman (input) for mailman id 1419480; Sun, 13 Sep 2026 03:27:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5asP-00031A-SG for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 03:27:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5asP-007Hv4-8T for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 05:27:33 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa6180f-bab6-0a2a0a5309dd-0a2a4501c83a-8 for ; Sun, 13 Sep 2026 05:27:31 +0200 Received: from [98.137.65.32] (helo=sonic315-8.consmr.mail.gq1.yahoo.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa61821-5984-0a2a45010019-62894120aea1-3 for ; Sun, 13 Sep 2026 05:27:31 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Sep 2026 03:27:29 +0000 Received: by hermes--production-ne1-6dbcb84f44-w9zrq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 14c5b846713c82b711c43225786a63a7; Sun, 13 Sep 2026 03:27:27 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789270049; bh=g6sVmPbbWSgcriWyUOxys6QUYAKxA8mRO/u8gh7Vvqg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=lNLGQ6+IzXgHybURv5QtyOTWJ/M1pBx9M9FcaQcSN+VQEap5wvfBs/SwAzqsMCZBZqmJAblveMZ76tk6yFRbP8B9ljvsE8ciT47EQY64s17AODwO0YUx9eAt1gtp1uj80bq2q1+G7k3GmkuTdAOvbsdHHMmjCBosnNf/mDfPENL70pvPyOXxA8sPPZzUyrf4mHsLW+AGDqA8r4IQ9B+FdvqFuSkRbnx2XoQdhPCyAzHo7KOcslWP3OY6yoAWyH9/yhl5Ms4SwPnGDBWU7QiSCzyFGtjsB2Ripq1chOwYz4QvPMyNUGQ62EK5PclW2rYRIAQc2c4oiI00O3RhjcSoUA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789270049; bh=k1QjJqPObvY+kp3pNOGyD4/IHYJIHdlOHQmtNrQwsEQ=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=c6p1ck+b9U8VCHEi9cfW0HGgAgx8djYoakvGHUkuZoPhgxEQ91mbpes1gzdTtN0iUPPdlXoGvzM5vPzR+kGBg1T5vgTC6IbU8HWWpn77oqur20//hAd4YnBiQ2KuuqtAwnXP2gZTB+Aonykc/l4PT/oPD6cWS/fuyxJdbySPcPjsEczU7ISolfUNy8KsBD/XEQ4Nq8MOrkOOZK2cPeTH4137luYdcHPL8udbHb2uLs5LifubNytCisRlVB14oyji1FIIUZ4rRNxn8/5vjRLLERmv6Jxw8oXZ1vQN8mzElczPgsunsaYu2Wfeu8HeqIYYn897iGgCB6IMyg50DxRb6A== X-YMail-OSG: DqWhuPQVM1mEjDiTVRhsZi5mrC0ABHntBCEg2xo6HRC4dsndt6vu6cW8iQ5lHyZ DtSKKJJH.FdHJSPKqSBlAIXiC7roIZA4nwyLtCWN1XmLTsBIXVT9HlMj0qbsxXlSud85DKpMYXM6 f2QZ9w7wIcNSxKDw_CFO4yE0fQsVv.ForvkhaexANwHesKJsUyvTeDSP3hoRVfC9is_4TCaJlvX_ jkdU39axBbP0DoZxvzBwowQWjETcTEAEvYskGyloRDF88JYWw1Y6M_pYA4Z5jTtW4j3wSBRKql3w gewpxSxZ9PdQgt6jogwQteFvSGFf1_WCuCuYEfNPLXoirJdCZzMc3Db7qYFaKQWgOqCiNm0JjrBe aqI25O6.wwzLz8a98Y.1Tbgplip2585lOOHf_x2UwuxLJ8gcnSrwPoSHZjc0jQVU9RuCDZhNllA0 dAlC1I_Zr_i6aBSHwCDuoQbgB0eXIgm_Zia1Ro1DXwbrPZvs4XvjC9kwybmfmGlVobd30zEKtBba 93QNIuD9._8A3i0JGNsbtF7uMNahJlU19Ae8R49bb.EHPHRYds8UW0C0e19bVEcf1s3.0Ghorok_ 8srByNfYrx7hpCq7eEZG7ay6ZBanzHWpnpVvYqcO0Fk9L7yVJ._xqt.zRopx9JWULpNt2M_PT9hl _Jm9fl584UfkbEWcwm8TydWbmeksUifsAUEhWRgKGsDQfelk.ij_urGvvjoNpsdqSdJnl71OOvLA hZcBN19zjFgLt6B77ExqM5YZ1zPXIWcxEBrgCUGo8vgOyOwzMtC_RXAVQYLCAtBV2CbzM0.a2a.K QNkIkkGiOKzWn5nDiRnArpy7hDXQ_vbMtnSP6JU.hKhmRabOnnF3_f8iIq5ArePCmPPv2QYNB9Io sddoxVUZwmR_Pnex_D9VzMwLNSFbmS3UtOZd92NKPLJn.Kt2W.INiY28K4T8ffXEmb3_dGaGWiGH kMIvDziHJTCiYKg7kZFsV9YlJJHJ5UnGCsbNdl5EO_qbBOr6UJ2i44EC1UJXbtqov.tpMpr43tBs e1gyNvzIUyKkZRY1MOd2dPoTDHtDsQFwmMl09JmLI_QbNcAd97WAmanXORKLtzLsFwqNUIP4NMHC NoI_XEdBpf8nENutmnpF9jZLpKTUKaiaYBg8ncr_dL4gHIVFN188fEw4hkzxzymhwoH_ycLAIzVj WUr_rGNdtlJ0NuQe9J7uSUhIUKHYtMcspGMG1G.7I1uMIkmGwiZ0.7AyrPkv7rSJgXptoDs2KRkF iwcCLvJ_xfRLDpiVC.unZI7LVGtYwu35EC_nN8bycaFRs0xQ.Mxj145rFxPRQAHFNAuw45gf2pwY Ee01TJJWucJB5aZcOUzSs3zbk6LcnMteMNNgXcMDmkgAn7KvAIMXoiEAba5WX2jvb6tBVX.fnJnW 755j4WCS2So9dudG3jwjhJE7VlRNWvCFDz2W2pvvU6OxdbKqCKxdOwJqKGVLdwP5wPz6wg8IV2E6 WqBZl3kakjfizNoze1YinRCvMlxdUsLan1vrb6J4TOWvzvDd2hTnMElR_JaUzPJqqhkcp5TnioOD X7QBywfrON1rLR.434P298bXck8d9HkkvG5jmNggSOMKnMl679CX848Cys6gXZP3mD4sjeA2OT.e vuBzeuuSSCtXy7qlDMsiyxxpGMJoTvWS2._A5aApL0AqqU9qLds5pK07SHSfd9Yqouj2jRLqg23Q 9nCMtc80lmOj1ipJjF.9tKstPdRswpfdVV25_JzpQ_zS5saP_sSV.9BcE6rUoKCL3GR4ZQ1uPOX6 k6NA9aag9i5GdOnKnpNg4kl8SqWlPOTzt5f2tChPE2emtjCXMjHJc8cl3ZCZFu5GavHUJFC2vUSR yeBtxKtdcNFDzVxLL2X4N8m9e60gOjBrF.Q2j8BUtAlsxuCpU0KuIqlhM1b_6JdqvWBHn89qRYR1 b1QYGaaLjrmxLF5CD9e5MBZdDoovirTuQ6bxOnWH84_oX5UM7j_elnC5CIoaBGXEBTvgc0NPljzp 1VjFew86rts624EqRTD0Qmd5v05VZ4EH5h9hIIZ_ph.WzqUIFM1nEzR7UPnlp4TRPvU46Ayu432E UrbPVM8PBB5TFigIgTo554n3NR74AZEU05qW7aKvgmQYBNOqe2j8BdmE1wqn._ulYAdm_JOF0brX KP9O9wImGTOCctmTtaw6h0w1ekujc3dLf0JOzMCSrWSWvrx1vCHytwLexa4KjWqzB0WUjmAo7CDE lyYKt.xyiHwm38lD6vVHcWJgmhriicnk. X-Sonic-MF: X-Sonic-ID: 8dc129f1-8b9b-442c-b983-0e3542f95d70 From: Chuck Zmudzinski To: xen-devel@lists.xenproject.org Cc: qemu-devel@nongnu.org, Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 1/2] tools/hvmloader: implement Intel IGD extended VBT support Date: Sat, 12 Sep 2026 23:27:23 -0400 Message-ID: <20260913032724.62438-2-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260913032724.62438-1-brchuckz@aol.com> References: <20260913032724.62438-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 21770 X-purgate-ID: tlsNG-d62444/1789270051-BFC69757-AAC5C9D0/0/0 X-purgate-type: clean X-purgate-size: 22179 Modern Intel IGD devices do not work well with the current implementation of support for the Intel IGD in hvmloader because it lacks support for an extended video bios table (VBT). Code 43 errors in Windows guests and failure of the guest screen to light up are some of the problems that occur with the current implementation. To address this problem, this patch implements support for Intel IGD devices with an extended VBT and OpRegion version 2+ which is required for most modern Intel IGD devices, as noted in the Linux kernel vfio commits referenced in the Link tags below. This patch ports support for devices with an extended VBT and OpRegion 2+ which was added in those commits for KVM/vfio, but adapted for Xen HVM guests with PCI passthrough. This patch depends on compatible support in the device model. If hvmloader detects the device model lacks such support, it will fall back to the currently implemented protocol for configuring the OpRegion to provide backward compatibiltiy for systems that lack a device model with support for an extended VBT. The primary reason the OpRegion needs to be patched in some cases is that with the addition of the RVDA and RVDS fields to the OpRegion, the OpRegion is not position-independent and may need to be patched if it is moved to a different address in the guest. This means the current protocol of having the device model directly map the unmodified host OpRegion to the guest is not compatible with the requiremnts of the newer devices that in some cases require that the OpRegion be modified for it to be compatible with the guest address space. In this implementation, the device model has the responsibility to read the host OpRegion and patch it as needed before exposing it to the guest. Since an extended VBT means more pages are needed for the OpRegion, depending on the size of the extended VBT, hvmloader has the responsibility to edit the E820 map to accomodate the additional pages needed to contain the OpRegion + VBT. To implement this in hvmloader, use a variable, igd_opregion_e820_pages, instead of the constant, IGD_OPREGION_PAGES, to represent the number of pages to reserve in the E820 map for the OpRegion + VBT. Also, to remove the confusion introduced by setting IGD_OPREGION_PAGES to 3 in an earlier patch to account for the fact that the OpRegion is not guaranteed to be aligned on a page boundary, reset IGD_OPREGION_PAGES to 2 so it matches the actual size of the OpRegion. Instead of only writing to the PCI_INTEL_OPREGION register, first read from it to provide a way for both hvmloader and the device model to discover if both components have support for an extended VBT and more than 3 pages reserved for the OpRegion + VBT. The device model detects the read of the register before the write to learn that hvmloader has support, and hvmoader detects that the device model returns the number of pages to reserve for the OpRegion + VBT instead of 0 when it first reads the register to learn that that the device model has support. When this new protocol is supported by both hvmloader and the device model, the device model will not expose the host OpRegion directly to the guest via a direct mapping as the old protocol does but instead exposes an emulated copy of the OpRegion and VBT using its ioreq server. This has the added benefit of preventing extraneous host memory in the regions before or after a non-page-aligned OpRegion that should be confidential to the host from being exposed to the guest. Testing reveals that when the device model exposes the OpRegion to the guest by mapping it to the device model's ioreq server, the Windows Intel IGD graphics dirvers are unable to access the OpRegion and report Code 43 errors with the result being that the guest screen never lights up. So after the device model exposes the OpRegion to the guest using its ioreq server, make a copy of it and use a copy of the OpRegion and VBT which is backed by RAM allocated to the guest instead of mapped via the ioreq server. This fixes the Code 43 errors reported by the Windows IGD graphics drivers. Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=bab2c1990b78 Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=49ba1a2976c8 Signed-off-by: Chuck Zmudzinski --- The companion patch for the Qemu device model (DM) is available here: https://lore.kernel.org/qemu-devel/20260911072453.46256-7-brchuckz@aol.com/ That patch is part of a larger patch series available here: https://lore.kernel.org/qemu-devel/20260911072453.46256-1-brchuckz@aol.com/ Up-to-date specifications for the Intel IGD are not available to the public but an older version is available from Intel here: https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/opregion-specification.html This patch derives the specifications for the OpRegion that are needed to add support for an extended VBT from the patches to the Linux kernel vfio driver. This mainly consists of the RVDA and RVDS fieds of the OpRegion which store the address and size of the extended VBT, respectively. See the links in the commit message which provide links to the vfio patches that added support for this feature to KVM/VFIO guests for more details. There is an undocumented setting that works in the xl.cfg(5) domain configuration file, firmware_override, that makes it possible to use a patched version of hvmloader alongside an installation of unpatched upstream Xen or a version of Xen packaged by a distro. So one can download the source for one's installed version of Xen, apply this patch and build just hvmloader and then install the patched version of hvmloader with a different filename, such as hvmloader-igd-testing, into the same directory where hvmloader is installed (usually something like /usr/libexec/xen/boot) and then one can configure a guest to use the patched version of hvmloader with one's installed version of Xen by adding a line like this to the domain xl.cfg file: firmware_override = 'hvmloader-igd-testing' The compatible patch for the DM is part of a larger patchset that fixes many of the problems that currently affect the feature of Intel IGD passthrough to Xen HVM guests. This patch should be considered as a companion patch to that patchset for the DM. Do not try to test this patch with a real Intel IGD device without also applying the patchset for the DM because without those patches, the guest will most likely fail to start if an Intel IGD is passed through to the guest. Changes in v4: - Now this patch is the first patch of a 2-patch series - Correct a spelling mistake in the commit message: beneift -> benefit - Added a link to the cover letter of the latest version of the companion Qemu device model patch series. Changes in v3: - The patch has been substantially re-worked. Most of the implementation of support for Intel IGD in v2 that could be implemented in the DM instead of in hvmloader has been moved to the DM. Specifically, the responsibility to read the OpRegion and patch it if necessary is done in the DM instead of in hvmloader. This change is in response to the comments that were made on v2 of this patch. - In contrast to both the current implementation and the implementation in v2, the host OpRegion is never directly exposed to the guest. Instead, the DM exposes an emulated copy of the OpRegion to the guest, patched appropriately for the guest, using the DM's ioreq server. - Hvmloader's main responsibility is to allocate enough pages in the E820 map to accomodate both the OpRegion and the extended VBT. In v3, hvmloader relies on the DM to communicate the number of pages that are needed for the OpRegion + VBT, and this change means all the code in v2 related to discovering the size of the extended VBT has been removed from hvmloader in v3 and moved to the DM. - Backward compatibility with versions of the DM that do not support an extended VBT has been simplified. There is no need for a bitmask setting to indicate support for extended VBT and OpRegion 2 and higher. Instead, the DM learns that hvmloader has support by detecting a read of the OpRegion register before a write to it, and hvmloader learns that the DM has support if the DM returns a non-zero value, the number of pages needed for the OpRegion + VBT, in response to the first read by hvmloader. - It was necessary to retain the code that populates the pages allocated for the OpRegion and VBT with guest RAM and copying the OpRegion and VBT to that guest RAM because testing revealed that when the OpRegion and VBT are exposed to the guest by the DM's ioreq server, Windows graphics drivers are unable to access the OpRegion and VBT. - To remove the confusion with the value of IGD_OPREGION_PAGES that is currently set to 3 to account for the fact that the OpRegion is not always aligned on a page boundary, it has been changed in v3 to 2, the actual number of pages needed for the OpRegion (not including an extended VBT). - Added a check on the number of pages needed for the OpRegion + VBT to ensure the region does not take up an unreasonably large percentage of the reserved dynamic memory range. I also provide the following table that hopefully helps illustrate how v3 of this patch differs from v2: Resource/Description Proposed in v2 Proposed in v3 ------------------------------------------------------------------------------ OpRegion register Emulated in DM Emulated in DM ------------------------------------------------------------------------------ OpRegion Emulated (hvmloader Emulated in DM (guest makes a copy from direct accesses emulated copy mapped host OpRegion provided by DM and and from then on guest from then on guest accesses its own copy accesses its own copy stored in guest memory) stored in guest memory) ------------------------------------------------------------------------------ Extended VBT Emulated (hvmloader Emulated in DM (guest makes a copy from direct accesses emulated copy mapped host VBT and provided by DM and from from then on guest then on guest accesses accesses its own copy its own copy stored in stored in guest memory) guest memory) ------------------------------------------------------------------------------ E820 pages allocated Depends on extended VBT Depends on extended VBT size if there is an size if there is an extended VBT extended VBT ------------------------------------------------------------------------------ If OpRegion needs patching hvmloader patches it DM patches it ------------------------------------------------------------------------------ Setting the OpRegion Done by DM after complex Done by DM with hint register communication protocol from hvmloader which with hvmloader completes provides DM with page base address of OpRegion in guest ------------------------------------------------------------------------------ Changes in v2: - Correct the name of the new function in the commit message opregion_setup() -> intel_opregion_setup() - Add a link to the companion patchset for the device model - Describe how to use the firmware_override setting in xl.cfg(5) to simplify testing of this patch. - Correct a logical flaw that in case the size of the extended VBT is <= 2 pages, an extra, unnecessary page would be allocated in the memory hole. This correction is in the intel_opregion.c file. This code: /* Update the number of pages we need for the E820 map */ igd_opregion_e820_pages = pages_needed; /* * So far we have allocated vbt_pages_needed * and we will likely need to allocate more * pages to fully contain OpRegion + VBT. */ if ( pages_needed > vbt_pages_needed ) igd_opregion_pgbase = mem_hole_alloc (pages_needed - vbt_pages_needed); Is replaced with this code: /* * So far we have allocated igd_opregion_e820_pages * and we will likely need to allocate more * pages to fully contain OpRegion + VBT. */ if ( pages_needed > igd_opregion_e820_pages ) igd_opregion_pgbase = mem_hole_alloc (pages_needed - igd_opregion_e820_pages); /* Update the number of pages we need for the E820 map */ igd_opregion_e820_pages = pages_needed; tools/firmware/hvmloader/config.h | 6 +- tools/firmware/hvmloader/e820.c | 4 +- tools/firmware/hvmloader/pci.c | 96 ++++++++++++++++++++++++++++++- 3 files changed, 100 insertions(+), 6 deletions(-) diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h index c159db3..edc3a8d 100644 --- a/tools/firmware/hvmloader/config.h +++ b/tools/firmware/hvmloader/config.h @@ -8,7 +8,8 @@ enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt }; extern enum virtual_vga virtual_vga; extern unsigned long igd_opregion_pgbase; -#define IGD_OPREGION_PAGES 3 +extern unsigned int igd_opregion_e820_pages; +#define IGD_OPREGION_PAGES 2 struct bios_config { const char *name; @@ -75,6 +76,9 @@ extern bool acpi_enabled; #define ACPI_MEMORY_DYNAMIC_START 0xFC001000 #define RESERVED_MEMORY_DYNAMIC_START 0xFC100000 #define RESERVED_MEMORY_DYNAMIC_END 0xFE000000 +#define RESERVED_MEMORY_DYNAMIC_PAGES (RESERVED_MEMORY_DYNAMIC_END - \ + RESERVED_MEMORY_DYNAMIC_START) >> \ + PAGE_SHIFT /* * GUEST_RESERVED: Physical address space reserved for guest use. * This is not dynamically advertised to guests, so this range must *never* diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c index 86d3954..97a234e 100644 --- a/tools/firmware/hvmloader/e820.c +++ b/tools/firmware/hvmloader/e820.c @@ -243,11 +243,11 @@ int build_e820_table(struct e820entry *e820, nr++; e820[nr].addr = igd_opregion_base; - e820[nr].size = IGD_OPREGION_PAGES * PAGE_SIZE; + e820[nr].size = igd_opregion_e820_pages * PAGE_SIZE; e820[nr].type = E820_NVS; nr++; - e820[nr].addr = igd_opregion_base + IGD_OPREGION_PAGES * PAGE_SIZE; + e820[nr].addr = igd_opregion_base + igd_opregion_e820_pages * PAGE_SIZE; e820[nr].size = (uint32_t)-e820[nr].addr; e820[nr].type = E820_RESERVED; nr++; diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c index c41c8d9..efe6b68 100644 --- a/tools/firmware/hvmloader/pci.c +++ b/tools/firmware/hvmloader/pci.c @@ -44,6 +44,7 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; enum virtual_vga virtual_vga = VGA_none; unsigned long igd_opregion_pgbase = 0; +unsigned int igd_opregion_e820_pages = 0; /* Check if the specified range conflicts with any reserved device memory. */ static bool check_overlap_all(uint64_t start, uint64_t size) @@ -93,6 +94,9 @@ void pci_setup(void) uint16_t class, vendor_id, device_id; unsigned int bar, pin, link, isa_irq; uint8_t pci_devfn_decode_type[256] = {}; + uint32_t igd_opregion; + void *opregion_vbt_scratch; + bool opregion_is_direct_mapped; /* Resources assignable to PCI devices via BARs. */ struct resource { @@ -192,12 +196,98 @@ void pci_setup(void) { igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES); /* - * Write the the OpRegion offset to give the opregion - * address to the device model. The device model will trap - * and map the OpRegion at the give address. + * To be compatible with this interface for programming the + * the PCI_INTEL_OPREGION register, the device model must + * check if the guest reads the register before it writes + * to the register. To indicate to the device model that + * we have support for an extended VBT, we read the + * PCI_INTEL_OPREGION register before writing to it. If the + * device model supports an extended VBT, it will return + * the number of pages needed for the OpRegion + VBT. If + * not, it will return 0 which indicates that it does not + * implement this interface for supporting an extended VBT. + */ + igd_opregion_e820_pages = pci_readl(vga_devfn, + PCI_INTEL_OPREGION); + if ( !igd_opregion_e820_pages ) + { + /* + * This case provides backward compatibility with + * device model versions that lack support for an + * extended VBT. In this case the device model + * expects us to allocate an extra page in case the + * OpRegion is not aligned on a page boundary. Also, + * in this case, the host OpRegion is direct mapped + * into the guest. + */ + igd_opregion_pgbase = mem_hole_alloc(1); + igd_opregion_e820_pages = IGD_OPREGION_PAGES + 1; + opregion_is_direct_mapped = true; + } + else + { + /* Allocate extra pages for an extended VBT */ + if ( igd_opregion_e820_pages > IGD_OPREGION_PAGES ) + { + igd_opregion_pgbase = + mem_hole_alloc(igd_opregion_e820_pages - + IGD_OPREGION_PAGES); + } + opregion_is_direct_mapped = false; + } + /* + * This ensures the OpRegion + VBT does not take up more + * than 1/32 of the reserved region. Also, we must reject + * a value of 1 for igd_opregion_e820_pages. + */ + if ( igd_opregion_e820_pages > + RESERVED_MEMORY_DYNAMIC_PAGES >> 5 || + igd_opregion_e820_pages == 1 ) + { + printf("too many or too few pages (%u) for OpRegion\n", + igd_opregion_e820_pages); + BUG(); + } + /* + * Write the the OpRegion offset to give the OpRegion + * address to the device model. The device model will trap + * and make the OpRegion accessible at the given address. + * The device model is also expected to verify that the + * OpRegion is compatible with the guest address space and + * patch it if necessary to make it compatible. */ pci_writel(vga_devfn, PCI_INTEL_OPREGION, igd_opregion_pgbase << PAGE_SHIFT); + + /* Don't use our own copy if OpRegion is direct mapped */ + if ( opregion_is_direct_mapped ) + break; + + /* + * Windows IGD drivers do not work properly when the + * OpRegion is exposed by the device model's ioreq server, + * so make a copy of the OpRegion and use that copy which + * will be backed by RAM allocated to the guest. + */ + opregion_vbt_scratch = + scratch_alloc(igd_opregion_e820_pages << + PAGE_SHIFT, 0); + memcpy(opregion_vbt_scratch, + (void *)(igd_opregion_pgbase << PAGE_SHIFT), + igd_opregion_e820_pages << PAGE_SHIFT); + + igd_opregion = pci_readl(vga_devfn, PCI_INTEL_OPREGION); + /* + * The device model will unmap the OpRegion from the ioreq + * server so we can use our own copy of the OpRegion. + */ + pci_writel(vga_devfn, PCI_INTEL_OPREGION, igd_opregion); + + mem_hole_populate_ram(igd_opregion_pgbase, + igd_opregion_e820_pages); + memcpy((void *)(igd_opregion_pgbase << PAGE_SHIFT), + opregion_vbt_scratch, + igd_opregion_e820_pages << PAGE_SHIFT); } } break; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Sep 13 03:27:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 03:27:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419481.1646625 (Exim 4.92) (envelope-from ) id 1x5asT-0003FD-0A; Sun, 13 Sep 2026 03:27:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419481.1646625; Sun, 13 Sep 2026 03:27:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5asS-0003F6-TT; Sun, 13 Sep 2026 03:27:36 +0000 Received: by outflank-mailman (input) for mailman id 1419481; Sun, 13 Sep 2026 03:27:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5asR-00035r-Fk for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 03:27:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5asQ-00HW2u-Gm for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 05:27:34 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa617ef-8faa-0a2a0a5109dd-0a2a450783d0-8 for ; Sun, 13 Sep 2026 05:27:34 +0200 Received: from [98.137.65.148] (helo=sonic309-22.consmr.mail.gq1.yahoo.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa61824-b4ea-0a2a45070019-628941948780-3 for ; Sun, 13 Sep 2026 05:27:34 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Sep 2026 03:27:32 +0000 Received: by hermes--production-ne1-6dbcb84f44-w9zrq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 14c5b846713c82b711c43225786a63a7; Sun, 13 Sep 2026 03:27:26 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789270052; bh=HkouYZw2OX7f6dDmS69vbQfS6RgsxVv51DceW+67D44=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=gRqxbTCykPi4d9t+y28sXXjLI8DiSA8TZEqlmAqEJg9+0bIA8D+0QkAVMFHuv5NGjVJziOROO5keW1NQcxHetjsdTHyuYUc+iE02GVmKmRDGmpaHIsN8a5qeb1mf/hW/RLt+19WqvGFRH5fN64IDizUisnQnilmX5lPwyb2TveP0fWYHZeky5TAHKUfyhHm6Wm6CKRO0U6Eg2QIb38d9Qe8p2onZw4pPvKheSzCiFMHalh3HTqFayO1ThZ/H+rP6Hd+EU1IL6x1JyOERfxQzFRxOTEcpZU8sMHDJFRUs6NZ4k1cYCj7rk4Y4HBK6/bhbDZn+t+Qb//+u0z+3CIv9cw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789270052; bh=WbPqrxs+NjO8G6mKw+TZVDB1erA7MoDgNa0UeFFjBXE=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=GpJ+AJeaPJXEuhjRnGmLwuxTkP2DgfRWCrx+Z+Sxmv2kxX3A2SzFsG+tsoRCPG8WYHqAOtGdC6DhlbxgsmKMh0IPgsI8jaha+8KIiWV/VApIaIpRapIf57HKDuXGlZUkMzW56BgtCgbYihgSqHIb8fq1j22rL3IjPmOMYsGO5L9mz6JLooWHI0u85NwFz6+hYtND/st5E92eRqlU3gTo4DFgrHWH6ZS903WutM+p6Hle4/lAKOEGX3ZInxEckNmpF7o3lLwl2UUM9PyMQVhGzVLRur0qRUvNFDSdDVo5o1GJc9ZjrO+SKXq+WHvvJVPE8ZUTkzNp3JLH6flenqPPCg== X-YMail-OSG: iQUPos4VM1mvQ12dnxXVn72jDFlgX72YQvOl4iKHJQZGnSd3noD_KulfJAkrd8e 4vsJPXLEpMK305IR80BrgouKmXQ5OSlkPIJidBRy8WNJVgKgfs2DhLaRLuGCzPWVC8ItW0anBVpG DdUAkWExj5Rqvozx2lgw9L4K09ufYGCJOV634gXBmKjNFMlkkqdNiNkXowKV0Ik7fT8vct98YcDm 7lZZKmAFA3MZZGLLWdzDGSE7LWlDkRu8MG9eUDG6QrJ_itL5yDqy2mFM63b5mgPyzz1cBRodE8ZB oTnzISRYGsIKAZIzIa5f2um24uHmci2QjT4tvrbk0FCcwNXfJIaFgs22bqGuI_3Hw9gu6jUN0NIw oxtvoUTlRh3ViisR.PCCfkLiC0NkyCbordSQWl9CHgCVxz3__4lTqBIDlpZm3zPmNB2MUBR.fJq4 gB2btE5MtemRFbp7gx63uB1O6MdzrCupPCwrz2MBGYPtwFXIKf2vcDg2aKr.w9QPq.wJm33Q9zL. DAH4DQ_0z0GTJHIwSZei0UR11Ns8OTElrjf8qS4thNvlw9DbcsVE1e075ZnAQ04q3ZX8_652GO_Q dGyBo0CvlWqCTLv6z_ykiduyHNDzaOmemmorU6w3AIAcjuEeuNa4xYHwjvIRL0Rg9jlGY7d5totk qYLf_jLVUqhRBqtgjr3H8Zb8gOXKRebdfpGke7gWW6f5RhBnie839wwNJepys_ZnQNbYuuIekNYH 4jokAWg73bhVjpiC8juuXlVp2EDjW84xEj2Sv3iEXtwxrd2W9Bznc3bbfACvGBl5R5_Ng1sihArH 5aXrp3fCn8l8e_my0YzQKNHJu1OcBFPX6Q.iGTBV4gz6e95ecHMuyJvc9wUrou5C_tXAEzOKYlhp 0i3ceCvGZD6pfG6u6xIEebA8aYhAAwi.pus.m6vR8v9DgIGTqfSbAtXxoyOrIMl8VvoFoGbqfhCL aJFduF_1zyLZeJIHeR2QPW0M8SJIF0riEwyWGgmiYOA5qw_yyMxRb2qtsvZVTPRqa_f4exYuJZ9m HpzsJwhXEK82RCzYjVrkN6ejYO_VCnOMMZNB.XXBu.dZwmHCGIiKfGjWEmJWG_wxSPqTSKPUqjsD qcO5W_QwURr90MmeTQLq7yr1fFS0zbz8.dEup1ajAKSf8aEJyQ3XhkFUaFDG_0E0ylrhKE3SyJl7 8Ltlj_KqrX0P5QIX6zhuI6V9Uygh2YSIFOWRSIj6Puox0nYNLEVHmG8LmUVOe_VeLpaaUYoa0wvZ 0HH59Q1_wRgLMH2wHTPMaY6hwUbcOZf8o5ZyN2U7wzadF6WNTieEn8q2FRQx4s8de1wLI69wKasG hKRwQQ6QCRkVgCGkICJ4uZBI3cOEGDqSBJK.yOcoKUe.wJeE3o.xx81H1nKGgO1X1y.a0PHRx_yd qFdLIWrXFo.BzUcxi14UkXbrclt3jvB3BZgViAurf564_BFp8.msHe9PtyY.abbugfxWoLalmxlj WgmWo5hSLYxwatpqnQBrHhWGnGggfIEVP4Wb.Zb2hojPHo3qSJqFt6TlqkIdzcysrtMTDcHbXPZJ zktu7VuGObtg40jkLUPSBkHmUdJcpzAxlgkntCrXEpAMxM3fqQUwiWM0egoSPKpBjjGwZ.Ft4GLe XX6yovJlpqXSZbAAX2NtVNqyaeGAJN_YaWccSn28Q5AOpw_0Aze.NI01OuYaUs6EQMR4BGBKzyLO np54Cexgs51VZcjlwiVlbdjXsO1Wy9S1KjJvGV04t.BAlEenMiX2IMlH7_pj6Th8P4zwkFsAuUJm 4ngouOfOOJJ1pRsiYYVipOYTPLL3Mrqcw6iv3NvZA4M2Ay7uELHcEyCAbZJe9_GQOYA3cmQhFf3T Xc9e85C4Ax4oKRAnayeTRfg_lC7vypG2KdkpyLM6hUzVowTqfm5trecxbcIUvUbDqaSp87lZggcW Qe4yuR1kYVH2VtT8Fmgem29BfFLxTfHluR5nMPYsb9BCrLoUag0mHlE.q1p0E1vYRh2bT28K87J2 LVq2pZHkQ5mDYi8x0sTdLzkg5mNjQ4e5jTQhNc6TAcxyEKqDhWg6hVcGBGtms8cCHh5z3mioI5l3 lOp5w0isi4KRTSA2opCcUUmnwOgAZfLFlLuVROotT.G9Uz_B5AJbWGMNrcZzkhGye7wlNKWcmv0K gEK_FAIh9_bvqnYCIdMD80vE9zr5gLErCgvrVvxCuWqlZt84qkVdxPOU4asIa4H60BSBYJZEL3fq P4NQukyTRxXARHntCXrUxTfcpFwsUqU1Z2rwM X-Sonic-MF: X-Sonic-ID: c76bfcf0-05e9-45f7-a584-afc9f234363e From: Chuck Zmudzinski To: xen-devel@lists.xenproject.org Cc: qemu-devel@nongnu.org, Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Juergen Gross Subject: [PATCH v4 0/2] tools: Intel IGD fixes Date: Sat, 12 Sep 2026 23:27:22 -0400 Message-ID: <20260913032724.62438-1-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit References: <20260913032724.62438-1-brchuckz.ref@aol.com> Content-Length: 1699 X-purgate-ID: tlsNG-ef75cf/1789270054-A68D9AE4-E29C1FCB/0/0 X-purgate-type: clean X-purgate-size: 1736 The goal of this series is to provide improved support for Intel graphics device (IGD) passthrough to Xen HVM guests which is currently not good. It started with a 3-patch series for the Qemu device model and has grown to a seven-patch series for the Qemu device model and this 2-patch series for the Xen tools. Most of the fixes needed for Intel IGD passthrough are in the device model but help is also needed from the Xen tools to provide proper support for newer Intel IGD devices with an extended video bios table (VBT). For the purpose of reviewing the two patches in this series, by far the most relevant patch in the patch series for the Qemu device model is Patch 6. At the least, reviewers of these two patches should also be familiar with Patch 6 of the companion patch series to the Qemu device model that is available here: https://lore.kernel.org/qemu-devel/20260911072453.46256-7-brchuckz@aol.com/ For further reference, the link to the cover letter of the latest version (v6) of the companion Qemu device model patch series is available here: https://lore.kernel.org/qemu-devel/20260911072453.46256-1-brchuckz@aol.com/ Please refer to each patch in this series and in the companion patch series for the Qemu device model for further details. Chuck Zmudzinski (2): tools/hvmloader: implement Intel IGD extended VBT support libxl: add OpRegion and VBT to firmware when assigning IGD tools/firmware/hvmloader/config.h | 6 +- tools/firmware/hvmloader/e820.c | 4 +- tools/firmware/hvmloader/pci.c | 96 ++++++++++++++++++++++++++++++- tools/libs/light/libxl_pci.c | 82 ++++++++++++++++++++++++++ 4 files changed, 182 insertions(+), 6 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Sep 13 03:27:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 03:27:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419482.1646635 (Exim 4.92) (envelope-from ) id 1x5asW-0003TR-6X; Sun, 13 Sep 2026 03:27:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419482.1646635; Sun, 13 Sep 2026 03:27:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5asW-0003TK-37; Sun, 13 Sep 2026 03:27:40 +0000 Received: by outflank-mailman (input) for mailman id 1419482; Sun, 13 Sep 2026 03:27:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5asU-0003Rk-5h for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 03:27:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5asT-00Cx8K-Ix for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 05:27:37 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa61794-2eae-0a2a0a5409dd-0a2a4509c456-28 for ; Sun, 13 Sep 2026 05:27:36 +0200 Received: from [98.137.64.146] (helo=sonic301-20.consmr.mail.gq1.yahoo.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa61827-be1a-0a2a45090019-628940928ec7-3 for ; Sun, 13 Sep 2026 05:27:36 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Sep 2026 03:27:34 +0000 Received: by hermes--production-ne1-6dbcb84f44-w9zrq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 14c5b846713c82b711c43225786a63a7; Sun, 13 Sep 2026 03:27:28 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789270054; bh=Hevw5B+Wr7DTBK/0kWmrMKgRnH/bAgiz5/Fykn/Eyuo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From:Subject:Reply-To; b=uY2lp5G1atnaUMVr0UscmeYJdwP0iwLvqcIb5ek5Yx7Jk04f2MuLHly8JbL038h+Dz5j6g00HJB53lMFolBUFiKDhenuE7OiftMW4oGSWCLXAz/rgz7srt4ORRoMNHPi0ZyUYUHbULJ5saf9Vmel1wTVrZqa12gn3FCD82QDCTz5cfPK8ItEOP60DItPbd6AUkxKy6VEn3phhH2oZiyDtcc7yvFT+duXFP5c7u7QuWVdHnTVaBpvidn4Jrmd2ksOS/OPudnFvgKG5IR4TkWbz+t8alo65i/KFbd0p3VcgElxW/LJNaHDOlJ68pMhM9HaNhMVtgb0IbEKtRsAyanuAQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789270054; bh=L/S97QuLM5PBrc49OcJhPUSRtUyjGcV/+NyI/8Pj037=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=UFQlu9zugYRcYYk+bet5IhgBoCs09GbijWWiC0cZ6E4Sa9RvGmLfeVf0VGi4FEOq4hhKDCRB7wyiPNeE4uNy3FpOKw0sCO1YxrKHRv2cI3YV6cQWjaKbhEc9OVuJE+WYVkDwe+ddLqhCb2dF8kreSccF+saeBDml0OOnhX/SrUhDjd7nUGmZCeYpNx/7nDa+cqOXgdS6bz8yKG1tXmzxkmXhOy5NmD/+bPhVP6NV3rE/8ztPXeC28PY005Mc/HelGrHw7+dLLFrfWygeyptEofMfbo8+R47yId1S8Fj2xA3T1e/R/lMBz46PbOLt4UzgwmHiym0Q5nTOtru6DLahtw== X-YMail-OSG: MABzF34VM1kLtJmAr1eV5IlNnii6cA6572ltl2Ut9a2FKZEgqP8dpOG53E35F9Q MMEkiElQEqUu3q9MJtkEUHjtnWQGqJXvzvWvnnhuyXVfbrX0CWnnmJeGgTU3W48tLC2Z5X8S8xwB wGiEsHHWI3zf0txp_8LyQB52YzEjUFuGqIq7DWtsmYzm7DKGcpYT8jqd223hI3sjQcx5Qa9krlIL diwlzVjPA3_uB.lDeyGeeG8NTRCATq.YYg7OtOr01JR1I13zeW.5wdAIpF79ssQKbIQ1Gj0ylNtN hF4tsLDZtSr4HjNOTuD6x93jdODa3YUpCS9QuURhjELyJw8T9YXnwyfIM.CrKtCrqazvPx.d6lhE SOoUBFuA80Uy4YAKxqFvM1hadL1XahH1My_bHZ4QVfYCrgaAoX0YaR_7rpMV76tPjs4_z9LvHwWC reRq54QDMluMPyQUUO4GFzEpCS3G7VVZNlJvJt8AcjsR9U1sLZZJ0qdR1t9HfGSRJOddPTXlX0Ts LEVKkb8ZoQqg0HjU_F3SuV.xHs2nC8W.TVgGQMGEHpV.6.0CDJxOH1kDfM5VIKbEzpiYrUuuSYkU ydUVqIzlrUcw9gXtAUFrDdTl9G6JQ_5U0b4MDQYm32K98Ub5GGk9kJy0wkV2udEO8QjpCT1DhTqR 8sU0L7AvFTu.SpydNBvHhVeDJFQDAoharDvTz8dQmJI5ha1j0Ay8PsXB00y82mjAglPsXEZ4oPjD SJRVM7MFYtlpths95YmXGJYMGHw78PPsBKxvfUYJnvzx8u3hYRqK4UjLwWz1caWG1DRSdDtVkNNQ .7Km9kc43nQcFKm2ToSTaaKaAMuu7N8ThN14KUHv2r37BEtXJHbG.vyClLPoyMhLfyARdkC9A7WZ 2rxniiviN8w_P7WSrQxZyglyNIKqIByvI4lptHSLCmF_miPu27BEQNcNYyDPyqhMGtHCmBSy.dsM gecEXRynxPBOAlCTKeQLQ3A6RM8_TLq4yb7CzLzqoB3IlZFWbCa7kR7r6OYLiFR7Dt8K8fO9yyRl czxC0t06WLjcjuJK_uZbBTcFRjUWEIwyGKVfBDHUomVCyyGG1eY4nllRLbIMkz2ECuT2sAEl8l3j 5UoZ17yWD4CRB0RLXDljPBroJKW3AOD2yhzfcxdX2Ak89evT3sdeXzCTWhtT1e8PcZmw7n2wDHz_ 0Sgn7Uu4bWSAdwpALaFqBEyD9BFFfQzfXsNulmf1QqyqKcpR1SIpxr3HyPL0D.ZqAFWC0AVX0jm. AVvvCwQtN7briAtzjGJ_CNL8qrZZz.OZh.q3EjYedFjFfY_Mq7jHn8DHWqIQM1v_kzl_NSAxn_H0 cjyqFy98NgcCDhd9_3r86H6NSkt6g9j2OZ3aX8j_x.MwGbAGD_qHiJnHH4ToQMJdTZgItsRddjm9 j_g0Y7fttDMw8PlYJMNw4SlPemyURDpQGUUY2YWTyDjQFqk9b8zbMcSv6WE_P5AtOsZjRy_aFWB3 UbRceVrRb6MpxiN6JBp3GQACgBE9Hh6l52osbv1ybWa2VXEqfsUr2AS6aWJfUWE4RAm5VIru49Xa prVQjhXynxxi1c3K2Nd1fOzbEgJrHPSxCaGC2KJ.yrtUtmVogp_CXA8L475NMxZ4lNxrkKnZiWVA Rx_i56tvlWWmzvTRBB61k1FPgjnd2pqcVAmx5ypcds2bLaB4puHzS6_St2joQ2Cc5mnkoJtTL4p0 5tkOzdFr3Tv1.efS8bxZAmiW1L.K0ZQIdbFmg3R2RBU4GyZsczCsEMJssfHoq5KbfIEB6UpocOmt SWOP38VFcWk3._iVmVFv9X7UF.edlDzXbwNOZ0Ed6Igk5HoSPTkrNu4ARCFGS5PtKsfXWwFuYVJR 3LCAzeqg3FtCJGzu.ymwnpxwqtS.88ksc152oaa99FT5K5k0n9FAJB_ORVYbYJukgjjaxTPaAXES Opk0xGvy3SjlKpZ0_mPDqij3SjJkTqgvBQ.v3oLXtr4XFHVIu18mdOCYLcb0bj6pH8kae8Zti1wb WFxJaYpUB2ztgxGxoXpllYRp5GmcvgBc3tTBFWGMKbRw_GaHxR89xb5NWXtInszNSwR0NYHOxi8o b4rs5n5Oc.zlbbBasnOhvphFbVK9.A6YN_fZF4Zgu.1gsFN.f6EVRseumFdKgN2R.yh6iM6.pD5o znmoIKD96PiOmj6L9lebFHVejVFSSG10uLMZBp7tm.9ZQgRxgJ3WzZ3o88_.kXzbeBZAlhVLY_Tq D..zwK7DEpCKjGU..8rRyQAP2P8fAQ14GJ9M- X-Sonic-MF: X-Sonic-ID: 25657ca0-4f28-40f3-9cdb-11cc86d67d9e From: Chuck Zmudzinski To: xen-devel@lists.xenproject.org Cc: qemu-devel@nongnu.org, Anthony PERARD , Juergen Gross Subject: [PATCH v4 2/2] libxl: add OpRegion and VBT to firmware when assigning IGD Date: Sat, 12 Sep 2026 23:27:24 -0400 Message-ID: <20260913032724.62438-3-brchuckz@aol.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260913032724.62438-1-brchuckz@aol.com> References: <20260913032724.62438-1-brchuckz@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Length: 7624 X-purgate-ID: tlsNG-bad1c0/1789270056-BD4C3034-45F313F0/0/0 X-purgate-type: clean X-purgate-size: 7795 To provide support for newer IGD devices with an extended video bios table (VBT), the device model needs to access the host OpRegion and VBT when the IGD is bound to the xen-pciback driver but the Linux kernel only exposes them in the debugfs when the IGD is bound to the i915 driver. Although the OpRegion and VBT can be manually copied to a firmware directory from the debugfs to a directory where the device model can access them when the IGD is bound to the xen-pciback driver, libxl can do this automatically by copying the OpRegion and VBT from the Linux debugfs to the Xen firmware directory before unbinding the IGD from the i915 driver. Since the copying of the OpRegion and VBT are not required for the device to be made assignable, don't return an error if the only error is that the attempt to copy the OpRegion and/or the VBT to the Xen firmware directory failed. It is necessary to read the RVDS field of the OpRegion which stores the size of the extended VBT. We cannot rely on stat(2) for this which returns a value of 0 for the size of files stored in the Linux debugfs. This patch relies on lstat(2) only to determine if the OpRegion and VBT files already exist in the Xen firmware directory. If the value stored in the RVDS field is 0, then there is no extended VBT and the VBT is embedded within mailbox # 4 of the OpRegion, in which case we can assume the size of the VBT is 6 KiB. For users of the Qemu device model, if the Xen firmware directory is not configured as one of the Qemu firmware directories, the "intel-opregion" and "intel-vbt" files must be moved or copied to a Qemu firmware directory to provide proper support for an IGD with an extended VBT that is passed through to a Xen HVM guest. Signed-off-by: Chuck Zmudzinski --- This patch also depends on the companion patch for the Qemu device model available here: https://lore.kernel.org/qemu-devel/20260911072453.46256-7-brchuckz@aol.com/ There is not an up-to-date specification for the OpRegion and VBT available to the public online but an older version is available here: https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/opregion-specification.html Despite the fact that we do not have an up-to-date specification, patches to the Linux kernel i915 driver and the igd-related files of the Linux kernel vfio driver provide enough information about the specification to provide support for the Intel IGD in Xen HVM guests. These patches to the Linux kernel vfio driver were particularly helpful for this series of patches to fix support for IGD passthrough for Xen HVM guests: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=bab2c1990b78 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=49ba1a2976c8 Many more details about the support for Intel IGD passthrough to Xen guests is available in the other patch in this series and the 7 patches of the companion patch series for the device model. Please refer to those patches before asking questions that might be answered by reading through those other patches. Changes in v4: - This is the first version of this series of IGD fixes with this patch tools/libs/light/libxl_pci.c | 82 ++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c index 49d272d..ff28387 100644 --- a/tools/libs/light/libxl_pci.c +++ b/tools/libs/light/libxl_pci.c @@ -25,6 +25,9 @@ #define PCI_OPTIONS "msitranslate=%d,power_mgmt=%d" #define PCI_BDF_XSPATH "%04x-%02x-%02x-%01x" #define PCI_PT_QDEV_ID "pci-pt-%02x_%02x.%01x" +#define PCI_OPREGION_SIZE 0x2000 +#define PCI_OPREGION_RVDS 0x3c2 /* offset of RVDS in OpRegion */ +#define PCI_VBT_MBOX4_SIZE 0x1800 /* PCI Interrupt Line is an 8-bit value, 0xff means disconnected. */ #define PCI_IRQ_LINE_LIMIT 0xff @@ -765,6 +768,17 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc, const char *name; int rc; struct stat st; + uint32_t rvds = 0; /* Intel VBT size */ + int fd = -1; + char *spath1 = NULL; + char *dpath1 = NULL; + char *spath2 = NULL; + char *dpath2 = NULL; + uint8_t *buf1 = NULL; + uint8_t *buf2 = NULL; + uint16_t pt_vendor = 0xffff; + uint16_t pt_device = 0xffff; + unsigned long class = 0; /* Local copy for convenience */ dom = pci->domain; @@ -797,6 +811,74 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc, return ERROR_FAIL; } + pt_vendor = sysfs_dev_get_vendor(gc, pci); + pt_device = sysfs_dev_get_device(gc, pci); + + /* Check if the device is an Intel IGD */ + if ( pt_vendor != 0x8086 || pt_device == 0xffff || + sysfs_dev_get_class(gc, pci, &class) || + (class != 0x030000 && class != 0x038000) ) + goto skipigd; + + /* These filenames match the filenames used in the device model */ + dpath1 = libxl__abs_path(gc, "intel-opregion", + libxl__xenfirmwaredir_path()); + dpath2 = libxl__abs_path(gc, "intel-vbt", + libxl__xenfirmwaredir_path()); + + /* Check if the OpRegion and VBT files are already present */ + if ( !lstat(dpath1, &st) && !lstat(dpath2, &st) ) + goto skipigd; + + spath1 = GCSPRINTF("/sys/kernel/debug/dri/"PCI_BDF"/i915_opregion", + dom, bus, dev, func); + spath2 = GCSPRINTF("/sys/kernel/debug/dri/"PCI_BDF"/i915_vbt", + dom, bus, dev, func); + + /* + * Try to copy the OpRegion and VBT while IGD is bound to i915 driver + * but don't return an error if one or both of the copies fail. + */ + if ( !lstat(spath1, &st) && !lstat(spath2, &st) ) { + fd = open(spath1, O_RDONLY); + GCNEW_ARRAY(buf1, PCI_OPREGION_SIZE); + rc = libxl_read_exactly(ctx, fd, (void *)buf1, PCI_OPREGION_SIZE, + spath1, NULL); + close(fd); + if ( !rc ) { + fd = open(dpath1, O_CREAT|O_WRONLY|O_TRUNC, 0644); + rc = libxl_write_exactly(ctx, fd, (void *)buf1, + PCI_OPREGION_SIZE, dpath1, NULL); + close(fd); + if ( !rc ) { + rvds = *(uint32_t *)(buf1 + PCI_OPREGION_RVDS); + if ( !rvds ) /* VBT is embedded in the OpRegion */ + rvds = PCI_VBT_MBOX4_SIZE; + fd = open(spath2, O_RDONLY); + GCNEW_ARRAY(buf2, rvds); + rc = libxl_read_exactly(ctx, fd, (void *)buf2, rvds, + spath2, NULL); + close(fd); + if ( !rc ) { + fd = open(dpath2, O_CREAT|O_WRONLY|O_TRUNC, 0644); + rc = libxl_write_exactly(ctx, fd, (void *)buf2, + rvds, dpath2, NULL); + close(fd); + if ( rc ) { + LOG(INFO, "Failed to copy VBT"); + } + } else { + LOG(INFO, "Failed to read VBT from debugfs"); + } + } else { + LOG(INFO, "Failed to copy OpRegion"); + } + } else { + LOG(INFO, "Failed to read OpRegion from debugfs"); + } + } + +skipigd: /* Check to see if it's already assigned to pciback */ rc = pciback_dev_is_assigned(gc, pci); if ( rc < 0 ) { -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Sep 13 05:36:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 05:36:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419538.1646645 (Exim 4.92) (envelope-from ) id 1x5ctD-0003rX-U8; Sun, 13 Sep 2026 05:36:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419538.1646645; Sun, 13 Sep 2026 05:36:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5ctD-0003rQ-QJ; Sun, 13 Sep 2026 05:36:31 +0000 Received: by outflank-mailman (input) for mailman id 1419538; Sun, 13 Sep 2026 05:36:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5ctC-0003rK-Vh for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 05:36:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5ctC-00FLur-1l for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 07:36:30 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa6365d-e002-0a2a0a5209dd-0a2a4503c1dc-2 for ; Sun, 13 Sep 2026 07:36:29 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa6365d-fae8-0a2a45030019-4a7de48ce250-3 for ; Sun, 13 Sep 2026 07:36:29 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c2940ef15d3so151912466b.2 for ; Sat, 12 Sep 2026 22:36:29 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2966066b75sm264030566b.29.2026.09.12.22.36.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Sep 2026 22:36:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789277789; x=1789882589; darn=lists.xenproject.org; h=content-type: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:content-type; bh=x33SXcGKJZwybp329vf09l/E4GjWsK3N79Z1GJxL4P0=; b=LlYXKMk/jIRgTfafyLrBI6QkNqAAcF7wAOGxwRFzB7dAXdyF/WdHvGgj6SPKLh7/dy RKVRO2XSLO5uYmV6IdbJJdsoB8mo7KGF7fILyUT3Ik0xMDnbQVcgthFf91LOQqGMaQVY 3DDDeRexrmUqntGE3NEH42QFtKRZYHiyxK1i66hqdiwLQCo6mobpjz8Vu1PYf1xq2vq7 EiliRxUSNcQU5u7pJ+qIjEKIaBPEEJVlI0JqiNJVt96NYgW/2qj6VRpQ2Hbc2Dw8E0pd INiQhJL5UQwGKbbFGvO52AVe6m1CRjUSLJ9hlmhdETgxYSwaB4zm7U+YYY2d0S7HdOJT pycw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789277789; x=1789882589; h=content-type: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 :content-type; bh=x33SXcGKJZwybp329vf09l/E4GjWsK3N79Z1GJxL4P0=; b=L7ODPhtBNp6aq15x+h0fQ++JcvTvsBUBWV0Zud5aLxuYsWLugEOBcnO8cE1o4uVe4P 3ey71ZceSYPgIjJjpEBl8r/usXC+B4LjC+8BJha5Noxb721k8mnVsNh6GXNyhZ28pMP5 ODSw3zTW2+YHN4AHwaAZoUMsA5F+7oOJc8BLVwyH7bcV+CS0eTeGatxEMypKBRTTyKFG z5b6Mduz7bfpGP7HBK98ILiRkI4r0UV2L3GDqWpJYMkBqbL9Z3EG6D8jlJNPkDWwVyHA OlUbyAK5McQJXIi1q8M12SCQHVNJvJQ0pMPxCYAhwsU8XmvB3knA/KOn4cvSywyG616i JOCA== X-Forwarded-Encrypted: i=1; AKwUvBzOlB8bGDC4Xn7WV1yKdWxu4AO6mwqgTDn9Cjg3NCvdBwTA6fwWLFvulOm92qCK+y4EYatqnBft+hc=@lists.xenproject.org X-Gm-Message-State: AFuF++mkPmLH+R8kAL9YuHOAZ1pQiCKcHE7azQv/uBKHGPddpYG3a1vu Qj3kYqSff9vK+4aYKJi9/1MLXQkyuhXFhSJWZP0iuQgI+HP+mUg3uXUDbrEteTokqD0= X-Gm-Gg: AYBFou0bsELL05th6or69o09e7BuLfqakoicB1RQEdzY3cKd5ydQrVtf4GP1YIMgNcA VXQeTkWlrc2CZoRsRQdCyd0COldpFeMGQ1AZrehP4cugCvBqV4Io4HGZTFWAv7V8/keZrwj+KMt ETEkmOmlTfOw5G0y6MSpxwoXDg3206bkk55bgxKwzsE6mjhPpGLjKPCCjsJCkyggRK5buqyBDER YcOAm26M6FzoS0v6SBVVaSbYDOXPHjTjoix0HDrkJXUUYHPkPrm+DSLgXF/x4wa1wiDDLfp8AMI pH0DDkRcAX0/Me+kS2WDjgNaz8h83fsJ0aIGGszpQ0amRfA4dzPOyrauhKdAuhO5M7RB5QLqSMS 0vr9itaewo/kNHq8clR6waAhe5fb7quCtN00dG3Gszv6AGp2VuQYkUukCqg/H8ctTwwjgmhv9LD QBCPI81BM22//dI2vPf2tHFgOpb5kfLmMA4Tdc8tF1qbu2SkVqITZ80FP59IBprpGjPA7TxNPrg gyAyC5L4+SZvFTy6j71C/scVEpYFajNlOTVnjWqNbDblNnsScddhb/MwL1218W4oyD+mEZWJyLi mSLRwF2MItWyqaAEwuhAoTmA X-Received: by 2002:a17:907:e895:b0:c20:1bc5:7002 with SMTP id a640c23a62f3a-c29665414f1mr1041706166b.3.1789277789216; Sat, 12 Sep 2026 22:36:29 -0700 (PDT) Message-ID: <170d06eb-5cc7-41f0-a0e0-0eeca77307c7@suse.com> Date: Sun, 13 Sep 2026 07:36:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 12/13] treewide: convert rdmsrq() from a macro to an inline function To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= Cc: LKML , x86@kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-fbdev@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Damien Le Moal , Niklas Cassel , David Airlie , Olivia Mackall , Herbert Xu , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Linus Walleij , Bartosz Golaszewski , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Arnd Bergmann , Greg Kroah-Hartman , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , Helge Deller , xen-devel@lists.xenproject.org, linux-geode@lists.infradead.org, Michael Kelley References: <20260911074530.3140830-1-jgross@suse.com> <20260911074530.3140830-13-jgross@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------eaM1imaen800kHMvvuISziE6" X-purgate-ID: tlsNG-33051d/1789277789-6EACC4E9-536B3C0B/0/0 X-purgate-type: clean X-purgate-size: 10620 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------eaM1imaen800kHMvvuISziE6 Content-Type: multipart/mixed; boundary="------------NEp702byBysSRAjr2vYU7iXA"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= Cc: LKML , x86@kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-fbdev@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Damien Le Moal , Niklas Cassel , David Airlie , Olivia Mackall , Herbert Xu , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Linus Walleij , Bartosz Golaszewski , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Arnd Bergmann , Greg Kroah-Hartman , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , Helge Deller , xen-devel@lists.xenproject.org, linux-geode@lists.infradead.org, Michael Kelley Message-ID: <170d06eb-5cc7-41f0-a0e0-0eeca77307c7@suse.com> Subject: Re: [PATCH v3 12/13] treewide: convert rdmsrq() from a macro to an inline function References: <20260911074530.3140830-1-jgross@suse.com> <20260911074530.3140830-13-jgross@suse.com> In-Reply-To: --------------NEp702byBysSRAjr2vYU7iXA Content-Type: multipart/mixed; boundary="------------JHou3VyeAHLBdBUp1ZKQPjhy" --------------JHou3VyeAHLBdBUp1ZKQPjhy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTEuMDkuMjYgMTE6MzcsIElscG8gSsOkcnZpbmVuIHdyb3RlOg0KPiBPbiBGcmksIDEx IFNlcCAyMDI2LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPiANCj4+IFRvZGF5IHJkbXNycSgp IGlzIGEgbWFjcm8gdXNpbmcgaXRzIHNlY29uZCBwYXJhbWV0ZXIgYXMgdGhlIHRhcmdldCBm b3INCj4+IHN0b3JpbmcgdGhlIHJlYWQgTVNSIHZhbHVlLg0KPj4NCj4+IENvbnZlcnQgcmRt c3JxKCkgdG8gYW4gaW5saW5lIGZ1bmN0aW9uIHJldHVybmluZyB0aGUgTVNSIHZhbHVlLg0K Pj4NCj4+IFRoZSB1c2VycyBoYXZlIGJlZW4gY29udmVydGVkIHVzaW5nIHRoZSBmb2xsb3dp bmcgc2VtYW50aWMgcGF0Y2g6DQo+Pg0KPj4gICAgLy8gT3B0aW9uczogLS1pbmNsdWRlLWhl YWRlcnMNCj4+DQo+PiAgICB2aXJ0dWFsIHBhdGNoDQo+PiAgICB2aXJ0dWFsIHJlcG9ydA0K Pj4NCj4+ICAgIEBADQo+PiAgICBleHByZXNzaW9uIG1zciwgdmFsOw0KPj4gICAgQEANCj4+ ICAgICgNCj4+ICAgIC0gcmRtc3JxKG1zcix2YWwpDQo+PiAgICArIHZhbCA9IHJkbXNycSht c3IpDQo+PiAgICApDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogSnVlcmdlbiBHcm9zcyA8amdy b3NzQHN1c2UuY29tPg0KPj4gQWNrZWQtYnk6IERhbWllbiBMZSBNb2FsIDxkbGVtb2FsQGtl cm5lbC5vcmc+ICAgICAgIyBBVEENCj4gDQo+IEFja2VkLWJ5OiBJbHBvIErDpHJ2aW5lbiA8 aWxwby5qYXJ2aW5lbkBsaW51eC5pbnRlbC5jb20+CQkjIHBkeDg2DQo+IA0KPiBXaGF0IGlz IHRoZSBwbGFuIGZvciBtZXJnaW5nIHRoaXM/DQoNCkluZ28gd2FudGVkIHRvIHRha2UgdGhl IHdob2xlIHNlcmllcyB2aWEgdGhlIHRpcCB0cmVlLg0KDQoNCkp1ZXJnZW4NCg== --------------JHou3VyeAHLBdBUp1ZKQPjhy Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------JHou3VyeAHLBdBUp1ZKQPjhy-- --------------NEp702byBysSRAjr2vYU7iXA-- --------------eaM1imaen800kHMvvuISziE6 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqmNlsFAwAAAAAACgkQsN6d1ii/Ey+b zwf+OzaU6Petyp2h+7lmUlJdSjc0eGdEi1rB0ocVzj1kZHlAYaJJchfEYlr+cy0jrRbAJUqhocOe c/DNBw8RSCwubb6xG6QmMEUtKIZLM+wjc/7U/S+ijRfm4cSHAnOr3Vh6jffSSW0G96X5SzsCpC5v vC2SBDQjyP+kgsXS4vGBrhBzRC4SXsIHwOmVNJWDkTlpnzTh0joIXofqOrNHKQMcGuBpxJCHDYSL NkUzegBFSRDKWDqtEOP5DrbpgeJEve03txe84l6HRyCVozjsba1pS2fehrmMh9+xRi40lMnxGRKq EiFbizqDTM71Fgp15B9MKWAg+6FGtcM7TKtwsc/reQ== =agVt -----END PGP SIGNATURE----- --------------eaM1imaen800kHMvvuISziE6-- From xen-devel-bounces@lists.xenproject.org Sun Sep 13 07:37:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 07:37:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419584.1646652 (Exim 4.92) (envelope-from ) id 1x5els-0002Zd-9L; Sun, 13 Sep 2026 07:37:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419584.1646652; Sun, 13 Sep 2026 07:37:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5els-0002ZW-6D; Sun, 13 Sep 2026 07:37:04 +0000 Received: by outflank-mailman (input) for mailman id 1419584; Sun, 13 Sep 2026 07:14:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5eQ4-0000A3-WA for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 07:14:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5eQ3-005Q82-R2 for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 09:14:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa64d52-bab6-0a2a0a5309dd-0a2a4503e2ba-2 for ; Sun, 13 Sep 2026 09:14:31 +0200 Received: from [74.125.224.141] (helo=mail-yx2-f13.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa64d56-fae8-0a2a45030019-4a7de08d80de-3 for ; Sun, 13 Sep 2026 09:14:31 +0200 Received: by mail-yx2-f13.google.com with SMTP id 00721157ae682-85d46e4cdccso8924457b3.1 for ; Sun, 13 Sep 2026 00:14:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1789283670; cv=none; d=google.com; s=arc-20260327; b=bfGHUUbaKpeKKEibrx4ZV3kNWW3mp34NrBOlonDT1OMCtIgNYTdxnrk3aZqknr3v1B OVoBIIdraqQ3IwXQ4JNVMDeRmroSgcEv2Rm/zFlIznvuLtYehOIGzrjBO2JjA3BuxOzW uVoMOXeb8HDc859h4KGZ8+l55kotkQ4xFNkQ0SQJHY2cyjBtOx/VMLhf849E/qu5jzW3 zVE18WUZ3L4q7c/nQAoD11aDCbBZszCzWr2v/lxf9+2wVaXM5uHx2x9ScqXnzkTCe8ce F87v8hg8m3+2nTTFAquOel6cqDTToW+z4RfhwAfEGae5UKOMVQdvGL0HP3z9JK3YmgKH Yi9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hs7PCl8ZdlMvhgHWX0PHVYVp8DWBXv1h24H33tOaVTY=; fh=m08vT+s2b1PxF6dAwLYJQ8biGihQSPDr46PCCOGul4E=; b=SpBKH6xdG3dBn8qlirwh7ojHid1jDDaNwB+Qe4OAYgJAUqHOIFTeY6HkQ+e/+ruJdE xDUUaP3ohgyUSSoHiLbeqqm3TpH9iqJuG/AxFZQC4/fuDTKTKSfPLr/sW/SnB8EzTZV7 +5894WE62+sexccC4pZEJn7nN//ZseVyh6O8d9rkAjWqGWKPW0O5gWV3cS38Wu8INMT8 YxgRHm25i1HPUnnQaOki0mWbZSzDA0hkNlrLMiyjENWg0gY1Y9etbJWbcg2nzxIUvJ0f QQFmEJr4aVZ1CUsQlQeZAmOXzC0YIPioLr7N847VxaHJCJtFkjZqZVD0zFSipH2D/CVX kJ2Q==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789283670; x=1789888470; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=hs7PCl8ZdlMvhgHWX0PHVYVp8DWBXv1h24H33tOaVTY=; b=f+ve+hcPgdWGt+p6KIti3tiVPnkcAKB+yjb6aM2CziY/hLe2jpyzIxa3T12OKQwn1+ ulF2f22ghdtF8vTqW/Oe5LgapCkvM/wyJAO3eTcJAoV8RjIjOC7vvKJnFkbtCfyaghST G9BrB7LEMHpIPxNSBp3/wXWdOZ1Y/VuK1WH+r+3QOD1EN4fk/fjzFmHiPrjCkPU/FsL7 YZbT6UREuxrjrmuW860ad54pwad2zeWpmBQy82cAfSuCty59sNzQC9DIXqDwlwfycsmM pfLF4FSp4Mf2BnpxWZVDaDesDcEWbKJn29a824VDCoXKVA+l0dscwr/oAVX6GmkRmm6s gJBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789283670; x=1789888470; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=hs7PCl8ZdlMvhgHWX0PHVYVp8DWBXv1h24H33tOaVTY=; b=fyGiyx8JjsMmaeRB+GeEiV1rHgsJI/2t5k32sOW4uYCBKCNEIpCY6ieaFXRaI0gC5L l15C5C0k8hdATgkEg3hjscOX3p3RYUcNnxAlMkFlYmvsNnQ19VVii6vm1UnBF9iw6VbW WrlCFxghVr1PEganOR4pH37TMtnx4BdsZkFWpNAnW00MslyVo1+mSiP48zlkHzOza9KU pK6jQMLcKKVET+iX3h48yAs2eRfaT/AUXT10YcgEGiaX85LzKm8THZS0dVc4k+hTlBRf ds3PTJ5ix5HUtTETDEev7TuiS2x1JD2VPlNzn4LO3EGj1Bh6Ao/APCTLM733+sjLE3Ps /f4g== X-Forwarded-Encrypted: i=1; AKwUvBwLI8vOT2pyeaBxwQ4gniMsOv4wTIO4U/tEeYtg84FKDvfT77mrG2ZiaLFg/oNkF/VsTSEli1WmVz0=@lists.xenproject.org X-Gm-Message-State: AFuF++keI7+K244JlBBhA30O6pa4oS68mESQ29yLuQUt1rP4VyIvd+bU ggNnnKkVAHEAYXyrsNwwtPGQwXTolvzrVz+VnzZQCMTZWKa1o46H3vjTGhI2V3KnU6dRY1nlsxL VYDHMQiSDYg9KCVBEfB5gMrGp0ohvDuQ= X-Gm-Gg: AYBFou0Ch0tfLI575PRUKiHYFiaxPsYIJLt2VimDQqHmYAP/VdUEUsROMFHmDd0JfPL MKd4nq2c4qhp5vUqJ1TJJrbxq6/jowcd6ow7KvKjxjpxnG0TicFPXXJcbi6nE/IqceMuV3XjvlS pUaRhPESYGC1F6472aGUHaD2qPCJitXwf0Ir92Hi+FPE2/HtyGC2iVzfYn7QDwDogbzDXZCPqnc PIZCKINItZRcHY/Zx+Xw4NZ27jNqR5027MlpqVA0nZ9GR/r8DYW9SlOaltPd/PME6L63aY+yM8D cLx9NaVKoovNzN2RqYFdo7aHuSQMGJQnUWuDDwpoSeJxagViFvHcvXfjsNxCgxBI2CsNT1P2Lfu SGt1momrw1/v7 X-Received: by 2002:a05:690c:e3cd:b0:87f:a9c6:470b with SMTP id 00721157ae682-884ae7afba1mr42342687b3.2.1789283670033; Sun, 13 Sep 2026 00:14:30 -0700 (PDT) MIME-Version: 1.0 References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> From: Yafang Shao Date: Sun, 13 Sep 2026 15:13:54 +0800 X-Gm-Features: AcwNN1UspbNtkItJTCvCtD3l6jewbKb17CHUZA9TTmeWwkQ5AKSxYWpYJfiUJCk Message-ID: Subject: Re: [PATCH RFC v2 00/15] rcu-tasks: let preemption outside trampolines be a quiescent state To: Josef Bacik Cc: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-33051d/1789283671-6F6C64E9-8FBD534A/0/0 X-purgate-type: clean X-purgate-size: 7070 On Sat, Sep 12, 2026 at 2:54=E2=80=AFAM Josef Bacik = wrote: > > v1: https://lore.kernel.org/all/20260910-b4-rcu-tasks-preempt-qs-v1-0-d44= 69f4cc101@toxicpanda.com/ > > v1->v2: > - Only walk the kprobe hash while the optimizer is actually waiting (Sash= iko). > - Re-check the kprobe jump window at every QS decision instead of once at > preemption time (AI review). > - Updated Documentation/RCU for the new rule (AI review). > - Added 14/15 and 15/15 to address Paul's comments. > - Added a comment in trace_recursion.h per Steve. > - No change for the arm64 ftrace_static_tramp_end report, the Kconfig > dependency already covers it (Sashiko). > - Re-ran the x86-64 QEMU tests, still 0.2-0.3s and clean. > > --- Original email --- > > Tasks RCU only treats a voluntary context switch, usermode or idle as a > quiescent state, because a preempted task may be sitting in a trampoline > that is about to be freed. That was a fine trade when PREEMPT_NONE > servers compiled Tasks RCU away and PREEMPT desktops rarely ran > long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: > Tasks RCU is now real on server configs, and cond_resched() is a no-op, > so a CPU-bound kthread or kworker only ever loses the CPU by being > preempted, which is exactly the event Tasks RCU refuses to count. > > The way this showed up for us was a cgroup writeback worker draining a > very large cgwb for around eleven minutes on an arm64 box. Nothing wrong > with that on its own, but a BPF program detach on another CPU went > bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() > while holding trampoline_mutex, forty-odd tasks piled up behind the > mutex, and the hung task detector panicked the machine. The kprobe jump > optimizer is worse in principle: it does synchronize_rcu_tasks() under > kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running > kthread can stall static key updates and CPU hotplug for its whole run. > The current answer is to find each such loop and add > cond_resched_tasks_rcu_qs() to it, which is the kind of annotation > PREEMPT_LAZY was supposed to let us stop writing. Hello Josef, Thanks for the great work! We've run into exactly the same issue on our production servers running the 6.18.y stable kernel: [ 84.393333] INFO: task bpf-thp:10274 blocked for more than 28 seconds. [ 84.393880] Not tainted 6.18.44-3 #3.infra [ 84.394214] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 84.394759] task:bpf-thp state:D stack:0 pid:10274 tgid:10274 ppid:10266 task_flags:0x400100 flags:0x00080001 [ 84.394764] Call Trace: [ 84.394765] [ 84.394767] __schedule+0x2c1/0x6f0 [ 84.394772] schedule+0x2a/0xb0 [ 84.394775] schedule_preempt_disabled+0x15/0x30 [ 84.394777] __mutex_lock.constprop.0+0x3a2/0x9c0 [ 84.394781] __mutex_lock_slowpath+0x13/0x20 [ 84.394784] mutex_lock+0x37/0x50 [ 84.394786] bpf_trampoline_get+0x2a/0x80 [ 84.394791] check_attach_btf_id+0x32c/0x3d0 [ 84.394796] ? __pfx_mem_cgroup_css_offline+0x10/0x10 [ 84.394800] bpf_check+0x4d6/0xf20 [ 84.394804] bpf_prog_load+0x4d7/0xb00 [ 84.394808] ? avc_has_perm+0x42/0xd0 [ 84.394811] __sys_bpf+0x729/0xd50 [ 84.394815] __x64_sys_bpf+0x1a/0x30 [ 84.394816] x64_sys_call+0x19e1/0x2190 [ 84.394820] do_syscall_64+0x67/0xe10 [ 84.394823] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 84.394825] RIP: 0033:0x7f2aa7e3ee5d [ 84.394831] RSP: 002b:00007ffd2b3e2a88 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ 84.394834] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f2aa7e= 3ee5d [ 84.394835] RDX: 0000000000000094 RSI: 00007ffd2b3e2b10 RDI: 00000000000= 00005 [ 84.394837] RBP: 0000000000000094 R08: 00007ffd2b3e2c30 R09: 00000000000= 00018 [ 84.394838] R10: 0000000000000070 R11: 0000000000000246 R12: 00007ffd2b3= e2b10 [ 84.394840] R13: 00007ffd2b3e2b10 R14: 0000000000000005 R15: 00000000215= 804c0 [ 84.394843] [ 84.394848] INFO: task bpf-thp:10274 is blocked on a mutex likely owned by task kworker/1:1:80. [ 84.395463] task:kworker/1:1 state:I stack:0 pid:80 tgid:80 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 84.395468] Workqueue: events bpf_link_put_deferred [ 84.395474] Call Trace: [ 84.395475] [ 84.395477] __schedule+0x2c1/0x6f0 [ 84.395482] schedule+0x2a/0xb0 [ 84.395485] schedule_timeout+0xea/0x100 [ 84.395488] ? trace_hardirqs_off+0x30/0x90 [ 84.395492] ? trace_hardirqs_on+0x2b/0xa0 [ 84.395494] __wait_for_common+0x94/0x1b0 [ 84.395498] ? __pfx_schedule_timeout+0x10/0x10 [ 84.395502] wait_for_completion_state+0x21/0x40 [ 84.395505] __wait_rcu_gp+0x135/0x140 [ 84.395510] ? 0xffffffffc03fed00 [ 84.395514] synchronize_rcu_tasks+0x56/0xb0 [ 84.395517] ? __pfx_call_rcu_tasks+0x10/0x10 [ 84.395521] ? __pfx_wakeme_after_rcu+0x10/0x10 [ 84.395525] ftrace_shutdown.part.0+0xd8/0x1f0 [ 84.395530] ? 0xffffffffc03fed00 [ 84.395533] unregister_ftrace_function+0x47/0x150 [ 84.395537] ? 0xffffffffc03fed00 [ 84.395539] unregister_ftrace_direct+0x49/0xc0 [ 84.395542] bpf_trampoline_update+0x448/0x4e0 [ 84.395545] ? __radix_tree_delete+0x84/0x100 [ 84.395547] bpf_trampoline_unlink_prog+0x8f/0x150 [ 84.395550] bpf_tracing_link_release+0x1a/0x50 [ 84.395553] bpf_link_free+0x57/0xd0 [ 84.395555] bpf_link_put_deferred+0x12/0x20 [ 84.395558] process_one_work+0x1b3/0x400 [ 84.395561] worker_thread+0x1a3/0x310 [ 84.395564] kthread+0x107/0x240 [ 84.395567] ? trace_hardirqs_on+0x2b/0xa0 [ 84.395569] ? __pfx_worker_thread+0x10/0x10 [ 84.395571] ? _raw_spin_unlock_irq+0x11/0x30 [ 84.395574] ? __pfx_kthread+0x10/0x10 [ 84.395577] ret_from_fork+0x10d/0x150 [ 84.395580] ? __pfx_kthread+0x10/0x10 [ 84.395583] ret_from_fork_asm+0x1a/0x30 [ 84.395588] [ 93.199020] rcu_tasks_wait_gp: rcu_tasks grace period number 1 (since boot) is 40249 jiffies old. We eventually traced the root cause to a problematic BPF program looping inside do_check() in the BPF verifier, and we've worked around it with the following change: --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -20411,8 +20411,7 @@ static int do_check(struct bpf_verifier_env *env) if (signal_pending(current)) return -EAGAIN; - if (need_resched()) - cond_resched(); + cond_resched_tasks_rcu_qs(); if (env->log.level & BPF_LOG_LEVEL2 && do_print_state) { verbose(env, "\nfrom %d to %d%s:", We've also observed random Tasks RCU stalls caused by kcompactd, but since they don't result in hung tasks, we haven't applied a workaround for those yet. Hopefully we can come up with a generic solution for these Tasks RCU stalls= . [...] --=20 Regards Yafang From xen-devel-bounces@lists.xenproject.org Sun Sep 13 09:58:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 09:58:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419690.1646661 (Exim 4.92) (envelope-from ) id 1x5gyH-00042S-1n; Sun, 13 Sep 2026 09:58:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419690.1646661; Sun, 13 Sep 2026 09:58:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5gyG-00042L-V4; Sun, 13 Sep 2026 09:58:00 +0000 Received: by outflank-mailman (input) for mailman id 1419690; Sun, 13 Sep 2026 09:58:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5gyE-00042F-TV for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 09:58:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5gyE-000We8-AZ for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 11:57:58 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa67390-2eae-0a2a0a5409dd-0a2a4509d13c-12 for ; Sun, 13 Sep 2026 11:57:57 +0200 Received: from [62.210.214.84] (helo=submarine.notk.org) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa673a3-be1a-0a2a45090019-3ed2d654cfea-3 for ; Sun, 13 Sep 2026 11:57:55 +0200 Received: from gaia.codewreck.org (localhost [127.0.0.1]) by submarine.notk.org (Postfix) with ESMTPS id 3885A14C2D6; Sun, 13 Sep 2026 11:57:47 +0200 (CEST) Received: from localhost (gaia.codewreck.org [local]) by gaia.codewreck.org (OpenSMTPD) with ESMTPA id 7a5da7f6; Sun, 13 Sep 2026 09:57:46 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=2 header.d=codewreck.org header.i="@codewreck.org" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1789293471; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ojc3Gf8XdcHrzIe5027BZcw/ZHmTep5+/EMX7/cpuQs=; b=I8x3cEXOrG0+DRO4ErfU7WXllrlpn1ZY9SxOSJnGpp4NmSMqs/nI1zmAid5c87Tk04wOVz 9e72wxFXuw7ra/qr3Yk6tk0A0XCriYPhZORmodOQbLN5UPTMjId1z9W1oIcIZ5dM42R+vZ Lu0BknfzS8Y4enR2uURKgMjLEE3jZw5uxjCrBG82XKlATKAHlZNEu9uaqsayQ4EnI3RXjI ASaMCoEXB1Sn6HAXM+/C1emdjJCf5LSSxEA2dmyurrghSrLZKvFsYE7Q5Bx/DfZERSG7EX ThFL/ALnEhkiqknZ57nFQWYzX/LguD+SZDvmP2WThznjfmMW/RDRBw/Sr7K4vQ== Date: Sun, 13 Sep 2026 18:57:31 +0900 From: Dominique Martinet To: Yifei Gao Cc: Eric Van Hensbergen , Latchesar Ionkov , v9fs@lists.linux.dev, Christian Schoenebeck , Juergen Gross , Boris Ostrovsky , Stefano Stabellini , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2] 9p/xen: fix refcount leak in p9_xen_response() on wrong tag Message-ID: References: <20260804213550.3409638-1-gyf161023@gmail.com> <20260806144255.4167019-1-gyf161023@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260806144255.4167019-1-gyf161023@gmail.com> X-purgate-ID: tlsNG-bad1c0/1789293477-BF2DC034-5FEE1EE0/0/0 X-purgate-type: clean X-purgate-size: 1316 Yifei Gao wrote on Thu, Aug 06, 2026 at 02:42:54PM +0000: > p9_xen_response() looks up the request for an incoming reply with > p9_tag_lookup(), which takes a reference on the returned p9_req_t. When > the tag does not resolve to a request in REQ_STATUS_SENT, the function > warns and continues the loop without dropping that reference, permanently > leaking the p9_req_t and its msize buffers. The reply header, including > the tag, is supplied by the backend, so a malicious or buggy 9P backend > can leak kernel memory on every crafted response. > > Drop the reference before continuing. > > Fixes: 728356dedeff ("9p: Add refcount to p9_req_t") > Cc: stable@vger.kernel.org > Assisted-by: Claude:claude-opus-4-8 > Signed-off-by: Yifei Gao > Reviewed-by: Stefano Stabellini Thanks, I've picked this up for 7.4 If someone is interested in the 9pfs xen backend security then sashiko had a lot of "pre-existing issues" to talk about[1]... I tend to agree with Stefano's point of view that the 9p backend is mostly trusted though, so I'll take patches if someone wants to spend the effort, but won't actively be able to contribute much more. [1] https://sashiko.dev/#/patchset/20260806144255.4167019-1-gyf161023@gmail.com -- Dominique From xen-devel-bounces@lists.xenproject.org Sun Sep 13 11:29:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 11:29:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419765.1646671 (Exim 4.92) (envelope-from ) id 1x5iOS-0006xW-6p; Sun, 13 Sep 2026 11:29:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419765.1646671; Sun, 13 Sep 2026 11:29:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5iOS-0006xP-4D; Sun, 13 Sep 2026 11:29:08 +0000 Received: by outflank-mailman (input) for mailman id 1419765; Sun, 13 Sep 2026 11:29:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5iOR-0006xJ-2O for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 11:29:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5iOQ-007zor-Bb for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 13:29:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa688f5-2eae-0a2a0a5409dd-0a2a45028128-14 for ; Sun, 13 Sep 2026 13:29:06 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa68902-6ca4-0a2a45020019-4a7de18ca232-3 for ; Sun, 13 Sep 2026 13:29:06 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d37b5so7344865e9.2 for ; Sun, 13 Sep 2026 04:29:06 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb32d3c7sm17806381f8f.10.2026.09.13.04.29.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Sep 2026 04:29:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789298946; x=1789903746; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=U8/tv6bYjr/JxaCBgXPuXjqSK44p/M/ZKAj7rPsQHeE=; b=b1sukgJhjBFiTPVTpOaTwwKly60OaSYLq5epVqm+QV8sEvubJWZvlOV1h9POl0t+Xp w4hmGYAYRxrzpXsAVIExpcSqj1ASp5QS8LFXrhC/8p27JqKcuKKDvSW63llRuZGoX9O9 s0EGfWxuzm7o69PahMh2p6rWGMrtDlFpjxRMp2mM+16H8USz1gagKiCGFB/dXYIHGPgQ AvycpEjW3itp6elFlUYyshG8c6M5/gd3mYUiU+/0R0P++g4qejp7E4R5wqPNiiunPVOU XpeflmG0A4ysjX4tHLXVcVztItyBdIp5TBzl3V1Iktyg9DvIEhXXJv4qRMB7pTbLcFdJ BsJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789298946; x=1789903746; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=U8/tv6bYjr/JxaCBgXPuXjqSK44p/M/ZKAj7rPsQHeE=; b=Azw00I1xpIWb8PPArPelsOESKWv0ZfiOYwBltJylJI5IomwO5Te2UBPgwve38NZotp 4J815ZJ4Wc6tii5oST5OwWPMi28Zl8r0Y+yuxLSsqS2RQ69aiyI2gR8+PNcQpzGbDWqe em+/CQLdh8ANgXD8m/Kv2p8tq7AybSaoUQpi4YA2d5FLJPSXEe0bx7uWhT+J0iOVcswc HS8/4K8hGyobfc56mBqoNpQAZX44JHPoXZVWixxHo7aeo/L2sCqExlnZMAoC/hUL/EJC tjPcKOhJ9FWpNEv2mTb5eMOP+4I+Pk62hvLYXfymTjY5lJs4fv2oe+fID0I18TIvkZR5 DUMw== X-Forwarded-Encrypted: i=1; AKwUvBwNdKqGjGbgWUWv/20bpAA2d9lD+NkFdSwrARgHWL8ledNJ/N31mQgG7rEVTdt/0emPkeTNx1DBykk=@lists.xenproject.org X-Gm-Message-State: AFuF++mXn33P+/fqv69ODHxmJHfR4bdGN3Jt2kP4ROOoe39cAmn0UDIo 2WhYBG0j2LArmpAJroRsmn+RwO+VE7sDIc/8JtrJ5rCPeTsneyY+mpZw X-Gm-Gg: AYBFou3KHovia1cTOzh/8WejPpZgSEyI+4BwriY7EB8YlQ97/feG+YQZGWhHh7OHT3J h6BOftsltxx0cfsSzR4XRNm3ZeqrrHzPJsfoeY8mXwWtUlI9Qpldo0bWE1R9VWiDkw4vywY7FHj FwQm1JJqkB8UlA8b9sSmPSCf0QB7pqYp+lbiPhXAX2dSpwqompVnfplncF8SDIT38ZxPOkpQNtp hsoONniDtRZplIQuqg5sJDYMgck2Ch1npvXCX+AWgR35OVWeYjkZvdIS55b8/xijHAQ1WyhZjwd RRqf/P22UcH4Rj1T08GZ62fdVz1Fs6b6uMsjQxo+9APBvcnWCcGRYL4APsXmB4wvJzcfVapS/DD QybTt07tqNjDTglOUcZj0hF8T/p5uVkriNxAxKsZnxLfdPMcLRPOT2MvMkBkHBHEd1pMiNM3aV7 tdSLWKKIhBLuHmTvm2tdq0yNELjURTi2KkW20YAkW+yO9cOOD5ZDFI66UHpCrOMUK5VKis6DzrK wbn4L+xFGWv6bmY0Vs2Ekm0TODwr3uLUawJ X-Received: by 2002:a05:600c:4ecc:b0:49e:6be6:d783 with SMTP id 5b1f17b1804b1-49e6be6d9dbmr138768675e9.0.1789298945625; Sun, 13 Sep 2026 04:29:05 -0700 (PDT) Date: Sun, 13 Sep 2026 12:28:59 +0100 From: David Laight To: "Paul E. McKenney" Cc: Alexei Starovoitov , Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline Message-ID: <20260913122859.4d5067cd@pumpkin> In-Reply-To: References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> <20260912221400.4045198b@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789298946-31FD62AC-A9CB0DFC/0/0 X-purgate-type: clean X-purgate-size: 1225 On Sat, 12 Sep 2026 15:31:24 -0700 "Paul E. McKenney" wrote: > On Sat, Sep 12, 2026 at 10:14:00PM +0100, David Laight wrote: > > On Sat, 12 Sep 2026 11:03:34 -0700 > > "Paul E. McKenney" wrote: > > > > > In the old kernels, yes, we have current->trc_reader_nesting++. > > > In the newer kernels, Tasks Trace RCU is instead implemented in terms > > > of SRCU-fast, which instead increments per-CPU counters. Which among > > > other thins is a bit faster and does not need to hook into the scheduler. > > > > Isn't that rather architecture dependant? > > It is fine on x86, but on arm incrementing a per-cpu variable is > > significantly expensive. > > Last I heard, slow ARM increments of per-CPU variables were to be a > transitory phenomemon. Plus changes late last year greatly sped up the > per-CPU increment operations. There are some unapplied patches to improve per-cpu operations for both arm64 and s390. Without those preemption has to be disabled (in current->xxx) which requires a conditional call in the preempt enable path. David > Plus this change removed some hundreds > of lines of RCU code. > > Thanx, Paul > From xen-devel-bounces@lists.xenproject.org Sun Sep 13 15:27:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 15:27:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419977.1646680 (Exim 4.92) (envelope-from ) id 1x5m6r-0002xV-BO; Sun, 13 Sep 2026 15:27:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419977.1646680; Sun, 13 Sep 2026 15:27:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5m6r-0002xN-6V; Sun, 13 Sep 2026 15:27:13 +0000 Received: by outflank-mailman (input) for mailman id 1419977; Sun, 13 Sep 2026 15:27:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5m6p-0002xH-J3 for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 15:27:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5m6p-0078vD-07 for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 17:27:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa6c0c8-bab6-0a2a0a5309dd-0a2a4502ccc8-4 for ; Sun, 13 Sep 2026 17:27:09 +0200 Received: from [98.137.65.30] (helo=sonic315-54.consmr.mail.gq1.yahoo.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa6c0cc-6ca4-0a2a45020019-6289411e9afd-3 for ; Sun, 13 Sep 2026 17:27:09 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Sep 2026 15:27:07 +0000 Received: by hermes--production-bf1-54b5569bdc-2n8f4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 91fea8749ccdd05d639ef192ab9d70cc; Sun, 13 Sep 2026 15:27:01 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789313227; bh=EoozB3bjfG8FjgjVi4Pa/GkHfnOoiVK3GJ3j78pUtlM=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=OMyUKa8qj5GPyTYU7DLq0OG3dqOV8t/G4lXIPD9/qEYgQ0xAbDVUMjvbaxReQGtuPc7q4aqcVcVvfUl1t7xm4eVoGdhQXAS6ITUphGOKsyF7/F7AqtrgTKZx9GIj4OaIZGQp/DqUPetufGDHAuZE2Boe+oQRB10Q5tRcJD+WrAyt2XPCPJsNkdekU3VzwBvzX6HrPyGH2AgsweXcmF74drvTgfFvHLim2P8L+d1BcJ/zrx+JeO7nI1IgTkE7HwMFPZBKtKc7Hj9M5vNzq318TWwv6MwWMrDzVqV10WUv+KfleykiBsyfCiEDfSZFPQO8ruu9dwseVA0S9fH9BaPxrw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789313227; bh=3LYiOU9aWUqZigvOf7Rx6CBO8oV+QOSiG0lEliFr41r=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=Oo5AMM7BnYSdzGbkulCiMmBiIg58t8Xp6DqfvclndbJcweu+oOxjt7qUMHplAhU8TOzSV4EUjpTTWiYPIYPSZb+o+7Ox7DVYsRcKzTPWaGtaz8Av/uYcsBhMJ4FHK6a+TEczAughhB29qPHKmwADMftIShlZGBtSz0dtAJmmQ/eJl0p3rY/vSBCWy6ub7NSFQ5hEP66lGgkmItOuSqip3eHGS+ruLzo0SktbXL46XqUsO5d695bA7iTDpOa9WcOAdF6UEUxalIx/sg6vU5cNTURhOYITEpjt+L1b0OPSD/CTecdz+NoIIWc7qV0KyWTNgCEpM0lgRQVrXFw3LQgdWg== X-YMail-OSG: WzcBx6wVM1mw9QBTOZuLShFQ8heTw6XAbjOSBFxbuw0T41tT9VorOGZZ5av8jr4 8vhQmVOI7mfd3exdtxwyW0u4vqK9NbbF1mmJhb_s6DVV7N7fEwkcJFNMViL4aVKgSurkauUCWkIC AWlzV8XJBPmrqAH2isFv0asfObw96wPlAa5Xsh8KN83Nq6kaYUp.KLKY8QMbRXsZaUB7WHUbHmBB UelyRxJ14jQawoTQFSiJzpXyAWNqjZEzC8SknYNiCHEUAuonnOYRzUH8ZXix_6AkCSMyLsJkunHS vqSBHUmauVdO9j5Nab8wB8rJrtVFp8ZOqg1HdOIVb_yG3gW9etzgMMH8PCnB.9c8FBpz8MRQZUZr 4tZ7meJ0JIGXIhYCUIwrtCJ3QiMTlzg6GCSTtAkblNHRPk9xviRbgaAC7D3QuD9kKMJM.Z43PXu1 f1fDndkDardsrQ70o975kpi9FpUv13w3_Raj8h3yemx4uSNZFdKWKzoMOyLCa7yiSb89oxnkdt1x CS.ScG_6p.N5n.c3ifHvoBnCHrJQxX9oZDNCVC_UPUddQ8Glm8tGOpEawgO0CS7XaTVJtg_0nB.z X3UNqmIeJ7PcN1ZPMpl86tEh7udEVyGx.NtgsiDw3hnbNGFsgDr_S1S4tf1.9USdlpp7QZyL8KQq AQG.1YvrJU9znUTZUR.vdsHLh7mdCLa0QvRYpEzD_l90iH6diiOlcspVg6_.ITEcgvAtSwIZxbO4 Ewm8HWKJmtPxpqzyd3_LJhJLAAg3Ol9KskDzF92ZHUsZbaoZtc5GjM82jyJvBIs7kfeMuLOAGs1b tXrnq5FtTsYFwD0EwwXlqVmsHroLokaozEGiCjCA6rMcd.J_DoL._BK41_uCg.p86LpsoXqj5f7D ucpgHSOAtpucDhrk8o.Rtnhsc_HbNNh4v30Z5Ic.VcC6P45owNtn5fWrOSv1vGjshB.paDAIA9tD F.Nfgfli4hxzX5ODsVlMXCr6Ku_pEt7oQNOcyG2MP_55HK3K2LqOY5VATVDbw46BGAN8z9EyitBu lxIZH5_LmnMBXGJL_PEFhW4c.DE2NFnZ80AdJkDd3vdPkFHRZAfwcf_z.GQoqVg8BOaNxqn3CX9t KR27sL1U8FSmjq0aCXTMFZ2FdIUR_DttKZ5W0DoVLU3bZ51nuQ.sVRm.nQyGsCDxzXIFXRTJZpzR 5uq0JZ4q.JkJ9FsM1pggqDxS4qCUeawKyTC2slwft5n6Q5pGgwWJ9wuqIXf30nmr6rxw3FnY2Yqz x2rmwZjelYI7Vl868mk0fhgpkDbpZ6ay30nXl9cgo9NHTq9y6MY4XlJb5G7Qzi.5_WJS34WcLhtj .LBcRgRPza_XYCp6xQZ1J8E_fKk1Fn_SNkt3niUCTrqfyMMpm9qcOwjhc3Aqvu2tnuLMJzJlVcRl iJEW2negtUqMwWlg8fwYk0yAArrYtTHin5IjwLAQlFR.CzvqPNGwln5jMBJnW77k5zaPWy.pbG1T CiaBqXNg9f_KcMFMgKwwxNA8PRgrCx3y6jtuRal.TGY.TQDtkVdJhtBzg8inwi_M7RpBXPRdYNvx LCON_W0ZEJImr.Z.T_iOndgydDO8VaAAF4kYFgjABpAuLMqPazSFNhqyr5chl_5p9zjzLrT6.WTP eIcQX58YOENh.UHl1kf_a_3HjQFmdeQ2qSUM_LXiCYRH.V7ERpVKEHu_citt2Wq3HOXgq.M4WAix ikTjgY1FhyvCXhzS_oeDdrLuQeebwLPzEAGfqWxzkhUo5gskHIyWFjpDX0eN2psM.eqWKYZ9N5Wd TLHFPWXJyGFz_WuiotPxbNRH5Hb4eZUCxFeatWJelnhJpkKKY8siZyGX7uB7hAJZ4RD6go9785YZ uJRrISRlnSp1xwN_92MW_oCdqyOV.ZkvjM1bG7KJjndHTUotn3b.ILej7aQdgpUPGVj1VHrgXVWZ y2qY9XWR9ln1TX_TUYl6jAqz5ROSe6IhFioI3_mq2OvJjBjPTiuXrUkrwIqDv5h7tCrxt21N_vSY bsdfmxSyIIK8AwBmrDU9ZVTU_3F1XL1XksR8PCTbeKMa73j3v2dADYhVwPwBs3x2quSbe1yv5Jfy l_4qH73bk4PZNAgU7UlzoXa7Y4lvEb0iZSzlFGg2NT.eDEYzDRKf8S.qXY88cNWd4v6e4u9xsSs5 rbDYzsqbQ72fgO52p46uElBNCDXWG04qFZ5PqiqJg48Nb5CGkFpgPc9dPvDUU96QQt903Y7nRCXI bzyewVej5r.nNa8IHkZsO.CqDY_TUhX4MIYB91f7I84W8AQ-- X-Sonic-MF: X-Sonic-ID: 0806e39c-1374-481f-aa83-482c050ccefd Message-ID: <292f5e2f-377d-498f-9966-d000468f8a19@aol.com> Date: Sun, 13 Sep 2026 11:27:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko References: <20260911072453.46256-1-brchuckz.ref@aol.com> <20260911072453.46256-1-brchuckz@aol.com> Content-Language: en-US In-Reply-To: <20260911072453.46256-1-brchuckz@aol.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.26525 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 646 X-purgate-ID: tlsNG-720697/1789313229-F26B72AC-D991EE05/0/0 X-purgate-type: clean X-purgate-size: 657 On 9/11/2026 3:24 AM, Chuck Zmudzinski wrote: > Please note that Patch 6 of this series requires a patch to hvmloader of > Xen for the new support to take effect. Also please note that earlier > versions of the patch to hvmloader are not compatible with this version > of Patch 6. Please look for v3 of the "tools/hvmloader: implement Intel IGD > extended VBT support" patch that will be posted shortly to both the xen-devel > and qemu-devel mailing lists. The patch to hvmloader required by Patch 6 of this patch series has been upgraded to v4 and is available here: https://lore.kernel.org/xen-devel/20260913032724.62438-2-brchuckz@aol.com/ From xen-devel-bounces@lists.xenproject.org Sun Sep 13 15:30:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 15:30:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1419986.1646690 (Exim 4.92) (envelope-from ) id 1x5mAH-0004T5-P3; Sun, 13 Sep 2026 15:30:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1419986.1646690; Sun, 13 Sep 2026 15:30:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5mAH-0004Sy-KF; Sun, 13 Sep 2026 15:30:45 +0000 Received: by outflank-mailman (input) for mailman id 1419986; Sun, 13 Sep 2026 15:30:43 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5mAF-0004Sq-KE for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 15:30:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5mAF-00AbE3-13 for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 17:30:43 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa6c184-bab6-0a2a0a5309dd-0a2a450cdd0a-38 for ; Sun, 13 Sep 2026 17:30:42 +0200 Received: from [98.137.64.147] (helo=sonic301-21.consmr.mail.gq1.yahoo.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa6c1a0-f479-0a2a450c0019-6289409389b3-3 for ; Sun, 13 Sep 2026 17:30:42 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Sep 2026 15:30:40 +0000 Received: by hermes--production-bf1-54b5569bdc-kpwjr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b73119bad5fb74a8759bef838f1a5a2f; Sun, 13 Sep 2026 15:30:37 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1789313440; bh=WjVc1WV5HjxlepYVAOj2MxPOACO6Ln4vDXN/9QU4OGI=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=s5U2JBr98QU6D8PWdOhGbE6czcJ35/Q5upzqJimrC9pZxJXDyVJV4dMYBB3e1U72jVYGjPWzfS2cRQ0G8kvsvMDNbVKvEOTobtGFMBsr+MvTP5E3FGyvp/DB/LXfaQP8Uq2kXQK+IMQQXpdxXEzWgYMw0H5fl6HREJpcqssbgUZGrT+WldHBM/NIVyCWSLdEPHA2KAyMdZN6NV1YHd6CKXPIcS5rZDxeGgksay3b+kEjZgHx8Nu9bEXynPBKTQfcdKSOPT52qiYXIyS6KFu0Ws1Fah75j8T56AkzVhg1Tsx0fqyzcCVe5eqr0tHX88AImKAhPOQyzaaxfMyyjmytkQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1789313440; bh=Ip8+thPGd7Mrzfd8SOzn832puZCCUDGlBUGR0cCuoTr=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=V6sUv46uqg4S2sXnTj5JZYij7ZtsTzuoXzFnb/JicdXFdrUuEVQtZMhd5uHCBYv8uoN5ZKFLhFz45/TlSbMWe390Qg/rboXT9I1/DmOaJWXhyQ1z7XNjgb6bIDr/Xzsvav6NJchzhSNgDHtQ9FR44ZCRUokz/i2T+MazdCOT++LXdUEWxaS1YhRiDh7/VlcrLDEuA7ZWDcXXTb3pPo9SNdPeYLT6Qo+6mOKE4AOI4NcqHIWhXA+wQfCcC9SwGGT1n8lxUWenMh1zTFUfwg0ch5IwCzp0f3rMHm/hdnyUraKARDWVWzr9uSnidzghihr9hgKXNERNxnbhUuFUja+tIg== X-YMail-OSG: VKOP9XoVM1m7xVi__8IWekBGavhQta5fbjb6mrCYNSRpgld.VeRZC22I1HY3gKn 57lq.ww4D0o5VNpmdoCsx8wgSEnAXbS7xSulI1CfU1jzSQ0V9z_EFI6ZOqJLEaKs9wRtVJVXGtzK Xk.EowitHSY73y1JUhxWigsa4DW4Ey0VFIX85PfVxufGZjwAaeAbS11sC8n3NRNSfuC3BdIUI4RX IHmWI1u_cFNt6VG5yDLNFhnExSiuwM3_aL607Vwa14lKjZwsh4K20lnVEfRL34aFwZTaZC6DV9N1 6y2eBaoSS.aEvSo2U1MQR.IyR822JUk8nrA41ocX8Ud6j_7iTkI1i9MrqPCQLcMIUBSli5JLmkSs Sl2zDylM3Ml4lW_cBqSOVvLkbeoZbMAqstbaw36cdkAooHbyxqFcboJ60WB3qmyacPAHsoDeW_OB GvIEquwm0rlvw3hKoYM0BVrHQAwDnpfmD16kxNrFQ.w_x_5IIVuAFrFzQttUAnexONls7TcR5brp _Gdt_q1Zrdz48OV9etLCHsw_dRJoazoY7VRixw45i9_jZMikE88gtiU4XGuQ9h1cs4iLskEgjHcy B3KniMRYV.94k5EmfSxO3ydDrT.48vjeuhUogPgvn4Dab._.YtyWKT9dkUDybavJMWN8dRTKUA.Q 6HLoOAuA4eQeAQ2f1mo_CP6NRjDa6SmumnYumLTz9fcUbvZJvm74ACW4MnAlBt0aCVR6fUuzrbHn LeC5_NAChOZBPuN_nof7.5zreXrDFk8DDx2Mbsx46jqELij_wr9xxvIHG8q52gpMuYgnIK6aQSko rypegAcNwzU2czVOFbZ3_vJzP5M6vZZueixvB4FgG.JHFMzpPvQMbJ6cUuoodryXJObJHuGPIfss PADAY5Z8eopH1pYFpgqrIvlL4BUiIgIRBX_rv5ra1dpoNN.IrJF0_aSEp2iUKfASCD.IPx_SIwoc nC8P9DUk1P_zKIvZuvUy64C_N_RZV1Np0k_weSiDWre7K.efIdzhlEf1VBTFphs_ausCPe8gX70C Djj.5Pb8d7jmbpOb7QEvOWIBMHnaNBqwZV6fnTB21kwWCoTgquZ9MzNfpv_41FF4U.6Hb.fWaAW9 0fCNwBHIqSLsmUypf6d7qk4ZT7gKEHuqqINMpvh5oHHghSzD8OGpq3.OEB3ZH.8ZJty8OWTeRSHb HkkpRkaIX0A7Cc6Ul4C8UoRXjnSw6AxH0iURwScvGR6dcJ09rL.ymDwMXnrnr5R4UujrRpiF5x23 iKhWHQ9FhtAWef.wUAZ1RJ5PHxtJ8FX6L1Ptc5ITPn6aJq5XryqR6XY5TVtWGncY.LaGOJZxn.Uy nJpSz0V1mTO5kLT_euYkpxfdEraBvFyBXQ7OonXzFV.RAzP_KHl81N30gXb0CG3SglpBmIUV8a7Z MNwx_0IYAziDwAJ.Ib22AdaJNOPr2Y4qhzAxOfYgUZHxmeqynPwN25MuAN2s2J91XWGNxQiOYIX6 1g1Mxuqr08a99MufjG2zuDNfGkHyGR39T04b3m8R9urEU8ueVO6ZUA74rpmIiMXEdtWcyfoleEf0 2wk8Paudnu1sm1HkdeScMRalpZeSJA6fDcG2RKPqb.2iASgUBOdzG0MAMvPv_4vjGbdRTwHKJ_wc wpqDvSkngYJuhFWwXZLTKi48cdGnmT1uGGivB22jc7UEHmuTuB5eCiSjHtZ5YJwbZriKGgHX_.A7 ptckyBlNghrC3F6um99EvZ9LtFQ9ihUTtSyIYSAp4A23LjeSuHSvldtn2aYgloTkkVp5XLqGmlAL UhVkzgKz4FQFNBX1U6PeD8co9_3bnpzhVqK9_g1YtsXmgR1bz41I.7MCHPn7Q4BwgXlg_GELM4TP wla7lRVfH_WzD8eumfZVpCgX74Ph84AIjkSM_NfzJQwzILov5jv68iklKoRlOwTn3D16Z8ZPI2Ax KgjmUGZGRO.MrgoupAapPheQNJ8bLNuCbYPHhwmyCGTHqdIC7gM5rdcAmbCP.OtLPWCAOPCCQP3e eV6d_7QbUAb7DKnbTR.bHlXz8knfVqV.wSXM77qG_OnAbQv.BvLEcwzSBwvhajBE1SAPRtmjL1Wm RVkQMaBqLDAQWyK.zO270s_YPtb_eoEbjYu5WU8mZAiGSucOak8W2BWR1hTzPuwopFN44RakS7ba .4o4wsEIckQLKG6sJyNIxyy.xQQQmCHlsyJByzlJVNJGms0dKhHZz.dND1KmMRwX9Sz1ENkIflWh 21Gv0rLl1fv3zozVKDdSHimFPJ.Fr74ATxP1vL45FeVtH X-Sonic-MF: X-Sonic-ID: ab88ba77-23ca-4dcf-88d5-66067669b80b Message-ID: <59c57e60-a677-4ae6-938f-fc533ca82468@aol.com> Date: Sun, 13 Sep 2026 11:30:36 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 6/7] xen/igd: implement support for extended VBT From: Chuck Zmudzinski To: qemu-devel@nongnu.org Cc: qemu-stable@nongnu.org, xen-devel@lists.xenproject.org, Stefano Stabellini , Anthony PERARD , "Edgar E . Iglesias" , Tomita Moeko References: <20260911072453.46256-1-brchuckz@aol.com> <20260911072453.46256-7-brchuckz@aol.com> Content-Language: en-US In-Reply-To: <20260911072453.46256-7-brchuckz@aol.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.26525 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 585 X-purgate-ID: tlsNG-d25034/1789313442-50520A5B-8209CA28/0/0 X-purgate-type: clean X-purgate-size: 596 On 9/11/2026 3:24 AM, Chuck Zmudzinski wrote: > --- snip --- > The companion patch to hvmloader will be posted to the xen-devel and qemu-devel > mailing lists shortly after this patch is posted. It is v3 of the patch > "tools/hvmloader: implement Intel IGD extended VBT support". Please note that > previous versions of that patch to hvmloader are not compatible with this > patch. The companion patch to hvmloader that is needed for this patch to take effect has been upgraded to v4 and is available here: https://lore.kernel.org/xen-devel/20260913032724.62438-2-brchuckz@aol.com/ From xen-devel-bounces@lists.xenproject.org Sun Sep 13 18:20:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 18:20:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420158.1646698 (Exim 4.92) (envelope-from ) id 1x5ooE-0001Ij-VA; Sun, 13 Sep 2026 18:20:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420158.1646698; Sun, 13 Sep 2026 18:20:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5ooE-0001Ic-SZ; Sun, 13 Sep 2026 18:20:10 +0000 Received: by outflank-mailman (input) for mailman id 1420158; Sun, 13 Sep 2026 18:20:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5ooD-0001IR-Iu for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 18:20:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5ooC-008ayP-Am for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 20:20:08 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa6e948-8faa-0a2a0a5109dd-0a2a4501a57a-16 for ; Sun, 13 Sep 2026 20:20:08 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa6e956-5984-0a2a45010019-ac6904fed6a4-3 for ; Sun, 13 Sep 2026 20:20:07 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 40B0360F86; Sun, 13 Sep 2026 18:20:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1B411F000FF; Sun, 13 Sep 2026 18:20:05 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 53A0ACE107B; Sun, 13 Sep 2026 11:20:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789323606; bh=NVD5gFDBWDGN0X6QVeDbX5tNYhDXBkX15MX3Yd3diVU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=mJ27Jmv/mJW2LDKw6I+T6hZEXq/ZvlwdOOJIHR64P4TERWpoC7uE4AYU4tWeybXKS IhEEGOMy0Mt1H/gMxVqeZRc1xjWs0hG72HL8fR9lzWZCJc+s6AutqyHSEJpptygnro 0ujyQ1jCJ2NdnkjiFiXL8AbMmC7IeFuaFqdm2wUUxnfYQ0605UquUF6v3IpXy6Hh9K ExMw4X6yCJv4rFys9evu9uD9jNFtrK5cQCDs3clrr7SgfUfCJke6/bv86T4a0uTWDQ s4J25tAJVZdbivSXe28DjPBWF9KgO0IoG9LWXGLAfbcUZYrE/yT1BmJCadTMNrOycI H5sJ25eSRm+gQ== Date: Sun, 13 Sep 2026 11:20:05 -0700 From: "Paul E. McKenney" To: David Laight Cc: Alexei Starovoitov , Josef Bacik , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline Message-ID: Reply-To: paulmck@kernel.org References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-8-eaaa61ed2da4@toxicpanda.com> <14cb8a91-497d-49f5-aa20-c6cb8b9a27fc@paulmck-laptop> <8c51a669-eb6b-455b-a829-b537da5209f8@paulmck-laptop> <20260912221400.4045198b@pumpkin> <20260913122859.4d5067cd@pumpkin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260913122859.4d5067cd@pumpkin> X-purgate-ID: tlsNG-d62444/1789323608-BE07B757-0531400C/0/0 X-purgate-type: clean X-purgate-size: 1492 On Sun, Sep 13, 2026 at 12:28:59PM +0100, David Laight wrote: > On Sat, 12 Sep 2026 15:31:24 -0700 > "Paul E. McKenney" wrote: > > > On Sat, Sep 12, 2026 at 10:14:00PM +0100, David Laight wrote: > > > On Sat, 12 Sep 2026 11:03:34 -0700 > > > "Paul E. McKenney" wrote: > > > > > > > In the old kernels, yes, we have current->trc_reader_nesting++. > > > > In the newer kernels, Tasks Trace RCU is instead implemented in terms > > > > of SRCU-fast, which instead increments per-CPU counters. Which among > > > > other thins is a bit faster and does not need to hook into the scheduler. > > > > > > Isn't that rather architecture dependant? > > > It is fine on x86, but on arm incrementing a per-cpu variable is > > > significantly expensive. > > > > Last I heard, slow ARM increments of per-CPU variables were to be a > > transitory phenomemon. Plus changes late last year greatly sped up the > > per-CPU increment operations. > > There are some unapplied patches to improve per-cpu operations for both > arm64 and s390. > Without those preemption has to be disabled (in current->xxx) which requires > a conditional call in the preempt enable path. These are on top of the patches that provided an order of magnitude improvement late last year? Very cool if so! Thanx, Paul > David > > > Plus this change removed some hundreds > > of lines of RCU code. > > > > Thanx, Paul > > > From xen-devel-bounces@lists.xenproject.org Sun Sep 13 23:34:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 13 Sep 2026 23:34:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420317.1646707 (Exim 4.92) (envelope-from ) id 1x5thy-0008Nz-Ra; Sun, 13 Sep 2026 23:34:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420317.1646707; Sun, 13 Sep 2026 23:34:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5thy-0008Nf-MD; Sun, 13 Sep 2026 23:34:02 +0000 Received: by outflank-mailman (input) for mailman id 1420317; Sun, 13 Sep 2026 23:34:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5thy-0008NZ-2U for xen-devel@lists.xenproject.org; Sun, 13 Sep 2026 23:34:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5thw-001sao-MF for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 01:34:00 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa732e3-2eae-0a2a0a5409dd-0a2a4509c6ba-8 for ; Mon, 14 Sep 2026 01:34:00 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa732e7-be1a-0a2a45090019-ac6904fe9282-3 for ; Mon, 14 Sep 2026 01:34:00 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id BB0D16101B for ; Sun, 13 Sep 2026 23:33:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72CEF1F00893 for ; Sun, 13 Sep 2026 23:33:58 +0000 (UTC) Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b5e4f1651bso1130426e87.3 for ; Sun, 13 Sep 2026 16:33:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789342438; bh=zng3/lheQcHYHRf6apSQbhsdybFIgxHykd4cCeRSALs=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=DIuwo+91E9j6P8gcffxeTWibtVYK84E/K0zWh6s/Yed5HdTiBGh4yJD4g8Yy7YMzp Zmb9UrM8SFiukhfEjKlqn74cChv71bxCDBhiCj/l/UQfge2Dm3qkgzsFbSGyqVSqpp Udm+lm2P+eabpV3YMbxtjsRr06pb7oVPf73ngoGqP6jy/KVGDLhpFrdPO/yuSXNhqF P/mNOKNoJ2KD2X8EoD31TZAHK6RsTWpDJuSUh375d6tPe7PrV/jmdpTbTzJGdzxjb1 iEp1c93xdl5nZIFDK9qu4pTXYFgqdfiS/ApZ0qsmVcVZZzCDaVwmiBwLQzxdIQXZR+ f0lsIW/5EvTVw== X-Forwarded-Encrypted: i=1; AKwUvBwNjz62Bw2CcTiU5HLAm59nqbqAe1R9fUULTmWYLyhBAZGDa06XjddaWy25vTLiv4VxFftJ82hFAFE=@lists.xenproject.org X-Gm-Message-State: AFuF++kgomAbfK0xV+tcc50biQYM3nwfInS8PxmJukPUFICxgzvBL7dJ GiG+6wA9KTOoHavgc2pgR84J/a7aEUFVRnMRCTQcjxDCntpMy+BvPCxjq++70UntaZgf6E87El1 JZW5diflde9Qy371+g47xyp0AHudl5G0= X-Received: by 2002:a05:6512:2204:b0:5b8:9a2d:38d with SMTP id 2adb3069b0e04-5b8ae8a73aemr7507e87.56.1789342437102; Sun, 13 Sep 2026 16:33:57 -0700 (PDT) MIME-Version: 1.0 References: <20260727-drm-simple-kms-removal-v3-0-cd5dc89858c6@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-4-cd5dc89858c6@oss.qualcomm.com> In-Reply-To: <20260727-drm-simple-kms-removal-v3-4-cd5dc89858c6@oss.qualcomm.com> From: Linus Walleij Date: Mon, 14 Sep 2026 01:33:45 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1XTt4ClabPMabRSeCfNHr3d8Y53WJSzGM-8HBGT1SAK6TVjQKD-jMPJbKA Message-ID: Subject: Re: [PATCH v3 4/8] drm/pl111: replace struct drm_simple_display_pipe with regular atomic helpers To: Ze Huang Cc: Alexey Brodkin , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Joel Stanley , Andrew Jeffery , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Hans de Goede , Alex Lanzano , Oleksandr Andrushchenko , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1789342440-BDEC6034-4CD608EF/0/0 X-purgate-type: clean X-purgate-size: 553 On Sun, Jul 26, 2026 at 9:46=E2=80=AFPM Ze Huang wrote: > Replace the PL111 simple display pipe with explicit plane, CRTC and > encoder objects. > > Move the existing timing, format and pitch validation into explicit > atomic check paths. Use commit-local plane state in the CRTC enable path > when reading framebuffer format state. > > Move page-flip event handling to the CRTC commit path. > > Signed-off-by: Ze Huang This patch 4/8 applied for next. Yours, Linus Walleij From xen-devel-bounces@lists.xenproject.org Mon Sep 14 02:24:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 02:24:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420363.1646716 (Exim 4.92) (envelope-from ) id 1x5wMt-0005Ja-GJ; Mon, 14 Sep 2026 02:24:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420363.1646716; Mon, 14 Sep 2026 02:24:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5wMt-0005JS-BT; Mon, 14 Sep 2026 02:24:27 +0000 Received: by outflank-mailman (input) for mailman id 1420363; Mon, 14 Sep 2026 02:24:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5wMs-0005JM-0s for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 02:24:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5wMr-001z90-60 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 04:24:25 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa75a3f-bab6-0a2a0a5309dd-0a2a45019464-30 for ; Mon, 14 Sep 2026 04:24:24 +0200 Received: from [40.107.209.26] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa75ad7-5984-0a2a45010019-286bd11ac12a-3 for ; Mon, 14 Sep 2026 04:24:24 +0200 Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DS0PR12MB6486.namprd12.prod.outlook.com (2603:10b6:8:c5::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Mon, 14 Sep 2026 02:24:17 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0406.007; Mon, 14 Sep 2026 02:24:17 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Sp7a8N+W7oK58Yehu//myQNUCEHc92N00qTl7DWhS6ZgaVp3rm9mH4wVZ4kamCZuFW+GhJHHvuOL5XY03V/qqD57s1xEq7tUkGZJ+Wk9dtuCjMuDHmenCi/jcMxL65PCZC7jIz97Q17pEztE6F/6BdK/8UmDH5UlVdqi3w6XDDfXNRsyex9A7LFj1h3j3pG9GsQHO2enNWIxUF0CytI+5wYJFWxaEnOkQvUuMT8TyYK0qdavlbRiaoiZy9pA/fLAUpzWYIiiJYocriY8ewSci9lNcKud1Bvh6pd9IuN0srN/deH3+Ux2Kf9lFKxXyd6gpKNDwbOaCCmTdEQ+mhOJrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zUjuXILVzjba9z+thh3HvZCbjHvrFmluDi/6zJAquZA=; b=FWDgr3fAx2uhKI0H/zwX6hCAP85EASuBYBwbUAZ9do28DW3Zch4cQF9EdDp2FZqUwp/8tOyF4xnmDk22PwTvG5q++i2fBpyrAObzieiodpsWDQGvNz0aLHFAYuNubuySRLeJQAB+WcTlsMaCDmafgLq+tNz+ZVPbv4mfRx7GU8Y4FIy+8T/tMwbWa3apqA8Zkii1S8RDVSldX0TaYOXtycda33UQvtOzYOD/MxSUHZJ4oBI9lr7iarVo7GLWlaKU9RHIlYx7+sxAWOf1zT7er+/OEQk3fZ9aM3B8GYRZCm+/s8/UAXWpszDSWYhXBGM/IBCX5uFdhMZcEKCQHkvLqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zUjuXILVzjba9z+thh3HvZCbjHvrFmluDi/6zJAquZA=; b=tgTgabpyBmDE0mCjoSaz7la/NJHpLJTA0QNH8L/8JGOH/adKuXwr99veXr6SGMiuvlV0V6m07iB3Nh2WHjkXuLGoC4FsaMZvcc4M3uArrl6yOCiuTzPT1zwPqvCjvNyBmcZwHw67y2gKDu/AlQhrhITRjCoYCZycgjANQLBHkGipxhW/XJpfvBXiBFQ57DRQqDbi/IZTe5cpWZrS8pAqzHRHqm83h6AAgQ1Z0ltHLJ9V2o7hWVoTHh1XocrzjJaHD2p1KTNLfKnLJ+HSNNpoyJN6SL9F+cbrG138oVtt/i/eVg1fxbDZD/26wMNE/RsjnZZoWft6maCaDTSbX/MMfQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; From: Zi Yan Date: Sun, 13 Sep 2026 22:24:01 -0400 Subject: [PATCH v4 03/16] xen/grant-table: stop setting PG_private on pages for grant mapping Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260913-remove-pg_private-v4-3-848550f7574e@nvidia.com> References: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> In-Reply-To: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> To: David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zi Yan , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org X-Mailer: b4 0.16.0 X-ClientProxiedBy: MN0PR03CA0020.namprd03.prod.outlook.com (2603:10b6:208:52f::27) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DS0PR12MB6486:EE_ X-MS-Office365-Filtering-Correlation-Id: 982e5414-cdc7-43f1-3bd0-08df12074690 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|366016|376014|1800799024|22082099003|18002099003|921020|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: z/p1/yzLc53JZYZ53rmd6dC7B8L8w49/gMQIhGR5QrVHUh2j7O2ONa48qlZznHbJHHion+Ak5rQoMEcxqjOhfla0nLfQWree90L1bause5fzWfCVNwirnthORJ/vBOEdWOo/WN0TvQ28YG7CsUhHx3biEDWDj/LZvwryd8xnuJS7ils5oqyvcwMcg2G8ICND4SdpKu1YVKrgJOeOioarOycaux98PW1Q0BJheuya+ZsQ1mjgx1xgoIOxqChcGDYp+Txu5XZiGLY8rPLk83FChwpnRooWCdqHKN7XAzLsM4b4ZFhJx/H6iYIQDqpxo0lcYijMmvsmuu6LlVFe8nTS5YoJQBlBT3B0Zy9xoBfqDzWTzPrq45OxQz/7Ni+ec0Tr2matRDgbNGlwXnaoXREkaICDQpmzBrMBp4fdtLBWw9ALUbLeOTwxrovQdO1P+ruGEnbuUtFF+kv3jcyklVGeIxpcivXGGuRamiLh9EFo3fhAvQIt9RU4+3VFWJyMKFgJ15BTNiVw6cYbIQ3U4pmb5krdyStnzoiVVxo0MmJqKkZ3bS6q0Zv53zw1EvqdXQ8AhvzUhbMEq/Hav4OeRn6ODjh+00SWRsjdsOZj6/3PbNYdsw2lv03YYQ9IBWKYLY6htsIyyCu67XGkVVFqJdacMGqIGIz9obMZadbHmiBqPcI1VqKXA5qIfBWvUUfSIHrqPg0beVreRPsMdUy3scJ3zQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(366016)(376014)(1800799024)(22082099003)(18002099003)(921020)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d0dPWnF2NWlvUmZxaW5RcnRkWDRxUU1jOTA3Z2l5eVF6cDBHalkzaDQ5cXlP?= =?utf-8?B?a2JBUUlRTUtJM3F3R01BWHdBZkRNa0paMFN2b1BQckJjNGxaUmJnb053YVJG?= =?utf-8?B?bU5IbWxJb1M4N1RnaWlndmIrdVVyMWhLS1hNbEk4ZGh4TGN0N3M5bk1uSjNP?= =?utf-8?B?V01XWVNxSkh2bFVOZm5pWGtIVUttQ1d5a0hMQy95dGt5QWZGVUNzOGplTWhF?= =?utf-8?B?U2NabUxSdE9GemxsdlMzdjNVMFZqS2ZiN2d2ZUljekQ4NUZXTmRpSzZqZmMz?= =?utf-8?B?Um1GM013YmhINUd0Q0d1aHl3ZVFBWnFOVnpJSGJIUEZrWkVWTzFhdnJZZVNs?= =?utf-8?B?UGlrdmRncEFDOW13Y25LOXZQRmlwaTdFbHhqTGY4MTRrT1BLSnNLams5SEdU?= =?utf-8?B?a1VlTlduLy8vZmRkeXNpTm5VTDU5MFRmS2JPUkZ0YzJ6bGNJNnBiVmtkMjJY?= =?utf-8?B?RjcxdGphRjZ2M0lSTFY3UVN4cTA2SVhRUG5QWDdmaTk4cTlnRVMwUGtTamlr?= =?utf-8?B?TUFETjY2UVllTVFTRFlCQUlGTG9KdHpzdUdVeGhPRjNwMFl2RzB0Mkk3UVg0?= =?utf-8?B?bHlNT1hVMGRhZEtwVTRub1A3VjZkMjBhc0VmdG94L2xseW8wZFN4bnZtd1Qr?= =?utf-8?B?MGIxS2JJZXROSHFvNElvYjZMVVJFeTlPWWNVUndjRnB1UGZxMXNXb20wNVFw?= =?utf-8?B?V3laUnZBQk03ZzQxRGUxODRDSXFLTnErcEZEcFZBUHZZbVlwMnk5UWRVZXRk?= =?utf-8?B?b2F2L055K00wYVB3VHhvTy9JaUhOME8xWFlIVDZBZTRidUsvNm9iak8rYy93?= =?utf-8?B?NUdCTDhEUzVVQzZCUnpCMzJzN1phaWxtai94dkYxZS9BTENTbUM2ZElVMkpY?= =?utf-8?B?NlFTQm1CQ0w3SjdVcWYwVFcrL3ZXdmJvZy81YnpMZEpFRFc5Rm5ZU0FUcC8w?= =?utf-8?B?Qk8rQmRYc0tiaVdVUmFleXFjZytPMUlGRGZpbGlMdHR1dElVU2VXTEtQcE1Q?= =?utf-8?B?dDFxa1ZiNEVhN0pVcUxodnY0QXFOZFFmQ1cySEtnWlVSb25ieGsxUWhxUWtE?= =?utf-8?B?anNQdEdQRHk5Ymt2aWl3K0Vkb1ROVnJMOVdxVFhwZG9uTmVqUTE5eVRZbkNv?= =?utf-8?B?bGliQ3VpVDZlTnl2NDZXTFE5RTRqRHMyQnBjUVgwZnpwdUFCNWg2WEMxazAx?= =?utf-8?B?U2I3V0tEajNHNS9jVDZxVTA2UlZPM0VCWWhlaDNkanBQc1JDaWhHWktaellz?= =?utf-8?B?eE5JMEVVYSt5eGxGL0JUMnNOQnBJRXJ0NU13SWpYaGN0Tml0WU14YWh2dGU2?= =?utf-8?B?d2tSU1RmS1VDS2VTREJRSkJGSWt6TXl0V3BBd054d0VaQVlySVVKcHoxNFBi?= =?utf-8?B?VlAxSWE4NklwYllYV051SC9xQXJGZ3MzMi9OOG1rVlpBK2YwOUJFSHh0RURX?= =?utf-8?B?bUx4Z1RLd1p3dnhBUDRUZFV3bGNodFJjZWNOSW0zM21aMENldlZGYUNUNHhW?= =?utf-8?B?cmtkRHdKZTcyMHFkeEdpVWJiQlpWaHRLUjJja0sxYmNudFB0WU1ZS0VNKzdN?= =?utf-8?B?U2h3ZjV5VW0xQVVBRmlmaEtnRk1IRW1teGE3ODF4b1ZPRWh1TXVGUnFyTndv?= =?utf-8?B?cE9CYWhxU2lWOTJTb1ZzTjE0M3J5NW16ZGJlK050Rzd5blQ2ZGhvTDJObTd6?= =?utf-8?B?blJlNm5naGpmdnpOZHM3NzdsQkVPZTZCa1RwSjYzVnNCODRtSGpOMHJFVmZ2?= =?utf-8?B?cWpRUEozcGR1RkJ0Rm5ERzNINHJZVFZqd2N2VzFLbzY3V0p3R0ttNDIrSzlt?= =?utf-8?B?OTNWVFNOKzFXNzZjMlhuWGZrejBZd1ROQ0Q0RnFyak96TGtuZ1RFdmdUdVNr?= =?utf-8?B?RWc0d09vZ1VjNGQ1UFJQb3l2VlV2RVJoR1lnUmswUjFYZURUUVhXVmE1QU1O?= =?utf-8?B?QU50V1F2NG5oS3NpQ0xkek40RkFnQVV6cVBKdFJSV3Fod2hwQkNIKzVWQzBR?= =?utf-8?B?QStNTDJSZ00velBQKzNMVXQvYlpRYUY1ZWtVQTJCVjBQK3ZvLytMRVNhRkt0?= =?utf-8?B?QzBiaDJZZHhGNWtreFZyemw0UkZGS1htRjZXZzRZaEk4Rys3bUlObWZGWjVX?= =?utf-8?B?eEttRGVDYkUyRFgwREJrZVpTTWhoK2RYWlhVQ2xlZlVEdlYzNlFGSldhWG5w?= =?utf-8?B?M0dMbFR5dWVZZGZIeWt5aWFqeVNheXczM2k0dUdFQ2VrMkU4VzBWSU02dU04?= =?utf-8?B?Tit5QU9UeWx1VGptSHFMd2EzcElRaHEwVUpJbS8xNXV0TllYMGhNMGxUOXpn?= =?utf-8?Q?ja6n8QxfWm22fveCv8?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 982e5414-cdc7-43f1-3bd0-08df12074690 X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 02:24:16.8986 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: To3O9zZcW/LMdCtzpMacLnBBGk++x3Djb34juhRZC6KxlJaWhOUdimgBAOw6n/v2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6486 X-purgate-ID: tlsNG-d62444/1789352664-1FE68757-B19921BA/0/0 X-purgate-type: clean X-purgate-size: 2028 gnttab_alloc_pages() stores xen_page_foreign in page->private. On 32-bit, a pointer to an allocated xen_page_foreign is stored; on 64-bit, xen_page_foreign is stored inline. Checking page->private != NULL is enough to tell whether a xen_page_foreign needs to be freed on 32-bit and page->private is zeroed unconditionally on 64-bit. It prepares for a future commit that remove PG_private. No functional change intended. Assisted-by: LLM Signed-off-by: Zi Yan To: Juergen Gross To: Stefano Stabellini Cc: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org Cc: linux-kernel@vger.kernel.org --- drivers/xen/grant-table.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 69922be28b54c..993f89f048e21 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -863,10 +863,10 @@ EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames); int gnttab_pages_set_private(int nr_pages, struct page **pages) { +#if BITS_PER_LONG < 64 int i; for (i = 0; i < nr_pages; i++) { -#if BITS_PER_LONG < 64 struct xen_page_foreign *foreign; foreign = kzalloc_obj(*foreign); @@ -874,9 +874,9 @@ int gnttab_pages_set_private(int nr_pages, struct page **pages) return -ENOMEM; set_page_private(pages[i], (unsigned long)foreign); -#endif - SetPagePrivate(pages[i]); } +#endif + /* Data is stored in page->private on 64-bit */ return 0; } @@ -1031,12 +1031,11 @@ void gnttab_pages_clear_private(int nr_pages, struct page **pages) int i; for (i = 0; i < nr_pages; i++) { - if (PagePrivate(pages[i])) { #if BITS_PER_LONG < 64 + if (page_private(pages[i])) kfree((void *)page_private(pages[i])); #endif - ClearPagePrivate(pages[i]); - } + set_page_private(pages[i], 0); } } EXPORT_SYMBOL_GPL(gnttab_pages_clear_private); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 14 03:40:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 03:40:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420382.1646726 (Exim 4.92) (envelope-from ) id 1x5xY9-0008Pl-Po; Mon, 14 Sep 2026 03:40:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420382.1646726; Mon, 14 Sep 2026 03:40:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5xY9-0008Pd-MH; Mon, 14 Sep 2026 03:40:09 +0000 Received: by outflank-mailman (input) for mailman id 1420382; Mon, 14 Sep 2026 03:40:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5xY8-0008OS-2w for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 03:40:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5xY7-002Eii-1N for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 05:40:07 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa76c81-bab6-0a2a0a5309dd-0a2a4508a836-12 for ; Mon, 14 Sep 2026 05:40:06 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa76c93-f659-0a2a45080019-aceafc1f9d02-3 for ; Mon, 14 Sep 2026 05:40:05 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 8DFC540A5C; Mon, 14 Sep 2026 03:40:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92FF91F000FF; Mon, 14 Sep 2026 03:39:59 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=korg header.d=linux-foundation.org header.i="@linux-foundation.org" header.h="Date:From:To:Cc:Subject:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1789357202; bh=x5zisV7HoQ8XMweM1XOT4E07P1NlnKsteMfQzVmO4Js=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=pHy6fbeflVTU8QtsqFS5eh8OvOR3ntwRr+lHZYMkoAT3ltm91/zKHpwN5XKZntEOS ILIVvwKavB+/VLgc77oFP5R90/PbqE2ALcouMF/TdFK9XZ9ovr5QioyLZB1yLh6r2e gdt1bOJXa+0zPlb1i7I7WNxSlmbqXRfHn0UsNCp4= Date: Sun, 13 Sep 2026 20:39:59 -0700 From: Andrew Morton To: Zi Yan Cc: David Hildenbrand , "Matthew Wilcox (Oracle)" , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, Oscar Salvador , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Tal Zussman , Gao Xiang , Jan Kara , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-trace-kernel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , ceph-devel@vger.kernel.org, Song Liu , Yu Kuai , Li Nan , Xiao Ni , linux-raid@vger.kernel.org, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org, Baoquan He , Pasha Tatashin , Pratyush Yadav , Jonathan Corbet , Dave Young , Shuah Khan , kexec@lists.infradead.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Message-Id: <20260913203959.6b46b0b5a052aec818a7f267@linux-foundation.org> In-Reply-To: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> References: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789357206-CF75B87B-29B29271/0/0 X-purgate-type: clean X-purgate-size: 1221 On Sun, 13 Sep 2026 22:23:58 -0400 Zi Yan wrote: > This patchset removes PG_private to make space for upcoming PG_folio for > identifying pages from a folio (more details in Note below). Instead of > checking PG_private, all code is changed to check page/folio->private != > NULL instead. > > MM people are cc'd on all patches and subsystem people are cc'd on the > cover letter and corresponding patches. > > Patch 6 is picked up separately in f2fs tree, but since mm-new does not > have it yet, it is sent for MM testing. AI review claims to have found a pre-existing critical level deadlock in f2fs: https://sashiko.dev/#/patchset/20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com it also had a few things to say about this patchset and, as always, hugetlb.c. Thanks, The MM bits appear adequately reviewed and review of the non-MM bits are, as usual: Great to have but I won't permit lack of other-than-MM review to block MM improvements. So I'll queue it all up and shall push it into -next after a few days. Acks from non-MM maintainers are appreciated. If a non-MM patch appears in linux-next I'll autodrop the mm.git copy of that patch. From xen-devel-bounces@lists.xenproject.org Mon Sep 14 04:05:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 04:05:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420366.1646734 (Exim 4.92) (envelope-from ) id 1x5xws-0003ft-Mh; Mon, 14 Sep 2026 04:05:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420366.1646734; Mon, 14 Sep 2026 04:05: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 1x5xws-0003fm-Jl; Mon, 14 Sep 2026 04:05:42 +0000 Received: by outflank-mailman (input) for mailman id 1420366; Mon, 14 Sep 2026 02:24:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5wMy-0005Wg-EQ for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 02:24:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5wMx-001z90-RQ for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 04:24:31 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa75ad6-bab6-0a2a0a5309dd-0a2a45028954-2 for ; Mon, 14 Sep 2026 04:24:31 +0200 Received: from [40.93.195.49] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa75ade-6ca4-0a2a45020019-285dc33185d2-3 for ; Mon, 14 Sep 2026 04:24:31 +0200 Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DS0PR12MB6486.namprd12.prod.outlook.com (2603:10b6:8:c5::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Mon, 14 Sep 2026 02:24:14 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0406.007; Mon, 14 Sep 2026 02:24:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RuH9vyjuYaid+zILzXrJrBV7OItP/6/TaUIQi0nBptyYKtiDiU/aolayw+RQamS95Fzg9hJ6tj6E5nnFpjx5vvopnryJhmJ/+n061jItD35cETPUHbqOqfhf5MIvs49CafSFXVPZnOoYnJouAGWDLqSho58fJBO0PcquMXI0euhFhzTQsku/Qo5aEvg9c14MP3C83Dgb/Uhmjg5HZfnuz26Ifc4kOLbv+loMFfym5nP9J0SI+3qVsn2OCyXQJ71UfJjLex3EuLoSFZdQSiAJ/Afo9RUzfonQcB76hxwBdexq+vWQfWPF01QPSJiK4l88NaGaRwRmxWcJLALRBUV9cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tvB0TSP3lu5xd3D2C+aiQSNa7p4jdAISkxA9X3SgoOc=; b=FOpKPUalL+ZKzBHLhfZ6Vue1SUn7Ley72wD6mi9CUAnfuPPzx9CTOO1SR6fgAxg2eVtO5b4OtARRGMH5N0JbmPuD8iWTXstNQLCC+VTxJKQ01ZVpx5UIh/epZcbcvHAN2Qex4LEG2TDr6QssdKXd8QD+OYIdnb9h3CNv58N0nTnKmkk3GjUAFAzeqJZ6ZKOUZyOKMg3wpUcwc+guOMS2GBxH6i6wFh/HAeFA1E7RL3+6Ne3qX6en6lR7P8L6zLtvmBaZDX+VXKTtXRkaf+NrVlMoravfYWsgsASnrX2SgNY35bqi6vu+x/nrpXaxhihfligXJywRwWgr6N5D+rubDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tvB0TSP3lu5xd3D2C+aiQSNa7p4jdAISkxA9X3SgoOc=; b=Td+0UxeuJ5XwD7k8zm6yDw1VXgIgLHuCWQhFVM0O1fEgKvCkktTrsRpHLTuSQFlSJglYmy98LGI99hAxpqXe7mdib/USXhShZhS7ejHTM/BwxeVdP3y7eyJREk10ljuqn/2p+9n3imx+Is67VykaGznn6nkpqMNl4VSJ1+8uuBCf2M7tRERmW1dbcVsKpUD96sRdWN6pd1aPBwaLZGlIy4Bea7yg5DlsUxfwxG3d/JXD+DuA/75bsdMcT/CSgVYGg8lp36cb0PH/voalbuwPTeiopxpxLOXIIE3SqB7M05KKlsIioUu6M4TiRWxfkahYS7u8ipHzxbfcsNDtlylJBA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; From: Zi Yan Subject: [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Date: Sun, 13 Sep 2026 22:23:58 -0400 Message-Id: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-B4-Tracking: v=1; b=H4sIAAAAAAAC/23OzQrCMAzA8VcZPVtZU+2HJ99DRGqXbTlsHd0oi uzdrUMY4o7/QH7Ji40YCUd2Kl4sYqKRQp/jsCuYb13fIKcqN4MSVKnB8IhdSMiH5jZESm5C7mu 0oLyujfQs7w0Ra3os5uWau6VxCvG5nEjiM/1qUmxoSfCSiwN4q+9OHhWc+0QVub0PHftwCVbCb BOQCamUEUfrK4vmj5ArYUu9RchMKIcAta0s6N8v5nl+AwHWcy45AQAA X-Change-ID: 20260728-remove-pg_private-cfe926c7f83c To: David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zi Yan , Minchan Kim , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, Oscar Salvador , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Tal Zussman , Gao Xiang , Jan Kara , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-trace-kernel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , ceph-devel@vger.kernel.org, Song Liu , Yu Kuai , Li Nan , Xiao Ni , linux-raid@vger.kernel.org, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org, Baoquan He , Pasha Tatashin , Pratyush Yadav , Jonathan Corbet , Dave Young , Shuah Khan , kexec@lists.infradead.org, linux-doc@vger.kernel.org X-Mailer: b4 0.16.0 X-ClientProxiedBy: MN0PR05CA0019.namprd05.prod.outlook.com (2603:10b6:208:52c::26) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DS0PR12MB6486:EE_ X-MS-Office365-Filtering-Correlation-Id: 58b806a8-7031-4f61-010f-08df120744e8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|366016|376014|1800799024|6133799003|18002099003|3023799007|921020|10067099003|56012099006|11063799006|5023799004; X-Microsoft-Antispam-Message-Info: uw4TP9xiaMyZIvIwMa32j3fGc17IpO2wUcD60ElgnQhs73y/FOYE9fUIpBI2nR3HVAx0lKAhr8hTl8TUpmTVMGYTd/m/IRrjtnotO5ehj8wSa//D08/3w7mB0CqGBcpCdTY3tPsjF6LFG2apQV1iMR7g6pv/cTa6H7tdPrVUlQeTFRQtxKuzQ5cYY+KjqTYdsg4m/BpegV51Mwxz0r4EO47yuY5hA++MKhLFwEB/+CGnICKvyQgX7A7/vEY9Qv0xC0+Ygz3u7a7D6mTQ3osA0DXA6L9ob0JUVXukEC19ue6PifLZsltomqqCyHZQsgym7Iz1W7HFSFJx9AANsJVeLzLDc3V4IicoGoPiE8VvinUHc3rRAwKqovz9D+OrIpnbgYVZbHWqRM5bDv6jjWxHNKR9RWZ9LFb5h94xE8B+cWFSohjx6aEM2HMcCCBt8HXucScSnmJ5NdIXWhLdQmn1SDa3I8ST5wrPmqIV4BY9jQX/hKmb5ylNHKxnmEPA4etqr3+9nc8zTiKWTWmvgbxrgZNeNQPpNbOQQ9mQ9f+WoNAr1vrpCOMnuwc+GmFtNrAqvjiSsuLP2bNLva5KUUfMq+qpW7DMW2Z6Rj157qLyOHER+4D7xk7Um0MkJSrx1AVZZPP80xAZxfSp3CQB/SfqHfGhHvsVgxoZinU7ICq2+OnMnm2hIUTR7/V5xpN9dodcyWjDo0UgPBbljPBHIMa5Kg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(366016)(376014)(1800799024)(6133799003)(18002099003)(3023799007)(921020)(10067099003)(56012099006)(11063799006)(5023799004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SFQvOVdTcHVpdDRzNkM3WWVxcWx1cE45czRqZjhXSXppYVlYVkUyYTAyeFYr?= =?utf-8?B?ejI1a2JON0I1RkNuOHJwWVlWbzVLLzRQTEpKNmJFYnVFRTE5NkFIQzZlVGtI?= =?utf-8?B?Qkpqbno5MGJkRzRWYnl5VG44ZmMyUWU0d3pqLzFZeTRsZFFIQ1NVMVhIeXFk?= =?utf-8?B?UFA2Nk5NYXl4MHErd0NpVVgvUEhkcGptVjZFVnJVcVN2MnRZVndOMUhaWXp3?= =?utf-8?B?ZlgyNWlpV3JjK0hhbDVNZTJRYllQN2d5MUpOZU00SllmaUVtbkVBcEgrNmZz?= =?utf-8?B?M1FhZFNNSHlZUUx3ZXF2R1A0NmYzalpiZk82anp3WlRYU2lzdTdVbDJEKzRS?= =?utf-8?B?QzBCZUdJWFFLOWZjbm8xTFl2TkE1Q2Y3L25PSUVwUC9zbkIzM1JWVDVFVmhJ?= =?utf-8?B?QkRvUTJxZFlXSDh1WGNCUGI1WGZLTnZqVk9HMC9ZTGc0aEJEeE5UTXVKZ2ZG?= =?utf-8?B?dkIwaEljTVFpTnZiUXlXU2ZRRnhpNUNlTTVOcTQ2a2piNHo2SEFHTGxWVWF6?= =?utf-8?B?a1hmVmlydko0L3FEUmhFOXhwR3Q1NnZvTzJGRmJKWlQ0elZ5OHg3R0JzT0dv?= =?utf-8?B?RkoxSm4rWmRrTXQvRXR3Vkh4aCsydGkvNnIrR0lRNHI3ODFVQUdmb1V4LzNr?= =?utf-8?B?TzViVDRmaWI4b24rRUdncHVyMXUwdzFiSE5jcUcveTZVTDNuKzd6aDdQSTBm?= =?utf-8?B?U1EzTGliZnh4U3BubVdBZWhMK2dLRmp4TlBRRFFqTnZieCtHN3FZUThsRVhN?= =?utf-8?B?Zm1wRk55ajlkOWtRQXNmdU5kb1RhYmJyalNMMmFydFk5R0JJVE94Ym9LL2NZ?= =?utf-8?B?NHBXMEZZWEJsZ0trbFNLVG1DZTdNOHB6WEIrdGh4bkNLMDhBbmlXUVBiTGJy?= =?utf-8?B?V1VJc1F3OTRNazZabjIrdDIvUzFyeHA4cVZQcGZZM3hGTkZDT2plczVvQTJl?= =?utf-8?B?UnRaRFBVOGpFS3hYM1dFMXY5RUM0UVE2Rm8wd2RtK1dmU0w4L1hRS3RRblBU?= =?utf-8?B?cTJwWXdTZ3ZWaThIcE5qbnlEcHE5am5zZkJNdjFYT0hHa2JDbDFlSG5tS3No?= =?utf-8?B?Mi8xa3hVRThWY3ZrcC82MThWY2lIY3FkdlN2TStjcjc2d3p1eVFiYzl6cTl4?= =?utf-8?B?L0ZML0s5U0pJeFpLTytRSklzdzhEeVFVV2lOOTVhSTdielB1ejVEZTN6SVRG?= =?utf-8?B?VFRSN0F0ZUU0RlFqS045RWp2QVNVZXRTUkU5RFdUVzdRdFJUNDJlNHdnSStN?= =?utf-8?B?Ull5eWdMeDNRWEFjdDhyTXB6Sm9ISXB0QU9kaEtTMmYyYm9VcElXMU9mYTdy?= =?utf-8?B?ZUV3ZlJFSFBCSlpnNkJQZXpQRmFzNGo2OXB6dUo1V3dRSEs3YmRqTjEyOVVp?= =?utf-8?B?V0h4dENzQWE1QlR2aFNOTEJTdjYrWU4vTC9DMjd2dDFVYllaa3JiRnBRNE1m?= =?utf-8?B?a2RFRW9tOXNDbDd1OW1LVFNPWEMzOW9BUlViNXB4ZmU4bXhzaHlCVWhNUnJk?= =?utf-8?B?bjVFc3RBdkgxM2w2d3ZPT0RITEk5SXNiek8zcmw3aitXWFBrbjZsdWxLRVR4?= =?utf-8?B?VUQrTlhvTVlQeGJ6Y1hPYnBjYXNBK0NWWmlKeXQrMy9EOUc4L2YvN1FxL0dM?= =?utf-8?B?N0FueGRwN0d6d3dnMkRvaHRIS2UzYytsN2Q5dlQ2RXJsS3NCRnZmUFZjY1o4?= =?utf-8?B?Zm9Tc3UvVVZDVUhWU2d3cDhMZTFCc2oyM1kxcFhBdE4vUUZQY25ZamQ0OUM3?= =?utf-8?B?bUZUa09Mc1VsUis0akR2dDJ0UjBqM2dwTUxDNUFuRkZOL1FNK0pPY1ZIYjZB?= =?utf-8?B?OUpUUm9TWWIxbi93Tnc4ZUZQRHJFNGVTK1F3dzREN3FrWmFzemZYN1BNcWVq?= =?utf-8?B?K3NvS3lzbFJVZ2ZQcWJXcjE4SSttZzJPN3BJQzJuWEYvT29NbVB5NUJXbkJv?= =?utf-8?B?Y0dDK2pKbGRIWXNBSTVVTjUwY0ZKQm5VdDE4Rk1GbjFQdGhmeTdLaG9Mc2VQ?= =?utf-8?B?R3JFTjRkL3FOUmhBQ1owZDNFRE1LbEJGWjVTaU5OaDROUEx3RExuWWk0MXRo?= =?utf-8?B?bmx5cWF2b05KWVppOGcyNkxBN1loY1hWYlpVTElBRkJaa3lHUkM3WmpjcU10?= =?utf-8?B?QmJ1ZzJ3YlcvbndqOXpSSGx3M01FVGdRczh1WGpwaDJYdHp6UmVaT0VtRW14?= =?utf-8?B?VHc2cEJrRi9aSEJoVjJMZ0dGSkQxb3F2enJhWnpYMlNoTzlEUnd1NkhIcjlW?= =?utf-8?B?Tm9WVHdodVFxbFJ4elF2SGJ1OFhGNXZQM0hTUjZTMU1yOHkwLzk0MkxycElV?= =?utf-8?Q?4B0cEUcbG9+81FWeZZ?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58b806a8-7031-4f61-010f-08df120744e8 X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 02:24:14.1529 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5QuzN4mEfAUXhsNUNhNjvq1VqrMux8K6U5WQLP8azuRWxVympQ+TSMu0urb+FhBH X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6486 X-purgate-ID: tlsNG-720697/1789352671-30DC12AC-6C06BE00/0/0 X-purgate-type: clean X-purgate-size: 11829 Hi all, This patchset removes PG_private to make space for upcoming PG_folio for identifying pages from a folio (more details in Note below). Instead of checking PG_private, all code is changed to check page/folio->private != NULL instead. MM people are cc'd on all patches and subsystem people are cc'd on the cover letter and corresponding patches. Patch 6 is picked up separately in f2fs tree, but since mm-new does not have it yet, it is sent for MM testing. Overview === Most code uses folio_attach/detach/change_private() functions, so folio refcount is increased and decreased when folio->private is set and reset, respectively. There is no need to change them. Changes are needed for exceptional users: 1. zsmalloc uses PG_private to indicate first component zpdesc page and page->private is used to store zspage in zpdesc. To remove PG_private, is_first_zpdesc() is replaced by pointer comparison. 2. kernel/events/ring_buffer.c stores page order in page->private. Replacing PG_private with page->private != NULL works. 3. drivers/xen/grant-table.c stores xen_page_foreign in page->private, where on 32-bit, a pointer to xen_page_foreign is stored; on 64-bit, page->private is used as xen_page_foreign. PG_private check is replaced by page->private != NULL on 32-bit for xen_page_foreign deallocation. On 64-bit, page->private is cleared unconditionally since {domid=0, gref=0} (xen_page_foreign can be 0) is valid. 4. fs/crypto/crypto.c stores a folio pointer in page->private, PG_private checks are replaced by page->private != NULL. 5. fs/erofs has two different uses: 5a. folio->private is used to form a reversed list of the outputs of readahead_folio(). readahead_folio_last() is added to output folios in reversed order, so that ->private is no longer needed. 5b. folio->private is used as an in-flight I/O counter. Convert the code to use folio_attach/detach/get_private() and add bias==1 to the counter to avoid folio->private being zero. 6. fs/nfs/write.c: folio refcount maintenance is in a bigger scope than folio->private. So folio_attach/detach/get_private() is not used. Nothing to change. 7. fs/f2fs uses attach_page_private() to first reset folio->private then immediately sets PAGE_PRIVATE_NOT_POINTER bit on it. Change it to use attach_page_private() to set PAGE_PRIVATE_NOT_POINTER bit directly to avoid folio->private == NULL gap inside set_page_private_##name(). 8. hugetlb uses folio_change_private(folio, NULL) without folio refcount maintenance. Change it to folio->private = NULL. After the above changes, PG_private ops are converted to page/folio->private ops. folio_has_attached_private() is added to check filesystem-only private data by excluding swapcache and hugetlb folios, because swapcache folios overlap swp_entry_t swap with ->private and hugetlb sets its own flags in ->private. Note === 1. KPF_PRIVATE is removed after PG_private is removed. 2. Documentation/mm/hugetlbfs_reserv.rst is outdated, so I did not remove PG_private related text. It should be rewritten. 3. PG_folio is planned to be set on every page from a folio in page_rmappable_folio(), so folios with any order (currently PG_large_rmappable is used to identify >0 order folios, but not order-0 folios) can be identified. Then vm_insert_*() can correctly reject all folios and rmap code will only see folios. Eventually, page_folio() will return NULL for non-folio pages by checking PG_folio, but before that all existing users that treat compound pages as folios will need to be converted. Tests === 1. allmodconfig build passed. 2. zsmalloc is tested using ext4 on a 1GB lz4 zram: 2a. zram load + zsmalloc compaction; 2b. concurrent zspage migration via memory compaction; 2c. confirmed that multi-page zspages actually formed. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_zsmalloc.md 3. erofs is tested on images created with -C4096 and lz4hc, lzma, deflate, and zstd algorithms: 3a. cold read of all files, verify checksums match source; 3b. readahead + reclaim/migration race. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_erofs.md 4. fscrypt is tested on software-encrypted ext4 with writes to exercise bounce pages. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_fscrypt.md 5. f2fs is tested on an image with inline_data,compress_algorithm=lz4: 5a. INLINE_INODE — lots of tiny files; 5b. REF_RESOURCE + general writeback — buffered write churn with fsync; 5c. ONGOING_MIGRATION — force GC / page migration; 5d. ATOMIC_WRITE — atomic-write ioctl path. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_f2fs.md (I did not run xfstests) 6. MM selftests passed. LLM use === Claude was used to form a concrete plan on what code needs to be changed and how to change them. The plan was reviewed by Codex until no issue was spotted. Plan is at: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/plan.md I then followed the plan to make code changes. I did bounce ideas with Claude how to change fs/erofs, since I did not like the original idea. After each change, I asked Claude to review my code and git commit message. I also asked Claude to give me test plans (see above). At last, Codex was used to review all patches. Comments and suggestions are welcome. Thanks. Assisted-by: LLM Signed-off-by: Zi Yan --- Changes in v4: 1. dropped set_page_private(0) in balloon_retrieve(), since page->private is cleared at that point. 2. simplified the comment in add_hugetlb_folio(). 3. additional cleanup for f2fs to remove fio->page uses and convert PAGE_PRIVATE_* flags and helper to folio-only. 4. added a comment for __readahead_advance(). 5. added core-mm split/migration interaction information on newly added folio_attach/detach_private() for erofs. 6. renamed folio_test_fs_private() to folio_has_attached_private() and merged the commit introducing folio_test_fs_private() into its prior commit. 7. adjusted the patch subject: "treewide: remove folio_set/clear_private() *usage*" 8. split "treewide: replace PagePrivate() with page_private()" into three. 9. moved some comments in "treewide: remove PagePrivate() and PG_private from comments and docs" to prior patches along with code changes. 10. used PG_folio instead of __PG_folio to avoid additional code change in __def_pageflag_names(). - Link to v3: https://patch.msgid.link/20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com Changes in v3: 1. changed folio_test_fs_private() to check PG_swapbacked instead of PG_swapcache for excluding swapcache folios. Because folio->private and PG_swapcache are not set as a whole, making folio_test_fs_private() give false positive, whereas PG_swapbacked is always set for swapcache folios. 2. added __DEF_PAGEFLAG_NAME() to show __PG_folio instead of open code. 3. f2fs change is picked up at https://git.kernel.org/jaegeuk/f2fs/c/5ad9409a9533, mm-new currently does not have it, so the patch is sent for MM testing purpose. - Link to v2: https://patch.msgid.link/20260831-remove-pg_private-v2-0-3668159cd9e8@nvidia.com Changes in v2: 1. removed is_first_zpdesc() in patch 1 and open coded the checks. 2. fixed wording in patch 2's commit message and clarified page_private() also works when ring buffer's AUX page order is 0. 3. removed the empty loop in 64-bit gnttab_pages_set_private(). 4. clarified folio->private will be reset to NULL by fscrypt_free_bounce_page() in the commit message. 5. clarified why hugetlb needs to restore hugetlb_vmemmap_optimized. 6. renamed readahead_folio_reverse() readahead_folio_last() and reimplemented readahead_folio_last() by adding a new readahead_control private member, _forward, and a new helper __readahead_advance(). 7. added a bias, 1, to erofs I/O counter, so that folio->private stays non NULL between folio_attach_private() and folio_detach_private(). 8. converted more call sites to use folio_test_fs_private(). - Link to v1: https://lore.kernel.org/r/20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com --- Zi Yan (16): mm/zsmalloc: replace PG_private with pointer comparison perf/ring_buffer: stop using PG_private as AUX page high-order marker xen/grant-table: stop setting PG_private on pages for grant mapping fscrypt: stop setting PG_private on bounce page mm/hugetlb: use direct assignment instead of folio_change_private() f2fs: stop using PG_private f2fs: convert the ->private flag helpers to folio-only erofs: mm/pagemap: add readahead_folio_last() to avoid folio->private erofs: use folio_attach/detach_private() instead of direct assignment mm/page-flags: check page/folio->private instead of PG_private treewide: remove folio_set/clear_private() usage ceph: replace PagePrivate() with page_private() md/md-bitmap: replace PagePrivate() with page_private() buffer: replace page_buffer() with page_private() and delete it treewide: remove PagePrivate() and PG_private from comments and docs mm/page-flags: remove PG_private Documentation/admin-guide/kdump/vmcoreinfo.rst | 2 +- Documentation/filesystems/vfs.rst | 6 +- arch/x86/events/intel/bts.c | 3 - arch/x86/events/intel/pt.c | 6 +- drivers/md/md-bitmap.c | 7 +- drivers/xen/grant-table.c | 11 ++- fs/ceph/addr.c | 8 +-- fs/crypto/crypto.c | 2 - fs/erofs/data.c | 16 +++-- fs/erofs/zdata.c | 13 +--- fs/f2fs/compress.c | 35 +++++---- fs/f2fs/data.c | 2 +- fs/f2fs/f2fs.h | 99 ++++++++++---------------- fs/f2fs/segment.c | 2 +- fs/nfs/file.c | 4 +- fs/nfs/write.c | 2 - fs/proc/page.c | 1 - fs/ubifs/file.c | 8 +-- include/linux/buffer_head.h | 6 -- include/linux/kernel-page-flags.h | 1 - include/linux/mm.h | 35 +++++---- include/linux/mm_types.h | 4 +- include/linux/page-flags.h | 43 ++++++++--- include/linux/pagemap.h | 64 ++++++++++++++--- include/trace/events/mmflags.h | 2 +- include/trace/events/pagemap.h | 3 +- kernel/events/ring_buffer.c | 7 +- kernel/vmcore_info.c | 1 - mm/huge_memory.c | 3 +- mm/hugetlb.c | 7 +- mm/migrate.c | 3 +- mm/page-writeback.c | 3 +- mm/vmscan.c | 2 +- mm/zpdesc.h | 2 +- mm/zsmalloc.c | 24 ++----- tools/mm/page-types.c | 2 - 36 files changed, 228 insertions(+), 211 deletions(-) --- base-commit: 3833e2f6aa6bf6af169f78a27843dfa2804be5a6 change-id: 20260728-remove-pg_private-cfe926c7f83c Best regards, -- Yan, Zi From xen-devel-bounces@lists.xenproject.org Mon Sep 14 04:21:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 04:21:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420405.1646744 (Exim 4.92) (envelope-from ) id 1x5yCW-0006o2-4s; Mon, 14 Sep 2026 04:21:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420405.1646744; Mon, 14 Sep 2026 04:21:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5yCW-0006nv-19; Mon, 14 Sep 2026 04:21:52 +0000 Received: by outflank-mailman (input) for mailman id 1420405; Mon, 14 Sep 2026 04:21:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x5yCU-0006mk-0V for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 04:21:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x5yCS-00EHuD-Lx for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 06:21:49 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7763a-8faa-0a2a0a5109dd-0a2a4504d3bc-16 for ; Mon, 14 Sep 2026 06:21:48 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7765b-b57f-0a2a45040019-5a9b32229600-3 for ; Mon, 14 Sep 2026 06:21:47 +0200 Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1x5yBr-00000008huW-1WeH; Mon, 14 Sep 2026 04:21:11 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=XIa/QTT2Vtv8NiYChAuw57Ae+l0UAwkEY31SNMwQavs=; b=VHq/c8Pp7UCdPy63XwI1Y7/evy Zs6wNzMUH3y9lsWgsWNb5RSGYeSQu3+dwRZdgXhGjQadm2skLDAn/gsZQSr0RPAMMeECDGpa+etFJ GZ9W0qUhgJ+QpqD56J7NZ5uRTrraPD2HDAatD107Dp3uDh0n+iOUAQepIYxNbT07CT1OivKUu4rqR 9T7pMp18HVSaFbknP5sOsW0VTb6JH/cNVnoDNqHZ/wAn8VlL9cIRO8bUeAaRAYVhxkupw1SgasBjf 4D0IoMEvGnWlzdIMpEsme0E/QLtp6CUPuirl9Z1VPsWGxuq6MgoCtKLvy6o4mAhIx6zXHL2D24MjY lZwDMIbg==; Date: Mon, 14 Sep 2026 05:21:11 +0100 From: Matthew Wilcox To: Zi Yan Cc: David Hildenbrand , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, Oscar Salvador , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Tal Zussman , Gao Xiang , Jan Kara , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-trace-kernel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , ceph-devel@vger.kernel.org, Song Liu , Yu Kuai , Li Nan , Xiao Ni , linux-raid@vger.kernel.org, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org, Baoquan He , Pasha Tatashin , Pratyush Yadav , Jonathan Corbet , Dave Young , Shuah Khan , kexec@lists.infradead.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Message-ID: References: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> X-purgate-ID: tlsNG-ebf023/1789359708-502E4B50-BE073396/0/0 X-purgate-type: clean X-purgate-size: 317 On Sun, Sep 13, 2026 at 10:23:58PM -0400, Zi Yan wrote: > md/md-bitmap: replace PagePrivate() with page_private() > buffer: replace page_buffer() with page_private() and delete it Sorry, looks like I screwed up git send-email usage. I'm proposing replacing these two patches wth the three I sent. From xen-devel-bounces@lists.xenproject.org Mon Sep 14 06:22:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 06:22:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420441.1646751 (Exim 4.92) (envelope-from ) id 1x604j-00004t-AZ; Mon, 14 Sep 2026 06:21:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420441.1646751; Mon, 14 Sep 2026 06:21:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x604j-0008WS-7w; Mon, 14 Sep 2026 06:21:57 +0000 Received: by outflank-mailman (input) for mailman id 1420441; Mon, 14 Sep 2026 06:21:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x604i-0008WK-A1 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 06:21:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x604h-002axN-GV for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 08:21:55 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa79274-8faa-0a2a0a5109dd-0a2a4504ea7e-22 for ; Mon, 14 Sep 2026 08:21:55 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa79282-b57f-0a2a45040019-d155802fede9-3 for ; Mon, 14 Sep 2026 08:21:55 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so31588035e9.1 for ; Sun, 13 Sep 2026 23:21:54 -0700 (PDT) Received: from ?IPV6:2003:ca:b735:686c:f5c4:7858:246b:ca62? (p200300cab735686cf5c47858246bca62.dip0.t-ipconnect.de. [2003:ca:b735:686c:f5c4:7858:246b:ca62]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d26c1bfb5sm400672555e9.5.2026.09.13.23.21.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Sep 2026 23:21:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789366914; x=1789971714; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=PaTnWN4YUI+J/59owkxYy/hOMub/sgSXwVppVvNcXGw=; b=TtpvdLfchZmvL/F4b5/xZu/wIQUOI/bneer/hgBxZAk2VYDpM/fArbivBuiR2T8bek FrA1V8i+alj4H+sGo0OqG7fz9bjgDHUtp7OIJ+TrMWM8QHoZNMni3OEuCFEBSV7o+aMI cprJcGSubr+bCFSgbLtdlAstH1YKpP9keUKY49tb5lKprguEHZceNajZHkDvkjIl4Cts 5Z1229d/LsB3r1VwV1oL/R4tfK3w1/Aok0wsmCjKjJe06LYG9MymMwr18b70GXkS40YK yBgfB4tgXRilyRk9CHPoznEnjYi1vTHsHs67/ERZ0p+aonedCsspBOzDggG44sIUqGpp DI3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789366914; x=1789971714; h=content-transfer-encoding:content-type: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:content-type; bh=PaTnWN4YUI+J/59owkxYy/hOMub/sgSXwVppVvNcXGw=; b=B/sw8c7keAVlcjCDlUXfZSHlYcI9aUkBrfGU59Lv61p/WMHPTJchvWxkxakahJ9cmX U3MLHTB/U8lbEXLKGEv6SujMmD902sjJewbKFDBhrc2hTtEqogrpq+NTX4g7/VyxvTlK IbGqkLuhBdLFjcgJjhO5AiAnmGaCTqknKsACz70a6lxbIv8ss7VaHlTe1A7RUE0wivRt Z0yachpQzlGxXqTiNI2zmuUO93CbS8uhLEqfZerpc/EuGMUBuOh98XoBLpAD/pzJWxck u2WNGcLI41Z0b0qrSJTdMps0FtFMDlYJzuHTwG3LcEUrgr2v+iXmpCLBy7sXuFibgw5f kIgQ== X-Gm-Message-State: AFuF++mnqyrZsutano69P2+ExSCTA6CIuyzUoVzB+UIVSKoZQyDjBBSU WdLAA9UGzQmQEtSwGuCdGvRoiniG77hUWvKSYEqBg29Kt39fM2DWAncj4J6Jzr7rYA== X-Gm-Gg: AYBFou0WsAnzHIMw/hiR34JqallUdcQIEUebyoPmucNblKn+FLAzLH2peE/YJx01WbT E+H5x+QuNSzw6NoRmtPVq3714R/GP/CnUWjEn8YOcqgtTdRluM/glrAFa5cvwqOUpIxtKVKdqtv QZaNhWLi3fpLE6BZQeRqk//yVl9Kl50Vj2INC1JnprJTthr4cizn1PgfyY3vlEa4i54m71NgSWp 2m+NmXNG7Mkpf3bmms1cbBSTNzKtUtlrN9L/q7OWoOo/FANTyT8oWq158SdMzMmF0nqbZzUE04M WHKzeJ8jyCvaV6EnpTyHhINnYyxxU3fg1XMNQf3sX2fB07gX/gY07Hu/0AJkRwWaM1pp8sBoQ3Z +8NzuYj9VfSy+ObpuJoI3AOXT+szNtdMEsl5/X4SrWAeX8XO4QUqgBSm5e624DvjWBbMia5bXjy ehYyTq/Y48vquc1niQ5lN7gy2gaTyyOWlwCACkSwwrZPBh2qhYUgXYL4I9H9A6OE1vRCXJafIiG gr9ERh1PHe6l4oj3FstEJSg8MMdz+HN7tVYlIuHLPfWZxgMbzFo43+bK8l6A0jTpi3bRhelvPCW aDgDsmFdaTp8hVWiEd4hIbXNs12LC4c= X-Received: by 2002:a05:600c:3b9f:b0:49c:fc6c:be1b with SMTP id 5b1f17b1804b1-49e7a691b0cmr14279005e9.33.1789366914515; Sun, 13 Sep 2026 23:21:54 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 08:21:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] x86/domain: address Misra rule 11.1 violation in reset_stack_and_call_ind() To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@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 X-purgate-ID: tlsNG-ebf023/1789366915-C2AC8B50-65F0AB83/0/0 X-purgate-type: clean X-purgate-size: 1589 On 12.09.2026 17:09, Nicola Vetrini wrote: > On 2026-09-03 13:43, Jan Beulich wrote: >> Eclair dislikes both sides of the comparison to differ in noreturn >> attributes, thus deeming this a violation of "Conversions shall not be >> performed between a pointer to a function and any other type". Since gcc >> doesn't permit use of "noreturn" types used in a typecast, resort to >> typeof(). >> >> No functional change intended. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Nicola Vetrini Thanks. >> --- >> Really Eclair's diagnosis is misleading here, and not only because of the >> missing "noreturn" there, making both sides be identical: There are no >> implicit conversions performed on this kind of pointer operands of an >> equality expression. A diagnosis of "comparison of pointers to different >> types", along the lines of what compilers use, would be more to the point. > > The point here is that the types are not identical, if you consider noreturn as part of the function type (as clang does) or not (as GCC does). This is the reason why we err on the side of caution and diagnose this, and it's not likely to change in the near future. Perhaps we could make the violation message more explicit about the motivation of the mismatch. Yes, they are different by "noreturn", but that's completely invisible from the report. That's the whole point of the remark: By its wording, the report at the same time says there is a violation just to use what's quoted to indicate there's none. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 06:23:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 06:23:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420448.1646762 (Exim 4.92) (envelope-from ) id 1x606B-0000dN-Me; Mon, 14 Sep 2026 06:23:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420448.1646762; Mon, 14 Sep 2026 06:23:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x606B-0000dF-Ht; Mon, 14 Sep 2026 06:23:27 +0000 Received: by outflank-mailman (input) for mailman id 1420448; Mon, 14 Sep 2026 06:23:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x606A-0000d7-7K for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 06:23:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6069-002RpJ-JW for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 08:23:25 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa792c8-bab6-0a2a0a5309dd-0a2a45028f16-30 for ; Mon, 14 Sep 2026 08:23:25 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa792dd-6ca4-0a2a45020019-d1558034edef-3 for ; Mon, 14 Sep 2026 08:23:25 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so31599305e9.1 for ; Sun, 13 Sep 2026 23:23:25 -0700 (PDT) Received: from ?IPV6:2003:ca:b735:686c:f5c4:7858:246b:ca62? (p200300cab735686cf5c47858246bca62.dip0.t-ipconnect.de. [2003:ca:b735:686c:f5c4:7858:246b:ca62]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e636f7fa2sm292322915e9.15.2026.09.13.23.23.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Sep 2026 23:23:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789367005; x=1789971805; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=fKN4h53ktpL+hbHe/If/KjkGr+4e1PqXhD/nt/CltO4=; b=e2ZtZxchp9cSlnniiNUcOozTOuTF5Ef0VCnwGt2NubS9NHkH21/8rNSQRzd2PhWG03 nQbN/ELr9V6gqivVneeIkB16+wfBM+woV2Z+k1UhKBMrCYw+/OZsYDWR30O20nR2PH7u VbTh4fujratMx/v2Gucc34MO54LasgBtUQD9A2fSt6Z3Y64X30/5Qtt2meqfHBB2nani +7LV8zAUoUtPR3gwK6oApnmCkDJnH0Jx7/xI2dVrpgu6U9pZD9H2WKgYWvdYbEbaE1+A PNseTZABkHcTWiLuQxY7cb1jPsmWcd+KzGWkq6GbwXsvhLJArKRtNoJziQPA3851WOOB 5r3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789367005; x=1789971805; h=content-transfer-encoding:content-type: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:content-type; bh=fKN4h53ktpL+hbHe/If/KjkGr+4e1PqXhD/nt/CltO4=; b=KTWoC5YmqDd/g5pxst7CR/HUpPrJfdtNo0R9kMdht5wD09R4dDPPqNruqcvWY2UtBz upO5/YjT4YH3STtk/JJh3+Caz60rYgkwb4QrrVK+/aMO79rl3a61wZ+rNlL5NYuzxAn2 P72hQi8KPK3dd5emD0QF/ji3nmuh0XtmPzmHOQEvAn1HB0pE3LmzbKs9M9o8VFjvtM/1 IuB8NhlUp9jHYuF/YBixxCp1w7GmSypDqEjv20z+BnL5+w8ppS4AiYaYskuBlrezW23/ WbzNj+498G4e1x3p+MVdeupHe6XdP98kw3J2kkeKLq4iOzgK0BRMxJEYc+RccfTyYA8J Lyxw== X-Gm-Message-State: AFuF++l0drZermoYUENuBBqOvZ1ZMf7liCqF16NCmfUl6itXMqohSxyA 8uS7z+vsUuQHW3+M40HXlbVPKowrcocfBJkoxT7P94TfLljDBywA/ettvMJQWo2lHCeakN8iSh4 oBew= X-Gm-Gg: AYBFou2HOhQ2GSCf4+UF9Rh6G1ZipS6va038XQKeZskX8szN7eR5dxnGLpG5oPii7Co 5DAtX+EcY794Lf4MTxM3fAYRlupNt6bvo3lcEWq93QNeYx2TRdp3pMbKso2Ey4flRooIVSHBb6I WONhCkIG7yhgr9NipzVtUkAPAuC39Dfty0xq6CneJnlKKhUp3sN0U47FPFBvqXppkgBEyBbJK7R WXhE8bjFtgmNXbHq1P/GWKZAVQ12jglZxhRCRjkwIm5i3CkdlOOXGGRQGuL7j7mKkfo5mz8hF6V XeW11rk9l6kXli3e4V8GPIMWfrm+5IXn6YSIpuWVqQWuSXHCdW/WwhRcelopJC9ieB8q9CeL54d w/ka+UTg88Nm0PIrKyYOxF2VRQ3kVZLm/WJH60teGD4sxKUMvBSP9RxxZDh1ExpEanEOAB7K9v9 WP3gsCIPDyxSWVJaONb6eJLCKKXAl8O6wmPyhc7IX4XtyEtio/2tJyhWoYQNgas4Wp50s9vhxGY jWhxlhXA12Ji9sJrub9UR6oxf6RXxcs09PhXLbBXuyPLVU2tkQ2pXXUgyIJNg0aM4nHBfVIdtIH X/5j4EjfKYCcodSzz9VXEntfwHIH11WnTPN1YDxhHg== X-Received: by 2002:a05:600c:3b9f:b0:49c:fc6c:be1b with SMTP id 5b1f17b1804b1-49e7a691b0cmr14344315e9.33.1789367004962; Sun, 13 Sep 2026 23:23:24 -0700 (PDT) Message-ID: <3b6b2796-b532-4b6b-8b04-8edce203ad3d@suse.com> Date: Mon, 14 Sep 2026 08:23:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] Eclair: relax long <-> function-pointer conversion deviation To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> <43e412de9e5165f33c572841bfc58dc9@bugseng.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: <43e412de9e5165f33c572841bfc58dc9@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789367005-31FD62AC-804A90E8/0/0 X-purgate-type: clean X-purgate-size: 2229 On 12.09.2026 17:19, Nicola Vetrini wrote: > On 2026-09-03 13:43, Jan Beulich wrote: >> What is true for unsigned long is also true for plain/signed long, thus >> also taking care of two instances of __x86_return_thunk() being cast to >> long. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Nicola Vetrini Thanks. > Some nits below: > >> >> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >> @@ -368,17 +368,17 @@ constant expressions are required.\"" >>  # Series 11 >>  # >> >> --doc_begin="The conversion from a function pointer to unsigned long or (void *) does not lose any information, provided that the target type has enough bits to store it." >> +-doc_begin="The conversion from a function pointer to [unsigned] long or (void *) does not lose any information, provided that the target type has enough bits to store it." >>  -config=MC3A2.R11.1,casts+={safe, >>    "from(type(canonical(__function_pointer_types))) >> -   &&to(type(canonical(builtin(unsigned long)||pointer(builtin(void))))) >> +   &&to(type(canonical(builtin(long)||builtin(unsigned long)||pointer(builtin(void))))) >>     &&relation(definitely_preserves_value)" >>  } > > could be canonical(builtin(long||unsigned long))||pointer(builtin(void)) > >>  -doc_end >> >> --doc_begin="Conversion from unsigned long or (void *) to a function pointer can restore full information, provided that the source type has enough bits to restore it." >> +-doc_begin="Conversion from [unsigned] long or (void *) to a function pointer can restore full information, provided that the source type has enough bits to restore it." >>  -config=MC3A2.R11.1,casts+={safe, >> -  "from(type(canonical(builtin(unsigned long)||pointer(builtin(void))))) >> +  "from(type(canonical(builtin(long)||builtin(unsigned long)||pointer(builtin(void))))) >>     &&to(type(canonical(__function_pointer_types))) >>     &&relation(definitely_preserves_value)" >>  } > > Same as above Okay, I'll happily adjust. As I have no reference for the syntax, I just have to guess when making changes. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 06:27:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 06:27:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420465.1646771 (Exim 4.92) (envelope-from ) id 1x60AK-0001I9-4x; Mon, 14 Sep 2026 06:27:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420465.1646771; Mon, 14 Sep 2026 06:27:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60AK-0001I2-1i; Mon, 14 Sep 2026 06:27:44 +0000 Received: by outflank-mailman (input) for mailman id 1420465; Mon, 14 Sep 2026 06:27:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60AI-0001Go-9k for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 06:27:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x60AH-00EaWK-MZ for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 08:27:41 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa793dc-e002-0a2a0a5209dd-0a2a45079318-14 for ; Mon, 14 Sep 2026 08:27:41 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa793dd-b4ea-0a2a45070019-4a7de14cde45-3 for ; Mon, 14 Sep 2026 08:27:41 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-484366874b0so849581f8f.2 for ; Sun, 13 Sep 2026 23:27:41 -0700 (PDT) Received: from ?IPV6:2003:ca:b735:686c:f5c4:7858:246b:ca62? (p200300cab735686cf5c47858246bca62.dip0.t-ipconnect.de. [2003:ca:b735:686c:f5c4:7858:246b:ca62]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb33ee8bsm24661901f8f.15.2026.09.13.23.27.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Sep 2026 23:27:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789367261; x=1789972061; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=mwmp9WPS7lTMWpQjfMoDaH5ulNLhnKsAqa1YMjCOZ5E=; b=gr8Gp2nm9zTBC/QdNaLxiGD48Ox1tOSI0FdKfW39U25/BAFXUiBDF4j3zoBMBgeJ/Z WPu0lzsn5DwWRa1/drSOp3wCfo7otkpnowXu9hPOfgpS8LAfs9hkToyGH3w8H9zCECsh b6aQv1xaagiRpJ1WTaxmlcny4bjl+thsXwH/ZqhLAX/1V6dvU5Ib73sbPeH6IzifErwr T7CrdgX364Ebn/JaOoWEoUUQ9mpquSBtyXQTGEio9pgONnJM6baD75nPE+XlZ+jDAEKg qcZ835MTXbqNKSOdutku4w5NPv2Uv2ZToQpczJ5p+BMteClqX8UqC5VTUfXb9vo1s7EZ J/Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789367261; x=1789972061; h=content-transfer-encoding:content-type: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:content-type; bh=mwmp9WPS7lTMWpQjfMoDaH5ulNLhnKsAqa1YMjCOZ5E=; b=schyUZpmvUbWCr8r3E8Xs7QPnbWUIvms2Dl2sxpuyzzYPgzC7DD9Mw0m+0DNkeW84+ 56fJ6gYxuoHkqianyS3l0ILdKjpzAsTEQrbzUeLP8+YsQ2C8bQVopiiIEv+o+z+RlQVP pPEDKAxBI2kiq10pV1YZaOXcRizuJRW7cBQ8nAWkWcZQvJyMOzASlqeRQYOsIDRKBgpW lYtCQEciiHavznrcPsd0kG9fRTlYsrA3P5nfrjKOoPcRbTFfcSm3M5dckfUzec39rKXE OGnktcXldBJ/77iCjGUHRY+FinisvcFLM6xzDlNzlx1GA+iznIarP0YNrSiD2YJPSQx5 wxew== X-Gm-Message-State: AFuF++lhdy4Iv6qpNZlP1DkWVanBM/LWNBrAyr3UceDH3RG0QRttRNtR mzYG+PVrOtkxl6oPjmutckX6SEQT8QxHmIwleQ39PG6ffWwW9QVuKRZ8Opj2W0jcLA== X-Gm-Gg: AYBFou0uZUhtELDNoU/DPqvFCVcogG5WzLHX363h6EUtTRXE6i4hJXKwZv+9Vk5nFRS zA/0dFwPemQSypI3SGrd/ETcDFgkIgKUCEuI/113s01rp6+mtXYAvm27wLPOtPcf0tCa9pGxyPT znHryzVr3q9kY9CHIaHZwto3f9R7clF34x6DTpV67O4SqTQ4jr9a/bZd9HjHLFyAOzmxg+7r/WC jzzU4SitLG5Exg4JhnLSHy7aVsoW1R5IU+f5tmyrMdlN+Ko0RPQA9vwifCDhqbEddI4oTM31gCe zuhn3/3hCl2SvdihOMGwn1+u1S6GHcT7OBGALTPC6Ptlsp9ywKqvaJ3WDwRrj3RoCQJ7bVxyXq+ QPtMpNh+zsvTciIuJUI+vw0Dm1teFUO+XfH9d08nPeZxeFuUSTPx5eKeB5mwYvGDX0rvkF+PktE aGiYnS597gQ5p7C1mFk0mbG+hYfVAGUF/Sj75gsWOVRYjJRPYiM+9lSdLM0nFcPTGFDk0i351io 2C0ln2s7sHYIR8hg5I2JsaH0vG4fjEES8RgbLpJrMsbajOnT5A6ggr4k0oT5bKvz0cQ4BMvW7AH UyZRdLBuTFL4XwljhVHy+R56nSbPadA= X-Received: by 2002:a05:6000:2403:b0:485:943c:886d with SMTP id ffacd0b85a97d-48702ad29bemr2153065f8f.7.1789367260972; Sun, 13 Sep 2026 23:27:40 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 08:27:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] Eclair: relax "noreturn" function-pointer conversion deviation To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> <4cca58b6-b555-4064-aa26-5204dc4b99cc@suse.com> <3d473b8a85331856ea2b95f9448f2d6c@bugseng.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: <3d473b8a85331856ea2b95f9448f2d6c@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1789367261-A60C5AE4-A74A6474/0/0 X-purgate-type: clean X-purgate-size: 3211 On 12.09.2026 18:04, Nicola Vetrini wrote: > On 2026-09-03 13:44, Jan Beulich wrote: >> Like misra/rules.rst says, function arguments other than "void *" are okay >> as well. >> >> Signed-off-by: Jan Beulich >> --- >> I can't explain why this covers the violation in mce.c:mce_callbacks'es >> initializer, but not the one in mce.c:default_handler's. > > Possibly differing attributes (e.g. cf_check vs section attributes)? Just a guess that would need to be tested, though. As long as its guesswork, it could end up being many (expensive) tries. >> As a result of 6852334f8416 ("Arm/GIC: add noreturn in a few more >> places"), vgic_v2_lpi_to_pending() and vgic_v2_lpi_get_priority() (both >> returning non-void) would also need covering. (As said in a remark there, >> non-void together with noreturn is somewhat odd.) > > Indeed > >> Really before and after this change there's no checking that parameter and >> return types actually match. I have no clue how one would express such >> checks. With this last sentence in mind ... > The presence of a bitcast indicates that the two types do not match exactly. Typically function attributes are not relevant towards determining a type difference, but different compilers may model non-standard features differently (rightly so), in such a way that some make a difference in the AST, and others do not. > > To check for compatibility of function pointers I would try activating service STD.funptrcv, which essentially mirrors -Wincompatible-pointer-types: > > caution for rule STD.funptrcv: (rule) A pointer is used to call a function whose type is not compatible with the pointed-to type. (untagged) > p.c:8.8-8.8: Loc #1 [culprit: implicit cast converts from `void(*)(int)' to `__typeof__(@EXPR@)*' (that is `void(*)(void)')] >   qq = m; >        ^ > p.c: In function ‘h’: > p.c:8:6: error: assignment to ‘void (*)(void)’ from incompatible pointer type ‘void (*)(int)’ [-Wincompatible-pointer-types] >     8 |   qq = m; >       |      ^ > p.c:3:6: note: ‘m’ declared here >     3 | void m(int x); >       |      ^ ... - well, fine, but ... >> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >> @@ -391,11 +391,11 @@ constant expressions are required.\"" >>  } >>  -doc_end >> >> --doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void (*)(void *)' is safe >> +-doc_begin="The conversion from 'void noreturn (*)(...)' to 'void (*)(...)' is safe >>  because the semantics of the 'noreturn' attribute do not alter the calling convention or behavior of the resulting code." >>  -config=MC3A2.R11.1,casts+={safe, >> -  "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1, pointer(builtin(void)))))))&&from(expr(skip(!syntactic(), >> -   ref(property(noreturn)))))"} >> +  "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))))))&&from(expr(skip(!syntactic(),ref(property(noreturn)))))" >> +} >>  -doc_end ... how would this be expressed here? Perhaps best if you would make an alternative patch? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 06:33:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 06:33:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420477.1646779 (Exim 4.92) (envelope-from ) id 1x60G3-00030h-QJ; Mon, 14 Sep 2026 06:33:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420477.1646779; Mon, 14 Sep 2026 06:33:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60G3-00030a-NK; Mon, 14 Sep 2026 06:33:39 +0000 Received: by outflank-mailman (input) for mailman id 1420477; Mon, 14 Sep 2026 06:33:38 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60G2-00030T-97 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 06:33:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x60G1-002Txc-EJ for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 08:33:37 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa79539-bab6-0a2a0a5309dd-0a2a4507d028-24 for ; Mon, 14 Sep 2026 08:33:37 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa79541-b4ea-0a2a45070019-c387df83e0c0-3 for ; Mon, 14 Sep 2026 08:33:37 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id AF4E51F388; Mon, 14 Sep 2026 06:33:28 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 08DF813693; Mon, 14 Sep 2026 06:33:27 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id OLQQMjeVp2qFEgAAD6G6ig (envelope-from ); Mon, 14 Sep 2026 06:33:27 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de"; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789367612; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ovBBaSgMLmlbSMqeNsjr5N8eDdz6l1RmmoDSShj29wE=; b=b16Odrj6bv0wp8OuyHaqBtpbaOjGnP9oDUkPm+RnEC2D3gQBz58ZPlxWU/CttnYcihdRLB W9ckoJDdVx6dO7vo2kVy82bj6PNrKQfv3GtcQ+ydcHEYIk1aK+5a1aeKXOtO+U3RRPmCCK c75mgcfRyGTh09JACGkenPbWXqI+yOM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789367612; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ovBBaSgMLmlbSMqeNsjr5N8eDdz6l1RmmoDSShj29wE=; b=h6IyQ2X3/hGfWruBjt45Bpjm6R/rVrgm2ZI/TWGL/4k6lMvTM7+LcT+bkGZQQ9FfVt1/XJ hDct8kTxT4gIkEAw== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="ov/teEO7"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=MuewFzNW DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789367608; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ovBBaSgMLmlbSMqeNsjr5N8eDdz6l1RmmoDSShj29wE=; b=ov/teEO7U6AxQHEQtbeVuit6+Esb59jvvHc1wnp8vKLnWpfaXRnJSRiSJXNbrsxGrERqD3 D0mM3mmD8XaIRjaEIHsJFOtRxdYqrJ3+DwrfaTqRiF+FmnHQR8cXA+Y7NE6h66cztla/pU 0BQtBNTOLhrKHZrOmvapY0G9AWkuTy8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789367608; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ovBBaSgMLmlbSMqeNsjr5N8eDdz6l1RmmoDSShj29wE=; b=MuewFzNWGNAVPk7ko9iJTbOoyxG+Ut0iz5lpJBigNxT3SjHYUKwlRHFh24JiMS5BoVGv5Q 1gdeuU5ohpB39OAQ== Message-ID: Date: Mon, 14 Sep 2026 08:33:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/8] drm/pl111: replace struct drm_simple_display_pipe with regular atomic helpers To: Linus Walleij , Ze Huang Cc: Alexey Brodkin , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , Joel Stanley , Andrew Jeffery , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Hans de Goede , Alex Lanzano , Oleksandr Andrushchenko , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org References: <20260727-drm-simple-kms-removal-v3-0-cd5dc89858c6@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-4-cd5dc89858c6@oss.qualcomm.com> Content-Language: en-US From: Thomas Zimmermann Autocrypt: addr=tzimmermann@suse.de; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -3.01 X-Rspamd-Queue-Id: AF4E51F388 X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Level: X-Rspamd-Action: no action X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; RCVD_TLS_ALL(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_TWELVE(0.00)[22]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[synopsys.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch,jms.id.au,codeconstruct.com.au,nxp.com,pengutronix.de,epam.com,lists.freedesktop.org,vger.kernel.org,lists.ozlabs.org,lists.infradead.org,lists.linux.dev,lists.xenproject.org]; TO_DN_SOME(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[qualcomm.com:email,suse.com:url,suse.de:dkim,suse.de:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; DKIM_TRACE(0.00)[suse.de:+] X-Spam-Flag: NO X-purgate-ID: tlsNG-ef75cf/1789367617-34CCFAE4-78530B26/0/0 X-purgate-type: clean X-purgate-size: 857 Hi Am 14.09.26 um 01:33 schrieb Linus Walleij: > On Sun, Jul 26, 2026 at 9:46 PM Ze Huang wrote: > >> Replace the PL111 simple display pipe with explicit plane, CRTC and >> encoder objects. >> >> Move the existing timing, format and pitch validation into explicit >> atomic check paths. Use commit-local plane state in the CRTC enable path >> when reading framebuffer format state. >> >> Move page-flip event handling to the CRTC commit path. >> >> Signed-off-by: Ze Huang > This patch 4/8 applied for next. Great, thanks a lot! > > Yours, > Linus Walleij -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg) From xen-devel-bounces@lists.xenproject.org Mon Sep 14 06:40:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 06:40:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420484.1646787 (Exim 4.92) (envelope-from ) id 1x60MR-0004iR-FN; Mon, 14 Sep 2026 06:40:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420484.1646787; Mon, 14 Sep 2026 06:40:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60MR-0004iK-Cj; Mon, 14 Sep 2026 06:40:15 +0000 Received: by outflank-mailman (input) for mailman id 1420484; Mon, 14 Sep 2026 06:40:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60MQ-0004iE-Em for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 06:40:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x60MP-002VMJ-Br for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 08:40:13 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa796c6-8faa-0a2a0a5109dd-0a2a4502b454-28 for ; Mon, 14 Sep 2026 08:40:13 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa796cd-6ca4-0a2a45020019-4a7de14c9f6f-3 for ; Mon, 14 Sep 2026 08:40:13 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6350f88so791182f8f.2 for ; Sun, 13 Sep 2026 23:40:13 -0700 (PDT) Received: from ?IPV6:2003:ca:b735:686c:f5c4:7858:246b:ca62? (p200300cab735686cf5c47858246bca62.dip0.t-ipconnect.de. [2003:ca:b735:686c:f5c4:7858:246b:ca62]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb32d3c7sm22890239f8f.10.2026.09.13.23.40.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Sep 2026 23:40:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789368013; x=1789972813; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=lpdzU9Y4yRt3tzkevqO7DUbsMCpycKpfrbImX2nQAjI=; b=LODrf3exWzIRdaSPX6PCsxK7xR1i6lp1FHuSLyEqOha8ILUm9Vgk+9OTeO6BLHmMaX EhUvefj0ZBLVzhiSD8iInc5syAIbh9Ozo77cwFPRs7Ss69/mI6OaQ/LjiNW9rIUFU+B7 sjGqhuMJBqI/uzJYiXY5qq6RLhVfu24GdA3ZHnwepKEOtIDTP+vN8TVfGv9gWmI9XpOy NORaDLxXL86kpbqSXmW34LQdhT1T5D1Q2WiVmXug0KskVoNdwUpDHMZgNBaNunrNYAVY nhiTAfw3lMjsj6KzW5YkXy87o0Ke6S5eSsVTK7PyhtEmVPhcpVEodBFWtuZIbea0cGXL 6DCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789368013; x=1789972813; h=content-transfer-encoding:content-type: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:content-type; bh=lpdzU9Y4yRt3tzkevqO7DUbsMCpycKpfrbImX2nQAjI=; b=fgjZo4waFjZKk46G5z+ow79X+/j/qKRfwPKsGnz8yN3V5TxPEha7ugcOlKbJZmTG2z n6uJ02nga52M/bGldlhsEYYLuDQYEdywq40Dwd/fTI24KhIyoXRa2hV0GHXkPFQ4CMkt TCAr165lX8KfDUPRbDQcEq1BdYj6kpt3SklGXPpgbwEW13GUbBOKHDwJ9fH+qyJAuMLL raUXVV3ZhnS9egUk8uyuI0lQk8rnswOuYOMCij1wdxA2K+zMK2/8sG/uFEZc7fwfU4s2 8vcpKP2MSC0LEPXqYbZqnLlYgbxpQg56VU3vGUQZsh4RKVSCn5epVk7Q1kHsJn1mt4en j2wA== X-Forwarded-Encrypted: i=1; AKwUvByMvilXbLz0nQVPMBXEMZtoyH0Ikfrz43UpieZcz/iRSFUMC3TA7WmyAOPdlktFTZ3Yobz/1J2zCy4=@lists.xenproject.org X-Gm-Message-State: AFuF++mRAzQ6i6f74bCOk+TqvJrc0EMDeDNZpeA45bknBIinPH5cFRcX z1Naiex4xlYpV8CBbeRz8MkIhe9/Sgjk2jmWJiktef9ABVQ+mCT+Fj3zaxVOToYVXA== X-Gm-Gg: AYBFou1i+vJBdsjVxqNHHUBa+3Y2JEXlzk9eBtD2C/vNRKa0P4WWCgeaNKIXY5fu66o uyJW5xU2lJCfMbXSv98kMYVtHcmdyLFtCQuhPPwDWtkEI8Ueml7U8DoWeAFi2SNtmibnFciFwCv 2IrCHiELk3kzZX6LhXAhq0HWjNQSa3oqYPuJnFALU7ZGu5OiD6HCvAJv7r137mJho5YFhFgcUx2 GSWlZHCTQCVOJD67weD8TQ+zQ+VJGgFuTlYbwolCWF47Zl+pA8wF0lgh34PsDuaAA5+50Q4/+1k 3o1H0/rIJyFEP2jDGVNlMlf7cKwmdTjSWmRz8/R9o2TRZqzVHwqTas0wte3YeJkddBqWTMvRUvQ sT4Ttu547DMaY5S80F+1DAQQ4mUFQo2NAABebjpihFuwS0G4wKPTRsoU0CWXGzAbrNFIQYdvT1s Y2fzTdg/f6VbY0CEfkAlW3tdyotW5XSxzI/5vGl2KmhskhXs+Z6V5F3tvKFd3y8lWSykXpp3jxC lJ1G8FW0bneVIWIdM8deeXcJbmryyNlD8u9XFraHcH1R+PvFir7U0OhKH7bzlC5UkaAiHW7esBM TtmV0JjclED/zyt6l+Hn3R7Vxrflgc8= X-Received: by 2002:a05:6000:4281:b0:485:8c17:9761 with SMTP id ffacd0b85a97d-48702aff858mr1201254f8f.35.1789368012751; Sun, 13 Sep 2026 23:40:12 -0700 (PDT) Message-ID: <05aebcad-fb84-4f11-ace2-80c0da7f0e9e@suse.com> Date: Mon, 14 Sep 2026 08:40:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/build: Remove leading space in xen.efi.S rule To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260911201601.3682596-1-andrew.cooper3@citrix.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: <20260911201601.3682596-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789368013-F26B72AC-93B5CAAB/0/0 X-purgate-type: clean X-purgate-size: 405 On 11.09.2026 22:16, Andrew Cooper wrote: > It happens to be benign, but it causes emacs to ask: > > Suspicious line 194. Save anyway? (y or n) > > whenever saving the file. > > Fixes: da944a72fdf4 ("x86: split xen-syms/xen.efi linking rules") > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich No idea how that had slipped in. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 06:44:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 06:44:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420491.1646797 (Exim 4.92) (envelope-from ) id 1x60QB-0005Io-U4; Mon, 14 Sep 2026 06:44:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420491.1646797; Mon, 14 Sep 2026 06:44:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60QB-0005Ih-RH; Mon, 14 Sep 2026 06:44:07 +0000 Received: by outflank-mailman (input) for mailman id 1420491; Mon, 14 Sep 2026 06:44:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60QA-0005Ib-M1 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 06:44:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x60Q9-000AY7-Uu for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 08:44:05 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa797a9-8faa-0a2a0a5109dd-0a2a450cdd74-8 for ; Mon, 14 Sep 2026 08:44:05 +0200 Received: from [209.85.221.49] (helo=mail-wr1-f49.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa797b5-f479-0a2a450c0019-d155dd31e56e-3 for ; Mon, 14 Sep 2026 08:44:05 +0200 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso1943044f8f.1 for ; Sun, 13 Sep 2026 23:44:05 -0700 (PDT) Received: from ?IPV6:2003:ca:b735:686c:f5c4:7858:246b:ca62? (p200300cab735686cf5c47858246bca62.dip0.t-ipconnect.de. [2003:ca:b735:686c:f5c4:7858:246b:ca62]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb34f353sm23631237f8f.26.2026.09.13.23.44.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Sep 2026 23:44:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789368245; x=1789973045; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=6xguFSnOSYw+2MbbJX+zFbpoRsJjaPMvT3MEKHOb3FA=; b=aVEcGDefdS7jFVcZrzB/aDJUzHLnymLPkKjkfC5W8ILj3vIgpeXE9f8Jj0EE3pGOiW m7T6jpTDvxy2EsIdJlMfKpP5vkopn+bjXf+oA7IEYLwxJQ/P0N2juYswI2wh5A5myntN JeR0Gy415UjIFQu2w3jEGFE+nF4d/lyhlKQmT9ey3nbsfRDZzj9+REgPfhGqUk9qCH8X MVkFApMtTi3IsY++CdITVi0pRwCRWQU9TpnRF/SJiUcOEK6a8mf81c1YyVYyVSCypCQ6 TdkirgORF6YTy/lwmU1c9uiqCfKNRTeh7NHURU4FbMhBql3QJMPalQYLDj78Xz/X8zDp dtnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789368245; x=1789973045; h=content-transfer-encoding:content-type: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:content-type; bh=6xguFSnOSYw+2MbbJX+zFbpoRsJjaPMvT3MEKHOb3FA=; b=pDV0g2a7sqI3m7336OG1ddy+V6jaL8j/yC19Pqpr243mlzKPaIZASYZe67VibAUEkx VQSAqLuW8iRSJ/dNmDStLXF+Yb1ApruHfKxf3D8WyVTbsqiRP9zybP0k77ox+B+9+gHQ o+V41JTgldcMSmD0hr6fmy+83e7CnRf5m+IfW+XVyvwf6o7agEvr6JI5opzYt6HTaJOA /2sZNwXETAqkaIfEWgeReCUk9yf2Jrkd0b5s2/MY9ENBfw7oxlpqVPcl3q4UZJ6qfVoc e9rC6BF6Psd331TqYg9Ojc5L+v2cxJojIMsGUGwL+gvvHs5ixAuLF9WYZWL3xHX1GvsC jLxw== X-Gm-Message-State: AFuF++mCBvCeXgsJZPTi7kPR+Y7jx3cVUhb9munFzSGFegcKui+M7meq JJPpU4+79WKFHhMkFUToLnDR4VsJQgDHtn5K9zQi3R62M0Se+U8uA9LwgrS5uYL/Fg== X-Gm-Gg: AYBFou1te9SLBjfZYOU+SgS0tOG7f0Ij9bGKzPPuEVCghjfS+e4n9+tWxCpktciBieL yHuKBF8ug/nL6Cp+pk0z5ttI6IAZSnHqP6qSFgc/GkBqBbfrvd21pWxjV/9Pg0Mimqeg+fQzMna +Og18LaBpLLgNjA0SUdczK7WLw1D6ayubgyo4z+hM7BVBMaEp4wMc0uihkOAWToUZv6PDDdMBhV uUPh6tYeFiLHt5zgvrNzyazapxvkEkKwuspYcLAwpRKqWz6lLUu353dDCiJhQ6OFAZk9kVm7oPG 1Cw+bk3pl5vInBxthCmNeMSWJRQ8MwjD46/qS8pwhj5x2J5t1t7o9Bevr9un109OldfeltXnLLc J1W7DLRG5yIQbJk9c5y6g9GS5xToXxh3xopFyhyuFUMikRHw+yqNpV8D0vo63xqK9Idzp/Q/P8Z oeXRSz8E4KSDYELzcgFt2egwc9nEjpmGNlEahWd5wklij4lNGjYmMF0CugQymZ8hBqbgH9YD1CV p63Kg5SMvVa3g5pPFeP3yrsCVlmGWCUpbNbsRNyS9u60//vwz+z2xT85EBRfTUvf7LlRtRnaDF7 BVZ3HW4sKPEO5WP11qraYlFbtjjme0o= X-Received: by 2002:a05:6000:290c:b0:486:f285:396 with SMTP id ffacd0b85a97d-48702b35091mr1077617f8f.52.1789368245385; Sun, 13 Sep 2026 23:44:05 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 08:44:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <96de425a-29f7-4759-8466-b72bbe40b90b@suse.com> <46dcfb81294d6f644a4d3f3c11b1f47e@bugseng.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: <46dcfb81294d6f644a4d3f3c11b1f47e@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1789368245-02EDAA5B-52068D76/0/0 X-purgate-type: clean X-purgate-size: 2658 On 11.09.2026 20:53, Nicola Vetrini wrote: > On 2026-09-10 14:29, Roger Pau Monné wrote: >> On Thu, Sep 10, 2026 at 11:52:10AM +0200, Jan Beulich wrote: >>> On 10.09.2026 11:30, Roger Pau Monné wrote: >>> > On Thu, Sep 10, 2026 at 10:38:34AM +0200, Jan Beulich wrote: >>> >> On 10.09.2026 09:49, Roger Pau Monné wrote: >>> >>> On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote: >>> >>>> The use of unreachable(), when unreachability is visible to Eclair (and >>> >>>> compilers), is deemed a violation. Drop the redundant statement. >>> >>> >>> >>> Urg, isn't that something that should be fixed in Eclair then? >>> >>> Otherwise all the unreachable() calls in our codebase are likely to be >>> >>> found by Eclair sooner or later, and will need to be removed. >>> >> >>> >> No, aiui most are covered by deviations. In particular ones in BUG() and >>> >> ASSERT_UNREACHABLE(). >>> > >>> > Shouldn't this be a deviation then also? >>> >>> Maybe, just that I had no good idea how to express such a deviation (preferably >>> without a SAF comment). >>> >>> >  Maybe it would be helpful if >>> > the commit message states why this is handled differently from other >>> > unreachable() instances then. >>> >>> I've added "..., , and the one here isn't covered by a deviation" to the first >>> sentence. Will that suffice? >> >> TBH, the handling of unreachable() feels inconsistent to me.  I don't >> blame you for this, I know you are just trying to fix the remaining >> issues. >> >> I guess I will defer the change to someone more familiar with MISRA >> and why some unreachable() usages are covered by deviations while >> others aren't. >> >> I think the point of adding something to the commit message is to >> justify why this is removed vs a deviation being added. > > Actually this should be done with a deviation, and I thought it was already taken care of by > > -config=MC3A2.R2.1,statements+={deliberate, "call(decl(name(__builtin_unreachable||panic||do_unexpected_trap||machine_halt||machine_restart||reboot_or_halt)))"} > > namely because unreachable() expands to a call to __builtin_unreachable(). It might be worth checking why that is not the case. Probably the configuration needs a slight tweaking. Question (on my side at least) is: How would such "checking" look like? As said elsewhere, the syntax used in and the semantics of all these deviations are close to impossible to fully understand (which is very certainly different for you). Yet without fully understanding what's written at present, how would one "check" that this is actually what is wanted/needed? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 07:06:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 07:06:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420503.1646806 (Exim 4.92) (envelope-from ) id 1x60ls-0000CO-LI; Mon, 14 Sep 2026 07:06:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420503.1646806; Mon, 14 Sep 2026 07:06:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60ls-0000CH-I1; Mon, 14 Sep 2026 07:06:32 +0000 Received: by outflank-mailman (input) for mailman id 1420503; Mon, 14 Sep 2026 07:06:31 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60lq-0000C9-Rq for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 07:06:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x60lp-008ktn-NO for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:06:29 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa79ceb-2eae-0a2a0a5409dd-0a2a45098500-24 for ; Mon, 14 Sep 2026 09:06:29 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa79cf5-be1a-0a2a45090019-d1558030e8fc-3 for ; Mon, 14 Sep 2026 09:06:29 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49d05d51553so24222575e9.2 for ; Mon, 14 Sep 2026 00:06:29 -0700 (PDT) Received: from ?IPV6:2003:ca:b735:686c:f5c4:7858:246b:ca62? (p200300cab735686cf5c47858246bca62.dip0.t-ipconnect.de. [2003:ca:b735:686c:f5c4:7858:246b:ca62]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e6a06cfb8sm219909315e9.5.2026.09.14.00.06.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 00:06:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789369589; x=1789974389; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=xoxPj2IhIv+iyPAxslvbs7AnEZ1l/sE+nUAbUTgbu4E=; b=L9jh9zG1C/zkaDRm8SBaJPy1ihXVZNX3+umCKNtOKlCTCLuKIM3SkxBLg+5nl/Qghs w7ZuMP5Z5NuUID0MkJsi5AinuksI5Fmy0AX+h8DGEtI9YQpDrEUcSEkLg4SC7kafw68k Hhn5hdXDJ4qlhwwlzzSlryHWc4if4lJkfzVgO4RtSU7V8V0bE6k0JRplsvpyUIRc68qE U8pOBk179nFxKMJu3uJVaz9pKB0fcT8slUpdqYf5WAEY8PgilidhLAbgdLDsTXeR79v3 5jeLJiscL1Vct4OLDuaEtLq/hOD01JRXMg1FcvCTLLCpvnfhjZHCuOBHiFjUp/y6Ew72 4dHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789369589; x=1789974389; h=content-transfer-encoding:content-type: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:content-type; bh=xoxPj2IhIv+iyPAxslvbs7AnEZ1l/sE+nUAbUTgbu4E=; b=JO7DyPSFmRjCXHCBmXSYM20/RzIDV6WlVl0lAu2DlrmWzjNep6voAaQ/qdS0IUbL2P +TPOIySUw34fhVSWItYRN9vKW27eikDhwbL5Y3RYv0WaVpo0qWNfUkA06wjTo78bJ2fB UIGThpYOZxCb0Od+3YJe5oAU7Zm58O3RqioXiXWi3PhSxpKSScoQAUwY0yRU8rvYu+VD BHODqqgQTDEpsC+lQUg9gHUZaTMIbHDJRqOBug7YlWbUNn7XGF9xDgQ2tBqWuIZwVb67 9KH2kRoUHoP0y/ZuFKH586bkZ1jwM2J4JU5O1ga8UAiL9whC/fVqGH1wJ+PC+glw/+Kr +e6w== X-Forwarded-Encrypted: i=1; AKwUvBxFtioNtd9X6bQFeRa/z8qWjXIAwXajabD+4CEbxeriNRl0gI3k7pEVHz2tx9wwTGnR0WRA2nIl2kQ=@lists.xenproject.org X-Gm-Message-State: AFuF++kkFnNukOO6TSydDt3hjyDYfTKn/NiiUpqN4e4XRoUhLOpjekkq d9x1sKR+129BOE5FICj/OSBMEKjnUK52+M4Y2uRcHXzTRXinwQmP0H/gOZovnNaekA== X-Gm-Gg: AYBFou38Uxasav3dqDRANjz9keLK2TD89ZWrlMXz/wFcW+z6WwPJXySh9PJ2MY1nqJJ bIJsc5xgUe2vNxZamw1wNhEpMc0PXa8cR0E+IO5MRHfK2loTd9xkMsZM3aqLkts81rB6tzfJ/qc qZiVtYiy9scwcHfL3M+v2fcqDcxttedW/w27947f6dLxBfV5caLU8qogjKICTLY79cOjylR8Cjz y1qGj6oUelRx7/dFDEWK/PYHsUaugG5wCueTfga9hJ3q+jJqeBUzK3T2fyBrkqbsUby0kIi3rwE 962ZHEeQrfX+v4hDieh0/bgqk1uzXCMlZ674uQCiy7VhF0ZeYirGzynVo6VnTzAlhbhAEEFbjZR mt/aly8MmR744Y+fjd7kVqBNR4exFouVqitXpp7Vuo/MpvcelWnmQtC8SEqUMefLDRMs2ENzfqX HJrlkBJbmc85vWymQ74x3xp9XHtgLAvYRoexw+QvlJ1Au4u9qODJdy/TBoRRZC5MpglR7CzxBb4 uO7GSzRAy6ROPEahHCrEQAdAyuLH9PXNu0/3T/tU/YLXvmZ15pxddtfoBu+/KeTjmQAJxgeOUgz BzKKHjezLOxz2tEzP3qumQKcAM3+ajs= X-Received: by 2002:a05:600c:34c2:b0:49d:17a8:211a with SMTP id 5b1f17b1804b1-49e7a678d3bmr13496945e9.28.1789369589057; Mon, 14 Sep 2026 00:06:29 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 09:06:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places To: Nicola Vetrini , Andrew Cooper Cc: Stefano Stabellini , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.com> <320b920b3e673671eddceccb4b86f211@bugseng.com> <26a57fab-955a-4de6-b17b-eb57aa1f014b@suse.com> <98af89029999f2d0535d603ebf64d9b4@bugseng.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: <98af89029999f2d0535d603ebf64d9b4@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1789369589-BE0C5034-D8A90CFF/0/0 X-purgate-type: clean X-purgate-size: 4194 On 11.09.2026 22:48, Nicola Vetrini wrote: > On 2026-09-10 08:43, Jan Beulich wrote: >> On 09.09.2026 21:07, Nicola Vetrini wrote: >>> On 2026-09-01 08:26, Jan Beulich wrote: >>>> On 31.08.2026 21:13, Andrew Cooper wrote: >>>>> On 28/08/2026 8:01 am, Jan Beulich wrote: >>>>>> --- a/xen/arch/x86/traps.c >>>>>> +++ b/xen/arch/x86/traps.c >>>>>> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu >>>>>>      case X86_ET_HW_EXC: >>>>>>          switch ( vec ) >>>>>>          { >>>>>> -        case X86_EXC_DF: return do_double_fault(regs); >>>>>> +        case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>>>>>          case X86_EXC_MC: return do_machine_check(regs); >>>>>>          } >>>>>>          break; >>>>>> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp >>>>>>      case X86_ET_HW_EXC: >>>>>>          switch ( regs->fred_ss.vector ) >>>>>>          { >>>>>> -        case X86_EXC_DF: return do_double_fault(regs); >>>>>> +        case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>>>>>          case X86_EXC_MC: return do_machine_check(regs); >>>>>>          } >>>>>>          break; >>>>>> >>>>> >>>>> For starters you're missing a break, and the only reason this isn't a >>>>> compile error is the trailing comment. >>>> >>>> "break" there would again be unreachable, though. >>>> >>>>>   Second, it's a tailcall anyway.  >>>>> There really is nothing unreachable anywhere in this construct. >>>> >>>> Just that the concept of "tailcall" is an optimization, not something >>>> inherent to the language. >>>> >>>>> But by far the most important, it the singular noreturn attribute on >>>>> do_double_fault() (elsewhere, and not visible when reading these two >>>>> functions) which is preventing #DF falling into #MC.   This introduces >>>>> fragility which did not exist previously. >>>> >>>> I realized that when making the patch, yet what do you do when the rule >>>> is as it is? Hence why I added the comment, really. >>>> >>>>> do_double_fault() would conditionally return if we ever got around to >>>>> fixing espfix64. >>>> >>>> And hence would have to lose its "noreturn". At which point call sites >>>> would need inspecting. (As said - yes, I do realize the fragility.) >>>> >>>>> So no - I'm going to insist that Eclair is taught to accept "return >>>>> some_noreturn_fn();" as intentional.  It is objectively less fragile >>>>> than the MISRA-preferred option. >>>> >>>> Nicola, thoughts? >>> >>> If you find a suitable argument from the toolchain that the generated >>> code is correct even though you return from a function where you >>> promised not to return in its declaration, I suppose that's fine, but >>> that MISRA Rule I mentioned ("A function declared with a _Noreturn >>> function specifier shall not return to its caller"), which is not (yet) >>> applied to Xen exists to defend from stumbling on UB 71 of C11: A >>> function declared with a _Noreturn function specifier shall not return >>> to its caller. >>> >>> So in general ECLAIR should not accept this by default. What you can do >>> is deviate these (hopefully few) cases if you have backing evidence of >>> the correct behavior. >> >> The disagreement between you suggesting a deviation and Andrew demanding >> "that Eclair is taught to accept ..." will need resolving. The argument >> towards the code being overall less fragile in its original shape cannot >> easily be put away. And Misra demanding code to be made more fragile >> than it needs to be cannot really be the goal either. >> > > Well, I feel like I have explained my reasoning, but let me step back a bit and lay out the possible safe alternatives I see for this construct. By the way, perhaps it's a better idea to split off this change from the other additions of noreturn, which can probably go in as is. Yes, yet on my question to Andrew whether that should cover just the two hunks above or also the adding of noreturn to do_double_fault() I didn't get any reply so far. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 07:11:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 07:11:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420513.1646814 (Exim 4.92) (envelope-from ) id 1x60r4-00021D-Al; Mon, 14 Sep 2026 07:11:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420513.1646814; Mon, 14 Sep 2026 07:11:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60r4-000216-7b; Mon, 14 Sep 2026 07:11:54 +0000 Received: by outflank-mailman (input) for mailman id 1420513; Mon, 14 Sep 2026 07:11:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x60r2-000210-C7 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 07:11:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x60r1-00FfCf-I5 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:11:51 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa79e2e-bab6-0a2a0a5309dd-0a2a4503d16e-18 for ; Mon, 14 Sep 2026 09:11:51 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa79e37-fae8-0a2a45030019-d155dd32e9d1-3 for ; Mon, 14 Sep 2026 09:11:51 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-485850cbac3so1488764f8f.3 for ; Mon, 14 Sep 2026 00:11:51 -0700 (PDT) Received: from ?IPV6:2003:ca:b735:686c:f5c4:7858:246b:ca62? (p200300cab735686cf5c47858246bca62.dip0.t-ipconnect.de. [2003:ca:b735:686c:f5c4:7858:246b:ca62]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb32e8d1sm24992844f8f.11.2026.09.14.00.11.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 00:11:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789369911; x=1789974711; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=y/Cs8HpoX9Yo1ntlNmfm9TtzMXK7PRApDowzUjGq8FA=; b=CybCFDrA4rYNpGf9KOeDOtrzBBfqwCQ9410jzfYw6/FKVR9kSgK48EzDO8hPRA3zYq Tytl0FnEOZitXZSZaUdc9Bsxk4Qp5FDn/piBXqnnxa4TqZ0VUdnHqQ8Yusts8hOhEo+n WrgtxfTenZhPfOHhYU9YOvgo/ZfLIfpuU07R+2KBF07P4H/pIKvQOffMv0NQ47DwBSrv nw1VNR14AQ9uE2Qr9z0raYhf+RqhxCUQRbhyiMhaH2IlqFZY717Zre1ZAwgYFBkkBtVV HWqtvGWfBa6lpWTbsk4AFnhfNh3xYjbUep0FkypiSTx52i5BRG8OZECh1Qnqc9WdrD5C gecQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789369911; x=1789974711; h=content-transfer-encoding:content-type: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:content-type; bh=y/Cs8HpoX9Yo1ntlNmfm9TtzMXK7PRApDowzUjGq8FA=; b=JUC62pWi1O1S5n35/0IcbQSlVcGjBUlLHWd4JUGiZqUnC4ck6za2thAB4s6jCRGUZE k8D3uMhTsS+1s4cx90HdXL9KeasFD+0xTiUXPXM6/j0v/g5YyLAAEznIymjrpapiI2he +PIPA6cYpHbzeXb4qtvRjsJ1vAd5YdmHieMglm8PlSRzVtkQbB7MtJ7rXL8UY2IxYe+y nTVV5H1Qj2iURy30D72EcvH/ZAR0mBNb5GUEGcJBT3Kn15Q/Wu4QqigUmMKSosid7l1j SqBiUV5ZEF+uIDNNHTfbu9MvlNF5MIQ5jrBEzYvu/EXlItgFIuHkIINCrT+EkEybE30K a6yQ== X-Forwarded-Encrypted: i=1; AKwUvBzU9T5JdKi5Ve6P3yjYiwZdVDzWyHwUXmMxbSxeKwYTgJHGXy6keKqLNSQvYY7Vmyvx5iTnpCyUSrU=@lists.xenproject.org X-Gm-Message-State: AFuF++mpC9LK3IwsTuN4Mmxo+0SXH4d46ar0cXMIm3YtD2Fjr68VOf38 kvmpWNRsqG3AVr/a/jHqN0ioKYQOKh/JamagUWu7nBOLYfnZGdkpgM4JhiyRFCFB6Q== X-Gm-Gg: AYBFou1pFspIq+apwA9vSqpxWnopEINZrQl8UDqIfo5cpgHdniwPGIijsbBbTm0W+wp jIPXRuGoWsq6mtlTrMNtmxxf9Z9MGYcXnQYBka3nB22gUsrvjn2dEpclge2niWF6BgEWiAqOwKy l6ylk70zNdlyDFAREx0xoJESgyeDWZPqefwqyWqNN+4YvT7mLUaT9i6cJAHgQtqq+mlg/CxFHxW A2b82xmThUTtWN49+/3ovuXpZWVKxCGQa5APIKIlghGD6GEiVtijHIdY9RzCEgdqzHr5MYtFOoi yHnng1Lwans5uBWxO3UlK+R6LugY90NNDT27bdzXmAwJz2PIcnSF4M7iNKs9TdIbcq2Z67mvpSp 5SdT53r7Q9c8cduW9YYcfgy0CO6pcHR/ukUwjiTs9wKVT8eUgT7DIktMh/eBFXsNNDhMpOhGSvv Vyg6TdyOb/PYNQr44mfTF7gZb1BycX7xhzj0uzRU40KbgW+2AAC5jo39VFtroa4y8eLlazwKfuh a1K+8GAvmeZBfHsDa4D+k584N80c6jokormEAzgpKoptbjSuBw91dIhxOcryl1wdfzsE0EdIl1y gyWkjYIPe4StlyUtuqc8dZjLiRbLbmc= X-Received: by 2002:a05:6000:26c7:b0:485:8c16:a35f with SMTP id ffacd0b85a97d-48702b3ae68mr1157486f8f.55.1789369910674; Mon, 14 Sep 2026 00:11:50 -0700 (PDT) Message-ID: <02d7010e-9864-40f5-ab3a-f0c161433d90@suse.com> Date: Mon, 14 Sep 2026 09:11:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/12] x86: add noreturn in a few more places To: Nicola Vetrini , Andrew Cooper Cc: Stefano Stabellini , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <90d0e3d6-2e12-43f1-815d-7936ca4c5fc6@suse.com> <66fc1415-df9e-41c2-b3ae-78305814cbfc@citrix.com> <320b920b3e673671eddceccb4b86f211@bugseng.com> <26a57fab-955a-4de6-b17b-eb57aa1f014b@suse.com> <98af89029999f2d0535d603ebf64d9b4@bugseng.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: <98af89029999f2d0535d603ebf64d9b4@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1789369911-6E2D04E9-E0B46DE5/0/0 X-purgate-type: clean X-purgate-size: 5067 On 11.09.2026 22:48, Nicola Vetrini wrote: > On 2026-09-10 08:43, Jan Beulich wrote: >> On 09.09.2026 21:07, Nicola Vetrini wrote: >>> On 2026-09-01 08:26, Jan Beulich wrote: >>>> On 31.08.2026 21:13, Andrew Cooper wrote: >>>>> On 28/08/2026 8:01 am, Jan Beulich wrote: >>>>>> --- a/xen/arch/x86/traps.c >>>>>> +++ b/xen/arch/x86/traps.c >>>>>> @@ -2304,7 +2304,7 @@ void asmlinkage entry_from_pv(struct cpu >>>>>>      case X86_ET_HW_EXC: >>>>>>          switch ( vec ) >>>>>>          { >>>>>> -        case X86_EXC_DF: return do_double_fault(regs); >>>>>> +        case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>>>>>          case X86_EXC_MC: return do_machine_check(regs); >>>>>>          } >>>>>>          break; >>>>>> @@ -2615,7 +2615,7 @@ void asmlinkage entry_from_xen(struct cp >>>>>>      case X86_ET_HW_EXC: >>>>>>          switch ( regs->fred_ss.vector ) >>>>>>          { >>>>>> -        case X86_EXC_DF: return do_double_fault(regs); >>>>>> +        case X86_EXC_DF: do_double_fault(regs); /* noreturn */ >>>>>>          case X86_EXC_MC: return do_machine_check(regs); >>>>>>          } >>>>>>          break; >>>>>> >>>>> >>>>> For starters you're missing a break, and the only reason this isn't a >>>>> compile error is the trailing comment. >>>> >>>> "break" there would again be unreachable, though. >>>> >>>>>   Second, it's a tailcall anyway.  >>>>> There really is nothing unreachable anywhere in this construct. >>>> >>>> Just that the concept of "tailcall" is an optimization, not something >>>> inherent to the language. >>>> >>>>> But by far the most important, it the singular noreturn attribute on >>>>> do_double_fault() (elsewhere, and not visible when reading these two >>>>> functions) which is preventing #DF falling into #MC.   This introduces >>>>> fragility which did not exist previously. >>>> >>>> I realized that when making the patch, yet what do you do when the rule >>>> is as it is? Hence why I added the comment, really. >>>> >>>>> do_double_fault() would conditionally return if we ever got around to >>>>> fixing espfix64. >>>> >>>> And hence would have to lose its "noreturn". At which point call sites >>>> would need inspecting. (As said - yes, I do realize the fragility.) >>>> >>>>> So no - I'm going to insist that Eclair is taught to accept "return >>>>> some_noreturn_fn();" as intentional.  It is objectively less fragile >>>>> than the MISRA-preferred option. >>>> >>>> Nicola, thoughts? >>> >>> If you find a suitable argument from the toolchain that the generated >>> code is correct even though you return from a function where you >>> promised not to return in its declaration, I suppose that's fine, but >>> that MISRA Rule I mentioned ("A function declared with a _Noreturn >>> function specifier shall not return to its caller"), which is not (yet) >>> applied to Xen exists to defend from stumbling on UB 71 of C11: A >>> function declared with a _Noreturn function specifier shall not return >>> to its caller. >>> >>> So in general ECLAIR should not accept this by default. What you can do >>> is deviate these (hopefully few) cases if you have backing evidence of >>> the correct behavior. >> >> The disagreement between you suggesting a deviation and Andrew demanding >> "that Eclair is taught to accept ..." will need resolving. The argument >> towards the code being overall less fragile in its original shape cannot >> easily be put away. And Misra demanding code to be made more fragile >> than it needs to be cannot really be the goal either. >> > > Well, I feel like I have explained my reasoning, but let me step back a bit and lay out the possible safe alternatives I see for this construct. By the way, perhaps it's a better idea to split off this change from the other additions of noreturn, which can probably go in as is. > > Adding noreturn to do_double_fault() while keeping "return do_double_fault()" in the #DF path is likely subtly broken (i.e. the compiler can rightfully optimize assuming the function does not return) so that's not a feasible solution. Hmm, why would this be subtly broken? do_double_fault() doesn't (and won't ever) return. So the compiler optimizing based on that is quite okay. > If noreturn is added to do_double_fault(), removing the return in entry_from_pv(), shouldn't that be guarded against falling trough via BUG() or equivalent constructs that do not vanish in release builds? My understanding, that may be incorrect, is that returning from do_double_fault() is currently not expected to happen (hence the panic() in it). This would feel odd to me - do_double_fault() is really already BUG()-like, so following a call to it by such a construct would end up questionable. All of the above (and maybe more) is what I understand makes Andrew say "Eclair needs to be taught ...". Andrew, maybe you could expand a bit? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:10:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:10:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420568.1646824 (Exim 4.92) (envelope-from ) id 1x62hl-0000zG-L1; Mon, 14 Sep 2026 09:10:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420568.1646824; Mon, 14 Sep 2026 09:10:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62hl-0000z7-GG; Mon, 14 Sep 2026 09:10:25 +0000 Received: by outflank-mailman (input) for mailman id 1420568; Mon, 14 Sep 2026 09:10:24 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62hk-0000z1-N8 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:10:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x62hj-00F8Kz-FU for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:10:23 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7b9f0-e002-0a2a0a5209dd-0a2a4503a522-34 for ; Mon, 14 Sep 2026 11:10:23 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7b9fe-fae8-0a2a45030019-c387df82ea40-3 for ; Mon, 14 Sep 2026 11:10:23 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 607CB21C09; Mon, 14 Sep 2026 09:10:14 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 412B613693; Mon, 14 Sep 2026 09:10:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 85wNDPW5p2qtQwAAD6G6ig (envelope-from ); Mon, 14 Sep 2026 09:10:13 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789377018; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=L0yEqga84Lai4g4C2HoxLMw5vN/Q+3iQH0yaLMApfE4=; b=ewc5NhYlzzaMVIWgBxvYdaD0Mopf/AKfIHgqX3ftbxgVLbNcDdmZdkAOjFweiVVKC9r3gU TsB1HgLxybVY/GsdbvkgdRn4W7SjPEGbQ5rdUEduAHGx/qcRB7oX+1NrVpwbqXvvuCG6rd iw//n5MTl/c66sARePLjuYzqK0TS/Jg= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=VdSnNMfT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789377014; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=L0yEqga84Lai4g4C2HoxLMw5vN/Q+3iQH0yaLMApfE4=; b=VdSnNMfTfuu2ZpVn7LRDCR/QrNntCCfLuLQMQqULcSbHeUo8EllgcUZ8CFuKEbb1Jn+LDS LA28ZPuX18IzvBNcq95lzumjuklaZ55cmWbgZpSIFsZEimkxLoT3QthCZ6tqVnA+4AWyUQ LO8JQuVsf6J5hCktyOAJ8vx/pttmpYc= Message-ID: <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> Date: Mon, 14 Sep 2026 11:10:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260826045720.5779-2-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------M2rsuI2wpe2aMY4A8miBY270" X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 607CB21C09 X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_BASE64_TEXT(0.10)[]; MX_GOOD(-0.01)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org]; RCPT_COUNT_TWELVE(0.00)[12]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Spam-Flag: NO X-Spam-Score: -5.41 X-purgate-ID: tlsNG-33051d/1789377023-6F2C84E9-473351AA/0/0 X-purgate-type: clean X-purgate-size: 18391 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------M2rsuI2wpe2aMY4A8miBY270 Content-Type: multipart/mixed; boundary="------------cHfNdzUgGgBZjB2FIuOf4NM3"; protected-headers="v1" From: Juergen Gross To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com Message-ID: <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> In-Reply-To: <20260826045720.5779-2-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------cHfNdzUgGgBZjB2FIuOf4NM3 Content-Type: multipart/mixed; boundary="------------nPKCoo5UwUVjt6X2yrEIazsv" --------------nPKCoo5UwUVjt6X2yrEIazsv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMDguMjYgMDY6NTcsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gUlREUyBoYXMg bm8gYWRtaXNzaW9uIGNvbnRyb2w6IG5vdGhpbmcgc3RvcHMgdGhlIHN1bSBvZiBhbGwgYWRt aXR0ZWQNCj4gdW5pdHMnIChidWRnZXQvcGVyaW9kKSByZXNlcnZhdGlvbnMgaW4gYSBjcHVw b29sIGZyb20gZXhjZWVkaW5nDQo+IHdoYXQgaXRzIHBDUFVzIGNhbiBhY3R1YWxseSBwcm92 aWRlLiBPbmNlIHRoYXQgaGFwcGVucywgbm9uZSBvZiB0aGUNCj4gRURGIGRlYWRsaW5lIGd1 YXJhbnRlZXMgdGhpcyBzY2hlZHVsZXIgaXMgYnVpbHQgYXJvdW5kIHN0aWxsIGhvbGQNCj4g Zm9yIHRoZSB1bml0cyBzaGFyaW5nIHRoYXQgcG9vbC4NCj4gDQo+IEludHJvZHVjZSBhZG1p c3Npb24gY29udHJvbCB0byBwcmV2ZW50IHRoaXM6IHJlamVjdCBhIHJlc2VydmF0aW9uDQo+ IHdoZW5ldmVyIGFkbWl0dGluZyBpdCB3b3VsZCBwdXNoIGEgY3B1cG9vbCdzIHVuaXRzIG92 ZXIgaXRzIGNhcGFjaXR5Lg0KPiBUcmFjayBhIHJ1bm5pbmcgdXRpbGl6YXRpb24gdG90YWwg cGVyIGNwdXBvb2wsIGFuZCBlbmZvcmNlIGl0IGluDQo+IHJ0X2FsbG9jX3VkYXRhKCkvcnRf ZnJlZV91ZGF0YSgpLCB0aGUgcGFpcmVkIGxpZmVjeWNsZSBob29rcyBmb3IgYQ0KPiB1bml0 J3MgY3JlYXRpb24gYW5kIGRlc3RydWN0aW9uLiBUaGlzIGNhdGNoZXMgdGhlIGRlZmF1bHQN Cj4gcGVyaW9kL2J1ZGdldCBldmVyeSBuZXcgdW5pdCBnZXRzLg0KPiANCj4gVXRpbGl6YXRp b24gaXMgcmVwcmVzZW50ZWQgYXMgYSBmaXhlZC1wb2ludCB2YWx1ZTogYnVkZ2V0IGlzDQo+ IGxlZnQgc2hpZnRlZCBieSBSVERTX1VUSUxfU0hJRlQgKDIwIGJpdHMpIGFuZCBkaXZpZGVk IGJ5IHBlcmlvZC4NCj4gQSBwbGFpbiAiKGJ1ZGdldCA8PCBSVERTX1VUSUxfU0hJRlQpIC8g cGVyaW9kIiByaXNrcyBvdmVyZmxvd2luZw0KPiB0aGUgbXVsdGlwbHkgZm9yIGxhcmdlIGVu b3VnaCBidWRnZXRzLiBSYXRoZXIgdGhhbiB3aWRlbiB0aGUNCj4gYXJpdGhtZXRpYyB0byB0 b2xlcmF0ZSBhbnkgaW5wdXQsIHRoZSBpbnB1dCBpdHNlbGYgaXMgYm91bmRlZDoNCj4gcnRf dmFsaWRhdGVfcGFyYW1zKCkgcmVqZWN0cyBhbnkgYnVkZ2V0IGFib3ZlIFJURFNfTUFYX0JV REdFVCwNCj4gY2hvc2VuIGFzIHRoZSBsYXJnZXN0IHZhbHVlIHRoYXQgY2FuIGJlIGxlZnQt c2hpZnRlZCBieQ0KPiBSVERTX1VUSUxfU0hJRlQgd2l0aG91dCBvdmVyZmxvd2luZyA2NCBi aXRzLCBzbyB0aGUgc2hpZnQgaW4NCj4gcnRfdW5pdF91dGlsaXphdGlvbigpIGNhbiBuZXZl ciBvdmVyZmxvdy4NCj4gDQo+IEEgY3B1cG9vbCdzIGNhcGFjaXR5IHJ0X3V0aWxpemF0aW9u X2NhcCgpIHNjYWxlcyB3aXRoIHRoZSBudW1iZXIgb2YNCj4gc2NoZWR1bGluZyByZXNvdXJj ZXMgaW4gaXQuIEl0IGlzIGNhbGN1bGF0ZWQgYXM6DQo+IChudW1iZXIgb2Ygc2NoZWRfcmVz b3VyY2VzICogUlREU19VVElMX1NDQUxFICogUlREU19VVElMX0NBUF9QQ1QgLyAxMDApLA0K PiB3aGVyZSBSVERTX1VUSUxfQ0FQX1BDVCBjb250cm9scyBob3cgbXVjaCBvZiB0aGF0IGNh cGFjaXR5IGNhbg0KPiBhY3R1YWxseSBiZSByZXNlcnZlZDsgYXQgMTAwJSAoaXRzIGN1cnJl bnQgdmFsdWUpLCBhbGwgb2YgaXQgY2FuIGJlLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogRnVy a2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29tPg0KPiAtLS0NCj4gICB4ZW4v Y29tbW9uL3NjaGVkL3J0LmMgfCAxMDUgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKystDQo+ICAgMSBmaWxlIGNoYW5nZWQsIDEwNCBpbnNlcnRpb25zKCspLCAx IGRlbGV0aW9uKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9zY2hlZC9ydC5j IGIveGVuL2NvbW1vbi9zY2hlZC9ydC5jDQo+IGluZGV4IDBlOWYwNGVhNzIuLjkxMjYzMjA4 MDEgMTAwNjQ0DQo+IC0tLSBhL3hlbi9jb21tb24vc2NoZWQvcnQuYw0KPiArKysgYi94ZW4v Y29tbW9uL3NjaGVkL3J0LmMNCj4gQEAgLTExNCw2ICsxMTQsMjQgQEANCj4gICAgKi8NCj4g ICAjZGVmaW5lIFJURFNfTUFYX1BSSU9SSVRZX0xFVkVMICh+MFUpDQo+ICAgDQo+ICsvKg0K PiArICogRml4ZWQtcG9pbnQgc2NhbGUgZm9yIHV0aWxpemF0aW9uIChidWRnZXQvcGVyaW9k KQ0KPiArICovDQo+ICsjZGVmaW5lIFJURFNfVVRJTF9TSElGVCAgICAgMjANCj4gKyNkZWZp bmUgUlREU19VVElMX1NDQUxFICAgICAoMVVMTCA8PCBSVERTX1VUSUxfU0hJRlQpDQo+ICsN Cj4gKy8qDQo+ICsgKiBMYXJnZXN0IGJ1ZGdldCBzYWZlIHRvIGxlZnQtc2hpZnQgYnkgUlRE U19VVElMX1NISUZUIHdpdGhvdXQNCj4gKyAqIG92ZXJmbG93aW5nIDY0IGJpdHMuIEVuZm9y Y2VkIGluIHJ0X3ZhbGlkYXRlX3BhcmFtcygpLg0KPiArICovDQo+ICsjZGVmaW5lIFJURFNf TUFYX0JVREdFVF9CSVRTICAoNjQgLSBSVERTX1VUSUxfU0hJRlQpDQo+ICsjZGVmaW5lIFJU RFNfTUFYX0JVREdFVCAgICAgICAoKDFVTEwgPDwgUlREU19NQVhfQlVER0VUX0JJVFMpIC0g MSkNCj4gKw0KPiArLyoNCj4gKyAqICUgb2YgYSBjcHVwb29sJ3Mgc2NoZWRfcmVzb3VyY2Ug Y2FwYWNpdHkgYWRtaXR0ZWQgdW5pdHMgbWF5IHN1bSB1cCB0by4NCj4gKyAqLw0KPiArI2Rl ZmluZSBSVERTX1VUSUxfQ0FQX1BDVCAgIDEwMA0KPiArDQo+ICAgLyoNCj4gICAgKiBVUERB VEVfTElNSVRfU0hJRlQ6IGEgY29uc3RhbnQgdXNlZCBpbiBydF91cGRhdGVfZGVhZGxpbmUo KS4gV2hlbiBmaW5kaW5nDQo+ICAgICogdGhlIG5leHQgZGVhZGxpbmUsIHBlcmZvcm1pbmcg YWRkaXRpb24gY291bGQgYmUgZmFzdGVyIGlmIHRoZSBkaWZmZXJlbmNlDQo+IEBAIC0xOTUs NiArMjEzLDkgQEAgc3RydWN0IHJ0X3ByaXZhdGUgew0KPiAgICAgICBzdHJ1Y3QgbGlzdF9o ZWFkIHJlcGxxOyAgICAgLyogb3JkZXJlZCBsaXN0IG9mIHVuaXRzIHRoYXQgbmVlZCByZXBs ZW5pc2htZW50ICovDQo+ICAgDQo+ICAgICAgIGNwdW1hc2tfdCB0aWNrbGVkOyAgICAgICAg ICAvKiBjcHVzIGJlZW4gdGlja2xlZCAqLw0KPiArDQo+ICsgICAgLyogU3VtIG9mIGFkbWl0 dGVkIHVuaXRzJyAoYnVkZ2V0L3BlcmlvZCksIHNjYWxlZCBieSBSVERTX1VUSUxfU0NBTEUg Ki8NCj4gKyAgICB1aW50NjRfdCB1dGlsaXphdGlvbjsNCj4gICB9Ow0KPiAgIA0KPiAgIC8q DQo+IEBAIC02MzUsNiArNjU2LDU0IEBAIHJlcGxxX3JlaW5zZXJ0KGNvbnN0IHN0cnVjdCBz Y2hlZHVsZXIgKm9wcywgc3RydWN0IHJ0X3VuaXQgKnN2YykNCj4gICAgICAgICAgIHNldF90 aW1lcigmcnRfcHJpdihvcHMpLT5yZXBsX3RpbWVyLCByZWFybV9zdmMtPmN1cl9kZWFkbGlu ZSk7DQo+ICAgfQ0KPiAgIA0KPiArLyoNCj4gKyAqIGJ1ZGdldCA8PCBSVERTX1VUSUxfU0hJ RlQgY2FuJ3Qgb3ZlcmZsb3c6IHJ0X3ZhbGlkYXRlX3BhcmFtcygpDQo+ICsgKiBjYXBzIGJ1 ZGdldCBhdCBSVERTX01BWF9CVURHRVQuIHBlcmlvZCA9PSAwIG1lYW5zICJubw0KPiArICog cmVzZXJ2YXRpb24iIChhIHVuaXQgYmVpbmcgcmVtb3ZlZCksIG5vdCBhbiBlcnJvci4NCj4g KyAqLw0KPiArc3RhdGljIHVpbnQ2NF90DQo+ICtydF91bml0X3V0aWxpemF0aW9uKHNfdGlt ZV90IHBlcmlvZCwgc190aW1lX3QgYnVkZ2V0KQ0KPiArew0KPiArICAgIGlmICggcGVyaW9k IDw9IDAgKQ0KPiArICAgICAgICByZXR1cm4gMDsNCj4gKw0KPiArICAgIHJldHVybiAoKHVp bnQ2NF90KWJ1ZGdldCA8PCBSVERTX1VUSUxfU0hJRlQpIC8gKHVpbnQ2NF90KXBlcmlvZDsN Cj4gK30NCj4gKw0KPiArLyoNCj4gKyAqIFV0aWxpemF0aW9uIGNhcGFjaXR5IG9mIHRoZSBj cHVwb29sIGRvbWFpbiBkIHJlc2lkZXMgaW4uDQo+ICsgKi8NCj4gK3N0YXRpYyB1aW50NjRf dA0KPiArcnRfdXRpbGl6YXRpb25fY2FwKGNvbnN0IHN0cnVjdCBkb21haW4gKmQpDQo+ICt7 DQo+ICsgICAgdW5zaWduZWQgaW50IGNwdXMgPSBjcHVtYXNrX3dlaWdodChjcHVwb29sX2Rv bWFpbl9tYXN0ZXJfY3B1bWFzayhkKSk7DQo+ICsNCj4gKyAgICByZXR1cm4gKHVpbnQ2NF90 KWNwdXMgKiBSVERTX1VUSUxfU0NBTEUgKiBSVERTX1VUSUxfQ0FQX1BDVCAvIDEwMDsNCj4g K30NCj4gKw0KPiArLyoNCj4gKyAqIFJlcGxhY2VzIGEgdW5pdCdzIHJlc2VydmF0aW9uIGFu ZCB1cGRhdGVzIHBydi0+dXRpbGl6YXRpb24NCj4gKyAqIHRvIG1hdGNoLiBHcm93dGggdGhh dCB3b3VsZCBwdXNoIHV0aWxpemF0aW9uIG92ZXIgdGhlDQo+ICsgKiBjcHVwb29sJ3MgY2Fw IGlzIHJlZnVzZWQuIFJlbW92aW5nIGEgdW5pdCBvciBzaHJpbmtpbmcNCj4gKyAqIGEgdW5p dCdzIHJlc2VydmF0aW9uIGFsd2F5cyBzdWNjZWVkLg0KPiArICovDQo+ICtzdGF0aWMgaW50 DQo+ICtydF9hZG1pc3Npb25fdGVzdChzdHJ1Y3QgcnRfcHJpdmF0ZSAqcHJ2LCBjb25zdCBz dHJ1Y3QgZG9tYWluICpkLA0KPiArCQkgICBzX3RpbWVfdCBvbGRfcGVyaW9kLCBzX3RpbWVf dCBvbGRfYnVkZ2V0LA0KPiArCQkgICBzX3RpbWVfdCBuZXdfcGVyaW9kLCBzX3RpbWVfdCBu ZXdfYnVkZ2V0KQ0KDQpJIHRoaW5rIHRoZSBmdW5jdGlvbiBuYW1lIGlzbid0IGFwcHJvcHJp YXRlLiBUaGUgZnVuY3Rpb24gZG9lc24ndCB0ZXN0IG9ubHksIGl0DQppcyBzZXR0aW5nIHRo ZSB1dGlsaXphdGlvbiwgdG9vLg0KDQpXaGF0IGFib3V0IHJ0X3RyeV9zZXRfdXRpbGl6YXRp b24oKSBpbnN0ZWFkPyBBbmQgbWFrZSB0aGUgcmV0dXJuIHR5cGUgYm9vbA0KKHRydWUgb24g c3VjY2VzcykuDQoNCj4gK3sNCj4gKyAgICB1aW50NjRfdCBvbGRfdXRpbCA9IHJ0X3VuaXRf dXRpbGl6YXRpb24ob2xkX3BlcmlvZCwgb2xkX2J1ZGdldCk7DQo+ICsgICAgdWludDY0X3Qg bmV3X3V0aWwgPSBydF91bml0X3V0aWxpemF0aW9uKG5ld19wZXJpb2QsIG5ld19idWRnZXQp Ow0KPiArICAgIHVpbnQ2NF90IHRvdGFsICAgID0gcHJ2LT51dGlsaXphdGlvbiAtIG9sZF91 dGlsICsgbmV3X3V0aWw7DQo+ICsNCj4gKyAgICBpZiAoIG5ld191dGlsID4gb2xkX3V0aWwg JiYgdG90YWwgPiBydF91dGlsaXphdGlvbl9jYXAoZCkgKQ0KPiArICAgICAgICByZXR1cm4g LUVJTlZBTDsNCj4gKw0KPiArICAgIHBydi0+dXRpbGl6YXRpb24gPSB0b3RhbDsNCj4gKw0K PiArICAgIHJldHVybiAwOw0KPiArfQ0KPiArDQo+ICAgLyoNCj4gICAgKiBQaWNrIGEgdmFs aWQgcmVzb3VyY2UgZm9yIHRoZSB1bml0IHZjDQo+ICAgICogVmFsaWQgcmVzb3VyY2Ugb2Yg YW4gdW5pdCBpcyBpbnRlc2VjdGlvbiBvZiB1bml0J3MgYWZmaW5pdHkNCj4gQEAgLTg2NCw2 ICs5MzMsNyBAQCBydF9mcmVlX2RvbWRhdGEoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3Bz LCB2b2lkICpkYXRhKQ0KPiAgIHN0YXRpYyB2b2lkICogY2ZfY2hlY2sNCj4gICBydF9hbGxv Y191ZGF0YShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCBzY2hlZF91bml0 ICp1bml0LCB2b2lkICpkZCkNCj4gICB7DQo+ICsgICAgc3RydWN0IHJ0X3ByaXZhdGUgKnBy diA9IHJ0X3ByaXYob3BzKTsNCj4gICAgICAgc3RydWN0IHJ0X3VuaXQgKnN2YzsNCj4gICAN Cj4gICAgICAgLyogQWxsb2NhdGUgcGVyLVVOSVQgaW5mbyAqLw0KPiBAQCAtODgxLDkgKzk1 MSwzMCBAQCBydF9hbGxvY191ZGF0YShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0 cnVjdCBzY2hlZF91bml0ICp1bml0LCB2b2lkICpkZCkNCj4gICAgICAgX19zZXRfYml0KF9f UlREU19leHRyYXRpbWUsICZzdmMtPmZsYWdzKTsNCj4gICAgICAgc3ZjLT5wcmlvcml0eV9s ZXZlbCA9IDA7DQo+ICAgICAgIHN2Yy0+cGVyaW9kID0gUlREU19ERUZBVUxUX1BFUklPRDsN Cj4gKw0KPiAgICAgICBpZiAoICFpc19pZGxlX3VuaXQodW5pdCkgKQ0KPiArICAgIHsNCj4g KyAgICAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsNCj4gKyAgICAgICAgaW50IHJjOw0KPiAr DQo+ICAgICAgICAgICBzdmMtPmJ1ZGdldCA9IFJURFNfREVGQVVMVF9CVURHRVQ7DQo+ICAg DQo+ICsgICAgICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCj4g KyAgICAgICAgcmMgPSBydF9hZG1pc3Npb25fdGVzdChwcnYsIHVuaXQtPmRvbWFpbiwgMCwg MCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3ZjLT5wZXJpb2QsIHN2 Yy0+YnVkZ2V0KTsNCj4gKyAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5s b2NrLCBmbGFncyk7DQo+ICsNCj4gKyAgICAgICAgaWYgKCByYyApDQo+ICsgICAgICAgIHsN Cj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORw0KPiArICAgICAgICAgICAg ICAgICAgICJSVERTOiBBRE1JU1NJT04gQ09OVFJPTDogcmVmdXNpbmcgdW5pdCAldSBvZiBk JWQsIg0KPiArICAgICAgICAgICAgICAgICAgICIgd291bGQgZXhjZWVkIHV0aWxpemF0aW9u IGNhcGFjaXR5IG9mIHRoZSBjcHVwb29sXG4iLA0KPiArICAgICAgICAgICAgICAgICAgIHVu aXQtPnVuaXRfaWQsIHVuaXQtPmRvbWFpbi0+ZG9tYWluX2lkKTsNCj4gKyAgICAgICAgICAg IHhmcmVlKHN2Yyk7DQo+ICsgICAgICAgICAgICByZXR1cm4gTlVMTDsNCj4gKyAgICAgICAg fQ0KPiArICAgIH0NCj4gKw0KPiAgICAgICBTQ0hFRF9TVEFUX0NSQU5LKHVuaXRfYWxsb2Mp Ow0KPiAgIA0KPiAgICAgICByZXR1cm4gc3ZjOw0KPiBAQCAtODkyLDggKzk4MywxOSBAQCBy dF9hbGxvY191ZGF0YShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCBzY2hl ZF91bml0ICp1bml0LCB2b2lkICpkZCkNCj4gICBzdGF0aWMgdm9pZCBjZl9jaGVjaw0KPiAg IHJ0X2ZyZWVfdWRhdGEoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCB2b2lkICpwcml2 KQ0KPiAgIHsNCj4gKyAgICBzdHJ1Y3QgcnRfcHJpdmF0ZSAqcHJ2ID0gcnRfcHJpdihvcHMp Ow0KPiAgICAgICBzdHJ1Y3QgcnRfdW5pdCAqc3ZjID0gcHJpdjsNCj4gICANCj4gKyAgICBp ZiAoIHN2YyAmJiAhaXNfaWRsZV91bml0KHN2Yy0+dW5pdCkgKQ0KPiArICAgIHsNCj4gKyAg ICAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsNCj4gKw0KPiArICAgICAgICBzcGluX2xvY2tf aXJxc2F2ZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQo+ICsgICAgICAgIHJ0X2FkbWlzc2lvbl90 ZXN0KHBydiwgc3ZjLT51bml0LT5kb21haW4sDQo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdmMtPnBlcmlvZCwgc3ZjLT5idWRnZXQsIDAsIDApOw0KDQpUaGlzIHVzZSBjYXNl IGNsZWFybHkgc2hvd3MgeW91IGFyZSBub3Qgb25seSB0ZXN0aW5nLiA6LSkNCg0KPiArICAg ICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCj4gKyAg ICB9DQo+ICsNCj4gICAgICAgeGZyZWUoc3ZjKTsNCj4gICB9DQo+ICAgDQo+IEBAIC0xMzg5 LDcgKzE0OTEsOCBAQCBydF92YWxpZGF0ZV9wYXJhbXMoY29uc3Qgc3RydWN0IHhlbl9kb21j dGxfc2NoZWRfcnRkcyAqcnRkcywNCj4gICAgICAgc190aW1lX3QgYiA9IE1JQ1JPU0VDUyhy dGRzLT5idWRnZXQpOw0KPiAgIA0KPiAgICAgICBpZiAoIHAgPCBSVERTX01JTl9QRVJJT0Qg fHwgcCA+IFJURFNfTUFYX1BFUklPRCB8fA0KPiAtICAgICAgICAgYiA8IFJURFNfTUlOX0JV REdFVCB8fCBiID4gcCApDQo+ICsgICAgICAgICBiIDwgUlREU19NSU5fQlVER0VUIHx8IGIg PiBwIHx8DQo+ICsgICAgICAgICBiID4gKHNfdGltZV90KVJURFNfTUFYX0JVREdFVCApDQo+ ICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4gICANCj4gICAgICAgKnBlcmlvZCA9IHA7 DQoNCg0KSnVlcmdlbg0KDQo= --------------nPKCoo5UwUVjt6X2yrEIazsv Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------nPKCoo5UwUVjt6X2yrEIazsv-- --------------cHfNdzUgGgBZjB2FIuOf4NM3-- --------------M2rsuI2wpe2aMY4A8miBY270 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqnue8FAwAAAAAACgkQsN6d1ii/Ey/9 Rgf+IltOEULM/jC/NtcAXjvtGoGKdkfNP/gYx9yL2YUwtp0O8Awf4hlqp+BWY2uGIqBF/zA/fJuq xTSMcaI+Xp4paYg9DrlG/wP385zo+BuUtScvtvoUpCkww8RAPdCzyaqm7qdsxAQYqvVOfFE4OkwJ YmC56jN0WG9ibpQKmeJ9sEEZoas5zc1co5r+mLJ9md6qrH3WQgrq+6N/aFM/fvrpK43PH970csB1 INXz0WQa4ajdCs899S92nsu3JGZzsI9hXxoqP8IT2T3E4ISQpfIQCCSIXou7VxlarlkG8Ad/5GDz AsLLnIaobmEB5GDv6E1nr8kCkOMRAZCRSVdkm/86oA== =s9TV -----END PGP SIGNATURE----- --------------M2rsuI2wpe2aMY4A8miBY270-- From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:14:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:14:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420577.1646832 (Exim 4.92) (envelope-from ) id 1x62lG-0001Xo-3y; Mon, 14 Sep 2026 09:14:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420577.1646832; Mon, 14 Sep 2026 09:14:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62lG-0001Xh-1J; Mon, 14 Sep 2026 09:14:02 +0000 Received: by outflank-mailman (input) for mailman id 1420577; Mon, 14 Sep 2026 09:14:00 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62lE-0001XZ-Li for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:14:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x62lD-009BaP-JK for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:13:59 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7bad2-e002-0a2a0a5209dd-0a2a4501d2ca-28 for ; Mon, 14 Sep 2026 11:13:59 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7bad7-5984-0a2a45010019-d155802be4b9-3 for ; Mon, 14 Sep 2026 11:13:59 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49e717c9841so9810825e9.0 for ; Mon, 14 Sep 2026 02:13:59 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e60ad0614sm324326405e9.10.2026.09.14.02.13.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 02:13:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789377239; x=1789982039; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4pX6ehIPkirYx2cXTlEJLZmpcOcMBvg1KKWQ3Tskgno=; b=BQcJSl35M47D7iZR4pVN4ImSV2Pt0JoMiFTgi9m2+7BWCvFy3Mt41uctrLV7PJ6uGQ 0zMT1bbUvlFZnkyYWoIdMOiYDDaVTL0lC1JxoFp+HfF6tjOEqir9BCWvqoxnEN8SN/EX rLo6hWa1CdiSdiyvAjkRN20Fc7kQg/wOArKOsqn8ydUKlpJz1pIWb9m2/KkmDViVMqKM CnCLo9ETYbZPMcEaFdMMP3m8Gw0JC/xFlR3jKmg3MxVss1g+7XbVa4n1HKNiHMtx8aAx 4voly+TvvdMm8MlEfWaQ6dpfMaho3RzuICX2QF+8QKPynhUScWRRFUtFSzUdczntwlxr I1uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789377239; x=1789982039; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=4pX6ehIPkirYx2cXTlEJLZmpcOcMBvg1KKWQ3Tskgno=; b=Wl01UIr4ed7lnixzaQsCeFUNmEYwoROvhOHLLUpB2RVDFzgpoBeRX+FY4pQFjuPXEi X1HUICgZTSq+k5aOio3kduCZ99ieLA6VMR2Mouuk3+5XXAQJNpCPcgth7IWDTtyZlZEr fA/8RxzgFRjY2NmfzJllpXXxlAT89reAABV31yiN9g1PdiZtz4rAX61DQRS/92gZ6mU7 +DQFvaGqXehUrjzML2dqs/Ra0UDXmgCxXYukt4nrrSLbJFX8JmuvxvmfSVPSdL48kBXg q8pvTfl9W8R1VPTHgZOwTxUKbhXmI0R3dmZhEaPCoACbtfSjrCsjkf5u+a+boJ5+LSy6 h03A== X-Forwarded-Encrypted: i=1; AKwUvBxFN2ckSm0sXVIxirU2eXjemPOhFhZ3sdF/YUk2Jbz5My1/LbeC1BkT1ijR+NZQ9eB7nbDKVvzOqz0=@lists.xenproject.org X-Gm-Message-State: AFuF++lFcgpRRKh9YEeki8cE4ibwnAEaLVLWDE/LDvwZHMS7CrQsbROl n6+DN4dUSGDYuwUYOCNCpgyFUlH3LkSzdjn8IJ1VjZkaqHU64Iffe+xL3LRNyULgOw== X-Gm-Gg: AYBFou2Ngls99foak8bSV0BkG/ToFlSqqU6NAzN4rVOEzN0j8Pa24H1qreFC0D+ZXx1 JMpbdqZDQ5CWnIk3huwgKxm3gQaUlU8/iy7j+rpHtVKlxSrOD5RGpDnr4OEj4bWs6ouWP1eDLNi DZa2DuLfnGw/98ZUxY/ZcOvIH5xUkxJAgTdg92T7gwucMx42TSK78K4YupIkAGbUrDhy1E1eXY+ EZNFuAaPool3psdGOrjgIUqiP7I2+H2Lkpb4okO8bjEfX+0EzZ8WMJg6A+BE5WrO7L3x10/wVqu Xp0GSQG4pLDO3vF1klM+Od38tA5MNH1+34sCsztnGtLR/Itt4z8KtAPi5ERJtDib0D9nCDelzGU Q/GvU8ltMGJctta8jz8AOfIkak1Fq/F97pN9DeStLJ4TFPA4AQiS9oazelmdRfA5du2Y6oRDJC4 Au3ou3uKocAqEGLxFAA4XGja8alMvF9jE4eJcXzILYPAWzQ1wCs4LZM0MaPHEU6KnPRYUSLoIZh GsgKLRBsOW0 X-Received: by 2002:a05:600c:190d:b0:49e:7a00:b9a5 with SMTP id 5b1f17b1804b1-49e7a63a894mr19963905e9.4.1789377238763; Mon, 14 Sep 2026 02:13:58 -0700 (PDT) Message-ID: <325f2b44-ea61-45e8-a681-c0bb08d5766a@suse.com> Date: Mon, 14 Sep 2026 11:13:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Juergen Gross , Furkan Caliskan Cc: andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com, xen-devel@lists.xenproject.org References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1789377239-C495A757-07026B2E/0/0 X-purgate-type: clean X-purgate-size: 2935 On 14.09.2026 11:10, Juergen Gross wrote: > On 26.08.26 06:57, Furkan Caliskan wrote: >> @@ -635,6 +656,54 @@ replq_reinsert(const struct scheduler *ops, struct rt_unit *svc) >> set_timer(&rt_priv(ops)->repl_timer, rearm_svc->cur_deadline); >> } >> >> +/* >> + * budget << RTDS_UTIL_SHIFT can't overflow: rt_validate_params() >> + * caps budget at RTDS_MAX_BUDGET. period == 0 means "no >> + * reservation" (a unit being removed), not an error. >> + */ >> +static uint64_t >> +rt_unit_utilization(s_time_t period, s_time_t budget) >> +{ >> + if ( period <= 0 ) >> + return 0; >> + >> + return ((uint64_t)budget << RTDS_UTIL_SHIFT) / (uint64_t)period; >> +} >> + >> +/* >> + * Utilization capacity of the cpupool domain d resides in. >> + */ >> +static uint64_t >> +rt_utilization_cap(const struct domain *d) >> +{ >> + unsigned int cpus = cpumask_weight(cpupool_domain_master_cpumask(d)); >> + >> + return (uint64_t)cpus * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100; >> +} >> + >> +/* >> + * Replaces a unit's reservation and updates prv->utilization >> + * to match. Growth that would push utilization over the >> + * cpupool's cap is refused. Removing a unit or shrinking >> + * a unit's reservation always succeed. >> + */ >> +static int >> +rt_admission_test(struct rt_private *prv, const struct domain *d, >> + s_time_t old_period, s_time_t old_budget, >> + s_time_t new_period, s_time_t new_budget) > > I think the function name isn't appropriate. The function doesn't test only, it > is setting the utilization, too. > > What about rt_try_set_utilization() instead? And make the return type bool > (true on success). > >> +{ >> + uint64_t old_util = rt_unit_utilization(old_period, old_budget); >> + uint64_t new_util = rt_unit_utilization(new_period, new_budget); >> + uint64_t total = prv->utilization - old_util + new_util; >> + >> + if ( new_util > old_util && total > rt_utilization_cap(d) ) >> + return -EINVAL; >> + >> + prv->utilization = total; >> + >> + return 0; >> +} >> + >> /* >> * Pick a valid resource for the unit vc >> * Valid resource of an unit is intesection of unit's affinity >> @@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >> static void cf_check >> rt_free_udata(const struct scheduler *ops, void *priv) >> { >> + struct rt_private *prv = rt_priv(ops); >> struct rt_unit *svc = priv; >> >> + if ( svc && !is_idle_unit(svc->unit) ) >> + { >> + unsigned long flags; >> + >> + spin_lock_irqsave(&prv->lock, flags); >> + rt_admission_test(prv, svc->unit->domain, >> + svc->period, svc->budget, 0, 0); > > This use case clearly shows you are not only testing. :-) Yet at the same time ignoring possible errors. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:21:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:21:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420588.1646842 (Exim 4.92) (envelope-from ) id 1x62sk-0003IM-Qw; Mon, 14 Sep 2026 09:21:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420588.1646842; Mon, 14 Sep 2026 09:21:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62sk-0003IF-O6; Mon, 14 Sep 2026 09:21:46 +0000 Received: by outflank-mailman (input) for mailman id 1420588; Mon, 14 Sep 2026 09:21:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62si-0003Ht-V9 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:21:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x62sh-0033K2-Uk for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:21:43 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7bca1-8faa-0a2a0a5109dd-0a2a450ad80e-20 for ; Mon, 14 Sep 2026 11:21:43 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7bca7-f2d2-0a2a450a0019-d155802fe8de-3 for ; Mon, 14 Sep 2026 11:21:43 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49d05d51553so25470155e9.2 for ; Mon, 14 Sep 2026 02:21:43 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e60ac411asm289006315e9.8.2026.09.14.02.21.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 02:21:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789377703; x=1789982503; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zdN9NrxN8B2lkyt5tUSGZLrhPJA9n6yB+2SAPCu++cA=; b=Efmh6lsNL7m/bUclu0WRYgryPOYLENfQ4jV6BqkGzzVuxyITvuqxOEVlzgL75si+np 7HeSd6+U/XZgSXRIKhTu/gDH9WO1QNhcmLw93XeJS/ymrqJE5wrPhCTbJbMAZKrWZumQ NXvUROLOvDJHBVT1SvGEOF8re6HoykdZE5rCLL23fVkxrRDPWQstdjoVzhDMd9vfZkGu UMkaWgKqr1rTs2WMpcgthOytcRQR+DRvXPJbAMAbyT45nclFyUOkyw4CLQnTxRuJeoTn Jf3GJTBvBGcVmCEh1xm1pLMgInKSzXg4/Kbx1oMMbSWRVRqy5l9xubI2AcFXGqgSJFtM 3unw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789377703; x=1789982503; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=zdN9NrxN8B2lkyt5tUSGZLrhPJA9n6yB+2SAPCu++cA=; b=GsY5fZGT9x4Lzya7BjKx/MWjwIRs5TpPwlWt/MyO9fHVsH+CmBs7xkUt9daUQQgr+g 4WIazJ+IGhZ7Uv+TTPxFHRDifU3AV/rnCHb9NRCV7A/iG+3zXvKzHsACeUb8zrb5XPVf evvS3xDngds0mxcgumI+LKfGkwQKsAtc7cK2HOFbGfaDERp3PdJJvD+ElSf0UAfQMoN8 aGgOqjWdIOBu5hm4jM5vWcYLEvYmhQF8OsoEo4+m2Heq4WQsfewi2Kp2guuQw5HOToRX 4pYNIkT0v5/NywGXlfXtZ2auLDJCmj+AGBz+EuXwWwdtA3ZNJu2XfY2rg+dSUabiF2lh Ty/Q== X-Forwarded-Encrypted: i=1; AKwUvBwtofChboxr/aakdN+6S87GEiKdQrb+ujVlM/1ztMx2c66/9zMDjq0fI1N9cK+pdH5nsULrubzYe1Q=@lists.xenproject.org X-Gm-Message-State: AFuF++mP6fkzLMWxyuimUmr1mUadgoaLAjKfaOifrlS5CivOEgZAa9/B C89U2PXBVi4TM6KxljDE5LfaHAUKXlFtonNITE+setpYU8ooQFEThTiRmZTxXjWYZg== X-Gm-Gg: AYBFou3uMFJgad7toUuSHlZGI6BjadJq0dsqj4DIm0wFTmXxkyY0ltkG3vOp7g8Kq1X 8Nc6TEvamtVubEtQ31Gm7C4IrjYu9GvWMlQ3+DTvn/tqE/RYtOa6sBRZk4xInKAWRcmfF3PFCq0 U3Q16CaY58pUSje6xShHTD/cf07Y377iFINKbKcm5uj0ggYBzYDG9ecP0YSQaEK284w2dkf9LHm Zym7edW18rG1+prqK8LbiTVQPNvL6OCDEQEvZudGQ4TR/p0HizEAYEv9Uyd5A/vTCh0I9TBvKUN rgkA9oyqJUugijGGpYxIO/mIO2fWJiYElG+HIPhhQcDs4ZldqiO+s7yQpaq4d6w3srHlxZx06rJ Mwt+2ElQRiAm16VOSNeQcXqb6wOtKXMrVLJ3btWtBWzAzpT1hx6+07+UKC4XFdtSqY/uQRgkxtZ R8cKGZkGGcQ0A7H30wjG+scdkIcd2DR0wyGWaqdG3A2YdnmZtiXjZZb3o5fi1a6oeGEidGapmEP TpATc8/qiaVYw== X-Received: by 2002:a05:600c:4746:b0:499:bf8c:cfd1 with SMTP id 5b1f17b1804b1-49e7a63a654mr18694485e9.2.1789377703290; Mon, 14 Sep 2026 02:21:43 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 11:21:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds To: Furkan Caliskan Cc: andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com, xen-devel@lists.xenproject.org, Juergen Gross References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-3-frn1furkan10@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789377703-5A9D9CFC-FD7579D1/0/0 X-purgate-type: clean X-purgate-size: 1806 On 14.09.2026 11:16, Juergen Gross wrote: > On 26.08.26 06:57, Furkan Caliskan wrote: >> --- a/xen/common/sched/rt.c >> +++ b/xen/common/sched/rt.c >> @@ -1527,11 +1527,43 @@ rt_dom_cntl( >> op->u.rtds.budget = RTDS_DEFAULT_BUDGET / MICROSECS(1); >> break; >> case XEN_DOMCTL_SCHEDOP_putinfo: >> + { >> + uint64_t dom_old_util = 0, new_util, new_total; >> + unsigned int nr_units = 0; >> + >> rc = rt_validate_params(&op->u.rtds, &period, &budget); >> if ( rc ) >> break; >> >> + new_util = rt_unit_utilization(period, budget); >> + >> spin_lock_irqsave(&prv->lock, flags); >> + >> + /* >> + * Same (period, budget) for every unit of d: test and commit >> + * the domain's whole utilization delta atomically, rather >> + * than unit-by-unit, which could spuriously reject an >> + * overall-acceptable change depending on iteration order. >> + */ >> + for_each_sched_unit ( d, unit ) >> + { >> + svc = rt_unit(unit); >> + dom_old_util += rt_unit_utilization(svc->period, svc->budget); >> + nr_units++; >> + } >> + >> + new_total = prv->utilization - dom_old_util + >> + (uint64_t)nr_units * new_util; >> + >> + if ( new_total > prv->utilization && new_total > rt_utilization_cap(d) ) >> + { >> + rc = -EINVAL; > > Is EINVAL a good choice here? I think a different error code might be wanted. > >> + spin_unlock_irqrestore(&prv->lock, flags); >> + break; >> + } Additionally please unlock first, then set rc. The compiler may do such a rearrangement, but it also may not. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:22:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:22:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420591.1646851 (Exim 4.92) (envelope-from ) id 1x62t7-0003ew-1f; Mon, 14 Sep 2026 09:22:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420591.1646851; Mon, 14 Sep 2026 09:22:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62t6-0003ep-Uz; Mon, 14 Sep 2026 09:22:08 +0000 Received: by outflank-mailman (input) for mailman id 1420591; Mon, 14 Sep 2026 09:22:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62t5-0003b4-92 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:22:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x62t4-00Ch0A-LX for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:22:06 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7bcb1-8faa-0a2a0a5109dd-0a2a450ba4e2-42 for ; Mon, 14 Sep 2026 11:22:06 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7bb91-b7e8-0a2a450b0019-c387df839b2a-3 for ; Mon, 14 Sep 2026 11:17:05 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 381CA1F7C0; Mon, 14 Sep 2026 09:16:57 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C246C1368C; Mon, 14 Sep 2026 09:16:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 7er1CYa7p2pmSwAAD6G6ig (envelope-from ); Mon, 14 Sep 2026 09:16:54 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789377421; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=v1RrV7t0jDaBEHvthMlJoTa5jLAg1QwWf/8HMUAMS5M=; b=C2ngAX+kqzwjyWUcmDQ97lLsOvJK81one/91ISlnlCpwYLTucqodBmT16L3RkW06KP/F42 l5IiAoHS+Yt5Ub/leaIMfv3M5vWm8YWTkVTbDLL9tgmS9VReeK1nj3Pl9WXzdlcOReli8t M08mh9rh0s5L9f7+JYfk6kLJXAu5/BU= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=WXP1Ff81 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789377417; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=v1RrV7t0jDaBEHvthMlJoTa5jLAg1QwWf/8HMUAMS5M=; b=WXP1Ff81820aoQinhSwZSmdMSWwX3uEWa2DLt5n3JcCMf1tj66j0dmFtSZW1Gk0jP1oWJa BJkKyubZL16T3F21y/Vc3p7VOQTHInG6FgsRmMkSV9yiFjyE9JM8/BQOLqdpcGLmEMq2ZW JUvRm5CQ5oqIe8ruwgvRv5t3hMcOWLw= Message-ID: Date: Mon, 14 Sep 2026 11:16:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-3-frn1furkan10@gmail.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260826045720.5779-3-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------3KyECH0prxl7JcdHsdJELaLT" X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 381CA1F7C0 X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_BASE64_TEXT(0.10)[]; MX_GOOD(-0.01)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org]; RCPT_COUNT_TWELVE(0.00)[12]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:dkim,suse.com:mid] X-Spam-Flag: NO X-Spam-Score: -5.41 X-purgate-ID: tlsNG-42698a/1789377426-A9AC09EA-3DBA0283/0/0 X-purgate-type: clean X-purgate-size: 12601 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------3KyECH0prxl7JcdHsdJELaLT Content-Type: multipart/mixed; boundary="------------sOm8GJl0l7gE0HMoNg1Nh0eW"; protected-headers="v1" From: Juergen Gross To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com Message-ID: Subject: Re: [PATCH 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-3-frn1furkan10@gmail.com> In-Reply-To: <20260826045720.5779-3-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------sOm8GJl0l7gE0HMoNg1Nh0eW Content-Type: multipart/mixed; boundary="------------gjsrgHf5698EAt0Wf0HjYQnv" --------------gjsrgHf5698EAt0Wf0HjYQnv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMDguMjYgMDY6NTcsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gTm93IHRoYXQg d2UgaGF2ZSBpbnRyb2R1Y2VkIGFkbWlzc2lvbiBjb250cm9sIGZvciBuZXcgYW5kDQo+IHJl bW92ZWQgdW5pdHMuIEV4dGVuZCBpdCB0byBYRU5fRE9NQ1RMX1NDSEVET1BfcHV0aW5mbyBh bmQNCj4gcHV0dmNwdWluZm8sIHNvIGdyb3dpbmcgYW4gZXhpc3RpbmcgcmVzZXJ2YXRpb24g dmlhDQo+IHhsIHNjaGVkLXJ0ZHMgaXMgY2hlY2tlZCB0b28uDQo+IA0KPiBwdXRpbmZvIHNl dHMgdGhlIHNhbWUgKHBlcmlvZCwgYnVkZ2V0KSBmb3IgZXZlcnkgdW5pdCBvZiBhDQo+IGRv bWFpbiBhdCBvbmNlLCBzbyBpdCB0ZXN0cyB0aGUgd2hvbGUgZG9tYWluJ3MgdXRpbGl6YXRp b24NCj4gZGVsdGEgYXRvbWljYWxseSwgcmF0aGVyIHRoYW4gdW5pdC1ieS11bml0LCB3aGlj aCBjb3VsZA0KPiBzcHVyaW91c2x5IHJlamVjdCBhbiBvdmVyYWxsLWFjY2VwdGFibGUgY2hh bmdlIGRlcGVuZGluZyBvbg0KPiBpdGVyYXRpb24gb3JkZXIuDQo+IA0KPiBwdXR2Y3B1aW5m byBjaGFuZ2VzIG9uZSB1bml0IGF0IGEgdGltZSwgc28gaXQganVzdCBjYWxscw0KPiBydF9h ZG1pc3Npb25fdGVzdCgpIGRpcmVjdGx5Lg0KPiANCj4gU2lnbmVkLW9mZi1ieTogRnVya2Fu IENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29tPg0KPiAtLS0NCj4gICB4ZW4vY29t bW9uL3NjaGVkL3J0LmMgfCA0MiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysNCj4gICAxIGZpbGUgY2hhbmdlZCwgNDIgaW5zZXJ0aW9ucygrKQ0KPiANCj4g ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWQvcnQuYyBiL3hlbi9jb21tb24vc2NoZWQv cnQuYw0KPiBpbmRleCA5MTI2MzIwODAxLi45NjQzYTI3N2ZlIDEwMDY0NA0KPiAtLS0gYS94 ZW4vY29tbW9uL3NjaGVkL3J0LmMNCj4gKysrIGIveGVuL2NvbW1vbi9zY2hlZC9ydC5jDQo+ IEBAIC0xNTI3LDExICsxNTI3LDQzIEBAIHJ0X2RvbV9jbnRsKA0KPiAgICAgICAgICAgb3At PnUucnRkcy5idWRnZXQgPSBSVERTX0RFRkFVTFRfQlVER0VUIC8gTUlDUk9TRUNTKDEpOw0K PiAgICAgICAgICAgYnJlYWs7DQo+ICAgICAgIGNhc2UgWEVOX0RPTUNUTF9TQ0hFRE9QX3B1 dGluZm86DQo+ICsgICAgew0KPiArICAgICAgICB1aW50NjRfdCBkb21fb2xkX3V0aWwgPSAw LCBuZXdfdXRpbCwgbmV3X3RvdGFsOw0KPiArICAgICAgICB1bnNpZ25lZCBpbnQgbnJfdW5p dHMgPSAwOw0KPiArDQo+ICAgICAgICAgICByYyA9IHJ0X3ZhbGlkYXRlX3BhcmFtcygmb3At PnUucnRkcywgJnBlcmlvZCwgJmJ1ZGdldCk7DQo+ICAgICAgICAgICBpZiAoIHJjICkNCj4g ICAgICAgICAgICAgICBicmVhazsNCj4gICANCj4gKyAgICAgICAgbmV3X3V0aWwgPSBydF91 bml0X3V0aWxpemF0aW9uKHBlcmlvZCwgYnVkZ2V0KTsNCj4gKw0KPiAgICAgICAgICAgc3Bp bl9sb2NrX2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KPiArDQo+ICsgICAgICAgIC8q DQo+ICsgICAgICAgICAqIFNhbWUgKHBlcmlvZCwgYnVkZ2V0KSBmb3IgZXZlcnkgdW5pdCBv ZiBkOiB0ZXN0IGFuZCBjb21taXQNCj4gKyAgICAgICAgICogdGhlIGRvbWFpbidzIHdob2xl IHV0aWxpemF0aW9uIGRlbHRhIGF0b21pY2FsbHksIHJhdGhlcg0KPiArICAgICAgICAgKiB0 aGFuIHVuaXQtYnktdW5pdCwgd2hpY2ggY291bGQgc3B1cmlvdXNseSByZWplY3QgYW4NCj4g KyAgICAgICAgICogb3ZlcmFsbC1hY2NlcHRhYmxlIGNoYW5nZSBkZXBlbmRpbmcgb24gaXRl cmF0aW9uIG9yZGVyLg0KPiArICAgICAgICAgKi8NCj4gKyAgICAgICAgZm9yX2VhY2hfc2No ZWRfdW5pdCAoIGQsIHVuaXQgKQ0KPiArICAgICAgICB7DQo+ICsgICAgICAgICAgICBzdmMg PSBydF91bml0KHVuaXQpOw0KPiArICAgICAgICAgICAgZG9tX29sZF91dGlsICs9IHJ0X3Vu aXRfdXRpbGl6YXRpb24oc3ZjLT5wZXJpb2QsIHN2Yy0+YnVkZ2V0KTsNCj4gKyAgICAgICAg ICAgIG5yX3VuaXRzKys7DQo+ICsgICAgICAgIH0NCj4gKw0KPiArICAgICAgICBuZXdfdG90 YWwgPSBwcnYtPnV0aWxpemF0aW9uIC0gZG9tX29sZF91dGlsICsNCj4gKyAgICAgICAgICAg ICAgICAgICAgKHVpbnQ2NF90KW5yX3VuaXRzICogbmV3X3V0aWw7DQo+ICsNCj4gKyAgICAg ICAgaWYgKCBuZXdfdG90YWwgPiBwcnYtPnV0aWxpemF0aW9uICYmIG5ld190b3RhbCA+IHJ0 X3V0aWxpemF0aW9uX2NhcChkKSApDQo+ICsgICAgICAgIHsNCj4gKyAgICAgICAgICAgIHJj ID0gLUVJTlZBTDsNCg0KSXMgRUlOVkFMIGEgZ29vZCBjaG9pY2UgaGVyZT8gSSB0aGluayBh IGRpZmZlcmVudCBlcnJvciBjb2RlIG1pZ2h0IGJlIHdhbnRlZC4NCg0KPiArICAgICAgICAg ICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQo+ICsgICAg ICAgICAgICBicmVhazsNCj4gKyAgICAgICAgfQ0KPiArDQo+ICsgICAgICAgIHBydi0+dXRp bGl6YXRpb24gPSBuZXdfdG90YWw7DQo+ICsNCj4gICAgICAgICAgIGZvcl9lYWNoX3NjaGVk X3VuaXQgKCBkLCB1bml0ICkNCj4gICAgICAgICAgIHsNCj4gICAgICAgICAgICAgICBzdmMg PSBydF91bml0KHVuaXQpOw0KPiBAQCAtMTU0MCw2ICsxNTcyLDcgQEAgcnRfZG9tX2NudGwo DQo+ICAgICAgICAgICB9DQo+ICAgICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZw cnYtPmxvY2ssIGZsYWdzKTsNCj4gICAgICAgICAgIGJyZWFrOw0KPiArICAgIH0NCj4gICAg ICAgY2FzZSBYRU5fRE9NQ1RMX1NDSEVET1BfZ2V0dmNwdWluZm86DQo+ICAgICAgIGNhc2Ug WEVOX0RPTUNUTF9TQ0hFRE9QX3B1dHZjcHVpbmZvOg0KPiAgICAgICAgICAgd2hpbGUgKCBp bmRleCA8IG9wLT51LnYubnJfdmNwdXMgKQ0KPiBAQCAtMTU4NCw2ICsxNjE3LDE1IEBAIHJ0 X2RvbV9jbnRsKA0KPiAgIA0KPiAgICAgICAgICAgICAgICAgICBzcGluX2xvY2tfaXJxc2F2 ZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQo+ICAgICAgICAgICAgICAgICAgIHN2YyA9IHJ0X3Vu aXQoZC0+dmNwdVtsb2NhbF9zY2hlZC52Y3B1aWRdLT5zY2hlZF91bml0KTsNCj4gKw0KPiAr ICAgICAgICAgICAgICAgIHJjID0gcnRfYWRtaXNzaW9uX3Rlc3QocHJ2LCBkLCBzdmMtPnBl cmlvZCwgc3ZjLT5idWRnZXQsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgcGVyaW9kLCBidWRnZXQpOw0KPiArICAgICAgICAgICAgICAgIGlmICggcmMg KQ0KPiArICAgICAgICAgICAgICAgIHsNCj4gKyAgICAgICAgICAgICAgICAgICAgc3Bpbl91 bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQo+ICsgICAgICAgICAgICAg ICAgICAgIGJyZWFrOw0KPiArICAgICAgICAgICAgICAgIH0NCj4gKw0KPiAgICAgICAgICAg ICAgICAgICBzdmMtPnBlcmlvZCA9IHBlcmlvZDsNCj4gICAgICAgICAgICAgICAgICAgc3Zj LT5idWRnZXQgPSBidWRnZXQ7DQo+ICAgICAgICAgICAgICAgICAgIGlmICggbG9jYWxfc2No ZWQudS5ydGRzLmZsYWdzICYgWEVOX0RPTUNUTF9TQ0hFRFJUX2V4dHJhICkNCg0KDQpKdWVy Z2VuDQo= --------------gjsrgHf5698EAt0Wf0HjYQnv Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------gjsrgHf5698EAt0Wf0HjYQnv-- --------------sOm8GJl0l7gE0HMoNg1Nh0eW-- --------------3KyECH0prxl7JcdHsdJELaLT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqnu30FAwAAAAAACgkQsN6d1ii/Ey92 vwf+NQWRm/D9nj52v/bcPjNoiBePbJaURCvvfcJd4BtCqfSgPlB9JAv+qYc5j8qZRoHEp6/Kp3E3 aGKZeqS/M0h/z3fTmN1OG9YxBdU/EjmL6zaxl3TQAcMFq2FOjFT/SkXNlA5KKH/DsyRJMpn7zP8q yJIN80BI2CJEALA31IyNAm665i/qlZL+Pg1OqMF2WSRUeeE4kiFmwG5KlzGrjkyFKu5wmGiN6cyD 3hv7nN17+nkYTcXmMUrUQyBWcRiT98NSt+ZhZB/KZ+ZkN+b1aoE8ru1+LxYtE9C0pgVSSayL4H7k EmZN/KbsAvcrvQbg8+sKaUhIev8YrrZRE2MTQIjKIQ== =9Fim -----END PGP SIGNATURE----- --------------3KyECH0prxl7JcdHsdJELaLT-- From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:22:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:22:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420596.1646860 (Exim 4.92) (envelope-from ) id 1x62tJ-0003zl-EH; Mon, 14 Sep 2026 09:22:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420596.1646860; Mon, 14 Sep 2026 09:22:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62tJ-0003zc-AU; Mon, 14 Sep 2026 09:22:21 +0000 Received: by outflank-mailman (input) for mailman id 1420596; Mon, 14 Sep 2026 09:22:20 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62tI-0003yp-8w for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:22:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x62tH-003AXA-BE for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:22:19 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7bcc7-bab6-0a2a0a5309dd-0a2a450bc46c-16 for ; Mon, 14 Sep 2026 11:22:19 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7bbda-b7e8-0a2a450b0019-c387df83adf4-3 for ; Mon, 14 Sep 2026 11:18:18 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5E1C31F83B; Mon, 14 Sep 2026 09:18:10 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 84F0C13693; Mon, 14 Sep 2026 09:18:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id eBNGHM+7p2pLTAAAD6G6ig (envelope-from ); Mon, 14 Sep 2026 09:18:07 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789377494; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=9LUU4wJHmbby3CvUXO/2e/oFRTOf97ByeLAhsJU9CcY=; b=u3H0PgFFxxMDcSFbkqg8wSH+MSXbHXjXGDGPERcOcQZLHsw5a6RCZic+j2KP5dMjT1qGbb 0SLYGYTDm9pQbV35UzH42yJgC1UYn3QR4agJ1i991iCs7l2Wxq8Y15EbHdEocY2vjGlm7G IxziWRwnmm/N8SK4CNqSkOwE0uBnBvE= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=rnpOSgrc DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789377490; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=9LUU4wJHmbby3CvUXO/2e/oFRTOf97ByeLAhsJU9CcY=; b=rnpOSgrcbTrgjJVvVOM8aggOsUW+tv0HqVhj+PJikreiV96gmCWrGGFOoR0HULxPSx39OJ A2Eyk48u5eopmM+mK8nJayn3u2ZjHDnTn2LTfe1POmH/EnZxH5wcbtyZUugdrR7oYv6AwU I4uvhxynJL+s68eontXfHZAjT43ZuXI= Message-ID: <55c833dd-40c5-411f-a1d7-85866e915669@suse.com> Date: Mon, 14 Sep 2026 11:18:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] xen/sched: rtds: report utilization and cap via debug key To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-4-frn1furkan10@gmail.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260826045720.5779-4-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------77ynnFbt7DXHbmsioHu0inj9" X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 5E1C31F83B X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_BASE64_TEXT(0.10)[]; MX_GOOD(-0.01)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org]; RCPT_COUNT_TWELVE(0.00)[12]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Spam-Flag: NO X-Spam-Score: -5.41 X-purgate-ID: tlsNG-42698a/1789377499-A94C39EA-30EEE938/13/0 X-purgate-type: clean X-purgate-size: 9561 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------77ynnFbt7DXHbmsioHu0inj9 Content-Type: multipart/mixed; boundary="------------7mAPCu7jw2zsvZSGCIxgX3m8"; protected-headers="v1" From: Juergen Gross To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com Message-ID: <55c833dd-40c5-411f-a1d7-85866e915669@suse.com> Subject: Re: [PATCH 3/5] xen/sched: rtds: report utilization and cap via debug key References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-4-frn1furkan10@gmail.com> In-Reply-To: <20260826045720.5779-4-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------7mAPCu7jw2zsvZSGCIxgX3m8 Content-Type: multipart/mixed; boundary="------------NfDGBOM4VulduyPkA8fnN8J7" --------------NfDGBOM4VulduyPkA8fnN8J7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMDguMjYgMDY6NTcsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gUHJpbnQgYSBj cHVwb29sJ3MgYWRtaXR0ZWQgdXRpbGl6YXRpb24gYWdhaW5zdCBpdHMgY2FwYWNpdHkgaW4g dGhlDQo+ICdyJyBkZWJ1ZyBreSAoeGwgZGVidWcta2V5cyByKSwgc28gYW4gb3BlcmF0b3Ig Y2FuIHNlZSB0aGUgdG90YWwNCj4gdXNhZ2Ugb2YgYSBjcHVwb29sLg0KPiANCj4gU2lnbmVk LW9mZi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29tPg0KPiAt LS0NCj4gICB4ZW4vY29tbW9uL3NjaGVkL3J0LmMgfCAxMCArKysrKysrKysrDQo+ICAgMSBm aWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKykNCj4gDQo+IGRpZmYgLS1naXQgYS94ZW4v Y29tbW9uL3NjaGVkL3J0LmMgYi94ZW4vY29tbW9uL3NjaGVkL3J0LmMNCj4gaW5kZXggOTY0 M2EyNzdmZS4uMDU4MmMwMDk0ZCAxMDA2NDQNCj4gLS0tIGEveGVuL2NvbW1vbi9zY2hlZC9y dC5jDQo+ICsrKyBiL3hlbi9jb21tb24vc2NoZWQvcnQuYw0KPiBAQCAtMzk5LDEyICszOTks MjIgQEAgcnRfZHVtcChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMpDQo+ICAgICAgIGNv bnN0IHN0cnVjdCBydF91bml0ICpzdmM7DQo+ICAgICAgIGNvbnN0IHN0cnVjdCBydF9kb20g KnNkb207DQo+ICAgICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQo+ICsgICAgdWludDY0X3Qg Y2FwOw0KPiAgIA0KPiAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmcHJ2LT5sb2NrLCBmbGFn cyk7DQo+ICAgDQo+ICAgICAgIGlmICggbGlzdF9lbXB0eSgmcHJ2LT5zZG9tKSApDQo+ICAg ICAgICAgICBnb3RvIG91dDsNCj4gICANCj4gKyAgICBjYXAgPSAodWludDY0X3QpY3B1bWFz a193ZWlnaHQob3BzLT5jcHVwb29sLT5yZXNfdmFsaWQpICoNCj4gKyAgICAgICAgICBSVERT X1VUSUxfU0NBTEUgKiBSVERTX1VUSUxfQ0FQX1BDVCAvIDEwMDsNCj4gKw0KPiArICAgIGlm ICggY2FwICkNCj4gKyAgICAgICAgcHJpbnRrKCJVdGlsaXphdGlvbjogJWxsdSUlIG9mIGNh cGFjaXR5XG4iLA0KPiArICAgICAgICAgICAgICAgKHVuc2lnbmVkIGxvbmcgbG9uZykocHJ2 LT51dGlsaXphdGlvbiAqIDEwMCAvIGNhcCkpOw0KPiArICAgIGVsc2UNCj4gKyAgICAgICAg cHJpbnRrKCJVdGlsaXphdGlvbjogY3B1cG9vbCBoYXMgbm8gY2FwYWNpdHlcbiIpOw0KPiAr DQo+ICAgICAgIHJ1bnEgPSBydF9ydW5xKG9wcyk7DQo+ICAgICAgIGRlcGxldGVkcSA9IHJ0 X2RlcGxldGVkcShvcHMpOw0KPiAgICAgICByZXBscSA9IHJ0X3JlcGxxKG9wcyk7DQoNClJl dmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdl bg0K --------------NfDGBOM4VulduyPkA8fnN8J7 Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------NfDGBOM4VulduyPkA8fnN8J7-- --------------7mAPCu7jw2zsvZSGCIxgX3m8-- --------------77ynnFbt7DXHbmsioHu0inj9 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqnu8oFAwAAAAAACgkQsN6d1ii/Ey8/ KQf/S1QU7Dx0n2cIQJMSD4+VpZ0WYWoPxw/GILotfJ/+VEd6uxtXJC2cSSijFIeaToATFk/ff7cq jAtP+ml8KIzgxNk6yWxOX4ZNJnNOkEp/KJfUyWN/e7Uu1otMtTYuwCaC2lsTb7cz5N2lE6TlGxc6 hWtIyvmXhMN+dij9TvK/8wKliCrMT2cMH2yjoG2t1PfGAtOlF0LwY0G30pkNBMXFPmfL6Sfxp86P 0iWjngYCweJFsiLBxygcKr+Qph9MWLUv6OWuxgqfOW8z/T0Bt8TXvI8LuwydKopMMjk/FaxaqIpw wa5YdKW+kPF3EIiS09N8l+A1+lcoa5YHfPyjOyWuKg== =Fvsd -----END PGP SIGNATURE----- --------------77ynnFbt7DXHbmsioHu0inj9-- From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:27:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:27:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420616.1646869 (Exim 4.92) (envelope-from ) id 1x62yT-0004tw-0k; Mon, 14 Sep 2026 09:27:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420616.1646869; Mon, 14 Sep 2026 09:27:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62yS-0004tp-UF; Mon, 14 Sep 2026 09:27:40 +0000 Received: by outflank-mailman (input) for mailman id 1420616; Mon, 14 Sep 2026 09:27:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x62yS-0004sc-28 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:27:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x62yQ-009FHJ-MH for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:27:38 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7be06-8faa-0a2a0a5109dd-0a2a45099b12-30 for ; Mon, 14 Sep 2026 11:27:38 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7be0a-be1a-0a2a45090019-d1558032e1da-3 for ; Mon, 14 Sep 2026 11:27:38 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49d0da752ffso37350395e9.3 for ; Mon, 14 Sep 2026 02:27:38 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb34fdd2sm25862446f8f.28.2026.09.14.02.27.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 02:27: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789378058; x=1789982858; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=xx/j5TK8XLtU89U2kDZ8oobMIgRGALq6rhd2aCZgOP0=; b=OZlPZBSDqi+f/gfi5IQqNtxH5PbvwJGBUMVia4tjfweLO/ZFVkGO+OQtQlj46pOJju mbGOEVpXLGhJZCVEgTyQXBrF5vQjiDuzUOMM+czpHnwJIt0qeX4yP8rQ9bPy+PCTL0zY 1eZuQLyVoa8alurusmIgDo9RXXV4M+DSpDkbg/EyTBDDJqL58IFth1C4OLgsrtEHvSJp tvlgrjUM73Fgtzvo2Cj5z/uefmiwiyp7H0lac5UNBjJtCODfXOn9Zv0zVWyQ+PlZPGG8 TW4hpdDEOkdyoTeJCzOMNMA2+PXXix2GuB/1ivd7NB/kc6jgjfg/8mf84G3plm8WDj6O e32g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789378058; x=1789982858; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references: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:content-type; bh=xx/j5TK8XLtU89U2kDZ8oobMIgRGALq6rhd2aCZgOP0=; b=eoRcT2x0fbbWklKoQvWbUz0PBGSv+p42vy/2de+mZtPkgeocUcCHtvxuJoImZZy50i 9tBLElMNf6//m0R9kgIIgv5CfCXieLAgF20AxViAKzeeTQtelTbvlQTrnYk+Kyl1FvTY dgao8hawvmiZELd1GxX/TVJaKq0BqMhkOMLZbv/Dgwu9uFYpAQUotQNUFW4kAEXEzkUO C48hDHWi/D3ou28bxkf7vSwzJieCmWcr7JJxq8HoXjMypmK6UWNtyI/gEIKm/Z02IZRN 1Tmr+w4jjXkf/fkcid7HkdXP/UeQdDQyL47NgM3HlLZ7amrKhSLrvEGQqxsmW+wbzjYh 153g== X-Gm-Message-State: AFuF++mrV49mLlsccGpXFX4ApieznzIdXjWYVT9C2fyAXBJJBgeVVVos RWpUiCujRc18Iats2rN0JdxCRUaj5HQ+3ECr3k+fZ8Hr6pyoiD0IPk9yGZRIt6HmWLbwBIY8Eqj g0Dk= X-Gm-Gg: AYBFou2rb3asiS0z0q3ygynx4rsxm9XsBv5/zK78qYQ5XKPhIVAVmQamWtM6f+hfIci cTVYi0qBVdsZ8e0XpKnX1Ze4FeiIRqXxD4qWDTWYQYjugcH96R+b5zfOJJZL55d/6Lbdwkifdmx NbQ7xWdX9WElru3m2qnRDyTyScUpDvKodZYA3aENMGffBxktMrlVm9AlZz8poELygHXOd49efIH P96h1gISb+EWrR90OCdq5vPbpgjMcdrGzm7RCyfrNCcitPeKSjBMs++tA0PVhqOyY/d+nw2vW63 0zqP9VbQgzL2qEUoU/WbKxkPJWmmsp45u2GXMImNtOlibGTpjLU04/uEeJgI8Wr88ccqkOcbYST 2/PV6qe9uB0H2KmlqkTsj7Ii26Tq/Z3sIQQJzOHAfb1dVYo51f+zwMMdYfPc32DQJZaIy0oBNM2 FjwDROGuYfvOlP7ewlm8yRmpEYaIfUhGUKZZt5tkC5BHJQnHsM3oTkzSuAf7+bqh2m7/aawhyVj vS/T3+VjQU+Tg== X-Received: by 2002:a05:600c:3acd:b0:49d:10d6:fd55 with SMTP id 5b1f17b1804b1-49e7a639518mr16575565e9.1.1789378058009; Mon, 14 Sep 2026 02:27:38 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 11:27:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: New Defects reported by Coverity Scan for XenProject To: "xen-devel@lists.xenproject.org" References: <6aa6dded12155_28a4c52b6718b7799c6170@prd-scan-dashboard-0.mail> Content-Language: en-US From: Jan Beulich In-Reply-To: <6aa6dded12155_28a4c52b6718b7799c6170@prd-scan-dashboard-0.mail> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1789378058-BD0CD034-D1BB223E/0/0 X-purgate-type: clean X-purgate-size: 1435 On 13.09.2026 19:31, scan-admin@coverity.com wrote: > 1 new defect(s) introduced to XenProject found with Coverity Scan. > 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 1 of 1 defect(s) > > > ** CID 1701169: Control flow issues (DEADCODE) > /xen/arch/x86/hvm/hvm.c: 5136 in do_hvm_op() > > > _____________________________________________________________________________________________ > *** CID 1701169: Control flow issues (DEADCODE) > /xen/arch/x86/hvm/hvm.c: 5136 in do_hvm_op() > 5130 rc = -EINVAL; > 5131 if ( unlikely(d != current->domain) ) > 5132 rc = -EOPNOTSUPP; > 5133 else if ( is_hvm_domain(d) && paging_mode_shadow(d) ) > 5134 rc = xsm_hvm_param(XSM_TARGET, d, op); > 5135 if ( !rc ) >>>> CID 1701169: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement: "pagetable_dying(a.gpa);". > 5136 pagetable_dying(a.gpa); > 5137 > 5138 rcu_unlock_domain(d); > 5139 break; > 5140 } Nothing really changed here recently, so how can this be a new violation? It's presumably related to SHADOW_PAGING=n by default now, but that change was done a while ago. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:38:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:38:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420624.1646877 (Exim 4.92) (envelope-from ) id 1x639F-00071R-UW; Mon, 14 Sep 2026 09:38:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420624.1646877; Mon, 14 Sep 2026 09:38:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x639F-00071K-Rq; Mon, 14 Sep 2026 09:38:49 +0000 Received: by outflank-mailman (input) for mailman id 1420624; Mon, 14 Sep 2026 09:38:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x639E-00071D-CA for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:38:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x639C-00FDzN-VZ for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:38:46 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7c09b-e002-0a2a0a5209dd-0a2a4509cfb0-20 for ; Mon, 14 Sep 2026 11:38:46 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7bd5d-be1a-0a2a45090019-c387df82c63e-3 for ; Mon, 14 Sep 2026 11:24:45 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 43D3921BF6; Mon, 14 Sep 2026 09:24:37 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1A7411368C; Mon, 14 Sep 2026 09:24:35 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id omE4NVO9p2o2VAAAD6G6ig (envelope-from ); Mon, 14 Sep 2026 09:24:35 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789377881; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=3D71y6FKL1ItUXUtk3+oPv378MqWCL3bWZ67e3DUc2g=; b=Ee0RmTOjQJr3X5MtCef1o00Tt0Co7R/pAPpqWO0sOEXuJS5lAFeniLpN+2rAjC6KU9Qwqs Yjha2N6wGu93DDUoSQR83Mctc+jNlZP67Mu6iVR9wazNJ7vbVocmhtfW2AXX5V3dZnSHXI Yuf3bAmiaxj1RdWIBhPPdQFVJmTN0Rw= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=EpHh1gCW DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789377877; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=3D71y6FKL1ItUXUtk3+oPv378MqWCL3bWZ67e3DUc2g=; b=EpHh1gCWPUm+zuawO7jna8uHFMkSlcREgod12ZI3brS/XdtfdEuPCIZ60Pn8WK+UG5DFyU lvFhbOwvFj+p/DH9lMfiMVmuLXRcaphOJBJnBA7ExU0eIVjoQwhHWO4rjlyRZBMuXxBLcp 2MKKLLxcfe2pBDJ3zwB1+nOchigbXYk= Message-ID: Date: Mon, 14 Sep 2026 11:24:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/5] xen/sched: rtds: make admission control cpupool-wide toggleable To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-5-frn1furkan10@gmail.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260826045720.5779-5-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------xIEm19SdR6OEU6LTHgx3jCMy" X-Spam-Score: -5.41 X-Rspamd-Queue-Id: 43D3921BF6 X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Level: X-Rspamd-Action: no action X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_BASE64_TEXT(0.10)[]; MX_GOOD(-0.01)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; ARC_NA(0.00)[]; RCPT_COUNT_TWELVE(0.00)[12]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:mid] X-Spam-Flag: NO X-purgate-ID: tlsNG-bad1c0/1789377885-BCECE034-B8E494FC/35/110847 X-purgate-type: clean X-purgate-size: 8177 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------xIEm19SdR6OEU6LTHgx3jCMy Content-Type: multipart/mixed; boundary="------------9FtGX50puUWWvzKJ1czPvVGx"; protected-headers="v1" From: Juergen Gross To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com Message-ID: Subject: Re: [PATCH 4/5] xen/sched: rtds: make admission control cpupool-wide toggleable References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-5-frn1furkan10@gmail.com> In-Reply-To: <20260826045720.5779-5-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------9FtGX50puUWWvzKJ1czPvVGx Content-Type: multipart/mixed; boundary="------------cpKQIODaH8mfgOCcuBdGnbcn" --------------cpKQIODaH8mfgOCcuBdGnbcn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMDguMjYgMDY6NTcsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gQWRkIGEgcGVy LWNwdXBvb2wgb24vb2ZmIHN3aXRjaCBmb3IgUlREUyBhZG1pc3Npb24gY29udHJvbCB2aWEN Cj4gWEVOX1NZU0NUTF9zY2hlZHVsZXJfb3AsIGVuYWJsZWQgYnkgZGVmYXVsdCwgc28gYW4g b3BlcmF0b3IgY2FuDQo+IGRpc2FibGUvZW5hYmxlIGVuZm9yY2VtZW50IGZvciBhIHBvb2wu DQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBGdXJrYW4gQ2FsaXNrYW4gPGZybjFmdXJrYW4xMEBn bWFpbC5jb20+DQoNCk5vIHJlbWFya3MgZnJvbSBtZSBhZGRpdGlvbmFsIHRvIEphbidzLg0K DQoNCkp1ZXJnZW4NCg== --------------cpKQIODaH8mfgOCcuBdGnbcn Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------cpKQIODaH8mfgOCcuBdGnbcn-- --------------9FtGX50puUWWvzKJ1czPvVGx-- --------------xIEm19SdR6OEU6LTHgx3jCMy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqnvUkFAwAAAAAACgkQsN6d1ii/Ey9F WAgAiXu+NBosy9TbDRh78Ij2rGgNiXEpD8Iew3t1RL1F79QBovp2GfFV/sdAEwx2Zataf8ADuPzk L3A9fi//k1AYN18LWc92raLbaVJdgMOaJGGnOy1CAB2H9gdn3W1ZEb/IXtZS1movRy2/hCBfLGVn On7VG78qAWYVwCtx/YMwcfj3t0tT/Rdc3HpdhphcUmLxCzQoI7RYcCb9isDE3ioYPYX5j6WF3Zhf 3JwVj87VTdA2cgOkuHJJ+vzZHOXiT9bTKoviImFYKnkL0u9SPO7OXSUZ1S7ve/ZwAco/W9bSxTJ5 WC+ZRFVKZ5vIQbCKzhNhoGOaYETq7+66NGDu45ZZ5g== =nlmQ -----END PGP SIGNATURE----- --------------xIEm19SdR6OEU6LTHgx3jCMy-- From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:39:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:39:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420625.1646887 (Exim 4.92) (envelope-from ) id 1x639S-0007Hc-7m; Mon, 14 Sep 2026 09:39:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420625.1646887; Mon, 14 Sep 2026 09:39:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x639S-0007HV-51; Mon, 14 Sep 2026 09:39:02 +0000 Received: by outflank-mailman (input) for mailman id 1420625; Mon, 14 Sep 2026 09:39:00 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x639Q-0007Gg-GB for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:39:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x639P-009Hhx-Ba for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:38:59 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7c09b-e002-0a2a0a5209dd-0a2a4509cfb0-34 for ; Mon, 14 Sep 2026 11:38:59 +0200 Received: from [209.85.221.44] (helo=mail-wr1-f44.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7bf86-be1a-0a2a45090019-d155dd2ce50f-3 for ; Mon, 14 Sep 2026 11:33:58 +0200 Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-48441a2ba1bso2069915f8f.1 for ; Mon, 14 Sep 2026 02:33:58 -0700 (PDT) Received: from [172.18.88.57] ([185.104.138.120]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb32e7f5sm25435042f8f.9.2026.09.14.02.33.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 02:33:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789378438; x=1789983238; darn=lists.xenproject.org; h=content-type: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:content-type; bh=Uu4VpEywB5kyiFTIqw8Hg2kpjb2ljJV1v1EjXssvCuw=; b=Fqb/4Iq/Xm/PqyeSrZm9IqqQ7UkybHbVJQGDsOs03GU+V1enCSY8EOO+j2ZbUVku3B 5G4Lk6EMT9dPN0LnrXKc+OWdQ9n4P9NRpNLONAgnbrBUo00IlLYw/IzwPAADgCMgRUpm DRhpP6LQ9xEp0wxGeG3n7wXLqmpUgarGjeLcrOY/0am9H11V8lRT5XrHVGaIpOrd6qms uZMEjavK2oZhasaX0pjReYQazryeWSaHWoaFH6f3RcKAZdttIix7qOXBgznbpy4E10QS JLwmaV/3CjbLpLTh4dJcWZ9bTVDCTIXnKYMFlXPBkj1MAenC18imdf897TMKzMv/zDr3 +zwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789378438; x=1789983238; h=content-type: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 :content-type; bh=Uu4VpEywB5kyiFTIqw8Hg2kpjb2ljJV1v1EjXssvCuw=; b=iQTT8sqdx0ZErdQRpXL876z+w/pzUU4nBydFw+TKadkkXGIbIJAdJjDGE1jBJN9KXL VT8FwQ1F6I3jwT7qLzPCCEK5JwX+0exT+my75kxltnUUQV7tLOIKDIcdTxni7NTHAwrw YSVxZZ+cxJR1eDMn8BjGWHjTHWuFOUjt7hShyZXYAgPi6El2JQYsqHrMSMTnaRMdwBOP +NROCe0ucSQryBDeiRf3HMISsSaVW5l9IIwjjT4RdlXM424T/MOsSMPP2jibNT44vfXO SyuTVAlwfEVOFPLCmpw0+rkvfyWo0HJmWyFG06PL+a+BlnnyTeBOpWnbH72y2t/HJhfz ulqg== X-Forwarded-Encrypted: i=1; AKwUvBxLewG94DCxfrCWb9YeqAZKYQVEyYZa/Oib4k1s/qCvskvUYO3JYU21Y12ffhvLBzGdcV3D/+Pzn24=@lists.xenproject.org X-Gm-Message-State: AFuF++kl/VigBCfBlj0gS9NxVcpS2BlVfTjNnGy17N2pp34CzJbT4BWZ l1CVPvis/dXe8bz5cd7mzioJCp9eXrwP5KOA+jK5g7qcrsVSneODUFc7z5iIRklXQMs= X-Gm-Gg: AYBFou2Pg60wW+j+6iliEj+RMV5qZCVm1hwFAed98D28mhlsv9A0/HP2+uHm3hEyt8E 8IVV43z2SvTD3IqBylFo7lmgNOKNiYS6PnVonowFdkOpS6mEHNDNuMPzYifVc4ELBgQUVIDAaXc MQIemj39h8qodEdVT/n89NO9fAKjE99PbAnZAwuLxoG3U/K0j/c9zEbJnG0p/fzixlxnIQdcXf/ HxIYZZSg1WjiqBMINFAlqXlr7T9ml8iFhpBB2O2sOr0TmJ20aRjj6JxSp2vAI1S+2q2cAxtL0xb Kql69xZY62mZP1eKhWegVqwmLQp6x1CKoiaQNYRD8aCrQ9jS98G2p6F4ONYUSHBylqoAo+sLZZE mE7wdimWG7gmszvoyIpUdDE8jtBfzR05BiDsJ67bapzvdevQtx7L8Ch1jc3Bs8/wJUenESE9rpX aQ/JYh6dr5kRW9YEj1vJYLyIBr3B0+VoFUUC/DUFnqUY8MtEReWonKOs4+CabPgZhlUloh35K2N zDiW/mW X-Received: by 2002:a5d:5e92:0:b0:486:f8c4:21e with SMTP id ffacd0b85a97d-48702b16c03mr1753853f8f.28.1789378438167; Mon, 14 Sep 2026 02:33:58 -0700 (PDT) Message-ID: <6fc3aa29-f6b5-43fd-893c-f4cbab0b5c84@suse.com> Date: Mon, 14 Sep 2026 11:33:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Jan Beulich , Furkan Caliskan Cc: andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com, xen-devel@lists.xenproject.org References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> <325f2b44-ea61-45e8-a681-c0bb08d5766a@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <325f2b44-ea61-45e8-a681-c0bb08d5766a@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vUVAImQAa0BvlNsfrJQYelW2" X-purgate-ID: tlsNG-bad1c0/1789378438-BD2CC034-3F888E7A/35/110847 X-purgate-type: clean X-purgate-size: 12169 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vUVAImQAa0BvlNsfrJQYelW2 Content-Type: multipart/mixed; boundary="------------ytxFuEYEwHjlgfcFg1t0EaZv"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich , Furkan Caliskan Cc: andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com, xen-devel@lists.xenproject.org Message-ID: <6fc3aa29-f6b5-43fd-893c-f4cbab0b5c84@suse.com> Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> <325f2b44-ea61-45e8-a681-c0bb08d5766a@suse.com> In-Reply-To: <325f2b44-ea61-45e8-a681-c0bb08d5766a@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------ytxFuEYEwHjlgfcFg1t0EaZv Content-Type: multipart/mixed; boundary="------------QjaWK6xw88WW67Vw7FBJbQzo" --------------QjaWK6xw88WW67Vw7FBJbQzo Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQuMDkuMjYgMTE6MTMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNC4wOS4yMDI2 IDExOjEwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gT24gMjYuMDguMjYgMDY6NTcsIEZ1 cmthbiBDYWxpc2thbiB3cm90ZToNCj4+PiBAQCAtNjM1LDYgKzY1Niw1NCBAQCByZXBscV9y ZWluc2VydChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCBydF91bml0ICpz dmMpDQo+Pj4gICAgICAgICAgICBzZXRfdGltZXIoJnJ0X3ByaXYob3BzKS0+cmVwbF90aW1l ciwgcmVhcm1fc3ZjLT5jdXJfZGVhZGxpbmUpOw0KPj4+ICAgIH0NCj4+PiAgICANCj4+PiAr LyoNCj4+PiArICogYnVkZ2V0IDw8IFJURFNfVVRJTF9TSElGVCBjYW4ndCBvdmVyZmxvdzog cnRfdmFsaWRhdGVfcGFyYW1zKCkNCj4+PiArICogY2FwcyBidWRnZXQgYXQgUlREU19NQVhf QlVER0VULiBwZXJpb2QgPT0gMCBtZWFucyAibm8NCj4+PiArICogcmVzZXJ2YXRpb24iIChh IHVuaXQgYmVpbmcgcmVtb3ZlZCksIG5vdCBhbiBlcnJvci4NCj4+PiArICovDQo+Pj4gK3N0 YXRpYyB1aW50NjRfdA0KPj4+ICtydF91bml0X3V0aWxpemF0aW9uKHNfdGltZV90IHBlcmlv ZCwgc190aW1lX3QgYnVkZ2V0KQ0KPj4+ICt7DQo+Pj4gKyAgICBpZiAoIHBlcmlvZCA8PSAw ICkNCj4+PiArICAgICAgICByZXR1cm4gMDsNCj4+PiArDQo+Pj4gKyAgICByZXR1cm4gKCh1 aW50NjRfdClidWRnZXQgPDwgUlREU19VVElMX1NISUZUKSAvICh1aW50NjRfdClwZXJpb2Q7 DQo+Pj4gK30NCj4+PiArDQo+Pj4gKy8qDQo+Pj4gKyAqIFV0aWxpemF0aW9uIGNhcGFjaXR5 IG9mIHRoZSBjcHVwb29sIGRvbWFpbiBkIHJlc2lkZXMgaW4uDQo+Pj4gKyAqLw0KPj4+ICtz dGF0aWMgdWludDY0X3QNCj4+PiArcnRfdXRpbGl6YXRpb25fY2FwKGNvbnN0IHN0cnVjdCBk b21haW4gKmQpDQo+Pj4gK3sNCj4+PiArICAgIHVuc2lnbmVkIGludCBjcHVzID0gY3B1bWFz a193ZWlnaHQoY3B1cG9vbF9kb21haW5fbWFzdGVyX2NwdW1hc2soZCkpOw0KPj4+ICsNCj4+ PiArICAgIHJldHVybiAodWludDY0X3QpY3B1cyAqIFJURFNfVVRJTF9TQ0FMRSAqIFJURFNf VVRJTF9DQVBfUENUIC8gMTAwOw0KPj4+ICt9DQo+Pj4gKw0KPj4+ICsvKg0KPj4+ICsgKiBS ZXBsYWNlcyBhIHVuaXQncyByZXNlcnZhdGlvbiBhbmQgdXBkYXRlcyBwcnYtPnV0aWxpemF0 aW9uDQo+Pj4gKyAqIHRvIG1hdGNoLiBHcm93dGggdGhhdCB3b3VsZCBwdXNoIHV0aWxpemF0 aW9uIG92ZXIgdGhlDQo+Pj4gKyAqIGNwdXBvb2wncyBjYXAgaXMgcmVmdXNlZC4gUmVtb3Zp bmcgYSB1bml0IG9yIHNocmlua2luZw0KPj4+ICsgKiBhIHVuaXQncyByZXNlcnZhdGlvbiBh bHdheXMgc3VjY2VlZC4NCj4+PiArICovDQo+Pj4gK3N0YXRpYyBpbnQNCj4+PiArcnRfYWRt aXNzaW9uX3Rlc3Qoc3RydWN0IHJ0X3ByaXZhdGUgKnBydiwgY29uc3Qgc3RydWN0IGRvbWFp biAqZCwNCj4+PiArCQkgICBzX3RpbWVfdCBvbGRfcGVyaW9kLCBzX3RpbWVfdCBvbGRfYnVk Z2V0LA0KPj4+ICsJCSAgIHNfdGltZV90IG5ld19wZXJpb2QsIHNfdGltZV90IG5ld19idWRn ZXQpDQo+Pg0KPj4gSSB0aGluayB0aGUgZnVuY3Rpb24gbmFtZSBpc24ndCBhcHByb3ByaWF0 ZS4gVGhlIGZ1bmN0aW9uIGRvZXNuJ3QgdGVzdCBvbmx5LCBpdA0KPj4gaXMgc2V0dGluZyB0 aGUgdXRpbGl6YXRpb24sIHRvby4NCj4+DQo+PiBXaGF0IGFib3V0IHJ0X3RyeV9zZXRfdXRp bGl6YXRpb24oKSBpbnN0ZWFkPyBBbmQgbWFrZSB0aGUgcmV0dXJuIHR5cGUgYm9vbA0KPj4g KHRydWUgb24gc3VjY2VzcykuDQo+Pg0KPj4+ICt7DQo+Pj4gKyAgICB1aW50NjRfdCBvbGRf dXRpbCA9IHJ0X3VuaXRfdXRpbGl6YXRpb24ob2xkX3BlcmlvZCwgb2xkX2J1ZGdldCk7DQo+ Pj4gKyAgICB1aW50NjRfdCBuZXdfdXRpbCA9IHJ0X3VuaXRfdXRpbGl6YXRpb24obmV3X3Bl cmlvZCwgbmV3X2J1ZGdldCk7DQo+Pj4gKyAgICB1aW50NjRfdCB0b3RhbCAgICA9IHBydi0+ dXRpbGl6YXRpb24gLSBvbGRfdXRpbCArIG5ld191dGlsOw0KPj4+ICsNCj4+PiArICAgIGlm ICggbmV3X3V0aWwgPiBvbGRfdXRpbCAmJiB0b3RhbCA+IHJ0X3V0aWxpemF0aW9uX2NhcChk KSApDQo+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4gKw0KPj4+ICsgICAgcHJ2 LT51dGlsaXphdGlvbiA9IHRvdGFsOw0KPj4+ICsNCj4+PiArICAgIHJldHVybiAwOw0KPj4+ ICt9DQo+Pj4gKw0KPj4+ICAgIC8qDQo+Pj4gICAgICogUGljayBhIHZhbGlkIHJlc291cmNl IGZvciB0aGUgdW5pdCB2Yw0KPj4+ICAgICAqIFZhbGlkIHJlc291cmNlIG9mIGFuIHVuaXQg aXMgaW50ZXNlY3Rpb24gb2YgdW5pdCdzIGFmZmluaXR5DQo+Pj4gQEAgLTg5Miw4ICs5ODMs MTkgQEAgcnRfYWxsb2NfdWRhdGEoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBzdHJ1 Y3Qgc2NoZWRfdW5pdCAqdW5pdCwgdm9pZCAqZGQpDQo+Pj4gICAgc3RhdGljIHZvaWQgY2Zf Y2hlY2sNCj4+PiAgICBydF9mcmVlX3VkYXRhKGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9w cywgdm9pZCAqcHJpdikNCj4+PiAgICB7DQo+Pj4gKyAgICBzdHJ1Y3QgcnRfcHJpdmF0ZSAq cHJ2ID0gcnRfcHJpdihvcHMpOw0KPj4+ICAgICAgICBzdHJ1Y3QgcnRfdW5pdCAqc3ZjID0g cHJpdjsNCj4+PiAgICANCj4+PiArICAgIGlmICggc3ZjICYmICFpc19pZGxlX3VuaXQoc3Zj LT51bml0KSApDQo+Pj4gKyAgICB7DQo+Pj4gKyAgICAgICAgdW5zaWduZWQgbG9uZyBmbGFn czsNCj4+PiArDQo+Pj4gKyAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUoJnBydi0+bG9jaywg ZmxhZ3MpOw0KPj4+ICsgICAgICAgIHJ0X2FkbWlzc2lvbl90ZXN0KHBydiwgc3ZjLT51bml0 LT5kb21haW4sDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHN2Yy0+cGVyaW9k LCBzdmMtPmJ1ZGdldCwgMCwgMCk7DQo+Pg0KPj4gVGhpcyB1c2UgY2FzZSBjbGVhcmx5IHNo b3dzIHlvdSBhcmUgbm90IG9ubHkgdGVzdGluZy4gOi0pDQo+IA0KPiBZZXQgYXQgdGhlIHNh bWUgdGltZSBpZ25vcmluZyBwb3NzaWJsZSBlcnJvcnMuDQoNCkkgZG9uJ3Qgc2VlIGhvdyB0 aGlzIGNvdWxkIGhhcHBlbiwgYXMgbmV3X3BlcmlvZCBhbmQgbmV3X2J1ZGdldCBhcmUgYm90 aCAwIGhlcmUuDQoNCg0KSnVlcmdlbg0K --------------QjaWK6xw88WW67Vw7FBJbQzo Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------QjaWK6xw88WW67Vw7FBJbQzo-- --------------ytxFuEYEwHjlgfcFg1t0EaZv-- --------------vUVAImQAa0BvlNsfrJQYelW2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqnv38FAwAAAAAACgkQsN6d1ii/Ey/y vQf/aiOSUiAEk/b7FiYYj6FFVqjnAd38Py7rwAKMM+Eu6PCAB1kKkC4Fvvd2Xpob89/83Z6nX/Nu 1uv4Lkqz/KJrOgz1FUNDP0faY4h+/zC/AdEfG5zQX7fyWZREIP7QSlMMFbrWdT9XyhXjrxegbqpO aOGEoUjEbv76AsQLI2J+Lual2IoolMMwbfsYsoiAxM6+BhqxkBchAm7ry5HkgI+yF2rRAsQJNUAs MrcFCX5epuHs2g3irNtslX8fNtP1GKLaGf9XctvPa2Uq9bQohDxFhC4cQllwLjBWTpECP+lutuui KLegivvj5OG2lpjOTwLT0/gVpSJvZeh8DOMA1oEQ7A== =7ER3 -----END PGP SIGNATURE----- --------------vUVAImQAa0BvlNsfrJQYelW2-- From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:44:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:44:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420641.1646896 (Exim 4.92) (envelope-from ) id 1x63Em-0000f8-Ql; Mon, 14 Sep 2026 09:44:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420641.1646896; Mon, 14 Sep 2026 09:44:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63Em-0000f0-N9; Mon, 14 Sep 2026 09:44:32 +0000 Received: by outflank-mailman (input) for mailman id 1420641; Mon, 14 Sep 2026 09:44:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63Ek-0000eu-J6 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:44:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x63Ej-009Ieo-QZ for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:44:29 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7c1ed-e002-0a2a0a5209dd-0a2a45088b7c-28 for ; Mon, 14 Sep 2026 11:44:29 +0200 Received: from [52.101.57.34] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7c1fc-f659-0a2a45080019-346539222b18-3 for ; Mon, 14 Sep 2026 11:44:29 +0200 Received: from DS0PR03MB7557.namprd03.prod.outlook.com (2603:10b6:8:1fc::8) by PH9PR03MB150476.namprd03.prod.outlook.com (2603:10b6:510:419::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Mon, 14 Sep 2026 09:44:21 +0000 Received: from DS0PR03MB7557.namprd03.prod.outlook.com ([fe80::6884:8bd5:3e4d:fde7]) by DS0PR03MB7557.namprd03.prod.outlook.com ([fe80::6884:8bd5:3e4d:fde7%5]) with mapi id 15.21.0406.007; Mon, 14 Sep 2026 09:44:20 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bu4LQQQLeOrvyQavYgmGeRAB7L/Q8S3GjfmFoBlroudlIyBnodyofSLY4iJhLLQBSjMmPE2yFC5gYayiCQA2knr2j0y+a9Y4EJVn/ehGqbe1ks/faC7w3EYbU881v28T+F8L4RZR9BuUdzZm1o0cfsOyXUPWEEo+xlBk4KUjh+wECgoKdFc4aVq1/UfSx8z8zSbCkf0ObqL21n5qKhLIVNRiZY94+6iIm9ejNS1LoHvqnNVdS4n/mSRCGINGKWixdsQ0c20xvcWYCT5GcBABYur9u/VhEKvzhgRtqN+wdOz2L5oGPUGFP7ta125XdzlL18I2ztW33h4qNfcVa8dBcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hVCM9Bd8dtXmxY2Pdmu4BEKJXZLE+qyH8JEtcseR1aw=; b=TA7vBxdOK7eF2nTi1Sy/8ynn8o0NsPuGmFKAZlPiOP5zNlyHNOWjXrEOzoLbkZ9WaSIGBbClQS++flAj4oolNu6wbwcfd3GUklKBG16ycqhqeXp1EJDQNTcvh8tqgi8h11wOhpyH9y7nF5UEhHFbVxWMi0tQdFHmspmh2YA1Tmu1SLVKWLlRvRKBigIGvrYpsdz3d+j8lUGug57kBXMfRFcwoImaA4wEKa9r9XMyiOJrcyqHZBDxJ+oSDn88+zxihjef+sWNeVS8yW3EJGRlKGfaWWmLQ/XBeoia79EfVKBCoQj2IDeqE9eOOtXeBRMvuf1z5M4NwP4cSXPGG8Qzmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hVCM9Bd8dtXmxY2Pdmu4BEKJXZLE+qyH8JEtcseR1aw=; b=m3oXGnvmKpWqJlE+pn8mlFG8iPlrQwvxO9TkVEDsk40y3xU2vXBnA334sRlfG4lwVt2u5Z7KbJ8zorVp5/ttHNUeEitaWdm2EQViR8PpHSyHQk7Lkp4Dm/ek2A14XzB/oPl1D0iArGiPNySRoDfS7/YEdNaVvAkqheGGLC9AW2c= From: Mark Syms To: Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" CC: "xen-devel@lists.xenproject.org" , "qemu-devel@nongnu.org" Subject: [bug] hw/xen/xen-bus.c return type confusion and missing error handling Thread-Topic: [bug] hw/xen/xen-bus.c return type confusion and missing error handling Thread-Index: AQHdRC1AOIgl1NL+C0ast83t01+HHg== Date: Mon, 14 Sep 2026 09:44:20 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS0PR03MB7557:EE_|PH9PR03MB150476:EE_ x-ms-office365-filtering-correlation-id: 66a872f0-f95f-4c71-f319-08df1244c0a8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|23010399003|1800799024|38070700021|11063799006|10067099003|56012099006|5023799004|6133799003|18002099003; x-microsoft-antispam-message-info: 4KGoN9a+/RQKxVBpaOJAcjgwAuHWJVd4vUNraPEwnYefdgEPcER0hxqv0qYQU70CgeePd0LycyMcl9tWsJ0t6peTbm5LjqjZf2gs9eDi/TlcrBFof8RTf0dt06GtXf7z3RudpgIg5RaxFNphw0yfFXrUWPctSDQzC7vXJmaxfCNG6ghinEAacKy/OQRqZVooHqPDInEmEHvFZ+JgdPwLJKLM2s2kYq1q83jFRE6ohvRvTSFSre+SAwx9qmqgurXSZGC4lDlgsoGea60C1fB9bj9F72N1nNjm+VAcuF8Xn4qM/lZ2MmGgGb1/mpdi3U0rzzLRgYMQCZsQxdIL9m2PEGUiUV//dW1NQ7DQ6DKHpKbjWdubU6KtbghzlLeWrggcYQIPRd/bgeRpHLcS4qKfgaggofBa2mcdtDT9TB4BIFCVMk6TnyeZBeixbGi+Ta80Eb77+EKCwxrmh3qrkVpTi8qr40PGk/oOAGBFlFVfdUpPnPVIXOYqXzEZucqAi0rb1Fr2AnPZfJE052pm1n/Zwfu7/Yhuu+t9UlcoumvQDceRL8EooztfFgrsgaBwdCpBDLtKp3jQMREMogpw73Qq7S62BFOjm3OW9O8ifiRY/yQBhhHlFngbwYf1ioDUk8p9UJcUe5ISWJ/i6LuErQk5kxvKSbdEdKS/Y0dOCiq2UCPWZ66Guk7VcyC3yIbggRDxxX/bgXyOXNKcYsWY/HDSY19JqfBuYqY10nb6Ep6+CVw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR03MB7557.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(23010399003)(1800799024)(38070700021)(11063799006)(10067099003)(56012099006)(5023799004)(6133799003)(18002099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?USmMPSwaSurNc63knlBk9ICcwH93nHTSs/r3Sj4gwOINfZvEBp84Z7rwb7?= =?iso-8859-1?Q?zLv5xVH31tHKghN2QODgLqBwgXEIdogjSX2FF3IqKRLj01+iy4Ai+TSPrR?= =?iso-8859-1?Q?bMIL+9/zg2d0Eq48zHkSnoBjjV8lXGj8ARRVamktZ+00QE9yQ8xrMIu8zP?= =?iso-8859-1?Q?c3wVPOJysCp+/tW7tROdILN17AROiEsBTClq/Pex5Zf36nDLUjeaxz/ai0?= =?iso-8859-1?Q?3iVdFFvYnt5NQv7KzuhVawKBg/6DNP53/0Q6fyepuFGPuv2aLgOmWa4oE2?= =?iso-8859-1?Q?mCGdcRrSf2rLJJwcOerVGs1xeuD6w+awj2wAwDBMBc1Oo80UHLMBJrVvTu?= =?iso-8859-1?Q?5BzX6GeEfra+WvNN7Ox06NJu67535essLOrxsGvuO/T4c+mfSRDCZ4waCx?= =?iso-8859-1?Q?KgvfAv64Mj6g+tuEngBqyGRSopy53ok4FilYRgwZFZ0Hlq/5a2a5MkAfSN?= =?iso-8859-1?Q?9zNDVYrA7oZsOYamqzLDyIs7gARdU8U/VYwVKELXAARda566SuYTt5BP2t?= =?iso-8859-1?Q?4MqVp6WO8/Q7AlVi/CG9dSxnpCtJic4C1yUmcy+0t0XKtKljN2gVYXaorD?= =?iso-8859-1?Q?XSb4jo1W5Q6c4tl9vKT722co1fxTLjhf6VopEx6IMAyr5j1E6QtJcPEhWc?= =?iso-8859-1?Q?flk82GsIMbt+k21baCtoJ2hBeKPYCCl8QPDM0WmmDbscT8gVjX2MFJR3l3?= =?iso-8859-1?Q?sUB25tHK9y0m4wWfQWh6UzyLklAnxqFu/MZX/1J/dnKrvIaz4wmDr1MKgj?= =?iso-8859-1?Q?Kwix5kNCW2YtiXGgev0rdPPcT7Z+GuO3DzpNh7NCWsUQlRFnva8Zesl0Hj?= =?iso-8859-1?Q?8AQgHH4meGWFMk3x8bxGhlM6vILFmVG0+7f2TdINE0SDJxmz2UmNY7YMW7?= =?iso-8859-1?Q?luRiDX6xJHhvr/mV0OQAQ1tCsCZ7n6j96byUnuo72hLvuZBRxO3AXfIEHb?= =?iso-8859-1?Q?OTZ35w1zzXaCs2padvUuJYae73lKwO+xlH4BmAMHKeEJ214CIJtZCdTF0y?= =?iso-8859-1?Q?8FNMq+t2n7TUsZSJ6vpbJ9f7+VP7vWETTGqc5Ajd+GkjHWEkMUE5sxGXGt?= =?iso-8859-1?Q?nJct8rq19c5i2+HTMCTZY7Ou1vII7//H1R+gtl+3yVVC9ynLrDioKcxooW?= =?iso-8859-1?Q?H9mBTmtzV6HQaP2yt0UotC/PCnFC1b6eAN0ws/BcqhLP0zUZOkR8j4qq/Q?= =?iso-8859-1?Q?A8GqLEzlJH5ZILn21CF12jr2HHsq2PZahFpUkpoWVmjOnVFuctUfDNXePi?= =?iso-8859-1?Q?b+jbyec2/vc/ObInt9PYQWfaot97BtWf6HiEbQxGqaiFLiinhGcE38eIp9?= =?iso-8859-1?Q?OeZzZQqhFIZbaYchO/mMwgz683oDYfSd37V2iYvYmHxXZvzArmdySMys+H?= =?iso-8859-1?Q?5nORCQseW7gfM9pEzqL7nJjdC6BoVSusCtEYbQl0uKwDkbL4bX95Rp2XyP?= =?iso-8859-1?Q?0JQ3HYSL9QbP1pKuaiusNy4udVlyBoE/9IGF5gV0sjdMxyF5BxpU03jlsB?= =?iso-8859-1?Q?WbX+x++aMA8VrqZUNiRGKCgMS6h+1wzVEMOpFhrsZA5xgxIFO9rXA4a6aG?= =?iso-8859-1?Q?AsMZZBh0MnpnmOTdYOcWuUIkqjU72vRoQXoq3AqAP1hfFP5LXAD4bCEZAi?= =?iso-8859-1?Q?g4Hn7jaPSf6YP5L7jJr3/Yi+9Q3uLo5BjHILYFoYdC3xEl3FuNs/158FpT?= =?iso-8859-1?Q?Xj7d6tnfaU/+rKSmXLhBg0mW9ULaXmhcA+/dx7Qy59en58mC5xK2tjz0Sf?= =?iso-8859-1?Q?/J1+hL5WJ1l5HGacShOMT0FYXUrwb4OzXoF3o5+3kS0itg?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS0PR03MB7557.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66a872f0-f95f-4c71-f319-08df1244c0a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2026 09:44:20.9239 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5SDQWgZsxKHEWIe3WY4/KNzgIuzIOwPAqBapzMaJV8sn8rpGmScrGu8vrmWJDY7n3i+5tQCRtQ5ciiaEYyHxYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH9PR03MB150476 X-purgate-ID: tlsNG-c1860d/1789379069-D594A87B-01C59A73/0/0 X-purgate-type: clean X-purgate-size: 1687 We found a bug in `xen_device_event` in `hw/xen/xen-bus.c`. The call=0A= to `qemu_xen_evtchn_pending` places its return value into an `unsigned=0A= long` variable. The function returns a signed int -=0A= =0A= ```c=0A= static inline int qemu_xen_evtchn_pending(xenevtchn_handle *xc)=0A= ```=0A= =0A= Thus, forcing this into an unsigned type sign extends a negative,=0A= error, return. In particular `-1` which is the error return from=0A= `xen_evtchn_ops->pending` will become `0xFFFFFFFFFFFFFFFF`. To further=0A= exacerbate this there is no handling of an error return from this=0A= call.=0A= =0A= As things stand currently in the mainline this does not directly cause=0A= a problem. But, if for some reason, in our case a buggy development=0A= patch, an error is returned nothing distinguishes the return from a=0A= benign port mismatch. If the event polling keeps reporting ready, the=0A= event loop will re-enter immediately, resulting in a CPU spin.=0A= =0A= Other callers of this function, in `xen_pvdev.c` & `xen-hvm-common.c`=0A= store the return into an `evtchn_port_t` and check if the value does=0A= not match the `local_port` and take appropriate action. Even this is a=0A= bit questionable as `evtchn_port_t` is still unsigned.=0A= =0A= Whilst this was exposed by a bug in some development code we were=0A= working on we can't say whether this could occur for other reasons=0A= such as the ring being filled.=0A= =0A= I'm reporting this as an issue rather than via a patch as whilst we=0A= have a fix in our local build it was generated by our corporate=0A= agentic AI.=0A= =0A= Regards,=0A= =0A= Mark=0A= XenServer Storage Engineering.= From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:45:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:45:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420650.1646906 (Exim 4.92) (envelope-from ) id 1x63Fu-0001Ak-8u; Mon, 14 Sep 2026 09:45:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420650.1646906; Mon, 14 Sep 2026 09:45: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 1x63Fu-0001Ab-44; Mon, 14 Sep 2026 09:45:42 +0000 Received: by outflank-mailman (input) for mailman id 1420650; Mon, 14 Sep 2026 09:45:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63Ft-0001AT-8y for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:45:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x63Fs-008Gtu-Lf for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:45:40 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7c232-2eae-0a2a0a5409dd-0a2a45069f2c-36 for ; Mon, 14 Sep 2026 11:45:40 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7c242-195a-0a2a45060019-d155802ae4dc-3 for ; Mon, 14 Sep 2026 11:45:38 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49e717c9841so10033815e9.0 for ; Mon, 14 Sep 2026 02:45:38 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e62230e72sm174875655e9.4.2026.09.14.02.45.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 02:45: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789379138; x=1789983938; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=yd+U0uxXX2y/ff3PnmrBy5y8mugIAsOf37cpwL0J0hI=; b=Iw2hqwF5CBLLUvxrSjMzeViv5onycjzO1Gwagbt+DdOy5HZIRdjToP04e54A88BFo9 5Lc48U8GQ9LqwGc61DbcoszzYaOrkrZXHsiWKByvf2Jjomb1hCV/EWu0h5tVvzN0Alto ugxE3lc9MUOprLCUi24OYGpmopemlDpYj66TQEowNyLoYeJw08vtaYGYg8AilohdNZHY 7IslrrAiscJNJWziKcH+7i8Fqvz/RSct3iWXJqB508wj8dcbZGVIWXSaxBBnXH+zuUb1 xvyJcZgDzGDsVXpPVNXpWyWon6QvOsjgBbrKBs4JTaQ1MhzTKhjiVrmiQquZfKUE3p0v 1KuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789379138; x=1789983938; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=yd+U0uxXX2y/ff3PnmrBy5y8mugIAsOf37cpwL0J0hI=; b=FnWd5kYXf0kMcPmo+NWD1XVZP2rHqaK9mH4plDaCJUBFP5F8xBW4f/op0+jwd/PhwA PFJX/RywjU08/lUWXZ1yfSRedidHqF+4WEDNn8d0/xT1iwYZIJrhTh6YQvQccBlytBh5 TC3OkVYp8nQ2EVpUfyBwiDej+PtWqOrT+bTawvt9XNXUzgxuDjeKiXacd6K5Z2a3Wthm zWf9dLJMuq14mpxgQ/A6DmgxAnwZyZrTm0TyFI8N3Q3cZ6/O6GWluH11/ZCIgrCF94Tw i9byCDYEQkisZ/7N9XX98z+vqRHu4WAcok01A5tP4J9H2bXIq/wi5bhDe62rTOYyRCVV BZrg== X-Forwarded-Encrypted: i=1; AKwUvBxeiTU+T0d08tGyG7MvJEJmmoK6crZ6A94U8IkqEF4GyJaP1is9WeBYKFuvnaoTi4IaAD8ycSDfVMM=@lists.xenproject.org X-Gm-Message-State: AFuF++lyfHxPys15VQDIRq7yIhDg8hkKjOaYlh6bAzxkAIL3JRZhKR/7 i9polMEi2YFKQzRxw+T83RlaV/ZoACxj0swkF/alre7xXjxaE5eZYXrGwZAqW0n9JA== X-Gm-Gg: AYBFou03Ipa0Ph4uuZDG6ANGNNqWk/KfxFgwhaCsnL4ZY7KdRUlOhw4+hX6rlWBoDt/ 0rHDhdZyDt3k35oLqpykHDCGqw9KHrJbbwW4teFdfsEjsEo2O6AqX8nPFbAEETy8tP8sgUo2w8R fP2bpkoTRjA1QfO/p5OmQFaRd2WbdR7ppXeOqs9q/hWXps6JlAIkFn4X33rgqZOKZLectMkdoh1 jhCACIHy7cSdI8rXVkUNxgS7+VcURWzcNvrpJNuzI0EDijmfLG0ET4Pd6lkwQbOVBoR4zy7wVlP +8/ek9PyYXEm3rHTEnKJEiJaHhxIHLGGl3MwzOncHgrh4BxXVR6LVPSsuPDg0f7slT3C8ozoNz8 WM2mR1WJ34iASqSHzDntWj7MQIzD+1vx9xGQns10oqT4cSGhG6nkLBwIFBX0q6Zuzq/qgWponrj xtHTP+KMJUiNQQc1+pgxTZK6kgSLxIkSTT3FXVVIWVOF6/Fm2Pxs1TJ4khFnXmgzvHaeu01zQSF s5ovBaldFr1 X-Received: by 2002:a05:600c:3586:b0:49d:15b9:2a2a with SMTP id 5b1f17b1804b1-49e7a64ea8fmr24842895e9.10.1789379138262; Mon, 14 Sep 2026 02:45:38 -0700 (PDT) Message-ID: <67395a7d-ccd7-41a3-a925-8679e5d37911@suse.com> Date: Mon, 14 Sep 2026 11:45:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com, xen-devel@lists.xenproject.org, Furkan Caliskan References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> <325f2b44-ea61-45e8-a681-c0bb08d5766a@suse.com> <6fc3aa29-f6b5-43fd-893c-f4cbab0b5c84@suse.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <6fc3aa29-f6b5-43fd-893c-f4cbab0b5c84@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1789379138-FDA0C77B-729DECA9/0/0 X-purgate-type: clean X-purgate-size: 1092 On 14.09.2026 11:33, Jürgen Groß wrote: > On 14.09.26 11:13, Jan Beulich wrote: >> On 14.09.2026 11:10, Juergen Gross wrote: >>> On 26.08.26 06:57, Furkan Caliskan wrote: >>>> @@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>>> static void cf_check >>>> rt_free_udata(const struct scheduler *ops, void *priv) >>>> { >>>> + struct rt_private *prv = rt_priv(ops); >>>> struct rt_unit *svc = priv; >>>> >>>> + if ( svc && !is_idle_unit(svc->unit) ) >>>> + { >>>> + unsigned long flags; >>>> + >>>> + spin_lock_irqsave(&prv->lock, flags); >>>> + rt_admission_test(prv, svc->unit->domain, >>>> + svc->period, svc->budget, 0, 0); >>> >>> This use case clearly shows you are not only testing. :-) >> >> Yet at the same time ignoring possible errors. > > I don't see how this could happen, as new_period and new_budget are both 0 here. Okay, that's simply entirely invisible here. So before freeing the two items are somehow zeroed? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:49:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:49:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420659.1646913 (Exim 4.92) (envelope-from ) id 1x63JU-0001vg-PD; Mon, 14 Sep 2026 09:49:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420659.1646913; Mon, 14 Sep 2026 09:49:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63JU-0001vZ-MC; Mon, 14 Sep 2026 09:49:24 +0000 Received: by outflank-mailman (input) for mailman id 1420659; Mon, 14 Sep 2026 09:49:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63JT-0001vT-RB for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:49:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x63JT-00CoBE-40 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:49:23 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7c31e-8faa-0a2a0a5109dd-0a2a4502a574-14 for ; Mon, 14 Sep 2026 11:49:23 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7c322-6ca4-0a2a45020019-4a7de18d8aa9-3 for ; Mon, 14 Sep 2026 11:49:23 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e6b885ef8so7498195e9.1 for ; Mon, 14 Sep 2026 02:49:22 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb2ecfc3sm24826006f8f.4.2026.09.14.02.49.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 02:49:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789379362; x=1789984162; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=JcnnsXW0NCPzXOWQCXzIot1QQ8b1TbROnhwSccF9ATc=; b=Y1+KVKOOb6nl+FhhJmizpoMQwiiM3F46aZC1RhuhpBIuXECV9fpAIQEFunJuZmh5Qo 1b2dCDgpaM6ExWLhGDboGKZY+WXnAZ3wN8MFCkUXiAYOURrQSf6T+NXbbf8Nu0CHAbG+ 4GOwl2FnBaDdDaaCaViLag8NbymtAF4ZouzRqjIZz858Lnx4fYjbttJq3CjFGLXfKLVU T8SOxgJro0pHHCcS5WbDuzxSqgxLKYOWWZKo+a1otwdgw6Eh0Bljm+mTTRfvfz29/WTX bf/RtcTBajSpwnDuHckZEJxLtdGrATWEra1YDJVAkIYo82CY5grz1h8Awt4ol5gSGDqr uiVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789379362; x=1789984162; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=JcnnsXW0NCPzXOWQCXzIot1QQ8b1TbROnhwSccF9ATc=; b=IJSZVgVU9xHzGQG9B5Gc4gazB54kKU67ke51PGnbMnVgrWlRbiand3wWtWk+vwCXNy EtUFbFgJjrY9Mw+4DzZvT2roAJpuSn+0ISkT9zaXcsNRvad0cWCix+r2VU4plpqWqJBB brS7BydbSnoYPb6FB9ypB+ZrV2oXYMZ/DmnDRtVvwaBGxjj/MlfC0v/IHxbEZJMTvcQw yVRbRSxfn5MfgblNwmjqp10RqF+UAufbIIojXifKt56rad/7MU5m8ghEllLLyNqY7bo2 CWnFeTsfLvRlVaLUMVK+v5NBe2ZV0ylWBragRnJEGoPZw768un2rEXSExR6qHZ3OYYi+ VbEA== X-Forwarded-Encrypted: i=1; AKwUvBy+/arWzBIeYqWE6E+Xc+rVjjQSKKamlegGx9ZUjDzqfqSnKynqtTQu7dn58IxZNmccn/0KEq6ljzQ=@lists.xenproject.org X-Gm-Message-State: AFuF++mVyuw6gObgsHfCqleqCKlDI4KQAdrdTxaTS6jzxtIzWnkvhFGS y+ejCliFApF8MrAJyxq6oNGq9ov8qkiBP8sLuw9Vevvwi1eDikbr3g7fVdLREqoc/A== X-Gm-Gg: AYBFou18XDxGcYjWQYHOvNahyxjO7rl1VahDrwxPEPETQkm8cijzeZmRSzE/DxnP0jl qhxZP177EHcXH/WXI4h7YQ17Qtk53KnUKN8IbHjcFenHDERK7PVIX07dB7YltWqqfWGEfZF2mvL mLKBOLZLmW5PcCbsqbFmdD7tS8j1jJB/YEGKbEkwXA8AZC9ZUvlyoXfaWvYpInQrhJwsZR5VhgG kHjhEcwTGuyvq9ogESdIgqrmVU+sjt1mVRFRkBM7OemosT97rzbvvVDroPaWGhmkibE1zHASNx3 R3Un6v0x3QslipEKNQbXK381PPp/yslgL/vDVxxRCWiJSuQt0gMmQVJ94VzjpkXv2/HLfZqPuOO ov4eXnohqpikEMmjtkh5qxfFJp8/85IVya0Nqf/P0SKNwJsVZiaA5fdbcIffjI6/3RwMxqxKmMe YWM7+99TwIjob4aBAQpHmFIOwRulKCCw/5dfI8DXcaLDTECZ1K3a/Z7O0Tt4mmmHnhAX5uBA== X-Received: by 2002:a05:600c:548b:b0:498:952:e276 with SMTP id 5b1f17b1804b1-49e7a6625aamr19728365e9.8.1789379362532; Mon, 14 Sep 2026 02:49:22 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 11:49:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/3] x86/viridian: Workaround Hyper-V GP fault writing to MSR To: Ross Lagerwall Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260911091244.1165516-1-ross.lagerwall@citrix.com> <20260911091244.1165516-2-ross.lagerwall@citrix.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <20260911091244.1165516-2-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789379363-F02992AC-82C126BF/0/0 X-purgate-type: clean X-purgate-size: 576 On 11.09.2026 11:12, Ross Lagerwall wrote: > The Viridian spec requires the vector to be >= 0x10 when writing to the > SINTx MSR, otherwise it should #GP fault. > The spec-defined initial value is 0x10000, i.e. the vector is 0. On > startup, for some reason Windows 11 Hyper-V tries to set the MSR to > the spec-defined initial value and since the vector is 0, it GP faults. > Fix this by doing as Hyper-V does and only fault if the SINT is > unmasked. > > Signed-off-by: Ross Lagerwall Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 14 09:59:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 09:59:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420671.1646923 (Exim 4.92) (envelope-from ) id 1x63Sl-0003s9-JK; Mon, 14 Sep 2026 09:58:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420671.1646923; Mon, 14 Sep 2026 09:58:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63Sl-0003s2-G4; Mon, 14 Sep 2026 09:58:59 +0000 Received: by outflank-mailman (input) for mailman id 1420671; Mon, 14 Sep 2026 09:58:58 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63Sj-0003rw-V9 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 09:58:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x63Sj-000n8l-Bk for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:58:57 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7c550-8faa-0a2a0a5109dd-0a2a4501e800-18 for ; Mon, 14 Sep 2026 11:58:57 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7c561-5984-0a2a45010019-4a7de14cde35-3 for ; Mon, 14 Sep 2026 11:58:57 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-484366874b0so983819f8f.2 for ; Mon, 14 Sep 2026 02:58:57 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb2ed0fbsm26143727f8f.3.2026.09.14.02.58.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 02:58:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789379937; x=1789984737; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7nj2WKhRtq0LWRb/70aoHdYoAG7yMtsmTUZJuj68xb8=; b=D3vF8HNVzDFp+ukp4xwAzTFnLnEB0C2e+TqA34xL5bCSEu6XEWLL3On3fw9PpflL8K E1ex8Tmf+TfzVBSs0vWM2pXEZ3pmvgo0x1fL9dWbbOWuhWlgPZSV2eBIdHMhh7it0aSH EjExhJf2LexAAXUM7yGcW6rPH6JYEufbXREPRyQS560nX6Tbpq7b+dDhkoua2sADmyfZ 6FIjytWbH4PPXDGfljNnmwTMyjL9CtbsofGrfzxpgrnanaI1lo56/3dOCiFRF2rKF+vc /y1C22AKQjo29hZHYLnb9pd6ITvsuLdtFeLeoK6wAq9i700+sEnooKSuz0XxvPFKxR+Z KWuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789379937; x=1789984737; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=7nj2WKhRtq0LWRb/70aoHdYoAG7yMtsmTUZJuj68xb8=; b=bKf5GObtLxutgdYwuU6aeC680hdAUKe/AtxsR7OHi3BOOhD9kZTVxLsGZIyek6y4I9 iVJQ0FNeGAhn+nBjMrqbDYPzeG1H8s+Qe5w+mahomozBbEPOiJZuEmTY4e6loBgihspd 19qH+r3g5Jf27z2F+9sILqM2JDHJukNrylvZM1kS55LJfFwTBcpYuo2t93aidXbMzuEr kjuyxeonoHpMnw3JkFwMZw6nuvl/gb/3HL4nCB3WQezCzS85ktQQxD/bsUOkQLPoq+4u TAQTqn8xp+JcFtR49xiprlLMfGtGik3DNsA9oDuPfZFY2r29mz/Fk85gBAlr6dR7YAz7 /mpA== X-Forwarded-Encrypted: i=1; AKwUvBx6fAjrVa+ilYYpTt3b/VaJSw9E5VzHbZ4ZuXLQurCTOXk2CF61pr0mjqEZeqrnR4dV4jPd0I5eNeE=@lists.xenproject.org X-Gm-Message-State: AFuF++k1fn1CWP99JJIXPZkfJmC0IcYFesy8oC0V750Ve0N3nkqlZvfP NHN2dRMnKe8pu03JKXC8h1pW/OQ6p74377YP6bny5cuD3Q/vQE5RhJCJxzqm3TJNhSdF3dpYGOG be64= X-Gm-Gg: AYBFou0FozU0mwTjIQVEnQ8dZmwO7KY23B1wPFQnhFLf1i5C1nz2uGQFKJm1KZ5/ZhU oOnMWuGPC9PFp0N/4HtipSgYXiN9Z/8S7U3p7b6BlmEPAjQZq0G5uqI1IRbptwZRmfthYeqO4OT FKCodxWlwIiy2L91OnzSBcfiU82LCDWkkIeTd9XMBPKxM0NebfrZZAsPI6A8rIsRZPB/0CaEGNf 5qZK75HU+zBVRbtttNbNvsQFwI72Ggr0OaRQs/3aTLzuEPJnPUoFoifiwOej1vqPL4L2AceU9cD RZRlK3w1CwhQm7bFlr7EcsZzwOIqcFONGMslMGLDe3pqzEnOR5V4bwh/AUUkdbDx+lJj/xuTUuT vpawMzXRhqVjEgY4v1kA1bO1tGrDv894ONPNXcKID1TAYg2yUAK/M+LiflIsFbBm308bbrbft4G sKoDJYWm74aEMIjjxKrJHNq8H5PHh7ba9o77zQFCQFAk6YeT16zuQu4EuC4aUus4zsqJTSjCH1e jfmy1DOTZET X-Received: by 2002:a05:6000:4010:b0:487:39a:6444 with SMTP id ffacd0b85a97d-487039a64eamr1434627f8f.2.1789379936705; Mon, 14 Sep 2026 02:58:56 -0700 (PDT) Message-ID: <547d74b4-37c9-40d2-a37e-5cf31637a2c2@suse.com> Date: Mon, 14 Sep 2026 11:58:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/3] x86/viridian: Implement synthetic timer direct mode To: Ross Lagerwall Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260911091244.1165516-1-ross.lagerwall@citrix.com> <20260911091244.1165516-3-ross.lagerwall@citrix.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <20260911091244.1165516-3-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1789379937-BCB45757-F43FAA0D/0/0 X-purgate-type: clean X-purgate-size: 717 On 11.09.2026 11:12, Ross Lagerwall wrote: > In direct mode, the timer asserts an interrupt on expiration rather than > using a SynIC message. It is useful to implement this since Windows 11's > Hyper-V can only use synthetic timers in direct mode. > > To avoid changing behaviour in existing guests, add a new Viridian flag, > stimer_direct, to control whether this feature is visible and usable. > > At the same time, check that the reserved bits are zero and the APIC > vector is only set when using direct mode since this is enforced by > Hyper-V (although not mentioned in the spec). > > Signed-off-by: Ross Lagerwall Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 14 10:09:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 10:09:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420682.1646933 (Exim 4.92) (envelope-from ) id 1x63d0-0005uV-FT; Mon, 14 Sep 2026 10:09:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420682.1646933; Mon, 14 Sep 2026 10:09:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63d0-0005uO-B1; Mon, 14 Sep 2026 10:09:34 +0000 Received: by outflank-mailman (input) for mailman id 1420682; Mon, 14 Sep 2026 10:09:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63cz-0005uI-3h for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 10:09:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x63cy-00FJ5r-93 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:09:32 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7c7d3-2eae-0a2a0a5409dd-0a2a4503aec8-36 for ; Mon, 14 Sep 2026 12:09:32 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7c7db-fae8-0a2a45030019-d155dd32f03b-3 for ; Mon, 14 Sep 2026 12:09:32 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-4858303de5dso3185856f8f.2 for ; Mon, 14 Sep 2026 03:09:32 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb33e020sm27075947f8f.18.2026.09.14.03.09.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 03:09:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789380571; x=1789985371; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EL1LH8FSvrtGc6aSbK2aArEjtvYc/uo76nQ7Y2KbdGw=; b=G+/KBflHkkk+vtin5oV3cl76CXqcrjIBxJXSBBJLUKIOz9PJ1OrezBDiGBHae+lrHA Vk0fN0WxsPSJZdVZZtnpiqh6Y5YBfgjkErZ9Y+B6h/+bvAZaQpJqZRi9TolibWauJwu6 nsRng5GbzdDGO/gT7FeqWACD4yGa7OzmCjpudKmYG3BSPAdWilHg8fyUfzry8NPIIY7H DEdY3kdDEgtOtW5zyoNgEo3UEBVaITo6qyOLde/7qsimD+XgInVExH4ZWcNCVJ6NqCyy 3puzWEt5/XjTfCSgNA6eE8qqF7LxckkNDBk4B0djObaw+0bHSMts0TCGo7mBjQiyV6bB az9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789380571; x=1789985371; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=EL1LH8FSvrtGc6aSbK2aArEjtvYc/uo76nQ7Y2KbdGw=; b=cv64B6LlczMIXfI2fEPKXYxbDK2z1RRCSE5EEnrwGvsxGw7wFo3zLFZ9tXiDV4pCbF NhmDkzve2+P+yBemQ08N/84PPIvnxOLKKsOFhbjhagYXuHY9168litu226v+3BJFSGPS zfKcptKfS6oAoJhd5EGmPSSTGZfMH9PcUYyMk9xL4giQH4tRLD2RquO1X4bjTyrfj/14 tWKEvtTe/PhfowUSiVtM4IJI1sg4L1781itROE9jJ+5GSd0Hevs9dOsWgbj+h0h1les8 cEZ17lk2Q0NKqsYz6G4nFTED9xdxOLnZbk7iyHeeOxq50MzcN4/L++hEquPwawqoMZjP 8OPA== X-Forwarded-Encrypted: i=1; AKwUvBwQXizyGDSS7F3c5rLAuCXFnSX7fpTYzeooZkxNi5f3Nm543iMZ8t14Ssdbl3lOIAEdmXnkLUU8bjc=@lists.xenproject.org X-Gm-Message-State: AFuF++m5NFO0tNl9BIdex9kqwXbHEs0JsMO07FV2hYjyFFK7vfTZur5o W+GW98TTburacPSzak6uUbeqi7EH4DI113B0sd3RWWiKRoTaMRee+y+VKmT8Thhv7Q== X-Gm-Gg: AYBFou2AC8X7huSL9XA+HYLRnAWGzXR/1mr7+fB6x5dWsSE7rMsBcHFViLS90E8DZlY fO145zpoUlI7QTNAom1H2ZssPPW0+50Noqyr7rl2qfrs+1cniiYrsimll8eU+lFiucVnbSOmhwm kZ/EJdi7jKLx3nbg24LkztjoG/CgV6GsM4nSSOJMtYCChnoWjYQBN2LDdYVZ6ui7yLVt9jt68Ye N3j7yvehRaa18hMvQQsmjk2Xu7Oy6iqPHWOis0jInKn2zWMihQ0+I9WsTwpZd4abf5MmHTU8o+P 1P7oOqAPCvLFrVsAcLtk9p0PMOPyZxdJ3FBf3zEwTfXBfaos0a9gLyliQcp6JH2EkKfo2N0BQsQ 71qdBVGfeVAfKpgLUgn/qjjxuZukEZb/9UR6Z/Y3fscfoAthuRRXSWVX0vuASvmN64dkY4qSDgl 7N3Xj+St7R6L85b+t9GkolCaSbmhq6Bm6wiH65ng+FPglX9e/LaZpvDn5nySJN+XaSuC6ZimeKQ rAoe7qmFxs5 X-Received: by 2002:a05:6000:983:b0:486:f46d:a13e with SMTP id ffacd0b85a97d-48702a2480cmr1886444f8f.0.1789380571539; Mon, 14 Sep 2026 03:09:31 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 12:09:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/svm: Intercept CR0 writes selectively To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260911095121.1177503-1-ross.lagerwall@citrix.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <20260911095121.1177503-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789380572-6EACC4E9-B7893CA6/0/0 X-purgate-type: clean X-purgate-size: 2202 On 11.09.2026 11:51, Ross Lagerwall wrote: > Since 3356d685dbda ("x86/svm: Remove lazy FPU support"), Xen does not > need to track when the TS or MP bits change so opt to intercept CR0 > writes selectively. Aside from potentially reducing a few VMEXITs, this > fixes a nested virt bug where L1 intercepts CR0_SEL_WRITE and L0 > intercepts CR0_WRITE. The hardware prioritizes CR0_WRITE and so L1 never > sees any CR0 writes. > > Since CR0 TS/MP bits may now change behind Xen's back, sync CR0 on > VMEXIT so that the emulator sees the correct values. > > Shadow mode continues to use the full CR0_WRITE intercept since with > Shadow the CR0 in the VMCB is not the same as the value Xen tracks on > behalf of the guest and allowing the guest to change one of them > directly would be fragile. > > Signed-off-by: Ross Lagerwall Reviewed-by: Jan Beulich Independently, ... > @@ -2519,7 +2520,10 @@ void asmlinkage svm_vmexit_handler(void) > > v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb); > if ( paging_mode_hap(v->domain) ) > + { > + v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb); > v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb); > + } ... we really want to change to !paging_mode_shadow() here and ... > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -154,6 +154,13 @@ static int construct_vmcb(struct vcpu *v) > vmcb->_cr_intercepts &= > ~(CR_INTERCEPT_CR3_READ|CR_INTERCEPT_CR3_WRITE); > > + /* > + * Xen is not interested in changes to the MP and TS bits so use > + * CR0_SEL_WRITE to avoid unnecessary intercepts. > + */ > + vmcb->_cr_intercepts &= ~CR_INTERCEPT_CR0_WRITE; > + vmcb->_general1_intercepts |= GENERAL1_INTERCEPT_CR0_SEL_WRITE; > + > /* > * No point in intercepting INVLPG if we don't have shadow pagetables > * that need to be fixed up. ... here, as that's compile-time constant when SHADOW_PAGING=n, while paging_mode_hap() is compile-time constant only when HVM=n (i.e. useless here). Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 10:31:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 10:31:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420707.1646949 (Exim 4.92) (envelope-from ) id 1x63xq-00028m-3y; Mon, 14 Sep 2026 10:31:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420707.1646949; Mon, 14 Sep 2026 10:31:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63xq-00028f-0j; Mon, 14 Sep 2026 10:31:06 +0000 Received: by outflank-mailman (input) for mailman id 1420707; Mon, 14 Sep 2026 10:31:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x63xo-00028Z-8j for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 10:31:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x63xn-003Gyw-Hg for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:31:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7ccdf-8faa-0a2a0a5109dd-0a2a450492cc-6 for ; Mon, 14 Sep 2026 12:30:58 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7cce2-b57f-0a2a45040019-4a7de18d9be2-3 for ; Mon, 14 Sep 2026 12:30:58 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7355e411so12077895e9.1 for ; Mon, 14 Sep 2026 03:30:58 -0700 (PDT) Received: from [192.168.1.109] ([85.107.101.239]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49d26c2a419sm433217575e9.7.2026.09.14.03.30.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 03:30:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789381858; x=1789986658; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ulI5AdkQmmvQ3Lyda75s2UBWI7+cwgUaCuMfCOhhjTk=; b=EWNrkJugIfoGbLlhtll95yA+EWr2vorlmil8TItS/nb6bvczpSUfDx4GKmoyFofwG9 5mX2IwNLMEs0vwnbPiDE69/dM34m2ipvxiflcckbLy5Noz5D4/9IiGgvwwycP68XiXHm UdJx0MwCuGejvMbGoqlLX1BYPvuUURh3v1pTPXGDkU+RRudRSvXPYgZWXgxwMKYzuQp5 4J3zVTuuK53UjrFo9hNc1Uca1QMuKbT2MzDga7G0RD6gaFlpI0CWB01B1cT59YD2sIHP hj2KXdB0FF2Eqan38SiN8j3T39nNPRnTZGSFgXD2l5Fz0lyHcu1mij+/Nefaz93XEiaC VCVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789381858; x=1789986658; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=ulI5AdkQmmvQ3Lyda75s2UBWI7+cwgUaCuMfCOhhjTk=; b=muTwiUMIs6yT5PbC6B/d5AAfEaTx25p8n813EGvl3ArXSCJrt4eHsBRh7LGZ5eeTNW Vpq5VJmp52ezP8qxd0Ljbaf5fIDodENwZEd80mfJFucDe1wY1PdVQ0zIz3geUPbchOZB bylUopLfyYojYqbkQFtRLrs+8Jq8b3g/9DhS93E3Zd6UxUZLslTt0IOT+XK6BXf4yk0N bKwZ2uu50PE3xxtROFipamj+21+9ndTEZ7lo+fgMrotZUF13LAyg5sopZGUwNtUquPmE GM1yUErQ8JhCLpeg1MwkRxJxRQAFFpyND0Ee6Co4YWPH/OkVd69BCBUmlZB7GNLxOBRP Ue2g== X-Forwarded-Encrypted: i=1; AKwUvBxtgGTXqY16xoZXtxPbMBaPZ1wlVEOQsP71zz3sxIhrFma0O/MqYopXbq8BoC2oed8wh7GxwcOlHEo=@lists.xenproject.org X-Gm-Message-State: AFuF++n8JNkLjfaezbSkhKIYL9WdCg/GoSfh06bjI1K5FWBgYDULi6vD NPZDinfmWwRdTyJx0cI12owHNibuFAvmh9smsdkA8nPrjNThTqtSKpDm X-Gm-Gg: AYBFou1zG83urNW+noq2AkkmotRQgX88H4J6HAw9NTuoZixyUR3g+9lmFcpKscIVtd5 TQzftH6IXoZlon0GePhsy4feTbwU4DJFp9SoHGDCaL153kx7308zRP9otdp5SHq72taWXXW+YGk LvQInNvj26e5ANGcRn7YrZLcsoGwiIA3kY5jL4uhq0qarAvbiHb+WNosByVK1b6HWK4wL4hCimj aintHrX36XUKQG5NNVHC26okIxocEMU1oVPuhUWhqWZ5oI9Bvm5l+88B6XnPawIuDcpDUEk8OIU 6opo58AF/zOUfPdO10CYq2e0NrqH1Rah3eF0KaCaR8Dcd7kOQ2MBDehfmi4DpqbY7efuIkVNwnj s57JDrPBG+4bKFO17TUycFbjA2y0007EH5Tt6U7VpTRyg/8wzzQGoHZz64MnPemBu13ynX+dgET zH140rW/nC1rzj0IEy93rpKvVeZYMMqhOgBEhK71ZrDd74jC4XnKb1DoDss4cPxOtdbY/Y2hS1V 7j3XGE= X-Received: by 2002:a05:600c:8b6b:b0:49c:d52e:d0ea with SMTP id 5b1f17b1804b1-49e7a64acc2mr50291725e9.4.1789381857547; Mon, 14 Sep 2026 03:30:57 -0700 (PDT) Message-ID: <384de41c-213b-4aed-af97-e0f4596b3f39@gmail.com> Date: Mon, 14 Sep 2026 13:30:51 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Juergen Gross , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1789381858-C1AD0B50-4387E8A2/0/0 X-purgate-type: clean X-purgate-size: 8613 On 9/14/26 12:10, Juergen Gross wrote: > On 26.08.26 06:57, Furkan Caliskan wrote: >> RTDS has no admission control: nothing stops the sum of all admitted >> units' (budget/period) reservations in a cpupool from exceeding >> what its pCPUs can actually provide. Once that happens, none of the >> EDF deadline guarantees this scheduler is built around still hold >> for the units sharing that pool. >> >> Introduce admission control to prevent this: reject a reservation >> whenever admitting it would push a cpupool's units over its capacity. >> Track a running utilization total per cpupool, and enforce it in >> rt_alloc_udata()/rt_free_udata(), the paired lifecycle hooks for a >> unit's creation and destruction. This catches the default >> period/budget every new unit gets. >> >> Utilization is represented as a fixed-point value: budget is >> left shifted by RTDS_UTIL_SHIFT (20 bits) and divided by period. >> A plain "(budget << RTDS_UTIL_SHIFT) / period" risks overflowing >> the multiply for large enough budgets. Rather than widen the >> arithmetic to tolerate any input, the input itself is bounded: >> rt_validate_params() rejects any budget above RTDS_MAX_BUDGET, >> chosen as the largest value that can be left-shifted by >> RTDS_UTIL_SHIFT without overflowing 64 bits, so the shift in >> rt_unit_utilization() can never overflow. >> >> A cpupool's capacity rt_utilization_cap() scales with the number of >> scheduling resources in it. It is calculated as: >> (number of sched_resources * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100), >> where RTDS_UTIL_CAP_PCT controls how much of that capacity can >> actually be reserved; at 100% (its current value), all of it can be. >> >> Signed-off-by: Furkan Caliskan >> --- >>   xen/common/sched/rt.c | 105 +++++++++++++++++++++++++++++++++++++++++- >>   1 file changed, 104 insertions(+), 1 deletion(-) >> >> diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c >> index 0e9f04ea72..9126320801 100644 >> --- a/xen/common/sched/rt.c >> +++ b/xen/common/sched/rt.c >> @@ -114,6 +114,24 @@ >>    */ >>   #define RTDS_MAX_PRIORITY_LEVEL (~0U) >>   +/* >> + * Fixed-point scale for utilization (budget/period) >> + */ >> +#define RTDS_UTIL_SHIFT     20 >> +#define RTDS_UTIL_SCALE     (1ULL << RTDS_UTIL_SHIFT) >> + >> +/* >> + * Largest budget safe to left-shift by RTDS_UTIL_SHIFT without >> + * overflowing 64 bits. Enforced in rt_validate_params(). >> + */ >> +#define RTDS_MAX_BUDGET_BITS  (64 - RTDS_UTIL_SHIFT) >> +#define RTDS_MAX_BUDGET       ((1ULL << RTDS_MAX_BUDGET_BITS) - 1) >> + >> +/* >> + * % of a cpupool's sched_resource capacity admitted units may sum up to. >> + */ >> +#define RTDS_UTIL_CAP_PCT   100 >> + >>   /* >>    * UPDATE_LIMIT_SHIFT: a constant used in rt_update_deadline(). When finding >>    * the next deadline, performing addition could be faster if the difference >> @@ -195,6 +213,9 @@ struct rt_private { >>       struct list_head replq;     /* ordered list of units that need replenishment */ >>         cpumask_t tickled;          /* cpus been tickled */ >> + >> +    /* Sum of admitted units' (budget/period), scaled by RTDS_UTIL_SCALE */ >> +    uint64_t utilization; >>   }; >>     /* >> @@ -635,6 +656,54 @@ replq_reinsert(const struct scheduler *ops, struct rt_unit *svc) >>           set_timer(&rt_priv(ops)->repl_timer, rearm_svc->cur_deadline); >>   } >>   +/* >> + * budget << RTDS_UTIL_SHIFT can't overflow: rt_validate_params() >> + * caps budget at RTDS_MAX_BUDGET. period == 0 means "no >> + * reservation" (a unit being removed), not an error. >> + */ >> +static uint64_t >> +rt_unit_utilization(s_time_t period, s_time_t budget) >> +{ >> +    if ( period <= 0 ) >> +        return 0; >> + >> +    return ((uint64_t)budget << RTDS_UTIL_SHIFT) / (uint64_t)period; >> +} >> + >> +/* >> + * Utilization capacity of the cpupool domain d resides in. >> + */ >> +static uint64_t >> +rt_utilization_cap(const struct domain *d) >> +{ >> +    unsigned int cpus = cpumask_weight(cpupool_domain_master_cpumask(d)); >> + >> +    return (uint64_t)cpus * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100; >> +} >> + >> +/* >> + * Replaces a unit's reservation and updates prv->utilization >> + * to match. Growth that would push utilization over the >> + * cpupool's cap is refused. Removing a unit or shrinking >> + * a unit's reservation always succeed. >> + */ >> +static int >> +rt_admission_test(struct rt_private *prv, const struct domain *d, >> +           s_time_t old_period, s_time_t old_budget, >> +           s_time_t new_period, s_time_t new_budget) > > I think the function name isn't appropriate. The function doesn't test only, it > is setting the utilization, too. > > What about rt_try_set_utilization() instead? And make the return type bool > (true on success). > Okay, I'll change the name in v2. And the return type too. >> +{ >> +    uint64_t old_util = rt_unit_utilization(old_period, old_budget); >> +    uint64_t new_util = rt_unit_utilization(new_period, new_budget); >> +    uint64_t total    = prv->utilization - old_util + new_util; >> + >> +    if ( new_util > old_util && total > rt_utilization_cap(d) ) >> +        return -EINVAL; >> + >> +    prv->utilization = total; >> + >> +    return 0; >> +} >> + >>   /* >>    * Pick a valid resource for the unit vc >>    * Valid resource of an unit is intesection of unit's affinity >> @@ -864,6 +933,7 @@ rt_free_domdata(const struct scheduler *ops, void *data) >>   static void * cf_check >>   rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>   { >> +    struct rt_private *prv = rt_priv(ops); >>       struct rt_unit *svc; >>         /* Allocate per-UNIT info */ >> @@ -881,9 +951,30 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>       __set_bit(__RTDS_extratime, &svc->flags); >>       svc->priority_level = 0; >>       svc->period = RTDS_DEFAULT_PERIOD; >> + >>       if ( !is_idle_unit(unit) ) >> +    { >> +        unsigned long flags; >> +        int rc; >> + >>           svc->budget = RTDS_DEFAULT_BUDGET; >>   +        spin_lock_irqsave(&prv->lock, flags); >> +        rc = rt_admission_test(prv, unit->domain, 0, 0, >> +                                svc->period, svc->budget); >> +        spin_unlock_irqrestore(&prv->lock, flags); >> + >> +        if ( rc ) >> +        { >> +            printk(XENLOG_WARNING >> +                   "RTDS: ADMISSION CONTROL: refusing unit %u of d%d," >> +                   " would exceed utilization capacity of the cpupool\n", >> +                   unit->unit_id, unit->domain->domain_id); >> +            xfree(svc); >> +            return NULL; >> +        } >> +    } >> + >>       SCHED_STAT_CRANK(unit_alloc); >>         return svc; >> @@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>   static void cf_check >>   rt_free_udata(const struct scheduler *ops, void *priv) >>   { >> +    struct rt_private *prv = rt_priv(ops); >>       struct rt_unit *svc = priv; >>   +    if ( svc && !is_idle_unit(svc->unit) ) >> +    { >> +        unsigned long flags; >> + >> +        spin_lock_irqsave(&prv->lock, flags); >> +        rt_admission_test(prv, svc->unit->domain, >> +                           svc->period, svc->budget, 0, 0); > > This use case clearly shows you are not only testing. :-) > >> +        spin_unlock_irqrestore(&prv->lock, flags); >> +    } >> + >>       xfree(svc); >>   } >>   @@ -1389,7 +1491,8 @@ rt_validate_params(const struct xen_domctl_sched_rtds *rtds, >>       s_time_t b = MICROSECS(rtds->budget); >>         if ( p < RTDS_MIN_PERIOD || p > RTDS_MAX_PERIOD || >> -         b < RTDS_MIN_BUDGET || b > p ) >> +         b < RTDS_MIN_BUDGET || b > p || >> +         b > (s_time_t)RTDS_MAX_BUDGET ) >>           return -EINVAL; >>         *period = p; > > > Juergen > Thanks, Furkan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 10:35:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 10:35:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420718.1646958 (Exim 4.92) (envelope-from ) id 1x641a-0002vm-Lb; Mon, 14 Sep 2026 10:34:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420718.1646958; Mon, 14 Sep 2026 10:34:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x641a-0002vf-In; Mon, 14 Sep 2026 10:34:58 +0000 Received: by outflank-mailman (input) for mailman id 1420718; Mon, 14 Sep 2026 10:34:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x641a-0002vZ-2d for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 10:34:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x641Z-00Cy2y-FH for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:34:57 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7cdc6-bab6-0a2a0a5309dd-0a2a4506b762-22 for ; Mon, 14 Sep 2026 12:34:57 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7cdd1-195a-0a2a45060019-d155dd2fa871-3 for ; Mon, 14 Sep 2026 12:34:57 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-48431648f33so1782467f8f.0 for ; Mon, 14 Sep 2026 03:34:57 -0700 (PDT) Received: from [192.168.1.109] ([85.107.101.239]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb35c071sm25984659f8f.33.2026.09.14.03.34.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 03:34:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789382097; x=1789986897; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=jawtF7j3qPP2d7G5bvrt5AsqmK13Zt06E+7LKY6ouMQ=; b=J3DuhVZk6SgwBkVXVGGFCQyDEMWTjndBPMLbVcu1M0Khnb+WApheRrsvP0cTLJr/l/ 4BgaexNxNhPJJmbveqKBIC4fnVkptyA1FL/xtmkVna4Fsx+Q25eSIb7C8x7A+Og4NebR 3uL5aQVMoiKLjp43+S+5bkL2S24CrGqF5YeG431XZfCPKibQ5ptxPcLOV6h9rIbkOgc+ tS3Jw6GtBMI4vf6tdIdKXZq/jgSxdpjCnoggYZzSBd+cym08VIK/AnnhD2Vm3GDmZLyU ocGY9Q5fXJimsk9UjhPerww1eZrG3Wwi6lLtn2JWRPu3/IBQq4E3/kAlm+6qgKmEB7eh J3+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789382097; x=1789986897; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=jawtF7j3qPP2d7G5bvrt5AsqmK13Zt06E+7LKY6ouMQ=; b=T7w9Hg1HaFcYB9SnJGU2lqlSf5cVcJBABS+dw4g89hYdg6v4XtoLFMRQewZBAIXhCL 1DlGdFR0u4NueUUC2y22vYHY/fFiinI/qu4c29HaXnBsrDu4/qQ5cMIrlXjUWrlIrfW2 3tGt89pARXmqWJM2MjlInObiDp04uIVmUKI6hhvEOTc8+1yHDNTZMWF21St+Ykk9qGQo y9ouzIjwbfb+YGsYz5ESFlI3rNA1nKaxUxAuscT3wHU7jqrBohU7Ys1ehJPlcllLBSby yEYwiBrbxfcnbLb1Sx8b87gu0Ju9BoWY7pGZZFRTTuToHO39vN+4fyQsMCCt6B2XUFFA EHxw== X-Forwarded-Encrypted: i=1; AKwUvBySAQL/iJM7AuF+Nlw0o7ej+ci6U/Jtt1PuE1d9zaI2L/pnovMZb1cJUZ/MWOhFvw2BdktBL6Guv5I=@lists.xenproject.org X-Gm-Message-State: AFuF++lE2LLzFDBedu0jCF9ZaYZn+Z10NA0WCI5/b3jJdsXibn0Eb0ng gZ22fQjHmSFcn09q+WgsTAgxxvN7psIx3WRuTgSrNM6OdbfqCE37HuYg X-Gm-Gg: AYBFou15RqqeerT+6dr2u1ZM1tXW6Q954jX/ZkpjApa6bnMzRPcGr/mj4mNsWxA/T84 h/KfR/mKMcvKKhZd59Vj9jaCIjSYKMt7AY6lpb0vcKg18MkGvnLx9qLpNMqOK7I0RmLJ4IHt2/B ofY7hXPbp0z0iu1YRaRFnQCTpVn02fZTXS2pGxZwhGBI/8i5UDFPo8FwvW+FAnFw+l8uEp4VIIg KqpYUtTQbZt2AuxGZ4rOhCAVg9wFmeIVCah3KvNhJ4ThOdlbD6uSkrA6sWlnTb4ApFtKBIAXDyr Dp2jE2ShD9jyYVZHlL1PZW7DTB/RgrB8uwO5b0QiIx1jzNzjfvuddvaXxJojFzqFufp3XWKMx8U BQHjPxDgiZFtyz/q8rvI/q2dez3nkLu5FoEakmmF/zibhefzvwTWW768mCh2KHNMSUNexIqUryY tWeHAR3UcV8KYxyHQMoYqVyWOEPizMPipj9gGqsMYJlN39qCiU22BX0a+CDV2ysxu6u7bP/OSUU 7pAxe9U X-Received: by 2002:a05:600d:848e:20b0:49d:28fc:d6a0 with SMTP id 5b1f17b1804b1-49e7607d36cmr47216025e9.18.1789382096627; Mon, 14 Sep 2026 03:34:56 -0700 (PDT) Message-ID: <85e6a89a-edc4-4d2e-9d75-5933af44f7fc@gmail.com> Date: Mon, 14 Sep 2026 13:34:50 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Jan Beulich , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com, xen-devel@lists.xenproject.org References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> <325f2b44-ea61-45e8-a681-c0bb08d5766a@suse.com> <6fc3aa29-f6b5-43fd-893c-f4cbab0b5c84@suse.com> <67395a7d-ccd7-41a3-a925-8679e5d37911@suse.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <67395a7d-ccd7-41a3-a925-8679e5d37911@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1789382097-F70C777B-48F2B81E/0/0 X-purgate-type: clean X-purgate-size: 1227 On 9/14/26 12:45, Jan Beulich wrote: > On 14.09.2026 11:33, Jürgen Groß wrote: >> On 14.09.26 11:13, Jan Beulich wrote: >>> On 14.09.2026 11:10, Juergen Gross wrote: >>>> On 26.08.26 06:57, Furkan Caliskan wrote: >>>>> @@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>>>> static void cf_check >>>>> rt_free_udata(const struct scheduler *ops, void *priv) >>>>> { >>>>> + struct rt_private *prv = rt_priv(ops); >>>>> struct rt_unit *svc = priv; >>>>> >>>>> + if ( svc && !is_idle_unit(svc->unit) ) >>>>> + { >>>>> + unsigned long flags; >>>>> + >>>>> + spin_lock_irqsave(&prv->lock, flags); >>>>> + rt_admission_test(prv, svc->unit->domain, >>>>> + svc->period, svc->budget, 0, 0); >>>> >>>> This use case clearly shows you are not only testing. :-) >>> >>> Yet at the same time ignoring possible errors. >> >> I don't see how this could happen, as new_period and new_budget are both 0 here. > > Okay, that's simply entirely invisible here. So before freeing the two > items are somehow zeroed? > > Jan Can you please clarify what do you mean here? Furkan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 10:40:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 10:40:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420731.1646967 (Exim 4.92) (envelope-from ) id 1x646u-0004y1-7D; Mon, 14 Sep 2026 10:40:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420731.1646967; Mon, 14 Sep 2026 10:40:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x646u-0004xu-4L; Mon, 14 Sep 2026 10:40:28 +0000 Received: by outflank-mailman (input) for mailman id 1420731; Mon, 14 Sep 2026 10:40:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x646t-0004xi-7d for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 10:40:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x646s-009Utk-9V for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:40:26 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7cf06-e002-0a2a0a5209dd-0a2a4503e2e6-42 for ; Mon, 14 Sep 2026 12:40:26 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7cf1a-fae8-0a2a45030019-4a7de18c9bb0-3 for ; Mon, 14 Sep 2026 12:40:26 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso17671515e9.3 for ; Mon, 14 Sep 2026 03:40:26 -0700 (PDT) Received: from [192.168.1.109] ([85.107.101.239]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e61a81943sm205742235e9.1.2026.09.14.03.40.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 03:40:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789382426; x=1789987226; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=UJAN9MPqRgVCZMSQ0QN1A1qp2/5TH4w9uZdSRau0bvM=; b=YWfhZEJZnPoVkM8iRMMuBYYAtb/ZBGiQIP0t9NU4q7URI2+SFheom33mLARlfuqhxO otL3MJwZHVhiRj8aET8Ydf3GvQahmSC3yTK1CyN6d1vjtEL/gp/DG4MBSP5IaBs71/1A m/3RD0+PiZc66VgrXG7FoeyTvK4cr2Saj3eYSUkged+f6LFnXS9yzJ9JLKfjg52BL/Gv Gxajsl6HLp1z9yx7cyM4G2+yy0zxVxzcLPkjwdAp08frK//ZQ9Ls+AifTlPHgdE5p7tO Q6zQmjGbySIjOBW5qxkNDhEn949Q8Ve8hSRgj8zd6haSGOuVmZ6H0zhwxK43tQX/ernM 96Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789382426; x=1789987226; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=UJAN9MPqRgVCZMSQ0QN1A1qp2/5TH4w9uZdSRau0bvM=; b=Y44gnYZ10a2loigYEyePue0jUuyORwSD+06DfUyylPyvdRneN0IsKwpJxHor9CNRD5 WzxBpT0aG3sgUx0+QiPKTTBypYOL8+BOuklra3T25EI/AHhXZBJwAdYr+eAd0aYfNJBS n5iNri8fMAo8jX0/WmAjdATNUozA8dIlJtsmVNiRYhVQpGW5TZeI2cAwb84R0c5TQF8v 44tBfUBt7g3N4AO/a9AX3j/HQeWsms3bxoxc9l1WvCARWJ0MDx9VevhQL28KjRpaahwv DxOlEI/ALBaEn1Zq8SljXP178pF8tgQWapRrM+cX1N1tR8SciTqb6YvM9BqGOqtRzjJr mF5A== X-Forwarded-Encrypted: i=1; AKwUvBy3AV3IAaQ5hfwDs8G5ofKHkqWIrpwd2Jc3UDTpF2Xb1jH9ia8hyehXhW4ZHe1VWOgd1SWS5+XoP4o=@lists.xenproject.org X-Gm-Message-State: AFuF++k568H0lGeZFuGwmPj/pVg42WOU53SPRGNBnsh7E1hyV5932DZM 0u3QEc1JWTazyCOzkkblDzW3GEUJzOsomsV5WlP9GnEGTvS7w6x/mqWF X-Gm-Gg: AYBFou2KhFGTisYdJdxAnsxJpvRKzPjwaImL5VNEjdrLRgXRjBZ9SNyZrTxHjjWVnlg h3PBkqc3MmETZcFf9OjdpS6G3owfdWLAEfbOXAE+CCaxArWd4RuMsGkFuDlO69urfZ0cydwYHs7 D26NAGZm49ndzGOzF6xj8aTtlERAyLR6BqJLHhFfAmzs/kVc4h9aPqXDA05JB3ZpYcpOeZOuGyj CLwDgRpZwi6vhM/neDx5Xb7NagplHsTdeyPNp8mqL/FV6JqDJ4LUYLwxWRV9rCyGVea5Dbujaka i2d46ICw4ysJICz5tVMAUfY2LIb8ZUjTKEuom146jZ+PIdohrqg82iZEs7YGwQpWCDYiGT9Bi5i K82O35EUkjDgCByWvRED5zd0LvzxpKecqbq/o0ovCtLmPbyfIVbhwRFCMlroGci9HUvdnxmIzo2 cIEbbBvfU6InN1eG8lZ+T2KwOSezg6qADuvNhTJRatdpBlOvYu37NDV55w5wClhSX4+N3w1XaH+ IqmviQMAhVRqThSrGw= X-Received: by 2002:a05:600c:4f16:b0:499:bf0e:95c8 with SMTP id 5b1f17b1804b1-49e7a65cd80mr27746375e9.1.1789382425387; Mon, 14 Sep 2026 03:40:25 -0700 (PDT) Message-ID: <0899d0b5-431a-450d-9aec-796f73f92a83@gmail.com> Date: Mon, 14 Sep 2026 13:40:20 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds To: Juergen Gross , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-3-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1789382426-776F34E9-F0D33F0A/0/0 X-purgate-type: clean X-purgate-size: 4356 On 9/14/26 12:16, Juergen Gross wrote: > On 26.08.26 06:57, Furkan Caliskan wrote: >> Now that we have introduced admission control for new and >> removed units. Extend it to XEN_DOMCTL_SCHEDOP_putinfo and >> putvcpuinfo, so growing an existing reservation via >> xl sched-rtds is checked too. >> >> putinfo sets the same (period, budget) for every unit of a >> domain at once, so it tests the whole domain's utilization >> delta atomically, rather than unit-by-unit, which could >> spuriously reject an overall-acceptable change depending on >> iteration order. >> >> putvcpuinfo changes one unit at a time, so it just calls >> rt_admission_test() directly. >> >> Signed-off-by: Furkan Caliskan >> --- >>   xen/common/sched/rt.c | 42 ++++++++++++++++++++++++++++++++++++++++++ >>   1 file changed, 42 insertions(+) >> >> diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c >> index 9126320801..9643a277fe 100644 >> --- a/xen/common/sched/rt.c >> +++ b/xen/common/sched/rt.c >> @@ -1527,11 +1527,43 @@ rt_dom_cntl( >>           op->u.rtds.budget = RTDS_DEFAULT_BUDGET / MICROSECS(1); >>           break; >>       case XEN_DOMCTL_SCHEDOP_putinfo: >> +    { >> +        uint64_t dom_old_util = 0, new_util, new_total; >> +        unsigned int nr_units = 0; >> + >>           rc = rt_validate_params(&op->u.rtds, &period, &budget); >>           if ( rc ) >>               break; >>   +        new_util = rt_unit_utilization(period, budget); >> + >>           spin_lock_irqsave(&prv->lock, flags); >> + >> +        /* >> +         * Same (period, budget) for every unit of d: test and commit >> +         * the domain's whole utilization delta atomically, rather >> +         * than unit-by-unit, which could spuriously reject an >> +         * overall-acceptable change depending on iteration order. >> +         */ >> +        for_each_sched_unit ( d, unit ) >> +        { >> +            svc = rt_unit(unit); >> +            dom_old_util += rt_unit_utilization(svc->period, svc->budget); >> +            nr_units++; >> +        } >> + >> +        new_total = prv->utilization - dom_old_util + >> +                    (uint64_t)nr_units * new_util; >> + >> +        if ( new_total > prv->utilization && new_total > rt_utilization_cap(d) ) >> +        { >> +            rc = -EINVAL; > > Is EINVAL a good choice here? I think a different error code might be wanted. Would EBUSY be okay here? Or what else would you suggest? > >> +            spin_unlock_irqrestore(&prv->lock, flags); >> +            break; >> +        } >> + >> +        prv->utilization = new_total; >> + >>           for_each_sched_unit ( d, unit ) >>           { >>               svc = rt_unit(unit); >> @@ -1540,6 +1572,7 @@ rt_dom_cntl( >>           } >>           spin_unlock_irqrestore(&prv->lock, flags); >>           break; >> +    } >>       case XEN_DOMCTL_SCHEDOP_getvcpuinfo: >>       case XEN_DOMCTL_SCHEDOP_putvcpuinfo: >>           while ( index < op->u.v.nr_vcpus ) >> @@ -1584,6 +1617,15 @@ rt_dom_cntl( >>                     spin_lock_irqsave(&prv->lock, flags); >>                   svc = rt_unit(d->vcpu[local_sched.vcpuid]->sched_unit); >> + >> +                rc = rt_admission_test(prv, d, svc->period, svc->budget, >> +                                        period, budget); >> +                if ( rc ) >> +                { >> +                    spin_unlock_irqrestore(&prv->lock, flags); >> +                    break; >> +                } >> + >>                   svc->period = period; >>                   svc->budget = budget; >>                   if ( local_sched.u.rtds.flags & XEN_DOMCTL_SCHEDRT_extra ) > > > Juergen Furkan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 10:45:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 10:45:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420739.1646976 (Exim 4.92) (envelope-from ) id 1x64CA-0005f0-Pw; Mon, 14 Sep 2026 10:45:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420739.1646976; Mon, 14 Sep 2026 10:45:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64CA-0005et-N8; Mon, 14 Sep 2026 10:45:54 +0000 Received: by outflank-mailman (input) for mailman id 1420739; Mon, 14 Sep 2026 10:45:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64C9-0005en-MO for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 10:45:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64C8-009VsU-VX for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:45:52 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7d052-8faa-0a2a0a5109dd-0a2a4505d122-42 for ; Mon, 14 Sep 2026 12:45:52 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7d060-4cb1-0a2a45050019-4a7de14cb5be-3 for ; Mon, 14 Sep 2026 12:45:52 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485b1d2874aso1486356f8f.1 for ; Mon, 14 Sep 2026 03:45:52 -0700 (PDT) Received: from [192.168.1.109] ([85.107.101.239]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb34e4b5sm25755895f8f.22.2026.09.14.03.45.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 03:45:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789382752; x=1789987552; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=JynjUxuKg39+UQ6kN2RPzfnI+Q+Me2MxlG+FxFUg+Jk=; b=Z6vM5uUVMQDsDNkRIOS8B0eC6YmUeXV3TZu8VQ/XLA6MPo/zoiuXYPfZa8cmvW8sU/ /9BDr50rjfAnBwZQCZUDdZ2Jo7IjlKt2lrpGXWqS3RkQu36nNPiu6EvmTnWa80ddAf2H HVoPrx6aJUSRn255iy5Btox663sAyrDE8mOyb+p2xz29cKQZ2RwP6vgmaAOxJjfC3GPv o76JlfSpVAWJmdXqSM0O8jexfHpSVKDO0NgqA/ZFrSjWtWNxuiWSSMksMOyRblu289Uj LX1sN9CK69rSYXq2BPLdHS6ljAOavDexNKlzaw3nTeM0V0OXE/1c0gY5/sQAARhXUJbr 9mMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789382752; x=1789987552; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=JynjUxuKg39+UQ6kN2RPzfnI+Q+Me2MxlG+FxFUg+Jk=; b=DJQpW6X0tUK+aAZwjfILMUjnyP5/hOcmPMXqXIAVNAYOmlZGYiOja8XKVYZ9uL3rt9 tgfL3AMt4xys6UPqIhprNbsmDi/1Ia70Ccsb1onszOZxysD8H8PwEKSlUjhf8tW5wcFo PREYdzxWWaSMSxUMgo/bi4QJHMQ9jHVgbh/1iXhAm6G6oAfkW4VU1KtMtjQV51sNDrGT MGmTYp5Rpdm1VAEXlkUXzC+0kZASN0XVOmgoPe7sdDH+fRAJe36ruC2k0Gf9YVhS34LO ERFuG61e2m6MgysCIuDF13i/eoZZkq+MkRvpOLhwKOkoLMGryxDcneCgAVXlcs1cX7mG ZQfg== X-Forwarded-Encrypted: i=1; AKwUvBwNpBJnNOkeJosfgHtIoUbHO1CmodtEB4U2rXI1BT5bYg5lsf90yTG/dY9lppXJ0zgWpWQuQ41TSs4=@lists.xenproject.org X-Gm-Message-State: AFuF++mCZIMoiH54WgjSt7tgB+laqtMHhquZfgM6Buck5J3IZ/LryL2n UvnUaGh5FgrJaWC7bVTnak5Z3wyK5Vpoa8qNSZxsefpbwV95IeZrsPf17IkWwA== X-Gm-Gg: AYBFou2v/Mz1jGoC85TGv1WV3KWdoUFQZoq5XROzj0cWe0XF62rMpfmyA/JRZm2ZEK7 xNtoSCRLa20WNn+Wwrr6mZBDs7GUbVMkoY7/TCWrgqVBKeNytwZDKEDh9/dp3iyMJSoCA0sq1Qn N01tPXHJQSW/f2Hq/wsik/VdLPlGPiGwBQzbILUjSaEo9y70q8muzNWYIW+6e1RpDM4KYWnvAcj NCXQ1KP56hEJ8ujouDj9HshVsUQeaGpy7/ix8E23ieBOYPN6CRyIlyKpgUsUwwwXGgo1HfTeUfG WFWiSaZbiK/E/Gt6JnovDRBh/yp0p0ls64KyNJVIhnt3QraDZL10dvnEK1pDmF5+za38bpchuWb kM5ahj6kNPEEWNH7LWYGblSDxa64NEqmg1wDPrQ0cDzjR7j5nfo5Y0+iv1h6Mn6+D9gtuGCs/9x N4oi/plZmzt73yd0LXMwCotwbkmIW+yi81kWlPdulSw/NYMVLLea/faKw7u2lxFW56RJLnwkmpP OBkbXs= X-Received: by 2002:a05:6000:186c:b0:486:f45a:57a7 with SMTP id ffacd0b85a97d-48702b0902amr4128597f8f.16.1789382752155; Mon, 14 Sep 2026 03:45:52 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 13:45:48 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/5] xen/sched: rtds: make admission control cpupool-wide toggleable To: Jan Beulich Cc: jgross@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com, xen-devel@lists.xenproject.org References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-5-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789382752-73EB92A1-8C393110/0/0 X-purgate-type: clean X-purgate-size: 1611 On 8/26/26 09:14, Jan Beulich wrote: > On 26.08.2026 06:57, Furkan Caliskan wrote: >> @@ -1691,6 +1709,33 @@ rt_dom_cntl( >> return rc; >> } >> >> +#ifdef CONFIG_SYSCTL >> +static int cf_check >> +rt_sys_cntl(const struct scheduler *ops, >> + struct xen_sysctl_scheduler_op *sc) >> +{ >> + struct xen_sysctl_rtds_schedule *params = &sc->u.sched_rtds; >> + struct rt_private *prv = rt_priv(ops); >> + unsigned long flags; >> + >> + switch ( sc->cmd ) >> + { >> + case XEN_SYSCTL_SCHEDOP_putinfo: >> + spin_lock_irqsave(&prv->lock, flags); >> + prv->admission_control_enabled = params->admission_control_enabled; >> + spin_unlock_irqrestore(&prv->lock, flags); >> + break; >> + case XEN_SYSCTL_SCHEDOP_getinfo: >> + spin_lock_irqsave(&prv->lock, flags); >> + params->admission_control_enabled = prv->admission_control_enabled; >> + spin_unlock_irqrestore(&prv->lock, flags); >> + break; >> + } > > Blank line please between non-fall-through case blocks. > >> --- a/xen/include/public/sysctl.h >> +++ b/xen/include/public/sysctl.h >> @@ -814,6 +814,10 @@ struct xen_sysctl_credit2_schedule { >> uint32_t ratelimit_us; >> }; >> >> +struct xen_sysctl_rtds_schedule { >> + bool admission_control_enabled; >> +}; > > In the public headers only fixed-width types may be used. The width of > bool is ABI-dependent (no matter that it's exceedingly unlikely to ever > be other than the same size as char). > > Jan Thanks, I'll fix these in v2. Furkan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 10:52:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 10:52:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420752.1646985 (Exim 4.92) (envelope-from ) id 1x64I2-0007VX-EW; Mon, 14 Sep 2026 10:51:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420752.1646985; Mon, 14 Sep 2026 10:51:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64I2-0007VQ-Bf; Mon, 14 Sep 2026 10:51:58 +0000 Received: by outflank-mailman (input) for mailman id 1420752; Mon, 14 Sep 2026 10:51:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64I0-0007VI-So for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 10:51:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64I0-00Aa2z-5q for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:51:56 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7d1c0-2eae-0a2a0a5409dd-0a2a4508abd4-42 for ; Mon, 14 Sep 2026 12:51:56 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7d1cb-f659-0a2a45080019-a237832faf18-3 for ; Mon, 14 Sep 2026 12:51:55 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id BF81A4EE00AD; Mon, 14 Sep 2026 12:51:54 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789383115; b=LTDIOYct3sI4In+uKmvU78owhQTUqUzyeZ9ptMZCtMArMSraXIKLsV95hZZxBn0upZtf p9cIFzJdDdnjkJSqMmMqjIkvdPagVDLKt9SZvr5iMr9Kz0BZWnNw++t1JnBRWaHZ2Camf SF9MuI4MxGUI/H6NdQCKL+lje7CsSHPcCaxeHd3IHNhhT3QCXlKt7FxNd1niI93b864Kb UEMMSGQ688ggDZsYQS7JXbmSGz/sutSkklmOX59Mm363se47VuyUewDarELyHsDzA32Y5 rD1zH77/KBF+I6DNzxpsD75Em/Gy54rJRDDPG0bWLlaWqu+pYexqSukFEvTeXGEBFTFOo jpO9xOkeuZkwQ3/m/oFxSpdaLmOTEwVWlY9srW24ZGx1WvQ4k5XahVeLixnP9GKEGz7GY wVvWeW+57jiSeAFCvlfzbQaIwUhh4hgPotugKXuHWGJubj31uQOJVt51MxtG3lXTA8y5Y nHaItVYiHyobzH96shQee5YZ4IxZd7y9ern2zFyLOpPg9KESEKIPeV9+t/epX9mlpe+eE KXrBw47dRrp87vTRTax3idoOb47D7ekIWip2LvcCzfvwNjm9MR5TQEttCWoOl+llGdRdU +1vruPE+xEXKDC3PbRcr1WvuKi6goFkfempuIDXQtz8qrFMFN9JlSkb0I5dlDc0= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789383115; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=SgNyosp90VH7eDQuiqttRwIXiW7vZ1s+1MzF9mXojdU=; b=zlLEW+L9x4CfRq2onNhjk0ZOsqUYsS2rOl3slHb2ZNTNdUsIqt3ZelYIVSj46mSbf3y5 TUFIQplr7bP3F3h9EZOcaaVdNLiJ8/amaSLjsSIQtvLBIFBanaT9hXxIszQFTuPaSuy0D 3KexA3JknT1NsjrH2AOvIbRwyRN2dRu9aef5m8Q6ARsKsxZ55gMZfRXCDoH5Ku6kHPlxr fMwQ2BmehRCDHE+dWiev+DGGhx+snK+sjqcz/jVRpYVnzdjchXqxibLO589u38YSYEBZ2 E+IPrF7LKWrb2BZyhrFI1Ms/CffryehEK/3vMqvEXJPJwEL/h9EFJMzwD6pJVaMb80uLY HOa3dWPXPy791ofaEA4wCKrR551sM0ch3eib0/F4CDVUqzo5HCBDSfdtlT378lRgPwVrd KeYs+wxWoGRWJXuL2P7FGFn6qYVNrchDe6OpkB2BSEaZ4Kb53vcb/GMvyIFTiZHT5sXLG zTXKiRLm3aspjP7ts6BHjmzS3SgRpFA42ZFDGqF5aQZ4y6qlwClrSSVCIauv5Dqn6QU2y 7qmwNwVWmjHxEZC8we3XpY8wJIrSMaZT6xF5YuFzJjuyfK77xGjcRdG8SRY+TGDQw31sv Km/vR1AcABeMOgqJrXFI5Hhym2cRu6BhrV61M0eLvDim3RErwn2pA5eDslwbMXc= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Mon, 14 Sep 2026 12:51:54 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 2/4] Eclair: relax long <-> function-pointer conversion deviation In-Reply-To: <3b6b2796-b532-4b6b-8b04-8edce203ad3d@suse.com> References: <6d212d60-5c0b-4909-996d-5d6a4906b7e1@suse.com> <43e412de9e5165f33c572841bfc58dc9@bugseng.com> <3b6b2796-b532-4b6b-8b04-8edce203ad3d@suse.com> Message-ID: <1410bb68c5bf5715690a542585834e9f@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789383115-D5B4987B-170C9A70/0/0 X-purgate-type: clean X-purgate-size: 516 >> Same as above > > Okay, I'll happily adjust. As I have no reference for the syntax, I > just > have to guess when making changes. > We'd be glad to share the ECLAIR User Manual with the Xen maintainers. In fact, the ECLAIR installation on the testing machines has already a copy of it. Anthony should be able to make it available to you and others. -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Mon Sep 14 10:54:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 10:54:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420762.1646993 (Exim 4.92) (envelope-from ) id 1x64Kc-000839-QI; Mon, 14 Sep 2026 10:54:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420762.1646993; Mon, 14 Sep 2026 10:54:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64Kc-000832-NK; Mon, 14 Sep 2026 10:54:38 +0000 Received: by outflank-mailman (input) for mailman id 1420762; Mon, 14 Sep 2026 10:54:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x64Kb-00082w-Jn for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 10:54:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64Kb-008TLc-00 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:54:37 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7d266-e002-0a2a0a5209dd-0a2a4505a158-6 for ; Mon, 14 Sep 2026 12:54:36 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7d26c-4cb1-0a2a45050019-4a7de18cbfd2-3 for ; Mon, 14 Sep 2026 12:54:36 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd38e0f79so9360205e9.3 for ; Mon, 14 Sep 2026 03:54:36 -0700 (PDT) Received: from ?IPV6:2a02:778:142:8f01:2700:bad4:284c:5aa5? ([2a02:778:142:8f01:2700:bad4:284c:5aa5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e60ac411asm294572305e9.8.2026.09.14.03.54.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 03:54:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789383276; x=1789988076; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=uR4S+flbKftxTsnvkVTTjO2b1d5a5haTCsx34TGyzE0=; b=Qv52MuuW+Wbym+rURLozpSAaJhn/hRbXoJefIroMZ7x4Xe3XIHraI63SFHHFTDTdic sSraelUVt2eA3ZmfmKEE7L8DGl3El/VWBAC9GJi+/mVrk9Ao8dp9432fOjiasxAd5We1 MMzifvqgTszsMwsYz6MjJVWBMnVdSxpxM3BS3OtcU/6/prlEmeBaYjXXy94VlWf3TDAM zS6cYTCVCEvsx5UZj8MURlu6LyrfhxTpsARfP8U4RjEhzirSAZkyJF4RNazPDOBIk4s+ 9AYFovpdhO4fjFL+x+oIUcWNXxKA863+Yus5WsVMlAEZLGR93gS8LeSGH2+GuR+KSisX C8cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789383276; x=1789988076; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=uR4S+flbKftxTsnvkVTTjO2b1d5a5haTCsx34TGyzE0=; b=Tno5hLq1SE7IjIgBPIho9ojyphvxtn5W1NBI5bsOGuHB8XzAKpWG7FNu3FwgeR/IsO GWkmisvnzHy7YxItmB8sPqhtUc/FuXBocQHVJBbWxAwcUhce4o/AEJPF8MMsCsEFvgZl 6siND9wOPFliayTZ3Mk1/AKBuiV3FDjeI74y9RtY1lCm+W4Y9YVRED/xx3LE1Vp+XbGa 6pVFaDDmQ+jWi9VUzwJ7x4g7Vdr6vQvxpnWDnW2nKDGcfxjvh8jpmtRWudUbAyQp8KiO SX7pZ8GWQ+0iJ6J5bTKRYlOnDST91+SZKx9nNrVT9XeI6J+OrDpUsfhwhuU8e3vdA4Ba jjEw== X-Forwarded-Encrypted: i=1; AKwUvByQYYqJHSCGwRyj9fz09o+amF5S2SF0ZfdXLU0RxPVy/c1LMe9ylK7Xyw5H+HY2jvGSnTte2P7b4qc=@lists.xenproject.org X-Gm-Message-State: AFuF++khQQubBupK3Bu74+0Jvvh117RE/SYogOtJgeSN6RF46iGZpB96 L7jQ1kjqWHSuHvpoaIarg1/smSDI2uNnluf8OOOfKPWTsQRROzIuCfA8rzzV2m5o X-Gm-Gg: AYBFou0VGcYOUvZAOxs22Puhdxi0Yol+6RhZZNaGNCNsTUvDMLyR/UBl6AtFC2CkiCt BmLUcKU2B1Rkpk8tiJ0NDJKY8m+i0vzZaQdiOPUWoZBx1xCEy3bRKny+d5+MOd/9V3VA+DrWnrG PSJG9Wjlbhx+HBxMtXMG6k9Zi2ksFfhs2m1EJPKgVzxBJ/7s3xk+ioXk8hC91/qg1taRaPhe7iv s6+hRLLLyK00sp9m2E7jXtCn8YZHXKwERshvIZP0LDB6271cUlF3abmxmD7Ul5zZi4wvDVpSbSB m+zGT1uoEZQGLn2ynmlM5HfvYDzRaj9+RthuPANL2JvXP87TGPtKW97YaEu0SHx1ONU6y3gAAks ff1be1fx3NxSWCWUTTndfGKygOO5hvzZ0k3WQ+qzb9Jvl11NRmSES0noM8aCZjmm0HbX1CBhP+3 4RIr7bmOSvd/Op7vv7VSa65B3UlKaY1S1JeYVzoSViNouPiY0J44XlzPIJiPM0PlYs4DfIMcpIS tmp7aXU4r/DAQd17HY/TK0UWQ4R2r0tbjk935lfr/EhcbpqqeBLo8nYYezOQAR5zQ== X-Received: by 2002:a05:600c:8b74:b0:49c:ee20:e787 with SMTP id 5b1f17b1804b1-49e7a658021mr43224175e9.1.1789383276208; Mon, 14 Sep 2026 03:54:36 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 12:54:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 16/20] xen/riscv: implement IRQ routing for device passthrough To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Alistair Francis , Connor Davis , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789383276-24B1D2A1-C43D94B2/10/73395122804 X-purgate-type: spam X-purgate-size: 6148 On 9/10/26 2:53 PM, Jan Beulich wrote: > On 09.09.2026 17:07, Oleksii Kurochko wrote: >> --- a/xen/arch/arm/irq.c >> +++ b/xen/arch/arm/irq.c >> @@ -205,7 +205,7 @@ void __init init_IRQ(void) >> static inline struct irq_guest *irq_get_guest_info(struct irq_desc *desc) >> { >> ASSERT(spin_is_locked(&desc->lock)); >> - ASSERT(test_bit(_IRQ_GUEST, &desc->status)); >> + ASSERT(desc->status & IRQ_GUEST); >> ASSERT(desc->action != NULL); >> >> return desc->action->dev_id; > > Why did an Arm change slip into a RISC-V patch? Considering that this code is executed under the spinlock it is fine to not use test_bit() so it is part of dropping of bitops functions. > >> --- a/xen/arch/riscv/aplic.c >> +++ b/xen/arch/riscv/aplic.c >> @@ -325,9 +325,40 @@ static const hw_irq_controller aplic_xen_irq_type = { >> .set_affinity = aplic_set_irq_affinity, >> }; >> >> +static unsigned int cf_check aplic_guest_irq_startup(struct irq_desc *desc) >> +{ >> + BUG_ON("unimplemented"); >> +} >> + >> +/* >> + * Shared by ->shutdown(), ->enable(), ->disable() and ->end(), which have >> + * no state. >> + */ >> +static void cf_check aplic_guest_irq_stub(struct irq_desc *desc) >> +{ >> + BUG_ON("unimplemented"); >> +} >> + >> +static void cf_check aplic_guest_set_irq_affinity(struct irq_desc *desc, >> + const cpumask_t *mask) >> +{ >> + BUG_ON("unimplemented"); >> +} >> + >> +static const hw_irq_controller aplic_guest = { >> + .typename = "aplic", > > This is indistinguishable from aplic_xen_irq_type. Naming of both variables > also isn't consistent I will align names properly: --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -316,8 +316,8 @@ static void cf_check aplic_set_irq_type(struct irq_desc *desc, spin_unlock(&aplic.lock); } -static const hw_irq_controller aplic_xen_irq_type = { - .typename = "aplic", +static const hw_irq_controller aplic_host_irq_type = { + .typename = "aplic-host", .startup = aplic_irq_startup, .shutdown = aplic_irq_disable, .enable = aplic_irq_enable, @@ -345,8 +345,8 @@ static void cf_check aplic_guest_set_irq_affinity(struct irq_desc *desc, BUG_ON("unimplemented"); } -static const hw_irq_controller aplic_guest = { - .typename = "aplic", +static const hw_irq_controller aplic_guest_irq_type = { + .typename = "aplic-guest", .startup = aplic_guest_irq_startup, .shutdown = aplic_guest_irq_stub, .enable = aplic_guest_irq_stub, @@ -357,8 +357,8 @@ static const hw_irq_controller aplic_guest = { static const struct intc_hw_operations aplic_ops = { .info = &aplic_info, - .host_irq_type = &aplic_xen_irq_type, - .guest_irq_type = &aplic_guest, + .host_irq_type = &aplic_host_irq_type, + .guest_irq_type = &aplic_guest_irq_type, .handle_interrupt = aplic_handle_interrupt, .set_irq_type = aplic_set_irq_type, }; > >> --- a/xen/arch/riscv/include/asm/intc.h >> +++ b/xen/arch/riscv/include/asm/intc.h >> @@ -15,6 +15,7 @@ enum intc_variant { >> }; >> >> struct cpu_user_regs; >> +struct domain; >> struct irq_desc; >> struct kernel_info; >> struct vcpu; > > Why is this suddenly necessary? There are ... > >> @@ -76,10 +82,13 @@ void register_intc_ops(const struct intc_hw_init_ops *init_ops); >> void intc_init(void); >> >> void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority); >> +int intc_route_irq_to_guest(struct irq_desc *desc, unsigned int priority); >> >> void intc_handle_external_irqs(struct cpu_user_regs *regs); >> >> int domain_vintc_init(struct domain *d); >> void domain_vintc_deinit(struct domain *d); >> >> +int vintc_reserve_virq(const struct domain *d, unsigned int virq); > > ... existing uses of struct domain already, immediately ahead of this added > line. Forward declaration of 'sturct domain' was missed before so it was added with this change. I can drop forward declaration as you noticed that it hasn't been needed before this change but it still make sense to add IMO. > >> @@ -78,6 +82,22 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority) >> intc_set_irq_priority(desc, priority); >> } >> >> +int intc_route_irq_to_guest(struct irq_desc *desc, >> + unsigned int priority) >> +{ >> + ASSERT(spin_is_locked(&desc->lock)); >> + >> + ASSERT(intc_hw_ops->guest_irq_type); >> + >> + desc->handler = intc_hw_ops->guest_irq_type; >> + __set_bit(_IRQ_GUEST, &desc->status); > > The revlog says you replaced all of these bitops. > >> @@ -227,3 +251,240 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq) >> spin_unlock(&desc->lock); >> irq_exit(); >> } >> + >> +static struct irq_guest *irq_get_guest_info(struct irq_desc *desc) >> +{ >> + ASSERT(spin_is_locked(&desc->lock)); >> + ASSERT(test_bit(_IRQ_GUEST, &desc->status)); > > Same here. And more elsewhere. > >> +/* Route an IRQ to a specific guest */ >> +int route_irq_to_guest(struct domain *d, unsigned int virq, >> + unsigned int irq, const char *devname) >> +{ >> + struct irq_guest *info; >> + struct irq_desc *desc = irq_to_desc(irq); >> + unsigned long flags; >> + int retval = 0; >> + >> + if ( d->is_dying ) >> + return -EINVAL; >> + >> + info = xvzalloc(struct irq_guest); >> + if ( !info ) >> + return -ENOMEM; >> + >> + info->d = d; >> + info->virq = virq; >> + >> + info->action.dev_id = info; >> + info->action.name = devname; >> + /* The action is part of 'info', thus it is freed together with it. */ >> + info->action.free_on_release = false; > > The revlog says this line doesn't exist anymore. > I will double check all the places before sending v10. Thanks. From xen-devel-bounces@lists.xenproject.org Mon Sep 14 11:03:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 11:03:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420775.1647003 (Exim 4.92) (envelope-from ) id 1x64T9-0001pt-P6; Mon, 14 Sep 2026 11:03:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420775.1647003; Mon, 14 Sep 2026 11:03:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64T9-0001pm-MQ; Mon, 14 Sep 2026 11:03:27 +0000 Received: by outflank-mailman (input) for mailman id 1420775; Mon, 14 Sep 2026 11:03:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64T8-0001pg-Q8 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:03:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64T8-00D35q-33 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:03:26 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7d473-8faa-0a2a0a5109dd-0a2a450add0c-20 for ; Mon, 14 Sep 2026 13:03:20 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7d478-f2d2-0a2a450a0019-4a7de18d9ad2-3 for ; Mon, 14 Sep 2026 13:03:20 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7355e411so12394565e9.1 for ; Mon, 14 Sep 2026 04:03:20 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e62232cb7sm241487115e9.4.2026.09.14.04.03.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 04:03:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789383800; x=1789988600; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VosfrI+8RtvxpWlfnnw7Xr/+ZAYLsvan3hsjL08KQUI=; b=g/8l7F7dknPb8xezowlQctydj+maX/PCM7LsApVUDacotRFMEmo4c00vNA9g9Yb44z 4o6V6DNbhSBriMg5mrkh6SDD/AQi4LBY0CjwNdphHmkpezjtQ5QbnC5+kWVp/jhqx2BZ ktJhMp3enMEPA5Sr+HNmkIX0q5Hx5ZBEsMgjbCzfhEpGKRhEJboV6ungGr8eAttm9EbP S+LxDqTzR7x2Kvx3k671i5BmjFtEhWDr/pFR35heaZIU9Vdm+tsVUUFKvC4zsbPQIUvh 4jo/vZq9AuFfY7F0fiinK494RuN3S2abpuYYtWnXYOAUG/bC1iEybgwgVEgbw86JIqWS MUUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789383800; x=1789988600; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=VosfrI+8RtvxpWlfnnw7Xr/+ZAYLsvan3hsjL08KQUI=; b=OSq7plBCblUxk3TCGRnhVXTw+nfutc3FeeFQNoQPrXvF92Ts9w4Y1kRjlQ9e4Ir4Wj 6fIQb8rqBS8p6Hrhu8fmMtml8PG2KWF2K4rE02yhfcBVfleuPT9AXUImOI2v2KJ2kDyT /9bSP1iLEdlOuFzDUL98eu2IKWFkrl+yzYEDPgacpglJv7j8FaXQxmyvftJVbO3sQqD7 iM7Diw01QBM1mP8qthYoijfaj35sMwLgf2oIrytr/eLgXaAADqx3li29PjE3DMsMbLKf 2Bnm/SnK6WoztuxtioT086Q2BHFPdCW1okKK/aZe0uxTBZFr19DOgf/77Aqm509Tk9oF e+8A== X-Forwarded-Encrypted: i=1; AKwUvBzX6i9dEZwIKkDkc4E6Wq3siDeByZ6baKe5FN9ktTmZMu+yEGoErOgOCVJQV9xrIPJiky1gyGVvUhY=@lists.xenproject.org X-Gm-Message-State: AFuF++lcs+z3TlgFf2PFRaiJihw4MKrdOzl3H0F4xvcPXcDUFLXlocsM QvjWS/gMJzm4jIDAptb2mWZJCKl1Oc1VYcqfUxmFyaCevWTdetdNPkkmZR1NUVGelA== X-Gm-Gg: AYBFou2h7260waN8DnQxCXuaUREcZiE91x9XENuOoWP76uSOcxhLll6xyqkGRoBC1V3 omiPCKG5Ft2FjXZIO0oRWhLjg3MqeH0PjKqlrE/9u7IQvVrC13YPdS8lUdmjrp4UleSLczOcWbp 49n/epiOL3YyiumbTZ379CoLwm8B+F4W+uGJaTGLFJZvS9vZN4FMCjPqKSTCofduM19qOdTWXVL VirSKrCwX67xQvHoVCt97oyXW3viYDBXrFq7ggBRpBZS4PgmjlFST50zPY/sP9Ud6k2S5zuUUVu w/lC7l0H1r9bcYbR7mQteL6uDAqx05/01cj2eaVTIo8ZV9AtJpG4kkvs8M31C6iWIug3Lx6rtsl FnkbNWhCssFN7dIoYKNv2o4kYknAgsGb1NziZM9QQR/ZfCZaEif1nauKfnAwnKUaRPUk8AqoQob bX7m0cX9bOZwsI832QhtkHwI/Z6rmJt4KjX0XQpBv1EdQkvrZvlBgvFBMjgU1MpjC19Q+x4sxEV aYoe52TVKnGJVbiJqeAXls= X-Received: by 2002:a05:600c:8b6b:b0:49c:d52e:d0ea with SMTP id 5b1f17b1804b1-49e7a64acc2mr53511275e9.4.1789383800100; Mon, 14 Sep 2026 04:03:20 -0700 (PDT) Message-ID: <895a427d-1adb-43cb-a2bb-e0e9d50791db@suse.com> Date: Mon, 14 Sep 2026 13:03:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 24/39] xen/riscv: add helpers for decoding a trapped load or store To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789383800-532D8CFC-40C8ABBC/0/0 X-purgate-type: clean X-purgate-size: 12186 On 27.08.2026 17:21, Oleksii Kurochko wrote: > emulate_load() and emulate_store() will both need to obtain the > instruction which caused a guest MMIO trap, decode it, and locate the > register operand it names. Add what the two share, ahead of either of > them being implemented: struct decoded_insn, insn_fetch_faulted(), > decode_ldst_insn(), guest_xlen(), guest_gpr() and advance_pc(). > > The mask/match chain is adapted from Linux's KVM RISC-V implementation. > > Nothing calls any of this yet, so tag the functions __maybe_unused to > keep the build going; the tags go away once emulate_load() and > emulate_store() gain their bodies later. That'll be a lot of churn to drop those __maybe_unused again. As this is merely transient, did you consider putting (void)is_load_guest_page_fault; etc in e.g. emulate_load()? > @@ -13,9 +14,29 @@ > #include > #include > #include > +#include > +#include > #include > #include > > +/* > + * Determine the trapped load or store instruction which caused a guest MMIO > + * trap. > + */ > +struct decoded_insn { > + /* The instruction itself, and its length in bytes. */ > + unsigned long insn; > + unsigned int insn_len; > + /* Width of the memory access, in bytes. */ > + unsigned int len; > + /* Number of the register operand: rd for a load, rs2 for a store. */ > + unsigned int reg; > + /* The access is a store rather than a load. */ > + bool is_write; > + /* The load zero-extends its result rather than sign-extending it. */ > + bool is_unsigned; > +}; I wonder how efficient this is. With use of bitfield the size of this struct can likely be more than halved. With suitable choice of widths this may not even cause significantly worse generated code. One thing in any event: Why would the insn field need to be wider than 32 bits? > @@ -39,6 +60,71 @@ struct guest_fault { > paddr_t gpa; > }; > > +static bool is_load_guest_page_fault(unsigned long scause) > +{ > + return scause == CAUSE_LOAD_GUEST_PAGE_FAULT; > +} With no "store" counterpart this may end up being a little fragile (at the use site(s)). > +/* > + * The effective XLEN of the guest at the point of the trap: hstatus.VSXL for a > + * trap taken from VS-mode, vsstatus.UXL for one taken from VU-mode. > + * > + * VSXL is consulted whichever mode the trap came from, as it also gives the > + * width of vsstatus itself: where VSXL says 32, that register has no UXL field > + * to consult and VU-mode is 32-bit as well, there being nothing to configure. > + * > + * It is needed to decode a trapped instruction: the encodings which exist only > + * for XLEN=64 must not be recognized for a 32-bit guest. Besides those simply > + * being reserved there, the compressed ones are ambiguous: C.LD and C.FLW > + * share the encoding 0x6000 (mask 0xe003), and likewise C.SD/C.FSW, > + * C.LDSP/C.FLWSP and C.SDSP/C.FSWSP. > + * > + * IS_ENABLED() can't be used here as HSTATUS_VSXL is defined for > + * __riscv_xlen == 64 only, the field not existing on RV32 in the first place. > + */ > +static __maybe_unused unsigned int guest_xlen(const struct cpu_user_regs *regs) > +{ > +#ifdef CONFIG_RISCV_32 > + return 32; > +#else > + unsigned long xl = MASK_EXTR(regs->hstatus, HSTATUS_VSXL); > + > + if ( (xl == XLEN_FIELD_64) && !(regs->sstatus & SSTATUS_SPP) ) How about xl > XLEN_FIELD_32 here, to be RV128-compatible? > @@ -87,6 +173,250 @@ static void resolve_faulting_gpa(struct guest_fault *gf) > (htinst_is_pseudo(gf->htinst) ? 0 : (gf->stval & 3)); > } > > +/* > + * Where the value of a decoded instruction's register operand is held. > + * > + * Relies on x0..x31 being laid out at the start of struct cpu_user_regs in > + * architectural register-number order; see the comment there. > + */ > +static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs, > + unsigned int reg) > +{ > + ASSERT(reg < 32); > + > + return REG_PTR(reg, 0, regs); > +} For future callers of this: For 32-bit environments hardware guarantees upper halves of registers to be zero? > +/* > + * Obtain the instruction which caused a guest MMIO trap, filling in > + * @di->insn and @di->insn_len. It either comes transformed in htinst, or has > + * to be fetched from guest memory. > + * > + * Returns true if the fetch faulted in turn; the resulting trap has then > + * already been redirected to the guest and there is nothing further for the > + * caller to do. Where it returns false, @di has been filled in and emulation > + * is to continue. > + */ > +static bool __maybe_unused insn_fetch_faulted(const struct guest_fault *gf, > + struct decoded_insn *di) > +{ > + unsigned long htinst = gf->htinst; > + > + /* > + * A pseudoinstruction says nothing about the instruction the guest was > + * executing, and comes with a guest physical address which isn't the one > + * that instruction accessed. handle_guest_page_fault() deals with such a > + * fault on its own, so no emulation can ever start for one. > + */ > + ASSERT(!htinst_is_pseudo(htinst)); > + > + if ( htinst & BIT(0, UL) ) > + { > + /* > + * Bit[0] == 1 implies trapped instruction value is > + * transformed instruction or custom instruction. > + * > + * The transformation always yields the 32-bit format, with bits[1:0] > + * holding a marker instead of the original opcode bits: bit[0] set to > + * flag the transformation, bit[1] clear if the trapped instruction > + * was a compressed one. Restoring the opcode bits makes the value the > + * valid 32-bit encoding decode_ldst_insn() matches against. Its > + * INSN_MASK_C_* cases exist for the branch below, where a compressed > + * instruction is read from guest memory as is: a trapped one arrives > + * here already expanded to its 32-bit equivalent, and the opcode bits > + * just restored keep it from matching those cases anyway. > + * > + * The length then cannot come from the value anymore, only from > + * bit[1]. And only a 16- or a 32-bit instruction is ever reported > + * this way: the standard load and store instructions the hardware > + * transforms are all of one of these two lengths, anything else comes > + * as the zero special value handled below. > + */ > + di->insn = htinst | INSN_16BIT_MASK; > + di->insn_len = (htinst & BIT(1, UL)) ? 4 : 2; Hmm, so ->insn_len doesn't describe ->insn, as suggested by the comment in the struct. That wants clarifying there. > + } > + else > + { > + const struct cpu_user_regs *regs = gf->regs; > + struct trap_info utrap = {}; > + > + /* > + * Bit[0] == 0 implies trapped instruction value is > + * zero or special value. With the pseudoinstructions ruled out > + * above, only zero is left: the instruction has to be read from > + * guest memory. > + */ > + > + di->insn = riscv_read_guest(regs->sepc, true, &utrap); > + if ( utrap.scause ) > + { > + /* > + * If during getting of trapped instruction a fault happen in > + * G-stage translation then CAUSE_LOAD_GUEST_PAGE_FAULT is > + * generated. Such faults during this operation is considered as > + * bus error. > + */ > + if ( is_load_guest_page_fault(utrap.scause) ) > + utrap.scause = CAUSE_FETCH_ACCESS; > + > + utrap.sepc = regs->sepc; Couldn't this be part of the initializer of utrap? Or does read_guest() alter the field? > + trap_redirect(&utrap); > + > + return true; > + } > + > + /* > + * riscv_read_guest() fetches at most two halfwords, so a wider > + * encoding has been read in part only and cannot be decoded here. > + * > + * Report an illegal instruction, which is what the guest would have > + * got for such an encoding anyway: the ISA defines no instruction > + * wider than 32 bits. > + */ Such wording is at risk of going stale. Better say that no guest-exposed extensions have wider than 32-bit insns. > + if ( !INSN_IS_16BIT(di->insn) && !INSN_IS_32BIT(di->insn) ) > + { > + utrap.sepc = regs->sepc; With the earlier remark this may then also not be needed here. > + utrap.scause = CAUSE_ILLEGAL_INSTRUCTION; > + /* > + * stval is left zero: the spec allows that for an illegal > + * instruction, and only part of the instruction is in hand. > + */ Not just this - stval may also not be wide enough to hold the full insn. > + trap_redirect(&utrap); > + > + return true; > + } > + > + di->insn_len = INSN_LEN(di->insn); If you moved this up a little, you could avoid the separate use of INSN_{32,64}BIT_MASK above, by going from the value calculated here. > + } > + > + return false; > +} > + > +/* > + * Decode the load or store instruction fetched into @di, filling in the > + * remaining fields of it (@di->insn and @di->insn_len are filled by > + * insn_fetch_faulted()). > + * > + * @xlen is the effective XLEN of the guest, needed as > + * the encodings which exist for XLEN=64 only must not be recognized for a > + * 32-bit guest. > + * > + * Returns false if the instruction is not a load or store which can be > + * emulated here. > + */ > +static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di, > + unsigned int xlen) > +{ > + unsigned long insn = di->insn; > + /* Register fields of the uncompressed forms ... */ > + unsigned int rd = RV_RD(insn); > + unsigned int rs2 = RV_RS2(insn); > + /* > + * ... and of the compressed ones, where the 3-bit field selects one of > + * x8..x15, while the stack-pointer-relative forms have a full-width one. > + */ > + unsigned int rs2s = RVC_RS2S(insn); > + unsigned int rs2c = RVC_RS2(insn); > + > + di->is_write = false; > + di->is_unsigned = false; Elsewhere we established that the whole struct has to start out zeroed. Why not leverage that also here? > + di->reg = rd; > + > + if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB ) > + di->len = 1; > + else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU ) > + { > + di->len = 1; > + di->is_unsigned = true; > + } > + else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH ) > + di->len = 2; > + else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU ) > + { > + di->len = 2; > + di->is_unsigned = true; > + } > + else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW ) > + di->len = 4; > + else if ( xlen == 64 && (insn & INSN_MASK_LWU) == INSN_MATCH_LWU ) > + { > + di->len = 4; > + di->is_unsigned = true; > + } > + else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW ) > + { > + di->len = 4; > + di->reg = rs2s; > + } These insns encode the access width uniformly, i.e. doing things the way done above is rather inefficient. > + /* c.lwsp and c.ldsp are reserved with rd being x0. */ > + else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP && rd ) > + di->len = 4; Careful with insns not part of the base ISA: Between the trap and you getting to fetch and decode, the in-memory insn may have changed. You posibly set yourself up for vulnerabilities if you permit C encodings for guests not having C exposed to them. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 11:15:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 11:15:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420789.1647013 (Exim 4.92) (envelope-from ) id 1x64ek-0003jC-Pg; Mon, 14 Sep 2026 11:15:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420789.1647013; Mon, 14 Sep 2026 11:15:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64ek-0003j5-MF; Mon, 14 Sep 2026 11:15:26 +0000 Received: by outflank-mailman (input) for mailman id 1420789; Mon, 14 Sep 2026 11:15:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64ej-0003iz-TL for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:15:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64ej-008Xww-9j for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:15:25 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7d746-8faa-0a2a0a5109dd-0a2a450bc820-34 for ; Mon, 14 Sep 2026 13:15:25 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7d74c-b7e8-0a2a450b0019-4a7de18cf653-3 for ; Mon, 14 Sep 2026 13:15:25 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccff31419so15569625e9.3 for ; Mon, 14 Sep 2026 04:15:25 -0700 (PDT) Received: from [192.168.1.109] ([85.107.101.239]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e6fe9d3e3sm127666515e9.0.2026.09.14.04.15.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 04:15:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789384524; x=1789989324; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LbuipxVR0TzPXP53d+scSiLX1pqUdF3Ft9Tt//zTHeM=; b=HK69w/MwOrFhPYIuUClS+s/SZ8SVHG7ZOjrNYFnH1kcTSN9B4K/TuDr9woVOXB/QrP MFMTRDjsVlVV1qw5rM8aFTSZFzPouLgTEABh2zzw5YLEeUm3tUhy5wKj+fnt5u6ekfMR dQtiRSbBil0+WVjiJF3AajWwUPhPXV1vdTh7/0Q7Lsm9pGS5B4vtCZwsWouzCB4nM1mZ Ie9URnw8eAkpjxxiauFNO+8A7JNueRLPvhPmStl08nxnABwirp+K/2jNva74enaSbPMo unfsoGSOsb+uE0L3NBkUXsY/DbW+QikBgegDaKT1TBoiqj9nROZu6LLQoAD/lH/sS0UA HZMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789384524; x=1789989324; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=LbuipxVR0TzPXP53d+scSiLX1pqUdF3Ft9Tt//zTHeM=; b=A6Njxahobo9pQoCQPyeLUyEfbG8gIx7qH1ZZs1nmMO3olckGnLnR4m/5Ypwc04WKsa eMK9wSLFb1TPyiTGRY8/6wjmzPdcFr3jd48sFaRhefd0/6WMH01VDJkxuI1V4l5kVEDY 46AO8eLdx664oSz7m3XqfrvpkdcJ7w+5oatH+js1wR1T/zyZANSgu4+kjOspZCNannH0 tF2At1iPwZtLDGf3A9S3mnaCOl+eISwZLN8ztFWTyFVSCmPKTCHruBaasZ+ef3sfMLaD B3Gq3iLxxYj7QHmTKAOt6nhQGYG638CZXQ3M7UnsJrKhksID2Wf617B+/1e1N5pHmmsh DGEg== X-Forwarded-Encrypted: i=1; AKwUvBx+cSup3FYCsBDqMKbiIdY9cMVEAnQQAxVuPNYqDw4BEde7Ivk3RkkUlNHWRPHZPIrmucDvt/GMgng=@lists.xenproject.org X-Gm-Message-State: AFuF++nv5NS0Wivv5o6fP411PVOGKZoB9ikMwAQp83jOUTa2GOgkAvpL 5VWBr/vFW91w/JmiIxsdE569id6dSFUwPsbh7m6Wn6SQ0U5Iua39iowx X-Gm-Gg: AYBFou3lnnkCxv99CoKAV3pi3zx0TUUfSSmAhe75GGhWaMdO6mG/BjnylBT7vGDUvUh 8i/zEwqZbjDmQQPvwohKMTFxh+ixfJWBCKkss6nxNksHmsNQuTWbkdtGXbwt3SgyzPE8rWnu05O 8r2Ta28Xmjh5lEPYPZJuWy1I+FtdAyPWlfWIknIuloE0Ce3jlM9MAo01s1p5hLx/XAnYsuuvcgz hBwwU0jrsaJFBAIxE3y1gJcVNIZ3rL5IBFpU+iBl64wUsDk9EsmwIAvYeKs8fZPlDvGPGEPWaSn mR3JeoNJJTyxURP/F/K+PFfeohYhICVLygg9xUsexvm61rnVJ7X3YGjWOvtofk4NYhzMhUlGhMg g2+Ce/DQjeMQBn+MhXowDfVRreHVamHpZ0i9NPyVUxmm4jwWdi1gcF6YZpXWEFIfhlNvJcIqj+Q JIqlcOmAbnVfaWbCXbmzNZiO2xLcuC8t/camNWH1x86FgWBj2l10uuw4O2zwsLe5x89RUr+by1m ivm9Q/3 X-Received: by 2002:a05:600c:698d:b0:49d:827:e5b6 with SMTP id 5b1f17b1804b1-49e7a68cc4cmr25373795e9.20.1789384524460; Mon, 14 Sep 2026 04:15:24 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 14:15:20 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Juergen Gross , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789384525-188C99EA-8840692F/0/0 X-purgate-type: clean X-purgate-size: 8932 On 9/14/26 12:10, Juergen Gross wrote: > On 26.08.26 06:57, Furkan Caliskan wrote: >> RTDS has no admission control: nothing stops the sum of all admitted >> units' (budget/period) reservations in a cpupool from exceeding >> what its pCPUs can actually provide. Once that happens, none of the >> EDF deadline guarantees this scheduler is built around still hold >> for the units sharing that pool. >> >> Introduce admission control to prevent this: reject a reservation >> whenever admitting it would push a cpupool's units over its capacity. >> Track a running utilization total per cpupool, and enforce it in >> rt_alloc_udata()/rt_free_udata(), the paired lifecycle hooks for a >> unit's creation and destruction. This catches the default >> period/budget every new unit gets. >> >> Utilization is represented as a fixed-point value: budget is >> left shifted by RTDS_UTIL_SHIFT (20 bits) and divided by period. >> A plain "(budget << RTDS_UTIL_SHIFT) / period" risks overflowing >> the multiply for large enough budgets. Rather than widen the >> arithmetic to tolerate any input, the input itself is bounded: >> rt_validate_params() rejects any budget above RTDS_MAX_BUDGET, >> chosen as the largest value that can be left-shifted by >> RTDS_UTIL_SHIFT without overflowing 64 bits, so the shift in >> rt_unit_utilization() can never overflow. >> >> A cpupool's capacity rt_utilization_cap() scales with the number of >> scheduling resources in it. It is calculated as: >> (number of sched_resources * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100), >> where RTDS_UTIL_CAP_PCT controls how much of that capacity can >> actually be reserved; at 100% (its current value), all of it can be. >> >> Signed-off-by: Furkan Caliskan >> --- >>   xen/common/sched/rt.c | 105 +++++++++++++++++++++++++++++++++++++++++- >>   1 file changed, 104 insertions(+), 1 deletion(-) >> >> diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c >> index 0e9f04ea72..9126320801 100644 >> --- a/xen/common/sched/rt.c >> +++ b/xen/common/sched/rt.c >> @@ -114,6 +114,24 @@ >>    */ >>   #define RTDS_MAX_PRIORITY_LEVEL (~0U) >>   +/* >> + * Fixed-point scale for utilization (budget/period) >> + */ >> +#define RTDS_UTIL_SHIFT     20 >> +#define RTDS_UTIL_SCALE     (1ULL << RTDS_UTIL_SHIFT) >> + >> +/* >> + * Largest budget safe to left-shift by RTDS_UTIL_SHIFT without >> + * overflowing 64 bits. Enforced in rt_validate_params(). >> + */ >> +#define RTDS_MAX_BUDGET_BITS  (64 - RTDS_UTIL_SHIFT) >> +#define RTDS_MAX_BUDGET       ((1ULL << RTDS_MAX_BUDGET_BITS) - 1) >> + >> +/* >> + * % of a cpupool's sched_resource capacity admitted units may sum up to. >> + */ >> +#define RTDS_UTIL_CAP_PCT   100 >> + >>   /* >>    * UPDATE_LIMIT_SHIFT: a constant used in rt_update_deadline(). When finding >>    * the next deadline, performing addition could be faster if the difference >> @@ -195,6 +213,9 @@ struct rt_private { >>       struct list_head replq;     /* ordered list of units that need replenishment */ >>         cpumask_t tickled;          /* cpus been tickled */ >> + >> +    /* Sum of admitted units' (budget/period), scaled by RTDS_UTIL_SCALE */ >> +    uint64_t utilization; >>   }; >>     /* >> @@ -635,6 +656,54 @@ replq_reinsert(const struct scheduler *ops, struct rt_unit *svc) >>           set_timer(&rt_priv(ops)->repl_timer, rearm_svc->cur_deadline); >>   } >>   +/* >> + * budget << RTDS_UTIL_SHIFT can't overflow: rt_validate_params() >> + * caps budget at RTDS_MAX_BUDGET. period == 0 means "no >> + * reservation" (a unit being removed), not an error. >> + */ >> +static uint64_t >> +rt_unit_utilization(s_time_t period, s_time_t budget) >> +{ >> +    if ( period <= 0 ) >> +        return 0; >> + >> +    return ((uint64_t)budget << RTDS_UTIL_SHIFT) / (uint64_t)period; >> +} >> + >> +/* >> + * Utilization capacity of the cpupool domain d resides in. >> + */ >> +static uint64_t >> +rt_utilization_cap(const struct domain *d) >> +{ >> +    unsigned int cpus = cpumask_weight(cpupool_domain_master_cpumask(d)); >> + >> +    return (uint64_t)cpus * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100; >> +} >> + >> +/* >> + * Replaces a unit's reservation and updates prv->utilization >> + * to match. Growth that would push utilization over the >> + * cpupool's cap is refused. Removing a unit or shrinking >> + * a unit's reservation always succeed. >> + */ >> +static int >> +rt_admission_test(struct rt_private *prv, const struct domain *d, >> +           s_time_t old_period, s_time_t old_budget, >> +           s_time_t new_period, s_time_t new_budget) > > I think the function name isn't appropriate. The function doesn't test only, it > is setting the utilization, too. > > What about rt_try_set_utilization() instead? And make the return type bool > (true on success). > >> +{ >> +    uint64_t old_util = rt_unit_utilization(old_period, old_budget); >> +    uint64_t new_util = rt_unit_utilization(new_period, new_budget); >> +    uint64_t total    = prv->utilization - old_util + new_util; >> + >> +    if ( new_util > old_util && total > rt_utilization_cap(d) ) >> +        return -EINVAL; >> + >> +    prv->utilization = total; >> + >> +    return 0; >> +} >> + >>   /* >>    * Pick a valid resource for the unit vc >>    * Valid resource of an unit is intesection of unit's affinity >> @@ -864,6 +933,7 @@ rt_free_domdata(const struct scheduler *ops, void *data) >>   static void * cf_check >>   rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>   { >> +    struct rt_private *prv = rt_priv(ops); >>       struct rt_unit *svc; >>         /* Allocate per-UNIT info */ >> @@ -881,9 +951,30 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>       __set_bit(__RTDS_extratime, &svc->flags); >>       svc->priority_level = 0; >>       svc->period = RTDS_DEFAULT_PERIOD; >> + >>       if ( !is_idle_unit(unit) ) >> +    { >> +        unsigned long flags; >> +        int rc; >> + >>           svc->budget = RTDS_DEFAULT_BUDGET; >>   +        spin_lock_irqsave(&prv->lock, flags); >> +        rc = rt_admission_test(prv, unit->domain, 0, 0, >> +                                svc->period, svc->budget); >> +        spin_unlock_irqrestore(&prv->lock, flags); >> + >> +        if ( rc ) >> +        { >> +            printk(XENLOG_WARNING >> +                   "RTDS: ADMISSION CONTROL: refusing unit %u of d%d," >> +                   " would exceed utilization capacity of the cpupool\n", >> +                   unit->unit_id, unit->domain->domain_id); >> +            xfree(svc); >> +            return NULL; >> +        } >> +    } >> + >>       SCHED_STAT_CRANK(unit_alloc); >>         return svc; >> @@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>   static void cf_check >>   rt_free_udata(const struct scheduler *ops, void *priv) >>   { >> +    struct rt_private *prv = rt_priv(ops); >>       struct rt_unit *svc = priv; >>   +    if ( svc && !is_idle_unit(svc->unit) ) >> +    { >> +        unsigned long flags; >> + >> +        spin_lock_irqsave(&prv->lock, flags); >> +        rt_admission_test(prv, svc->unit->domain, >> +                           svc->period, svc->budget, 0, 0); > > This use case clearly shows you are not only testing. :-) > >> +        spin_unlock_irqrestore(&prv->lock, flags); >> +    } >> + >>       xfree(svc); >>   } >>   @@ -1389,7 +1491,8 @@ rt_validate_params(const struct xen_domctl_sched_rtds *rtds, >>       s_time_t b = MICROSECS(rtds->budget); >>         if ( p < RTDS_MIN_PERIOD || p > RTDS_MAX_PERIOD || >> -         b < RTDS_MIN_BUDGET || b > p ) >> +         b < RTDS_MIN_BUDGET || b > p || >> +         b > (s_time_t)RTDS_MAX_BUDGET ) >>           return -EINVAL; >>         *period = p; > > > Juergen > BTW, if the rt_admission_test() returns false in rt_alloc_udata(), vcpu_create() will fail too. This will cause the d->vcpu[i] to become null, and it will crash in sched_move_domain(). So to avoid the crash, this patch needs the v2 of my fix for that. https://lore.kernel.org/xen-devel/20260819051532.9197-2-frn1furkan10@gmail.com/ Juergen, what do you say to acking that v2 fix? Furkan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 11:22:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 11:22:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420799.1647020 (Exim 4.92) (envelope-from ) id 1x64lk-0005iW-HW; Mon, 14 Sep 2026 11:22:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420799.1647020; Mon, 14 Sep 2026 11:22:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64lk-0005iP-EP; Mon, 14 Sep 2026 11:22:40 +0000 Received: by outflank-mailman (input) for mailman id 1420799; Mon, 14 Sep 2026 11:22:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64lg-0005iG-Ul for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:22:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64le-00FVed-Kt for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:22:35 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7d8f7-2eae-0a2a0a5409dd-0a2a450ae968-10 for ; Mon, 14 Sep 2026 13:22:33 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7d8f8-f2d2-0a2a450a0019-d561b3389ac8-3 for ; Mon, 14 Sep 2026 13:22:33 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x64lG-001qu6-1K; Mon, 14 Sep 2026 13:22:09 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x64lE-005S9L-IM; Mon, 14 Sep 2026 13:22:09 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x64lE-00000001lBc-2bZU; Mon, 14 Sep 2026 13:22:08 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=2ydmnqg3HzMcYUZI2KHG3VyDjXAqFDQPhoUDoniAetY=; b=cy74yz1Y2/+YbLAzf8335Y1wM1 1qLgLIt0fU9HO16yeqOoAy75tO5s7AnypubeO87+oGmwMGKg6q/MUoFSq/tZGgTz3sgbEqxG4vc06 zP5qqCPG2YgXWFEm/jscvjKnYZqQADeVQe6vHEZwKPPqvss9nk2fDZVgKLv8YLmEjIjHVWeRlSwW2 WcYalKf39RPww+iHWTzwYX2w9xtZlPVx5pqbT5wAQEq6eQ1cloAxLY//PvcnaFRV8H/pR1T5tVApd 0JemAXv1ZInZf4KodOETfh6hsN1r8ePc9cSgp/7sirQgvLogFgLm4GzTF7q6H4HXrK+Il1qrPcrRb rLAiSyAQ==; MIME-Version: 1.0 Date: Mon, 14 Sep 2026 08:22:08 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() In-Reply-To: <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> Message-ID: <6113f06c790cfe1141d2dc09b68937b6@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-4011c0/1789384953-53AD4CFC-9956213B/0/0 X-purgate-type: clean X-purgate-size: 2518 On 2026-09-11 01:38, Borislav Petkov wrote: > On Sat, Aug 22, 2026 at 03:33:20PM -0300, Mauricio Faria de Oliveira wrote: >> diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h >> index 82eddfa2347b32b76c2ea9b85f005ca5416ac71f..2d9f3d4d63de6e721f275d9e80d372edbdfedf30 100644 >> --- a/arch/x86/include/asm/cpuid/api.h >> +++ b/arch/x86/include/asm/cpuid/api.h >> @@ -204,7 +204,7 @@ static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves) >> * from PVH early boot code before instrumentation is set up >> * and memcmp() itself may be instrumented. >> */ >> - if (!__builtin_memcmp(sig, signature, 12) && >> + if (!__inline_memcmp(sig, signature, 12) && > > Dunno, did you not think of simply doing it by foot and save yourself all > those gymnastics in patches 1-3? In the review of the original patchset (fixed by this series) it is mentioned that a compiler might turn it into a memcmp() [1] -- and thus revert back to the same issue. [1] https://lore.kernel.org/all/877ccz12ab.ffs@tglx/ Thanks, > > IOW, something like this totally untested thing below: > > diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h > index 2d9f3d4d63de..a2db83d17940 100644 > --- a/arch/x86/include/asm/cpuid/api.h > +++ b/arch/x86/include/asm/cpuid/api.h > @@ -192,9 +192,10 @@ static __always_inline bool cpuid_function_is_indexed(u32 function) > #define for_each_possible_cpuid_base_hypervisor(function) \ > for (function = 0x40000000; function < 0x40010000; function += 0x100) > > -static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves) > +static inline u32 cpuid_base_hypervisor(const char *__sig, u32 leaves) > { > u32 base, eax, signature[3]; > + u32 *sig = (u32 *)__sig; > > for_each_possible_cpuid_base_hypervisor(base) { > cpuid(base, &eax, &signature[0], &signature[1], &signature[2]); > @@ -204,9 +205,12 @@ static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves) > * from PVH early boot code before instrumentation is set up > * and memcmp() itself may be instrumented. > */ > - if (!__inline_memcmp(sig, signature, 12) && > - (leaves == 0 || ((eax - base) >= leaves))) > - return base; > + if (sig[0] == signature[0] && > + sig[1] == signature[1] && > + sig[2] == signature[2]) { > + if (leaves == 0 || ((eax - base) >= leaves)) > + return base; > + } > } > > return 0; -- Mauricio From xen-devel-bounces@lists.xenproject.org Mon Sep 14 11:30:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 11:30:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420810.1647030 (Exim 4.92) (envelope-from ) id 1x64t2-0007Xa-7X; Mon, 14 Sep 2026 11:30:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420810.1647030; Mon, 14 Sep 2026 11:30:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64t2-0007XT-50; Mon, 14 Sep 2026 11:30:12 +0000 Received: by outflank-mailman (input) for mailman id 1420810; Mon, 14 Sep 2026 11:30:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64t0-0007XM-GE for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:30:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64sz-009dls-Sn for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:30:09 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7dab9-8faa-0a2a0a5109dd-0a2a4506ed5a-20 for ; Mon, 14 Sep 2026 13:30:09 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7dac1-195a-0a2a45060019-4a7de14caf0d-3 for ; Mon, 14 Sep 2026 13:30:09 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356256so659206f8f.1 for ; Mon, 14 Sep 2026 04:30:09 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e7a29826fsm53654545e9.4.2026.09.14.04.29.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 04:30:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789385409; x=1789990209; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1bOKvzJnepd9EkMxCuCxlztqYz1GKXLQzRt0L94g7yA=; b=OL9PUicU9f7BruoV9veTOIk+dYJEmFekCbQqhuAty7RRWgBnXlFWNnJjSxwfiq7AmT oje1F2RPFkAyavRwqwn3jGegcxmNS3dROjrTIFuB+ik4xkicpnzz7jqo2FX17vz4l3vt uZ8MVX5VYI5s6XqnoQZfcXg327gQVca0QlHdLcLJBd+l7f/M3JaJN4GJ6NQYgBYeQPQU YMIdZRE9/nl/VHS9QIrTATpMaoedYO3KTazVQM4n9CZ7d359mfBKweRDf17coQxV0YL0 o/IqRCCqvDWwGe4fqkVH6PF/GfVakadf7bTZ53CaySXfCWwDFGlZBDgUKk073VeO0bgF 4NPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789385409; x=1789990209; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=1bOKvzJnepd9EkMxCuCxlztqYz1GKXLQzRt0L94g7yA=; b=HQF6nW7LQ+vdOxI9HCj3qE8RqSWIku81s09P60TM5fDzVSfjGb+cmZh+3u1tOSAu3F t9KX+mti7/Owiuatw3hNx8isovXpfTqszQO77AUHhYG7mpZKiwvgEOGbXPSNqiNdqMON 6S94y8P5V3ZkRAamBlA3lS3Q4shoy1j5A2oIlGHfEy3Q5YoiLJ5/XZGBVKggifXFzA8T xPUV+DJPTId5Migs7lRtvAeUCe6Nf3APvU303YxyQ+Sv2MhG5RntWaWXiiF5Z9MfzErI S9XTCghhUsc0/uoEny3x70fLvxGxmyJf9nRMN/eGYmRHuj3LpKtF9D7IaRVZ889MK7p8 ilrg== X-Forwarded-Encrypted: i=1; AKwUvBzVo43QgQVPTGrl+EPqkjWrFlDWzeXXWm6regfk9HGIjfN84HAT88CIFRArq/tdAnQItz9khw1rbZk=@lists.xenproject.org X-Gm-Message-State: AFuF++lsY8boVHXwB/oVOUKhNCOWwISp5S5MKtKMrCN+xIh/EFrjnVOI xjMZQvOsh9g5vyutqp837aKoNhJQhmeoh7QuuWg1m3nG/XnMWDy/WjT4S36ontnG1w== X-Gm-Gg: AYBFou2gFEZs1jj2GtCDG0vLj0N5/8N7H0OHPQOqSqgVTPzDX8+l94MZmGu1vuh0WH7 moRWoiOzEpv/cEJve538ozAuF1cn6FEV/HLK/ErRuaNX3qYwRcp8O6z3ZqQkD59NaQkyqUsxRlw IQpCWjvqGb21cvOMmLMObQhfiLEOAA/3FtpF7kvg+ZpuU9xla+wFuoLdNI3+S/d61/heP5cudO3 vNh2M+BQR//3nyMFu0mamgKPa8QvUm6wL/UZFCBuZcPmSVpm5v9/TrK1T/hbVCYQxxqGbYNq0KM iWBWLzM/2IbvQ5rgpVMOUkEjHgbdutwzyPhlS/sVsaRw+x1KZ9ZC8x++fAm5tDfgNVG/IbYwuIQ ApQkSKWrcgMYnM1LgDLZu+f4J06p3Gzhy2SnfTdRoB6aKIVH6wghxhbE6Qi2fZRVIFo7ZjLZJBG bqSclKRYDg6IsqLrttI9gSoHPnLpHimZVI6/Jz5uM82qHVmSi37o4Cu10/q5gWqUW4XCobTL5t2 0LDMPNSHQVnb1oAB+VOb0Y= X-Received: by 2002:a05:600c:6383:b0:49e:715d:95ca with SMTP id 5b1f17b1804b1-49e7a67e134mr23957095e9.13.1789385408763; Mon, 14 Sep 2026 04:30:08 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 13:29:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen/sched: rtds: add global-EDF utilization admission control To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= Cc: andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com, xen-devel@lists.xenproject.org, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-2-frn1furkan10@gmail.com> <371537bb-7c12-4630-bb1f-57e301b1fbf2@suse.com> <325f2b44-ea61-45e8-a681-c0bb08d5766a@suse.com> <6fc3aa29-f6b5-43fd-893c-f4cbab0b5c84@suse.com> <67395a7d-ccd7-41a3-a925-8679e5d37911@suse.com> <85e6a89a-edc4-4d2e-9d75-5933af44f7fc@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <85e6a89a-edc4-4d2e-9d75-5933af44f7fc@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1789385409-F7ACA77B-9F9E19AA/0/0 X-purgate-type: clean X-purgate-size: 1561 On 14.09.2026 12:34, Furkan Çalışkan wrote: > > On 9/14/26 12:45, Jan Beulich wrote: >> On 14.09.2026 11:33, Jürgen Groß wrote: >>> On 14.09.26 11:13, Jan Beulich wrote: >>>> On 14.09.2026 11:10, Juergen Gross wrote: >>>>> On 26.08.26 06:57, Furkan Caliskan wrote: >>>>>> @@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) >>>>>> static void cf_check >>>>>> rt_free_udata(const struct scheduler *ops, void *priv) >>>>>> { >>>>>> + struct rt_private *prv = rt_priv(ops); >>>>>> struct rt_unit *svc = priv; >>>>>> >>>>>> + if ( svc && !is_idle_unit(svc->unit) ) >>>>>> + { >>>>>> + unsigned long flags; >>>>>> + >>>>>> + spin_lock_irqsave(&prv->lock, flags); >>>>>> + rt_admission_test(prv, svc->unit->domain, >>>>>> + svc->period, svc->budget, 0, 0); >>>>> >>>>> This use case clearly shows you are not only testing. :-) >>>> >>>> Yet at the same time ignoring possible errors. >>> >>> I don't see how this could happen, as new_period and new_budget are both 0 here. >> >> Okay, that's simply entirely invisible here. So before freeing the two >> items are somehow zeroed? > > Can you please clarify what do you mean here? Confusion on my part: I assumed talk was of the two svc-> values being passed, but those are "old". "new" are the two uncommented literal zeroes. Leaving them uncommented may be okay here; to me that's almost like uncommented literal "true" / "false" somewhere. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 11:37:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 11:37:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420821.1647039 (Exim 4.92) (envelope-from ) id 1x64zv-00088f-UM; Mon, 14 Sep 2026 11:37:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420821.1647039; Mon, 14 Sep 2026 11:37:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64zv-00088Y-RU; Mon, 14 Sep 2026 11:37:19 +0000 Received: by outflank-mailman (input) for mailman id 1420821; Mon, 14 Sep 2026 11:37:17 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64zt-00088S-NR for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:37:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64zt-00FYc8-3s for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:37:17 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7dc6b-e002-0a2a0a5209dd-0a2a450a9e0e-6 for ; Mon, 14 Sep 2026 13:37:16 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7dc6c-f2d2-0a2a450a0019-4a7de18da069-3 for ; Mon, 14 Sep 2026 13:37:16 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7acdc816so1832305e9.1 for ; Mon, 14 Sep 2026 04:37:16 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e7548d99bsm145609395e9.1.2026.09.14.04.36.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 04:37:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789385836; x=1789990636; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=NzjcLEEHu0Z2onF46QZZ6heVSjqtGQIl7AQjZEemKSU=; b=IJwegXYwzDHN4BdpZMsCDDhtHpbjitqr/Dil/chBknPgRLSr+6tUa4eKGBqWwmu98k JoMt7JGAGmAFiTankQxTqUMI9Fhyd4JOnc/A4spNPjqkXADwFc9i9orP9Ij040GSQlDb gpMPw0BlBRO6+q1vCe02/otnC72G1an4R5b3hZYb8Pp1ZxHWHGM9Iged/q6UF0HSfD2a VYV42kw/wdHD2yxal9JLuq3pt9NHcDxZjxnUMhP0Jm50nDot255BpRFinuiVLrSNAaeD 2qXCnAYsnASLglXWToQ2PHC7WYCueCkGBWTa2wyPp7zCgpnmb3xx0Syd39s+rz2cwQjY EKOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789385836; x=1789990636; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=NzjcLEEHu0Z2onF46QZZ6heVSjqtGQIl7AQjZEemKSU=; b=EMnn9Y5iO+TFBCOVar+VhZzhqbNv5q0QHr/mlWBanjd4SQnocPi0ltZJwidxu1FNcu Ul+nTV16eUyojIcHzCT4l5Pu4+OOqAkvyGf2hySMWThCc/pP+acN9FAaPubQAku6Ajf3 KLBBgWMJvpnaGX31OwR/szvJl0moSi2ts/3lSCb4+P7w9UaZrSXWtBRnWPTCbchOsHUK ny23qWj4vk+jg7LXR+2kMZD6vtM0a1odttDGe6uZQ6eh97msobNV6AUG7wByIeWb+9ii taeym7iWkGGt0y4biJCWEFBbLHW0O2ctC3wupMb4xI+scDL7nkt9V+TULDS+/oKYk1eW ZjWA== X-Forwarded-Encrypted: i=1; AKwUvBycKhljzxZKW7Qx6cXzacZecmQyKw/RQHfYQmBPqVoHof3tWaeGj4RnH2IoGJvhx+hl33HxVH0DxDA=@lists.xenproject.org X-Gm-Message-State: AFuF++ngoCMWc0hPsItNlizhmhvMl6Cgpku1bDfJCmpiKO8Z9gEH/7rF i0XHNFhzueocVIBj+OrGMPIKD99rZvTE5INl1nJXtmA2R7hi6EEBHU/k6lJatIBiVw== X-Gm-Gg: AYBFou0VpKRjqLMphNWxeWQir3SLLsHbhC8IiLRBQL2M1gj2X6Jh2s4+8P29nWk9uQE 2iNWbFPLU+3GH3M6fKXhzuwx2kWAld5wa0fuIFnpkJMi4UD4kcJGSel7hW7J/tFO9stiwrgQvNg SglIT3fYHyykgGeDsOotMgJnd50QYpFrGHfuvBYORKc0tiebfNnY96V1MpXV9m0SZYHJYlImp8e KwjMpl5XD13ZbTXT2W+PniimGyn9c7Cuaz3azBhTn4IkTYpWyBejoVxPW6z+/awf+VGwxjPfF8T 4gY3LAYzra69MP3MC71nnhyCT2s8bPMbQldAjYOJsJEZGXzApYmU5S3vH363byk9Wz0qYUSM9Qe n6dIi4pz/vOzWXjK75N7wcuJFSOm8t3y94aWHHGItvVBmbh0F9syPDry0URSdjlVz1qqvSRaPxB iLDuLA73Sp9fEwPUwwFR65OTZq09oAzTaPOLwQOfE8GFCJXNV9KKUh/FgIBYyqm1itoZUFv6uXO mh0851KAl6c X-Received: by 2002:a05:600c:8705:b0:49c:f13e:e4d with SMTP id 5b1f17b1804b1-49e7a678639mr24802965e9.10.1789385835828; Mon, 14 Sep 2026 04:37:15 -0700 (PDT) Message-ID: <3e05825b-9762-4fba-a064-821bd3d7f8d6@suse.com> Date: Mon, 14 Sep 2026 13:36:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 16/20] xen/riscv: implement IRQ routing for device passthrough To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Alistair Francis , Connor Davis , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789385836-4BCD3CFC-F442B5EF/0/0 X-purgate-type: clean X-purgate-size: 3044 On 14.09.2026 12:54, Oleksii Kurochko wrote: > On 9/10/26 2:53 PM, Jan Beulich wrote: >> On 09.09.2026 17:07, Oleksii Kurochko wrote: >>> --- a/xen/arch/arm/irq.c >>> +++ b/xen/arch/arm/irq.c >>> @@ -205,7 +205,7 @@ void __init init_IRQ(void) >>> static inline struct irq_guest *irq_get_guest_info(struct irq_desc *desc) >>> { >>> ASSERT(spin_is_locked(&desc->lock)); >>> - ASSERT(test_bit(_IRQ_GUEST, &desc->status)); >>> + ASSERT(desc->status & IRQ_GUEST); >>> ASSERT(desc->action != NULL); >>> >>> return desc->action->dev_id; >> >> Why did an Arm change slip into a RISC-V patch? > > Considering that this code is executed under the spinlock it is fine to > not use test_bit() so it is part of dropping of bitops functions. Perhaps, but then in a separate patch and changing all places consistently (I didn't go check, but I'm pretty sure there are more). >>> --- a/xen/arch/riscv/aplic.c >>> +++ b/xen/arch/riscv/aplic.c >>> @@ -325,9 +325,40 @@ static const hw_irq_controller aplic_xen_irq_type = { >>> .set_affinity = aplic_set_irq_affinity, >>> }; >>> >>> +static unsigned int cf_check aplic_guest_irq_startup(struct irq_desc *desc) >>> +{ >>> + BUG_ON("unimplemented"); >>> +} >>> + >>> +/* >>> + * Shared by ->shutdown(), ->enable(), ->disable() and ->end(), which have >>> + * no state. >>> + */ >>> +static void cf_check aplic_guest_irq_stub(struct irq_desc *desc) >>> +{ >>> + BUG_ON("unimplemented"); >>> +} >>> + >>> +static void cf_check aplic_guest_set_irq_affinity(struct irq_desc *desc, >>> + const cpumask_t *mask) >>> +{ >>> + BUG_ON("unimplemented"); >>> +} >>> + >>> +static const hw_irq_controller aplic_guest = { >>> + .typename = "aplic", >> >> This is indistinguishable from aplic_xen_irq_type. Naming of both variables >> also isn't consistent > > I will align names properly: > > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -316,8 +316,8 @@ static void cf_check aplic_set_irq_type(struct > irq_desc *desc, > spin_unlock(&aplic.lock); > } > > -static const hw_irq_controller aplic_xen_irq_type = { > - .typename = "aplic", > +static const hw_irq_controller aplic_host_irq_type = { > + .typename = "aplic-host", > .startup = aplic_irq_startup, > .shutdown = aplic_irq_disable, > .enable = aplic_irq_enable, I'm not convinced this one is needed. > @@ -345,8 +345,8 @@ static void cf_check > aplic_guest_set_irq_affinity(struct irq_desc *desc, > BUG_ON("unimplemented"); > } > > -static const hw_irq_controller aplic_guest = { > - .typename = "aplic", > +static const hw_irq_controller aplic_guest_irq_type = { > + .typename = "aplic-guest", > .startup = aplic_guest_irq_startup, > .shutdown = aplic_guest_irq_stub, > .enable = aplic_guest_irq_stub, This one certainly is. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 11:41:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 11:41:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420829.1647048 (Exim 4.92) (envelope-from ) id 1x653c-0001Mc-DO; Mon, 14 Sep 2026 11:41:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420829.1647048; Mon, 14 Sep 2026 11:41:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x653c-0001MV-A3; Mon, 14 Sep 2026 11:41:08 +0000 Received: by outflank-mailman (input) for mailman id 1420829; Mon, 14 Sep 2026 11:41:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x653b-0001MP-28 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:41:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x653a-00GbBt-0s for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:41:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7dd48-e002-0a2a0a5209dd-0a2a4502d2b4-18 for ; Mon, 14 Sep 2026 13:41:05 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7dd4c-6ca4-0a2a45020019-d561b338e46a-3 for ; Mon, 14 Sep 2026 13:41:01 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x653A-001rT0-6p; Mon, 14 Sep 2026 13:40:39 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x6539-005UIG-0y; Mon, 14 Sep 2026 13:40:39 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x6539-00000001lUT-0Hp4; Mon, 14 Sep 2026 13:40:38 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=9CFOHjBOf3yPy/DhHAL3D16IeilqUND+JE3cSijaXso=; b=JzJ232aVCAQkvfcw/WMghan5vq 08b52hWMOrx42r7WC3jSHoFS1yHhbqL9lKT9J/QPQhqelN2/is/ODfaXEBRdK8XPwz4yTApOZKbZN BiUpi0ocDJOOmelexgUaly7bAyOBGChwGSQGNjvK969Z7lJqV6pPyaLef+6Uuf3nmAa2gxtDZ1A7T WbAeG6OnHTwb0k8wpO91bY68H49ewXJqnKlHqChvO+zFKagBuk+UfOVXHPirjzmlnZJ5UcBSpJoaM unHkgbvEsQ35c3YMnzHFvPUcVGmQ0b8RSWU3EYJ7shFJRnpR9LqH9hBtetoiaLqWP1WjrxmbKiAQb Zw5BBrWQ==; MIME-Version: 1.0 Date: Mon, 14 Sep 2026 08:40:38 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 5/5] x86/pvh: fix unbootable VMs by really inlining memset() in xen_prepare_pvh() In-Reply-To: <20260911043947.GIaqOGE9DFCHWwc6Ys@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-5-e70ef3b75b6a@igalia.com> <20260911043947.GIaqOGE9DFCHWwc6Ys@fat_crate.local> Message-ID: X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-720697/1789386061-315CD2AC-2C5EE642/0/0 X-purgate-type: clean X-purgate-size: 1903 On 2026-09-11 01:39, Borislav Petkov wrote: > On Sat, Aug 22, 2026 at 03:33:21PM -0300, Mauricio Faria de Oliveira wrote: >> Even with __builtin the compiler may decide to use the out of line function >> instead of the inline implementation. >> >> This particular one (still) generated the inline implementation as expected >> (at least in these compiler versions) but this is not guaranteed to remain. >> >> Switch the builtin to the inline implementation to address it. >> >> Fixes: fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()") >> Signed-off-by: Mauricio Faria de Oliveira >> Reviewed-by: Juergen Gross >> --- >> arch/x86/platform/pvh/enlighten.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c >> index f2053cbe9b0ce3d2178938269607c652ae8f528e..cb442cbd9d828619421babb281bfe9759edbca8a 100644 >> --- a/arch/x86/platform/pvh/enlighten.c >> +++ b/arch/x86/platform/pvh/enlighten.c >> @@ -8,6 +8,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> >> @@ -129,7 +130,7 @@ void __init xen_prepare_pvh(void) >> * This must not compile to "call memset" because memset() may be >> * instrumented. >> */ >> - __builtin_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams)); >> + __inline_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams)); >> >> hypervisor_specific_init(xen_guest); >> >> >> -- > > Why is this a separate patch from 4/5 if it is fixing the same thing? Due to scope and review purposes (4/5 is more generic, 5/5 is specific to PVH). If there's a strong preference to combine these, please just let me know. Thanks, -- Mauricio From xen-devel-bounces@lists.xenproject.org Mon Sep 14 11:48:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 11:48:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420840.1647057 (Exim 4.92) (envelope-from ) id 1x65At-0002Eb-3B; Mon, 14 Sep 2026 11:48:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420840.1647057; Mon, 14 Sep 2026 11:48:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65At-0002EU-0L; Mon, 14 Sep 2026 11:48:39 +0000 Received: by outflank-mailman (input) for mailman id 1420840; Mon, 14 Sep 2026 11:48:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65As-0002EO-EI for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 11:48:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x65Ar-0017U7-Cm for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:48:37 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7df0d-bab6-0a2a0a5309dd-0a2a450599f8-22 for ; Mon, 14 Sep 2026 13:48:37 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7df15-4cb1-0a2a45050019-4a7de48cddef-3 for ; Mon, 14 Sep 2026 13:48:37 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254fa4c24cso262570666b.2 for ; Mon, 14 Sep 2026 04:48:37 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c29660219ecsm413939866b.16.2026.09.14.04.48.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 04:48:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789386517; x=1789991317; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6xL0QViIq8WveYbpgruXyAkwKN3bOGAOjj8sghQlhHo=; b=ejeq5xC7KrYyjj0Vk23l1hhAnLtHtfK0uLiX3F9zJWjNGOtXJb5rVKAJgHezm1PiM4 X8w/90LzRTF3KmoH7JHgKTGvNEwuDqE4V+vnx8SUKfJti3fUvOSu2e3y7UTofzvD0/5l j73n5T0haePBNCIr2z0+D5MprhblAHdC3RPZqVVDpIiLP4P7fM9NZwFbFtBRn37hkJ9D +aY4AJwSxE9MBNDDC4lyW/PSlF9lhTnmFfwLRQZB2Q3ylTb9l28kLF8h/bihf+2R7f5A vvAGHLO4Mw51WS39mV6G3ELLhygc4cLIH8E8npjaYhMjRkqDwfMsr/NqGIWf55R4wqhc UViQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789386517; x=1789991317; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=6xL0QViIq8WveYbpgruXyAkwKN3bOGAOjj8sghQlhHo=; b=LtgyDlnMsbZ6z8doyyomZrXnS0YV9IyKk53Xk72QSlMB/5zV9UE+/LzzhrKMq6O1T1 LzSCovFx2BBHM1+kAMODpY0Jj9YPGxevxAVx1W+2qUAFkxMu8ep2DDPHlyY/8XqWSO7L jDSd+wqYnpAEDW9UqEpyvD22QF37pti+iPtLkq92LXycf+KsUV2xj2bsHuvRBdG3bIRt QaFMoqGDZ6WVIignghkGmJ6ZTzFYExr84FJHZ0EYOZ6tV/mU0r2a0KDGJwikqC3Us+bH 1NJH4zB8SRPBzqHZjChNMYn/2EfOUFqnalJ2sK30jdtFwkcZEw0bo6/oGRRsTyQ4Js9/ NbsA== X-Forwarded-Encrypted: i=1; AKwUvByoBovO2T2fIWcMtP4aqm+qmS8vgVv1w1ZujPtNwcYUwoVpGlwGU8iLl5wd+C6MuD1jHnsB3uk7gTM=@lists.xenproject.org X-Gm-Message-State: AFuF++lrfR/T+9Ii8m677dGS47hHTWe01C1K5HcxFpr1P8zW6NbItYPU tN3h4j79ipXeiYP77riX732U0FX5lMn0dI+ILWefS9LE+nmAkwOjpcHk+AUZF6hPOA== X-Gm-Gg: AYBFou3EbdzL70W8HL7eZmrQVD43Fm850ODMkVex/QloAm2OTlND3FKPTG21uLEn0lQ dnlCtRZFvMoyJaCFCslUPyjE6a+ZAQ1jRtDL6Af9+8+t6whivPf+Jsq3mBB3OvEN1xDnfRmoUF2 VeXEy0dc1ra5G2QGsRKXA62K+WWBMTcOQAdcZpzcFFVNoAF8hP0phEm4QVD4L70IqH0sXe5/GB6 GgNrJaO0Su6qR/7I1JgS3iRL1US1nVvcYuGIqd/ZI+1ONrbbHyWwldtiRmQU4XeGoNN5pcMsiPV QmKjcqv40v+t1QVjFB5EpA0IEM2kpyJue1JpIrauNioNe8eZfDyPlWTR7ylLMJl57ZQB+wZkF6c LzSLeC64A/KnUPsRQr719FAtP+Cm0TTLgntDVMhFDZA/mhzBFxb8CCx8fRQHMB5Wds9vkaDopsO F0Q1WUuSn/srkl4JdYDoqKYq4x/5RdtstvV821cMm3YC2fDwzVQ8Hh5ikKzKCCO6Vxm2Dq/ePK7 hNtVnHkeGrxhYqefpWQ2fc= X-Received: by 2002:a17:907:9806:b0:c29:4503:35a9 with SMTP id a640c23a62f3a-c29b874b239mr138933466b.44.1789386516719; Mon, 14 Sep 2026 04:48:36 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 13:48:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 25/39] xen/riscv: add guest load emulation for trapped MMIO accesses To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7cf3203f8f826eefa1b24bb2dedbd76c0b611dc1.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <7cf3203f8f826eefa1b24bb2dedbd76c0b611dc1.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789386517-71CA82A1-DB2C0647/0/0 X-purgate-type: clean X-purgate-size: 1707 On 27.08.2026 17:21, Oleksii Kurochko wrote: > @@ -419,7 +416,41 @@ static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di, > > static int emulate_load(const struct guest_fault *gf) > { > - return -EOPNOTSUPP; > + struct cpu_user_regs *regs = gf->regs; > + mmio_info_t info = { .is_write = false }; > + struct decoded_insn di; > + unsigned int shift = 0; > + int rc; > + > + /* A fault taken re-reading the instruction is redirected to the guest. */ > + if ( insn_fetch_faulted(gf, &di) ) > + return 0; > + > + if ( !decode_ldst_insn(&di, guest_xlen(regs)) || di.is_write ) > + return -EOPNOTSUPP; > + > + if ( !di.is_unsigned ) > + shift = BITS_PER_BYTE * (sizeof(unsigned long) - di.len); This is one of the cases where sizeof() is not only unclear to read, but actively risky: Which variable(s) of that type does this refer to? What if those variable(s)' type(s) change? Aha, ... > +#ifdef EMULATE_LOAD_DEBUG > + gdprintk(XENLOG_DEBUG, "pc=%#lx, addr=%#"PRIpaddr", len=%u, shift=%u\n", > + regs->sepc, gf->gpa, di.len, shift); > +#endif > + > + rc = do_mmio(&info, gf->gpa, di.len); > + if ( rc ) > + return rc; > + > + /* > + * A load into x0 discards its result: writing regs->zero would break the > + * invariant that it reads as zero when x0 is a source operand elsewhere. > + */ > + if ( di.reg ) > + *guest_gpr(regs, di.reg) = (long)(info.data << shift) >> shift; ... you apparently mean sizeof(info.data) there. The comment is (nit) also too long for my taste. Everything from the colon onwards is imo redundant. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 12:02:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 12:02:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420853.1647065 (Exim 4.92) (envelope-from ) id 1x65No-0005nJ-64; Mon, 14 Sep 2026 12:02:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420853.1647065; Mon, 14 Sep 2026 12:02:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65No-0005nC-3U; Mon, 14 Sep 2026 12:02:00 +0000 Received: by outflank-mailman (input) for mailman id 1420853; Mon, 14 Sep 2026 12:01:59 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65Nn-0005n6-5B for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:01:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x65Nm-00DDDc-3i for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:01:58 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7e22c-e002-0a2a0a5209dd-0a2a4505cfb6-10 for ; Mon, 14 Sep 2026 14:01:54 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7e231-4cb1-0a2a45050019-4a7de44c982a-3 for ; Mon, 14 Sep 2026 14:01:53 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a67fa7a64eso3480497a12.1 for ; Mon, 14 Sep 2026 05:01:53 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a9b592470asm4090703a12.17.2026.09.14.05.01.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 05:01:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789387313; x=1789992113; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=cN8ZWLGPIppK8G01ukyR0GIEK59bBmRpRoiq2Sd2cTU=; b=JeyZXgSBKjvsuMmyPCyydbOqjMyyOkuOAQO4Be1Vu7m4g1AxGgCmz+wZ0PSJrbt1do P0z95jQpPmrQRKiDJjSto+w6ELzPqSi6wz8IWfKjBYLjSupMiY8zPkWOQTnp7WMaQmHH 16KJvcRZqjMLzn1Z1AMolSL+niK0BJsZ3W3YA1Dy7G9w1/r/4DTEc1g44mkD9Hz6+3Fg rKimVzvbM+K6VB8jZOAoQXRmSwtWyQ/YZt681QSel3lw/ed+AUpPjfPih/hYQwRJyUz4 1hvcRSGQ2Vx/q91Xpl3cooLWXBCv8KmmfExh3fZgJAYRDXHOf2n9bpwN1K8nVvkgkCWC GwpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789387313; x=1789992113; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=cN8ZWLGPIppK8G01ukyR0GIEK59bBmRpRoiq2Sd2cTU=; b=k6a2LkYkJFrNdjn4Yh7kKe96L51L0Mxv0iYPW/8lzaotqU9dr73ysG3xNfXyzpNUtO vH7TFbqCtGPSN6L5uZsedTyngOoWb4TPqK8WJCGjYFPDLNOaHwwZ+jgmjLTBNVqJHDKG HbmlAkz50nvPSnjM0gFQSn4NZjDudHCQR74qrn86D+K5V8XOP7GX3vdXVsSKRHLW76w5 Fj9ErmzwNV1LSE3+3DQ6S/Y9iO/jC3X5Aptnuu1aQQL56yNc6CcBZL5eWgbZ0XpIz+Lv NVrtqSj9kBWkx3PBvscLstU/sGS/6rM9evIQauZLJiFfzDU/pR1aZvOW45t+gV5LXHKM 6Udg== X-Forwarded-Encrypted: i=1; AKwUvBz+7wqOm1Jr6qAafN8zM8tdFag9tNjjbYGU6rmzPdkvpmOMiC5eM60iWdUORq5G0bj3qSzFm9ChlqM=@lists.xenproject.org X-Gm-Message-State: AFuF++l+I1UoGAcHolyK4/lpD685Wo66AmxvtA+psJ8IPYbfC9kJUs+g CO4be0jtvsrSd2moGvcQ/F6xhNrr8t1P03SB1vH+I5BvcEy2eNuOReYs1anNuxGeQw== X-Gm-Gg: AYBFou02l8Xn02R3BwxxckzxDLD3YlQQJRBgoqzqU6m3rdJduixrrwYhbgeRCJxUkDf GQTuuHBAAOsHAVB9fg5EenxR+VOOdyeDjnyqlmiWOzMB4VxguAXnnYLm7REE5tjSe+/YAiNnw/G OATjkZKyp0xoGaHSBOD3u05waV2/icME+CCRh78SGPPe20FOnEM/kfAyMwMdX1mm58RwZ7uSYhA ynSNkhISZ/pt8AdPF3IIMn9dectsmwQ9oME1TFtjFmO3d1bEI7BWUL1EBv1fcChO9lNd2BuK7oT tq/g3JlA2b7TySXAo8m016BI6/e5ldscVS/5bGQK7uVF4IktMhYo6FX9sPFFBBjlQsAGRqq8WP5 fX6HUusWVYfl8w3P7P8CtDJC5NN1o2awidmBnwA+5z4UfsRnKR29IOaiqFx9tOdOb4iRhsVgotW 2bk80oFCknBV/uDEu0Xke/G1LPo37uX7tSXMz13ynuT3/cq1BaDxR1puu7/aU1L00aDRzJpQ== X-Received: by 2002:a05:6402:46cc:b0:6a9:b3b0:6cf3 with SMTP id 4fb4d7f45d1cf-6a9f63dfcffmr1233556a12.34.1789387313182; Mon, 14 Sep 2026 05:01:53 -0700 (PDT) Message-ID: <9d4600c6-258e-4990-b1f1-3c86037227b3@suse.com> Date: Mon, 14 Sep 2026 14:01:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 26/39] xen/riscv: add guest store emulation for trapped MMIO accesses To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789387314-734BC2A1-7512F94A/0/0 X-purgate-type: clean X-purgate-size: 1110 On 27.08.2026 17:21, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/emulate.c > +++ b/xen/arch/riscv/emulate.c > @@ -453,9 +453,28 @@ static int emulate_load(const struct guest_fault *gf) > return 0; > } > > -static int emulate_store(struct guest_fault *gf) > +static int emulate_store(const struct guest_fault *gf) > { > - return -EOPNOTSUPP; > + struct cpu_user_regs *regs = gf->regs; > + mmio_info_t info = { .is_write = true }; > + struct decoded_insn di; > + int rc; > + > + if ( insn_fetch_faulted(gf, &di) ) > + return 0; > + > + if ( !decode_ldst_insn(&di, guest_xlen(regs)) || !di.is_write ) > + return -EOPNOTSUPP; > + > + info.data = *guest_gpr(regs, di.reg); This came to mind only here, but applies to the earlier patch as well: There's no checking of di.len, not even by an assertion. The above is fragile as to extensions like Zilsd. Zilsd itself may still be okay as the overrun of the register field will hit the correct one, but the general concern remains (plus of course that moving across fields is UB). Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 12:04:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 12:04:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420859.1647076 (Exim 4.92) (envelope-from ) id 1x65Q2-0006Qc-IK; Mon, 14 Sep 2026 12:04:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420859.1647076; Mon, 14 Sep 2026 12:04:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65Q2-0006QU-EQ; Mon, 14 Sep 2026 12:04:18 +0000 Received: by outflank-mailman (input) for mailman id 1420859; Mon, 14 Sep 2026 12:04:17 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65Q1-0006QL-Bq for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:04:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x65Q0-003d50-O7 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:04:16 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7e2bb-bab6-0a2a0a5309dd-0a2a4501dd68-26 for ; Mon, 14 Sep 2026 14:04:16 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7e2c0-5984-0a2a45010019-c387df82e1c6-3 for ; Mon, 14 Sep 2026 14:04:16 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C998C21CB3; Mon, 14 Sep 2026 12:04:07 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 220F513693; Mon, 14 Sep 2026 12:04:06 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 7pSXO7bip2ooAgAAD6G6ig (envelope-from ); Mon, 14 Sep 2026 12:04:06 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de"; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789387451; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=oGAjaTYW9+9pgn++AOoLz4Ni470k5ZTJydWoPlVjGtw=; b=s/8xx6Phz3C7iM/cwG9s8JXgPeKzTtz4W6E9+Uhp6s9Gs/q4fMObgrEZD/4NxhHiFsdcf2 ZM6Qh/tVSkNxYVtWGvCqBcxrhMdAFYPiSEMCYMZJMlDj0tz/5VUQ+bZH8pksfb2JVTG+5w FfgjqwkQnXAe+9Pxe4TxSaAh9X5JSww= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789387451; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=oGAjaTYW9+9pgn++AOoLz4Ni470k5ZTJydWoPlVjGtw=; b=2aIGkYQw+Hgr38Ip6uo267G6WZ91VP7Dxuxusffo6tKuVt3zNSusGXVLwZxJU/AZQyjlmC 6f5pD3OuLxnFrEAQ== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=Skls9UdH; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=VcjQ+Hdk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789387447; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=oGAjaTYW9+9pgn++AOoLz4Ni470k5ZTJydWoPlVjGtw=; b=Skls9UdHYfdXyf1+XvkwS6SIvprCy3p2rJCF1FKee5E3K2ZBAldyVbo19v4UyM2suOo0hX K1Un2SuqyTqASEvDn26RzJnN3TfWDLVGzrBodBbs+iYxanHJ5/zGZ4PWWdHYpkFSSMovwZ Rfv6uXQrwIIC4TLWe35YbO0yxYhEw08= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789387447; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=oGAjaTYW9+9pgn++AOoLz4Ni470k5ZTJydWoPlVjGtw=; b=VcjQ+HdkXxscPpMhk3xwqyl+LRC6Nrunw9/MnWxAoModxunwDKnTQyOJaYV9MteRSadyKe 8Hi/lZQaLkSsc5Bw== Message-ID: Date: Mon, 14 Sep 2026 14:04:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/8] drm: replace simple display pipe users with atomic helpers To: Ze Huang , Alexey Brodkin , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , Joel Stanley , Andrew Jeffery , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Linus Walleij , Hans de Goede , Alex Lanzano , Oleksandr Andrushchenko Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org References: <20260727-drm-simple-kms-removal-v3-0-cd5dc89858c6@oss.qualcomm.com> Content-Language: en-US From: Thomas Zimmermann Autocrypt: addr=tzimmermann@suse.de; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c= In-Reply-To: <20260727-drm-simple-kms-removal-v3-0-cd5dc89858c6@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: C998C21CB3 X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FREEMAIL_TO(0.00)[oss.qualcomm.com,synopsys.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch,jms.id.au,codeconstruct.com.au,nxp.com,pengutronix.de,epam.com]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_TWELVE(0.00)[22]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[qualcomm.com:email,suse.de:dkim,suse.de:email,suse.de:mid,suse.com:url,msgid.link:url,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Spam-Flag: NO X-Spam-Score: -3.01 X-purgate-ID: tlsNG-d62444/1789387456-1F063757-86B02AFF/0/0 X-purgate-type: clean X-purgate-size: 5711 Hi Am 26.07.26 um 21:45 schrieb Ze Huang: > struct drm_simple_display_pipe was meant to simplify simple DRM > drivers, but instead adds an extra wrapper around normal DRM atomic > helper setup. As noted in Documentation/gpu/todo.rst, remaining users > should be converted to regular atomic helpers and stop depending on the > simple-KMS interfaces. > > This series converts the following drivers: > > - arcpgu > - aspeed > - mcde > - repaper > - tve200 > - xen frontend For these drivers: Reviewed-by: Thomas Zimmermann I've taken the rest of the series into drm-misc-next. We had 2 drivers tested and the others are variants of the same. Best regards Thomas > > Each patch replaces drm_simple_display_pipe_init() with explicit > primary plane, CRTC and encoder setup, and moves the old simple-pipe > callbacks into regular plane and CRTC helper callbacks named according > to local driver conventions. > > The conversions preserve helper behavior that used to be implicit in > drm_simple_kms_helper.c, including plane-state validation, CRTC > primary-plane checks, affected-plane propagation, framebuffer prepare > handling, and existing event/vblank flow where applicable. > > Result is less helper indirection and more explicit driver-side atomic > wiring, with no remaining simple-KMS dependency in these drivers. > > Except for gm12u320, no hardware testing was performed. > > This series is based on drm-next-2026-06-27. > > AI usage disclosure: > - I wrote the first two commits myself. The remaining patches were completed > with assistance from AI tools. > - AI tools were also used to review the code and suggest code changes for > the DRM atomic conversion. > > Thanks, > Ze Huang > > Signed-off-by: Ze Huang > --- > Changes in v3: > - Use atomic state from the commit path consistently in converted helpers: > fetch new CRTC/plane state from the commit in enable/update/flush paths, and > use drm_atomic_get_crtc_state() with PTR_ERR() handling in plane atomic_check > hooks before drm_atomic_helper_check_plane_state(). > - Move MCDE one-shot flow start from plane atomic_update() to CRTC > atomic_flush(), after pending vblank event handling. > - Fix repaper damage update path to skip updates unless CRTC is active. > - Fix arcpgu missing remote encoder node handling and lock CRTC state access in > debugfs. > - Make container helpers static inline. > - Link to v2: https://lore.kernel.org/r/20260716-drm-simple-kms-removal-v2-0-1133a8fc3785@oss.qualcomm.com > > Changes in v2: > - common changes: > - create upcast helpers > - use 'commit' as name of struct drm_atomic_commit in atomic helpers > - improve control flow in *_crtc_helper_atomic_check() and > *_plane_helper_atomic_check() > - Moved page-flip/vblank event handling out of plane update paths and into > CRTC atomic_flush(), using atomic_flush and disable paths for mcde, > pl111 and tve200 > - arcpgu: > - remove reduntant mod_supported helper > - change obsolete mode field to crtc->state->mode > - mcde: > - drop attach of unused encoder > - tve200: > - reorder connector/bridge attach > - xen: > - change possible_crtcs mask to 0 > - Link to v1: https://patch.msgid.link/20260705-drm-simple-kms-removal-v1-0-b4e1ca053623@oss.qualcomm.com > > --- > Ze Huang (8): > drm/arcpgu: replace struct drm_simple_display_pipe with regular atomic helpers > drm/aspeed: replace struct drm_simple_display_pipe with regular atomic helpers > drm/mcde: replace struct drm_simple_display_pipe with regular atomic helpers > drm/pl111: replace struct drm_simple_display_pipe with regular atomic helpers > drm/gm12u320: replace struct drm_simple_display_pipe with regular atomic helpers > drm/repaper: replace struct drm_simple_display_pipe with regular atomic helpers > drm/tve200: replace struct drm_simple_display_pipe with regular atomic helpers > drm/xen: replace struct drm_simple_display_pipe with regular atomic helpers > > drivers/gpu/drm/aspeed/aspeed_gfx.h | 11 +- > drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 203 ++++++++++++++++++------- > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +- > drivers/gpu/drm/mcde/mcde_display.c | 248 ++++++++++++++++++++----------- > drivers/gpu/drm/mcde/mcde_drm.h | 12 +- > drivers/gpu/drm/mcde/mcde_drv.c | 3 +- > drivers/gpu/drm/pl111/pl111_display.c | 199 ++++++++++++++++++------- > drivers/gpu/drm/pl111/pl111_drm.h | 5 +- > drivers/gpu/drm/pl111/pl111_drv.c | 3 +- > drivers/gpu/drm/tiny/arcpgu.c | 201 +++++++++++++++++++------ > drivers/gpu/drm/tiny/gm12u320.c | 138 +++++++++++++---- > drivers/gpu/drm/tiny/repaper.c | 138 +++++++++++++---- > drivers/gpu/drm/tve200/tve200_display.c | 219 ++++++++++++++++++--------- > drivers/gpu/drm/tve200/tve200_drm.h | 6 +- > drivers/gpu/drm/tve200/tve200_drv.c | 12 +- > drivers/gpu/drm/xen/xen_drm_front.h | 6 +- > drivers/gpu/drm/xen/xen_drm_front_kms.c | 188 ++++++++++++++++------- > 17 files changed, 1155 insertions(+), 440 deletions(-) > --- > base-commit: 3696d07837d1df13a5603d77f667685e7dfb3c53 > change-id: 20260704-drm-simple-kms-removal-01a031c6a129 > > Best regards, -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg) From xen-devel-bounces@lists.xenproject.org Mon Sep 14 12:07:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 12:07:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420868.1647084 (Exim 4.92) (envelope-from ) id 1x65T0-000763-Th; Mon, 14 Sep 2026 12:07:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420868.1647084; Mon, 14 Sep 2026 12:07:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65T0-00075w-Qy; Mon, 14 Sep 2026 12:07:22 +0000 Received: by outflank-mailman (input) for mailman id 1420868; Mon, 14 Sep 2026 12:07:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65Sz-00074l-R1 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:07:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x65Sz-00FeEC-7a for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:07:21 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7e373-8faa-0a2a0a5109dd-0a2a450ca88c-34 for ; Mon, 14 Sep 2026 14:07:21 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7e378-f479-0a2a450c0019-4a7de48c9bc6-3 for ; Mon, 14 Sep 2026 14:07:20 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f705536so461333666b.1 for ; Mon, 14 Sep 2026 05:07:20 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2966147b46sm415673566b.60.2026.09.14.05.07.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 05:07:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789387640; x=1789992440; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HA60+e5Pq/r/yiWzjxDAI87jtQZSqdkKSGgJz/Lj8Mc=; b=dFSYtQO+khXtHTnXrctWU1ML88MPggEpc1UNLZoXMxlYB7evz1aqNKFHKxFuN9dCIH rHLRr7hejQrwCqsuCO7bCXotRPsfBMk1QO9HvJ17LGY4DibPbrcUNtsU1mAgd9WXCY63 vfQyNYRoN+YzAjhqx5BFBXTCk1fkQhSycJ6fk7FdJ1UbXBmvTXnv6wVX4RSswoxncoF5 nM54fLOqbnF6UHHxnznk6cmmuRcXjYsmRdWUFcjscQscJT++Fi6RlpF9Q4ZWP1BobZ8l Xotmj8rbfLQyQjyGOW3ZBeaYkB/foEfGg1HkG03Bykmo8XRWSr9ua/MZiB+PgRKbejr2 ehTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789387640; x=1789992440; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=HA60+e5Pq/r/yiWzjxDAI87jtQZSqdkKSGgJz/Lj8Mc=; b=L15HHcq/cQUSOm5MWxFLUwklW23f2QhLzbQliLRv/06mELR9/hyWVVLHONXm1tu2F0 Q5V0BSY39tBp6fvqcw7Lcrb6jIB4TX2bJccgF1hR3tcIOXq41FkgJhrk/vp1CmlRLQpG Be94H6CcBSivAyNrS5vaC6LIJ/srvOxqFFbfzfRHTROtgcJke8BQIYiRGUsDBRkjx4GQ Kbm7hMUIUAuQHYNSfrNZ5VNr/XlEHRwkVohta9oVv0wxBNoEPj84QY0u/FEEnVhAPyvs dKGZqTJGacEzWaqAtV/9JDQTwKXvC1w2emndg2pSOx8GMejzzcSNQ6Daqj8QZ5fXk4Xn 0NXw== X-Forwarded-Encrypted: i=1; AKwUvBzDCQDYOq7bWvR+mQ6mImSX7JDHvXKqxIqlpaxhDTuA8lPZ1n+7RN4RlLNe31CUZLucnM/nBIja1zg=@lists.xenproject.org X-Gm-Message-State: AFuF++mc/g2nyMtRpIfoiMlrMSGWFHqO17vjmrv+btfIJJficBBNbgfG hips7XWTmm8K5jj3Pp3hO5mVL9/z3Hh8DpcvWwRdWcePur0IGk8FT4ikU2xREZyodQ== X-Gm-Gg: AYBFou2WEnCR+pWD0RK13uAF+JO71Qh7yjn9tTPFPWTWx0Uar38XHnDAzwUtRLb+pAE CmNIji/cwki+a1OhRvE0wNV98jHLgIFn843we8E8k4iZBAkh7lER6IrJgD+szT6lstgXgJESUmM /jmUk4jeOs8T2SkzLYBiCrrquoQUWpEgLpI1NJL0UO0CGgKmBvWSHzxZTntsMLi2njYAwsFCE5p pBgRQiuMhZkjK+BXrrjV+8ljsDdH6TlVJLpi+8H3mKLW/HCQA2+Xx00ECvmz8/Zl9y7/8pw2std OGJMpqNdvPhjtySESWL5GFijFsZ4D98/vUw5JiqzxpaPFdZSFHhBuMblPf3qOrum0Wd7PD4WNVf X0PC1GT+hrHquB4BzAR5A9NxPDdZbmwvaoY1m/K2zbcUtaeORvD5Y1wK7JTBEa/zPfu2B97K+pH 3dX8T4lEvt9d0WNohbj8lhx7Hcbyuoin1eHpyrMj3z9OSytDDn6De4FZ+wMU4Qu91d8obWUu6zH XDNroy43n2i X-Received: by 2002:a17:907:7ba1:b0:c29:591a:d247 with SMTP id a640c23a62f3a-c29b87259fcmr155760966b.30.1789387640437; Mon, 14 Sep 2026 05:07:20 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 14:07:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 27/39] xen/riscv: introduce arch_move_irqs() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1789387640-02EDAA5B-2BCA926A/0/0 X-purgate-type: clean X-purgate-size: 1701 On 27.08.2026 17:21, Oleksii Kurochko wrote: > When migrating a vCPU between pCPUs the hypervisor must also migrate > the associated virtual interrupt state. arch_move_irqs() is the > per-arch hook called by generic code to trigger that. > > Replace the static inline BUG_ON placeholder in asm/irq.h with a real > implementation in intc.c dispatching through a new move_irqs vintc_ops > callback. Wire it up in vAPLIC, which delegates to imsic_migrate_vcpu() > which itself still a stub to be implemented in follow-up patches. > > Note that technically ASSERT() in arch_move_irqs() could be skipped as > it will be anyway NULL pointer dereference (and a trap will occur) if > something isn't properly initialized but sometimes it is harder to > find place where NULL pointer derefence happened as it isn't > guaraunted that all necessary registers will be filled with something > useful. > As at the moment I don't find any case when ->move_irqs() could be > skipped, the check that ->move_irq isn't NULL is added to ASSERT() > instead of adding "if ( ...->move_irq) vitnc->ops->move_irqs(v)". All of these two paragraphs look stale / inapllicable; ... > --- a/xen/arch/riscv/intc.c > +++ b/xen/arch/riscv/intc.c > @@ -192,3 +192,11 @@ void vintc_ctxt_switch_to(struct vcpu *v) > > ops->ctxt_switch_to(v); > } > + > +/* Move vCPU's IRQs from one pCPU to another */ > +void arch_move_irqs(struct vcpu *v) > +{ > + const struct vintc_ops *ops = v->domain->arch.vintc->ops; > + > + ops->move_irqs(v); > +} There's no ASSERT() here (and I'd prefer if none was added). With the description pruned: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 12:12:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 12:12:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420881.1647100 (Exim 4.92) (envelope-from ) id 1x65Xq-0000VG-Gc; Mon, 14 Sep 2026 12:12:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420881.1647100; Mon, 14 Sep 2026 12:12:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65Xq-0000V9-Df; Mon, 14 Sep 2026 12:12:22 +0000 Received: by outflank-mailman (input) for mailman id 1420881; Mon, 14 Sep 2026 12:12:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65Xo-0000V3-NB for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:12:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x65Xn-00DFHw-Qm for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:12:19 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7e490-bab6-0a2a0a5309dd-0a2a450bd3da-28 for ; Mon, 14 Sep 2026 14:12:19 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7e4a3-b7e8-0a2a450b0019-d1558030eda2-3 for ; Mon, 14 Sep 2026 14:12:19 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so35027805e9.1 for ; Mon, 14 Sep 2026 05:12:19 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e62231360sm216648425e9.4.2026.09.14.05.12.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 05:12:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789387939; x=1789992739; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=B3C7PP1zJhs71RIxzW2LS8GvnVQCNFJCxHXtKjFfjEE=; b=TaxXZbuUpElMCu7vIhorApUOtGT+0TwYE/FAIeQyMGghopk7JGVCXLsZs9PJVlJ8K9 Ftm8wRsKYIAh3x1r2FXGbpFH3k84ohLoGTePja6B+ilc/VqvSn6scvueTI02rbZ7aFL9 QrMjuRvpnvCOXyNtEXHi4G96TWXXz7ar/sW0wS3DpFkX8EZlk3s4bM5IhxW3ttTIgI36 wFjux4EKuUOnRSBF/wFFEZ96vssM/YI/dMn8lCdAGjB9xK22EbuAhNJYZSk3ajtvT8f9 jET42gBPacN2l1X158QhQ8q9+uNfpkCrFYekj0pXMPfnw/BOD4/b/Vk6KWUS4MjJU2JC 7V2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789387939; x=1789992739; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=B3C7PP1zJhs71RIxzW2LS8GvnVQCNFJCxHXtKjFfjEE=; b=YYg8ISJreLVuxeTEDmw4kWCi5r+K+8kBNRxIc0teKlSwM6HhLWN2MCj2N+0kqvhQmJ P4BZW5U+CQErMdXkIVW2mQaryFJTN329SK5d2msStQaOFkPBXKLVquUkHeIMnOo6g8/C 2CShWlaAHkhNL2Yd4sOxz6Gwmq1tSci5ezyrNUz+OQBL7Q/VjxKnzzXHwNDFWYqLFYM2 aG/DspTQ5jlp/PrZWx0xTVGeXCHOWXvFf1GbvtglTM7B7YUQQtI+wmTVtYf0s7xleChm xMMebYUfVkMxm1lpmxAenL0kHsxLYZ6iWftitS8ObpH0qTF60VOm/xjzdcIFfxqTArfZ YPrw== X-Forwarded-Encrypted: i=1; AKwUvByGDsG1Vm/zT7PuN6cuHbigyll2O5tlLqw38srVTznPI4KrIBaA4grv80fsZZy/Tfm511f0APKJF/Q=@lists.xenproject.org X-Gm-Message-State: AFuF++kkVT0gN18oNfhVrPEL5ihQuYw7mW1wO8EvNt9RyrmzZy1jj5aD M7mSBehAa8GEcp5/C+TWpqG8HWprwd9jLSMYiFsrJ16Gaa0lPwPUkEudW/7pkfC/VA== X-Gm-Gg: AYBFou2aSfzho89RuNS1q1LI/MKucJv3wuN4YYZJ868AXFufchThL1KonFmr48JHfo2 BRX1H67gMplpewkymjHKVggx1v5JeFHlpz1YD+pijyC06HnXHnq6zl6QH/kKlv73MExgoRWNYLS YYUlIMH8fHn/xDWBUA43JV1qgtftNMdhIcMTlHOxFoiIxH2OKarDqb1pVCRrPucUWHy8Q86xbcx 0AZEp8LUn1Cude8u+cyfRbqMugLQB5xC3qBrwp4WKjOZtb27pVA/1DKLYQF5IBwn0ewCfrCG8Re 32YqJKSyPFvvF0m8LoDcyhppP53ZAPdD6Gww671tFZ/uzF/oA87nJbKQWOl6+FGcKeFzGvLkxoV 71MmS1uPeGnakTEuQsjGi50Kt6YxoXkDFoMH82pc6c7eQ1mp16BXmd5MjBof7q2xCM7zr71Qd0W 2RHqYGHS8MuaoDcYi1j49TmUY5GH6efSzKdwu4Z9n9yZgUC3pHvfRzKtiobnMDZyID/1KDD34XK 9MWoUNnS8l6 X-Received: by 2002:a05:600c:3b1d:b0:49e:74b6:740f with SMTP id 5b1f17b1804b1-49e7a685a5cmr25650815e9.17.1789387939221; Mon, 14 Sep 2026 05:12:19 -0700 (PDT) Message-ID: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> Date: Mon, 14 Sep 2026 14:12:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789387939-182F49EA-915F61F7/0/0 X-purgate-type: clean X-purgate-size: 1509 On 27.08.2026 17:21, Oleksii Kurochko wrote: > The IMSIC vsfile mapping is performed in continue_new_vcpu(), since the > target pCPU must be known at that point. It is therefore possible for > imsic_migrate_vcpu() to be called before continue_new_vcpu() has > executed, in which case v->arch.last_pcpu is NR_CPUS and there is nothing > to migrate. > > Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > against silent incorrect behaviour or unexpected panics in guest VMs until > the function is fully implemented. This doesn't adequately describe the change made: The BUG_ON() was already there. > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, > > void imsic_migrate_vcpu(struct vcpu *v) > { > + /* > + * The scheduler can mark a freshly created vCPU's unit as migrated and > + * invoke this before the vCPU has ever run (see the migrated branch in > + * schedule()). No need to do migration for such vCPUs as they aren't fully > + * initialized (for example, context_switch() will be called after > + * imsic_migrate_vcpu()). > + */ > + if ( v->arch.last_cpu == NR_CPUS ) May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a good sentinel. If we/you decided to switch to ~0, >= here would continue to be correct. Jan > + return; > + > BUG_ON("unimplemented"); > } From xen-devel-bounces@lists.xenproject.org Mon Sep 14 12:23:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 12:23:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420893.1647109 (Exim 4.92) (envelope-from ) id 1x65iH-0002ts-G7; Mon, 14 Sep 2026 12:23:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420893.1647109; Mon, 14 Sep 2026 12:23:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65iH-0002tl-DY; Mon, 14 Sep 2026 12:23:09 +0000 Received: by outflank-mailman (input) for mailman id 1420893; Mon, 14 Sep 2026 12:23:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x65iG-0002tf-LE for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:23:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x65iF-008lA0-TI for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:23:07 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7e729-2eae-0a2a0a5409dd-0a2a450abb4a-14 for ; Mon, 14 Sep 2026 14:23:07 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7e72b-f2d2-0a2a450a0019-4a7de44ce2cc-3 for ; Mon, 14 Sep 2026 14:23:07 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a605c198fdso3517914a12.2 for ; Mon, 14 Sep 2026 05:23:07 -0700 (PDT) Received: from ?IPV6:2a02:778:142:8f01:2700:bad4:284c:5aa5? ([2a02:778:142:8f01:2700:bad4:284c:5aa5]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a9b5912644sm4178916a12.11.2026.09.14.05.23.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 05:23:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789388587; x=1789993387; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=cmCZh2AH2E7mtWOqD/SFB0LdOZ8LeKTlc+r7cOKCVrs=; b=bwHE9x5vEXJVDwl/lULWeCsOIhZb2Gk6XaAtJil098eFmc5EBMBDUp9dURaB3VOa8h suDF48ZySzIwHOkEyMHc9AZwlZWFYh5vdxsMWrtNAjZ4elF6dyCUMqWN6FGkdjJG569Q 8RJXPQCEckEonm1iO99GAxMjBlROY97wqgOSQtgtxUHleV4IG6BBvEK6BhPQWc6qrpdx YMP3iFEPCbOj9i3GpPD4u+wBAPusHKEEXh5gLAFyBaV9r1HhZApYJvJOyFxjLE8DKvxe ljyozeW0p4M9JwWH2w2N/Tqh6fAZ4bpaKrYE5olaerHCbknVEnBhvs41BzW4wmqfB9Et N8bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789388587; x=1789993387; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=cmCZh2AH2E7mtWOqD/SFB0LdOZ8LeKTlc+r7cOKCVrs=; b=IxFxZDO49CiPLDSzuNgIWlbo1QRW7qc7w6lTuNwXtQd63nMPsqGRSzfPk4xbwbWlJ1 S0pSj+Dg0eb8JuWBjbbj+iDNDr7rSo4jzDK/B709qvOEqZgHZtOk968ADiCXHITR6ZmX XEGQlGEAvTASIVnK9kzmurU0b2krD3T8/SdiMEejzKUn1ZLCOxqLt0rBNQacroq3VmML mp0OYdJkPAGX3iXNUyLyR68c8zP4yjzoOCRhScPJG4gGzikSJ+H1zGbODBGOvcwzzen9 njIQiYA/MIetfqzMUh6aFVyLB5buEEZG+M9boqzP4MrBVrRqlmJBrD/UlFLVI48Kcs3L LyjA== X-Forwarded-Encrypted: i=1; AKwUvBzvpfnL8tTqL+XW5Ar15bzuGTW2Ba6bUBVWXUa1farXCbP00Ih5yD1efKNgVqGT7ipKPDjWRMpURjA=@lists.xenproject.org X-Gm-Message-State: AFuF++nrCzKtYHmNc0OfQUwYHV3YhaSWZPWT3LQFbY0UKytIPlj1R3eW JM6E4tR6Lpjh62eNJvAfBYUj7j9sMqfMKOSg0LLb4ppP2xnbh5Z65AGc X-Gm-Gg: AYBFou2kFyn6cnSjkZOkLsHINiQDNpldI3w7970BT2q1fEpgdOpFZyCifYGGzQNNVXH XwCzBo4m3t036ThsUCjorlHGksw3MMYEQKBw/+Dp27irZyrBhJWKfrPXOwYiQLwJyIwg/xny+uG 2zggou2D6ahlD/7L44cPt2DFrY9dIS+T3/IKDvwZU6xFhKab2MubcvQJhXIjTpoQ9mm9SA4SDeN XCJQPPiw6YHGzj24pMCC65zK4f+m8ALgvRNaLqdMqEhxrmTcWbrrsk73WaEZVHAfN4euB5d2mx5 nZnx9QFTH1zv5jS7TPzJKaQcaVQfMJJ6Xk0MZzz2e5mXlPr4uuoR83rqg59xsEFLo/WrZd7tIG8 j19iPSm0KkuadhAJaq/qEBtZLBP9PlBIueOQ2w6QEYjyXjGp5vKV4Hz5VuBDtJdAzp5JiaZpZy/ IZtpFYhn+4mlJEjsiFrT8yUclY0NsQ0SEfI8PvBF+fgAQGhXW6mjArXGdFj1oB9aqUnQsFwatGH NNp0gyYGP7gtGw3BTmGbN+2ncSL3yswB7oTKSZR2aFAyPoJ6jx5AdU= X-Received: by 2002:a05:6402:4504:b0:6a7:ea54:376 with SMTP id 4fb4d7f45d1cf-6a9f6282363mr1323794a12.30.1789388587160; Mon, 14 Sep 2026 05:23:07 -0700 (PDT) Message-ID: <8cb54ae1-a195-4b05-8024-b7b613e2e956@gmail.com> Date: Mon, 14 Sep 2026 14:23:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 16/20] xen/riscv: implement IRQ routing for device passthrough To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Alistair Francis , Connor Davis , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: <3e05825b-9762-4fba-a064-821bd3d7f8d6@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <3e05825b-9762-4fba-a064-821bd3d7f8d6@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789388587-530D9CFC-67A6AFE0/10/73395122804 X-purgate-type: spam X-purgate-size: 1107 On 9/14/26 1:36 PM, Jan Beulich wrote: > On 14.09.2026 12:54, Oleksii Kurochko wrote: >> On 9/10/26 2:53 PM, Jan Beulich wrote: >>> On 09.09.2026 17:07, Oleksii Kurochko wrote: >>>> --- a/xen/arch/arm/irq.c >>>> +++ b/xen/arch/arm/irq.c >>>> @@ -205,7 +205,7 @@ void __init init_IRQ(void) >>>> static inline struct irq_guest *irq_get_guest_info(struct irq_desc *desc) >>>> { >>>> ASSERT(spin_is_locked(&desc->lock)); >>>> - ASSERT(test_bit(_IRQ_GUEST, &desc->status)); >>>> + ASSERT(desc->status & IRQ_GUEST); >>>> ASSERT(desc->action != NULL); >>>> >>>> return desc->action->dev_id; >>> >>> Why did an Arm change slip into a RISC-V patch? >> >> Considering that this code is executed under the spinlock it is fine to >> not use test_bit() so it is part of dropping of bitops functions. > > Perhaps, but then in a separate patch and changing all places consistently > (I didn't go check, but I'm pretty sure there are more). Oh, sorry, it is really Arm file. I overlooked that... It shouldn't be really touched in this patch. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Sep 14 12:25:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 12:25:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420899.1647119 (Exim 4.92) (envelope-from ) id 1x65kX-0003Tv-SE; Mon, 14 Sep 2026 12:25:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420899.1647119; Mon, 14 Sep 2026 12:25:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x65kX-0003To-P9; Mon, 14 Sep 2026 12:25:29 +0000 Received: by outflank-mailman (input) for mailman id 1420899; Mon, 14 Sep 2026 12:25:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x65kW-0003Ti-AK for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:25:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x65kV-009oxT-N9 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:25:27 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7e7b1-2eae-0a2a0a5409dd-0a2a4509bc2a-8 for ; Mon, 14 Sep 2026 14:25:27 +0200 Received: from [209.85.208.45] (helo=mail-ed1-f45.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7e7b5-be1a-0a2a45090019-d155d02df14c-3 for ; Mon, 14 Sep 2026 14:25:25 +0200 Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-6a68279dd86so3784832a12.3 for ; Mon, 14 Sep 2026 05:25:25 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c296601f4ccsm418223666b.20.2026.09.14.05.25.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 05:25:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789388725; x=1789993525; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4hx2uFWIyZzNHhpXFCEL4qmHY6+FmVxnXkFpagWWooc=; b=M6CzoqnEx7pPyIF/O9kJNjKbMIdTS2dgQTwXNd6mvcJxErCEEDCyjBHljAwjE+79QB //yIKbeqr4Q+uWAWH3gdO6V7N5bLPoYB7GnbKqB1UIvhw1cpd+JD6rrQjwWjUDHDVCPH OexjIp4JrylRmf6pSsFra05b0rY3YsHubBhFCVxLrNUEUmnZBdlb+UujpWJdoE4/glWm k98m5X+CPtsc5ozi1uVAOUed7xf6U55oUhkLiWDTMtTTa1g7XxP7Qd1faSHyGl/0FIaa pn6StbAKIVivk6eA6ugMVE6ktYiBopQGyXpg70vDa8OMkfrgq0tPCAX3HULDrZdj9v6o +iFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789388725; x=1789993525; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=4hx2uFWIyZzNHhpXFCEL4qmHY6+FmVxnXkFpagWWooc=; b=tRCxYZusTVYT9y6v8wm/z+JqvdQQLkfzLesCnJZIzlrBEHfdiNmPauvj4i0zDuD4NU Qgy313PwTKUDP+JlhoTYf5VzZsxCY5QH5liUFMMxbYPfaptyzX6jZP6ZuR8w9df2bZYA P8EWDgdB22s5GVLz2/tqlA6zgI0LhW7PgDQmmqb/NBziHho7rjHmFJqp4hFP7wXysE6X W+plCpgWBWP/+cagTV25cx0765GdZowJnzGiIXxXweplLeYqhSvu3c/Zf2Ph02mImuiB GU5v2HCKq31uvxCZOtgRl4UpSOavQdiksaqFFC92RWmRqfTBxdY1pMqiHVK0ineWzL/X T8bw== X-Forwarded-Encrypted: i=1; AKwUvBxfXKejQ/x2tWfgWkYXwm+qyrEAhUVzY2H/84sk2V8l5RmoC2PfXY71h6/WH7IKTcE5IBxHPqYbafs=@lists.xenproject.org X-Gm-Message-State: AFuF++nqezJSYCLMZHZkhHKWbSDq5f40bB8eUOvJC7zX1xFT2zZtX3JT uTZ5dBpFVJDmY714PunUxMDrMCB/e9brknDSyzUb9tcxzO9O4A5CYn+wAeMUmlyB4A== X-Gm-Gg: AYBFou0x5b2SX5xzsNEL1xKqxbyxUtCfkGRkoKGfEISzmXBXFjWqtIENsCe4hCRH61w Y83VyaLp97vEzl01EE/d7X0ql9dlCrRPbnnAKStjSrYPxipJG03GXVoP/U5/e4f72bHgoMgqAQD +N+R1V4uN/xv83SzsCO3YNdkP/UWjbil25m87GykcwewJ8U+ixQ6VrGMR5hGDBdQPCemYRLJ2sl lFXy2WgsFQLZDgDwvD9nCJk2fudqwnXEQnCgANnjZ4ejQ1For4uk1Ca1/FDilfc/Cg0SBKeyKcw SfxbIqHAMslnje6FGGrDgK/j8jiWAKwQVFzF6i/zWOplVdFaJv3tkRmH1LZuEmg1w0WKL2LuEFE R1vKh64KWud98nYvMsEbKUcwBFkAtOCUL37OgxadCc3+e0v1MD2y1YZ25XS0r4vSWSYLhB/sUc4 yoUs2PnpiAFg1nwmlaN0RZ548yFqabXoXv/zdaj6kcD2l1TVU/FZdWgxfycvp+nNbKB1ZYd5FMq UiicraEm3r8heN9gIzxy0M= X-Received: by 2002:a17:907:d0d:b0:c29:3d59:7072 with SMTP id a640c23a62f3a-c29b8647a82mr145566166b.16.1789388725361; Mon, 14 Sep 2026 05:25:25 -0700 (PDT) Message-ID: <2e29de1d-370d-4251-8e1d-dd9f17720339@suse.com> Date: Mon, 14 Sep 2026 14:25:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 29/39] xen/riscv: introduce aplic_reconfigure_target() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1789388725-3BCD7034-27909F39/10/73395122804 X-purgate-type: spam X-purgate-size: 2642 On 27.08.2026 17:21, Oleksii Kurochko wrote: > When a vCPU is migrated to a different pCPU, its IMSIC guest interrupt > file changes. Any APLIC interrupt previously configured to deliver an > MSI to the old interrupt file must be retargeted to the new one. > > Implement aplic_reconfigure_target() to scan all interrupts allocated > to the domain and update their APLIC TARGET registers accordingly. > > Signed-off-by: Oleksii Kurochko First of all I'd like to understand how this "reconfigure" works without losing interrupts and at the same time without other possible races. An interrupt can be raised at any time, after all. > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -138,6 +138,48 @@ uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, > return base_val; > } > > +void aplic_reconfigure_target(const struct vcpu *v, > + unsigned int old_guest_file_id, > + unsigned int old_cpu) > +{ > + const struct vintc *vintc = v->domain->arch.vintc; > + const unsigned long *auth_irq_bmp = vintc->used_irqs; > + unsigned long old_hart_field = aplic_hart_field(old_cpu); Once again a question you may already recognize: What extra value does "field" in the variable name add? > + unsigned long flags; > + unsigned int irqn; > + > + /* Support only MSI mode at the moment */ > + BUG_ON(!aplic_msi_mode()); > + > + spin_lock_irqsave(&aplic.lock, flags); Taking a global lock for a per-vCPU operation isn't going to scale very well. Even more so when then ... > + bitmap_for_each ( irqn, auth_irq_bmp, vintc->nr_virqs ) ... you run a loop with perhaps many (hundreds? thousands?) iterations. > + { > + volatile uint32_t __iomem *ptarget; > + uint32_t target_val; > + unsigned int guest_index, hart_index; > + > + if ( !irqn ) > + continue; > + > + ptarget = &aplic.regs->target[irqn - 1]; > + target_val = readl(ptarget); > + > + guest_index = MASK_EXTR(target_val, APLIC_TARGET_GUEST_IDX); > + hart_index = MASK_EXTR(target_val, APLIC_TARGET_HART_IDX); > + > + if ( (guest_index != old_guest_file_id) || > + (hart_index != old_hart_field) ) > + continue; Along the lines of the naming comment above: This would be more logical to follow if it was if ( (guest_id != old_guest_id) || (hart != old_hart) ) continue; i.e. names on each side of the != suitably matching up. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 13:11:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 13:11:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420933.1647128 (Exim 4.92) (envelope-from ) id 1x66T3-000397-5T; Mon, 14 Sep 2026 13:11:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420933.1647128; Mon, 14 Sep 2026 13:11:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x66T3-000390-22; Mon, 14 Sep 2026 13:11:29 +0000 Received: by outflank-mailman (input) for mailman id 1420933; Mon, 14 Sep 2026 13:11:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x66T1-00037a-MB for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:11:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x66T1-001NHh-1N for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:11:27 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7f27e-e002-0a2a0a5209dd-0a2a4507c5be-2 for ; Mon, 14 Sep 2026 15:11:26 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7f27d-b4ea-0a2a45070019-ac6904febb6e-3 for ; Mon, 14 Sep 2026 15:11:26 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 3558160120; Mon, 14 Sep 2026 13:11:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65F6B1F000FF; Mon, 14 Sep 2026 13:11:01 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789391484; bh=HMEr8VxikyVfU6qvEUZWpmfPP3XV/5sFL4uxF81JxCA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=CJKJt+kIe+hjf+CMIokL8p95jJbZP9ztsmmxzZVo1NFVjWTN+jeWfJ8gkpM0krJT8 Utjnt2XRl1o23z+XgGILQt1K7qKpVap9QKwfAQ3Pbw7Nb1qdciasZLG+bCxX6W8crk mB6ySTVDkFOyHlizGE9wPiKXzd5ZoeQzUUHq4GK3Az9uzbVLKJs+jLvaWj//Z7s9yJ 26BLl4l4JsAZDlTiLo0F5mBC0VkJP+XRzFeBS+pwUeA7vgq+fA4Y2VALNJVCMnpA9v 1Oa2VfL25A9Rb97s1Afe8qFm5GadjQrDawLd5iUENfXkRUR76/6j5S6iZTu65TIRWr 3oGpW4Ax822zA== Message-ID: <066c3b3b-e5a7-4cbb-b077-26c78cfc07ac@kernel.org> Date: Mon, 14 Sep 2026 15:10:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead To: Matthew Wilcox , Zi Yan Cc: Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, Oscar Salvador , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Tal Zussman , Gao Xiang , Jan Kara , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-trace-kernel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , ceph-devel@vger.kernel.org, Song Liu , Yu Kuai , Li Nan , Xiao Ni , linux-raid@vger.kernel.org, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org, Baoquan He , Pasha Tatashin , Pratyush Yadav , Jonathan Corbet , Dave Young , Shuah Khan , kexec@lists.infradead.org, linux-doc@vger.kernel.org References: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789391486-362C4AE4-7786B2AB/0/0 X-purgate-type: clean X-purgate-size: 660 On 9/14/26 06:21, Matthew Wilcox wrote: > On Sun, Sep 13, 2026 at 10:23:58PM -0400, Zi Yan wrote: >> md/md-bitmap: replace PagePrivate() with page_private() >> buffer: replace page_buffer() with page_private() and delete it > > Sorry, looks like I screwed up git send-email usage. I'm proposing > replacing these two patches wth the three I sent. For everybody CCed wondering "which patches": https://lore.kernel.org/r/20260914041830.2072626-1-willy@infradead.org https://lore.kernel.org/r/20260914041830.2072626-2-willy@infradead.org https://lore.kernel.org/r/20260914041830.2072626-3-willy@infradead.org -- Cheers, David From xen-devel-bounces@lists.xenproject.org Mon Sep 14 13:13:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 13:13:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420940.1647136 (Exim 4.92) (envelope-from ) id 1x66VC-0003dC-FU; Mon, 14 Sep 2026 13:13:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420940.1647136; Mon, 14 Sep 2026 13:13: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 1x66VC-0003d5-Ck; Mon, 14 Sep 2026 13:13:42 +0000 Received: by outflank-mailman (input) for mailman id 1420940; Mon, 14 Sep 2026 13:13:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x66VA-0003cy-Ve for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:13:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x66VA-00GsrM-Bk for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:13:40 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7f2f2-2eae-0a2a0a5409dd-0a2a450b974e-36 for ; Mon, 14 Sep 2026 15:13:40 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7f304-b7e8-0a2a450b0019-d1558031e0e4-3 for ; Mon, 14 Sep 2026 15:13:40 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49e78adf099so12412825e9.2 for ; Mon, 14 Sep 2026 06:13:40 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e60ad0614sm339581965e9.10.2026.09.14.06.13.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 06:13:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789391619; x=1789996419; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Y5CB6YBam0fmqhE0ijkrGF3sE995xttITmudScBDlcc=; b=FSI44xCOvPRRcPjG861CS/0WJ/Z6FIQTvh4GAwp9l+SqFy3vm+EFSIFo3FBLzaBYae HrDFkReB6rg4QVhcD6S4toHoS1XfYU299dVELsSYCzbP5U6tj7M/MNQMoYxGeajIkfwG NAKwP3fcJvXvBCMLoCQ8Ucd5O7ZVhAK1bHiYOHyxe8f1b/0EKnWj8wYOgs+HhVY+Pyrc Ty1kvH2eXjKy7uVzvzaeU5uPE0vRzcVTYWcSJFyccG90fOrhCADIj6AkYEu+nJO32y4Y oh46k5iVVo5OY84Ol902fQuyNc4wq82IeLzbEOAKFz3FRGboLLS7LeQH2iI5SGJH9buH h6cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789391619; x=1789996419; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=Y5CB6YBam0fmqhE0ijkrGF3sE995xttITmudScBDlcc=; b=KdVbGYjsqO9evId+wzuC94rfJeaeDAxtt2gBtca32lyyIUA9BIN2fcWVu5JmTaxuIh y//lcaE0SVKmnYsl8BbHKSkcuwrK4wVKHFNMUmQfZ6vvk0GvwDi8XNNgLtWvznTzKbKB gQ8e7965mqbynsT3ywPfT+ApAXuhl3Eq3L7kutuiYyGGWNO5IcBo+D/sfn5uhR4x4yv9 gCGVEr9jSmq22PbefIfArMjc9uJP2r+K/0a0XwQf6mJc5y2Cr6uL49EFLJPR/w7oo0wY 4OrEpuY/Gd21QdDA7nKTpGPr6K/WUX29d0prpgW8ez/oqs+nu5vP3YQ2bAbUbkai5XNt Vhvg== X-Forwarded-Encrypted: i=1; AKwUvBzmuD9bWHQpbww+3oBzgGH/M7rKXSXXt2Opeayv7Rln++wSuL6xyUY7HQjt8JNo3G77yKlQd2o8ags=@lists.xenproject.org X-Gm-Message-State: AFuF++ko75xzkp9JlgW02XxGJM40I6ZYi2c5vl/MZ38Wsx0b9LQzQdCY lpj+1F3Wj4u7ymbflu2yfF1Y0CdfI5zzJSgss7zzfkM/d7O+k8l6/B5906Zhxd9dSQ== X-Gm-Gg: AYBFou1B8OXbmZPN72rQ9/pr95QeruCxTVGJ0mXbWMJQnMORwrvupuI2ZhwsoxNTorp dXcUAptO4HyK6RhR4dA4ElB6LWxx3XyBnk8VxS4AcmGvVfbJy7ZAZx1VapfuHbKmKlit3yO5TB1 1MmXc9yCcCMP2Ke3k7C/Sx2zYdY1RgWzJGrV24176HAqBIb/t1UMu059+IAKtYzDx6FkoQcNF5U W5xJxBgy9fHbRRQOE93dd3BHbs8aBZaUhfIpYTSoBxfT4FdcP7U5Cw7fVPx3YTWzM1rQ1Y7xST4 hmz2eFx48Q/HhhonTLryH61UntiDkcx2xh9LPFMH0/AUOWjZGUfX+hBEdUGHO5/1odJ5SgTrh0j 3fNfAxVn0RmjSkMRcOBUkE68u9+gAdcZYwAt3mkvYysC9x4WR7jvGXNTgTO4x4tV6lrkb7ng33f d0HlWVHEWIysXSK88XwU73KFMTOISNjsDZCu+AwPKlM+FsA4Gbd66fkG98oTac2ecap62Upr9dN py1KLqQTOBFvw== X-Received: by 2002:a05:600c:860b:b0:49e:79c5:ee93 with SMTP id 5b1f17b1804b1-49e7a64b4dbmr28601075e9.8.1789391619585; Mon, 14 Sep 2026 06:13:39 -0700 (PDT) Message-ID: <2ea26d3b-6413-410f-9cb1-59645cf594e2@suse.com> Date: Mon, 14 Sep 2026 15:13:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789391620-A96C29EA-43E18A0D/0/0 X-purgate-type: clean X-purgate-size: 6288 On 27.08.2026 17:21, Oleksii Kurochko wrote: > @@ -77,6 +78,64 @@ do { \ > csr_clear(CSR_SIREG, v); \ > } while (0) > > +#define imsic_vs_csr_write(c, v) \ > +do { \ > + csr_write(CSR_VSISELECT, (c)); \ > + csr_write(CSR_VSIREG, (v)); \ As patch context also tells: Excess parentheses. > +} while ( 0 ) > + > +/* > + * Generic switchcase expansion pyramid. > + * F is the per-operation leaf macro, ireg is the base register index. > + * Optional extra args (e.g. an operation and/or a value) are forwarded to F > + * via __VA_ARGS__. Just that there's no F below. > + * imsic_switchcase_break(ireg, op, v) - emit "case ireg: op(ireg,v); break;" > + * imsic_switchcase_ret(ireg, op, ...) - emit "case ireg: return op(ireg[,v]);" > + * The variadic tail is optional so the same leaf works for both read (no v) > + * and swap (with v). > + */ > +#define imsic_switchcase_break(ireg, op, v) \ > + case ireg: \ > + op(ireg, v); \ > + break; > + > +#define imsic_switchcase_ret(ireg, op, ...) \ > + case ireg: \ > + return op(ireg, ##__VA_ARGS__); > + > +#define imsic_switchcase_2(F, ireg, ...) \ > + F(ireg + 0, ##__VA_ARGS__) \ > + F(ireg + 1, ##__VA_ARGS__) Ah, there is an F here. This (recurring below) shows another problem: The two F invocations look syntacticlly incorrect, due to the missing semicolon. Semicolon use wants redoing everywhere here. Further (and again throughout) I think we'd be better off using either standard C constructs (e.g. __VA_ARGS__) or the gcc extension permitting use of ## after a comma. A mix of both always looks odd (to me at least). Finally, unlike further up, here (and below) ireg wants parenthesizing. > @@ -389,6 +448,76 @@ int cf_check vcpu_imsic_init(struct vcpu *v) > return 0; > } > > +/* > + * Arguments of the imsic_vsfile_local_*() helpers, which are executed by the > + * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). > + */ > +struct imsic_vsfile_data { > + unsigned int hgei; > + unsigned int nr_eix; > + struct imsic_mrif *mrif; I can't spot any use of this field (and hence I also can't judge whether const wants adding). > +}; > + > +/* > + * Execute func() on the pCPU which owns the IMSIC interrupt file func() is > + * going to work with. > + * > + * An IMSIC VS-file is reachable only through hstatus.VGEIN of the hart the > + * file belongs to, and a guest interrupt file index is meaningless on any > + * other hart, so such work always has to be done by that very hart. > + * > + * The local case runs with IRQs disabled to provide func() with the same > + * environment it is given when it is called from the function call IPI > + * handler. > + */ > +static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), > + void *data) If this is supposed to be passed struct imsic_vsfile_data *, why not say so here? Be as type-safe as possible. Of course the callback function has to use void *. > +static void cf_check imsic_vsfile_local_clear(void *data) > +{ > + unsigned int i; > + const struct imsic_vsfile_data *idata = data; > + unsigned long new_hstatus, old_hstatus, old_vsiselect; > + > + /* We can only zero-out if we have a IMSIC VS-file */ > + if ( !idata->hgei ) > + return; Wouldn't it make sense to avoid the call here altogether then? > + old_vsiselect = csr_read(CSR_VSISELECT); Likely obvious to you, but I can't spot why vsiselect would need saving here. If you want me to ack such code, please add at least brief comments. > + old_hstatus = csr_read(CSR_HSTATUS); > + new_hstatus = old_hstatus & ~HSTATUS_VGEIN; > + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); > + csr_write(CSR_HSTATUS, new_hstatus); > + > + imsic_vs_csr_write(IMSIC_EIDELIVERY, 0); > + imsic_vs_csr_write(IMSIC_EITHRESHOLD, 0); > + > + for ( i = 0; i < idata->nr_eix; i++ ) > + { > + imsic_eix_write(IMSIC_EIP0 + i * 2, 0); > + imsic_eix_write(IMSIC_EIE0 + i * 2, 0); > +#ifdef CONFIG_RISCV_32 > + imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); > + imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); > +#endif In asm/imsic.h I see #define IMSIC_EIPx_BITS 32 Why is the number of CSR writes different here for RV32 vs RV64? And if so, why would you not use the 64-bit write function, allowing the #ifdef to be omitted? > @@ -689,6 +818,14 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, > > void imsic_migrate_vcpu(struct vcpu *v) > { > + unsigned int new_vsfile_hgei; > + unsigned int new_vsfile_cpu; > + unsigned int nr_hw_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, > + BITS_PER_TYPE(uint64_t)); As written, this could also be 64. uint64_t is a fixed-width type after all. The question here is: Which variable's type do you really mean here? > + struct imsic_vsfile_data vsfile_data = { > + .nr_eix = nr_hw_eix, The local variable looks to be used only here. Is there really a need for such a local variable? > @@ -699,5 +836,27 @@ void imsic_migrate_vcpu(struct vcpu *v) > if ( v->arch.last_cpu == NR_CPUS ) > return; > > + /* > + * At this point, all interrupt producers are still using the old IMSIC > + * VS-file. > + */ > + > + /* > + * Latch the pCPU the new interrupt file is taken from: vgein_assign() > + * allocates it from v->processor's pool of guest interrupt files, and > + * only that hart can access the file afterwards. > + */ > + new_vsfile_cpu = v->processor; Same here: Is this variable really needed? And what exactly is the comment telling me? > + new_vsfile_hgei = vgein_assign(v); > + > + /* We don't support SW interrupt files at the moment. */ > + BUG_ON(!new_vsfile_hgei); > + > + vsfile_data.hgei = new_vsfile_hgei; And again - any real need for the separate local variable? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 13:15:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 13:15:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420954.1647153 (Exim 4.92) (envelope-from ) id 1x66XH-0004LT-1E; Mon, 14 Sep 2026 13:15:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420954.1647153; Mon, 14 Sep 2026 13:15:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x66XG-0004LM-Uq; Mon, 14 Sep 2026 13:15:50 +0000 Received: by outflank-mailman (input) for mailman id 1420954; Mon, 14 Sep 2026 13:15:49 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x66XF-0004LE-UY for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:15:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x66XF-003l3r-B6 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:15:49 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7f377-2eae-0a2a0a5409dd-0a2a4507b31a-48 for ; Mon, 14 Sep 2026 15:15:49 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7f384-b4ea-0a2a45070019-ac6904fee22a-3 for ; Mon, 14 Sep 2026 15:15:49 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id A339460120; Mon, 14 Sep 2026 13:15:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6BC7B1F000FF; Mon, 14 Sep 2026 13:15:40 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789391747; bh=7MgZNxAm6rLbdWEaG1tKVLSEArg8sJOE28H+A/hGdqY=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=nrUcY1Z6EE9Yx3XyardKgLAilyIh7MG7IgdjNN9c8v3syQj4OF+ECl1T9O/tXLQCv UVtqX/wTf76sh1GACfeMRusPbe6Vj5/1dvuMmVo4YB1cwMZck8rrjeFPyGMyokvA0O iAlby2CTO5yt/kB3WNF3NjgTOYDx48nsnszifQkqaqFLCmXQx3e63oyIez2RDF8qmX ml8aUvxpYcLKp85j9j2nc82pVP/v0RMqMq4ZSDblHPVUXXQqzi/VYRtpwP/4EpgwAC VT051wV3YVZ0kc2khK+T8fxTqk4DrLkiyLpI1qQvmkX9U2Hn2fRZDlzVSwfbOGtvgz xUjfBKk257kqg== Message-ID: Date: Mon, 14 Sep 2026 15:15:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 03/16] xen/grant-table: stop setting PG_private on pages for grant mapping To: Zi Yan , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org References: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> <20260913-remove-pg_private-v4-3-848550f7574e@nvidia.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <20260913-remove-pg_private-v4-3-848550f7574e@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789391749-A78D1AE4-BAE7E698/0/0 X-purgate-type: clean X-purgate-size: 863 On 9/14/26 04:24, Zi Yan wrote: > gnttab_alloc_pages() stores xen_page_foreign in page->private. On 32-bit, a > pointer to an allocated xen_page_foreign is stored; on 64-bit, > xen_page_foreign is stored inline. Checking page->private != NULL is enough > to tell whether a xen_page_foreign needs to be freed on 32-bit and > page->private is zeroed unconditionally on 64-bit. > > It prepares for a future commit that remove PG_private. > > No functional change intended. > > Assisted-by: LLM > Signed-off-by: Zi Yan > To: Juergen Gross > To: Stefano Stabellini > Cc: Oleksandr Tyshchenko > Cc: xen-devel@lists.xenproject.org > Cc: linux-kernel@vger.kernel.org > --- Reviewed-by: David Hildenbrand (Arm) -- Cheers, David From xen-devel-bounces@lists.xenproject.org Mon Sep 14 13:27:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 13:27:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420972.1647167 (Exim 4.92) (envelope-from ) id 1x66iS-0006Yr-31; Mon, 14 Sep 2026 13:27:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420972.1647167; Mon, 14 Sep 2026 13:27:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x66iS-0006Yk-0D; Mon, 14 Sep 2026 13:27:24 +0000 Received: by outflank-mailman (input) for mailman id 1420972; Mon, 14 Sep 2026 13:27:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x66iQ-0006Ye-JK for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 13:27:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x66iP-003sIY-WA for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:27:22 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7f629-e002-0a2a0a5209dd-0a2a4506c4ec-36 for ; Mon, 14 Sep 2026 15:27:21 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7f639-195a-0a2a45060019-4a7de14cde82-3 for ; Mon, 14 Sep 2026 15:27:21 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-484366874b0so1122809f8f.2 for ; Mon, 14 Sep 2026 06:27:21 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e7d202a2bsm1961545e9.0.2026.09.14.06.27.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 06:27:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789392441; x=1789997241; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ir3e7UrikW5diNP5IWdtsqID8I/hj9kpLtBWACPpVPY=; b=J3BIUCaXULMheC6w1ZEk/3lrkoJLAhIczzN6XWS28J85bdWaMknCEd9lYUiK042Htd moGxzDpxdjXQlYt5N1mN+coretUCPglYeX9UCmY8jkbJrmTDDDGDmxNfmLPqe50lFJCY D+Y4+sXgktC/wIyesDnmBGS2+u8PynZ0Rx8lSN+UW/dx5MpAP0Mik2GfR4AzfvoKm8Gy 5TZcMtFDq55lKmbhUwOK6v0JpGe6FaeaxtGiqQidAmGbdPn2CRwBXNgjpiVYa4OiKpKW KvfqXQHdnqOht6NGXGbDnxDBBKzg9xesSNfPxAoWtBQVBIqQSgYL3fYQ44N4tCUNy4L2 X2ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789392441; x=1789997241; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=ir3e7UrikW5diNP5IWdtsqID8I/hj9kpLtBWACPpVPY=; b=tYh6hPCZ+di9cQMI7DbMnahCk3TGhu9PwVln9c73IuTH/rqFjoTUEezWtp7olDsO2F OXRv/9h2hl7xljMynt1zeU+wrYK0A2eD3jXp8BMUl5OycUdByg0ctKFq/bD2gt/HB22k Hfy8EzszjpFkkc3/uUQPspMVKAdckJ6NGe0ROzBaXan4rQ/172iWkKE5uNE+0+HQAt35 SPIedVbSZx9xK5cd8L5FVUqyXULi/F9uHMLN2ntHQfyZF9IkfRed8cZtxTl2rv/4dtXv IMxehUd917UNblKCyZ7L/P1NedT9olboPXPtTwLry1BBvR9316iuJKnlLrFlpyzJqmxY KCxA== X-Forwarded-Encrypted: i=1; AKwUvByWuvGEmj7ok4SLEzZmfYefd9+mREmDtVpxPoCDIUWanmIlonozom2Hm+J7dJgBmAQ4oYrW0GRsyT0=@lists.xenproject.org X-Gm-Message-State: AFuF++katkoVCJtz9qUQuLozlVqvgvPoo2bqSOwbw/fqqnA+x8hpPbcN ct9H7dsE+qX2radrP9MnUlfurke7MKzrdWDetuh+q0G4TlExF9a0CUVAUCR/ktAcew== X-Gm-Gg: AYBFou3gNLXZ8vdG/Rn0PnjUGJWPq+WDCPH9xIuHhPjFuvWszKGZ5477i5Eva1QKkWR qZ5QxVS5OTpIvld2eZNEoDNT+cnoOkDCpalmlzRNBPmePjgBNAVN6sbKo2DNpv+2coV0Lw505Hz IKE7x5m0l2BOLH95zhnJwWrVgH/Txm+ZrAGIGaxxE4U/BcD735VQHHaxtq4S3GPdhpo6n5WwkFi vSB+YeIojTyBhuMiNbMGmRrGPYGDxw7COMvA7vloLYmVl4kCu12MsBA4rQUgrk7yBDmwS4Px1sa E8aNYTB84O2MGPycohvMrwhQOesNSyqNaiL2Wdf8xHZJWncZYjXAjqjx0DN0LYMRNnJ9SbOxlOd Fk7kKsgwGcYtxwm0194ACu0tiHY5dIrdoTXu7wGkqXGaFKxvT8kd2eyEBaZDLBI0qWZDUMgcgsV VbxpVXyxYRrvGV3O/rT4INu1LQ3iomQsDySF2VVf44y56+ncsVzzgnWcM+zjyDC/gaWFwKIfKD1 rJ+jWFiy9Sf X-Received: by 2002:a05:600c:8716:b0:49e:6692:27fd with SMTP id 5b1f17b1804b1-49e7a657f9dmr65862005e9.2.1789392441267; Mon, 14 Sep 2026 06:27:21 -0700 (PDT) Message-ID: <45f6e417-ea0e-470c-bfae-e163a65b48d0@suse.com> Date: Mon, 14 Sep 2026 15:27:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789392441-F74C977B-09ED7B40/0/0 X-purgate-type: clean X-purgate-size: 1492 On 27.08.2026 17:21, Oleksii Kurochko wrote: > During migration of a virtual hart to a different guest interrupt file, > straggler MSIs from the APLIC could arrive at the old interrupt file > after the switch. > > genmsi is used despite not supporting guest interrupt files because the > AIA spec guarantees that all MSIs previously sent from the APLIC to the > same hart are visible at the hart's IMSIC before the extempore MSI from > genmsi becomes visible. Hmm. As indicated, I'm learning RISC-V as I'm reviewing patches. This paragraph, if left as is, would make sure I simply can't ack the patch. I just don't understand what is being talked about. I can guess parts, but for example I don't know what "genmsi" is. > @@ -205,6 +207,30 @@ void aplic_hw_write_reg(unsigned int offset, uint32_t value) > spin_unlock_irqrestore(&aplic.lock, flags); > } > > +/* > + * As needed, synchronize with all IOMMUs and APLICs to ensure that no > + * straggler MSIs will arrive at the old interrupt file after this step. > + */ > +void aplic_genmsi_barrier(void) > +{ > + const struct imsic_config *imsic = imsic_get_config(); > + unsigned int cpu = smp_processor_id(); > + unsigned long flags; > + uint32_t val; > + > + val = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | > + (imsic->sync_id & APLIC_TARGET_EIID); Along the lines of a question on an earlier patch: What if this ANDing actually chops off bits? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 14:21:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 14:21:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420994.1647176 (Exim 4.92) (envelope-from ) id 1x67Ys-0007iW-TM; Mon, 14 Sep 2026 14:21:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420994.1647176; Mon, 14 Sep 2026 14:21:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x67Ys-0007iP-QF; Mon, 14 Sep 2026 14:21:34 +0000 Received: by outflank-mailman (input) for mailman id 1420994; Mon, 14 Sep 2026 14:21:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x67Yr-0007iJ-OJ for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:21:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x67Yq-00DbO7-HO for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 16:21:32 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa802e8-e002-0a2a0a5209dd-0a2a4507c1c8-14 for ; Mon, 14 Sep 2026 16:21:31 +0200 Received: from [52.101.66.59] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa802ea-b4ea-0a2a45070019-3465423be1ad-3 for ; Mon, 14 Sep 2026 16:21:30 +0200 Received: from PA7P264CA0143.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:377::16) by GV2PR08MB8193.eurprd08.prod.outlook.com (2603:10a6:150:78::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7; Mon, 14 Sep 2026 14:21:25 +0000 Received: from ZR1PEPF0000E6AE.eurprd05.prod.outlook.com (2603:10a6:102:377:cafe::84) by PA7P264CA0143.outlook.office365.com (2603:10a6:102:377::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.12 via Frontend Transport; Mon, 14 Sep 2026 14:21:24 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by ZR1PEPF0000E6AE.mail.protection.outlook.com (10.167.241.85) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Mon, 14 Sep 2026 14:21:23 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) by AS8PR08MB5941.eurprd08.prod.outlook.com (2603:10a6:20b:296::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.8; Mon, 14 Sep 2026 14:20:47 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0428.004; Mon, 14 Sep 2026 14:20:47 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=XR3MzMMsCLfi1h+dESjG8KtWgGQUHqk8UtKIE8R4AiOvLRkE0U1KQZGxBIj0IDBckU2LDtuzrlySXOSUm7hjhPRBSa3FeqB1gtg+BTFlIYRBUtGiotclj3FfVg/ApT6RvT7QHr0eGmbNef7V3YyC1GOWc6FNWDn94f6IbttzS7eKJRlKC+qVG6jiPmSGyolcixwior6bFun2W+bAOaYRFDEfgZpm4bWrJQeLXlXQpn6ZgTGNKeppFEUjVu7vDEnGGYBj06UQZnPSPaOz3qO1/hAaH5MPiejLy2tWzOSBJr90DsnkzzX426d2gNAH2Z1oGFSYShAxZamwiUk1VMHtVQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zkgII8j+B/QTCnrNsKIPJFbW+bzzcbLKy2xc45UpZ5E=; b=NE2r53R9U9WHfM2TlDGRGwfu9ibzwpG7AlAtMUprXzJN9LWMh1Ongti1DcG1YzJUnmN1SE17q9G/r0wxNMDhjiv30YXz5EkHYySQCDyjdgmUK5fphME+pSG2r8BbR/ZBZiznA+iR2BxHGIhV0ej1iwpbNSJ7m2/i28h/ZXhspMPEgGGTIA8MM9309hLslmYbv2ZORvKOBJ8QAsNfBzgyIA3DpDAwp5hfX/zNsMN3FBGGl4oUZD9+xjnxOJJCWarZzNNePaQkS6J1baroDV0+mzP7hOfyGxpcnZr/uxNIknTvndbwe/HsAOp8zT/HmiQk0W7qZ1FJ9xsBczR5j5amNQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=kernel.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zkgII8j+B/QTCnrNsKIPJFbW+bzzcbLKy2xc45UpZ5E=; b=A1gWcfxgzuTR97Fz99KaJWYhe9KQYmnZ7qVDQ4OZ+7MmqLG/tavH5JbSEezpwV0LJyGwmry8N0DAtqasHpVZedb6mJ11sngGsEdfCURti3vF/k93I0/RHIAvJlH3vmLfFnuA4Lq8tXN/RD5V8zxlR4M3dcq0ZWyt0BIx19teA1c= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BtZEPMsAQEu7Q2aR8kjGAqorM/H7o26fZY4gOl9ETXpEKQxpTLoBEbGepH22GKEPrcM26qxEV36jVCYsvmQxflGWAJuipOppMsXtyhveiaPgJh1lcsCT0r0+ND8TOKqOlB2mFTNAXrW0XB9066235SO6fbYjchYTRr4TpeQgy5h/Mm6XMHqeXKKTIK7hc65jL+ba7WmSb95QDeKSwBOmvKm4m4MasqEXpVzEJwbCkYCI1RnNUrvXA8xchasAEKb3cOJD/AgJZ86CHPTBCGF02aLOR9PRKP3hvDlsey2h/PeVFIDUC6K1bx2if5WJnEJxe+OdXqbv23ah3V/4pmdPHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zkgII8j+B/QTCnrNsKIPJFbW+bzzcbLKy2xc45UpZ5E=; b=SLQNf00nX/qGALisM7+0893bPJYE1HCLB1A2ixREYKLCPVdjyz/Jdyor6hHv5VYeh6DvFYAxv9yDXaAzWgem3kitKrC9DSYjG8AdcE3xNB6wmaZ/Mv2sMFs60mt1LFAZLd8D72xkULjx1YVW5+E5TWScbcxZKLzXqoP6nezCAmDm6xdaP66CHeRW4NxMzXigDZ1u042u2EKhSdMIlPrN0MqaaNzPHPCdHZOc1SRWojMeY35ZBpoHfiUFSZo22eUIwPb8CVPX92jJ7+94TI8w3IzuAJIHuoyVONT1av7jq1JR8p175RaWcsbbilKGdLoHtYO+OtirbpaePKKA4Ui9Aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zkgII8j+B/QTCnrNsKIPJFbW+bzzcbLKy2xc45UpZ5E=; b=A1gWcfxgzuTR97Fz99KaJWYhe9KQYmnZ7qVDQ4OZ+7MmqLG/tavH5JbSEezpwV0LJyGwmry8N0DAtqasHpVZedb6mJ11sngGsEdfCURti3vF/k93I0/RHIAvJlH3vmLfFnuA4Lq8tXN/RD5V8zxlR4M3dcq0ZWyt0BIx19teA1c= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Message-ID: <5f9279ef-2386-482f-b0bc-76a52b52d676@arm.com> Date: Mon, 14 Sep 2026 15:20:44 +0100 User-Agent: Mozilla Thunderbird Cc: usama.anjum@arm.com, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values To: "David Hildenbrand (Arm)" , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com References: <20260903103002.1091859-1-usama.anjum@arm.com> From: Muhammad Usama Anjum Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0364.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::9) To VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3421:EE_|AS8PR08MB5941:EE_|ZR1PEPF0000E6AE:EE_|GV2PR08MB8193:EE_ X-MS-Office365-Filtering-Correlation-Id: 317cca55-8395-46dc-9dcd-08df126b74a6 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|366016|7416014|376014|23010399003|1800799024|921020|11063799006|56012099006|4143699003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info-Original: nHqdZi896xslxpr5bFTsP7Cr5Iu5XTgM2rD0wnDOqRt++y+UelQPkjR6Q93St8VtNPwXSmDJY5Wjo9ONs/+6vxESuzyGfIua1LpeoMBX1Qa+1mpEXoKKEcXwRc9CdBMgGGSLGmNih+sIjYUHjUk7u/X67P10YO1hzxoe0TpayMRQqyTgIKxd8yskXYARn1vLyNJEd8GIvtgV3p4SDAzy7izD0zorHUNMmNIWNbK0NEft6dDMmQrX6RDTfQ97FUgBYURGPme+fPOIGqpdXU++Tv0rrDsWUE4cc/ruX9Pk/D57Yu7K/VqfsLU+3HVLQAvyuoT/gMqcgm6B3ersq5BQqoTudAOYHvgd2Xbqi5vUuPC/EMJxs9w/RqgKNo4toGq46GeUqpG1t8Gsl7q0dzhvd3OlwhITOxUsy9HkBgMs/+ZjdcH7mIzmU8COfLvQrV6SAUPVRDk5VD7u2hvyFNocnr7FEFTaroZV1rFWTYEIS0+hcOQ7Kh0K9fOPSUgTCa/L4q4yx9Jzq8bTF40gPUnIT9p0XciJ1j2UjQ8xQIFCgn7Xzo0y1WdvZ/SKrwdcji04LmGV6ZwEGneS6d7Ev75IExh8tD3DbwRGkGD2eqa6yVFZ92hB9SeRwBygVbHtmhd4zWArLyfAjWsYNjGnJS4len/dRwagvg1JoK8p3TiWlC/wmB6vFo8l1hhXiqgQZ46e1maj7XIemcwE4UD4NBs3Rw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(23010399003)(1800799024)(921020)(11063799006)(56012099006)(4143699003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-Exchange-RoutingPolicyChecked: x6jc8Ibf6nj8zYdsacdPlIriRr5eXndO8f3rVZKtJOglXFytmmpAAYQxI0LC37aEYFHWsK9V/PZU5BtFtWu+DbRMWo4KVBfka1dv0iR1eD0glezqHnmgs3DMsaR3uBUc+zZMuGI8VL6ocwrUpEGsgvECPI0dBL4Ezw5uE/J5cHxbQnXyRouW/cxhx1JNaUr+axWxy1pusRABAMv9TVJzqnW7tE9Qbv+lB+LUAa+KSfgtszliTTvCv/fGmDK4eEtF0Nn87fKeMtw6FrFmlvbSq9PJ9UNyIxmzfysXBfDb5BSlNUIGm/RD7uvrK42NUS/mRnBhC1KU/bxU6UBqIR9juQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB5941 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: ZR1PEPF0000E6AE.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 07a6a9c2-9204-4db3-3804-08df126b5ecd X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|35042699022|23010399003|14060799003|36860700016|376014|7416014|18002099003|22082099003|921020|11063799006|10067099003|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: 0PXH/drgR7Qs700WRE0lczL+BOSRU5MmIevTqtxAkEL/PNBX2UcMsCw9dv+9Iwtq7BUpJXlo9zNsyoWKeGORjpbX3Zd8gcqWSGiqnkrVtMIkR9T7Ughh3Br2SS3keIgA6O0OK39SNIj+YclOcMlRkM8ulLQaUo/h2x1HFwGbhV4HPgpGIkLYE4F25tPCsFLD+Agof2Nr/bh2V67skHeBUjUo1sYL4+xoMA+bH7FLpzieganEQ+V/RBBQ3msyDquBlWE4staCsdTPtAzWuns8GJKJtw/jQDdUyRYmszxWGmN4CNynxaEr06ARdZkUroKjeDspnOaAoYyqNd749aanVHo9a7ddojMJrKQeEPyN4/EsEO+wZM94guHAaefiO7B6yVJ6jFPmjG4ZqjGQnQ9o1ya1OQNqZ8q7UNm5lWtKl4A3Ccd03u8x3tJtC0jlAp3lNnt1UTzIK+GQ+reC3szeHULLhjZZ+stcFFLdhASH+w2yWPCDhDoIegw7EDpiendUlxtiC6tWSNcevp9UUAPIWUDOllo+9KHdWOxzi7v7f7RsV0NJkjrK+fvHwV7/dP8NnWKqs40tEqIk5jr9W0BMWTW0iT+rgk9Sz4RivcU6U3+krHhnKXRynpRGzgX4/2HIqaLmwsqQMhJiM8fQXOe6SSCKzR8vj5qeig/KYC1gwvgmu415tsGAMkO93UqDUc2KXi7ij/esa0dSrfd04awG4mn84rRpWi1PgRUNbJWMeCWASuuCCGJt7eISr7blj7Eo X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(35042699022)(23010399003)(14060799003)(36860700016)(376014)(7416014)(18002099003)(22082099003)(921020)(11063799006)(10067099003)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: YXJdNj1/QTlxWRnwQfr+R2yeVCbxkX48HaqnlyNfPiSGwrzopUJg9UX7IpRpDu0afxOXCX4e7Ut6XzDdapR2/QN896aeTojj8wz2kEkWlUKRIWz5yjYL8+0NRU+ido4gY5yQ0bme9TaZYd/dxicLNs0KJB8f5susEVehPNXu5y1pCFg0DaOwc3XbB0vL19aqIOJPn/Ny/Kt/eP4xnxwvrjh6UxojWmAfQ84wWoueJ+7SpIl/zYV54xVVjg0fA0g7qwQ8hB5+AWjoDK0hlOz89HorhY3oRLJGYRWEXvoI+Za2uxkHM3Cj0xnFfvHfRH/EGykho518dPSmP9e6djoNadPfn1PREOyiI/pExGn3U4ATqT1xDsn1dz/DQrH7pcgr3dG8yrxYsUgRPTleKzZXVtRu4lilQ5LDvKc6np9SnKwUIk9b9ku/iZ1lCOhUxyu+ X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 14:21:23.6584 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 317cca55-8395-46dc-9dcd-08df126b74a6 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: ZR1PEPF0000E6AE.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB8193 X-purgate-ID: tlsNG-ef75cf/1789395691-A72DCAE4-77274F3B/0/0 X-purgate-type: clean X-purgate-size: 324 On 11/09/2026 5:59 pm, David Hildenbrand (Arm) wrote: > On 9/3/26 12:29, Muhammad Usama Anjum wrote: >> Hi, > > Btw, I was wonder whether the subject would be better as > > "mm: distinguish HW PTE pointers from SW PTE value pointers" > > or sth. like that. > Seems good. I'll update. -- Thanks, Usama From xen-devel-bounces@lists.xenproject.org Mon Sep 14 14:28:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 14:28:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421006.1647185 (Exim 4.92) (envelope-from ) id 1x67f5-000089-Jf; Mon, 14 Sep 2026 14:27:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421006.1647185; Mon, 14 Sep 2026 14:27:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x67f5-00007x-Fp; Mon, 14 Sep 2026 14:27:59 +0000 Received: by outflank-mailman (input) for mailman id 1421006; Mon, 14 Sep 2026 14:27:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x67f4-00007r-8y for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:27:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x67f3-00DcLr-6R for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 16:27:57 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa80465-e002-0a2a0a5209dd-0a2a45068716-14 for ; Mon, 14 Sep 2026 16:27:56 +0200 Received: from [40.107.130.53] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa8046c-195a-0a2a45060019-286b8235d017-3 for ; Mon, 14 Sep 2026 16:27:56 +0200 Received: from DU2PR04CA0158.eurprd04.prod.outlook.com (2603:10a6:10:2b0::13) by AS8PR08MB6232.eurprd08.prod.outlook.com (2603:10a6:20b:296::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.8; Mon, 14 Sep 2026 14:27:49 +0000 Received: from DB1PEPF000509E5.eurprd03.prod.outlook.com (2603:10a6:10:2b0:cafe::a9) by DU2PR04CA0158.outlook.office365.com (2603:10a6:10:2b0::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.12 via Frontend Transport; Mon, 14 Sep 2026 14:27:49 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB1PEPF000509E5.mail.protection.outlook.com (10.167.242.55) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Mon, 14 Sep 2026 14:27:49 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) by AS8PR08MB6056.eurprd08.prod.outlook.com (2603:10a6:20b:299::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.8; Mon, 14 Sep 2026 14:27:14 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0428.004; Mon, 14 Sep 2026 14:27:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=PpbQiML79cwS/Mf8O0Rk7owZujki0rksDdePFXtq4e+FYZinNaEeXm6od7B+dEzKJ1we13B6yUkMwsGljRRcWinrNc4odgqYSZ9XqRyyD1isuD7ujsH+VXT2nEUqusY58alcIGrUI764QzoNI0eutCqrZr/YdvpRs98nQrKctN/BqOfJ78qawmWRRW/iRVe4mA+5M/+YNzQP7T+HmEn+if2KssmSTAS9vd/NrpzbOjQ9PIjP5arjXcnHxQJs3DyAbAqZxNtXc907eIbfUA4wfJg1A2Zo0vphzTIjABKstu7d9+xFfkXc7mRd10iFuCmbK5WlKF7+9fncIDGHZmRhOQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q96gATrUbUR0fNAZfspTOLhOnG/Q6l4kaViCzTAeDH8=; b=uBDtjZ/wOrhG0QLOgMJ+/KFV5ujL50Ign1ZVAkgO4ilwc6I3uX9qe8/jVatiKy3iGxxrU5rVKJCFoz1qhxzEfxy7QKsRDdvaNgRjaCSuE+hJszTjdPCMGn74rqW43VX++kY+C3OWp345uphPatPC9dm7LZZKAfVy/kZGg4xHyHCNcxedXc/PoUUXtp84IYYdwip1RnhqXB/uzXFsCYph2GEoTiE7uI4Q84qj7bAxI0ZsaRkaEdog4biRU7Ce+qwJKjMSXI/nw73oXTXCUEavntYB01RbjbEhc3aK9aqzIcNh9ZLCjItn38jo+/PXN8zT/KTfPffXBrRvMo1gWV9x+w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=kernel.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q96gATrUbUR0fNAZfspTOLhOnG/Q6l4kaViCzTAeDH8=; b=CajgCHwvjm1945f923+pGJXwFutOcYDhNNei1u6AtcmC3HlH/OPYz0/p0wetpIxNo2Kv82DRErqMX+YlkuHfDAHEQdcDDj90KmbCj6NmvBZv191hjCxklfzxEPo/Z1AZM0rKU9s276VBAdDunF3pjpZ+YGw+NaCgucq+cj/Q4eI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=F9KV7u71QswuU+0zbfVrY3DlPlQgB3pRKOG1An/XUBk9/MO4UhQuhaHFSovix/vNfs8Aad42B4lo6C18we8BMd6LOk2+Ym2Vhv+YyFxt/lbKkh2kq+cbuBYzTkcH3nWG10Xd5Pwz+dMKBZzLCnkVxDcb13hUGXkZDXbdUm6+xgjfNMrW8MTBcZZDDc3p/PFuWibbML9xwCTZwnV6IJVtbifbl43+JBeI1WlT9XP3r9hrnI9E7ox+TVGCfAgEuiVLh1ta7JfzKoIVbnn0KvjfRIibsAnWpYFrT8zLm/qkDQdAsELDosn9xGLPJuSjRWjEubAB1LL04/AQ2jFBcZuk9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q96gATrUbUR0fNAZfspTOLhOnG/Q6l4kaViCzTAeDH8=; b=bWe4uqgVCK7sWClD4LkTW9t9is7KjjfmDxqogwyY8SX/zoZ8jUMEm5EDCkMolM3Ma3J5ExdNjM0peUh5UEueJpdZ01Y4qoFu7Mt1xKDL+ZHySoeg4crsNhcIPpfnXAgG6Cv/gPPPds9KeJJhXNQx9FGPl5dwNKVsdMKTQH2U9y823gg4sXQjqHpgwimGsTES0TcpaTiinwpvjS/lfvDlp1i9yi3qh46ZxjS+ES/eFky020hBKRfSSYN6ZidQza5FY5pYFy/t6CisYXenpRuc7Y4kdzyj2Dv0qrK3cA2OrA+culFUR9kIOX88cr/VwipPK07N54+gydOUSvt8AGc78A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q96gATrUbUR0fNAZfspTOLhOnG/Q6l4kaViCzTAeDH8=; b=CajgCHwvjm1945f923+pGJXwFutOcYDhNNei1u6AtcmC3HlH/OPYz0/p0wetpIxNo2Kv82DRErqMX+YlkuHfDAHEQdcDDj90KmbCj6NmvBZv191hjCxklfzxEPo/Z1AZM0rKU9s276VBAdDunF3pjpZ+YGw+NaCgucq+cj/Q4eI= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Message-ID: <9edaff57-de65-4335-8439-823519a502ee@arm.com> Date: Mon, 14 Sep 2026 15:27:11 +0100 User-Agent: Mozilla Thunderbird Cc: usama.anjum@arm.com, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, agordeev@linux.ibm.com, ryan.roberts@arm.com Subject: Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values To: "David Hildenbrand (Arm)" , Alexander Gordeev References: <20260903103002.1091859-1-usama.anjum@arm.com> From: Muhammad Usama Anjum Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PR3P195CA0001.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::6) To VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3421:EE_|AS8PR08MB6056:EE_|DB1PEPF000509E5:EE_|AS8PR08MB6232:EE_ X-MS-Office365-Filtering-Correlation-Id: 314c31fd-cf09-48b0-f0cc-08df126c5a53 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|1800799024|7416014|23010399003|366016|22082099003|10063799003|18002099003|56012099006|11063799006|3023799007|4143699003|10067099003|6133799003; X-Microsoft-Antispam-Message-Info-Original: UEMSfUJEaWEajDBturqJu6KW8OYyxCGj8nkyovMvwn6ArMMLLn0c3260UK/wwdFEds3bDLkZUL3NYQhL7jYtpl65ogJB8E+BDguKdgMC8vDX9B48giOr4GcSHNIUeIeXWWqNTZWGLtEBN37eH7v8cArvKr2Erz1nGnf3vFssgA5sc1cyluR+2wKTkTFKgxz9/ZY1ggnEAjazixd2NqALzjzp2Qd5pst9e6/ytHWlzgf6nv29Ks23/8sKt1tT66FvMtI3nR7zczlGJoWKblIc8bKzB4NJtByP/W0KJ2veaNvTL7cpY9v54fREMsTK5dT43T6kLLXLKkEKCBxFk9dLUhXT0++I8bJi+hvWJ3ykzxUtSs8SvJQ0M6iKf/1BV1FyiElrfpu+hzECNlxsMUpVxtya/TwSXiUI9UPuYGhdZIn1hGwt4J7SLouk4pREPvnW/LZ4dn+rERAJGRBF1puD9dKQuPYTvH702Ko0tjytyjmnCbuhgfVIXHJi04kSxQdhxvPLRxXTracWEGen2WFuCkn0+2dwXVlc8pVfCanSEtEaKfVdDY3o2Ao8tHnyWsct8vBZDLy2nXbmcEBFsi6BJp107FlUKmXkH7yqWFFL/wccbCitMCeUbjGOO/QI2tpwMbEjf/EsPpQzixJi/gEpS9YMAqyL163dv00gMJTq1e0= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(7416014)(23010399003)(366016)(22082099003)(10063799003)(18002099003)(56012099006)(11063799006)(3023799007)(4143699003)(10067099003)(6133799003);DIR:OUT;SFP:1101; X-Exchange-RoutingPolicyChecked: Ox0ApicW/xsZTDWWGbIPRo4yID+i+qX2712xjmA8XjBvFrKMx5C+tb5VfmTFicxgxlewKc9OgzJPg6jh2ybwtadXL477GSd2jxXRjrUGFLbT8TdFcR7exGsRGvhuEihw7meD4UQ9iyDkomf7xIdqlmF8inCM2yXnjGx4ISSmGoSi250o4sJGhGQ/bbyX8xaRbqs5Hkhv52+Zm/76e98xCM+z8YxROeWjSENtO3wf8DNYRI0vuJdtAUOp2n6diwN14izvLHXhn99hfG+8bkfZaFzzLTmQrTwE3crm2CHvk8SnIrp4j+rKiHObtz1HZ3NLrysHib1aIOMyNJTeg9x73w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6056 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF000509E5.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 372fb2b5-2aa8-446c-f3b8-08df126c45b1 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|14060799003|1800799024|82310400026|23010399003|35042699022|36860700016|13003099007|10063799003|4143699003|11063799006|56012099006|6133799003|22082099003|18002099003|10067099003|3023799007; X-Microsoft-Antispam-Message-Info: 4ogOTScx6ErN5/M/7+VF5xKhLzmxGm4GC8n7UWC01odvgAJAEZHWaRGn8D6N1JOJ792ypYrN6XHDHkL0NoYLWDHNU3aph+okWZGAeXzGFQ2MXNGMnIxQ3Q30vicrjlVYI1Qn0h7AJjyXh5tHKr0ZQJCzfh7C7KuBYOVUOgpUvxf7X+AJct8w300RQnf8KKdsn8ae/BAI+3xOEVhZfzgBVROPQjjeoygLwvN+XRGrl5vhGZOiTyTfvDwd9zEnlBgROSZgrxCkVnztZ+HLRqI7dSBqCpTNv1CPQTNfzY2gjXEGktRcAo7ur+K6aEsNGrhQJUD+sBa6kaoGbo2pIENHf87ihSBnxswuwngaRw7CD6m3/uq87A52UciThDOFrFVp9u2sGKZXoLeSJAConMzLpH3k/SshD8H+5+sQ/wZgsrpjaSpJ0WP95Ncey+MgBG563Y84Jm7srdpqkATjyb/dJqBasODoavijNSGhazaaDf8KMGcjUGaQ05rZDeYejDI/x61QEnxW+iAIv9QUrf0va3qpkuxb1vdMr77y+gTxQESE7v6HRzEdKJCFwrVWW2yvfzQlS66AYeRZzz9nJZ6W5YDQWuDvQ0F9uRSC7fh/hNCEdXhc8LHl1fSAc2l4Xaz7glLSKXnZLSRpiRP4Z7C4t/M7VQwpYcubJ+d6gcbfJzS2F93dfgT2ppbjSN1vBPhF+gFvEVpIJ7227UybkDHDew== X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(14060799003)(1800799024)(82310400026)(23010399003)(35042699022)(36860700016)(13003099007)(10063799003)(4143699003)(11063799006)(56012099006)(6133799003)(22082099003)(18002099003)(10067099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ZGMEqhFUi2qhN1Lau3ZeSYgSkk85im6sY2Oo3siiB3KWw+svQD6+JA/ceJFkEG7Xy0hpgo8RlV1zeb8jrPhbA0gtWWX/aJaEmdl/WoZ69cuLy/wGJtajbRaEbHEC1jk5Q7H55rFl7/jBDhtiBRZ0laSQGCGwnmokT6E3IFDr+Z4qB/tsEpINP6fVdZAsgUCibeSURBFVJaMDZwr+7BnUiiEKPh9FpG7vFuHEx2iz8mgshmT15GHzlc6evfAvdED8wO+p5oIeEQcrfWLMdBhP6+IJtikJm7xnv3tzfsl+aag9IAOFGNZe+JRz11n6wAI2Vx2Y6PkszSSCsdUiKYeBQEZYMjDg78IUKoQFBI4DcW+BAFabpFUPhRhuzxUeQW0NDBHEwdvudXrH2LRuwJcyvZqkuAJC6OMt/5FObWJt3rlmmCaDv7CR4inUC0vxr3NJ X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 14:27:49.0313 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 314c31fd-cf09-48b0-f0cc-08df126c5a53 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DB1PEPF000509E5.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6232 X-purgate-ID: tlsNG-16d1c6/1789396076-F520877B-7EF08637/0/0 X-purgate-type: clean X-purgate-size: 3758 On 11/09/2026 5:55 pm, David Hildenbrand (Arm) wrote: > On 9/3/26 12:29, Muhammad Usama Anjum wrote: >> Hi, >> >> pte_t currently describes both a software PTE value and an element stored >> in a PTE table. Consequently, pte_t * can point either to a software PTE >> value, often a stack copy, or to a PTE-table slot. The compiler cannot >> distinguish these cases. A value pointer can therefore be passed to an >> interface that expects table storage, while table storage can be read by >> direct dereference instead of the architecture accessor. >> >> This series begins a staged conversion at the PTE level. It introduces >> hw_pte_t as the element type for PTE-table storage and converts generic >> MM to use hw_pte_t *. Software PTE values remain pte_t. Interfaces that >> intentionally return a value through pte_t *, such as install_pte, >> remain value interfaces; the relevant parameters are named ptentp to >> make that distinction explicit. >> >> The generic definition aliases hw_pte_t to pte_t unless an architecture >> selects ARCH_HAS_HW_PTE_T, which enables a distinct generic wrapper named >> __hw_pte_t. Some architectures define pgtable_t in headers parsed before >> the generic hw_pte_t typedef is visible. The structure tag allows those >> headers to define pgtable_t as struct __hw_pte_t * without creating an >> include-order dependency. This is required when converting s390, m68k, >> powerpc and sparc. >> >> No architecture selects ARCH_HAS_HW_PTE_T in this series, so the >> representation and behavior of every architecture are preserved. ptep_get() >> keeps its existing READ_ONCE() semantics and converts the stored element >> through __pte_from_hw(). An architecture can later select the option and >> convert its PTE interfaces to make the distinction compiler-enforced. >> Architecture PTE implementations and most architecture code are >> deliberately left for those later opt-in conversions. >> >> Here, hw_pte_t identifies PTE-table storage rather than table lifetime: >> complete PTE tables use hw_pte_t whether or not they are currently >> linked into a page-table hierarchy, while software PTE values use >> pte_t. The distinction between complete but unlinked tables and >> hardware-reachable tables was raised during discussion and remains an >> important point for review. >> >> PMD, PUD, P4D and PGD storage are deliberately out of scope. They can be >> converted in later series after the PTE boundary is agreed, avoiding the >> PMD-specific cases that made an all-level conversion difficult to >> review. >> >> Most mechanical pointer conversions were generated with the Coccinelle >> script included below, then audited and fixed by hand. >> >> This series does not add a second ptep_get_once() accessor and does not >> remove or replace STRICT_MM_TYPECHECKS. >> >> The design discussion is available at [1]; while the original idea came >> from [2]. >> >> I've the patches here [3] for arm64 conversion which I used to find >> usages in generic code which I missed during development. These would be >> sent separately. > > Unless there is more feedback on the overall approach, the next step for this is > to have at least one architecture support posted. > > We should only merge this if at least one architecture (better two? :) arm64 and > s390x? ) would merge the architecture bits. > > That is, we should get an ACK from the arch maintainer son the common code bits > and the arch bits. > Thank you for reviewing the series. I've posted the patches for arm64 just now [1]. Let's wait for arm64 maintainers to ACK the patches. [1] https://lore.kernel.org/all/20260914-pte0_arm-v1-0-bb53b663e396@arm.com -- Thanks, Usama From xen-devel-bounces@lists.xenproject.org Mon Sep 14 14:33:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 14:33:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421015.1647194 (Exim 4.92) (envelope-from ) id 1x67k7-0001vA-4x; Mon, 14 Sep 2026 14:33:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421015.1647194; Mon, 14 Sep 2026 14:33:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x67k7-0001v2-1w; Mon, 14 Sep 2026 14:33:11 +0000 Received: by outflank-mailman (input) for mailman id 1421015; Mon, 14 Sep 2026 14:33:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x67k4-0001uw-Pb for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 14:33:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x67k3-00AEEo-OY for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 16:33:07 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa80597-2eae-0a2a0a5409dd-0a2a450a97a2-40 for ; Mon, 14 Sep 2026 16:33:07 +0200 Received: from [52.101.57.32] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa805a2-f2d2-0a2a450a0019-346539202a16-3 for ; Mon, 14 Sep 2026 16:33:06 +0200 Received: from MN2PR14CA0018.namprd14.prod.outlook.com (2603:10b6:208:23e::23) by BL1PR12MB5826.namprd12.prod.outlook.com (2603:10b6:208:395::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Mon, 14 Sep 2026 14:32:54 +0000 Received: from BN3PEPF00022BCB.namprd03.prod.outlook.com (2603:10b6:208:23e:cafe::68) by MN2PR14CA0018.outlook.office365.com (2603:10b6:208:23e::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.12 via Frontend Transport; Mon, 14 Sep 2026 14:32:54 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF00022BCB.mail.protection.outlook.com (10.167.248.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Mon, 14 Sep 2026 14:32:54 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 14 Sep 2026 09:32:54 -0500 Received: from [172.20.10.246] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Mon, 14 Sep 2026 09:32:52 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=P7mJTt209GHhz8k+14/GlHVQtav9EV5QD/AmEUw7pA2KOJ6IYICIMgM4NPUVA5TzFl8ybRmY4+wpuI2Nv3G9F55iSmQPaoZLgoaM490z8JYaYPwTHMu2m4b6shxjPLvmBwQCB50BNOtO3aJn6x8gsskwJ7Ps0DMa3rI2JZVjiGgMONWj55hdaDSYfB/xMZkjJBQYXQlIElbBlwJ1og275nZUenMTrN2RwY5heXFafpPhOPbzb4vHciAMbVnwLX3A02eSi97NwcTFX1Q2fGi8xyRbeJV4joGIUHOpY82CylbdkFiP9UT2Op2l2SwQIvNWl8JNHjf4WPks5vwJ+hkkCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jtEkKwmNvCfF5torAU4XaBwSUSR88U+gxejZ7gt4JHY=; b=YYH3QM+sns6pFxV7FqX0G1taFgb2a+MqxJK0y2Du/jY/GuYYftGCY+kGuf54ntOPjdm1zoKgRCoQY2EK/FEEVif52+gPjpXpXx8ds+S+Txy5H/qSxBeDar/JaZd3o+7az8AYmKImxhLexal4f+VJXb32zENX3XLFiben09RMZAPIgB6Jil2RYZMvFBpHcYGONrJHwCrr0SUerxIMGxSFOlGrX0pFTbxgPnXogFJ93akp7zxnaBgnZueByStMPceyg5G38bUs628QVdFDM50vACWgobRHSARXXI049O7BplkeSZeUJ8iWow794zWhOoWoQu5gva9sxy9mb1QlxhHWxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jtEkKwmNvCfF5torAU4XaBwSUSR88U+gxejZ7gt4JHY=; b=nZ+HRRbEaXBJfD4QD06Sx39peqLbIP7VwNBr1Ckqw7FAewjMma41mowoZD4HjzoNQf9hGZ0XMQ5DRAYfU0rYxfDzkcUHIYYSmgQXjsbl1O1BzEVWV/fP14GxFxUAwI8XzArUoXkDcn9yXs4xk2KPtT74+aUmzbHEyysRRWzeeLI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Mon, 14 Sep 2026 16:32:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 01/20] xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page To: Oleksii Kurochko , CC: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BCB:EE_|BL1PR12MB5826:EE_ X-MS-Office365-Filtering-Correlation-Id: f0f73f0e-70d0-4848-2772-08df126d1085 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|376014|1800799024|82310400026|36860700016|22082099003|18002099003|4143699003|10067099003|56012099006|11063799006|5023799004; X-Microsoft-Antispam-Message-Info: mkPuD9TrbEdT0uL8rNE8XAjXs0Y2tsU8dkp0ol6N7fvggbtZWqrnqmPA30oiqGM1HEir77OHXSuAQ7UmzxowgBhyIuRJOTP/wTtyMkzHlePrBPh/JWtPKQiDu687CK+oMnuPTmmLMRxtANdCfssxduBl2Zw6vUJKlZ8td7EEm0vn16pE4HCOjdTOuMEuOQJHEd3MVrNC3olZFRncX6VFNEf+RY9zggWVjirXqdvoZy/xmwpSTLz8gButayglEh9V08giw/Xh2GR0S/3DZkd9926y+Tjbs+1AjZfNpOEwb0DaLLRDxRUaEbSbGhsCPVuNcwx/2WMywArDuTk0P2ulpoVQhR8F70txfICIU3dCfOB2/ghrZsmFouacgOak9ruR+11ToS4c++wZ9asWAH9FCuX4btGKgYV/9bIlIv0ehJw38xBL2Gg6UWehzqh2/OQ7PT+Farbh+LtUrrK29RzdqG4sPMAmRKODZop0BpNzF9rZd/5NMK7uy6LJ6/IwYA6BjxjSyL+YDJspn/8aJ1YV8yhR6Z5fXSN52a5dETyyWmufmYgnWcr2e0nXZuLYfCKJVPo99ZLum7+p1k7BfKYJO5FNZIQLgGV1bUp3FecPZmAj9ASK60DuvDfjGCdG+9LvHCa2vWW5vtleNpHa1VfYQnGNTCb4CChg2jIVAKc8UVLTHfdsElqA5NIE88dD8X0l X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(376014)(1800799024)(82310400026)(36860700016)(22082099003)(18002099003)(4143699003)(10067099003)(56012099006)(11063799006)(5023799004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 4rGSga3CxuxW+HV1+EYTt1PZGFG9LHLiRQVWZEmvI2MPUO8c/8Ch14vQHCz6nnhjkbl3VfI4ee6uF46SIMeSyfQdM5bSqBdTiLR7b2ND1ykd5I4dKN0ivGEaM0MdHcqk+rDdAcSir8u9vPVb5UOOumteyxX2E2BbWGJu4JUJarMMyRK03CpMZ+J/uQWTfxp9JkKaNguy+C3Fv7oOf3lfkqr4pJU5EsCiVazrx42j5Nw6f3UFD9T0Cg/W/YiW2fVAeDNtjXvfWFxxbtTxbt7m11ysIiL8sN0qi3kbG6ju9hVj1ZZDcof0StnVhdSmk4m4j195RNdukVGtz3tl6hEZ51OqoOTTBYUhn9aqOQXXU0l9Ix7rowsX9nMzXDeyNuuNVCUPTUXHky5cVgM7Wwv7dY+r67mz2mNLVrpUO9Erdd9AdrNyHF7AoWP2K2CGWdeV X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 14:32:54.7360 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f0f73f0e-70d0-4848-2772-08df126d1085 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF00022BCB.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5826 X-purgate-ID: tlsNG-4011c0/1789396387-506CECFC-669C85EE/10/73395122804 X-purgate-type: spam X-purgate-size: 2801 On 09-Sep-26 17:07, Oleksii Kurochko wrote: > On architectures that run guests in dom0less mode without the PV ABI > (currently RISC-V), no shared_info page is allocated and d->shared_info > remains NULL throughout the domain lifetime. Several places in common > code access d->shared_info through the shared_info() macro or directly, > causing UBSAN null-pointer errors on such architectures. > > Rather than adding runtime NULL guards that are logically unreachable > on x86 and Arm (where shared_info is always allocated), introduce a new > Kconfig symbol CONFIG_HAS_SHARED_INFO selected by x86 and Arm. > > On !HAS_SHARED_INFO the shared_info() macro expands to a dereference > of shared_info_absent, an extern pointer that is declared but > intentionally never defined. Any use of shared_info() that is not > dead-code-eliminated will therefore cause a link-time failure, making > missed guards impossible to overlook. > > The 2L event-channel ops call shared_info() and must not be compiled on > architectures without a shared_info page, so event_2l.o is gated on > CONFIG_HAS_SHARED_INFO. On such architectures evtchn_init() installs the > FIFO ops as a placeholder instead, so that a later guest opt-in to the > FIFO ABI via EVTCHNOP_init_control has no special-casing to do; if FIFO > support itself is also unavailable (!CONFIG_EVTCHN_FIFO), a dedicated > no-op evtchn_port_ops_none table is installed instead, so that > d->evtchn_port_ops is never NULL. evtchn_fifo_word_from_port() is > guarded against uninitialised d->evtchn_fifo so the FIFO ops are safe > before evtchn_fifo_init_control() is called by the guest. > > With CONFIG_HAS_SHARED_INFO=n all vCPUs fall back to the global > dummy_vcpu_info, so writes through vcpu_info() could leak data between > vCPUs. Reviewing the write paths in common code: the write in > map_guest_area() stores the constant ~0 so nothing serious would happen > if it were leaked; the event_2l.c paths are not compiled on > !HAS_SHARED_INFO, as event_2l.o is gated on CONFIG_HAS_SHARED_INFO; the > write in vcpu_info_populate() targets the new mapping buffer, not > dummy_vcpu_info. > > Outside common code, the remaining writes are x86 PV-specific, for which > CONFIG_HAS_SHARED_INFO=y. No code changes are needed. > > Finally, struct domain's shared_info field itself is gated on > CONFIG_HAS_SHARED_INFO, as it would otherwise be a permanently NULL > pointer: every user of it is either arch code for an architecture that > selects HAS_SHARED_INFO, or common code already guarded by the same > Kconfig symbol. > > Signed-off-by: Oleksii Kurochko > Reviewed-by: Jan Beulich Acked-by: Michal Orzel #Arm ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 14 15:02:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 15:02:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421063.1647202 (Exim 4.92) (envelope-from ) id 1x68CY-0007mR-CX; Mon, 14 Sep 2026 15:02:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421063.1647202; Mon, 14 Sep 2026 15:02:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68CY-0007mK-9X; Mon, 14 Sep 2026 15:02:34 +0000 Received: by outflank-mailman (input) for mailman id 1421063; Mon, 14 Sep 2026 15:02:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68CX-0007mE-JS for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:02:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x68CW-00HCzN-JA for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:02:32 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa80c83-e002-0a2a0a5209dd-0a2a450bcdbc-22 for ; Mon, 14 Sep 2026 17:02:32 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa80c87-b7e8-0a2a450b0019-4a7de14ce8e8-3 for ; Mon, 14 Sep 2026 17:02:32 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4834977ae75so1180753f8f.3 for ; Mon, 14 Sep 2026 08:02:31 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.149]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb2ecf2esm27574599f8f.2.2026.09.14.08.02.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 08:02:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789398151; x=1790002951; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=SiHZaQhv67cyk4hXA/7ZoxNWw/khsJFenYx83nLehNk=; b=DK/8zIHDjPP1PGPU2k3KFJUY/v+MNKEuvw7/KI/ZnyEwBDkP1hwLa4s67ggExSWTPK 7l0p+wdS8GmziAwz6QrDRu76YA1up8zUCIk7l2+Xy7cUBpZ10d+YgL5OnW580NG5FiVi UUQH9NALHJWXwZ1L9zTb1hO7X2m74lVkIprdMIG6v2VoO2Sj/iWkMaEqnNDRpncYIrP3 IJLF1NDjHmW2wfbgNahkP8c+qCQb2RbhL8iMtIYzgu9gDckG+o4X+2jXKJjOdcD7O/Kb ALt+30cJdWdNy2CuANixFEynhyf3jg2hEAc/fYCytxd0yt0vGcXVlMyJohal+86EgJ3h edcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789398151; x=1790002951; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=SiHZaQhv67cyk4hXA/7ZoxNWw/khsJFenYx83nLehNk=; b=mN9rG5jos8GGs76h+K4ktYbcM62mISL8mk3ndVp1AQOPxWvV86w0KOqTJth4/sQMXG 6ICKv9/AYsF2UWEZ22S+kjSVJpfSvM51vQpawSqQ9w2IiLdwxz/6Ja+L0NQziBluVg8N gkGukzfLkJ888b9PzROzC9ZMauwG38L/XGsrzfZt43M6V1sAqD+OMhQhaDInxzIBtUeb SO9UBg+4i2RkRnYL63aJf/AfRyKl3/Ju9qFiM9xLlTO2Aj/3qwoLkNfpEDS4PBT9n+Fw w7QjUlYbN1ftw4JTUbWOGAXK7uZNXCtNUGykAP4Q+fnKrNEFTDX7WJyin0dqZSa0QKJG T8/A== X-Forwarded-Encrypted: i=1; AKwUvBzZ5613IErjwy40y6gbDW6LHidoKxY5Nxb3ikpVynUs0EovamNuNgCWEZDkwmkBeat/QiPdLK4Gcdo=@lists.xenproject.org X-Gm-Message-State: AFuF++lBT5UfN0ZDP70f5tRO5UOoKsTfnU/ZuLaK0RdpnYfNsjIeggEc Z+Lmvss1x93gETm8O3P3gCWYPlmsOx57i2bNVR66MHf3g7YqV/XJ9mgIvwN+z35yhg== X-Gm-Gg: AYBFou2sfmtkArCTgbF70QBnSLYiH6JfNoBE/DJNR9Geq+cQcbEsxuMoxwPqA9g47sT 6GhwACmBEao0GqG2DXB52BKebbgeq54xvOiVouIru1tDXWS98va9NU3Clzsfa0ypjphLATKmafn 1on/eE8LCgbGrkkYB2gsn7RP7+Y+LINJZXCpLkgoBeTk03TNON42nN5Cxx1gXxDN2F4vWpRIDH0 15/Ifu2I8+liq/Iiug6FMJuM9ZePjdIzzaeURL/dJRxr7lZyfusLH2+k9xbZcUKZ9mn3laJNmXH Z6rjx33Ij6vVAWacOQiVtnt1odX9Lmayqz3vH+CjSp48w02AjPgBIvaXh+KRvrFt8l+nIfww8Gc 6T3UeFav8vGChRzHkzyxrBhQVAAE/IfiwvcuPf2E33ltMdxckgzNdxGJAGGOTGFHinJtgoXCZ25 x0SuYkT63Gz9ae5Wn0gH0tuan/5YQp8FgxdXeMq2NJAztzW9qKN0tek8P4KoZGS4mi6/oXaa4Nh HiPyYd3Lr1j X-Received: by 2002:a05:6000:4b05:b0:485:acdd:1524 with SMTP id ffacd0b85a97d-48702afdde6mr3943134f8f.11.1789398151205; Mon, 14 Sep 2026 08:02:31 -0700 (PDT) Message-ID: <2394a616-16be-4657-be17-0a2dafebaeee@suse.com> Date: Mon, 14 Sep 2026 17:02:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789398152-1A4DB9EA-6D178448/0/0 X-purgate-type: clean X-purgate-size: 4044 On 27.08.2026 17:21, Oleksii Kurochko wrote: > @@ -60,6 +61,12 @@ static unsigned int __ro_after_init guest_num_msis; > #define IMSIC_DISABLE_EITHRESHOLD 1 > #define IMSIC_ENABLE_EITHRESHOLD 0 > > +#define imsic_csr_read(c) \ > +({ \ > + csr_write(CSR_SISELECT, (c)); \ Nit: Excess parentheses again. > @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) > spin_unlock(&imsic_cfg.lock); > } > > +static bool imsic_local_is_pending(unsigned int id) > +{ > + unsigned long isel = > + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0; > + unsigned long bit = BIT(id % BITS_PER_LONG, UL); Both can be unsigned int, can't they? > + return !!(imsic_csr_read(isel) & bit); > +} No need for !! here. What about endianness, btw? Does the IMSIC always match the CPU (and its setting)? Overall, what does "local" in the function name signify? (For a static function, the "imsic" prefix may also be unnecessary.) > @@ -497,6 +523,27 @@ static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), > on_selected_cpus(cpumask_of(cpu), func, data, 1); > } > > +/* > + * Ensure that all the MSIs the APLIC has already generated for the hart this > + * runs on have really reached the hart's IMSIC. > + * > + * The barrier is the one described by the AIA specification in > + * "Synchronizing interactions between a hart and the APLIC": ask the APLIC to > + * send an MSI to the hart itself and wait until it shows up as pending in the > + * hart's own interrupt file. As it says nothing about MSIs on their way to > + * any other hart, it has to be executed by the pCPU owning the interrupt file > + * the MSIs were being sent to. > + */ > +static void cf_check imsic_aplic_sync(void *data) If the parameter isn't used, maybe best to name it "unused"? > @@ -848,8 +899,22 @@ void imsic_migrate_vcpu(struct vcpu *v) > if ( v->arch.last_cpu == NR_CPUS ) > return; > > + read_lock_irqsave(&imsic_state->vsfile_lock, flags); > + old_vsfile_id = imsic_state->guest_file_id; > + old_vsfile_cpu = imsic_state->vsfile_cpu; > + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > + > + /* > + * We don't support SW interrupt files at the moment. Bail out before > + * anything is touched, as the old file has no owning pCPU in that case > + * and there is nothing to retarget the producers away from. > + */ > + if ( old_vsfile_cpu == NR_CPUS ) > + panic("IMSIC SW-file isn't supported\n"); > + > /* > * At this point, all interrupt producers are still using the old IMSIC > + * VS-file so we first move all interrupt producers to the new IMSIC > * VS-file. > */ Isn't the new part of the comment premature? Moving doesn't start until ... > @@ -870,5 +935,43 @@ void imsic_migrate_vcpu(struct vcpu *v) > /* Zero-out new IMSIC VS-file */ > imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); > > + /* Update G-stage mapping for the new IMSIC VS-file */ > + if ( imsic_map_guest_file(v, new_vsfile_hgei) ) > + { > + domain_crash(v->domain, "Migration to hw interrupt file failed\n"); > + > + return; > + } > + > + imsic_update_state(v, new_vsfile_hgei); > + > + /* > + * TODO: Modify the relevant translation tables at all IOMMUs so that MSIs > + * for this virtual interrupt file are now sent to the new physical > + * interrupt file. > + */ > + if ( iommu_enabled ) > + printk_once("IMSIC: IOMMU MSI retargeting is not implemented\n"); > + > + /* > + * If any interrupts at an APLIC are forwarded by MSIs to the old interrupt > + * file, reconfigure the APLIC to send them to the new interrupt file. > + */ > + aplic_reconfigure_target(v, old_vsfile_id, old_vsfile_cpu); ... here, as it looks. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 15:15:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 15:15:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421083.1647212 (Exim 4.92) (envelope-from ) id 1x68P0-0001SA-E4; Mon, 14 Sep 2026 15:15:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421083.1647212; Mon, 14 Sep 2026 15:15:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68P0-0001S3-B1; Mon, 14 Sep 2026 15:15:26 +0000 Received: by outflank-mailman (input) for mailman id 1421083; Mon, 14 Sep 2026 15:15:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68Oz-0001Rx-5x for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:15:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x68Oy-00HFR2-1S for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:15:24 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa80f7c-e002-0a2a0a5209dd-0a2a4508e680-26 for ; Mon, 14 Sep 2026 17:15:23 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa80f8b-f659-0a2a45080019-4a7de14cb474-3 for ; Mon, 14 Sep 2026 17:15:23 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485984ebf5cso1731564f8f.0 for ; Mon, 14 Sep 2026 08:15:23 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.149]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb32e8d1sm28048390f8f.11.2026.09.14.08.15.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 08:15:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789398923; x=1790003723; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=NuF/cpRbw+GzcHinI5yNpRgxXswL5i7y2FE8bwjfAKY=; b=c/T8N/ezeRO+0sn3gec80chBKgNkMY9Ezi2Cg82DB7ASWv97jhTAHuTGdUUaIYVMF1 xJZjq0cZFujjpd8h8T+xtijnFvXj35X4YE717RGzE00b79voyCvZSEhlIZgTVHNAGrvq pqPdpYxqlP88H/W+MmNfR54zrG0wWaCzNa904StXQ0fdeFevvUFJJmQanjFKmOIs+UcB 3TKCvdg+Sm4fxmx1u2tEvH13du+/TQ2wlSfq/BbQhvVbKqnAwSS480FgTuoBBQfQNxHU vYEJCaN3dayDLfgjhnY9p0o3p/pegthx+ZkqNE3w7whrjkDR3UxuW1T8/CkO9TOEGVqS C9gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789398923; x=1790003723; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=NuF/cpRbw+GzcHinI5yNpRgxXswL5i7y2FE8bwjfAKY=; b=p/+chJAmoHnAj51IdJGB9SljmYIR8197McIpNqjSSvTdU3HXxrLdz62YetpMRjQwRO hrnVXiXlNTJPzQykiB02sJiDz6F1RUFXFQ0rt+7e/CQoROnDLj4Yu0mIPq9g032grHsC 7gylDDdu27R2M1oP0ZhPTJzyCOtKXTOF8BY5dnu23Qv7nDEd67M16t9rlwfcN06yqhDd eE8ztMG52rUJj46NmOwR9BBDPkxnmYUboc+joGGSnxaFob6j+GksCIMIUbASh/8PLLzL kkeUchNdtMfm09V2m5/G0iZeGf/YUoGnuMS53m0KRlLdp98YSPEIFhsDs6Dtt2Ele8+x QddA== X-Forwarded-Encrypted: i=1; AKwUvBxw1VrjcFnLaLxX+UZvD4nMNX0zyZcDXvvsL+yG+/x/ZRa15+COVMSdqmZ1OEiGTlAEaAE2pHaBAbQ=@lists.xenproject.org X-Gm-Message-State: AFuF++n3RC1UbjzydDU0L/4wrYHXoGj1/YjgJLCVxRGGc7w4jH5XwJBC WYfJHI2u4J2CbaSo4ApW1MB9l/yVNajhoPkJSXSDWy8hNQqt/ylQ2z9jFpe68IkYJQ== X-Gm-Gg: AYBFou23JTksErlh61izXNdTAsS9kXgrWSKvgQzy75wbCU6Omy7bmBUfZsuG1yh4Tqe pHMJHGO39QkSqFBJe65rp74qJbL68YCxK0tS/L8t1nRvmVkbnJ6d5uVFmlS14KpTf+9h0MQaPs8 Y2bStucgBrx+kXQ/Pu/YmamTsxzHJU0bkHn/LNfPcnpr9E2W/f8Mp4wQB1gWFA3N53iA9GEfXFE URZomd4Bvf43RzESGkJoooxf7Qew5ssdvExOmnuFE+UVAlOKccJZk2Hpkum6Z8qHeMWMjhl+GmM tOUQu/t/MEC89UWISokwjsbZfSZ3zWwcmhdPmpA87xxVLn0UO0+uTw6jmIBgc9aMGcDL1dTnmwJ p5EkRAa7grtgKPbfJB//xrWp7CILVaPCneQFHy2A8zHpNZoftZd362RpMPhOjBZEl+WjjpYNebt GPvxyZ1ZZqixHk6Iq4SAbojo4qGniK3Vew7tHLszlCMCRhTFpVKnNPt3ajfLch+BahngdgU9ZGM HM6hhFl45Et X-Received: by 2002:a05:6000:1861:b0:485:9b35:a20e with SMTP id ffacd0b85a97d-48702b30773mr3580941f8f.56.1789398923193; Mon, 14 Sep 2026 08:15:23 -0700 (PDT) Message-ID: Date: Mon, 14 Sep 2026 17:15:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789398923-D694287B-276EDC7B/0/0 X-purgate-type: clean X-purgate-size: 3213 On 27.08.2026 17:21, Oleksii Kurochko wrote: > At the old interrupt file, dump to memory all the eip and eie arrays). > After this step is done, the old interrupt file is no longer in use so > old intrrupt file VGEIN could be released. > > Restoring of old interrupt file state will be done in follow-up > patch. > > There are cases where it is needed to specify on which cpu it is > necessary to VGEIN should be released so update vgein_release() to > deal with that. Beside this being difficult to parse, it looks like it is inapplicable? As said ... > Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > against silent incorrect behaviour or unexpected panics in guest VMs until > the function is fully implemented. > > vgein_release() is stub for now and will be introduced later. ... also here? > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -56,6 +56,24 @@ static unsigned int __ro_after_init guest_num_msis; > */ > #define GUEST_IMSIC_MAX_MSIS 255U > > +/* > + * The interrupt identities an IMSIC interrupt file provides are 0 (which is > + * never valid, but still occupies a bit) up to IMSIC_MAX_ID inclusive, so > + * IMSIC_MAX_ID + 1 bits have to be covered. > + */ > +#define IMSIC_MAX_EIX DIV_ROUND_UP(IMSIC_MAX_ID + 1, BITS_PER_TYPE(uint64_t)) As before - plain 64 please, or it needs to become clear where the uint64_t is actually coming from. > +struct imsic_mrif_eix { > + unsigned long eip[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; > + unsigned long eie[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; Same here. Yet better may be to use DECLARE_BITMAP()? > @@ -85,6 +103,15 @@ do { \ > csr_clear(CSR_SIREG, v); \ > } while (0) > > +#define imsic_vs_csr_swap(c, v) \ > +({ \ > + unsigned long r_; \ > + \ > + csr_write(CSR_VSISELECT, (c)); \ > + r_ = csr_swap(CSR_VSIREG, (v)); \ > + r_; \ > +}) Excess parentheses again. Plus - what use is r_ here? > @@ -130,6 +157,21 @@ do { \ > imsic_switchcase_32(F, ireg + 0, ##__VA_ARGS__) \ > imsic_switchcase_32(F, ireg + 32, ##__VA_ARGS__) > > +static unsigned long imsic_eix_swap(unsigned int ireg, unsigned long val) > +{ > + switch ( ireg ) > + { > + imsic_switchcase_64(imsic_switchcase_ret, IMSIC_EIP0, > + imsic_vs_csr_swap, val) > + imsic_switchcase_64(imsic_switchcase_ret, IMSIC_EIE0, > + imsic_vs_csr_swap, val) > + default: > + ASSERT_UNREACHABLE(); > + } There still wants to "break" in the default case. > @@ -973,5 +1071,11 @@ void imsic_migrate_vcpu(struct vcpu *v) > * to the new IMSIC VS-file. > */ > > + /* Read and clear register state from old IMSIC VS-file */ > + imsic_vsfile_read_clear(old_vsfile_id, old_vsfile_cpu, nr_hw_eix, &tmrif); Why is &tmrif being passed into the function, when it's not otherwise used here? The function could itself have a suitable local var. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 15:21:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 15:21:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421092.1647221 (Exim 4.92) (envelope-from ) id 1x68UJ-0003FI-Vr; Mon, 14 Sep 2026 15:20:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421092.1647221; Mon, 14 Sep 2026 15:20:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68UJ-0003FB-T8; Mon, 14 Sep 2026 15:20:55 +0000 Received: by outflank-mailman (input) for mailman id 1421092; Mon, 14 Sep 2026 15:20:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68UI-0003E0-S3 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:20:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x68UG-001jua-Vi for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:20:52 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa810d2-8faa-0a2a0a5109dd-0a2a4509cabc-6 for ; Mon, 14 Sep 2026 17:20:52 +0200 Received: from [52.101.52.54] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa810d2-be1a-0a2a45090019-34653436e8f9-3 for ; Mon, 14 Sep 2026 17:20:51 +0200 Received: from MN0PR04CA0029.namprd04.prod.outlook.com (2603:10b6:208:52d::34) by SA1PR12MB7038.namprd12.prod.outlook.com (2603:10b6:806:24d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.11; Mon, 14 Sep 2026 15:20:47 +0000 Received: from BN1PEPF00018548.namprd05.prod.outlook.com (2603:10b6:208:52d:cafe::7d) by MN0PR04CA0029.outlook.office365.com (2603:10b6:208:52d::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.12 via Frontend Transport; Mon, 14 Sep 2026 15:20:47 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00018548.mail.protection.outlook.com (10.167.248.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Mon, 14 Sep 2026 15:20:47 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 14 Sep 2026 10:20:46 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 14 Sep 2026 10:20:46 -0500 Received: from [172.20.10.246] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Mon, 14 Sep 2026 10:20:44 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=koz6YBslh5yElXpnMEkAgKBM115n+TwRrDaMXW9mZhAPkRft/qYWwx6gTF9Lt+QGHobVgwaN5L0usBoG5DqrsJhoEi0NepQ2SXpneyAOWJKa5p+BsCDEZHFcTpteH03ph3E7k2BJiF5gRArn9f8FfV17OHVFyuSCofzCi+QRBlZJtszPIVP5e1KDkO+buFY0p0ycS+fdpE8V4+gBgCTC7PElgkuwpzYOHOB4WDgABc8RQsfWjWzF/Iqw6eJqYw9+rkACGGbOYCrtGbci19Yl5vJ++66Icd/M7JGMr38j+gdouNbBf7/ofBtzwe5kaYXKNk491985UjShTVEDnXk1/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oXkx4OuIL7Nj9mL0UTRvfUTVTmUATYBGM+v3BpJscII=; b=Ln5gUqjdaOQazOah2fstPc1z7NCqSq0OBaublKrZsN2e1xDCW6NqLdIMRdrJ5hL9sGriZdUmOppWWN1tF4jbCUFLhJS9IixhqW3Ytj8IFjIGT3oVv8sw7569Su7xrJGvo03lX1vNyCRUv/m/N6A9xirSyMtd+gO44K21GlV8ZMJZF7nBlmkpzrpjY9LXcOHr93ahGsRFC1U6qx4WkhZ1hjjGadfThcSabLCRCap60wdHY+BbL7Vp8hbRp+fkdNO+5s4OssUiF7knhYm5qsDXl1a6HnKPyjwJHAPtcVp2H1F5ZYKK/NFPvbDSnA141u/JxKaN4TrVasJRoXJhPP1pdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oXkx4OuIL7Nj9mL0UTRvfUTVTmUATYBGM+v3BpJscII=; b=B3HpVuDR2jw0MqFGgQWRAhSog/tWAXlBXZXzBuD4DMkEki1jh3kXQKBKOVoxCS3Or3Ks6nhrSe+wDaDP2LUpZzz0F0Sf7/sUifUfHIUY9K/RTsxOywF74JfF9ZQxygybQDyJGyrZsRrDGkMn6sShysSFLFlLyaiatLvtdwxXMN4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <4eba243f-01cb-49a6-9f6f-edab49d5901b@amd.com> Date: Mon, 14 Sep 2026 17:20:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/4] xen/arm: validate IRQs before descriptor lookup To: Volodymyr Babchuk , Mykola Kvach CC: "xen-devel@lists.xenproject.org" , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" References: <355ff5a0aab671894a527ccb7b5999db6b168de3.1787050437.git.mykola_kvach@epam.com> <87fr03xcr1.fsf@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <87fr03xcr1.fsf@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00018548:EE_|SA1PR12MB7038:EE_ X-MS-Office365-Filtering-Correlation-Id: d555130e-7224-4c24-9004-08df1273c095 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|23010399003|82310400026|376014|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 3MVWk0A/4VW3bK98e8c/TVK+EQ7+mXJkCrPn4XlzkCBYNfH2J2csOkS3cEN/X5QNoiGXIwNWV/ICEHxiyhuy05HGtDcYWrcfIjVBRgjCMY3LRUlxHprSHo8xorn0c1yA+HqU9WmRhMlKV0TaW+Bm+LtEDP12iLE6a/EbMBzFybZ3F50hYGIm3XW0Yh/UdVh2UjZIrT8NJynA9tiqd8pEZEAQtyBfGO80Alv8W7A92Gl2dmSApLQuWw22zBbVQtWyRqdgPjpA9ALXZIpl1vSIDnrvgK5Ziu7TLzwomdoBJdzxAyi6KK3GypMQbFr5fADa4RbesJCnC7PmK4DMpJyDIjxCoBliTnKA/QTAJwZjE1rcjH1aX3galHGdMGwAm0FTpVA+coD65NL0H0O1csJ0/UuT6RIRcM4jYT7xO1NJd4oFoaYm64X6eoJaRwr34QF0BwQ6paM4P3ckSgRSQF589JhM44pAvtokig17TQsLhU3yC68t0FwvB2GY0YO12hWMljgvdt7SKRlav+GG5TBl7YFVWUSSQdFbGYgoMtGSyuzj/qvMUOgHeQRDESpXec87kuBRP+93djk2SegHd3oeNGMCyylg0ajPhobKK7NVNe1SY/MOEfxaSggZ++DOA4GFr9nAPOvnBtzW9YFiWxOyIhLVLZTW+E0wyN4x9vMW3+V8XaN+X4Konqwkf0rTMPLw9hQx0n/KEXYAyFFyL8/VqA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700016)(23010399003)(82310400026)(376014)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: y33GOMOFIvYZP3wkCFqcP8e6hXmxlutS/GutnfONw14q7brKh9gApyEYEuEMKMizVDYLL4Y1KABt5coYYHCr15eJBv03yHp9NLZKkdz6nKYPFNF/h3Y3+JPXduBdaBT2j+RVG4QkXmnTD6d5sn1BV4r+gAOe3XcMEFRvh6rYErttLigaOTlMjKEnbuz8+lNCJMsgUYA5MEIAV/GBOqpFZDEdAgOi7maAVQpdfxYG0ocfMlNmxfWX6595LIuPJHq5R2cCq/zlxS2DHFbppyPxHxeAtSjC2vWyN0eDVJT3a+vfGg0dmeaXbJXF2QLX3f63uHIQMTkcsz4SgdKGk4+tr42Z6aM2QCjwI+WEFT5jKAlT1+MwVa5ny5XkA+CwNNFSavmEZO6JrGeDuUcOxH/6XX+V7iB7E8ZLsrBHNbSLVNVz+bhNh/MpG7DW6Hn94YVw X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 15:20:47.1038 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d555130e-7224-4c24-9004-08df1273c095 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF00018548.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7038 X-purgate-ID: tlsNG-bad1c0/1789399252-FD86F034-B141FD1D/0/0 X-purgate-type: clean X-purgate-size: 4604 On 25-Aug-26 02:30, Volodymyr Babchuk wrote: > Hi, > > Mykola Kvach writes: > >> GICv3 eSPI support makes nr_irqs span the architectural INTID namespace >> through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[] >> and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs. >> INTIDs 1024 through 4095 have no backing descriptors. >> >> Validation based only on nr_irqs accepts an INTID in this gap. >> __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or >> update unrelated Xen memory. >> >> Reject INTIDs that the GIC reports as unimplemented in setup_irq() before >> looking up a descriptor. irq_set_spi_type() can run before the implemented >> GIC line counts are available, so validate descriptor-backed ranges there >> before looking up a descriptor. >> >> Assert the regular descriptor bound in __irq_to_desc() so direct callers >> cannot silently index the sparse gap in debug builds. >> >> Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range") >> Signed-off-by: Mykola Kvach >> --- >> Changes in v3: >> - Add the requested bound assertion and retain the SPI-only comment. >> >> Changes in v2: >> - Validate descriptor-backed ranges in irq_set_spi_type(). >> - Validate implemented GIC lines in setup_irq(). >> - Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled. >> --- >> xen/arch/arm/irq.c | 26 ++++++++++++++++++++++---- >> 1 file changed, 22 insertions(+), 4 deletions(-) >> >> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c >> index 73e58a5108..bf14180f97 100644 >> --- a/xen/arch/arm/irq.c >> +++ b/xen/arch/arm/irq.c >> @@ -23,6 +23,12 @@ const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ? >> (ESPI_MAX_INTID + 1) : >> NR_IRQS; >> >> +static bool irq_has_desc(unsigned int irq) > > You are using this function only in one place, where you are actually > testing for SPI. So, maybe introduce irq_is_spi() helper instead? And > use it below? It can stay as is but: - move it next to __irq_to_desc(), - use it also as ASSERT(irq_has_desc(irq)) in __irq_to_desc() instead of the assertion you just added. This way the two stay in sync. > >> +{ >> + return irq < NR_IRQS || >> + (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); >> +} >> + >> static unsigned int local_irqs_type[NR_LOCAL_IRQS]; >> static DEFINE_SPINLOCK(local_irqs_type_lock); >> >> @@ -76,7 +82,6 @@ static int __init init_espi_data(void) >> return 0; >> } >> #else >> - > > Please, no unnecessary changes > >> static int __init init_espi_data(void) >> { >> return 0; >> @@ -95,6 +100,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq) >> return espi_to_desc(irq); >> #endif >> >> + ASSERT(irq < NR_IRQS); check_timer_irq_cfg() in time.c calls irq_to_desc() on timer_irq[], and on the GTDT path those are not validated. >> + >> return &irq_desc[irq-NR_LOCAL_IRQS]; >> } >> >> @@ -416,6 +423,9 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new) >> struct irq_desc *desc; >> bool disabled; >> >> + if ( !gic_is_valid_line(irq) ) Please add a printk message to inform the user. >> + return -EINVAL; >> + >> desc = irq_to_desc(irq); >> >> spin_lock_irqsave(&desc->lock, flags); >> @@ -647,13 +657,21 @@ static bool irq_validate_new_type(unsigned int curr, unsigned int new) >> int irq_set_spi_type(unsigned int spi, unsigned int type) >> { >> unsigned long flags; >> - struct irq_desc *desc = irq_to_desc(spi); >> + struct irq_desc *desc; >> int ret = -EBUSY; >> >> - /* This function should not be used for other than SPIs */ >> - if ( spi < NR_LOCAL_IRQS ) >> + /* >> + * This function should not be used for other than SPIs. >> + * >> + * The implemented GIC line counts are not available when early >> + * callers configure IRQ types. Check descriptor storage here; setup_irq() >> + * validates the implemented line before the interrupt is used. >> + */ >> + if ( spi < NR_LOCAL_IRQS || !irq_has_desc(spi) ) > > So here you can just call if ( !irq_is_spi(spi) ) > >> return -EINVAL; >> >> + desc = irq_to_desc(spi); >> + >> spin_lock_irqsave(&desc->lock, flags); >> >> if ( !irq_validate_new_type(desc->arch.type, type) ) > ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 14 15:21:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 15:21:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421101.1647230 (Exim 4.92) (envelope-from ) id 1x68V6-0003ml-AO; Mon, 14 Sep 2026 15:21:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421101.1647230; Mon, 14 Sep 2026 15:21:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68V6-0003me-7b; Mon, 14 Sep 2026 15:21:44 +0000 Received: by outflank-mailman (input) for mailman id 1421101; Mon, 14 Sep 2026 15:21:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68V4-0003mV-Io for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:21:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x68V3-004Cpx-VX for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:21:41 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa81102-bab6-0a2a0a5309dd-0a2a45068a3c-8 for ; Mon, 14 Sep 2026 17:21:41 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa81105-195a-0a2a45060019-4a7de44c9d02-3 for ; Mon, 14 Sep 2026 17:21:41 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a98604f6b4so3021600a12.2 for ; Mon, 14 Sep 2026 08:21:41 -0700 (PDT) Received: from [172.18.123.208] ([185.104.138.149]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c29ad3e033asm166766666b.47.2026.09.14.08.21.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 08:21:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789399301; x=1790004101; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BOTx3sWZgl50ibr0pIUML6XT/6YYqGuo6aTW43iDchk=; b=SNhSkVSSjjoq0/icnlWqzNTX3oyLDTH2VME8xisjdGJB9BdKdDIK/3mxLI27txoRMp jS3q9UKxRO3oxkH/pCwDETQsVCy3oxAMlbtDg/BUTp2AuHvmw7iVlQGsRfWPsE++351S W9sno4hq4hTxN2aRdfRadEbyCRz306dkjYywRJFkl81m3pX7/HRccXnBVgcF0Z/Vj+eL zwfYfXKFdbcygqRXBQPIDjxbcfc+S8V63uBdmWocrR620tPaoVXoimlWO1p4pUkAq8dQ LSw/9HeiEz/YMSvS8HGjLQ92de2He2auz3iokS1T/JpQWx3GpzKIGnE4LiHA69OoFX4e bT/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789399301; x=1790004101; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=BOTx3sWZgl50ibr0pIUML6XT/6YYqGuo6aTW43iDchk=; b=oqQHjCky/KPgACwAhKSfwh8P8OPTVMETzf8iEPQoWF/bf3mOVugZjBUDZJogWFhSuG O/SQI40dTwbE2Zw3Gkks0ABYhGOW+Ci79zpYCom6FCyHDU849CCQzDb8znAa7GTzrZ1m ExiUwY9dWwbk3nXOFLZuRM4cNAQe1gtUTL7qeQjFYQnV/ZbwKlYO19FMdEH/TPdQY5Cv dLxujwVAgfbq7QRr/lCvGjQfDW4TMZBnVfn7+UQJL/y3gmipSW4oMKNqRViuvGB3NTXK KQ6rQJ/nQq3NOliHaZLnBJNxFECeijJ5dtfOoWCe6OpCwkdMDW7ABbttBTzhonLfC8zM xE5g== X-Forwarded-Encrypted: i=1; AKwUvBwvl8ODN+p/xcIrginoa5h1PR2dt2C0HjIKptf/UQPTKWpjityScsAwVvoIoJvCs16GiYI6wQOQkUk=@lists.xenproject.org X-Gm-Message-State: AFuF++l68qAd9eC5EZ7KrH8eI1Rb/DvOjzkyQcgsjH6+5DA7Tr4dDOkX 9DSWx+PNuJrBO3zFNyKgiEeCr4Vi6o3z1bi6utVzXozn8CTARQ2LgTu8vNKqy1uK8Q== X-Gm-Gg: AYBFou1G6/GzaHInA+MJo86Q0V1gs931l6jiCrUTHFV4hVFnMEtIucW9HC1JpfCgdZL JnoQ8+9D1o2cMHG4cdHOLcE/cv23g0ybUYWquC/C0BZUR9IlqbSYt5G68pfJ8eh2KvLUiJkkrgw vFsav1N3GObA6KvTTfF6Qs2alwyZa0KlIpsWhjacMjlueLOfhxCeNtdlnluGpodLHdq5e8+7ZTr DYiDS+kKmNhHFzdzHN25ELBiC3y2wRN4sy5ZsD8Txd2+hN+c88S1H+4+D9eSZ+8zRMZUxgys67t Pcl3tNxtlJCc+rNqS36ClrsRZn6OsPsEN46PaLajCwXT7EQyQ9aV1XUXwgzvWki6aq78aASJiMW 0Fka/R4Ug5/3H43bRHuxl2HiyCs+F6Jfw8Alh/mBwWCPDlakBqaB05I0mdqW0OOlBfrX+81NNNS z7ltTX+PYf1nmKtnZ48dDJ2L9VTYbEyU8g6jP3tgP59POqq+Af50Kci3AZr+vVJmXKPoNnIG49V cwENK2CiDHzvO4zvhtMh8Q= X-Received: by 2002:a17:907:845:b0:c26:19de:9ad1 with SMTP id a640c23a62f3a-c29b871d15amr212063166b.41.1789399301487; Mon, 14 Sep 2026 08:21:41 -0700 (PDT) Message-ID: <8672bc80-38a5-43b5-a5d0-40a33dcb01dd@suse.com> Date: Mon, 14 Sep 2026 17:21:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 34/39] xen/riscv: restore register state in the new IMSIC VS-file To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789399301-FCC0777B-AB378AE7/0/0 X-purgate-type: clean X-purgate-size: 1756 On 27.08.2026 17:21, Oleksii Kurochko wrote: > @@ -630,13 +649,13 @@ static void cf_check imsic_vsfile_local_read_clear(void *data) > old_vsiselect = csr_read(CSR_VSISELECT); > old_hstatus = csr_read(CSR_HSTATUS); > new_hstatus = old_hstatus & ~HSTATUS_VGEIN; > - new_hstatus |= ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT; > + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); Please put into final shape upon introduction. > csr_write(CSR_HSTATUS, new_hstatus); > > /* > - * There is no need to use atomic functions version to store > - * values in MRIF because imsic_vsfile_read_clear() is always called > - * with pointer to temporary MRIF on stack. > + * No atomic accessors are needed to store the values into the MRIF here, > + * as imsic_vsfile_read_clear() is always called with a pointer to a > + * temporary MRIF on the stack. > */ Same for this comment perhaps. > @@ -1077,5 +1140,12 @@ void imsic_migrate_vcpu(struct vcpu *v) > /* Free-up old IMSIC VS-file */ > vgein_release(v, old_vsfile_id, old_vsfile_cpu); > > - BUG_ON("unimplemented"); > + /* Restore register state in the new IMSIC VS-file */ > + vsfile_data.mrif = &tmrif; Ah, here &tmrif is used a 2nd time. > + imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_update, &vsfile_data); > + > + /* Set VCPU HSTATUS.VGEIN to new IMSIC VS-file */ > + vcpu_guest_cpu_user_regs(v)->hstatus &= ~HSTATUS_VGEIN; > + vcpu_guest_cpu_user_regs(v)->hstatus |= > + MASK_INSR(new_vsfile_hgei, HSTATUS_VGEIN); Nit: Indentation. Other comments on earlier patches apply here (and possibly elsewhere) as well. Just ftaod. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 14 15:31:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 15:31:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421118.1647248 (Exim 4.92) (envelope-from ) id 1x68eW-00066U-Bo; Mon, 14 Sep 2026 15:31:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421118.1647248; Mon, 14 Sep 2026 15:31:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68eW-00066N-8A; Mon, 14 Sep 2026 15:31:28 +0000 Received: by outflank-mailman (input) for mailman id 1421118; Mon, 14 Sep 2026 15:31:27 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68eU-0005t7-VZ for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:31:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x68eU-004ExS-B7 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:31:26 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa8134c-bab6-0a2a0a5309dd-0a2a450ad290-8 for ; Mon, 14 Sep 2026 17:31:26 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa8134b-f2d2-0a2a450a0019-aceafc1fcd92-3 for ; Mon, 14 Sep 2026 17:31:25 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 953F9408EA; Mon, 14 Sep 2026 15:31:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73F361F0089A; Mon, 14 Sep 2026 15:31:23 +0000 (UTC) Received: from [10.30.226.235] (localhost [IPv6:::1]) by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id D092A3924A79; Mon, 14 Sep 2026 15:30:19 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:Date:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789399883; bh=nR/vh4GvI0WOU5I3SDjzgrYVoTA8r4/N125W3zwVcoM=; h=Subject:From:Date:References:In-Reply-To:To:Cc; b=RbCEKtn4AO+w1y1Nm4+9OPjd3F5HeNMHAg3uez+4FdxFCGDSSpv7EiKf+nOYlAqRD WpbEgLLqAW4/l8pXzRAprjeTjPg5iYhCGnBEarYYppZgnkrHtBmnFS9mupbuYxw5uF 9IaiI70goJcN/QHzRT88UUSpAI4Re7c2DETfrByKeR3s4TjTlq6nG8lVpXAeCBJkvv 0JK4xXezKzgYlQ+Oc3bwKs3QN943NILxYGwTYwEDkh+jk8qAJukkZVAb2U57/OORtM maeohl2NdOmJIEX01jxCO7utzNVfC1W0jyXsjrJ+AH6xFXa9Zfjke3MaE5gkTOu/bL U9AI6BB36tibg== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [f2fs-dev] [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead From: patchwork-bot+f2fs@kernel.org Message-Id: <178939981839.647967.9641554131485178993.git-patchwork-notify@kernel.org> Date: Mon, 14 Sep 2026 15:30:18 +0000 References: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> In-Reply-To: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> To: Zi Yan Cc: david@kernel.org, willy@infradead.org, akpm@linux-foundation.org, muchun.song@linux.dev, ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, baolin.wang@linux.alibaba.com, nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, hannes@cmpxchg.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, kasong@tencent.com, mark.rutland@arm.com, irogers@google.com, jack@suse.cz, linux-doc@vger.kernel.org, amarkuze@redhat.com, peterz@infradead.org, kexec@lists.infradead.org, dave.hansen@linux.intel.com, ruirui.yang@linux.dev, adrian.hunter@intel.com, linux-mm@kvack.org, hongbohbli@tencent.com, hpa@zytor.com, guochunhai@vivo.com, skhan@linuxfoundation.org, tz2294@columbia.edu, baoquan.he@linux.dev, matthew.brost@intel.com, anna@kernel.org, sstabellini@kernel.org, zbestahu@gmail.com, rakie.kim@sk.com, minchan@kernel.org, richard@nod.at, x86@kernel.org, ceph-devel@vger.kernel.org, ebiggers@kernel.org, alexander.shishkin@linux.intel.com, mingo@redhat.com, slava@dubeyko.com, weixugc@google.com, yukuai@fygo.io, xen-devel@lists.xenproject.org, xiang@kernel.org, magiclinan@didiglobal.com, mhiramat@kernel.org, joshua.hahnjy@gmail.com, xiao@kernel.org, byungchul@sk.com, james.clark@linaro.org, acme@kernel.org, linux-raid@vger.kernel.org, linux-fscrypt@vger.kernel.org, bp@alien8.de, rostedt@goodmis.org, linux-mtd@lists.infradead.org, axelrasmussen@google.com, jefflexu@linux.alibaba.com, namhyung@kernel.org, jaegeuk@kernel.org, yuanchu@google.com, idryomov@gmail.com, osalvador@suse.de, jgross@suse.com, pratyush@kernel.org, linux-nfs@vger.kernel.org, tytso@mit.edu, oleksandr_tyshchenko@epam.com, song@kernel.org, corbet@lwn.net, pasha.tatashin@soleen.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-perf-users@vger.kernel.org, senozhatsky@chromium.org, tglx@kernel.org, jolsa@kernel.org, linux-fsdevel@vger.kernel.org, mathieu.desnoyers@efficios.com, linux-trace-kernel@vger.kernel.org, linux-erofs@lists.ozlabs.org, trondmy@kernel.org X-purgate-ID: tlsNG-4011c0/1789399885-4B8D5CFC-CEC5E8D3/0/0 X-purgate-type: clean X-purgate-size: 789 Hello: This series was applied to jaegeuk/f2fs.git (dev) by Jaegeuk Kim : On Sun, 13 Sep 2026 22:23:58 -0400 you wrote: > Hi all, > > This patchset removes PG_private to make space for upcoming PG_folio for > identifying pages from a folio (more details in Note below). Instead of > checking PG_private, all code is changed to check page/folio->private != > NULL instead. > > [...] Here is the summary with links: - [f2fs-dev,v4,06/16] f2fs: stop using PG_private https://git.kernel.org/jaegeuk/f2fs/c/60105162524e - [f2fs-dev,v4,07/16] f2fs: convert the ->private flag helpers to folio-only (no matching commit) You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html From xen-devel-bounces@lists.xenproject.org Mon Sep 14 15:31:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 15:31:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421117.1647240 (Exim 4.92) (envelope-from ) id 1x68eV-0005tN-7H; Mon, 14 Sep 2026 15:31:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421117.1647240; Mon, 14 Sep 2026 15:31:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68eV-0005tC-23; Mon, 14 Sep 2026 15:31:27 +0000 Received: by outflank-mailman (input) for mailman id 1421117; Mon, 14 Sep 2026 15:31:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x68eT-0005t1-6V for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:31:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x68eS-009Jyg-JM for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:31:24 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa8134c-8faa-0a2a0a5109dd-0a2a4505a88e-4 for ; Mon, 14 Sep 2026 17:31:24 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa8134a-4cb1-0a2a45050019-aceafc1f874e-3 for ; Mon, 14 Sep 2026 17:31:24 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 2734740124; Mon, 14 Sep 2026 15:31:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03D7F1F00893; Mon, 14 Sep 2026 15:31:22 +0000 (UTC) Received: from [10.30.226.235] (localhost [IPv6:::1]) by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id 56B213924A79; Mon, 14 Sep 2026 15:30:18 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Subject:From:Date:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789399882; bh=6YNBDNqtv3G7fIIrCWxRo+R7rFxECIiWXZYEw0TsCm8=; h=Subject:From:Date:References:In-Reply-To:To:Cc; b=oafm7V4RKsPy/Q1nCVBWDqYf7CzIKQWwzaAUfYXO4K5blgVLNKT30EOhNjyiJ68b4 EmE0pg7kCS+rsBO2hQhqAcC1jDNgaAjoHfS35HWN3j5jboLSqfna8lVYkkpRTOVBLm z7XrVJIhN7zqa0ZqIGC7moq0IJyRMgoMb82ImK4Ze2REEcVBWDrF/nBND+suW7cTj+ wRFmHT2zlonTyo+1brM1i34j0QTrbmA5FknqN7kXJ9bimmAF15wqhMttnovE1K17hY mCHO/L8QQoVL9DoTMRTdTxGNm4LGmdWMH05qUrovm9ES8pb0mcHRy3YO183W8YwGVi tCv3P8ki+lNgA== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [f2fs-dev] [PATCH v3 00/14] Remove PG_private by using page/folio->private checks instead From: patchwork-bot+f2fs@kernel.org Message-Id: <178939981687.647967.15609695091265022344.git-patchwork-notify@kernel.org> Date: Mon, 14 Sep 2026 15:30:16 +0000 References: <20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com> In-Reply-To: <20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com> To: Zi Yan Cc: david@kernel.org, willy@infradead.org, akpm@linux-foundation.org, muchun.song@linux.dev, ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, baolin.wang@linux.alibaba.com, nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, hannes@cmpxchg.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, kasong@tencent.com, mark.rutland@arm.com, irogers@google.com, jack@suse.cz, linux-doc@vger.kernel.org, amarkuze@redhat.com, peterz@infradead.org, kexec@lists.infradead.org, dave.hansen@linux.intel.com, ruirui.yang@linux.dev, adrian.hunter@intel.com, linux-mm@kvack.org, hongbohbli@tencent.com, hpa@zytor.com, guochunhai@vivo.com, skhan@linuxfoundation.org, ceph-devel@vger.kernel.org, baoquan.he@linux.dev, matthew.brost@intel.com, anna@kernel.org, sstabellini@kernel.org, zbestahu@gmail.com, rakie.kim@sk.com, minchan@kernel.org, richard@nod.at, x86@kernel.org, ebiggers@kernel.org, alexander.shishkin@linux.intel.com, mingo@redhat.com, slava@dubeyko.com, weixugc@google.com, yukuai@fygo.io, xen-devel@lists.xenproject.org, xiang@kernel.org, magiclinan@didiglobal.com, mhiramat@kernel.org, joshua.hahnjy@gmail.com, xiao@kernel.org, byungchul@sk.com, james.clark@linaro.org, acme@kernel.org, linux-raid@vger.kernel.org, linux-fscrypt@vger.kernel.org, bp@alien8.de, rostedt@goodmis.org, linux-mtd@lists.infradead.org, axelrasmussen@google.com, jefflexu@linux.alibaba.com, namhyung@kernel.org, jaegeuk@kernel.org, yuanchu@google.com, idryomov@gmail.com, osalvador@suse.de, jgross@suse.com, pratyush@kernel.org, linux-nfs@vger.kernel.org, tytso@mit.edu, oleksandr_tyshchenko@epam.com, song@kernel.org, corbet@lwn.net, pasha.tatashin@soleen.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-perf-users@vger.kernel.org, senozhatsky@chromium.org, tglx@kernel.org, jolsa@kernel.org, linux-fsdevel@vger.kernel.org, mathieu.desnoyers@efficios.com, linux-trace-kernel@vger.kernel.org, linux-erofs@lists.ozlabs.org, trondmy@kernel.org X-purgate-ID: tlsNG-c201ff/1789399884-F58AE2A1-F8F9ECC3/0/0 X-purgate-type: clean X-purgate-size: 707 Hello: This patch was applied to jaegeuk/f2fs.git (dev) by Jaegeuk Kim : On Mon, 07 Sep 2026 22:56:07 -0400 you wrote: > Hi all, > > This patchset removes PG_private to make space for upcoming PG_folio > (reserved as __PG_folio) for identifying pages from a folio (more details > in Note below). Instead of checking PG_private, all code is changed to > check page/folio->private != NULL instead. > > [...] Here is the summary with links: - [f2fs-dev,v3,06/14] f2fs: stop using PG_private https://git.kernel.org/jaegeuk/f2fs/c/60105162524e You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html From xen-devel-bounces@lists.xenproject.org Mon Sep 14 15:55:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 15:55:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421153.1647258 (Exim 4.92) (envelope-from ) id 1x6924-0002FP-9H; Mon, 14 Sep 2026 15:55:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421153.1647258; Mon, 14 Sep 2026 15:55:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6924-0002FI-5I; Mon, 14 Sep 2026 15:55:48 +0000 Received: by outflank-mailman (input) for mailman id 1421153; Mon, 14 Sep 2026 15:55:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6923-0002FC-4N for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:55:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6922-001pCn-H3 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:55:46 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa818f7-2eae-0a2a0a5409dd-0a2a4501c016-22 for ; Mon, 14 Sep 2026 17:55:46 +0200 Received: from [52.101.48.42] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa818f9-5984-0a2a45010019-3465302aff09-3 for ; Mon, 14 Sep 2026 17:55:40 +0200 Received: from BN9PR03CA0227.namprd03.prod.outlook.com (2603:10b6:408:f8::22) by LV8PR12MB9110.namprd12.prod.outlook.com (2603:10b6:408:18b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Mon, 14 Sep 2026 15:55:33 +0000 Received: from BN3PEPF0000B076.namprd04.prod.outlook.com (2603:10b6:408:f8:cafe::82) by BN9PR03CA0227.outlook.office365.com (2603:10b6:408:f8::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.12 via Frontend Transport; Mon, 14 Sep 2026 15:55:33 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF0000B076.mail.protection.outlook.com (10.167.243.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Mon, 14 Sep 2026 15:55:33 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 14 Sep 2026 10:55:31 -0500 Received: from [172.20.10.246] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Mon, 14 Sep 2026 10:55:30 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kWPO3yW3SDDeNCwG33G8h1ivc2XFSbdYez1Lfz92MRmdTiQ/kOCZlI9ZlJnB8ktNWVmGtdW74nJOCzlFWTsiBiE8s3WOApnJXu/Grz4p+RHZpUeIGpdb3Z4cgLzAVNnnZv5FB2pydg0xVpyiy4ALfxCypXmbhFTcYslw4hbDaCaj3rFS1zh8wjBcQNQrkMGn8b5jWJam4ST9TcJddDBLmBC+uZk51mIEUhMF4f4w386YoYITHKNZ6VCjjbYCf7u5bfBPkdkUthcR9F0YPMWrHiAFE/FQZ051O2NOUrIWineZKoQ5fT5Ce0pXsGuUoAUXLJ3HqBusOR948tYvTQXVLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vIcYhh7rNGzaEgLlSvJR9moaf3b6CekunNJoxLa5bQ0=; b=J9SAzCsIBslyDDe59NUvXhl3PWl2828C+2sLdUo0EplcLdlYUz395h+OhdQU9A3NJjspv4uWHdniZkn6RTBycaWFMX2e/SMCgyggjL1myFfOhodgV8NIbDp2gX6sWmrGbDujUdhLBphG9uJk647TXcuL8g+cTgENzA0aG9pLmfBBXh/V4XE1McbtjbWhVkg2i/0BNSZNAyMU1DAO2L3QqEKNvPng0XR+SIZ901Fq58QqRLQmji8U4gxP83rOeqSGutqxaicY1bd5IlODE2Iqtfm1ciUzT0j+NKLcUcjAAnHtx108E3OP6fMSDpGH973rLYdazPJTFGVOPmvu7Lzrvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vIcYhh7rNGzaEgLlSvJR9moaf3b6CekunNJoxLa5bQ0=; b=5EGgaohBFFAyqnGL9lmgaIZD94UdbYpIrHrsgbEmCFdQro23k8fQa5S9nUceI4L9tJ76wiqNdZb96/UPGETEK9GQIEl7LwPuJhuCypYGSe6mgg1PhqqrVDGBHu1oDL2l3a0xHliJzKIXOslBXnc2BBNg3PaEj5O2NhXjYCCjFQA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <2e0f1fcf-dfcd-4a26-8124-4b7da0ca4f83@amd.com> Date: Mon, 14 Sep 2026 17:55:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/4] xen/arm: vgic: free eSPIs using the bitmap index To: Volodymyr Babchuk , Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis References: <874igjxcjs.fsf@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <874igjxcjs.fsf@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B076:EE_|LV8PR12MB9110:EE_ X-MS-Office365-Filtering-Correlation-Id: b8cbb7b7-0197-4459-7311-08df12789c03 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|82310400026|36860700016|6133799003|22082099003|18002099003|4143699003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: rhqkI7XFsZzEk7rW4D6+hULK7oxJHxTIpmhEzgV+5NDOXpOLwJaUEF0weYNHngJg+pxGeeen2trJ3focvFRk5vZh9UJ7qYb2SI/eS3ejyQlZo3xGH0HrLgE2OmV0LKbhWQI2B3Otsxg/LIPYoEbP2EopppB/TdbcAEWB0Jrg4rRrkOYPWK2t3kYRGDIuBoA8g3eGWlsrA9dB818HwruUMLPaWhaDhaWLkvcP5F+uSdxsL8nVpo52X7ROI9z9yvBwFd1G95/GLgN40N9mKyw1VZPUJSa6U8Ils9z7/eMwiyXlkyhfQev8KH8hR1IP8jhpT6suCH1Za3tf1+U97U8V5Bi+pmbt+1sitsH3kTFNoiAOC30+33Qpn3t3pt708FBm/uGtpX4dusgchXiE0ZLrPTOjsYweba2FuSBQ26EVLhG4H3bYA5nJtDQYCHI8c0ITg9IdLseforL8ihYszrhMj2a8RWxLE5AyVxF6/Vm8wxwg9DABvD7ZlNImKBV8v/WfEHYrqsbjWeVG90Yyn7NWyoECTDalyVop4jNoxM2uTx2BmUdIln5aSS9XLLvbgrHT7GHPc8TzFrUfrYNHZoa0qw2YLz6oNFFxNALTTyEsWf3WELWdXoz6GvEgro2kKAN2RxzIwxQ/j9YIE1JxDjCi0cxvV6fcpSCa9Wfk3CSHTEjdVv3+eoNuswdEaUJn3OBh2eTRsRl4G6BM+A6NQ8RLiw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(82310400026)(36860700016)(6133799003)(22082099003)(18002099003)(4143699003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Vr4+oGQdpVTe6YlqMg+cwxjVMtjDx3K4vMPe8aYT8hLKnxxW44glDGZVhV10X5+HXmXguiKYxsfGZRDvSj1jM0ALO3JQE/LdZ8//plF+KbQON/aQfcR/W03Gp12Iw27DAnunnqFZyaoz3NQ2p3XYT3jhme5TTEzlzHb5S1hYGH30VEgvYMkvGtGhiOknQ8tvHRQrUlRTI5EtZ5VX9Lkrn6ziN1JN2yVaZQBISLkXfGhHlPsKrVXG4xUt6s/ptN5UtuK9J9mEq1o9i9AeOAXQ0frgfOr+A50XobpQNtAMrj/tN/G0/3ZSBIS3l8za/5OxIP0qoh4ipG5ejSyXhhYxkDJ/bmpXTOGUcPjf3TsVEXgpF34v0CyP+1x4Mjtw3wCd31oneTKp/CSpQAyXzgX5Jw1C2UPCN1y+V68KHD4uWYN8aQvwTRs/a7LDQK1/up/g X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 15:55:33.2302 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b8cbb7b7-0197-4459-7311-08df12789c03 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B076.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9110 X-purgate-ID: tlsNG-d62444/1789401346-BEA66757-3111DB56/0/0 X-purgate-type: clean X-purgate-size: 3390 On 25-Aug-26 02:35, Volodymyr Babchuk wrote: > Hi, > > > I have only one small question to this patch. Please see below. > > Mykola Kvach writes: > >> The allocated_irqs bitmap in the existing vGIC implementation stores eSPI >> allocation bits immediately after the regular vIRQ bits. >> vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index, >> but vgic_free_virq() used the raw INTID. >> >> Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit. >> This writes beyond allocated_irqs and leaves the intended eSPI bit set. >> Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind, >> and during vPL011 teardown. >> >> Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving >> and freeing vIRQs. Validate a vIRQ before clearing its allocation bit. >> >> Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended SPIs") >> Signed-off-by: Mykola Kvach >> --- >> Changes in v3: >> - Adapt virq_to_idx() to the configuration-neutral is_espi() helper. >> >> Changes in v2: >> - Call is_espi() without a configuration guard. >> --- >> xen/arch/arm/vgic.c | 27 ++++++++++++++++----------- >> 1 file changed, 16 insertions(+), 11 deletions(-) >> >> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c >> index e14123a30a..e541348a5c 100644 >> --- a/xen/arch/arm/vgic.c >> +++ b/xen/arch/arm/vgic.c >> @@ -33,6 +33,16 @@ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx) >> return idx; >> } >> >> +static inline unsigned int virq_to_idx(struct domain *d, unsigned int virq) Please add a comment at the top of the function about the layout these two helpers encode to prevent such problems in the future. >> +{ >> + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(virq)); >> + >> + if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(virq) ) >> + return espi_intid_to_idx(virq) + vgic_num_irqs(d); >> + >> + return virq; >> +} >> + >> bool vgic_is_valid_line(struct domain *d, unsigned int virq) >> { >> #ifdef CONFIG_GICV3_ESPI >> @@ -849,19 +859,11 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr) >> >> bool vgic_reserve_virq(struct domain *d, unsigned int virq) >> { >> - unsigned int idx = virq; >> - >> if ( !vgic_is_valid_line(d, virq) ) >> return false; >> >> - if ( is_espi(virq) ) >> - { >> - unsigned int num_regular_irqs = vgic_num_irqs(d); >> - >> - idx = espi_intid_to_idx(virq) + num_regular_irqs; >> - } >> - >> - return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs); >> + return !test_and_set_bit(virq_to_idx(d, virq), >> + d->arch.vgic.allocated_irqs); >> } >> >> int vgic_allocate_virq(struct domain *d, bool spi) >> @@ -898,7 +900,10 @@ int vgic_allocate_virq(struct domain *d, bool spi) >> >> void vgic_free_virq(struct domain *d, unsigned int virq) >> { >> - clear_bit(virq, d->arch.vgic.allocated_irqs); >> + if ( !vgic_is_valid_line(d, virq) ) > > Is this really can happen during normal runtime? Yes, it can. A dom0less domU with direct-map, vpl011 and an explicit nr_spis. With the comment added: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 14 15:57:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 15:57:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421162.1647267 (Exim 4.92) (envelope-from ) id 1x6941-0002vi-OB; Mon, 14 Sep 2026 15:57:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421162.1647267; Mon, 14 Sep 2026 15:57:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6941-0002vb-KG; Mon, 14 Sep 2026 15:57:49 +0000 Received: by outflank-mailman (input) for mailman id 1421162; Mon, 14 Sep 2026 15:57:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x6940-0002uP-El for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:57:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x693z-001pfl-Ki for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:57:47 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa81960-8faa-0a2a0a5109dd-0a2a450cc4ac-42 for ; Mon, 14 Sep 2026 17:57:47 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa8197b-f479-0a2a450c0019-4a7de18ce8ba-3 for ; Mon, 14 Sep 2026 17:57:47 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49e620fa473so11899285e9.1 for ; Mon, 14 Sep 2026 08:57:47 -0700 (PDT) Received: from ?IPV6:2a02:778:142:8f01:2700:bad4:284c:5aa5? ([2a02:778:142:8f01:2700:bad4:284c:5aa5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e7d67de8asm2141425e9.12.2026.09.14.08.57.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 08:57:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789401467; x=1790006267; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=KBDqS46zgMxbjss1lWF0YOIwg7GNOYawwN+MAfvbfJM=; b=XWbjI7BWvEqK/MkgFOpx77p1W2IWkt+UkX6VLwbagiCsCXKLuKmcbsphnPuAeePtDq TPXV3CIU7QqVeEL+oPPU5rh6V0KS58gxmvyoSXMycuja5LfsD3cqDt0SLqTEhoi9CCpC vGJMGmb+wvlrxKhwE8rXBW/xdQzn4kyQBX/pghhij3lOZTF7m0hwewSnTONvzJ4nvQdQ i+TxemskfS5F53NhR+4FYtt5IrJxw0yx54AT6PzN8KiPHiyxOv0NSrWq59qeyvgNaVmz 4+5K0eMvLzjGGa4PUDpCKediTkbk9lCxjzCxvw7NTTKiEBLMokUMkaogUOEN3kTlEyqB ZpwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789401467; x=1790006267; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=KBDqS46zgMxbjss1lWF0YOIwg7GNOYawwN+MAfvbfJM=; b=I7giCTqlVjQigZAu6TTphFc86rZaVIOKmfCRGglWkKpiPDcNAzDbnzM6XUbgd1CvEJ DirRVTB6rPp11C8SNcPRhEtfQEZkNxY2BIv52MXBeAZN2R3xVXJ+yGR1+ioWUivXoGKZ osK86RuXWbIB/AoHj+JgSZbjoC9yEPsPX2fgrJrOrn98FJ1dDfF4KiOK7anOJCipFHKV qswH3lo7ZpDPHjBtyGLooAh7iVRrRocRkovrTX91JvmQpPHJ2/VVyrwCJy9BEpPIWlW3 ZDWchCqtHLJrNSNocgYe/5ikMzCBLX51Pmg66SWJ94PCF/nRvM7TLCkoCkvGTyg1hSJ3 X6uw== X-Forwarded-Encrypted: i=1; AKwUvBwVijy188f7xd0XB3m94iX2EJ8HjGRcLxNNy3Hp2zpHXKqG9BoqGqbB8KkWTLUbyQzgQ/BzspVjB5c=@lists.xenproject.org X-Gm-Message-State: AFuF++l20jQgpM7bPb+3UZN55KQhjpDURhCSYyln90uwuNCVMEsZgCf5 MKTRgWmIHKIptGOf34bk0tOz8dWgTehBHNgobSpnSsbYY5+GuQ4LQbmJ X-Gm-Gg: AYBFou0KeqjLDb97ReNWmIQtsih/KpRjZj6InH7pnwEqJO6FArm1Ob7c9NcO8h2cmyv /SWWJmEXgYlOwdosddqbgqKm4xym0the1nbbyPyCOTe2oYIFh4OTkb5CU3WCKdgjD70CjdrxQFB zhQi/7KbRZdCWkZN8N3j3OhIplWRss7AYNfaXt7WaYuZZcyMk9vF1RFPI4DZ4hmltjUPYcw5zKz C5HUpQTN+qyhT+kXX7XAHErIk8lwE9TIQyt31+PWrVzZ73RC+5OSUjbNWrXnwebBpq33wAoghlv tSxfXpL01wVxPJaZYIjcbjDT/3arCe7fCEs1j0ONbAxo6RYo3KlYz/9QEDMpvEXwJ5Ip0jp/8QO QxsC0WJoDPNXlW/sZQ+hqiVGvNARJgJsk3XW0wXV8uMhF8+O+aVWvkxcgj+b4Qo2On7z/4bBIgk 3MNjAET8JCVVIYHFRyg6HwjYDy02iPven8jRlkR3WuxCNspCt7sESoxrXyEdMbJqyET8bvWwLNL cM87kVA/Oj9MUKRymxiuTFk7GJ1BFmoLhyj7zAeBvydGv/iJm82qvhCx8dujIEuuQ== X-Received: by 2002:a05:600c:8012:b0:49c:fc6c:be08 with SMTP id 5b1f17b1804b1-49e7a67c769mr41079025e9.31.1789401466652; Mon, 14 Sep 2026 08:57:46 -0700 (PDT) Message-ID: <62a6884d-f2dc-46d9-ba5d-0dc4949ba25f@gmail.com> Date: Mon, 14 Sep 2026 17:57:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 24/39] xen/riscv: add helpers for decoding a trapped load or store To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com> <895a427d-1adb-43cb-a2bb-e0e9d50791db@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <895a427d-1adb-43cb-a2bb-e0e9d50791db@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1789401467-02ADCA5B-B46A7013/10/73395122804 X-purgate-type: spam X-purgate-size: 21724 On 9/14/26 1:03 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> emulate_load() and emulate_store() will both need to obtain the >> instruction which caused a guest MMIO trap, decode it, and locate the >> register operand it names. Add what the two share, ahead of either of >> them being implemented: struct decoded_insn, insn_fetch_faulted(), >> decode_ldst_insn(), guest_xlen(), guest_gpr() and advance_pc(). >> >> The mask/match chain is adapted from Linux's KVM RISC-V implementation. >> >> Nothing calls any of this yet, so tag the functions __maybe_unused to >> keep the build going; the tags go away once emulate_load() and >> emulate_store() gain their bodies later. > > That'll be a lot of churn to drop those __maybe_unused again. As this > is merely transient, did you consider putting > > (void)is_load_guest_page_fault; > > etc in e.g. emulate_load()? I think it could be really an option. I will rework in that way. > >> @@ -13,9 +14,29 @@ >> #include >> #include >> #include >> +#include >> +#include >> #include >> #include >> >> +/* >> + * Determine the trapped load or store instruction which caused a guest MMIO >> + * trap. >> + */ >> +struct decoded_insn { >> + /* The instruction itself, and its length in bytes. */ >> + unsigned long insn; >> + unsigned int insn_len; >> + /* Width of the memory access, in bytes. */ >> + unsigned int len; >> + /* Number of the register operand: rd for a load, rs2 for a store. */ >> + unsigned int reg; >> + /* The access is a store rather than a load. */ >> + bool is_write; >> + /* The load zero-extends its result rather than sign-extending it. */ >> + bool is_unsigned; >> +}; > > I wonder how efficient this is. With use of bitfield the size of this struct > can likely be more than halved. With suitable choice of widths this may not > even cause significantly worse generated code. > We could compress the structure into 8 bytes: struct decoded_insn { /* * The instruction itself: no ratified extension defines one wider than * 32 bits, and insn_fetch_faulted() rejects anything longer. */ uint32_t insn; /* Length of the instruction in bytes: 2 or 4. */ unsigned int insn_len:3; /* Width of the memory access, in bytes: 1, 2, 4 or 8. */ unsigned int len:4; /* Number of the register operand: rd for a load, rs2 for a store. */ unsigned int reg:5; /* The access is a store rather than a load. */ bool is_write:1; /* The load zero-extends its result rather than sign-extending it. */ bool is_unsigned:1; }; > One thing in any event: Why would the insn field need to be wider than 32 > bits? Initial idea was that htinst register is HSXLEN so here it will be nice to emphasize this. But considering that read_guest() can read maximum 32-bit instructions and no ratified extension defines one wider than 32 bits, and insn_fetch_faulted() rejects anything longer then we could really use here uint32_t for insn + the comment will be useful: struct decoded_insn { /* * The trapped instruction: as read from guest memory, or the 32-bit * equivalent the hardware transformed it into (see insn_fetch_faulted()). * None of the extensions exposed to guests has instructions wider than * 32 bits, and insn_fetch_faulted() rejects anything longer. */ uint32_t insn; > >> @@ -39,6 +60,71 @@ struct guest_fault { >> paddr_t gpa; >> }; >> >> +static bool is_load_guest_page_fault(unsigned long scause) >> +{ >> + return scause == CAUSE_LOAD_GUEST_PAGE_FAULT; >> +} > > With no "store" counterpart this may end up being a little fragile (at the > use site(s)). I will drop then function and just open-code where it is used. > >> +/* >> + * The effective XLEN of the guest at the point of the trap: hstatus.VSXL for a >> + * trap taken from VS-mode, vsstatus.UXL for one taken from VU-mode. >> + * >> + * VSXL is consulted whichever mode the trap came from, as it also gives the >> + * width of vsstatus itself: where VSXL says 32, that register has no UXL field >> + * to consult and VU-mode is 32-bit as well, there being nothing to configure. >> + * >> + * It is needed to decode a trapped instruction: the encodings which exist only >> + * for XLEN=64 must not be recognized for a 32-bit guest. Besides those simply >> + * being reserved there, the compressed ones are ambiguous: C.LD and C.FLW >> + * share the encoding 0x6000 (mask 0xe003), and likewise C.SD/C.FSW, >> + * C.LDSP/C.FLWSP and C.SDSP/C.FSWSP. >> + * >> + * IS_ENABLED() can't be used here as HSTATUS_VSXL is defined for >> + * __riscv_xlen == 64 only, the field not existing on RV32 in the first place. >> + */ >> +static __maybe_unused unsigned int guest_xlen(const struct cpu_user_regs *regs) >> +{ >> +#ifdef CONFIG_RISCV_32 >> + return 32; >> +#else >> + unsigned long xl = MASK_EXTR(regs->hstatus, HSTATUS_VSXL); >> + >> + if ( (xl == XLEN_FIELD_64) && !(regs->sstatus & SSTATUS_SPP) ) > > How about xl > XLEN_FIELD_32 here, to be RV128-compatible? good point. I'll apply. > >> @@ -87,6 +173,250 @@ static void resolve_faulting_gpa(struct guest_fault *gf) >> (htinst_is_pseudo(gf->htinst) ? 0 : (gf->stval & 3)); >> } >> >> +/* >> + * Where the value of a decoded instruction's register operand is held. >> + * >> + * Relies on x0..x31 being laid out at the start of struct cpu_user_regs in >> + * architectural register-number order; see the comment there. >> + */ >> +static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs, >> + unsigned int reg) >> +{ >> + ASSERT(reg < 32); >> + >> + return REG_PTR(reg, 0, regs); >> +} > > For future callers of this: For 32-bit environments hardware guarantees > upper halves of registers to be zero? I think that no as according to the spec: Whenever XLEN in any mode is set to a value less than the widest supported XLEN, all operations must ignore source operand register bits above the configured XLEN, and must sign-extend results to fill the entire widest supported XLEN in the destination register. Similarly, pc bits above XLEN are ignored, and when the pc is written, it is sign-extended to fill the widest supported XLEN. I think we want to add the following to the comment above guest_gpr(): * The register is held at its full width, whatever the guest's XLEN is (see * guest_xlen()). Where XLEN is narrower, the bits above it are not guaranteed * to be zero, nor even a sign extension: hardware only ignores them in source * operands, so they may have been left there by more privileged code running * at a wider XLEN. Hence callers must not rely on those bits when reading a * value, and must sign-extend what they write from bit XLEN-1, as hardware * does for the result of an operation. > >> +/* >> + * Obtain the instruction which caused a guest MMIO trap, filling in >> + * @di->insn and @di->insn_len. It either comes transformed in htinst, or has >> + * to be fetched from guest memory. >> + * >> + * Returns true if the fetch faulted in turn; the resulting trap has then >> + * already been redirected to the guest and there is nothing further for the >> + * caller to do. Where it returns false, @di has been filled in and emulation >> + * is to continue. >> + */ >> +static bool __maybe_unused insn_fetch_faulted(const struct guest_fault *gf, >> + struct decoded_insn *di) >> +{ >> + unsigned long htinst = gf->htinst; >> + >> + /* >> + * A pseudoinstruction says nothing about the instruction the guest was >> + * executing, and comes with a guest physical address which isn't the one >> + * that instruction accessed. handle_guest_page_fault() deals with such a >> + * fault on its own, so no emulation can ever start for one. >> + */ >> + ASSERT(!htinst_is_pseudo(htinst)); >> + >> + if ( htinst & BIT(0, UL) ) >> + { >> + /* >> + * Bit[0] == 1 implies trapped instruction value is >> + * transformed instruction or custom instruction. >> + * >> + * The transformation always yields the 32-bit format, with bits[1:0] >> + * holding a marker instead of the original opcode bits: bit[0] set to >> + * flag the transformation, bit[1] clear if the trapped instruction >> + * was a compressed one. Restoring the opcode bits makes the value the >> + * valid 32-bit encoding decode_ldst_insn() matches against. Its >> + * INSN_MASK_C_* cases exist for the branch below, where a compressed >> + * instruction is read from guest memory as is: a trapped one arrives >> + * here already expanded to its 32-bit equivalent, and the opcode bits >> + * just restored keep it from matching those cases anyway. >> + * >> + * The length then cannot come from the value anymore, only from >> + * bit[1]. And only a 16- or a 32-bit instruction is ever reported >> + * this way: the standard load and store instructions the hardware >> + * transforms are all of one of these two lengths, anything else comes >> + * as the zero special value handled below. >> + */ >> + di->insn = htinst | INSN_16BIT_MASK; >> + di->insn_len = (htinst & BIT(1, UL)) ? 4 : 2; > > Hmm, so ->insn_len doesn't describe ->insn, as suggested by the comment in > the struct. That wants clarifying there. Right, insn_len is the length of the trapped instruction in guest memory, which is what advance_pc() needs, whereas insn may hold its 32-bit transformed equivalent. I'll clarify both comments in the struct.: struct decoded_insn { /* * The trapped instruction: as read from guest memory, or the 32-bit * equivalent the hardware transformed it into (see insn_fetch_faulted()). * None of the extensions exposed to guests has instructions wider than * 32 bits, and insn_fetch_faulted() rejects anything longer. */ uint32_t insn; /* * Length in bytes of the trapped instruction in guest memory: 2 or 4. * This need not be the length of the encoding in insn, as a compressed * instruction may have been transformed into its 32-bit equivalent. */ unsigned int insn_len:3; > >> + } >> + else >> + { >> + const struct cpu_user_regs *regs = gf->regs; >> + struct trap_info utrap = {}; >> + >> + /* >> + * Bit[0] == 0 implies trapped instruction value is >> + * zero or special value. With the pseudoinstructions ruled out >> + * above, only zero is left: the instruction has to be read from >> + * guest memory. >> + */ >> + >> + di->insn = riscv_read_guest(regs->sepc, true, &utrap); >> + if ( utrap.scause ) >> + { >> + /* >> + * If during getting of trapped instruction a fault happen in >> + * G-stage translation then CAUSE_LOAD_GUEST_PAGE_FAULT is >> + * generated. Such faults during this operation is considered as >> + * bus error. >> + */ >> + if ( is_load_guest_page_fault(utrap.scause) ) >> + utrap.scause = CAUSE_FETCH_ACCESS; >> + >> + utrap.sepc = regs->sepc; > > Couldn't this be part of the initializer of utrap? Or does read_guest() > alter the field? It can't: on a fault read_guest() overwrites it. The exception table fixup records the sepc of the nested trap, i.e. Xen's own PC at the faulting hlvx, while the trap is to be reported to the guest at its instruction. I'll add a comment saying so: /* * Not set in the initializer: on a fault read_guest() leaves in * utrap.sepc the address of its own faulting access, whereas the * trap is to be reported at the guest instruction. */ utrap.sepc = regs->sepc; > >> + trap_redirect(&utrap); >> + >> + return true; >> + } >> + >> + /* >> + * riscv_read_guest() fetches at most two halfwords, so a wider >> + * encoding has been read in part only and cannot be decoded here. >> + * >> + * Report an illegal instruction, which is what the guest would have >> + * got for such an encoding anyway: the ISA defines no instruction >> + * wider than 32 bits. >> + */ > > Such wording is at risk of going stale. Better say that no guest-exposed > extensions have wider than 32-bit insns. I will re-word in the following way: /* * read_guest() fetches at most two halfwords, so a wider encoding has * been read in part only and cannot be decoded here. * * Report an illegal instruction: none of the extensions exposed to * guests has instructions wider than 32 bits, so such an encoding is * not a valid instruction for the guest in the first place. */ > >> + if ( !INSN_IS_16BIT(di->insn) && !INSN_IS_32BIT(di->insn) ) >> + { >> + utrap.sepc = regs->sepc; > > With the earlier remark this may then also not be needed here. > >> + utrap.scause = CAUSE_ILLEGAL_INSTRUCTION; >> + /* >> + * stval is left zero: the spec allows that for an illegal >> + * instruction, and only part of the instruction is in hand. >> + */ > > Not just this - stval may also not be wide enough to hold the full insn. Right, I'll mention that as well: /* * stval is left zero, which the spec allows for an illegal * instruction: only part of the instruction is in hand, and stval, * being only XLEN bits wide, may not be able to hold all of it * anyway. */ > >> + trap_redirect(&utrap); >> + >> + return true; >> + } >> + >> + di->insn_len = INSN_LEN(di->insn); > > If you moved this up a little, you could avoid the separate use of > INSN_{32,64}BIT_MASK above, by going from the value calculated here. > I will do in this way as INSN_LEN() will (after a conversation in another thread) return zero if insn is something not 16 or 32: di->insn_len = INSN_LEN(di->insn); ... if ( !di->insn_len ) >> + } >> + >> + return false; >> +} >> + >> +/* >> + * Decode the load or store instruction fetched into @di, filling in the >> + * remaining fields of it (@di->insn and @di->insn_len are filled by >> + * insn_fetch_faulted()). >> + * >> + * @xlen is the effective XLEN of the guest, needed as >> + * the encodings which exist for XLEN=64 only must not be recognized for a >> + * 32-bit guest. >> + * >> + * Returns false if the instruction is not a load or store which can be >> + * emulated here. >> + */ >> +static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di, >> + unsigned int xlen) >> +{ >> + unsigned long insn = di->insn; >> + /* Register fields of the uncompressed forms ... */ >> + unsigned int rd = RV_RD(insn); >> + unsigned int rs2 = RV_RS2(insn); >> + /* >> + * ... and of the compressed ones, where the 3-bit field selects one of >> + * x8..x15, while the stack-pointer-relative forms have a full-width one. >> + */ >> + unsigned int rs2s = RVC_RS2S(insn); >> + unsigned int rs2c = RVC_RS2(insn); >> + >> + di->is_write = false; >> + di->is_unsigned = false; > > Elsewhere we established that the whole struct has to start out zeroed. > Why not leverage that also here? The callers don't actually zero it at present: di is declared without an initializer in both emulate_load() and emulate_store(), which is why these two fields get reset here. But I agree that's the better way: I'll have both callers initialize di with {} and drop the resets, stating in the comment that @di is expected to start out zeroed: " ... insn_fetch_faulted()). Fields which don't apply to the instruction are left * alone, so @di is expected to start out zeroed. " > >> + di->reg = rd; >> + >> + if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB ) >> + di->len = 1; >> + else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU ) >> + { >> + di->len = 1; >> + di->is_unsigned = true; >> + } >> + else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH ) >> + di->len = 2; >> + else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU ) >> + { >> + di->len = 2; >> + di->is_unsigned = true; >> + } >> + else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW ) >> + di->len = 4; >> + else if ( xlen == 64 && (insn & INSN_MASK_LWU) == INSN_MATCH_LWU ) >> + { >> + di->len = 4; >> + di->is_unsigned = true; >> + } >> + else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW ) >> + { >> + di->len = 4; >> + di->reg = rs2s; >> + } > > These insns encode the access width uniformly, i.e. doing things the > way done above is rather inefficient. I think that I don't know how to do that better at the moment. It could be less of if/else if to do in this way: static bool decode_ldst_insn(struct decoded_insn *di, unsigned int xlen) { uint32_t insn = di->insn; unsigned int funct3, width_log2; if ( INSN_IS_16BIT(insn) ) { /* * C.LW, C.LD, C.SW and C.SD (bits[1:0] == 00), and their sp-relative * C.*SP forms (bits[1:0] == 10), have bits[15:13] of the form x1y: * x is set for a store, and y selects a width of 4 or 8 bytes. */ funct3 = RV_X(insn, 13, 3); if ( (insn & 1) || !(funct3 & 2) ) return false; di->is_write = funct3 & 4; width_log2 = 2 + (funct3 & 1); if ( !(insn & 2) ) di->reg = RVC_RS2S(insn); else if ( di->is_write ) di->reg = RVC_RS2(insn); else { di->reg = RV_RD(insn); /* C.LWSP and C.LDSP are reserved with rd being x0. */ if ( !di->reg ) return false; } } else { /* * funct3[1:0] is log2 of the width in bytes, and funct3[2] selects * zero-extension for a load, while being reserved for a store. */ funct3 = RV_X(insn, 12, 3); width_log2 = funct3 & 3; switch ( insn & INSN_OPCODE_MASK ) { case INSN_OPCODE_LOAD: di->is_unsigned = funct3 & 4; di->reg = RV_RD(insn); break; case INSN_OPCODE_STORE: if ( funct3 & 4 ) return false; di->is_write = true; di->reg = RV_RS2(insn); break; default: return false; } } di->len = 1U << width_log2; /* * No access is wider than XLEN, and one as wide as XLEN exists only in * its sign-extending form: this rules out the encodings which exist for * XLEN=64 only on a 32-bit guest, including C.FLW for C.LD (and alike). */ if ( (di->len * BITS_PER_BYTE > xlen) || (di->is_unsigned && di->len * BITS_PER_BYTE == xlen) ) return false; return true; return true; } But I am not sure this is what you meant. > >> + /* c.lwsp and c.ldsp are reserved with rd being x0. */ >> + else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP && rd ) >> + di->len = 4; > > Careful with insns not part of the base ISA: Between the trap and you > getting to fetch and decode, the in-memory insn may have changed. You > posibly set yourself up for vulnerabilities if you permit C encodings > for guests not having C exposed to them. I think then it will be better to reject it duing instruction fetch in insn_fetch_faulted(): di->insn_len = INSN_LEN(di->insn); /* * read_guest() fetches at most two halfwords, so a wider encoding has * been read in part only and cannot be decoded here. * * Report an illegal instruction: none of the extensions exposed to * guests has instructions wider than 32 bits, so such an encoding is * not a valid instruction for the guest in the first place. The same * goes for a compressed encoding where C isn't exposed to the guest: * the instruction in memory may have been changed since the trap, so * what is read back must not be taken to be what trapped. */ if ( !di->insn_len || (di->insn_len == 2 && !riscv_isa_extension_available(current->domain->arch.isa, RISCV_ISA_EXT_c)) ) { ... Would it be better? Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Sep 14 21:38:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 21:38:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1420749.1647274 (Exim 4.92) (envelope-from ) id 1x6EN1-0005b3-I3; Mon, 14 Sep 2026 21:37:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1420749.1647274; Mon, 14 Sep 2026 21:37:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6EN1-0005av-Dk; Mon, 14 Sep 2026 21:37:47 +0000 Received: by outflank-mailman (input) for mailman id 1420749; Mon, 14 Sep 2026 10:50:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x64GK-0007R8-AL for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 10:50:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x64GJ-00FQGd-64 for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 12:50:11 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa7d153-e002-0a2a0a5209dd-0a2a4501dfa0-34 for ; Mon, 14 Sep 2026 12:50:10 +0200 Received: from [40.107.200.21] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa7d160-5984-0a2a45010019-286bc815b109-3 for ; Mon, 14 Sep 2026 12:50:10 +0200 Received: from PH1PEPF0001330C.namprd07.prod.outlook.com (2603:10b6:518:1::1b) by SJ2PR12MB8650.namprd12.prod.outlook.com (2603:10b6:a03:544::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.11; Mon, 14 Sep 2026 10:50:00 +0000 Received: from SJ1PEPF000023D1.namprd02.prod.outlook.com (2a01:111:f403:c902::7) by PH1PEPF0001330C.outlook.office365.com (2603:1036:903:47::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.9 via Frontend Transport; Mon, 14 Sep 2026 10:50:00 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000023D1.mail.protection.outlook.com (10.167.244.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Mon, 14 Sep 2026 10:50:00 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 14 Sep 2026 05:49:59 -0500 Received: from localhost.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49 via Frontend Transport; Mon, 14 Sep 2026 05:49:57 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xQ9tOJm+K6dWjjze29Dbch5nS/aX3hVLlSii86/apwzsSjA+4LyyE4jWrkfHaYjaHz2ZgsbQguOsmRuczF8zdGZD7xjHejWeTp/SOocO46Cv52VYj9N7WkJRzC/jVfZDcq8FsMBBaO9Lwq9S06y7ctd3crVZ41NQjGkrFu2CEIyQ5BUzpR2VGxnsgK/0rtY9wl8NzL3STqSD7x89U/oSSinY4tdJBJh+lUKrDgwc8nwAFfBZR/CNXZm+svI87DyyFROhGsmPc0rtR5UxWXFvMx4yUNnuJMURy9opwvwTef+pfhM+K49vijR1KwTw1lfxaAxbwgILsn3u+F+qa/C7OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JmMNrl28IFnlEeTDxgaWxQyRK4ELYjXjpeG1ntvUuIk=; b=ht3YLv2woc0ZTw7W4egqmS85qhglS5DLWdqDq2iPT6G3d+9OtFf5O3HQEn/35rlH0IyA+VoMe6WcltKdhsWosdQj4cF3Tq5Sg/93iRRarquNEEyK7o+4bvyC1TBtJMPE/VwVlDDwVPt20i93SrEmOYRm9Oh29RsSgtaMc0RS1ZS7BXAEUSNPnG+0dhn9TMn86axeWB2IvIth/0oqa6T1cItglqbiUyKHSxhvIFyVsJOYG62Iq2/r51tYlknp+2V0g+/+6czedNA1KrPUpwhp9/kc4S5Z8UvnxRBHRtgabjCA9jo39hqAxpMaiX98R8JOOeDN8dbfcEPucTYUecbelw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JmMNrl28IFnlEeTDxgaWxQyRK4ELYjXjpeG1ntvUuIk=; b=Jl0fEjIb4iPLwwYuzGL1KDh2woqfkR4bRVcGGrUKyyfXad4bx8EPIJQMR2RluRT0NZddoka0QVslC7J5kj1r6p11UEiPNXpMHiS7jqDwqSbEoDRZHbhtiwP2mhD1Bu+/MF/DebxnCG5SI+5qEFy5wGNIpa4eCwQRzJU4UCrm+Rc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Huang Lei To: Juergen Gross , Stefano Stabellini CC: Oleksandr Tyshchenko , Jonathan Corbet , Shuah Khan , , , , Subject: [RFC PATCH] xen/manage: allow forcing shutdown without a userspace helper Date: Mon, 14 Sep 2026 18:49:45 +0800 Message-ID: <20260914104945.637-1-Lei.Huang@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D1:EE_|SJ2PR12MB8650:EE_ X-MS-Office365-Filtering-Correlation-Id: f7e4f340-7021-4ae0-2a3e-08df124dec9d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|82310400026|36860700016|376014|11063799006|56012099006|6133799003|3023799007|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: gXExf+TgtiNmjVO4iBrwlEnf0HIrY5FHbJrpc9QovqsACB8CifaKkI9N3ztVreeje90+631/Ma0Um8QnacXCiNkNORDyBvjUnh/VwxMXEEun3HqNMFbSdmEHt8GfGlvmhJYPtW0Twhlfu/QLTyCBSEXNgltq7RI2YhwRktMxh1RBiQkC1mnrpgsrp2YbLDrrXiW25T0kMTCSMPAKUvM+iqTYsVPOEQBSWPzxlGY1+MpZ32ykGP5EesGAJZxNvpp3yMNXF2G3TXt3wVAHj6RSsl0PIwqIgIGSo6zjDybDzZDwOAJLgsAgvYO2Qnq3EZfblo63yDFyfr7SNEf7dZ5hMYoDurCDk7AAjC6SrprJ4l/gxxZSGJe8NNYbqjPRm/XTtcg/g+Nrgmt8r/EwAdphQ9x7lpuzd2WFzeUKSj2noLPyIA3dbTjJA0/fpXW04mNJKqGSrSNmTHNTmjlSDlVmdSoyk5OelSomENVCx7kBDU1VBpLa9rRLaHpJScH1B8TX2/244SbgwLGe0GO8tknJBYLvLrjOMKXPWCDbkTLhK0llxbz7kBNrcVEYcglQ27YaGb7qMRYwE29XyUKj8vUSTmpvFz/CNdlZoGEzeZZEeC0e5NCdsXkbmBXrAi5hAPcAZLe4OcEssoqQaE3UFUCXgRwRMvyzLgZRO2qemvf8ERgiBCej+FYbw1neaKZY4eUSUhj2uyefqjiDNbgMfTeY/A== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(82310400026)(36860700016)(376014)(11063799006)(56012099006)(6133799003)(3023799007)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: tycHTZ6SmRmI1kW0J1GTaABI+Q1qGQhTtEn+nmmtBO/HjudM3mWcrKBU1LTZJu/MgMqbhlfvaCuNt4F+sJIZUV8NDPoXhZ4JQ8gCnsY7l1lPpF09ztMoTE/2dXbSjs9qKRuVuAdLpB8gMskcJuGRg9joKiN1+YpB5tibf98bSca4P6T6nlBrwbmKU9IvFIGHleY5i0hzenwy20uwez/O/46WEQ3yqb4U8l2+itNJjAskXeXW/6D0jYs0E+enp2146uS2OXKHah2/Q32f+FS2hw9uFkfvAOqR6BWfbHRNpQo4hcu7QywcJl3aQLH6GGWAeWWh3hVHfUBMd9s2bJfKtEAU6qFlVy7MFDBCT9ODn8cAdDfxhz08JMXfwyYsE1UGnhIEAbZ4K4cn4fbSI1QWkkBlFWGOFkgx3R1GeafkZFKg6Tb1opslsR1W10VbYOIH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 10:50:00.0617 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f7e4f340-7021-4ae0-2a3e-08df124dec9d X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023D1.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8650 X-purgate-ID: tlsNG-d62444/1789383010-BC359757-5874B308/0/0 X-purgate-type: clean X-purgate-size: 5274 From: Lei Huang Xen poweroff, halt and reboot requests are normally forwarded to a userspace helper so that the guest can perform an orderly shutdown. Some guests cannot provide a functional helper, for example when their security policy prevents a kernel-initiated helper from completing the operation. Add the xen.force_shutdown parameter to let such guests handle toolstack shutdown requests in workqueue context. Flush filesystems synchronously before performing the transition directly in the kernel. This is an explicit bypass rather than a timeout fallback: once a userspace helper has been executed successfully, the kernel cannot determine whether it will eventually complete the shutdown. Keep the parameter disabled by default so existing guests retain the opportunity to perform userspace cleanup or reject a shutdown request. Enabling the parameter explicitly accepts the risk of losing userspace data which has not been committed before the request. Signed-off-by: Lei Huang --- Notes: RFC: This is an opt-in bypass rather than a timeout fallback. Once a userspace helper has been executed successfully, the kernel cannot determine whether it will eventually complete the shutdown. Would a kernel command-line opt-in be acceptable for this case, or should the policy be represented through XenStore instead? Test status: This exact xen.force_shutdown=1 version was built and booted on a Celadon Android Xen PVH guest. An xl shutdown request successfully powered off the guest through the direct kernel shutdown path. .../admin-guide/kernel-parameters.txt | 7 +++ drivers/xen/manage.c | 45 +++++++++++++++++-- 2 files changed, 49 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index b5493a7f8f2..6beda2f3d5b 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -8623,6 +8623,13 @@ Kernel parameters fairer and the number of possible event channels is much higher. Default is on (use fifo events). + xen.force_shutdown= [XEN] + Force Xen toolstack poweroff, halt and reboot requests in + the kernel instead of invoking a userspace helper. This can + cause the loss of uncommitted userspace data and should only + be enabled for guests without a functional userspace shutdown + helper. The default is off. + xirc2ps_cs= [NET,PCMCIA] Format: ,,,,,[,[,[,]]] diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c index 05d7de128e7..a86426c8671 100644 --- a/drivers/xen/manage.c +++ b/drivers/xen/manage.c @@ -7,14 +7,17 @@ #include #include +#include #include #include +#include #include #include #include #include #include #include +#include #include #include @@ -38,6 +41,14 @@ enum shutdown_state { SHUTDOWN_HALT = 4, }; +#undef MODULE_PARAM_PREFIX +#define MODULE_PARAM_PREFIX "xen." + +static bool xen_force_shutdown; +module_param_named(force_shutdown, xen_force_shutdown, bool, 0444); +MODULE_PARM_DESC(force_shutdown, + "Force Xen poweroff, halt and reboot requests without a userspace helper"); + /* Ignore multiple shutdown requests. */ static enum shutdown_state shutting_down = SHUTDOWN_INVALID; @@ -189,15 +200,40 @@ static int poweroff_nb(struct notifier_block *cb, unsigned long code, void *unus } return NOTIFY_DONE; } + +static void xen_poweroff_work_func(struct work_struct *work) +{ + pr_warn("Forcing Xen toolstack shutdown without userspace cleanup\n"); + ksys_sync(); + kernel_power_off(); +} + +static DECLARE_WORK(xen_poweroff_work, xen_poweroff_work_func); + +static void xen_reboot_work_func(struct work_struct *work) +{ + pr_warn("Forcing Xen toolstack reboot without userspace cleanup\n"); + ksys_sync(); + kernel_restart(NULL); +} + +static DECLARE_WORK(xen_reboot_work, xen_reboot_work_func); + static void do_poweroff(void) { switch (system_state) { case SYSTEM_BOOTING: case SYSTEM_SCHEDULING: - orderly_poweroff(true); + if (xen_force_shutdown) + schedule_work(&xen_poweroff_work); + else + orderly_poweroff(true); break; case SYSTEM_RUNNING: - orderly_poweroff(false); + if (xen_force_shutdown) + schedule_work(&xen_poweroff_work); + else + orderly_poweroff(false); break; default: /* Don't do it when we are halting/rebooting. */ @@ -209,7 +245,10 @@ static void do_poweroff(void) static void do_reboot(void) { shutting_down = SHUTDOWN_POWEROFF; /* ? */ - orderly_reboot(); + if (xen_force_shutdown) + schedule_work(&xen_reboot_work); + else + orderly_reboot(); } static const struct shutdown_handler shutdown_handlers[] = { From xen-devel-bounces@lists.xenproject.org Mon Sep 14 21:38:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 14 Sep 2026 21:38:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421151.1647284 (Exim 4.92) (envelope-from ) id 1x6ENA-0005pX-TA; Mon, 14 Sep 2026 21:37:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421151.1647284; Mon, 14 Sep 2026 21:37:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6ENA-0005pQ-PU; Mon, 14 Sep 2026 21:37:56 +0000 Received: by outflank-mailman (input) for mailman id 1421151; Mon, 14 Sep 2026 15:55:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x691K-0002B7-Sa for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 15:55:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x691J-00DrMg-PI for xen-devel@lists.xenproject.org; Mon, 14 Sep 2026 17:55:01 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa818b5-2eae-0a2a0a5409dd-0a2a45078726-46 for ; Mon, 14 Sep 2026 17:55:00 +0200 Received: from [192.198.163.18] (helo=mgamail.intel.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa818d1-b4ea-0a2a45070019-c0c6a312c3f5-3 for ; Mon, 14 Sep 2026 17:54:59 +0200 Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2026 08:54:54 -0700 Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa003.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2026 08:54:53 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 14 Sep 2026 08:54:52 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46 via Frontend Transport; Mon, 14 Sep 2026 08:54:52 -0700 Received: from DM5PR21CU001.outbound.protection.outlook.com (52.101.62.69) by edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Mon, 14 Sep 2026 08:54:52 -0700 Received: from SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) by SA3PR11MB566415.namprd11.prod.outlook.com (2603:10b6:806:589::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Mon, 14 Sep 2026 15:54:50 +0000 Received: from SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc]) by SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc%5]) with mapi id 15.21.0406.007; Mon, 14 Sep 2026 15:54:49 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=Intel header.d=intel.com header.i="@intel.com" header.h="Message-ID:Date:Subject:To:CC:References:From:In-Reply-To:Content-Transfer-Encoding:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789401299; x=1820937299; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=tz0kGCFO8UJKs7OlRSI5fOcp+hF2EbB44q3ez+I5y2s=; b=FFqUGfh8dDe0wLWp5CBK6wwcegAxgI4TQegI1J8Mz6iLYhZmQRpXx//3 zePpeTp9HKW257Ab8Lvsl53QC1cxIv84UGniopFbjIdoWWI2PfR7LOYkG YgRsGOBELZ7ToGcYQ1YsZuO9PeGKX4FC7tJ+/WPwyqXahuL95fyUfF19f 9aJgLg4L6BUlsXH/iHIN3J9InZn0mRCP5YWxnO4yBVN4waNG+EpPLOoGv b+q3t6pbN1jZ7meS/Mfm1aYbE5LuFe8nVOFJnntMqigMiYZGdh086/DcI xmBcn+QRln1gf3tp+4IoPkVHwxLmc1gnCDQSagh1TYfMEflG+Q02nZSNZ Q==; X-CSE-ConnectionGUID: Ut9j+PadQWqZ9kT2wYpWhg== X-CSE-MsgGUID: On3S1WY0TpGjnIBbi8h+Pg== X-IronPort-AV: E=McAfee;i="6800,10657,11905"; a="88893859" X-IronPort-AV: E=Sophos;i="6.27,103,1787036400"; d="scan'208";a="88893859" X-CSE-ConnectionGUID: GAKaSmkeRIeb/AsJULLdIw== X-CSE-MsgGUID: xOuHZigwRJOE7FyzMD2fgA== X-ExtLoop1: 1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=X6IjsL3/Dl7c+Bonbh13vnjEG/5KJJhyeUqwy1KVmGBwKkGVyg4sdQcGUOJOrRKTfP137+nJAP8i8WTKT6fV932YRiU2WCc2iQs14oJz7FKVw5zSns2aVfZpKyzLnn9xJLDqdupUekrWFaqRGhRLgBcfy7XWt+y8qbmtgkOR1SkhyPrBkUQubG08CO8fTo2fkpEfR+dWkVTm3uiX+9OMhz/5H99HafC2G4fN/YosTvZJMwZCLTKgC8maYYxCjUdvAwkwChaUAKOdnbIqk7M+4wwaE9u7Ext7SbYw/eicLM7atRC5Lb88ohdsZd03l/gYB8OkR31hqhn93CWMNlyaQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YJywIoQ62JkPFaRDKdqkSpKHrELoIjFnIMHh4GDwy5M=; b=TMNampOHWSONDb5XzQ+gnvcDil50bPYlhc6VxF4OTqh2BbnhLyzQXjNHuAD74WzyJPe3UfWZ/WYCF3A0xVDjIW/paprfTNR+tG5QM45qYT00y1zN/zQ+71EiEwZTUc9obti8oGkm+1NyIXQcXFhA6AKyxjmxAnF91iCYXrr3Hg2LKVcwGZwrR1LH8Dhj/wZT1Y9KNvqQXgryLUrIUNo8z4lXv265nZBrfuEM3vsi6t1nLOm7/OA/L3QPqxgPn/hGKSRGXITdshy8GkDh+pKvDkpcTSj3DLk4eX2DlPBxQxbFod8LkQe/Pkd4Yxl2q9a7RTNlKSe93fd5e8wMkQoWww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Message-ID: <13c52f11-61c9-48a4-ab6c-3ebe7676fdda@intel.com> Date: Mon, 14 Sep 2026 08:54:42 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 12/13] treewide: convert rdmsrq() from a macro to an inline function To: Juergen Gross , , , , , , , , , , , , , , , , , , , CC: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , "Alexander Shishkin" , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , "Dexuan Cui" , Long Li , "Sean Christopherson" , Paolo Bonzini , "Ajay Kaher" , Alexey Makhalov , Broadcom internal kernel review list , Josh Poimboeuf , Pawan Gupta , "Pu Wen" , Tony Luck , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , "Vitaly Kuznetsov" , Andy Lutomirski , "Bjorn Helgaas" , "Rafael J. Wysocki" , "Pavel Machek" , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Damien Le Moal , "Niklas Cassel" , David Airlie , Olivia Mackall , Herbert Xu , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Linus Walleij , Bartosz Golaszewski , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Arnd Bergmann , Greg Kroah-Hartman , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , "Rajneesh Bhardwaj" , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , Helge Deller , , , "Michael Kelley" References: <20260911074530.3140830-1-jgross@suse.com> <20260911074530.3140830-13-jgross@suse.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: <20260911074530.3140830-13-jgross@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR03CA0053.namprd03.prod.outlook.com (2603:10b6:303:8e::28) To SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR11MB8370:EE_|SA3PR11MB566415:EE_ X-MS-Office365-Filtering-Correlation-Id: 551bf591-1ca3-475a-2be7-08df127881ec X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|366016|376014|1800799024|22082099003|18002099003|921020|4143699003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: FCdcRAsMIgf1njP/rTi6g0mD5FTBwjqPKJlKMfYLIzHABACl3yu+Bp9ABUa4YIxLOSf0A4/1LlfPNfOdSCAagLX6RNR5w/+ZgtlriDS3e8Ti8P7F5MiclfyTSBUc26pDgq0FXpleG0oOAIb21Lenjsm6+eE8MHtwetKU9nH2yPusdp8tmbXqUEjEUtE/3hWH4X4oRvaLaFcohO36Xw4xt5MfwuZtVLhw3Zh0T8J9Z3zVuD5tuGDpLG3NZ8Xh/uBJq+9WXtZFbJPvUTb82v+WUBmHQ7/+emn6VBPh5kEsl9e0p4EUe+gIN5EBx/SckIUTh2+Pfh4Hp9CibOxmo4FI5ejLXsjJpc2uzA5zWmYkVZUBskPNqr/Ce39z3Pth0MTdfwlwzV6voFNyCZCTVTwVORyollyZlS/MfkDul9lHdqhaytdpeVZe316vpXH2UcUga8Iscx3Hl8pvjXyKhORvWGP3muHgAMsRa/RXgHwEzjOJLsJCvZgYPOszsq8iteGLFEQd8JLAAjzX0xmBnLUtLpGvJKy6f2zFtsms3NjiLqoNXkxqQEfytQhOwgFt6i10KrP4H/5cvwqr03FJz3Vldkddg7sqR/f10LoY6Fw73QQrit7NZYQyej5ZfjArn9hQQD3beKMjL0YWKO1Cs+OAFqQ/DnoxSvrg0+YIOX/N0ynQgrUJZ3zVYBUS6cP1N31ZkmfNaPDsQdZ6IEZoL44uOg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR11MB8370.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(366016)(376014)(1800799024)(22082099003)(18002099003)(921020)(4143699003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?blV5NUQ2NHJ2ZThBNHlRSDlwbE83YzhWd2RKV0pTNkJwTGVITnVqZ3FvWTVm?= =?utf-8?B?TDlzNXZwRFkyWkxKYVk3bklTNktuNFF3MWVRZTJkbUkwR28zRitueXBjUC9z?= =?utf-8?B?cHpRRlFwa21hcGdUakRndjEvNE9vbWNTK3dFNXI1NEt6d0s3ajFuTVY1c2tR?= =?utf-8?B?Rk9HbEpqcEN2UlhoRDhUOC9tM1c3NmFrL3V2UjRQQ1QybEI1VG5WeVZ1eEll?= =?utf-8?B?N0FKWnp3UDUwUmkrcjFhNnVDcEN2REZzbEpnMFdTdG9mcEhTOGRFc0dlTGJR?= =?utf-8?B?eHZJaXpBWENBd28yYnp1cGQ1T1pjNjlJNWJ2bzYrZlhhU3VrMGZFeVZiNTVo?= =?utf-8?B?T0hDUFNqaVdMcXZRc3lTMFBIbE5CQzdsenJzT3QxbFF0UGlhN0kyS2thMDhh?= =?utf-8?B?VkNiME1ZZEhOVUJ1Q2hCMm9DYUNFemlBWDVpdG9NYnJDa3RQUkZ4akNVNXZS?= =?utf-8?B?V0NWRnhBcWtMQzBFTTREbVZ1SmZ6YjdmampncFJxR2xvMWdSYmRUdy9kNlJw?= =?utf-8?B?SWtGOEc5QUt1V1F6Z3A2YmR2bnFRVDZMQ1FZd0VQckxCRkpUVEhQcVFwWCtn?= =?utf-8?B?YUc0T3pRWHNvd1JzYVVkaWxmZHRYQ3ZBalZ1a3FuazNyNjVIajNpNFNkT2Zh?= =?utf-8?B?RTJsUVVSR3ZuME12a1k3Y21XWWJGKzR3TmQ1bkpUZHJ2cFZZbHpFeDJybyt3?= =?utf-8?B?enk3N01DL2syc2tTeUlKdG1aaGN4S25TWG9wS0hwcHFNeGJRV0oyTVl6TThJ?= =?utf-8?B?WnJMaFBDMjFXNndNb1hxQitNLzJqM2E2WFZjTWNwVDlXbVpLTGtzWDJWb0g2?= =?utf-8?B?V0s2Q1E3STZ5UklOSE5HSzR5UUJEaXpkVFNRRVRCVDBTczdiZ0U1NVF6YVE2?= =?utf-8?B?K3cxMjFIZTVLRUorWTdzK3M0QmRVNFFMSDk5T0JNL240SlhhQi9ieFo4SWxn?= =?utf-8?B?eStPOGZMeUVwQnhRTkg3M0ZyM3NaWnQybTZGbnJ1VXg3a2RTdWo5ODBIbDJ6?= =?utf-8?B?YmxUeHBYcFpmdzZvZS9sM25ZWC84SHV3Q2tvZ0s5b0Y1K3NzV3ZMRmhtVExu?= =?utf-8?B?VEU1OFdpdnZqZzFabi90SHVla25CeEVWZDdwOE9DY2EvT2ZZVk1FL0ovSXho?= =?utf-8?B?QXdybWVKM00yNEVPSWsyUzUwcUJGOHp2VUFVM1lQTWZncUZYaWxaaG9LL0Jk?= =?utf-8?B?QStDRUlJaVM3YmhVb3RiRXhkVEZQbmdxczlub1NFbkl1RzByWHJvWW5FUm1Q?= =?utf-8?B?UFlwejJ6UnE1RGV4aGQ1a2NGYlliT3U1VjZRL25LekJhKzZIVWRkQ0M2YVdU?= =?utf-8?B?QXhRc040MWJ3aDRUSmtuZzMwZ1JKaHg0QXBLUXNlWDE5UHdMQVlPSFhyUkRt?= =?utf-8?B?cEIyak13UGtmcnU2UmxVVlVXVnEwVzhzR1c1NWpsYlJqNWsvQUtyMUlJUHN5?= =?utf-8?B?bkxrRlVJWU05akJoRkd3WGE0TVhubU15OHZtTjJCYlRwVERFSHUxZkdYL2JI?= =?utf-8?B?SFNMVkVsT3R6WlFMeFpZSXlFTGl0ZWxjaFl6OUx0SFVVNzYydXJodkRwS2ZH?= =?utf-8?B?YVZHUC9RQ0g4ZGZ4K0VGYUlpOEZFbmJxempscUg4NFpMaEpWSlBzckovQ08y?= =?utf-8?B?UXRibTNOSHNJdnRrV3Vtdkl6YmRLNE9jZnRvS3A3MG04V1pQUWFpN2NtekNT?= =?utf-8?B?ZldPdkU0R2owYldDYzdwQWdIdVdEU2RPdFVaUlRHL1FMTmxsZmNhdDZvMFo4?= =?utf-8?B?bkJ1U1BCY2JVUFJURW50Z1ppS3ZhTVBqcWNVSTNUbW9vdnNQNHNveVB1UThI?= =?utf-8?B?SGp1YkZhYzBsenB0YVpwN2NzQkVhaGJwNDFiU3lMYk9WSWhIZlgzSThWSElW?= =?utf-8?B?UGdEYlQ1NHNoNmRuMG5CZlU5dVFEYVdiaG1oRUp3VUhvUHpMMG1ZUGlWRmli?= =?utf-8?B?RGNEVWVselVGSzJkVUFjWFVkQmpzVU1PVktPcGRJd0NlT0hiUlB2RWU1SUZY?= =?utf-8?B?OCs2ak1RSXlsajlxUXlkdGFBckRZYVQ0RlFHUGcvd0RiNGs1eTBPMTc4ZHJi?= =?utf-8?B?cnNVeU15by9wUXl1QVpxZWlyUCtjOWdyOXpJSU4xb0tiUXZ1M0FLV1Z3VGVy?= =?utf-8?B?ODNTOEM3ckg0cklNelRmOWxTQlAyWUI0c01hSG1oVGFqRnh0aUM4djVQMW9T?= =?utf-8?B?Z2V2NHFERkpYaXpROHZYOXpOQnNyRW5QQ2hwTCtuZW5PT1N0ZWpPU2tFdU95?= =?utf-8?B?YjRUU0phOXhSK29pa2xadXRsYmZmVC93aWh1eUxEQkZWbW51Tm10ZjJPVmpj?= =?utf-8?B?WXFqSVRJTGtiZ3R5R0RNTXNVc1J6VVNyWmowVEJpcnYwemlmR09NajZIV2R1?= =?utf-8?Q?wLXmYqB+hVXFJCZQ=3D?= X-Exchange-RoutingPolicyChecked: cyJqkjq6LyZ2s/C+Xz7GWP1SYjQVauCVMSHvaQuLdJ+lkqMVaOgWZxc0DGnNUiNWVwimNV2eSi6F0Gre6pt6CeAetaTxAiW7qjQ82x/dc2LflDMjYvQzKoek1JsM0VXNKs4/nbh/qNYCXy92HxilQngMPjr7og596FIb+ZRQlVkbp/LKWvzvLnenDaaN2uOZ5Re1g7yzInlf2pPBx0AkkUuVxJyRE4/c4e2+bpvoXElbhjoWUiKW7HPqwV1j8mvsvDc5S0kORlABwth4SuwapiMqpm5AedSpNYZiuiIVqQORwovJaRjSsQzA5TkohpYyNIp1YWPObfx+EVzLYznZJA== X-MS-Exchange-CrossTenant-Network-Message-Id: 551bf591-1ca3-475a-2be7-08df127881ec X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2026 15:54:49.7466 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SaRdg+Ghp5yz6Z/XSmHZMZPrm05TT0dIoDTHljLMsUnfo0Fa/XkbNuA7gxHhR3aB8ylqcr2YZxDn7J7qkI77a4ZJFExbfFgBGARpRscpYkw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB566415 X-OriginatorOrg: intel.com X-purgate-ID: tlsNG-ef75cf/1789401300-A68D9AE4-317794BE/0/0 X-purgate-type: clean X-purgate-size: 1012 Hi Juergen, On 9/11/26 12:45 AM, Juergen Gross wrote: > Today rdmsrq() is a macro using its second parameter as the target for > storing the read MSR value. > > Convert rdmsrq() to an inline function returning the MSR value. > > The users have been converted using the following semantic patch: > > // Options: --include-headers > > virtual patch > virtual report > > @@ > expression msr, val; > @@ > ( > - rdmsrq(msr,val) > + val = rdmsrq(msr) > ) > > Signed-off-by: Juergen Gross > Acked-by: Damien Le Moal # ATA > Reviewed-by: Michael Kelley # Hyper-V > --- ... > arch/x86/kernel/cpu/resctrl/core.c | 2 +-> arch/x86/kernel/cpu/resctrl/monitor.c | 4 +-- > arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 +-- > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +- Thank you. Acked-by: Reinette Chatre # resctrl Reinette From xen-devel-bounces@lists.xenproject.org Tue Sep 15 05:12:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 05:12:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421446.1647293 (Exim 4.92) (envelope-from ) id 1x6LT1-0007aD-Bs; Tue, 15 Sep 2026 05:12:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421446.1647293; Tue, 15 Sep 2026 05:12:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6LT1-0007Zu-6i; Tue, 15 Sep 2026 05:12:27 +0000 Received: by outflank-mailman (input) for mailman id 1421446; Tue, 15 Sep 2026 05:12:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6LSz-0007Zm-FK for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 05:12:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6LSy-00FF8d-7p for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 07:12:24 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa8d396-e002-0a2a0a5209dd-0a2a4506d788-26 for ; Tue, 15 Sep 2026 07:12:24 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa8d3b7-195a-0a2a45060019-416d716cecde-3 for ; Tue, 15 Sep 2026 07:12:24 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 424C640E00B9; Tue, 15 Sep 2026 05:12:23 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id l7mK6AY6STDk; Tue, 15 Sep 2026 05:12:13 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 99D8240E015D; Tue, 15 Sep 2026 05:11:58 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1789449133; bh=hLEWkb75NILErIyiEvrD6H5Nyelzx0xY/igrkoWaqWk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JpG6RQygncGPaWQbpmRNxxwJCcqwa5zGFcq7wXesX1MmWu5X84jzrTis3K34DMzwM cUdiscylPSQgVCua0KQJOj/vAYrZhUBXO1iZXS/vNmpja/FvkQXqej1nNd3/rmwLAx hq1FdeUgxjsUXOK6uFSHn43qfp5DYsUGbwIQoAJjd3F77PybjeoCRY6+yZ4/ZAxwy2 /KC0Q4B6qk+wlC3WzM6y8a8crPlbeCu/z+qPzVw9uK6gwxGpO4D5bjEZEbKH14QSDB xz4EwFmxy9kx0gwZrZLja4Cakm9KfReIa/oFlVP1ClPsyZTtp1bIVXkoOT/JfsWFFz zHMCrNzhHoB1wwBvgfaSzpsneU3Ud1m/DX5mrku2Ok1CjJtiLJrkqE6Bc39zakdt6y kDAvFl+u8OkXvuiL5uRO0o8a5/Xe+PVRFFGfo/XZM88gjbpy/7xMT9E/mwxc2arID0 L32tLGSgjo3OnoVIxuHLuKFFZ3nWwWNTaozksEkiXVHJ+TDpzJpEkMsuLApWCVjToF rU6J7yoBjWlEghXu6itUXnnDInCq1AKVACCZfpMI87AUKa5ojEnkBeb12CYoKW9fQQ wYqWQws2pnIWYZ/Zk41/4YWS4C7cdLM9Lw/SMHY2N6aZfvfu17hm8ycMoTNYVqe9N6 GrBoXGvQi6Ai4aCNnH/+FMgs= Date: Mon, 14 Sep 2026 22:11:55 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() Message-ID: <20260915051155.GGaqjTm7yIluwxZ80x@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> <6113f06c790cfe1141d2dc09b68937b6@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6113f06c790cfe1141d2dc09b68937b6@igalia.com> X-purgate-ID: tlsNG-16d1c6/1789449144-FD80D77B-72D5BFE1/0/0 X-purgate-type: clean X-purgate-size: 565 On Mon, Sep 14, 2026 at 08:22:08AM -0300, Mauricio Faria de Oliveira wrote: > In the review of the original patchset (fixed by this series) it is > mentioned that a compiler might turn it into a memcmp() [1] -- and thus > revert back to the same issue. > > [1] https://lore.kernel.org/all/877ccz12ab.ffs@tglx/ Hmm, never heard that before but that doesn't mean anything. Probably should mention it in one of the commit messages so that we know for the future... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Tue Sep 15 05:18:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 05:18:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421454.1647302 (Exim 4.92) (envelope-from ) id 1x6LZF-0008CF-TN; Tue, 15 Sep 2026 05:18:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421454.1647302; Tue, 15 Sep 2026 05:18:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6LZF-0008C8-QR; Tue, 15 Sep 2026 05:18:53 +0000 Received: by outflank-mailman (input) for mailman id 1421454; Tue, 15 Sep 2026 05:18:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6LZF-0008C2-0a for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 05:18:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6LZE-00CjpQ-A6 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 07:18:52 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa8d521-e002-0a2a0a5209dd-0a2a4501aa30-28 for ; Tue, 15 Sep 2026 07:18:52 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa8d53b-5984-0a2a45010019-4a7de14cafdf-3 for ; Tue, 15 Sep 2026 07:18:52 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356256so981737f8f.1 for ; Mon, 14 Sep 2026 22:18:52 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e7d280f69sm32885055e9.3.2026.09.14.22.18.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2026 22:18:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789449531; x=1790054331; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=is8I/jPfh/JULRUoN5crrHFUA655y0BwhWcPxqSjvzA=; b=AOWtJJBRwvP+ijDnMZtufq+rh4qGm3WWbsQNEwBUo/m0VZaXj8sC/62NoEDHj7sg1P NbS9RhNq5YS2aC5stKa5YK1RwSN+GodD6huY3tv7YAEAoskBtBEjMtOLaFmmNy1dm8Nh RoK0MX9K1kZNRrn0HgV5aonk7v4tW18fyP/We1vgRyAm+FNX8st5HGHZOMdwP4WkitZi NRIhQ2Gs2CvlkXzQuCci2WTSvTecHGJpK6jYFJ43bTBRM8/2gV07lL8bv29VuZZ+CHHm BfhZ4+t4E+zjwunUj+2DAze5jzThlhySlL0FmVNB525ZTmYoHPi7u5y7oQPA/xLkNY+F GA3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789449531; x=1790054331; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=is8I/jPfh/JULRUoN5crrHFUA655y0BwhWcPxqSjvzA=; b=Tuvy23CTsFRylfX6ftviIvEPwmRpArVQWgcJE+PSVleOAzJBc9+3o4h9WDgUednquG t5cr2N2TUYDeSyrC+TgbChrUvlvWPe37Ow/mjcCjBwoKPeNCHM9HUXJHlQR/8qrqbWTE abdpnA56/mazHmjYDGdHorVKvJDfngtzI7XBDtkRK6wbxmRrwcwWSSfc4UvZ2Pvos8xj ++10xqkJk9zxfSpF/orapeVCKLwey+2LiPbQokNCpN+AzJvmF4bsQDY0G+LHQjRc3oxP vTH2SXufmY6y2TSEtkyXXMkUhTuOfjpHK9SbZmFeaJ6zjvYRJYQ01rjZGX4JZds1LkKn ET2Q== X-Forwarded-Encrypted: i=1; AKwUvBymxdVF+6SqdUO7/UtZHmuWqxQxq5hEYB17JnbqOlVKz/fQuWGlq+gZQRh7XCcQleKuD4Cy67oWlAA=@lists.xenproject.org X-Gm-Message-State: AFuF++nx6dhF+lHCTc3zs4wW0DAys0yIdq5x9V1dqICanTR85j3qUGov unBz8zaHbTuxhNh4x6HAenU5y7nVRmFsEiaoIZHhmj0R2J9GRo9PBmQSIByToCnfCw== X-Gm-Gg: AYBFou1gWRnzMBctlYqysNOeTBrRZrjkF9Jsl2Gka5wQ4hyhFAP7xn+YbmNCxhfndu1 zdi3WGyYUUaAuMctNwBtqrAZ47xm2Rc+IDiOCP5wiik1I8mTe7S0LyreKe3BC/S7cCKtc477z9Q XslsIKiU/w7ZJCQp8qEsSvBPKm8dA2QChUDb2VwK6TpSDrYMPv0MQTy9Dfl3Bt6+SCqj50zN+Ui 59aRsGDSr1Usm47/nw4uASG8tsGMp8ViyL6C69+Yhi2qcDFde4cmPIa9b1pDdH8dK54aZ0SJzvN 1Ggc2EZHBp8ha5ovqo5MxKTwXFZw/xQ2xOvEY3e9eFkj9FjWH30iDbDjQRSzWp1nE3sGaswKuSb Gp8qmelNhetoES6hAIZ9X/WiGs6XL3jd/ZE9wmvc5/Td07s/Ds6pxDvPuhnsjFw9DkIh0DvePUm 6VUXZZjI29qesgGP8bnQ4V0+Zgluap6d6aLQznnob6d2HZ4XrcWEVatu1dyTKIyu0djSQ/18b6U zg= X-Received: by 2002:a05:600c:5352:b0:49e:715d:95ca with SMTP id 5b1f17b1804b1-49e7d750bebmr20952005e9.13.1789449531362; Mon, 14 Sep 2026 22:18:51 -0700 (PDT) Message-ID: <1d11bbb6-ebad-48e3-8a06-695a3d4dc7a0@suse.com> Date: Tue, 15 Sep 2026 07:18:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 24/39] xen/riscv: add helpers for decoding a trapped load or store To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com> <895a427d-1adb-43cb-a2bb-e0e9d50791db@suse.com> <62a6884d-f2dc-46d9-ba5d-0dc4949ba25f@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <62a6884d-f2dc-46d9-ba5d-0dc4949ba25f@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1789449532-1E867757-97B7E468/0/0 X-purgate-type: clean X-purgate-size: 7422 On 14.09.2026 17:57, Oleksii Kurochko wrote: > On 9/14/26 1:03 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> @@ -13,9 +14,29 @@ >>> #include >>> #include >>> #include >>> +#include >>> +#include >>> #include >>> #include >>> >>> +/* >>> + * Determine the trapped load or store instruction which caused a guest MMIO >>> + * trap. >>> + */ >>> +struct decoded_insn { >>> + /* The instruction itself, and its length in bytes. */ >>> + unsigned long insn; >>> + unsigned int insn_len; >>> + /* Width of the memory access, in bytes. */ >>> + unsigned int len; >>> + /* Number of the register operand: rd for a load, rs2 for a store. */ >>> + unsigned int reg; >>> + /* The access is a store rather than a load. */ >>> + bool is_write; >>> + /* The load zero-extends its result rather than sign-extending it. */ >>> + bool is_unsigned; >>> +}; >> >> I wonder how efficient this is. With use of bitfield the size of this struct >> can likely be more than halved. With suitable choice of widths this may not >> even cause significantly worse generated code. >> > > We could compress the structure into 8 bytes: > > struct decoded_insn { > /* > * The instruction itself: no ratified extension defines one wider than > * 32 bits, and insn_fetch_faulted() rejects anything longer. > */ > uint32_t insn; > /* Length of the instruction in bytes: 2 or 4. */ > unsigned int insn_len:3; > /* Width of the memory access, in bytes: 1, 2, 4 or 8. */ > unsigned int len:4; > /* Number of the register operand: rd for a load, rs2 for a store. */ > unsigned int reg:5; > /* The access is a store rather than a load. */ > bool is_write:1; > /* The load zero-extends its result rather than sign-extending it. */ > bool is_unsigned:1; > }; Likely this is going a little too far: The non-bool fields may want to be 8 bits wide, for better code gen. >>> + if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB ) >>> + di->len = 1; >>> + else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU ) >>> + { >>> + di->len = 1; >>> + di->is_unsigned = true; >>> + } >>> + else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH ) >>> + di->len = 2; >>> + else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU ) >>> + { >>> + di->len = 2; >>> + di->is_unsigned = true; >>> + } >>> + else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW ) >>> + di->len = 4; >>> + else if ( xlen == 64 && (insn & INSN_MASK_LWU) == INSN_MATCH_LWU ) >>> + { >>> + di->len = 4; >>> + di->is_unsigned = true; >>> + } >>> + else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW ) >>> + { >>> + di->len = 4; >>> + di->reg = rs2s; >>> + } >> >> These insns encode the access width uniformly, i.e. doing things the >> way done above is rather inefficient. > > I think that I don't know how to do that better at the moment. > > It could be less of if/else if to do in this way: > > static bool decode_ldst_insn(struct decoded_insn *di, unsigned int xlen) > { > uint32_t insn = di->insn; > unsigned int funct3, width_log2; > > if ( INSN_IS_16BIT(insn) ) > { > /* > * C.LW, C.LD, C.SW and C.SD (bits[1:0] == 00), and their > sp-relative > * C.*SP forms (bits[1:0] == 10), have bits[15:13] of the form x1y: > * x is set for a store, and y selects a width of 4 or 8 bytes. > */ > funct3 = RV_X(insn, 13, 3); > > if ( (insn & 1) || !(funct3 & 2) ) > return false; > > di->is_write = funct3 & 4; > width_log2 = 2 + (funct3 & 1); > > if ( !(insn & 2) ) > di->reg = RVC_RS2S(insn); > else if ( di->is_write ) > di->reg = RVC_RS2(insn); > else > { > di->reg = RV_RD(insn); > /* C.LWSP and C.LDSP are reserved with rd being x0. */ > if ( !di->reg ) > return false; > } > } > else > { > /* > * funct3[1:0] is log2 of the width in bytes, and funct3[2] selects > * zero-extension for a load, while being reserved for a store. > */ > funct3 = RV_X(insn, 12, 3); > width_log2 = funct3 & 3; > > switch ( insn & INSN_OPCODE_MASK ) > { > case INSN_OPCODE_LOAD: > di->is_unsigned = funct3 & 4; > di->reg = RV_RD(insn); > break; > > case INSN_OPCODE_STORE: > if ( funct3 & 4 ) > return false; > di->is_write = true; > di->reg = RV_RS2(insn); > break; > > default: > return false; > } > } > > di->len = 1U << width_log2; > > /* > * No access is wider than XLEN, and one as wide as XLEN exists only in > * its sign-extending form: this rules out the encodings which > exist for > * XLEN=64 only on a 32-bit guest, including C.FLW for C.LD (and > alike). > */ > if ( (di->len * BITS_PER_BYTE > xlen) || > (di->is_unsigned && di->len * BITS_PER_BYTE == xlen) ) > return false; > > return true; > > > return true; > } > > But I am not sure this is what you meant. Yes, this goes along the lines of what I was thinking of. >>> + /* c.lwsp and c.ldsp are reserved with rd being x0. */ >>> + else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP && rd ) >>> + di->len = 4; >> >> Careful with insns not part of the base ISA: Between the trap and you >> getting to fetch and decode, the in-memory insn may have changed. You >> posibly set yourself up for vulnerabilities if you permit C encodings >> for guests not having C exposed to them. > > I think then it will be better to reject it duing instruction fetch in > insn_fetch_faulted(): > > di->insn_len = INSN_LEN(di->insn); > > /* > * read_guest() fetches at most two halfwords, so a wider > encoding has > * been read in part only and cannot be decoded here. > * > * Report an illegal instruction: none of the extensions exposed to > * guests has instructions wider than 32 bits, so such an > encoding is > * not a valid instruction for the guest in the first place. > The same > * goes for a compressed encoding where C isn't exposed to the > guest: > * the instruction in memory may have been changed since the > trap, so > * what is read back must not be taken to be what trapped. > */ > if ( !di->insn_len || > (di->insn_len == 2 && > !riscv_isa_extension_available(current->domain->arch.isa, > RISCV_ISA_EXT_c)) ) > { > ... > > Would it be better? It's an option. Where exactly the check is best placed I can't easily say. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 15 05:27:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 05:27:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421464.1647310 (Exim 4.92) (envelope-from ) id 1x6LhI-0001RZ-Pi; Tue, 15 Sep 2026 05:27:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421464.1647310; Tue, 15 Sep 2026 05:27:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6LhI-0001RS-ND; Tue, 15 Sep 2026 05:27:12 +0000 Received: by outflank-mailman (input) for mailman id 1421464; Tue, 15 Sep 2026 05:27:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6LhG-0001RM-RK for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 05:27:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6LhF-00CktJ-Iu for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 07:27:09 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa8d726-8faa-0a2a0a5109dd-0a2a45038bde-26 for ; Tue, 15 Sep 2026 07:27:09 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa8d72d-fae8-0a2a45030019-416d716cd9b4-3 for ; Tue, 15 Sep 2026 07:27:09 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 9482D40E0173; Tue, 15 Sep 2026 05:27:08 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NJEJj1msCFG2; Tue, 15 Sep 2026 05:27:03 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id F340240E00B9; Tue, 15 Sep 2026 05:26:48 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1789450023; bh=HKvxq+Jm0VlS/M6lbhcuyNDa0aYnnNuCZTGWrmh5kJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hrozHNR9PBjD1a2ru5GC60dfZdnUwMfS7jMZLilty/gPY0WAbaefo5To+XQxBpxPj U1rj8n0/pOYYhARENy6aREWflM3W3eG/WmN0RAQ1QMjEfA7RXk7wZwxGMGLjzykjCg 4zazX0ZxGprOgPjSN49BICmFplN6q1pHdPRT8Lv3z0lyV3YM4NgXzndP9OoEsI96Nd QETLQZgfh59duUsjxuhbUc9mJBSVjypRinKeWQViOiO3g6KQcDIx3f2ghgHM6EZWq7 6jHYxgaA6cNib6L3Bd0ShoMuXDfR/0vWhSf7qnoPi7T7cVZk8n/X+EGBk4grf/S0xK /uotGQZ1FML+DVaNWOpJ7kprEmqUTrPZ2BKeiW4JhTMuJKMlPboxsLsZJc4M8M1Jqu ZDdNCxUnndm6HA6urqVFy2mjw9gRMxRwES4ZuHmIBbAu9vD6f3XxPI4vjGGp24D5ia HLrnwdRDs96sTGfDjalAKwYUqWL5QpHY1pVetYTx/Xodsqqq1C2adPM8cCZOOjeanC E6gykAT1C9LiM14xOXTx93970kTYv8CG4qmGbIGHD/hw9Q3QPWUz6q23G3UEYCtPu3 os7ivZBfp2YqyjGl93c9sbb0qHLDeTTBLLQT7Nt5U+/br8Gmg2pytPOhefIKbbrTuF LT0agOuvPqMBStJwpukqCInk= Date: Mon, 14 Sep 2026 22:26:46 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 5/5] x86/pvh: fix unbootable VMs by really inlining memset() in xen_prepare_pvh() Message-ID: <20260915052646.GIaqjXFkXBkWfvt3tP@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-5-e70ef3b75b6a@igalia.com> <20260911043947.GIaqOGE9DFCHWwc6Ys@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-33051d/1789450029-754844E9-91325ED7/0/0 X-purgate-type: clean X-purgate-size: 909 On Mon, Sep 14, 2026 at 08:40:38AM -0300, Mauricio Faria de Oliveira wrote: > Due to scope and review purposes (4/5 is more generic, 5/5 is specific > to PVH). If there's a strong preference to combine these, please just > let me know. But they sound like they're fixing the same thing: "vmlinux no longer boots with CONFIG_PVH if CONFIG_KASAN_GENERIC is set." and this one's commit message: "This particular one (still) generated the inline implementation as expected (at least in these compiler versions)" sounds like it is referring to the previous patch. Or I don't know what you mean with "these compiler versions"? Bottom line: if someone needs to apply both to fix unbootable PVH VMs due to mis-inlining of the compiler, then someone can simply apply one and be done with it. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Tue Sep 15 08:29:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 08:29:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421523.1647320 (Exim 4.92) (envelope-from ) id 1x6OXi-0007h1-E1; Tue, 15 Sep 2026 08:29:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421523.1647320; Tue, 15 Sep 2026 08:29:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6OXi-0007gt-9m; Tue, 15 Sep 2026 08:29:30 +0000 Received: by outflank-mailman (input) for mailman id 1421523; Tue, 15 Sep 2026 08:29:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6OXg-0007gn-VL for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 08:29:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6OXf-001itT-LY; Tue, 15 Sep 2026 10:29:27 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa901e4-2eae-0a2a0a5409dd-0a2a450ac702-4 for ; Tue, 15 Sep 2026 10:29:26 +0200 Received: from [148.163.154.28] (helo=mx0b-0002e601.pphosted.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa901e4-f2d2-0a2a450a0019-94a39a1cc3c4-3 for ; Tue, 15 Sep 2026 10:29:25 +0200 Received: from pps.filterd (m0374955.ppops.net [127.0.0.1]) by mx0b-0002e601.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68F6adpM3727917; Tue, 15 Sep 2026 03:29:15 -0500 Received: from bn8pr05cu002.outbound.protection.outlook.com (mail-eastus2azon11011023.outbound.protection.outlook.com [52.101.57.23]) by mx0b-0002e601.pphosted.com (PPS) with ESMTPS id 4gpvpja46k-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 15 Sep 2026 03:29:15 -0500 (CDT) Received: from BL1PR13CA0332.namprd13.prod.outlook.com (2603:10b6:208:2c6::7) by MN6PR10MB8071.namprd10.prod.outlook.com (2603:10b6:208:4ef::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7; Tue, 15 Sep 2026 08:29:11 +0000 Received: from BN7PEPF0000009C.namprd04.prod.outlook.com (2603:10b6:208:2c6:cafe::32) by BL1PR13CA0332.outlook.office365.com (2603:10b6:208:2c6::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.6 via Frontend Transport; Tue, 15 Sep 2026 08:29:11 +0000 Received: from lewvzet200.ext.ti.com (198.47.23.194) by BN7PEPF0000009C.mail.protection.outlook.com (10.167.248.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Tue, 15 Sep 2026 08:29:10 +0000 Received: from DLEE203.ent.ti.com (157.170.170.78) by lewvzet200.ext.ti.com (10.4.14.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 15 Sep 2026 03:28:28 -0500 Received: from DLEE212.ent.ti.com (157.170.170.114) by DLEE203.ent.ti.com (157.170.170.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 15 Sep 2026 03:28:27 -0500 Received: from lelvem-mr05.itg.ti.com (10.180.75.9) by DLEE212.ent.ti.com (157.170.170.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45 via Frontend Transport; Tue, 15 Sep 2026 03:28:27 -0500 Received: from uda0510294.dhcp.ti.com (uda0510294.dhcp.ti.com [10.24.50.162]) by lelvem-mr05.itg.ti.com (8.18.1/8.18.1) with ESMTP id 68F8SO9d3833282; Tue, 15 Sep 2026 03:28:25 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint-05-2026 header.d=ti.com header.i="@ti.com" header.h="CC:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector1 header.d=ti.com header.i="@ti.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=proofpoint-05-2026; bh=nP2oa/Upr36nO 3JVb2wzWNMKED0TaUB8y8sRyK+QJcU=; b=ogq5PB50fGgqHN4UhfPTdv4I0Ag+9 CU8sRo0X5b+2wxoK2XNpyILQPsJSvngaR2Q1wPKN34WxF3zrvzx2YGFetSyD8TRv wbebfJHF9ab6JVem+OvogaxBmMg14Fk1vaCWyGYnLZDvY85iGSrtCEq1j3UyPk1Y wBNBPpfCQM42TbGbomEV6P6gtLKYXK9H1ncKUc+gr8PTUYR6No5u+TwlMdCNorO2 MvGMXAmiFn20nrVrXwZYB+F962peGZEnTd9xzkdpDC344u3gAzYa96ahRavPoXGM V8nDMX8Wonto/B6tAkqpzjltCGbGbtHHlS4xEZ3dvxyVcwo51bdhrVPUw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NxnRDGjQnPaOD0zDNezjctQSoESmei0R2TQRdkkDLgcDRKZWlUl/vrzdPER5l05aCPjFUfsgcWUxP15LXHKfnzup/+CQFh5qspynzZ6Oeds3JniZtF0SYMQPK/4fG9hFh+yKjUiWZ28qIgfvYXMwjFpjGrNFctJkkVLi/8ba96CejLVhm4UwHtKY3EUpcs2mPkEstUzAfZ0X0lP6lQUy0UiLVbkKcvu5nW+h6R8ZlOSP7sfVdXAf8tHO/35dgdMcz6f0YlH1PIEZdtdN3E4FjKt52w43cpyvkIYEKwYf7Qz3WuMeW4Y2zJcs7AiBg5WxkrOu30wpS5q07hv9EEdidA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nP2oa/Upr36nO3JVb2wzWNMKED0TaUB8y8sRyK+QJcU=; b=bfR0EZsVksRYaADy2uJFabYnBSL5DuTvVNNFSYQXchyiIPKtO3iPHVDX86h0Ld9w+ZPJPAxyU/fdDuzxrw8AYAEuefIZ5+Ecbm6en4JZTLLT7mqvpZeFyhPIhjB8LWFrqgwLE/AsFA+ZfhdM3D5j6+BdfiQ1PxIHoXbQHFIv+cAhCk8qgrEcYkZvqJvONCb8j01FqjMA+n6C6RCRqk/QrVLzQJG5gpQEgNhyWijikjzAcyPCwx2+RgID+65cG+ue0B5tbGdV4BdZ+cyC2LKIx9/lt9Cb7SIAfFm5DXQYCQo/edkjGUDJESm0W0NeGvV9XWZyEiCjcA5RjtgI/1QBoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 198.47.23.194) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=ti.com; dmarc=pass (p=quarantine sp=none pct=100) action=none header.from=ti.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nP2oa/Upr36nO3JVb2wzWNMKED0TaUB8y8sRyK+QJcU=; b=Ce9VhEVAT1JPymUQcdFPQvhi4wBmBty0Ar4vIRTA6Hy+qZiUJU6M6VScczRg6qwGLRL8DQlDa+47eJfXfwhi6sKTLhHEcJ91EnoMOsSdXeNMejaptFLTsIJ+Nfk8KiAJs/dSIsHsRLLlISuU8iHvcqT1P7OIpaYcY4AtW0RstEA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 198.47.23.194) smtp.mailfrom=ti.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=ti.com; Received-SPF: Pass (protection.outlook.com: domain of ti.com designates 198.47.23.194 as permitted sender) receiver=protection.outlook.com; client-ip=198.47.23.194; helo=lewvzet200.ext.ti.com; pr=C From: Beleswar Padhi To: , , , CC: , , , , Subject: [PATCH] xen: Add support to passthrough reserved memory carveouts to DomU Date: Tue, 15 Sep 2026 13:58:24 +0530 Message-ID: <20260915082824.2180692-1-b-padhi@ti.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN7PEPF0000009C:EE_|MN6PR10MB8071:EE_ X-MS-Office365-Filtering-Correlation-Id: 85a927bf-2bdd-4a97-40a8-08df13036b04 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|82310400026|36860700016|1800799024|56012099006|10067099003|18002099003|6133799003|13003099007; X-Microsoft-Antispam-Message-Info: 8tSUQ6pSMm81+WY3WA1NyGNIqwMMljMq5qH8KJ1PJo54ug+a3KD1IEn+0ziBChyP9TDr4zMEDZjrImSDYIjwj9d/wGXnTje8U0BsvqLPiegR7CIjImQ6IDUO41cpLG62pD+FbbmvhOOiK1bPl1oq3vok+a7zSVeLqulsEXSkZv8O+o3IJqzaAYMNY7N9WtdWstXjh1Q2RL+hmnNQzAf9dNkA+EZbbKKGE7Z6wR0T112goBraBqf7mcQHB2E9nd7bM+Gza/4ZTm0QPbHS/UeQkuy/zAOeWy4B8i4yb+TS7MwCVaAhSPCtOuIFe2ZjdG1hgi6rqfb7xDEn97r2Ejyo8R8kxEsFhmO3IGHrplSmgi1DdoVoBJUkMZQRC9KF4RliCq4s9jRO+/AOJve/35r6w3IFnqZTmJVHEs8otgF2AilvZgrXALXq+FDBFduYKdwXRcd2sm7q5h3vY8IycqpYcg8f1rIz5Cye9c5gUHYx4o+0ls6Dx/Nkg0hQcL2ZYGmBtYtNNdGe3Hx/9UhD+rCIvmn+iewje0BQ4+N2qP05lZP/SZkXtCYCoPU8dw/uMUqAn0nsFjgMCTeplnLRP9lHhAVoH2QOMZZwTuu0u7be2bdCI/oCbDg3fkWpSFvlCA7Dce3hIUjhkN2me5uZ8wckRPlHMgCt/TAJKJVc5SjGo/tpcLprgEL6iZXy6+xVZBXSONMV2HTqeW1OCad8Afjk4g== X-Forefront-Antispam-Report: CIP:198.47.23.194;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:lewvzet200.ext.ti.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(23010399003)(82310400026)(36860700016)(1800799024)(56012099006)(10067099003)(18002099003)(6133799003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: b4+xwjn4aKLMlXNReDPRYzyU8hKSn1ZARrn0buUS8x4CF9C2DIZJ/nd6fZO6Pj1xQ2Cw+bQn8iNSeVzjWBZX3u9Lqz/0l9GzEjnYXDo0/DOXY1/Hnr6aPuTa1Zcxs/ewJprrOBcV7EEUK5Zh8LWRUdL0n9OlJm0AQABzfGtEzPScWOtflROWCjwKfSy4ytWzjR3gweHawXaOeYfsg9ljjnefnnNWktJWUR31iPo43yPUF85zM45TrBppeaH2HuKd+KPe5N7Og9EeFbhMW1F952W26rr9Um1W9C6mWHPfL7PRsQGaMyLZtEenKaUpft8v2atzQC0K+x/BjDAWMGL9+e+LDA1T/Omy+YgfQpg6Ce6Qbp9K+OpHWhStpRxEEUYncNDJQ1Mf8D2310P8dnQD9aX9VKNJ2+8/QhDyjY1s8Gs6nNl1zHktfKtcAW3CigCy X-Exchange-RoutingPolicyChecked: A2mYEUgxikh5m95fi8LKAJ06PcqSQV2Pd/EuQsIxsj7xZc1ydJLhLRzXIHYpXk4qm07vU2lUnNWJKmNDT5Z8tN9xoL0UB1Bhf2ftP85F9sizK3rSbygB9xRvVjQxa/zKBKD1F+JPErC24ehaDkG5XXkp/yZsFxI+1T0nrrouAWOHaW3NgFJGw4Ru3X3Kr9BTa6E4bp8B6jhckHSfHNKbfhnvzCnIFphk23ZD2HjLi4Rqkx4WNLus+a4FK0IoH0cTl9uWUPWmWMlD8QSsEIc3TAIMweVtSgEF0WMgRLbwyMuHYPR10gPuQP22QoZA1HxVOVWz9OlWI69X2PViwYa6kQ== X-OriginatorOrg: ti.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2026 08:29:10.9706 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 85a927bf-2bdd-4a97-40a8-08df13036b04 X-MS-Exchange-CrossTenant-Id: e5b49634-450b-4709-8abb-1e2b19b982b7 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=e5b49634-450b-4709-8abb-1e2b19b982b7;Ip=[198.47.23.194];Helo=[lewvzet200.ext.ti.com] X-MS-Exchange-CrossTenant-AuthSource: BN7PEPF0000009C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR10MB8071 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE1MDEyMCBTYWx0ZWRfX7te6AOBd4xAn JCfyEFrBEev11PJJDECECcQQ41c/GMAFeuhoq+DQqNXktZpbdeFbYTV9IpqvfniCWnEQtv38Jqf h6gUCjmfmuCq/coslPYP7Ak0epVzD6I= X-Authority-Analysis: v=2.4 cv=KvnYSmWN c=1 sm=1 tr=0 ts=6aa901db cx=c_pps a=n8CZQ1v8Y1OZ9xNCwzzv5Q==:117 a=WotqVVQAdb04rnGuttW3Kw==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=VdqzKS8jKosA:10 a=s63m1ICgrNkA:10 a=V5UXEbMT0ywA:10 a=VkNPw1HP01LnGYTKEx00:22 a=Z8NIEmU8O1QQgoT56wFK:22 a=fPAWb5peG099m5CrUpKH:22 a=VwQbUJbxAAAA:8 a=sozttTNsAAAA:8 a=NEAV23lmAAAA:8 a=Z-IV5SkFREQAX4yTDDYA:9 X-Proofpoint-ORIG-GUID: WPGqndh5NNxe2JjTyaNwCjtWyc_vGG9Y X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE1MDEyMCBTYWx0ZWRfX6bwrl8+oQx95 6uDagvdgxl9sjA+YEP3At+v9TkWGkJiDGJEZ+Iot77uaZMqRaWGMxsm1kod4agaB5POuKv+uvea cammmfk7V6awkEXN76ZNa5KgDvF1szp7jyDkZOfLWdcucGJShs9i+4Zfy7kOSJNlPlNiCyB5ZcL iZNZ7xX0Qo18imMH/LRYGF5Thrj+g2Sw4Td+ypyVKWU70C1G21FtBJkzs7GqwIdLGQF0grPgT8y AeyrEPL2O0QxtPaaz2zUIFxxv7BP7NYfpLdYjYZ8ojjf/abqu8qVI0WARJZXZuAmNDN5lqAMTc2 MmDxzc8jBzjyQAWCX63bXIJSUkqfby2ch2T1LF7Mrj5lTC+afCKLf6h1RI8PoqqoH9dImffrzgY dAnKQdcaGyFl+6miquB8txGLd48ajYf06gGOn30RPuZllgVMi9fCYvwm/J9oK0f/upDIb+iCVT0 cycZPJqHa8vEQn0+LDw== X-Proofpoint-GUID: WPGqndh5NNxe2JjTyaNwCjtWyc_vGG9Y X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_02,2026-09-14_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1011 priorityscore=1501 impostorscore=0 suspectscore=0 spamscore=0 bulkscore=0 adultscore=0 phishscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609150120 X-purgate-ID: tlsNG-4011c0/1789460966-58BC8CFC-E724A13C/0/0 X-purgate-type: clean X-purgate-size: 5681 Currently Xen only looks for /passthrough and /aliases nodes. Add support to parse the /reserved-memory node and pass it through as requested to DomUs. This is useful to enable many usecases in DomUs like Remoteproc firmware carveouts, CMA carveouts etc. If Xen's static shared memory carveout is found, it is placed as child nodes under the top level /reserved-memory node as also done in commit 51a2b3f10918 ("xen/arm: fix duplicate /reserved-memory node in Dom0"). Signed-off-by: Beleswar Padhi --- Hello all, Sending this patch as discussed in: https://lore.kernel.org/all/0e556bb5-269d-47d7-9ae8-68f06eee9fc0@ti.com/ Test Configurations & Logs: https://gist.github.com/3V3RYONE/bef3bb51459f8b823605261b35494a7e Thanks, Beleswar xen/common/device-tree/dom0less-build.c | 45 +++++++++++++++++++------ 1 file changed, 34 insertions(+), 11 deletions(-) diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index fcbeb8adbd..e9581327ee 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -334,7 +334,7 @@ static int __init handle_prop_pfdt(struct kernel_info *kinfo, static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, int nodeoff, uint32_t address_cells, uint32_t size_cells, - bool scan_passthrough_prop) + bool scan_passthrough_prop, bool resv_mem_node) { int rc = 0; void *fdt = kinfo->fdt; @@ -358,13 +358,20 @@ static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, while ( node_next > 0 ) { rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, - scan_passthrough_prop); + scan_passthrough_prop, false); if ( rc ) return rc; node_next = fdt_next_subnode(pfdt, node_next); } + if ( resv_mem_node ) + { + rc = make_shm_resv_memory_node(kinfo, address_cells, size_cells); + if ( rc ) + return rc; + } + return fdt_end_node(fdt); } @@ -389,7 +396,8 @@ static int __init check_partial_fdt(void *pfdt, size_t size) } static int __init domain_handle_dtb_boot_module(struct domain *d, - struct kernel_info *kinfo) + struct kernel_info *kinfo, + bool *found_reserved_mem_node) { void *pfdt; int res, node_next; @@ -430,8 +438,8 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, continue; /* - * Only scan /$(interrupt_controller) /aliases /passthrough, - * ignore the rest. + * Only scan /$(interrupt_controller) /aliases /passthrough + * /reserved-memory, ignore the rest. * They don't have to be parsed in order. * * Take the interrupt controller phandle value from the special @@ -445,7 +453,7 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, res = scan_pfdt_node(kinfo, pfdt, node_next, DT_ROOT_NODE_ADDR_CELLS_DEFAULT, DT_ROOT_NODE_SIZE_CELLS_DEFAULT, - false); + false, false); if ( res ) goto out; continue; @@ -455,11 +463,22 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, res = scan_pfdt_node(kinfo, pfdt, node_next, DT_ROOT_NODE_ADDR_CELLS_DEFAULT, DT_ROOT_NODE_SIZE_CELLS_DEFAULT, - true); + true, false); if ( res ) goto out; continue; } + if ( dt_node_cmp(name, "reserved-memory") == 0 ) + { + res = scan_pfdt_node(kinfo, pfdt, node_next, + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, + false, true); + if ( res ) + goto out; + *found_reserved_mem_node = true; + continue; + } } out: @@ -486,6 +505,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) { int addrcells, sizecells; int ret, fdt_size = DOMU_DTB_SIZE; + bool found_reserved_mem_node = false; BUILD_BUG_ON(DOMU_DTB_SIZE > SZ_2M); @@ -538,7 +558,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) */ if ( kinfo->dtb ) { - ret = domain_handle_dtb_boot_module(d, kinfo); + ret = domain_handle_dtb_boot_module(d, kinfo, &found_reserved_mem_node); if ( ret ) goto err; } @@ -556,9 +576,12 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) if ( ret ) goto err; - ret = make_resv_memory_node(kinfo, addrcells, sizecells); - if ( ret ) - goto err; + if ( !found_reserved_mem_node ) + { + ret = make_resv_memory_node(kinfo, addrcells, sizecells); + if ( ret ) + goto err; + } ret = make_intc_domU_node(kinfo); if ( ret ) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 08:43:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 08:43:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421531.1647330 (Exim 4.92) (envelope-from ) id 1x6OlV-0001xu-IS; Tue, 15 Sep 2026 08:43:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421531.1647330; Tue, 15 Sep 2026 08:43:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6OlV-0001xn-F1; Tue, 15 Sep 2026 08:43:45 +0000 Received: by outflank-mailman (input) for mailman id 1421531; Tue, 15 Sep 2026 08:43:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6OlU-0001xh-2p for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 08:43:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6OlS-00BQwV-MU for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 10:43:42 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa90535-8faa-0a2a0a5109dd-0a2a450bd286-40 for ; Tue, 15 Sep 2026 10:43:42 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9053e-b7e8-0a2a450b0019-4a7de18c9bde-3 for ; Tue, 15 Sep 2026 10:43:42 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso27918485e9.3 for ; Tue, 15 Sep 2026 01:43:42 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e7ef24be2sm30342585e9.0.2026.09.15.01.43.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 01:43:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789461822; x=1790066622; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=wn/lyeTbbPBDsoxu3rQlBRh1hn3vc28DqPKEKt99NCc=; b=cLZ1/oxtvB5c8AAMWRFeVIFWMKniREzNFe5Jgp/GISC+m3rFDLOsGQGSVJ6OoYel2K Ph/lIZo+GYkIhUt07jW4baHRga6sIcovszvq0opSIIOAJEeT0Q/bfj1lE1wJCVTGrm0w oLeMT4onH89E5y/rdGLZRHumsM+3OKBEp4Eq/OMIsX9Ycspdf/1KFpNc4D9M9oeiimvI YiZ6M0fM1VXN2w+f1ydchwqJp85B9JFPK7IdnWa93pG/59t1QgTDT/mqty3COcawfPPw HgYH+0xWlq4a2DZsxPEcyM0lsSvVrEQ33pw6+qfHmljUBiG7augE+8hsHOG6OUbQkRwo Wg6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789461822; x=1790066622; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wn/lyeTbbPBDsoxu3rQlBRh1hn3vc28DqPKEKt99NCc=; b=EaSP7pG4YUu/qXeocyWVvOrDatsX8rvyFCdm95B6Hs6BaEaZEXpJVrDEg901kdrAPG +OMgnJrl00ZZAjO2tt8cZsQaUpewrrSXMWzcM8IMZQFUEFIg/AU8txGCaacfC3KzH99W XbzygWJl7CITd8Kd81spCSPwaIfKx/vR4NMBJ2NFjFfU0MyExtvXj5ROz19kESNn7wVQ i0eQssNioF6dTjO/UYz1FwST1VM7T/pKxiiuaP7qm0/kXgpejYs69G3+DQKDVNNPutVY QiDAv/JNDxSp0dJ/BzRLan7KPPwqQYhtSYo8SOQ0FiIrKWYch5RK74yP7pbBrtRyi0aZ Xlrw== X-Forwarded-Encrypted: i=1; AKwUvBwbF9X5ZmazQaYRh9Zbbszt3MPuOUmMbI1v2hkO+nj5yjf6rjD+PZkVQSqwdFJUbHPaTV5NcpFb2jU=@lists.xenproject.org X-Gm-Message-State: AFuF++mMlf59VEffwhAnX3cWqqMyXLhpravtTyPp1QqIj4sUMlsfg9+W OO6nHxkKjK7CMyQdRmokpdqEfutF1R2+ac1Ccq3Jm3w5VBnOFUQRrNmA X-Gm-Gg: AYBFou0eNsUPV+E0JkrOS1ydsyXDZuuH/raf0JEAK+rJWmN6s91EUg4l/+Ux40sXzIT 1C/CVrh+i3ch7UqHR4BrUNlArGGExbLCn5vZEonGF5ctC8wMA37bXGeeGr9GKlafrAEETOMwMHA nfz0PsWJdHFZNsyOKtg3XsImFKdKil+OtIGdlB8PGp10B3V4OMTfcoXy7mK6sixe2XqJQpLMl7x tJ04QJt5FcP+OiCguTA6ntZys+mxJdTg4lYksqG5Wp8MPQTr9KlAmzd8KchKN+u8hlCRHANT0kT HiHjrsefU0qaaLQYBQNfa8RNmZE8NDB2hi35IJEIo7FiHDFhy/2ky44D4up3dOpbT4NblITKrP4 2BjzgWBKrTEgIhyVrolkZn7W+TVwmVsEreNJv9Ib7OlAda2FiW4YhGHL/ZMm61TNha88J5rU37X 9dIcS+kYZAZGYb6tO6rpdSWFsloYE6Zq3ZmptVgW+zIIgJ8TGGxypq1FO2Vo0bi87vFWQMvhymz sk8JC3cCu8PRLHkADDDkEK4stE5kSkCGv+o X-Received: by 2002:a05:600c:3593:b0:49c:e3ad:41d3 with SMTP id 5b1f17b1804b1-49e7a5edc17mr72558105e9.0.1789461821804; Tue, 15 Sep 2026 01:43:41 -0700 (PDT) Date: Tue, 15 Sep 2026 09:43:39 +0100 From: David Laight To: Borislav Petkov Cc: Mauricio Faria de Oliveira , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() Message-ID: <20260915094339.39a83b54@pumpkin> In-Reply-To: <20260915051155.GGaqjTm7yIluwxZ80x@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> <6113f06c790cfe1141d2dc09b68937b6@igalia.com> <20260915051155.GGaqjTm7yIluwxZ80x@fat_crate.local> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789461822-A90CD9EA-CE4605F9/0/0 X-purgate-type: clean X-purgate-size: 773 On Mon, 14 Sep 2026 22:11:55 -0700 Borislav Petkov wrote: > On Mon, Sep 14, 2026 at 08:22:08AM -0300, Mauricio Faria de Oliveira wrote: > > In the review of the original patchset (fixed by this series) it is > > mentioned that a compiler might turn it into a memcmp() [1] -- and thus > > revert back to the same issue. > > > > [1] https://lore.kernel.org/all/877ccz12ab.ffs@tglx/ > > Hmm, never heard that before but that doesn't mean anything. Probably should > mention it in one of the commit messages so that we know for the future... > It definitely has a habit of converting copy loops to memcpy(). Annoying when they are short. But usually easily avoidable by sprinkling 'volatile' or barrier() in the right places. David From xen-devel-bounces@lists.xenproject.org Tue Sep 15 09:07:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 09:07:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421544.1647339 (Exim 4.92) (envelope-from ) id 1x6P7v-0004vD-AA; Tue, 15 Sep 2026 09:06:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421544.1647339; Tue, 15 Sep 2026 09:06:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6P7v-0004v6-6Y; Tue, 15 Sep 2026 09:06:55 +0000 Received: by outflank-mailman (input) for mailman id 1421544; Tue, 15 Sep 2026 09:06:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6P7t-0004v0-1J for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 09:06:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6P7s-006NKI-9O for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 11:06:52 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa90aaa-8faa-0a2a0a5109dd-0a2a450bbe3c-14 for ; Tue, 15 Sep 2026 11:06:52 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa90aab-b7e8-0a2a450b0019-b9ff1c12869f-3 for ; Tue, 15 Sep 2026 11:06:51 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0a4519d3d000c4f3.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 15 Sep 2026 09:06:47 +0000 Received: from leducb-2.local (155.89.66.37.rev.sfr.net [37.66.89.155]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id E487C80F92; Tue, 15 Sep 2026 11:06:45 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=TWb1Pi/xe8T33qSa6iB7iWKAUcrFfU+7ZlQtCxdnF1Q=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:feedback-id; b=RfVQcWw6JIB4IIVYWziz22xR8n/TUszX7DYNA+clVIQCg33AujPyHc3u0TFM0FrAb6B+Udohc G3cVrzRiq8GjW9Ha0woDyWKzJUNZIkh5pJcH7SVNCAyFhNk4ZQFJ9OYJv5dW4chmgcyhDNnHYmm RQruSW097jaPjlVWsf7MMqdniF7DclsuwGa501S0TU+Pr48qcLX5JZgvObMKAS7G5vS4gBEvfzA qbrP/w7Jua4+2u3TQEHS2RNJvLITjzfCZWjva9prz3F3OWu4GGONmVchr2wzeV9mBgG/UnCjD1Z Z/FYjgYkR6TeyS4Lz5TIwBYq5SqAmfFSuKzzuxKaljRQ== X-Zone-Loop: 897cb62e1b3c49f16ccc13e6743e829971b0c7f4d9b9 x-campaign-type: default x-transaction-id: faed4c69-370c-4449-862c-d13c819a5d1b x-swg-uid: 01-f8a9a391-a777-4d8e-8442-97fd406cce11 X-Mailer: Sweego Message-ID: <1789463207.8631fc262581453bbf619ec5b2062170.1a0a4519d3d000c4f3@vates.tech> x-swg-bid: 1789463207.8631fc262581453bbf619ec5b2062170.1a0a4519d3d000c4f3 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Baptiste Le Duc Date: Tue, 15 Sep 2026 11:06:43 +0200 Subject: [PATCH v2] Add basic b4 config file MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAAAAAAAC/3WOuw7DIAxFfyViLm0gD4lO/Y8qgwFD6EAiIKhVl H8vpHPHc22f651EDA4juTc7CZhddIsvwC8NUTN4i9TpwoS3fGwFYxS0prKnavHGWSpQGjDDAB3 vSLlZAxr3Pn3P6cdxky9UqUrqhoSIVAbwaq7Rtt5iAuu8rcPZxbSEz/lNZlXyrzgzyqiAHhTTX A+jeGRIGK8Ji3c6juMLtDgo/9oAAAA= X-Change-ID: 20260911-add-b4-config-9ebfaf55a323 To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc X-Developer-Signature: v=1; a=ed25519-sha256; t=1789463204; l=1641; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=bXamDHTWjbeAwiLKmMPva03Iv8OiLO5TKjT+IaM4des=; b=YwsRKZwxfLe+ZQ30vdJe5F2CJyFbUPZBYRsOwihRpKeE+nB5xAjBcllyKjUICtiZ4tJN4xkFk hz1sUlup7xkAoG3WJTZZS/O3ftDO4t7KIcdJgLZinC9eqf9ZXoiuPhR X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789463206667 X-purgate-ID: tlsNG-42698a/1789463212-188C99EA-D6831E0E/0/0 X-purgate-type: clean X-purgate-size: 1643 b4[1] is a convenient tool for mail-based contribution. A config file[2] tracked in the tree lets the project ship a few defaults that match the Xen patch submission rules. This aims to help new contributors who have never used a mailing list avoid mistakes when sending their patch series. The tree has no scripts/checkpatch.pl or equivalent, so there is nothing for b4 to run per patch. Disable the needs-checking pre-flight check so a series can be sent without first running b4 prep --check. [1] https://pypi.org/project/b4/ [2] https://b4.docs.kernel.org/en/latest/config.html Signed-off-by: Baptiste Le Duc --- Changes in v2: - Drop Xen's patches submission rules from comment - Drop flags that are not supported by get_maintainer.pl script, --nogit is supported but is a default so drop it also. - Link to v1: https://patch.msgid.link/20260911-add-b4-config-v1-1-9a4ac1d2d569@vates.tech --- .b4-config | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.b4-config b/.b4-config new file mode 100644 index 0000000000..e5e2435ec4 --- /dev/null +++ b/.b4-config @@ -0,0 +1,10 @@ +# +# Common b4 settings for sending patches to the Xen Project upstream. +# https://b4.docs.kernel.org/ +# + +[b4] + send-series-to = xen-devel@lists.xenproject.org + send-auto-to-cmd = echo + send-auto-cc-cmd = ./scripts/get_maintainer.pl + midmask = https://lore.kernel.org/xen-devel/%s --- base-commit: acd87f99ac65ff9426dd52f9b7a6ef9db45cc735 change-id: 20260911-add-b4-config-9ebfaf55a323 Best regards, -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Sep 15 09:38:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 09:38:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421566.1647347 (Exim 4.92) (envelope-from ) id 1x6Pcc-0000zJ-P9; Tue, 15 Sep 2026 09:38:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421566.1647347; Tue, 15 Sep 2026 09:38:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Pcc-0000zC-Lr; Tue, 15 Sep 2026 09:38:38 +0000 Received: by outflank-mailman (input) for mailman id 1421566; Tue, 15 Sep 2026 09:38:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Pcb-0000z6-G8 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 09:38:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Pca-001xBC-Cm for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 11:38:36 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9121b-2eae-0a2a0a5409dd-0a2a4503af86-4 for ; Tue, 15 Sep 2026 11:38:36 +0200 Received: from [40.93.195.13] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9121a-fae8-0a2a45030019-285dc30de614-3 for ; Tue, 15 Sep 2026 11:38:35 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB4989.namprd03.prod.outlook.com (2603:10b6:208:1a5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Tue, 15 Sep 2026 09:38:32 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Tue, 15 Sep 2026 09:38:31 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cOGkhIeUGNt6T4TzMF3zosPT9Ss1LmMfK0+BuGoHSW8cKR0BTnkQyT2vcO1Zx6jiR4dLzz8GJkcHQk1nnkflFflIYB8lZCWzaLTeUM2x7Y0/4Abj7HY19J2gKZkZY9KM+lknVH1p7o+sZC3SkuCzn+SkfHhLUXLEJZ4x93wRNzW/kFDvsxzMakBTkpWSfyEFkFx10dzIHarTOvtfy4y1r2wShRVh/ZJNRvJA3GJmRcLnJ9rgQcXSfNkzpox6jvoVzreZl0gEIFafK6hVzPwAOzb9JnwBYDsdfAvhzkJTAAHRh3e7Iyp/ktJolHCxUVQATmxFewB3gGTB1RX6tvmlJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Oifu2j0T/ryYwRsVAwvUc9UCZV78mWd5/uiBJmInh1U=; b=AuL7XMZ6Pobw0LXOzujT1bikBulk0XtgNYMNGHERsI57oA7s30/vkAxYziYel+H9KKwRvRBqesyPsG9/1z8mJZ6ufGEVx2KoL4NXVUZY/5m3JRa3tJCQClWWqq0Xjpq2fYVPtsJzwStG/kh55FiII/6jIQ4VxwzzqGr7F6d7hxyLyzXc0iJXigOOJgwXv/ek+6AtBW4EpIelDwDv6gKR+C5tm/AGlf8w3lO65JyBekUVjYxNA6Ku1+zes9YN71Ru2s1gYVzPkM7L337t7UWTVrGF6raO1kfHq5+twEYc1Lg870K6I2Km4dJXxxBdS/VY9+mCKapRsWyQ8uh0ENgvsw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oifu2j0T/ryYwRsVAwvUc9UCZV78mWd5/uiBJmInh1U=; b=q2FoBlG6ecrTTU4z48+66OU+rMH/adg5S3yEtdGFek4PBAmrjq9wGEfpBHluNNBJbQOd6TPi6WhESdm72QEQkROmAIT58Hra+mf29+P/T3Vsp3xG3UvL88VkXW6yeHGAQD8cx9LsrUfOmw55sxx1KLcI7sEW9V58Z8voeSlEa9g= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 15 Sep 2026 11:38:26 +0200 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v2] Add basic b4 config file To: Baptiste Le Duc , xen-devel@lists.xenproject.org References: <1789463207.8631fc262581453bbf619ec5b2062170.1a0a4519d3d000c4f3@vates.tech> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <1789463207.8631fc262581453bbf619ec5b2062170.1a0a4519d3d000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0036.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c7::9) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN2PR03MB4989:EE_ X-MS-Office365-Filtering-Correlation-Id: 8a1fb316-7d7d-4f83-5ee8-08df130d1ae6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|56012099006|5023799004|11063799006|22082099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: nmD8aEyvHqI0um8nOUKTbPoxy1GK2CMeMsR9NErjlq9d32vID0SK1LlyHFAmdQ0TR1Jo2sK5ek3nti1Szqp5yvQyW2zzlReX5KOAiSzR455rWiaYDNSAyD26F+3J9nFbBsawHaJa/Suy55cMSmN1xwcUGPZY95X1On8u9p4QzM7aOvBrKtcdZu/2TVwHFWmjzGZzWTpG14w7aSbOXXda4yeMquviQeMBggevbHPdoX+FxPOVDma6mbhDkf39Sxsn0SLgY7q7LXt7rrRUzoMGhihGWyfML6ISm63qlGDHnQZ7eoRRgvCCrJ8RaRA3W4rKb8ismJ16YKM/Z0Krvln+yydwoQ5ELmlTIHF2jxdSN7EaGrXNulqP3Ru4hOtFH6xIV2rvg2r1ywIPKMQdnlg/1US11+FdsUNDZh68amZ7G9QNkT0NdXbRoQPdx+CCccYBTUNHjADwCKS7vii7uLuZewK/EWfVbbI0dg3si2yvTZKEOD2P3s5Iv4EN/5xpm5n10wPFdsXXyq99G2iIV/DQEcczMFhMkpPKegG0xGpDiHalpGSF0uTsNulRtZEX/ZTs1NF1Nxmf2r2OrLP0AZBNgl6Tl2Y6CFAYxgSI+aqIOJ8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(56012099006)(5023799004)(11063799006)(22082099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QVZvMGxJNFNDbkdyaDRlQTBXLy9tS1hoMGIvS3VTWlNocjNlZ0pzWmpIT3J6?= =?utf-8?B?NzZpc0Nyc3dueE1ZSi9WWE5pTjFVRVVyN0dseWNhSEFzK0Q0SGg0RW0wTjFp?= =?utf-8?B?ODJORklLMXRDL052OUNnN05QTmRoM0ErMGdlZm0rMHZzL0JEbEJ2NVRndG4r?= =?utf-8?B?ald6Uk0zNEdtd0JFVEdMZzgzeXpvQmFlTERyNHd5ejh3aC9ENHFhUlRYYkp2?= =?utf-8?B?Y01NUUlPa1Nzc3JweGhMM0tDQS8wQjNITk4wUkVQOUJHR2VQM3BaeVhvV0do?= =?utf-8?B?cWRCaENORTBxNGJEUGRkOElqaW1UaGRidDRzY0ZVM2FaaEtDTFFLK1lFOUhH?= =?utf-8?B?dTZZMDZXVnpNY09YL1NpVUxzM2ZnRndGQzh3cWVldnRkVEpQU2JNY3UwZlJ6?= =?utf-8?B?ek4wV1Y1WHNnaWRyRDdoeENpUVJDdzMyQnZHRXJCZHJ5ZVg1NXhuejNxbGox?= =?utf-8?B?RmtBb2gwenJ4dkQ2UzJpaVhzUmVqS3RyRnVXUzA0OFUrZDdyb0RVaUF3RzVw?= =?utf-8?B?aThYSDJwY1hYYnBkazdLelB6dzdhNVRTeFllUlh3d3BrcDM5SVZIQ3d4R09h?= =?utf-8?B?VWl5MERKSE5HRzZLaWZ1RWYvdmQyc2xEM1lBOGh3a0U2NFM1QjZXbHU0QlRB?= =?utf-8?B?TVBiZktVaExibjM5TW9QT1JMMThmWWJQNkNaaHpwZU5ITzcwQ1RnQlVCMWQz?= =?utf-8?B?S21qQXllVjc5RkVidnE3elJ4OE9zb1hzUGIzUTgxVGRhbjBrbHRmdFhKUGR4?= =?utf-8?B?RW5vQmFUZkxud0ZhcnUwOHFBR3FuRmZSNXdzRmtjUllJTTFRVlRRTkhHVG8v?= =?utf-8?B?LzhmSmhuam5kTFV4bmE2Mnk0R2NZMXg1MVJFU2crSkRpNklrRElTSk02QUFy?= =?utf-8?B?blBkMDVYSWNiTVJuYzZaN1pKTmhyb0pqYWVuRmRYcUJpYmpBQ2lWbjdKM0JH?= =?utf-8?B?c01wblFwR0NXNXYyZVJjdzVHT2pYNlpCVzVhajIvTTg0eEc1d2hKZFM3WFRK?= =?utf-8?B?Zmo1TnVaVXhYMmVMZ25uVS9oVzFZbmFNeDZoM3VvZ1BlQ2lPblZzZi9IbTlw?= =?utf-8?B?cGQxV1VIRVFPYmZMTm9YZDNhQTVTdzRKRytxeEtoc3NhZnFJQ2ZmellzOERr?= =?utf-8?B?eGR6YkdQTHpvR0hBcVM4Z3hKRnJ2Qzdva0oxQ0Z3NTJDY3dPTHdiNHd1MUtJ?= =?utf-8?B?UHRTblJUUnYvTXRtdVZRcDdvaWdWN3BzNzMvR3J2Z3RheU5CQjZEOTRZQmJ4?= =?utf-8?B?cXVuZzh5dHhWQ3FTS1lUN0swVnRJdkkrbExPRHpoMWFnVGo4OGVhdk4wUE1n?= =?utf-8?B?TkxVV3h5NHZIV09sV3RtOEcxSVYvaTYrc1ZpajZ5UFA1WXlnSmc3MjVaWndm?= =?utf-8?B?b3d0U25mdFFpYkF6T1ZwRUJ3aW9UWVlxaG9tSCsxMVpFWmdHcDVJKzhRT0lh?= =?utf-8?B?eEZVUG9yeG04cEJlLzdZOVBTUUYwS3kwM3ZhMjNnYjYwRjlLODcxNHFUZ21m?= =?utf-8?B?L21aVnQzamRLQmFVanBTYzRORkdnSWJGVmVPU2crQTZsNUtmeDRyQjhzN2hk?= =?utf-8?B?S3FPRW93UHVEaGIyRzdFVmlBUFhBa0I4bG90dUVCRExoQUhTOVZNR1pvSmgv?= =?utf-8?B?SkpoR1RCaUxvK1BKRHByYlJKYVV6eHZGUnhHeFRYRGZTOS80Y0RKbUtDY25K?= =?utf-8?B?Rkpyc0NqK2FWZnlURTZFT2NDcFlGQ2pjNWZyRU42c1NEV0JpRmJLaDE0TUlX?= =?utf-8?B?VkNFTUdhRDF3YWhaTkUzVTY0T29ENnhnNlFxZkNic3VtS3NpRUxPQk0vYnhD?= =?utf-8?B?ZTlTc0JZUm51dWdvY2dOZm9mWVZ6bmVTV2FaU3ZKY3pDWWxvOUNUelR6N3Iw?= =?utf-8?B?cUhQMkE3N3JmcUl5UnFGN3BDLzl4azNHNytwMXVuMVZTbWN0MGZ6L1doSFU5?= =?utf-8?B?U1BWZGNqNUNjNmxPSUdhYnFyQzBnazh2N1BIOHBIaUpSbUNWVlh6d1F0Zy81?= =?utf-8?B?Y2FZc2xLQVZES3dTNW13STZkUTluSGcvT1dOaHRQYWFOdFd6UkZWbERNR3J0?= =?utf-8?B?dWFDamhaN3Jxc3JRUlQ4amlRZTBmYW50TzZXaTN4ditJVHhWMmFZRTlLakh6?= =?utf-8?B?RTVNVlpnVllad0VqRWhCbjZJZXAySHF2aDl2ZnY4QzVmMGU1Y21RQVBKSkVN?= =?utf-8?B?Y015UkgwSTUwVy82OG9MRUVrcDA4VmRYSDViUlNaWjZHUWtrbGhubEhhTGF0?= =?utf-8?B?VTFQNFgvSTV5aVA5UUpETXRDaU9RREc5R0xYQjhvM1Z2WHJyMEZtMVVKdndr?= =?utf-8?B?b3BlT1lobEYwNlJlRzUrYUw2dS9odExHSmFJNTdCMXdxT3FvVk8rdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8a1fb316-7d7d-4f83-5ee8-08df130d1ae6 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2026 09:38:31.8410 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VLzzQ2Qsx8HxxwardX95HnHfWqVnl0HG/sihhjG5MVaH034jdwusPn6VeG9Fb2zkxhyrjy8DcytHJKs6IrNNYDka7S9NRjtIhGR5EbjgPAE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB4989 X-purgate-ID: tlsNG-33051d/1789465116-77AC44E9-F13AC87C/0/0 X-purgate-type: clean X-purgate-size: 790 On 15/09/2026 10:06 am, Baptiste Le Duc wrote: > b4[1] is a convenient tool for mail-based contribution. A config file[2] > tracked in the tree lets the project ship a few defaults that match the Xen > patch submission rules. > > This aims to help new contributors who have never used a mailing list avoid > mistakes when sending their patch series. > > The tree has no scripts/checkpatch.pl or equivalent, so there is nothing > for b4 to run per patch. Disable the needs-checking pre-flight check so a > series can be sent without first running b4 prep --check. > > [1] https://pypi.org/project/b4/ > [2] https://b4.docs.kernel.org/en/latest/config.html > > Signed-off-by: Baptiste Le Duc Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Sep 15 09:59:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 09:59:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421587.1647363 (Exim 4.92) (envelope-from ) id 1x6PwQ-0003sX-CL; Tue, 15 Sep 2026 09:59:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421587.1647363; Tue, 15 Sep 2026 09:59:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6PwQ-0003sQ-9R; Tue, 15 Sep 2026 09:59:06 +0000 Received: by outflank-mailman (input) for mailman id 1421587; Tue, 15 Sep 2026 09:59:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6PwO-0003sD-Sg for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 09:59:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6PwN-00GA70-9Q for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 11:59:03 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa916e0-e002-0a2a0a5209dd-0a2a45089b1e-20 for ; Tue, 15 Sep 2026 11:59:02 +0200 Received: from [52.101.46.31] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa916e4-f659-0a2a45080019-34652e1f5631-3 for ; Tue, 15 Sep 2026 11:59:02 +0200 Received: from BN0PR02CA0046.namprd02.prod.outlook.com (2603:10b6:408:e5::21) by MN0PR12MB6055.namprd12.prod.outlook.com (2603:10b6:208:3cd::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Tue, 15 Sep 2026 09:58:57 +0000 Received: from BN2PEPF0000A895.namprd04.prod.outlook.com (2603:10b6:408:e5:cafe::88) by BN0PR02CA0046.outlook.office365.com (2603:10b6:408:e5::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.9 via Frontend Transport; Tue, 15 Sep 2026 09:58:57 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF0000A895.mail.protection.outlook.com (10.167.248.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Tue, 15 Sep 2026 09:58:57 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 15 Sep 2026 04:58:56 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 15 Sep 2026 04:58:55 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=E8S5vOr8cHMiuAULtSVo0sFWZdMD/yKZcBtdrazuFptTpkPsaS1vyisi6Bjbz3ivxVAcjhavFyyAYpK5Cuyj2ojAzNizjHbOf44hdqEw2jAixPFMdH32kcQIzLAyxjnggOzUZY3N9BsOFCBQ+sTpHorNr6b7DXC+LPv06tzuZj9mzA9B6hpYxebDo3Y8oiLz1/aGeAxnT67RBB/zvjYxLCF6ofSENRlt6qV823SHBts7R2R3NKsp7xuL/ykbK6mJ2uTGc35qCTLzPMiEHPNubkUUqUEIOXGD7ltoHy8jw2pUgaGBibeaZ8ULrzr7GgZ4SSqrd0cYYiijIR9cuVeDug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KywGxKMrh44b9K61tCSeBZhvRqdD6BlG94XY3KfEqaA=; b=kzfo8Ki+AKbJbGqhkzDtQTzuNCueEQLcUd5TjuaXXR7KHIzcaqmnSj+Y3prE+RRi7LG3u/iY//DYVn2O7lFacwoIat110cOh/jzFsNpFEAw0RMK8qxGNC1f6l9RcCBhuuNIa4JSmn+bAp8lg1c5D2bELp5e+HCqRUmaYrOXhGKQIGfA6orea/bzKEu5UqoPo+3ocelkIH3DeaXBjZsxaH6SbezNK1CjihzT9dRh5aLXd9ES3JmflpzMjiPyxhrVpY9PfgTZKBCBGj4ry79Tw5i/aeLrQV2zi2Ddw//SSNDymT0+daHyBSMJnbjmKWNj39LCxVhBnmPylD49foFI4gQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=ti.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KywGxKMrh44b9K61tCSeBZhvRqdD6BlG94XY3KfEqaA=; b=EOoURSt2FLbw1CHMKFmRHzEJLjYcKKmqAJvZmTf4oRbSiyWt0JHk5UeZNXe6NorYrH0zmkxO+Uf7XTL+H6O7oN0HazLlQaVXDc3dH36ATQEd8xxDNwrHyJv94xXHeB9c1Jf2KtugtOmHd2km+PAHDI2Ou9tER7bMS7HRKuwSyAw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Tue, 15 Sep 2026 11:58:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Add support to passthrough reserved memory carveouts to DomU To: Beleswar Padhi , , , CC: , , , References: <20260915082824.2180692-1-b-padhi@ti.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260915082824.2180692-1-b-padhi@ti.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF0000A895:EE_|MN0PR12MB6055:EE_ X-MS-Office365-Filtering-Correlation-Id: 569f70ff-5e98-41ce-82f7-08df130ff559 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|376014|23010399003|82310400026|10067099003|22082099003|11063799006|56012099006|18002099003|6133799003|13003099007; X-Microsoft-Antispam-Message-Info: 6yZKmSayIT6bLcor3Dhi6U6M0Ng3ocUT2QMasuS7JFrCESOeaykA17ETt+rOkvI5LCoUYcH8/oqXNHE/zkK/GAZNBR6Z1bQUjuE4ufcqSHDYZLPVxVWD0AqSBnIRSx9yqdzYY2xhcRGaSOiykqXQXHGWr4KVJ53U/wCFUd94S8sFBBW+xa7yJnT5LfT1QSeIvDMMKRJ3H2J9lDCFtOxiY5MxIxryul0TnMGJM9Hq6eElZUVz4NiWv2IvH6BxwnDgnQm5cVnVcPY1gYBgmB446zsbonGTZxOBQmVfL9OF/v8vTyc2ycEDEG9cOiRX21PMIAlh0JzFV27YhwCJ+nN7AjSdAWMifXqy04nCSA5QDjCdcrGLpPvEUWo5RCRtlVyMV8hwmspV4sPP3dnDMUIh/yZLTi5/v9Z5/BUAgf8+hixu/JL6M35wCvGXAeHOr2mHj5qq4wVWhT7PNmx5XukJnj1xkwga8BRcewMjO74VUpl2ANTlaTRz5LqVMkQTLZuHj26CwLJ99AieeJOtXuTzL3/YU64mxBNkncoeAVrt8L+jiLXLNaNI+xpmcCyb8vT+uxa8qla64fnOK5N9btDLvJQuqv93kb2Fg6rUNg5cYlgnOzs6q9U5gCth5JEvW3RMaQFzeEVMGtZ6L9cS+Nkozw5wFE2YQ/OIeIdOz9L62phmwEhG5WW0qnQom3yj4AjCCWN40T+3Wlq5FF3PfWPjrA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(376014)(23010399003)(82310400026)(10067099003)(22082099003)(11063799006)(56012099006)(18002099003)(6133799003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Jv65bECHlpovCzGvZEXD2+0iYGsSfQZ4pOXp58dOE7MxdESB1zG28Ho4kcXyOJ58a8XRIZR6wpgFepKRCGXNzaDcpkDZP1TFp39lp+PM4b26vjKzFyPAmFSUhnt0LvYkd90QCVkQ1pWJ2fKvWAKRXVTSQmWK4qB/Bb79/gwtejsZFIHKpvW9UaHYxhBDxtlxih6E+1OkaGjaWZ5sA6yYDyHCxN1U/BqCj9kdJgR8pKWp89eeF5jR9ChaZcuVRO8QG/JAMKRRJxS1l7zuafl+UrAQKgAq0LZt7qbwn+Ai6WnOXhN6qv1tCdA/4vof+m+s4HDEJRC02rGn4UxwxJ32PmxjU6tZkBjZxOlY9HRO3GoApYxW//9ezXDIjmpaFAQpVpEMIwkHYAkaiBS3u5CE+wv15shA5g7xShe18H0HVX6polNfhpynTnnjSSo3eS2e X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2026 09:58:57.1199 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 569f70ff-5e98-41ce-82f7-08df130ff559 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF0000A895.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6055 X-purgate-ID: tlsNG-c1860d/1789466342-D554C87B-ECCCA531/0/0 X-purgate-type: clean X-purgate-size: 7901 Hi, On 15-Sep-26 10:28, Beleswar Padhi wrote: > Currently Xen only looks for /passthrough and /aliases nodes. Add > support to parse the /reserved-memory node and pass it through as > requested to DomUs. This is useful to enable many usecases in DomUs > like Remoteproc firmware carveouts, CMA carveouts etc. > > If Xen's static shared memory carveout is found, it is placed as child > nodes under the top level /reserved-memory node as also done in commit > 51a2b3f10918 ("xen/arm: fix duplicate /reserved-memory node in Dom0"). > > Signed-off-by: Beleswar Padhi I'm afraid adding support for passthroughing /reserved-memory nodes like this patch does is unfortunately not enough to help with the common use cases these days. /reserved-memory nodes got complex from Xen PoV mainly because of the "reusable" property that lets OS (say Linux) use such memory for whatever it wants until device asks for it. The common use case is "shared-dma-pool" and CMA buffers. They specify "reusable" (hence no "no-map"). This causes a few issues: 1) Xen maps memory for passthroughed regions for domUs as device memory (keep in mind the rules from Arm ARM for joining stage 1 and stage 2 memory attributes - device type is the most stringent one and wins) but for shared memory it should be normal memory. 2) Linux can use such reserved memory region as normal RAM and hence use it for Xen shared buffers (e.g. hypercall buffers, shared memory, etc.). As per arch-arm.h any memory shared between guest and Xen needs to be of normal type. 3) Xen does not give reserved memory to the allocators and does not have backing page_info structs for such pages. If such memory ends up being used with Xen (e.g. to map foreign pages) such access will fail because Xen will not be able to get pages for such region. Problem 3) exists today also for hwdom. Problems 1) and 2) are gone because Xen maps memory of passthroughed nodes for hwdom in a more relaxed way so guest attributes win. This is high on my TODO list because there is a real need from customers to add a proper support but I don't have any bandwidth this year to do any work. I guess your solution would only work for the simplest use case which is for /reserved-memory nodes with only "no-map" property present. We could limit the support for only such nodes (check if it contains "reusable" property and if so, bail out) as a temporary solution if this helps. ~Michal > --- > Hello all, > > Sending this patch as discussed in: > https://lore.kernel.org/all/0e556bb5-269d-47d7-9ae8-68f06eee9fc0@ti.com/ > > Test Configurations & Logs: > https://gist.github.com/3V3RYONE/bef3bb51459f8b823605261b35494a7e > > Thanks, > Beleswar > > xen/common/device-tree/dom0less-build.c | 45 +++++++++++++++++++------ > 1 file changed, 34 insertions(+), 11 deletions(-) > > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index fcbeb8adbd..e9581327ee 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -334,7 +334,7 @@ static int __init handle_prop_pfdt(struct kernel_info *kinfo, > static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, > int nodeoff, > uint32_t address_cells, uint32_t size_cells, > - bool scan_passthrough_prop) > + bool scan_passthrough_prop, bool resv_mem_node) > { > int rc = 0; > void *fdt = kinfo->fdt; > @@ -358,13 +358,20 @@ static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, > while ( node_next > 0 ) > { > rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, > - scan_passthrough_prop); > + scan_passthrough_prop, false); > if ( rc ) > return rc; > > node_next = fdt_next_subnode(pfdt, node_next); > } > > + if ( resv_mem_node ) > + { > + rc = make_shm_resv_memory_node(kinfo, address_cells, size_cells); > + if ( rc ) > + return rc; > + } > + > return fdt_end_node(fdt); > } > > @@ -389,7 +396,8 @@ static int __init check_partial_fdt(void *pfdt, size_t size) > } > > static int __init domain_handle_dtb_boot_module(struct domain *d, > - struct kernel_info *kinfo) > + struct kernel_info *kinfo, > + bool *found_reserved_mem_node) > { > void *pfdt; > int res, node_next; > @@ -430,8 +438,8 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, > continue; > > /* > - * Only scan /$(interrupt_controller) /aliases /passthrough, > - * ignore the rest. > + * Only scan /$(interrupt_controller) /aliases /passthrough > + * /reserved-memory, ignore the rest. > * They don't have to be parsed in order. > * > * Take the interrupt controller phandle value from the special > @@ -445,7 +453,7 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, > res = scan_pfdt_node(kinfo, pfdt, node_next, > DT_ROOT_NODE_ADDR_CELLS_DEFAULT, > DT_ROOT_NODE_SIZE_CELLS_DEFAULT, > - false); > + false, false); > if ( res ) > goto out; > continue; > @@ -455,11 +463,22 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, > res = scan_pfdt_node(kinfo, pfdt, node_next, > DT_ROOT_NODE_ADDR_CELLS_DEFAULT, > DT_ROOT_NODE_SIZE_CELLS_DEFAULT, > - true); > + true, false); > if ( res ) > goto out; > continue; > } > + if ( dt_node_cmp(name, "reserved-memory") == 0 ) > + { > + res = scan_pfdt_node(kinfo, pfdt, node_next, > + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, > + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, > + false, true); > + if ( res ) > + goto out; > + *found_reserved_mem_node = true; > + continue; > + } > } > > out: > @@ -486,6 +505,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > { > int addrcells, sizecells; > int ret, fdt_size = DOMU_DTB_SIZE; > + bool found_reserved_mem_node = false; > > BUILD_BUG_ON(DOMU_DTB_SIZE > SZ_2M); > > @@ -538,7 +558,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > */ > if ( kinfo->dtb ) > { > - ret = domain_handle_dtb_boot_module(d, kinfo); > + ret = domain_handle_dtb_boot_module(d, kinfo, &found_reserved_mem_node); > if ( ret ) > goto err; > } > @@ -556,9 +576,12 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) > if ( ret ) > goto err; > > - ret = make_resv_memory_node(kinfo, addrcells, sizecells); > - if ( ret ) > - goto err; > + if ( !found_reserved_mem_node ) > + { > + ret = make_resv_memory_node(kinfo, addrcells, sizecells); > + if ( ret ) > + goto err; > + } > > ret = make_intc_domU_node(kinfo); > if ( ret ) From xen-devel-bounces@lists.xenproject.org Tue Sep 15 10:05:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 10:05:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421601.1647372 (Exim 4.92) (envelope-from ) id 1x6Q2h-0005nG-4r; Tue, 15 Sep 2026 10:05:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421601.1647372; Tue, 15 Sep 2026 10:05:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Q2h-0005n9-2J; Tue, 15 Sep 2026 10:05:35 +0000 Received: by outflank-mailman (input) for mailman id 1421601; Tue, 15 Sep 2026 10:05:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Q2f-0005n1-Bt for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 10:05:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Q2e-00BhJM-Oj for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 12:05:32 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9186a-e002-0a2a0a5209dd-0a2a450cc8ce-12 for ; Tue, 15 Sep 2026 12:05:32 +0200 Received: from [52.101.46.71] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa91868-f479-0a2a450c0019-34652e47ed59-4 for ; Tue, 15 Sep 2026 12:05:30 +0200 Received: from BN0PR04CA0209.namprd04.prod.outlook.com (2603:10b6:408:e9::34) by SJ1PR12MB6364.namprd12.prod.outlook.com (2603:10b6:a03:452::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Tue, 15 Sep 2026 10:05:25 +0000 Received: from LV8PEPF00000066.namprd03.prod.outlook.com (2603:10b6:408:e9:cafe::57) by BN0PR04CA0209.outlook.office365.com (2603:10b6:408:e9::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.12 via Frontend Transport; Tue, 15 Sep 2026 10:05:23 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by LV8PEPF00000066.mail.protection.outlook.com (10.167.248.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Tue, 15 Sep 2026 10:05:23 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 15 Sep 2026 05:05:23 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 15 Sep 2026 05:05:23 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 15 Sep 2026 05:05:21 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DnRt4yTDNKzemUtdIFmlFjFGommpMs7KyLPRcWLiQR8fT9cXW3dxgr/9kGJd+zNmJSZ6u4z0n/KsiW2YrjMdCW+oMLQ+LeAh7uOWtdOBGEgxjaveoWcx8oB98yi2KRlgLqKMEMZUOTwNsfjawwUUhs9uH5leMWeycQOyLj51QhmVCCMnKd3+RrDl1U9phW1vm+TUUfYgl2rsQnGlF1ofGKB4JgNWvWl/YWgUhG2bH+VSSERu1JrjKEcBmb/fl6mejNTp3Al6rhAJV9bepIIM9eAexWijYkcEwRTNP7u2u1HeQM4MZfVZ0KcIbzmJScA3mAaOOdabvvQxsimm7Natjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=j006rmxLo+ApI4QfmDcFsOzeYmInP1NFjds5PKVI7+U=; b=VM++YpADTiu6HwmSnYGMftVcc5cKUp/e+/Lhx78FzzCY1QwsltHyG78MlSJ6C2HF4wigLxbDLcfvWqo55Q5KlXQWInYwH56XoI3YwFpCJ6wQeTvcIWR+YyBu/wdBVOxsXcNmLavoECRzBm2Pj+N3KAb+f13n65he/JW1GQ/FrojJnfr5lAchdPJSgKYdfwUo7QeNYI50OmflcCq8AuJtxWKKbIDkHyTWGprzJIpwP9cncyRYzGpR2dDHhUbX9wd7VnLMi/KCOidpvLkE2ZwlHba6HIyDDe+1U5UJMxXOLhZlYLiDOUEzDQ62K2pzgcjflV6KJEUdBIrBkTSm3UZ36Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j006rmxLo+ApI4QfmDcFsOzeYmInP1NFjds5PKVI7+U=; b=ANd4+iYEz2qV3yvy0fjmba8sXBibPQxHfdEaPsh34JqYbr5soTGkAeBrgTDTTPVfEJqahKDUIEjicMAVmUlE9YKJACoepfcbb37fynDHVV3x3b5lNLbvR1s7b9+HHmM1lGQOubRk1sdlvQG0bIgxWXjjsd0pNP2OKJ4JD3wFL0A= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Tue, 15 Sep 2026 12:05:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/4] xen/arm: handle irq_set_type() failures To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jens Wiklander References: From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV8PEPF00000066:EE_|SJ1PR12MB6364:EE_ X-MS-Office365-Filtering-Correlation-Id: cfc22f37-7d63-47b6-4c11-08df1310dbd7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|7416014|1800799024|376014|23010399003|6133799003|18002099003|22082099003|10067099003|11063799006|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: fIB/3NiCgOMFLYQZbq1PbWdO5q3jOnB+i2IuULF+lwTs0tKIh/5XNBo7WoH3uoOFAWuG1FW52ocyuHWGbqvwFoE2ObroRK9wGRSZQIImyaUZfagtGGV04qyqP5XZfV0zGvYPMAezW798T9MNJpT1cOtnfBHzP8W8u5j9ojHrYJzuAi48Q6idyFu5RT/B70aIPeDSilqybAhB8Ik1KdAyBI6R8PNA8DVizqIZkicZf5GXQh0vMvoa7hOcZXfnlJBOq8988/5K4yZes+X1MM9U06GWF4t3fhy1WhNln5OuoH+PCbwFLv0ZJVJS5s6NUsaeuLdqhCgAdSuAEN6hrl9zhVn4fUCL3u36zD09SVd65EdDsGz4zdrw8SmGCtdW+eVmwkI9fuHYaMZ34W6reLdgvooVQhC8ZWAJIkzQtdNHO46JhsDekMW2qgdXZ0/CWqf52tla3tgqWQu35HWfFIfusBvflrdMHDKLQXLg/4bR/LV3m8AHjJ5FZ0EUntJGO0qsv4QHrS/8Vc2IFMrNr688Xxk6whUOYiehPUv2JBCKKiPEoVCzImFwH4r79as230x4BIfEpj0cVUdHXcTwnE7XJ9v68VWWcVRQTdsxMoc4IAHi28oz4MXIYxbDaUR7d9C6+sgOD0cmWwEdHSB6dJlBjnBjyB1G/j+igKTFUSz+rq6o+Tb/HWRF9dnupZNVRyz/5C2iQ0wrHWc8LzK/ZxQu4g== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(82310400026)(7416014)(1800799024)(376014)(23010399003)(6133799003)(18002099003)(22082099003)(10067099003)(11063799006)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: a1aqWonAu11FVvFrmVWRP5APWFdB+txzAcD5+9Z7M5bjbMWO9MeyGdP99dMktQJYsZ8bCXtZ39Mqz6Eh611SrHZILmLuxJtKF3acVMpGqodYcSivLmfbe//gqB9Nh96Ot0jV2kjWPbguFlzirSfvEk/fR3VecDSQFbbJSyabl1nJcvOlR9YFmw2nEyLShIZPs1wHOs2bMZIo7iJWEWfa5jbyX6lD4XMV1gMAhf9TZgPhH7lj9owVaYUFTL8AOmFeNx+NaAQlQPLbPTzJB1iKtx0LjRvp4bl1aWZuz7svaXGB8yK+RlRcRjOTbeO87DfqVPgpYoKHlTnqGXUoYO1CN8NMTc65AqIcA7nWav0uvfyFiBrOkOxpMayEHLMIRZdeAmdFEATcRszSNu/mPv21lAcCPBi1AZ4KjFfsBquV3dtwRNqgCoYMCvNVkQvRfY49 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2026 10:05:23.8238 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cfc22f37-7d63-47b6-4c11-08df1310dbd7 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: LV8PEPF00000066.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6364 X-purgate-ID: tlsNG-d25034/1789466730-5290EA5B-AE2C3C15/0/0 X-purgate-type: clean X-purgate-size: 1016 On 18-Aug-26 13:33, Mykola Kvach wrote: > Several Arm firmware initialization paths discard irq_set_type()'s return > value, violating MISRA C Rule 17.7. If trigger configuration fails, > initialization continues with an IRQ that was not configured as requested. > > GTDT and MADT retain rejected timer and maintenance INTIDs. > check_timer_irq_cfg() and release_irq() later perform unconditional > descriptor lookups on those values. Xen has no backing descriptors for > INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds > access. > > Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store timer > INTIDs only after successful trigger configuration, make GTDT parsing > failure fatal, and stop UART or notification setup when trigger > configuration fails. > > Signed-off-by: Mykola Kvach This should be the first patch in a series that can be committed right away. Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:13:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:13:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421693.1647382 (Exim 4.92) (envelope-from ) id 1x6SyY-0003do-Pk; Tue, 15 Sep 2026 13:13:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421693.1647382; Tue, 15 Sep 2026 13:13:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6SyY-0003dh-My; Tue, 15 Sep 2026 13:13:30 +0000 Received: by outflank-mailman (input) for mailman id 1421693; Tue, 15 Sep 2026 13:13:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6SyX-0003db-Fa for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:13:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6SyW-001Tjd-EH for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:13:28 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9446b-e002-0a2a0a5209dd-0a2a4504cafa-42 for ; Tue, 15 Sep 2026 15:13:28 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94476-b57f-0a2a45040019-aceafc1fd10a-3 for ; Tue, 15 Sep 2026 15:13:28 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 17A9D43572; Tue, 15 Sep 2026 13:13:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54BE11F0089A; Tue, 15 Sep 2026 13:13:25 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789478006; bh=4tD8a6exBiuiMZ+UoC5PJsvb3MP2QyoYGVvzltIQRI4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Knl5Rk7L79lys25DYi750mDQwSC6ffBx2Yd/MV/TjslA4t980FAtpJisR/xidrHPa 6T6sVPQ0O8X3eLpZ4aarQrxyNuteXmYp3jFjVCIelAbEeqFmpJ0aG+1p7qWMugMF2G WnMT63DNSgDMnE4a4bsyEHD0XV1F9aDohAhutgwte6vXVNl4dHGI/2KBmBhezBvpJx 3GnTUXWxqs+EZxgeUrMfbLe6QI7ea2Bw2jnSpd87qTMVX6qIeb9u4IYVif7vUzusPZ 1kTqjhRNVP4VMysH92GYpVpSFfauL7AkXQtXSNc7pu9ap+gUdQdJdoxv0udHzAQgmY SX9YeTJ0eXJvg== Date: Tue, 15 Sep 2026 15:13:23 +0200 From: Frederic Weisbecker To: Josef Bacik Cc: "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v2 03/15] rcu-tasks: Hold trampoline nesting across irq-exit preemption in trampoline text Message-ID: References: <20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com> <20260911-b4-rcu-tasks-preempt-qs-v2-3-eaaa61ed2da4@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260911-b4-rcu-tasks-preempt-qs-v2-3-eaaa61ed2da4@toxicpanda.com> X-purgate-ID: tlsNG-ebf023/1789478008-508D9B50-ECAD250F/0/0 X-purgate-type: clean X-purgate-size: 868 Le Fri, Sep 11, 2026 at 02:08:41PM +0000, Josef Bacik a crit : > A trampoline's own rcu_tramp_nesting increment and decrement live inside > the trampoline, so there is a window of a few instructions on entry and > exit where the count is zero while the CPU is executing trampoline text > (or text on the way into one, such as a static ftrace stub holding a > direct-call target). In that window the task has not called out, so it > can only be preempted from an interrupt, and the interrupted instruction > pointer identifies where it is. I haven't read the whole patchset yet but what happens if the count is zero on trampoline exit but the trampoline isn't finished yet and RCU tasks does a fully quiescent scan of all tasks during that short window? Isn't that ending with a too short grace period? Thanks. -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:17:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:17:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421704.1647391 (Exim 4.92) (envelope-from ) id 1x6T2k-0004Dv-94; Tue, 15 Sep 2026 13:17:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421704.1647391; Tue, 15 Sep 2026 13:17:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2k-0004Dm-5v; Tue, 15 Sep 2026 13:17:50 +0000 Received: by outflank-mailman (input) for mailman id 1421704; Tue, 15 Sep 2026 13:17:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2i-0004Dg-NM for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:17:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2i-00EG1H-3u for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:17:48 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94571-8faa-0a2a0a5109dd-0a2a45019fcc-32 for ; Tue, 15 Sep 2026 15:17:47 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9457a-5984-0a2a45010019-4a7de6ccada6-3 for ; Tue, 15 Sep 2026 15:17:47 +0200 Received: by mail-qk2-f12.google.com with SMTP id af79cd13be357-939695b5741so370064585a.1 for ; Tue, 15 Sep 2026 06:17:46 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e86b7424sm1246323785a.32.2026.09.15.06.17.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:17:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478265; x=1790083065; darn=lists.xenproject.org; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=CA3eKaZE6WZpL/SGK3o3QsvQZMbyNxLDZChWtjOtLj4=; b=J6tYyr9tNhzr6Ed+ulfh5m7yeFToGH1XtOMLv+Q4VwfXZJl5vFBlNJTL1nLkjwtly/ UtmZ5v7gG4OJywgnMF3WNd8DHASdMbOPT7Iu0nigGxVlRy1TvtXhQrBYPd4CIcHIIIMN H47b+jIPsMSUGUwtcDOK3qZfM30F0hJjO4pahBmImnCwk1L6J0wPHQcAQzo1LURCxWPw Nhqylxq3qkPriAdoVdMW+4c0RnrUDcDiJMvCz0d+LCaNzG7mYWva3Thp2BV6c6CWbWYQ ttPFX4Sk7Of1tP/g3UIWOgMFT+Qthf/ktBDZm17aYqbVn++icfvecsQlqG5JTgjlJzvc Nmhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478265; x=1790083065; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=CA3eKaZE6WZpL/SGK3o3QsvQZMbyNxLDZChWtjOtLj4=; b=1N9RCv1vPhG6wBIKZL9GqRVAFO3xN5YVcO3iLFvAW7sX2d6VGU30n0zM0gKUPNLFws MXNrqzt2/iVzIoFQhFWdMTdPIaQd6Esw4mDcp9x+h5/zkl61Hjqgfa3W3CsQNpGnLSUu GNMTbQJdbwU2BkJLaiULrAmR10QHQZPwtj+tlo9WlL7Fp6SbxRt8s4EcWFi4DFHmZYQ8 VXNBUXvo8IkYSa5V27PIAb3BckCysgO1TR5RYepLDuVjrjWCUWCKO1DhWEUieu6auWE2 Xdn3yXbTe0SQhMqdZlNkzUqliOA9J67Zb5zbYUUbNpOjzViPzp1kWgP2ohVVUbzX6ARV 9DAw== X-Forwarded-Encrypted: i=1; AKwUvBxHrO5JH71ekBx/+XhxvOivnvXvli9BqbT1j/ZLCF6HoI7dDsfXzSe3E9dhnBGa2bmGeQ+1WQ/eLDc=@lists.xenproject.org X-Gm-Message-State: AFuF++kAJPVsWf4bR5T5GFfXIzswu13sOOUPt84KA4dBO6g1DNBAP0eF WjpoZKR21MkeleMsAEdJ3RvD2k7I1OdzupOIMG5ZMje7GlCjD1V0vv20sJTmZIsKlms= X-Gm-Gg: AYBFou1XtGnGpi/kETs5GnYpgZ9sX8lijj5R56UR0sMrWfjLA5dM0VjLIm0MSBXe7wW fqz8nwNTNNWeGgGqdX3yZGxC+PNc0JET+wGpA8b7EQIRhl/91zaEquuMZBIwt21meGRoey6m9dz We1Y29iKzFRUxzm1SzYCHN0ofRngVZhCuFVwaeQogpY8RpBTief1US4ph0CZVd8FEc8Il0Ow33w WraIFV3YhYCBaYhSMx9OiG/51mQDfHQi3hpUnQBTtN9LRcP61/U9dLG+pP12QoeVjECNNyqcKtw 2Ev8B6QjhwreNxMoYRSuHtzm3j7P18kgyzNZAEoznGYL+cxKfebn8uFjSJCiE22zjdcw/KaPCjG eOgEpepqOyaI/Goe5t0W2nzgd0Wt/7/1XzTyP/jVfQmJd/xOwAXV0hOhRIBtCdZdmd8D0cVYxc9 UMzqodw5HuOkraVWdQvx8TPfRcJBEO9lxUceN/+dtX411Nb3/Rs6JgALtLzZGc69tB34Cwn+8PM vr47MVnPE41PEk/RmK+nMOK37VKKNAmz0a+VLFfjavvotaV+W63msu5 X-Received: by 2002:a05:620a:470e:b0:939:abe1:ed1b with SMTP id af79cd13be357-93a294d965amr1123242485a.0.1789478264913; Tue, 15 Sep 2026 06:17:44 -0700 (PDT) From: Josef Bacik Subject: [PATCH RFC v3 00/13] rcu-tasks: build Tasks RCU on Tasks Trace readers in trampolines Date: Tue, 15 Sep 2026 13:17:27 +0000 Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAGlFqWoC/4WOwU7DMBBEf6XymW1t1w0qJyQkPoAr6mG93hADT YLXjVpV+Xccc0ECxHFmZ97OVQmnyKLuVleVeIoSh76I7c1KUYf9C0MMRSurbaP3RoN3kOgEGeV NYEzMxzHDh4DTpm3dzjU7ulWlXU5tPFfys3p6fFCHL1NO/pUpL8wl5lEYfMKeusV6Hzfebar52 5el0UXJQ7rUxZOp+H/HTQY0BOeafeuIjDb3eThHGrEPuKbhWMdN9jvM/A2zBcaI2BgONqD7AZv n+RPLhkj2WQEAAA== X-Change-ID: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478261; l=22161; i=josef@toxicpanda.com; h=from:subject:message-id; bh=43eZJz07KhwqgXdlOExlWEsTOX1gVCGqU7n6x7bSOxA=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QIUmgCqbuHwL4lKDJsIWfwnYKIqMjOtPbbw4D7yPVkPP1w3qdsMr95Lcgdt8uokycoTCZZYcBR+ nlRJ2PahVqAY= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d62444/1789478267-BF063757-592F753F/0/0 X-purgate-type: clean X-purgate-size: 22163 v1: https://lore.kernel.org/all/20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com/ v2: https://lore.kernel.org/all/20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com/ v2->v3: - Reworked along the lines Alexei and Paul discussed: no new per-task counter, trampolines take rcu_read_lock_trace() (open-coded in asm for ftrace_caller, the optprobe template and the sample direct trampolines; in the existing C glue for BPF, so the JITs are untouched). - Tasks RCU on x86-64/arm64 becomes a per-CPU pass over context switches and irq-exit reschedules outside trampoline text plus synchronize_rcu_tasks_trace(), keeping the call_rcu_tasks() API and callers as they are. Classic stays for everyone else. - Dropped the v2 QS-rule, holdout-scan and resched-kick patches, they are subsumed by the above. - Moved the lockdep annotations in rcu_read_lock_trace()/unlock inside the reader and made it (and __srcu_read_lock_fast()) __always_inline so nothing runs out of line before the reader is entered. - Addressed AI review on the staging branch: kprobe optimizer waits out tasks already preempted in the jump window; fentry-only BPF images take one Tasks RCU round per prog on teardown; holds are released on any non-irq context switch (PREEMPT_DYNAMIC none/voluntary); nohz_full user CPUs and the user tick count as quiescent; Kconfig excludes NEED_SRCU_NMI_SAFE; x86 select depends on DYNAMIC_FTRACE. v1->v2: - Only walk the kprobe hash while the optimizer is actually waiting (Sashiko). - Re-check the kprobe jump window at every QS decision instead of once at preemption time (AI review). - Updated Documentation/RCU for the new rule (AI review). - Added 14/15 and 15/15 to address Paul's comments. - Added a comment in trace_recursion.h per Steve. - No change for the arm64 ftrace_static_tramp_end report, the Kconfig dependency already covers it (Sashiko). - Re-ran the x86-64 QEMU tests, still 0.2-0.3s and clean. --- What v3 does --- Following the v2 thread, this version takes Alexei's and Paul's suggestion: instead of teaching classic Tasks RCU about a new per-task "in trampoline" count, make the trampolines Tasks Trace RCU readers and build the Tasks RCU grace period on top of that. - Every trampoline whose lifetime Tasks RCU guards enters rcu_read_lock_trace() before calling out and leaves it before returning. For BPF that is done in the existing __bpf_prog_enter/exit and __bpf_tramp_enter/exit glue (the sleepable paths already did), so the JIT-emitted trampolines do not change. ftrace_caller (x86-64 and arm64), the x86 optprobe template and the samples' direct trampolines get the reader open-coded in assembly: trc_reader_nesting++ plus the SRCU-fast per-CPU increment, same as the C inline. - That leaves the handful of trampoline instructions before the reader is entered and after it is left, the BPF glue's own prologue (placed in a new .text..rcu_tramp section so it can be recognised), the static ftrace stubs and x86 return thunks that carry a trampoline address, and the kprobe jump-optimization window, which has no trampoline at all. A task can only linger in any of those by being interrupted there, and a pure SRCU grace period cannot see it. Such text never calls anything that schedules, so the grace period also waits, per CPU rather than per task, for a context switch; the one switch that can catch a task at an arbitrary instruction, irq-exit preemption, checks the interrupted IP first (rcu_tasks_trampoline_text()) and puts a task it finds inside on a short holdout list until a later voluntary switch or irq-exit check finds it elsewhere. CPUs that have not switched after a jiffy get resched_cpu(). - A grace period is then: CPU pass, drain holdouts, synchronize_rcu_tasks_trace(), and one more CPU pass and drain for tasks that have since left the reader into the trailing instructions. It runs from the existing rcu_tasks kthread, so call_rcu_tasks(), synchronize_rcu_tasks() and rcu_barrier_tasks() keep their names and every caller is untouched (fentry-only BPF images, which have no percpu_ref and one reader per prog, requeue for one grace period per prog before freeing). It is bounded by a few jiffies, preempt-off latency and an SRCU grace period, independent of how long any task runs without sleeping, needs no per-task scan, and makes cond_resched_tasks_rcu_qs() unnecessary on these architectures. - x86-64 and arm64 select HAVE_RCU_TRAMPOLINE_READERS in the last patch; everything before that is inert. Other architectures keep the classic implementation unchanged. Same QEMU test as before (x86-64, PREEMPT_LAZY with PREEMPT_RCU=n and with PREEMPT_DYNAMIC/PREEMPT_RCU=y, PROVE_RCU, lockdep; 30s in-kernel spinner with the function tracer, an ftrace kprobe, an optimized kprobe and the direct samples cycling): synchronize_rcu_tasks() is now 20-25ms against the spinner (classic: 29.7s; v2: 0.2-0.3s), ftrace instance teardown ~0.2s, optprobe register+unregister ~0.6s, samples load and unload in about a second, no warnings and the new return-to-user assertion quiet. arm64 is build-tested; hardware numbers for both are still owed. Things I would like opinions on: - Paul: whether hanging this off the rcu_tasks kthread as an alternate gp_func is acceptable, or you would rather see classic go away outright on these architectures and the API become thin wrappers. - The open-coded rcu_read_lock_trace() in ftrace_caller is ~9 instructions each side versus 2 in v2; it is what "use the existing Tasks Trace infrastructure" costs in asm. On arm64 the per-CPU increment is an LL/SC add (David's point about per-CPU ops applies). - CONFIG_TASKS_TRACE_RCU_NO_MB depends on RCU_EXPERT, so a non-expert x86/arm64 build gets the smp_mb() in rcu_read_lock_trace() even though ARCH_WANTS_NO_INSTR; the asm follows the C here but that looks unintended. - Alexei: the non-sleepable BPF enter/exit glue now takes rcu_read_lock_trace() on these architectures (compiled out elsewhere), and __bpf_tramp_enter/exit bracket the percpu_ref get/put with it. Nothing is added to the JITed image. --- Original email (v1) --- Tasks RCU only treats a voluntary context switch, usermode or idle as a quiescent state, because a preempted task may be sitting in a trampoline that is about to be freed. That was a fine trade when PREEMPT_NONE servers compiled Tasks RCU away and PREEMPT desktops rarely ran long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: Tasks RCU is now real on server configs, and cond_resched() is a no-op, so a CPU-bound kthread or kworker only ever loses the CPU by being preempted, which is exactly the event Tasks RCU refuses to count. The way this showed up for us was a cgroup writeback worker draining a very large cgwb for around eleven minutes on an arm64 box. Nothing wrong with that on its own, but a BPF program detach on another CPU went bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() while holding trampoline_mutex, forty-odd tasks piled up behind the mutex, and the hung task detector panicked the machine. The kprobe jump optimizer is worse in principle: it does synchronize_rcu_tasks() under kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running kthread can stall static key updates and CPU hotplug for its whole run. The current answer is to find each such loop and add cond_resched_tasks_rcu_qs() to it, which is the kind of annotation PREEMPT_LAZY was supposed to let us stop writing. This series tries the other direction: have the trampolines say when a task is inside them, so that a preemption anywhere else can be a quiescent state. - task_struct grows an int, rcu_tramp_nesting. Every trampoline whose lifetime Tasks RCU guards increments it before calling out and decrements it before returning: ftrace_caller and its dynamic copies, the BPF trampoline (which drops it again around the call to the original function, since im->pcref covers that), the x86 optprobe template, and out-of-line register_ftrace_direct() trampolines. Only current writes it and nested users are balanced, so it is a plain non-atomic inc/dec, one load of current plus one RMW per entry/exit. - The inc/dec are inside the trampoline, so there is a window of a few instructions on each side where the count is zero but the task is in (or on its way into) trampoline text. Nothing there can be preempted synchronously, only from an interrupt, so the irq-exit preemption path looks at regs->ip and holds the count across preempt_schedule_irq() when the IP is somewhere the counter cannot cover: outside core and module text (all the dynamically allocated trampolines and slots), in the static ftrace stubs or the x86 return thunks that still hold a direct-call target, in a module that hosts its own direct trampoline, or inside the bytes after a kprobe that the jump optimizer may be about to rewrite (the one synchronize_rcu_tasks() user that is not about trampolines at all). - With those in place, rcu_tasks_classic_qs() also clears the holdout flag on a preemption when the count is zero, on architectures that opt in. x86-64 and arm64 do so here. Everyone else keeps the voluntary-only rule and is untouched apart from the (unused) field. A running holdout already gets poked via rcu_request_urgent_qs_task(), which makes the next tick set NEED_RESCHED, so with this the resulting preemption retires it and a Tasks RCU grace period is bounded by roughly a tick plus the longest preempt-off section rather than by the longest stretch without a voluntary schedule(). Patches 1-12 are scaffolding and change no behaviour on their own; patch 13 flips the rule and selects the option for the two architectures. Testing so far is QEMU only: x86-64, PREEMPT_LAZY with PREEMPT_RCU=n, PROVE_RCU and lockdep, with and without PREEMPT_DYNAMIC. A kthread spinning in-kernel for 30s with the function tracer, an ftrace kprobe, an optimized kprobe and fentry/fexit programs attached: synchronize_rcu_tasks() goes from 29.7s to 0.1-0.3s, tearing down a DYNAMIC ftrace_ops (tracefs instance function -> nop) from 27s to 0.2-0.8s, and the ftrace-direct sample modules load, fire and unload in about 2.5s each while the spinner runs, with no warnings and the new return-to-user assertion quiet. arm64 is build-tested only at this point; real hardware numbers for both are the obvious next step and I did not want to sit on the idea waiting for them. Things I would particularly like opinions on: - Whether hooking rcu_tasks_classic_qs() is the right place, or whether Paul would rather see this expressed differently inside Tasks RCU. - return_to_handler and the rethook/kretprobe trampolines are not instrumented. Their C callees take the ftrace recursion lock before touching any ops and the trampolines themselves are static text, so I believe they do not need it, but I would like Steven and Masami to confirm. - The register_ftrace_direct() contract change: out-of-line direct trampolines now have to maintain the count themselves (the samples are converted). I do not know of out-of-tree users beyond BPF, but this is the one place an existing user could be silently weakened. - Whether arm64 folks are comfortable with the ldr/add/str in ftrace_caller and the BPF trampoline, and with treating all of ftrace_caller as trampoline text for the IP check. - If this holds up, cond_resched_tasks_rcu_qs() and rcu_softirq_qs_periodic() become unnecessary on the opted-in architectures; I have not touched them here. Based on v7.3-rc2+ (893e11787f78). rcu-tasks: let preemption outside trampolines be a quiescent state v1: https://lore.kernel.org/all/20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com/ v2: https://lore.kernel.org/all/20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com/ v1->v2: - Only walk the kprobe hash while the optimizer is actually waiting (Sashiko). - Re-check the kprobe jump window at every QS decision instead of once at preemption time (AI review). - Updated Documentation/RCU for the new rule (AI review). - Added 14/15 and 15/15 to address Paul's comments. - Added a comment in trace_recursion.h per Steve. - No change for the arm64 ftrace_static_tramp_end report, the Kconfig dependency already covers it (Sashiko). - Re-ran the x86-64 QEMU tests, still 0.2-0.3s and clean. v2->v3: - Reworked 15/15 to batch resched_cpu() per scan with a cpumask and skip it for young grace periods, per Paul. - Folded Paul's WARN_ON_ONCE() nit into 1/15. --- Original email --- Tasks RCU only treats a voluntary context switch, usermode or idle as a quiescent state, because a preempted task may be sitting in a trampoline that is about to be freed. That was a fine trade when PREEMPT_NONE servers compiled Tasks RCU away and PREEMPT desktops rarely ran long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: Tasks RCU is now real on server configs, and cond_resched() is a no-op, so a CPU-bound kthread or kworker only ever loses the CPU by being preempted, which is exactly the event Tasks RCU refuses to count. The way this showed up for us was a cgroup writeback worker draining a very large cgwb for around eleven minutes on an arm64 box. Nothing wrong with that on its own, but a BPF program detach on another CPU went bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() while holding trampoline_mutex, forty-odd tasks piled up behind the mutex, and the hung task detector panicked the machine. The kprobe jump optimizer is worse in principle: it does synchronize_rcu_tasks() under kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running kthread can stall static key updates and CPU hotplug for its whole run. The current answer is to find each such loop and add cond_resched_tasks_rcu_qs() to it, which is the kind of annotation PREEMPT_LAZY was supposed to let us stop writing. This series tries the other direction: have the trampolines say when a task is inside them, so that a preemption anywhere else can be a quiescent state. - task_struct grows an int, rcu_tramp_nesting. Every trampoline whose lifetime Tasks RCU guards increments it before calling out and decrements it before returning: ftrace_caller and its dynamic copies, the BPF trampoline (which drops it again around the call to the original function, since im->pcref covers that), the x86 optprobe template, and out-of-line register_ftrace_direct() trampolines. Only current writes it and nested users are balanced, so it is a plain non-atomic inc/dec, one load of current plus one RMW per entry/exit. - The inc/dec are inside the trampoline, so there is a window of a few instructions on each side where the count is zero but the task is in (or on its way into) trampoline text. Nothing there can be preempted synchronously, only from an interrupt, so the irq-exit preemption path looks at regs->ip and holds the count across preempt_schedule_irq() when the IP is somewhere the counter cannot cover: outside core and module text (all the dynamically allocated trampolines and slots), in the static ftrace stubs or the x86 return thunks that still hold a direct-call target, in a module that hosts its own direct trampoline, or inside the bytes after a kprobe that the jump optimizer may be about to rewrite (the one synchronize_rcu_tasks() user that is not about trampolines at all). - With those in place, rcu_tasks_classic_qs() also clears the holdout flag on a preemption when the count is zero, on architectures that opt in. x86-64 and arm64 do so here. Everyone else keeps the voluntary-only rule and is untouched apart from the (unused) field. A running holdout already gets poked via rcu_request_urgent_qs_task(), which makes the next tick set NEED_RESCHED, so with this the resulting preemption retires it and a Tasks RCU grace period is bounded by roughly a tick plus the longest preempt-off section rather than by the longest stretch without a voluntary schedule(). Patches 1-12 are scaffolding and change no behaviour on their own; patch 13 flips the rule and selects the option for the two architectures. Testing so far is QEMU only: x86-64, PREEMPT_LAZY with PREEMPT_RCU=n, PROVE_RCU and lockdep, with and without PREEMPT_DYNAMIC. A kthread spinning in-kernel for 30s with the function tracer, an ftrace kprobe, an optimized kprobe and fentry/fexit programs attached: synchronize_rcu_tasks() goes from 29.7s to 0.1-0.3s, tearing down a DYNAMIC ftrace_ops (tracefs instance function -> nop) from 27s to 0.2-0.8s, and the ftrace-direct sample modules load, fire and unload in about 2.5s each while the spinner runs, with no warnings and the new return-to-user assertion quiet. arm64 is build-tested only at this point; real hardware numbers for both are the obvious next step and I did not want to sit on the idea waiting for them. Things I would particularly like opinions on: - Whether hooking rcu_tasks_classic_qs() is the right place, or whether Paul would rather see this expressed differently inside Tasks RCU. - return_to_handler and the rethook/kretprobe trampolines are not instrumented. Their C callees take the ftrace recursion lock before touching any ops and the trampolines themselves are static text, so I believe they do not need it, but I would like Steven and Masami to confirm. - The register_ftrace_direct() contract change: out-of-line direct trampolines now have to maintain the count themselves (the samples are converted). I do not know of out-of-tree users beyond BPF, but this is the one place an existing user could be silently weakened. - Whether arm64 folks are comfortable with the ldr/add/str in ftrace_caller and the BPF trampoline, and with treating all of ftrace_caller as trampoline text for the IP check. - If this holds up, cond_resched_tasks_rcu_qs() and rcu_softirq_qs_periodic() become unnecessary on the opted-in architectures; I have not touched them here. Based on v7.3-rc2+ (893e11787f78). --- Josef Bacik (13): entry: Pass pt_regs to irqentry_exit_cond_resched() rcu-tasks-trace: Inline rcu_read_lock_trace() and annotate inside the reader rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines kprobes: Expose the optprobe jump window to Tasks RCU ftrace: Mark modules hosting direct-call trampolines for Tasks RCU bpf: Take a Tasks Trace reader in the trampoline glue x86/ftrace: Take a Tasks Trace reader around ftrace_caller's call-out x86/kprobes: Take a Tasks Trace reader in the optprobe template arm64: ftrace: Take a Tasks Trace reader around ftrace_caller's call-out samples: ftrace: Make the direct-call trampolines Tasks Trace readers rcutorture: Make Tasks RCU readers Tasks Trace readers where required rcu-tasks-trace: Assert no reader is held on return to userspace x86, arm64: Build Tasks RCU on Tasks Trace readers in trampolines .../RCU/Design/Requirements/Requirements.rst | 20 + Documentation/RCU/checklist.rst | 7 +- arch/arm64/Kconfig | 1 + arch/arm64/kernel/asm-offsets.c | 8 + arch/arm64/kernel/entry-ftrace.S | 74 ++++ arch/arm64/kernel/ftrace.c | 20 + arch/x86/Kconfig | 1 + arch/x86/kernel/asm-offsets.c | 8 + arch/x86/kernel/ftrace.c | 43 ++ arch/x86/kernel/ftrace_64.S | 69 +++ arch/x86/kernel/kprobes/opt.c | 44 ++ arch/x86/kernel/vmlinux.lds.S | 4 + arch/x86/xen/enlighten_pv.c | 2 +- include/asm-generic/vmlinux.lds.h | 11 + include/linux/bpf.h | 1 + include/linux/irq-entry-common.h | 14 +- include/linux/kprobes.h | 8 +- include/linux/module.h | 7 + include/linux/rcupdate.h | 32 +- include/linux/rcupdate_trace.h | 29 +- include/linux/sched.h | 1 + include/linux/srcutiny.h | 4 +- include/linux/srcutree.h | 5 +- kernel/bpf/trampoline.c | 107 ++++- kernel/entry/common.c | 14 +- kernel/fork.c | 1 + kernel/kprobes.c | 50 +++ kernel/rcu/Kconfig | 28 +- kernel/rcu/rcutorture.c | 10 + kernel/rcu/tasks.h | 480 ++++++++++++++++++++- kernel/rcu/update.c | 2 + kernel/trace/ftrace.c | 39 ++ samples/ftrace/ftrace-direct-modify.c | 9 + samples/ftrace/ftrace-direct-multi-modify.c | 9 + samples/ftrace/ftrace-direct-multi.c | 5 + samples/ftrace/ftrace-direct-too.c | 5 + samples/ftrace/ftrace-direct.c | 5 + samples/ftrace/ftrace-direct.h | 126 ++++++ 38 files changed, 1241 insertions(+), 62 deletions(-) --- base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8 change-id: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 Best regards, -- Josef Bacik From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:17:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:17:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421705.1647399 (Exim 4.92) (envelope-from ) id 1x6T2m-0004RN-IE; Tue, 15 Sep 2026 13:17:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421705.1647399; Tue, 15 Sep 2026 13:17:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2m-0004RG-FL; Tue, 15 Sep 2026 13:17:52 +0000 Received: by outflank-mailman (input) for mailman id 1421705; Tue, 15 Sep 2026 13:17:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2l-0004QS-G5 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:17:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2k-00EG5U-T6 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:17:50 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94574-8faa-0a2a0a5109dd-0a2a45049d76-36 for ; Tue, 15 Sep 2026 15:17:50 +0200 Received: from [74.125.224.140] (helo=mail-yx2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9457d-b57f-0a2a45040019-4a7de08cbd16-3 for ; Tue, 15 Sep 2026 15:17:50 +0200 Received: by mail-yx2-f12.google.com with SMTP id 956f58d0204a3-66fabb1a601so278080d50.3 for ; Tue, 15 Sep 2026 06:17:49 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f2032d4sm120309036d6.5.2026.09.15.06.17.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:17:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478269; x=1790083069; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=6aaaKNzMayGmjMwZUrTAjDsf1dO37tc7Q4XOVkfUDkI=; b=LI9pqqvYIoXl5Mr0o+z6D5mG+Q/pFzYWKGri+lONcUnSvWOmn6qKarwUffuXLS+Xuh ++/F5v1Y3GNQZDD5wefveGzjidioFc1rvbAFmBTnkE6x8DFhgP0OTOisgGAx+lQ+QHIX BXkllG3ooFi0yeD2NB/44MozbLubplBsFPuCyauMaHOY2gIEEBp882+WdWPIqrPYTYeo +FCdIl1YlQZNup5yIRgISJ5AMAKlSwflTvDN2YYxCXUWiDiYWH9h799tEd0kBUKtkQFE mcfhn+9oQNLLlsmpUDK88FII4rjoCKvZKAF9BUDJ96PAtSvX4QyOM8gt1rxp9txzHJxf BSCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478269; x=1790083069; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6aaaKNzMayGmjMwZUrTAjDsf1dO37tc7Q4XOVkfUDkI=; b=zHguepcCqh0YQaLWp1hX8qEUBsJ//XjGvprqPOezVpeI6xtmKWjK98HuLzOuUrtfXZ 6HHko3ObiYoEPD4/PyD3WRHxNNaMGp5XlX/aAk3NwlQIbdIiUhu9gBjxOQbheGzcLbl9 YfhH3AHnSBuUr/uJoxCSQMqP7H4jLgiBJu2DSggmPvcak0+TS7wzlODWMhurAZJe1L5a xXLvBqYh48CHpTGNy3JfNO282xG8IBOBU/Xh4wTeEOSAfKwgEAsqjVKHFA74GpTPysg2 NxR4iEGkMwcIMrdsOippf7TYxvgLUN2A6YZUJ6D5babYC7hG+OHgWa93ffqyVhmlx9FT nXOg== X-Forwarded-Encrypted: i=1; AKwUvBx7ta9hS6feF3rqXJwbqdCPeBCLbt53UASyQrv9FTcbH6etIb6xcKpuh2MZo5q0x42+x9XdG8xQc+E=@lists.xenproject.org X-Gm-Message-State: AFuF++kPxHmlgdAFuG7mNO2uPoyoJ3W0qY6e5/HOO25kNkUW9pLjaAtZ AdCjCOC9Zs2zYmujtUgEyMMnwz6pkF5ZuoR8xFWU57ffu0uZ46A3cHE7O6TGdDF51yI= X-Gm-Gg: AYBFou18IYIGTf+6ZOEoKPfqViPwaOY+Emf6H2Z0pP3n95/QGdsMGc9uK9AvpMCnWFT OR1Jm4b6Lb7a4eLv0BSD+qC0hunvjLXkpLkraRUjnQ0vA9mH2Cs+0GrhfMK5eKiUqBPGHJ8KZ0L I/kxlENTtViAy9WDCzutCqtmtR/hvSdCwW6EPX987Y2sN8xZ2kcq6b1zyGN3MFNDRdrAh32HkmV KfXNbG/qBmx4sQ1e9962z2ROmnV9M7WpGIOLYlUHK17Jy2Ay753eBaZ2ZUVOgVgPpqtXJJnyqSt nglBsimGAKOrzZgc5dj3eyK/7ksP+wK6NuNdcJNONALYZmDY3iv9rM6Il+fZ13B1XJIxx+W8Hfu NtdYpysxZFMlhngT3i16tFGQ53SHDUxkcl6TpN3gaVeJqaCMBaPewRxX4mqi70p55d2CLahJc6V e1EfscCmSzZGGUEiaP+Ns5NmgZ9uPNLosEgPob936LdmZg4G5rXe1VMeAvrcyknqTTib398ozW6 7cjJFiVkg3nd/rSHQpPjK+uWoxkRZl8KXsWiym72l6gl/Icr3iYAVVy X-Received: by 2002:a53:ac8d:0:b0:66f:c1bc:c08e with SMTP id 956f58d0204a3-6715cbfa390mr343734d50.86.1789478267673; Tue, 15 Sep 2026 06:17:47 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:28 +0000 Subject: [PATCH RFC v3 01/13] entry: Pass pt_regs to irqentry_exit_cond_resched() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-1-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=4149; i=josef@toxicpanda.com; h=from:subject:message-id; bh=4dQuHlI7KqFK9OlS3RCAgATHNrdOmuvuGUsCmQTn02w=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QEWkL7am6CPwY8WEkFAeUlQhZwIsKFKiG0LL4CTUEuVNlpBbsncWTVxiTecESmw1XMIxu5wivHh xkMDa7QjuUgk= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1789478270-50CDFB50-912E103E/0/0 X-purgate-type: clean X-purgate-size: 4151 The irq-exit preemption path is about to need the interrupted context's registers to decide whether the preemption may be reported to Tasks RCU as a quiescent state. irqentry_exit_to_kernel_mode_preempt() already has them; hand them down through irqentry_exit_cond_resched(), its PREEMPT_DYNAMIC static-call and static-key variants, and raw_irqentry_exit_cond_resched(). The only caller outside the generic entry code is Xen PV's upcall handler, which has regs as well. No functional change. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 12 ++++++------ kernel/entry/common.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 2c64b388f616..3d85035f5624 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -739,7 +739,7 @@ __visible noinstr void xen_pv_evtchn_do_upcall(struct pt_regs *regs) inhcall = get_and_clear_inhcall(); if (inhcall && !WARN_ON_ONCE(state.exit_rcu)) { - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); instrumentation_end(); restore_inhcall(inhcall); } else { diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index 0bb6c03481fa..b811b469b0a7 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -346,21 +346,21 @@ typedef struct irqentry_state { * * Conditional reschedule with additional sanity checks. */ -void raw_irqentry_exit_cond_resched(void); +void raw_irqentry_exit_cond_resched(struct pt_regs *regs); #ifdef CONFIG_PREEMPT_DYNAMIC #if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL) #define irqentry_exit_cond_resched_dynamic_enabled raw_irqentry_exit_cond_resched #define irqentry_exit_cond_resched_dynamic_disabled NULL DECLARE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); -#define irqentry_exit_cond_resched() static_call(irqentry_exit_cond_resched)() +#define irqentry_exit_cond_resched(regs) static_call(irqentry_exit_cond_resched)(regs) #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void); -#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs); +#define irqentry_exit_cond_resched(regs) dynamic_irqentry_exit_cond_resched(regs) #endif #else /* CONFIG_PREEMPT_DYNAMIC */ -#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() +#define irqentry_exit_cond_resched(regs) raw_irqentry_exit_cond_resched(regs) #endif /* CONFIG_PREEMPT_DYNAMIC */ /** @@ -465,7 +465,7 @@ static inline void irqentry_exit_to_kernel_mode_preempt(struct pt_regs *regs, return; if (IS_ENABLED(CONFIG_PREEMPTION)) - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); } /** diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e3d381fd3d25..e4acd50bd81a 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -134,7 +134,7 @@ static inline bool arch_irqentry_exit_need_resched(void); static inline bool arch_irqentry_exit_need_resched(void) { return true; } #endif -void raw_irqentry_exit_cond_resched(void) +void raw_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!preempt_count()) { /* Sanity check RCU and thread stack */ @@ -150,11 +150,11 @@ void raw_irqentry_exit_cond_resched(void) DEFINE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void) +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) return; - raw_irqentry_exit_cond_resched(); + raw_irqentry_exit_cond_resched(regs); } #endif #endif -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:17:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:17:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421706.1647408 (Exim 4.92) (envelope-from ) id 1x6T2n-0004ez-OZ; Tue, 15 Sep 2026 13:17:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421706.1647408; Tue, 15 Sep 2026 13:17:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2n-0004eq-Lt; Tue, 15 Sep 2026 13:17:53 +0000 Received: by outflank-mailman (input) for mailman id 1421706; Tue, 15 Sep 2026 13:17:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2m-0004RF-KS for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:17:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2m-00DQNP-1E for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:17:52 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94570-e002-0a2a0a5209dd-0a2a450babec-48 for ; Tue, 15 Sep 2026 15:17:51 +0200 Received: from [74.125.230.205] (helo=mail-qk2-f13.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9457e-b7e8-0a2a450b0019-4a7de6cdd447-3 for ; Tue, 15 Sep 2026 15:17:51 +0200 Received: by mail-qk2-f13.google.com with SMTP id af79cd13be357-93a2218d7c2so67884885a.1 for ; Tue, 15 Sep 2026 06:17:51 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939f19f94a1sm1137880185a.42.2026.09.15.06.17.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:17:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478270; x=1790083070; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=IVf/c/k7gzeyhXD1Q6M+2DLwLNI40n7fXEqvG2ZQN0k=; b=BDHNr5XS265fiyZv+nKnkdGvsCZz+AfecQhqLZ16Lbmq5KXvrTXGPDXjcpVb7K6HuX cuBWF4dZhFFusCnoB5VW9GuZ8tztdqGQ3V2FGK5SNKIrT5sWMf3358krpTKSB03uwP6c unP0FpBHUVAaTBVjYZaxdqnUFSEJMBKWcytpcXw2UKPhHY3oQ+50hLy5rZp6WFNv8gOR aJkEXy9N/wQj94ymlRYTJYo6IqJPQ2XcWp3T7BxrVgZT/HsZ1nbgGGB0fEd+2yKIAn3l qefageNO6GA9+qt+pehuW10h3JptI1mDaQQdIGSBDUx6jpxH7pWF71cOTLZkWAQHHrAz fSeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478270; x=1790083070; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=IVf/c/k7gzeyhXD1Q6M+2DLwLNI40n7fXEqvG2ZQN0k=; b=kN5yMI0+fccljiYTyYOb+IqRCpqE1S5tTseaIpHaPUhjFV8jOcbN4RbWc0hC75O8EZ 1/hOXL7Wf9lvcmfVnLJXQGYMUaue9qiL+n6rfrXdo//gysym4hnYQiuV0+lJvIE5XFTF LjDfGTdcpuLIsN/xl4sjG42Jsj1OudKS+P5qYYPUjVOLO008bT1Z0AnSrTajYeoEivTF iyV7Nj6wy1smYOCUhaMvklV52ajrx9mXfnY0kKTDSROJvUb8co7jGHIId+2wtGUZskhI MJ6KNWrMIH5C6mwwaoiVW9oEok3L1+UtKdXHchQbzYFMnc5yaq9nbdh3SoIVP3+2wldg /57g== X-Forwarded-Encrypted: i=1; AKwUvBwoI2WFvEQtvHwLBZGK5GyhxGBn4JPV7MuseUteg8Be6XtYaMr7Zg00DP94KJzMKxPafALzlU2X1Nc=@lists.xenproject.org X-Gm-Message-State: AFuF++ndQrZ3sdtlncP2arRnCETmFwrGKl93eFsWlYJQ7gZmTaB/dfdT uvViOcwHjPlAwGa0JL+ZEkw194a/z8V4gqwe1ORlTCpe096cYcl4GybEZS0IwL3s2hw= X-Gm-Gg: AYBFou0Vyz1GL0Z5QwKWbgwF/0rT4E9vB252vhwG1iFRl7RipISlMdXtjMm+Bt7X8oC yUrkJLoS/HBfy3Aactj6Ms3gtl7XY7KN0iJ8hj3r56WulBP0emZWTX3x9cAKk2mjvH7XVcx5pqV 4jR7XONNn/MB4zBzKV4yTQp6jXJWrN8l7fUeeZ4zVRgyJhq+Gf8sS61J0YJdTToiR2xKIG6kC8I kCid+AaRiUvjLOBWg+6uOMRalTIPEvCiKAT9W136oeVhkr6uhe0Fk6zyHEOCDl3cSYl3LASuUx0 julFLt927WzMnPPa2/BvdLLlRx8Un5Hs/g0WzusmEoXAN+I83HTbRBEyLsLR5UZsgTh5xNw0nVl 3qC+7I8/ImQcsNV4uY3rOdZKWoZXOKT8e8PXO9KZoFw9GBdQnpH/8u/roXyFzScGqwONGfpEs25 gIFqIbs8VDc2+eotmJug4zacSquL+hpqJxHL6YSEmHdLsuUlXEs+ifyWKbbq5ha5jYab8mT+Bym hPi6jkO0L/ws+ydwzQHrGPlfdjSqZIa5WKcXiwL6I3jwxXl8eoa7r6X X-Received: by 2002:a05:620a:2b8f:b0:936:d00a:4947 with SMTP id af79cd13be357-93a345745demr474274385a.2.1789478269641; Tue, 15 Sep 2026 06:17:49 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:29 +0000 Subject: [PATCH RFC v3 02/13] rcu-tasks-trace: Inline rcu_read_lock_trace() and annotate inside the reader MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-2-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=5472; i=josef@toxicpanda.com; h=from:subject:message-id; bh=WoSDn4ZEoocgxJI9vrvXQ3qPnrz/LPBQsbDWUONxsf4=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QOqgtWORMkFCOHo3WLOy6WMvyvf/Bd/PX1OTaW4H8LYu/zuiatDpxAZC81QUixDJwPnYFE7C1UL 57TTusaQZdwg= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1789478271-1A4DB9EA-5F436B44/0/0 X-purgate-type: clean X-purgate-size: 5474 rcu_read_lock_trace() calls rcu_try_lock_acquire() before it has entered the SRCU-fast reader, and rcu_read_unlock_trace() calls srcu_lock_release() after it has left it. rcu_read_lock() and rcu_read_unlock() do it the other way around, annotating strictly inside the critical section, and rcu_read_lock_tasks_trace() already follows that order on the lock side. Make the trace variants match. Also make them, and the __srcu_read_lock_fast() and __srcu_read_unlock_fast() they are built on, __always_inline like rcu_read_lock() rather than leaving it to the compiler, which does outline all four in KASAN/KCOV builds. Besides consistency, this means the first thing a caller of rcu_read_lock_trace() does is enter the reader and the last thing rcu_read_unlock_trace() does is leave it, with no out-of-line call on the outside. A later patch relies on that for callers whose own text is protected by the reader they are about to take. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/rcupdate_trace.h | 22 ++++++++++------------ include/linux/srcutiny.h | 4 ++-- include/linux/srcutree.h | 5 +++-- 3 files changed, 15 insertions(+), 16 deletions(-) diff --git a/include/linux/rcupdate_trace.h b/include/linux/rcupdate_trace.h index 273c59a03251..4035054309d7 100644 --- a/include/linux/rcupdate_trace.h +++ b/include/linux/rcupdate_trace.h @@ -93,22 +93,20 @@ static inline void rcu_read_unlock_tasks_trace(struct srcu_ctr __percpu *scp) * * For more details, please see the documentation for rcu_read_lock(). */ -static inline void rcu_read_lock_trace(void) +static __always_inline void rcu_read_lock_trace(void) { int n; struct task_struct *t = current; - rcu_try_lock_acquire(&rcu_tasks_trace_srcu_struct.dep_map); n = READ_ONCE(t->trc_reader_nesting); WRITE_ONCE(t->trc_reader_nesting, n + 1); - if (n) { - // In case we interrupted a Tasks Trace RCU reader. - return; - } - barrier(); // nesting before scp to protect against interrupt handler. - t->trc_reader_scp = __srcu_read_lock_fast(&rcu_tasks_trace_srcu_struct); - if (!IS_ENABLED(CONFIG_TASKS_TRACE_RCU_NO_MB)) - smp_mb(); // Placeholder for more selective ordering + if (!n) { + barrier(); // nesting before scp to protect against interrupt handler. + t->trc_reader_scp = __srcu_read_lock_fast(&rcu_tasks_trace_srcu_struct); + if (!IS_ENABLED(CONFIG_TASKS_TRACE_RCU_NO_MB)) + smp_mb(); // Placeholder for more selective ordering + } // Else we interrupted a Tasks Trace RCU reader. + rcu_try_lock_acquire(&rcu_tasks_trace_srcu_struct.dep_map); } /** @@ -120,12 +118,13 @@ static inline void rcu_read_lock_trace(void) * * For more details, please see the documentation for rcu_read_unlock(). */ -static inline void rcu_read_unlock_trace(void) +static __always_inline void rcu_read_unlock_trace(void) { int n; struct srcu_ctr __percpu *scp; struct task_struct *t = current; + srcu_lock_release(&rcu_tasks_trace_srcu_struct.dep_map); n = READ_ONCE(t->trc_reader_nesting) - 1; if (n) { WRITE_ONCE(t->trc_reader_nesting, n); @@ -137,7 +136,6 @@ static inline void rcu_read_unlock_trace(void) smp_mb(); // Placeholder for more selective ordering __srcu_read_unlock_fast(&rcu_tasks_trace_srcu_struct, scp); } - srcu_lock_release(&rcu_tasks_trace_srcu_struct.dep_map); } /** diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h index fbcf13bc12d1..a43bae11c81c 100644 --- a/include/linux/srcutiny.h +++ b/include/linux/srcutiny.h @@ -101,13 +101,13 @@ static inline struct srcu_ctr __percpu *__srcu_ctr_to_ptr(struct srcu_struct *ss return (struct srcu_ctr __percpu *)(intptr_t)idx; } -static inline struct srcu_ctr __percpu *__srcu_read_lock_fast(struct srcu_struct *ssp) +static __always_inline struct srcu_ctr __percpu *__srcu_read_lock_fast(struct srcu_struct *ssp) __acquires_shared(ssp) { return __srcu_ctr_to_ptr(ssp, __srcu_read_lock(ssp)); } -static inline void __srcu_read_unlock_fast(struct srcu_struct *ssp, struct srcu_ctr __percpu *scp) +static __always_inline void __srcu_read_unlock_fast(struct srcu_struct *ssp, struct srcu_ctr __percpu *scp) __releases_shared(ssp) { __srcu_read_unlock(ssp, __srcu_ptr_to_ctr(ssp, scp)); diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h index 75e54e4f963f..fdb42ab50301 100644 --- a/include/linux/srcutree.h +++ b/include/linux/srcutree.h @@ -286,7 +286,8 @@ static inline struct srcu_ctr __percpu *__srcu_ctr_to_ptr(struct srcu_struct *ss * on architectures that support NMIs but do not supply NMI-safe * implementations of this_cpu_inc(). */ -static inline struct srcu_ctr __percpu notrace *__srcu_read_lock_fast(struct srcu_struct *ssp) +static __always_inline struct srcu_ctr __percpu notrace * +__srcu_read_lock_fast(struct srcu_struct *ssp) __acquires_shared(ssp) { struct srcu_ctr __percpu *scp = READ_ONCE(ssp->srcu_ctrp); @@ -309,7 +310,7 @@ static inline struct srcu_ctr __percpu notrace *__srcu_read_lock_fast(struct src * Please see the __srcu_read_lock_fast() function's header comment for * information on implicit RCU readers and NMI safety. */ -static inline void notrace +static __always_inline void notrace __srcu_read_unlock_fast(struct srcu_struct *ssp, struct srcu_ctr __percpu *scp) __releases_shared(ssp) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:17:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:17:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421707.1647417 (Exim 4.92) (envelope-from ) id 1x6T2r-0004vD-25; Tue, 15 Sep 2026 13:17:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421707.1647417; Tue, 15 Sep 2026 13:17:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2q-0004v6-Uz; Tue, 15 Sep 2026 13:17:56 +0000 Received: by outflank-mailman (input) for mailman id 1421707; Tue, 15 Sep 2026 13:17:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2p-0004sv-8m for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:17:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2o-00DQNP-Lg for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:17:54 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94581-e002-0a2a0a5209dd-0a2a45099780-4 for ; Tue, 15 Sep 2026 15:17:54 +0200 Received: from [209.85.219.54] (helo=mail-qv1-f54.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94580-be1a-0a2a45090019-d155db36a875-3 for ; Tue, 15 Sep 2026 15:17:53 +0200 Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-90e9ad1a373so7400796d6.0 for ; Tue, 15 Sep 2026 06:17:53 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-912321108a5sm31206596d6.46.2026.09.15.06.17.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:17:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478272; x=1790083072; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=fYtErF6vBN+NnnD1JqJDCU7rpx142OZs1HR5OhHJnD0=; b=Vjm83Eu+tPVcteSMCRWXtdBwGLzYwSaSEdhiG55n9GZVTzotJYAc1HLQ6y6KBSf1iz GApzeln3B22k7qBhuAN8tqJazcFv5T8nZ0IWli+Pe5LDg7vI2nrQjPQowydDOjszlawi edRGeYa8FaqM7bG7lqL5LHDN7Lcq8Hin+BbkaJNL+EXyIPM/sxRxQ818EP/OBR+6/avU LZxigtEn1x/+bZxUjFdYL8/FBtNtUp8Q8N+CdDZ+XedhFmBvVZpegaF77D9YdOlLWVqg cAW87553JEu2RymSq+l1OosIBEtBPNIf9R7WMP12HyRXVolHusZPYiDDzBo9J5dmktUe U+BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478272; x=1790083072; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=fYtErF6vBN+NnnD1JqJDCU7rpx142OZs1HR5OhHJnD0=; b=qpE14rOYPRnDO+TWuLAzY+U/FXqY54C5s5UzwipCVSTQd/4LkW0bLXcmOBxIHnKClE gSjwCBgWg/gwrEf4Eyr7um0jSccTAMMZF+gH2BmH/nUXaVVdsEy2qK52M492+16MRxa8 PyWxX/m+2vnclkf4y8Sq+deit3bS5nHODS1Gst/NtF6uShboQDHuqqHjQpsQLr6fo12k 1EzVpvQv74hrAAbQ4AQsx+7U2qF7JNX+ORKwx39Y63nx3yIWHnpll9tj0h7w6LZ7n2sD O3f0fwLSIaqldAzdj5QrDtY0iAEzVe7McxJQ7pPRmQ+0BbfB0dc760FEvvpTflVzWa5g Oe4g== X-Forwarded-Encrypted: i=1; AKwUvBwKx9NwO2Emgm0c6am6Gxt5dcR4Ryi31LEdjdZG4fxYp+7DJRX9+6TglFevgTqCxmgeKAfLAuqixug=@lists.xenproject.org X-Gm-Message-State: AFuF++mS7e7fYRXlsQriPabgILhGRXHXvEk2fUZvDRntivjH7pimAx1K zWf3NBTJ6QkRj2LVfjgDyvn3qBPruB32k/F9MN1FQ1+kMT3yzO/xTzBkTlamA0qkzRE= X-Gm-Gg: AYBFou0gj9oUfvtqwhuT0SPHTnKyTfK5Z60bhFx545PSstsM4cdJrEvCtYn9JJ8pYwJ vAlhDfeQvdLmVvfq+LYB5zrCfX8ZDQQfl9drPIP0gdkyOvYqWdITQmDaUh6ejwZXizOe1KPaqad cvClcvcucz5GEo9qYgjtPGKW45A3nERGF5ZMHL/FlTwuLzmRvQoMxG/yK+XM4Z6LB/MeYyH+V6p k+3svzW2uAtparhlFRjxRkCCeTwSh4iELJHHUkB1Ejc0LkKeb04I9X9p4306lKXZMxb5hMZVZB9 LCDk3HC9zXWO0ovGaPQbEfC5CQttMUS77oRozM1LrHU0mwz6IwPEUbCjT0hC76l/A+EvQ0+Tc3U sbBujT5c3MFHYfZAr20T7q68QmnjUCUJJXnlafVilrI5MFPy+/enmgPAxDtznFW43La7Nr1Bkjw M6fWI8Z/KD3iYcm5omIJ4sVG3WFXJUuZwv9DENH/pR0AiwtMzX/E2KbJ/hVh6shA/s7rc8WdlLi rAox+mutTAJd9Ry+ikTO/xozvE1ml4g+cSQOxOFdOa05Nz3dlN2Svgg X-Received: by 2002:ad4:5aa4:0:b0:911:2a7c:65b9 with SMTP id 6a1803df08f44-912344347ccmr49325266d6.30.1789478271691; Tue, 15 Sep 2026 06:17:51 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:30 +0000 Subject: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=32683; i=josef@toxicpanda.com; h=from:subject:message-id; bh=wQeEStQPLpkB0ZukCY5vknBzMvvV//pSfULH7QtsQGc=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QMM+dAGbEOlns74BRRoxfkCG0nJCZGoqB9FIgpGikpOfYMXm9qc7IWrJfu93xYxIrOxZ1yXrj33 aa/TFXf8Q9wU= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1789478273-FD26A034-5D7126A2/0/0 X-purgate-type: clean X-purgate-size: 32685 Tasks RCU waits for every task to pass through a voluntary context switch, usermode or idle, because a preempted task might be sitting in a trampoline that is about to be freed and nothing marks it as such. With PREEMPT_LAZY that is a poor fit for servers: cond_resched() is a no-op, so a CPU-bound kthread only ever leaves the CPU by preemption, and one such kthread holds every synchronize_rcu_tasks() caller -- ftrace and BPF trampoline teardown under their mutexes, the kprobe jump optimizer under text_mutex and cpus_read_lock() -- hostage for as long as it runs. Following the discussion on v2, take the other road: let the architecture make its trampolines Tasks Trace RCU readers. When an architecture selects HAVE_RCU_TRAMPOLINE_READERS it promises that every trampoline whose lifetime Tasks RCU guards enters rcu_read_lock_trace() (or its assembly equivalent) before calling out and leaves it before returning, so a task anywhere inside such a call-out, preempted or not, is an ordinary Tasks Trace reader. That leaves the few instructions of trampoline text before the reader is entered and after it is left (plus, in a later patch, the bytes a kprobe jump optimization is about to overwrite). A task can only linger there by being interrupted there, and such text never calls anything that schedules, so instead of tracking tasks we track CPUs: every pass through __schedule() is a per-CPU quiescent event, except that the one context switch that can catch a task at an arbitrary instruction -- a preemption from irq exit -- first records the interrupted IP in the task and parks it on a per-CPU list for the duration (reusing the fields and lists the classic flavor keeps for its exit-path bookkeeping), and, if the IP is inside such "unmarked" text, puts the task on a short holdout list; the task takes itself off at its next context switch outside such a preemption or irq-exit check that finds it elsewhere. Usermode (the existing tick hook, or a nohz_full CPU in an RCU extended quiescent state) and idle count as well. rcu_tasks_trampoline_text() does the classification: anything outside core and module text, a new .text..rcu_tramp section for C glue that trampolines call before it has entered the reader (__rcu_trampoline), and an arch hook for things like static ftrace stubs and return thunks. The grace period, run by the existing rcu_tasks kthread so that call_rcu_tasks(), synchronize_rcu_tasks() and rcu_barrier_tasks() keep their names and callers, is: wait for every online non-idle CPU to context switch (nudging stragglers with resched_cpu() after a jiffy), drain the holdout list as it stood, synchronize_rcu_tasks_trace() for everything inside the readers, then one more CPU pass and drain for tasks that have since left the reader into the trailing instructions. That is bounded by a few jiffies, preempt-off latency and an SRCU grace period rather than by the longest stretch any task runs without sleeping, needs no per-task scan, and makes cond_resched_tasks_rcu_qs() unnecessary on such architectures. As before, idle tasks are not waited for. rcu_tasks_wait_irq_preempted() walks the parked lists for the one caller (the kprobe jump optimizer, later in the series) that makes ordinary text unsafe to be parked in and so has to wait out tasks that were preempted there before it said so. The classic implementation is untouched and remains the default; the new one is built only as CONFIG_TASKS_RCU_TRAMPOLINE_READERS when the architecture opts in and uses the generic irq entry code, whose reschedule check gains the rcu_tasks_irq_resched() call. Nothing selects it yet. Suggested-by: Paul E. McKenney Suggested-by: Alexei Starovoitov Assisted-by: LLM Signed-off-by: Josef Bacik --- include/asm-generic/vmlinux.lds.h | 11 + include/linux/rcupdate.h | 32 ++- include/linux/sched.h | 1 + kernel/entry/common.c | 8 +- kernel/fork.c | 1 + kernel/rcu/Kconfig | 22 ++ kernel/rcu/tasks.h | 460 +++++++++++++++++++++++++++++++++++++- kernel/rcu/update.c | 2 + 8 files changed, 528 insertions(+), 9 deletions(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index b2988aa12f66..86e58c4fe370 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -571,6 +571,16 @@ __cpuidle_text_end = .; \ __noinstr_text_end = .; +/* + * C glue called directly from Tasks-RCU-protected trampolines, bounded so + * that rcu_tasks_trampoline_text() can recognise it; see __rcu_trampoline. + */ +#define RCU_TRAMP_TEXT \ + ALIGN_FUNCTION(); \ + __rcu_tramp_text_start = .; \ + *(.text..rcu_tramp) \ + __rcu_tramp_text_end = .; + #define TEXT_SPLIT \ __split_text_start = .; \ *(.text.split .text.split.[0-9a-zA-Z_]*) \ @@ -607,6 +617,7 @@ TEXT_HOT \ *(TEXT_MAIN .text.fixup) \ NOINSTR_TEXT \ + RCU_TRAMP_TEXT \ *(.ref.text) /* sched.text is aling to function alignment to secure we have same diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 44c07a66edff..fb2a3889a696 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -50,6 +50,31 @@ token_context_lock_instance(RCU, RCU_BH); /* Exported common interfaces */ void call_rcu(struct rcu_head *head, rcu_callback_t func); void rcu_barrier_tasks(void); + +/* + * Trampoline-reader Tasks RCU (CONFIG_TASKS_RCU_TRAMPOLINE_READERS), see + * kernel/rcu/tasks.h. rcu_tasks_irq_resched_enter()/_exit() bracket the + * irq-exit preemption; rcu_tasks_trampoline_text() and the arch_ override + * classify an interrupted IP; rcu_tasks_wait_irq_preempted() lets a caller + * wait out tasks already preempted somewhere it is about to make unsafe. + * __rcu_trampoline places C code that such trampolines call directly, before + * it has entered its Tasks Trace reader, where that classification can see it. + */ +void rcu_tasks_irq_resched_enter(unsigned long ip); +void rcu_tasks_irq_resched_exit(void); +bool rcu_tasks_trampoline_text(unsigned long ip); +bool arch_rcu_tasks_trampoline_text(unsigned long ip); +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)); +#else +static inline void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)) { } +#endif +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +/* Also keeps instrumentation calls out of the prologue, ahead of the reader. */ +#define __rcu_trampoline __noinstr_section(".text..rcu_tramp") +#else +#define __rcu_trampoline +#endif void synchronize_rcu(void); /* @@ -180,11 +205,16 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } #ifdef CONFIG_TASKS_RCU_GENERIC # ifdef CONFIG_TASKS_RCU -# define rcu_tasks_classic_qs(t, preempt) \ +# ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +void rcu_tasks_note_qs(struct task_struct *t, bool preempt); +# define rcu_tasks_classic_qs(t, preempt) rcu_tasks_note_qs((t), (preempt)) +# else +# define rcu_tasks_classic_qs(t, preempt) \ do { \ if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ WRITE_ONCE((t)->rcu_tasks_holdout, false); \ } while (0) +# endif void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func); void synchronize_rcu_tasks(void); void rcu_tasks_torture_stats_print(char *tt, char *tf); diff --git a/include/linux/sched.h b/include/linux/sched.h index 8b3d47a325cc..15beb44caa2c 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -957,6 +957,7 @@ struct task_struct { u8 rcu_tasks_holdout; u8 rcu_tasks_idx; int rcu_tasks_idle_cpu; + unsigned long rcu_tasks_irq_ip; struct list_head rcu_tasks_holdout_list; int rcu_tasks_exit_cpu; struct list_head rcu_tasks_exit_list; diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e4acd50bd81a..94318519998c 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include @@ -141,8 +142,13 @@ void raw_irqentry_exit_cond_resched(struct pt_regs *regs) rcu_irq_exit_check_preempt(); if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) WARN_ON_ONCE(!on_thread_stack()); - if (need_resched() && arch_irqentry_exit_need_resched()) + if (need_resched() && arch_irqentry_exit_need_resched()) { + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_tasks_irq_resched_enter(instruction_pointer(regs)); preempt_schedule_irq(); + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_tasks_irq_resched_exit(); + } } } #ifdef CONFIG_PREEMPT_DYNAMIC diff --git a/kernel/fork.c b/kernel/fork.c index 416758c8a3d4..8077336bb136 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1871,6 +1871,7 @@ static inline void rcu_copy_process(struct task_struct *p) p->rcu_tasks_holdout = false; INIT_LIST_HEAD(&p->rcu_tasks_holdout_list); p->rcu_tasks_idle_cpu = -1; + p->rcu_tasks_irq_ip = 0; INIT_LIST_HEAD(&p->rcu_tasks_exit_list); #endif /* #ifdef CONFIG_TASKS_RCU */ #ifdef CONFIG_TASKS_TRACE_RCU diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index 332df7a7a634..bbab14bc14c3 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -107,6 +107,28 @@ config TASKS_RCU default NEED_TASKS_RCU && PREEMPTION select IRQ_WORK +config HAVE_RCU_TRAMPOLINE_READERS + bool + help + Select this if the architecture uses the generic irq entry code and + every trampoline whose lifetime Tasks RCU guards on it (ftrace + trampolines, kprobe out-of-line and optimized-probe slots, BPF + trampolines, out-of-line ftrace direct-call trampolines) enters a + Tasks Trace RCU read-side critical section before calling out of + the trampoline and leaves it before returning, and any core text + that runs on behalf of such a trampoline outside that reader is + reported by arch_rcu_tasks_trampoline_text(). The assembly readers + use the this_cpu_inc() form of SRCU-fast, hence !NEED_SRCU_NMI_SAFE. + +config TASKS_RCU_TRAMPOLINE_READERS + def_bool TASKS_RCU && HAVE_RCU_TRAMPOLINE_READERS && GENERIC_IRQ_ENTRY && !NEED_SRCU_NMI_SAFE + select TASKS_TRACE_RCU + help + Implement the Tasks RCU grace period as a per-CPU pass over + context switches and irq-exit reschedules outside trampoline text + plus a Tasks Trace RCU grace period, instead of waiting for every + task to voluntarily context switch. See kernel/rcu/tasks.h. + config FORCE_TASKS_RUDE_RCU bool "Force selection of Tasks Rude RCU" depends on RCU_EXPERT diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 627295396cd9..3a7c092361a6 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -152,7 +152,7 @@ static struct rcu_tasks rt_name = \ .kname = #rt_name, \ } -#ifdef CONFIG_TASKS_RCU +#if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) /* Report delay of scan exiting tasklist in rcu_tasks_postscan(). */ static void tasks_rcu_exit_stall(struct timer_list *unused); @@ -802,7 +802,7 @@ static void rcu_tasks_torture_stats_print_generic(struct rcu_tasks *rtp, char *t #endif // #ifndef CONFIG_TINY_RCU -#if defined(CONFIG_TASKS_RCU) +#if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) //////////////////////////////////////////////////////////////////////// // @@ -897,10 +897,445 @@ static void rcu_tasks_wait_gp(struct rcu_tasks *rtp) rtp->postgp_func(rtp); } -#endif /* #if defined(CONFIG_TASKS_RCU) */ +#endif /* #if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) */ #ifdef CONFIG_TASKS_RCU +static int rcu_tasks_lazy_ms = -1; +module_param(rcu_tasks_lazy_ms, int, 0444); + +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + +//////////////////////////////////////////////////////////////////////// +// +// Tasks RCU for architectures whose trampolines are Tasks Trace RCU +// readers (CONFIG_HAVE_RCU_TRAMPOLINE_READERS). +// +// On these architectures every piece of text whose lifetime Tasks RCU +// guards -- ftrace trampolines, kprobe optinsn slots, BPF trampoline +// images, out-of-line ftrace direct-call trampolines -- enters a Tasks +// Trace RCU read-side critical section before calling out of itself and +// leaves it before returning, so a task anywhere inside such a call-out, +// preempted or not, is an ordinary rcu_read_lock_trace() reader and +// synchronize_rcu_tasks_trace() waits for it. +// +// What that cannot cover is the handful of instructions in the trampoline +// before the reader is entered and after it is left, and the one user that +// has no trampoline at all: the bytes after a kprobe that the jump +// optimizer is about to overwrite. A task can only linger in such +// "unmarked" text by being interrupted there; unmarked text never calls +// anything that could schedule. So a context switch on a CPU tells us that +// whatever that CPU was running is out of unmarked text, with one +// exception: a preemption from the irq-exit path, which can happen at any +// instruction boundary. That path has the interrupted pt_regs in hand, so +// just before it preempts it records the IP in the task and checks it +// (rcu_tasks_trampoline_text()); if it is inside unmarked text the task +// goes on a short holdout list first, and takes itself off again at its +// next context switch outside such a preemption or its next irq-exit +// check that finds it elsewhere. With that, every pass through +// __schedule() is a per-CPU quiescent event, as are usermode and idle. +// +// A grace period is then: +// +// 1. Wait for every online, non-idle CPU to context switch, nudging +// stragglers with resched_cpu(). Afterwards no task is in the leading +// unmarked instructions of a dying trampoline unless it is on the +// holdout list. +// 2. Wait for the holdout list (as it stood) to drain. +// 3. synchronize_rcu_tasks_trace(), for everything inside the readers. +// 4. Repeat 1 and 2 for tasks that have since left the reader and are in +// the trailing unmarked instructions. +// +// which is bounded by a few jiffies plus preempt-off latency plus an SRCU +// grace period, independent of how long any task runs without sleeping. +// As with the classic implementation, the idle tasks are not waited for. + +static void rcu_tasks_tramp_wait_gp(struct rcu_tasks *rtp); +void call_rcu_tasks(struct rcu_head *rhp, rcu_callback_t func); +DEFINE_RCU_TASKS(rcu_tasks, rcu_tasks_tramp_wait_gp, call_rcu_tasks, "RCU Tasks"); + +/* Per-CPU count of Tasks RCU quiescent events, and the GP kthread's snapshot. */ +static DEFINE_PER_CPU(unsigned long, rcu_tasks_qs_seq); +static DEFINE_PER_CPU(unsigned long, rcu_tasks_qs_snap); + +/* + * Tasks currently switched out by an irq-exit preemption are kept, with the + * interrupted IP, on the per-CPU rtp_exit_list of the CPU that preempted them + * (reusing the list, lock and task_struct fields the classic flavor uses for + * its exit-path bookkeeping, which this flavor does not need), so that + * rcu_tasks_wait_irq_preempted() can find them without a tasklist scan and + * regardless of where they are in exit. + */ + +/* Tasks last seen preempted inside unmarked trampoline text. */ +static LIST_HEAD(rcu_tasks_tramp_holdouts); +static DEFINE_RAW_SPINLOCK(rcu_tasks_tramp_lock); + +/* CPUs / holdouts the current grace period is still waiting for. */ +static struct cpumask rcu_tasks_pending_cpus; +static LIST_HEAD(rcu_tasks_gp_holdouts); + +extern char __rcu_tramp_text_start[], __rcu_tramp_text_end[]; + +/** + * arch_rcu_tasks_trampoline_text - Does the architecture treat @ip as unmarked trampoline text? + * @ip: kernel text address inside core kernel text + * + * See rcu_tasks_trampoline_text(). Architectures override this to flag + * core text that runs on behalf of a trampoline outside its Tasks Trace + * reader, e.g. static ftrace entry stubs or return thunks that hold a + * trampoline address they are about to jump to. + */ +bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) +{ + return false; +} + +/** + * rcu_tasks_trampoline_text - Is @ip in text Tasks RCU protects but no reader marks? + * @ip: an interrupted instruction pointer + * + * True when a task interrupted at @ip may be executing, or about to enter + * or return into, text whose lifetime depends on synchronize_rcu_tasks() + * without being inside the Tasks Trace reader that text takes around its + * call-outs: + * + * - anything outside core kernel and module text (ftrace and BPF + * trampolines, kprobe slots and other dynamically allocated text; this + * deliberately does not ask is_ftrace_trampoline() and friends, since + * text being torn down may already be unregistered there); + * - the .text..rcu_tramp section, C glue called directly from such + * trampolines before it has entered the reader; + * - whatever the architecture adds via arch_rcu_tasks_trampoline_text(). + * + * A false positive only makes the task a holdout until its next quiescent + * event. Called with interrupts disabled from the irq-exit path. + */ +bool rcu_tasks_trampoline_text(unsigned long ip) +{ + if (core_kernel_text(ip)) { + if (ip >= (unsigned long)__rcu_tramp_text_start && + ip < (unsigned long)__rcu_tramp_text_end) + return true; + return arch_rcu_tasks_trampoline_text(ip); + } + return !is_module_text_address(ip); +} +NOKPROBE_SYMBOL(rcu_tasks_trampoline_text); + +/* Note a Tasks RCU quiescent event on this CPU. */ +static void rcu_tasks_qs_event(void) +{ + unsigned long *seq; + + guard(preempt_notrace)(); + seq = this_cpu_ptr(&rcu_tasks_qs_seq); + /* Order a preceding rcu_tasks_tramp_hold() before the count. */ + smp_store_release(seq, *seq + 1); +} + +static void rcu_tasks_tramp_hold(struct task_struct *t) +{ + unsigned long flags; + + if (t->rcu_tasks_holdout) + return; + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); + list_add_tail(&t->rcu_tasks_holdout_list, &rcu_tasks_tramp_holdouts); + WRITE_ONCE(t->rcu_tasks_holdout, true); + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); +} + +static void rcu_tasks_tramp_release(struct task_struct *t) +{ + unsigned long flags; + + if (likely(!t->rcu_tasks_holdout)) + return; + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); + list_del_init(&t->rcu_tasks_holdout_list); + WRITE_ONCE(t->rcu_tasks_holdout, false); + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); +} + +/** + * rcu_tasks_irq_resched_enter - Tasks RCU hook for the irq-exit reschedule check + * @ip: instruction pointer of the interrupted (task-level) context + * + * Called with interrupts disabled when an interrupt returning to kernel + * mode is about to preempt_schedule_irq(), the one context switch that can + * catch a task inside unmarked trampoline text. Record where the task is + * parked for as long as it is (rcu_tasks_wait_irq_preempted() looks at + * that), and if it is inside such text make it a holdout before + * __schedule() reports the quiescent event; if it is not, this is as good + * as a voluntary switch for ending an earlier hold. + */ +void rcu_tasks_irq_resched_enter(unsigned long ip) +{ + struct task_struct *t = current; + struct rcu_tasks_percpu *rtpcp = this_cpu_ptr(rcu_tasks.rtpcpu); + + lockdep_assert_irqs_disabled(); + WRITE_ONCE(t->rcu_tasks_irq_ip, ip); + t->rcu_tasks_exit_cpu = smp_processor_id(); + raw_spin_lock_rcu_node(rtpcp); + list_add(&t->rcu_tasks_exit_list, &rtpcp->rtp_exit_list); + raw_spin_unlock_rcu_node(rtpcp); + + if (unlikely(rcu_tasks_trampoline_text(ip))) + rcu_tasks_tramp_hold(t); + else + rcu_tasks_tramp_release(t); +} +NOKPROBE_SYMBOL(rcu_tasks_irq_resched_enter); + +/** + * rcu_tasks_irq_resched_exit - preempt_schedule_irq() has returned + * + * The task is running again (possibly elsewhere) and about to return to the + * interrupted context; it is no longer parked anywhere. + */ +void rcu_tasks_irq_resched_exit(void) +{ + struct task_struct *t = current; + struct rcu_tasks_percpu *rtpcp = per_cpu_ptr(rcu_tasks.rtpcpu, t->rcu_tasks_exit_cpu); + + lockdep_assert_irqs_disabled(); + raw_spin_lock_rcu_node(rtpcp); + list_del_init(&t->rcu_tasks_exit_list); + raw_spin_unlock_rcu_node(rtpcp); + WRITE_ONCE(t->rcu_tasks_irq_ip, 0); +} +NOKPROBE_SYMBOL(rcu_tasks_irq_resched_exit); + +/** + * rcu_tasks_note_qs - Tasks RCU hook for a context switch or explicit QS + * @t: current + * @preempt: this is a preemption rather than a voluntary switch + * + * Every pass through __schedule() (and cond_resched_tasks_rcu_qs(), and a + * tick from userspace or idle) is a quiescent event for this CPU: unmarked + * trampoline text never calls anything that schedules, and the irq-exit + * path has already made @t a holdout if it is preempting inside such text. + * Any of these outside an irq-exit preemption also shows @t itself to be + * outside, ending an earlier hold -- including cond_resched() under + * PREEMPT_DYNAMIC's none/voluntary modes, where the irq-exit path is off. + */ +void rcu_tasks_note_qs(struct task_struct *t, bool preempt) +{ + WARN_ON_ONCE(t != current); + if (!READ_ONCE(t->rcu_tasks_irq_ip)) + rcu_tasks_tramp_release(t); + rcu_tasks_qs_event(); +} +EXPORT_SYMBOL_GPL(rcu_tasks_note_qs); /* cond_resched_tasks_rcu_qs() */ + +/** + * rcu_tasks_wait_irq_preempted - wait for tasks irq-preempted inside @inside + * @inside: predicate on a task's recorded irq-exit preemption IP + * + * For a caller about to make some ordinary text unsafe to be parked in + * (the kprobe jump optimizer): once the caller has arranged for + * rcu_tasks_trampoline_text() to cover that text, new irq-exit preemptions + * there become holdouts, but a task preempted there earlier is invisible + * to the grace period. Wait until no parked task's recorded preemption IP + * is inside; a following synchronize_rcu_tasks() then covers the rest. + * The leading synchronize_rcu() orders the caller's arrangement against + * preemptions in flight, which run with interrupts disabled. + */ +void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)) +{ + struct task_struct *t; + unsigned long flags; + int cpu, kick; + bool found; + + synchronize_rcu(); + for (;;) { + found = false; + for_each_possible_cpu(cpu) { + struct rcu_tasks_percpu *rtpcp = per_cpu_ptr(rcu_tasks.rtpcpu, cpu); + + kick = -1; + raw_spin_lock_irqsave_rcu_node(rtpcp, flags); + list_for_each_entry(t, &rtpcp->rtp_exit_list, rcu_tasks_exit_list) { + if (inside(READ_ONCE(t->rcu_tasks_irq_ip))) { + found = true; + if (task_curr(t)) + kick = task_cpu(t); + } + } + raw_spin_unlock_irqrestore_rcu_node(rtpcp, flags); + if (kick >= 0) + resched_cpu(kick); + } + if (!found) + return; + schedule_timeout_uninterruptible(1); + } +} + +/* Has @cpu passed a quiescent event since the snapshot, or need it not? */ +static bool rcu_tasks_cpu_quiescent(int cpu) +{ + if (!cpu_online(cpu)) + return true; + /* Pairs with the release in rcu_tasks_qs_event(). */ + if (smp_load_acquire(per_cpu_ptr(&rcu_tasks_qs_seq, cpu)) != + per_cpu(rcu_tasks_qs_snap, cpu)) + return true; + /* + * Idle or nohz_full userspace (an RCU extended quiescent state): no + * task-level kernel frames there, and whatever ran before has switched + * out. As with the classic flavor, the idle task itself is not waited + * for. + */ + if (!(ct_rcu_watching_cpu(cpu) & CT_RCU_WATCHING)) + return true; + return idle_cpu(cpu); +} + +/* Rate-limited stall report; returns true if the caller should add detail. */ +static bool rcu_tasks_tramp_stall(struct rcu_tasks *rtp, unsigned long *lastreport, + const char *what) +{ + int rtst = READ_ONCE(rcu_task_stall_timeout); + + if (rtst <= 0 || !time_after(jiffies, *lastreport + rtst)) + return false; + *lastreport = jiffies; + pr_err("INFO: %s: %s, grace period %lu is %lu jiffies old\n", rtp->kname, + what, rcu_seq_current(&rtp->tasks_gp_seq), jiffies - rtp->gp_start); + return true; +} + +/* + * Steps 1/4: wait until every online non-idle CPU has context switched. A + * CPU that has not after a jiffy is asked to with resched_cpu(), which takes + * it through rcu_tasks_irq_resched_enter() and __schedule() (or, from + * userspace or a guest, straight to __schedule()). + */ +static void rcu_tasks_tramp_wait_cpus(struct rcu_tasks *rtp, unsigned long *lastreport) +{ + struct cpumask *pending = &rcu_tasks_pending_cpus; + unsigned long start; + int cpu; + + /* + * The quiescent events run with preemption (in practice interrupts) + * disabled, so after this any event we go on to count began after the + * caller's updates -- the unpublished trampoline, and whatever + * rcu_tasks_trampoline_text() consults -- were visible to it. + */ + synchronize_rcu(); + + start = jiffies; + for_each_online_cpu(cpu) { + per_cpu(rcu_tasks_qs_snap, cpu) = READ_ONCE(per_cpu(rcu_tasks_qs_seq, cpu)); + __cpumask_set_cpu(cpu, pending); + } + /* Snapshots before the checks below; pairs with rcu_tasks_qs_event(). */ + smp_mb(); + + for (;;) { + for_each_cpu(cpu, pending) + if (rcu_tasks_cpu_quiescent(cpu)) + __cpumask_clear_cpu(cpu, pending); + if (cpumask_empty(pending)) + break; + if (time_after(jiffies, start)) { + for_each_cpu(cpu, pending) + resched_cpu(cpu); + rtp->n_ipis += cpumask_weight(pending); + } + schedule_timeout_idle(1); + if (rcu_tasks_tramp_stall(rtp, lastreport, "CPUs without a quiescent event")) + pr_err("\tCPUs: %*pbl\n", cpumask_pr_args(pending)); + } +} + +/* + * Steps 2/4: wait for the tasks that were holdouts when we looked to stop + * being holdouts. They are moved to a private list so that tasks becoming + * holdouts later (in live trampolines) cannot keep us here; each removes + * itself via rcu_tasks_tramp_release() wherever it is queued. + */ +static void rcu_tasks_tramp_wait_holdouts(struct rcu_tasks *rtp, unsigned long *lastreport) +{ + struct task_struct *t; + unsigned long flags; + int cpu; + + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); + list_splice_tail_init(&rcu_tasks_tramp_holdouts, &rcu_tasks_gp_holdouts); + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); + + for (;;) { + struct cpumask *kick = &rcu_tasks_pending_cpus; + struct task_struct *show[8]; + int nshow = 0, i; + bool empty, report; + + report = rcu_tasks_tramp_stall(rtp, lastreport, + "tasks preempted in trampoline text"); + cpumask_clear(kick); + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); + empty = list_empty(&rcu_tasks_gp_holdouts); + list_for_each_entry(t, &rcu_tasks_gp_holdouts, rcu_tasks_holdout_list) { + if (task_curr(t)) + __cpumask_set_cpu(task_cpu(t), kick); + if (report && nshow < ARRAY_SIZE(show)) + show[nshow++] = get_task_struct(t); + } + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); + /* Never printk under the lock the irq-exit path takes. */ + for (i = 0; i < nshow; i++) { + sched_show_task(show[i]); + put_task_struct(show[i]); + } + if (empty) + break; + for_each_cpu(cpu, kick) + resched_cpu(cpu); + rtp->n_ipis += cpumask_weight(kick); + schedule_timeout_idle(1); + } +} + +/* Wait for one trampoline-reader Tasks RCU grace period. */ +static void rcu_tasks_tramp_wait_gp(struct rcu_tasks *rtp) +{ + unsigned long lastreport = jiffies; + + set_tasks_gp_state(rtp, RTGS_WAIT_SCAN_HOLDOUTS); + rcu_tasks_tramp_wait_cpus(rtp, &lastreport); + rcu_tasks_tramp_wait_holdouts(rtp, &lastreport); + + set_tasks_gp_state(rtp, RTGS_WAIT_READERS); + synchronize_rcu_tasks_trace(); + + set_tasks_gp_state(rtp, RTGS_SCAN_HOLDOUTS); + rcu_tasks_tramp_wait_cpus(rtp, &lastreport); + rcu_tasks_tramp_wait_holdouts(rtp, &lastreport); + + set_tasks_gp_state(rtp, RTGS_POST_GP); +} + +static int __init rcu_spawn_tasks_kthread(void) +{ + rcu_tasks.gp_sleep = HZ / 10; + if (rcu_tasks_lazy_ms >= 0) + rcu_tasks.lazy_jiffies = msecs_to_jiffies(rcu_tasks_lazy_ms); + rcu_tasks.wait_state = TASK_IDLE; + rcu_spawn_tasks_kthread_generic(&rcu_tasks); + return 0; +} + +void exit_tasks_rcu_start(void) { } +void exit_tasks_rcu_finish(void) { } + +#else /* #ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ + //////////////////////////////////////////////////////////////////////// // // Simple variant of RCU whose quiescent states are voluntary context @@ -1173,6 +1608,8 @@ static void tasks_rcu_exit_stall(struct timer_list *unused) #endif // #ifndef CONFIG_TINY_RCU } +#endif /* #else #ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ + /** * call_rcu_tasks() - Queue an RCU for invocation task-based grace period * @rhp: structure to be used for queueing the RCU updates. @@ -1187,6 +1624,12 @@ static void tasks_rcu_exit_stall(struct timer_list *unused) * primitives analogous to rcu_read_lock() and rcu_read_unlock() because * this primitive is intended to determine that all tasks have passed * through a safe state, not so much for data-structure synchronization. + * On CONFIG_TASKS_RCU_TRAMPOLINE_READERS kernels a preemption outside + * trampoline text also ends one, and a reader whose protected window + * spans preemptible code must additionally be a Tasks Trace RCU reader + * (rcu_read_lock_trace(), as the trampolines there take around their + * call-outs); an arbitrary stretch of preemptible kernel code is not + * protected. * * See the description of call_rcu() for more detailed information on * memory ordering guarantees. @@ -1205,7 +1648,9 @@ EXPORT_SYMBOL_GPL(call_rcu_tasks); * executing rcu-tasks read-side critical sections have elapsed. These * read-side critical sections are delimited by calls to schedule(), * cond_resched_tasks_rcu_qs(), idle execution, userspace execution, calls - * to synchronize_rcu_tasks(), and (in theory, anyway) cond_resched(). + * to synchronize_rcu_tasks(), and (in theory, anyway) cond_resched(); + * on CONFIG_TASKS_RCU_TRAMPOLINE_READERS kernels also by preemption + * outside trampoline text, see call_rcu_tasks(). * * This is a very specialized primitive, intended only for a few uses in * tracing and other situations requiring manipulation of function @@ -1233,9 +1678,7 @@ void rcu_barrier_tasks(void) } EXPORT_SYMBOL_GPL(rcu_barrier_tasks); -static int rcu_tasks_lazy_ms = -1; -module_param(rcu_tasks_lazy_ms, int, 0444); - +#ifndef CONFIG_TASKS_RCU_TRAMPOLINE_READERS static int __init rcu_spawn_tasks_kthread(void) { rcu_tasks.gp_sleep = HZ / 10; @@ -1251,6 +1694,7 @@ static int __init rcu_spawn_tasks_kthread(void) rcu_spawn_tasks_kthread_generic(&rcu_tasks); return 0; } +#endif /* #ifndef CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ #if !defined(CONFIG_TINY_RCU) void show_rcu_tasks_classic_gp_kthread(void) @@ -1279,6 +1723,7 @@ void rcu_tasks_get_gp_data(int *flags, unsigned long *gp_seq) } EXPORT_SYMBOL_GPL(rcu_tasks_get_gp_data); +#ifndef CONFIG_TASKS_RCU_TRAMPOLINE_READERS /* * Protect against tasklist scan blind spot while the task is exiting and * may be removed from the tasklist. Do this by adding the task to yet @@ -1322,6 +1767,7 @@ void exit_tasks_rcu_finish(void) list_del_init(&t->rcu_tasks_exit_list); raw_spin_unlock_irqrestore_rcu_node(rtpcp, flags); } +#endif /* #ifndef CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ #else /* #ifdef CONFIG_TASKS_RCU */ void exit_tasks_rcu_start(void) { } diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index b62735a67884..a122b8d1effb 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -40,7 +40,9 @@ #include #include #include +#include #include +#include #include #include #include -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:17:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:17:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421708.1647422 (Exim 4.92) (envelope-from ) id 1x6T2r-00050C-Ef; Tue, 15 Sep 2026 13:17:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421708.1647422; Tue, 15 Sep 2026 13:17:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2r-0004yu-Ay; Tue, 15 Sep 2026 13:17:57 +0000 Received: by outflank-mailman (input) for mailman id 1421708; Tue, 15 Sep 2026 13:17:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2q-0004tp-1c for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:17:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2p-00EG9J-Dv for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:17:55 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9457b-bab6-0a2a0a5309dd-0a2a4503e980-14 for ; Tue, 15 Sep 2026 15:17:55 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94582-fae8-0a2a45030019-4a7de6ccce25-3 for ; Tue, 15 Sep 2026 15:17:55 +0200 Received: by mail-qk2-f12.google.com with SMTP id d75a77b69052e-52fb76906adso46626251cf.0 for ; Tue, 15 Sep 2026 06:17:55 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530ca4ba156sm126369461cf.19.2026.09.15.06.17.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:17:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478274; x=1790083074; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=zOBWKoOt8czuTeNdTxDxvLfMht4h54WO3jEdwibwnr4=; b=NqEVb7HrEnHrZA5W2qxk+nVH6z+qq08zjTm0pTrJJzvNRuBXta3K9r7d0mHCxGt+TV 2TV7DFHol2TC2OJt/KpByH24qiIEx3VyMpr6TZx0Si8mfDa2x5lU/pEp/UDs/vlzg/1d ObALVskR2C8G29X5BT8NQmzxpKu5zHt/v9GZTOI0U4ydA9upCBL9uyA1aWXv7HAwlgdA QSFZRF1fFT4SAmXKrXmdQtFcsEQ3kUWAr3oBeLT9OMrqZEpsjiYR8nUJ4Z0R2rcKh8TR kQGDw4jCp8crnP9YwLrOYuU9gStKk+ETPCfDNrfbZUTynhIlRBphoneCL8IT2CgX3MKC OzXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478274; x=1790083074; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zOBWKoOt8czuTeNdTxDxvLfMht4h54WO3jEdwibwnr4=; b=EamyQS2PpCQXPpPQ/kj0eHsG8GTAa4AXpqU0+fr2W+yRG9XOE5cRjwppPlEbqKpRgx phx+KhjoutFHhL/z4bHS2WsUm6l6zDcRCA6TtA1icBMp02rP/g+YLHoH+ayFCQXp4buP rA4PSwg54nbiiZ8UoOCmu0gIbtxFEok8zy0GPHkl3bLbe7xxH1IDM1IzrEtm1Zg0mGUY 1aE/PEHbOeMo37ZMvNP0OWPi/ex8ETl6nas89i0sX1BMvHL4jmXJ2ORT6B1cQIQk8+M9 Aj+kAIU1mWDMwn8yIrxR1C7B02JVKcOi8t7l9mjGrCm27V3b0E8FJNWYq6QSc3cr7e0K FqNw== X-Forwarded-Encrypted: i=1; AKwUvBzAIqCXTH4APV9mDA0vamYLLwfsdVAFh4XjrbCVY4nhug0rSP1W9mtex7WCTpxTutHoMzm/Pn/FtWc=@lists.xenproject.org X-Gm-Message-State: AFuF++nPNT29Kp5WvjisUOvxQK0QfyJbMCM0fI6GKUyMJWafXnSmMoG4 F1oNW31qb/5700hXTK8nzvsykLhfiPy7wLFKgliNU+D6FHGkUVG0DleBxTbmQjrjIiM= X-Gm-Gg: AYBFou2Iczvmt9SQ4rsh/jknC9G1r0UB0gCiWFpCWvYQHecnrDerD1Y0e/HNAp7xtLD TfoeuKMIizMwbaXns+BjSKuH8HSB9O2mX+2jOS4XG/s9G6C4RRoxsXQYFvuhNRaibcTjOpBOFdP +O2iKzO3aLjIhmrepZgH6W0+WK3lF5cxTjGWGfJw75iaAwc4puVekDBT6+hOVaoSodh0Ytj/BPC 1z2KSKfJMmIfAF8IN7ama0U0b7pJsAvdf62XPD2qY8zKwQ4Q3y6c+nRVdU9R7WhPUhcNPlco/jw DdKkRYBM/KsvvWlRGNb9P5nMRku8M0ChD0mTNIwwUY8SVvh+ifZZW5kNLidXDwy553x7a+ZMDwq Je+cTXXj/VJB8s+hyXcO6S+nRMvJbD+YRRyHUDxEZW/Oxc+jxtasnK5MG2cQglHG6njhbyyBFf8 lPKAIj1AWTWRuo3vz04/sjBZE/cfv45BLpuZljnJSBhnXiQEyhK4l9nfwjPe64SISiILNZ18NZ6 IIPzrkzBkjsrNoKUfmEN74oMQ4IsNUs7bAKiDceWNb96Rzw8K4/tDd0 X-Received: by 2002:a05:622a:1646:b0:530:9bb:54ae with SMTP id d75a77b69052e-5310cf32770mr102643101cf.15.1789478273513; Tue, 15 Sep 2026 06:17:53 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:31 +0000 Subject: [PATCH RFC v3 04/13] kprobes: Expose the optprobe jump window to Tasks RCU MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-4-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=7478; i=josef@toxicpanda.com; h=from:subject:message-id; bh=2gqgm31o9vakOy6+NG5dFQrZfNnO16Cyr1QKmdk48dg=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QFs4wUTmA5uBGNzmizfs5h8i2jZ+BJEC+ZKMMB4U6RQcjTiVVDPqXAZ9evZNBFK/JcfouDSMfSj BhbWSxMKT7As= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-33051d/1789478275-6C8DD4E9-C8161ED8/0/0 X-purgate-type: clean X-purgate-size: 7480 kprobe_optimizer() is the one synchronize_rcu_tasks() user that is not about trampoline text: it waits for tasks that were interrupted on an instruction boundary inside the bytes it is about to overwrite with the optimized jump, so that none of them resumes into the middle of the new instruction. Those bytes are ordinary kernel or module text with no Tasks Trace reader around them, so on CONFIG_TASKS_RCU_TRAMPOLINE_READERS kernels the irq-exit quiescent-state check has to be told about them. Add kprobe_in_optimized_region(), a lockless and conservative form of get_optimized_kprobe() that reports whether any registered kprobe lies within MAX_OPTIMIZED_LENGTH before the given address regardless of its optimization state, and have rcu_tasks_trampoline_text() consult it for core and module text so that a task interrupted there becomes a holdout rather than a quiescent event. The hash walk only runs while kprobe_optimizer() is actually inside its synchronize_rcu_tasks(), tracked by a flag it sets around the call; otherwise the check is a single load. That check cannot see a task that was already preempted in the region before the flag went up (possibly before the kprobe even existed), and the new grace period does not otherwise wait for a preempted task to run again, so before synchronize_rcu_tasks() the optimizer calls rcu_tasks_wait_irq_preempted() to wait until no parked task's recorded irq-exit preemption IP is inside such a region; its leading synchronize_rcu() also publishes the flag to every (interrupts- disabled) check in flight. The kprobe hash is RCU-protected and every free path waits for a grace period after unhashing, so the lockless walk from the irq-exit path is safe. On other configurations the flag is set and cleared but nothing reads it and rcu_tasks_wait_irq_preempted() is a stub; the classic implementation already waits for such tasks. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/kprobes.h | 8 +++++++- kernel/kprobes.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++ kernel/rcu/tasks.h | 11 ++++++++--- 3 files changed, 65 insertions(+), 4 deletions(-) diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h index e6de7ae55bda..74cc48c04417 100644 --- a/include/linux/kprobes.h +++ b/include/linux/kprobes.h @@ -530,11 +530,17 @@ static inline bool is_kprobe_insn_slot(unsigned long addr) } #endif /* !CONFIG_KPROBES */ -#ifndef CONFIG_OPTPROBES +#ifdef CONFIG_OPTPROBES +bool kprobe_in_optimized_region(unsigned long addr); +#else /* !CONFIG_OPTPROBES */ static inline bool is_kprobe_optinsn_slot(unsigned long addr) { return false; } +static inline bool kprobe_in_optimized_region(unsigned long addr) +{ + return false; +} #endif /* !CONFIG_OPTPROBES */ #ifdef CONFIG_KRETPROBES diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 6337da5cab9e..e460fba83e4a 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -511,6 +511,48 @@ static struct kprobe *get_optimized_kprobe(kprobe_opcode_t *addr) return NULL; } +/* + * True while kprobe_optimizer() is waiting for its Tasks RCU grace period. + * Only in that window can an interruption inside an optprobe's jump region + * matter to it, so kprobe_in_optimized_region() does no work otherwise. + */ +static bool kprobe_optimizer_waiting; + +/** + * kprobe_in_optimized_region - Could @addr be inside bytes a jump-optimized + * kprobe replaces? + * @addr: kernel text address, typically an interrupted instruction pointer + * + * kprobe_optimizer() relies on synchronize_rcu_tasks() to wait for tasks that + * were interrupted on an instruction boundary inside the region about to be + * overwritten by the optimized jump. Where Tasks RCU is built on + * reader-marked trampolines that region has no reader, so the irq-exit + * quiescent-state check asks this instead (see rcu_tasks_trampoline_text()). + * This is the lockless, conservative form of get_optimized_kprobe(): it does + * not care whether the kprobe found is, or ever will be, optimized. May be + * called from any context with preemption disabled; the kprobe hash is + * RCU-protected and every free path waits for a grace period after unhashing. + * + * The hash walk only runs while the optimizer is actually waiting. A task + * that was preempted in such a region before the flag went up is invisible + * to that check, so the optimizer first waits those out by their recorded + * preemption IP (rcu_tasks_wait_irq_preempted(), whose leading + * synchronize_rcu() also publishes the flag to every check in flight). + */ +bool kprobe_in_optimized_region(unsigned long addr) +{ + int i; + + if (!READ_ONCE(kprobe_optimizer_waiting)) + return false; + + for (i = 1; i < MAX_OPTIMIZED_LENGTH / sizeof(kprobe_opcode_t); i++) + if (get_kprobe((kprobe_opcode_t *)addr - i)) + return true; + return false; +} +NOKPROBE_SYMBOL(kprobe_in_optimized_region); + /* Optimization staging list, protected by 'kprobe_mutex' */ static LIST_HEAD(optimizing_list); static LIST_HEAD(unoptimizing_list); @@ -644,8 +686,16 @@ static void kprobe_optimizer(void) * to 2nd-Nth byte of jump instruction. This wait is for avoiding it. * Note that on non-preemptive kernel, this is transparently converted * to synchronoze_sched() to wait for all interrupts to have completed. + * kprobe_optimizer_waiting lets a reader-marked-trampoline Tasks RCU + * recognise tasks interrupted in such a region while we wait, and + * rcu_tasks_wait_irq_preempted() (a no-op elsewhere) first waits + * out any that were preempted there before we said so; see + * kprobe_in_optimized_region(). */ + WRITE_ONCE(kprobe_optimizer_waiting, true); + rcu_tasks_wait_irq_preempted(kprobe_in_optimized_region); synchronize_rcu_tasks(); + WRITE_ONCE(kprobe_optimizer_waiting, false); /* Step 3: Optimize kprobes after quiesence period */ do_optimize_kprobes(); diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 3a7c092361a6..866768462850 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1006,7 +1006,9 @@ bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) * text being torn down may already be unregistered there); * - the .text..rcu_tramp section, C glue called directly from such * trampolines before it has entered the reader; - * - whatever the architecture adds via arch_rcu_tasks_trampoline_text(). + * - whatever the architecture adds via arch_rcu_tasks_trampoline_text(); + * - the bytes after a kprobe that a pending jump optimization is about to + * overwrite, the one synchronize_rcu_tasks() user with no trampoline. * * A false positive only makes the task a holdout until its next quiescent * event. Called with interrupts disabled from the irq-exit path. @@ -1017,9 +1019,12 @@ bool rcu_tasks_trampoline_text(unsigned long ip) if (ip >= (unsigned long)__rcu_tramp_text_start && ip < (unsigned long)__rcu_tramp_text_end) return true; - return arch_rcu_tasks_trampoline_text(ip); + return arch_rcu_tasks_trampoline_text(ip) || + kprobe_in_optimized_region(ip); } - return !is_module_text_address(ip); + if (is_module_text_address(ip)) + return kprobe_in_optimized_region(ip); + return true; } NOKPROBE_SYMBOL(rcu_tasks_trampoline_text); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421709.1647436 (Exim 4.92) (envelope-from ) id 1x6T2u-0005QW-P8; Tue, 15 Sep 2026 13:18:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421709.1647436; Tue, 15 Sep 2026 13:18:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2u-0005QI-Kt; Tue, 15 Sep 2026 13:18:00 +0000 Received: by outflank-mailman (input) for mailman id 1421709; Tue, 15 Sep 2026 13:17:59 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2t-0005NY-8s for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:17:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2s-00DQRf-Lp for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:17:58 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94581-e002-0a2a0a5209dd-0a2a45099780-36 for ; Tue, 15 Sep 2026 15:17:58 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94585-be1a-0a2a45090019-4a7de68ca160-3 for ; Tue, 15 Sep 2026 15:17:58 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-90cdfc9b6eeso34079826d6.0 for ; Tue, 15 Sep 2026 06:17:58 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f45a780sm120563676d6.10.2026.09.15.06.17.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:17:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478277; x=1790083077; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=N2aqKzOffwJC2uJ3O0Ky+yGqpaXXawvJtULMY2mEOoI=; b=LXtDBQP/6dEP0Lzvw94Zy3SApKxl1v9IYOvwpA7VnJ1VS3CoNbZTr6HNJCvkfkuUJJ 3Z0e7gV4mouR3AwZBTDMVY41b2qK2iu2SkiLxWKegxCzSHhPB04BaEm/kMqlB04DwEpG Hci7xMJ/MCjAfi77PpldnH906nfVov5UQbqt9tyQws/MqG7TXCSKQ8Hjft/gHV+TMAzb Q3Y1b7XeIuNHqOMzVsFRQ2G2TkbQYdhlbQLO1vKYx3HZ3eyByr9vY8MYvS2wvo3JrDPL 4jFSSD0efqxLz8uSfScs/Wn8GdIKakZ1fBSEcXXaGYwgGavw3RApehCW7ipd6EIZDrQF i6vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478277; x=1790083077; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=N2aqKzOffwJC2uJ3O0Ky+yGqpaXXawvJtULMY2mEOoI=; b=0yvdNvpw7AufpRQ/N9JLEH9PGRtQrikytyo5AeciLToyHA1bqu/eWc60sAsProC9yk fYtJtpI5db0WAKGydA1Kqq7JxJLEaMdVGBCmbHt3QF5OFAyRa2te7oIzLh2pPbqjlHKl 8tws7hdch15TIDpUnYhhT7lVmUB9JAw2LHPWMLHWBjJ9vRyjKJGbyn2I84abxFfZlH45 fs+2qGyBC2zB1H/k2foJUoM38yga5ORqXnAP/DAHx/vWF2ddx6nG/9wu8ME50iGP9qB5 FBuzV5++UE1xT7Vjmot/DoIhJdDvMffdK6QITKpt5Ckb7pyBSpoH7lQIc0UaYJSD4FCE jUIA== X-Forwarded-Encrypted: i=1; AKwUvBxKDND3YEPTWDWDlK4aPB5uLjex1meR97oDtym1NXGqmG1Bu3rVyeSlzhOlm6VMj19zI+H6DdOcILk=@lists.xenproject.org X-Gm-Message-State: AFuF++kC/6vq8vYRJbJ1O+WmM//LWVOaSlvZ+KVmMmnCkcBMgKo6C8TJ +zifRq/LlS4Nacw7IrWRxN2+P9PeipuaBDeapXfpPIu++dte348mMc07mQuoGtz6TZ4= X-Gm-Gg: AYBFou1tqz8Z2TQCIlgVcsqS1MHz4tmeetVDACerFLY4qDCH7BrLB4B5jJ74n51JSoA k5IGamoqdyYdGZ4CPwKbQdnLHUJV5I9+pQqCiWCN/J+MoLAQ9ioDxdqA4qTkKwn7vC+Izj7iJRL +v4FqjnRCp+lmv3Ryad8RHDlWiXX5Wp2+vk8stVXgUSEiO1De2UxYfmxklkpukMTPztwno953PR qWBv32KrM01QFUYGLlQutyaIDmEn/jQ0Vjdt2ZcGTaC7fGCO0dwbzDhzGIcNxb7v961lkQxaYWw +sjoXJp8ARuvyeiUUATIQkwoMLAy5/RWf7up/hfnWOlRG5R3ZPERBetWZ2x4a7O+Tbiv0xCj3ku MM+Z+OvDja8n73bhsgDH0T039WTvyHK1Ocz2w+bSJ8LXDKg9MvyS8dbZwjpAP4DeVb4+ZhjEucm vhaHOnFBueCcCqit6BnYkZdH6lsdCRGM9A4tUZLQv93en3l9qunvjY99xZczVvQot1yY6qupZcQ rW7drtxbklBIAH/+q46FUfR9aHSsrMVHXTIGMife9ewxu14dbt2VGzhHIqA7w3pxG4= X-Received: by 2002:a05:6214:4285:b0:90e:873f:112b with SMTP id 6a1803df08f44-9122e51912amr113387396d6.16.1789478276555; Tue, 15 Sep 2026 06:17:56 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:32 +0000 Subject: [PATCH RFC v3 05/13] ftrace: Mark modules hosting direct-call trampolines for Tasks RCU MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-5-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=7194; i=josef@toxicpanda.com; h=from:subject:message-id; bh=Fqdt5J86rRS/oaPi1G1Rp34bXnNDaywOKyZCOJUFY5s=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QFK/UccVcmZvo9+nJV8bUtDnpQLusVqacik5jCxxwwehteVs8AbBeSvZttSzdRt3+dA+Fv7F8p7 qiOCn2ZKvEwc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-bad1c0/1789478278-3ACDF034-7F26B264/0/0 X-purgate-type: clean X-purgate-size: 7196 An out-of-line direct trampoline registered with register_ftrace_direct() is kept alive only by Tasks RCU while a task executes it or is preempted in something it called; ftrace_shutdown()'s synchronize_rcu_tasks() is what stops rmmod freeing it under such a task. Where Tasks RCU is built on reader-marked trampolines, such a trampoline must be a Tasks Trace reader across its call-out like the ftrace and BPF trampolines are, so document that in register_ftrace_direct(). That still leaves the few instructions before the reader is entered and after it is left. For BPF images those are in dynamically allocated text that rcu_tasks_trampoline_text() already treats as unmarked trampoline text, but the in-tree samples (and any similar user) place their trampolines in module .text. Add a sticky module::ftrace_direct_tramp flag, set by every register/modify path when the direct address is module text, and have rcu_tasks_trampoline_text() treat a task interrupted anywhere in such a module as a potential holdout. Other modules' text is unaffected. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/module.h | 7 +++++++ kernel/rcu/tasks.h | 21 ++++++++++++++++++--- kernel/trace/ftrace.c | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 3 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 96cc98568eea..28488687cb01 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -521,6 +521,13 @@ struct module { unsigned int num_ftrace_callsites; unsigned long *ftrace_callsites; #endif +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS + /* + * An ftrace direct-call trampoline lives in this module's text; see + * rcu_tasks_trampoline_text(). Sticky once set. + */ + bool ftrace_direct_tramp; +#endif #ifdef CONFIG_KPROBES void *kprobes_text_start; unsigned int kprobes_text_size; diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 866768462850..ec54a27e47fa 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1007,6 +1007,8 @@ bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) * - the .text..rcu_tramp section, C glue called directly from such * trampolines before it has entered the reader; * - whatever the architecture adds via arch_rcu_tasks_trampoline_text(); + * - the text of a module that hosts an out-of-line ftrace direct-call + * trampoline (see ftrace_direct_mark_module()); * - the bytes after a kprobe that a pending jump optimization is about to * overwrite, the one synchronize_rcu_tasks() user with no trampoline. * @@ -1015,6 +1017,8 @@ bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) */ bool rcu_tasks_trampoline_text(unsigned long ip) { + bool ret = true; + if (core_kernel_text(ip)) { if (ip >= (unsigned long)__rcu_tramp_text_start && ip < (unsigned long)__rcu_tramp_text_end) @@ -1022,9 +1026,20 @@ bool rcu_tasks_trampoline_text(unsigned long ip) return arch_rcu_tasks_trampoline_text(ip) || kprobe_in_optimized_region(ip); } - if (is_module_text_address(ip)) - return kprobe_in_optimized_region(ip); - return true; + +#ifdef CONFIG_MODULES + scoped_guard(rcu) { + struct module *mod = __module_text_address(ip); + + if (mod) { + ret = kprobe_in_optimized_region(ip); +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS + ret = ret || READ_ONCE(mod->ftrace_direct_tramp); +#endif + } + } +#endif + return ret; } NOKPROBE_SYMBOL(rcu_tasks_trampoline_text); diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 53d5db60bfa5..efc4a518658a 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6076,6 +6076,29 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) ops->trampoline = 0; } +/* + * A direct trampoline may live in module text rather than in dynamically + * allocated text that rcu_tasks_trampoline_text() recognises on its own (see + * samples/ftrace/ftrace-direct*.c). The trampoline itself must be a Tasks + * Trace reader across its call-out (see register_ftrace_direct()); marking the + * owning module here covers the instructions before it enters that reader and + * after it leaves it, where a task interrupted in the module's text must not be + * counted as Tasks-RCU quiescent, so that ftrace_shutdown()'s + * synchronize_rcu_tasks() still keeps the module text from being freed under + * it. + */ +static void ftrace_direct_mark_module(unsigned long addr) +{ +#ifdef CONFIG_MODULES + struct module *mod; + + guard(rcu)(); + mod = __module_text_address(addr); + if (mod) + WRITE_ONCE(mod->ftrace_direct_tramp, true); +#endif +} + /** * register_ftrace_direct - Call a custom trampoline directly * for multiple functions registered in @ops @@ -6090,6 +6113,17 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) * and save the parameters of the function being traced, and restore them * (or inject new ones if needed), before returning. * + * Nothing but Tasks RCU keeps the trampoline at @addr alive while a task is + * executing it or is preempted in something it called. On architectures that + * select HAVE_RCU_TRAMPOLINE_READERS, Tasks RCU only waits for such a task if + * it is a Tasks Trace RCU reader, so the trampoline must enter one + * (rcu_read_lock_trace() or its assembly equivalent, see + * samples/ftrace/ftrace-direct.h) before calling out and leave it before + * returning, as the ftrace and BPF trampolines do. The few instructions + * before and after are covered by the irq-exit check: automatically for + * trampolines outside kernel and module text (e.g. BPF images), and via + * ftrace_direct_mark_module() for trampolines in module text. + * * Returns: * 0 on success * -EINVAL - The @ops object was already registered with this call or @@ -6169,6 +6203,7 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) ops->flags |= MULTI_FLAGS; ops->trampoline = FTRACE_REGS_ADDR; ops->direct_call = addr; + ftrace_direct_mark_module(addr); err = register_ftrace_function_nolock(ops); if (err) @@ -6237,6 +6272,8 @@ __modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) lockdep_assert_held_once(&direct_mutex); + ftrace_direct_mark_module(addr); + /* Enable the tmp_ops to have the same functions as the direct ops */ ftrace_ops_init(&tmp_ops); tmp_ops.func_hash = ops->func_hash; @@ -6419,6 +6456,7 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash) hlist_for_each_entry(entry, &hash->buckets[i], hlist) { if (__ftrace_lookup_ip(direct_functions, entry->ip)) goto out_unlock; + ftrace_direct_mark_module(entry->direct); } } @@ -6702,6 +6740,7 @@ int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, b tmp = __ftrace_lookup_ip(direct_hash, entry->ip); if (!tmp) continue; + ftrace_direct_mark_module(entry->direct); tmp->direct = entry->direct; } } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421712.1647445 (Exim 4.92) (envelope-from ) id 1x6T2z-0005m3-79; Tue, 15 Sep 2026 13:18:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421712.1647445; Tue, 15 Sep 2026 13:18:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2z-0005lk-3M; Tue, 15 Sep 2026 13:18:05 +0000 Received: by outflank-mailman (input) for mailman id 1421712; Tue, 15 Sep 2026 13:18:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2x-0005hh-By for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:18:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2w-00EGDb-On for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:18:02 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9458a-bab6-0a2a0a5309dd-0a2a450bc220-0 for ; Tue, 15 Sep 2026 15:18:02 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94589-b7e8-0a2a450b0019-4a7de68cbe17-3 for ; Tue, 15 Sep 2026 15:18:02 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-90cdfc9b6eeso34080786d6.0 for ; Tue, 15 Sep 2026 06:18:02 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f47afc2sm120542886d6.20.2026.09.15.06.17.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:17:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478281; x=1790083081; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=pPH1+eiN4EhHtK6rDK3I01/qZvQ6oNbinGntBhruq3Q=; b=pdegXvcXrGOGWkHIqK5XopTSUhhctMzmxlyvokwlDr+7V/9rH3cWwRiT0YvCzX+OQD qcVOgZXRFaNcM5cvxvIMB0SJUKpJ2ccZ/CVT9q3uFgU3ghpVz8VxMaTZy36HxERmVncK 01Ub9upahL+7BN2TpuMj8QwxtcCQWhGUIVXobhJhjP2WeywYzhES4KzwVT8+56Rmpcn/ ISjJ73Ivg6Cq+HOzitMKswnptvE2vLukFyTybUt85TQVDtB7f6OKlllbIOC2xompU4VP diil+2SrocO2vSWOWXf/Kyyfg2Y+zAoDKILdSCRvLG0rY7RiT5c0YzgLyUdK3hwipIik J4Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478281; x=1790083081; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=pPH1+eiN4EhHtK6rDK3I01/qZvQ6oNbinGntBhruq3Q=; b=hrffP7EnTbp4TMc6EBrOvskgssxmHqjjekIAmU2TuIEUu91u3maziXKUlAY1dCPsEd 7e5m8xTHxZjZwiMzLJUx+hK3G+Jzqp6es9s23yoNjU2aHItZzhQ59dlolJDAKqCvvmin a6itqTKRFAwoSoWywYjrIYG6+a5+BekKhsZhIBjLCsUwZwTOkRJ1VTTFBPSAggi3CFEY 17zeNri7x4ldWtiHnaoaLJVlLFNfIw9gAqiT/QbUFaDtilHn6yIaIEave3hvMgR7gfQZ 320nhpGD+bdsydHLdu7lMo6Dm3qSmTsUHnJ31/lXwjHJkn9JU0iz4oaXwTC260w+ypyy dIfQ== X-Forwarded-Encrypted: i=1; AKwUvBxkICOM4kvJIyMYcmETzPYoTturNX6Nvi2t5m8UcnoD3pE3KfVoAMm3ZMl/mlmgsPnDV+3rnpYvR20=@lists.xenproject.org X-Gm-Message-State: AFuF++lUSy0FVEP1MCXHFQWVlUn9rSRCUxkM6jYZA0DrTYFcvmtrdiKD YSmbvoLLRqSqgWfOaoB7yNBlBi2empzZ9v29xLiKvi6G+zqUPQwTbin5DUk2k1GjfskW4elFSSo vhgxeFk8PmA== X-Gm-Gg: AYBFou2eaHTTFmb7DbMAo09rh7DxT7GxXJNGkDM9MQfMQQ82suEtPna1xALFU3OxhAn JIySjHR7zusd5zTXnTFQ6fpNNr8KWPCIMWV2t8HGeuMDXDze3rei1wFPcxyThk6AYjnEn6E0wij ZtBkVoLNMUURkZtGaDzr3E8Lnt3rswh6MjK+04Oa9cYFP4kl5X9pvfkQbAMbiHwLz85IWU7k1PI Wx9pxkxF9ezsyNfetZ1BWhMWyMlXrDfG5ZFKPWmWdujArJ/EiXBT/klA/dwf7t8++KhgF6zxBFA XHH+Kqn/DWtGqBqIwfHcVdh2EVqJY0es6M1g+apDZFN8l3o+GNfJF3Us7aCbO5JVDk51wY97iih ZSnoY+I6LXo+xPatU6RFRUsJO6bZMzaOOQoTyuXRRO9IXp1zv4N9nyaVdferAtZ3LmdR5ub1LoB rTQOR+3aR4sQcM0KRPv0hfs4H0AtLcqhh8MoUNGurDscjRkhDkdp2FRzp5rjDjFjulG3nNR1Hhn mmimyi1FsrKsnAtXVZlqnUsyqVqfCAptXClhtQ2j9zRyOXEYoIlyCVC X-Received: by 2002:a0c:f40b:0:b0:907:dd19:fcb3 with SMTP id 6a1803df08f44-9122e55d2e0mr126180476d6.24.1789478280887; Tue, 15 Sep 2026 06:18:00 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:34 +0000 Subject: [PATCH RFC v3 07/13] x86/ftrace: Take a Tasks Trace reader around ftrace_caller's call-out MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-7-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=9964; i=josef@toxicpanda.com; h=from:subject:message-id; bh=EBgIXBiL5Z/I6XbFK2Nq9sAUVoT2dZ9k9OxjIjZChGA=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QJJZPzWCoHiGtBk3LJYNRCR9qGstVoSpG9sCCUThRLJ2AVjOv69KNmqUSOUhIKjcnlXv6dm2yvx k1FTR+gbuUgc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1789478282-194C39EA-1A4B1781/0/0 X-purgate-type: clean X-purgate-size: 9966 For HAVE_RCU_TRAMPOLINE_READERS the ftrace trampolines must be Tasks Trace RCU readers while they call out, since that -- and not the absence of a voluntary context switch -- is what synchronize_rcu_tasks() will wait for before ftrace_shutdown() frees a dynamic trampoline or its ops. Open-code rcu_read_lock_trace() and rcu_read_unlock_trace() in ftrace_caller and ftrace_regs_caller: bump current->trc_reader_nesting and, for the outermost reader, do the SRCU-fast per-CPU increment on rcu_tasks_trace_srcu_struct and stash the counter pointer in current->trc_reader_scp, exactly as the C inlines do (including the smp_mb() when CONFIG_TASKS_TRACE_RCU_NO_MB is not set). The lock sits before the function_trace_op load, because between that load and the call the ops pointer is protected only by Tasks RCU, and the unlock after the call returns. The sequences are inside the region that create_trampoline() copies for per-ops trampolines; their %rip-relative references are fixed up by text_poke_apply_relocation() like CALL_DEPTH_ACCOUNT's. %rax and %rcx are dead at both points. Two pieces of core text still run outside that reader while holding the address of a Tasks-RCU-protected trampoline they are about to enter: the static stubs themselves, whose direct-call tails keep a BPF trampoline address on the stack until the final RET, and, under CONFIG_MITIGATION_RETHUNK, the return thunk that RET expands to. Add an ftrace_static_tramp_end marker after ftrace_stub_direct_tramp and linker symbols around .text..__x86.return_thunk and .text..__x86.rethunk_safe, and provide arch_rcu_tasks_trampoline_text() covering [ftrace_caller, ftrace_static_tramp_end) and both thunk ranges so the irq-exit check treats a task interrupted there as a holdout. All of this is built only under CONFIG_TASKS_RCU_TRAMPOLINE_READERS, which x86 does not enable until a later patch. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/kernel/asm-offsets.c | 8 +++++ arch/x86/kernel/ftrace.c | 43 +++++++++++++++++++++++++++ arch/x86/kernel/ftrace_64.S | 69 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/vmlinux.lds.S | 4 +++ 4 files changed, 124 insertions(+) diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c index 081816888f7a..876c3986419a 100644 --- a/arch/x86/kernel/asm-offsets.c +++ b/arch/x86/kernel/asm-offsets.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -46,6 +47,13 @@ static void __used common(void) #ifdef CONFIG_STACKPROTECTOR OFFSET(TASK_stack_canary, task_struct, stack_canary); #endif +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + OFFSET(TASK_trc_reader_nesting, task_struct, trc_reader_nesting); + OFFSET(TASK_trc_reader_scp, task_struct, trc_reader_scp); + OFFSET(SRCU_srcu_ctrp, srcu_struct, srcu_ctrp); + OFFSET(SRCU_CTR_srcu_locks, srcu_ctr, srcu_locks); + OFFSET(SRCU_CTR_srcu_unlocks, srcu_ctr, srcu_unlocks); +#endif BLANK(); OFFSET(pbe_address, pbe, address); diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index 17d6edfcb7e0..9babaed483eb 100644 --- a/arch/x86/kernel/ftrace.c +++ b/arch/x86/kernel/ftrace.c @@ -275,6 +275,49 @@ static inline void tramp_free(void *tramp) execmem_free(tramp); } +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +extern void ftrace_static_tramp_end(void); +extern char __return_thunk_start[], __return_thunk_end[]; +extern char __rethunk_safe_start[], __rethunk_safe_end[]; + +/* + * The SRCU-fast increments in TRACE_RCU_READ_LOCK/UNLOCK (ftrace_64.S) are the + * this_cpu_inc() form. + */ +static_assert(!IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE)); + +/* + * See rcu_tasks_trampoline_text(). Some core kernel text behaves like a + * trampoline for Tasks RCU purposes because a task executing there outside + * any Tasks Trace reader may still be about to enter a Tasks-RCU-protected + * trampoline whose address it already holds: + * + * - the static ftrace_caller / ftrace_regs_caller / ftrace_stub_direct_tramp + * stubs, which carry a direct-call target on the stack until their final + * RET, and + * - the return thunks that RET expands to under CONFIG_MITIGATION_RETHUNK, + * which run after leaving the stubs above and before landing in that + * target. + */ +bool arch_rcu_tasks_trampoline_text(unsigned long ip) +{ + if (ip >= (unsigned long)ftrace_caller && + ip < (unsigned long)ftrace_static_tramp_end) + return true; +#ifdef CONFIG_MITIGATION_RETPOLINE + if (ip >= (unsigned long)__return_thunk_start && + ip < (unsigned long)__return_thunk_end) + return true; +#endif +#ifdef CONFIG_MITIGATION_SRSO + if (ip >= (unsigned long)__rethunk_safe_start && + ip < (unsigned long)__rethunk_safe_end) + return true; +#endif + return false; +} +#endif /* CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ + /* Defined as markers to the end of the ftrace default trampolines */ extern void ftrace_regs_caller_end(void); extern void ftrace_caller_end(void); diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index 62c1c93aa1c6..5d8cb3861978 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -145,6 +146,53 @@ SYM_FUNC_END(ftrace_stub_graph) #ifdef CONFIG_DYNAMIC_FTRACE +/* + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace(), see + * include/linux/rcupdate_trace.h and CONFIG_HAVE_RCU_TRAMPOLINE_READERS: the + * trampoline and the ftrace_ops it is about to load are kept alive by Tasks + * RCU only while we are inside this reader, so the lock must precede the + * function_trace_op load and the unlock must follow the call. These live + * inside the region copied into dynamic trampolines; the %rip-relative + * references are fixed up by text_poke_apply_relocation() in + * create_trampoline(). Clobbers %rax, %rcx and flags. + */ +.macro TRACE_RCU_READ_LOCK +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + movq PER_CPU_VAR(current_task), %rcx + movl TASK_trc_reader_nesting(%rcx), %eax + incl TASK_trc_reader_nesting(%rcx) + testl %eax, %eax + jnz .Ltrl_nested_\@ + movq rcu_tasks_trace_srcu_struct+SRCU_srcu_ctrp(%rip), %rax + incq %gs:SRCU_CTR_srcu_locks(%rax) + movq %rax, TASK_trc_reader_scp(%rcx) +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB + lock addl $0, -4(%rsp) /* smp_mb() */ +#endif +.Ltrl_nested_\@: +#endif +.endm + +.macro TRACE_RCU_READ_UNLOCK +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + movq PER_CPU_VAR(current_task), %rcx + movl TASK_trc_reader_nesting(%rcx), %eax + subl $1, %eax + jnz .Ltru_nested_\@ + /* Outermost: pick up scp before an interrupt can see nesting == 0. */ + movq TASK_trc_reader_scp(%rcx), %rax + movl $0, TASK_trc_reader_nesting(%rcx) +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB + lock addl $0, -4(%rsp) /* smp_mb() */ +#endif + incq %gs:SRCU_CTR_srcu_unlocks(%rax) + jmp .Ltru_done_\@ +.Ltru_nested_\@: + movl %eax, TASK_trc_reader_nesting(%rcx) +.Ltru_done_\@: +#endif +.endm + SYM_FUNC_START(__fentry__) ANNOTATE_NOENDBR CALL_DEPTH_ACCOUNT @@ -163,6 +211,8 @@ SYM_FUNC_START(ftrace_caller) leaq MCOUNT_REG_SIZE+8(%rsp), %rcx movq %rcx, RSP(%rsp) + TRACE_RCU_READ_LOCK + SYM_INNER_LABEL(ftrace_caller_op_ptr, SYM_L_GLOBAL) ANNOTATE_NOENDBR /* Load the ftrace_ops into the 3rd parameter */ @@ -181,6 +231,8 @@ SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) ANNOTATE_NOENDBR call ftrace_stub + TRACE_RCU_READ_UNLOCK + /* Handlers can change the RIP */ movq RIP(%rsp), %rax movq %rax, MCOUNT_REG_SIZE(%rsp) @@ -209,6 +261,8 @@ SYM_FUNC_START(ftrace_regs_caller) CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK + SYM_INNER_LABEL(ftrace_regs_caller_op_ptr, SYM_L_GLOBAL) ANNOTATE_NOENDBR /* Load the ftrace_ops into the 3rd parameter */ @@ -246,6 +300,8 @@ SYM_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL) ANNOTATE_NOENDBR call ftrace_stub + TRACE_RCU_READ_UNLOCK + /* Copy flags back to SS, to restore them */ movq EFLAGS(%rsp), %rax movq %rax, MCOUNT_REG_SIZE(%rsp) @@ -328,6 +384,19 @@ SYM_FUNC_START(ftrace_stub_direct_tramp) RET SYM_FUNC_END(ftrace_stub_direct_tramp) +/* + * [ftrace_caller, ftrace_static_tramp_end) is treated as trampoline text by + * rcu_tasks_trampoline_text(): outside TRACE_RCU_READ_LOCK/UNLOCK the stubs + * may still hold a direct-call trampoline address (ORIG_RAX / the return + * address they RET to) that only Tasks RCU keeps alive. With return thunks + * the RET itself runs elsewhere; arch_rcu_tasks_trampoline_text() covers + * those too. + */ +SYM_CODE_START_NOALIGN(ftrace_static_tramp_end) + UNWIND_HINT_UNDEFINED + ANNOTATE_NOENDBR +SYM_CODE_END(ftrace_static_tramp_end) + #else /* ! CONFIG_DYNAMIC_FTRACE */ SYM_FUNC_START(__fentry__) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 2438b89a4620..e546283dc267 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -151,7 +151,9 @@ SECTIONS * definition. */ . = srso_alias_untrain_ret | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20); + __rethunk_safe_start = .; *(.text..__x86.rethunk_safe) + __rethunk_safe_end = .; #endif ALIGN_ENTRY_TEXT_END @@ -162,7 +164,9 @@ SECTIONS SOFTIRQENTRY_TEXT #ifdef CONFIG_MITIGATION_RETPOLINE *(.text..__x86.indirect_thunk) + __return_thunk_start = .; *(.text..__x86.return_thunk) + __return_thunk_end = .; #endif STATIC_CALL_TEXT *(.gnu.warning) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421716.1647455 (Exim 4.92) (envelope-from ) id 1x6T31-00063Y-Ff; Tue, 15 Sep 2026 13:18:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421716.1647455; Tue, 15 Sep 2026 13:18:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T31-00063N-Ax; Tue, 15 Sep 2026 13:18:07 +0000 Received: by outflank-mailman (input) for mailman id 1421716; Tue, 15 Sep 2026 13:18:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2z-0005lx-AI for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:18:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2y-00DQRf-ND for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:18:04 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94586-e002-0a2a0a5209dd-0a2a4502d90c-8 for ; Tue, 15 Sep 2026 15:18:04 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9458b-6ca4-0a2a45020019-4a7de6cccb07-3 for ; Tue, 15 Sep 2026 15:18:04 +0200 Received: by mail-qk2-f12.google.com with SMTP id d75a77b69052e-52fb7692a57so36023731cf.1 for ; Tue, 15 Sep 2026 06:18:04 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530ca4899dasm125209321cf.12.2026.09.15.06.18.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:18:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478283; x=1790083083; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=9lDajmUPmaz8BTxhPEk6XaACKGtk0v9RwI05AN+Obys=; b=HS3o7GwDZfuWn761isCadth/I8EGnjkKsjcmVm/g+TKD0AKN39MXDUiVedZ9j/pNgu JskMwQavgNjV2RO6WM2YdUlLcWNf0KoCQ87cJRaZJ+/lycQXU+xZ5J/QxCJV8aBQSqHo nlVqXREOrVdPqc8QC/9I8tMUdua1O6sxNMKkRNlxx2hzl9h2K/fcipAeuPllkLDxJOx7 0pv6wcqPillhRf+LR7juPlPYX4ROoA4G4F2BFOGvWPeJrA4DzetXmiZ3Wdy0XuzVMJc6 AlREzMNNfhHUJwt0rRZmAHUhsYtFGdAtG6IGKkLbPZjCqpntOPuOvzjTmdhWvug1lJzc 29eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478283; x=1790083083; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9lDajmUPmaz8BTxhPEk6XaACKGtk0v9RwI05AN+Obys=; b=QphUjjOPK5E4VAqiQh+AfvQIPf0/opsdNa7/IbXQTGRM67w+BOuBjff1Se4u1JYgQx +IAdsww2DFuNJB5GhDvEDNdAH3eXeCNijP3wPfHJElEO1s0NR2plduIZAVX3ERu0atRq 5i7aSK/1/zadqyNNtEIG0/woxZgmm09QCycq7N4pgyPCtg8/V0srDI/mD657yqG2ZRBg oQtjnO7PA0lsEPuC8ogdivHlVDdcg48KoAngHJTtvZPFykg2oGGP5mj+urgy9ZxE8Z8X gUcHQLcQ8ETGV5+V84szB4W9uLAvSBIlx20L1ohAPvP7wGSx1rvDZBDcJAjwmhISSxwb 9lNw== X-Forwarded-Encrypted: i=1; AKwUvBzkxz2VkaPdZB2PRJA8eDzKownQiMi4+EXeYaE/rtgY5TF12tFzPIdLlubupSaF6F3FN7ePNSruXb8=@lists.xenproject.org X-Gm-Message-State: AFuF++lEgN6sGMzRlx/jGNfp+XjkKJq8TNA9hY38q2LQqDkwXF2PribM VhHseJQUu/vwlpM6MQFWihFBqJsAYQGHC/paFtTm2yJYbUrzAsnZsDN69TbF+tgeqK0= X-Gm-Gg: AYBFou3Anq/cIpaJZya7VfsSyGWeIU37KzI0ATgp+jkEHWBULjPOPFBremuIuwvvUOz AuB3nMRMgospJJVhs0FwBabwQUubF9CXdWTSl1rKVWCUad1TyAvD+Y64h3ZRqVIJds3EgbsU4MD 8MdVXWwVqpanhUxqTIhW06chRZPBWcL3O4v9nRJfsw9GIexFZygSlYFpRlPEAyA0OlHKVf+uePI LCiRObP1PO+gUSoG2vC+PEhr9cGwrsWcaEhY3tgI0kFyCLm0kiafKyrmsLOnpqqbuEdMomn8dHb D/lJzbewE52qZ4GNTxWPRrcASe8wl82cPbpbOBkA3L1yARFYlyj2p64vCddEgZmsso6ksbJDRNF g9w3ygnUueWIi1s/yozoOqpt5NYESOVcYH1CyNLUR5e4oD7OCwk5G0BEoruiDXMs6wELmEgLXAS 66uGxvFleufIvL82iKx20VolKzUN1JAEThQ/NT40OZ6okL+XGPCxGONb9PmwYGyNkl57YhALEQ7 PZXSqvm427JFkyeXQ3a9va7x6f6aU2ydA7zVuAx9nR+FMCqbWQK73mt X-Received: by 2002:ac8:5882:0:b0:531:4d7:bbe1 with SMTP id d75a77b69052e-5310d0620aamr106343871cf.50.1789478282597; Tue, 15 Sep 2026 06:18:02 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:35 +0000 Subject: [PATCH RFC v3 08/13] x86/kprobes: Take a Tasks Trace reader in the optprobe template MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-8-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=3977; i=josef@toxicpanda.com; h=from:subject:message-id; bh=cyOEpv7E+99KbsYBQF12i4qmiz/SB2W5CJ1v6BiG3CI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QPs7HUne0IzQlm9wRQkt109QqoRgFF/pfpz8lJ+9BcfBer6XnRW2+MjSGUTLZ6JFUaWA9Uyg01K Y4lSDYJOfogI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1789478284-F12A12AC-CECFB057/0/0 X-purgate-type: clean X-purgate-size: 3979 The jump-optimized kprobe template calls optimized_callback() from a dynamically allocated slot with preemption enabled, and only Tasks RCU keeps that slot alive under a task preempted in the callback. For HAVE_RCU_TRAMPOLINE_READERS that means the template must be a Tasks Trace reader across the call, so open-code rcu_read_lock_trace() and rcu_read_unlock_trace() around it as ftrace_64.S does. The template lives in .rodata and is memcpy()d into each slot without relocation processing, so the references to current_task and rcu_tasks_trace_srcu_struct are absolute (R_X86_64_32S, relocated for KASLR like any other) rather than %rip-relative. %rax and %rcx have already been saved by SAVE_REGS_STRING and are dead after the call. The slot itself is dynamically allocated text, so the instructions before the lock and after the unlock are covered by the irq-exit check. 64-bit only; 32-bit x86 does not take part. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/kernel/kprobes/opt.c | 44 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c index 3f8fea52619f..68a5de6cdabe 100644 --- a/arch/x86/kernel/kprobes/opt.c +++ b/arch/x86/kernel/kprobes/opt.c @@ -31,6 +31,7 @@ #include #include #include +#include #include "common.h" @@ -101,6 +102,47 @@ static void synthesize_set_arg1(kprobe_opcode_t *addr, unsigned long val) *(unsigned long *)addr = val; } +/* + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace() around the call + * to optimized_callback(), see CONFIG_HAVE_RCU_TRAMPOLINE_READERS and the + * equivalent macros in ftrace_64.S. The template is memcpy()d into the slot + * without relocation processing, so memory references must be absolute + * rather than %rip-relative. %rax and %rcx are free at both points. + */ +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB +#define OPTPROBE_TRACE_RCU_MB " lock addl $0, -4(%rsp)\n" +#else +#define OPTPROBE_TRACE_RCU_MB +#endif +#define OPTPROBE_TRACE_RCU_READ_LOCK \ + " movq %gs:current_task, %rcx\n" \ + " movl " __stringify(TASK_trc_reader_nesting) "(%rcx), %eax\n" \ + " incl " __stringify(TASK_trc_reader_nesting) "(%rcx)\n" \ + " testl %eax, %eax\n" \ + " jnz 1f\n" \ + " movq rcu_tasks_trace_srcu_struct+" __stringify(SRCU_srcu_ctrp) ", %rax\n" \ + " incq %gs:" __stringify(SRCU_CTR_srcu_locks) "(%rax)\n" \ + " movq %rax, " __stringify(TASK_trc_reader_scp) "(%rcx)\n" \ + OPTPROBE_TRACE_RCU_MB \ + "1:\n" +#define OPTPROBE_TRACE_RCU_READ_UNLOCK \ + " movq %gs:current_task, %rcx\n" \ + " movl " __stringify(TASK_trc_reader_nesting) "(%rcx), %eax\n" \ + " subl $1, %eax\n" \ + " jnz 2f\n" \ + " movq " __stringify(TASK_trc_reader_scp) "(%rcx), %rax\n" \ + " movl $0, " __stringify(TASK_trc_reader_nesting) "(%rcx)\n" \ + OPTPROBE_TRACE_RCU_MB \ + " incq %gs:" __stringify(SRCU_CTR_srcu_unlocks) "(%rax)\n" \ + " jmp 3f\n" \ + "2: movl %eax, " __stringify(TASK_trc_reader_nesting) "(%rcx)\n" \ + "3:\n" +#else +#define OPTPROBE_TRACE_RCU_READ_LOCK +#define OPTPROBE_TRACE_RCU_READ_UNLOCK +#endif + asm ( ".pushsection .rodata\n" ".global optprobe_template_entry\n" @@ -114,6 +156,7 @@ asm ( "optprobe_template_clac:\n" ASM_NOP3 SAVE_REGS_STRING + OPTPROBE_TRACE_RCU_READ_LOCK " movq %rsp, %rsi\n" ".global optprobe_template_val\n" "optprobe_template_val:\n" @@ -122,6 +165,7 @@ asm ( ".global optprobe_template_call\n" "optprobe_template_call:\n" ASM_NOP5 + OPTPROBE_TRACE_RCU_READ_UNLOCK /* Copy 'regs->flags' into 'regs->ss'. */ " movq 18*8(%rsp), %rdx\n" " movq %rdx, 20*8(%rsp)\n" -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421717.1647460 (Exim 4.92) (envelope-from ) id 1x6T31-00066n-SQ; Tue, 15 Sep 2026 13:18:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421717.1647460; Tue, 15 Sep 2026 13:18:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T31-00065M-KG; Tue, 15 Sep 2026 13:18:07 +0000 Received: by outflank-mailman (input) for mailman id 1421717; Tue, 15 Sep 2026 13:18:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T2z-0005rb-OL for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:18:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T2z-00EGDb-4h for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:18:05 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94586-bab6-0a2a0a5309dd-0a2a4504e7e8-28 for ; Tue, 15 Sep 2026 15:18:05 +0200 Received: from [74.125.230.205] (helo=mail-qk2-f13.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9458c-b57f-0a2a45040019-4a7de6cdcb65-3 for ; Tue, 15 Sep 2026 15:18:04 +0200 Received: by mail-qk2-f13.google.com with SMTP id af79cd13be357-93a135ffb08so354041385a.2 for ; Tue, 15 Sep 2026 06:18:04 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-939e86b7424sm1246377685a.32.2026.09.15.06.17.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:17:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478283; x=1790083083; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=BZpG8a4K/YgKhJUrG5n9/0zVHbEqV2OSxLbwC0u3TSA=; b=hfpjD77576w47tmYR2ULv5Hf172bKfHccQgSALKQtfA3ysWu4N1mvaxDHVBizwfNl1 RIogPEoKxxbwWqwMhJkoq85MDFpSEi6iTTjbcusm3hAB/xg/8wEpWl4cOogV+Cmo82MZ MvwaZX9GJdCaBoxu8Yd8owYfKaaEDhyqGsxrjTmlR878KsBzro9OAwJrCxkS5dNKrlkI kfBkLk6G2PAtNzaS/LPkTvjUW1dsjE2N3RDODfRI2icJVUV9PL9SJKtubzEu51klAeJY OLP/5XFMa0jECAnz7akelZFDOY71GbgDXIyQl7fWFqOVRZs7xxoA6lbis5LFprp38ONz 9svw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478283; x=1790083083; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BZpG8a4K/YgKhJUrG5n9/0zVHbEqV2OSxLbwC0u3TSA=; b=bnpaj7nXl2c5r1C07x20DUA7H8Dq6/ICe71RZQoBohkg3MydLAzRysFdBl3LY01tAk fuhgPggFqap+jnOoDHV6RMkUqwbM2rBXLuBdfqRmDMsTrLSY+GLnOIrvgy1Pn/Np+JG8 U5LV2CacnQrElReGJfUWl+bc9NBHdaS5BV+g6Z46Xzb36aMUARapBAeaPeuPzlUVQyWO Gwiy796c4idod/eHHGQVhNSXWtGXrJeytKBV32HPLO+GhgjL0dlK4FUYFishJRpFsIdj OzoUNomqXpb1v/pNM+C+1ow6T5QUpxoohpn2xzJhMF3eHvICks/ODVP2v4Hjy/AZARfh veCg== X-Forwarded-Encrypted: i=1; AKwUvBwh32vim1k4O/MeLBpLh1PIP5/Fw7+wUnm/Yxfxp39pUqgvifleQwi/RT/nhEYtr1+Hn0J/0jMYCAA=@lists.xenproject.org X-Gm-Message-State: AFuF++muY4ZeTr2w2SC4+ssX5HZ8B0ep+2FY+UIpPlYTVXoorX6EpKdb oT8KIwuoTdjFrqnVH5h6I7fGs8x1wmDSNLUqIqYT4fXbf7lRojDfn9lWJrAhtGamBlc= X-Gm-Gg: AYBFou223pDWi/6rGcM3KacYlN2EtALYuawtyQiyZfuDo8YG7WXK/7hl1IfBfi5OXwG gQZrFDFEL5wRA0qM9YhcSSALIuJisTovfdM8aLRmoS5V2+dW2n9Ng9DJqjUn0KqsfpksNBZAZam ZTQcGR03yPnwCwgb9FDK3JORMqKPMTBHgJunLpufeZn7JF6Ilie4YicMKQqoc9xj+beEoR7iFtK lRn3LkMm7woLFhX/dEZylxx66EusBoI16SJqnVuhy5q7wNYE/dkmTTb2CvfH1hgddEQgCJT4cIB B9MsE/Eajm9X9JeGtmCjZPIkeobdTNlq8K4FubGFtiIqhSTK1BWO9d8XtbHI0drHpS+PSMIQFy9 TBQqGTbnjhWINdJkGAAuCCMJIbJ696v9TGKcJNwVN9PKH6p1rf9H6Di+ymd98OM7yESquWYSN4D wzBH01ONrF7pNEmva2nQ+nY5U4yGLm/kq4fcYJjkktpYcYAvRR12DK36/oakUTbHVY8pUr1ul8u JhnNO2nRv3XPHn7PKplxLS/p6LnJxPig+Ipn7kHk6tCDX26YtFQqSeW X-Received: by 2002:a05:620a:1b98:b0:93a:1092:48fa with SMTP id af79cd13be357-93a297e91bemr9631785a.4.1789478278679; Tue, 15 Sep 2026 06:17:58 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:33 +0000 Subject: [PATCH RFC v3 06/13] bpf: Take a Tasks Trace reader in the trampoline glue MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-6-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=11875; i=josef@toxicpanda.com; h=from:subject:message-id; bh=TXFGxaV6JtFDo/uJzdvTZ+O6U4MOxiEs7Jz7Lihg/aQ=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QMNOzSXH+MqwbhPyhl85UFDH60OjviU5by15ukzOGqWorm6a0N96E9GIqZviv+bWi33vuGmPHvW FnOzjv4m5SQI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1789478285-C0CDFB50-713987AE/0/0 X-purgate-type: clean X-purgate-size: 11877 On CONFIG_TASKS_RCU_TRAMPOLINE_READERS kernels Tasks RCU keeps a BPF trampoline image allocated only while a task using it is a Tasks Trace RCU reader or is executing text that rcu_tasks_trampoline_text() recognises. The image itself is such text, but from it we call C glue in core kernel text -- __bpf_prog_enter*(), __bpf_prog_exit*(), __bpf_tramp_enter() and __bpf_tramp_exit() -- and today only the sleepable variants take rcu_read_lock_trace(). Rather than add anything to the JIT-emitted trampolines, close the gap in the glue: place all of it in .text..rcu_tramp via __rcu_trampoline so that a task interrupted in its prologue or epilogue is treated like one interrupted in the image, have every enter helper take rcu_read_lock_trace() before anything that could run out of line and every exit helper drop it last, and bracket the percpu_ref get and put in __bpf_tramp_enter()/__bpf_tramp_exit() the same way (the percpu_ref continues to cover the call to the original function). From the image's call to the glue's return the task is then always either in recognised text or a reader. The extra reader is compiled out on other configurations, and the sleepable paths are unchanged. bpf_tramp_image_put()'s call_rcu_tasks() stages are what now wait for those readers and for tasks interrupted in the image's own instructions. For images that call the original function nothing else changes: the percpu_ref pins the image from __bpf_tramp_enter() to __bpf_tramp_exit(), so only the instructions before and after need the grace periods they already get. A fentry-only image has no percpu_ref, and with one reader per prog a task walks reader, image, reader, image...; one grace period only guarantees such a task has left the reader or gap it was in when the grace period began, so on these kernels the fentry-only teardown requeues itself for one Tasks RCU grace period per prog (im->nr_progs, recorded when the image is built) before freeing. That costs nothing on the call path and a few more asynchronous grace periods on detach. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/bpf.h | 1 + kernel/bpf/trampoline.c | 107 +++++++++++++++++++++++++++++++++++++----------- 2 files changed, 85 insertions(+), 23 deletions(-) diff --git a/include/linux/bpf.h b/include/linux/bpf.h index e57af902560c..b97ad80aacae 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -1366,6 +1366,7 @@ enum bpf_tramp_prog_type { struct bpf_tramp_image { void *image; int size; + int nr_progs; /* see bpf_tramp_image_put() */ struct bpf_ksym ksym; struct percpu_ref pcref; void *ip_after_call; diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c index 90b70ea0d370..dbbc9bd7fd22 100644 --- a/kernel/bpf/trampoline.c +++ b/kernel/bpf/trampoline.c @@ -601,12 +601,25 @@ static void __bpf_tramp_image_put_rcu_tasks(struct rcu_head *rcu) struct bpf_tramp_image *im; im = container_of(rcu, struct bpf_tramp_image, rcu); - if (im->ip_after_call) + if (im->ip_after_call) { /* the case of fmod_ret/fexit trampoline and CONFIG_PREEMPTION=y */ percpu_ref_kill(&im->pcref); - else + } else if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) && + --im->nr_progs > 0) { + /* + * fentry-only trampoline on a reader-marked Tasks RCU: each prog + * runs in its own Tasks Trace reader with a few image + * instructions in between, and one rcu tasks grace period only + * guarantees that a task has moved on from the reader (or gap) it + * was in when the grace period started. A task walking the image + * therefore needs one grace period per prog before the image can + * go; keep requeueing until we have had that many. + */ + call_rcu_tasks(&im->rcu, __bpf_tramp_image_put_rcu_tasks); + } else { /* the case of fentry trampoline */ call_rcu_tasks(&im->rcu, __bpf_tramp_image_put_rcu); + } } static void bpf_tramp_image_put(struct bpf_tramp_image *im) @@ -619,6 +632,14 @@ static void bpf_tramp_image_put(struct bpf_tramp_image *im) * (which are few asm insns before __bpf_tramp_enter and * after __bpf_tramp_exit) * + * With CONFIG_TASKS_RCU_TRAMPOLINE_READERS, rcu tasks waits for a task + * in those asm insns because they are trampoline text, and for a task + * inside the glue or a prog because the glue makes it a + * rcu_read_lock_trace reader. The percpu_ref case is otherwise + * unchanged; the fentry-only case, having no percpu_ref across the + * whole image, takes one rcu tasks grace period per prog, see + * __bpf_tramp_image_put_rcu_tasks(). + * * The trampoline is unreachable before bpf_tramp_image_put(). * * First, patch the trampoline to avoid calling into fexit progs. @@ -776,6 +797,7 @@ static int bpf_trampoline_update(struct bpf_trampoline *tr, bool lock_direct_mut err = PTR_ERR(im); goto out; } + im->nr_progs = total; err = arch_prepare_bpf_trampoline(im, im->image, im->image + size, &tr->func.model, tr->flags, tnodes, @@ -1285,9 +1307,34 @@ static __always_inline u64 notrace bpf_prog_start_time(void) * [2..MAX_U64] - execute bpf prog and record execution time. * This is start time. */ -static u64 notrace __bpf_prog_enter_recur(struct bpf_prog *prog, struct bpf_tramp_run_ctx *run_ctx) +/* + * Where Tasks RCU is built on reader-marked trampolines + * (CONFIG_TASKS_RCU_TRAMPOLINE_READERS), the trampoline image that called the + * glue below stays allocated only while the task is a Tasks Trace RCU reader + * or is executing text that rcu_tasks_trampoline_text() recognises: the image + * itself, or this glue, which is therefore placed in .text..rcu_tramp + * (__rcu_trampoline). Each enter helper takes the reader before anything + * that could run out of line and each exit helper drops it last, so from the + * image's call to the glue's return the task is always one or the other. The + * sleepable variants already are such readers for their own reasons. + */ +static __always_inline void bpf_tramp_read_lock_trace(void) +{ + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_read_lock_trace(); +} + +static __always_inline void bpf_tramp_read_unlock_trace(void) +{ + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_read_unlock_trace(); +} + +static u64 notrace __rcu_trampoline +__bpf_prog_enter_recur(struct bpf_prog *prog, struct bpf_tramp_run_ctx *run_ctx) __acquires(RCU) { + bpf_tramp_read_lock_trace(); rcu_read_lock_dont_migrate(); run_ctx->saved_run_ctx = bpf_set_run_ctx(&run_ctx->run_ctx); @@ -1329,8 +1376,8 @@ static __always_inline void notrace update_prog_stats(struct bpf_prog *prog, __update_prog_stats(prog, start); } -static void notrace __bpf_prog_exit_recur(struct bpf_prog *prog, u64 start, - struct bpf_tramp_run_ctx *run_ctx) +static void notrace __rcu_trampoline +__bpf_prog_exit_recur(struct bpf_prog *prog, u64 start, struct bpf_tramp_run_ctx *run_ctx) __releases(RCU) { bpf_reset_run_ctx(run_ctx->saved_run_ctx); @@ -1338,15 +1385,17 @@ static void notrace __bpf_prog_exit_recur(struct bpf_prog *prog, u64 start, update_prog_stats(prog, start); bpf_prog_put_recursion_context(prog); rcu_read_unlock_migrate(); + bpf_tramp_read_unlock_trace(); } -static u64 notrace __bpf_prog_enter_lsm_cgroup(struct bpf_prog *prog, - struct bpf_tramp_run_ctx *run_ctx) +static u64 notrace __rcu_trampoline +__bpf_prog_enter_lsm_cgroup(struct bpf_prog *prog, struct bpf_tramp_run_ctx *run_ctx) __acquires(RCU) { /* Runtime stats are exported via actual BPF_LSM_CGROUP * programs, not the shims. */ + bpf_tramp_read_lock_trace(); rcu_read_lock_dont_migrate(); run_ctx->saved_run_ctx = bpf_set_run_ctx(&run_ctx->run_ctx); @@ -1354,17 +1403,18 @@ static u64 notrace __bpf_prog_enter_lsm_cgroup(struct bpf_prog *prog, return NO_START_TIME; } -static void notrace __bpf_prog_exit_lsm_cgroup(struct bpf_prog *prog, u64 start, - struct bpf_tramp_run_ctx *run_ctx) +static void notrace __rcu_trampoline +__bpf_prog_exit_lsm_cgroup(struct bpf_prog *prog, u64 start, struct bpf_tramp_run_ctx *run_ctx) __releases(RCU) { bpf_reset_run_ctx(run_ctx->saved_run_ctx); rcu_read_unlock_migrate(); + bpf_tramp_read_unlock_trace(); } -u64 notrace __bpf_prog_enter_sleepable_recur(struct bpf_prog *prog, - struct bpf_tramp_run_ctx *run_ctx) +u64 notrace __rcu_trampoline +__bpf_prog_enter_sleepable_recur(struct bpf_prog *prog, struct bpf_tramp_run_ctx *run_ctx) { rcu_read_lock_trace(); migrate_disable(); @@ -1381,8 +1431,9 @@ u64 notrace __bpf_prog_enter_sleepable_recur(struct bpf_prog *prog, return bpf_prog_start_time(); } -void notrace __bpf_prog_exit_sleepable_recur(struct bpf_prog *prog, u64 start, - struct bpf_tramp_run_ctx *run_ctx) +void notrace __rcu_trampoline +__bpf_prog_exit_sleepable_recur(struct bpf_prog *prog, u64 start, + struct bpf_tramp_run_ctx *run_ctx) { bpf_reset_run_ctx(run_ctx->saved_run_ctx); @@ -1392,8 +1443,8 @@ void notrace __bpf_prog_exit_sleepable_recur(struct bpf_prog *prog, u64 start, rcu_read_unlock_trace(); } -static u64 notrace __bpf_prog_enter_sleepable(struct bpf_prog *prog, - struct bpf_tramp_run_ctx *run_ctx) +static u64 notrace __rcu_trampoline +__bpf_prog_enter_sleepable(struct bpf_prog *prog, struct bpf_tramp_run_ctx *run_ctx) { rcu_read_lock_trace(); migrate_disable(); @@ -1404,8 +1455,8 @@ static u64 notrace __bpf_prog_enter_sleepable(struct bpf_prog *prog, return bpf_prog_start_time(); } -static void notrace __bpf_prog_exit_sleepable(struct bpf_prog *prog, u64 start, - struct bpf_tramp_run_ctx *run_ctx) +static void notrace __rcu_trampoline +__bpf_prog_exit_sleepable(struct bpf_prog *prog, u64 start, struct bpf_tramp_run_ctx *run_ctx) { bpf_reset_run_ctx(run_ctx->saved_run_ctx); @@ -1414,10 +1465,11 @@ static void notrace __bpf_prog_exit_sleepable(struct bpf_prog *prog, u64 start, rcu_read_unlock_trace(); } -static u64 notrace __bpf_prog_enter(struct bpf_prog *prog, - struct bpf_tramp_run_ctx *run_ctx) +static u64 notrace __rcu_trampoline +__bpf_prog_enter(struct bpf_prog *prog, struct bpf_tramp_run_ctx *run_ctx) __acquires(RCU) { + bpf_tramp_read_lock_trace(); rcu_read_lock_dont_migrate(); run_ctx->saved_run_ctx = bpf_set_run_ctx(&run_ctx->run_ctx); @@ -1425,24 +1477,33 @@ static u64 notrace __bpf_prog_enter(struct bpf_prog *prog, return bpf_prog_start_time(); } -static void notrace __bpf_prog_exit(struct bpf_prog *prog, u64 start, - struct bpf_tramp_run_ctx *run_ctx) +static void notrace __rcu_trampoline +__bpf_prog_exit(struct bpf_prog *prog, u64 start, struct bpf_tramp_run_ctx *run_ctx) __releases(RCU) { bpf_reset_run_ctx(run_ctx->saved_run_ctx); update_prog_stats(prog, start); rcu_read_unlock_migrate(); + bpf_tramp_read_unlock_trace(); } -void notrace __bpf_tramp_enter(struct bpf_tramp_image *tr) +/* + * The percpu_ref keeps the image alive across the call to the original + * function; the reader only has to cover getting and putting it, see above. + */ +void notrace __rcu_trampoline __bpf_tramp_enter(struct bpf_tramp_image *tr) { + bpf_tramp_read_lock_trace(); percpu_ref_get(&tr->pcref); + bpf_tramp_read_unlock_trace(); } -void notrace __bpf_tramp_exit(struct bpf_tramp_image *tr) +void notrace __rcu_trampoline __bpf_tramp_exit(struct bpf_tramp_image *tr) { + bpf_tramp_read_lock_trace(); percpu_ref_put(&tr->pcref); + bpf_tramp_read_unlock_trace(); } bpf_trampoline_enter_t bpf_trampoline_enter(const struct bpf_prog *prog) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421720.1647472 (Exim 4.92) (envelope-from ) id 1x6T36-0006fq-97; Tue, 15 Sep 2026 13:18:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421720.1647472; Tue, 15 Sep 2026 13:18:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T36-0006fc-4x; Tue, 15 Sep 2026 13:18:12 +0000 Received: by outflank-mailman (input) for mailman id 1421720; Tue, 15 Sep 2026 13:18:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T34-0006aV-NC for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:18:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T34-00EGI1-3v for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:18:10 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9458a-bab6-0a2a0a5309dd-0a2a450bc220-40 for ; Tue, 15 Sep 2026 15:18:10 +0200 Received: from [74.125.230.205] (helo=mail-qk2-f13.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94590-b7e8-0a2a450b0019-4a7de6cdea8e-3 for ; Tue, 15 Sep 2026 15:18:09 +0200 Received: by mail-qk2-f13.google.com with SMTP id af79cd13be357-93910ca5aa7so364803685a.1 for ; Tue, 15 Sep 2026 06:18:09 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93a26921baesm489982785a.24.2026.09.15.06.18.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:18:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478288; x=1790083088; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=MkP56mJgKixcgLXoBxrfzz0NyJo14L+hjKFrNfKE/2k=; b=KsRnxpdM0ubtvKqOAXQ7edwqj91lFxrXbW5a+peC4GCrrs1OGpZmAT02aHMhQwpj2A OUl1liAYrNpjr2svthAGkLJJ0v4Or2xTtkrHntMp71Tf/y7HJM8b2wbDhKNyXVMBpsQ7 /2h2UilfXT5C8Q/RDcBlXCbSYkpwe8OQZ/N5zSIj4a0sgNEIICuSpb1tgCgqnI0l0fAY GG0RqzhSQrFprEnrTO3bKy/oAWkZ1TxIOSQ9Q3a+YteTsLxKjeXvseQ1/sYbC6m8TviJ spsRj0n/72HuRd/t4lCikc1Ih4D3efe8RCDelK6RxIeM/Jofq6uGkq1AKpoiGS+4Me4R 8DYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478288; x=1790083088; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=MkP56mJgKixcgLXoBxrfzz0NyJo14L+hjKFrNfKE/2k=; b=2xJMNB9VjNxWAxn+hHVVxprkSTSIerT9e5UFG4wZbTXLBpW8Vvwba/nL1sdW8LEpAk XskRfS8SM21VSR1zBfDidHCSGmvR1Y83RZRv7qySpsfVdXvl6MtEOeFUO/JTqnoxIbst /beNLw8ivkXUTPbE7l4B6Dhp/LLDxkWJpV+e1/a+eaEdHhYXCTG/5gWBc/+57x8DRlYm +kmM3FfHtZoIIqrayAnXTVBkOXiS7ZBCoBOs8EVKX6xh+WHrPsYAv8++qNi4eSRu1CNX C1iUVY+//+lQ720S1TzFxo12I/lwy4FrfrYEfa12J6KauINvPCMJDr3uXgSh8NuMqDkh Bl2w== X-Forwarded-Encrypted: i=1; AKwUvBz4pR3Eh2yU6DzL7W0xlkk9JouzidaNRBiVMB0ZJpMSGVw86bY9OK0mFfK1Ebwgcyu1X3Cg6tGnreo=@lists.xenproject.org X-Gm-Message-State: AFuF++mKQ28ibEteFqq9bBG8TCCRNqDDWViO+JiT8zQNQuWJbhZuIQ5Q QbMyKUoWGcy6qkCNp7rTRjGL7BaPeisaZbALNnNfVtKi66c2zDNLNbGtW7RX/FdF4vG93Vcdx7V Dj6ZJj7yZMw== X-Gm-Gg: AYBFou2+vmOm3SFLh1kzwU5QoyX6TWL+KBVxUWhG4avFwGvqrmjWbMfIzmXMN9dvMVj HWGD0QMUwOelwbKBwsjb9FadJoiOgGO2n7kBuDkzHuGf657p6ri3hDyYwF3jFE4hSMGKgcmKcLQ fWx4+XuDrEq8ldsOwqeUMQ0DZ7sOKIOR+eHqQz6yev37k33DS/KUZJ8MOXpVjlnEwsgXBu0t/Dw 3hsJx/e14zFy+C6wXW2C+P+b1eUM9vl0ejr2z0nIW81S0+nny/fVerHCfCnYhcqPC7dGU4nDQOT 6NnXnr26NPxmhBl+bcPZFNDowmlmoD7lIfmNs8O+sRtDSQA5HDDoEdAJAaQmGBqEMLunUWggyBC GJH4p9SKJmlTEVQ7byt9fR7ExsZ1SE3BBmh1PgHkTDcSjDwS9a3YkB1JCncLl/uZ3ocJb21wwxv NCyNJ3qNlEjyZ0BNSL2V42RF9GZL5tcyrlc1dr5xN87IddamR13Fm68LFp68uEYPEgaqysz50nh cTVJ1rhsVlUAAxMv2h+3LIg6ZlP/mPPId5LjR80a8AD4yuJBac8rKV0 X-Received: by 2002:a05:620a:1b87:b0:92e:76a1:96cd with SMTP id af79cd13be357-93a297e8f8cmr1159268485a.13.1789478288213; Tue, 15 Sep 2026 06:18:08 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:38 +0000 Subject: [PATCH RFC v3 11/13] rcutorture: Make Tasks RCU readers Tasks Trace readers where required MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-11-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=1716; i=josef@toxicpanda.com; h=from:subject:message-id; bh=O8YdW4YSHUYyF3GwEQN16WzJM7UkZZFfh8RzVwv7xJM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QIccOQgqxisnPo/25JJmyx4Bx5hp1tfVVTZrdfU6SlgArQbvK/ARnj8AAoaQqqIY//mIhN1g1fK eVSGZVlcF5wA= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1789478290-1A8D99EA-A78D3724/0/0 X-purgate-type: clean X-purgate-size: 1718 rcutorture's "tasks" flavor has empty readlock/readunlock hooks because a classic Tasks RCU reader is simply code that does not block. Under CONFIG_TASKS_RCU_TRAMPOLINE_READERS a preemption outside trampoline text is also a quiescent state, and the thing real readers (trampolines) do to stay protected across their call-outs is take rcu_read_lock_trace(), so have the torture readers do the same there. Otherwise a preempted torture reader would rightly be treated as quiescent and the test would report false-positive too-short grace periods. Assisted-by: LLM Signed-off-by: Josef Bacik --- kernel/rcu/rcutorture.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index 794937e13e7c..ab870ef09af0 100644 --- a/kernel/rcu/rcutorture.c +++ b/kernel/rcu/rcutorture.c @@ -1142,13 +1142,23 @@ static struct rcu_torture_ops trivial_preempt_ops = { * Definitions for RCU-tasks torture testing. */ +/* + * A classic Tasks RCU reader is any stretch of kernel code that does not + * voluntarily block. With CONFIG_TASKS_RCU_TRAMPOLINE_READERS a preemption + * outside trampoline text also ends it, and what a trampoline does to stay + * protected across its call-out is take a Tasks Trace reader, so model that. + */ static int tasks_torture_read_lock(void) { + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_read_lock_trace(); return 0; } static void tasks_torture_read_unlock(int idx) { + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_read_unlock_trace(); } static void rcu_tasks_torture_deferred_free(struct rcu_torture *p) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421721.1647481 (Exim 4.92) (envelope-from ) id 1x6T37-0006wL-Iq; Tue, 15 Sep 2026 13:18:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421721.1647481; Tue, 15 Sep 2026 13:18:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T37-0006vW-ER; Tue, 15 Sep 2026 13:18:13 +0000 Received: by outflank-mailman (input) for mailman id 1421721; Tue, 15 Sep 2026 13:18:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T35-0006e6-KB for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:18:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T35-00DQUc-17 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:18:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94586-e002-0a2a0a5209dd-0a2a4502d90c-18 for ; Tue, 15 Sep 2026 15:18:11 +0200 Received: from [74.125.230.205] (helo=mail-qk2-f13.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94591-6ca4-0a2a45020019-4a7de6cd843a-3 for ; Tue, 15 Sep 2026 15:18:10 +0200 Received: by mail-qk2-f13.google.com with SMTP id d75a77b69052e-530e2f50d01so38941751cf.0 for ; Tue, 15 Sep 2026 06:18:10 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-530f6849802sm80503791cf.10.2026.09.15.06.18.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:18:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478289; x=1790083089; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ua8lq0Nx07F8Y+BgJ1JiUwgoDOin8IZmspGmQtj7ybE=; b=qejDFAD2az3AaDLu2CvoHTf+EnV/K/Cr9KvHqmh9vzxo97B7mTqSXR+FoFSd3D0LIl hjIu41ym36vrbKYH7H4I2Dp2vb7Tf78J3R9PKUA6xOWEzK2jDR+34ECu2DFZCxYFw63C gSz6GN5eLbbv23k4hbW8ZWt6u0l43v9ZMdS6OkDnHEOh1UCtPptAbFokqUp8St2jjqKx cX0xiPgh+Xzfx7GhlXDg7k+UBcEDjmJESofyKmW8RrKMitNWJy9clc2Gc5dmI2YyG3U8 Xug6fGXdTQmKqQRZ3oPxx9UjcPI2198egLcKunmCL06RzDfm7RJuKw2IS4e/ziY4MWsr ISdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478289; x=1790083089; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ua8lq0Nx07F8Y+BgJ1JiUwgoDOin8IZmspGmQtj7ybE=; b=tWVD+KzwdWcuILIKwn+cDE0RiNTBAqm+t1Hzp4YD7TvMF8zQMhX9a9EDfWFjr0YBvF lZ08i/moWfsv3TUcHk4Saw3tjeIG3YWFQJxEsi2mK9f/vhPnFOLE1cdAOTNSCBR5b7n3 gB9AVs+G5kCCfzxvPr4OcX0ue9x8RimYZB3AfwVw1QYAhMG/hwIdZR9tdYZo3mhrE+DR 4/yt15LODfd+w3YoE8yFvDDjS/uGnUZs/NP+Yuc43V65jLYaIqdThfx5T8MQr9jxmJcc x8SD3boP+7DyHHIhUZ2h/BEU5Blf9iu/Fun4Im4O6ezaIR/rUrDlLUAFzu/GCf9m4BKi Oqcw== X-Forwarded-Encrypted: i=1; AKwUvByyVYblx1dFuS0qTSch/0wiPwmZv5k8H6XFKzSv2cPC+T0nt1U3QcxJshdWUd/xLLj4C8MCKDVkURY=@lists.xenproject.org X-Gm-Message-State: AFuF++mwQQXSEaEWugEmgsA0hjBDqNwPj8sKFu2KKd1yEi9UAFE9l7Sv o2DiEcVyBjaiyzd+zbeER0MAwzoCktnxbhOa2JlYirOO7W+OUdXMpEar6f6hL5pz3SA= X-Gm-Gg: AYBFou3I9EPORL6KlwMLEm9MQDZR2dW7hJv3hh6qywWQDBue6RtS7SxC/uyUZRrWgTW SKRifgbEWh/9lvoIo/nLsLaOGF0uQXDNz7uJDvSvn8ypqVzbgMDa6VYwgiG99mct/FX2sudUZr8 jVa7Rq0YiJE1l6lghRZi8+EsPPnjmKAvfOKY6y7vtjNSjUQsaztJbOO2Xt+qYBFWggL40HozUkt VcNo2hqyUgy1a0PPxBTY1JA068rPlMMXXlGDrpcurkUUr753T6MQCwnXzIAsUZrj38PByKHpWr2 Ffd9d5iu3bD7yS4huKjZbAXXyvngnzDJPI87fR5Jd+VvPoOsChMnFgflxPxyuKJ7hvb2wW8txuS xzeIXas1fyN+khLMlAjwhlfKhQY9o9JwvYNA7G18imxg7nDP4ge67ZEpzmw57BL6AweUovJEQsf ncvcYxmlX1ujoU8zpgD6I/uLhYXc7IDsufhv0r+3JA51CFkk5PtqbKJy+tKjPRKlNAid/n0+mqX 458EiPOHljtWXLeiQGpSrpVrHQqr/TIky3resEmrujE/7J8y8tefnRU X-Received: by 2002:a05:622a:1919:b0:530:98bc:3974 with SMTP id d75a77b69052e-5310cf631f8mr109341941cf.22.1789478284669; Tue, 15 Sep 2026 06:18:04 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:36 +0000 Subject: [PATCH RFC v3 09/13] arm64: ftrace: Take a Tasks Trace reader around ftrace_caller's call-out MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-9-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=7839; i=josef@toxicpanda.com; h=from:subject:message-id; bh=Aqm0C5BBMBkqFusbG93kcm6leRi28F4VKStTPzg6dAE=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QGtKBbzIh64iNKja7atdfYbFNhvzop2423iTP8KKI74RhSORDHi3DpZgpvvVVV7stG2frrx5HDn 5ncEuv/+0CQs= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1789478290-67EBB2AC-F83B22E8/0/0 X-purgate-type: clean X-purgate-size: 7841 For HAVE_RCU_TRAMPOLINE_READERS the ftrace trampoline must be a Tasks Trace RCU reader while it calls out, since that is what synchronize_rcu_tasks() will wait for before ftrace_shutdown() frees an ftrace_ops (or, with CALL_OPS, lets its owner free it) under a task preempted in the callback. Open-code rcu_read_lock_trace() and rcu_read_unlock_trace() around the call to ops->func in ftrace_caller: bump current->trc_reader_nesting via sp_el0 and, for the outermost reader, do the SRCU-fast per-CPU increment on rcu_tasks_trace_srcu_struct and stash the counter pointer in current->trc_reader_scp, as the C inlines do (including the dmb when CONFIG_TASKS_TRACE_RCU_NO_MB is not set). The per-CPU increment is an LL/SC add on this CPU's counter; being migrated between reading the per-CPU offset and the store-exclusive only means another CPU's counter is incremented atomically instead, which SRCU sums over anyway. x12-x16 are free at both points. arm64 has no return thunks and, with CALL_OPS, no dynamic ftrace trampolines, but ftrace_caller itself carries the ops pointer in x11 from before the reader is entered and a direct-call BPF trampoline address in x17 until the final br/ret after it is left, so mark the end of the static trampoline text and provide arch_rcu_tasks_trampoline_text() covering [ftrace_caller, ftrace_static_tramp_end). Built only under CONFIG_TASKS_RCU_TRAMPOLINE_READERS, which arm64 does not enable until a later patch. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/arm64/kernel/asm-offsets.c | 8 +++++ arch/arm64/kernel/entry-ftrace.S | 74 ++++++++++++++++++++++++++++++++++++++++ arch/arm64/kernel/ftrace.c | 20 +++++++++++ 3 files changed, 102 insertions(+) diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 9c853ed3ceab..f6a8fb1f9b43 100644 --- a/arch/arm64/kernel/asm-offsets.c +++ b/arch/arm64/kernel/asm-offsets.c @@ -10,6 +10,7 @@ #include #include +#include #include #include #include @@ -39,6 +40,13 @@ int main(void) DEFINE(TSK_STACK, offsetof(struct task_struct, stack)); #ifdef CONFIG_STACKPROTECTOR DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary)); +#endif +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + DEFINE(TSK_TRC_READER_NESTING, offsetof(struct task_struct, trc_reader_nesting)); + DEFINE(TSK_TRC_READER_SCP, offsetof(struct task_struct, trc_reader_scp)); + DEFINE(SRCU_SRCU_CTRP, offsetof(struct srcu_struct, srcu_ctrp)); + DEFINE(SRCU_CTR_SRCU_LOCKS, offsetof(struct srcu_ctr, srcu_locks)); + DEFINE(SRCU_CTR_SRCU_UNLOCKS, offsetof(struct srcu_ctr, srcu_unlocks)); #endif BLANK(); DEFINE(THREAD_CPU_CONTEXT, offsetof(struct task_struct, thread.cpu_context)); diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S index 025140caafe7..fc2805eb9e15 100644 --- a/arch/arm64/kernel/entry-ftrace.S +++ b/arch/arm64/kernel/entry-ftrace.S @@ -14,6 +14,72 @@ #include #ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS +/* + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace(), see + * include/linux/rcupdate_trace.h and CONFIG_HAVE_RCU_TRAMPOLINE_READERS. The + * whole of ftrace_caller is treated as trampoline text by the irq-exit check + * (see arch_rcu_tasks_trampoline_text()), so these only need to bracket the + * call out to ops->func; everything before the lock and after the unlock, + * including the direct-call tails that carry a BPF trampoline address in x17, + * is covered by that. + * + * The SRCU-fast per-CPU increment is done LL/SC on this CPU's counter; being + * migrated between reading the per-CPU offset and the store-exclusive only + * means another CPU's counter is (atomically) incremented, which SRCU sums + * over anyway. Ordering between the nesting count and the scp stash only + * matters against interrupts on this CPU, which observe program order. + * Clobbers x12-x16 and the flags. + */ + .macro trace_rcu_srcu_inc, addr:req, tmp:req, wtmp2:req +8888: ldxr \tmp, [\addr] + add \tmp, \tmp, #1 + stxr \wtmp2, \tmp, [\addr] + cbnz \wtmp2, 8888b + .endm + + .macro trace_rcu_read_lock +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + mrs x12, sp_el0 // current + ldr w13, [x12, #TSK_TRC_READER_NESTING] + add w14, w13, #1 + str w14, [x12, #TSK_TRC_READER_NESTING] + cbnz w13, .Ltrl_nested\@ // interrupted a reader: done + ldr_l x13, rcu_tasks_trace_srcu_struct + SRCU_SRCU_CTRP + str x13, [x12, #TSK_TRC_READER_SCP] + get_this_cpu_offset x14 + add x14, x14, x13 + add x14, x14, #SRCU_CTR_SRCU_LOCKS + trace_rcu_srcu_inc x14, x15, w16 +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB + dmb ish +#endif +.Ltrl_nested\@: +#endif + .endm + + .macro trace_rcu_read_unlock +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + mrs x12, sp_el0 // current + ldr w13, [x12, #TSK_TRC_READER_NESTING] + subs w13, w13, #1 + b.ne .Ltru_nested\@ + /* Outermost: pick up scp before an interrupt can see nesting == 0. */ + ldr x14, [x12, #TSK_TRC_READER_SCP] + str wzr, [x12, #TSK_TRC_READER_NESTING] +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB + dmb ish +#endif + get_this_cpu_offset x15 + add x14, x14, x15 + add x14, x14, #SRCU_CTR_SRCU_UNLOCKS + trace_rcu_srcu_inc x14, x15, w16 + b .Ltru_done\@ +.Ltru_nested\@: + str w13, [x12, #TSK_TRC_READER_NESTING] +.Ltru_done\@: +#endif + .endm + /* * Due to -fpatchable-function-entry=2, the compiler has placed two NOPs before * the regular function prologue. For an enabled callsite, ftrace_init_nop() and @@ -94,6 +160,8 @@ SYM_CODE_START(ftrace_caller) stp x29, x30, [sp, #FREGS_SIZE] add x29, sp, #FREGS_SIZE + trace_rcu_read_lock + /* Prepare arguments for the tracer func */ sub x0, x30, #AARCH64_INSN_SIZE // ip (callsite's BL insn) mov x1, x9 // parent_ip (callsite's LR) @@ -111,6 +179,8 @@ SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) bl ftrace_stub // func(ip, parent_ip, op, regs) #endif + trace_rcu_read_unlock + /* * At the callsite x0-x8 and x19-x30 were live. Any C code will have preserved * x19-x29 per the AAPCS, and we created frame records upon entry, so we need @@ -178,6 +248,10 @@ SYM_CODE_START(ftrace_stub_direct_tramp) SYM_CODE_END(ftrace_stub_direct_tramp) #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */ +/* End of [ftrace_caller, ...) for arch_rcu_tasks_trampoline_text(). */ +SYM_CODE_START(ftrace_static_tramp_end) +SYM_CODE_END(ftrace_static_tramp_end) + #else /* CONFIG_DYNAMIC_FTRACE_WITH_ARGS */ /* diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c index e1a3c0b3a051..5f4193f15cd9 100644 --- a/arch/arm64/kernel/ftrace.c +++ b/arch/arm64/kernel/ftrace.c @@ -17,6 +17,26 @@ #include #include +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +extern void ftrace_static_tramp_end(void); + +/* The SRCU-fast increments in entry-ftrace.S are the this_cpu_inc() form. */ +static_assert(!IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE)); + +/* + * See rcu_tasks_trampoline_text(). ftrace_caller and ftrace_stub_direct_tramp + * are core kernel text but must be treated as trampolines: a task interrupted + * in them outside the Tasks Trace reader may be carrying an ops pointer (x11) + * or a direct-call BPF trampoline address (x17) whose lifetime is guarded only + * by Tasks RCU. + */ +bool arch_rcu_tasks_trampoline_text(unsigned long ip) +{ + return ip >= (unsigned long)ftrace_caller && + ip < (unsigned long)ftrace_static_tramp_end; +} +#endif + #ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS struct fregs_offset { const char *name; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421722.1647487 (Exim 4.92) (envelope-from ) id 1x6T38-00076Q-Cb; Tue, 15 Sep 2026 13:18:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421722.1647487; Tue, 15 Sep 2026 13:18:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T38-000741-24; Tue, 15 Sep 2026 13:18:14 +0000 Received: by outflank-mailman (input) for mailman id 1421722; Tue, 15 Sep 2026 13:18:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T36-0006lz-Qp for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:18:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T36-00DQUc-7Q for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:18:12 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94591-e002-0a2a0a5209dd-0a2a4508dc0e-2 for ; Tue, 15 Sep 2026 15:18:12 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94593-f659-0a2a45080019-4a7de6ccf07f-3 for ; Tue, 15 Sep 2026 15:18:12 +0200 Received: by mail-qk2-f12.google.com with SMTP id d75a77b69052e-52fb76ef19aso34891141cf.2 for ; Tue, 15 Sep 2026 06:18:11 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-53104165737sm56777241cf.27.2026.09.15.06.18.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:18:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478290; x=1790083090; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4AdtdE/dNeJhNnC7k2tL4hzZr80UNkNMTy9M8Z5zSRM=; b=Ia5Eo53s0W2zmBu2Fg/1TT8MVq/bTXJk6UWoeAq8sWlBVnzxHGLju0NuMlvhegiTjp yfKodsDfVttFcUb7ivkshmnrZwBDZO8k3jRCyAm8OQVf7g9OffP1VX3P0ChMT6vubAKj hg0uIdYm4cooW8uEYyoQhSjWzRGNpldFiTGw+SmCTMPYKaQshOCRlS+IMUq991NypGTw ppLEhGpODK2vAqy83GpCESG6wKNCj8uH9/ndkAXGyZvWR/X11v24rgBKYd5nAq/Yb++h CK0ZVU8f7xCl3wv0Nwg9PO8UX1yz+IilPywxjkZ6+om8IHjpNePro3ew4q+ax/axOi27 XTWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478290; x=1790083090; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4AdtdE/dNeJhNnC7k2tL4hzZr80UNkNMTy9M8Z5zSRM=; b=GIKbeLvOtNiOjXyLyd929Xe79OmUZBy+Sf5PbttluYl231YS+UHNU1ukWOESoYjrlb dmzUYl5YRWKTsQXe7hdSrZ1rpJQ4HU1Qi9TXhv6HbNt/KfLNtjmeB1BTJ3UVh525ilFD kcKuAz4u1sXrA4oD1feVlW16FrGSwUCCdy2IFDR2Sh2B9xlUOyMsKS0slguby2ZLgvV/ HfQ8J8AP61xQ16ckFxqFqCl/rm96Lc0u9CZewgj8gwFi5ASsaLjS1xDHISXscEbE7ufT KtpOLE56dHxovloBBduGPp51lkUA9u9q4ADjvnWD9qhvgUivOHAa4ccFaLur1EySTenT zU5w== X-Forwarded-Encrypted: i=1; AKwUvBzpePRy76cO4oD8KbquCddLy4RiyqO9oSIPtlvivcOHoIPz6IqVOTCtEsHImhYHh/5dvvjSOqqRbX4=@lists.xenproject.org X-Gm-Message-State: AFuF++kqC5xOjrk29tcWrBrx8k00wsiUnPybMrIl4m3K7R1stQsUpo9L 7ZwbLpLa/PY9NuQIOBQI7lCyhZMML3//kwaqOwnYjopaOTyT0tiEst1TWsFghZYCSaw= X-Gm-Gg: AYBFou1rFkfWcJYDr/kbgDR+bzcWxsu/9r1iHo5GpdvqEzfp7rsA97Lm9CUIwWV3Z60 dL5TAoinwLYZRxAq8Z4nbGqYYvc9bPVNB8qaRM+QrrmtsQJQhJMfbxGmh1fZMO+buKxOYJtaowf VEbQI3oocKZAv4bsUrM5nQfy6hWzQeGpZvAKTzcGYiM+rQzucRnfTTKELUrJ9zqDxtewCmfQt/a MzBF+b/L/8PJIz59A73jpEhwwYRRbHL+6MilgwB0Pn98fHe6QHxTuAC3oc01p+3RGlA2hImcvNZ a9/oDLW/W5UP+8Lhtwc/IE+BhcoIEqytHMcQul7IYO6b/cvGF/eR/SgUNhf7uDRV/zG6GhEB2yA 6m2UQPrORUqshlP+dmsAzmGfFfhBE8dfzrAXcVqts2ekbj09iOuFZ8cy8IQqzn0jNFu5TW963k0 j5ZvZNDMWz8/dW2Wg2RwTzgDzvZFECGPc4xajx1SZtS48N21588SMAGZOSBeUO0Gw7j3xR0NSE/ nTmdk5Ife8nq5qPSGc7gpA0G1gAq+at6WLsBRlPvCOrM2mE8qkV1C2K X-Received: by 2002:ac8:5705:0:b0:530:e6b9:f5d9 with SMTP id d75a77b69052e-5310cf60dcamr104610221cf.20.1789478290432; Tue, 15 Sep 2026 06:18:10 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:39 +0000 Subject: [PATCH RFC v3 12/13] rcu-tasks-trace: Assert no reader is held on return to userspace MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-12-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=2589; i=josef@toxicpanda.com; h=from:subject:message-id; bh=a8x0095kiaPfODWOL6BE+0O7E5TXMNLRrf+m1qUM63A=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QNQ+h4Rgq+uBTWY42BKURCuzv1XjZ1QDbD5nWJycO3HnjSRSDGwSoVc9aADl5pV0kBRcRtS0O1v XzhUhrtoXcQU= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1789478292-D715E87B-EDF34101/0/0 X-purgate-type: clean X-purgate-size: 2591 With trampolines and their glue now taking rcu_read_lock_trace() from assembly and from several C paths, an unbalanced reader would silently turn every later Tasks Trace grace period on that task into a stall. No task can legitimately reach userspace with current->trc_reader_nesting non-zero, so under CONFIG_PROVE_RCU check it in the generic entry code's return-to-user validation, next to the existing kmap and lockdep assertions. Compiles away otherwise. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/irq-entry-common.h | 2 ++ include/linux/rcupdate_trace.h | 7 +++++++ 2 files changed, 9 insertions(+) diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index b811b469b0a7..58086cc1140c 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -214,6 +215,7 @@ static __always_inline void __exit_to_user_mode_validate(void) { /* Ensure that kernel state is sane for a return to userspace */ kmap_assert_nomap(); + rcu_tasks_trace_assert_idle(); lockdep_assert_irqs_disabled(); lockdep_sys_exit(); } diff --git a/include/linux/rcupdate_trace.h b/include/linux/rcupdate_trace.h index 4035054309d7..f5a51de4a4ef 100644 --- a/include/linux/rcupdate_trace.h +++ b/include/linux/rcupdate_trace.h @@ -209,6 +209,12 @@ unsigned long rcu_tasks_trace_batches_completed(void); // Placeholders to enable stepwise transition. void __init rcu_tasks_trace_suppress_unused(void); +/* A task must never reach userspace inside an rcu_read_lock_trace() reader. */ +static inline void rcu_tasks_trace_assert_idle(void) +{ + WARN_ON_ONCE(IS_ENABLED(CONFIG_PROVE_RCU) && READ_ONCE(current->trc_reader_nesting)); +} + #else static inline unsigned long rcu_tasks_trace_batches_completed(void) { return 0; } /* @@ -218,6 +224,7 @@ static inline unsigned long rcu_tasks_trace_batches_completed(void) { return 0; static inline void call_rcu_tasks_trace(struct rcu_head *rhp, rcu_callback_t func) { BUG(); } static inline void rcu_read_lock_trace(void) { BUG(); } static inline void rcu_read_unlock_trace(void) { BUG(); } +static inline void rcu_tasks_trace_assert_idle(void) { } #endif /* #ifdef CONFIG_TASKS_TRACE_RCU */ DEFINE_LOCK_GUARD_0(rcu_tasks_trace, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421723.1647499 (Exim 4.92) (envelope-from ) id 1x6T3A-0007bC-Lz; Tue, 15 Sep 2026 13:18:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421723.1647499; Tue, 15 Sep 2026 13:18:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T3A-0007aK-F2; Tue, 15 Sep 2026 13:18:16 +0000 Received: by outflank-mailman (input) for mailman id 1421723; Tue, 15 Sep 2026 13:18:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T38-00074x-Ah for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:18:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T37-00EGI1-MW for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:18:13 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94590-bab6-0a2a0a5309dd-0a2a450489ce-18 for ; Tue, 15 Sep 2026 15:18:13 +0200 Received: from [74.125.227.12] (helo=mail-vs2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94593-b57f-0a2a45040019-4a7de30cbd05-3 for ; Tue, 15 Sep 2026 15:18:12 +0200 Received: by mail-vs2-f12.google.com with SMTP id 71dfb90a1353d-5c67e512ee9so1127535e0c.0 for ; Tue, 15 Sep 2026 06:18:12 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f4963fcsm120754396d6.33.2026.09.15.06.18.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:18:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478291; x=1790083091; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Nk/uI/WquaXkRgHHd/dzhScVzrCkrWpp6IlwsBXJcUg=; b=pXVsR5dYFAoWs1wwFqDGtidGpav0t5q/yeKDCAV9WIN+qdkniY3aaxSuXkio5z6Qro W/km9W3Ov9cMbAOgjNBrwBsYPIFCXRwaZyqNCAuEEEx5HnCAYAgXP+qt/g2meOi69+vp j482wcmBRmHONA/PuWfHX1vsbQHg8K6BR3Zbds4X6KPC2FLsrzH5NCHGSBLvpojW2XhO OV1lYwDH6o0xuZ2blu65SGNgef/plro+Lhixz2a9ouNL0lk2oOdzfaNXoIAi1dGcMKVl 73SzzAaWZob6nGBVGtqAFm6Dv28sIgNJtL24hZ6bfYt7T9fMTpsia/svbhO/ay5QPfgl AOEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478291; x=1790083091; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Nk/uI/WquaXkRgHHd/dzhScVzrCkrWpp6IlwsBXJcUg=; b=AR33XRIMOjYLwELvIyB1QwjfBr+NiweIyf0GV4sI4u6JalE6XdFpB33yRltQ9wWC8k ZbTfQWU/DwW/ixdeDIiTp/WzLlFsqdBE9xh1MoIW/uY2mYWUCFxN/DnDfxgXsy+kGt8v V1YN/eNBHL7/HwJUDdZ166e5vwmv/8vutfGktG4SHqZWJOl3ip7fz+Qrn6QuST9GUfh2 KvurGIKw1J1EwnHiFDKOy59nRC6hhTxuPzBQtzYH4br09DMkwG/CkeC0KDGVKAHSGY9X ycecqt8RZxA3D4w/qrQ4ToI4SMMuwmTm91uXk6L12jLXVu668bAqWCSc1yhEW4nuPrMM 0qGQ== X-Forwarded-Encrypted: i=1; AKwUvBwOI8WngVSn9DzbHqkS74yf5ZvWrUdvldpuoti5yNX+z/PquKKfH1A7ZNFBEIEiiDbwJWbKickuYn4=@lists.xenproject.org X-Gm-Message-State: AFuF++msoTIUyumgJw+wuVoRAPUIIpm+y5rxZuZSklAyYo/1xDnKtFXj 9TCGY5RUaBcYHzIbv0xBBfANYFs6r0elwPafjhoEKrPrP2ZoJU8kaaepKHfyzlCZ9Dg= X-Gm-Gg: AYBFou3H848TgoaaT8xWJCV5xHQCRqW89nehqolA759s/M25Pm/w8fSLSujpFcfKvqL iiffxkn79N/0MLpok/xEVV+yxF+kInsZKkshNS76rNnSGlUoYoVwXqFvYBMupf/I10iDDu8vSMQ +gAOJwA5K3iIyGBUguwmp2MWsKaZfMPYo+XkreWJON/IOBcXEBtj6Fq85vpoCcEmHP/FJ/AFVBC F729Qz6YJ7lgSJf2AnsKiWKCWHKpO+x4BhDwrQvJ0mo3MJcohuwV3iaMtncfJxVT7JJNVVzRkFB 3zBk82trhEfhX3w3HNv8gq3wj6D1/zPSRsExqaDx/bjXF3hnute4CDFzlwxBg35aH/pP8benubw bqFXm2jhSEku0XEl/deq++Z35J3jlQNIwRcpZ+jttAnJOWBjOPhIhA14DPicfcVmM3YDu7OmgGV UMNCTHHvFF96JaYgEM/YO4E03lDaj9AtuTkUKQrghYvgYM6tBwAzP3EGTsKLerDM1LT02uVFllF 0NX0MSIkJpUIg90NP7V3fSJ8f+/k2+r7boozTVfucQbcjp5+Wp7Gukw X-Received: by 2002:a05:6122:547:b0:5c8:2ad8:1484 with SMTP id 71dfb90a1353d-5c981ad6d23mr8006048e0c.1.1789478286304; Tue, 15 Sep 2026 06:18:06 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:37 +0000 Subject: [PATCH RFC v3 10/13] samples: ftrace: Make the direct-call trampolines Tasks Trace readers MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-10-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=13193; i=josef@toxicpanda.com; h=from:subject:message-id; bh=I7rYeQZ4spsxQVfaE2Sayb+dFXGxTZqIS2lZCUAJvtU=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QPOtf94yWU2d+WH5tRovPgYME0ctrPN2IFl8MP+VQNtbbXuFRpRyfsP4CCmH0G4Kr6G14TpI5yJ WZ3+go910yQc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1789478292-506DAB50-3D18CE3C/0/0 X-purgate-type: clean X-purgate-size: 13195 The sample direct trampolines are exactly the kind of out-of-line register_ftrace_direct() user whose lifetime depends on Tasks RCU waiting for a task inside them: nothing else stops rmmod while a task is preempted in my_direct_func(). On HAVE_RCU_TRAMPOLINE_READERS architectures that wait only covers Tasks Trace RCU readers, so give the samples a small shared header with rcu_read_lock_trace() and rcu_read_unlock_trace() open-coded as instruction strings for x86-64 and arm64 -- the same sequences as ftrace_64.S and entry-ftrace.S, using caller-saved non-argument scratch registers -- and bracket every call-out with them. The instructions outside the bracket are module text, covered by ftrace_direct_mark_module(). Other architectures get empty definitions. Assisted-by: LLM Signed-off-by: Josef Bacik --- samples/ftrace/ftrace-direct-modify.c | 9 ++ samples/ftrace/ftrace-direct-multi-modify.c | 9 ++ samples/ftrace/ftrace-direct-multi.c | 5 ++ samples/ftrace/ftrace-direct-too.c | 5 ++ samples/ftrace/ftrace-direct.c | 5 ++ samples/ftrace/ftrace-direct.h | 126 ++++++++++++++++++++++++++++ 6 files changed, 159 insertions(+) diff --git a/samples/ftrace/ftrace-direct-modify.c b/samples/ftrace/ftrace-direct-modify.c index 164d9dd6fd92..937c8d8c2a1b 100644 --- a/samples/ftrace/ftrace-direct-modify.c +++ b/samples/ftrace/ftrace-direct-modify.c @@ -2,6 +2,7 @@ #include #include #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -73,7 +74,9 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " call my_direct_func1\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp1, .-my_tramp1\n" @@ -85,7 +88,9 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " call my_direct_func2\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp2, .-my_tramp2\n" @@ -141,11 +146,13 @@ asm ( " .globl my_tramp1\n" " my_tramp1:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #16\n" " stp x9, x30, [sp]\n" " bl my_direct_func1\n" " ldp x30, x9, [sp]\n" " add sp, sp, #16\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp1, .-my_tramp1\n" @@ -153,11 +160,13 @@ asm ( " .globl my_tramp2\n" " my_tramp2:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #16\n" " stp x9, x30, [sp]\n" " bl my_direct_func2\n" " ldp x30, x9, [sp]\n" " add sp, sp, #16\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp2, .-my_tramp2\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-multi-modify.c b/samples/ftrace/ftrace-direct-multi-modify.c index b03766c6217b..e12e5c8b83f0 100644 --- a/samples/ftrace/ftrace-direct-multi-modify.c +++ b/samples/ftrace/ftrace-direct-multi-modify.c @@ -2,6 +2,7 @@ #include #include #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -77,10 +78,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func1\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp1, .-my_tramp1\n" @@ -92,10 +95,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func2\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp2, .-my_tramp2\n" @@ -154,6 +159,7 @@ asm ( " .globl my_tramp1\n" " my_tramp1:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -162,6 +168,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp1, .-my_tramp1\n" @@ -169,6 +176,7 @@ asm ( " .globl my_tramp2\n" " my_tramp2:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -177,6 +185,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp2, .-my_tramp2\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-multi.c b/samples/ftrace/ftrace-direct-multi.c index 3fe6ddaf0b69..a970464ed378 100644 --- a/samples/ftrace/ftrace-direct-multi.c +++ b/samples/ftrace/ftrace-direct-multi.c @@ -3,6 +3,7 @@ #include /* for handle_mm_fault() */ #include +#include "ftrace-direct.h" #include #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include @@ -56,10 +57,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -101,6 +104,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -109,6 +113,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-too.c b/samples/ftrace/ftrace-direct-too.c index bf2411aa6fd7..abc098c2ab7a 100644 --- a/samples/ftrace/ftrace-direct-too.c +++ b/samples/ftrace/ftrace-direct-too.c @@ -3,6 +3,7 @@ #include /* for handle_mm_fault() */ #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -61,6 +62,7 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " pushq %rsi\n" " pushq %rdx\n" @@ -70,6 +72,7 @@ asm ( " popq %rdx\n" " popq %rsi\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -110,6 +113,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #48\n" " stp x9, x30, [sp]\n" " stp x0, x1, [sp, #16]\n" @@ -119,6 +123,7 @@ asm ( " ldp x0, x1, [sp, #16]\n" " ldp x2, x3, [sp, #32]\n" " add sp, sp, #48\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct.c b/samples/ftrace/ftrace-direct.c index 5368c8c39cbb..99b65ad2fccc 100644 --- a/samples/ftrace/ftrace-direct.c +++ b/samples/ftrace/ftrace-direct.c @@ -3,6 +3,7 @@ #include /* for wake_up_process() */ #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -54,9 +55,11 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " call my_direct_func\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -97,6 +100,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -104,6 +108,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct.h b/samples/ftrace/ftrace-direct.h new file mode 100644 index 000000000000..726f67048ff5 --- /dev/null +++ b/samples/ftrace/ftrace-direct.h @@ -0,0 +1,126 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef _SAMPLES_FTRACE_DIRECT_H +#define _SAMPLES_FTRACE_DIRECT_H + +#include + +/* + * A direct-call trampoline is entered with no lock, refcount or RCU marker + * held; only Tasks RCU keeps it (and, for a module, its text) alive while a + * task is inside it or preempted in something it called. On architectures + * that select HAVE_RCU_TRAMPOLINE_READERS, Tasks RCU only waits for such a + * task while it is a Tasks Trace RCU reader, so the trampoline must enter one + * before calling out and leave it afterwards, exactly like the ftrace and BPF + * trampolines do. See register_ftrace_direct(). The instructions before the + * lock and after the unlock are covered by ftrace_direct_mark_module(). + * + * These are rcu_read_lock_trace() / rcu_read_unlock_trace() open-coded as + * instruction strings for use inside the samples' asm() trampolines, after + * the versions in arch/x86/kernel/ftrace_64.S and + * arch/arm64/kernel/entry-ftrace.S. The scratch registers are caller-saved + * and not argument registers, so they are dead on entry to and exit from an + * fentry trampoline; the flags are clobbered. + * + * The generated asm-offsets.h is only pulled in on the architectures that need + * it here: it is not generally safe to include from C (e.g. PPC32's TASK_SIZE + * and arm64's TRAMP_VALIAS clash with the C definitions). + */ +#if defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) && defined(CONFIG_X86_64) + +#include + +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB +#define TRACE_RCU_MB " lock addl $0, -4(%rsp)\n" +#else +#define TRACE_RCU_MB +#endif + +#define TRACE_RCU_READ_LOCK \ + " movq %gs:current_task(%rip), %r11\n" \ + " movl " __stringify(TASK_trc_reader_nesting) "(%r11), %r10d\n" \ + " incl " __stringify(TASK_trc_reader_nesting) "(%r11)\n" \ + " testl %r10d, %r10d\n" \ + " jnz 771f\n" \ + " movq rcu_tasks_trace_srcu_struct+" __stringify(SRCU_srcu_ctrp) "(%rip), %r10\n" \ + " incq %gs:" __stringify(SRCU_CTR_srcu_locks) "(%r10)\n" \ + " movq %r10, " __stringify(TASK_trc_reader_scp) "(%r11)\n" \ + TRACE_RCU_MB \ + "771:\n" + +#define TRACE_RCU_READ_UNLOCK \ + " movq %gs:current_task(%rip), %r11\n" \ + " movl " __stringify(TASK_trc_reader_nesting) "(%r11), %r10d\n" \ + " subl $1, %r10d\n" \ + " jnz 772f\n" \ + " movq " __stringify(TASK_trc_reader_scp) "(%r11), %r10\n" \ + " movl $0, " __stringify(TASK_trc_reader_nesting) "(%r11)\n" \ + TRACE_RCU_MB \ + " incq %gs:" __stringify(SRCU_CTR_srcu_unlocks) "(%r10)\n" \ + " jmp 773f\n" \ + "772: movl %r10d, " __stringify(TASK_trc_reader_nesting) "(%r11)\n" \ + "773:\n" + +#elif defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) && defined(CONFIG_ARM64) + +#include +#include +/* arm64's asm-offsets.h redefines TRAMP_VALIAS from . */ +#pragma push_macro("TRAMP_VALIAS") +#undef TRAMP_VALIAS +#include +#pragma pop_macro("TRAMP_VALIAS") + +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB +#define TRACE_RCU_MB " dmb ish\n" +#else +#define TRACE_RCU_MB +#endif + +#define TRACE_RCU_SRCU_CTRP "rcu_tasks_trace_srcu_struct+" __stringify(SRCU_SRCU_CTRP) + +/* x14 = this CPU's offset; then atomically increment the long at x14 + \areg */ +#define TRACE_RCU_PERCPU_INC(areg) \ + ALTERNATIVE(" mrs x14, tpidr_el1\n", " mrs x14, tpidr_el2\n", \ + ARM64_HAS_VIRT_HOST_EXTN) \ + " add x14, x14, " areg "\n" \ + "778: ldxr x15, [x14]\n" \ + " add x15, x15, #1\n" \ + " stxr w16, x15, [x14]\n" \ + " cbnz w16, 778b\n" + +#define TRACE_RCU_READ_LOCK \ + " mrs x12, sp_el0\n" \ + " ldr w13, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + " add w14, w13, #1\n" \ + " str w14, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + " cbnz w13, 771f\n" \ + " adrp x13, " TRACE_RCU_SRCU_CTRP "\n" \ + " ldr x13, [x13, #:lo12:" TRACE_RCU_SRCU_CTRP "]\n" \ + " str x13, [x12, #" __stringify(TSK_TRC_READER_SCP) "]\n" \ + " add x13, x13, #" __stringify(SRCU_CTR_SRCU_LOCKS) "\n" \ + TRACE_RCU_PERCPU_INC("x13") \ + TRACE_RCU_MB \ + "771:\n" + +#define TRACE_RCU_READ_UNLOCK \ + " mrs x12, sp_el0\n" \ + " ldr w13, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + " subs w13, w13, #1\n" \ + " b.ne 772f\n" \ + " ldr x13, [x12, #" __stringify(TSK_TRC_READER_SCP) "]\n" \ + " str wzr, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + TRACE_RCU_MB \ + " add x13, x13, #" __stringify(SRCU_CTR_SRCU_UNLOCKS) "\n" \ + TRACE_RCU_PERCPU_INC("x13") \ + " b 773f\n" \ + "772: str w13, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + "773:\n" + +#else + +#define TRACE_RCU_READ_LOCK +#define TRACE_RCU_READ_UNLOCK + +#endif + +#endif /* _SAMPLES_FTRACE_DIRECT_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 13:18:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 13:18:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421727.1647504 (Exim 4.92) (envelope-from ) id 1x6T3B-0007h1-4n; Tue, 15 Sep 2026 13:18:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421727.1647504; Tue, 15 Sep 2026 13:18:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T3A-0007fn-TT; Tue, 15 Sep 2026 13:18:16 +0000 Received: by outflank-mailman (input) for mailman id 1421727; Tue, 15 Sep 2026 13:18:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6T39-0007K3-8d for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 13:18:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6T38-00EGE6-Ku for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:18:14 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa94592-8faa-0a2a0a5109dd-0a2a450ce112-12 for ; Tue, 15 Sep 2026 15:18:14 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa94595-f479-0a2a450c0019-4a7de68ca73b-3 for ; Tue, 15 Sep 2026 15:18:14 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-910531ea7feso1933546d6.0 for ; Tue, 15 Sep 2026 06:18:14 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9120f45cb06sm120943296d6.11.2026.09.15.06.18.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 06:18:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789478293; x=1790083093; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dyunHw12Wk9XaltfwN7bGL3PCRgKnyr3LfmugMg8Gj0=; b=kVbYizVvr0XDYxRwAlznzX16CEGNCN3e0SM703D6FCbOn8fYG0Av0OzdwoCCP1+j/J Nj4urZN8r1kEa2225NXa2HyIqnsh4vKC5qlxP7nTwmKJ/1a0PoSJl5zYSKm7+u62Bb/Y 8DpLL9kHOZYdk1PhBJvyiu/h4M0iroJRlJfj+OsPt1eT4Tb6ItC1ctPDeP1OqQA3cX0A nDrPQ2eiI271dhOy39WokDfTsO3CPTKjmAuHRK6Wm8PSEhNljdbkwJE/5ZNUVL+dkoIh JGTztFhWm+j6/phJ+WkEfcVOgktu9gcSuHnxeMiXsLerg+Uk7vUdoxQ3B5X2rcPxHY1R ZjhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789478293; x=1790083093; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=dyunHw12Wk9XaltfwN7bGL3PCRgKnyr3LfmugMg8Gj0=; b=jKom8/oJe6fK2hVMuCTHhhLTmWyxThvGGDqwQHUYbu6A0YmxwwAv1PigScEJnvywO7 /nG5gCxx3EHwf9AsUiPAmM/eM6hrbPSm7YoXrejwNzkWTWkquBgkI3P2R4VSSA62CD9g 6/VnOzglMrcGad3ltm9D+nxI3CmBIR2T/Bm+iOLdKleEyrZyj2+M+smnS2X6NYnNGoSj atSZX7ewMwiyNRig+porICRCkvqCssGvQBil/VtvelPXtSI5usAiVdAwLstYy4fV7Z0V 49U90HCm+mypkfJjHzgWzpMjQhlKjMrsmBDYq8KfzcfjGFZ2V6hLzQ/e1wK82+YlcECh ubCw== X-Forwarded-Encrypted: i=1; AKwUvBz7NUpxt9ZhDbWyFmS/a1O+CMhHqGYFcr2wXSZseC+PBAEbzEhP/D2GJikSFkrTOxvLP7J6mcZML8w=@lists.xenproject.org X-Gm-Message-State: AFuF++lpdYITDE3mXKMJrsizMM7cy5eFISlK5bSUsk9+4aTOfUE/o9jr 7REPbRFoX7ilsHQRFc9KwYRPORXFDD+UDCVZR1JI7R6plNemN5yZsxifBjCorZvud+w= X-Gm-Gg: AYBFou3arBiSY2czv/WL9oh5IY3mK9KIXu1SM9QKOalV4i/PYjLTQlDL83/v8uSwruQ NcFB1bRn0Ev95sUTrReT7EamrqajR32/tS6ADXNvr0UOWkh3gmJE5zJJC4Mxowmx9UFZPG7Q7p5 Qc3PFAyW8Er3rsIbBfzOqW6AHoyHhlAmHALHdhgzq4HbH1zcLOGY0rleas4PWcu2ptpGXTaf0SS 0O0+xTJrVhOE8B8sdjh6Ki8IsMGXG09okE3vaXCY/HyhNiGyA6AxOY0rm8mHEWumexGnWuDM4Ie sNmJ9/iSHa7iVEB8k2sVVmiLUY4Q8a70YIW6YezhaR/DIzduePiy6aCknDM7ls78ttZT7NkMmH/ nPf4qrIvMExYqwStddkSLUeRj3Qz5eANdeN3hlqO6iFyeLV+kGM5zqZIWnK7+TRqLB1xELWwG37 bqxem6Axva2VPTJvHg69lhJo2yvMmjUjGU+5xdX7QvvMpxOrMzDGGwxatN4jPgAuN3Exx1AlIUx ycfWTtd0091SKn7TdSx14w7y77SCWbP/j1zz4Wi3UhLh0QI53hMqs22 X-Received: by 2002:ad4:594b:0:b0:910:4c56:76d8 with SMTP id 6a1803df08f44-9123a42ec8fmr14508336d6.1.1789478292499; Tue, 15 Sep 2026 06:18:12 -0700 (PDT) From: Josef Bacik Date: Tue, 15 Sep 2026 13:17:40 +0000 Subject: [PATCH RFC v3 13/13] x86, arm64: Build Tasks RCU on Tasks Trace readers in trampolines MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260915-b4-rcu-tasks-preempt-qs-v3-13-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789478262; l=5993; i=josef@toxicpanda.com; h=from:subject:message-id; bh=R9t47tbzDpBlKabnqSyLf9h+YtCy+mgQn2kYE1SNKlg=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLrYYFTmT4yc2HnPNOm135tMG3u8qPYsi+9GRPNIPdwz0QfAjvOD+lsxTwptmj0sG65nDpJ4ULX TbSFHTaStyQI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d25034/1789478294-00ACCA5B-2A63553D/0/0 X-purgate-type: clean X-purgate-size: 5995 With the preceding patches every trampoline whose lifetime Tasks RCU guards on x86-64 and arm64 -- ftrace_caller and its copies, the optprobe template, BPF trampolines via their glue, and the sample direct-call trampolines -- is a Tasks Trace RCU reader around its call-out, and the text outside that reader is known to rcu_tasks_trampoline_text(). Select HAVE_RCU_TRAMPOLINE_READERS on both (x86-64 with SMP for Tree SRCU and DYNAMIC_FTRACE, which is where its ftrace_caller changes and arch_rcu_tasks_trampoline_text() live; arm64 with DYNAMIC_FTRACE_WITH_ARGS likewise), which switches CONFIG_TASKS_RCU to the implementation added earlier in the series: a Tasks RCU grace period becomes a per-CPU pass over context switches and irq-exit reschedules outside trampoline text plus a Tasks Trace grace period, bounded by a few jiffies and preempt-off latency instead of by the longest stretch any task runs without sleeping. Other architectures keep the classic implementation. Update Documentation/RCU and the FORCE_TASKS_RCU help text to describe the variant and the obligation it places on trampolines. Assisted-by: LLM Signed-off-by: Josef Bacik --- .../RCU/Design/Requirements/Requirements.rst | 20 ++++++++++++++++++++ Documentation/RCU/checklist.rst | 7 ++++++- arch/arm64/Kconfig | 1 + arch/x86/Kconfig | 1 + kernel/rcu/Kconfig | 6 ++++-- 5 files changed, 32 insertions(+), 3 deletions(-) diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 8101fe6229d5..34b81512cc5f 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -2756,6 +2756,26 @@ synchronize_rcu(), and rcu_barrier(), respectively. In three APIs are therefore implemented by separate functions that check for voluntary context switches. +Architectures that select ``CONFIG_HAVE_RCU_TRAMPOLINE_READERS`` keep the +same three APIs but implement the grace period differently +(``CONFIG_TASKS_RCU_TRAMPOLINE_READERS``). There, every trampoline whose +lifetime Tasks RCU guards enters a Tasks Trace RCU read-side critical +section (rcu_read_lock_trace() or its assembly equivalent) before calling +out and leaves it before returning, so a task anywhere inside such a +call-out is an ordinary Tasks Trace reader whether or not it is +preempted. The few trampoline instructions outside that reader can only +be occupied by a task that was interrupted there, so the grace period +additionally waits for each CPU to pass through a context switch, and the +irq-exit preemption path, the only switch that can catch a task inside +such text (rcu_tasks_trampoline_text()), briefly makes such a task a +holdout until it is next seen elsewhere. On such kernels an involuntary +context switch outside trampoline text *is* a Tasks-RCU quiescent state, +a Tasks RCU grace period no longer depends on how long any task runs +without sleeping, cond_resched_tasks_rcu_qs() is unnecessary, and the +obligation moves to the trampolines: anything that relies on +synchronize_rcu_tasks() to protect code a task may be preempted in must +take the Tasks Trace reader (see register_ftrace_direct()). + Tasks Rude RCU ~~~~~~~~~~~~~~ diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 4b30f701225f..7082686cbd66 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -252,7 +252,12 @@ over a rather long period of time, but improvements are always welcome! a. If the updater uses synchronize_rcu_tasks() or call_rcu_tasks(), then the readers must refrain from executing voluntary context switches, that is, from - blocking. + blocking. On architectures that select + CONFIG_HAVE_RCU_TRAMPOLINE_READERS a reader must in + addition be a Tasks Trace RCU reader (that is what the + trampolines there do around their call-outs); an + arbitrary stretch of preemptible kernel code is not + protected. b. If the updater uses call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then the diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b5a51b0ef944..bf0e56006863 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -218,6 +218,7 @@ config ARM64 select HAVE_PERF_REGS select HAVE_PERF_USER_STACK_DUMP select HAVE_PREEMPT_DYNAMIC_KEY + select HAVE_RCU_TRAMPOLINE_READERS if DYNAMIC_FTRACE_WITH_ARGS select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_RELIABLE_STACKTRACE select HAVE_POSIX_CPU_TIMERS_TASK_WORK diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 15fd9ec5ecac..64c3814eb745 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -288,6 +288,7 @@ config X86 select MMU_GATHER_RCU_TABLE_FREE select MMU_GATHER_MERGE_VMAS select HAVE_POSIX_CPU_TIMERS_TASK_WORK + select HAVE_RCU_TRAMPOLINE_READERS if X86_64 && SMP && DYNAMIC_FTRACE select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_RELIABLE_STACKTRACE if UNWINDER_ORC || STACK_VALIDATION select HAVE_FUNCTION_ARG_ACCESS_API diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index bbab14bc14c3..341b68b972ef 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -95,8 +95,10 @@ config FORCE_TASKS_RCU help This option force-enables a task-based RCU implementation that uses only voluntary context switch (not preemption!), - idle, and user-mode execution as quiescent states. Not for - manual selection in most cases. + idle, and user-mode execution as quiescent states, or, on + HAVE_RCU_TRAMPOLINE_READERS architectures, the variant built on + Tasks Trace RCU readers in trampolines. Not for manual + selection in most cases. config NEED_TASKS_RCU bool -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 15 15:11:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 15:11:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421893.1647516 (Exim 4.92) (envelope-from ) id 1x6UoN-0001Gu-HN; Tue, 15 Sep 2026 15:11:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421893.1647516; Tue, 15 Sep 2026 15:11:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6UoN-0001Gn-Eh; Tue, 15 Sep 2026 15:11:07 +0000 Received: by outflank-mailman (input) for mailman id 1421893; Tue, 15 Sep 2026 15:11:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6UoL-0001GO-7b for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:11:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6UoK-00HDv8-2Y for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 17:11:04 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa96004-bab6-0a2a0a5309dd-0a2a4507946e-10 for ; Tue, 15 Sep 2026 17:11:03 +0200 Received: from [40.93.194.38] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa96004-b4ea-0a2a45070019-285dc2262173-3 for ; Tue, 15 Sep 2026 17:11:02 +0200 Received: from SJ0P220CA0019.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::35) by IA1PR12MB6233.namprd12.prod.outlook.com (2603:10b6:208:3e7::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Tue, 15 Sep 2026 15:10:55 +0000 Received: from BY1PEPF00026966.namprd05.prod.outlook.com (2603:10b6:a03:41b:cafe::98) by SJ0P220CA0019.outlook.office365.com (2603:10b6:a03:41b::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Tue, 15 Sep 2026 15:10:54 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BY1PEPF00026966.mail.protection.outlook.com (10.167.244.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Tue, 15 Sep 2026 15:10:54 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 15 Sep 2026 10:10:53 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 15 Sep 2026 10:10:50 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vWIHfdx2yvo2ifZSfC8Rt1yqiB83ZqBHUkaW2xM4PAqRKMHZW2DZb/4E82CRUKpqJC9Kym77OnGQWy89r18GcREPL9Itgh+eNr57NxdJAJlBJSSE1m+zU1YFScMkGzSIGw7nFbnkEGbzEEOhwDTt7OsHGqtHILogXFQuWJouORVCc5quQsyUYxV4A3SY6IPGE8DclbKw22hlWsFNgk8bNxX8Q++KnnoVWpZGAWJNY6TW03kbP4w9AuE0bLRIZYoTHKkYqtGz3dK3NAJ3SBFrdW5coaVSrgGpb/tVTqPaGO4jFgcaQr5PGCAQshrA0KsVGqivfz1fb+LUKk67AkcMAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qlRb2gesJ/feywV2dEBLlDH3IlnkEBKEj38S1Cmyy1M=; b=I6aqAXpP/SInA8w00WAZzSuOQaBr1k5UvQzrRC0DIRC1JnPb1/uF8DEv4RxABNLyf9RdiI49m3zvcH4ib1/mNqLkiZEZ+rZ4REE5vZSwd5pcs/EtLQqMkysfs7A9NwvxfogbB4ImMdPf34p10TXb+UPvx4qMbiyeuZq6FfNx0a9cUuXlb+HWrzi+LUVsq8R70R6Lx/JnFJB+gXyNU7igynufKcfZfAub4oiaONoLOorUQspZ6C3Ls4yYKMAjJMWPNsmrL8jSt8d1tH+UvRmbIpXU3lHfov8ghPIYvbfmGIgwh8l6sLwP6qlwZJA8r7je53ocSqbsvTLvMZgU9oDyCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qlRb2gesJ/feywV2dEBLlDH3IlnkEBKEj38S1Cmyy1M=; b=DURdfjvimofBwOm/N+DN3CkNzqFqPF5Ztl718ePkzrQyxblXb/IUr1an/gy7udchXW+lpKGE6mq62qXZFT6Jk7X3bvnm+pPWVNZXeeZKQe9c5Dc29oZg0Py1UhFxVnNBdlzKHgSJFT9p2uA1eHwCyfTvV+yDTtUIAI/DuVyfQcI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Tue, 15 Sep 2026 17:10:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/6] ARM/sysctl: Expose the supported guest GIC modes in physinfo To: Julian Vetter , CC: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130862.8631fc262581453bbf619ec5b2062170.1a090827031000c4f3@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1789130862.8631fc262581453bbf619ec5b2062170.1a090827031000c4f3@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PEPF00026966:EE_|IA1PR12MB6233:EE_ X-MS-Office365-Filtering-Correlation-Id: 676102be-cb34-4d21-e809-08df133b89be X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|82310400026|36860700016|23010399003|1800799024|10067099003|56012099006|5023799004|11063799006|4143699003|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: BFJ2tLQhmsOZk81RbyCFsNaTXLRfkCmEY/XSfVGmndNHzc5Ty+ylpbmFrNLZjDxAwl66LoRzwhygxAo2KMzig/BLmlvhXthnrpi8vaZFgV7xvZw5puwTNi0wtNfBMNjABNKqlKcM8u3dQ66tluy2oImOf3AjRREWumxNBvUjcYPzaDkybut6+YsifrFLEGL+sziODsGtqbQ2YMgeEw1jPbl6uf7AXRG3zYg7MpLr/RDwnQ6W6uSwZqOINTWfID3mxYzxtZQsQBBsl6IRHFX+gkwYhZ/S18q/STD76YEZb77GN78D2UonjNIkZXMNmrei6CI//Q+hz00Ftby2lLzHH3WnIDAUxjvY1zuCq6nwGfEE5XPh3zBL34FzWgyHd8KDJAFjbPJBOfGMQweJXz3xds+Zv4C9rzxKSMMSeCTuprSwB9+oBYEFLXwFjA+pJ1DSKcQdQddV+juO/NpCX9SLjz1vffv/FuK6KxbPhRZfIs0xQjqN24EYIEOquzOrGt68Zqh+zwSCNV4KY8+OXexunqnGYV0E8u0AENu/pjgDGp+i0lK0JnfCZVEDZi063LLP+ZFIuIN8cs9WzFt9laSH35bUNQ3rMIqMZkqlG9/5lskzUo1QOOiVXnDXWVUE0RjuNJXEwmKbD/RReyzkNUiwmXj2pJ0KnJjfGaRAY+uGMwqTF+ItZw9I4hHR9Svq+y/QH4wdTyf03mj6NR9sp/fysA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(82310400026)(36860700016)(23010399003)(1800799024)(10067099003)(56012099006)(5023799004)(11063799006)(4143699003)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: C4a1r/HhWkqC2O1AwqFl0SODcCGw0vdgT+cbiDVsn/94aOQ0b+MTxxbMboq1V8OTMVFIW46gPwmA1y1b6K4V0aWoF4pqCbf8rBsFOo3EaQKqJEPxplFWRdyweFtjpvTAo1Rjm4wz23TGTnaUDQ/Iol5cn467oUicVXTvliHAij3aEvw8BcfhD6Ly8lcgCLyqWpz/s/eSoMtLlT6cMq6OweVZChUUgcbhX4o0Fwq7Y0uWOFZVBsKsPttUOHGDMV6pyO8hmIzcUhZehf1fFrmM3ekdThaOInruFs1BWMpN1A9WYuCIOwM+d0Qa0g5fBD5+CAacXhG/6559O3O4QPJi0x+ub9yHC0BYyzf3vUOUCz5sRm6XEJiboLuWRgXMhuxQJjrHKsJ1TeSzV1CjBLkY7o5K0xlAgWlwhFz5F43Ky/BpqIecDXo5U5tZ3hsuRX4e X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2026 15:10:54.3862 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 676102be-cb34-4d21-e809-08df133b89be X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BY1PEPF00026966.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6233 X-purgate-ID: tlsNG-ef75cf/1789485063-A74D3AE4-CC83A485/0/0 X-purgate-type: clean X-purgate-size: 3725 On 11-Sep-26 14:47, Julian Vetter wrote: > From: Andrew Cooper > > In preparation to simplify the domain creation logic surrounding GIC > version. > > On a GICv3 host, also report support for GICv2-compatible guests when > the hardware's vGICv2 compatibility mode is enabled, rather than just > the native GIC version. > > Signed-off-by: Andrew Cooper > Signed-off-by: Julian Vetter > --- > Changes in v5: > - Add vgic_v2_hw_enabled() to new vgic implementation. > --- > xen/arch/arm/include/asm/vgic.h | 6 ++++++ > xen/arch/arm/sysctl.c | 34 +++++++++++++++++++++++++++++++++ > xen/arch/arm/vgic-v2.c | 5 +++++ > xen/arch/arm/vgic/vgic-v2.c | 5 +++++ > xen/include/public/sysctl.h | 2 ++ > 5 files changed, 52 insertions(+) > > diff --git a/xen/arch/arm/include/asm/vgic.h b/xen/arch/arm/include/asm/vgic.h > index 6f9ab1c98c..26c53aaf3c 100644 > --- a/xen/arch/arm/include/asm/vgic.h > +++ b/xen/arch/arm/include/asm/vgic.h > @@ -433,6 +433,12 @@ unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version); > void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize, > paddr_t vbase, uint32_t aliased_offset); > > +#ifdef CONFIG_VGICV2 > +bool vgic_v2_hw_enabled(void); > +#else > +static inline bool vgic_v2_hw_enabled(void) { return false; } > +#endif > + > #ifdef CONFIG_GICV3 > struct rdist_region; > void vgic_v3_setup_hw(paddr_t dbase, > diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c > index 32cab4feff..8411deb7e2 100644 > --- a/xen/arch/arm/sysctl.c > +++ b/xen/arch/arm/sysctl.c > @@ -12,7 +12,11 @@ > #include > #include > #include > + > #include > +#include > +#include > + > #include > > void arch_do_physinfo(struct xen_sysctl_physinfo *pi) > @@ -21,6 +25,36 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi) > > pi->arch_capabilities |= MASK_INSR(sve_encode_vl(get_sys_vl_len()), > XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK); > + > + /* > + * The GIC version(s) we're happy creating guests with. Right now for > + * simplicity it is tied to the active hardware version, but this will > + * cease to be the case if/when the compatibility modes are enabled. You carry on this comment but as we are now also informing about the legacy GICv2 mode (which was not there in v1) I no longer understand what it denotes and why we need it. I think we can drop this. > + */ > + switch ( gic_hw_version() ) > + { > + case GIC_V2: > + pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V2; > + break; > + > + case GIC_V3: > + pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V3; > + > + /* GICv3 may additionally support GICv2-compatible guests. */ > + if ( vgic_v2_hw_enabled() ) > + pi->arch_capabilities |= XEN_SYSCTL_PHYSCAP_ARM_GIC_V2; > + break; > + > + case GIC_INVALID: Change to default please to make MISRA C R16.4 happy. > + /* > + * Running a control domain without having the GIC sorted yet? > + * Something's broken, but there's nothing we can do about it here. > + */ > + ASSERT_UNREACHABLE(); > + printk_once(XENLOG_ERR "Unrecognised GIC version %d\n", > + gic_hw_version()); Please swap the printk with ASSERT. With these remarks addressed: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 15 15:14:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 15:14:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421901.1647525 (Exim 4.92) (envelope-from ) id 1x6UrU-0001nS-Ua; Tue, 15 Sep 2026 15:14:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421901.1647525; Tue, 15 Sep 2026 15:14:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6UrU-0001nL-Rg; Tue, 15 Sep 2026 15:14:20 +0000 Received: by outflank-mailman (input) for mailman id 1421901; Tue, 15 Sep 2026 15:14:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6UrS-0001nF-JX for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:14:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6UrR-007SaN-Sq for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 17:14:17 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa960be-8faa-0a2a0a5109dd-0a2a4507846c-32 for ; Tue, 15 Sep 2026 17:14:17 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa960c8-b4ea-0a2a45070019-aceafc1fb58a-3 for ; Tue, 15 Sep 2026 17:14:17 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 5E6BF438B0; Tue, 15 Sep 2026 15:14:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C0DE1F000FF; Tue, 15 Sep 2026 15:14:14 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789485255; bh=X3+2zYRSpciM7uYDkfrVnfpdjazC9P6LhL6MmIorApI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=SGhRs7CyUcB+xKNzzgWZcvokGEOOVMOQJ3OETwnVY4jRSuKplqoTwyAHVl1KH+8b0 VNFp7fTkeI9e0+ZC+dM3TCI/46xIVfnf6Hk9+kbi2++thNjHW5PBB5/REKjWuWnhOX NsSD7M8d1YeI07hn49Tk4V15z8kJeBIKxKfhHx/GhLBjJYbwN3chruH08krEcNHwOL tIzZTpw/abh24Oe+viSlZfRNOaS6B5P91oMAkTKw/YqLk36i3YOHepcXc0roWktlD6 DjzlWtA6jsr6cBjFcAyGQ1ancIHd7wSK3XNR1o86hlnCFoVmiGndLQ4Fj8yQl/Cg9F e28SqUFMkedvA== Date: Tue, 15 Sep 2026 17:14:12 +0200 From: Frederic Weisbecker To: Josef Bacik Cc: "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> X-purgate-ID: tlsNG-ef75cf/1789485257-A62C4AE4-B676FA74/0/0 X-purgate-type: clean X-purgate-size: 15862 Le Tue, Sep 15, 2026 at 01:17:30PM +0000, Josef Bacik a crit : > Tasks RCU waits for every task to pass through a voluntary context > switch, usermode or idle, because a preempted task might be sitting in a > trampoline that is about to be freed and nothing marks it as such. With > PREEMPT_LAZY that is a poor fit for servers: cond_resched() is a no-op, > so a CPU-bound kthread only ever leaves the CPU by preemption, and one > such kthread holds every synchronize_rcu_tasks() caller -- ftrace and > BPF trampoline teardown under their mutexes, the kprobe jump optimizer > under text_mutex and cpus_read_lock() -- hostage for as long as it runs. > > Following the discussion on v2, take the other road: let the > architecture make its trampolines Tasks Trace RCU readers. When an > architecture selects HAVE_RCU_TRAMPOLINE_READERS it promises that every > trampoline whose lifetime Tasks RCU guards enters rcu_read_lock_trace() > (or its assembly equivalent) before calling out and leaves it before > returning, so a task anywhere inside such a call-out, preempted or not, > is an ordinary Tasks Trace reader. > > That leaves the few instructions of trampoline text before the reader > is entered and after it is left (plus, in a later patch, the bytes a > kprobe jump optimization is about to overwrite). A task can only linger > there by being interrupted there, and such text never calls anything > that schedules, so instead of tracking tasks we track CPUs: every pass > through __schedule() is a per-CPU quiescent event, except that the one > context switch that can catch a task at an arbitrary instruction -- a > preemption from irq exit -- first records the interrupted IP in the task > and parks it on a per-CPU list for the duration (reusing the fields and > lists the classic flavor keeps for its exit-path bookkeeping), and, if > the IP is inside such "unmarked" text, puts the task on a short holdout > list; the task takes itself off at its next context switch outside such > a preemption or irq-exit check that finds it elsewhere. Usermode (the > existing tick hook, or a nohz_full CPU in an RCU extended quiescent > state) and idle count as well. rcu_tasks_trampoline_text() does the > classification: anything outside core and module text, a new > .text..rcu_tramp section for C glue that trampolines call before it has > entered the reader (__rcu_trampoline), and an arch hook for things like > static ftrace stubs and return thunks. > > The grace period, run by the existing rcu_tasks kthread so that > call_rcu_tasks(), synchronize_rcu_tasks() and rcu_barrier_tasks() keep > their names and callers, is: wait for every online non-idle CPU to > context switch (nudging stragglers with resched_cpu() after a jiffy), > drain the holdout list as it stood, synchronize_rcu_tasks_trace() for > everything inside the readers, then one more CPU pass and drain for > tasks that have since left the reader into the trailing instructions. > That is bounded by a few jiffies, preempt-off latency and an SRCU grace > period rather than by the longest stretch any task runs without > sleeping, needs no per-task scan, and makes cond_resched_tasks_rcu_qs() > unnecessary on such architectures. As before, idle tasks are not > waited for. rcu_tasks_wait_irq_preempted() walks the parked lists for > the one caller (the kprobe jump optimizer, later in the series) that > makes ordinary text unsafe to be parked in and so has to wait out tasks > that were preempted there before it said so. > > The classic implementation is untouched and remains the default; the > new one is built only as CONFIG_TASKS_RCU_TRAMPOLINE_READERS when the > architecture opts in and uses the generic irq entry code, whose > reschedule check gains the rcu_tasks_irq_resched() call. Nothing > selects it yet. > > Suggested-by: Paul E. McKenney > Suggested-by: Alexei Starovoitov > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > include/asm-generic/vmlinux.lds.h | 11 + > include/linux/rcupdate.h | 32 ++- > include/linux/sched.h | 1 + > kernel/entry/common.c | 8 +- > kernel/fork.c | 1 + > kernel/rcu/Kconfig | 22 ++ > kernel/rcu/tasks.h | 460 +++++++++++++++++++++++++++++++++++++- > kernel/rcu/update.c | 2 + > 8 files changed, 528 insertions(+), 9 deletions(-) > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > index b2988aa12f66..86e58c4fe370 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -571,6 +571,16 @@ > __cpuidle_text_end = .; \ > __noinstr_text_end = .; > > +/* > + * C glue called directly from Tasks-RCU-protected trampolines, bounded so > + * that rcu_tasks_trampoline_text() can recognise it; see __rcu_trampoline. > + */ > +#define RCU_TRAMP_TEXT \ > + ALIGN_FUNCTION(); \ > + __rcu_tramp_text_start = .; \ > + *(.text..rcu_tramp) \ > + __rcu_tramp_text_end = .; > + > #define TEXT_SPLIT \ > __split_text_start = .; \ > *(.text.split .text.split.[0-9a-zA-Z_]*) \ > @@ -607,6 +617,7 @@ > TEXT_HOT \ > *(TEXT_MAIN .text.fixup) \ > NOINSTR_TEXT \ > + RCU_TRAMP_TEXT \ > *(.ref.text) > > /* sched.text is aling to function alignment to secure we have same > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > index 44c07a66edff..fb2a3889a696 100644 > --- a/include/linux/rcupdate.h > +++ b/include/linux/rcupdate.h > @@ -50,6 +50,31 @@ token_context_lock_instance(RCU, RCU_BH); > /* Exported common interfaces */ > void call_rcu(struct rcu_head *head, rcu_callback_t func); > void rcu_barrier_tasks(void); > + > +/* > + * Trampoline-reader Tasks RCU (CONFIG_TASKS_RCU_TRAMPOLINE_READERS), see > + * kernel/rcu/tasks.h. rcu_tasks_irq_resched_enter()/_exit() bracket the > + * irq-exit preemption; rcu_tasks_trampoline_text() and the arch_ override > + * classify an interrupted IP; rcu_tasks_wait_irq_preempted() lets a caller > + * wait out tasks already preempted somewhere it is about to make unsafe. > + * __rcu_trampoline places C code that such trampolines call directly, before > + * it has entered its Tasks Trace reader, where that classification can see it. > + */ > +void rcu_tasks_irq_resched_enter(unsigned long ip); > +void rcu_tasks_irq_resched_exit(void); > +bool rcu_tasks_trampoline_text(unsigned long ip); > +bool arch_rcu_tasks_trampoline_text(unsigned long ip); > +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > +void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)); > +#else > +static inline void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)) { } > +#endif > +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > +/* Also keeps instrumentation calls out of the prologue, ahead of the reader. */ > +#define __rcu_trampoline __noinstr_section(".text..rcu_tramp") > +#else > +#define __rcu_trampoline > +#endif > void synchronize_rcu(void); > > /* > @@ -180,11 +205,16 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } > #ifdef CONFIG_TASKS_RCU_GENERIC > > # ifdef CONFIG_TASKS_RCU > -# define rcu_tasks_classic_qs(t, preempt) \ > +# ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > +void rcu_tasks_note_qs(struct task_struct *t, bool preempt); > +# define rcu_tasks_classic_qs(t, preempt) rcu_tasks_note_qs((t), (preempt)) > +# else > +# define rcu_tasks_classic_qs(t, preempt) \ > do { \ > if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ > WRITE_ONCE((t)->rcu_tasks_holdout, false); \ > } while (0) > +# endif > void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func); > void synchronize_rcu_tasks(void); > void rcu_tasks_torture_stats_print(char *tt, char *tf); > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 8b3d47a325cc..15beb44caa2c 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -957,6 +957,7 @@ struct task_struct { > u8 rcu_tasks_holdout; > u8 rcu_tasks_idx; > int rcu_tasks_idle_cpu; > + unsigned long rcu_tasks_irq_ip; > struct list_head rcu_tasks_holdout_list; > int rcu_tasks_exit_cpu; > struct list_head rcu_tasks_exit_list; > diff --git a/kernel/entry/common.c b/kernel/entry/common.c > index e4acd50bd81a..94318519998c 100644 > --- a/kernel/entry/common.c > +++ b/kernel/entry/common.c > @@ -6,6 +6,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -141,8 +142,13 @@ void raw_irqentry_exit_cond_resched(struct pt_regs *regs) > rcu_irq_exit_check_preempt(); > if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) > WARN_ON_ONCE(!on_thread_stack()); > - if (need_resched() && arch_irqentry_exit_need_resched()) > + if (need_resched() && arch_irqentry_exit_need_resched()) { > + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) > + rcu_tasks_irq_resched_enter(instruction_pointer(regs)); > preempt_schedule_irq(); > + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) > + rcu_tasks_irq_resched_exit(); > + } > } > } > #ifdef CONFIG_PREEMPT_DYNAMIC > diff --git a/kernel/fork.c b/kernel/fork.c > index 416758c8a3d4..8077336bb136 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1871,6 +1871,7 @@ static inline void rcu_copy_process(struct task_struct *p) > p->rcu_tasks_holdout = false; > INIT_LIST_HEAD(&p->rcu_tasks_holdout_list); > p->rcu_tasks_idle_cpu = -1; > + p->rcu_tasks_irq_ip = 0; > INIT_LIST_HEAD(&p->rcu_tasks_exit_list); > #endif /* #ifdef CONFIG_TASKS_RCU */ > #ifdef CONFIG_TASKS_TRACE_RCU > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > index 332df7a7a634..bbab14bc14c3 100644 > --- a/kernel/rcu/Kconfig > +++ b/kernel/rcu/Kconfig > @@ -107,6 +107,28 @@ config TASKS_RCU > default NEED_TASKS_RCU && PREEMPTION > select IRQ_WORK > > +config HAVE_RCU_TRAMPOLINE_READERS > + bool > + help > + Select this if the architecture uses the generic irq entry code and > + every trampoline whose lifetime Tasks RCU guards on it (ftrace > + trampolines, kprobe out-of-line and optimized-probe slots, BPF > + trampolines, out-of-line ftrace direct-call trampolines) enters a > + Tasks Trace RCU read-side critical section before calling out of > + the trampoline and leaves it before returning, and any core text > + that runs on behalf of such a trampoline outside that reader is > + reported by arch_rcu_tasks_trampoline_text(). The assembly readers > + use the this_cpu_inc() form of SRCU-fast, hence !NEED_SRCU_NMI_SAFE. > + > +config TASKS_RCU_TRAMPOLINE_READERS > + def_bool TASKS_RCU && HAVE_RCU_TRAMPOLINE_READERS && GENERIC_IRQ_ENTRY && !NEED_SRCU_NMI_SAFE > + select TASKS_TRACE_RCU > + help > + Implement the Tasks RCU grace period as a per-CPU pass over > + context switches and irq-exit reschedules outside trampoline text > + plus a Tasks Trace RCU grace period, instead of waiting for every > + task to voluntarily context switch. See kernel/rcu/tasks.h. > + > config FORCE_TASKS_RUDE_RCU > bool "Force selection of Tasks Rude RCU" > depends on RCU_EXPERT > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h > index 627295396cd9..3a7c092361a6 100644 > --- a/kernel/rcu/tasks.h > +++ b/kernel/rcu/tasks.h > @@ -152,7 +152,7 @@ static struct rcu_tasks rt_name = \ > .kname = #rt_name, \ > } > > -#ifdef CONFIG_TASKS_RCU > +#if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) > > /* Report delay of scan exiting tasklist in rcu_tasks_postscan(). */ > static void tasks_rcu_exit_stall(struct timer_list *unused); > @@ -802,7 +802,7 @@ static void rcu_tasks_torture_stats_print_generic(struct rcu_tasks *rtp, char *t > > #endif // #ifndef CONFIG_TINY_RCU > > -#if defined(CONFIG_TASKS_RCU) > +#if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) > > //////////////////////////////////////////////////////////////////////// > // > @@ -897,10 +897,445 @@ static void rcu_tasks_wait_gp(struct rcu_tasks *rtp) > rtp->postgp_func(rtp); > } > > -#endif /* #if defined(CONFIG_TASKS_RCU) */ > +#endif /* #if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) */ > > #ifdef CONFIG_TASKS_RCU > > +static int rcu_tasks_lazy_ms = -1; > +module_param(rcu_tasks_lazy_ms, int, 0444); > + > +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > + > +//////////////////////////////////////////////////////////////////////// > +// > +// Tasks RCU for architectures whose trampolines are Tasks Trace RCU > +// readers (CONFIG_HAVE_RCU_TRAMPOLINE_READERS). > +// > +// On these architectures every piece of text whose lifetime Tasks RCU > +// guards -- ftrace trampolines, kprobe optinsn slots, BPF trampoline > +// images, out-of-line ftrace direct-call trampolines -- enters a Tasks > +// Trace RCU read-side critical section before calling out of itself and > +// leaves it before returning, so a task anywhere inside such a call-out, > +// preempted or not, is an ordinary rcu_read_lock_trace() reader and > +// synchronize_rcu_tasks_trace() waits for it. > +// > +// What that cannot cover is the handful of instructions in the trampoline > +// before the reader is entered and after it is left, and the one user that > +// has no trampoline at all: the bytes after a kprobe that the jump > +// optimizer is about to overwrite. A task can only linger in such > +// "unmarked" text by being interrupted there; unmarked text never calls > +// anything that could schedule. So a context switch on a CPU tells us that > +// whatever that CPU was running is out of unmarked text, with one > +// exception: a preemption from the irq-exit path, which can happen at any > +// instruction boundary. That path has the interrupted pt_regs in hand, so > +// just before it preempts it records the IP in the task and checks it > +// (rcu_tasks_trampoline_text()); if it is inside unmarked text the task > +// goes on a short holdout list first, and takes itself off again at its > +// next context switch outside such a preemption or its next irq-exit > +// check that finds it elsewhere. With that, every pass through > +// __schedule() is a per-CPU quiescent event, as are usermode and idle. > +// > +// A grace period is then: > +// > +// 1. Wait for every online, non-idle CPU to context switch, nudging > +// stragglers with resched_cpu(). Afterwards no task is in the leading > +// unmarked instructions of a dying trampoline unless it is on the > +// holdout list. > +// 2. Wait for the holdout list (as it stood) to drain. > +// 3. synchronize_rcu_tasks_trace(), for everything inside the readers. > +// 4. Repeat 1 and 2 for tasks that have since left the reader and are in > +// the trailing unmarked instructions. Alternatively the approach could be generalized to vanilla RCU, it could be possible to define a .text.rcu_no_qs section within which code running is considered as an RCU reader (with a pause while on the explicit RCU tasks section). It would be forbidden to voluntary sleep inside and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). Based on IP, RCU could consider those interrupted section as readers. This would require PREEMPT_RCU though. And then synchronize_rcu() would do the 1, 2, 4 jobs. -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Tue Sep 15 15:45:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 15:45:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421923.1647551 (Exim 4.92) (envelope-from ) id 1x6VLj-0006Fq-DB; Tue, 15 Sep 2026 15:45:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421923.1647551; Tue, 15 Sep 2026 15:45:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6VLj-0006Fj-A2; Tue, 15 Sep 2026 15:45:35 +0000 Received: by outflank-mailman (input) for mailman id 1421923; Tue, 15 Sep 2026 15:45:34 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6VLi-0006Fd-09 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:45:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6VLh-007cxE-8e for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 17:45:33 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9680b-e002-0a2a0a5209dd-0a2a450cbe34-16 for ; Tue, 15 Sep 2026 17:45:33 +0200 Received: from [52.101.65.88] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9681c-f479-0a2a450c0019-346541582ec8-3 for ; Tue, 15 Sep 2026 17:45:33 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV1PR03MB10315.eurprd03.prod.outlook.com (2603:10a6:150:165::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.13; Tue, 15 Sep 2026 15:45:28 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.008; Tue, 15 Sep 2026 15:45:28 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iD7iRFaj9c1PV86ofe/ABzG9apnzRrIWOV7hT8XYHw90F206Sm1aX4JmXmgNgsEOuecAM5JyssbLqysC4hUuqHEnS4QkWvFR00Br4ysPYQNg/YfA5TDA5tL/QwZ3DbpcY4GqAUxWKmSPPV6+5wk3cJCjv6xnRA1Y6V+aMQ+igItS1ZFmTxYyJg3z6dzzbxqvVTblaA1OELQIJLtCNtM1X+VM8HwjYGvqsTBvqre6yO931EECUDyz2YMkVZpRfaHo2DIlK4c0lQhR5Fclars9YmkDFXw2FeJngRIMk2FThWCg3gD1F4bAxBGcgO9JUOhKep6pPk3Y0aVxBTB1KaTIdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HUdUZUlb93Zh7vFpmIMPuV2SWdtdN03aswJIXG1nxzU=; b=cc9d/QX/oCT+nqrjwaAilz/XvQtW0mINk9IsIM6EZlskHOIho4WzUvwcsszapZCQTP9FLtSCz1QzlE/bPn8wQO48Uc8KTb1wRDE+OY+1vqyySb+Q6kTYDnmaS1AbVatL/WWMZMEOROXQjDo27uTeC2lTYyLCkIPuGDzYse/c079t1QmpptsYiYJQbZEaiNXKQ6wyZGGnkA6Ir18Beh/PyB07KUUg41zKLBgyCx/wSefBiDics5F7C3uuWHZdb7O4hPZN+p5moNeNoMNp+nEUNRxa4QF3NekzRa7m1ta1VHENzYFCOMzlj3hfp24w3BIAqEQbW7OutQ6rjMp/EuNlPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HUdUZUlb93Zh7vFpmIMPuV2SWdtdN03aswJIXG1nxzU=; b=XxOwvWMRFPs+YTNhHMUK8SejfMFww5JhuKUbcFivqOUsn4KmPpPv9PXbYvyx0gKtMJ+m0SyfgxW6PttpwJ76ia7Rd+v0cblyl9Jpg2a63sEYDHNPpTkVvirsdcRNMT7u1RYPqJMm/NlyxCYjpAYuVbxYsitUYEXbb8MDVfpig8Kv1yWWTCWjrK+wKs7wc+2ZeTT/eRUMVkB9goU/+8bGR6dN7xaMrtIWIV+oZ0E0K9NsK3dS+Clb7ywN12OpjEqmIk+LLJ+Lor2kMm9bP731EGKVnkpmCEvewKp5tUnqS/2yogEeV3nhzthkAPq5XMft+8Ju4ukBf1aCF1rrv+DhJg== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers Thread-Index: AQHdQb7XwQvbnxLqDEGK19PLXXgae7bJAQCAgABYGQCABnW1gA== Date: Tue, 15 Sep 2026 15:45:28 +0000 Message-ID: References: <6bf8f9dd61da4d0fbea096b863f51db08df46c56.1789055542.git.oleksii_moisieiev@epam.com> <1d8be2c2-a56d-4b81-8e36-c4f97099c879@suse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV1PR03MB10315:EE_ x-ms-office365-filtering-correlation-id: 298dd45a-4e98-41ea-c047-08df13405db6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|366016|1800799024|23010399003|11063799006|5023799004|56012099006|3023799007|4143699003|10067099003|6133799003|18002099003|22082099003|38070700021; x-microsoft-antispam-message-info: BqX43QXjosfR2cVgOB441ZZVMusO0Qn6bhk/70fltPaQu3YwyIpfDrNBTv16ppu9MC+SJkkIq1cjaADQv8A/0SyPCifW/yF59tbHxVobZEkR+U2tErKmg4D/wYyKnn5U2in6a0Tp0i5xlndpAsvvUfhVW6qGaKbzf+P4s/PhSvJWXElaLm6MOJE0HcNtaj1iIwBXRRk8R84k049j2ykNmdaOKynUYxhEdlowFVneNvZlrL1Qg+TfbYIjDW7BhqUCaHJdBtwp4QjtBSo9lLUhm0nvUX1HwXjo+eWN2aVbYy5TjzgZ8ybs4h/Bc9+xr2/GeD3xEoZyGKc7MPTxXfudWATjYuS9HNfYWTIFKDS5Lcs8ztdEoLJnnCHHbWIjjwqML/Q6cMlZ+wrwA4ySm13lkoBsihLtXQzAwRyumtRqY8BRbYDEG1M7w0JrEPEAaH1FIub5lyWAKVu4/mGNyYWSN3T0nE1nnTZw8h1+ZeYiYSDFNQRcrpjm7FtEW9IUS50i1WK3hMRiF31w2rkyboVKd8CaQ4I1802wR6CWfuByZJOJ8PB+q1cG5aCBINRx3GacjEOu7yyeayZOdh1fa2q5SC1gEhVeX1TqF0Nu6JK2/4PLFZd3tAPLetS61CFtyG0Lo/zaXyzsJpJEXNhEbjpOflwG5ANgXFr0c4CXBwMBlIxRtVicHrkfbYBH+3aeMuNg x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(23010399003)(11063799006)(5023799004)(56012099006)(3023799007)(4143699003)(10067099003)(6133799003)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VHY4WTJNTTBSaEJqak5nQktKZXpFZC9RY1NSLzlmdy96Rm5lMVlDNEs1ZFNK?= =?utf-8?B?SDBUVmJUZzdZN1pWUXpGcWd4ZkQ1VCtqMDZoblFFcnBHN1FpRDMvb3JYcUJO?= =?utf-8?B?Z1VmeFJBNzZvdzJhaTB3U2lmZkhZdlV4UTIxQVdPSVRsY2s3QmFBKytUNWNs?= =?utf-8?B?clZJcG5sRU55Vzl4RjRPbjltcXpDZ0hxZE53dXlTbnlMSjcrWGlCWmdIaXBp?= =?utf-8?B?dGQwS2hGcE9lQ295OS83Wkw0VUQ1TGpCR0lkejRIUGJ6b0Q1R1JrVVFhbmdQ?= =?utf-8?B?WXM2ZkwrRkc3MWNtMHdNcTNyUGo5aGl2cDVJeXNBb241L2s0Ni9QaEl3bjl5?= =?utf-8?B?QytOMVh3bCtQUnhIMXRwdFJCR1FGUE5kMkExU092RmpTL0c3Q09RbGVsbUxC?= =?utf-8?B?MDBOZi9vSDRvRHoxc1h2V3N2dTlEZUhBWE0xd0ZBalNuMjlTVG5ReU4ySTZq?= =?utf-8?B?eGN1VVhCU3pHOTZmQjkyRG5XenBkMWNJVWN3SlMzOUtRb2lRQlovbGxBenlR?= =?utf-8?B?Y2JhODQ3cStBMElsTUNVdGVIaTI2ampHcTI3ZkRlSTFGaEs1TTZoVjI5UVJ6?= =?utf-8?B?cnZwMTFGbVNVaE9NV2lrME05NXJGRm5LRzIrdzFwdGdlTEVCcTFjbVAweUdq?= =?utf-8?B?SXFOSmloTUk3VGFlUmU3Zk1KekVRRWd5djhMRm9RNlpIeHk0NG05bGx5Rmdy?= =?utf-8?B?WExiV2grbVNwcUFlZG96YjZ6UFlWYnJmaXNJcGhKTCtoNEtUK0RwSTdicWR0?= =?utf-8?B?YkZVMHdaTlpGckF0TXVTWlJ4WnpCcGxIZlpqNXlFTkRHOCtWL054QVZ1QnhW?= =?utf-8?B?d0lEaXIweitSNm1Wa0kvNTlPZ08vNlVQTWZhS09jOVp2RnBMT2FMc3hteHlq?= =?utf-8?B?S2ZlK1hTKzVseS94em85T1FDSXBPQ21NSTdMLzZ0WnUvZXU0Wm0rSEZJbjNK?= =?utf-8?B?Y3BzOXd3b0hDdTdjNUlnVW40M3FlbzBtdFRzUFJHcWtzdWJQWWxITFl2RHNo?= =?utf-8?B?TnJkTFFBaldpVjBIay8yNWhuVCtZZ2pqUE1TbFhndDhOQWxyWDJtN0I5Snl6?= =?utf-8?B?aXptOFJ3UHdlZHlpRmlJcGdvVjgzQW9uZTAreERsVDhFWG1pSW4ydmJ6bFV2?= =?utf-8?B?NjR5TTBtTXhXcUdESVhVK0NGbmVWaXh2ZzVXMm5KTkRWZXhSSm0waUVHRUdu?= =?utf-8?B?UERxZ1ZTUUxSQ2Q4a3hRazJqYnZzd0had2lwaTdyV3lVVjRvOFJGeTc3SWpF?= =?utf-8?B?TXV3MzZLTERCK3NrV0ZUcHlLVnJWdWhQdnlUSEU1YTFPWXZEbGZsWUZzNU1X?= =?utf-8?B?MnBXQUJoaVNWU0M0Y1l4VmJPZzZ0UXpVUys2d0xDdVBHU09QR01qcU9IbjRj?= =?utf-8?B?dFIxdy91eTVseklYYTZSSXhCaTQ1WW95eitadGxoSFoveDF2ZHpHM2FnVUFG?= =?utf-8?B?OUZ6Z0xvTzVjYmNpVkhUTmNBbGcyVVBkQndkd2xTS3Z6b0V3djZQZ3dRVkV1?= =?utf-8?B?M3NXa3RIVzRkL2hDaG9VZHMvZ3U5bVUrQ05XTTJsOFkwZUtMMUtPQmg3dy9T?= =?utf-8?B?NVpvNy9SN0JjSlV2ODl1M0xLR012SFV4NlYzc2dKNktkbURIbUJvYjhrTk1R?= =?utf-8?B?VkFURU9OTXp3QkxaalFvaGpYOU9NMVRWRmcwd0FaWk8ydk85NE1CdWVWUTFZ?= =?utf-8?B?R2hCVzNXYjlzbEJKZE83TnFZblM5M0hYbHhEdlpReWJ5cFIveXA3clJZcDBn?= =?utf-8?B?WmJiSTQ1anlIcHF3Z0FHekxyQmVKUFNLRElPcy85YUY3bExYamZjd3ZEQUFw?= =?utf-8?B?ZkhuNkJybmhNRjdNaFJJZ2djcmV4Tnh0WE4vV0ZLS2VQamovN0F0cSs2NUFo?= =?utf-8?B?VXhrZ092NEhNeUU4Nys5cEhwbnJXT0xZQXZzR3pTWm92S3ErZ21YUHNDMHd2?= =?utf-8?B?NlNoZzBQbHltQWMwcEdkU2ZGMGl0UFhVa2twY3FxWkxFbXVHNURBaTAxQ0tD?= =?utf-8?B?Ym5ZME1YU2VDTjNNTWVTR2t6OVRRbVplMTBuVTZKZldHdlNVUHV2UFlnZCtL?= =?utf-8?B?STFpZTYrajFRVEhlWVVURXpNTDZJdEE4TzBtZUFqK3BleEZDNENmU2Z3cUMz?= =?utf-8?B?d3JXL2hJd0RKRGNCbVpDdTErZTdwaTRuQitkOU1PNENpTDhxRmdmckM2ci90?= =?utf-8?B?SjdzOWRWZzhncjNSQmVHWWVOZHd3WTJuWFNIeCtpR1NlcEhkb0c3UHBjZGxO?= =?utf-8?B?VGNLWlVkNGErQU5pSnFmSjZRUld6N2VrbzB4M2xtWVBmc0t4ZncxcTdEUG9M?= =?utf-8?B?U3J0cCtKYnV0cWdncTg1eE95aEtKMElBQzh1RllFRjRKSW9VcXlIMzJ5dEZ1?= =?utf-8?Q?jJONOvtaXvBPLPUc=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <8F525F57D6D718468677AAD72927B534@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 298dd45a-4e98-41ea-c047-08df13405db6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2026 15:45:28.0907 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rs/ALyK+c6fvKQ5EZo4isfd0ZVCFbjvyh2I9Qbg/Imto3f2J2kNUrMgnC/pbZHDdT6mhcYfX1SLRvaKAKd4WqpqW34lgIEjZhDyg66fneNU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10315 X-purgate-ID: tlsNG-d25034/1789487133-020C1A5B-5B0FEFC7/0/0 X-purgate-type: clean X-purgate-size: 11496 SGkgSmFuLA0KDQpBIHNob3J0IGZvbGxvdy11cCB0byBteSBwcmV2aW91cyByZXBseSwgdG8gbWFr ZSB0aGUgcHJvcG9zYWwgY29uY3JldGUNCg0KT24gMTEvMDkvMjAyNiAxNjowNiwgT2xla3NpaSBN b2lzaWVpZXYgd3JvdGU6DQo+IEhpIEphbiwNCj4NCj4gVGhhbmsgeW91IGZvciBxdWljayByZXNw b25zZS4gcGxlYXNlIHNlZSBiZWxvdy4NCj4NCj4gT24gMTEvMDkvMjAyNiAxMDo1MCwgSmFuIEJl dWxpY2ggd3JvdGU6DQo+PiBPbiAxMS4wOS4yMDI2IDA5OjI2LCBPbGVrc2lpIE1vaXNpZWlldiB3 cm90ZToNCj4+PiBJbnRyb2R1Y2UgbWVtY3B5X2Zyb21pbygpIGFuZCBtZW1jcHlfdG9pbygpIGhl bHBlcnMgdG8gY29weSBiZXR3ZWVuDQo+Pj4gcmVndWxhciBtZW1vcnkgYW5kIE1NSU8gc3BhY2Ug b24gQXJtLiBUaGUgZ2VuZXJpYyBwcm90b3R5cGVzIGxpdmUgaW4NCj4+PiBpby5oIHNvIG90aGVy IGFyY2hpdGVjdHVyZXMgY2FuIHByb3ZpZGUgdGhlaXIgb3duIGltcGxlbWVudGF0aW9ucy4NCj4+ Pg0KPj4+IFRoZXNlIGhlbHBlcnMgaGFuZGxlIGFsaWdubWVudCBzYWZlbHkgYnkgdXNpbmcgb3Jk ZXJlZCBieXRlIGFjY2Vzc2VzIA0KPj4+IGZvcg0KPj4+IGFueSBsZWFkaW5nL3RyYWlsaW5nIHVu YWxpZ25lZCBieXRlcyBhbmQgb3JkZXJlZCAzMi1iaXQgYWNjZXNzZXMgZm9yIA0KPj4+IHRoZQ0K Pj4+IGFsaWduZWQgYnVsayB0cmFuc2Zlci4NCj4+IFRoYXQncyBvdmVyLXNpbXBsaWZ5aW5nIHRo aW5ncyAoanVzdCBsaWtlIGNvZGUgY29tbWVudHMgZG8pLiBJZiBzb3VyY2UNCj4+IGFuZCBkZXN0 aW5hdGlvbiBhcmUgZXF1YWxseSBtaXNhbGlnbmVkIG1vZHVsbyA0LCB3aGF0IGlzIHNhaWQgaXMg DQo+PiB0cnVlLiBJZg0KPj4gdGhleSBhcmUgZGlmZmVyZW50bHkgbWlzYWxpZ25lZCwgdGhlIGVu dGlyZSBjb3B5IHdpbGwgYmUgZG9uZSBieXRlLXdpc2UuDQo+PiBXaGljaCBjYW4gZWFzaWx5IGJl IGEgcHJvYmxlbSB3aGVuIDQtYnl0ZSBhY2Nlc3NlcyBhcmUgcmVxdWlyZWQgZm9yDQo+PiBwYXJ0 aWN1bGFyIE1NSU8gbG9jYXRpb25zICh3aGljaCBtYXkgZS5nLiBhY3R1YWxseSByZXByZXNlbnQg ZGV2aWNlDQo+PiByZWdpc3RlcnMpLg0KPj4NCj4+IEFzIHNhaWQgb24gZWFybGllciB2ZXJzaW9u czogSSB0aGluayB5b3UgZWl0aGVyIHdhbnQgdG8gZ2V0IG1pc2FsaWdubWVudA0KPj4gaGFuZGxp bmcgcmlnaHQgZm9yIGFsbCBwb3NzaWJsZSBjYXNlcywgb3IgeW91IHdhbnQgdG8gZGVtYW5kIGFs aWduZWQNCj4+IGluY29taW5nIHBvaW50ZXJzLg0KPj4NCj4+IChGdGFvZCwgdXNpbmcgYnl0ZSBh Y2Nlc3NlcyBmb3IgdHdvIG9yIHRocmVlIGxlYWRpbmcgLyB0cmFpbGluZyANCj4+IG1pc2FsaWdu ZWQNCj4+IGJ5dGVzIGNhbiBiZSBlcXVhbGx5IHdyb25nLCB3aGVuIHRoZSBNTUlPIGxvY2F0aW9u IGFjY2Vzc2VkIHdhbnRzIHRvIGJlDQo+PiBhY2Nlc3NlZCB3aXRoIGEgMTYtYml0IGxvYWQvc3Rv cmUsIGZvciBiZWluZyBlLmcuIGEgMTYtYml0IGRldmljZSANCj4+IHJlZ2lzdGVyLg0KPj4gU2lt aWxhcmx5IHVzaW5nIDMyLWJpdCBsb2Fkcy9zdG9yZXMgY2FuIGJlIHdyb25nIGluIHRoZSBnZW5l cmFsIGNhc2UuIA0KPj4gSU9XDQo+PiB3aGlsZSBzb21lIG9mIHRoYXQgaXMgc2FpZCB0byBhIGNl cnRhaW4gZGVncmVlLCBJIHRoaW5rIHRoZXJlIGFyZQ0KPj4gdW5tZW50aW9uZWQgZnVydGhlciBj b25zdHJhaW50cyBvbiB3aGVuIHRoZXNlIGZ1bmN0aW9ucyBtYXkgc2FmZWx5IGJlDQo+PiB1c2Vk LiBGb3IgZXhhbXBsZSAiZGV2aWNlcyB0aGF0IHRvbGVyYXRlIDgtYml0IGFuZCAzMi1iaXQgYWNj ZXNzZXMiIGlzDQo+PiBzdGlsbCBhbWJpZ3VvdXMgYXMgdG8gd2hhdCBleGFjdGx5IGl0IG1lYW5z LiBOb3QgdGhlIGxlYXN0IGJlY2F1c2UNCj4+ICJ0b2xlcmF0ZSIgZG9lc24ndCBtZWFuICJ3b3Jr IGNvcnJlY3RseSB3aXRoIi4pDQo+Pg0KPj4+IFVzaW5nIHRoZSBvcmRlcmVkIGByZWFkYi9yZWFk bGAgYW5kDQo+Pj4gYHdyaXRlYi93cml0ZWxgIGFjY2Vzc29ycyBhdm9pZHMgdW5pbnRlbmRlZCBl bmRpYW5uZXNzIGNvbnZlcnNpb24gd2hpbGUNCj4+PiByZXNwZWN0aW5nIGRldmljZSBvcmRlcmlu ZyByZXF1aXJlbWVudHMgb24gQVJNMzIvQVJNNjQgaGFyZHdhcmUgdGhhdCANCj4+PiBtYXkNCj4+ PiBub3Qgc3VwcG9ydCA2NC1iaXQgTU1JTyBhdG9taWNhbGx5Lg0KPj4gSSdtIGhhdmluZyB0cm91 YmxlIG1ha2luZyBzZW5zZSBvZiB0aGlzIHBhcnQuIFdoeSdzIGVuZGlhbm5lc3Mgb2YgDQo+PiBj b25jZXJuDQo+PiBoZXJlPyBUaGUgYWNjZXNzb3JzIHVzZWQgZG9uJ3QgY2FyZSBhYm91dCBlbmRp YW5uZXNzIGF0IGFsbCwgYW5kIHdoYXQgDQo+PiBtYXkNCj4+IGhhdmUgKHdyb25nbHkpIGJlZW4g dXNlZCBpbiBlYXJsaWVyIHZlcnNpb25zIHNob3VsZG4ndCBtYXR0ZXIgaGVyZSANCj4+IChvciBp dA0KPj4gd291bGQgbmVlZCBjYWxsaW5nIG91dCB3aGljaCBvdGhlciBhY2Nlc3NvcnMgd291bGQg YmUgd3JvbmcgdG8gdXNlKS4NCj4gVGhpcyBpcyB0aGUgbGVmdG92ZXIgZnJvbSB2NyB3aGVyZSBf X3Jhd193cml0ZS9fX3Jhd19yZWFkIHdlcmUgdXNlZC4gDQo+IHJlYWRsKCkvd3JpdGVsKCkgaW5j bHVkZSBsaXR0bGUgZW5kaWFuIGNvbnZlcnNpb24gdGhyb3VnaCB0aGVpciANCj4gcmVsYXhlZCB2 YXJpYW50cy4NCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vY292ZXIuMTc2ODQxNTIwMC5naXQu b2xla3NpaS5fNUZtb2lzaWVpZXZAZXBhbS5jb20vZDE2NjM0ODUzMGI5MjI5NjczZTFhNmUzYjI5 ZmY0ZWU5MTIzYWIyZi4xNzY4NDE1MjAwLmdpdC5vbGVrc2lpLl81Rm1vaXNpZWlldkBlcGFtLmNv bS8gDQo+DQo+DQo+IEkgd2lsbCByZW1vdmUgdGhlIGNsYWltIHRoYXQgb3JkZXJlZCBhY2Nlc3Nv cnMgYXZvaWQgZW5kaWFubmVzcyANCj4gY29udmVyc2lvbi4NCj4NCj4+PiAtLS0gYS94ZW4vaW5j bHVkZS94ZW4vaW8uaA0KPj4+ICsrKyBiL3hlbi9pbmNsdWRlL3hlbi9pby5oDQo+Pj4gQEAgLTY3 LDQgKzY3LDE0IEBAIHN0YXRpYyBpbmxpbmUgYm9vbCB3cml0ZV9tbWlvKHZvbGF0aWxlIHZvaWQg DQo+Pj4gX19pb21lbSAqbWVtLCB1bnNpZ25lZCBsb25nIGRhdGEsDQo+Pj4gwqDCoMKgwqDCoCBy ZXR1cm4gdHJ1ZTsNCj4+PiDCoCB9DQo+Pj4gwqAgKy8qDQo+Pj4gKyAqIENvcHkgYmV0d2VlbiBy ZWd1bGFyIG1lbW9yeSBhbmQgTU1JTyBzcGFjZS4gSW1wbGVtZW50YXRpb25zIGFyZQ0KPj4+ICsg KiBhcmNoaXRlY3R1cmUtc3BlY2lmaWMgYW5kIG11c3QgdXNlIGFwcHJvcHJpYXRlIE1NSU8gYWNj ZXNzb3JzIGZvcg0KPj4+ICsgKiB0aGVpciBtZW1vcnkgYW5kIEkvTyBtb2RlbHMuDQo+Pj4gKyAq Lw0KPj4+ICt2b2lkIG1lbWNweV9mcm9taW8odm9pZCAqdG8sIGNvbnN0IHZvbGF0aWxlIHZvaWQg X19pb21lbSAqZnJvbSwNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHNpemVfdCBjb3VudCk7DQo+Pj4gK3ZvaWQgbWVtY3B5X3RvaW8odm9sYXRpbGUgdm9pZCBfX2lv bWVtICp0bywgY29uc3Qgdm9pZCAqZnJvbSwNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgc2l6ZV90IGNvdW50KTsNCj4+IEZvciBzb21lYm9keSB3YW50aW5nIHRvIHVzZSB0 aGVzZSBmdW5jdGlvbnMgYW5kIG1lcmVseSBsb29raW5nIGhlcmUsIGhvdw0KPj4gd291bGQgdGhl eSBrbm93IG9mIGFsbCB0aGUgY29uc3RyYWludHM/IFRoYXQgaXMgaW1wbGVtZW50YXRpb25zIGFy ZSBub3QNCj4+IG1lcmVseSBhcmNoLXNwZWNpZmljLCB0aGV5IG1heSBhbHNvIGltcG9zZSBhcmNo LXNwZWNpZmljIGNvbnN0cmFpbnRzLg0KPj4NCj4+IEphbg0KPiBZb3UgYXJlIHJpZ2h0IGFib3V0 IHRoZSBhbGlnbm1lbnQgaGFuZGxpbmcuIEFkdmFuY2luZyBib3RoIHBvaW50ZXJzIGJ5DQo+IHRo ZSBzYW1lIGFtb3VudCBwcmVzZXJ2ZXMgdGhlaXIgcmVsYXRpdmUgYWxpZ25tZW50LCBzbyB0aGV5 IG5ldmVyIGJlY29tZQ0KPiBhbGlnbmVkIHRvZ2V0aGVyIGlmIHRoZWlyIG9mZnNldHMgbW9kdWxv IGZvdXIgZGlmZmVyLiBJbiB0aGF0IGNhc2UgdGhlDQo+IGN1cnJlbnQgaW1wbGVtZW50YXRpb24g Y29waWVzIHRoZSB3aG9sZSByYW5nZSB1c2luZyBieXRlIGFjY2Vzc2VzLg0KPg0KPiBJIHByb3Bv c2UgdG8gaGFuZGxlIGFyYml0cmFyeSBSQU0gYWxpZ25tZW50IGJ5IGFsaWduaW5nIG9ubHkgdGhl IEkvTw0KPiBwb2ludGVyLCB0aGVuIHVzaW5nIHB1dF91bmFsaWduZWRfbGUzMigpL2dldF91bmFs aWduZWRfbGUzMigpIG9uIHRoZQ0KPiBOb3JtYWwtbWVtb3J5IHNpZGUgb2YgdGhlIHdvcmQgdHJh bnNmZXJzLiBBbGwgSS9PIGFjY2Vzc2VzIHdvdWxkIHN0aWxsDQo+IHVzZSByZWFkYi9yZWFkbCBv ciB3cml0ZWIvd3JpdGVsLiBUaGlzIHdvdWxkIG1ha2UgdGhlIEkvTyBhY2Nlc3Mgd2lkdGhzDQo+ IGluZGVwZW5kZW50IG9mIHRoZSBSQU0gcG9pbnRlcidzIGFsaWdubWVudC4gSW4gcGFydGljdWxh ciwgYW4gYWxpZ25lZA0KPiBJL08gYWRkcmVzcyBhbmQgYSBsZW5ndGggZGl2aXNpYmxlIGJ5IGZv dXIgd291bGQgcHJvZHVjZSBvbmx5IDMyLWJpdA0KPiBJL08gYWNjZXNzZXMsIGV2ZW4gd2l0aCBh biB1bmFsaWduZWQgUkFNIGJ1ZmZlci4NCj4NCj4gU28gdGhlIGNoYW5nZXMgZm9yIG1lbWNweV90 b2lvIHdpbGwgbG9vayBsaWtlOg0KPg0KPiB2b2lkIG1lbWNweV90b2lvKHZvbGF0aWxlIHZvaWQg X19pb21lbSAqdG8sIGNvbnN0IHZvaWQgKmZyb20sDQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgc2l6ZV90IGNvdW50KQ0KPiDCoHsNCj4gLcKgIMKgIHdoaWxlICggY291bnQgJiYgKCFJU19B TElHTkVEKCh1bnNpZ25lZCBsb25nKXRvLCA0KSB8fA0KPiAtwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgIUlTX0FMSUdORUQoKHVuc2lnbmVkIGxvbmcpZnJvbSwgNCkpICkNCj4gK8Kg IMKgIHdoaWxlICggY291bnQgJiYgIUlTX0FMSUdORUQoKHVuc2lnbmVkIGxvbmcpdG8sIDQpICkN Cj4gwqAgwqAgwqB7DQo+IMKgIMKgIMKgIMKgIMKgd3JpdGViKCooY29uc3QgdWludDhfdCAqKWZy b20sIHRvKTsNCj4gwqAgwqAgwqAgwqAgwqBmcm9tKys7DQo+IEBAIC0yOSw3ICsyMiw3IEBADQo+ DQo+IMKgIMKgIMKgd2hpbGUgKCBjb3VudCA+PSA0ICkNCj4gwqAgwqAgwqB7DQo+IC3CoCDCoCDC oCDCoCB3cml0ZWwoKihjb25zdCB1aW50MzJfdCAqKWZyb20sIHRvKTsNCj4gK8KgIMKgIMKgIMKg IHdyaXRlbChnZXRfdW5hbGlnbmVkX2xlMzIoZnJvbSksIHRvKTsNCj4gwqAgwqAgwqAgwqAgwqBm cm9tICs9IDQ7DQo+IMKgIMKgIMKgIMKgIMKgdG8gKz0gNDsNCj4gwqAgwqAgwqAgwqAgwqBjb3Vu dCAtPSA0Ow0KPg0KPiBUaGlzIGRvZXMgbm90IG1ha2UgdGhlIGhlbHBlcnMgc3VpdGFibGUgZm9y IGFyYml0cmFyeSBkZXZpY2UgcmVnaXN0ZXJzLg0KPiBJIHdpbGwgZGVzY3JpYmUgdGhlbSBhcyBj b3B5aW5nIGEgYnl0ZSBzZXF1ZW5jZSB0by9mcm9tIGEgbWVtb3J5LWxpa2UNCj4gSS9PIHJlZ2lv bi4gVGhlIHJlZ2lvbiBtdXN0IHN1cHBvcnQgYnl0ZSBhY2Nlc3NlcyBhdCBldmVyeSBieXRlIGFk ZHJlc3MNCj4gYW5kIGFsaWduZWQgMzItYml0IGFjY2Vzc2VzIHdpdGggZXF1aXZhbGVudCBieXRl LXN0b3JhZ2Ugc2VtYW50aWNzLg0KPiBUaGUgaW1wbGVtZW50YXRpb24gdXNlcyBieXRlIGFjY2Vz c2VzIHRvIGFsaWduIHRoZSBJL08gcG9pbnRlci4NCj4NCj4gQW5kIGFsc28gSSB3aWxsIGRvY3Vt ZW50IHRoZSBBcm0gcmVxdWlyZW1lbnRzIG5leHQgdG8gdGhlIGRlY2xhcmF0aW9ucw0KPiBpbiB4 ZW4vaW8uaCBhcyB5b3Ugc3VnZ2VzdGVkLg0KPg0KPg0KPiBXaGF0IGRvIHlvdSB0aGluayBhYm91 dCB0aGlzIGFwcHJvYWNoPw0KPg0KPiBPbGVrc2lpLg0KDQoNCg0KLSBQb3RlbnRpYWwgdXNhZ2UN Cg0KVGhlIG9ubHkgdXNlciBpbiB0aGlzIHNlcmllcyBpcyB0aGUgU0NNSSBzaGFyZWQtbWVtb3J5 IHRyYW5zcG9ydA0KKHBhdGNoIDQpLiBUaGVyZSB0aGUgIkkvTyIgc2lkZSBpcyB0aGUgU0NNSSBz aG1lbSBhcmVhOiBTUkFNIG9yIG5vcm1hbA0KUkFNIG1hcHBlZCBieSBYZW4gd2l0aCBEZXZpY2Ug YXR0cmlidXRlcywgaS5lLiBwbGFpbiBieXRlLWFkZHJlc3NhYmxlDQpzdG9yYWdlIHdpdGhvdXQg YW55IHJlZ2lzdGVyIHNlbWFudGljcy4gQm90aCBjYWxsZXJzIHBhc3MgYSAzMi1iaXQNCmFsaWdu ZWQgSS9PIHBvaW50ZXIgKG1zZ19wYXlsb2FkIHNpdHMgYXQgb2Zmc2V0IDI4IG9mIHRoZSBwYWdl LWFsaWduZWQNCnNobWVtLCBwbHVzIGEgNC1ieXRlIHN0YXR1cyB3b3JkIGZvciB0aGUgcmVzcG9u c2UgcGF0aCksIHdoaWxlIHRoZSBSQU0NCnNpZGUgaXMgYSBjYWxsZXItcHJvdmlkZWQgc3RydWN0 IG9mIGFyYml0cmFyeSBzaXplLCBzbyBjb3VudCBpcyBub3QNCm5lY2Vzc2FyaWx5IGEgbXVsdGlw bGUgb2YgNC4NCg0KLSBpby5oDQoNCkknZCByZXBsYWNlIHRoZSBjdXJyZW50IGNvbW1lbnQgd2l0 aCBzb21ldGhpbmcgYWxvbmcgdGhlc2UgbGluZXMgKGtlcHQNCmFyY2gtbmV1dHJhbCwgc28gb3Ro ZXIgaW1wbGVtZW50YXRpb25zIHJlbWFpbiBwb3NzaWJsZSk6DQoNCi8qDQogwqAqIENvcHkgYSBz ZXF1ZW5jZSBvZiBieXRlcyBiZXR3ZWVuIHJlZ3VsYXIgbWVtb3J5IGFuZCBhIG1lbW9yeS1saWtl DQogwqAqIEkvTyByZWdpb24sIGUuZy4gc2hhcmVkIG1lbW9yeSBwbGFjZWQgaW4gUkFNIG9yIFNS QU0gbWFwcGVkIHdpdGgNCiDCoCogZGV2aWNlIGF0dHJpYnV0ZXMuDQogwqAqIFRoZSBJL08gcmVn aW9uIG11c3QgYmVoYXZlIGxpa2UgYnl0ZS1hZGRyZXNzYWJsZSBzdG9yYWdlOiBpdCBtdXN0DQog wqAqIGFjY2VwdCA4LWJpdCBhY2Nlc3NlcyBhdCBhbnkgYnl0ZSBhZGRyZXNzIGFuZCBuYXR1cmFs bHkgYWxpZ25lZA0KIMKgKiAzMi1iaXQgYWNjZXNzZXMsIHdpdGggcGxhaW4gYnl0ZS1zdG9yYWdl IHNlbWFudGljcyBpbiBib3RoIGNhc2VzDQogwqAqIChubyBzaWRlIGVmZmVjdHMsIG5vIGRlcGVu ZGVuY3kgb24gdGhlIGFjY2VzcyB3aWR0aCkuIEFuDQogwqAqIGltcGxlbWVudGF0aW9uIG1heSB1 c2UgYW55IG9mIHRoZXNlIHdpZHRocywgYnV0IG5ldmVyIHdpZGVyIG9uZXMuDQogwqAqIFRoZSBo ZWxwZXJzIGFyZSBub3Qgc3VpdGFibGUgZm9yIGRldmljZSByZWdpc3RlcnMgd2l0aCBhY2Nlc3Mt d2lkdGgNCiDCoCogcmVxdWlyZW1lbnRzLg0KIMKgKg0KIMKgKiBOZWl0aGVyIHBvaW50ZXIgbmVl ZHMgdG8gYmUgYWxpZ25lZC4gVGhlIGFjY2VzcyB3aWR0aHMgaXNzdWVkIG9uIHRoZQ0KIMKgKiBJ L08gc2lkZSBkZXBlbmQgb25seSBvbiB0aGUgYWxpZ25tZW50IG9mIHRoZSBJL08gcG9pbnRlciBh bmQgb24NCiDCoCogY291bnQsIG5ldmVyIG9uIHRoZSBhbGlnbm1lbnQgb2YgdGhlIHJlZ3VsYXIg bWVtb3J5IHBvaW50ZXIuDQogwqAqDQogwqAqIEltcGxlbWVudGF0aW9ucyBhcmUgYXJjaGl0ZWN0 dXJlLXNwZWNpZmljOyBzZWUgdGhlIHJlc3BlY3RpdmUNCiDCoCogYXJjaC8qL2xpYi9tZW1jcHkt e2Zyb20sdG99aW8uYyBmb3IgdGhlIGV4YWN0IGFjY2VzcyBwYXR0ZXJuLg0KIMKgKi8NCg0KVGhl IEFybS1zcGVjaWZpYyBub3RlIGluIG1lbWNweS17ZnJvbSx0b31pby5jIHdvdWxkIHRoZW4gc3Rh dGUgdGhlDQpjb25jcmV0ZSBwYXR0ZXJuOiA4LWJpdCBhY2Nlc3NlcyB1bnRpbCB0aGUgSS9PIHBv aW50ZXIgaXMgMzItYml0DQphbGlnbmVkIGFuZCBmb3IgdGhlIHRyYWlsaW5nIGNvdW50ICUgNCBi eXRlcywgMzItYml0IGFjY2Vzc2VzIGZvciB0aGUNCmFsaWduZWQgYnVsay4gSSdkIGFsc28gZHJv cCB0aGUgInRvbGVyYXRlIiB3b3JkaW5nIGluIGZhdm91ciBvZiB0aGUNCmFib3ZlLg0KDQotIGlt cGxlbWVudGF0aW9uDQoNCkFzIHByb3Bvc2VkOiBvbmx5IHRoZSBJL08gcG9pbnRlciBpcyBhbGln bmVkIHVwOyB0aGUgUkFNIHNpZGUgdXNlcw0KZ2V0X3VuYWxpZ25lZF9sZTMyKCkvcHV0X3VuYWxp Z25lZF9sZTMyKCkgZm9yIHRoZSAzMi1iaXQgcGFydC4gVGhlDQpfbGUzMiB2YXJpYW50cyBhcmUg dXNlZCBkZWxpYmVyYXRlbHk6IHBhaXJlZCB3aXRoIHJlYWRsKCkvd3JpdGVsKCksDQp3aGljaCBh cmUgZGVmaW5lZCBhcyBsaXR0bGUtZW5kaWFuIGFjY2Vzc29ycywgdGhpcyBwcmVzZXJ2ZXMgdGhl IGJ5dGUNCnNlcXVlbmNlIHJlZ2FyZGxlc3Mgb2YgQ1BVIGVuZGlhbm5lc3MuIFRoYXQgaXMgdGhl IG9ubHkgZW5kaWFubmVzcw0KYXNwZWN0IHdvcnRoIGEgbWVudGlvbiwgYW5kIEknbGwgcmV3cml0 ZSB0aGUgY29tbWl0IG1lc3NhZ2UNCmFjY29yZGluZ2x5IChkcm9wcGluZyB0aGUgc2VudGVuY2Ug eW91IHBvaW50ZWQgb3V0KS4NCg0KV291bGQgdGhhdCBhZGRyZXNzIHlvdXIgY29uY2VybnM/DQoN Cg0KVGhhbmtzLA0KT2xla3NpaQ0K From xen-devel-bounces@lists.xenproject.org Tue Sep 15 15:49:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 15:49:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421933.1647560 (Exim 4.92) (envelope-from ) id 1x6VPP-0006oV-T2; Tue, 15 Sep 2026 15:49:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421933.1647560; Tue, 15 Sep 2026 15:49:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6VPP-0006oO-Pl; Tue, 15 Sep 2026 15:49:23 +0000 Received: by outflank-mailman (input) for mailman id 1421933; Tue, 15 Sep 2026 15:49:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6VPO-0006oI-OU for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 15:49:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6VPN-00HKBs-PR for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 17:49:21 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa968fa-e002-0a2a0a5209dd-0a2a45038ea2-26 for ; Tue, 15 Sep 2026 17:49:21 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa96901-fae8-0a2a45030019-416d716ce308-3 for ; Tue, 15 Sep 2026 17:49:21 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id BE48340E0173; Tue, 15 Sep 2026 15:49:20 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id d06NG9gSV47R; Tue, 15 Sep 2026 15:49:11 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 461FC40E015D; Tue, 15 Sep 2026 15:48:56 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1789487350; bh=fCN5qSYaL57eT0UM8WiuWb5l8tYcx6z/BpUC5JNlUb4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BmrQ8O97V62IdGr2cPLY4/94bh4q4aGkqLolGjSKVWl2G02JdCoWNFDYZnvaNhGZ0 Yq+Tuwe1BjVum7MHvi8IdJSDn4UsN/tPQQaR2GKfyWqK0fsjtBGAanpudTypZcYyHs a73TB9hmEFZz5DTr1FbnmNfndFVMYFPfRs5jsaCbY1SFTYKuZt2yvsivm+RwwAD8TI 7DgGeXGCC/atNDJQAqDGzNf283pZqtgiHpBxAB2j4qZafZFlZM9G/Tqz4EaeJilQmD AQZnB9aBbPazCB5w+8CBOz+OCYTEvyOTVVmXl5IvpnHvwaT9dZCmtfL5Ryns0jTK+m r+Nl9yb3eBYVB0TpU9oko4owZgIQoGXDUGPAm4jQ4sni/mohatEUcttY5aIlouxEdA /RAJ5/t0JLAtB2Aav3vv3spktUmxk+x6gpHnDzwoss6isvj7FV0lXuB0iZ4FHMEh4w D/AcBxBiIq1iAKuJg6vFN7YkJZhvjkzjis0nsC7FTBfQA4RHfs9rowT8jq5DxM7V7Z DpQ6yPUgJo/aXjydiCA5cAVpyBMHsURX3UQ2lLZoNypWfpyFhJeSA7Pf6nQXCB+AbV FuR+ChyPBoI3A28duw3kRaLwjECYxxs34Pi/4geFpjxfa8qsdRDY3mEATj3v8DZwi0 N0JSLieIrbyRTWf9HRJY5oqU= Date: Tue, 15 Sep 2026 08:48:53 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() Message-ID: <20260915154853.GAaqlo5YxQ9ALlhjbF@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> <6113f06c790cfe1141d2dc09b68937b6@igalia.com> <20260915051155.GGaqjTm7yIluwxZ80x@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260915051155.GGaqjTm7yIluwxZ80x@fat_crate.local> X-purgate-ID: tlsNG-33051d/1789487361-6C8DD4E9-21B62604/0/0 X-purgate-type: clean X-purgate-size: 579 On Mon, Sep 14, 2026 at 10:11:55PM -0700, Borislav Petkov wrote: > Hmm, never heard that before but that doesn't mean anything. Probably should > mention it in one of the commit messages so that we know for the future... My compiler friends are telling me that gcc doesn't do that now but it might in the future, perhaps. -fno-builtin-memcmp will stop any of that behavior so if, perhaps, building the pvh code with it looks better as a solution, we probably could use it. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Tue Sep 15 17:17:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 17:17:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421982.1647593 (Exim 4.92) (envelope-from ) id 1x6Wlx-0001eL-0z; Tue, 15 Sep 2026 17:16:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421982.1647593; Tue, 15 Sep 2026 17:16:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Wlw-0001eE-UI; Tue, 15 Sep 2026 17:16:44 +0000 Received: by outflank-mailman (input) for mailman id 1421982; Tue, 15 Sep 2026 17:16:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Wlv-0001e8-AS for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 17:16:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Wlu-00Eq6K-1B for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 19:16:42 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa97d60-8faa-0a2a0a5109dd-0a2a4504c094-42 for ; Tue, 15 Sep 2026 19:16:41 +0200 Received: from [40.107.200.30] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa97d77-b57f-0a2a45040019-286bc81ec48d-3 for ; Tue, 15 Sep 2026 19:16:41 +0200 Received: from DS7PR12MB8371.namprd12.prod.outlook.com (2603:10b6:8:e9::18) by PH7PR12MB9102.namprd12.prod.outlook.com (2603:10b6:510:2f8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Tue, 15 Sep 2026 17:16:14 +0000 Received: from DS7PR12MB8371.namprd12.prod.outlook.com ([fe80::23d7:9e07:1de8:d80a]) by DS7PR12MB8371.namprd12.prod.outlook.com ([fe80::23d7:9e07:1de8:d80a%3]) with mapi id 15.21.0406.007; Tue, 15 Sep 2026 17:16:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iwwFsvFOloHx4altECsYutAjbApJwPPXiD6QFXUizuENJtzyIE8exaKrZDcNq5I7j1CLZzN3u3ISD6WbMfmpsUQmCJN4RckcRofY0QshFZrbmhoHbkvQRop+h5YKS4kEBvdfiak61L/wb9hjmyJeZtvcGY5jTfRGI+aULIZfGXZZgbhOIgFJ3Jo0saNgmRlfEd7RZFz3v9ZPsHti4brKICSnAb8UPjO1ocO8ZFz49Dd2j8K+ZJviXuuGfO78cqEl0vyoC0pMRQ0iUke1SRVEdlfpkGjgpoL5TUmVYOmDQUI/Rod8n93gL5h8XE6gRHEW1s66fNlcnu8KTVQAGxqagQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gm4A0dC/cSIZYi95VVuBQCnE1WnlU3ZJPlPGzxqmmdc=; b=izs3jKvQd2SPtIHCbqSzFGoF/iXmI728U1Xlv4NuvE2aWCWp99y+/8UF7Z4R9btCS7XEV6S7MzB5QgrnbKYyDjDw4I22mF0e9yYLUWo6LsxQeAotR+60Ij38OCq8+Xxs9bPppAHUMkXoVgQtJLufv3wqxE/Q1NhsjkzA/WYubFdA+bGMA3TPA64vVgRIvjsPkXsQ4+qsoih20yCJz5VqC5FsmYVrVMuzBh42bO6fXBfbrwwwx5Vbn9AOUQ8vukhRFj86KXZuvZ5X3d85hIbyOAHQVN14MjH1edvzJfPG0QWrkK4uKQP3TT+UFB9yeLBGWXmT7WGnN2xRkrx9vaAV5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gm4A0dC/cSIZYi95VVuBQCnE1WnlU3ZJPlPGzxqmmdc=; b=qdjnEuZm+PoCkspfNOFNWfGpWz5qPUaQuoTEkOpTbi+fqdQpJTQt+C4lxiilcFDnbfSiq+FGTV+fRSmCE/TCUpCLM6y/p2UBuSMu0zsZ3TVemN8SDX3CAV2s4+WZnt7LA6f2dTjX2Cyu/P/qopUr95wEH9C9IV+34J9UMfEdRrJ6BVu2Nuxo524O9pQxU/y5dJDMca7N0gyUn0b+XTcLZfM0vuag7Io98Q0jH5Ll6bqWVefpOdaDuKZvyIJkomyuTSTVq/N2StADM738facGw9b6wKIZeOjGvklwX1BS5eUtzGbKAADcRCCRvX30ruvmlVg4sgMNeiqiuzwDIZ++Lg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; From: Zi Yan To: Andrew Morton Cc: David Hildenbrand , "Matthew Wilcox (Oracle)" , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, Oscar Salvador , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Tal Zussman , Gao Xiang , Jan Kara , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-trace-kernel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , ceph-devel@vger.kernel.org, Song Liu , Yu Kuai , Li Nan , Xiao Ni , linux-raid@vger.kernel.org, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org, Baoquan He , Pasha Tatashin , Pratyush Yadav , Jonathan Corbet , Dave Young , Shuah Khan , kexec@lists.infradead.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v4 00/16] Remove PG_private by using page/folio->private checks instead Date: Tue, 15 Sep 2026 13:16:07 -0400 X-Mailer: MailMate (3.0r7032) Message-ID: In-Reply-To: <20260913203959.6b46b0b5a052aec818a7f267@linux-foundation.org> References: <20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com> <20260913203959.6b46b0b5a052aec818a7f267@linux-foundation.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-MS-Reactions: disallow X-ClientProxiedBy: BN9P220CA0024.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:13e::29) To DS7PR12MB8371.namprd12.prod.outlook.com (2603:10b6:8:e9::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR12MB8371:EE_|PH7PR12MB9102:EE_ X-MS-Office365-Filtering-Correlation-Id: 040b751e-5a2a-4578-d517-08df134d0be6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|7416014|10067099003|4143699003|22082099003|18002099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: EdmOT4SZggvXel11Uhh1H9mF8pJyToiZ4vo+EaL4dQpqpSiRPlv1r32Dgz69iVxRKeRQA2Ast0fMgp+dtSul+ssZ/kJs2D95hmspE8OQmcfALuUDnDqNeKbNVO83v2iXLX1TgKyRNG512daoHu/3lsvC7YFuT9syyAMKYcc8Cj7sRTVCwf7hiclEtUz9K+WYpQE60SsB9HMKu1aGNd+rOH4FuYpR0yN0pEZ9QMKTScul+Ork7mxnVj5Reie3mU3RZve/Igx+fzCyG74c/PU8IYeO3UC6228cv7SfuZEYjtTK3KsezbygJexMLYcjShKX3igAX2GXZzGSorl7Mi9BPwIm77+Sj1aax9f/Sy8vPMzVa8cLugoy5vYsGLC2OtrPq6Qpg8JuCZ2tbHicv6TteAmWCBgMe4ITXR/1Q2OTVdMrlua3hQfyZvShF0+Lt/pkcoExAwGghOwaNgsKpt68C3YDegf81smiqhANEWkXKOR/pLOE7NVTzz6IGCHYv0NPj0srvj9cGTgi+w88gmqAg0OWELisn+6fTDEmj3nFvk2ZKGneX4EdIAGOAHWtDBQTiEdFxiiQtE+G0uXNbgHPDiyTqEXJ97gGwJGOZSqGQ3tTkLHMw6dlf647AS9ptFS1i40d0Stx1d8ifCCWC48sIvnPF7yU5MgpaGtihLIlJP8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR12MB8371.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(7416014)(10067099003)(4143699003)(22082099003)(18002099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V3VZVW84WlRLMThCTE10TGpMWXpHUEFQclpFRGgwYjJRQ1luV1BrS0dOcFRZ?= =?utf-8?B?a3ZtdnQ1YUNNdXJPSFZyOHY4UHhpRktvOUpXZEVqVVN6c1BoOU95RElsY1Iw?= =?utf-8?B?RGpRQXVCZy9Pd01tWDIrdXZnMlB2WEFYRDYvb01QRnViQW9nTmRtYUYvbDM2?= =?utf-8?B?dm11N2tIeGVTaFRpMk4xdzlnMFJpUjdoc2lCRlBVK29zdHBFbVNmekhXWHg2?= =?utf-8?B?cXRDbi9odVA4cTFWdjFHSURLWDhsamU3NWxtVmNFeUFvc3dNUGsrNHpVWjgy?= =?utf-8?B?bVRkWHFQTWdWVGQ4VTRTQTY5MG9reUpLU1RndEg1b0wyNW5aM1NnNVhicmJu?= =?utf-8?B?RWVQTytCNmZYSlYzVXkwcm85UDFMSnZrdmRMS2k2QWxIc1dkN2ovd2swNG5E?= =?utf-8?B?c01GRVRUcmdCWFhXRHo3UjlyN2Q1K0xLdTdkOFRocUpmMWRFdE5tcU5Tczho?= =?utf-8?B?QlNmYXVJd3NFeHliRjlZS3dQUDJYeGpEbk4xUmc5ZTZyb0tRWkVJNElJbHNa?= =?utf-8?B?UTZoa1YxWitOOS9lMFZoM0ErZS9ZQ0RjdU9tRHdadVZ6a2h2WVBqNVZudFhX?= =?utf-8?B?WEFiZkRsdVpuTStVT0J3bVZRcmt2OVdZa0JMQTY5cm5Yam9ObnVIVG14Tm5m?= =?utf-8?B?T05uLzBrQitWWElDdFViR0NiZkhUTExhZzBuV1R0MUVIdEVIY3dKclR0WmpU?= =?utf-8?B?SUlYUG1ZNnpMejRZUlVvQTZ2V2tqK0hxSTZFT25kdE5FaFdNZDNsS0dQZXlB?= =?utf-8?B?Z0hZeldiNzZDdDhoeWg2OXVUMHI2UWh3dmpmZC81c2hJcmdybHFTbk1PaFh6?= =?utf-8?B?elBuMm5LK2Zka0RoUnQraGdMb0hVN0JGUkRsU1RxdVJpWG1OU2VQemU0eTFC?= =?utf-8?B?V2pBYWJnSjQ3WlVMMnphQVN1ekQ2RmtuY3NZUWVpcytGSUMwUm5NeFAra2tC?= =?utf-8?B?eTcrZG9qVmlLbFM0SnVUdjc1WGIrMGZKVUlhNmg5U0N6ZkZuVzJpbktjSitk?= =?utf-8?B?ZWlXU1BKNE1OcDVySWFzcTRmY0pZak1JTWVMak13dzBCRjBuSGMzM3U1WDNM?= =?utf-8?B?ZENLQnlPVno1ZUpEMFRmRnh5a1YvMGFQc1E1Q1dTTEZ1QlUxSzI5d2dKM0Np?= =?utf-8?B?S3JrcnRpRTVKeDllbVhEK3h2U0Q0OGN1ZUQxOHZGWlcyZ2NFMHA4N0xJM0pm?= =?utf-8?B?empNendDUkI3d3J0TXQ2WnJBQm40dEw4dmFpMWNYd09RUXJ6MU9iZjBOOS9S?= =?utf-8?B?VHpCQXFVUE9iWXRnVW9ibDdRdDNBTGRncExmNjFBdkdrT3NOdGtDMUs5dzc1?= =?utf-8?B?SktIN0dhWXl3cGt3ejl6S2lST1I5KzVpNHlvSFZLaDlQa1NyWHhvS2NoQ1k1?= =?utf-8?B?ajVVUzNpcUpPZ0FGdlNSTXk1Y20rNmU5QjNFN1pzT1FuSzBycnhreGJpbmdJ?= =?utf-8?B?QVMzbnZ3anExa3J5aVJLK2RGYVFwUEZEUHE0aFJlQlpDYlZ6aWxCd2IreWYz?= =?utf-8?B?MnJxOTJsc21naEJjaG8wcWR1U2NJdUg3UERBZEpZbmlTS25TWlhaeExwTU5J?= =?utf-8?B?Ti94c2ZEa2VIWTNQS3dpck1zeGhRajlKQnNCSnhRS2Y1Vmo4SmVnd3FUNmcz?= =?utf-8?B?d3VZR3VtbFFRbU5JdTkycCtrMTc3SkEyc2tzSWhuYjh3ei9FWllkRUtKcUZj?= =?utf-8?B?VkVHRnBpZkprbTB6Q0Y5OWJsUThJcUg4b3hmejhoWkN2ZWFXK1FkM3V2djN4?= =?utf-8?B?SDN0bUdvd2h1NWVHZFgraU5leFVVMXR6UGxPVjA1ZzdjRGxycXNqTDQ3MlB6?= =?utf-8?B?MVBMWGxyTFF6RTk3SDBySmdvZ2dHRDBKK2lROWF0cGJYZnlteFpwOWIxVEtG?= =?utf-8?B?MWEydVdIc2hOLzlxaWQzTzhjck5zajVaSVhpcVU4QmtzV1VZb081Q0lUK2ht?= =?utf-8?B?Y0ozMnAzTDFMeWJzWDhwK2QwL1JjNkZONExrY2RFM3VpQkwzRzlYTG94amx4?= =?utf-8?B?RXhGZ3R3SzBFeGs1Z2F4dE5FZlh5WXIwQzJYNEw1L2JXU3FCYUQ2MkV4ODNl?= =?utf-8?B?cGkyWmxnbHh6R1B3K0krbzgvVHVWbHVwbXZDQzNWKy9TWjVacERyZjRxc0J0?= =?utf-8?B?VHBFUW9kNVFhUVZOTWVldlFkVjRQZjNVUjZBam9YM3dBKzViSGFmVEFkOTFs?= =?utf-8?B?QmlIZHVFdXcreUdIeWwrT0hma0oxOE1VNjVHeXFMMTJRYXlQUWJ1UStNOFdD?= =?utf-8?B?ek1Rd1YzbGxvM1lneHJWaC9UOEcxV0xjS1l5TUJ4V1hmTHM2d0lEUWNWMlMx?= =?utf-8?Q?1XlVQwkgpA6kYbW734?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 040b751e-5a2a-4578-d517-08df134d0be6 X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB8371.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2026 17:16:14.4277 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: yP9mlXsqTt1fzeF09feTD+wBnvQ4TzeslAIXm2l/hTA0PyUaCtr/LSo5CBpsWAAX X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9102 X-purgate-ID: tlsNG-ebf023/1789492601-C0AD8B50-599EA6B4/0/0 X-purgate-type: clean X-purgate-size: 1518 On 13 Sep 2026, at 23:39, Andrew Morton wrote: > On Sun, 13 Sep 2026 22:23:58 -0400 Zi Yan wrote: > >> This patchset removes PG_private to make space for upcoming PG_folio for >> identifying pages from a folio (more details in Note below). Instead of >> checking PG_private, all code is changed to check page/folio->private != =3D >> NULL instead. >> >> MM people are cc'd on all patches and subsystem people are cc'd on the >> cover letter and corresponding patches. >> >> Patch 6 is picked up separately in f2fs tree, but since mm-new does not >> have it yet, it is sent for MM testing. > > AI review claims to have found a pre-existing critical level deadlock > in f2fs: > > https://sashiko.dev/#/patchset/20260913-remove-pg_private-v4-0-848550f75= 74e@nvidia.com > > it also had a few things to say about this patchset and, as always, > hugetlb.c. It seems that Sashiko overwrote my patch reviews with the reviews to Matthew=E2=80=99s md patches. :/ I wonder if there is a way of recovering t= hem. > > > Thanks, The MM bits appear adequately reviewed and review of the non-MM > bits are, as usual: > > Great to have but I won't permit lack of other-than-MM review to > block MM improvements. > > So I'll queue it all up and shall push it into -next after a few days. > > Acks from non-MM maintainers are appreciated. > > If a non-MM patch appears in linux-next I'll autodrop the mm.git copy > of that patch. Thanks. Best Regards, Yan, Zi From xen-devel-bounces@lists.xenproject.org Tue Sep 15 17:40:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 17:40:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421995.1647601 (Exim 4.92) (envelope-from ) id 1x6X9J-0005Xl-VL; Tue, 15 Sep 2026 17:40:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421995.1647601; Tue, 15 Sep 2026 17:40:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6X9J-0005Xe-Se; Tue, 15 Sep 2026 17:40:53 +0000 Received: by outflank-mailman (input) for mailman id 1421995; Tue, 15 Sep 2026 17:40:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6X9I-0005XY-Fb for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 17:40:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6X9H-00HXrj-Sr for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 19:40:51 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa982eb-2eae-0a2a0a5409dd-0a2a4501a2ce-32 for ; Tue, 15 Sep 2026 19:40:51 +0200 Received: from [40.107.201.19] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa98322-5984-0a2a45010019-286bc91304a0-3 for ; Tue, 15 Sep 2026 19:40:51 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DS2PR03MB8418.namprd03.prod.outlook.com (2603:10b6:8:32c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Tue, 15 Sep 2026 17:40:48 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%3]) with mapi id 15.21.0406.007; Tue, 15 Sep 2026 17:40:48 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Gqsr7afEe8MXHi4A9Nh+Zmjw+Tg8+nrqfbB41Mg6zzGVPejOnH9MUvQS6PHQWgw5Ir12xnRt6jNxL6HSOUGt/iWHvKYA5sPoQSH/+ssq+m1LzWNR1/BCaPr+XG04lRkoEyqT9YhR1aeUPXGUZVW3iwqM/RN4mosgJFL31DNedrlOUkx5NamAUAtmxqjmRV7dlmCi7NJyUpZsSN+oK7U+9TMaKQxd2qDEg8HP1Wqcxbj7PlRrCnizGh0PdLuBk28u81TeAA+BPEMg4t1cUtTgW8+NtRmWhYQU86D+D3z6p34FTG5FjBt2c05wdvjqKfmR1/a1msWCuoGjYDhLxbHi7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vUrYNOI9r0C0mwIIGWx2ncqfPsgZgCcsFQo4810CMeA=; b=lDMacFVP/DK6JDL9irPgdP5mAuy4tLSLbLFH9QBewVd8CXIToOBLr0eICPTrjJdrWcg/Alsn3dim3dj2f42HrsvtM2V4aM0/0qZ1tO3zSKjsSXJcx/3KIu3yc5lYBt+K/b/diymSrvxWVm+VeOMtNyL0ZFZNu66/rNNv2fqbvyKfgY4BKm9OtORtCRcCB3ZQrMeqwq69mxR636VElUMQQd/PPV1YtRQ+5RZH43zK0VG7/JbnY8mpXBjnjcmnHN6CTol9eCFFVLOoU+M95yF/x7QFTQgjZlPgpLq79wmgIAcU/0qaw6rxxNTbyKElpLQqFIFaKIWgRPKyCYJtJku3Qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vUrYNOI9r0C0mwIIGWx2ncqfPsgZgCcsFQo4810CMeA=; b=HOnDeN1/65PKazYUxejH5HN43hB/rGaLEy4WkBusinNtPu83ajK7wUyvgeLklwIEzheXo5WLsvUixBbKGy2W1Ca2gdJlqW/crJ2LV4hirDFU+9fpjy2G6fFveboc7mvy1zeP/EnS8nIw41YtuB1H4vcz6FzUrIP/yeV3LTkJJ4U= From: Kevin Lampis To: Andrew Cooper , "xen-devel@lists.xenproject.org" CC: "jbeulich@suse.com" , "teddy.astie@vates.tech" Subject: Re: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update Thread-Topic: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update Thread-Index: AQHdQWMYYuOEW7sUTEmdu2MmKUu4LbbJV30AgAaXyo0= Date: Tue, 15 Sep 2026 17:40:48 +0000 Message-ID: References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-4-kevin.lampis@citrix.com> <0aedfbad-29ae-4083-89b4-5c662398553d@citrix.com> In-Reply-To: <0aedfbad-29ae-4083-89b4-5c662398553d@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY1PR03MB7996:EE_|DS2PR03MB8418:EE_ x-ms-office365-filtering-correlation-id: b028f62b-9aa0-444d-abdc-08df13507a78 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|18002099003|22082099003|38070700021|4143699003|10067099003|11063799006|56012099006; x-microsoft-antispam-message-info: k+TIVgZcXnk4MtYWpB5tXyhiFnmp8Gd3rD+MwgjJg5H8o7rEfLzZppklT8hEvcXDEm8I0JHBC0vGvs0IfaRSNVjaQ1wY3V7pdx7NIFJKM0vbrHPd/Z1VswvrALMZiePWxcQOotV6TINbj5nHONWARNp7VccEVtLzfQV21mpz6EdQx3enr5P4hlv3zxTpocDIZIEV97OLCB7KDkJvHJQNf8CHm1MuY3v/onzIoIRpH/yciDO/aL5f7uTVvp5mHf3//mQeJUFPayxzEoXeEBWs95teXA8rQp2j4a0g/tRuPKb+yoXLImZlojaX9nKLEQk4NTE9wnj9HJneG77LOl6ZfbTFmUXgAJRq3DqqULNBwr35lhEcQEtNg2EQFZBFlJOBqxzEdHYk4cAOaZAmX7xUERd3A7/MUjgcjBkR6KmJD82Pq1Fnmr0SMDXeiGjBf6VHKcnM48uZGQ4HwgR886zn2mQpswLNViRqih+7ItioNKvVRRxqXsrCl7mZzoT7z2bSpoHkrCH7NsFWCARRiUwgjo1y9d9DvX+s8LbR5i96EJmPaxnvRzuzgZBH0r7GjdtKan52NMty3Hi8YcftX8x6WcrjZ+kjJZ+7S0tHDuvAxWWeMz9OczqDRA3Xm5UeccssPEr2CoDUCr/mdJiqUlIiEIzHzSH3WOc6iFlkk4Fj0YEmftWeP9T9H4uL5HNaL9/0/lTWq/9hNUy16wChBQi4Rq8IlmzPsDRxYvM8kZDdFbs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(18002099003)(22082099003)(38070700021)(4143699003)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?3N8opkPzxWymciWYmRuw26PIv3m4Nwp6/RriaDHTn9vZDw0AM8J+AvvCxJ?= =?iso-8859-1?Q?l5n2ef/+l0tcMbRXMbOQEJITAhkSqHroV3xCXKwpY6Dw96CXqJR0SvMFM1?= =?iso-8859-1?Q?BhM4eLhkY7ZJIheE7q4fPceXeNEMJiXYMea5PzEb9O/8ch907uPPCv+ajq?= =?iso-8859-1?Q?eNFu70+GWmOUBfZFc15zHLmhlwQ0aSZ18yHonIkAop3OqOgSag8+IkZZuP?= =?iso-8859-1?Q?oXHTLMc40DpYUp299f2y1RTUZM1e+UhwvjbBt7hI/lZSXyS8+ZDRi+plVQ?= =?iso-8859-1?Q?N6adqayItoxMXIB5hTcEg48N+hUy08LgfP8xgKAcq/BDdKTnFZAzDem8F3?= =?iso-8859-1?Q?aM0HEPiuGnbejbSor0KvqTmnT0tnnqWesVIGpstHIUDSVCCoP/eLm56iBC?= =?iso-8859-1?Q?HjJC8+jZcKpGI2Mz2I8uvgyUjUA9zAHS7XCXEzYnbs5YVsqowKgL95DIuI?= =?iso-8859-1?Q?686GNcS7KtKDL6IMBJWw4B5thpKKL6oxIrJxLBeuRZ4n0x5ZjNrCuP6TOV?= =?iso-8859-1?Q?pXlPUpUAkherZCS+ZAAVrSOzSoWlieajLlQECgVXFXPRO539OiMjJ8ySz5?= =?iso-8859-1?Q?8GCbsVN5eLi/N+QwDl3CVdqpn8xeB50+j1OLevdAZBGHhtkw0Rtl8vtAgF?= =?iso-8859-1?Q?8CmH3TbN6UZuT8KHCE0SA+Dc/Yy+6ywuSfrmKMudMGDFW13f6OhMau8cRd?= =?iso-8859-1?Q?PGu4xp5Ajrbc3HSaxSWPqg8j2k5kFuHfE1XeiDc85l+GAQvNaVjcOvt7QN?= =?iso-8859-1?Q?efKsmRlWSRBxvjhJwpUP4A1+RugBmAUaPMzOlUkk4T1lwmQa6ZB2cOfqIA?= =?iso-8859-1?Q?oXG7cA/D2sS9ZdFnOJBEOZAJ9HzjlszXKKlA+CU0qBr02i7oioPwK+a7CC?= =?iso-8859-1?Q?acbtK7MeYpc0GmT9Y8YuFGESz5KFxU+hjWuAhg02TzLdUHvaiYWrXT3K7+?= =?iso-8859-1?Q?+b6zX3pHoch3nt7YvEuRJskTCn3jHvsRwL6+fsLvFim/y/MdVVPQwnot/F?= =?iso-8859-1?Q?kjhLcXMb6JICLiKHNZ4/CObyd8WT2n8nUXRMtv4vui7tTZwH8kaUjHM1zk?= =?iso-8859-1?Q?VA+DZYIK0f3oewtBSKV1C00KGr6ocrHK7EDwnzl+Lu+eO+KgGDes5/rsvz?= =?iso-8859-1?Q?Aad+S3zo4Q7yyYdT5b0x/ptXTGwkqhNQ0gKW83JovFwskfhY3jbBHt2beS?= =?iso-8859-1?Q?VGoisb3Q1HJEyvRj4N+MN3VdVF3PK7wxIFlOlQaRdihPP2OVS7xvNfO4Nb?= =?iso-8859-1?Q?ZXbwbHidBKxfooQPr8yo34BR+zImzbTYPL1Pkv6Sr/uB2HlRu6fqr1tDUx?= =?iso-8859-1?Q?BenpXZkQTglYE1rzw12/+42tu63VNX86N9AULNBnTIrhsr1i8oQX/EaOdb?= =?iso-8859-1?Q?CpUfq2Sob11Z6QOSVFfZ1+F48Q4Z4v95h6X4eIK+qthnPRfSskE77mJm9/?= =?iso-8859-1?Q?wJiM+GZPMXVz8eCN/0g4/vj3NtezLMPVhd9rdhPREj6vFafNvG9GFfGB4w?= =?iso-8859-1?Q?2SlESy/B9REQ6tBpXDrqBLPtrzgGQNC+vbrGkQPg1oRj2XM4C/vMNwoUJT?= =?iso-8859-1?Q?4aOZOUHfaYFy5arlS97U95LVC3x6LpLgKw+Y0eaGObxcNihviPvJK1wugY?= =?iso-8859-1?Q?EomGgjtnfNFlobhpY8q4mNdDz8YV1UR/F/blZr4ecStD/Yw6tlExR5nAGn?= =?iso-8859-1?Q?cDN27IxOM5wh5KSevFfVuh4H55MEaBWgwEYAJi0NRpYQ9ge979tuwHHwF+?= =?iso-8859-1?Q?w08MaIoinbxVeoUWPqSX0a4rxFDWFWU5LUpUg+wUH1HuQW?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b028f62b-9aa0-444d-abdc-08df13507a78 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2026 17:40:48.2868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: M5ybPd6r8I1gvswsGtdKTX0Q//g78XbdcC2w/Fd3/hU3tIUtUUDyUa0jHAc6NuTFw43zeIx3tMZgtO6k8IDtcw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR03MB8418 X-purgate-ID: tlsNG-d62444/1789494051-1D87F757-E3B7FE8C/0/0 X-purgate-type: clean X-purgate-size: 616 > you want to wrap the expression in _t ## e_from_intpte(...) to=0A= >hand back the type safe version.=A0 In turn, this lets you remove the=0A= >'.l1' part of the assignments in the following patch.=0A= =0A= That would be much nicer but it trips over `-Werror=3Dunused-value`.=0A= =0A= I don't know a way to solve this without adding `(void)UPDATE_ENTRY(...)` t= o=0A= every call site or doing=0A= #pragma GCC diagnostic push=0A= #pragma GCC diagnostic ignored "-Wunused-value"=0A= #define UPDATE_ENTRY(...)=0A= #pragma GCC diagnostic pop=0A= neither of which seems very good.= From xen-devel-bounces@lists.xenproject.org Tue Sep 15 17:42:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 17:42:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422002.1647612 (Exim 4.92) (envelope-from ) id 1x6XB5-00062J-9p; Tue, 15 Sep 2026 17:42:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422002.1647612; Tue, 15 Sep 2026 17:42:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6XB5-00062C-6J; Tue, 15 Sep 2026 17:42:43 +0000 Received: by outflank-mailman (input) for mailman id 1422002; Tue, 15 Sep 2026 17:42:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6XB4-000624-D9 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 17:42:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6XB3-00HYA8-QD for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 19:42:41 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa98391-2eae-0a2a0a5409dd-0a2a4503be64-0 for ; Tue, 15 Sep 2026 19:42:41 +0200 Received: from [52.101.62.9] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9838c-fae8-0a2a45030019-34653e095667-3 for ; Tue, 15 Sep 2026 19:42:37 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DS2PR03MB8418.namprd03.prod.outlook.com (2603:10b6:8:32c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Tue, 15 Sep 2026 17:42:33 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%3]) with mapi id 15.21.0406.007; Tue, 15 Sep 2026 17:42:33 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vPRURJwUI9cbGGOtBMdGPEurIWB/B1bwqvf1XO/wcKCfL5vePF8BTr+fVFyxtRMAb/zUEVk50ef/gkcJQVCn4K/7awWIZGLATYitCMG/yXpFVFGGsrLLoxS61v8gD8R8g7vi6IaG6Vlok+dQVdKec8bruNj7c2lmWjjSU+EbbXmhxarl6Q3UBZtGdhVpjvvqfV7lfuj3hZAZmfYIgOjS0xW3Y8GgrIrioFOyS4Hd/8t0iwXGeIQoYQ9QtjsTEM5Oyv2D/qJr/kdgwtWpsJ9gY7Pv4xZYJvY/B4F+sAen5ODte6s9xLjXN/QYT/o9fl0n2ybyh+XC4EnHvlcnqEpgVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p4gN79TQcPC5idfvpcfAo9WIw4i8UsGMHqTsnqefc7w=; b=NRZwooYzgo+fudkqNo6iO1/LbO3GNNZrLpydH7OCtuCIABbZJXT4T3E6KA/jHIleIYvDqI8l7gI/kS0dWQMc+nAKk3YT1Qyfr9PicBZbBmITcKDzId93xgTAnlb5crMEJt4s5nb7IYcGRf8GnyS8AxVenzQFGW9lkLOjj53/uvL6y75exk3QEoqaskMXYxTkzakdVK5SeZhHhtZA/BZkkd3uge5U+8/SLTQrgXiCAlJLOmGqBztNZ7thoChQv6WJh9VTATKfvYr06Wv7HE+oGUuxXtVbK0+vfOhx/MGHRrojD6eVAJBGIVLRZ29DuIzyzv75z3b0LGJpG4jeh/4E7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p4gN79TQcPC5idfvpcfAo9WIw4i8UsGMHqTsnqefc7w=; b=LQQfzW8b3Q3FGDji2/8XR//MfjZPakYAd1sxJMGZJHAAyXr8NHF089to4tcG7janaP7m31RMLne2mFF06mu25xfDMkgbokdtoS0z1TDSoy1KY2cILjX8P2irVq1ICc+jeltVteZFAqBkuGSUv3HGkbf4WpFNrLXYA9QPMUnBp20= From: Kevin Lampis To: Andrew Cooper , "xen-devel@lists.xenproject.org" CC: "jbeulich@suse.com" , "teddy.astie@vates.tech" , Juergen Gross Subject: Re: [PATCH Linux v2 7/7] xen: Add new Xen pv-op pte_get_and_clear. Thread-Topic: [PATCH Linux v2 7/7] xen: Add new Xen pv-op pte_get_and_clear. Thread-Index: AQHdQWMkTXxtUlg8hk+HuEHbfTb847bJVMcAgAaZYss= Date: Tue, 15 Sep 2026 17:42:33 +0000 Message-ID: References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-8-kevin.lampis@citrix.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY1PR03MB7996:EE_|DS2PR03MB8418:EE_ x-ms-office365-filtering-correlation-id: eb2847da-ac02-4e2e-1e41-08df1350b965 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|6133799003|18002099003|22082099003|38070700021|4143699003|10067099003|11063799006|56012099006; x-microsoft-antispam-message-info: 5nVsYgAZoXGYUrLJj6+3HSK5bOXqRHvohEs2E3NxqfoASR8bqrq8o2yOBnvq1Jlz0tESIx1fvMoR9Jvl4K+vbvukuTJAuIyO0uT5itZ2EQ+I5jj/Z0n+Gokd482n8vzyeU6boW0dephKoQKtBf41dODMP8xEE0faZSJ7GOKSoLLgf+aziUcyU6PvC2D9r/zFzE6JhNA2XSSx4jTXwCu2vpsVO1/DIia0gYX2ZRNDC+0FB7BENBXGtEIq92/p1VKqS3qzZZ3Aji+I0kqs9o+72mgFhepuYgUX6eRGcZch1GIk2Nyy4cHgBBiKWFhdZqpgRoT8jqr1PFBgHBluQ0C8t8zRTA/aoLy7FhwbUX9Wdt/oRFwdLt9RCj944uD8HJKMeoR9jwV9SYD7YQRFeTq20KFb6q+Ff/e8DCTdYjbvB1ICHxuRdsAaACQjmWQjVV7FxXN2TJSO8HQ9OwBIMXXdHHHGddieUNSrFjjasNwHt5C87OE28/Je29soUujeImLhv4ah9iynCvNTHJJIFB1mNxulczmPkvx0AO/E1j+Q8/XFEdVuQGGjlbnQtOw4ecKxUB9tvBcEvTMjVRxW1yV99O1lsKurHXYoWnFl+NBtQIX2X1ZBk+tgdbwUGszoYFpfqZzFkneF+SPeoAEg7SGEPWWF3/p1UBmqI8b/a9ctew5AVgehD3Y9VWTLAPq7kBhRu/MW+3hUVWz50H8u9AefsMQLy9kfPeI/I3cwJDi/dOg= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(6133799003)(18002099003)(22082099003)(38070700021)(4143699003)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?vnjQDTeuVN8Tl8ekJ5WBHwZ31GpSFR9Qj1h2FEwViELJKn0aDerDlsIQgA?= =?iso-8859-1?Q?roqdTXU8pG2M/l7H6zJaHXLO+Rfsn9wP8Y/J1/EQW1z0z6fe7sXjRJ1zFb?= =?iso-8859-1?Q?+vEOmpgI6KnCTz+cNBwxDhuIXntg5LIkZzOlECwViUjjVRpKkx2I/YHZZQ?= =?iso-8859-1?Q?Q7LuCmzImkG/q+4mAY8HKGegTQpWVJ3Gv4JUprEiVsCesLbJVD2ZfBxRYE?= =?iso-8859-1?Q?AFkhu+eCtvlVXnrVHAk9pf634MPd4m+PgopiEgoh2FAuYEn3qAr889RtVs?= =?iso-8859-1?Q?+mERbqgU4ioxwbwa2j2QR9H0vAwBAhgVKrUf15aw+O6M7lnoyU11d+3Nh1?= =?iso-8859-1?Q?2CJmwCfEc1ohtwrx4IO9bDVebaUPwYHcl6Cj/VcMkiNVRq+pdPU1QVXTWP?= =?iso-8859-1?Q?uzQ3lYdNuLsGUqjhmvuLan1yk1bvWrOGd/19MORquqvqI5QdlZe7isTEfb?= =?iso-8859-1?Q?/bRkcvUeJtwh9tWo+9eG6UwE7u2ciOKuwGl3OTEr4D2cQF4lLV6FnLPXXn?= =?iso-8859-1?Q?U9xy+W5LfFaVaS1f7GTyyBSCrFJgXZQEWlLBEPpwrHcIfd0PG0EHJ4WK98?= =?iso-8859-1?Q?IKSLTrvnPh76hGAIioVx6Q74NIm7P+nrZRvlH7CswxksCSQ5Rw4UkTt5bx?= =?iso-8859-1?Q?XkFlzlwyNCjqLaqhVOXBfECiZ5dLkGHjaEaW0arJaXbKUVLyxeUNGYqRQE?= =?iso-8859-1?Q?6v5S87DApEITOyGU51Dv3KN606Il3YvzViFXEu5j/u/az5NoU9mRXZWKuL?= =?iso-8859-1?Q?FO0HAspHRYAf7Q/+4RcISsQbUSOB7Q8I8+VOpNtikBDVs9mzz1nYBJiDdG?= =?iso-8859-1?Q?vgD/6Lwkuz6oBnYNJgocjKcF9Snm4b2VyiZe6JgqTlWZ6KiLHokw65JTjN?= =?iso-8859-1?Q?8K9JCcQAWv1Ocb8YDnk9nTFWiUgViuyZ6Hj+FLtryGbbTJumDL9QkD13cP?= =?iso-8859-1?Q?ZpO/ygq79I+JFq6e5DmuryJ+H3oTN5RzeoldbwCl0mZcv6zAAIbctxO4qh?= =?iso-8859-1?Q?nHvG4j66qbM/kh1XVNKUzwlJ9+OdOJg9p6e7rpRuuLFV6rLe9utM3L3Q4A?= =?iso-8859-1?Q?CB88nr7XTa7EIDGDyT3k2Rdit8WhC1QDDVWQyLQc2pt3PLF1CnqWo7zHx2?= =?iso-8859-1?Q?/8yZuSsm1ypEctzas/EC38A7L71EG+Ng/cWCMV5/nKb6V5UDAK2+y0MuPU?= =?iso-8859-1?Q?yFNmCGlPAoI0cC0RWpzfbLWGA6+0lqIboGcLPWrac6BRcU8XkjhAGf7Z99?= =?iso-8859-1?Q?Dhdw3SImGBE9zSeI243uxLrvv0ntv7w7OGVHD4PsIEa6w+Nz+BT1Nij3Qd?= =?iso-8859-1?Q?wPa6ENxiKCT96LDSzqsq4SYoKlEDXN0ASDW7Ik8SvoSG0oEqnVraEH+B43?= =?iso-8859-1?Q?xpO9zsi2Fm6vCLzQuuoxJk7plxJ4ytAOj9Vibq3cQVFmv8jYSnmFamCCBp?= =?iso-8859-1?Q?JurrJp7ODQo6b9FbwIJF327fFXLhGwt033NJPTw8TkbH+7IuMPQqJfQR8s?= =?iso-8859-1?Q?PZTEr2Nleyg85cHL9uWwNAXAtGhfH0PNxfFg1He7xyzTAh2GIS7waGus57?= =?iso-8859-1?Q?RNkiirZs6HCJLa/RYMPZ/S0C9zVef3kpcC23T1mV2bduVg+VrIIffi4OQD?= =?iso-8859-1?Q?kirsiWdoynDJVJha6+VRovdDypNnfOoBk6DKMxsFg542fK5eN1WSl5rKrR?= =?iso-8859-1?Q?nyled/ol6roLFm2JViTunlvP/R19VGQ4BO7MquP6E79mKHvc6HIkTO0X8g?= =?iso-8859-1?Q?/GQ8oNjaZsSjbHO7w11qPOZNo8Wp9T0EgLexyL291dlqdM?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb2847da-ac02-4e2e-1e41-08df1350b965 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2026 17:42:33.8604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xRU2VsoLh49Dwv3re3oXuukliP7TAQL+JwlHPC8ybPP/ha/3WWpB3RYgQN05gOb50kcol6eS82vgjaqOpVKEFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR03MB8418 X-purgate-ID: tlsNG-33051d/1789494157-766FB4E9-654F565A/0/0 X-purgate-type: clean X-purgate-size: 3288 >> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/para= virt.h=0A= >> index 0591aa38fd85..0a3a286c46f0 100644=0A= >> --- a/arch/x86/include/asm/paravirt.h=0A= >> +++ b/arch/x86/include/asm/paravirt.h=0A= >> @@ -373,6 +373,11 @@ static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)= =0A= >>=A0=A0=A0=A0=A0=A0=A0 PVOP_VCALL2(pv_ops, mmu.set_pmd, pmdp, native_pmd_v= al(pmd));=0A= >>=A0 }=0A= >>=A0=0A= >> +static inline pte_t pte_get_and_clear(pte_t *ptep)=0A= >> +{=0A= >> +=A0=A0=A0=A0 return (pte_t){PVOP_CALL1(pte_t, mmu.pte_get_and_clear, pt= ep)};=0A= >> +}=0A= >> +=0A= >>=A0 static inline pmd_t __pmd(pmdval_t val)=0A= >>=A0 {=0A= >>=A0=A0=A0=A0=A0=A0=A0 return (pmd_t) { PVOP_ALT_CALLEE1(pmdval_t, pv_ops,= mmu.make_pmd, val,=0A= >> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/as= m/paravirt_types.h=0A= >> index b4c4a23e77a1..1bd4c19450b5 100644=0A= >> --- a/arch/x86/include/asm/paravirt_types.h=0A= >> +++ b/arch/x86/include/asm/paravirt_types.h=0A= >> @@ -135,6 +135,7 @@ struct pv_mmu_ops {=0A= >>=A0=A0=A0=A0=A0=A0=A0 /* Pagetable manipulation functions */=0A= >>=A0=A0=A0=A0=A0=A0=A0 void (*set_pte)(pte_t *ptep, pte_t pteval);=0A= >>=A0=A0=A0=A0=A0=A0=A0 void (*set_pmd)(pmd_t *pmdp, pmd_t pmdval);=0A= >> +=A0=A0=A0=A0 pte_t (*pte_get_and_clear)(pte_t *ptep);=0A= >>=A0=0A= >>=A0=A0=A0=A0=A0=A0=A0 pte_t (*ptep_modify_prot_start)(struct vm_area_stru= ct *vma, unsigned long addr,=0A= >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pte_t *ptep);=0A= >> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtab= le.h=0A= >> index ac295ca6c92f..b0d7d6520984 100644=0A= >> --- a/arch/x86/include/asm/pgtable.h=0A= >> +++ b/arch/x86/include/asm/pgtable.h=0A= >> @@ -58,6 +58,7 @@ extern pmdval_t early_pmd_flags;=0A= >>=A0 #include =0A= >>=A0 #else=A0 /* !CONFIG_PARAVIRT_XXL */=0A= >>=A0 #define set_pte(ptep, pte)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 native_set_p= te(ptep, pte)=0A= >> +#define pte_get_and_clear(ptep)=A0=A0=A0=A0=A0 native_ptep_get_and_clea= r(ptep)=0A= >>=A0=0A= >>=A0 #define set_pte_atomic(ptep, pte)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=0A= >>=A0=A0=A0=A0=A0=A0=A0 native_set_pte_atomic(ptep, pte)=0A= >> @@ -1243,7 +1244,7 @@ bool ptep_clear_flush_young(struct vm_area_struct = *vma,=0A= >>=A0 static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned= long addr,=0A= >>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pte_t *ptep)=0A= >>=A0 {=0A= >> -=A0=A0=A0=A0 pte_t pte =3D native_ptep_get_and_clear(ptep);=0A= >> ++=A0=A0=A0 pte_t pte =3D pte_get_and_clear(ptep);=0A= >=0A= >This looks like a typo, on a path you didn't compile.=0A= =0A= I don't understand what you mean here.=0A= =0A= If `CONFIG_PARAVIRT_XXL` is not set then `pte_get_and_clear()` is replaced= =0A= with `native_ptep_get_and_clear()` by the preprocessor.=0A= =0A= If `CONFIG_PARAVIRT_XXL` is set then we jump through the pv-op machinery=0A= starting in arch/x86/include/asm/paravirt.h:pte_get_and_clear().= From xen-devel-bounces@lists.xenproject.org Tue Sep 15 17:45:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 17:45:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422015.1647620 (Exim 4.92) (envelope-from ) id 1x6XDz-0006YA-Mv; Tue, 15 Sep 2026 17:45:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422015.1647620; Tue, 15 Sep 2026 17:45:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6XDz-0006Y3-KB; Tue, 15 Sep 2026 17:45:43 +0000 Received: by outflank-mailman (input) for mailman id 1422015; Tue, 15 Sep 2026 17:45:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6XDy-0006Xv-Sr for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 17:45:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6XDy-00D0UO-9f for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 19:45:42 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9843a-bab6-0a2a0a5309dd-0a2a450acb5e-10 for ; Tue, 15 Sep 2026 19:45:42 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa98441-f2d2-0a2a450a0019-4a7de18d8ba7-3 for ; Tue, 15 Sep 2026 19:45:37 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e6b885ef8so505415e9.1 for ; Tue, 15 Sep 2026 10:45:37 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e83da071asm7154315e9.8.2026.09.15.10.45.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 10:45:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789494337; x=1790099137; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HmUQ481Rpl/xf/x3B2lvULx6YRYaBZClw8WZwBpgsko=; b=Z536YEBvwFwSIjwwGEN/18UIoBqw/uMrz7r8sG/vKGnfhTCzeWlkUjIMfqfMdTPqwy 5JtA4q5vrO02o6BLpyg5uu/XEtDXXPESUJGCDTgP2hJFUvnbsJfpNH2GMhRA0zyDjnHE 2UtkpO15o+cjqp21VoXIBXXi4P9i6l4kSJMaDIv9JS6p+i0oSWbqM4/R0JwnP0410tIh MfngjtFWBX4M/nQVLB6BIOM9nUi+BOxvuTyikBb/I/jtK/GTGbwV00JSr7lBAYg3shGX ipHNeoQ7/mRjzeQvqzwEFjMzAnCr2M347QVKP3e/d4LDecsxHzccc++8xSVgfgD0IJMS wb3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789494337; x=1790099137; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=HmUQ481Rpl/xf/x3B2lvULx6YRYaBZClw8WZwBpgsko=; b=O61SIRNidEKWxOvnosniNs5qNQBudbIAntT+1cPVXwpCGKA7JUqjqdc1LL2+CBZ0ip 6K0UWoG2yNahMhMOqNPV27Y+Qw8Rc1bJmw8p6++C5BfLdvnfW8tVSEsCsDheeKAGlY89 46dgJW5MECyA+Yhtoxv4B6wZTb3LXpqufqUQtLHPf1cqnynUsBXaJcTCjdffemo6g0lw Uhk7ZJnoVvdq980P9JMEF4LJeI35rwkjzlaasWeouMG1DWsa94RI0ETmbFjnxaFymYyR WD98W1ghbm4LS2wxx1HOHmikWqP4/Vu0n2VelLxmAbv5s9QVtqbmmcWc/H3mkAwbgL5g up2A== X-Forwarded-Encrypted: i=1; AKwUvBzb6XJ9xEHaqVkx19vAoe1w0lYSQOlUUvBKi66Rn2rzst9IaMlDopqpCdiF3XoaQBsuwbS+x8wFKGU=@lists.xenproject.org X-Gm-Message-State: AFuF++mtz23IEONAYB3s3FtIR4dDqQF+BiuTLBLeWdlzAUHYnqPqFSnj B+X8HQBWvp8/Zjlyjy2eEsuAzTYZU503fsE6T0HpbZFmw/E6PaNTepOmYQdfrf71MA== X-Gm-Gg: AYBFou3PpamJEmCeQWxjeWAhT7TmqXM57Ofm3lPDLj13IGQkhHo2Fo+KFWJJfsv2k49 Sn3/Xnix7TZtGhc2oPE8DY0bevyKENDmOchLeWWeRsWbtZ+Fn7cxrBONaj9VOd2/aElcnGpDLqI r81NLxHCL7GwxqJxPHnhcYgsP9I+XLIAo1mBlHgGUMw0HbVsim8TEyETwXFl+aVGOgsfHMTqwdL UG0WUi26Ypxv70pUKrlbbs0mt4cjgXnHqYS34o/Ook8A1HIsM614qfjwtcCb55bHH2c+5iyjX/h Le4xbpxLMRjhfQfGlvsq6+b97TeMnMQkEQcGSmkTY7ue9UhuU1d1HLtpPZG+xXOCLM3K2kPnvW4 Qf3M6PohdlktIcpktkiDlNcIcHeRNKdCPbsvK9pp51a93DencqILVXiezHAJDGPnTBwOLmqpqCc ZmANgoTGtw8uJyKQbYCKmPHgDSUnOPuK3MNB7o463SmzNtsuNyoO11N+swxSZpt2WUVvhkLaBxQ yE= X-Received: by 2002:a05:600c:34c2:b0:49e:8184:f619 with SMTP id 5b1f17b1804b1-49e8184fc78mr31698005e9.22.1789494336598; Tue, 15 Sep 2026 10:45:36 -0700 (PDT) Message-ID: <852f47c4-bd95-4e44-b409-ee805a07a5d4@suse.com> Date: Tue, 15 Sep 2026 19:45:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <6bf8f9dd61da4d0fbea096b863f51db08df46c56.1789055542.git.oleksii_moisieiev@epam.com> <1d8be2c2-a56d-4b81-8e36-c4f97099c879@suse.com> Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1789494342-4ABD8CFC-C90512F1/0/0 X-purgate-type: clean X-purgate-size: 2078 On 15.09.2026 17:45, Oleksii Moisieiev wrote: > - io.h > > I'd replace the current comment with something along these lines (kept > arch-neutral, so other implementations remain possible): > > /* >  * Copy a sequence of bytes between regular memory and a memory-like >  * I/O region, e.g. shared memory placed in RAM or SRAM mapped with >  * device attributes. >  * The I/O region must behave like byte-addressable storage: it must >  * accept 8-bit accesses at any byte address and naturally aligned >  * 32-bit accesses, with plain byte-storage semantics in both cases >  * (no side effects, no dependency on the access width). An >  * implementation may use any of these widths, but never wider ones. >  * The helpers are not suitable for device registers with access-width >  * requirements. >  * >  * Neither pointer needs to be aligned. The access widths issued on the >  * I/O side depend only on the alignment of the I/O pointer and on >  * count, never on the alignment of the regular memory pointer. >  * >  * Implementations are architecture-specific; see the respective >  * arch/*/lib/memcpy-{from,to}io.c for the exact access pattern. >  */ > > The Arm-specific note in memcpy-{from,to}io.c would then state the > concrete pattern: 8-bit accesses until the I/O pointer is 32-bit > aligned and for the trailing count % 4 bytes, 32-bit accesses for the > aligned bulk. I'd also drop the "tolerate" wording in favour of the > above. > > - implementation > > As proposed: only the I/O pointer is aligned up; the RAM side uses > get_unaligned_le32()/put_unaligned_le32() for the 32-bit part. The > _le32 variants are used deliberately: paired with readl()/writel(), > which are defined as little-endian accessors, this preserves the byte > sequence regardless of CPU endianness. That is the only endianness > aspect worth a mention, and I'll rewrite the commit message > accordingly (dropping the sentence you pointed out). > > Would that address your concerns? I think so. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 15 18:00:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 18:00:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422033.1647628 (Exim 4.92) (envelope-from ) id 1x6XS9-00015j-04; Tue, 15 Sep 2026 18:00:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422033.1647628; Tue, 15 Sep 2026 18:00:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6XS8-00015c-SU; Tue, 15 Sep 2026 18:00:20 +0000 Received: by outflank-mailman (input) for mailman id 1422033; Tue, 15 Sep 2026 18:00:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6XS7-00015W-SP for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 18:00:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6XS7-003KrS-5b for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 20:00:19 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa987a4-bab6-0a2a0a5309dd-0a2a4505c3b0-32 for ; Tue, 15 Sep 2026 20:00:19 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa987b2-4cb1-0a2a45050019-4a7de18de799-3 for ; Tue, 15 Sep 2026 20:00:19 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso827545e9.3 for ; Tue, 15 Sep 2026 11:00:18 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e83fcb6a7sm2702495e9.3.2026.09.15.11.00.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 11:00:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789495218; x=1790100018; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=DbocWXlcEIDeWQmoiKaYfSe4JLkp81pz5qnai9wv5tg=; b=Z4FcHmmr95xIrMNMFMvLFKAEfuFmUa/NK8xnbKfUsVe1G1LWlvHgWOeJO8SQLGX1Ly WaWBb1N6sg7POE+gxAlHWlxlMLIaon+V5ql0ObT3Z2vauipfsA5nQWCDlPil3Zsz09Eh bw8M8B8gv4w+HPq5t/ZI+fBI5KeNQ310zq1ValgrXefdD3effiyUHFisaVDPLfndonJs JhuCbWWaH5V6t9TFIAkBmwCzCZjIDJIjr3NXEPggAzWSd3P9Ir8iFe9qALz9/kwCviQ4 fPXhgQp87BSF5/pYzrG3lLpPGMAYSHWQJ3F6sBq92APxeR/YrRPVloYAS4KmVA2lPXEI 99kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789495218; x=1790100018; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=DbocWXlcEIDeWQmoiKaYfSe4JLkp81pz5qnai9wv5tg=; b=a/M8cUIwDQ5+DyVheiWUd3FhMt5JeEn/dW6HKO4zuoAWIzOKBgpCHYKYiqS1eygR1y w/tvHxzFFqQNwhWRI9Xpx+1ZCFvvj2haCh6Rnv9mYBSE7Zq4cl/TW5f9dYBQm32eezbS dvDZJVKt74gt8dUMaeFVYJCsljyY7yLlDbUle5enzau8p0AmxwxvnHo+V/cCboZLoxyq MlTOl267rHH9RmJdh88X1WFs+iESAJHWnBl5rN9nhUHa9o3e5OinphtuHY23dDOIlv61 nJO7Vv1qollsXGKn8jKyeK1wPm6Ob8yGpBHxwC77rK4SiDA5kF2sC/D7gBnuhi76NDlq TiBg== X-Forwarded-Encrypted: i=1; AKwUvBxm3J931tlQFFA/yx5TP0UTMOZcPYiFjowRSPwL+ivY28HpDQdy5TCWs5SmC5/bIsJCpZYK1BUvQWw=@lists.xenproject.org X-Gm-Message-State: AFuF++n/7+CK0upilbvacu+sOl6QxujEmr1LZa+An3ojyuWopCoWCTjS Wrjfxyjfp4VcHglsz4vlI38XIY/13bM7V0AKntfjLUzKaNULIWQ1lqkLGuo9n2dQew== X-Gm-Gg: AYBFou0suUghApIvP0vw3vsRwYXxoGg1VYnZWW2xpBiP62DxKHR0DGqYK7fDVwLW8hp XbZXGGxOGhGE4YacSRVP+eIH6zeZndBmJGZ6w8Bm385dbUsiyTIQVHNX93n+PIjClII0YqQAx1w jJ/vvdZd7+jR/+7gvzUcqrgTaSrheAVcDJRy9siY84XigcWJS7nnKCgy5y/AwGODfKCtYYEBVFH SRtvQfuRUW2Dl2MSGZggAoOM0EviwgP9Sj4X+VDyTBTX5OSEAl2C9W5JE5nNCCv8LNxJYAiFeZf oVHNyz2kUl3ut9veWj91YfJfsljKcAWLWsWZ6dEI7VssuPDUKWupvJynVvXgsZmQAW+IeQTN7wG MTTYfeTNXqLljUj7f/KpPl/vZiSb6BY5YYBeE1pxD7CBtj6FwF/o5X74pdzY0eP5NMibORf08ks ORldV+hUV4oBDjVHnJZ5hNA1xrF2Y2wljG9vBUC+ZKHFqaTbmjH6zWxay8tRyRQQ39C3AQT48IY ZM= X-Received: by 2002:a05:600c:8b76:b0:49e:719e:e215 with SMTP id 5b1f17b1804b1-49e7a68c8f7mr100216985e9.26.1789495218533; Tue, 15 Sep 2026 11:00:18 -0700 (PDT) Message-ID: Date: Tue, 15 Sep 2026 20:00:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH Linux v2 7/7] xen: Add new Xen pv-op pte_get_and_clear. To: Kevin Lampis Cc: "teddy.astie@vates.tech" , Juergen Gross , Andrew Cooper , "xen-devel@lists.xenproject.org" References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-8-kevin.lampis@citrix.com> Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1789495219-24D1E2A1-1A42173F/0/0 X-purgate-type: clean X-purgate-size: 1252 On 15.09.2026 19:42, Kevin Lampis wrote: >>> --- a/arch/x86/include/asm/pgtable.h >>> +++ b/arch/x86/include/asm/pgtable.h >>> @@ -58,6 +58,7 @@ extern pmdval_t early_pmd_flags; >>>   #include >>>   #else  /* !CONFIG_PARAVIRT_XXL */ >>>   #define set_pte(ptep, pte)           native_set_pte(ptep, pte) >>> +#define pte_get_and_clear(ptep)      native_ptep_get_and_clear(ptep) >>>   >>>   #define set_pte_atomic(ptep, pte)                                    \ >>>         native_set_pte_atomic(ptep, pte) >>> @@ -1243,7 +1244,7 @@ bool ptep_clear_flush_young(struct vm_area_struct *vma, >>>   static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr, >>>                                        pte_t *ptep) >>>   { >>> -     pte_t pte = native_ptep_get_and_clear(ptep); >>> ++    pte_t pte = pte_get_and_clear(ptep); >> >> This looks like a typo, on a path you didn't compile. > > I don't understand what you mean here. There's a stray + at the start of the line (apart from the one that indicates the inserted line). I think that's what Andrew has tried to point out. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 15 19:18:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 19:18:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422055.1647639 (Exim 4.92) (envelope-from ) id 1x6Yfp-0001xy-Eo; Tue, 15 Sep 2026 19:18:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422055.1647639; Tue, 15 Sep 2026 19:18:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Yfp-0001xr-AO; Tue, 15 Sep 2026 19:18:33 +0000 Received: by outflank-mailman (input) for mailman id 1422055; Tue, 15 Sep 2026 19:18:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Yfn-0001xh-Hf for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 19:18:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Yfi-00DBEC-Mp for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 21:18:26 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa999ed-e002-0a2a0a5209dd-0a2a450ab7e2-8 for ; Tue, 15 Sep 2026 21:18:26 +0200 Received: from [52.101.62.6] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa99a01-f2d2-0a2a450a0019-34653e06eafb-3 for ; Tue, 15 Sep 2026 21:18:26 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by LV4PPF3BC8B6302.namprd03.prod.outlook.com (2603:10b6:40f:fc02::20a) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.11; Tue, 15 Sep 2026 19:18:21 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%3]) with mapi id 15.21.0406.007; Tue, 15 Sep 2026 19:18:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yM2FTaVxTtzS4/pZXivfmJjDOj2lXgJr4uUyk2bIRETM9FGofG+GZ6qNs2k22tSpu69o77S8AWmoZep5dt5F9dGxYogOw4lg5tHMoPqAzlTjWBIUu1iCKmg5WE2B+mV8elOKWLfGlzbUKUWkO0xmVaIViw2uvA0iIPOeWUsC87keTYuFmaZ6RgOS2wm5eQQSXSJCdBPqyguVcuyrLGKbR0mvG57OqEUKNnIhZTOQoZxghVK3F9OqEZIBP7CunloO+d+5nfuP61w8y/P/n6J48sEWxqf0eZmqxZJfagqHK2SpHgJBQ6UpU/AOYKXHXr4UcyS5D0wmSwlV8FuR5Vn3Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9EEmnDY2RvtYHr/tatAELGHNf+vce1RQws0XaHh4hcg=; b=nutDMDSOKSlef94W/PY6nJwnY5Zmk2M+dZlxEj0VMamgexjq+DWgsTtQyM0qvUGxz80alWYxUA4JtnZmo5f5Suy01cXtow/76tgJ5NP6dwcTYkpEf+RjmGaXY7YW5p52RLepP/y0XgVWPqCpOmuwjRXZV3OubJ3rQBGG8D4lB9YGygHs0ykdCc4bKTIJQ6tqszInUWzjHSk3ocu0kYO817LLswTXJgeydUj2B71DgXbBot7rWQouQhiDCI/EyDQYjj65Vt2Rl0vcnqK9jhR2bXBP7OjR6YzDIrkvk5OdjoCJSDP1hqzquEgprDZsZ3e/C4xauEQjJZWV59DmDc8T/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9EEmnDY2RvtYHr/tatAELGHNf+vce1RQws0XaHh4hcg=; b=LnI2LoiATmOiKcILdVYRlZdS4UrWWK8NK8R6//oU+2AHlddVZ175CsRfUGdbv5FRRx/l/QXF6C9pxjvFfmYZYPhtSReEM0VtMzIJ1gRsYCMHT/GLx8DSjnnaWTP/2ukf+13MdAnuvSGH2qLkt5ytAc0EdT47uRSCodFIUc/L1rQ= From: Kevin Lampis To: Jan Beulich CC: "teddy.astie@vates.tech" , Juergen Gross , Andrew Cooper , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH Linux v2 7/7] xen: Add new Xen pv-op pte_get_and_clear. Thread-Topic: [PATCH Linux v2 7/7] xen: Add new Xen pv-op pte_get_and_clear. Thread-Index: AQHdQWMkTXxtUlg8hk+HuEHbfTb847bJVMcAgAaZYsuAAAcwAIAAFYQS Date: Tue, 15 Sep 2026 19:18:21 +0000 Message-ID: References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-8-kevin.lampis@citrix.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY1PR03MB7996:EE_|LV4PPF3BC8B6302:EE_ x-ms-office365-filtering-correlation-id: b1063f69-9f11-44c9-5488-08df135e1b60 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|22082099003|10067099003|18002099003|4143699003|11063799006|56012099006|38070700021; x-microsoft-antispam-message-info: ff1nODmWyPzcI4ctkhjqfXaGumbH3Jbm6vpeothZ/pjuOTtRTkLj1UvUmEtUmU6gLxLl/Ko7JGE2r19pg2Pel3VFAFmfK8ZpBMcYS5WRn1IKqBu0k6SotVxVHW0UVkkPkl1Ob1WgK9RGJidxNyRNeeN7IZ4BdMwQNxMldE66I181amr/8IPU2Rum/8VeoiFdYU5DCGQ4KqGzUTvggNqCiV/xsXTCm26njQDaRA8DOqWH8XDGWJyna4N3QkVT00zQFzrn7WRJ5or1kmIbXgjNPwTFJV0vRRh6NauTv4ItgOuFvwetZ0DSlFtIdTCUXA2VVpIPiVitpmnr05ZUPaJOhLe3csFAeVzABqfdHOEXbia9hcrdDR5/Cm9UyOcnngPR44AZg/5VBi3iMxg/e58FFTkcMAfp3EsxLZRW2TU4zxJx/8ZBuuJbQmtT5dh+2OBcRIduqDNuOspvxWZxviT0RLSr6s7wJFg070/TFeKzk0vB4+YOPflJv3/KOGE6qcnu/CFkE0IgPHSeDZpueXDFy+xnrC2erBkMHLO3gcpAKc3+FP8pK/FAgnBjJrbeJer7nDcH2//3qDXt1KeXz5swPtDyBYuXwak3VcCTCECj5kUOktqus/uxCk7FGvHX8znhxNwdKv2uma67dKBtJMNm3sDrPmyCQ8NBGB5aIPB9z+aXQONVpfZlcDsOfVJ9SRi8RDRXG2PZSEtcD1XpGlITBqu6dyzuB0zigy9nj0ikIeE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(22082099003)(10067099003)(18002099003)(4143699003)(11063799006)(56012099006)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?3dCKJfYa3BW2fpm/z5ikYXMD1/M8laN3o+FEd0Y7MfN/YX/+hv2zyY9jm0?= =?iso-8859-1?Q?k0fpKBbfoTsZfbP2Xnee+uYvDa2o9XpxV3uHqCAp7h0RDwZoyEr22siVdk?= =?iso-8859-1?Q?OPiFw4/dFhla4JmqGI9/RX7GZHmOy2UPanL/EChywrrRmCQmaBZOqcgdny?= =?iso-8859-1?Q?uA/qhjlYu/NVqQ5oGHIj+nGfa1AMS83ZU9M5MXv5bluXwTDCVQL4ItZ7Hb?= =?iso-8859-1?Q?o+QAokIRP6SKwPz2KDTB5qQIBZbtg8NFWW5/snD4gR/f4u979M5gdiG9B4?= =?iso-8859-1?Q?svDkVCkWuWRq5lmWGcnacfTkRVm3uvOuf0W6OOJulVQ43LTgxvbaGDVlvX?= =?iso-8859-1?Q?qALGC6pjMQwIMm7dh/qzW/WmaIguWl7+Pn+VbpJVQCwaVhMbOsB2l/Uizh?= =?iso-8859-1?Q?iDnOqknCcqbdyo7NjRRzWYQ6frX38FfkDizKC/i1cO+28DfQouce/hcJ7E?= =?iso-8859-1?Q?U9sKkGYqs/t0JnjRUVq8wBLoj40y01M1TLL8Ahk7lpzBdbdrEoNLWq4242?= =?iso-8859-1?Q?EUZHaHVkWAc/dUI4WKk/by07F8i/Ve+yQueQhAbZnqs2rbqscp/2I2N9GH?= =?iso-8859-1?Q?pjzTRa606lnj5ArUBFqchJfpsHyC5zkLh9inGEHqJ6tJW5abxWuBncsLVL?= =?iso-8859-1?Q?qM92lE9da9kswyW50f3MaecOTmLhi+rC40Ac0M+81QX/ebYLy5+VKdVD8l?= =?iso-8859-1?Q?1hpeag/p5dCmKdyr9X22XiWCIisYyjux5tS0+URKg2bocE8dNP7xKFJu22?= =?iso-8859-1?Q?Z/83EK2QU8K+voKVlCxuiJtNeZw7D4vhXG7bw0u0PJ7fJNSYcJ/yVHRJcu?= =?iso-8859-1?Q?yeKYtOQoBZC5/r061glXGulPsIVEkmsauoaClguw5D2AjU0nFVwrNdvLRB?= =?iso-8859-1?Q?HWm9xkcIdRGlEDdCNv7xdF17+nJ0gwWae7GagcX7JTzw4XShEqejSRlloz?= =?iso-8859-1?Q?FJE+IAWt7Jk5r32QjSYIgesCtWeV1hqvnU50VJ+mznfbO8c+E0pmYoUk8V?= =?iso-8859-1?Q?jD1XYI2QlO2nT/D93LiSjnnRSsfRDFLT6sHSAvSzd++M+M/sqy55ZcFBnY?= =?iso-8859-1?Q?e8IzKcaW7EqZiPsf4mgqDMlkBkvq3qPjRTfV6JQdvKJ/qDoexvzlsZF1JH?= =?iso-8859-1?Q?ulS8Ue384PX3y1saqijW/3OKrEgqAMxrlAhgXBDqJmvmUsvVEU9Z3lpDIU?= =?iso-8859-1?Q?lqexr1ThFAq6iQRSd7Ldyct1PUGG2jD/bPz4Ey3KK0vr8+sRgbmzkaf+vt?= =?iso-8859-1?Q?vXBbLvaf+MYMVg28ckr9KNZnsF3icl+U5v4NRYozfUTgUeDRIrKpKGzBy9?= =?iso-8859-1?Q?9xHKYRe+A5KhvpEPWnhdi9Nm1pIv4ut7W35WfXkPOVnMqayAHEmg3N9Qx1?= =?iso-8859-1?Q?CoPwsbfkjVn2BKEqO2iAtPQexGMbKgnkQUff0ajM4b7TRuV86lTyip11we?= =?iso-8859-1?Q?roPFlmSmG3FVBrHp+nbVS/h+ZsXa2PSj/4IrN8LATdQ+CsltwM+FVnIcYp?= =?iso-8859-1?Q?t7/hTFLP7j4MzzjlHZZSXnkKv4aB/k5/2ORNHgeiGy7D37CRv8jV99ho40?= =?iso-8859-1?Q?bwyuwWwAJ3Hm4mtkKpXJfUWzIhCfyIrJ6rDpGnESyxA/h6K/HKvwkidzj8?= =?iso-8859-1?Q?zM5bR0Mgg/USbs8O9lk93SrOrHbgtYKD3tcHHFpVf5PlPTMdnP8pUWhk7K?= =?iso-8859-1?Q?KqQTAN823voQ9U1gb2XVz4ECLwh0k1zyxlWV1MOjqAhiDk+1SEMzr3ZumW?= =?iso-8859-1?Q?PaBHuRFNF/apTcRUPrdLw2k6voXJKAJ8upJcEZ+P8+ZPrb?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b1063f69-9f11-44c9-5488-08df135e1b60 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2026 19:18:21.6748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: L+kZDZh0p9vV7T9hbHTUtDQh7wT2CbsgRjUMRUH9rPnjKuChJv0lrwRUeVgWiMm5LoMzyh26wtvN7ud1WBchjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV4PPF3BC8B6302 X-purgate-ID: tlsNG-4011c0/1789499906-4ACDBCFC-E720D5AA/0/0 X-purgate-type: clean X-purgate-size: 241 >There's a stray + at the start of the line (apart from the one that=0A= >indicates the inserted line). I think that's what Andrew has tried=0A= >to point out.=0A= =0A= Thank you. I don't know how that happened I will be more careful.= From xen-devel-bounces@lists.xenproject.org Tue Sep 15 19:37:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 19:37:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422064.1647647 (Exim 4.92) (envelope-from ) id 1x6YyH-0004g0-SR; Tue, 15 Sep 2026 19:37:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422064.1647647; Tue, 15 Sep 2026 19:37:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6YyH-0004ft-PT; Tue, 15 Sep 2026 19:37:37 +0000 Received: by outflank-mailman (input) for mailman id 1422064; Tue, 15 Sep 2026 19:37:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6YyG-0004fk-1y for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 19:37:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6YyF-0085N2-6r for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 21:37:35 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa99e52-2eae-0a2a0a5409dd-0a2a4503b550-26 for ; Tue, 15 Sep 2026 21:37:35 +0200 Received: from [40.107.208.45] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa99e7a-fae8-0a2a45030019-286bd02d6955-3 for ; Tue, 15 Sep 2026 21:37:34 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by PH8PR03MB7308.namprd03.prod.outlook.com (2603:10b6:510:254::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Tue, 15 Sep 2026 19:37:25 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%3]) with mapi id 15.21.0406.007; Tue, 15 Sep 2026 19:37:25 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NbSYQXNOIULcFVUMqtGecV97BIAlT9UUghOCZb22RDDBIbf2KabehI1gLUD2zpdr2/jmBuB4LyuehKUfRCxDxTL9PbO75kFpAo2IwgKzxTublF2L59e7z54XG+A7vwmQm3CfzBFPtbyV+EvVkJMecnMu9VOik1a+lYkFzDMx1/hIce9uSOKZm+mVbmbf8cCx+1R2ArYAbtOvOpUpEja+ZXpJOnFLg/hqOX20nhl7nimwczpWtiY555KnAClcqXyPjpkBs3s6+L2agKMuVN+QgO8d8dSbdZkHCjJLS4jhr1QNHE7x73/tEgJb78T7aBDXf6AD43fFE85xgAWzmv2yPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Jge8zOljOUYlG2uCmO5vY/sOGSjD131OalvqMCXWsDk=; b=ldvONQiHCDKFm/ZSEZ7txEAY+5lBCM2VFoJV3tIg+MvWUoZkEYa92d2Dr61940F3d2UwuGqXU3M+y2VS5kqkGSkzOilEX5e6uio0//YAiAzWnNNmQ8XMZNLS61S1BD9nQQuZBdqxJt5lKxyfb2FHhzOLF3y5teUO0V/k77BlaPgLwbTqJlvsG+YK9JpWBKbMCe4i2Lv9jFcQ3WKvFVD63b7AxonFVuxdQRvaBeQEndj+HCg0dnONjcJoQEp8mkh0ThEhP9fGh1uY7aXsFHyLypFVK3rElCQjFuBxYa4SO/pTJHConlMNygA8hQ4wZE/NmzDUCL8LLF91aq6Mi7BrYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jge8zOljOUYlG2uCmO5vY/sOGSjD131OalvqMCXWsDk=; b=VnwAK5ezpraYiKLLyh1g39IOZOgWGQ+Q71WV1fQu7n1KSTfpT+8HSEYBiuJd49hWiTLPCFwruDxMo9o/Gf/MS6lDIYTq2aqP66OAu9kOrU7xVjOLTPobonRvNGHKrgBzEjVXYsoDjutMoSuorRMBR/h7EFYZOFp+mhTL19ghC7s= From: Kevin Lampis To: Andrew Cooper , "xen-devel@lists.xenproject.org" CC: "jbeulich@suse.com" , "teddy.astie@vates.tech" Subject: Re: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update Thread-Topic: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update Thread-Index: AQHdQWMYYuOEW7sUTEmdu2MmKUu4LbbJV30AgAaz+PY= Date: Tue, 15 Sep 2026 19:37:25 +0000 Message-ID: References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-4-kevin.lampis@citrix.com> <0aedfbad-29ae-4083-89b4-5c662398553d@citrix.com> In-Reply-To: <0aedfbad-29ae-4083-89b4-5c662398553d@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY1PR03MB7996:EE_|PH8PR03MB7308:EE_ x-ms-office365-filtering-correlation-id: 3aab7f18-af14-4a8c-5601-08df1360c4e4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|4143699003|18002099003|22082099003|56012099006|38070700021|10067099003|11063799006; x-microsoft-antispam-message-info: 4nuJVfJ1+CmQn+BeEihvC5HWcP+sZo6/QlkZPeJg9RqjcAHgidwQxAYnSQoOKppPu9kuqNqBqB/WkMI4heBRqgsgVj6YQwhOgcZfIOL9LN5tvagzH4q9HVjFaFFMXEI1U6E72lqtbEAo/cNyVTJR8MCkPfHxc82ocCjayrSdNmgCWe5wy5w66Xgs682osnyteR++lrw3+PhrrmrxhiIPRafE3aSqQdP20B2igMqqPH7YUGfgaDHgg4+Ciz59wX57zdsVWiTX4o1w+w5FBF0AShEWu1H0ht5NuHtxLRH1qa4c0W+pp9WQAmoALRs5GpKvKFjdhOHN2rN2FTZoLO1VsV9ek5952OJS5RXwI0CRJByQYi0+xVbMh3nHnhp9cXQsQArchsrGfK7+lFEp2plLvQ86BHsaC06AD5eZlj04Y2tnCz5wDuKbyV64D5Dldbsd1U14460MU4ZCyeYgTATBAIoCeor46n6yr9VyQfKg9IVuHEuMW0keKYL3SAY19xFo0qfuDYiRFpoGhawauhWolSy9+fdKFfCnI4NYoq7OfIIPvKfOneo+mZglMf9qrzIFVx7Pv+fOLGr0ox9AjQ27kpxyRNynHpDTKqRyRmobH384EBbypezdApPX19kz8XTXFHuHamiEKFXKGWmV7BUOjj5jcilNI4AkODhUoXuDbYcYQvpsG+ff+OG1AIDf+cPG9SQ4IdP/inFYV0kb11Ycscz6BebHfXdk4AWlUzmK7v8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(4143699003)(18002099003)(22082099003)(56012099006)(38070700021)(10067099003)(11063799006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?APXHXS7OuQDMX6X27aplWPt1hfU/mbNY+IkDPMFxFRItTy05WOpb/ybcVB?= =?iso-8859-1?Q?EzSqIJ9NmBHiO4Ci56on8O3yLb7GodIT17SaNx/Ev2sw4speug+6XIpf4T?= =?iso-8859-1?Q?ifV7FdMUVpFFbLJa+bJkZ/a/Z2p6zWNnUZagnSpOQ3B0GivXtyrBhYNeVM?= =?iso-8859-1?Q?M6SQ9KZBtu3uuS9dIOPPi4BUGC7nRGqTBuE8ilaMP/iX78/mK0N8ozaje4?= =?iso-8859-1?Q?IS7rbJjWerMCKFz1RAyW0GvvfRpz9rJ/u2iPSRh7j20v6/giZitFDuGvQR?= =?iso-8859-1?Q?eGZQN0UaxedUMgj39HGK8rKBOaWfaO3TOq5kGOT4Q2lMmReH/Ap20n46wF?= =?iso-8859-1?Q?wyUdIVIa7N+m/KG4qKusi11cMOzlcbu3Zm32uA/6ivIieSwkiFUJMnJV7J?= =?iso-8859-1?Q?erPevi1d7PED4hEUWkLlOUA9tRZ4eT/RgeUF2fmudy9Dp4Cs9xMRYX1p0Z?= =?iso-8859-1?Q?Mm5i20DTEJHnDkyGVuj8apq6ZAjeAYvJOhOn/LTdRd6AdtCSAitlLsDTSc?= =?iso-8859-1?Q?m75tmMwwQvlw919UFRX/r8Ug3gnlj4J4BwMi1lDWk0jJensBDI90awrUrg?= =?iso-8859-1?Q?jgj0pG9idfZ4GNSCHkhjTcOgYWMcdnPEJHrQFR945C99EpOutN7EfY+uf+?= =?iso-8859-1?Q?1bN68wE/jCzpn8f+bXwnkjC03AwLrdLlXq+E5HH4cOq1wFUnMmOmASUfGJ?= =?iso-8859-1?Q?39FcCx1FK+2bTUsBrEB9yuYq1dS9dTmnukGXi4JjKTbqGMitNcwDtzTdep?= =?iso-8859-1?Q?9fNSEOP3S9aQYe52o6SpvJSoe09tXZt5SPGkKwTgEoIs8qMgupeQc12Clt?= =?iso-8859-1?Q?s6cL1VUFlE7jtk6uxxqyPUWmv83r1xWTS3AB6qys/z0MIM4oIq+wp3y4e+?= =?iso-8859-1?Q?keA/aTYmemmiSyNvLFTu6k5/8fUVBoSB8Gyrs2aK+DAapsKmRMMKdw/PUR?= =?iso-8859-1?Q?PlGHaN6EIfeeEPXeJXbRLIByr6b0R34I/WeD5F+BcUQwpK3qLjNxhVketz?= =?iso-8859-1?Q?yRkBwK4z8EBm1nkum9OqH7Bwj8kUeo4oh9ofboe5BJQe8gglT1nE9Fscou?= =?iso-8859-1?Q?KRB1CElQrg9x3245eErPI1RX0npESvAgBLiyo1qxZuGvRdTOOdSzBjs3UU?= =?iso-8859-1?Q?gpPtae/cJeTk2JnDf/erjWK5Rw13N43Ig8rHtbaV+4C+P7Vq6ipOdPMPIn?= =?iso-8859-1?Q?mcClUtboXqza986tQWF9BtKkVKYbMQO+uijGZ0IyKTdT5IdHMZGqxOXYV0?= =?iso-8859-1?Q?tZIzN30xM0Ry5D5IiXEJSgM71nl5WzZO+CiZslwH8hIi058LDDMcOHWtSv?= =?iso-8859-1?Q?zucwzZRVXbt06EoFlvY5HexL36MWqaWLVBCmf5LmsfVBmiVtUUmf7wUR7d?= =?iso-8859-1?Q?C9+JWtPE1HgR6VVYoGQdRveAC4QGkM1pRQrQECCRmisnCJ81OsgFV2RpRH?= =?iso-8859-1?Q?So92a2n0LLqnSrnMCsoAh8NUThK+fOQc1kta0z8fp3P3yYjqlwXPSqCaK/?= =?iso-8859-1?Q?5YJVm63oIn+t4PAoBodm30Juqdx4ehYc26Sl3gvX/n7AgirKARds3/IS+t?= =?iso-8859-1?Q?yAzTi0OCK2k5yNWpfFw0+enQuaF0mEAnG21HRgBeYMSErmFdqVxUuwpUQs?= =?iso-8859-1?Q?XZEa7aiJkXYfX1dR8thAjLIEyP8G4Duhsg/eO3CRp+0R9f3POYeJ0+WgVa?= =?iso-8859-1?Q?VpV975eCdyEsP6Ip87Z9eVpFWTl3N8C7uFKGOW2op4WrNIv2RRvImyvcgU?= =?iso-8859-1?Q?q0kvPXo/oHxCrR/12OYEXIX2jq6X2VcAeiHwlhtc/jH9gp?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3aab7f18-af14-4a8c-5601-08df1360c4e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2026 19:37:25.0821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Wjnlfgowln6qNV1PKEbGZAjK1EooXWJQhSEgWceJnVYHrgOQ5RicjGMNd/+k+OorQ4To5eQn8wiedjaAGX7B8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR03MB7308 X-purgate-ID: tlsNG-33051d/1789501055-6DED24E9-1155097C/0/0 X-purgate-type: clean X-purgate-size: 1255 >This seems unwise. I think you want a return 0 in the=0A= >paging_write_guest_entry() case because returning the input cannot=0A= >possibly lead to anything good.=0A= =0A= This would make the calling code in mod_l1_entry() more complicated.=0A= =0A= At the moment it shakes out like this=0A= static int mod_l1_entry(l1_pgentry_t *pl1e,=0A= ...,=0A= l1_pgentry_t *ol1e_out)=0A= {=0A= l1_pgentry_t ol1e =3D l1e_read(pl1e);=0A= ...=0A= ol1e =3D UPDATE_ENTRY(l1, pl1e, ol1e, ...);=0A= ...=0A= put_page_from_l1e(ol1e, pt_dom);=0A= ...=0A= if ( ol1e_out )=0A= *ol1e_out =3D ol1e;=0A= }=0A= =0A= But if UPDATE_ENTRY() sometimes returns 0 depending on what internal path i= t=0A= takes then we'll need two local ol1e variables, one that is always valid to= =0A= give to put_page_from_l1e() and a different one to maybe assign to *ol1e_ou= t.=0A= =0A= When you say "returning the input cannot possibly lead to anything good", t= he=0A= current version of this patch series actually depends on it.=0A= =0A= I guess I just wanted to clarify before adding more complexity to mod_l1_en= try.=0A= From xen-devel-bounces@lists.xenproject.org Tue Sep 15 20:30:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 20:30:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422085.1647656 (Exim 4.92) (envelope-from ) id 1x6Zms-00030h-IX; Tue, 15 Sep 2026 20:29:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422085.1647656; Tue, 15 Sep 2026 20:29:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Zms-00030a-FZ; Tue, 15 Sep 2026 20:29:54 +0000 Received: by outflank-mailman (input) for mailman id 1422085; Tue, 15 Sep 2026 20:29:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Zmq-00030U-5c for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 20:29:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Zmn-003bMQ-TI for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 22:29:49 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9aaa7-bab6-0a2a0a5309dd-0a2a4507ab20-14 for ; Tue, 15 Sep 2026 22:29:49 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9aabd-b4ea-0a2a45070019-b9ff1c12a9c7-3 for ; Tue, 15 Sep 2026 22:29:49 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0a6c2e2a000072c4.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 15 Sep 2026 20:29:44 +0000 Received: from [172.20.10.2] (155.89.66.37.rev.sfr.net [37.66.89.155]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id E4D3681FCC; Tue, 15 Sep 2026 22:29:43 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=9vXBUfxgjPFp3KmZ37GOIdI1MCaV70rvftemLG1fgbY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=X1nw4nOoqDObMXjk3AvMkJOGYInTC/bvukQR/YDkj8iszXYF3HoPe09fhN9A97zOWMNK76B0K 3YKfdJRoa2ntGTU5Y6c4OK5QRdLrTBp6axatLXGnMFHN+2UixfNYTq1U/86z/4imucXELwjOPRK BevCOGnkGpFuTOpqcicb6HDTFimNOjLcIT40/FtBD6mtpv5i9mm0WvSddlqSf635ddl92iC2/H2 DqxuBLlJZu9zzRlMdrnkCw6RTLfEOcFBC7xJ3l6y6zNvRGwaMaNrG1Eho3rX1hGlr40NkjWP9as yn0Qg90aaZ28rGHCjw9lo1RbsYHfVdfsPPZBRS6fiZFg== X-Zone-Loop: 15c720a56699ee382656ff14473537110d73d1d216b4 x-campaign-type: default x-transaction-id: 98e19032-3a67-4cc8-a3dc-0bc06e6ad841 x-swg-uid: 01-00f0ce25-2e75-42d4-bd56-72852f229583 X-Mailer: Sweego Message-ID: <1789504185.8631fc262581453bbf619ec5b2062170.1a0a6c2e2a000072c4@vates.tech> x-swg-bid: 1789504185.8631fc262581453bbf619ec5b2062170.1a0a6c2e2a000072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Tue, 15 Sep 2026 22:29:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 6/6] CI: run the riscv64 smoke test via QTB framework console-test To: xen-devel@lists.xenproject.org Cc: Doug Goldstein , Stefano Stabellini , zhangzheng@iscas.ac.cn, alejandro.garciavallejo@amd.com References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <20260827094301.338069-6-baptiste.le-duc@vates.tech> From: Baptiste Le Duc Content-Language: en-US Autocrypt: addr=baptiste.le-duc@vates.tech; keydata= xsBNBGoPSX8BCADSuTikqW3FD4mscQugY1thRaKlIhcJ2G9YCWYXAlp+xosvTlzfIftOZZim 750MLvyKtLPkQzB6TZtFZBiexSraaF/MdDKRTT5DcVa3r7ZnHgqMclWlPa4ioysS4yFcJanL cyNOT7HUFvIdirMMqiViedfYtS0GORPBBPVISD6ClMz3ecHIxqllfq9CHYQn4amKEfHmh6tm Rufo4Gjl6x8cUFZZlRQf+aCmUzdSPA0P5u3sueYH1uEz4w/jbD53MlKqzCvxUeOsfS2swTQA 6mS9jIgOjNadpUTOzKfDHMgFirtG+HFpm45Nwp6KQizxgDVOfTnOfVHm5Gwqm3ETl9y5ABEB AAHNPEJhcHRpc3RlIExlIER1YyAoVmF0ZXMgWXViaWtleSkgPGJhcHRpc3RlLmxlLWR1Y0B2 YXRlcy50ZWNoPsLAjgQTAQoAOBYhBGiSJ6HgW88MgT/gfu2Cu2XL9M6QBQJqD0l/AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO2Cu2XL9M6QuMcH/ihiy/Nrxp919AmY0ENnc0NK r/2LDvW/hrX4FfbpxAmrGmQ7MU1aQTk0JDbfcsG8OYH6wO5sqnXb1gz50YrEdpfVSbHz5YTZ EhDIxE4g7NrvJZh3Qc0m0CAyjYTNHen7J6olVaCMjrOH7uRHUYZ7Pl3am9mZosfLmez/aWJO a6ihQxBXHI75brlk1teIURkep2kP7P0Flmfl4cA//saREoTF7GXCtjOSQk/xg8PP0Sswqp5G TdJptn3FQn6lAzfz0eFSYqkaoX2c2k1MDa7o+UX9cfGPL8ybMKnYkasLxck6eOWGJWf+YTrm ga/r0kBaftmqNDgt5nI2jNTDwZcT9g3OwE0Eag9JfwEIAM6IWbuBSvz+erv27oGDDpo8M6Fp dGUvft7v+WceHUfxiXpYFx9qgIU6XGy6y+3lJMAvNcltS8DuhioqMlfKRSYGKZlpliY65dNP 557IuM4ctVJ+I9CVclvv9eahARQKgF5auLJAAlvGSmU+ufNvlwTUmLIRcrPviTmB6X5jJYc+ fiNeyI0HcsgcN21C0r62tUCypuZ+vgEJXw2bx1V8mVGZKxdGJPh58QF6kRK+xmd4kEComLGV BeM6BcVOtEjDcGNC0tLhXb0p9g1Ys55iA8sd6s4WacyolW2J6rwmcOkjiWexWw1caYgIWAV1 004M3gwUaOz0dGq2i7HQ0AiVfVkAEQEAAcLAdgQYAQoAIBYhBGiSJ6HgW88MgT/gfu2Cu2XL 9M6QBQJqD0l/AhsMAAoJEO2Cu2XL9M6QovYH/RjstyL5o/V5K74ylBtz0j5t3pLX5JKbwApi 656rGgDdqElImyvvZppNMl/mgHNzvxmfFAhJXnSX9f1fqVEQKOGEhLUastnl/ssBiE5x7btM V0GAffxXbXJZbVv4b/DI+gVrOPc2YXlVwruapvTZNtD3hqPrkjrmq5WTtGR2loIVSe62hmh0 BGD2Fy79b/hYWyBqhayPBEjwGW75u4/yn+Yqy1PgG3hIcvg7GSuT3akhHZSB2Mbguzcoyf9Q DJl6t33JxPRkkNrEdkPPmRlQCTSiUkVjKqMDF3jlINWsJ5t4jKFsNF91ksdw7aQgiX+tQIpE ugMC1NuNi5dDGip66bw= In-Reply-To: <20260827094301.338069-6-baptiste.le-duc@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789504184416 X-purgate-ID: tlsNG-ef75cf/1789504189-A50CDAE4-0D15E59F/0/0 X-purgate-type: clean X-purgate-size: 4441 Ping On 8/27/26 11:43 AM, Baptiste Le Duc wrote: > qemu-smoke-riscv64-gcc drove QEMU through > automation/scripts/qemu-smoke-riscv64.sh, an expect wrapper whose machine > description (cpus, memory, device tree, console wiring) lived in the script > itself. The QTB framework now owns all of that: machines come from the > shared catalog, expectations from the test type's own YAML. > > Turn .qemu-riscv64 into a template running qemu_smoke_riscv64.py run > in the qtb-riscv64 container, machine and test picked per job > through QTB_TEST_TYPE/QTB_TEST. The container comes from the test-artifacts > registry, hence the new ARTIFACTS_REGISTRY next to the existing > ARTIFACTS_REPO/ARTIFACTS_BRANCH. QTB_BINARIES_DIR points at the artifacts > of the job (Xen only currently, but aims to have initrd and linux images > when dom0less will be supported). QTB_LOG_DIR collects the per-console > logs, kept on failure and on success. > > Point qemu-smoke-riscv64-gcc at that template, running the console-test > type on dom0less-1smp-0domu-1vcpu-aplic-imsic-null: a Xen-only machine, so > the smoke check is Xen's own "All set up" on console 0, the same string the > expect script waited for. > > Drop automation/scripts/qemu-smoke-riscv64.sh as it has no caller left in > the CI after this patch and drop smoke.serial from the .qemu-riscv64 > artifacts since no riscv64 job uses it anymore, the logs are now kept under > QTB_LOG_DIR. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > .gitlab-ci.yml | 3 +++ > automation/gitlab-ci/test.yaml | 20 ++++++++++++++------ > automation/scripts/qemu-smoke-riscv64.sh | 19 ------------------- > 3 files changed, 17 insertions(+), 25 deletions(-) > delete mode 100755 automation/scripts/qemu-smoke-riscv64.sh > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index f42a9abeaa..15f93b8634 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -11,6 +11,9 @@ variables: > ARTIFACTS_BRANCH: > description: "Branch in test-artifacts to use" > value: master > + ARTIFACTS_REGISTRY: > + description: "Registry holding the test-artifacts containers" > + value: registry.gitlab.com/xen-project/hardware/test-artifacts > LINUX_JOB_X86_64: > description: "Job name in test-artifacts to use for Linux x86_64" > value: linux-6.6.56-x86_64 > diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml > index 61adc1baff..e9dd147380 100644 > --- a/automation/gitlab-ci/test.yaml > +++ b/automation/gitlab-ci/test.yaml > @@ -72,14 +72,21 @@ > TEST_TIMEOUT_OVERRIDE: 120 > > .qemu-riscv64: > + image: ${ARTIFACTS_REGISTRY}/${CONTAINER} > extends: .test-jobs-common > variables: > - CONTAINER: debian:13-riscv64 > - LOGFILE: qemu-smoke-riscv64.log > + CONTAINER: debian:13-qtb-riscv64 > + QTB_LOG_DIR: qtb-logs > + QTB_BINARIES_DIR: ${CI_PROJECT_DIR}/binaries > + script: > + - ./automation/scripts/qemu_smoke_riscv64.py > + ${QTB_TEST_TYPE} > + run > + ${QTB_TEST} > + --log-dir ${QTB_LOG_DIR} > artifacts: > paths: > - - smoke.serial > - - '*.log' > + - ${QTB_LOG_DIR} > when: always > tags: > - x86_64 > @@ -779,8 +786,9 @@ qemu-xtf-argo-x86_64-gcc-debug: > > qemu-smoke-riscv64-gcc: > extends: .qemu-riscv64 > - script: > - - ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee ${LOGFILE} > + variables: > + QTB_TEST_TYPE: console-test > + QTB_TEST: dom0less-1smp-0domu-1vcpu-aplic-imsic-null > needs: > - debian-13-riscv64-gcc-debug > > diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh > deleted file mode 100755 > index c0b1082a08..0000000000 > --- a/automation/scripts/qemu-smoke-riscv64.sh > +++ /dev/null > @@ -1,19 +0,0 @@ > -#!/bin/bash > - > -set -ex -o pipefail > - > -# Run the test > -rm -f smoke.serial > - > -export TEST_CMD="qemu-system-riscv64 \ > - -M virt,aia=aplic-imsic \ > - -cpu rv64,svpbmt=on \ > - -smp 1 \ > - -nographic \ > - -m 2g \ > - -kernel binaries/xen" > - > -export TEST_LOG="smoke.serial" > -export PASSED="All set up" > - > -./automation/scripts/console.exp |& sed 's/\r\+$//' From xen-devel-bounces@lists.xenproject.org Tue Sep 15 23:50:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 23:50:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422142.1647677 (Exim 4.92) (envelope-from ) id 1x6cua-0002Da-6i; Tue, 15 Sep 2026 23:50:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422142.1647677; Tue, 15 Sep 2026 23:50:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6cua-0002Cu-37; Tue, 15 Sep 2026 23:50:04 +0000 Received: by outflank-mailman (input) for mailman id 1422142; Tue, 15 Sep 2026 23:50:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6cuW-0001ig-4j for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 23:50:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6cuV-008U2Q-0r for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 01:49:59 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9d967-bab6-0a2a0a5309dd-0a2a45059fc2-14 for ; Wed, 16 Sep 2026 01:49:57 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9d9a3-4cb1-0a2a45050019-d561b33880d4-3 for ; Wed, 16 Sep 2026 01:49:55 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x6cu2-002gmb-8v; Wed, 16 Sep 2026 01:49:30 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x6cu0-00859I-Rj; Wed, 16 Sep 2026 01:49:29 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x6cu0-000000029fQ-3n0E; Wed, 16 Sep 2026 01:49:28 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=I8JTmEd44ay2XHHFYotn7CWkmIwj8DNipARBUw7yAXk=; b=M5pUMVLaNCzsLx5LTcydsMeZCN s9AKwvruPECFpPUZF4Sj2JVpUooGQ9sb6+TTIpRZXO6oO/v1ub8GxAeHJPKC42fex+gVpEMu2lwig DycdC3uIwtmjH+AtyZq9UWde5aWNzst+87vcnj5+9wHX+ef6nMXxlRy8K84AFi1vDkmyEpz0eG2nf WYzXWsJ3YK5GVMm9b1DbN14cIno1b42gBgBArBSr50KWsu2lCLz/mvB/qHbfbTSEFTQfRhpKef1b4 YX9RLKgbecJlt7hBOEASyBl/3+aNSsGiMD7wRMPMChDq24CKPjOtC+P3vy4kKsN5+SuEyL0g15WQq wp50ai2g==; MIME-Version: 1.0 Date: Tue, 15 Sep 2026 20:49:27 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() In-Reply-To: <20260915154853.GAaqlo5YxQ9ALlhjbF@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> <6113f06c790cfe1141d2dc09b68937b6@igalia.com> <20260915051155.GGaqjTm7yIluwxZ80x@fat_crate.local> <20260915154853.GAaqlo5YxQ9ALlhjbF@fat_crate.local> Message-ID: <9086138f2dcaffe30622438b7e825ae7@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-c201ff/1789516197-73CB82A1-20A45973/0/0 X-purgate-type: clean X-purgate-size: 1111 On 2026-09-15 12:48, Borislav Petkov wrote: > On Mon, Sep 14, 2026 at 10:11:55PM -0700, Borislav Petkov wrote: >> Hmm, never heard that before but that doesn't mean anything. Probably should >> mention it in one of the commit messages so that we know for the future... > > My compiler friends are telling me that gcc doesn't do that now but it might > in the future, perhaps. > > -fno-builtin-memcmp > > will stop any of that behavior so if, perhaps, building the pvh code with it > looks better as a solution, we probably could use it. It looks like clang does [1], but according to an LLM that is also disabled with -fno-builtin-memcmp. IMO a fix in the source file is clearer, less obfuscated than in a Makefile (and the source file has to be changed anyway). It also has the potential advantage that, if the Makefile change slips in a future change/refactor, the issue shouldn't reappear. Either way, please let me know and I can certainly change the patch. Thanks, [1] https://github.com/llvm/llvm-project/commit/9473c01e968bc4ecf5ea7c54ef0c84b687d365ea -- Mauricio From xen-devel-bounces@lists.xenproject.org Tue Sep 15 23:56:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 23:56:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422151.1647685 (Exim 4.92) (envelope-from ) id 1x6d0O-0003F4-PZ; Tue, 15 Sep 2026 23:56:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422151.1647685; Tue, 15 Sep 2026 23:56:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6d0O-0003Ex-Ml; Tue, 15 Sep 2026 23:56:04 +0000 Received: by outflank-mailman (input) for mailman id 1422151; Tue, 15 Sep 2026 23:56:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6d0O-0003Er-7R for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 23:56:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6d0L-00Dcwv-GU for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 01:56:01 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9dac9-e002-0a2a0a5209dd-0a2a4507de56-24 for ; Wed, 16 Sep 2026 01:56:00 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9db0f-b4ea-0a2a45070019-d561b338b142-3 for ; Wed, 16 Sep 2026 01:56:00 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x6d02-002gs2-4j; Wed, 16 Sep 2026 01:55:41 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x6d01-0085PP-5B; Wed, 16 Sep 2026 01:55:41 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x6d01-000000029jK-0qGh; Wed, 16 Sep 2026 01:55:40 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=KcruWwdX0V35F0OFmxXzRLw0Nkd32o9ayTCXiOg/3lc=; b=FYTeW+Jse40BtVnGitDFqVV/fa oZNgbPIaWm2VLM7aof8GkquqiOdh+416aGGYzTWdgN7qlYyPdsGzR2/YZOVHZI4ICCGuDixvaU4Nm RnbXya4BrDsCDFRnChHv8nWFooZe8qxElaYBYLr9hK1eHu43YfCMV0hQZhO3tDaZuYd99/W3j0XRE jkWFBVq8G3gqKDXw4ScVxAhHKQVPRA4nl/Q8+LEz7B0CeujEWyVR9wRPMc1+UCm4G0tJNXbElw02z hjgOkRqBE063kOy7EejC80UWwyKCKI47LMCzuYnQjTu3D17U1FcvlbLwhntLa0tmZKOvx59zLl/Qe iUFxAqLg==; MIME-Version: 1.0 Date: Tue, 15 Sep 2026 20:55:40 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 5/5] x86/pvh: fix unbootable VMs by really inlining memset() in xen_prepare_pvh() In-Reply-To: <20260915052646.GIaqjXFkXBkWfvt3tP@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-5-e70ef3b75b6a@igalia.com> <20260911043947.GIaqOGE9DFCHWwc6Ys@fat_crate.local> <20260915052646.GIaqjXFkXBkWfvt3tP@fat_crate.local> Message-ID: <78399f2346182d7de96343c9ede3da6c@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-ef75cf/1789516560-3C610AE4-7CC15D7C/0/0 X-purgate-type: clean X-purgate-size: 960 On 2026-09-15 02:26, Borislav Petkov wrote: > On Mon, Sep 14, 2026 at 08:40:38AM -0300, Mauricio Faria de Oliveira wrote: >> Due to scope and review purposes (4/5 is more generic, 5/5 is specific >> to PVH). If there's a strong preference to combine these, please just >> let me know. > > But they sound like they're fixing the same thing: > > "vmlinux no longer boots with CONFIG_PVH if CONFIG_KASAN_GENERIC is set." > > and this one's commit message: > > "This particular one (still) generated the inline implementation as expected > (at least in these compiler versions)" > > sounds like it is referring to the previous patch. Or I don't know what you > mean with "these compiler versions"? > > Bottom line: if someone needs to apply both to fix unbootable PVH VMs due to > mis-inlining of the compiler, then someone can simply apply one and be done > with it. > > Thx. Sure, I'll combine these. Thanks, -- Mauricio From xen-devel-bounces@lists.xenproject.org Tue Sep 15 23:56:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 15 Sep 2026 23:56:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422159.1647694 (Exim 4.92) (envelope-from ) id 1x6d14-0003iw-1X; Tue, 15 Sep 2026 23:56:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422159.1647694; Tue, 15 Sep 2026 23:56:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6d13-0003ip-VF; Tue, 15 Sep 2026 23:56:45 +0000 Received: by outflank-mailman (input) for mailman id 1422159; Tue, 15 Sep 2026 23:56:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6d12-0003id-Qy for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 23:56:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6d12-000aBT-7s for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 01:56:44 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9db25-bab6-0a2a0a5309dd-0a2a4507ecdc-16 for ; Wed, 16 Sep 2026 01:56:44 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9db3a-b4ea-0a2a45070019-ac6904fed326-3 for ; Wed, 16 Sep 2026 01:56:43 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 06B5E600CB; Tue, 15 Sep 2026 23:56:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A23C91F000FF; Tue, 15 Sep 2026 23:56:41 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 35753CE0996; Tue, 15 Sep 2026 16:56:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789516601; bh=6xg/ezatpUxwFU75bwryxIRlQlQYj6Bzwx0rt5taCFU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=FPSAp2LhPJjFgwTsVcW6Cskc9lLNu8x3L7QknsvOQY7de/kwu2pvu320ieHITiaIl tX8Mt0uVX7PBpcVR5g26r1OPAYM2gNcN6NguN4y5nCaHaWbjlERwKrG6kEC2OBkdno pmtKSJeF7AaRTVO73wh5FiIBTTOHqIowzsVi8HhoqnsSNitOHhssiBUrH+Zw4+s/E3 wzw6PNnqhTWamoqrF3kAuKqYo9MA2dolu5RZtMGl0M9RLxOEvv3y2jAscoeRcgwnmR QGfm60hJMsTbLASoJYb/IX08DpRAzvbrO8PnF6AebqzWxOV1y0OiFuJzB+t0u7oGxg ip8eNRowueeAg== Date: Tue, 15 Sep 2026 16:56:41 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: Reply-To: paulmck@kernel.org References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-ef75cf/1789516604-37AD0AE4-9F9D8835/0/0 X-purgate-type: clean X-purgate-size: 17351 On Tue, Sep 15, 2026 at 05:14:12PM +0200, Frederic Weisbecker wrote: > Le Tue, Sep 15, 2026 at 01:17:30PM +0000, Josef Bacik a crit : > > Tasks RCU waits for every task to pass through a voluntary context > > switch, usermode or idle, because a preempted task might be sitting in a > > trampoline that is about to be freed and nothing marks it as such. With > > PREEMPT_LAZY that is a poor fit for servers: cond_resched() is a no-op, > > so a CPU-bound kthread only ever leaves the CPU by preemption, and one > > such kthread holds every synchronize_rcu_tasks() caller -- ftrace and > > BPF trampoline teardown under their mutexes, the kprobe jump optimizer > > under text_mutex and cpus_read_lock() -- hostage for as long as it runs. > > > > Following the discussion on v2, take the other road: let the > > architecture make its trampolines Tasks Trace RCU readers. When an > > architecture selects HAVE_RCU_TRAMPOLINE_READERS it promises that every > > trampoline whose lifetime Tasks RCU guards enters rcu_read_lock_trace() > > (or its assembly equivalent) before calling out and leaves it before > > returning, so a task anywhere inside such a call-out, preempted or not, > > is an ordinary Tasks Trace reader. > > > > That leaves the few instructions of trampoline text before the reader > > is entered and after it is left (plus, in a later patch, the bytes a > > kprobe jump optimization is about to overwrite). A task can only linger > > there by being interrupted there, and such text never calls anything > > that schedules, so instead of tracking tasks we track CPUs: every pass > > through __schedule() is a per-CPU quiescent event, except that the one > > context switch that can catch a task at an arbitrary instruction -- a > > preemption from irq exit -- first records the interrupted IP in the task > > and parks it on a per-CPU list for the duration (reusing the fields and > > lists the classic flavor keeps for its exit-path bookkeeping), and, if > > the IP is inside such "unmarked" text, puts the task on a short holdout > > list; the task takes itself off at its next context switch outside such > > a preemption or irq-exit check that finds it elsewhere. Usermode (the > > existing tick hook, or a nohz_full CPU in an RCU extended quiescent > > state) and idle count as well. rcu_tasks_trampoline_text() does the > > classification: anything outside core and module text, a new > > .text..rcu_tramp section for C glue that trampolines call before it has > > entered the reader (__rcu_trampoline), and an arch hook for things like > > static ftrace stubs and return thunks. > > > > The grace period, run by the existing rcu_tasks kthread so that > > call_rcu_tasks(), synchronize_rcu_tasks() and rcu_barrier_tasks() keep > > their names and callers, is: wait for every online non-idle CPU to > > context switch (nudging stragglers with resched_cpu() after a jiffy), > > drain the holdout list as it stood, synchronize_rcu_tasks_trace() for > > everything inside the readers, then one more CPU pass and drain for > > tasks that have since left the reader into the trailing instructions. > > That is bounded by a few jiffies, preempt-off latency and an SRCU grace > > period rather than by the longest stretch any task runs without > > sleeping, needs no per-task scan, and makes cond_resched_tasks_rcu_qs() > > unnecessary on such architectures. As before, idle tasks are not > > waited for. rcu_tasks_wait_irq_preempted() walks the parked lists for > > the one caller (the kprobe jump optimizer, later in the series) that > > makes ordinary text unsafe to be parked in and so has to wait out tasks > > that were preempted there before it said so. > > > > The classic implementation is untouched and remains the default; the > > new one is built only as CONFIG_TASKS_RCU_TRAMPOLINE_READERS when the > > architecture opts in and uses the generic irq entry code, whose > > reschedule check gains the rcu_tasks_irq_resched() call. Nothing > > selects it yet. > > > > Suggested-by: Paul E. McKenney > > Suggested-by: Alexei Starovoitov > > Assisted-by: LLM > > Signed-off-by: Josef Bacik > > --- > > include/asm-generic/vmlinux.lds.h | 11 + > > include/linux/rcupdate.h | 32 ++- > > include/linux/sched.h | 1 + > > kernel/entry/common.c | 8 +- > > kernel/fork.c | 1 + > > kernel/rcu/Kconfig | 22 ++ > > kernel/rcu/tasks.h | 460 +++++++++++++++++++++++++++++++++++++- > > kernel/rcu/update.c | 2 + > > 8 files changed, 528 insertions(+), 9 deletions(-) > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > index b2988aa12f66..86e58c4fe370 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -571,6 +571,16 @@ > > __cpuidle_text_end = .; \ > > __noinstr_text_end = .; > > > > +/* > > + * C glue called directly from Tasks-RCU-protected trampolines, bounded so > > + * that rcu_tasks_trampoline_text() can recognise it; see __rcu_trampoline. > > + */ > > +#define RCU_TRAMP_TEXT \ > > + ALIGN_FUNCTION(); \ > > + __rcu_tramp_text_start = .; \ > > + *(.text..rcu_tramp) \ > > + __rcu_tramp_text_end = .; > > + > > #define TEXT_SPLIT \ > > __split_text_start = .; \ > > *(.text.split .text.split.[0-9a-zA-Z_]*) \ > > @@ -607,6 +617,7 @@ > > TEXT_HOT \ > > *(TEXT_MAIN .text.fixup) \ > > NOINSTR_TEXT \ > > + RCU_TRAMP_TEXT \ > > *(.ref.text) > > > > /* sched.text is aling to function alignment to secure we have same > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > index 44c07a66edff..fb2a3889a696 100644 > > --- a/include/linux/rcupdate.h > > +++ b/include/linux/rcupdate.h > > @@ -50,6 +50,31 @@ token_context_lock_instance(RCU, RCU_BH); > > /* Exported common interfaces */ > > void call_rcu(struct rcu_head *head, rcu_callback_t func); > > void rcu_barrier_tasks(void); > > + > > +/* > > + * Trampoline-reader Tasks RCU (CONFIG_TASKS_RCU_TRAMPOLINE_READERS), see > > + * kernel/rcu/tasks.h. rcu_tasks_irq_resched_enter()/_exit() bracket the > > + * irq-exit preemption; rcu_tasks_trampoline_text() and the arch_ override > > + * classify an interrupted IP; rcu_tasks_wait_irq_preempted() lets a caller > > + * wait out tasks already preempted somewhere it is about to make unsafe. > > + * __rcu_trampoline places C code that such trampolines call directly, before > > + * it has entered its Tasks Trace reader, where that classification can see it. > > + */ > > +void rcu_tasks_irq_resched_enter(unsigned long ip); > > +void rcu_tasks_irq_resched_exit(void); > > +bool rcu_tasks_trampoline_text(unsigned long ip); > > +bool arch_rcu_tasks_trampoline_text(unsigned long ip); > > +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > > +void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)); > > +#else > > +static inline void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)) { } > > +#endif > > +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > > +/* Also keeps instrumentation calls out of the prologue, ahead of the reader. */ > > +#define __rcu_trampoline __noinstr_section(".text..rcu_tramp") > > +#else > > +#define __rcu_trampoline > > +#endif > > void synchronize_rcu(void); > > > > /* > > @@ -180,11 +205,16 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } > > #ifdef CONFIG_TASKS_RCU_GENERIC > > > > # ifdef CONFIG_TASKS_RCU > > -# define rcu_tasks_classic_qs(t, preempt) \ > > +# ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > > +void rcu_tasks_note_qs(struct task_struct *t, bool preempt); > > +# define rcu_tasks_classic_qs(t, preempt) rcu_tasks_note_qs((t), (preempt)) > > +# else > > +# define rcu_tasks_classic_qs(t, preempt) \ > > do { \ > > if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ > > WRITE_ONCE((t)->rcu_tasks_holdout, false); \ > > } while (0) > > +# endif > > void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func); > > void synchronize_rcu_tasks(void); > > void rcu_tasks_torture_stats_print(char *tt, char *tf); > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > index 8b3d47a325cc..15beb44caa2c 100644 > > --- a/include/linux/sched.h > > +++ b/include/linux/sched.h > > @@ -957,6 +957,7 @@ struct task_struct { > > u8 rcu_tasks_holdout; > > u8 rcu_tasks_idx; > > int rcu_tasks_idle_cpu; > > + unsigned long rcu_tasks_irq_ip; > > struct list_head rcu_tasks_holdout_list; > > int rcu_tasks_exit_cpu; > > struct list_head rcu_tasks_exit_list; > > diff --git a/kernel/entry/common.c b/kernel/entry/common.c > > index e4acd50bd81a..94318519998c 100644 > > --- a/kernel/entry/common.c > > +++ b/kernel/entry/common.c > > @@ -6,6 +6,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > > > @@ -141,8 +142,13 @@ void raw_irqentry_exit_cond_resched(struct pt_regs *regs) > > rcu_irq_exit_check_preempt(); > > if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) > > WARN_ON_ONCE(!on_thread_stack()); > > - if (need_resched() && arch_irqentry_exit_need_resched()) > > + if (need_resched() && arch_irqentry_exit_need_resched()) { > > + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) > > + rcu_tasks_irq_resched_enter(instruction_pointer(regs)); > > preempt_schedule_irq(); > > + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) > > + rcu_tasks_irq_resched_exit(); > > + } > > } > > } > > #ifdef CONFIG_PREEMPT_DYNAMIC > > diff --git a/kernel/fork.c b/kernel/fork.c > > index 416758c8a3d4..8077336bb136 100644 > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -1871,6 +1871,7 @@ static inline void rcu_copy_process(struct task_struct *p) > > p->rcu_tasks_holdout = false; > > INIT_LIST_HEAD(&p->rcu_tasks_holdout_list); > > p->rcu_tasks_idle_cpu = -1; > > + p->rcu_tasks_irq_ip = 0; > > INIT_LIST_HEAD(&p->rcu_tasks_exit_list); > > #endif /* #ifdef CONFIG_TASKS_RCU */ > > #ifdef CONFIG_TASKS_TRACE_RCU > > diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig > > index 332df7a7a634..bbab14bc14c3 100644 > > --- a/kernel/rcu/Kconfig > > +++ b/kernel/rcu/Kconfig > > @@ -107,6 +107,28 @@ config TASKS_RCU > > default NEED_TASKS_RCU && PREEMPTION > > select IRQ_WORK > > > > +config HAVE_RCU_TRAMPOLINE_READERS > > + bool > > + help > > + Select this if the architecture uses the generic irq entry code and > > + every trampoline whose lifetime Tasks RCU guards on it (ftrace > > + trampolines, kprobe out-of-line and optimized-probe slots, BPF > > + trampolines, out-of-line ftrace direct-call trampolines) enters a > > + Tasks Trace RCU read-side critical section before calling out of > > + the trampoline and leaves it before returning, and any core text > > + that runs on behalf of such a trampoline outside that reader is > > + reported by arch_rcu_tasks_trampoline_text(). The assembly readers > > + use the this_cpu_inc() form of SRCU-fast, hence !NEED_SRCU_NMI_SAFE. > > + > > +config TASKS_RCU_TRAMPOLINE_READERS > > + def_bool TASKS_RCU && HAVE_RCU_TRAMPOLINE_READERS && GENERIC_IRQ_ENTRY && !NEED_SRCU_NMI_SAFE > > + select TASKS_TRACE_RCU > > + help > > + Implement the Tasks RCU grace period as a per-CPU pass over > > + context switches and irq-exit reschedules outside trampoline text > > + plus a Tasks Trace RCU grace period, instead of waiting for every > > + task to voluntarily context switch. See kernel/rcu/tasks.h. > > + > > config FORCE_TASKS_RUDE_RCU > > bool "Force selection of Tasks Rude RCU" > > depends on RCU_EXPERT > > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h > > index 627295396cd9..3a7c092361a6 100644 > > --- a/kernel/rcu/tasks.h > > +++ b/kernel/rcu/tasks.h > > @@ -152,7 +152,7 @@ static struct rcu_tasks rt_name = \ > > .kname = #rt_name, \ > > } > > > > -#ifdef CONFIG_TASKS_RCU > > +#if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) > > > > /* Report delay of scan exiting tasklist in rcu_tasks_postscan(). */ > > static void tasks_rcu_exit_stall(struct timer_list *unused); > > @@ -802,7 +802,7 @@ static void rcu_tasks_torture_stats_print_generic(struct rcu_tasks *rtp, char *t > > > > #endif // #ifndef CONFIG_TINY_RCU > > > > -#if defined(CONFIG_TASKS_RCU) > > +#if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) > > > > //////////////////////////////////////////////////////////////////////// > > // > > @@ -897,10 +897,445 @@ static void rcu_tasks_wait_gp(struct rcu_tasks *rtp) > > rtp->postgp_func(rtp); > > } > > > > -#endif /* #if defined(CONFIG_TASKS_RCU) */ > > +#endif /* #if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) */ > > > > #ifdef CONFIG_TASKS_RCU > > > > +static int rcu_tasks_lazy_ms = -1; > > +module_param(rcu_tasks_lazy_ms, int, 0444); > > + > > +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > > + > > +//////////////////////////////////////////////////////////////////////// > > +// > > +// Tasks RCU for architectures whose trampolines are Tasks Trace RCU > > +// readers (CONFIG_HAVE_RCU_TRAMPOLINE_READERS). > > +// > > +// On these architectures every piece of text whose lifetime Tasks RCU > > +// guards -- ftrace trampolines, kprobe optinsn slots, BPF trampoline > > +// images, out-of-line ftrace direct-call trampolines -- enters a Tasks > > +// Trace RCU read-side critical section before calling out of itself and > > +// leaves it before returning, so a task anywhere inside such a call-out, > > +// preempted or not, is an ordinary rcu_read_lock_trace() reader and > > +// synchronize_rcu_tasks_trace() waits for it. > > +// > > +// What that cannot cover is the handful of instructions in the trampoline > > +// before the reader is entered and after it is left, and the one user that > > +// has no trampoline at all: the bytes after a kprobe that the jump > > +// optimizer is about to overwrite. A task can only linger in such > > +// "unmarked" text by being interrupted there; unmarked text never calls > > +// anything that could schedule. So a context switch on a CPU tells us that > > +// whatever that CPU was running is out of unmarked text, with one > > +// exception: a preemption from the irq-exit path, which can happen at any > > +// instruction boundary. That path has the interrupted pt_regs in hand, so > > +// just before it preempts it records the IP in the task and checks it > > +// (rcu_tasks_trampoline_text()); if it is inside unmarked text the task > > +// goes on a short holdout list first, and takes itself off again at its > > +// next context switch outside such a preemption or its next irq-exit > > +// check that finds it elsewhere. With that, every pass through > > +// __schedule() is a per-CPU quiescent event, as are usermode and idle. > > +// > > +// A grace period is then: > > +// > > +// 1. Wait for every online, non-idle CPU to context switch, nudging > > +// stragglers with resched_cpu(). Afterwards no task is in the leading > > +// unmarked instructions of a dying trampoline unless it is on the > > +// holdout list. > > +// 2. Wait for the holdout list (as it stood) to drain. > > +// 3. synchronize_rcu_tasks_trace(), for everything inside the readers. > > +// 4. Repeat 1 and 2 for tasks that have since left the reader and are in > > +// the trailing unmarked instructions. > > Alternatively the approach could be generalized to vanilla RCU, it could be > possible to define a .text.rcu_no_qs section within which code running is > considered as an RCU reader (with a pause while on the explicit RCU tasks > section). It would be forbidden to voluntary sleep inside > and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). > > Based on IP, RCU could consider those interrupted section as readers. This would > require PREEMPT_RCU though. > > And then synchronize_rcu() would do the 1, 2, 4 jobs. If I am following correctly (ha!), sleepable BPF programs rule out use of RCU in this manner. But your point is nevertheless valid, in that SRCU could be used. And because rcu_read_lock_trace() is a thin wrapper around SRCU-fast, we *might* be able to instead use rcu_read_lock_tasks_trace(), which would skip the task-struct increment and decrement, saving a few instructions. Then, instead of waiting for each task's counter to go to zero, instead just invoke synchronize_rcu_tasks_trace(). Which is pretty close to what Josef is proposing, just with the new RCU Tasks Trace read-side primitives. I think. ;-) This assumes that we do not need to flatten partially overlapping RCU Tasks Trace readers into one big reader. Or am I missing something here? Thanx, Paul From xen-devel-bounces@lists.xenproject.org Wed Sep 16 00:05:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 00:05:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422173.1647705 (Exim 4.92) (envelope-from ) id 1x6d95-00069l-MV; Wed, 16 Sep 2026 00:05:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422173.1647705; Wed, 16 Sep 2026 00:05:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6d95-00069e-HX; Wed, 16 Sep 2026 00:05:03 +0000 Received: by outflank-mailman (input) for mailman id 1422173; Wed, 16 Sep 2026 00:05:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6d93-00069W-LM for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 00:05:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6d91-00645c-IR for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 02:04:59 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9dcec-8faa-0a2a0a5109dd-0a2a45069bd2-22 for ; Wed, 16 Sep 2026 02:04:59 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9dd2b-195a-0a2a45060019-416d716cb7aa-3 for ; Wed, 16 Sep 2026 02:04:59 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id B396640E01F9; Wed, 16 Sep 2026 00:04:58 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7oU5wfVy674d; Wed, 16 Sep 2026 00:04:51 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 6659940E015B; Wed, 16 Sep 2026 00:04:36 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1789517091; bh=WkVYQ3OsJCAsU+bmA69lZz2EHCVpfFuTnaOAkdJMBTY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kPVnzKMKNTszNOxzT8EmeyXvqDOq1+TdT9uNBmyPgAR4Q8+WlJ/GgzgE1SgoF+0wa C8+fa14EYhk2d8Gd811+MKAdsG/n/yBm/vGthLfj0GZXDQNtm3yp4gztrsvaD9xvlu 9iH4tlnS8m6njgnKNfWs2KDjQPRyh7cBiZ9pzga/vIoVCiViUSZzGcvjN8HrQJdx46 Gmz1RE0C3lgocziKN5XCOMIGGYIPuFsmwwZYXoqfZmpSSKa/UkqJI2CSQ7Wz3aBATq 3K7u0/JRzejAJjhUX4NFelbnq6yZF0ekoiyZW6m5wXypcI8AoeNg7X2LBXIYkU+bqr 8JI5Vo+PWDutoemX6Ax0lw9QxGE79C6mkDBujxRrlTfEGKcnDrOHFEGBRNGwpFbIE7 9xI4YWR+eq/MXpMIB3lBUEKiv1fyjZeKpY0uAf8iG/GiwanL34g6d3DqJc+f1bZAgM NiJfy/GaOt2OoGnxWG35CT9h7EfOKNbBxjUN/2m2Xbj8v+UfOoZzsKN98Plred/4SF tFE73SA/mjm0ABRdPVhXZz0H+JUqgOX47gZNT4FhJ7PRcEl7EB5yTBwYbYFbNagOBd Fi2YKI8t3KsXMzR0TQ4ug28ifNYFJbdurHHZ5cUgWOSy6ALy5WIz8LLn99Kl4sw0tI NxIfFiGJk1BoehWZY13rOvrk= Date: Tue, 15 Sep 2026 17:04:32 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() Message-ID: <20260916000432.GDaqndEGBGiL2IUPrG@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> <6113f06c790cfe1141d2dc09b68937b6@igalia.com> <20260915051155.GGaqjTm7yIluwxZ80x@fat_crate.local> <20260915154853.GAaqlo5YxQ9ALlhjbF@fat_crate.local> <9086138f2dcaffe30622438b7e825ae7@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9086138f2dcaffe30622438b7e825ae7@igalia.com> X-purgate-ID: tlsNG-16d1c6/1789517099-F76C877B-2C95953C/0/0 X-purgate-type: clean X-purgate-size: 830 On Tue, Sep 15, 2026 at 08:49:27PM -0300, Mauricio Faria de Oliveira wrote: > IMO a fix in the source file is clearer, less obfuscated than in a > Makefile (and the source file has to be changed anyway). No, with the build option you only need to touch the Makefile which contains the build directives for the objects which contain hypervisor_cpuid_base() and xen_prepare_pvh(). > It also has the potential advantage that, if the Makefile change slips in > a future change/refactor, the issue shouldn't reappear. Yes, that is possible. > Either way, please let me know and I can certainly change the patch. Ok, let's do the explicit thing - the difference between the solutions is not that earth-shattering. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Wed Sep 16 00:53:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 00:53:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422191.1647713 (Exim 4.92) (envelope-from ) id 1x6dtU-0004K8-43; Wed, 16 Sep 2026 00:53:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422191.1647713; Wed, 16 Sep 2026 00:53:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6dtU-0004K1-1Q; Wed, 16 Sep 2026 00:53:00 +0000 Received: by outflank-mailman (input) for mailman id 1422191; Wed, 16 Sep 2026 00:52:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6dtS-0004Jv-IZ for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 00:52:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6dtR-003zlu-1w for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 02:52:57 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9e854-8faa-0a2a0a5109dd-0a2a450cdf9c-16 for ; Wed, 16 Sep 2026 02:52:56 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9e867-f479-0a2a450c0019-d561b338c222-3 for ; Wed, 16 Sep 2026 02:52:56 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x6dt7-002hsb-93; Wed, 16 Sep 2026 02:52:37 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x6dt6-0088ZL-81; Wed, 16 Sep 2026 02:52:36 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x6dt6-00000002AJn-1CbL; Wed, 16 Sep 2026 02:52:36 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=71+5XpzCocajiTsiXQeY++69HYCLAtrxNkPLeB+bShA=; b=BbWB8poqLP8OS5CNwejIh0tZCt WbwFW81FEfVr5PrfZvomEx1IQF9+zetaBpiX6cr02wx2nv93e5R73XLzotWF5VBcViKnSPQCsJK3s I34X4jHK1Lh4JAT9tgjyz9z2qLExHSpfIImNjAmt4HnzFuRcDEVhrz4hCN4ZXO/kUaZrKSe2Dx/cv f8F/eM6voT+vU9lSl6KR5fo7bLdFQFk0lra6qJVcyFIzPI26l7UJLOIZAgCGETREp533wvAGFUhVb gflVwxkGWo/m8rlZDr+EvRPLMDcX9VOv9CeYVvsNI4dZ9CuKRn3Tg5rTff1FSm7KMD/Wl15OZHHra bTD6PZ/g==; MIME-Version: 1.0 Date: Tue, 15 Sep 2026 21:52:35 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() In-Reply-To: <20260916000432.GDaqndEGBGiL2IUPrG@fat_crate.local> References: <20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com> <20260822-pvh-kasan-inline-v9-4-e70ef3b75b6a@igalia.com> <20260911043822.GHaqOFvnw5mQ0s89QQ@fat_crate.local> <6113f06c790cfe1141d2dc09b68937b6@igalia.com> <20260915051155.GGaqjTm7yIluwxZ80x@fat_crate.local> <20260915154853.GAaqlo5YxQ9ALlhjbF@fat_crate.local> <9086138f2dcaffe30622438b7e825ae7@igalia.com> <20260916000432.GDaqndEGBGiL2IUPrG@fat_crate.local> Message-ID: <6092a255f6fd5ccbc7945b4df0ecc88f@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-d25034/1789519976-766DEA5B-13BDFEB4/0/0 X-purgate-type: clean X-purgate-size: 1174 On 2026-09-15 21:04, Borislav Petkov wrote: > On Tue, Sep 15, 2026 at 08:49:27PM -0300, Mauricio Faria de Oliveira wrote: >> IMO a fix in the source file is clearer, less obfuscated than in a >> Makefile (and the source file has to be changed anyway). > > No, with the build option you only need to touch the Makefile which contains > the build directives for the objects which contain hypervisor_cpuid_base() and > xen_prepare_pvh(). IIUIC, the source file would also be touched for changing __builtin_memcmp() into the open-coded comparison suggested earlier, no? (the 3x u32-based comparisons.) And that is the code which would require -fno-builtin-memcmp in a Makefile. >> It also has the potential advantage that, if the Makefile change slips in >> a future change/refactor, the issue shouldn't reappear. > > Yes, that is possible. > >> Either way, please let me know and I can certainly change the patch. > > Ok, let's do the explicit thing - the difference between the solutions is not > that earth-shattering. Ok, I think this closes the feedback and discussion so far; I'll send v10. Thanks again, > > Thx. -- Mauricio From xen-devel-bounces@lists.xenproject.org Wed Sep 16 03:20:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 03:20:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422228.1647721 (Exim 4.92) (envelope-from ) id 1x6gBk-000435-49; Wed, 16 Sep 2026 03:20:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422228.1647721; Wed, 16 Sep 2026 03:20:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6gBk-00042x-1A; Wed, 16 Sep 2026 03:20:00 +0000 Received: by outflank-mailman (input) for mailman id 1422228; Wed, 16 Sep 2026 03:19:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6gBj-00042r-3Y for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 03:19:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6gBi-0033iJ-H0 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 05:19:58 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa0ab4-8faa-0a2a0a5109dd-0a2a4501cb94-28 for ; Wed, 16 Sep 2026 05:19:58 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa0add-5984-0a2a45010019-a065830896be-3 for ; Wed, 16 Sep 2026 05:19:58 +0200 Received: from xenrt10716048 (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 1118F453E758; Tue, 15 Sep 2026 23:17:57 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Lin Liu To: jbeulich@suse.com Cc: abdelkareem.abdelsaamad@citrix.com, andrew.cooper3@citrix.com, jason.andryuk@amd.com, lin.liu01@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/nSVM: Validate the L1 MSRPM physical address range Date: Wed, 16 Sep 2026 03:19:52 +0000 Message-ID: <20260916031952.720395-1-lin.liu01@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <73918fa5-0c61-4a91-8e44-be5bd377141b@suse.com> References: <73918fa5-0c61-4a91-8e44-be5bd377141b@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1789528798-BF063757-B1BB9333/0/0 X-purgate-type: clean X-purgate-size: 1765 On 10.09.2026 09:29, Jan Beulich wrote: > On 10.09.2026 08:18, Lin Liu wrote: >> 8c36d5a500 ("x86/nSVM: Validate the L1 IOPM physical address range") added >> this check for the IOPM. The MSRPM requires a check as well. > > See https://lists.xen.org/archives/html/xen-devel/2026-08/msg00242.html > and Abdelkareem's reply. If you disagree, please go into further detail > here. I had missed that thread; the patch as posted should not go in as it stands. The one thing I would still raise is that hvm_copy_from_guest_phys() does not only reject an out-of-range MSRPM. It also rejects one which is in range but simply not backed by memory - and hardware accepts that. I checked on an EPYC 9255: I patched Xen so an ordinary non-nested guest's own VMCB carried _msrpm_base_pa = 1 << 45, in range with nothing behind it. The guest ran a full Linux boot; a rejected VMRUN would have executed no guest instructions at all. On an EPYC 9965 I then counted MSR exits, and the CPU reads such a map as all ones - every one of the ten bits construct_vmcb() clears trapped, against none in a control guest on the same boot. (What an unbacked machine-physical read returns is chipset behaviour, not architectural.) So what I would like to send as v2 is two patches: 1/2 make the MAXPHYADDR range check explicit, as 8c36d5a500 did for the IOPM. No functional change on its own. 2/2 stop a failed copy returning NSVM_ERROR_VVMCB; fill the cached map instead - all ones where L1 set MSR_PROT, zero where it did not. They have to go together: that failing copy is currently the only thing rejecting an out-of-range MSRPM, so 2/2 alone would leave one accepted. Does that sound reasonable to you? Lin From xen-devel-bounces@lists.xenproject.org Wed Sep 16 03:45:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 03:45:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422259.1647730 (Exim 4.92) (envelope-from ) id 1x6gaI-0007oo-SY; Wed, 16 Sep 2026 03:45:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422259.1647730; Wed, 16 Sep 2026 03:45:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6gaI-0007oh-Py; Wed, 16 Sep 2026 03:45:22 +0000 Received: by outflank-mailman (input) for mailman id 1422259; Wed, 16 Sep 2026 03:45:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6gaH-0007ob-0M for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 03:45:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6gaG-00FpDF-DO for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 05:45:20 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa10b6-8faa-0a2a0a5109dd-0a2a450bbdba-30 for ; Wed, 16 Sep 2026 05:45:20 +0200 Received: from [74.125.227.141] (helo=mail-pj2-f13.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa10ce-b7e8-0a2a450b0019-4a7de38dc0d1-3 for ; Wed, 16 Sep 2026 05:45:20 +0200 Received: by mail-pj2-f13.google.com with SMTP id 98e67ed59e1d1-396ccd78e6eso121477a91.0 for ; Tue, 15 Sep 2026 20:45:19 -0700 (PDT) Received: from localhost (ec2-35-83-186-167.us-west-2.compute.amazonaws.com. [35.83.186.167]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39e1bba0696sm1902898a91.7.2026.09.15.20.45.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 20:45:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="In-Reply-To:References:To:From:Subject:Cc:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789530318; x=1790135118; darn=lists.xenproject.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ukRQUFxBTM3YxkUDVCzWjtsHOmDoo6m23BhwxAxqqWs=; b=DuM+AOgGFiWTaSXFKszBCnHTnJZgjSqjXJkFUXiiMxiru4MizjPORcEew6qlNgEWCd CuFScDe1RcDz23yOoyYY2MgH0fhtryBRa+Jy5uogZyE/NTS5Q3pAYqKV3cT6mKFpQi0G 7K3V3/IFAIH8H0FGpCCTfecJ+kDvnPl22iitOYL7B8rcRcHnqJDbN8nUEbXp98TvkW5l alNk4K0UoZFAWxgLwj0HF+htiyfEN+7mB2lJQwU3mrcjyoi4WHRPam9Ekkakm0T+vXRV nPjHbpWhVitBeElH2COPD1wffS04P3xXgkvYkHBOLGUfQjUo9O9doocdP8GAL+QDpNRi ji6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789530318; x=1790135118; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ukRQUFxBTM3YxkUDVCzWjtsHOmDoo6m23BhwxAxqqWs=; b=IUjFQyCtSwEn1SpBx2G9PYmBIcMT5JEBTVSOe39agQL0GXruRyItS0ux6RcnkEVhXj YaVcDt/PhrQuLFwz9hPulwLaaC0pM+oJM/RVYIPxWl/6YrIeb8A6sZFoVbsSYu2/yMhe 2FGHrR740j1/jvjhzqgxPuXD56KUeDIS8OAgHJLK4bPcT8NEPaA/bTJTq3ackGbtmYRg OhW3hewP58G3kRsmWubk5IkoDDYyIAXJ/C+Hfp/ef4OXTSZ4BC07wRx9zwl4nOr86oM4 6nVdei0bNgVT/fq8hDjfUkJIG9TFQicjcqUiXfdy53QogB+SY8H5PbKXLmar4ztm37WA V7Jw== X-Forwarded-Encrypted: i=1; AKwUvBwjQbz7Za1LMloMdRs16UheezU1QHx+XIPAMws37QeL9Jf2E7C3qaMYeLSyyHmvhUmWcAI1e3OqQ/o=@lists.xenproject.org X-Gm-Message-State: AFuF++nMkZlhJlQuMULMMXGviIKMJSfP8BInG0Ymovkob0r9mwVXCuDJ dF1aoN9ahQA+fO4t9wvxR0ITtfKCrbs7E/i9DvowzS7cob9cP4gh2bfS X-Gm-Gg: AYBFou1CRKMQb2df6RaBEmI+XO50+PGq4741PAV2mcYse020vfXvMG9RaqsiNq5An0E 7wCSs0Gr10pYqj70QFMnkf7qaVZ/T8Y5X6oYKdR9BjXeueARnstj8Fv5adLpVEx1hdLDUhRzPme 0Uth9nyxCtCBqe/T8h+hXLf0TupqCIj5FTR0pcTHxeBoXHqeUNvjj53x50RAvwcUJGRh7UIStXJ R2TRZqOy/3QcQILDkNWCe61x577eT1dQVa+iqHbIqDA5JIQYSuumobVv4NDAOn3r7Mc1ebZ3DKK EQoWFDVWCZbZZkDdWZQz//ClKUJ1VhvsnqBTFFwdwbOsAnqw9OlaM6kBoyVKoNJmFiLR2tqT7lg Z72XIZKlxQyII9iK8w74PjjDDfRtzNuQcUcVrpO7XdcJWFVIlBn2Rel31h1ZwNWWvmX8Ditm/Bt MQhg9T7IV2ae54xEtW2cwbRXiCJztV+JzRNCki1TSp/SxZ/+uYPH88EtgJyLT9zYsuGIPbr8uGx mHg9RCEltYBY4i0dkRy4f3sgC+AKEudFuUG3CzlJNghz73Wh1+5rvvUlkzSuMTiF4ZTuGzXo7h7 4DxpR/IklGq+R/HTuo6pO19WdRDPdJgNTpkt0M+kQ/8E0ZBeDcsBoKXhwb00pkiXGhY= X-Received: by 2002:a17:90b:2f06:b0:39d:b57e:b47d with SMTP id 98e67ed59e1d1-39e1ff96302mr969180a91.8.1789530318064; Tue, 15 Sep 2026 20:45:18 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 16 Sep 2026 03:45:16 +0000 Message-Id: Cc: "Andy Lutomirski" , "Josh Triplett" , "Uladzislau Rezki" , "Mathieu Desnoyers" , "Lai Jiangshan" , "Zqiang" , "Juergen Gross" , "Luis Chamberlain" , "Ihor Solodrai" , , , , , , , "Andy Lutomirski" , "Josh Triplett" , "Uladzislau Rezki" , "Mathieu Desnoyers" , "Lai Jiangshan" , "Zqiang" , "Juergen Gross" , "Luis Chamberlain" , "Ihor Solodrai" , , , , , , Subject: Re: [PATCH RFC v3 06/13] bpf: Take a Tasks Trace reader in the trampoline glue From: "Alexei Starovoitov" To: "Josef Bacik" , "Paul E. McKenney" , "Frederic Weisbecker" , "Neeraj Upadhyay" , "Joel Fernandes" , "Boqun Feng" , "Thomas Gleixner" , "Peter Zijlstra" , "Steven Rostedt" , "Masami Hiramatsu" , "Mark Rutland" , "Jiri Olsa" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , , "Catalin Marinas" , "Will Deacon" , "Puranjay Mohan" , "Xu Kuohai" , "Paul E. McKenney" , "Frederic Weisbecker" , "Neeraj Upadhyay" , "Joel Fernandes" , "Boqun Feng" , "Thomas Gleixner" , "Peter Zijlstra" , "Steven Rostedt" , "Masami Hiramatsu" , "Mark Rutland" , "Jiri Olsa" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , , "Catalin Marinas" , "Will Deacon" , "Puranjay Mohan" , "Xu Kuohai" X-Mailer: aerc 0.17.0 References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-6-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-6-0ad30c4c5ee7@toxicpanda.com> X-purgate-ID: tlsNG-42698a/1789530320-184CB9EA-DE772F7D/0/0 X-purgate-type: clean X-purgate-size: 713 On Tue Sep 15, 2026 at 1:17 PM UTC, Josef Bacik wrote: > +static __always_inline void bpf_tramp_read_lock_trace(void) > +{ > + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) > + rcu_read_lock_trace(); > +} > + > +static __always_inline void bpf_tramp_read_unlock_trace(void) > +{ > + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) > + rcu_read_unlock_trace(); > +} > + > +static u64 notrace __rcu_trampoline > +__bpf_prog_enter_recur(struct bpf_prog *prog, struct bpf_tramp_run_ctx *= run_ctx) > __acquires(RCU) > { > + bpf_tramp_read_lock_trace(); > rcu_read_lock_dont_migrate(); This is double increment. rcu_read_lock_dont_migrate() includes rcu_read_lock_trace(). From xen-devel-bounces@lists.xenproject.org Wed Sep 16 04:16:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 04:16:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422280.1647739 (Exim 4.92) (envelope-from ) id 1x6h4J-0003c8-2H; Wed, 16 Sep 2026 04:16:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422280.1647739; Wed, 16 Sep 2026 04:16:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6h4I-0003c1-Vj; Wed, 16 Sep 2026 04:16:22 +0000 Received: by outflank-mailman (input) for mailman id 1422280; Wed, 16 Sep 2026 04:16:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x6h4H-0003bv-Cw for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 04:16:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6h4F-006SFq-Ep for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 06:16:19 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa17fd-bab6-0a2a0a5309dd-0a2a450c8268-12 for ; Wed, 16 Sep 2026 06:16:19 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa1813-f479-0a2a450c0019-4a7de14cf443-3 for ; Wed, 16 Sep 2026 06:16:19 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6350faaso169103f8f.0 for ; Tue, 15 Sep 2026 21:16:19 -0700 (PDT) Received: from [10.250.112.129] (h-213.61.72.154.host.de.colt.net. [213.61.72.154]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf33e01sm4529369f8f.23.2026.09.15.21.16.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 21:16:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789532179; x=1790136979; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LJ7Q+r4Dz9iCkm1JnTTVO7noWaR6rOrHRmLAPkrbqC8=; b=ehqAvvAcyX7+KmvOV45QE3UQwyHqiVrLWCu2sjCVjKkfhZLtEi2c768TScaUAWFlB3 ITWEPe9m06uyPzu57yy2dsJyE4up2hU/hGnHGGELtqbZlOxaD9kM946dNarGYGni2K8K 8bgqHbThgFWgsvGsKR1DIofTGxnOqMui6RfniQ+dN3C4HsHvS6Or+x3ekVzXssnMC7br hY+CQBrFENKpiK7E+F5HvIMzjuyJovFe2nIZhoZ4dqXn6C+n4CXjh1dtAabhMHNiZ8aX Dqxp7CgRchOimcFIQqbORmLox7Lp+dMAvt8z40d0IkABGswnvyBbSgmbwVZrDOMYB8D1 d9dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789532179; x=1790136979; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=LJ7Q+r4Dz9iCkm1JnTTVO7noWaR6rOrHRmLAPkrbqC8=; b=nYwBqm0jQ7I1JuVbnrndfwOE35CXQ8CfQH233MmxTEdvSN/gHNI9TVyqKS2ONxFd+y hN7ASaIAs71HORbH+MXnu6XBav8tgnbFeOugJ00BFoAowo5eOMIFw0Kps4Sc4Ca5SuUj CdDbXZpwa+XnDh+H+RZ5DlcYXjTfEOh6KUrZ7Eo8X8+2vXblOGBwHEvapFX0lWv/MZ7C Tzq/MZtv1Plrio7IxKhTuR4mGF3yy5kMKxHPxzgOoyMg4D/75tGmX2VSaMLHOGGG/Nu/ DO4wrz3KlWJ8tnvibOMuRvMvFn4VFC9c1T7UUunKyHd1fApmlYmLmZXr6kDqN7uQXNjV 2vuA== X-Forwarded-Encrypted: i=1; AKwUvBwHu0jU09K6FqhS70+g9ZDYGgl/zp6dN3LIlJjhk5UblHmkgHiv3N2yqkmpmklG8RkaplZgPGk222E=@lists.xenproject.org X-Gm-Message-State: AFuF++ktJOWBBfN82rXvmFmjefaZyvkPE8XIl4CIUiPRv9WGe4BkJTj/ XOvXWv1V3n0jTSoPZ8DOccz1YmCZ1XUztyOdJt0v4ylKqt0YBNDTw5PJ X-Gm-Gg: AYBFou07pS3zZZW3ZNJxCtR1SFAp3P1OaoSmWyHCqJi7qfZrqhLlZGJGN9lZNqHbBq4 hral1Y9N+7okiU252KVijuQULbkgBeEXTvP9/8CjIwAIwTZmRD5WwO7BVOu/upsfF0A6vpsn2z+ WoB3XefS+SPgaBB//qssiqDdyxdKyqzlGJ16SeDkEQXXkJS4/vsvd+J8l0voyhyIbSSJwFutT/e CbQtxVhtdLHFSa1gla3lXI9qGSmiIePFYbF5oS8LbaqZ9TIliFlEap6aYl3uFm7aFKZS9XuRwY2 nlmWJepJOBuvJIqo32NRzk8TieB3vMDRVU7UZ+57C8IAQJAkMdSARKOpFszyabgzZGd1IK8LIQb mhBjMjWbJeyAgONW4tqsfR43RsP/02wlQVzntdKigTC5fu1A8WbyBUC1PcdBKi8U7g8zSExOZD4 RscNamrC8nHYSYYZNTdg5zSp+5Y0YNJq9wcQu3xBnUmH76KMAIYGvWjyJNi7+PeMspUQR54a/Uu aVTIgYj4gx5WdP6OXdQciQ/BPVZ6GkikKIXk7BMtZyDw/Dr X-Received: by 2002:a05:6000:220b:b0:487:863:253d with SMTP id ffacd0b85a97d-4870d0667d8mr1082508f8f.31.1789532178702; Tue, 15 Sep 2026 21:16:18 -0700 (PDT) Message-ID: <35e5b328-2139-4ed4-a725-f4671f4239d6@gmail.com> Date: Wed, 16 Sep 2026 06:16:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 25/39] xen/riscv: add guest load emulation for trapped MMIO accesses To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7cf3203f8f826eefa1b24bb2dedbd76c0b611dc1.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1789532179-5073FA5B-CF0FD179/10/73395122804 X-purgate-type: spam X-purgate-size: 2108 On 9/14/26 1:48 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> @@ -419,7 +416,41 @@ static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di, >> >> static int emulate_load(const struct guest_fault *gf) >> { >> - return -EOPNOTSUPP; >> + struct cpu_user_regs *regs = gf->regs; >> + mmio_info_t info = { .is_write = false }; >> + struct decoded_insn di; >> + unsigned int shift = 0; >> + int rc; >> + >> + /* A fault taken re-reading the instruction is redirected to the guest. */ >> + if ( insn_fetch_faulted(gf, &di) ) >> + return 0; >> + >> + if ( !decode_ldst_insn(&di, guest_xlen(regs)) || di.is_write ) >> + return -EOPNOTSUPP; >> + >> + if ( !di.is_unsigned ) >> + shift = BITS_PER_BYTE * (sizeof(unsigned long) - di.len); > > This is one of the cases where sizeof() is not only unclear to > read, but actively risky: Which variable(s) of that type does this > refer to? What if those variable(s)' type(s) change? Aha, ... > >> +#ifdef EMULATE_LOAD_DEBUG >> + gdprintk(XENLOG_DEBUG, "pc=%#lx, addr=%#"PRIpaddr", len=%u, shift=%u\n", >> + regs->sepc, gf->gpa, di.len, shift); >> +#endif >> + >> + rc = do_mmio(&info, gf->gpa, di.len); >> + if ( rc ) >> + return rc; >> + >> + /* >> + * A load into x0 discards its result: writing regs->zero would break the >> + * invariant that it reads as zero when x0 is a source operand elsewhere. >> + */ >> + if ( di.reg ) >> + *guest_gpr(regs, di.reg) = (long)(info.data << shift) >> shift; > > ... you apparently mean sizeof(info.data) there. Good point. I will try to follow such approach in future and use the variable name instead of a type. > > The comment is (nit) also too long for my taste. Everything from the > colon onwards is imo redundant. Probably you are right. It is a little bit obvious just from the defintion of x0 that it should be always zero. I will drop that part of the comment after the colon. THanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 16 04:37:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 04:37:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422294.1647748 (Exim 4.92) (envelope-from ) id 1x6hOV-0006Wr-Mv; Wed, 16 Sep 2026 04:37:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422294.1647748; Wed, 16 Sep 2026 04:37:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6hOV-0006Wk-KH; Wed, 16 Sep 2026 04:37:15 +0000 Received: by outflank-mailman (input) for mailman id 1422294; Wed, 16 Sep 2026 04:37:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6hOU-0006WI-Bp for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 04:37:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6hOS-0013Lg-22; Wed, 16 Sep 2026 06:37:12 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa1ccc-e002-0a2a0a5209dd-0a2a4507a094-30 for ; Wed, 16 Sep 2026 06:37:10 +0200 Received: from [148.163.154.28] (helo=mx0b-0002e601.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa1cf4-b4ea-0a2a45070019-94a39a1c29d8-3 for ; Wed, 16 Sep 2026 06:37:09 +0200 Received: from pps.filterd (m0374955.ppops.net [127.0.0.1]) by mx0b-0002e601.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G3pb4p1476939; Tue, 15 Sep 2026 23:36:55 -0500 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11011059.outbound.protection.outlook.com [40.93.194.59]) by mx0b-0002e601.pphosted.com (PPS) with ESMTPS id 4gqc4paqph-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 15 Sep 2026 23:36:55 -0500 (CDT) Received: from BN9PR03CA0264.namprd03.prod.outlook.com (2603:10b6:408:ff::29) by SJ2PR10MB7618.namprd10.prod.outlook.com (2603:10b6:a03:548::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 04:36:48 +0000 Received: from BN3PEPF00022BBB.namprd04.prod.outlook.com (2603:10b6:408:ff:cafe::5c) by BN9PR03CA0264.outlook.office365.com (2603:10b6:408:ff::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.12 via Frontend Transport; Wed, 16 Sep 2026 04:36:47 +0000 Received: from flwvzet201.ext.ti.com (198.47.21.195) by BN3PEPF00022BBB.mail.protection.outlook.com (10.167.248.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 04:36:46 +0000 Received: from DFLE200.ent.ti.com (10.64.6.58) by flwvzet201.ext.ti.com (10.248.192.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 15 Sep 2026 23:36:24 -0500 Received: from DFLE213.ent.ti.com (10.64.6.71) by DFLE200.ent.ti.com (10.64.6.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 15 Sep 2026 23:36:24 -0500 Received: from lelvem-mr05.itg.ti.com (10.180.75.9) by DFLE213.ent.ti.com (10.64.6.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45 via Frontend Transport; Tue, 15 Sep 2026 23:36:24 -0500 Received: from [10.24.50.162] (uda0510294.dhcp.ti.com [10.24.50.162]) by lelvem-mr05.itg.ti.com (8.18.1/8.18.1) with ESMTP id 68G4aLPl1287894; Tue, 15 Sep 2026 23:36:22 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint-05-2026 header.d=ti.com header.i="@ti.com" header.h="CC:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=ti.com header.i="@ti.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint-05-2026; bh=amnGjW9G+3T7Nm5fmWbwKZWX0vAJQUWA3Hp30qjnN NQ=; b=D5CwfYEs2qF50Ugeqq8mM0RFiBiOPwjA0c5kLYBKsdHOjyR0ySya2LMcg 9FNrS8//GcTi9dG6roVUgTMU4VIRkOqom+xFIdrEWuHAAMF24QehFYgOsoznHbnD 1e/xhepNNSUKrg27yrHpLUqdrbYs0Dsh/mA0jr21ksVb1CUROH2pfnEWehlMuPHh cUtGmaQrkVIbYUCH1HsK21XXuEvN3EriRwKf1c9xEEDqNh+fsI+GzDVLYjECCcnA F3/TtZ+jYIhCL2q4lXkXU3bVdh85eJzKk4l9WDWGjQE/2fVL0niytcbwf70d4kVg JNNOnvNbL0omANBfvj9ENp42qLztw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jMbnjLFlql3aAQMJx6KG8vOLacUs5DTbSSyKNxlkHR7tRc0E6ZFoV0zX+0MK6ZKIL2shBF3WNC7/v1FLRkHVTyyD2w7Q7SF/raoD+kPvRskGJPMzClcMG2PiYM4xCZEWqMHEfwW7jgWB5bl2GsoVCcQHC48pZESc06BesrzXtWIA8/ijGysiaJyD2khfqYOnswGYdJKdOxgpSqbhwZtWCKKqncRww9w9A4RkB27Aeyv8sVUMZTFS++0o7+nJsROWdPp12DvPJUieH1LDfyLM28cPqPPzZPvVpCa/eV1vJPmf+kQ4xRDAmxfxmdO4gea0HLE++PnB/waEnMpYADiWGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=amnGjW9G+3T7Nm5fmWbwKZWX0vAJQUWA3Hp30qjnNNQ=; b=eWusskmxV71b/JQ089CDvwXl62vJC6tGYtvgjoptYOM8EUgI2sGjnppQrYFgU5q4O+WxbSWqaB8bGk74+5b4qlQD/pcChmb5pIssO4a2aqE2i92b7HI3AlNAYBm7HkCQGx6QgtngD3kPHoyGJ1Qy6jrJloV+Nqx378MROZ7F1wQATyVdv6gMcnEjOIdktun0nL8TYDHpkYMng6W5ex4oRx81eW3S+AFqCVLwKokCBg8c4BgKaZJowOBRMemqDvojlrpK8Gd4AGjZCHExbLX8uOjHP/P2B+js/nD/kKWHi5OHQBeCBHFbiIuAZDHQubfXFn0L1LMp0mI2pYG0q4Uclg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 198.47.21.195) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=ti.com; dmarc=pass (p=quarantine sp=none pct=100) action=none header.from=ti.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=amnGjW9G+3T7Nm5fmWbwKZWX0vAJQUWA3Hp30qjnNNQ=; b=bZnO8//5+wJ/smqy/BrDTBSzE2Du2TLSG44TvtWXOFj9wxOKXrm4oO5eDELoyrnSvOjkTSRYKstn0OUvjVRfw2nG7nGAjjR1J8JjGQOQ0nKtshqJHHMBBP5X/YatbQDzBzoPfXnxDGk/oVSJq1As/6dr/dH/maucq/ireKsalnY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 198.47.21.195) smtp.mailfrom=ti.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=ti.com; Received-SPF: Pass (protection.outlook.com: domain of ti.com designates 198.47.21.195 as permitted sender) receiver=protection.outlook.com; client-ip=198.47.21.195; helo=flwvzet201.ext.ti.com; pr=C Message-ID: <1f9617a8-1e34-4708-af44-5c1a0432e5d2@ti.com> Date: Wed, 16 Sep 2026 10:06:21 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Add support to passthrough reserved memory carveouts to DomU To: "Orzel, Michal" , , , CC: , , , References: <20260915082824.2180692-1-b-padhi@ti.com> Content-Language: en-US From: Beleswar Prasad Padhi In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BBB:EE_|SJ2PR10MB7618:EE_ X-MS-Office365-Filtering-Correlation-Id: bf3efa02-6a59-4c17-2a3c-08df13ac1d97 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|82310400026|23010399003|1800799024|10067099003|4143699003|6133799003|18002099003|22082099003|56012099006|13003099007; X-Microsoft-Antispam-Message-Info: a+sjoX7Re7btLqWGGCw5AuEN81aFEcscp3dLbyiLFeN8rf5L1LAuPMhAvudNVALhEfptPtrOdcg8ofXA8EhxDsBfCFmhNJSgRHR3425s2YNTYmPlrX01VrVHFoDR7dQ8sOW2deT5+TqF1A3CgEEa4XpBdVYPQV2N2gLvJlobePRuV+OXZa6E6ulosd3QBnUNnRI7UZjZynnVLSP69YNOtOI3LhDFIyMCTGqffORG+HtI6DKDsTNgCCxoNvPhtWzr4Fp/7WkcJVPtpBU+GTlaL783p1YQfQjzXVQwapJVkMJJlCDo7PYSkvWxmvS14dOxvV1oK1hTq+RbHpvmA02yPiUlXg917rpPp3nnQhdjQTUjg8/NVLJviRJECHQrTqK/ZnE3H4Nb+zHLIvdtMf2YuJuxolqYY/PeqdNHVtQfvTsTyZ1kvktVqK9tGmljrDa1YYOMBast1v9rwA7P26c1Jma0T+6ecatJJdimbwB54t1C9q1s6YsUqjGxcXjIUB3Pddv2xCwWrFy8SVWs3gh28NSqmgpP9Euix15ypJ/UNmt5Jh7pLeMAyuPXjicZr0CvRtJdlyvatptWcPHxUeI8Lq5iiHAMss9IFsx0PJLlWBfaVVtM0qqRmjVod2XhrncdFC8PNVFRfMe6Nf5iy9GlzJzGKJSEQeC3kIutQvy2zKv8YQJyBUrWI2RS1gomylYDSKVoTAx2YlFxTfSAqpLUjQ== X-Forefront-Antispam-Report: CIP:198.47.21.195;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:flwvzet201.ext.ti.com;PTR:ErrorRetry;CAT:NONE;SFS:(13230040)(376014)(36860700016)(82310400026)(23010399003)(1800799024)(10067099003)(4143699003)(6133799003)(18002099003)(22082099003)(56012099006)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: r/nrBkCkXZjBlGngjyByZBIN35szW0OrtSMoxMIbZPwEqMzwhc/0ekcqMxezC6ieZ3XnZ7/UaVl/rfDFDTTiymzETB0coVl1mBTt1ACL4jEq0jANdXoB764qY3MyEgBWrmY+IMS2pHhrCMMSSSNpxclLrkvOx/Wnos5CNxlfPlE85LPwga9bRkR8+FdzJXm6xIPqC8WwlBeJ17f58MJrCD6B5JwXzjN5rLcqCrxlegXm6ZAzthcTwfY7GvbkTm41OzPFc39XkJpkr3wFKKzjdqBKgNYlFJl3stFokyANOAvtk5fw4J0dyMNI3ZVJZJYZLwjg+R+lt1aynsIRoNCxMXTAbvOWwudHcnUs+/EhwU9bK+oo8swJwn/CN9WoKqQmKy9xBcFPoRT9oa+Aryyc6z3MaVKZcxkGpX8t9UjwYQ9YW9TDArW7e/KaNkfSd24H X-Exchange-RoutingPolicyChecked: 0/CZoscfYpHVrFRNjLeVvAWdpXkjjdaYQt6fLbHjvdjGR9KDmEtflyQyeqcXQ5hRo43P0IA/txxUJT+4GuO2EgAUT+1ko6I4xiMZrQIX31kZ13yA+Jq3sDZDDsCUzTlkRdrqF0AQ4vh8WnZJ/+AmxHmEzEptM5D5z3wCA416LjWnSu4ytalTQXEsJuSKXiv1RYF0XRnIS9A7gh1t9eTC/tMZwKiu+Aeqlo2Nf89voTLu0wlpwSNpiXSy8lPvLsy5V+Rt8Nxb6nXaUGuTu4H2/Frf1nZ1MCh9S3QuQzLECRyl+parNIbncuuqWhuQJkgcB057I75i5vLjk+y/LAx/ig== X-OriginatorOrg: ti.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 04:36:46.0441 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bf3efa02-6a59-4c17-2a3c-08df13ac1d97 X-MS-Exchange-CrossTenant-Id: e5b49634-450b-4709-8abb-1e2b19b982b7 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=e5b49634-450b-4709-8abb-1e2b19b982b7;Ip=[198.47.21.195];Helo=[flwvzet201.ext.ti.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF00022BBB.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR10MB7618 X-Authority-Analysis: v=2.4 cv=HP9WhYtv c=1 sm=1 tr=0 ts=6aaa1ce7 cx=c_pps a=jMLRuqkCa9WS4sFRI2wrKA==:117 a=tJyPKKxUohctrY4NYmUjkA==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=V5UXEbMT0ywA:10 a=VkNPw1HP01LnGYTKEx00:22 a=Z8NIEmU8O1QQgoT56wFK:22 a=fPAWb5peG099m5CrUpKH:22 a=VwQbUJbxAAAA:8 a=sozttTNsAAAA:8 a=NEAV23lmAAAA:8 a=V-GNSYgToPBOHEKkF1IA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: zolDfeCL-Cxrti9fwdDQiQcLNREWIl30 X-Proofpoint-ORIG-GUID: zolDfeCL-Cxrti9fwdDQiQcLNREWIl30 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDA1NyBTYWx0ZWRfXwl4FVqj5UhMe JGadcZyHw5BUbkkOCeplPPHlNE0ukCPXWo5h4WHW5FnlpDe7bMOFU/mXmGlDMFxABYOukiF2FmC 0t5cM58NFgGSV6PUN+/hhEPvQs4aZJY= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDA1NyBTYWx0ZWRfX8fnoJgW4gRT8 YQ7sz56rGmarh/vbT6JT8hnchfMjcnh2ljvEcvqTnucWhjExzehESfBw2GWeeas3CqgKbBv0cug 2I1jgZ8M6QysEA6jACrb3A4+ZU0qdznErSxbztkFU+Nfjvi8KNigHM36+mLW0FLHFc7QGfWnDk1 1S8vwUCml9SRD10DEdfjOfslI5eYnLOwuld/EN7FMe/cXNGKOJougGwbYszfpoge0/hFZZMXj+q rOE+cXNmzlFPWHfA9242E0NQg2n6XDp1JQxN8wSznLOiDz5LRBaAfR+Y7PyiEAyITd6i3JSXxZb MeQwkPEYOe+V9rFxGkuknO3fxVyKCIf/v3MkxS3eeeo8Y6mji4cE/Danj5vqo61b3OlPIDrKVzP /Vh3ykyQQSUaTy+rXCfOm8FVSxeeC3xzrLRuKrk4nJm9Ia3rniuixHe51FVm+iREMjWMNBpjO48 aG4Mr3H69X4aDvLQrcg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609160057 X-purgate-ID: tlsNG-ef75cf/1789533430-37CD7AE4-E820470C/0/0 X-purgate-type: clean X-purgate-size: 8366 Hello, On 15/09/26 15:28, Orzel, Michal wrote: > Hi, > > On 15-Sep-26 10:28, Beleswar Padhi wrote: >> Currently Xen only looks for /passthrough and /aliases nodes. Add >> support to parse the /reserved-memory node and pass it through as >> requested to DomUs. This is useful to enable many usecases in DomUs >> like Remoteproc firmware carveouts, CMA carveouts etc. >> >> If Xen's static shared memory carveout is found, it is placed as child >> nodes under the top level /reserved-memory node as also done in commit >> 51a2b3f10918 ("xen/arm: fix duplicate /reserved-memory node in Dom0"). >> >> Signed-off-by: Beleswar Padhi > I'm afraid adding support for passthroughing /reserved-memory nodes like this > patch does is unfortunately not enough to help with the common use cases these > days. /reserved-memory nodes got complex from Xen PoV mainly because of the > "reusable" property that lets OS (say Linux) use such memory for whatever it > wants until device asks for it. The common use case is "shared-dma-pool" and CMA > buffers. They specify "reusable" (hence no "no-map"). This causes a few issues: > 1) Xen maps memory for passthroughed regions for domUs as device memory (keep in > mind the rules from Arm ARM for joining stage 1 and stage 2 memory attributes - > device type is the most stringent one and wins) but for shared memory it should > be normal memory. > > 2) Linux can use such reserved memory region as normal RAM and hence use it for > Xen shared buffers (e.g. hypercall buffers, shared memory, etc.). As per > arch-arm.h any memory shared between guest and Xen needs to be of normal type. > > 3) Xen does not give reserved memory to the allocators and does not have backing > page_info structs for such pages. If such memory ends up being used with Xen > (e.g. to map foreign pages) such access will fail because Xen will not be able > to get pages for such region. > > Problem 3) exists today also for hwdom. Problems 1) and 2) are gone because Xen > maps memory of passthroughed nodes for hwdom in a more relaxed way so guest > attributes win. > > This is high on my TODO list because there is a real need from customers to add > a proper support but I don't have any bandwidth this year to do any work. > > I guess your solution would only work for the simplest use case which is for > /reserved-memory nodes with only "no-map" property present. We could limit the > support for only such nodes (check if it contains "reusable" property and if so, > bail out) as a temporary solution if this helps. Thanks for the detailed feedback. Let me come back with more reading to decide if I can implement passing through 'reusable' carveouts or we can go with only 'no-map' temporarily. Thanks, Beleswar > > ~Michal > > --- >> Hello all, >> >> Sending this patch as discussed in: >> https://lore.kernel.org/all/0e556bb5-269d-47d7-9ae8-68f06eee9fc0@ti.com/ >> >> Test Configurations & Logs: >> https://gist.github.com/3V3RYONE/bef3bb51459f8b823605261b35494a7e >> >> Thanks, >> Beleswar >> >> xen/common/device-tree/dom0less-build.c | 45 +++++++++++++++++++------ >> 1 file changed, 34 insertions(+), 11 deletions(-) >> >> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c >> index fcbeb8adbd..e9581327ee 100644 >> --- a/xen/common/device-tree/dom0less-build.c >> +++ b/xen/common/device-tree/dom0less-build.c >> @@ -334,7 +334,7 @@ static int __init handle_prop_pfdt(struct kernel_info *kinfo, >> static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, >> int nodeoff, >> uint32_t address_cells, uint32_t size_cells, >> - bool scan_passthrough_prop) >> + bool scan_passthrough_prop, bool resv_mem_node) >> { >> int rc = 0; >> void *fdt = kinfo->fdt; >> @@ -358,13 +358,20 @@ static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt, >> while ( node_next > 0 ) >> { >> rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells, >> - scan_passthrough_prop); >> + scan_passthrough_prop, false); >> if ( rc ) >> return rc; >> >> node_next = fdt_next_subnode(pfdt, node_next); >> } >> >> + if ( resv_mem_node ) >> + { >> + rc = make_shm_resv_memory_node(kinfo, address_cells, size_cells); >> + if ( rc ) >> + return rc; >> + } >> + >> return fdt_end_node(fdt); >> } >> >> @@ -389,7 +396,8 @@ static int __init check_partial_fdt(void *pfdt, size_t size) >> } >> >> static int __init domain_handle_dtb_boot_module(struct domain *d, >> - struct kernel_info *kinfo) >> + struct kernel_info *kinfo, >> + bool *found_reserved_mem_node) >> { >> void *pfdt; >> int res, node_next; >> @@ -430,8 +438,8 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, >> continue; >> >> /* >> - * Only scan /$(interrupt_controller) /aliases /passthrough, >> - * ignore the rest. >> + * Only scan /$(interrupt_controller) /aliases /passthrough >> + * /reserved-memory, ignore the rest. >> * They don't have to be parsed in order. >> * >> * Take the interrupt controller phandle value from the special >> @@ -445,7 +453,7 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, >> res = scan_pfdt_node(kinfo, pfdt, node_next, >> DT_ROOT_NODE_ADDR_CELLS_DEFAULT, >> DT_ROOT_NODE_SIZE_CELLS_DEFAULT, >> - false); >> + false, false); >> if ( res ) >> goto out; >> continue; >> @@ -455,11 +463,22 @@ static int __init domain_handle_dtb_boot_module(struct domain *d, >> res = scan_pfdt_node(kinfo, pfdt, node_next, >> DT_ROOT_NODE_ADDR_CELLS_DEFAULT, >> DT_ROOT_NODE_SIZE_CELLS_DEFAULT, >> - true); >> + true, false); >> if ( res ) >> goto out; >> continue; >> } >> + if ( dt_node_cmp(name, "reserved-memory") == 0 ) >> + { >> + res = scan_pfdt_node(kinfo, pfdt, node_next, >> + DT_ROOT_NODE_ADDR_CELLS_DEFAULT, >> + DT_ROOT_NODE_SIZE_CELLS_DEFAULT, >> + false, true); >> + if ( res ) >> + goto out; >> + *found_reserved_mem_node = true; >> + continue; >> + } >> } >> >> out: >> @@ -486,6 +505,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> { >> int addrcells, sizecells; >> int ret, fdt_size = DOMU_DTB_SIZE; >> + bool found_reserved_mem_node = false; >> >> BUILD_BUG_ON(DOMU_DTB_SIZE > SZ_2M); >> >> @@ -538,7 +558,7 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> */ >> if ( kinfo->dtb ) >> { >> - ret = domain_handle_dtb_boot_module(d, kinfo); >> + ret = domain_handle_dtb_boot_module(d, kinfo, &found_reserved_mem_node); >> if ( ret ) >> goto err; >> } >> @@ -556,9 +576,12 @@ static int __init prepare_dtb_domU(struct domain *d, struct kernel_info *kinfo) >> if ( ret ) >> goto err; >> >> - ret = make_resv_memory_node(kinfo, addrcells, sizecells); >> - if ( ret ) >> - goto err; >> + if ( !found_reserved_mem_node ) >> + { >> + ret = make_resv_memory_node(kinfo, addrcells, sizecells); >> + if ( ret ) >> + goto err; >> + } >> >> ret = make_intc_domU_node(kinfo); >> if ( ret ) From xen-devel-bounces@lists.xenproject.org Wed Sep 16 04:53:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 04:53:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422305.1647757 (Exim 4.92) (envelope-from ) id 1x6he2-0000sw-VC; Wed, 16 Sep 2026 04:53:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422305.1647757; Wed, 16 Sep 2026 04:53:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6he2-0000sp-S5; Wed, 16 Sep 2026 04:53:18 +0000 Received: by outflank-mailman (input) for mailman id 1422305; Wed, 16 Sep 2026 04:53:18 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x6he1-0000sj-UG for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 04:53:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6hdz-0015HF-8H for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 06:53:15 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa20b7-2eae-0a2a0a5409dd-0a2a450cc47c-10 for ; Wed, 16 Sep 2026 06:53:15 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa20ba-f479-0a2a450c0019-4a7de14c971f-3 for ; Wed, 16 Sep 2026 06:53:15 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-48434392b02so286294f8f.3 for ; Tue, 15 Sep 2026 21:53:15 -0700 (PDT) Received: from [10.250.112.129] (h-213.61.72.154.host.de.colt.net. [213.61.72.154]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf27ce2sm4217567f8f.20.2026.09.15.21.53.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 21:53:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789534394; x=1790139194; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=TjovXOKrHdNzhMFRWFG1pucKmnnB4Yp77LWjlx5Rkbo=; b=e3UmjIillTlxAYDDCN2syzSJpB/rMbu8FowwvHjPetjPufByQqVtneMGFNWd9/at6V EUUhrdpJeiKJ4y1bJiZyikckPK40eArR/PBJpgccnJR1yUPPl5fcL3DNc1hQmo9lZx4j J4TyWNXRjgdY8UY640GTM58yRssy7qlK9Hb1p43k6witQAcizndPyYOPHbxOAFV/4GeR roLlXDvEqScgHF9z/IKzZBLIMGQA5CR31M1O3M8WnT8jYOBZ+lbh2fw+spWtNk/wZU1h mTkf1yQJ+MFoNNtwGLjfYMXDAILfzrCwkJZ+ee03zZgusLKM5MhY3B1BKs3InQUlcqvB Tt6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789534394; x=1790139194; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=TjovXOKrHdNzhMFRWFG1pucKmnnB4Yp77LWjlx5Rkbo=; b=zw/sLSSLx0UlMRfzVtaGrWypW/xbnN085h4SFytgHwOfFQmCvTgsrCoE8gxxH8rHxp 3LAG8/DhVypfe7nh3sI6SR4wenL+rrffidQ7lWJ3/KXgdURZuMpguoDoqloDb+CAxJ36 a/MI42cUK1m1H7F+bjPWLbPqchMR6nspYHRyJa90Cb3sc9Te0c3v9rTTLMdWnYyWwqYr 7Dwiw+EB3si/iw/PipHvLhuQX/l8QsQr6L6135FW7+tf/lIt3q2OuNEfV5GB0c1Btg+7 8AyrgokLdXmeBtHoRheg66O9HudQKqHjCyABvTTXCsWCKpc7yZ6/se+TBiBdrOSwUaxV VEmg== X-Forwarded-Encrypted: i=1; AKwUvBxF2GDTxamQi2tz9/QOt77hlFXlk7LpMALwxMYe9J1ISTqUHu7BFX0HBpuuyuQr7nvwmu3yLoG9U5M=@lists.xenproject.org X-Gm-Message-State: AFuF++mMUTfMhLFlrgq0eGUsfqZBcQtc4lVnkq6U9FI9/n8LJEqppAfM jOz6XAzXQilLf6ShFxHQgOoowYijyGB5kPIK+ODhqK2n2v0jKUMny+69 X-Gm-Gg: AYBFou1Gqf2x6PpLokvaTs6nvUk4UjxxttDaC3dpdQB74Bscq0J9Rrb1hpdEnPtaNyV nuNEGnlEWwxxkkTnjCDWEqLPexhGe6mDqkgKIIQflpsrXTPO/BzlGntsCT3EoNotfDYknJZQ/Ym hnStxIawDOn4GzBl3hnyEzQcRsGGpmhIcxqYUZZeudIS5E1OC8ry/WOyyczwdozqLSVfQlLXGWT Vf0o1IjYXQ2x6ezLKRHiblgC1Tm4Q0S6/c1+ky+pH0LWWZF1taFavl3EaANbKdV2OQjGUvzZiob W8poApcamPd0QQ5dCrL/+to4UW/18lCFZGPdjP2Dfdgq26uuiuFR8KCi5OZ2s7lREOZ9y1sHp6I ICCkV287y4q9enyrKL8tOP7AWsISJwUyBN8vwhqsHNGrqhjcOnSBtFXHeQFVphx0clZzIhxWGmH w3m4xIGImBeN0FsyCJd4luLukTD4+8dEEOeivPWjxHfCzNVOPuOBS99uwWaSRWoOF71idIZfLAM AwIsglIUcCSZw6TdjMwEhVKsoge/D92cNvAw4JkwrvBODD5 X-Received: by 2002:adf:e00a:0:20b0:487:bef:31cb with SMTP id ffacd0b85a97d-4870d05afb7mr1667397f8f.22.1789534394565; Tue, 15 Sep 2026 21:53:14 -0700 (PDT) Message-ID: <900ec227-8960-4033-90f1-054180ad56b3@gmail.com> Date: Wed, 16 Sep 2026 06:53:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 26/39] xen/riscv: add guest store emulation for trapped MMIO accesses To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> <9d4600c6-258e-4990-b1f1-3c86037227b3@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <9d4600c6-258e-4990-b1f1-3c86037227b3@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1789534395-77ED2A5B-1453FC1B/10/73395122804 X-purgate-type: spam X-purgate-size: 2986 On 9/14/26 2:01 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/emulate.c >> +++ b/xen/arch/riscv/emulate.c >> @@ -453,9 +453,28 @@ static int emulate_load(const struct guest_fault *gf) >> return 0; >> } >> >> -static int emulate_store(struct guest_fault *gf) >> +static int emulate_store(const struct guest_fault *gf) >> { >> - return -EOPNOTSUPP; >> + struct cpu_user_regs *regs = gf->regs; >> + mmio_info_t info = { .is_write = true }; >> + struct decoded_insn di; >> + int rc; >> + >> + if ( insn_fetch_faulted(gf, &di) ) >> + return 0; >> + >> + if ( !decode_ldst_insn(&di, guest_xlen(regs)) || !di.is_write ) >> + return -EOPNOTSUPP; >> + >> + info.data = *guest_gpr(regs, di.reg); > > This came to mind only here, but applies to the earlier patch as well: > There's no checking of di.len, not even by an assertion. The above is > fragile as to extensions like Zilsd. Zilsd itself may still be okay as > the overrun of the register field will hit the correct one, but the > general concern remains (plus of course that moving across fields is > UB). Nothing can produce di.len > sizeof(register_t) today, as the 8-byte cases are all gated on xlen == 64, so I'd add the assertion at the point where the lengths are assigned, covering both emulate_load() (where the shift calculation would underflow) and emulate_store() at once: ASSERT(di->len <= sizeof(register_t)); right before decode_ldst_insn()'s final "return true". Probably it makes sense to have just "if (di->len >= sizeof(register_t) )" with the comment and then return false in deocde_lst_insn(): + /* + * An access wider than a register could not be carried through: the + * register operand guest_gpr() hands out is register_t-wide, as is the + * value an emulated access moves. None of the encodings above yields + * such an access, the 8-byte ones all being gated on XLEN=64, but a + * future extension might (Zilsd, say, whose 8-byte accesses exist for a + * 32-bit guest). + */ + if ( di->len > sizeof(register_t) ) + return false; (i think that the same could be also true for D and Zdinx but I will mention only Zilsd as an example) Also, I think it make sense to add the comment to guest_gpr() than di->len is checked in decode_ldst_insn(). Alternative will be to update the proto of guest_gpr() and pass `di` and then have extra ASSERT() in guest_gpr() for the case if someone will try to use guest_gpr() without using insn_fetch_faulted() & decode_ldst_insn() before guest_gpr(). I will apply this alternative way, it looks to me better for now and then will add the following ASSERT: /* * decode_ldst_insn() is what fills @di in, and it rejects an access * wider than a register. */ ASSERT(di->len <= sizeof(register_t)); Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 16 05:07:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 05:07:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422314.1647766 (Exim 4.92) (envelope-from ) id 1x6hrd-0002v4-3y; Wed, 16 Sep 2026 05:07:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422314.1647766; Wed, 16 Sep 2026 05:07:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6hrd-0002ux-0y; Wed, 16 Sep 2026 05:07:21 +0000 Received: by outflank-mailman (input) for mailman id 1422314; Wed, 16 Sep 2026 05:07:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6hrb-0002ur-Fm for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 05:07:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6hra-00E7xh-P7 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 07:07:18 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa23fb-bab6-0a2a0a5309dd-0a2a4505c60c-32 for ; Wed, 16 Sep 2026 07:07:18 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa2406-4cb1-0a2a45050019-4a7de18dd05c-3 for ; Wed, 16 Sep 2026 07:07:18 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912e4ad9so2334435e9.2 for ; Tue, 15 Sep 2026 22:07:18 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e83db9102sm46523255e9.12.2026.09.15.22.07.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 22:07:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789535238; x=1790140038; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wqy+eUnBDhR3xphgwfhff7sRpkik/R1pHavkMcVWaco=; b=MXvImZCOWlYGhh4Q8J65J6Hwjtxmej0YS5o48FhT1sGXFVr+5OnaBB1JgJ5Y34K1pl N/q3Ix7UQ+9JPzrIAaOwvn5+TzJ0zW3iTz5PgxeHG0tuW5svqd8DhVKmDNe3f5XQq68+ JHNh1fGUPqqLCLIkQs7a6kC8DrFV4n3yjrgfWlqSfELo5fhVCj/VF7S3Z03TAWGRu9jc VbaXYcoTn20SvZXpOmfaUGiW15nHvUDc0jNlP6QaxqXePFPdMcRX4GPsN19i45wM0a1g b2nOQq/jeurCGPyiVWeQZs644fkC3tAfW5gifig+1gMc7J2ouiRfc0LBDskdWd0A2KIf qPqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789535238; x=1790140038; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=wqy+eUnBDhR3xphgwfhff7sRpkik/R1pHavkMcVWaco=; b=CM25yItX+oVmuYjFn3r0PcXTOEZMprhW6mfFzHQeciAMQA98GVQdHD/5HXF5fhs6Jy Pnfdlj/3oEYmc/ZHhu4IFE0fI040N7QBVW1uokRwba6B5srSYQmdn571vxODvOSaymFO Qpo9C90wvcNbQtQ3MKJVMpK3t6xIBRk/tANeahF+O95GLCluXF5HXuQF9IgK1va4BIF2 jfuB7At8J4iDOr5KjU6MnLYVwOy66aH+WSbT0qNDjou9UHWWgrCmciYSCxpegOwxE5P/ ZZk7250Qe6B9r1g4gubapg1RaFHKN4fq+s4Ptggl+QW7HOYW+XSBvMuK9IkhjthbQcKd U2Fg== X-Forwarded-Encrypted: i=1; AKwUvBxV3MZNKH6SNOcDB/Y/ShOj/8sd7HLN9FFFdmBG9tdfbvQ/O/a8frtUFpFSKlUJ02jQTNA4QPO0hJw=@lists.xenproject.org X-Gm-Message-State: AFuF++mswaMuHdtZq+Z3sKce2n2h2IavFAA8SIi+FWtvozW41KjvRReb /aPJ/wvjHamiz/yt9DVrFooOvyyA/33ImcdjJHWwPHUj+zOiGeaszvFeDdIzY+qZ8Q== X-Gm-Gg: AYBFou22jwVcOHHXKQMpCr0GBS4MVl2jFe7ErTowz1klVgfEub9+VA+uRl5xw4+2sMz xTJQFFp9c9jIWm8ZgAM6ImQmCy3jbzGt41ds99oozi1jBLhXs0trx8Azdug/KKUbbwaKZ4099C+ adMznpDzcxb6217WLBc8FyOq3SL3SBFRPZ5ouv3KYmmF2zranmbxOpR2Dr6wsW7+py9JXxQ4UCX N9rI5SpVTH06VjV4QFJmBBmChWA96t/yADzgHzPTt/4UBoxjan9XuHEikjBuTaSmcj6XQZvd4i+ 2IQ1fPGBJmUDNWb9H7nRRHdumo/HPi7OEF1TK+1+2TCw2WMqhKV7ilC7R9gPAC5UyjDtAk2EbQB 2tI+w3hjkOmAMjRArWFh4zZ8OOCl1GW9x99THYCQtrjnRrf05JrX6lSAmrpxw413D7DI1amEPTb rYRTlbYCbms34bQhKnm0nxBPwnkXVTyaG2CTf7tGrXpuDov475XzH7YIFYDNgax1mFKRm5Q3G2K ZY= X-Received: by 2002:a05:600c:c165:b0:49c:fc6e:a3d8 with SMTP id 5b1f17b1804b1-49eb733641fmr9448305e9.23.1789535237953; Tue, 15 Sep 2026 22:07:17 -0700 (PDT) Message-ID: <85e4aa12-7fc8-4c52-9fdc-ca4408cc9375@suse.com> Date: Wed, 16 Sep 2026 07:07:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Validate the L1 MSRPM physical address range To: Lin Liu , andrew.cooper3@citrix.com Cc: abdelkareem.abdelsaamad@citrix.com, jason.andryuk@amd.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <73918fa5-0c61-4a91-8e44-be5bd377141b@suse.com> <20260916031952.720395-1-lin.liu01@citrix.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <20260916031952.720395-1-lin.liu01@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789535238-F46A52A1-F21E3C5E/0/0 X-purgate-type: clean X-purgate-size: 2239 On 16.09.2026 05:19, Lin Liu wrote: > On 10.09.2026 09:29, Jan Beulich wrote: >> On 10.09.2026 08:18, Lin Liu wrote: >>> 8c36d5a500 ("x86/nSVM: Validate the L1 IOPM physical address range") added >>> this check for the IOPM. The MSRPM requires a check as well. >> >> See https://lists.xen.org/archives/html/xen-devel/2026-08/msg00242.html >> and Abdelkareem's reply. If you disagree, please go into further detail >> here. > > I had missed that thread; the patch as posted should not go in as it > stands. > > The one thing I would still raise is that hvm_copy_from_guest_phys() > does not only reject an out-of-range MSRPM. It also rejects one which > is in range but simply not backed by memory - and hardware accepts > that. > > I checked on an EPYC 9255: I patched Xen so an ordinary non-nested > guest's own VMCB carried _msrpm_base_pa = 1 << 45, in range with > nothing behind it. The guest ran a full Linux boot; a rejected VMRUN > would have executed no guest instructions at all. On an EPYC 9965 I > then counted MSR exits, and the CPU reads such a map as all ones - > every one of the ten bits construct_vmcb() clears trapped, against > none in a control guest on the same boot. (What an unbacked > machine-physical read returns is chipset behaviour, not architectural.) > > So what I would like to send as v2 is two patches: > > 1/2 make the MAXPHYADDR range check explicit, as 8c36d5a500 did for > the IOPM. No functional change on its own. > 2/2 stop a failed copy returning NSVM_ERROR_VVMCB; fill the cached > map instead - all ones where L1 set MSR_PROT, zero where it did > not. > > They have to go together: that failing copy is currently the only > thing rejecting an out-of-range MSRPM, so 2/2 alone would leave one > accepted. > > Does that sound reasonable to you? On the surface it sounds plausible. I'm not sure we'd be doing ourselves a favor, though. Non-RAM is rejected in other situations as well, where in principle the same behavior you describe could apply. Hence imo if we wanted to go that route, I think we'd want to be consistent. That would be quite a bit more work. Andrew - do you have any thoughts here? Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 16 05:15:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 05:15:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422326.1647777 (Exim 4.92) (envelope-from ) id 1x6hzJ-0004dE-V0; Wed, 16 Sep 2026 05:15:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422326.1647777; Wed, 16 Sep 2026 05:15:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6hzJ-0004d6-RO; Wed, 16 Sep 2026 05:15:17 +0000 Received: by outflank-mailman (input) for mailman id 1422326; Wed, 16 Sep 2026 05:15:16 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6hzI-0004d0-NH for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 05:15:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6hzH-00E96A-Nm for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 07:15:15 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa25cf-bab6-0a2a0a5309dd-0a2a4504de50-16 for ; Wed, 16 Sep 2026 07:15:12 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa25e0-b57f-0a2a45040019-4a7de14cbd9e-3 for ; Wed, 16 Sep 2026 07:15:12 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843172bff4so193398f8f.0 for ; Tue, 15 Sep 2026 22:15:12 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf43511sm4128146f8f.33.2026.09.15.22.15.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 22:15:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789535712; x=1790140512; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=lxewp+tTZQXrODK7DvbcdNn3QRHocyOZLU3+rzgQEyI=; b=IDTDhVhn9WMSBhUaUuvTFi+bmpdlNuIjQHf9J/MfkvMKymSK4mkpSb+i1VyKh91Wet eywXlJm/pKMEU2a1cUb6pTQxnbEorq3qyVpPxJmg9RDnJ+e5hmZwAtmQidgabnhP+Us0 uR9pUV6AT9n6I1hx4ubwqkF7V9TlBykyYXmbxg1e6g1m+NfGvacder2Cm8LC4WQDA9qJ eO3dc15hR6tMjSn14SJP5dUpe9CP1/at4jolSIkKtm1GyJSq2sdFxQ/PA4nNklQ5kgWl MByZh191l83H+SaUI7Vuuk8aX1Q57EQA6yf7/VX6ajz0fO2k/Cg7b0+HWjtGKWQ4//cK n8MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789535712; x=1790140512; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=lxewp+tTZQXrODK7DvbcdNn3QRHocyOZLU3+rzgQEyI=; b=XxbczWUdLK5u5vnjhuSw8JWcniPw2CAqOYNTTzI/d9jCDKnobjdC9qXLzoHvarZjDt KhHCKbm0Pa7DbohOx/+lSKz5T5qXLhbF3T15LVC/SCnsvynopGIwLGz9bGnWFxhBTzNM Xe79i4eXo7zsb5f9pffybgFLp8w4sOd9Wdx++T1u67hgHfSUh2MapRB6Tcz0rFCZYIbG ImupJlkXCh5jpgxWjXjuAuLnFpDvagbx2rE7Be3IeWYqaJlOSNupQ7alV4/IBPmxM90u FgozMlUtTbJ1WU4BQcLJBnZcN0oywYK9pe1y1dp7tf0TorbXlx/Sn2Mw94ZsiHMFP8XA IH8w== X-Forwarded-Encrypted: i=1; AKwUvBx5o8S0OK12IzUsgp0nDTkSF42wnkXOqlXe7uqwl4g9rbCS+7Q0VqKuCBVj43Lr7TwKN1Uh2IdqJI0=@lists.xenproject.org X-Gm-Message-State: AFuF++kdj0EFZifS0BpaMZphmkDLfejUGGh33F4d1245YiB/rsozN0n8 l2x90bc474I7mI2fnByckbBa5tckbKuL9dn8mab07QPPBdqpPWygr+w5bPRPuQAm/A== X-Gm-Gg: AYBFou0EPqSJWFHJvcISKHAmUTEksG4+YzJZDNvN39BIWUHIegajkcdgJdvDXpt37yy iVIlx/YtDPnyPaeJV5PSeebP2JEU7Mnk62Q7pywb2AmfqboGteccjiAmDs5Yw5y7nGcYN+dOI6x imheSGjYNjq2Aj5hgfT/WtPlVliWA7H1FbqNeyK3ZtQ3oh9r4UXft3PiPfzUqOx/fi+53QI9GjD Y92jUvGrR12XQnWJvKJBQLmxQ4rJlPrKBfU9qJTvvgodbQbi3xmhwbY7G/fVOnyteIrMPU8BZ2i HC4sVe2Iipm+JvWbByOXBMidGTRnHXm+KwGKH/I/AVMqvFnyDcA8Wow4QCg6gHqtyIf7VSyeSQH ltLU8++vZk6imV5ngJCRxfqNN9TOsyAN7Zv2uCvJfgOGPYxOj3qFdWbUOHMcJnko6chKnsyZ+In PzBKpgAgxx94dj4Y6JxJQLz7L9BELx7kQCoJ9DnVG70GXLwkS4dkHAPuL4I65K+tLGJrRcr1glt B8= X-Received: by 2002:a05:6000:24c6:b0:487:a15:b4cc with SMTP id ffacd0b85a97d-4870cf1acd3mr1172083f8f.23.1789535711568; Tue, 15 Sep 2026 22:15:11 -0700 (PDT) Message-ID: <68b71d51-3784-472b-ab1c-b24b98ccdd27@suse.com> Date: Wed, 16 Sep 2026 07:15:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 26/39] xen/riscv: add guest store emulation for trapped MMIO accesses To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> <9d4600c6-258e-4990-b1f1-3c86037227b3@suse.com> <900ec227-8960-4033-90f1-054180ad56b3@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <900ec227-8960-4033-90f1-054180ad56b3@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1789535712-536C2B50-42CFDE75/0/0 X-purgate-type: clean X-purgate-size: 3464 On 16.09.2026 06:53, Oleksii Kurochko wrote: > On 9/14/26 2:01 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/emulate.c >>> +++ b/xen/arch/riscv/emulate.c >>> @@ -453,9 +453,28 @@ static int emulate_load(const struct guest_fault *gf) >>> return 0; >>> } >>> >>> -static int emulate_store(struct guest_fault *gf) >>> +static int emulate_store(const struct guest_fault *gf) >>> { >>> - return -EOPNOTSUPP; >>> + struct cpu_user_regs *regs = gf->regs; >>> + mmio_info_t info = { .is_write = true }; >>> + struct decoded_insn di; >>> + int rc; >>> + >>> + if ( insn_fetch_faulted(gf, &di) ) >>> + return 0; >>> + >>> + if ( !decode_ldst_insn(&di, guest_xlen(regs)) || !di.is_write ) >>> + return -EOPNOTSUPP; >>> + >>> + info.data = *guest_gpr(regs, di.reg); >> >> This came to mind only here, but applies to the earlier patch as well: >> There's no checking of di.len, not even by an assertion. The above is >> fragile as to extensions like Zilsd. Zilsd itself may still be okay as >> the overrun of the register field will hit the correct one, but the >> general concern remains (plus of course that moving across fields is >> UB). > > Nothing can produce di.len > sizeof(register_t) today, as the 8-byte > cases are all gated on xlen == 64, so I'd add the assertion at the point > where the lengths are assigned, covering both emulate_load() (where the > shift calculation would underflow) and emulate_store() at once: > ASSERT(di->len <= sizeof(register_t)); > right before decode_ldst_insn()'s final "return true". > > Probably it makes sense to have just "if (di->len >= sizeof(register_t) > )" with the comment and then return false in deocde_lst_insn(): > > + /* > + * An access wider than a register could not be carried through: the > + * register operand guest_gpr() hands out is register_t-wide, as is the > + * value an emulated access moves. None of the encodings above yields > + * such an access, the 8-byte ones all being gated on XLEN=64, but a > + * future extension might (Zilsd, say, whose 8-byte accesses exist > for a > + * 32-bit guest). > + */ > + if ( di->len > sizeof(register_t) ) > + return false; > > (i think that the same could be also true for D and Zdinx but I will > mention only Zilsd as an example) Since you don't support floating point extensions so far, that's probably best. I don't quite understand the mentioning of Zdinx, though: That extension (by itself) doesn't add any memory access insns. > Also, I think it make sense to add the comment to guest_gpr() than > di->len is checked in decode_ldst_insn(). Alternative will be to update > the proto of guest_gpr() and pass `di` and then have extra ASSERT() in > guest_gpr() for the case if someone will try to use guest_gpr() without > using insn_fetch_faulted() & decode_ldst_insn() before guest_gpr(). > I will apply this alternative way, it looks to me better for now and > then will add the following ASSERT: > > /* > * decode_ldst_insn() is what fills @di in, and it rejects an access > * wider than a register. > */ > ASSERT(di->len <= sizeof(register_t)); Here and above using register_t won't help with Zilsd. The type is tied to Xen's xlen, but you mean to check against the guest's here. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 16 05:23:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 05:23:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422340.1647785 (Exim 4.92) (envelope-from ) id 1x6i7C-0006J4-Lo; Wed, 16 Sep 2026 05:23:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422340.1647785; Wed, 16 Sep 2026 05:23:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6i7C-0006Ix-IZ; Wed, 16 Sep 2026 05:23:26 +0000 Received: by outflank-mailman (input) for mailman id 1422340; Wed, 16 Sep 2026 05:23:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x6i7A-0006Ir-H0 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 05:23:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6i79-0019RN-E8 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 07:23:23 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa27a2-bab6-0a2a0a5309dd-0a2a4508c694-30 for ; Wed, 16 Sep 2026 07:23:23 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa27cb-f659-0a2a45080019-4a7de14ca049-3 for ; Wed, 16 Sep 2026 07:23:23 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6350f91so220532f8f.1 for ; Tue, 15 Sep 2026 22:23:23 -0700 (PDT) Received: from [10.250.112.129] (h-213.61.72.154.host.de.colt.net. [213.61.72.154]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf37e69sm4246357f8f.29.2026.09.15.22.23.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 22:23:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789536203; x=1790141003; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7qFLGsBMWm6xJEgJYQAHZtHzOXRYDMZ+HdX9upL3PYA=; b=hFOT3mG6Z4EbGXp9g7JX2IGqwrUf/t0osnjIkBlYyMhR1psER5jh1ZUrBevTmQTLGu EwvK7iG1A+y4PE2d4xN7f9xoXcS2SyKT/0j37QhLqMmOU1PGyuNmHZTr5+aAcct4PMXf SICWD1gQ6bvIujYXZYKKMk+AoG5DrvPyTx7bbUbU9iJewjZqaP8ou8rEc+KIJSWqG9xA ymsgD0R5X4egslNtYemufEFn2EJpPbXktMAqaS0MkBme0SE0Flb6gqAsTvmsvFAkAqQz gCxxkQ9SzJSDsPCT6xYUMKCRo9RUehS++LB7mvPJDQwwEg4H7MA/590yY5HgrzDUjW5O eKhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789536203; x=1790141003; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=7qFLGsBMWm6xJEgJYQAHZtHzOXRYDMZ+HdX9upL3PYA=; b=ZlmijKe36GSg7XVN/x15l2Ix21PeJIkEdZOkH8qOcnPelH+zk7dJyBNcgWTTQkvz7h DUTGDi3QX0Afm79sVzaPbOPM4R81WRlNzmsmBXpoJm9hYgpTyTu0vqoJnz+lAirffAxq 3L1CNmcbW6LCF5saRUYgTNSgvYVF7wVy6801u4SwQhG/vEfS2qPfRcsTbMEjAIPFac1R 3uSTiBnvulSTlsQ4IRv82IgGz2AGi5y1+gFtxvBhX2RJjg1CoLKkLw12nryVzqi/O0RT /5wI2xVEHvD3z9CFkBgcmFWCa96Q3CEi5jFw87Mc4rcQk7eXnAoEBM67rZYn7dWzQQar m3FA== X-Forwarded-Encrypted: i=1; AKwUvBxA4zqQGZ0sPKqUZziqx0FGvHMKPPaSuquyE8VtRdrNQX6VknFbC1HeKP6tuttxX7ele2XKIBGUWt8=@lists.xenproject.org X-Gm-Message-State: AFuF++lxvRjq3UvT6Ku9F/Y1Jnt5z0iLSNEsgu0gs9HziorTMZnYpHy5 bfhO0ybOi4jGDuUmEhKXNeIRyO+SKzHvwbHtHrWnOIMJuSBfaSN67WgW X-Gm-Gg: AYBFou2U0AEjN9C89s+hHxyktK81Y4e9we4GtuuFBrOAfo4J9gwlEdWlGc7+euYHUjq 3Uw2p8zchInzgzow4OqVqw+LVNOu7zK06ndPEUWdhsd9O8gGOCUY8LK4mGKq9vXjwaoofTdzsDH /15DlMvF8VgFYwKf0Kf1EU0ieLzOp3YNbO2UHu3rW0KlK8UtdQU1txhJWrTn/1jUitCCOTNTvtd nHw1i3allysE/uKQlPOhPfJvGap4I3xLpPGia8nbRACRFlIT6PjfznHL14/HyzjQXX3PZtdaVBf Pbc4vQSGyFR1n1zsthI2Nm/jOfXkajp5f1RURalnsQyLJAunkwoUOt48DD+stdceg7zOGbaspm6 M7gBN5gngV0dKPt9BH6QI4kitdI+LLvginVIARO8sAL3LKEXJjR6+yMMXr23owZQgkZEzOojWG0 zlPDDVm+5by6o7Jwrk7f6XZZu0SKD0EI6+G7ogD2y8sKFJZVdSoDnpY/iDQrn4cklb2zdyJFBxO fR/mHBiS37TjRgEuVJCHH/mc50GNYFDdZSyNudF/IYkrtJS X-Received: by 2002:a05:6000:2901:b0:487:aa6:c90d with SMTP id ffacd0b85a97d-4870cf09f05mr1350827f8f.1.1789536202786; Tue, 15 Sep 2026 22:23:22 -0700 (PDT) Message-ID: Date: Wed, 16 Sep 2026 07:23:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 26/39] xen/riscv: add guest store emulation for trapped MMIO accesses To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> <9d4600c6-258e-4990-b1f1-3c86037227b3@suse.com> <900ec227-8960-4033-90f1-054180ad56b3@gmail.com> <68b71d51-3784-472b-ab1c-b24b98ccdd27@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <68b71d51-3784-472b-ab1c-b24b98ccdd27@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789536203-CD14E87B-EDD98216/10/73395122804 X-purgate-type: spam X-purgate-size: 3657 On 9/16/26 7:15 AM, Jan Beulich wrote: > On 16.09.2026 06:53, Oleksii Kurochko wrote: >> On 9/14/26 2:01 PM, Jan Beulich wrote: >>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>> --- a/xen/arch/riscv/emulate.c >>>> +++ b/xen/arch/riscv/emulate.c >>>> @@ -453,9 +453,28 @@ static int emulate_load(const struct guest_fault *gf) >>>> return 0; >>>> } >>>> >>>> -static int emulate_store(struct guest_fault *gf) >>>> +static int emulate_store(const struct guest_fault *gf) >>>> { >>>> - return -EOPNOTSUPP; >>>> + struct cpu_user_regs *regs = gf->regs; >>>> + mmio_info_t info = { .is_write = true }; >>>> + struct decoded_insn di; >>>> + int rc; >>>> + >>>> + if ( insn_fetch_faulted(gf, &di) ) >>>> + return 0; >>>> + >>>> + if ( !decode_ldst_insn(&di, guest_xlen(regs)) || !di.is_write ) >>>> + return -EOPNOTSUPP; >>>> + >>>> + info.data = *guest_gpr(regs, di.reg); >>> >>> This came to mind only here, but applies to the earlier patch as well: >>> There's no checking of di.len, not even by an assertion. The above is >>> fragile as to extensions like Zilsd. Zilsd itself may still be okay as >>> the overrun of the register field will hit the correct one, but the >>> general concern remains (plus of course that moving across fields is >>> UB). >> >> Nothing can produce di.len > sizeof(register_t) today, as the 8-byte >> cases are all gated on xlen == 64, so I'd add the assertion at the point >> where the lengths are assigned, covering both emulate_load() (where the >> shift calculation would underflow) and emulate_store() at once: >> ASSERT(di->len <= sizeof(register_t)); >> right before decode_ldst_insn()'s final "return true". >> >> Probably it makes sense to have just "if (di->len >= sizeof(register_t) >> )" with the comment and then return false in deocde_lst_insn(): >> >> + /* >> + * An access wider than a register could not be carried through: the >> + * register operand guest_gpr() hands out is register_t-wide, as is the >> + * value an emulated access moves. None of the encodings above yields >> + * such an access, the 8-byte ones all being gated on XLEN=64, but a >> + * future extension might (Zilsd, say, whose 8-byte accesses exist >> for a >> + * 32-bit guest). >> + */ >> + if ( di->len > sizeof(register_t) ) >> + return false; >> >> (i think that the same could be also true for D and Zdinx but I will >> mention only Zilsd as an example) > > Since you don't support floating point extensions so far, that's probably > best. I don't quite understand the mentioning of Zdinx, though: That > extension (by itself) doesn't add any memory access insns. > >> Also, I think it make sense to add the comment to guest_gpr() than >> di->len is checked in decode_ldst_insn(). Alternative will be to update >> the proto of guest_gpr() and pass `di` and then have extra ASSERT() in >> guest_gpr() for the case if someone will try to use guest_gpr() without >> using insn_fetch_faulted() & decode_ldst_insn() before guest_gpr(). >> I will apply this alternative way, it looks to me better for now and >> then will add the following ASSERT: >> >> /* >> * decode_ldst_insn() is what fills @di in, and it rejects an access >> * wider than a register. >> */ >> ASSERT(di->len <= sizeof(register_t)); > > Here and above using register_t won't help with Zilsd. The type is tied > to Xen's xlen, but you mean to check against the guest's here. Oh, you are right, it should be guest's xlen. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 16 05:32:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 05:32:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422350.1647794 (Exim 4.92) (envelope-from ) id 1x6iFo-0007yl-FN; Wed, 16 Sep 2026 05:32:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422350.1647794; Wed, 16 Sep 2026 05:32:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6iFo-0007ye-Bn; Wed, 16 Sep 2026 05:32:20 +0000 Received: by outflank-mailman (input) for mailman id 1422350; Wed, 16 Sep 2026 05:32:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x6iFn-0007yY-8K for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 05:32:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6iFm-008uIj-Dw for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 07:32:18 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa29c8-2eae-0a2a0a5409dd-0a2a450996c0-44 for ; Wed, 16 Sep 2026 07:32:18 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa29e2-be1a-0a2a45090019-4a7de14cad05-3 for ; Wed, 16 Sep 2026 07:32:18 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485ac898fa4so281344f8f.0 for ; Tue, 15 Sep 2026 22:32:18 -0700 (PDT) Received: from [10.250.112.129] (h-213.61.72.154.host.de.colt.net. [213.61.72.154]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf27ce2sm4461406f8f.20.2026.09.15.22.32.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 22:32:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789536738; x=1790141538; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=fskisN0fCV738ZD+8Qg9uE6kvXTWgr+lufjzhZ4Lm/w=; b=SVB3dpPt4AmzMDgZVb8Du33anw4yeJj+bNDZKuw2gxPbYztuCBKcQ5Jeep5RCsaAdD JwdpwNB1XxuvxQ6XP+DJzJjc9dvAAyqScdKsenzEIs3qdq427tZEfZxrpElMwGYlsjku e42vPxqpCmuwZgxQKKjER6YpXgaGgfxcP+KrtVsupsM9Q7R0ICSQeat4l1GEu/iSDcxE K1A0bzEA9GsZvO1SdzsEK4gtptsrcQCf30DLyb2oPjY0Yt5lpLhcB7Vi2nW6bFF2zjWD bx9NZAb6KWW8IPfgezqTyKAGSMEYgKz8Iw/j3Q+QGyw9xlErVDFYfTjwrgQppEidTpqc KWKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789536738; x=1790141538; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=fskisN0fCV738ZD+8Qg9uE6kvXTWgr+lufjzhZ4Lm/w=; b=2rLc5RzOncTX3h86ztEpeYJEtzeTofyRkSo00C+wMcvmTlPQytc+KlQw590lRl3NcL h/5LBIc96O7AiRgypxl/8m4bPkWkn6wG+JC1oRAnWgd0++Gp800qyh8WhIRmAXl/eo0P nJql/Nas7QtbF3VDlKcold9Pi3fek0j0UP5gTybSE36BqwSH2z/JJrv33V8knuS2mZ/l Cou72jJsKANkjc3xTeDr056cxCPqiarwM4EdT6FTTd5BXrw2OdI4uqMDU3uWM6W5TqJz 82TZKiKuEPWus1uRRBJgYzNG7Jh/lZKIxdFZkPL64hcKKx66A0p66r9J9ArxkD1pn0FA RgGA== X-Forwarded-Encrypted: i=1; AKwUvBzxiuf6M2J316X0xYH5EWbTuPS40vddANLKuOA2BDBBj+lk/Wyyfn6mNnJEsV6VrqojuaRRTegagfM=@lists.xenproject.org X-Gm-Message-State: AFuF++lUB6HEkpoI2RaZmymCk8uzwGxCCKZQUm2rQv82yWzvtuC3Yuwi 7XQbgfu4qyHbEO5DaOgppCW6u3lNg9OlKf3Rg1L8oVccXVX7NIBVKq1h X-Gm-Gg: AYBFou3qHMbPma7QE5YmInLrOmrYGL3/TmmabfsDmWlPtCmvCkgu1jBhiaQdm1BimLS tYYI6+zXvc6d6l/gG+rVKRpdMZvRpuIcoGWbzkTCG65TLy8vDPNkszvk9b6ly5PwrY8ztP8CFiy GIbNXA8L7x7t4ORTM7WLqcv0f3e3A8l2v+hzDu3KVno+ED6cGymJ6RqtFY6i+ElQD/9AmRIc1Mf pvWW6MdhIR1x8vjFTHvaepOHV1exgy1pAspb2vuCS9rzzn19XqNn6duu8dSMQe0pRcc4B2TBKL/ U5cEju9df8DIl2mRqFuYruaSeDLd3IGXnHh0Iq7EBViUWIMfKgH0xrOzev17c5PwKc9NpYpTqi0 ho/tN5sPQqGOfJ4QmhA7EZdZs05+Hcew/b+MMZfriNWwrytRreM7RpvDJbyo4yxPdjy6FYxm/B0 mXev77J4ogE5an1v6fH9qyelGKnS2SZg/mHkkfwosFCf8DdNvIPaZxVD0F6E6P8N6xcBDWN/zAu 0x9V0MxKeAks5sWtDO05QihOU+kcyr0q7mNeHhved35ycZZ X-Received: by 2002:a05:6000:250c:b0:485:c240:20f7 with SMTP id ffacd0b85a97d-4870d26ec7emr1391611f8f.53.1789536737351; Tue, 15 Sep 2026 22:32:17 -0700 (PDT) Message-ID: <84e978a2-ddee-4b24-b0e4-c2ee154c717b@gmail.com> Date: Wed, 16 Sep 2026 07:32:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 27/39] xen/riscv: introduce arch_move_irqs() To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1789536738-FD26A034-2CF3BB2E/10/73395122804 X-purgate-type: spam X-purgate-size: 1885 On 9/14/26 2:07 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> When migrating a vCPU between pCPUs the hypervisor must also migrate >> the associated virtual interrupt state. arch_move_irqs() is the >> per-arch hook called by generic code to trigger that. >> >> Replace the static inline BUG_ON placeholder in asm/irq.h with a real >> implementation in intc.c dispatching through a new move_irqs vintc_ops >> callback. Wire it up in vAPLIC, which delegates to imsic_migrate_vcpu() >> which itself still a stub to be implemented in follow-up patches. >> >> Note that technically ASSERT() in arch_move_irqs() could be skipped as >> it will be anyway NULL pointer dereference (and a trap will occur) if >> something isn't properly initialized but sometimes it is harder to >> find place where NULL pointer derefence happened as it isn't >> guaraunted that all necessary registers will be filled with something >> useful. >> As at the moment I don't find any case when ->move_irqs() could be >> skipped, the check that ->move_irq isn't NULL is added to ASSERT() >> instead of adding "if ( ...->move_irq) vitnc->ops->move_irqs(v)". > > All of these two paragraphs look stale / inapllicable; ... > >> --- a/xen/arch/riscv/intc.c >> +++ b/xen/arch/riscv/intc.c >> @@ -192,3 +192,11 @@ void vintc_ctxt_switch_to(struct vcpu *v) >> >> ops->ctxt_switch_to(v); >> } >> + >> +/* Move vCPU's IRQs from one pCPU to another */ >> +void arch_move_irqs(struct vcpu *v) >> +{ >> + const struct vintc_ops *ops = v->domain->arch.vintc->ops; >> + >> + ops->move_irqs(v); >> +} > > There's no ASSERT() here (and I'd prefer if none was added). With the > description pruned: I will drop last two paragraphs. They are really stale. > Acked-by: Jan Beulich Thanks. ~ Oleksii > > Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 16 05:46:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 05:46:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422358.1647803 (Exim 4.92) (envelope-from ) id 1x6iT6-0001JH-Im; Wed, 16 Sep 2026 05:46:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422358.1647803; Wed, 16 Sep 2026 05:46:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6iT6-0001JA-Fe; Wed, 16 Sep 2026 05:46:04 +0000 Received: by outflank-mailman (input) for mailman id 1422358; Wed, 16 Sep 2026 05:46:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6iT5-0001J4-RV for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 05:46:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6iT4-004UW6-H2 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 07:46:02 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa2d1a-bab6-0a2a0a5309dd-0a2a4509956e-0 for ; Wed, 16 Sep 2026 07:46:02 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa2d19-be1a-0a2a45090019-4a7de18ca918-3 for ; Wed, 16 Sep 2026 07:46:02 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccff31419so4495245e9.3 for ; Tue, 15 Sep 2026 22:46:02 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e83dba8f4sm46382725e9.13.2026.09.15.22.46.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 22:46:01 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789537561; x=1790142361; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7LmDLvn/cNVsmLhARUce9FVScA940nFRVtC+xvvIuZY=; b=bB4ODZBZoEVzB8GPkjRBjeVaNIeEY18GQKlF52IzUnLlmS0fCWgq8+eehxETEStcK2 hN4+RIvRADOnLSeOmJttygEBZINtm2msIpEGXPNY+pVDwvVma172Px0vo16I3sGNHud9 0ggkq5NH5kFo9MTtRwzISuSrv3/ccdNiT9EFW80PfmrmTrAcQ/hmudmMQqs1Yu4sMBaM 4pAGx6rPAasopMjB1wgFohpXpxPVgAu2cRg1U5mae1oAZxC95xE8XM+9J8RtBjMerska RW1ZSO8mDm2gvyAYWbXCKr/RU1e9Kl1bWwif5Yf13672AQw8t16q8JTGArJ/+4rhKSVM XZ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789537561; x=1790142361; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=7LmDLvn/cNVsmLhARUce9FVScA940nFRVtC+xvvIuZY=; b=WABluYEAHMhvOIRgnMrSCcrjZKqaZdYh5OlMJ+bro702XK6cuxHUPQDkFC3deJ/6og 0zZaglDJ6l9nDdv6yQ/+1rKpHWdS5iApDs0s+2r62l618GNsbYktwNd/4gnocfbYp7PI 3vHRp5wuBJbvIH1DMDtjTK8C3R4ZwJf9QwpZx6wqI47xuMTbUMrOp7HBOpw/Ix7ZOAMO WNBLccW992C0X0vAbop+/qoEF6YgNv4KvzvdvzsyH4RagM/E8x1DVOExrfdS0AFGdEKb auqzVpwFWQLExIhfqVKcH9ns9Hn7Xa72STDb02KTRolhqmlfIVlynV7SidIfvrft6cfI sTVg== X-Forwarded-Encrypted: i=1; AKwUvBzRgYBdcIaBlRXn27EroY44hhSW/mUlEDFxXpXBaiPPMZ9HKOfSGJpH2a+l99vMNgVVzzNetc22eR8=@lists.xenproject.org X-Gm-Message-State: AFuF++kolPzFCzm3bVi5YqM78EthJy0Coz9xWIy9Rtrsv/oiPy2Ve7ne TchTz1ettp4lXtN+2cI6itx15VcWfZn7U3dZogOQG8gqXqsX4p3FsM4e3QuXHObhyQ== X-Gm-Gg: AYBFou10mXEkDLC91+p49PZLAp5B/Hqh++tAmSee9Ydj69bWHUom2Okqh1xcWqn6Fec eQ+61mQOs8LlUc7Mcx+hhqEr0ZoAV7HHZPr1k2yRgRtOtuXRU/vWiSKvZsGaGmpZu47t9c61rPK OIr2gkxvVUwN4Y/y2x0/PMXLj/b4+F8VMSTplj98pB5TCWh6SmWnsLg6WnrpQEOAMf7zr85aTQQ Q5S4OhQeAoERN2V2JR4RTpQPCyUqC552CwPpKNdQ9IcUj38MXubzDeeafkRmk9IlIHNF1lU7mJg E/p3I3oMwJRGwUOgqGNp9czt4IolkJKqGEJw2NhlcvyS0qxmfet5AciBMDekzwink4g+fQVd9KU wCjoaQ5AXdU5/ChTLU9CZsL19p9wl7ueQxAy5Wjhx/eJLhGo5YhM0LUvHarfzWN2sNAiLEyqovX YUTf8uN0F+J1yTBhm03LQqS7areHqK4zg+GJzswZs1f0JSjiD8oqtBmKYThlHj4NJwhWqZBvkKS zE= X-Received: by 2002:a05:600c:6290:b0:49d:797:8488 with SMTP id 5b1f17b1804b1-49eac45b9ecmr10956195e9.1.1789537561618; Tue, 15 Sep 2026 22:46:01 -0700 (PDT) Message-ID: <2516df18-b239-4bf8-9f89-f1811515e5d8@suse.com> Date: Wed, 16 Sep 2026 07:45:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update To: Kevin Lampis Cc: "teddy.astie@vates.tech" , "xen-devel@lists.xenproject.org" , Andrew Cooper References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-4-kevin.lampis@citrix.com> <0aedfbad-29ae-4083-89b4-5c662398553d@citrix.com> Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1789537562-BE0C5034-5093CC0B/0/0 X-purgate-type: clean X-purgate-size: 1462 On 15.09.2026 21:37, Kevin Lampis wrote: >> This seems unwise. I think you want a return 0 in the >> paging_write_guest_entry() case because returning the input cannot >> possibly lead to anything good. > > This would make the calling code in mod_l1_entry() more complicated. > > At the moment it shakes out like this > static int mod_l1_entry(l1_pgentry_t *pl1e, > ..., > l1_pgentry_t *ol1e_out) > { > l1_pgentry_t ol1e = l1e_read(pl1e); > ... > ol1e = UPDATE_ENTRY(l1, pl1e, ol1e, ...); > ... > put_page_from_l1e(ol1e, pt_dom); > ... > if ( ol1e_out ) > *ol1e_out = ol1e; > } > > But if UPDATE_ENTRY() sometimes returns 0 depending on what internal path it > takes then we'll need two local ol1e variables, one that is always valid to > give to put_page_from_l1e() and a different one to maybe assign to *ol1e_out. > > When you say "returning the input cannot possibly lead to anything good", the > current version of this patch series actually depends on it. Does it? I've peeked ahead only to the next patch so far, but aren't you going to use the new PTE_UPDATE_SWAP flag? And isn't ol1e_out being non- NULL tied to that new flag being set? Mixing both is what I think Andrew in concerned about. The "flag set, pointer non-NULL" case wouldn't hit the "return 0" path, aiui. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 16 05:56:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 05:56:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422369.1647812 (Exim 4.92) (envelope-from ) id 1x6icf-00038n-Gf; Wed, 16 Sep 2026 05:55:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422369.1647812; Wed, 16 Sep 2026 05:55:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6icf-00038g-Dy; Wed, 16 Sep 2026 05:55:57 +0000 Received: by outflank-mailman (input) for mailman id 1422369; Wed, 16 Sep 2026 05:55:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x6icd-00038a-LJ for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 05:55:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6icc-004Vts-UA for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 07:55:54 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa2f5d-bab6-0a2a0a5309dd-0a2a4507bf50-34 for ; Wed, 16 Sep 2026 07:55:54 +0200 Received: from [74.125.225.78] (helo=mail-wr2-f14.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa2f6a-b4ea-0a2a45070019-4a7de14e802f-3 for ; Wed, 16 Sep 2026 07:55:54 +0200 Received: by mail-wr2-f14.google.com with SMTP id ffacd0b85a97d-482f6350f88so229114f8f.2 for ; Tue, 15 Sep 2026 22:55:54 -0700 (PDT) Received: from [10.250.112.129] (h-213.61.72.154.host.de.colt.net. [213.61.72.154]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf344bfsm4295371f8f.27.2026.09.15.22.55.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2026 22:55:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789538154; x=1790142954; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+buq0Vktqq6Z2yLf/7utD+Vd5iA9eXlDjGCIuWpvIXo=; b=Fd976c4/ULh8Jz1E8rqeTnfzlWLMcwDk1hnhmJqBC/nC7YHAe2Z3x17NSc06N0K3Mc P3U9bpIkQAm+h9kAKFI5TUBcNKIx/6Necb2XBILGqE2A/WQp4SRlraMt7sKaBMZOsog+ O4MDS60mmEzFnAi7YjjqSmDhxkS9HAZxVixknASD/w+tNs0aM5VLZoiM2gkyvEEWsnLy k9oBhi1WYE49RSOjMA1Etur2SQaUd7M8qpQPVfaWeVXI9+pBorgffCyT2s3y67cNh+Bs 1+kqaqwAIL6LB3yumgfLAxS8vjPhzt8zSubQHCcI/ZZ0G8oLeJgZtDJt2WjA52cPAEO+ HohQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789538154; x=1790142954; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=+buq0Vktqq6Z2yLf/7utD+Vd5iA9eXlDjGCIuWpvIXo=; b=tEdkSY2CBrflRJm37fMZBQIhrfbAga0pyF7+dyklgy2gZYseGAZbI0Frn5qJbJ3sZY dUevObMqIaCi5c/ZQ8TlnZG15pAWlCqTas/ct+GQSu/i5ifsn0MdMsFcaMDV3gI9PiPK tAMrBnmQ/Mr2eeMuy2+v6QTJKzyQyWYMnVoc6lhE4kZuc11UAHi45RwLyhPMNmT9rVVg L5Ny2rbN+91zDRCEufrsLKTuKdkIrqdIvHQRnhU36jtukikhgD12YnYFm0XrFTyPNj/w e6ZcpOK+zmIq4FU/YCME8IIc9W2l0G+DVhbl7X6WGAAwwukCQXm4Q+w3tGJ/gOHI2s9D iRJg== X-Forwarded-Encrypted: i=1; AKwUvBxHmEyC60NspH+On4JG9nqs8sPgX0jrbCYWEKXJ0oJA/RN5nGyjvnDqUviKzinSCDIPtagfuI9456k=@lists.xenproject.org X-Gm-Message-State: AFuF++l/feUvbbn8N6t31Ye0EqjsfJr+A+seuTqVpLGO5rE/DJCMtUte dVOajRs5kQcNrmD9BzoiY0Rhw83gBpxG9+sm4wWVji0DLqa9FLU1QoaX X-Gm-Gg: AYBFou1h46kLObkom1kEQ6JYhV9GaMeD37lPHcqHg/NwL0HBvvlh1okCiR9J78OyIqj oTKXZVTLTq86AMphv0PaxjSBA0JJOYFPGqY7OwXSbjyoQq3bi0IwhEx4KgLyTSD9sZUhWYgChAd oXGp6m1n4UvVI4ySU49uRq8/QnZdugC0JvZfuUVm14Sr48PCgJp1OMUccYywlVXvPDzjdJTq4pd gPpCl+HMRJnI3f9YkehSyRBUYPX+M+LVxulfsnUnRX4EccaLOZ8+i3TGnSZOtH4MnhYkdBUCQh/ x8lS1NVlOggnDl1cmjiFaMHz+ea2lq2gR0OGkK4LKVuKEGwETHx/xN1/sgS1sJgzyN79ubthCkY qHi42lFzAY8x965HM/CyY+jn9BFquBaGL14rj4O2gnYui6OAz7QAMk4RKfym6gy+Wbm0Akq2/TH /g+IlUpOTTMw0dkPqgcKPDn3gV7+mOaRsYACaQOgAKOqxCwUU/2DF7NuOKR7Xrf4JHz98XRvU2j atv9GANbvOnbNetHYbs31WOSTiInBlssNTVarOiyUy/dj+P X-Received: by 2002:a05:6000:3110:b0:487:952:bb75 with SMTP id ffacd0b85a97d-4870cf0a036mr1586757f8f.7.1789538154205; Tue, 15 Sep 2026 22:55:54 -0700 (PDT) Message-ID: Date: Wed, 16 Sep 2026 07:55:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789538154-A74D3AE4-D01EA2A2/10/73395122804 X-purgate-type: spam X-purgate-size: 2170 On 9/14/26 2:12 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> The IMSIC vsfile mapping is performed in continue_new_vcpu(), since the >> target pCPU must be known at that point. It is therefore possible for >> imsic_migrate_vcpu() to be called before continue_new_vcpu() has >> executed, in which case v->arch.last_pcpu is NR_CPUS and there is nothing >> to migrate. >> >> Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard >> against silent incorrect behaviour or unexpected panics in guest VMs until >> the function is fully implemented. > > This doesn't adequately describe the change made: The BUG_ON() was already > there. Agree, it should be just: Keep the BUG_ON() at the end of the function until imsic_migrate_vcpu() is fully implemented, to avoid ending up with a vCPU which isn't fully migrated to the new IMSIC interrupt file. > >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, >> >> void imsic_migrate_vcpu(struct vcpu *v) >> { >> + /* >> + * The scheduler can mark a freshly created vCPU's unit as migrated and >> + * invoke this before the vCPU has ever run (see the migrated branch in >> + * schedule()). No need to do migration for such vCPUs as they aren't fully >> + * initialized (for example, context_switch() will be called after >> + * imsic_migrate_vcpu()). >> + */ >> + if ( v->arch.last_cpu == NR_CPUS ) > > May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a > good sentinel. If we/you decided to switch to ~0, >= here would continue to > be correct. I agree with >= but I am not quite sure that I fully understand what is wrong with NR_CPUS. We have for example the following: static inline unsigned int smp_processor_id(void) { unsigned int id = tp->processor_id; BUG_ON(id >= NR_CPUS); return id; } So it is guaranteed that NR_CPUS what be used as cpu id and so it still could be considered as a good sentinel. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 16 06:24:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 06:24:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422382.1647821 (Exim 4.92) (envelope-from ) id 1x6j46-0007iI-KV; Wed, 16 Sep 2026 06:24:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422382.1647821; Wed, 16 Sep 2026 06:24:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6j46-0007iB-GO; Wed, 16 Sep 2026 06:24:18 +0000 Received: by outflank-mailman (input) for mailman id 1422382; Wed, 16 Sep 2026 06:24:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6j45-0007i5-6U for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 06:24:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6j43-006k2S-Hj for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 08:24:15 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa3602-8faa-0a2a0a5109dd-0a2a4503a758-38 for ; Wed, 16 Sep 2026 08:24:15 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa360f-fae8-0a2a45030019-c387df83d006-3 for ; Wed, 16 Sep 2026 08:24:15 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 9A7501FE21; Wed, 16 Sep 2026 06:24:06 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CC8D9136D1; Wed, 16 Sep 2026 06:24:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id nLZ5HgU2qmrNRQAAD6G6ig (envelope-from ); Wed, 16 Sep 2026 06:24:05 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de"; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789539850; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=+wG3urIqyzvutvhz3o+cV/d3V7dF1C3I+4csedxlzqA=; b=FIez1earGLDGi7AqR01AuARvOdlajBp+fRMJJGGeMnoTq9dvnv8hE+2+gQMjWWcpKgyOLE Rku1ObTlPRpO9d3QhfYq3w5xFrQ9UJdihQAgaVmQguhkUR0wsXjPhFE/I81McJ8toPFvxd LloqQsKoLaB0OKmvT0WyzdFoTqBbWds= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789539850; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=+wG3urIqyzvutvhz3o+cV/d3V7dF1C3I+4csedxlzqA=; b=RjL6l8c7EsdgERq9co40eQ+Wc02hB5lJOzclY2Lh8ZiNcUBip/Y5z1vXt3Nx/OeT79fF/y O2vIt8n7NWHc+ZDQ== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=HV1v3uyF; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=7fiYrcF9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789539846; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=+wG3urIqyzvutvhz3o+cV/d3V7dF1C3I+4csedxlzqA=; b=HV1v3uyFjN5zL4NWzhwKMUjp7TwlFd4m1QaG4vFm2grNfzrds33nWaEFJlTtQTTAl4D4GA +/JjHPWs1MSVm5S4zSpKQSInBbt/Urj+jlb/fyMVXUDCkKku6Eqp/5k7pUSYXFx+YtZ/Yv rpL8xVbpMnduyVg/dTUJUMNUFECyXN8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789539846; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=+wG3urIqyzvutvhz3o+cV/d3V7dF1C3I+4csedxlzqA=; b=7fiYrcF9r6CsxpTC7KA1gcliQjuqfJKzfk9I74tLP5t4YESS86eerA8R6qzTH0zULKC6v3 HchgkWW6EGZZFyBQ== Message-ID: Date: Wed, 16 Sep 2026 08:24:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] drm/imx/lcdc: avoid duplicate clk_per enable To: Ze Huang , Alexey Brodkin , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , Joel Stanley , Andrew Jeffery , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Linus Walleij , Hans de Goede , Alex Lanzano , Oleksandr Andrushchenko , Philipp Zabel , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Marian Cichy Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org References: <20260727-drm-simple-kms-removal-v3-0-de36e534f7a1@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-1-de36e534f7a1@oss.qualcomm.com> Content-Language: en-US From: Thomas Zimmermann Autocrypt: addr=tzimmermann@suse.de; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c= In-Reply-To: <20260727-drm-simple-kms-removal-v3-1-de36e534f7a1@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 9A7501FE21 X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FREEMAIL_TO(0.00)[oss.qualcomm.com,synopsys.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch,jms.id.au,codeconstruct.com.au,nxp.com,pengutronix.de,epam.com]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_TWELVE(0.00)[25]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:url,suse.de:dkim,suse.de:email,suse.de:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,qualcomm.com:email] X-Spam-Flag: NO X-Spam-Score: -3.01 X-purgate-ID: tlsNG-33051d/1789539855-6D0D94E9-1F97B7B5/0/0 X-purgate-type: clean X-purgate-size: 2119 Hi Am 26.07.26 um 21:42 schrieb Ze Huang: > The simple-KMS helper calls the pipe update after enabling the CRTC. > On an enable commit, imx_lcdc_pipe_enable() already programs the > mode and enables clk_per. The following pipe update sees the plane move > from no CRTC to the active CRTC, treats it as a mode update, and calls > imx_lcdc_update_hw_registers() again. > > That second call has no old CRTC state to disable clk_per first, but it > enables clk_per again at the end. The disable path only drops one > reference, leaving clk_per enabled after each on/off cycle. > > Skip the register update from the pipe update path when the CRTC already > needs a modeset. The enable path has already programmed the hardware for > that commit; keep the event handling in pipe update unchanged. That seems reasonable. Once the driver uses regular DRM helpers instead of simple_kms, it can all be untangled and this test won't be necessary any longer. > > Fixes: c87e859cdeb5 ("drm/imx/lcdc: Implement DRM driver for imx25") > Signed-off-by: Ze Huang Acked-by: Thomas Zimmermann > --- > drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > index f52832b43aca..81024f7d9e96 100644 > --- a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > +++ b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > @@ -311,7 +311,8 @@ static void imx_lcdc_pipe_update(struct drm_simple_display_pipe *pipe, > else if (old_crtc != crtc) > mode_changed = true; > > - imx_lcdc_update_hw_registers(pipe, old_state, mode_changed); > + if (!drm_atomic_crtc_needs_modeset(crtc->state)) > + imx_lcdc_update_hw_registers(pipe, old_state, mode_changed); > > if (event) { > crtc->state->event = NULL; > -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg) From xen-devel-bounces@lists.xenproject.org Wed Sep 16 06:50:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 06:50:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422397.1647831 (Exim 4.92) (envelope-from ) id 1x6jTX-0003Fx-JL; Wed, 16 Sep 2026 06:50:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422397.1647831; Wed, 16 Sep 2026 06:50:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6jTX-0003Fp-El; Wed, 16 Sep 2026 06:50:35 +0000 Received: by outflank-mailman (input) for mailman id 1422397; Wed, 16 Sep 2026 06:50:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6jTV-0003Fj-Jj for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 06:50:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6jTU-00GFEa-FN for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 08:50:32 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa3c27-bab6-0a2a0a5309dd-0a2a4505bdaa-26 for ; Wed, 16 Sep 2026 08:50:32 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa3c38-4cb1-0a2a45050019-c387df83d44a-3 for ; Wed, 16 Sep 2026 08:50:32 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 38C6A1FDD2; Wed, 16 Sep 2026 06:50:23 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 3ED2C136D1; Wed, 16 Sep 2026 06:50:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id K2fRBy48qmqIYgAAD6G6ig (envelope-from ); Wed, 16 Sep 2026 06:50:22 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de"; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789541427; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=q1Rlto9SnJgRaHJraIYWJFcfagZYqIMFP0BBB/sf7fE=; b=TZ/zq1RnlM2xpYQOmH/HwJkp52sY0SEiteMePDhTlwWGfBUZHpTyHScFA59Y81pfwVw/EI 5TGLA4NaOat3FNyV3fDgwLj5DgPHZr7rgw+ppJSdcOJHfAJBtyvL88dmmBLYnim0IMjT3J l77GTDr9t23y9GiGER02VBh3aQh2djA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789541427; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=q1Rlto9SnJgRaHJraIYWJFcfagZYqIMFP0BBB/sf7fE=; b=e5N4EcVW7vOCcAoIIiYm3cIS8BaVJB0Mbo77IPyji6ZoQAZnZQpJ77LI7UNWhAvGBMgMcN OKIq7Dtdr70o0IBA== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="0/M4VYRi"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=cd3MI51R DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789541423; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=q1Rlto9SnJgRaHJraIYWJFcfagZYqIMFP0BBB/sf7fE=; b=0/M4VYRiPlBIQlmFuj1q2+uA1pXiWQ9A2HAy2vIXEEcrush/tlyFGsE7Xq0f+w6oU0y72w 0BB+Kh+6eRrssN2U3/VBty0LYeYIvQ8RdrPEhWdGbCXCLfb9ZVUT0k8b0oyGu10Xj0CyvH 0+57HrK3SBPeRoyTFFffmW3EIb0OQ3Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789541423; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=q1Rlto9SnJgRaHJraIYWJFcfagZYqIMFP0BBB/sf7fE=; b=cd3MI51RD6FudCt6pZ5qioa6wu2F0gZlMJFOQ3lZ/z2GekKGtjSos20r1Jd3JSxsPv7wIt WpdvOtYiAR/zABBg== Message-ID: <8e4c84be-5c89-4d84-adda-aad4c7de0c8a@suse.de> Date: Wed, 16 Sep 2026 08:50:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] drm/imx: replace struct drm_simple_display_pipe with regular atomic helpers To: Ze Huang , Alexey Brodkin , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , Joel Stanley , Andrew Jeffery , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Linus Walleij , Hans de Goede , Alex Lanzano , Oleksandr Andrushchenko , Philipp Zabel , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Marian Cichy Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org References: <20260727-drm-simple-kms-removal-v3-0-de36e534f7a1@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-2-de36e534f7a1@oss.qualcomm.com> Content-Language: en-US From: Thomas Zimmermann Autocrypt: addr=tzimmermann@suse.de; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c= In-Reply-To: <20260727-drm-simple-kms-removal-v3-2-de36e534f7a1@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 38C6A1FDD2 X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; URIBL_BLOCKED(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:url,qualcomm.com:email,suse.de:dkim,suse.de:mid,bootlin.com:url,pengutronix.de:email,i.mx:url]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FREEMAIL_TO(0.00)[oss.qualcomm.com,synopsys.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch,jms.id.au,codeconstruct.com.au,nxp.com,pengutronix.de,epam.com]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_TWELVE(0.00)[25]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[bootlin.com:url,pengutronix.de:email,i.mx:url,suse.com:url,qualcomm.com:email,suse.de:dkim,suse.de:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Spam-Flag: NO X-Spam-Score: -3.01 X-purgate-ID: tlsNG-c201ff/1789541432-F4CA02A1-FE7440C3/0/0 X-purgate-type: clean X-purgate-size: 19176 Hi Am 26.07.26 um 21:42 schrieb Ze Huang: > Convert i.MX LCDC to explicit primary plane, CRTC and encoder objects. > Keep no-scaling plane check and GEM framebuffer prepare callback from > simple-KMS path. > > Wire the vblank lifecycle explicitly with CRTC vblank callbacks and > drm_crtc_vblank_on()/drm_crtc_vblank_off(). Use the old CRTC state in the > disable path for clock unwinding so the clock reference count remains > paired with the previous active state. > > Signed-off-by: Ze Huang > --- > drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 264 ++++++++++++++++++++++++++---------- > 1 file changed, 190 insertions(+), 74 deletions(-) > > diff --git a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > index 81024f7d9e96..4835f01954f7 100644 > --- a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > +++ b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > @@ -2,6 +2,7 @@ > // SPDX-FileCopyrightText: 2020 Marian Cichy > > #include > +#include > #include > #include > #include > @@ -14,9 +15,9 @@ > #include > #include > #include > +#include > #include > #include > -#include > #include > #include > #include > @@ -102,7 +103,9 @@ > > struct imx_lcdc { > struct drm_device drm; > - struct drm_simple_display_pipe pipe; > + struct drm_plane plane; > + struct drm_crtc crtc; > + struct drm_encoder encoder; > struct drm_connector *connector; > void __iomem *base; > > @@ -135,14 +138,15 @@ static unsigned int imx_lcdc_get_format(unsigned int drm_format) > } > } > > -static void imx_lcdc_update_hw_registers(struct drm_simple_display_pipe *pipe, > - struct drm_plane_state *old_state, > +static void imx_lcdc_update_hw_registers(struct drm_crtc *crtc, > + struct drm_crtc_state *old_crtc_state, > + struct drm_crtc_state *new_crtc_state, > + struct drm_plane_state *new_state, > bool mode_set) > { > - struct drm_crtc *crtc = &pipe->crtc; > - struct drm_plane_state *new_state = pipe->plane.state; > + struct imx_lcdc *lcdc = imx_lcdc_from_drmdev(crtc->dev); > + const struct drm_display_mode *mode = &new_crtc_state->mode; > struct drm_framebuffer *fb = new_state->fb; > - struct imx_lcdc *lcdc = imx_lcdc_from_drmdev(pipe->crtc.dev); > u32 lpcr, lvcr, lhcr; > u32 framesize; > dma_addr_t addr; > @@ -155,24 +159,24 @@ static void imx_lcdc_update_hw_registers(struct drm_simple_display_pipe *pipe, > return; > > /* Disable PER clock to make register write possible */ > - if (old_state && old_state->crtc && old_state->crtc->enabled) > + if (old_crtc_state && old_crtc_state->enable) > clk_disable_unprepare(lcdc->clk_per); > > /* Framesize */ > - framesize = FIELD_PREP(IMX21LCDC_LSR_XMAX, crtc->mode.hdisplay >> 4) | > - FIELD_PREP(IMX21LCDC_LSR_YMAX, crtc->mode.vdisplay); > + framesize = FIELD_PREP(IMX21LCDC_LSR_XMAX, mode->hdisplay >> 4) | > + FIELD_PREP(IMX21LCDC_LSR_YMAX, mode->vdisplay); > writel(framesize, lcdc->base + IMX21LCDC_LSR); > > /* HSYNC */ > - lhcr = FIELD_PREP(IMX21LCDC_LHCR_HFPORCH, crtc->mode.hsync_start - crtc->mode.hdisplay - 1) | > - FIELD_PREP(IMX21LCDC_LHCR_HWIDTH, crtc->mode.hsync_end - crtc->mode.hsync_start - 1) | > - FIELD_PREP(IMX21LCDC_LHCR_HBPORCH, crtc->mode.htotal - crtc->mode.hsync_end - 3); > + lhcr = FIELD_PREP(IMX21LCDC_LHCR_HFPORCH, mode->hsync_start - mode->hdisplay - 1) | > + FIELD_PREP(IMX21LCDC_LHCR_HWIDTH, mode->hsync_end - mode->hsync_start - 1) | > + FIELD_PREP(IMX21LCDC_LHCR_HBPORCH, mode->htotal - mode->hsync_end - 3); > writel(lhcr, lcdc->base + IMX21LCDC_LHCR); > > /* VSYNC */ > - lvcr = FIELD_PREP(IMX21LCDC_LVCR_VFPORCH, crtc->mode.vsync_start - crtc->mode.vdisplay) | > - FIELD_PREP(IMX21LCDC_LVCR_VWIDTH, crtc->mode.vsync_end - crtc->mode.vsync_start) | > - FIELD_PREP(IMX21LCDC_LVCR_VBPORCH, crtc->mode.vtotal - crtc->mode.vsync_end); > + lvcr = FIELD_PREP(IMX21LCDC_LVCR_VFPORCH, mode->vsync_start - mode->vdisplay) | > + FIELD_PREP(IMX21LCDC_LVCR_VWIDTH, mode->vsync_end - mode->vsync_start) | > + FIELD_PREP(IMX21LCDC_LVCR_VBPORCH, mode->vtotal - mode->vsync_end); > writel(lvcr, lcdc->base + IMX21LCDC_LVCR); > > lpcr = readl(lcdc->base + IMX21LCDC_LPCR); > @@ -184,19 +188,20 @@ static void imx_lcdc_update_hw_registers(struct drm_simple_display_pipe *pipe, > writel(new_state->fb->pitches[0] / 4, lcdc->base + IMX21LCDC_LVPWR); > > /* Enable PER clock */ > - if (new_state->crtc->enabled) > + if (new_crtc_state->enable) > clk_prepare_enable(lcdc->clk_per); > } > > -static void imx_lcdc_pipe_enable(struct drm_simple_display_pipe *pipe, > - struct drm_crtc_state *crtc_state, > - struct drm_plane_state *plane_state) > +static void imx_lcdc_crtc_helper_atomic_enable(struct drm_crtc *crtc, > + struct drm_atomic_commit *commit) > { > int ret; > int clk_div; > int bpp; > - struct imx_lcdc *lcdc = imx_lcdc_from_drmdev(pipe->crtc.dev); > - struct drm_display_mode *mode = &pipe->crtc.mode; > + struct imx_lcdc *lcdc = imx_lcdc_from_drmdev(crtc->dev); > + struct drm_crtc_state *cstate = drm_atomic_get_new_crtc_state(commit, crtc); > + struct drm_plane_state *pstate = drm_atomic_get_new_plane_state(commit, &lcdc->plane); > + struct drm_display_mode *mode = &cstate->mode; > struct drm_display_info *disp_info = &lcdc->connector->display_info; > const int hsync_pol = (mode->flags & DRM_MODE_FLAG_PHSYNC) ? 0 : 1; > const int vsync_pol = (mode->flags & DRM_MODE_FLAG_PVSYNC) ? 0 : 1; > @@ -207,7 +212,7 @@ static void imx_lcdc_pipe_enable(struct drm_simple_display_pipe *pipe, > > clk_div = DIV_ROUND_CLOSEST_ULL(clk_get_rate(lcdc->clk_per), > mode->clock * 1000); > - bpp = imx_lcdc_get_format(plane_state->fb->format->format); > + bpp = imx_lcdc_get_format(pstate->fb->format->format); > > writel(FIELD_PREP(IMX21LCDC_LPCR_PCD, clk_div - 1) | > FIELD_PREP(IMX21LCDC_LPCR_LPPOL, hsync_pol) | > @@ -231,40 +236,46 @@ static void imx_lcdc_pipe_enable(struct drm_simple_display_pipe *pipe, > > ret = clk_prepare_enable(lcdc->clk_ipg); > if (ret) { > - dev_err(pipe->crtc.dev->dev, "Cannot enable ipg clock: %pe\n", ERR_PTR(ret)); > + dev_err(crtc->dev->dev, "Cannot enable ipg clock: %pe\n", ERR_PTR(ret)); > return; > } > ret = clk_prepare_enable(lcdc->clk_ahb); > if (ret) { > - dev_err(pipe->crtc.dev->dev, "Cannot enable ahb clock: %pe\n", ERR_PTR(ret)); > + dev_err(crtc->dev->dev, "Cannot enable ahb clock: %pe\n", ERR_PTR(ret)); > > clk_disable_unprepare(lcdc->clk_ipg); > > return; > } > > - imx_lcdc_update_hw_registers(pipe, NULL, true); > + imx_lcdc_update_hw_registers(crtc, NULL, cstate, pstate, true); > > /* Enable VBLANK Interrupt */ > writel(INTR_EOF, lcdc->base + IMX21LCDC_LIER); > + > + drm_crtc_vblank_on(crtc); > } > > -static void imx_lcdc_pipe_disable(struct drm_simple_display_pipe *pipe) > +static void imx_lcdc_crtc_helper_atomic_disable(struct drm_crtc *crtc, > + struct drm_atomic_commit *commit) > { > - struct imx_lcdc *lcdc = imx_lcdc_from_drmdev(pipe->crtc.dev); > - struct drm_crtc *crtc = &lcdc->pipe.crtc; > + struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(commit, crtc); > + struct drm_crtc_state *new_crtc_state = drm_atomic_get_new_crtc_state(commit, crtc); > + struct imx_lcdc *lcdc = imx_lcdc_from_drmdev(crtc->dev); > struct drm_pending_vblank_event *event; > > + drm_crtc_vblank_off(crtc); > + > clk_disable_unprepare(lcdc->clk_ahb); > clk_disable_unprepare(lcdc->clk_ipg); > > - if (pipe->crtc.enabled) > + if (old_crtc_state->enable) > clk_disable_unprepare(lcdc->clk_per); > > spin_lock_irq(&lcdc->drm.event_lock); > - event = crtc->state->event; > + event = new_crtc_state->event; > if (event) { > - crtc->state->event = NULL; > + new_crtc_state->event = NULL; > drm_crtc_send_vblank_event(crtc, event); > } > spin_unlock_irq(&lcdc->drm.event_lock); > @@ -273,66 +284,151 @@ static void imx_lcdc_pipe_disable(struct drm_simple_display_pipe *pipe) > writel(0, lcdc->base + IMX21LCDC_LIER); > } > > -static int imx_lcdc_pipe_check(struct drm_simple_display_pipe *pipe, > - struct drm_plane_state *plane_state, > - struct drm_crtc_state *crtc_state) > +static int imx_lcdc_crtc_helper_atomic_check(struct drm_crtc *crtc, > + struct drm_atomic_commit *commit) > { > + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(commit, crtc); > + struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(commit, crtc); > const struct drm_display_mode *mode = &crtc_state->mode; > - const struct drm_display_mode *old_mode = &pipe->crtc.state->mode; > + const struct drm_display_mode *old_mode = &old_crtc_state->mode; > + int ret; > > - if (mode->hdisplay < LCDC_MIN_XRES || mode->hdisplay > LCDC_MAX_XRES || > - mode->vdisplay < LCDC_MIN_YRES || mode->vdisplay > LCDC_MAX_YRES || > - mode->hdisplay % 0x10) { /* must be multiple of 16 */ > - drm_err(pipe->crtc.dev, "unsupported display mode (%u x %u)\n", > + if (crtc_state->enable) { > + ret = drm_atomic_helper_check_crtc_primary_plane(crtc_state); > + if (ret) > + return ret; > + } > + > + if (crtc_state->enable && > + (mode->hdisplay < LCDC_MIN_XRES || mode->hdisplay > LCDC_MAX_XRES || > + mode->vdisplay < LCDC_MIN_YRES || mode->vdisplay > LCDC_MAX_YRES || > + mode->hdisplay % 0x10)) { /* must be multiple of 16 */ > + drm_err(crtc->dev, "unsupported display mode (%u x %u)\n", > mode->hdisplay, mode->vdisplay); > return -EINVAL; > } > > - crtc_state->mode_changed = > - old_mode->hdisplay != mode->hdisplay || > - old_mode->vdisplay != mode->vdisplay; > + if (old_mode->hdisplay != mode->hdisplay || > + old_mode->vdisplay != mode->vdisplay) > + crtc_state->mode_changed = true; > > - return 0; > + return drm_atomic_add_affected_planes(commit, crtc); > } > > -static void imx_lcdc_pipe_update(struct drm_simple_display_pipe *pipe, > - struct drm_plane_state *old_state) > +static void imx_lcdc_plane_helper_atomic_update(struct drm_plane *plane, > + struct drm_atomic_commit *commit) > { > - struct drm_crtc *crtc = &pipe->crtc; > - struct drm_pending_vblank_event *event = crtc->state->event; > - struct drm_plane_state *new_state = pipe->plane.state; > + struct drm_plane_state *old_state = drm_atomic_get_old_plane_state(commit, plane); > + struct drm_plane_state *new_state = drm_atomic_get_new_plane_state(commit, plane); > + struct drm_crtc *crtc = new_state->crtc; > + struct drm_crtc_state *old_crtc_state = NULL; > + struct drm_crtc_state *new_crtc_state; > struct drm_framebuffer *fb = new_state->fb; > struct drm_framebuffer *old_fb = old_state->fb; > struct drm_crtc *old_crtc = old_state->crtc; > bool mode_changed = false; > > + if (!fb || !crtc) > + return; > + > + if (old_crtc) > + old_crtc_state = drm_atomic_get_old_crtc_state(commit, old_crtc); > + > + new_crtc_state = drm_atomic_get_new_crtc_state(commit, crtc); > + if (!new_crtc_state) > + return; > + > if (old_fb && old_fb->format != fb->format) > mode_changed = true; > else if (old_crtc != crtc) > mode_changed = true; > > - if (!drm_atomic_crtc_needs_modeset(crtc->state)) > - imx_lcdc_update_hw_registers(pipe, old_state, mode_changed); > + if (!drm_atomic_crtc_needs_modeset(new_crtc_state)) > + imx_lcdc_update_hw_registers(crtc, old_crtc_state, new_crtc_state, > + new_state, mode_changed); > +} > > - if (event) { > - crtc->state->event = NULL; > +static int imx_lcdc_plane_helper_atomic_check(struct drm_plane *plane, > + struct drm_atomic_commit *commit) > +{ > + struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(commit, plane); > + struct drm_crtc_state *crtc_state = NULL; > + > + if (plane_state->crtc) { > + crtc_state = drm_atomic_get_crtc_state(commit, plane_state->crtc); > + if (IS_ERR(crtc_state)) > + return PTR_ERR(crtc_state); > + } > > - spin_lock_irq(&crtc->dev->event_lock); > + return drm_atomic_helper_check_plane_state(plane_state, crtc_state, > + DRM_PLANE_NO_SCALING, > + DRM_PLANE_NO_SCALING, > + false, false); > +} > > - if (crtc->state->active && drm_crtc_vblank_get(crtc) == 0) > - drm_crtc_arm_vblank_event(crtc, event); > - else > - drm_crtc_send_vblank_event(crtc, event); > +static const struct drm_plane_helper_funcs imx_lcdc_plane_helper_funcs = { > + .prepare_fb = drm_gem_plane_helper_prepare_fb, > + .atomic_check = imx_lcdc_plane_helper_atomic_check, > + .atomic_update = imx_lcdc_plane_helper_atomic_update, > +}; > > - spin_unlock_irq(&crtc->dev->event_lock); > - } > +static const struct drm_plane_funcs imx_lcdc_plane_funcs = { > + .update_plane = drm_atomic_helper_update_plane, > + .disable_plane = drm_atomic_helper_disable_plane, > + .destroy = drm_plane_cleanup, > + .reset = drm_atomic_helper_plane_reset, > + .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state, > + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, > +}; > + > +static void imx_lcdc_crtc_helper_atomic_flush(struct drm_crtc *crtc, > + struct drm_atomic_commit *commit) > +{ > + struct drm_crtc_state *new_crtc_state = drm_atomic_get_new_crtc_state(commit, crtc); > + struct drm_pending_vblank_event *event = new_crtc_state->event; > + > + if (!event) > + return; > + > + new_crtc_state->event = NULL; > + > + spin_lock_irq(&crtc->dev->event_lock); > + if (new_crtc_state->active && drm_crtc_vblank_get(crtc) == 0) > + drm_crtc_arm_vblank_event(crtc, event); > + else > + drm_crtc_send_vblank_event(crtc, event); > + spin_unlock_irq(&crtc->dev->event_lock); > } Please use drm_crtc_vblank_atomic_flush(). [1] [1] https://elixir.bootlin.com/linux/v7.2.5/source/drivers/gpu/drm/drm_vblank_helper.c#L51 Best regards Thomas > > -static const struct drm_simple_display_pipe_funcs imx_lcdc_pipe_funcs = { > - .enable = imx_lcdc_pipe_enable, > - .disable = imx_lcdc_pipe_disable, > - .check = imx_lcdc_pipe_check, > - .update = imx_lcdc_pipe_update, > +static const struct drm_crtc_helper_funcs imx_lcdc_crtc_helper_funcs = { > + .atomic_check = imx_lcdc_crtc_helper_atomic_check, > + .atomic_enable = imx_lcdc_crtc_helper_atomic_enable, > + .atomic_disable = imx_lcdc_crtc_helper_atomic_disable, > + .atomic_flush = imx_lcdc_crtc_helper_atomic_flush, > +}; > + > +static int imx_lcdc_crtc_enable_vblank(struct drm_crtc *crtc) > +{ > + return 0; > +} > + > +static void imx_lcdc_crtc_disable_vblank(struct drm_crtc *crtc) > +{ > +} > + > +static const struct drm_crtc_funcs imx_lcdc_crtc_funcs = { > + .reset = drm_atomic_helper_crtc_reset, > + .destroy = drm_crtc_cleanup, > + .set_config = drm_atomic_helper_set_config, > + .page_flip = drm_atomic_helper_page_flip, > + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, > + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state, > + .enable_vblank = imx_lcdc_crtc_enable_vblank, > + .disable_vblank = imx_lcdc_crtc_disable_vblank, > +}; > + > +static const struct drm_encoder_funcs imx_lcdc_encoder_funcs = { > + .destroy = drm_encoder_cleanup, > }; > > static const struct drm_mode_config_funcs imx_lcdc_mode_config_funcs = { > @@ -370,7 +466,7 @@ MODULE_DEVICE_TABLE(of, imx_lcdc_of_dev_id); > static irqreturn_t imx_lcdc_irq_handler(int irq, void *arg) > { > struct imx_lcdc *lcdc = arg; > - struct drm_crtc *crtc = &lcdc->pipe.crtc; > + struct drm_crtc *crtc = &lcdc->crtc; > unsigned int status; > > status = readl(lcdc->base + IMX21LCDC_LISR); > @@ -388,6 +484,9 @@ static int imx_lcdc_probe(struct platform_device *pdev) > struct imx_lcdc *lcdc; > struct drm_device *drm; > struct drm_bridge *bridge; > + struct drm_plane *plane; > + struct drm_crtc *crtc; > + struct drm_encoder *encoder; > int irq; > int ret; > struct device *dev = &pdev->dev; > @@ -429,23 +528,40 @@ static int imx_lcdc_probe(struct platform_device *pdev) > if (ret) > return dev_err_probe(dev, ret, "Cannot initialize mode configuration structure\n"); > > - /* CRTC, Plane, Encoder */ > - ret = drm_simple_display_pipe_init(drm, &lcdc->pipe, > - &imx_lcdc_pipe_funcs, > - imx_lcdc_formats, > - ARRAY_SIZE(imx_lcdc_formats), NULL, NULL); > + plane = &lcdc->plane; > + ret = drm_universal_plane_init(drm, plane, 0, > + &imx_lcdc_plane_funcs, > + imx_lcdc_formats, > + ARRAY_SIZE(imx_lcdc_formats), > + NULL, > + DRM_PLANE_TYPE_PRIMARY, NULL); > + if (ret < 0) > + return dev_err_probe(drm->dev, ret, "Cannot initialize primary plane\n"); > + drm_plane_helper_add(plane, &imx_lcdc_plane_helper_funcs); > + > + crtc = &lcdc->crtc; > + ret = drm_crtc_init_with_planes(drm, crtc, plane, NULL, > + &imx_lcdc_crtc_funcs, NULL); > + if (ret < 0) > + return dev_err_probe(drm->dev, ret, "Cannot initialize CRTC\n"); > + drm_crtc_helper_add(crtc, &imx_lcdc_crtc_helper_funcs); > + > + encoder = &lcdc->encoder; > + ret = drm_encoder_init(drm, encoder, &imx_lcdc_encoder_funcs, > + DRM_MODE_ENCODER_NONE, NULL); > if (ret < 0) > - return dev_err_probe(drm->dev, ret, "Cannot setup simple display pipe\n"); > + return dev_err_probe(drm->dev, ret, "Cannot initialize encoder\n"); > + encoder->possible_crtcs = drm_crtc_mask(crtc); > > ret = drm_vblank_init(drm, drm->mode_config.num_crtc); > if (ret < 0) > return dev_err_probe(drm->dev, ret, "Failed to initialize vblank\n"); > > - ret = drm_bridge_attach(&lcdc->pipe.encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR); > + ret = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR); > if (ret) > return dev_err_probe(drm->dev, ret, "Cannot attach bridge\n"); > > - lcdc->connector = drm_bridge_connector_init(drm, &lcdc->pipe.encoder); > + lcdc->connector = drm_bridge_connector_init(drm, encoder); > if (IS_ERR(lcdc->connector)) > return dev_err_probe(drm->dev, PTR_ERR(lcdc->connector), "Cannot init bridge connector\n"); > > -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg) From xen-devel-bounces@lists.xenproject.org Wed Sep 16 07:47:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 07:47:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422426.1647839 (Exim 4.92) (envelope-from ) id 1x6kMD-0001gP-MN; Wed, 16 Sep 2026 07:47:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422426.1647839; Wed, 16 Sep 2026 07:47:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6kMD-0001gI-Is; Wed, 16 Sep 2026 07:47:05 +0000 Received: by outflank-mailman (input) for mailman id 1422426; Wed, 16 Sep 2026 07:47:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6kMC-0001gC-FH for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 07:47:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6kMB-00FgqG-CS for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 09:47:03 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa496f-2eae-0a2a0a5409dd-0a2a4508b68c-22 for ; Wed, 16 Sep 2026 09:47:03 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa4976-f659-0a2a45080019-ac6904fe86c6-3 for ; Wed, 16 Sep 2026 09:47:03 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 685B66020C; Wed, 16 Sep 2026 07:47:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8BAF61F000FF; Wed, 16 Sep 2026 07:47:00 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789544821; bh=0joaZXkFzvHsMPXxvnQrk/bZSSnjHuyjzDW4e7lSU7g=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Nc+M2tZwVJsixOM56NLEFYEzQkaMNDIiByci6H3lph5WSy/sEnP/SvbP6NTlniikG Ewmocn8mbkhzZl9xv2kVMDBr9tzV6fTxVdxlVlUs7jGzcaKO2mFJVVhpduKi44oong sHtZYmooyLnIcMDIU55vEXNcmGKmkaxT2821zwOmgb3Efs5H3NrjmHxgoHWATRdia5 KNsXvB16dSqeGTjIGJunLyXRJRAL3W18yGfPBId94h5QLA//ndBGRfh3HO0XR5ZLsF ZZfrrn52BOrmvfzleaLFXxmfmxJIZnjEVpiunf5J+VIySiejvQLBNbUK5GOMjqX3Eh +6UMsYsqAvK1w== Date: Wed, 16 Sep 2026 09:46:56 +0200 From: Maxime Ripard To: Thomas Zimmermann Cc: Ze Huang , Alexey Brodkin , Maarten Lankhorst , David Airlie , Simona Vetter , Joel Stanley , Andrew Jeffery , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Linus Walleij , Hans de Goede , Alex Lanzano , Oleksandr Andrushchenko , Philipp Zabel , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Marian Cichy , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 2/2] drm/imx: replace struct drm_simple_display_pipe with regular atomic helpers Message-ID: References: <20260727-drm-simple-kms-removal-v3-0-de36e534f7a1@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-2-de36e534f7a1@oss.qualcomm.com> <8e4c84be-5c89-4d84-adda-aad4c7de0c8a@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="3s4tplx46ij6zcs2" Content-Disposition: inline In-Reply-To: <8e4c84be-5c89-4d84-adda-aad4c7de0c8a@suse.de> X-purgate-ID: tlsNG-c1860d/1789544823-D7B5987B-42074652/0/0 X-purgate-type: clean X-purgate-size: 1205 --3s4tplx46ij6zcs2 Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Subject: Re: [PATCH v3 2/2] drm/imx: replace struct drm_simple_display_pipe with regular atomic helpers MIME-Version: 1.0 On Wed, Sep 16, 2026 at 08:50:21AM +0200, Thomas Zimmermann wrote: > > +static const struct drm_plane_funcs imx_lcdc_plane_funcs = { > > + .update_plane = drm_atomic_helper_update_plane, > > + .disable_plane = drm_atomic_helper_disable_plane, > > + .destroy = drm_plane_cleanup, > > + .reset = drm_atomic_helper_plane_reset, Also, this needs to be drm_atomic_helper_plane_create_state > > +static const struct drm_crtc_funcs imx_lcdc_crtc_funcs = { > > + .reset = drm_atomic_helper_crtc_reset, and drm_atomic_helper_crtc_create_state Maxime --3s4tplx46ij6zcs2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaqpJcAAKCRAnX84Zoj2+ doCwAXoC9/rqP3SJq9eA3TmbsgUL1dNQBlXU005d6LFRuERn952eYKYsEdnw0oH7 sS3Ms8EBfiZnSTC8Whf1zsDguMj/m/bcSyfEzHV6wM8Ix8qPXjNRdKfvP1twZo2V tHED8pYuFg== =LKtN -----END PGP SIGNATURE----- --3s4tplx46ij6zcs2-- From xen-devel-bounces@lists.xenproject.org Wed Sep 16 07:51:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 07:51:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422435.1647848 (Exim 4.92) (envelope-from ) id 1x6kQR-0003Br-4t; Wed, 16 Sep 2026 07:51:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422435.1647848; Wed, 16 Sep 2026 07:51:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6kQR-0003Bk-1r; Wed, 16 Sep 2026 07:51:27 +0000 Received: by outflank-mailman (input) for mailman id 1422435; Wed, 16 Sep 2026 07:51:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6kQP-0003Be-Py for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 07:51:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6kQP-001bxM-3B for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 09:51:25 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa4a75-8faa-0a2a0a5109dd-0a2a4506b270-22 for ; Wed, 16 Sep 2026 09:51:25 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa4a7c-195a-0a2a45060019-c387df83b132-3 for ; Wed, 16 Sep 2026 09:51:24 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 404C41FD86; Wed, 16 Sep 2026 07:51:16 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 51DDA136A5; Wed, 16 Sep 2026 07:51:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id Kr1lAXNKqmpDJwAAD6G6ig (envelope-from ); Wed, 16 Sep 2026 07:51:15 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de"; dkim=pass header.s=susede2_rsa header.d=suse.de header.i="@suse.de" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Autocrypt"; dkim=permerror header.s=susede2_ed25519 header.d=suse.de header.i="@suse.de" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789545080; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=XBhtVBTat+R1KWkqHRDVuXf9g4iyat+P91M6XkPAv2w=; b=BxQzUfzoqAIHFY0Ykr5vgXzbVKLviRIY7hccIBoiF0VOwuulTxGuADWpvUhUQGE+dtvh6x 3vN3THPQlyMTgaSmtlFC8E/xSCtAvNR4pl0Y78zwc64vtFl+S/JL6W18IKobHCawM233/6 sqXYRyZdz9GCSXrRWvGRYHQ1PVG3uV8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789545080; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=XBhtVBTat+R1KWkqHRDVuXf9g4iyat+P91M6XkPAv2w=; b=lCBuT9OuoBHAwbbbQn7B51DQOeRuFn6J7gbvd5edmEp/evS0eeAuQT8S9jVqh8UkB94o8U qjgOLhXNZcO2jyAQ== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="II3l/jzB"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=ucPKXdWy DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789545076; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=XBhtVBTat+R1KWkqHRDVuXf9g4iyat+P91M6XkPAv2w=; b=II3l/jzBRy236VBKXLz7gLYqUZsYcddfazBTpq8CVwqWHn3k4en4Tv5GHhIazbrHUJIGwK vm8f28e1ZkgsVFsf4uANGqPfeKkzJpof49bKphUnOo3yLSjwWLCS30PmEyIeuJehsiTG8+ CnPVBO8r96Y8mAYMuU0iAqn7oPc5BaA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789545076; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=XBhtVBTat+R1KWkqHRDVuXf9g4iyat+P91M6XkPAv2w=; b=ucPKXdWyMHsByG8+jpc4ABTYOK6OpiDIOhFzz69x9AXbFTAGbG/3PxJQtkShM3fc5d7X5h 7Z4Ia2cIthQ1fwAA== Message-ID: <9a248432-31df-484d-abc3-3fc73b42a43c@suse.de> Date: Wed, 16 Sep 2026 09:51:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] drm/imx: replace struct drm_simple_display_pipe with regular atomic helpers To: Maxime Ripard Cc: Ze Huang , Alexey Brodkin , Maarten Lankhorst , David Airlie , Simona Vetter , Joel Stanley , Andrew Jeffery , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Linus Walleij , Hans de Goede , Alex Lanzano , Oleksandr Andrushchenko , Philipp Zabel , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Marian Cichy , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org References: <20260727-drm-simple-kms-removal-v3-0-de36e534f7a1@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-2-de36e534f7a1@oss.qualcomm.com> <8e4c84be-5c89-4d84-adda-aad4c7de0c8a@suse.de> Content-Language: en-US From: Thomas Zimmermann Autocrypt: addr=tzimmermann@suse.de; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 404C41FD86 X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_TWELVE(0.00)[25]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[oss.qualcomm.com,synopsys.com,linux.intel.com,gmail.com,ffwll.ch,jms.id.au,codeconstruct.com.au,nxp.com,pengutronix.de,kernel.org,epam.com,lists.freedesktop.org,vger.kernel.org,lists.ozlabs.org,lists.infradead.org,lists.linux.dev,lists.xenproject.org]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:url,suse.de:dkim,suse.de:mid] X-Spam-Flag: NO X-Spam-Score: -3.01 X-purgate-ID: tlsNG-16d1c6/1789545085-1F8CB77B-36E6F3DC/0/0 X-purgate-type: clean X-purgate-size: 929 Hi Am 16.09.26 um 09:46 schrieb Maxime Ripard: > On Wed, Sep 16, 2026 at 08:50:21AM +0200, Thomas Zimmermann wrote: >>> +static const struct drm_plane_funcs imx_lcdc_plane_funcs = { >>> + .update_plane = drm_atomic_helper_update_plane, >>> + .disable_plane = drm_atomic_helper_disable_plane, >>> + .destroy = drm_plane_cleanup, >>> + .reset = drm_atomic_helper_plane_reset, > Also, this needs to be drm_atomic_helper_plane_create_state > >>> +static const struct drm_crtc_funcs imx_lcdc_crtc_funcs = { >>> + .reset = drm_atomic_helper_crtc_reset, > and drm_atomic_helper_crtc_create_state Right. I forgot that create_state is available already. Best regards Thomas > > Maxime -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg) From xen-devel-bounces@lists.xenproject.org Wed Sep 16 08:23:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 08:23:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422455.1647857 (Exim 4.92) (envelope-from ) id 1x6kvL-000813-V6; Wed, 16 Sep 2026 08:23:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422455.1647857; Wed, 16 Sep 2026 08:23:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6kvL-00080w-SI; Wed, 16 Sep 2026 08:23:23 +0000 Received: by outflank-mailman (input) for mailman id 1422455; Wed, 16 Sep 2026 08:23:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6kvJ-00080q-Pn for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 08:23:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6kvF-001jlh-JM for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:23:17 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa51ea-e002-0a2a0a5209dd-0a2a4506d892-48 for ; Wed, 16 Sep 2026 10:23:17 +0200 Received: from [52.101.53.23] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa51f4-195a-0a2a45060019-34653517907f-3 for ; Wed, 16 Sep 2026 10:23:17 +0200 Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SA1PR03MB7147.namprd03.prod.outlook.com (2603:10b6:806:336::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 08:23:14 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 08:23:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CNvIdsGjYpropUhIAlAb3AboTwf+JVFbuAO2C2I9MMdxRri/OPFIoKyOoYyncMQsnlquA+hS5ErUSD+3PfXiXXMX0qM3SvHHecIq7XMSGQWpRYQ8xnOeW9BxfCtWvKLn0IE5ZXe+HVED/r+qEnF/ApAMQUKrOXMhqvCM/tN+DlVZiKRNuVQbVuojQdzu8fMSX9lICbJtAKvJ0qsTBvbWLNM+pgZs9yLOtYa/u3yGz+dlkC6KW/4DiQIsutuPDVKofxyjLcN4nw4W+W1COTn2VwtarSMKyD7TJUsu7pSTbdrN+DeF89vzLtKXUgCxsR6dxkz4E7bMWlcG5SXZErrowg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7B3fv3RhboLg99eykgwSnE5v+dtq2chUexLkyAwo+8c=; b=PTfklA+y55uUHRsS5Xpr6jJWPc9ToDiyOWlC3rHSbbuTOcj0BANqVs1hbTFLbN4JKfSpMTA7TJ7AbHZCp2iY0oV5dtAQtRpL1KnDdRwKvIytkS1Ir/HwQ4b9kZTae+GY9k7tZO/a+RdZSp+XJn4CyBEul0G0zZNw6MAdpyc03MnCzrJaaBtCG4bNgqUstNbC6L1ufveE050lXMFKnYH+u22fGdjfXL5Qcr9vmfQc0uzfQG25vRRUiHNAuXyeaG4+TpAEjD75n3vHWibaUg9WGALPtV2TxcsD1q7NBBoeiO8Q+2fumd24eaStl4Np2We+E73u44dzh+W5Ff8fxJGJUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7B3fv3RhboLg99eykgwSnE5v+dtq2chUexLkyAwo+8c=; b=xxrX3ZZh7bGf8LEdrBuzsiXYfT/JHmNgA2nCW2beu0Hq0Sidf6Ij3zLjKW7V+wfznDdohJf0QR1nRQldnE4Q6KFUB5uYehtVC81Q08GoZsvvhIVZDt4lUbN0JKeUo8C/ccuP1KLyOBKQ3O6VwyMoPgv+L4GcrmHSRTdxAyNlkvM= From: Kevin Lampis To: Jan Beulich CC: "teddy.astie@vates.tech" , "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update Thread-Topic: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update Thread-Index: AQHdQWMYYuOEW7sUTEmdu2MmKUu4LbbJV30AgAaz+PaAAK8QAIAAK46o Date: Wed, 16 Sep 2026 08:23:14 +0000 Message-ID: References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-4-kevin.lampis@citrix.com> <0aedfbad-29ae-4083-89b4-5c662398553d@citrix.com> <2516df18-b239-4bf8-9f89-f1811515e5d8@suse.com> In-Reply-To: <2516df18-b239-4bf8-9f89-f1811515e5d8@suse.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BY1PR03MB7996:EE_|SA1PR03MB7147:EE_ x-ms-office365-filtering-correlation-id: 11c0e00a-dc2e-44d2-e124-08df13cbc0b9 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|18002099003|22082099003|10067099003|6133799003|4143699003|8096899003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: 5MpPTaGnc3en+YoCWuEkB5W/TGuw7ZDzyNKnv3+P/D0WWvvYIjoqBg18psMEWAMmzIT1FBoUm362P8Cvi348VQksoNRJwCmZgQa/MHW0Vx0h0UfaFMxs0XmnuYhxhorajGr9PoQRrVtmV1TBdbMWOQlWbCYKunptw4BGjcArgM7I2rYam2PJ2oQvSoqE7XL4uEM4jYDo2vud8aT2l3xFvEzagHFKcCAeH7tE7jwaw8DSME+7+I4B9jhuLahKIC+tLdyttLTkgh05L+YIopvBtad6i1qG4XF6r8qHkyf2PuVAktv5TwwjzPjhx7aw69nCbED3Clqj7/dHndbux3hHoq1X79j5TUBBTQun5Wv/uv3Feh/m0sKFTxZKartm1F0MnaQSkvPEklQQ9FoUHUwl9q6e4es1ZDUglBeq3qVZxOM8VsBNnyjcYQJHFPMYzwx1LKfLAmzbtN5kV6wX61mdrXuxvjnxb5sKWi+4+5ZJPzfxtzgf+416I7Mrf8oBC0WNAd1wMfjx1UD0LR9+SpumPj/5utS/wP7ClTyusWWIqJQbLV2usnIbnPqmhGQcHR9n8GRgz15CL2svrinWy0+MyJz2QneB33i2kMYlgeOsraSHU9t3iik5RVfX/EELHh+5j4vrKz+wuKHSTZt2wT4d4fo2PD1oMxVoxVX5dZyBnTFYP+964eJ/WEVmie6j83i2Kym0kAQnYwyXLTM+e0m0+xp8pw7WxseQIolrlOeYKNI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7996.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(18002099003)(22082099003)(10067099003)(6133799003)(4143699003)(8096899003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?2sGWyM5RvFEtu5qvZaHaPP/Y+otOEPVBVvPhJGh1+zsUtdB3azy7EnOS3k?= =?iso-8859-1?Q?BWfG6SOBTR2pzt6I9vfSXCOAenx2ze/b5OnakxpMl9aQbJbw1JWDwnseiH?= =?iso-8859-1?Q?h9UG6a0bccRDg3C25BUIsAd6/mXT5MU0uZcS+8upEWfS2tCzb9wG2X6qgi?= =?iso-8859-1?Q?no3DEDq96JBdOBtPQMhI9YxIoizNWUZeAz+rbtkbszibr8eYm50bliojZI?= =?iso-8859-1?Q?U6LYu8mKUSFn3WosbJcpP7mU85BVINqnQSsBceAXufVZ6l5YAtGIwscVeS?= =?iso-8859-1?Q?qKO1Tf93UEbs+NyAV1BD1M5Xb2XqRaqKEN/MFjYze2pG2loIcvDmQsoBtt?= =?iso-8859-1?Q?b7Q6JfyThvaTZBlhT1CpwIMFycaxqufkiUkeeO7uCXM6qh002561rh+e9x?= =?iso-8859-1?Q?ukqmSugDWELGiRX1ERRORScujxeojvf0rAaO+mYs1uLB7yXUXOm1ne1XQV?= =?iso-8859-1?Q?8bxsT2p4gxtM2UiAy06BjiNLdH2YFyfeQSFR1qyp/7eET5afh7IMtIMDb1?= =?iso-8859-1?Q?X0h5sYe9K2Wr+ARwz+DzepSI9COwdxBV5sksSCi/YgvWgLsOQLVohK1WYR?= =?iso-8859-1?Q?nkeg/r9RmxuTGI0V4msPWTW6/0v30dsazEbHvmN8IULQJ5A/xbEeJ3+XU8?= =?iso-8859-1?Q?w8wP049T9gTToJbSK7I1p8f3/DJepZFUxrCQPJWInyZ22/7R8fl5HA+K9a?= =?iso-8859-1?Q?FZ0FkEgEJCrPK5ETSogIUDwNNPer29ReW9jXfhxSdeLvnAYp57iEwZ+TOS?= =?iso-8859-1?Q?2ZaIRQ7cyh0CDQv/OoLKckx4naYFY6Bh7+DUb/cDsZPRDMg9th6fmE+YpU?= =?iso-8859-1?Q?RTalexUFWs+LuuyTRHjVPvTTc7JytnXxuKfiC0jb1o8BwJVFF7cepnr/zR?= =?iso-8859-1?Q?BV7RG7neYCujwtDVwlp2ue+mwmpptPqqKC7GTdUwDtoX7xZ/7df715bJcT?= =?iso-8859-1?Q?iUDCa70tJ1MEw4/AyBjVaAvfvrU01GPOyR7zQ1Eo2cARNi2DIRY+33Scoo?= =?iso-8859-1?Q?vyoeFBuHtK3xzYhD0VKv+vyl81OAUJpTT9xLLTlbsIDBWCC/WSG0REv1Ci?= =?iso-8859-1?Q?4lAm886bHUSueQCkgCTFCmOjtnPoZnq4tgeR2V0k2F/9sUBIlmrNEpldag?= =?iso-8859-1?Q?SG6FbMM5cg82tl4H35O/ALPmgzssAEBZY2QM8NUP1cpfize4Ke33guuj6+?= =?iso-8859-1?Q?aAm+6ag6obVOWjjwJMGUjsKkB2mG7OOrOMVHvR7YHwFrBwlTYyyrKMtQMb?= =?iso-8859-1?Q?9uncrlsZOZ0EPFBJEIksLSiFsmBCvgGDOxTCQudI8/ID+IoJAKuWW8W0uy?= =?iso-8859-1?Q?Fp4oBCOUfbTAPSZDA+eKYrV6jl0h15zmpc+o4y2KVmkZYKOpOmbU+kjZVm?= =?iso-8859-1?Q?z7/rXplj3Ij0E/B6TORiT5oJqq9VWHIl/Sfocygl+PQB0+GHR83gOeGUVr?= =?iso-8859-1?Q?ZvtYPpoS6dFOiprIhRuMmoc+UJCHiI+EJ8fy9H2srwCblqxW1uw+6plU/C?= =?iso-8859-1?Q?+v6vNO0MBgHm7pCMYh5HV/A9fWnKEa8ws2EEyni+UgF7AaLLDyZSPaL+Er?= =?iso-8859-1?Q?W6mKGTi5IN5GeJqvAQQET8Zi1IFU9FASDBduHItk8CrXc7p4idZROXhS7A?= =?iso-8859-1?Q?oxlgHxcPbR5cXIPDB+HibRqaXMxFft4Q4k7RV9wZpgJlDD2cXTzxHAURQM?= =?iso-8859-1?Q?oBJZBH6+Ar2l6BKaV+KiW/q0sh33WFL1AKBwt4H51Z9wOvs+g1Sqhu2vMu?= =?iso-8859-1?Q?WzGvuT2hYjohguSRn1X/Puj27uou3JPaweV0IzK4vykcRs?= Content-Type: multipart/alternative; boundary="_000_BY1PR03MB7996E6B84145F4A368D611B2F3B92BY1PR03MB7996namp_" MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11c0e00a-dc2e-44d2-e124-08df13cbc0b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2026 08:23:14.2412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4nZu7E9aeGtxbk0jfmi4tXQRNoSJqeKJ/7avmYG7vrTQF4kZ1pJXhE5c7fzZK6ClDNA9wIoPUhvMy3W785HuqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB7147 X-purgate-ID: tlsNG-16d1c6/1789546997-1F4C977B-2740B61D/0/0 X-purgate-type: clean X-purgate-size: 7226 --_000_BY1PR03MB7996E6B84145F4A368D611B2F3B92BY1PR03MB7996namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >The "flag set, pointer non-NULL" case wouldn't hit the "return 0" path Correct. But what about the "flag not set" case. When PTE_UPDATE_SWAP is not set the= n UPDATE_ENTRY may return 0. If UPDATE_ENTRY() returns 0 then mod_l1_entry() will give the wrong ol1e value to put_page_from_l1e(). static int mod_l1_entry( ... ) { ... ol1e =3D UPDATE_ENTRY(l1, pl1e, ol1e, ...); ... put_page_from_l1e(ol1e, pt_dom); ... } I think mod_l1_entry may need to store a copy of ol1e incase UPDATE_ENTRY() returns 0. Or add some extra if/else around every call to UPDATE_ENTRY() to only assign ol1e if we know we're on the new PTE_UPDATE_SWAP path. And the mod_l{2,3,4}_entry() functions will probably have to do the same th= ing too so I just wanted to get some input first. --_000_BY1PR03MB7996E6B84145F4A368D611B2F3B92BY1PR03MB7996namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>The "flag set, pointer non-NULL" case wouldn't hit the "= return 0" path

Correct.

But what about the "flag not set" case. When PTE_UPDATE_SWAP is n= ot set then
UPDATE_ENTRY may return 0.

If UPDATE_ENTRY() returns 0 then mod_l1_entry() will give
the wrong ol1e value to put_page_from_l1e().

    static int mod_l1_entry( ... )
    {
        ...
        ol1e =3D UPDATE_ENTRY(l1, pl1e, ol1e, ...);
        ...
        put_page_from_l1e(ol1e, pt_dom);
        ...
    }

I think mod_l1_entry may need to store a copy of ol1e incase UPDATE_ENTRY()=
returns 0. Or add some extra if/else around every call to UPDATE_ENTRY() to=
only assign ol1e if we know we're on the new PTE_UPDATE_SWAP path.

And the mod_l{2,3,4}_entry() functions will probably have to do the same th= ing
too so I just wanted to get some input first.
--_000_BY1PR03MB7996E6B84145F4A368D611B2F3B92BY1PR03MB7996namp_-- From xen-devel-bounces@lists.xenproject.org Wed Sep 16 08:54:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 08:54:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422474.1647866 (Exim 4.92) (envelope-from ) id 1x6lP2-0003pb-6w; Wed, 16 Sep 2026 08:54:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422474.1647866; Wed, 16 Sep 2026 08:54:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6lP2-0003pU-4H; Wed, 16 Sep 2026 08:54:04 +0000 Received: by outflank-mailman (input) for mailman id 1422474; Wed, 16 Sep 2026 08:54:03 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6lP1-0003pO-B2 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 08:54:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6lOz-001s2r-Sf for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:54:01 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa5917-2eae-0a2a0a5409dd-0a2a4503cabc-48 for ; Wed, 16 Sep 2026 10:53:59 +0200 Received: from [159.226.251.81] (helo=cstnet.cn) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa5925-fae8-0a2a45030019-9fe2fb51caee-3 for ; Wed, 16 Sep 2026 10:53:59 +0200 Received: from [10.213.11.11] (unknown [36.110.52.2]) by APP-03 (Coremail) with SMTP id rQCowABHUT8gWapqgfLfBw--.13937S3; Wed, 16 Sep 2026 16:53:52 +0800 (CST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 6/6] xen/riscv: fix level_map_mask truncation on load_start From: Zhang Zheng To: Baptiste Le Duc Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org, Zheng Zhang In-Reply-To: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3@vates.tech> Date: Wed, 16 Sep 2026 16:54:24 +0800 Message-Id: <178954886475.200919.15962926828653940980.b4-review@b4> X-Mailer: b4 0.15.2 X-CM-TRANSID:rQCowABHUT8gWapqgfLfBw--.13937S3 X-Coremail-Antispam: 1UD129KBjvJXoW7tw47JF47AryDZr13JrW8WFg_yoW8Jw4Upr WUGry3KrZ3X34DXFZ2y34kZr4YgryDZayfAw17Aryjq3s5JFyUJF9Iyws8WF4fGFy8ZFya v3sY93WI9ws8GaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmY14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2AI xVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20x vE14v26r1q6rW5McIj6I8E87Iv67AKxVW8Jr0_Cr1UMcvjeVCFs4IE7xkEbVWUJVW8JwAC jcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka0x kIwI1lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1V AY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAI cVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIev Ja73UjIFyTuYvjfU0wZcUUUUU X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-33051d/1789548839-770F64E9-B2DD69E5/0/0 X-purgate-type: clean X-purgate-size: 1368 On Thu, 10 Sep 2026 11:34:54 +0200, Baptiste Le Duc wrote: > diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c > index 53bebbcabf..e7f2491257 100644 > --- a/xen/arch/riscv/mm.c > +++ b/xen/arch/riscv/mm.c > @@ -180,7 +180,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_desc *mmu_desc, > bool is_mode_supported = false; > unsigned int index; > unsigned int page_table_level = (mmu_desc->num_levels - 1); > - unsigned level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level); > + unsigned long level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level); > > unsigned long aligned_load_start = load_start & level_map_mask; > unsigned long aligned_page_size = XEN_PT_LEVEL_SIZE(page_table_level); This resolves the issue where Xen fails to correctly mask the upper 32 bits of the physical address. Which make xen failed to boot on the SpacemiT K3, where U-Boot boots the kernel image located at physical address 0x1_4000_0000 by default. In sv39, page_table_level=2 : uboot bootm addr : 0x0000_0001_4000_0000 ^ unsigned level_map_mask = 0x0000_0000_c000_0000 unsigned long level_map_mask = 0xffff_ffff_c000_0000 Tested-by: Zheng Zhang -- Zhang Zheng From xen-devel-bounces@lists.xenproject.org Wed Sep 16 08:54:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 08:54:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422475.1647874 (Exim 4.92) (envelope-from ) id 1x6lP6-00042M-Do; Wed, 16 Sep 2026 08:54:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422475.1647874; Wed, 16 Sep 2026 08:54:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6lP6-00042F-Ag; Wed, 16 Sep 2026 08:54:08 +0000 Received: by outflank-mailman (input) for mailman id 1422475; Wed, 16 Sep 2026 08:54:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6lP5-00041s-Jx for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 08:54:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6lP4-0054r3-Dk for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:54:06 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa5916-8faa-0a2a0a5109dd-0a2a45078d1a-28 for ; Wed, 16 Sep 2026 10:53:59 +0200 Received: from [159.226.251.81] (helo=cstnet.cn) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa5925-b4ea-0a2a45070019-9fe2fb51a0c0-3 for ; Wed, 16 Sep 2026 10:53:59 +0200 Received: from [10.213.11.11] (unknown [36.110.52.2]) by APP-03 (Coremail) with SMTP id rQCowABHUT8gWapqgfLfBw--.13937S2; Wed, 16 Sep 2026 16:53:52 +0800 (CST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 2/6] xen/riscv: set A/D bits in Xen's page-table mappings under Svade From: Zhang Zheng To: Baptiste Le Duc Cc: Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org In-Reply-To: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3@vates.tech> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3@vates.tech> Date: Wed, 16 Sep 2026 16:54:24 +0800 Message-Id: <178954886474.200919.8556627169956989747.b4-review@b4> X-Mailer: b4 0.15.2 X-CM-TRANSID:rQCowABHUT8gWapqgfLfBw--.13937S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tFWDGrW5Xr1UZryfAry5urg_yoW8Zr4UpF 97Kwsayrs5A3WxArn7Za17XFyDWa1xJ3ykWr90g347uFsIvw1xGr4I9a4UJayDuwsakw4j vr4qvryrWrsYyrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvKb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1q6rW5McIj6I8E87Iv67AKxVW8Jr0_Cr 1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACI402YVCY1x02628vn2kI c2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbV WUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF 67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42 IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF 0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxh VjvjDU0xZFpf9x07befHbUUUUU= X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: x2kd0wx2kh0w46lvutnvoduhdfq/ X-purgate-ID: tlsNG-ef75cf/1789548839-3C610AE4-22F95A95/0/0 X-purgate-type: clean X-purgate-size: 1972 # Add your code comments below. There is no need to trim or delete # any existing content -- just insert your comments under the relevant # lines of code. Lines starting with "> " are quoted diff context and # lines starting with "| " are comments from other reviewers. # The final email will be reformatted automatically to include only # the sections that have your comments. # > The previous patch set A/D bits in case of the Svade extension for G-stage > mappings. Xen's own S-stage mappings need the same fix as both > setup_initial_mapping() (the boot page tables) and arch_pmap_map() (the > fixmap) build leaf PTEs directly instead of going through > pt_update_entry(), which is what adds A/D bits. So with Svade, both would > fault on first access. > > Add PTE_ACCESSED to all PAGE_HYPERVISOR_* and also PTE_DIRTY to > PAGE_HYPERVISOR_RW as it needs to be set during a write to avoid a fault. > This fixes arch_pmap_map() for free, since it already builds its PTE from > PAGE_HYPERVISOR_RW. Switch setup_initial_mapping() to use these macros for > its default, text and rodata permissions, and for the temporary root entry > built by check_pgtbl_mode_support(), instead of the equivalent raw bit > lists. The latter drops PTE_WRITABLE, going from RWX to RX, but this is > harmless, as that entry only has to make the current instruction stream > fetchable between the two CSR_SATP writes used to probe SATP mode support, > and nothing writes through it. > > Drop the now-redundant PTE_LEAF_DEFAULT, since converting the last > open-coded site above leaves it with no user outside page.h itself. > > A PTE is a table entry iff PTE_VALID is set and R/W/X are all clear, so > update pte_is_table() and pte_is_mapping() accordingly. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc Tested-by: Zheng Zhang -- Zhang Zheng From xen-devel-bounces@lists.xenproject.org Wed Sep 16 09:29:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 09:29:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422515.1647884 (Exim 4.92) (envelope-from ) id 1x6lxM-0008OL-Vy; Wed, 16 Sep 2026 09:29:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422515.1647884; Wed, 16 Sep 2026 09:29:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6lxM-0008OE-TE; Wed, 16 Sep 2026 09:29:32 +0000 Received: by outflank-mailman (input) for mailman id 1422515; Wed, 16 Sep 2026 09:29:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6lxL-0008O8-RT for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 09:29:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6lxL-009fZT-89 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:29:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa6178-2eae-0a2a0a5409dd-0a2a4504d424-14 for ; Wed, 16 Sep 2026 11:29:31 +0200 Received: from [52.101.57.61] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa6179-b57f-0a2a45040019-3465393d8b80-3 for ; Wed, 16 Sep 2026 11:29:30 +0200 Received: from DS0PR03MB7557.namprd03.prod.outlook.com (2603:10b6:8:1fc::8) by DS0PR03MB7582.namprd03.prod.outlook.com (2603:10b6:8:1f5::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 09:29:21 +0000 Received: from DS0PR03MB7557.namprd03.prod.outlook.com ([fe80::6884:8bd5:3e4d:fde7]) by DS0PR03MB7557.namprd03.prod.outlook.com ([fe80::6884:8bd5:3e4d:fde7%5]) with mapi id 15.21.0428.008; Wed, 16 Sep 2026 09:29:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AVKZySrl2wXQU16m79sBlNxVb3a0Yq436qWDY4cIq+RclPmxMOZvTWAPNkC83OGyIdi/dL3eBbBKyngqq66IZ1LHUW9y+CwVmH8xRE870DI6cOEfcG+RCvmwKzhBnPbTY2TIHfxYdkMh8Zk3auKdSo3jTcN48CkWBWous1OLGlKyQKR6Xsp+hcNipuOmbhqF6k3mJBwEEjejfspA2sxyKW9VxWf8tu0+zwML1KwC7Ho6CXDVXQcM85sxjXVePPtF745UOK7g8ZzAlqeTC/XK6zNWkX4Eh/JBVVoaMVs4KB0puMqYc3CT7asK1hqfrXheyQj5jtLheWQDdMaSUaxPFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=B+bVW6awHFUI9dFXxsOrceZQwHB+1lgluMYbgslDmYs=; b=kyMwodk6uIJI0chjcM0MDVJyR3a8GFwTbnbgPrAzD87fjB3QkpJJaguabv4BhFRPkMkRVseha/1Nzjh3PQ8TOG+1lUih7VwsHxniFPFLVXwJxGDRM4hiU9acurCVw5YV6Fb3P+9EpPhlFc0GB3hYdiJAXIExKGMyxvfr7gevkhEgbz0s8WrGQNLYgG5UsSO3It+W330dVtCSQxLlrnKDJ71QQ/8oVeLcsvb6pYtdZWjjy8f8+D6UfqU5lyghLh/sU8jHzX6jm7ANZf0JapwCgVK019s4w2VwGV+bfHRYBEBuvWn/aPh03WQFJgYtM5LjhLWHs459zHP51fVCpe84QA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B+bVW6awHFUI9dFXxsOrceZQwHB+1lgluMYbgslDmYs=; b=NZ/nq9SMHOPsL8qTgZxSiTlI4isnsw8hSsd8ZjgMU1jKUAmbugR6gfaRKX5hdbpmM/o+RBdYtCzoWWgIRlbxEagxE6yM5Ki5ZYG3xkzrZhhl8SwAsGrboHfTMgoSxRCgzypfPpyUxG6/LvLua7ut0gPkk/vymiNsV5/HQGNMWzs= From: Mark Syms To: Stefano Stabellini , Anthony PERARD , Paul Durrant CC: "qemu-devel@nongnu.org" , "Edgar E. Iglesias" , Kevin Wolf , Hanna Reitz , Stefan Hajnoczi , "xen-devel@lists.xenproject.org" , "qemu-block@nongnu.org" Subject: Xen/QEMU PV Storage backend performance issues Thread-Topic: Xen/QEMU PV Storage backend performance issues Thread-Index: AQHdRby6p8WbXIfQiUq6fN2CsBlKNQ== Date: Wed, 16 Sep 2026 09:29:21 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS0PR03MB7557:EE_|DS0PR03MB7582:EE_ x-ms-office365-filtering-correlation-id: cee1a447-a47c-4c9e-c99a-08df13d4fd6b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016|23010399003|38070700021|3023799007|10067099003|56012099006|11063799006|18002099003; x-microsoft-antispam-message-info: PHnMssEOMcXePAOP+Qw+jbbtMFEDprWcnYOfM7DERqbGfWmLaltgD3Ma0IG7wWnwi2gAWdms1jfyV43ebRhw1VjmcAbQRDCNo/n2n1FY2U2DZtwoHAQK1B9PUE3ca8y088AMB+MeqTP90XkJcgt52Q9FCeVDdS1EQnpKTMIm+lZ3Fh1qSEfehy9zCkbMpwHIvrZXvhli42kK38NzeH9EAXC63w/wAKBcgOzaj4ScMzFxFEiqh2mopUJFARNmdzKDa3a4bfrC3I0QhI0DGKZwavl3XRU/LLxaDSjO2M04yJ0WBpuXWlOOqWHqAFPwLtJ8L4yqCrBugv7IZdDT/6DDXeFjUT/CTfVUvgKMkZyBRSu3OSjZd7Clh5o2f0ngVkgba//dAPvQpzaCjO4uE8UJrAwI/N0zejov3j0w5tCiQg05MO5koMjdfSOWNlJK89KNKA6rkvw8exdf5mlGNZwfEPtoE1iQD6Ja2Quevpw9M+c1/N5onwneDusQ0maodnfz45u+jna3OxFUFrIHrgS+0PDsN6wD8XzZo8gWAm9Da/auiz6JAMVtKmJb+tcdnbyFSmVLeCVLrHtAa3n8QT85DgImr6yJHBbVeXKI585KU0hxvbg4wFhngavcK6UAdGuexz7XtZbLh3i137Is+VyUQu0NVuQ1OJEZvrgZuRsuOCqIeZJ9b8dtixjkaDJr3MdfQArtYLpmQ5cZjHYG8xOobo1ReS+VY1XWxgxraSTxPT8= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR03MB7557.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(23010399003)(38070700021)(3023799007)(10067099003)(56012099006)(11063799006)(18002099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?CFYT4X69YayEA+Q6AVdVO6KhOLYJbyuzQBmyfd+CSPqAvhHLpx7bPmLbGL?= =?iso-8859-1?Q?YzRbbPdRbNd3Z3TYovQzggB0MV2KDugxz4RhxKAL8MQaucU7+1waHnQLBG?= =?iso-8859-1?Q?FO0whe9tbsK+gfIWiufGUC3G8A1vFTGPsR8JKqGwvdp/ebE2vNT+nl5laY?= =?iso-8859-1?Q?tN0WpZZBx5e1jPc4eqZUg5eb7qhR9bXlX2ZGmIjUISEPgxYqnI7QwbviWF?= =?iso-8859-1?Q?s6fdY+goSKCmwXUtFHMfBi5mty2wnOTZ1D3Gct6XORn+NGzM/W/WY3LbcU?= =?iso-8859-1?Q?61u9ZFP1yFJGzbcO/oeLzo31M5B0AKsHLTMEAa789lWIM53wwyBYtutgnA?= =?iso-8859-1?Q?sCjMYq5SkyUALRSQtznbQsgFaDjHuKWTkDBXjB2SfCYWJ7yByeSyBvL7YT?= =?iso-8859-1?Q?btEK7H1hB1xgpxhQQXFjPyCxOdWEGc113OiOQDeAwh5m9PzHAuYtT+IBb3?= =?iso-8859-1?Q?zB0cNOdgL+TMtnwz8aBITq0dylR3rAZ0pusQAbcEU9jcVOIri+qaAbfYOg?= =?iso-8859-1?Q?0JgLuavhBPvAr1a525z89HNR7bfkilyBKP3UmNUNvK6Htd3njlMLr07dBF?= =?iso-8859-1?Q?uJYM8xd/38xmaXn7N9jUPLOuowrgsvpZb0hwvnQGO7oqciPCGCeJzYYGr/?= =?iso-8859-1?Q?5qxucsIuSNqVH1sxXh/PTG5Tb4b9HfCMHqTQkvIkrtwCPTipG11j3EXhz7?= =?iso-8859-1?Q?6TgvVq3N8jiWBpI/ddTyFZdAfnlzpHtRxTWqsK67m3kBZHXGtlyicFqrK9?= =?iso-8859-1?Q?BEONeyneqkVbyo+gMXe0xqRDtwMdS3gfpBfP2FI7fpYkl9eqOGkogOVDg+?= =?iso-8859-1?Q?CLcCq/QNnWM4r7NNmy+q6vAi1Ys3b7+T/0xCS5ak13J5+gELkaH/hOKPYg?= =?iso-8859-1?Q?98XaeiZa20vnj1sJeCNk7zquoWg40Gw2kVCyiJjJAY2Wfxa6ofO//QqVBC?= =?iso-8859-1?Q?DmySHCG2SH2j3nH/aXZJLZ2vgYRfDg+aOQNIT112cRQX9qXNXqNwphxpdM?= =?iso-8859-1?Q?IRCnZ6tENDR3/Drc8tQjA/SlmiOV1Kw4Pp40yh/hdAepS2ME9zS+m9YeA8?= =?iso-8859-1?Q?LD+W18D5e+83XlyzkJQrFaNCl5i24yCqGT7v4qWAIwtlLDy/iJwvsQ/m6C?= =?iso-8859-1?Q?idVirCTWGhDorbIRWH7mjBeeKDaH7NNczsLIXJlWZViQ3TTVi0MXnLwCvr?= =?iso-8859-1?Q?fHiRMWjbkD5vp/OKj7jRxzKHg9GsHDh3fr/1nHW0Q1nMNJdlh+cQKCgAZO?= =?iso-8859-1?Q?tGCVaLppr/3R0eTf5twUwLUrwbUnAbGvxSQorztOXpkaqBu6jWMdn7/LKd?= =?iso-8859-1?Q?f6w8FfbiawpbMa/xVJnLekQY3R2n8O9vyyuZw5i/Cfk6Erc+QqEQQlKDjL?= =?iso-8859-1?Q?7XtpU/DB4i1u2+hBkCdbi0Z9+LkjcB1XN/9R3cQVqN0/qbXBbVOT1QrwL7?= =?iso-8859-1?Q?tJFaj8qU55Aj/H/6prLwFhfxomNdCpbu72Em2QwZVk8iTQBpcEtL5kkuZD?= =?iso-8859-1?Q?uquMEbTYLbxQ0zYnvrsJvqgyzdBJUoQp+5T3f44F9HEuRV0Yh+gMczh14c?= =?iso-8859-1?Q?u5rX5f6buXb+npphxM21ztG62Kq+lypfi3IE1Hkni0K2ttM80DFzZgwqQ1?= =?iso-8859-1?Q?deGu2nhVlS8p0NQHs585xPGyO/gwQVQPV+BOgiMnXaeMFpG/CbHu/8L/JC?= =?iso-8859-1?Q?NCxuxMHprLpxe5ROh5EDS28IY2lsi+Ov46Ou48+0E8qhrZPKtVkfIwLDs7?= =?iso-8859-1?Q?5JaFl2S6JePY3JGyyM/DosA36ro2rYmfonzCfKB1BydBvl?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS0PR03MB7557.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cee1a447-a47c-4c9e-c99a-08df13d4fd6b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2026 09:29:21.5167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OsOjePThIar9NRrPnoith6NwKDmggnjcxgH1AcpgKQiSKhESJmG/m5U+wg/hjoP02pEtqEnxBB8dWa/MHGF5jg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7582 X-purgate-ID: tlsNG-ebf023/1789550971-504DBB50-A651B5C4/0/0 X-purgate-type: clean X-purgate-size: 8340 Stefano, Anthony, Paul,=0A= =0A= Hi guys, hope this finds you all well. We, in XenServer, have been=0A= doing some back to back Xen VM PV storage backend performance=0A= comparisons between tapdisk + VHD and QEMU + QCOW2. The image=0A= storage format appears to be largely irrelevant to the rest of this=0A= conversation. In doing so we have found a few significant issues in=0A= QEMU, mainly around the xen-block dataplane and adjacent code.=0A= =0A= ## Testing Environment=0A= =0A= Debian 12 VM, 8 vCPUS, 4G Ram on XenServer 9. Three virtual block=0A= devices, one for the OS on host local storage and two, unformatted,=0A= 20G test devices, one backed by tapdisk and one backed by QEMU. These=0A= disks themselves are then backed by a BRD based target hosted on a=0A= native installed Rocky 9.8 host. The two hosts are connected over a=0A= 25G, 9000 MTU, switched storage network whose switch is rated to run=0A= all ports at wire speed without contention. In the guest=0A= `xen_blkfront` is configured with `max_ring_page_order=3D3`, which is=0A= honoured by both tapdisk and QEMU. QEMU supports 4 but tapdisk caps at=0A= 3 so for consistency 3 was used. Performance data was collected by=0A= `fio` v3.33 from the default Debian 12 repo.=0A= =0A= Note: we did find during this that QEMU has a separate problem with=0A= feature publication when hot plugging a device -=0A= =0A= https://lists.gnu.org/archive/html/qemu-devel/2026-09/msg03492.html=0A= =0A= This was worked around by always cold booting the VM which then=0A= negotiates correctly.=0A= =0A= ## Results=0A= =0A= The following table is the full grid from the testing=0A= performed. Points are expressed as ratios of QEMU/tapdisk so any=0A= points < 1.0 show QEMU having a performance deficit. Each figure is=0A= the median of the per-repeat ratio over 12 repeats, the first discarded=0A= as unstable on a newly booted VM. The tapdisk arm is measured=0A= seconds away from the QEMU arm in every repeat, so that drift in the=0A= rig cancels rather than being attributed to either datapath.=0A= =0A= | block size | queue depth | read | write |=0A= |:-----------|------------:|-----:|------:|=0A= | 4k | 1 | 0.73 | 0.73 |=0A= | 64k | 1 | 0.81 | 0.83 |=0A= | 256k | 1 | 0.67 | 0.92 |=0A= | 1m | 1 | 0.67 | 0.76 |=0A= | 4m | 1 | 0.81 | 1.01 |=0A= | 4k | 32 | 1.90 | 1.32 |=0A= | 64k | 32 | 0.99 | 1.00 |=0A= | 256k | 32 | 1.14 | 0.84 |=0A= | 1m | 32 | 0.86 | 0.88 |=0A= | 4m | 32 | 0.87 | 0.86 |=0A= =0A= Median across the 20 cells is 0.86, with 5 of 20 at or above parity.=0A= =0A= The deficit is concentrated at queue depth 1, which is what pointed at=0A= per-request latency rather than throughput. Note that 1m QD1 read is the=0A= noisiest cell in the grid at 24% coefficient of variation across=0A= repeats, so treat 0.67 as "much worse" rather than as a precise figure;=0A= the 4k and 64k QD1 cells sit at 3-4% and are solid. 1m QD1 is noisy on=0A= both backends and is probably an artifact of the environment.=0A= =0A= ## Issues found=0A= =0A= 1. **Large (4m) blocksize read**. Analysis determined that this was=0A= impacted by QEMU being overly keen in notifying the frontend of=0A= completion responses being placed into the ring. In turn this=0A= results in a Dom0 to DomU context switch and all the associated=0A= hypervisor flushes and mitigations. This can also be observed in=0A= the `ctx` count tracker in `fio` itself. Tapdisk mitigates this by=0A= only sending the notification on the `final` completion, managed by=0A= a `bool` flag. For QEMU we can use built in primitives such as=0A= `qemu_bh_schedule` so that the notify is sent at the tail of=0A= processing the `iothread` events.=0A= =0A= 2. **Small (4k) Queue Depth 1 read/writes**. Analysis pointed at=0A= dataplane wakeup latency of ~57us being the culprit. Tapdisk=0A= mitigates this by implementing polling, for a defined time period,=0A= after receiving a request from the ring. QEMU contains built in=0A= support for equivalent polling which can be set a property on the=0A= `iothread`. However there is no plumbing for this in=0A= `xen_device_set_event_channel_context` as `io_poll_ready` is passed=0A= as NULL to `aio_set_fd_handler` so no polling occurs regardless of=0A= the value set for `poll-max-ns`. Adding an implementation for this=0A= goes most of the way to addressing this issue. Matching tapdisk we=0A= used 8,000,000, i.e. 8ms. This ensures that the poll window exceeds=0A= the backend service time. There should be no `evtchn` unmask in the=0A= `io_poll_end` as this will introduce a CPU spin in the poller.=0A= =0A= 3. **Overall performance deficit**. After addressing the above two=0A= issues, overall comparative performance was still found to be=0A= deficient relative to tapdisk. Analysis found that QEMU was making=0A= many more, much smaller, I/O requests to the block layer than=0A= tapdisk was for equivalent guest I/O patterns. This I/O pattern=0A= difference was traced to tapdisk performing merges of adjacent,=0A= same operation, I/O requests at the blkif level before submitting=0A= to the lower level format drivers. Equivalent behaviour can be=0A= achieved in QEMU using the `qemu_iovec` function family and issuing=0A= `blk_aio_pwritev`/`blk_aio_preadv` as necessary. Suitable=0A= completion fan-out is then needed to respond appropriately to the=0A= associated request IDs.=0A= =0A= ## Outcomes=0A= =0A= After addressing the above items the resulting comparison table is as=0A= follows, measured the same way on the same rig as the table above,=0A= again 12 repeats, first discarded.=0A= =0A= | block size | queue depth | read | write |=0A= |:-----------|------------:|-----:|------:|=0A= | 4k | 1 | 1.07 | 1.07 |=0A= | 64k | 1 | 1.02 | 1.03 |=0A= | 256k | 1 | 0.93 | 1.04 |=0A= | 1m | 1 | 0.80 | 1.00 |=0A= | 4m | 1 | 1.03 | 1.01 |=0A= | 4k | 32 | 2.24 | 1.50 |=0A= | 64k | 32 | 1.05 | 1.00 |=0A= | 256k | 32 | 1.32 | 0.99 |=0A= | 1m | 32 | 1.17 | 0.99 |=0A= | 4m | 32 | 1.06 | 0.98 |=0A= =0A= Median across the 20 cells moves from 0.86 to 1.03, and the number of=0A= cells at or above parity from 5 of 20 to 13 of 20. The cells still=0A= well below parity are 1m QD1 read at 0.80, 256k QD1 read at 0.93, the=0A= other deficient cells are 1-2% down.=0A= =0A= 4k QD1 operations benefited most from the fixes for issue 2, voluntary=0A= context switches per I/O went from 1.94 to 0.00, corresponding CPU=0A= usage went from 26.5% to 96.7% which is a significant increase but it=0A= was mostly doing useful work.=0A= =0A= We believe that the final 3 rows of QD32 operations are probably I/O=0A= bound on the iSCSI transport.=0A= =0A= One cell deserves comment so it is not mistaken for one of our fixes.=0A= 4k QD32 sits well above parity at 2.24 read and 1.50 write, but it was=0A= already at 1.90 and 1.32 before any of these changes; whatever causes=0A= it is pre-existing and we have not investigated it.=0A= =0A= XenServer has fixes for all of the above issues which are undergoing=0A= further testing before release to customers. We can't send these to=0A= qemu-devel as we have made extensive use of Claude Opus 5 in all=0A= aspects of this work from defining the test environment, the test=0A= strategy and automation to implement it, post-run analysis and gap=0A= detection, and finally implementation of the solution fixes. All text=0A= in this message is mine with the exception of the data tables.=0A= =0A= We did feel though that it was only right that we made you aware of=0A= the issues we have found so that you can make your own decisions about=0A= them and whether to address them.=0A= =0A= I'm happy to have any further conversation on this as you deem=0A= necessary.=0A= =0A= Regards,=0A= =0A= Mark=0A= XenServer Storage Engineering.=0A= From xen-devel-bounces@lists.xenproject.org Wed Sep 16 09:34:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 09:34:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422523.1647892 (Exim 4.92) (envelope-from ) id 1x6m1j-0001T5-FD; Wed, 16 Sep 2026 09:34:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422523.1647892; Wed, 16 Sep 2026 09:34:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6m1j-0001Sy-Cd; Wed, 16 Sep 2026 09:34:03 +0000 Received: by outflank-mailman (input) for mailman id 1422523; Wed, 16 Sep 2026 09:34:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6m1h-0001Ss-V5 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 09:34:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6m1h-00EySy-BW for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:34:01 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa6285-8faa-0a2a0a5109dd-0a2a450892e8-28 for ; Wed, 16 Sep 2026 11:34:01 +0200 Received: from [103.168.172.155] (helo=fhigh-a4-smtp.messagingengine.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa6287-f659-0a2a45080019-67a8ac9bdc77-3 for ; Wed, 16 Sep 2026 11:34:00 +0200 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id AF8E514001FD; Wed, 16 Sep 2026 05:33:59 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Wed, 16 Sep 2026 05:33:59 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Sep 2026 05:33:58 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:Message-ID:MIME-Version:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm1; t=1789551239; x=1789637639; bh=LW pTYQZgKfMCkuYeRduPa053Fwih7qDBbKTFi2jaGEY=; b=ZNi06WFEQai14WQwOY r3i0BkR+NllOXiPj9a36D0lscVvBVRH5alYJ+up8AfVSpLbRU6aCmb511pN/PTHn h7kDGwd7cjevfQK5E1dlTFt1qA4nq0m5qIcKgFXZwntx23F9jwtWn+OM1MtGiOhC /Ve1i48d38yHiKmYRtxJG0uXQYylyWT3vevwJOP6L9/j5C1jIvURu81p0SrE6Hin Ub1Izp+xdly3QukFfBqjwul2Ze3Tuo1I3SSgioepzWOXzxNMiHs8zlynCE6OCcZy A7y8QgCh2akGaVrlUbJQnhKQA2W8pDV0VtvwwLmLoVdAKhw1nk0XtwwTMHM/ypwe xm+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1789551239; x= 1789637639; bh=LWpTYQZgKfMCkuYeRduPa053Fwih7qDBbKTFi2jaGEY=; b=S v+oQx6ZXkLQCSm7xMf2OKjeIhGywPNagEdvTmR4bZsCl1PLha3sj5Cj2m73ne89b unYgeUH/FV/7o6QHagFqMigzj2N98I4bZoUK49AexvZAD7P+WL4TZF7LfaCW3VM6 uYcbJx6f4BvQwezOddgwEaZMg6gbWM5PXfePcN0PPKesKRwehBmewxfGogkraIu6 ZATZ02ENlL9LzoWXrS8fKBjZyq9MGiYy+BMWcDAg9CDCltvlKVYF2vR86lDdpZSn PJVN8skKnbpqxIMPm8hUR6u1lVk/Vp2V0k2lh2Zl7AN/onyUd5Aj/gEm2OFmZudA fF0b8qWqxV6Whg6H/3tHg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEc+7cC+aORsuuJJRdg6p2lxD1IHfyjNi4R3dq07RP4R5Y+HVBi7D9bzsE/UDdLBC 7CD7vDZe6ClS2P/K1nCP9tvAF/sAgAzBxyBVTwQvJ0DM38x2bf0aIINwTz7EtXTq6/2ZJp 5otaxbs57LvjtbdYd2KBFMHFNMNXDjESkTeNF6d0Hywg9HzIaRJUZXh+rXSuowX2RiMkCg riy76luua9iPrUfwt8eshCOguIh/Ga1RdiuPpzRSbaZAtdG0V6I7ufJNowAsctniyWZdqy 5q75xZWUoSjb1yASeKFS02hUcshGnw6TmlZ1tG5+JQ2Dip80u5EgI3kbC+Ut7vf6S0+jBk UhEk0L9qB6XyO4KPXjG5H1F9+shtorkRkkt6o5SlM8sL/5H4rMDS9VZW7aAL2vdr2JSrQu pGCD/rf8hHLynQUxcYT4DRSH/heFA23DxYcZb7eyBN2nVxDzsmGjZ3iHp5EzKFDO7zgVWZ KrQqFew2WmFf/M+YYjmjyACorkv1e/T78ovPVAg7Wrr/C9whDbzxxxnpkMSljr0CrFiAuZ 6B/uX0IBZ9Q3tMIDyM60+BX+7GDNxgszk51jqggkuorqduvu7J/lmAgXCPBoO3t9GdYYgd 09VJyPZg/5QroMzMqJjcwJExxEne+hUP9iftqnrVTOjSBsl6I3+QcpA0Sryg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Wed, 16 Sep 2026 11:33:57 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Teddy Astie Subject: Test report: IGD (RPL) SR-IOV on Xen - Linux 7.2.5, xe Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NmWEiZWwkdeD2rFi" Content-Disposition: inline X-purgate-ID: tlsNG-c1860d/1789551241-D594A87B-29B048F9/0/0 X-purgate-type: clean X-purgate-size: 16345 --NmWEiZWwkdeD2rFi Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Sep 2026 11:33:57 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: xen-devel Cc: Teddy Astie Subject: Test report: IGD (RPL) SR-IOV on Xen - Linux 7.2.5, xe Hi, I was talking with Teddy about SR-IOV of Intel GPU and decided to repeat the test. My setup is: Hardware: Intel Raptor Lake system with: 00:02.0 Display controller [0380]: Intel Corporation Raptor Lake-S GT1 [UHD= Graphics 770] [8086:a780] (rev 04) Software: Qubes 4.3 with Xen 4.19.5 (PV) Dom0 Linux 6.18.51, with "xe.force_probe=3Da780 i915.force_probe=3D!a7= 80" on cmdline DomU Linux 7.2.5, also with "xe.force_probe=3Da780 i915.force_probe=3D!a780" on cmdline Hardware-wise, this platform should support SR-IOV: https://www.intel.com/content/www/us/en/support/articles/000093216/graphics= /processor-graphics.html But software-wise, the "xe" driver doesn't officially support this platform - this one is officially still on i915 - which in upstream version doesn't support SR-IOV at all. There is a i915 branch from Intel with SR-IOV support added, but it isn't maintained anymore, and I had worse results with it (although some people report it worked for them). I tried also LNL, but the one I have does not advertise SR-IOV at all (not sure if hardware lacking, or disabled at firmware level). I have also PTL that should theoretically be better, but userspace side on the current Qubes OS version is too old for that, so it's more complicated for me to test. Anyway, back to RPL: Dom0 steps: echo 7 > /sys/bus/pci/devices/0000:00:02.0/sriov_numvfs This makes the VFs to appear, now they can be assigned to a domU (I used 00:02.1). Dom0 messages on boot: [ 6.063363] xe 0000:00:02.0: [drm] Running in SR-IOV PF mode [ 6.063373] xe 0000:00:02.0: [drm] Found alderlake_s/raptorlake_s (devic= e ID a780) integrated display version 12.00 stepping D0 [ 6.119874] xe 0000:00:02.0: [drm] Finished loading DMC firmware i915/ad= ls_dmc_ver2_01.bin (v2.1) [ 6.129583] xe 0000:00:02.0: [drm] Tile0: GT0: Using GuC firmware from i= 915/tgl_guc_70.bin version 70.49.4 [ 6.134506] xe 0000:00:02.0: [drm] Tile0: GT0: Using HuC firmware from i= 915/tgl_huc.bin version 7.9.3 [ 6.224163] xe 0000:00:02.0: [drm] Tile0: GT0: vcs1 fused off [ 6.224237] xe 0000:00:02.0: [drm] Tile0: GT0: vcs3 fused off [ 6.224240] xe 0000:00:02.0: [drm] Tile0: GT0: vcs4 fused off [ 6.224244] xe 0000:00:02.0: [drm] Tile0: GT0: vcs5 fused off [ 6.224248] xe 0000:00:02.0: [drm] Tile0: GT0: vcs6 fused off [ 6.224251] xe 0000:00:02.0: [drm] Tile0: GT0: vcs7 fused off [ 6.224255] xe 0000:00:02.0: [drm] Tile0: GT0: vecs1 fused off [ 6.224259] xe 0000:00:02.0: [drm] Tile0: GT0: vecs2 fused off [ 6.224262] xe 0000:00:02.0: [drm] Tile0: GT0: vecs3 fused off [ 6.242973] xe 0000:00:02.0: [drm] Registered 4 planes with drm panic [ 6.242979] [drm] Initialized xe 1.1.0 for 0000:00:02.0 on minor 0 [ 6.323673] xe 0000:00:02.0: [drm] Allocated fbdev into stolen failed: -= 12 [ 6.326272] Console: switching to colour frame buffer device 128x48 [ 6.343560] xe 0000:00:02.0: [drm] fb1: xedrmfb frame buffer device And then on adding VFs: [ 274.829735] xe 0000:00:02.0: [drm] Tile0: GT0: PF: VF1..VF7 provisioned = with 598138880 (570 MiB) GGTT [ 274.830257] xe 0000:00:02.0: [drm] Tile0: GT0: PF: VF1..VF7 provisioned = with 9324 GuC context IDs [ 274.831069] xe 0000:00:02.0: [drm] Tile0: GT0: PF: VF1..VF7 provisioned = with 36 GuC doorbell IDs [ 274.935797] pci 0000:00:02.1: [8086:a780] type 00 class 0x038000 PCIe Ro= ot Complex Integrated Endpoint [ 274.935947] pci 0000:00:02.1: DMAR: Skip IOMMU disabling for graphics [ 274.936569] i915 0000:00:02.1: I915 probe blocked for Device ID a780. [ 274.936607] xe 0000:00:02.1: enabling device (0000 -> 0002) [ 274.940247] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode [ 274.940272] xe 0000:00:02.1: [drm] VF: migration disabled: experimental = feature not available on production builds [ 274.958658] xe 0000:00:02.1: [drm] Tile0: GT0: vcs1 fused off [ 274.958664] xe 0000:00:02.1: [drm] Tile0: GT0: vcs3 fused off [ 274.958668] xe 0000:00:02.1: [drm] Tile0: GT0: vcs4 fused off [ 274.958671] xe 0000:00:02.1: [drm] Tile0: GT0: vcs5 fused off [ 274.958674] xe 0000:00:02.1: [drm] Tile0: GT0: vcs6 fused off [ 274.958677] xe 0000:00:02.1: [drm] Tile0: GT0: vcs7 fused off [ 274.958680] xe 0000:00:02.1: [drm] Tile0: GT0: vecs1 fused off [ 274.958683] xe 0000:00:02.1: [drm] Tile0: GT0: vecs2 fused off [ 274.958686] xe 0000:00:02.1: [drm] Tile0: GT0: vecs3 fused off [ 274.964105] [drm] Initialized xe 1.1.0 for 0000:00:02.1 on minor 1 [ 274.964276] pci 0000:00:02.2: [8086:a780] type 00 class 0x038000 PCIe Ro= ot Complex Integrated Endpoint [ 274.964297] pci 0000:00:02.2: DMAR: Skip IOMMU disabling for graphics [ 274.964426] i915 0000:00:02.2: I915 probe blocked for Device ID a780. [ 274.964440] xe 0000:00:02.2: enabling device (0000 -> 0002) [ 274.965163] xe 0000:00:02.2: [drm] Running in SR-IOV VF mode [ 274.965167] xe 0000:00:02.2: [drm] VF: migration disabled: experimental = feature not available on production builds [ 274.981117] xe 0000:00:02.2: [drm] Tile0: GT0: vcs1 fused off [ 274.981124] xe 0000:00:02.2: [drm] Tile0: GT0: vcs3 fused off [ 274.981127] xe 0000:00:02.2: [drm] Tile0: GT0: vcs4 fused off [ 274.981130] xe 0000:00:02.2: [drm] Tile0: GT0: vcs5 fused off [ 274.981134] xe 0000:00:02.2: [drm] Tile0: GT0: vcs6 fused off [ 274.981137] xe 0000:00:02.2: [drm] Tile0: GT0: vcs7 fused off [ 274.981140] xe 0000:00:02.2: [drm] Tile0: GT0: vecs1 fused off [ 274.981143] xe 0000:00:02.2: [drm] Tile0: GT0: vecs2 fused off [ 274.981146] xe 0000:00:02.2: [drm] Tile0: GT0: vecs3 fused off [ 274.986586] [drm] Initialized xe 1.1.0 for 0000:00:02.2 on minor 2 [ 274.986666] pci 0000:00:02.3: [8086:a780] type 00 class 0x038000 PCIe Ro= ot Complex Integrated Endpoint [ 274.986690] pci 0000:00:02.3: DMAR: Skip IOMMU disabling for graphics [ 274.986873] i915 0000:00:02.3: I915 probe blocked for Device ID a780. [ 274.986886] xe 0000:00:02.3: enabling device (0000 -> 0002) [ 274.987857] xe 0000:00:02.3: [drm] Running in SR-IOV VF mode [ 274.987949] xe 0000:00:02.3: [drm] VF: migration disabled: experimental = feature not available on production builds [ 275.000724] xe 0000:00:02.3: [drm] Tile0: GT0: vcs1 fused off [ 275.000730] xe 0000:00:02.3: [drm] Tile0: GT0: vcs3 fused off [ 275.000733] xe 0000:00:02.3: [drm] Tile0: GT0: vcs4 fused off [ 275.000736] xe 0000:00:02.3: [drm] Tile0: GT0: vcs5 fused off [ 275.000739] xe 0000:00:02.3: [drm] Tile0: GT0: vcs6 fused off [ 275.000742] xe 0000:00:02.3: [drm] Tile0: GT0: vcs7 fused off [ 275.000745] xe 0000:00:02.3: [drm] Tile0: GT0: vecs1 fused off [ 275.000748] xe 0000:00:02.3: [drm] Tile0: GT0: vecs2 fused off [ 275.000751] xe 0000:00:02.3: [drm] Tile0: GT0: vecs3 fused off [ 275.005750] [drm] Initialized xe 1.1.0 for 0000:00:02.3 on minor 3 [ 275.005819] pci 0000:00:02.4: [8086:a780] type 00 class 0x038000 PCIe Ro= ot Complex Integrated Endpoint [ 275.005844] pci 0000:00:02.4: DMAR: Skip IOMMU disabling for graphics [ 275.006222] i915 0000:00:02.4: I915 probe blocked for Device ID a780. [ 275.006236] xe 0000:00:02.4: enabling device (0000 -> 0002) [ 275.007191] xe 0000:00:02.4: [drm] Running in SR-IOV VF mode [ 275.007197] xe 0000:00:02.4: [drm] VF: migration disabled: experimental = feature not available on production builds [ 275.023297] xe 0000:00:02.4: [drm] Tile0: GT0: vcs1 fused off [ 275.023303] xe 0000:00:02.4: [drm] Tile0: GT0: vcs3 fused off [ 275.023306] xe 0000:00:02.4: [drm] Tile0: GT0: vcs4 fused off [ 275.023309] xe 0000:00:02.4: [drm] Tile0: GT0: vcs5 fused off [ 275.023312] xe 0000:00:02.4: [drm] Tile0: GT0: vcs6 fused off [ 275.023315] xe 0000:00:02.4: [drm] Tile0: GT0: vcs7 fused off [ 275.023318] xe 0000:00:02.4: [drm] Tile0: GT0: vecs1 fused off [ 275.023321] xe 0000:00:02.4: [drm] Tile0: GT0: vecs2 fused off [ 275.023324] xe 0000:00:02.4: [drm] Tile0: GT0: vecs3 fused off [ 275.028862] [drm] Initialized xe 1.1.0 for 0000:00:02.4 on minor 4 [ 275.028936] pci 0000:00:02.5: [8086:a780] type 00 class 0x038000 PCIe Ro= ot Complex Integrated Endpoint [ 275.028958] pci 0000:00:02.5: DMAR: Skip IOMMU disabling for graphics [ 275.029139] i915 0000:00:02.5: I915 probe blocked for Device ID a780. [ 275.029151] xe 0000:00:02.5: enabling device (0000 -> 0002) [ 275.030260] xe 0000:00:02.5: [drm] Running in SR-IOV VF mode [ 275.030266] xe 0000:00:02.5: [drm] VF: migration disabled: experimental = feature not available on production builds [ 275.042968] xe 0000:00:02.5: [drm] Tile0: GT0: vcs1 fused off [ 275.042974] xe 0000:00:02.5: [drm] Tile0: GT0: vcs3 fused off [ 275.042977] xe 0000:00:02.5: [drm] Tile0: GT0: vcs4 fused off [ 275.042980] xe 0000:00:02.5: [drm] Tile0: GT0: vcs5 fused off [ 275.042983] xe 0000:00:02.5: [drm] Tile0: GT0: vcs6 fused off [ 275.042986] xe 0000:00:02.5: [drm] Tile0: GT0: vcs7 fused off [ 275.042989] xe 0000:00:02.5: [drm] Tile0: GT0: vecs1 fused off [ 275.042992] xe 0000:00:02.5: [drm] Tile0: GT0: vecs2 fused off [ 275.042995] xe 0000:00:02.5: [drm] Tile0: GT0: vecs3 fused off [ 275.047932] [drm] Initialized xe 1.1.0 for 0000:00:02.5 on minor 5 [ 275.048093] pci 0000:00:02.6: [8086:a780] type 00 class 0x038000 PCIe Ro= ot Complex Integrated Endpoint [ 275.048125] pci 0000:00:02.6: DMAR: Skip IOMMU disabling for graphics [ 275.048443] i915 0000:00:02.6: I915 probe blocked for Device ID a780. [ 275.048456] xe 0000:00:02.6: enabling device (0000 -> 0002) [ 275.049613] xe 0000:00:02.6: [drm] Running in SR-IOV VF mode [ 275.049622] xe 0000:00:02.6: [drm] VF: migration disabled: experimental = feature not available on production builds [ 275.068094] xe 0000:00:02.6: [drm] Tile0: GT0: vcs1 fused off [ 275.068100] xe 0000:00:02.6: [drm] Tile0: GT0: vcs3 fused off [ 275.068103] xe 0000:00:02.6: [drm] Tile0: GT0: vcs4 fused off [ 275.068107] xe 0000:00:02.6: [drm] Tile0: GT0: vcs5 fused off [ 275.068110] xe 0000:00:02.6: [drm] Tile0: GT0: vcs6 fused off [ 275.068113] xe 0000:00:02.6: [drm] Tile0: GT0: vcs7 fused off [ 275.068116] xe 0000:00:02.6: [drm] Tile0: GT0: vecs1 fused off [ 275.068119] xe 0000:00:02.6: [drm] Tile0: GT0: vecs2 fused off [ 275.068122] xe 0000:00:02.6: [drm] Tile0: GT0: vecs3 fused off [ 275.073227] [drm] Initialized xe 1.1.0 for 0000:00:02.6 on minor 6 [ 275.073299] pci 0000:00:02.7: [8086:a780] type 00 class 0x038000 PCIe Ro= ot Complex Integrated Endpoint [ 275.073323] pci 0000:00:02.7: DMAR: Skip IOMMU disabling for graphics [ 275.073512] i915 0000:00:02.7: I915 probe blocked for Device ID a780. [ 275.073525] xe 0000:00:02.7: enabling device (0000 -> 0002) [ 275.074485] xe 0000:00:02.7: [drm] Running in SR-IOV VF mode [ 275.074581] xe 0000:00:02.7: [drm] VF: migration disabled: experimental = feature not available on production builds [ 275.088133] xe 0000:00:02.7: [drm] Tile0: GT0: vcs1 fused off [ 275.088139] xe 0000:00:02.7: [drm] Tile0: GT0: vcs3 fused off [ 275.088142] xe 0000:00:02.7: [drm] Tile0: GT0: vcs4 fused off [ 275.088146] xe 0000:00:02.7: [drm] Tile0: GT0: vcs5 fused off [ 275.088149] xe 0000:00:02.7: [drm] Tile0: GT0: vcs6 fused off [ 275.088152] xe 0000:00:02.7: [drm] Tile0: GT0: vcs7 fused off [ 275.088155] xe 0000:00:02.7: [drm] Tile0: GT0: vecs1 fused off [ 275.088159] xe 0000:00:02.7: [drm] Tile0: GT0: vecs2 fused off [ 275.088162] xe 0000:00:02.7: [drm] Tile0: GT0: vecs3 fused off [ 275.093163] [drm] Initialized xe 1.1.0 for 0000:00:02.7 on minor 7 [ 275.093338] xe 0000:00:02.0: [drm] PF: Enabled 7 of 7 VFs And then domU kernel messages: [ 101.601460] xe 0000:00:07.0: [drm] Running in SR-IOV VF mode [ 101.601479] xe 0000:00:07.0: [drm] VF: migration disabled: experimental = feature not available on production builds [ 101.616800] xe 0000:00:07.0: [drm] Tile0: GT0: vcs1 fused off [ 101.616818] xe 0000:00:07.0: [drm] Tile0: GT0: vcs3 fused off [ 101.616831] xe 0000:00:07.0: [drm] Tile0: GT0: vcs4 fused off [ 101.616844] xe 0000:00:07.0: [drm] Tile0: GT0: vcs5 fused off [ 101.616856] xe 0000:00:07.0: [drm] Tile0: GT0: vcs6 fused off [ 101.616872] xe 0000:00:07.0: [drm] Tile0: GT0: vcs7 fused off [ 101.616885] xe 0000:00:07.0: [drm] Tile0: GT0: vecs1 fused off [ 101.616899] xe 0000:00:07.0: [drm] Tile0: GT0: vecs2 fused off [ 101.616912] xe 0000:00:07.0: [drm] Tile0: GT0: vecs3 fused off [ 101.623546] [drm] Initialized xe 1.1.0 for 0000:00:07.0 on minor 0 but when actually trying to use the device, it fails: [ 177.031375] xe 0000:00:07.0: [drm] Tile0: GT0: Schedule disable failed t= o respond, guc_id=3D2 [ 177.031520] xe 0000:00:07.0: [drm] Xe device coredump has been created [ 177.031558] xe 0000:00:07.0: [drm] Check your /sys/class/drm/card0/devic= e/devcoredump/data [ 177.031598] xe 0000:00:07.0: [drm] Tile0: GT0: trying reset from guc_exe= c_queue_timedout_job [xe] [ 177.031934] xe 0000:00:07.0: [drm] Tile0: GT0: reset queued [ 177.031985] xe 0000:00:07.0: [drm] Tile0: GT0: reset started [ 177.092882] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0xffff [ 177.143396] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.211682] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.270458] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.333223] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.392473] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.447398] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.515673] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.574551] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.637391] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: GuC mmio request = 0x5507: no reply 0x5507 [ 177.637455] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: VF: Failed to res= et GuC state (-ETIMEDOUT) [ 177.637537] xe 0000:00:07.0: [drm] *ERROR* Tile0: GT0: reset failed (-ET= IMEDOUT) [ 177.637610] xe 0000:00:07.0: [drm] *ERROR* CRITICAL: Xe has declared dev= ice 0000:00:07.0 as wedged. [ 177.637610] IOCTLs and executions are blocked. Only a rebind may clear t= he failure [ 177.637610] Please file a _new_ bug report at https://gitlab.freedesktop= =2Eorg/drm/xe/kernel/issues/new [ 177.637744] xe 0000:00:07.0: [drm] device wedged, needs recovery [ 177.637842] xe 0000:00:07.0: [drm] Tile0: GT0: Timedout job: seqno=3D429= 4967175, lrc_seqno=3D4294967175, guc_id=3D2, flags=3D0x0 in Xorg [1388] Full logs, note multiple files there (unfortunately start of Xen log is cut= ): https://gist.github.com/marmarek/fe5cdd3a82efc75a02f5b3050e6b5c89 I kinda suspect getting similar result on PTL, but I'll hold off with the proper bug report until I can actually confirm it. I'll repeat the test on Xen 4.22 later. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --NmWEiZWwkdeD2rFi Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqqYoUACgkQ24/THMrX 1yznMgf9FGkgF3LjGrMzbMYdVZJLexSo/N5oqdFOTNduAirhZt8wkZLW4TmRQIx+ /6tsxRlZsbNfE9Hc27fKgFjU+Ry5toMJH4Q1WvAXjkzjHRREvUf/jQTX+OyCs/8C wf6sdprXKUxKIT2AIcYFOoBNUUAT77Bp4AJaZTkwmFesAbW4JUqHezPomK1cFdbR 85YfTJtboX5JzGrR8W5AQPuZ4vnlTTcgRTcHK6nhn7VpM42rQsrteE2SM5HJmxmd 1t+E9uwzYr/t26zMNAR9c+6SrAL84/7R4m3NPDYydJOFAsYbCFNyTpOD77CQ7srM hFBHQQohr1fpVbCGw0+hECdAWEsJ7w== =yRu6 -----END PGP SIGNATURE----- --NmWEiZWwkdeD2rFi-- From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:28:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:28:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422548.1647901 (Exim 4.92) (envelope-from ) id 1x6msO-00081U-BO; Wed, 16 Sep 2026 10:28:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422548.1647901; Wed, 16 Sep 2026 10:28:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6msO-00081N-8d; Wed, 16 Sep 2026 10:28:28 +0000 Received: by outflank-mailman (input) for mailman id 1422548; Wed, 16 Sep 2026 10:28:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6msM-00081H-Vg for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:28:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6msM-00GIsp-42 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:28:26 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa6f2f-8faa-0a2a0a5109dd-0a2a450bd21e-36 for ; Wed, 16 Sep 2026 12:28:25 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa6f47-b7e8-0a2a450b0019-a0658308cacc-3 for ; Wed, 16 Sep 2026 12:28:25 +0200 Received: from xenrt10716048 (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 74C7F454676F; Wed, 16 Sep 2026 06:26:16 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Lin Liu To: jbeulich@suse.com Cc: abdelkareem.abdelsaamad@citrix.com, andrew.cooper3@citrix.com, jason.andryuk@amd.com, lin.liu01@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/nSVM: Validate the L1 MSRPM physical address range Date: Wed, 16 Sep 2026 10:28:10 +0000 Message-ID: <20260916102810.763302-1-lin.liu01@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <85e4aa12-7fc8-4c52-9fdc-ca4408cc9375@suse.com> References: <85e4aa12-7fc8-4c52-9fdc-ca4408cc9375@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789554505-A8ECE9EA-AC878ECE/0/0 X-purgate-type: clean X-purgate-size: 1450 On 16.09.2026 07:07, Jan Beulich wrote: > Non-RAM is rejected in other situations as well, where in principle the > same behavior you describe could apply. Hence imo if we wanted to go > that route, I think we'd want to be consistent. That would be quite a > bit more work. Agreed - I'm dropping the series. My premise was wrong in any case. 15.10.1 (p.537) and 15.11 (p.539) both say the map "should reside in memory that is mapped as writeback (WB)", which I had missed, so an unbacked map is outside the contract rather than legal-but-refused. The range check is redundant too: an out-of-range address cannot be populated, so the copy already rejects it. And "match what hardware does" would not be a consistent rule even in principle, because hardware is not uniform here. On EPYC 9255 / 9965 / 8324P, with a non-nested guest's own VMCB pointed at each address: in-range unpopulated hole accepted; map reads as all ones SMRAM (inside an enabled TSeg) VMRUN hard-rejected, both maps one page above TSeg accepted The TSeg boundary is the discriminator, not MMIO-vs-RAM; Andrew predicted that offline. One incidental result: at that last address the bitmap is real firmware data, the EFER read bit happened to be clear, and the guest read the host's real EFER with SVME set before triple-faulting - an argument for rejecting rather than guessing. Thanks for the help to review. Lin From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422577.1647919 (Exim 4.92) (envelope-from ) id 1x6n8L-0002Ta-Q9; Wed, 16 Sep 2026 10:44:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422577.1647919; Wed, 16 Sep 2026 10:44:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8L-0002TT-ND; Wed, 16 Sep 2026 10:44:57 +0000 Received: by outflank-mailman (input) for mailman id 1422577; Wed, 16 Sep 2026 10:44:56 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8K-0002TN-8s for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:44:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8J-002G1v-H8 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:44:55 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7321-e002-0a2a0a5209dd-0a2a45018ec4-24 for ; Wed, 16 Sep 2026 12:44:55 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7325-5984-0a2a45010019-94a39744a086-3 for ; Wed, 16 Sep 2026 12:44:55 +0200 Received: from pps.filterd (m0127839.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8NpPu539450; Wed, 16 Sep 2026 03:44:44 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020142.outbound.protection.outlook.com [52.101.46.142]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0pt9xh-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:44:44 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MW4PR02MB7380.namprd02.prod.outlook.com (2603:10b6:303:74::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 10:44:41 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:44:41 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=prUedyp4AYuc7mLB5VI6y/YZt603NMIJq8WEZ9TCJ CA=; b=FIBYkMQKRY8M7UhxUNQSJvQ4jvq22gaAwa7lYbJLyKlXEdCRcZthh6oSx PA7ZtsmyiktmbYj8FIBvGWROVhwqYwRDC1scewmC0y/CrT1+wy5Q/MreJgkdMDnF jXyPdTAAkVvJDmkY8/qD+WoqCUmH5RkY0Pr01HVrkN85Ot8GBqoCSA583PVrVcFo s4ZMkosZ/hU8yLZM2HZ3LpSncEu/EfAQj0DpRmFjkUaZTJaOR1Qfn5ooHJrE/RaY H/GzClR1ii35zJl17RNkbeFrssSakKSQtgXX9nWVQ04ftv4wXgkK2ToCT45Kso5M O8L2nW3YtblrFc+G0h8ucSKTdqxow== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=flhFFEppQEBRdsHvOmRubo5NntVuDipcwFr6iadkFrI41ndIBqwa2gILt/QNrRCgMMuWJFMvzS1Kh4hzHEaIso/g/7MAtHyGAyuKgcPMm8/dJ3S/OcM23xbVUl3KnNTA6LYQrhRZfw0tmgrZKTWYRDCpz43D3PR2wWKfJ0BJ66XEgre4fgMZyzXv1VUFWPnV0tP+/N7MqJLH5YYWtpo6tbvvLbYAl3a9+wBgLSwSbBXXKKblS0utOdybx25ismav1iDJoc5gsySLfDVJwRTvae3BS4o3APpf8r6M7wGNRN15bMqsbwCwDjWGH51ZBHGZQDBwMT+KMhfNft38EfCl2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=prUedyp4AYuc7mLB5VI6y/YZt603NMIJq8WEZ9TCJCA=; b=Ib3WNAbScNxPoRiv9cjY774vkDzGAeltmam54wTaJBvQ1QYCYbES51CKHWc/4HU93u+cZiy55yR8UwhSE0NylBJmtTCYN3h8cV+CVzxmbIqCFd6A3hYlG3RflBHEj9G17JWYXY5x7pqke8PxxgGVncBPUiqKghceeYg/Lx/bBmOiWoqF6iep3leWJjumPk2NznL0ZZ3DVYk3gM7APxp5UzvGzgneUXP4erutTTNQmR6ZaVQdjz7C/qSebDM359gubHNHYWqyBvE7uB5iK9yVGkMKZasXVPUHe5w1aXA7pfVFnl6fyWPzuYMYjY06pTV3eNJ9r1tVX8LgON5IEVvfPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=prUedyp4AYuc7mLB5VI6y/YZt603NMIJq8WEZ9TCJCA=; b=Xfvxz5kMUI7cPZkRE5O/VeNgwqUKCgSW1AM8pfAfMFvjeL2TjgKzYxdBtqkX/hrypzJP1pGrjnL2xf0OjE4liIqxMlJQ6vXGYZXShYuUAAsMkozPIkOtWFkE1NzbSPeo8tLIucOKp+cOusy9xvfeHYG6rItAtI1F1k67SIiHxtwevoArEvPZqgV3HAUOHdP1QzVp3kw5kZT2faFYR7pdVk8DWUb5tbvpQNJ3OwjzIpratTgj0lKkjn8oB9cnCR1gEbpfWRpCBAnwfAU7nSComssNUZHO+bE7x4EmdTxN/7v1tL1QIGfCHx5MJTC8/DFCsi9yWj7oS4ZJGtBs0/jceg== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 01/22] i8259_internal.h: rename PIC_COMMON to I8259_COMMON Date: Wed, 16 Sep 2026 11:43:29 +0100 Message-ID: <20260916104435.600211-2-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0277.namprd03.prod.outlook.com (2603:10b6:a03:39e::12) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MW4PR02MB7380:EE_ X-MS-Office365-Filtering-Correlation-Id: b928cdc9-c82a-4b3b-cb26-08df13df837f x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|22082099003|10067099003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: 78SkZK4UYr7breG+pCgv55dS6aPSQVRgF0mjs1+rCRh7cigI75iKm1oRfZW5NsAl9pwbAPDEFK463uUdh+4rxAh7qO2rZ2R3/WOeXLkSrBh1waGcHiokxogWH8pD24R16YzkyGKqJxur28+nriKF/vVP1wRzFt2jmgKyjkPiBIpPkrPuSaiz5rdH7hFx/kcx3KdGl2jF4OkNYd6zQIhF4r2eBUErog+P3O9qstKlaSBcfjjU/KaSoOkWLTWCSmKce8SvoRyReldBIrkC9BWDItakSU+qpU4yGSI5ZX4tjJcD1nhTBSaLyYQxvEq6L0FXA8ufQ/Sh/2FM0GWMU7QP7+I9BWZTg2DLoi5HEhqhPwHEYzyOg5E3rhIAQ60Vl9oYiOm2pA0C+Tz4gmnTlbA08mlpJv0or04kDLtwE+vS+PVjf12K8gEMOHFRp3wmxhqVX/dZywIFjfRzioUMBHPXJR/9Ukd7WmFIL+5GW1yrsSRnmCpz0aDNiZm9sJcwZoqwScpFkC4JEIwKC2BHg8hJMifFLSSIXvvbT5IelOQkDGo/Nh0l3gAlbdVxGOimsVzkeLX5TuPTs8w0cY+H3VibTNdw2DEo/dsMASulNNbGAmyN5fHw5VaFsPwBuzpn1T0RZP2o5mOiafimOx+MVJXgQPWpFAbJlI5e+nVC3AQdLnA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(22082099003)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RH+VyBB8HlGNe00NDjHfYo8XhmlIniyU6P6S9VYvU9U3PmlVC6/6jZ6k/fkS?= =?us-ascii?Q?WZv0/M9hC6EoxCajWQnud7cV574I/KId+B5eDa5Jq0q5c2qDQBwAB6Sznx8O?= =?us-ascii?Q?BOuq0Q1EubOsTgLsnGzyP/T0f/SR5eerX3obqQJMlynIj6fMPFn4S7DUU3q6?= =?us-ascii?Q?V5OQaNxy4sizA6Qi50TK4YDeguV6eEMrrPBe2xmOL5rOWqobMGIjGXXyY8sP?= =?us-ascii?Q?EDfC9A6EnSOhgCPPKcOWdbpy/de29HTTS70IvpVdmtsaUzeu0em+tPwqzOyE?= =?us-ascii?Q?OB/A12vLKB2/lmYuW7kLoUFgxQwH+uPOuDtamQtbnOWbmjq9FbDfgP3toPAe?= =?us-ascii?Q?1E0TeHFpq4DnH5neOlPPJmvDoRQwLMHkc3ukaxTQpLCt7Z+AbUloT+MRuQU0?= =?us-ascii?Q?BS6vP1G9BkKKpjkecBcjO7Z4RLiA6/1K62puqf6K2w4h0yMWE6RbzQe/Cypz?= =?us-ascii?Q?Iau6ztZFdFpNrywO1uzFVf8vOx2dHVmaQPGseQHlx9W1QnzDB/kOdDUX3xEe?= =?us-ascii?Q?RZU2RmmU+RppWtr0pd2n+ibK0yaLSii8h9iA8If2EUStvPVf1XvOXp42Ffof?= =?us-ascii?Q?x+6NG+Xqr46d3uiZZkePBwuPlpnmsD3g+1X3ywsHVPKvzytXJ4hVyc2q1UDr?= =?us-ascii?Q?wcBocxHSpV8BSSMdn7T9yRZm5x3f39p7FlqCNVuPEQmS7lukRYmeeYv0XFnZ?= =?us-ascii?Q?kAXVXA3/tytaO4bA3F03u2YhwEdJyIkiAr5cnfX+wHRoT/otJKnW0+lDIPGh?= =?us-ascii?Q?wcdCUbKUy6Gb2swtKlw1Vc31YublLys5NgTAi5VXHBCKr/VPuC2QyfqPc3tf?= =?us-ascii?Q?rsbu3RnwKj1yHTBXn4sj5SgBz78AwkcLpvue+Hu7Ku9CZTLtqAEsraByKJsS?= =?us-ascii?Q?hkUlMOP67ElisIYZq1nfLk5fHH3GbPDs/Phnljcj1gBL79MFW6oPOX0JgCbJ?= =?us-ascii?Q?6FgUZF1BSohvdXFJyKVG73r8qBneQipgeDXC6htz7PDrOAUhnH05SSGY+5E1?= =?us-ascii?Q?ZPtVPPRs5wH/YDhIgt7HJj3rVauNld6LQRC+iJ99Dar9FxSm1FAa84eG/YZv?= =?us-ascii?Q?Q/HF4uDQ1E6u414Z0Vj9qE5XP3qG//Ib9oQBgxl1RxMw+8jLExahuSKaMlI5?= =?us-ascii?Q?eELIIsnYeg+ngalyfFRkS3UwghKdJvfVbfjQY3BtLVP4mXHCA14AlEEl/ELA?= =?us-ascii?Q?UX4Pjl5teXFIiRKfUzvJp7yP8MgpVhH1VfdwqY6aaGV9Ky7iWSAlrXPLSC//?= =?us-ascii?Q?aMiQBrpWedMTLjw1Uf+QFdmCXRGOf8MAuc0OiWMRFwyag4wuqm5O5p57tkSV?= =?us-ascii?Q?gA6zrO4EhdUOyeDH+/KhD7f/uAFm+cw5qtYG38J54P6ufQ70EUlWS9y/ogcr?= =?us-ascii?Q?lE2lP7+YraXNkGCf7rsvhhZdfYl34dzQzrSbvfQVeXXNQ4gikWRlUhRYIicO?= =?us-ascii?Q?L6Lx+7eE3iPJBefXJ9g6XNuxCZscD/wne1/TzHFJDeP4EUP6gZzBCNV9ms5m?= =?us-ascii?Q?XHapHj7hkZ0xKsruQRywFzmXs1Q4j2zmNKvyJb36RLIeMqW8/JQPilvTf1Tu?= =?us-ascii?Q?ie+FFplp2k0vvRug8ZuqokstwhiUQASAVjYQuSWE8MrYLRvzE+bRKhV1e+lK?= =?us-ascii?Q?tFOvevm0M59z4Z41SHJgi8aoPZojR0FAghIFx6oZgvUtdPSERVj0pXPv5RGh?= =?us-ascii?Q?WItkY0LOUT48qbwQHzeY6Psdg+LVpuFpUdMeCxWzuatHsc60pgJPocfuVryv?= =?us-ascii?Q?Oavh5/25Lru2pKC8dumP4necU6OUH9E=3D?= X-Exchange-RoutingPolicyChecked: tLU+vcdoC2UwaurktwJti4xWLmJqH+1lYmZ20NF8d13hWD64gtR0+JTcY/4GQoBVbrwA5nhMvSNqfAfzxL67Dg4Sp4mIr3dgvYHVvWeY4SzfbFiCBsbL3aMDaKMfbxPIp5y1AG0+M/SofbI19wIAKfHSDhDfLN0YFSx1RqULFmaCdU4pQkmWVDkoIRASXGxolOa8aVEGD7t91YyzZE+axjesPSA/QRrWsUSuJ7Y57uGVIMecojT+4yASGSGjmv6FDesuZAizFDG8DhofCq3NDB9tBZtCbNIGeLr659i3b4SMFXcOCdgt+DnUWiN3S+lstOmYUKKVVAuowQ+QXzM6gw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b928cdc9-c82a-4b3b-cb26-08df13df837f X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:44:41.7065 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tZI/IjMG42zOcz+IcxJU8s/D5Qkfx9ZQutCyLilBvdMm7of6moT5t/xxVz/KnhjKdWbR+vJ2k0Cu6w+QL4SxKKkRguyLp+ljRjUn/weieRE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7380 X-Proofpoint-GUID: u7lcTM77ncOdzjWAb2vWC9dhAk_goSs6 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXy0BXZ3ibuEtP Ai0e2uYsGgUOy3BZHRotvBrYPXqUUtrE27e3Q55/2kT7RHX5Sj6zY/vp33xiKikGCL1yJgT7C04 /oHC4joucQhgpyBvRjPTYWR202ynoME= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXw5C/Lkpm3pHb 8Xrk419VfF/FFnYM03Ha4Zee0RLoLdk3BxURbQ/lCo/du0Ig0aLVGj0NPk3qW3+X4ATC4wEvnSs Oa9n+lS1FxSsKb7SpfYpEb//gHnAivt7aSUwa5rh0DWN+dmaibKH4v/r3xjPa5+Z9nvP+Ar/k1z TUji7GdYKjpSuN5GrEm/YRomDwzPSS8ZfYUQMGORfFVTkgqkGXSoP1dSWGR100nBVWLJyqroo+a HUdftljsy6t4Lo/EyMtmdDa9cqkc2Kyj6aa8TqzdLMAVYDwhCQ/cxxdXmHr97TLq9TOH8SbXqIW KKKKcFMx8/TbCPsrmCsdRCDL4Ez6776oi7eXetX+Wj5chaohDrcDHOPAFhgbP5nyukflNr0S3nb G8CgzTHOZhtP0aiFdfdA28EgaDz4iPvoWrdEBuZTvAUzfph+ovKydiqjd0LAAH6UomMibmwH/Cv CSANQ5cdqOVid9Vf4pA== X-Proofpoint-ORIG-GUID: u7lcTM77ncOdzjWAb2vWC9dhAk_goSs6 X-Authority-Analysis: v=2.4 cv=Ps4G/AM3 c=1 sm=1 tr=0 ts=6aaa731c cx=c_pps a=iw/g3Nm1s12GBgadF/0+Gw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=XF9Y1ugsmyLceZbb4BIA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1789555495-1FE68757-AAEBCA89/0/0 X-purgate-type: clean X-purgate-size: 6588 This is to emphasise that child types of PIC_COMMON are all instances of an an 8259 PIC. Signed-off-by: Mark Cave-Ayland --- include/hw/isa/i8259_internal.h | 4 ++-- hw/i386/kvm/i8259.c | 8 ++++---- hw/intc/i8259.c | 10 +++++----- hw/intc/i8259_common.c | 14 +++++++------- 4 files changed, 18 insertions(+), 18 deletions(-) diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index f9dcc4163e..54dc9036cf 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -31,8 +31,8 @@ #include "qom/object.h" -#define TYPE_PIC_COMMON "pic-common" -OBJECT_DECLARE_TYPE(PICCommonState, PICCommonClass, PIC_COMMON) +#define TYPE_I8259_COMMON "pic-common" +OBJECT_DECLARE_TYPE(PICCommonState, PICCommonClass, I8259_COMMON) struct PICCommonClass { DeviceClass parent_class; diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 66f37e1303..14029783e5 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -103,7 +103,7 @@ static void kvm_pic_put(PICCommonState *s) static void kvm_pic_reset(DeviceState *dev) { - PICCommonState *s = PIC_COMMON(dev); + PICCommonState *s = I8259_COMMON(dev); s->elcr = 0; pic_reset_common(s); @@ -122,7 +122,7 @@ static void kvm_pic_set_irq(void *opaque, int irq, int level) static void kvm_pic_realize(DeviceState *dev, Error **errp) { - PICCommonState *s = PIC_COMMON(dev); + PICCommonState *s = I8259_COMMON(dev); KVMPICClass *kpc = KVM_PIC_GET_CLASS(dev); memory_region_init_io(&s->base_io, OBJECT(dev), NULL, NULL, "kvm-pic", 2); @@ -142,7 +142,7 @@ qemu_irq *kvm_i8259_init(ISABus *bus) static void kvm_i8259_class_init(ObjectClass *klass, const void *data) { KVMPICClass *kpc = KVM_PIC_CLASS(klass); - PICCommonClass *k = PIC_COMMON_CLASS(klass); + PICCommonClass *k = I8259_COMMON_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_legacy_reset(dc, kvm_pic_reset); @@ -153,7 +153,7 @@ static void kvm_i8259_class_init(ObjectClass *klass, const void *data) static const TypeInfo kvm_i8259_info = { .name = TYPE_KVM_I8259, - .parent = TYPE_PIC_COMMON, + .parent = TYPE_I8259_COMMON, .instance_size = sizeof(PICCommonState), .class_init = kvm_i8259_class_init, .class_size = sizeof(KVMPICClass), diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 8f2aa1f0fb..52e24d333e 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -218,7 +218,7 @@ static void pic_init_reset(PICCommonState *s) static void pic_reset(DeviceState *dev) { - PICCommonState *s = PIC_COMMON(dev); + PICCommonState *s = I8259_COMMON(dev); s->elcr = 0; s->ltim = 0; @@ -387,7 +387,7 @@ static const MemoryRegionOps pic_elcr_ioport_ops = { static void pic_realize(DeviceState *dev, Error **errp) { - PICCommonState *s = PIC_COMMON(dev); + PICCommonState *s = I8259_COMMON(dev); PICClass *pc = PIC_GET_CLASS(dev); memory_region_init_io(&s->base_io, OBJECT(s), &pic_base_ioport_ops, s, @@ -418,7 +418,7 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) irq_set[i] = qdev_get_gpio_in(dev, i); } - isa_pic = PIC_COMMON(dev); + isa_pic = I8259_COMMON(dev); isadev = i8259_init_chip(TYPE_I8259, bus, false); dev = DEVICE(isadev); @@ -428,7 +428,7 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) irq_set[i + 8] = qdev_get_gpio_in(dev, i); } - slave_pic = PIC_COMMON(dev); + slave_pic = I8259_COMMON(dev); return irq_set; } @@ -445,7 +445,7 @@ static void i8259_class_init(ObjectClass *klass, const void *data) static const TypeInfo i8259_info = { .name = TYPE_I8259, .instance_size = sizeof(PICCommonState), - .parent = TYPE_PIC_COMMON, + .parent = TYPE_I8259_COMMON, .class_init = i8259_class_init, .class_size = sizeof(PICClass), }; diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index 8ceb5841b9..e2f997e161 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -56,7 +56,7 @@ void pic_reset_common(PICCommonState *s) static int pic_dispatch_pre_save(void *opaque) { PICCommonState *s = opaque; - PICCommonClass *info = PIC_COMMON_GET_CLASS(s); + PICCommonClass *info = I8259_COMMON_GET_CLASS(s); if (info->pre_save) { info->pre_save(s); @@ -68,7 +68,7 @@ static int pic_dispatch_pre_save(void *opaque) static int pic_dispatch_post_load(void *opaque, int version_id) { PICCommonState *s = opaque; - PICCommonClass *info = PIC_COMMON_GET_CLASS(s); + PICCommonClass *info = I8259_COMMON_GET_CLASS(s); if (info->post_load) { info->post_load(s); @@ -78,7 +78,7 @@ static int pic_dispatch_post_load(void *opaque, int version_id) static void pic_common_realize(DeviceState *dev, Error **errp) { - PICCommonState *s = PIC_COMMON(dev); + PICCommonState *s = I8259_COMMON(dev); ISADevice *isa = ISA_DEVICE(dev); isa_register_ioport(isa, &s->base_io, s->iobase); @@ -118,7 +118,7 @@ void pic_stat_update_irq(int irq, int level) static bool pic_get_statistics(InterruptStatsProvider *obj, uint64_t **irq_counts, unsigned int *nb_irqs) { - PICCommonState *s = PIC_COMMON(obj); + PICCommonState *s = I8259_COMMON(obj); if (s->master) { *irq_counts = irq_count; @@ -133,7 +133,7 @@ static bool pic_get_statistics(InterruptStatsProvider *obj, static void pic_print_info(InterruptStatsProvider *obj, GString *buf) { - PICCommonState *s = PIC_COMMON(obj); + PICCommonState *s = I8259_COMMON(obj); pic_dispatch_pre_save(s); g_string_append_printf(buf, "pic%d: irr=%02x imr=%02x isr=%02x hprio=%d " @@ -146,7 +146,7 @@ static void pic_print_info(InterruptStatsProvider *obj, GString *buf) static bool ltim_state_needed(void *opaque) { - PICCommonState *s = PIC_COMMON(opaque); + PICCommonState *s = I8259_COMMON(opaque); return !!s->ltim; } @@ -220,7 +220,7 @@ static void pic_common_class_init(ObjectClass *klass, const void *data) } static const TypeInfo pic_common_type = { - .name = TYPE_PIC_COMMON, + .name = TYPE_I8259_COMMON, .parent = TYPE_ISA_DEVICE, .instance_size = sizeof(PICCommonState), .class_size = sizeof(PICCommonClass), -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422576.1647910 (Exim 4.92) (envelope-from ) id 1x6n8I-0002H8-Jc; Wed, 16 Sep 2026 10:44:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422576.1647910; Wed, 16 Sep 2026 10:44:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8I-0002H1-Gn; Wed, 16 Sep 2026 10:44:54 +0000 Received: by outflank-mailman (input) for mailman id 1422576; Wed, 16 Sep 2026 10:44:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8H-0002Gv-2K for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:44:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8G-009uB7-AK for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:44:52 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7305-bab6-0a2a0a5309dd-0a2a450adcc6-34 for ; Wed, 16 Sep 2026 12:44:51 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7322-f2d2-0a2a450a0019-94a39744f12c-3 for ; Wed, 16 Sep 2026 12:44:51 +0200 Received: from pps.filterd (m0127837.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8K2Ti700459; Wed, 16 Sep 2026 03:44:40 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020116.outbound.protection.outlook.com [52.101.46.116]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0ka9vd-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:44:39 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MW4PR02MB7380.namprd02.prod.outlook.com (2603:10b6:303:74::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 10:44:38 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:44:38 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=proofpoint20171006; bh=hLA8q5A8Lzbad uFj9D065CiadtRTYoD6VhJ5ec0zV+Q=; b=VeyiWCR9qV1iPVk03B3H/NZbOtlLG Gf+wada7cDUgq1otRlFlb/tkrFWfethPq0f//suPuKp+aKpOsPapaDFqAg/EmE+i cBX26XYXtGcyoi7M80cwrQ1kxgrBMV0rbcfvsN4PehfcrwEXwrGgcnkFSW1NsWjB 93p8vToIkUQHBr5XSX4/GeW1m6ddQvmOGRREoIXtWlrN1m87VHZVhh85ETVO5DfV AFXw/KVvo8RG9kr1GiPHQT7GqP9+/Yw4wNNpAYF+OU66L7Q5a3slr2NAD2kEMSu8 DYthq6/5DBniSlq3nhluF+PD+NyGNARlsJrnmIVR7/tMnZGRkRhfE7zdQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yJ/J9jdNcGtBRFWO7H1IhFI1788p0e2neYO8VylFKcD0BWVXEYC64YLDAM9MnbwBuGH1DU6xIu109rQvba//MepnKdO/UjGFv+FIlh6r9l6qVTQlDKvYnj11+OvhLvto9nyArNxsZnm/nVVCVOb30JuZbt51vGjIdxgeJAVBhJKwz/v+XHwEq6kE5dIFusQnCc3JJ4w+hCVIZ1istI7E78RzQfzdlf5vlEwukZDPZ0hAo+PPGFjqOnqCEJPYr2QklvnioRh+1t9Yx8xVh2s91egPpxbrxTlJ8qFH5BZjrdbLk8XnhrsMonfmT4pz8ACEr6dpv1AFnmopKWxrhjDCtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hLA8q5A8LzbaduFj9D065CiadtRTYoD6VhJ5ec0zV+Q=; b=qiHsNw0cGyK5t+WLu3/ROwQksnqrfZnSwM0eu15NnNBFa7iK3PP4tQCVPUyXdxNCP7LYp0Icl3W1QJte0yXK7rl0PcVwyi+15hgBCUsdBHV/O2qQhget57JUn/KGFUF9KfcfW/JkdDf1+3mRJPT7FRgueYBbXPBHGx161qLOLjJl4zmsJ/5ffeAEDsg2fWI9RW++cNt8740VgTqCxVJ0/kmim6YwEChvsq/51SIhSaZ0sWxL1b2OxvjUTN7McRsTrypS3OCEEoa7h9+PSQLAYNciPb0RoKBoi3AK22TIKTsCDk56jVuoZi/GsaKhmKFV24dXYj04wR9NW91y8l5J7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hLA8q5A8LzbaduFj9D065CiadtRTYoD6VhJ5ec0zV+Q=; b=gAEny682MRqlB4cTP6y2SfQn/Y+VdHrBGhvMbtzaAFB6rqlELxbNr2zA7GejvzrE6aLh0FMrmJUs66S+4KTk86Lm81mQE/K5djUTjW65sHHJuvRymBhKDxLQKzRAp70MqEn+YpvolieZUcq8V/Z0qbQP6OfohRoJjeLPgnDG4+DpR985bWIa6j5aLULMcQHpx6oW6FFxLpPt6R2TyfGH6wngVHQYsU9NHplDlpjXjou85iN5lifsqBv4GxKUeLn6L3kUYGNeQ5++fTJu9XLE9kOHzE9Yb1A4qWWcGmWNJyssVFcRm2Cgqpn264fu8yyMpStRGeNXtuY7z5IszReGpw== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 00/22] i8259: improve qdev PIC modelling (and misc fixes) Date: Wed, 16 Sep 2026 11:43:28 +0100 Message-ID: <20260916104435.600211-1-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ2P220CA0009.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5da::8) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MW4PR02MB7380:EE_ X-MS-Office365-Filtering-Correlation-Id: a39ed88e-7905-4b64-6596-08df13df81a0 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|10067099003|3023799007|6133799003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: xEMUlUKS09Fi8oSGUgelTVFdxo/EBgnxR/z/TOsq9M73QEcA4ZpC6f8NLLasrHuLgSeeyJSGfRylhvnZxl4NVKYUz7fCqukoFpn7AivBjFhJZ/iv2yz8qn1v3WJr8U4GOpQoDNqris70XZONuj55lH4tyDQ06rI0Y27ySUDdNBTT0oQHtXPlw1Paqst1ARviqzRSId36+CmJJ8WWepf0oWNDax22riyGI7v3HFZsOS7fLqDz3KWF2k6cVsIKIOIaifObksZX8o861Ci6ODdwPSgZHZmOrKpSB3iscBrFM5DFLCCN5Sw7gEOaYPXAKPFPp7lwbzhBOUE2f6PLCcm9HQx6K4PjQijvSBjBNQeRtQJrU+omZTLZ+SyGDdDfKS786Eq8P7Cm93F9FJ7UNBXG7+uPWWvfgWOm6lCwESFhR0ifkwQZOJ/89or7F6N2G0WqFWCBziBV00fRb88+KbSEI+w0lZD8QLgzUF+jwQ4qsPcuQ5LO3B9tw5HBLtVDowreS6pOdEKvryzb0iK3ENz6LaPeFmqaWX3m2r36Qb8K9OfCNE2SXSpv9KAXBtBHaK4RypE9u+eLrYHBr9R8PvnYjCIPi2WrnLMYoS/uua49fV291h+XgmIbjp3PRbPOtu4pIWrYbD63Vp6JvuJqH515Q5sHhDmwiYqZgLAHHTCZXfc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(10067099003)(3023799007)(6133799003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xxn6jA6Ficqii3+2Gh4dDVPr/Ri1eEfTGbMYD068absw0vWY+moBcdtUYyi/?= =?us-ascii?Q?IKkXlelfCHsqkej5pwCONU+io2/dHagZQ/ntfY430vISNIPHn2zrxfQ/CeOB?= =?us-ascii?Q?k6gdKylsPk9SfYSZ7Dr3MDwmo4bSXQQB6kIZvgLeGnF5z215uNj+ZLKN83Hu?= =?us-ascii?Q?X2MBZxSvyFVUdE1Ng7NXoYA2RU7SW0Starmha39ucP/93vXNlxPp4QErUG5l?= =?us-ascii?Q?nH8oUGUKEs/litMrdqrOYdzy0oKQVaus8cY/ULALeNsTeo6dUMS0vN74sVls?= =?us-ascii?Q?SU7DHOR8J2ylwxj+C2P8UBHJXJWJvj/I8EolB+OqQ23Nhlh7BZyZ7LJ4uu/a?= =?us-ascii?Q?baafEMxXxKEqOIFkDlGCjkfxvO18Z/pld+404xy+7fFLPJeyc2rUGDXGmf+h?= =?us-ascii?Q?HgcyYsZYF3RlY26hR3jTmhgrx7MOR/0EUBJl0z2fnDXdnezIelTx2zieDc4p?= =?us-ascii?Q?geRv3qevLsfvodREvQVOd45ni2jlv3y8ih92novyfmgqZp5rTNefKXN2GLPK?= =?us-ascii?Q?3Jny56AMhsLsdDKx8Z+EDIclZ854zYckCpaHdun/SR91pJPU94Ns1FsVKHiL?= =?us-ascii?Q?3q3bw233SJnUBiLCL+GRut1ahlsIxWnyc7F2qSrcx/xmAoUxbDg30W+aaX9r?= =?us-ascii?Q?JLpK00mRabS3KDypFRhtIili7AUMWqrDY2ziNea16ekKhT6g4y0PmJhTQ3mW?= =?us-ascii?Q?VBOjQDjhZKUIxtI8Q/x56jow25SkaQwRCavoDvsxjKk4Zr4Sg1R8JzGyWAvi?= =?us-ascii?Q?+jCeEoQCrmgayHfjDs0HpdmCu1p0sYsxSenJ9QtQglF5N9nSbe/Ujsx7eXYC?= =?us-ascii?Q?EcZpqfBf+9pkJ8dtayES9nakJxc2AiLemm8rEwzZzTfMzkl/utjWqN93Z3rH?= =?us-ascii?Q?gFZZpXtvf9CdGmqfBnTf1j0smQsZX3zS/KI6FgaewSVZHwyoULPT+axk0dNI?= =?us-ascii?Q?MUxEV5w5fJtaaiwpNGcl5jbK0HbQSqVQsTcHi5cbnEDq+w2Ru3QA7mDxbaDy?= =?us-ascii?Q?sdi6ij62dudvCXizSRhNXX/DDKZfYKIebSAb48faRcEo7tTNttrvS9zNqcfo?= =?us-ascii?Q?GXDSOvg1yGCCSmtZ/+DBahjvRV3SERqNEuUHdTyZ5Tn9OJ1bu7fi/DBR+chF?= =?us-ascii?Q?A6NS4Yec6NaO9lAt3nWutHgUTxPo3OWYHzzh7spfox9x1j+z7Ae+JX5O61Zz?= =?us-ascii?Q?4reEJ3lNd73AOGXG9YtPMniHmdAMoVRcpj9Ibpu4LdZdWXUmBAy0nWZz79Oy?= =?us-ascii?Q?l6t2LQYQltRZs6j/YRXhyYi0YBydgSudZJAq8z5BcUS9Zja6Zfs8IbAYeuFs?= =?us-ascii?Q?dry9t+2iGtBJA0UrFloknIUEz8wVt6h+uB6m3EkGrIvj3NlVkwUC04VYZu+z?= =?us-ascii?Q?nWm+T4/AlEr70yKAIZliaBwKY+izfYMOhfaVF6+CoJ3KtB7sXw8gcGCdDMSg?= =?us-ascii?Q?D2vlSn4BcNcdD6oMNyzqQVmbB96j4vCzaTYiH65MLDxNFIL0Wyf+Dj8TaZp3?= =?us-ascii?Q?4GF+VbTkhCnbISvsFpZ0wBPWbaREPcRqpXLIPMLYdUrNjejpiPBm2ryDZIy6?= =?us-ascii?Q?LwTG2tMO1siG9jMCa9mZ9BMBlC3rb9cFsELCI8enJB9JFF+5PgooWp7e8ZYO?= =?us-ascii?Q?7qQ1i9iJvQYw+gw4DOU7KCYJxFvfzMg1Dql80X316EnjmMpEk7lSmJmyaCd3?= =?us-ascii?Q?cWP/PahIIo0psUQ+mJoPiwU0cIJWpHxA+koulP44GpGe0qHiUxuHpxNYPyQ6?= =?us-ascii?Q?Ed9w4SoWYyTLYdVhiIi5OPTzmbXb8/s=3D?= X-Exchange-RoutingPolicyChecked: JGYZitA6ZpN1yi+QqSMuGpKesUWLni9uFZTF/7ytQ2tQ+3nvd/vsXBLlIskIb5N1ls3m2LEJdJwzgZPljUyp96h9sT0AC34d32W8lkZ72aFNW0SMoO0iPU9s3WmVY1iqPFTR0FpQFYJTLibmvq6ePuJv+9+wA3zqJLuESJTWxB4ho/fK94cvQ6w09sw/zV4ppWntmHaaMS8K5jMfu5yna7rtYcvYxMa4BYUgPJDJ51b/ycAAk44VzUc6e35BYD7gnaV2ISUPe3mJLbIooZPNUP7XdZt/6UEJz9c9lxNDezigIJkLvp6OMihKMm8YBaczOBUdbEJTagk0TiXb/2O34g== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a39ed88e-7905-4b64-6596-08df13df81a0 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:44:38.4124 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: w9DcCIDn4npznu9mXabTvPGNxL1Gpgf4RUmTV4zK3rxGqQtKDkqDVm/zPLLFsBFO5ud7jMfNnagaya6cxZ20fg4C1qyLvV1Tww6bT7r2fR0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7380 X-Proofpoint-GUID: 1lDE_YNnNDioHLOJ3YhAgBbWtaMmOzf8 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX9p82a9rleULP gowk172ty9k3Ph9wvDSxbyj3nL3hZqKvYKBZsrMzMYvauNqyhf/WKcRzHTPFeqTyOO6edHKv/ai C5JkxN1otK1umUCUj0rNNnIjRdQ22gw= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX+tzN5JuddDFY qgHcH+VKURNlC/h29Kdtn7gssh0iCzR7R9CzFIAeUQP3ymKS0D1ZTNfoMqNoWGp1D/Keu4JG1dU YzRHA03msSJXEAhSvPjXtP9md/yJVSw7rFsg5ypp9J0/EumZS9zIHgsVRIQ5JZ+W9upCTdhpjQl QPC3LjDT2jTikmgb4kBm2TY30fkUgmXS2wmGPl2BuofI1IwyGXcVDq/zwlu62lsLDvWogRFThUm etzp+ZIJkucglmbkoG9gqSIoCm5FjW+mYaQ9Hc5JxWzLlb7WvXQJH7Ytsq0s5rMOwnUS8sWI8O4 xjTdb+GnT/lozRgFMvnO+kpS1ieDW9EmHr1gm1kGINF0HPCO8EU5FML9mBcc152kGbttUS0XkvP tvaszvC5tw4TAzW2HFcObjwt5NTMqD7BpnGj/oWoyMaLk+Sa6VGli0fxPSiDcMo73MukvtsOFSm OHdBczd7q7vta7DjBRQ== X-Authority-Analysis: v=2.4 cv=P46vFSAu c=1 sm=1 tr=0 ts=6aaa7317 cx=c_pps a=ouQKzlSDvkUBIcrmkWtKoA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=B-xQ1axTSFxXRe3sjz8A:9 X-Proofpoint-ORIG-GUID: 1lDE_YNnNDioHLOJ3YhAgBbWtaMmOzf8 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-4011c0/1789555491-51EC2CFC-AD4BBFF1/0/0 X-purgate-type: clean X-purgate-size: 2902 This series attempts to improve the modelling of legacy x86 PICs within QEMU. The initial aim was to have a qdev device with one output gpio, and 16 input gpios representing the legacy IRQ lines, however as I went about trying to model this, I found a number of other inconsistencies/bugs: in particular there seemed to be some fuzziness around the functionality that belongs to an individual i8259 chip, and a cascaded i8259 configuration. For the purposes of this patch an i8259 device is considered to be a single i8259 chip whilst a PIC device is considered to be either a cascaded i8259 configuration (emulated/KVM) or standalone device (Xen) representing the set of 16 legacy IRQs and a single output IRQ. Due to the updated device names, there is currently one visible change in the HMP monitor output for "info irq" where the isa-i8259 device now appears as isa-i8259-pic and the kvm-i8259 device appears as kvm-i8259-pic (see patch 19). Signed-off-by: Mark Cave-Ayland Mark Cave-Ayland (22): i8259_internal.h: rename PIC_COMMON to I8259_COMMON i8259_internal.h: rename TYPE_I8259_COMMON to i8259-common i8259_internal.h: rename PICCommonState to I8259CommonState i8259_internal.h: rename PICCommonClass to I8259CommonClass i8259.c: move parent_realize from PICClass to I8259CommonClass kvm/i8259.c: move parent_realize from KVMPICClass to I8259CommonClass i8259_common.c: use i8259/i8259_common prefix for functions i8259.c: use i8259 prefix for functions kvm/i8259.c: use kvm_i8259 prefix for functions i8259_common.c: convert to use DEFINE_TYPES() macro i8259.c: convert to use DEFINE_TYPES() macro kvm/i8259.c: convert to use DEFINE_TYPES() macro i8259.c: introduce TYPE_I8259_PIC device i8259.c: properly cascade secondary i8259 from primary i8259 kvm/i8259.c: introduce TYPE_KVM_I8259_PIC device xen-hvm.c: rename xen_interrupt_controller_init() to xen_i8259_init() xen/xen-hvm.c: introduce TYPE_XEN_I8259_PIC device i8259_common.c: remove unused i8259_init_chip() function i8259: move InterruptStatsProviderClass get_statistics() from i8259 to PIC i8259.c: switch isa_pic from I8259CommonState to I8259PICState i8259_common.c: remove static irq_count and irq_level variables i8259_common.c: add missing 0x prefixes to "info pic" output include/hw/intc/i8259.h | 12 +- include/hw/isa/i8259_internal.h | 21 ++- include/hw/xen/xen.h | 2 +- hw/i386/kvm/i8259.c | 167 +++++++++++++---- hw/i386/pc.c | 2 +- hw/i386/xen/xen-hvm.c | 40 +++- hw/intc/i8259.c | 322 +++++++++++++++++++++----------- hw/intc/i8259_common.c | 171 ++++++++--------- stubs/xen-hw-stub.c | 2 +- 9 files changed, 477 insertions(+), 262 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422578.1647929 (Exim 4.92) (envelope-from ) id 1x6n8O-0002hC-5u; Wed, 16 Sep 2026 10:45:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422578.1647929; Wed, 16 Sep 2026 10:45:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8O-0002h2-2K; Wed, 16 Sep 2026 10:45:00 +0000 Received: by outflank-mailman (input) for mailman id 1422578; Wed, 16 Sep 2026 10:44:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8M-0002c9-K0 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:44:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8M-009u9P-0R for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:44:58 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7316-2eae-0a2a0a5409dd-0a2a4504cc16-20 for ; Wed, 16 Sep 2026 12:44:57 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7328-b57f-0a2a45040019-94a39b0c723a-3 for ; Wed, 16 Sep 2026 12:44:57 +0200 Received: from pps.filterd (m0127844.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G89JCJ579568; Wed, 16 Sep 2026 03:44:46 -0700 Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11020135.outbound.protection.outlook.com [52.101.46.135]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqbtb9y9h-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:44:46 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MW4PR02MB7380.namprd02.prod.outlook.com (2603:10b6:303:74::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 10:44:45 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:44:45 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=47KAukU17fw16ZQnEsguQxctcBzaDB9q4df+PeVtS uI=; b=xAB73kb2TKiB4lf3zzZPXVzl3G4Xpciqrha9Qs3G5HomT8wjXxh6IXVaB XvsZj3qjW+yN6dWgBHMVnkCfOhGmGqNO7ROa3sYP5ADjQDXZqz77ThT77mX0qQp9 tKMHyNqh0qsqoGezXo5AeNTk23n5h9YDdaBVJMm1mqTkR9oyW+iG0Ht2hW7GqvOd NPEmxVckzTP+MP4PCAf7ucrTUGNr/JjoyV6EABjm/xJ6uYM9uAMGuOhSYgMdhuA3 CNYbQNt8nkJcE+rhqzHV6eshGdpmuurJCA29YV7cdfrGPkd4j1L40d0rFlW2j/LA jsSJqEMWrENv8PMBE2+k5eAYz8d5g== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DHMstPH0mNxvah2vThSXjVCT3By8Jk8irxXa7RUA6KIyUN9+BvjQRjHOsq6KsK43WVZlOEjSE5hcMDdGebfb7UrxtoNWzjNcJ1DZR0gGXfykXQc8CeXM9Vh53eLjb5zrVRniBY8gLRYIyoOLr21KXF/KwOtrlgbrC8Q/63T59UXWTuCfCiC+XftQFgEmMsEcIMQ2WqPbX0EjoLsi734mPOcxVLQRLnWv+uX1FGbBE8G+nd9Xo5TeZDELhnWExNnO8pEzRg3pcfcqpBB4VWMorIOk8KwHfNAXNiM2XWjCuWO6HpoRzNvmDBhRnCYuqvSaSEWVQwjtzvAJeUj1hXcD7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=47KAukU17fw16ZQnEsguQxctcBzaDB9q4df+PeVtSuI=; b=VrQE7dhvYMh2XtotwSdcrj/tYTgt6NeYXySxPwdl6LDq2q7TJDVkQOfeRhbhcfF4shvh13FLuZ3IgwOdS+FXawKntzTxVpElBz7l2N5Fxama02uWou67rUHprCRM1/z79dRELhXazLRSyAmSL2erkyFm9O0nk7Zcig16si9diQm4dYpo71/UtRtFUr43lGxiz+Kg5nxerlmnZv5jR+DgzBfd6Z28EL8aPXc/JBJ4vyOJGJVTvLgqhIQa5+6Z5NKQ8DXRYexz178mi7bCawhcfO4ln30oMl8YiAks7ZD7Nc/Z9mxfPc0OdhXX7PdpYfYc2ENxbBHDIZ4qCNUsGvDIMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=47KAukU17fw16ZQnEsguQxctcBzaDB9q4df+PeVtSuI=; b=uTKuzKXlcFMjiKljBBivyj+/aUQcK49sWdOW5baDrlyw9ASGnLmAbut00+80881SdKpc73Q4pFviUCx0cH1IX6Xh191iQ2V5zCHaPktkTWh6SffIbg5BAfeJbx7dEsN6BqflGhtgxLJiWB4hY/RVfAQ0LSPsan/5z5mDtiElFLa3rRAJlXctIU8ReriiDaus2yAVaQyZBDQJRMbQFxPJaZlVPvYd5Bm74EYVDdVJ1yZ4zUruMj1+LevmShV8NsPBeb3m60yPrzzBG9hOcyVWFY2h+V9Zpk0hb2L2oATqePOKYgSmRRb6Lm52RRH/y13P9Y3tYxVve/bxsL+bum7/0w== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 02/22] i8259_internal.h: rename TYPE_I8259_COMMON to i8259-common Date: Wed, 16 Sep 2026 11:43:30 +0100 Message-ID: <20260916104435.600211-3-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0245.namprd03.prod.outlook.com (2603:10b6:a03:3a0::10) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MW4PR02MB7380:EE_ X-MS-Office365-Filtering-Correlation-Id: 39542bc0-e8d3-4c67-7a01-08df13df85a9 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|22082099003|10067099003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: 6vhYz4JyaWMhD5U3FnyuVC0rB/40xgbpBlxHyy7gGyMGhtlknLUYuOaWFqraZl+nmCOf4NBGZbUcPi+TOM0WzbG2Uw6YIjDRFQSPu5IAWg/dgpGN+eCOjiUvCIHu4iKe72OLEqrHpsXhkppZG+Y9nvFol19qe1KDJYPfO3wTVf/LCbEa1OCu2DZzs8W0DgakNq8tgOwD26Whco+moiyDSHs/lDsGqmL1UQ9TTQ6OIbAM4d2fJKVSG/E+UFKoQbXIBUf/c0LCsfJuq033qFXVgXMqhhwpAWTLgfWUB/tdz7h9jFbACqTKI2AUJp9qJ0JTJ8U7V2bvAWmHr9TGe53OeDy2zTgJ5Ejrw1Q+b6kmf7E+zD9sCcBQVPzA465bBkABKdDhoOq96pX0iGwew6H6KTJJXimSMk2y1o3mPK+RaMxgA2IV9j7IpOHtYFOYzZBnr95Nwcqn+TabWWtUTt65HL7sDMmhmYVvjMRH42FKxqquBa1smgMcJOGk/a/VgoeV7ZAOD8wKxnWwoBkrH2IgaDqhmSKpl98sL0zKue19FZLrt4I31uC7oHKtyzZ3TOoMtrhcV/Fnz/FGfVZPDys45JkmSWQlDgRDgiTRZ+ol0RD211oLXR+X/7eZJLnIc9kvX3MReMs2dSwyIp6rp5q6aBRLr8xLSMNSNerP+UPlGHE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(22082099003)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7Qgcxb7gSoWiqUff4CSTkHBUYrJBWlwcSgOJW/O3uhVvoMPYoVfqjVvCN+cd?= =?us-ascii?Q?ALLNUtWchhpthrjE5STWNTOnn/8iLGIgJLjVzBECYBnApNAyrV3e4BhiMfQt?= =?us-ascii?Q?blQF3B5ZPdZb9D8nsE8mHKYC1pT+aSUjDahPXMbfbcJSsZUJlk+QZ4sieJbS?= =?us-ascii?Q?qTosNPoPx0MDxB7JV9ta4m2xWS76ciNkMqUoog9fEWBfmH9lxRd6i5TtE28k?= =?us-ascii?Q?bdczvRfCnzm020T4Clwh4jHdS46EWBWr+ZDfbeCFG925wg2vRi3YP80ynXDQ?= =?us-ascii?Q?sIWGDarbPJI8ypGNS141W4OSpp87/eeIfCN8cGbxhvUs4dxuQ5eC5DMlKf9y?= =?us-ascii?Q?6sV0PzgFvpH4eXMPrXet5WRYaz6SP1z/fKVU6BJIJeXzUvoyzH7Ti289uOph?= =?us-ascii?Q?C/zq24G3/GMpCQ29Vb3sQ7/BHLoG4ELGoDgyePX/SDUDHMiT9mQAXn9uF/WG?= =?us-ascii?Q?rP0c1yomXX5msjv95Vx8ECKVpC/rForgObLE215StuRYRg5cBGAYa3MRWVHf?= =?us-ascii?Q?/vx6a1xnrNnW2/x90WrKx89bYvsgcXI+LWPsCWMSNabEwEplF2Z5G8ArIZpB?= =?us-ascii?Q?2Y4Oi5v1d8zReqvVkqwi7UWO5iZ56kATiCoDBHcjfIL+y3bthpLGacQSUKZg?= =?us-ascii?Q?EjSQ00mli6DwL5yBm2YezwtSU4EZJs6RnUEIr/pLuzYwCGE8da1rEjp/X9xq?= =?us-ascii?Q?vDeyEcA90KT/rdzTC2HHZdxdcm5XIk1LeNkubYL6miHlUvf8ROFB++1cHVJE?= =?us-ascii?Q?+4RugPFfZ5rB/E4iHx/y76G8dPw9y3wGbLV+ZyfiyK4SvcQvZkfPsC0UPOrn?= =?us-ascii?Q?AgsA6AQoeTbenzETUeH2Vol5YlOmU68tzhUo/Dm5LwWhwUsDtNH4/q5foeYj?= =?us-ascii?Q?QonYHkjDBhRLDvz9z0d2Z6UjB7yqm/qzI5P6pS19YpOL95iFuFxmS2YPQT+8?= =?us-ascii?Q?x4OHNONRtLcvJ8XUIYN60dEqko3Togvm+cev1xFTbKo2oEdHulizkodDXDKV?= =?us-ascii?Q?e784sy8WmtT0Oorra8eAWb1QCmwolzYyiSkBGk3ImAOxgyMImFL4DRFY/Fsn?= =?us-ascii?Q?tFBi0DtpvZy7xPrPJfd/pFLjvUeoA0hnVq/fqYm0LCQtZ4bCW2OWGD+V1rrn?= =?us-ascii?Q?M+xSOE4j/cVa7cuirVXZlxgiYscvQWSvCingJC5w4OcKtrgVVxpb8PoLwF7y?= =?us-ascii?Q?P2JCg2MhXRswTyB1j/xW15DzwpRybvt3eE49ycxR/Poh8DZgHyOjqdz/BhAV?= =?us-ascii?Q?jeFX0i2CzCp/4KNADtCQYYUlviito/JzJkjLNx5fDAJ9We0eUZJhwDPjUVsd?= =?us-ascii?Q?NnIbhas/aK/nbtoFPACym23rLCHdlBeBfvbD4/5P7Z8EXa/yFeXuGq/q4rtm?= =?us-ascii?Q?a9HBddKqUmBJxc+X210EsgrKfHyfhCLkbL9KOTYWYWtvCbU+R73lCn20H5xD?= =?us-ascii?Q?HauJxxIVIeiH1iMUaQm92OFXq+Y01rPn7Ehm5lPxI7Zrw3yd0sRi1n+Y2GPq?= =?us-ascii?Q?jQUUrCxTCsRVeqyn4jlkLH/DMpTTjt/3WzL1VDrNKLmkRS9QJPmQGmYJ5PL7?= =?us-ascii?Q?CKSIb0ocWs9TtvixpJKstEz5I+46vUcv9Tg7Ho7Tfw3DpgOlC4oew3ThNLiP?= =?us-ascii?Q?b464PbB/tXrqaIhawF2jYFqbEpE/x2DNt281HVhKIZ/oDPv2WgBqn1SGt9Y4?= =?us-ascii?Q?Dm36DUFTv+2u+W8P+lBn36fSIX4OhWU4YyXqro+wvseoxgqkCI6sHsEk8nEm?= =?us-ascii?Q?jIZI/GYShndmjiUW9h3z5tQLrR3G4SM=3D?= X-Exchange-RoutingPolicyChecked: RqYqtDzWPAE9uZKty4+QO9eq/OFm8IQxbvTCY9F735n1ZyQIKRNEHe1bHveU1nin+yzE8PxeGhyoi/E2gFMcf91Nu7ulZRhJEjzgP9Zbxw7RfTEDPyJeHGbJTl59jsHKwNic03MPtdtb99MNQQ9VQsOE7pgzOPQP6E3awLGOiLng/Ry2K2krrR8pjbfBJ8wglHeUsTgaWSUIOta5eaBWxrhyOZtsLgAuxXw1n6pcOF66J2W6pdZHWuyO3QgfGUDaOm42HamH1M0GSt9qaS+ROWhN/kV/aaqJNhPNf6VajMIJooCRJbIT97V43O0AbL0wzRFs04Rbw/Fty2FW/v+9qg== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39542bc0-e8d3-4c67-7a01-08df13df85a9 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:44:45.1695 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jqR0BXsLOpDdDYUyi+6RL+QDdQC5Tdg/wUMbMaddnXQzLQRz43HESo8mcixC0oHYNczeDjXU0KXDzNk7vTEszgy7n0VZOTycuPtBYwPWcYQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7380 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXxzfpPlhYTKgz 9opON5QGoH4vI9pAitfxn7VmMKcRs3GYUvj7IrEQmkcE0zu7qJf7D2dzy1PUU/wD1Vjqzp6MAyi xYf2F6iXGGMa2CETHOpKVCjiNcGqmgU= X-Proofpoint-ORIG-GUID: 6GxFv3o7tf2jdG0-aexsyqUYcgSr1KfO X-Proofpoint-GUID: 6GxFv3o7tf2jdG0-aexsyqUYcgSr1KfO X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX8vn0HnGTVMmL qlxF0G1x6vsFtt8dEVVEMfvhfazWFXk9KGSP3GOARQGDALHQJsjuusQGJZ6wMSkZoEPShL9hSXc ie4obN0ArWNdEscdiSKzZ4g+MQ3ehTRglAFua/nU1OiGPgjcllaeOB1DYsmsu+37XBmEBSTjbb2 6CDBfxOUfP9ESMWcCrT2oD5pdqrATF29v5ilMc5XbL9akTVE0+H1sBmODtpPInchReKyIWpHkGL RU+Zk4RnDbLgSNgD8+dO0jRCZBDDVu2Tj7Je5I/KIDtGzlmFyStTqhoh0a7txDG/7OcLsoSkmMv 3XsLTMeY9GPHXCn8SrITMeZWCk2D/jOwOPxdkm97lLjyBX1Q1CmW5feNpxaWc7Jm4vG28P9Xwuk vlNpNVfhI3lounrd8WM4UFBjF9EXeNR3mLOckjoRKkiErTlbOSgOIVQviwlLlmFgJXVAkvLDgBh BtW4O3QGVkHZQ5kDZrg== X-Authority-Analysis: v=2.4 cv=QYvzLcbv c=1 sm=1 tr=0 ts=6aaa731e cx=c_pps a=5R5l3xa2V1v4tL9kvXelng==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=xWlEjtkXqD840QCPih0A:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1789555497-C24CBB50-58A9F50B/0/0 X-purgate-type: clean X-purgate-size: 694 This is to emphasise that child types of PIC_COMMON are all instances of an an 8259 PIC. Signed-off-by: Mark Cave-Ayland --- include/hw/isa/i8259_internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index 54dc9036cf..289d08b7d7 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -31,7 +31,7 @@ #include "qom/object.h" -#define TYPE_I8259_COMMON "pic-common" +#define TYPE_I8259_COMMON "i8259-common" OBJECT_DECLARE_TYPE(PICCommonState, PICCommonClass, I8259_COMMON) struct PICCommonClass { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422579.1647938 (Exim 4.92) (envelope-from ) id 1x6n8Q-0002vj-Ch; Wed, 16 Sep 2026 10:45:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422579.1647938; Wed, 16 Sep 2026 10:45:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8Q-0002vb-9p; Wed, 16 Sep 2026 10:45:02 +0000 Received: by outflank-mailman (input) for mailman id 1422579; Wed, 16 Sep 2026 10:45:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8O-0002pu-Vm for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8O-002G4Y-CV for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:00 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa732b-e002-0a2a0a5209dd-0a2a45059d64-4 for ; Wed, 16 Sep 2026 12:45:00 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa732a-4cb1-0a2a45050019-94a39744bb5e-3 for ; Wed, 16 Sep 2026 12:44:59 +0200 Received: from pps.filterd (m0127839.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8q4Uc541814; Wed, 16 Sep 2026 03:44:55 -0700 Received: from bn1pr04cu002.outbound.protection.outlook.com (mail-eastus2azon11020103.outbound.protection.outlook.com [52.101.56.103]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0pt9xw-2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:44:54 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MW4PR02MB7380.namprd02.prod.outlook.com (2603:10b6:303:74::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 10:44:53 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:44:53 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=/JiDjhK9ihDCRHHsJrq/x8B2es8Is22hCKPznDosI PI=; b=2G8M55Xbdeso9Lyaz/tF/PHCTQMqBf2xkG8nok1Ef+2h9zJcittzfqr7t mcGMauXPWiFcMgudgYQKNvQe3rrW+1ZSTAiOL6WKTIhfn+jmsRGNNaS9BbJrkk+j x0h3VR2NKkL21PZtkgO2kASUf3Tph8S/D+UEQayTUsfH0oo0vWu9GI63UhQjXSTo yS1aT2Y8jSYIbu4k32Z2xqPSrNWMT3R1ZRNWnoH6zMTGjHQ/j3OjJeFFieY1yT01 9CQw91hkbBQWWHm4BEzpN2nOv/YCkA35PZkjLTulSZ+Vt8/WjuTX/EFzCxtGjL0p CKZresKeYd8/WeJvSHOtWbs4UuxAQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FFeHadgar+P43tvQV9tE/xFb3ai4EpiLCUeJWsibWtsk22gG4x+YYkaZYAx2pnYeqsPH+PMk+6GZ6oeydPQcBLw4rhroL3Sut+liZ5RggEg3VJXB3zi7jpS0A+J9qGQaGbzawdUHoIWOoOSJK5nkIfRWkmvtYFs8TuZtBdVQZMvNHXC/P5AHLWTiqPZSdzmtv5sWZbONkISGLSo2dxgqbwA0yttFbQFybQNqSB86vk+zKdRKxvXB508BCF+Z3OdYRzmIhZ64u5IqaQ5wICI5kaySFogIiDii1BLqG95k0ylu7R4nyupvoz6CWvgbeO5wDV8qoQ2B7SFeNgRw8NCSGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/JiDjhK9ihDCRHHsJrq/x8B2es8Is22hCKPznDosIPI=; b=CTyNfM0rxldafRJAYw3lpAYGajwteKkYjWCP3SEDaRdwjBebriMfXb+nK1fg65nZI3E9ikZzTkxiSZNm3buLZsNt90/xvccvQjAeKw9dPe2mzw50gAm+oUGi6DWLP3uqzsJ2pE4jUVkt+vt7tVftqpA7WU1qCNLcq/zbXGCVYeb3NZeNrWksB3k4/Pyqrj50tneb6wBHoI6SKgDmgxn67vsHo3E7oATXhyx3L9B3sSHY74SrF7i1cAsgkOmQAAevX3/ib7KtTHbAe7Mqay8mbbLR8Pg0eaVM3J8nVtIkXY4yPpeYHIWZJdpNvCztJ3KcSaDq8Rk8Xhtb1OJwQ8Li2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/JiDjhK9ihDCRHHsJrq/x8B2es8Is22hCKPznDosIPI=; b=dRoIrO7O5EuJa7Hg5Ee7wz+vzL1yU6KhT3VCTShpSfE4uiB7yJ0Ifnmdqr6OGTTsyTVKnYjl46OBcfoRbRFXtdyjUqenZ1qnjaj2HXl6rzOFTnqkwNDIDP8exAnCaAwxDuUTRulDzv4TMEEJ9M+QD8X0Bpe/QU7RNu+dkhpZM/IbppyGAbnXME7Ej1Ebv+Tzom0AIOqC5OYYS19zk69bLvXqTU4x4z75V8lq6+SIFSAlN0OEoArn7CYMWXhGtewj2JX+jP0fAexS2CBYc5xAOWcHoYyCtK0p1dam2FeXU/uQC8+CWG1Nh/YURqZhVwUCAvM0iTt73Rlmb2coGgz1OQ== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 04/22] i8259_internal.h: rename PICCommonClass to I8259CommonClass Date: Wed, 16 Sep 2026 11:43:32 +0100 Message-ID: <20260916104435.600211-5-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0172.namprd05.prod.outlook.com (2603:10b6:a03:339::27) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MW4PR02MB7380:EE_ X-MS-Office365-Filtering-Correlation-Id: 253c477a-c126-49ae-400c-08df13df8a36 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|22082099003|10067099003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: 9H+ghNKnwKDFH7EdiIysRAASGEH6ET+us2KM5JNcprZM6LUgkH5cGE/7iXOi+nqSseBgAcEp94BQoOBd3mEYQBAw7lCg77EDkj5/hWg3dMYlBrD3yUyuWNlBG+ZkPU3E7vUM7YPctwha+z9z2WZA09tzo3KrY0hgUCri9J68TLOBIx/Awc8V4EMDZ9B31p6cy1gLSuxT3WAj4q7wEOBVaDCjKa6rof46MYErzNpd4p2K/sWaYIfo2y7uXtC/lSPup2ks4zZD0K1pNI2PoNRHfWiqkCN4IaX5LXuARNLTBROe9w9yW5AUlG3pQudCjE1RHuV36hhj9noza5YI3VYytYH/dFrV9oYiUUrZI66O9JOowDvc0fGOuxqSFcQNntHDJjnZe/qahBaofQUXK81baXStdSqOQe+IWsk0MMNiuH0C2QzWmjqftUBHIfuRLvSa6N5Cr2u9+2i1Ogmjq1jyRy4lE9+9LlR5Snh8fuf8IjtPPAgugIrGSjteKXVUTQLAKBO6UyuvmhUeCxh+f/tgeg6liceDNoX4VB+oSXXM317WnK8IXlDNUy1s4y0sUpxf5PVtpPlNBTiEWHPUTUhdqNP+UdhVlreQNtov4NIiuFjZ+3o4e+qXtKYWWTEQi3Z0885XpE/QDlW3HZgnXKGe5ruCCYzr5lqEds95uxm5d+0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(22082099003)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/Y6aHUZhj4ZcKESIabf8UQPM3yBnXRPfyNlgjdfxCH8lDRbRV8QuT2XgOWjf?= =?us-ascii?Q?H7JL5H7gxOp4WI/265vIpJAiV06O2HZJhkftfbaPu9p94WAU7Het/Tq/NRZn?= =?us-ascii?Q?flXlCmgeBH+asbA4Trz7V1eqAIOdpj3T8sda1VZUvSb2Nmp3SZXatQWCKG6v?= =?us-ascii?Q?uWNG0Ggsgb0vLHt9c7UQBkGXuYfsRKVm7adWS8Bk8yrd8K0uis803yRml3i+?= =?us-ascii?Q?MZk/F0REnx3Epo53JGsoAmjMoXZV+7ZlQoNWJ3Vft8ZeO2HVSLNQGwLUGrMA?= =?us-ascii?Q?1pqChdliLO8ovXa2suRrU2iZwt9iy3VPuamlNqbB8CbcF62VsDXT8TtQnvDw?= =?us-ascii?Q?beCusrVC8HM9gTKawZ/2p6/aHo/wBHJb4kgkgFheqmWecB+EgRLLthd0H0Ms?= =?us-ascii?Q?hVPF3V+bE3dEoBMCAbWOItJa4inEI17aP5x102/5oWcQU6RoBitYdFHgxtHP?= =?us-ascii?Q?MJjwQl9FmHsQW7TyseSlWm3sOTX9IflF3+YSrGL64065aIVjkFJwTUFg2QCU?= =?us-ascii?Q?nh4w4QnX0/V+XHG/9tmE2TslGek8ftUfCau9sdgw+nJQYfif0CXcae5etmuP?= =?us-ascii?Q?pSYhh+06Sxczk4uAKZZnw+P0X1HhPVYenA2czgjIE9cwShXVltYcYQUf1MwY?= =?us-ascii?Q?h5YQQCRpI9USK2TO7WsyvuC5kJ8OflRItrw8NKV+TqrZyXDRhBu5bmZpUBry?= =?us-ascii?Q?8Adq6MZi84+XKC0uEN/50S80mgbVYzuyHAdykGDWxSJGcm3/aex5CPkM99M0?= =?us-ascii?Q?/dHvrn9Q3obzCdvkIs0roF1sGseKjxJAEYBcy7lsQ2Cn0JuJAGxGNEzbl38k?= =?us-ascii?Q?gpZKlSAZfz5ifnQLxe8hBF9k0Z9uZHUF0iS+1AneujNnDLN9IYd5HTPztNY8?= =?us-ascii?Q?9biQZg4GAg/zwuLi1N9fjLo0bEXUz74kmqJ8MDKWflSgmEranMy4JKAyhlsZ?= =?us-ascii?Q?G/rngIPm+q+fok18WHCY6kamOMEUR6wVwGBpgXO/4WCQlIOKk6yeWevk47AE?= =?us-ascii?Q?szuTRb1LexEKma15mASW520xF4AJzo2fmsz/pawdr6n8GkIa2E+sOmnMpBfo?= =?us-ascii?Q?EXJ3nUQDlFho5ViHQ+eu0NdnL1PE+KHvjJReVD4BTJNwtChzGWdnHnOUS2Ep?= =?us-ascii?Q?34sH1WxKD0HVZFReJ+SG9xMLsYNXFUc2clP32ByJuIFawBS1LbIinNZnfFyu?= =?us-ascii?Q?XqoHbxgHHAWIywkcRBiBLJhJ/PFs++Wvgg6RqpA+Mdq9s4AGcr1G4d0usYQ7?= =?us-ascii?Q?frKgH8CokLXWv71xVsw/Eau3Vonln6jHhJMV6GmdClYprp/lQFPckaQ+iXxe?= =?us-ascii?Q?pAL8uFepLOvIQ0B8zRHPEjzvp4kAAA4/N81tTMuDz8O4dKXUhuXgmWGye9RT?= =?us-ascii?Q?C7sYAI4S5cDLRbXmdIcd8e5c5vJlhenXj9JApXOT8NBqStALpyVpB1OJnEAm?= =?us-ascii?Q?mh+ePKPiseq4UdrfGPKc4jgLFOPMpzb3cA5UaDeQGFQTehljCYFzg9cuNr9l?= =?us-ascii?Q?PdertWQl/3krp/EHYsnsFeixSx26IrZElCl4K8zJZaJOqccrCcw0VVrz+UdQ?= =?us-ascii?Q?OCjfkrbcXh2soKFylY46FgiZec2BaFmXwUDXzhX3V5AR1PNCVi4IptfaX4vo?= =?us-ascii?Q?NqqV4+CS5OWv55E8JSmOAVj+dxETFYeoKAdaj42s+vr9zkDUVOe7kZxN6FMk?= =?us-ascii?Q?+bgNwQUsCKTVZwP/zoOzeJiPA9tfDe4MUVKgBX4c5qboJVTRcHJizc02C9Cl?= =?us-ascii?Q?DyI9sPRzaJwgwzVBJX02CUCd+FePdak=3D?= X-Exchange-RoutingPolicyChecked: u2MfnjxmuHq21fyYdaEZAZhzlTRIFc4XsQYS329QN0AmMIOTFNlRVee/I2gtT+Ih/aYZiBgASMQKHKduUtYM70DH/KJKvD6o+Mm4QnkRKjRTJCBt0Te+REJyBisvm078VK4zPORi7JNOyZkRJPMYSOVKToOTIPIH+pEGEYgQCKhVXCG2hWKIEUlt5/lUwSvdN6VMXqjd7XfAdZlwTkBgN84LEYvBvl/gD/N7ygLNOBiOrWHYx3RMDZziNOMLZ8OyBRM/QTZfE7bOcmnLVCrpnlLnfm+sAqQihve0inT/r66yNzsDBHJTT9GuWaqw2AzYgbDLmpaeXuzmbZg38xHElQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 253c477a-c126-49ae-400c-08df13df8a36 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:44:52.9570 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: szo+oyR6Z42Cub15A6V3HoL5abKwWCnUUMV/urC53LXJSk4NZdBteyR346SW+jrCLNTEBqlVQ4rCQUGlc225SquDX43JGbU3IoE8ldMmRSI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7380 X-Proofpoint-GUID: 6QG87q_fHnRmciYURCiYzuxU4ytyhHfa X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXzD0hUIVFxmFS e2wMDX8/qZmRMSlktjwNtT2ZKNax+aqlFtpmhYXdj0vb6B1g7bNtVaogTac/Iu0D5Jlxt4N3uqY HJE/WK8gndrngs3T/mr+LkttGMeaD/o= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX6lmGkHivmc+O SIfzKS6onzYc37akVMtRkp+0B7NG7Atj7GBPTSRx2cKzmq1Tz8keGbpOkDjKdkRwAMviKgnDWG0 jK5Dyxt0vv3Z0OXtplVBXMhSiuf6PigSiv8CJdB68beC2a0PB/z/e7E6l/s8ApG5qjn0C1LWTTw uG8uuEWgO6N4Lwz7iIqkVWGuXfUlk05ql/ZvJhlUXcsujd86rJ3S31dyF8+icVQg1BWBVNFaIxa VcnHxdN6r3qhZ3VjBm5lbHMD841wFrPxpGbHKQRkzaKLia6SkNtMyciR5aLTf8oPnU2gZpKuJQt o9A+xhK51N7UZndnhAYW1I1dywA2y19kZYkdOuOaPbJ7SF9fSc8yTQvYsBmd+3T4CjPZrtsebRS EFwKoh/BTLwO+hPoBus/8/dBQSIBMxuogNk07wu3vVz8NOJenrAJDFze/sButiOF2YnUOXr3zfU t1WySzR4464WZ0EDy1Q== X-Proofpoint-ORIG-GUID: 6QG87q_fHnRmciYURCiYzuxU4ytyhHfa X-Authority-Analysis: v=2.4 cv=Ps4G/AM3 c=1 sm=1 tr=0 ts=6aaa7327 cx=c_pps a=WPXs+xwE9Zb4LCNJX07eKw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=qh9Ixq9Ib_qUO60TQ2wA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c201ff/1789555499-24D1E2A1-06DE47A5/0/0 X-purgate-type: clean X-purgate-size: 3236 Signed-off-by: Mark Cave-Ayland --- include/hw/isa/i8259_internal.h | 4 ++-- hw/i386/kvm/i8259.c | 4 ++-- hw/intc/i8259.c | 2 +- hw/intc/i8259_common.c | 6 +++--- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index 7a2f9addaf..e039d6f067 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -32,9 +32,9 @@ #define TYPE_I8259_COMMON "i8259-common" -OBJECT_DECLARE_TYPE(I8259CommonState, PICCommonClass, I8259_COMMON) +OBJECT_DECLARE_TYPE(I8259CommonState, I8259CommonClass, I8259_COMMON) -struct PICCommonClass { +struct I8259CommonClass { DeviceClass parent_class; void (*pre_save)(I8259CommonState *s); diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index f10643a120..68607d721d 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -29,7 +29,7 @@ DECLARE_CLASS_CHECKERS(KVMPICClass, KVM_PIC, * @parent_realize: The parent's realizefn. */ struct KVMPICClass { - PICCommonClass parent_class; + I8259CommonClass parent_class; DeviceRealize parent_realize; }; @@ -142,7 +142,7 @@ qemu_irq *kvm_i8259_init(ISABus *bus) static void kvm_i8259_class_init(ObjectClass *klass, const void *data) { KVMPICClass *kpc = KVM_PIC_CLASS(klass); - PICCommonClass *k = I8259_COMMON_CLASS(klass); + I8259CommonClass *k = I8259_COMMON_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_legacy_reset(dc, kvm_pic_reset); diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 45db87a2ad..547e86c5f4 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -44,7 +44,7 @@ DECLARE_CLASS_CHECKERS(PICClass, PIC, * @parent_realize: The parent's realizefn. */ struct PICClass { - PICCommonClass parent_class; + I8259CommonClass parent_class; DeviceRealize parent_realize; }; diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index 17040bdb1e..ac8dc7cf00 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -56,7 +56,7 @@ void pic_reset_common(I8259CommonState *s) static int pic_dispatch_pre_save(void *opaque) { I8259CommonState *s = opaque; - PICCommonClass *info = I8259_COMMON_GET_CLASS(s); + I8259CommonClass *info = I8259_COMMON_GET_CLASS(s); if (info->pre_save) { info->pre_save(s); @@ -68,7 +68,7 @@ static int pic_dispatch_pre_save(void *opaque) static int pic_dispatch_post_load(void *opaque, int version_id) { I8259CommonState *s = opaque; - PICCommonClass *info = I8259_COMMON_GET_CLASS(s); + I8259CommonClass *info = I8259_COMMON_GET_CLASS(s); if (info->post_load) { info->post_load(s); @@ -223,7 +223,7 @@ static const TypeInfo pic_common_type = { .name = TYPE_I8259_COMMON, .parent = TYPE_ISA_DEVICE, .instance_size = sizeof(I8259CommonState), - .class_size = sizeof(PICCommonClass), + .class_size = sizeof(I8259CommonClass), .class_init = pic_common_class_init, .abstract = true, .interfaces = (const InterfaceInfo[]) { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422580.1647944 (Exim 4.92) (envelope-from ) id 1x6n8Q-0002yo-QY; Wed, 16 Sep 2026 10:45:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422580.1647944; Wed, 16 Sep 2026 10:45:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8Q-0002yR-IP; Wed, 16 Sep 2026 10:45:02 +0000 Received: by outflank-mailman (input) for mailman id 1422580; Wed, 16 Sep 2026 10:45:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8O-0002p8-T9 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8O-002G4Y-A4 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:00 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7321-e002-0a2a0a5209dd-0a2a45018ec4-42 for ; Wed, 16 Sep 2026 12:45:00 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa732a-5984-0a2a45010019-94a39744bf5c-3 for ; Wed, 16 Sep 2026 12:44:59 +0200 Received: from pps.filterd (m0127839.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8q4Ub541814; Wed, 16 Sep 2026 03:44:54 -0700 Received: from bn1pr04cu002.outbound.protection.outlook.com (mail-eastus2azon11020103.outbound.protection.outlook.com [52.101.56.103]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0pt9xw-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:44:54 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MW4PR02MB7380.namprd02.prod.outlook.com (2603:10b6:303:74::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 10:44:48 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:44:48 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=oCxDLQQ0JtOJx+l00uKoBh/UgomiZOIYm3LR6JQrD XA=; b=zHHVnhS6ojghbU7jIp7YfnsSZ+e6aA3ok8ZgOJCPNrylUk5KqJ94VlSqg 5b3DSQ3sY9KWKUrioIMa3dr57cOih+jJ4GcXRnHGjL1Qo5rHnRwDYwJ98LpsOwyg Mbkc6CIMe/wLnOEQHNOkhc85ivF5yEYsYi9rmYFnzVzzaJQbe2/iDzlO7L2ghj9N zjp6UwdYa4HNO2Uq60uGcILT3gekkRnf8Q+V3BWOTM+S1yrpbvJp9a/seHcCtskS sa2ieIYqn2qeybL77cb+kFuKtcg5UedwNIU5WeMJy6dK/i15IhuuYE5u3qZAxHWM D1qOULVZ+1Ab9mKdr6/R9ui7FsqOw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=J4Ytt+ZAMJcNRjOYNEiYnROly+7klnM2ruopQOO8rs1MNNKFNzyjNNwbRaSEExOYCFX4aiqGdZ8wOtArYcJM1A1w884qMB4iQmWijN9qK3PSm56Ao+T1b6Gnvq0lbaA1ztC//9N4kt1dVYCojCb2Mr0uJ3mw61P7hh8DivtNB/8h2KY8jIHrNTufGszDwQ1cOkQpuvRfPp68eLAbaf37KqSwx1bUec1PV0095JLS0wFwjiCGxSBWLiDQbLqXqOPYnuJKE4g3eF/Dj4/cTMlTO5vFc28pkleY13ghanhp8zs4DsauTvon4qB6tFewXt1swOVVgjmAEdFXSn18Dj9few== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oCxDLQQ0JtOJx+l00uKoBh/UgomiZOIYm3LR6JQrDXA=; b=e9bt/ipdC/4WmHDbuq2MYD4CcMRGRbcAKM0sCeHJ0sP79abTyyN8J7BtKDtphnz8BgrN7IO6OGtS+rZtjeYNsfFuw+ucli3GRFvuAPyo698qc4e01KGVMfvM6JBwnGcudN6imAu+hRKPiIubXoY/iZQyw74OXmw8V9CrR5LblkTPtQ7cyexS36NbHwUJYsPmoF4OvXcALSUMeKL0zuVFKbhiLkCuFT6b9VH59+4k6oAym6UEk0GJNQpBXo0pXyEuAtnolwoRfsqUxK4M+t+5+6aivJ+n0hXM2sa2rqtC+DeDALSKYnc/uRAKqnzGrR9ZMbiLB0xowxKfqwutPE4vvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oCxDLQQ0JtOJx+l00uKoBh/UgomiZOIYm3LR6JQrDXA=; b=VAagvSOdYPhz7ilzs5Q/RrPHgqJ+0Ki1trQuX52D+fQ7pZBp0dGATP8yocyJUIiF0WYlvCtJZu9yI4ivhskoej0AK9QFBNj4GZDLjCePSnbv2apyM0w8EI7Im/MACfSaSkrfjDwMA9rkbCKVvidZT50GthLukwDkhOzi8dba3v4IZwHh5Qifp9HJFxAOfrvKlgwclOwK3/lHvTiH52vXjFZgiMX1KzumZWRmVr6Fni05WM5DpZkE9c4TjFmh0hskigzlz5KmVtRJQE6RKjnQfquOsAJqgjujmIA9X1fWo/Shi4O7kgt/FYkne8o5EgtHOCc1fS8c3aT0f2ZDkuXUCw== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 03/22] i8259_internal.h: rename PICCommonState to I8259CommonState Date: Wed, 16 Sep 2026 11:43:31 +0100 Message-ID: <20260916104435.600211-4-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0056.namprd03.prod.outlook.com (2603:10b6:a03:33e::31) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MW4PR02MB7380:EE_ X-MS-Office365-Filtering-Correlation-Id: f52442b9-c85d-4c94-e8a9-08df13df87b5 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|22082099003|10067099003|3023799007|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: pzBTX3ZpHkQEMssxpYlRUxBmCcytQ06n+Cyzla4PFCi55Nv1Ztc4BJ508xXZk530NJ7LuhG6310lDTbI4dir6VMnLevE0/Klg1V1N4f2QGzFjLRu1cc1Nn/ZPT6oUl7wdrDwmf0aM50X/fac2qH2PK5ZjjPmqnQqGbQCblwpGckyypuKqSDgrA4fqe7wPwitWOh+OZuplVbUdFWWwWj3/uRKsm7Ng84jhTioAsRoiAkHl1yiAwQnBlQqHiR+3jeY6W5p81iiH6+WaPQkQAavdwu35GRbXIz/yhHaump40KKL37nhYGolscwy1nS2WUr0YfgyqtuFjxESKbAScgDMKqm9CSwJD1z1EJ0NccPzrOSo6hj+MhGAsRm6eqXXMf+g+vczvfPgyiT2UJ8TfBBfT6S+RaLe1Byz0wc9jHdXUmlQkR5Uw0H6M+qYNquz8LxTR2iyAs4fJtoUQWM9vR4MCpMWn/JlYpoXuhZBq3rw2AVPG0kaQPNvC/2INXPRsS8XBUXNB0Kwb4VY5wf2POwfJdDju+Chm8IISFStIbuqtXdo4WON0qyoxZwnjfddjSfiRYwPXOJYZ0UvCUS27H/zN+bMdoahU6l1omiGvKxSr5HQJ6L4iZWXemLkBlB8OG3C49+RTBK+NRGhb6gFGZbvOKFg+binYLVQanLO4XEP1ZE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(22082099003)(10067099003)(3023799007)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?DGx0rcPHr9WquJH6dWY5Ml7TrVKKK8i2Vo2EBBfa3amL9XVhgpjdo+xEiMUN?= =?us-ascii?Q?QEttGsBgL9GGbnqshQzavuVj24yGkR2Go+6DW2JWIQYuDFKPNHqky/3ySkvE?= =?us-ascii?Q?PCBEkZ6xwXVCL5xhkbAY5wz3eGageuAY1CbR39nfZBD8GcXQaQ0zK5v/4JSu?= =?us-ascii?Q?2+vQmt4TFtz4lhrzi9Msepyyy83CHwuTpFgybzAFZPESP0MdW4tcVt3oQLQx?= =?us-ascii?Q?Nd0eLboFCtACojz4zUU+iWAKgk3obs+sbQlK7nSbgZwLs+tSNfQaMbYbr8hT?= =?us-ascii?Q?+IzfX79EcUm6Gv3njDQRSBt4CaFjxNHBcZJWyZuGxRHIgJ+QXVdi07/rMEPM?= =?us-ascii?Q?lDlCDRKB6tMFAZuh0IdtErsLw1mM2HQTZudB6gtdCxs5XtQkeAASBAqFgAxV?= =?us-ascii?Q?J/hQ/kkTcFYIJBhhHLOp1eoVdyHHDwtZjBiWnU4Cyp3ndPOiJti+fNe5wjH9?= =?us-ascii?Q?egwZOkxncgldAspLHQN4D0ZvKdOo6q3mOFALew1qC2wmKEamyW+yo1OneMc3?= =?us-ascii?Q?qx0uXZ+ekNMvGBPBjt6r1FV8cn9K/IIjY5f0/mgmNlCW/6uLzeYIKREz01Xs?= =?us-ascii?Q?FkyATZ4ftOgyIcu5uOzUp6u8eHAwUloi/giXFJttE4o2n7DxMcdJpY0YsGeo?= =?us-ascii?Q?qJHfZyMjNDQAqxKRjU2fgO/v4ZYPsRXto5iyO1M5IVF1W+ru/kiJB040TjF0?= =?us-ascii?Q?PJ8RHedcELkQuNkYOvQcoQmPLTEkBcWIXivinBNQ86ZsrNl3iLwy4kaGaDdz?= =?us-ascii?Q?6C5T8fJFo9RSH00TCtZMdslI1nupKcabR37tvnOJa53bEHvmZktaORMY3UQp?= =?us-ascii?Q?qvtkn5fBqE87bkFrJWx8SkPv7UUpDHLGbMWClBgMo/dGuerJNvYSRDUWqRHa?= =?us-ascii?Q?sNB7QmziKinzouEkojlWVpPDLtTB7yPhzOZ6xM9V6g5eLtGsZKZAUsj27TtH?= =?us-ascii?Q?uUaENN3aHBM06JWrq+HPO1YVhbSMJwjar4wSkyY17Txf7r/0ordHkS9+LuO/?= =?us-ascii?Q?kIiEvuZTezb01QTpyUJeSUfKd+kDMqlT6S0BR7fbzz22Dz5urnl+647wE0F5?= =?us-ascii?Q?ckPJCDKZN8C09OJ8o6CPYwXGB6CqzR5g4SdYbAPpoSBzm9qxumYcni85gAYZ?= =?us-ascii?Q?WXi+bWjAHfWo4F4zXtw2mJKfRFi9/cMrymbPbpL9hRg6aVSgyEXcUrP2fEFR?= =?us-ascii?Q?+82+zsQI5SYbXPGoRyt01X0JZt6u+P3wtVTj5cEZqSMlw74zjDiqkuhHAY1l?= =?us-ascii?Q?8YGmaFcCddl2lw0fc1vQhKlwQZszZuKWZbE7wU/07ziGDV9dqI0xITs854V+?= =?us-ascii?Q?6iKlOPH2XrUijQmJINIsb8T++4fDZWZvn/BeK6/kW1ZZ0iNrQ+I/Hi/1K2sd?= =?us-ascii?Q?F/9l1LlP6vJwkMU93PLOmbQek7eOv4ob0I2LsHCeKabahQPjg3/5+g/g1fIN?= =?us-ascii?Q?P+AYIPvjEDd4xcryGvhdTb9qRcObtRLpLVg/9skthzhsW6vLF6px2btHQt+E?= =?us-ascii?Q?H0kdO5MU3p//i/1njokyfZOliVzgI5zYJWXNUhtfNgJmv1K3GHUSxQUe19/1?= =?us-ascii?Q?jq2yRIdKgdtqhkz6pyFPzetIS2X6UPspxzaitkpDMhgsu4PuLXf5Ll0Azh6d?= =?us-ascii?Q?MdMITmEoprfZcsZIhvZHj86zU9PcL0rBagQP4cFVIojcha3WcTEjYuqJqQnm?= =?us-ascii?Q?JQJype+4bwD5FeEDHsBu7uBOkZIrOlbnNOzxMWGoE2QZ1/slSRy9xpVnGlqj?= =?us-ascii?Q?eOHqcRz7j8fVaTvw+H6dHAIY5LF2/oY=3D?= X-Exchange-RoutingPolicyChecked: fiXGG/uq0ni/TD5YsQf+7XB/3OIi5Zv1pXl7JC7vQza+86dveJaPmGWeJpTDFwXpBOGykzZ2JS08XJTGDFIv/Ik+VfJjJFuazbH+XFfIYrbysGAzu0u+ihlnKT+hA04meHLgU1GsAnD7nSMDX6NjdjRz5C3n44kR2Wm6LNFgUK2kzlYUMDWDDuhwexHwYLapaTVkkhws6hWenQ/gf+qJ3qOGWfOkgfszF5vEHcwCQSs2f4dpk/zy7S9o21/huJFX6vW9kkbuPXFX9q8WvwIqOEhYOXotfk5bjTagB4l8cRmYlQ9nKzuV7XmMD1CLwgwZgiCkxjwL5ROJc/mvWrccJQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f52442b9-c85d-4c94-e8a9-08df13df87b5 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:44:48.7674 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: joFT/uxeyLQxacYAsLt5so5Cj94sXdpPTkuk9Z7ONz+biwg88xqWimaFgb7+QbpAsF3KOW+Z7d6WDqEK31J58PjW0mCBiNMjVGTGSnh497Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7380 X-Proofpoint-GUID: rnFeN0odM08iXz9gj7odNRaiY4vShV-e X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX7zmgByKtVDO/ sMMsDsb/pm66Tyhbiqn9Pzo2XDLbPuo8OseAdQRmsa+uh/c5a0XYpI5/4cFzd0y7PPWtHL7EZvC kytv7cVuk9sdK8xzAzm2OvuwozUwhfg= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX6FAZ131tOhRZ gXuOMU/atiFn4btLM+IMqIqxsBgPcRi+gH917zBDxuaNT5crThTk2RNlaYIPy0VGOJ/8Z43K+yL PccjQNWTKYE4JI/YXcEUYCSLnkBLDkAs0kNl3j5XRLVcptaO6x1D5s+4NUAbe8uOvQA3+yBnssM TDzomF7y/jtqzkfx6kF5Ex04w7vWZbEZTUOjEbwGCJ6T1RxAb36QEu1fPcAWrr3EVt+9q82bjTD NidRibG9wJqHh53ku9Nre6MIWO+7wh0gKGY01dR2f+fmoOIMM+Giz/f1cGzprwDFgjzE8For/7s DwJnuhzTLBI1yljFZxnBlanPFKLv14TCid3GsRtLbIO/YvkU8V32sqfepGKH9f7zV44sAD6BawA 5x70Shc/eT3NaLAU15Ik+2X+T/ZY54nkip1Et992tBNOX1AM/Ikwh5hSPVN7saFkrw9jzy6iBER BIgMD3fVHR67hpWBfDw== X-Proofpoint-ORIG-GUID: rnFeN0odM08iXz9gj7odNRaiY4vShV-e X-Authority-Analysis: v=2.4 cv=Ps4G/AM3 c=1 sm=1 tr=0 ts=6aaa7326 cx=c_pps a=WPXs+xwE9Zb4LCNJX07eKw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=01ND9n3NiX1-kDoXiQMA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1789555500-1E27A757-83CDB1E9/0/0 X-purgate-type: clean X-purgate-size: 14343 Signed-off-by: Mark Cave-Ayland --- include/hw/intc/i8259.h | 8 ++--- include/hw/isa/i8259_internal.h | 10 +++--- hw/i386/kvm/i8259.c | 10 +++--- hw/intc/i8259.c | 34 +++++++++---------- hw/intc/i8259_common.c | 58 ++++++++++++++++----------------- 5 files changed, 60 insertions(+), 60 deletions(-) diff --git a/include/hw/intc/i8259.h b/include/hw/intc/i8259.h index 1f2420231f..1921a30371 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -3,9 +3,9 @@ /* i8259.c */ -typedef struct PICCommonState PICCommonState; +typedef struct I8259CommonState I8259CommonState; -extern PICCommonState *isa_pic; +extern I8259CommonState *isa_pic; /* * i8259_init() @@ -16,7 +16,7 @@ extern PICCommonState *isa_pic; */ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in); qemu_irq *kvm_i8259_init(ISABus *bus); -int pic_get_output(PICCommonState *s); -int pic_read_irq(PICCommonState *s); +int pic_get_output(I8259CommonState *s); +int pic_read_irq(I8259CommonState *s); #endif diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index 289d08b7d7..7a2f9addaf 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -32,16 +32,16 @@ #define TYPE_I8259_COMMON "i8259-common" -OBJECT_DECLARE_TYPE(PICCommonState, PICCommonClass, I8259_COMMON) +OBJECT_DECLARE_TYPE(I8259CommonState, PICCommonClass, I8259_COMMON) struct PICCommonClass { DeviceClass parent_class; - void (*pre_save)(PICCommonState *s); - void (*post_load)(PICCommonState *s); + void (*pre_save)(I8259CommonState *s); + void (*post_load)(I8259CommonState *s); }; -struct PICCommonState { +struct I8259CommonState { ISADevice parent_obj; uint8_t last_irr; /* edge detection */ @@ -70,7 +70,7 @@ struct PICCommonState { MemoryRegion elcr_io; }; -void pic_reset_common(PICCommonState *s); +void pic_reset_common(I8259CommonState *s); ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master); void pic_stat_update_irq(int irq, int level); diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 14029783e5..f10643a120 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -34,7 +34,7 @@ struct KVMPICClass { DeviceRealize parent_realize; }; -static void kvm_pic_get(PICCommonState *s) +static void kvm_pic_get(I8259CommonState *s) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; @@ -67,7 +67,7 @@ static void kvm_pic_get(PICCommonState *s) s->elcr_mask = kpic->elcr_mask; } -static void kvm_pic_put(PICCommonState *s) +static void kvm_pic_put(I8259CommonState *s) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; @@ -103,7 +103,7 @@ static void kvm_pic_put(PICCommonState *s) static void kvm_pic_reset(DeviceState *dev) { - PICCommonState *s = I8259_COMMON(dev); + I8259CommonState *s = I8259_COMMON(dev); s->elcr = 0; pic_reset_common(s); @@ -122,7 +122,7 @@ static void kvm_pic_set_irq(void *opaque, int irq, int level) static void kvm_pic_realize(DeviceState *dev, Error **errp) { - PICCommonState *s = I8259_COMMON(dev); + I8259CommonState *s = I8259_COMMON(dev); KVMPICClass *kpc = KVM_PIC_GET_CLASS(dev); memory_region_init_io(&s->base_io, OBJECT(dev), NULL, NULL, "kvm-pic", 2); @@ -154,7 +154,7 @@ static void kvm_i8259_class_init(ObjectClass *klass, const void *data) static const TypeInfo kvm_i8259_info = { .name = TYPE_KVM_I8259, .parent = TYPE_I8259_COMMON, - .instance_size = sizeof(PICCommonState), + .instance_size = sizeof(I8259CommonState), .class_init = kvm_i8259_class_init, .class_size = sizeof(KVMPICClass), }; diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 52e24d333e..45db87a2ad 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -52,12 +52,12 @@ struct PICClass { #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif -PICCommonState *isa_pic; -static PICCommonState *slave_pic; +I8259CommonState *isa_pic; +static I8259CommonState *slave_pic; /* return the highest priority found in mask (highest = smallest number). Return 8 if no irq */ -static int get_priority(PICCommonState *s, int mask) +static int get_priority(I8259CommonState *s, int mask) { int priority; @@ -72,7 +72,7 @@ static int get_priority(PICCommonState *s, int mask) } /* return the pic wanted interrupt. return -1 if none */ -static int pic_get_irq(PICCommonState *s) +static int pic_get_irq(I8259CommonState *s) { int mask, cur_priority, priority; @@ -101,7 +101,7 @@ static int pic_get_irq(PICCommonState *s) } /* Update INT output. Must be called every time the output may have changed. */ -static void pic_update_irq(PICCommonState *s) +static void pic_update_irq(I8259CommonState *s) { int irq; @@ -117,7 +117,7 @@ static void pic_update_irq(PICCommonState *s) /* set irq level. If an edge is detected, then the IRR is set to 1 */ static void pic_set_irq(void *opaque, int irq, int level) { - PICCommonState *s = opaque; + I8259CommonState *s = opaque; int mask = 1 << irq; int irq_index = s->master ? irq : irq + 8; @@ -154,7 +154,7 @@ static void pic_set_irq(void *opaque, int irq, int level) } /* acknowledge interrupt 'irq' */ -static void pic_intack(PICCommonState *s, int irq) +static void pic_intack(I8259CommonState *s, int irq) { if (s->auto_eoi) { if (s->rotate_on_auto_eoi) { @@ -170,7 +170,7 @@ static void pic_intack(PICCommonState *s, int irq) pic_update_irq(s); } -int pic_read_irq(PICCommonState *s) +int pic_read_irq(I8259CommonState *s) { int irq, intno; @@ -210,7 +210,7 @@ int pic_read_irq(PICCommonState *s) return intno; } -static void pic_init_reset(PICCommonState *s) +static void pic_init_reset(I8259CommonState *s) { pic_reset_common(s); pic_update_irq(s); @@ -218,7 +218,7 @@ static void pic_init_reset(PICCommonState *s) static void pic_reset(DeviceState *dev) { - PICCommonState *s = I8259_COMMON(dev); + I8259CommonState *s = I8259_COMMON(dev); s->elcr = 0; s->ltim = 0; @@ -228,7 +228,7 @@ static void pic_reset(DeviceState *dev) static void pic_ioport_write(void *opaque, hwaddr addr64, uint64_t val64, unsigned size) { - PICCommonState *s = opaque; + I8259CommonState *s = opaque; uint32_t addr = addr64; uint32_t val = val64; int priority, cmd, irq; @@ -321,7 +321,7 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, static uint64_t pic_ioport_read(void *opaque, hwaddr addr, unsigned size) { - PICCommonState *s = opaque; + I8259CommonState *s = opaque; int ret; if (s->poll) { @@ -348,7 +348,7 @@ static uint64_t pic_ioport_read(void *opaque, hwaddr addr, return ret; } -int pic_get_output(PICCommonState *s) +int pic_get_output(I8259CommonState *s) { return (pic_get_irq(s) >= 0); } @@ -356,14 +356,14 @@ int pic_get_output(PICCommonState *s) static void elcr_ioport_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) { - PICCommonState *s = opaque; + I8259CommonState *s = opaque; s->elcr = val & s->elcr_mask; } static uint64_t elcr_ioport_read(void *opaque, hwaddr addr, unsigned size) { - PICCommonState *s = opaque; + I8259CommonState *s = opaque; return s->elcr; } @@ -387,7 +387,7 @@ static const MemoryRegionOps pic_elcr_ioport_ops = { static void pic_realize(DeviceState *dev, Error **errp) { - PICCommonState *s = I8259_COMMON(dev); + I8259CommonState *s = I8259_COMMON(dev); PICClass *pc = PIC_GET_CLASS(dev); memory_region_init_io(&s->base_io, OBJECT(s), &pic_base_ioport_ops, s, @@ -444,7 +444,7 @@ static void i8259_class_init(ObjectClass *klass, const void *data) static const TypeInfo i8259_info = { .name = TYPE_I8259, - .instance_size = sizeof(PICCommonState), + .instance_size = sizeof(I8259CommonState), .parent = TYPE_I8259_COMMON, .class_init = i8259_class_init, .class_size = sizeof(PICClass), diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index e2f997e161..17040bdb1e 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -33,7 +33,7 @@ static int irq_level[16]; static uint64_t irq_count[16]; -void pic_reset_common(PICCommonState *s) +void pic_reset_common(I8259CommonState *s) { s->last_irr = 0; s->irr &= s->elcr; @@ -55,7 +55,7 @@ void pic_reset_common(PICCommonState *s) static int pic_dispatch_pre_save(void *opaque) { - PICCommonState *s = opaque; + I8259CommonState *s = opaque; PICCommonClass *info = I8259_COMMON_GET_CLASS(s); if (info->pre_save) { @@ -67,7 +67,7 @@ static int pic_dispatch_pre_save(void *opaque) static int pic_dispatch_post_load(void *opaque, int version_id) { - PICCommonState *s = opaque; + I8259CommonState *s = opaque; PICCommonClass *info = I8259_COMMON_GET_CLASS(s); if (info->post_load) { @@ -78,7 +78,7 @@ static int pic_dispatch_post_load(void *opaque, int version_id) static void pic_common_realize(DeviceState *dev, Error **errp) { - PICCommonState *s = I8259_COMMON(dev); + I8259CommonState *s = I8259_COMMON(dev); ISADevice *isa = ISA_DEVICE(dev); isa_register_ioport(isa, &s->base_io, s->iobase); @@ -118,7 +118,7 @@ void pic_stat_update_irq(int irq, int level) static bool pic_get_statistics(InterruptStatsProvider *obj, uint64_t **irq_counts, unsigned int *nb_irqs) { - PICCommonState *s = I8259_COMMON(obj); + I8259CommonState *s = I8259_COMMON(obj); if (s->master) { *irq_counts = irq_count; @@ -133,7 +133,7 @@ static bool pic_get_statistics(InterruptStatsProvider *obj, static void pic_print_info(InterruptStatsProvider *obj, GString *buf) { - PICCommonState *s = I8259_COMMON(obj); + I8259CommonState *s = I8259_COMMON(obj); pic_dispatch_pre_save(s); g_string_append_printf(buf, "pic%d: irr=%02x imr=%02x isr=%02x hprio=%d " @@ -146,7 +146,7 @@ static void pic_print_info(InterruptStatsProvider *obj, GString *buf) static bool ltim_state_needed(void *opaque) { - PICCommonState *s = I8259_COMMON(opaque); + I8259CommonState *s = I8259_COMMON(opaque); return !!s->ltim; } @@ -157,7 +157,7 @@ static const VMStateDescription vmstate_pic_ltim = { .minimum_version_id = 1, .needed = ltim_state_needed, .fields = (const VMStateField[]) { - VMSTATE_UINT8(ltim, PICCommonState), + VMSTATE_UINT8(ltim, I8259CommonState), VMSTATE_END_OF_LIST() } }; @@ -169,22 +169,22 @@ static const VMStateDescription vmstate_pic_common = { .pre_save = pic_dispatch_pre_save, .post_load = pic_dispatch_post_load, .fields = (const VMStateField[]) { - VMSTATE_UINT8(last_irr, PICCommonState), - VMSTATE_UINT8(irr, PICCommonState), - VMSTATE_UINT8(imr, PICCommonState), - VMSTATE_UINT8(isr, PICCommonState), - VMSTATE_UINT8(priority_add, PICCommonState), - VMSTATE_UINT8(irq_base, PICCommonState), - VMSTATE_UINT8(read_reg_select, PICCommonState), - VMSTATE_UINT8(poll, PICCommonState), - VMSTATE_UINT8(special_mask, PICCommonState), - VMSTATE_UINT8(init_state, PICCommonState), - VMSTATE_UINT8(auto_eoi, PICCommonState), - VMSTATE_UINT8(rotate_on_auto_eoi, PICCommonState), - VMSTATE_UINT8(special_fully_nested_mode, PICCommonState), - VMSTATE_UINT8(init4, PICCommonState), - VMSTATE_UINT8(single_mode, PICCommonState), - VMSTATE_UINT8(elcr, PICCommonState), + VMSTATE_UINT8(last_irr, I8259CommonState), + VMSTATE_UINT8(irr, I8259CommonState), + VMSTATE_UINT8(imr, I8259CommonState), + VMSTATE_UINT8(isr, I8259CommonState), + VMSTATE_UINT8(priority_add, I8259CommonState), + VMSTATE_UINT8(irq_base, I8259CommonState), + VMSTATE_UINT8(read_reg_select, I8259CommonState), + VMSTATE_UINT8(poll, I8259CommonState), + VMSTATE_UINT8(special_mask, I8259CommonState), + VMSTATE_UINT8(init_state, I8259CommonState), + VMSTATE_UINT8(auto_eoi, I8259CommonState), + VMSTATE_UINT8(rotate_on_auto_eoi, I8259CommonState), + VMSTATE_UINT8(special_fully_nested_mode, I8259CommonState), + VMSTATE_UINT8(init4, I8259CommonState), + VMSTATE_UINT8(single_mode, I8259CommonState), + VMSTATE_UINT8(elcr, I8259CommonState), VMSTATE_END_OF_LIST() }, .subsections = (const VMStateDescription * const []) { @@ -194,10 +194,10 @@ static const VMStateDescription vmstate_pic_common = { }; static const Property pic_properties_common[] = { - DEFINE_PROP_UINT32("iobase", PICCommonState, iobase, -1), - DEFINE_PROP_UINT32("elcr_addr", PICCommonState, elcr_addr, -1), - DEFINE_PROP_UINT8("elcr_mask", PICCommonState, elcr_mask, -1), - DEFINE_PROP_BIT("master", PICCommonState, master, 0, false), + DEFINE_PROP_UINT32("iobase", I8259CommonState, iobase, -1), + DEFINE_PROP_UINT32("elcr_addr", I8259CommonState, elcr_addr, -1), + DEFINE_PROP_UINT8("elcr_mask", I8259CommonState, elcr_mask, -1), + DEFINE_PROP_BIT("master", I8259CommonState, master, 0, false), }; static void pic_common_class_init(ObjectClass *klass, const void *data) @@ -222,7 +222,7 @@ static void pic_common_class_init(ObjectClass *klass, const void *data) static const TypeInfo pic_common_type = { .name = TYPE_I8259_COMMON, .parent = TYPE_ISA_DEVICE, - .instance_size = sizeof(PICCommonState), + .instance_size = sizeof(I8259CommonState), .class_size = sizeof(PICCommonClass), .class_init = pic_common_class_init, .abstract = true, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422581.1647956 (Exim 4.92) (envelope-from ) id 1x6n8T-0003PK-6y; Wed, 16 Sep 2026 10:45:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422581.1647956; Wed, 16 Sep 2026 10:45:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8T-0003PD-3n; Wed, 16 Sep 2026 10:45:05 +0000 Received: by outflank-mailman (input) for mailman id 1422581; Wed, 16 Sep 2026 10:45:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8S-0003KK-0c for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8R-009uGc-Cx for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:03 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa732d-2eae-0a2a0a5409dd-0a2a4506cbf2-6 for ; Wed, 16 Sep 2026 12:45:03 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa732d-195a-0a2a45060019-94a39744f828-3 for ; Wed, 16 Sep 2026 12:45:02 +0200 Received: from pps.filterd (m0127837.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8j54J700548; Wed, 16 Sep 2026 03:44:57 -0700 Received: from byapr05cu005.outbound.protection.outlook.com (mail-westusazon11020092.outbound.protection.outlook.com [52.101.85.92]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0ka9vx-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:44:57 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MW4PR02MB7380.namprd02.prod.outlook.com (2603:10b6:303:74::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 10:44:56 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:44:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=v0kaGrtHuAWW3BhosR58UAq4Y91huIt/VByeAJS2U co=; b=dse14ZTYUTLslaaYJwd1AdvlSIwpiyGZovETRTb94qD1ZfKjBAsUmM58p t2fn2D6OvQ6x8zYQSZc2AZS25EeOqQ9qkaHRbRNoIUil7jQoh/InpJXbhSr6dydW Jn/vftsoy7Hw/ziJ7Um8uBFTDvgYPkx1vabyX+AQ3picI8aoAdRnoCqoPjcJc9RJ K1VAC94Kw4OXOXIUHWEG1ZM1Z5YEjMtn9bC1er+dRxe8NVfCt629OFo+G65Gid2p y1ROGUpSTUNfT/zWGZzkYmB+KKkoo45qh4MpUN23cmnBncoPkyrgYL6pKbdcYu3z RznQCX8I0OiqmnKrdndF262cOW4CQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cOZHR7B0KZ10MZ5h7Hu45RrRKErR4xJDqbed9pBIujBoSW3sOqta92RcVPJ+MVZSjrlai5M71IPaVE9o7Np8gWy5+m1t0rUj0Zn33SwA92sKVfrouRWIqTYB5XmDoHkyu9eiBggwWm4k3AQcwNnpu4hy4O9q+yIp7US4Ua6a7H02zzBK8xaVwaWfk/Pw61CgyEH2xbl/q97+RQfGE0eKawNBVhzpNMO+47LlLkEDI2xa+SYc83b/EQ6atRC15ssgDpyxlPWfGir1VUrTBGVetN8gyb+g5GoTjGCOGMkbKYf/QFkWN0fT4G9c4Ad5KCbi6eiUIsmPWLegeXdjyUswVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v0kaGrtHuAWW3BhosR58UAq4Y91huIt/VByeAJS2Uco=; b=NQ54SL+D+qsPMEEKb82HxvlK6MX1lYOwS1wBg4V+7x4CABbKlE1g+tRLaxSiUrNZhmNnx0K4RWec5zVdJ4o2yw/mJWyBzdJsV1M3g/XlwIdgS0ISFFowp48iEns5zlSdDFiYCCnApTFr1IpX0RYjprmWtoyDPdPPwcrhWIu3JXWoi7dnwMSrmrEHS7N358kag2RDdidni58HVInmOr2F/lUB8MP3ndE9QQquFhhPL0337e3wnE472DDWl6LD64oEpe6xFZGqMMKx4qR9IBQwXycauJhnxtidnLspR3F2lhd/OeIZTxNgVTVfqINMu0ZoCKV7JOC83zsYD4mF5RNIoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v0kaGrtHuAWW3BhosR58UAq4Y91huIt/VByeAJS2Uco=; b=fm8ZRSb2cyR5AK1+NlVV8PivMgqzAvdhG9pvC0iCcBoZXXbKzSgxpB9kOb6t6hXxxx+6PVjsgDC6//HBQNGj7UFMHgLFmkogjTjI4R6hHWGLkYVhjc8RQczES1zF81WWE0MCzqnCBWwxd7M2WN0agabEScGNSIl7N21adMopsZZbmdJ7K1/88AnHhoaEpu8XFt33S6G+2/KgtsbcrApU/kwlCCQhxkeD8raeEky8LP8Lpns50cOYuGcBZQK6ZqnuTYMVeyQTNF4oCKAbTO6bKgWxWHzTcH4IsXAUZPhcOg9VVIFA6NUKf5tAt8gne3v/0WOc6qfo51+15mwvW6XTng== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 05/22] i8259.c: move parent_realize from PICClass to I8259CommonClass Date: Wed, 16 Sep 2026 11:43:33 +0100 Message-ID: <20260916104435.600211-6-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0205.namprd13.prod.outlook.com (2603:10b6:a03:2c3::30) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MW4PR02MB7380:EE_ X-MS-Office365-Filtering-Correlation-Id: d6fecace-1a57-44df-fb14-08df13df8c39 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|22082099003|10067099003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: 6XrZisVsJ2t8aDwyDz7LWugPmBd6G4B1BeuENS0ib6rXuq7GKZO8J9J6zIHC6uslGcsLZSpGdtuaSST2BrLHt9TysBKdgHtFg7WoxDRwehOWt26fIO98+esuL8gXrFHLM4dTx7PAqeejKUbEEvVk4XIqaZfi13BIUEB/J/qGvRl0N55zY/b5QP6tGro9sd7f9VQxoajL/Skidi1/+f6gYwdlaA6ivkO/ej8JAIm2nsC4rfU/ZL8noZi+m+77WFmFsHQiP61o8fXHj7ViqGKLqjd2JYqFcb6zvx4hEcTvcggl4CfuMrOwRkvsJVSJSl3cZscrtrtv0DNuEJN66Zonqm4IdttnW9sYyn4Zf94lK9TAosK4VoPQInORS6+oP4B+Jp5+DGzsdOfIh6Qq59H8yFbVCW5ftVAAA+SxyKqeXqXp9VnawjBQs99ArU6GE7yWjKNjb/Ynsna7gN+8YKg/a5l1hIBAIIA8s0bp32G6yM1h/dsMJF+Fa/MqsbTqrPsIzFCsFFxrQfUWqWC7wri8DRquH18drMpd46vDvBqWI7ei4Kpau0npCI5Vu8MwUv0T3Y3XYK65oB6LSxpf1bQ5f37if0zlpOqGjShlnqNjD9u4mErAAMysUWSXsrAsAhvh7lgdqVyEC+pFOX3j1sBbXrGoo3vtfVG+/FJEfCF6fCs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(22082099003)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Ws2oX42ZeYUHrXOtJ5se5MwjBoOUjxH2V/pu6fizyM/2kiK/1N1BN5HcayCk?= =?us-ascii?Q?3LyzfZD16sVuMlyErwUIKk0eNQ72VO1aAVD7Z53rMMHYGz2RzGdIJSvX35Eh?= =?us-ascii?Q?zGFWamTNfCuiRdx5fQUzgKS9AdXqHbFshFGZknLxeHWSyEqo5Le2x1BRJV5i?= =?us-ascii?Q?pau8cvoBcRRlwVmtz9kHEVM5DrEWHt32Y/Qxqc0BqwmBf/J4XUvAWPrmh9Vr?= =?us-ascii?Q?Pvtu0L3Azegu4FhYRR9afL1rjA8bT2cJ2MoLfuLxFQp0s29Xu8dH8Uivj5Id?= =?us-ascii?Q?3VcbTTmOrlYv+cRerBmNifeMoOwjO9IOIE410Q1IknAREmLk9whlWRCDc6GL?= =?us-ascii?Q?RPBfle8ZIgRMdLGdBI2WVmd8kvr0HnqbTaAk3M3rMmjmUwRS+WMmJTmOg1sb?= =?us-ascii?Q?HpnuL+TxtmxeFU324/l5qB/O4UXXPZJpHaIsJwRxq9J566dRULPNeCRvROqE?= =?us-ascii?Q?HuuDv/kn921/zihffHS2ZXpWb/TiZyyeU867RBgxUPgg3olQ2knXzpr3y6Tv?= =?us-ascii?Q?sYkRpIhQAouqgTDamYcoLHwHigpfo8sVg0HzLxDxblL5UFM/2pihjf0rp8TL?= =?us-ascii?Q?Ce3ztaLfUPkxCHVzC0gP3DGiP7XVD2DN/N/GRMtwxyyIvrsO7krbAhvFr4Vt?= =?us-ascii?Q?ppSybhB7qozc1aMQN/ag3q/XZV76po+C20O5HjA3b+8JchWof92Lzr2TsJhh?= =?us-ascii?Q?DvslmjuAGr2di8eGOrx6hXbyDZ2dq5Iz0/PrnkCT4zkVS3BAK3ts5+rQRHkq?= =?us-ascii?Q?Vjpsks9F7NgOvzskO+lJCRTOhMvjgcvSQSIEKgacVjP8oJ5CXQcmBz5zET1M?= =?us-ascii?Q?n6GVla5t6W1bG4xZ1p9jZZ9zNiFyl9bg68jAv1/KuBSqpfqZjXorsb6TM9CR?= =?us-ascii?Q?uo5teBQKrIj4ij3SRpbc8TL+QN/ow/R1+bK3Twcegqjp53VG2vx1ZLHNjA/v?= =?us-ascii?Q?2AoarONCnXS5/1ThzHrlRV0MVR6OXJijx9GPyYq8JKXBWdM/pHCzBZcD1UaA?= =?us-ascii?Q?nYOFr1o32EroojmFF9iM5Uz+g7IXIGaOUTKh49VJeddAMd7N/KOogXh/gMpo?= =?us-ascii?Q?XOVxDmu8ZvKlvObn/t3otSjM4K10rHBbjwaovd23bSqG3H1Ygw870Ds4B9TW?= =?us-ascii?Q?iNxxsXmd/XXldUN1jsdJ9I/VuQ1XDN4M1igiJQ4HgaPCsEZIJwUhA7OVynxI?= =?us-ascii?Q?qJ3BYUA//pTAQD0oeRqXX2pygTvIMKKUQ8QqK9+K3KA51ErARIfRzk7MrEgd?= =?us-ascii?Q?T9Gm/V/CwkJW+jAH6++zgDlczgS6zfvgybqqpFUurt8uLqg12FxlZiEsa7xB?= =?us-ascii?Q?ogNUfBGzfXvn58qEB0p9S5c/K5ujfgzconh8PQGmav0YQSWsBulg6KbSnGdr?= =?us-ascii?Q?7uxDaqsAK9KY0nyu0DVD6rr2MUOGevgfkjMqOpnAY6V3PNndc/cJvglZJINy?= =?us-ascii?Q?UAH4uCOygWbneKaHXU+SpkSLsK941r1yv09BXdH36+mTy8UKBEDj+PmT/dsp?= =?us-ascii?Q?GsUJPordlD1RP8YZPe/OTI2GOW52Prcwpr6qlmLqa2L6JC9EQaruFtOdlTwg?= =?us-ascii?Q?66UGoqu7lLK8ypuQHHKLX+PbOuMGs9TlvedtIAuYNBrnqLXF5V0l9Y6IYxiP?= =?us-ascii?Q?kPLjYlTd2Em18kJSZbRCMqnhkql5U50kEnkC81pJaY1ICfWr3RFjxGvG74/M?= =?us-ascii?Q?GU6Z1M/ul8CF7RRpjyi9CJycPEr6H4s3JvlOcYW+a7PmN1IGVSquVP25ZNSi?= =?us-ascii?Q?2XWXsdmoOGNqWfG7zk35DxHqsb64bDc=3D?= X-Exchange-RoutingPolicyChecked: qZqCFZo609+/6AAEK5jj4c5MtFYNF+p7zgH/aSytJnrlgV/f1shxLwq8f3D0T9EcZwtUBvZel6jeSxOinRlSVdyX0yLJmC0L9Z+Pipn0Q11sv4bpoK7lnR/cVXsAfHGEK10QQdrxsTS3wYiMZOVs8dmZ7OSUOEkdS4zShDoosVVmJpopqY45DODJNwtvISbNyEm6bdj86US4u1k7SpNsJx+XQVbRCywZiu8ufh5D8Ag0dIAvohDd0gZpaR48oPGmbzaXqhPgDNCgqsQv9EmvuzXpo0Xj22BAYsdYfJ3vQ7DWLKU6ZlUXtfeZkC+gc0lBvtd5j0aRrUek8haNamKZaQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6fecace-1a57-44df-fb14-08df13df8c39 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:44:56.3169 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: GCvl1ght25PaCEj9zR6R2GF/tWG9ndXTToP3OHyNObdTy0YHeK+pAl0RX7wXyy8WP0cT7/34n8+h89n2Hk2dGx4niDEG8SD8fb3TUAN2ygU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7380 X-Proofpoint-GUID: 6S3yKRD2RXniTedcURJuooGA0kiTLUxg X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX+fd2EWzCHdks UsyjeJCBtiIMuotuc2DI6cdp8NumtpdpryfYHgzy838au1MmsZqvpLIxg3GHnsWbU4grQU1iBM1 TVAd0bAe4onLW+CLpG1esk92On9Bl1k= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX1amkBnlD4tw8 QRnJvbvhnkPkcX3EN6upw8OuOu/IZmj7dNYcO6wJxx2/jCRb5KxFgAMcPv9sLaeixMJ6gadOy0W QesPP5XSve9qPDylAyeSM7ZKAPWx9s5ywCRjKur+zl3MgHOUBtXL6WQh8luMEYhKQq8lrUmTsjb 5zC7P6FjfUHuQEOJJS47On0bwVVbSm3Hpjo9BNXA3LOXZdUJur6UX03L1hsqedFuVy+XL/QEZmt aQ24zRlI6qclTyvQckbFAdgnbIGOK6pDq4vOf8fvYUeei3jyM6T+bhDmiVW4XWSDxg8uWIhW/RZ 4CeaMfwabFnIRhMv2MCzajUfXBUR9TBs2s2QxQgMrVjTZzgkyOX5F1evBnOo2Ejv1dbEhbscRy2 XmuQRMXb77sHhen+fe6mQ2yBUWrwOfF0fi8cNGO+dpcjOYaxBSwP2Ph35KANxmvPsr7eOqbHvQx 7dkDotVDQLaQkAJHXmw== X-Authority-Analysis: v=2.4 cv=P46vFSAu c=1 sm=1 tr=0 ts=6aaa7329 cx=c_pps a=rN54qV+o3v1qfa0lUeS+bg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=REJzgUj2r183NUftQ48A:9 X-Proofpoint-ORIG-GUID: 6S3yKRD2RXniTedcURJuooGA0kiTLUxg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-16d1c6/1789555503-F5E0E77B-7109FD4D/0/0 X-purgate-type: clean X-purgate-size: 3022 Both the emulated and KVM i8259 implementations store a reference to the parent_realize function in their respective classes. Start by moving parent_realize from PICClass to I8259CommonClass and removing PICClass since it is no longer required. Signed-off-by: Mark Cave-Ayland --- include/hw/isa/i8259_internal.h | 2 ++ hw/intc/i8259.c | 21 +++------------------ 2 files changed, 5 insertions(+), 18 deletions(-) diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index e039d6f067..e2b0b00f5b 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -37,6 +37,8 @@ OBJECT_DECLARE_TYPE(I8259CommonState, I8259CommonClass, I8259_COMMON) struct I8259CommonClass { DeviceClass parent_class; + DeviceRealize parent_realize; + void (*pre_save)(I8259CommonState *s); void (*post_load)(I8259CommonState *s); }; diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 547e86c5f4..131aaf9b04 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -35,19 +35,6 @@ /*#define DEBUG_IRQ_LATENCY*/ #define TYPE_I8259 "isa-i8259" -typedef struct PICClass PICClass; -DECLARE_CLASS_CHECKERS(PICClass, PIC, - TYPE_I8259) - -/** - * PICClass: - * @parent_realize: The parent's realizefn. - */ -struct PICClass { - I8259CommonClass parent_class; - - DeviceRealize parent_realize; -}; #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; @@ -388,7 +375,7 @@ static const MemoryRegionOps pic_elcr_ioport_ops = { static void pic_realize(DeviceState *dev, Error **errp) { I8259CommonState *s = I8259_COMMON(dev); - PICClass *pc = PIC_GET_CLASS(dev); + I8259CommonClass *k = I8259_COMMON_GET_CLASS(dev); memory_region_init_io(&s->base_io, OBJECT(s), &pic_base_ioport_ops, s, "pic", 2); @@ -398,7 +385,7 @@ static void pic_realize(DeviceState *dev, Error **errp) qdev_init_gpio_out(dev, s->int_out, ARRAY_SIZE(s->int_out)); qdev_init_gpio_in(dev, pic_set_irq, 8); - pc->parent_realize(dev, errp); + k->parent_realize(dev, errp); } qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) @@ -435,7 +422,7 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) static void i8259_class_init(ObjectClass *klass, const void *data) { - PICClass *k = PIC_CLASS(klass); + I8259CommonClass *k = I8259_COMMON_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_parent_realize(dc, pic_realize, &k->parent_realize); @@ -444,10 +431,8 @@ static void i8259_class_init(ObjectClass *klass, const void *data) static const TypeInfo i8259_info = { .name = TYPE_I8259, - .instance_size = sizeof(I8259CommonState), .parent = TYPE_I8259_COMMON, .class_init = i8259_class_init, - .class_size = sizeof(PICClass), }; static void pic_register_types(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422582.1647965 (Exim 4.92) (envelope-from ) id 1x6n8X-0003k8-En; Wed, 16 Sep 2026 10:45:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422582.1647965; Wed, 16 Sep 2026 10:45:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8X-0003js-BB; Wed, 16 Sep 2026 10:45:09 +0000 Received: by outflank-mailman (input) for mailman id 1422582; Wed, 16 Sep 2026 10:45:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8W-0003gE-6a for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8V-00Gz7F-1i for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:07 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa732c-8faa-0a2a0a5109dd-0a2a450cb4b8-20 for ; Wed, 16 Sep 2026 12:45:07 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7331-f479-0a2a450c0019-94a39b0c405c-3 for ; Wed, 16 Sep 2026 12:45:06 +0200 Received: from pps.filterd (m0127842.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G7x2ou3215142; Wed, 16 Sep 2026 03:45:01 -0700 Received: from bn1pr04cu002.outbound.protection.outlook.com (mail-eastus2azon11020125.outbound.protection.outlook.com [52.101.56.125]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqbt7a0e8-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:01 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by MW4PR02MB7380.namprd02.prod.outlook.com (2603:10b6:303:74::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 10:44:59 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:44:59 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=b4a1VVZQ1aZOauQn24XOWH2/qUfMYMvEynGh+kmjS lA=; b=y+/5AS/N2zk9y5fdI5wfAb97v8e+ELn7SYJ4vwpgoPnIzcczycY7gGvQs 3/pPrSOYGQqAVo0NuWwndRO0ngKhvmZ2qij80i5msmEYMoLbECD11K6thlRloJbN LpGzEi6qQzLhhXpYEcjB/z+nfUMgM5by7IQz+cP1GKJEdl76TigRAo93wvinqiPq y2mEA60afVjalh3ytcmCG6fcuDoh/jK9LHrSa6QqMW9dqskhoiLjL5JpGSe9PJSu tKNTiuCxIxWsNJD5BE6IlWKZURWxFH/VDu2VGRG8PlmL4Bx/GKWrRelStPBtumsU JPaStMkDUhzsPSU2fA33Dy1NiW8Kg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JVrSN/8qfPXU7fBMOlJLhPTSEqOqIZV6uFR0YaEk1v7DBKKvkWVp7Oppi4YzYyBXfT9I//iZE0OADALjnMuK9Yciho3Xe8uQ1OpFAUe9e6A1RAV8h4kX8X7slC4F1cUrC4pfzsBo1tBc5HToYlMpuICr/YJOVohWi0RGNPQglRuhWsONJfhXIuNWS0M/eQHKsqU8zkoL4ft+Gxyb3QKTz+EOqeq+blwkWV/kFXRVQC6WHGTUjs4be/u5KuuDR8TaZewMUvKGLJ2Z87KzCNUxYwElQXwtX99d4itct/z0gegpOn86y1caBxxsFn+689lXSVb9Il2zQrLg/AC7G57bww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=b4a1VVZQ1aZOauQn24XOWH2/qUfMYMvEynGh+kmjSlA=; b=XJmJEYb1XbNefDZHTOgbzcddC3unWyAYyPY7p9eF+eQJsuRGhhBX4eReBa23o5DHl2WOYt364AlgAmRkw9fZM+m35RsbuDG/stfkbpi/gUKdy91Bg/o5c72fbrPXXqsUIVhok0TYTfRVGJzIZ1gXazzrLAiDDtnMkGWU7EZ7Ho10kRTxD67KALL4gcNxV4nG18UBVMuTbaJCL9xvqqQjcnrtrm+EA8+MIXo5EmPM/ASP9h3PhUzllk3Xp0k/houNuWUVUH1tabDNdFLvjvO1T8p3H5NDuaZZSon+lnuC5WWkkMv95TtqAs1SJtzFEFEfWQvlhmGOOqBSFb6PBq3i1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b4a1VVZQ1aZOauQn24XOWH2/qUfMYMvEynGh+kmjSlA=; b=sNPeExw1tAdIH9+QfxnsDQ4DwtMJfvsIBb6qIjki+eUC11DGcFWZ4ni2qYOQQZ74ODNLKTsmf6+knzjL/fXJu0RCIyAsF0SFg3FpYcJ8YFnG9kFOJ1xIY8nZr/yNhLrM9n80WNNP1VDMlfMBvYSQX7Qrv808l7oWe61DR5q/xeX41BwVaKI4cfDTjoZpAJVtGkVmEWhk926rzF+I5bCoofEY9L1oANkclQ2oLv46unB1428lWfQM5r7IEJMWlgrFPqerXU4ih0mZyYvQZCNjO1enoOU05RW9j3ctyqlx/dMzj471cJQizFd/2yXQn4Zk28BBQ5rXJPcGGnUVNIqKNg== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 06/22] kvm/i8259.c: move parent_realize from KVMPICClass to I8259CommonClass Date: Wed, 16 Sep 2026 11:43:34 +0100 Message-ID: <20260916104435.600211-7-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0252.namprd03.prod.outlook.com (2603:10b6:a03:3a0::17) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|MW4PR02MB7380:EE_ X-MS-Office365-Filtering-Correlation-Id: e108a641-3265-48fb-48b8-08df13df8e4d x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|22082099003|10067099003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: JiKH92oK2ZnSvZA2C36llbjqvWUHpdy/5Tlkt2075BxWtew+XOBkirf9oXYeXeYJRO0xu+QaHwLbeT9LKOqzkmNdXMA9EXzj8hD8xuZ64fIuH5Xu5Hlts0waUtr6Ny7Oj+P05heEfnHCH4Q2BQigKyGyOcvQ03/39qUUG3i6Axd1IZBvCq8QBZEwQ2VMmq8yLXzQkgj/3WJLXqZvEOfYO+Zu3QeBui/qjb5+u1ySzMxixF+bw0IKUiEHrsVAC9vYMIOqll6eKCYtUS9FKTFduPWJMBnOmM2ojy3UrHRRCUgVmcW3iR4lPmzaYetrCqDm6sfv4PkHq0NpuMnWvbjQsvph+3ktyv+2zmAPE8u2bVJYsWWjIDB9LXIXWyzk4YDVKgFykhb4SVXx57sXeXbfGSCRx8WkWFl66dRjIGzRqSG/Hf28G0bm4ZU1zcAfLG5YqyMSbUeJEHV5VWEkrmaE57x7Mb52zPba3IkIh6tmkD95flvMJJIzMRjnFJ4aM3JJHd1CjN8cmcq52MjkZqBwaVLYcakC/f3NWB8LiJczxotfw4QI4/H1/rLXAjAT9t1dunfui5HXIBqiyP/B+69N/7THFEl3rv/RbOJj14OQeXCErGWVm4eFu2bgLsyLFR0UgsqFd2oo9tpd2T7tgFPQS72zbAE3OkzT7lB7/hyLF5M= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(22082099003)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zPPLT7lKRItLPOrDAIBZqd3XWcAmH3wHY6dyeVzBLM3/P7u8Bcx0TrdgsEed?= =?us-ascii?Q?M2tjS1mTcT6hwCjQoD+I1dLT+uQc57zLmlBI6T29w+flFRIScvOTVs9s0yFq?= =?us-ascii?Q?Ld3MEUD9jl7unsaN3QHcfMwcR6sB7akL5TvFSNuhzkuZW3MQQzLKDeRJQCWf?= =?us-ascii?Q?tduU4HdpIjlf9vzszOEHI0eWriKCH40v/5HxSPhM/xMGbSUngMdmQpiH9reC?= =?us-ascii?Q?CNR5Ug/RczUwF4zbc7bzMD9JQWfhODHh3MBYdtmuSQyqyNpbRTQ41o/dsoXW?= =?us-ascii?Q?qlpAolxrDKBnpV2qvVm38aRbT48hM3u0wZwYPxmdKh8kQNgaKie6bvwAn7JC?= =?us-ascii?Q?DGzIdY8C4YXs/JL6Zv8JGUt6HOcfTx5mu2Jd4mVh5+7skzeNLqGcfqJjjn7F?= =?us-ascii?Q?Ge1vRl2oC0dz3BC1mDPW7qKW2RC/LGZKAQzXIW2H+KcOHyeq8TI93hon7qSj?= =?us-ascii?Q?NqFfRl2Abn8/d1pCmCLBUs4ZhPZoKLicsbD9WB4cM95EAcbgVI7be1MTTNn6?= =?us-ascii?Q?ocrPBgJ+m+aei7ygKecX6FRrHpVysT+FtTJlruwrZXBfV9B08l0CzCTUo9Wb?= =?us-ascii?Q?dIng8Q8wPwpRtg1DFWo+i/bD7Xnud6HuiL1Biaw4U/qlE+e2u1NO775OG3rc?= =?us-ascii?Q?kRqYFR2Fc+qcdOa5/4qlVYHMoCo0wsjj443hPGUlfK4J0R0yipDcDMMvep8s?= =?us-ascii?Q?fTov7gMVVnr1nUy5pMSTUw8qBdl8g+CVKIcjc6diUgTFkWbSVjsUc/cfBCgZ?= =?us-ascii?Q?WoXArF/DoNvtdh03u4yC4/K2eYcseh8wkJ+/m0N7Sr7N/zLuyAcHOV0qijyt?= =?us-ascii?Q?BSLRq3b0CTlqj1ufYN9DErY717b2/sdDPieM+Hn7W5XTnp8LHIBvCKGs4Y5M?= =?us-ascii?Q?po/R/5ZZazCZ7l53u12+dajHDTui5eoimRrTI8cBFo8zRKOyxsbGB9VQzfTp?= =?us-ascii?Q?MRQHc+c8tOpWQUiXMTfEO3z24Scm8cWR/J4JKIDkLLgIcXhtwerniKd3P1/S?= =?us-ascii?Q?foORxOmVw5hDe++ArAHVaecvrDrYAeGRgUyYY0AGFLPV0cGmPkjcxncK93gJ?= =?us-ascii?Q?czPY1A/f8qx2qIqg4GZrMAgVIFio98vev7UEZlohL9UMEUSY7sL9FGyZ47Q1?= =?us-ascii?Q?jvFtxn1/8vftfVnonXI0Ofq2img95C2JX+yADYK4ixiuuAzA8MjYyaQG+ue8?= =?us-ascii?Q?K1lbrXOqV+4Gz7WHRztdB+7H4hLuEhWmn80fGetZKRcpOKcTOKayZDUqHRkA?= =?us-ascii?Q?ETINou+l4KdlMjMHz4tnt1ZgjLtKM6Jh9iJPVJnP52iMEXeaDhAHERAiXzGr?= =?us-ascii?Q?Konxe8a2m6WlLMt5PmXCGKHbqdYiGoXbtslcK1vhbPP42KiPzOVDLB0Ly0zH?= =?us-ascii?Q?yNqd+sQtHK6j3WYnk1XzcvRyjkjX9dcqtZ/fopJU+XXryUrEehpSIyrYR2Me?= =?us-ascii?Q?knM+8UQNWZ6iWeZXrffGO8z9s/P1QlRcNT6UyDmsX5Xaw2M79JYjX/g5OlD5?= =?us-ascii?Q?aBA7zf9PFUKFC0/Sy8YIRHFWrMEs7SE9S4FbS6h8eqLpimDIYDiZtcVHxAMk?= =?us-ascii?Q?aNAA3uK7fHkamHKKkOrd4UHrNmGfraUK0A79yRbH43DjwtwW/W0RFoIhg2QQ?= =?us-ascii?Q?dLE6DXkgpl/ccpBzc5Mpk8VKpRvz7Sv5Tza0uTTnMuf4iX41y4e1nfTrSVqS?= =?us-ascii?Q?+pYPaapwo6LZmUXTguLEx6oIpstk+BmD9sH2eh/klSTXZgM0y8371tiRsl6b?= =?us-ascii?Q?174Tr6MgZnWtv4Vs5RAay/F3zjPFqZ4=3D?= X-Exchange-RoutingPolicyChecked: UbL2DofvExxBA5nP2qQWuCNHhJJ3/cceT9t7VlbFNhr5TnlccQeB/FqX/G3iJ3JpKrSjUyzk4lQuQ/9zg1DjrZOQQ5MnE/3KGtxIvGrShI0x98Si2ddcyXw4T12j+x1yEpzoYxr7dyYho0hUe7F4qPYr644hWp2zw2j9ZY9oojy109S2FVnDyhEJQzxeGExmFTceYHKaa6G6D6D1+y+R9A54+z7jDxKnJjv8Iw5jdZmxjjPuAOgQxs2ts5Vhz3Gihi5TF6v1kJ4/xeIPNFx8Lv7VPv4/iIsyJ9yQuJbyAg0IbYwGjf5sVWMpx7UDoFtm2becNGl3Tf6IFx8CuV97Ww== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e108a641-3265-48fb-48b8-08df13df8e4d X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:44:59.6645 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: uiieCWXnTHntT4i2VSTPG3vfEsPGdlT5+h+L8d7yW/A6N06OLQm9dIWtaN1MNLmJCbw7hen27r0ChvG3tExPXzH+h+Lhjv7ztQc2/hAi/FE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR02MB7380 X-Authority-Analysis: v=2.4 cv=d+pgWhjE c=1 sm=1 tr=0 ts=6aaa732d cx=c_pps a=qoAvcrxUHY3FHMzwJxUv3w==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=VUi8bpU7OL1Oj2-RSIOF:22 a=64Cc0HZtAAAA:8 a=JoGAwIMGT5QChKfUXAUA:9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX7V5uxCAVch/A FB9NntY0sY7NiMCrVuy9asnh832qZCQ/k2D/k2AW58C3PjbuNkRLmLngGrgaMALSaTF1bvb15Af SrzWLe7sGT+DRHlrzycYNQOyt2vRtp4q5N5b65LjL65jId07QZNLr2RkStOQ9Z4vVxou3BzyQjl oJW1dr7/w83swce2VcdPRkrDiYk6eGFDpQNw64UStKazF51p8QRygpuchE0tvgC+w6LBNTi6AmU cv6xMkQ+xXu5FqXofGTAV5xhD9NZPp6UWiS3UEswDzBTz5EEf+wAWicniN9KnEWJQuquciS0fCl gPm7j3rQuJtg741i+SL0Njw88cDbujmVvhawoha30nYK2UO/8MbtfP6oBBeiPlqp+iMBCF67yDV raFVw8Qn1o2Ax+S23KCpcelTpBSFI0nDDqjIcTY9c660EjaqSmxb6Oai3XqAq9keuaE364brpqu 5tqjKzKzBWYNxQq2BKA== X-Proofpoint-ORIG-GUID: LN-aDWzHnMxDCbWYLG6YZL1HgNvVKXCH X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX4YCkNzbTRQeM dbXql7nub+BF83MsqbvArBUT8J4K8R7EC3LCm0UGU+HbdBRS8gEnM9WalX5/F/ezOIU6Z967Dov jUZCb2SS5LwvGc3tFNhZazx7de85xgQ= X-Proofpoint-GUID: LN-aDWzHnMxDCbWYLG6YZL1HgNvVKXCH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d25034/1789555506-018C5A5B-2AFCF907/0/0 X-purgate-type: clean X-purgate-size: 2462 Move parent_realize from KVMPICClass to I8259CommonClass and remove KVMPICClass since it is no longer required. Signed-off-by: Mark Cave-Ayland --- hw/i386/kvm/i8259.c | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 68607d721d..bcfed11a3a 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -20,19 +20,6 @@ #include "qom/object.h" #define TYPE_KVM_I8259 "kvm-i8259" -typedef struct KVMPICClass KVMPICClass; -DECLARE_CLASS_CHECKERS(KVMPICClass, KVM_PIC, - TYPE_KVM_I8259) - -/** - * KVMPICClass: - * @parent_realize: The parent's realizefn. - */ -struct KVMPICClass { - I8259CommonClass parent_class; - - DeviceRealize parent_realize; -}; static void kvm_pic_get(I8259CommonState *s) { @@ -123,12 +110,12 @@ static void kvm_pic_set_irq(void *opaque, int irq, int level) static void kvm_pic_realize(DeviceState *dev, Error **errp) { I8259CommonState *s = I8259_COMMON(dev); - KVMPICClass *kpc = KVM_PIC_GET_CLASS(dev); + I8259CommonClass *k = I8259_COMMON_GET_CLASS(dev); memory_region_init_io(&s->base_io, OBJECT(dev), NULL, NULL, "kvm-pic", 2); memory_region_init_io(&s->elcr_io, OBJECT(dev), NULL, NULL, "kvm-elcr", 1); - kpc->parent_realize(dev, errp); + k->parent_realize(dev, errp); } qemu_irq *kvm_i8259_init(ISABus *bus) @@ -141,12 +128,11 @@ qemu_irq *kvm_i8259_init(ISABus *bus) static void kvm_i8259_class_init(ObjectClass *klass, const void *data) { - KVMPICClass *kpc = KVM_PIC_CLASS(klass); I8259CommonClass *k = I8259_COMMON_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_legacy_reset(dc, kvm_pic_reset); - device_class_set_parent_realize(dc, kvm_pic_realize, &kpc->parent_realize); + device_class_set_parent_realize(dc, kvm_pic_realize, &k->parent_realize); k->pre_save = kvm_pic_get; k->post_load = kvm_pic_put; } @@ -154,9 +140,7 @@ static void kvm_i8259_class_init(ObjectClass *klass, const void *data) static const TypeInfo kvm_i8259_info = { .name = TYPE_KVM_I8259, .parent = TYPE_I8259_COMMON, - .instance_size = sizeof(I8259CommonState), .class_init = kvm_i8259_class_init, - .class_size = sizeof(KVMPICClass), }; static void kvm_pic_register_types(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422585.1647974 (Exim 4.92) (envelope-from ) id 1x6n8Z-000437-Um; Wed, 16 Sep 2026 10:45:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422585.1647974; Wed, 16 Sep 2026 10:45:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8Z-00042v-R1; Wed, 16 Sep 2026 10:45:11 +0000 Received: by outflank-mailman (input) for mailman id 1422585; Wed, 16 Sep 2026 10:45:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8Y-0003vZ-Fq for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8X-00Gz7F-S1 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:09 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7330-8faa-0a2a0a5109dd-0a2a4501db78-16 for ; Wed, 16 Sep 2026 12:45:09 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7334-5984-0a2a45010019-94a39b0c79e8-3 for ; Wed, 16 Sep 2026 12:45:09 +0200 Received: from pps.filterd (m0127844.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G7x6qC579616; Wed, 16 Sep 2026 03:45:05 -0700 Received: from ch5pr02cu005.outbound.protection.outlook.com (mail-northcentralusazon11022116.outbound.protection.outlook.com [40.107.200.116]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqbtb9yac-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:05 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:03 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:03 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=VGDCeduTgR2HUCuVX9bXOtAEkzXf6+m9yLeGk+5Fr i8=; b=V8DF21NKiAi4zMAehbr36+SVQSsenEC6bZQdEIdWjYq9akjE14ipNXVRh hxYRTKkYynKiFzp7CzGni7w0bAXRsTmwEdCjjVrKSHvN04mQhBCI8lb5YzJkHfgf E1bkbNMgseTlt7Dnr73coich9UZqeEP0OTPblcbj2a1fuOKFOK9mf/DJEGjB6dtY Iwxbw4EgRyv45QZVLQMXoAb7x8Yiijd9d7MUFKVq8YGCiXX0fwwy+QeUxb7lhfII +nvWtP3M1U/23vzbNlijek+IixzTWZ0ANV9PcaYqQLu3dS6yORx4Nm0uFuIWUvVb aixgAoW0nj3MDvNEP5Tjfz7WKnI+w== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Qkf3qoHTf1uYCMWPKn/7dEwabeJMIL84DzBmszzeq52iG2Tsbbq8RrhN0zEaK36edHiExhKiGKmHkX0+nBTUVz/AxtjwuuhcScOupEc/qjTb+cx5b38y66PwesaALfFjvb7svLHLI0EKPlABgBs3xZ8BHGT9mATnwlShQmXxXeT4+edm3jxQSt+h3DHpNUEyM/QqEMzQMATwCLGeuCoEC4fIdjQ+daTK+iVqttoowqEjVBwYmsZAyYU1hMApNCGWGV552mm7+xeTvfTwGz0AwYExQaV8RPR3I0onvilrnuGE+joueMvQXWJ7iXZaFWFzoGVUZoGlHBcPmNJA2kwqJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VGDCeduTgR2HUCuVX9bXOtAEkzXf6+m9yLeGk+5Fri8=; b=FlPNxqKbSHpP+ECI5znJr/uX14A0i2zeTs3jxziaMJL3lbriCPYtwN4pdySX2COR7bU17MOt4lA5dBHKYTyi9PzZatZHz9YZtbuqBmOU+9FQ7SyKTZA13r6YQh3ZykanInwbyKVWw/cWJNda3ShbxrqyfSzdJwTKEmpvnI6NoNTrpeOMFVNH+VTF4I8YyAkI39VHXOs+Y/Og2ly9m3q8EVa9+J/AwU1NuAXmA//7o+b35lK7UJZLvXYg7M6+eIGw5iV5SJKlkfD6gm40foXYeV8FfTU1wRjX1Ge/VTxiPtFR7QWs8/qh7b2lI9DzWDXVgYy9f7gVwbE7tBZ6/SwFnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VGDCeduTgR2HUCuVX9bXOtAEkzXf6+m9yLeGk+5Fri8=; b=h0MBpQsVoaayr9IABN3DQ5XMLKTKE2JoFvqkNhmNEkc0vXvC0hoBiP+pIdhEfE2QuCefZqKFxdfnfBZsdJ1Glvp52Lc7/m6S4SK3on9ZJYNP11Eb7v5yx5SdtuJiByBzu3+qWDi+/c9XoeFniTvmiU6JNIqKqx1sjNH2Wkf8fvupB/BJEJ2tMQOhO+7PHynqBmO1JBrL6gMAuGAZ9XvDbVy4ysgnTgerYLa7RpleQCLbXBtTfR/R67cK2HPLWKYTubLK9Fi8wAnPnPuKEu21nBeOSqlKS2pJN4iX9tx/6oLHuTKwlBKtcMySmosTJIquduAc0w0Xeqv2afX/eSYHLQ== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 07/22] i8259_common.c: use i8259/i8259_common prefix for functions Date: Wed, 16 Sep 2026 11:43:35 +0100 Message-ID: <20260916104435.600211-8-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ2P221CA0014.NAMP221.PROD.OUTLOOK.COM (2603:10b6:a03:5db::9) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 4146b6d7-058d-4c5a-1d2f-08df13df9056 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: E5xM66L2oDgB8wvZ+4HEIRdGsSbN0BUCrz5ut2H8axVqyvIdSv1NDJgjAMcVlsPCXxPUigtCy4GqYkHN36PyQ4FoYVn8vmtyupqT/TGE8gaNCvd0A9pGp//kjgMOfC4JqAYPYDpL6pXEgN8O/5gU3gd59ZK4DI4ez7RnBShEVHanjdgFZ51eWlwslwD8hpDBD+FG2ukErHVxPfHskLIkaNy5xxNP+EqI2W2ChysmZC5v9OT5na3vehSFyBMKW4PEfaLkumxyhK11lfYv2V7O0qmy/bGRnKV8saDKwGoLQShjtjXnX41f9xf+5m0+fxc/Us9VjeTMmGs+dgCVNPuppn9jC7PmB2QsOSeJykr00euRQl5TG96Hdwl6AmbTQo293Y3aXgK1bvWJWjDYVfoZzO+Z2Zj8Xc72QVv9vu8/rKhRURPgW3wh68rH66hiAR5p2J0tpD2esIwB8rHj/gsDoq2gIOJbUQX4duWG/MY/zZqw+RJOUqkBKeHCUICzFm2t9+KxbVVyIJt5OdzWUriPWfVu2/ED7zNCWQRlTH7mfoJURw8GSllh9RfV/1nCiVuR3UPYec3qoT+OigX98vchzuNGQgl97rwKNvginQGPzS78PuBuZ1zgejG5Wg1mOjWCCdS0XykGizyjHV4wS049wmtFr50eshc8/ty2Oa3BQ6s= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?1IlOgYxR/ObmOBJp62O2rQ7nVpAlWy31BHH4tmbhF5YMBN7zB/4HWZ9JGEfw?= =?us-ascii?Q?kIaeDTTYY2mSIp7CiXsrRAfuL7zhdflnwWeTRy4bgX6CK+OGVawT84iAzqmW?= =?us-ascii?Q?mANNh5Usq9+d8dYchmTm0Jj4NrhvKvYUP/ldY1ecQ1UrZAJqz+VGAJBZRB+n?= =?us-ascii?Q?GN1U3Au1nVQdIIYTJxURpeZpZfQnqfQwbZnlKCGoNBr3AW+O4BbvErzCUUNK?= =?us-ascii?Q?WTNNBa3TaCf/A56B+05R/2SmaE/rO3s7EhtHaRNKvVBwsEODX9zYhWsY8pHX?= =?us-ascii?Q?0m/ovZRSv6ozsNV+vSxc8d4c3MBfHGA2TG3rNeOZmEG79898wOO62Ul7zfLN?= =?us-ascii?Q?QEELH0RFYsVizmdjoOtcvSC66d0MM8IJc9YR4h6wXGSIEOAVM+5ufJ4H+4hM?= =?us-ascii?Q?254EN7HzDqIySt9GXIOe/lRBbUADgHuvgZ2bjB0yoUnLAzNkdN0RPi2lMzJ/?= =?us-ascii?Q?wh7U+T00tW5RIITj1uGvoEFGVFRfVmBWXVqImYZA0BO8j4Z+5Zy5f9HtQZnF?= =?us-ascii?Q?CuzbvVyhrR5/pqtZei6stA1vSRcg2W0FA3ux5RGU1RJgH2R9+0XsHHFss2vB?= =?us-ascii?Q?hTMuk7dYJSvpSuInpj6WNwT8XYXuq80P1cs7VSgbm+fkch+62HFJPWdPx9BN?= =?us-ascii?Q?6kWeveGW5CpXfKGfCMxE/qGcBwN69sBLMsg2hqH4MD97r7xSvevLwJkfLfzK?= =?us-ascii?Q?+NaysCYuwsh473gwRqVsSgBzdkAcjjoctEtccB/8+6mWAXSFJz21byOSjoES?= =?us-ascii?Q?cEuSTvLRuvWlt33QWRXlBKK7EyfdRzkvMgX1XF71tU9hxLMClT1mMSBDhzvM?= =?us-ascii?Q?Iu01KDRMNReAFoYhQRLJjCKJkV8BFs9y36QiFxq9s1wS7XoCJLp3gWVrUUbs?= =?us-ascii?Q?TCwGiy3/ZbvKFwpSULGcH1lPKf535jsesn7nidin/TN/CqNVNYSlXsBb00Ng?= =?us-ascii?Q?/mstHlEdLw+9/yyAtd03w5BqeTqMDvg24VQryjvYh/QQRUcds30niqzIocql?= =?us-ascii?Q?yVRhB2I/i7JtTPOFa8nNkAPSBw7y4TwSQK7DCYxQVlxTedFvOpKRD6TMGtHF?= =?us-ascii?Q?7BxelcmGcOIfH616uRMlAzMD1uiyCHOeJBONFaf3ZlPXFpO6HVSMd0z1OGob?= =?us-ascii?Q?PLiEkirTaVlXtxBL8dA2CA2NUXGtE350/CSz5l/pRbAacosd1klcKypOXyvJ?= =?us-ascii?Q?DKrN1osonbyF6M54ucsSCP4nqPF+426H+9OEeFR1YXEBx9c9+9xZC6Z6QECY?= =?us-ascii?Q?0COJa4H2YEFhIb6kYuKs+GHs6mfExu0znRul9E9q6pidesYuoKoJvH/kD248?= =?us-ascii?Q?c6Fy3GFz7/bja8GyIVpoXNxR0AT19wWQxAEC/x/4+saTgH9j6kyYJOW81FR7?= =?us-ascii?Q?nunLDa06MzJyXNn+xKcbzCu6dfB9/LXhXu+3g9OjkE5DmB+pm6JpfJZ5Gp72?= =?us-ascii?Q?vy/hInBqXSbTPq40/ezoHEJRly+UNSu8zYnfTImJZk3x+5tMetQNcSbGjQtp?= =?us-ascii?Q?LE5mMQvMyhrFH0pBWPG1RstTTditcuK9l1B46j0S3L3/PCJHQ2wEKCkdd9Vy?= =?us-ascii?Q?js2BdAetD60EM58brKALqg6rQlGHRvZF8jxpDJBQxKNfjh0iiQyaFzz3p5CI?= =?us-ascii?Q?FHDpPtiRZ2j2Ki9E6al3MQq8/zRxx3uzsmVGLGIfclaYFOoA6frinMkeg2uH?= =?us-ascii?Q?InemVceqbYQ656tasjv43kEETwfNM75jj71vZQppS3dBp5AvUe8Axqpl9D4w?= =?us-ascii?Q?akwo+/zFvNRUN4bk+BKoU2ccVraLP8o=3D?= X-Exchange-RoutingPolicyChecked: 5YRUKibA2hiJ9PqmmM9rwmMIpGc7DVXUyCIey9xs16rLt32d6/3QlAV+seMJHqA26x7ZdsJqIW0pcDH/1rWUbuqMncPynxAOflPSaXKdkbXURO1Ryubr2Bz3emJTaoWqan5twZ2VWpovu0UBdcM0TpULk++0p1oWqD278Dft1tvrBwGGEJ8fDbY8Lm+KhLEaZGHpcVIHxmj2/8ic6+JdKkS7fOAQNGBS1lnvk6UvZv6mPdMuRn1FwDnrZKoJ59rKle9pYlen++9Yih/VT/JKcfas184K9/jkOmKw56UFyFWdXxj8QMjFHMQSKi0hEG6I2qwDEKsAaU8jzwHT/40yOA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4146b6d7-058d-4c5a-1d2f-08df13df9056 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:03.2135 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FWhIlFW1/4jw0IWsdiuI4HJGUleFdTnVoBMFw+RP4dbJ4JOmGN90jCOxFwTUDE8EYUPYCeYu7qnOlJRbnOrn0l45e1pN5+R2Vn/KiDa7+pg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX1OOpLJspM3rC ndxqwP4IWOJ1PhSdnAXwNH8dhfW9tJuVX3BJW1YG+cKIaaHlWgHKCzSvetVr03jLvPjBDKlNUqU /1v1pa1NaGL73Pa8XXmzAJtaT2aO8rs= X-Proofpoint-ORIG-GUID: 1LoA-P8ySFLkkX0P8s6wptaZLc2Nrk2W X-Proofpoint-GUID: 1LoA-P8ySFLkkX0P8s6wptaZLc2Nrk2W X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX+F2H58qFmULN 7qbJqLAI2CDvmxwV6pb3LTvv4VSok55hW0l1hvp2aES72kQGi4FqKWP+6tIMdQ0tuW7iiSeqbcJ XprMAKnufDxkMRR9cbTU7T81QGfgGcXh9ufdsSv2BkqNJi+liaWT37LlCCI4zNNMyioQFrCWq+d StW5FAZrLDoY/kia6C5MAKK5Tjxm9znztG1eQs8hEkQvjSBLwGCw11KitTOY2hMcOpH3Bfab2vI JSr7klhj3Rp4i4rCOSaDL8GbN+Cn2p1HykAFsHBsfntCFgFLr7u3xsYubXl930BU1CbJVh9TwSk hbqMObjXCeKy/vgdrAq/1V98UrRZEJZ9U0c76JacAU0cjCiquxtiQ4ulR9UH1puStwJ5GqWkfMt dzPlei4Nw5GAMTXJfytLY70CwShovWNxxXxRBfxghpX8/NBMy5DmDdyj7S/utDc/+QsCqxcIpZG O3SwwxrcSKzNFTtlm1A== X-Authority-Analysis: v=2.4 cv=QYvzLcbv c=1 sm=1 tr=0 ts=6aaa7331 cx=c_pps a=iaCbk/XvQ83LTQeyZmlihA==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=ox8dIxdxdu1w5TD4ToMA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d62444/1789555509-BE27A757-ECE2AFFC/0/0 X-purgate-type: clean X-purgate-size: 8028 This ensures consistency with our normal QOM-based naming convention. Signed-off-by: Mark Cave-Ayland --- include/hw/isa/i8259_internal.h | 4 +-- hw/i386/kvm/i8259.c | 4 +-- hw/intc/i8259.c | 4 +-- hw/intc/i8259_common.c | 49 +++++++++++++++++---------------- 4 files changed, 31 insertions(+), 30 deletions(-) diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index e2b0b00f5b..282e437d25 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -72,8 +72,8 @@ struct I8259CommonState { MemoryRegion elcr_io; }; -void pic_reset_common(I8259CommonState *s); +void i8259_common_reset(I8259CommonState *s); ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master); -void pic_stat_update_irq(int irq, int level); +void i8259_stat_update_irq(int irq, int level); #endif /* QEMU_I8259_INTERNAL_H */ diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index bcfed11a3a..6c79907aaa 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -93,7 +93,7 @@ static void kvm_pic_reset(DeviceState *dev) I8259CommonState *s = I8259_COMMON(dev); s->elcr = 0; - pic_reset_common(s); + i8259_common_reset(s); kvm_pic_put(s); } @@ -102,7 +102,7 @@ static void kvm_pic_set_irq(void *opaque, int irq, int level) { int delivered; - pic_stat_update_irq(irq, level); + i8259_stat_update_irq(irq, level); delivered = kvm_set_irq(kvm_state, irq, level); kvm_report_irq_delivered(delivered); } diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 131aaf9b04..0f823f9824 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -109,7 +109,7 @@ static void pic_set_irq(void *opaque, int irq, int level) int irq_index = s->master ? irq : irq + 8; trace_pic_set_irq(s->master, irq, level); - pic_stat_update_irq(irq_index, level); + i8259_stat_update_irq(irq_index, level); #ifdef DEBUG_IRQ_LATENCY if (level) { @@ -199,7 +199,7 @@ int pic_read_irq(I8259CommonState *s) static void pic_init_reset(I8259CommonState *s) { - pic_reset_common(s); + i8259_common_reset(s); pic_update_irq(s); } diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index ac8dc7cf00..e03bbb9a8c 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -33,7 +33,7 @@ static int irq_level[16]; static uint64_t irq_count[16]; -void pic_reset_common(I8259CommonState *s) +void i8259_common_reset(I8259CommonState *s) { s->last_irr = 0; s->irr &= s->elcr; @@ -53,7 +53,7 @@ void pic_reset_common(I8259CommonState *s) /* Note: ELCR and LTIM are not reset */ } -static int pic_dispatch_pre_save(void *opaque) +static int i8259_common_dispatch_pre_save(void *opaque) { I8259CommonState *s = opaque; I8259CommonClass *info = I8259_COMMON_GET_CLASS(s); @@ -65,7 +65,7 @@ static int pic_dispatch_pre_save(void *opaque) return 0; } -static int pic_dispatch_post_load(void *opaque, int version_id) +static int i8259_common_dispatch_post_load(void *opaque, int version_id) { I8259CommonState *s = opaque; I8259CommonClass *info = I8259_COMMON_GET_CLASS(s); @@ -76,7 +76,7 @@ static int pic_dispatch_post_load(void *opaque, int version_id) return 0; } -static void pic_common_realize(DeviceState *dev, Error **errp) +static void i8259_common_realize(DeviceState *dev, Error **errp) { I8259CommonState *s = I8259_COMMON(dev); ISADevice *isa = ISA_DEVICE(dev); @@ -105,7 +105,7 @@ ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master) return isadev; } -void pic_stat_update_irq(int irq, int level) +void i8259_stat_update_irq(int irq, int level) { if (level != irq_level[irq]) { irq_level[irq] = level; @@ -115,8 +115,9 @@ void pic_stat_update_irq(int irq, int level) } } -static bool pic_get_statistics(InterruptStatsProvider *obj, - uint64_t **irq_counts, unsigned int *nb_irqs) +static bool i8259_common_get_statistics(InterruptStatsProvider *obj, + uint64_t **irq_counts, + unsigned int *nb_irqs) { I8259CommonState *s = I8259_COMMON(obj); @@ -131,11 +132,11 @@ static bool pic_get_statistics(InterruptStatsProvider *obj, return true; } -static void pic_print_info(InterruptStatsProvider *obj, GString *buf) +static void i8259_common_print_info(InterruptStatsProvider *obj, GString *buf) { I8259CommonState *s = I8259_COMMON(obj); - pic_dispatch_pre_save(s); + i8259_common_dispatch_pre_save(s); g_string_append_printf(buf, "pic%d: irr=%02x imr=%02x isr=%02x hprio=%d " "irq_base=%02x rr_sel=%d elcr=%02x fnm=%d\n", s->master ? 0 : 1, s->irr, s->imr, s->isr, @@ -162,12 +163,12 @@ static const VMStateDescription vmstate_pic_ltim = { } }; -static const VMStateDescription vmstate_pic_common = { +static const VMStateDescription vmstate_i8259_common = { .name = "i8259", .version_id = 1, .minimum_version_id = 1, - .pre_save = pic_dispatch_pre_save, - .post_load = pic_dispatch_post_load, + .pre_save = i8259_common_dispatch_pre_save, + .post_load = i8259_common_dispatch_post_load, .fields = (const VMStateField[]) { VMSTATE_UINT8(last_irr, I8259CommonState), VMSTATE_UINT8(irr, I8259CommonState), @@ -193,21 +194,21 @@ static const VMStateDescription vmstate_pic_common = { } }; -static const Property pic_properties_common[] = { +static const Property i8259_common_properties[] = { DEFINE_PROP_UINT32("iobase", I8259CommonState, iobase, -1), DEFINE_PROP_UINT32("elcr_addr", I8259CommonState, elcr_addr, -1), DEFINE_PROP_UINT8("elcr_mask", I8259CommonState, elcr_mask, -1), DEFINE_PROP_BIT("master", I8259CommonState, master, 0, false), }; -static void pic_common_class_init(ObjectClass *klass, const void *data) +static void i8259_common_class_init(ObjectClass *klass, const void *data) { DeviceClass *dc = DEVICE_CLASS(klass); InterruptStatsProviderClass *ic = INTERRUPT_STATS_PROVIDER_CLASS(klass); - dc->vmsd = &vmstate_pic_common; - device_class_set_props(dc, pic_properties_common); - dc->realize = pic_common_realize; + dc->vmsd = &vmstate_i8259_common; + device_class_set_props(dc, i8259_common_properties); + dc->realize = i8259_common_realize; /* * Reason: unlike ordinary ISA devices, the PICs need additional * wiring: its IRQ input lines are set up by board code, and the @@ -215,16 +216,16 @@ static void pic_common_class_init(ObjectClass *klass, const void *data) * code. */ dc->user_creatable = false; - ic->get_statistics = pic_get_statistics; - ic->print_info = pic_print_info; + ic->get_statistics = i8259_common_get_statistics; + ic->print_info = i8259_common_print_info; } -static const TypeInfo pic_common_type = { +static const TypeInfo i8259_common_type = { .name = TYPE_I8259_COMMON, .parent = TYPE_ISA_DEVICE, .instance_size = sizeof(I8259CommonState), .class_size = sizeof(I8259CommonClass), - .class_init = pic_common_class_init, + .class_init = i8259_common_class_init, .abstract = true, .interfaces = (const InterfaceInfo[]) { { TYPE_INTERRUPT_STATS_PROVIDER }, @@ -232,9 +233,9 @@ static const TypeInfo pic_common_type = { }, }; -static void pic_common_register_types(void) +static void i8259_common_register_types(void) { - type_register_static(&pic_common_type); + type_register_static(&i8259_common_type); } -type_init(pic_common_register_types) +type_init(i8259_common_register_types) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422591.1647983 (Exim 4.92) (envelope-from ) id 1x6n8f-0004VJ-8f; Wed, 16 Sep 2026 10:45:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422591.1647983; Wed, 16 Sep 2026 10:45:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8f-0004V5-4C; Wed, 16 Sep 2026 10:45:17 +0000 Received: by outflank-mailman (input) for mailman id 1422591; Wed, 16 Sep 2026 10:45:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8e-0004St-DT for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8d-002G7R-Px for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:15 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa733b-e002-0a2a0a5209dd-0a2a4506b20c-2 for ; Wed, 16 Sep 2026 12:45:15 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa733a-195a-0a2a45060019-94a39744c98e-3 for ; Wed, 16 Sep 2026 12:45:15 +0200 Received: from pps.filterd (m0127840.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G83uAV353108; Wed, 16 Sep 2026 03:45:10 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021110.outbound.protection.outlook.com [40.93.194.110]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gq9drte5n-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:09 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:06 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:06 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=rqR4OCxXqweOsL/Jai/0JNZHCvy6zRsE6FKKgK6aI jY=; b=H0kEaFEAk0x7mAXoWd6tNILZjvshdU9zZNf3G0EmkYPl2SUvBN/9aHhe6 f9QqX7HYjp79po2IF+6cgQO7e9pYp5vp/wKOhk1//rqDRnMtLM8/zGplVKxzt0U+ 4J7niN1uwSe6fjRh9iIEMh4IzpXV9+cflNlO01AIr4ju7zujJck5yCfeYZ+BU3e/ KPV4R56lbxxmaIVP54hxvjF3alMC4ExD8H2wbuCPTFkBUrDrdwcjHc18bWp9ML3z vpwPTxxD2K4YISOPRZIhqziVF7LqN182HYMjsphglDIJSjBgc8IIEOmFi//JWhaW Q+ekL0KJhUWr7xDjFrdtstiwXVrsw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kTa+P3NbkbGcSQVfHFiBBmzGHTE4TbgzPEiEAfspzTqnYKbS7tlPLYHywt1oKlpjXhtvUUK1UCYQ5ofKMSmfClgRJnvhj2zWRSFeJV8dtKnluATOKH6tR/R/VbWMBbZy4Lm3piFrbcYzir0M6vYvKXciLh9LLcw84YxweKAcUm/cCpJxI1crKMcWeBKJ8hOmGdEm6UpX9pgCVhscRpWEkXkDDgrn91cKSGg6Od+wJjouFDE8LD2O/V0FBr3sVXK8ca0DRDLG8P+Ow6/y5UsnlmW2RNOjureKhdNUT+KaLjOLGiDyFuSiblfPZ2+xE5eHeCtj2Ux3WZDyw0b64o75fA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rqR4OCxXqweOsL/Jai/0JNZHCvy6zRsE6FKKgK6aIjY=; b=v436zD+6gmFY3AlR0Easw+y+nQDH/rD0YxprzFKXWZnAitPAtmMBSCqowUIGACBGuhlckABFT8+kFKHdPVuPN0nd6fRrhKQCsMv2aCGBhv60u+j4l+LYaObSszH4XlN6KCoojswqpiNvnMcjixbPkwLqgE4BFD93hffI8uCH1ZIlQeDpvVNUifBGkeQ99flpBmHqOlinA6EgWxVeXTX0ncrxgPjoOn4sljcboczRb8XAZXiAtu3zoJOLDb26xTwVNmLB6hXPqRFJGNWGOOY0+SoL9qixUQ2RlEWLMtbMzQmB9ukYmE0XXTaHyPlEJq4upzKskdIOK2k3ib/cUtyKkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rqR4OCxXqweOsL/Jai/0JNZHCvy6zRsE6FKKgK6aIjY=; b=MeViRYOai88j4s90fB9SIlPLROpBc4cgsxWi0V2lJ0Aa/3k2RcOi9E3SycAcGQz/UbcrBOts754tqcIB7wCtRShxF4KjyOuKYjPDpNyP0HoiRZeF5+gKv8mfBEvc8/9p2/119qiSNsk1niHPDo+f4xf40ulhzIrAo9qDCTkMBtFlbIspQGwraV3zMr5a5127Gh/+PJE+7WNghhA4DYL1+iaPYFN3OKL5TLxjcVfiBK78DEzGqyxLILwcwKEIZs0jkGxVpXTCeHdSYmEM9P6cUyikVdHaqWGc2JN80pnrU9czcf9h9lxA3VfWKPTL/LfI4E8eAuv5eFROFiZroymcbw== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 08/22] i8259.c: use i8259 prefix for functions Date: Wed, 16 Sep 2026 11:43:36 +0100 Message-ID: <20260916104435.600211-9-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0098.namprd13.prod.outlook.com (2603:10b6:a03:2c5::13) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 5269b4fb-f3a4-4e56-f155-08df13df925e x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|3023799007|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: SXbMYsg9PDJTvWMSgZQzZCkvXjgTQ2+TLB0GhvRj+V6lHb/EmBlvF88+J7O6LC0olFrmnNJRUHvPDUa1oIhBMrPyg8AGlDRx2xFjug4DLUaOo2PWH53IB8BO2fYmPy0RsXYfjV4uvDNAe3O1PaakYeekjLGtc5cvoE5ItY0snjOJejNoiR+ebcXRwWf+cIzShQrQQM3cktPT9TZTBzdALUApnmtCEP5dxWM7VHbNBIKA7PrbYDfPlUXyQ50gx9xeGBCDgXcs0j1bf46EMLeTtQRgXnSjE1ZX0gRg8xyCgsqL7vKGGG+KhdR1vVd4zzQbPEGEFOl8YYhnDR2uPc34UlfIeNkIBaDcpL9VXxg09BtxvrKihlj3UFFzkPIezXzmjh+982ubGUt6Ct5EocB2adghobQpwO3G+a7M0mJB53Beisb/BcXtB5VZFoJxDG291NkUqt1cOVJNADj/vHivoTMaEkrGRspjqJ5qx6U8SKJyEMTt0bD3b25IjzkCMuzry2b1rVEcrRKs23BcvHRX5qX6IMaXZi8JqnbOGwzrmUX1RsjMC/Or0XnESkOx7GdNJSFNmnEwh9kmCrcNX4UzlUla1RVzaitzLphTCz0HQ3ChuQJ+yNWVMwnYPifO4ccpEVXyXUaCKDT6osfDXxHnncmjOP73hmfuwjBCeVIVUL8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(3023799007)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?P1Je7kpW/EvkbA5e7LlZ18HfjbEI6+lpILEQjUrTYR4C7EsLgQtSr6MOoQfA?= =?us-ascii?Q?idHi5b6lKEAUJKYlqUgaRBEbtBXoIahhb8VT217/4j/mOKaZjKaLGfvoDYU/?= =?us-ascii?Q?vLPYrQ5eSWk4Ldpvt92G6YvjLniq3VoOTPtF1YH3A9P2BH6pPvTMrfZy0HvD?= =?us-ascii?Q?f6LOo0d9hm0PQPGWiT0aNPoKwHQsnw5R5GHTmXrZr8g86Vp0+71H2Qysv9FK?= =?us-ascii?Q?5kzXqDU/SGATK1rOeWX7zMUDF9vOqFjzeSsObFiZYNaKCQRpa5vYO0gT+/1p?= =?us-ascii?Q?Aqlqr9aL1KQ6bYCgCvJCZ/DaOMmbnOPVljHqMEasVdZucoiqLKnlfBLS3CXs?= =?us-ascii?Q?cK3jGebr5BUJxBjGM/9T1FE2hAOVvT9BOPzJKjQqEofL/dIivLFEU1R2Ok5u?= =?us-ascii?Q?7nT0hHSTBiuiOKVRgG9OhF4l2Vy0YAAC5tHyDvlRLG1PzNXh3q1sCvpxJcRJ?= =?us-ascii?Q?zgi1nRbFjFnHKDMDZw5TBHTjziY1IUCcADFqDlsAUDvIz7pqijtUWmepMKJH?= =?us-ascii?Q?P/yVFLIdFN7BW2edaQFru/dVCf0acgZ5O9MzEbZgUAKRSXxqUu0Xz8nvfk+s?= =?us-ascii?Q?1VBtXn4nY1yhgSXZYGKCb4E+qlIATTS2kP2ZuHAQpBOk0MzclcRNIVGzMp+H?= =?us-ascii?Q?ruZAX81HquedrY/tcPqhggLKs1rNJLTb8N4LU621Q3b+7KZt4wH/2QBnM5mU?= =?us-ascii?Q?QLGjlooX3g6I6BhH1Q7Q4BDWi7a6cK5k2wWSjhzgLFTB10AEeirpo31T8hQw?= =?us-ascii?Q?vLugoblKCs2xw7jS3pbTAsNPp+eAcg5lJWa8IIBVqP4qZW1wjZscknWbX2cw?= =?us-ascii?Q?MJzeKA9v5+q0CheeT690etezrKiGPdwWERZSlioA84DLGqOEDvXfAvKKWTRa?= =?us-ascii?Q?dBjml10v+oZj1JQlma0cDwmAu2mxfZ0a4TIcUP196IgHNixXNOeOBi2kg6o2?= =?us-ascii?Q?79HMDIT1dusYtyhYgoDYoPF60XgpTYsL+SkwGL5hO7o5K6LWktbGoEkIa4X7?= =?us-ascii?Q?SoCI6fNzRshBtLnLHPrHDuGRensix/akXGK08Ytaf0oMYkBFF94W5TXCOPIr?= =?us-ascii?Q?L3+83z3rMpNhSiuWLi/RVO9ZAtj0rJSzjyTfLNFDLYtJsDZoI9aQO6Med0Qu?= =?us-ascii?Q?VWGYNJQKnF7ym/d7NkUnCNHBBWUziwxP4SdPSW6hnm/u9lCfotBZiEIX4AEx?= =?us-ascii?Q?4qgNKREWcCX0lA2fCPvLApNnKhbXzUPshRvKvnNtklq1EETVp7kKtRBhALaF?= =?us-ascii?Q?QIzcLBaf3nLrXV2GYDtB/ex1quYX62+k8WkXFYLISm9PqQTae6s1A0cNAdfY?= =?us-ascii?Q?trS8Xj8xuXc2qW1/O00geHp4J1g/bXcaQB0nq56IdfJITDdWub7r8MY9vl9V?= =?us-ascii?Q?FMlzdj0OvdjgT49hOA9F/nr294iB7LRxGWJ+rHI938f+GWjhh/uMYTyfAkfY?= =?us-ascii?Q?6jfINCCZ+YUhcHxx0GnP161J7DN8vKD6qgJtwR101bbc5TMMU2gF1U/3TpS3?= =?us-ascii?Q?fi/2EBT4BwCU/BbCBjo2EVDfg/yEdhgpECFjKsfaJPIzYq0LoJNvLE3WHNnJ?= =?us-ascii?Q?M7aBd/MP2STWP626BxOEg5bfCtF5bQLTGJPnD37GYJkQa4TWVhRiBigqN8C/?= =?us-ascii?Q?g7fBu/MuSuec+lPZRmILPoBr7xQveN6bdoCDvPrpPvl7+2Wv4xOQPxNoWKbl?= =?us-ascii?Q?Lb5ryQYd0GmTpMFGu25Eb30otf7mhukMno9hKRt1x7X+J9cq40t/2JyosgCY?= =?us-ascii?Q?hLSxuhJpM+ae8zfJzH8LyqM6aX8NLBg=3D?= X-Exchange-RoutingPolicyChecked: Cy4e4t7YytaJLNU/lWLKjarCPi/7bMQaBpUfm9LZSFU8Kz9o7sRLOVOi6QfIr6rL5OSok1BbwqY9147cne3A0wVJYftaMVQ6bIP59h98jP64o3gGjQwju4F4z61sCcCOgV/UPI2qY2IrC6C+NY+HeUaPT3390TPsl4Pel7Eh3pAZOYVFHiBIQ4BM7szTxmNDBdGPeAzlC6hbePHwFYHO/NjZnP7GzDNnIjS3n3u8jFLC0yuSE68js17KwFAR3PWyvk4aHCLZ0f4YWXpDS5blmX5ujAZP7L0SLZQMScgr1bfDBE5jbGMoWqoYC1E63Z53rAskEwFhw+JGBCDZr4XfEQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5269b4fb-f3a4-4e56-f155-08df13df925e X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:06.6799 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: JNvxgy2qQDgJT2Y4XeDnr6kOQYB1MEYjN1+V92FUi0rUqAHOYa2JinLQx+MWSUiEFP1eTJ1YI2RdO+TJyInslXpGI55FNE+VDbpuIsGE/04= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX82gp2FDuEBHv Qcsl7T+xAtQ+rY5vFovefwtSFR/hzq10ufPcduLb7/T/0Qrj4ROxb1OLjNOsirmc/nqOKQoXth0 kNPcUe+FNPkiv5xjzlHZunL9so9n+YCDb3iJXDRalDXqt1r/icHobVaKjuGBdKTwB7SzgQ1fmO2 dwokE06wAsjpeQvUXoHVDNCs4eTSJQRvUEzE3OIIcc48XgJbH2ebQjr3QbW1+FxJA+VQvayXSn6 kl8jNu8J3U4drObBYonq0H+3TWsL/uMhKC2Lj8HJ0M4sVCruwyzTybLsZXYoiTHjezjHejNX3QM fByXxQHB5sLNbHvlgnyF3pu6hMtZ6ISQuoanpfh+BeaKnnkVvNwpgCd3fIEorjp8UhOEqkDLwuW 8O58iUAmGHFNyxbJMzFCS+TqpPK+hgSH71yLNY4MOX63FRkR4CDFQFibr4VVER6JFcgxoPvuPC4 oC1bPExP0kDDDI50MzQ== X-Authority-Analysis: v=2.4 cv=XO2l2ghE c=1 sm=1 tr=0 ts=6aaa7335 cx=c_pps a=is1TPszdXRKtgCc8Qn4wPQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=64Cc0HZtAAAA:8 a=BS222h8BhpbHzx9SlcQA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXxWnwiWtsqE83 OYoNWSplpst/B0FCIEvDMBHcCGGiLgWzs5bo0mB5eH+c0t9+dko21ENL7DXw0oG70nIBSUmsqa6 goxqbtI37E9+GQkqU6ToYUxGAL9rjfw= X-Proofpoint-ORIG-GUID: FgC-zqXhrwH76hr1rGkCGWtBbHOJ5WVj X-Proofpoint-GUID: FgC-zqXhrwH76hr1rGkCGWtBbHOJ5WVj X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-16d1c6/1789555515-1ECC577B-C9F663C8/0/0 X-purgate-type: clean X-purgate-size: 9444 This ensures consistency with our normal QOM-based naming convention. Signed-off-by: Mark Cave-Ayland FIXME: rename trace events? --- hw/intc/i8259.c | 96 ++++++++++++++++++++++++------------------------- 1 file changed, 48 insertions(+), 48 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 0f823f9824..f2d8cb1489 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -58,8 +58,8 @@ static int get_priority(I8259CommonState *s, int mask) return priority; } -/* return the pic wanted interrupt. return -1 if none */ -static int pic_get_irq(I8259CommonState *s) +/* return the i8259 wanted interrupt. return -1 if none */ +static int i8259_get_irq(I8259CommonState *s) { int mask, cur_priority, priority; @@ -88,11 +88,11 @@ static int pic_get_irq(I8259CommonState *s) } /* Update INT output. Must be called every time the output may have changed. */ -static void pic_update_irq(I8259CommonState *s) +static void i8259_update_irq(I8259CommonState *s) { int irq; - irq = pic_get_irq(s); + irq = i8259_get_irq(s); if (irq >= 0) { trace_pic_update_irq(s->master, s->imr, s->irr, s->priority_add); qemu_irq_raise(s->int_out[0]); @@ -102,7 +102,7 @@ static void pic_update_irq(I8259CommonState *s) } /* set irq level. If an edge is detected, then the IRR is set to 1 */ -static void pic_set_irq(void *opaque, int irq, int level) +static void i8259_set_irq(void *opaque, int irq, int level) { I8259CommonState *s = opaque; int mask = 1 << irq; @@ -137,11 +137,11 @@ static void pic_set_irq(void *opaque, int irq, int level) s->last_irr &= ~mask; } } - pic_update_irq(s); + i8259_update_irq(s); } /* acknowledge interrupt 'irq' */ -static void pic_intack(I8259CommonState *s, int irq) +static void i8259_intack(I8259CommonState *s, int irq) { if (s->auto_eoi) { if (s->rotate_on_auto_eoi) { @@ -154,31 +154,31 @@ static void pic_intack(I8259CommonState *s, int irq) if (!s->ltim && !(s->elcr & (1 << irq))) { s->irr &= ~(1 << irq); } - pic_update_irq(s); + i8259_update_irq(s); } int pic_read_irq(I8259CommonState *s) { int irq, intno; - irq = pic_get_irq(s); + irq = i8259_get_irq(s); if (irq >= 0) { int irq2; if (irq == 2) { - irq2 = pic_get_irq(slave_pic); + irq2 = i8259_get_irq(slave_pic); if (irq2 >= 0) { - pic_intack(slave_pic, irq2); + i8259_intack(slave_pic, irq2); } else { /* spurious IRQ on slave controller */ irq2 = 7; } intno = slave_pic->irq_base + irq2; - pic_intack(s, irq); + i8259_intack(s, irq); irq = irq2 + 8; } else { intno = s->irq_base + irq; - pic_intack(s, irq); + i8259_intack(s, irq); } } else { /* spurious IRQ on host controller */ @@ -197,23 +197,23 @@ int pic_read_irq(I8259CommonState *s) return intno; } -static void pic_init_reset(I8259CommonState *s) +static void i8259_init_reset(I8259CommonState *s) { i8259_common_reset(s); - pic_update_irq(s); + i8259_update_irq(s); } -static void pic_reset(DeviceState *dev) +static void i8259_reset(DeviceState *dev) { I8259CommonState *s = I8259_COMMON(dev); s->elcr = 0; s->ltim = 0; - pic_init_reset(s); + i8259_init_reset(s); } -static void pic_ioport_write(void *opaque, hwaddr addr64, - uint64_t val64, unsigned size) +static void i8259_base_ioport_write(void *opaque, hwaddr addr64, + uint64_t val64, unsigned size) { I8259CommonState *s = opaque; uint32_t addr = addr64; @@ -224,7 +224,7 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, if (addr == 0) { if (val & 0x10) { - pic_init_reset(s); + i8259_init_reset(s); s->init_state = 1; s->init4 = val & 1; s->single_mode = val & 2; @@ -255,23 +255,23 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, if (cmd == 5) { s->priority_add = (irq + 1) & 7; } - pic_update_irq(s); + i8259_update_irq(s); } break; case 3: irq = val & 7; s->isr &= ~(1 << irq); - pic_update_irq(s); + i8259_update_irq(s); break; case 6: s->priority_add = (val + 1) & 7; - pic_update_irq(s); + i8259_update_irq(s); break; case 7: irq = val & 7; s->isr &= ~(1 << irq); s->priority_add = (irq + 1) & 7; - pic_update_irq(s); + i8259_update_irq(s); break; default: /* no operation */ @@ -283,7 +283,7 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, case 0: /* normal mode */ s->imr = val; - pic_update_irq(s); + i8259_update_irq(s); break; case 1: s->irq_base = val & 0xf8; @@ -305,16 +305,16 @@ static void pic_ioport_write(void *opaque, hwaddr addr64, } } -static uint64_t pic_ioport_read(void *opaque, hwaddr addr, - unsigned size) +static uint64_t i8259_base_ioport_read(void *opaque, hwaddr addr, + unsigned size) { I8259CommonState *s = opaque; int ret; if (s->poll) { - ret = pic_get_irq(s); + ret = i8259_get_irq(s); if (ret >= 0) { - pic_intack(s, ret); + i8259_intack(s, ret); ret |= 0x80; } else { ret = 0; @@ -337,53 +337,53 @@ static uint64_t pic_ioport_read(void *opaque, hwaddr addr, int pic_get_output(I8259CommonState *s) { - return (pic_get_irq(s) >= 0); + return (i8259_get_irq(s) >= 0); } -static void elcr_ioport_write(void *opaque, hwaddr addr, - uint64_t val, unsigned size) +static void i8259_elcr_ioport_write(void *opaque, hwaddr addr, + uint64_t val, unsigned size) { I8259CommonState *s = opaque; s->elcr = val & s->elcr_mask; } -static uint64_t elcr_ioport_read(void *opaque, hwaddr addr, - unsigned size) +static uint64_t i8259_elcr_ioport_read(void *opaque, hwaddr addr, + unsigned size) { I8259CommonState *s = opaque; return s->elcr; } -static const MemoryRegionOps pic_base_ioport_ops = { - .read = pic_ioport_read, - .write = pic_ioport_write, +static const MemoryRegionOps i8259_base_ioport_ops = { + .read = i8259_base_ioport_read, + .write = i8259_base_ioport_write, .impl = { .min_access_size = 1, .max_access_size = 1, }, }; -static const MemoryRegionOps pic_elcr_ioport_ops = { - .read = elcr_ioport_read, - .write = elcr_ioport_write, +static const MemoryRegionOps i8259_elcr_ioport_ops = { + .read = i8259_elcr_ioport_read, + .write = i8259_elcr_ioport_write, .impl = { .min_access_size = 1, .max_access_size = 1, }, }; -static void pic_realize(DeviceState *dev, Error **errp) +static void i8259_realize(DeviceState *dev, Error **errp) { I8259CommonState *s = I8259_COMMON(dev); I8259CommonClass *k = I8259_COMMON_GET_CLASS(dev); - memory_region_init_io(&s->base_io, OBJECT(s), &pic_base_ioport_ops, s, + memory_region_init_io(&s->base_io, OBJECT(s), &i8259_base_ioport_ops, s, "pic", 2); - memory_region_init_io(&s->elcr_io, OBJECT(s), &pic_elcr_ioport_ops, s, + memory_region_init_io(&s->elcr_io, OBJECT(s), &i8259_elcr_ioport_ops, s, "elcr", 1); qdev_init_gpio_out(dev, s->int_out, ARRAY_SIZE(s->int_out)); - qdev_init_gpio_in(dev, pic_set_irq, 8); + qdev_init_gpio_in(dev, i8259_set_irq, 8); k->parent_realize(dev, errp); } @@ -425,8 +425,8 @@ static void i8259_class_init(ObjectClass *klass, const void *data) I8259CommonClass *k = I8259_COMMON_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); - device_class_set_parent_realize(dc, pic_realize, &k->parent_realize); - device_class_set_legacy_reset(dc, pic_reset); + device_class_set_parent_realize(dc, i8259_realize, &k->parent_realize); + device_class_set_legacy_reset(dc, i8259_reset); } static const TypeInfo i8259_info = { @@ -435,9 +435,9 @@ static const TypeInfo i8259_info = { .class_init = i8259_class_init, }; -static void pic_register_types(void) +static void i8259_register_types(void) { type_register_static(&i8259_info); } -type_init(pic_register_types) +type_init(i8259_register_types) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422592.1647992 (Exim 4.92) (envelope-from ) id 1x6n8g-0004ng-Ll; Wed, 16 Sep 2026 10:45:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422592.1647992; Wed, 16 Sep 2026 10:45:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8g-0004mx-HX; Wed, 16 Sep 2026 10:45:18 +0000 Received: by outflank-mailman (input) for mailman id 1422592; Wed, 16 Sep 2026 10:45:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8f-0004V0-8w for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8e-002G7R-Ln for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:16 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa732b-e002-0a2a0a5209dd-0a2a45059d64-42 for ; Wed, 16 Sep 2026 12:45:16 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa733a-4cb1-0a2a45050019-94a397444cac-3 for ; Wed, 16 Sep 2026 12:45:16 +0200 Received: from pps.filterd (m0127838.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8eiYw769720; Wed, 16 Sep 2026 03:45:11 -0700 Received: from ph8pr06cu001.outbound.protection.outlook.com (mail-westus3azon11022142.outbound.protection.outlook.com [40.107.209.142]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqatdt57e-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:11 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:10 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=YYDEHb0n4ZArJUHD5DiG9aC24YVKRRvasL5SP6kR9 mY=; b=FPcZtlSoxuaRcpjIOgs0TtP0y00gkKRhOvQ1/1ufsnUSB/TvZFsUNquci A2iZ7qpwcC+NFFSnWiocotTXXBTGFuNnMCtcHTmjhvhYUiBBmsiiDWe4hDAWz9SF DEpb45BCxb0GUUh8NrsReZOn6Iodzz0rN86G+70/54qWNojvvmuxat1FP/c9W8hS lyyZ5nHDYOHRNyiZFliGiDxu7RKsxFhCYgpl72BEdAeDfwmB4O3rkjD0QwB27lg4 rUxqcXqt7kln/rIEKAS9+XCvAlOTKIrQrFXucqigso32ucFm8FmwYEeN3I0VwN+z hzm6I2i+ztVZf86jJWuOJd0IK4OsA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=O02g03XyahCaMLq2dW3ZvNDims63MSR9gkV5ZgbyhxIEdDazxFjffqCRRbLxwZKOHF+IOpJ9crrz4Y+8yTU620OSok04M5pIbX27FRYkxma5bgrsN1j81U2k5CMq/3vEHEKLBBmNyW0Aydnl40wtpHl54irNfFukMlYXuxYrPNvTjw/P+Yl593SvpBsOBPeXr+wuupdxDHinjHQ/pV8TXDy0EOoI67S8c18uXyjKGhaJhLyYyJW02/qxf+yY0G/3EoDAHKEuT+kfH9nOx5fkKrT8K2gZcYln3gZGNt76RpnnB9Q/KuokJAio1ki7lTA2biBZid86+k5Vka64LxjTlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YYDEHb0n4ZArJUHD5DiG9aC24YVKRRvasL5SP6kR9mY=; b=eefDZys6pr3HUbkI1LGQF2eTiuut8iAiVEb5e4whgdD0cApZ1AJRtjmM43FLvH6PItQ++fNcB4LsCpoyRzIXkX0nhpT6tiUhA2UEELlZPZrLCFEKd47gXS/PNyYkiF9qwdRihovN/70fG5ChtxlLGcmh3+rQAJrSTzSY5CKO61knXmU8NyX3KV9krOrmyabemfJObyLJEiugwc7eakctNPsBoLeR3OqjyqpeI1UQeLS9qpBp2/l4zd/kagB2rg4zeSA29fd2ubRG+sFPpftzejgGrGxUVR2dLuiR4Sqd2WijoMRHy+BYDHVr4TrEXMZtkNHA47vgzpUnqDTGvCSjsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YYDEHb0n4ZArJUHD5DiG9aC24YVKRRvasL5SP6kR9mY=; b=QkUunYrYv8rw/uM/p2z/z1xwQL6i6tSEAct0NKMFoLcaJwmusPZD/FWg+eRG1iMHxWVSb6nOEdxXJCx54FmkwoGXN096tVDS9FJsYRVV6mwXGurULXCf1JiExs4OEa40RjfynrVDizXQ8rMAn4uTMUTPmenyxwO+tsM4N1SpT2Crp+Of8jiHb+BHwhzsHf3/mfO/0IY1bj4UrPMKFYrE4BgcHNrLKE6kSPYPW0wR0A9Tu9DkByktzexmdLbGCuzHSMF0S59ChBLN8QRUa+tnDhyJIEaMaU8PwefK5vuRc8huN2i9htbaEq74Otd+/GVYy7oKucw2xjgGFavtUWtc+A== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 09/22] kvm/i8259.c: use kvm_i8259 prefix for functions Date: Wed, 16 Sep 2026 11:43:37 +0100 Message-ID: <20260916104435.600211-10-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR05CA0015.namprd05.prod.outlook.com (2603:10b6:a03:254::20) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: e53f911c-66cc-477b-ffb5-08df13df9485 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: uspjZd+TqpZfrDi+P88YVTHmXXBueMk92Zgkkm8Jun3CVOrez0PfNu6ARjlsej6zMd02GaQ/WnJJJvQegfgwr1Gj3Hs0F36h6maCe8O9nHtDlnQMjWWbhaVdBcgrEm6kVvd/M04IgcrP9ED9XyI+8GOYsGbqN7qV/afCqk5izDTePvJTNML6tqeewZdgcVu98y7xz7Skd8y1ZTiyUYPiQw5epnHInnrLuY1Bhf37fQ+10e910ODqX8ODWz0M6YQyJZd+LOwgoT8mArU/ZVL6saNU0B+FqeuTMDv0XwGcbQj6nI0ISIef5w57oiHeR/MMvkUDoSjTf+0Wkg9lvbeecO3OhOQdszxlhANH3wuHI9tbyh91CJhPO+4aheqYocRfWDl0rM9c3Qb8oX4HYJm2deV2n0edalvv8PwszMcNQz2QV3eNRVfc1sE4pP8y1olJ6atMrQagwLmJLuj+oaUTi3sCMZ1ceJePGUY8foYG7HGPmPtQNDxsJ2Zv9K5EOULVNDdNQGoWEcpDZkWi5UPXVTBTSRpBGIH2KhVzTkCc9PhJZpodoa9iPNDJGpJcP/uOCvlup8pVH0ubpK1r7/Elz4NeeevWymMyzCeWYdmiB6qyIM+HOx0E14OnCu7dTT4glJpG6gZBRxAjev/NNAM4UP5J7XTUbdqQWtQ3hkYTKyQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?UrViESBIOGc2G1j+3aaeHXamvjOHeysESpFHO30/xdSux06npIwfeVLpZIOm?= =?us-ascii?Q?vRcE8/oilNU4EeObRSIea11e+P+V5L37dc9N5IJF54yE2+9PnNxsR+Yo7OR/?= =?us-ascii?Q?XA8IAkgst8hIwGPhbNFAvGED55iYz5Yyqj2Y6cFm3aM+m5EOxIJN4/+akZwX?= =?us-ascii?Q?lQp4DYGl2FD8Vc7930U34nd/i9vr7WmwfJt8gEqooA35D3K8WK72cKz2KD3G?= =?us-ascii?Q?d/24Bd98qKMpu040laErd9Kcy7zjOqJ7q5cWlBd10ZJIgC+xaUWewIAC74dt?= =?us-ascii?Q?Ct9HL5YeLCfnXPMIYjibkoEzo5cVVO5r14pB7qQkM445nCwznnAZi9sxkxZK?= =?us-ascii?Q?fMr/1byJbz44G5ljbxxJRVqDRH34PJQWLG4L7axYNwDHS2WgTW+jzjTcT2hS?= =?us-ascii?Q?BGLitEsxV9pbMoXxe7JejMLhYpBNwa00ktG3OogfX9EfPfj20g+v/1y0rIQE?= =?us-ascii?Q?ntPNyxwckkglTzZ4bJ6YntTL/KIslz3Ev27NSzc38aI2inP1C1RYYJe55n2H?= =?us-ascii?Q?cVblgfyOmsN+TtKhn28Q0PfP25T8qoVmBncnxhuxC8ucUfuLdxOSKB48nU8Y?= =?us-ascii?Q?0Akn+ljHgFIKs4M1BDmimT8fFSi9t7NtYoFNGOh1PTktXsL9Kut3PT70HFO+?= =?us-ascii?Q?ielSvmqGNswmdHpeYOGsXxpfWv22sAWQrjA22+s5Pe3U3j496oeVImWMkwOj?= =?us-ascii?Q?jseOIS7hK+IHhe8FFljmSeKDyw0OlKfGODyEAVtLKVIKnYU8kPYPNk/2v91p?= =?us-ascii?Q?HtZuykix0tiR2RiqesC9mlyddsAJGqfE6jozoaHLqpllOAXygecP0+eVPUxi?= =?us-ascii?Q?kei9eIC8gjuUfwkOEDONzNpKLmwhWD6C2ydWzUXj/fUw/Kx35F1KuU6zkRJJ?= =?us-ascii?Q?hcT8lOW64ipmhuDKu45UYahAqMl5xdl2fAApgKTIdPceOCQLeTlZ6q52JBdS?= =?us-ascii?Q?Tpl+dTXE1FE84/hSKvt82EWTXjMDU5oLa77ND/qtAjl96iXQawAGhddmIG6A?= =?us-ascii?Q?PVUxy6wWt74TUKiiZ2NXiuTdqIhrBC/q0kfdNKg+wUiXhxE6dKRV8m7e//81?= =?us-ascii?Q?Apa2dD+/EczGVbZ+KeCwHsr2tJCp5jXJZgQIIWrzL0H6UK+FNys5QbAruibz?= =?us-ascii?Q?KsSHQZtF6P4Grwh76U3MxdIm6ULl5axsNa71hPOrLDQksEqC55U+C0DQEvOw?= =?us-ascii?Q?qJ2Hz3TjJz4XdD10zjl4yr6yVFNr9j5CL5huCKJo8t1b+WszcUxLDwqVNoLF?= =?us-ascii?Q?Gir+34VF8n3ovACmSu0dLyIwzzg6lJicKDg/uFqPbHW+FEglt3tMiCK22FCK?= =?us-ascii?Q?RuXNx3Mb6zl5I7Epe5R5wQWIQklvBhh0CGUeRV3uB5gEV2IbRp+Hvq7eer7D?= =?us-ascii?Q?MoqqL3E1XmS2rZKjHA/TFYP4/f08SfTjGHfDNCt3S33d1iqUnwbBqZQQ3IX1?= =?us-ascii?Q?L4ll2mK+3tHjsoqHH3/JX0nfGKN3ma+VW/CdBtbPUaKm5yM99M+tS7+Xu1re?= =?us-ascii?Q?c1ti9GduiRKdh30RpEBnxzMdkYsh3lRrlpZVKKFcTtKCwzBNkX2BdKn+j5VE?= =?us-ascii?Q?x1ikWEvYeCmlPioOqvCaOzFIZ/buXZPMsr0WN6Jsh5FD7yOjugrs5yWzumgM?= =?us-ascii?Q?fDgUY/6HG2AZQ0gWLNRgysHmANP1CKUsSz2q2ZhmrjUZEuXF9DhMrXJXYO+x?= =?us-ascii?Q?AeyFztOdw+SUkduK81EwPtTaxnywfApmEkakF2qaES0SmaUWLbmIra4q9vgz?= =?us-ascii?Q?GukDXRxo6kzb2O6V172QROWoaCWcBm0=3D?= X-Exchange-RoutingPolicyChecked: AHH32F8l9b+IL9t4X6TLHplogOJ6ijoggsP3OxrnBDE6W1ouVjao80PAMJMnwrbHID37RHDSMbPC0noaGRd3LuPnN+ojyZ7ofjDr8lWtoYHOou4Ww6/lzHkObiEP75PqVieBJo7Xd54LWBBgQIXbxaaJ4/ZRz2czVzxiddSeEdlFzw1mAApLQds8/e99izpXIDWao7Uc7vchfDztgbUtctXacRbT4Hah8R+m8SNvGZPvESuIl+SHMeenCD2bxsmseHh9gdg4ofITfH5iuRaynN/tjZVJFj+6dpp/PG5p33eEsGygrqhlGjHaUrnQoI61E8G2aipCHrkCTM7RvNWyYQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e53f911c-66cc-477b-ffb5-08df13df9485 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:10.3027 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AWlReVDpbF8MdOEIdhtaAufd8OAF/sWE0lgm85XeirSXeh26v8VPcdLQh+ALT2T1+CLunOIfifrSocwrlnCRBxVMsk+0LF7dqoaJt8A4Ouk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-ORIG-GUID: -LgbwupfRSQeycAqC9PLXcpxPNnu8If0 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX9aXO6XXv4Imv b4QNFMNJKrlWbzqzstjQY+t4MfxlPH45J8bv5JronZq1dS/17nbm0pBYlCb/sjTFFqRx4LzW9mp Nyj/bW5/3BukxZadbeujW/TDPk78BFo= X-Authority-Analysis: v=2.4 cv=IbsSymqa c=1 sm=1 tr=0 ts=6aaa7337 cx=c_pps a=0JIDn+9SpPUHitkVorI07Q==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=1L6crL_YRTbalZ11mEUO:22 a=64Cc0HZtAAAA:8 a=TUTnhI6DmTZhWknvEmIA:9 X-Proofpoint-GUID: -LgbwupfRSQeycAqC9PLXcpxPNnu8If0 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX9XNRIZAHGYDE KTFrRneWP5UdBzO8NG4kx5o2H3UTVZcOQfNPnisraPmj4QsexqyH1BBIegRQ7dFpEVwOeabVX1j /1WIvjW8UBoYXvzHqY/MR1FlRXkbCgWOeLiArNirl1jE3WrbnwRiKB9vJOLhzinktwuRlxtGp7z bMUagofS5uWQulwlug9yxUdxQw48IQvemA68ImasFWVGTqodZ1IWejyffTwDjWsWSsOo9BwfQU+ FboHAdJ4V9kR7BrK81Hzr+8xz35vGoqz1ETy9NPVEW8S4Luks1clH163PSMxwX4aZo3d3iN836C USdQDOK4LDH0FE5AqJs9C0E6xvr0hKImV10T2DkaY25TtaZJziwQNfSBuTcUUjCp0dSdy3bEPYK jv+X8HKIYJ8Gxb9M9zxXHakGI/sHsIStljPlBnLqX06FBEW0JH+Gp+gpNC9xtjAR9dX0749/0pe 8zagrjj2ksE9tuozy3w== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c201ff/1789555516-73EB92A1-06CF51E2/0/0 X-purgate-type: clean X-purgate-size: 2669 This ensures consistency with our normal QOM-based naming convention. Signed-off-by: Mark Cave-Ayland --- hw/i386/kvm/i8259.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 6c79907aaa..28e6e40bd2 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -21,7 +21,7 @@ #define TYPE_KVM_I8259 "kvm-i8259" -static void kvm_pic_get(I8259CommonState *s) +static void kvm_i8259_get(I8259CommonState *s) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; @@ -54,7 +54,7 @@ static void kvm_pic_get(I8259CommonState *s) s->elcr_mask = kpic->elcr_mask; } -static void kvm_pic_put(I8259CommonState *s) +static void kvm_i8259_put(I8259CommonState *s) { struct kvm_irqchip chip; struct kvm_pic_state *kpic; @@ -88,14 +88,14 @@ static void kvm_pic_put(I8259CommonState *s) } } -static void kvm_pic_reset(DeviceState *dev) +static void kvm_i8259_reset(DeviceState *dev) { I8259CommonState *s = I8259_COMMON(dev); s->elcr = 0; i8259_common_reset(s); - kvm_pic_put(s); + kvm_i8259_put(s); } static void kvm_pic_set_irq(void *opaque, int irq, int level) @@ -107,7 +107,7 @@ static void kvm_pic_set_irq(void *opaque, int irq, int level) kvm_report_irq_delivered(delivered); } -static void kvm_pic_realize(DeviceState *dev, Error **errp) +static void kvm_i8259_realize(DeviceState *dev, Error **errp) { I8259CommonState *s = I8259_COMMON(dev); I8259CommonClass *k = I8259_COMMON_GET_CLASS(dev); @@ -131,10 +131,10 @@ static void kvm_i8259_class_init(ObjectClass *klass, const void *data) I8259CommonClass *k = I8259_COMMON_CLASS(klass); DeviceClass *dc = DEVICE_CLASS(klass); - device_class_set_legacy_reset(dc, kvm_pic_reset); - device_class_set_parent_realize(dc, kvm_pic_realize, &k->parent_realize); - k->pre_save = kvm_pic_get; - k->post_load = kvm_pic_put; + device_class_set_legacy_reset(dc, kvm_i8259_reset); + device_class_set_parent_realize(dc, kvm_i8259_realize, &k->parent_realize); + k->pre_save = kvm_i8259_get; + k->post_load = kvm_i8259_put; } static const TypeInfo kvm_i8259_info = { @@ -143,9 +143,9 @@ static const TypeInfo kvm_i8259_info = { .class_init = kvm_i8259_class_init, }; -static void kvm_pic_register_types(void) +static void kvm_i8259_register_types(void) { type_register_static(&kvm_i8259_info); } -type_init(kvm_pic_register_types) +type_init(kvm_i8259_register_types) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422595.1648001 (Exim 4.92) (envelope-from ) id 1x6n8l-0005I1-2k; Wed, 16 Sep 2026 10:45:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422595.1648001; Wed, 16 Sep 2026 10:45:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8k-0005He-Sa; Wed, 16 Sep 2026 10:45:22 +0000 Received: by outflank-mailman (input) for mailman id 1422595; Wed, 16 Sep 2026 10:45:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8i-00056z-Ui for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8i-009uMQ-B1 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:20 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7333-bab6-0a2a0a5309dd-0a2a4502b36e-26 for ; Wed, 16 Sep 2026 12:45:20 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa733f-6ca4-0a2a45020019-94a39b0c1600-3 for ; Wed, 16 Sep 2026 12:45:20 +0200 Received: from pps.filterd (m0127843.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8P5He767662; Wed, 16 Sep 2026 03:45:15 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021107.outbound.protection.outlook.com [40.107.208.107]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqdhm9r5r-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:15 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:14 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=X2tdt+OFRJu3/CyARXQCgURgSsSHaKXcsV/f/DeQL C0=; b=FJppL52EIWlx1gPC8DqzjanmQIgsEPl9hlX3JwrrSN+nZZpBuKjLN0rtZ v/AMwbYWOgeTcuS7NniskUEf5CjwxWtMfPxNEUPnZ+dY9F+3oXCVAPY1/hd6hvP8 96lZPPPS4a2kTf9IKv3sPSlP5twGoerKxoPJ5JMNLadZR0fue7f78PyAnceVgEqd dO7vLbzynpi0aNobRDPRjQFwsAfCp0w361JiI5U393JhGS0E3Y6AtVAznRc3wdeQ Zn4KTYBGCACuDccgBIvV31PJ39Qg1VMVGMvaizQ2l/BEiItWjC6uRa+4yxckuHL5 u9fgag4WPveWjZuW/l3jYgYUmSQwg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NQO/vaaCAqSpCRa5TMHFZf3YKzFNFehxiKbdPwxjBTbLl/V/cFc+/Qx0bJwrYJyJJmiOW31ZOkwoCkXNA1+FM7TKR9FG5CbLSCH+WCKuMvJmC0QrOeTQ2MDy+dI0HOb/ij0dLYaKD4rZH7dROW5b49nY+Q7ORU8clIh8Np94OssZOJskatSnfunTvzftfynHeVLsN3WQi/IeH+Tkw7M2o/RSZyZQS7wvaJdAf1heywv9vC4fWbpNdUO6HfYLv/vABSfRgtd1kyTErSJKtRbT0Zr+vm38Rx74UA6GLqju+rw6OCtJxiKHv8GrTDkSb7rqgGO6gMkJk1l0VGoV8te3rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=X2tdt+OFRJu3/CyARXQCgURgSsSHaKXcsV/f/DeQLC0=; b=cQaKTYEhGgOZ1SqIq+WdWBq6mKADQf7ao/hmCduzmj/PsJ1j0ehKOKxiEFNG7F+/EQ2zJ+/ceu796+WdMdp7dmCWzIWOV20v7zwydRTXrdqVS5BGwDkExO/5ljQMrik5AK9Fs55KqJGFMhRGuSIEZT52g9ntWWpC1H5CjgXplyz3d17aJx7yG2JQMrc1R6aM3kka7axN3H33nSUR6JoMb5JG/BbgBjVoWZxfGyCzp9yNGTk+kQidLpUn30t4/tJnySVZDY4tXPYIkz6+OGXI+wY27YF6McPT9lPCgWosCML+O+XePibmdBqvDQsmR65dHt18+zrQzHVrrXMPXcPy7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X2tdt+OFRJu3/CyARXQCgURgSsSHaKXcsV/f/DeQLC0=; b=uoFqTH1U5oXo5A1RSkyi/QlT2h2AqcKvfaXUP7k29HmoIkh47IsbUuD7wfkdh4txW7qrV1CDfiU/2fQDEZZ7zSRbmVztN1DeCK+ZDPu/TC5d75uOp8GRwqAgivEz8RbfJPsWJDLkgzKGo+ICG5+mgh0rJUp5qJwOG9J02AyEww2RnjMHCIy1iBGOnitjv6mMDcSUBT6l0J7BFPHQaxzEC7gs46BpCRVmg3og4m2hjumG3wirZZeVqUscOv4EPIkQVwxvbQznzhxpHZ077hhL0uzIND5+QGMd5ZGx72UvR3A9TSXovbmZjrRTeHBgf49zljU6Orv+OUHQYemvVjVOEg== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 10/22] i8259_common.c: convert to use DEFINE_TYPES() macro Date: Wed, 16 Sep 2026 11:43:38 +0100 Message-ID: <20260916104435.600211-11-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR03CA0003.namprd03.prod.outlook.com (2603:10b6:a03:39a::8) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 9f611f48-a192-4198-e6ba-08df13df9720 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: R0FmaNe43d6KeEPyWoMoYIszH/snIJx9M/Csyg8m0MaXtyT49xiWYhxgkuwT9aWYixham5jSf7PEytPe+9Wa5Vs1zxV6ZAvvB3nJmoC8MC29D0c48zozGPtFRGcNibAxZijhcOeCe6l5mrHXVgHicFlDkT1XsveWPKl6RrpOJx6mKjOqax5kd176mDD6Z4qclcpIgylDZ5O3nV7kRTTVEbJ6fFN3CXk17RH1FLDsdYMhCOg7Ly8GdPzTOalX1i10z490u7Vz5+XvA+JTTatTBwRuvSg3n2QWJ5KAMCVbiLUCevbibZizZUKb/4uUDXtYen06UlteFR7PLW09IrudestWJZ1cMhbsEvNbAmjw2XGJUKVUeJaL7fFuExn3Npe7WLuV++bT/B/ves2zk+wpE7xBOZpzHWJVyHC61bGbFvsZ7ADMCaHJAqNpZINWuThm7v81XsI4JSRxf8RmrFUoLUq0iqx1gKo/T3kqwm93acbunD8Zkj/CN9AOAn/kJHIV/3nMPD1pwG81m97Flm9xrgUpzBlEVQq+zQO9mmYQakTxK9qUruG71k4GjBfAiW52FJCEdCT/nUQ8hUaqmF77bUEJeuTFj1UilZxrum+8TO9/gM0NvQuqr8HUs+lm5oqSnxQXalmIV6BBdgbO1EuJ8738aRHNCdGAnQOJUcAoIdM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?qUEfJ8oa7buYc7bX+Aq4HAea77L2DFzkyMM9xzxI3SE5VDGyAq7FgTvmPRXQ?= =?us-ascii?Q?bIIZOZyc87Sy67BenoKoub9hIb4Y83OCQOTTh6ufVWun3Rr5c3HMeJbH3MBN?= =?us-ascii?Q?zckjLyekwsLki7cHN2KsiMYk4b+4ZtgSR/bNFhfeAdoWH06o7QpwfdDeVdzf?= =?us-ascii?Q?ppSj1UQammdXqGM0IboqC78GGHMYVYavI5vmEDB+y3tMg6k2YPU0ZbTIN28B?= =?us-ascii?Q?6ycqDyOoHvGzxWaIXHWOO1lJb0M/t+fRovWwLJU2e3EIRHh3ekGyU0YAhbCH?= =?us-ascii?Q?lFkcEpQvg5q6XwJ46KxqWcPowndNw8d7Y9QZKyZDkbMi9v2GZVxZRnikLwuI?= =?us-ascii?Q?BCsyBucutoL9s+8rjmIwikB6aaOlJhjrCplfX6QJAjngzIc2EwojIK7CKo2b?= =?us-ascii?Q?95TwKu0xr6Hf+UkR7i7TKbMS0/E3cWS7cSup5qY/wDqV25EFtiZdek2MmBOu?= =?us-ascii?Q?ApFfubvsS6sokmL1hvrAWeGy/VZRhseQ0ylp4V0dIDdHPhZcrTwxh2E6ndMc?= =?us-ascii?Q?n9UMV9lDOJfT1Tl+yQzeqFNC7CdnqDdmpR1Y+PdzpvwWRALbhcHxNCO8ZUkx?= =?us-ascii?Q?CPzplAakFGoUcadVLcFs+6WeEHTbIh8BtlEh6qE+AX7SMWq4n55prwXReVIw?= =?us-ascii?Q?sfHM57WqKqrC9Z9GCk263x0cT04lxTXyRwYGSJtL/97BG/5JSkoEpI0qPfJd?= =?us-ascii?Q?NRAVnjfnyam3M5yh+P35YT++z8SQVoJI0p26RrPugNyfKmLna5JRLm+f7EV5?= =?us-ascii?Q?lA6dk8bZDnPsMt1xdi/FSJKJy6huHEQI3FEKh4aICaXqzYe7Cv2ZGJwz9FJ1?= =?us-ascii?Q?U3T4tPW33/yfvAmuR/qmaUAVrkBn6GrjZOaQCR0CY8oWdYcgjgYirLMcrBAF?= =?us-ascii?Q?m+aTo/1ifhPHCq1yAZRJvgChLF+26TyZEgs0ZI/Lgv7RjY3kxNKoe8TufVT7?= =?us-ascii?Q?PN0X0k4j6mbXEUGj2BRkDeAHY+BdJE964EztRz7Ecw+qe8B0T8clXkk7kPSO?= =?us-ascii?Q?xi37YaUVbRtqkuPLvR/t6FuKvbF81fEWJGyqtUrKR2lXDksx2mVTnK1i6i59?= =?us-ascii?Q?pzrvH7zS/rBJWcQ4msYqL7URyJmU/6NkHjFgdu/CXV8R028WUIRh8DjybPIF?= =?us-ascii?Q?HQevVFWzLaKoSV1ULhq108+R2s/dCwf6OPXzKWFkiLuZl5tzQO+uneHQ5/DA?= =?us-ascii?Q?CefOPfBGtlIUc77fByGYxVXbbMSvNC1sh3GEoWyHtihe7nVPpBLRYQsFTQaa?= =?us-ascii?Q?fQztoNmW1vzHY4Slt6+wgVj3As5bwta+18zJRtLpiZ+jhgw4D11BMBJPUmlY?= =?us-ascii?Q?JapW7x6Mb4JWYgl4ENAFWZaMpDB9NE8XJobBBe6lmj6CRX5loI4SqTce1lWd?= =?us-ascii?Q?zUPFxaHJoN8K88b4Kp0Md+LHIMSAUrxk7JNKRrlqCkjMOD2xmFFDhxCu8uJW?= =?us-ascii?Q?ml21pRnUnVGmUYe+jec2Y9gFx/NDFNlE8n8Wbf//M55EqvXwNIPka9tNLBxY?= =?us-ascii?Q?a6lP/4F+8fshQHJhjMmUM5FTWa4v7w/bbyIo+AJCkPXswuruNFstPphM5/6m?= =?us-ascii?Q?LsLg6kQFICmcWTMeX/33146/Kb7gh/8moTX9q4ayRA6IyGyyJLs6tNnXlDE6?= =?us-ascii?Q?Y9x4Guzr/ChUHxu9LTz7Eg2THp/5GkIehVm+YyupmkyJ0Qr/e7364op/8vv1?= =?us-ascii?Q?uGUnBuUcuRi25Jym0kIQAqLW+wOSChml0oLizDHVU0RmVvNon1pp77PBQj66?= =?us-ascii?Q?5J+/UHSWYebhCUfvYOeoZoqagQT4IlE=3D?= X-Exchange-RoutingPolicyChecked: LfgLXvB5EuUvkgLgq1kDx03FgihHEJ/2/XmuX+qaABZB02gWcNbr72HXt36B7ZMba7bnBqtx2MpKV0imENdrZfuYgPalKzpg849VTmUoASLLyJP/NnLZlwL+sLi6cZ/OuF++0tzXvp2p8GnvFL8ip4rRtA8TEljBzLqTqeqRpwNPW2Hy+yvsbsiDrdj2A8bs2WGu4F2BcS/MiL037qQi5LJ1KWzDs6XkSPyPP8Hr479hmX70/KbZKef7kRNi8qJM5QCjQzK9AWxAe2GWFApWwLldIa6RP2NMgiO0uPwjACyCHo3S0jhj3vgouC64d3tlDHx2RTFQeR+RLTADDKC43g== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f611f48-a192-4198-e6ba-08df13df9720 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:14.4800 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 2sjoA53h4b1DnOmHcSZW4k3XCzGj8Hah80RHfhBXxMunwbrLNlluxnfeFOMIQQOUP+UwoRI3dahr+2pquHFhXGJGjyinDRW5x3KUFgKVJl4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-GUID: RqA5faqyttuuwWO5UZprhGJV3WeZmooD X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXxLl8jwUk2/z6 TkpY4bnv6IvMjJxZnH7OtGieAKfLW3E5050ZyJqeKrBulpP5BzO7MXPtU++4PHvVU5dT72knMXa WEw5HvakiOs1Q8ovbXi94ZjrPOnR91Y= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX7ngutfmFB9nI NA3vlYrG7YyVXE7uvbh83FTbLKmYmzuIplzdIPVcDT9ozd4k3l68yz7p2GsNo1nWscumXB5hH2i 7Z2JT5ZdIMPMvN91LNmZuBeKcuOF/q5fMq7JoP1jYgrFDxfS5xIuU++jhFEchzdd+0vzvzASwdQ jgWe33YFZQK04AgrLi5j93ruECEiUFBbIZ4WGIiWMc49Ju57Vt3dkY6BXHh6uevLJj3tVq8Tw/I M6vx6dU+8WEZtF4lB2TKV7n/o6FXfBSK3WADWBcTKahbnIk0G/TnydmK3X16R/SMv/bU1hxbCM5 DX9L0ylZVTublXe3Jyoy2Uqa3CahVr5i+J4qLPjZuT4muZ1pMGjOmF9Ae5lNbhwDg++kOWkfkGe 02XRXsN87QgeiCu3ifl0ySUbaYi0LtG+GbtziQTDbtZrBleoNQopfXypAGm4vE4+DwA3KsNsD9m jKkX63SQGzPGh+Ad7pQ== X-Authority-Analysis: v=2.4 cv=IfkSymqa c=1 sm=1 tr=0 ts=6aaa733b cx=c_pps a=WvTO7h1a7pp8pZEQxufCPQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=bPck6Z4TT5Um9jj7BtEA:9 X-Proofpoint-ORIG-GUID: RqA5faqyttuuwWO5UZprhGJV3WeZmooD X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-720697/1789555520-303C42AC-3FCC8A15/0/0 X-purgate-type: clean X-purgate-size: 1540 Signed-off-by: Mark Cave-Ayland --- hw/intc/i8259_common.c | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index e03bbb9a8c..ec229a0b5d 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -220,22 +220,19 @@ static void i8259_common_class_init(ObjectClass *klass, const void *data) ic->print_info = i8259_common_print_info; } -static const TypeInfo i8259_common_type = { - .name = TYPE_I8259_COMMON, - .parent = TYPE_ISA_DEVICE, - .instance_size = sizeof(I8259CommonState), - .class_size = sizeof(I8259CommonClass), - .class_init = i8259_common_class_init, - .abstract = true, - .interfaces = (const InterfaceInfo[]) { - { TYPE_INTERRUPT_STATS_PROVIDER }, - { } +static const TypeInfo i8259_common_type_infos[] = { + { + .name = TYPE_I8259_COMMON, + .parent = TYPE_ISA_DEVICE, + .instance_size = sizeof(I8259CommonState), + .class_size = sizeof(I8259CommonClass), + .class_init = i8259_common_class_init, + .abstract = true, + .interfaces = (const InterfaceInfo[]) { + { TYPE_INTERRUPT_STATS_PROVIDER }, + { } + }, }, }; -static void i8259_common_register_types(void) -{ - type_register_static(&i8259_common_type); -} - -type_init(i8259_common_register_types) +DEFINE_TYPES(i8259_common_type_infos) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422600.1648010 (Exim 4.92) (envelope-from ) id 1x6n8p-0005jv-9N; Wed, 16 Sep 2026 10:45:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422600.1648010; Wed, 16 Sep 2026 10:45:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8p-0005jd-4p; Wed, 16 Sep 2026 10:45:27 +0000 Received: by outflank-mailman (input) for mailman id 1422600; Wed, 16 Sep 2026 10:45:25 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8m-0005cy-Rp for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8m-009uPu-8O for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:24 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7343-2eae-0a2a0a5409dd-0a2a45089568-2 for ; Wed, 16 Sep 2026 12:45:24 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7342-f659-0a2a45080019-94a39b0c8042-3 for ; Wed, 16 Sep 2026 12:45:23 +0200 Received: from pps.filterd (m0127844.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G81MRd579034; Wed, 16 Sep 2026 03:45:20 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021117.outbound.protection.outlook.com [40.107.208.117]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqbtb9yb3-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:19 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:18 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:18 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=iHuChNbu5rbXyA0PVs5s0TbcMgtzaERrjGU1D2vny 2c=; b=aPIChpv9SLgz6h9+7a/QT8YbBtPd7Yxpcu5TiJKB1SmzoGEE4w3XwTc3R E4olm4PAv5Zhown74IZCt0QaKyIncoZoLdTk3cVC4TtiyHsbx+jwf4JqEueQw9RE JmwVLZ0YGSF2hRDSQCgCI8PeteOw1UAZ4ejNDpEUvwYrOF0NaIXVrvkfCGa20mqV ueV4SbgAbGUP+CtUHfOqOCw1yjsFU4OXdBEnc4rsf1qyim9a7UrymDZETo4ar0X5 h408zfbAyhSB3/Gs/h063m7x4lrZRfcV4QLGweqNTXZAaVfO3bh6cCdes4eBjW6/ k/c9BDOXNnZXqwfO0fAaBpPFlYg4A== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NXoSynAj3pqOeFftRU4ugQUmLGxjxNcZ6WFS14d9HPhYyIyM67V48YEn8Y0HSDyxBUarz7SMi6SEdLKGoQ8wPuk6iKVQWA5L7QkpoKpX+tA0MuXesGCpeCd30wLwvrCHsqrmZBzuL5wtC/j/nMhA19/bZv4l3McoAIZJ5t9tlsNnwovpzmPyVdQ9qg+DbPxXKyZ1aZ0rdV7HtX1RQzd0AdyS3SmT7IsK6ofcNzoHG+OTafDscmZb3Z8fv1zsmlJ7rI6i7fLIvDlZkG9mtLN8B8Ywm/mJLtUf9LIWrVPjz26TzOTE0v278qW3NY5YkIXBFbtzmBnPgFBJZoBYz95+aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iHuChNbu5rbXyA0PVs5s0TbcMgtzaERrjGU1D2vny2c=; b=OCy3+9scQ85i+x+PnJFA7Dz7zJDE1cux9vdzV2W77SfVg778fLGCwuZBhj7Z96QvxOlpXmUKvxf812sEV6IWXPsKtFMkkGZuijNlWQK7qoAS53wy7rKgRqWF6eWI+jt/ogYL3KOKuqU22rW+edNKyljLwNbvQYQc2n7yVHspeUjdsybGtuosIQesTMZgMoE7XHIK64PVJJoNe/7VLCDmyrtjrXJ1vO90yoWkibV1WGssDg42qIZqTEmsMxoP7cTEPZWI7892btuq/cpCBGleLkId5e0mPuTLBlB9OlM7HDhngkeesdRZ8ayNW3pBIOTmF9ovIIzao3EYFF5LK3dEEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iHuChNbu5rbXyA0PVs5s0TbcMgtzaERrjGU1D2vny2c=; b=wicJ7Sb77IsjkASCtm9QGpVG8oBTm9x4k3Aucv2350gOm2AOf+w8787d5YVe3Eaw0aHDb2WQSsXyW5lnHPe79gSvRCs4FXr5AOA/7bQNf1VDmh3jmNRYjOF+HvYFj+0JCo1ei+/H6JHeVRDRcThdX54T9lruMJyklx0vzm9MnmIKFoDRccHCHWQ19cuI8OnYDPzXFzOKb4naejA9Q0DUGVQqiwGDqvkPrTgVUu8MHeqOLh++tp9kO2gPF5apjbIPtQNeTCmgKmmDB0qAowTH9+4v5aTzc/2nwEOkJ0srV5moDguqvhfbgqucFBGq8dqyrrS/B14ZRTVH/Z0ZVHPC1A== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 11/22] i8259.c: convert to use DEFINE_TYPES() macro Date: Wed, 16 Sep 2026 11:43:39 +0100 Message-ID: <20260916104435.600211-12-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0070.namprd05.prod.outlook.com (2603:10b6:a03:332::15) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 3b2d9d4c-b562-4545-e46c-08df13df9969 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: prJoDOR8yx1WBqIPyJNTXUB8ZLH+vqWeUJs5H6umAmMF5NcLWgXoUd8IKgvhTk1hiu78Zz0c7yRAPXcWX+QR0j9Hux/bA6kzmagFAj66GFwV5CRyvSQgX5+mjSpaSqz7ZAFSvl4znUvTTl2pFBh5w66GG0sK/lO4+zVHH+zaZ2qea+uOG7lINk33LFPLhOEvWF90MhRTjq/mXkz8OVZW9oyDVsZxWM0uiZClSawuXQDGsbiCDa1YaiRUZf6Mx3mlJuiPYB0VjnNPlBaZaC2frrtQ2DsQu/jMoL05j03I9rjPyPShEms7xjkRr5IPEN0z+DyqlDR1HHVOh7F7mAcDn3oSpmhVyzUmVkoPPkMxxA5So0B57vlAyeoMNrSF/xEjgpCcLc2p1Oj32Bf2lC45vNrIvstbjXyyuAS2QxKQLay5BZChk3LQFyrmtf0DptnJjcrF0knvFxvab8EiDE74EAnXQa3iC3NGqjXNbescEMKh2koNQsvN5hQvn1+Sk95VhWC4q6Ibl5NOyPQnT08d6zUdQyPPAXnW9/NgAAImisaru3mnTv8klhWIVJmmhS4tMxhgzi63dX441kEnx9/Mvo9QCuxUjA5ydU/1ukzGApqZ7sD8hxxaJ9h14EHq+jm9LM5o8vd+ZcifjZJWDb4KzxYJymhmfXwQ82GSmsgqixY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GZNsWJUOH8v3xYMC+xQ8yZ3aER1nnzwboLkmW9AEc5PLGE9FEN+UcUM2/qsv?= =?us-ascii?Q?wMf0rrGQ8ffzLyDS3U9RNUWonE/gPEyp65ZvMqppZq2YxtIxwvJZ9kcaL1fg?= =?us-ascii?Q?L2S3tK7qACONpR3uwGOX8T7OPRgRRMdUskO/I3E0QxKmnNxcgN4P6e55UtNZ?= =?us-ascii?Q?WNHJa6TFlsRhvXi/8dUk7B32sCtI6kjO7kjLv7RsHcK487whIlmGB/WukFdg?= =?us-ascii?Q?FPIAVxtGv+9iJFX912emTWfUu2DLWcUKkL9A3m31ioqfhpgx5wwVGwkPEGZn?= =?us-ascii?Q?r6HySyUDc8KHsKkfYOpwoQt0nx7TGb2xf0nS/f32MPvIumQPkSBmPLwjNRp/?= =?us-ascii?Q?HZSn08T6ps5oItCJwpnxOWyiSNSPx1x26hH0l0zQeApUboYacy6Mz19t3RaB?= =?us-ascii?Q?IW8Hn2Y7/64vy9gT/tj6/k0tL/8V1mliT7u10KSt1ok3mm/d+gvd78FxkqPK?= =?us-ascii?Q?Qly7tDlL7thv5vZEk7yVKLTIi7h2G/Pdu26QiAzsgvOGFaXPRRMe5jPdxbBs?= =?us-ascii?Q?tW5X9woG/XGY1MoZ2u5pXvHVDkmzO5cklYo0FuquyNRuwHGBFf7k7/NL/jQ8?= =?us-ascii?Q?f7YgGcVChhhmwz46GhHenh+JNfZl+SGc+Yjouj+0pqpE1n+9RMue+fg8KHyM?= =?us-ascii?Q?JJEtadptNOEJWRyp6aYa6Qzl2xIxQt25LR3pmbXzGCY7XsJUAquVcWKW1IOm?= =?us-ascii?Q?OaBr2BIvwvC4S2Zyjh1j8GKZleSymnXt5TkBh8dZH6VuDHC4t2sWx3GBQn7C?= =?us-ascii?Q?E/wVQo2E1lxKTIVjlDSFpYNTGOk82/PmVGMAFEr1Q2/tYwVGLFVEn6/RvN9P?= =?us-ascii?Q?k+4XklBiBtxfpI30OlC7z3OIkrwU3h90rX58FbMErrpUe7HLwwwB7GwkH3y3?= =?us-ascii?Q?vEJmS+VxPStfq2sW8xxeZ0K+BohGzQGgokBnSgKr6TBnkFCAuSz3KcmK0wjK?= =?us-ascii?Q?ot+wCfsCwE9y9b7dU6r84sYIEsc9FNIH1AwaU524bKW4d+8GrA0jCdEZelMJ?= =?us-ascii?Q?XT5TK8dSk3NQbfrF7aUcFAIPMDwo9ZAbJ1uBoyQOk3bBgZFCrdFTnb05dAw9?= =?us-ascii?Q?Z37fBe0i4xtmSVXhpFywykGTyA9Pm/bFd7Jlt1FXaeJOvo6HyLb8tRHwUNjc?= =?us-ascii?Q?JEtp6jen7DYV/TwA4gxqgRqQv6E8+iC5dC3JNJJkE3bnHbhJozT1sqiD98cN?= =?us-ascii?Q?CmUNnz//aI6jr1RGHPNDQBv/D3oKg2HXH5Zk0+cjdoJFCUD0r/pSB1SCZLD7?= =?us-ascii?Q?aFWQDS7J4WcrxuXfGCxPrU5+aEdXMUD5N5DbT5c0FqxtXSr7bLxoYFy5D19Y?= =?us-ascii?Q?1d+pMEXoumQiDv7GSCs4iRR9jePsb2C1HmqFIq4gAJ/qAf5JEQLTbAoaB7SF?= =?us-ascii?Q?tiiD/2AzhAYGRNHRvBlZ9PfMiAKBiK5TjDuRTHaTqeHmns91o+aEPvbGTHga?= =?us-ascii?Q?I2VWHTMQp+bVWt4dgeeR5x2pFi8E2CQTcBN/FhTBsdV92+1K8tWacyzhYgqs?= =?us-ascii?Q?4sQeW8h3Snl5PHYE/kMcqcqZLbbL9d+FoKOzu9IenWWc79VUOGqT0sdNQrS0?= =?us-ascii?Q?fWNiSxQZPAdKVCszNm590yl8Nu2ieZgNpuUU5dmNZiju3Hw8gaMa8LUS/kuz?= =?us-ascii?Q?uzpYqpwVqtsldjaehhPoG+UBpGovrQMGYoSN6BrNRAyP0NF9NFPrfiiODZLG?= =?us-ascii?Q?1RGc9r0VSjiaQqTckqjzkfJ/uLAeHggwpHz/Ven2rN97o72RqRxXieCqG3B5?= =?us-ascii?Q?XdZBixzhysLKNjEIMLGNqbVndddfnqo=3D?= X-Exchange-RoutingPolicyChecked: jLEfsHiq1xlZcmq9vpqLejaNdN2egt3edMN8H7vRf0xmMYxSkPAErmqOJTzYT8vQPDrmFupnsSi9q29Uwm7tzN1A9TnoFtAlTcTjmAxYsuzNEIO/LXevTmxTu/Jew21FobA7r0xhmCwAFxOJOXRxZoiv+ipviAwBeQ3wPhIJNPuw2FLBPJollkCJyOAXfA5UolU8CmvXfPbTuA5IJFG6MhnERwU8tW24apDdtnWAA75pWolSQ3jas0cIcSfgtH0YAFlk+qpJ4Abf5tBC+N3dHKBVyYY4wIoSGVHGg2iV6GsLG/UrMzLmWVvfmKYANhpMFxCsz7gbTeuCzR1zftIOzA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b2d9d4c-b562-4545-e46c-08df13df9969 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:18.3671 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: l1Fl1rshUhTKy6dNuYmf1y9ulbiQc9abteeTKr2aEBJYQcP8pko1vJgxfbSTKIlFEn6Vqupnhe0I7GW6/8sgsMxX8WnCDR9rPAlnJmSzFtY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX4rcPc3GjM8D1 wa5uB0EY0Y9iyLgzrpamJfFXSefkD46zEZ3+tEYY8zdZ/NVaZMPjaDJdZzP2Nqlsi9ff7+IOTpi Nrs+jN3S39p6OhME0Zd1YLFAscx0Csg= X-Proofpoint-ORIG-GUID: Uh_gmNpcXbqHiEMQ9VPaUsqYzNb0UyrM X-Proofpoint-GUID: Uh_gmNpcXbqHiEMQ9VPaUsqYzNb0UyrM X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX0RBcQQwhNTmY Lwea4NNuGtL8yO3UhLvXnw08n/iEaRlEVidtwX2j23xIRiNFapc0ZA34wPWSpugZ8zdixWAboRf VinHkIyr67fbsO1JMDcDMhb4uIqwNe0D6+/TmQEUJ2Nx+CxGZdBb/rQtRf4Ae5ycbE+c6EmTvZc adN7eVEyZIdjVVDy/qNWWFyXWJnmCpilP2yESbe/f20XWDZPn/+IIVhDAY3ME5tp7JIvbJqgwRd ylQtrIAONuSmYdnT7a7JtQREeaTuqjx5r8Zk7mXM0AanK/JhwidBau93o81DOAJ95sIt/rfvYUk oMUF7lItAgm4EBiFcD01m/TC4SbIOMZiBtunUiyVtCl3EiVHHwTmco3qhoh4ZSLAv75KfVIrzg9 TlhclNsRe+PT5jxQYwjMoGekMUw1LQg7ABCeeMuREX4gTDouf3RN81j0L7w+gXoOo1fGFQKcFic DzcQ5NyKa8DXKwDdWAA== X-Authority-Analysis: v=2.4 cv=QYvzLcbv c=1 sm=1 tr=0 ts=6aaa733f cx=c_pps a=fJIB0T+C2yAfE4P2TQxPqg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=7eIJgSlqxBVt2QvjjhkA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1789555524-CD94A87B-C44751BD/0/0 X-purgate-type: clean X-purgate-size: 960 Signed-off-by: Mark Cave-Ayland --- hw/intc/i8259.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index f2d8cb1489..af33b71591 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -429,15 +429,12 @@ static void i8259_class_init(ObjectClass *klass, const void *data) device_class_set_legacy_reset(dc, i8259_reset); } -static const TypeInfo i8259_info = { - .name = TYPE_I8259, - .parent = TYPE_I8259_COMMON, - .class_init = i8259_class_init, +static const TypeInfo i8259_type_infos[] = { + { + .name = TYPE_I8259, + .parent = TYPE_I8259_COMMON, + .class_init = i8259_class_init, + }, }; -static void i8259_register_types(void) -{ - type_register_static(&i8259_info); -} - -type_init(i8259_register_types) +DEFINE_TYPES(i8259_type_infos) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422604.1648019 (Exim 4.92) (envelope-from ) id 1x6n8s-0006GI-S9; Wed, 16 Sep 2026 10:45:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422604.1648019; Wed, 16 Sep 2026 10:45:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8s-0006FQ-Ms; Wed, 16 Sep 2026 10:45:30 +0000 Received: by outflank-mailman (input) for mailman id 1422604; Wed, 16 Sep 2026 10:45:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8r-00062u-2s for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8q-009uPu-Ep for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:28 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7348-2eae-0a2a0a5409dd-0a2a450b84ac-0 for ; Wed, 16 Sep 2026 12:45:28 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7346-b7e8-0a2a450b0019-94a39744e836-3 for ; Wed, 16 Sep 2026 12:45:27 +0200 Received: from pps.filterd (m0127840.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G83uAY353108; Wed, 16 Sep 2026 03:45:22 -0700 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11021074.outbound.protection.outlook.com [40.107.208.74]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gq9drte6d-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:22 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:21 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=GeiLRjmqXC7pnl0xUqlMjcIIuJxuKXS5eOpzhsJsz 4E=; b=dtgz3oDYS/p6TQ9xHyEtPGQ7SOdVB44WwYKYxMFMHqI5CnEaRb7LcV3Ng pjUSvPkwaLbp6YMBdHBd9f9IDGzZRI840vXK9gFG8BJMh54MZgmErumWVM8cJ234 /kq49kS/W3nb838f5STVHIPhoGPDb6zGOFGbLghvfqQRA32dQOEnCYJOYthMwi9q v95HmtEmXgBk0JneIkDzgHtRpdv0/f9SlsK2Poc2BYMx/d8Wn5R4odxNhRfbqkga ALbmo0+ZexS1CeXiyGlVPUBuHd+NnbLU5iCnQnU/rvPq/wqOc99QdmN/Ew/Ap28q xzB8B115tSRBEIUNZq/lCn988ilqg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qlf4q3wuc4mtJNyQDaGQAFvVDA3352BNuMmFZKh6P/A8DNfDdOxKx8k5b7yVFMie+6oyHeRz09vP214q0kGiB7WQ1ijhA4jMBTXSCfN8kSpDGVKersTv7ATeHGV1GkOUz1+tidOKPvQUFb9DMKdjj3IkqOdn4aATb8kTbkPRG8VCJJvY5odQlZiFlR8/5j2oDZ6MV54MLqFDmpeLoRqqpZSul8n9/Y4uxZCKcVkXL4q/xY9FRbCFA8vLCNuz3jUcz/lqG078y5CgSCzolAUEnFW/X7nxe+b/tjk/WvwPWz2JNzZcoHnt2U55JsrbwdqGg4lxMYyqDEhmwj8RiSnRWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GeiLRjmqXC7pnl0xUqlMjcIIuJxuKXS5eOpzhsJsz4E=; b=c6X3GcL9bsfYwe+QO7kCB/jqGDIQDiIaa6fXMW3tJiHBb2rr1NqyqZ4+au3l5VUlEeUSVvK4qxa9BGsWYIh5yle1TaMihQNB4e1x417gCHnkldhLRTuEt0TcD9LAnRDi/wqLlkCTMMPZPoTOBaoUOC/k0wJRmAfixUuTqgB4fvUkHdSCKOUBsv4Vmw/x49SNFyd0mik2p6EB6l0XIXzWSrnZrEQZIX03CPSP5l9qa7acdquTWYLlA5aqW6kIILpVkCop67WfnLu3UgSNwPho2OifbyHI/uCuOlP7KQ3Jr9MkxIsHUo/5C+V2VpJYZJB9ObmAPHJ3aFYasQosnG0kHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GeiLRjmqXC7pnl0xUqlMjcIIuJxuKXS5eOpzhsJsz4E=; b=dJJ6Ik/oPfwZCcvmmPqW/m5TsQGLzUGlcEtccVgZwMHqWZxswRNcp3t6ZEeJCGyffmCKUIijo++2U6Vr+R0oKseR9dvYumcpmTwXcBAn8nRspBfvXKVH2hVCt+Rs2LbCzK4Joc4OJ2L90XSdzItdLXKl8hht6pFCKTiIhYMxmVDVFGrwAX4LVehl69PN+JqBX3D7HHynfEbhMxPI40fClDY+bhUpi9PhEYxln3/3Hz+WqgpNfsR9rEAPAO9F+56JK2tf8GWiT98C0lrGHPiU4lXXjcK51T/2xYseMEBPpH8yXFirufU7G18XJILXSB1dD265QYM3+p0jlbNsdnHcOg== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 12/22] kvm/i8259.c: convert to use DEFINE_TYPES() macro Date: Wed, 16 Sep 2026 11:43:40 +0100 Message-ID: <20260916104435.600211-13-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ2PR07CA0004.namprd07.prod.outlook.com (2603:10b6:a03:505::10) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 47c17469-b1c6-4396-bd73-08df13df9b5d x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: SZgu+T00QUcGv3RCctNJLGqm3X+vaLNyJxcGm3gR8HFF03HWJewtNf0M2DGY1hC0TRq3L4MH1UCKrZnEkzODmRofoABu6KBZ6LfCi0Tvnm146Kz/ULsYMX+nTRPWdPG/OxW3RsDJYZYBjhFM8q2eSTPSZ04b4IStKN7sjCiM8wcA3sh78Z1qMkkpM0ciL8dFCDIN2wHrlwTdsMeyZPRa+bocAKFMR55iFrDlShPALhyDfaAnCcIekO/7NWY+7kmg+UmebIa+inaHtjKyHXO7fv7YSQbvfNl/V4DRH+qsQ6i9d6Oyg5eVLGB8WCE38KMLPB9GAoiXXX8CsU+rfuci+TfEcZRyLzH2lc68V1CiA9OZoD0UqCVbVmZN/hBIYjK5RwvzgAgof0KkWfXVJ1dP9ZUNdMkpB8RjC37pTbld9Un9buESEy13turlW5vP29emgkgOTIq7Zie+M4nKb990xY8Hf5z1BlGXKVr7qZt2fP0M+t00o5fMg8IlPudZ/XlwZ0oYMHMgVHbbnfgwvIK18zmFhXTQvjqPET7kgBhqLV4wJkY4Esbu4NceDEc6M6BufkpG3a8inb1LwJYAIuz4Ljq6k2X88LhwrHLckkkZ7UW/GcJu4qFSjxt9YcGvMQzokG4Yk36q1bFeLE5Rg+vfY3d7GxyK6f5wVE5jv26BcaM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ojhDwRMRuP0ldhUeCzvfgkMqGEpUlRcGnZzp6ilSV+SrM2lNvjhCriE4aJIN?= =?us-ascii?Q?g/cYh3dIL/JWynrihGV4Jv/WEvsF4EsOx534KHTG0IIwTRVRQ8CpHKBCxuAo?= =?us-ascii?Q?0zaTantCaRraRJUF3eNDnZpq5jKctxqpPiDs8z14c2690LWuC7NXGmKpuVID?= =?us-ascii?Q?/K18mh6GapVw6/53Trj7O7K800WRWWHx2kFMa4aYdIdbWk9JeeUN6Ea2h8fl?= =?us-ascii?Q?uwXuLW2FaIt+RjCYzaek+1zUlp94NKho26XcWjzntQ7gj+X1WeZxQ7NUwd5R?= =?us-ascii?Q?g6MzxF3jTVyuM3R6Nrqqp0Sp6JtHEmPsZpmIz7GUEldx5KTJGnQzKCuFBFgZ?= =?us-ascii?Q?vUKayhH4FKNJ1+AWJ5OGp14LOxk/pjEMVMyBAGIDYWuIUVZUNJyHaPmGYVHB?= =?us-ascii?Q?r1WiO/46SgDd+AfcnUe46JPpEiw4Wmtq6WZGnb4+ctOuISqtKRvpRFhxnRtw?= =?us-ascii?Q?5Y87/9ahZncP+U5JpEEmHIvc16tJYa71y4EawRVN8Vdxlo+itDrda0nfEvmm?= =?us-ascii?Q?7SCxzS/di72+uJ9r38aUPrk3qWY3nNgWP44nXAGmEwVteiu20LxE/anyfDFj?= =?us-ascii?Q?o4w/Wc0QJDsCrSg1TDVSGrdPjbRoPEZ0PEN0eOS8z23Z2ciowhSWbzDBphhb?= =?us-ascii?Q?Ay52kWj24evlqaodxI923knEGcnXdwf0c8zNqVGhJj7QHG82WW+gzt5kk4ig?= =?us-ascii?Q?JA4C5u0VMB8EBYjm/ZW5CKD4f0covco0+kciIT/iJv5y5T0/TFLw/sRD4har?= =?us-ascii?Q?HIPCoo6QDAE6IJbWjeEqPdGtmBC3EyT4BMnnbSx2AB+SYOfqCt4hzEv44fnZ?= =?us-ascii?Q?YZx5K5NoVa8xk1NHDTNpmzRSmbvIFuJsW6kuS1ACPID2WKZFexTZ5rILruCv?= =?us-ascii?Q?WkF8sYYKTU4ITWfyPjCU9qeqITgyl/ipG16zuLFJobwVtymLjY6aS3L+lkXF?= =?us-ascii?Q?rxgfUWQ5YWelDdyN8eyzzX85lbfb4kYJVeQMMao3OqMq8cnafvyQvwS3CDi5?= =?us-ascii?Q?4ZvKRtX4wf23jZzgAL9XnO8uRfB7nFadJgKi8xYIFUJuK9q4EySqqDzlhITo?= =?us-ascii?Q?uXmkGhDjsde2ybOgB0pXswIeAu0BQkCZIMUeib1xt6H1HaW9X8PqC0nb6hF+?= =?us-ascii?Q?0vV8iakuTLXXCU8bBW2sKVEGD6XHrcAiyYu4ZSawSLQD/Mx5UiHQ1Mt7VMG2?= =?us-ascii?Q?pD6WYpdLHuTh1Cn5QEHP32pbTbwNNLopbMeacTpesZemPFqP0rzBoBGZeGug?= =?us-ascii?Q?AT1HeJqjgrfaM5DY18CRsoZf/Y1BJOa00e/g5IEJDjCx5KvDSR0n3jQUm57Y?= =?us-ascii?Q?VS2Jkk5eMRi01/kBD8hteoL9oJhlO7mbx1YNEHlaIwgMycPAsRv4vZuY9iqF?= =?us-ascii?Q?0k8rO0T7Ps4U27RWRC4mPTXB395iZCa/ecJjoQZ8u7STtO9SvidTM6UbEXyI?= =?us-ascii?Q?SyAHNam9mFVh3UDqfi552Dh4qm+Hq9c3lG4ZXTkpZDbvVdXYWRfqahZd/5sP?= =?us-ascii?Q?4+J1uaFhFnjknwqnKm9FlV3qbbXYSky2zuLGpwKIDD8NaqhmwmTK4qNCz0qz?= =?us-ascii?Q?dYihB4DBqSbOU+G+mZaaxiBxNhCHd9XP9itoSqTz6a6QnSdk6Msbq9taXefY?= =?us-ascii?Q?s70KlC66U+oUVvrX+WpW48YIN1zo/Pe1g6ijeGKOP0kqm1Yov5+nay1SLsfk?= =?us-ascii?Q?AMoP3h236wqSh01VSKQoJDNFbBYGbe7GFLfNwf2+4VMGHkLTjh28SaALvsLI?= =?us-ascii?Q?6dSU3XxWYcTHuC9dETomiGOg21Kd+VQ=3D?= X-Exchange-RoutingPolicyChecked: JL22umKvd0v3nk8hOR1fY25JA0L4r0LIwgis+yvClCkhRbUMPXKicsjQgATepJoPX1Nf/9UH9LmZcMsaT1dUNJrolhSgzhKoOO6v8MEetRjvGgwNdWqe63Jntnh163joCwk2fQ0hlwXR35nXzBqrakc5VwaLtjw2v3uBO+jNSj6yrMjAoYkAdvlxnV4OjJ4zAkwzWWfTs6c9QDOHX+N7GCfW5T5Y0daskPKd/tv+fK1KxrY1MdodW9Geojjk2eLY2pfjCsU5XBNFtRAztoghqplfr4HC31dFg/2kqqR8En57xcTgjJDQ7TbKMtM9KsbhyouZ3weKxYARl+/+ZWgSHA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47c17469-b1c6-4396-bd73-08df13df9b5d X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:21.6800 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ABjGaAYpoy2dJKk5f2EzK6bFcjqC9QYlZgRU2XOTVO38UvWBcS3Eggzj119tjlZUr2Hut0P4YsNsFKD9tBL/5Z3TAPpWel0xl3xmaNold30= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXxTDLGFL8AyqA PJPgH8XpyN3vlQxtndYYE9wTnobK3lkTudDgQH4dVzOT+AKwSLsl8bCX1JNGwDz5b4zHZ0JPqh1 0yFYgvO91MWYYw0+IvGHgQwL/FiaJ/QHFN55vGokY8rEX1R8SQvyub4oXg7/UinVkUQGHVc5Z4d wo8lf7HuvFkg6yAAKmBoMRbODUolvjfu5agxHqZy2NBNYxTeyYVjtritIlrf8WK+S0ghEkoUqQ0 /pPt01oA4UrGi9RbFCpuLBiBr3W2wgvWB8+sYzAB1DMymedfb/skQxh9zKm3torDwenA8KwXl95 Tdg61Mf2JK3dGIcLoCGu48Na38o0YXNr1ycg/Bo9TgsG5hmixDkSs7Uyyu5/jnE4gS9KkIwueC6 eAWNmCsi/q3cmBdE1AIy5ht7qmTKse63cO5uqOiZtvSUl1/kbCzStIk+lOMmAaKIPIrD0MIdaE5 laymsUU9yzDnDq5fqFQ== X-Authority-Analysis: v=2.4 cv=XO2l2ghE c=1 sm=1 tr=0 ts=6aaa7342 cx=c_pps a=QrNjdqYeTG6M0XQO4N/sOg==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=64Cc0HZtAAAA:8 a=AnAY-G272_MYj7koicQA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXy3hCaGO24Dnv Tf5DCCUWRRyNelbW0P5uC/AZMJv1gPs6rTSMHuRWMBZoRGX3jH/TGZIZr6sallFuLLPN9JSb3ch k/wEtuWTFpKZQg8EMHvCS8KsgTNob80= X-Proofpoint-ORIG-GUID: Ye0svMxooe8ZJkyyGMnl99pJQBNl6-pF X-Proofpoint-GUID: Ye0svMxooe8ZJkyyGMnl99pJQBNl6-pF X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-42698a/1789555527-1AAD89EA-519350BF/0/0 X-purgate-type: clean X-purgate-size: 987 Signed-off-by: Mark Cave-Ayland --- hw/i386/kvm/i8259.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 28e6e40bd2..9793473163 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -137,15 +137,12 @@ static void kvm_i8259_class_init(ObjectClass *klass, const void *data) k->post_load = kvm_i8259_put; } -static const TypeInfo kvm_i8259_info = { - .name = TYPE_KVM_I8259, - .parent = TYPE_I8259_COMMON, - .class_init = kvm_i8259_class_init, +static const TypeInfo kvm_i8259_type_infos[] = { + { + .name = TYPE_KVM_I8259, + .parent = TYPE_I8259_COMMON, + .class_init = kvm_i8259_class_init, + }, }; -static void kvm_i8259_register_types(void) -{ - type_register_static(&kvm_i8259_info); -} - -type_init(kvm_i8259_register_types) +DEFINE_TYPES(kvm_i8259_type_infos) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422613.1648028 (Exim 4.92) (envelope-from ) id 1x6n8w-0006nb-6F; Wed, 16 Sep 2026 10:45:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422613.1648028; Wed, 16 Sep 2026 10:45:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8w-0006nQ-0Y; Wed, 16 Sep 2026 10:45:34 +0000 Received: by outflank-mailman (input) for mailman id 1422613; Wed, 16 Sep 2026 10:45:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8t-0006V9-W5 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8t-007b2k-CC for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:31 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa733b-bab6-0a2a0a5309dd-0a2a4504b194-32 for ; Wed, 16 Sep 2026 12:45:31 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa734a-b57f-0a2a45040019-94a39b0cddb6-3 for ; Wed, 16 Sep 2026 12:45:31 +0200 Received: from pps.filterd (m0127843.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8Ooof768822; Wed, 16 Sep 2026 03:45:26 -0700 Received: from ch5pr02cu005.outbound.protection.outlook.com (mail-northcentralusazon11022120.outbound.protection.outlook.com [40.107.200.120]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqdhm9r6q-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:26 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:24 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:24 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=Jy1v04X56TCY5cimNIdgAFOsHOMy8I9bpWBMtANdR tA=; b=pWRxEbwvqnF6Z+gbQw0tVVDRTnVrL31Chv3FbbP3hLyOgmmDw9qbA9vv8 Dzbz+GzmtCPNFFqfqgoAyTMgzBrajbE0YQDlY414Yk9riRm4rRi0iUln338G/+hp d9LXGKLL8GENEkHrPgoV2fQ3gsaovUDYztis4UU6O31MuG4yee0ozyA53fEe9Hfb lYguyINjbqFnuxbkS2M9WdqTDH3jYm7U106DXhaR3g4wI2Idj6A9SsgaqeYiffgw KXU/FL1YUeeFZQIhcoLjkMBboFC7BUY5Pt5HWTDypkmz+4mG01OJbtCPZeI+FtAJ 7BbMT52G4UbFANV0XRxPUI1e+0Bwg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fXxEsjAaWUWgSimyTrdo5AaAZrIjYQEBapDnOJSQ6YGN+A4jPzqfP8SUi4DYq/ENuhn9tmQv4CuPedOR8Vng6/nXvNTrWyVtvFiqiH9MADhCb88QlBA1m8ynac4kGWJRHELpaoq3hAO8LvqJqlqQ7PC9qZfuzEdhMiAP7S40nP5BfXMDY8zd8GgtGI7s/BAmIWtocO5MCIjJjZxB1sftfX8zu3Jhl79HrsAns+f9x4m8Ho62BjgGQQwpFR5aAf3pzL8jLIc1zyq9Lq6UF1r6LKYRI9T0x4SjgrjgLT43ihl3eUmdpJJhv6x8rO2LI26XBOg2Mez0cGydxYIY6UstwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Jy1v04X56TCY5cimNIdgAFOsHOMy8I9bpWBMtANdRtA=; b=hxYF6acavvPm2wxGhYlHUsx8qIoHdxR2dKmK5bqyqMOqIw1E2J+PDwG3Rp929Sq3r32PflAWVHfVuMPkYO+Owha50RRkMK2m0KlaVsg8Daqixf/FAXO9nRbcEG6+NPPLGdL6W/3stbcKo4NqlWEXktRqH+Z/s11l8eHmyreXwN7/Gd3kauYF2nSkjk+gw9nyouZEKWZxtKZeSxR4MW90e5JPuLohd4nIhVlTag7IKz5jFHwdPcrdhbmEW0wYybft46KBRbWIRC/USYt634PFl/9DfE6/9wCdTAHgUNWBz3AsEr8KmG1wkJlnfikm9SFzWIvEhNttZA71K/JefhxFlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jy1v04X56TCY5cimNIdgAFOsHOMy8I9bpWBMtANdRtA=; b=mdAx/NZDFw8qqaZSFH2r1j6P4nk+ywr0Z/uv6RfnjENqrCcXxCbzF2e4AnqF4pTwWRbNtvXjhzx/sXHMbY7QG/dYSEXUw2S4ygnYxWP03ZiLZHvVTdKVcnHl94gILkO6mTf1bB7YB/h4UxMgwftXR5ZnYAxa4eB4NLuhfByp3/Pbit+qgQN1IFBEFj238euDu0ciYIUO4XUWdAxgXm6IT2jrIdoaS42X5dQIff7jT42qeMC4nDJ8SrAifixV5bwGWwaePxOTIqHCob5gd5WulZMvLsYX31s5/PZjgksz4wxB53pAz//uWiI1qqLRegcTv0xyIENcbSvS6dXUVHBAeQ== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 13/22] i8259.c: introduce TYPE_I8259_PIC device Date: Wed, 16 Sep 2026 11:43:41 +0100 Message-ID: <20260916104435.600211-14-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0182.namprd03.prod.outlook.com (2603:10b6:a03:2ef::7) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f8559f2-1bf2-4f92-104d-08df13df9d2c x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: kqkNYyfUzXHn99juzjFDmXWP6HZyCnqZbbEYlhCHfbtXG9DGLKV29MNB8uZFblsY9dgT7SdlXatzi3/zijRH3l6/Oj7PQM81iF3Dvq6umQfiO6CO6DKp7znX+Vde2NLvx44h7M5mluKqgbswWgrfThJ8m5TLn0LT/NYt/zm6ElIdShk2aJtzJ0oVM/tnw7AMVN4BhVL2ADH/79x17CS6WQfOALpNdVeS/ssZvWEwyH7ASm+IYly3mFXDuK4hnuL0I655DDcE/ZlCMqeuC9UNQ6otgZNn0QBF0kym1rR2KOMySSR1DZ8MVYs44ciuzj5kMdsaqrsKta9Armb88gkqVbnlNMu7yLNPvX12dZ2oecVhFg3AhaJh0gufuIK/5im9d4dxPGACp02jJo7pzYGegrQ5Ez3M6vXENmHEH5JyrFNRuKvFZwM9ZLl6kAG4498PmGzpizymrie6BPZbdoo6W7nSZybe6ZEL4IIOH9qIy22uHpE2OkpQZXsoce246yvPoCQUZWWL83NgxjoHFcwB4H37P0G5PZCQCmnWFvVLeX1mn6Rgk+6vUYavoa/oKktq1ADnnGCTnSPmmC/gNKRl0rysVTPwlatzsAIX1ykaZ0WEkNmeCT0UfE9AQOwMuO6JRbxoqlG+7pcXHpogUNteeWyJb4ZRLnikg/JM0rCFg+8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?fO/qg/o4mWVX6Xp9u2DdQgDWXFk8ZlXRJ/IblQrGlOq068PncphbdmG6HSSg?= =?us-ascii?Q?VD1ILevdii4eiKxSIJ5OmGJZOo/pCigqZKYUtp9ijftwBoIudt4OXKYGPMyi?= =?us-ascii?Q?tvl+gWc/g/qPdVDfeR4EFmk6WztfoUDLIIiTosEi9Xs0MBS9ZZXkifAjM/bM?= =?us-ascii?Q?ZvkYvP9fNjtBOFMwBV5fzmaIjaQVu8jMJAUtf0s+q33EPqVhOwj4mB2lWTlG?= =?us-ascii?Q?eDhJiD/WnKQWmh47O5EcBl6/Tc7w7gwrx1D4ze0qWvjMpm09J3vr6SrvqnOr?= =?us-ascii?Q?LplR8pJ32IjX7kXf8bezryJbLU2oEph/TWTU8mBCw/FJ/QY4rYK5Ea2ZRC80?= =?us-ascii?Q?iB+DyxgsD0RKMj9UP8tJ5RO0bLm2kWJs0lXBVQh3m1MZ8qWgAUJK3+1n/DnG?= =?us-ascii?Q?I++wtvRcdP2mKDS5limDMBpNwSqV34kjm9wOm/VyBBN5FyQJXE4cTCYyw3+r?= =?us-ascii?Q?dxVyKOGlR9m15jO19BNBXrhGvD+8PDgEV9gsxsDt0zLH1W79n07vzw0RUkgf?= =?us-ascii?Q?dv464GpEyZR8d0D9PDbrGt1XXFZx4h33jFPbYYrNvNZAcoU/wxU1jGlba6iT?= =?us-ascii?Q?ORQdHXul2cmLA8z2+XmBpq1Trd+fVUCsXu5iRbRUGFlCbAhr0njhJrB+eOfD?= =?us-ascii?Q?HzsauaSRJjn4t0YVxDltqGd0b1DvjBBmCjOEiUUDtmdLI0qTbhrB19xVxlib?= =?us-ascii?Q?Cmq/1ncf96+w1Dsuvn0zW/AwdFwZ97VLe5pN4gVukPO/rnn3u/6pzzrUAKHa?= =?us-ascii?Q?rhE4qHxWi/PIwiwH2B7YJaqVS6GhtFUZi+GXJWuKHRZMz6fh/s6Ca2V8InnQ?= =?us-ascii?Q?ZxqnnSpzKL9bREGPdpyoZJsYyWvXIBYJJMnxmj9xuFzzpdN5yAJC5YOp26nJ?= =?us-ascii?Q?gvFk3GTiFLHgfIffu5SltIZRg1VXnzRvne8Ww4QT9N/M0KKiZQsjWdqWagOE?= =?us-ascii?Q?IvILDkBCNQg5q9Lh4a3KzrnZPssXyYZGRibMOs12aG5d/N9RzPcjnewd9Sf2?= =?us-ascii?Q?5QzkZOmWRqHoSN6gXe/FBe6UGtVbEXnojyAIfyosw4mqI94dgiBtogDQn7fb?= =?us-ascii?Q?z9nvVJ61MjZMT+eksMpwqaUgihJOV2fYilmDcxn3rF6W842dlik89uR5P0ad?= =?us-ascii?Q?meI9TrTdgS8SooFZwXiQvn5A8tQh2NIhz7hBgSgkedeMlojFOgonjP2H/xm1?= =?us-ascii?Q?xiPHH20a0TLwMmBbtwzRuj+QU390mU2AjXTWyRDAw491HgoXaRhGag7v0vXz?= =?us-ascii?Q?wW3PZGNapAdjP+FxUGZ+ouMAzZYbVB64wnFyWiSGESs60B+2bNsL2JC+MyYw?= =?us-ascii?Q?SKxGAXuUUPDHWWbR66+RAA3eUyQjXNQHu1BXGW7OSFi5szvi6qMeOy5JoQlY?= =?us-ascii?Q?df9SiBCfGfPNCfFPhdAy3u2OvwGJNwgDFtspviH5cef4r3e32EXTo/0jEre6?= =?us-ascii?Q?Vy3mWp/7+4zS2NM3VH8GqCmJbnN0RAVB+1LbwYskbhD9L8jWqa4EXC/k/MQO?= =?us-ascii?Q?XJOa7ID98t+qbEke326LhRyeDHn7xGPRoOyJHJWV95aGa0DidQr+V3QGLKH1?= =?us-ascii?Q?h4HJoTMMYBNem2YohLLofe9rGHkNL8Vgpyh6tmbEr5J9u/aGSwzo/L53d6Fe?= =?us-ascii?Q?eNxOYxSC8UMr/3WCVGkaFUuazDFTpnq1NX0DjAnNgvtU6z80/bDwvLE8Hoqv?= =?us-ascii?Q?4mz862JUrfGwSGAkBiZPmzC2Ga1seFE3ojg4YqJDYH6aLr+xZArV9raFohbi?= =?us-ascii?Q?CjonJENfGKfVgLbR8xzb0DC+T6Ge+/I=3D?= X-Exchange-RoutingPolicyChecked: Zh+aTXM23hqHIdvBbI+8g2nITmaZWJAbOwtrRA9q0uYroeNsjrg0nccH82mgA6dgQOTfemyx5wi8vPGSg8d9MwwYkPrRQgFm1OmHhB4pis81HManflorzUJL3k6nMkGpirSNk3VkgJytQ+OB9o92dbst23eBiEk1Uh/74SQTrCgG2GXza51zQYbwCYcJA98OW+dGPRhS2Qzgxko6fVuEyWuRsIotH7hUsWM21bpoLyHsRHmJCnmr+tDKCOZgySPgo6UzPClX0yBIa91eGYU/EOQLSqmcWT1BiHnq2XXcdkYq1fWdhG3/SBowgWRy+pXcqXsDLMb9dc060GB2hWbzIQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f8559f2-1bf2-4f92-104d-08df13df9d2c X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:24.7474 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QW+3vlhqxQ6aYe24vIgD/RNLUekWgayHi42HnVr+xdp0BLjY+FknQC6OlBhj7T5DYB9KKygxOJRJsnyayRPuNJDulXyl38Gn5ksqe5iktzc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-GUID: etXJZf7p4Z2i7zg11tkyG5VuRnhs_8Li X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX/EIlMI7ap35K vn2Eo4a8QuJsBEJZp3EyzlZYe5VFyyybBukoyDr7n8lAcWVhrlIeGcTYgLfv/guk5IExNz73vGv RqufHpVQ3i5+oojwtWt26ALpxoSKwHs= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXxeoiuqGmZ0sb vAqxMlEq8JNEdXAV70Yuu14GI7/trknOSpWcLOSe3BJiJW9Oq/JnbZc7UteOdKYIKsDVhD9b9+T fVQioZxRGOC6MSmcPS7A6bYFZI5tmvCBNbyXsegsOhuBCk6XpTCkmImeFuFjrQQwlBSfZ8Zj9R2 cFVocbL2G7UgXTu+pFh0jD5ey/cyp6aopfxYGujRd6hyRG5p18SRUUK6OG4dNYzLus9Oy3Qv1tO enjjprwd3PK93cqGSi8DzLtn5/OCHKIDQKIJPgLjCCllkjj58tGeWeAxEF9bPP51V9RimVLnoEu 6sAwx1mRWBILO8lOfmvzssVuqN+h+N+U0qcEIC0kz1Uh5bMcuwN9x8cb5lfNeVUIK9bhUCPQT/C IwIUp0CvLkMIzJfDFyOLId6v4aw7ZbTH3tRjXf7UfdToVZh7BIoN31Fjh/NC986mVzI0lp+iJgk 3PI5mhLusQ2K7RylPtA== X-Authority-Analysis: v=2.4 cv=IfkSymqa c=1 sm=1 tr=0 ts=6aaa7346 cx=c_pps a=3SCk7X9PwWHtu4c5+rqWlQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=dEe9Ve2bX-KnNSUMM2s9:22 a=64Cc0HZtAAAA:8 a=wVjqpWDhUWNmLA9U0x4A:9 X-Proofpoint-ORIG-GUID: etXJZf7p4Z2i7zg11tkyG5VuRnhs_8Li X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1789555531-C24CBB50-30C0EA97/0/0 X-purgate-type: clean X-purgate-size: 5607 This device represents a PIC for an x86 machine consisting of 2 cascaded i8259 devices wired accordingly. Signed-off-by: Mark Cave-Ayland --- hw/intc/i8259.c | 133 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 118 insertions(+), 15 deletions(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index af33b71591..fcc94e12f8 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -25,7 +25,9 @@ #include "qemu/osdep.h" #include "hw/intc/i8259.h" #include "hw/core/irq.h" +#include "hw/core/qdev-properties.h" #include "hw/isa/isa.h" +#include "qapi/error.h" #include "qemu/timer.h" #include "qemu/log.h" #include "hw/isa/i8259_internal.h" @@ -36,6 +38,22 @@ #define TYPE_I8259 "isa-i8259" +#define TYPE_I8259_PIC "isa-i8259-pic" + +struct I8259PICState { + DeviceState parent_obj; + + qemu_irq pic_out_irq; + qemu_irq pass_irqs[ISA_NUM_IRQS]; + + ISABus *isabus; + IRQState i8259_primary_out_irq; + I8259CommonState i8259[2]; +}; + +OBJECT_DECLARE_SIMPLE_TYPE(I8259PICState, I8259_PIC) + + #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif @@ -392,30 +410,24 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) { qemu_irq *irq_set; DeviceState *dev; - ISADevice *isadev; + Object *pic_obj; int i; irq_set = g_new0(qemu_irq, ISA_NUM_IRQS); - isadev = i8259_init_chip(TYPE_I8259, bus, true); - dev = DEVICE(isadev); + dev = qdev_new(TYPE_I8259_PIC); + object_property_set_link(OBJECT(dev), "bus", OBJECT(bus), &error_fatal); + qdev_realize_and_unref(dev, NULL, &error_fatal); qdev_connect_gpio_out(dev, 0, parent_irq_in); - for (i = 0 ; i < 8; i++) { + for (i = 0 ; i < ISA_NUM_IRQS; i++) { irq_set[i] = qdev_get_gpio_in(dev, i); } - isa_pic = I8259_COMMON(dev); - - isadev = i8259_init_chip(TYPE_I8259, bus, false); - dev = DEVICE(isadev); - - qdev_connect_gpio_out(dev, 0, irq_set[2]); - for (i = 0 ; i < 8; i++) { - irq_set[i + 8] = qdev_get_gpio_in(dev, i); - } - - slave_pic = I8259_COMMON(dev); + pic_obj = object_resolve_path_component(OBJECT(dev), "primary"); + isa_pic = I8259_COMMON(pic_obj); + pic_obj = object_resolve_path_component(OBJECT(dev), "secondary"); + slave_pic = I8259_COMMON(pic_obj); return irq_set; } @@ -429,12 +441,103 @@ static void i8259_class_init(ObjectClass *klass, const void *data) device_class_set_legacy_reset(dc, i8259_reset); } + +static void i8259_pic_set_irq(void *opaque, int n, int level) +{ + I8259PICState *s = opaque; + + qemu_set_irq(s->pass_irqs[n], level); +} + +static void i8259_primary_out_irq(void *opaque, int n, int level) +{ + I8259PICState *s = opaque; + + qemu_set_irq(s->pic_out_irq, level); +} + +static void i8259_pic_init(Object *obj) +{ + I8259PICState *s = I8259_PIC(obj); + + object_initialize_child(obj, "primary", &s->i8259[0], TYPE_I8259); + object_initialize_child(obj, "secondary", &s->i8259[1], TYPE_I8259); + + qemu_init_irq(&s->i8259_primary_out_irq, i8259_primary_out_irq, s, 1); + + qdev_init_gpio_in(DEVICE(obj), i8259_pic_set_irq, ISA_NUM_IRQS); + qdev_init_gpio_out(DEVICE(obj), &s->pic_out_irq, 1); +} + +static void i8259_pic_realize(DeviceState *dev, Error **errp) +{ + I8259PICState *s = I8259_PIC(dev); + DeviceState *pri_dev, *sec_dev; + int i; + + /* Primary */ + pri_dev = DEVICE(&s->i8259[0]); + qdev_prop_set_uint32(pri_dev, "iobase", 0x20); + qdev_prop_set_uint32(pri_dev, "elcr_addr", 0x4d0); + qdev_prop_set_uint8(pri_dev, "elcr_mask", 0xf8); + qdev_prop_set_bit(pri_dev, "master", 1); + if (!isa_realize_and_unref(ISA_DEVICE(pri_dev), s->isabus, errp)) { + return; + } + + for (i = 0; i < 8; i++) { + s->pass_irqs[i] = qdev_get_gpio_in(pri_dev, i); + } + + qdev_connect_gpio_out(pri_dev, 0, &s->i8259_primary_out_irq); + + /* Secondary */ + sec_dev = DEVICE(&s->i8259[1]); + qdev_prop_set_uint32(sec_dev, "iobase", 0xa0); + qdev_prop_set_uint32(sec_dev, "elcr_addr", 0x4d1); + qdev_prop_set_uint8(sec_dev, "elcr_mask", 0xde); + if (!isa_realize_and_unref(ISA_DEVICE(sec_dev), s->isabus, errp)) { + return; + } + + /* Wire up secondary cascade */ + qdev_connect_gpio_out(sec_dev, 0, s->pass_irqs[2]); + + for (i = 8; i < ISA_NUM_IRQS; i++) { + s->pass_irqs[i] = qdev_get_gpio_in(sec_dev, i - 8); + } +} + +static const Property i8259_pic_properties[] = { + DEFINE_PROP_LINK("bus", I8259PICState, isabus, TYPE_ISA_BUS, + ISABus *), +}; + +static void i8259_pic_class_init(ObjectClass *klass, const void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = i8259_pic_realize; + device_class_set_props(dc, i8259_pic_properties); + /* + * Reason: must be wired to the ISA bus via the "bus" property + */ + dc->user_creatable = false; +} + static const TypeInfo i8259_type_infos[] = { { .name = TYPE_I8259, .parent = TYPE_I8259_COMMON, .class_init = i8259_class_init, }, + { + .name = TYPE_I8259_PIC, + .parent = TYPE_DEVICE, + .class_init = i8259_pic_class_init, + .instance_init = i8259_pic_init, + .instance_size = sizeof(I8259PICState), + }, }; DEFINE_TYPES(i8259_type_infos) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422625.1648036 (Exim 4.92) (envelope-from ) id 1x6n8x-00078U-Nq; Wed, 16 Sep 2026 10:45:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422625.1648036; Wed, 16 Sep 2026 10:45:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8x-00077S-I3; Wed, 16 Sep 2026 10:45:35 +0000 Received: by outflank-mailman (input) for mailman id 1422625; Wed, 16 Sep 2026 10:45:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n8w-0006z0-RG for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n8w-009uTy-7z for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:34 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7343-2eae-0a2a0a5409dd-0a2a45089568-42 for ; Wed, 16 Sep 2026 12:45:34 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa734c-f659-0a2a45080019-94a397442c0c-3 for ; Wed, 16 Sep 2026 12:45:33 +0200 Received: from pps.filterd (m0127839.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G80eEf539594; Wed, 16 Sep 2026 03:45:29 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021111.outbound.protection.outlook.com [40.93.194.111]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0pta0c-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:28 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:27 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:27 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=KaJeHdK8X2+JKUmO1RyhHbFBbRUmyKqMfGaHwwjNQ Ek=; b=Tm40bbzjQBoWMoE5Ec8y137ts/ChyVPjJV2uSRGCixUz/MbUY6wu37Rju Oc51l4a78XXC2qru+8IQIs3+/KoTMy2qmzKAHKNdZAqVX1dBsZdU8XIv4EHLiR/P dE1rGLedcqRV64nQ9XEMiWBIuz7Rwayz5XdU9R2+rNgrltkb/y4JW1gWeQqIJQNU G4VoxM9CgSNSk503+7DMS6uPoS8/Rmib5JyvxRoezgjAHUQfw3VlbgF9TnFsjsli lSU/zng2NXqdYNv5SzxrxcXhkCzYCFhT2bu7XewaRkDJWwgUDi1/EUy9k/0J6ibe FZBQF3wO1/AzEN08gnvIHQyDbieeA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W8IQ9qs7agnm4IWI3NMGImwgAP6mT3rqEQyuXt+2NT+J9ZEOfnT5eGt6ycEc8ZNDmXGmoPpSa6Gij1zHRIiUJQDEPa4b4alFjaLy+2cMc++pH2nZ6GDTRJhRhl3904OG9EkGoL+OFWadMrhOeK7YwhQcIEHuPG214wgCZE6DxVlkfIu4O0cWf0O/3QErhfFcYBsZWh8pM1g+eHsMyiDFZ9b2cxUSNokEIE+n0ss9gB3ThPLC8tfkl6XyDkzsvrW3XKRyq+54/xQ0/ONrwLy/EGh8nfBKQWjn1cLaSI7agWHKTyQUM0GiY2D22LMX/ZE3zU6KnScfr+5zLN4zNxcPow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KaJeHdK8X2+JKUmO1RyhHbFBbRUmyKqMfGaHwwjNQEk=; b=Nk/cmRa5RpSMez6tt1FNz1MbS40EPnZuYVJwRm07sd1DKLIP3yEKkK6yrgPJiHfsvqfLi3+zTycJUVwden0Wpk+cZsZZaTSX5yQdgoZQcvbmKzyWvi0iRuJkz2ttiVMz/yzt+e6mc2FJR65aNFAQCLCIAHf/daC7iJrd8EbB4EvnFgN7i+0zkCzyQqDlvitC3vHcc5s7fXUGpmORoS4aKU4rGT/hKk3E/frRzT51FuAoQmBpIbHr0mDmL+cvRM9rgVLgGQr2A7nwyKzNDW2Y1uhay7JLs95LTm8SONkpEUEyBjVx3P87EjUnBB1dJ3ByRDhHyuHY3P3tSgJ9UAl9LA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KaJeHdK8X2+JKUmO1RyhHbFBbRUmyKqMfGaHwwjNQEk=; b=gzfqlvcHFhjE52VrWGrIAv8QWvqdcyulBCConAVv3L9MGGRPzfWBarghMuRumULgINjNdzjZrX39J5tMuvTCLhYOx/32Nwt7iJBrFsCODb40SM1goh5rzB51xrwdr1BtvFVd2GyzM8di0m0nA/3R5DLGOZcssxMTn+GKtWuznD0wRpR58dYp07NXdLjVP3NOsF4/LF+GYgO9zdrPYWT4IGQhbdrcDFbKBuEmEiKMvnMXStOzYrAU4yY5mivPu+FwUM66zREH5bcbRTZf4HxU819H1ll7lPyVlyQ4p/NZ8/nNirMcTYlRlCo2s0bJNt4t4plxs4hDBlSr0WTaFOdZKQ== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 14/22] i8259.c: properly cascade secondary i8259 from primary i8259 Date: Wed, 16 Sep 2026 11:43:42 +0100 Message-ID: <20260916104435.600211-15-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY3PR05CA0026.namprd05.prod.outlook.com (2603:10b6:a03:254::31) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 4e945ac3-1529-4c9f-2b1f-08df13df9f05 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|3023799007|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: VcQ7Mb9r1OYyCbJryQGF2bel79bqeqHy6UyqrWN01MVDAlA8A6NAO0StdrHfNS5Z9yPwH2fLtAYYU7sPyCD1tNAW5JAZUrJBhJ/QYeKuXYxFAsJV7uzYyq+o9sdC5VrfrQ1iwBnfKfiW11g6Yv8sOPrTRcUmDXiSgnohucur9hNtEmiV6dHDEUCYBGAzbZEGw9v+Mx1SxkXvIES5QnXWLtyo+mxRf+ne6UhnteTvjZ2+Z8GaZyJzCIGKelUhYdcw69SubfMDDckcx7Y6leINO5uxNn89RhBUdvp/0YvUHbyD87zi6s1K4rgLtIg3un0XnOi+LXdMWQdo5cMW8YipWHXGwxgoN6Yd4c/lr8qaKsfyyDLfDnSJu4Peb+cVpDVSZftuG2ouGVPptrh99VewlIPJzOc2tHmzm+8UW4aMWm2JEBbez1f4468ZwKZfffHYITq+vMi3ErhiXAjGS8vUqw2t03w38ZiUYp3S2fORUBWWVrAmLL7c7+k5tKpLhdALW5Spm7toS1xXNsMOUt72UU+C+euGm4wb/Anrx/CpC+knADmZzE60OGguU447BYXCXnSBHTBbXgW/qA0dbq15keOkZAd6JMZKNEs0aFxW0+YpRt3epSjt+0Zt1NzFIcNW7/nHIAlD/rsrb1fua0EJ+LonL+UTIZGu5ZR9G8mnm6c= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(3023799007)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zPBqx7B0JlQ41uiY46E24Nav7YXDPvFEHEnVdXVoAmUiS+YJOgEKR35m+t3L?= =?us-ascii?Q?n3P67WVtVABEEMEntIosBtimT9MeSpaV3JmWBNw3yEpm6KPq7A/wcawDIlVA?= =?us-ascii?Q?m6qw/IE2eU7IM0e3diN9cV75AGiepSa0c0XpOjeUsXf2j44a+9xfFpkwNb/8?= =?us-ascii?Q?l+5Gi4SiLNZoL2486XSy6Q+2UevsdvEedB9rDMRuZeGWerWuxtqJIjciy/Yy?= =?us-ascii?Q?NmNLvhtaK4wNBcACHqGW8rtrTye9hYC7c7RtTsyyFJPGwb+jNuzH/MIT+nQD?= =?us-ascii?Q?mpADYQp7ghg9PwSPqRN3VzmyzER0MlgcEvzu8EsasmXJD3uZGDAfpXbmMQZR?= =?us-ascii?Q?mlBXKpiwPkiRlfPrWLxu78gJAWUyYxgJsUW+wPoxA8SKR20w4x5kZHAJLT69?= =?us-ascii?Q?32QVG5Xt4cJJxVeDocovqujxQlE6xOUGc/1nDO7vw1e2dFN8NNT4qvJUzBUi?= =?us-ascii?Q?dNaZ9aJa62djnjAHR1RxFlq0Yw8H4lnl4s7lTZIDO1jlYWnAJXtg12MHnxlj?= =?us-ascii?Q?KtWD7HDompwiHnjd+VKufHw8D2ocSKPUW6ju66B15xiy6dTRFlpgVJI6igZz?= =?us-ascii?Q?7HD+S7A029ceDSS7PRrZLTPUim3HnYIQz4tmr1mljRkB1eiiRY4/0HOTZJgh?= =?us-ascii?Q?ASjfRYUQMEXgNBfFXlV4bjk4nNUxA6xtTp3vKEEWJ6eGe88DwvlhxU+5irna?= =?us-ascii?Q?rXSkbZMKBdxxWt0ZwNcV2loJE+rKdBsZxd8BYgSeGla/0dayKrzU91RkKxb8?= =?us-ascii?Q?hxzvseKdrJu0Q53txhMQlJn3J2nk1iKQZJNtq53B6TS+RP74NJsz9tQyaD5w?= =?us-ascii?Q?mvbCB6dMhVk0FkebW4d83gaFL8BmmT8BMdyYsLNWITkC83sg0tp9HsXJjOJl?= =?us-ascii?Q?FBbRmLVq11t8R2C55VKTV1HusfM7PcBTRIhKJxi3ZmGDoUZ8nZemvxJPczsi?= =?us-ascii?Q?hPjunp4fS7GYsgBT+wt/4xVsNkfhPxcQN+x6Gr4Fd1/02g/1rxMZw/0lWQ16?= =?us-ascii?Q?k3yJlw6hTEWYSUfVdxy9XLQzNYAVfHtsnK6RTkIDKLcp8+wUe7cb60xM3ubA?= =?us-ascii?Q?2oWlAAr84lwb+XUYoHSDWC5+rOy5u8SI4edmLzKsaAtbv5lw2yRTKToGnEYu?= =?us-ascii?Q?do5Q+odWRZfCG0vpClGFoF0xrgmk5CXzn9WVp6PsZzMkFvuWnX3ezUFkuNsn?= =?us-ascii?Q?KRJIS9qduOOzqYtw8tFTnxCuU5VvuKiT9urh64RWvnlFGQwMVvaPtxXVYwY5?= =?us-ascii?Q?87WenBu6hpRU8bLsKRW2EfYLwMlPtRc6kAd6VEI/L0CiQY8U7e5S5e9aEHGk?= =?us-ascii?Q?wiZPifEEhz3Xz6Vl/8sRHu3fmjBOmtUG/aavT++o9RLxfIfN/0davziL+GB3?= =?us-ascii?Q?52nyTGxl8jr6hmKC++iGnmuVzGqqt7S+KllSwCxNhWBHcl04a4jiko/1QQHC?= =?us-ascii?Q?tf0XIV5McNE0YIWYDMZjMSdQP/T2Ay1L93Zf63pVIVsJscnQJ5D5eeWclE5Q?= =?us-ascii?Q?yhTQaB2Xs6XFupinD8hzOowokmpLvUSBKIWXPqK3q8EQpFiSoJaIQAsKVSIG?= =?us-ascii?Q?IiOuGm/3qY2qa8lkJcCsEHET5aZJaHaqBwFgsAzpANidfWnA33jVOeBFSc8e?= =?us-ascii?Q?KzplutZiHfZLEE3pDnM1+QP3HqfJ8pJnENrku3FSxWLhr1B4S2l8SzaMm/PD?= =?us-ascii?Q?JjhAY0V4Y/+5EVTGpoE63HpaunqQ1jJAD24/lkKpH0KBAJ1FQWrlHi8cZfFh?= =?us-ascii?Q?Nmbr8tcSE7CLcUA4qDxFX00OVR463NA=3D?= X-Exchange-RoutingPolicyChecked: wSmWmZMeTDpYSvv9EF0gnp2ud/pkOe4oUMo67WOtpVcuNYbMtqVky9K2EvHM9pp+8i5UTOVkzoRQqsILswnACiY1t4q6u7V136dDLep66OgQyLzTsHfHEFmKxFDBPKNFhTWXFZVtLEKzLhJXcQazjiXJAuHVNHxBs8io6sUvT1kQSOcmvMD2iahY3ePfyfnrcNE+ttOfSFCsJ9KPjgvpYuYhvwcXEOjq3KaCF40huHvfmk+/Q5GXzicSx/9gfzHr7PJ7ugm2aQlF+2b64P5LLqAR+K3Qgt1QcrKrwpJmiLkgNdzp6WzPd3jj6Mf+h4ZtklDlLYvpywnHUGNGofKuig== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e945ac3-1529-4c9f-2b1f-08df13df9f05 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:27.7693 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dmaXQuMyb7DQQOPLaJc8GJ5Xl3dtUHrlyBfm2WnHsLiHi3v4Oq1kB6+9JUPjZ+7/VBRoDyNOmwXRDi+lse1BJst82W1HGrm3wEqeH9Oy64o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-GUID: xXvIDoLSfYsO4AQT1nn-gGaJpLHEO11W X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX6s2lHkCRWpUR SJSu+SZmpCPSDTTy25uzyD3ekb9G7GXS8tQMlB+01HbOrzirZ4uwdv5NahncRocLwu4gbYWzXOj TNDUM4JyKS5Tm6KF7GuGCZtgyCSJv2s= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX9zgopvbNXKQT uZ/MMF0cjOCALNVE/xe/8t3aRT9lLGniY05Ocx6OG6YnidPO1PvWZS00KjUzckKQduzWN0JhGxT lP3LCzx0aBqJNUaDEfvqHe5LcGgvt8/zPl9njdPJuvrdXOJXUGkEb+ZZ5f78aSkTeXG6IeDTwW1 0ChdzZvzocRznBb4bKhW8oLNdKsxE84dchxzx2Yjg2tWyGjzKtpGUb7gvujrPE2sHPGM/hiuxpP ow6C6pUp94Iz/mTrKNJPkiCGXJiGzQs54Ov733i6WvOxk4cZGDUaZK39AEP7tgA71Ku+rzTKnCH WFYLq2gYdZc/q5S+NgjamD+coXAnDyiLHVwUBFFNV8ZZ/wTvicuS1kS+uAbwdwuzL1Wkz+cSGsl zbBQkxxI+GyXQRGE/7NteloUCQymk/plVHQptLiDjYrepxTXRHHfGHMx0Wb4ezZc0qHy4kVtQ1n W9TQGuTzG6u4Hl8/hWw== X-Proofpoint-ORIG-GUID: xXvIDoLSfYsO4AQT1nn-gGaJpLHEO11W X-Authority-Analysis: v=2.4 cv=Ps4G/AM3 c=1 sm=1 tr=0 ts=6aaa7349 cx=c_pps a=Xow/CfGS+sd61STD3JSCXQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=qb3w2fq3S_qpQCe-DwsA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c1860d/1789555534-DF8D587B-72B79366/0/0 X-purgate-type: clean X-purgate-size: 866 Currently the cascaded output from the secondary i8259 is returned directly in the pass_irqs[] array, instead of being connected to the relevant input of the primary i8259. Signed-off-by: Mark Cave-Ayland --- hw/intc/i8259.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index fcc94e12f8..964ceb04b2 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -501,7 +501,8 @@ static void i8259_pic_realize(DeviceState *dev, Error **errp) } /* Wire up secondary cascade */ - qdev_connect_gpio_out(sec_dev, 0, s->pass_irqs[2]); + qdev_connect_gpio_out(sec_dev, 0, + qdev_get_gpio_in(pri_dev, 2)); for (i = 8; i < ISA_NUM_IRQS; i++) { s->pass_irqs[i] = qdev_get_gpio_in(sec_dev, i - 8); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422635.1648047 (Exim 4.92) (envelope-from ) id 1x6n92-0007jH-0M; Wed, 16 Sep 2026 10:45:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422635.1648047; Wed, 16 Sep 2026 10:45:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n91-0007j6-RV; Wed, 16 Sep 2026 10:45:39 +0000 Received: by outflank-mailman (input) for mailman id 1422635; Wed, 16 Sep 2026 10:45:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n91-0007gZ-0l for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n90-00FCP9-D7 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:38 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa734f-e002-0a2a0a5209dd-0a2a450582a2-6 for ; Wed, 16 Sep 2026 12:45:38 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7350-4cb1-0a2a45050019-94a39744b51e-3 for ; Wed, 16 Sep 2026 12:45:38 +0200 Received: from pps.filterd (m0127837.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8JrHB700573; Wed, 16 Sep 2026 03:45:33 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021119.outbound.protection.outlook.com [40.93.194.119]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0ka9xq-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:32 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:31 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:31 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=ltDhewVOxH5BIDFITuFF3S3YzHHvPXtjOOTxeIvEY 0k=; b=mWxOnbPIybvQPEWqgbBSAS0KfdaXAQcDGrvzReQkEbLjId6pdBOUiRqb0 VyMXcS0bJUJvhi5mLSsK3rlpKhRSOrQ+rv+jN46aEFVHq9plinrGf4JK7Vx7HYdc /Eq1t8yh9TNu5FWLEeaqMjXQklR0Cb01lOg7mtxW6CVvXD/M6hO2xHT5GJS2WTYr PNjA5nS6p+Gf2hDqs8nMpPTlChlsLeYot5FMun3lvz87zgn0CKRpEegcLveBhR2T asnkFztAzAutBoGCBm32QmDERjCd9ZZRVFnnS4qS27MCx0lN8TqQcr+PXka1wSnX sADp6D1kFD6aFJyRjpCUzke/hq08g== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=m8ypQl+IrGsTzYmc+VrPAaOR1r6Ntw/opRWBH34Gp2rl02pe2YNSM/0cRTxjCfdx/rIUpxEl+ykjCfCwuE0I3Yr+1Vf2oGauOHyilkvt0x9owt6GbdJgLPc90g/DnDaONQ/2G/5PM//vKMgl2yrMcY29SxUH3p0+0+ojgFO71z9bHF9i/9lc27f9lwhJcCV5P4nCHLPAIjfv8/v4xna2TQILNuhNZmFUf7LBg5OHH+YYLpThXC0pmB+/VKPPtVaGFTq0JBHbSk65omf6ccfZBmEfJbk4Npt65Wq+2asvZ0YASSnyZ8p+yaFhJh4bPxAl9EMOB7knDjWkqUwKlKDfGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ltDhewVOxH5BIDFITuFF3S3YzHHvPXtjOOTxeIvEY0k=; b=mDBO+/8t5BKeOdf5kcZwaBcZB4328h2w4Mkw5u5iSlak5cN6svDIHpMxSl3LUgcc38jkwG1/kTlJPlAd4dUtR2kqM9PE0/1nzdSRwjv6iHxshHeY/JbXS7UNQrTqLth/5FRCbBgiXZrv9UhuZiBhHSGcnpkQluIHVnBqUUifItjqetJUboPeCdOheWC1P09Xf/HRg1gTH+WOjoiNVqIDQJPkvUM5osle8b3nMKJ5dIvkwHNclPCoiaA4kwqDSNWOqLPOahgXYAfpsTl272uHOG4LRK3v7fM8xJnt91YVfsY5/ldL6iUMddamzMLzxVUtg0Ah+MELH35BppTdgnQxQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ltDhewVOxH5BIDFITuFF3S3YzHHvPXtjOOTxeIvEY0k=; b=h+fBzxXMZzbeXRlX8daQQx7bnosXt1AjjxzpTy9RxDoBH8hKqHAsR5gpQ8qWMz5zQiWc+dFfcjcz9d+nJAHRP2kDDFyhLbZtH7E7fOrCXdAzw7yh90V1xeRMcowFlmQ45eYi+TPUmpXqyHwQWVxQahYMVenKBkbU5EJHeRTCSMP53mDSl4l4P0RicGy15kEFE046TYbbCGFJTu+qOdQtm9CuraICAVv2PZjV2oLW88wuzav5qDc4UzL/GwtCubP498OhJmyaXDzecLCH9ey5UcYG2A7Gf0vmGPiJS/wFR/os2gsO5+kZPJFlnFbVQrnovu5TZauWx0SWPYjZeq5JsA== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 15/22] kvm/i8259.c: introduce TYPE_KVM_I8259_PIC device Date: Wed, 16 Sep 2026 11:43:43 +0100 Message-ID: <20260916104435.600211-16-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0224.namprd03.prod.outlook.com (2603:10b6:a03:39f::19) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 57b3878d-70e3-4cf6-8b81-08df13dfa0db x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: XlXoTM862QELIzTTHjHasT7T9OoYtP7Wae/N70KYeqZeL31ekCOiDQMJ+BtSli4D7FuQTk1vkx6N4IINR074ry+aDFMIXC09W9LnPWUFOpts7Zm7W0uL/8ILLmTApQ4W+OSvP6pTysZHZcMp33FRcXTuFMG6aRDXqk6pjoLqdn0hCF4gYtliExHDefpLGjU1YVK2qwGBBMjT2i4gmHf1sHoAdZR0gL/lM558gXhCe18n6D5HD8tBsDSmLIltMspWsVPfBZ36T2mv+Hha+JW3Sn7kxJGXxncz2Q+VzdGGTdEwhvT5SiZwtNqLuXcXHkraNwyFAdrKyoYBTi9stIU4uScwHb6ozJpJU6zSKdSd3p1/BSsUhdNT5WRDs4kR0XdJ1+xh5bydBU1bM+FuoYOl55/RemLJPp6/9fS927PnYn3cHfs3pIlTDXNNOx/3Nd/7mQDeYERYV4L8jkAbXNC1YMPgSvEioAWVbhtwd3FkpM84WoR8x+5G1AWXvDkOBIpzkYsE7gxQ9kPz15KGN/ohn/11urmUpU+4Jfk6L6zjqQLdVoL5/P6pQv5pIaJj08HhtSXiydHlXYhffS8XGXzE4PmpQAulOo8Vqu9OaWa9R/3NEluqnesI2ypfjOep+W/OZTTZ71IKpPDZRiNO8kjrjREi+i4JeNBZXcb36u3g/tg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?28KCIf911ApyxylgPf1uidPuvnRpiOvHhF4B2FNc/oP0tnZRO3Ccc2GBg1vZ?= =?us-ascii?Q?XIVyuDwkPohmWWj6xxTUUYGYcs5y2wLhMGtgelUYZLlahl7dY6TEkcQHqksp?= =?us-ascii?Q?J76bacDHGQXXv5ztkmrzMfekLblkEmbCZL3xuFB1c5M4VCnWX97Rit9N3eLp?= =?us-ascii?Q?jPuKLGZseTPjjZh9Zp4V2VQ4LhjzerM04V8UpZgDWmQ9Yks3n2Kj7bslroV7?= =?us-ascii?Q?JmkK4YLYHR/VsjbUOvcUC/MzETecauJXQPOCnEby/bVo8rcxbkeyPtLh9UND?= =?us-ascii?Q?t+gZiR9ALLtDbs2uabkbFEQVIgE39bALqZ0Fb7tmLqbtZdoAF+iHavGre/7j?= =?us-ascii?Q?g5UeU1cCKXj72AiEQOBB6NhfF/lBfK72eqpFAXx+79fJg0oDaNxS/tBPcBD3?= =?us-ascii?Q?uWBSMLHnfpiXe/vm6Q2O6TbRhQS7Bbs0V3QNZnAYk2M5wLTSbqFNoCfRIDJA?= =?us-ascii?Q?vv+DKEBxjWVDndPg0/uZEw40/ouFxLZYr3nMf+4KgDThck2Jl4BBbSikVedk?= =?us-ascii?Q?B4xb53GkDav19HZh+HirzuxFNZv9NvqvNkhO7iYvwnLlPPvcvlPq4CJ1yB2T?= =?us-ascii?Q?RKvn/PX9MP/9WRLC6Q6svl4PHZFx9YutxKV53zhnP0+1SL7cmp29fDxFrVcT?= =?us-ascii?Q?a3OJtCiBBQ4rYe1Bfg7qIAupYs46XxctUhe1k0XzL2U+6GnfUj1d2e3qFCOm?= =?us-ascii?Q?mOLdQ2+7dy8b/of0jepwycP5ccvwWwcQsb4se09qZPF6fGYmifcuZKUKlCGC?= =?us-ascii?Q?wR21tVr+t2E6/4+NTct8g9GVLwcB81/m6EbJjIqspYgMd7ZLxj+H5O68sU9F?= =?us-ascii?Q?1GFSutjYdJsstPRdHaT54f66w1xYdaK1hWX29mTcDbEtjSg2adCqT3SioDZy?= =?us-ascii?Q?oUVh+PyTqMO+g8D/qEjJM1gA6GOwc0pKtKIKgRzpy0kRQgUgcQwAdQSew9kQ?= =?us-ascii?Q?KYePYdjthpGa5RGVlMI6HqcAideE8GlXOKDkTCuNlN4Pp6daBU8oJtgTjVrM?= =?us-ascii?Q?r8w68YeTR8wJ9BW4kZSbbmK833mfBssOzfTOtGGz0Y4+6j1b9eru48tcq0LR?= =?us-ascii?Q?w/OMTsrmdJQviDGmm+0WIEfI5baKksAY+wOJF5QoKKTeuQ5/LG0828GzbfmN?= =?us-ascii?Q?HzPS4czfQdP7K9AnzN/6M7rDOnzXAx8TmtrZlZT+H1/CCEFKeGUXgy+EuAgD?= =?us-ascii?Q?07iTaKCUl2+aWZ5+YriCaeGo9q0inYkdVDYf5LXPQoBzxvKvARfpiqhH7fud?= =?us-ascii?Q?X5zZGicqIGWCBNvILavp+twwUU0kVA/qoA7YPvwJa9yKhqGOwSSUinihzi3H?= =?us-ascii?Q?CWUIwoTfsLp5pkXRtovS/pHoga5pGYANAmwqPOxVQhobLDv7geguZkU0THzQ?= =?us-ascii?Q?xsaywAHtovyJ36G5ExGTVcmQ2tvn9a4zSQvZoRyaK4vvoUrzmYSMrHrkiIMS?= =?us-ascii?Q?2z09n2+GNKxvRxVXFQijHfR3uPCQYvmkXuuzPmMLnRrTteO9rIi2dKP/QekP?= =?us-ascii?Q?0WErm5gHZx1ruUeBo77XJZqKLp7ljT0nS0B0UdLqlFX4m2+ziHJk8gwavppb?= =?us-ascii?Q?zN4oQEsbaBBkfc879sOja9lruSS3YRjWzLXlwb6SMIBhYu+w9tNn88EHFlYs?= =?us-ascii?Q?WSY6ssJ4HOhIey4tSdsB7pS+lQvA91ybLTrN+m5aOJI4w4DnDIUbZEC7SIJL?= =?us-ascii?Q?YMoTMSrTcTH46diRbgAXeXS31lpwId2Zb0+AT2U0x4NCK/DJLS9cLU8Fc+3x?= =?us-ascii?Q?uhtRDYul3eRZM1DWV3Vu4KeMcR9I4gM=3D?= X-Exchange-RoutingPolicyChecked: XJVhPw+63izdzpFrqJ3YvOlHjghh4Y9E/gNhUFdzFuaaxN8d/B+KfzsSt+8iq2lnxxnl1esN6X1J2FdosL9jPLupaGgTKEl4rtOx0x/b+HdTnn4n2gF+w28pwaQJDP/a5FbMgYdaXLkaEJFQ+edZ2OWRbs9fY+TJpboQD0l8gnu3YAgpqQWuvojn7SZNHnbDyiSEjuLAhQLybKlRI9+ROjueaexww+D71ETQtmKt1s5k/BjT/JjaQfb701DvZtLAmvpXcG/uVw58FRrCs2RyUhF4KFurcE8ED5SytFaNjWbrxltYXbgtk+8DyfToN6ZitlxmNhQovSS6kmrLkYh09Q== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 57b3878d-70e3-4cf6-8b81-08df13dfa0db X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:31.0196 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: xNYoYZn0QtEYCNygkpIMnHxIEOurJvq2W+XeuIIYijDwgXK71QMnrBupo+8bnfi0QAFqVXPXb4yEQ+ItpxGoRFUwEkoGYhyVlO8OYyRhJFs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-GUID: T_a2ioT64h1SRz37BaKhPISEOa-ScxtI X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX27lMZ/R2MGJF PXGDVMGD1a0xFW7hWzB19B1OlxwAnrM3npfFjq5JpRzAK/PiXcSUixMfBfFvJo+pWdpYuzDuAHi gF8qi5k2FgzZ2Cm0vruc/OhAjU2WKdM= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX7qOPq2+hJAXL KfHgNAkraJHUE+miHuWArTxFhhmC9DW+yvNOzmwyCYc/PiWtaZaudKn+AtBpQWDc+fZSafIoPR6 OufkW5igW6e6W9X5PlydS7LaDV/8E6U0NuEUJYPDPIXA7Bh0FBbDVrY4uyxKxIItu2ETln6rbfw 6C7Tp48aeEFNFSAxslpvjVVaYW2ZU7FewMMpPAkQyVGWAUckbPnsZTeENZqutX2WZampasEOzOa 3X69iCyO2Uubs6uqrh9RCdLUgkA2qYBS1QWLSJA92CV8H2kZjdT1RG6LouYsi2AFPe++qN5i6vV t/GswpbWsSAQWZR77SLdwrX4zWgcf4gj3kKsS+HO0BJcZ5baXlWooP+jZsbCWN61cGR55f7svpt N9iBueTSC7oit8DyHgUszPLXB0UvMOM3e/hxy+Aw9z68OZN2tNOZte9mtl6slHiXW/KoFkLq8or Lvmia4h0yhgfcVlG6oA== X-Authority-Analysis: v=2.4 cv=P46vFSAu c=1 sm=1 tr=0 ts=6aaa734c cx=c_pps a=GdOSod5Hi6qnJTGfnwF89g==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=CV9Lyex1vB-al1NDbmIA:9 X-Proofpoint-ORIG-GUID: T_a2ioT64h1SRz37BaKhPISEOa-ScxtI X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-c201ff/1789555538-F7EB92A1-9E3DE4B4/0/0 X-purgate-type: clean X-purgate-size: 4164 This device represents the KVM in-kernel PIC for an x86 machine. Signed-off-by: Mark Cave-Ayland --- hw/i386/kvm/i8259.c | 91 +++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 88 insertions(+), 3 deletions(-) diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 9793473163..0ae5caa655 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -16,11 +16,25 @@ #include "qemu/module.h" #include "hw/intc/kvm_irqcount.h" #include "hw/core/irq.h" +#include "hw/core/qdev-properties.h" #include "system/kvm.h" +#include "qapi/error.h" #include "qom/object.h" #define TYPE_KVM_I8259 "kvm-i8259" +#define TYPE_KVM_I8259_PIC "kvm-i8259-pic" + +struct KVMI8259PICState { + DeviceState parent_obj; + + ISABus *isabus; + I8259CommonState i8259[2]; +}; + +OBJECT_DECLARE_SIMPLE_TYPE(KVMI8259PICState, KVM_I8259_PIC) + + static void kvm_i8259_get(I8259CommonState *s) { struct kvm_irqchip chip; @@ -120,10 +134,21 @@ static void kvm_i8259_realize(DeviceState *dev, Error **errp) qemu_irq *kvm_i8259_init(ISABus *bus) { - i8259_init_chip(TYPE_KVM_I8259, bus, true); - i8259_init_chip(TYPE_KVM_I8259, bus, false); + qemu_irq *irq_set; + DeviceState *dev; + int i; + + irq_set = g_new0(qemu_irq, ISA_NUM_IRQS); + + dev = qdev_new(TYPE_KVM_I8259_PIC); + object_property_set_link(OBJECT(dev), "bus", OBJECT(bus), &error_fatal); + qdev_realize_and_unref(dev, NULL, &error_fatal); - return qemu_allocate_irqs(kvm_pic_set_irq, NULL, ISA_NUM_IRQS); + for (i = 0 ; i < ISA_NUM_IRQS; i++) { + irq_set[i] = qdev_get_gpio_in(dev, i); + } + + return irq_set; } static void kvm_i8259_class_init(ObjectClass *klass, const void *data) @@ -137,12 +162,72 @@ static void kvm_i8259_class_init(ObjectClass *klass, const void *data) k->post_load = kvm_i8259_put; } + +static void kvm_i8259_pic_init(Object *obj) +{ + KVMI8259PICState *s = KVM_I8259_PIC(obj); + + object_initialize_child(obj, "primary", &s->i8259[0], TYPE_KVM_I8259); + object_initialize_child(obj, "secondary", &s->i8259[1], TYPE_KVM_I8259); + + qdev_init_gpio_in(DEVICE(obj), kvm_pic_set_irq, ISA_NUM_IRQS); +} + +static void kvm_i8259_pic_realize(DeviceState *dev, Error **errp) +{ + KVMI8259PICState *s = KVM_I8259_PIC(dev); + DeviceState *pri_dev, *sec_dev; + + /* Primary */ + pri_dev = DEVICE(&s->i8259[0]); + qdev_prop_set_uint32(pri_dev, "iobase", 0x20); + qdev_prop_set_uint32(pri_dev, "elcr_addr", 0x4d0); + qdev_prop_set_uint8(pri_dev, "elcr_mask", 0xf8); + qdev_prop_set_bit(pri_dev, "master", 1); + if (!isa_realize_and_unref(ISA_DEVICE(pri_dev), s->isabus, errp)) { + return; + } + + /* Secondary */ + sec_dev = DEVICE(&s->i8259[1]); + qdev_prop_set_uint32(sec_dev, "iobase", 0xa0); + qdev_prop_set_uint32(sec_dev, "elcr_addr", 0x4d1); + qdev_prop_set_uint8(sec_dev, "elcr_mask", 0xde); + if (!isa_realize_and_unref(ISA_DEVICE(sec_dev), s->isabus, errp)) { + return; + } +} + +static const Property kvm_i8259_pic_properties[] = { + DEFINE_PROP_LINK("bus", KVMI8259PICState, isabus, TYPE_ISA_BUS, + ISABus *), +}; + +static void kvm_i8259_pic_class_init(ObjectClass *klass, const void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = kvm_i8259_pic_realize; + device_class_set_props(dc, kvm_i8259_pic_properties); + /* + * Reason: must be wired to the ISA bus via the "bus" property + */ + dc->user_creatable = false; +} + static const TypeInfo kvm_i8259_type_infos[] = { { .name = TYPE_KVM_I8259, .parent = TYPE_I8259_COMMON, .class_init = kvm_i8259_class_init, }, + { + .name = TYPE_KVM_I8259_PIC, + .parent = TYPE_DEVICE, + .class_init = kvm_i8259_pic_class_init, + .instance_init = kvm_i8259_pic_init, + .instance_size = sizeof(KVMI8259PICState), + }, }; DEFINE_TYPES(kvm_i8259_type_infos) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422643.1648055 (Exim 4.92) (envelope-from ) id 1x6n99-0008MJ-8U; Wed, 16 Sep 2026 10:45:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422643.1648055; Wed, 16 Sep 2026 10:45:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n99-0008M8-4z; Wed, 16 Sep 2026 10:45:47 +0000 Received: by outflank-mailman (input) for mailman id 1422643; Wed, 16 Sep 2026 10:45:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n97-0008Gm-Gn for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n96-00GzGj-TD for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:44 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7352-8faa-0a2a0a5109dd-0a2a4509ca8c-18 for ; Wed, 16 Sep 2026 12:45:44 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7357-be1a-0a2a45090019-94a3974463bc-3 for ; Wed, 16 Sep 2026 12:45:44 +0200 Received: from pps.filterd (m0127839.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8q4Uj541814; Wed, 16 Sep 2026 03:45:40 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021127.outbound.protection.outlook.com [40.93.194.127]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0pta0w-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:39 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:38 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:38 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=AbKFGCy6bi6Di+SjRTibND8oFXMooQqZd57pXAx9H zs=; b=uyIAmcAkKaOGiJoy49/ZvMWPUEUi9/DNBahKbyG4sVR4UYJeIyxhP7+Op gcSsnyEV21n7pZUdWoannDO4ppcMd28d8hgwf8gMb2kexjTLuBjS/KXwkz9//oBL 2DOM7uQ+Ih5oKdPAYeGlmVIq/zloXo2n5xoulQ5KsFN1tGdSp9jRpS1SoWP94G3f oWav7DRvROr4OJBImJ/+wboQ85h0pH8HwOKiysDN/NE4xuEj+I1M5j6gi0IY3//z M/Ykk4lXG6WqA5g6/lyQLTSngp+vmah06/KmHypKJuitdleEdPVTXpZV4enPsS6i Q36B1J/9svGkTFnFPk2qtlJzDbyyg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fC8njwabtF4WW6oAlHmE6sMMIJpA0dBudFJAanFXdYmrc8Kfa3io3ClSdBrWrT3Kecu5V0cPi+/7BJDLm8z9PbOnrRNQf6T7+KlOX+d4voqwxfhgR6akp3wkdih36vyjHPElzqOPlhkW+6pTcbK0AcVPik94Cws8Ud56LqDJbaMhAV9A7vW9mKq0zvIaxiToyiRY0n+0gyHQqkT+1NofrguFnE45XmO1SiPoUg9lMcj8wpHlloS+SQkRhkdGjnn1SYy/i7rDq91Rfm7WtH+FEZ8rExKVzNwe4ru6NeZj6Zms015Qgx3GcAeQhe/D7A4f1uMRnsJhqe2TSsrA836FuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AbKFGCy6bi6Di+SjRTibND8oFXMooQqZd57pXAx9Hzs=; b=lyNc5psA0/ML8NuC4mOw9UpBHfCTsY8CUTp+fcut1L048BfFqghcb+tGslezWQS3lT749FnLbbiBVFM+1QTht1p4ZGATnXLCXVCF0BCzhYpytJeC4jK3ezzjgWdsGBjXRlBEQfiOiWVw5OAW1sMi6qTDjmSD6bauDj1WXGR9jnAmjoSub95lo46OJYkFRRa56rjNX4QXvsgrDpj09Sqpby7FCKCbm+G8jNRuomzWbEEBHlS8V716laZAwhHD8xJJfX3bxFnSLFYZjA32Sx3TDLkFRQGrvlemfKZY65xnnwusqDu1AdH1q1w52P/JW3zDEIbWKg3FuADjPZH3QEm/Tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AbKFGCy6bi6Di+SjRTibND8oFXMooQqZd57pXAx9Hzs=; b=EPDwXfHj1u1wb5qe4hSwzniOHQcC/8H0SCTbpnkp0GEN7MySDXvBddZl2blgaRsUj0Hvk/sAyWLmlkiKs6nmtoPwlnwDO+1D5Dgztw7n4rK9UsqmgV2+9/tFwVz+7Qs+X/e3r0c0yBNJYpCpxujkXs39To+o3fu0gFZcOK3fTaYCtWZafqHQnEpPLhb12QQMBkgpOjM3Fl9PbS9r71+kzoGqRKzrJBUAKkKbUbtfhsDqj96oLw0N5Da3fDLBDfgFGUt/qAdiXjKPm+fMl51ql44ItkqFIaZrVX9rdmCLVb88yEAB+GzpN19S7XR3dDkSvrF5F6QuQjVI4oO5AfZ4Wg== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 17/22] xen/xen-hvm.c: introduce TYPE_XEN_I8259_PIC device Date: Wed, 16 Sep 2026 11:43:45 +0100 Message-ID: <20260916104435.600211-18-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0103.namprd13.prod.outlook.com (2603:10b6:a03:2c5::18) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: edbc8c1b-417f-4626-04f5-08df13dfa551 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|3023799007|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: RTVu5x402l1nA3jWtBY7Nmah/Z/dPEI2ST5uemMPworGzeUjMHQpy26ZwVdZIpdwtzk9BWbWF5cWcUzZKR3c6bhIAEX2FonRXfFy6WDdSIzQPYmWBegeFV31H0+U7eaulKH1wyVnULt9yqcnD1OaQ8BXCgDS9CiCf55Vn8TkKp1az80AL1yslfa9QfKo7iR5wo54ilajOp+cnnxJcrmK+liNG8QkaRaDSe7I0XG60EK7HkUSpxfejk4AyevNce8j8YAqM1igiCuYASIm9y1dxf2WkFExmW9Reg1/HfDBRwyNM+21CSV/w2f5i+CuWEBZDNO//sdl+zuNeSrwlLNWY/NS9MP+biaFlkXQ9dXszNNiTldHC3NfcvsUHTjy4L0X3Pz5ArRUS1HIp5vWHEOuC+5DbRY9rHaS6HcPQtUdPq+6DKlHwSfqkv+QBQoY/OLiBHCwJc5xqJ/iNjvHyVElK6aBnFKypCmu5AbxSTqVmdObpgrn0hufzJ7PvgevtUztnF7l3Nq2Jb7c3gUi9lHJR5PUnrq5pXR4nwzOrkOFThoNVxHgJQ8ab8nkq56Pnn6FphYNA6mwODZBKbbijcu2WN7xjIX/HxXqjQnxysRYAwIU3pjaftpnaHivuyV2y4qyvHPyEBDOwQfmXTPcNA7eG1ZGrY6oAf9iD0NiiCtCJPo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(3023799007)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?spuzrXT7E2cc9NtkVcBKdwUTCWjMDbIYz0Q/srBm/eu+gqYaySzfSsGg3ngG?= =?us-ascii?Q?WauYFAWLu9FEZtAHyhDG6NHqyutHPhOTTKUVB75t8vq3ZPu+yzsO8fXAUdMz?= =?us-ascii?Q?7mW/IMK0rrDMMUB/Ey+Af5Y2HgtzVtvRsZ2/nvEM3RpMTtkSI5puuYPNGoxa?= =?us-ascii?Q?st1F53jt/vhJUTuA69cUQ9O2/bTBFqtRBg4l6WWmU9PemQ3DRO1N7AV9muxE?= =?us-ascii?Q?dijx7XhQS3X1tBJbo4m8dsZdjKFbsgVgyfLLsHCJCB68fPezZN8pkrl08exe?= =?us-ascii?Q?LbDN7S1jpAIZbVQR26qJw3/y5yIaYTK7dZdpk9hXRUC0geyehjAD1zbvhfHt?= =?us-ascii?Q?0Html/MvJCEAABJIe5xYHsRekF2g/bnXByjvxOJKaheQiUmaBLUm3K1JfVOo?= =?us-ascii?Q?Ssc6CpeL0YyLYXF1E6nQjxGVTLvN7uMJHtqSqRvK5wdNMTxTogy6ctPPO0jP?= =?us-ascii?Q?q8/EcWsyde/RAmtK/DedgHAvajkATIJ3zbXjQcSVPPUFnQXEX6vVA4KqYVKr?= =?us-ascii?Q?U0v3lKX+qoIfRacrKaqHMpKKC1ZI0nFw+wn//5RW58wAfGloD2nxRXXrzncE?= =?us-ascii?Q?zi02go0Am7nD4QRRy3P8V60y4AskWOK1AYbtS3BlVMmnJ9usnCOTM/xzu/Jk?= =?us-ascii?Q?uB2tRakGGHaXoMT0OJm7vXgtpT/JHIGnICicF3SzFz5V79QXqClNwrx5aVpz?= =?us-ascii?Q?jISPFuNBcV2SlA7QVlZErdaiviQU3um3DJO+GwK5g7ib5Tk7pzDpYoRBw45Q?= =?us-ascii?Q?z0ia8L6K5bZHnFt3t+ogLB43mDtKnRwwj0sNuu2Q5TzHJ5sXJwBeY5cpsr7Y?= =?us-ascii?Q?OKUICW4ovksu61SJ9X5wdx4q0tplrJf2CHdRCfSCrD05FISqO1Zsp9Amkv6a?= =?us-ascii?Q?VMp6NVbBsH9Dx/A9+8ho5EE98x6iIi3i61qilsKn4Bh6Q12R5gOBdg5QPZ6d?= =?us-ascii?Q?ivWy2dHe7WGfKFL3oReiYbPOvYrHTLsGxwbv1h20WVu5Nr6KfqrxyRPcq4rr?= =?us-ascii?Q?l12HRlmhGHyFcwubgSED2kCakIK7OgqJIhVYvNUghuPSHKXzR756BOgxIbd7?= =?us-ascii?Q?m0u4+SifS23YOeaThqZXvpObE4FitmYbqVIBlmE5Z1gUEiK3oGXevzjFfAO3?= =?us-ascii?Q?ZoTJjCN49gk5PXrSzaG1GoNsWY+BlYzeDJQY8XQISrzdBuSulWDkDg09daoP?= =?us-ascii?Q?NONDKM+gSNerkcNMg+fEZudPPIMC+M1KgYr7DrPLMQlzK9R4C9Mwq66cgQpI?= =?us-ascii?Q?bhn6i1l2Aq66kngzE/ZuNcfdxWrVR4+xVYCh4IlPQqRMnacuVtS54vNqFbWU?= =?us-ascii?Q?S1Fw8DVRE44yrtlWUaOgqT9+HLi2dd4Z9V4IpaH8MiPzmqSvOzkkX9U5VvNK?= =?us-ascii?Q?wi1IG/Dkb7KSEDHmFAcbb37s/nbmzdWyUwUd2+HDDitb8Avt46VwnpEMFFzG?= =?us-ascii?Q?QBSgvRw3QO0nxpVczsrRYJXrq/a4p7DL6WEHDXdge28910+DmzcsfVsh8EsM?= =?us-ascii?Q?VNS6xlZpROOnFhDkj1p/ROtatKSEHTGpJYAIttNoqs2D/A0HSaH4mKhaJX2t?= =?us-ascii?Q?Q3AAKlN6aF5AgDBUnnFp8ECG1Dom3oVMPTt7SVAjNw0rn134px5GNjwrkaG7?= =?us-ascii?Q?Vc2s1hynP0l01+oJlzpwMi1cyrtzS+qpcpdHkhkp10OIRqIxQSpx3Sf2pwuD?= =?us-ascii?Q?YZYtl0vpSsq6LM66ytl2WdIO4ewVKtKZR77mBJSAbGDGqjnM0xGHKNEauIh7?= =?us-ascii?Q?DZGlpmCOt99NkdPrQRk893MlmdIG8O8=3D?= X-Exchange-RoutingPolicyChecked: gwBL1mSHqLxeX6dgLLLCY4OEW0iqlotCK4tGRGPdvfXt34IH70MXyO8X3hNLs+Tg8uoyJnHzzz754WqxJciczpNGNfmJPg57zrt2HYS8roSKOFQUH8mP5loCALBd+IKmG78HNBPzPvIZivV9HkTAKRi/SCkF+1oyIaFoJyqf9DWk3sV/jfIqUhM5ZRBO5giMCXfEJ/SQTpmJk7vX0ra3cBlDs5LZAhRa/FmOiWiT9FE6pcpCHlD5nNyqdxIzUGQK3umPdY4RFWRVmCXtt6g10NAEXXfgE7MH3mTQz2rkSalxXXRdiX691a39K2bglIhuTw+/xCttZImkLJhEOciFGw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: edbc8c1b-417f-4626-04f5-08df13dfa551 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:38.4780 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 71lYsmtJ4F6NRmrK9fPw78CywHNLZ8kQnamSSJHlc5nXTp/7tEd9A4fUEiszuB/vpCmOGCsD5YYfxa+LvcHBWu4qP3oRtDXRgXByr+Lh4Js= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-GUID: 2c5Iupx0Z644kjYl4UWSkPZIK8rJyrIo X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX5OGqPFMkD++J Xa5IM6lVjCseNHyDdroiKWarjk0OM2xcl6SIGRHjaxxyMh9EjnqerVKYwQeS5tb4wDjilTcRJI5 +Lrcu0bLpWhh4JU2WKke3yu2QAsy67k= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXw60ffdmqlbog qY4qr+LORPFKLiebn8rz9iZ+T2QPCgKRbLP8b6x+N8RMpZCCu+t5CtD68VqsPs0cJIXGXJBbBCJ 8/D23at/y/SldsLA1YBXmUEauSdf5B8WvTplyaAu19O3W2jfPmU96dTGsvTrbAGrwbX9vq7ykFo jXvRwG/OC+UfT9FhpkHztfZYY61tZ/RG4jLxoLstRkjNNHkNqHBm8lD7cam45kJXXjb6QsIzy/f pu+uSYQ5HnZ+e81dKhV/+r8qJrh45YQI++RA7JgizgXv+muH2DxvQJc6rZtcL7cgmZR3Ydv9HG4 dYp0jVXqhQASCWrdejD1PvJS+297GEFwCrerRRPEfCuP/4uC6EJJERMWRVdjnKCXX13hsiKyPM0 Eb4hx6ybH1ztZU7iNqrBSGG9SBuhFCfjlntlUiJtvi1QwhtJGOV6vC14uV/Tjs4ZVgiJmlGH4Gx HBjbPbHS92P3HIH4omw== X-Proofpoint-ORIG-GUID: 2c5Iupx0Z644kjYl4UWSkPZIK8rJyrIo X-Authority-Analysis: v=2.4 cv=Ps4G/AM3 c=1 sm=1 tr=0 ts=6aaa7353 cx=c_pps a=wuCIV2M2hcCPwYkL8T+rjw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=y4UcunY2MAxhM4LwGdWI:22 a=64Cc0HZtAAAA:8 a=tqVLSPGIGyqkaOPIRdYA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-bad1c0/1789555544-3AEDE034-34FA9205/0/0 X-purgate-type: clean X-purgate-size: 2075 This device represents the Xen PIC for an x86 machine. Signed-off-by: Mark Cave-Ayland --- hw/i386/xen/xen-hvm.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index af3a90987c..b2378fe3f0 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -13,6 +13,7 @@ #include "qemu/error-report.h" #include "qapi/error.h" #include "qapi/qapi-commands-migration.h" +#include "qom/object.h" #include "trace.h" #include "hw/core/hw-error.h" @@ -69,6 +70,12 @@ static unsigned long *dirty_bitmap; static Notifier suspend; static Notifier wakeup; +#define TYPE_XEN_I8259_PIC "xen-i8259-pic" + +DECLARE_OBJ_CHECKERS(DeviceState, DeviceClass, XEN_I8259_PIC, + TYPE_XEN_I8259_PIC) + + /* Xen specific function for piix pci */ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num) @@ -114,9 +121,28 @@ static void xen_set_irq(void *opaque, int irq, int level) qemu_irq *xen_i8259_init(void) { - return qemu_allocate_irqs(xen_set_irq, NULL, 16); + qemu_irq *irq_set; + DeviceState *dev; + int i; + + irq_set = g_new0(qemu_irq, 16); + + dev = qdev_new(TYPE_XEN_I8259_PIC); + qdev_realize_and_unref(dev, NULL, &error_fatal); + + for (i = 0 ; i < 16; i++) { + irq_set[i] = qdev_get_gpio_in(dev, i); + } + + return irq_set; } +static void xen_i8259_pic_init(Object *obj) +{ + qdev_init_gpio_in(DEVICE(obj), xen_set_irq, 16); +} + + /* Memory Ops */ static void xen_ram_init(PCMachineState *pcms, @@ -760,3 +786,13 @@ void arch_handle_ioreq(XenIOState *state, ioreq_t *req) hw_error("Invalid ioreq type 0x%x\n", req->type); } } + +static const TypeInfo xen_i8259_type_infos[] = { + { + .name = TYPE_XEN_I8259_PIC, + .parent = TYPE_DEVICE, + .instance_init = xen_i8259_pic_init, + }, +}; + +DEFINE_TYPES(xen_i8259_type_infos) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422647.1648064 (Exim 4.92) (envelope-from ) id 1x6n9A-0000C1-NS; Wed, 16 Sep 2026 10:45:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422647.1648064; Wed, 16 Sep 2026 10:45:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9A-0000Bs-JF; Wed, 16 Sep 2026 10:45:48 +0000 Received: by outflank-mailman (input) for mailman id 1422647; Wed, 16 Sep 2026 10:45:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n99-0008TV-U2 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n99-007b5t-AE for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:47 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa734b-bab6-0a2a0a5309dd-0a2a4502b1f4-34 for ; Wed, 16 Sep 2026 12:45:47 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7353-6ca4-0a2a45020019-94a39b0c83ca-3 for ; Wed, 16 Sep 2026 12:45:40 +0200 Received: from pps.filterd (m0127844.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G89JCY579568; Wed, 16 Sep 2026 03:45:36 -0700 Received: from ch5pr02cu005.outbound.protection.outlook.com (mail-northcentralusazon11022099.outbound.protection.outlook.com [40.107.200.99]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqbtb9ybx-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:35 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:34 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:34 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=PgMrs3YOWMsmiAprS015sI7/c0L9GRi3GbtRd7GYD RA=; b=vY36fqt5lxC6fuEwH1Zfa8vKp7pltFM0n9Iwg0F5iqm8eDQwmyGurOA+n fhvdXFSe3bDv2L69Uu0IteLjDTE7QVT1xePpWhy9RI5AQgrMG0EMEbY6/D2UhwHd cnBjXvSmQdlJKGUA/hCqbNUbiVu2g58AvCuWFqWJwPyMZ7v5cc0YIyVQnUiVo/gW SXxQ3PJn3B+9A/8eA0kRToUit2VuBRHh8sry9FI5NljzECjY3eOrl0zC7LTgNzp+ oDlyvwk+flBuQ9q9S8PoTcDUJm/M4apEi0kRdgS1T9E//EGxfXwpDcjuzCFDIx4A lQANDauuTnb4C1uosUsTdtUhWDmtg== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZJYii4s4kl6rIWMm9RxkenXwqcrC9+DXdukoJZJVLA34g04luKbApx75oB+hTZQkp8p2aE0mmo93m0RyPcHbr04w2v+ddRsclUFplznyhR7jpBbU/rhBdATBU4jwRmsiiuAlz76a1V+51b2BCLxJ8FZtTPiusu1AV4MQr4UumJJ0JAk7CmB/4h1kMUBCSll0DizjgI+LMOL7Nk4VkLNUkAan64JO1XYdB+QQyFNezUPzTQHOADmAYiZ6F7oNZHKQS0rSg5QDgWsceH8AeDZQ6lZExvTzNeOaE6Qtw7Fym9KabpykP8/HwWVDbFKmoUMWKBeVYO568idRJeTwMdi3Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PgMrs3YOWMsmiAprS015sI7/c0L9GRi3GbtRd7GYDRA=; b=QoTkbPSvqzxBa+qXvsWfw/+VBt+M2DFAWGMrxwBKCFGIEWyuxQcSjXxjzCAbFkUc4fzvPqlVLcb5HTazcgIB3iq5WVLUMmWOal/ZMF4S5+OuhZMqzBnBdULWm6zWUO1SIs9MeH7HId1cl8WQVwpyyCkRLI6xFGAjYdDaGE6UcOHOAxPD/+6iIYQdbLcOTBXy2VrMn+bC1LJUKbxTMFBXUQ5u/hbqlO0eXVws7cfeaTwobB0CNSL8GRrY5zi0Ybhxb3bH9J4cbirRwqYkRwJH85iiUGXYyIPargAtVXGZRBj2ifbzY8+JTM8aygNPUXAf/wRvJp4r9X9kNxjDAH7r/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PgMrs3YOWMsmiAprS015sI7/c0L9GRi3GbtRd7GYDRA=; b=ij7JQoAfBI0gHgWtmAlxQ0WtqYp1/slc5rY2WZbjSRdWEE2QpIFSVMMFaWjm7HLUyKhKhDwneGZWVU1xG9lEQ4pEtkXXYjEEaO6hjbV023anaPqNGydw9dS5jMymeWdI0OC5lmFMPwZXgxj2mD3d4R26QX3tDpq8s/jBWDVx1HDtRC5Vl721vmjK2svr1v0K/2YILL549VrJMPK0QFDG+lV+Vr/uWDgPleVSCMQ13FAjE21YCf78ZUIzX0l3TpJbTIR9LD4nKx51wL6DvL2h2+O7ebCZQK6hxMHyqA0+q7SwjZNxXYxnSEMOP7W1Hc5J5zu6/Qea1C18H6hDlZUSFw== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 16/22] xen-hvm.c: rename xen_interrupt_controller_init() to xen_i8259_init() Date: Wed, 16 Sep 2026 11:43:44 +0100 Message-ID: <20260916104435.600211-17-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0280.namprd03.prod.outlook.com (2603:10b6:a03:39e::15) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: fef8331e-162c-48f7-de1c-08df13dfa30e x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: Aez+eTmH7fj45IrYLDModWIH70IR7c2Z+1lYLTSLIp/9D8YBcEIZ4I+CQ7helSo13ieEem2EqdxSBNuVySdXIMVgg8FXYt03d7ZUa0XOhrxpfdmsYSe/uJORdJ/l0HCBZ+qtACnwDY9JV0w0UjouTj/WWVNFrITHvzt/UO1290t/iqb5TcPpF2sYfSUs7vC+8k97U7zYldLVyrzUeFa0s7CWYmBx8uhvaGI+r2YHskytFI+V926SfYx45VQbfI+T+6Q2FqRrcSI2wEE8Ivc7OriOvEhoaiB55CcKWIFqt2Cib/b5aiUrOGr/6TqStGjhpYe0vOO4wTIQ5NPi3dM+crDjx/H6uEd79AfxD7ZidUJed74e9qoDJthR7EVHWCYMxgGfyzqlg+FxHrdYyM4+TzGpHjFpatsBk1hMw1UHKr43blTNgxOuuz0YEDYQVF9wfxRYNMNvjff8ymDE9haetA8vVWDXEkuaTWyrhW7gLF+h2UYedyouV+0vnL+9zYm0fvZAO6khAm+kbL70YNoryBif/43ems+r5aG2w/1twNtVTL96u3Xh52Gz+35W0KSHXS96493Gj4KSQka2a++XUoCRWQHc0GjwLDvCKkeTLoQussZJ/f9G6BKlAsXo37Tf2kZDaBhUTFpHuX9QpVa5ZgAG8QiuHlqVx1A+LGBvJGA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?U+/UsDcJWmSbNmbYtqssDwDpCHhK017/7VVfUw+uGpU+MyxGx3mnYZCnDRxF?= =?us-ascii?Q?r7cgzhQjKydWUqwkEp8p9r+8MWW1+TyL/j4/LoV/lfpXf9vw/cTFggm9eNQ1?= =?us-ascii?Q?VGSPPrLHYFwTcl492cdVMUcTQozC42iPwyxC3ayin4GUsySn1sBf5SyNgmn+?= =?us-ascii?Q?uwMRwNOenGucrUBczlxDm/agxlVjjXkrbulfmSf1MHtSnBjScyfMeXr4FuJH?= =?us-ascii?Q?amlvUvkAQPJed5KDLyzqYrX8O/4ixVeoJqFY3m0pgQYTQFiN+9ItNb1n0CWd?= =?us-ascii?Q?+eySU2His+/JwloHaADr7b4HbSBC4N/v7w7Rn2SwL2VJ6x3mxzG3IIKFqy9c?= =?us-ascii?Q?eBVB4ySk8AJJVE1CImehYZfeU4Wa9J11f8T9W1IJzHspN2RoX70uG16WiVaC?= =?us-ascii?Q?5v1pKQKiLDPKu2G7H91gq40TImJ8hkDq5DJigkywsaGeSt7qiNu/XY0+ucwL?= =?us-ascii?Q?Q+Y29hWwijE1w6yAOCbE2zcjCVpfVkdTwkJRenPU9BSx3x2Xh9am0q9soojb?= =?us-ascii?Q?BVNI5w/kgw0LNnbptMeY+tzaBBE/555pQ+HSZa54MpgcVLEBYYqnVM7lMpgd?= =?us-ascii?Q?YQdGMZVSwd7V0mLB0Rt7wC/umnXWqSWWt1CeXDZGAQI5dXR+PckUUygKEvnW?= =?us-ascii?Q?US6mLXkvjGqzlW9F9jSwdFzq5DpSrlEyw+R2EhyBCAOH7ZxsKCPR6vX6MyUH?= =?us-ascii?Q?3wlkz/kKwCsoxCa31waviLMRstxLEpCPa20mrC2VmEKKjSBTJj2vxbcpXvfu?= =?us-ascii?Q?js2qJ0ijV1PLi4W186C4XC4Q8H0DsY/TcriQD+it24Q7mzAwWcuoI840sHpL?= =?us-ascii?Q?sQtMWhYT1KZhk2Bogo8t+ewCLgWba6dldLlYMVwhVWaZrh293ZRc1jDqTfaZ?= =?us-ascii?Q?bOwMZrNjLCntRleMVW0GaYrn7rMvAz1l1qu2wBU7ejoEbcjawRHukREOzch3?= =?us-ascii?Q?BXSPBHG+eOdYi+W8weAQAJzcfsriUtUvc7nntRHd398afoOWw5SHnXPZDGTp?= =?us-ascii?Q?f8RVDXZYQl9zzifhrDMU4Ce6ymut72HrUHwf96LwWICXv8AsFv6qsteqKepV?= =?us-ascii?Q?qUZI6GcEhRfSM7biucqtEYscPqcAiUU7p9uffQWxet55/E0aMEMz+1NnOXn3?= =?us-ascii?Q?7oVtLfFC63Mzm4T7+m+RJLhJSM4tJfkOt2K4SY0HC+okYJ1Gzb1BVH18jb6e?= =?us-ascii?Q?RuJsqmPYweV1fZe/36lhPqiAfVE/U+/8xopHWMXW0nMxG4RKUlohL8RGdn9b?= =?us-ascii?Q?Au2mGn6O/OajlDEOArZLlG4mpr/BAquEEs6GePXjCeUm7ygostPx7Oufcmgv?= =?us-ascii?Q?hw4R0diTvGBGe/0A7X06mKVtlYcE/hjdTo34FGZRHC7H9YYRkbq8dtAyN4z4?= =?us-ascii?Q?liyNojYCbVHEQwYqrdJb4Zsq3COjnR3VTOVYyDWdUHwlGBPm4ZR2B0awLbg7?= =?us-ascii?Q?DyjxWJnTo3LSWkBAG604Kit6NUrdQNkf4jF8cCVxRfaj+V80RhmIDiPllDsk?= =?us-ascii?Q?SN0Pc2e267VD7EJAqjjTwtbhlKPMzZiTL1izYN+HGmFk2pSTRbivLJ++lyOG?= =?us-ascii?Q?fKE561TT2DzeW98Az7qCF5MdV6X169f6XAe2DZtta6SFyKRuDRgv2lruSxwe?= =?us-ascii?Q?yHZq8i9ELhuUjLHTnvhGUU+yfQMs9arY7nqbEGMjMbEcA1w9bVi/P9xlbGyH?= =?us-ascii?Q?+1WuymkMtIUODbI03FUpx2Kxg+swxUa3ET+gmky+lY4txpsVV5+MFIS1QmZG?= =?us-ascii?Q?CKuOPmYdmFEjAtFTKScCeusmsBcHm2s=3D?= X-Exchange-RoutingPolicyChecked: BOV52+Ef5mPKmsfVsddPlPQoD0vA4Jlyjt8vRX6R5X0AAGQspMpiujCyZCB1pD160S2uE0oZj1lRt2wGkM93QWS/P2/0T+PzE+wwWRYTQq+IgVXPlXhz/MG8P5pcZ2KhNz4Dy51HY/Q8tnex2g1fmidm9dbOQU4LY9GTupzlUou6nZEFHZmnqd4oSJLnMcxj7RiYP5WdKVZu6DexRWWmqd6Jxk6apPbAu65+k6Cwg6k/oL0sO8ydQcUxMvfA6llzXqMrDrStJdU4QNdowUJzD7ODYecKAItMlCFYsbQL+T4cumIYPCW4zgETvSaRTU0XizXodbQLB7nZ1fj9484WSQ== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fef8331e-162c-48f7-de1c-08df13dfa30e X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:34.7302 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iZqr55UeLIFu2ny3nlzEnvDyJnfmkOw9xsbG3rUve3xdBpZKcsyNyeJ6pf0ieA1xxC8ig9XnMu/0n0RxSV/bzD/4Nj3AQ9YZFYDE45d4ga4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX6ZuAEDy4+gw4 6z3p6hJ6iApxnrjMHFCYTc/+E6DZwvEJEeeSf37UZQVilruLMZ8LPKRrIUMm0lKZWXtFl74jrnB PDzfWcIXxsMC5J1ZNZ92BD+rxp2O/QI= X-Proofpoint-ORIG-GUID: UavbkyGv_febwgguLzMk2PySixRf5kvn X-Proofpoint-GUID: UavbkyGv_febwgguLzMk2PySixRf5kvn X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXyA6sM3JL0Tm7 rISwHFx3lPHdVE9kmIZlQ4xRXeoFf8nT4ghrkzF8EGfIE8Js5RaJS95ZBqO1ql0HdCNgcf3yp49 OoxyensCSKXcVekicdPPO/uhyZz57dYd3I8DzeEbCMadNAjYzdGzvJrmcSwxiUD+2vSEn4ASz2C wuSAYmfqvlZQuUqO1wSJ/++VA7JpPZyQ+KJzV5VRBidmmaI58Dn2nKVb+bxw7UwaAw6K3CGrFed dRvsVPtmtSDziaAYTSovVDyzqVyTmibwNbJm82R6Z6ZzTekbEXDivJWzzP00WGOjr3JZUhTGDrM fsmKxPtyPmsmn3Q4h9VK/yuKk4WaqdevAWEUuVTw4kiGzrFF1KDpFiVmVVKbn2eMiJab1OUuggt 9VAwdsyaXhHis9H0N9WS0i689FMaRoUr8Skdw1J5Wy+lc5qdMVBiraT0OVXzRAmCEEuZsEkEYt0 GrZ1kepKllJf5nFdqtg== X-Authority-Analysis: v=2.4 cv=QYvzLcbv c=1 sm=1 tr=0 ts=6aaa734f cx=c_pps a=PwPAvtB/AbIKdmTKg7In6w==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=ufYRZG4kn_nPcl-B8swA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-720697/1789555540-F3EBB2AC-88B84B65/0/0 X-purgate-type: clean X-purgate-size: 2197 This clarifies that the interrupt controller being modelled is an emulated i8259 implementation, and brings the naming convention in line with the in-built i8259 and KVM i8259 implementations. Signed-off-by: Mark Cave-Ayland --- include/hw/xen/xen.h | 2 +- hw/i386/pc.c | 2 +- hw/i386/xen/xen-hvm.c | 2 +- stubs/xen-hw-stub.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h index e94c6e5a31..ee4ed4f11b 100644 --- a/include/hw/xen/xen.h +++ b/include/hw/xen/xen.h @@ -42,7 +42,7 @@ void xen_intx_set_irq(void *opaque, int irq_num, int level); void xen_hvm_inject_msi(uint64_t addr, uint32_t data); int xen_is_pirq_msi(uint32_t msi_data); -qemu_irq *xen_interrupt_controller_init(void); +qemu_irq *xen_i8259_init(void); void xen_register_framebuffer(struct MemoryRegion *mr); diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 9006e7c29e..4ad6b81816 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1169,7 +1169,7 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs) if (kvm_pic_in_kernel()) { i8259 = kvm_i8259_init(isa_bus); } else if (xen_enabled()) { - i8259 = xen_interrupt_controller_init(); + i8259 = xen_i8259_init(); } else { i8259 = i8259_init(isa_bus, x86_allocate_cpu_irq()); } diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index d3ce082e07..af3a90987c 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -112,7 +112,7 @@ static void xen_set_irq(void *opaque, int irq, int level) xen_set_isa_irq_level(xen_domid, irq, level); } -qemu_irq *xen_interrupt_controller_init(void) +qemu_irq *xen_i8259_init(void) { return qemu_allocate_irqs(xen_set_irq, NULL, 16); } diff --git a/stubs/xen-hw-stub.c b/stubs/xen-hw-stub.c index 6cf0e9a4c1..b3e27f0292 100644 --- a/stubs/xen-hw-stub.c +++ b/stubs/xen-hw-stub.c @@ -29,7 +29,7 @@ int xen_is_pirq_msi(uint32_t msi_data) return 0; } -qemu_irq *xen_interrupt_controller_init(void) +qemu_irq *xen_i8259_init(void) { return NULL; } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422648.1648074 (Exim 4.92) (envelope-from ) id 1x6n9C-0000Yb-B2; Wed, 16 Sep 2026 10:45:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422648.1648074; Wed, 16 Sep 2026 10:45:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9C-0000Y3-1K; Wed, 16 Sep 2026 10:45:50 +0000 Received: by outflank-mailman (input) for mailman id 1422648; Wed, 16 Sep 2026 10:45:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9A-0000C6-RA for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n9A-007b5t-78 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:48 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7356-bab6-0a2a0a5309dd-0a2a4504a75c-4 for ; Wed, 16 Sep 2026 12:45:48 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa735a-b57f-0a2a45040019-94a397449eb0-3 for ; Wed, 16 Sep 2026 12:45:47 +0200 Received: from pps.filterd (m0127840.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8i7xW353641; Wed, 16 Sep 2026 03:45:43 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021132.outbound.protection.outlook.com [40.93.194.132]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gq9drte7e-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:43 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:42 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:41 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=CVzucpNfOsd45ZWBehwp5Jyz8xROMk2RY6hnw2IeO 3w=; b=eqlHxThBwdbt0dsXsG+Zh+BQVviFsN/bpnm4KDjhfc3zjz8mSNCkxIzqN PbDdPZEm8X+UCoHT6aQX6IcteY3bVqqtxd0i5FlR8JFT2BCSvSfVRoXutShZ6nEN Kl7yuI/H33OSJHIyxaoV/wV5nc3g0ovfJEeUzUi61V342rpHnI877E9Eey9AqXhd qe22EBY8eKeRPtLjvLssxEmdVlqH3QY0wnWkGU6winqcDrvbD/Bqsq8MQ6kTLc3u c5qH72bsPnyVOk7BFjUSJM2Y7/PLWuMN3audCxSOj9u9TUj5RwVme82V0QCRbhEj TimAtZ7RBAM+mxeZ8LOpOr0A6cGoA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ft3EhXjbGPe6426enODVOjnTr/xChz3Rfi8srPexCaVXvlOaoCK0U+EL1w4rqYY8pj1nuhAb9sFRXESHgeowvdVrEKffWcHQb5pZkaLNq49y4A7aFIF5SBV0N9UGmSkfdPAfispEhjiKIgOI5X8GwsfHyOMI7CKJ42nWIWprOUOOXBLpDT74cMpfuNM1n9fIs+xpDXrBBultK2Ha2x0AmEMJqBPZNZw/GhAC9z24Fc0liMp0bzL3Uezs7+dAO2XB+WrKK6xBpgejp2hUuYAjwwFW5N/80RoDPzZFaiQJR5GVMbqLlpqFTETnqr4IEsl9iespO+haSAxNZhHMbLNylA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CVzucpNfOsd45ZWBehwp5Jyz8xROMk2RY6hnw2IeO3w=; b=jMzdcyW2qkNY+r1P8qLJmbL8ufq+rMNCN3GAThZ/yDSW1Eq1AIhn8EXHaf+kHvTVon3ZUzZLgtfk/LgGDAKcBJMSWkZS1USl6KrWbpVbODNXtYjFBUaUhHsUXLQmrerjRf52VlUlacERzvhHMI1oH4PzijydiF+qXMbGOHrACCt3vPYAH7QRwwMwo4xpQjsy7krpMCjB7jC8tqNf9GRL57SVScdYdYFPveEoCEt0bQWNJa8CVvFXFnMC+MrTPeNYrFBmGB6Giob9/AZBTkPQ9yWKDmEy4svCg4jH9npDsGdmhqv931irurSxBZ/K4/8mY+VMooJyrMzYTcBZEaznCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CVzucpNfOsd45ZWBehwp5Jyz8xROMk2RY6hnw2IeO3w=; b=LlvGyLg8+dWh68mocmH/mnfWSThgE0S+NHwAfsAbOja+N902MR7xTQzP9+TmaYUwCrbrTwwULGpM9PckXzhBLJYcPBIoZHab3yrjGgqkpzrNt7wUf4DtjhLOJBb/zVsmPmmjQhQLQEVZ7s7qzQW8Vmvl9II4HKodC8xW6XyodCi6ELz+yKW9flaRzPhzTOFfXW9npNcb8dqTELVS1NajKY6WXRiQGg/MvZwm8kaDHFyBEzPqOwPJNCJmAOwGxbFuS3rR9HzUTG8mCPHfLadxNFZtfSRdYH8Xv4x8EHLwPnfcEjuNaABoez+LKzbSpUaDWkXdTilFKCTpsa86v3Ui2w== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 18/22] i8259_common.c: remove unused i8259_init_chip() function Date: Wed, 16 Sep 2026 11:43:46 +0100 Message-ID: <20260916104435.600211-19-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR13CA0095.namprd13.prod.outlook.com (2603:10b6:a03:2c5::10) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: a5f07026-3969-4637-0487-08df13dfa76d x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: nWFSEh+wjfS9xTxhUHJZmZXI9vckJ/ffqTXv2IDdEaIwwyAnB8v77gGKPfrNd2iLQt5wIg08X8+33xQo4iXPENXORR1j3voPc6gn1BD3qQN0af3eaiDo4m3oQuc3RXEhyTOAPaeeDfKyqU2Q1QlILRmBwChS4sNBkp+74qo/VNXTXttXqanZa+7hV/XytnHDwk6QDAaE2+13f4Zh7/r7a2FGJOJ9Kb9eehM9FhPk/vbJXJ4eNJyGRXp5TMzmZFkmdbFdmzWtvlPMxTDFSHZo2A/v/tZFWRk+G592HdU3i3Fx2aruJdBbKs8zvlMoaG6tJmniOh4ofH47k+n9lDnfblZWanWsJrTV6H0w3AVfkPg5CG6ttm8W5lfSlIs64bh/MXFlQcWKBc/g9nDCF8UzhXFWQPXaMS+4MbgeHME/tjB63LDBYC3AOrTgusjfnF/wMgSLTkxcbAdESzl+i+2zJMZF6oPLqW6635/wtP9C0gpWUlH/H+yydrkCxvqgpEgkExq4BnE0xx4OPqcrl2qzVX8WgQ2ZomTMS054o4fG2I8e0VEKyyCN8Vzh1M976f7QLA22DnOQdK2C9HFQABCv7Wz0JZ//grLI9Nh01CcmYSOwZR46oN3fSOq/szFXctgemPMyvLKN/sKpLy8+dA2tDrJ3X/Zu1rmibba7iZ5fyGw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xqaaYB5G5dEIfMvaLJ8Ma9IONtiEHSU62+8gjaY415EE5Y+vckV3+weBzzRq?= =?us-ascii?Q?LfFIsC32UTleJzJ8ELuFXFoOEJoCpKd4MLO8p4vn6UoEY1w5q18iHckaWV1c?= =?us-ascii?Q?V3hq40LO0qVWI6EsKIXlV5AYMAt1XtkoJZJe/zUE8j2x6Ei5tLC4pFDjC4EU?= =?us-ascii?Q?qYxFPxy0FiSxvvZoFh0JzyuhxpOmZLS6krzhYtlKuOyvNGfqWxJ/2L1FWJi3?= =?us-ascii?Q?9WVFUnC+I28nBTwExOxp0468wZPmQQ7HC2FBq6MgcQ9Db6rDUdNPmQvvGiDF?= =?us-ascii?Q?HvvM/8xxGX706mdDXJ3BJv5uq4Fb9mZL8iGTlAjz+k3dliVHKgJjiALweARW?= =?us-ascii?Q?SoK+5/zmbUQ4V6fIHU4rymoovQ+w0/+RkwvYHerYH0WtiyutTwC0shycY2Am?= =?us-ascii?Q?MovNy60OniwaeQwnedeNTQvvM6cipTCstyJQewVRo7mU/2VfLfL5oa/cne7q?= =?us-ascii?Q?1ei4Xor/S2yZSxiXlVVhHo8VTkkrl1cWqxDu0n/cEwB/GgtMRSSC3fPFJ3hj?= =?us-ascii?Q?h3Mt9d5uz7spz6PHfgrAk98xqOcM3EwQ5ECEIoEbeSe7GFOHwZElgK9pLWV+?= =?us-ascii?Q?st9YJV/EDjE35YCZRLBMx+STUxuq5Dk702lTr3oHBme0ZDHPYo3bQOMmqcuS?= =?us-ascii?Q?nApyyzl6JdTgxEh68xF1it8IF6ajo5MHRl7/H6sXVt9jZSxh30u3SW3Fa14M?= =?us-ascii?Q?/OlU4JhOCnvCEssAY/kYQ8KW0Vnl3PGOw9ZId+MI1dNBFdsyX6WIjX2cr7LR?= =?us-ascii?Q?51AUEo2p3C9NKJ71H3+tyWaXR+zWB6FMFhQe1x/ouE8Kp4vPbHRbXRh/jrVY?= =?us-ascii?Q?bqTh4Rg70bhG8zLcDksqiox9uofqa3w6WPhfmwTuEiN1PCg3COI+aDVUYZDD?= =?us-ascii?Q?Hz8wSMLnOWARuzHj7BPW1Sxeb/gV9uRsVNCIy2ileGwKE6WwR9fzU/ou5kiP?= =?us-ascii?Q?3jCJRAFFEtN4Iox7whKmaNSutyHQuBMGzC+xIt3kheN1f9K7HWBHNZ5ZTj2p?= =?us-ascii?Q?KVHruimnwBI1tr47l1v7Y+UJSAWvKeBHGJ7skJV5uZmM0H39OBsNWEjrJH1B?= =?us-ascii?Q?tKV4KWoz14iIZ3W3/OJBD52C4jW3yiXUz+gzG/JMYpGiC4IZTDhR1baiqJaQ?= =?us-ascii?Q?puI6qPze+RvyXc0A8bDgaudstsQyv57EBjdmPBRPE3sLnRTBuMfvDpUzsq84?= =?us-ascii?Q?6l/nxds7ALjN5x2td3EnaIHvWBYwt1XGrEYhCEn92JQEkOlundiCf9jMO0mb?= =?us-ascii?Q?a0NqIeDJi63nqX+ONio54Zb193H9hGOHX1j3Tge58OPaueHfwfzFgme/PgDs?= =?us-ascii?Q?PT/cIlfgoUeP5EdQBNotKvBXmiuHfSAGhWHjxrJf5VMDkd+NIoLUujFfMFJL?= =?us-ascii?Q?5dwkrnQZ28KVEK1Oex9zPVE5KkA/P9VsvuJlIG2XVuM0V3Q1jGjHMfeUWhRZ?= =?us-ascii?Q?zHOfRJ1ukM2rK4KOHbBCucGFxSc919nkv9EVmFc+jK1P0SJ95dsmNRl8QQhI?= =?us-ascii?Q?egxXIr+H25Mh8bdr9DnN4dq2LaNOOz/uWpTN0utUSSD/qmzwnc2zwEIW0cEY?= =?us-ascii?Q?fZgsibwOPUgryo5KNT7RGXByXbJhgQ66A+0g0+BUxyegVwZnegvkgDJthZxE?= =?us-ascii?Q?wxtC1V7NiFoJt60XG1Vqbpo97j6MMZIrwSR0+ZFupKC7BTcDbL05O8U5I++z?= =?us-ascii?Q?bX33dS/JGAUhOjSfpdSQgjm8+wb9Q0pI7HUDim781hnUKUmG8M6bziURyMor?= =?us-ascii?Q?pLETKZ4M67xMa6aGCbSv+Igvu+HL9XY=3D?= X-Exchange-RoutingPolicyChecked: GxPX6SCW9Cx5S8NQQAYvNpZxBnz93myhLerMer4aX6/0PtFRs68rZ1oX41jm5iatqm0vx8vlHQsRH0cFyaHh7XS9/wvwu2IOa5ChVvOChkU7OH9YL5zVD4UI1yU0kPJlb0LuSRT0QlffIPVIP+LGQQ3jWZmCgmX0fLiGEnQokZRJfuZwwJMYV+k4TXSSwO+NJX4MEBayszV9GXpyIoKML1tDcMA1+llJhZlDQy3M6PpecQkPkXCAsyVOO0uFNIP2PUdm363C7lMSoCxO8ttLBEHFB5w9OowVD3QZgYyElZ2p1I9IovebbLEiR/pA1foAyb7wa/l9G27tvT+v7f286A== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5f07026-3969-4637-0487-08df13dfa76d X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:41.9344 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EKIf7ThANs9prk6b6tofJiZCRA9/GWvhtMqiGQh6711F55QPb9UfIJrJMfzP7xxOj9R1eisCJonivRP17jSGC3eV6L4yKrv4RXvy/lXRRoo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX0nHhkCfUIt3m jGuhlmbQ2ch1t7ETxdqpB6tPSUDftOEvImB84pzjNgSBKDmWGXsNk9Zo4RZn1sPS7V3jPWzVlIf A80YHaF9P+AbJBdgms40/RKEpcSaBoSR8PnZiMF6oPLSV26/YpQjJqW9b+7ErZ/d8thHJRWZUmz j818jK5XGsZA1gcQl7SbtNtXx2xB5BkzuRiRL5V/OapWsFgwIyf15ygL3CjPyVmDpB1w+Mw+vnW r/Ggy4PKcUVFsdyRvPC1aQ/DtpPfrkHAx1pwFfXkCDq8Hy3IO30DrJ8PdkA4wZXeWsLxNzEF7Ch Ca585ciTVd9gTsk3MV8HiqVJq4BgdIwDIkEIM8L25TKedeyUez5lZGUNeHGnJfROoYi8vSSAYt9 350C0VjIZT1c1NFGlhswByMIqgP/He84R+fVixtgRurmuCt+uDLYoJ+tkCayvq2Shur9S/kGpH7 4Bmsh6rWtlYcWhsJkZQ== X-Authority-Analysis: v=2.4 cv=XO2l2ghE c=1 sm=1 tr=0 ts=6aaa7357 cx=c_pps a=hMPBqNrkZiCD5Zgemr5n7Q==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=_-M8LpHI31CeLmyZm6wg:22 a=64Cc0HZtAAAA:8 a=fn9E0C1quIHmE1dKZfwA:9 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfXzorE31bLTvO/ 7vxAMLg3k1BjAklsDO3NSE/msdZDiDrNPgwjOgiaNia3wX+3gtKu2XHhmeW1/2Lq5645sDvIisW 4WbYoij/PfA+S5uGFLBeGUbP5FmMKdY= X-Proofpoint-ORIG-GUID: lr9dVMnoDwcinhadbufyLQ39wMlyeJQh X-Proofpoint-GUID: lr9dVMnoDwcinhadbufyLQ39wMlyeJQh X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-ebf023/1789555548-C0CDFB50-8AF3D9C3/0/0 X-purgate-type: clean X-purgate-size: 1647 This function is now unused and can be removed. Signed-off-by: Mark Cave-Ayland --- include/hw/isa/i8259_internal.h | 1 - hw/intc/i8259_common.c | 16 ---------------- 2 files changed, 17 deletions(-) diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index 282e437d25..390a373511 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -73,7 +73,6 @@ struct I8259CommonState { }; void i8259_common_reset(I8259CommonState *s); -ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master); void i8259_stat_update_irq(int irq, int level); #endif /* QEMU_I8259_INTERNAL_H */ diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index ec229a0b5d..b3f2600523 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -89,22 +89,6 @@ static void i8259_common_realize(DeviceState *dev, Error **errp) qdev_set_legacy_instance_id(dev, s->iobase, 1); } -ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master) -{ - DeviceState *dev; - ISADevice *isadev; - - isadev = isa_new(name); - dev = DEVICE(isadev); - qdev_prop_set_uint32(dev, "iobase", master ? 0x20 : 0xa0); - qdev_prop_set_uint32(dev, "elcr_addr", master ? 0x4d0 : 0x4d1); - qdev_prop_set_uint8(dev, "elcr_mask", master ? 0xf8 : 0xde); - qdev_prop_set_bit(dev, "master", master); - isa_realize_and_unref(isadev, bus, &error_fatal); - - return isadev; -} - void i8259_stat_update_irq(int irq, int level) { if (level != irq_level[irq]) { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422658.1648082 (Exim 4.92) (envelope-from ) id 1x6n9F-0000zm-L3; Wed, 16 Sep 2026 10:45:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422658.1648082; Wed, 16 Sep 2026 10:45:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9F-0000zb-Ei; Wed, 16 Sep 2026 10:45:53 +0000 Received: by outflank-mailman (input) for mailman id 1422658; Wed, 16 Sep 2026 10:45:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9D-0000uz-Ty for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n9D-005QVA-AS for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:51 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa735c-8faa-0a2a0a5109dd-0a2a45069e1e-10 for ; Wed, 16 Sep 2026 12:45:51 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa735d-195a-0a2a45060019-94a39b0cffa6-3 for ; Wed, 16 Sep 2026 12:45:51 +0200 Received: from pps.filterd (m0127844.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G7x6qJ579616; Wed, 16 Sep 2026 03:45:46 -0700 Received: from ch4pr04cu002.outbound.protection.outlook.com (mail-northcentralusazon11023123.outbound.protection.outlook.com [40.107.201.123]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqbtb9yck-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:46 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:45 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:45 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=ihH5Aan2jq7PxNKIjpNTz0jnjtfH5nsB0nWZwEzS8 lg=; b=1YeS32lDh8hcTt5dCJ8oVmIFs5Tu/x7A0UY04UBvg+DkEn5DqoynMYIop ReS/ezvRAsWvbTJgx/6d3ECfLPt4s7v6xWY5TGPa/ko1wXwZ2WNbqr0QSamy80J4 Dtx2Wb7ksF7nlL6YnQEQMK+B4xTqd69kac3vfUhSxof3PUIYnuU5Rv80BNESKfxT hayl9GlOwjyvYY2Ke2dHm02tApNF+bQddkS6jdDTKw4dgFTs6h7qAsuaxGCE0m2m TEJtf1gPSCcx2nL2tfYR+vnGtOF8/Rk4F3KxdBP8rdgA4AFSy9WxrTBUw97cOSiP TJgDvPO4ifAEpqlXA7jy7NxmWCAjw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Jt/EI7Y9DwmWeJSvcY1YjCRt0w451VAXPxUgFdl51ADaGZgtvfevWfu7AyJWtGJ2gs0U8mqyJ37XbXT+EgjnkTSNks29zqtRPyu/K6v27STQ+DX2W0j0uUfgxVhOncfk+1KwH2WEENZYCMpXB09gZv53x2QNxNVw8UoaeIEcpeKgmfJenm3TZaEZvaNQM688tr4gXfGcqL45Nm/FzTbaMOuEiVjQMX9EIUlh8X+n8avr8Doiqrp/Xfki/r5TVe0dj514LAuPfk3EO3o6iNtNtDSTqtNXI1GZOablG8IEACtE48mJLvJmj8Dl236YvedJAMa5OrRNZAoBkm21qRci2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ihH5Aan2jq7PxNKIjpNTz0jnjtfH5nsB0nWZwEzS8lg=; b=SZsFYpUCL8U5qZZDoO36+PUL5Bh0A3oAGfjhx5NbCVRfKQhLj15cw+1DElwRXeTeyXgGU9xjj52vs0Npc/QFMG8uMmYhp9r0IDvkYGRwxoyfh1Ex2BzBawh/jBtEZ8t9rmZeLSa3CBiUtDiPHuRMniowUAsMcxXeftwqtQCJELG2MDe2diYoW42Ap+MC6PtMSAGBoYxL14pGRpcAi1GZqeGPCpjMguihu0NsXGVTTxJRe6pSMfuGS2A0bKuYN40vrRD14Mj7QM9c3Vmpq3NOx0b8NVx0CfOZRX7dZQ/bPLimuAAl55Vb97fDBMc4g+SR5VDuP2Tup9qzqAT36VWWRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ihH5Aan2jq7PxNKIjpNTz0jnjtfH5nsB0nWZwEzS8lg=; b=Bmfnie5TNuQgXOTidqZwziJ9rKQtB1ob7sZRHcWwI5rqjaq0RY5qp9wGzhHsSHi2EInoKqT7Id8pDl2BQMNbpg6iXAV20LyCx190rHr025ENPajtJmgs5QkfSedOkFKXW/qyafDZhAZwm/DXQugKrFEH9fIa9il8mPA9YWeu6pweWiPWOv3E3HpOerwFYlZDoXYFpuYvxa9VoATrsE0RQjU1kccYagNdgANCqi3IS8oVOcknBVDTdktg+zCUVm00s1XNNIALBgwPvoH/X00PUisEiqgSEkzEZu+hORN/A/EGgA0O9vHUNu/yubHw+Tt3+H70SajmwJopQ55++kjzZQ== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 19/22] i8259: move InterruptStatsProviderClass get_statistics() from i8259 to PIC Date: Wed, 16 Sep 2026 11:43:47 +0100 Message-ID: <20260916104435.600211-20-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: BY1P220CA0045.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59e::14) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 7926d65c-4b18-41af-c2b7-08df13dfa95a x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|3023799007|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: wEh6tNVM7FI3/NfB/qPABNPHhAZsIXSrbB80pq/L/t3CNLcmp//SwB7cajpTeL/A/9kVBMD7ylprE6DGFtn43QlFDXoo+ZvMW9/x0EzaO5+EcCkxO37J6is6Bu3wo7GVKeVDnGvtr0E+1rB1pK/5us5Ut4cJdLs314PGvqxtkJpGy3jWkChRZ9vRjAyUR29aky3Jqesd7pGhXdfrK1B8MJByFyygSgIKpUQewfgWWcRDKzG3SbF6n7V0p5L3eIt07Hta7j2jetvwQRK4zhHoDzIb3iiTnxfX+xIpC8NFoEYdZnBf/4GhXwTtPjf6/K+vyHLG6t5Ejtuf8TgZxRBxYl8EnjESCCQwKr1XBkcWZVxwhCK6c/h7QEq10iD/ZymRiHijgWHYRirmTvIep93+bj0pwepFmKwsqlUA6UjwkwAJsMObx/ee5Lm4SmFDiL4HlMccQoR/SuL2wV7pj9/FtfJ0DcR9z8e1IzmxxmKoEzSjyZ4G+VVmchoU2CFyq25aLb29tOEmZKOZyTKFv8ZQHpMcVfWyVdUsx66LQREiWmPQiPKYV30JdgAV8m1/aUkSHmgVl/3ZIxjqbLItPcIj/FJ2I4MNrY6iLAvh/1OSzBflwe/3pyHbGGF5fh7Btb/ZxsRj+6BgzO9sCLT1/JBmVs/lhrrCnrEO+ht5MWG1UUg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(3023799007)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?8pYZ6YWt+VdzaJmG54dG6HJIov/9Y2LN9/NnDkIJls7DHsK2y6UWyi5ANtms?= =?us-ascii?Q?pacqGMaiyD4nxwW3fFxdpdb9gbS3MMASmzF+weV79PT+mxDioLF2G/DDg11R?= =?us-ascii?Q?PJ1lxS6ZUVY8bAPvggvKqzBXZ1FUdjQl5hSnNA1puT9OzTQGaJz8rmmT/GQD?= =?us-ascii?Q?YsVZdwYs8Cgf9xmjJZdPZNLGvGA9XrZCFtLjdw0NzSAAH7W52DF2roHtDNBX?= =?us-ascii?Q?v3uNRg8BSxpNGDbyNF5fNzCGzmKYr3xujG0qHL5AbpMvDhkojJd9g9vWyTge?= =?us-ascii?Q?B7heebURlSPc51ca/ulQ4Z4kC+eRNQE+nSz0VDlKfRpbR/njM+67JqQeC8Nf?= =?us-ascii?Q?0xbjbVmZhWzibD0P1Lm8C9wiOtxIH1l7DAwLiCm/g56UZnP9sjCeT0dmMC+m?= =?us-ascii?Q?wSQ6AQVGRsQC2woUJLvBSVozACtObbSnryA/uE9FBBIxhhBBEsDj6YF7TzkO?= =?us-ascii?Q?lcQ6sdEB9UnPc3S2UL1/z01UKSZXlMCICk1+B2X4f/ixRdGWkmu8smO7cBD2?= =?us-ascii?Q?R4tSLb2oEpMAuXM351UDshywQ+7OZu4XsVbaFvAkRFEqAgdHBcDvCAvxQJdz?= =?us-ascii?Q?IEMHGIprbzMCY2UNYnqd+m8WDiYBFnY8+1Rmw8BJjN+6CvdEjrSWlWmaIfKn?= =?us-ascii?Q?T2G5Nlsw05h41vORybYH69jttzxjvOT0CPwnXYwrciXuIBPpjVg3LT/H8RXq?= =?us-ascii?Q?95Tk0JF3B18vgKSJJvOfNQLhd/P7MakTBGm0S9vfr56AU78PGp2R9gaSsJfe?= =?us-ascii?Q?NTwJk5aUBd/tu6jRoH0n8zOuOk5ojIZpNQug9HpDBxz5n6Zwn9Ueb35m99ka?= =?us-ascii?Q?7aaAMz9jO7WURZrHUhTncu+QJHQ5C6RmOarYyziVwXxsTELwYjrKyBUgTu/3?= =?us-ascii?Q?e9j/nkMDh15Uan/jgnqYQO1ITNOO4m+tMeFFUzYq2BniEk7C3a2jYASGG8Ln?= =?us-ascii?Q?qhqnGUsaI3J7M0H86orXTMCejd1fBItM36wtomvGEz7Z+V7Zw6D13/E1y5oh?= =?us-ascii?Q?xTDLvIb8yNhtN9I0Fo98bVsjb5hqFSqlo+qA7Y91TF8k0KtiE2kfK0Km9cJq?= =?us-ascii?Q?V3WiWFZA3LJ+taunV+N4Y761tmgpd3Fge7PuhCdqqUzCh2AE1/PfzaN85vKZ?= =?us-ascii?Q?eZCWpdCxY7NdNU6/R7FyCPwcZyJbC/2OASnujffVqfy1rkWEGFgPcIzYfF/p?= =?us-ascii?Q?njW+yz/iBvMzY2XqtI8KUyW/JFtElKk7CizJeHA6bKnTH1h/FuR2cbg4ghIT?= =?us-ascii?Q?jaWzJIfeqX+uuEfTbJ/uR4dVDwWOFChTBqm//rzNCGrjahBtsvWPwXgxBBBL?= =?us-ascii?Q?f8/VRHaFHQ41thA19r26a1sL0YusRhFqKK4GVOvBM2rthTUTWK7JzGNW4tDo?= =?us-ascii?Q?lx5BpO7c6K3oNwzc+ad40tdN0qpk14ufIVLcxmAE1oEHJ4TsWrE/FjOpPxQS?= =?us-ascii?Q?rr2wY9JtdP37/RCVaMnsSfRCOdasoH1HicmUrZNwNIlTJoEera/j21r3wJ8l?= =?us-ascii?Q?8jwSBD1FAdTun9uCrdqIZpAWKXCyuUN0kmniYZffBMSWmk80wDM2IOyNn0Sn?= =?us-ascii?Q?J3hYsplfavzezWwIGyatO0NKKpJeieYy4ILQhX0oDiHj6woh9DpI43nDEwIr?= =?us-ascii?Q?l+TOBMtpHE4zHYMY1zvHMtYKbB+ZV6uP4n41FQYJCXC91CrAQo4NLNeEp3F5?= =?us-ascii?Q?VYBRTAOEDTA8u/8YK0A1Rx5yO+T1okzbV3qZBt1ML8lmckpC21eahVr5f9jW?= =?us-ascii?Q?SPvM1cwZULZebBW1tZpHFp/RvvYDcIY=3D?= X-Exchange-RoutingPolicyChecked: g5ZdVuxOFxp4XWe3LvyjZkpOC5AeJku9Tq4meGIVWpjSwJL7DmvXpB/hU1AhZUtE408jMlhHcORgps19G05onx9/U395oTPQyxI/N4xUz13LGtRmdRaCFXxC5hzU5N/w8t4cK2bo9MOnhT1NRfqD0E2CFeLH7iPu/RhMzCRlMciNZwhhPqZhB7/ea3hak87Za9i7Torw4/thky00gCQ94DcOs/+un1u7/6s2JoJp2DaGDa4+YRaSoa3fHZGw83HhXe/Lq2SGggfdiFBTjuROZNOz1z/mDXp1SHV7R9vwiDIEs0JAoG9SaWjBKA4rxqXp/cKZ3XBicYJavs7c7rrr3A== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7926d65c-4b18-41af-c2b7-08df13dfa95a X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:45.2496 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /Dh3ho+PdJTLKkHJi5fgX37f3Msrntc8M7f24zGxqV1xm94I/niydO3LJ5fXywqR6itw+CPa1kKK2WUoktWpFmnUSPYL4nD6vXgk4FbvsoI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX6LKqaZsss3Ig sX7YtgeUxUX0Ng/AurLgXLFmcY0ZHzUasLF4zKNEyPUiDtcQ9PBlR0rdmqmmtXmcpSfsJiWXJza 96YkL9p/MENJZMB/2RvY7qx92gu/iYk= X-Proofpoint-ORIG-GUID: kpVvWs6dz-q-2TTU3FAlEzs_6_aNAjUr X-Proofpoint-GUID: kpVvWs6dz-q-2TTU3FAlEzs_6_aNAjUr X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX+fbmi7BTHGOA +gpdqGxbeC5/BQanNIgTrH4GzUxxPbbGzk/e+ks+dm+eIqLQII//uCDFc1zWxDpBQGE1pW1t3Eb mgpJUKRCcjMkrV5QmMP52h6//MR+pGMSNsEFntF3MOiQIB8PhJhHLQCZ3KstLkOMglGuZAeAv7m u/b79uHLpiwZI8mHmR4aZyXIosGaEbpqtHUkHOcENJOmRnJ2A0/cxy7SMr2/IebYMYj9BWFoh7/ ATJM7nsIczoeY2adBGbinjcrviNluVWqWEnd/Y71eJOnODel3tT42E+EddAqUy1tz3ZXBSbcw8C jVTNytQmHc0IzA9VSOK2LbuVctes1LRyhe9IeRHB9vOOi01FZDvkQouiKabUZOf+gpef8ynqgi3 mIZX3KFphVMHd1JhZomhG3Jqde4vIWx00S5Bz7JSF3O3YGCHONL8BQe+YczpjRJ1vHuTK2NVBSO 4IWWFkxjZ58V/5T0EQg== X-Authority-Analysis: v=2.4 cv=QYvzLcbv c=1 sm=1 tr=0 ts=6aaa735a cx=c_pps a=MuaoZ+x0jvd2FUwkjOjmXQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=0LlEyIVc8U2lsR7dKhuH:22 a=64Cc0HZtAAAA:8 a=A7cMN0_0mIGH7w_oRUwA:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-16d1c6/1789555551-F480577B-222F8659/0/0 X-purgate-type: clean X-purgate-size: 5931 The internal i8259 implementation has workaround logic for storing interrupt statistics since these are currently recorded at the PIC level (i.e. for all 16 interrupt lines) whilst being stored in the master i8259 device which only has 8 physical interrupt lines. Move the get_statistics() implementation from the individual i8259 device to the containing PIC device in preparation for removing this hack. Note that this has a visible change to the "info pic" HMP monitor output since the named device displayed by "info irq" is now the PIC and not the individual i8259: Before (TCG): (qemu) info irq IRQ statistics for ioapic: 0: 68 4: 1 IRQ statistics for isa-i8259: 0: 68 4: 1 After (TCG): (qemu) info irq IRQ statistics for ioapic: 0: 47 4: 1 IRQ statistics for isa-i8259-pic: 0: 47 4: 1 Before (KVM): (qemu) info irq IRQ statistics for kvm-ioapic: 4: 1 IRQ statistics for kvm-i8259: 4: 1 After (KVM): (qemu) info irq IRQ statistics for kvm-ioapic: 1: 3 4: 1 IRQ statistics for kvm-i8259-pic: 1: 3 4: 1 Signed-off-by: Mark Cave-Ayland --- include/hw/intc/i8259.h | 6 ++++++ include/hw/isa/i8259_internal.h | 1 - hw/i386/kvm/i8259.c | 7 +++++++ hw/intc/i8259.c | 7 +++++++ hw/intc/i8259_common.c | 27 ++++++++++++++++++--------- 5 files changed, 38 insertions(+), 10 deletions(-) diff --git a/include/hw/intc/i8259.h b/include/hw/intc/i8259.h index 1921a30371..24237a4ed5 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -1,6 +1,8 @@ #ifndef HW_I8259_H #define HW_I8259_H +#include "hw/intc/intc.h" + /* i8259.c */ typedef struct I8259CommonState I8259CommonState; @@ -18,5 +20,9 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in); qemu_irq *kvm_i8259_init(ISABus *bus); int pic_get_output(I8259CommonState *s); int pic_read_irq(I8259CommonState *s); +bool i8259_pic_get_statistics(InterruptStatsProvider *obj, + uint64_t **irq_counts, + unsigned int *nb_irqs); +void i8259_pic_print_info(InterruptStatsProvider *obj, GString *buf); #endif diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index 390a373511..53751b045b 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -26,7 +26,6 @@ #define QEMU_I8259_INTERNAL_H #include "hw/isa/isa.h" -#include "hw/intc/intc.h" #include "hw/intc/i8259.h" #include "qom/object.h" diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 0ae5caa655..421c9279cd 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -206,9 +206,12 @@ static const Property kvm_i8259_pic_properties[] = { static void kvm_i8259_pic_class_init(ObjectClass *klass, const void *data) { DeviceClass *dc = DEVICE_CLASS(klass); + InterruptStatsProviderClass *ic = INTERRUPT_STATS_PROVIDER_CLASS(klass); dc->realize = kvm_i8259_pic_realize; device_class_set_props(dc, kvm_i8259_pic_properties); + ic->get_statistics = i8259_pic_get_statistics; + ic->print_info = i8259_pic_print_info; /* * Reason: must be wired to the ISA bus via the "bus" property */ @@ -227,6 +230,10 @@ static const TypeInfo kvm_i8259_type_infos[] = { .class_init = kvm_i8259_pic_class_init, .instance_init = kvm_i8259_pic_init, .instance_size = sizeof(KVMI8259PICState), + .interfaces = (const InterfaceInfo[]) { + { TYPE_INTERRUPT_STATS_PROVIDER }, + { } + }, }, }; diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 964ceb04b2..ffd09f6c61 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -517,9 +517,12 @@ static const Property i8259_pic_properties[] = { static void i8259_pic_class_init(ObjectClass *klass, const void *data) { DeviceClass *dc = DEVICE_CLASS(klass); + InterruptStatsProviderClass *ic = INTERRUPT_STATS_PROVIDER_CLASS(klass); dc->realize = i8259_pic_realize; device_class_set_props(dc, i8259_pic_properties); + ic->get_statistics = i8259_pic_get_statistics; + ic->print_info = i8259_pic_print_info; /* * Reason: must be wired to the ISA bus via the "bus" property */ @@ -538,6 +541,10 @@ static const TypeInfo i8259_type_infos[] = { .class_init = i8259_pic_class_init, .instance_init = i8259_pic_init, .instance_size = sizeof(I8259PICState), + .interfaces = (const InterfaceInfo[]) { + { TYPE_INTERRUPT_STATS_PROVIDER }, + { } + }, }, }; diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index b3f2600523..7980f86f1f 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -99,19 +99,28 @@ void i8259_stat_update_irq(int irq, int level) } } +bool i8259_pic_get_statistics(InterruptStatsProvider *obj, + uint64_t **irq_counts, + unsigned int *nb_irqs) +{ + *irq_counts = irq_count; + *nb_irqs = ARRAY_SIZE(irq_count); + + return true; +} + +void i8259_pic_print_info(InterruptStatsProvider *obj, GString *buf) +{ + /* No information for i8259-based PICs */ + return; +} + static bool i8259_common_get_statistics(InterruptStatsProvider *obj, uint64_t **irq_counts, unsigned int *nb_irqs) { - I8259CommonState *s = I8259_COMMON(obj); - - if (s->master) { - *irq_counts = irq_count; - *nb_irqs = ARRAY_SIZE(irq_count); - } else { - *irq_counts = NULL; - *nb_irqs = 0; - } + /* No statistics for individual i8259s */ + *nb_irqs = 0; return true; } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:45:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:45:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422665.1648091 (Exim 4.92) (envelope-from ) id 1x6n9K-0001Wc-8L; Wed, 16 Sep 2026 10:45:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422665.1648091; Wed, 16 Sep 2026 10:45:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9K-0001WP-30; Wed, 16 Sep 2026 10:45:58 +0000 Received: by outflank-mailman (input) for mailman id 1422665; Wed, 16 Sep 2026 10:45:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9I-0001Ok-K9 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n9I-005QVA-0h for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:56 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7363-8faa-0a2a0a5109dd-0a2a450c9f74-4 for ; Wed, 16 Sep 2026 12:45:55 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7362-f479-0a2a450c0019-94a39744ecca-3 for ; Wed, 16 Sep 2026 12:45:55 +0200 Received: from pps.filterd (m0127837.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8K2Tx700459; Wed, 16 Sep 2026 03:45:50 -0700 Received: from sn4pr0501cu005.outbound.protection.outlook.com (mail-southcentralusazon11021091.outbound.protection.outlook.com [40.93.194.91]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0ka9yp-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:50 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:49 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:49 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=ZeMvtYJ+Cvv28zu4IBYu7pIyvPvX3ma62mHZ983wF Q0=; b=xLAgrXQBvpMMlRIMejydplMeLlUcNQhnDk9FKs5pJgXApljCqGyBbKf3W mX1yXPj0Ag2xCyHMS0As0Rojf4vYPlKmkltqMQffeUE/aGmA/geW/i2GJhz18GDE RzPKm0Wz13RYkkcUp3ZKljho8utfYifpoMaRfMp5IAZLEXibq4k3aQRjYsctX5E+ PnUT4hsZ6UW5Ma4TJ0FFJxsnCY5AmD40Tt82G+FOtC4ki770fa0pwwYFAMRMg86x Y74jLVONBscmdg+c25YXodHXcX8sZK5CDyxlbS6ZE1sfnB3ROskqctN1li4PCyUm Z0cS4Avn3v39zfBM2f6Upb7P336sw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h9SkLQMVYi8r7PzJTGNlR0oQ+l0VIHdsVUlHqshmVWJjT17tlrrRrDBOppf8TKj12z1FqJhMht/tYqlHKEuq58z81y9OgEo5D4ObOxLC5uDvIZLctyeumtD31YgdiXfzudKKS5rMVrLqIgc9ZqSU7FHGkCos7yWvUieFh9VKkLeuyAfycAMQPU1oWkX2VUzWbbYaDnT+9GIjOpCEpOKdYsGMdQ88+29TNmvclb4iAKrDqOK+gNd4TabRYk03wgXhmXtAbjYqVFDXpkuFwJiN85K4UlTdnQBdB6jmUAVQeyAWkR+PYNtZxvaQD9mfMOO/S43aB+tozKUsKXifreFfPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZeMvtYJ+Cvv28zu4IBYu7pIyvPvX3ma62mHZ983wFQ0=; b=YO/D6yoLDm4+c+SN4oAm2UbYe4/D8P0q5BWbOfqJuJbXfzWCTnwTPLztA7HbtREQeJt6ozH5Kx1QseDLD4f7p7M//Yw01TUQKZYuE5R7HOdFj2lZ9NlFQa0zWdXhHRPUu0Y7z5QUK7K0DA4mASrtKVtBP89hNYVsdgKmRsYOJn9M4lbV7dm+v4wrJuumOprFeBAb8+92IeG95A/+/vpPWPEjUn7W+g9QbrWWUg1xkUJV0hjU9/RZ9BiSd1NvfmpChGjnXGiykAWP7xoCQmhvAGhW4AOMLNV5CfPalg6r2+AvEcgw3OpyMHNZx2qPR5BAG0VgC9PAnfik2hSnMpm/Bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZeMvtYJ+Cvv28zu4IBYu7pIyvPvX3ma62mHZ983wFQ0=; b=NWLAE6ZSYivBF7qRGLCtXvTbKk1e8rgmF1dyhB6JoycJw4lbirQ8Y9BEXzDBaqFo+m+8GypEShklx7mWRTRB3LcahcHVoVc/rvfHnIW/suUxPcb6rJT5OXm4wTUQY7TIgJhyXdNb4r5/T3ogqVkSDuUa/rMBGzO+P7fCJ6yMfgKkmAnBX03qBpMnSJRl2PSqIfUdVqwryWBojbQQxEJJdYqj9eLn703cCkfI6axhgEGX/Hqj2Djik12OTCcMkuVkaezB+F7GtDLJZN5BnOqlpGN8J6V08If0vfUx8pcPswdhn1inSoCbUc2uM0UGvTXvHgtjWKXe5A5XDUblntc1fw== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 20/22] i8259.c: switch isa_pic from I8259CommonState to I8259PICState Date: Wed, 16 Sep 2026 11:43:48 +0100 Message-ID: <20260916104435.600211-21-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0188.namprd03.prod.outlook.com (2603:10b6:a03:2ef::13) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 5431d887-b5c3-4e13-eaee-08df13dfab79 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|3023799007|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: P+/w8UnkVOtGcFmBzS8Lh/apBY2tOSsqHthSUSr6kF3CrzQc0fslLKjI9UQPgINztRzpIpl4LDgBosczA4+Rlpk+9jEK/r2tdO9xknD/LZhsN4laIAFyWGg3kXzH+f+gm8pkWQjdSRQvA4i1mll4dVqi1WUKeXCbW/dakCmo7G1IkNt144R+alLFpVpHahgx3MdigstjD6PCurMIsXixw1iVC5F2G5yNVYinHvOzOcqSuPxdSy0tfs38QyJ4IocPjLfGRxPKXpfe0kbZco4iWFNIOqJnE/ChNQfQo4B0QsjA2SE+WYed04CwNN5luVoHCEwypXdkqqWZjSWRFyztPHHXRpA7LurDnl9eQHtmnB4mSYr8tETgO7KsB42+2vY/gf0fyQ09D0Lg55N4oD40vH9MUM1Hnr3aVAOeEXbJiQ06yeUIrUTFbeL+BR3jXAB85OgGCneVAhyq8k+oWLpXpC97i1FYUPliRSuEBJeEEY3lLtees9TIDwCz9BwGu+aJCbDG6c5hEi9wW1wkFTh/ChvdidODMwAgruTXdgEdE/g/lRl6wlYniAzQrkNLVYJYYdWdd9c07ZfGNRcChnAyMbMczb0COF5AaH8/7Fv87wTzj+8NrY8PwP/q7B3cNuNrbbDqWUy7DMpyXffmY5Y7mqKh/NbfGpHDcLa5ZKrj7+8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(3023799007)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TEc/l7hHqXouIcnypTjVIgkkPL0uAUHMM3dBa/nmLKuhLfIqBOLvV2STaeaR?= =?us-ascii?Q?BgUiyMhPlhbg9Onj07uANQjewvjyxb0h4txMLIZ3n1y5WhT1agj4T1hbh7G2?= =?us-ascii?Q?cBvaU66v3u25u8aUxQzXidxwAU7zbr88HZm/EXfTQjZ3yD3hkqgCVVD75/gx?= =?us-ascii?Q?ZgHnhDJ9PpmMKAei7B0b930aSn5tnVKhyE7U2MwJklnsTBFZRSDFq1yet/3s?= =?us-ascii?Q?VebB34oJXE1mfQgGt7uuH4+Tvro2gF+AFarVyPNhyeEGVXFXOfDYAtD+3Kl2?= =?us-ascii?Q?WyCHct3r5USfsnja0nBuvG1y2nH84wFuiJfptRYikemoBr6/Vxtl1ft1T97F?= =?us-ascii?Q?BgsAbI8T3e/Bqix69WoIm62H9shCYTNN8VJoCVAXYQEMRydlYbr42D9Qscxi?= =?us-ascii?Q?xZMu0kWac59kUsKefN3wjH0RdOhE5wDH01XB4xKcf9oyI30rRwkpt7PmRgDW?= =?us-ascii?Q?DnW+NkyOhrOlRFrd+HdSWpqKkTsoLuc5WYhBgdd/rIbXLdwqhJ4aO9llG9dh?= =?us-ascii?Q?xm0rqq/rkWWqCpv20iiddz2yzk6hdFbDeh0H1rJUBJ2QEiQcqMd79DHtOiFK?= =?us-ascii?Q?LKk55dEQaoJtNND/fA08l70jbD8+yMACP+wPXrNrgVfGMmCBhcJaYWGB4L8m?= =?us-ascii?Q?ea9dSrBtGy0K36eUze5sx4BSpeoFqldgaMsIMPcqBw1/aa8swQWEoN+JtERF?= =?us-ascii?Q?4uWQZJm3/9C2dMRTBOw88qPibMN5BW9410D19c8QzO23ps5R3+6ZjU4G8ceD?= =?us-ascii?Q?FQrdzsfwRBR8j7I7aj2VbPwFbSZDBrI0y2q5CuMI2c3u2o95cso8f4XKPXr5?= =?us-ascii?Q?vgTGyM6r6Z8QvKZVJZ3WaYZI3ZuoIyFmAl2UzHANfDvNkXuaAtl10ip6dUy3?= =?us-ascii?Q?knFAt2EJd2vuaSujy8Tq1Ydb162oxA7qdH+baPvZrWqAJFNxye3xE4zUBqfW?= =?us-ascii?Q?CbYgdRBLOzmlGWRgvR+qNPPBOmHEFa2TbrlcpuP6Y8a839/CCQYQsewiIz/e?= =?us-ascii?Q?m+yIjHguru/EKh1hdYqO/cxfpE/2mpSwRrVj+oqL/1rQ6tnkFBg3GQaZziX7?= =?us-ascii?Q?dGPcuc0lisUX70ohM5oLNPi8MW1mcpfrfZ+/uu6nvY1jLiOyqPN9fYMazWGH?= =?us-ascii?Q?TuMoTUmKyfBm2DH/b5kyvWfFHUiNRClrgSqBfu4dLAQdO3UPXEGladiWDOn9?= =?us-ascii?Q?Mg3AWCGXGSLLQZLKVsoYSu32WKV1fYd0ccDTE7fah/OzyCrqLx+vV96WIJ+l?= =?us-ascii?Q?xnLMTev22VQiFv2SbBbn1PqAD8aLcN6V6SnBjR0R60UTICbHMT1JMXmLPBBl?= =?us-ascii?Q?m+iSoSzeodRizAHBbFF9JfxekJ7b3ZC13j8A3OngmV79QU/fcZgg++AsqdnF?= =?us-ascii?Q?y3iSsP6jhNEPVx1/LvYHFF2PfVHLpIf8Bo/1qCCgpFjdG4DdGvnshrFBV0eK?= =?us-ascii?Q?MiGfTTX1cyk4yKrkLr5djoBhN/KH38Yuo2B1vykxD2q9Aq1p+V177XL2km1g?= =?us-ascii?Q?YO0JWDyb9kvD3q1i5jVqMqWjEcxZw0OSOW8qbFqEbpwMZqjewrzPMI/jiE97?= =?us-ascii?Q?qAYrJLSC5b9TmmAqoFbxk6U1wOuL4bfrTPms6fM1LRBEbAdH7fDmQdsIv4dI?= =?us-ascii?Q?nscHcjDhq6w7sm3r5aGTT08JI+fgg47gXZs35LWn08oKeD4Yen1Q0rX+Fvl1?= =?us-ascii?Q?EvKIUhYMLtDuSRDcALn+W4nmm4bRZQfymRLF4JlkEu9PxOLOXOb1qBL610h/?= =?us-ascii?Q?OCgRXu3l//TGs3mnR6yMUqOJfkL5Bvo=3D?= X-Exchange-RoutingPolicyChecked: 4LoSZwGOSopRjvuk9BtqVMPeptbaQCknnfCOz8NVlWqmmPs7GIFmALvgo+SEfguZP23cuIotiLX8vKYjJzOaYDrm/N4gsO+j2A4ilSFGF2/90ZQ0jjQQ14dpc/OCnFba3SEWfkwo3EiaqcZvtTNEbKU6povSxX87Vaqyz4shpIWWHIBV0tK7/3orO3iWmYKp/Vx94jdyLwVdo2IJnhcYV/jQ8ME9INx2Zg3RqF7LvG7I+mnWuob0u/QGDDc6oRsSsiGJgv6OlHyJFbY8FoIH0TvWIbB+kKenotmM3ys4JbP726vfAZnmG3v/iWAGE3s7QRQZjhtJ20LCqxPjW3vPqw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5431d887-b5c3-4e13-eaee-08df13dfab79 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:48.8774 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: JhxUdFXErCUb3KfsE/TFBklALqiK9b6XxLos0JG4ZrksHFjcBeqRRLbxgfezCifT/IL61IYBCjG0Q5h0ps0tXT6ekfQH/OpOXRoPF5zkVzc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-GUID: tu4xethUYLRFAEBvP2RqVEcjIzydIsZy X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX+p5bhSY0JrJc 6WtzhaImHAGmjJVp78XM7+XLKedYJVGbeKtN8XzgHvnmlZqw7DvcUcowcspkGIabDWso0JuGjeu zzngcpLJG1KhGMDtDUqsbWFA6WP5oEQ= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX3Z9ESevNqs9W E85FFYt2pPe5Q3rObMJayw4OZYhFOjD87Re3zUH6bjiSMMFCCZeYioK13vvfDkAvYmI5boy04Lv 4Pvvt6fQrAQJa+AubKygMSiUqOMNQJRhEnxFq+ItL4BkZjq+nljK/CuyoHrzsOL/8CtI19Mx1Sz H0mNylMQLwDLgonc6f3PvkpxjiKfsrEO0ao/9sAmm3HgOpJ4lhpzwAGoYQUq4WzYsfCtF8fXx90 FAIy4oyWCIOl6UYx0c6BKb+XPOXTUi2dOzdhStQTCimxKM1F1IvFpIyWOi7g4nJVOdOgPg440qM NFMKv7qlLnWVLf6mD/FW/Ef1hOUd9DTHdAt47/fdMjsgExXm8d6uWZLJlsdH65gFcT4/u1YoWwp nxfp8gSOlG5j6EgZyF95clsPV2MiPWytXo7tQHMtoxvdZe7055uFSefQ/Edq5ZcyDlnWauSkfoo 4Cz0DltuMuR0uobUmzg== X-Authority-Analysis: v=2.4 cv=P46vFSAu c=1 sm=1 tr=0 ts=6aaa735e cx=c_pps a=ijlDDoB9/djO8DkT6Rc3Rw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=SFRUhxsDDi52rhXrSC8A:9 X-Proofpoint-ORIG-GUID: tu4xethUYLRFAEBvP2RqVEcjIzydIsZy X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d25034/1789555555-76CDBA5B-F07488ED/0/0 X-purgate-type: clean X-purgate-size: 4482 The isa_pic variable exists to allow the output to be fetched or read (fetched and acknowledged) from the x86 PIC. Since this can also contain a cascaded interrupt from a slave i8259, switch isa_pic from I8259CommonState to I8259PICState and update both pic_get_output() and pic_read_irq() accordingly. This has the advantage that a i8259-based PIC device contains its own internal reference to both the primary and secondary i8259s, and therefore it becomes possible to completely remove the slave_pic variable. Signed-off-by: Mark Cave-Ayland --- include/hw/intc/i8259.h | 7 ++++--- hw/intc/i8259.c | 33 +++++++++++++++------------------ 2 files changed, 19 insertions(+), 21 deletions(-) diff --git a/include/hw/intc/i8259.h b/include/hw/intc/i8259.h index 24237a4ed5..72be7c3de2 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -6,8 +6,9 @@ /* i8259.c */ typedef struct I8259CommonState I8259CommonState; +typedef struct I8259PICState I8259PICState; -extern I8259CommonState *isa_pic; +extern I8259PICState *isa_pic; /* * i8259_init() @@ -18,8 +19,8 @@ extern I8259CommonState *isa_pic; */ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in); qemu_irq *kvm_i8259_init(ISABus *bus); -int pic_get_output(I8259CommonState *s); -int pic_read_irq(I8259CommonState *s); +int pic_get_output(I8259PICState *s); +int pic_read_irq(I8259PICState *s); bool i8259_pic_get_statistics(InterruptStatsProvider *obj, uint64_t **irq_counts, unsigned int *nb_irqs); diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index ffd09f6c61..3f10777036 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -57,8 +57,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(I8259PICState, I8259_PIC) #ifdef DEBUG_IRQ_LATENCY static int64_t irq_time[16]; #endif -I8259CommonState *isa_pic; -static I8259CommonState *slave_pic; +I8259PICState *isa_pic; /* return the highest priority found in mask (highest = smallest number). Return 8 if no irq */ @@ -175,33 +174,35 @@ static void i8259_intack(I8259CommonState *s, int irq) i8259_update_irq(s); } -int pic_read_irq(I8259CommonState *s) +int pic_read_irq(I8259PICState *s) { + I8259CommonState *pri = &s->i8259[0]; + I8259CommonState *sec = &s->i8259[1]; int irq, intno; - irq = i8259_get_irq(s); + irq = i8259_get_irq(pri); if (irq >= 0) { int irq2; if (irq == 2) { - irq2 = i8259_get_irq(slave_pic); + irq2 = i8259_get_irq(sec); if (irq2 >= 0) { - i8259_intack(slave_pic, irq2); + i8259_intack(sec, irq2); } else { /* spurious IRQ on slave controller */ irq2 = 7; } - intno = slave_pic->irq_base + irq2; - i8259_intack(s, irq); + intno = sec->irq_base + irq2; + i8259_intack(pri, irq); irq = irq2 + 8; } else { - intno = s->irq_base + irq; - i8259_intack(s, irq); + intno = pri->irq_base + irq; + i8259_intack(pri, irq); } } else { /* spurious IRQ on host controller */ irq = 7; - intno = s->irq_base + irq; + intno = pri->irq_base + irq; } #ifdef DEBUG_IRQ_LATENCY @@ -353,9 +354,9 @@ static uint64_t i8259_base_ioport_read(void *opaque, hwaddr addr, return ret; } -int pic_get_output(I8259CommonState *s) +int pic_get_output(I8259PICState *s) { - return (i8259_get_irq(s) >= 0); + return (i8259_get_irq(&s->i8259[0]) >= 0); } static void i8259_elcr_ioport_write(void *opaque, hwaddr addr, @@ -410,7 +411,6 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) { qemu_irq *irq_set; DeviceState *dev; - Object *pic_obj; int i; irq_set = g_new0(qemu_irq, ISA_NUM_IRQS); @@ -424,10 +424,7 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in) irq_set[i] = qdev_get_gpio_in(dev, i); } - pic_obj = object_resolve_path_component(OBJECT(dev), "primary"); - isa_pic = I8259_COMMON(pic_obj); - pic_obj = object_resolve_path_component(OBJECT(dev), "secondary"); - slave_pic = I8259_COMMON(pic_obj); + isa_pic = I8259_PIC(dev); return irq_set; } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:46:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:46:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422671.1648100 (Exim 4.92) (envelope-from ) id 1x6n9M-0001rn-K9; Wed, 16 Sep 2026 10:46:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422671.1648100; Wed, 16 Sep 2026 10:46:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9M-0001rU-EL; Wed, 16 Sep 2026 10:46:00 +0000 Received: by outflank-mailman (input) for mailman id 1422671; Wed, 16 Sep 2026 10:45:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9L-0001iE-BJ for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:45:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n9K-00A1UL-OA for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:45:58 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa735b-bab6-0a2a0a5309dd-0a2a4502b0ca-38 for ; Wed, 16 Sep 2026 12:45:58 +0200 Received: from [148.163.155.12] (helo=mx0b-002c1b01.pphosted.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7365-6ca4-0a2a45020019-94a39b0ce988-3 for ; Wed, 16 Sep 2026 12:45:58 +0200 Received: from pps.filterd (m0127841.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8IwgB639332; Wed, 16 Sep 2026 03:45:54 -0700 Received: from ch4pr04cu002.outbound.protection.outlook.com (mail-northcentralusazon11023142.outbound.protection.outlook.com [40.107.201.142]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqbx0sysq-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:53 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:52 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:52 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=pkJiFODl6b5vPY8FgP6Q0oGKEYfQCpQNYQchDr5v9 co=; b=e9049sm0PfHTdb/e3IZbpZjrt9trDXuLq7dPoe3fpbjxj/anCFZWZKGC/ IxNYIHK57znEpgLL2gvBlq9LpSsdOwZYHbCRveetBHJrQPo6HiQBgDiL5uE/rIOt 3dJw0cwNUQvM360SVben66CvGNt1iPiBhn/666+DdCERXqEgBqw6WyTTmcQBQOKD gkiiAIGd2KE73d9rx3GIWNHXszCOZiuHxX5g9PnpI37yPOFnAv3EWAtfcmEnFq+B zlV48ktvvViYjA0tmIG4hyE3Ub8XrdlFBIQQPjW4QaPnC7I3xwbNejjRaEGD+NKl YRsyO/6dr+mT4zWkId2DbxtxLc7Kw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rY/IzxnfvawlFNkBlpQ8EedVOLOYiA6TurSUrH28gOvHV9G7qPBuNwfbtciQpp6GmJDJfcec5r1A2Uwk5de0t3NNxpQucCyGfwI85VbLk9nwmrPnfz9BvHBlRXjoIiUIulJaS8+HmiOGUQXzHG6zn+9u/14RMNA274qW9J2d9dz1PCvYgjOp/K7DkdqXe1IaK3hy1ZEYirwqfsf6XDGFXH77CFYaT8A7mYmOQ/OZrNYAvFW1L39JJ5OcsogvHbnCNEg1GffhFxDTFdJ017acAzBaplORhRODxHy9a3wmIT02ooNmeCl1CDxRX7N2flOyv5qjHNXzv6eWuuZiVM3jcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pkJiFODl6b5vPY8FgP6Q0oGKEYfQCpQNYQchDr5v9co=; b=lwjvvX1cUnsEg99Jr9blNxLy1sXjPD1OzxfdIzUTIP6F177GA/PbedVXIghBelEBIptzu6DXj/HGPU2bWl2pJA+V6EcNUd+S9WuKXOexXl6zzzCtoSAZYHgYfpbHCpaJ8lv/HSs0/YVsxwTxyNAzmXM1HiPx7B0eD87W4pR5A4vWCP6Eeh8GLltmlnmkqm+erSbJfwztis0OpZZU/m5VVNi1zzZOvzkwzTVJ1dn8c/6BxKeHD+05qWPbiHVIDHCOnj/XNKxCpa8f6D4szZiAsHEY5GbmF1LFvtS5vDYQ3urvBEatzM8aabRhrV1GaR/Gx2zC0QxkyTGQrDX8g6nZbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pkJiFODl6b5vPY8FgP6Q0oGKEYfQCpQNYQchDr5v9co=; b=YPmBrh44ongr2RCK67ATKBA2lSR2kdRpNWV3ZxNXmE8EV2s0orr61mrgzV3ndC6BDvz7m3B5ur65g1A7tbMejiclyg1Ef+Tz35+h4lACqrjJATvFOEqtXzV+hO8uguKod6/MdHbKe6/UvhUdO0iKFO6O50XbY7MfNfmbw2otoKVwmqxSdQgLshPEDu6qWFKGQ4k9w0WnIQmyXbRF8QnC3QJUtp5spF8Xe8dlTGydV0yOt02utmgsQ5aWzsghueC1JVMahGH8g60uWEThwUvLasHHHwwRvKLICX69CXhsP61ed4loy/dg13+sTtiMq+rYkvJt4+FXSBOg290d7xzCug== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 21/22] i8259_common.c: remove static irq_count and irq_level variables Date: Wed, 16 Sep 2026 11:43:49 +0100 Message-ID: <20260916104435.600211-22-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0077.namprd05.prod.outlook.com (2603:10b6:a03:332::22) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: 7324f8ee-bb0c-4930-96d2-08df13dfadbc x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|6133799003|3023799007|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: mny/sBr/FrGXACmPXrz0nt/UdwC9w+7/2ZbBP5GQtLMbTWA0ov4gxTRt9Kpyf6NRnwYxQ5/Ik/aXEdu/Uj9UQWGAZePcYSWfhTxY4WbpGpzbrXucFJmrt3TrOX+cnKMl1r9f5FCj8dv59rFISyeKlPe1tjQtpBcA5fffGpbIht8YuKWE7iMe+qbrLL/D8IEUH+0tZ7NONrSESBbmZRSnGfl8lyZmMuNMjgAnce9wJuZ8mXtc2LUlK5WORvQT0Na1UNjsa6pVcTk3r3o6U17pMR/fezto2RsvfNVVdxUT+O2du8AQ7fln5V7v0G01Xd+87C0TbivwRASZoQx9GlT8ZeUuI/UcWysfnMvE8Qop0tRMLS+YTglw4ydnGcQmnPjr43K+R23fexkruAud6Wt+E17OJxtPB4gOG/P6hJm0cyGdbF3xMdGUXlwED2I19PXeg5h9kV5PcMx6b/bnxb/MFYhMTLE/fdrGlpYrt3Q/7DMqUpF0JhR/Me0G5D9+gb5lDs4vil8QMSNjIYBsCQ5YFbgthZwPPvBQ5fhYjmzA+qrQ7YpFC0/QlLUVa2QAUisbcUhACOjc9RAil/pDFkkkuH0M6T7u8Z8o5p8SlfsSnqG/N1AILi+ytcNcFBjfVcr5+ZmM4WaWuKV3Fhq3E9rsIeNeiRTb02rVKesHH2T1n8k= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(6133799003)(3023799007)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2X9TcRXiJULb99j7T6SQRPC2gtmRqJkHeZXbC9UfcqnS8sx+Ypwcyp8FZXYS?= =?us-ascii?Q?ABMuuwk37B1/8gkBe0LGkZySJ89JvUhsLjaXJ/1mcG+7myZVlFL2/jT108jU?= =?us-ascii?Q?OKjtK6GRxQ2dsVSy6Scx7Cm4a34b3rnscBKXAstHzEpFJmvfplyJbbZCl8Gv?= =?us-ascii?Q?ZVrUMfzF+oUggugqTSw72zW6dGtba5a1DOKczwyP5kp59ORZ/wHlyIPdYOYm?= =?us-ascii?Q?5CyEspxIzjcwSKYbv+ir30oSKdYG3R8i8rzrfDPLGiM2IcqQKAwc6DURIFXb?= =?us-ascii?Q?nU+HX4rRkUrEmCfCvHPDfUxOFyckb3rriznHoxSaZdOgzhqfD0wT8Sz2pvDO?= =?us-ascii?Q?4ylbOMj2nzGyDcHqUR5t3L50YUGvCTbVIyJmRSI/C81lavu+h8fmzVgn1IFM?= =?us-ascii?Q?zL1TVEgtj6mub/nmLZ/KJDvX3+/Trnecb7rQ2Jg5sIyNn38dBjahB30WvPiL?= =?us-ascii?Q?LUMQ9FuUve12fWArvWzvds6+UJL2cOE0enla68Q1Nu4mzNqXpGFTttXcYl6c?= =?us-ascii?Q?z0bYry+poVCpobr/YoNeM1sXUlXjOxJOzhhcHtTFyFoFGcLcF6lMUuIY/48b?= =?us-ascii?Q?spVZBmqN8q0DB5CasgpUJ73Rxec4Xhpv4xVFPIWZ8yq1s33XqddZ7WqxtFwJ?= =?us-ascii?Q?hojQ4m2IYuE1L0owiTR009Eh5P7fiKJiMhZ3s50TUzRB4ZZm5F7ISASWBUq6?= =?us-ascii?Q?Xx0bymFj7erCJrZgUXQ5B/DSwbeXjYRLk9tLKZRyYpr0ZtJi3iX/JBYq2b8K?= =?us-ascii?Q?inSl2YdzbAczMNNEgV1cNMcW6IYaCKIBGShZzMLdTunE+xN4EoqTaDy+W0HJ?= =?us-ascii?Q?XWVe7X20KOVEHzEIS8jdxL7aIwf3wDABFaium71xWZfCq/VNr9ep7DJf7xF7?= =?us-ascii?Q?mSvaxXkfZAsNEvJIh/Jypulqbj/KQKTY0+Qvf9d6eYIVmcA1H8Qbuurf+iwG?= =?us-ascii?Q?9NoIULh3pbX/8zkJh4mvzmSvouKdQMlbIFXHTyXoB8U1SrPBXjt5Mc10LSNG?= =?us-ascii?Q?FnlKEBBcMkV7xGf2zGlPZWPfG+q5CGZScjlD5jdeFSKuT3jUpF2JByZzu4Nx?= =?us-ascii?Q?EwEAENvn28NRJkagv6YILcRlbuwh9Ydu9cCt0id2mwTem19CeNaYEVXLDJDx?= =?us-ascii?Q?eJVRx5eHoYaJF+o5Iw6FuRorE2oQ1kWQe/3FS2yK5C3QLj0EgXKmMG2NQ0q4?= =?us-ascii?Q?wtutMBFgOB4n8aaAM8mr9fer8hx+zoePI3TaXePZYSB2Vli7wwJVAE7/W5Lv?= =?us-ascii?Q?CIeyU6xB6Ba7hv+rVuT5NsSUdPlFCg34UY8qXgjVrut+LP+zPRsX2Cng1Pwb?= =?us-ascii?Q?w+QPuGPjAzIZWeNFMcWpWDZHyubJiepvRAXxPe3g8w2w2jAhLmevZvGyJM6v?= =?us-ascii?Q?ySpTGeS7zTdLal8SbOqz+TYjBEr27iH6srNkee28MQ1hB2Fe9BCKjWinRQ+T?= =?us-ascii?Q?KYWjNOo7Asi0uG6JxSRC/odDcN4M85I5UfFrvyDaVBsboSeZPFazSKsCnQ7G?= =?us-ascii?Q?Te/1/IG+UYK09TgXjLbAzzczdrJHD5rr9XcQ1YURk6tm3NcGbrzEeLRGTLHe?= =?us-ascii?Q?y59HugkI0+2QlbHN6kBmiKaozmHFL5uM2YPFJO4VVn/W64cc1gqLTrOhoNGJ?= =?us-ascii?Q?bV2BXDhABNUyT7b279eC6iKRCk2iQhtexoMBq/Vc8sEYlUVWUAKefyx1T7+R?= =?us-ascii?Q?vxBcpU84mX3P73xIhv8+ZC3mT+j3MFnvtkeo+ZQ+P4R/+JUJ/WuYzfD6VMPx?= =?us-ascii?Q?tCAuwfbQtOWLyom57THudj48mrXNjaE=3D?= X-Exchange-RoutingPolicyChecked: KTivrjYdFvR7SJHrTTBQzO5zaHde9OiVioRlXndUZzYsc9CQ4KNRDFEIoMJPBBdGQbvA/c9RKoVHge2XcgtSW3LxOE864nnbWD4Nhf6ZeEc77PoKt5nTtvRgp9n9sPoX6MoewabeRsALjCdpN2YB3H5PxAAUPlPUK99j8SCJrWh9yAFQG2lL+HzBATwFpIy09ADfz4fpvhaOnfmSBGFf/SpNaCeyqETrzoilx4UFtwHHZ7ANjdNtnVWIT/j6q6tDIBbH1fCeAL7c1ONutkOyZDEQYzshOwaz0V+MpU86h4byZI2BxCEeUzmInw1kgTNk+eGgv5EKp5Gdu1tM9nDGgw== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7324f8ee-bb0c-4930-96d2-08df13dfadbc X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:52.6825 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fSxUaaZf+rCVhXhIsmBB4cJg6SsDwqqWoeVwkOEUYYlsbMyXk9WXDqm5UIDfJcadDc76n9ijQFtb8p4GMg/bHZfOTEe2M4wUycvJUBlcADY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Authority-Analysis: v=2.4 cv=Xq5vqlF9 c=1 sm=1 tr=0 ts=6aaa7362 cx=c_pps a=nzP3m+/CqRdBhj8fzGTHBQ==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=jxMXjlTPpCISP5mWtjnE:22 a=64Cc0HZtAAAA:8 a=KJqig-R1GVLqmjI8InkA:9 X-Proofpoint-ORIG-GUID: WfxuQKVPr1TjN3bNhFd63-_04f_peMQh X-Proofpoint-GUID: WfxuQKVPr1TjN3bNhFd63-_04f_peMQh X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX5UNtd2mNsJum XxPo9EBN659z2gNVDxbcWR9b4FW+aTQPHhrSycdSTvKg/6vxyMmYwJSObgfzewZJP9PiidJ89S6 692RIxLRpfIq9loS0TtKWqkiv+hevcU= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX7MOwfRkdisx0 bjEnOu6jpiYP887LHQj9oYMyv5JwN3ofpx0aVnzUy7X2m4khh+fwq0etKCMQ8SNQbcC7unWMOVJ mMgTyDI+PMJLuCHbdcFo95VRILXapfrEAUiYYyi1mnsUKH8OHYDwTNPuCofBJmq+jjSeqMxw3i5 fQd1x5raPK/EatgA2L0jTc9JpYaeU9D1a2l9/8WyIX83+spH1L1szQApbg4uC9PrNRGOvyXOS1Y PbfYRwHULsUcc36bZUeFxME25LSOjAL7G4y4tjHfeEFr4jqiMx5RdD6P/Hz5MXqeb1Olw1Ob/IS UIHhgmbf6tX8WnMz2vbSsafH/A3UdocCmmIw4LiibB/lReUzQMR5mQaXyFVTi2yDePbF+jcPTVi hYc5mCeDGpVigdlfD3Ue/FMGQlEfmgEG9y6ydcU5IdV0sA0bsLZBIQ6RvfhFS802t4PxTLlxpUU yeGZ2YvKI1Sb8FdrI6Q== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-720697/1789555558-F0AA52AC-A8EA178E/0/0 X-purgate-type: clean X-purgate-size: 7331 Adjust the parameters to i8259_stat_update_irq() to allow passing in pointers to the irq_count and irq_level arrays, and then move the arrays into the corresponding i8259 PIC and KVM PIC devices. Doing this allows the statistics capture logic in i8259_set_irq() that handles incoming cascading interrupts to be removed. Signed-off-by: Mark Cave-Ayland --- include/hw/intc/i8259.h | 3 --- include/hw/isa/i8259_internal.h | 3 ++- hw/i386/kvm/i8259.c | 20 +++++++++++++++-- hw/intc/i8259.c | 40 ++++++++++++++++++++++----------- hw/intc/i8259_common.c | 21 +++++------------ 5 files changed, 52 insertions(+), 35 deletions(-) diff --git a/include/hw/intc/i8259.h b/include/hw/intc/i8259.h index 72be7c3de2..2efdaaca2b 100644 --- a/include/hw/intc/i8259.h +++ b/include/hw/intc/i8259.h @@ -21,9 +21,6 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq_in); qemu_irq *kvm_i8259_init(ISABus *bus); int pic_get_output(I8259PICState *s); int pic_read_irq(I8259PICState *s); -bool i8259_pic_get_statistics(InterruptStatsProvider *obj, - uint64_t **irq_counts, - unsigned int *nb_irqs); void i8259_pic_print_info(InterruptStatsProvider *obj, GString *buf); #endif diff --git a/include/hw/isa/i8259_internal.h b/include/hw/isa/i8259_internal.h index 53751b045b..53d8e087eb 100644 --- a/include/hw/isa/i8259_internal.h +++ b/include/hw/isa/i8259_internal.h @@ -72,6 +72,7 @@ struct I8259CommonState { }; void i8259_common_reset(I8259CommonState *s); -void i8259_stat_update_irq(int irq, int level); +void i8259_stat_update_irq(uint64_t *irq_levels, int *irq_counts, + int irq, int level); #endif /* QEMU_I8259_INTERNAL_H */ diff --git a/hw/i386/kvm/i8259.c b/hw/i386/kvm/i8259.c index 421c9279cd..ca661afc02 100644 --- a/hw/i386/kvm/i8259.c +++ b/hw/i386/kvm/i8259.c @@ -30,6 +30,9 @@ struct KVMI8259PICState { ISABus *isabus; I8259CommonState i8259[2]; + + int irq_level[ISA_NUM_IRQS]; + uint64_t irq_count[ISA_NUM_IRQS]; }; OBJECT_DECLARE_SIMPLE_TYPE(KVMI8259PICState, KVM_I8259_PIC) @@ -102,6 +105,18 @@ static void kvm_i8259_put(I8259CommonState *s) } } +static bool kvm_i8259_pic_get_statistics(InterruptStatsProvider *obj, + uint64_t **irq_counts, + unsigned int *nb_irqs) +{ + KVMI8259PICState *s = KVM_I8259_PIC(obj); + + *irq_counts = s->irq_count; + *nb_irqs = ARRAY_SIZE(s->irq_count); + + return true; +} + static void kvm_i8259_reset(DeviceState *dev) { I8259CommonState *s = I8259_COMMON(dev); @@ -114,9 +129,10 @@ static void kvm_i8259_reset(DeviceState *dev) static void kvm_pic_set_irq(void *opaque, int irq, int level) { + KVMI8259PICState *s = opaque; int delivered; - i8259_stat_update_irq(irq, level); + i8259_stat_update_irq(s->irq_count, s->irq_level, irq, level); delivered = kvm_set_irq(kvm_state, irq, level); kvm_report_irq_delivered(delivered); } @@ -210,7 +226,7 @@ static void kvm_i8259_pic_class_init(ObjectClass *klass, const void *data) dc->realize = kvm_i8259_pic_realize; device_class_set_props(dc, kvm_i8259_pic_properties); - ic->get_statistics = i8259_pic_get_statistics; + ic->get_statistics = kvm_i8259_pic_get_statistics; ic->print_info = i8259_pic_print_info; /* * Reason: must be wired to the ISA bus via the "bus" property diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 3f10777036..ac43995ce4 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -49,14 +49,16 @@ struct I8259PICState { ISABus *isabus; IRQState i8259_primary_out_irq; I8259CommonState i8259[2]; + + int irq_level[ISA_NUM_IRQS]; + uint64_t irq_count[ISA_NUM_IRQS]; +#ifdef DEBUG_IRQ_LATENCY + int64_t irq_time[ISA_NUM_IRQS]; +#endif }; OBJECT_DECLARE_SIMPLE_TYPE(I8259PICState, I8259_PIC) - -#ifdef DEBUG_IRQ_LATENCY -static int64_t irq_time[16]; -#endif I8259PICState *isa_pic; /* return the highest priority found in mask (highest = smallest @@ -123,16 +125,8 @@ static void i8259_set_irq(void *opaque, int irq, int level) { I8259CommonState *s = opaque; int mask = 1 << irq; - int irq_index = s->master ? irq : irq + 8; trace_pic_set_irq(s->master, irq, level); - i8259_stat_update_irq(irq_index, level); - -#ifdef DEBUG_IRQ_LATENCY - if (level) { - irq_time[irq_index] = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); - } -#endif if (s->ltim || (s->elcr & mask)) { /* level triggered */ @@ -209,7 +203,7 @@ int pic_read_irq(I8259PICState *s) printf("IRQ%d latency=%0.3fus\n", irq, (double)(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) - - irq_time[irq]) * 1000000.0 / NANOSECONDS_PER_SECOND); + s->irq_time[irq]) * 1000000.0 / NANOSECONDS_PER_SECOND); #endif trace_pic_interrupt(irq, intno); @@ -439,10 +433,30 @@ static void i8259_class_init(ObjectClass *klass, const void *data) } +static bool i8259_pic_get_statistics(InterruptStatsProvider *obj, + uint64_t **irq_counts, + unsigned int *nb_irqs) +{ + I8259PICState *s = I8259_PIC(obj); + + *irq_counts = s->irq_count; + *nb_irqs = ARRAY_SIZE(s->irq_count); + + return true; +} + static void i8259_pic_set_irq(void *opaque, int n, int level) { I8259PICState *s = opaque; + i8259_stat_update_irq(s->irq_count, s->irq_level, n, level); + +#ifdef DEBUG_IRQ_LATENCY + if (level) { + s->irq_time[n] = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); + } +#endif + qemu_set_irq(s->pass_irqs[n], level); } diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index 7980f86f1f..3511303c21 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -30,8 +30,6 @@ #include "migration/vmstate.h" #include "qapi/error.h" -static int irq_level[16]; -static uint64_t irq_count[16]; void i8259_common_reset(I8259CommonState *s) { @@ -89,26 +87,17 @@ static void i8259_common_realize(DeviceState *dev, Error **errp) qdev_set_legacy_instance_id(dev, s->iobase, 1); } -void i8259_stat_update_irq(int irq, int level) +void i8259_stat_update_irq(uint64_t *irq_counts, int *irq_levels, + int irq, int level) { - if (level != irq_level[irq]) { - irq_level[irq] = level; + if (level != irq_levels[irq]) { + irq_levels[irq] = level; if (level == 1) { - irq_count[irq]++; + irq_counts[irq]++; } } } -bool i8259_pic_get_statistics(InterruptStatsProvider *obj, - uint64_t **irq_counts, - unsigned int *nb_irqs) -{ - *irq_counts = irq_count; - *nb_irqs = ARRAY_SIZE(irq_count); - - return true; -} - void i8259_pic_print_info(InterruptStatsProvider *obj, GString *buf) { /* No information for i8259-based PICs */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 10:46:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 10:46:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422682.1648110 (Exim 4.92) (envelope-from ) id 1x6n9R-0002Sm-8P; Wed, 16 Sep 2026 10:46:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422682.1648110; Wed, 16 Sep 2026 10:46:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9R-0002SQ-1P; Wed, 16 Sep 2026 10:46:05 +0000 Received: by outflank-mailman (input) for mailman id 1422682; Wed, 16 Sep 2026 10:46:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6n9P-0002NI-Jc for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 10:46:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6n9P-005QYS-09 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:46:03 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7363-8faa-0a2a0a5109dd-0a2a450c9f74-22 for ; Wed, 16 Sep 2026 12:46:02 +0200 Received: from [148.163.151.68] (helo=mx0a-002c1b01.pphosted.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7369-f479-0a2a450c0019-94a39744a6da-3 for ; Wed, 16 Sep 2026 12:46:02 +0200 Received: from pps.filterd (m0127837.ppops.net [127.0.0.1]) by mx0a-002c1b01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68G8j54T700548; Wed, 16 Sep 2026 03:45:58 -0700 Received: from ch5pr02cu005.outbound.protection.outlook.com (mail-northcentralusazon11022122.outbound.protection.outlook.com [40.107.200.122]) by mx0a-002c1b01.pphosted.com (PPS) with ESMTPS id 4gqa0ka9yy-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 03:45:57 -0700 (PDT) Received: from PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) by PHXPR02MB11343.namprd02.prod.outlook.com (2603:10b6:510:3cc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 10:45:56 +0000 Received: from PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250]) by PH0PR02MB7159.namprd02.prod.outlook.com ([fe80::8e97:bc32:822c:b250%3]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 10:45:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=proofpoint20171006 header.d=nutanix.com header.i="@nutanix.com" header.h="Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector1 header.d=nutanix.com header.i="@nutanix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= proofpoint20171006; bh=JTc6OttRkqFr2IJN61bUNmzaH+my9K//Vu9fu/m3Z Oo=; b=HPSF88vcHpu7V/6CCbEPY0gTGaylMCyFJnShtb5Us1jBlFEwmLF9UF7fT dXsTg9f6OIrEibOZ4HSP6i/tpZFQX6CO16VxXk+Czc09EhoBsTo+imeyPx3ewVHl Na56EQeUQ9Uh4/vorX/WdeUhulUj0GtvNEYRDKXzyR96rXQtbEJz1KZNu/foRSSN ukkFP5u+gGRhOvMMvI1c4gPQmR7eXvfskk/i3pLAwU8XE+nMVIkMAWLIm0pdZOld cMVReFQEq/7o6FAIk7Pts7/owFv15049fuWXECv0SifZuwslkOGh+ktFTjawWpY/ l+/dAmQDooIHRsEEQ89vlh5mu18LA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GWBUpy6cJOv/8rH4IrKRao34eGCsqct/+iCDZM9JNMAxSmJF1a0LqXul+2BdWXURctViicXLDdoGRHqM940YI+uxTOeD8ohB3VOSqUCMxF0YZsq+FGQ2fw1VEqsCWIzB6Z1hczCVwhDCMtIk2hAWfao0tSsKC5jYvDv9inVCClpl1aWXg+hWXTls8C8waV01woEvxYrqKmaAtzT0Cgdj6E4xs2fzKGhV+LnsFNRw9zrp5zs6R1EfljfSOZQKcppJxUTcc7+D/b4+WQz6bOGOhKlaTLe+htC38ysbbVYCLs0kWkSZfYCOTYN5it3EodCfGTy7h3hq17A9rHeDEz72UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JTc6OttRkqFr2IJN61bUNmzaH+my9K//Vu9fu/m3ZOo=; b=VvDbG8iywoiJWTfQkfw6b4ogjC42TCswTdDfqaDkLw/NVSXLZ2iwyHFHYtluE/fHhiE7EuIuEs89nTltfhvd0w0BZBHYH/1Gu+HjmM0Hz0hKNnGqJ89qKfXm2wyP7SPc3lcvwUu4bCCfjVvJG8IbOO3qq0EiOPcpz/WtIb4B8ERJHDsVXzqiQiAFUqtJ1iLCDz+JFfZ1mQv06VXdOIkCT+K6dPdTAXXVe5lZ+zyP92sc5uoIdfC0StOk4vDMv61LvuxQf8msDqPKufsrhoMqk8xTW6+HcVgjjxs2w/WwtSg7w5rfwFfwfAch3wjXSQu1NKcpbDlQq9WZ3DlgSnPmfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nutanix.com; dmarc=pass action=none header.from=nutanix.com; dkim=pass header.d=nutanix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JTc6OttRkqFr2IJN61bUNmzaH+my9K//Vu9fu/m3ZOo=; b=iLm1wj2oLJHdcLkjedcYjgWDcttr2XQEu2rdQqgZhTYtBSE9WcEg9JRuOme939+lBNYCxy2WYKW83Q7U57yVWEHzjVe+awcANQo5wqx10iqTkKNtKTD4GCxRLEqfG9eOdYsQK/pEuzDrJO1PRQ4j49ZxVYQh+wWlC8o2SNNi6JcdhDXLiC04KswPtyNLLH8xCBGxnGqhKiAgtIjyigDbrZ3ecy8zGjCyvLtvFFPz5X6Ct/8lVwPStRZWOD/HR2QRfDXSAQ3zOo2bJrl2rVXeYuzd1CpCxRomMvu6pf0gtaASqRFoRxvbV8wiJ+dZC9VXJXzFLAFAJSOEVS6c5rUUlA== From: Mark Cave-Ayland To: pbonzini@redhat.com, richard.henderson@linaro.org, mst@redhat.com, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@gmail.com, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org Subject: [PATCH 22/22] i8259_common.c: add missing 0x prefixes to "info pic" output Date: Wed, 16 Sep 2026 11:43:50 +0100 Message-ID: <20260916104435.600211-23-mark.caveayland@nutanix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260916104435.600211-1-mark.caveayland@nutanix.com> References: <20260916104435.600211-1-mark.caveayland@nutanix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0074.namprd03.prod.outlook.com (2603:10b6:a03:331::19) To PH0PR02MB7159.namprd02.prod.outlook.com (2603:10b6:510:16::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR02MB7159:EE_|PHXPR02MB11343:EE_ X-MS-Office365-Filtering-Correlation-Id: b282492a-627a-4b7e-460a-08df13dfb024 x-proofpoint-crosstenant: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|18002099003|3023799007|10067099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: o5fIuqwFZ6u2uLBnHwEQkkattin1LC/NI8LYF1LAGWQPhnYmafuQ/2ayPYEd0yxY40fO9ol/5nv9gnr+urPQtkaDyCsvFD+r88NLjAESze6AzOtldEvUsDrmxhJlP/WeYL3rGzAk0J06wsx/d7IESxWDKQ/rNshi4ufhBrmc9uymQbi9xZ+13nE/9ZLUxKLAAQaF04WcV1ozNn9JjTD22RUN1lJbYu3p9QyjybnLJWNhB6+zdCBSz0Pn3GyFr9hkbakhrYKRtb05H9z9xa5qHxrgXKspvtj7nz1is9XZjoffIggDEIHJJCRg+AsHkkeRT2y4B4U7Q2AVtwc3HqYxqJcB5IH1ABn6YAOad/CeLbDmVCExxpg0XUmyPnkZ2EP5L+512KHaZb3BFRBOPlSWyGH7YGcces8gKpdvMmGJL3dBZdKU9i7AuQuwRATZKVPLi41x788x6BsIuQFNaCl7Gh3btyTy6WjdykWMG/f4iFbwnj+tI+89zrIdNUWMYptYbWtkh7SgyOPAJr33zsA8vEtllF9VGKhKEQjobxa9Tk16U5CRmhJDssGI1hGjQH+Ktpf+UtGram2hH7pOs8R0Pc4TUDTv+o7Vtw8+yCSFkp38FhOXl+YsigHEMaIhwCQ8gHF0KGbJyjOQXYN/fxAJBo5cPoMlt2eVxDreqKv0YJg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR02MB7159.namprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(18002099003)(3023799007)(10067099003)(56012099006)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?eCw1hWh2Qh3daljCkUA8m1AsNubDKl1vUdFi0U4rndIZeak/ypnCLW+GjyON?= =?us-ascii?Q?fDNZtZw3CyX+wo4d7U+wWKaLpfP0N+iv6HzvxZG6Xy2i1yFH/SDtwGkMipEs?= =?us-ascii?Q?sDJHT4vgxddJmKXjEHrjacWG6rI09l9nYVF7Xiqq4xcEDX46yfFB9xXPKFXK?= =?us-ascii?Q?4E8FGYv/Vq+tTTAW7n8jzjWjc20a7hBNwOGm1yvnl+Qsmzra+DA0iof4+HwN?= =?us-ascii?Q?/cwfqe0sImMa4PshlofRih4Hsbrlu2P2pLVbjbU5n4uGnTOYDbOvIwui19um?= =?us-ascii?Q?uuWHR6qDGSTG6QgYpEbUWZjgNVM+2IMeLrS8UsW2s84/Fz3+brZq55/+NYGs?= =?us-ascii?Q?PMpH39DWZWSJYvxlC8V11dYdeUVJBRZSZhVKa5Yo3gnpjGJr1jgIBC50YMXF?= =?us-ascii?Q?ORankv1NgDZexVF0Jq7JbwMjby01f0mkb/wpGj8Kk+SYV2DS3gCHGpY/y0jy?= =?us-ascii?Q?17FN+8aqpXsK0JTuVUD0KI3gAEAYcA/fNYKm8iDbrkI2oCCR/qYIg4BKydvb?= =?us-ascii?Q?l5KCNvo50fgja2rFyukWJqQezcJ84KFk8vdVHa++6zKbnwedMOB/zzcJ0mEN?= =?us-ascii?Q?JOqRWvDWIbcP5hz9ejtx/6bFT1JEQtdbh+lbGALQr6+KwkjEgBdTvg+jHVh1?= =?us-ascii?Q?Bdkg9UMWhJ+4VzjXE28STL95BgrvY9ChFOOHkQMdzgSao/Bh2beBuvCXSVbm?= =?us-ascii?Q?M4G1fkcGk3sHj7HiRRJNGBRxCvgFtKSTMSNr+P8lIP6OM725aceMY8ZZnCBs?= =?us-ascii?Q?l4ouMcVYWwxchhTsyGlZ82XXbdXka8xpgN49qdn4UY4tE74YwneO8n33BD++?= =?us-ascii?Q?Jq9VZ8bDjgpxtJM5OsPSQHxGLHdwWWqpR0XBx6d1RzVyKhmG8cpiPcp3kES6?= =?us-ascii?Q?y/q84v/j/0la+ii70kcaHThlqHEQSeD07VfHPjztOMGXeGwFdjD0jIZlx60M?= =?us-ascii?Q?9xUMsIHNnW+B5ii0XSjc7UqqSH8xWVaAXPRu5vji9wAiMXJ2/9TRfI/Ys5Qv?= =?us-ascii?Q?Toj0R+yAcBOu1iO5YIzHMbq/8Knqr+wZQKs0KUF5FsRkcWZGxqf05BXuEB5s?= =?us-ascii?Q?6x7lUBjEhJeagCt84g/SuS5wfO4lgxcbit+8bNodbQnaJRsZwB0IxSJTPdde?= =?us-ascii?Q?rV/T84WB2BdiQ4O7rT0G12+Ff+4BJlW+ACt6B6ZgzuR1Oda1OrB3B4Ri0iff?= =?us-ascii?Q?zYJ9rmcY2jMcWUgX3p7AtZDtN8VZBrXfNiJ9hbirVJtKJMkS3bOtoP8au53/?= =?us-ascii?Q?T71YbvxHWJgGX5e8DRA2uwTTDORA0Kl9nhQ9+X6jGPK0GLuMXx6FG4fqtTgY?= =?us-ascii?Q?AaxDzvgN7MGmyP5xIZygl7APS4f4MnrMvAlzNU0F1JHMk2D0FDD+HmdC0FnB?= =?us-ascii?Q?Ksg32eilX/oy+BzINuyLdi5to1sQI9/KuJOUeZjh4rQ38IFWtiP+dE7WbqrV?= =?us-ascii?Q?+rjZnWSaYPd6mQ01yAylmTK1FW28uiJ/31EU/5mc+O68Gtw5KPONkgmMn/Mp?= =?us-ascii?Q?W8BlEcF1v5c49DKtVcoj5qBEmQ5Dx1RTsygGhZhKlxE2/4b1nTfwnZC7v++W?= =?us-ascii?Q?TNtr16YoYK13U2FVi4cbfPe6VugqtHHp7Lv4aR5tIcxVuuySDxs43ZOaeq0f?= =?us-ascii?Q?7ihM6YhEuRtyXhGIw8vnPbclLILKkBiaqpONTUhqoopSo4V8W0UK4hm/qIxA?= =?us-ascii?Q?BEekkOfj2xKktU8fwD9Ayc3DqFBBz8wfsYvnplruj4/tnUHw7czxuz8iI5AI?= =?us-ascii?Q?/4BJL/dxFMfBx/EFTRP6Gh1Sl3jxbNI=3D?= X-Exchange-RoutingPolicyChecked: UVopdt5oxqgddegIluQzc1POBGWpGLLlOgrj/UBD+y5nszAu7D5M4JxxH2+cyepGzjCNr7In9eq+hAeNPt4/JEF72BBwznf8N/peTHytsz6J74SllwkbbLJaWqVltpCVaM69q8RvQLKC6SX6HswXhi6q/ZaJ0ROh33Gfay5VrpmrUSiFJl+gK1FiX9hjMve4jF+8CQvH7MzwyCSxPQVPf5ks5ofqE4US2mgf5TrCzZ6Q7Qm04mufjikHMgAQAMuXvZKuDYU62Q2V7d7if2EniCWjmRioD7uojqAOhwMBBQ9fzyNQRgOktF8l0Db5QgHzXpykxTs2vhwG9vXTKjIQrA== X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b282492a-627a-4b7e-460a-08df13dfb024 X-MS-Exchange-CrossTenant-AuthSource: PH0PR02MB7159.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 10:45:56.4409 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7RSu3+crYflFY0p8Nw54PssXWVyLZaZ1UqrFM1v9ctcvD3rwNyug7WmrMtjKEJ8yuortByDYmcoPsNYN1VYocNFQknDlpoGpzG/Sv+EWioI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PHXPR02MB11343 X-Proofpoint-GUID: SkqHOwJ-R7bjBoqc8w8XNeV6j_Zkt_z6 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX7BVlohr3YCLU 9smf44hdQb7QhqOzM19zvNIbYsTMLcpXN+LZw1un/gs3w7rAs6mhu5aUHsaclUupk87JrAIAv7m rtf+sIK5e8tvikI9Ghh/cXZaeIQBA/M= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE0MSBTYWx0ZWRfX61FSD+DTlV+h 2QIuL4OO/xAtIB54PnCW0pHxszWMPxXGpz1xLHM1h5aaIao56ll3Kg8eK+SjQCHY1jhvjwMRgE7 0BD8fSDiNIhVTMGA2TDpP+s49jERuXextxEJqCi54GLhYXe4LKq0csIU4aiESsjkPHxfx6NLJZk c8MIAcKLbm1gQWm/O0gc0KKJJgL+FqOWvEGti8/lj+2D97HfdFY/xq3vzq2QLB9GGIngCcn1pbi 7UGO4ztsBIGSpy1qxczzbybzzoNwvnImeJ2c45PbGZwgeo1QO0/M3fxRQozFQaCLG4yL0goyeVD FQ0aa50IygeRQFJ0lryfDtb2Z24NkHbARhAlVFy/IpYP9jwLqVP3Gh3fkhHqcHfWKLpfOaIcl2K rRr+tMnVvvoJXcvrm1h52wmpxy7HRUQAE9TDiU1G8u+gF5LNl76EnneX7fRQEGwxMo5wPgpKmsS pvEsLyTa5uhvnpylm8g== X-Authority-Analysis: v=2.4 cv=P46vFSAu c=1 sm=1 tr=0 ts=6aaa7365 cx=c_pps a=jsJx5cRpnMcsqjM19+T+dw==:117 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=0kUYKlekyDsA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VofLwUrZ8Iiv6rRUPXIb:22 a=Ap8k9tRZuQ82DLYWQqG7:22 a=64Cc0HZtAAAA:8 a=ap9nPAedobMI28Fi-wYA:9 X-Proofpoint-ORIG-GUID: SkqHOwJ-R7bjBoqc8w8XNeV6j_Zkt_z6 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Reason: safe X-purgate-ID: tlsNG-d25034/1789555562-014C7A5B-B28A8292/0/0 X-purgate-type: clean X-purgate-size: 1136 This indicates that the specified register values are being output in hex. Signed-off-by: Mark Cave-Ayland --- hw/intc/i8259_common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/hw/intc/i8259_common.c b/hw/intc/i8259_common.c index 3511303c21..64d6f3e959 100644 --- a/hw/intc/i8259_common.c +++ b/hw/intc/i8259_common.c @@ -119,8 +119,9 @@ static void i8259_common_print_info(InterruptStatsProvider *obj, GString *buf) I8259CommonState *s = I8259_COMMON(obj); i8259_common_dispatch_pre_save(s); - g_string_append_printf(buf, "pic%d: irr=%02x imr=%02x isr=%02x hprio=%d " - "irq_base=%02x rr_sel=%d elcr=%02x fnm=%d\n", + g_string_append_printf(buf, + "pic%d: irr=0x%02x imr=0x%02x isr=0x%02x hprio=%d " + "irq_base=0x%02x rr_sel=%d elcr=0x%02x fnm=%d\n", s->master ? 0 : 1, s->irr, s->imr, s->isr, s->priority_add, s->irq_base, s->read_reg_select, s->elcr, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:35:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:35:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422815.1648119 (Exim 4.92) (envelope-from ) id 1x6nvN-0004dO-Os; Wed, 16 Sep 2026 11:35:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422815.1648119; Wed, 16 Sep 2026 11:35:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6nvN-0004dD-JS; Wed, 16 Sep 2026 11:35:37 +0000 Received: by outflank-mailman (input) for mailman id 1422815; Wed, 16 Sep 2026 11:35:36 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6nvM-0004bw-0q for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:35:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6nvK-007kMV-Fd for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:35:34 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa7f03-bab6-0a2a0a5309dd-0a2a450ce87e-20 for ; Wed, 16 Sep 2026 13:35:33 +0200 Received: from [52.101.57.31] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa7f04-f479-0a2a450c0019-3465391f34fc-4 for ; Wed, 16 Sep 2026 13:35:33 +0200 Received: from BN9PR03CA0254.namprd03.prod.outlook.com (2603:10b6:408:ff::19) by DS7PR12MB5718.namprd12.prod.outlook.com (2603:10b6:8:71::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 11:35:26 +0000 Received: from BN2PEPF000044A8.namprd04.prod.outlook.com (2603:10b6:408:ff:cafe::82) by BN9PR03CA0254.outlook.office365.com (2603:10b6:408:ff::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 11:35:24 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF000044A8.mail.protection.outlook.com (10.167.243.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:35:24 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:35:24 -0500 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Wed, 16 Sep 2026 06:35:23 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UijxvMgJUc1Cdm1VX5c/02X+1e0tUKjKB/XAVLdlcCHQ+TCQRwjOZd5Civ3QsluqEoBUdljs1veTvAIrMVV+j1Hyq9SJ4cF8ejWmmhS6QhS8EJZRKKo2Lh/R25jHik3uerpqH7tuGoGFqWUQoOpBpx8U6sFDplV7xzPIAuGLStDDVW1o2W3Ld7VBWWwfqvYzxZpFFibqp5Kh+9kEjKlaJwrpyh/vy0WcuzqLhmNRhUzntmE5rR4JaBDUW9T1iVC/OGwa8c//M0Cbby/Lv8xzJ/an6ANHi/ScQ7ksshhKtB+d5q1Pm+Ezg/sbtbdKL9YFPwEHql2nyDLWIw1NLSwJRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xrc0yfbW430zJrQysRPIrSUuJKNogQEEXYt7wQuJzTk=; b=iAQlXARduT4k6FAWlzOWYAgRihEHESmtn5JgBh7dYYlwOVVfQNbOD7CUqVk5P8hiDCoxc9W5KRZLjXw1C4aZVZR+dmh9603gQtoxeUJKHwa9HUmU0CX4vl8wgaR/i1VJpYDah0KFLrJ1xp2sCSU4sYAIoWvWY7GQLqlesYXBtREmNfI/An5pnN9qNyZMQ/JC/gK94dxPVdKj5tGjO1kYqgpZld9u5sdsTze7tiTl8AwMs3R/sCD1bdND4NmF6F5ssLK16wWg4o0P5euVKDcPBMqIwg4/XuwXzSYjRNqvwaKzFH2Q0CVcOOKsG2AvSRLHecz9fB1fyUn6KeEWfYXOaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xrc0yfbW430zJrQysRPIrSUuJKNogQEEXYt7wQuJzTk=; b=SFobVkwRy1qKmtXgFCEbSeRkrKpHXfl443wq+ZdLXzDebP8YI4iUKM1hWyGa2GroeAnaZGd/+lPx6e+KPOkxbsAsYGrx80YdRHVfeD4s1FzIf0Y0o+t+X3Xum3zFimdcBCZqzOrLbRZGn7SiAvT7HnWU3XpTje9wtj1rfjvk0zc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C From: Ayan Kumar Halder To: CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Roger Pau Monne , Doug Goldstein Subject: [PATCH v4 for 4.23] Add GIC SGI boot/self tests in Xen Date: Wed, 16 Sep 2026 12:35:20 +0100 Message-ID: <20260916113520.3870182-1-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A8:EE_|DS7PR12MB5718:EE_ X-MS-Office365-Filtering-Correlation-Id: b078d290-02fe-4873-2f1e-08df13e6996b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|7416014|82310400026|376014|1800799024|11063799006|56012099006|10067099003|18002099003|6133799003|3023799007|13003099007; X-Microsoft-Antispam-Message-Info: /NsNvaSuCNqTkGlCegv4dF29jzmiaA8Ha0I8c1+N5pRgzqR8Xs4zBpX/pOICk1X10kLI622jWz+QBYpcVfkZpHDASxSqD11Htq03vJ56fFdzA5xneXg9Q8Ynw+ARy9G3h09ZElvBWGcyI78nNpLbbs3q1NxSZjmx2ZXIuDUufbD/OXbNdEZjxMKK3HnyzISGCy63fDsLh7oeRtgoMpGUP6U5EuUsi9WogSQUG+rNguzxCEOIcNoowJOuDCPrfpsuB7OcmpdI+3NOZRtEYrD7gRgy4A/cyfzzWGNpa4Cr/8elu5h/B9bQXZr/qKYqdRUTWvkhBhyizmWn3wfzV1MxVd/Oid/SBjlWTKh/518jjAgzssnSayW1Pl/Dbd+nKeRw1/8/j3J/1hc5pS/lIgNPA89RCI3K7jqeZeqe2YuX6ZKyX1HbwArBlYJm2Roca/GEOdsBnfxB4yq+vlZboEBZYeeGXjnFtUZL4V0aPJhQJ9sAe7PYmu2dtg5cpOq+190PSYF53x7E+hrwwjfixyRqoZkpdD6JO6OKsoHOySiFuugFYfON4Ce/0NMEcjxsxG7R+nIdiveB6tXCgelTw+Tkr1nbLPGN7SXDuXqO/Hb2Q1hpk2yKZZLQUVGsucI9Ls7ka1Fz0bPzKiXG6BTkxGppkw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(7416014)(82310400026)(376014)(1800799024)(11063799006)(56012099006)(10067099003)(18002099003)(6133799003)(3023799007)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: FRG4pgQuR+NHZVva3sqosX/VGPIyOZXl40agbowTCXKXP24DOY/AU3HlpFttDEqTMF8u37lT5z6tc6gJDtaA8sv2o/tvqfqo2KCBIMSmwyVaASVOGjg61Z5G86jlIieEBWt1hnoeT/RC9zUSCzDAMHhYJKXNG9cgzWAjERdCeRE4j0Z45lKvUqRWfjXwvLIs9P2HIJkYq+3MpG/5L9BakaZibQSurLCXab6O7YzbGhNuKVvsL9fqG5xMmwkAQiErnomga3TxOFOUhgyDfZlwfsedQ7U4RHUtTR9HS0PrxnFsu5ofuWxJtbhp80hIrClD96ctFNsFK9BwFhAM8c7D1n9se9+nTMv/KTKOJiMK5Mrm/0GcaG70VzowI6aYiSx+E6Tjfthb4dg73A6arYR3A0KM6cCAivwngzxgmzIJ6kl5S2Ok8W7UPWlPFe/vMJ7r X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:35:24.6840 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b078d290-02fe-4873-2f1e-08df13e6996b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF000044A8.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5718 X-purgate-ID: tlsNG-d25034/1789558533-024DFA5B-31BE9BA7/0/0 X-purgate-type: clean X-purgate-size: 16383 Boot self-tests (also referred to as boot-time tests or power-on self-tests) are intended to check that Xen has configured the hardware correctly before bringing up any domains. Introduce tests to confirm that, using a dedicated SGI (GIC_SGI_TEST): 1. A cpu can send the SGI to itself 2. A cpu can send the SGI to another specific CPU (CPU0) 3. A cpu can send the SGI to all the other CPUs Each CPU counts the test SGIs it takes. A sender samples those counters before sending and then waits for the count of every CPU it targeted to change, which is how it tells that the SGI was really delivered. The counters are never reset, so comparing against a sample rather than an absolute value keeps concurrent senders from disturbing each other. A test reports a failure by panic(), so Xen never continues on a platform where SGI delivery is broken. When the tests pass, Xen carries on booting normally. Also introduce a config CONFIG_BOOT_SELFTEST which enables these tests. It depends on DEBUG and is off unless explicitly enabled. Also introduce a boolean command line parameter "gic-test", so that a build with CONFIG_BOOT_SELFTEST enabled can be shipped but the tests selected at boot. It is documented in docs/misc/xen-command-line.pandoc. In order to keep all the boot self-tests together in the binary, a separate section "initcallboottest" is introduced. Tests are registered using __initcallboottest() and run once on every CPU by do_init_boottests(), bracketed by begin/end messages. They run before any domain is created on the primary core, and before the idle loop is entered on a secondary core. Signed-off-by: Ayan Kumar Halder Signed-off-by: Michal Orzel --- Link to v3: https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg215355.html Upstream CI run: https://gitlab.com/xen-project/people/ayankuma/xen/-/pipelines/2853709475 Changes in v4: - gic-test.c is SPDX GPL-2.0-only; COPYING states v2-only is the only valid version. v3 had changed this to GPL-2.0-or-later to match the neighbouring GIC files, which was wrong (Julien). - The SGI handler uses ACCESS_ONCE() for the increment as well as the read, since the counter is published to another CPU. Not an atomic: only the receiving CPU writes its own counter (Julien). - Dropped the file name from the gic_sgi_test_interrupt() comment in asm/gic.h (Julien). - asm/setup.h is included after asm/tee/tee.h in smpboot.c (Julien). - Sent as a new thread rather than in-reply-to v3 (Julien). - Rebased onto current staging (adbbbd47a1); applied unchanged. automation/gitlab-ci/build.yaml | 8 ++ automation/gitlab-ci/test.yaml | 8 ++ .../scripts/qemu-boot-selftest-arm64.sh | 72 +++++++++++++ docs/misc/xen-command-line.pandoc | 10 ++ xen/arch/arm/Kconfig | 13 +++ xen/arch/arm/Makefile | 1 + xen/arch/arm/gic-test.c | 102 ++++++++++++++++++ xen/arch/arm/gic.c | 5 + xen/arch/arm/include/asm/gic.h | 8 ++ xen/arch/arm/include/asm/setup.h | 9 ++ xen/arch/arm/setup.c | 20 ++++ xen/arch/arm/smpboot.c | 3 + xen/arch/arm/xen.lds.S | 4 + 13 files changed, 263 insertions(+) create mode 100755 automation/scripts/qemu-boot-selftest-arm64.sh create mode 100644 xen/arch/arm/gic-test.c diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index 27eefec5f9..3d37e0b572 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -420,6 +420,14 @@ alpine-3.24-arm64-gcc-debug: CONFIG_UBSAN=y CONFIG_UBSAN_FATAL=y +alpine-3.24-arm64-gcc-debug-boot-selftest: + extends: .gcc-arm64-build-debug + <<: *build-test + variables: + CONTAINER: alpine:3.24-arm64v8 + EXTRA_XEN_CONFIG: | + CONFIG_BOOT_SELFTEST=y + alpine-3.24-arm64-gcc-randconfig: extends: .gcc-arm64-build variables: diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml index 61adc1baff..96127995d7 100644 --- a/automation/gitlab-ci/test.yaml +++ b/automation/gitlab-ci/test.yaml @@ -605,6 +605,14 @@ qemu-smoke-dom0less-arm64-gcc-debug-gicv3: - *arm64-test-needs - alpine-3.24-arm64-gcc-debug +qemu-smoke-boot-selftest-arm64-gcc-debug: + extends: .qemu-arm64 + script: + - ./automation/scripts/qemu-boot-selftest-arm64.sh 2>&1 | tee ${LOGFILE} + needs: + - *arm64-test-needs + - alpine-3.24-arm64-gcc-debug-boot-selftest + qemu-smoke-dom0less-arm64-gcc-debug-staticmem: extends: .qemu-arm64 script: diff --git a/automation/scripts/qemu-boot-selftest-arm64.sh b/automation/scripts/qemu-boot-selftest-arm64.sh new file mode 100755 index 0000000000..e36bd8d94a --- /dev/null +++ b/automation/scripts/qemu-boot-selftest-arm64.sh @@ -0,0 +1,72 @@ +#!/bin/bash + +set -ex -o pipefail + +# Boot Xen under QEMU with gic-test in xen,xen-bootargs and check that every +# self-test reported OK and that Xen carried on booting. + +XEN=binaries/xen +# qemu-system-aarch64 comes from the debian:13-arm64v8 test container, the +# same way the other qemu-smoke-*-arm64 scripts get it. +QEMU=qemu-system-aarch64 +DTB_RAW=binaries/virt.dtb +DTB=binaries/virt-bootselftest.dtb +LOG=smoke.serial + +NR_CPUS=4 + +test -f ${XEN} + +${QEMU} \ + -machine virt,virtualization=true,gic-version=3,dumpdtb=${DTB_RAW} \ + -cpu cortex-a57 -m 1024 -smp ${NR_CPUS} -display none -net none + +cp ${DTB_RAW} ${DTB} +fdtput -t s ${DTB} /chosen xen,xen-bootargs \ + "gic-test console=dtuart sync_console" + +rm -f ${LOG} +timeout 60 ${QEMU} \ + -machine virt,virtualization=true,gic-version=3 \ + -cpu cortex-a57 -m 1024 -smp ${NR_CPUS} \ + -serial file:${LOG} \ + -monitor none -display none -no-reboot -net none \ + -dtb ${DTB} \ + -kernel ${XEN} || true + +fail=0 + +check() { + local what=$1 + local expected=$2 + local got + + got=$(grep -c -- "${what}" ${LOG} || true) + if [ "${got}" -ne "${expected}" ]; then + echo "FAIL: '${what}': expected ${expected}, got ${got}" + fail=1 + return + fi + + echo "OK: '${what}' x${expected}" +} + +# Every CPU sends an SGI to itself... +check "GIC selftest: CPU[0-9]*: SGI to self: OK" ${NR_CPUS} +# ...every secondary CPU sends one to CPU0... +check "GIC selftest: CPU[0-9]*: SGI to CPU0: OK" $((NR_CPUS - 1)) +# ...and whichever CPU runs last sends one to all the others. +check "GIC selftest: CPU[0-9]*: SGI to all but self: OK" 1 + +check "boot self-tests done" ${NR_CPUS} +check "GIC selftest: .*did not receive" 0 + +# A passing self-test must leave Xen booting normally. +check "LOADING DOMAIN 0\|Xen dom0less mode detected" 1 + +if [ ${fail} -ne 0 ]; then + echo "FAILED" + exit 1 +fi + +echo "PASSED" diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index b2c94ae56d..ea0e3368b1 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1282,6 +1282,16 @@ available on Intel Panther Lake and Diamond Rapids CPUs, and AMD Zen6 CPUs. FRED is fully supported on AMD hardware. On Intel hardware it is still tech preview, and in particular not security supported. +### gic-test (arm) +> `= ` + +> Default: `false` + +Only available when `CONFIG_BOOT_SELFTEST` is enabled. + +Run the GIC SGI boot self-tests while each CPU is brought up. Xen panics if +an SGI is not delivered; otherwise it carries on booting normally. + ### gnttab > `= List of [ max-ver:, transitive=, transfer= ]` diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 843a43897e..92a1788854 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -498,6 +498,19 @@ config ARM64_HARDEN_BRANCH_PREDICTOR config ARM32_HARDEN_BRANCH_PREDICTOR def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR +config BOOT_SELFTEST + bool "Enable boot self-tests" + depends on DEBUG + help + This option enables boot self-tests. They are intended to check that + Xen has configured the hardware correctly before bringing up any + domains. A failure is reported by panic(); when the tests pass, Xen + boots normally. + + Selected at boot with the "gic-test" command line option. + + If unsure, say N. + source "arch/arm/platforms/Kconfig" source "common/Kconfig" diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index b7afd3e58c..71f177824b 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -24,6 +24,7 @@ obj-y += domctl.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o obj-y += efi/ obj-y += gic.o +obj-$(CONFIG_BOOT_SELFTEST) += gic-test.o obj-$(CONFIG_GICV2) += gic-v2.o obj-$(CONFIG_GICV3) += gic-v3.o obj-$(CONFIG_HAS_ITS) += gic-v3-its.o diff --git a/xen/arch/arm/gic-test.c b/xen/arch/arm/gic-test.c new file mode 100644 index 0000000000..c2ffe2e9b9 --- /dev/null +++ b/xen/arch/arm/gic-test.c @@ -0,0 +1,102 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static bool __initdata opt_gic_test; +boolean_param("gic-test", opt_gic_test); + +static DEFINE_PER_CPU(unsigned int, sgi_test_count); + +void gic_sgi_test_interrupt(void) +{ + ACCESS_ONCE(this_cpu(sgi_test_count))++; +} + +static unsigned int __init sgi_count(unsigned int cpu) +{ + return ACCESS_ONCE(per_cpu(sgi_test_count, cpu)); +} + +static void __init snapshot_sgi(unsigned int *before) +{ + unsigned int cpu; + + for_each_online_cpu ( cpu ) + before[cpu] = sgi_count(cpu); +} + +/* + * Wait for every CPU in @mask to take one more GIC_SGI_TEST than the count + * recorded in @before. + */ +static void __init expect_sgi(const cpumask_t *mask, + const unsigned int *before, const char *what) +{ + s_time_t deadline = NOW() + MILLISECS(100); + unsigned int cpu; + + for_each_cpu ( cpu, mask ) + { + while ( sgi_count(cpu) == before[cpu] ) + { + if ( NOW() > deadline ) + panic("GIC selftest: %s: CPU%u did not receive GIC_SGI_TEST\n", + what, cpu); + cpu_relax(); + } + } + + printk("GIC selftest: CPU%u: %s: OK\n", smp_processor_id(), what); +} + +/* + * "All but self" is only meaningful once every CPU can take an SGI, so it is + * run by whichever CPU observes that it is the last one to get here. + */ +static int __init gic_sgi_selftest(void) +{ + static atomic_t __initdata seen = ATOMIC_INIT(0); + unsigned int before[NR_CPUS] = { }; + unsigned int cpu = smp_processor_id(); + + if ( !opt_gic_test ) + return 0; + + snapshot_sgi(before); + send_SGI_self(GIC_SGI_TEST); + expect_sgi(cpumask_of(cpu), before, "SGI to self"); + + if ( cpu != 0 ) + { + snapshot_sgi(before); + send_SGI_one(0, GIC_SGI_TEST); + expect_sgi(cpumask_of(0), before, "SGI to CPU0"); + } + + if ( atomic_add_return(1, &seen) == num_online_cpus() ) + { + cpumask_t target; + + cpumask_andnot(&target, &cpu_online_map, cpumask_of(cpu)); + + if ( !cpumask_empty(&target) ) + { + snapshot_sgi(before); + send_SGI_allbutself(GIC_SGI_TEST); + expect_sgi(&target, before, "SGI to all but self"); + } + } + + return 0; +} +__initcallboottest(gic_sgi_selftest); diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 078049e741..6a132c64e1 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -330,6 +330,11 @@ static void do_static_sgi(struct cpu_user_regs *regs, enum gic_sgi sgi) case GIC_SGI_CALL_FUNCTION: smp_call_function_interrupt(); break; +#ifdef CONFIG_BOOT_SELFTEST + case GIC_SGI_TEST: + gic_sgi_test_interrupt(); + break; +#endif default: panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id()); break; diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h index ee2c26adb4..33dca9dcc6 100644 --- a/xen/arch/arm/include/asm/gic.h +++ b/xen/arch/arm/include/asm/gic.h @@ -306,6 +306,9 @@ enum gic_sgi { GIC_SGI_EVENT_CHECK, GIC_SGI_DUMP_STATE, GIC_SGI_CALL_FUNCTION, +#ifdef CONFIG_BOOT_SELFTEST + GIC_SGI_TEST, +#endif GIC_SGI_STATIC_MAX, }; @@ -321,6 +324,11 @@ extern void send_SGI_one(unsigned int cpu, enum gic_sgi sgi); extern void send_SGI_self(enum gic_sgi sgi); extern void send_SGI_allbutself(enum gic_sgi sgi); +#ifdef CONFIG_BOOT_SELFTEST +/* Record a GIC_SGI_TEST delivered to this CPU. */ +void gic_sgi_test_interrupt(void); +#endif + /* print useful debug info */ extern void gic_dump_info(struct vcpu *v); extern void gic_dump_vgic_info(struct vcpu *v); diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 2af7805125..c491c56729 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -48,6 +48,15 @@ void setup_mm(void); extern uint32_t hyp_traps_vector[]; void init_traps(void); +#ifdef CONFIG_BOOT_SELFTEST +#define __initcallboottest(fn) \ + static const initcall_t __initcall_##fn __init_call("boottest") = (fn) + +void do_init_boottests(void); +#else +static inline void do_init_boottests(void) {} +#endif + int handle_device(struct domain *d, struct dt_device_node *dev, p2m_type_t p2mt, struct rangeset *iomem_ranges, struct rangeset *irq_ranges); diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 79bbf24305..16f899dff5 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -81,6 +81,24 @@ static void __init init_idle_domain(void) /* TODO: setup_idle_pagetable(); */ } +#ifdef CONFIG_BOOT_SELFTEST +extern const initcall_t __initcall_boot_test_start[], + __initcall_boot_test_end[]; + +void do_init_boottests(void) +{ + const initcall_t *call; + + printk("CPU%u: boot self-tests start\n", smp_processor_id()); + + for ( call = __initcall_boot_test_start; call < __initcall_boot_test_end; + call++ ) + (*call)(); + + printk("CPU%u: boot self-tests done\n", smp_processor_id()); +} +#endif /* CONFIG_BOOT_SELFTEST */ + static const char * __initdata processor_implementers[] = { ['A'] = "ARM Limited", ['B'] = "Broadcom Corporation", @@ -471,6 +489,8 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) enable_errata_workarounds(); enable_cpu_features(); + do_init_boottests(); + /* Create initial domain 0. */ if ( !is_dom0less_mode() ) create_dom0(); diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 1806c47a08..8c9072f3c1 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -30,6 +30,7 @@ #include #include #include +#include /* Override macros from asm/page.h to make them work with mfn_t */ #undef virt_to_mfn @@ -413,6 +414,8 @@ void asmlinkage noreturn start_secondary(void) printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id()); + do_init_boottests(); + startup_cpu_idle_loop(); } diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S index d4d9594033..7399ef4804 100644 --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -146,6 +146,10 @@ SECTIONS *(.initcall1.init) __initcall_end = .; + __initcall_boot_test_start = .; + *(.initcallboottest.init) + __initcall_boot_test_end = .; + . = ALIGN(4); __alt_instructions = .; *(.altinstructions) -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421684.1648126 (Exim 4.92) (envelope-from ) id 1x6oDj-0003CQ-Fi; Wed, 16 Sep 2026 11:54:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421684.1648126; Wed, 16 Sep 2026 11:54:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDj-0003CJ-CM; Wed, 16 Sep 2026 11:54:35 +0000 Received: by outflank-mailman (input) for mailman id 1421684; Tue, 15 Sep 2026 12:56:12 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Sho-0001GA-8e for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 12:56:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Shn-001PeN-56 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 14:56:11 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9406a-8faa-0a2a0a5109dd-0a2a4507980e-6 for ; Tue, 15 Sep 2026 14:56:11 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9406a-b4ea-0a2a45070019-4a7de14cb65e-3 for ; Tue, 15 Sep 2026 14:56:11 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843f22dcb8so184994f8f.0 for ; Tue, 15 Sep 2026 05:56:11 -0700 (PDT) Received: from 830778650420 named unknown by gmailapi.google.com with HTTPREST; Tue, 15 Sep 2026 05:56:09 -0700 Received: from 830778650420 named unknown by gmailapi.google.com with HTTPREST; Tue, 15 Sep 2026 05:56:09 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:MIME-Version:From" ARC-Seal: i=1; a=rsa-sha256; t=1789476970; cv=none; d=google.com; s=arc-20260327; b=eSowFjY+1fRoglpik6lKl2SJqkyhe+xKwQ4HVjiJnybF4CKuOmCu9JOtctBhr91wg8 R5YWk5EXpDQ84klSfGnGV5ct47nyb77MWI2JU+WAgZLDSn4iMJ01vovTv5ozWtKeoeWR YxrTIcmATRKvBSv8Qlt7Ru6gYkv3YgjVg7vWzfotNA0T2ST0cQG5TC6aBOJSQvwFTljY fJEY5AYCcpWmId5ZfgfQAWKjLZQonWMMprD03YStQvtub6aoxN+7M/MXyyaBBQYLFbRQ bB0iYL7iv0u03yEEdQwQUGM6Clo2ZceUEyjBWYbq8nWv3pBFYMxgimYLKWsfk7DFUcOI K8wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:mime-version:from:dkim-signature; bh=NYTm+ORiuCMyxJc9UywtnBxVs5qgekVj+icnB/ZVvik=; fh=lPwC7CchF1+dXFOM/FzxI/B4aQd83dw89+WvzXVIKTI=; b=n62laoELRqMZTOUpPwut8/LmaQiAOJwhGsP5M+eus7UNQ8Xspr64GIgohKvgZV0ub5 zF/6JCmgrxn3IktrGsGfS0MnV2l0hfq20UZWAEqTzspwKCUETej5zDFA1//wpJ90SJQI oR64yE16OJ/I4RMPPdBdQT+9RxzaMJs2ZDzjiYd2XZjkY1wX5E5DbmMLB0ttYZcs5ZtQ 2+fF+Eq59LC72E/wv+SZfTfhMpCy3qZtQTPXAs7wInvzGwjA6IrcshvZQYcYTSHMVwVf hUo9Upgfn/FspAdhd402At0eD0uA1F0Eu8qxtcmenscIHg5eNmwNK2IQzZhGEvuyFsAF d6Mw==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789476970; x=1790081770; darn=lists.xenproject.org; h=content-type:cc:to:subject:message-id:date:mime-version:from:from :to:cc:subject:date:message-id:reply-to:content-type; bh=NYTm+ORiuCMyxJc9UywtnBxVs5qgekVj+icnB/ZVvik=; b=JrwXoviZSijFTSspWmmvJmxm7mgETCqCpXgI+jAT3HZMXumndU/Ayy3fI52HfhWp7R oCN/BuIkk6kkM4CDummzP5Zv2il9oajzeVwCRziUnudoT8ruYfg0rhxAOWRgGf6eJ9Aw iMXR/kau95yM804ot75KfQbIY3YyOWR/CaqDY249wlXakJwpWGs6Q1DXvt3EuIMRPGZW ZE4cRZRhkbD+r192LeNmHaad7wChZ4L9dGNUpdrz3Qx4p7cBDiL6Twr+zCKp0M/nhw52 Zia9ugFP7YLp4kI9xRrYQzUrMEsolRDb7eWP7d+uRxgWDuwxP7DiBbqOgDpNiDf+1ud4 l63Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789476970; x=1790081770; h=content-type:cc:to:subject:message-id:date:mime-version:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=NYTm+ORiuCMyxJc9UywtnBxVs5qgekVj+icnB/ZVvik=; b=JKxBpDaY/b3VugrvcRymdMEGVrn6GL7vQoDmX1zIR0aBgi+UFYYPOmrfIni5DXguzn ssreoq5w5+vvZNx/gSZhVlh5vfLTglI7aQ9K+q00Frd0hY4KGy0U/1gETsRr+gVZfNL/ OMZnrM9UIZyHPYYlXnIsJ1SWIXfTl9jqHw069EUI6LaPaJoGfdReCfZdg0+b/75/AE0X DC1Q2Rb2EbO8ZuNmB9y8OLj9ZJnnQV4LyKauZWaEa1tx/jE69q+H7xWYURCfdH22rXUj xaEtO44wW3kYcxPXWfeAWQrU6K/i8s1MoMJzARhls0F7tlQeBHXTnsHKxOxKUb1D450a H0Mg== X-Gm-Message-State: AFuF++m5LUzDIcu6PVoH3qNVoYlDnmZZGm/e/ZjSxeSC89yk6Zdk2xix Zt+2bB2C45Wm0RSFnmgBoZtNoGYzIT4OCSB3/biRYnyVtlyruB73mrwUP0//WFcwZ3nEYuJXPSr ydPXq+QqnwHeoya4ME+3aPpThke6VFqnUz1vNG5bp47CE X-Gm-Gg: AYBFou0z+vQUQKyVSXrF4AlWFl2ea5eVvJor4LV9P26z737+UrtRgqHmLgVDTG/T87k BKIDmuzX8YVLNcyXVMLevQvAZMm/89+0ZoSl/DvZnaBucARx3QICE06PYs6y4/ZaIHJTHx4piuj W0sKfTRH5whmmVCUgPbDtz8mOmrN0ebaWOYDFWB3GFqK+XA7Uc0nFVRZaq6u6qsCUw1E4+6DqiH PAp2vHxRjUxEN+P0D9QrYlDd1f43652T0Ec0I5J6zGCgxd0yEm6STMlhSNbatnJxU2yeVnVsJP0 Og+kNL6VuKvC13tSzvnMgKyaAbWtp2UKggQLozq252UWv2jWHR7zalBa1KdeYwRn X-Received: by 2002:adf:e18e:0:b0:487:aee:75cb with SMTP id ffacd0b85a97d-4870aee76aamr341482f8f.10.1789476970478; Tue, 15 Sep 2026 05:56:10 -0700 (PDT) From: Ruslan Vagner MIME-Version: 1.0 Date: Tue, 15 Sep 2026 05:56:09 -0700 X-Gm-Features: AcwNN1XleUuyvV52uIvINjYuMpQl23DTZbfH1-4Iiz2Z6kIPWcHwstIh4TDuGDA Message-ID: Subject: [PATCH] xen: fix comment typo in xen.h To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, Ruslan Vagner Content-Type: text/plain; charset="UTF-8" X-purgate-ID: tlsNG-ef75cf/1789476971-A7CD7AE4-61FE23A5/0/0 X-purgate-type: clean X-purgate-size: 1069 Fix the spelling in comments. No functional change. Signed-off-by: Ruslan Vagner --- include/xen/interface/xen.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index 40c9793e9880..f9acb21875cf 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -94,7 +94,7 @@ #define VIRQ_XENOPROF 7 /* V. XenOprofile interrupt: new sample available */ #define VIRQ_CON_RING 8 /* G. (DOM0) Bytes received on console */ #define VIRQ_PCPU_STATE 9 /* G. (DOM0) PCPU state changed */ -#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occured */ +#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occurred */ #define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient */ #define VIRQ_ENOMEM 12 /* G. (DOM0) Low on heap memory */ #define VIRQ_XENPMU 13 /* PMC interrupt */ -- 2.54.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421869.1648150 (Exim 4.92) (envelope-from ) id 1x6oDk-0003YP-Ip; Wed, 16 Sep 2026 11:54:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421869.1648150; Wed, 16 Sep 2026 11:54:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDk-0003WC-Bk; Wed, 16 Sep 2026 11:54:36 +0000 Received: by outflank-mailman (input) for mailman id 1421869; Tue, 15 Sep 2026 14:18:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Tyy-0002b9-2v for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 14:18:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Tyx-007PNe-G3 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 16:17:59 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa95393-bab6-0a2a0a5309dd-0a2a4509bb62-24 for ; Tue, 15 Sep 2026 16:17:59 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa95395-be1a-0a2a45090019-aceafc1fe91c-3 for ; Tue, 15 Sep 2026 16:17:58 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 230DF41650; Tue, 15 Sep 2026 14:17:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6F7A1F00893; Tue, 15 Sep 2026 14:17:53 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="In-Reply-To:References:Subject:From:To:Cc:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789481877; bh=37WI6Bj/Ggz3/9zO2SR1BHA0D09BihoVO8j7O418CP4=; h=In-Reply-To:References:Subject:From:To:Cc:Date; b=L8QviNNrTmMpIqQxxWm+1VskqSUHJhnuf0/rYUwn4D42ISdoJmFjdazUlkGx8ggjD X9a5oqOjNa/CDI0U1C0R5QjHTXlgPr/67Rld+0Hyr0uJ/7kc3460S3rv7/jkol6ScQ +IDquEBZlfhgOQp6PB69iJ4aD7kdmPXVcZA+RIUuxHxgEsToRDVkNmvLsX0odMc+Rw nuEvkdqjxbWUYQZihz9u2BVhArW2qXa3JsNJNFwxqYCKBT6wR0d7kywT/XE6mpf1b3 xzVVYFhiewYfFNfuT8Uq0rEA4UxyGjpPPEsrojRib0d1ehB27wSNo+4fQ7hHW5u7Gn OzxzjqzdwP2cg== Content-Type: multipart/mixed; boundary="===============0488351286812016447==" MIME-Version: 1.0 Message-Id: <99771250491ac7c5568e688eacca866676565a40f18f1189b8937472f4aba91e@mail.kernel.org> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-13-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-13-0ad30c4c5ee7@toxicpanda.com> Subject: Re: [PATCH RFC v3 13/13] x86, arm64: Build Tasks RCU on Tasks Trace readers in trampolines From: bot+bpf-ci@kernel.org To: josef@toxicpanda.com,paulmck@kernel.org,frederic@kernel.org,neeraj.upadhyay@kernel.org,joelagnelf@nvidia.com,boqun@kernel.org,tglx@kernel.org,peterz@infradead.org,rostedt@goodmis.org,mhiramat@kernel.org,mark.rutland@arm.com,jolsa@kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,x86@kernel.org,catalin.marinas@arm.com,will@kernel.org,puranjay@kernel.org,xukuohai@huaweicloud.com,paulmck@kernel.org,frederic@kernel.org,neeraj.upadhyay@kernel.org,joelagnelf@nvidia.com,boqun@kernel.org,tglx@kernel.org,peterz@infradead.org,rostedt@goodmis.org,mhiramat@kernel.org,mark.rutland@arm.com,jolsa@kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,x86@kernel.org,catalin.marinas@arm.com,will@kernel.org,puranjay@kernel.org,xukuohai@huaweicloud.com Cc: luto@kernel.org,josh@joshtriplett.org,urezki@gmail.com,mathieu.desnoyers@efficios.com,jiangshanlai@gmail.com,qiang.zhang@linux.dev,jgross@suse.com,mcgrof@kernel.org,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,rcu@vger.kernel.org,linux-trace-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-arm-kernel@lists.infradead.org,xen-devel@lists.xenproject.org,luto@kernel.org,josh@joshtriplett.org,urezki@gmail.com,mathieu.desnoyers@efficios.com,jiangshanlai@gmail.com,qiang.zhang@linux.dev,jgross@suse.com,mcgrof@kernel.org,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,rcu@vger.kernel.org,linux-trace-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-arm-kernel@lists.infradead.org,xen-devel@lists.xenproject.org,josef@toxicpanda.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev Date: Tue, 15 Sep 2026 14:17:53 +0000 (UTC) X-purgate-ID: tlsNG-bad1c0/1789481878-3AAD8034-D5CAAA14/0/0 X-purgate-type: clean X-purgate-size: 4585 --===============0488351286812016447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst > index 8101fe6229d57..34b81512cc5f3 100644 > --- a/Documentation/RCU/Design/Requirements/Requirements.rst > +++ b/Documentation/RCU/Design/Requirements/Requirements.rst > @@ -2756,6 +2756,26 @@ synchronize_rcu(), and rcu_barrier(), respectively. In > three APIs are therefore implemented by separate functions that check > for voluntary context switches. > > +Architectures that select ``CONFIG_HAVE_RCU_TRAMPOLINE_READERS`` keep the > +same three APIs but implement the grace period differently > +(``CONFIG_TASKS_RCU_TRAMPOLINE_READERS``). There, every trampoline whose > +lifetime Tasks RCU guards enters a Tasks Trace RCU read-side critical > +section (rcu_read_lock_trace() or its assembly equivalent) before calling > +out and leaves it before returning, so a task anywhere inside such a > +call-out is an ordinary Tasks Trace reader whether or not it is > +preempted. The few trampoline instructions outside that reader can only > +be occupied by a task that was interrupted there, so the grace period > +additionally waits for each CPU to pass through a context switch, and the > +irq-exit preemption path, the only switch that can catch a task inside > +such text (rcu_tasks_trampoline_text()), briefly makes such a task a > +holdout until it is next seen elsewhere. On such kernels an involuntary > +context switch outside trampoline text *is* a Tasks-RCU quiescent state, > +a Tasks RCU grace period no longer depends on how long any task runs > +without sleeping, cond_resched_tasks_rcu_qs() is unnecessary, and the > +obligation moves to the trampolines: anything that relies on > +synchronize_rcu_tasks() to protect code a task may be preempted in must > +take the Tasks Trace reader (see register_ftrace_direct()). ^^^^^ Does this paragraph describe the complete set of options? The series itself includes kernel/kprobes.c:kprobe_optimizer(), which relies on synchronize_rcu_tasks() to protect instructions a task may be preempted in, but instead of taking a Tasks Trace reader it registers an address predicate and calls rcu_tasks_wait_irq_preempted(kprobe_in_optimized_region) before synchronize_rcu_tasks(). kernel/kprobes.c:526-539 documents that alternative: "kprobe_optimizer() relies on synchronize_rcu_tasks() to wait for tasks that ... the quiescent-state check asks this instead." Since this paragraph is the single place in Documentation/RCU that describes the new contract for HAVE_RCU_TRAMPOLINE_READERS architectures, a subsystem author reading it would conclude there is one way to comply and would get no pointer to rcu_tasks_wait_irq_preempted() or rcu_tasks_trampoline_text() for code that cannot take a reader. Could the paragraph mention the rcu_tasks_wait_irq_preempted() escape hatch, or soften to "must take the Tasks Trace reader or otherwise make its text known to the quiescent-state check"? > diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst > index 4b30f701225fd..7082686cbd66d 100644 > --- a/Documentation/RCU/checklist.rst > +++ b/Documentation/RCU/checklist.rst > @@ -252,7 +252,12 @@ over a rather long period of time, but improvements are always welcome! > a. If the updater uses synchronize_rcu_tasks() or > call_rcu_tasks(), then the readers must refrain from > executing voluntary context switches, that is, from > - blocking. > + blocking. On architectures that select > + CONFIG_HAVE_RCU_TRAMPOLINE_READERS a reader must in > + addition be a Tasks Trace RCU reader (that is what the > + trampolines there do around their call-outs); an > + arbitrary stretch of preemptible kernel code is not > + protected. ^^^^^^^^^ Same question here. This text also states the obligation in absolute terms ("a reader must in addition be a Tasks Trace RCU reader"), with no mention of the rcu_tasks_wait_irq_preempted() alternative that kprobe_optimizer() uses. [ ... ] --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/34975311706 --===============0488351286812016447==-- From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421867.1648143 (Exim 4.92) (envelope-from ) id 1x6oDk-0003R0-8S; Wed, 16 Sep 2026 11:54:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421867.1648143; Wed, 16 Sep 2026 11:54:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDk-0003PS-1q; Wed, 16 Sep 2026 11:54:36 +0000 Received: by outflank-mailman (input) for mailman id 1421867; Tue, 15 Sep 2026 14:17:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Tyt-0002ZP-NE for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 14:17:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Tyt-007PNe-3q for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 16:17:55 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9537f-bab6-0a2a0a5309dd-0a2a4507d13a-46 for ; Tue, 15 Sep 2026 16:17:55 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa95391-b4ea-0a2a45070019-aceafc1f8a26-3 for ; Tue, 15 Sep 2026 16:17:54 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 9AA57444FB; Tue, 15 Sep 2026 14:17:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 615571F000FF; Tue, 15 Sep 2026 14:17:49 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="In-Reply-To:References:Subject:From:To:Cc:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789481872; bh=dlifTzsU870ATuTg2IJn/IPrNft0aFbK+vPgKDTS1dk=; h=In-Reply-To:References:Subject:From:To:Cc:Date; b=NcJKS+kV0GgjRC3ooOQJBaPV2jeb6Y3d7UL4KriHUw2PKdKGn7mKEA7SMmMWfIlqt bc5DtxknhNCYHW85dgnR0O1wnuoYHGcJ4C0AiZgmu+fz+2klekeelQG3tQy3kn6mb+ Bxu2osCJ/9PVurBc5hIFiJw9HG5D0gNBBXFktBxTe2x/6bGUzUrFRDlIdugN52I3XS 6ljxmdn9PqqOpms/XSTRgW4rIXZ4KadYi1RlA823W0VzXI7FxNHwHs5eMtMxi15qv5 /tajIopVGIHRQEKBrIrFfINbf3r5PbFrdZhzKSzVcNP89nB8SMq97bnqwcqNM7l/MA 5l0+g0xX/gTig== Content-Type: multipart/mixed; boundary="===============7591369071524205309==" MIME-Version: 1.0 Message-Id: <08596bcdd997ab7122dafdb363cf80caaf038378f32ccb89fbca114c2fd9110a@mail.kernel.org> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-5-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-5-0ad30c4c5ee7@toxicpanda.com> Subject: Re: [PATCH RFC v3 05/13] ftrace: Mark modules hosting direct-call trampolines for Tasks RCU From: bot+bpf-ci@kernel.org To: josef@toxicpanda.com,paulmck@kernel.org,frederic@kernel.org,neeraj.upadhyay@kernel.org,joelagnelf@nvidia.com,boqun@kernel.org,tglx@kernel.org,peterz@infradead.org,rostedt@goodmis.org,mhiramat@kernel.org,mark.rutland@arm.com,jolsa@kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,x86@kernel.org,catalin.marinas@arm.com,will@kernel.org,puranjay@kernel.org,xukuohai@huaweicloud.com,paulmck@kernel.org,frederic@kernel.org,neeraj.upadhyay@kernel.org,joelagnelf@nvidia.com,boqun@kernel.org,tglx@kernel.org,peterz@infradead.org,rostedt@goodmis.org,mhiramat@kernel.org,mark.rutland@arm.com,jolsa@kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,x86@kernel.org,catalin.marinas@arm.com,will@kernel.org,puranjay@kernel.org,xukuohai@huaweicloud.com Cc: luto@kernel.org,josh@joshtriplett.org,urezki@gmail.com,mathieu.desnoyers@efficios.com,jiangshanlai@gmail.com,qiang.zhang@linux.dev,jgross@suse.com,mcgrof@kernel.org,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,rcu@vger.kernel.org,linux-trace-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-arm-kernel@lists.infradead.org,xen-devel@lists.xenproject.org,luto@kernel.org,josh@joshtriplett.org,urezki@gmail.com,mathieu.desnoyers@efficios.com,jiangshanlai@gmail.com,qiang.zhang@linux.dev,jgross@suse.com,mcgrof@kernel.org,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,rcu@vger.kernel.org,linux-trace-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-arm-kernel@lists.infradead.org,xen-devel@lists.xenproject.org,josef@toxicpanda.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev Date: Tue, 15 Sep 2026 14:17:49 +0000 (UTC) X-purgate-ID: tlsNG-ef75cf/1789481874-370DDAE4-84E6386A/0/0 X-purgate-type: clean X-purgate-size: 6027 --===============7591369071524205309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > diff --git a/include/linux/module.h b/include/linux/module.h > index 96cc98568eea5..28488687cb01f 100644 > --- a/include/linux/module.h > +++ b/include/linux/module.h > @@ -521,6 +521,13 @@ struct module { > unsigned int num_ftrace_callsites; > unsigned long *ftrace_callsites; > #endif > +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS > + /* > + * An ftrace direct-call trampoline lives in this module's text; see > + * rcu_tasks_trampoline_text(). Sticky once set. > + */ > + bool ftrace_direct_tramp; > +#endif This isn't a bug, but could the field and ftrace_direct_mark_module()'s body be gated on CONFIG_TASKS_RCU_TRAMPOLINE_READERS instead? The only reader of module::ftrace_direct_tramp is rcu_tasks_trampoline_text(), which lives inside kernel/rcu/tasks.h's CONFIG_TASKS_RCU_TRAMPOLINE_READERS block: kernel/rcu/tasks.h:rcu_tasks_trampoline_text() { #ifdef CONFIG_MODULES scoped_guard(rcu) { struct module *mod = __module_text_address(ip); if (mod) { ret = kprobe_in_optimized_region(ip); #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS ret = ret || READ_ONCE(mod->ftrace_direct_tramp); #endif } } #endif } On every configuration that does not select HAVE_RCU_TRAMPOLINE_READERS the per-module bool and the four ftrace_direct_mark_module() call sites that write it have no consumer. > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h > index 8667684628500..ec54a27e47fae 100644 > --- a/kernel/rcu/tasks.h > +++ b/kernel/rcu/tasks.h [ ... ] > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index 53d5db60bfa56..efc4a518658a3 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c [ ... ] > @@ -6090,6 +6113,17 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) > * and save the parameters of the function being traced, and restore them > * (or inject new ones if needed), before returning. > * > + * Nothing but Tasks RCU keeps the trampoline at @addr alive while a task is > + * executing it or is preempted in something it called. On architectures that > + * select HAVE_RCU_TRAMPOLINE_READERS, Tasks RCU only waits for such a task if > + * it is a Tasks Trace RCU reader, so the trampoline must enter one > + * (rcu_read_lock_trace() or its assembly equivalent, see > + * samples/ftrace/ftrace-direct.h) before calling out and leave it before > + * returning, as the ftrace and BPF trampolines do. The few instructions This isn't a bug, but would it read better to point at the sample header only once it exists in the tree, or to word the ftrace/BPF trampoline part as what the series establishes rather than as current state? The new kernel-doc paragraph points readers at samples/ftrace/ftrace-direct.h, which does not exist at this commit (it is added later in the series by 'samples: ftrace: Make the direct-call trampolines Tasks Trace readers'), and states in the present tense that the ftrace and BPF trampolines already take the reader, which also only becomes true in later commits of the series (bpf/x86/arm64 reader patches). Anyone reading or bisecting at this commit gets a dangling reference and a claim the tree does not yet satisfy. > + * before and after are covered by the irq-exit check: automatically for > + * trampolines outside kernel and module text (e.g. BPF images), and via > + * ftrace_direct_mark_module() for trampolines in module text. > + * > * Returns: > * 0 on success > * -EINVAL - The @ops object was already registered with this call or [ ... ] commit ef57b52d2606546f6d483b113fc2202c13863c2c Author: Josef Bacik > ftrace: Mark modules hosting direct-call trampolines for Tasks RCU > > An out-of-line direct trampoline registered with register_ftrace_direct() > is kept alive only by Tasks RCU while a task executes it or is preempted > in something it called; ftrace_shutdown()'s synchronize_rcu_tasks() is > what stops rmmod freeing it under such a task. Where Tasks RCU is built > on reader-marked trampolines, such a trampoline must be a Tasks Trace > reader across its call-out like the ftrace and BPF trampolines are, so > document that in register_ftrace_direct(). > > That still leaves the few instructions before the reader is entered and > after it is left. For BPF images those are in dynamically allocated > text that rcu_tasks_trampoline_text() already treats as unmarked > trampoline text, but the in-tree samples (and any similar user) place > their trampolines in module .text. Add a sticky > module::ftrace_direct_tramp flag, set by every register/modify path when > the direct address is module text, and have rcu_tasks_trampoline_text() > treat a task interrupted anywhere in such a module as a potential > holdout. Other modules' text is unaffected. > > Assisted-by: LLM > Signed-off-by: Josef Bacik This looks like a bug fix for reader-marked trampoline support. Should this include: Fixes: 00bd9b746f5e ("rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines") The bug was introduced in commit 00bd9b746f5e which added rcu_tasks_trampoline_text() but failed to properly handle module .text containing direct trampolines. The function returned false for module text addresses, meaning such trampolines were not protected by Tasks RCU, potentially allowing module text to be freed while still executing. --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/34975311706 --===============7591369071524205309==-- From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422832.1648161 (Exim 4.92) (envelope-from ) id 1x6oDl-0003n0-5H; Wed, 16 Sep 2026 11:54:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422832.1648161; Wed, 16 Sep 2026 11:54:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDk-0003jY-VD; Wed, 16 Sep 2026 11:54:36 +0000 Received: by outflank-mailman (input) for mailman id 1422832; Wed, 16 Sep 2026 11:53:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oCX-00033Q-S2 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:53:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oCX-005ckC-8X for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:53:21 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8329-e002-0a2a0a5209dd-0a2a450594f2-20 for ; Wed, 16 Sep 2026 13:53:20 +0200 Received: from [52.101.48.58] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa832e-4cb1-0a2a45050019-3465303af8eb-3 for ; Wed, 16 Sep 2026 13:53:20 +0200 Received: from CH2PR02CA0009.namprd02.prod.outlook.com (2603:10b6:610:4e::19) by DS6PR12MB152050.namprd12.prod.outlook.com (2603:10b6:8:410::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 11:53:13 +0000 Received: from CH2PEPF0000013B.namprd02.prod.outlook.com (2603:10b6:610:4e:cafe::6f) by CH2PR02CA0009.outlook.office365.com (2603:10b6:610:4e::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 11:53:13 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH2PEPF0000013B.mail.protection.outlook.com (10.167.244.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:53:13 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:52:49 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DYBwkp72ulVUxF0lRt6GqSmvMXRJuEgchxPBZV/zlmhjFqryWjHMaYuPxYbaNEDnO4QJks2xk+oc9A9ndQr7YmFhO+NF055lbq0zdSj7NpghIoxft6CM/AwqJ7STor8ECQhDY863hoe56iY7QuqZIM97lBhkNg9SKq29wTy0wiw9s++TkF7B6zFbMvVBVvAj/NHVbEdLlWLM/j+NR67vn8g1Sf8o1NlAPy0TEbNNyCy1Scgj8r+Hx+P3GGavevg7NfeXesR9NPGOyW00QWVftoO1tpwsv1sSCEh+B2fV6elySji0oGLYe95aAyYxHDKAy98SCchlKTkzpkdaqKFjRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SY2PXIfdH4gQPL2ZLaN4rYd0hBg60SV0RgUb/GbX15c=; b=ULct9KQj2LIhQ/B/hbSpdfU0x2GV/D2bWqLj/X1urkO5IZ0QSHU71OHI17z+INNJnIJzalFrcBRmNvkI7J2m8/GrbMcJbOGYdS5XqTEaDe7YB+O8bx/yGrGa6r+QfHZ9ZqVLOYQe6uxFVPIJJOGdeJODKbpCiEYmTQuh2qpVenYQ4dwIXHgF2O08hMAMEwzoPi2ZqHkDTq+pqTHCMrdXTz/Rh40AmQzwbMjU2ifmLIFtGmRI9Y/GuJEVSIfzmNeVnAKMaT3wKva1auS9TFNtbhGKSl76LJCT4cwmNI25BkNiMdgtbOSeJX3HJDfl46BTm/Jl0Ko7zFWyWEY4XohYUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SY2PXIfdH4gQPL2ZLaN4rYd0hBg60SV0RgUb/GbX15c=; b=N0hikTVZLLlKQRQ9LljQNzVBYbzKHH0cYxZSKI6Hs7pNoviNSEjKHhzWdLDlHjsbn73c0xoZU6VRevsCcGmPydi7mrdoPBzv5blnhya4oMO67gLF4YjYQYkks0qMDyMH3CTQuolNJzfUJ/MBaLhFG8bA5Ui6P5aQl5qA7zDvPmg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 01/17] pci/dma/tsm: Call disable DMA bus hook on cleanup Date: Wed, 16 Sep 2026 21:51:41 +1000 Message-ID: <20260916115159.1938195-2-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF0000013B:EE_|DS6PR12MB152050:EE_ X-MS-Office365-Filtering-Correlation-Id: c368b172-fea0-475e-27fd-08df13e91646 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|82310400026|36860700016|376014|7416014|32650700020|11063799006|56012099006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: lTbYfoL+zluMIQcZMX9c7spGZjQpXCynFv3y/cznROcYIxht8DJBw5ZLo8zGEnnTVHWw2qAb7J2BwF5bOjDhq2N7DkQjd+elST2JCWUXpyO/R7ixu/Y59GDjQCR/uX8ZJ+hoCcjGzuqzxqwPZXIA6Hk7NfEDjKLWbuLEDawfl+W/8sniBWPuDo0SLKRlToGBM4tAHn3wgj4XNq50zxnhK9OWU+/Uz7JOxe0eq8qmeAsPXaKRemotGofnQnu8ao7ULnXSqcvYntuzx9WaCWFn78Y/xe3xyWBxlXjnLOeKMRPYU8Awk5LhRYyxlO8X4icA6IA0TovktSJsx89DNS2jZ+rz2QQocNbqmXHIPUjolM7ehwfHWGGircyk9GCfbwD5P/dinhquBfDUpmQOaBvDs/hVTZdaGTRt4GjnIM16Z0Qh9iKRtXw83BfMmVUMpUWdhLJDb4aAgV/tvLtChQNrN/M3QS+2TyYtxV4Mr6aAhHGRBzZZ9WhPAwr2MBDMzjUvo/C9cItn9SfcwirGV8FnAJQ8SrGXwK/w3dUgRGcXKqar2Hycqq4M/oDb1C4fmeZKQ/PM0JxtOO3H6wDkXhq7aF/cV6gI7TNZEN09Ydt6mnEzfpGmAI96cLvtJ8/t5fmTuHmALW6bARpQlwaLinJNEk+/A9eLsr+jqbuksFvGyT8YqV17Z36rwxQPVGoerdCHYcA8GGykuJuX3HK9WyMQSg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(82310400026)(36860700016)(376014)(7416014)(32650700020)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 8Car1z4HpXq9pf9mgugQAiDX2M+RvASwLDL9yQIeM+kN/l86aDUJkLlLhXbA7h5FyKBkYdpkEvfnzFtAY1ypdABOLbjCcnRxFBKj2AqHYp3MJJkkxZp84M9m9JgKaBp3rXD4byWsdFprofXiibB3C/Aqe5xf/4+mDSyGncGAsfcoYA69DAfAmCeT0Weetem3fMELGDOK5EChaoFW5WWc17UwY4vkz4nFMdZngDqMXJiDZL4Jz7mkbzgsggHXldh7RY6AEc9zJSlma77wuBATEvSpwK5DjBoSX/o2xKHp1XmL2zF2qZ3AVtfjXHVaJg3js5x2DOxzUGU7365U9zN119sIeHjs9Wk0BELZkps29710E9Z5yecIj4dG6BrhgdrlFzWsRus8rYj7S96/IwFvQzh7ArrzAIHx3s8UCRtb/sMfMykBapwtCYQpoVQ3QXGs X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:53:13.1361 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c368b172-fea0-475e-27fd-08df13e91646 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF0000013B.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS6PR12MB152050 X-purgate-ID: tlsNG-c201ff/1789559600-F4EA12A1-BBBCF8F7/0/0 X-purgate-type: clean X-purgate-size: 945 Since XXXX ("PCI, device core: Add private memory access for DEVICE_TRUST_TCB") the TSM subsystem relies on the PCI subsystem to ask the TSM to enable DMA. That misses teardown path to disable DMA, add it now. Fixes: XXXX ("PCI, device core: Add private memory access for DEVICE_TRUST_TCB") Signed-off-by: Alexey Kardashevskiy --- Squash into "PCI, device core: Add private memory access for DEVICE_TRUST_TCB"? --- drivers/pci/pci-driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index a036f3d7e6d5..633926b55da6 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -1739,6 +1739,9 @@ static void pci_dma_cleanup(struct device *dev) if (!driver->driver_managed_dma) iommu_device_unuse_default_domain(dev); + + if (device_tcb_trusted(dev)) + pci_tsm_disable_dma(to_pci_dev(dev)); } /* -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422830.1648157 (Exim 4.92) (envelope-from ) id 1x6oDk-0003f7-TG; Wed, 16 Sep 2026 11:54:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422830.1648157; Wed, 16 Sep 2026 11:54:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDk-0003e3-LY; Wed, 16 Sep 2026 11:54:36 +0000 Received: by outflank-mailman (input) for mailman id 1422830; Wed, 16 Sep 2026 11:52:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oC0-0002xC-Ro for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:52:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oBz-00HAq8-Nm for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:52:47 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8301-2eae-0a2a0a5409dd-0a2a450bad6c-22 for ; Wed, 16 Sep 2026 13:52:47 +0200 Received: from [40.93.196.64] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa830b-b7e8-0a2a450b0019-285dc4402850-3 for ; Wed, 16 Sep 2026 13:52:47 +0200 Received: from CH2PR17CA0024.namprd17.prod.outlook.com (2603:10b6:610:53::34) by LV3PR12MB9119.namprd12.prod.outlook.com (2603:10b6:408:1a2::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 11:52:37 +0000 Received: from CH2PEPF00000141.namprd02.prod.outlook.com (2603:10b6:610:53:cafe::4e) by CH2PR17CA0024.outlook.office365.com (2603:10b6:610:53::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.9 via Frontend Transport; Wed, 16 Sep 2026 11:52:36 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH2PEPF00000141.mail.protection.outlook.com (10.167.244.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:52:36 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:52:13 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aG0oKHb8KcEdre+rK3In8EAAqhdVUmF9VvRw6NPuPrlGrqPlvJPLzycguBO2noWHblZKBztH6x0PTeRAIrNfo/FpZQhkGtE6TprWRpR+ankhY0Sb5NVTSp8OB0TsfwRe1wR34gNExtL8rMQVZtY0WVlYqAev9TLoyn8+fjF+tErqAlqXMQ6QaChgVBOe+FHNUOdFQtBVCZnDV7xdAVyT5RA8NUbNzytuhsjQ2QVS4uT/x4y0xn/YQEwASNyZ3/qCOIOJoXazBFPW4b9h4kcue6fkaKWdAiUhfg0gCYUPi89mn6ssnZCOXYzl2h2M3N6O6c0ARXSiUxHJeyn6Ynu7BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mZx62VDeT0ufB+RoQyhNsYub6vn+IMt5N7ocikkQ9sU=; b=FUyNkmAgjoL3/Qs+3F8bOdJWZRxxAQSwJW4szhpjx76WlA2EdbNX7jtMV4pbjd6iC91k08D4iBb9j8AgeMohTuau1FzNyZt2pgMNrR3k7wEhCceWhRur0It9nkugCoDQfECZ/QHNEXl5jVGK9zQfspiclLtQPItvb1RkcyDOMSOeazpPRKoZiKffRGMnXBwgNMPwDdqq7GrZVoEa2hiF6nXWgC58+c0tDXJtUVpRjwHqUBSf7xfoY9HeBUajjbck/1j+ocf+2OW94VtyszgXGAhvPMbR2a17/AFehv7xqsqmqP2D78ATc4RhwLcSfrFMBON46FvV0aHG6+MLdveVFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mZx62VDeT0ufB+RoQyhNsYub6vn+IMt5N7ocikkQ9sU=; b=TYb0b5xWa3CwbsbXaROqwWacW3UnsWZAsLXCBsuO2VZj3iXs8h7XkGDWJzHS+Rr4NOgL3HVseZVrYfoYjT+MEH/NbZvmfhn1kvBEhxyM6OmIB0EJdTl5EhLqRsxHyVePmgg7X/cEjYvCt0uElsJXsLaUetdh0Zp7OnwDJk7C+7o= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 00/17] PCI/TSM: coco/sev-guest: Implement SEV-TIO PCIe TDISP (phase2) Date: Wed, 16 Sep 2026 21:51:40 +1000 Message-ID: <20260916115159.1938195-1-aik@amd.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000141:EE_|LV3PR12MB9119:EE_ X-MS-Office365-Filtering-Correlation-Id: 7391569d-ac2a-4616-69f3-08df13e9008e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|376014|7416014|23010399003|36860700016|32650700020|18002099003|13003099007|3023799007|5023799004|10067099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: T/gKaq7XFEnBi/yuOuXBHIHCD7TNUzO6/LsGHGpb0VdFnhOacL7FQW1YWREUJE4JArQUEVm1ccK17oYVI1nlQOwVcl/+SkFGawQkgJDJaZ4qH1D/uIlFGDhiW1/d74DByXinxZnIkDQYj9FGXk4OOKJ+kYv/d+CAgG/PTWX0UzZ/Lp0jxAQbHs0Dyh/2BKLQqGx6/d87Tw12FdpCH48IcuKsPZwqk5G9T+klwO3fX8+XnXeVDGfJzW1m5NX1LnPISZhnXsO1uvc3KjxwqC2Ws3B92AV1byfml134mscouKf/eQr8L/BZGaOFkoksnlwWnjD9lH0mPC+uYD4fmIH/V9QWuw+a9tH/N1wA7D6WVBzjww7atU8VJyL+8XzaMFb2qtdJHbhuqCMaB+z8zwC49JfgoEPtAu0mlkYGGFxSu1TzrPnUKfMf62FtDWqwnsNj+u/4ijrmb4SDCnyuz/6Z5BsgMBwCnB0FOHo2HxPuIIO/mnWIVAz+NpBP5CW+k+EC5+76SALy+Sdr9vQ3wwwT8Jfd5sNrI69QlA0aSM0wKMl/u8/LnCLD16kj9JQrN6WPJvPTYouVAb0XPd8oICcFGbiT83qjuJrhursHTFxWhZkq9RUKjqw8PtitrmDBrh8LUAuK8iS9K561fV/OmR7VSuUhBxxDeAcJFprd3/YTi2LlHtvo9PNlxcIYxGV3Ppv25ZrBkRpchcUBXVADUWXLhA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(7416014)(23010399003)(36860700016)(32650700020)(18002099003)(13003099007)(3023799007)(5023799004)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: +PlvSj+WWJdnQa9fqspJ0fGqU+h8yDsfBtjgrmCFlifW3rsbziq4yuNPQQyR/FXWEZSSp00sFYlutVZKzH62lMegd/JbzlYn/hpN78cr2SasoVm5fd/J4xz3ACrrUADNDus1kHqqqKweQl1XkKAuyyjZFggKvacCQoEX2+evG1kj/d82Fq/frgLm/kuBcCvch7vryn1qSGP2AV5fgGB6MD44u054gmUCHYZ5J56mDlJHDsaimg0mgKICWykgf5Qrzl+6gXxuOP4oouH0O8q6rxFwhevrd3K2x79h5jdXml1nC+XkfEUmXRGj3ewK399oB19ERF3hI9KhQsBGCljTGcXTZww+3pXfxyI/qyphgkPNRR1m+v+1Meh6DZkmrq0nPl4K1ltrTht/7eWVnESEApX3Cd54btZQ1VkXv4eebynsR510gjyu4rP54UQmEU7W X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:52:36.6991 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7391569d-ac2a-4616-69f3-08df13e9008e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000141.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9119 X-purgate-ID: tlsNG-42698a/1789559567-186CA9EA-03BB215C/0/0 X-purgate-type: clean X-purgate-size: 5607 Here are some patches to continue enabling SEV-TIO on AMD. SEV-TIO allows guests to establish trust in a device that supports TEE Device Interface Security Protocol (TDISP, defined in PCIe r6.0+) and then interact with the device via private memory. In order to streamline upstreaming process, a common TSM infrastructure is being developed in collaboration with Intel+ARM+RiscV. There is Documentation/driver-api/pci/tsm.rst with proposed phases: 1. IDE: encrypt PCI, host only 2. TDISP in guest: lock + accept flow, interface report <= WE ARE HERE 3. Enable on host: secure MMIO + DMA, KVM changes 4. Device attestation: certificates, measurements Acronyms: TEE - Trusted Execution Environments, a concept of managing trust between the host and devices TSM - TEE Security Manager (TSM), an entity which ensures security on the host PSP - AMD platform secure processor (also "ASP", "AMD-SP"), acts as TSM on AMD. SEV TIO - the TIO protocol implemented by the PSP and used by the host, extension to SEV-SNP GHCB - guest/host communication block - a protocol for guest-to-host communication via a shared page TDISP - TEE Device Interface Security Protocol (PCIe). Flow: - Boot guest OS, load sev-guest.ko which registers itself as a TSM - PCI TSM creates sysfs nodes under "tsm" subdirectory in for all TDISP-capable devices - lock the device via: echo tsm0 > "/sys/bus/pci/devices/0000:01:00.0/tsm/lock" - accept the device via: echo 1 > "/sys/bus/pci/devices/0000:01:00.0/tsm/accept" - load the device driver: - DMA to encrypted memory should work right away - Reported TEE MMIO regions will be mapped as encrypted Patches 01/17..05/17 are fixes and can go in sooner. Patches 06/17..17/17 are the minimum required by the VM to get encrypted MMIO and DMA. Doing "io_tlb_default_mem.for_alloc = true" in swiotlb_init_remap() enabled T=1 DMA to shared guest memory. The previous conversation is here: https://lore.kernel.org/r/20260225053806.3311234-1-aik@amd.com This is based on the last Dan's patch series rebased on top of v7.3-rc2 with the DMA SWIOTLB fixes from Aneesh. The whole tree is here: https://github.com/AMDESE/linux-kvm/commits/tsm-next/ The host support is here: https://github.com/AMDESE/linux-kvm/commits/tsm Some raw QEMU sketch is here: https://github.com/AMDESE/qemu/commits/tsm-next Please comment. Thanks. The SEV TIO spec: https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58271.pdf Alexey Kardashevskiy (16): pci/dma/tsm: Call disable DMA bus hook on cleanup pci/tsm: Fix stale comment about TDI report range start tsm/core: Store range_id in pci_tsm_mmio_entry crypto/ccp/tsm: Use TSM API for DOE tsm-core: Register nevertheless x86/io/tsm: Allow mixed ioremap for shared+private BARs x86/dma: Revert "x86: Remove unnecessary architecture-specific " x86/dma: Add ARCH_HAS_PHYS_TO_DMA dma/swiotlb: Force shared DMA for allocatios from SWIOTLB tsm/core: Add TDI status coco/sev-guest: Allow multiple source files in the driver x86/sev: Pass HV features to sev-guest device via platform data x86/sev: Add GHCB calls for SEV-TIO x86/sev: Implement guest TSM driver for SEV-TIO (phase2, DMA) x86/sev: Enable secure MMIO (phase2) x86/sev: Flush IOMMU TLB for trusted devices Dan Williams (1): x86, dma: Allow accepted devices to map private memory arch/x86/Kconfig | 1 + drivers/virt/coco/sev-guest/Kconfig | 1 + drivers/virt/coco/sev-guest/Makefile | 5 +- arch/x86/include/asm/device.h | 13 + arch/x86/include/asm/dma-direct.h | 77 +++ arch/x86/include/asm/sev-common.h | 3 + arch/x86/include/asm/sev.h | 13 + arch/x86/include/uapi/asm/svm.h | 43 ++ drivers/virt/coco/sev-guest/sev-guest.h | 20 + include/linux/dma-direct.h | 2 +- include/linux/io.h | 8 + include/linux/ioport.h | 3 + include/linux/pci-tsm.h | 71 ++ include/uapi/linux/sev-guest.h | 12 + arch/x86/coco/sev/core.c | 148 +++- arch/x86/mm/ioremap.c | 2 +- arch/x86/mm/mem_encrypt.c | 5 +- drivers/crypto/ccp/sev-dev-tsm.c | 5 +- drivers/pci/pci-driver.c | 3 + drivers/pci/tsm/core.c | 3 +- drivers/virt/coco/sev-guest/{sev-guest.c => core.c} | 25 +- drivers/virt/coco/sev-guest/tio.c | 725 ++++++++++++++++++++ drivers/virt/coco/tsm-core.c | 16 +- drivers/xen/swiotlb-xen.c | 2 +- kernel/dma/direct.c | 3 +- kernel/dma/swiotlb.c | 2 +- kernel/resource.c | 63 ++ mm/ioremap.c | 2 +- 28 files changed, 1249 insertions(+), 27 deletions(-) create mode 100644 arch/x86/include/asm/device.h create mode 100644 arch/x86/include/asm/dma-direct.h create mode 100644 drivers/virt/coco/sev-guest/sev-guest.h rename drivers/virt/coco/sev-guest/{sev-guest.c => core.c} (97%) create mode 100644 drivers/virt/coco/sev-guest/tio.c -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421863.1648132 (Exim 4.92) (envelope-from ) id 1x6oDj-0003Ey-NT; Wed, 16 Sep 2026 11:54:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421863.1648132; Wed, 16 Sep 2026 11:54:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDj-0003Ep-Js; Wed, 16 Sep 2026 11:54:35 +0000 Received: by outflank-mailman (input) for mailman id 1421863; Tue, 15 Sep 2026 14:17:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Tyk-0002X0-Uk for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 14:17:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Tyj-007PK2-Sw for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 16:17:45 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9537a-bab6-0a2a0a5309dd-0a2a4501ce8a-30 for ; Tue, 15 Sep 2026 16:17:45 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa95388-5984-0a2a45010019-ac6904fea58c-3 for ; Tue, 15 Sep 2026 16:17:45 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id BDC386022A; Tue, 15 Sep 2026 14:17:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 692041F000FF; Tue, 15 Sep 2026 14:17:40 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="In-Reply-To:References:Subject:From:To:Cc:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789481863; bh=OkMqESzdj+3RbY/kyt0I+HkaA6aNmsfECfxsjJo32bA=; h=In-Reply-To:References:Subject:From:To:Cc:Date; b=Vgvg6Vf6N5nvwhVZWf8fGzDXd9ZlEfXfBBG/w2riqNn/dcr/s/Bb1Kjn5xCt4rLZO /FNDQs2/ZLouDowbLTAoG+bOsccbO7s5T82+OyYwfcX6um3B/KUl0YlT8/pOC1v+5f qfcdM1Uto9fEVYDQOYHZKjjKOlmt0lChn43XPsBWCwsrLtJFm1HSPrz2wnmJCfJh1M iDY+pqsv0fXbc6ZC9p6/TRWvhMishNU4m7IfF0kyo4cmqOO3eYQhyXTS5cVMxD4cbH zUx/KbsD7HuIXt8sdbPnV1BFxKYfT7hprxoA82Tbi0rgBmyLGJtCk7rqFPY/rZT2dM tUhop+sx6hp9A== Content-Type: multipart/mixed; boundary="===============5486250446856456697==" MIME-Version: 1.0 Message-Id: <2bb91d9868e07bedd1bc7a167a661b1f41e691d975184209c7e617adf551651e@mail.kernel.org> In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-2-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-2-0ad30c4c5ee7@toxicpanda.com> Subject: Re: [PATCH RFC v3 02/13] rcu-tasks-trace: Inline rcu_read_lock_trace() and annotate inside the reader From: bot+bpf-ci@kernel.org To: josef@toxicpanda.com,paulmck@kernel.org,frederic@kernel.org,neeraj.upadhyay@kernel.org,joelagnelf@nvidia.com,boqun@kernel.org,tglx@kernel.org,peterz@infradead.org,rostedt@goodmis.org,mhiramat@kernel.org,mark.rutland@arm.com,jolsa@kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,x86@kernel.org,catalin.marinas@arm.com,will@kernel.org,puranjay@kernel.org,xukuohai@huaweicloud.com,paulmck@kernel.org,frederic@kernel.org,neeraj.upadhyay@kernel.org,joelagnelf@nvidia.com,boqun@kernel.org,tglx@kernel.org,peterz@infradead.org,rostedt@goodmis.org,mhiramat@kernel.org,mark.rutland@arm.com,jolsa@kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,x86@kernel.org,catalin.marinas@arm.com,will@kernel.org,puranjay@kernel.org,xukuohai@huaweicloud.com Cc: luto@kernel.org,josh@joshtriplett.org,urezki@gmail.com,mathieu.desnoyers@efficios.com,jiangshanlai@gmail.com,qiang.zhang@linux.dev,jgross@suse.com,mcgrof@kernel.org,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,rcu@vger.kernel.org,linux-trace-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-arm-kernel@lists.infradead.org,xen-devel@lists.xenproject.org,luto@kernel.org,josh@joshtriplett.org,urezki@gmail.com,mathieu.desnoyers@efficios.com,jiangshanlai@gmail.com,qiang.zhang@linux.dev,jgross@suse.com,mcgrof@kernel.org,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,rcu@vger.kernel.org,linux-trace-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-arm-kernel@lists.infradead.org,xen-devel@lists.xenproject.org,josef@toxicpanda.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev Date: Tue, 15 Sep 2026 14:17:40 +0000 (UTC) X-purgate-ID: tlsNG-d62444/1789481865-1FA6E757-4D996BDA/0/0 X-purgate-type: clean X-purgate-size: 3513 --===============5486250446856456697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > diff --git a/include/linux/rcupdate_trace.h b/include/linux/rcupdate_trace.h > index 273c59a032512..4035054309d7c 100644 > --- a/include/linux/rcupdate_trace.h > +++ b/include/linux/rcupdate_trace.h > @@ -93,22 +93,20 @@ static inline void rcu_read_unlock_tasks_trace(struct srcu_ctr __percpu *scp) > * > * For more details, please see the documentation for rcu_read_lock(). > */ > -static inline void rcu_read_lock_trace(void) > +static __always_inline void rcu_read_lock_trace(void) > { > int n; > struct task_struct *t = current; > > - rcu_try_lock_acquire(&rcu_tasks_trace_srcu_struct.dep_map); > n = READ_ONCE(t->trc_reader_nesting); > WRITE_ONCE(t->trc_reader_nesting, n + 1); > - if (n) { > - // In case we interrupted a Tasks Trace RCU reader. > - return; > - } > - barrier(); // nesting before scp to protect against interrupt handler. > - t->trc_reader_scp = __srcu_read_lock_fast(&rcu_tasks_trace_srcu_struct); > - if (!IS_ENABLED(CONFIG_TASKS_TRACE_RCU_NO_MB)) > - smp_mb(); // Placeholder for more selective ordering > + if (!n) { > + barrier(); // nesting before scp to protect against interrupt handler. > + t->trc_reader_scp = __srcu_read_lock_fast(&rcu_tasks_trace_srcu_struct); > + if (!IS_ENABLED(CONFIG_TASKS_TRACE_RCU_NO_MB)) > + smp_mb(); // Placeholder for more selective ordering > + } // Else we interrupted a Tasks Trace RCU reader. > + rcu_try_lock_acquire(&rcu_tasks_trace_srcu_struct.dep_map); > } > > /** > @@ -120,12 +118,13 @@ static inline void rcu_read_lock_trace(void) > * > * For more details, please see the documentation for rcu_read_unlock(). > */ > -static inline void rcu_read_unlock_trace(void) > +static __always_inline void rcu_read_unlock_trace(void) > { > int n; > struct srcu_ctr __percpu *scp; > struct task_struct *t = current; > > + srcu_lock_release(&rcu_tasks_trace_srcu_struct.dep_map); > n = READ_ONCE(t->trc_reader_nesting) - 1; > if (n) { > WRITE_ONCE(t->trc_reader_nesting, n); > @@ -137,7 +136,6 @@ static inline void rcu_read_unlock_trace(void) > smp_mb(); // Placeholder for more selective ordering > __srcu_read_unlock_fast(&rcu_tasks_trace_srcu_struct, scp); > } > - srcu_lock_release(&rcu_tasks_trace_srcu_struct.dep_map); > } This isn't a bug, but the changelog notes that rcu_read_lock_tasks_trace() already annotates inside the reader "on the lock side" and then says "Make the trace variants match." rcu_read_unlock_tasks_trace(), four functions above the changed code in the same header, still calls srcu_lock_release() after __srcu_read_unlock_fast(), i.e. the exact ordering being corrected in rcu_read_unlock_trace(). After this patch the two unlock helpers in the file disagree. This has no functional effect (srcu_lock_release() is a lockdep annotation and compiles away without CONFIG_DEBUG_LOCK_ALLOC), but would it be worth either flipping rcu_read_unlock_tasks_trace() the same way, or saying in the changelog why only the rcu_read_{,un}lock_trace() pair is being changed? --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/34975311706 --===============5486250446856456697==-- From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422835.1648190 (Exim 4.92) (envelope-from ) id 1x6oDo-0004iK-0i; Wed, 16 Sep 2026 11:54:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422835.1648190; Wed, 16 Sep 2026 11:54:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDn-0004hr-QB; Wed, 16 Sep 2026 11:54:39 +0000 Received: by outflank-mailman (input) for mailman id 1422835; Wed, 16 Sep 2026 11:54:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDD-0003BS-H1 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:54:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oDC-00FQZN-U5 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:54:02 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8344-8faa-0a2a0a5109dd-0a2a45088c30-44 for ; Wed, 16 Sep 2026 13:54:02 +0200 Received: from [40.107.200.25] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8357-f659-0a2a45080019-286bc8197473-3 for ; Wed, 16 Sep 2026 13:54:02 +0200 Received: from CH2PR14CA0052.namprd14.prod.outlook.com (2603:10b6:610:56::32) by CY5PR12MB6250.namprd12.prod.outlook.com (2603:10b6:930:22::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 11:53:49 +0000 Received: from CH2PEPF00000142.namprd02.prod.outlook.com (2603:10b6:610:56:cafe::45) by CH2PR14CA0052.outlook.office365.com (2603:10b6:610:56::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 11:53:49 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH2PEPF00000142.mail.protection.outlook.com (10.167.244.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:53:49 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:53:26 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VTzZkWUgFSGTYEdYEZpPOMaVLEQhmQGq7QBUMCbWzotJQ27rAtQmjDP+9McdJ3+Qz/sUzSQQjoEminnXngDsnhUJLlmos9CTi9EOAycBw3LsUI+zk3luYdwCLlE+Oe7i+JYlp2ZQ14EDq4im4zIzlwZSdkGOSWlwn2CLRDnBfcKqUrE85+Vpfz/lUKwLFpYRmN3IsBcsTUPU7RDHs26AlbBReDMo7zlSilA6XdxPsEmUjOsJ9BjIhgNMQ7YcmrlnoW31AYHYVzKdK2MnDutinTdg19jp+cYj5iqut87RGiOdLEHW98ZsbKc93pfB3xGks/qX24tShdXW/8QwrsEmcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xdXMPNC37iRVDCMXKNEKZ2ifmpdSeHtP/V7TZt/SDC8=; b=Fe+LOHyb0f3R9Z0gTpvD88qAkXG6x4cnFREewCHQdG4dkhPWd65F27J0tmrFme+Pj8b7EvY9Ah38aOWwEVXKzeI7NsVBKxTw+RqBShVu20bRGfJLBgcMUI6CJIzS7pfFAX19ogoeC4kRD8ddrwPJ0gxbMEQBE1XJlIOAqIiRrZf92UAd8DVrGVBwVDbmzDPd1F6jBZSUc1JC2ZXBtsRM5n7mmDHgTE9TB5K3Ch17IfAYpmnPTUk20P50+CFRkOFzvR5PsJIF5KavfoU+KbFr/zuPtUs19Ot/k0oMD5Z5PTQbaHrjjM5qCOzl1L87SNMqYSplg1BH8YuVyrECFZm+MQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xdXMPNC37iRVDCMXKNEKZ2ifmpdSeHtP/V7TZt/SDC8=; b=fUWyDB4dKMWU3pNQM64UZ9R1E/1jXAdN/6P/dqK4FcokxpkI+zEkkScVU2SfrKYX32Vo9B8woMqS4wyNWcYEpzYehswUcnIGfjkhWsaszP7Jkdgt7lWY6ANDt4/u0I2m5bxDYCjb+gap9sRWg6r/Xii3Tt1llCKdN/HIt+bP8fs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 02/17] pci/tsm: Fix stale comment about TDI report range start Date: Wed, 16 Sep 2026 21:51:42 +1000 Message-ID: <20260916115159.1938195-3-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000142:EE_|CY5PR12MB6250:EE_ X-MS-Office365-Filtering-Correlation-Id: 368ef6c3-44c2-4fa8-6d72-08df13e92c0e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|32650700020|36860700016|7416014|82310400026|376014|23010399003|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: ty7fn9JOkvoiU24GPVZ/rmNQytrpaC2dhfMBHPhdzS00TZxP9WBKw5etuOyR9/ZWu2XQfWBGWkSaF7tmlvVKeZVMvFiZkVZMV4lOH00MqJdO9voSL4Z68EVgz+FY7R2pGsVQXtFvURVAFu3q8u+dl2exxvwB4eVgYe7crcTdoV8lr4hd6eN6HnmO51qX7eyzMRPLXQXQNpURKRaHOF99KIKMRwPmtBUm8LcvkLDBJiroyx0MJkncpp/0my7FU0IeQifDlirZuH0gXAkKO+gAG4rN5DP0MqzLs0MQvLlj0h6ezg+H7sF2QWO/jlQe8YyxBU4kitrVIvjdpTkls/SMRn1Ct6sKSCcHdHNzUeaf4cJFSEHdTirh/hwtT3jZv83FslMpXDnVmgKLD42MZqWNV7/fhFliSMJmd/KwGx7MD/i5gAUminPfEZJpsqoA/LtMtA2aeOCPpy2vdix3tbhjTEnASLqkdwmlM1tE3izZ6lEYqRwHCMepvS355O5VwM5KrvZTyuWEWSkAxSwuk96DQY1xxl/Mztr7El8q3VdfsPesBTpZpg869xG0kx9Sb3vMBVcI64R0d6UN+AkUINSbNwiCwk1oRSqtT1yx4UK0CpSEK3b2ZSK1WkVzcVSFu+JFKuS9aivdEPiiJ4QjM1bBZ/Nimxhbpia/x+La9XIjb+wOKtwQzkEnCmwTnYNLIKN1LLzOs8Ia79FoXUsN8zAgpw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(32650700020)(36860700016)(7416014)(82310400026)(376014)(23010399003)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 1EwaPy9VnUgtfRgZAzstYDIfAgiTyXKXlbJfuTIyKOwSN5Prp96/PGgZjfYrQj9CaYl+G7vqsaWOQ7FjVnIRoOEruayIAheJjkTsvujYuDKm3S69YPRakGGFruhoAQfg0sSGIyUf3X4ekMEq/dKreWVi2JuGOz+xy4UzjtJYPwmKb4TdsKkd5b/9XT/YuYhcEbT5JWftmCA0MB/ESbaAT0fma4wtJw6R/G8hNQMqCdAbxjQIUDXCTbd/73hpaexsaV8I1m5M11Ady04jbTZNDw1S2tNDcqky+Ufo0UenqmrqC0cVkZaRmr3LOy4h4AIHj1e6qnbhY8WVC5YGb2ZgrAmw/V1aB93n1bLO4VB1r+zul35eBo4BtftZbYjuuVXsTS9AtyCrVvVX7Y9yJ8LxKnHqEtHB2RNplComEIpjTGDwUzE/bRbIoJZwe3qv6nwP X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:53:49.6782 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 368ef6c3-44c2-4fa8-6d72-08df13e92c0e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000142.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6250 X-purgate-ID: tlsNG-c1860d/1789559642-CEF5F87B-3733CAFF/0/0 X-purgate-type: clean X-purgate-size: 846 The PCIe spec r6 and later defines the MMIO range start in 4K units which was not the intention. The upcoming change makes it a byte address. The structure is already fixed to match the new definition but the comment is stale, fix it. Signed-off-by: Alexey Kardashevskiy --- drivers/pci/tsm/core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pci/tsm/core.c b/drivers/pci/tsm/core.c index 9ac216ad896d..2a18be5be56e 100644 --- a/drivers/pci/tsm/core.c +++ b/drivers/pci/tsm/core.c @@ -623,7 +623,6 @@ EXPORT_SYMBOL_GPL(pci_tsm_mmio_teardown); #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_UPDATABLE BIT(3) #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_RANGE_ID GENMASK(31, 16) -/* An interface report 'pfn' is 4K in size */ struct pci_tsm_devif_mmio { __le64 phys; __le32 nr_pfns; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1421865.1648137 (Exim 4.92) (envelope-from ) id 1x6oDj-0003Kl-WB; Wed, 16 Sep 2026 11:54:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1421865.1648137; Wed, 16 Sep 2026 11:54:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDj-0003K8-Ql; Wed, 16 Sep 2026 11:54:35 +0000 Received: by outflank-mailman (input) for mailman id 1421865; Tue, 15 Sep 2026 14:17:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6Tyo-0002Yo-Fl for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 14:17:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6Tyn-002pto-Sl for xen-devel@lists.xenproject.org; Tue, 15 Sep 2026 16:17:49 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aa9538a-2eae-0a2a0a5409dd-0a2a4502a9e8-26 for ; Tue, 15 Sep 2026 16:17:49 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aa9538c-6ca4-0a2a45020019-ac6904feb846-3 for ; Tue, 15 Sep 2026 16:17:49 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 4F66E602C2; Tue, 15 Sep 2026 14:17:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C088A1F00893; Tue, 15 Sep 2026 14:17:44 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="In-Reply-To:References:Subject:From:To:Cc:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789481868; bh=rJvpLOWtutAdyJcIT4Epm9F/ufbvJwi0dK09wh/lipY=; h=In-Reply-To:References:Subject:From:To:Cc:Date; b=b5hKV+gKFGEYB++V/g0LCzL6EdpH+9azJH56tU91B+MKNmFVYfcfubRI+Z6jUwjfZ SEgnOeBs3bmkgqS7C1Kidx46+6Kxlpini01Qx0s2uUnpLOI7mdUSrPeOa7Y8lWQwY/ btfzDnYi+pjxUhgfSmgahplYapkq5Em2dbm/YNQOGAaK8WFvoovMEXiE7Xnr5EIpTo 8T6NeN//BDqwnyiMsnnAdm0lV97sGWugDZOU071h2RnNzNKJGDyAPMaQLiNiRqiaHf B+gACGttwahZzLIHSCmZ+UYbizeNXEZ+OsDwsHi8Uan3ZCzG/CrX19BajbqyLIeDGI ohwSxRnyNQGUw== Content-Type: multipart/mixed; boundary="===============3131281285391241463==" MIME-Version: 1.0 Message-Id: In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-1-0ad30c4c5ee7@toxicpanda.com> References: <20260915-b4-rcu-tasks-preempt-qs-v3-1-0ad30c4c5ee7@toxicpanda.com> Subject: Re: [PATCH RFC v3 01/13] entry: Pass pt_regs to irqentry_exit_cond_resched() From: bot+bpf-ci@kernel.org To: josef@toxicpanda.com,paulmck@kernel.org,frederic@kernel.org,neeraj.upadhyay@kernel.org,joelagnelf@nvidia.com,boqun@kernel.org,tglx@kernel.org,peterz@infradead.org,rostedt@goodmis.org,mhiramat@kernel.org,mark.rutland@arm.com,jolsa@kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,x86@kernel.org,catalin.marinas@arm.com,will@kernel.org,puranjay@kernel.org,xukuohai@huaweicloud.com,paulmck@kernel.org,frederic@kernel.org,neeraj.upadhyay@kernel.org,joelagnelf@nvidia.com,boqun@kernel.org,tglx@kernel.org,peterz@infradead.org,rostedt@goodmis.org,mhiramat@kernel.org,mark.rutland@arm.com,jolsa@kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,x86@kernel.org,catalin.marinas@arm.com,will@kernel.org,puranjay@kernel.org,xukuohai@huaweicloud.com Cc: luto@kernel.org,josh@joshtriplett.org,urezki@gmail.com,mathieu.desnoyers@efficios.com,jiangshanlai@gmail.com,qiang.zhang@linux.dev,jgross@suse.com,mcgrof@kernel.org,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,rcu@vger.kernel.org,linux-trace-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-arm-kernel@lists.infradead.org,xen-devel@lists.xenproject.org,luto@kernel.org,josh@joshtriplett.org,urezki@gmail.com,mathieu.desnoyers@efficios.com,jiangshanlai@gmail.com,qiang.zhang@linux.dev,jgross@suse.com,mcgrof@kernel.org,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,rcu@vger.kernel.org,linux-trace-kernel@vger.kernel.org,bpf@vger.kernel.org,linux-arm-kernel@lists.infradead.org,xen-devel@lists.xenproject.org,josef@toxicpanda.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev Date: Tue, 15 Sep 2026 14:17:44 +0000 (UTC) X-purgate-ID: tlsNG-720697/1789481869-317CA2AC-B009F15F/0/0 X-purgate-type: clean X-purgate-size: 1894 --===============3131281285391241463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index 2c64b388f6164..3d85035f5624f 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c [ ... ] > diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h > index 0bb6c03481fad..b811b469b0a77 100644 > --- a/include/linux/irq-entry-common.h > +++ b/include/linux/irq-entry-common.h > @@ -346,21 +346,21 @@ typedef struct irqentry_state { > * > * Conditional reschedule with additional sanity checks. > */ > -void raw_irqentry_exit_cond_resched(void); > +void raw_irqentry_exit_cond_resched(struct pt_regs *regs); Should the kernel-doc block above this declaration be updated with an @regs parameter description? Every other function in this header that takes a regs argument documents it (for example, irqentry_enter_from_ kernel_mode's block has "* @regs: Pointer to currents pt_regs"). Also, the kernel-doc block documents "irqentry_exit_cond_resched" but the prototype is "raw_irqentry_exit_cond_resched" - that mismatch currently prevents kernel-doc from checking the parameter list, so adding @regs wouldn't trigger a warning yet, but it would make the documentation complete for readers of the header. [ ... ] > diff --git a/kernel/entry/common.c b/kernel/entry/common.c > index e3d381fd3d251..e4acd50bd81a1 100644 > --- a/kernel/entry/common.c > +++ b/kernel/entry/common.c [ ... ] --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/34975311706 --===============3131281285391241463==-- From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:54:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:54:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422837.1648200 (Exim 4.92) (envelope-from ) id 1x6oDp-00050e-Dy; Wed, 16 Sep 2026 11:54:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422837.1648200; Wed, 16 Sep 2026 11:54:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDp-0004zq-8A; Wed, 16 Sep 2026 11:54:41 +0000 Received: by outflank-mailman (input) for mailman id 1422837; Wed, 16 Sep 2026 11:54:39 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oDn-0004h9-H9 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:54:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oDm-00HBSF-U7 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:54:38 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa836c-e002-0a2a0a5209dd-0a2a4503b7a8-44 for ; Wed, 16 Sep 2026 13:54:38 +0200 Received: from [40.107.200.51] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa837d-fae8-0a2a45030019-286bc833cfd4-3 for ; Wed, 16 Sep 2026 13:54:38 +0200 Received: from BN9PR03CA0556.namprd03.prod.outlook.com (2603:10b6:408:138::21) by CH3PR12MB9124.namprd12.prod.outlook.com (2603:10b6:610:1a7::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 11:54:31 +0000 Received: from BN1PEPF0001854C.namprd05.prod.outlook.com (2603:10b6:408:138:cafe::7b) by BN9PR03CA0556.outlook.office365.com (2603:10b6:408:138::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.9 via Frontend Transport; Wed, 16 Sep 2026 11:54:31 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF0001854C.mail.protection.outlook.com (10.167.248.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:54:31 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:54:07 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Urn84h68Kv1NiW1kUjFhGSLpejB7pKDouEqo54M/qmMxqqUURd6ehj7mM9xpJoyNrMOyUCwditYWutF0X2+l0E9N6rbyp7n7T93fYm75aTFSiMm3PWzBQ+EzDba/ohbFoxZMLDEtYQ1KMmI8f5qJucPcqUgzNSHQSRCwKOJghCsJdwF34jAnX0AJGV7mjpTDuVJ835sAoA+8mt2dLoBHWmWxVbsPI9P5Pn6LMSuK6og9lrcTYvcgozQynqSEb07n+m9GO1XMQ/tOeOWdpd9q73+IScNGeTdee02ynit+Phwjbohxr+Vsj9onyxl/yw6v5FMtv8Fn2PQ7QgGYuWBOaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OKUdPqVU6vcP8IIVfw9k2l6nR9BJplx9o3NZa4hjOck=; b=EDrGQU+zjyMIoBNBObg/r6jTe0H5NY8XWxArKdQBcDcekZYrh0UbRIh0tmCOcCfHp+dP6Wztd+oV40oofWIb4PFbFrxaTyiu/fxvMKTsdJyfUDuQBzh63awmNCIlzw2kxvb5izGceKhpYEkaujCzyL/utidKOJh+2vZjiyRqmTUXA9/cQePrUksl8uf6C0grj3ZJTzNp5u8EZzpUEviQPAjjmdTPZeGYvt8v8f/WO3Xzv8VITj5VSvEuFuOEads2rBd6M5Dm/XYx0+tsXPMX9v/5O/KZVSEJUGfxZpb+NPctjB7Uw3AuYXTo9rForv4T9S6RWtJhg4NX8Ej5WJRPrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OKUdPqVU6vcP8IIVfw9k2l6nR9BJplx9o3NZa4hjOck=; b=H4qYp44qyY8gpvkWf1Ci8lBKgSKe4gGnaL0LZRKfWPHAKK1lwWWi+ubOgacGhxO5O1FzaozHGsrB/86eOm8Ue4BleHqQnDCWrO2eOb1cPtrNH5hsFjJTDNBzzppowIKl9d0/tzYyGSbtYSUiVlSk/3S/fYLmtLs6HF6Luzu27Rw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 03/17] tsm/core: Store range_id in pci_tsm_mmio_entry Date: Wed, 16 Sep 2026 21:51:43 +1000 Message-ID: <20260916115159.1938195-4-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0001854C:EE_|CH3PR12MB9124:EE_ X-MS-Office365-Filtering-Correlation-Id: d59d45d3-0f08-439b-d6d0-08df13e944b8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|32650700020|7416014|376014|1800799024|82310400026|56012099006|10067099003|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: rI3FUyxtUsFrikLPRCWOe3jkIJpu8Ayez//FbHvA7EZPaqMJ28NzEM4VhJ4uFsUfHOrPAJb/7UHnkmYOiZsZByETBO7LqwDolMkGk+NuIkrgD4qgEv4RzEDqahiEUr6RmoqLOB4/nnuarOms1DULPJLjrKyDmeOUAEEoyYHWB5A273Gc3ieXPZf/pG8FYsRMtuGwuUM0kd2jypZAIucOFIPlseEW6Tidon+1+G+qvbnitCdEbepShhBJZCMdJvcbi2vS4qERdzgmPEUsJ3ylIy1Ob5JKPPqLHOQxCE0Qe2/CCLBuIYsjqzVwfGEXXNSuZ2BN207i2oGm20r9eqcOgEt3kaOz34+dHkchUmel6U3bjs2AQ+EvxIjcvZ+I/wsFwRJXZHaO71FmXafnt71PBAcdJEK6qVYfgqy2v5S3Uj+vyR+1IKmg6Rfr4z3YMDSg+ptuH+K9bmzONBteIzA0bli1GHUAA4BrfnH2iDkYHuBxYRfVK9Xxfa3cxTwYqdojQDJQ4wX9c/N0NYNBfz8h9ph3umCHa0RhWXWwSESKEBn+FZY+jNWIHHce+uQnoGNf7r5KtJkpLdjT8wtA4XS8UGoRQZRBGqToFDemJKAzlXlGC45dacLPHVyAKBXcIcQK1KSkr1cjUWaUbUoGTGzCb1wvFKZUGANi+ZFG81a1RXGumrPU+cxRi4EFst/iIx9UAMPQNzjE4joretksZWLINw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(32650700020)(7416014)(376014)(1800799024)(82310400026)(56012099006)(10067099003)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 3PXzb1uIYISSNMY+R0m2gI1Golc9yZxyHNjo9mqcVW1iX+W8QOAgaw0Jx0+Ta1VKAjQN4QvuQJSWrTEiqdmnJWGdsiX9SXLTV7KsO1jkKL+RbUtl3rM6lse+vVwlHmd+IzaKPKUqMnAJwfSIsMv+aCwgqXOJHqF/H7s5tLLKw2PLKZUtD1ZyNYccxLICbLJnupx7vGu1T6MszIipxPfFngv9Ym+30x0Q2ajKbHjL0uPDpj7E5wgANp2xo3ZVGlO1/icucw65fAYiw3XHyAOEuraigI/3+qS1j8myjEMuJ4CLxEAyULrUad8gSQ6vE9GGBcTDKo8iENf0+SwfAW4PoJeJq0iP70PPpGHtspLqITaJWMzTVVn3E+S6NBglTQqsv+5r2fAzrn5fFPMMl+5p05yA4VJJHiI+sj+qmhIWaBwI9YGSh9HQT9Re3VgfsDTs X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:54:31.0614 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d59d45d3-0f08-439b-d6d0-08df13e944b8 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF0001854C.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9124 X-purgate-ID: tlsNG-33051d/1789559678-77AC44E9-46B275BD/0/0 X-purgate-type: clean X-purgate-size: 1753 The pci_tsm_mmio struct represent a parsed TDI report which platform TSM driver will apply at the TDI accept step. On top of what the existing structure stores already, the AMD TSM driver is going to need a range ID for the PSP communication. Instead of calculating it in the platform TSM driver, just pass it along. While at this, set the flag as resource_contains() checks for the type when pci_tsm_mmio_setup() inserts the range. Signed-off-by: Alexey Kardashevskiy --- Not quite sure if IORESOURCE_MEM deserves a separate fix; also if it is just me who hit this. --- include/linux/pci-tsm.h | 2 ++ drivers/pci/tsm/core.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/include/linux/pci-tsm.h b/include/linux/pci-tsm.h index 6d5fadd79360..9b34304d9a1f 100644 --- a/include/linux/pci-tsm.h +++ b/include/linux/pci-tsm.h @@ -161,10 +161,12 @@ struct pci_tsm_pf0 { * @res: MMIO address range (typically Guest Physical Address, GPA) * @tsm_offset: Host Physical Address, HPA obfuscation offset added by the TSM. * Translates report addresses to GPA. + * @range_id: PCI BAR index for this range */ struct pci_tsm_mmio_entry { struct resource res; u64 tsm_offset; + unsigned char range_id; }; struct pci_tsm_mmio { diff --git a/drivers/pci/tsm/core.c b/drivers/pci/tsm/core.c index 2a18be5be56e..a197d56edbfb 100644 --- a/drivers/pci/tsm/core.c +++ b/drivers/pci/tsm/core.c @@ -746,6 +746,8 @@ struct pci_tsm_mmio *pci_tsm_mmio_alloc(struct pci_dev *pdev) entry->res.start = range.start; entry->res.end = range.end; + entry->res.flags = IORESOURCE_MEM; + entry->range_id = bar; entry->tsm_offset = tsm_offset; mmio->nr++; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:55:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:55:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422880.1648208 (Exim 4.92) (envelope-from ) id 1x6oEd-0007Sm-L2; Wed, 16 Sep 2026 11:55:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422880.1648208; Wed, 16 Sep 2026 11:55:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oEd-0007SC-Ht; Wed, 16 Sep 2026 11:55:31 +0000 Received: by outflank-mailman (input) for mailman id 1422880; Wed, 16 Sep 2026 11:55:30 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oEc-0007RU-IE for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:55:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oEb-002Sxm-Ut for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:55:29 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa83aa-8faa-0a2a0a5109dd-0a2a45078760-42 for ; Wed, 16 Sep 2026 13:55:29 +0200 Received: from [40.107.209.43] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa83af-b4ea-0a2a45070019-286bd12bd262-3 for ; Wed, 16 Sep 2026 13:55:29 +0200 Received: from BN0PR04CA0192.namprd04.prod.outlook.com (2603:10b6:408:e9::17) by CY8PR12MB7267.namprd12.prod.outlook.com (2603:10b6:930:55::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 11:55:12 +0000 Received: from BN1PEPF00018545.namprd05.prod.outlook.com (2603:10b6:408:e9:cafe::a) by BN0PR04CA0192.outlook.office365.com (2603:10b6:408:e9::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 11:55:12 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00018545.mail.protection.outlook.com (10.167.248.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:55:12 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:54:44 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TZy2ZJrkMF7OCH9yN7sKyjTdWF7pgDVN6EGs0NLiBABwnnfINtahWOBYqwOz/NWr6N0AN5xk3KZ9gnYsR5DRJMFpXYxh6z5BOA4SqDov1+Py1rv1VdX8JfLWi2Iu9VC//4ZTsve+l1KibkrziEneP494mzlK+fKQ8Y6ZYsA72HeYMG2Hr2hrH/eH1tEk+QrUFUMbjHI1RdRPodHPy4kbR8OzqIx9MnVk7cuU+a0TdPj82AuZaqRcYaxYTHwARqMM06dsFTyWbujX389/moTRtNEA9l6ZTCBwS/3FOhSuXIjxLzfOGe+Ae7jc9Z5xx92b3zLyVpM45P9ZGWWrKZixBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1fOSelVshB8tt+z9i3a63f+uWxxjJMxzG7NNd33A9O0=; b=jvahsYYrSSADIREzYZklS3cfIwMu0Zmjl3U5BvdwOD0bHjS79vNZLV1090cMPL6Uddm1Hw+ha8DsRIl6P3D7x0Ofg7n5e0eXwx40OjAREYnsDswkBOv39tT7q/bKNNpUmqXWpuNLksT0urT9O7eswM+0t9pB45isrHcK6lFqM8UdcQiBDw4Vb33gF6dsB3eyhqYeP32eJFGEnfmG5DILEG7wekx+bPb9r8qXvsuX1N7LC/toA2ovW1QUEOVq6z514RTOhjhfZBxnBBRn+Dlr186XJ+X6ysknfcEZXH08zx1mABhTDn64ZziAWAzDtRO8T9+PFyMF6nB9sRZuzltbiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1fOSelVshB8tt+z9i3a63f+uWxxjJMxzG7NNd33A9O0=; b=hJHVgTgw40xSH04nc9KEY2kTfcBikFvdZzQOK6y8fFdlPWQ206tziMwKbuHLq2YsQdsWnXpxBJBN+nC+uIlM7TQItN4B4LBXEVkNpnzIbo0qAVLlJlMgBl/jaNSuWF8TLglwQGLQXYoBSkSvj44AiMmqUoZVh4d3hV9YFqdWZsw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 04/17] crypto/ccp/tsm: Use TSM API for DOE Date: Wed, 16 Sep 2026 21:51:44 +1000 Message-ID: <20260916115159.1938195-5-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00018545:EE_|CY8PR12MB7267:EE_ X-MS-Office365-Filtering-Correlation-Id: 95b0368a-0e2f-42c3-de47-08df13e95d65 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|32650700020|1800799024|23010399003|7416014|376014|22082099003|18002099003|56012099006|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: 78xBYQC3+wj95ztS+jhBh7cicxBkBZUOOlFcfH+bxAVFisXGI8GTXus06sBoYkM4BHUkb5zK5O7yhQwpaF6Ip7ekJl/G+pCPCtnHlkIbjjDv8+KUNHhK+PJ5RhP6SlzTgoe81C/Eh+DyMDQXye78SzFJwQW40rgBDQmTb9VchioXMTf4z/5CzwrtVTOPqbyMg+Y8jjHpiDtfFf8zitapJgCESsXZOSM9HNHyJ0Um1NQ7D9s0uHUfcT/dzxDylcymM2S+Ld5yStPeE7mCxLl6qhrLFr3BSHwHwIQKghVjXLTcDnqt3GYaRiw1yz3V3OyeUjtuGPCVf3AbPcfXsEjBmGX3h2tdEuTQRVG2yu5p2hVO7DHZiUoLYTEA8rUsbspBT4rewvZj80kJwOFeoOC9mrD53/WOfp4jUrKfPm1SisbB+kyVpNsgZZv5etsg5Ftvdv2z1q+jSldsTRs0LfdHF3TNYwTFEs1O7ZDtHQkyvUMGi8Wd0Q4cAhiexEAvh9HeKXdpy7ly9noT4dc7jyjth76Lc412wIb3GxzcBx4uGvx9TbHy30dbUYFWfGVgiRyJ4kKr6lWWtTrwgeUS8GP8q2WbaMspMBnT3PljHdlQYUHCU206jA3P1Ax0KDSFRZmCQHobtyHO4o9tJVYCppnHdmpteVaf6qX9JvzuwR/35nR2qu87SdsvzIJ/RRzcLYid X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(32650700020)(1800799024)(23010399003)(7416014)(376014)(22082099003)(18002099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 2+d9WKfuRzwiWgMdluOVo4qJNhnH2FvmuZhqqjP8Ga5RudmSdxm4o30kD3JGM+JEJhea7Mw6INW7XT3nm6ypzdPviJMk9OK4Pvzn2FWUxcA7Vdl/e56ub2ci729tDDVfvh9CVw61K6ffH4bM+JOXA9hNl5odzX2HLX/1echQ9gdSp7MdJwUJI64mKFNnvbf9aUbAqNw4+4SJCg+XD9XffbZf6fjl0LBtuDu0HjfarKrIabaGlv54VhQ3oyYEtE9psLNTPckbXz1N2avdxAcXqsvWJ2kLmfkkwZ5KVqB55EFLafOAfCbw5IMEhQaZWZfVjmI54+4RWFQcol/rYF1TFVzsYPTn+eBGFcEeCuS6BT7+MsDtPowlpnYvJ/R4X0x3YM5wuUYpDWv4dKXLhb6UuiqPb5UM6Mz5WR/m9mvvSwqSgI6A6Nq+5hSnCXyY+hAU X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:55:12.4634 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 95b0368a-0e2f-42c3-de47-08df13e95d65 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF00018545.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7267 X-purgate-ID: tlsNG-ef75cf/1789559729-A70DDAE4-994594FC/0/0 X-purgate-type: clean X-purgate-size: 994 Compared to the currently used pci_doe(), the pci_tsm_doe_transfer() helper performs a few more sanity checks, use that helper now. Signed-off-by: Alexey Kardashevskiy --- drivers/crypto/ccp/sev-dev-tsm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/ccp/sev-dev-tsm.c b/drivers/crypto/ccp/sev-dev-tsm.c index 46f2539d2d5a..6e704ad239af 100644 --- a/drivers/crypto/ccp/sev-dev-tsm.c +++ b/drivers/crypto/ccp/sev-dev-tsm.c @@ -40,8 +40,9 @@ static int sev_tio_spdm_cmd(struct tio_dsm *dsm, int ret) /* ret > 0 means "SPDM requested" */ while (ret == PCI_DOE_FEATURE_CMA || ret == PCI_DOE_FEATURE_SSESSION) { - ret = pci_doe(dsm->tsm.doe_mb, PCI_VENDOR_ID_PCI_SIG, ret, - spdm->req, spdm->req_len, spdm->rsp, spdm->rsp_len); + ret = pci_tsm_doe_transfer(dsm->tsm.base_tsm.pdev, ret, + spdm->req, spdm->req_len, + spdm->rsp, spdm->rsp_len); if (ret < 0) break; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:55:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:55:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422893.1648217 (Exim 4.92) (envelope-from ) id 1x6oF4-00083g-0a; Wed, 16 Sep 2026 11:55:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422893.1648217; Wed, 16 Sep 2026 11:55:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oF3-00083Z-TK; Wed, 16 Sep 2026 11:55:57 +0000 Received: by outflank-mailman (input) for mailman id 1422893; Wed, 16 Sep 2026 11:55:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oF3-00082w-0m for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:55:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oF2-00A8hj-De for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:55:56 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa83c5-8faa-0a2a0a5109dd-0a2a4503e2ec-26 for ; Wed, 16 Sep 2026 13:55:56 +0200 Received: from [52.101.56.26] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa83ca-fae8-0a2a45030019-3465381a2b3b-3 for ; Wed, 16 Sep 2026 13:55:55 +0200 Received: from IA1P220CA0022.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:464::11) by PH8PR12MB7027.namprd12.prod.outlook.com (2603:10b6:510:1be::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.10; Wed, 16 Sep 2026 11:55:44 +0000 Received: from BN1PEPF0001854A.namprd05.prod.outlook.com (2603:10b6:208:464:cafe::29) by IA1P220CA0022.outlook.office365.com (2603:10b6:208:464::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 11:55:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF0001854A.mail.protection.outlook.com (10.167.248.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:55:44 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:55:20 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LQfhMPYkhD6AnR3K8tdXf9QINnpy/KelrwnnDKg8EXRBdKD5of7YfSCTWdYSnWOsr0I1VYtFD35pu4D2udoh2lwT7n+aWyHtcfLM8eiK+6MMLJnbiGXsAZ7g7/b0RZhuEjRnuK9qZFWawxSaB5ABeeYkymtRbvub0kuSGYcZTZgc5f3w7ZudNJye3VGGqZA9mRWofXcfvs3d4xoGVYv2yTkAKTz1JQV9yJsp9oX3ehDxru2HNYJAxnvuUe0rYlpjD87snl2N5POoCnMxVWdVdvi7fUSG3k9jm9EzBv/bfLH2Ck+YIwo5A3A52Y2CtCPdKsvHIjB8rUBJ7Bw4x84O/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v0t8hG0A53D6hUuYqrsRHML1F/umVz5zdX/nWs1UwOo=; b=EzdtJjB28ig+7GsTxViWodfdnFK6WufDnsBFEiO1UwZIo17Tcz25r3ejAPYwQJydY57Nl1h9wYB4IiARz1qyJs6NuD1klpbFoeDR6qXIke2xYhkWTyHALBr9cRTlrCBYbsI2lHbqgWF4N1b3eJuz/4sPgOqFRtYUUoa/of0m3KFZOqnWcohj1slFfaYBXPk8vLMsuhaUmvIAEmUZ/q6QU8sMW7QOnJdvFbm/nywajodTdM7mTFc49uPK0VyZqNanscCphpSWAE9S7XW7dsVbq/w1PnSnOSNgjq4/1cTW9hh3tdO7CQepZlV1RLYebeXM44aOtDLRC09UVng/PrzDQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v0t8hG0A53D6hUuYqrsRHML1F/umVz5zdX/nWs1UwOo=; b=msinSkf7Cpw75oiMTS2aiOWLwlb2KTeD6N02xI3NUB3lkqrXiCYf5cqgrZhvjcor9u0jz7IU2WTVgRWhwjRHkYRzThUKIqa2E80Ewfzu+4aQDo+fC6yLyJjOVWT/8zBaB8ULBRJoVWrIKVs7xr2fHRlUDzE85kFEG7NdNyGUS7o= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 05/17] tsm-core: Register nevertheless Date: Wed, 16 Sep 2026 21:51:45 +1000 Message-ID: <20260916115159.1938195-6-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0001854A:EE_|PH8PR12MB7027:EE_ X-MS-Office365-Filtering-Correlation-Id: f0628022-b809-4ddf-e51b-08df13e9703a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|36860700016|376014|32650700020|7416014|82310400026|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 7y+YJ5Z+OyMGOf2iurea6gWtIJXfcQNlJ0b9e0e2ih6oXqh9RVnwVlOKmPJLGMLMS6FZcGH4V6tgofrJMpnmvNmT3QePntJclBhTe4VKupQBAuiwbR9H79UATphkzqpFzkWlblZDDX9yazeeCUCNS5MpFkOetKOx02UbALu3b9eO5owPfy4OLOxFlFqV/o3vkI+bDZ8K7SDC05IwrAtkvFCQc5+HxLHYR/rpE+fg3arpfN+l8PnhQhB1b8uA/v7XsYGtzl1PKpYg2dVhJb1/nI5NGKqoKTMcPdCiu7vxkN84812ys0WVum587F9iiI05Eeu2pW/kTv0tkeZ0UFE1oS/gaDC+dxrummeYBtKnQon0zn+8VOMQSxAUrDajnM/ZA1b/+KaOCO1dlMauuUh3Om0Uz3TaS8Bjptwi0eOetEq8KZfzm32mXgwFsxjn/3x5v7nDS7Pwq6+ao5rhwXx9DgiIs+c04mY3+QYreV/B1j6V833CBCe9RDV3XCArkxJVka7fmYIE/hIftnRsQ19pRInVx/zRmYRnLEMVHorNHCIbSliJkLdTV6ioxSP1hU+nx4u2h7OEGQcbl7BYvtWHmTUpJydOz6Gr77oCqF4/sUyr/c5HERIvY/RPq1CQKe4suHTwchv99EAEG9HM54+eUwc5mstMh0e3kVG8B2bQxKjgvrTXE9XJjUQoVE1hbhdLidU1hUqNS/UcIjNiaYtHEg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(36860700016)(376014)(32650700020)(7416014)(82310400026)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 7gfBfw3cwrGt/CVo84j1pCRkyKykdOlikms4I9xrPxtU7a2fA0pHJxQRzxTWM+6b8a0csSjVoT8mKS6Fh5S4p3/YacTgzDsLs29wKHI/s+zpKWUZ9S53dJFYpvBTT8StmCj/fj7zbUsH6N3b3bTHkmBQGnkn/4VaLDkXK1yxeo1yCrpPf2lmJw5/PllWcJJ1K/31arILyJ5yLqnpqII+99EtP/UBjAfpsm3m91xjaz98+aj2kvIGKlc37TDCjygAK12BGRa0qB1t6adk5ILZ5QyUIz9UON+TI362rNKmbMy3uhfCJSbGQeiK/Z6JtG/alh0EOQsQ1KHtKtn0fEg+o8r4RyTZSwI8qaVd+PCCgOLfSASKmbQA3ZdpRcL0VYNSVfc+YyIvcuBrdeIIq8yhycKS3ykvz2dFWZDSJIsRnWvuMUrENy0ph0XkYNEq2Oau X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:55:44.0564 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f0628022-b809-4ddf-e51b-08df13e9703a X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF0001854A.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7027 X-purgate-ID: tlsNG-33051d/1789559756-770F64E9-65D6913A/0/0 X-purgate-type: clean X-purgate-size: 1832 When this and platform TSM are built-in, there is no way to control the init order other than alphabetical. Force the class init when a TSM platform driver registers itself. Signed-off-by: Alexey Kardashevskiy --- The alternative is making it a subsys_init() and drop tsm_exit(). --- drivers/virt/coco/tsm-core.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/virt/coco/tsm-core.c b/drivers/virt/coco/tsm-core.c index 0843b77c6549..accee6a5cba8 100644 --- a/drivers/virt/coco/tsm-core.c +++ b/drivers/virt/coco/tsm-core.c @@ -51,6 +51,7 @@ static const struct attribute_group *tsm_pci_groups[] = { }; static void tsm_release(struct device *); +static bool tsm_class_registered; static const struct class tsm_class = { .name = "tsm", .dev_release = tsm_release, @@ -58,6 +59,14 @@ static const struct class tsm_class = { }; static DEFINE_IDA(tsm_ida); +static int tsm_class_init(void) +{ + int ret = class_register(&tsm_class); + + tsm_class_registered = ret == 0; + return ret; +} + static int match_id(struct device *dev, const void *data) { struct tsm_dev *tsm_dev = container_of(dev, struct tsm_dev, dev); @@ -82,6 +91,9 @@ static struct tsm_dev *alloc_tsm_dev(struct device *parent) struct tsm_dev *tsm_dev __free(kfree) = kzalloc_obj(*tsm_dev); + + tsm_class_init(); + if (!tsm_dev) return ERR_PTR(-ENOMEM); @@ -254,12 +266,14 @@ static void tsm_release(struct device *dev) static int __init tsm_init(void) { - return class_register(&tsm_class); + return tsm_class_init(); } module_init(tsm_init) static void __exit tsm_exit(void) { + if (!tsm_class_registered) + return; class_unregister(&tsm_class); xa_destroy(&tsm_ide_streams); } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:56:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:56:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422900.1648225 (Exim 4.92) (envelope-from ) id 1x6oFd-0000Qf-80; Wed, 16 Sep 2026 11:56:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422900.1648225; Wed, 16 Sep 2026 11:56:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oFd-0000QY-5J; Wed, 16 Sep 2026 11:56:33 +0000 Received: by outflank-mailman (input) for mailman id 1422900; Wed, 16 Sep 2026 11:56:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oFb-0000Ou-85 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:56:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oFa-004czc-Kw for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:56:30 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa83d3-2eae-0a2a0a5409dd-0a2a4505b916-48 for ; Wed, 16 Sep 2026 13:56:30 +0200 Received: from [40.93.195.44] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa83ec-4cb1-0a2a45050019-285dc32c2906-3 for ; Wed, 16 Sep 2026 13:56:30 +0200 Received: from BN9PR03CA0220.namprd03.prod.outlook.com (2603:10b6:408:f8::15) by BL3PR12MB6572.namprd12.prod.outlook.com (2603:10b6:208:38f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 11:56:20 +0000 Received: from BN1PEPF0001854C.namprd05.prod.outlook.com (2603:10b6:408:f8:cafe::45) by BN9PR03CA0220.outlook.office365.com (2603:10b6:408:f8::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.9 via Frontend Transport; Wed, 16 Sep 2026 11:56:20 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF0001854C.mail.protection.outlook.com (10.167.248.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:56:20 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:55:57 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eu1rDpedbFlRmafQwHimTL2zpjqI6OnKvSPg9Cgt3hYuHfkU5jan9BFL4f/5mMj3e1+zKYrTfV2MP3UYyf6FT72J9oWO8ZLYglPsg+r42fpOkuqYAuQKs0bDNH5ueBumA5sJTkCwigmxX94BtGcTbmFh/v2U7uK02QUn5Qr/Xk6dCy9B4c+JZMWlBHBOaD4kmqhOpfniyJyYR9lyv0iy+a4cod7BhPM3ump9xYae6KltF4oHYrEDlGNxvNvB0/ZnNrekrCm116hWpFDVNZKDa66HPK9eMGcisBx8qiyhZYUq4cUrAHFOHWLwPXNpGJbUvfgKL21bq6fMtjScR5JXdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aCqYaRgrO+KLB88pTWh3Gi1rxQIXg5tUAStrI07396M=; b=UW1C31Q3ZMe5lzylroEIRDdlQWpL33tgWCFhwZ+FbScLUjm3lwEtx98dUT3nACRentiZuJKrlhHUAuor1f/Ugd6PQENRoMEQ2vF+e5LQjmYBYF/vjRmvqbYhCfzY5woJZWeS0gPa5f6Ft10ECJIzsRHn83wIcy+T7Y2m3JY7kUrykEoPqoeyw0wlJoMCSC47azoxh8Xu84CFqXUJOdj6N7KDzxLJcBC6AMb+39Vp9hCstbDyhREZt/H0+SdrIiC6YVRtdWfOQv4/4hrjFR9EhsqJfvZL5hIs0TbrANeqjvuzcRubAMK2g9CyeASLdJk4nEEfGzcmHUZwbMpVy+CC8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aCqYaRgrO+KLB88pTWh3Gi1rxQIXg5tUAStrI07396M=; b=byrgDqtZMilsSHENNMrnd3FZ6bJr030oMSRaGwqHUgCAurG+6q/KmZmZjvtsA/b4dD9IBYDwi66eYFBFv39PDsWU/ktcC5AIcn9r3O4VuQ8pGm/T6YmQ4AlOwiWlQ8s8plOk2r6Hc/OP5fpYe9ODvS+fi/e2DnX+ml01usyI/DM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 06/17] x86/io/tsm: Allow mixed ioremap for shared+private BARs Date: Wed, 16 Sep 2026 21:51:46 +1000 Message-ID: <20260916115159.1938195-7-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0001854C:EE_|BL3PR12MB6572:EE_ X-MS-Office365-Filtering-Correlation-Id: 5fce5108-a749-4aae-aa96-08df13e98612 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|376014|32650700020|7416014|23010399003|82310400026|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 6BNZ2mu0j6dBjBOVar6cacjJVAtU+Ps0QvoB+UKPyfiXU0JmH6UJ3nG3n498jJiMjdGnOwpW7UBXYOtT44Poq/xKUtMHnotRE3puTY4NJ+O8CafJ7+HSBblgv3k/uwv9fPuz7JvZnsNR8qXlBPSgeQ9xzubjsJzvrQZiaNUnPlYQADHO3PjStIamA0JKZoREOrP+P+kpR2PXfo4VohaKyHZvIUsh65WgixlWDO+4e4peveBLQjvvGQN/O5wvQ6KN9oOsufipv1XvSNw7NgsTtpTDWZx2vah76oHoSXdsrZ54R0yPDPinCQ4BIxgqewcnMyN9HzxQtkLWzigy8nDKWSQAVP8O0HorWnb2STJwYEP/wFHlfZy2lBUirpszgx7yPUJoV+ba3iwvAQeaV9xoTgTWrvF9cnztobl5qtyTj+cabWqeXHL5uafvI7WbGGIPgg+xQ61T9id1rFDi20OVavrcHhNJUcuA4jlvLbjSaAdBVQTbhd5CCWKny28oephlhWhS8xvhRVCZj86K470/82FJihQatdvsP6zs/F+w6j71OIlOpKQqs8bFzvNVuQkLW3qD8zTcIojUo7Zd9mX0OFowXKBOV5m+vmuaNRyHzv6V1O0TkVAvA0TtGH40LvBtxw5mQJDejCz82szBtGtP+L+LQ0Ckq3+9An/Pq9HmwTS1qnfOHbdX42W9zuZAHTKx8uGTPJedP1hORo1+MFW+cQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700016)(376014)(32650700020)(7416014)(23010399003)(82310400026)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 5PrUQXodM/RpiDtbczG0PNLIWYOlbcHbPuTp2HvrSbS1YRU3oRAcjy53d6eJrT/DIqnNGJ6s7ddDqWIQ+0vGw0xO+7dhSgYuNvKdI7bkh8z5FNNNuoj60dyZ14zgPqaRReLGHqESwmB0AFK0325GqPKOjsGjjykn6ZiH6Onp2LeKKQcD8/IupxwkrskjpEFpGMFfvwDK/Nb5tp3Np8hbHe6YDFNDb3luVK+KBbpUPwvI1wafyYjlrws9LPZjYEopf8hNKZyntOR7AUqpGGDGrEgulfL9flLPiEHVtEmZlJAbsqYXdQi0Kd31InIG8AC5xbgmWRvs9osMt8JHGWo+sLi2IZqb9t+qBZMJgGfYaQZXrUR14BTe8N6NS8bbnxtZSSz9qgwMzR7ou45rKp4ej0QHU42hlrvYL5z/EuaBgM2DU6Dww07lxLiMN/yfePZ+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:56:20.7036 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5fce5108-a749-4aae-aa96-08df13e98612 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF0001854C.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6572 X-purgate-ID: tlsNG-c201ff/1789559790-2551A2A1-4442270C/0/0 X-purgate-type: clean X-purgate-size: 6286 A TDISP device advertises private MMIO ranges via a TDI report. Upon transitioning to RUN, accesses to those must be made with the encrypted bit set in a PTE. A device can allow private access to a part of a BAR, for example, MSIX BAR (when MSIX config is not locked or MSIX is emulated by the HV). The existing __ioremap_caller() fails if not every single page has the same protection in PTE and this breaks device drivers (usually TDISP-unaware) calling pci_iomap() and such. Adjust __ioremap_caller() to map such MMIO BAR in chunks. Signed-off-by: Alexey Kardashevskiy --- include/linux/io.h | 8 +++ include/linux/ioport.h | 3 + arch/x86/mm/ioremap.c | 2 +- kernel/resource.c | 63 ++++++++++++++++++++ mm/ioremap.c | 2 +- 5 files changed, 76 insertions(+), 2 deletions(-) diff --git a/include/linux/io.h b/include/linux/io.h index 0642c7ee41db..9f5d5928f30c 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -27,6 +27,8 @@ void __iowrite64_copy(void __iomem *to, const void *from, size_t count); #ifdef CONFIG_MMU int ioremap_page_range(unsigned long addr, unsigned long end, phys_addr_t phys_addr, pgprot_t prot); +int ioremap_map_page_range(unsigned long vaddr, phys_addr_t phys_addr, + unsigned long size, pgprot_t prot); int vmap_page_range(unsigned long addr, unsigned long end, phys_addr_t phys_addr, pgprot_t prot); #else @@ -35,6 +37,12 @@ static inline int ioremap_page_range(unsigned long addr, unsigned long end, { return 0; } +static inline int ioremap_map_page_range(unsigned long vaddr, + phys_addr_t phys_addr, + unsigned long size, pgprot_t prot) +{ + return 0; +} static inline int vmap_page_range(unsigned long addr, unsigned long end, phys_addr_t phys_addr, pgprot_t prot) { diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 122f1eefb4b9..49d35b31f22d 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -444,8 +444,11 @@ walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 end, void *arg, int (*func)(struct resource *, void *)); extern int walk_soft_reserve_res(u64 start, u64 end, void *arg, int (*func)(struct resource *, void *)); +extern int walk_encrypted_mem_res(u64 start, u64 end, void *arg, + int (*func)(struct resource *, void *)); extern int region_intersects_soft_reserve(resource_size_t start, size_t size); +extern int region_intersects_encrypted(resource_size_t start, size_t size); struct resource *devm_request_free_mem_region(struct device *dev, struct resource *base, unsigned long size); diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 12c8180ca1ba..976ce6d5cf70 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -298,7 +298,7 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size, if (memtype_kernel_map_sync(phys_addr, size, pcm)) goto err_free_area; - if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot)) + if (ioremap_map_page_range(vaddr, phys_addr, size, prot)) goto err_free_area; ret_addr = (void __iomem *) (vaddr + offset); diff --git a/kernel/resource.c b/kernel/resource.c index 1b9cf2244b3f..c575ed87d67a 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include #include #include @@ -713,6 +715,67 @@ int region_intersects_soft_reserve(resource_size_t start, size_t size) } EXPORT_SYMBOL_GPL(region_intersects_soft_reserve); +/* + * Walk encrypted MMIO ranges registered for TDISP/TSM private device + * regions (see encrypted_iomem_resource). + */ +int walk_encrypted_mem_res(u64 start, u64 end, void *arg, + int (*func)(struct resource *, void *)) +{ + return walk_res_desc(&encrypted_iomem_resource, start, end, + IORESOURCE_MEM, IORES_DESC_ENCRYPTED, arg, func); +} +EXPORT_SYMBOL_GPL(walk_encrypted_mem_res); + +int region_intersects_encrypted(resource_size_t start, size_t size) +{ + guard(read_lock)(&resource_lock); + return __region_intersects(&encrypted_iomem_resource, start, size, + IORESOURCE_MEM, IORES_DESC_ENCRYPTED); +} +EXPORT_SYMBOL_GPL(region_intersects_encrypted); + +#ifdef CONFIG_MMU +/* + * Map @size bytes at @vaddr to @phys_addr using @prot, splitting the mapping + * when TDISP/TSM has registered only part of the range in + * encrypted_iomem_resource and per-page encryption attributes are required. + */ +int ioremap_map_page_range(unsigned long vaddr, phys_addr_t phys_addr, + unsigned long size, pgprot_t prot) +{ + if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) || + region_intersects_encrypted(phys_addr, size) == REGION_DISJOINT) + return ioremap_page_range(vaddr, vaddr + size, phys_addr, prot); + + while (size) { + bool enc = region_intersects_encrypted(phys_addr, PAGE_SIZE) == + REGION_INTERSECTS; + unsigned long run = PAGE_SIZE; + pgprot_t run_prot = enc ? pgprot_encrypted(prot) : prot; + + phys_addr += PAGE_SIZE; + vaddr += PAGE_SIZE; + size -= PAGE_SIZE; + + while (size && + (region_intersects_encrypted(phys_addr, PAGE_SIZE) == + REGION_INTERSECTS) == enc) { + run += PAGE_SIZE; + phys_addr += PAGE_SIZE; + vaddr += PAGE_SIZE; + size -= PAGE_SIZE; + } + + if (vmap_page_range(vaddr - run, vaddr, phys_addr - run, run_prot)) + return -EINVAL; + } + + return 0; +} +EXPORT_SYMBOL(ioremap_map_page_range); +#endif /* CONFIG_MMU */ + void __weak arch_remove_reservations(struct resource *avail) { } diff --git a/mm/ioremap.c b/mm/ioremap.c index c36dd9f62fd5..ccf938628e55 100644 --- a/mm/ioremap.c +++ b/mm/ioremap.c @@ -40,7 +40,7 @@ void __iomem *generic_ioremap_prot(phys_addr_t phys_addr, size_t size, vaddr = (unsigned long)area->addr; area->phys_addr = phys_addr; - if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot)) { + if (ioremap_map_page_range(vaddr, phys_addr, size, prot)) { free_vm_area(area); return NULL; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:57:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:57:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422911.1648235 (Exim 4.92) (envelope-from ) id 1x6oGC-00013Z-J2; Wed, 16 Sep 2026 11:57:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422911.1648235; Wed, 16 Sep 2026 11:57:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oGC-00013S-GK; Wed, 16 Sep 2026 11:57:08 +0000 Received: by outflank-mailman (input) for mailman id 1422911; Wed, 16 Sep 2026 11:57:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oGB-000136-2H for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:57:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oGA-004d8l-F3 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:57:06 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8411-2eae-0a2a0a5409dd-0a2a4503e5f4-6 for ; Wed, 16 Sep 2026 13:57:05 +0200 Received: from [52.101.43.42] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8410-fae8-0a2a45030019-34652b2a7b45-3 for ; Wed, 16 Sep 2026 13:57:05 +0200 Received: from BN9PR03CA0695.namprd03.prod.outlook.com (2603:10b6:408:ef::10) by IA5PR12MB999278.namprd12.prod.outlook.com (2603:10b6:208:603::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.11; Wed, 16 Sep 2026 11:56:58 +0000 Received: from BN1PEPF0001854B.namprd05.prod.outlook.com (2603:10b6:408:ef:cafe::5a) by BN9PR03CA0695.outlook.office365.com (2603:10b6:408:ef::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.9 via Frontend Transport; Wed, 16 Sep 2026 11:56:58 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF0001854B.mail.protection.outlook.com (10.167.248.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:56:58 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:56:33 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l+SiFZ7/hHfUrDLNpVjc22zytUw7mMLTkNxt2r69S/qdu0carYYohxObD3yjvEu5SQ+wuQB5XlBQtUYxqK23iFPpi97i/zOUOutR5bio1rYvBG7vh8eTJRa7JEw0ia8z1aSHpTYQV9X8xqC/ahDTR54v0kFasHb36sea796g42VVvgBkDCOetPJ0Ti3nNfTJvVd1PUzjB9O8r0JSoC7HMnvIQrSLvUt1YBqy1cqr9RBxrMuTan+xoxsIXP1WwomplLJ0+xvcYvBPi4OmcNiAP7EiSaA78S74jQsWh5GOi4LlWJkdJ1/y2eF7yfwSjql3kUPkYNY39HNyHj65MPauDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=U59zJdwFWF8Dtpjn0ZNqO7P2OXSyW40uUqet0Z5N1JU=; b=wH4q8IqwEmW9neFuBRcBWVeDfcDVooZbJzAoYEaB03BZq8MFLpsUT9SNJK4/LA1+cPPHIA8UtaSQYE8Vz1RTVNIa9rfTP/fHer1KhXxX1lTaK/UzA3lhHh3nQQn5R1aZ3R5w+suwK+v0PI+7JZC8V7KgAVILBkgZlDEfJ65S9rsEP4Fmv4pmpyJnPQ5r6jnRi1XUFYABorMStBPjUTLDXpYOsTKX33v/3rA93XuBvBQYsiPSgx0umdgkfSLyefokQkbvyDsV4Vs6YLjNVywjESue4wzmYUycoYcNYsDgcLwNQjWO72vQAAcdOuev1MzoOtkJqAjgxrLcRHyEUqS6zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U59zJdwFWF8Dtpjn0ZNqO7P2OXSyW40uUqet0Z5N1JU=; b=Gi07ps9CzGoJ81/8k6Wbcbo2i1+zlay2fkTSjAjFrf0a4xOQv7YRLHjN77rhDs7p8+Wl/5mvaQkQXXwzqAMUUyJYXlSoLYvgj6Azcig8qLvThcWeRs9bl2er29aN1DAyj9u4cBH66SYMUYPx3TzdI7HG720ZqjXhASc9Wc77DsI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 07/17] x86/dma: Revert "x86: Remove unnecessary architecture-specific " Date: Wed, 16 Sep 2026 21:51:47 +1000 Message-ID: <20260916115159.1938195-8-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0001854B:EE_|IA5PR12MB999278:EE_ X-MS-Office365-Filtering-Correlation-Id: 448520c7-a25f-43ce-e785-08df13e99c7f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|7416014|376014|32650700020|36860700016|82310400026|56012099006|11063799006|22082099003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: oWYjiIiilI1/ltPRVsCgLypCaO9vdfmAiW9o7bG/tLr2NRbsTlSQv8K3/d8rX5M3nVeN6TkYSM0w/F84RRGrLZsu2Ldkmc4ao/v8bnqwZasx5h5XVYDVuAsWhTTT9NFe6UpG4yaEsyyKCfdO9tOujEJEkc6RxwvGJD8pvPIwjcZe/hiQPRg9ahlPVTlPguqvcxaE0HlKapm8SZdVvh1v7e/GExGtg9hmAmQqi+88Ew0CeUueYnm2cOkNy4Hqh293Bp33eoouGRPfo2SJmIk6Kny0EZqIWDioPOOsC4H81BGc40CEsUhgdf1cThyOgmdWNPOgo2Qbl/SsdmoWPqNymLBymYwfIrB8blbG7dDXHC6wcqhv1eGLMJzbry36D/Aejm39ycmLZKQGzAPzJrIAXN/CzMR8MBpzyYhV/KYmnHaC5Xj8lCgybKAqQuavFgIdTHzm9LVsderQaU79gQoXCU+oWJDzAr295ed6KTXKdZZJg8gGA6Tbpd38JNDlPxoddI0RR14x2MijKrCrsoEGapRMVFegBZigvRmxXJqy2QrB+tPg81V4TV196umnkVC7nTxZQQOx0u03/i1SaUcNKHvonyCjMqj6V9gxIZbqRiXNrmla5PQFBCxnLFKFMm689C1qxvRd9yao6HBZMwM6/KCKXwGbz6i/RoOC18iiTPVntLke1mU7l6ZDhxJBnqvRbhtPwZCwBHfSwRyn0o0mDg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(7416014)(376014)(32650700020)(36860700016)(82310400026)(56012099006)(11063799006)(22082099003)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 06G2FJL0nKGF5TZJWtb7HCRGG+2PKlr27MT4WesUbZV0+gY80l88PL3BrmSeQ5beh70gGokCsKSRysqzfX3ciubcsIdAgmE4y0F4Ova3YxLQ5ozXQV8jIvB/ODOKm0hzPGI1pSwI1ByYd5u5QCjB0hPfjquA08XIbaOue6zkn1tV3Kn/gUAylPpox6/hZRAaJBMEj7DLM5b2wwi5kO0ZHkLwfHDI6r/j1crQDqupTVDXVqOuwF68hi1zCDtYsqvl3N1ntLgU3p8HTTB75Muqf9IMzhthlWMGQpWme4gTOH1dPPBGebMzKO/lwp4X8IixDkk8V5F7M20c7y6q0Em4t50tzsSw6gpQSlPcV8ahXZOZq4skJKBSdaGvLnoLoUvMa46yGRJkzCkyOSNOvQFGaxtyRraDo/hGmA4sggJrE4UwcXwFsqenewvBgglqYzrr X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:56:58.3314 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 448520c7-a25f-43ce-e785-08df13e99c7f X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF0001854B.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA5PR12MB999278 X-purgate-ID: tlsNG-33051d/1789559825-6E2D04E9-1805FCE0/0/0 X-purgate-type: clean X-purgate-size: 761 The trusted guest device DMA setup is going to distinguish encrypted and decrypted memory and dev_archdata is a logical place for it. This reverts commit c256d2a8adf2f5670ca262979c451ec4c1108e38. Signed-off-by: Alexey Kardashevskiy --- arch/x86/include/asm/device.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h new file mode 100644 index 000000000000..7c0a52ca2f4d --- /dev/null +++ b/arch/x86/include/asm/device.h @@ -0,0 +1,11 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_X86_DEVICE_H +#define _ASM_X86_DEVICE_H + +struct dev_archdata { +}; + +struct pdev_archdata { +}; + +#endif /* _ASM_X86_DEVICE_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:57:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:57:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422927.1648245 (Exim 4.92) (envelope-from ) id 1x6oGm-0001hm-SD; Wed, 16 Sep 2026 11:57:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422927.1648245; Wed, 16 Sep 2026 11:57:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oGm-0001gm-OL; Wed, 16 Sep 2026 11:57:44 +0000 Received: by outflank-mailman (input) for mailman id 1422927; Wed, 16 Sep 2026 11:57:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oGk-0001f4-BL for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:57:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oGj-002TLu-OA for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:57:41 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8425-8faa-0a2a0a5109dd-0a2a4504a492-44 for ; Wed, 16 Sep 2026 13:57:41 +0200 Received: from [40.93.201.71] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8433-b57f-0a2a45040019-285dc9474ad8-3 for ; Wed, 16 Sep 2026 13:57:41 +0200 Received: from BN9PR03CA0273.namprd03.prod.outlook.com (2603:10b6:408:f5::8) by DS0PR12MB999311.namprd12.prod.outlook.com (2603:10b6:8:42c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 11:57:34 +0000 Received: from BN1PEPF0001854A.namprd05.prod.outlook.com (2603:10b6:408:f5:cafe::a5) by BN9PR03CA0273.outlook.office365.com (2603:10b6:408:f5::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.9 via Frontend Transport; Wed, 16 Sep 2026 11:57:33 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF0001854A.mail.protection.outlook.com (10.167.248.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:57:33 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:57:10 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=e0hZQz2ly2aua2Z6ZGSh2w8G4Zwdd2zHDTyQNsPDeFJzZlb2avbBchHKRIOXzb49t7PxXqjLsMnzaMkk7mtwLM/MSNG/eUN2YuY2ZjLWnUIN6CNpo7+P9bHMduW9QiimGvNdsENfL4rP7XU8SjESAlIS89+aNYuw3/pWQ6YPX4O/Le0v01N/nKbEqP5EvHAXEXNM9Bl+TIqlTdwyCvWqusFJc8zKV9cFp0cUeeDx4gcQG4kMUHZCmrAH4HFysNBh7NJxP6vQnz15BJLDXqb5dasTR6R7xkNDD2KaeaPd0tU3D84yPwr+wql95dkgOJ8jwja4q4z8aClhEF0etnpgzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0HUBrkcanKP7HSIPLpfduG1GgH85AS/UaJthCpuaLQk=; b=PrcPtrvkgZBxuroIXC3TwasdGTxB/zfCXaknrPstK9/nn4DlIj4O3R46UmNjnE867EfRv87KVb+2+Ek6ExiZpz7H8KRK4Hp/rd6houOy+BH3W6EGiNGWI0Htqi3pTKjCvEv+ORDwONTxWGFFruqHaPMmV/LYCrjxKk+9zuDq81ZZ1Yg8DUkF5yuN4WTtg/Q007QLbOotsJvTU/OrPBQ4CF4HhO8SrRPlwIVcO+LU6NomEqyucPb9dSQTcbXuFyJPgpOb2k/vCCyUfPFO/6nV7egXG099zN1XXTFcnsgDQHgRbdDQdp8IKy3F1aG7F0mGze8isCWRW55dZbgpRO1N2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0HUBrkcanKP7HSIPLpfduG1GgH85AS/UaJthCpuaLQk=; b=QV15anIuuHWTYLolbBMi91et8XL9OGeDIsQrAoRT8BFl+I1U6jsdYMCz49LJNt/7euLhofzeBxsUagwjxE1osQAWRXh/yDwOPP8f0+3eJxyytEMzYqrift3pJO6sgoiae6d2gbRDI9fDDd2DheM97h8Gm6RT6vrDPpzLS43byX0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 08/17] x86/dma: Add ARCH_HAS_PHYS_TO_DMA Date: Wed, 16 Sep 2026 21:51:48 +1000 Message-ID: <20260916115159.1938195-9-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0001854A:EE_|DS0PR12MB999311:EE_ X-MS-Office365-Filtering-Correlation-Id: 812fd5a2-86d9-4479-97f7-08df13e9b1af X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|1800799024|32650700020|82310400026|23010399003|7416014|10067099003|18002099003|22082099003|5023799004|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: er94ITmWcnhrxhyFDFF8CA+wo3OcaYsqyrxyg8FsjvHuU9hbYcOn8yKJ8P9I9a6kAmssaycN1S60pGL/85Hz40P2Y07GKdnLBbE5aVSU7yKOJVYRTTzYDXONwHdAkp4KT9WaO9miG8qHfYuT8tRDj9n/p3qkJ75f0No+LFoexZJT0FCSK4OkfEYmH+fAvHNKjTnPnRHf0yQkY9i/YusrSpYYzODNqRZr9mSzV0nji0rDuy+fePlMkEe84ddhFFrHerpO/T9UwzZzahF42KDd8jGb89oWkRgq4U3qITSWdUMaHAvuY0MiukKz5gIr7Fa6tE2IXZjjtFFppFObdpCvVX5cZaK8u7l0CTjr9W1wQSxnnW0QeATbOVHQ5x4Jh3cGweFoRUKk95W2kDUXQUYF+EAiXIKtRxuquILQfmN6CiR0qsZFtwaGlJbR0uxNpf2jwx/v1J4eBfVBXKJ0r/QgOdEeimbiCSdIN8ORGcl6HEHuuiZGCLNsR8f73a7pkW6ZLDDfMRpc7B+ErLCTbDprdxhqK0aojQFf0Rc77jk3pAO4gZEHm89HDWrJGQHGfnFhwpcs96sYMG7HdFlD8COwEtJahgr9ul2CHc3td1kr4/4ek+EHfVg2qGB6XMCprqcVrjFXZw0tpKqFIjfEFFDaI7erOOMW8RRzdbL4T0DsJE18W7TTmtoOq2zYwB7ISP025qzd68WvKg7mhqXECJaxIw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(1800799024)(32650700020)(82310400026)(23010399003)(7416014)(10067099003)(18002099003)(22082099003)(5023799004)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Xt8sxNe21lwjTxCXMGse61wsz1HS5p7ZKAo4SfcdIkscuki7ds9IMSFXyuuHN+Rg+VAhJUDrULObfgnn2VVL75R3iStKXUY9kz1rH7C1OsEqT8PoH4W1aZrtox1ncrsG0LrgtMBr26FsKZgIni2keOEhhePVCe6WdFNrvJiLvQc9+VjtariGQ7y3M4iWyhQ29Zv5Vb8wUVIxiTEbZG7DVUzklH6KkbaFTdKBN4vSElKdJpOCIRl5LXgc03N5ZU58szdchfEgu1UsZJHbepmej50F+lrCm9Qb6F/HCmbkeSnaZWyEi6py/kqp8aRxZG8HdFi9quOamRi9EJ/lnCCmYXeEUwVx1FPKJrvDcXbArM+19SO/QbwysihNi7dbyYmLtw6MhD9o3UVYuFrCeP14A+jA1e6swbl/L5+yd+QuSCtmJRdIIsSwR3q/GNxmLRgq X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:57:33.8747 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 812fd5a2-86d9-4479-97f7-08df13e9b1af X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF0001854A.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB999311 X-purgate-ID: tlsNG-ebf023/1789559861-516D2B50-E489C5EA/0/0 X-purgate-type: clean X-purgate-size: 6805 Confidential VMs work with both trusted and legacy (untrusted devices). The trusted devices allow DMA to/from encrypted guest memory while legacy devices have to use SWIOTLB or share pages for DMA. In case of P2P between trusted and legacy devices, the trusted device has to perform DMA with T=1 (a PCIe IDE TLP bit saying "encrypt") but the target may be shared. One way of allowing the above on AMD SEV is using IOMMU sDTE vTOM feature which is a bus address: - below that address all accesses target private guest memory; - above - shared memory. Effectively this adds some high bit in a DMA handle to mark "shared" (on AMD). Copy the generic phys_to_dma / dma_to_phys helpers from include/linux/dma-direct.h into arch/x86/include/asm/dma-direct.h and select ARCH_HAS_PHYS_TO_DMA for x86. The x86 implementation is the same as the generic code for __phys_to_dma, dma_range_map handling, and SME encryption, with two additions for confidential devices: - cc_shared_dma_offset and cc_private_dma_offset in dev_archdata - when TDI is accepted is true, phys_to_dma() adds the shared or private offset (selected by DMA_ATTR_CC_SHARED), and dma_to_phys() subtracts it on the way back phys_to_dma() also gains an attrs argument so dma_capable() and swiotlb can pass mapping attributes through. Update the call sites accordingly. Signed-off-by: Alexey Kardashevskiy --- DMA_ATTR_CC_SHARED or __DMA_ATTR_ALLOC_CC_SHARED? --- arch/x86/Kconfig | 1 + arch/x86/include/asm/device.h | 2 + arch/x86/include/asm/dma-direct.h | 77 ++++++++++++++++++++ include/linux/dma-direct.h | 2 +- drivers/xen/swiotlb-xen.c | 2 +- kernel/dma/swiotlb.c | 2 +- 6 files changed, 83 insertions(+), 3 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 15fd9ec5ecac..c4df431e74b2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -112,6 +112,7 @@ config X86 select ARCH_HAS_UBSAN select ARCH_HAS_DEBUG_WX select ARCH_HAS_ZONE_DMA_SET if EXPERT + select ARCH_HAS_PHYS_TO_DMA select ARCH_HAVE_NMI_SAFE_CMPXCHG select ARCH_HAVE_EXTRA_ELF_NOTES select ARCH_MEMORY_ORDER_TSO diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h index 7c0a52ca2f4d..0dbc2c125522 100644 --- a/arch/x86/include/asm/device.h +++ b/arch/x86/include/asm/device.h @@ -3,6 +3,8 @@ #define _ASM_X86_DEVICE_H struct dev_archdata { + dma_addr_t cc_shared_dma_offset; + dma_addr_t cc_private_dma_offset; }; struct pdev_archdata { diff --git a/arch/x86/include/asm/dma-direct.h b/arch/x86/include/asm/dma-direct.h new file mode 100644 index 000000000000..37074c87bbec --- /dev/null +++ b/arch/x86/include/asm/dma-direct.h @@ -0,0 +1,77 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef ASM_X86_DMA_DIRECT_H +#define ASM_X86_DMA_DIRECT_H 1 + +#include + +static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr) +{ + if (dev->dma_range_map) + return translate_phys_to_dma(dev, paddr); + + return paddr; +} + +static inline bool __device_cc_accepted(struct device *dev) +{ + if (!dev || !dev_is_pci(dev) || !to_pci_dev(dev)->tsm) + return false; + + return test_bit(PCI_TSM_F_ACCEPT, &to_pci_dev(dev)->tsm->flags); +} + +static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr, unsigned long attrs) +{ + if (__device_cc_accepted(dev)) { + if (attrs & DMA_ATTR_CC_SHARED) + return __phys_to_dma(dev, paddr) + dev->archdata.cc_shared_dma_offset; + + return __phys_to_dma(dev, paddr) + dev->archdata.cc_private_dma_offset; + } + + return dma_addr_encrypted(__phys_to_dma(dev, paddr)); +} + +static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr) +{ + phys_addr_t paddr; + + if (__device_cc_accepted(dev)) { + if (dev->archdata.cc_shared_dma_offset && + daddr >= dev->archdata.cc_shared_dma_offset) + return daddr - dev->archdata.cc_shared_dma_offset; + + if (dev->archdata.cc_private_dma_offset && + daddr >= dev->archdata.cc_private_dma_offset) + return daddr - dev->archdata.cc_private_dma_offset; + } + + daddr = dma_addr_canonical(daddr); + if (dev->dma_range_map) + paddr = translate_dma_to_phys(dev, daddr); + else + paddr = daddr; + + return paddr; +} + +static inline dma_addr_t phys_to_dma_unencrypted(struct device *dev, phys_addr_t paddr) +{ + if (__device_cc_accepted(dev)) + return __phys_to_dma(dev, paddr) + dev->archdata.cc_shared_dma_offset; + + return dma_addr_unencrypted(__phys_to_dma(dev, paddr)); +} + +static inline dma_addr_t phys_to_dma_encrypted(struct device *dev, phys_addr_t paddr) +{ + if (__device_cc_accepted(dev)) + return __phys_to_dma(dev, paddr) + dev->archdata.cc_private_dma_offset; + + return dma_addr_encrypted(__phys_to_dma(dev, paddr)); +} + +#define phys_to_dma_unencrypted phys_to_dma_unencrypted +#define phys_to_dma_encrypted phys_to_dma_encrypted + +#endif /* ASM_X86_DMA_DIRECT_H */ diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index daa31a1adf7b..616b66ccf322 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -150,7 +150,7 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size, return false; if (is_ram && !IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT) && - min(addr, end) < phys_to_dma(dev, PFN_PHYS(min_low_pfn))) + min(addr, end) < phys_to_dma(dev, PFN_PHYS(min_low_pfn), attrs)) return false; return end <= min_not_zero(*dev->dma_mask, dev->bus_dma_limit); diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index e2538824ef52..915c174f8b56 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -55,7 +55,7 @@ static inline phys_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) static inline dma_addr_t xen_phys_to_dma(struct device *dev, phys_addr_t paddr) { - return phys_to_dma(dev, xen_phys_to_bus(dev, paddr)); + return phys_to_dma(dev, xen_phys_to_bus(dev, paddr), 0); } static inline phys_addr_t xen_bus_to_phys(struct device *dev, diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index ded7016a46a7..d7c7d15740ae 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -1764,7 +1764,7 @@ dma_addr_t swiotlb_map(struct device *dev, phys_addr_t paddr, size_t size, phys_addr_t swiotlb_addr; dma_addr_t dma_addr; - trace_swiotlb_bounced(dev, phys_to_dma(dev, paddr), size); + trace_swiotlb_bounced(dev, phys_to_dma(dev, paddr, attrs), size); swiotlb_addr = swiotlb_tbl_map_single(dev, paddr, size, 0, dir, &attrs); if (swiotlb_addr == (phys_addr_t)DMA_MAPPING_ERROR) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:58:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:58:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422938.1648254 (Exim 4.92) (envelope-from ) id 1x6oHL-0002Qp-9G; Wed, 16 Sep 2026 11:58:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422938.1648254; Wed, 16 Sep 2026 11:58:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oHL-0002Qi-3s; Wed, 16 Sep 2026 11:58:19 +0000 Received: by outflank-mailman (input) for mailman id 1422938; Wed, 16 Sep 2026 11:58:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oHK-0002QY-C6 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:58:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oHJ-00HC5l-OR for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:58:17 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8455-bab6-0a2a0a5309dd-0a2a4505ddc8-12 for ; Wed, 16 Sep 2026 13:58:17 +0200 Received: from [52.101.201.63] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8457-4cb1-0a2a45050019-3465c93f6165-3 for ; Wed, 16 Sep 2026 13:58:17 +0200 Received: from DS7PR07CA0016.namprd07.prod.outlook.com (2603:10b6:5:3af::18) by IA0PPF6E99B1BC1.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bd1) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 11:58:11 +0000 Received: from BN1PEPF00018548.namprd05.prod.outlook.com (2603:10b6:5:3af:cafe::24) by DS7PR07CA0016.outlook.office365.com (2603:10b6:5:3af::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.9 via Frontend Transport; Wed, 16 Sep 2026 11:58:10 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00018548.mail.protection.outlook.com (10.167.248.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:58:10 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:57:46 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NV6s6jceu/ZS4M3BPMMEluiazfdQPZuri/VXYG8FSfB8pF5RfGvI8kksyzvJh1cHeYt/hP8szR5ie159qViXlrh1SY9lGvhbu5dmTufyXT3sseJQWm7Pdf9lFLEPolNneGtHOSsAPz4dOhG6k/04XMJPxpRhi9RsKQf3/j3tDAfdc19utjvRzEEeURrMmYgdZniUX5L0/5du+sMEWpdDNq6CLuMA59yRjSJj0pM+vNWjCwJbkNMtb1QXcm20uIZu1+OR/cVOiIBt8lHb4RHA0/BWbFA+9vC5le/fcjxzpBZVjIBGuncX6s9Q7e+GYDbnsSjglIrstaxnFVONN1UZ0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UGeG5UViy26eddcMIwAbSGGeZIQdkW5rZ6uT6XlTNXE=; b=HgyaDOT99pzp46n9b4AsZkH2yBSKUG7QnzEUnYQY0d3JALrsGd4BQ175ZVfWaB/fAeQ3azTOA777KO3QyiJ5nGvIBZRctI3Hp01RwZB9MNObD9LC7jJVcXxkY6lelR683vnAao7EKvyM0D4ReLoDRIbMe3Ekd0Nkg4RWOIsH1FY7yC4XxFFuVD2NKkwwudPbVFDQEqFTF/Bc/jUMIl9FO0CF5+3XIGlczkJQlvL5frQ5W3h4UJvtcjvEG8TGICB7pcmiH/yVrQx9dlHzfO0x8Iz5iNKpRFxp1+uDRBVqWag6GTNRJ6yGjoPbFC5SZuiYOZXU4birCAg/yPJNAnXP0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UGeG5UViy26eddcMIwAbSGGeZIQdkW5rZ6uT6XlTNXE=; b=aotvzm2txPYMiNm37GYVZcv7nTGw4HjZldkCMfRHaQJlMMOX8qvwe9G9Rz8pgbK8ERMmHtcJhBs2ICDnRYXhQVvOv4OufpOw4mDEkaGW7vo6JlWmN2HF9VO8f/8dOBcSdgi3YXa9aQOmeqMyLY0xEDySEcjlpqVkM671GOxBUhY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 09/17] dma/swiotlb: Force shared DMA for allocatios from SWIOTLB Date: Wed, 16 Sep 2026 21:51:49 +1000 Message-ID: <20260916115159.1938195-10-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00018548:EE_|IA0PPF6E99B1BC1:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c3e0d42-9d65-43b7-68d7-08df13e9c79b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|7416014|32650700020|23010399003|36860700016|18002099003|22082099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: +GpeRrECie8z1D9ALNbaVkKslqe0K7+pREljkkHFWG+hTQaCiH4sIZT/MbiDR9MWL2T4L5pH8K9j6eQ0rPFIDktbKEJDVnSuavSQT1pE2jVKFVNcZeVDNx1QdN1qe+tQrVTtPfXe1thRZYFJl66uOmMmrKN4p4eZq3FxsS3dfsvFDmVKMuVncBGmBZ94WsHCgoFBLUSKVBOURsbaEoFJmN8osu4Q5Jdzr1Mlybij83EhAXICHeMQfZj3qDJW7raZ3TZvvNacja2NlGXKd/3Udyegr4sgtV/CWHzM+NlBC01JII9KMW+8CgIE6ADRG+b2l/ytc5sLzQGRZiHwgwS3WhB1kBADN6PSYOGmLGrvc03O66rDzvj9zt5ccDEaVWWDp4xN0o1v19z9238kLIaG3TFeJLDYOimtILWx9CEXluW4aDKRpNacF2iPneJboZ4b3NI7C885/y8n7nl/rlX3G8joXfFxsNYKvidXEIee3uDf67C9SEXZObD9PDP4YcmLGAJHNTwGORAMq61qBVd5+9on8qBAR2rWkQICNPkOEJKhdBxGAn3NLNCfoOJBbFOzvOWrGMQafUoTEqoIND74/TgH5zaPBLDC8XM1WgWm13XRATv7g8ynhEC9qN6OZMH1vv2U9Kf6jd3kloorCsRTL9A6DGb7AAJXpHbFlYdR7xiwANKrXsl/T/0jj9plvAsnMc4wMsrTs6HOkDX2GX7gVQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(7416014)(32650700020)(23010399003)(36860700016)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: N+QQCCWsHa7bqeHcyE9nTBdDa+bifDbun1axL/Jp+ouegH1jwRNDqGgZk9TnDMM0NkTrcFPDnH+mykQQ0BMSQxgY6hyIlPAIwKpGIAO+SlfWu1uY4kl2tIJYheErrmKT6AiYJLReu57IKXwx/n1iCmnQ/1sNR6Qx9rksJF+r7pSItlxQmXGUdxLCcqTz478u3FI20fTD5nJ7nyf37O4NpIHYbh3xpHya/3WGmaKBccRqqiF3pB0m10k//KIaBQcKbtyc1vuVtbYs5hu5q1T8AzJnqKlTvvdi8qtlFANfaGhlnhwnJA1w32iuN27yG1NExvnhRTcGPXtxAlggmbrjRRMf0VoeT0wKRj6X5ZhXvBNi9Egyrep6YAHcKOkokxnLq1riiT/QoWOY9upXNI8KANCUiE8B4qkM6/pLLtlzFqVPEro4k8b8NJ5zTk6WRHf0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:58:10.6516 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0c3e0d42-9d65-43b7-68d7-08df13e9c79b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF00018548.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF6E99B1BC1 X-purgate-ID: tlsNG-c201ff/1789559897-730B22A1-DB02D9F0/0/0 X-purgate-type: clean X-purgate-size: 1147 SWIOTLB allocations are always decrypted but the DMA layer is unaware of those and will miss to adjust the DMA handle. Force __DMA_ATTR_ALLOC_CC_SHARED if SWIOTLB is used for memory allocations. This will be exploited by AMD SEV guest vTOM feature where DMA handles of shared memory have some high bit set (not to be confused with the Cbit). Signed-off-by: Alexey Kardashevskiy --- kernel/dma/direct.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index da665ca22d5c..dacf513d45fd 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -273,13 +273,14 @@ void *dma_direct_alloc(struct device *dev, size_t size, } if (is_swiotlb_for_alloc(dev)) { - page = dma_direct_alloc_swiotlb(dev, size, attrs); + page = dma_direct_alloc_swiotlb(dev, size, attrs | __DMA_ATTR_ALLOC_CC_SHARED); if (page) { /* * swiotlb allocations comes from pool already marked * decrypted */ mark_mem_decrypt = false; + attrs |= __DMA_ATTR_ALLOC_CC_SHARED; goto setup_page; } return NULL; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:58:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:58:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422947.1648262 (Exim 4.92) (envelope-from ) id 1x6oHv-0003MT-Eh; Wed, 16 Sep 2026 11:58:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422947.1648262; Wed, 16 Sep 2026 11:58:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oHv-0003MM-Bp; Wed, 16 Sep 2026 11:58:55 +0000 Received: by outflank-mailman (input) for mailman id 1422947; Wed, 16 Sep 2026 11:58:54 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oHu-0003Ku-Ii for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:58:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oHt-00Gak7-Vh for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:58:53 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa846d-2eae-0a2a0a5409dd-0a2a4503bbbc-36 for ; Wed, 16 Sep 2026 13:58:53 +0200 Received: from [52.101.201.61] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa847c-fae8-0a2a45030019-3465c93d9270-3 for ; Wed, 16 Sep 2026 13:58:53 +0200 Received: from BN9PR03CA0782.namprd03.prod.outlook.com (2603:10b6:408:13f::7) by SJ2PR12MB8111.namprd12.prod.outlook.com (2603:10b6:a03:4fe::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.11; Wed, 16 Sep 2026 11:58:47 +0000 Received: from BN1PEPF0001854A.namprd05.prod.outlook.com (2603:10b6:408:13f:cafe::37) by BN9PR03CA0782.outlook.office365.com (2603:10b6:408:13f::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 11:58:46 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF0001854A.mail.protection.outlook.com (10.167.248.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:58:46 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:58:23 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=seol/ZRYlk9PRV/AE/0igGP4M475B8bTrWiYjR7Z5NVQdKgQ8Snt2Iybu43auxQTLklLTDj+/czXGPucm0VRfzcuHZnrtWsnzt9fa564LGCuzyXYB2wboIBU0JiXD2tXbkUw4vznR7ZJdYwkqjhER+nCBLKlLXXLD77GbCUVxF55cBM98geU4KyUAbObpDwGwPlX7OUjvnyQ/ErVPhnYwe35LYF2lgl5JKmTc092duqdYS/xqXIz44O5hNx1ujjZtaQrsdxqobZsO6EZPAGhyMogjMHX3oHd0JDOqY35plSg988uH9TBWL1tdirm3lgBThESwB5WN07dH7u6fQsegQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uN3TtTwM+bwTehqyvzEhtWdo/9tbU5sGc+GO4ttJXns=; b=XlTCsuXfh6cbbhbZNEiVEITWSHaHxkZnjq0bBeBSI5S9g72kOw6XGGLeK+K4EWewm32H7VlSEd4nr9nUOHdWNETpfESYKdGCr2rAYiTPH207To88lFcUGwNjCbRT5kfB/PfJJXyvT9Em+8pJ3/kxdg7x61bbkpD3JT9YQtyIVXR5ilk5oujw/aNZ0uubZrZfPpO/N0oLeVTV7PmLE9i4C+BeEl2/6Slm/wxe2mDrFRJf9rojTe83MvrKt2jeWQn8nrZyd2tWkH35wRnCkyEjLproJIrPBR1lP5u2c2UEo9YQu/qPilPg/lGoa9Pjy7GmzZv5ehcBcrlNaEp9KYwiZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uN3TtTwM+bwTehqyvzEhtWdo/9tbU5sGc+GO4ttJXns=; b=KNHRx1/uIQrLP/p1OqbUtpLgVwCk7UVtvYLpPsa2/jtKdsR4Vjqm3gQm0t1vp4EhK906ZcAgkkSaNp5GN9OT1xi2nBN7sRrVepy7neCrEzBcLk6mtscazitXsKE123nz5ng2gI1C17BYkbYjzOdNlcc5U03fFb1OlKx8D9A4k+g= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba , Dan Williams Subject: [RFC PATCH kernel 10/17] x86, dma: Allow accepted devices to map private memory Date: Wed, 16 Sep 2026 21:51:50 +1000 Message-ID: <20260916115159.1938195-11-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0001854A:EE_|SJ2PR12MB8111:EE_ X-MS-Office365-Filtering-Correlation-Id: c49f70c9-81ce-478f-dac0-08df13e9dd27 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|36860700016|7416014|82310400026|32650700020|11063799006|10067099003|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 1bJ49a9trfumDwoyn9MewgHhdhH/vcO7H1vXItEBAR2GcC7Oz87Mn2l/avJzWfkRSChnShOjFI7hXwvbMP4FfIal/XfkCyAQO06jw07jp3OKH8Fv14GY6YOHfTvUSlnHRxfsxtpJfmrCwkr9GnKg5GXYolHH8kdXZuVQtH+PnHROr5jB+rRKZUZkw+jMKi6EB5sMFZve0dHPB2LyTXPZfcqQSwRzRnMa9JPAmrYk6BmjpPlY/zGIZMRL4ogIwgoaoBWgr2X3fJECn8xofhkS/dPlWE1gm4LGMM32AysHf5mzmXFzDVjFx/CzkJpupwN0nH8TVL9pWKTlpIbIQXDjaLx+FkjqAMfx3fzEL7R4946H7Hyse1Woyyf1+rbrQX6IFOCMqIQA75eNFofO3sWviWdOBrpPfr3KmGpt74PsgqnSShJAKfS1rBPn1YyDMZkLp8IRElEVCiFMgecxLvI7J7mj2+8+4z5F1jrSmVH0Pm+vouATGQfb5p4qKwJd5g31NtCxqwjL3sFapbwogiTa2xbrqJegMhJ+hMbhT1MYg0hV+Xn4w7KKLhnAON+dlxkAOXrgjAYJhDrg6VqYsK3x1ZmsmutuwzCbubbgs27aDBSaTnor7fzVXyE4z3gIdRZrtCPFmFIGs1Lxt9GqNBFoPs+7N5a4otqlL9gf7mHsWsJ4fS9vrcN8OM8srKTIfIU3IRe3qhs521WNeSWpaqmQQg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(36860700016)(7416014)(82310400026)(32650700020)(11063799006)(10067099003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: qK/f3bcE1ASam6x2JuApZeSzxgwli4lwEhb+EPtO5GlbcvqWi2n0k+nCmOHidWa9c57wxnSKyVw6rpTH9uNaDmg3oJNXlIBXvGR1R/KFN/gP+3nnPsanWwrd57y/UdARYtTQx0oclZLQ0BGPI91gFjNkAlX5ujD1fxxig+qClAg8/i1f9m8YX9y28sjNZGmBEwP33TPzxrpHnN+hFi9AJNhz+zn1fgjuz4xCrtBlZIiJKBNAa55ix5MqPrc/Hp0hNMUb1/YlmECGfzThwtN1CwLiUVLLQlBKO1fcb1JIi5Qgv+5uPUz+SYTP5gl8NeH5pRlAUwiBM8wDq7PFX6NC37IA+rMpo1xfWlWcVjunL8MiE56oFApW110XZtgRGjDSOijBETZIzUKDFueWDJ8SMcnlpUO0wFZzFrYSoIR3W1JjxXGiUODmzMgF+4duPdAm X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:58:46.8022 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c49f70c9-81ce-478f-dac0-08df13e9dd27 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF0001854A.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8111 X-purgate-ID: tlsNG-33051d/1789559933-6D8D54E9-B0A20225/0/0 X-purgate-type: clean X-purgate-size: 1464 From: Dan Williams With the arrival of "accepted" devices, devices that have been enabled to DMA to private encrypted memory, coherent DMA allocation no longer requires page conversion. Update force_dma_unencrypted() to skip accepted devices. Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: x86@kernel.org Cc: "H. Peter Anvin" Signed-off-by: Dan Williams [aik: re-added device_cc_accepted()] Signed-off-by: Alexey Kardashevskiy --- arch/x86/mm/mem_encrypt.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c index 95bae74fdab2..805800ddbd79 100644 --- a/arch/x86/mm/mem_encrypt.c +++ b/arch/x86/mm/mem_encrypt.c @@ -20,10 +20,11 @@ bool force_dma_unencrypted(struct device *dev) { /* - * For SEV, all DMA must be to unencrypted addresses. + * Require unencrypted DMA unless the device has been "accepted", + * enabled by a TSM driver to DMA to private encrypted memory. */ if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) - return true; + return !__device_cc_accepted(dev); /* * For SME, all DMA must be to unencrypted addresses if the -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 11:59:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 11:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422959.1648272 (Exim 4.92) (envelope-from ) id 1x6oIZ-00043m-Ms; Wed, 16 Sep 2026 11:59:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422959.1648272; Wed, 16 Sep 2026 11:59:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oIZ-00043f-JO; Wed, 16 Sep 2026 11:59:35 +0000 Received: by outflank-mailman (input) for mailman id 1422959; Wed, 16 Sep 2026 11:59:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oIX-00043M-RB for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 11:59:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oIX-00FRjE-83 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:59:33 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa84a4-8faa-0a2a0a5109dd-0a2a4505b236-4 for ; Wed, 16 Sep 2026 13:59:32 +0200 Received: from [40.107.209.70] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa84a2-4cb1-0a2a45050019-286bd146568b-3 for ; Wed, 16 Sep 2026 13:59:32 +0200 Received: from SJ2P220CA0004.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5da::11) by SJ0PR12MB6832.namprd12.prod.outlook.com (2603:10b6:a03:47e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.11; Wed, 16 Sep 2026 11:59:24 +0000 Received: from SJ5PEPF00000208.namprd05.prod.outlook.com (2603:10b6:a03:5da:cafe::ab) by SJ2P220CA0004.outlook.office365.com (2603:10b6:a03:5da::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 11:59:24 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF00000208.mail.protection.outlook.com (10.167.244.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 11:59:23 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:58:59 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ofOgEZt5/WvZL398DiMP4cnJu+bAOQ7ChdryDjdv6oc3B+1IqZ5xoCor8N7Ik69lXihL8DalFNN9z171VyKvjWP7qM0DDXR3yLwNOmXuBqCv86Gbl8ba8tHqsafdCNrPxltMrbLTHvsJAE5IbcIcl+RldZJlImHm7npnTIGIzJJ1QMcy8I+eqcBMS9ZZqprVDYX2C05fuBYoOpwyswLPdGLbxffVcsQm3S+lV4Mtf7YbMTeFB9fehnnY8S4cHnUSdXF5aINmNiKz7F17iSKPebMKZAIN0MpN0ypjqkW2E4BYk1eFRto289kn9r4R9JwcoGJZ4lcE9S2+Jgiy17XQSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qTsg1utTkplWuARlA0qswoeLICanNrYPE/18/PBEUNY=; b=rmoiGjoh+6GgaL646m2gMAgAeOVhpofkBX3f/ONIo6agDbJ3NudbMju58xl+C1BXMLqHJHo/SJLgCu6OfZ6ClRdQOK+hdd+xThXKfg0ZOf8ObPpFogMdFYwFsuEVQyDlOqpg6yNgukAg4WRCIldL4HVzAGdtQX2nPGDjHKo/+CXnz1CXQERwq5BbbujDJTMzsYKKk4HZj6Q0ZmvdBb7+OwZZswtvWAkI3jaCClT3FPSNqo8ZTMgGcp9Xw0Zxm0nnnymV0tycimCtTkLIwfYtp4uFWIZo/SDWyrbE3/S4DfvtntmL3XIUE/P/cTKwfr6stSp1zjl52cvPMVYQHPKRMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qTsg1utTkplWuARlA0qswoeLICanNrYPE/18/PBEUNY=; b=wzwC6nfwNmFtjgfk9sDcnKOMQ04jGfMzMCsC94PMwXHTyprnLafBJ/OMhSdIIZT7e1gKWt5OaYurLNADb4gi+KaWK8d7Qz3Dv4f9nx3JwyUsO5xKzntXU9YygO+pNZBzDvE9YfRcVfyBpz6mQnPpD2GxVC7juJ3ZzS7smUM8JKs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 11/17] tsm/core: Add TDI status Date: Wed, 16 Sep 2026 21:51:51 +1000 Message-ID: <20260916115159.1938195-12-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000208:EE_|SJ0PR12MB6832:EE_ X-MS-Office365-Filtering-Correlation-Id: d8ed4718-0d0d-4492-fba9-08df13e9f352 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|7416014|32650700020|376014|23010399003|36860700016|18002099003|22082099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: 1gjrxiOzZs++uLN/08CsbVuU5pzivX1w5sGfokhVo62HhTqsZAyt2altg4jQKy61YsFa5Q4JpAePEy56dZ2EtjTCeKjExL81JRYHJiYMY2uEiMnekm+X4HfnK61KTogTrUDOSWqYPac0RXsqXDF4wcWCECweQL2O+qrasaKF9Ob2twna6aAPVekdisRqgLeJlZeWB+Pyy3Bj167PJL09ZDmneWPqJ/nWbZ0cNzIZ9Uqu+TxE79xdf2uWrFfFyctA02oysbQLQg7NUfSUI+121Lh84kpVXJKbsCp4RX8FM8vKws3J3lHABQArpnrkiLAf2KQseddH0TJq+Gv/qJeo3ppTVrTxG+l8MATdtE6Ao3U3P+6gT3P9M6R6/DAw+GSzx5a/5muRGjOlLBCzMMiMgoy/exC0T3bXU9lf4eS/7wyQMhaEBz721jzLwZwa2Dv1PivZYIiWNzz8ZjfwLrQbmMk5/p8DJ5F9/KW0TMkedGokdgxIMOBxpzKrj0WOPNZTSFL2PdgqRRvebRWS/tn5JkJTmIfnpT4wVrU/EEANzAHAwcREbazlGn77NGogt+eYeQ5dt8vAtItGg7Je1OTdf7apf9IzPoCJmzfouuIh9OdDINS2GF86XJJkhSUJfr/0LPVLQjFXnrujzmzz+zKMX+LG2m67WgXyvo8/Y0n5DPWZ4ATFg4mJDgroef2p5B6hrmxaAbtQhopAI4TWgp6URw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(7416014)(32650700020)(376014)(23010399003)(36860700016)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Fw53La2fWg2oO27psEqX3jIivEE3n3gbx3/xjn+KQHm1lz4FNVBajz48hTuLTPBt6uG2tVEbRRVvKQr7qSZv/THDK5/fsPRLILmlZp0+sWXWEMlp25tRTvdUlkvhgDpQhBBk7Xpw2/WNTNcciwCV4ENZvJuvlLVUt1sTm2llbK9DDNN55pWfltlQswjlh2XFTQbM3dBdqqt+eTE/9bviiGOC+WUEncGgm0s5E9hPqxwtrOEHu++p+E6DTbn76h4jtwoev54pqgHFtv9qpZ3UnUOsoBgI/lRE0iX1qfId86tWTOyfo3im62f04xW5+LNlhm5i3d1Ohcu/n4ZPM6reeV5E+Yufduo2+SyugUAxp87dhY4NTuBXalrrqjLQ46tVhj9YCY3Hk8coI/nSAbVxEzdI6mbCYS8c/Eerz4Y0bR2xhA+W8KI8DfNb2knsosaa X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 11:59:23.9209 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d8ed4718-0d0d-4492-fba9-08df13e9f352 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF00000208.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6832 X-purgate-ID: tlsNG-c201ff/1789559972-F56AD2A1-539BF0DB/0/0 X-purgate-type: clean X-purgate-size: 2853 Define a structure with all info about a TDI such as TDISP status, bind state, used START_INTERFACE options and the report digest. Signed-off-by: Alexey Kardashevskiy --- include/linux/pci-tsm.h | 69 ++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/include/linux/pci-tsm.h b/include/linux/pci-tsm.h index 9b34304d9a1f..2ca577e2a37e 100644 --- a/include/linux/pci-tsm.h +++ b/include/linux/pci-tsm.h @@ -11,6 +11,7 @@ struct pci_tsm; struct tsm_dev; struct kvm; +struct tsm_tdi_status; enum pci_tsm_req_scope; /* @@ -88,6 +89,7 @@ struct pci_tsm_ops { int (*refresh_evidence)(struct pci_tsm *tsm, const void *nonce, size_t nonce_len); + int (*tdi_status)(struct pci_dev *pdev, struct tsm_tdi_status *ts); }; /** @@ -331,4 +333,71 @@ static inline ssize_t pci_tsm_guest_req(struct pci_dev *pdev, return -ENXIO; } #endif + +/* private: */ + +enum tsm_tdisp_state { + TDISP_STATE_CONFIG_UNLOCKED = 0, + TDISP_STATE_CONFIG_LOCKED = 1, + TDISP_STATE_RUN = 2, + TDISP_STATE_ERROR = 3, +}; + +enum tsm_tdisp_status { + TDISP_STATE_BOUND = 0, + TDISP_STATE_INVALID = 1, + TDISP_STATE_UNBOUND = 2, +}; + +/* + * struct tdisp_interface_id - TDISP INTERFACE_ID Definition + * + * @function_id: Identifies the function of the device hosting the TDI + * 15:0: @rid: Requester ID + * 23:16: @rseg: Requester Segment (Reserved if Requester Segment Valid is Clear) + * 24: @rseg_valid: Requester Segment Valid + * 31:25 – Reserved + * 8B - Reserved + */ +#define TSM_TDISP_IID_REQUESTER_ID GENMASK(15, 0) +#define TSM_TDISP_IID_RSEG GENMASK(23, 16) +#define TSM_TDISP_IID_RSEG_VALID BIT(24) + +struct tdisp_interface_id { + __u32 function_id; /* TSM_TDISP_IID_xxxx */ + __u8 reserved[8]; +} __packed; + +struct tsm_tdi_status { + __u8 status; /* enum tsm_tdisp_status */ + __u8 state; /* enum tsm_tdisp_state */ + __u8 meas_digest_fresh; + __u8 meas_digest_valid; + __u8 all_request_redirect; + __u8 bind_p2p; + __u8 lock_msix; + __u8 no_fw_update; + __u16 cache_line_size; + __u64 spdm_algos; /* Bitmask of TSM_SPDM_ALGOS */ + __u8 certs_digest[48]; + __u8 meas_digest[48]; + __u8 interface_report_digest[48]; + __u64 intf_report_counter; + struct tdisp_interface_id id; + __u64 tdi_id; +} __packed; + +enum tsm_spdm_algos { + TSM_SPDM_ALGOS_DHE_SECP256R1, + TSM_SPDM_ALGOS_DHE_SECP384R1, + TSM_SPDM_ALGOS_AEAD_AES_128_GCM, + TSM_SPDM_ALGOS_AEAD_AES_256_GCM, + TSM_SPDM_ALGOS_ASYM_TPM_ALG_RSASSA_3072, + TSM_SPDM_ALGOS_ASYM_TPM_ALG_ECDSA_ECC_NIST_P256, + TSM_SPDM_ALGOS_ASYM_TPM_ALG_ECDSA_ECC_NIST_P384, + TSM_SPDM_ALGOS_HASH_TPM_ALG_SHA_256, + TSM_SPDM_ALGOS_HASH_TPM_ALG_SHA_384, + TSM_SPDM_ALGOS_KEY_SCHED_SPDM_KEY_SCHEDULE, +}; + #endif /*__PCI_TSM_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:00:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:00:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422969.1648281 (Exim 4.92) (envelope-from ) id 1x6oJN-0005ia-3d; Wed, 16 Sep 2026 12:00:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422969.1648281; Wed, 16 Sep 2026 12:00:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oJN-0005iT-06; Wed, 16 Sep 2026 12:00:25 +0000 Received: by outflank-mailman (input) for mailman id 1422969; Wed, 16 Sep 2026 12:00:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oJK-0005iB-T4 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:00:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oJK-007oXG-9g for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:00:22 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa84c6-8faa-0a2a0a5109dd-0a2a4502c49a-42 for ; Wed, 16 Sep 2026 14:00:21 +0200 Received: from [52.101.43.20] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa84d2-6ca4-0a2a45020019-34652b14f21e-3 for ; Wed, 16 Sep 2026 14:00:21 +0200 Received: from BY1P220CA0011.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::11) by MW6PR12MB8663.namprd12.prod.outlook.com (2603:10b6:303:240::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 12:00:06 +0000 Received: from SJ5PEPF00000207.namprd05.prod.outlook.com (2603:10b6:a03:59d:cafe::d) by BY1P220CA0011.outlook.office365.com (2603:10b6:a03:59d::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 12:00:04 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF00000207.mail.protection.outlook.com (10.167.244.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 12:00:04 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 06:59:40 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QOT7sVRXy9De2202CBbsIjMNa3wpE64zrj65FxGGKS7PGb1MplltqpoLeCUpGx7ERZpY3Wx3NAV/QLDD5ajZ8TWBhHAmA7svGZ0jRP+vm0EfeMRqzOra+gqEXc3wU2EUl3w5PL74Psv9aAjdKrMNFUdLmRVJkQK2/JK/tDQMJIp5RWvNbrsOmDMxwqf1AYrbxWIFO9Q6nLPhIlAHBFeZiskQzoJuvogtBFK//uDXAZC/DiazhNPFh9XmflxC3nO/YGV/6XeV9IWs6D0zAN0r07oXvJZZwudZ9ulmklLYQEAsk+qdJ/Qo0ulexhdhaCd/lK0XwXDFaXjI9mK24RPtWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jaFnTLlUeuS15Vco6JUFNTtjEg2/GLK2yLIZqCLTaAk=; b=Q5qrJsNAJXmzz0ze4iE6i1fEBUGJQFh0UxYftcksk8ufaz1yIDLcrj4GXAK8nACOLg6tFJdf36XWt0fiuVrvSDAcZVafTi+ehnmYjj/Bcc6GqwKJB0oncFHWsDbq+FKYYIVLek3mX2tJJhtqKAUChv3FCxISUBsAUFX4KWQw4+O+YaaDU2dxRiPqDCEHgUKL89cqNcuwbWD3oLQ5qPOjVAlgf7lgsqbw52wuZeaNyOWuVLUV5BeUYZvtR4ZH06sTqUsJchF4+DCIuIq/zDzCxVKC2Py6c7IvuS6xtZM5PncphGiKcCkKflcuw2KKxDCCQZ/KrxVKCadiD8iTS2wqng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jaFnTLlUeuS15Vco6JUFNTtjEg2/GLK2yLIZqCLTaAk=; b=gl3xaf2YW+xaUIdq/Ze4Vsnj1kQ2CrbCHsosjClYBGfqZKutdv3pYi+i/jzEWmd68FNLaEXIyXR//z2vbzRuO6R+38BRzH0IfFjoSr/u2P6BUTDTi5bwX8GkZ01py42Csy+noYDtShAmBDoL57gbb5TnjyLoMF0lpOHKJkgiW4U= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 12/17] coco/sev-guest: Allow multiple source files in the driver Date: Wed, 16 Sep 2026 21:51:52 +1000 Message-ID: <20260916115159.1938195-13-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000207:EE_|MW6PR12MB8663:EE_ X-MS-Office365-Filtering-Correlation-Id: 2b51706f-555c-417b-6072-08df13ea0b92 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|32650700020|82310400026|376014|1800799024|7416014|36860700016|23010399003|18002099003|22082099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: c1h/v5dfyxtiJ0WMVLNUDUgDxQatd0LMYdCKEY7e04HynA36o8DyKva5ruSvgqLaYCZoACqFUTHJK34ToQWM2MCCBg8Kk7vj/2plyvqelPReb5cAchDM+rTgWz3R7+Bnn8ph2gDyR2gM1wOZ3eh96GmQgRBj+zLT5cv5IdSYd3m2550ol3Ju1H9Km4MeCRVLxS3P5tQG7Q6T60yUsavCTOXu+/lSdcNSXfH4XlPCpgcpdFxRyqXRxBfbCDZiWLw0jYPQBg+gnHcm43Ypv3xHiGWQZTrQCmEP5i4jtweCR3YCmnazEVmPJCF5QstAYvxEeM743M1roHVrc9DqPuzMr8zHM0+lYfjxrS1wZoed/qJt1s5IE2AwGFgZuW7dDZtT6kWHu/51GndcomO9IWD/jwWkOFsL7bzdnTa7mI57odOgfeKiGNW5KML1b9MMJHQlon4dZskVmWAL8Sz4TeZsfI2snrZQqZHw1VeqP6cNOd1+SAikuN0yICPz2mmXFbsY9kDso0V8ykYrmJaFLk+T0sI6wo9CqW8wOzY2zQE86bI3j0nzMoUhX/M92d3xvTibl5Q8beTHkpAFkouRueVl86YNLgpODk3wkrrQXf65BdnneQuNWY7Gj2PWopz3bSypTYcLY/pRErszp3XubjRa2THlRPuWrl2ob/Hd5ZjCxnrdU7d5A7UKCUOQWy0Tr3m4DZo2fK5268pMv5G9i3j5zA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(32650700020)(82310400026)(376014)(1800799024)(7416014)(36860700016)(23010399003)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: mS/imRrmbpxps67qGJxsphoc6eABPi9uEQAis97tyVjMcE7n1lUTb6+nlr386lpHVT/77AfVBAUGjtAsAI5U9VXIwQoNQqyOCrtenVvuZ6eZw8IQ01EvVcJIJZKPAyUI4IO5d87YjfhcEbh3mwPSHX0ytq1np4FzH1zAlBJzgfTo8p0WT7ftEYpWH/8xtuWrky0lg7Vb96bVRK0Oeh6Z/Bqtz30YVY0Ax3IUkvh2HhjL40wS9DrhCJBLx7/jYYe/jKEXsV+a4EnUeg6An48phGGuN8HGBTtQ3lpe6CODT1Jd3R3JIsEO3VlQNWWwvtg/FD5FsLXAXzDKQGVzf+GeBuklrtxXE/UOq8e27ANdgmihgrEF0Zlccza6kUJgBTwzV1Cp83zG4TJU548hlWxppR2g/9S2jzp+mAiL2crSmfzp8SlYOzleDPsozfr+5czZ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 12:00:04.6040 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2b51706f-555c-417b-6072-08df13ea0b92 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF00000207.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8663 X-purgate-ID: tlsNG-720697/1789560021-F16AF2AC-FEBAE27B/0/0 X-purgate-type: clean X-purgate-size: 2248 Prepare for SEV-TIO support as it is going to equal or bigger than the existing sev_guest.c which is already 700 lines and keeps growing. No behavioural change expected. Signed-off-by: Alexey Kardashevskiy --- drivers/virt/coco/sev-guest/Makefile | 2 +- drivers/virt/coco/sev-guest/sev-guest.h | 16 ++++++++++++++++ drivers/virt/coco/sev-guest/{sev-guest.c => core.c} | 10 ++-------- 3 files changed, 19 insertions(+), 9 deletions(-) diff --git a/drivers/virt/coco/sev-guest/Makefile b/drivers/virt/coco/sev-guest/Makefile index 63d67c27723a..a8eb28b6736e 100644 --- a/drivers/virt/coco/sev-guest/Makefile +++ b/drivers/virt/coco/sev-guest/Makefile @@ -1,2 +1,2 @@ # SPDX-License-Identifier: GPL-2.0-only -obj-$(CONFIG_SEV_GUEST) += sev-guest.o +obj-$(CONFIG_SEV_GUEST) += core.o diff --git a/drivers/virt/coco/sev-guest/sev-guest.h b/drivers/virt/coco/sev-guest/sev-guest.h new file mode 100644 index 000000000000..b2a97778e635 --- /dev/null +++ b/drivers/virt/coco/sev-guest/sev-guest.h @@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __SEV_GUEST_H__ +#define __SEV_GUEST_H__ + +#include +#include + +struct snp_guest_dev { + struct device *dev; + struct miscdevice misc; + + struct snp_msg_desc *msg_desc; +}; + +#endif /* __SEV_GUEST_H__ */ diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/core.c similarity index 99% rename from drivers/virt/coco/sev-guest/sev-guest.c rename to drivers/virt/coco/sev-guest/core.c index 935537a41469..98f698809720 100644 --- a/drivers/virt/coco/sev-guest/sev-guest.c +++ b/drivers/virt/coco/sev-guest/core.c @@ -27,19 +27,13 @@ #include #include -#include + +#include "sev-guest.h" #define DEVICE_NAME "sev-guest" #define SVSM_MAX_RETRIES 3 -struct snp_guest_dev { - struct device *dev; - struct miscdevice misc; - - struct snp_msg_desc *msg_desc; -}; - /* * The VMPCK ID represents the key used by the SNP guest to communicate with the * SEV firmware in the AMD Secure Processor (ASP, aka PSP). By default, the key -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:01:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:01:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422976.1648288 (Exim 4.92) (envelope-from ) id 1x6oK8-0006F2-B0; Wed, 16 Sep 2026 12:01:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422976.1648288; Wed, 16 Sep 2026 12:01:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oK8-0006Ev-8K; Wed, 16 Sep 2026 12:01:12 +0000 Received: by outflank-mailman (input) for mailman id 1422976; Wed, 16 Sep 2026 12:01:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oK7-0006Ep-In for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:01:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oK6-00FSG1-Ud for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:01:10 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8505-8faa-0a2a0a5109dd-0a2a450caae8-8 for ; Wed, 16 Sep 2026 14:01:10 +0200 Received: from [40.107.209.45] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8501-f479-0a2a450c0019-286bd12de579-3 for ; Wed, 16 Sep 2026 14:01:06 +0200 Received: from BY3PR05CA0060.namprd05.prod.outlook.com (2603:10b6:a03:39b::35) by PH8PR12MB7206.namprd12.prod.outlook.com (2603:10b6:510:226::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 12:00:55 +0000 Received: from SJ5PEPF00000208.namprd05.prod.outlook.com (2603:10b6:a03:39b:cafe::43) by BY3PR05CA0060.outlook.office365.com (2603:10b6:a03:39b::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.9 via Frontend Transport; Wed, 16 Sep 2026 12:00:53 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF00000208.mail.protection.outlook.com (10.167.244.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 12:00:53 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 07:00:23 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RysGZKMHs1epu977SrAA1JJSXiIjQsbitUAUzo0og631gjBBRGn2BjxwjMCWcLdW9BsWVbm0Un2UWcNH5lE4IaOSolB+EkLLL8y2QC6InyHSCVH8JjNHWIpV/7BUTovPbEJnD7mVpQRQNLEHc8NGPHKTkozR+hormCPiq7qcpKgUF9ntpa0wTdJrnvqkVfL2LQAUffw4syw5+2lkQTDAErjXLyOf0hMFBwydmsV820C42XeGwt5YwL64AxB5caus6zS5j6nidzX9qAtb/5kccD2ijd+JMZACa8CX7RLp2vr6/GItAGOH+HS4AqSNrMwA18UolsJq2Z4l4JM/wgsoiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dA9IhLE51D9NYfND88bqQhl20dii5Ckm+YGWHKm39+w=; b=Zq0s1qpS2T2DBAuVG1kAZEK2avJylW2WibH619MTsPJcnmCtsy1p2I1ivYzWdNAhUd5neykHRhgupx2s/Y/JvUhW8/IYB16p0wipHiXVW+9efx5+IxkXcL2HtMZ1R8vdNDDp6ZzjPSoXYbwziqKk1+1JJOG2NhcAatzs/Zg/c3y02nnp1NjdPLp2UJAcxfugXovube426MkdH85A+meTpKT/FjzKXkiDvbMhda9Bgkqb/IrtggNSTMnaQAMb1vdTZlFzcOAJUdISU6JFE1SCbpzE9wik9Usi7b5LGY2ahxnVtfJunrT8l9Ypo3DQBW1JfoVcadkhf+whT9WGqV7WZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dA9IhLE51D9NYfND88bqQhl20dii5Ckm+YGWHKm39+w=; b=tAK/ysYqFM0Y9x2ZqU5FZKr3ii9y+n+d3OlTvslr4zPgMTQ/QxQBNp5eDczxHclEBLKTBi7+YVb+89H49gjSJ8nuWbfMQQb/vKu1imImgR00hozdC6mQ2b97US6CJSaqjungVhFJjkw/Jne+utrpAr9Lj6257hszIYPZukzEU2Y= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 13/17] x86/sev: Pass HV features to sev-guest device via platform data Date: Wed, 16 Sep 2026 21:51:53 +1000 Message-ID: <20260916115159.1938195-14-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000208:EE_|PH8PR12MB7206:EE_ X-MS-Office365-Filtering-Correlation-Id: a5d7f197-52a1-412b-0589-08df13ea2869 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|23010399003|1800799024|82310400026|36860700016|32650700020|6133799003|18002099003|22082099003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: ggHAuYoxRsyDmpK7PPMyGhSXUVaxMF5B6QiwogeqTKeq8nrUfoGbiuHNraN3dkd0skkFA3zEvpk+aJnVn1HM6Jq20t56aRiGcpH2o0cXLweg0liKmiDcCC0rVTLVDHw4zu0r5TqyXPV0r1wWtMiMs1/Irbo7Nfa6QDPUtnkUGtLIwNkNgcyeCTpUK90LpQ6qZx7P9ESt9G85MtUYrZLY7RfJ0gid8yc/pnrWXBcO+mQK5o2S5b7YhtmRIDgvztr55XrEh67vlroLgrNb8jaYr8nDMz4i/9lByCpQdb8yQy/5NvY556JdFYDckQVfFZI2EE58KtUVYUcuccC2dtXmn0VRjQ1R67mNN1M1TQ1AGf0mdo1JmD1iSqgrgeONVkGWhNHvACyMuymSAv3ODDMMoQFLYkLE64NgcdAmHWnBTTrLWTajZCIk6ab/c7FKNX/qohLNMdzlwlZVWHjClgupBMitwAspZw2ZsvbTVeCLcjVVRTx6nmWmM+mnCK1M1m0gYtN34UqUkVnyU13gu5hdjshHC6Y8qotNQMLqVVM/aMxuBIzK6oYFKFNMirClvOi9DljNzBUDiHa93ScnhQhL24WJIy4czyUnL7X+4c3NSoj3fn+TF9i5jKlmOtlFxBDjRVI5c2PokHHhJoP1BvEr3EHgaPtjCbeP96Q3CO9/FQ1p6QHskScpLi4OdNF500oQ+7BIGtxXXQ6/VNPe/nAfsg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(23010399003)(1800799024)(82310400026)(36860700016)(32650700020)(6133799003)(18002099003)(22082099003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 5VNspuapkH17wbM+rVXflo4XP8xHnthNl+oOZFPFwbu0ugA4FoP8rAAUVJs6Yka2Pf9TSkZj8jDB29CK112ociHjGt5B00jAIadlkGTdc2UI8GMXYt1VAeMUUb9rwBk/stqu34Adiy3P+T4PB9eMdUYUn3yiLdaPs4ogEouoY829E5R2JUSrc4IFcPwjvID1T1VQnqBeoAkvC1D+na+ouWQLZxfoeQGeuOcqF+t+YyAZnPqe18nMmY1Z8bLPTs3psdy259oc24hf1xtUyjag9UpQQjQPxYFPD6njODKts36lplHDLXD9rIosqr1OeZ74O8VI8Z1SbXkE9wuewkr4EEKRq0wMQ2nOLq9AW5ex0ZCC2BRhFwfJzrC8XLCib2BFQxENnEquSWrDi2eR7wEJZ/Y8ZNN7UyQLJbqXj9h2mdsKjd55xNr0uBVojEztnq9l X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 12:00:53.0122 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a5d7f197-52a1-412b-0589-08df13ea2869 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF00000208.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7206 X-purgate-ID: tlsNG-d25034/1789560066-51538A5B-53181225/0/0 X-purgate-type: clean X-purgate-size: 1679 The SEV HV advertises supported options via GHCB, the guest stores bitmask in the SEV core. The sev-guest device is a user visible platform device (/dev/sev-guest) which provides the interface to communicate with the HV via GHCB. It may choose to limit the functionality depending on what is available. The first user is going to be SEV-TIO which is going to trigger creation of "tsm" folders in the PCI sysfs but only if GHCB advertised such support. This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy --- arch/x86/coco/sev/core.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index cc292d7c6fd1..5b912f42f493 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -1381,11 +1381,6 @@ static int snp_issue_guest_request(struct snp_guest_req *req) return ret; } -static struct platform_device sev_guest_device = { - .name = "sev-guest", - .id = -1, -}; - static struct platform_device tpm_svsm_device = { .name = "tpm-svsm", .id = -1, @@ -1393,10 +1388,17 @@ static struct platform_device tpm_svsm_device = { static int __init snp_init_platform_device(void) { + struct platform_device *dev; + if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) return -ENODEV; - if (platform_device_register(&sev_guest_device)) + dev = platform_device_register_data(NULL, "sev-guest", -1, + &sev_hv_features, + sizeof(sev_hv_features)); + if (IS_ERR(dev)) + return PTR_ERR(dev); + if (!dev) return -ENODEV; if (snp_svsm_vtpm_probe() && -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:02:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:02:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1422987.1648297 (Exim 4.92) (envelope-from ) id 1x6oKx-0006m9-JW; Wed, 16 Sep 2026 12:02:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1422987.1648297; Wed, 16 Sep 2026 12:02:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oKx-0006m2-Gs; Wed, 16 Sep 2026 12:02:03 +0000 Received: by outflank-mailman (input) for mailman id 1422987; Wed, 16 Sep 2026 12:02:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oKw-0006lg-5j for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:02:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oKv-004eQD-IQ for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:02:01 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa852c-8faa-0a2a0a5109dd-0a2a4507cdc0-46 for ; Wed, 16 Sep 2026 14:02:00 +0200 Received: from [52.101.57.50] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8537-b4ea-0a2a45070019-346539324613-3 for ; Wed, 16 Sep 2026 14:02:00 +0200 Received: from SJ0PR05CA0076.namprd05.prod.outlook.com (2603:10b6:a03:332::21) by MN0PR12MB5860.namprd12.prod.outlook.com (2603:10b6:208:37b::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.11; Wed, 16 Sep 2026 12:01:35 +0000 Received: from SJ5PEPF00000209.namprd05.prod.outlook.com (2603:10b6:a03:332:cafe::8c) by SJ0PR05CA0076.outlook.office365.com (2603:10b6:a03:332::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.6 via Frontend Transport; Wed, 16 Sep 2026 12:01:35 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF00000209.mail.protection.outlook.com (10.167.244.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 12:01:35 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 07:01:11 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ez46YkTXVNPBaIsUDadQp2HbzH2MzSUTArP8XRKzrau9uH0KazSMpiFMJZ490AM5RobEp4q9wt2iGXMEqV57xqQ+7WNBr4fQGROO8j5yxCaL+8MNG//M8krALapxAMwhH0SHA7PhBc8BE4SSX8Gg0OXxj1uSPdPElVL0l4smWPJNuUUi82ixmSnYE3t2E0nNUcMhb1jyWUad1pBSjYrqdnXzQZ9OGeJk0LuHacrJV/l7JM+tMqyuwog0xwrnbxr92smLbFOpUWBAHJ0S6F7Z0UoYA18POj44sijrJP+kH/+UbdPpNP/1PIRKMvGs1DUhohi4AWy+05VycuHa+hrnqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=m5Wn2u7LMPCPQqnkaKjK7qt1ozlCRrR1eh6v97NBG5s=; b=dC4kPfCKMTsVvumw/AfwQJbkmA2qPNO9VhXvprucbnf+ClPy5GBqXj/tV0VDOf2g5yDmU0u3kPQdc/dBZ+tGAxSgry0KDbdk+UozBMtFTc4UVpv2hcxoxmcET0BtrW7p8YWVLeN2EMmJlBve0UzZsoImvYJ+T5uNcQro5PpgqhFTmVQfjUwK/KL/AxVBiCpG9LXMMX9WFxySQRqdg242zGeeUz+Ol/ak432vVMKWeabLzmlQDu4xGdWvridNCNHuqHZ40OGroIk/DF1zfd09DMAuWyMVZ5Fzr4n93OjBe3DrxRsxCXYA/8WmVCNSJpJOx+EsFYGqhMltn22NgCGadw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m5Wn2u7LMPCPQqnkaKjK7qt1ozlCRrR1eh6v97NBG5s=; b=RpT1pMU0oCMmamH88JBb2YcpTKg9WPNT5UC213Hyh3uJ2ZzAdSDTiHve1Mje7l3BusNT0TkBooD/4Qbrpjx4TnAppNG2+xKugKTq8jTIevcVjmt4MUN1IIdPrcPPPPxMNpDnuPscIwCJ0SAu8MamfhuIX1GeizOLAUYAiqFd8+Y= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 14/17] x86/sev: Add GHCB calls for SEV-TIO Date: Wed, 16 Sep 2026 21:51:54 +1000 Message-ID: <20260916115159.1938195-15-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000209:EE_|MN0PR12MB5860:EE_ X-MS-Office365-Filtering-Correlation-Id: 43b471b3-312e-4f11-3c46-08df13ea4171 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700016|32650700020|23010399003|7416014|376014|10067099003|3023799007|6133799003|20052099010|22082099003|18002099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: /5G+nkTNRMJNQGSuiS6RRZKhS/KhosBx1ar6A3U+Yen4hddWoqMH8sZ3wb207pdmlf0+n/OzPd/tDMYtXqhUUSVV1cPUQ8F0erZvNy6rM/w6QV8wI/3i7R92YCzdRuxztFT05eYuD1VphA9OBQ1iM1Cw5YjQnrR1cQhe1GMX/T7+lB7WgHV2DFFqnZePUqxNodAa/Imy8E4w+nNI2OXHRKchZyt+I95+JXZj8Ww4qsCEvsPhzpEcM/JFQgSTpiSrjROv38LiYhzlpTW+O41JTbJPqj4GWBLFT5esxRrw136PSiIhRppB/qqNKj6DkLGUjpO7nQK3klmH6NDYQ8Uy9OuJSuRLay4fy8FwEOCrI54/BjnWWiHslCVUMoD7pHg8/sn4WcUc9MnM7rS1MoD+Tsic0kR4DsMjM8I8JQ4x7BjAv1Tob2/14Kvxoh82LRwbhsZrIZuhuKF2Q8B2nCJSiN+dbS6FAY1W7m/ULAGzT2Ey6rt4cJtRxkvAtEeH62ozmZIBcxg4Q5y5JQL93YMM/F20OqMGA+v2k89I8WiSaEh7Z0hvlHQ/1anLCNqI2jbHJ3atWpbmXAbPazrzonBx9HP6m8/vlg4rQs3J1QlaGF6HYKZaZM0Z6YsuplxSNzGoR3K9NIyLylTwMPtZE3FjYtWqp/1oCWdduhO0VRo7g1XoMXRTWtgFYjZon5qA+8wfMD30YexillBF9Jp4aRT7Sw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(32650700020)(23010399003)(7416014)(376014)(10067099003)(3023799007)(6133799003)(20052099010)(22082099003)(18002099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: KGWqrxMpevRTUyLVG3M4M4v9Z+GrPszOWDRjjAtKr8gD+oIKekSZU1I1NEkcyDv7jCtK/HW59j+Q01lJZ5+zIvQt1Yhwllk/712KIEfEkfOUWdb9QDW/f1PSxKSNWqwa2Pogq0I/jKyYueKaGIv/XT+r1HVArzdQkAJ9qVWcdO8aFyoGyd/UNzEmgh0Tn/FDwDD2A8AT+3wBP0YhiGrwfhBW46lVveiCmlm6+h+mUnz3dFWiK9l4XDhlwlulUqJFOWY+5qRerR47gP50Op8Fn9lkliy0er94KZgjh1e2zYnNzdsI6FqJ8zf7rDPycm/1ljgPBc1U3QKNG8CeLDr9L3ctPipWjYJoyohqqivWF7/UVU1ZG0BjMPaUwVLmS9cN0G664BHbQ3K+kBgAKtcvax+3dNsK0RA8i0eVE/WZXPRECrI/mCBS5Waf/5k8hME0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 12:01:35.0080 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 43b471b3-312e-4f11-3c46-08df13ea4171 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF00000209.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5860 X-purgate-ID: tlsNG-ef75cf/1789560120-A7ED6AE4-7EA0D2D8/0/0 X-purgate-type: clean X-purgate-size: 7346 SEV-TIO is a PSP protocol allowing PCI pass through of trusted devices (TDI == TEE Device Interface) to an SNP VM. The VMM advertises the support via HV_FEATURES and implements new calls: 1) TDI operation: the host executes on the guest behalf: - TDI bind/unbind to/from the SNP VM in the PSP; - TDI start/stop which translates to TDISP interface start/stop. 2) TIO guest request for an encrypted communication channel between the SNP VM and the PSP, it follows the existing Extended Guest Request pattern to read device evidence: - get TDI status; - validate MMIO ranges (a variant of the PVALIDATE instruction for MMIO RMPs); - configure sDTE (a secure IOMMU descriptor). Extend snp_req_data to pass more parameters. Signed-off-by: Alexey Kardashevskiy --- arch/x86/include/asm/sev-common.h | 1 + arch/x86/include/asm/sev.h | 5 +++ arch/x86/include/uapi/asm/svm.h | 40 +++++++++++++++++++ arch/x86/coco/sev/core.c | 42 ++++++++++++++++++++ 4 files changed, 88 insertions(+) diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h index 01a6e4dbe423..ff763c3c5d63 100644 --- a/arch/x86/include/asm/sev-common.h +++ b/arch/x86/include/asm/sev-common.h @@ -137,6 +137,7 @@ enum psc_op { #define GHCB_HV_FT_SNP BIT_ULL(0) #define GHCB_HV_FT_SNP_AP_CREATION BIT_ULL(1) #define GHCB_HV_FT_SNP_MULTI_VMPL BIT_ULL(5) +#define GHCB_HV_FT_SNP_SEV_TIO BIT_ULL(7) /* * SNP Page State Change NAE event diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h index 9e7a077c445d..89aaccb053ba 100644 --- a/arch/x86/include/asm/sev.h +++ b/arch/x86/include/asm/sev.h @@ -149,6 +149,9 @@ struct snp_req_data { unsigned long resp_gpa; unsigned long data_gpa; unsigned int data_npages; + unsigned int guest_rid; + unsigned long npages; + unsigned long param; }; #define MAX_AUTHTAG_LEN 32 @@ -597,6 +600,8 @@ static inline void sev_evict_cache(void *va, int npages) } } +int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id); + #else /* !CONFIG_AMD_MEM_ENCRYPT */ #define snp_vmpl 0 diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h index 010a45c9f614..93597ad492bf 100644 --- a/arch/x86/include/uapi/asm/svm.h +++ b/arch/x86/include/uapi/asm/svm.h @@ -122,6 +122,44 @@ #define SVM_VMGEXIT_SAVIC_REGISTER_GPA 0 #define SVM_VMGEXIT_SAVIC_UNREGISTER_GPA 1 #define SVM_VMGEXIT_SAVIC_SELF_GPA ~0ULL +#define SVM_VMGEXIT_SEV_TIO_GR 0x80000020ull +#define SVM_VMGEXIT_SEV_TIO_GR_INFO_STATE BIT(0) +#define SVM_VMGEXIT_SEV_TIO_GR_INFO_CERTS BIT(1) +#define SVM_VMGEXIT_SEV_TIO_GR_INFO_MEAS BIT(2) +#define SVM_VMGEXIT_SEV_TIO_GR_INFO_REPORT BIT(3) + +#define SVM_VMGEXIT_SEV_TIO_GR_SDTE_VALIDATE BIT(0) +#define SVM_VMGEXIT_SEV_TIO_GR_SDTE_VTOM GENMASK_ULL(51, 21) + +/* + * TIO_GUEST_REQUEST's MMIO_VALIDATE_REQ/MMIO_CONFIG_REQ encoding for MMIO in RDX: + * + * T....... ....GGGG GGGGGGGG GGGGGGGG GGGGGGGG GGGGGGGG GGGG.... ........ + * Where: + * G - guest physical address + * T - TEE + */ +#define SVM_VMGEXIT_SEV_TIO_GR_MMIO_GFN(r) (((r) & 0x000FFFFFFFFFF000ULL) >> PAGE_SHIFT) +#define SVM_VMGEXIT_SEV_TIO_GR_MMIO_RESERVED(r) ((r) & 0x7FF0000000000FFFULL) +#define SVM_VMGEXIT_SEV_TIO_GR_MMIO_PRIVATE(r) (!!((r) & BIT(63))) + +#define SVM_VMGEXIT_SEV_TIO_GR_MMIO_NUM(r) ((uint32_t)((r) >> 32)) +#define SVM_VMGEXIT_SEV_TIO_GR_MMIO_ADDR(r) ((uint32_t)((r) & 0xFFFFFFFF)) + +#define SVM_VMGEXIT_SEV_TIO_GR_MMIO_MK_VALIDATE(start, private) \ + ((SVM_VMGEXIT_SEV_TIO_GR_MMIO_GFN(start) << PAGE_SHIFT) | \ + ((private) ? BIT(63) : 0)) + +#define SVM_VMGEXIT_SEV_TIO_OP 0x80000021ull +#define SVM_VMGEXIT_SEV_TIO_GR_MMIO_MK_NUM_BDFN(n, bdfn) (((uint64_t)(n) << 32) | (bdfn)) + +#define SVM_VMGEXIT_SEV_TIO_OP_PARAM(guest_id, action) ((u64)(action)<<32|(guest_id)) +#define SVM_VMGEXIT_SEV_TIO_OP_ACTION(exitinfo1) ((exitinfo1)>>32) +#define SVM_VMGEXIT_SEV_TIO_OP_GUEST_ID(exitinfo1) ((exitinfo1) & 0xFFFFFFFF) +#define SVM_VMGEXIT_SEV_TIO_OP_BIND 0 +#define SVM_VMGEXIT_SEV_TIO_OP_UNBIND 1 +#define SVM_VMGEXIT_SEV_TIO_OP_RUN 2 +#define SVM_VMGEXIT_SEV_TIO_OP_STOP 3 #define SVM_VMGEXIT_HV_FEATURES 0x8000fffdull #define SVM_VMGEXIT_TERM_REQUEST 0x8000fffeull #define SVM_VMGEXIT_TERM_REASON(reason_set, reason_code) \ @@ -245,6 +283,8 @@ { SVM_VMGEXIT_GUEST_REQUEST, "vmgexit_guest_request" }, \ { SVM_VMGEXIT_EXT_GUEST_REQUEST, "vmgexit_ext_guest_request" }, \ { SVM_VMGEXIT_AP_CREATION, "vmgexit_ap_creation" }, \ + { SVM_VMGEXIT_SEV_TIO_GR, "vmgexit_sev_tio_guest_request" }, \ + { SVM_VMGEXIT_SEV_TIO_OP, "vmgexit_sev_tio_op" }, \ { SVM_VMGEXIT_HV_FEATURES, "vmgexit_hypervisor_feature" }, \ { SVM_EXIT_ERR, "invalid_guest_state" } diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index 5b912f42f493..ed0e4546d5e5 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -104,6 +104,37 @@ static unsigned long snp_tsc_freq_khz __ro_after_init; DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data); DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); +int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) +{ + struct ghcb_state state; + struct es_em_ctxt ctxt; + struct ghcb *ghcb; + int ret; + + /* __sev_get_ghcb() needs IRQs disabled because it uses per-CPU GHCB. */ + guard(irqsave)(); + + ghcb = __sev_get_ghcb(&state); + if (!ghcb) + return -EIO; + + vc_ghcb_invalidate(ghcb); + ret = sev_es_ghcb_hv_call(ghcb, &ctxt, SVM_VMGEXIT_SEV_TIO_OP, + SVM_VMGEXIT_SEV_TIO_OP_PARAM(guest_rid, op), 0); + + *fw_err = ghcb->save.sw_exit_info_2; + if (*fw_err) + ret = -EIO; + + if (!ret && op == SVM_VMGEXIT_SEV_TIO_OP_BIND && tdi_id) + *tdi_id = ghcb_get_rcx(ghcb); + + __sev_put_ghcb(&state); + + return ret; +} +EXPORT_SYMBOL_GPL(sev_tio_op); + /* * SVSM related information: * When running under an SVSM, the VMPL that Linux is executing at must be @@ -1345,6 +1376,11 @@ static int snp_issue_guest_request(struct snp_guest_req *req) if (req->exit_code == SVM_VMGEXIT_EXT_GUEST_REQUEST) { ghcb_set_rax(ghcb, input->data_gpa); ghcb_set_rbx(ghcb, input->data_npages); + } else if (req->exit_code == SVM_VMGEXIT_SEV_TIO_GR) { + ghcb_set_rax(ghcb, input->data_gpa); + ghcb_set_rbx(ghcb, input->data_npages); + ghcb_set_rcx(ghcb, ((uint64_t)input->npages << 32) | input->guest_rid); + ghcb_set_rdx(ghcb, input->param); } ret = sev_es_ghcb_hv_call(ghcb, &ctxt, req->exit_code, input->req_gpa, input->resp_gpa); @@ -1354,6 +1390,8 @@ static int snp_issue_guest_request(struct snp_guest_req *req) req->exitinfo2 = ghcb->save.sw_exit_info_2; switch (req->exitinfo2) { case 0: + if (req->exit_code == SVM_VMGEXIT_SEV_TIO_GR) + input->param = ghcb_get_rdx(ghcb); break; case SNP_GUEST_VMM_ERR(SNP_GUEST_VMM_ERR_BUSY): @@ -1366,6 +1404,10 @@ static int snp_issue_guest_request(struct snp_guest_req *req) input->data_npages = ghcb_get_rbx(ghcb); ret = -ENOSPC; break; + } else if (req->exit_code == SVM_VMGEXIT_SEV_TIO_GR) { + input->data_npages = ghcb_get_rbx(ghcb); + ret = -ENOSPC; + break; } fallthrough; default: -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:02:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:02:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423000.1648307 (Exim 4.92) (envelope-from ) id 1x6oLK-0007BI-Uj; Wed, 16 Sep 2026 12:02:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423000.1648307; Wed, 16 Sep 2026 12:02:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oLK-0007B9-Rz; Wed, 16 Sep 2026 12:02:26 +0000 Received: by outflank-mailman (input) for mailman id 1423000; Wed, 16 Sep 2026 12:02:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oLJ-0007Ak-Nc for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:02:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oLJ-00GbTK-3w for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:02:25 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8545-bab6-0a2a0a5309dd-0a2a450c8698-38 for ; Wed, 16 Sep 2026 14:02:24 +0200 Received: from [52.101.57.31] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa854e-f479-0a2a450c0019-3465391fd612-3 for ; Wed, 16 Sep 2026 14:02:23 +0200 Received: from BY1P220CA0001.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:59d::14) by DS4PR12MB248322.namprd12.prod.outlook.com (2603:10b6:8:509::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 12:02:12 +0000 Received: from SJ5PEPF00000207.namprd05.prod.outlook.com (2603:10b6:a03:59d:cafe::97) by BY1P220CA0001.outlook.office365.com (2603:10b6:a03:59d::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 12:02:11 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF00000207.mail.protection.outlook.com (10.167.244.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 12:02:11 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 07:01:48 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=t8eW2LZEeLsU5jzpxmRNjLBvYNB9HJjnxAyywrycjmnbuC24mWlxMxocCel1hugJN4AUupJWDJgVSyJzWzoCX4/pU46IjkjUVNdxrno6uyb+z2qR2NNRxZ8qH8L0PtABQKeEBkn+SjuMB6Wm/EcYEni8RNHATQFQFhy/sni/UuHYvPIYoKZOfWxIG9ZXZ3q635KKVUl5OOoRTEHjClYtc6A/npwLR6oVNEMqT3fsQX5W2kvscbwhD4xAClMprr79hbM7OgScH0obY8Fx/pNwgpz83JpfbPAopW5v52T1V/DC/ACX8ot3jvUne5UADw8yYWZ17d/VPKGQ9mpB7vjSbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fWoH/Llw6YUXkVi9P/+pg2Cd/4z3RJ6aV+gYVYAAcRU=; b=hMkmTKVXm9niBUWx2oPRBhZNg8twP2kwB5XiO8t05lU0EP6ZXq0ajDmpl8R3ao1gX+VZ4pPdyOOIL2UKs5vlBJeiqZFVVPZ3XqGZawdPXGcVMCXd+ByEAGMYdW1TFYFvy87oKy1DIuvSDKsg7Rxsw/yRfOKlWgipq5e1AyMGY3XAUJ+PFshOIebUYvktTHQf4zTaStqHQMPQIvqx7GNN0cFEyenyUnM0Eu5OdoyylWRBnDhq4VhtbCHlvpUchvRbg2Hwdk34eB/nOPYKSw5AQp+k8thR9Rm3BEFrzG5eUcuYnPDMmXkS8HG7Ywa5AJVqW1SE/QZkkaTm1Ljvl16TFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fWoH/Llw6YUXkVi9P/+pg2Cd/4z3RJ6aV+gYVYAAcRU=; b=lz4uBZzkq+4GluEyz4oPAFXtUpVJwIPB1Z4Pi69SWOSJJcxY2nmirLEPj3jSXn39gQop7QHlYljA0TwzjJlf0suqyINmyDle7sh/5g91a+FSbsAmoWmQwwBnR6fPI0hjd2FnRMAZrbSa4IcPQbpp7ZPiHRBsKnqKm7bM1bBcdjs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 15/17] x86/sev: Implement guest TSM driver for SEV-TIO (phase2, DMA) Date: Wed, 16 Sep 2026 21:51:55 +1000 Message-ID: <20260916115159.1938195-16-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000207:EE_|DS4PR12MB248322:EE_ X-MS-Office365-Filtering-Correlation-Id: 04cd4172-76ca-459e-f814-08df13ea574c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|1800799024|32650700020|82310400026|23010399003|7416014|10067099003|18002099003|22082099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: fUqLwP2yBeGwzHtiDcoNUQWtntKDgz8U8C25nqzqoH2MPw/rY1tOggSZ+v9VCWmr7NYblHy8WR/0Ct3cmbUgXyRiLYJOR0ufnlIDIe5ba9PIQT78mB8Hcif0UmdhR2Ge1kN4GcXGWlNWrQM+faCwl4gz+3WpdBHg6/yh3Ns59rM+SWtsH5M2cABjl4G87VuSRLYXQjyDFbT+BNehAs2POk6DDZNQkaz6QLBxnG2aNM+GSrlA31RMXxpLA4jD10Pa+9vPGPQOuPmU9ZtSb3gUlw8JuMQPUnVoIRdw2JS6yMnsUk7bBLGBCSFnX8z4Q1OLu6QLfdXLLaJ5k/7KFuiE2Qz0ear1aYyXia/PRJcGW8eSeAmiOzjw6IYGDHWELAi+I/07k1IdD2Ij72KerVCygCjsm/BjYhctwVC5phAeS0RKEuQWKor3Dkw5RAQ7taxgT/h6VvtZIOcx5aNT2AaCcAU7wS+gDt6PMP8p53Ai2OgUoeRSDZWwvf03VpSCTs+4JRd9KkUPKI3vc1C3iJ1ye2toJGCPNPcPz8fYWzz7lxWQP7XTB6OCJHZmLmQ+s0WajS7fIYUhjZyk/YGTgrYV5JxfZ2VDSjYC7R0tqjN63JghHVrecj/GqDCPWZXuaSUnQrq0AU/KPCLwsHEIEBC7fdCo0vvDzSD1pBe18cUaw5GQ6X+q4U/wfYPOPkscStdBLCjaX38cgupFrhidHOzoWw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(1800799024)(32650700020)(82310400026)(23010399003)(7416014)(10067099003)(18002099003)(22082099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: gwUS5QlepI1jB9RFz2eYhcIGjvljtIY8qky9Q+KRNfs9t0uqazvIMGtOYEiFlwPgXSP299Vg+7GXppDplxnrxl8KhzpfVTLl7nL/G8fzrL0YLtAU3zgDc2tq4LZyBUjN25O+7XhpKZFJyuBjunYQIZlUpKbteps681NIyuNeXgsHTIu9yVQw85BUurli3THx77HFez2QWV0+4dmsiUwpbp6zVqOTghTQN9f6tOvRVv82jbPF8+2gddvsKXUs2gOEifWhO0aTAJPnk1nNXPRO7YFgcLmfvp/PwzcSkUVYrw5GNbQnS6f32B5Uud9ZAFwtWYNuBc+hKuO6gIZrsf5gDxbU9w7VgqmQzZRZEHl899j09k1/qtZNa3M5qYG/6TAP6YcmFjZL85P1lu5Su6ofeediQUNa9ytdmQA3BHdB4h6EkWZluYv1Wh0vMZRrun0J X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 12:02:11.6575 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 04cd4172-76ca-459e-f814-08df13ea574c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF00000207.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB248322 X-purgate-ID: tlsNG-d25034/1789560144-020C1A5B-59351F9C/0/0 X-purgate-type: clean X-purgate-size: 14155 Add the guest-side PCI TSM backend for AMD SEV-TIO, wiring the generic pci_tsm framework to GHCB TIO operations and PSP guest requests. Register pci_tsm_ops from sev-guest on probe when TIO GHCB support is present (gated by the tsm_enable module parameter). lock() binds a TDI, constructs a devsec TSM object and transitions to CONFIG_LOCKED; accept() transitions the TDI to RUN and programs the SDTE with vTOM and guest access permissions; unlock() invalidates the SDTE, unbinds the TDI, quiesces DMA and transitions to CONFIG_UNLOCKED. Introduce tio.c with TIO guest-request handling (TIO_MSG_SDTE_WRITE_REQ and related message layouts) and set cc_shared_dma_offset from the configurable tsm_vtom so shared DMA addresses are translated for the hypervisor. Extend asm/sev.h with TIO message types and TDISP SPDM algorithm constants. Build tio.o when PCI_TSM is enabled and select PCI_TSM from SEV_GUEST Kconfig. Signed-off-by: Alexey Kardashevskiy --- drivers/virt/coco/sev-guest/Kconfig | 1 + drivers/virt/coco/sev-guest/Makefile | 3 + arch/x86/include/asm/sev.h | 8 + drivers/virt/coco/sev-guest/sev-guest.h | 4 + drivers/virt/coco/sev-guest/core.c | 14 + drivers/virt/coco/sev-guest/tio.c | 347 ++++++++++++++++++++ 6 files changed, 377 insertions(+) diff --git a/drivers/virt/coco/sev-guest/Kconfig b/drivers/virt/coco/sev-guest/Kconfig index a6405ab6c2c3..4255072dfa1a 100644 --- a/drivers/virt/coco/sev-guest/Kconfig +++ b/drivers/virt/coco/sev-guest/Kconfig @@ -3,6 +3,7 @@ config SEV_GUEST default m depends on AMD_MEM_ENCRYPT select TSM_REPORTS + select PCI_TSM if PCI help SEV-SNP firmware provides the guest a mechanism to communicate with the PSP without risk from a malicious hypervisor who wishes to read, diff --git a/drivers/virt/coco/sev-guest/Makefile b/drivers/virt/coco/sev-guest/Makefile index a8eb28b6736e..84a8b0dd62cd 100644 --- a/drivers/virt/coco/sev-guest/Makefile +++ b/drivers/virt/coco/sev-guest/Makefile @@ -1,2 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_SEV_GUEST) += core.o +ifeq ($(CONFIG_PCI_TSM),y) +obj-$(CONFIG_SEV_GUEST) += tio.o +endif diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h index 89aaccb053ba..375cb5346ec3 100644 --- a/arch/x86/include/asm/sev.h +++ b/arch/x86/include/asm/sev.h @@ -182,6 +182,14 @@ enum msg_type { SNP_MSG_TSC_INFO_REQ = 17, SNP_MSG_TSC_INFO_RSP, + TIO_MSG_TDI_INFO_REQ = 19, + TIO_MSG_TDI_INFO_RSP = 20, + TIO_MSG_MMIO_VALIDATE_REQ = 21, + TIO_MSG_MMIO_VALIDATE_RSP = 22, + TIO_MSG_MMIO_CONFIG_REQ = 23, + TIO_MSG_MMIO_CONFIG_RSP = 24, + TIO_MSG_SDTE_WRITE_REQ = 25, + TIO_MSG_SDTE_WRITE_RSP = 26, SNP_MSG_TYPE_MAX }; diff --git a/drivers/virt/coco/sev-guest/sev-guest.h b/drivers/virt/coco/sev-guest/sev-guest.h index b2a97778e635..c823a782739f 100644 --- a/drivers/virt/coco/sev-guest/sev-guest.h +++ b/drivers/virt/coco/sev-guest/sev-guest.h @@ -11,6 +11,10 @@ struct snp_guest_dev { struct miscdevice misc; struct snp_msg_desc *msg_desc; + + struct tsm_dev *tsmdev; }; +void sev_guest_tsm_set_ops(bool set, struct snp_guest_dev *snp_dev); + #endif /* __SEV_GUEST_H__ */ diff --git a/drivers/virt/coco/sev-guest/core.c b/drivers/virt/coco/sev-guest/core.c index 98f698809720..8448c123ab1e 100644 --- a/drivers/virt/coco/sev-guest/core.c +++ b/drivers/virt/coco/sev-guest/core.c @@ -45,6 +45,10 @@ static int vmpck_id = -1; module_param(vmpck_id, int, 0444); MODULE_PARM_DESC(vmpck_id, "The VMPCK ID to use when communicating with the PSP."); +static bool tsm_enable = true; +module_param(tsm_enable, bool, 0644); +MODULE_PARM_DESC(tsm_enable, "Enable SEV TIO"); + static inline struct snp_guest_dev *to_snp_dev(struct file *file) { struct miscdevice *dev = file->private_data; @@ -668,6 +672,14 @@ static int __init sev_guest_probe(struct platform_device *pdev) snp_dev->msg_desc = mdesc; dev_info(dev, "Initialized SEV guest driver (using VMPCK%d communication key)\n", mdesc->vmpck_id); + + u64 *sev_hv_features_ptr = dev_get_platdata(&pdev->dev); + if (!sev_hv_features_ptr || !(*sev_hv_features_ptr & GHCB_HV_FT_SNP_SEV_TIO)) + tsm_enable = false; + + if (tsm_enable) + sev_guest_tsm_set_ops(true, snp_dev); + return 0; e_msg_init: @@ -681,6 +693,8 @@ static void __exit sev_guest_remove(struct platform_device *pdev) struct snp_guest_dev *snp_dev = platform_get_drvdata(pdev); snp_msg_free(snp_dev->msg_desc); + if (tsm_enable) + sev_guest_tsm_set_ops(false, snp_dev); misc_deregister(&snp_dev->misc); } diff --git a/drivers/virt/coco/sev-guest/tio.c b/drivers/virt/coco/sev-guest/tio.c new file mode 100644 index 000000000000..99ff2b9c872a --- /dev/null +++ b/drivers/virt/coco/sev-guest/tio.c @@ -0,0 +1,347 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "sev-guest.h" + +ulong tsm_vtom = (2ULL << 40); +module_param(tsm_vtom, ulong, 0644); +MODULE_PARM_DESC(tsm_vtom, "SEV TIO vTOM value"); + +#define tsm_dev_to_snp_dev(t) ((struct snp_guest_dev *)dev_get_drvdata((t)->dev.parent)) +#define pdev_to_tdi(p) container_of((p)->tsm, struct tio_guest_tdi, ds.base_tsm) +#define ghcb_tio_sbdfn(pdev) ((pci_domain_nr((pdev)->bus) << 16) | pci_dev_id(pdev)) + +struct tio_guest_tdi { + struct pci_tsm_devsec ds; + struct snp_guest_dev *snp_dev; + u64 tdi_id; /* Runtime FW generated TDI id */ +}; + +static int handle_tio_guest_request(struct snp_guest_dev *snp_dev, u8 type, + void *req_buf, size_t req_sz, void *resp_buf, u32 resp_sz, + u64 *bdfn, u64 *param, u64 *fw_err) +{ + struct snp_msg_desc *mdesc = snp_dev->msg_desc; + struct snp_guest_req req = { + .msg_version = 2, + .msg_type = type, + .vmpck_id = mdesc->vmpck_id, + .req_buf = kmemdup(req_buf, req_sz, GFP_KERNEL), + .req_sz = req_sz, + .resp_buf = kmalloc(resp_sz, GFP_KERNEL), + .resp_sz = resp_sz, + .exit_code = SVM_VMGEXIT_SEV_TIO_GR, + .input.guest_rid = 0, + .input.param = 0, + }; + int ret; + + if (!req.req_buf || !req.resp_buf) { + ret = -ENOMEM; + goto error_exit; + } + + if (bdfn) { + req.input.guest_rid = *bdfn & 0xFFFFFFFF; + req.input.npages = *bdfn >> 32; + } + req.input.param = *param; + + ret = snp_send_guest_request(mdesc, &req); + + memcpy(resp_buf, req.resp_buf, resp_sz); + *param = req.input.param; + *fw_err = req.exitinfo2; + +error_exit: + kfree(req.resp_buf); + kfree(req.req_buf); + + return ret; +} + +struct tio_msg_tdi_info_req { + u64 tdi_id; + u8 reserved[8]; +} __packed; + +enum { + TIO_MSG_TDI_INFO_RSP_STATUS_BOUND = 0, + TIO_MSG_TDI_INFO_RSP_STATUS_INVALID = 1, + TIO_MSG_TDI_INFO_RSP_STATUS_UNBOUND = 2, +}; + +struct tio_msg_tdi_info_rsp { + u64 tdi_id; + u16 status; /* TIO_MSG_TDI_INFO_RSP_STATUS_xxx */ + u8 reserved1[6]; + + u32 meas_digest_valid:1; + u32 meas_digest_fresh:1; + u32 reserved2:30; + + /* These are TDISP's LOCK_INTERFACE_REQUEST flags */ + u32 no_fw_update:1; + u32 cache_line_size:1; + u32 lock_msix:1; + u32 bind_p2p:1; + u32 all_request_redirect:1; + u32 reserved3:27; + + u64 spdm_algos; + u8 certs_digest[48]; + u8 meas_digest[48]; + u8 interface_report_digest[48]; + u64 tdi_report_count; + u64 reserved4; +} __packed; + +struct sdte { + u64 v : 1; + u64 reserved : 3; + u64 cxlio : 3; + u64 reserved1 : 45; + u64 ppr : 1; + u64 reserved2 : 1; + u64 giov : 1; + u64 gv : 1; + u64 glx : 2; + u64 gcr3_tbl_rp0 : 3; + u64 ir : 1; + u64 iw : 1; + u64 reserved3 : 1; + u16 domain_id; + u16 gcr3_tbl_rp1; + u32 interrupt : 1; + u32 reserved4 : 5; + u32 ex : 1; + u32 sd : 1; + u32 reserved5 : 2; + u32 sats : 1; + u32 gcr3_tbl_rp2 : 21; + u64 giv : 1; + u64 gint_tbl_len : 4; + u64 reserved6 : 1; + u64 gint_tbl : 46; + u64 reserved7 : 2; + u64 gpm : 2; + u64 reserved8 : 3; + u64 hpt_mode : 1; + u64 reserved9 : 4; + u32 asid : 12; + u32 reserved10 : 3; + u32 viommu_en : 1; + u32 guest_device_id : 16; + u32 guest_id : 15; + u32 guest_id_mbo : 1; + u32 reserved11 : 1; + u32 vmpl : 2; + u32 reserved12 : 3; + u32 attrv : 1; + u32 reserved13 : 1; + u32 sa : 8; + u8 ide_stream_id[8]; + u32 vtom_en : 1; + u32 vtom : 31; + u32 rp_id : 5; + u32 reserved14 : 27; + u8 reserved15[0x40-0x30]; +} __packed; + +struct tio_msg_sdte_write_req { + u64 tdi_id; + u8 reserved[8]; + struct sdte sdte; +} __packed; + +/* + * Status codes from TIO_MSG_SDTE_WRITE_REQ + */ +enum sdte_write_status { + SDTE_WRITE_SUCCESS = 0, + SDTE_WRITE_INVALID_TDI = 1, + SDTE_WRITE_TDI_NOT_BOUND = 2, + SDTE_WRITE_RESERVED = 3, +}; + +struct tio_msg_sdte_write_rsp { + u64 tdi_id; + u16 status; /* SDTE_WRITE_xxx */ + u8 reserved[6]; +} __packed; + +static int tio_tdi_sdte_write(struct pci_dev *pdev, struct snp_guest_dev *snp_dev, + uint64_t tdi_id, u64 vtom, bool invalidate) +{ + size_t resp_len = sizeof(struct tio_msg_sdte_write_rsp) + AUTHTAG_LEN; + struct tio_msg_sdte_write_rsp *rsp __free(kfree_sensitive) = kzalloc(resp_len, GFP_KERNEL); + struct tio_msg_sdte_write_req req; + u64 flags = vtom | (invalidate ? 0 : SVM_VMGEXIT_SEV_TIO_GR_SDTE_VALIDATE); + u64 bdfn = ghcb_tio_sbdfn(pdev); + u64 fw_err = 0; + int rc; + + BUILD_BUG_ON(sizeof(struct sdte) * 8 != 512); + + pci_notice(pdev, "SDTE write vTOM=%llx", flags); + + if (!invalidate) + req = (struct tio_msg_sdte_write_req) { + .tdi_id = tdi_id, + .sdte.vmpl = 0, + .sdte.vtom = vtom >> 21, + .sdte.vtom_en = 1, + .sdte.iw = 1, + .sdte.ir = 1, + .sdte.v = 1, + }; + else + req = (struct tio_msg_sdte_write_req) { + .tdi_id = tdi_id, + }; + + if (!rsp) + return -ENOMEM; + + rc = handle_tio_guest_request(snp_dev, TIO_MSG_SDTE_WRITE_REQ, + &req, sizeof(req), rsp, resp_len, + &bdfn, &flags, &fw_err); + if (rc || fw_err || rsp->status != SDTE_WRITE_SUCCESS) { + pci_err(pdev, "SDTE write failed with rc=%d, fwerr=0x%llx, status=%x\n", + rc, fw_err, rsp->status); + if (!rc) + return -EFAULT; + return rc; + } + + pdev->dev.archdata.cc_shared_dma_offset = invalidate ? 0 : vtom; + + return 0; +} + +static struct pci_tsm *sev_guest_lock(struct tsm_dev *tsmdev, struct pci_dev *pdev) +{ + struct tio_guest_tdi *gtdi __free(kfree) = kzalloc(sizeof(*gtdi), GFP_KERNEL); + u64 fw_err = 0, tdi_id = 0; + int rc; + + if (!gtdi) + return ERR_PTR(-ENOMEM); + + /* Enabling device tells the HV to register MMIO as memory slots */ + rc = pci_enable_device_mem(pdev); + if (rc) + return ERR_PTR(rc); + + rc = pci_tsm_devsec_constructor(pdev, >di->ds, tsmdev); + if (rc) + return ERR_PTR(rc); + + gtdi->snp_dev = tsm_dev_to_snp_dev(tsmdev); + + rc = sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_BIND, &fw_err, &tdi_id); + if (rc) { + pci_err(pdev, "TDI bind CONFIG_LOCKED failed rc=%d fw=0x%llx\n", + rc, fw_err); + return ERR_PTR(rc); + } + pci_dbg(pdev, "New TDI ID=%llx\n", tdi_id); + + struct device_evidence *evidence = device_evidence_create(0, HASH_ALGO_SHA384); + if (!evidence) + return ERR_PTR(-ENOMEM); + gtdi->ds.base_tsm.evidence = evidence; + + gtdi->tdi_id = tdi_id; + + return &no_free_ptr(gtdi)->ds.base_tsm; +} + +static void sev_guest_unlock(struct pci_tsm *tsm) +{ + struct pci_dev *pdev = tsm->pdev; + u64 fw_err = 0; + + sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_UNBIND, &fw_err, NULL); + + /* Quiesce DMA */ + sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_STOP, &fw_err, NULL); + + tsm->pdev->tsm = NULL; + kvfree(tsm); +} + +static int sev_guest_accept(struct pci_dev *pdev) +{ + struct pci_tsm *tsm = pdev->tsm; + u64 fw_err = 0; + + if (!tsm->evidence->obj[DEVICE_EVIDENCE_TYPE_REPORT].data) { + pci_warn_once(pdev, "Cannot accept without the report"); + return -ENODEV; + } + + int ret = tio_tdi_sdte_write(pdev, snp_dev, gtdi->tdi_id, 0, false); // Mark everything "shared" + if (ret) + return ret; + + return sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_RUN, &fw_err, NULL); +} + +static int sev_guest_enable_dma(struct pci_dev *pdev) +{ + struct tio_guest_tdi *gtdi = pdev_to_tdi(pdev); + struct snp_guest_dev *snp_dev = gtdi->snp_dev; + int ret; + + ret = tio_tdi_sdte_write(pdev, snp_dev, gtdi->tdi_id, tsm_vtom, false); + + return ret; +} + +static void sev_guest_disable_dma(struct pci_dev *pdev) +{ + struct tio_guest_tdi *gtdi = pdev_to_tdi(pdev); + struct snp_guest_dev *snp_dev = gtdi->snp_dev; + int rc; + + rc = tio_tdi_sdte_write(pdev, snp_dev, gtdi->tdi_id, tsm_vtom, true); + if (rc) + pr_err("SDTE_WRITE failed, ret=%d\n", rc); +} + +struct pci_tsm_ops sev_guest_tsm_ops = { + .lock = sev_guest_lock, + .unlock = sev_guest_unlock, + .run = sev_guest_accept, + .enable_dma = sev_guest_enable_dma, + .disable_dma = sev_guest_disable_dma, +}; + +void sev_guest_tsm_set_ops(bool set, struct snp_guest_dev *snp_dev) +{ + if (set) { + struct tsm_dev *tsmdev; + + tsmdev = tsm_register(snp_dev->dev, &sev_guest_tsm_ops); + if (!IS_ERR_OR_NULL(tsmdev)) + snp_dev->tsmdev = tsmdev; + return; + } + + if (snp_dev->tsmdev) { + tsm_unregister(snp_dev->tsmdev); + snp_dev->tsmdev = NULL; + } +} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:03:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:03:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423012.1648316 (Exim 4.92) (envelope-from ) id 1x6oLy-0007nW-5v; Wed, 16 Sep 2026 12:03:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423012.1648316; Wed, 16 Sep 2026 12:03:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oLy-0007nP-2l; Wed, 16 Sep 2026 12:03:06 +0000 Received: by outflank-mailman (input) for mailman id 1423012; Wed, 16 Sep 2026 12:03:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oLw-0007m7-Kv for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:03:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oLv-005eex-UV for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:03:03 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8566-e002-0a2a0a5209dd-0a2a4507dab6-48 for ; Wed, 16 Sep 2026 14:03:03 +0200 Received: from [40.107.201.37] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8575-b4ea-0a2a45070019-286bc92563b6-3 for ; Wed, 16 Sep 2026 14:03:03 +0200 Received: from SJ0PR05CA0149.namprd05.prod.outlook.com (2603:10b6:a03:33d::34) by DS5PPF5A66AFD1C.namprd12.prod.outlook.com (2603:10b6:f:fc00::64d) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 12:02:49 +0000 Received: from SJ5PEPF00000209.namprd05.prod.outlook.com (2603:10b6:a03:33d:cafe::6d) by SJ0PR05CA0149.outlook.office365.com (2603:10b6:a03:33d::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.8 via Frontend Transport; Wed, 16 Sep 2026 12:02:48 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF00000209.mail.protection.outlook.com (10.167.244.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 12:02:48 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 07:02:24 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wz0IlNnPvJv+NQAGKSxKEz9M9Zu3liuLwku0ioqfSTQ6l+zxOZoVJ0Co91tG+SSf5sNCiNLxQktZ4JtQaJKg7yawDJfN9Q7k0396HYkuGICsRWGbwYttSz7q5z/GcFw1s2SqTgMoCXyEC3GTTTiSA5f6W//nmzXn0XhMer9rCSgPY1d718e/fCkjyvAorsXdGLmF4+MC6hn7jzzfXCPRd7YakXH/gmxT/YwwLrYZW81/FvM62ZthtuizjcoqeY5fGn9CJndIankLG4xBii7ykgiFg+B7hjaIUuDVli6ZzNctIxXwVKs7cPIOwX8/La6ozlyFR3CbROBdwjcTbpkLJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hhr24ObJOq7bbaHkOTfqjQthzL33Uot6iWXZUXcZvPs=; b=C3riSyFLxEVKfOLplH1eesMG6rtOSW/nYQi/teGYPwUwjp2FTN6PPIAPa5kQnNFfNnhHNzDUyFXfXjg5Di3qrtT2BEDt0TOpWfqaSFvIjGZgtWKWWv7PFuFcw+cB6PRhtY63vsoKSy+pnz3rwX+Fd9eRBU1CmV933ZKNnoq2Gqrl86HY10c9k72I7QqFdaGu9dYGx60JfeI4OyOKqmreXgpQnVPoSceJdaeOQc9Wx4I3orBJaST5k9KniRmBQRgMBnZG5FDWwevTFsgx1naDh+SOKbhm7oGA+8OlbrErb3s04XT7gape9znrm/9SLM2MF2HUu69+pPaZ81xwc952Lw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hhr24ObJOq7bbaHkOTfqjQthzL33Uot6iWXZUXcZvPs=; b=dEagLY+Q3BlZMFubhFKDxlq/VNvHhtoadVYQRpEkP8iywVjbqSaNYxEKsk2CCsd+MrIc+y2wuFiPJJp5DmsVQ/aBXX0/gtkpRi+NCfLn5sGDLixNm5X64cghILOT8DAoUpxwQi3Q1MOkdKZ2KgRt9yUkPQp77HoPLvYG9eAWgf8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 16/17] x86/sev: Enable secure MMIO (phase2) Date: Wed, 16 Sep 2026 21:51:56 +1000 Message-ID: <20260916115159.1938195-17-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000209:EE_|DS5PPF5A66AFD1C:EE_ X-MS-Office365-Filtering-Correlation-Id: 192fdd71-d3ad-437f-84a5-08df13ea6d18 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700016|32650700020|23010399003|7416014|376014|10067099003|10063799003|22082099003|18002099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: rAYJ1ZEaPMY4ebXUUanmtjH5GEDkJnfh2oL7uP/UlnwngJ8+9U59pjrgkf4l5QSbrf8ozYU5eoQwHQTrO5/idOTclo6MIV0wNKOdmHaQZ3INkfDB/XAtTJ4OoqtNPEdJVgzbQMl7CWpSOWXIPrNmyNwJMxi5D4mSrZ0J3e17RhpZDokMYuXqz0mAdKKtqOJd81i+Nd+rcjnx9SKXoi/6JyrpU5X6EvICFAyCThuCOubkPovwahz6YmYcUrkTk663y+v8gXZV8ZcWu6ZJSWtilEg8mj8jjL8+ngQb0DhrBTKcTJeJCq42g8/CMZ7tY817KvogenvedaZ6al+bXS2RjD96VUaawgJhZtZWPSI3g2zh+YS4PbnxVGrHVt2lL/k8UVaVg1Z/fZxYWrpgceiAAa2rV2vBtjAUuJgA5irKPhCsdI5OwiLaYFjxq7/SSUwls1yHzAZnGM44o76zKT4v17sbL2hO+vIjQdAB+dIUqiPoCqSrNhfZzzIDeFT6tYZgfFBbtLA4WcIlG9+zfQN1D6a235f2BCUQBrtMK8/5aI0ICuhL0M9ugvbjzKf1MWvj/dNnqlwGPN5ufUEsx7bSYOj+SOGXTi9bUK1971DWPtqt0iHU/lyofxH40zJH7dJzDUW6842JtzdwvMmsSOZvngAMGq2jaz09qWMm4vJ2joSeGqY4IoDS7lmWYf2HbjTeEmjIDkqTQZuyWDIBP/ufkw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(32650700020)(23010399003)(7416014)(376014)(10067099003)(10063799003)(22082099003)(18002099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: DCCVrm9p8t6eZOOk4GJCUS43Z8KcgmvI3YzmmAcBE7ZahABBe4I8M2kGS3XT+z98XTu8RWiszsGk3RkVlxAeionzj0+s/hzFqaXr95aBLKliNb8Vy9gGHiv1ty1VW6NMqgGCcwMJbmRWBIUuaOZvGJFmugcuex7+5Se0MrloxwhfaqOgqOuY59lt4SiIc33tTxHRbxS/qKYztBXkCL41CR8p21ARH5RkDUxUEE04b+DGQFcWgLSrWLlV2449Buir2O7ku6XuIGkixZGFshjeWbMuO7z7oGdzhztZoJA9wLBwN3ho9S3/7CytKu7bbicVhiLxJYobMswAmpOBPDSUnOsIYVQ2KkbVc3P/MhbnkmLiXAwltHY6MIAvEvvR6Z6AIOEwTejP0cZtr46zUvlvdMl0g5s22S2HsMxTYOuWxHmn4M2fpWp4MFdvBX+eYvQO X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 12:02:48.2468 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 192fdd71-d3ad-437f-84a5-08df13ea6d18 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF00000209.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPF5A66AFD1C X-purgate-ID: tlsNG-ef75cf/1789560183-34ECEAE4-35DA5EE7/0/0 X-purgate-type: clean X-purgate-size: 17496 In order to enable secure MMIO, RMP needs to be updated. Unlike RAM (where PVALIDATE validate the RMP entry), MMIO RMP entries require assistance from the PSP. Add TDI_INFO TIO guest request command. Request the TDI interface report from the PSP. Use the report to validate MMIO ranges reported as non-NonTEE (i.e. encrypted). The TSM subsystem notifies the PCI subsystem to automatically map validated MMIO ranges as encrypted. Since for MMIO the TSM driver needs TDISP report, add shared memory buffers for receiving the device evidence. Use DMA SWIOTLB for these buffers, explicitly, by forcing 32bit DMA mask. Signed-off-by: Alexey Kardashevskiy --- include/uapi/linux/sev-guest.h | 12 + drivers/virt/coco/sev-guest/core.c | 3 +- drivers/virt/coco/sev-guest/tio.c | 394 +++++++++++++++++++- 3 files changed, 400 insertions(+), 9 deletions(-) diff --git a/include/uapi/linux/sev-guest.h b/include/uapi/linux/sev-guest.h index fcdfea767fca..28db79886ca5 100644 --- a/include/uapi/linux/sev-guest.h +++ b/include/uapi/linux/sev-guest.h @@ -13,6 +13,7 @@ #define __UAPI_LINUX_SEV_GUEST_H_ #include +#include #define SNP_REPORT_USER_DATA_SIZE 64 @@ -96,4 +97,15 @@ struct snp_ext_report_req { #define SNP_GUEST_VMM_ERR_INVALID_LEN 1 #define SNP_GUEST_VMM_ERR_BUSY 2 +/* Optional Certificates/measurements/report data from TIO_GUEST_REQUEST */ +struct tio_blob_table_entry { + guid_t guid; + __u32 offset; + __u32 length; +} __packed; + +/* Attestation report: 70dc5b0e-0cc0-4cd5-97bb-ff0ba25bf320 */ +#define TIO_GUID_REPORT \ + GUID_INIT(0x70dc5b0e, 0x0cc0, 0x4cd5, 0x97, 0xbb, 0xff, 0x0b, 0xa2, 0x5b, 0xf3, 0x20) + #endif /* __UAPI_LINUX_SEV_GUEST_H_ */ diff --git a/drivers/virt/coco/sev-guest/core.c b/drivers/virt/coco/sev-guest/core.c index 8448c123ab1e..8710c41daed6 100644 --- a/drivers/virt/coco/sev-guest/core.c +++ b/drivers/virt/coco/sev-guest/core.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include @@ -677,7 +678,7 @@ static int __init sev_guest_probe(struct platform_device *pdev) if (!sev_hv_features_ptr || !(*sev_hv_features_ptr & GHCB_HV_FT_SNP_SEV_TIO)) tsm_enable = false; - if (tsm_enable) + if (tsm_enable && !dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) sev_guest_tsm_set_ops(true, snp_dev); return 0; diff --git a/drivers/virt/coco/sev-guest/tio.c b/drivers/virt/coco/sev-guest/tio.c index 99ff2b9c872a..06addbb3a9ad 100644 --- a/drivers/virt/coco/sev-guest/tio.c +++ b/drivers/virt/coco/sev-guest/tio.c @@ -22,15 +22,71 @@ MODULE_PARM_DESC(tsm_vtom, "SEV TIO vTOM value"); #define pdev_to_tdi(p) container_of((p)->tsm, struct tio_guest_tdi, ds.base_tsm) #define ghcb_tio_sbdfn(pdev) ((pci_domain_nr((pdev)->bus) << 16) | pci_dev_id(pdev)) +#define TIO_DATA_PAGES (SZ_32K >> PAGE_SHIFT) +#define SPDM_MEASUREMENTS_NONCE_LEN 32 + +static void sev_free_shared_pages(struct device *dev, void *buf, + unsigned long npages, dma_addr_t dma_handle) +{ + dma_free_coherent(dev, npages << PAGE_SHIFT, buf, dma_handle); +} + +static void *sev_alloc_shared_pages(struct device *dev, unsigned long npages, + dma_addr_t *dma_handle) +{ + return dma_alloc_coherent(dev, npages << PAGE_SHIFT, dma_handle, GFP_KERNEL); +} + struct tio_guest_tdi { struct pci_tsm_devsec ds; struct snp_guest_dev *snp_dev; u64 tdi_id; /* Runtime FW generated TDI id */ }; +static void device_evidence_object_clear(struct device_evidence_object *obj) +{ + if (!obj) + return; + + kfree(obj->digest); + kfree(obj->data); + obj->data = NULL; + obj->len = 0; + obj->digest = NULL; +} + +static int device_evidence_object_assign(struct device_evidence_object *obj, + const void *src, size_t len) +{ + void *copy; + + device_evidence_object_clear(obj); + if (!len || !src) + return 0; + + copy = kmemdup(src, len, GFP_KERNEL); + if (!copy) + return -ENOMEM; + + obj->data = copy; + obj->len = len; + return 0; +} + +static void device_evidence_release(struct device_evidence *evidence) +{ + unsigned int i; + + if (!evidence) + return; + + for (i = 0; i <= DEVICE_EVIDENCE_TYPE_MAX; i++) + device_evidence_object_clear(&evidence->obj[i]); +} + static int handle_tio_guest_request(struct snp_guest_dev *snp_dev, u8 type, void *req_buf, size_t req_sz, void *resp_buf, u32 resp_sz, - u64 *bdfn, u64 *param, u64 *fw_err) + void *pt, u64 *npages, u64 *bdfn, u64 *param, u64 *fw_err) { struct snp_msg_desc *mdesc = snp_dev->msg_desc; struct snp_guest_req req = { @@ -52,6 +108,10 @@ static int handle_tio_guest_request(struct snp_guest_dev *snp_dev, u8 type, goto error_exit; } + if (pt && npages) { + req.certs_data = pt; + req.input.data_npages = *npages; + } if (bdfn) { req.input.guest_rid = *bdfn & 0xFFFFFFFF; req.input.npages = *bdfn >> 32; @@ -71,6 +131,69 @@ static int handle_tio_guest_request(struct snp_guest_dev *snp_dev, u8 type, return ret; } +static int guest_request_tio_data(struct snp_guest_dev *snp_dev, u8 type, + void *req_buf, size_t req_sz, void *resp_buf, u32 resp_sz, + u64 bdfn, struct device_evidence_object *report, + u64 *fw_err) +{ + u64 npages = TIO_DATA_PAGES, param = 0; + struct tio_blob_table_entry *pt; + dma_addr_t dh = 0; + int rc; + + pt = sev_alloc_shared_pages(snp_dev->dev, TIO_DATA_PAGES, &dh); + if (!pt) + return -ENOMEM; + + if (report) + param |= SVM_VMGEXIT_SEV_TIO_GR_INFO_REPORT; + + rc = handle_tio_guest_request(snp_dev, type, req_buf, req_sz, resp_buf, resp_sz, + pt, &npages, &bdfn, ¶m, fw_err); + if (npages > TIO_DATA_PAGES) { + sev_free_shared_pages(snp_dev->dev, pt, TIO_DATA_PAGES, dh); + pt = sev_alloc_shared_pages(snp_dev->dev, npages, &dh); + if (!pt) + return -ENOMEM; + + rc = handle_tio_guest_request(snp_dev, type, req_buf, req_sz, resp_buf, resp_sz, + pt, &npages, &bdfn, ¶m, fw_err); + } + if (rc) + goto out_free_pt; + + if (report) + device_evidence_object_clear(report); + + for (unsigned int i = 0; i < 3; ++i) { + u8 *ptr = ((u8 *)pt) + pt[i].offset; + size_t len = pt[i].length; + + if (guid_is_null(&pt[i].guid)) + break; + + if (!len) + continue; + + if (guid_equal(&pt[i].guid, &TIO_GUID_REPORT) && report) + rc = device_evidence_object_assign(report, ptr, len); + else + continue; + if (rc) + goto out_clear_blobs; + } + sev_free_shared_pages(snp_dev->dev, pt, npages, dh); + + return 0; + +out_clear_blobs: + if (report) + device_evidence_object_clear(report); +out_free_pt: + sev_free_shared_pages(snp_dev->dev, pt, npages, dh); + return rc; +} + struct tio_msg_tdi_info_req { u64 tdi_id; u8 reserved[8]; @@ -107,6 +230,224 @@ struct tio_msg_tdi_info_rsp { u64 reserved4; } __packed; +static int tio_tdi_status(struct pci_dev *pdev, struct snp_guest_dev *snp_dev, + struct tsm_tdi_status *ts, uint64_t tdi_id, + struct device_evidence_object *report) +{ + size_t resp_len = sizeof(struct tio_msg_tdi_info_rsp) + AUTHTAG_LEN; + struct tio_msg_tdi_info_rsp *rsp __free(kfree_sensitive) = kzalloc(resp_len, GFP_KERNEL); + struct tio_msg_tdi_info_req req = { + .tdi_id = tdi_id, + }; + u64 fw_err = 0; + int rc; + + pci_notice(pdev, "TDI info"); + if (!rsp) + return -ENOMEM; + + rc = guest_request_tio_data(snp_dev, TIO_MSG_TDI_INFO_REQ, &req, + sizeof(req), rsp, resp_len, + ghcb_tio_sbdfn(pdev), report, &fw_err); + if (rc) + return rc; + + ts->tdi_id = rsp->tdi_id; + + return 0; +} + +struct tio_msg_mmio_validate_req { + u64 tdi_id; + u8 reserved2[8]; + u64 subrange_base; + u32 subrange_page_count; + u32 range_offset; + + u16 validated:1; /* Desired value to set RMP.Validated for the range */ + /* + * Force validated: + * 0: If subrange does not have RMP.Validated set uniformly, fail. + * 1: If subrange does not have RMP.Validated set uniformly, force + * to requested value + */ + u16 force_validated:1; + u16 reserved3:14; + + u16 range_id; + u8 reserved4[12]; +} __packed; + +/* Status codes from TIO_MSG_MMIO_VALIDATE_REQ */ +enum mmio_validate_status { + MMIO_VALIDATE_SUCCESS = 0, + MMIO_VALIDATE_INVALID_TDI = 1, + MMIO_VALIDATE_TDI_UNBOUND = 2, + MMIO_VALIDATE_NOT_ASSIGNED = 3, /* At least one page is not assigned to the guest */ + MMIO_VALIDATE_NOT_IO = 4, /* At least one page is not an I/O page */ + MMIO_VALIDATE_NOT_UNIFORM = 5, /* Validated bit is not uniformly set for range */ + MMIO_VALIDATE_NOT_IMMUTABLE = 6,/* >=1 page does not have immutable bit set */ + MMIO_VALIDATE_NOT_MAPPED = 7, /* At least one page is not mapped to the expected GPA */ + MMIO_VALIDATE_NOT_REPORTED = 8, /* Range ID is not reported in TDI report */ + MMIO_VALIDATE_OUT_OF_RANGE = 9, /* Subrange is out the MMIO range in TDI report */ + MMIO_VALIDATE_NOT_4K = 10, /* >=1 page is not 4K page size */ +}; + +struct tio_msg_mmio_validate_rsp { + u64 tdi_id; + u16 status; /* MMIO_VALIDATE_xxx */ + u8 reserved1[6]; + u64 subrange_base; + u32 subrange_page_count; + u32 range_offset; + + u16 changed:1; /* Validated bit has changed due to this operation */ + u16 reserved2:15; + + u16 range_id; + u8 reserved3[12]; +} __packed; + +static int mmio_validate_range(struct snp_guest_dev *snp_dev, struct pci_dev *pdev, + uint64_t tdi_id, unsigned int range_id, + resource_size_t start, resource_size_t size, + bool invalidate, u64 *fw_err, u16 *status) +{ + size_t resp_len = sizeof(struct tio_msg_mmio_validate_rsp) + AUTHTAG_LEN; + struct tio_msg_mmio_validate_rsp *rsp __free(kfree_sensitive) = + kzalloc(resp_len, GFP_KERNEL); + struct tio_msg_mmio_validate_req req = { + .tdi_id = tdi_id, + .subrange_base = start >> 12, + .subrange_page_count = size >> 12, + .range_offset = 0, + .validated = !invalidate, /* Desired value to set RMP.Validated for the range */ + .force_validated = 0, + .range_id = range_id, + }; + u64 num_bdfn = SVM_VMGEXIT_SEV_TIO_GR_MMIO_MK_NUM_BDFN(size >> 12, ghcb_tio_sbdfn(pdev)); + u64 mmio_val = SVM_VMGEXIT_SEV_TIO_GR_MMIO_MK_VALIDATE(start, !invalidate); + int rc; + + if (!rsp) + return -ENOMEM; + + rc = handle_tio_guest_request(snp_dev, TIO_MSG_MMIO_VALIDATE_REQ, + &req, sizeof(req), rsp, resp_len, + NULL, NULL, &num_bdfn, &mmio_val, fw_err); + if (rc || *fw_err || rsp->status != MMIO_VALIDATE_SUCCESS) { + pci_err(pdev, "MMIO validate failed with rc=%d, fwerr=0x%llx, status=%x\n", + rc, *fw_err, rsp->status); + if (!rc) + return -EFAULT; + return rc; + } + + *status = rsp->status; + + return 0; +} + +static void tio_tdi_mmio_invalidate(struct pci_dev *pdev, struct snp_guest_dev *snp_dev, + uint64_t tdi_id) +{ + struct pci_tsm *tsm = pdev->tsm; + u16 mmio_status; + u64 fw_err = 0; + int i = 0, rc = 0; + struct pci_tsm_devsec *devsec_tsm = to_pci_tsm_devsec(tsm); + struct pci_tsm_mmio *mmio = devsec_tsm->mmio; + + if (!mmio) + return; + + pci_notice(pdev, "MMIO invalidate"); + + for (i = 0; i < mmio->nr; ++i) { + struct pci_tsm_mmio_entry *entry = pci_tsm_mmio_entry(mmio, i); + struct resource *res = &entry->res; + unsigned int range_id = entry->range_id; + + if (range_id >= PCI_NUM_RESOURCES || + !resource_contains(pci_resource_n(pdev, range_id), res)) { + pci_info(pdev, "Skipping MMIO [%d] %pr: no BAR %u window\n", + i, res, range_id); + continue; + } + + mmio_status = 0; + rc = mmio_validate_range(snp_dev, pdev, tdi_id, range_id, + res->start, resource_size(res), true, &fw_err, + &mmio_status); + if (rc || fw_err != SEV_RET_SUCCESS || mmio_status != MMIO_VALIDATE_SUCCESS) { + pci_err(pdev, "MMIO #%d %llx..%llx validation failed 0x%llx %d\n", + range_id, res->start, res->end, fw_err, mmio_status); + continue; + } + + pci_notice(pdev, "MMIO #%d %llx..%llx invalidated\n", + range_id, res->start, res->end); + } + + pci_tsm_mmio_teardown(devsec_tsm->mmio); + kfree(devsec_tsm->mmio); + devsec_tsm->mmio = NULL; +} + +static int tio_tdi_mmio_validate(struct pci_dev *pdev, struct snp_guest_dev *snp_dev, + uint64_t tdi_id) +{ + struct pci_tsm *tsm = pdev->tsm; + u16 mmio_status; + u64 fw_err = 0; + int i, rc = 0; + struct pci_tsm_mmio *mmio __free(kfree) = pci_tsm_mmio_alloc(pdev); + + if (!mmio) + return -ENOMEM; + + pci_notice(pdev, "MMIO validate"); + + for (i = 0; i < mmio->nr; ++i) { + struct pci_tsm_mmio_entry *entry = pci_tsm_mmio_entry(mmio, i); + struct resource *res = &entry->res; + unsigned int range_id = entry->range_id; + + if (range_id >= PCI_NUM_RESOURCES || + !resource_contains(pci_resource_n(pdev, range_id), res)) { + pci_info(pdev, + "Skipping MMIO [%d] %pr: no BAR %u window\n", + i, res, range_id); + continue; + } + + mmio_status = 0; + rc = mmio_validate_range(snp_dev, pdev, tdi_id, range_id, res->start, + resource_size(res), false, &fw_err, &mmio_status); + if (rc || fw_err != SEV_RET_SUCCESS || mmio_status != MMIO_VALIDATE_SUCCESS) { + pci_err(pdev, "MMIO #%d %llx..%llx validation failed 0x%llx %d\n", + range_id, res->start, res->end, fw_err, mmio_status); + continue; + } + + pci_notice(pdev, "MMIO #%d %llx..%llx validated\n", range_id, res->start, res->end); + } + + if (!rc) { + rc = pci_tsm_mmio_setup(pdev, mmio); + if (!rc) { + struct pci_tsm_devsec *devsec_tsm = to_pci_tsm_devsec(tsm); + + devsec_tsm->mmio = no_free_ptr(mmio); + } + } + + if (rc) + tio_tdi_mmio_invalidate(pdev, snp_dev, tdi_id); + + return rc; +} + struct sdte { u64 v : 1; u64 reserved : 3; @@ -216,7 +557,7 @@ static int tio_tdi_sdte_write(struct pci_dev *pdev, struct snp_guest_dev *snp_de rc = handle_tio_guest_request(snp_dev, TIO_MSG_SDTE_WRITE_REQ, &req, sizeof(req), rsp, resp_len, - &bdfn, &flags, &fw_err); + NULL, NULL, &bdfn, &flags, &fw_err); if (rc || fw_err || rsp->status != SDTE_WRITE_SUCCESS) { pci_err(pdev, "SDTE write failed with rc=%d, fwerr=0x%llx, status=%x\n", rc, fw_err, rsp->status); @@ -233,6 +574,7 @@ static int tio_tdi_sdte_write(struct pci_dev *pdev, struct snp_guest_dev *snp_de static struct pci_tsm *sev_guest_lock(struct tsm_dev *tsmdev, struct pci_dev *pdev) { struct tio_guest_tdi *gtdi __free(kfree) = kzalloc(sizeof(*gtdi), GFP_KERNEL); + struct tsm_tdi_status ts = {}; u64 fw_err = 0, tdi_id = 0; int rc; @@ -258,11 +600,21 @@ static struct pci_tsm *sev_guest_lock(struct tsm_dev *tsmdev, struct pci_dev *pd } pci_dbg(pdev, "New TDI ID=%llx\n", tdi_id); - struct device_evidence *evidence = device_evidence_create(0, HASH_ALGO_SHA384); - if (!evidence) + struct device_evidence *ev = device_evidence_create(0, HASH_ALGO_SHA384); + if (!ev) return ERR_PTR(-ENOMEM); - gtdi->ds.base_tsm.evidence = evidence; + rc = tio_tdi_status(pdev, gtdi->snp_dev, &ts, tdi_id, + &ev->obj[DEVICE_EVIDENCE_TYPE_REPORT]); + if (rc) + return ERR_PTR(rc); + + if (!ev->obj[DEVICE_EVIDENCE_TYPE_REPORT].data) { + device_evidence_release(ev); + return ERR_PTR(-ENODEV); + } + + gtdi->ds.base_tsm.evidence = ev; gtdi->tdi_id = tdi_id; return &no_free_ptr(gtdi)->ds.base_tsm; @@ -271,19 +623,33 @@ static struct pci_tsm *sev_guest_lock(struct tsm_dev *tsmdev, struct pci_dev *pd static void sev_guest_unlock(struct pci_tsm *tsm) { struct pci_dev *pdev = tsm->pdev; + struct tio_guest_tdi *gtdi = pdev_to_tdi(pdev); + struct snp_guest_dev *snp_dev = gtdi->snp_dev; u64 fw_err = 0; - sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_UNBIND, &fw_err, NULL); + tio_tdi_mmio_invalidate(pdev, snp_dev, gtdi->tdi_id); /* Quiesce DMA */ sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_STOP, &fw_err, NULL); - tsm->pdev->tsm = NULL; + /* + * Up until now the VMM has been blocking clearing of BME and the device may + * not be able to recover without BME going via 0, do it now. + * Note that the device reset is still needed, leave to the userspace to + * decide on that. + */ + pci_disable_device(pdev); + + sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_UNBIND, &fw_err, NULL); + + device_evidence_release(tsm->evidence); kvfree(tsm); } static int sev_guest_accept(struct pci_dev *pdev) { + struct tio_guest_tdi *gtdi = pdev_to_tdi(pdev); + struct snp_guest_dev *snp_dev = gtdi->snp_dev; struct pci_tsm *tsm = pdev->tsm; u64 fw_err = 0; @@ -296,7 +662,19 @@ static int sev_guest_accept(struct pci_dev *pdev) if (ret) return ret; - return sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_RUN, &fw_err, NULL); + ret = sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_RUN, &fw_err, NULL); + if (ret) + return ret; + + ret = tio_tdi_mmio_validate(pdev, snp_dev, gtdi->tdi_id); + if (ret) + goto stop_tdi; + + return 0; + +stop_tdi: + sev_tio_op(ghcb_tio_sbdfn(pdev), SVM_VMGEXIT_SEV_TIO_OP_STOP, &fw_err, NULL); + return ret; } static int sev_guest_enable_dma(struct pci_dev *pdev) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:03:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:03:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423026.1648326 (Exim 4.92) (envelope-from ) id 1x6oMY-0008Tt-JA; Wed, 16 Sep 2026 12:03:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423026.1648326; Wed, 16 Sep 2026 12:03: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 1x6oMY-0008Tm-Es; Wed, 16 Sep 2026 12:03:42 +0000 Received: by outflank-mailman (input) for mailman id 1423026; Wed, 16 Sep 2026 12:03:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oMW-0008Sl-TY for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:03:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oMW-00AANj-9Y for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:03:40 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8596-2eae-0a2a0a5409dd-0a2a4502b68c-16 for ; Wed, 16 Sep 2026 14:03:39 +0200 Received: from [52.101.62.37] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa859a-6ca4-0a2a45020019-34653e25f70c-3 for ; Wed, 16 Sep 2026 14:03:39 +0200 Received: from SJ0PR05CA0148.namprd05.prod.outlook.com (2603:10b6:a03:33d::33) by PH7PR12MB5758.namprd12.prod.outlook.com (2603:10b6:510:1d1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.11; Wed, 16 Sep 2026 12:03:24 +0000 Received: from SJ5PEPF00000209.namprd05.prod.outlook.com (2603:10b6:a03:33d:cafe::6c) by SJ0PR05CA0148.outlook.office365.com (2603:10b6:a03:33d::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.8 via Frontend Transport; Wed, 16 Sep 2026 12:03:24 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF00000209.mail.protection.outlook.com (10.167.244.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 12:03:24 +0000 Received: from aiemdee.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 07:03:01 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sdWZGPM/zgWMCChuh52X0kMji/qLxyRnue0l4weppikfIskSxwetWJztFG0+vdh/yuym1d0rd0z3AfQTJLfwN5/s3ttZPOvbaFGTaPbhJkkXfTU7wIDgO0fbrwAc5JCaaTsidDHnutfF/OQFVv1XYn98HJ1W3xvnmWScIDfCUT3K14TyKd7PASinbA8Sk8PoFypDZP5fTlvlv72O+U9SMCcK8jxp/mNUydtEyYrHwfGavd0ucS7VnvEy4x6T/JOxc0I/y7m7k1tEp9FGYw6ZAGvqpO1pnvZy8VTszGO7n/Vrl6+0g9/VY2DU6OMEWRU0tw/CWyETpjwPpA/MYywJ6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WNgXfa5En712+eAspMOEbd4EbM4QDl/vkmtEAEeJtpw=; b=LSYNh5pVts8gPMPMedX0JXjgMQiXo3cpgEMoWw+mHa2iEZwEuZAKy3JVH8sIV7pIGmPmhp1Pdii9dBGHYWUfDaV0yH1y3hpCRTFtVJhCc0K+PedFf69YdzoqYzT2HqGmzRSs9uVXsmJ0xPZOKeqPmEvBxX77/wEC+/CFR0QNoj1/Bv6PYR5S5yWrBIsn+h+41pGYwwPOoqAGPvhk62KHw7QAI0K0wqRibfEVgjss5cLb4NuliWck4voL2FcQcwdG7v/OtNPkoKmw0VmNAxi9FfEkUd6wHZVObbXkDVnCjSrM89ghLFpoHG8o9WNsZ6W0mO4hvtvv3dAyLMTEF37LHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WNgXfa5En712+eAspMOEbd4EbM4QDl/vkmtEAEeJtpw=; b=pEkxIe6WPh1OzcaBTJT4DVHOZUiIH9fM8UC0vHozp9wjEJKN7cTc8RQ2oJN5lIT/WKvmxpwTk90fQw7tTftPmDuF5diikQVG431OJLdqT9rnfRqfjeWMxJu4oTNAbxUZyI+8bsbwvSOuw7uEzI8tt4Fqr8NUiKxBtub7JpwIGes= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alexey Kardashevskiy To: CC: , , , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , "Andrew Morton" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , "Suren Baghdasaryan" , Michal Hocko , "Catalin Marinas" , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , "Liam Merwick" , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?q?Carlos=20L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , "David Howells" , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , "Christian Marangi" , Dave Jiang , "Michael Kelley" , Ilias Stamatis , "Sumanth Korikkar" , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , "Palmer Dabbelt" , , , , , Alexey Kardashevskiy , , Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: [RFC PATCH kernel 17/17] x86/sev: Flush IOMMU TLB for trusted devices Date: Wed, 16 Sep 2026 21:51:57 +1000 Message-ID: <20260916115159.1938195-18-aik@amd.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260916115159.1938195-1-aik@amd.com> References: <20260916115159.1938195-1-aik@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000209:EE_|PH7PR12MB5758:EE_ X-MS-Office365-Filtering-Correlation-Id: 21ea1d17-cfda-4c2c-c170-08df13ea82d3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|36860700016|82310400026|23010399003|376014|1800799024|32650700020|11063799006|56012099006|6133799003|18002099003|22082099003|3023799007|10067099003; X-Microsoft-Antispam-Message-Info: yu/3328I801SY6FsYLc9CmvUZeEctUSSIDcyqxwUJ2hyVwt1WwcikhhyEMaqjVoj9tup6Xs7JzO2JsFAwueqDHDuLJ4UJeD/Cqr0S/gwkM/VbD2cofhYFX+DGMcg8giesVcXkUaTcZfLys+XRE2GX0TEknqjsrq8h+KJMRLuv9azyIRAHjLcNOetKEeY/l3SK+Zl6nQaWCi2uBgCZm871matcHCgw8YPx771yvaq3lo372oXL6vbba3D+LqRDMjyGQXtjXjQ2kEqFmGqfdaiaI24BeoAKNt4T4lsp8YxyrpYck0xZC8v2YQWbWtd2ZjGgUZdlW8WfxK7kNLFYHLfq1OsmitoWZ5nLJKkI5SlgjZ5Y1b6ytdTP9v1b5oOHAKJ/TeeWP3hRt4xn56FdReJnGnJ6Mfx1xjAhoFl16ZwQ25h/RSTrPwtNSOwF0tNev+u2W1ADCXmLBjsw6yfT18W86V2LNNt4b+fRE23l5h0xhIYXcOsWPSB+Y3F5SDGmWere2xqvjMP/gQfj8rpcZxpYarVEjV+OFEKpCid77UcNu/fAGh7619VZIwl2bovx9wB X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(36860700016)(82310400026)(23010399003)(376014)(1800799024)(32650700020)(11063799006)(56012099006)(6133799003)(18002099003)(22082099003)(3023799007)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: cb7bK2cEQmHcr0JP49cyQs52un826U+ce5HZh0WUKLP+NxrD8AcCzH5bePkXMGpnA3ymANrzpOSs6nrnYlJPrhKvhMt+HtLVqqmS/E6++vt5OAdCWcjsBtHKJ+QIvM/bunvTX7sQKQ/2dns2Gc45uni/M6nHqDzJVC8R0Po21vRlnjJa+CcTk0dJZ3HbQ5zUPHsM1WIk9XQj39DDho1cKopgzakVdo/TZNycLzBfRVOk8LuI1piyvQ5BRbAzLqWH76tpNQKNERneQPauhw+yjtUPl1rqfN8chlrueV970xK4gUAPXQ2sMffAzL/zncSCVYK1Hwdgvut4Qb3FsjbJ3ufmR1Vfxlf8u1T+0W2JcqtSsasf0M/f6hxoC+oUKHN+NZI6VVyVLetXy4sdmL6/faQmDdYbLkXxVyvkuVeH1fivn8YnzvYNkPGf8gVbJJcV X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 12:03:24.6817 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 21ea1d17-cfda-4c2c-c170-08df13ea82d3 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF00000209.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5758 X-purgate-ID: tlsNG-720697/1789560219-31FD62AC-CA4974FF/0/0 X-purgate-type: clean X-purgate-size: 7507 IOMMU performs RMP checks when SNP is enabled, the results are cached along with the IOMMU translations. When a VM lowers permission of a mapped page (moves to a lower VMPL level or from read+write to read-only or private to shared), the cached RMP check results require invalidation. At the moment the only way to invalidate IOMMU cache is the RMPUPDATE instruction which flushes all IOMMU TLBs. It is a host privileged instruction so a VM needs a way to ensure the host has done it. Note that the guest's RMPADJUST/PVALIDATE do not flush IOMMU TLBs. The host implements a new "IOMMU TLB Flush" VMGEXIT code which is advertised via bit#11 in the GHCB Hypervisor capabilities. Use RMPUPDATE in the following way: - allocate a page per VCPU (to allow lockless flushing); - When invalidation is needed, copy two patterns (A and B) to the page; - invalidate the page so the host can make it shared; - use new GHCB call to request RMPUPDATE on the host; - the host makes the page shared; - the host clears pattern A; - the host makes the page private again; - the host returns to the guest; - check if pattern A has changed and pattern B has not; - if the above failed, panic(). The patterns are located far enough to not hit the same cache line to work with the cipher text hiding feature. The host can choose to not execute the request, WARN_ON if this is the case. Further patches will attempt to handle this in other way. Signed-off-by: Alexey Kardashevskiy --- arch/x86/include/asm/sev-common.h | 2 + arch/x86/include/uapi/asm/svm.h | 3 + arch/x86/coco/sev/core.c | 92 ++++++++++++++++++++ 3 files changed, 97 insertions(+) diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h index ff763c3c5d63..51abf8d061fa 100644 --- a/arch/x86/include/asm/sev-common.h +++ b/arch/x86/include/asm/sev-common.h @@ -138,6 +138,7 @@ enum psc_op { #define GHCB_HV_FT_SNP_AP_CREATION BIT_ULL(1) #define GHCB_HV_FT_SNP_MULTI_VMPL BIT_ULL(5) #define GHCB_HV_FT_SNP_SEV_TIO BIT_ULL(7) +#define GHCB_HV_FT_SNP_IOMMU_TLB_FLUSH BIT_ULL(11) /* * SNP Page State Change NAE event @@ -210,6 +211,7 @@ struct snp_psc_desc { #define GHCB_TERM_SECURE_TSC 10 /* Secure TSC initialization failed */ #define GHCB_TERM_SVSM_CA_REMAP_FAIL 11 /* SVSM is present but CA could not be remapped */ #define GHCB_TERM_SAVIC_FAIL 12 /* Secure AVIC-specific failure */ +#define GHCB_TERM_IOMMUTLB_FLUSH 13 /* IOMMUTLB flush failed for SEV-TIO device */ #define GHCB_RESP_CODE(v) ((v) & GHCB_MSR_INFO_MASK) diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h index 93597ad492bf..269050942c8e 100644 --- a/arch/x86/include/uapi/asm/svm.h +++ b/arch/x86/include/uapi/asm/svm.h @@ -160,6 +160,8 @@ #define SVM_VMGEXIT_SEV_TIO_OP_UNBIND 1 #define SVM_VMGEXIT_SEV_TIO_OP_RUN 2 #define SVM_VMGEXIT_SEV_TIO_OP_STOP 3 +#define SVM_VMGEXIT_IOMMU_TLB_FLUSH 0x80000022ull +#define SVM_VMGEXIT_IOMMU_TLB_FLUSH_NO_ACTION 1 #define SVM_VMGEXIT_HV_FEATURES 0x8000fffdull #define SVM_VMGEXIT_TERM_REQUEST 0x8000fffeull #define SVM_VMGEXIT_TERM_REASON(reason_set, reason_code) \ @@ -285,6 +287,7 @@ { SVM_VMGEXIT_AP_CREATION, "vmgexit_ap_creation" }, \ { SVM_VMGEXIT_SEV_TIO_GR, "vmgexit_sev_tio_guest_request" }, \ { SVM_VMGEXIT_SEV_TIO_OP, "vmgexit_sev_tio_op" }, \ + { SVM_VMGEXIT_IOMMU_TLB_FLUSH, "vmgexit_sev_tio_iommu_tlb_flush" }, \ { SVM_VMGEXIT_HV_FEATURES, "vmgexit_hypervisor_feature" }, \ { SVM_EXIT_ERR, "invalid_guest_state" } diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index ed0e4546d5e5..aa5a3abb4796 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -44,6 +44,7 @@ #include #include #include +#include #include "internal.h" @@ -103,6 +104,36 @@ static unsigned long snp_tsc_freq_khz __ro_after_init; DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data); DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); +DEFINE_PER_CPU(u8 *, iommu_tlb_flush_ghcb_page); +static atomic_t sev_tio_devices_num; + +static int alloc_iommu_tlb_flush_ghcb_pages(void) +{ + unsigned int cpu; + struct page *pg; + void *p; + + /* + * Allocate per CPU pages while encrypted DMA is not happening yet + * and smashing is cheap. + */ + for_each_possible_cpu(cpu) { + if (per_cpu(iommu_tlb_flush_ghcb_page, cpu)) + continue; + + pg = alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL, 0); + if (!pg) + return -ENOMEM; + + p = page_to_virt(pg); + /* Trigger psmash in the host os now to avoid psmash race later */ + snp_set_memory_shared((unsigned long)p, 1); + snp_set_memory_private((unsigned long)p, 1); + per_cpu(iommu_tlb_flush_ghcb_page, cpu) = p; + } + + return 0; +} int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) { @@ -111,6 +142,24 @@ int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) struct ghcb *ghcb; int ret; + if (!(sev_hv_features & GHCB_HV_FT_SNP_SEV_TIO)) + return -EPERM; + + if (op == SVM_VMGEXIT_SEV_TIO_OP_RUN || op == SVM_VMGEXIT_SEV_TIO_OP_STOP) { + if (!(sev_hv_features & GHCB_HV_FT_SNP_IOMMU_TLB_FLUSH)) + return -EPERM; + + if (op == SVM_VMGEXIT_SEV_TIO_OP_RUN) { + if (atomic_inc_return(&sev_tio_devices_num) == 1) { + ret = alloc_iommu_tlb_flush_ghcb_pages(); + if (ret) + return ret; + } + } else if (atomic_dec_return(&sev_tio_devices_num) == 0) { + /* Do cleanup or leave it like this? */ + } + } + /* __sev_get_ghcb() needs IRQs disabled because it uses per-CPU GHCB. */ guard(irqsave)(); @@ -347,6 +396,42 @@ static int vmgexit_psc(struct ghcb *ghcb, struct snp_psc_desc *desc) return ret; } +static int ghcb_flush_iommu_tlb(struct ghcb *ghcb) +{ + /* AES encrypts with 16 byte blocks */ + unsigned long s1[BITS_TO_LONGS(128)], s2[BITS_TO_LONGS(128)]; + void *p = this_cpu_read(iommu_tlb_flush_ghcb_page), *p2; + struct es_em_ctxt ctxt; + int ret; + + if (!p) + return -ENOMEM; + + /* Keep patterns apart far enough to not share the same cache line */ + p2 = (u8 *) p + 2048; + + vc_ghcb_invalidate(ghcb); + + BUILD_BUG_ON(ARRAY_SIZE(s1) != 2); + if (!rdrand_long(s1) || !rdrand_long(s1 + 1) || + !rdrand_long(s2) || !rdrand_long(s2 + 1)) + return -EFAULT; + + memcpy(p, s1, sizeof(s1)); + memcpy(p2, s2, sizeof(s2)); + + pvalidate((unsigned long) p, RMP_PG_SIZE_4K, false); + ret = sev_es_ghcb_hv_call(ghcb, &ctxt, SVM_VMGEXIT_IOMMU_TLB_FLUSH, __pa(p), 0); + pvalidate((unsigned long) p, RMP_PG_SIZE_4K, true); + + /* Ensure that the host change is visible */ + smp_mb(); + + if (!memcmp(p, s1, sizeof(s1)) || memcmp(p2, s2, sizeof(s2))) + return -EFAULT; + + return 0; +} static unsigned long __set_pages_state(struct snp_psc_desc *data, unsigned long vaddr, unsigned long vaddr_end, int op) { @@ -404,6 +489,13 @@ static unsigned long __set_pages_state(struct snp_psc_desc *data, unsigned long if (!ghcb || vmgexit_psc(ghcb, data)) sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PSC); + if (atomic_read(&sev_tio_devices_num)) { + int ret = ghcb_flush_iommu_tlb(ghcb); + + if (ret) + sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_IOMMUTLB_FLUSH); + } + __sev_put_ghcb(&state); local_irq_restore(flags); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:07:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:07:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423041.1648334 (Exim 4.92) (envelope-from ) id 1x6oQC-0001QE-26; Wed, 16 Sep 2026 12:07:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423041.1648334; Wed, 16 Sep 2026 12:07:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oQB-0001Q7-UO; Wed, 16 Sep 2026 12:07:27 +0000 Received: by outflank-mailman (input) for mailman id 1423041; Wed, 16 Sep 2026 12:07:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6oQ9-0001Ol-Sx for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:07:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6oQ8-007qg5-OK for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:07:24 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8675-8faa-0a2a0a5109dd-0a2a450ab456-24 for ; Wed, 16 Sep 2026 14:07:24 +0200 Received: from [40.107.209.57] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8679-f2d2-0a2a450a0019-286bd1393e79-3 for ; Wed, 16 Sep 2026 14:07:24 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5496.namprd03.prod.outlook.com (2603:10b6:5:2c8::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 12:07:19 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 12:07:19 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ypAQPKhkhg7pKDPGPk80nCJp3xBU9l7t230wXnISFtBAJWmpWQlybn1v50fxCHBh+g8epMNkAwekgUSNpV5qcArXd9PUuXm1QBFiMZ6D6T5Fk0cC69Bp5xilrGhbyTvuMRcbpkiB9T1g384YSecCLilRJo08nqFov/RMVbq6Px1me/k8ZiEC1OP5sSrlZMSZWawJ10/GQ4MPCI8HiLivb7etSvxLX9F2lL98E6J+nHpn/1p9fUNI/6H5QYbaJQYgtPgUz5ISerhGBiGxN0TM1Uh5Y6DZeVXTVY3RnCjxPiZqAI3Ui+W9f+eif9zvmV+1glL1m5slbp2dOUIwYk8+Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0vZ4XXFbt5a3v02WEzaqIp/5eYWAcGbB5UTBBruBXWM=; b=W4hjqdN40f3y/wXuX5jueYW73YZqXbZwg2HLcFyFf420+wRWn8pocW3Eo40MItqHC19wG87rhwEGDtkdk7JrcM/Masg3g2NuOSO9MciuPo0NS/3gGNUb8yGXQ8FsGxRuwMtmkpGqI33qJSfWQmfT/MuOAWO8qN1iqYoItL6yxfn9J7t+FW9gtFlf0RSTza8MevcNwx1/OxpiITdshAM8Wfcl9DC97quyHShL77PlBJAdzvEn6yhoeRQSG5PHqWxYzEuhDAZsv6R3GwEikB5wpI3gx06wMWb+eHc5vOJ+akJfANylhq2O2BYPeXwKgJgahqZV7VSs/H0UiMgukNEVKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0vZ4XXFbt5a3v02WEzaqIp/5eYWAcGbB5UTBBruBXWM=; b=n2d1ugrYbH2ZEYYsDoMFdNI7dppPOISypr5mMlY2WmLA2Snq5B2RLkI6VIioDRTnbe3a4J/4n2oub3VLk/UEgSRcEXk1OGpgBNkcr+7RHPkspqgFa9Mf4Rodjj/9+TuehSkJ25/aHY7OgZFItiZyPptB2b92rCGx2anaDOQrLXs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 16 Sep 2026 14:07:15 +0200 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jgross@suse.com Subject: Re: [PATCH] xen: fix comment typo in xen.h To: Ruslan Vagner , xen-devel@lists.xenproject.org References: Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR4P281CA0387.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:f7::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5496:EE_ X-MS-Office365-Filtering-Correlation-Id: ab291a0d-8c04-43bf-6e12-08df13eb0e41 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|6133799003|10067099003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: K0I7O7NjAcxVj/T7bIIxYf4eYf4eu7ybe9WciEYJIsE/a9zWtjgY/ud+F+N841iPcLlnJTV3/BYGh9DKHj9VAwy8iUvhpeACpEWmpJ/GXmZrLNzWFBcuSWP16WYaYy4lnschNFhWo3SAYdi6frJwokyNHl/20qesKUWjmKcWZXZ73scMT0CzFTFtnCvbhkr32L3+qmxiigBu3yT8EmHGqH/rKCPTYdyA+tAwdWqJAbUcDI2btiB82BkH6bKUqcO3TryaT/gfIhxNZj3Vb/kHMZX4ug58+1MAdC2BsKGerlQttDhyYFkL0f3MVhtlbhsZHJlHo2gfzDIYw4WGCqamlmS3V6OMJu4ECyyRtjqIuDFw7JhLTod31jRogXE3zAGlf6t7l1pCqbE5FYRoZpaqJgAoe32VHDae06eA0gVgtYJHqo8fncFCJwKwRB9C63xBw9/7CKboWXJSRIN40OvkRhDiYBZgtcQNP+PKB6fxuKays8jZ/TdtciB7fjC0TA6BGodsq6XFgmFuf5E4jJp6rLv+hv/XM9/zafKgBR3t70WWcodJRdzEl1n/U6qUMZz+dZV6kHY3PIRLIPCkIiObSxb0H15h98J/LNvx9XQ9jqSueooVczlPBTiLMlswvQ7Q+PkC5fwA8BGXKz5sjtJuc2Kf/j9ChTAocW2PUosGHkQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(6133799003)(10067099003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TFUwT0J6M1l2OTZtVkxPZTdZNVRJNC95UzZPMXlPSjBzNm1sYm5rU3NzN1V0?= =?utf-8?B?eUtlR3lQdnRDbVBoM1VvL1FBRU9SaDdjakxwbGhhRmRTRmpUNHVlSjRYcXYy?= =?utf-8?B?ZWNBZi9UZFFWQUJyOEhyejJ2TU81d1NZbUJLSGhhSDVsck1LT21qa3pIK09a?= =?utf-8?B?R0Rxd1VZZHh2Y1ZidzJTWjZvckNtUmQ1M0J0YTMzOXZxQnY1NDRsU0lhb21u?= =?utf-8?B?RzFHdzUvVWk1VldJdFRQVDdNb0dFRklxTDFBT2RGdFc5OG52bS9DSkUzZVhX?= =?utf-8?B?dWxDU1FDUkZjQXh6ZENEWUczdSs1Q0haSnpEbGxvSUxZeHFhYlJ1YldPNFBz?= =?utf-8?B?QlhCUVZtb1U2RGlza0o0RXg1b3hYalJRYU9iTERDeWtyMlpEMU9VaktGVWZm?= =?utf-8?B?SDVEbFhoOHVkaEpYcmlnZTU1bkNFSzN3WUpKbjdiS251cGdvWXpWTHhLdGcv?= =?utf-8?B?TnF1NGQxMWtNQlBTL1ZYLzNZbWFPOW1xL2VTcjRqeXpOOFBMUGRyMHgrdEY4?= =?utf-8?B?eFE5ME1hNzNpcldUVHVXSkZGa1oyV3RlN2VUcWlyRzJYLzVma0M3a2xEaC9G?= =?utf-8?B?RlZyRVZHNjBKd1lJQnRyTGlTMENzbDlsdzhwRWRHZm5xL2x1MEJHczdGNllr?= =?utf-8?B?M3YrazkvLzdRN3FnUjV1MXZyNm5aRnV2Q3JiNW5iZzRiRWtNNmwrMEg2TWdm?= =?utf-8?B?Ukp6YUhxTFEzVFBudWRDU3dwcjBKaUJRT29ZWHJQRU43NWdaZE93MzBmNjZr?= =?utf-8?B?MW9VbjhDanAxNG11cnp0UHZtTHlZbGFzdkxuL1ZRcDNNdFVRSU1HRnJybFpn?= =?utf-8?B?MTJrYUV3VE9tZFY2MmZuWHpEN0U1U2dDRVhsMnJZSEJIUEdGYXhVTmsvb2M0?= =?utf-8?B?RFJucUdKdUlUSVdOcUNjMERadE5wSGhiUnR2M2JtR04wUi9iTWpFNVc3M29L?= =?utf-8?B?RUgwak1kdlpueUM2emNtWWV6dkxvTkI5K1VXRGkwamhRRWRRSnB4SVlPNFRv?= =?utf-8?B?cWs5UUJDalJRaFJSMFJrSnNVSTF0VGNib0FndUhCTmlEb0Y1U1VPMEJ3NkRt?= =?utf-8?B?K0N4UDBSWlVHQVVPYWdBN1c3N3Roc3VTQlBac3E0R3FrLysrckM2TVpxNXZQ?= =?utf-8?B?dzQ2TWlMTFF6dWxpUnE4WGE1dFhhbjV1NmVEaktSNzNseFVGazNaRXVlQm9R?= =?utf-8?B?WElSVVkwb3YwZXM1azFmQWwwTlR4RmRGVXhUTUpXRXdNU3RneGtoNnh1Ymd5?= =?utf-8?B?M0VQRjJpNzh3RWw5RHJuY3BhK093RW5mNmlucGNMYkJhVi9FYk04clFuTmF1?= =?utf-8?B?QlJRTXJocTVFVUZ3bUFmTEd1OW43Q3hGMW5KRGhwZGwxUWp6bjZZUm81d0NB?= =?utf-8?B?cDNDZjh5ODlJbmE2VEJwcHRwWU5YeUhaZ3ZOeTgvNThKbkJzS1Vmb2xVR1dJ?= =?utf-8?B?YzkzQUdLclBSekc5Uk5wRzJLTnltSi9TU3NZSVlEZEwyZUhkRkZuUGJzRTB6?= =?utf-8?B?UFIzMDdZa1NoeTZCbm14TkpYWnNRZ0ZYWVlTc2lsU0JlNUcvbDJWVEZDaE1p?= =?utf-8?B?ODMwdkREcTFzTC8ySUR5amFCMWdPRkJQTEVBQXZhMFpjL2N2TE1yeXpXZGpY?= =?utf-8?B?bENVMDZIeldmTHNvbTdVSExOVUNTVTBBejdidm9RV2doR3lXSEVYYTdjeE5E?= =?utf-8?B?QTZ6NnFEOHBBeTNxWEdoZVFmdmphWGE1ZUkyRHRqQVZxVzk5Ri9sa1d5NnhR?= =?utf-8?B?cXVIMEFxTG8reVB4THo5aGZ6cHRzWUFpVmovakV3SldSR2tCMDk3K29HSitm?= =?utf-8?B?d1lta3lSdWpvMEE3QTlha25UL2s1a3dJVGM3dEhwR2hlRUdKK2JYMXNnbHdV?= =?utf-8?B?QUFuaGt1bWc1RFdoMTlRQTRTZUR4TnV3TG9xUGpJMGRIK0RpZEN3Y1JGQWpR?= =?utf-8?B?SnA0Um5JMndXMk5FUjZmZmIxOUlBTWtaVElZdjR0RXl2eHJWMW9BZzd5Vjcy?= =?utf-8?B?MEhkZVFsbXFTZEV4NEtrRldrSWJpT3U3cnFja1V1UFczNnp1d0ZSVGVtcVN2?= =?utf-8?B?aWdWaG5VMGZ3M3dVemthTC9WNG5NU2lGTEU1dmhWaS83a09EWmRzZzN4SE00?= =?utf-8?B?YkVVbjhHOFhidmNRNGp5QkJVWGhmNVFYc0E0S3NkZG40VUMwdXV4LzZxY0ox?= =?utf-8?B?UWowaWtkU2I4bjZ5QXdIeU1GRU1TWGZYWWU2cVQ3ZnIwRVY4OElXUXROU0ZY?= =?utf-8?B?SzlodnlZMFowcjVydUhrWmJpWXZTZThTeVYwKzhsVi9QRGFzaytXWlRKcnFn?= =?utf-8?B?eVZNai9kbTVhR09nZEg5ekVjMzJjb3I5bkIxMWhaQzQ1bDVUSUh5UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab291a0d-8c04-43bf-6e12-08df13eb0e41 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 12:07:18.9092 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7277ZqZnpnnv/47Nv6TR8tXG7hHAc1ghNKemVlGHJVHkiEnZ+TD1FrcdzVaSMRTcRZ907u0RbQEqjTuq77r/aYoObbDPiDA6CAYNqLM7HI0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5496 X-purgate-ID: tlsNG-4011c0/1789560444-50CCBCFC-1A6DA991/0/0 X-purgate-type: clean X-purgate-size: 1430 On 15/09/2026 2:56 pm, Ruslan Vagner wrote: > Fix the spelling in comments. No functional change. > > Signed-off-by: Ruslan Vagner > --- > include/xen/interface/xen.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h > index 40c9793e9880..f9acb21875cf 100644 > --- a/include/xen/interface/xen.h > +++ b/include/xen/interface/xen.h > @@ -94,7 +94,7 @@ > #define VIRQ_XENOPROF 7 /* V. XenOprofile interrupt: new sample available */ > #define VIRQ_CON_RING 8 /* G. (DOM0) Bytes received on console */ > #define VIRQ_PCPU_STATE 9 /* G. (DOM0) PCPU state changed */ > -#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occured */ > +#define VIRQ_MEM_EVENT 10 /* G. (DOM0) A memory event has occurred > */ > #define VIRQ_XC_RESERVED 11 /* G. Reserved for XenClient */ > #define VIRQ_ENOMEM 12 /* G. (DOM0) Low on heap memory */ > #define VIRQ_XENPMU 13 /* PMC interrupt */ The change is fine, but the email is whitespace corrupted, with the closing */ moved onto the next line. I can fix this up on commit, but you will want to double check your email configuration before sending further patches. Acked-by: Andrew Cooper ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:21:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:21:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423061.1648343 (Exim 4.92) (envelope-from ) id 1x6odp-0007lZ-8t; Wed, 16 Sep 2026 12:21:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423061.1648343; Wed, 16 Sep 2026 12:21:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6odp-0007lS-63; Wed, 16 Sep 2026 12:21:33 +0000 Received: by outflank-mailman (input) for mailman id 1423061; Wed, 16 Sep 2026 12:21:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6odn-0007lM-UV for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:21:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6odn-007tnW-AO for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:21:31 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa89bd-e002-0a2a0a5209dd-0a2a45019a56-44 for ; Wed, 16 Sep 2026 14:21:31 +0200 Received: from [74.125.229.205] (helo=mail-lf2-f13.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa89ca-5984-0a2a45010019-4a7de5cdca34-3 for ; Wed, 16 Sep 2026 14:21:30 +0200 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b5e4f13d76so928787e87.3 for ; Wed, 16 Sep 2026 05:21:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:To:Subject:Message-ID:Date:From:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1789561290; cv=none; d=google.com; s=arc-20260327; b=sbV7ADaxucQb4sRmPcMlBnKif/QCtRruu25YEJGazIFkAXlGDcjKJlSG9ovNfVyYRz jopCB36+xEyBZkSGhyB2dMCj2ZQ1ZUcS4cNb0YR1Zes0BnEb7IuA19NndOJN4tWkrvU7 AGjiKNGLJUh1LHEsX21lewcJvZR2eo7kicO62qCFJOmLE59Evg7Zdp36njdhJ1nYDY9J +M523mgwxASzPk36is55WET0M/ITDKaQ1j3tpkBWqXN1dAM+djdB1ZGRqqf29AcfimOr Z4mX85j1UJ5m6JWYtESjg6HTpPZbFII6cmZjs2ncd6h4UrEcuapSFOh15zb9/O/dsLWF /GBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=YqO0WlKHE0+GoRcBS3yjBKiqahNfqfB6FZoicxS9Bcc=; fh=quJY5mN2l4ZorNvEoO9ngNXalhEvTdq/+W8CvHWhECs=; b=KVBX49kgvaxlxdfeydCiW2QN5+ps+0cmBgehP44CKnotl7PQuQVAyU2nn9RUIv6jeX 1Bi2hJAjAPVBruRbn8agIb6OAgNPntl/ns1Vk3otCq9PSAj53qun6oZi93Nppeyd+nGa h4tl+/frnFzxflWOpZ49u2Ft2QRe+pfbDRBzSbswZoNYoBqjzOprOFzAD8ayps0CEYoF HAyP5mWNKBUeFxIO68KKWoErf9b58G0pqWxwk0ASOFznjF5TEsvGgoadzBiaXeA/rjFw 4c9PrSJiCrBqlzzHCutAG+/1b3mPoNjya400IRxL4kHFylUUU+UaCqxWYrg9AoS75KnD 6L6w==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789561290; x=1790166090; darn=lists.xenproject.org; h=content-type:to:subject:message-id:date:from:mime-version:from:to :cc:subject:date:message-id:reply-to:content-type; bh=YqO0WlKHE0+GoRcBS3yjBKiqahNfqfB6FZoicxS9Bcc=; b=dvd228xea04qJeyvz8ql/wh+BB9XM+d9hXdRHgsZWG1WiBWQQ/XDMogsbbXg489221 VGAW/r0LI8kgmlPr6+dqwycNMj/PSLErUr5bImgVXjiiFOGCH4gMmi5gYFyiEDjXeP6q aoJ2bcXyy4CD9CGnrzx0D40eLLfF2Hm+2vr5TBPQEjxzrykuwbuLGO4NAE6tI1kB8YVy ilvFanDLdfqu7fN5Spz4vnRQaFXlzxs+qg+fpgB0ANopCl/LOalN1xaVRlu3lL4sHqw4 FXis4DkD8T4D3w1JGQtjC4JMhuXCsjcxcW+6PIu3o8Qm0NVKxYxijDq9Tz3Z3LYq0sDF QDUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789561290; x=1790166090; h=content-type:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=YqO0WlKHE0+GoRcBS3yjBKiqahNfqfB6FZoicxS9Bcc=; b=w/cQRqkpC+Q53ulfaoLK5Ix+1e4kjSnyMh9RuaRg5lce0Y2WFrk0RD7B46eK6Yk/iE 3DXiauRaBMRxqgaSd0C2eoePocLsZxUI30vhi/EuaqTyGCpHtRMxdUs55+ZfwlET0bOV vx5kmA4U4GJ5HKTFYw5xHbeYh5RPvDDpu1MAoeUThslUNPUnYzCjKjNReumip7LI8nNh eMRpdlbDoZlSDZyPw44OqvBfX8nobzf2P9vLBYhn0zUcPD6+HveqHl07uHrjJFQTbX9r a+4vbL+AjIQZ7JYiU6kN2t2QgyftJtKV0G4Sjxu9Yz0AOwfm1sxc8Xjkrrv1+g8Igmbu UMFA== X-Gm-Message-State: AFuF++lHenEwm3SLO+F9ArvPeRYiZjDwB8ywMjvio6VT6BADEeie51hg DtI0+bXxJK7SW4nmS92lGDYkCtRo0ME3Swtn7zpV8YWdhj8Dxoh9VPEAMzhQIhY2BWPCwSMTVGk YkaotUZs3UAqwncM4MB1hLNkul76hj1ZDWC8gfLSyxw== X-Gm-Gg: AYBFou3XGgI21NSzoBwH5qN4+lwYAKVz1kt6P06rrPiC9ivA50eG6dGGwfIunqW2bF/ PZO4lT+leOvawrXHqYJeBLSpKzfPH7IWoSbRLprZ92KWgbG3KmDbCu29BLkmXlxwfPXu7/U0zx8 PcyFI4+B+1kXZVNfZb09eehwYeTgBLnwxYY0YNHeV+c1c48akPZM4Uk8Uy0uj7QBnolXAz9hJjw RR6xr/AFlL5GzDapVtkNNKUG3cyhx348XMqIX4OrAZAEUdPqqjLV1CW7TTf7XAjQL86TpeiBcCJ waEHuHlqlZ8kmGRdKQ3gvlgv8nxL5/gAgDjna6weF7I8cu35QamsRuC+lxjlywV+llgOEKjTvq3 y1HOVjZCg7nOYJw73iJlJbGh4kbnefCLruTMbJg== X-Received: by 2002:a05:6512:3996:b0:5b6:1a7c:2a with SMTP id 2adb3069b0e04-5b8b665689bmr648894e87.45.1789561289837; Wed, 16 Sep 2026 05:21:29 -0700 (PDT) MIME-Version: 1.0 From: Anton Markov Date: Wed, 16 Sep 2026 15:21:18 +0300 X-Gm-Features: AcwNN1VULV0aY1I9iNDEeGvRj12DW5z2jAcH21Ms4o8BilSgyydGcYQVHJsK9c4 Message-ID: Subject: [BUG] xen-swiotlb: 32-bit coherent DMA mask rejected on PV dom0 since 6.6 (CONFIG_SWIOTLB_DYNAMIC), aacraid probe fails To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000fc0ec5065b98b4aa" X-purgate-ID: tlsNG-d62444/1789561290-1FE68757-8EF9624C/0/0 X-purgate-type: clean X-purgate-size: 9504 --000000000000fc0ec5065b98b4aa Content-Type: text/plain; charset="UTF-8" Hello, I'm hitting a regression on a PV dom0 where a driver that requests a 32-bit coherent DMA mask fails to probe. Bare metal with the same kernel is fine. Environment: Xen: 4.21.2-pre dom0: Ubuntu 24.04, linux-image-6.8.0-139-generic (Ubuntu stock, CONFIG_SWIOTLB_DYNAMIC=y) dom0 mode: PV Hardware: Supermicro X10DRW-i (BIOS 2.0, 12/17/2015), 2x Xeon E5-2670 v3, 128 GB RAM Controller: 81:00.0 RAID bus controller [0104]: Adaptec Series 8 12G SAS/PCIe 3 [9005:028d] (rev 01) Xen command line (no dom0_mem, so dom0 gets all host memory): placeholder ucode=scan dom0_max_vcpus=4-48 dom0_vcpus_pin=0 force-ept=1 ept=no-ad,no-pml hap_1gb=0 hap_2mb=0 altp2m=1 hpet=legacy-replacement smt=1 spec-ctrl=no gnttab_max_frames=512 cpufreq=xen:performance max_cstate=1 sched=credit sched-gran=cpu apicv=0 sched_credit2_max_cpus_runqueue=48 credit2_runqueue=cpu credit2_load_window_shift=33 credit2_load_precision_shift=18 sched_credit_tslice_ms=5 sched_ratelimit_us=500 hvm-freeze-on-pause=adaptive no-real-mode edd=off Symptom (dmesg): aacraid 0000:81:00.0: PCI 32 B consistent dma mask set failed aacraid: probe of 0000:81:00.0 failed with error -5 The controller is present in lspci, the driver loads, but dma_set_coherent_mask(DMA_BIT_MASK(32)) is refused, so the disks never appear. Booting the same kernel without Xen works. What probably goes wrong: Since v6.6, xen_swiotlb_dma_supported() checks xen_phys_to_dma(hwdev, default_swiotlb_limit()) <= mask With CONFIG_SWIOTLB_DYNAMIC=y, default_swiotlb_limit() returns io_tlb_default_mem.phys_limit, which swiotlb_init_remap() sets to virt_to_phys(high_memory - 1) because Xen passes SWIOTLB_ANY (ad96ce3252db, used by swiotlb-xen since 05ee774122bd). On a PV dom0 that pseudo-physical address translates to a machine frame that, on any host with RAM above 4 GB, is above the 32-bit mask, so every 32-bit coherent mask request is rejected. Before v6.6 the check used the end of the actual default pool, which xen_swiotlb_fixup() places below 4 GB, so 32-bit masks always passed. The coherent allocation itself would still succeed via xen_swiotlb_alloc_coherent() / xen_create_contiguous_region(); only the capability check is wrong. This looks like the same root cause as the unanswered report from July 2024 (megaraid_sas, 63-bit mask, "Failed to set DMA mask"): https://lkml.iu.edu/hypermail/linux/kernel/2407.3/08254.html That report already confirmed CONFIG_SWIOTLB_DYNAMIC=n makes the problem go away. The 32-bit-mask case here is deterministic on any >4 GB host, so it should be easy to reproduce. A minimal change that restores the previous behaviour, e.g. return xen_phys_to_dma(hwdev, io_tlb_default_mem.defpool.end - 1) <= mask; probably isn't the right fix for dynamic pools in general, but I wanted to flag where the check went wrong. Happy to test patches on this hardware. Thanks. --000000000000fc0ec5065b98b4aa Content-Type: text/html; charset="UTF-8"

Hello,


I'm hitting a regression on a PV dom0 where a driver that requests a 32-bit coherent DMA mask fails to probe. Bare metal with the same kernel is fine.


Environment:

Xen: 4.21.2-pre

dom0: Ubuntu 24.04, linux-image-6.8.0-139-generic (Ubuntu stock, CONFIG_SWIOTLB_DYNAMIC=y)

dom0 mode: PV

Hardware: Supermicro X10DRW-i (BIOS 2.0, 12/17/2015), 2x Xeon E5-2670 v3, 128 GB RAM

Controller: 81:00.0 RAID bus controller [0104]: Adaptec Series 8 12G SAS/PCIe 3 [9005:028d] (rev 01)


Xen command line (no dom0_mem, so dom0 gets all host memory):

placeholder ucode=scan dom0_max_vcpus=4-48 dom0_vcpus_pin=0 force-ept=1 ept=no-ad,no-pml hap_1gb=0 hap_2mb=0 altp2m=1 hpet=legacy-replacement smt=1 spec-ctrl=no gnttab_max_frames=512 cpufreq=xen:performance max_cstate=1 sched=credit sched-gran=cpu apicv=0 sched_credit2_max_cpus_runqueue=48 credit2_runqueue=cpu credit2_load_window_shift=33 credit2_load_precision_shift=18 sched_credit_tslice_ms=5 sched_ratelimit_us=500 hvm-freeze-on-pause=adaptive no-real-mode edd=off


Symptom (dmesg):


aacraid 0000:81:00.0: PCI 32 B consistent dma mask set failed

aacraid: probe of 0000:81:00.0 failed with error -5


The controller is present in lspci, the driver loads, but dma_set_coherent_mask(DMA_BIT_MASK(32)) is refused, so the disks never appear. Booting the same kernel without Xen works.


What probably goes wrong:


Since v6.6, xen_swiotlb_dma_supported() checks


xen_phys_to_dma(hwdev, default_swiotlb_limit()) <= mask


With CONFIG_SWIOTLB_DYNAMIC=y, default_swiotlb_limit() returns io_tlb_default_mem.phys_limit, which swiotlb_init_remap() sets to virt_to_phys(high_memory - 1) because Xen passes SWIOTLB_ANY (ad96ce3252db, used by swiotlb-xen since 05ee774122bd). On a PV dom0 that pseudo-physical address translates to a machine frame that, on any host with RAM above 4 GB, is above the 32-bit mask, so every 32-bit coherent mask request is rejected.


Before v6.6 the check used the end of the actual default pool, which xen_swiotlb_fixup() places below 4 GB, so 32-bit masks always passed. The coherent allocation itself would still succeed via xen_swiotlb_alloc_coherent() / xen_create_contiguous_region(); only the capability check is wrong.


This looks like the same root cause as the unanswered report from July 2024 (megaraid_sas, 63-bit mask, "Failed to set DMA mask"):

https://lkml.iu.edu/hypermail/linux/kernel/2407.3/08254.html

That report already confirmed CONFIG_SWIOTLB_DYNAMIC=n makes the problem go away. The 32-bit-mask case here is deterministic on any >4 GB host, so it should be easy to reproduce.


A minimal change that restores the previous behaviour, e.g.


return xen_phys_to_dma(hwdev, io_tlb_default_mem.defpool.end - 1) <= mask;


probably isn't the right fix for dynamic pools in general, but I wanted to flag where the check went wrong. Happy to test patches on this hardware.


Thanks.

--000000000000fc0ec5065b98b4aa-- From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:40:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:40:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423076.1648368 (Exim 4.92) (envelope-from ) id 1x6owD-0007qb-US; Wed, 16 Sep 2026 12:40:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423076.1648368; Wed, 16 Sep 2026 12:40:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6owD-0007qS-RN; Wed, 16 Sep 2026 12:40:33 +0000 Received: by outflank-mailman (input) for mailman id 1423076; Wed, 16 Sep 2026 12:40:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6owC-0007mw-5m for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:40:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6owB-004nD8-Ir for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:40:31 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa8e32-e002-0a2a0a5209dd-0a2a4502c50e-38 for ; Wed, 16 Sep 2026 14:40:25 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa8e38-6ca4-0a2a45020019-aceafc1f95b0-3 for ; Wed, 16 Sep 2026 14:40:25 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 5B19740248; Wed, 16 Sep 2026 12:40:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 897C31F000FF; Wed, 16 Sep 2026 12:40:22 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789562423; bh=7AU/8ACJEmdfMEzWFUoLouoFn9hVgqhFaXoJr5gmXy0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=WIJFRT40PNWCKpJEGdeyOHWQs2coLd0zbqmAGheVUz0XzbaIhFkUQ1tuVTMRTz0IE 9MKQlzG6J1v0UfcJygkPvKJozwlsQrnUjaMakzWadv4L6dGulYSUqvENefsZ2cIURx e3g6QyEiLDyESMbbYUSKrphJEieWL+uqCprVnN7n61v1eo3Qg6lnoP5k+NPMgemXUJ y9/V4fTq+wWUnUogN5WSpt3wM0wK5axcpILVbmVA1++yV815rVyxfVEneI0GYu8Ze5 ase2yrBBtCFqdkglLPiLLuC5iqEDJ6i++91EG0Qfy6A1twPB1cUhwrqml2KebAgEMk TQAOGzSqc0DtQ== Date: Wed, 16 Sep 2026 14:40:20 +0200 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-720697/1789562425-F24B62AC-7CE1B05C/0/0 X-purgate-type: clean X-purgate-size: 2741 Le Tue, Sep 15, 2026 at 04:56:41PM -0700, Paul E. McKenney a crit : > > Alternatively the approach could be generalized to vanilla RCU, it could be > > possible to define a .text.rcu_no_qs section within which code running is > > considered as an RCU reader (with a pause while on the explicit RCU tasks > > section). It would be forbidden to voluntary sleep inside > > and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). > > > > Based on IP, RCU could consider those interrupted section as readers. This would > > require PREEMPT_RCU though. > > > > And then synchronize_rcu() would do the 1, 2, 4 jobs. > > If I am following correctly (ha!), sleepable BPF programs rule out use > of RCU in this manner. > > But your point is nevertheless valid, in that SRCU could be used. > And because rcu_read_lock_trace() is a thin wrapper around SRCU-fast, we > *might* be able to instead use rcu_read_lock_tasks_trace(), which would > skip the task-struct increment and decrement, saving a few instructions. > Then, instead of waiting for each task's counter to go to zero, instead > just invoke synchronize_rcu_tasks_trace(). > > Which is pretty close to what Josef is proposing, just with the new RCU > Tasks Trace read-side primitives. I think. ;-) > > This assumes that we do not need to flatten partially overlapping RCU > Tasks Trace readers into one big reader. > > Or am I missing something here? Yes I think that's what Josef does in this patchset. The problem is about handling the few instructions: 1) between the begining of the trampoline and the call to rcu_read_lock_trace() 2) between the call to rcu_read_unlock_trace() and the end of the trampoline So what I'm proposing is to make those two parts implicit RCU read lock sections. So the whole trampoline would be .text.rcu_no_qs: .text.rcu_no_qs trampoline: __________________________________________________________________________________________ |Few instructions 1 | rcu_read_lock_trace() .... rcu_read_unlock_trace | Few instructions 2| ___________________________________________________________________________________________ Then when a tick fires, rcu_flavor_sched_clock_irq() discards the interrupted code as QS if the IP was within .text.rcu_no_qs _unless_ it is in the rcu_read_lock_trace. Both are easy and quick to verify. Also preempt_schedule_irq() would make sure to verify the same condition and enqueue the task as a GP blocker if preempting inside "Few instructions 1" or "Few instructions 2". And since RCU tasks already does a synchronize RCU before and after the scan, that's all we would have to do. Thanks. -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:48:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:48:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423088.1648377 (Exim 4.92) (envelope-from ) id 1x6p4J-0001j5-ND; Wed, 16 Sep 2026 12:48:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423088.1648377; Wed, 16 Sep 2026 12:48:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6p4J-0001iy-KE; Wed, 16 Sep 2026 12:48:55 +0000 Received: by outflank-mailman (input) for mailman id 1423088; Wed, 16 Sep 2026 12:48:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6p4H-0001is-9S for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:48:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6p4G-005ogO-9Y for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:48:52 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa902c-8faa-0a2a0a5109dd-0a2a4503d4e0-26 for ; Wed, 16 Sep 2026 14:48:52 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa9033-fae8-0a2a45030019-4a7de6ccfdb9-3 for ; Wed, 16 Sep 2026 14:48:52 +0200 Received: by mail-qk2-f12.google.com with SMTP id af79cd13be357-939922847efso81162385a.0 for ; Wed, 16 Sep 2026 05:48:51 -0700 (PDT) Received: from ziepe.ca (hlfxns010zw-159-2-239-150.pppoe-dynamic.high-speed.ns.bellaliant.net. [159.2.239.150]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93b7821dcfesm208481285a.18.2026.09.16.05.48.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2026 05:48:49 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1x6p4D-000000099Zm-0Jbp; Wed, 16 Sep 2026 09:48:49 -0300 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=ziepe.ca header.i="@ziepe.ca" header.h="In-Reply-To:Content-Disposition:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1789562930; x=1790167730; darn=lists.xenproject.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=VzaI7ZYbqdoJC4coFReri2t1Bm12kg0MhPi/KYFxqXI=; b=htTzrPHbafR3201eQGP32p7UZV2X8RGTqxt59+AZNvPmmlHpo6os5Wp+d/6pEpTeWy Pd5fh38FYupzyhnEh060Txd813N6XBOXXvwd4hgJ2uncqpJX8ymUnv7IAfm83YHhsIlV V+XdPDgfvspxTY1Nm8HA2bXx/+f4QwkkaoG5fzyoKMh9yakAThsVj8VE04WE7O3s4tZU ykzKL8gKUDmkSQXCb1BisQ63SOtXagWAJpk3qFADoB0U8gOqr47Uu0vNHcZxDiGDha2T 3ffYVC9livkXJxRVJdtmR4SX7VkchRLyWkqocFegomuBvhpYY8xwUntWhNf+Cs1XdXSf TUPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789562930; x=1790167730; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VzaI7ZYbqdoJC4coFReri2t1Bm12kg0MhPi/KYFxqXI=; b=tP/WbdyjZkHbMQ2op8WXNkp5/5cLub/dz482qNT92zf9ZSXHpUzrcb88zv/hUHcfK1 npSl1NXEM1GxDAUsA5YZRVuwq9blZVAYJeBIKTwHPw7I9rYoojRUXQ/sywtuOHxnd5tJ 8d7cERiF09mhH9hN8WpaV94sxPYiRb/XiuWKmI2Pryzk9JD4jt/aJ+oGTaRTAFysxpt9 MwPiqGk9IgfvS3nNlamN9EPg+fWFjCx1Lxvy+Dsj4vUPZeIjhd+Rm9hGokfVCWdtJI6o Xb2A9RK3JonneRzfThAxcDn58yAEzwMIIgJbyIXBvYWyy5GRf4yXk0/hZfb1BUrsape7 ru2A== X-Forwarded-Encrypted: i=1; AKwUvBwpGAvIsyB9M514Jmr5jOJAAH8SECRZscULpdJgXKnfbzhTyyZzZqxRBDlYtR3VlDMt6oe8lyhsHfQ=@lists.xenproject.org X-Gm-Message-State: AFuF++m3KpgyTJ9ep4pP2F50J9hDuuaQbWKHf2Im8apQQZdijN0MT/ZO R4ck+AlKA1hC8bV6snYgrVzr3daNS0IYeF1kHTJ1xo7FIM9PRHl2G7agtoqe5vT5pPA= X-Gm-Gg: AYBFou3OgQnM2RT2duYPYHgvE0KaQk6y3PsGhv+7nNyJCrHzHtCeGyNWTH2ErOdO+d5 wi8J0TC66VTi2AnURC+BaoL862/EklwoR4Eh+JWAgTe/niGCQFvW9rC1vfNalz7tFSj0sPUlnXx w7ny0DYzsa7LcNx9g0APJC46yTJZvVW549rx+G0Xyo8WQabOjmLCwdQipl5BvVtpTfnNw4WFXXx AzxuWYrkuzoXP7JHreC30q7RFsGgt0FbxuiPL7NsDjKy+A44rxwavzYB+ZwhRhJy48rPTGZ56ps mh3K5cjb8Bs7q0wE0obimOwnHDu/UzaKgXfA3Ere8cMJ+1pUk7MTfaniRZJ5lmNutdabGVA0TO/ UVE8EKarCrSFCkcSIcBBtpZ2Vf8vTbBaaa43zAIDoW1FH4nS4xzbySrlZUbmFY6YufDM7RW7CVK w4oBnUydZ+1bOn2sQiDVybejRiUZthnFYFBtQ2xV5upBQKV8n2xbuP8SpfYDvwsmE6WaHhQxO34 Hjp2tsm2uWGYj82mEJjfAq6SaQsGQ2ZX/jnebRftRhahyjE0KCRF2cXtA== X-Received: by 2002:a05:620a:d8e:b0:939:6de9:4cff with SMTP id af79cd13be357-93bb7907fecmr386232885a.45.1789562930363; Wed, 16 Sep 2026 05:48:50 -0700 (PDT) Date: Wed, 16 Sep 2026 09:48:49 -0300 From: Jason Gunthorpe To: Alexey Kardashevskiy Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Catalin Marinas , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , Liam Merwick , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Lu Baolu , Xu Yilun , Carlos =?utf-8?B?TMOzcGV6?= , Jonathan Cameron , Jori Koolstra , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , David Howells , Haavard Skinnemoen , Kenji Kaneshige , Ilpo =?utf-8?B?SsOkcnZpbmVu?= , Christian Marangi , Dave Jiang , Michael Kelley , Ilias Stamatis , Sumanth Korikkar , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , Palmer Dabbelt , linux-coco@lists.linux.dev, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, linux-mm@kvack.org, aik@ozlabs.ru, Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: Re: [RFC PATCH kernel 10/17] x86, dma: Allow accepted devices to map private memory Message-ID: <20260916124849.GD3196566@ziepe.ca> References: <20260916115159.1938195-1-aik@amd.com> <20260916115159.1938195-11-aik@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260916115159.1938195-11-aik@amd.com> X-purgate-ID: tlsNG-33051d/1789562932-6DAD44E9-E2005F67/0/0 X-purgate-type: clean X-purgate-size: 669 On Wed, Sep 16, 2026 at 09:51:50PM +1000, Alexey Kardashevskiy wrote: > bool force_dma_unencrypted(struct device *dev) > { > /* > - * For SEV, all DMA must be to unencrypted addresses. > + * Require unencrypted DMA unless the device has been "accepted", > + * enabled by a TSM driver to DMA to private encrypted memory. > */ > if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) > - return true; > + return !__device_cc_accepted(dev); I want this out of arch code, after Aneesh's recent rework Nicolin is trying this approach: https://lore.kernel.org/all/abddd433493324a6bfdf8ba9710e96d90f0d1ccc.1789010941.git.nicolinc@nvidia.com/ Jason From xen-devel-bounces@lists.xenproject.org Wed Sep 16 12:49:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 12:49:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423095.1648387 (Exim 4.92) (envelope-from ) id 1x6p5H-0002ou-4u; Wed, 16 Sep 2026 12:49:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423095.1648387; Wed, 16 Sep 2026 12:49:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6p5H-0002on-09; Wed, 16 Sep 2026 12:49:55 +0000 Received: by outflank-mailman (input) for mailman id 1423095; Wed, 16 Sep 2026 12:49:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6p5F-0002nI-Lf for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 12:49:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6p5F-002eo5-2V for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:49:53 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa905f-2eae-0a2a0a5409dd-0a2a4503ad00-42 for ; Wed, 16 Sep 2026 14:49:52 +0200 Received: from [52.101.43.69] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa906e-fae8-0a2a45030019-34652b458713-3 for ; Wed, 16 Sep 2026 14:49:52 +0200 Received: from MN0PR02CA0030.namprd02.prod.outlook.com (2603:10b6:208:530::20) by IA1PR12MB7663.namprd12.prod.outlook.com (2603:10b6:208:424::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 12:49:42 +0000 Received: from BN3PEPF0000B06A.namprd21.prod.outlook.com (2603:10b6:208:530:cafe::9b) by MN0PR02CA0030.outlook.office365.com (2603:10b6:208:530::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.406.12 via Frontend Transport; Wed, 16 Sep 2026 12:49:41 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF0000B06A.mail.protection.outlook.com (10.167.243.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.1 via Frontend Transport; Wed, 16 Sep 2026 12:49:41 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 07:49:40 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 07:49:40 -0500 Received: from [10.71.198.170] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Wed, 16 Sep 2026 07:49:38 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VoRFHW+6GXrySzh6X388L0L/BwMx5gXMo9xqH9ruvn+ZmqcKkuQDzH8QFI1tBq+I7pXkghEH1InJDysCEtC/5yzDZMEHK3xcU5NoRUYJOgS1WDIgTRIQkBzaPyjOs3OtsuO8GvWkuvATOSmkrNtnSy5wDc5KRuwUxwXpFMfe2i7K0OR+mR7Q416Q0G0gLcDIhVILGec8RBLWVLYKSQkyQU0dQkRwvt+x6CJp3lcSTAG02hYmr2ujzDMgymRc3EeMca4iJ4u6CMXzxnEhH8Bht/99fdrFpQakOfZJazAq4TocDLkT3xRcSwu86TvoicD8+Ov0Czu91PLI/7LgkbATfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p7rj08W+9s+ncwSiQ/vMxa2pDYFXixayHnpEoVjV+s8=; b=wyOS0MBX/upHjZa0DnR/Bl9rSLsGNwj7IQaPmFhaAR0f703aItXRn2+ZB1wxzmP93l4nRKgXbPLA/A52nFPDXIAjqk/Giqa3ih4Badf3jIb44+131LWXUemVPzzg3mgM/Ip08bm20M895mdg1IbiTnsONJBKmLS0my+ik0T3Gwnj9AwWzdcW4rxp2SCVCH+CsZ81O6nF5sUcQRuyRLeIb/QoCEOqSthY2VWUUXIGIQ0OzR/oA2dvqB3xJTAeHCggty3Macu98iCxI+tWLqB7eJdyHzQ/TXThE26mKzKhyNjTF2ubvD51mboDa2rfC7EVihupiTJkngT/hyjZ/mcNyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p7rj08W+9s+ncwSiQ/vMxa2pDYFXixayHnpEoVjV+s8=; b=4yevIhmpDaCSdCba9AHwzOYs8fbwQR/fEerL7XGxt/zcSW/NwNnYumOwHedYBgR49OfQNP33S5a/4gEsjFjFhmuv4JKx1LjEKYCuiPl6A7/LO3VRqHF0y6xQ/fqtgdMlFco6YHA050gqhLlrUF0J6rx+lm6o0vXuI3fWlW42xAU= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Wed, 16 Sep 2026 13:49:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 for 4.23] Add GIC SGI boot/self tests in Xen To: Julien Grall , Ayan Kumar Halder , CC: Stefano Stabellini , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , Roger Pau Monne , "Doug Goldstein" References: <20260529170956.49797-1-ayan.kumar.halder@amd.com> <20260828102933.2853627-1-ayan.kumar.halder@amd.com> <7d6ffbc7-83e7-4254-9cc2-f2a7113088ab@xen.org> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <7d6ffbc7-83e7-4254-9cc2-f2a7113088ab@xen.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06A:EE_|IA1PR12MB7663:EE_ X-MS-Office365-Filtering-Correlation-Id: 1cc6fe51-e725-4d5e-194a-08df13f0fa09 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|36860700016|82310400026|23010399003|1800799024|56012099006|11063799006|4143699003|6133799003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 2x+U8YY9nqqPJ48XvQ/KkYwJn0T/Q2Mq3vZJ9Ucy6WKFKYAK6nIpxh4nGcgyJgEo8PzNNpgvGO7jjlrFFkYicg/KnDMuut4GUXGea4MXEcwqeVCf7s3LFkA+A01ejNNNENlk9eWU9C9ak2PICm1iKbvSsfkrXVhVXU14u2vGLNJbixNkIIvKY5OQKjXDnZqMFPJRHlD9VlDzsMxIjX700oz93vEG1uhSU2WkszMZPgz9j24I/yQgpr0WC1ixTAy49GcoubA7yyHXVfnrxLCjL1a8XCK5R7j61ETlnsnaa0i2vkPt5IWKVu8HWhpWBbTrXJ8fgdOJBlmIQ4CZWTBNf7UKhoFE4b8mWGqXLaSWjIbfrrbbXBDm64mNzKAoT7Qaguvk7Nnd2I7YhW9sp0QEE4nrQWdiWBff5ZxBdVP5X4puDaFZGPp4gAslqIr0OrCTf/N4kosMTlKWDsoB3UZyA78GgVHNbgApV4e0MlnQ+s1PFOT5Fe5Hz7pO/86K8CogXOaVtfdGGvfAC6yrJFtJ9ZQthC7kkqZMwIrlR6ltA/iKgNaZfZhB1uInIgWQUYNC//WNDr5Uu/OghTm/gT2k+PcsjAPn0f+SbuKPpK4uctCrAr7oCTQ2PiYslY7Cy9LLvQpxmqYhz5x9Xknc03ytdDIQdlobzGiHmpaH2xbPAErqMTKaZFrC3HUCKktKGIVnH19MHWz2WX0Nu0+tnZlHKA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(36860700016)(82310400026)(23010399003)(1800799024)(56012099006)(11063799006)(4143699003)(6133799003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: tVch2RuI8a78GdlOWOMWD+EiKpQfo7LPRmX7Cej1bDgk9j2CSloPiNPJxwt4KXQ4qKL38WdRj5snniSJ4/hr7wSJ9Ar4Lpi46zToL3riRCc2YQA0TLfkw2PC7P7J7IxBC22Fb7kShGpONId8bMcw6bLmhvE81gfeHlLF4+jjozDHdkBYnPnjwFJVtvjVOVXOxCPI2ZVi9PVzmJyvGQYTduU4QRS5i30XJtfiwZo3WeTKPstPdzLjAU/8m86QtyOTG9kxH/ltgdwsUu93ifIGlugmsG/ISE2ZZjkTKlyOhc5q95FdxAb/IRur7/rhefvfMpxfZg1q94QDptCpuaC9uL/9L3msAwkMdNwAMQ4mZVPDCGnI8E0qpcBLof2ODF17E9Suj5qoJoyuQIYlXtGFupR8xvN8sQL7A8K8H8KpowemII4TYFzE1PqJWhOCetBI X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 12:49:41.7434 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1cc6fe51-e725-4d5e-194a-08df13f0fa09 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B06A.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7663 X-purgate-ID: tlsNG-33051d/1789562992-6F2C84E9-C74597F1/0/0 X-purgate-type: clean X-purgate-size: 6500 On 04/09/2026 20:21, Julien Grall wrote: > Hi Ayan, Hi Julien, > > It is usually preferred to send a new version in its own thread rather > than in-reply-to an existing version. Apologies, this was my mistake (bad git send command). > > On 28/08/2026 12:29, Ayan Kumar Halder wrote: >> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile >> index b7afd3e58c..71f177824b 100644 >> --- a/xen/arch/arm/Makefile >> +++ b/xen/arch/arm/Makefile >> @@ -24,6 +24,7 @@ obj-y += domctl.o >>   obj-$(CONFIG_EARLY_PRINTK) += early_printk.o >>   obj-y += efi/ >>   obj-y += gic.o >> +obj-$(CONFIG_BOOT_SELFTEST) += gic-test.o >>   obj-$(CONFIG_GICV2) += gic-v2.o >>   obj-$(CONFIG_GICV3) += gic-v3.o >>   obj-$(CONFIG_HAS_ITS) += gic-v3-its.o >> diff --git a/xen/arch/arm/gic-test.c b/xen/arch/arm/gic-test.c >> new file mode 100644 >> index 0000000000..9ddd47cad2 >> --- /dev/null >> +++ b/xen/arch/arm/gic-test.c >> @@ -0,0 +1,102 @@ >> +/* SPDX-License-Identifier: GPL-2.0-or-later */ > > The preferred license for Xen is GPLv2-only (see COPYING). Can you > confirm the use of GPL2+ is intended? fixed > >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +static bool __initdata opt_gic_test; >> +boolean_param("gic-test", opt_gic_test); >> + >> +static DEFINE_PER_CPU(unsigned int, sgi_test_count); >> + >> +void gic_sgi_test_interrupt(void) >> +{ >> +    this_cpu(sgi_test_count)++; > > In sgi_count(), you are using ACCESS_ONCE() to read the content of the > variable, but I am not entirely sure this_cpu(...)++ is guarantee to > be a single write. > > As this happen on different CPU, don't we also need to use > ACCESS_ONCE() here too ACCESS_ONCE(this_cpu(sgi_test_count))++; >  or atomically increment? > > [...] > >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c >> index 078049e741..6a132c64e1 100644 >> --- a/xen/arch/arm/gic.c >> +++ b/xen/arch/arm/gic.c >> @@ -330,6 +330,11 @@ static void do_static_sgi(struct cpu_user_regs >> *regs, enum gic_sgi sgi) >>       case GIC_SGI_CALL_FUNCTION: >>           smp_call_function_interrupt(); >>           break; >> +#ifdef CONFIG_BOOT_SELFTEST >> +    case GIC_SGI_TEST: >> +        gic_sgi_test_interrupt(); >> +        break; >> +#endif >>       default: >>           panic("Unhandled SGI %d on CPU%d\n", sgi, smp_processor_id()); >>           break; >> diff --git a/xen/arch/arm/include/asm/gic.h >> b/xen/arch/arm/include/asm/gic.h >> index ee2c26adb4..40635a9d32 100644 >> --- a/xen/arch/arm/include/asm/gic.h >> +++ b/xen/arch/arm/include/asm/gic.h >> @@ -306,6 +306,9 @@ enum gic_sgi { >>       GIC_SGI_EVENT_CHECK, >>       GIC_SGI_DUMP_STATE, >>       GIC_SGI_CALL_FUNCTION, >> +#ifdef CONFIG_BOOT_SELFTEST >> +    GIC_SGI_TEST, >> +#endif >>       GIC_SGI_STATIC_MAX, >>   }; >>   @@ -321,6 +324,11 @@ extern void send_SGI_one(unsigned int cpu, >> enum gic_sgi sgi); >>   extern void send_SGI_self(enum gic_sgi sgi); >>   extern void send_SGI_allbutself(enum gic_sgi sgi); >>   +#ifdef CONFIG_BOOT_SELFTEST >> +/* Record a GIC_SGI_TEST delivered to this CPU (see >> arch/arm/gic-test.c). */ > > I would suggest to remove (see ...). One can easily find > gic_sgi_test_interrupt() and this reduces the risk of stale file name. > >> +void gic_sgi_test_interrupt(void); >> +#endif >> + >>   /* print useful debug info */ >>   extern void gic_dump_info(struct vcpu *v); >>   extern void gic_dump_vgic_info(struct vcpu *v); >> diff --git a/xen/arch/arm/include/asm/setup.h >> b/xen/arch/arm/include/asm/setup.h >> index 0adfa4993a..2fdf5da526 100644 >> --- a/xen/arch/arm/include/asm/setup.h >> +++ b/xen/arch/arm/include/asm/setup.h >> @@ -50,6 +50,15 @@ void setup_mm(void); >>   extern uint32_t hyp_traps_vector[]; >>   void init_traps(void); >>   +#ifdef CONFIG_BOOT_SELFTEST >> +#define __initcallboottest(fn) \ >> +    static const initcall_t __initcall_##fn __init_call("boottest") >> = (fn) >> + >> +void do_init_boottests(void); >> +#else >> +static inline void do_init_boottests(void) {} >> +#endif >> + >>   int handle_device(struct domain *d, struct dt_device_node *dev, >> p2m_type_t p2mt, >>                     struct rangeset *iomem_ranges, struct rangeset >> *irq_ranges); >>   diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c >> index 6310a47d68..c7abbdb04e 100644 >> --- a/xen/arch/arm/setup.c >> +++ b/xen/arch/arm/setup.c >> @@ -83,6 +83,24 @@ static void __init init_idle_domain(void) >>       /* TODO: setup_idle_pagetable(); */ >>   } >>   +#ifdef CONFIG_BOOT_SELFTEST >> +extern const initcall_t __initcall_boot_test_start[], >> +    __initcall_boot_test_end[]; >> + >> +void do_init_boottests(void) >> +{ >> +    const initcall_t *call; >> + >> +    printk("CPU%u: boot self-tests start\n", smp_processor_id()); >> + >> +    for ( call = __initcall_boot_test_start; call < >> __initcall_boot_test_end; >> +          call++ ) >> +        (*call)(); >> + >> +    printk("CPU%u: boot self-tests done\n", smp_processor_id()); >> +} >> +#endif /* CONFIG_BOOT_SELFTEST */ >> + >>   static const char * __initdata processor_implementers[] = { >>       ['A'] = "ARM Limited", >>       ['B'] = "Broadcom Corporation", >> @@ -470,6 +488,8 @@ void asmlinkage __init noreturn >> start_xen(unsigned long fdt_paddr) >>       enable_errata_workarounds(); >>       enable_cpu_features(); >>   +    do_init_boottests(); >> + >>       /* Create initial domain 0. */ >>       if ( !is_dom0less_mode() ) >>           create_dom0(); >> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c >> index 1806c47a08..97d8b19cf4 100644 >> --- a/xen/arch/arm/smpboot.c >> +++ b/xen/arch/arm/smpboot.c >> @@ -28,6 +28,7 @@ >>   #include >>   #include >>   #include >> +#include > > Style: I think this wants to go after asm/tee/tee.h (acpi.h seems to > be misplaced). fixed. - Ayan From xen-devel-bounces@lists.xenproject.org Wed Sep 16 13:02:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 13:02:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423116.1648395 (Exim 4.92) (envelope-from ) id 1x6pHF-0007sH-4r; Wed, 16 Sep 2026 13:02:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423116.1648395; Wed, 16 Sep 2026 13:02:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6pHF-0007sA-1x; Wed, 16 Sep 2026 13:02:17 +0000 Received: by outflank-mailman (input) for mailman id 1423116; Wed, 16 Sep 2026 13:02:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6pHD-0007rn-S4 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:02:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6pHD-00Fe1R-7E for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 15:02:15 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa9355-bab6-0a2a0a5309dd-0a2a4505b124-10 for ; Wed, 16 Sep 2026 15:02:15 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa9356-4cb1-0a2a45050019-4a7de18cfe9b-3 for ; Wed, 16 Sep 2026 15:02:15 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49e66390995so5366535e9.2 for ; Wed, 16 Sep 2026 06:02:15 -0700 (PDT) Received: from [10.72.3.60] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e83da071asm95694245e9.8.2026.09.16.06.02.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2026 06:02:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789563734; x=1790168534; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=vvV6WREj3Mr2sX4jitYZb1MyPJGMZ+/fVuQpQQtUfV0=; b=Y+v6xvUKFwP4Tt1ZaJN7/WihFKnNOlHejXzjfLtF7Mqh0aaqT7L55m0uckTjJeX65c jDyNd3+t9jMiaogpwADO8S0SWcPArirQI+b5H+RXUwWj/om6swDaAGLFWSGz2EUohPSk 1juSVm9G6G18tyW6VYx3DUgNp1WHgM3a/2PDujyHqiSwIsNeVz04z6gPlxB242mBm6dO Mp6lh2qfUZqCXuOJw45xEB7vQ/F5WeMuynK809gTs1gzMZzOMgJDb/U04O2NUpoZ+8yJ yBTvJZWXy1a9s/rQu/NY3y+7k8MMBJM/ca6pj4fF+xvNxaQsaYzuhNOd0+DUb2j0/4io k0uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789563734; x=1790168534; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=vvV6WREj3Mr2sX4jitYZb1MyPJGMZ+/fVuQpQQtUfV0=; b=W0FKMemPRCva1e4cSC/oHZYYsOfRmAYXNjR7V4Qd3KXCh9o2pTNcixRq024X6tPCg5 9jvHrVcXLeEt1HwKRyy9bpmvPW86VTjVab8i1qwGiKv9M0Pl7hezbNUsaBqYG+ulJgKj JCJY6zaUhiHyA70BVnxCzjxpirV2omI38b+npcnM5XBsqFtiCl6SyYEzLlydKlkjY38t 9GpwkfybBQ+nJoNcmVzzBtxMZ7BaHymY9+Fa2JXVT3d7utxm9Iidg2zyDDvxPnyrkIge gdMjzdJlLRDyhAXZTYfU6IRLU6g47Ong57r92hf9HTwKkpq1p1FZp387MDR4jDmpmXse stpQ== X-Forwarded-Encrypted: i=1; AKwUvBxChVfUJd7j0smkEzMXz/djCyCEcHYvxxSr4FOOoa+LUxYXeOKSMqJt7sL+SQkEV2fjZLqBHN8KUwU=@lists.xenproject.org X-Gm-Message-State: AFuF++kP4WV+X6qIAxE1iQMa6sqbnmWN0Ld9/4zbJ4+yQ7XZvwUh8rTc SlAQqVARaxLw5dRV5IEV0ZCrg1PBBQxqCrynG9MvhdtMEJTh8gHPxiZBNGB+VaC32Q== X-Gm-Gg: AYBFou0R7C6W+I6uL6Axs4N2iRpugixHJkRfjiHBVp+Ir+P5HoLeBc6I5WNxfux68Cf TbAfrWl6l4NzoRnQyjL3PBTJE1F8bHaHmysUm1BQjRMFsgnPcTjR2/ESeoVSHuG4rvGa5I4fy8Q 40OWNzWBa5DwGHQ85ryuffQAHOYEB9xfQVd9QxasIb7WuDhJMMxtc84b8VVfS2/W+81CelqCNFR +rIjafi5HMViJGrHECMaWpqMuArZ03qg03Oq1RKZKKBVoCS/3kDj663Bg6VkswQPmVMQwNLWcyw XubR49au58hYM+TAVdCywkGgrNJ2tdk9NKCixgjcSpIhWSUUYAculkhP/SeDk/i1SC0oqXYX+B5 QaIB1Gz0lsBM+HoMTbtNvdredr71yxp/YV8Z5mBCuarqAWP1bHjb+DXUAs0XM6JhNwqTUaEOUt/ GIm9JOFbM/c49L34mRgV6+61r39tEv1kA6RHsLsp8pGuyEiQ+gFQPfDdTeM8basSXfm/GrKHXeS A== X-Received: by 2002:a05:600c:5486:b0:49d:1d7e:4085 with SMTP id 5b1f17b1804b1-49eb732347fmr29712515e9.22.1789563734516; Wed, 16 Sep 2026 06:02:14 -0700 (PDT) Message-ID: <52c8ca00-423a-4c91-a60d-a1662d20a012@suse.com> Date: Wed, 16 Sep 2026 15:02:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789563735-F78BE2A1-29695A2B/0/0 X-purgate-type: clean X-purgate-size: 1762 On 16.09.2026 07:55, Oleksii Kurochko wrote: > On 9/14/26 2:12 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/imsic.c >>> +++ b/xen/arch/riscv/imsic.c >>> @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, >>> >>> void imsic_migrate_vcpu(struct vcpu *v) >>> { >>> + /* >>> + * The scheduler can mark a freshly created vCPU's unit as migrated and >>> + * invoke this before the vCPU has ever run (see the migrated branch in >>> + * schedule()). No need to do migration for such vCPUs as they aren't fully >>> + * initialized (for example, context_switch() will be called after >>> + * imsic_migrate_vcpu()). >>> + */ >>> + if ( v->arch.last_cpu == NR_CPUS ) >> >> May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a >> good sentinel. If we/you decided to switch to ~0, >= here would continue to >> be correct. > > I agree with >= but I am not quite sure that I fully understand what is > wrong with NR_CPUS. We have for example the following: > > static inline unsigned int smp_processor_id(void) > { > unsigned int id = tp->processor_id; > > BUG_ON(id >= NR_CPUS); > > return id; > } > > So it is guaranteed that NR_CPUS what be used as cpu id and so it still > could be considered as a good sentinel. Arbitrary numbers can be problematic when used as a sentinel. If you look at disassembly, you may not recognize that number as a sentinel. Further there's also a code-gen concern: ~0, aiui, will always generate the same code (to e.g. load into a register). NR_CPUS, depending on .config, may not. The value may not be loadable by a single insn. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 16 13:06:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 13:06:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423127.1648404 (Exim 4.92) (envelope-from ) id 1x6pLM-0000MD-Lp; Wed, 16 Sep 2026 13:06:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423127.1648404; Wed, 16 Sep 2026 13:06:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6pLM-0000M6-Io; Wed, 16 Sep 2026 13:06:32 +0000 Received: by outflank-mailman (input) for mailman id 1423127; Wed, 16 Sep 2026 13:06:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6pLL-0000Kk-Kg for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:06:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6pLK-00AQpY-TJ for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 15:06:30 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa9451-2eae-0a2a0a5409dd-0a2a4503b7e4-20 for ; Wed, 16 Sep 2026 15:06:30 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa9456-fae8-0a2a45030019-4a7de18dec56-3 for ; Wed, 16 Sep 2026 15:06:30 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49cd38e0f79so4999805e9.3 for ; Wed, 16 Sep 2026 06:06:30 -0700 (PDT) Received: from [10.72.3.60] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e847da0cdsm40245e9.2.2026.09.16.06.06.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2026 06:06:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789563990; x=1790168790; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mun2AV+TlG924D+xyrsyfLJbFNsClESosmH8/Nj3Ijs=; b=R9cXsxL+kyLX3SruWooKrgrKo4M/afknKCg7HCYNZhQwv1enPYN8mNJ/KEb9fJGrNy i/Lt8scESbkHOciUvGnxfI4ilGbhTd/8v1IbcnmByGV2TU3rt/9irvYkG2LFDf7zIGwE 8BPMXz/VOKfJsubHMbkN0qsHhSqrzuOOQqT4G9j98GreDBLIN28l+DfbHitv7Nmqwoy0 Rl3sO6uM8UFY5U/30dXMyBNgzqcoC9fNYRE7w0fhk3VtlipmI+b5mNm2tRh5k350ZyLa 71CIN3Uc0dK6X3nFf7HvC+0Ic8QJAQpIVRY2kqQ30BEG0stzP8aGYZeelHkLuKkkyryO QEmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789563990; x=1790168790; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=mun2AV+TlG924D+xyrsyfLJbFNsClESosmH8/Nj3Ijs=; b=XxUWI2UngUbYITISf8xvEU1UuuNEHF83+127D3qj8WKtZXPofpWz3icJZKA7dfAmVz E/yfgTiB5Lf4vBDkK9h04QqcgUD+9FKNpfjVZP9lvcK+44yU7bDGZl7iQmu1J2wFcvi9 R2y16QLVpjHsY7kGKDBO1Hzk+tyMJERNiI6zo/CqHfZV1gY+vCHtZy4d2Uw1FubmO13Z /g4IoGgp4Duo/FvY+cLXHDvomxRNcFuqOYywdmei8fXcdIXTSbF7FDlanbxqTQdgp5wB x24DwuRqa6nHuNF3iFUV8ckUBoVr1eb0/1YZHHlNpa1KTMYG6dfxdRhX+/j95e1xAZgL oXGw== X-Forwarded-Encrypted: i=1; AKwUvBxhamOVQg2NuDeqD39h+Wvctrg1wfXQ5VI4Pge8FNMzwGiSF2rRHlrPc3YZn+7YhJTbj3ToK8PsbFQ=@lists.xenproject.org X-Gm-Message-State: AFuF++nLkfjdbTlovNjtWrgTme/uSOL3DIuUlg4J2A/nn9jGf3XwP0N1 E7tKGxB0EwmNw+iDc65Ij7vl1femruCT9VnoZ4fFT0WoD3wSQ2zS78rwXg0ZGvsnbQ== X-Gm-Gg: AYBFou3cXdoAiWj5+gmdAiRw8c5kxPwtgLgPtNF/D6VUsmCbKBL/0Cn1uIw6iSv/+jL r7lwPHNzdTg5dDbpSUQKYrEQUz21GpF/U23C+Um7xHnkOCDM/M+Inhk2JedCXQl8z79vbxtYqIu wCAGP43SqBq3MB1rhp6QE7FqobWSkC5pzxSJY4/vPYvehIoHmUFnhzLSAYRjnujhGA2jM1fFSUI fLU9u/bhHNt9bkdZeM2ob012cTKfCZuQKPVOzim4Dqd2HnI5mU9wZ/8q47e9huynftUneHkqY95 cSSshjB6y+bl32E5tmwEp9+xAwpvK7NwGCS4RhMdybPveSbhpVURH+Uy8qh8cqaTRJJsoWpKKIJ pLl6yLHXptj97+pk/azVKbeTltlvFhXPaoB9hSgsrK/WxoB0Up+7B4eRQ9siBfqGSIiiQskV/zc TxTE3BFLkyu7K6GVSoXQjBOl4xZCCjzHAWnn65fjtNSZxE0fRtwwwhS/riEDGBvwpyAd94P4wn1 Q== X-Received: by 2002:a05:600c:620d:b0:49e:6692:27fd with SMTP id 5b1f17b1804b1-49eac46430amr65034215e9.2.1789563990267; Wed, 16 Sep 2026 06:06:30 -0700 (PDT) Message-ID: <839b00ad-038b-41d4-86a8-24f85e01ca74@suse.com> Date: Wed, 16 Sep 2026 15:06:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/7] x86: extend update_intpte() to support atomic get-and-update To: Kevin Lampis Cc: "teddy.astie@vates.tech" , "xen-devel@lists.xenproject.org" , Andrew Cooper References: <20260910203113.462943-1-kevin.lampis@citrix.com> <20260910203113.462943-4-kevin.lampis@citrix.com> <0aedfbad-29ae-4083-89b4-5c662398553d@citrix.com> <2516df18-b239-4bf8-9f89-f1811515e5d8@suse.com> Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789563990-6DAD44E9-E58F16F5/0/0 X-purgate-type: clean X-purgate-size: 1088 On 16.09.2026 10:23, Kevin Lampis wrote: >> The "flag set, pointer non-NULL" case wouldn't hit the "return 0" path > > Correct. > > But what about the "flag not set" case. When PTE_UPDATE_SWAP is not set then > UPDATE_ENTRY may return 0. > > If UPDATE_ENTRY() returns 0 then mod_l1_entry() will give > the wrong ol1e value to put_page_from_l1e(). > > static int mod_l1_entry( ... ) > { > ... > ol1e = UPDATE_ENTRY(l1, pl1e, ol1e, ...); > ... > put_page_from_l1e(ol1e, pt_dom); > ... > } > > I think mod_l1_entry may need to store a copy of ol1e incase UPDATE_ENTRY() > returns 0. Or add some extra if/else around every call to UPDATE_ENTRY() to > only assign ol1e if we know we're on the new PTE_UPDATE_SWAP path. Possibly, yes. Or even have a separate helper for the SWAP case. What may be possible with the returning of 0 is ol1e = UPDATE_ENTRY(l1, pl1e, ol1e, ...) ?: ol1e; when the return value is relevant in both cases. Question is: Is it, in the first place when SWAP isn't set? Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 16 13:08:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 13:08:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423136.1648414 (Exim 4.92) (envelope-from ) id 1x6pNJ-0001KU-6q; Wed, 16 Sep 2026 13:08:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423136.1648414; Wed, 16 Sep 2026 13:08:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6pNJ-0001KN-2Z; Wed, 16 Sep 2026 13:08:33 +0000 Received: by outflank-mailman (input) for mailman id 1423136; Wed, 16 Sep 2026 13:08:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6pNH-0001KH-27 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:08:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6pNG-00AR7Y-Dm for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 15:08:30 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa94c1-bab6-0a2a0a5309dd-0a2a4501b174-34 for ; Wed, 16 Sep 2026 15:08:29 +0200 Received: from [52.101.201.53] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa94cc-5984-0a2a45010019-3465c935a79a-3 for ; Wed, 16 Sep 2026 15:08:29 +0200 Received: from DS7PR06CA0021.namprd06.prod.outlook.com (2603:10b6:8:2a::23) by LV2PR12MB5869.namprd12.prod.outlook.com (2603:10b6:408:176::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.11; Wed, 16 Sep 2026 13:08:18 +0000 Received: from DS3PEPF0000C381.namprd04.prod.outlook.com (2603:10b6:8:2a:cafe::8a) by DS7PR06CA0021.outlook.office365.com (2603:10b6:8:2a::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 13:08:18 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF0000C381.mail.protection.outlook.com (10.167.23.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 13:08:17 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 08:08:17 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Wed, 16 Sep 2026 08:08:14 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vaiijM8eKvTGBraPrgU2Lx68hFeUixrk3Llell3nGa07F/+gcURJGay7PqavDIMZ7PqVMBBLPGUWmDkMiaJ3iolMIB2BUFc0lmnDggZxRRncLxRwMiGnRMq+XezDodRhhGjUYL4AWqNEjxcXuoTPOsWcsn3KrJmjRA9xlRrNe/VSKt9QoKlWQtmp3qvl2OnBqlZKL3WSh7mnsBLMykkQXn4+yuk2DGHpfbqtGcHs3gxUDtEcLvx1qk8AOpjW4x13TttzgJ5+yW44rM0gkvTPkqhVajdqxiMNefZkLZUDcivjgHmKbuW/uvJWLBXJ7GjxS1BDRlPCojGM9G0cNks8CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ulvMdc2h4+5GzScz2sdRv3zUV+Rn3U3Mje1rhe4SjyY=; b=InjHiuwYnyVKV5NtBXnjar1ACFhR/f5N06r8e7+qnsfNrHh7gninAycEK6mMLjqhQCMkV3MX819+7BUezHmuQdEEXT4bY+oQZ1k6npgFltQSlARow9to/y+2GltVh8u8QSd9L4DJG0cCQsxrSH5jvdtnh0GFHQU70oQnG78A8YA6/na3+rk651oejBNQmxKa8zAmJD/ALZbQxObHflg9wAgVT9hl9BtchE0+cqPTfiEoyCMBhk5IO6heIsnOBAAx8iumb92dqF5Vim2pYypjahr0DjzhRWnD1fgmuie6uFCPD2UrpGN/qPYQ+3BKWIDMEvmlLAN7Cg4HiZG+ct2DAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ulvMdc2h4+5GzScz2sdRv3zUV+Rn3U3Mje1rhe4SjyY=; b=RviIIriqlucy+rHO/x7zsmykN7AXiYi3sdNbbmrKJzcxVyA9Uwny260CwnfrqoAg5iU5XblGqMz89pp71Rcb41bX13UOtdu3g52j/wksI84pYj+SgZ/yB3nRi5Xt9zC/Dz/DygPr0j6/9J/PwwSKGFkbzzRBJODYl0+xkBgdCFw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <3c3c203d-7951-4340-a926-67b92224d531@amd.com> Date: Wed, 16 Sep 2026 15:08:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 3/6] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE To: Julian Vetter , CC: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130863.8631fc262581453bbf619ec5b2062170.1a090827272000c4f3@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1789130863.8631fc262581453bbf619ec5b2062170.1a090827272000c4f3@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF0000C381:EE_|LV2PR12MB5869:EE_ X-MS-Office365-Filtering-Correlation-Id: 875b8efe-7384-42bc-bd8b-08df13f3935d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|7416014|82310400026|36860700016|22082099003|6133799003|10067099003|4143699003|11063799006|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: lUQ2Gpb38eHECXZvdr8na5eNOdcNB/lhqsaDb4knVKwJSOdcEpmWk5EFeMBKkDl/A/s5svGU/ekdSJIvJHB6jseAlVffytUaPF6mHJ1GsexHRBRI9/9s9J32tNY7rDJBkJP1Dgh+UsfcBlDw7xfQdfbJL4Vgh6An/I2xQrugSDmD0xIXE0hYBotxgo5A+f+3F7FdgoJsSFG2cTMNprKxihMpc4gTqL+1ZHreMiBhfnrw0t1u5AB8oF1izTT5dgtkZZaNTNuVBADhYAXGHV6s+1SlzW8LOcd5XABYgaAIDk/1WzHNFohQ6S3PwkNdz4DSqqMak5EV2zvpJgL/FpHpitvV7u5awZvSXpurtaJuCYLj4GmoE0ybzFf2UKH8nLTRe1s35vm4Rm+WFC17Nni2sgji9ng3Q1x+AMK5XX57CTCC931im634n5LCFCvdWxfQkU6n8CAGAtJySRZlPiv4fNSp1eOaZqnu0DoPeVG+rxzb/m2jT0GxrjzJNebC6UEhqU5UT6E4KHtzooINa35ceRPcPVfXPImyfW8CjM+BlhMEGZ/fK5XG7Ca2NFJ6TMXX2sAh6/gHuJm3RuipShz7AXh/bvDslxfbc/w0WuWDNXqRGT7WiY5DaniPh/tIb11UG5LGDjDbyJ7x/Pt7Zgc+248KpXG0uuwx3zrG65mxfcQ8D/LGHCpBPByKkIec0K/a/r9jKtkRI6hdQ5YIRK6BmA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(7416014)(82310400026)(36860700016)(22082099003)(6133799003)(10067099003)(4143699003)(11063799006)(56012099006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: P0U7wodbilj/LWoHVETy0VqYUmOj3H7zWKygKmV3Si2T0s1kjUGpzv4W3AgkDD6MH65sreBFof/RNQzyQ0ZgeCxNgoTq9MGy7qHHO5QfadElfy1ct408vKdfEb4fOL8P3a9ohwWrUlrAnwcTZ0IQ8nxjc+5UhkgHFc+CRb8iCkGAystVQNxvGFwoheYjeOfJm7GdEyltOewjRidcvPv5N53wjTkxuXMDAe8E/cTaqTwxQwas4iQWBi6p1x5wC3WypJ0vhkLO86VkPTLxN96hxPqm9pwVgAwO6ICReCjXCWtcN0piLAA6bLEaGE9ZuJD2km25a+WTgkJK0RzOE4HdHWeDTFkO5UE4jsUIxxIfpBAL53ndrz6Fw/wqhAhXfvrIQpO/EY60tulruqsUzO+/29/XYyMREioyNT1SO13GVDmIVxjN0ZnOJwv9sf014uLH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 13:08:17.9663 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 875b8efe-7384-42bc-bd8b-08df13f3935d X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF0000C381.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5869 X-purgate-ID: tlsNG-d62444/1789564109-1FA6E757-AE5005E1/0/0 X-purgate-type: clean X-purgate-size: 6665 On 11-Sep-26 14:47, Julian Vetter wrote: > XEN_DOMCTL_CONFIG_GIC_NATIVE lets the toolstack ask Xen to silently > resolve the domain's GIC version to whatever the host hardware has. Xen > then writes the resolved value back into the same in/out > xen_arch_domainconfig the toolstack used as input, which is the kind of > API abuse we're trying to get rid of. The struct passed to createdomain > should only be an input parameter. > > Move the "pick the best available GIC version" decision to the > toolstack, using the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 capability bits > already exposed via XEN_SYSCTL_physinfo: > > * libxl__arch_domain_build_info_setdefault() resolves the GIC version > against those bits before the config is built. An unspecified version > becomes v3 if available, else v2, else fails. An explicitly requested > v2/v3 is validated against the same bits, so a version the host > cannot provide is directly rejected in the toolstack. > * The Python xc.domain_create() binding does the same via a call to > xc_physinfo(). > * libxl__arch_domain_prepare_config() therefore only ever sees a > concrete v2/v3 request and just validates it. The GIC_NATIVE case is > dropped since setdefault() always resolves it first. > > The LIBXL_GIC_VERSION enum value 0 is renamed from DEFAULT to NONE to > reflect that it now only means "the user did not pick a version". > setdefault() resolves it before anything else can observe it, so there > is no longer a "default" left in the config. The xl.cfg(5) gic_version > documentation is updated to match. > > This guarantees no toolstack path can still produce > XEN_DOMCTL_CONFIG_GIC_NATIVE, in preparation for removing it from the > Xen side and from the ABI entirely. > > Signed-off-by: Julian Vetter > --- > Changes in v5: > - Go back to the initial per-version arch_capabilities_arm_gic_{v2,v3}() > helpers instead of a generic arch_capabilities_arm_has(caps, mask) > - Validate an explicitly requested GIC version against the host > capabilities, not just resolve an unspecified one > - Rename LIBXL_GIC_VERSION_DEFAULT to LIBXL_GIC_VERSION_NONE This one is on me. I just realized that libxl compares user provided string with the IDL types, so a xl.cfg file specifying "default" would fail now. This would be wrong given that libxl API is stable. Let's keep the DEFAULT as it was (for NONE you would also need to change the golang bindings). With that changed: Acked-by: Michal Orzel You will still need Rb from Anthony as toolstack maintainer. > - Document the change in xl.cfg(5) > --- > docs/man/xl.cfg.5.pod.in | 9 ++-- > .../include/xen-tools/arm-arch-capabilities.h | 21 +++++++++ > tools/libs/light/libxl_arm.c | 45 +++++++++++++++++-- > tools/libs/light/libxl_types.idl | 4 +- > tools/python/xen/lowlevel/xc/xc.c | 18 +++++++- > 5 files changed, 87 insertions(+), 10 deletions(-) > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index d34951edb9..6a5e75eeab 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -3081,15 +3081,16 @@ Emulate a GICv2 > Emulate a GICv3. Note that the emulated GIC does not support the > GICv2 compatibility mode. > > -=item B > +=item B > > -Emulate the same version as the native GIC hardware used by the host where > -the domain was created. > +Let the toolstack choose the GIC version: GICv3 if the host supports it, > +otherwise GICv2. This is the default when C is not specified. > > =back > > This requires hardware compatibility with the requested version, either > -natively or via hardware backwards compatibility support. > +natively or via hardware backwards compatibility support. The GIC versions > +the host can emulate for a guest are reported via C. > > =item B > > diff --git a/tools/include/xen-tools/arm-arch-capabilities.h b/tools/include/xen-tools/arm-arch-capabilities.h > index 4aa4c6c34a..21e3c73bd1 100644 > --- a/tools/include/xen-tools/arm-arch-capabilities.h > +++ b/tools/include/xen-tools/arm-arch-capabilities.h > @@ -6,6 +6,7 @@ > #ifndef ARM_ARCH_CAPABILITIES_H > #define ARM_ARCH_CAPABILITIES_H > > +#include > #include > #include > > @@ -25,4 +26,24 @@ unsigned int arch_capabilities_arm_sve(unsigned int arch_capabilities) > #endif > } > > +static inline > +bool arch_capabilities_arm_gic_v2(unsigned int arch_capabilities) > +{ > +#if defined(__arm__) || defined(__aarch64__) > + return MASK_EXTR(arch_capabilities, XEN_SYSCTL_PHYSCAP_ARM_GIC_V2); > +#else > + return false; > +#endif > +} > + > +static inline > +bool arch_capabilities_arm_gic_v3(unsigned int arch_capabilities) > +{ > +#if defined(__arm__) || defined(__aarch64__) > + return MASK_EXTR(arch_capabilities, XEN_SYSCTL_PHYSCAP_ARM_GIC_V3); > +#else > + return false; > +#endif > +} > + > #endif /* ARM_ARCH_CAPABILITIES_H */ > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c > index 7e9f8a1bc3..283cfb749b 100644 > --- a/tools/libs/light/libxl_arm.c > +++ b/tools/libs/light/libxl_arm.c > @@ -196,9 +196,6 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, > LOG(DEBUG, " - Allocate %u SPIs", config->arch.nr_spis); > > switch (d_config->b_info.arch_arm.gic_version) { > - case LIBXL_GIC_VERSION_DEFAULT: > - config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; > - break; > case LIBXL_GIC_VERSION_V2: > config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V2; > break; > @@ -1800,6 +1797,48 @@ int libxl__arch_domain_build_info_setdefault(libxl__gc *gc, > /* Trapping of unmapped accesses enabled by default. */ > libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true); > > + /* > + * Resolve the GIC version against the host capabilities reported by > + * XEN_SYSCTL_physinfo. If the user didn't request a specific version, pick > + * the best one available. Otherwise validate the requested version here, > + * so a bad request fails early instead of in the hypervisor. > + */ > + { > + bool has_v3 = arch_capabilities_arm_gic_v3(physinfo->arch_capabilities); > + bool has_v2 = arch_capabilities_arm_gic_v2(physinfo->arch_capabilities); NIT: you can move them to the top to prevent the need for indentation. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Sep 16 13:43:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 13:43:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423164.1648421 (Exim 4.92) (envelope-from ) id 1x6puh-0005OQ-Oa; Wed, 16 Sep 2026 13:43:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423164.1648421; Wed, 16 Sep 2026 13:43:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6puh-0005OJ-La; Wed, 16 Sep 2026 13:43:03 +0000 Received: by outflank-mailman (input) for mailman id 1423164; Wed, 16 Sep 2026 13:43:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6pug-0005OD-1c for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:43:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6pue-00GuGo-Hn for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 15:43:01 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa9ce1-8faa-0a2a0a5109dd-0a2a45019bfa-4 for ; Wed, 16 Sep 2026 15:42:59 +0200 Received: from [198.175.65.14] (helo=mgamail.intel.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa9ce0-5984-0a2a45010019-c6af410e65d3-3 for ; Wed, 16 Sep 2026 15:42:58 +0200 Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2026 06:42:56 -0700 Received: from conormcd-mobl2.ger.corp.intel.com (HELO [10.245.244.154]) ([10.245.244.154]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2026 06:42:55 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=Intel header.d=intel.com header.i="@intel.com" header.h="Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Transfer-Encoding:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789566178; x=1821102178; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=lMOHGhqhRC7o8DUWxe2ZtG0eCBNNwQPKpwZSpxZkLjE=; b=E3WHzNVf+vIl6B6suA0kI16gdSsDKTtBZkOdYMxEA77ihaJXfUR6jB5g mGToMpf9INx8Of7hId02n1lnzz0rDh8vgKkbBjFkYMIs4N590vgb7iNA0 Zl66OCSz4wODHPndKHXROXSCuQxVaRyJPpUgy//LZfhTM4IihWbpPGcL4 j+FjjGXVkx6+2Qi+0P5GIvmTCxdc+6LTKgQqG09zhrfYaGlVDma1hyPin HXJJz9As0TH/Y+3y5Jc0OrLjJ75Z5v4sJwkTJ+yQH49tuqUyNhquHjbu0 iuTsZkDpQP/CMeCs2Q0NIYgZMRz3BfO7GC2gwcXyL2SxbOGsfw0F6h0CN Q==; X-CSE-ConnectionGUID: tmjk79AISji5MdGEoqYUkw== X-CSE-MsgGUID: 6TQlCiFrTOG8VCKq2euD1A== X-IronPort-AV: E=McAfee;i="6800,10657,11905"; a="93814093" X-IronPort-AV: E=Sophos;i="6.27,103,1787036400"; d="scan'208";a="93814093" X-CSE-ConnectionGUID: 33c8L43rQM+N7DHUEOWbWA== X-CSE-MsgGUID: IuQaeLKrSrK4WNC52PKSyQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,103,1787036400"; d="scan'208";a="303230461" Message-ID: <2efce17e1036dae156f0eb3f8abbce98e754d537.camel@linux.intel.com> Subject: Re: [PATCH] drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Szymon =?UTF-8?Q?Aceda=C5=84ski?= , intel-xe@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org, marmarek@invisiblethingslab.com, xen-devel@lists.xenproject.org, stable@vger.kernel.org Date: Wed, 16 Sep 2026 15:42:52 +0200 In-Reply-To: <20260820101212.1608543-1-accek@invisiblethingslab.com> References: <20260820101212.1608543-1-accek@invisiblethingslab.com> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) MIME-Version: 1.0 X-purgate-ID: tlsNG-d62444/1789566179-BFC69757-49853FCB/0/0 X-purgate-type: clean X-purgate-size: 3099 Hi! On Thu, 2026-08-20 at 12:12 +0200, Szymon Aceda=C5=84ski wrote: > Fixes display corruption on Xen PV dom0, where DMA buffers are not Please use imperative language in commit messages: "Fix display corruption..." > guaranteed machine-contiguous, in which case bounce buffering kicks > in, breaking xe's memory coherency assumptions. >=20 > Apply the same workaround i915 carries in i915_sg_segment_size() > since > commit 78a07fe777c4 ("drm/i915: stop abusing swiotlb_max_segment"). >=20 > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel > GPUs") > Reported-by: Marek Marczykowski-G=C3=B3recki > > Closes: > https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8382 > Link: https://lore.kernel.org/xen-devel/aYtznP_tT6xNPwf-@mail-itl/ > Link: > https://lore.kernel.org/all/20221020110308.1582518-1-hch@lst.de/=C2=A0# > i915 counterpart > Cc: stable@vger.kernel.org=C2=A0# v6.8+ > Signed-off-by: Szymon Aceda=C5=84ski Please also CC the Author of the original i915 patch in case there are any updates to the validity of this hack. While there is a precedent in i915 authored by Christoph, the patch really relies on completely undocumented behaviour.... Otherwise LGTM, Once you have an update I'll forward it to Xe CI. Thanks, Thomas > --- > =C2=A0drivers/gpu/drm/xe/xe_bo.h | 19 +++++++++++++++++++ > =C2=A01 file changed, 19 insertions(+) >=20 > diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h > index e8081af..152bfcf 100644 > --- a/drivers/gpu/drm/xe/xe_bo.h > +++ b/drivers/gpu/drm/xe/xe_bo.h > @@ -9,6 +9,8 @@ > =C2=A0#include > =C2=A0#include > =C2=A0 > +#include > + > =C2=A0#include "xe_bo_types.h" > =C2=A0#include "xe_ggtt.h" > =C2=A0#include "xe_macros.h" > @@ -575,6 +577,23 @@ static inline unsigned int > xe_sg_segment_size(struct device *dev) > =C2=A0 struct scatterlist __maybe_unused sg; > =C2=A0 size_t max =3D BIT_ULL(sizeof(sg.length) * 8) - 1; > =C2=A0 > + /* > + * For Xen PV guests pages aren't contiguous in DMA > (machine) address > + * space.=C2=A0 The DMA API takes care of that both in > dma_alloc_* (by > + * calling into the hypervisor to make the pages contiguous) > and in > + * dma_map_* (by bounce buffering).=C2=A0 But xe (like i915, see > commit > + * 78a07fe777c4) ignores the coherency aspects of the DMA > API and thus > + * can't cope with bounce buffering actually happening, so > add a hack > + * here to force small allocations and mappings when running > in PV > + * mode on Xen. > + * > + * Note this will still break if bounce buffering is > required for other > + * reasons, like confidential computing hypervisors or PCIe > root ports > + * with addressing limitations. > + */ > + if (xen_pv_domain()) > + return PAGE_SIZE; > + > =C2=A0 max =3D min_t(size_t, max, dma_max_mapping_size(dev)); > =C2=A0 > =C2=A0 /* >=20 > base-commit: b4f95affc66ef76342c1f6bf3849f6c8ade6b9d6 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 14:12:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 14:12:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423189.1648430 (Exim 4.92) (envelope-from ) id 1x6qMp-00052F-Tp; Wed, 16 Sep 2026 14:12:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423189.1648430; Wed, 16 Sep 2026 14:12:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qMp-000528-R9; Wed, 16 Sep 2026 14:12:07 +0000 Received: by outflank-mailman (input) for mailman id 1423189; Wed, 16 Sep 2026 14:12:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qMo-000520-0B for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:12:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6qMm-002vvX-J8 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 16:12:04 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaaa3b3-2eae-0a2a0a5409dd-0a2a45048ab6-0 for ; Wed, 16 Sep 2026 16:12:03 +0200 Received: from [52.101.52.68] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaaa3b2-b57f-0a2a45040019-34653444c099-3 for ; Wed, 16 Sep 2026 16:12:03 +0200 Received: from CH2PR18CA0021.namprd18.prod.outlook.com (2603:10b6:610:4f::31) by MN2PR12MB4175.namprd12.prod.outlook.com (2603:10b6:208:1d3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Wed, 16 Sep 2026 14:11:57 +0000 Received: from BN2PEPF0000A992.namprd04.prod.outlook.com (2603:10b6:610:4f:cafe::5a) by CH2PR18CA0021.outlook.office365.com (2603:10b6:610:4f::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 14:11:57 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF0000A992.mail.protection.outlook.com (10.167.248.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 14:11:55 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 09:11:54 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Wed, 16 Sep 2026 09:11:50 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BxtC3XKwMrnaNmc0YhBoOnEAs4XCIVBhFc7g/lcZedXv9HP64/v310VxpLB8Zd9D5l9kc+5Dga5p9VWZ4y/mv2tdo59t20K8K70EG4HNhxt71d4KqYaJNG6V7n0fSGPeHaYybIh66U0+qMgzBEN3M6RI/tpIgxNglpRxtQtAZjBN5noe1CswwEIaNO66vnQEwvrHcCjHrR2aKC/DpYjR+FPqAcUZfuL+ZH8FsoZ6UCywtimFdeXqqhVslj/7/OtwFVLtch00Pd+eRC61g9fHKGhTYhzbiuPcrKrpawR849SLe4WJOUraLN/d6AYD9wj9mX10cPauZ9MAaCh76EPx3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+qbHj1a5FX6YNk34OUl1j8Kb3V0wSr32WDkvEzQcPtA=; b=w0YPdKMumpPI23dBJIkTOVvpTTfb0x1cT1Tic0+5etJunbEW386MAckvTVvTFATNHj7hOFQdnsMop1DM7GuYrxstlsd+pDljngy7zkYKXcPc5fZSJRP49XmRyWpzsZLaXKxGZnth1iWFAshou2Ks/URqGfROqBqdZRnQV5ZeU4dCM44EJlLhJlIJL5M8soKpPk00zyMp8rKClkoHB9zzi9OwE8VvIvjiDO97hybLZTjZij+dbe+qN99OEhrgXKwugSrg3iymvvQGwcFKiYhtglVVv9h+fUMui2sZAf/qEzAW3lzWfAtGmJIkcasFtkm1NIDdxZhq9r3Mu/+vWgAgwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=temperror action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+qbHj1a5FX6YNk34OUl1j8Kb3V0wSr32WDkvEzQcPtA=; b=UIYhctP/9YHgHk+7tGRb5wXufLuAydfuOLoaHI9cNimt0yEd/34k09782xkXsq8iDyMJALvgkoGODwKz3gvL5oJy/U0eJrZGxuDSQ+RhckhPZx3+Gf5oR9Eu+Qm7+o8B9Phgc6Z0pVIiMK3BsnIHMaGM4FwthkJcbRk1JSg5Di0= X-MS-Exchange-Authentication-Results: spf=temperror (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=temperror action=none header.from=amd.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of amd.com: DNS Timeout) Message-ID: Date: Wed, 16 Sep 2026 16:11:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 4/6] xen/arm: remove XEN_DOMCTL_CONFIG_GIC_NATIVE from the ABI To: Julian Vetter , CC: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130863.8631fc262581453bbf619ec5b2062170.1a09082744e000c4f3@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1789130863.8631fc262581453bbf619ec5b2062170.1a09082744e000c4f3@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF0000A992:EE_|MN2PR12MB4175:EE_ X-MS-Office365-Filtering-Correlation-Id: 99b52762-f6a1-40b7-c1c4-08df13fc7692 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|376014|82310400026|1800799024|36860700016|13003099007|6133799003|10067099003|4143699003|11063799006|5023799004|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: EucNr4dCCNuu+X16NcxqY+pDKE9+oiIjcy27JgDzka+i3mHMjyLc5E2WCae5AHaHkUJ5lQ5bGwnIhlFN9JirDxH6E7vWLZg8sFTvhVVKYsi18ZQmVpyPruyNYW4qYi9AbdWjk1ipPW3enugjPFXfaPPF9NHj4k7QXB2EcWLBF7KqkGMywzbqEkElxhc+kgkzVA7+Yda60MZ4zwD9fe6VwWsr9/nGFlVUChCviwZgikdWAMsZCsEHggqBhXJfyjXc8ZRIc4XDxXTjeXb24v5tlWGNfKGhTMLl8jKu+goxvAPv8D4t9I1+BZA1edFVKF/ajlTtFMQ4Kz00pBWqHoTfNi89i2wfmiuHZdOq1ZWrp51rGeVThTCyks0iD0iJVliRlQ8D9SYMPsV8p/VgmbSk+MROj5lVfDXkKK283RgT2/ugoJGXW6BHjXfr9eR3erMJFWswJV1zEnJ8Rg4hh+f4T1TsrCekb5TQaVNb1/vfOAyc5pwm1Q0v6udQ+qniZBlj8wA4IicrAZxa8Ts+V4LB4MrYPMx3gug3r5+ERUWxzY5t1FyUAtIicdOxdTt/BMVlrrsHlHa6ZuEMFqpO7i3cbWW+q3boGCJLdcEvNkEnLKwIirCi5SY+jYFbsF1Z4h6CX6cPLkV+z0//LjRdPO7XmA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(376014)(82310400026)(1800799024)(36860700016)(13003099007)(6133799003)(10067099003)(4143699003)(11063799006)(5023799004)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: z6BC5hJpRaQwZg+mgs6w9fOMv1WmL4pg/NByRSOwIyMoEYeBW1T02avJAmlO9C6FLt4K/YGsH0SBYsTw+WV3TMAkplyYI/KihsbuEu/HJKVsUqmsuetA/ppBceYE37AEe75AvhUErz/3r1PzajeggGOtp/4YI0dQxLQC5ACJSh30qMQ3cRSEpbDVDIt/fy7EnwWYK5vYra+4dp2gw0ceAcpQ3nEbl8jMq6A8zaXdVT4uuDstzZ3Seb6F9ezVE5nNZaJrfbx7F6TwQORwUnSPyEDYQAMEFL46u30/4QyA6Uf6dOBOuD9b+AN6qUUKFpOj8ZcPggFcOyuDpBKeOdE92PqSR6e+3FlJGJcWm+K6RTFHuVxexyJPEDalrMfVoPa4CIP1MwjrXVIcNW7t01syYv/Oe7TJHTasJ7kYfuOIXGyaOmV6HO556ShbyFFjrkw1 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 14:11:55.1482 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99b52762-f6a1-40b7-c1c4-08df13fc7692 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF0000A992.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4175 X-purgate-ID: tlsNG-ebf023/1789567923-C32CCB50-BB0662D9/0/0 X-purgate-type: clean X-purgate-size: 8152 On 11-Sep-26 14:47, Julian Vetter wrote: > Now that the toolstack always resolves a concrete GIC_V2 or GIC_V3 > before calling createdomain, nothing on the Xen side needs to resolve > GIC_NATIVE either: > > * A new gic_domctl_hw_version() helper returns the > XEN_DOMCTL_CONFIG_GIC_* value matching the host's gic_hw_version(). > * arch_sanitise_domain_config() uses it to validate the requested > version against the hardware, rather than resolving GIC_NATIVE and > writing the result back into config->arch.gic_version. A guest must > use the host's GIC version, except that a GICv3 host with the GICv2 > compatibility mode enabled may also run GICv2 guests. This is the > same information that XEN_SYSCTL_physinfo reports to the toolstack. > * create_dom0() and arch_parse_dom0less_node(), which both always want > a vGIC that exactly matches the hardware, use the same helper instead > of GIC_NATIVE. > > With nothing left resolving or relying on it, drop > XEN_DOMCTL_CONFIG_GIC_NATIVE from the public ABI. Every caller must now > request a concrete GIC_V2 or GIC_V3. > > This is an incompatible change for any toolstack still passing 0 > (formerly GIC_NATIVE) expecting Xen to auto-select a version. Add a > CHANGELOG.md entry, noting that available GIC versions can be queried > via XEN_SYSCTL_physinfo. > > Signed-off-by: Julian Vetter > --- > Changes in v5: > - Rename gic_domctl_version() to gic_domctl_hw_version() > - Accept a GICv2 guest on a GICv3 host with GICv2 compatibility mode > enabled, instead of requiring an exact match with the host GIC version > --- > CHANGELOG.md | 4 ++++ > xen/arch/arm/dom0less-build.c | 3 ++- > xen/arch/arm/domain.c | 27 +++++++++++---------------- > xen/arch/arm/domain_build.c | 3 ++- > xen/arch/arm/gic.c | 16 ++++++++++++++++ > xen/arch/arm/include/asm/gic.h | 6 ++++++ > xen/include/public/arch-arm.h | 2 +- > 7 files changed, 42 insertions(+), 19 deletions(-) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index aa1a777dd4..78d1b13f3f 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -18,6 +18,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > ### Added > > ### Removed > + - On Arm: > + - XEN_DOMCTL_CONFIG_GIC_NATIVE has been removed. Toolstacks must now > + explicitly request GIC_V2 or GIC_V3 when creating a domain. > + Available GIC versions can be queried via XEN_SYSCTL_physinfo. > - On x86: > - The kexec "v1" interface, which was declared obsolete in Xen 4.4 (2013). > The only known user was the classic-xen fork of Linux. This does not > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 3f48f74226..7bbb2eafb6 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -368,7 +369,7 @@ int __init arch_parse_dom0less_node(struct dt_device_node *node, > unsigned int flags = bd->create_flags; > uint32_t val; > > - d_cfg->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; > + d_cfg->arch.gic_version = gic_domctl_hw_version(); > d_cfg->flags |= XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap; > > if ( domu_dt_sci_parse(node, d_cfg) ) > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index a739dd157e..6f5f92876e 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -609,23 +609,18 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) > return -EINVAL; > } > > - /* Fill in the native GIC version, passed back to the toolstack. */ > - if ( config->arch.gic_version == XEN_DOMCTL_CONFIG_GIC_NATIVE ) > + /* > + * A guest can only use the host's GIC version, except that a GICv3 host > + * with the GICv2 compatibility mode enabled can also run GICv2 guests. > + * This mirrors what XEN_SYSCTL_physinfo reports to the toolstack. > + */ > + if ( config->arch.gic_version != gic_domctl_hw_version() && > + !(config->arch.gic_version == XEN_DOMCTL_CONFIG_GIC_V2 && > + vgic_v2_hw_enabled()) ) > { > - switch ( gic_hw_version() ) > - { > - case GIC_V2: > - config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V2; > - break; > - > - case GIC_V3: > - config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V3; > - break; > - > - default: > - ASSERT_UNREACHABLE(); > - return -EINVAL; > - } > + dprintk(XENLOG_INFO, "Unsupported GIC version %u\n", There is a check below for max_vcpus being 0. With this check added, it becomes dead (unless vgic_max_vcpus() is changed), so add ASSERT_UNREACHABLE() there. > + config->arch.gic_version); > + return -EINVAL; > } > > /* max_vcpus depends on the GIC version, and Xen's compiled limit. */ > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 72d5316180..cf7e1100bd 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1960,7 +1961,7 @@ void __init create_dom0(void) > int rc; > > /* The vGIC for DOM0 is exactly emulating the hardware GIC */ > - dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; > + dom0_cfg.arch.gic_version = gic_domctl_hw_version(); > dom0_cfg.arch.nr_spis = vgic_def_nr_spis(); > dom0_cfg.arch.tee_type = tee_get_type(); > dom0_cfg.max_vcpus = dom0_max_vcpus(); > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index 078049e741..997b6ee6ed 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -56,6 +56,22 @@ enum gic_version gic_hw_version(void) > return gic_hw_ops->info->hw_version; > } > > +uint8_t gic_domctl_hw_version(void) > +{ > + switch ( gic_hw_version() ) > + { > + case GIC_V2: > + return XEN_DOMCTL_CONFIG_GIC_V2; > + > + case GIC_V3: > + return XEN_DOMCTL_CONFIG_GIC_V3; > + > + default: > + ASSERT_UNREACHABLE(); We should BUG() here instead to protect both builds given that you return just 0 (ASSERT would be ok provided you propagate somehow the error). > + return 0; > + } > +} > + > unsigned int gic_number_lines(void) > { > return gic_hw_ops->info->nr_lines; > diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h > index ee2c26adb4..434b888e69 100644 > --- a/xen/arch/arm/include/asm/gic.h > +++ b/xen/arch/arm/include/asm/gic.h > @@ -262,6 +262,12 @@ DECLARE_PER_CPU(uint64_t, lr_mask); > > extern enum gic_version gic_hw_version(void); > > +/* > + * The XEN_DOMCTL_CONFIG_GIC_* value matching the GIC version actually > + * present on this host. > + */ > +extern uint8_t gic_domctl_hw_version(void); No need for extern for prototypes. > + > /* Program the IRQ type into the GIC */ > void gic_set_irq_type(struct irq_desc *desc, unsigned int type); > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index 00de30b896..9d3bf11cbd 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -319,7 +319,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); > * struct xen_arch_domainconfig's ABI is covered by > * XEN_DOMCTL_INTERFACE_VERSION. > */ > -#define XEN_DOMCTL_CONFIG_GIC_NATIVE 0 > +/* XEN_DOMCTL_CONFIG_GIC_NATIVE 0 - removed in Xen 4.23 */ You should also update the comment below saying that gic_version is IN only. Otherwise, LGTM. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Sep 16 14:26:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 14:26:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423209.1648441 (Exim 4.92) (envelope-from ) id 1x6qau-00080s-6S; Wed, 16 Sep 2026 14:26:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423209.1648441; Wed, 16 Sep 2026 14:26:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qau-00080l-32; Wed, 16 Sep 2026 14:26:40 +0000 Received: by outflank-mailman (input) for mailman id 1423209; Wed, 16 Sep 2026 14:26:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qas-00080f-MN for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:26:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6qas-00AfeE-2g for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 16:26:38 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaaa718-e002-0a2a0a5209dd-0a2a450a8af6-12 for ; Wed, 16 Sep 2026 16:26:38 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaaa71c-f2d2-0a2a450a0019-ac6904fee068-3 for ; Wed, 16 Sep 2026 16:26:37 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id C62C0602CC; Wed, 16 Sep 2026 14:26:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 721FD1F00898; Wed, 16 Sep 2026 14:26:35 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 5AEB5CE04DE; Wed, 16 Sep 2026 07:26:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789568795; bh=YQpLtInKnNU1c3G2VdhDCkw1r2wibZuZTlQmjanXtRs=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=bNFUoDHPGDIHKeQpseuwGqWMM1DE5j1Rk5TojUwfAftuYfcdlx87V1FeTMnCjtl2N AzZz2tcm6JX+Y1OQc6CtoOxaw5D3FfiXa2dnSchn35L6zymzQspNu5cth2kF7lsF5q jpNwWJ3uu8kdD0rYYiWAJjzbNTYo7CXS4+AgNb1RdbrKjGhDjwDBgmcBv56HpihnJf 5lAGbidbtuSopBfptp1v/0NgSaHPYv5eiVpr4cDUdhOG39Il9EFme26lRJQ6V++7Fx IZEnAV/A5Yb1YwrjoCJL+B+GlgcJlLS1josFK4IKPCjqSH/X4mmuQciMXq9yC8zj9q 8uuQhtPvBPadQ== Date: Wed, 16 Sep 2026 07:26:35 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-4011c0/1789568798-589C9CFC-05396C9F/0/0 X-purgate-type: clean X-purgate-size: 3420 On Wed, Sep 16, 2026 at 02:40:20PM +0200, Frederic Weisbecker wrote: > Le Tue, Sep 15, 2026 at 04:56:41PM -0700, Paul E. McKenney a crit : > > > Alternatively the approach could be generalized to vanilla RCU, it could be > > > possible to define a .text.rcu_no_qs section within which code running is > > > considered as an RCU reader (with a pause while on the explicit RCU tasks > > > section). It would be forbidden to voluntary sleep inside > > > and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). > > > > > > Based on IP, RCU could consider those interrupted section as readers. This would > > > require PREEMPT_RCU though. > > > > > > And then synchronize_rcu() would do the 1, 2, 4 jobs. > > > > If I am following correctly (ha!), sleepable BPF programs rule out use > > of RCU in this manner. > > > > But your point is nevertheless valid, in that SRCU could be used. > > And because rcu_read_lock_trace() is a thin wrapper around SRCU-fast, we > > *might* be able to instead use rcu_read_lock_tasks_trace(), which would > > skip the task-struct increment and decrement, saving a few instructions. > > Then, instead of waiting for each task's counter to go to zero, instead > > just invoke synchronize_rcu_tasks_trace(). > > > > Which is pretty close to what Josef is proposing, just with the new RCU > > Tasks Trace read-side primitives. I think. ;-) > > > > This assumes that we do not need to flatten partially overlapping RCU > > Tasks Trace readers into one big reader. > > > > Or am I missing something here? > > Yes I think that's what Josef does in this patchset. The problem is about > handling the few instructions: > > 1) between the begining of the trampoline and the call to rcu_read_lock_trace() > > 2) between the call to rcu_read_unlock_trace() and the end of the trampoline > > So what I'm proposing is to make those two parts implicit RCU read lock sections. > > So the whole trampoline would be .text.rcu_no_qs: > > .text.rcu_no_qs trampoline: > __________________________________________________________________________________________ > |Few instructions 1 | rcu_read_lock_trace() .... rcu_read_unlock_trace | Few instructions 2| > ___________________________________________________________________________________________ > > Then when a tick fires, rcu_flavor_sched_clock_irq() discards the interrupted > code as QS if the IP was within .text.rcu_no_qs _unless_ it is in the > rcu_read_lock_trace. Both are easy and quick to verify. > > Also preempt_schedule_irq() would make sure to verify the same condition and > enqueue the task as a GP blocker if preempting inside "Few instructions 1" > or "Few instructions 2". Ah, OK, I might be following now. ;-) We also need both versions of rcu_exp_handler() to check the IP as well, given that sooner or later someone is going to want trampoline removal to go faster. Or am I still missing a turn in here somewhere? > And since RCU tasks already does a synchronize RCU before and after the scan, > that's all we would have to do. This is going to need some *serious* documentation. Also, what would be a good way to add tests for this to rcutorture? Designate some new rcutorture function as being in .text.rcu_no_qs and add this as another type of rcutorture reader? Or is there a better way? Thanx, Paul From xen-devel-bounces@lists.xenproject.org Wed Sep 16 14:36:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 14:36:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423226.1648448 (Exim 4.92) (envelope-from ) id 1x6qjv-00029c-06; Wed, 16 Sep 2026 14:35:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423226.1648448; Wed, 16 Sep 2026 14:35:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qju-00029V-TX; Wed, 16 Sep 2026 14:35:58 +0000 Received: by outflank-mailman (input) for mailman id 1423226; Wed, 16 Sep 2026 14:35:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qjs-00029P-RE for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:35:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6qjs-00Ah3I-7o for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 16:35:56 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaaa92d-2eae-0a2a0a5409dd-0a2a4503cf64-44 for ; Wed, 16 Sep 2026 16:35:56 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaaa94a-fae8-0a2a45030019-ac6904fe9e94-3 for ; Wed, 16 Sep 2026 16:35:55 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 28FCC60008; Wed, 16 Sep 2026 14:35:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 284711F00893; Wed, 16 Sep 2026 14:35:53 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789569353; bh=dRzGIp8BZC3HTfXO+TCW/m41vLXjfhf9X+2OCoM1kLM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=FA5kMueDfHQy6e7vnoQFHpYhwZpX7iem27nD89IbZJX2O9EUmarZgs1YNP4KAYjAK QifdGNffl2hCcco37lyGuH3hnSh6qg+tY3yJtb3RWolk50ac+Z7PmhikxXXLCDUc3l CnuwVmM9f3JUI5Ylx7XQYhbg4O78htzc8S2XmH7oHC9F2WbMqRXZ2mLRizxW4+c6IK wLhbL7RGjN9QRqvaBL7HmI70fgIgjcWABsFnNBBIbszSofHGVMPtQmr61SstIQUgeI nEaLyqYTCaYzHG7enXG6FfKdw6evl82vQs3bPs+7qBV93sYtEKnTZ4HL2C4CoAyN71 tmAdxw/yHaJMw== Date: Wed, 16 Sep 2026 16:35:50 +0200 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> X-purgate-ID: tlsNG-33051d/1789569356-74E874E9-7ACE59BD/0/0 X-purgate-type: clean X-purgate-size: 3745 Le Wed, Sep 16, 2026 at 07:26:35AM -0700, Paul E. McKenney a crit : > On Wed, Sep 16, 2026 at 02:40:20PM +0200, Frederic Weisbecker wrote: > > Le Tue, Sep 15, 2026 at 04:56:41PM -0700, Paul E. McKenney a crit : > > > > Alternatively the approach could be generalized to vanilla RCU, it could be > > > > possible to define a .text.rcu_no_qs section within which code running is > > > > considered as an RCU reader (with a pause while on the explicit RCU tasks > > > > section). It would be forbidden to voluntary sleep inside > > > > and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). > > > > > > > > Based on IP, RCU could consider those interrupted section as readers. This would > > > > require PREEMPT_RCU though. > > > > > > > > And then synchronize_rcu() would do the 1, 2, 4 jobs. > > > > > > If I am following correctly (ha!), sleepable BPF programs rule out use > > > of RCU in this manner. > > > > > > But your point is nevertheless valid, in that SRCU could be used. > > > And because rcu_read_lock_trace() is a thin wrapper around SRCU-fast, we > > > *might* be able to instead use rcu_read_lock_tasks_trace(), which would > > > skip the task-struct increment and decrement, saving a few instructions. > > > Then, instead of waiting for each task's counter to go to zero, instead > > > just invoke synchronize_rcu_tasks_trace(). > > > > > > Which is pretty close to what Josef is proposing, just with the new RCU > > > Tasks Trace read-side primitives. I think. ;-) > > > > > > This assumes that we do not need to flatten partially overlapping RCU > > > Tasks Trace readers into one big reader. > > > > > > Or am I missing something here? > > > > Yes I think that's what Josef does in this patchset. The problem is about > > handling the few instructions: > > > > 1) between the begining of the trampoline and the call to rcu_read_lock_trace() > > > > 2) between the call to rcu_read_unlock_trace() and the end of the trampoline > > > > So what I'm proposing is to make those two parts implicit RCU read lock sections. > > > > So the whole trampoline would be .text.rcu_no_qs: > > > > .text.rcu_no_qs trampoline: > > __________________________________________________________________________________________ > > |Few instructions 1 | rcu_read_lock_trace() .... rcu_read_unlock_trace | Few instructions 2| > > ___________________________________________________________________________________________ > > > > Then when a tick fires, rcu_flavor_sched_clock_irq() discards the interrupted > > code as QS if the IP was within .text.rcu_no_qs _unless_ it is in the > > rcu_read_lock_trace. Both are easy and quick to verify. > > > > Also preempt_schedule_irq() would make sure to verify the same condition and > > enqueue the task as a GP blocker if preempting inside "Few instructions 1" > > or "Few instructions 2". > > Ah, OK, I might be following now. ;-) > > We also need both versions of rcu_exp_handler() to check the IP as well, > given that sooner or later someone is going to want trampoline removal > to go faster. Or am I still missing a turn in here somewhere? Yes indeed, missed the exp part! > > > And since RCU tasks already does a synchronize RCU before and after the scan, > > that's all we would have to do. > > This is going to need some *serious* documentation. Yes :-) > Also, what would be a good way to add tests for this to rcutorture? > Designate some new rcutorture function as being in .text.rcu_no_qs and > add this as another type of rcutorture reader? Or is there a better way? Yes that sounds good! > > Thanx, Paul -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Wed Sep 16 14:37:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 14:37:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423232.1648458 (Exim 4.92) (envelope-from ) id 1x6qlK-0002ds-9H; Wed, 16 Sep 2026 14:37:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423232.1648458; Wed, 16 Sep 2026 14:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qlK-0002dl-6h; Wed, 16 Sep 2026 14:37:26 +0000 Received: by outflank-mailman (input) for mailman id 1423232; Wed, 16 Sep 2026 14:37:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qlJ-0002df-A6 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:37:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6qlI-006AYu-NM for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 16:37:24 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaaa998-e002-0a2a0a5209dd-0a2a45098080-18 for ; Wed, 16 Sep 2026 16:37:23 +0200 Received: from [18.216.144.57] (helo=yurei.relay-egress.a.mail.umich.edu) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaaa9a1-be1a-0a2a45090019-12d89039d6de-3 for ; Wed, 16 Sep 2026 16:37:22 +0200 Received: from ecstatic-alux.authn-relay.a.mail.umich.edu (ip-10-0-74-47.us-east-2.compute.internal [10.0.74.47]) by yurei.relay-egress.a.mail.umich.edu with ESMTPS id 6AAAA9A1.1E50635C.618204D5.233540; Wed, 16 Sep 2026 10:37:21 -0400 Received: from mail-lf2-f13.google.com (mail-lf2-f13.google.com [74.125.229.205]) by ecstatic-alux.authn-relay.a.mail.umich.edu with ESMTPSA id 6AAAA9A0.2E70A683.26708D96.1774539; Wed, 16 Sep 2026 10:37:21 -0400 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b5e4f16f15so998934e87.3 for ; Wed, 16 Sep 2026 07:37:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=relay-1 header.d=umich.edu header.i="@umich.edu" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-1; t=1789569441; bh=vP+kDBT3fDlaM1JatwsC88YOWaDz4s5Z7/lGCUT6FhE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Ky+OuugVuJ0MzL1iA14kHDvNtgz+hP01ZLALPKmTkDqzjwEJPbU1imxDtcUIdpCny dZrC1sIfF+x8suEgLwZZDhuGzyS1o9ltW+0AuIPV89sdQWAfSPtw+J02JaaX6M+nxD Rzt/3wFjvOG+ta9KtshzJ454WCYDHGTcU/uaLbVfq93/W9RQGf7m3WzWuqDvX2J0NJ 3QIL0R1wL8Z2hvzFaUoOKkzUHHsFIA+e284ESF0rWZocxsgMo0XP0UxwfzqAitPEUg TTNFY0myNVwtiUVfLENr58fdEanFV4FyF8+OrLTlNedBZv8t+yKCsWXEdYCEbUFATK a2h0ZZEMzBmiw== Authentication-Results: ecstatic-alux.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=74.125.229.205 (mail-lf2-f13.google.com); auth=pass smtp.auth=dunlapg X-Gm-Message-State: AFuF++mXaWBLQvidhG78lTosF0z1P0AEMVGnyRr6xiUt57n8UUAnSjku vkmTJVOh5PoQ6FCDTjTjM8lMFs994Y7FLFVtDlaQ4THFyN3dTJiPHk4QzGqoSvRPY+ZRcQu5VSo 5psyEchdWflVJ88ogkUpeGHvawCgNZis= X-Received: by 2002:a05:6512:1318:b0:5b6:6af:4e0e with SMTP id 2adb3069b0e04-5b8b661a3edmr1650433e87.3.1789569438962; Wed, 16 Sep 2026 07:37:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Dunlap Date: Wed, 16 Sep 2026 16:37:07 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1X5QMHHfcnSweQ5rKXLNR7hvpsajkA_-RQeX4gjj6EBXTUkoQKndkEGB-s Message-ID: Subject: Re: [PATCH v2 1/2] EFI: avoid OOB config file reads To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Marek Marczykowski , Daniel Smith , Andrew Cooper Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1789569443-BF4D3034-779651D1/0/0 X-purgate-type: clean X-purgate-size: 1104 On Wed, Mar 25, 2026 at 2:24=E2=80=AFPM Jan Beulich wro= te: > @@ -878,6 +882,23 @@ static bool __init read_section(const EF > > file->ptr =3D ptr; > > + /* For cfg file, if necessary allocate space to put an extra NUL the= re. */ > + if ( file =3D=3D &cfg && file->size && !iscntrl(file->str[file->size= - 1]) ) > + { > + EFI_PHYSICAL_ADDRESS addr; > + EFI_STATUS ret =3D efi_bs->AllocatePages(AllocateMaxAddress, > + EfiLoaderData, > + PFN_UP(file->size + 1), &= addr); efiapi.h lists the Memory parameter as OUT, but that seems to be a mistake; the UEFI spec [1] says this is IN OUT; and the other two callers of AllocatePages in Xen initialize the value before passing it in. So we should probably fix both efiapi.h, and initialize this to an appropriate value, rather than passing in stack rubble. Discovered by sashiko+Opus. -George [1] https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May= %202020.pdf From xen-devel-bounces@lists.xenproject.org Wed Sep 16 14:38:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 14:38:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423239.1648467 (Exim 4.92) (envelope-from ) id 1x6qmQ-0003Pu-IX; Wed, 16 Sep 2026 14:38:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423239.1648467; Wed, 16 Sep 2026 14:38:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qmQ-0003Pn-FM; Wed, 16 Sep 2026 14:38:34 +0000 Received: by outflank-mailman (input) for mailman id 1423239; Wed, 16 Sep 2026 14:38:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qmP-0003Pd-9O for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:38:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6qmO-005BHt-MJ for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 16:38:32 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaaa9df-8faa-0a2a0a5109dd-0a2a4503d58a-36 for ; Wed, 16 Sep 2026 16:38:32 +0200 Received: from [40.107.209.39] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaaa9e6-fae8-0a2a45030019-286bd127ec3b-3 for ; Wed, 16 Sep 2026 16:38:32 +0200 Received: from SJ0PR13CA0125.namprd13.prod.outlook.com (2603:10b6:a03:2c6::10) by SA0PR12MB4414.namprd12.prod.outlook.com (2603:10b6:806:9a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 14:38:25 +0000 Received: from SJ1PEPF000026C5.namprd04.prod.outlook.com (2603:10b6:a03:2c6:cafe::d2) by SJ0PR13CA0125.outlook.office365.com (2603:10b6:a03:2c6::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.7 via Frontend Transport; Wed, 16 Sep 2026 14:38:25 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ1PEPF000026C5.mail.protection.outlook.com (10.167.244.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 14:38:24 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 09:38:21 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 09:38:21 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Wed, 16 Sep 2026 09:38:17 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aIulBRCVpxYjEGIoVnTriNNJ37MVs3zqy12fzDuk/jec3u9nI9lmLBfCRO3awe2CV/N4WtIhPQ0ye0YP36or7PO8u8EQqRrlK/b48HoTDe0iKcnaVGduCiqZ8bGuATv6a2Q9XGjGRWsrMZRtF1+bmhQEeEz+4fVvaV8Bj1otTsUtHrO131IwZxfjrYDM+6rISoe2mPokLBCeTee3tDyzVU9M92oWGwfwDzZZcbd2ANdoZ9JTFvD8bfG9MGwTxqm3hnTqyKRzCmNzio2q5IJpFD3mvU0ai55G2nqNph1d5NrQwr86VrnpEjff635s+EWypPQJDGa4rVBCMMF/zfyvCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c1VYw1JVMv0jGKjEWxwkh/UE1+S6crJIjV50/HX6X7M=; b=oi2f1frZEFjtokASrjI7wRKHpOa9BtCIe8cCbL/r/StUJosveyl7azGEy52qxeZO1kasYaymtct2I+5+nG2TchH3/HeMd36bz4LJ5gnWvtM87i4Pn/SRdi2LsWy1iQDgcCJ/h/7rnGFoBKeLm5AvNijSGxykhjX2Sgbvh/W40SmCOwlpppu7RhG9TarUDG/MSAnRGzYdthTM42TFKqsyrYAZAgK375sVIrR6ZDsVFMNtg4F90bHTge1w3hEBeI8wdffcW/4NdXfES7E8WIy9miRqnV5O4ewrxf/i+zl9x6lXpqJFdiMow/mFRMN7Jib859zGFnJJjiYe9jDs9KoGyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c1VYw1JVMv0jGKjEWxwkh/UE1+S6crJIjV50/HX6X7M=; b=OO5ZN++HmtG0NFP1hIeUVheEvWmarNpiRNh4KsODX3m3EPEwoJPly2i3Hkc1mICpEQZFekWJHFwC8G4EOp9ziXXMiblhyQkuXjY8e6/FnEe2hRPdpVzIu+xF0SEn+miBoefc7D/0U5nDOv0XepWrgxzFnGj7S4fciggMOWUPr+o= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: <8f347150-0634-4e02-b000-d3f2ed0d6090@amd.com> Date: Wed, 16 Sep 2026 16:38:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 5/6] xen/arm: report clock_frequency via sysctl physinfo, not createdomain To: Julian Vetter , CC: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , "Jan Beulich" , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130864.8631fc262581453bbf619ec5b2062170.1a0908275e9000c4f3@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1789130864.8631fc262581453bbf619ec5b2062170.1a0908275e9000c4f3@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000026C5:EE_|SA0PR12MB4414:EE_ X-MS-Office365-Filtering-Correlation-Id: f407d348-2dc8-412a-c70f-08df14002a28 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|7416014|376014|1800799024|82310400026|4143699003|56012099006|5023799004|10067099003|11063799006|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: 4+TgrCwr01+ouWdu/qswmlqzPrvnA0EXDbW/PxtnqxRaWM374C15jfeRA4mUXdWx3lqd53YIj4G0/OUmvzNdbC9fS348cYbVKB9sOtpQyDjRZngj4GdTCRkHNiIFqZ5eCaEhAd1EBdvk2kuZp0vYNiZRkZtNHdF3N5TLCVvy7YJpAOis6PGzMR0eHtR/e46vuhNbSmIl2I1IUbE5kmeUnUg02ASgvbq3BfTERPqsujVz4Hrp4GBm21Ucrf1t49tuf0+4QUx3QlaFtaSdHiWG0Yws9eUCkI7WAOjRkSKVZuKfqsDp+CLk0Xfbv6zvimAiXDJ9cL340ORJj7gsbL/oKZab2z6aof6HoMVS+RbjEgksIV3KE1JqFNs8/ftsSQvgRm3HmPsh1obU9a4j2DydOyToRJkgyXVH4Vw3HTdBwFvI/52nTsbxwIn5yl3OzMIrhgYSaYPTEDRwt0LtpsP5m8COVvcVeE2D3siK7AYUb6xN0Wah70e9kfyHFru+sm9lFHq+8Uhh7md38MWIsRqJkJ+6WHe3zo+sa/cDnIIsDJdQI8HK2ggJkvlyp7ev23+ddWgOK45oVUcYZRlZrhDjPYotAQV5/QhsDxTIrpKA7RSEV11QMpr3ax4RxfdzKgeq5kIf3EcnI3AgXYi+h5mzJOWYTjQd2yFde1hLfvPY/jcKUlyhgcOGjhcpMISVz6eaufKJw5kv+Roc9dlKiAHM3Q== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(7416014)(376014)(1800799024)(82310400026)(4143699003)(56012099006)(5023799004)(10067099003)(11063799006)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: XOunlzLN87a6XwUc1s9tmzMnOiFXJkkUS8DevWjOHsjwGdzbGhLt1ZQBRk1VbUl/kDgj1l7QXh2qC8beXHm7GSyaLlvMbZPxKxLcOBPOzZ8bKjJlAAMVD78RxP4y7a0is7LqeDuT30sYpm68+ifDIUgniK9phsa0DyPNrEQJ8AZSsYiNJz9y0YmumIVMAr7LYnyj3rR+v7UMc47KpwtQ46MZofXJQeGG0uWT6GktugAq7Ud54YlazuXMI5ZKZQEerrJjHRSunInCrW6RBx9Rufs3P9o870QTnW4D5wW2yzzr+LegG7YtxF5qjCqZbPyhzs1aJK+3QeG2c2JYM43gl4lx1G36eSHXU8gVY8SvumMaqBEfcoqwoV/ZPzX0KxuscWCx0f58Gj6oQ6ELa0UsvDy2EVic/Q5zhnEDajG+Z+Qlcm/V3mNKcS46wjEx9Rvc X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 14:38:24.8762 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f407d348-2dc8-412a-c70f-08df14002a28 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000026C5.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4414 X-purgate-ID: tlsNG-33051d/1789569512-752854E9-ECC4ACE7/0/0 X-purgate-type: clean X-purgate-size: 3248 On 11-Sep-26 14:47, Julian Vetter wrote: > The xen_arch_domainconfig.clock_frequency value is populated in > domain_vtimer_init() during XEN_DOMCTL_createdomain from the global > timer_dt_clock_frequency, which comes from the host's DT timer node and > has nothing to do with the domain being created. Like now removed > GIC_NATIVE resolution, this is a host-wide system property being > smuggled out through a domain-creation IN struct. > > Expose it instead as a new arch_clock_frequency_hz field in > XEN_SYSCTL_physinfo, populated via arch_do_physinfo(), and mirroring how > the GIC capability bits were already moved there. > > Rather than making the field dependant on DT boot, make Xen always > report the timer frequency, either via the DT "clock-frequency" node, or > directly via CNTFRQ_EL0. preinit_xen_time() already computes cpu_khz for > every boot path. The renamed timer_clock_frequency_hz now captures > whichever of the two produced that value, in full Hz precision, instead > of only recording the DT case. So, ACPI guests get a real value too, > allowing to drop the special case. > > The DT "clock-frequency" property exists because firmware might leave > CNTFRQ_EL0 wrong, and since CNTFRQ_EL0 cannot be trapped the only fix is > to replicate the correct value into the guest DT. To keep that signal, a > new XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ capability bit records whether > arch_clock_frequency_hz came from the DT property. Then libxl only emits > a "clock-frequency" property into the guest timer node when that bit is > set. A guest whose CNTFRQ_EL0 is already correct keeps an unmodified > timer node, exactly as before. > > Although the CNTFRQ_EL0 register is 64 bits wide, and some current timer > implementations run at 1GHz, a 32bit value is sufficient to store the > timer value, because it only mirrors the DT 'clock-frequency' property, > which the bindings define as a single 32-bit cell. > > In struct xen_sysctl_physinfo the new field just reuses the former pad > word, so sysctl consumers are unaffected. struct xen_arch_domainconfig > however loses clock_frequency from its middle, which shrinks the struct > and shifts every field after it, so bump XEN_DOMCTL_INTERFACE_VERSION. > > The xen_arch_domainconfig parameter passed to domain_vtimer_init() is no > longer needed, so drop that parameter entirely. libxl now fetches the > frequency via libxl_get_physinfo() in libxl__arch_domain_save_config() > instead of reading it back out of the createdomain reply. The OCaml > xen_arch_domainconfig mirror drops the field too. > > Signed-off-by: Julian Vetter [...] > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index 9d3bf11cbd..5d15f572c7 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -335,7 +335,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); > #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_VMSA 2 > > struct xen_arch_domainconfig { > - /* IN/OUT */ > + /* IN */ This belong to one of the previous patches. Reviewed-by: Michal Orzel You still need a toolstack maintainer tag. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Sep 16 14:39:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 14:39:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423248.1648476 (Exim 4.92) (envelope-from ) id 1x6qnW-0004I3-Uh; Wed, 16 Sep 2026 14:39:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423248.1648476; Wed, 16 Sep 2026 14:39: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 1x6qnW-0004Hw-RX; Wed, 16 Sep 2026 14:39:42 +0000 Received: by outflank-mailman (input) for mailman id 1423248; Wed, 16 Sep 2026 14:39:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qnV-0004Hm-Es for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:39:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6qnU-0005FY-RD for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 16:39:40 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaaaa23-e002-0a2a0a5209dd-0a2a450492cc-16 for ; Wed, 16 Sep 2026 16:39:40 +0200 Received: from [40.107.200.56] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaaaa29-b57f-0a2a45040019-286bc83828e0-3 for ; Wed, 16 Sep 2026 16:39:40 +0200 Received: from SN7PR04CA0120.namprd04.prod.outlook.com (2603:10b6:806:122::35) by PH0PR12MB5632.namprd12.prod.outlook.com (2603:10b6:510:14c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Wed, 16 Sep 2026 14:39:30 +0000 Received: from SN1PEPF00036F3C.namprd05.prod.outlook.com (2603:10b6:806:122:cafe::5f) by SN7PR04CA0120.outlook.office365.com (2603:10b6:806:122::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Wed, 16 Sep 2026 14:39:30 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SN1PEPF00036F3C.mail.protection.outlook.com (10.167.248.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.7 via Frontend Transport; Wed, 16 Sep 2026 14:39:30 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 09:39:28 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 16 Sep 2026 09:39:27 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Wed, 16 Sep 2026 09:39:23 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QrPUxMuXi/RjFfxc/22QD4eaL+xRixWb1SILwOaaUi0H5gNeZM1Tk5Lk5kJNzlRSxRQ5bKWyhJNcZsKXKLfAn7se4D8LGfsKgmkK6lyNLXrhZe4mDS9clqxMOKUOpRw0rReX7Y5b7wQ/sMflKmlUA0l2PDQj2/ytFHmFEjPUMEhl9PIQhLQeQFwOCXui2NDdWSzbZ7J7TitXtVkE/JbDqsCr2Pt59sRiOqyxWNo3ADz1Bg7EXmJ8oW0xEYj3odLBeuEboR/C1LzLZUtMog2GXHjfojjHgQ00QufAnFexqU4J2xC9O/Jg7j8UC8QJTl7k/pINaW95uETrwLuscADR3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pz4q6f7GLl8hC/23nld3wkkhJVaSL+69OiDtd5ESiow=; b=SVclmbPCVlA6BAI5yNHeHqhZhX1XQ0cL02g9uUDwmWokI10VZN1fPB5lCXBPBg2iyUXNPxYnq/WPociY8d/G5aUZP9CGgtS8Y7w3BEhaaXI4bEi3LN/vz2zEZGTwCumZf2u1qGLT/n8VVmpBgKZfLbSXCTK6RLwtnkoSSqFnK3HIvu09JbP67QmjYzd9HbxgBCd5GjSa4FNbdU84pCZs0bwe5rEBoevJHcdGLghtNfFqQ170/Z2ipTNBwTBrq9+SIxvLbhWH8DzE4TxuezU1urSLxPQnLprU+bvgcEQUGybqCzmgh2mDDRmG9cYmVD4OkpiZC75sq+nSboxYB7ID8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pz4q6f7GLl8hC/23nld3wkkhJVaSL+69OiDtd5ESiow=; b=muPuCqJ/mmvU9QPVtfnn2Iu2n6gvlPNG25eE/O0u+YhKQyjxqkMyX/5/t8LoxcduzBHb+ZIiHz+6ChEOx8F/apR7RlD1SGvs6ZhHJHUzWvw1/QYI3mC1NRV1zc7Hvp+ynu7Y+I+5me3vNvAJYoOgxuFiD592O/I1ELDNlGJtr8c= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: Date: Wed, 16 Sep 2026 16:39:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 6/6] xen: make config argument const To: Julian Vetter , CC: Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , "Jan Beulich" , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130864.8631fc262581453bbf619ec5b2062170.1a0908277f6000c4f3@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1789130864.8631fc262581453bbf619ec5b2062170.1a0908277f6000c4f3@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3C:EE_|PH0PR12MB5632:EE_ X-MS-Office365-Filtering-Correlation-Id: 18e88d60-fd5f-4188-5c3a-08df140050fd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|36860700016|23010399003|376014|82310400026|1800799024|4143699003|11063799006|10067099003|18002099003|22082099003|6133799003|56012099006|3023799007; X-Microsoft-Antispam-Message-Info: coU8w49d31fU4I2Xt+Ca3R0OZHAf4WGlLc5eR1lY4jm8Kzd+Azj7vHyU3i4+6oMEKnewkBGptDnXB0Y6R/0jfjpZhHdodzvlzu6A6MbQFOxcc/yX3hB6Ivb+JapcFD+kmRwhLFlxVXuuqM5BJV4ZNBU87jiqwvW9nwGVGAjjoo1a4QbjLu5GCUL0m8KfrnLz2wokNmDnvoIqPfBrQUQCAcivITgfHXDKmrJ3brM093KKbaGZvwK9DvD5YJxLuo6GobFhsHGAAq8kp8HVszngtjfyCIIbm6g/M0yaniHeFTQi8mEmdGTu5hSm5eqwbtPgrpUy/39cM519UEcw/l+OxUQgjew+NgdgrV5zR21PIATPMo4mbVx2tHBkFQUOgWTMnq7T+n11Rtl/J5txsjIaegWlWRaMZeX1WsxShCCnAARiN2M1Sf1j5u63wEPs3qKmGGMXp5wvuujBcuAmDnBCqiiC5XPYjgHknnhuHQF9QUiUN6zENOM0sm59ts87F/0fCRdzNqjGHGDmPTdkO0Yxvjf9OIgYfRrIc8nSfZtm6pxZabtnfa6nKSn5iuD6IYAYkilO/PAMi/2rEFA6zd/+6sVFL7KhymN0877D34wfXbYgXeV/MyG4XTR4Ypg2gAuJhfB/LXYGY5oB6oNz/dgJzbPHmG3obLniRgGwIms0TY5njfmfBD9hTNHhHT51mPXCYqNsuomxn5pb++raa6q0HA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(36860700016)(23010399003)(376014)(82310400026)(1800799024)(4143699003)(11063799006)(10067099003)(18002099003)(22082099003)(6133799003)(56012099006)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Ium0/KCgOS62Ph/Lb8Z4Ucsebp/Hm+Oe0KZdz8AhdrD/6Hb+8X2xbjcpixezlzqiYhcYOUgE6dyagKfQYJogpwm1wAW3fcDYqPx0FCNmqGGbFARy13F/F/kISjAO/cU1W+8lOPuxTyTh3X3FMnLGNaAl8wG1prxNsMGXJbzToSr7/mG5TPyPAAuZD5GyiYDT/pJEXNfplYusA89csD5EKvy480Dt15kyzs0+tblyX6YJNRkr5xijiLRn5kajRfS6xFeK39qga4iAa9yfFyX2kEAiS7eSO2dAkqgl6fTRJIaTXJ3raj2+7mXEtjmRe2zv2fB6U1LoNsO3/kst5jSIbQeYj2pco0xoWYowmJwfr6SPQiJWv8lN97GeIZe778hw4EUUQ3fIdbIUpw2syyZQrjUTqoKqwQ4ahO5mnSWNLqIwQI+61176ejcM1ERrdDOh X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2026 14:39:30.0613 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 18e88d60-fd5f-4188-5c3a-08df140050fd X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF00036F3C.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB5632 X-purgate-ID: tlsNG-ebf023/1789569580-530CDB50-3B5DF09F/0/0 X-purgate-type: clean X-purgate-size: 1303 On 11-Sep-26 14:47, Julian Vetter wrote: > arch_sanitise_domain_config() validates the configuration requested by > the toolstack, and should not fill anything in. The config struct passed > to createdomain is supposed to be pure input. ARM used to abuse this > (GIC_NATIVE resolution, now removed) to smuggle output back to the > toolstack. Making the parameter const stops that type of abuse from > happening on any architecture. > > The x86 implementation turned out to have its own instance of the same > issue. It set XEN_DOMCTL_CDF_oos_off into config->flags for non-HVM > guests. Since The sanitisation runs before the function domain_create() > copies config->flags into d->options, this relied on mutating the > toolstack's config to take effect. Move the default onto d->options > directly in arch_domain_create() (which runs after d->options is > populated), where all the remaining domain options are resolved. This > has the same effect and no mutation of the input config is required. > > ARM, PPC and RISC-V need no equivalent change, Their implementations > were already read-only. > > Signed-off-by: Julian Vetter > Reviewed-by: Jan Beulich # x86 Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Wed Sep 16 14:47:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 14:47:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423263.1648484 (Exim 4.92) (envelope-from ) id 1x6qvA-0006A4-LH; Wed, 16 Sep 2026 14:47:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423263.1648484; Wed, 16 Sep 2026 14:47:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qvA-00069x-IW; Wed, 16 Sep 2026 14:47:36 +0000 Received: by outflank-mailman (input) for mailman id 1423263; Wed, 16 Sep 2026 14:47:35 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6qv9-00068d-8F for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:47:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6qv8-00H6sL-LS for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 16:47:34 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaaabfc-2eae-0a2a0a5409dd-0a2a45068a4c-32 for ; Wed, 16 Sep 2026 16:47:34 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaaac05-195a-0a2a45060019-ac6904fe957a-3 for ; Wed, 16 Sep 2026 16:47:34 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 6DAB36057A; Wed, 16 Sep 2026 14:47:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E8D21F00898; Wed, 16 Sep 2026 14:47:31 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789570052; bh=nEwQ5laeGMbsqBGqeW1j1B+pVXcHOGrBCoV3rMszFqI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ESfNYJff1sk7IiuwwG3HvTPMmCGAx8UgjOjjnCy2TviZOIYSqWqg0sdwtZLMQ4SFB GyQc6zB66KFJ3Hi63acec2mkm3/wskIaQUWVvFemdJFFUL1G7AfAM8FQYe7cuyIbHB miyVE3hyVQL8kdra34J+OCKDwWqkJmxHNhFMtUeYQ1viY/hUvEL0XJvzopfNZi1HSQ A4bpEm24o23fCoTayuANP3RG7p91ZWCy73UOFpsXrGlDJhyXXuUUk57L8Td1dVTqGE QqMx7zWctlVHg2zHVM5GFk/JJcNw4M0KV7vjs9yEPLrAQdLvmK0jdT5zjbjd0ikjFM Zz70PSLp81qDA== Date: Wed, 16 Sep 2026 16:47:29 +0200 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-16d1c6/1789570054-FCA0477B-F5584242/0/0 X-purgate-type: clean X-purgate-size: 3651 Le Wed, Sep 16, 2026 at 04:35:50PM +0200, Frederic Weisbecker a crit : > Le Wed, Sep 16, 2026 at 07:26:35AM -0700, Paul E. McKenney a crit : > > On Wed, Sep 16, 2026 at 02:40:20PM +0200, Frederic Weisbecker wrote: > > > Le Tue, Sep 15, 2026 at 04:56:41PM -0700, Paul E. McKenney a crit : > > > > > Alternatively the approach could be generalized to vanilla RCU, it could be > > > > > possible to define a .text.rcu_no_qs section within which code running is > > > > > considered as an RCU reader (with a pause while on the explicit RCU tasks > > > > > section). It would be forbidden to voluntary sleep inside > > > > > and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). > > > > > > > > > > Based on IP, RCU could consider those interrupted section as readers. This would > > > > > require PREEMPT_RCU though. > > > > > > > > > > And then synchronize_rcu() would do the 1, 2, 4 jobs. > > > > > > > > If I am following correctly (ha!), sleepable BPF programs rule out use > > > > of RCU in this manner. > > > > > > > > But your point is nevertheless valid, in that SRCU could be used. > > > > And because rcu_read_lock_trace() is a thin wrapper around SRCU-fast, we > > > > *might* be able to instead use rcu_read_lock_tasks_trace(), which would > > > > skip the task-struct increment and decrement, saving a few instructions. > > > > Then, instead of waiting for each task's counter to go to zero, instead > > > > just invoke synchronize_rcu_tasks_trace(). > > > > > > > > Which is pretty close to what Josef is proposing, just with the new RCU > > > > Tasks Trace read-side primitives. I think. ;-) > > > > > > > > This assumes that we do not need to flatten partially overlapping RCU > > > > Tasks Trace readers into one big reader. > > > > > > > > Or am I missing something here? > > > > > > Yes I think that's what Josef does in this patchset. The problem is about > > > handling the few instructions: > > > > > > 1) between the begining of the trampoline and the call to rcu_read_lock_trace() > > > > > > 2) between the call to rcu_read_unlock_trace() and the end of the trampoline > > > > > > So what I'm proposing is to make those two parts implicit RCU read lock sections. > > > > > > So the whole trampoline would be .text.rcu_no_qs: > > > > > > .text.rcu_no_qs trampoline: > > > __________________________________________________________________________________________ > > > |Few instructions 1 | rcu_read_lock_trace() .... rcu_read_unlock_trace | Few instructions 2| > > > ___________________________________________________________________________________________ > > > > > > Then when a tick fires, rcu_flavor_sched_clock_irq() discards the interrupted > > > code as QS if the IP was within .text.rcu_no_qs _unless_ it is in the > > > rcu_read_lock_trace. Both are easy and quick to verify. > > > > > > Also preempt_schedule_irq() would make sure to verify the same condition and > > > enqueue the task as a GP blocker if preempting inside "Few instructions 1" > > > or "Few instructions 2". > > > > Ah, OK, I might be following now. ;-) > > > > We also need both versions of rcu_exp_handler() to check the IP as well, > > given that sooner or later someone is going to want trampoline removal > > to go faster. Or am I still missing a turn in here somewhere? > > Yes indeed, missed the exp part! What remains to handle also is non-preemptible RCU because if the task is preempted by an IRQ while in the .text.rcu_no_qs, we may still need to keep track of that somewhere. -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Wed Sep 16 14:55:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 14:55:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423272.1648493 (Exim 4.92) (envelope-from ) id 1x6r2S-0008Sy-Af; Wed, 16 Sep 2026 14:55:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423272.1648493; Wed, 16 Sep 2026 14:55:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6r2S-0008Sr-85; Wed, 16 Sep 2026 14:55:08 +0000 Received: by outflank-mailman (input) for mailman id 1423272; Wed, 16 Sep 2026 14:55:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6r2Q-0008Sk-Fg for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 14:55:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6r2P-006DU2-CX for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 16:55:05 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaaadc7-e002-0a2a0a5209dd-0a2a4502db12-14 for ; Wed, 16 Sep 2026 16:55:05 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaaadc7-6ca4-0a2a45020019-aceafc1f8cfe-3 for ; Wed, 16 Sep 2026 16:55:04 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id DAA3341820; Wed, 16 Sep 2026 14:55:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1D151F000FF; Wed, 16 Sep 2026 14:55:02 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 22DAECE04DE; Wed, 16 Sep 2026 07:55:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789570502; bh=QV82UNlXLIGXwYDB+EGE0wWjQDs7Krio9WNaWSO5xfQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=WzoyCkX6qile7VqKWaszhfBXITo1Vva2+0mj6NaQsOyenrrABW3jFSk/WQfJacLrS swxPQeQStUtlNnTb+NFoYnsOzLHKbKCy1SDiJA95sbZqsJQVCBqHLPLNYZvvlIv8wQ erkCQQ0YASVigmBa6cSO5aiMovZ7W2Gekrh9Y1mcwIOBUe0eLhD7Fa4KhblMJQBRXy a7qqgENAA49mGyM3i2AajSuIwgC2KGSJh0IxZtlr6wQmpfStpfaz9d875V82OB/h92 B0Oy45XssMrBhorahUjjMDJS+76TYEIiUGYH0KMWUCQWE0ASKp0vHT5E8Cr30QCw1+ pTumMZ0fkABgw== Date: Wed, 16 Sep 2026 07:55:02 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-720697/1789570505-F3ABD2AC-EC7BDD36/0/0 X-purgate-type: clean X-purgate-size: 4276 On Wed, Sep 16, 2026 at 04:47:29PM +0200, Frederic Weisbecker wrote: > Le Wed, Sep 16, 2026 at 04:35:50PM +0200, Frederic Weisbecker a crit : > > Le Wed, Sep 16, 2026 at 07:26:35AM -0700, Paul E. McKenney a crit : > > > On Wed, Sep 16, 2026 at 02:40:20PM +0200, Frederic Weisbecker wrote: > > > > Le Tue, Sep 15, 2026 at 04:56:41PM -0700, Paul E. McKenney a crit : > > > > > > Alternatively the approach could be generalized to vanilla RCU, it could be > > > > > > possible to define a .text.rcu_no_qs section within which code running is > > > > > > considered as an RCU reader (with a pause while on the explicit RCU tasks > > > > > > section). It would be forbidden to voluntary sleep inside > > > > > > and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). > > > > > > > > > > > > Based on IP, RCU could consider those interrupted section as readers. This would > > > > > > require PREEMPT_RCU though. > > > > > > > > > > > > And then synchronize_rcu() would do the 1, 2, 4 jobs. > > > > > > > > > > If I am following correctly (ha!), sleepable BPF programs rule out use > > > > > of RCU in this manner. > > > > > > > > > > But your point is nevertheless valid, in that SRCU could be used. > > > > > And because rcu_read_lock_trace() is a thin wrapper around SRCU-fast, we > > > > > *might* be able to instead use rcu_read_lock_tasks_trace(), which would > > > > > skip the task-struct increment and decrement, saving a few instructions. > > > > > Then, instead of waiting for each task's counter to go to zero, instead > > > > > just invoke synchronize_rcu_tasks_trace(). > > > > > > > > > > Which is pretty close to what Josef is proposing, just with the new RCU > > > > > Tasks Trace read-side primitives. I think. ;-) > > > > > > > > > > This assumes that we do not need to flatten partially overlapping RCU > > > > > Tasks Trace readers into one big reader. > > > > > > > > > > Or am I missing something here? > > > > > > > > Yes I think that's what Josef does in this patchset. The problem is about > > > > handling the few instructions: > > > > > > > > 1) between the begining of the trampoline and the call to rcu_read_lock_trace() > > > > > > > > 2) between the call to rcu_read_unlock_trace() and the end of the trampoline > > > > > > > > So what I'm proposing is to make those two parts implicit RCU read lock sections. > > > > > > > > So the whole trampoline would be .text.rcu_no_qs: > > > > > > > > .text.rcu_no_qs trampoline: > > > > __________________________________________________________________________________________ > > > > |Few instructions 1 | rcu_read_lock_trace() .... rcu_read_unlock_trace | Few instructions 2| > > > > ___________________________________________________________________________________________ > > > > > > > > Then when a tick fires, rcu_flavor_sched_clock_irq() discards the interrupted > > > > code as QS if the IP was within .text.rcu_no_qs _unless_ it is in the > > > > rcu_read_lock_trace. Both are easy and quick to verify. > > > > > > > > Also preempt_schedule_irq() would make sure to verify the same condition and > > > > enqueue the task as a GP blocker if preempting inside "Few instructions 1" > > > > or "Few instructions 2". > > > > > > Ah, OK, I might be following now. ;-) > > > > > > We also need both versions of rcu_exp_handler() to check the IP as well, > > > given that sooner or later someone is going to want trampoline removal > > > to go faster. Or am I still missing a turn in here somewhere? I should add that the thing that I really like about Frederic's approach is that avoids the task-list scan. Or at least has the potential to do so. Such scans have proven problematic in the past. > > Yes indeed, missed the exp part! > > What remains to handle also is non-preemptible RCU because if the task is > preempted by an IRQ while in the .text.rcu_no_qs, we may still need to keep > track of that somewhere. Perhaps in rcu_core() in kernels booted with use_softirq? I am thinking specifically of the checks for deferred quiescent states. I don't (yet) see a need to modify rcu_check_quiescent_state(). Maybe other places as well. ;-) Thanx, Paul From xen-devel-bounces@lists.xenproject.org Wed Sep 16 15:05:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 15:05:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423291.1648504 (Exim 4.92) (envelope-from ) id 1x6rCH-0002Yb-74; Wed, 16 Sep 2026 15:05:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423291.1648504; Wed, 16 Sep 2026 15:05:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6rCH-0002YU-3c; Wed, 16 Sep 2026 15:05:17 +0000 Received: by outflank-mailman (input) for mailman id 1423291; Wed, 16 Sep 2026 15:05:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6rCF-0002YO-TQ for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 15:05:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6rCF-00AhOQ-9x for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 17:05:15 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaab02a-bab6-0a2a0a5309dd-0a2a45049700-6 for ; Wed, 16 Sep 2026 17:05:15 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaab02b-b57f-0a2a45040019-4a7de48c849b-3 for ; Wed, 16 Sep 2026 17:05:15 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f55efe5so180047866b.2 for ; Wed, 16 Sep 2026 08:05:15 -0700 (PDT) Received: from [10.72.3.60] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c29de454babsm151691266b.12.2026.09.16.08.05.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2026 08:05:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789571115; x=1790175915; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=WKwD5CEyyczDXC7rMb4uQ85VEJAd/Vp60j6HWY+K1ww=; b=COIn+Y9e4i2uweasTeGf22VKAD+c3ifC7+oxgHRmUi4dxczCaUIxrOSac/8GxfT7OS +89Gt8aQGHbFQCNQnekqr+HXqqMtzDbWYRZYZ4tcc2Vsl80HJkz++899hl+v4ehIbsnd PiW7A0r6zAHcE7RrkgN7NJZ3v8dBc4YPDWIOnysDCzVvRImSLJQwqj2Khw3G3MynBdrR MX8msArnQ0IYubJIe9dyKmwqeal1PYiJFskQbHacT+7DczqE3EFs7wBH279fIUK7KVfi a+3+CDpvmdtb7Yg9Dko+mIzuymujnI2js0mW0NOcnqYK0X8HGLlVQmSGjKHFX8Rl8S0A pqcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789571115; x=1790175915; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=WKwD5CEyyczDXC7rMb4uQ85VEJAd/Vp60j6HWY+K1ww=; b=Beq5/Pr8jY+hGcZuqfZaGmYpHdEnMnIWMGB6xZTBcFi2ZOhf6pHeoDZpFPwtYVcEH5 R2NbXZxsgsVBxBgXu15XxeWNXnYCwchx1R/IZaNjt4jKGalrYHgmlBxtqHyzVR4xxvQc AK/o5/yHUoLTZquQ2oXcW+jhvnxvvbgBcjMs/Iu/czn+TPQAR9cyGCH+WKX8FCoQRVFu vh7IAsHGTcy08CU/Ij+HdMTbl/1pX+5BrhtYKsC6utWIRbXw1XS4LtMdLp00cMNkpqEi hUbhWbPifJ/3FMRNs5uSKg3pL4rJNEEUz15pJGTvGza+sSov/5BFUMK5vlAd45YJbhKb vOOQ== X-Gm-Message-State: AFuF++mcPMqioPi6AWlXKcDH/ueYTBbi3y92zBu0rWPwoY2R6p8yzvdg /LkRL5KBeAObk3TB7gaQvBDaNwP/MKEH+/DHQihWGFt2gHsIjWT/U/wlB21JqjwUeQ== X-Gm-Gg: AYBFou144uTHCP1Vw6nUF+GSUWAkfnRTjndOcyYuMgy8jZD5uHJO1PsMElgiKE0mRu8 Q/Z7FxuKHB73DoOyFal9ChOK7DW601MgdyEc91dNXK95PyudRE34LoQ9GXKIs4/QPd15+L5Y2oj r2OCYZ/IQnncbfD1CFAjAZGBycMMlZ/9J6nvsa50rYuVYE/dx7uzK+K6a1tCGD5X+8qgZWDaoyD S/qq1n/atpWXs8L1icp0Ol5tnXJEvSoWuoVmHbuQlqnoe+bg3WmNHhFow3CXNCC93Lr1iS34xIA 3sUoETdR7vI1Rr9PGq4T8UkoW9tqyFwnoCtZJbMr5msfjSObdZ1jwjrUQ6ASZ4RT85hRPdCLsVc Uax5VD1UOBpeBk+JzcLMoSnppdcnqFr1tQVEyUDg1crQE0GBIc/PcyFyxowI6U39oxZgnu03vM2 vEZGMyP2BDKsHIPX/CylU8RNNXoKdn34zmQeg8SAjGKTJz/RL8ZhIYtUmgFGJtt5uQ0kUNn+uPi Q== X-Received: by 2002:a17:907:9343:b0:c29:62d8:68af with SMTP id a640c23a62f3a-c29e5311f45mr201016966b.47.1789571114597; Wed, 16 Sep 2026 08:05:14 -0700 (PDT) Message-ID: <64821a66-6726-449e-b1f4-2d8750e99f95@suse.com> Date: Wed, 16 Sep 2026 17:05:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] EFI: avoid OOB config file reads To: George Dunlap Cc: "xen-devel@lists.xenproject.org" , Marek Marczykowski , Daniel Smith , Andrew Cooper References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1789571115-502E4B50-458FC1F8/0/0 X-purgate-type: clean X-purgate-size: 1263 On 16.09.2026 16:37, George Dunlap wrote: > On Wed, Mar 25, 2026 at 2:24 PM Jan Beulich wrote: >> @@ -878,6 +882,23 @@ static bool __init read_section(const EF >> >> file->ptr = ptr; >> >> + /* For cfg file, if necessary allocate space to put an extra NUL there. */ >> + if ( file == &cfg && file->size && !iscntrl(file->str[file->size - 1]) ) >> + { >> + EFI_PHYSICAL_ADDRESS addr; >> + EFI_STATUS ret = efi_bs->AllocatePages(AllocateMaxAddress, >> + EfiLoaderData, >> + PFN_UP(file->size + 1), &addr); > > efiapi.h lists the Memory parameter as OUT, but that seems to be a > mistake; the UEFI spec [1] says this is IN OUT; and the other two > callers of AllocatePages in Xen initialize the value before passing it > in. So we should probably fix both efiapi.h, and initialize this to > an appropriate value, rather than passing in stack rubble. Oh, yes, we definitely need to init the variable. I'm less certain about efiapi.h, though, as that's an imported header. We'd need to check gnuefi, and import a possible update from there. I guess I'll leave that part to the maintainers... Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 16 15:23:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 15:23:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423307.1648512 (Exim 4.92) (envelope-from ) id 1x6rU1-0006Tr-N9; Wed, 16 Sep 2026 15:23:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423307.1648512; Wed, 16 Sep 2026 15:23:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6rU1-0006Tk-KS; Wed, 16 Sep 2026 15:23:37 +0000 Received: by outflank-mailman (input) for mailman id 1423307; Wed, 16 Sep 2026 15:23:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6rU1-0006Te-2i for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 15:23:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6rU0-00ApLD-Fh for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 17:23:36 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaab46c-bab6-0a2a0a5309dd-0a2a45059954-22 for ; Wed, 16 Sep 2026 17:23:36 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaab476-4cb1-0a2a45050019-aceafc1fd370-3 for ; Wed, 16 Sep 2026 17:23:36 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 0310C43670; Wed, 16 Sep 2026 15:23:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 341851F000FF; Wed, 16 Sep 2026 15:23:33 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789572213; bh=gUBqB4Fqzqc99qDiZRC6rn2LnblCueCLqVsZm7n7TfU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Zms7zbQMXsV+X5ghNSF6YjMl6cJUjNxOkr2rrVhGM0XFYBR9/EjTqpLFG0bk/C0J+ F29El3ZivUeVL99Zn3f4rNP0UQ71wVGtSaM4Wr/EMConrjhwND2seSG6X9LdI8PKKt wBlIcZKq1r/aZ74++NVwbVmjyfyz5z1nYuTWwX+kD2jkBcYRdj7Mi6GJnPNsh85OIT Wt/c6bCxiBrWxpCWyEuLB8YAvC09SN9sOOK19ICTHSvz2x5HNnAUJXlBqgbo7+D6OZ nx0j/Hi/XmglqjOXV6BadfdwTE/hibURx5tCXMkuCpoOvvLMWTRan6RTc2WQiI6iCr 47EQKZi3eSznQ== Date: Wed, 16 Sep 2026 17:23:31 +0200 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> X-purgate-ID: tlsNG-c201ff/1789572216-F7CB82A1-5A342ED9/0/0 X-purgate-type: clean X-purgate-size: 5102 Le Wed, Sep 16, 2026 at 07:55:02AM -0700, Paul E. McKenney a crit : > On Wed, Sep 16, 2026 at 04:47:29PM +0200, Frederic Weisbecker wrote: > > Le Wed, Sep 16, 2026 at 04:35:50PM +0200, Frederic Weisbecker a crit : > > > Le Wed, Sep 16, 2026 at 07:26:35AM -0700, Paul E. McKenney a crit : > > > > On Wed, Sep 16, 2026 at 02:40:20PM +0200, Frederic Weisbecker wrote: > > > > > Le Tue, Sep 15, 2026 at 04:56:41PM -0700, Paul E. McKenney a crit : > > > > > > > Alternatively the approach could be generalized to vanilla RCU, it could be > > > > > > > possible to define a .text.rcu_no_qs section within which code running is > > > > > > > considered as an RCU reader (with a pause while on the explicit RCU tasks > > > > > > > section). It would be forbidden to voluntary sleep inside > > > > > > > and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). > > > > > > > > > > > > > > Based on IP, RCU could consider those interrupted section as readers. This would > > > > > > > require PREEMPT_RCU though. > > > > > > > > > > > > > > And then synchronize_rcu() would do the 1, 2, 4 jobs. > > > > > > > > > > > > If I am following correctly (ha!), sleepable BPF programs rule out use > > > > > > of RCU in this manner. > > > > > > > > > > > > But your point is nevertheless valid, in that SRCU could be used. > > > > > > And because rcu_read_lock_trace() is a thin wrapper around SRCU-fast, we > > > > > > *might* be able to instead use rcu_read_lock_tasks_trace(), which would > > > > > > skip the task-struct increment and decrement, saving a few instructions. > > > > > > Then, instead of waiting for each task's counter to go to zero, instead > > > > > > just invoke synchronize_rcu_tasks_trace(). > > > > > > > > > > > > Which is pretty close to what Josef is proposing, just with the new RCU > > > > > > Tasks Trace read-side primitives. I think. ;-) > > > > > > > > > > > > This assumes that we do not need to flatten partially overlapping RCU > > > > > > Tasks Trace readers into one big reader. > > > > > > > > > > > > Or am I missing something here? > > > > > > > > > > Yes I think that's what Josef does in this patchset. The problem is about > > > > > handling the few instructions: > > > > > > > > > > 1) between the begining of the trampoline and the call to rcu_read_lock_trace() > > > > > > > > > > 2) between the call to rcu_read_unlock_trace() and the end of the trampoline > > > > > > > > > > So what I'm proposing is to make those two parts implicit RCU read lock sections. > > > > > > > > > > So the whole trampoline would be .text.rcu_no_qs: > > > > > > > > > > .text.rcu_no_qs trampoline: > > > > > __________________________________________________________________________________________ > > > > > |Few instructions 1 | rcu_read_lock_trace() .... rcu_read_unlock_trace | Few instructions 2| > > > > > ___________________________________________________________________________________________ > > > > > > > > > > Then when a tick fires, rcu_flavor_sched_clock_irq() discards the interrupted > > > > > code as QS if the IP was within .text.rcu_no_qs _unless_ it is in the > > > > > rcu_read_lock_trace. Both are easy and quick to verify. > > > > > > > > > > Also preempt_schedule_irq() would make sure to verify the same condition and > > > > > enqueue the task as a GP blocker if preempting inside "Few instructions 1" > > > > > or "Few instructions 2". > > > > > > > > Ah, OK, I might be following now. ;-) > > > > > > > > We also need both versions of rcu_exp_handler() to check the IP as well, > > > > given that sooner or later someone is going to want trampoline removal > > > > to go faster. Or am I still missing a turn in here somewhere? > > I should add that the thing that I really like about Frederic's approach > is that avoids the task-list scan. Or at least has the potential to > do so. Such scans have proven problematic in the past. > > > > Yes indeed, missed the exp part! > > > > What remains to handle also is non-preemptible RCU because if the task is > > preempted by an IRQ while in the .text.rcu_no_qs, we may still need to keep > > track of that somewhere. > > Perhaps in rcu_core() in kernels booted with use_softirq? I am thinking > specifically of the checks for deferred quiescent states. I don't (yet) > see a need to modify rcu_check_quiescent_state(). > > Maybe other places as well. ;-) Hmm this tracking would have to happen on preempt_schedule() just like we do for PREEMPT_RCU. Or am I missing something? And then we would need a list scan of those tasks. Or we can build the blocked task list handling, that we already have for PREEMPT_RCU, when CONFIG_RCU_TASKS && !CONFIG_PREEMPT_RCU. We would just only add tasks when preempted in .text.rcu_no_qs since rcu_read_lock() would still disable preemption on normal explicit readers. So I wouldn't expect more overhead due to that blocked list tracking built since it would rarely track tasks. Thanks. -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Wed Sep 16 15:41:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 15:41:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423332.1648521 (Exim 4.92) (envelope-from ) id 1x6rlV-0001gS-4Y; Wed, 16 Sep 2026 15:41:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423332.1648521; Wed, 16 Sep 2026 15:41:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6rlV-0001gL-1l; Wed, 16 Sep 2026 15:41:41 +0000 Received: by outflank-mailman (input) for mailman id 1423332; Wed, 16 Sep 2026 15:41:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6rlU-0001gF-7E for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 15:41:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6rlT-008Vku-KP for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 17:41:39 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaab8b3-e002-0a2a0a5209dd-0a2a45048198-0 for ; Wed, 16 Sep 2026 17:41:39 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaab8b2-b57f-0a2a45040019-ac6904fe9e6c-3 for ; Wed, 16 Sep 2026 17:41:39 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 601636020C; Wed, 16 Sep 2026 15:41:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0560E1F00898; Wed, 16 Sep 2026 15:41:37 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 89BBFCE04DE; Wed, 16 Sep 2026 08:41:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789573297; bh=sGvzKbFPjf+oPN6Vq1aebGYY5v8J+QGBuqhmyn8aUVA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=KIYUEz2FGcRHG+Ssklm2bHmtEXBGohs83s4Od39AMcZubOJsE9RcpEkF2MgFpaJyw cRxlDEaoPOVjTBiub0GC4lMMtcPW5Ai2f1xdjaWDEWMvi39Rl+gSqxtwEHJWheUE9m h8vHINDZAmYdg6E6FA6HEIujkaLUYdjPBXyiGd3emqo+GbGuJoiOmurbsPEcPhZ39A HzIPstpdtUBGHOY7LAsWpCzyaUAh+S2igBzAKhzvbQRIoKHL6/ON5LVD5FfW5y58Al UD8E7AGKumNniUj/FyucyAAXgQ+SyVefcwHGcFDMHxy4FOBWJ/JdVyW3WqSbC4G+Bq /anXSiz9gu+gQ== Date: Wed, 16 Sep 2026 08:41:36 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-ebf023/1789573299-516D2B50-6DA1D1A6/0/0 X-purgate-type: clean X-purgate-size: 6533 On Wed, Sep 16, 2026 at 05:23:31PM +0200, Frederic Weisbecker wrote: > Le Wed, Sep 16, 2026 at 07:55:02AM -0700, Paul E. McKenney a crit : > > On Wed, Sep 16, 2026 at 04:47:29PM +0200, Frederic Weisbecker wrote: > > > Le Wed, Sep 16, 2026 at 04:35:50PM +0200, Frederic Weisbecker a crit : > > > > Le Wed, Sep 16, 2026 at 07:26:35AM -0700, Paul E. McKenney a crit : > > > > > On Wed, Sep 16, 2026 at 02:40:20PM +0200, Frederic Weisbecker wrote: > > > > > > Le Tue, Sep 15, 2026 at 04:56:41PM -0700, Paul E. McKenney a crit : > > > > > > > > Alternatively the approach could be generalized to vanilla RCU, it could be > > > > > > > > possible to define a .text.rcu_no_qs section within which code running is > > > > > > > > considered as an RCU reader (with a pause while on the explicit RCU tasks > > > > > > > > section). It would be forbidden to voluntary sleep inside > > > > > > > > and to put explicit preemption points (CONFIG_PROVE_RCU could report misuses). > > > > > > > > > > > > > > > > Based on IP, RCU could consider those interrupted section as readers. This would > > > > > > > > require PREEMPT_RCU though. > > > > > > > > > > > > > > > > And then synchronize_rcu() would do the 1, 2, 4 jobs. > > > > > > > > > > > > > > If I am following correctly (ha!), sleepable BPF programs rule out use > > > > > > > of RCU in this manner. > > > > > > > > > > > > > > But your point is nevertheless valid, in that SRCU could be used. > > > > > > > And because rcu_read_lock_trace() is a thin wrapper around SRCU-fast, we > > > > > > > *might* be able to instead use rcu_read_lock_tasks_trace(), which would > > > > > > > skip the task-struct increment and decrement, saving a few instructions. > > > > > > > Then, instead of waiting for each task's counter to go to zero, instead > > > > > > > just invoke synchronize_rcu_tasks_trace(). > > > > > > > > > > > > > > Which is pretty close to what Josef is proposing, just with the new RCU > > > > > > > Tasks Trace read-side primitives. I think. ;-) > > > > > > > > > > > > > > This assumes that we do not need to flatten partially overlapping RCU > > > > > > > Tasks Trace readers into one big reader. > > > > > > > > > > > > > > Or am I missing something here? > > > > > > > > > > > > Yes I think that's what Josef does in this patchset. The problem is about > > > > > > handling the few instructions: > > > > > > > > > > > > 1) between the begining of the trampoline and the call to rcu_read_lock_trace() > > > > > > > > > > > > 2) between the call to rcu_read_unlock_trace() and the end of the trampoline > > > > > > > > > > > > So what I'm proposing is to make those two parts implicit RCU read lock sections. > > > > > > > > > > > > So the whole trampoline would be .text.rcu_no_qs: > > > > > > > > > > > > .text.rcu_no_qs trampoline: > > > > > > __________________________________________________________________________________________ > > > > > > |Few instructions 1 | rcu_read_lock_trace() .... rcu_read_unlock_trace | Few instructions 2| > > > > > > ___________________________________________________________________________________________ > > > > > > > > > > > > Then when a tick fires, rcu_flavor_sched_clock_irq() discards the interrupted > > > > > > code as QS if the IP was within .text.rcu_no_qs _unless_ it is in the > > > > > > rcu_read_lock_trace. Both are easy and quick to verify. > > > > > > > > > > > > Also preempt_schedule_irq() would make sure to verify the same condition and > > > > > > enqueue the task as a GP blocker if preempting inside "Few instructions 1" > > > > > > or "Few instructions 2". > > > > > > > > > > Ah, OK, I might be following now. ;-) > > > > > > > > > > We also need both versions of rcu_exp_handler() to check the IP as well, > > > > > given that sooner or later someone is going to want trampoline removal > > > > > to go faster. Or am I still missing a turn in here somewhere? > > > > I should add that the thing that I really like about Frederic's approach > > is that avoids the task-list scan. Or at least has the potential to > > do so. Such scans have proven problematic in the past. > > > > > > Yes indeed, missed the exp part! > > > > > > What remains to handle also is non-preemptible RCU because if the task is > > > preempted by an IRQ while in the .text.rcu_no_qs, we may still need to keep > > > track of that somewhere. > > > > Perhaps in rcu_core() in kernels booted with use_softirq? I am thinking > > specifically of the checks for deferred quiescent states. I don't (yet) > > see a need to modify rcu_check_quiescent_state(). > > > > Maybe other places as well. ;-) > > Hmm this tracking would have to happen on preempt_schedule() just like we > do for PREEMPT_RCU. Or am I missing something? And then we would need a > list scan of those tasks. I am thinking of the case where a trampoline is interrupted before entering (or after leaving) its RCU Tasks Trace read-side critical section. Then there is a softirq handler on the back of that interrupt handler, and RCU_SOFTIRQ is invoked, calling rcu_core(). Specifically: /* Report any deferred quiescent states if preemption enabled. */ if (IS_ENABLED(CONFIG_PREEMPT_COUNT) && (!(preempt_count() & PREEMPT_MASK))) { rcu_preempt_deferred_qs(current); } else if (rcu_preempt_need_deferred_qs(current)) { guard(irqsave)(); set_need_resched_current(); } Preemption is enabled, but we should not report a quiescent state because we have interrupted a trampoline. Correct? > Or we can build the blocked task list handling, that we already have for PREEMPT_RCU, > when CONFIG_RCU_TASKS && !CONFIG_PREEMPT_RCU. We would just only add tasks when > preempted in .text.rcu_no_qs since rcu_read_lock() would still disable > preemption on normal explicit readers. So I wouldn't expect more overhead due to > that blocked list tracking built since it would rarely track tasks. Yes, we could avoid the list of tasks by treating the preemption within the trampoline the same as preemption within an RCU read-side critical section, but there might not be an rcu_read_unlock() to clean up. Which could be a problem. Trampolines that transfer control to tracing code could supply the needed cleanup call. But last I checked, there were trampolines that transferred directly back to the original code, with no opportunity for cleaning up. Or am I still missing a trick here? Thanx, Paul From xen-devel-bounces@lists.xenproject.org Wed Sep 16 17:10:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 17:10:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423390.1648530 (Exim 4.92) (envelope-from ) id 1x6t9U-0006SI-2O; Wed, 16 Sep 2026 17:10:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423390.1648530; Wed, 16 Sep 2026 17:10:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6t9T-0006SB-W9; Wed, 16 Sep 2026 17:10:31 +0000 Received: by outflank-mailman (input) for mailman id 1423390; Wed, 16 Sep 2026 17:10:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6t9T-0006S5-22 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 17:10:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6t9S-000Qwm-FG for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 19:10:30 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaacd6d-8faa-0a2a0a5109dd-0a2a4501b3ee-20 for ; Wed, 16 Sep 2026 19:10:28 +0200 Received: from [159.226.251.25] (helo=cstnet.cn) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaacd81-5984-0a2a45010019-9fe2fb19bbb4-3 for ; Wed, 16 Sep 2026 19:10:27 +0200 Received: from dfae2b116770.home.arpa (unknown [36.110.52.2]) by APP-05 (Coremail) with SMTP id zQCowABHsTuAzapqVVJuCA--.22263S2; Thu, 17 Sep 2026 01:10:24 +0800 (CST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Wentao Liang To: boris.ostrovsky@oracle.com Cc: jgross@suse.com, linux-kernel@vger.kernel.org, oleksandr_andrushchenko@epam.com, oleksandr_tyshchenko@epam.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, Wentao Liang , stable@vger.kernel.org Subject: [PATCH] xen/gntdev: Fix gntdev_dmabuf ref leak in dmabuf_exp_wait_released() Date: Wed, 16 Sep 2026 17:09:56 +0000 Message-Id: <20260916170956.2086505-1-vulab@iscas.ac.cn> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:zQCowABHsTuAzapqVVJuCA--.22263S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tw4kAFyfCrWxJw4rtFW5ZFb_yoW8GF1xpr sIqFy8AFZ3t347ta1DJ34Y9ryYyayDtrySkrW5Aws8Zry5Xw1xXF1fJr18XFyqkws3ua4f Aa40yFy3Xr45AFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvY14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r 4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2Wl Yx0E2Ix0cI8IcVAFwI0_JF0_Jw1lYx0Ex4A2jsIE14v26r4j6F4UMcvjeVCFs4IE7xkEbV WUJVW8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lc7CjxVAaw2AF wI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43 MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_JFI_Gr1lIxAIcVC0I7IYx2IY6xkF7I 0E14v26F4j6r4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBIdaVFxhVjvjDU0xZFpf9x0J UgXocUUUUU= X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: pyxotu46lvutnvoduhdfq/1tbiCRIMA2qqozVjiwAAsq X-purgate-ID: tlsNG-d62444/1789578628-1DC79757-B63200B5/0/0 X-purgate-type: clean X-purgate-size: 1349 dmabuf_exp_wait_released() takes a reference on the exported gntdev_dmabuf with dmabuf_exp_wait_obj_get_dmabuf() and passes it to dmabuf_exp_wait_obj_new(), which drops that reference after adding the wait object to the wait list. When the wait object allocation fails, dmabuf_exp_wait_obj_new() returns ERR_PTR(-ENOMEM) early and the reference is never dropped, leaking a reference to the exported gntdev_dmabuf. Drop the reference on the allocation failure path so the reference is consumed whether the wait object is created or not. Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang --- drivers/xen/gntdev-dmabuf.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c index 83b0df460894..df1883aca850 100644 --- a/drivers/xen/gntdev-dmabuf.c +++ b/drivers/xen/gntdev-dmabuf.c @@ -96,8 +96,10 @@ dmabuf_exp_wait_obj_new(struct gntdev_dmabuf_priv *priv, struct gntdev_dmabuf_wait_obj *obj; obj = kzalloc_obj(*obj); - if (!obj) + if (!obj) { + kref_put(&gntdev_dmabuf->u.exp.refcount, dmabuf_exp_release); return ERR_PTR(-ENOMEM); + } init_completion(&obj->completion); obj->gntdev_dmabuf = gntdev_dmabuf; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 17:12:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 17:12:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423397.1648540 (Exim 4.92) (envelope-from ) id 1x6tBE-0006wY-Dm; Wed, 16 Sep 2026 17:12:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423397.1648540; Wed, 16 Sep 2026 17:12:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6tBE-0006wR-AT; Wed, 16 Sep 2026 17:12:20 +0000 Received: by outflank-mailman (input) for mailman id 1423397; Wed, 16 Sep 2026 17:12:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6tBC-0006wJ-RZ for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 17:12:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6tBC-00GGGJ-8b for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 19:12:18 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaacdde-bab6-0a2a0a5309dd-0a2a4509af94-22 for ; Wed, 16 Sep 2026 19:12:16 +0200 Received: from [159.226.251.25] (helo=cstnet.cn) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaacded-be1a-0a2a45090019-9fe2fb1981ba-3 for ; Wed, 16 Sep 2026 19:12:15 +0200 Received: from dfae2b116770.home.arpa (unknown [36.110.52.2]) by APP-05 (Coremail) with SMTP id zQCowAA3oDrpzapqV1xuCA--.22441S2; Thu, 17 Sep 2026 01:12:09 +0800 (CST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Wentao Liang To: Jiqian.Chen@amd.com Cc: jgross@suse.com, linux-kernel@vger.kernel.org, oleksandr_tyshchenko@epam.com, ray.huang@amd.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, Wentao Liang , stable@vger.kernel.org Subject: [PATCH] xen-pciback: Fix pcistub_device ref leak in pcistub_get_gsi_from_sbdf() Date: Wed, 16 Sep 2026 17:11:41 +0000 Message-Id: <20260916171141.2086627-1-vulab@iscas.ac.cn> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:zQCowAA3oDrpzapqV1xuCA--.22441S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKrW8WFWUuF17JF1xKrW7Jwb_yoWkKwcEgr WIvr97urs8tFWxtrW7uwn0vrZav3Z0q395XF1xta4rGw4j9r4UXr1rXF98Wr4Igr45JF13 Xr1DCr93Kr4I9jkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbxkFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8w A2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_ Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr 1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv 7VC0I7IYx2IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r 1j6r4UM4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwCY1x0262kKe7AK xVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F4 0E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFyl IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Cr0_Gr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8 JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7VUb o5l5UUUUU== X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: pyxotu46lvutnvoduhdfq/1tbiBgEMA2qqok9l6QAAsp X-purgate-ID: tlsNG-bad1c0/1789578736-39AC0034-4730C548/0/0 X-purgate-type: clean X-purgate-size: 1205 pcistub_get_gsi_from_sbdf() obtains the stub device with pcistub_device_find(), which returns it with its kref incremented, and returns psdev->gsi without dropping that reference again. The caller cannot release it either, so every lookup leaks one reference to the stub device. Release the reference after reading gsi. Fixes: 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang --- drivers/xen/xen-pciback/pci_stub.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index 79a2b5dfd694..d1a335233aab 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -234,13 +234,16 @@ static int pcistub_get_gsi_from_sbdf(unsigned int sbdf) int bus = PCI_BUS_NUM(sbdf); int slot = PCI_SLOT(sbdf); int func = PCI_FUNC(sbdf); + int gsi; psdev = pcistub_device_find(domain, bus, slot, func); - if (!psdev) return -ENODEV; - return psdev->gsi; + gsi = psdev->gsi; + pcistub_device_put(psdev); + + return gsi; } #endif -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 17:31:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 17:31:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423414.1648549 (Exim 4.92) (envelope-from ) id 1x6tTQ-0001ML-0O; Wed, 16 Sep 2026 17:31:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423414.1648549; Wed, 16 Sep 2026 17:31:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6tTP-0001ME-Sf; Wed, 16 Sep 2026 17:31:07 +0000 Received: by outflank-mailman (input) for mailman id 1423414; Wed, 16 Sep 2026 17:31:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6tTO-0001M8-C5 for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 17:31:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6tTM-005Y5P-0t for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 19:31:04 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaad257-bab6-0a2a0a5309dd-0a2a450488aa-2 for ; Wed, 16 Sep 2026 19:31:03 +0200 Received: from [103.168.172.154] (helo=fhigh-a3-smtp.messagingengine.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaad241-b57f-0a2a45040019-67a8ac9ad147-3 for ; Wed, 16 Sep 2026 19:30:42 +0200 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id 2ADD614000F4; Wed, 16 Sep 2026 13:30:41 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Wed, 16 Sep 2026 13:30:41 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Sep 2026 13:30:37 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:Message-ID:MIME-Version:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm1; t=1789579841; x=1789666241; bh=sEzC4k5CJmAV6EJO1XhWjipY2iPMC41J 5KqRauPMcFs=; b=W8z3cBvmX93Pzsm5bNCRiY139GXpeJe1v3Xkn22MstaPsHgy qP3GyTYl3P4a67pLjO1PGEb1dFV1DfPLDykR4z/854lyE6SMAtsArI+Gg3QGFr1n 22KxTFVF9xgnaXFSKcdskfp+stDb1Pu+bcwUl6yYWwE7HdqikOZmXN7S2PksSAiz sgsf43bs4CbOHMqYYAtbePUcusunHBJd3lidU1ECQdq27jC6XHpJWeRCKR2HI0SI 54cDKJ3qD8gY/Pp6ysmC2UYSxTKrj+SIgbfvcG/60mX9CYFf9Ad0K/j/m2WjSNhF kvv8ksUz7PGSeUJLLSMNF+khLrS/fwOUBVeUOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1789579841; x=1789666241; bh=sEzC4k5CJmAV6EJO1XhWjipY2iPM C41J5KqRauPMcFs=; b=TFZUoj1sd5wzq6V92J/uxsf3SSM2ifhX4DsjAgUNlWhU 6eAsn61pwSeiVLgGV7jvmCKRWbXQ6CLYgzqEyQyv759H6AiJGx9yCW0EZQGvSqZA tdLRY4dnewtM5NFNa99MZxpUr+OwHRfifJ+FXNEbp/VePCF8odEsQ7SJjMpAePN6 yl8MXZQOR9wortnzRLC5Cv8WCPbUmDe+qwK+357xalVj0aNXRwvbTbZPLtQprqPe 8fnjP8Nhh2NWHHZ+WzFzG5iiuhGyDesYUDsQAReRN+nca32x16AxG+UqKvyJLZwb e07DMW/szM+5nAcoTmduXKQo+NQgCo0s6D5w4prHYA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFRR2SdzYysCnDldAnwcUjqwv+J1OcwrzewRKc+tpczioQYwLmLsiqEXhmQdC2nje 56bGrrx9GV0swaDUdEK3vzaaVqY+M/XwqVdnxH+XYP25yLI5dgcMCMyHp1UAKHpzlMM6Pa NfKIQqGtUlBxkueH0hJjWk2FklFgBKXLz2xRvyNL8MinjeW04yJe6UQoDcfj7Fm7GkQqjv hWMDmiLq+BTLEM4gbkW/awJ3xlxmRvUzWx2Z1pfR7j7X/jzaQ8xRnBoS7gvzb3G9bG0ct3 i24Lbjgm0XtyjqxFcsT4bz5ya9cZ4U8Y9gRKqIKKaOSFKm85ALGxH1ylfLgRm2aN/+3adN cUBVfKKQWHA2itOHpXXPGf2EhOirzoD+YJUN8W2J8btmtWKsDaOFNp10yxo1cjCNfqFLCA eetNRPqBIDmnhflwbewQqA80/IE9YIqIzcnlCVJFyqgi/DPFkMyhrMlFDOWWfHiQjIeh9G 89n9QqLFXfGqXXqk99gbjnMCdgUUBVwfGw6Qv0Oj/Sv5b8KJP0y9gIov6j06UeHeBXiu58 ngIpfuaFxt/OlglSkpwlIdfm8koIBhdly2sJuzoiRSESBrEf2tn7hwG3rFYegHCYuFa04F L7fp6z+VojadVcqdg1VI+iW4SHrDfKfNnDMGMAOf0fHuPfqzSNP33fuzmKRg X-ME-Proxy: Feedback-ID: i792e4853:Fastmail From: =?UTF-8?q?Szymon=20Aceda=C5=84ski?= To: intel-xe@lists.freedesktop.org Cc: thomas.hellstrom@linux.intel.com, matthew.brost@intel.com, rodrigo.vivi@intel.com, maarten.lankhorst@linux.intel.com, hch@lst.de, bob.beckett@collabora.com, dri-devel@lists.freedesktop.org, marmarek@invisiblethingslab.com, xen-devel@lists.xenproject.org, =?UTF-8?q?Szymon=20Aceda=C5=84ski?= , stable@vger.kernel.org Subject: [PATCH v2] drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV Date: Wed, 16 Sep 2026 19:30:30 +0200 Message-ID: <20260916173030.3223833-1-accek@invisiblethingslab.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1789579842-C0CDFB50-61F3B139/0/0 X-purgate-type: clean X-purgate-size: 2577 Fix display corruption on Xen PV dom0, where DMA buffers are not guaranteed machine-contiguous, in which case bounce buffering kicks in, breaking xe's memory coherency assumptions. Apply the same workaround i915 carries in i915_sg_segment_size() since commit 78a07fe777c4 ("drm/i915: stop abusing swiotlb_max_segment"). Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Marek Marczykowski-Górecki Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8382 Link: https://lore.kernel.org/xen-devel/aYtznP_tT6xNPwf-@mail-itl/ Link: https://lore.kernel.org/all/20221020110308.1582518-1-hch@lst.de/ # i915 counterpart Cc: Christoph Hellwig Cc: Robert Beckett Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Szymon Acedański --- v2: - Imperative language in the commit message (Thomas Hellström) - CC the authors of the original i915 workaround (Thomas Hellström) drivers/gpu/drm/xe/xe_bo.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h index 290ca62..341fa93 100644 --- a/drivers/gpu/drm/xe/xe_bo.h +++ b/drivers/gpu/drm/xe/xe_bo.h @@ -9,6 +9,8 @@ #include #include +#include + #include "xe_bo_types.h" #include "xe_ggtt.h" #include "xe_macros.h" @@ -574,6 +576,23 @@ static inline unsigned int xe_sg_segment_size(struct device *dev) struct scatterlist __maybe_unused sg; size_t max = BIT_ULL(sizeof(sg.length) * 8) - 1; + /* + * For Xen PV guests pages aren't contiguous in DMA (machine) address + * space. The DMA API takes care of that both in dma_alloc_* (by + * calling into the hypervisor to make the pages contiguous) and in + * dma_map_* (by bounce buffering). But xe (like i915, see commit + * 78a07fe777c4) ignores the coherency aspects of the DMA API and thus + * can't cope with bounce buffering actually happening, so add a hack + * here to force small allocations and mappings when running in PV + * mode on Xen. + * + * Note this will still break if bounce buffering is required for other + * reasons, like confidential computing hypervisors or PCIe root ports + * with addressing limitations. + */ + if (xen_pv_domain()) + return PAGE_SIZE; + max = min_t(size_t, max, dma_max_mapping_size(dev)); /* base-commit: baafc300cd079a5210c1e70e5ea3d93518e40b38 -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 16 17:51:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 17:51:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423430.1648556 (Exim 4.92) (envelope-from ) id 1x6tms-0004Fz-Dk; Wed, 16 Sep 2026 17:51:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423430.1648556; Wed, 16 Sep 2026 17:51:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6tms-0004Fs-BD; Wed, 16 Sep 2026 17:51:14 +0000 Received: by outflank-mailman (input) for mailman id 1423430; Wed, 16 Sep 2026 17:51:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6tmp-0004Fm-Sp for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 17:51:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6tmo-008mBh-Qd for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 19:51:10 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaad70e-8faa-0a2a0a5109dd-0a2a4507a180-0 for ; Wed, 16 Sep 2026 19:51:10 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaad70e-b4ea-0a2a45070019-416d716cc8a8-3 for ; Wed, 16 Sep 2026 19:51:10 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 99E4540E00E8; Wed, 16 Sep 2026 17:51:09 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9zV9muLWubjt; Wed, 16 Sep 2026 17:51:04 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 6DA8240E00B9; Wed, 16 Sep 2026 17:49:32 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1789581064; bh=or2++1LeeipZYCb3G9WRgyA4slOHEhMs91sMxm37PrE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E7FjhsZ1898C+iRkHA2e9itQoyiqH/Ch3CRAiwQscnU0CXAU1B3A58i/8qF7CWRQh G9fmEyLGGIFdYQql64Uc91Gneuv+SDG6aDTZnURc3lGHscWFc5r5ZPh1vPnn+mqjo9 KFHhO1O53B1kflUQZ5pwBl1X+TZ/YeOf6S4ukWau6F9Oy2bvc2AkWVFtpJFZA/d20Q giWI8kOs24tcni/YN9qyJ2ifRbE9E3/xTzGmQUWsiuXTEhyoEZljOUczoL/sJ+VORm Jkvi5hPfZD2JyHdgx2JTUeJM+9EfC5lNAKlo3wpXrtxjuZdy0HbqzBa/nrDlGGXUEB T6ChTVHnrHjzueQm9iG6UjvNvWs1Ci2nBGXVxdIW5G0N5g5YvMPiyWBQmN/KIt+8BJ 4nMWbx4zbda4r5Pe4F71yKd9gdBn5WVrThXpykty5Y9ZS6rxK/Zy/4imk+qiuwIQBK +J/Y7B2Xd/vbfAw0NWAJZRMYwlCrFpuzM/A8ynROZCZpyn7YbI8CMVxBS6k2Zrpwya T6Y4mlUo4kZxEKXRc1Vy6jsORFjfP4A+DtCjZKq1wSzIccfVVxpJX103Kp6LkYYPGE WV11UFcMReR+2ndH81MYlmJrtQ8QF3VCSlMJid4YqIKWMK9eHGy2UwsKc4B1bjlrvo ZcjWPKxqQS0jjFQdEECxxF+M= Date: Wed, 16 Sep 2026 10:49:29 -0700 From: Borislav Petkov To: Alexey Kardashevskiy Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Catalin Marinas , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , Liam Merwick , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , Carlos =?utf-8?B?TMOzcGV6?= , Jonathan Cameron , Jori Koolstra , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , David Howells , Haavard Skinnemoen , Kenji Kaneshige , Ilpo =?utf-8?B?SsOkcnZpbmVu?= , Christian Marangi , Dave Jiang , Michael Kelley , Ilias Stamatis , Sumanth Korikkar , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , Palmer Dabbelt , linux-coco@lists.linux.dev, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, linux-mm@kvack.org, aik@ozlabs.ru, Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: Re: [RFC PATCH kernel 01/17] pci/dma/tsm: Call disable DMA bus hook on cleanup Message-ID: <20260916174929.GCaqrWqZ1fIhi4Rgbn@fat_crate.local> References: <20260916115159.1938195-1-aik@amd.com> <20260916115159.1938195-2-aik@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260916115159.1938195-2-aik@amd.com> X-purgate-ID: tlsNG-ef75cf/1789581070-A5AC0AE4-D8657EAE/0/0 X-purgate-type: clean X-purgate-size: 434 On Wed, Sep 16, 2026 at 09:51:41PM +1000, Alexey Kardashevskiy wrote: > + if (device_tcb_trusted(dev)) Where is that function and the rest of the gunk needed for me to apply before I review those? The patches on that branch: https://github.com/AMDESE/linux-kvm/commits/tsm-next which come before those here are enough? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Wed Sep 16 20:36:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 16 Sep 2026 20:36:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423485.1648566 (Exim 4.92) (envelope-from ) id 1x6wMM-00072U-AZ; Wed, 16 Sep 2026 20:36:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423485.1648566; Wed, 16 Sep 2026 20:36:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6wMM-00072N-74; Wed, 16 Sep 2026 20:36:02 +0000 Received: by outflank-mailman (input) for mailman id 1423485; Wed, 16 Sep 2026 20:36:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6wML-00072H-Ei for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 20:36:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6wMK-0094aC-1C for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 22:36:00 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaafd92-8faa-0a2a0a5109dd-0a2a45068692-40 for ; Wed, 16 Sep 2026 22:36:00 +0200 Received: from [74.125.229.204] (helo=mail-lf2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaafdaf-195a-0a2a45060019-4a7de5cced33-3 for ; Wed, 16 Sep 2026 22:35:59 +0200 Received: by mail-lf2-f12.google.com with SMTP id 2adb3069b0e04-5b5e4f15d00so32350e87.2 for ; Wed, 16 Sep 2026 13:35:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1789590959; cv=none; d=google.com; s=arc-20260327; b=jSpGaMOONZt1Cwa9eRnC2JXc3qSoXDOgdEehjmPY7cGnLoFeIIqJZQodNLL75B1Yp/ jFbv3J7PhdvRsUmkD23pQVJO644jNJcWZDRlOX+Iea4OrlItvFF4XijgSoyJ+FLp2KwQ vfOMob/hi/h9fqTS758+dXDF7U2IoX+yaOyyeSWWTVVZJ1KGwVrQoUKUqI7QKiKRvRn3 LUAw5IxGVnZkSRLBPbW+ExA38/I7hiBTddQ+RlzYTZOzwUJZyK2TF9p/ALKz1oNq+eNe MiL6vhPWXZGruV4U+Or4bjPH8eshhp9FQn0j4lJC3MKs4eNsYFp/69oW6iIYFhM+eo7x sLsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=wNCZPSbPYJyFVLNjgBg2eGFHgK4UGL4TNgHPrNNY8gE=; fh=quJY5mN2l4ZorNvEoO9ngNXalhEvTdq/+W8CvHWhECs=; b=qeOYO8yvyOAdEOXVCw7EeD0F6RJ3+zbC4AGaNmwIX47Kte0RensKELhAKm6wuV7pHd p3KxnUzLzReSP0npTT91/cwVwlzHr17kRKiC1WNmDB5hUo90GoaUlIYDU7+KjXKQt9oC LtB3xNx3NVl3xK9a35D2fNze2b6vvXFdzPAEaAwD9ILbkDxtX3P0PBzyzcfH9EYs4s5i VgMBX6glnUQKw0jFJVQYqvVv0GZ04mcGQOpVomdJFbP9vN4lu4DlRJFhfgOuhABfzoZ1 JnPx7EHjY8n+steY2s0MfDtSw4mlnrHc4iNURMX+zQxopXGDpmLJoakRBGqGMlrQ8qR3 e9RQ==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789590959; x=1790195759; darn=lists.xenproject.org; h=content-type:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wNCZPSbPYJyFVLNjgBg2eGFHgK4UGL4TNgHPrNNY8gE=; b=SyGGb17tFg5AdaAfxVfiy5d+QK3SSFVFSlq0Cx8qTdHWBs6ZL2WBJ8aLHkzE75xSUl +sSupMxBu0SipZwAWS8IzmyUXz9o9zTTjqONqQGy9hqyswbZY5bKWuY8KjO4cLo/vmnn P94OLr95x94iNW6PKFvjqod7yMRNg1GDk6LLx5tPnfpq++vK5dSz9haQtfYSTpn+OWmR yhqSIQbanD/iol0eqar1riC/QVfzjlrf5XTS45W1Fcwbgw4/KHW2kYIOGP0BHkIEOkzs 7vEEoQsGKZ6vTfHv8RntBJYVMPDZATWyMmHtJPuVDJC6Yovcjnd9LIXG2qG4SaIQtUuZ he6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789590959; x=1790195759; h=content-type:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=wNCZPSbPYJyFVLNjgBg2eGFHgK4UGL4TNgHPrNNY8gE=; b=DETeGthB0X+ZiulZQV62mfhzoSX74On7Ofk+fyXn/bkVDPmatowIbbFt3GpNvVTI5c 6mKTJL8obgJu7hiwcbApD7dkHzpu0IYICURzSExChFitmBcsEejAFBbws39dfNU9/A6P 7bL1ZbfyuEwmuzkmBOF2GzWj+yKT5KlvvnbJih+BAitNs+Li4SN3x11KqvIUYWPcLkve dFHjgFojePkOR/pPZjhX2+mYZqPV/QX1TxkDuDxYp/+BgFpgDtST4QOfBLX0/G3qBPko anN3KFP1+YFNZYJOYVfA+tsTMpLERk1GCtTpAjzZKtolftDVtfNsruJcPA+z4UVtfWtE CeSw== X-Gm-Message-State: AFuF++n13QmnW/EajXJPP/EbY2FT4f96IqUlSccxn4zI+dO4TwlvABGB UCIbZkxG0wEMRsPih+GYu3IG+QtfnvMyu8pQVFSwHLiw20hvN0tWMGW2KVJy0FQL7L2G5n2QULT dbq0oZFNWYsoi5H9hYgCKYR2fx74h4T84lQi0pP0IQg== X-Gm-Gg: AYBFou2LWBwZNXDARvt6sYFZfElCkUP38cHo2WmyGOKUWZ/pjVjKmF6m/XQieOmVjPV EGojnyI3fwSgj4mxVnCeARNvyh1Q1p4jf9jipgMKkguTeSJ9WFtS8/c4NizBZp3IP3QCk6k2Mfs FcxLep7qL0s6DaqyPdHB78+Z4b3KeDQPGmhkv9QfHI9FVd3rDTQfKwsNJXwY2u0iMtBS8KuzAMH YjQkr7/l0d8UnphpvmlXnQ+Z3tglfI5jZy13hnnmG+/xw9AKRkWr5P1VHiZBsWxBOrnekw6Suxm g3lNIJzGt8z8/FjTtzU3TuF+PW6VwCJYhUAnt8HQ/tD1rFmdj24KLM7Y2LrZt/jmiuWbsvHsncN NryJE5w0PVnMqDJ+g4sy6auw7RZms5TLn3mDZEg== X-Received: by 2002:a05:6512:3345:b0:5b0:1ace:3bec with SMTP id 2adb3069b0e04-5b8b6605fa1mr1064310e87.10.1789590958898; Wed, 16 Sep 2026 13:35:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anton Markov Date: Wed, 16 Sep 2026 23:35:47 +0300 X-Gm-Features: AcwNN1XHUIOQnMc8cFGclGWK3Pp4BPSJqFjssZueWZRpIpoYyTgXf-k6gYCMEf0 Message-ID: Subject: Re: [BUG] xen-swiotlb: 32-bit coherent DMA mask rejected on PV dom0 since 6.6 (CONFIG_SWIOTLB_DYNAMIC), aacraid probe fails To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000660429065b9f9df7" X-purgate-ID: tlsNG-16d1c6/1789590959-F7CCD77B-5CA3DFDE/0/0 X-purgate-type: clean X-purgate-size: 21272 --000000000000660429065b9f9df7 Content-Type: text/plain; charset="UTF-8" Follow-up with a second reproduction on different hardware, an exact explanation of the failing check, and a tested patch. My first analysis was incomplete: the problem is not that the top of RAM lies above 4 GiB. On a PV dom0 the pseudo-physical address that default_swiotlb_limit() returns usually has no machine frame behind it at all, so *every* mask below 64 bits is rejected. That also explains the July 2024 megaraid_sas report where a 63-bit mask failed: https://lkml.iu.edu/hypermail/linux/kernel/2407.3/08254.html Second reproduction ------------------- Xen: 4.21.2-pre, xen.efi via systemd-boot, PV dom0 Hardware: ASUS N550JX, Core i7-4720HQ (Haswell), 16 GiB RAM dom0: Arch Linux kernel 7.2.6-arch2-1 rebuilt with CONFIG_SWIOTLB_DYNAMIC=y and nothing else changed (the stock Arch config has it disabled and is fine) Memory: host e820 top 0x42f1fffff, dom0 nr_pages 0x3c8783 (no dom0_mem= on the Xen command line) With the SWIOTLB_DYNAMIC kernel every driver that asks for less than a 64-bit mask fails to probe: i915 0000:00:02.0: [drm] *ERROR* Can't set DMA mask/consistent mask (-5) i915 0000:00:02.0: probe with driver i915 failed with error -5 iwlwifi 0000:04:00.0: No suitable DMA available iwlwifi 0000:04:00.0: probe with driver iwlwifi failed with error -5 i915 requests a 40-bit mask on this platform, iwlwifi 36 bits with a 32-bit fallback. ahci, xhci_hcd and mei_me request 64 bits and work. The same kernel booted natively is fine, and the stock kernel without SWIOTLB_DYNAMIC is fine as dom0. What the check evaluates to --------------------------- I wrote a small out-of-tree module that calls dma_set_mask() / dma_set_coherent_mask() on an unbound PCI device for a range of widths and also prints what xen_swiotlb_dma_supported() is comparing against (pfn of high_memory - 1, its p2m entry, the resulting DMA address). Output on the SWIOTLB_DYNAMIC dom0 kernel: dmamask_test: xen-pv: high_memory-1 paddr=0x000000042f1fffff pfn=0x42f1ff mfn=0xffffffffffffffff (INVALID_P2M_ENTRY: unpopulated) nr_pages=0x3c8783 dmamask_test: xen-pv: highest populated pfn below it=0x41a8b6 mfn=0x37491a; SWIOTLB_DYNAMIC limit dma addr=0xffffffffffffffff -> smallest passing mask=64 bits dmamask_test: 32-bit dma_set_mask=FAIL(-5) dma_set_coherent_mask=FAIL(-5) dmamask_test: 33-bit dma_set_mask=FAIL(-5) dma_set_coherent_mask=FAIL(-5) dmamask_test: 34-bit dma_set_mask=FAIL(-5) dma_set_coherent_mask=FAIL(-5) dmamask_test: 35-bit dma_set_mask=FAIL(-5) dma_set_coherent_mask=FAIL(-5) dmamask_test: 36-bit dma_set_mask=FAIL(-5) dma_set_coherent_mask=FAIL(-5) dmamask_test: 40-bit dma_set_mask=FAIL(-5) dma_set_coherent_mask=FAIL(-5) dmamask_test: 48-bit dma_set_mask=FAIL(-5) dma_set_coherent_mask=FAIL(-5) dmamask_test: 64-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) Identical result for three different devices (00:02.0, 01:00.0, 04:00.0), so it is not device specific. On the stock kernel without SWIOTLB_DYNAMIC all widths pass. The chain is: swiotlb_init_remap(..., SWIOTLB_ANY, xen_swiotlb_fixup) -> io_tlb_default_mem.phys_limit = virt_to_phys(high_memory - 1) default_swiotlb_limit() -> phys_limit (with SWIOTLB_DYNAMIC) xen_swiotlb_dma_supported() -> xen_phys_to_dma(dev, limit) <= mask xen_phys_to_bus() -> pfn_to_bfn(0x42f1ff) pfn_to_mfn() -> INVALID_P2M_ENTRY (~0UL) bfn << PAGE_SHIFT | offset -> 0xffffffffffffffff high_memory on a PV dom0 covers the whole host e820 map, while dom0 only owns nr_pages frames of it. The top of the pseudo-physical space is normally unpopulated (here everything above pfn 0x41a8b6 is a hole; Xen itself and the reserved regions live above dom0's last frame). The p2m lookup for such a pfn yields INVALID_P2M_ENTRY, which xen_phys_to_bus() shifts into an all-ones bus address, and only a 64-bit mask can cover that. Whether the last pfn happens to be populated depends on the host memory map and on dom0_mem, which is why the symptom varies between "32-bit masks fail" (my Supermicro report) and "everything below 64 bits fails" (this laptop, the 2024 megaraid_sas report). Before v6.6 the comparison used io_tlb_default_mem.end - 1, i.e. the end of the default pool. That pool has been made machine-contiguous and placed below 4 GiB by xen_swiotlb_fixup(), so its machine address is meaningful and small. On this box the pool is mapped at pseudo-physical 0x405600000-0x409600000 (64 MiB) and its machine frames are below 4 GiB. Why the old value is still the right one ---------------------------------------- phys_limit only describes where *additional* pools may be allocated when the default pool is allowed to grow. Xen always passes a remap callback to swiotlb_init_remap(), and that clears can_grow, so under Xen every bounce buffer comes from the default pool forever. Translating high_memory - 1 through the p2m therefore answers a question that never matters for Xen, and answers it with a value that has no relation to any address a device could be handed. The minimal change I suggested in the first mail (io_tlb_default_mem.defpool.end - 1 in xen_swiotlb_dma_supported()) no longer compiles as is: io_tlb_default_mem has been static in kernel/dma/swiotlb.c since the same series. The equivalent fix at the place where the information lives is to have default_swiotlb_limit() return the default pool end whenever the pool cannot grow. That is a no-op for every non-Xen SWIOTLB_DYNAMIC user (they never pass remap, so can_grow stays true) and restores the pre-6.6 behaviour for Xen. Test result with the patch below -------------------------------- Same laptop, same config plus the patch, booted as PV dom0: dmamask_test: xen-pv: high_memory-1 paddr=0x000000042f1fffff pfn=0x42f1ff mfn=0xffffffffffffffff (INVALID_P2M_ENTRY: unpopulated) nr_pages=0x3c8783 dmamask_test: 32-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) dmamask_test: 33-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) dmamask_test: 34-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) dmamask_test: 35-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) dmamask_test: 36-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) dmamask_test: 40-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) dmamask_test: 48-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) dmamask_test: 64-bit dma_set_mask=ok(0) dma_set_coherent_mask=ok(0) The p2m situation is unchanged (top pfn still unpopulated), but the check now uses the default pool end. i915 and iwlwifi probe normally, display and WiFi work, no DMA related messages in dmesg: software IO TLB: mapped [mem 0x0000000405600000-0x0000000409600000] (64MB) iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 7260 iwlwifi 0000:04:00.0: loaded firmware version 17.bfb58538.0 7260-17.ucode op_mode iwlmvm I have not yet re-tested the aacraid machine from the first mail, but it is the same check with the same input, so I expect the same result. Happy to confirm on that box if useful. Patch ----- From: Anton Markov Subject: [PATCH] swiotlb: report the default pool end as limit when the pool cannot grow Since the CONFIG_SWIOTLB_DYNAMIC work, default_swiotlb_limit() returns io_tlb_default_mem.phys_limit, which swiotlb_init_remap() sets to virt_to_phys(high_memory - 1) when SWIOTLB_ANY is passed. The only caller, xen_swiotlb_dma_supported(), compares the machine address of that value against the mask a driver asks for. On a Xen PV dom0 high_memory covers the whole host e820 map while dom0 owns only nr_pages of it, so the last pseudo-physical frame is normally not populated. pfn_to_mfn() returns INVALID_P2M_ENTRY for it and xen_phys_to_dma() turns that into 0xffffffffffffffff. The result is that only a full 64-bit mask is accepted: i915 (40 bits), iwlwifi (36 bits), aacraid and megaraid_sas (32/63 bits) all fail to probe. Before v6.6 the end of the default pool was used and these worked. Xen always passes a remap callback, which clears can_grow, so the default pool is the only place bounce buffers can ever come from. phys_limit only matters for allocating further pools. Return the end of the default pool whenever the pool cannot grow. Signed-off-by: Anton Markov --- --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -1680,10 +1680,18 @@ phys_addr_t default_swiotlb_limit(void) { #ifdef CONFIG_SWIOTLB_DYNAMIC - return io_tlb_default_mem.phys_limit; -#else - return io_tlb_default_mem.defpool.end - 1; + /* + * phys_limit bounds where additional pools may be allocated. If the + * default pool can never grow (a remap callback was given at init, + * e.g. by Xen), all bounce buffers live in the default pool and its + * end is the real limit. phys_limit would be high_memory - 1 in + * that case, which on a Xen PV domain is a pseudo-physical address + * that typically has no machine frame behind it at all. + */ + if (io_tlb_default_mem.can_grow) + return io_tlb_default_mem.phys_limit; #endif + return io_tlb_default_mem.defpool.end - 1; } #ifdef CONFIG_DEBUG_FS The test module (GPL, ~120 lines) is available on request; it takes a bdf= parameter, probes the mask widths listed above and restores the original masks afterwards. Thanks, Anton --000000000000660429065b9f9df7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Follow-up with a second reproduction on d= ifferent hardware, an exact
explanation of the failing check, and a test= ed patch.

My first analysis was incomplete: the problem is not that = the top of
RAM lies above 4 GiB. On a PV dom0 the pseudo-physical addres= s that
default_swiotlb_limit() returns usually has no machine frame behi= nd it
at all, so *every* mask below 64 bits is rejected. That also expla= ins
the July 2024 megaraid_sas report where a 63-bit mask failed:
https= ://lkml.iu.edu/hypermail/linux/kernel/2407.3/08254.html

Second r= eproduction
-------------------

=C2=A0 Xen: =C2=A0 =C2=A0 =C2=A04= .21.2-pre, xen.efi via systemd-boot, PV dom0
=C2=A0 Hardware: ASUS N550J= X, Core i7-4720HQ (Haswell), 16 GiB RAM
=C2=A0 dom0: =C2=A0 =C2=A0 Arch = Linux kernel 7.2.6-arch2-1 rebuilt with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 CONFIG_SWIOTLB_DYNAMIC=3Dy and nothing else changed
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (the stock Arch config has it disabled a= nd is fine)
=C2=A0 Memory: =C2=A0 host e820 top 0x42f1fffff, dom0 nr_pag= es 0x3c8783
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (no dom0_mem=3D on= the Xen command line)

With the SWIOTLB_DYNAMIC kernel every driver = that asks for less than a
64-bit mask fails to probe:

=C2=A0 i915= 0000:00:02.0: [drm] *ERROR* Can't set DMA mask/consistent mask (-5)=C2=A0 i915 0000:00:02.0: probe with driver i915 failed with error -5
= =C2=A0 iwlwifi 0000:04:00.0: No suitable DMA available
=C2=A0 iwlwifi 00= 00:04:00.0: probe with driver iwlwifi failed with error -5

i915 requ= ests a 40-bit mask on this platform, iwlwifi 36 bits with a
32-bit fallb= ack. ahci, xhci_hcd and mei_me request 64 bits and work.
The same kernel= booted natively is fine, and the stock kernel without
SWIOTLB_DYNAMIC i= s fine as dom0.

What the check evaluates to
---------------------= ------

I wrote a small out-of-tree module that calls dma_set_mask() = /
dma_set_coherent_mask() on an unbound PCI device for a range of widths=
and also prints what xen_swiotlb_dma_supported() is comparing against(pfn of high_memory - 1, its p2m entry, the resulting DMA address).
Ou= tput on the SWIOTLB_DYNAMIC dom0 kernel:

=C2=A0 dmamask_test: xen-pv= : high_memory-1 paddr=3D0x000000042f1fffff pfn=3D0x42f1ff mfn=3D0xfffffffff= fffffff (INVALID_P2M_ENTRY: unpopulated) nr_pages=3D0x3c8783
=C2=A0 dmam= ask_test: xen-pv: highest populated pfn below it=3D0x41a8b6 mfn=3D0x37491a;= SWIOTLB_DYNAMIC limit dma addr=3D0xffffffffffffffff -> smallest passing= mask=3D64 bits
=C2=A0 dmamask_test: 32-bit =C2=A0dma_set_mask=3DFAIL(-5= ) =C2=A0dma_set_coherent_mask=3DFAIL(-5)
=C2=A0 dmamask_test: 33-bit =C2= =A0dma_set_mask=3DFAIL(-5) =C2=A0dma_set_coherent_mask=3DFAIL(-5)
=C2=A0= dmamask_test: 34-bit =C2=A0dma_set_mask=3DFAIL(-5) =C2=A0dma_set_coherent_= mask=3DFAIL(-5)
=C2=A0 dmamask_test: 35-bit =C2=A0dma_set_mask=3DFAIL(-5= ) =C2=A0dma_set_coherent_mask=3DFAIL(-5)
=C2=A0 dmamask_test: 36-bit =C2= =A0dma_set_mask=3DFAIL(-5) =C2=A0dma_set_coherent_mask=3DFAIL(-5)
=C2=A0= dmamask_test: 40-bit =C2=A0dma_set_mask=3DFAIL(-5) =C2=A0dma_set_coherent_= mask=3DFAIL(-5)
=C2=A0 dmamask_test: 48-bit =C2=A0dma_set_mask=3DFAIL(-5= ) =C2=A0dma_set_coherent_mask=3DFAIL(-5)
=C2=A0 dmamask_test: 64-bit =C2= =A0dma_set_mask=3Dok(0) =C2=A0dma_set_coherent_mask=3Dok(0)

Identica= l result for three different devices (00:02.0, 01:00.0,
04:00.0), so it = is not device specific. On the stock kernel without
SWIOTLB_DYNAMIC all = widths pass.

The chain is:

=C2=A0 swiotlb_init_remap(..., SWI= OTLB_ANY, xen_swiotlb_fixup)
=C2=A0 =C2=A0 -> io_tlb_default_mem.phys= _limit =3D virt_to_phys(high_memory - 1)
=C2=A0 default_swiotlb_limit() = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> phys_limit (with SWIOTLB_DYNAMIC)<= br>=C2=A0 xen_swiotlb_dma_supported() =C2=A0 =C2=A0 =C2=A0 -> xen_phys_t= o_dma(dev, limit) <=3D mask
=C2=A0 xen_phys_to_bus() =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> pfn_to_bfn(0x42f1ff)
=C2= =A0 pfn_to_mfn() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0-> INVALID_P2M_ENTRY (~0UL)
=C2=A0 bfn << P= AGE_SHIFT | offset =C2=A0 =C2=A0 =C2=A0 =C2=A0-> 0xffffffffffffffff
<= br>high_memory on a PV dom0 covers the whole host e820 map, while dom0
o= nly owns nr_pages frames of it. The top of the pseudo-physical space
is = normally unpopulated (here everything above pfn 0x41a8b6 is a hole;
Xen = itself and the reserved regions live above dom0's last frame). The
p= 2m lookup for such a pfn yields INVALID_P2M_ENTRY, which
xen_phys_to_bus= () shifts into an all-ones bus address, and only a
64-bit mask can cover= that.

Whether the last pfn happens to be populated depends on the h= ost
memory map and on dom0_mem, which is why the symptom varies between<= br>"32-bit masks fail" (my Supermicro report) and "everythin= g below 64
bits fails" (this laptop, the 2024 megaraid_sas report).=

Before v6.6 the comparison used io_tlb_default_mem.end - 1, i.e. th= e
end of the default pool. That pool has been made machine-contiguousand placed below 4 GiB by xen_swiotlb_fixup(), so its machine address
i= s meaningful and small. On this box the pool is mapped at
pseudo-physica= l 0x405600000-0x409600000 (64 MiB) and its machine
frames are below 4 Gi= B.

Why the old value is still the right one
---------------------= -------------------

phys_limit only describes where *additional* poo= ls may be allocated
when the default pool is allowed to grow. Xen always= passes a remap
callback to swiotlb_init_remap(), and that clears can_gr= ow, so under
Xen every bounce buffer comes from the default pool forever= .
Translating high_memory - 1 through the p2m therefore answers a
que= stion that never matters for Xen, and answers it with a value that
has n= o relation to any address a device could be handed.

The minimal chan= ge I suggested in the first mail
(io_tlb_default_mem.defpool.end - 1 in = xen_swiotlb_dma_supported())
no longer compiles as is: io_tlb_default_me= m has been static in
kernel/dma/swiotlb.c since the same series. The equ= ivalent fix at the
place where the information lives is to have default_= swiotlb_limit()
return the default pool end whenever the pool cannot gro= w. That is a
no-op for every non-Xen SWIOTLB_DYNAMIC user (they never pa= ss remap,
so can_grow stays true) and restores the pre-6.6 behaviour for= Xen.

Test result with the patch below
--------------------------= ------

Same laptop, same config plus the patch, booted as PV dom0:
=C2=A0 dmamask_test: xen-pv: high_memory-1 paddr=3D0x000000042f1fffff= pfn=3D0x42f1ff mfn=3D0xffffffffffffffff (INVALID_P2M_ENTRY: unpopulated) n= r_pages=3D0x3c8783
=C2=A0 dmamask_test: 32-bit =C2=A0dma_set_mask=3Dok(0= ) =C2=A0dma_set_coherent_mask=3Dok(0)
=C2=A0 dmamask_test: 33-bit =C2=A0= dma_set_mask=3Dok(0) =C2=A0dma_set_coherent_mask=3Dok(0)
=C2=A0 dmamask_= test: 34-bit =C2=A0dma_set_mask=3Dok(0) =C2=A0dma_set_coherent_mask=3Dok(0)=
=C2=A0 dmamask_test: 35-bit =C2=A0dma_set_mask=3Dok(0) =C2=A0dma_set_co= herent_mask=3Dok(0)
=C2=A0 dmamask_test: 36-bit =C2=A0dma_set_mask=3Dok(= 0) =C2=A0dma_set_coherent_mask=3Dok(0)
=C2=A0 dmamask_test: 40-bit =C2= =A0dma_set_mask=3Dok(0) =C2=A0dma_set_coherent_mask=3Dok(0)
=C2=A0 dmama= sk_test: 48-bit =C2=A0dma_set_mask=3Dok(0) =C2=A0dma_set_coherent_mask=3Dok= (0)
=C2=A0 dmamask_test: 64-bit =C2=A0dma_set_mask=3Dok(0) =C2=A0dma_set= _coherent_mask=3Dok(0)

The p2m situation is unchanged (top pfn still= unpopulated), but the
check now uses the default pool end. i915 and iwl= wifi probe normally,
display and WiFi work, no DMA related messages in d= mesg:

=C2=A0 software IO TLB: mapped [mem 0x0000000405600000-0x00000= 00409600000] (64MB)
=C2=A0 iwlwifi 0000:04:00.0: Detected Intel(R) Dual = Band Wireless AC 7260
=C2=A0 iwlwifi 0000:04:00.0: loaded firmware versi= on 17.bfb58538.0 7260-17.ucode op_mode iwlmvm

I have not yet re-test= ed the aacraid machine from the first mail, but
it is the same check wit= h the same input, so I expect the same result.
Happy to confirm on that = box if useful.

Patch
-----

From: Anton Markov <akmarkov45@gmail.com>
Subject: [= PATCH] swiotlb: report the default pool end as limit when the pool cannot g= row

Since the CONFIG_SWIOTLB_DYNAMIC work, default_swiotlb_limit() r= eturns
io_tlb_default_mem.phys_limit, which swiotlb_init_remap() sets to=
virt_to_phys(high_memory - 1) when SWIOTLB_ANY is passed.=C2=A0 The onl= y
caller, xen_swiotlb_dma_supported(), compares the machine address ofthat value against the mask a driver asks for.

On a Xen PV dom0 hi= gh_memory covers the whole host e820 map while dom0
owns only nr_pages o= f it, so the last pseudo-physical frame is normally
not populated. =C2= =A0pfn_to_mfn() returns INVALID_P2M_ENTRY for it and
xen_phys_to_dma() t= urns that into 0xffffffffffffffff.=C2=A0 The result is
that only a full = 64-bit mask is accepted: i915 (40 bits), iwlwifi
(36 bits), aacraid and = megaraid_sas (32/63 bits) all fail to probe.
Before v6.6 the end of the = default pool was used and these worked.

Xen always passes a remap ca= llback, which clears can_grow, so the
default pool is the only place bou= nce buffers can ever come from.
phys_limit only matters for allocating f= urther pools.=C2=A0 Return the end
of the default pool whenever the pool= cannot grow.

Signed-off-by: Anton Markov <akmarkov45@gmail.com>
---
--- a/kernel/dma/s= wiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -1680,10 +1680,18 @@
=C2=A0= phys_addr_t default_swiotlb_limit(void)
=C2=A0{
=C2=A0#ifdef CONFIG_S= WIOTLB_DYNAMIC
- return io_tlb_default_mem.phys_limit;
-#else
- re= turn io_tlb_default_mem.defpool.end - 1;
+ /*
+ * phys_limit bounds = where additional pools may be allocated.=C2=A0 If the
+ * default pool = can never grow (a remap callback was given at init,
+ * e.g. by Xen), a= ll bounce buffers live in the default pool and its
+ * end is the real = limit. =C2=A0phys_limit would be high_memory - 1 in
+ * that case, whic= h on a Xen PV domain is a pseudo-physical address
+ * that typically ha= s no machine frame behind it at all.
+ */
+ if (io_tlb_default_mem.c= an_grow)
+ return io_tlb_default_mem.phys_limit;
=C2=A0#endif
+ r= eturn io_tlb_default_mem.defpool.end - 1;
=C2=A0}

=C2=A0#ifdef CO= NFIG_DEBUG_FS

The test module (GPL, ~120 lines) is available on requ= est; it takes a
bdf=3D parameter, probes the mask widths listed above an= d restores the
original masks afterwards.

Thanks,
Anton
<= /div> --000000000000660429065b9f9df7-- From xen-devel-bounces@lists.xenproject.org Thu Sep 17 01:17:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 01:17:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423559.1648574 (Exim 4.92) (envelope-from ) id 1x70kW-0006Lc-NB; Thu, 17 Sep 2026 01:17:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423559.1648574; Thu, 17 Sep 2026 01:17:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x70kW-0006LU-KL; Thu, 17 Sep 2026 01:17:16 +0000 Received: by outflank-mailman (input) for mailman id 1423559; Thu, 17 Sep 2026 01:17:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x70kU-0006LO-CG for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 01:17:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x70kS-009V84-Ug for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 03:17:13 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab3f8f-e002-0a2a0a5209dd-0a2a4503839e-6 for ; Thu, 17 Sep 2026 03:17:12 +0200 Received: from [74.125.230.235] (helo=mail-qk2-f43.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab3f97-fae8-0a2a45030019-4a7de6eba3fa-3 for ; Thu, 17 Sep 2026 03:17:12 +0200 Received: by mail-qk2-f43.google.com with SMTP id d75a77b69052e-52fb767cc7fso2151781cf.0 for ; Wed, 16 Sep 2026 18:17:12 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5326200b8d1sm35571491cf.12.2026.09.16.18.17.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2026 18:17:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789607831; x=1790212631; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:subject:cc:to:from:message-id:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=+5zFJ55cgnEY1OXRIavKUOEIG38H34pgZ3VgFg2bzwY=; b=ZF6puEjZqmdQ9NTlnAIu64KuLtkP+pIjsYbOi67PToGmST8ot7FrfSia9hkzRpdb58 /qiCSEqzK4906vuX73H6ZvCVdw30C7S49EL3S7GMnCzmUIaNTH06sBmPnmTzYu+iroFO oelxMYgFXn7EiFJ5SgS6DpJYuyRH2EPOkZUwFicO08+QntpJFJyX545Quua/YKmefQIy WC5+qQQFVcdZ7CpAnqcMtyEXxzUVmru/J59zAKpjr7kCPRbsVCYmM7GiMVy2+phjK6Ke VyaYwxW/TCWjc1+k43UW0w5+XyLXvwdVSBKDKFqGUPAJIIfLh85NEhSkK89ujUOutDQX BnNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789607831; x=1790212631; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:subject:cc:to:from:message-id:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+5zFJ55cgnEY1OXRIavKUOEIG38H34pgZ3VgFg2bzwY=; b=kcG+EzY/1XWjBvFpAHDdEcdthsd8LSkSUhKXSea4lt25HIaIbvOcqGvOyJDBejmvpj pnUndnXm+3Tdx0irAcCTtHvMOY+e0gaXzNqlMxcln4G2W3H/4R0p3jcxxCCueyCyOqjM Y9zFgBmp1JGkOX+pERnm+JfDkFjm1lJ4RIg9NQNbZkxIKrW5HG59Gspp2GRRCAB3bDc4 CNt4DXXivSofPhOpw20ZniZWG4pxusBo3LsPxz01QsV3Tbw2VbtBAALFRExrkzEvX5PM PLkn6k6c3mBon2K0Qg42ga4m/pMd83KM/C/NTuBXK7mrBrWYy8Pu97ZdeflMEzJ5QXt6 82qg== X-Forwarded-Encrypted: i=1; AKwUvBxFxEMuOa6nH5Cp0QMCUzFcBs5Xx4KmKY+CTOpvagnF00qZ9Oo+P8+RPBXO3HF6BFbxjPppCScjzDc=@lists.xenproject.org X-Gm-Message-State: AFuF++n057Sm05UVXI0ZoH6rmNOpmiifhvhclmE2zmOZMgcGjvuia8Nk xdEbDahgpgR1raso4z99z4TPB9nibf9v3VeQmGBCUORAiM6unUmFcmlJX6Yk7SSPdUo= X-Gm-Gg: AYBFou2OBzwfFxbHrvNUb1YLWQlP0IRdjW0HYqUgW5EwOow2uAo5BScvvnrhHTGKpvI ykIW78ZOSts/OnyR8fA+XCNdmEj5m3I3EJSyy8UwFKQc0dgHeNXI/C2WOYitG9ra/XupO0KiWCu UAkBVcV2dGtnGM8jhqu/josgvHGld1do2b/rcVJnHKRuUjQQ+ge274Ir/NbP0BNF81E+AE65qGB pLNHV5xU23SdO/XXh910dUjwgf4NuorAG3guVkcnagRKtAUjmbqzMFrkCLzV1T8261f9OUSlw0P PF30+HwB+l6hkB8+gqYP+OIWDgQHDIEx9WpDsZzaCCtEiVN5wwWwCpsWPMfMihky+oLNa2GxFFp 5SFAqVoMr0sn9RZFZ1fZ+ZPr5W5ug5mJ8A64FmuROfNQZ4tnQssKr/ulJTZsUEx7ejYrwUKSx5y VNWGwRlpYzl5JaDiSmMgWqUmTCp9t1TGJGkOzaK4BzGiHJ6W/wzSgNnFd8wp6chDTaFfHiC/rmQ 0EFwiVI+4XYJ6mwea/D9UvzfhUzGxnI2UWftE9o5bGNxz3Ybq+jzSjQ X-Received: by 2002:a05:622a:1a93:b0:530:4249:e7a9 with SMTP id d75a77b69052e-5327ed78742mr91407171cf.13.1789607830859; Wed, 16 Sep 2026 18:17:10 -0700 (PDT) Date: Thu, 17 Sep 2026 01:16:58 +0000 Message-ID: From: Josef Bacik To: Alexei Starovoitov Cc: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 06/13] bpf: Take a Tasks Trace reader in the trampoline glue In-Reply-To: References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-6-0ad30c4c5ee7@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1789607832-7428D4E9-77E71A0B/0/0 X-purgate-type: clean X-purgate-size: 1802 On Wed, 16 Sep 2026 03:45:16 +0000, Alexei Starovoitov wrote: > On Tue Sep 15, 2026 at 1:17 PM UTC, Josef Bacik wrote: > > __acquires(RCU) > > { > > + bpf_tramp_read_lock_trace(); > > rcu_read_lock_dont_migrate(); > > This is double increment. rcu_read_lock_dont_migrate() includes > rcu_read_lock_trace(). Unless I'm looking at the wrong tree it doesn't, on Linus' master and on bpf-next it is static __always_inline void rcu_read_lock_dont_migrate(void) { if (IS_ENABLED(CONFIG_PREEMPT_RCU)) migrate_disable(); rcu_read_lock(); } so plain RCU plus migrate_disable(), no Tasks Trace reader. That is why the non-sleepable glue needs one added here: on these architectures the trampoline image the glue returns into is only kept alive by Tasks RCU while the task is a rcu_read_lock_trace() reader, and rcu_read_lock() does not give us that. It is two counters for a non-sleepable prog on x86-64/arm64 though, rcu_read_lock()'s and trc_reader_nesting plus the SRCU-fast percpu one, if that is what you meant. I don't see a way around it short of not using Tasks Trace as the trampoline reader: the prog still needs plain RCU for everything it dereferences, and the image needs something that survives preemption. It is compiled out on every other configuration and nothing changes in the JITed image. If you would rather the reader be taken once around the whole image in the JIT instead of per prog in the glue (which would also let the fentry-only teardown stay a single grace period), I can do that for x86 and arm64, it is what v2 did with the private counter. Separately, Junseo's "bpf: keep trampoline progs alive until image release" also adds bpf_tramp_image::nr_progs; if that lands first I will just use it here. Thanks, Josef From xen-devel-bounces@lists.xenproject.org Thu Sep 17 02:24:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 02:24:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423584.1648583 (Exim 4.92) (envelope-from ) id 1x71nb-00070a-6O; Thu, 17 Sep 2026 02:24:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423584.1648583; Thu, 17 Sep 2026 02:24:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x71nb-00070T-3i; Thu, 17 Sep 2026 02:24:31 +0000 Received: by outflank-mailman (input) for mailman id 1423584; Thu, 17 Sep 2026 02:24:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x71nZ-000707-7l for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 02:24:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x71nY-009bPy-1y for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 04:24:28 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab4f16-2eae-0a2a0a5409dd-0a2a4507a710-40 for ; Thu, 17 Sep 2026 04:24:27 +0200 Received: from [74.125.227.140] (helo=mail-pj2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab4f5a-b4ea-0a2a45070019-4a7de38cae57-3 for ; Thu, 17 Sep 2026 04:24:27 +0200 Received: by mail-pj2-f12.google.com with SMTP id d9443c01a7336-2d8fbef5018so3501315ad.0 for ; Wed, 16 Sep 2026 19:24:27 -0700 (PDT) Received: from localhost ([153.61.198.242]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2dd89ee3557sm18694235ad.52.2026.09.16.19.24.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2026 19:24:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="In-Reply-To:References:From:Subject:Cc:To:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789611865; x=1790216665; darn=lists.xenproject.org; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=6EKmqByiGxzJPh+0Mll6vjXYdVK/vy8pIRVPNPfe0KQ=; b=Qbs97lxuRnHpH/1qrNb6G5MqmINkr1NB28fcEfYBl76byCnkR+lk/or2KCjMXAPwmN FnZZy1WVRVoc6YDQrYkuEc6tXLUaBmA+eUNuibFKeeV8SUxvysprfSxR7UTdjdcN5WOa cgchJXLeNfazT7gOiCYml/oY8kPWHtgw7huQRF9+bOf7P4D0SAjUBqtMmB9rutnQifP9 91h5kLF5Rs6U9uCBgAxlOOneAP9rdMeWMeBeyxpCInSVkgo/593W+m6C97q7ZWc1Zomd kTdNH4mIRiMiHSxajimgMWUk0KzXas9JroULXrd/64N2fSGdUuFG/5kDs1NgUyt84bcH h/Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789611865; x=1790216665; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6EKmqByiGxzJPh+0Mll6vjXYdVK/vy8pIRVPNPfe0KQ=; b=pgS8eGwPYM+whD/Uqwt7TwTyX2IkaVjmWykuXPZKngt5h3x5uz1kxZ/I5lE/e9RNfX sovOEEp+xa8q/kNo7xUJBqqgTpgiVF9jIIsNsMTikgsTURenRn1dVa+rEQeXVG3qhHcc gGxWvkS+LlTWu1KwjW85X2q//B4LpYoLPDYdhI/U49mszbKw0vNFMsBSd7hANfnIPNvi BdULE6+v6qlmp5Plq/wgXczNXMkzeabyKsFrl3hObYC7rfDpQiHy0r+22nWBFjuy0F16 x5mtI3HAG/8YdMMma3Dm6IUGmbL1Ck+IeBiIFd7LWMu8zc8yPr2eXVJium+WixY4G3eT pjAQ== X-Forwarded-Encrypted: i=1; AKwUvBzAqb/+uebX8uSxnzCjgVZDZFa5F8I4MKKJ9npgGN9gD3aXpQPdrB/Pv0LDd0Ll7bO0w5DXyNfsAFE=@lists.xenproject.org X-Gm-Message-State: AFuF++mB6+rb57cuxd+uxihxWQ0egG/gLcM7KCSCPKFv/U8rhPhDg/aC CvVonR+3GJByNK1nNPdTMAjDES7aRqBuE2ch/XqrEvZjB8DuRfP55Q78 X-Gm-Gg: AYBFou1/qJRFFF7rr1WCwKW6Qy0NQlF6jP9NsCGQBR99GlS2KIIfKHK4wtV8zR+8wfH ub68/sdU4aO6O+aBNV7cYWPmzV+ofNxIzlMV9JJAJO/Uc8IasG97DT8PltmOCJMjxfPyI1DPXa/ wJtrnaRKi258zEvi4P8YkxY1QTCj79YIo4nlPYP7zCfGZHDf2v+hFJtqhy2Vc/CVRJk+200o9uU 0+YuNhyhNtKCm/ekGUJYGSE9fdSNnEds46BRVfBMgksTLcuGf4+MS1PP6NLX3QUN9DNJNt4EEN5 GhGJtf4E6Hxf61NQYnx4gpOORa8q/PoeAnw1uBDLKxms2ALidp8svsIL7STwGs4yoezzEXgf/QF 4/RhJuKQX2D3WJiF/XYMHw1tMhyHGTRozG0kOT3kQqnFANlD48KEv+2uJMmYkfMuNfVlvZxkjIO 8scPaXeuNhDU3pPfxoAAm6JW07G3QlTg1FDjXchdVzk1B5yAyaTWQWQaztjH+sVRQyyyc9y3UvE JN8+hbxg56oSkR1r1tZd1126MAHoYdDEPhDUsVYYZ8WDV9kHDWx2mAFZWvAgy1K4hUAotjyXgTO hCYn X-Received: by 2002:a17:903:1ac7:b0:2dd:60d:8b7c with SMTP id d9443c01a7336-2dd8e3f57f8mr114351815ad.13.1789611865419; Wed, 16 Sep 2026 19:24:25 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 17 Sep 2026 02:24:24 +0000 Message-Id: To: "Josef Bacik" Cc: "Paul E. McKenney" , "Frederic Weisbecker" , "Neeraj Upadhyay" , "Joel Fernandes" , "Boqun Feng" , "Thomas Gleixner" , "Peter Zijlstra" , "Steven Rostedt" , "Masami Hiramatsu" , "Mark Rutland" , "Jiri Olsa" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , , "Catalin Marinas" , "Will Deacon" , "Puranjay Mohan" , "Xu Kuohai" , "Andy Lutomirski" , "Josh Triplett" , "Uladzislau Rezki" , "Mathieu Desnoyers" , "Lai Jiangshan" , "Zqiang" , "Juergen Gross" , "Luis Chamberlain" , "Ihor Solodrai" , , , , , , Subject: Re: [PATCH RFC v3 06/13] bpf: Take a Tasks Trace reader in the trampoline glue From: "Alexei Starovoitov" X-Mailer: aerc 0.17.0 References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-6-0ad30c4c5ee7@toxicpanda.com> In-Reply-To: X-purgate-ID: tlsNG-ef75cf/1789611867-A48C9AE4-C3958146/0/0 X-purgate-type: clean X-purgate-size: 1284 On Thu Sep 17, 2026 at 1:16 AM UTC, Josef Bacik wrote: > On Wed, 16 Sep 2026 03:45:16 +0000, Alexei Starovoitov wrote: > > On Tue Sep 15, 2026 at 1:17 PM UTC, Josef Bacik wrote: > > > __acquires(RCU) > > > { > > > + bpf_tramp_read_lock_trace(); > > > rcu_read_lock_dont_migrate(); > > > > This is double increment. rcu_read_lock_dont_migrate() includes > > rcu_read_lock_trace(). > > Unless I'm looking at the wrong tree it doesn't, on Linus' master and on > bpf-next it is > > static __always_inline void rcu_read_lock_dont_migrate(void) > { > if (IS_ENABLED(CONFIG_PREEMPT_RCU)) > migrate_disable(); > rcu_read_lock(); > } > > so plain RCU plus migrate_disable(), no Tasks Trace reader. That is why > the non-sleepable glue needs one added here: on these architectures the > trampoline image the glue returns into is only kept alive by Tasks RCU > while the task is a rcu_read_lock_trace() reader, and rcu_read_lock() > does not give us that. Right. I got confused. Since rcu_read_lock_trace() CS will cover both sleepable and non-sleepable prog types let's do it once per fentry+fmod_ret region and 2nd time for fexit region. We probably don't want to hold it for the whole trampoline, since orig_call will delay freeing of progs. From xen-devel-bounces@lists.xenproject.org Thu Sep 17 02:29:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 02:29:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423592.1648594 (Exim 4.92) (envelope-from ) id 1x71sW-0007a7-P1; Thu, 17 Sep 2026 02:29:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423592.1648594; Thu, 17 Sep 2026 02:29:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x71sW-0007a0-LL; Thu, 17 Sep 2026 02:29:36 +0000 Received: by outflank-mailman (input) for mailman id 1423592; Thu, 17 Sep 2026 02:29:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x71sU-0007Zu-MJ for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 02:29:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x71sT-006OAF-BG for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 04:29:33 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab5061-8faa-0a2a0a5109dd-0a2a4507ecb0-18 for ; Thu, 17 Sep 2026 04:29:32 +0200 Received: from [52.101.43.53] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab5089-b4ea-0a2a45070019-34652b35dcd5-3 for ; Thu, 17 Sep 2026 04:29:32 +0200 Received: from CHXPR12MB999219.namprd12.prod.outlook.com (2603:10b6:610:2fd::8) by DSVPR12MB999123.namprd12.prod.outlook.com (2603:10b6:8:388::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Thu, 17 Sep 2026 02:29:23 +0000 Received: from CHXPR12MB999219.namprd12.prod.outlook.com ([fe80::da19:941f:da0c:2408]) by CHXPR12MB999219.namprd12.prod.outlook.com ([fe80::da19:941f:da0c:2408%2]) with mapi id 15.21.0406.007; Thu, 17 Sep 2026 02:29:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aU5atneVhycdmMhtLSwfg54zKU3yGrUYjvprNXNstXA6CZ2sIEs9AK1SdM+nPwa/q8huXKd8M97yd/JlaAbJ6lseyYr2G4qrpEdECyIPSTk5E9m2LwcJ5rAfGCJG1R/11dJBFbmQiZBwXtxfgcScinUMMQ5h3q4EVQ+d8O8Vo50z3pk/EGsPDgVUri4pg7Y8jE+/vlkZSa7m9Za46n6i+bmfdsWwX5f4lPPN4ISl+VJ6pSwc+DD6eh4yFNv2BbuBfmqSqV4t6t7l0CiNeAM/DvYjxBcKqHG6AqOr9VMrJeWTOrW2ZOYFmCD1T1bFNTvR+56tAP3878Y5fRcud0QAhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pnOSeT827JqM1WHSr2HBLUMH3Xd9V0DEn2LgQLiflk4=; b=TtI7glOzplsZ/P8IzLNNf9lZYdYnB0qW2c28zQlXq1hrzFoXPbvBG+ZAiPMWCSrgoL2cilXPR+CkY8/87z3cijXZyUtKGCMMtf7rNud0LeWpp+gZkGbhmQ/1eJmNYln794C63W8e+0dqi504QHI44byMjHdeEEZ5YBbaGZwPYs1KYLoTsGp9zBkm3t+xkgT0eZmyrexJuWBQKyor++xqUTP8CApPWa/baMtBdmLZMsI61JoFrqdTbXYLISRuZHul93jY12ta1FbIK7Dh/BPyc7tloWtdnExLiVvnRnRwK719jpfaRQsYT1Yq+Y8JghNs1AM934wloSPBQ3xcYCGLzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pnOSeT827JqM1WHSr2HBLUMH3Xd9V0DEn2LgQLiflk4=; b=ChHaTJWzZ+TxxrfC9iMO2WNgY60TZrG4LmDyunjLzpNzxCq2HVuEjwdJKOn+6zpHMSHNL2Hknt3xRIv89K4z4pIEi1WgGeQac6Tc3TGO1EMQmJ0JVXx9cp+zdfw0dW595Bv+9O1zLelSOaq7vB1xbppzV+hy3X2HsGm+SmzvXLg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <9c83efe9-9367-472f-bf39-e07252e70c3c@amd.com> Date: Thu, 17 Sep 2026 12:28:50 +1000 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH kernel 01/17] pci/dma/tsm: Call disable DMA bus hook on cleanup To: Borislav Petkov Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Catalin Marinas , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , Liam Merwick , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?Q?Carlos_L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , David Howells , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Christian Marangi , Dave Jiang , Michael Kelley , Ilias Stamatis , Sumanth Korikkar , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , Palmer Dabbelt , linux-coco@lists.linux.dev, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, linux-mm@kvack.org, aik@ozlabs.ru, Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba References: <20260916115159.1938195-1-aik@amd.com> <20260916115159.1938195-2-aik@amd.com> <20260916174929.GCaqrWqZ1fIhi4Rgbn@fat_crate.local> From: Alexey Kardashevskiy Content-Language: en-US In-Reply-To: <20260916174929.GCaqrWqZ1fIhi4Rgbn@fat_crate.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SY6PR01CA0119.ausprd01.prod.outlook.com (2603:10c6:10:1b8::13) To CHXPR12MB999219.namprd12.prod.outlook.com (2603:10b6:610:2fd::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CHXPR12MB999219:EE_|DSVPR12MB999123:EE_ X-MS-Office365-Filtering-Correlation-Id: 5c5369cd-ffef-47fb-d79a-08df14637cb1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|7416014|376014|56012099006|11063799006|10067099003|4143699003|18002099003|22082099003|6133799003; X-Microsoft-Antispam-Message-Info: OTWkJ3BzLvXlpYrhzvzJ/m6bDLG6FVqhqVagagcJJmrDwex9mkmlsGSPyD9vZbM1EorDdeY5zKRT2tKL3AwI/77eRPKsj8+0JjxUGKuqVkCtXvgYVHwHyS/uYGS7cOh2d5NtBtDAx1RGUTLnGBmfyHSkGKtRJWFbP2Oz4QdmrLHy/3tmWtTLREvL78kzH8AXrMHNDj6ePCq/fJiOEiezoiSdL3Si90dGeEcVxGLU/z02aAx1L5fJX+gAztzdfHBlvf4TJLbKg6eIttIJjLnZRYIIsgPlOK+mT3piX3Do7D2sGM4ifLcEeg5LS15cwCnkluKzId3YlyGxXllznR6+JejZgHECA/1s6tJxny8I3oXWdRe+bUkGeX7y6zKdgElS7rqTOE4b4kBg/0S6nDdhVvLH+eYGU9+FJM6aRrJKlVCpdS3Ir7cqZ8TjJ9CV76xmgFiNjVxuc5cjPmL7AyTPKC//iSRb/5xKpLQtIL6Qz384357y9I6YF3u7GKlv2K1MORL7kdBwPo2WR0VhuOuDXxiQrGMjiRPcBu9oR0kVhPAo9iKn1Mn5D3dloVVmz2VPCdlyxE0Xqgf6GKJxgVvqCnvUPG2lHFvPj76Po8MxlKqS98nek9hAhC54VcRzdvJMXLv1L7KJtjXjCJuBmpala/hD/nk4Mg8YbJVWeuy0rdY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CHXPR12MB999219.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(7416014)(376014)(56012099006)(11063799006)(10067099003)(4143699003)(18002099003)(22082099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N3phOU4xTkYvemVvS0duR2YzKzVHY3BFVmdnQ3VIbERGSmFQZ3NNdXhKRGx4?= =?utf-8?B?b3BDUlRZMUpiUGVTQ1MzbThWRlRZZFcyYVFSMVFLNldzbDh2TDNBTVl0MmNv?= =?utf-8?B?amcySUpwTWRuMFFtcDNCVWNHWUw5VzFlU0dPMWdrT3RKNjhIa0tTcXAvL2lJ?= =?utf-8?B?TDZnN2JMaFdwblR2aTd3aTVaUEphNWFVUE1yNTZvRlpCT01WcXU3SDljY3Mz?= =?utf-8?B?aTYzeWVING80UjR1V29vcGJEQmlXaEc4andDL3p4ajUzMGxIRXZkbUZiQk1T?= =?utf-8?B?Q0lDQ29wMlprN1JsVnNJQk8xSDRuOEJKRzhqSllydnlQWDNudTVaQUpkVm5H?= =?utf-8?B?RXJRczJQWlcwaGx0MHdJUWN6T3UzSGhhZ0VTUFFBaEJPcWlocEhENEVXK3M1?= =?utf-8?B?Zkp2Q1lBdm9LYXh0MkIvOFh2b0JFZWxjUFNkMTE5ZnVUdlpVUTdrbzg0QXdk?= =?utf-8?B?ai9pVTBrTkF5azZXaW9DOFV4VDhDeFJBb0xZR2d0bEJsbFcyNVlUbTRaOXZa?= =?utf-8?B?Q1owbHV6UHpXZUNselRyeVBMSzZhR1JKendIcUJId09CQUZGdWtSeW5sTVdJ?= =?utf-8?B?ZmE4MzArejJ3RThDWUJwYWlzdjRsMHRscDJjVjVMOXpZRjVDRWNxNjlZczd6?= =?utf-8?B?VHR0ZTMxcDdtUWlXQUUzSFlLR2dJSTRPeTdSOHhuQ0Q4NHY4VEN3a2laNHVt?= =?utf-8?B?TDc4NmhZT1cxWUpBbGVNaytCRkJMckVIaDQySERqSEN4WTZmUzdya0kreGVU?= =?utf-8?B?eTBQTWlHRHQ2aFlFNnd6UHpxT3h2M09GRnZtTFE1eDhIVE5ZNWhVdXVkMFpH?= =?utf-8?B?a3cvS0UwNURYQUZuSkRiVUZhTTJkTldURWhUTDgyS3oyVU5VcGdWRE9Cc0d1?= =?utf-8?B?a2pxbEcxL2xMaFJodFVVakFMYXlzY29QS09aMnVMeFlIdE96WlRtaGt0clo3?= =?utf-8?B?dGZvbjY2T3gxMkVoenYxakM0L21kSFczb2RqeU54YTBaWXFKOXI0M3ptdVZX?= =?utf-8?B?MkRhSEZsY2lYRktnMUtZSnE3bVNiS0VrcVRucGpxcTRpdkFtY0M5amtkTmZ2?= =?utf-8?B?MTNVUDNISS8xekxOVkxadnAvb0pJWGRUdHUrR3NpVDVCSFl0ajZ5MUpHdk1p?= =?utf-8?B?R1BhQXFUMGVrRkxkYm51dXJVWFoxZHVwMWlMRGp3L1k3TEpkREdkaTM1K3Bs?= =?utf-8?B?aVpHUG51bXBTVFpnY0g4TFM0SStRNWRjK3hpM295ODV2QTJzTVl6Qk5Ba09z?= =?utf-8?B?cS9NQlhXcWhOUGV2NlVIdFJ4SGdnOFZNdEl6TU8xL2JSQi9QdytxUjdBclNI?= =?utf-8?B?ZUVLazRoL29YT0dtdlN0L3dtUjc2ckorN2ZRTUl6blZ0MTR0TjRPWDkyaTVX?= =?utf-8?B?VVhVbkFZQ2NOdXIzUFkwdUhOZ25YYUYyeXhQNE9YWUYzQ1BhK2NIejBoM0FW?= =?utf-8?B?N1FHeHBKZjlkc3FPSnJGSUdoUG9tNnIrSGlQZnFqQytleEZtdWpqR2VFNS83?= =?utf-8?B?ZHpTeFliSHRhWEFMQTE4YVBxcHFvc243cjNJOVNGYWZPdjZaQk9vOU1UK0lX?= =?utf-8?B?QzlLcHJHbmkxMnYxYnI0clc2d2QyY2lGUERUem1xVXNtUVdKeWVZcnRhNXFV?= =?utf-8?B?VUFxWXhGZFROaUowbWRFMGQ2NlNzQ2JrWjZqOGhSNEMzQXlGS3VNdk0zck81?= =?utf-8?B?L29CNzkzWXJNUmxtQmNONjFsUTdONjFtK0JTbUNEcGMyaXYwS3MxYlJ2MTlr?= =?utf-8?B?WmVIN3pZQjZYSUxjdkFyODdQZHgzdzZqYlNWeUtmcGR3VkFuaWIraU4yazVx?= =?utf-8?B?STFoNURCalJxQURuekxKdW1qRlUvaGdUQkFva0dtaUZyN2djRUppNTdvTU1H?= =?utf-8?B?S1pYbkRXc1dxM1h6M0dycWRDREdGR1ZQWngxcUZwYnQxYXdjTW1qcW1Md2JR?= =?utf-8?B?a1Q4K0w2RHE4czVBQm9pNHQ2U3J3TzBDb3N1U3V1TFVheTlwc2ZJZzdLSFVi?= =?utf-8?B?dld0UEE3MTBBY3BQdVk0YVNZdXJqVzFlcW9EU2p4Z0cyL0NZc2FDaFM5QnNk?= =?utf-8?B?K2xnN1hVU2JmTmpPTU8xL09nd2lFYWRQYVdLSTlmOWozMG4vV2FURVJ3bzBK?= =?utf-8?B?Wi8vL1VDMkV5MzFBVnpNZ09hZE8yTjJaMGY5V3RaOWxnZ0U4WXNVNGV0cFdl?= =?utf-8?B?cDNTZGJRV0tkNHFzUEJvUTR1d2g0SXYvS09xcnQ0L1pGaDJFZFNzOFBjM2dy?= =?utf-8?B?aWtBOTlPQjU2dTBoN3BEVkZKRE0weFpxOC80bGVrbHI4eVR6bkUrTnBPWlJR?= =?utf-8?B?ck5aWUh3NnJ0dUoxN0JRYzlka2NXSTlJZzN0RmNHL0JuNWk4Wllvdz09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c5369cd-ffef-47fb-d79a-08df14637cb1 X-MS-Exchange-CrossTenant-AuthSource: CHXPR12MB999219.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2026 02:29:23.7911 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: T2crqjoZUBnh2uJavoqc94OSC7soEz1LMPV53bIpK5Sn65abFUdpyx8ya+Nl4NVL1fkkL22sad+ivtm+rsm8XA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSVPR12MB999123 X-purgate-ID: tlsNG-ef75cf/1789612172-A64DBAE4-6DE5A6C7/0/0 X-purgate-type: clean X-purgate-size: 829 On 17/9/26 03:49, Borislav Petkov wrote: > On Wed, Sep 16, 2026 at 09:51:41PM +1000, Alexey Kardashevskiy wrote: >> + if (device_tcb_trusted(dev)) > > Where is that function and the rest of the gunk needed for me to apply before > I review those? > > The patches on that branch: > > https://github.com/AMDESE/linux-kvm/commits/tsm-next > > which come before those here are enough? Correct, the patches between v7.3-rc2 and 01/17 (can drop samples and tools, obviously) are enough. It is basically recent tagged upstream + rebased Dan's https://lore.kernel.org/r/20260705220819.2472765-1-djbw@kernel.org What device_tcb_trusted() means is still debatable, the earlier proposal was including a module flag saying that the driver is trusted too, I think we are ditching it now. Thanks, -- Alexey From xen-devel-bounces@lists.xenproject.org Thu Sep 17 04:55:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 04:55:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423626.1648603 (Exim 4.92) (envelope-from ) id 1x749M-0000OR-Pa; Thu, 17 Sep 2026 04:55:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423626.1648603; Thu, 17 Sep 2026 04:55:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x749M-0000OK-M2; Thu, 17 Sep 2026 04:55:08 +0000 Received: by outflank-mailman (input) for mailman id 1423626; Thu, 17 Sep 2026 04:55:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x749K-0000OE-PI for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 04:55:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x749I-004UiQ-Km for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 06:55:04 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab7293-bab6-0a2a0a5309dd-0a2a4505e6d8-38 for ; Thu, 17 Sep 2026 06:55:04 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab72a8-4cb1-0a2a45050019-4a7de18dc760-3 for ; Thu, 17 Sep 2026 06:55:04 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e69b9e16aso3831845e9.1 for ; Wed, 16 Sep 2026 21:55:04 -0700 (PDT) Received: from [10.250.112.129] (h-213.61.72.154.host.de.colt.net. [213.61.72.154]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd24108asm43188605e9.9.2026.09.16.21.55.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2026 21:55:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789620904; x=1790225704; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=a8oqEQkzkKnAgHJ1zAnZI8QD5OUD1n2euF6jqK2YUcA=; b=PEg/r1LTCgk1Zux5YzBTRxGqb4K9jI80VRXUvBOwdcfg+7uCdpPVMLcJ1KdsgFRpwJ ldiiyaHu23iqGG9hPKwF+CqjSVY1h0YYJVYfjeILfYaFPkEP6kM3QSRqlaTBOGHKEhZe zztLB6MT7DfpA3l0HEJRYmBQbnq/xrztO6u9YuFeVdG2574vqERHpBOkemp+rfCX6MUM dCagPPeguhVEXcCRgqbHaxf9agebPqZnMNuMQpfP9AsJJ3VTcJ0YOZ3JI5wDefAsNakc QnjBzEdAwX01rrY4t9PGDBJ/UdWVnuDGiLVkZaCMAKXv/a/iBMuYtZytN/w7mSnkQRJB H6gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789620904; x=1790225704; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=a8oqEQkzkKnAgHJ1zAnZI8QD5OUD1n2euF6jqK2YUcA=; b=yi5mHlaFn8gvmastLk7X6NvjIrWnRocsWv4yeJVcStZ7j3h0C+wQGhCumJ64fM/HX9 E8Ix5O4rf7f+JWBW9q1eoLi7oa1dOYMnqqTmaCfNT32iEs9NBX45AuRZNAddZpTXJoxT O368OCQ19kz4ZiPw/+6GkE86DlFyeD8Vo1wtr7O4T2bo4dRpaAdF5U4GwgfZsf0eJ9fc vo8+rCmRA6x5FwRWQmHOWs6SlDYYonl9Jw88iPD8cKhJqrVTrokWPa196HYq9kZRpyN6 D8r92xuICqSnifbeSjaklzvvHzYmygHIT7KoM10VF0YlYrXvuJoDodYIfkZs2M6MZkrF a81A== X-Forwarded-Encrypted: i=1; AKwUvBzRVLnU1SUqqWYYeXNJFmEsWeZR1HIbi8/jOEMu1Xqneazff8AhJxMOZJvWnm1XJzGVm72y079oh8Y=@lists.xenproject.org X-Gm-Message-State: AFuF++ngdGnuQwova36Yb67GpKnH4QEfwbJ2eKtmhXLYZh6IELnTWz5h vlOO/6+t8yPwfnI0LtuOQZaMSZN7DzPettjznhjPXwB4RnwU1zaNUQRNpz3ygr7b X-Gm-Gg: AYBFou2RkjFcBNu1LDY8dhbRX+5Fze7D4Ec+Q7O8Fj7lPZmUH7n3/tkDhQT6v6Kfvaz xBVcVZL2hsE2pGX+LAvwxLguU7wQhYuqx3d95vRXfmmEylEZOZkR15g17NDpsKHh8jBL9yq4/Ia 2BJL1QBrjtVa/wSIyUM+XtRWHfmkvxH8d5sVQbS5Lu4QEtB5NAIvHyRo6gvw2LKWaw8fefIdg5x MaxJs67CRhXs5UtYOMyQEiljw4DbCLAm+yF2964MYgNG8+sF2i1tYq1q+cu4Ehf3HhJaPoJZH5a mJwIlFBtiACQNePSWEaDdZbdJQuYo8FhZTpV0fLZ1HDBg8AMOfvTGZKPGaUEScWAfgf4joYv9Qs 2/7mWZP0DREkTNbxkFoyjdrZ4DHpLM1aTa+bF18C5sU7gtWWZva90hS2erjFQfTcGpJtBceRf0f AftkpHhoPAxHkeAKnWHI/907QYOkpLWjzfJrMtJiUuZUMEUlphJ26YDVmKO5ZQoaroleFUlCxi7 PZaAjes8RCTpCntyHsaLYdI5wHRzOcKNp5JiJ23wZQJgcs= X-Received: by 2002:a05:600c:8b61:b0:49e:69ff:c6b1 with SMTP id 5b1f17b1804b1-49eb7339916mr63107195e9.31.1789620903846; Wed, 16 Sep 2026 21:55:03 -0700 (PDT) Message-ID: <75658755-ba86-4089-85f4-fb608f628d7b@gmail.com> Date: Thu, 17 Sep 2026 06:55:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v2 29/39] xen/riscv: introduce aplic_reconfigure_target() To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <2e29de1d-370d-4251-8e1d-dd9f17720339@suse.com> Content-Language: en-US In-Reply-To: <2e29de1d-370d-4251-8e1d-dd9f17720339@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789620904-F429B2A1-6620D7E6/10/73395122804 X-purgate-type: spam X-purgate-size: 4695 On 9/14/26 2:25 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> When a vCPU is migrated to a different pCPU, its IMSIC guest interrupt >> file changes. Any APLIC interrupt previously configured to deliver an >> MSI to the old interrupt file must be retargeted to the new one. >> >> Implement aplic_reconfigure_target() to scan all interrupts allocated >> to the domain and update their APLIC TARGET registers accordingly. >> >> Signed-off-by: Oleksii Kurochko > > First of all I'd like to understand how this "reconfigure" works without > losing interrupts and at the same time without other possible races. An > interrupt can be raised at any time, after all. The RISC-V AIA specification relies on this separation for the 6-step vCPU migration sequence: Step 1. Setting eidelivery = 0 at the old interrupt file stops new traps on the host CPU. Step 3: Reconfiguring APLIC/IOMMU and flushing the interconnect forces all in-flight "straggler" MSIs to reach the old interrupt file. Step 4: Because eidelivery = 0 did not block incoming MSIs from setting bits in eip, those straggler MSIs safely landed in the old eip array. Step 5: The hypervisor reads/dumps the old eip array and bitwise ORs it into the new interrupt file, guaranteeing that no in-flight MSIs are lost during the transition. (Note that I re-word some steps and skipped some for simplicity. Here you can find full text: https://github.com/riscv/riscv-aia/blob/main/src/VSLevel.adoc?plain=1#L134) Does it make sense now? > >> --- a/xen/arch/riscv/aplic.c >> +++ b/xen/arch/riscv/aplic.c >> @@ -138,6 +138,48 @@ uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, >> return base_val; >> } >> >> +void aplic_reconfigure_target(const struct vcpu *v, >> + unsigned int old_guest_file_id, >> + unsigned int old_cpu) >> +{ >> + const struct vintc *vintc = v->domain->arch.vintc; >> + const unsigned long *auth_irq_bmp = vintc->used_irqs; >> + unsigned long old_hart_field = aplic_hart_field(old_cpu); > > Once again a question you may already recognize: What extra value does > "field" in the variable name add? Because aplic_hart_field() construct target's part of hart field which isn't contains only pure hart value (apparently, thanks to the way how spec is written and things are done). Note that based on other reviews from this patch series it is renamed to: unsigned long old_hart_index = aplic_hart_index(old_cpu); (and here _index for the same reason it is basically how AIA spec calls this part of the target register) > >> + unsigned long flags; >> + unsigned int irqn; >> + >> + /* Support only MSI mode at the moment */ >> + BUG_ON(!aplic_msi_mode()); >> + >> + spin_lock_irqsave(&aplic.lock, flags); > > Taking a global lock for a per-vCPU operation isn't going to scale > very well. Even more so when then ... > >> + bitmap_for_each ( irqn, auth_irq_bmp, vintc->nr_virqs ) > > ... you run a loop with perhaps many (hundreds? thousands?) > iterations. I agree. Then per vcpu's target register lock (or per-irq lock) + APLIC's global lock mention here only for a short period when APLIC register would be needed. I've done such change for support of IMSIC software interrupt file but it seems like it is started to need earlier. > >> + { >> + volatile uint32_t __iomem *ptarget; >> + uint32_t target_val; >> + unsigned int guest_index, hart_index; >> + >> + if ( !irqn ) >> + continue; >> + >> + ptarget = &aplic.regs->target[irqn - 1]; >> + target_val = readl(ptarget); >> + >> + guest_index = MASK_EXTR(target_val, APLIC_TARGET_GUEST_IDX); >> + hart_index = MASK_EXTR(target_val, APLIC_TARGET_HART_IDX); >> + >> + if ( (guest_index != old_guest_file_id) || >> + (hart_index != old_hart_field) ) >> + continue; > > Along the lines of the naming comment above: This would be more > logical to follow if it was > > if ( (guest_id != old_guest_id) || > (hart != old_hart) ) > continue; > > i.e. names on each side of the != suitably matching up. I agree with guest_id suggestion but hart_index should be left as according to the spec what is stored in hart index field of target register isn't pure hart cpu id but it is a combination of hart cpu id + group index (check the comment above aplic_hart_field() for better context). Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 17 05:12:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 05:12:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423637.1648610 (Exim 4.92) (envelope-from ) id 1x74Pu-0003fM-4K; Thu, 17 Sep 2026 05:12:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423637.1648610; Thu, 17 Sep 2026 05:12:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x74Pu-0003fF-1M; Thu, 17 Sep 2026 05:12:14 +0000 Received: by outflank-mailman (input) for mailman id 1423637; Thu, 17 Sep 2026 05:12:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x74Ps-0003f9-DB for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 05:12:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x74Pr-009seW-Q4 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 07:12:11 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab7694-e002-0a2a0a5209dd-0a2a4507aad0-22 for ; Thu, 17 Sep 2026 07:12:11 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab76ab-b4ea-0a2a45070019-4a7de18d96ed-3 for ; Thu, 17 Sep 2026 07:12:11 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e71cdb22bso2620585e9.2 for ; Wed, 16 Sep 2026 22:12:11 -0700 (PDT) Received: from [10.250.112.129] (h-213.61.72.154.host.de.colt.net. [213.61.72.154]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf27c65sm12626442f8f.21.2026.09.16.22.12.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2026 22:12:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789621931; x=1790226731; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=KCIuSRrWRr6ZhyjbWuzbQFsE0KRSs9atqvR0PaqwdCE=; b=jQlWrhOIJ7lhXJEud/OT9OjRcItlSDKqwWojaswjoTA/dkDvqdgOIiEotbBvCLCtd1 D7/wZICtAxqVkJ/D2BwHit2ueC8pPk2P8NI0Kv7sxeOagIYSoB3engHHbt5g1wOhxtiF 2L9eYUfdytfh1meZDnhlXj8etohLM/WNlgren0wubHaIf5g6jfgTWVwIL/TvzeNGndtl uCclwK/1IXDx59rnZdooH+2E7nbCMqPGvUTlGIv3+GnyJVLFkHhG2VMlpu4dmUvlgrEl +Ij9Bxj4u5LF/OTEJUbUGhd3s2kghfQ5jrBEBLUzmoDntTp9cfMF/D0wk8TfdyovDjrS qs2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789621931; x=1790226731; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=KCIuSRrWRr6ZhyjbWuzbQFsE0KRSs9atqvR0PaqwdCE=; b=TIEgJQARvQ2S4upWnebkU4cIJaohEareZb3GYiy9saGC0oZyVOIFMFeYoM1BCPY3Wm 5HBEQEhDG/oCfGgTld4LFtP4Bcm8iy2hdZ+K9Og+z47sVP0VSOYzIzTk8RdAFZoTU1Xz T0U+I0n0P/BKby8RfbXczl0+CTWrnuXmYuEhjXj8neyWhQakFHlCcwCX3rxx53wqodr5 bZPMXY87A+z65+pDT85av3clCMaIAyXbloRjlfRKExZSFwP0wFiKMxTimhVbe118/Xzc htRSQeoWzUPZ/eDSefU8Feh1QOHaLjrAoON+n0coSIxC59PBDSnfCLF6aR6MaebXAPG+ bnPQ== X-Forwarded-Encrypted: i=1; AKwUvBy7qAsFFmi/kZH23ESYF3sdKI/LuiQX5HwKp93zR8ELv3T/iacETqeZ6HqrZPVYBTeEkHKRtwXvkLA=@lists.xenproject.org X-Gm-Message-State: AFuF++kNnwEfLJdHajgh2+vVfGxpzwWRHRVP9ogm1IXWFNZ/ESR8uSTM 5leS1ggOaG4xu6UIovEnlQymDYGHkNEQS/8ogGGn1+SsirnG7ZJwcsb3 X-Gm-Gg: AYBFou0Bjb/vlmwlx1E6XosR7WsgHX6LcEE1Rx1dq0QA6vm8W3rv2tSK8Pr3wAEINYJ hzyjRAU9qIT/eXAYef3vi+XLzeZIAU3xJNqrl4+nZ/j8cpSeQCW+lV0dE3Ot79mHbmjPwWJekm0 TBsu7Wv9K6ch/vwRpYrUzGdPmI8+uyJIHVnmOSDRfGyoxOydtRBdslT+jYYwwycD0Agd8tFebiP 04xXXe+Ac0QSdT1bUdXFQbRkSn+VkzZeIAQIiA6eFFUSrc1+KlHHYjYox9GFedy/6AzCOQuy0j3 bsVQ0OZ6thYm60pBCSEt5A63fcSxGQ6L8DxiKB90lY9nnmHLqowaLqCx34aC7+LY9IsJlNTcXNS QagidB6d3CseZ2h5SW31wAa2evbtcPsK6pbU0T2qvGAeURT2Jx3jGUiI7lKtxRikuA7CAXCwFgF 5EgGZ6SCsfmdqtszuGe3nAERlrNJJ8cl2w52XXOTB0y4vrhCE0ZkGg/FcQeBZvCC1CU49TUYFS0 8YL3Jz7WMS7tvo688pRqAUdw3Jpm322YgaCU+agfq9GJG765zqwLB8pTQ== X-Received: by 2002:a05:600c:1392:b0:49c:fa20:cc02 with SMTP id 5b1f17b1804b1-49eb732df6amr57663045e9.25.1789621931080; Wed, 16 Sep 2026 22:12:11 -0700 (PDT) Message-ID: <0d13b587-0920-4958-9a17-425d1a23d51e@gmail.com> Date: Thu, 17 Sep 2026 07:12:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> <52c8ca00-423a-4c91-a60d-a1662d20a012@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <52c8ca00-423a-4c91-a60d-a1662d20a012@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789621931-350CDAE4-DED35D17/10/73395122804 X-purgate-type: spam X-purgate-size: 2579 On 9/16/26 3:02 PM, Jan Beulich wrote: > On 16.09.2026 07:55, Oleksii Kurochko wrote: >> On 9/14/26 2:12 PM, Jan Beulich wrote: >>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>> --- a/xen/arch/riscv/imsic.c >>>> +++ b/xen/arch/riscv/imsic.c >>>> @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, >>>> >>>> void imsic_migrate_vcpu(struct vcpu *v) >>>> { >>>> + /* >>>> + * The scheduler can mark a freshly created vCPU's unit as migrated and >>>> + * invoke this before the vCPU has ever run (see the migrated branch in >>>> + * schedule()). No need to do migration for such vCPUs as they aren't fully >>>> + * initialized (for example, context_switch() will be called after >>>> + * imsic_migrate_vcpu()). >>>> + */ >>>> + if ( v->arch.last_cpu == NR_CPUS ) >>> >>> May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a >>> good sentinel. If we/you decided to switch to ~0, >= here would continue to >>> be correct. >> >> I agree with >= but I am not quite sure that I fully understand what is >> wrong with NR_CPUS. We have for example the following: >> >> static inline unsigned int smp_processor_id(void) >> { >> unsigned int id = tp->processor_id; >> >> BUG_ON(id >= NR_CPUS); >> >> return id; >> } >> >> So it is guaranteed that NR_CPUS what be used as cpu id and so it still >> could be considered as a good sentinel. > > Arbitrary numbers can be problematic when used as a sentinel. If you look > at disassembly, you may not recognize that number as a sentinel. Further > there's also a code-gen concern: ~0, aiui, will always generate the same > code (to e.g. load into a register). NR_CPUS, depending on .config, may > not. The value may not be loadable by a single insn. Witch such explanation it started to be more sense in it. I will introduce then /* Value of arch_vcpu.last_cpu for a vCPU which hasn't run yet. */ #define VCPU_NEVER_RAN (~0U) and use it to work with v->arch.last_cpu. Just to be sure that I understand correctly your suggestion with ~0U is only for the case of ->last_cpu and check if vcpu was ran or not. For struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { .processor_id = NR_CPUS, }}; and struct vimsic_state { ... /* * s/w IMSIC VS-file -> vsfile_cpu == NR_CPUS * h/w IMSIC VS-file -> vsfile_cpu < NR_CPUS */ unsigned int vsfile_cpu; }; I can continue to use NR_CPUS, right? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 17 05:21:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 05:21:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423646.1648619 (Exim 4.92) (envelope-from ) id 1x74YJ-0005HS-St; Thu, 17 Sep 2026 05:20:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423646.1648619; Thu, 17 Sep 2026 05:20:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x74YJ-0005HL-QK; Thu, 17 Sep 2026 05:20:55 +0000 Received: by outflank-mailman (input) for mailman id 1423646; Thu, 17 Sep 2026 05:20:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x74YH-0005HF-NY for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 05:20:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x74YG-0013Uh-IW for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 07:20:52 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab78ab-2eae-0a2a0a5409dd-0a2a4502ba0e-8 for ; Thu, 17 Sep 2026 07:20:52 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab78b3-6ca4-0a2a45020019-4a7de18cf8ff-3 for ; Thu, 17 Sep 2026 07:20:52 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e2406so1831965e9.1 for ; Wed, 16 Sep 2026 22:20:52 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e847fcbdfsm83662125e9.4.2026.09.16.22.20.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2026 22:20:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789622451; x=1790227251; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=TndC/rN9SBBgQkXeBDyMqo06diiHoj5sgSiTaP7wOIY=; b=Uu6A5BxqknrA6TnbglbHYtOoso2wF4KUfHtXCMUZhyhifdwYaYYOmSTVCudVp0pWZ0 rA253RrP2vGzEMBICuwJLDldoMQh0EAHavmaN22VOJsrpkAD98P7YbOwObYt1xUycfXt BbW4o/KsrVWR1t1sOevND92nWo1oBfd+fCcsAt05pqTEx86QGCai74fdUCw/BzRvTLc4 9HhIUQfIzvo4QoyCQ1ePbgyIogwBHMArKGgT61JEvO021TKUIpzoPSt+birAJ+TPSwDo xqi4KFoyCb7sg/Pc2tAlsC0xrECDwzCjOXYdtRieSxwVBV4+mEgL/jbKOrTggZGvFUVe +yBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789622451; x=1790227251; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=TndC/rN9SBBgQkXeBDyMqo06diiHoj5sgSiTaP7wOIY=; b=LL8LnUzMDaVAbspo4aTE6T+r1hIrr0kMxWvViUlz+EWQbMR9HH3ACeUqGZm56aDwyz FRaGgzpjNUiyg6M4a7EyFL8RyB7PU7d3jc8/5h4lTa68dz6WcAJzh3SdfZDhTp8loSs9 D8oavafsMbF1TPHTt2gai+4ljD0odr86lxzL+bpo31Dkchcunl5y3rmQH3Kxhycyjmcs l3nVe1htG0LTy18Lx6cyemdIz7htF2M2eeJaDgArfOf8uNF4+gUVyYrL3la7kHBA7WxA qL6SG6w9dO4aXNb+2BGurqk/+j7GPesyBpWxQzGQAmlq3HOIT3k/+ZRHfJP/pB5GMv/J ruMQ== X-Forwarded-Encrypted: i=1; AKwUvBxFNrZTJQSZC8uwPue/ojaiTvq0r85zMuew3b3UzxDWyLFK0zuoVY30jXEBx1rsm5ht4Cpjyt7l0B8=@lists.xenproject.org X-Gm-Message-State: AFuF++lxa0VJy4N+s+Kr5LaVLdYDkZplF7k5IQD1H3fSxoY3W3IQlWMw WOkhOXwGPpOhjyq9UJ/ayNLswNiWF1x9PXgmBSE+6shKT0WylcjJLc6mYTsXBnSiiQ== X-Gm-Gg: AYBFou1kMumISQgXjul+HVhwBpBVqtwQ7jcvvI04q6UKetuJB5PrffkqcWaK8ELskQd yHPFRYG6T3xScoYVrKO5w8AAJYJ1AOFQysWzEtvMrEP6WobsdsDKHIouS1o9ZDhis9lyT5J2O6r xzagdls0A4QKSADMW95SoO5ze0IOTzZMFN95cX8wvbW87dGQX24LKZsjR1F7Ri4eSUu2U6VW2I4 J4RGTgfXwhBFAnvHRRBTazojJo46cM8gono27H3q2JXNvKIEKT6kjsh2CvneHTTnTnqYecMe0Aj BaN9LeplbpgvwMmNDc6zqMDg+xB8vgMzeU1x5Cb5HzYolgmL/4NUK/5mBfc86zLZRHvRFbL3d0y 9kkcq4Likf2MVaECVqG42LWULFO7KpsiF/iPVobZWu7xVG6cAjXLL/mrHsZT+J7sGabt0K0XuJZ BUN0G86TofKtOwEBWn/gzP9Xto1Liufs5XkUpMnfoECMHIhv+VGB8tdeDB5ocMpMUIxVIiTY5eV xo= X-Received: by 2002:a05:600c:4796:b0:49d:257c:a735 with SMTP id 5b1f17b1804b1-49fbd1ddf38mr13099805e9.11.1789622451583; Wed, 16 Sep 2026 22:20:51 -0700 (PDT) Message-ID: <16ffbf4e-0178-4089-b279-d39e97ab885f@suse.com> Date: Thu, 17 Sep 2026 07:20:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> <52c8ca00-423a-4c91-a60d-a1662d20a012@suse.com> <0d13b587-0920-4958-9a17-425d1a23d51e@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <0d13b587-0920-4958-9a17-425d1a23d51e@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789622452-F12A12AC-48FDC98D/0/0 X-purgate-type: clean X-purgate-size: 3000 On 17.09.2026 07:12, Oleksii Kurochko wrote: > > > On 9/16/26 3:02 PM, Jan Beulich wrote: >> On 16.09.2026 07:55, Oleksii Kurochko wrote: >>> On 9/14/26 2:12 PM, Jan Beulich wrote: >>>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>>> --- a/xen/arch/riscv/imsic.c >>>>> +++ b/xen/arch/riscv/imsic.c >>>>> @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, >>>>> >>>>> void imsic_migrate_vcpu(struct vcpu *v) >>>>> { >>>>> + /* >>>>> + * The scheduler can mark a freshly created vCPU's unit as migrated and >>>>> + * invoke this before the vCPU has ever run (see the migrated branch in >>>>> + * schedule()). No need to do migration for such vCPUs as they aren't fully >>>>> + * initialized (for example, context_switch() will be called after >>>>> + * imsic_migrate_vcpu()). >>>>> + */ >>>>> + if ( v->arch.last_cpu == NR_CPUS ) >>>> >>>> May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a >>>> good sentinel. If we/you decided to switch to ~0, >= here would continue to >>>> be correct. >>> >>> I agree with >= but I am not quite sure that I fully understand what is >>> wrong with NR_CPUS. We have for example the following: >>> >>> static inline unsigned int smp_processor_id(void) >>> { >>> unsigned int id = tp->processor_id; >>> >>> BUG_ON(id >= NR_CPUS); >>> >>> return id; >>> } >>> >>> So it is guaranteed that NR_CPUS what be used as cpu id and so it still >>> could be considered as a good sentinel. >> >> Arbitrary numbers can be problematic when used as a sentinel. If you look >> at disassembly, you may not recognize that number as a sentinel. Further >> there's also a code-gen concern: ~0, aiui, will always generate the same >> code (to e.g. load into a register). NR_CPUS, depending on .config, may >> not. The value may not be loadable by a single insn. > > Witch such explanation it started to be more sense in it. > > I will introduce then > > /* Value of arch_vcpu.last_cpu for a vCPU which hasn't run yet. */ > #define VCPU_NEVER_RAN (~0U) > > and use it to work with v->arch.last_cpu. > > Just to be sure that I understand correctly your suggestion with ~0U is > only for the case of ->last_cpu and check if vcpu was ran or not. > > For > > struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { > .processor_id = NR_CPUS, > }}; > > and > > struct vimsic_state { > ... > /* > * s/w IMSIC VS-file -> vsfile_cpu == NR_CPUS > * h/w IMSIC VS-file -> vsfile_cpu < NR_CPUS > */ > unsigned int vsfile_cpu; > }; > > I can continue to use NR_CPUS, right? You _can_ everywhere. It may merely be beneficial to use ~0 instead, at least in some cases. The "how to load value into a register" aspect of course doesn't affect static initializers. The "easy to recognize" one, otoh, may apply there as well. You get to judge... Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 17 06:02:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 06:02:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423669.1648638 (Exim 4.92) (envelope-from ) id 1x75Ce-0002Oo-2y; Thu, 17 Sep 2026 06:02:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423669.1648638; Thu, 17 Sep 2026 06:02:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x75Cd-0002Oh-W7; Thu, 17 Sep 2026 06:02:35 +0000 Received: by outflank-mailman (input) for mailman id 1423669; Thu, 17 Sep 2026 06:02:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x75Cd-0002OP-6B for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 06:02:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x75Cc-004exF-JK for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 08:02:34 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab8274-bab6-0a2a0a5309dd-0a2a450bc814-40 for ; Thu, 17 Sep 2026 08:02:34 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab8279-b7e8-0a2a450b0019-a237832fc870-3 for ; Thu, 17 Sep 2026 08:02:33 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 2EE194EE0091; Thu, 17 Sep 2026 08:02:33 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789624953; b=Ddrxy353OE5YXZyHrxiwSL9UYy7zY8Elkit9mV9n+a8S63EgACtXXq0Tw/GExhu3W6yY bCouFCTD29XnC6wW2/OiA/X5vg/q235zMNPNUvlsvfnH0BOW6lWXzBUp9L3iOf79GgSOm LFj6S/nh9gRAZEwi2vYbj+9ToscXfaWUKd1D50L/5x7bJCpFLlCF1+Vov7yNCCKDRniQx Kns0DKyoudOvKtqZovMqIKkYnpV+Gj5nngmBsiKsexgoYKHz4oPM3cJWGjKIDYjUNqTAm 5Pc6/Kr/0hgOI33ffKK2UMDJcPC4cnN6f+mZSAMapaXjtRFS2isV81dfSWDgAxeyW2i/z injXUVoexoP9YhI3XTmKZOjBfPqIcA4fYWfK6TIIVpeIcH1Ar5mR/7CGQJtSBpZIL2BUK 0DMZze5dk3R9wHvdIiKHzC21h2cRqPWnVqbFF8g6Dv5nnfUI1BG4qY4CfZuXt0r/7GWGF 2M0QdhNhS4+tN7lfLaSpEoyuW/lGYxDqPuQkAcimGBh45xaO7pOlnd2KODmX6zJGbWLO0 58Fu7KLwV4f/6ypszaXMHZzAgcEAulD8oEb56dmrZ5K/rGMw/xGIv3vBD8aPcAKg086Sr YN9TsinkPrWTi4ghP+x2wXdHYf+5RMqHXVQ/lIXr8c2CMIDBAL0krAgPq8JQC4s= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789624953; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=AKVD4zQmp0fABHipds2ZuwEtMrYuY5h109P153OAoyA=; b=H0HBg0OVqYzpbxJjnfbFfimcFO4bIOn6Hh57BIMrrLlIAc2iRXQxBJzEm3/z6TuNKihh w6H5CeEEcs/jPbSPMLD1LKLXrnRVB55XRUIIq7lW4EkezPQRglzwL0uhW9FPYTIC2iZOq xxL8ClBkWcg8BOroMSh24EJn2VPvmMIckayD1eGPei2Zn4NeLLjQpkr5D6WUOmjJV/O/e tjTGJPeiKPezDMMvqVD0Ewaq2tdVW1t1QQnoQ2+IbZ3j97hhsAOZKXtKRm15CTA1QYIqw ywn0j2MK5HexqqaNEFuSOJvx8GNmOztcg8Wj8Jav6uQg2hOhw5VxTghVdjUQVSHziU8m+ 2hvdXdgi02vNYwPtK14aS3gaa0XVa9/LxeWzvB5RFQMvwagY3hxPJdYAGo+TrCl4UJ34w w6qtrZ96S/mkPQ2X06+lr9iDWhsKf4VUNxSc7omJBHE3WrrKH8T/BSmF6oNost/dVtQLM O91Z9xOKnchwwRSsUA4hXWwrbiHXx75mcTsqQUJchOJcnCwQUGLCu5GLv2+65c5LeCkh/ Gp+U8lU8h8bbjbBqB7qUHF1OVSjRdIOIhEyTyi+z+55i7frUgahjldUcMfkQMO0GW3CXx sMREGm7JpuqecJjFyGYRLHDA5E8Bj9n6pJpbGFcRyCpfZ1KFkKufi4WizfS+53k= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Thu, 17 Sep 2026 08:02:33 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] Eclair: re-enable scanning of the (almost) final linking step In-Reply-To: <19fff81a-5920-4c9b-be8f-74354f88bb69@suse.com> References: <19fff81a-5920-4c9b-be8f-74354f88bb69@suse.com> Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789624953-A88C99EA-F82DFEE5/0/0 X-purgate-type: clean X-purgate-size: 1418 On 2026-09-10 11:55, Jan Beulich wrote: > The real final binaries are now no longer created by a linker > invocation, > but by renaming an intermediate file (each). Arrange for linking pass 2 > outputs to be scanned instead, yet continue to exclude the auxiliary > .xen.efi.alt.* binaries. > > Fixes: da944a72fdf4 ("x86: split xen-syms/xen.efi linking rules")) > Signed-off-by: Jan Beulich Reviewed-by: Nicola Vetrini > --- > Sadly for Arm64, until "Arm: split xen-syms linking rule" has gone in, > this will slow down analysis jobs. > > --- a/automation/eclair_analysis/ECLAIR/analysis.ecl > +++ b/automation/eclair_analysis/ECLAIR/analysis.ecl > @@ -36,8 +36,8 @@ their Standard Library equivalents." > > -doc_begin="Do not analyze intermediate linking artifacts, as they do > not differ from their final > counterparts for the purposes of MISRA C static analysis." > --file_tag+={xen_efi_tmp, "^xen/\\.xen\\.efi\\..*$"} > --file_tag+={xen_syms_tmp, "^xen/\\.xen-syms\\..*$"} > +-file_tag+={xen_efi_tmp, "^xen/\\.xen\\.efi\\.([01]|alt\\..*)$"} > +-file_tag+={xen_syms_tmp, "^xen/\\.xen-syms\\.[013]$"} > -frames+={hide, "kind(program)&&target(xen_syms_tmp||xen_efi_tmp)"} > -doc_end -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Thu Sep 17 06:02:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 06:02:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423668.1648629 (Exim 4.92) (envelope-from ) id 1x75CQ-00028Q-Nq; Thu, 17 Sep 2026 06:02:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423668.1648629; Thu, 17 Sep 2026 06:02:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x75CQ-00028I-Km; Thu, 17 Sep 2026 06:02:22 +0000 Received: by outflank-mailman (input) for mailman id 1423668; Thu, 17 Sep 2026 06:02:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x75CP-00028C-JL for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 06:02:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x75CP-004en2-0I for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 08:02:21 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab8264-e002-0a2a0a5209dd-0a2a4509db7a-28 for ; Thu, 17 Sep 2026 08:02:20 +0200 Received: from [52.101.61.47] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab826a-be1a-0a2a45090019-34653d2fc3db-3 for ; Thu, 17 Sep 2026 08:02:20 +0200 Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18) by CH8PR12MB666014.namprd12.prod.outlook.com (2603:10b6:610:32d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.11; Thu, 17 Sep 2026 06:01:51 +0000 Received: from BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::53da:e77e:261e:5a29]) by BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::53da:e77e:261e:5a29%4]) with mapi id 15.21.0428.009; Thu, 17 Sep 2026 06:01:51 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ds5xOFjkOZb98/ARRhv1YrZ4IQofj7+9JFjeP5+cztzrk/a5QWCrfRd+C963TnaKpGQOHZO46Kp5g6IJ+yAH7MHSAXzF1zLYQUahNZXENKasTPSI1qgai45Jw2vRZrUPUmFM+u+dtikjbxiuzlNeWXq1hjY58Rx8q/PeLuym8sJ9ZH/zuxccz2wYlhNM0rYvxFuRdbys8a8xQz+nB141NEwqAsPP7me0ayTP3nC732K8w2RV/yeyZirprO/jjSfq7RxDWxzhbLAa+oafM1R8NlZz+Ly7bNvjUladkGi355r/e263FrTmT2eL2su/ut63xv9lHaFoWMNtT2u0NvGiFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kGFzhJ0we7FSexsT7KsViNjB4Z9b6XRi2aPaIDaAtjg=; b=flXtSs4Vq/Xt/mQr645lGFegtLLE/2RZbSvoOUfD7+3JeiKelXUVwEL9jGo8fnxIzUV1hKkUgwwFMPXJAvG8vKfVWq10zexjO8jf3YEVs334CXXyZu7/7KhWK+f0TaJ5JOT3e4t1XFSbc3uNQvgxNrkNa+Hkfp2MYHAjBBALI7XKmRr9mLXapdYNxpRDkyqeENaZWDuEcKP9D7bXh2rKnKCxc7ytDnXMEpTO/O0IcgX7wYbS4atFiFWkqde5mrj3P6vVwofN/ydbhpRtyoF6pvMKd6shgGF1eJ0ZCWvqQJd8f6dxO3U4K5+f7mtenwo79Ey8Y4YrnX9C9442ZDiGXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kGFzhJ0we7FSexsT7KsViNjB4Z9b6XRi2aPaIDaAtjg=; b=nbNft4Vs5ucJi48dlZZqGfF0qTUIWSmFM9ugSAJWna6bi0TF5+d1ZoPy2oWHqMArdpl4nTwJOhQ6fPM6TTnEZimsG8Erb0clii7b7qpK6jIps/6pWkz7agF8M8CYYb11Ht2woPoy9zOJ027LcFI57ZUigzsPrOGJe4ndGjuVu8U= From: "Chen, Jiqian" To: Wentao Liang CC: "jgross@suse.com" , "linux-kernel@vger.kernel.org" , "oleksandr_tyshchenko@epam.com" , "Huang, Ray" , "sstabellini@kernel.org" , "xen-devel@lists.xenproject.org" , "stable@vger.kernel.org" Subject: Re: [PATCH] xen-pciback: Fix pcistub_device ref leak in pcistub_get_gsi_from_sbdf() Thread-Topic: [PATCH] xen-pciback: Fix pcistub_device ref leak in pcistub_get_gsi_from_sbdf() Thread-Index: AQHdRf6GMogNWDJZT0qc64OaPhUu9bbSzYUA Date: Thu, 17 Sep 2026 06:01:51 +0000 Message-ID: References: <20260916171141.2086627-1-vulab@iscas.ac.cn> In-Reply-To: <20260916171141.2086627-1-vulab@iscas.ac.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com (15.21.0428.008) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|CH8PR12MB666014:EE_ x-ms-office365-filtering-correlation-id: 1092a324-4976-46e4-e4d7-08df14812b0d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|22082099003|18002099003|38070700021|10067099003|11063799006|56012099006; x-microsoft-antispam-message-info: hG9ZsU5TINVKX+GvEIFpuuSQ1E0z47m8M28eZK8uqF9phSCBbEyRzdRNgGh8Q/jNRli331/g6pt5nEEaYKeYorm3nKtOnq5RU7GL2J2DRdIok4CcY/fyuOTRuLaW4QJttNPkaekkr7jKMTSUurk/e9EjSNqvDZoQOgWZqblJmaZhN3FCyE/sgsIcxoqaxn1YXFjWV5v+/SDRSO70V04v7Jf+kgQ0k1ol/JkZBOf+xSisWjTGgY7C3DGXoVWKrIFj+TUreUv/+hLTq5DUZrqzGPoFe1w6ccP5vDK2OQygXMt0YYt8q2ZqL2KVCLTrh5QByDPPHxQaHS15CO8qabAwoE5B+4vMIltns9ge3musRVflzyHcE1V98FsjUxKKOGiCGh2bYrNxwE2xipdm4cOss5/mjEIvveBy5Hv3XNdGQ7IRCFT3n1x14v/83mo5CrY9Xft8jtN2kqJi5yQJQ8YSqWfI76cvZQ0FIINgB24MnQ73dQ+UbFd2BWVR04j0OZ0xjTnJ7vKJA84rSTuSmObxLlehq+QQIm9iYOhR0mDQ+TWrTmnj/G4U1WSP/zy1D6z5hBnmv4AqazefK7tbxOKmOgWJJixPUjUPq2GnYTENbfHZIjggR+ejixqFx5jxUVANscIRdsgwdC7O3XUJKAuSJbFqg1QwELDpqAjXC6YGVnVwOa2c7fsgjpfBmD1Viloo8x1Yw456bu45tCXTXgPDRL1VXkCjNdn6NlsPSJ8tGzs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(22082099003)(18002099003)(38070700021)(10067099003)(11063799006)(56012099006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?a3hCRHk0MWtJYnRmMXFKZ1dXYVBIYW9FaE9kZk5lUlRKQ3FnVDI1K3ZDRHY2?= =?utf-8?B?WGxraWdzMjNPc3dsaG00ZGh5SHBLdnhld0h6N2FxeGpHY1VETjVGRFJXaXJp?= =?utf-8?B?Q29WYUJ3aURaUitxRU8va0Y5cHVObXhIbFF1VlltQmVKdVBBOThQK293L09z?= =?utf-8?B?Vm8vdGJibzUwTENCS3kvSGlQcHdScVN0WEt4MTFtZG1LMC9vTnJ3TXpUclZB?= =?utf-8?B?cnhucGdMdVZFSVUwS3dLRy9ncHlXQ1JZNG5FVXpkMDc0endqelFnd1ozb2Jh?= =?utf-8?B?YXVidTg5UGlvZG5zWlJRRmgxR0VBQ0lWdUUzaXdBWlYxaDBNOE55OUJWNDFC?= =?utf-8?B?dGlpaXN6UklqcCtVeEZEY0hGN0x0OC80c0twYWs0QzcvVFNmZkRFcTFIN3Qr?= =?utf-8?B?NkU2T21IakM0cS81djhlWVdEalcxcjRoZEVlclA1d1VQOVRTNW52aGc2N1VD?= =?utf-8?B?TXdSbzA5Q0crM0tDd1hCN1JpbWdlY2tWQmdEYXdkV3dlY0FwdjlvdUhZeGY0?= =?utf-8?B?U0ttSEFNSzFqQVFvRnQ5cVFCNE5TNk9pc3VURWlpelkyMmFuM0JHS21yQTVZ?= =?utf-8?B?SS9XSlczeTdCRUpqTTNTSGtic2hNcU1rT0N0YTBEcVlnNzFuSjlqV05KQzcx?= =?utf-8?B?aHI3ZTJuK21IaXdabndXY1BENW00VVpGOFJQdlFaNDdZdFU1WmtkbnB1WjdM?= =?utf-8?B?OU5SOVdueitOczdtMkVJM2xpSFpBSi9WcmxmZXdpUUdzaUJuQU5SZXhJQ3hO?= =?utf-8?B?aGs0WW9FVU9MNTBaSWVuVEtpdlh1WURGUUhrdXZCWmZjTlAvaGJlMTRrV1Fy?= =?utf-8?B?NEdIYVc2OEhWbG4rVVl1aEpQZkJzQ3pOMWxONWcrUnhvUVVHN3oxeDY2L1BO?= =?utf-8?B?ajhQOTVWQll2eFloU1dIZ015NE9lR2thamFLd0JpeHpxR2tTaTdGOUlOZ0NF?= =?utf-8?B?bG5zNUlkZjhpcDMyd1dRckRPSG5QRHdOWXJpdlFsVk9SQ0FrZVlXc2F5VWVq?= =?utf-8?B?engrQW1LWDV3bEIySFNMODZoZit2L2h5ZVFSdjMveDFFNkFRV204WUJVY3Fh?= =?utf-8?B?UXo1emRPUlF4RC9TRHpJVHFCR1hISW8xZmwydnU2U0dTckxpS2tGRUJOSlJH?= =?utf-8?B?d2tlUzI3Qk9XOFBlUXJObmpXNU9BQlZkbTFhc0tSa29OUE1hMkRuUDRNRzNI?= =?utf-8?B?c0dEMmZGWmR5NjFLZm5wOUhkeXIxZnh4dlNMcnhISzZEalZrYzZ3ckdxUlRW?= =?utf-8?B?R3hpSE0xcTNpWDRaL1Y5MGdRZ1AxSE9OMWU1MnBLMkJDT0pYWWJnRUllMnNG?= =?utf-8?B?TVgxVGtQc1k3WTZkaTBsZXFqSmJUMTVUMjhpUkpVaENqRzdPUjF1Yk1RVkJq?= =?utf-8?B?L2tsYlFFRjgraDJDODAwRDE3RkdpOHVtcExCZjhjNWNNaHhGcmhjMWkrZzlr?= =?utf-8?B?by8zZURSdFVnaVYyZDVnYURMVkV2OGh6MGF5ZGVKYmppWEJMaDFpdjhuYWhx?= =?utf-8?B?clR1QkFnM2U3cDJKNFhISDl4eWo2RzNtelZGcW80MkhQSFM4TDl0RGZwSzFW?= =?utf-8?B?dmtaQ2pUay8yVEVxZThRUWtoSjRpRlJnZldMeEVIVHppSDFCK1pXUDByUlJD?= =?utf-8?B?VjVSbWZsOHdNa3FvYXNkNEl0NmpJYWJsZXZqSjN2N0hnamE0VUpGM0hacnVq?= =?utf-8?B?UFBtV3NMVHhlTmVmU0E4UitjUjljYUs1Mm0yc2l0eStsb1lEUlh3bzhwM3F0?= =?utf-8?B?R2U0UXdIcmpvb1VPeENibXBaMXk4dTZjOGtXYlJWZTR2SGVxRVZOdTY1WUxH?= =?utf-8?B?T0RUVUY2U0grRW9CMmYyYlBFYXVpak9iamxLSWdFUElIWi96UDl5dXUwRUhq?= =?utf-8?B?M2lWMjI1REFDaUQyOG82RG8zMHpidnY1QWs1M2hlWXphQU1GTHNxUkxGODI2?= =?utf-8?B?WHRyT0pZSnBMd2tkSFZ5TEFsZnZySDVPR205Vk5ieU1LWEhkL1NoM2FmN1Fp?= =?utf-8?B?S1NxUVdOVFZBRnFYdzUwc05Ca2hSSGF4SVpRcnFFUnVFaVBodjRibkQ2WHZC?= =?utf-8?B?cGpMb25zQnN0WnJPOHM0NktRYWVMcEpxdmo5Nk5oU3J4S0pjeWhWV01JY1VC?= =?utf-8?B?WFpIRDY2SkRNTXFDZ3U0ZU42U3Y1ZUJOUXlVbHQxRk1EV1JWUkZDbU5kVTBm?= =?utf-8?B?MG5ZV3NGOTNuYUk3bDE0RWpteDJrQm40L2NlZlczdW5aQkdVSEhjS3c4ZEkr?= =?utf-8?B?THJlR2pGSTFuM3RwbkxkNnVJSTQ0QjJRZGRUZ2wyVkcrYlJnWTMzSXdITmtL?= =?utf-8?Q?xtiJZ/9EmsBrwABjx5?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1092a324-4976-46e4-e4d7-08df14812b0d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2026 06:01:51.4641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NH27bbiF2hotpvENcQVZKXrpDmN5dEO6xI4yI0wkyZTBri+3TNI/845/gs+012xerHdcpgIzJ57kkCHVLhpzwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR12MB666014 X-purgate-ID: tlsNG-bad1c0/1789624940-BDAC0034-951ED2E9/0/0 X-purgate-type: clean X-purgate-size: 1922 T24gOS8xNy8yNiAwMToxMSwgV2VudGFvIExpYW5nIHdyb3RlOg0KPiBwY2lzdHViX2dldF9nc2lf ZnJvbV9zYmRmKCkgb2J0YWlucyB0aGUgc3R1YiBkZXZpY2Ugd2l0aA0KPiBwY2lzdHViX2Rldmlj ZV9maW5kKCksIHdoaWNoIHJldHVybnMgaXQgd2l0aCBpdHMga3JlZiBpbmNyZW1lbnRlZCwgYW5k DQo+IHJldHVybnMgcHNkZXYtPmdzaSB3aXRob3V0IGRyb3BwaW5nIHRoYXQgcmVmZXJlbmNlIGFn YWluLiAgVGhlIGNhbGxlcg0KPiBjYW5ub3QgcmVsZWFzZSBpdCBlaXRoZXIsIHNvIGV2ZXJ5IGxv b2t1cCBsZWFrcyBvbmUgcmVmZXJlbmNlIHRvIHRoZQ0KPiBzdHViIGRldmljZS4NCj4gDQo+IFJl bGVhc2UgdGhlIHJlZmVyZW5jZSBhZnRlciByZWFkaW5nIGdzaS4NCj4gDQo+IEZpeGVzOiAyZmFl NmJiN2JlMzIgKCJ4ZW4vcHJpdmNtZDogQWRkIG5ldyBzeXNjYWxsIHRvIGdldCBnc2kgZnJvbSBk ZXYiKQ0KPiBDYzogc3RhYmxlQHZnZXIua2VybmVsLm9yZw0KPiBTaWduZWQtb2ZmLWJ5OiBXZW50 YW8gTGlhbmcgPHZ1bGFiQGlzY2FzLmFjLmNuPg0KVGhhbmtzLg0KUmV2aWV3ZWQtYnk6IEppcWlh biBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KDQo+IC0tLQ0KPiAgZHJpdmVycy94ZW4veGVu LXBjaWJhY2svcGNpX3N0dWIuYyB8IDcgKysrKystLQ0KPiAgMSBmaWxlIGNoYW5nZWQsIDUgaW5z ZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3hl bi94ZW4tcGNpYmFjay9wY2lfc3R1Yi5jIGIvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNpX3N0 dWIuYw0KPiBpbmRleCA3OWEyYjVkZmQ2OTQuLmQxYTMzNTIzM2FhYiAxMDA2NDQNCj4gLS0tIGEv ZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNpX3N0dWIuYw0KPiArKysgYi9kcml2ZXJzL3hlbi94 ZW4tcGNpYmFjay9wY2lfc3R1Yi5jDQo+IEBAIC0yMzQsMTMgKzIzNCwxNiBAQCBzdGF0aWMgaW50 IHBjaXN0dWJfZ2V0X2dzaV9mcm9tX3NiZGYodW5zaWduZWQgaW50IHNiZGYpDQo+ICAJaW50IGJ1 cyA9IFBDSV9CVVNfTlVNKHNiZGYpOw0KPiAgCWludCBzbG90ID0gUENJX1NMT1Qoc2JkZik7DQo+ ICAJaW50IGZ1bmMgPSBQQ0lfRlVOQyhzYmRmKTsNCj4gKwlpbnQgZ3NpOw0KPiAgDQo+ICAJcHNk ZXYgPSBwY2lzdHViX2RldmljZV9maW5kKGRvbWFpbiwgYnVzLCBzbG90LCBmdW5jKTsNCj4gLQ0K PiAgCWlmICghcHNkZXYpDQo+ICAJCXJldHVybiAtRU5PREVWOw0KPiAgDQo+IC0JcmV0dXJuIHBz ZGV2LT5nc2k7DQo+ICsJZ3NpID0gcHNkZXYtPmdzaTsNCj4gKwlwY2lzdHViX2RldmljZV9wdXQo cHNkZXYpOw0KPiArDQo+ICsJcmV0dXJuIGdzaTsNCj4gIH0NCj4gICNlbmRpZg0KPiAgDQoNCi0t IA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQoNCg== From xen-devel-bounces@lists.xenproject.org Thu Sep 17 06:39:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 06:39:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423695.1648647 (Exim 4.92) (envelope-from ) id 1x75lt-0006jE-MA; Thu, 17 Sep 2026 06:39:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423695.1648647; Thu, 17 Sep 2026 06:39:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x75lt-0006j7-JF; Thu, 17 Sep 2026 06:39:01 +0000 Received: by outflank-mailman (input) for mailman id 1423695; Thu, 17 Sep 2026 06:39:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x75ls-0006j1-GK for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 06:39:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x75lr-0005me-PA for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 08:38:59 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab8af7-2eae-0a2a0a5409dd-0a2a4503e78c-32 for ; Thu, 17 Sep 2026 08:38:59 +0200 Received: from [74.125.225.91] (helo=mail-wr2-f27.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab8b03-fae8-0a2a45030019-4a7de15b80be-3 for ; Thu, 17 Sep 2026 08:38:59 +0200 Received: by mail-wr2-f27.google.com with SMTP id ffacd0b85a97d-4843796e373so249001f8f.1 for ; Wed, 16 Sep 2026 23:38:59 -0700 (PDT) Received: from [10.59.1.64] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf3494dsm12056011f8f.28.2026.09.16.23.38.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2026 23:38:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789627139; x=1790231939; darn=lists.xenproject.org; h=content-type:in-reply-to:autocrypt:from:content-language:references :to:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ktheWUwpwG5PoeERgvM5/E/d83cgmcpzEL2QKfm5nmo=; b=KBRrmDp1hq2R4QOqLno7JMiH6A6rhv2AVpGQIVpIVUuZYglUmQAncClGSIxGmnROMH LeXNkESDPE5XjtEZpjzibtJV5A5jASn6vEYMuLFM5OE1hzEZ4nFqji0SdRs6ge20fg0h Bu6PP8H1+zLJznVYvAwh1pFzy4zJOIxe1k32YTvq5h4VVfJMCRKdNfF7/e/n6vK48Prz hinN6KCRBnUULKcftN65p4qbNWQbq8MHE30J9eyAVYBezW+LVybOWMR0qc3EhP82NWO0 7eOayTi8NWPf4xQQ9Vp0dI6L0zIT5SDOmO3H0MgJeAScfEfHrkM9Y85OC1d9DjRcKxIF 3FOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789627139; x=1790231939; h=content-type:in-reply-to:autocrypt:from:content-language:references :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 :content-type; bh=ktheWUwpwG5PoeERgvM5/E/d83cgmcpzEL2QKfm5nmo=; b=cpPGt+y1LRdnVDBbakRfLSgOXiIP8VmEaAtxQZenITZgnSFfj+XblTAk/BrusNhjR1 bXIqEDKrVaATi6VAftO4tlwP6rU6o0pCk/tTShih7+x8lITBarg7xxrW345XTu4Hzinx g/jNLDlNV+tFNQzW8OyMWfd7DQyRtG9O3VIOxnbn4689t1osaacmlTAAP+8LxtaV1mZM HawHqViNrRuHMutouFhKtjRYaqkVOqxg7hTWv+/LHkENwq87ci2xOvmw7YUhdV1XGAhe JhQ4fJZh5LcdPhkYZgOCSuh8nDm7Sia1SWkZN7L21c/bQvD3zkCvFlY9XeJZxLNlry6n 6fhw== X-Forwarded-Encrypted: i=1; AKwUvBxG3Q3zbxFd5RGzrAmY3scaHpPEzMGaFxlYYax14f7GvuJ7ByRrlkUUAOjlAd8bJg+HAFqlrUzSwj8=@lists.xenproject.org X-Gm-Message-State: AFuF++nUiUkN6g8TIpWkZxAMp7qXbs/GwN9MGJ4itEAhQEacKyJNoNrw /LF1hUzrNLwQCUKtvwMtL3AEhEGLnGXc3PSBewtVxhxV2x3Uq0mTBsQETrD3DSj1LOn3S3w5eeN 1j2Ds X-Gm-Gg: AYBFou2mYO/U5F0lpVtcBoXvZJBhz+snb7gE019TQJoKi5hxwIAhbrknOEknfNy2HdZ TnTJzPrIY/UeLO121O6nwc0TS5PB3yfNntSixTk103w//k1hbbi8T39qhhoHQc43s8yYce5a8xK XKTFNKnVg8nLbrBD2Atl6tzDkfii2RpHM2umEVu54rmTdH23A78YoqsnFBwG+aBIwcMCuzu5ctz c0edipT5hxozyUPT7ygEwbVJ6kpyS7G3aWpbUj5DUwoAtvHcZSHa8L4UsfmxrNXOz1ZfkUVkMhi Aswo8hhst29YeuovMZTZWrOgNG2MSxtPaWnUfp+FOCzc0X1ERZvkaQLNncU8q9nI805ecB4Yvdm SVS6nWchybKkwAiNVM4hSAYsQTCR4f6chojs1nr1dXeoziXsihokGWQJFo47plyPe5eo2UQ/SVo KYk0luNGC/v6W+z+kokoxxH6TzRMqhzpE0zHjkMDv9EZead07gpj4gUi9uI+rQf+Y= X-Received: by 2002:a05:6000:2c06:b0:487:57a:a9bf with SMTP id ffacd0b85a97d-4870cf39f0fmr6745443f8f.18.1789627139036; Wed, 16 Sep 2026 23:38:59 -0700 (PDT) Message-ID: <66290300-a861-4318-bb2c-e0c4cdcf3ab9@suse.com> Date: Thu, 17 Sep 2026 08:38:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: fix comment typo in xen.h To: Andrew Cooper , Ruslan Vagner , xen-devel@lists.xenproject.org References: Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------OToTj9qXtG023NoWepGW6A58" X-purgate-ID: tlsNG-33051d/1789627139-752854E9-500C7532/35/110847 X-purgate-type: clean X-purgate-size: 8469 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------OToTj9qXtG023NoWepGW6A58 Content-Type: multipart/mixed; boundary="------------alx37pDTXRJQwtu0P3KUYAj6"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Andrew Cooper , Ruslan Vagner , xen-devel@lists.xenproject.org Message-ID: <66290300-a861-4318-bb2c-e0c4cdcf3ab9@suse.com> Subject: Re: [PATCH] xen: fix comment typo in xen.h References: In-Reply-To: --------------alx37pDTXRJQwtu0P3KUYAj6 Content-Type: multipart/mixed; boundary="------------eDPzX0VN6fj0A0FCyeeHKgYo" --------------eDPzX0VN6fj0A0FCyeeHKgYo Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTYuMDkuMjYgMTQ6MDcsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IE9uIDE1LzA5LzIw MjYgMjo1NiBwbSwgUnVzbGFuIFZhZ25lciB3cm90ZToNCj4+IEZpeCB0aGUgc3BlbGxpbmcg aW4gY29tbWVudHMuIE5vIGZ1bmN0aW9uYWwgY2hhbmdlLg0KPj4NCj4+IFNpZ25lZC1vZmYt Ynk6IFJ1c2xhbiBWYWduZXIgPHJ1c3lhOTIyNjZAZ21haWwuY29tPg0KPj4gLS0tDQo+PiAg IGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaCB8IDIgKy0NCj4+ICAgMSBmaWxlIGNoYW5n ZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBh L2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94 ZW4uaA0KPj4gaW5kZXggNDBjOTc5M2U5ODgwLi5mOWFjYjIxODc1Y2YgMTAwNjQ0DQo+PiAt LS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgNCj4+ICsrKyBiL2luY2x1ZGUveGVu L2ludGVyZmFjZS94ZW4uaA0KPj4gQEAgLTk0LDcgKzk0LDcgQEANCj4+ICAgI2RlZmluZSBW SVJRX1hFTk9QUk9GICAgNyAgLyogVi4gWGVuT3Byb2ZpbGUgaW50ZXJydXB0OiBuZXcgc2Ft cGxlIGF2YWlsYWJsZSAqLw0KPj4gICAjZGVmaW5lIFZJUlFfQ09OX1JJTkcgICA4ICAvKiBH LiAoRE9NMCkgQnl0ZXMgcmVjZWl2ZWQgb24gY29uc29sZSAgICAgICAgICAgICovDQo+PiAg ICNkZWZpbmUgVklSUV9QQ1BVX1NUQVRFIDkgIC8qIEcuIChET00wKSBQQ1BVIHN0YXRlIGNo YW5nZWQgICAgICAgICAgICAgICAgICAgKi8NCj4+IC0jZGVmaW5lIFZJUlFfTUVNX0VWRU5U ICAxMCAvKiBHLiAoRE9NMCkgQSBtZW1vcnkgZXZlbnQgaGFzIG9jY3VyZWQgICAgICAgICAg ICovDQo+PiArI2RlZmluZSBWSVJRX01FTV9FVkVOVCAgMTAgLyogRy4gKERPTTApIEEgbWVt b3J5IGV2ZW50IGhhcyBvY2N1cnJlZA0KPj4gICAgICAgICAgKi8NCj4+ICAgI2RlZmluZSBW SVJRX1hDX1JFU0VSVkVEIDExIC8qIEcuIFJlc2VydmVkIGZvciBYZW5DbGllbnQgICAgICAg ICAgICAgICAgICAgICAqLw0KPj4gICAjZGVmaW5lIFZJUlFfRU5PTUVNICAgICAxMiAvKiBH LiAoRE9NMCkgTG93IG9uIGhlYXAgbWVtb3J5ICAgICAgICovDQo+PiAgICNkZWZpbmUgVklS UV9YRU5QTVUgICAgIDEzICAvKiBQTUMgaW50ZXJydXB0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKi8NCj4gDQo+IFRoZSBjaGFuZ2UgaXMgZmluZSwgYnV0IHRoZSBlbWFp bCBpcyB3aGl0ZXNwYWNlIGNvcnJ1cHRlZCwgd2l0aCB0aGUNCj4gY2xvc2luZyAqLyBtb3Zl ZCBvbnRvIHRoZSBuZXh0IGxpbmUuDQo+IA0KPiBJIGNhbiBmaXggdGhpcyB1cCBvbiBjb21t aXQsIGJ1dCB5b3Ugd2lsbCB3YW50IHRvIGRvdWJsZSBjaGVjayB5b3VyDQo+IGVtYWlsIGNv bmZpZ3VyYXRpb24gYmVmb3JlIHNlbmRpbmcgZnVydGhlciBwYXRjaGVzLg0KPiANCj4gQWNr ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQoNCkFu ZHJldywgeW91IGFyZSBhd2FyZSB0aGF0IHRoaXMgaXMgYSBMaW51eCBrZXJuZWwgcGF0Y2g/ DQoNCmp1c3Qgc2F5aW5nLi4uDQoNClJ1c2xhbiwgeW91IHNob3VsZCBzZW5kIGtlcm5lbCBw YXRjaGVzIHdpdGggdGhlIHJlbGF0ZWQgbWFpbnRhaW5lciAoaW4gdGhpcyBjYXNlDQptZSkg YWRkZWQgYXMgQ2M6DQoNCkFzIHRoaXMgaGVhZGVyIGZpbGUgaXMgYSBzbGlnaHRseSBtb2Rp ZmllZCBjb3B5IG9mIHRoZSByZWxhdGVkIGhlYWRlciBvZiB0aGUgWGVuDQpoeXBlcnZpc29y IHByb2plY3QsIGEgc2ltaWxhciBwYXRjaCBtaWdodCBiZSB3YW50ZWQgZm9yIFhlbiwgdG9v Lg0KDQpUaGF0IHNhaWQsDQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NA c3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------eDPzX0VN6fj0A0FCyeeHKgYo Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------eDPzX0VN6fj0A0FCyeeHKgYo-- --------------alx37pDTXRJQwtu0P3KUYAj6-- --------------OToTj9qXtG023NoWepGW6A58 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqriwIFAwAAAAAACgkQsN6d1ii/Ey80 VQf/f+ZKtYheFgiw/rKJrq4AtX5D8wuwEAlT2u/0TF/zxhx42vaAAkmMYN9R8tq5AyQE9UHtBvcc CLMiyi5uK2D62+BZougYIx/mhdaY4QTWHZsEeKR7OY7SR2HoaLzJuZfzHYvUnY2D1aHQMmwLGgqL ERTIyuHgqAFPr2KPns9EVyyfmV3Ou5v9FiJ6AnNOmJ2qsOMmv1JyU1G/pqnTSKk3GvkVDPfH00uT KSnccT61Te3TpONyDyKtskJGIss+hbIebdTz8rifeEwnZICAlsAoPJEDgKDeMru5Ld0C4AsHPfo+ Bi9iaBuX/MbMAXVoVv2mirQLcsC7EflwcQNsvy8Klg== =Zjnm -----END PGP SIGNATURE----- --------------OToTj9qXtG023NoWepGW6A58-- From xen-devel-bounces@lists.xenproject.org Thu Sep 17 07:54:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 07:54:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423730.1648675 (Exim 4.92) (envelope-from ) id 1x76wn-0000KX-FP; Thu, 17 Sep 2026 07:54:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423730.1648675; Thu, 17 Sep 2026 07:54:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76wn-0000KI-AG; Thu, 17 Sep 2026 07:54:21 +0000 Received: by outflank-mailman (input) for mailman id 1423730; Thu, 17 Sep 2026 07:54:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76wl-0000JO-W9 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 07:54:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x76wl-00Cg8p-Cw for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 09:54:19 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab9ca8-bab6-0a2a0a5309dd-0a2a45088d44-20 for ; Thu, 17 Sep 2026 09:54:19 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab9cab-f659-0a2a45080019-c387df83e14c-3 for ; Thu, 17 Sep 2026 09:54:19 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id EAA0420020; Thu, 17 Sep 2026 07:54:09 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A805F1374A; Thu, 17 Sep 2026 07:54:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id leFHHqGcq2oYPgAAD6G6ig (envelope-from ); Thu, 17 Sep 2026 07:54:09 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789631654; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sq2juZmccS1kbSX34mhsDq8iUQGA6RiaIGaDBw9BsD4=; b=pFYpzXgPW3spsAZknQedbpzIcRu9UuchSHiH1huH4wg+hCbq5j2zVSCMVwcLT1bIUZH+Sn kAFnexkhXFk+juc1HV3dot4fUGYbTrUwnUvhXpgMym1cttYcKVBsGdglEX0NAYPwE8hwQ3 j4czyznqzqYZ3Goylckb97uUPMIR76M= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789631649; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sq2juZmccS1kbSX34mhsDq8iUQGA6RiaIGaDBw9BsD4=; b=vUEGeo6SMR7PBlvsx00UDLJg5GZBi6k1i313USWy2wkz/fuSxqJgnO8C6Wz9BdnZ0ND2vd HlNR14yZd+hARXMD/RQoJmYKP8mFkv4Bdr4kUvTjr3zmJbj6HZAOpTbeHo5swWio6OxqA3 2ZCUXUbhiQSXetZgPec9kJWjEaFk4Rw= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD , Samuel Thibault Subject: [PATCH v2 2/4] stubdom: remove build of zlib Date: Thu, 17 Sep 2026 09:53:49 +0200 Message-ID: <20260917075351.37208-3-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917075351.37208-1-jgross@suse.com> References: <20260917075351.37208-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -6.80 X-Spam-Level: X-Spamd-Result: default: False [-6.80 / 50.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.996]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,sourceware.org:url,imap1.dmz-prg2.suse.org:helo]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_THREE(0.00)[4]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-purgate-ID: tlsNG-c1860d/1789631659-D795A87B-FE99E032/35/110847 X-purgate-type: clean X-purgate-size: 4648 The last users of zlib for stubdoms have been removed. Remove zlib from the stubdom build system, too. Signed-off-by: Juergen Gross Acked-by: Samuel Thibault --- config/Stubdom.mk.in | 3 --- stubdom/.gitignore | 1 - stubdom/Makefile | 25 ++----------------------- stubdom/configure | 15 --------------- stubdom/configure.ac | 1 - 5 files changed, 2 insertions(+), 43 deletions(-) diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in index 0d70d03941..59f5e955e3 100644 --- a/config/Stubdom.mk.in +++ b/config/Stubdom.mk.in @@ -11,9 +11,6 @@ STUBDOM_TARGETS := @STUBDOM_TARGETS@ STUBDOM_BUILD := @STUBDOM_BUILD@ STUBDOM_INSTALL := @STUBDOM_INSTALL@ -ZLIB_VERSION := @ZLIB_VERSION@ -ZLIB_URL := @ZLIB_URL@ - LIBPCI_VERSION := @LIBPCI_VERSION@ LIBPCI_URL := @LIBPCI_URL@ diff --git a/stubdom/.gitignore b/stubdom/.gitignore index 08f2e9b432..021ad263ff 100644 --- a/stubdom/.gitignore +++ b/stubdom/.gitignore @@ -30,4 +30,3 @@ /vtpm/vtpm_manager.h /xenstore /xenstorepvh -/zlib-* diff --git a/stubdom/Makefile b/stubdom/Makefile index 40b6ececf1..2e0d65e26b 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -102,26 +102,6 @@ $(NEWLIB_STAMPFILE): mk-headers-$(XEN_TARGET_ARCH) newlib-$(NEWLIB_VERSION) $(MAKE) DESTDIR= && \ $(MAKE) DESTDIR= install ) -############ -# Cross-zlib -############ - -zlib-$(ZLIB_VERSION).tar.gz: - $(FETCHER) $@ $(ZLIB_URL)/$@ - -zlib-$(XEN_TARGET_ARCH): zlib-$(ZLIB_VERSION).tar.gz - tar xzf $< - mv zlib-$(ZLIB_VERSION) $@ - -ZLIB_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libz.a -.PHONY: cross-zlib -cross-zlib: $(ZLIB_STAMPFILE) -$(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) - ( cd $< && \ - CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" CC=$(CC) ./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf && \ - $(MAKE) DESTDIR= libz.a && \ - $(MAKE) DESTDIR= install ) - ############## # Cross-libpci ############## @@ -250,7 +230,7 @@ cross-tpmemu: $(TPMEMU_STAMPFILE) ####### .PHONY: $(CROSS_ROOT) -$(CROSS_ROOT): cross-newlib cross-zlib cross-libpci +$(CROSS_ROOT): cross-newlib cross-libpci ####### # libraries under tools/libs @@ -477,7 +457,7 @@ clean: crossclean: clean rm -fr $(CROSS_ROOT) rm -fr newlib-$(XEN_TARGET_ARCH) - rm -fr zlib-$(XEN_TARGET_ARCH) pciutils-$(XEN_TARGET_ARCH) + rm -fr pciutils-$(XEN_TARGET_ARCH) rm -fr libs-$(XEN_TARGET_ARCH) rm -fr xenstore xenstorepvh rm -fr gmp-$(XEN_TARGET_ARCH) @@ -499,7 +479,6 @@ patchclean: crossclean .PHONY: downloadclean downloadclean: patchclean rm -f newlib-$(NEWLIB_VERSION).tar.gz - rm -f zlib-$(ZLIB_VERSION).tar.gz rm -f gmp-$(GMP_VERSION).tar.bz2 rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz rm -f pciutils-$(LIBPCI_VERSION).tar.bz2 diff --git a/stubdom/configure b/stubdom/configure index 689ff4d6ed..259d3768ed 100755 --- a/stubdom/configure +++ b/stubdom/configure @@ -636,8 +636,6 @@ NEWLIB_VERSION NEWLIB_URL LIBPCI_VERSION LIBPCI_URL -ZLIB_VERSION -ZLIB_URL INSTALL_DATA INSTALL_SCRIPT INSTALL_PROGRAM @@ -724,7 +722,6 @@ CFLAGS LDFLAGS LIBS CPPFLAGS -ZLIB_URL LIBPCI_URL NEWLIB_URL LWIP_URL @@ -1375,7 +1372,6 @@ Some influential environment variables: LIBS libraries to pass to the linker, e.g. -l CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory - ZLIB_URL Download url for zlib LIBPCI_URL Download url for libpci NEWLIB_URL Download url for newlib LWIP_URL Download url for lwip @@ -4027,17 +4023,6 @@ fi # Stubdom libraries version and url setup -if test "x$ZLIB_URL" = "x" -then : - - ZLIB_URL=\$\(XEN_EXTFILES_URL\) -fi -ZLIB_VERSION="1.2.3" - - - - - if test "x$LIBPCI_URL" = "x" then : diff --git a/stubdom/configure.ac b/stubdom/configure.ac index 6ff3ab0ee9..5ef1dead11 100644 --- a/stubdom/configure.ac +++ b/stubdom/configure.ac @@ -38,7 +38,6 @@ AC_PROG_INSTALL AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake]) # Stubdom libraries version and url setup -AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3]) AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], [https://mirrors.edge.kernel.org/pub/software/utils/pciutils]) AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], [https://sourceware.org/ftp/newlib]) AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], [https://download.savannah.gnu.org/releases/lwip]) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 17 07:54:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 07:54:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423731.1648683 (Exim 4.92) (envelope-from ) id 1x76wo-0000Y4-L9; Thu, 17 Sep 2026 07:54:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423731.1648683; Thu, 17 Sep 2026 07:54:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76wo-0000Xx-HW; Thu, 17 Sep 2026 07:54:22 +0000 Received: by outflank-mailman (input) for mailman id 1423731; Thu, 17 Sep 2026 07:54:21 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76wn-0000KC-3z for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 07:54:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x76wm-00Cg8p-HC for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 09:54:20 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab9cac-bab6-0a2a0a5309dd-0a2a450c9916-2 for ; Thu, 17 Sep 2026 09:54:20 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab9cab-f479-0a2a450c0019-c387df83e15a-3 for ; Thu, 17 Sep 2026 09:54:19 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id AE4A520020; Thu, 17 Sep 2026 07:54:19 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 5B7841374A; Thu, 17 Sep 2026 07:54:19 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id MzV5Daucq2oqPgAAD6G6ig (envelope-from ); Thu, 17 Sep 2026 07:54:19 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: smtp-out2.suse.de; none From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD , Samuel Thibault Subject: [PATCH v2 3/4] stubdom: remove pciutils Date: Thu, 17 Sep 2026 09:53:50 +0200 Message-ID: <20260917075351.37208-4-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917075351.37208-1-jgross@suse.com> References: <20260917075351.37208-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: AE4A520020 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: -4.00 X-purgate-ID: tlsNG-d25034/1789631659-51936A5B-882B7775/0/0 X-purgate-type: clean X-purgate-size: 16011 There is no user of libpci left in stubdoms. Remove libpci from the stubdom build system. Signed-off-by: Juergen Gross --- config/Stubdom.mk.in | 3 - stubdom/.gitignore | 1 - stubdom/Makefile | 32 +--- stubdom/configure | 16 -- stubdom/configure.ac | 1 - stubdom/libpci.config.h | 5 - stubdom/libpci.config.mak | 7 - stubdom/pciutils.patch | 298 -------------------------------------- 8 files changed, 1 insertion(+), 362 deletions(-) delete mode 100644 stubdom/libpci.config.h delete mode 100644 stubdom/libpci.config.mak delete mode 100644 stubdom/pciutils.patch diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in index 59f5e955e3..dc0a3b54b3 100644 --- a/config/Stubdom.mk.in +++ b/config/Stubdom.mk.in @@ -11,9 +11,6 @@ STUBDOM_TARGETS := @STUBDOM_TARGETS@ STUBDOM_BUILD := @STUBDOM_BUILD@ STUBDOM_INSTALL := @STUBDOM_INSTALL@ -LIBPCI_VERSION := @LIBPCI_VERSION@ -LIBPCI_URL := @LIBPCI_URL@ - NEWLIB_VERSION := @NEWLIB_VERSION@ NEWLIB_URL := @NEWLIB_URL@ diff --git a/stubdom/.gitignore b/stubdom/.gitignore index 021ad263ff..e5d5744361 100644 --- a/stubdom/.gitignore +++ b/stubdom/.gitignore @@ -23,7 +23,6 @@ /mk-headers-* /newlib-1.* /newlib-x86* -/pciutils-* /pkg-config/* /polarssl-* /tpm_emulator-* diff --git a/stubdom/Makefile b/stubdom/Makefile index 2e0d65e26b..8830deebce 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -102,34 +102,6 @@ $(NEWLIB_STAMPFILE): mk-headers-$(XEN_TARGET_ARCH) newlib-$(NEWLIB_VERSION) $(MAKE) DESTDIR= && \ $(MAKE) DESTDIR= install ) -############## -# Cross-libpci -############## - -pciutils-$(LIBPCI_VERSION).tar.bz2: - $(FETCHER) $@ $(LIBPCI_URL)/$@ - -pciutils-$(XEN_TARGET_ARCH): pciutils-$(LIBPCI_VERSION).tar.bz2 - tar xjf $< - mv pciutils-$(LIBPCI_VERSION) $@ - patch -d $@ -p1 < pciutils.patch - touch $@ - -LIBPCI_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libpci.a -.PHONY: cross-libpci -cross-libpci: $(LIBPCI_STAMPFILE) -$(LIBPCI_STAMPFILE): pciutils-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) $(ZLIB_STAMPFILE) - ( cd $< && \ - cp ../libpci.config.h lib/config.h && \ - chmod u+w lib/config.h && \ - echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h && \ - ln -sf ../../libpci.config.mak lib/config.mk && \ - $(MAKE) DESTDIR= CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \ - $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/ && \ - $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci && \ - $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \ - ) - ###### # lwIP ###### @@ -230,7 +202,7 @@ cross-tpmemu: $(TPMEMU_STAMPFILE) ####### .PHONY: $(CROSS_ROOT) -$(CROSS_ROOT): cross-newlib cross-libpci +$(CROSS_ROOT): cross-newlib ####### # libraries under tools/libs @@ -457,7 +429,6 @@ clean: crossclean: clean rm -fr $(CROSS_ROOT) rm -fr newlib-$(XEN_TARGET_ARCH) - rm -fr pciutils-$(XEN_TARGET_ARCH) rm -fr libs-$(XEN_TARGET_ARCH) rm -fr xenstore xenstorepvh rm -fr gmp-$(XEN_TARGET_ARCH) @@ -481,7 +452,6 @@ downloadclean: patchclean rm -f newlib-$(NEWLIB_VERSION).tar.gz rm -f gmp-$(GMP_VERSION).tar.bz2 rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz - rm -f pciutils-$(LIBPCI_VERSION).tar.bz2 rm -f lwip-$(LWIP_VERSION).tar.gz rm -f polarssl-$(POLARSSL_VERSION)-gpl.tgz diff --git a/stubdom/configure b/stubdom/configure index 259d3768ed..33a7f5095b 100755 --- a/stubdom/configure +++ b/stubdom/configure @@ -634,8 +634,6 @@ LWIP_VERSION LWIP_URL NEWLIB_VERSION NEWLIB_URL -LIBPCI_VERSION -LIBPCI_URL INSTALL_DATA INSTALL_SCRIPT INSTALL_PROGRAM @@ -722,7 +720,6 @@ CFLAGS LDFLAGS LIBS CPPFLAGS -LIBPCI_URL NEWLIB_URL LWIP_URL GMP_URL @@ -1372,7 +1369,6 @@ Some influential environment variables: LIBS libraries to pass to the linker, e.g. -l CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory - LIBPCI_URL Download url for libpci NEWLIB_URL Download url for newlib LWIP_URL Download url for lwip GMP_URL Download url for libgmp @@ -4023,18 +4019,6 @@ fi # Stubdom libraries version and url setup -if test "x$LIBPCI_URL" = "x" -then : - - if test "x$extfiles" = "xy" -then : - LIBPCI_URL=\$\(XEN_EXTFILES_URL\) -else $as_nop - LIBPCI_URL="https://mirrors.edge.kernel.org/pub/software/utils/pciutils" -fi - -fi -LIBPCI_VERSION="2.2.9" diff --git a/stubdom/configure.ac b/stubdom/configure.ac index 5ef1dead11..34a47c95e1 100644 --- a/stubdom/configure.ac +++ b/stubdom/configure.ac @@ -38,7 +38,6 @@ AC_PROG_INSTALL AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake]) # Stubdom libraries version and url setup -AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], [https://mirrors.edge.kernel.org/pub/software/utils/pciutils]) AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], [https://sourceware.org/ftp/newlib]) AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], [https://download.savannah.gnu.org/releases/lwip]) AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [https://gmplib.org/download/gmp/archive]) diff --git a/stubdom/libpci.config.h b/stubdom/libpci.config.h deleted file mode 100644 index 28c2f6ab31..0000000000 --- a/stubdom/libpci.config.h +++ /dev/null @@ -1,5 +0,0 @@ -#define PCI_OS_MINIOS -#define PCI_HAVE_STDINT_H -#define PCI_PATH_IDS_DIR "." -#define PCI_COMPRESSED_IDS -#define PCI_IDS "pci.ids.gz" diff --git a/stubdom/libpci.config.mak b/stubdom/libpci.config.mak deleted file mode 100644 index 5c8632cf07..0000000000 --- a/stubdom/libpci.config.mak +++ /dev/null @@ -1,7 +0,0 @@ -LIBZ=-lz -LDLIBS+=$(LIBZ) -PCI_OS_MINIOS=1 -PCI_HAVE_STDINT_H=1 -PCI_PATH_IDS_DIR=. -PCI_COMPRESSED_IDS=1 -PCI_IDS=pci.ids.gz diff --git a/stubdom/pciutils.patch b/stubdom/pciutils.patch deleted file mode 100644 index 5ab84d6cce..0000000000 --- a/stubdom/pciutils.patch +++ /dev/null @@ -1,298 +0,0 @@ -diff -urN pciutils-2.2.9.orig/lib/access.c pciutils-2.2.9/lib/access.c ---- pciutils-2.2.9.orig/lib/access.c 2007-02-06 11:59:43.000000000 +0000 -+++ pciutils-2.2.9/lib/access.c 2008-06-30 19:07:09.713187000 +0100 -@@ -57,6 +57,11 @@ - #else - NULL, - #endif -+#ifdef PCI_OS_MINIOS -+ &pm_minios, -+#else -+ NULL, -+#endif - }; - - struct pci_access * ---- pciutils-2.2.9.orig/lib/pci.h 2006-09-09 13:46:06.000000000 +0100 -+++ pciutils-2.2.9/lib/pci.h 2008-06-30 18:56:15.350111000 +0100 -@@ -33,6 +33,7 @@ - PCI_ACCESS_NBSD_LIBPCI, /* NetBSD libpci */ - PCI_ACCESS_OBSD_DEVICE, /* OpenBSD /dev/pci */ - PCI_ACCESS_DUMP, /* Dump file (params: filename) */ -+ PCI_ACCESS_MINIOS, /* MiniOS */ - PCI_ACCESS_MAX - }; - ---- pciutils-2.2.9.orig/lib/internal.h 2006-09-09 11:52:47.000000000 +0100 -+++ pciutils-2.2.9/lib/internal.h 2008-07-01 10:46:24.968202000 +0100 -@@ -37,4 +37,4 @@ - - extern struct pci_methods pm_intel_conf1, pm_intel_conf2, pm_linux_proc, - pm_fbsd_device, pm_aix_device, pm_nbsd_libpci, pm_obsd_device, -- pm_dump, pm_linux_sysfs; -+ pm_dump, pm_linux_sysfs, pm_minios; ---- pciutils-2.2.9.orig/lib/Makefile 2007-10-19 13:41:34.000000000 +0100 -+++ pciutils-2.2.9/lib/Makefile 2008-07-01 12:13:14.400525000 +0100 -@@ -46,6 +46,12 @@ - PCILIB=libpciutils.a - endif - -+ifdef PCI_OS_MINIOS -+XEN_ROOT=$(CURDIR)/../../.. -+include $(XEN_ROOT)/Config.mk -+OBJS += minios.o -+endif -+ - all: $(PCILIB) $(PCILIBPC) - - $(PCILIB): $(OBJS) ---- pciutils-2.2.9.orig/lib/types.h 2009-07-14 18:18:59.000000000 +0200 -+++ pciutils-2.2.9/lib/types.h 2009-07-14 18:19:16.000000000 +0200 -@@ -20,10 +20,12 @@ typedef DWORD u32; - typedef uint8_t u8; - typedef uint16_t u16; - typedef uint32_t u32; -+typedef uint64_t u64; - #else - typedef u_int8_t u8; - typedef u_int16_t u16; - typedef u_int32_t u32; -+typedef u_int64_t u64; - #endif - - #ifdef PCI_HAVE_64BIT_ADDRESS - ---- pciutils-2.2.9.orig/lib/minios.c 1970-01-01 01:00:00.000000000 +0100 -+++ pciutils-2.2.9/lib/minios.c 2008-07-01 12:31:40.554260000 +0100 -@@ -0,0 +1,106 @@ -+/* -+ * The PCI Library -- MiniOS PCI frontend access -+ * -+ * Samuel Thibault , 2008 -+ * -+ * Can be freely distributed and used under the terms of the GNU GPL. -+ */ -+ -+#include -+#include -+#include -+#include "internal.h" -+ -+static int -+minios_detect(struct pci_access *a) -+{ -+ return 1; -+} -+ -+static void -+minios_init(struct pci_access *a) -+{ -+} -+ -+static void -+minios_cleanup(struct pci_access *a) -+{ -+ shutdown_pcifront(NULL); -+} -+ -+static void -+minios_scan(struct pci_access *a) -+{ -+ void func(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun) -+ { -+ struct pci_dev *d = pci_alloc_dev(a); -+ -+ d->domain = domain; -+ d->bus = bus; -+ d->dev = slot; -+ d->func = fun; -+ -+ pci_link_dev(a, d); -+ } -+ -+ pcifront_scan(NULL, func); -+} -+ -+static int -+minios_read(struct pci_dev *d, int pos, byte *buf, int len) -+{ -+ unsigned int val; -+ switch (len) { -+ case 1: -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) -+ return 0; -+ * buf = val; -+ return 1; -+ case 2: -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) -+ return 0; -+ *(u16 *) buf = cpu_to_le16((u16) val); -+ return 1; -+ case 4: -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) -+ return 0; -+ *(u32 *) buf = cpu_to_le32((u32) val); -+ return 1; -+ default: -+ return pci_generic_block_read(d, pos, buf, len); -+ } -+} -+ -+static int -+minios_write(struct pci_dev *d, int pos, byte *buf, int len) -+{ -+ unsigned int val; -+ switch (len) { -+ case 1: -+ val = * buf; -+ break; -+ case 2: -+ val = le16_to_cpu(*(u16 *) buf); -+ break; -+ case 4: -+ val = le32_to_cpu(*(u32 *) buf); -+ break; -+ default: -+ return pci_generic_block_write(d, pos, buf, len); -+ } -+ return !pcifront_conf_write(NULL, d->domain, d->bus, d->dev, d->func, pos, len, val); -+} -+ -+struct pci_methods pm_minios = { -+ "MiniOS-device", -+ NULL, /* config */ -+ minios_detect, -+ minios_init, -+ minios_cleanup, -+ minios_scan, -+ pci_generic_fill_info, -+ minios_read, -+ minios_write, -+ NULL, /* dev_init */ -+ NULL /* dev_cleanup */ -+}; ---- pciutils-2.2.9/lib/generic.c 2007-02-06 12:00:05.000000000 +0000 -+++ pciutils-2.2.9-mine/lib/generic.c 2008-07-01 19:13:52.289949000 +0100 -@@ -74,6 +74,19 @@ - pci_generic_scan_bus(a, busmap, 0); - } - -+static u32 pci_size(u32 base, u32 maxbase, u32 mask) -+{ -+ u32 size = mask & maxbase; -+ if (!size) -+ return 0; -+ size = (size & ~(size-1)) - 1; -+ -+ if (base == maxbase && ((base | size) & mask) != mask) -+ return 0; -+ -+ return size + 1; -+} -+ - int - pci_generic_fill_info(struct pci_dev *d, int flags) - { -@@ -114,23 +127,61 @@ - if (!x || x == (u32) ~0) - continue; - if ((x & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) -- d->base_addr[i] = x; -- else -+ { -+ d->base_addr[i] = x & PCI_BASE_ADDRESS_IO_MASK; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); -+ d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_IO_MASK); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x); -+ } -+ } -+ else - { - if ((x & PCI_BASE_ADDRESS_MEM_TYPE_MASK) != PCI_BASE_ADDRESS_MEM_TYPE_64) -- d->base_addr[i] = x; -+ { -+ d->base_addr[i] = x & PCI_BASE_ADDRESS_MEM_MASK; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); -+ d->size[i] = pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4); -+ d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_MEM_MASK); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x); -+ } -+ } - else if (i >= cnt-1) - a->warning("%04x:%02x:%02x.%d: Invalid 64-bit address seen for BAR %d.", d->domain, d->bus, d->dev, d->func, i); - else - { - u32 y = pci_read_long(d, PCI_BASE_ADDRESS_0 + (++i)*4); - #ifdef PCI_HAVE_64BIT_ADDRESS -- d->base_addr[i-1] = x | (((pciaddr_t) y) << 32); -+ d->base_addr[i-1] = (x | (((pciaddr_t) y) << 32)) & PCI_BASE_ADDRESS_MEM_MASK; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); -+ d->size[i-1] = pci_size(y, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4) | -+ pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), 0xffffffff ); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, y); -+ } - #else - if (y) - a->warning("%04x:%02x:%02x.%d 64-bit device address ignored.", d->domain, d->bus, d->dev, d->func); - else -- d->base_addr[i-1] = x; -+ { -+ d->base_addr[i-1] = x & PCI_BASE_ADDRESS_MEM_MASK; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0); -+ d->size[i-1] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4), PCI_BASE_ADDRESS_MEM_MASK); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x); -+ } -+ } - #endif - } - } -@@ -154,10 +205,19 @@ - { - u32 u = pci_read_long(d, reg); - if (u != 0xffffffff) -- d->rom_base_addr = u; -+ { -+ d->rom_base_addr = u; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, reg, ~0); -+ d->rom_size = pci_read_long(d, reg); -+ pci_write_long(d, reg, u); -+ } -+ } - } - } -- return flags & ~PCI_FILL_SIZES; -+ return flags; - } - - static int -diff -uNpbE -uNpbEr pciutils-2.2.9.orig/lib/sysdep.h pciutils-2.2.9/lib/sysdep.h ---- pciutils-2.2.9.orig/lib/sysdep.h 2007-02-06 12:00:18.000000000 +0000 -+++ pciutils-2.2.9/lib/sysdep.h 2009-07-22 16:26:30.000000000 +0100 -@@ -32,6 +32,10 @@ typedef u16 word; - - #else - -+#ifdef PCI_OS_MINIOS -+#include -+#endif -+ - #ifdef PCI_OS_LINUX - #include - #define BYTE_ORDER __BYTE_ORDER -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 17 07:54:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 07:54:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423727.1648657 (Exim 4.92) (envelope-from ) id 1x76wa-0008Hd-Sn; Thu, 17 Sep 2026 07:54:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423727.1648657; Thu, 17 Sep 2026 07:54:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76wa-0008HV-OF; Thu, 17 Sep 2026 07:54:08 +0000 Received: by outflank-mailman (input) for mailman id 1423727; Thu, 17 Sep 2026 07:54:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76wY-0008HP-Uj for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 07:54:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x76wY-001WKy-Av for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 09:54:06 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab9c8f-2eae-0a2a0a5409dd-0a2a4502d5b6-42 for ; Thu, 17 Sep 2026 09:54:03 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab9c9a-6ca4-0a2a45020019-c387df829d12-3 for ; Thu, 17 Sep 2026 09:54:03 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7B62421D6E; Thu, 17 Sep 2026 07:53:54 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1C2441374A; Thu, 17 Sep 2026 07:53:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id O61BNZGcq2oIPgAAD6G6ig (envelope-from ); Thu, 17 Sep 2026 07:53:54 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789631638; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ahYh7uYAiL2VabuhXedajTNlhyXTnPPSB6lJzVtTfmw=; b=jOLTEhrLXC8jtdLc8g3X8WF1xFfnwB3CnQZ1Eyu4vhYMzvOsSLgBPX/xprf8IzY74Tuufa dWNoyDCbhwUxt2pdmjl0xcjrfoC5IZeOm/y3C9kIyl7FPkbwUHZzPPULSGtMaUEm2TzQcg 29vjRouEP0/Ep/xt2FqRG6TosCyUq3Q= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789631634; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ahYh7uYAiL2VabuhXedajTNlhyXTnPPSB6lJzVtTfmw=; b=EdpFsgfWJmDqedk1FLDXC/g01luvOiS7PWhkmVW2T0WjFpYp0NbjprAJG9E38sTk2Pt7JR 0qDETjQrVtcqbGQjSvTsHpJSaJjVE+7D8ly0Opb6qFYsT/P0huRPKaRcYPVsWTyUtTYXMQ W3AVhMg1Q+UIQRwX9w2vvlg37KYMO90= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD , Samuel Thibault , Oleksii Kurochko , Community Manager Subject: [PATCH v2 0/4] stubdom: remove building unused libraries Date: Thu, 17 Sep 2026 09:53:47 +0200 Message-ID: <20260917075351.37208-1-jgross@suse.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.30 X-Spam-Level: X-Spamd-Result: default: False [-1.30 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_CC(0.00)[suse.com,vates.tech,ens-lyon.org,gmail.com,xenproject.org]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_TLS_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,changelog.md:url]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; FREEMAIL_ENVRCPT(0.00)[gmail.com] X-Spam-Flag: NO X-purgate-ID: tlsNG-720697/1789631643-F12A12AC-DFD71D8B/35/110847 X-purgate-type: clean X-purgate-size: 2343 Pciutils and zlib are no longer used by any stubdom since removal of grub-pv, so they can be removed from the stubdom build system. Changes in V2: - removed patch 1 of V1 as already applied - added new patch 1 from another series which was not yet applied - switched sequence of patches (swapped patch 2 and 3), as the drop of pciutils is still under discussion Juergen Gross (4): tools/libxenguest: remove Mini-OS specific parts stubdom: remove build of zlib stubdom: remove pciutils CHANGELOG: add removal of grub-pv CHANGELOG.md | 2 + config/Stubdom.mk.in | 6 - stubdom/.gitignore | 2 - stubdom/Makefile | 53 +--- stubdom/configure | 31 -- stubdom/configure.ac | 2 - stubdom/libpci.config.h | 5 - stubdom/libpci.config.mak | 7 - stubdom/pciutils.patch | 298 ------------------ tools/libs/guest/Makefile.common | 15 - tools/libs/guest/xg_dom_decompress_unsafe.c | 48 --- tools/libs/guest/xg_dom_decompress_unsafe.h | 28 -- .../guest/xg_dom_decompress_unsafe_bzip2.c | 14 - .../libs/guest/xg_dom_decompress_unsafe_lz4.c | 39 --- .../guest/xg_dom_decompress_unsafe_lzma.c | 14 - .../guest/xg_dom_decompress_unsafe_lzo1x.c | 44 --- .../libs/guest/xg_dom_decompress_unsafe_xz.c | 46 --- .../guest/xg_dom_decompress_unsafe_zstd.c | 44 --- 18 files changed, 3 insertions(+), 695 deletions(-) delete mode 100644 stubdom/libpci.config.h delete mode 100644 stubdom/libpci.config.mak delete mode 100644 stubdom/pciutils.patch delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.h delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzma.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_xz.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_zstd.c -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 17 07:54:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 07:54:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423728.1648665 (Exim 4.92) (envelope-from ) id 1x76we-0008UC-2X; Thu, 17 Sep 2026 07:54:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423728.1648665; Thu, 17 Sep 2026 07:54:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76wd-0008U5-Vu; Thu, 17 Sep 2026 07:54:11 +0000 Received: by outflank-mailman (input) for mailman id 1423728; Thu, 17 Sep 2026 07:54:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76wb-0008RG-NE for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 07:54:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x76wb-000NZh-3R for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 09:54:09 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab9c8c-e002-0a2a0a5209dd-0a2a4504a7e2-48 for ; Thu, 17 Sep 2026 09:54:09 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab9ca0-b57f-0a2a45040019-c387df828450-3 for ; Thu, 17 Sep 2026 09:54:08 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 6B6E021D78; Thu, 17 Sep 2026 07:54:00 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EEFF513786; Thu, 17 Sep 2026 07:53:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id h8+cMJecq2oPPgAAD6G6ig (envelope-from ); Thu, 17 Sep 2026 07:53:59 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789631644; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0JNIg8tCy5+mq+WNUtDANvh6UPH9IaowmYkVl1naPQ0=; b=Toi+Bz32epssW3GvVacTGwxOEk2cuR/BoTdPgdcMSXu/hK8Dsz+CmrPtcr6fmVPKav0XXK liYJT1y30M/zkIT6wK/QOe6gKsSQa2bUFHffHfEBXrsFxAvfy1CZhhAbUid6B5q3jB6Ojf HnQF4saW5j8KgsBLT9QgV+qqHSwC2dU= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789631640; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0JNIg8tCy5+mq+WNUtDANvh6UPH9IaowmYkVl1naPQ0=; b=uAcK6sl41MvLRToi2/XCdHnZ1EIoyoF673GoVeZfm6P/I4yBcpo8SaIqeaU17V3h1BHhf9 rqMl61nhC41OVVWB4opJiE9whwApe1MeytRE4HjEO8Epm00hVyrUyg4PwWuoicjbwzOVCx AGwOtIpr7ZMYgLq5JsfwtNuk4l8qWTk= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD Subject: [PATCH v2 1/4] tools/libxenguest: remove Mini-OS specific parts Date: Thu, 17 Sep 2026 09:53:48 +0200 Message-ID: <20260917075351.37208-2-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917075351.37208-1-jgross@suse.com> References: <20260917075351.37208-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Level: X-Spam-Score: -6.80 X-Spam-Flag: NO X-Spamd-Result: default: False [-6.80 / 50.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.997]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid] X-purgate-ID: tlsNG-ebf023/1789631648-53CC7B50-D5E771AC/35/110847 X-purgate-type: clean X-purgate-size: 11480 The last Mini-OS use case of libxenguest is gone, so remove the Mini-OS specific parts of libxenguest. Signed-off-by: Juergen Gross --- tools/libs/guest/Makefile.common | 15 ------ tools/libs/guest/xg_dom_decompress_unsafe.c | 48 ------------------- tools/libs/guest/xg_dom_decompress_unsafe.h | 28 ----------- .../guest/xg_dom_decompress_unsafe_bzip2.c | 14 ------ .../libs/guest/xg_dom_decompress_unsafe_lz4.c | 39 --------------- .../guest/xg_dom_decompress_unsafe_lzma.c | 14 ------ .../guest/xg_dom_decompress_unsafe_lzo1x.c | 44 ----------------- .../libs/guest/xg_dom_decompress_unsafe_xz.c | 46 ------------------ .../guest/xg_dom_decompress_unsafe_zstd.c | 44 ----------------- 9 files changed, 292 deletions(-) delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.h delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzma.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_xz.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_zstd.c diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common index 86b1f160e5..47b3a52360 100644 --- a/tools/libs/guest/Makefile.common +++ b/tools/libs/guest/Makefile.common @@ -1,8 +1,3 @@ -ifeq ($(CONFIG_LIBXC_MINIOS),y) -# Save/restore of a domain is currently incompatible with a stubdom environment -override CONFIG_MIGRATE := n -endif - OBJS-y += xg_private.o OBJS-y += xg_domain.o OBJS-y += xg_suspend.o @@ -55,16 +50,6 @@ OBJS-$(CONFIG_X86) += xg_dom_x86.o OBJS-$(CONFIG_X86) += xg_cpuid_x86.o OBJS-$(CONFIG_ARM) += xg_dom_arm.o -ifeq ($(CONFIG_LIBXC_MINIOS),y) -OBJS-y += xg_dom_decompress_unsafe.o -OBJS-y += xg_dom_decompress_unsafe_bzip2.o -OBJS-y += xg_dom_decompress_unsafe_lz4.o -OBJS-y += xg_dom_decompress_unsafe_lzma.o -OBJS-y += xg_dom_decompress_unsafe_lzo1x.o -OBJS-y += xg_dom_decompress_unsafe_xz.o -OBJS-y += xg_dom_decompress_unsafe_zstd.o -endif - CFLAGS += -D__XEN_TOOLS__ CFLAGS += -include $(XEN_ROOT)/tools/config.h CFLAGS += -iquote ../../../xen/common/libelf diff --git a/tools/libs/guest/xg_dom_decompress_unsafe.c b/tools/libs/guest/xg_dom_decompress_unsafe.c deleted file mode 100644 index 21d964787d..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe.c +++ /dev/null @@ -1,48 +0,0 @@ -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -static struct xc_dom_image *unsafe_dom; -static unsigned char *output_blob; -static unsigned int output_size; - -static void unsafe_error(const char *msg) -{ - xc_dom_panic(unsafe_dom->xch, XC_INVALID_KERNEL, "%s", msg); -} - -static int unsafe_flush(void *src, unsigned int size) -{ - void *n = realloc(output_blob, output_size + size); - if (!n) - return -1; - output_blob = n; - - memcpy(&output_blob[output_size], src, size); - output_size += size; - return size; -} - -int xc_dom_decompress_unsafe( - decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size) -{ - int ret; - - unsafe_dom = dom; - output_blob = NULL; - output_size = 0; - - ret = fn(dom->kernel_blob, dom->kernel_size, NULL, unsafe_flush, NULL, NULL, unsafe_error); - - if (ret) - free(output_blob); - else { - *blob = output_blob; - *size = output_size; - } - - return ret; -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe.h b/tools/libs/guest/xg_dom_decompress_unsafe.h deleted file mode 100644 index 5bc2222076..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe.h +++ /dev/null @@ -1,28 +0,0 @@ -#ifdef __MINIOS__ -# include "../../xen/include/xen/decompress.h" -#else -typedef int decompress_fn(unsigned char *inbuf, unsigned int len, - int (*fill)(void*, unsigned int), - int (*flush)(void*, unsigned int), - unsigned char *outbuf, unsigned int *posp, - void (*error)(const char *x)); -#endif - -#define cf_check /* No Control Flow Integriy checking */ - -int xc_dom_decompress_unsafe( - decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); - -int xc_try_bzip2_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_lz4_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_lzma_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_lzo1x_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_xz_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_zstd_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c b/tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c deleted file mode 100644 index 9d3709e6cc..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c +++ /dev/null @@ -1,14 +0,0 @@ -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -#include "../../xen/common/bunzip2.c" - -int xc_try_bzip2_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(bunzip2, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_lz4.c b/tools/libs/guest/xg_dom_decompress_unsafe_lz4.c deleted file mode 100644 index 405143aa61..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_lz4.c +++ /dev/null @@ -1,39 +0,0 @@ -#include -#include -#include -#include - -#include INCLUDE_ENDIAN_H - -#define XG_NEED_UNALIGNED -#include "xg_private.h" -#include "xg_dom_decompress.h" - -#define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS - -typedef uint8_t u8; -typedef uint16_t u16; -typedef uint32_t u32; -typedef uint64_t u64; - -#define likely(a) a -#define unlikely(a) a - -static inline uint16_t le16_to_cpu(uint16_t v) -{ -#if BYTE_ORDER == BIG_ENDIAN - return __builtin_bswap16(v); -#else - return v; -#endif -} - -#include "../../xen/include/xen/lz4.h" -#include "../../xen/common/decompress.h" -#include "../../xen/common/unlz4.c" - -int xc_try_lz4_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unlz4, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_lzma.c b/tools/libs/guest/xg_dom_decompress_unsafe_lzma.c deleted file mode 100644 index 5d178f0c43..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_lzma.c +++ /dev/null @@ -1,14 +0,0 @@ -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -#include "../../xen/common/unlzma.c" - -int xc_try_lzma_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unlzma, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c b/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c deleted file mode 100644 index 356f228718..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c +++ /dev/null @@ -1,44 +0,0 @@ -#include -#include -#include -#include INCLUDE_ENDIAN_H -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -typedef uint8_t u8; -typedef uint32_t u32; -typedef uint16_t u16; -typedef uint64_t u64; - -#define likely(a) a -#define noinline -#define unlikely(a) a - -static inline uint16_t be16_to_cpu(const uint16_t v) -{ -#if BYTE_ORDER == LITTLE_ENDIAN - return __builtin_bswap16(v); -#else - return v; -#endif -} - -static inline uint32_t be32_to_cpu(const uint32_t v) -{ -#if BYTE_ORDER == LITTLE_ENDIAN - return __builtin_bswap32(v); -#else - return v; -#endif -} - -#include "../../xen/common/lzo.c" -#include "../../xen/common/unlzo.c" - -int xc_try_lzo1x_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unlzo, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c deleted file mode 100644 index 0501f7f693..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c +++ /dev/null @@ -1,46 +0,0 @@ -#include -#include INCLUDE_ENDIAN_H -#include -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -// TODO -#define XZ_DEC_X86 - -typedef uint8_t u8; -typedef uint16_t u16; -typedef uint32_t u32; -typedef uint32_t __le32; - -static inline uint32_t cpu_to_le32(const uint32_t v) -{ -#if BYTE_ORDER == BIG_ENDIAN - return __builtin_bswap32(v); -#else - return v; -#endif -} - -static inline uint32_t le32_to_cpu(const uint32_t v) -{ -#if BYTE_ORDER == BIG_ENDIAN - return __builtin_bswap32(v); -#else - return v; -#endif -} - -#define __force -#define always_inline - -#include "../../xen/common/unxz.c" - -int xc_try_xz_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unxz, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c deleted file mode 100644 index 319816a390..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c +++ /dev/null @@ -1,44 +0,0 @@ -#include -#include INCLUDE_ENDIAN_H -#include -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -typedef uint8_t u8; - -typedef uint16_t __u16; -typedef uint32_t __u32; -typedef uint64_t __u64; - -typedef uint16_t __le16; -typedef uint32_t __le32; -typedef uint64_t __le64; - -typedef uint16_t __be16; -typedef uint32_t __be32; -typedef uint64_t __be64; - -#define attr_const -#define __force -#define always_inline -#define noinline -#define __packed __attribute__((__packed__)) - -#undef ERROR - -#define __TYPES_H__ /* xen/types.h guard */ -#include "../../xen/include/xen/byteorder.h" -#include "../../xen/include/xen/unaligned.h" -#include "../../xen/include/xen/xxhash.h" -#include "../../xen/lib/xxhash64.c" -#include "../../xen/common/unzstd.c" - -int xc_try_zstd_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unzstd, dom, blob, size); -} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 17 07:54:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 07:54:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423742.1648691 (Exim 4.92) (envelope-from ) id 1x76x9-0001I6-SM; Thu, 17 Sep 2026 07:54:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423742.1648691; Thu, 17 Sep 2026 07:54:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76x9-0001Hz-PH; Thu, 17 Sep 2026 07:54:43 +0000 Received: by outflank-mailman (input) for mailman id 1423742; Thu, 17 Sep 2026 07:54:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76x8-0001Dp-Jk for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 07:54:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x76x8-001WWu-0D for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 09:54:42 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab9cc1-2eae-0a2a0a5409dd-0a2a450c8420-2 for ; Thu, 17 Sep 2026 09:54:41 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab9cc1-f479-0a2a450c0019-c387df83999c-3 for ; Thu, 17 Sep 2026 09:54:41 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5D72E2004A; Thu, 17 Sep 2026 07:54:33 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id F3B2013786; Thu, 17 Sep 2026 07:54:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id e5X5M7icq2p0PgAAD6G6ig (envelope-from ); Thu, 17 Sep 2026 07:54:32 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789631677; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rJBC93oeDjibAmlMfbYh+ITd4umiwKFoqqHnj9UduOs=; b=R2U6cixgapFJWwmKyvosULUcQ0v4ZkQKEvfo4qk3ase5SQ8SI5J0oCQcw4IBqvIxXDqYPP 9Y+CYHXtx1sHPxQRVtkmjoXiZiev6I+mKFC1q6jopy8u+ru+Tfy5Jv6E1gC83Qtp+Qsln1 ZEx78Lch15CoCMtlwrZzxQ9rJeF6Ogo= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789631673; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rJBC93oeDjibAmlMfbYh+ITd4umiwKFoqqHnj9UduOs=; b=RsBgo5pgRPOgLF+A+qmYzAf4jI1VbCbweJ5EUjsKHMxm3Qk76xcaOVpu1dTXZVvDuTTzJP fKr0HuZMPGgNBpJVBK/gJ1kLGyjZ9ytEccIJGordcg2qMrIdhYuOydS9wqu/ykLaQBM/H5 F/CFaZfdbLGNJcz4+EJLOtJDh0R8f/0= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Oleksii Kurochko , Community Manager Subject: [PATCH v2 4/4] CHANGELOG: add removal of grub-pv Date: Thu, 17 Sep 2026 09:53:51 +0200 Message-ID: <20260917075351.37208-5-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917075351.37208-1-jgross@suse.com> References: <20260917075351.37208-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Level: X-Spam-Score: -5.30 X-Spam-Flag: NO X-Spamd-Result: default: False [-5.30 / 50.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[99.99%]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[suse.com,gmail.com,xenproject.org]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[changelog.md:url,suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo]; RCPT_COUNT_THREE(0.00)[4]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FREEMAIL_ENVRCPT(0.00)[gmail.com] X-purgate-ID: tlsNG-d25034/1789631681-768DDA5B-76F77826/35/110847 X-purgate-type: clean X-purgate-size: 782 Signed-off-by: Juergen Gross --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index aa1a777dd4..a2dd01037b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,6 +23,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) The only known user was the classic-xen fork of Linux. This does not affect Xen kexec support in the kexec-tools package. - The example stubdom "c-stubdom" has been removed. + - The grub-pv stubdom has been removed. A grub-pv stubdom from an older + Xen version (e.g. 4.22) will still work with Xen 4.23. ## [4.22.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=staging) - 2026-07-30 -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 17 07:57:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 07:57:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423764.1648702 (Exim 4.92) (envelope-from ) id 1x76zb-0002F1-CY; Thu, 17 Sep 2026 07:57:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423764.1648702; Thu, 17 Sep 2026 07:57:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76zb-0002Eu-8T; Thu, 17 Sep 2026 07:57:15 +0000 Received: by outflank-mailman (input) for mailman id 1423764; Thu, 17 Sep 2026 07:57:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x76zZ-0002Ek-HL for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 07:57:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x76zY-0052OM-U8 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 09:57:12 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aab9d4b-8faa-0a2a0a5109dd-0a2a4503a8ce-36 for ; Thu, 17 Sep 2026 09:57:12 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aab9d58-fae8-0a2a45030019-4a7de14cfa23-3 for ; Thu, 17 Sep 2026 09:57:12 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485933b24c3so263864f8f.0 for ; Thu, 17 Sep 2026 00:57:12 -0700 (PDT) Received: from [10.59.21.104] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bef766dsm12873599f8f.4.2026.09.17.00.57.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 00:57:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789631832; x=1790236632; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=b25K+0eQc+w9aEdNM5ZwSZu66c3vdqimY2qbc/J0aDM=; b=zzUb5YCI/RPU52EhUDFlKOBEIYJ8JqXaLHm7ZdXDt885rFQiImxEyyEQbQuJDQ/1dt HkOP+hGLMyYg/gqAvlZpz9wAfEbO7gDeCHAb9FuWQ1Tl13TBEwlirDOgSYMrBKcsdkKR BkT+Dwye8tVrJJxhue659GXm48ZjiWbC+2i5u1EmTRodSJfQR4Ql1XSUdsaSdP9JNN3B nN9WFb/1rCF+QPhn4S7mKE16mtu4k7QcdtCc52r54hFROiFONcvRuZNZKjaG7J+EWkJ9 6Pj+yFCio7OjwSWMsKh91bzaqZ87aMQIPqsGx5WCtc03UvDc9k+RE18gkJRuf+7UCdUf XKHQ== X-Forwarded-Encrypted: i=1; AKwUvBxCjCJ1Z919gpYKUAdJmUJ007knhd3e2G3uYpk34nMyC55rTVRqcpnemv/7efQqkvVFBWwqjvva9Jw=@lists.xenproject.org X-Gm-Message-State: AFuF++k2WiYFdcs/e7s34GOxfUzR8mF/NNi1yU7PxAUc3dboKweWFAZh uVqRxaFoggaMmPyr/saD+zw0WRkvT3BF1bkGhSqH8KOgpIzYDTA8eihJ X-Gm-Gg: AYBFou0mTMe0YZZOAIbRYFgNSdAi69cXjoH/pElGmLRPEh9CrAgn+eJdej4fpBkhPHz 6wOo0ECNyVxrQEuCWETjN5HGJGHiZTjaAXbjPtloGom5Iswo+VWlYjJCcez6IeSikcwdvJWByXt 4bogwo0aUFzr4VSZ53/w0opzY3lMGQxOwGO9NmhiDd6N8sMG346/I/GUqwozWQ/D9IzrPtgon1w b5YyDEpPC9sNs3B2RPwBij1tPdOD+/ylQ8OOSz9qStVzmxxxjDqC1RTEObm3C6vT4PfIz6+wT3m 5gRPFP/cZQV61Xc8w79Y/wUeJa8FZuiXq74vMRpJ13ykOHfArSR7IzNJkZatWIf0ylMeMpsQa8H 75QhYg2+5niCCmJaPpSux9H403MZSMFKODEybuagYkLw/nYhD9icqEwEPzmsXdDPRBvsWNqHkMb ekWcqmmewe+GXhF+gFelRS3qMfcXdnfrGT0/By7+nsB9GAXSugYEszRJEOO3cl49X3eieAZEOow CEydiG6hmU/xA== X-Received: by 2002:a5d:5f43:0:b0:487:732:9964 with SMTP id ffacd0b85a97d-4870cf38810mr7279880f8f.13.1789631832213; Thu, 17 Sep 2026 00:57:12 -0700 (PDT) Message-ID: <7b6d9027-9848-4909-a5a3-16ddf56dde72@xen.org> Date: Thu, 17 Sep 2026 09:57:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 for 4.23] Add GIC SGI boot/self tests in Xen To: Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Roger Pau Monne , Doug Goldstein References: <20260916113520.3870182-1-ayan.kumar.halder@amd.com> Content-Language: en-GB From: "Grall, Julien" In-Reply-To: <20260916113520.3870182-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789631832-778C54E9-80B81624/0/0 X-purgate-type: clean X-purgate-size: 1310 Hi Ayan, On 16/09/2026 12:35, Ayan Kumar Halder wrote: > +static void __init expect_sgi(const cpumask_t *mask, > + const unsigned int *before, const char *what) > +{ > + s_time_t deadline = NOW() + MILLISECS(100); > + unsigned int cpu; > + > + for_each_cpu ( cpu, mask ) > + { > + while ( sgi_count(cpu) == before[cpu] ) > + { > + if ( NOW() > deadline ) > + panic("GIC selftest: %s: CPU%u did not receive GIC_SGI_TEST\n", > + what, cpu); > + cpu_relax(); > + } > + } > + > + printk("GIC selftest: CPU%u: %s: OK\n", smp_processor_id(), what); > +} > + > +/* > + * "All but self" is only meaningful once every CPU can take an SGI, so it is > + * run by whichever CPU observes that it is the last one to get here. > + */ > +static int __init gic_sgi_selftest(void) > +{ > + static atomic_t __initdata seen = ATOMIC_INIT(0); > + unsigned int before[NR_CPUS] = { }; Sorry I didn't spot this earlier. NR_CPUS can be quite large (up to 16K). So this will blow up the stack. There are two options: 1) Use static 2) Temporarily allocate "before" I don't have a strong opinion on which way to go with. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Sep 17 08:40:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 08:40:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423810.1648710 (Exim 4.92) (envelope-from ) id 1x77fL-00018w-NO; Thu, 17 Sep 2026 08:40:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423810.1648710; Thu, 17 Sep 2026 08:40:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x77fL-00018p-Kq; Thu, 17 Sep 2026 08:40:23 +0000 Received: by outflank-mailman (input) for mailman id 1423810; Thu, 17 Sep 2026 08:40:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x77fK-00018i-LJ for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 08:40:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x77fJ-000YWd-QT for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 10:40:21 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaba772-8faa-0a2a0a5109dd-0a2a4508d95e-24 for ; Thu, 17 Sep 2026 10:40:21 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaba775-f659-0a2a45080019-4a7de18de74e-3 for ; Thu, 17 Sep 2026 10:40:21 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso5123905e9.3 for ; Thu, 17 Sep 2026 01:40:21 -0700 (PDT) Received: from [10.72.3.52] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf33e01sm15146728f8f.23.2026.09.17.01.40.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 01:40:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789634421; x=1790239221; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=bTVpwr75FW73NN3lI8WqiuLVDo0vgH81sRu11EciCRY=; b=Ovlmy9OqKuwDFvgkykNFM0LXFHJx60NuFa92DR6qyOv/WKlpgulS0t72D0Wpc1io++ 4kqEKjATTGKgIRs7DV/Ayi+0p63/eTmborwNj/nYP3kC+t6xKKGrmAgNHLX7IkQtg4+I 2r9GcdG3P0UMBm0t1F5BdOYDpSmeGY8IfPkR6i1jG8GniIckpufqt5zbhMyBr2PO70jH rTK9W5T4T4LWmZqE2mJWm7MpeeIHrv/Hn55yxqUjfVopi+4epTpnQIvEi8e+D/f+es4J anvLByQjJgPHF1NqMJbXEqyRvu4pSUp3FIRNOzNTrekB8nu/Ma0LQZthXj6vAtjlHK0C mbZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789634421; x=1790239221; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=bTVpwr75FW73NN3lI8WqiuLVDo0vgH81sRu11EciCRY=; b=2oRdKLq8Cuombj+qGyvWlgj4lNxKps+S3TQfRTIXVL7ph5vj+ysks4lpbhmmSPmRWj bTVRFhDvSqlAtKQ2jIkwO/Rkl7s7YNnmWypnw/y4CBoaGQt6TjxCcmEZV1+BBT7cjp61 zimFlqyPmFqVmxEnOuRbgxfDdWtJMARzRoI7l/dxpeenRGxAdehhyTnxjshtlLx+bO/z aSbNBXzKxHDVVLsCceERarN0f347tnCzHZPR1P9EY1EcANWQhRA452HRUuxgTViefpS8 E7YKozzdI/fQnStCV/t2vqQXTt/dO+hbPteOxpcO+xJiamq78+add16NZxqtXPMpaEf/ gphA== X-Forwarded-Encrypted: i=1; AKwUvBxruf9ilIr64ShlKjtZlFfL5EnHcOvfg6jFTEEHff5sCCPW4pE+TB0UM+vdstAaf9z/kjvkN37QbK4=@lists.xenproject.org X-Gm-Message-State: AFuF++mY+b/5+Oe8Ea4AApNbzE5vum+zGYEbNRFENTlgLuHZW+eBczP6 g7rGZLZK5/9q/EqPpTQxey/Psn4xP/UzBukJlHB6rRYkXmZzWDRTdPKy X-Gm-Gg: AYBFou1sE/Q6NaQtyUZW3vA76TKwOoIU9Cgz6vuDz51v7bf+vpSKTYRsujLk7NzTBX6 RWNFhNyAdY1nh4UpH7QnuR6eJafONQkxQajvF/sfD9owbs6oc4ZtkPpxLqrq510muGazjCbG2Gv RWjQ4KeGubDG8uQzeZaxGdOT7VrDe3gMBdlbalFMW02Ts4xoXuTQNy+BibHD+txYVlePjjycD1j Rf8YL+ITaSCmU1DZnJeAd7dRZnx5lPHmD00nmwIoFR0uzsvYGqJpSaOovc9HMtydphPO5R+a+FR 7/6179bIxl0LhR/mmeyQPICmUEgfccnMo5C8lgTsBW1sGIymIsa//qjL+tmtjDrlcRmQMTdSiwV /2HG1wvnjdb7ebfVSu9XaspOnjqYre+wE2Hwu9ifpFkERIbz98XNVWURVV8VFqK5DLP0chTzDCQ xqTUSPjYFuG/QARSt+aNYWzZuF7EX2jBi8kgdcc7PYKX1NmJ2Yy5844FHfi+qgt5fhVUr9riHs6 gkASg== X-Received: by 2002:a05:600c:1906:b0:49e:8418:3858 with SMTP id 5b1f17b1804b1-49eb51902b2mr69856685e9.9.1789634420986; Thu, 17 Sep 2026 01:40:20 -0700 (PDT) Message-ID: <99f7bb36-14c2-474f-83e9-b36ae62a1f1a@gmail.com> Date: Thu, 17 Sep 2026 10:40:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> <52c8ca00-423a-4c91-a60d-a1662d20a012@suse.com> <0d13b587-0920-4958-9a17-425d1a23d51e@gmail.com> <16ffbf4e-0178-4089-b279-d39e97ab885f@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <16ffbf4e-0178-4089-b279-d39e97ab885f@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789634421-CD14E87B-12B266C0/10/73395122804 X-purgate-type: spam X-purgate-size: 3952 On 9/17/26 7:20 AM, Jan Beulich wrote: > On 17.09.2026 07:12, Oleksii Kurochko wrote: >> >> >> On 9/16/26 3:02 PM, Jan Beulich wrote: >>> On 16.09.2026 07:55, Oleksii Kurochko wrote: >>>> On 9/14/26 2:12 PM, Jan Beulich wrote: >>>>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>>>> --- a/xen/arch/riscv/imsic.c >>>>>> +++ b/xen/arch/riscv/imsic.c >>>>>> @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, >>>>>> >>>>>> void imsic_migrate_vcpu(struct vcpu *v) >>>>>> { >>>>>> + /* >>>>>> + * The scheduler can mark a freshly created vCPU's unit as migrated and >>>>>> + * invoke this before the vCPU has ever run (see the migrated branch in >>>>>> + * schedule()). No need to do migration for such vCPUs as they aren't fully >>>>>> + * initialized (for example, context_switch() will be called after >>>>>> + * imsic_migrate_vcpu()). >>>>>> + */ >>>>>> + if ( v->arch.last_cpu == NR_CPUS ) >>>>> >>>>> May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a >>>>> good sentinel. If we/you decided to switch to ~0, >= here would continue to >>>>> be correct. >>>> >>>> I agree with >= but I am not quite sure that I fully understand what is >>>> wrong with NR_CPUS. We have for example the following: >>>> >>>> static inline unsigned int smp_processor_id(void) >>>> { >>>> unsigned int id = tp->processor_id; >>>> >>>> BUG_ON(id >= NR_CPUS); >>>> >>>> return id; >>>> } >>>> >>>> So it is guaranteed that NR_CPUS what be used as cpu id and so it still >>>> could be considered as a good sentinel. >>> >>> Arbitrary numbers can be problematic when used as a sentinel. If you look >>> at disassembly, you may not recognize that number as a sentinel. Further >>> there's also a code-gen concern: ~0, aiui, will always generate the same >>> code (to e.g. load into a register). NR_CPUS, depending on .config, may >>> not. The value may not be loadable by a single insn. >> >> Witch such explanation it started to be more sense in it. >> >> I will introduce then >> >> /* Value of arch_vcpu.last_cpu for a vCPU which hasn't run yet. */ >> #define VCPU_NEVER_RAN (~0U) >> >> and use it to work with v->arch.last_cpu. >> >> Just to be sure that I understand correctly your suggestion with ~0U is >> only for the case of ->last_cpu and check if vcpu was ran or not. >> >> For >> >> struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { >> .processor_id = NR_CPUS, >> }}; >> >> and >> >> struct vimsic_state { >> ... >> /* >> * s/w IMSIC VS-file -> vsfile_cpu == NR_CPUS >> * h/w IMSIC VS-file -> vsfile_cpu < NR_CPUS >> */ >> unsigned int vsfile_cpu; >> }; >> >> I can continue to use NR_CPUS, right? > > You _can_ everywhere. It may merely be beneficial to use ~0 instead, at > least in some cases. The "how to load value into a register" aspect of > course doesn't affect static initializers. The "easy to recognize" one, > otoh, may apply there as well. You get to judge... > I checked how NR_CPUS is used and it is okay to change to ~0U for vsfile_cpu mentioned above as it could really affect how to load value into a register but I am not sure about .processor_id as it is just static initializer (maybe just for consistency). Also as hartid_to_cpuid() returning NR_CPUS to follow the common convention of returning an out-of-range CPU number when nothing was found (like cpumask_first() / cpumask_next() do), so callers check the result with >= rather than against a specific sentinel. If to use ~0U for vsfile_cpu then suggested name VCPU_NEVER_RAN isn't good. Then probably CPU_NONE will be better. If we will start to use ~0 instead of NR_CPUS then IIUC it won't be any sense to use ">=" suggested above and "==" could be continue to be used, right? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 17 09:53:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 09:53:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423833.1648719 (Exim 4.92) (envelope-from ) id 1x78oJ-0001K4-J2; Thu, 17 Sep 2026 09:53:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423833.1648719; Thu, 17 Sep 2026 09:53:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x78oJ-0001Jx-Fv; Thu, 17 Sep 2026 09:53:43 +0000 Received: by outflank-mailman (input) for mailman id 1423833; Thu, 17 Sep 2026 09:53:42 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x78oI-0001Jr-8c for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 09:53:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x78oG-001vNq-QV for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 11:53:40 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabb89e-e002-0a2a0a5209dd-0a2a4508d8b4-10 for ; Thu, 17 Sep 2026 11:53:40 +0200 Received: from [40.93.196.56] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabb8a2-f659-0a2a45080019-285dc438b8af-3 for ; Thu, 17 Sep 2026 11:53:39 +0200 Received: from CH0PR04CA0077.namprd04.prod.outlook.com (2603:10b6:610:74::22) by PH7PR12MB6491.namprd12.prod.outlook.com (2603:10b6:510:1f4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Thu, 17 Sep 2026 09:53:34 +0000 Received: from CH2PEPF00000148.namprd02.prod.outlook.com (2603:10b6:610:74:cafe::8e) by CH0PR04CA0077.outlook.office365.com (2603:10b6:610:74::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.12 via Frontend Transport; Thu, 17 Sep 2026 09:53:34 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH2PEPF00000148.mail.protection.outlook.com (10.167.244.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Thu, 17 Sep 2026 09:53:33 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Thu, 17 Sep 2026 04:53:33 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Thu, 17 Sep 2026 04:53:33 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Thu, 17 Sep 2026 04:53:31 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s+4oG5Zlg7rpHWOpNpubXCtWklBjhah+X60ZYr9Z9b0mqyefcxfQUQydWyE6oX0Q3X1V7Eb1WNNAC5mZuS/abCPbczdpMd7xlZX4dfjb0RVsgWmLV7EYFBTMcCPmvTSHybnj8Ul8gdEExp1vXoZGO2XUzSyC1vOhxYWppu3t94ld5MHY8nHKLmpE9jUWK6oS7vC9Moxx6FqytZpZn9MiCFOC5EBb4sx2p078qRsCCKi3KEttbLOHfm7qUZUzb0kDFX2kas5F1Gx0LE4PEK3F0uKNXZn/ho/l4oqAf5GCaKjpc4B37MgTnft6bQ5fJZ25FcQvwpFN+rwEGqvhFlmXKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i2J8t7NYslWa+wbHBKZXAQak7qxXejaVKiIYjoQCp1c=; b=mRDaXnLmlhZHorpDI0Nd73QapR6jUYCM91X/SUdsSH5QcX8ZJCOopmNRXf/2KWNw4sCuINVyc9OjEPY3SujduqV+SQNfQBXNFDWx8NFi3lXnWMQ/CEoWYPvv/aeQpi2/9eEQsImMyKZiXoH/zOyZxrViTMt/JA65PuBfO7mCn2W2MTWUagQjTZvwZ2hBiGUYoOb7WIrthSZ7vob2IIk1f5u31tt6bqDc/TuBTRZmuakbMD70WGpBLnMWlINGMe1x0ciIQsgHV7W4I7nhh7Xrg2D5lGShuVX7ZGFfNM9WxaxOluvIz4eNHygZnntxuetE6AsjyaIYP169F2bfsyHthA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i2J8t7NYslWa+wbHBKZXAQak7qxXejaVKiIYjoQCp1c=; b=G0ED7XUmNyJmrICx/qVwtJ7r1eCNC3RJrURLh258UTP9ge0YPI2I9b/Hb6fGWpADQHhJocIrQLKpwSPAaQt3gYd8rT2xYeWhQg+kgMJlUCxeEg6BPxvT5z9L+u/RH0Fb3t2O+ilJ3uLKsjYNe3WOVYeWjBtqbLe9XOxrammFjeQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <0054cd1a-1f2d-4484-b70f-419f9b5ac697@amd.com> Date: Thu, 17 Sep 2026 11:53:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] Arm/guestcopy: avoid use of "current" in compound literals To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Nicola Vetrini , Julien Grall , Stefano Stabellini , "Volodymyr Babchuk" , Bertrand Marquis References: <7424be87-9a97-4b83-b920-a8ccf4c1a889@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <7424be87-9a97-4b83-b920-a8ccf4c1a889@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000148:EE_|PH7PR12MB6491:EE_ X-MS-Office365-Filtering-Correlation-Id: 956ba756-f1d8-4ee9-5bc2-08df14a18987 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|82310400026|36860700016|18002099003|22082099003|4143699003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: 6rNK5T2sJ+g4ZmkFqKCP3gzYx8Y/MJc6w4QTB657nptAIRLaPesu7wPfslWdWc6TPyqAXKgfZFdEq/aW4FYY+zKLrw5DDYuNIa9aainU9A9KKpEv/r/31d77uLVD0h0eHdakFc8lyPIH3FRRf0ebW//SQwOnhXhug3dPNbuRYGdV6nSAeDAgJRQ6R09phBgOsoCtbiatWcxYwzyuqvk1ph9ae4Uf13z0MWhjw2yI4ZH5fKxdBOSYAFJe4iH03ggjUHnENHjTAqVbet5ooxciuEnfPoId53K94Dkow5B2+dsjZM06IZ16OhggY6EMtGVMLBAHLIQzIclPEagsM8uJTIJttuqVA02P45yZMU284y8pYKFwPqwFxXafL5q/Lpx7fIUOmGs6qHXE3t+11x3r73EkOHOAFjp44xQMKaxJxKSy6We0LNVxNmjpsnPjJImVTsWChetB4rWoVMvU8HkJLK2Ty344dpVvZvjBWOdLsHsEoCQ3C1fmaRPcnBzd8Ob83M0Miv32MGjtCt9VR25OCYHt96/dnT8r0eXCeYRrgzAo5jDcb//aIKm7L2203pX/51EkGL/0YdwoTuEMjSs9XBXbwL9bhpmWeoJU4RIzvGuVcDgeCWVnEvoJPWJEc1xi3knp05Tk63YATXxJ2rLfP/9+XVa/mN6KkPTTE8mDmtlgWkAnr8mptmLHvbcY8ZVmj4bJH6Q5p7KoO+IjIRn8Tw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(82310400026)(36860700016)(18002099003)(22082099003)(4143699003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: kH++CO0zr4Q0AjAzDF678t50AOPSFmKbGOL8UpDFjfv2zm3VnO84ZT1DZDdYo2sg3n8whUtBm3IxITLURbbmje4TJnBYer1GUAHwvCPKtwzIvY0g+qC/w47hrxhHH8b6YVTG7Vlbuar7DVyPpHITHhVygT9WZ6UMHtTG+v0e3JudO39qv4IyNIAN1AkewQOB449FND7f9XnCCIuNp51rtwZMOcGSarJR+dTmNpBZfVWlLFCWjM6gI/do9oFzV41BLOH7i5Pe8zFtpLNr3fJzgh1BSakVc/tiVzw+1t/QTI2zOAcBd6se8XneRDnKYFuKJzV4UREOlzcdkZdE9IktCswWgFQU/Xn82Czk3Ti30DUZ+bCKrEvA85Kr6je4zSKDoiyqlOP/Rgt62s3O9lviQd4F2c/gm24WAjOqo8OcbaENS3G3agqhs9/edLyItaJd X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2026 09:53:33.8979 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 956ba756-f1d8-4ee9-5bc2-08df14a18987 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000148.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6491 X-purgate-ID: tlsNG-c1860d/1789638820-D715E87B-1E5C1263/0/0 X-purgate-type: clean X-purgate-size: 508 On 03-Sep-26 13:52, Jan Beulich wrote: > Compound literals are also covered by Misra C:2012 rule 13.1 > ("Initializer lists shall not contain persistent side effects"), and > (sadly?) that rule also applies to lists with just a single element, or > more generally with just a single side effect. Use intermediate variables > to overcome this. > > No functional change intended. > > Signed-off-by: Jan Beulich Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Thu Sep 17 10:00:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 10:00:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423841.1648727 (Exim 4.92) (envelope-from ) id 1x78uc-0003TX-6f; Thu, 17 Sep 2026 10:00:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423841.1648727; Thu, 17 Sep 2026 10:00:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x78uc-0003TQ-3Z; Thu, 17 Sep 2026 10:00:14 +0000 Received: by outflank-mailman (input) for mailman id 1423841; Thu, 17 Sep 2026 10:00:12 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x78ua-0003TK-7e for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 10:00:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x78uZ-000q11-HX for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 12:00:11 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabba26-bab6-0a2a0a5309dd-0a2a4506e9e4-16 for ; Thu, 17 Sep 2026 12:00:11 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabba2a-195a-0a2a45060019-a237832f8542-3 for ; Thu, 17 Sep 2026 12:00:10 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 741554EE002F; Thu, 17 Sep 2026 12:00:10 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789639210; b=pLbJh0q1Qk4JM9ksumZnsImVcsUfKSWzhQh062FH2RsZ+fGckQqe0MhtknUVLxlfZPKk EbZS+Y1kwmFPsTx2H4agBPQc8R0U3l+H8zQNKgOXNVxjRzULV+fXsh7siavzJIVZkEqd7 b0y96//Bf3Oc5w7sFOH4NbzoZLq2yAdb0T9CvdlWkbUONrBkjdyAJhdNOjJvN4s5iBO3d hgJKHx8os7u9BgLfaCJmKYWz5C+ibzC4i/TtBQd1U92cqaWC36bROQdsY8E42MPJKFluu feEHQEHCauGnyFw8h+PD37RyKHI3J9kGCo4ZtA1VozVlAOETmvkLTSx43X5F/onLOvSkn 1FwSqK0IQV6V6TrXv8jmjohUoUChTlnxPnD92I54tuvcQpIEcC2piNZ0LNlV/E1PJmUKC 3s9vtxZQYp3TJdPTu1WwcK5RleMa/l999azEypjTw/JhLXpdwRO6/uMyBGD7DFo15rGvQ 6IaqVsW4JrQA0W0Y8aBTDuaKbG4OCPOq3es+/XlSk5eZu3H0c/4cFO/XSs/vzkDptU417 ipsfG/rpIp+aYX4H8bHS4GN7lmDD1sd0VZ9ydXAGTvgnuWfQLv7Pl6QjLB3IjI+HefcI7 /COIt5NBauAeinTVNdrCJFIWeXuK7GSqovonaQkayEiQbB0GskwDFpcQOpqfk5M= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789639210; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=jzBEGJUFucDzR5aOP7bbez8UwKFcuiJLcZvMhjGbk3M=; b=hhGI0O/gn68VfTPLygyawQM8xaPcR19w62v/MGWcMfMpNO9lny0gq8ALzuGJHNwg2/2i CBU3hWTXKTODhZPB4Q/O62kInJ+r7tqpcCWOXctWYYjw6x0q+BMIb5jQc08CFMFBFtKS/ xJv8HB9pPk5KnDZzAZ6O5hY2DFj8spjTpr6i3aYgChn1mzHY8W+HjsqAt3hv3x3bcbdA3 bRLqlQ61uNLVzaEM4UQ9sqT2pIkQCw4auuOh23JrwqV1etQpiZ5FE3xP7E+dhnpQdy3ct ifj5iihBDkWzv2i35HcefdYlCIl5HRrrPDbXdGxWw2N2y+Rz5P4xi4oWDDhJYDvji93f7 mCaM1ZCOe50G/gNgDAbOouT/SnxqvW1ngAEGtoyLpqZGwKLhrC0kfdSgu2KfxUbLLi/YO 1PA49n2+/wQ+nKG9XV/1UW2X1YCVHhWitZwj/xfhcx2uQ+bpG4HGJ+l7Jag5SNR0zslJQ w5Te+mXVJUErxPZkp1QzFcgRpbVTCcW6xPca0tmpRjU3Xfiql5Vz7yfSx6PVMEurD3YHm yX4zrjqIt74p0Ayknwe5o0gx/LoGTBhZy50lURIt+wN+LQ0cDesCWrspmKIulOMfOii7/ 66f2JCKM2M60twF/EoImA4aPU4PleWmS+hlxvI08dLGMWxm2gpJQRywcCCFTLZk= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Thu, 17 Sep 2026 12:00:10 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 4/4] automation/Eclair: tag rule 13.1 as clean In-Reply-To: <4952eacf-06ad-433e-8d0a-14b704888d21@suse.com> References: <4952eacf-06ad-433e-8d0a-14b704888d21@suse.com> Message-ID: <7c9167bafa25ae9fc359e13787b270a9@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789639210-FC60277B-ABA733C4/0/0 X-purgate-type: clean X-purgate-size: 679 On 2026-09-03 13:54, Jan Beulich wrote: > Remaining violations were addressed. > > Signed-off-by: Jan Beulich > Reviewed-by: Nicola Vetrini Supposing of course all previous patches are ready to go in > --- a/automation/eclair_analysis/ECLAIR/tagging.ecl > +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl > @@ -66,6 +66,7 @@ MC3A2.R11.7|| > MC3A2.R11.9|| > MC3A2.R12.2|| > MC3A2.R12.5|| > +MC3A2.R13.1|| > MC3A2.R13.2|| > MC3A2.R13.6|| > MC3A2.R14.1|| -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Thu Sep 17 10:41:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 10:41:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423871.1648737 (Exim 4.92) (envelope-from ) id 1x79YP-0000on-1j; Thu, 17 Sep 2026 10:41:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423871.1648737; Thu, 17 Sep 2026 10:41:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x79YO-0000og-VV; Thu, 17 Sep 2026 10:41:20 +0000 Received: by outflank-mailman (input) for mailman id 1423871; Thu, 17 Sep 2026 10:41:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x79YN-0000oa-Km for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 10:41:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x79YM-005cJ5-Qg for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 12:41:18 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabc3c8-bab6-0a2a0a5309dd-0a2a450c9234-18 for ; Thu, 17 Sep 2026 12:41:18 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabc3ce-f479-0a2a450c0019-4a7de18cce69-3 for ; Thu, 17 Sep 2026 12:41:18 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b91369d18so5079805e9.0 for ; Thu, 17 Sep 2026 03:41:18 -0700 (PDT) Received: from [10.72.3.60] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd204c1asm63603835e9.4.2026.09.17.03.41.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 03:41:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789641678; x=1790246478; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=jWOMj2zAtCvn0F8fSysaujKwbNl80fvQFMaO4DA7EXQ=; b=U8c6lnIO5ZdMQwsxypEaL1e/DovGmLGu1MDsKFq4zTP30qG0bUeMjRPwIoZfN/yU+z /gnnwM+kp8rk+xpk2p+TmKIA3wiJAi2Zqz10iU+3NLeRIKBS4W/5KvwBn5Bx2h/SxDBs X7ghJYpd/9jetH5ciTXbiVkWkkOIVeRvb77sYg+v4MaqV8BJqZlhRxwi1GCmqPpzbMzy fO/TrXJd6IEsd8RHg7sd5rwTQri+UeN+qr1T5cuNpxeU7Nd80kqReafvsNpOBitnR8kB iWJdcXQsOOX2Oq+Z1kv8eiYbVx/SLlc3F4QC/WPNCnevDHNFVSeYouMmy48lD/LcL0LH STlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789641678; x=1790246478; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=jWOMj2zAtCvn0F8fSysaujKwbNl80fvQFMaO4DA7EXQ=; b=xYkuUf1LgDSkivsj2wfUJbGRFYMs1mqI+CXwgFb+zv9ISR1DNBYFPQzKC2xWZSXBaH 2Vnk+3cKWG6oyE5pQ5Zl0EK3pN1BMISDG80J6JJffBmalUhd3/J9ymA9G6PStHannfDJ mAekaY73P5aa0+Ibnto5lEzOYF6gelu6kn6jYGI8RNAQlj4WHuft5PLhvrS7p6N62A/L 3MsszkU3jz+3F1tM12iqpX6c5XQkwhnDd6sdif0CQEbpvgdoN8z3YwlaBBEqU90KxkwI 3fQFYW1hfB5F0tj+PvQaXiorGrKRvipttN0HOpJ7mM+z7rj9AmTVQTfKvM3qGTtTQ2SU Q83Q== X-Forwarded-Encrypted: i=1; AKwUvBy6OIuisAIfyf7D/C/zNyiOeqGM5sE+q7QczeiWEvsyoffLBXEbsAHz+Q3mKMDnn2gwNzzLsSye6Gg=@lists.xenproject.org X-Gm-Message-State: AFuF++lLrsuKJYNk5FIPZJ+TKJIXuY/UNz3qlR/I6mE0JqOh3+nGQQj1 PVDz1d4VFXcWIbc/bJ8d82RtNUBOhYw2IAw5JsI5+ABoCM1skwBtuTST08V562tBfQ== X-Gm-Gg: AYBFou2fMO3+IrLlJIkKQPCF+qQanW1qvDDZKpsS3AeR6bpua1SWBoTl+vtRGIrorLa b9LlOZ/0hNc4Dqo5mC6b1CFb8Kon7vYhxIyIIJSnJoFUDRhvqQ7BbdQU0TS+lYJey9VbUNNNen8 yWoAXGkOvdt4kj1KtZy334gVCLe5G1J0s6l1vPH6PZZACg/S1IGxUBL+J2KsHrmmpSKuCIWBwoh J8rpn10j4Y8p+ZO7M6gHUOIZSXxhiCcFIIfnrUXm4ibHT+q5F+WcofTwbVKCf1gTsprQK8aKg7l 0ipHkk2pKXH89dtbdtFdaNEzfe4eby+VTW1+Jws7EAS8gU6QJa/7FFR5zDsNBJtnKXMvCs/7jp/ SqSCF7+poDq/6wFDTMrw3IMkksMRDkYCA63pSEhICCT2CLaODUe847tMy0ueKbh5lJn6p1FA4jz /MD8FqWm6bqQCfjkBU7lY+TzgOZRvbjWRNKuUfGeNPtZqD6F7aNa7Lv29lNAvQHnj/G5oiKzI8W w== X-Received: by 2002:a05:600c:3b1d:b0:49e:6e46:2db with SMTP id 5b1f17b1804b1-49eb72f2c33mr71996335e9.8.1789641678014; Thu, 17 Sep 2026 03:41:18 -0700 (PDT) Message-ID: <310125fd-5a40-4a39-b54c-ff917c73a43f@suse.com> Date: Thu, 17 Sep 2026 12:41:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> <52c8ca00-423a-4c91-a60d-a1662d20a012@suse.com> <0d13b587-0920-4958-9a17-425d1a23d51e@gmail.com> <16ffbf4e-0178-4089-b279-d39e97ab885f@suse.com> <99f7bb36-14c2-474f-83e9-b36ae62a1f1a@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <99f7bb36-14c2-474f-83e9-b36ae62a1f1a@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1789641678-51B35A5B-F0200433/0/0 X-purgate-type: clean X-purgate-size: 4209 On 17.09.2026 10:40, Oleksii Kurochko wrote: > On 9/17/26 7:20 AM, Jan Beulich wrote: >> On 17.09.2026 07:12, Oleksii Kurochko wrote: >>> On 9/16/26 3:02 PM, Jan Beulich wrote: >>>> On 16.09.2026 07:55, Oleksii Kurochko wrote: >>>>> On 9/14/26 2:12 PM, Jan Beulich wrote: >>>>>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>>>>> --- a/xen/arch/riscv/imsic.c >>>>>>> +++ b/xen/arch/riscv/imsic.c >>>>>>> @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, >>>>>>> >>>>>>> void imsic_migrate_vcpu(struct vcpu *v) >>>>>>> { >>>>>>> + /* >>>>>>> + * The scheduler can mark a freshly created vCPU's unit as migrated and >>>>>>> + * invoke this before the vCPU has ever run (see the migrated branch in >>>>>>> + * schedule()). No need to do migration for such vCPUs as they aren't fully >>>>>>> + * initialized (for example, context_switch() will be called after >>>>>>> + * imsic_migrate_vcpu()). >>>>>>> + */ >>>>>>> + if ( v->arch.last_cpu == NR_CPUS ) >>>>>> >>>>>> May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a >>>>>> good sentinel. If we/you decided to switch to ~0, >= here would continue to >>>>>> be correct. >>>>> >>>>> I agree with >= but I am not quite sure that I fully understand what is >>>>> wrong with NR_CPUS. We have for example the following: >>>>> >>>>> static inline unsigned int smp_processor_id(void) >>>>> { >>>>> unsigned int id = tp->processor_id; >>>>> >>>>> BUG_ON(id >= NR_CPUS); >>>>> >>>>> return id; >>>>> } >>>>> >>>>> So it is guaranteed that NR_CPUS what be used as cpu id and so it still >>>>> could be considered as a good sentinel. >>>> >>>> Arbitrary numbers can be problematic when used as a sentinel. If you look >>>> at disassembly, you may not recognize that number as a sentinel. Further >>>> there's also a code-gen concern: ~0, aiui, will always generate the same >>>> code (to e.g. load into a register). NR_CPUS, depending on .config, may >>>> not. The value may not be loadable by a single insn. >>> >>> Witch such explanation it started to be more sense in it. >>> >>> I will introduce then >>> >>> /* Value of arch_vcpu.last_cpu for a vCPU which hasn't run yet. */ >>> #define VCPU_NEVER_RAN (~0U) >>> >>> and use it to work with v->arch.last_cpu. >>> >>> Just to be sure that I understand correctly your suggestion with ~0U is >>> only for the case of ->last_cpu and check if vcpu was ran or not. >>> >>> For >>> >>> struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { >>> .processor_id = NR_CPUS, >>> }}; >>> >>> and >>> >>> struct vimsic_state { >>> ... >>> /* >>> * s/w IMSIC VS-file -> vsfile_cpu == NR_CPUS >>> * h/w IMSIC VS-file -> vsfile_cpu < NR_CPUS >>> */ >>> unsigned int vsfile_cpu; >>> }; >>> >>> I can continue to use NR_CPUS, right? >> >> You _can_ everywhere. It may merely be beneficial to use ~0 instead, at >> least in some cases. The "how to load value into a register" aspect of >> course doesn't affect static initializers. The "easy to recognize" one, >> otoh, may apply there as well. You get to judge... >> > I checked how NR_CPUS is used and it is okay to change to ~0U for > vsfile_cpu mentioned above as it could really affect how to load value > into a register but I am not sure about .processor_id as it is just > static initializer (maybe just for consistency). > > Also as hartid_to_cpuid() returning NR_CPUS to follow the common > convention of returning an out-of-range CPU number when nothing was > found (like cpumask_first() / cpumask_next() do), so callers check the > result with >= rather than against a specific sentinel. > > If to use ~0U for vsfile_cpu then suggested name VCPU_NEVER_RAN isn't > good. Then probably CPU_NONE will be better. > > If we will start to use ~0 instead of NR_CPUS then IIUC it won't be any > sense to use ">=" suggested above and "==" could be continue to be used, > right? I fear you may not like the answer: Depends. IOW I can't give a concrete reply unless seeing the concrete use(s). Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 17 10:51:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 10:51:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423889.1648747 (Exim 4.92) (envelope-from ) id 1x79i7-0002UZ-Vr; Thu, 17 Sep 2026 10:51:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423889.1648747; Thu, 17 Sep 2026 10:51:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x79i7-0002US-Ry; Thu, 17 Sep 2026 10:51:23 +0000 Received: by outflank-mailman (input) for mailman id 1423889; Thu, 17 Sep 2026 10:51:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x79i6-0002UM-Rr for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 10:51:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x79i0-002ame-MA for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 12:51:16 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabc620-8faa-0a2a0a5109dd-0a2a4505b4fe-26 for ; Thu, 17 Sep 2026 12:51:16 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabc624-4cb1-0a2a45050019-4a7de18cbf13-3 for ; Thu, 17 Sep 2026 12:51:16 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd38e0f79so4038145e9.3 for ; Thu, 17 Sep 2026 03:51:16 -0700 (PDT) Received: from [10.72.3.60] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd2563ccsm80801395e9.13.2026.09.17.03.51.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 03:51:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789642276; x=1790247076; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Fz342ZapvVW137Glp/+LrmoTo3LQuz+HEHydJlsSWMI=; b=TpjLUkNAKGNtk0lqYUoSnMZ8uNhpAIWzZZ9IaLv1dWuKl1zI4FBHhSbbufConpSmlX JPHUEqOCJB3rPaCthOtUkdacM+cvTK8XXRMUqrcbgYoZsvsS9NN4TtbNc+mW6JH2JLWU gqtqEUQaL3RObh1OGtowoZPdCX17E59T7Ng4vFxgL/gMt5cia6Si3fYA9rvP2tzydopi ZfBVGNNP+eTYLuj2TLzyuly3ygi3Yab8YjCOoCotM74nh7Kou7S/iEaw8ykgYChoZR9P X126Z95j02nC7TyV1bJ/GtGa6w3fQJaXIxMBx9O9FWqmo7cRTNObo+zWRa8htsz4QAOl nOVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789642276; x=1790247076; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=Fz342ZapvVW137Glp/+LrmoTo3LQuz+HEHydJlsSWMI=; b=izE/d8yAQrk5fO0CYAHE7YYgj6FyDf4KlYUi8llCoTPTXV4e8SYjBhaclFgKPNaKKo UViQ99+6q4sD97wfGNC2uLQ5QDZ3G9YWOx/+AjDmM4cRpKy/+j88LiJJOq6bIAS9PjZC KFEjZVdI96hRv6KEKTkTf8pgnk6EQu/QsIQKiZ16p0+2gJb+P0YBaTGJv7rdEGsGgQN5 XrRDJX4pNmB0aSHsbTvE7UwZH727kOcuWSdnbF6suCaodOTp9rKGvPSpDVIwHTtkA5j7 XiWJlu4lOq8nREbXAUZdm/V62x26qhnn/8Q7BTBKoq1YqhKgxB81luRMn2a+6p+YFd75 RA3g== X-Forwarded-Encrypted: i=1; AKwUvBx8s8HmhCs5amhuk6P1Q3RZxoMpRfS8SkZi8uynqciaKsOFpzHUdW9lwgjftFe8IbUUnYCc3nL9FbY=@lists.xenproject.org X-Gm-Message-State: AFuF++n4tXUemRNvaMRUCstYA3+molC9r7PuYvnc4O3n96fBwOo/+dM4 J26h4NdYukF6cEIUrVaNZRSMU+GC2AqwwH23T0v6va4B5eWfw4BSbhTYzPoafwXTxQ== X-Gm-Gg: AYBFou0A6JjP/XENGnuUv0eYZWDvnWHso3rDQsrWl5qsXN+/i7U3L36Rs3UZJNQZ/Mz kxJK0yGVftuFBoU23hu2qFr101YDaNznldbuiiKwiF57bKS+P2VQU6vvVInYEtMa0RQMbDA1J3g 7ISkR1riIKmQy7yjKqw0g1+g+SpAQbXYffTFdqzMIlKcjuVE7dLsgh0JkFfA5NaJzxL1OIjqkxj P5BLvqY6C90AoCQAJ1pPE39LK3FtFJz5cMblafR45P+VVkufQKoa33e5MEpGvKxkVAVmEUjL+9e q9VpphK7RbbCaExPM3FSq1rZSnB+TOv6guVR8KetSduml1EXbYhhbYPQoYgqacaQgzgqext54Yu Rj3xVCrMLMYtrBBVup0eFOgWs2C8tQdDrhFpJgoKhwNA8rbb/SfH5ccSnDyWf6q9EClLU9bNuYO OpH6FpU7RkLjqXySF5/nemkRZ7zjGldZBiLusY8vbvG//eUVqoVuTNdTO0aH7V7SqbZKIXUCLc+ w== X-Received: by 2002:a05:600c:474a:b0:49c:ee20:e787 with SMTP id 5b1f17b1804b1-49eac464371mr115512335e9.1.1789642276122; Thu, 17 Sep 2026 03:51:16 -0700 (PDT) Message-ID: <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@suse.com> Date: Thu, 17 Sep 2026 12:51:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] stubdom: remove build of zlib To: Juergen Gross Cc: Anthony PERARD , Samuel Thibault , xen-devel@lists.xenproject.org References: <20260917075351.37208-1-jgross@suse.com> <20260917075351.37208-3-jgross@suse.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <20260917075351.37208-3-jgross@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789642276-F66B52A1-6F56D40F/0/0 X-purgate-type: clean X-purgate-size: 314 On 17.09.2026 09:53, Juergen Gross wrote: > The last users of zlib for stubdoms have been removed. Looking at patch 1, I can't really conclude whether that's where the last user disappeared (no occurrence of "zlib" in that patch), or whether this patch really could go in right away. Please clarify. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 17 11:06:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 11:06:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423902.1648755 (Exim 4.92) (envelope-from ) id 1x79wp-0004Hn-49; Thu, 17 Sep 2026 11:06:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423902.1648755; Thu, 17 Sep 2026 11:06:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x79wp-0004Hg-1U; Thu, 17 Sep 2026 11:06:35 +0000 Received: by outflank-mailman (input) for mailman id 1423902; Thu, 17 Sep 2026 11:06:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x79wn-0004HK-MH for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 11:06:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x79wm-007oHS-P1 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 13:06:32 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabc9af-e002-0a2a0a5209dd-0a2a4501c648-30 for ; Thu, 17 Sep 2026 13:06:32 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabc9b8-5984-0a2a45010019-4a7de18cf755-3 for ; Thu, 17 Sep 2026 13:06:32 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912df756so5062195e9.3 for ; Thu, 17 Sep 2026 04:06:32 -0700 (PDT) Received: from [10.59.21.104] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd23ac75sm66756155e9.13.2026.09.17.04.06.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 04:06:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789643192; x=1790247992; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=Gl4yOBZHVn1WWC0kXfJAc1rkrfWw9MhhXbVMZn3eV/Y=; b=icNAhJ7HN50ip5yeOCo9/4xLeYjfyPyV4qJCyEbKDjv1frPaXvFT5rnHLiruabOdXH ciEagT/exVt4P2EWZTK7jmBdF5SmVQjmrHWSthQ/KKru9EbMSqi2/+qz33MrH4CzE1Fv nHHLe1w3hlJ/0OPo/HKK1FwdudaRfzmCIxlnA97Z6LLt3HRsDXri87Pg54/6TJhijsUB TQXyngxX87FCF5IQrilRN9GsLcD7ijVH9z7+Bng8bocrq4Me74lrB8pUIQb/0Vwe3jC8 luSeBL/CM5jPABgcjNBr4FGSqKbzKqwHRuCrgVk9xS0y0HyL1KL7bbA2qOctU+ymQzA5 STRQ== X-Forwarded-Encrypted: i=1; AKwUvBxVD8NbaAVKJB8nWdzjv/0+3b457+68ezK8vA9/mKthFAEfWSCAqGBz1u43yPPZLV0hmr1rvFU/PHA=@lists.xenproject.org X-Gm-Message-State: AFuF++myOF9je45fbWoaw8+WwPcutFIuJUTPYIiWop0ikwSnY0gO/Y2k w3kx0kJOKxv54cFz6v6o/OUG+Bwttk+H0VUohKCQ0iTDyJC6PMd7KYQU X-Gm-Gg: AYBFou2k+9wKgiLPKNODwfr82XHpH/+leNP2ZMrtpzHxe07oH4NfTONjcO4ACJpOrqO Tqxqsso3gueowSmRg34VLyWTcA5ZT+eU1gyw2EstlmU6sBwZL7RiuqZcQU5idFO8D5EX74pPOLq PHtoDl43hvS2yxJNUFyu5WY1himSbwp13ggPWxYan+t06Rv6sCnDr2zwGl2SRxfTGqvF2zuiha6 ylmr1Y8Vp2st4pt0Okp3PNQ5Sa8/hdCMcHRWp2LiLdU2w7kQ5wlTvz4HU3dMkT0JFjrrbjKb15P UxjnKTXuNDcC8ZhVDxagYG3bkRLDxdG5R7elQiqTzx69FDUPtxL/ixPb3o/urBgNV9NvALlZ8BT xFYeBeFIFVLGfZJffwp4XocAshTVkvGNREONozE32US7nz/x/ZjGRNVcoAYgmBYqrlYfEtTu/Un EBmC9UhgdgCSs5qtU7RfQtsdORgmx9CoQUphIj0VK2fqSDQsdAjV3bNKXjo1fM7n6gBNNEB2dBQ ZSEc8i4TKRZ8Q== X-Received: by 2002:a05:600d:8498:10b0:49e:6ac4:b76e with SMTP id 5b1f17b1804b1-49ec0543cf1mr54913475e9.30.1789643192103; Thu, 17 Sep 2026 04:06:32 -0700 (PDT) Message-ID: Date: Thu, 17 Sep 2026 13:06:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/1] static-memory: allow skipping the cache flush To: Jan Setje-Eilers , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20260829050611.3353566-1-Jan.SetjeEilers@oracle.com> Content-Language: en-GB From: "Grall, Julien" In-Reply-To: <20260829050611.3353566-1-Jan.SetjeEilers@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1789643192-1F46D757-46E54996/0/0 X-purgate-type: clean X-purgate-size: 2930 Hi Jan, Sorry for the late answer. The topic is a bit tricky. On 29/08/2026 07:06, Jan Setje-Eilers wrote: > Hi all, > > I would like feedback on whether Xen needs to flush every page in a > dom0less xen,static-mem bank before assigning it to a guest. > > Static-memory support is currently enabled only on Arm, where I am using > and testing this change. Its implementation and acquisition path are in > common code, so this RFC is about the generic static-memory path. > > The current code cleans and invalidates every page in the bank. This is a > safe default, but walking a large bank can add several seconds to boot even > though Xen only writes the pages used for the guest kernel, initrd, and > device tree. > > Here, cleaning refers to cache maintenance, not boot scrubbing. With > bootscrub=1 or the default bootscrub=idle, Xen assigns dom0less static > banks before boot scrubbing starts. The pages are no longer free, so boot > scrubbing does not clear them. > > My starting point is that if a platform permits the untouched pages to be > cleared before guest start, the guest cannot depend on their initial > contents. This is a platform policy assumption, not something Xen's boot > scrubbing establishes. Xen already cleans each page it writes during > domain construction. > > Would it therefore be reasonable to let a platform skip the full-bank > flush, provided it can also guarantee that the untouched pages are absent > from all caches and that firmware, DMA, EL3 services, and other CPUs do not > write them before guest start? IIUC, the cache flush was mainly added to prevent memory leaking between two guests if they are the MMU off (see XSA-364). I think what you wrote makes sense, but I would prefer Arm to confirm this is fine. For Xen ... > I am using no-staticmem-cache-flush with bootscrub=0 on a 64-bit Arm > system with two dom0less guests. Both guests boot normally. Skipping the > flush reduced Xen startup from about five seconds to about one second. ... I think the slow down you describe could also happen when a dynamic VM is created (e.g. via xl). A few years ago, Arm introduced FEAT_FWB to rework how stage-2 + stage-1 memory attributes works. Currently in Xen, we are using the "old" approach where the used attributes is the strongest of the two. For instance, the guest has the MMU off, then the access will bypass the cache. With FEAT_FWB, you can force the memory attributes to be cacheable even when the MMU is off. I believe FEAT_FWB should solve the problem you have (assume your HW supports it). In term of effort, it is mostly updating the stage-2 memory attributes and then getting rid of some cache operations (include set/way emulation) when the feature is enabled. BTW, how much memory do you give to the domain? 4 seconds difference seems quite a lot. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Sep 17 11:56:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 11:56:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423939.1648763 (Exim 4.92) (envelope-from ) id 1x7Aid-00024U-LL; Thu, 17 Sep 2026 11:55:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423939.1648763; Thu, 17 Sep 2026 11:55:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Aid-00024N-Ii; Thu, 17 Sep 2026 11:55:59 +0000 Received: by outflank-mailman (input) for mailman id 1423939; Thu, 17 Sep 2026 11:55:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Aic-00024H-Jk for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 11:55:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Aic-00DUz9-0P for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 13:55:58 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabd53d-8faa-0a2a0a5109dd-0a2a45028cfe-40 for ; Thu, 17 Sep 2026 13:55:57 +0200 Received: from [52.101.52.56] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabd54c-6ca4-0a2a45020019-346534382c88-3 for ; Thu, 17 Sep 2026 13:55:57 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS6PR03MB989139.namprd03.prod.outlook.com (2603:10b6:8:368::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.12; Thu, 17 Sep 2026 11:55:55 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0406.007; Thu, 17 Sep 2026 11:55:55 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PBe51dcRF9kWhewhlcHkTXYRddk50e4Ndz5bcadyvFsozzYhckNXfE/Rb7DpCABRfOIn+H3M1dAvQ73ee1Q1eDhpT0OIejTDeYxabPdG1SJ+tofKu78dzrzDWuKeahw6vxrP6yB0KbDyigHsrrRhUGAFRKr8YMZH2HalwkAwog72PR8ahuHuETVyAtctA3BVyuAyrHt+PdgE7gAS/BFwk9vsa+902p64XNtEeipNmRqemrH7LzNbC+41ADqWNRg6eWXweCwjCwzXochWf2GdY3el7iMhnO5CisxssOaHG6U6yOqCJ5nuBBodaAV1LlNoIBHkjsALD7GE0iw/CKQxCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AzBtTiyCxoz5Ohfl1wwUqMxTVfiFfDbVMtiyRXcdruY=; b=uUSNTOxlXiNnqrGoWavZ66ehtllF6zxUBrSlhPr5dE17uzAgstP+RCTKq43yGe3ovABRYbTijtZYqBz9JkzLrw8hCOhpx/UeLSg6YtU4VINFOw0xTxg3B2HJyn+SMcAWFxzNnmjfpur/eH/SDixKIhnIsIyhqRqGBpFzrtr1xFK2/zjWH+mUN95bdPb+8UIIPeVBot1S9C5fUCd8b2tPiGxI1S89Hx3G70hK9FwGazb5TrxFq21NSvY8hHUNzY0y9ElUvZF1hjKybgaV/u41vz12ttH7cqMPwy/e59s6gP9/pvJAsv0SDW2/q9+mXXDgbGj9886tSArslnz5MglM4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AzBtTiyCxoz5Ohfl1wwUqMxTVfiFfDbVMtiyRXcdruY=; b=PgElSMt7ugp1xncPdTdLNx3SIzSSAqve7P7Urw54cE7rMHE/foFhYzcBNL5omFEwbGQY3G/N83jJYVuwRN4oIh2xxhCxy3O7+aK0/dbHQMmTofCOfUSQotorCfCC66qSzMrtWvHZHxGefdMKibwKGTjt0JtpLIgYgFvYe4KUvJg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <591230f5-f68a-4a18-ac01-05aaecb0950a@citrix.com> Date: Thu, 17 Sep 2026 13:55:51 +0200 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD Subject: Re: [PATCH v2 1/4] tools/libxenguest: remove Mini-OS specific parts To: Juergen Gross , xen-devel@lists.xenproject.org References: <20260917075351.37208-1-jgross@suse.com> <20260917075351.37208-2-jgross@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260917075351.37208-2-jgross@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR4P281CA0422.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:d1::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS6PR03MB989139:EE_ X-MS-Office365-Filtering-Correlation-Id: 3628addc-2f35-4268-1497-08df14b2a124 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|11063799006|56012099006|6133799003|4143699003|18002099003|22082099003|10067099003; X-Microsoft-Antispam-Message-Info: TRrDUJ6QDB7kq2nd32lxapzf+hZTVwUKSoO7QcUE6jC1telrB8wfQlIaAo665Bm8Do6YiCfJD1QfWIiteT1Q7J63SoqxJL1aNQXv55duRMSepHpp6A3RD7P9pHaoZ/Rrgj0260uwTl8pnMftwRjc0ay62Rbt1cOA/gaylGqvnAEa7tGsYch1AoDze2lWtpT2uGVdrwTGzoS01oE9mMRjslMEBwr8ODUDYcFqRwjtOfhIz6eHIgb9kvZTO4MrjMyjlMhhgB5CSj8cd61qP8dE5psBHQWq7sMdTm6+2dChh2Fv/uCbVhBiL8nXNApbZ0sIwRscho90+8dvyYb3nAzORibt683Xzw+r+E/LMsFE6/gAI1rBUfiAvA2IslCi3v92OplMEDvZ82jX3CKCXKjIuZEAVfUgRK5TSPY7goMIac7VA5aXM63At+bkPLRr/p4X0WYTN1wHARvTr1z+bP8LtQW2zzqe8Q6hKblHJIIn0/FAgB6PeGXNnFUI8UoHAPxIMmSmBfvsmCAbxvgx+LdvbRC2jH5GDKzzJqCXBV8cTKCRGMkefJLT+juB2TqxlUj/pFpnXlqyVs3hQLWJEwaXLYg1Ve50B+pshnyfFabPmMVeHs7nsKc7xfM5i10sP7J1IowSR+aCOdtE1Z33yZxJiXPeyloZMCheWbpgIttH6z4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(11063799006)(56012099006)(6133799003)(4143699003)(18002099003)(22082099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UmlMdXNRbkE4eEwzcE9oeFFlNm5QYk9ORmYwOWgxMWNMd1NCbWFOOXpReW1m?= =?utf-8?B?ZytLUzQvNmQvWTNPWUhjYWhKeHVXZlhRVFlYNHkvalpRT3FKZW1lWkJhU2x6?= =?utf-8?B?Q1ZDcm9qWEJKR1pZMjVQT2xHd2EwMHFqeG80Y0s4cm84eTZqUVR4SDdKN01j?= =?utf-8?B?WjBYVlpNNmcxRTdzUkZIa0F0MDgvWElLcVh3N0J3OGc2YVk1WWN0UWtoNG5o?= =?utf-8?B?cGVPN2U0MkZhYVFxcjFLTnNMdU10TmhzL0lDekpiOVNvdXpRM0NLL1plVlor?= =?utf-8?B?ckJSbmJ3MlBSbVpMcGswc3BjSUt0UjNXa1NYaThJbFp1ejJ5cE9mSU95dVJX?= =?utf-8?B?dS9wTkdHVUtkQUErTmN3WG91YUpxVDdOc0pFQ3lTbFZlV2VyZ0tta2o2Q3Zr?= =?utf-8?B?MW5tWXJ1aGN3UUNhdnZwZG5IT3RES0JHblhrU1U5eGtLTXZIVVE5QjJOSGRZ?= =?utf-8?B?bnNMc0F2UnU0OHE3WHlab3l0RTR5NStiODBESUs2NUhzdk1wTUxlTVVrVUNn?= =?utf-8?B?WkRFb0xEZ3VtWVM0QTRzWjdYUm1WOGkza20wUEJEWUlqUVdVRWRHTUlLQ1hq?= =?utf-8?B?K1hlRSs0NisyclVydHJtVjRJdkdzWldxbDd0SjNRNG1VczNXZmRsWnMraVVx?= =?utf-8?B?N3JMc0RjbWpnNXk0M2IweHJPT2twOXJlbjV1VFNIclp0UTZTNDVVUFc4cHg2?= =?utf-8?B?NUNmZHdrN0swK0NGcmk5K1ZGNTdONnF4V1RKY25raUIwNjhoNHkvUW5YZnV2?= =?utf-8?B?U2hMYWpETGFMY3NjS0RkMmpUZi9oVFBHcHByQzl3YzV4bE9ZWUZFWHRoVy9Y?= =?utf-8?B?WlR2KzdOTWpmQlN0bUtEQVl4YUNYTEswZXhFSHBuVDE1OE8zSHRyTjZUQ2R5?= =?utf-8?B?ZjJ1Y2h2VjRhajgxeXN3SkM3c0xzbFR6WUM2bTFJT29xbE1XVzVSb25MNThR?= =?utf-8?B?bkFqdEF4SUxHK1ppZTh1NjNMQ1NSOE9YRlZ3c0tRQmxsa01HYnlGblF2Wldv?= =?utf-8?B?ZkFHa3lvQnA4L05tSjJzZ0xlSEQyNVdUaDN2bkovWUdoVzdDdUFWb2hQS3Fk?= =?utf-8?B?YjEvTm4wbmRnSWhBODVBWXBlUWY0TENkTFpiUG1ZWURwOFhYeUJ5MFNtT3ZF?= =?utf-8?B?TndUd0hoclRZQmIvNDZJNW13am0wTWN0QlZ1QlNqM2Flb1RMckEwbjhTdEkz?= =?utf-8?B?NTBtd2dnRTl4RDlvYjVuRU1jdE00bGc5WDZhOWNnZUxlU2k5ZCtoZkpKQVpS?= =?utf-8?B?SWNhWTlhR1NyZkJnaWpINjVJb0djR1psVWJJQTFmemRaYW83RkZWKzE0cUVx?= =?utf-8?B?dWRIVTNtQWE5UEJvY1FrdUJvTDZ5dzJ4a0VubHlwbXhOb1Nsd3NuV1FKMnQr?= =?utf-8?B?UnR3dFQ3MzRBOFBzMTRYMGphMVFqRUF4ZEt3RTMrOGtYdE9ydExqd0JCM01x?= =?utf-8?B?VFlHTFdkc1pIOFpiNkkvSk4xZCtTL0g2aGE0L2hlQktDaGJidFlnZHlkYTJa?= =?utf-8?B?M1FMdU9EbGgxdDNCMnJ0RlB4VGE2UG1xUnNmQ210K2wrcHlJL3p2S2E3ejh4?= =?utf-8?B?cEJFeUtXbmhmUjZUemdmaW1WSEVNQndiS1VubUZyb1luZlNPaWlrUE8ybVNp?= =?utf-8?B?aTd1MVptZVB1dVlNc0JrQnVuK2tjQmNFR1BMbFNFRzd3ZkQvYnFlVlRTQjhV?= =?utf-8?B?K0RBa3ZIZEY2WE1HbEpSVWZucWFXeUZVNGloZUFuL3h1a3F5TzNhZ1dOSzA3?= =?utf-8?B?ckZMR0dOTEhRQ0VvcHB4YjkzWFhwbWlhc2RDZ0lXZUlCYUEzcTI2QVFMYk9F?= =?utf-8?B?SWhYd3A5dlg3Wi92RmEzOHZidDUxclRxODJUTnczMXlkRHV0bVRtZXppZ2RB?= =?utf-8?B?akRTTVpQMWFUamZ2Wjd1Qm5BZnhPMU1wbVVJQkdsRDdDYy8rbFNaTFUrWnNR?= =?utf-8?B?ZWRZQTU1TnR0enJMenkzNllSRTN1a1lNcGFCamxJY205SzFoRkcxRUF1dzJI?= =?utf-8?B?MzdNSVNhOCt0NVM2UWZnYkVHU1RsUmJFMWVPZTN4blJGU2NDSm5LTXNTb1JH?= =?utf-8?B?R3FzZ2V5WW1KMi9vNnBPdjVKaVRpUnF3WE9GbmdUc0dVTWlrcmh1dEtHR0Y1?= =?utf-8?B?dnMxdi9BOWlKWHh5dW1zbTN3cFdVNWlHS2VtNEh6NFFZeTdjMzFRVWt6Mld6?= =?utf-8?B?WEdCQ1FacWZGOXkvZ09uVFM5WjJLK1BJTzFLOGJxc0g0dWpJWTdxOTUwcmFO?= =?utf-8?B?MXRSdDlUOXl2QjRFN2NxWTdPczByU1ZRVU9HWWVSYUlCKytIU285QWUwaTVE?= =?utf-8?B?ektqV0hHV3hneWhpL20xVmk4UXRUTGdNRWpGOEpYQnprWDltMVFEUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3628addc-2f35-4268-1497-08df14b2a124 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2026 11:55:55.0798 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FcolArjB9bEqK51gDkKBxC4sNujG5YtBl14wO9q692Q11ugaqryruIXA7uNf3E8/2EJuCxdTacBblw1IuljA3LXokibCeLD8UaArwwfxJrA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS6PR03MB989139 X-purgate-ID: tlsNG-720697/1789646157-30DC12AC-3EC05AF8/0/0 X-purgate-type: clean X-purgate-size: 1516 On 17/09/2026 9:53 am, Juergen Gross wrote: > The last Mini-OS use case of libxenguest is gone, so remove the > Mini-OS specific parts of libxenguest. > > Signed-off-by: Juergen Gross > --- > tools/libs/guest/Makefile.common | 15 ------ > tools/libs/guest/xg_dom_decompress_unsafe.c | 48 ------------------- > tools/libs/guest/xg_dom_decompress_unsafe.h | 28 ----------- > .../guest/xg_dom_decompress_unsafe_bzip2.c | 14 ------ > .../libs/guest/xg_dom_decompress_unsafe_lz4.c | 39 --------------- > .../guest/xg_dom_decompress_unsafe_lzma.c | 14 ------ > .../guest/xg_dom_decompress_unsafe_lzo1x.c | 44 ----------------- > .../libs/guest/xg_dom_decompress_unsafe_xz.c | 46 ------------------ > .../guest/xg_dom_decompress_unsafe_zstd.c | 44 ----------------- > 9 files changed, 292 deletions(-) > delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.c > delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.h > delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c > delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c > delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzma.c > delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c > delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_xz.c > delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_zstd.c Good riddance.   Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Thu Sep 17 12:14:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 12:14:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423977.1648773 (Exim 4.92) (envelope-from ) id 1x7B0G-0005DJ-4Z; Thu, 17 Sep 2026 12:14:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423977.1648773; Thu, 17 Sep 2026 12:14:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7B0G-0005DC-1p; Thu, 17 Sep 2026 12:14:12 +0000 Received: by outflank-mailman (input) for mailman id 1423977; Thu, 17 Sep 2026 12:14:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7B0E-0005D6-B7 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 12:14:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7B0D-00BAe3-OF for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 14:14:09 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabd98e-e002-0a2a0a5209dd-0a2a4505e26a-12 for ; Thu, 17 Sep 2026 14:14:09 +0200 Received: from [52.101.85.69] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabd98f-4cb1-0a2a45050019-346555452cbb-3 for ; Thu, 17 Sep 2026 14:14:09 +0200 Received: from MW4P222CA0012.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::17) by BL1PR12MB5731.namprd12.prod.outlook.com (2603:10b6:208:386::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.9; Thu, 17 Sep 2026 12:14:01 +0000 Received: from SJ1PEPF000037A1.namprd04.prod.outlook.com (2603:10b6:303:114:cafe::9a) by MW4P222CA0012.outlook.office365.com (2603:10b6:303:114::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Thu, 17 Sep 2026 12:13:59 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000037A1.mail.protection.outlook.com (10.167.244.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Thu, 17 Sep 2026 12:13:58 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Thu, 17 Sep 2026 07:13:57 -0500 Received: from [172.31.52.207] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Thu, 17 Sep 2026 07:13:55 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SKBmbSLzRAt1lq/B6y9mAbm6WYOumh/YSFOk+ks8yEgg8y5BygBPcgGW+mzmVwfGH0L8zl7RJJil4VjH6idr7Dnpy7Q3Xz4OYB5dqx/GPT3/oTAG9/jiA8DKWDM/STL4VztmrGfvrLctk01+QgiAkTFbVqUWxfepEy1DluccLBwUTheVlBdwKZ61ce5bAn2O9ySiW9MPmTBUPv+kseFTFX2dFMWZF9tT+LQtm3uTTd7Ectz9BeEFLAVl24j+1HNQpZc+tNkxdbfa3IC7/ln1AUib0ayJZQeS4+hIiYk3NQBwhIwvJRmZ8DkQAFO+WhTArW64kUjb3GDq4n6hGa9nYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ykwnd8AuGRDEEAns2qhqEaiPT3affmZmerE5r61BzM8=; b=r35rXy6/I4ceUOHZs7mH+f0Or3ZkiACfCe/YTpj6d0Kw9alMApzK7eGYoxKjfu6TlY2XdlGetMORPn63l2zSeCSjLi77p4DppNYaAfY2R3Rka+9Wct385f6P4sNU6Z5IBpqMWL4luEy+C8eHh8jOCRxnN9b0jX6RoicWxiw1MQ9pz5bpOrH3nHWHHMCXrQCKz318EOgdMbhfjf1zQv80bGeC6GdZEUnkrRr7h86CNE92OGR5qtQ7zE7XG9i5Bis+8qm7fX/hIFdrpYuxYDa5OvW+Lm8eV4FAtg8fWYbdaNAlDuGbm/KTrZsfZ99t6q1eLxdiNCMc8oUhIT4HpLB4yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ykwnd8AuGRDEEAns2qhqEaiPT3affmZmerE5r61BzM8=; b=AHtlSYB9/Uh0ZhwgSCoJztKI+YekS8I4hx2dSRYQnkuXKwfsRlduQytJ2fIZxkmLReE6gdOrbjYI5Tt8wnm/UR67xb4/rlLVV5XKmU74vWroATlWyVxeGcnv/2MdXLYVKY1DvA5eIDfQAkBzQZ63f3chnvnlwHVxAoZcR8JwQ9E= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Thu, 17 Sep 2026 13:13:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 for 4.23] Add GIC SGI boot/self tests in Xen To: "Grall, Julien" , Ayan Kumar Halder , CC: Stefano Stabellini , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , Roger Pau Monne , "Doug Goldstein" References: <20260916113520.3870182-1-ayan.kumar.halder@amd.com> <7b6d9027-9848-4909-a5a3-16ddf56dde72@xen.org> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <7b6d9027-9848-4909-a5a3-16ddf56dde72@xen.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000037A1:EE_|BL1PR12MB5731:EE_ X-MS-Office365-Filtering-Correlation-Id: dc8f70a3-282f-47dd-2f45-08df14b52705 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|7416014|1800799024|82310400026|36860700016|22082099003|18002099003|4143699003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: hBApP9LFR+p/1xjjmnBwsUrcLxraBZlgZaHQ40VdC2G6t+eu3azn8T0zfWB1Cqf1W0KyUYnlTXRBYhZaDpkXjlIOHARpjJw8xtWbIF3wLd0nWVgtK/HrK6483mFk+qf61587Gk9o93kEX/sfeZkPkzjcOD3k6CztQCQU45kWWPhh8echu3Vz4JQcy5hiRNJqmAg7eX2AJWpg763jML12hQc/8BYC1rL5Qyo8pxKAyGxiHeLds9agmEovglq7yvkIQ2SS4uN95gquAeoxW2YcOC1P3EcX7ZxIWZM8V8GjMj5D6nVImtySkE9XvNHE5ml0PsQaq/qcjMSJ5eAt45KqSUJLVsSZWkCSioLHK08OMnZaYQ00+kAhvHoZQM8OtOI48BgFVdd0vxIzGyNxKJIQB6q3GystbzdyChAkcoPtvL8SdCg/b9c9SxwZY+IjN7XHrjNzMOdar1Q3rDq9GIqUciYO7OKlaXcxQtwDbNF3CeGTH16kEmWKVtsH7jZVU67nV2nNq1u7ltH90J6NsbyifOy1c6NhAa7Hkg+KbAbykWqO4p8az8iNDdEv9TNrdDwd1NnNNIsOapybDn7Z6Roryv0DOFWe+8fmRtd9Yki23ybxzQx9A7RkBAILrsx95XRG1dhBqidWgoEU/CTU0qSTUafWwoZ8uWHj6T5Is9V2N3smZCVcPvdRMEIQKpHsHKCXbs1uec2fCQg4Xc5k8+nLUQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(376014)(7416014)(1800799024)(82310400026)(36860700016)(22082099003)(18002099003)(4143699003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: WCedLCB81mfPnUqFWfPfnkxM7sZ2g2MBcxr7P6jOGXZZEb+rGSJzVJocZSdQvg+tqACZWJDGEAX/rghR5sftBXQAlmFJ9WLkj96DUeyBRKlpS457CWUK2YAyhRcHoi/MY7w2sw6OySr+8H7h74wE/VlfFJDYomiXoHkM/1A8QgPTBs68DedHs2FsHi9nO2IF9JF35aqYk4hoxXPIceo3XIYfWhv/Pp91+G1kF/EZDx+zyf4N+fDoBI/KCIwj9EaMRCURadTbaxUZ5/ArOu0XE6e2NIP+zK1v9LMmAtZYshCxVdVRIxEuxCwXEUgg7LwgjQlla76u/ast4xGV4uTsScv8OVzlhqOmS3s8mnPeSf81lEdji5qZ1SD6OvGmPFkMwdUDxcoZaSxH1502s/ETgkenxm2KFxK2csA/OR4DSWXv6oP8n4OehvIX/SDPIss0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2026 12:13:58.4927 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dc8f70a3-282f-47dd-2f45-08df14b52705 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000037A1.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5731 X-purgate-ID: tlsNG-c201ff/1789647249-72AB72A1-42C6D0CD/0/0 X-purgate-type: clean X-purgate-size: 1793 On 17/09/2026 08:57, Grall, Julien wrote: > Hi Ayan, Hi Julien, > > On 16/09/2026 12:35, Ayan Kumar Halder wrote: >> +static void __init expect_sgi(const cpumask_t *mask, >> +                              const unsigned int *before, const char >> *what) >> +{ >> +    s_time_t deadline = NOW() + MILLISECS(100); >> +    unsigned int cpu; >> + >> +    for_each_cpu ( cpu, mask ) >> +    { >> +        while ( sgi_count(cpu) == before[cpu] ) >> +        { >> +            if ( NOW() > deadline ) >> +                panic("GIC selftest: %s: CPU%u did not receive >> GIC_SGI_TEST\n", >> +                      what, cpu); >> +            cpu_relax(); >> +        } >> +    } >> + >> +    printk("GIC selftest: CPU%u: %s: OK\n", smp_processor_id(), what); >> +} >> + >> +/* >> + * "All but self" is only meaningful once every CPU can take an SGI, >> so it is >> + * run by whichever CPU observes that it is the last one to get here. >> + */ >> +static int __init gic_sgi_selftest(void) >> +{ >> +    static atomic_t __initdata seen = ATOMIC_INIT(0); >> +    unsigned int before[NR_CPUS] = { }; > > Sorry I didn't spot this earlier. NR_CPUS can be quite large (up to > 16K). So this will blow up the stack. As this is a test, we have hardcoded NR_CPUS = 4 in automation/scripts/qemu-boot-selftest-arm64.sh. If there are 16K CPUs, our test only checks for 4 cpus only. However if there is still a concern .... > > There are two options: >   1) Use static >   2) Temporarily allocate "before" > > I don't have a strong opinion on which way to go with. I can use static. - Ayan > > Cheers, > From xen-devel-bounces@lists.xenproject.org Thu Sep 17 12:15:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 12:15:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423983.1648782 (Exim 4.92) (envelope-from ) id 1x7B18-0005dZ-Dj; Thu, 17 Sep 2026 12:15:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423983.1648782; Thu, 17 Sep 2026 12:15:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7B18-0005dR-A9; Thu, 17 Sep 2026 12:15:06 +0000 Received: by outflank-mailman (input) for mailman id 1423983; Thu, 17 Sep 2026 12:15:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7B16-0005dH-M9 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 12:15:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7B15-0081hy-Je for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 14:15:03 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabd9c7-bab6-0a2a0a5309dd-0a2a450aad26-4 for ; Thu, 17 Sep 2026 14:15:03 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabd9c6-f2d2-0a2a450a0019-ac6904fe91b6-3 for ; Thu, 17 Sep 2026 14:15:03 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 70873602CA; Thu, 17 Sep 2026 12:15:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 894761F00893; Thu, 17 Sep 2026 12:15:00 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789647301; bh=gkbPrcWx7naDFzx6es9+fglMGRB1RD3y/GInwlzOxG0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=l9x6i3WuvpeAcNcSCVNaCtMy5SaRo1F+MZuI+PgVBSML9X+5R+oQzomOBe+PerxoF MGnUJJPBiBDo05wMQ6X2KJcxdTZENp23PzB7WcnSwSqj62YzmxsyGgJ7HZBIPXjfEF E8dIJpEOvURwajkhYJ8tZHYQ6DR7NoU4HbmBYBXiWsOXfSshDWbFnC/MWHjo/l6SjU kyARmxn8MXXrjxfSzwNY5oyHwnrB7W7LX+V0sI6oGEFdrpZUh+ZlK2RgUPaDlHkss4 ui9Wsp50EnRuS0GxbBmgweTiv/MsHviRvjcYoGFHOH38WcDLv/iZ2YR+oN+hK1zE4l XEyjqlwBekiag== Date: Thu, 17 Sep 2026 14:14:57 +0200 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: References: <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> X-purgate-ID: tlsNG-4011c0/1789647303-50ACCCFC-D73F6C38/0/0 X-purgate-type: clean X-purgate-size: 2514 Le Wed, Sep 16, 2026 at 08:41:36AM -0700, Paul E. McKenney a crit : > On Wed, Sep 16, 2026 at 05:23:31PM +0200, Frederic Weisbecker wrote: > > Le Wed, Sep 16, 2026 at 07:55:02AM -0700, Paul E. McKenney a crit : > > > Perhaps in rcu_core() in kernels booted with use_softirq? I am thinking > > > specifically of the checks for deferred quiescent states. I don't (yet) > > > see a need to modify rcu_check_quiescent_state(). > > > > > > Maybe other places as well. ;-) > > > > Hmm this tracking would have to happen on preempt_schedule() just like we > > do for PREEMPT_RCU. Or am I missing something? And then we would need a > > list scan of those tasks. > > I am thinking of the case where a trampoline is interrupted before entering > (or after leaving) its RCU Tasks Trace read-side critical section. Then > there is a softirq handler on the back of that interrupt handler, and > RCU_SOFTIRQ is invoked, calling rcu_core(). Specifically: > > /* Report any deferred quiescent states if preemption enabled. */ > if (IS_ENABLED(CONFIG_PREEMPT_COUNT) && (!(preempt_count() & PREEMPT_MASK))) { > rcu_preempt_deferred_qs(current); > } else if (rcu_preempt_need_deferred_qs(current)) { > guard(irqsave)(); > set_need_resched_current(); > } > > Preemption is enabled, but we should not report a quiescent state because > we have interrupted a trampoline. Correct? Right! > > Or we can build the blocked task list handling, that we already have for PREEMPT_RCU, > > when CONFIG_RCU_TASKS && !CONFIG_PREEMPT_RCU. We would just only add tasks when > > preempted in .text.rcu_no_qs since rcu_read_lock() would still disable > > preemption on normal explicit readers. So I wouldn't expect more overhead due to > > that blocked list tracking built since it would rarely track tasks. > > Yes, we could avoid the list of tasks by treating the preemption within > the trampoline the same as preemption within an RCU read-side critical > section, but there might not be an rcu_read_unlock() to clean up. > Which could be a problem. Ah yes, good point. > > Trampolines that transfer control to tracing code could supply the needed > cleanup call. But last I checked, there were trampolines that transferred > directly back to the original code, with no opportunity for cleaning up. > > Or am I still missing a trick here? You're right. So we'll indeed need to reuse the deferred qs points here. Thanks. -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Thu Sep 17 12:16:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 12:16:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1423989.1648791 (Exim 4.92) (envelope-from ) id 1x7B25-00067Z-Lv; Thu, 17 Sep 2026 12:16:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423989.1648791; Thu, 17 Sep 2026 12:16:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7B25-00067Q-JA; Thu, 17 Sep 2026 12:16:05 +0000 Received: by outflank-mailman (input) for mailman id 1423989; Thu, 17 Sep 2026 12:16:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7B23-000675-6v for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 12:16:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7B22-002sPn-Jd for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 14:16:02 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabd9fe-bab6-0a2a0a5309dd-0a2a4509ce2a-6 for ; Thu, 17 Sep 2026 14:16:02 +0200 Received: from [52.101.85.11] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabda00-be1a-0a2a45090019-3465550b08f9-3 for ; Thu, 17 Sep 2026 14:16:01 +0200 Received: from BN9PR03CA0579.namprd03.prod.outlook.com (2603:10b6:408:10d::14) by PH8PR12MB7373.namprd12.prod.outlook.com (2603:10b6:510:217::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Thu, 17 Sep 2026 12:15:57 +0000 Received: from BN3PEPF00022BC4.namprd05.prod.outlook.com (2603:10b6:408:10d:cafe::6) by BN9PR03CA0579.outlook.office365.com (2603:10b6:408:10d::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.12 via Frontend Transport; Thu, 17 Sep 2026 12:15:57 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF00022BC4.mail.protection.outlook.com (10.167.248.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Thu, 17 Sep 2026 12:15:55 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Thu, 17 Sep 2026 07:15:54 -0500 Received: from [10.59.21.158] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Thu, 17 Sep 2026 07:15:52 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IGlDCTHqdiaYCJ1zHnb7i+/Q36sp4C/NZLAJxmkvaIoGHB9aiOS2cAPSZQm9r4WNBdcvSW59mQa47z9acCkCaTiDze5P5qfMpTgu3/V6pcT0AGrBZULN4+qD9hx+r3FPTWb4A6/iUjb4YTZeEcUFDA3teRL7w4ba/FqsmMnzjfnq9vGGVKXHVSAsc/SMx2CItl6ovQUr5uN5ziofvJ/wlXI/ZmW1En2isGeLtHUKancV9PwKIlL8F5IYW7UJ+gPTHXzOviSqFGH0q8EmFbyRANvH5Iy4El0bI557GFXljDKMjyKt7kcG/UXzR6u3EdIOtf3FLdyGG9mOtvCqBjaPGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=u8O8o+6GognuIehsqoEsV+kIhBgi+XgprtCO7CZ1tAg=; b=jS2ZrkrK46djc8R9aN/uKnMlvengEb6eiRHIFxOon9Gf6jhEBwCD9ALMW4ZUQfiVIkjSUseV8nwxDdfIqZWY3iOimLSm+ky3zu/FAb4MPsfoK626pNDY7GFz2n6pSLcPY3h5MnTi/jesZnmCmG2lqo6hyWP36//sncGtBsaZyPSH7ZIoBt+W2a12ZVcEFd7ku+nznhLh736/pnWMztinM73dN3CaBoFZMlztx5ontk9AYydSY1FNuXrl2vhLz41AWnDYXTIW6QG7fQRhggnt6Txtmew1Y/39P6wKMA+U2Dz+hKggsCpNVhdvsZsura7LWm/Dvvu29nKZj3mS1ZpOJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip is 165.204.84.17) smtp.rcpttodomain=valinux.co.jp smtp.mailfrom=amd.com; dmarc=temperror action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u8O8o+6GognuIehsqoEsV+kIhBgi+XgprtCO7CZ1tAg=; b=IJ1mQDj88/f7al/91wE1tg6uoN8mAnv4JQPyk+kzK6lUMYDOmiaCHn+6fDlV2OP6M9uuPZhSn245730UYsnOoP+vL3Pp2ntU+5BpZW1+CQu/WCMqdv8QkmaUojSsz7OrTG729F5vHwdgab8F2hx/xLhWmNRpYvPtRhG1EMDCUBA= X-MS-Exchange-Authentication-Results: spf=temperror (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=temperror action=none header.from=amd.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of amd.com: DNS Timeout) Message-ID: <78d6b1a6-5a59-409a-9d44-64314a4db106@amd.com> Date: Thu, 17 Sep 2026 14:15:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration To: Hirokazu Takahashi , CC: , Jan Beulich , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20260911094213.79936-1-taka@valinux.co.jp> <20260911094213.79936-2-taka@valinux.co.jp> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260911094213.79936-2-taka@valinux.co.jp> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BC4:EE_|PH8PR12MB7373:EE_ X-MS-Office365-Filtering-Correlation-Id: 0d13a5c0-faef-437d-e89d-08df14b56c92 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|376014|1800799024|82310400026|36860700016|6133799003|22082099003|18002099003|4143699003|10067099003|56012099006|11063799006; X-Microsoft-Antispam-Message-Info: Lree6iDbUR143qXShvxW3pbmYusne725lb0yu7GYEulkudOlHwZyMfZL1MTC/31OixzHfO6B5ra58wezsuvdnu+8gPqRkuydee3WV2Tt5TYOvxcbFhjRjEAJO911h6chdmYQe5segusQGvlUJlNUuPnhacJ2AiJEaqNOkMd56uU9wBnqG1Q5YLOrUnOP0LKrTVjsa9clKglfQVSaX75IG1M/1UfytvXUVijT2WnzhcrUYgtgZY1DD6F//EfTt5JnrQAKv1l1UbOeLCSpghJjJCi9MiIGerQ+VjaARgigJWKQ9M/EfiixWiagL/Xoi/tMzW9XuMpcu+g2uS9gRsvLdHAIlMs2XDoHm8tXkCiEUJwXQi8QlNTF5oPhr1RkH8o9g1iBYr+2lsRa1EaciVGNoQY9HQ/sII+ix2MLWk+lKpjeToWj4hVtq0E9FxEShoNCE6XrH4ZZbeQno+uzIyYz0YpqzrYakBRLAdWN5nBfFcZ7vNbexJ+oDKpsfdAC1jwtezhM2MVaYjeI6BhtlGMONGeshz3cAm+ib3R5iglJz2t8kRJSDhpeDxM2OnaUMQiEekNNlOhydvapqHUmeWM2B4IA1cOFTU3+drCbs+ksmyQYzMF+BZ6LuOIzkL44QCKQlW+aR1WvxN6mc/ZuKB49ma2xsTIQX1q5Krdn8mu3PDtt3l7I6Hj/lVs0J1iG/Qcs0XmUtgtB9Rqg9g1Ud1Lzdg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(376014)(1800799024)(82310400026)(36860700016)(6133799003)(22082099003)(18002099003)(4143699003)(10067099003)(56012099006)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: IHmqKweDyW6EK8QwYPGD/mNE+fV7wtLGaGf5Q6czGU30tUW9R6LhNH2m+MWntzFVQMLY8rq3bIbpbJz+PrZARFn+mzDyWx+qd15d6dn6e/vsKj1Te4j+lsSpMGFvEcVZSczrIq6lejDdhVvCpMFhfD5glwh3v9/Y8IlWaEMd5EXTPimjICZANX9JkVoKZlei/xIZjZuvD2BQUK1awxtXqPgsiFILqYnZIgFQ8yNV+xtsY6XU3ZAOsO25rP2V/5pdxxGcCIj5PlGbwHS72lJHVdiOmyzTlnyqioiTv4GpOJ0GjBvLfi/G+C3kQe5chZAORWlMBChFIbVXUkVLlKOaL51IZ4/WZyR7c8T0hg7612J8kp9Qfu5kweEI5URGh8JT7XR0ROWJ49ndWoHpFNGFLIP2ndfUdLpkz6qxpsFKtGKJSwVPXA1uB4B1ZzggXsPf X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2026 12:15:55.2717 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0d13a5c0-faef-437d-e89d-08df14b56c92 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF00022BC4.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7373 X-purgate-ID: tlsNG-bad1c0/1789647362-BC2F4034-8C84BCAA/0/0 X-purgate-type: clean X-purgate-size: 24780 On 11-Sep-26 11:42, Hirokazu Takahashi wrote: > Parse the 'cpu-map' node in the Device Tree to extract CPU topology > information. If the 'cpu-map' node is absent, simply ignore it. > > Signed-off-by: Hirokazu Takahashi > Reviewed-by: Jan Beulich # common, acpi > --- > Changes in v10: > - Postpone the invocation of init_cpu_topology() until after nr_cpu_ids > is finalized. > - Improve the Device Tree cpu-map node parsing logic: > * Rename functions and variables to accurately reflect the DT nodes > being processed. > * Simplify the parsing algorithm by eliminating recursive calls and > avoiding passing INVALID_TOPO_ID as an argument. > - Unify all license headers to GPL-2.0-only. > - Return an error instead of triggering an ASSERT() when duplicate CPU > definitions are detected. > - Replace BUG_ON() with ASSERT() for condition checks in > dt_init_cpu_topology(). > - Update commit messages to remove details that no longer match the > current implementation. > > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/setup.c | 3 + > xen/arch/arm/smpboot.c | 5 + > xen/common/Kconfig | 22 ++ > xen/common/Makefile | 1 + > xen/common/cpu-topology.c | 62 +++++ > xen/common/cpu.c | 5 + > xen/common/device-tree/Makefile | 1 + > xen/common/device-tree/cpu-topology.c | 347 ++++++++++++++++++++++++++ > xen/drivers/acpi/Makefile | 1 + > xen/drivers/acpi/topology.c | 41 +++ > xen/include/xen/acpi.h | 13 + > xen/include/xen/cpu-topology.h | 34 +++ > xen/include/xen/dt-cpu-topology.h | 35 +++ > 14 files changed, 571 insertions(+) > create mode 100644 xen/common/cpu-topology.c > create mode 100644 xen/common/device-tree/cpu-topology.c > create mode 100644 xen/drivers/acpi/topology.c > create mode 100644 xen/include/xen/cpu-topology.h > create mode 100644 xen/include/xen/dt-cpu-topology.h > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 843a43897e..1e0fd4957e 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -19,6 +19,7 @@ config ARM > select HAS_ALTERNATIVE if HAS_VMAP > select HAS_DEVICE_TREE_DISCOVERY > select HAS_DOM0LESS > + select HAS_GENERIC_CPU_TOPOLOGY > select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE > select HAS_STACK_PROTECTOR > select HAS_STATIC_MEMORY > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 86532d0a35..108f1c703e 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -10,6 +10,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -387,6 +388,8 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr) > nr_cpu_ids = smp_get_max_cpus(); > printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", nr_cpu_ids); > > + init_cpu_topology(); > + > /* > * Some errata relies on SMCCC version which is detected by psci_init() > * (called from smp_init_cpus()). > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > index 1806c47a08..904130efdf 100644 > --- a/xen/arch/arm/smpboot.c > +++ b/xen/arch/arm/smpboot.c > @@ -9,10 +9,12 @@ > > #include > #include > +#include > #include > #include > #include > #include > +#include > #include > #include > #include > @@ -244,6 +246,9 @@ static void __init dt_smp_init_cpus(void) > } > else > tmp_map[i] = hwid; > + > + /* Pass the info to dt_init_cpu_topology() */ > + map_cpu_to_dt_node(i, cpu); This should be moved to the above else branch which is taken on a success only. > } > > if ( !bootcpu_valid ) > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index da80fdba84..29879a9131 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -140,6 +140,9 @@ config HAS_EX_TABLE > config HAS_FAST_MULTIPLY > bool > > +config HAS_GENERIC_CPU_TOPOLOGY > + bool > + > config HAS_IOPORTS > bool > > @@ -191,6 +194,25 @@ config VM_EVENT > config NEEDS_LIBELF > bool > > +config GENERIC_CPU_TOPOLOGY > + bool > + > +config DT_CPU_TOPOLOGY > + bool "Device tree based CPU topology support (UNSUPPORTED)" Can you please explain why unsupported? > + depends on HAS_GENERIC_CPU_TOPOLOGY && DEVICE_TREE_PARSE && UNSUPPORTED > + select GENERIC_CPU_TOPOLOGY > + help > + Retrieve CPU topology information from the device tree to optimize > + vCPU scheduling. > + > +config ACPI_CPU_TOPOLOGY > + bool "ACPI based CPU topology support (UNSUPPORTED)" > + depends on HAS_GENERIC_CPU_TOPOLOGY && ACPI && UNSUPPORTED > + select GENERIC_CPU_TOPOLOGY > + help > + Retrieve CPU topology information from the ACPI PPTT to optimize > + vCPU scheduling. > + > config NUMA > bool > > diff --git a/xen/common/Makefile b/xen/common/Makefile > index 6018e25614..901bb37925 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -5,6 +5,7 @@ obj-$(CONFIG_GENERIC_BUG_FRAME) += bug.o > obj-$(CONFIG_HYPFS_CONFIG) += config_data.o > obj-$(CONFIG_CORE_PARKING) += core_parking.o > obj-y += cpu.o > +obj-$(CONFIG_GENERIC_CPU_TOPOLOGY) += cpu-topology.init.o > obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o > obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += device.o > obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o > diff --git a/xen/common/cpu-topology.c b/xen/common/cpu-topology.c > new file mode 100644 > index 0000000000..f784afbd3d > --- /dev/null > +++ b/xen/common/cpu-topology.c > @@ -0,0 +1,62 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +static void __init free_topology_table(void) > +{ > + unsigned int cpu; > + > + for ( cpu = 0; cpu < nr_cpu_ids; cpu++ ) > + { > + free_cpumask_var(cpu_topology[cpu].thread_sibling); > + free_cpumask_var(cpu_topology[cpu].core_sibling); > + free_cpumask_var(cpu_topology[cpu].cluster_sibling); > + } > + > + XVFREE(cpu_topology); > +} > + > +void __init init_cpu_topology(void) > +{ > + unsigned int cpu; > + int ret; > + > + cpu_topology = xvzalloc_array(struct cpu_topology, nr_cpu_ids); > + if ( !cpu_topology ) > + return; I don't think this is ok for this function not to let the caller about the error. That's especially important for failures from actual DT/ACPI topology initialization. You don't even print anything. > + > + for ( cpu = 0; cpu < nr_cpu_ids; cpu++ ) > + { > + if ( !zalloc_cpumask_var(&cpu_topology[cpu].thread_sibling) || > + !zalloc_cpumask_var(&cpu_topology[cpu].core_sibling) || > + !zalloc_cpumask_var(&cpu_topology[cpu].cluster_sibling) ) > + { > + free_topology_table(); > + return; > + } > + } > + > + if ( acpi_disabled ) > + ret = dt_init_cpu_topology(); > + else > + ret = acpi_init_cpu_topology(); > + > + /* Free the CPU topology table if initialization fails. */ > + if ( ret != 0 ) > + free_topology_table(); > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/common/cpu.c b/xen/common/cpu.c > index f09af0444b..9591ada60a 100644 > --- a/xen/common/cpu.c > +++ b/xen/common/cpu.c > @@ -1,5 +1,6 @@ > #include > #include > +#include > #include > #include > #include > @@ -46,6 +47,10 @@ const unsigned long cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)] = { > #undef MASK_DECLARE_2 > #undef MASK_DECLARE_1 > > +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY > +struct cpu_topology *__ro_after_init cpu_topology; > +#endif /* CONFIG_GENERIC_CPU_TOPOLOGY */ > + > static DEFINE_RWLOCK(cpu_add_remove_lock); > > bool get_cpu_maps(void) > diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile > index 9036e455d6..6ee670b5f4 100644 > --- a/xen/common/device-tree/Makefile > +++ b/xen/common/device-tree/Makefile > @@ -1,6 +1,7 @@ > obj-y += bootfdt.init.o > obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo-fdt.init.o > obj-$(CONFIG_HAS_DEVICE_TREE_DISCOVERY) += bootinfo.init.o > +obj-$(CONFIG_DT_CPU_TOPOLOGY) += cpu-topology.init.o > obj-y += device-tree.o > obj-$(CONFIG_DOMAIN_BUILD_HELPERS) += domain-build.init.o > obj-$(filter $(CONFIG_DOM0LESS_BOOT),$(CONFIG_HAS_DEVICE_TREE_DISCOVERY)) += dom0less-build.init.o > diff --git a/xen/common/device-tree/cpu-topology.c b/xen/common/device-tree/cpu-topology.c > new file mode 100644 > index 0000000000..ce9da0bb36 > --- /dev/null > +++ b/xen/common/device-tree/cpu-topology.c > @@ -0,0 +1,347 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Derived from Linux kernel 7.0's $drivers/base/arch_topology.c > + * Parse cpu topology information. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define INVALID_TOPO_ID (~0U) > + > +struct cpu_map { > + unsigned int thread_id; > + unsigned int core_id; > + unsigned int cluster_id; > + unsigned int socket_id; > +}; > + > +static struct cpu_map __initdata cpu_map[NR_CPUS] = { > + [0 ... NR_CPUS - 1] = { > + .thread_id = INVALID_TOPO_ID, > + .core_id = INVALID_TOPO_ID, > + .cluster_id = INVALID_TOPO_ID, > + .socket_id = INVALID_TOPO_ID, > + }, > +}; > +static struct dt_device_node *__initdata dt_cpu_table[NR_CPUS]; > + > +static void __init setup_siblings_masks(unsigned int target_cpu) > +{ > + const struct cpu_topology *target_topo = &cpu_topology[target_cpu]; > + const struct cpu_map *target_map = &cpu_map[target_cpu]; > + unsigned int cpu; > + > + /* Update cluster, core and thread sibling masks */ > + for_each_possible_cpu(cpu) > + { > + const struct cpu_topology *cpu_topo = &cpu_topology[cpu]; > + const struct cpu_map *map = &cpu_map[cpu]; > + > + if ( target_cpu > cpu ) > + continue; > + > + if ( target_map->socket_id != map->socket_id ) > + continue; > + > + cpumask_set_cpu(target_cpu, cpu_topo->core_sibling); > + cpumask_set_cpu(cpu, target_topo->core_sibling); This does not compile. > + > + if ( target_map->cluster_id != map->cluster_id ) > + continue; > + > + cpumask_set_cpu(target_cpu, cpu_topo->cluster_sibling); > + cpumask_set_cpu(cpu, target_topo->cluster_sibling); > + > + if ( target_map->core_id != map->core_id ) > + continue; > + > + cpumask_set_cpu(target_cpu, cpu_topo->thread_sibling); > + cpumask_set_cpu(cpu, target_topo->thread_sibling); > + } > +} > + > +static const struct dt_device_node *__init dt_find_child_node_by_name( > + const struct dt_device_node *dt, > + const char *name) > +{ > + const struct dt_device_node *np; > + > + dt_for_each_child_node(dt, np) > + if ( np->name && (dt_node_cmp(np->name, name) == 0) ) > + return np; Please use dt_node_name_is_equal() here. > + > + return NULL; > +} > + > +void __init map_cpu_to_dt_node(unsigned int cpu, > + struct dt_device_node *cpu_node) > +{ > + if ( cpu < ARRAY_SIZE(dt_cpu_table) ) > + dt_cpu_table[cpu] = cpu_node; > + else > + printk(XENLOG_WARNING > + "cpu %u exceeds the max cpus %zu\n", > + cpu, ARRAY_SIZE(dt_cpu_table)); > +} > + > +static unsigned int __init cpu_node_to_id( > + const struct dt_device_node *cpu_node) > +{ > + unsigned int cpu; > + > + for_each_possible_cpu(cpu) > + if ( cpu_node == dt_cpu_table[cpu] ) > + return cpu; > + > + return INVALID_TOPO_ID; > +} > + > +/* > + * This function returns the Xen cpu number of the DT node. > + */ > +static unsigned int __init get_cpu_for_node( > + const struct dt_device_node *dt_node) > +{ > + const struct dt_device_node *cpu_node = > + dt_parse_phandle(dt_node, "cpu", 0); > + > + if ( !cpu_node ) > + return INVALID_TOPO_ID; > + > + return cpu_node_to_id(cpu_node); > +} > + > +static bool __init is_cpu_map_empty( unsigned int cpu ) Stray space at the end "cpu )" > +{ > + return (cpu_map[cpu].socket_id == INVALID_TOPO_ID) && > + (cpu_map[cpu].cluster_id == INVALID_TOPO_ID) && > + (cpu_map[cpu].core_id == INVALID_TOPO_ID) && > + (cpu_map[cpu].thread_id == INVALID_TOPO_ID); > +} > + > +static int __init parse_core(const struct dt_device_node *core, > + unsigned int socket_id, > + unsigned int cluster_id, > + unsigned int core_id) > +{ > + bool leaf = true; > + unsigned int thread_id; > + unsigned int cpu; > + > + for ( thread_id = 0; ; thread_id++ ) > + { > + const struct dt_device_node *thread; > + char name[20]; > + > + snprintf(name, sizeof(name), "thread%u", thread_id); > + thread = dt_find_child_node_by_name(core, name); > + > + if ( !thread ) > + break; > + > + leaf = false; > + cpu = get_cpu_for_node(thread); > + > + if ( cpu == INVALID_TOPO_ID ) > + { > + printk(XENLOG_ERR > + "ERROR: %s: Can't get CPU for thread\n", dt_node_name(thread)); No need for the ERROR/WARNING prefixes. You already use correct xenlog levels. > + return -EINVAL; > + } > + > + if ( !is_cpu_map_empty(cpu) ) > + { > + printk(XENLOG_ERR > + "ERROR: Duplicate CPU definition for CPU%u\n", cpu); > + return -EINVAL; > + } > + > + cpu_map[cpu].socket_id = socket_id; > + cpu_map[cpu].cluster_id = cluster_id; > + cpu_map[cpu].core_id = core_id; > + cpu_map[cpu].thread_id = thread_id; > + } > + > + cpu = get_cpu_for_node(core); > + > + if ( cpu != INVALID_TOPO_ID ) > + { > + if ( !leaf ) > + { > + printk(XENLOG_ERR "ERROR: %s: Core has both threads and CPU\n", > + dt_node_name(core)); > + return -EINVAL; > + } > + > + if ( !is_cpu_map_empty(cpu) ) > + { > + printk(XENLOG_ERR > + "ERROR: Duplicate CPU definition for CPU%u\n", cpu); > + return -EINVAL; > + } > + > + cpu_map[cpu].socket_id = socket_id; > + cpu_map[cpu].cluster_id = cluster_id; > + cpu_map[cpu].core_id = core_id; > + cpu_map[cpu].thread_id = 0; > + } > + else if ( leaf ) > + { > + printk(XENLOG_ERR > + "ERROR: %s: Can't get CPU for leaf core\n", dt_node_name(core)); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int __init parse_cluster(const struct dt_device_node *cluster, > + unsigned int socket_id, > + unsigned int cluster_id) > +{ > + bool has_cores = false; > + int ret = 0; > + > + if ( dt_find_child_node_by_name(cluster, "cluster0") ) > + { > + printk(XENLOG_WARNING XENLOG_ERROR? > + "WARNING: Topology for clusters of clusters not yet supported\n"); > + return -EINVAL; > + } > + > + for ( unsigned int core_id = 0; ; core_id++ ) > + { > + const struct dt_device_node *core; > + char name[20]; > + > + snprintf(name, sizeof(name), "core%u", core_id); > + core = dt_find_child_node_by_name(cluster, name); > + > + if ( !core ) > + break; > + > + has_cores = true; > + > + ret = parse_core(core, socket_id, cluster_id, core_id); > + if ( ret != 0 ) > + return ret; > + } > + > + if ( !has_cores ) > + printk(XENLOG_WARNING "WARNING: %s: empty cluster\n", > + dt_node_name(cluster)); > + > + return ret; > +} > + > +static int __init parse_socket(const struct dt_device_node *socket, > + unsigned int socket_id) > +{ > + bool has_cluster = false; > + int ret = 0; > + > + for ( unsigned int cluster_id = 0; ; cluster_id++ ) > + { > + const struct dt_device_node *cluster; > + char name[20]; > + > + snprintf(name, sizeof(name), "cluster%u", cluster_id); > + cluster = dt_find_child_node_by_name(socket, name); > + > + if ( !cluster ) > + break; > + > + has_cluster = true; > + ret = parse_cluster(cluster, socket_id, cluster_id); > + if ( ret != 0 ) > + return ret; > + } > + > + /* > + * If no cluster node is defined, assume the socket has > + * a single cluster. > + */ > + if ( !has_cluster ) > + ret = parse_cluster(socket, socket_id, 0); > + > + return ret; > +} > + > +static int __init parse_package(const struct dt_device_node *package) > +{ > + bool has_socket = false; > + int ret = 0; > + > + for ( unsigned int socket_id = 0; ; socket_id++ ) > + { > + const struct dt_device_node *socket; > + char name[20]; > + > + snprintf(name, sizeof(name), "socket%u", socket_id); > + socket = dt_find_child_node_by_name(package, name); > + > + if ( !socket ) > + break; > + > + has_socket = true; > + ret = parse_socket(socket, socket_id); > + if ( ret != 0 ) > + return ret; > + } > + > + /* > + * If no socket node is defined, assume all clusters reside under > + * a single socket. > + */ > + if ( !has_socket ) > + ret = parse_socket(package, 0); > + > + return ret; > +} > + > +static int __init parse_dt_topology(void) > +{ > + const struct dt_device_node *cpus; > + const struct dt_device_node *map; > + > + cpus = dt_find_node_by_path("/cpus"); > + if ( !cpus ) > + return -ENOENT; > + > + map = dt_find_child_node_by_name(cpus, "cpu-map"); > + if ( !map ) > + return -ENOENT; > + > + return parse_package(map); Linux ends this function with for_each_possible_cpu(). What's the reason for dropping it for our case? > +} > + > +int __init dt_init_cpu_topology(void) > +{ > + unsigned int cpu; > + int ret; > + > + ASSERT(acpi_disabled); > + ASSERT(cpu_topology); > + > + ret = parse_dt_topology(); > + if ( ret == 0 ) > + for_each_possible_cpu(cpu) > + setup_siblings_masks(cpu); > + > + return ret; > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile > index 477408afbe..6d676e91d4 100644 > --- a/xen/drivers/acpi/Makefile > +++ b/xen/drivers/acpi/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_ACPI_NUMA) += numa.o > obj-y += osl.o > obj-$(CONFIG_PM_STATS) += pmstat.o > obj-$(CONFIG_PM_OP) += pm-op.o > +obj-$(CONFIG_ACPI_CPU_TOPOLOGY) += topology.init.o > > obj-$(CONFIG_X86) += hwregs.o > obj-$(CONFIG_X86) += reboot.o > diff --git a/xen/drivers/acpi/topology.c b/xen/drivers/acpi/topology.c > new file mode 100644 > index 0000000000..090c793f33 > --- /dev/null > +++ b/xen/drivers/acpi/topology.c > @@ -0,0 +1,41 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > +#include > +#include > + > +/* > + * TODO: Populate the topology information by scanning the ACPI > + * PPTT (Processor Properties Topology Table). > + */ > +int __init acpi_init_cpu_topology(void) > +{ > + unsigned int cpu; The correspondong DT function has two ASSERTs. Why the divergence here? At least the one for cpu_topology existing is a good one (I don't consider the first ASSERT very useful). > + > + /* > + * Generate temporary cpu topology information for now. > + * It assumes that the cpu doesn't have SMT and all CPUs > + * belong to the same socket. > + */ > + for_each_possible_cpu(cpu) > + { > + struct cpu_topology *topo = &cpu_topology[cpu]; > + > + cpumask_set_cpu(cpu, topo->thread_sibling); > + cpumask_copy(topo->core_sibling, &cpu_possible_map); > + cpumask_copy(topo->cluster_sibling, &cpu_possible_map); > + } > + > + return 0; > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h > index 2fdf38cf74..cbb02e0f35 100644 > --- a/xen/include/xen/acpi.h > +++ b/xen/include/xen/acpi.h > @@ -135,6 +135,19 @@ static inline int acpi_boot_table_init(void) > > #endif /*!CONFIG_ACPI*/ > > +#ifdef CONFIG_ACPI_CPU_TOPOLOGY > + > +int acpi_init_cpu_topology(void); > + > +#else /* CONFIG_ACPI_CPU_TOPOLOGY */ > + > +static inline int acpi_init_cpu_topology(void) > +{ > + return -EOPNOTSUPP; > +} > + > +#endif /* CONFIG_ACPI_CPU_TOPOLOGY */ > + > int get_cpu_id(u32 acpi_id); > > unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low); > diff --git a/xen/include/xen/cpu-topology.h b/xen/include/xen/cpu-topology.h > new file mode 100644 > index 0000000000..7cfe3752cd > --- /dev/null > +++ b/xen/include/xen/cpu-topology.h > @@ -0,0 +1,34 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef XEN_CPU_TOPOLOGY_H > +#define XEN_CPU_TOPOLOGY_H > + > +#include You can move it under #ifdef where you actually use these types. > + > +#ifdef CONFIG_GENERIC_CPU_TOPOLOGY > + > +struct cpu_topology { > + cpumask_var_t thread_sibling; > + cpumask_var_t core_sibling; > + cpumask_var_t cluster_sibling; > +}; > + > +extern struct cpu_topology *cpu_topology; > +void init_cpu_topology(void); > + > +#else /* CONFIG_GENERIC_CPU_TOPOLOGY */ > + > +static inline void init_cpu_topology(void) {} > + > +#endif /* CONFIG_GENERIC_CPU_TOPOLOGY */ > + > +#endif /* XEN_CPU_TOPOLOGY_H */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/include/xen/dt-cpu-topology.h b/xen/include/xen/dt-cpu-topology.h > new file mode 100644 > index 0000000000..72b35b3cf2 > --- /dev/null > +++ b/xen/include/xen/dt-cpu-topology.h > @@ -0,0 +1,35 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef XEN_DT_CPU_TOPOLOGY_H > +#define XEN_DT_CPU_TOPOLOGY_H > + > +#include You can move it under #else which is where you actually use the errno code. > + > +struct dt_device_node; > + > +#ifdef CONFIG_DT_CPU_TOPOLOGY > + > +void map_cpu_to_dt_node(unsigned int cpu, struct dt_device_node *cpu_node); > +int dt_init_cpu_topology(void); > + > +#else /* CONFIG_DT_CPU_TOPOLOGY */ > + > +static inline void map_cpu_to_dt_node(unsigned int cpu, > + struct dt_device_node *cpu_node) {} > +static inline int dt_init_cpu_topology(void) > +{ > + return -EOPNOTSUPP; > +} > + > +#endif /* CONFIG_DT_CPU_TOPOLOGY */ > + > +#endif /* XEN_DT_CPU_TOPOLOGY_H */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ ~Michal From xen-devel-bounces@lists.xenproject.org Thu Sep 17 12:32:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 12:32:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424020.1648800 (Exim 4.92) (envelope-from ) id 1x7BHX-0000uF-3A; Thu, 17 Sep 2026 12:32:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424020.1648800; Thu, 17 Sep 2026 12:32:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7BHX-0000u8-0M; Thu, 17 Sep 2026 12:32:03 +0000 Received: by outflank-mailman (input) for mailman id 1424020; Thu, 17 Sep 2026 12:32:02 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7BHV-0000u2-U5 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 12:32:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7BHV-005xG6-AO for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 14:32:01 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabddb2-bab6-0a2a0a5309dd-0a2a4504e392-38 for ; Thu, 17 Sep 2026 14:32:01 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabddc0-b57f-0a2a45040019-4a7de18dcc43-3 for ; Thu, 17 Sep 2026 14:32:01 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e6b885ef8so4468165e9.1 for ; Thu, 17 Sep 2026 05:32:01 -0700 (PDT) Received: from [10.59.1.64] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd216ec7sm67921235e9.8.2026.09.17.05.31.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 05:32:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789648320; x=1790253120; darn=lists.xenproject.org; h=content-type: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:content-type; bh=PIJVJTsQMYgXr0Au3pD7s/neMschib98XYJeD1KMccM=; b=LbjpooqIE4hZ9sDSNFAx26zI4yGiBnQFFrrzWte+eVMpCzBszAyjQBc+fgTYLt510L Ld5MaS0hXI3uOMJOI1vBdmd2n6tGtTDH/5qDos7DzCE4ZKowW+BUtnum7rORPY+6eP0R 7MAk8nWPxe7U2zNRlNAsBdRNtr1itGXtnJG5pa+9N/USN8mJcH7jGOzMwn+p+0UMtWzt mUym/ZtFNkckJj1C6Djzhhkcy+N2/4ProwGzMmB6Wlz5e288y2Ib+mSHgf8Br9azrood lafBCrhliUDT33B9EGOA6w/i2pSz2ooJZo3Nhv/eiKSaTt4RDupLE9wNqJTVqC40ZQ9t /AbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789648320; x=1790253120; h=content-type: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 :content-type; bh=PIJVJTsQMYgXr0Au3pD7s/neMschib98XYJeD1KMccM=; b=dmRsfniZAUolMaX1IIFW/7xtOP4nm0r7gnocu3B+DdiTZBUmqGyPCPa3Qz1cmQO5aW 5Z+Mpv5yaq+CEI15qUtwxD9Ycy0xyGt2DErX7wLM7lEDXgC9j62jnjezky3NGnKvypu4 KJW+sZ70Rn1LDUbD05Ra9UGXwStrx6QH/j7O3MSOiVvk21ofgjiIXrAQAJ6YuPo5azl2 okCmGlAnGmXx0fV8X+mU7hoSsrctSJatEpW2Fofq4i8yIXs+DO/a6UGU3JhAPoCs0WgW d8oZKc0QVSoDlEq+Fq9N4PONEb1/VPyS9ONCnHcQRuwxkzizs7jvEbMKrUuTBECvu006 1kHA== X-Forwarded-Encrypted: i=1; AKwUvBwsUY9Ak5jW4JpaOkZhRfL1VOESgx494JRwZfGTWdGRRHOEiPF3BVu4uu/4+Ms0HdddGsb99SqOpu0=@lists.xenproject.org X-Gm-Message-State: AFuF++kKFbaxq3Bv66+uT95ud/mCRInqudJDnchiosxT+z5mc3zGnMwx wEZc/d+TuyIpmmeWITvg+Zj8NQd3QGqiYR0hFWhiwwHyqsSQ+m31orKUVQDLqPepTP4= X-Gm-Gg: AYBFou0b/LtA43G9inilUo01lyjOvDznBtvTINuWhCGIOOlvaH0qDsIfAuPrkJluAls advkkZrKej1zsM6A6uxgckmzfvVis7TFzdX5R8nayNjpqMkJwoszmV+WzoIRPopueQJ8gwZNl6U h40bz3Lhpc4Hl3YIqLSAuzSEIE4hox+O5MTdGAfPXGLWuIKZ6m6cTPi1ieS1VXXyrqvFDkZMvk7 EMiWol8bTNH0tEMGVDSgxxIPX9RER4Uoa0RN5gf3GdFmFMKccAcDXHafTQfLMOdUNdOpgRiz6RI LJa9VKqwf9jfdSTdJKIABM7I22SdVLmwPvp/Oc25z6555Ld3H3ZpIJrqqOiDO4rS2qKVeczweGe vvEEMH2mDpJ31uEY3djEk7wpG2qrbVfVcX/WrRWkSBL/T5PTGmg9sYVUC2LOLGYaqPEeRcVd4qj YXXRAPAukDQbDHL68oNFclIjiWCy4PtYVgfrLWoX4BlYpTSrphSZoFrlOdVaZgI7KZy4p8jhvDk g== X-Received: by 2002:a05:600c:6592:b0:49e:73e7:888c with SMTP id 5b1f17b1804b1-49eac4626b5mr84698025e9.4.1789648320566; Thu, 17 Sep 2026 05:32:00 -0700 (PDT) Message-ID: Date: Thu, 17 Sep 2026 14:31:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] stubdom: remove build of zlib To: Jan Beulich Cc: Anthony PERARD , Samuel Thibault , xen-devel@lists.xenproject.org References: <20260917075351.37208-1-jgross@suse.com> <20260917075351.37208-3-jgross@suse.com> <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------PgWh1syXWBsGDryZKid1cFKB" X-purgate-ID: tlsNG-ebf023/1789648321-520D5B50-0E452325/35/110847 X-purgate-type: clean X-purgate-size: 8260 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------PgWh1syXWBsGDryZKid1cFKB Content-Type: multipart/mixed; boundary="------------byaMTfrUtNrG3bGzUps4BfC3"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich Cc: Anthony PERARD , Samuel Thibault , xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH v2 2/4] stubdom: remove build of zlib References: <20260917075351.37208-1-jgross@suse.com> <20260917075351.37208-3-jgross@suse.com> <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@suse.com> In-Reply-To: <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------byaMTfrUtNrG3bGzUps4BfC3 Content-Type: multipart/mixed; boundary="------------DwT33C6pZn2eaFC9FCKZTdcp" --------------DwT33C6pZn2eaFC9FCKZTdcp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTcuMDkuMjYgMTI6NTEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNy4wOS4yMDI2 IDA5OjUzLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gVGhlIGxhc3QgdXNlcnMgb2Ygemxp YiBmb3Igc3R1YmRvbXMgaGF2ZSBiZWVuIHJlbW92ZWQuDQo+IA0KPiBMb29raW5nIGF0IHBh dGNoIDEsIEkgY2FuJ3QgcmVhbGx5IGNvbmNsdWRlIHdoZXRoZXIgdGhhdCdzIHdoZXJlIHRo ZSBsYXN0DQo+IHVzZXIgZGlzYXBwZWFyZWQgKG5vIG9jY3VycmVuY2Ugb2YgInpsaWIiIGlu IHRoYXQgcGF0Y2gpLCBvciB3aGV0aGVyIHRoaXMNCj4gcGF0Y2ggcmVhbGx5IGNvdWxkIGdv IGluIHJpZ2h0IGF3YXkuIFBsZWFzZSBjbGFyaWZ5Lg0KDQpJdCBjYW4gZ28gaW4gcmlnaHQg YXdheS4gVGhlIGxhc3QgdXNlciBkaXNhcHBlYXJlZCB3aXRoIGNvbW1pdA0KNmE5NGVhYTJi ZjNmYTA2YjA1ZWQyZGFkM2RkOTExNjA2MDIzNTMyNi4NCg0KDQpKdWVyZ2VuDQo= --------------DwT33C6pZn2eaFC9FCKZTdcp Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------DwT33C6pZn2eaFC9FCKZTdcp-- --------------byaMTfrUtNrG3bGzUps4BfC3-- --------------PgWh1syXWBsGDryZKid1cFKB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqr3b8FAwAAAAAACgkQsN6d1ii/Ey+9 AQf/dWF3ka9WG7AfR8kvrtLCUV+s2VCQk67EnUJzJIhMmY44Xi1oJBryt2sUjQ63Ui01HNLYjYKe HxJY89+kHFti/8HaVc5KERxuqC5GBST40J+E4NzKOF2mOSp3+MHBooVE2r3i7Y1YzSGRnMp/wgd6 kjtcoR8MMxGpVKNl1FMDdLdip9+l0jXf38w22nB/z0VmksmxRI4UCQPHIjbhY7fm24FskMxcagZl yfpgQWZ/RyJvwBroYUKZJZIs/tey0Xt4mMqNqhqkt6e3QWZLO24dTvJSuDUsL/5NPCfoztOBfA72 liCuzYUhlU7HVfUaEO4AbYDULS4BjilBfyMSOHdhxg== =ULZx -----END PGP SIGNATURE----- --------------PgWh1syXWBsGDryZKid1cFKB-- From xen-devel-bounces@lists.xenproject.org Thu Sep 17 13:30:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 13:30:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424091.1648809 (Exim 4.92) (envelope-from ) id 1x7CBY-0007mf-CP; Thu, 17 Sep 2026 13:29:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424091.1648809; Thu, 17 Sep 2026 13:29:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7CBY-0007mY-8k; Thu, 17 Sep 2026 13:29:56 +0000 Received: by outflank-mailman (input) for mailman id 1424091; Thu, 17 Sep 2026 13:29:54 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7CBW-0007mS-OA for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 13:29:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7CBV-00BPNz-Lg for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 15:29:53 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabeb49-2eae-0a2a0a5409dd-0a2a450ae47a-20 for ; Thu, 17 Sep 2026 15:29:52 +0200 Received: from [159.226.251.25] (helo=cstnet.cn) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabeb4d-f2d2-0a2a450a0019-9fe2fb19a85e-3 for ; Thu, 17 Sep 2026 15:29:51 +0200 Received: from dfae2b116770.home.arpa (unknown [36.110.52.2]) by APP-05 (Coremail) with SMTP id zQCowACXADtI66tqC3qBCA--.3599S2; Thu, 17 Sep 2026 21:29:44 +0800 (CST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Wentao Liang To: bhelgaas@google.com Cc: boris.ostrovsky@oracle.com, jgross@suse.com, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, oleksandr_tyshchenko@epam.com, sstabellini@kernel.org, u.kleine-koenig@pengutronix.de, xen-devel@lists.xenproject.org, Wentao Liang , stable@vger.kernel.org Subject: [PATCH] xen/pcifront: Fix PCI device reference leak in pcifront_common_process() Date: Thu, 17 Sep 2026 13:29:44 +0000 Message-Id: <20260917132944.2153421-1-vulab@iscas.ac.cn> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:zQCowACXADtI66tqC3qBCA--.3599S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WF1Uur1rKw1fAFWxWry5twb_yoW8uw1fp3 98AF13Ars0ya40qrZxAF4jga45ZFsrJ3y7C3ySg3s7X34aq3Z5Jw15JF1a9r48G395Zrnx trnxJa1UZF1UXaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPqb7Iv0xC_Kw4lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8I cIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2 AK021l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v2 6F4j6r4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxV W0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv 7VC0I7IYx2IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Cr1j6rxdMcvjeVCFs4IE7xkEbV WUJVW8JwACjcxG0xvY0x0EwIxGrwACjI8F5VAI37AI020EjII2zVCS5cI20VAGYxC7M4II rI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMx AIw28IcVCjz48v1sIEY20_Gr43Wr1UJr1l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAq x4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r 43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF 7I0E14v26F4j6r4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI 0_Gr1j6F4UJwCI42IY6I8E87Iv6xkF7I0E14v26rxl6s0DYxBIdaVFxhVjvjDU0xZFpf9x 07bb5rxUUUUU= X-Originating-IP: [36.110.52.2] X-CM-SenderInfo: pyxotu46lvutnvoduhdfq/1tbiBgQNA2qrq3bHZgAAsx X-purgate-ID: tlsNG-4011c0/1789651792-53ED2CFC-D9A70334/0/0 X-purgate-type: clean X-purgate-size: 2147 pcifront_common_process() gets a reference to the PCI device with pci_get_domain_bus_and_slot() and only drops it on the early error path. Returning directly from the AER handler switch instead of recording the result and falling through to the common pci_dev_put(pcidev) leaks the reference on every successful call. Collect the handler result in a variable and drop the reference on the single exit path again. Fixes: 34ab316d7287 ("xen/pcifront: Drop pcifront_common_process() tests of pcidev, pdrv") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang --- drivers/pci/xen-pcifront.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c index cffc32d66032..5fdce7c41af5 100644 --- a/drivers/pci/xen-pcifront.c +++ b/drivers/pci/xen-pcifront.c @@ -579,6 +579,7 @@ static pci_ers_result_t pcifront_common_process(int cmd, int bus = pdev->sh_info->aer_op.bus; int devfn = pdev->sh_info->aer_op.devfn; int domain = pdev->sh_info->aer_op.domain; + pci_ers_result_t result = PCI_ERS_RESULT_NONE; struct pci_dev *pcidev; dev_dbg(&pdev->xdev->dev, @@ -597,21 +598,25 @@ static pci_ers_result_t pcifront_common_process(int cmd, pci_dbg(pcidev, "trying to call AER service\n"); switch (cmd) { case XEN_PCI_OP_aer_detected: - return pdrv->err_handler->error_detected(pcidev, state); + result = pdrv->err_handler->error_detected(pcidev, state); + break; case XEN_PCI_OP_aer_mmio: - return pdrv->err_handler->mmio_enabled(pcidev); + result = pdrv->err_handler->mmio_enabled(pcidev); + break; case XEN_PCI_OP_aer_slotreset: - return pdrv->err_handler->slot_reset(pcidev); + result = pdrv->err_handler->slot_reset(pcidev); + break; case XEN_PCI_OP_aer_resume: pdrv->err_handler->resume(pcidev); - return PCI_ERS_RESULT_NONE; + break; default: dev_err(&pdev->xdev->dev, "bad request in aer recovery operation!\n"); } } - return PCI_ERS_RESULT_NONE; + pci_dev_put(pcidev); + return result; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Sep 17 14:51:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 14:51:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424193.1648830 (Exim 4.92) (envelope-from ) id 1x7DRy-0002L4-Am; Thu, 17 Sep 2026 14:50:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424193.1648830; Thu, 17 Sep 2026 14:50:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7DRy-0002Kx-7Y; Thu, 17 Sep 2026 14:50:58 +0000 Received: by outflank-mailman (input) for mailman id 1424193; Thu, 17 Sep 2026 14:50:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x7DRw-0002Kr-Bk for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 14:50:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7DRv-003KPq-OR for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 16:50:55 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aabfe3a-2eae-0a2a0a5409dd-0a2a4502dbdc-22 for ; Thu, 17 Sep 2026 16:50:55 +0200 Received: from [74.125.225.99] (helo=mail-wr2-f35.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aabfe4f-6ca4-0a2a45020019-4a7de1638689-3 for ; Thu, 17 Sep 2026 16:50:55 +0200 Received: by mail-wr2-f35.google.com with SMTP id ffacd0b85a97d-48437356d60so526706f8f.3 for ; Thu, 17 Sep 2026 07:50:55 -0700 (PDT) Received: from [10.72.3.52] ([91.26.93.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4870bf27198sm16171656f8f.15.2026.09.17.07.50.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 07:50:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789656655; x=1790261455; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=e4dF3hk9Uxz0Ygi6JMqQi0SH29NrgEpW+/dmOOr6Fbs=; b=sQZCk+WAMOyauuUYRJFdXeRF71IWjW1hua5CnyLX9WxZXTRqqJbAYM2QSyXIBAXLMW eH+WBKi3ElhxoeYGul89vw/68u3PNFwATw8Z7kC/2PKP2tuT3lrOaMppV3dVrhYhOBFd IvVMPfOS8sCTXSzzxDJghoaGFqv0GjCGGOBOvjaPy8qoi2SHhpONuRczZHPGhvF0YtsF hR9D3HoucY890ecJMeH9Gbxb4wOCwq1P7m4Pt2NlIdo+tpxy//Sk2bXkQr+c9WkJA//M DGxYM6QQB6rZ9MILazUxvpLvJEuFia0VXUc1hZqrGY2yCKAq/9AZiUZnf82RY2XGVoPY d+qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789656655; x=1790261455; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=e4dF3hk9Uxz0Ygi6JMqQi0SH29NrgEpW+/dmOOr6Fbs=; b=Ek9E7zZtTbtgplIJGN2SVQ2SM55OpoyVhXST+BDBOarRlfgzNxUZYelarPCTxQjdCa IxUcFB4ORf5Dva7nkqH/XTtfBuLBt51uE60nzV5zNVlX/wb59rilRoRxtVn+qqG6AD1/ h0LeCcuxPv9rwtiNUJZ4d0iZrMdXSNYfEEZogTkNmjlb4knJjeKPchydXqvhFMzG+0gK jq48ZbZi3y5/utkBqoLyHBU6KCQjhssjEi+FrHcBP9R5el5tvyRSXv7JuNiny4HjDn4G yjNcWImZDHr+SUUFD37pu1sIz2JAqT+EU4jQ8uSndDs8cOItYyzSYdCkrV8B39rkrey2 sNjQ== X-Forwarded-Encrypted: i=1; AKwUvBxQYCaWbwU+3YXTvC7biiV2wNECpMVcoMGyFas5LRvk53uUlWcIdOraJExmU1mry+noMIl0sTzW5YA=@lists.xenproject.org X-Gm-Message-State: AFuF++ls7CiCKo+QoinXhdOV4FZ7UGhZwGdFwlykUQ6PTSE8VhQHYP8x kGalTUxlK8WB7akkY4NHA6b5nEtyVJiGktYG0PphpAjl4sBg3fYqZA/C X-Gm-Gg: AYBFou2L3meBNwGfgmfvymYWJGOV38OxqFGROHJHZxBgJ+M8WGrE7ijABPMHr3WGW8Z rzoPm08LQXrRV9fdJMNJRMP/3SZpsHB8yrumBobCJ5NeRCOiNAkRwaeeBU+Yr9N1wmgdgFVi43b +av1zIZzVFGoORg8MoNtZP/Hi/VavVMUA5sK6TNo3dbjjkln3wz7HNMZwdnR7lgu97/aUb8brRD npvU6zsdUqYB8JXPUkdH+Im0Bghsssaje/ixIMzsTtkm8r4x9YO/e58pgvrFhaMKo9DarqWO+nc EiPPcLY61TZo2pA8yQ/nfqS+dj59ReiwU9JHl7fiVyQT2+Ae/3OaUq7v9vCsp/QNhGESXGIVXMV NXhz4acevFilEWpepQPsT6Wab0FTpC0vTFmLpOr3jX4Sr6XPC8pPN5JDU9/Bnhdf41oxN3bZLgc TO2ILco8luxlOyk0Tnb0VHZOoQk1vdjNdvqijwAZu1BpkKLSUUKvBS4sPICmdD1/fjlPvGhGXQx Vi5qA== X-Received: by 2002:a05:6000:4697:b0:485:8ee5:5ffa with SMTP id ffacd0b85a97d-4870d273f7emr6296054f8f.38.1789656654802; Thu, 17 Sep 2026 07:50:54 -0700 (PDT) Message-ID: <8c0855ca-7e32-4b6e-91ed-dc2e72d9693b@gmail.com> Date: Thu, 17 Sep 2026 16:50:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> <2ea26d3b-6413-410f-9cb1-59645cf594e2@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2ea26d3b-6413-410f-9cb1-59645cf594e2@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789656655-F20A82AC-8F708166/10/73395122804 X-purgate-type: spam X-purgate-size: 12517 On 9/14/26 3:13 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> @@ -77,6 +78,64 @@ do { \ >> csr_clear(CSR_SIREG, v); \ >> } while (0) >> >> +#define imsic_vs_csr_write(c, v) \ >> +do { \ >> + csr_write(CSR_VSISELECT, (c)); \ >> + csr_write(CSR_VSIREG, (v)); \ > > As patch context also tells: Excess parentheses. I will drop them then. > >> +} while ( 0 ) >> + >> +/* >> + * Generic switchcase expansion pyramid. >> + * F is the per-operation leaf macro, ireg is the base register index. >> + * Optional extra args (e.g. an operation and/or a value) are forwarded to F >> + * via __VA_ARGS__. > > Just that there's no F below. Oh, right. I will move this comment a little bit down. > >> + * imsic_switchcase_break(ireg, op, v) - emit "case ireg: op(ireg,v); break;" >> + * imsic_switchcase_ret(ireg, op, ...) - emit "case ireg: return op(ireg[,v]);" >> + * The variadic tail is optional so the same leaf works for both read (no v) >> + * and swap (with v). >> + */ >> +#define imsic_switchcase_break(ireg, op, v) \ >> + case ireg: \ >> + op(ireg, v); \ >> + break; >> + >> +#define imsic_switchcase_ret(ireg, op, ...) \ >> + case ireg: \ >> + return op(ireg, ##__VA_ARGS__); >> + >> +#define imsic_switchcase_2(F, ireg, ...) \ >> + F(ireg + 0, ##__VA_ARGS__) \ >> + F(ireg + 1, ##__VA_ARGS__) > > Ah, there is an F here. > > This (recurring below) shows another problem: The two F invocations > look syntacticlly incorrect, due to the missing semicolon. Semicolon > use wants redoing everywhere here. I will drop then ';' from imsic_switchcase_{break,ret}. > > Further (and again throughout) I think we'd be better off using either > standard C constructs (e.g. __VA_ARGS__) or the gcc extension > permitting use of ## after a comma. A mix of both always looks odd > (to me at least). I will follow C standard here. > > Finally, unlike further up, here (and below) ireg wants parenthesizing. I will add some. > >> @@ -389,6 +448,76 @@ int cf_check vcpu_imsic_init(struct vcpu *v) >> return 0; >> } >> >> +/* >> + * Arguments of the imsic_vsfile_local_*() helpers, which are executed by the >> + * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). >> + */ >> +struct imsic_vsfile_data { >> + unsigned int hgei; >> + unsigned int nr_eix; >> + struct imsic_mrif *mrif; > > I can't spot any use of this field (and hence I also can't judge > whether const wants adding). It should be introduced later in the another patch. > >> +}; >> + >> +/* >> + * Execute func() on the pCPU which owns the IMSIC interrupt file func() is >> + * going to work with. >> + * >> + * An IMSIC VS-file is reachable only through hstatus.VGEIN of the hart the >> + * file belongs to, and a guest interrupt file index is meaningless on any >> + * other hart, so such work always has to be done by that very hart. >> + * >> + * The local case runs with IRQs disabled to provide func() with the same >> + * environment it is given when it is called from the function call IPI >> + * handler. >> + */ >> +static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), >> + void *data) > > If this is supposed to be passed struct imsic_vsfile_data *, why not say > so here? Be as type-safe as possible. Of course the callback function > has to use void *. At the moment, I don't see where I am using void * so I will use struct imsic_vsfile_data * instead. > >> +static void cf_check imsic_vsfile_local_clear(void *data) >> +{ >> + unsigned int i; >> + const struct imsic_vsfile_data *idata = data; >> + unsigned long new_hstatus, old_hstatus, old_vsiselect; >> + >> + /* We can only zero-out if we have a IMSIC VS-file */ >> + if ( !idata->hgei ) >> + return; > > Wouldn't it make sense to avoid the call here altogether then? I think it is better to have this if () here instead of the caller side as this function one day could be just directly (w/ imsic_call_on_cpu) and even the way how it is called now and in the case of imsic_call_on_cpu() is executed on local cpu then it will be basically just direct call of imsic_vsfile_local_clear(). So in the case I am not missing something I prefer to have a check here. > >> + old_vsiselect = csr_read(CSR_VSISELECT); > > Likely obvious to you, but I can't spot why vsiselect would need saving > here. If you want me to ack such code, please add at least brief comments. I think then it will be better to put the comment once above struct imsic_vsfile_data and then just point here to that comment as basically it will be needed for all imsic_vsfile_local_* helpers. So basically I am suggesting: --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ ... @@ /* * Arguments of the imsic_vsfile_local_*() helpers, which are executed by the * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). + * + * The helpers interrupt whatever vCPU context is loaded on that pCPU, which + * generally isn't the vCPU the interrupt file belongs to. To reach the file + * they retarget hstatus.VGEIN and select the file's registers through + * vsiselect. Both CSRs are live state of the interrupted vCPU (vsiselect is + * saved to struct arch_vcpu only on context switch, but the interrupted vCPU + * may resume guest execution without one), hence the helpers have to restore + * them before returning. */ struct imsic_vsfile_data { unsigned int hgei; unsigned int nr_eix; struct imsic_mrif *mrif; }; @@ ... @@ static void cf_check imsic_vsfile_local_clear(void *data) /* We can only zero-out if we have a IMSIC VS-file */ if ( !idata->hgei ) return; + /* See the comment ahead of struct imsic_vsfile_data. */ old_vsiselect = csr_read(CSR_VSISELECT); old_hstatus = csr_read(CSR_HSTATUS); @@ ... @@ static void cf_check imsic_vsfile_local_read_clear(void *data) csr_clear(CSR_HGEIE, BIT(idata->hgei, UL)); + /* See the comment ahead of struct imsic_vsfile_data. */ old_vsiselect = csr_read(CSR_VSISELECT); old_hstatus = csr_read(CSR_HSTATUS); @@ ... @@ static void cf_check imsic_vsfile_local_update(void *data) * stack. */ + /* See the comment ahead of struct imsic_vsfile_data. */ old_vsiselect = csr_read(CSR_VSISELECT); old_hstatus = csr_read(CSR_HSTATUS); Does it look clear now? > >> + old_hstatus = csr_read(CSR_HSTATUS); >> + new_hstatus = old_hstatus & ~HSTATUS_VGEIN; >> + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); >> + csr_write(CSR_HSTATUS, new_hstatus); >> + >> + imsic_vs_csr_write(IMSIC_EIDELIVERY, 0); >> + imsic_vs_csr_write(IMSIC_EITHRESHOLD, 0); >> + >> + for ( i = 0; i < idata->nr_eix; i++ ) >> + { >> + imsic_eix_write(IMSIC_EIP0 + i * 2, 0); >> + imsic_eix_write(IMSIC_EIE0 + i * 2, 0); >> +#ifdef CONFIG_RISCV_32 >> + imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); >> + imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); >> +#endif > > In asm/imsic.h I see > > #define IMSIC_EIPx_BITS 32 > > Why is the number of CSR writes different here for RV32 vs RV64? IMSIC_EIPx_BITS is the unit the AIA spec numbers the eip/eie registers by. On RV32 all of eip0..eip63 exist and are 32 bits wide. On RV64 only the even-numbered ones exist, each being 64 bits wide and covering what eip and eip cover on RV32; accessing an odd-numbered one is an illegal instruction. Hence one 64-bit group of interrupt identities takes one register on RV64, but two on RV32. I will add some small comments: for ( i = 0; i < idata->nr_eix; i++ ) { /* On RV64 a 64-bit EIx group is the even-numbered register alone. */ imsic_eix_write(IMSIC_EIP0 + i * 2, 0); imsic_eix_write(IMSIC_EIE0 + i * 2, 0); #ifdef CONFIG_RISCV_32 /* * On RV32 it is split into the even-numbered (low half) and the * following odd-numbered (high half) register. */ imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); #endif } > And > if so, why would you not use the 64-bit write function, allowing the > #ifdef to be omitted? I can introduce something like: /* * On RV64 a 64-bit EIx group is the even-numbered register alone, whereas * on RV32 it is split into the even-numbered (low half) and the following * odd-numbered (high half) register. */ static void imsic_eix_write64(unsigned int ireg, uint64_t val) { imsic_eix_write(ireg, val); if ( IS_ENABLED(CONFIG_RISCV_32) ) imsic_eix_write(ireg + 1, val >> 32); } And then: for ( i = 0; i < idata->nr_eix; i++ ) { imsic_eix_write64(IMSIC_EIP0 + i * 2, 0); imsic_eix_write64(IMSIC_EIE0 + i * 2, 0); } Would it be better? Or instead of imsic_eix_write64() I could just have a combination of imisc_vsfile_local_clear(): imsic_eix_write(ireg, 0); if ( IS_ENABLED(CONFIG_RISCV_32) ) imsic_eix_write(ireg + 1, 0); > >> @@ -689,6 +818,14 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, >> >> void imsic_migrate_vcpu(struct vcpu *v) >> { >> + unsigned int new_vsfile_hgei; >> + unsigned int new_vsfile_cpu; >> + unsigned int nr_hw_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, >> + BITS_PER_TYPE(uint64_t)); > > As written, this could also be 64. uint64_t is a fixed-width type after > all. The question here is: Which variable's type do you really mean > here? The minimum number of hardware EIx groups is 1 (for the minimum 63 supported interrupt identities, i.e. DIV_ROUND_UP(63 + 1, 64) = 1), and the maximum is 32 (for 2047 identities), on both RV32 and RV64.You are right regarding BITS_PER_TYPE(uint64_t). Since an architectural EIx group always covers 64 interrupt identities regardless of XLEN, using BITS_PER_TYPE(uint64_t) is unnecessarily indirect when we mean a constant 64-bit group size.I will simplify this in v3 to use 64. > >> + struct imsic_vsfile_data vsfile_data = { >> + .nr_eix = nr_hw_eix, > > The local variable looks to be used only here. Is there really a need > for such a local variable? No, I will drop nr_hw_eix. > >> @@ -699,5 +836,27 @@ void imsic_migrate_vcpu(struct vcpu *v) >> if ( v->arch.last_cpu == NR_CPUS ) >> return; >> >> + /* >> + * At this point, all interrupt producers are still using the old IMSIC >> + * VS-file. >> + */ >> + >> + /* >> + * Latch the pCPU the new interrupt file is taken from: vgein_assign() >> + * allocates it from v->processor's pool of guest interrupt files, and >> + * only that hart can access the file afterwards. >> + */ >> + new_vsfile_cpu = v->processor; > > Same here: Is this variable really needed? Technically no, it could be used v->processor everywhere but just for readability (to how spec is wording migration process) I think I will prefer to have new_vsfile_cpu here. But if it doesn't make sense I can agree to drop it. > And what exactly is the comment > telling me? I am re-reading it now and it looks just useless. I think that initially I thought that for some reason v->processor could change during the end of migration and so by that I wanted to fix new vsfile cpu so all the interrupts will go there before migration functon for that vcpu will be called again and reschedule all the interrupt to new v->processor. I think it isn't real case so the comment could be dropped. > >> + new_vsfile_hgei = vgein_assign(v); >> + >> + /* We don't support SW interrupt files at the moment. */ >> + BUG_ON(!new_vsfile_hgei); >> + >> + vsfile_data.hgei = new_vsfile_hgei; > > And again - any real need for the separate local variable? Here I agree, we could have only vsfile_data.hgei. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Sep 17 15:40:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 15:40:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424235.1648839 (Exim 4.92) (envelope-from ) id 1x7EDe-0000Rq-Tq; Thu, 17 Sep 2026 15:40:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424235.1648839; Thu, 17 Sep 2026 15:40:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7EDe-0000Rj-QZ; Thu, 17 Sep 2026 15:40:14 +0000 Received: by outflank-mailman (input) for mailman id 1424235; Thu, 17 Sep 2026 15:40:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7EDd-0000Rd-Qc for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 15:40:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7EDd-008e78-0J for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 17:40:13 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aac09d2-8faa-0a2a0a5109dd-0a2a4503e446-32 for ; Thu, 17 Sep 2026 17:40:12 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aac09db-fae8-0a2a45030019-ac6904fe93be-3 for ; Thu, 17 Sep 2026 17:40:12 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 3666E60204; Thu, 17 Sep 2026 15:40:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D81BB1F000FF; Thu, 17 Sep 2026 15:40:10 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 98EA8CE1716; Thu, 17 Sep 2026 08:40:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789659610; bh=OnYr6zMfa+cOfnhiHI6/0JGoc6S5Gsj1WeIOONeYOVs=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=hcvQWlllk84UctC7FJV5+Iain7lAuduBRO6z+yL3t53gBs3K5x933ujpp6K9IYYo7 eCUvlyIqRf/1fHAeUjXgmhAl8T5UIu8zVkdDz7M+8odIRYwbhn2mMScpw6NJ6vKuvo S+HQwwO+z7y/+TIgLsPfDLmkVZcLsd7gORLkKcupTeH6WyCLgszAqZrcH25OiH6w5p hh8beW5jD1BC0KZ5dRJA/WDQ21iYAyRHR0fDNE1CI3UfmJmcxqHhe85nw44QJyfg7E p9qBPzqxanQ07NR44YW6yh/VAu/KEDUuMkUys+s8jvEqk3idTYzwPbBE0vGR+TPz/Q fZmzmQykfpn4g== Date: Thu, 17 Sep 2026 08:40:10 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: <8fea176a-0ca0-4a70-8cf9-8240a22359e4@paulmck-laptop> Reply-To: paulmck@kernel.org References: <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-33051d/1789659612-77AF14E9-B56B6AED/0/0 X-purgate-type: clean X-purgate-size: 2919 On Thu, Sep 17, 2026 at 02:14:57PM +0200, Frederic Weisbecker wrote: > Le Wed, Sep 16, 2026 at 08:41:36AM -0700, Paul E. McKenney a crit : > > On Wed, Sep 16, 2026 at 05:23:31PM +0200, Frederic Weisbecker wrote: > > > Le Wed, Sep 16, 2026 at 07:55:02AM -0700, Paul E. McKenney a crit : > > > > Perhaps in rcu_core() in kernels booted with use_softirq? I am thinking > > > > specifically of the checks for deferred quiescent states. I don't (yet) > > > > see a need to modify rcu_check_quiescent_state(). > > > > > > > > Maybe other places as well. ;-) > > > > > > Hmm this tracking would have to happen on preempt_schedule() just like we > > > do for PREEMPT_RCU. Or am I missing something? And then we would need a > > > list scan of those tasks. > > > > I am thinking of the case where a trampoline is interrupted before entering > > (or after leaving) its RCU Tasks Trace read-side critical section. Then > > there is a softirq handler on the back of that interrupt handler, and > > RCU_SOFTIRQ is invoked, calling rcu_core(). Specifically: > > > > /* Report any deferred quiescent states if preemption enabled. */ > > if (IS_ENABLED(CONFIG_PREEMPT_COUNT) && (!(preempt_count() & PREEMPT_MASK))) { > > rcu_preempt_deferred_qs(current); > > } else if (rcu_preempt_need_deferred_qs(current)) { > > guard(irqsave)(); > > set_need_resched_current(); > > } > > > > Preemption is enabled, but we should not report a quiescent state because > > we have interrupted a trampoline. Correct? > > Right! > > > > Or we can build the blocked task list handling, that we already have for PREEMPT_RCU, > > > when CONFIG_RCU_TASKS && !CONFIG_PREEMPT_RCU. We would just only add tasks when > > > preempted in .text.rcu_no_qs since rcu_read_lock() would still disable > > > preemption on normal explicit readers. So I wouldn't expect more overhead due to > > > that blocked list tracking built since it would rarely track tasks. > > > > Yes, we could avoid the list of tasks by treating the preemption within > > the trampoline the same as preemption within an RCU read-side critical > > section, but there might not be an rcu_read_unlock() to clean up. > > Which could be a problem. > > Ah yes, good point. > > > > > Trampolines that transfer control to tracing code could supply the needed > > cleanup call. But last I checked, there were trampolines that transferred > > directly back to the original code, with no opportunity for cleaning up. > > > > Or am I still missing a trick here? > > You're right. So we'll indeed need to reuse the deferred qs points here. Except this is getting a bit involved. Don't get me wrong, if Josef is happy to take this on, far be it from me to stand in his way. But if not, we should be willing to treat this optimization as a follow-on effort, whether by Josef or someone else. Thanx, Paul From xen-devel-bounces@lists.xenproject.org Thu Sep 17 16:35:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 16:35:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424291.1648864 (Exim 4.92) (envelope-from ) id 1x7F5A-0007gK-TM; Thu, 17 Sep 2026 16:35:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424291.1648864; Thu, 17 Sep 2026 16:35:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7F5A-0007gD-QC; Thu, 17 Sep 2026 16:35:32 +0000 Received: by outflank-mailman (input) for mailman id 1424291; Thu, 17 Sep 2026 16:35:31 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7F59-0007g7-Do for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 16:35:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7F58-00EGwx-Qr for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 18:35:30 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aac16ac-2eae-0a2a0a5409dd-0a2a4508ecd2-20 for ; Thu, 17 Sep 2026 18:35:30 +0200 Received: from [74.125.230.205] (helo=mail-qk2-f13.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aac16d1-f659-0a2a45080019-4a7de6cd8479-3 for ; Thu, 17 Sep 2026 18:35:30 +0200 Received: by mail-qk2-f13.google.com with SMTP id d75a77b69052e-530e2f50d01so11301601cf.0 for ; Thu, 17 Sep 2026 09:35:30 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5326208ea78sm56756741cf.24.2026.09.17.09.35.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2026 09:35:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789662929; x=1790267729; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:subject:cc:to:from:message-id:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=BF23L7IjgM1pfHyM3ghg4jPhGbV/DtVtyTw2lo+n/XU=; b=K7n1gBHRIRkHaxBSPi3oarOq3WgVPhj/Snsh3mNCAutc5DWdbn6l7mF8uMkc0Qwmg0 y7h+aR4d3IkZnvgBUPRPjAAetjUuaEyrwSbFoaPQWe4ivL7EUAnF56B13iH+6HgEEHaC mR5nbV8TMbVbxlcy0BNruFUe+kpFFfIiu10V562t21HG+UNsrfwUATU6WienZJUzDwQC 6QEJRx2H7BUXiWl4BKPCF9I17p69Kxj27IMa7Pnm8S1DlQVs9hnJ8r9AlvU7sz+Anauc Dow7fKlN/98ZBb5c/Ieb4I2SEHCPFh154F5P2MozrFOptbn6ndNTTP+eyOgBHTylDx1n nDLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789662929; x=1790267729; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:subject:cc:to:from:message-id:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BF23L7IjgM1pfHyM3ghg4jPhGbV/DtVtyTw2lo+n/XU=; b=OZ7BEuSY1lUhtVHw1pVvJ/LBRP65DKUUVqGBEzsh6BUqhT1ueVEXhvS352RSrFT/JH GKOcFoZJa3h6gn67fb3fy+oVPkeD5e4UnxcWxlSZXRHoNd0r0w0PtcLnMKs7yMtQQmKu 0rwioDDT17DOUVj9DPktkL4h5kEzm5qIlbug7nttcagOAEzW8x06jtjGStO9GeJBnNMx uJt/of66xIOIZe2pU5sqNVxEGpFkhIfG8d3jBz2ndG/9ECy10fOt8zT2VKNxqysjg+hj Q/d+wsUa8u+0166E23/TpbdOJLjcrA4T+jWVRfP3R8Vx/2GY6ZjuI944T8CeVmNRFulC XkHA== X-Forwarded-Encrypted: i=1; AKwUvBwv8k+09Q5VzZsuwMLU4uvvi+whhhKONkjkOzNhLVSJote87/LtaFp5JyVmSvuBY6/l+C6qyUJEhAo=@lists.xenproject.org X-Gm-Message-State: AFuF++kj7c8LtWMWGz20vmFpDJK53u0t1CJ1JOBZjkn7fdEn4StPXqPR 0CnjqIDUBG3FhwUWlFHelzJxfvIKfRvFZMJnA1bC+YdCMnbR3gbjR0w5Jz+YcNRZN7g= X-Gm-Gg: AYBFou1Bdp8szR1epHriFW8J9NDHIRwIiDejSVm4cFQ+0mWaS6viwTIpi0I8mU4rfJP lYZuj/Im45P77DtmTd9erXZ+aS3jceztE6HujKrb0XJzc+oJluhSZ+Ob6q1qD8J633DqMHMf32c Tk6N+YSziF3R05cm5fgHadgJbaHpIUgs5dYM9Uaka5vPuO6Kpc8BCx1BlyPdVwhmMynJm582yA6 9m6Dl2g+gxvgDP8qvv/gmER5D0IXgdC9KX3QLz9HKl3q55Atm+NQGrjj1ddEOwPR7LGvttuwWAr qLGqI3jH47+5laR9gfqRoxIW79OEHrEikQMn+1gcmdsp6OgBy4j8yvIYzvy/lxLB1f5Q43SoFJN K09LP9FeAMgCOvcPDrua361errnUsOjiNjGBRrc0ZeAF9wSSct3yBq/lRloWgv+ZY5kQsDyAYrd +fwQUACIBbvwDkfuP4s1giLIUgF6Hrq7qkPZxTVlOUPn4z2CUWXn+Z30k7CWQCEolNlMqPXt22b QM21cYaDAtnyyFLJzEubi7U4Kk2t+h9YaPITECoW6VdKmFJab6fP6mc X-Received: by 2002:a05:622a:1ba0:b0:530:b2e1:2f3b with SMTP id d75a77b69052e-5329b61d526mr11929121cf.50.1789662928648; Thu, 17 Sep 2026 09:35:28 -0700 (PDT) Date: Thu, 17 Sep 2026 16:35:19 +0000 Message-ID: From: Josef Bacik To: "Paul E. McKenney" , Frederic Weisbecker Cc: Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines In-Reply-To: <8fea176a-0ca0-4a70-8cf9-8240a22359e4@paulmck-laptop> References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> <8fea176a-0ca0-4a70-8cf9-8240a22359e4@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1789662930-CC37587B-4F69848E/0/0 X-purgate-type: clean X-purgate-size: 1270 On Thu, 17 Sep 2026 08:40:10 -0700, Paul E. McKenney wrote: > On Thu, Sep 17, 2026 at 02:14:57PM +0200, Frederic Weisbecker wrote: > > You're right. So we'll indeed need to reuse the deferred qs points here. > > Except this is getting a bit involved. > > Don't get me wrong, if Josef is happy to take this on, far be it from me > to stand in his way. But if not, we should be willing to treat this > optimization as a follow-on effort, whether by Josef or someone else. Follow-on works for me. For what it's worth 03/13 is already fairly close to what Frederic describes, just outside the core flavor: no task-list scan (the GP waits per CPU for a pass through __schedule() or an EQS), the irq-exit preemption path checks the interrupted IP and queues the task as a holdout before the switch, and the holdout is keyed on where the task was interrupted so nothing is needed from the trampoline tail. Moving that IP check into the tick / rcu_exp_handler() / deferred-QS paths and reusing the blocked-tasks list is something I'm happy to look at once this has settled. v4 will pick up Alexei's ask (reader emitted by the BPF JIT around the fentry and fexit regions rather than in the glue) and the idle-CPU hole Sashiko found. Thanks, Josef From xen-devel-bounces@lists.xenproject.org Thu Sep 17 16:55:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 16:55:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424329.1648872 (Exim 4.92) (envelope-from ) id 1x7FOo-0002BC-Eo; Thu, 17 Sep 2026 16:55:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424329.1648872; Thu, 17 Sep 2026 16:55:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7FOo-0002B5-CD; Thu, 17 Sep 2026 16:55:50 +0000 Received: by outflank-mailman (input) for mailman id 1424329; Thu, 17 Sep 2026 16:55:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7FOm-0002Ay-Nq for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 16:55:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7FOl-0025RJ-NO for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 18:55:47 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aac1b87-e002-0a2a0a5209dd-0a2a4501a44a-28 for ; Thu, 17 Sep 2026 18:55:47 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aac1b92-5984-0a2a45010019-ac6904fed37e-3 for ; Thu, 17 Sep 2026 18:55:47 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 95F76601EF; Thu, 17 Sep 2026 16:55:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45EB21F00893; Thu, 17 Sep 2026 16:55:45 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 0461BCE1716; Thu, 17 Sep 2026 09:55:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789664145; bh=kimfGEK+WeQrCTnIb5ePzNtWXHK0EcqiD+euMxaQ0do=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=T9OE8qLzP1qfh6XFbx+1FEoAjXMXA5nopSdvlfyoaHtqeRG7yuIX6hvGsZ2fZDZHC LlZHivU+VHSNOyLlTJD9LcDm74HSY0oBYS6V98tfaqWPsGPg0x3pT212aZxB1cTj2h H5i+iwmISzuUJTFqG0ROiZDclaI7Dsm5HDgAJBJ1MUlStbHa5H1eEUO5Q0pdnLLmRn bfDIUKXG/xV9fr8ZZBBKeo2cOSk+IR2Blsw1i4L2ofdwxlH5VeRL80zT4LC59Fh7Zv 2QJ/t3AdkTEG0yssMOFKDF+buK2RR78k+s/SfH4SFxaON89u5sImLoK7VX3+tMuq4b 4hANaNhRy05TA== Date: Thu, 17 Sep 2026 09:55:44 -0700 From: "Paul E. McKenney" To: Josef Bacik Cc: Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: <5734196a-22ab-428e-9565-d7ba787d3eb1@paulmck-laptop> Reply-To: paulmck@kernel.org References: <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> <8fea176a-0ca0-4a70-8cf9-8240a22359e4@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-d62444/1789664147-BE27A757-D9F8FAD3/0/0 X-purgate-type: clean X-purgate-size: 1401 On Thu, Sep 17, 2026 at 04:35:19PM +0000, Josef Bacik wrote: > On Thu, 17 Sep 2026 08:40:10 -0700, Paul E. McKenney wrote: > > On Thu, Sep 17, 2026 at 02:14:57PM +0200, Frederic Weisbecker wrote: > > > You're right. So we'll indeed need to reuse the deferred qs points here. > > > > Except this is getting a bit involved. > > > > Don't get me wrong, if Josef is happy to take this on, far be it from me > > to stand in his way. But if not, we should be willing to treat this > > optimization as a follow-on effort, whether by Josef or someone else. > > Follow-on works for me. For what it's worth 03/13 is already fairly > close to what Frederic describes, just outside the core flavor: no > task-list scan (the GP waits per CPU for a pass through __schedule() or > an EQS), the irq-exit preemption path checks the interrupted IP and > queues the task as a holdout before the switch, and the holdout is keyed > on where the task was interrupted so nothing is needed from the > trampoline tail. Moving that IP check into the tick / rcu_exp_handler() / > deferred-QS paths and reusing the blocked-tasks list is something I'm > happy to look at once this has settled. > > v4 will pick up Alexei's ask (reader emitted by the BPF JIT around the > fentry and fexit regions rather than in the glue) and the idle-CPU hole > Sashiko found. Even better! ;-) Thanx, Paul From xen-devel-bounces@lists.xenproject.org Thu Sep 17 18:37:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 18:37:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424383.1648881 (Exim 4.92) (envelope-from ) id 1x7Gz4-0006ij-99; Thu, 17 Sep 2026 18:37:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424383.1648881; Thu, 17 Sep 2026 18:37:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Gz4-0006ic-6A; Thu, 17 Sep 2026 18:37:22 +0000 Received: by outflank-mailman (input) for mailman id 1424383; Thu, 17 Sep 2026 18:37:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Gz2-0006iW-Ow for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 18:37:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Gz1-00EVsp-Bh for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 20:37:19 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aac3329-bab6-0a2a0a5309dd-0a2a4506e348-40 for ; Thu, 17 Sep 2026 20:37:19 +0200 Received: from [103.168.172.145] (helo=fout-a2-smtp.messagingengine.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aac335d-195a-0a2a45060019-67a8ac919f23-3 for ; Thu, 17 Sep 2026 20:37:18 +0200 Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfout.phl.internal (Postfix) with ESMTP id 50CAAEC0246; Thu, 17 Sep 2026 14:37:17 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-09.internal (MEProxy); Thu, 17 Sep 2026 14:37:17 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Sep 2026 14:37:08 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1789670237; x=1789756637; bh=k0Tpt9jrFZIKZxdXfsQxY2n5bJUNuBFFI7/5Z5UdDSc=; b= MCyqT8NAnkCGUq8gn+uVxXIBTMq2pUT4hoOLsbuEXKvyXPQCv+pR/3XVdyu74wXI 7+3izDP89X038UT2trt56TbUOt/9JZImJUd5VFRhRdVw8JF7LKgR6VDj6B9Y6wuA zaTNiHv4tzWjZ6vkmhxdvI4pXI5ToBt4p2iI3Y0F7p5dSCQegjS70b/s1NYs4c12 iw/JgmwkBc/lLUM/8LIfqNEbccMLjATk05VWjl5T9BbuDx09h0dv/0o2nbR95mg1 jear36vRfkb7B35UMjDuIf8P6amyIOaYkqK0MoNPH4QU4jrhpMIlFxONeaqg1LoB NhTwN5KF2WBM65MvcJmAHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1789670237; x=1789756637; bh=k0Tpt9jrFZIKZxdXfsQxY2n5bJUNuBFFI7/ 5Z5UdDSc=; b=KwMphScEnfqRooEdLoI5Dfo6ZcilwicnDITqojMUQqru06kRque doo3Cugq3Jzfx+vUFZ0tZSf23a85z8KlFAwlqK7evJrznL6Kfu8mCgCp3ZpFGnOJ Usq1JwvjfZyAgFUNhOpKzkJuS9N9vzSo1A5/jqx1z/1gvn/h67qe2vljo9wWjWaz ZFDsG7+ZAnsxcGsUHNrt+O8QXVaS5Ifgcd0lAUadqoqMBBScpG52MmD4b6a53Khm WStlUgWhcHtC99yKh2K4h5YMgVA0nadSRjZFHrVCAGsvvE1eK1p98Zd7ql8FH8EA gT+sDyWW3aKLHm6QPMrJUCDLYNBNwoU7tcg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGmFKmh2HR18D4gBJZzQKUVQXL/w6zccRGNDgOFqklXxkmyrWx6/O0xAL8WgUZ068 2T4TkmxL+ecbIs0NJQbEF9SfdF53CkKwZVL+76P++9Jro/L9AXft84OOU/HW6b88UtfbLs vw0C4xh/C9+C+7Y4N0atwaPkZfzt2dlIaabWnQCjZxoMPw9YYrk16vLjJirmyFcSF7Y3Lg oAWgkJ7aaF1FnRllKPyDyy5t5ZCAKUYRKDhLTx6k69ADZc3wBQso+xz/D6rsTsZhf0MTfy D8vwccVHlgYEs3Nz8AZekMROnm5WCyz792/EgrnKKQW9XsbIEXD+LoPUCjYp+G68zFLKNE +SMVN1CGeG6sQ+BwP+fcdC0n+iNdkQJCfXfSt4+R+9iXWNvqQgmiKt1R1lW/DAbhyE1+AI SyB9TcJ9pxs97D/A5U5fDPphq4gPwcQ7pQ2Zc/9hEne3+qpv7BcJi9daT7kDSftSUf/a8y niqL8KGr+BJerOr1fMynac9YQSDuZOIs+91+QuEcHNVOHXyaEdkrPs/aZoe5FSZeN8UMg2 THChobW+s+gK5r2ITlZF5JMEEmrNBlx12SkBSgg9gaE6dDophzczFjirZOlWwY2GHvaBJW J3JphRYYPH6nJuOS/f6jTMB4JDmXNGEKghyRYaHd4iSm1Bxnek5SDk7ISlRQ X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Thu, 17 Sep 2026 20:36:35 +0200 From: Marek Marczykowski To: George Dunlap Cc: Jan Beulich , "xen-devel@lists.xenproject.org" , Daniel Smith , Andrew Cooper Subject: Assisted-by tag (was: Re: [PATCH v2 1/2] EFI: avoid OOB config file reads) Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b+OdSe7mBE9SL46Q" Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-16d1c6/1789670239-F7CCD77B-A3FB2BD9/0/0 X-purgate-type: clean X-purgate-size: 1547 --b+OdSe7mBE9SL46Q Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Sep 2026 20:36:35 +0200 From: Marek Marczykowski To: George Dunlap Cc: Jan Beulich , "xen-devel@lists.xenproject.org" , Daniel Smith , Andrew Cooper Subject: Assisted-by tag (was: Re: [PATCH v2 1/2] EFI: avoid OOB config file reads) On Wed, Sep 16, 2026 at 04:37:07PM +0200, George Dunlap wrote: > Discovered by sashiko+Opus. How does that influence tags on a patch fixing the issue? Should that be Reported-by: sashiko+Opus ? Or maybe Reported-by: George + Assisted-by: sashiko+Opus? Or something else? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --b+OdSe7mBE9SL46Q Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqsMzMACgkQ24/THMrX 1ywvegf+MvYLBIY8ezEjN5y4/ObQrfq20vsvu157ZFXRxn8aNZlQHVKa1//hzEqS nfS3KYkN2hEvl8RwU6ur6aJ1AKc4BP8pGz7uVtpxjuEf5QaYosYwoak31U1FALQx AxyKgfvhsRXrKIDdoLiNR+wnpQDoebz/74o69j9oTHM+py07lAPNs5CQpWDggrUm fhHWdjov8RyvNtqnLM/zMlfPwNUZoWlXl6JEu6xYtkgeDGyYfZpXY3HmYhz28Ifc dmPwyjmyKhadnW+0D/uxxDAWjGiFoVaT6nAn430jyKLpXTHqz5cvWrEImujrcgkg BZyMolQhzm6Us2bQiuwALHt/DDPNhQ== =zehe -----END PGP SIGNATURE----- --b+OdSe7mBE9SL46Q-- From xen-devel-bounces@lists.xenproject.org Thu Sep 17 18:45:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 18:45:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424401.1648890 (Exim 4.92) (envelope-from ) id 1x7H7F-0008Sq-39; Thu, 17 Sep 2026 18:45:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424401.1648890; Thu, 17 Sep 2026 18:45:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7H7F-0008Sj-0Y; Thu, 17 Sep 2026 18:45:49 +0000 Received: by outflank-mailman (input) for mailman id 1424401; Thu, 17 Sep 2026 18:45:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7H7D-0008Sc-4z for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 18:45:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7H7C-00A17P-C5 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 20:45:46 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aac3535-8faa-0a2a0a5109dd-0a2a4504ad16-46 for ; Thu, 17 Sep 2026 20:45:46 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aac3556-b57f-0a2a45040019-aceafc1fdd32-3 for ; Thu, 17 Sep 2026 20:45:46 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 2340643DF2; Thu, 17 Sep 2026 18:45:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43C4C1F00893; Thu, 17 Sep 2026 18:45:39 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789670740; bh=VUqmoZ9tkjprNUAzv5MpNYkWxkSqU7Rla2JQs5OrKPE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=h33H9GduZ2Nbb//sSFkLLwqVDqBIdeknn/eumej5e7rnzoQFxi4MlgOnM2Gt6j7GB iE3tvUHRv+ixjLq+DWgWPyT7DoF/CYAC3R4euNtsJ2N4LHOUWTuAenMrDCqNT8k0zG U59UbDrs8tfw88NjPBWxAmzoXD7fWC5AStfO6GkpqIyMxP60IaZf1VURFo7L1a2N31 CZ97fG48sVdVZAt67BzNGDjQ2uyRlnAdjFzsJJASWRSNkAFHDnymfoO1wKmIi3sYQ/ uiC5mOc8yyM/Z/8oOa/Nnm/1UaEfhLKvQNS2zEGERuhrZ7oxaz7OX2ScghU6oH5ZC+ c1PYnG1LmvA9g== Date: Thu, 17 Sep 2026 20:45:36 +0200 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: References: <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> <8fea176a-0ca0-4a70-8cf9-8240a22359e4@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8fea176a-0ca0-4a70-8cf9-8240a22359e4@paulmck-laptop> X-purgate-ID: tlsNG-ebf023/1789670746-C26CAB50-055BF863/0/0 X-purgate-type: clean X-purgate-size: 879 Le Thu, Sep 17, 2026 at 08:40:10AM -0700, Paul E. McKenney a crit : > > > Trampolines that transfer control to tracing code could supply the needed > > > cleanup call. But last I checked, there were trampolines that transferred > > > directly back to the original code, with no opportunity for cleaning up. > > > > > > Or am I still missing a trick here? > > > > You're right. So we'll indeed need to reuse the deferred qs points here. > > Except this is getting a bit involved. > > Don't get me wrong, if Josef is happy to take this on, far be it from me > to stand in his way. But if not, we should be willing to treat this > optimization as a follow-on effort, whether by Josef or someone else. Sure, I guess I can try the follow-on, especially if it leads to removing all this RCU tasks black magic. Thanks. -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Thu Sep 17 19:25:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 19:25:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424426.1648900 (Exim 4.92) (envelope-from ) id 1x7Hjs-0005fF-V1; Thu, 17 Sep 2026 19:25:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424426.1648900; Thu, 17 Sep 2026 19:25:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Hjs-0005f8-SE; Thu, 17 Sep 2026 19:25:44 +0000 Received: by outflank-mailman (input) for mailman id 1424426; Thu, 17 Sep 2026 19:25:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Hjs-0005f2-EL for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 19:25:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Hjr-003Jdu-Eb for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 21:25:43 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aac3ea6-e002-0a2a0a5209dd-0a2a4509ddc4-20 for ; Thu, 17 Sep 2026 21:25:43 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aac3eb6-be1a-0a2a45090019-ac6904feeaf4-3 for ; Thu, 17 Sep 2026 21:25:43 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 5726F601EF; Thu, 17 Sep 2026 19:25:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05E491F000FF; Thu, 17 Sep 2026 19:25:41 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id BA399CE1771; Thu, 17 Sep 2026 12:25:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789673141; bh=6ZHuttUZCZV4Q8v2OQevWMSgjgpr+6xpv1ywa/+PiNQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=ZmJyLGnYRfFoBTzswnP6QdP7lKNX+3Ys095RUqDUlO0tsNO6mp4CvE8vzXJshuXn3 xPFaDeRb2lcvGNDMeQAUSCw/Rg+CJ9n0q4PX8I1RTGAt+Xo3pxykRcqTvcWblVj5h9 6+hFH6z4eRU+l6RfZ+MRN0rjwcm87Nc8Izl8PAbUP7xB845hooRtpCO93tjcAS3JAs DTb/96iIH3u0adZnc6wfmhiAMA/a8K1oYVoa34Q2L55mtv4tc1KbrzuTbxZidisC0S 7GQbNlj3RmNxpKB49XH1ngw38N9/b1jZSSzgmucNSbV+mc3gCV8a5GAyELDmojUOW0 ZtTl62/MsQchQ== Date: Thu, 17 Sep 2026 12:25:40 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: <33b8e33a-3fad-4b33-9ae7-3948f0e6d3aa@paulmck-laptop> Reply-To: paulmck@kernel.org References: <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> <8fea176a-0ca0-4a70-8cf9-8240a22359e4@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-purgate-ID: tlsNG-bad1c0/1789673143-FC411034-85E50569/0/0 X-purgate-type: clean X-purgate-size: 997 On Thu, Sep 17, 2026 at 08:45:36PM +0200, Frederic Weisbecker wrote: > Le Thu, Sep 17, 2026 at 08:40:10AM -0700, Paul E. McKenney a crit : > > > > Trampolines that transfer control to tracing code could supply the needed > > > > cleanup call. But last I checked, there were trampolines that transferred > > > > directly back to the original code, with no opportunity for cleaning up. > > > > > > > > Or am I still missing a trick here? > > > > > > You're right. So we'll indeed need to reuse the deferred qs points here. > > > > Except this is getting a bit involved. > > > > Don't get me wrong, if Josef is happy to take this on, far be it from me > > to stand in his way. But if not, we should be willing to treat this > > optimization as a follow-on effort, whether by Josef or someone else. > > Sure, I guess I can try the follow-on, especially if it leads to removing > all this RCU tasks black magic. That sounds most excellent, thank you! Thanx, Paul From xen-devel-bounces@lists.xenproject.org Thu Sep 17 20:20:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 20:20:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424458.1648909 (Exim 4.92) (envelope-from ) id 1x7Iam-0005h8-TP; Thu, 17 Sep 2026 20:20:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424458.1648909; Thu, 17 Sep 2026 20:20:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Iam-0005gp-MS; Thu, 17 Sep 2026 20:20:24 +0000 Received: by outflank-mailman (input) for mailman id 1424458; Thu, 17 Sep 2026 20:20:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Ial-0005gj-Ga for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 20:20:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Iak-0075Xx-QH for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 22:20:22 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aac4b6c-bab6-0a2a0a5309dd-0a2a4502c3f8-42 for ; Thu, 17 Sep 2026 22:20:22 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aac4b85-6ca4-0a2a45020019-ac6904fe8efa-3 for ; Thu, 17 Sep 2026 22:20:22 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id E5B52601FF; Thu, 17 Sep 2026 20:20:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B03F1F000FF; Thu, 17 Sep 2026 20:20:20 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789676420; bh=RXB70s8tC0N4djKhk6YxK6M2sEK0IClm9i5YiNUGtD8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=FgWzVoH4Tdgc3xbhEiQn7a6FJ/07+ERma5xsfx6CkqdFWA+dhVut+XxWCw+O3cdHo 353RpR9YS4TSztc8wrKkHDyD3hOLYGP+SFrzV6RR38x+cCsWQrL4Tkx0apZ1LOlbjD Pw+ePTdyDbLqc4xmPt8BS1hyD5vEys0JA49NovRKLhSpDUz7u0bVIDfae91KAFjAWu Lc2oIXJ0sLEUOn/7zsKrlGx2h278H2Ocj/FRGNmzwEbvq6nCQj5a4GNBMRZ3Brx1y7 Mq5DVlrP4IJn0NFAcN7hGMfB3aMSFA7idC83SWUP1zSgwwVqHLkW2tXu3aIDr+xk1O XIViCSjFySfOA== Date: Thu, 17 Sep 2026 22:20:17 +0200 From: Frederic Weisbecker To: Josef Bacik Cc: "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: References: <20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com> <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260915-b4-rcu-tasks-preempt-qs-v3-3-0ad30c4c5ee7@toxicpanda.com> X-purgate-ID: tlsNG-720697/1789676422-F08A42AC-7BEBAFFF/0/0 X-purgate-type: clean X-purgate-size: 2597 Le Tue, Sep 15, 2026 at 01:17:30PM +0000, Josef Bacik a crit : > +static void rcu_tasks_tramp_hold(struct task_struct *t) > +{ > + unsigned long flags; > + > + if (t->rcu_tasks_holdout) > + return; > + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); > + list_add_tail(&t->rcu_tasks_holdout_list, &rcu_tasks_tramp_holdouts); > + WRITE_ONCE(t->rcu_tasks_holdout, true); > + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); > +} > + > +static void rcu_tasks_tramp_release(struct task_struct *t) > +{ > + unsigned long flags; > + > + if (likely(!t->rcu_tasks_holdout)) > + return; > + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); > + list_del_init(&t->rcu_tasks_holdout_list); > + WRITE_ONCE(t->rcu_tasks_holdout, false); > + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); > +} > + > +/** > + * rcu_tasks_irq_resched_enter - Tasks RCU hook for the irq-exit reschedule check > + * @ip: instruction pointer of the interrupted (task-level) context > + * > + * Called with interrupts disabled when an interrupt returning to kernel > + * mode is about to preempt_schedule_irq(), the one context switch that can > + * catch a task inside unmarked trampoline text. Record where the task is > + * parked for as long as it is (rcu_tasks_wait_irq_preempted() looks at > + * that), and if it is inside such text make it a holdout before > + * __schedule() reports the quiescent event; if it is not, this is as good > + * as a voluntary switch for ending an earlier hold. > + */ > +void rcu_tasks_irq_resched_enter(unsigned long ip) > +{ > + struct task_struct *t = current; > + struct rcu_tasks_percpu *rtpcp = this_cpu_ptr(rcu_tasks.rtpcpu); > + > + lockdep_assert_irqs_disabled(); > + WRITE_ONCE(t->rcu_tasks_irq_ip, ip); > + t->rcu_tasks_exit_cpu = smp_processor_id(); > + raw_spin_lock_rcu_node(rtpcp); > + list_add(&t->rcu_tasks_exit_list, &rtpcp->rtp_exit_list); > + raw_spin_unlock_rcu_node(rtpcp); I don't think we can do that. This is too much unconditional overhead on the hot preemption path. rcu_tasks_trampoline_text() should be a condition here. And do we really need to maintain both lists? I understand that they have different purposes. ->rcu_tasks_exit_list is to track preempted tasks on trampoline ->rcu_tasks_holdout_list is to track preempted tasks on trampoline until they ever voluntary schedule() Can the latter replace the former? I see it's used on kprobes and others but I haven't checked the details yet. Thanks. -- Frederic Weisbecker SUSE Labs From xen-devel-bounces@lists.xenproject.org Thu Sep 17 20:31:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 17 Sep 2026 20:31:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424467.1648918 (Exim 4.92) (envelope-from ) id 1x7Ilt-0007v5-R9; Thu, 17 Sep 2026 20:31:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424467.1648918; Thu, 17 Sep 2026 20:31:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Ilt-0007uy-Nx; Thu, 17 Sep 2026 20:31:53 +0000 Received: by outflank-mailman (input) for mailman id 1424467; Thu, 17 Sep 2026 20:31:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Ilr-0007us-V0 for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 20:31:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Ilq-003Qht-IJ for xen-devel@lists.xenproject.org; Thu, 17 Sep 2026 22:31:50 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aac4e1a-8faa-0a2a0a5109dd-0a2a4503dda8-36 for ; Thu, 17 Sep 2026 22:31:50 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aac4e33-fae8-0a2a45030019-aceafc1fd9f0-3 for ; Thu, 17 Sep 2026 22:31:50 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 25A9440F2D; Thu, 17 Sep 2026 20:31:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F115D1F000FF; Thu, 17 Sep 2026 20:31:44 +0000 (UTC) Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id AF6E2CE1771; Thu, 17 Sep 2026 13:31:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789677105; bh=1DNCW5bB+cAYVy5PyJp5VUEN9k9DZzvAe3lm+iP5ciY=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=Ts3RaYNrEkFulPAP4OS7uNGnQMm/6SzgIVeMh8NGZAkrMhOzleLAdfRvTZ6hDjBpn sK3Xe4dOcnOhN9iirOMs0CB2GL2Z6qOI3aMMVN9pozJjUFCtPX2GsXChdiXAMvHv/H A9ja+yO6aO4CuwpA4BPDb/njnc8+lhp17d7MAKl8dciFXjoqTpMKiBiwhuhirN0XzO D1azThDi/j3Cf7bGLueAkZ9BywzCDXdnK4GG5oCv2G8CqZplWKkn8lYBpNwE7UR8ay wI53qK8FbjQmzeKpADME9erclbbWiZVtKHS3EtpdnGGngJcrveU/fvURFyEGsddimA W8zBwB4+X35YA== Date: Thu, 17 Sep 2026 13:31:44 -0700 From: "Paul E. McKenney" To: Frederic Weisbecker Cc: Josef Bacik , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Message-ID: Reply-To: paulmck@kernel.org References: <91687748-0781-4133-baed-43cf82f35ff5@paulmck-laptop> <6afb0afe-e7b8-46b4-9fea-2c7cf4791044@paulmck-laptop> <8b73e1b3-0580-4ba9-b2e0-6363e429808d@paulmck-laptop> <8fea176a-0ca0-4a70-8cf9-8240a22359e4@paulmck-laptop> <33b8e33a-3fad-4b33-9ae7-3948f0e6d3aa@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <33b8e33a-3fad-4b33-9ae7-3948f0e6d3aa@paulmck-laptop> X-purgate-ID: tlsNG-33051d/1789677110-77EC24E9-84BA2323/0/0 X-purgate-type: clean X-purgate-size: 1318 On Thu, Sep 17, 2026 at 12:25:40PM -0700, Paul E. McKenney wrote: > On Thu, Sep 17, 2026 at 08:45:36PM +0200, Frederic Weisbecker wrote: > > Le Thu, Sep 17, 2026 at 08:40:10AM -0700, Paul E. McKenney a crit : > > > > > Trampolines that transfer control to tracing code could supply the needed > > > > > cleanup call. But last I checked, there were trampolines that transferred > > > > > directly back to the original code, with no opportunity for cleaning up. > > > > > > > > > > Or am I still missing a trick here? > > > > > > > > You're right. So we'll indeed need to reuse the deferred qs points here. > > > > > > Except this is getting a bit involved. > > > > > > Don't get me wrong, if Josef is happy to take this on, far be it from me > > > to stand in his way. But if not, we should be willing to treat this > > > optimization as a follow-on effort, whether by Josef or someone else. > > > > Sure, I guess I can try the follow-on, especially if it leads to removing > > all this RCU tasks black magic. > > That sounds most excellent, thank you! Ah, and in case anyone (especially Josef) is wondering, one big advantage of the more elaborate approach is that it allowed the real-time guys to avoid yet another source of IPIs messing with their latencies. Thanx, Paul From xen-devel-bounces@lists.xenproject.org Fri Sep 18 06:02:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 06:02:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424687.1648943 (Exim 4.92) (envelope-from ) id 1x7Rfx-0004gQ-UO; Fri, 18 Sep 2026 06:02:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424687.1648943; Fri, 18 Sep 2026 06:02:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Rfx-0004g4-PD; Fri, 18 Sep 2026 06:02:21 +0000 Received: by outflank-mailman (input) for mailman id 1424687; Fri, 18 Sep 2026 06:02:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Rfw-0004fy-Sd for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 06:02:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Rfv-00FdmJ-HO for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:02:19 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacd3e1-bab6-0a2a0a5309dd-0a2a450cd050-30 for ; Fri, 18 Sep 2026 08:02:19 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacd3eb-f479-0a2a450c0019-4a7de18dc943-3 for ; Fri, 18 Sep 2026 08:02:19 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e620fa473so1971975e9.1 for ; Thu, 17 Sep 2026 23:02:19 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd204c1asm126959335e9.4.2026.09.17.23.02.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 23:02:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789711338; x=1790316138; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=RSeT5yd8NdFFrVtsy5vtjDBjbSJvUp8pS8fV0GkpzDs=; b=ezIZyG12NqOZl6nkPeWcBUCJ96F485z2YjrgUmqGKDGQwcSV2dC3CrkbCbLxCQlLAC mVCB50Xa9v34m6tHuB0CLT3Dsl8IQgnqxbGz8FvCpb1ArrtA91URPkWj4qVcXnrW/HA4 s4Nm4IDe2oyfOLM6ZQRBs8xRDow4k33/hCmbwFBIJAKXy+AouefSNBSyrXFEpw5CohdM g+xVaaAaRkbQqBssvxkxyYXDoLE8Ksa/YEmtyuTQWvKe+eAC1r+T/OAhxyaKvqdeF6tb H1ODay0zJESK+nXN4Bc6Om44VPzH3lQqA0VbsPiHuLdaVMf44OZanfdF+PbA95ih+w4S fSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789711338; x=1790316138; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=RSeT5yd8NdFFrVtsy5vtjDBjbSJvUp8pS8fV0GkpzDs=; b=u0H7+0pHTuMlb1fhdKO1W7lYgtKPpcBEQuB6XIK/BgOCxvzay47Ub22ApZUtbOaaE3 wn2YsxMS2Zl3Q7RkRys18MTSje6QurefQ7SZfC8A5czxQ4ovCFNe+k64cPCFjvHax+fc Z8Obc+UcTEjTVjo/zRPygP0/BDw4lEhEaCJ/5yFRliFF7niCmHJ/O/cM9LYB3oh3LSuQ gi9WoNtXyNHyde/sF52WRy2FYUA92NMc46v9+ULDl0UQkoJ2BFK+sVSaM3qLFBL70Lv+ K3WhAty7l5hsNf6SDX6gspHftyLnyr7GP7uo/T45U9k8TuY/ZHoimiNBVzR8DKigl6ry oS2w== X-Forwarded-Encrypted: i=1; AKwUvByMbiw9l81qnbdw8NPGRP3kj7mjfNqKL21OUe/+R8C+lNwE8C5FhaL8OWX1vBsurHvtEcBL42JjNjI=@lists.xenproject.org X-Gm-Message-State: AFuF++kKpMUfOAGaFIBlzO16STbsSBXnuB8bOATBFzjufr2DSU6ZPVuL BAegk1gGXFP4czxsItV6IJ+GMGCGmTMXIDJUW28buUMJa3Q5m/1YkrhPP6UWIHeWXg== X-Gm-Gg: AYBFou0u1VxBeB/p0Smnmxq5dAB0QRrDw9ong2zvCIsBo+/V92gXi/1O/pWQ+LMq9xR ohqZElMdhAZsmFRtEaZ77iVtuBSOodFP1hJFoghFr32rCFMX7hru/0PHkHW9TXr5YpCdyZ3JKwl cPuppPHn8LfnW2m/JIwRbGhf5Hhdi1bzsLNAAbebciX4WlSX7euvwzitVFAv8xBqogzgVrPdcOn 3MY6aTHN57W0OWMu7pwd1+7vyZ4YKn99o3Nl17pLgRLi5KpmY2m7C9kRZxG1Xo/iqgg2rrdL1EJ UWPK+HEp2Fu+kSQr3YqnIgsAMBNYRu5CicFa/NJ5J+VWlMiUP9Nb2qsIcrq7W7Cl3HybOOVHNZU r9fWgArTi3a0n/8g+48Jz4/LvobJY1X7fO9Vg7x30Vct/+ftIFqght1xGdI5kiIZ9hBkpBb6S9S OHS/BzKbbjBlNGvMUChJ2M4nw/pZtkfmvouy7xFXdrJ3DITiaHvhprHbfGCp/yTY2nyhR3N+r5k Ko= X-Received: by 2002:a05:600c:46c7:b0:49d:7fc:5dc5 with SMTP id 5b1f17b1804b1-49fc56dba6emr13377775e9.1.1789711338574; Thu, 17 Sep 2026 23:02:18 -0700 (PDT) Message-ID: Date: Fri, 18 Sep 2026 08:02:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> <2ea26d3b-6413-410f-9cb1-59645cf594e2@suse.com> <8c0855ca-7e32-4b6e-91ed-dc2e72d9693b@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <8c0855ca-7e32-4b6e-91ed-dc2e72d9693b@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1789711339-028DDA5B-2D08BFCD/0/0 X-purgate-type: clean X-purgate-size: 7196 On 17.09.2026 16:50, Oleksii Kurochko wrote: > On 9/14/26 3:13 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> +#define imsic_switchcase_break(ireg, op, v) \ >>> + case ireg: \ >>> + op(ireg, v); \ >>> + break; >>> + >>> +#define imsic_switchcase_ret(ireg, op, ...) \ >>> + case ireg: \ >>> + return op(ireg, ##__VA_ARGS__); >>> + >>> +#define imsic_switchcase_2(F, ireg, ...) \ >>> + F(ireg + 0, ##__VA_ARGS__) \ >>> + F(ireg + 1, ##__VA_ARGS__) >> >> Ah, there is an F here. >> >> This (recurring below) shows another problem: The two F invocations >> look syntacticlly incorrect, due to the missing semicolon. Semicolon >> use wants redoing everywhere here. > > I will drop then ';' from imsic_switchcase_{break,ret}. Provided that works, i.e. you have no cae where __VA_ARGS__ expands to nothing. >>> +static void cf_check imsic_vsfile_local_clear(void *data) >>> +{ >>> + unsigned int i; >>> + const struct imsic_vsfile_data *idata = data; >>> + unsigned long new_hstatus, old_hstatus, old_vsiselect; >>> + >>> + /* We can only zero-out if we have a IMSIC VS-file */ >>> + if ( !idata->hgei ) >>> + return; >> >> Wouldn't it make sense to avoid the call here altogether then? > > I think it is better to have this if () here instead of the caller side > as this function one day could be just directly (w/ imsic_call_on_cpu) > and even the way how it is called now and in the case of > imsic_call_on_cpu() is executed on local cpu then it will be basically > just direct call of imsic_vsfile_local_clear(). So in the case I am not > missing something I prefer to have a check here. > >> >>> + old_vsiselect = csr_read(CSR_VSISELECT); >> >> Likely obvious to you, but I can't spot why vsiselect would need saving >> here. If you want me to ack such code, please add at least brief comments. > > I think then it will be better to put the comment once above struct > imsic_vsfile_data and then just point here to that comment as basically > it will be needed for all imsic_vsfile_local_* helpers. > > So basically I am suggesting: > > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ ... @@ > /* > * Arguments of the imsic_vsfile_local_*() helpers, which are executed > by the > * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). > + * > + * The helpers interrupt whatever vCPU context is loaded on that pCPU, > which > + * generally isn't the vCPU the interrupt file belongs to. To reach the > file > + * they retarget hstatus.VGEIN and select the file's registers through > + * vsiselect. Both CSRs are live state of the interrupted vCPU > (vsiselect is > + * saved to struct arch_vcpu only on context switch, but the > interrupted vCPU > + * may resume guest execution without one), hence the helpers have to > restore > + * them before returning. > */ > struct imsic_vsfile_data { > unsigned int hgei; > unsigned int nr_eix; > struct imsic_mrif *mrif; > }; > @@ ... @@ static void cf_check imsic_vsfile_local_clear(void *data) > /* We can only zero-out if we have a IMSIC VS-file */ > if ( !idata->hgei ) > return; > > + /* See the comment ahead of struct imsic_vsfile_data. */ > old_vsiselect = csr_read(CSR_VSISELECT); > old_hstatus = csr_read(CSR_HSTATUS); > @@ ... @@ static void cf_check imsic_vsfile_local_read_clear(void *data) > csr_clear(CSR_HGEIE, BIT(idata->hgei, UL)); > > + /* See the comment ahead of struct imsic_vsfile_data. */ > old_vsiselect = csr_read(CSR_VSISELECT); > old_hstatus = csr_read(CSR_HSTATUS); > @@ ... @@ static void cf_check imsic_vsfile_local_update(void *data) > * stack. > */ > > + /* See the comment ahead of struct imsic_vsfile_data. */ > old_vsiselect = csr_read(CSR_VSISELECT); > old_hstatus = csr_read(CSR_HSTATUS); > > > Does it look clear now? Not really, I'm afraid. A much shorter comment mentioning that imsic_..._write() alter vsiselect (if I got things right) would imo be both more direct, more clear, and could easily live at all three sites individually. >>> + old_hstatus = csr_read(CSR_HSTATUS); >>> + new_hstatus = old_hstatus & ~HSTATUS_VGEIN; >>> + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); >>> + csr_write(CSR_HSTATUS, new_hstatus); >>> + >>> + imsic_vs_csr_write(IMSIC_EIDELIVERY, 0); >>> + imsic_vs_csr_write(IMSIC_EITHRESHOLD, 0); >>> + >>> + for ( i = 0; i < idata->nr_eix; i++ ) >>> + { >>> + imsic_eix_write(IMSIC_EIP0 + i * 2, 0); >>> + imsic_eix_write(IMSIC_EIE0 + i * 2, 0); >>> +#ifdef CONFIG_RISCV_32 >>> + imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); >>> + imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); >>> +#endif >> >> In asm/imsic.h I see >> >> #define IMSIC_EIPx_BITS 32 >> >> Why is the number of CSR writes different here for RV32 vs RV64? > > IMSIC_EIPx_BITS is the unit the AIA spec numbers the eip/eie > registers by. On RV32 all of eip0..eip63 exist and are 32 bits wide. On > RV64 only the even-numbered ones exist, each being 64 bits wide and > covering what eip and eip cover on RV32; accessing an > odd-numbered one is an illegal instruction. Hence one 64-bit group of > interrupt identities takes one register on RV64, but two on RV32. > > I will add some small comments: > > for ( i = 0; i < idata->nr_eix; i++ ) > { > /* On RV64 a 64-bit EIx group is the even-numbered register > alone. */ > imsic_eix_write(IMSIC_EIP0 + i * 2, 0); > imsic_eix_write(IMSIC_EIE0 + i * 2, 0); > #ifdef CONFIG_RISCV_32 > /* > * On RV32 it is split into the even-numbered (low half) and the > * following odd-numbered (high half) register. > */ > imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); > imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); > #endif > } > >> And >> if so, why would you not use the 64-bit write function, allowing the >> #ifdef to be omitted? > > I can introduce something like: > > /* > * On RV64 a 64-bit EIx group is the even-numbered register alone, whereas > * on RV32 it is split into the even-numbered (low half) and the following > * odd-numbered (high half) register. > */ > static void imsic_eix_write64(unsigned int ireg, uint64_t val) > { > imsic_eix_write(ireg, val); > if ( IS_ENABLED(CONFIG_RISCV_32) ) > imsic_eix_write(ireg + 1, val >> 32); > } > > And then: > > for ( i = 0; i < idata->nr_eix; i++ ) > { > imsic_eix_write64(IMSIC_EIP0 + i * 2, 0); > imsic_eix_write64(IMSIC_EIE0 + i * 2, 0); > } > > Would it be better? Imo yes. That said, when making the original comment, I was (apparently wrongly, as per the stuff further up) assuming these are direct CSR writes. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 06:11:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 06:11:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424699.1648952 (Exim 4.92) (envelope-from ) id 1x7RoJ-0006cN-QL; Fri, 18 Sep 2026 06:10:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424699.1648952; Fri, 18 Sep 2026 06:10:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7RoJ-0006cF-Mw; Fri, 18 Sep 2026 06:10:59 +0000 Received: by outflank-mailman (input) for mailman id 1424699; Fri, 18 Sep 2026 06:10:57 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7RoH-0006c9-Q8 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 06:10:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7RoH-00FfMW-3K for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:10:57 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacd5ef-e002-0a2a0a5209dd-0a2a4507b232-8 for ; Fri, 18 Sep 2026 08:10:57 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacd5f0-b4ea-0a2a45070019-4a7de18d9e18-3 for ; Fri, 18 Sep 2026 08:10:56 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e79a408deso1596635e9.2 for ; Thu, 17 Sep 2026 23:10:56 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd216028sm128708515e9.7.2026.09.17.23.10.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 23:10:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789711856; x=1790316656; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VKSdUrl5slR8sYu4cKVxDwvqNkKE4AHINuHc25H5PF8=; b=JvgyCHbKORZxpxvElmQyO3IozsyZAhw9wJ1zx3cDkb/e5t7OvudfvUhjw3ZBHLPm2M ACvuY3mu1qH5NJRSPZAkldgmuBjpYydGs1CF9bxm/ElRSeUegSj+ScgaONofDCtO6Wtx AzO0vqQfcZTNeUY4kL14mdTkB9IFNv6NSxc3stX6KpJO2rj29RPk+n001a+vm/0BJ7JB /vLGiny0j2J0giwmL3TFgWQtUqdXaJDpU8knHBhzhPcfGAy1gQJgdIY4TZt7DT4k5Ice eijc3EbFRYjvmQkF1ReSGop0ASGLdocd0pV4JDt6n8AMyJ5KuOqEwIlJM6pdi7PdTemW oukA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789711856; x=1790316656; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=VKSdUrl5slR8sYu4cKVxDwvqNkKE4AHINuHc25H5PF8=; b=J6c1Tq2PtwFVpceAwjBK9bFxQMYnSAm3G4ue5IIp1o56OR+ZjlzA1uN1PHjQiHlgJ0 6ZtoSY0vfh90gKba2nSFsL/lX1erlP4pE54tFyaMQEXUMKRaPRFaaCBsUuEQlupQjQEg oLWe58RMWEvT6jBSWQr09EFNH7rUaleDHxgKNbdHQm1PlW+aAcr3RbGxAlwohGyMNs3I CEx851EPdN/8kViySxL/igeEEJ/vjub+c7kHQq8s4vHOwbVGpxxkS8c3bKZNMeI8LdsE F6Z8KHSDuaoJDeWIiDc0zdB/rp8AFJ4b40mJeV23l0NuDeWLzZP0T8BlI5wnRifc5Ehb 0Cww== X-Gm-Message-State: AFuF++ncoprtqmfe3pjaf5ddtzKusmJO+Kk1qhkpbAO2Wt7YGl1jjexI Bb5oGDmZdzIkiFKPvu13WxvUtNZTvbk56ySBzFuwqc0Fu74/B/EoTUL/5GlThKjuNQ== X-Gm-Gg: AYBFou1QgGbtELNRdSj0L/jPOH/Hga4fVKm04/sUSF4RPTEMDU+UevJeVLG/tl+TTrq vjfdumvFIxYDlMf3jTA+7JAlhe6UpZD9eKiZNUAS29ywvWNZ0267TmQ22gC0LIJ9KYjOidHMcB1 2agkfizBRyx2Q6LaM2RdojXORjdOjKlDKt80YyQGJFJLF5h2GdKRZju1gqaEj4I6sFNB+S5oHVD ida4oEgw77qXE2F0gRS12v1Rb7GAp1wBnPF4kMDN3LSmWOICqSeFv3iNAGObiGOc+pWqgxBKaJr 9Vi07L4f9gneBfx+brbV4LkQUJuW63JnGK9lKcquBYzmHZ+1Apc1G3OiCnmSlX6ljUPT4Y8HEhl apobMNu9U9/MP9vdzX/UCNvSMVpYn0uE5I++maDQA5IrTXqeYPHYvlJlSWauSHLgi2uCj5yeGVz VvdXn0cWAx+pBWKKfPFd6qnvgi8+8jPLfElvb177NqyNJ381ygWKcgEHnhi887t4k55QWHgsCH2 tk= X-Received: by 2002:a05:600c:8b61:b0:49d:e0c:e55e with SMTP id 5b1f17b1804b1-49fc574a635mr15220055e9.23.1789711853175; Thu, 17 Sep 2026 23:10:53 -0700 (PDT) Message-ID: <284816d0-b7e5-4e5a-8feb-d3ee984c95e2@suse.com> Date: Fri, 18 Sep 2026 08:10:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Assisted-by tag To: Marek Marczykowski Cc: "xen-devel@lists.xenproject.org" , Daniel Smith , Andrew Cooper , George Dunlap References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789711857-A46CAAE4-DD7F94D9/0/0 X-purgate-type: clean X-purgate-size: 853 On 17.09.2026 20:36, Marek Marczykowski wrote: > On Wed, Sep 16, 2026 at 04:37:07PM +0200, George Dunlap wrote: >> Discovered by sashiko+Opus. > > How does that influence tags on a patch fixing the issue? Should that be > Reported-by: sashiko+Opus ? Or maybe Reported-by: George + Assisted-by: > sashiko+Opus? Or something else? I was wondering the same, and my plan was to use two Reported-by: here (as I was assuming I was to make a patch here, which maybe now you're intending to do). The alternative I had thought of was to have the Assisted-by: ahead of the Reported-by:, thus trying to clarify (by tags being in chronological order) that it was the finding of the issue where AI had helped. (In principle a 2nd Assisted-by: after the Reported-by: could then indicate which [other] AI helped with making the patch itself.) Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 06:17:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 06:17:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424708.1648960 (Exim 4.92) (envelope-from ) id 1x7RuW-0007Cl-Dv; Fri, 18 Sep 2026 06:17:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424708.1648960; Fri, 18 Sep 2026 06:17:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7RuW-0007Ce-B3; Fri, 18 Sep 2026 06:17:24 +0000 Received: by outflank-mailman (input) for mailman id 1424708; Fri, 18 Sep 2026 06:17:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7RuU-0007CX-S3 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 06:17:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7RuT-00BBBL-J9 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:17:21 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacd766-bab6-0a2a0a5309dd-0a2a4503b36e-42 for ; Fri, 18 Sep 2026 08:17:21 +0200 Received: from [74.125.225.105] (helo=mail-wr2-f41.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacd771-fae8-0a2a45030019-4a7de16980be-3 for ; Fri, 18 Sep 2026 08:17:21 +0200 Received: by mail-wr2-f41.google.com with SMTP id ffacd0b85a97d-4834977ae75so131669f8f.3 for ; Thu, 17 Sep 2026 23:17:21 -0700 (PDT) Received: from [172.18.88.57] (195-200-20-130.mclarenap.oninferno.net. [195.200.20.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48720072501sm1401896f8f.22.2026.09.17.23.17.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 23:17:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789712241; x=1790317041; darn=lists.xenproject.org; h=content-type: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:content-type; bh=vNWdM4gBld9jUsn7+mJExiBKESMp/3Gv72wCXlMEQs0=; b=EHLWrT1ewhF9pJIJUUeYHzxQgL1KXbFlMYCwWNw/sBt5hsyHrUPsiYwo/Zkm9nM449 K1QMZxLLZU0m/hsx1XeHDx0A6QGxw4jUnI9NsuIHKLPwJ2zan4jca292LJJWqfyYNPaw ZK8/cKOky0/aN5AEUPQI4gSkXh+TN7B4iU+0PkMizEYhzX9LK7hTXoIrJSpJyz5RYaew rlbtWUx6jbU/AlEQDTdg/aWjS0be/QOqig30AlwI1vHl4gmWfiONQLd8GTBcwd33hvYW ZxVN+irdCDh4IQLGbMheOvhcvxQhXJao5VGYiZLVAl71BpciCGMrnWStxs+W/Dipjj5u TFHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789712241; x=1790317041; h=content-type: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 :content-type; bh=vNWdM4gBld9jUsn7+mJExiBKESMp/3Gv72wCXlMEQs0=; b=NwTuaKgQh5lOrHCVO1mOwg44XwzULdd/TVfvfaMzHLx/gECePbBFGLyRZtVcbKXcka uDd5pJzsfRuAZDWaTLNs6X7rlTz4wgjVujw/qP78hpWyMkBDCaXaMOy6EB0G3cEiwwnD 5twMabuFHRtKhFA2VbiGLsccOQgOcOyLqOLNfpvOXZE1RUqvk3PRcb6Wm1EXzZJ+aO7q cq2RSf/zD6z0mTNVdOWCdn2MdRenuxSmD7jDY5N6Msh0TPCOQROk6W/xNEnhMdmHpqlm 0kLA0AKviyMvtvRf76gnVPxq3DLLHLXtpcjYqiCplIlYLPX7b1IPLCAyEaREhhipYwz1 G6DQ== X-Forwarded-Encrypted: i=1; AKwUvBzTcJDro3uWi1YaXxPXVpVE31GammqiDjHKaI/YQN3cUbbKmdxskIyHocgXdynn2jGEI9p74k2VXUg=@lists.xenproject.org X-Gm-Message-State: AFuF++lzDbYt4qOP8iiBu1PdgWrBz0NfF8puujqpNFSccHUsGJvzPaL0 V7fW3BV+pjjWRz0K176u+hHNUAsDHAY2yE9Y3sNj2XonvmU6OJ7zsh9yid6K1QXqaZ4= X-Gm-Gg: AYBFou3GGzDznD9miGISmc0P/Md8fvR//eRv+nUkdqtAn4ixRF1UpieuxnbFYqG0d9d mp6mWDDK+FzmWJRd8kFMLsmzAm4Sq+KAAk/O3ZTPuf0Hk+bM8m6nyCyJDhnmSCdKzIx5/FwaXnR SOBxeNSYVWoeClZ/APZnKMYYDufO1AMoLLr7mT0+/hPDOFGVqdl+eVScxOQ3KeGPENqKD2jQ7m1 nQnntQpKBBofrUHjOAlcpEPQnEAUDViZ+SlHG6VvNySKLEOKIkPhS+oT8jlja53yutPiN1c433p XgwWulHtZSG6nw58VbVhsdRRtGLOLekkaL+2KEl+kd1qs9kc9lSaqccvvKg88iCa4LVb5BoYEo5 3p/j81RmMAbKfVTj83wT+y72dtD2+4S+EV0Wku+0Hh190isTU3xoklqqH7J25geXgYIBf4OcTp+ gymNZGfujvofcBzmDa9dgPivXvh5nQd2JRjQEMESDwv57R5Gzh2ay05VEzlNtjxjNWwC6ZA/yW0 JpVCKOxSURypWX+rSa8fJ0Q/A2UrpfEo4F4F2M= X-Received: by 2002:a5d:5d86:0:b0:487:62d:37d9 with SMTP id ffacd0b85a97d-4871e371d94mr3149169f8f.27.1789712240940; Thu, 17 Sep 2026 23:17:20 -0700 (PDT) Message-ID: <9e6b2d03-7523-4d7a-a523-041c3183dd52@suse.com> Date: Fri, 18 Sep 2026 08:17:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] xen/rcu: rework the RCU logic To: Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini References: <20260904171121.65300-1-roger@xenproject.org> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260904171121.65300-1-roger@xenproject.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------fJq0MczReU3Y2rx94wJ40gC0" X-purgate-ID: tlsNG-33051d/1789712241-7428D4E9-29FB76EB/35/110847 X-purgate-type: clean X-purgate-size: 9403 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------fJq0MczReU3Y2rx94wJ40gC0 Content-Type: multipart/mixed; boundary="------------NU5FmJL239Ur2G2IqaniYlbO"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Roger Pau Monne , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Message-ID: <9e6b2d03-7523-4d7a-a523-041c3183dd52@suse.com> Subject: Re: [PATCH 0/5] xen/rcu: rework the RCU logic References: <20260904171121.65300-1-roger@xenproject.org> In-Reply-To: <20260904171121.65300-1-roger@xenproject.org> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------NU5FmJL239Ur2G2IqaniYlbO Content-Type: multipart/mixed; boundary="------------NMUNF0guQWM0xzN0uLShdZUf" --------------NMUNF0guQWM0xzN0uLShdZUf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDQuMDkuMjYgMTk6MTEsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gSGVsbG8sDQo+ IA0KPiBGb2xsb3dpbmcgc2VyaWVzIGFpbXMgdG8gc29sdmUgdHdvIHByb2JsZW1zIHdlIGhh dmUgb2JzZXJ2ZWQgd2l0aCB0aGUNCj4gUkNVIHN1YnN5c3RlbSwgY29tcGxldGUgZGV0YWls cyBvbiBwYXRjaCA0Lg0KPiANCj4gVGhlIHNlcmllcyBpcyBiYXNpY2FsbHkgYSByZS13cml0 ZSAoYW5kIElNTyBzaW1wbGlmaWNhdGlvbikgb2YgdGhlIFJDVQ0KPiBsb2dpYywgcGF0Y2gg NCBjb250YWluaW5nIG1vc3Qgb2YgdGhlIG5ld2x5IGludHJvZHVjZWQgbG9naWMuDQo+IA0K PiBJdCdzIGJlZW4gKHNsaWdodGx5KSB0ZXN0ZWQgbG9jYWxseSBhbmQgb24gdGhlIHNhZmV0 eSBDSS4gIE1heWJlIEknbQ0KPiBiZWluZyBuYWl2ZSwgYnV0IHRoaXMgbG9va3MgbXVjaCBl YXNpZXIgdG8gcmVhc29uIGFib3V0IGFuZCBtYWludGFpbg0KPiB0aGFuIHRoZSBjdXJyZW50 IGxvZ2ljLg0KPiANCj4gVGhpcyAic2ltcGxpZmljYXRpb24iIGlzIG9ubHkgcG9zc2libGUg YWZ0ZXIgdGhlIGludHJvZHVjdGlvbiBvZg0KPiByY3VfcmVhZF97bG9jayx1bmxvY2t9KCkg aGVscGVycyB0aGF0IGlkZW50aWZ5IFJDVSBjcml0aWNhbCBzZWN0aW9ucy4NCj4gDQo+IFRo YW5rcywgUm9nZXIuDQo+IA0KPiBSb2dlciBQYXUgTW9ubmUgKDUpOg0KPiAgICB4ZW4vcmN1 OiBmaXggdHlwZXMNCj4gICAgeGVuL3JjdTogc29ydCBpbmNsdWRlcw0KPiAgICB4ZW4vcmN1 OiBpbnRyb2R1Y2UgdGhlIGNvbmNlcHQgb2YgUkNVIGVwb2NoDQo+ICAgIHhlbi9yY3U6IHNp bXBsaWZ5IFJDVSBpbXBsZW1lbnRhdGlvbg0KPiAgICB4ZW4vcmN1OiByZW1vdmUgcmN1X25l ZWRzX2NwdSgpDQo+IA0KPiAgIHhlbi9jb21tb24vcmN1cGRhdGUuYyAgICAgIHwgNTAyICsr KysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICB4ZW4vaW5jbHVkZS94 ZW4vcmN1cGRhdGUuaCB8ICA0NSArKy0tDQo+ICAgeGVuL2luY2x1ZGUveGVuL3NjaGVkLmgg ICAgfCAgIDIgKy0NCj4gICAzIGZpbGVzIGNoYW5nZWQsIDE1MyBpbnNlcnRpb25zKCspLCAz OTYgZGVsZXRpb25zKC0pDQo+IA0KDQpJIGhhdmUgbG9va2VkIGF0IHRoZSBzZXJpZXMgd2l0 aCBmb2N1cyBvbiB0aGUgZ2VuZXJhbCBhcHByb2FjaCwgYW5kIEkgYWdyZWUgaXQNCmxvb2tz IGNvcnJlY3QuIEkgd2lsbCBsb29rIGludG8gdGhlIGRpZmZlcmVudCBwYXRjaGVzIGluIG1v cmUgZGV0YWlsIG5leHQuDQoNCg0KSnVlcmdlbg0K --------------NMUNF0guQWM0xzN0uLShdZUf Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------NMUNF0guQWM0xzN0uLShdZUf-- --------------NU5FmJL239Ur2G2IqaniYlbO-- --------------fJq0MczReU3Y2rx94wJ40gC0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqs120FAwAAAAAACgkQsN6d1ii/Ey9V Rwf+LaF3q23Tzhl3iuCOiDnTQGknNmuem6ZrwGMn9YBs+dJWg9m/0QGU6q92e7CfcuNTpnB+JaYs D8ekFclQeI8UnrGZRv2T2rUGnDZcwd8mvtdulQYtJRJf8/ae4Rhr0GHqgv36UozPq6xsHhtKYClP IDY7GNZk89HpslvoAytsH/f0vLhZrx9VbPhDdxIW+UzdydoevvmlzIsZjmbYNv4rabpCUOTd8GDF s3J/kTYtD4iSKbEBHWh4HeeqH2TINAQwYvgoQm4/yNjv6y+knLfMOxvX2oPYgyfMlM+/E/2K3yz8 FRhLvp9FFlT8OcNBluHIYJVK3TfvaTekhnrmzOhJ2Q== =m5l7 -----END PGP SIGNATURE----- --------------fJq0MczReU3Y2rx94wJ40gC0-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 06:18:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 06:18:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424713.1648969 (Exim 4.92) (envelope-from ) id 1x7RvX-0007jA-Mo; Fri, 18 Sep 2026 06:18:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424713.1648969; Fri, 18 Sep 2026 06:18:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7RvX-0007j3-KF; Fri, 18 Sep 2026 06:18:27 +0000 Received: by outflank-mailman (input) for mailman id 1424713; Fri, 18 Sep 2026 06:18:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7RvX-0007iv-1d for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 06:18:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7RvW-004vmg-Ee for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:18:26 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacd7ac-e002-0a2a0a5209dd-0a2a450bbaa2-22 for ; Fri, 18 Sep 2026 08:18:26 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacd7b2-b7e8-0a2a450b0019-4a7de14ca80e-3 for ; Fri, 18 Sep 2026 08:18:26 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843378fb37so130378f8f.3 for ; Thu, 17 Sep 2026 23:18:26 -0700 (PDT) Received: from [10.59.3.202] ([146.0.124.57]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4872008023dsm1453197f8f.29.2026.09.17.23.18.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 23:18:25 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789712306; x=1790317106; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=JDrM1rXJY+2LuSqMSQqcwWYWAtN2395aCP/SrQLth64=; b=bIOXczzMVyMnDelAj1+2l10zgsAh81zSnCKKJ2GbsQB6fO/fct8lw5t9EclLINfhbf 4bVYeh4kWlNYFvmzYUBF7luoiZfrUGQ6WWrHWMCjHRD/6xrhRIXkbbQAdgkIxOCcmgCF YcwkCEwNi2BWM56HBFfcWhHDbCPflRQN9MDJtD5dHC3DnAtWNZF5jE1b//PuSWiWoiTz TbR3bpmTDLM+dI9gSi5gwHzEFvaGKrziHLb0SpaQ09T2OUEzh53h8VwAnOSyeF9IDKGy 6mQi7dRd1byVYbUbXKK+LJyJrfD30qXLjrmIzgacx3tky9k45AaBKkvyGjVFL7iReLY+ BGig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789712306; x=1790317106; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JDrM1rXJY+2LuSqMSQqcwWYWAtN2395aCP/SrQLth64=; b=LrxYdAYvcJ/8fzRcyQV+DETtkOOcqCZlN//HsqMEFoRyCeZ45bao9oUqmaShrUOskb 0j3Rh3BJmJgm6E5ZSijakPDDfmvMrI1QDH7tBFAGQvtK7GKdhIeUXIhIMjn8SiTvzqlu JCfeI38X5aSTxeu7h7dfxI6Yc8gYNTCzw2mzJhwFbDFQoJWP5Z06XONsZW++tO5K6Sli UONoELBD7LkuMB1RJ62AUvodivP92GCeRhRJ2ELLJRILVx6VrtTCkWMBvU3UqGkG/OWw 4iZTaSMfcrCEWPLUdwNrpNT7fZrngSamswqKdR9VgQcXlQzB7TFgYmDhDXOGkj+FvziC PAlQ== X-Gm-Message-State: AFuF++mLJfMJ/rQmbL6SDqr5PtWWOI3c8vn/1huSD/MCdmmK1QqxAaHL zGbYJQFMs94f1VGgOct0cG1wX1d6OOO8DBF0sb5BGsdHoY9P2SvEA5cS5T/4ePwdwJGj7k11UCZ Dm0o= X-Gm-Gg: AYBFou2Lqmf/fJKUXXpV8U6IeK/cLoEEjZx44U3N0Kv0B2yiKRL7bRneWvlczuMoaXY AESIZsIKC6/9cor/Myw1mbGFTKtd54/p3bSMDyLlMlBw8ki1y99PvlrVIcm201bra7XHlYVzO/D 9VjKrC8Ixh6upZtVXm8RlTZFKJxn5VpxyRpi8GUzjWjT+e4XJEiU0pe5ZT+v93QiNNIpSB8IdV4 FHZjbIh+yFeJLNbKJWmJFb0aqOFj1H/kzsF2JlVxXWihfbugR/ZjSeoYkLYVk6FDu0aLEwpnzc3 RRMa44JzySaDaGx7NC/l9uC/kGH2cSn2zGH/vcPc4/OEkezrPr1Xh+uN5n86+mQn4V1XkVLWPtb 7SjxO6oAqpuOJ0CC12wq4xVb4IiWNbVKu+oPYzNVAnD4lG1zTjS0vMZPavauiaHz0UFh9w6Bqxz h4a3IyCc0YoOhz5yfwUyLfjQ2aW/8qNIqbWENe/b1RM53kA+wIFRegI5xlxePpkSiFXJzOV07Tp sw= X-Received: by 2002:a05:6000:2312:b0:486:f6dc:52c8 with SMTP id ffacd0b85a97d-4871e269e92mr1606354f8f.37.1789712305874; Thu, 17 Sep 2026 23:18:25 -0700 (PDT) Message-ID: <35ee5c25-bf5d-4443-aa33-f71c8eefe526@suse.com> Date: Fri, 18 Sep 2026 08:18:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] EFI: avoid OOB config file reads From: Jan Beulich To: George Dunlap , Marek Marczykowski Cc: "xen-devel@lists.xenproject.org" , Daniel Smith , Andrew Cooper References: <64821a66-6726-449e-b1f4-2d8750e99f95@suse.com> Content-Language: en-US In-Reply-To: <64821a66-6726-449e-b1f4-2d8750e99f95@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1789712306-A98C19EA-140384A8/0/0 X-purgate-type: clean X-purgate-size: 1449 On 16.09.2026 17:05, Jan Beulich wrote: > On 16.09.2026 16:37, George Dunlap wrote: >> On Wed, Mar 25, 2026 at 2:24 PM Jan Beulich wrote: >>> @@ -878,6 +882,23 @@ static bool __init read_section(const EF >>> >>> file->ptr = ptr; >>> >>> + /* For cfg file, if necessary allocate space to put an extra NUL there. */ >>> + if ( file == &cfg && file->size && !iscntrl(file->str[file->size - 1]) ) >>> + { >>> + EFI_PHYSICAL_ADDRESS addr; >>> + EFI_STATUS ret = efi_bs->AllocatePages(AllocateMaxAddress, >>> + EfiLoaderData, >>> + PFN_UP(file->size + 1), &addr); >> >> efiapi.h lists the Memory parameter as OUT, but that seems to be a >> mistake; the UEFI spec [1] says this is IN OUT; and the other two >> callers of AllocatePages in Xen initialize the value before passing it >> in. So we should probably fix both efiapi.h, and initialize this to >> an appropriate value, rather than passing in stack rubble. > > Oh, yes, we definitely need to init the variable. I'm less certain about > efiapi.h, though, as that's an imported header. We'd need to check > gnuefi, and import a possible update from there. I guess I'll leave that > part to the maintainers... Actually no. There's no need to use AllocateMaxAddress here, at which point the need to init addr will go away. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 06:30:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 06:30:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424723.1648978 (Exim 4.92) (envelope-from ) id 1x7S6k-0001Fx-MA; Fri, 18 Sep 2026 06:30:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424723.1648978; Fri, 18 Sep 2026 06:30:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7S6k-0001FS-JD; Fri, 18 Sep 2026 06:30:02 +0000 Received: by outflank-mailman (input) for mailman id 1424723; Fri, 18 Sep 2026 06:30:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7S6j-0000yW-57 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 06:30:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7S6h-00DNJk-MR for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:29:59 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacda67-8faa-0a2a0a5109dd-0a2a45029e0a-2 for ; Fri, 18 Sep 2026 08:29:59 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacda67-6ca4-0a2a45020019-c387df83948c-3 for ; Fri, 18 Sep 2026 08:29:59 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id C65DC1FF11; Fri, 18 Sep 2026 06:29:50 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 42055133CF; Fri, 18 Sep 2026 06:29:49 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id QKxyFFzarGoGdAAAD6G6ig (envelope-from ); Fri, 18 Sep 2026 06:29:49 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789712994; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=DUv/bGelfeKfi7NzV8gLKEZcP219T234L/B4tf6rh9c=; b=HU3atgbsr3FvbZV38FFbubSlqBLxPveOsCYWuZD8HxCW05Z8a05VOcs2keLcZv8/FXz0Rm aSPffbbOQ+vpoIF7TzDOKIa65aAqTIfZ4dnYN4v0sRc8SOsO2Ae4LX7oUH3fS2lTdmOGpl /uV6g+0XBhXx3JeWWfkSbuSz8Gg6pSE= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789712990; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=DUv/bGelfeKfi7NzV8gLKEZcP219T234L/B4tf6rh9c=; b=TTzV98uzJ5hcBSFTUFQaonwbci4H3Su75g3jMTwQzGqTvZFNjuTpgL0boJCYpAAkVsYHRU tig2W/JS39Ty75bDBZscZoC4cqQII4zyj6uLS/zWPfhFEeXSo5VZkm8qtVgf012Ops39gM WHlasSW4tdnmh5NXM8uNjb75/JKfWI8= Message-ID: <2e0ef574-8950-4a07-9c8e-05014dce5bd6@suse.com> Date: Fri, 18 Sep 2026 08:29:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Assisted-by tag To: Jan Beulich , Marek Marczykowski Cc: "xen-devel@lists.xenproject.org" , Daniel Smith , Andrew Cooper , George Dunlap References: <284816d0-b7e5-4e5a-8feb-d3ee984c95e2@suse.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <284816d0-b7e5-4e5a-8feb-d3ee984c95e2@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------A8EQat3H0w2wsSUv0JK2eWGX" X-Spam-Score: -5.17 X-Spam-Level: X-Spamd-Result: default: False [-5.17 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-0.97)[-0.973]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_BASE64_TEXT(0.10)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid]; HAS_ATTACHMENT(0.00)[] X-Spam-Flag: NO X-purgate-ID: tlsNG-720697/1789712999-F22A92AC-68BCA2FA/35/110847 X-purgate-type: clean X-purgate-size: 9401 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------A8EQat3H0w2wsSUv0JK2eWGX Content-Type: multipart/mixed; boundary="------------4BH4xqA1JkX07j9xu1ds0zO2"; protected-headers="v1" From: Juergen Gross To: Jan Beulich , Marek Marczykowski Cc: "xen-devel@lists.xenproject.org" , Daniel Smith , Andrew Cooper , George Dunlap Message-ID: <2e0ef574-8950-4a07-9c8e-05014dce5bd6@suse.com> Subject: Re: Assisted-by tag References: <284816d0-b7e5-4e5a-8feb-d3ee984c95e2@suse.com> In-Reply-To: <284816d0-b7e5-4e5a-8feb-d3ee984c95e2@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------4BH4xqA1JkX07j9xu1ds0zO2 Content-Type: multipart/mixed; boundary="------------1lP7QEgZfhrkVYMmdAW5LxIn" --------------1lP7QEgZfhrkVYMmdAW5LxIn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTguMDkuMjYgMDg6MTAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNy4wOS4yMDI2 IDIwOjM2LCBNYXJlayBNYXJjenlrb3dza2kgd3JvdGU6DQo+PiBPbiBXZWQsIFNlcCAxNiwg MjAyNiBhdCAwNDozNzowN1BNICswMjAwLCBHZW9yZ2UgRHVubGFwIHdyb3RlOg0KPj4+IERp c2NvdmVyZWQgYnkgc2FzaGlrbytPcHVzLg0KPj4NCj4+IEhvdyBkb2VzIHRoYXQgaW5mbHVl bmNlIHRhZ3Mgb24gYSBwYXRjaCBmaXhpbmcgdGhlIGlzc3VlPyBTaG91bGQgdGhhdCBiZQ0K Pj4gUmVwb3J0ZWQtYnk6IHNhc2hpa28rT3B1cyA/IE9yIG1heWJlIFJlcG9ydGVkLWJ5OiBH ZW9yZ2UgKyBBc3Npc3RlZC1ieToNCj4+IHNhc2hpa28rT3B1cz8gT3Igc29tZXRoaW5nIGVs c2U/DQo+IA0KPiBJIHdhcyB3b25kZXJpbmcgdGhlIHNhbWUsIGFuZCBteSBwbGFuIHdhcyB0 byB1c2UgdHdvIFJlcG9ydGVkLWJ5OiBoZXJlDQo+IChhcyBJIHdhcyBhc3N1bWluZyBJIHdh cyB0byBtYWtlIGEgcGF0Y2ggaGVyZSwgd2hpY2ggbWF5YmUgbm93IHlvdSdyZQ0KPiBpbnRl bmRpbmcgdG8gZG8pLiBUaGUgYWx0ZXJuYXRpdmUgSSBoYWQgdGhvdWdodCBvZiB3YXMgdG8g aGF2ZSB0aGUNCj4gQXNzaXN0ZWQtYnk6IGFoZWFkIG9mIHRoZSBSZXBvcnRlZC1ieTosIHRo dXMgdHJ5aW5nIHRvIGNsYXJpZnkgKGJ5IHRhZ3MNCj4gYmVpbmcgaW4gY2hyb25vbG9naWNh bCBvcmRlcikgdGhhdCBpdCB3YXMgdGhlIGZpbmRpbmcgb2YgdGhlIGlzc3VlDQo+IHdoZXJl IEFJIGhhZCBoZWxwZWQuIChJbiBwcmluY2lwbGUgYSAybmQgQXNzaXN0ZWQtYnk6IGFmdGVy IHRoZQ0KPiBSZXBvcnRlZC1ieTogY291bGQgdGhlbiBpbmRpY2F0ZSB3aGljaCBbb3RoZXJd IEFJIGhlbHBlZCB3aXRoIG1ha2luZw0KPiB0aGUgcGF0Y2ggaXRzZWxmLikNCj4gDQo+IEph bg0KDQpJIGFncmVlIHRoaXMgaXMgYSBzZW5zaWJsZSB3YXkgdG8gaW5kaWNhdGUgaG93IEFJ IGFzc2lzdGVkIGluIHRoZSB3aG9sZQ0KcHJvY2Vzcy4NCg0KSSdsbCB3cml0ZSBhIHBhdGNo IGZvciBzZW5kaW5nLXBhdGNoZXMucGFuZG9jIGNsYXJpZnlpbmcgdGhhdCBhbnkNCkFzc2lz dGVkLWJ5OiB0YWcgcmVsYXRlcyB0byB0aGUgbmV4dCB0YWcgKFJlcG9ydGVkLWJ5LCBSZXZp ZXdlZC1ieSwNClNpZ25lZC1vZmYtYnkpLg0KDQoNCkp1ZXJnZW4NCg== --------------1lP7QEgZfhrkVYMmdAW5LxIn Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------1lP7QEgZfhrkVYMmdAW5LxIn-- --------------4BH4xqA1JkX07j9xu1ds0zO2-- --------------A8EQat3H0w2wsSUv0JK2eWGX Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqs2lYFAwAAAAAACgkQsN6d1ii/Ey9c aQf/bjv7ep6tyrFZLOcvMHHgIykDSUx3L6AbLYYjQHWWZ82JVoljFjKYjB+h1otfu7QQ8zuL3m8X /dVuGbrCGRvKHj+iAgrBvk/5YoOy59u2HxHMwAWOZpsmhPLN/uu/W2Jb0X34C9POqO5cspKSxI2B yCESDX+MT/+VnpiF2yrg6nLlahn6Ie+8wb1DqdbqKyqKh4cm72JGU7dcSbuC/gtKLJpUIREzbb0L EWz0RVGSagdj1U9lT1diZtV/P9CdP5H9rBNwjBSUEp55zfd+Ky76J03a7fiLFP0sfJKhjfkr0Zdx jpauB2h75M6Ce0q73uKbBqwW15KVh49whox0nriu5Q== =ah9J -----END PGP SIGNATURE----- --------------A8EQat3H0w2wsSUv0JK2eWGX-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 06:37:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 06:37:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424733.1648988 (Exim 4.92) (envelope-from ) id 1x7SE6-0002cu-GW; Fri, 18 Sep 2026 06:37:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424733.1648988; Fri, 18 Sep 2026 06:37:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7SE6-0002cn-Dp; Fri, 18 Sep 2026 06:37:38 +0000 Received: by outflank-mailman (input) for mailman id 1424733; Fri, 18 Sep 2026 06:37:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7SE4-0002cb-RI for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 06:37:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7SE3-00Fm8S-E1 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:37:35 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacdc2c-2eae-0a2a0a5409dd-0a2a450cd3be-18 for ; Fri, 18 Sep 2026 08:37:35 +0200 Received: from [212.23.1.3] (helo=smarthost01b.sbp.mail.zen.net.uk) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacdc2e-f479-0a2a450c0019-d4170103a26c-3 for ; Fri, 18 Sep 2026 08:37:34 +0200 Received: from [217.155.64.189] (helo=mail0.xen.dingwall.me.uk) by smarthost01b.sbp.mail.zen.net.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97) (envelope-from ) id 1x7SE1-0000000APxL-1jF3; Fri, 18 Sep 2026 06:37:33 +0000 Received: from localhost (localhost [IPv6:::1]) by mail0.xen.dingwall.me.uk (Postfix) with ESMTP id B8838F401F0; Fri, 18 Sep 2026 07:37:32 +0100 (BST) Received: from mail0.xen.dingwall.me.uk ([IPv6:::1]) by localhost (mail0.xen.dingwall.me.uk [IPv6:::1]) (amavis, port 10024) with ESMTP id Yl6ZiyD8Q2tD; Fri, 18 Sep 2026 07:37:32 +0100 (BST) Received: from behemoth.dingwall.me.uk (behemoth.dingwall.me.uk [IPv6:2a02:8010:698e:302::c0a8:105]) by dingwall.me.uk (Postfix) with ESMTP id 9C0D1F401ED; Fri, 18 Sep 2026 07:37:32 +0100 (BST) Received: by behemoth.dingwall.me.uk (Postfix, from userid 1000) id 8B7A5123608D; Fri, 18 Sep 2026 07:37:32 +0100 (BST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none X-Virus-Scanned: Debian amavis at dingwall.me.uk Date: Fri, 18 Sep 2026 07:37:32 +0100 From: James Dingwall To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Marek Szyprowski , iommu@lists.linux.dev Subject: Re: BUG kernel 6.12.19 defautl_swiotlb_limit() returns wrong value for CONFIG_SWIOTLB_DYNAMIC=y effects atm only under XEN dom0 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Originating-smarthost01b-IP: [217.155.64.189] Feedback-ID: 217.155.64.189 X-purgate-ID: tlsNG-d25034/1789713455-774D7A5B-7D69B4CC/0/0 X-purgate-type: clean X-purgate-size: 1862 Hi, I've been having a problem with a Dell HBA330 SCSI controller (mpt3sas) when booting under Xen and CONFIG_SWIOTLB_DYNAMIC=y is set. I had a similar issue with a megaraid_sas card that I previously posted about: https://lkml.iu.edu/hypermail/linux/kernel/2407.3/08254.html In that case we rebuilt the kernel with CONFIG_SWIOTLB_DYNAMIC=n. While investigating the current problem I came across a patch that was posted on the xen-devel list: https://lists.xen.org/archives/html/xen-devel/2025-05/msg00991.html I have applied that to the Ubuntu 7.0.0-31 kernel sources which has resolved the controller initialisation error I was encountering and the system now boots as expected. [ 3.921136] mpt3sas_cm0: no suitable DMA mask for 0000:03:00.0 [ 3.921275] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:13610/_scsih_probe()! I've included the patch below, I don't have the author's real address for the s-o-b. I'm able to test alternative fixes if there are any issues with this one. Thanks, James Signed-off-by: Andreas Greve andreas.greve@xxxxxxxxxx Tested-by: James Dingwall diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index abcf3fa63a56..742e6cbbe852 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -1654,7 +1654,16 @@ phys_addr_t default_swiotlb_base(void) phys_addr_t default_swiotlb_limit(void) { #ifdef CONFIG_SWIOTLB_DYNAMIC - return io_tlb_default_mem.phys_limit; + struct io_tlb_mem *mem = &io_tlb_default_mem; + phys_addr_t retval = mem->defpool.end; + struct io_tlb_pool *pool; + rcu_read_lock(); + list_for_each_entry_rcu(pool, &mem->pools, node) { + if (pool->end > retval) + retval = pool->end; + } + rcu_read_unlock(); + return retval - 1; #else return io_tlb_default_mem.defpool.end - 1; #endif From xen-devel-bounces@lists.xenproject.org Fri Sep 18 06:56:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 06:56:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424762.1648996 (Exim 4.92) (envelope-from ) id 1x7SWb-0005Sz-VC; Fri, 18 Sep 2026 06:56:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424762.1648996; Fri, 18 Sep 2026 06:56:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7SWb-0005Ss-Sa; Fri, 18 Sep 2026 06:56:45 +0000 Received: by outflank-mailman (input) for mailman id 1424762; Fri, 18 Sep 2026 06:56:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7SWa-0005Sm-H0 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 06:56:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7SWZ-00AG2O-Tq for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:56:43 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aace09d-bab6-0a2a0a5309dd-0a2a450291f2-22 for ; Fri, 18 Sep 2026 08:56:43 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aace0ab-6ca4-0a2a45020019-c387df82a7be-3 for ; Fri, 18 Sep 2026 08:56:43 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 02E5D21E78; Fri, 18 Sep 2026 06:56:35 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2D9E51348F; Fri, 18 Sep 2026 06:56:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id EyvkMqHgrGqcEQAAD6G6ig (envelope-from ); Fri, 18 Sep 2026 06:56:34 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789714599; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=T2G8aHyZhUHK33UoAphpOtfRTTVsDciZ3TZlcHGDoqo=; b=UNBpeC2281a50lULujwRgY+sQUZZo33KGEI5I+lBOWgWAuNiwH0Ti3qGBBeZS5IckDXNj4 UdxpbX5uzSdSrp4Mf0JKkiDWJylNPpsneksbQujX3+xb5UBkAz0yS3K7UO9o+2HuEl4/CY mzqvAtBBc5K3TinRy4rUaEY6AAsOPmQ= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789714595; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=T2G8aHyZhUHK33UoAphpOtfRTTVsDciZ3TZlcHGDoqo=; b=irl+mKQgt92K8KHNaGhoI4PVeyaO98ctYNWHY5twG9OZs9Z/HCL8AEkzSMADN+TkbB1cE8 ax3iXLoyE5csgnRQNcCQ2mbWeBY/M3RmmqpQZF/32PWMtIMa1ToSiBuSakNKSPFI3+Lv7r isrRooQgFMOx1s15GHxlM5HyUbEUUYs= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] docs: clarify tag sequence in sending-patches Date: Fri, 18 Sep 2026 08:56:14 +0200 Message-ID: <20260918065614.11003-1-jgross@suse.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Level: X-Spam-Score: -2.80 X-Spam-Flag: NO X-Spamd-Result: default: False [-2.80 / 50.00]; BAYES_HAM(-3.00)[99.99%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.997]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_SEVEN(0.00)[9]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:helo]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-purgate-ID: tlsNG-720697/1789714603-F26B72AC-0482FB44/35/110847 X-purgate-type: clean X-purgate-size: 1667 Make clear what an "Assisted-by: tag tag relates to in sending-patches.pandoc. Add the possibility to clarify how AI was used. Signed-off-by: Juergen Gross --- docs/process/sending-patches.pandoc | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/docs/process/sending-patches.pandoc b/docs/process/sending-patches.pandoc index b924fa2b87..2506a686bb 100644 --- a/docs/process/sending-patches.pandoc +++ b/docs/process/sending-patches.pandoc @@ -213,9 +213,25 @@ Basic development tools (git, gcc, make, editors) should not be listed. Specialised but deterministic tools may optionally be listed, but their use should be clear from other context in the commit message. +Note that an `Assisted-by:` tag relates to the next tag mentioning a +natural person. So if you used AI to write a patch, the `Assisted-by:` tag +should be just before your `Signed-off-by:` tag, while if AI was used to +find an issue the patch is fixing, the `Assisted-by:` tag should be +before the `Reported-by:` tag naming the reporter of the issue. + +The `Assisted-by:` tag can be followed by an optional comment mentioning +in which part of the process AI was used, e.g.: + + Assisted-by: Chat-GPT # commit message + +This allows even to list multiple different AI models used for different +use cases, including the use of AI for finding an issue and the creating +a patch for fixing it. + Example: - Assisted-by: Claude:claude-3-opus + Assisted-by: sashiko-bot # finding the issue + Assisted-by: Claude:claude-3-opus # patch creation ### Signed-off-by: -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 07:41:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 07:41:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424791.1649007 (Exim 4.92) (envelope-from ) id 1x7TE4-0003N4-5K; Fri, 18 Sep 2026 07:41:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424791.1649007; Fri, 18 Sep 2026 07:41:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TE4-0003Mx-1h; Fri, 18 Sep 2026 07:41:40 +0000 Received: by outflank-mailman (input) for mailman id 1424791; Fri, 18 Sep 2026 07:41:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TE3-0003Mr-3c for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 07:41:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TE2-00Fw4D-2S for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:41:38 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaceb29-2eae-0a2a0a5409dd-0a2a4509abf2-38 for ; Fri, 18 Sep 2026 09:41:37 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaceb31-be1a-0a2a45090019-c387df83e9b4-3 for ; Fri, 18 Sep 2026 09:41:37 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4779120085; Fri, 18 Sep 2026 07:41:29 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A4C1B133CF; Fri, 18 Sep 2026 07:41:27 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id iKz4CCfrrGoIQgAAD6G6ig (envelope-from ); Fri, 18 Sep 2026 07:41:27 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789717293; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ymdhaB3oXsE4hyZBgWSC41BaSOZAmXTKcum/Sn4Edq0=; b=NPyAVMkGm2QDWio/oeOI8JmQ26oUqj0gmxN8tJ0uAd6EfFJEt4uO0gUZ7oAnz2XLVZ0595 kC4kyDoQ7FlUezHlNmzopKEtF1fJXKJVWpwh4bWPSBXTxm1yvalcreWDmDOrixDhAJbXnD hGP3Z9Ec5sxTc/QtwaZkD7IIQEW4yPg= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=iEMYQ9cN DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1789717289; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ymdhaB3oXsE4hyZBgWSC41BaSOZAmXTKcum/Sn4Edq0=; b=iEMYQ9cNvuZ4BkzWH8MXAvmKaHNwtIeRoIsjT5NAPsOyR7nskYf8chdqi5RNTk+L5D7/MD HcJprrSSyu47dme+WSzpMvSQjhi0gla7Hu+lKcEQflG/0ziGg07cYzWNkUa736swf9w73m /ENxmkiQ5qfHZHB9aVS1IGqOMzuKDAU= Message-ID: <81193b2a-9ac5-48c2-ba27-71cb5aae62da@suse.com> Date: Fri, 18 Sep 2026 09:41:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in sched_move_domain() To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com, gwd@xenproject.org References: <20260819051532.9197-1-frn1furkan10@gmail.com> <20260819051532.9197-2-frn1furkan10@gmail.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260819051532.9197-2-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FIZstQ8A5CH0LYBBp0tZuTHT" X-Spam-Score: -5.41 X-Rspamd-Queue-Id: 4779120085 X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Level: X-Rspamd-Action: no action X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MX_GOOD(-0.01)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ATTACHMENT(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:email,suse.com:mid] X-Spam-Flag: NO X-purgate-ID: tlsNG-bad1c0/1789717297-BD2CC034-7F5BCAC6/35/110847 X-purgate-type: clean X-purgate-size: 9819 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FIZstQ8A5CH0LYBBp0tZuTHT Content-Type: multipart/mixed; boundary="------------e5iK8ZJKZag4v0fRehD2sR2g"; protected-headers="v1" From: Juergen Gross To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, dfaggioli@suse.com, gwd@xenproject.org Message-ID: <81193b2a-9ac5-48c2-ba27-71cb5aae62da@suse.com> Subject: Re: [PATCH v2 1/2] xen/sched: core: skip missing vcpu slots in sched_move_domain() References: <20260819051532.9197-1-frn1furkan10@gmail.com> <20260819051532.9197-2-frn1furkan10@gmail.com> In-Reply-To: <20260819051532.9197-2-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------e5iK8ZJKZag4v0fRehD2sR2g Content-Type: multipart/mixed; boundary="------------WRuO24dDrei0AXL0G40Ht8JH" --------------WRuO24dDrei0AXL0G40Ht8JH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTkuMDguMjYgMDc6MTUsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gc2NoZWRfbW92 ZV9kb21haW4oKSBkZXJpdmVzIHRoZSBudW1iZXIgb2YgdW5pdHMgdG8gcmVidWlsZCBmcm9t DQo+IGQtPm1heF92Y3B1cywgd2hpY2ggaXMgZml4ZWQgYXQgZG9tYWluIGNyZWF0aW9uIGFu ZCBuZXZlciByb2xsZWQNCj4gYmFjayBpZiB2Y3B1X2NyZWF0ZSgpIGZhaWxzIHBhcnR3YXkg dGhyb3VnaCBidWlsZGluZyBhIGRvbWFpbi4gU28NCj4gZC0+dmNwdVtpXSBjYW4gYmUgTlVM TCBmb3Igc29tZSBpIGV2ZW4gdGhvdWdoIG1heF92Y3B1cyBzdGlsbA0KPiBjb3VudHMgaXQg LSB0aGlzIGhhcHBlbnMgaWYgc2NoZWRfYWxsb2NfdWRhdGEoKSByZXR1cm5zIE5VTEwuDQo+ IA0KPiBUaGUgcGVyLXVuaXQgbG9vcCBkb2Vzbid0IGNoZWNrIGZvciB0aGlzOiBpdCBzZXRz DQo+IHVuaXQtPnZjcHVfbGlzdCA9IGQtPnZjcHVbdW5pdF9pZF0gKE5VTEwpIGFuZCBoYW5k cyB0aGF0IGJyb2tlbg0KPiB1bml0IHN0cmFpZ2h0IHRvIHRoZSBkZXN0aW5hdGlvbiBzY2hl ZHVsZXIncyBhbGxvY191ZGF0YSgpLA0KPiB3aGljaCBhc3N1bWVzIHZjcHVfbGlzdCBpcyBh bHdheXMgdmFsaWQgYW5kIGNyYXNoZXMgWGVuIHdoZW4NCj4gaXQgaXMgbm90Lg0KPiANCj4g UmVwcm9kdWNlZCBieSBidWlsZGluZyBhIGRvbWFpbiBpbiBhIG5vbi1kZWZhdWx0IGNwdXBv b2wgd2hlcmUNCj4gdmNwdSBjcmVhdGlvbiBmYWlscyBwYXJ0d2F5IHRocm91Z2gsIHRoZW4g ZGVzdHJveWluZyBpdC4NCj4gZG9tYWluX2tpbGwoKSBtb3ZlcyB0aGUgZG9tYWluIGJhY2sg dG8gdGhlIGRlZmF1bHQgY3B1cG9vbCB2aWENCj4gc2NoZWRfbW92ZV9kb21haW4oKSBiZWZv cmUgYWN0dWFsbHkgZGVzdHJveWluZyBpdCwgY3Jhc2hpbmcNCj4gaW5zaWRlIHRoZSBkZXN0 aW5hdGlvbiBzY2hlZHVsZXIncyBhbGxvY191ZGF0YSgpIChzZWVuIGluDQo+IENyZWRpdDIn cyBjc2NoZWQyX2FsbG9jX3VkYXRhKCkgLT4gaXNfaWRsZV91bml0KCkgLT4gTlVMTCBkZXJl ZikuDQo+IA0KPiBCZWZvcmUgYnVpbGRpbmcgYSB1bml0IGluIHNjaGVkX21vdmVfZG9tYWlu KCksIGNoZWNrIHdoZXRoZXIgYWxsDQo+IHZwY3Ugc2xvdHMgYmVsb25naW5nIHRvIHRoYXQg dW5pdCBhcmUgcG9wdWxhdGVkLiBJZiBhbnkgb2YgaXRzDQo+IHZwY3VzIGlzIG1pc3Npbmc6 DQo+ICAgLSBGb3IgYSBkeWluZyBkb21haW4sIHNraXAgdGhlIHVuaXQgYWxsb2NhdGlvbi4N Cj4gICAtIEZvciBhbiBhY3RpdmUgZG9tYWluLCBhYm9ydCB0aGUgbW92ZSBhbmQgcmV0dXJu IC1FSU5WQUwgdG8NCj4gICAgIHByZXZlbnQgcnVubmluZyB3aXRoIGRyb3BwZWQgdkNQVXMu DQo+IA0KPiBGaXhlczogNzBmYWRjNDE2MzViICgieGVuL2NwdXBvb2w6IHN1cHBvcnQgbW92 aW5nIGRvbWFpbiBiZXR3ZWVuIGNwdXBvb2xzIHdpdGggZGlmZmVyZW50IGdyYW51bGFyaXR5 IikNCj4gU2lnbmVkLW9mZi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21h aWwuY29tPg0KDQpXaXRoIHRoZSBWMyBhcHByb2FjaCBub3QgYmVpbmcgZWFzaWx5IGRvYWJs ZToNCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0K DQpKdWVyZ2VuDQo= --------------WRuO24dDrei0AXL0G40Ht8JH Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------WRuO24dDrei0AXL0G40Ht8JH-- --------------e5iK8ZJKZag4v0fRehD2sR2g-- --------------FIZstQ8A5CH0LYBBp0tZuTHT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqs6yIFAwAAAAAACgkQsN6d1ii/Ey9g 4Af/dPZjcPyqebswRykeH8eobrpr67ekP0DXnafMCLgdQomDOQaNG8DFBDhQMP7B4dsjEVMV7Z+B gnJFLiupIGFPo89aGfwYug/a1jjHTJwUwG3cA38HTtO3E6BawbrLIlISULTPPrUcZ8K4uYAUWsmQ FYh9FJnGjpqRtqUBnZzfXCUTdyrQUh1BJROTqKFTtT8aew4FrsG3n67XmwR+kGY5uqPJMFEd6HFf 1GeWvZ2kHHpuifQvENvaRHtNygJP/IUjX+RkySvb7ucn+A2lKg1XpAoRNEGHZTUdKhxpOOhZhN5u yJLBPvCrHSYrl1HdFx0yviA8MYJJdsNkk2VkNr2umQ== =wfGk -----END PGP SIGNATURE----- --------------FIZstQ8A5CH0LYBBp0tZuTHT-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 07:45:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 07:45:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424798.1649016 (Exim 4.92) (envelope-from ) id 1x7THJ-0003rs-IR; Fri, 18 Sep 2026 07:45:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424798.1649016; Fri, 18 Sep 2026 07:45:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7THJ-0003rl-Eq; Fri, 18 Sep 2026 07:45:01 +0000 Received: by outflank-mailman (input) for mailman id 1424798; Fri, 18 Sep 2026 07:45:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7THI-0003rf-4F for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 07:45:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7THH-00FwfA-Dy for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:44:59 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacebfb-8faa-0a2a0a5109dd-0a2a4508d896-0 for ; Fri, 18 Sep 2026 09:44:59 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacebfb-f659-0a2a45080019-4a7de18ca804-3 for ; Fri, 18 Sep 2026 09:44:59 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d8239so3070815e9.0 for ; Fri, 18 Sep 2026 00:44:59 -0700 (PDT) Received: from [172.20.2.169] ([87.190.33.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fc7d8cee0sm28936475e9.15.2026.09.18.00.44.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 00:44:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789717499; x=1790322299; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=Y2RlL6M6yuns/eV6zZ3NgaxHrjObOqzIRFqXVj8kzP0=; b=ZXyfbaoZnGCt5kI16P6EJR27NYbUgkYgmRs5DTWhAQuMc9cet5AjudQ3zq6W7PrWwd eSTwwsAt004HVjBKEbJeeNXki6wjkHOaIXt2i76PmgiaFcxWTZ7/SHJwTtgFWgxqiuyS xoEzjah37xmN96+C8yxcs8U+VP6j0FfSr0hqnUEDefDeC3Wf/gzItZk+JhtJ/DSyqix0 eX1t7qgB2gpK1dhHXSeyjA7jAFl8HhUrua9JW5CCxLuluhx3VZDTXkvyeZZT8OyoLTp/ S3zpZC3nheWW5nhyTU50GfC+gAJOkbolFNdY0/HgZnJeK2a2kfOZABKuRQhaAH4nxFEM iDKw== X-Forwarded-Encrypted: i=1; AKwUvBwIhgovgyREb/pkmvImaVQ20xCQ0hAoaUuyM5KlkLtpm8T5OtMHtCXcpmazt6xF5qUhPVrfbGhizkE=@lists.xenproject.org X-Gm-Message-State: AFuF++kun24SwffmG9fC97GMWv+S/ayIRk8xP/jcLjV0knz6MUR3ahiF x2LuOVC062C+pYDS+O11RkB/IQNdgcga7NTp5KfV842KFqLZUmo1onl1 X-Gm-Gg: AYBFou2xJudWBDfVJVAY3YSxOj7UwzImOTeP6mnAdjL3Z5ZSfXtyEMhGQa958/P6zKW +xUVHuvb+2vTGj6/GizAi2wJKd1hwn5XQfSyrNsV31acJpQkXSztJ9RK1Vu5iQquUiWrTtCzQI0 ZvmJQQoSBj31aIbn1YxpHaXeUSEs6R04NvYR3K5UDaxecXdfZwVmpcVvD7121knhafk/dz/kg8J +nFA7OtB1I2bVR3rLy6iMAAPRe2azdg5pKYKbQiDgFfBPPFlHlXVCo5jxKaX+INldFL9yNTQp10 +FlXVWMtfRRJOEbbpZOgajBZXz+3UggYPAH/SoupJnH8QR1Asfq4Mcf/RwIdXtlI2bTOGH3VZyT tWFjXgo/5hv4GOPF+Gyud6TYHOrP7mR7wv4Pw7qjkTHCo6cdotyaTFB74kpjhJwjLEldSU2hvA2 kLaPNJNW+NIzkLHZY0sXdezGSMUPIZwpPmDS4icozjz6zUi1846a8PrPxOYNi7xbFmMRdjQZ4j3 HtuUuXl X-Received: by 2002:a05:600c:3104:b0:49e:7c83:4733 with SMTP id 5b1f17b1804b1-49fc5749bbdmr18162585e9.32.1789717498125; Fri, 18 Sep 2026 00:44:58 -0700 (PDT) Message-ID: Date: Fri, 18 Sep 2026 09:44:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs: clarify tag sequence in sending-patches To: Juergen Gross , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <20260918065614.11003-1-jgross@suse.com> Content-Language: en-GB From: "Grall, Julien" In-Reply-To: <20260918065614.11003-1-jgross@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789717499-CC77387B-5B1FFB79/0/0 X-purgate-type: clean X-purgate-size: 329 Hi Juergen, On 18/09/2026 08:56, Juergen Gross wrote: > Make clear what an "Assisted-by: tag tag relates to in > sending-patches.pandoc. > > Add the possibility to clarify how AI was used. > > Signed-off-by: Juergen Gross Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Sep 18 07:47:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 07:47:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424807.1649024 (Exim 4.92) (envelope-from ) id 1x7TJQ-0004R3-Vm; Fri, 18 Sep 2026 07:47:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424807.1649024; Fri, 18 Sep 2026 07:47:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TJQ-0004Qw-T2; Fri, 18 Sep 2026 07:47:12 +0000 Received: by outflank-mailman (input) for mailman id 1424807; Fri, 18 Sep 2026 07:47:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TJP-0004Qa-HL for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 07:47:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TJN-00G0Kc-NG for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:47:09 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacec70-e002-0a2a0a5209dd-0a2a45029a0e-42 for ; Fri, 18 Sep 2026 09:47:09 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacec7c-6ca4-0a2a45020019-4a7de18ca9c2-3 for ; Fri, 18 Sep 2026 09:47:08 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccff31419so3549445e9.3 for ; Fri, 18 Sep 2026 00:47:08 -0700 (PDT) Received: from [172.18.88.57] (195-200-20-130.mclarenap.oninferno.net. [195.200.20.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fc7ceb92asm32081995e9.6.2026.09.18.00.47.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 00:47:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789717627; x=1790322427; darn=lists.xenproject.org; h=content-type: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:content-type; bh=qlBffCAVKG+keMuYn7lVKUDo3cAsqTTy6FKRP74v+Uc=; b=RNOVyffOc6T9WiMDvMMQib5I4z+vo2uKA8mpm0ELfhcEmITUQZMe7Eae8zGvvwUaD7 z8e4NhahdmlzzSRagMa6Uwa7rvSiLL/FSK8MKrhMNe5+FXU4+kCB0OPYvYDjr1xpyFQU 4t/AU/flNu0bD4wtAhGnNPFtuT7QB9Kx8dZgyjYJv7GvVEv5/BhkiD24njEqfedAfdgt Hkcx3/1IRKylVydFaEy9h/4Xbd1quWRbR7xkVcEhOjfJSWti38EnY0f2f4cPP++y3PRZ Noyt4JMugQDkp0BVRZZ07vICX0bC1Dog3Fe22BmneouvLMMxR04RlR/H+DJUEpeS5Epd 4zbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789717627; x=1790322427; h=content-type: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 :content-type; bh=qlBffCAVKG+keMuYn7lVKUDo3cAsqTTy6FKRP74v+Uc=; b=H5HLOpLze8hu/9y0HHzGpQ/hP52Lo1j9zziPcuaKsT7dRliUi97SlJLWaH/KlAc8xJ uLGtvNMAP4wv2RG1sx0x2yaWhKEQpCKJ676aanrNEOPE+kpWJK7r1U+o7bTrsAbNxjNn oyoR00AFrgR09mktC+AuYMjNkMbNxsZSJCmkM9mIMqyuC515jLN2v+Ab26pP1XLelDkN JUAriS8S9YMgDlI3tme5SkTmZnbkEd4jXGqL+6ZVCszo62PpaPoBPJNDlYpyv0k75jnx 9rwtSe6OpzQ9RnPkxBrRz0jpYrsjoCf6ZkCIz2DIbRIFQ8bk2pLqc0n3ztjEKHZyg9l6 R68g== X-Forwarded-Encrypted: i=1; AKwUvBzKaKxgQz/lMnCZ+qOtrhkBnDIc0LDubIVFK21IHn+GmvzY/qYctbkrPUnBdiS/w4C73+p1eAUJMOE=@lists.xenproject.org X-Gm-Message-State: AFuF++klap4NIA+lDrHMmxviWMqoMu6zt6a8JrvaSZYTvYOnyKB7158r gn8cu4X8bBF8vPF+R9OwBBj3nNLucqj+4+3St9gqhpPj8qpXjijEXNxfH2DxW4IKlxQ= X-Gm-Gg: AYBFou2x6Isx/Tl82QMSCD/NMvOFOUh8f/U+ufcREmYvuClIJyX2rTOIuKGlAX45EZb yqIgOHeMSlLC9EmGa5bnPXL2GBzoy3/6sFT3Q7MNnuu1fGPpye0SPEQrF7sKTGbA/C+YIwRyfhe +4T4CytxoHC8ZZH5Csxlp7MseDAFoGudNBWCxEcwwpfIvqbzrWx66X1o0ggPGnbYWVnEjYJfIky bTcdYdjRNwZrerp/ceivW4XyHTyzg776w9d7BW2L6hZTHhiUbt/Iv2BgGysFpX70rhkwG5N2tl2 7VQfQRtp+7pHLdXuRIO6WnMlYotISa08yzEp76ueuKtL2xN6NnMf6Po18XB23Z5oksR+XaGBrTZ peQUnXO4nykazbxNJZZf5Uo/4BY3qdaJ1h/xKfVIXKvKyzBoX3rlOP/ijsOvZualDZE8YRqSU6T 88jNoqeoh6QGPHsvXRBR5xCaC5N9d2Umt6fsDxsqptjTi7UKO6luMioIrV8eJhpVvH/MbMky8I0 iC7OUWipJq2qiNA91fH+HYnc6Qe2oWEvTI7gII= X-Received: by 2002:a05:600c:3512:b0:49c:e1cd:536 with SMTP id 5b1f17b1804b1-49fc56aee64mr17835935e9.12.1789717627523; Fri, 18 Sep 2026 00:47:07 -0700 (PDT) Message-ID: <502268de-9e38-425b-bbc5-6202ed981398@suse.com> Date: Fri, 18 Sep 2026 09:46:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-3-frn1furkan10@gmail.com> <0899d0b5-431a-450d-9aec-796f73f92a83@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <0899d0b5-431a-450d-9aec-796f73f92a83@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------QN3QB5THt2LtBSjw2TUYcOhI" X-purgate-ID: tlsNG-720697/1789717628-668B42AC-3ACAC121/35/110847 X-purgate-type: clean X-purgate-size: 11914 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------QN3QB5THt2LtBSjw2TUYcOhI Content-Type: multipart/mixed; boundary="------------tBXNJeeDFfkE0os3pybH0RNc"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com Message-ID: <502268de-9e38-425b-bbc5-6202ed981398@suse.com> Subject: Re: [PATCH 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-3-frn1furkan10@gmail.com> <0899d0b5-431a-450d-9aec-796f73f92a83@gmail.com> In-Reply-To: <0899d0b5-431a-450d-9aec-796f73f92a83@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------tBXNJeeDFfkE0os3pybH0RNc Content-Type: multipart/mixed; boundary="------------RT3b0kFl1ayTUZPnQRNCa8rz" --------------RT3b0kFl1ayTUZPnQRNCa8rz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQuMDkuMjYgMTI6NDAsIEZ1cmthbiDDh2FsxLHFn2thbiB3cm90ZToNCj4gDQo+IE9u IDkvMTQvMjYgMTI6MTYsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+PiBPbiAyNi4wOC4yNiAw Njo1NywgRnVya2FuIENhbGlza2FuIHdyb3RlOg0KPj4+IE5vdyB0aGF0IHdlIGhhdmUgaW50 cm9kdWNlZCBhZG1pc3Npb24gY29udHJvbCBmb3IgbmV3IGFuZA0KPj4+IHJlbW92ZWQgdW5p dHMuIEV4dGVuZCBpdCB0byBYRU5fRE9NQ1RMX1NDSEVET1BfcHV0aW5mbyBhbmQNCj4+PiBw dXR2Y3B1aW5mbywgc28gZ3Jvd2luZyBhbiBleGlzdGluZyByZXNlcnZhdGlvbiB2aWENCj4+ PiB4bCBzY2hlZC1ydGRzIGlzIGNoZWNrZWQgdG9vLg0KPj4+DQo+Pj4gcHV0aW5mbyBzZXRz IHRoZSBzYW1lIChwZXJpb2QsIGJ1ZGdldCkgZm9yIGV2ZXJ5IHVuaXQgb2YgYQ0KPj4+IGRv bWFpbiBhdCBvbmNlLCBzbyBpdCB0ZXN0cyB0aGUgd2hvbGUgZG9tYWluJ3MgdXRpbGl6YXRp b24NCj4+PiBkZWx0YSBhdG9taWNhbGx5LCByYXRoZXIgdGhhbiB1bml0LWJ5LXVuaXQsIHdo aWNoIGNvdWxkDQo+Pj4gc3B1cmlvdXNseSByZWplY3QgYW4gb3ZlcmFsbC1hY2NlcHRhYmxl IGNoYW5nZSBkZXBlbmRpbmcgb24NCj4+PiBpdGVyYXRpb24gb3JkZXIuDQo+Pj4NCj4+PiBw dXR2Y3B1aW5mbyBjaGFuZ2VzIG9uZSB1bml0IGF0IGEgdGltZSwgc28gaXQganVzdCBjYWxs cw0KPj4+IHJ0X2FkbWlzc2lvbl90ZXN0KCkgZGlyZWN0bHkuDQo+Pj4NCj4+PiBTaWduZWQt b2ZmLWJ5OiBGdXJrYW4gQ2FsaXNrYW4gPGZybjFmdXJrYW4xMEBnbWFpbC5jb20+DQo+Pj4g LS0tDQo+Pj4gIMKgIHhlbi9jb21tb24vc2NoZWQvcnQuYyB8IDQyICsrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPj4+ICDCoCAxIGZpbGUgY2hhbmdlZCwg NDIgaW5zZXJ0aW9ucygrKQ0KPj4+DQo+Pj4gZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2No ZWQvcnQuYyBiL3hlbi9jb21tb24vc2NoZWQvcnQuYw0KPj4+IGluZGV4IDkxMjYzMjA4MDEu Ljk2NDNhMjc3ZmUgMTAwNjQ0DQo+Pj4gLS0tIGEveGVuL2NvbW1vbi9zY2hlZC9ydC5jDQo+ Pj4gKysrIGIveGVuL2NvbW1vbi9zY2hlZC9ydC5jDQo+Pj4gQEAgLTE1MjcsMTEgKzE1Mjcs NDMgQEAgcnRfZG9tX2NudGwoDQo+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoCBvcC0+dS5ydGRz LmJ1ZGdldCA9IFJURFNfREVGQVVMVF9CVURHRVQgLyBNSUNST1NFQ1MoMSk7DQo+Pj4gIMKg wqDCoMKgwqDCoMKgwqDCoCBicmVhazsNCj4+PiAgwqDCoMKgwqDCoCBjYXNlIFhFTl9ET01D VExfU0NIRURPUF9wdXRpbmZvOg0KPj4+ICvCoMKgwqAgew0KPj4+ICvCoMKgwqDCoMKgwqDC oCB1aW50NjRfdCBkb21fb2xkX3V0aWwgPSAwLCBuZXdfdXRpbCwgbmV3X3RvdGFsOw0KPj4+ ICvCoMKgwqDCoMKgwqDCoCB1bnNpZ25lZCBpbnQgbnJfdW5pdHMgPSAwOw0KPj4+ICsNCj4+ PiAgwqDCoMKgwqDCoMKgwqDCoMKgIHJjID0gcnRfdmFsaWRhdGVfcGFyYW1zKCZvcC0+dS5y dGRzLCAmcGVyaW9kLCAmYnVkZ2V0KTsNCj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgIGlmICgg cmMgKQ0KPj4+ICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBicmVhazsNCj4+PiAgwqAg K8KgwqDCoMKgwqDCoMKgIG5ld191dGlsID0gcnRfdW5pdF91dGlsaXphdGlvbihwZXJpb2Qs IGJ1ZGdldCk7DQo+Pj4gKw0KPj4+ICDCoMKgwqDCoMKgwqDCoMKgwqAgc3Bpbl9sb2NrX2ly cXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KPj4+ICsNCj4+PiArwqDCoMKgwqDCoMKgwqAg LyoNCj4+PiArwqDCoMKgwqDCoMKgwqDCoCAqIFNhbWUgKHBlcmlvZCwgYnVkZ2V0KSBmb3Ig ZXZlcnkgdW5pdCBvZiBkOiB0ZXN0IGFuZCBjb21taXQNCj4+PiArwqDCoMKgwqDCoMKgwqDC oCAqIHRoZSBkb21haW4ncyB3aG9sZSB1dGlsaXphdGlvbiBkZWx0YSBhdG9taWNhbGx5LCBy YXRoZXINCj4+PiArwqDCoMKgwqDCoMKgwqDCoCAqIHRoYW4gdW5pdC1ieS11bml0LCB3aGlj aCBjb3VsZCBzcHVyaW91c2x5IHJlamVjdCBhbg0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgICog b3ZlcmFsbC1hY2NlcHRhYmxlIGNoYW5nZSBkZXBlbmRpbmcgb24gaXRlcmF0aW9uIG9yZGVy Lg0KPj4+ICvCoMKgwqDCoMKgwqDCoMKgICovDQo+Pj4gK8KgwqDCoMKgwqDCoMKgIGZvcl9l YWNoX3NjaGVkX3VuaXQgKCBkLCB1bml0ICkNCj4+PiArwqDCoMKgwqDCoMKgwqAgew0KPj4+ ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHN2YyA9IHJ0X3VuaXQodW5pdCk7DQo+Pj4gK8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqAgZG9tX29sZF91dGlsICs9IHJ0X3VuaXRfdXRpbGl6YXRp b24oc3ZjLT5wZXJpb2QsIHN2Yy0+YnVkZ2V0KTsNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBucl91bml0cysrOw0KPj4+ICvCoMKgwqDCoMKgwqDCoCB9DQo+Pj4gKw0KPj4+ICvC oMKgwqDCoMKgwqDCoCBuZXdfdG90YWwgPSBwcnYtPnV0aWxpemF0aW9uIC0gZG9tX29sZF91 dGlsICsNCj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKHVp bnQ2NF90KW5yX3VuaXRzICogbmV3X3V0aWw7DQo+Pj4gKw0KPj4+ICvCoMKgwqDCoMKgwqDC oCBpZiAoIG5ld190b3RhbCA+IHBydi0+dXRpbGl6YXRpb24gJiYgbmV3X3RvdGFsID4gcnRf dXRpbGl6YXRpb25fY2FwKGQpICkNCj4+PiArwqDCoMKgwqDCoMKgwqAgew0KPj4+ICvCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIHJjID0gLUVJTlZBTDsNCj4+DQo+PiBJcyBFSU5WQUwgYSBn b29kIGNob2ljZSBoZXJlPyBJIHRoaW5rIGEgZGlmZmVyZW50IGVycm9yIGNvZGUgbWlnaHQg YmUgd2FudGVkLg0KPiANCj4gV291bGQgRUJVU1kgYmUgb2theSBoZXJlPyBPciB3aGF0IGVs c2Ugd291bGQgeW91IHN1Z2dlc3Q/DQoNCkVCVVNZIGlzIGEgbGlpdGxlIGJpdCBiZXR0ZXIu IFdoYXQgZG8geW91IHRoaW5rIGFib3V0IEVOT1NQQz8NCg0KDQpKdWVyZ2VuDQo= --------------RT3b0kFl1ayTUZPnQRNCa8rz Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------RT3b0kFl1ayTUZPnQRNCa8rz-- --------------tBXNJeeDFfkE0os3pybH0RNc-- --------------QN3QB5THt2LtBSjw2TUYcOhI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqs7G8FAwAAAAAACgkQsN6d1ii/Ey/3 jAf/ZWggMGchX5YBGOrPVJaIAYqG3UAeIeDrm0cXASBy5sjVgWPjqKc8R+Yvh0e8/43wkJgFL1HN BzK6Sk937YFNbF4sEFtFIet9JSu7PGuWN/ajoozxMvWouGECDfDMPZx6PAwV4xM3Y0xGNDXui2WF thN1wJgClQLrl4kYQRABgoVPiNdNAY8KakSu576hxDooahBWX2Zy86RBqpS7JtQ3s9R09RMBuIbD Gp86/1fR+Bgnjf7tgUDHzam5D7iHtlIezo+0BzmzJUTnOLutFJXFFRpuy0Mpp/wTC8c+9Gvm9cHR G3Wl56R0gB5TWdZFt94tdg4Zc7UME+2nXPkH+vE5rg== =kunD -----END PGP SIGNATURE----- --------------QN3QB5THt2LtBSjw2TUYcOhI-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 07:48:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 07:48:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424815.1649033 (Exim 4.92) (envelope-from ) id 1x7TL4-0004yl-9i; Fri, 18 Sep 2026 07:48:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424815.1649033; Fri, 18 Sep 2026 07:48:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TL4-0004ye-71; Fri, 18 Sep 2026 07:48:54 +0000 Received: by outflank-mailman (input) for mailman id 1424815; Fri, 18 Sep 2026 07:48:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TL1-0004yW-IR for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 07:48:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TL0-005CIf-VV for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:48:50 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacece0-2eae-0a2a0a5409dd-0a2a4504ee20-8 for ; Fri, 18 Sep 2026 09:48:50 +0200 Received: from [210.118.77.12] (helo=mailout2.w1.samsung.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacece1-b57f-0a2a45040019-d2764d0c6937-3 for ; Fri, 18 Sep 2026 09:48:50 +0200 Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20260918074849euoutp022613b4ffe1e1f419eba05fd0d3114ab5~WWsr6S5v-0840708407euoutp02S for ; Fri, 18 Sep 2026 07:48:49 +0000 (GMT) Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20260918074849eucas1p2f59ebb5edcf83292cd71fac7d0733896~WWsrk-7kH2296122961eucas1p2O; Fri, 18 Sep 2026 07:48:49 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20260918074848eusmtip187731a913ef6f63bbe35f6c4ba5f178b~WWsrFBHrg2379023790eusmtip1m; Fri, 18 Sep 2026 07:48:48 +0000 (GMT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mail20170921 header.d=samsung.com header.i="@samsung.com" header.h="Date:Subject:To:Cc:From:In-Reply-To:References" DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20260918074849euoutp022613b4ffe1e1f419eba05fd0d3114ab5~WWsr6S5v-0840708407euoutp02S DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1789717729; bh=9LRBFHkYxsMPHxldhSoBfcRMe67HegoQO3fxwKGAgho=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=ZA4IVbSokPWcxbEovDrM9dv0tHKT+oK6CJcM5gMAOcDFDCFv+nN/bGAGSRAUY/SxA vsV46J8vI/rQCeWpuHIgeiiLastztygUel2sybT5fHV5vK8B+9naw4xtYHx1q2p0CY cLQjz77i+qCb3CMLPbYym39iG17CJQHQ9zR0rHyE= Message-ID: Date: Fri, 18 Sep 2026 09:48:48 +0200 MIME-Version: 1.0 User-Agent: Betterbird (Windows) Subject: Re: BUG kernel 6.12.19 defautl_swiotlb_limit() returns wrong value for CONFIG_SWIOTLB_DYNAMIC=y effects atm only under XEN dom0 To: James Dingwall , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Andreas Greve Cc: iommu@lists.linux.dev Content-Language: en-US From: Marek Szyprowski In-Reply-To: Content-Transfer-Encoding: 7bit X-CMS-MailID: 20260918074849eucas1p2f59ebb5edcf83292cd71fac7d0733896 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20260918063741eucas1p290cc7d0360de73b3d07a23316a238b48 X-EPHeader: CA X-CMS-RootMailID: 20260918063741eucas1p290cc7d0360de73b3d07a23316a238b48 References: X-purgate-ID: tlsNG-ebf023/1789717730-53CC7B50-37F72A12/0/0 X-purgate-type: clean X-purgate-size: 1631 On 18.09.2026 08:37, James Dingwall wrote: > I've been having a problem with a Dell HBA330 SCSI controller (mpt3sas) > when booting under Xen and CONFIG_SWIOTLB_DYNAMIC=y is set. I had a > similar issue with a megaraid_sas card that I previously posted about: > > https://lkml.iu.edu/hypermail/linux/kernel/2407.3/08254.html > > In that case we rebuilt the kernel with CONFIG_SWIOTLB_DYNAMIC=n. > While investigating the current problem I came across a patch that was > posted on the xen-devel list: > > https://protect2.fireeye.com/v1/url?k=202f9c3b-7fb4525f-202e1774-000babda0201-d2724d878716e4ba&q=1&e=538195f2-f8bd-499e-8576-5e3d7c8ebca6&u=https%3A%2F%2Flists.xen.org%2Farchives%2Fhtml%2Fxen-devel%2F2025-05%2Fmsg00991.html > > I have applied that to the Ubuntu 7.0.0-31 kernel sources which has > resolved the controller initialisation error I was encountering and the > system now boots as expected. > > [ 3.921136] mpt3sas_cm0: no suitable DMA mask for 0000:03:00.0 > [ 3.921275] mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:13610/_scsih_probe()! > > I've included the patch below, I don't have the author's real address > for the s-o-b. I'm able to test alternative fixes if there are any > issues with this one. https://lore.kernel.org/xen-devel/93625976-e8af-4c39-90fb-45c926d420fd@a-greve.de/ Andreas: could You send Your fix with a bit more elaborated description and to the proper recipients (hint: use scripts/get_maintainer.pl tool), so it can be reviewed and potentially applied? Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From xen-devel-bounces@lists.xenproject.org Fri Sep 18 07:50:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 07:50:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424822.1649043 (Exim 4.92) (envelope-from ) id 1x7TMs-0006RH-Ke; Fri, 18 Sep 2026 07:50:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424822.1649043; Fri, 18 Sep 2026 07:50:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TMs-0006R8-HC; Fri, 18 Sep 2026 07:50:46 +0000 Received: by outflank-mailman (input) for mailman id 1424822; Fri, 18 Sep 2026 07:50:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TMr-0006R2-74 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 07:50:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TMq-005D7u-Jn for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:50:44 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaced3b-8faa-0a2a0a5109dd-0a2a4507b5fc-42 for ; Fri, 18 Sep 2026 09:50:44 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaced54-b4ea-0a2a45070019-4a7de18deca3-3 for ; Fri, 18 Sep 2026 09:50:44 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49cd38e0f79so2527335e9.3 for ; Fri, 18 Sep 2026 00:50:44 -0700 (PDT) Received: from [172.20.2.169] ([87.190.33.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fc7b7a6d9sm27906425e9.2.2026.09.18.00.50.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 00:50:43 -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" Authentication-Results: eu.smtp.expurgate.cloud; none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789717844; x=1790322644; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=ScPZq/aX/RVMdzyktUcM72kz/d/bEqiXLjtN1elr1+Y=; b=pKEWEueqqHGvrmHySa1rUsqWg4803crbePm+D5rdnYVhSk462RvwSxF1F+phR2e6me B4FT4y2q7PcLy+ydl9ZRCEzeqV3qc9jRWcyEEjm6P3DLxEm4JG3Vz6veK90wxOaE+OD1 aMz1ArRgOYoDsN91+KYJlw3XrHqguIER/N54yB+pz8tEE8bQjR2fzdpqRPr+CRZ6Va5z JUi/BsC1HQ0lNdXpo/iMG1gg7ZSvOD02kLlacNemyD3BW8HMROeAqsb11wHKJwd6uSej v79kHMYAP2W4mMRbUROKYNZ/F6qa/dUQPfNsa3UwVoHKI6S13rO4I/8yESqocUNRzI2S fHcw== X-Forwarded-Encrypted: i=1; AKwUvBysRA3HZZOWOvq2Npx1Ci/BuN6djldgifjagb7pySW62p5dS2LopAuYIRWV2csArsCcHFM7fRcklHY=@lists.xenproject.org X-Gm-Message-State: AFuF++mJ1AxVrwk2V6bSqy8tfPsAp3ER67asvVFbEJbgt9QPOCzxsdt+ 95WY81OAuNiKm8btvnL92KefNJI85TKrssrgWnQUNvGIHQppt8Z0XoMr X-Gm-Gg: AYBFou276IrawNqdpoXTUkUc5va8L4xYqiq889s08ABb1VyzuGzI9OpPvsRLsvPhyk9 atsrDWrRmCzAE8f0aQHHcHUJgchNmRZv+5Po++1B0JS53ib34bI96HgwwkqD4Ffti5TxRkb/cT9 w9QDaFXTNSAnniwqAzHkkdVf9r1daG0PB4VZBqrmtK2h7QEqmwTIeDqMlISh6JTmua9vjAxivZL hvPtPvagk3dAY6Piu7O4K1VObCozPf6+r4QWNaR8NVXrxaLgeLbAaUrkIwYXK0MCsa7+Nv0iyXN W2xEOTvNgWGsy8YTMm2imsNr8sKQc2dm0PUnx1ZwNjDrudQmYdIboEXoCq7wqEXR8Ia6D/694gw NnCIdPlxPBjiOvIkHwaGZBC5DEy0fDUmwgzNxrT7LpMuPddTq2OyqiFntQg9gfQKiPUoliyERox b9HMlIp9Wx2aOKuySWfGoja4BlnUauAXsGXhxK/6j2wOxXPKYyf+Jwp8wcJQFm9wYDkUmmqBh49 /e+e4TDRfgEXzyScik= X-Received: by 2002:a05:600c:c490:b0:49d:2555:1a6d with SMTP id 5b1f17b1804b1-49fc573e8b8mr32559905e9.16.1789717843913; Fri, 18 Sep 2026 00:50:43 -0700 (PDT) Message-ID: <81b73414-febe-4e3e-bfd4-30b6a13ede98@xen.org> Date: Fri, 18 Sep 2026 09:50:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 for 4.23] Add GIC SGI boot/self tests in Xen To: "Halder, Ayan Kumar" , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Roger Pau Monne , Doug Goldstein References: <20260916113520.3870182-1-ayan.kumar.halder@amd.com> <7b6d9027-9848-4909-a5a3-16ddf56dde72@xen.org> Content-Language: en-GB From: "Grall, Julien" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1789717844-34AC8AE4-12551795/0/0 X-purgate-type: clean X-purgate-size: 2233 Hi Ayan, On 17/09/2026 14:13, Halder, Ayan Kumar wrote: > On 17/09/2026 08:57, Grall, Julien wrote: >> On 16/09/2026 12:35, Ayan Kumar Halder wrote: >>> +static void __init expect_sgi(const cpumask_t *mask, >>> +                              const unsigned int *before, const char >>> *what) >>> +{ >>> +    s_time_t deadline = NOW() + MILLISECS(100); >>> +    unsigned int cpu; >>> + >>> +    for_each_cpu ( cpu, mask ) >>> +    { >>> +        while ( sgi_count(cpu) == before[cpu] ) >>> +        { >>> +            if ( NOW() > deadline ) >>> +                panic("GIC selftest: %s: CPU%u did not receive >>> GIC_SGI_TEST\n", >>> +                      what, cpu); >>> +            cpu_relax(); >>> +        } >>> +    } >>> + >>> +    printk("GIC selftest: CPU%u: %s: OK\n", smp_processor_id(), what); >>> +} >>> + >>> +/* >>> + * "All but self" is only meaningful once every CPU can take an SGI, >>> so it is >>> + * run by whichever CPU observes that it is the last one to get here. >>> + */ >>> +static int __init gic_sgi_selftest(void) >>> +{ >>> +    static atomic_t __initdata seen = ATOMIC_INIT(0); >>> +    unsigned int before[NR_CPUS] = { }; >> >> Sorry I didn't spot this earlier. NR_CPUS can be quite large (up to >> 16K). So this will blow up the stack. We discussed this offline at Xen Summit. But I will answer here as well. > > As this is a test, we have hardcoded NR_CPUS = 4 in automation/scripts/ > qemu-boot-selftest-arm64.sh. I agree with your current test harness we only test 4 CPUs. However, this is not enforced by the Kconfig in Xen. So anyone could modify the script (or write their own) with a much higher number of NR_CPUS (possibly to match the number of pCPUs on their hardware). Depending on the value, they could face a stack overflow. > > If there are 16K CPUs, our test only checks for 4 cpus only. > > However if there is still a concern .... I would preferred if this is solved. Assuming this is fixed: Reviewed-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Sep 18 07:56:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 07:56:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424833.1649052 (Exim 4.92) (envelope-from ) id 1x7TS2-00075S-Ag; Fri, 18 Sep 2026 07:56:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424833.1649052; Fri, 18 Sep 2026 07:56:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TS2-00075J-5Q; Fri, 18 Sep 2026 07:56:06 +0000 Received: by outflank-mailman (input) for mailman id 1424833; Fri, 18 Sep 2026 07:56:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x7TS1-00075D-2S for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 07:56:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TS0-00G1oD-BX for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:56:04 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacee92-8faa-0a2a0a5109dd-0a2a450590fc-4 for ; Fri, 18 Sep 2026 09:56:04 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaceda3-4cb1-0a2a45050019-4a7de18dd80b-3 for ; Fri, 18 Sep 2026 09:52:04 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912d822dso3006625e9.2 for ; Fri, 18 Sep 2026 00:52:03 -0700 (PDT) Received: from [192.168.1.109] ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fc7d1cca3sm29583815e9.11.2026.09.18.00.51.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 00:52:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789717923; x=1790322723; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+4rlEcaV00AvkcPBwnwJy+XQ/erHrlEYt1ZIbqoN5K0=; b=d1eHCxHGwezoITZuZwC0E79gikFUn56osg+Zm6f/v95qlzdUgEntT4vFA/ByjOKIq5 Z3e4XAF1lAdxE5u4X4SExmhR/iTJxSvPXIqNNP7CrlEnp2l00p9TWRDS1K5ol/WxwPys O8xO2C36MTTvhDBydOPrVBijLejzePvGvc8Nq0eL15L/VT+lyzRhfrvsykKT6dN9AJ8D 0KmudXn7HYb7FsB3XNyZFtOnul65DJNy/Hhi3fmBDsyER3MgF38xqz0cP0IEt2mzo3Aw czRQj7bEiM8HoVerIx7HEcLHfEDhLnL1+h+2usJTx8mVg71VnhhW0EreGqy2pQXOhzp5 JN/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789717923; x=1790322723; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=+4rlEcaV00AvkcPBwnwJy+XQ/erHrlEYt1ZIbqoN5K0=; b=vtL8JaOmXmQPZmnqDIfyomOycq1srcTqr7reLGtkprG4JUJsANvqjpid7YJQ4rA5+1 FlbafoAggX5DRI45L7VB01a/MpN3kb4DoLogykOtgwtXb8mOLO722nSqImLc2fPKibl4 XS657YjstxRSg6+yRjS2iwcUcvDMGirBfeKTcUpJLVYDL3+R12aWY539B+4ZumTk61NA azlIH2wKoNynTizgYRWpupvz01wNi9dYIbaMccl6aAC0+LmNl9ElWd4SnZvly8mRZqso RGU24B86RnvltUJ+xfQsPiKzhIbkBx+nrEIJYDacDF6vZ0onZThcmEGTgYSidhVoGkFj GwQA== X-Forwarded-Encrypted: i=1; AKwUvBygnZqTT5K2qcDGwFeihpZsSYTaH6COa9IxH93I3BHASacZTIgS0h5kmrH4bix9z6wJCEBG6oj6NU8=@lists.xenproject.org X-Gm-Message-State: AFuF++ncC87dDJs5C4vYrvIDEY9j035reNR5UgjfNhVpZgQzM44pWHeH Gkvi2RgEy1aPupAbKsfFJes6AzSileC7AQGUcXnwxM7Z3aQtaC1DaEBq X-Gm-Gg: AYBFou2I1jzuWGlMQA9WFrY81qZwSPc8e8ZAv+bEtFMCHacUaey2q1dE7vRCxF5CrxK DKasLHeRZ1iy9P5Iq37oTnEnRWZE1tWAvfohsh8TWVh+bqjTIF8CKLInKy5uWhr9iVR6F+rzbtQ OYWFt6Tf5KURMS5Ae4TFM58NVqpV4IU/n1npEPo8Iz9WoYapqKzqE7ENt7b8HyFvfH4espjzzxE eQVK6dzQcTVixcCtRjWtCG8mJmw5sdLDoXNRsXRTTP8ncT1a2rm1Gcw6h8S1h5Uy8D4xw1VulH+ 8FqPhS8l9SCpDkBjNCm/uFpPF024vZ8wDI/L744yJOrYFDgwyjJekx4JppIxJ2Y+9Xyk1nHLrea 73EM/JWjOdmxNUYD01bZ3yGfLKoJrVdbs+XQomBlyCC+oDEyOVDePHL1EWbo8uiuse4cUHGFi9i IzuMoV/2uczjv2O6YvTW4y1KmXJ2gXlZPn4UwXFwZbXo97u0tNtOi4PAEl7gsHQPd2sMu9Xropj WGLWVqyJ4j8WlW5 X-Received: by 2002:a05:600c:6085:b0:49d:797:8488 with SMTP id 5b1f17b1804b1-49fc567338bmr17631565e9.1.1789717923045; Fri, 18 Sep 2026 00:52:03 -0700 (PDT) Message-ID: Date: Fri, 18 Sep 2026 10:51:56 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, sstabellini@kernel.org, gwd@xenproject.org, enr0n@ubuntu.com, michal.orzel@amd.com References: <20260826045720.5779-1-frn1furkan10@gmail.com> <20260826045720.5779-3-frn1furkan10@gmail.com> <0899d0b5-431a-450d-9aec-796f73f92a83@gmail.com> <502268de-9e38-425b-bbc5-6202ed981398@suse.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: <502268de-9e38-425b-bbc5-6202ed981398@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1789717924-F48A62A1-78BC8FAE/3/8867283744 X-purgate-type: clean.bounce X-purgate-size: 3162 On 9/18/26 10:46, Jürgen Groß wrote: > On 14.09.26 12:40, Furkan Çalışkan wrote: >> >> On 9/14/26 12:16, Juergen Gross wrote: >>> On 26.08.26 06:57, Furkan Caliskan wrote: >>>> Now that we have introduced admission control for new and >>>> removed units. Extend it to XEN_DOMCTL_SCHEDOP_putinfo and >>>> putvcpuinfo, so growing an existing reservation via >>>> xl sched-rtds is checked too. >>>> >>>> putinfo sets the same (period, budget) for every unit of a >>>> domain at once, so it tests the whole domain's utilization >>>> delta atomically, rather than unit-by-unit, which could >>>> spuriously reject an overall-acceptable change depending on >>>> iteration order. >>>> >>>> putvcpuinfo changes one unit at a time, so it just calls >>>> rt_admission_test() directly. >>>> >>>> Signed-off-by: Furkan Caliskan >>>> --- >>>>    xen/common/sched/rt.c | 42 ++++++++++++++++++++++++++++++++++++++++++ >>>>    1 file changed, 42 insertions(+) >>>> >>>> diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c >>>> index 9126320801..9643a277fe 100644 >>>> --- a/xen/common/sched/rt.c >>>> +++ b/xen/common/sched/rt.c >>>> @@ -1527,11 +1527,43 @@ rt_dom_cntl( >>>>            op->u.rtds.budget = RTDS_DEFAULT_BUDGET / MICROSECS(1); >>>>            break; >>>>        case XEN_DOMCTL_SCHEDOP_putinfo: >>>> +    { >>>> +        uint64_t dom_old_util = 0, new_util, new_total; >>>> +        unsigned int nr_units = 0; >>>> + >>>>            rc = rt_validate_params(&op->u.rtds, &period, &budget); >>>>            if ( rc ) >>>>                break; >>>>    +        new_util = rt_unit_utilization(period, budget); >>>> + >>>>            spin_lock_irqsave(&prv->lock, flags); >>>> + >>>> +        /* >>>> +         * Same (period, budget) for every unit of d: test and commit >>>> +         * the domain's whole utilization delta atomically, rather >>>> +         * than unit-by-unit, which could spuriously reject an >>>> +         * overall-acceptable change depending on iteration order. >>>> +         */ >>>> +        for_each_sched_unit ( d, unit ) >>>> +        { >>>> +            svc = rt_unit(unit); >>>> +            dom_old_util += rt_unit_utilization(svc->period, svc->budget); >>>> +            nr_units++; >>>> +        } >>>> + >>>> +        new_total = prv->utilization - dom_old_util + >>>> +                    (uint64_t)nr_units * new_util; >>>> + >>>> +        if ( new_total > prv->utilization && new_total > rt_utilization_cap(d) ) >>>> +        { >>>> +            rc = -EINVAL; >>> >>> Is EINVAL a good choice here? I think a different error code might be wanted. >> >> Would EBUSY be okay here? Or what else would you suggest? > > EBUSY is a liitle bit better. What do you think about ENOSPC? > > > Juergen ENOSPC sounds good to me, I'll go with that. Thanks, Furkan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:08:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:08:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424853.1649060 (Exim 4.92) (envelope-from ) id 1x7Te1-00016l-KH; Fri, 18 Sep 2026 08:08:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424853.1649060; Fri, 18 Sep 2026 08:08:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Te1-00016e-HI; Fri, 18 Sep 2026 08:08:29 +0000 Received: by outflank-mailman (input) for mailman id 1424853; Fri, 18 Sep 2026 08:08:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Te0-00016Y-Ay for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:08:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Tdy-00DgIs-Rp for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:08:26 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacf174-8faa-0a2a0a5109dd-0a2a450992c8-36 for ; Fri, 18 Sep 2026 10:08:26 +0200 Received: from [52.101.83.73] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacf17a-be1a-0a2a45090019-346553496f5f-3 for ; Fri, 18 Sep 2026 10:08:26 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by DB4PR03MB8682.eurprd03.prod.outlook.com (2603:10a6:10:384::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.11; Fri, 18 Sep 2026 08:08:24 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.011; Fri, 18 Sep 2026 08:08:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sWBLC8h6iS3yaD6NReWdZY45JJzRsFHvnyUicW2eCtEP9nzdM8hdwl5/y7jVbrvhmJQKu9tOlqrF0mJyi+vRDxktmNuCYCslWrxKmjBW8V1cz0b72slOnaxhBgHQBWls+aZ52ks73qniSFce77gC3nfqh7hgwUoevqNv+BseVU5mF3ixLsp560+ZVdBcf2N8fu3tV8yWzkAL83yO9qWnZtCwbFBK7kaumbJFmvqtpVeOtaEvCSUhV1xcZzBZxIigVchFu9ERMj7c8pbR7ujVHxYoo0LhoNnKQwZcX6VZgn2Zo9VjnLTIxLkWxGbJpP0ogHB/r1WZGgMyLLnLu1tEEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=G6+n1hGOzr9TmaAtRS0gAJhj3pgZH7cMOCZq4RYAa3s=; b=by0CV3tJsLhhv9skwfPO0BNukwFgnUPsvtT78GfluAnY8nicPA6PODFuMByGQ+bEXykaFUJkJ3deCktFNlytqgQ3pJAeh9zpedsr6/zR5MoUNbNhMXUIHoJ4P4ZMeelbwvGWQtaHzlQIdPzgRAPuZa8ClrAe0lQcWX+nUujBba9eDtKoRg4upOrCmMZzuBNJQAHEfyQGFOTji8IKJGu8GBFIQJ5bDtqdasm2DWRYlZDULocC1h9Ts637t1sC+cunicoOX1YJINu34DlnaS2u264IoYAXMIMv3l2KKu2nwmCmW0GsMNhxa6SUax0a/i2a4CvpDHj4cYEnQ3gh9lBOdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G6+n1hGOzr9TmaAtRS0gAJhj3pgZH7cMOCZq4RYAa3s=; b=VtOMYl+85RG2Zpz4ncualfZPUgCCPIHS+Z9PiicdFUH+DIHILhZvP39C6TPPCFw4CG81mYPX4qHs+VmV5nK3UAOT4EH2d3QWWBeW6H7eWF8Qj3Afc84cETHxTKGqDTk/h5bDAc4nxmRPvXBnWHf3A9slcFDqAcNPpP5kzO2yS2HCMqX0EKzX0ElJ+ngcS4H6jueszZwhHUGZgGqRpxl/n0EkBYeJy8L+Jtv5al9L4BVjQnaBAt6eYx1JgGkf6uZxdEl2mtI+EQgMuae/YyF9bjaK9dhGgNnrvcJyMg74l8sGS7CmJ+Qxw877Eyjkv4KqOIg35h2HliePNetMxaANDg== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers Thread-Index: AQHdQb7XwQvbnxLqDEGK19PLXXgae7bJAQCAgABYGQCABnW1gIAAIbgAgAQVsQA= Date: Fri, 18 Sep 2026 08:08:23 +0000 Message-ID: <5dc8dfd3-c228-432f-b812-6a60b038552f@epam.com> References: <6bf8f9dd61da4d0fbea096b863f51db08df46c56.1789055542.git.oleksii_moisieiev@epam.com> <1d8be2c2-a56d-4b81-8e36-c4f97099c879@suse.com> <852f47c4-bd95-4e44-b409-ee805a07a5d4@suse.com> In-Reply-To: <852f47c4-bd95-4e44-b409-ee805a07a5d4@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|DB4PR03MB8682:EE_ x-ms-office365-filtering-correlation-id: ea200908-2843-4837-bee4-08df155c02ce x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|1800799024|7416014|376014|366016|22082099003|10067099003|4143699003|18002099003|56012099006|11063799006|38070700021; x-microsoft-antispam-message-info: NNdYlGU9brHtTOldTbQ9rH0B65xResO2wrx8qc7lCfrWsjSZJYKFeaYjskDSJBe/zM0zD6l28EWGpTN053xP3daVfgJNUgzoQw1nGQYSgYIFtzl/PIpaXWRBVwBdG5oTa0WC1wzTz9lAfzE/qGpk7LY8FMVbK//lP85eYl7MOyBq0tzrh9Qc2HNWYe1sNpP/7ixDNDYXgJbVCirTMdR7MfYfgrpbZE5U5nz60ed2wr2BAhTFZz1CQPXh1yT1aVf9urRL34nNMKOgjllGfWFSCB9C1ShmjwLj9CKLXoUInnkmFjmaxenvxoWuMxvEiwUQW8OkCprkJK/A8haUwJySuc1EIeB1zJLlTBIY0+LondUFLQN1pWwvfqiYBvJWEtRJAmUvClKpylSkBbqbymiuQJdfvdKb83vscQRd0B+tPe161t/8vFlELanBEa9M1EjkUsE6Hc8lg/Xm2HOTF8BQ64ebOXrMokSirejX8Kt4W/5v1E8HivhL/wtkuKDndrP4TTrm4dFv9TEr0MdyjZgl8SuJ1NI9Y/qa42NfFn9TFG8Ky85XIqLr67+8ymLjG+zg2Kgfs3akb4stAkgj2EGwViQD5XwkmAPeFvzVTJ/JwcJFTQPK/YGxZ8FtaNyLPpDZFVFL4WvXm8+qiHbBeJWvXRLykFg+LafZu3Us8AWSJ22+pIbz0yFA71DfvkZkgYEioXRyw8tQMpRqtnqBpdAYqxVBGnbKtR/fB4K277I6X+Q= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(7416014)(376014)(366016)(22082099003)(10067099003)(4143699003)(18002099003)(56012099006)(11063799006)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?anlJTGFOVjNtV0NVSEI0TmRBOEJYUE5LNjA2Z0d3dlBKZDNSUWpsVU9VSmZZ?= =?utf-8?B?clJaTUh4Q0dBZkFHTFo4dExmSlVJUlh1bW5qaU50eWJUM0JaTFVheXZPYmNu?= =?utf-8?B?WTVzZVB2S1Z2QnhuZlZwKzlNN3hoaGhHVHJSMzZzSUgvUXhDcGlHOUlGdnZl?= =?utf-8?B?WGp4VnRwZk9POVZaWXJhQlFPVC9ORUZveVg4OTR2N3F5U3QzRkJpWFB3MUwr?= =?utf-8?B?MThJamk5RTJBcVJHTVNVTUl2UGwycTY2MGgvdlV4bGEyNHZzZXYxWWZ4VE5L?= =?utf-8?B?c0w5LzN5UDl2b04vV09HSVhkaXhMM3g3VytVb01aWDlpMzNCNFcrVGJ0aDVn?= =?utf-8?B?Y2tIRk91azdIU3d0Y3RzOXdBS3pjVzgxUkZTT2N4cS9qSnVaNkFGaTh1cXVM?= =?utf-8?B?b0lJZVphL3Rkd1BRcU5EL2F6Uk9Mbjh2eFY2djNZOFJkYjJvUmRZbkE5SThl?= =?utf-8?B?SlNXUHNYRGRyNnRxQ3Z1bnZSVnhYd3hwZmdPSGhHbm1OUlhYQlYzcTZtdGFi?= =?utf-8?B?N1U3eWtGZVhMYnM1dGdHaTNVSS9DYVVtM0FZdTRmNCtMN21kYWlEem1zbHVp?= =?utf-8?B?TU5aUlJtQVVGcHIzTEdMdFFXZUdDeERWejZyUXBHdUw4T1JJVTBZOXM2MUFU?= =?utf-8?B?MWR3VUg1RGN5SDBGTEliTitkSjgvU0JhQXhtdDQyeXhPRys2RUdXRWgrR0JG?= =?utf-8?B?aWNVcXYxVEE5TzlKOC94OENOaDd6M0RsWjJWQ0RxUzRzUFQ2ZWRvUGtaWlFo?= =?utf-8?B?eDZIemRMZ21ZRG1mRmFWdkVnVEEwN3R4VkY2R2hhZm82TnQzRFRhZnc3NVVM?= =?utf-8?B?RXpyd3p0SFcyQndwdVNWZ2JKUmVyaGx5SFFXVXJYQk9Kb2dEeU1EdDJjMWxr?= =?utf-8?B?VlBqaElFUVJhTVkwOGZTR2ZTc2hUU0h5bnd5R1FjeTZzbU13TENKM3Vwc3ll?= =?utf-8?B?YjlpN1g1eVAwZFlaelIrSEhBYUp2Q2V3THVDYjhFVXh3UHFzYTNnZFVvSEVJ?= =?utf-8?B?Sm5hMXlrSCtkTW15dXY0ekExR1ZqVTZvZXZpWGZyaHJ0M05BMjJ1d0JDTG1Y?= =?utf-8?B?bDF5bTJPTjNMTVA0K21rRzd0TkZNV0xVMUtpUTIrU0tiVUR1dGgxaXNxQkNO?= =?utf-8?B?QndtMjlIZ2JueDlFRnE4dDQ4eXYvb21Zd0g2R0ZmSWlXUFdzQ2EwWlBuY0lJ?= =?utf-8?B?T1lBL05VYjM3NWRrTkNDY1JFYmxRMENoTjFWRzBBT0doOEF0MzRET0VUVnlI?= =?utf-8?B?N2VTSUU3MXA4T2VrVkRUMi9ZZVBCSDk2c01PLy91ZjNtQm54Sk1uNHQrRG9M?= =?utf-8?B?OFNFVnhLUEtMZHY1c1MwQjdINFA3MlpjeVJIK29wd0FMbmk1Q1Y4T0NOSHlk?= =?utf-8?B?TTAvaTlEZ1FKcjJ5N3RGZnQ2L0dUVWZvWGRPL21lUlBSM3FIWXAwdmV1ZGF0?= =?utf-8?B?TG1oQ09XWUFjdndEam9qTFdXOThha2QrdnNHNG90SVJ5SUM0L2FidkNsRkd3?= =?utf-8?B?TDZ2SG5TaFpweTN5KzVKQWVKQXJjSzM4ZysyTEZoN1NwMXMrWTFSYmlnZWYv?= =?utf-8?B?SHQ0WTg3cjZoeTN4YXdJVVRHazVTY3JzajRQek5rcDhueDNCYVhmN2t5dFJq?= =?utf-8?B?eG1iY0E4MjgyYS96aEk0M0x3RllpUGhqZzg2NXFsWWJGcjNNRmMweE8ycVVX?= =?utf-8?B?Ny85NG0wNmVJa1BhUTYyd1RVRHpLckZQTGNpVUZiUmZvQ0VvU2RTMzVHWnc1?= =?utf-8?B?ZVNKVllDdW11UG5vTG9FQmFGamYyUmNHTlA0YkorU2s5bjdQUEJOdnlWb2RN?= =?utf-8?B?RXdQZlpmNFlkKzIzNjZCaUJ1YVQ3Nk5FRHc3YjROZlBrRWJJdnNocFZSRTdG?= =?utf-8?B?RktBRjJwQ3pEaW9sWUJZUU5URHZBbUZqVkJnTTFvUklNNEJXUUpkaEFubFJQ?= =?utf-8?B?Y0hublhobDVGVHVZeWZBUUJWUXNYM1prSzdTaGV6SmZnYmluTm5ZeGliUG53?= =?utf-8?B?cDdXMFpnNzkvVjRQQVhza0JXUDNaUy9TeGROREhkeTBYZm1YZ2tnVDQ2VGY0?= =?utf-8?B?UlFCZzZ5STBmK1J4NmhpZWlha2JsdFY4dUg1Zk9qQlhxaTlqMTZjakE4Kysv?= =?utf-8?B?bkMwdFZWbkY4Nm03N1pqMmxxNHlMQmdPeVpNenZWb3pBVjU2aERselFLc01P?= =?utf-8?B?djNVTHlQT2FoVXFDeFVXRTRCNkIzNVMzbms0Znp5U25mVDk2ZEJZZTdIOFV5?= =?utf-8?B?TTlNMXpwK0c4bVBSUGRCVjEya2VaUTA3SnZlbzhkWTkxbkFJU0I5TWoyMlNW?= =?utf-8?B?VG56ZFJvL3pyazdudkNGMndVNC8wU0NGQWg3d3NGcmhvcGc3S1hzUXp2akxs?= =?utf-8?Q?sxi4JyPPUOOIEv7k=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <479004F459AEFA4F9836FE26C1F30598@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea200908-2843-4837-bee4-08df155c02ce X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2026 08:08:23.7755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WpB8IOwXwj4/6t72C/dh6wfXmwQeDZrkFrWxVPV7hU47A7EnDkx+vbrB2YQHmGrX4NfRxn0n67Soe7Le2OE4MgaP2b+H85LrdCnUyyLZbyY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB8682 X-purgate-ID: tlsNG-bad1c0/1789718906-FD469034-EF777448/0/0 X-purgate-type: clean X-purgate-size: 3174 DQpPbiAxNS8wOS8yMDI2IDIwOjQ1LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMTUuMDkuMjAy NiAxNzo0NSwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiAtIGlvLmgNCj4+DQo+PiBJJ2Qg cmVwbGFjZSB0aGUgY3VycmVudCBjb21tZW50IHdpdGggc29tZXRoaW5nIGFsb25nIHRoZXNlIGxp bmVzIChrZXB0DQo+PiBhcmNoLW5ldXRyYWwsIHNvIG90aGVyIGltcGxlbWVudGF0aW9ucyByZW1h aW4gcG9zc2libGUpOg0KPj4NCj4+IC8qDQo+PiAgIMKgKiBDb3B5IGEgc2VxdWVuY2Ugb2YgYnl0 ZXMgYmV0d2VlbiByZWd1bGFyIG1lbW9yeSBhbmQgYSBtZW1vcnktbGlrZQ0KPj4gICDCoCogSS9P IHJlZ2lvbiwgZS5nLiBzaGFyZWQgbWVtb3J5IHBsYWNlZCBpbiBSQU0gb3IgU1JBTSBtYXBwZWQg d2l0aA0KPj4gICDCoCogZGV2aWNlIGF0dHJpYnV0ZXMuDQo+PiAgIMKgKiBUaGUgSS9PIHJlZ2lv biBtdXN0IGJlaGF2ZSBsaWtlIGJ5dGUtYWRkcmVzc2FibGUgc3RvcmFnZTogaXQgbXVzdA0KPj4g ICDCoCogYWNjZXB0IDgtYml0IGFjY2Vzc2VzIGF0IGFueSBieXRlIGFkZHJlc3MgYW5kIG5hdHVy YWxseSBhbGlnbmVkDQo+PiAgIMKgKiAzMi1iaXQgYWNjZXNzZXMsIHdpdGggcGxhaW4gYnl0ZS1z dG9yYWdlIHNlbWFudGljcyBpbiBib3RoIGNhc2VzDQo+PiAgIMKgKiAobm8gc2lkZSBlZmZlY3Rz LCBubyBkZXBlbmRlbmN5IG9uIHRoZSBhY2Nlc3Mgd2lkdGgpLiBBbg0KPj4gICDCoCogaW1wbGVt ZW50YXRpb24gbWF5IHVzZSBhbnkgb2YgdGhlc2Ugd2lkdGhzLCBidXQgbmV2ZXIgd2lkZXIgb25l cy4NCj4+ICAgwqAqIFRoZSBoZWxwZXJzIGFyZSBub3Qgc3VpdGFibGUgZm9yIGRldmljZSByZWdp c3RlcnMgd2l0aCBhY2Nlc3Mtd2lkdGgNCj4+ICAgwqAqIHJlcXVpcmVtZW50cy4NCj4+ICAgwqAq DQo+PiAgIMKgKiBOZWl0aGVyIHBvaW50ZXIgbmVlZHMgdG8gYmUgYWxpZ25lZC4gVGhlIGFjY2Vz cyB3aWR0aHMgaXNzdWVkIG9uIHRoZQ0KPj4gICDCoCogSS9PIHNpZGUgZGVwZW5kIG9ubHkgb24g dGhlIGFsaWdubWVudCBvZiB0aGUgSS9PIHBvaW50ZXIgYW5kIG9uDQo+PiAgIMKgKiBjb3VudCwg bmV2ZXIgb24gdGhlIGFsaWdubWVudCBvZiB0aGUgcmVndWxhciBtZW1vcnkgcG9pbnRlci4NCj4+ ICAgwqAqDQo+PiAgIMKgKiBJbXBsZW1lbnRhdGlvbnMgYXJlIGFyY2hpdGVjdHVyZS1zcGVjaWZp Yzsgc2VlIHRoZSByZXNwZWN0aXZlDQo+PiAgIMKgKiBhcmNoLyovbGliL21lbWNweS17ZnJvbSx0 b31pby5jIGZvciB0aGUgZXhhY3QgYWNjZXNzIHBhdHRlcm4uDQo+PiAgIMKgKi8NCj4+DQo+PiBU aGUgQXJtLXNwZWNpZmljIG5vdGUgaW4gbWVtY3B5LXtmcm9tLHRvfWlvLmMgd291bGQgdGhlbiBz dGF0ZSB0aGUNCj4+IGNvbmNyZXRlIHBhdHRlcm46IDgtYml0IGFjY2Vzc2VzIHVudGlsIHRoZSBJ L08gcG9pbnRlciBpcyAzMi1iaXQNCj4+IGFsaWduZWQgYW5kIGZvciB0aGUgdHJhaWxpbmcgY291 bnQgJSA0IGJ5dGVzLCAzMi1iaXQgYWNjZXNzZXMgZm9yIHRoZQ0KPj4gYWxpZ25lZCBidWxrLiBJ J2QgYWxzbyBkcm9wIHRoZSAidG9sZXJhdGUiIHdvcmRpbmcgaW4gZmF2b3VyIG9mIHRoZQ0KPj4g YWJvdmUuDQo+Pg0KPj4gLSBpbXBsZW1lbnRhdGlvbg0KPj4NCj4+IEFzIHByb3Bvc2VkOiBvbmx5 IHRoZSBJL08gcG9pbnRlciBpcyBhbGlnbmVkIHVwOyB0aGUgUkFNIHNpZGUgdXNlcw0KPj4gZ2V0 X3VuYWxpZ25lZF9sZTMyKCkvcHV0X3VuYWxpZ25lZF9sZTMyKCkgZm9yIHRoZSAzMi1iaXQgcGFy dC4gVGhlDQo+PiBfbGUzMiB2YXJpYW50cyBhcmUgdXNlZCBkZWxpYmVyYXRlbHk6IHBhaXJlZCB3 aXRoIHJlYWRsKCkvd3JpdGVsKCksDQo+PiB3aGljaCBhcmUgZGVmaW5lZCBhcyBsaXR0bGUtZW5k aWFuIGFjY2Vzc29ycywgdGhpcyBwcmVzZXJ2ZXMgdGhlIGJ5dGUNCj4+IHNlcXVlbmNlIHJlZ2Fy ZGxlc3Mgb2YgQ1BVIGVuZGlhbm5lc3MuIFRoYXQgaXMgdGhlIG9ubHkgZW5kaWFubmVzcw0KPj4g YXNwZWN0IHdvcnRoIGEgbWVudGlvbiwgYW5kIEknbGwgcmV3cml0ZSB0aGUgY29tbWl0IG1lc3Nh Z2UNCj4+IGFjY29yZGluZ2x5IChkcm9wcGluZyB0aGUgc2VudGVuY2UgeW91IHBvaW50ZWQgb3V0 KS4NCj4+DQo+PiBXb3VsZCB0aGF0IGFkZHJlc3MgeW91ciBjb25jZXJucz8NCj4gSSB0aGluayBz by4NCj4NCj4gSmFuDQoNCg0KVGhhbmsgeW91LiBJIHdpbGwgbWFrZSB0aGUgY2hhbmdlcyBhbmQg cG9zdCB0aGVtIGluIHYxMy4gSSdsbCB3YWl0IGEgDQpsaXR0bGUgd2hpbGUgYmVmb3JlIHBvc3Rp bmcgdG8gYXZvaWQgc3BhbW1pbmcgcGF0Y2ggdmVyc2lvbnMuDQo= From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:09:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:09:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424859.1649068 (Exim 4.92) (envelope-from ) id 1x7TfO-0001Z6-U7; Fri, 18 Sep 2026 08:09:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424859.1649068; Fri, 18 Sep 2026 08:09:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TfO-0001Yz-Ra; Fri, 18 Sep 2026 08:09:54 +0000 Received: by outflank-mailman (input) for mailman id 1424859; Fri, 18 Sep 2026 08:09:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TfN-0001Yr-DQ for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:09:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TfM-00G22i-QD for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:09:52 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacf1c2-bab6-0a2a0a5309dd-0a2a450c9e2a-30 for ; Fri, 18 Sep 2026 10:09:52 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacf1d0-f479-0a2a450c0019-4a7de18da4e5-3 for ; Fri, 18 Sep 2026 10:09:52 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7bcb94d3so2928425e9.2 for ; Fri, 18 Sep 2026 01:09:52 -0700 (PDT) Received: from notebook.. ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48720083c19sm2174133f8f.31.2026.09.18.01.09.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 01:09:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789718992; x=1790323792; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=ipw7wZeqiwl6i7QK6/km4eSO0T1cabNVYb1txoxoEDs=; b=qITzEJ+BvZHRbOIstbE6Ge9x2/6mwmsiUg+D0oZaSv64cqCU26m9vMsnYNT5UBnPd3 pog8zycgZqKquer1oVxi8ii4NKWYkq6YcJ3yrhriKVIoHLJ3jHiE0zOwaXfWvzwQGyIM jsau3qt6C/VR9ZPC30JT67WIHxZnkHNR/rGVXVFypSicnVUX8eUA/sUnS3sO8a+PqOkU hvpRn2VJvl3mT5pJrGprvUIdZSAsXHDVDgNcdSFoZmSJ+U4k0lChHp1tqWBu+OoIDhJf H9CcfBOgToeytw54nUu7S1AhxPQLGeC1/Mvk+5Tj8PS0FXtL6L2cQxAvhei8PA+Wh/H7 CpqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789718992; x=1790323792; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ipw7wZeqiwl6i7QK6/km4eSO0T1cabNVYb1txoxoEDs=; b=wW80J6miVGxX1zw6L//h8Faor12QIC5GCdEGCgd2G29idnOVUo2h9LMvHUiZwq0+mv s1lafsM3cChUy4tMuYIbX/RZEAvxzoSvbtkA1ZVLvPY0teEqtomrh3Ej8EHAIMI6m270 aD+DkQP1zUUr1V5iMM2dy9fIe/iAzH/gfeek3NLR1NVE6RsyNJGZyDyTSirXb5ANAlPF 3wH6Szu8P8g91D+ESIsj3S4a4sA1T7e/Cn0wpNO+oJ9P7DyUBrppKKUavmPIE8qqRHtt PFSGAdoC6QY3NNA14wLnuZldh8FrZrKHFyoZZGObLQyaqiN3Ary9K4tw0Ki79hmLZ5G+ o/ag== X-Gm-Message-State: AFuF++l+0F828qf3jzZ3L26sejmXON2pSw1HbO+MC33WH7SZ8VUh4/Rz H+cFGhi8aA8kKL9Ninsos1oHQro54HazNfV5FLp1WuCGKPy4C8S2xMkdv9yg5w== X-Gm-Gg: AYBFou38lQQHOfK9+zWLOVTvVeCWmiHd9YRia4TqRk79trfyeYgCLNqUM3833t6m21L +XVj9j8V2ysibi2WaQtk0LiRpZZxb0Oiv66Owt2LoWbL7h9ia8a201YcM7nkmgBsP4eZb1W+GJ9 MwGh0tL4qHJmK5z7Q3tbMQNnh3TKJy35gJ7JtqzH2FqW7HgS6j9lmnsWsX+O4NtkY7SbGt11KXr PRaMirL1rsedMmX8EYIkDcm0DgZRzxovnwbFIPX1pqz4DBtTF2cmBC5ocFJoJWQkeY7BNgyb3FN L15olEy7+uj4WnwH1up+oVVBe4ijQF4ra42gbyVAvISBxGcZujIBC3Cy5Ui/dz6kreqnV5Tm7kM UDkm7E15iVleP1UNItchdPex/CkRSz8VVsmI/RPqi8bCUNCPb83p6wPoPAwTEI7jzrNLrlsv+EQ ys+9fRvYTuPLOLEiu3q0GyTn/Vi0c2PXREWUbCvh8ayr7xnLE/WI94f5G8HNUXC1+xn57Fu/E= X-Received: by 2002:a05:600c:4e89:b0:49d:10d6:fd55 with SMTP id 5b1f17b1804b1-49fc5681267mr19222485e9.1.1789718992015; Fri, 18 Sep 2026 01:09:52 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, Furkan Caliskan Subject: [PATCH v2 0/5] xen/sched: rtds: add per-cpupool admission Date: Fri, 18 Sep 2026 11:09:30 +0300 Message-Id: <20260918080935.35498-1-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1789718992-038D5A5B-17CF10A9/0/0 X-purgate-type: clean X-purgate-size: 2236 RTDS currently has no admission control: nothing stops the sum of all admitted units' (budget/period) reservations in a cpupool from exceeding what its pCPUs can actually provide. Once that happens, the global-EDF deadline guarantees the scheduler is built around no longer hold for any unit sharing that pool. This series adds admission control to prevent that, tracks and report utilization, and makes the check toggleable per cpupool so an operator can disable it if they intentionally want to overcommit. Patch 1 introduces the core mechanism: a running utilization total per cpupool, a fixed-point representation of a unit's (budget/period), and a capacity check enforced in rt_alloc_udata()/rt_free_udata() - the lifecycle hooks that catch every new unit's default reservation. Patch 2 extends the same check to domctl, so growing an existing reservation via xl sched-rtds is checked too. Patch 3 reports a cpupool's admitted utilization agains its capacity via the 'r' debug key. Patch 4 makes admission control itself toggleable per cpupool (enabled by default) via sysctl. Patch 5 wires that toggle through libxl and adds -s/-a to xl sched-rtds, and documents it. Furkan Caliskan (5): xen/sched: rtds: add global-EDF utilization admission control xen/sched: rtds: enforce admission control in xl sched-rtds xen/sched: rtds: report utilization and cap via debug key xen/sched: rtds: make admission control cpupool-wide toggleable tools: expose admission control toggle via xl sched-rtds docs/man/xl.1.pod.in | 20 +++ tools/golang/xenlight/helpers.gen.go | 23 +++ tools/golang/xenlight/types.gen.go | 4 + tools/include/libxl.h | 4 + tools/include/xenctrl.h | 6 + tools/libs/ctrl/xc_rt.c | 40 ++++++ tools/libs/light/libxl_sched.c | 46 ++++++ tools/libs/light/libxl_types.idl | 5 + tools/xl/xl_cmdtable.c | 8 +- tools/xl/xl_sched.c | 103 +++++++++++++- xen/common/sched/rt.c | 206 ++++++++++++++++++++++++++- xen/include/public/sysctl.h | 5 + 12 files changed, 464 insertions(+), 6 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:09:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:09:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424860.1649078 (Exim 4.92) (envelope-from ) id 1x7TfT-0001ne-8i; Fri, 18 Sep 2026 08:09:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424860.1649078; Fri, 18 Sep 2026 08:09:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TfT-0001nV-5j; Fri, 18 Sep 2026 08:09:59 +0000 Received: by outflank-mailman (input) for mailman id 1424860; Fri, 18 Sep 2026 08:09:58 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TfS-0001ms-9w for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:09:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TfR-008Sfx-N5 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:09:57 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacf1ce-e002-0a2a0a5209dd-0a2a45048800-20 for ; Fri, 18 Sep 2026 10:09:57 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacf1d5-b57f-0a2a45040019-4a7de18ca119-3 for ; Fri, 18 Sep 2026 10:09:57 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d3920so3128395e9.1 for ; Fri, 18 Sep 2026 01:09:57 -0700 (PDT) Received: from notebook.. ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48720083c19sm2174133f8f.31.2026.09.18.01.09.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 01:09:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789718997; x=1790323797; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=+D5EjjhGdVeYfpgBtQwACc7NrGO8erRw97egY4pDHIA=; b=MdnVsE9jDsItahxS0hAy6S6ILGz7hm2Sv8F+uFBZQaCGk3b7KFwETLGeldGlCzHCu7 0I/LsSYJRQ8SDzmExPDvPlHxDF0/sPKwTSZcCbjSP+bLDEDoI8EmbwBK0qNYlrv9oM3X rjw8h1IxCUv2X58+1k7LN825omub+rATNR9kTs9jL334sz3+dhwOraErjW3PoIWIBxd5 9gu8VDPsuULe+IxQBWlfXFr1ZMDcgt8QfRFpcbQhfCdzs+0LF4qfb/Jr1pA73rUugar6 qCa7Loz0bpLNRyTwbjU+WNWwkQ1qs8S/+H4evFMPQnZEEaRZXMXqB/rFmaVjkNwAvGVI rP/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789718997; x=1790323797; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=+D5EjjhGdVeYfpgBtQwACc7NrGO8erRw97egY4pDHIA=; b=UJ5BYTEP/bFbnqGANGMP18qaMd7WYfdD8R2k4lG0KhJGSjV/prAeQudh4/6pIjR1ch DWq74eQA+wj9oDm9L2E6xbgiiwj+IJiNaRsgPEbJecCa7O1M+e/bLgAhpipPFihvrX4r OrDoTXzrEw9m3wy8CaYrA3j1gCFBC3MOxbglhKmord9VkQZ13roJBBOWDeZPBgoO/FYp DoJIUNvp/FXrmOBvLrX1JTn8tWPXIUeIoBHv1bNCy7stHKbee0QDfJibPdudCCMaRYOS qY6jdytPcUHgplONNO+kspbnzymI6P7NnK6LzK4+P571XrjlKucksPTN+ZNzXjO94Sx5 u6YA== X-Gm-Message-State: AFuF++mRJMFjFJmcFCKIhOnAcZqtaQ6BhgH89OmEreao8PDU4F9Lnnp4 10mFAeItQmPHsxJZdeX+X4XrcF35exIabdhYjN88c7OPdzxbJBUcF5VJ5RvIjA== X-Gm-Gg: AYBFou2Tj1JGCiU88njb7LqLWphqd36treL4iasEjAt0OCTWb+8DufXY8S2lLRLHAgO zyfDX6IWMeKJ/uQKLLMNcybID3HJcKKhSScbJY1s1J16cTjoAuOTHiEu+ffo/P+TXAP8k1wqApZ N8ZhrczZAdgR28KvrFNNSuA+N6cQpwagZ6qs+vsDdVWGyTkyRFDWel0l6ChNubERHOjJev1yIX2 ruzEwvlMh5U2KQaum4aPRkXYvlj9twScvYJdwu3iyE5NkkKFUzCtxwwgBHlbDtEszKWj7zkoco6 Z6kWIYYqKhzX9MWgLUI6YF9gFoHG6L66mXB7X1AcOeGnm0PiiNur9xZ84aYYBbfwbPwrFgOwSlI EiecgJ69FKFbXIsJU3llLHxmNc37RzdJCkc5BQCpGJtAivbQl++ebdIP76/TYQzG5SDjisFFZPv 0YIERdzIw2G93dYnYU5mDPTKCjTAxSJmt5qBMwT4uWl/MtXMHEU3614qIlDpsby7Dv/BQ/K6y08 MwU3AXsWw== X-Received: by 2002:a05:600c:138c:b0:49e:799a:8969 with SMTP id 5b1f17b1804b1-49fc574af20mr17055175e9.30.1789718996990; Fri, 18 Sep 2026 01:09:56 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, Furkan Caliskan Subject: [PATCH v2 1/5] xen/sched: rtds: add global-EDF utilization admission control Date: Fri, 18 Sep 2026 11:09:31 +0300 Message-Id: <20260918080935.35498-2-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260918080935.35498-1-frn1furkan10@gmail.com> References: <20260918080935.35498-1-frn1furkan10@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1789718997-C2AC8B50-8B09FF18/0/0 X-purgate-type: clean X-purgate-size: 7316 RTDS has no admission control: nothing stops the sum of all admitted units' (budget/period) reservations in a cpupool from exceeding what its pCPUs can actually provide. Once that happens, none of the EDF deadline guarantees this scheduler is built around still hold for the units sharing that pool. Introduce admission control to prevent this: reject a reservation whenever admitting it would push a cpupool's units over its capacity. Track a running utilization total per cpupool, and enforce it in rt_alloc_udata()/rt_free_udata(), the paired lifecycle hooks for a unit's creation and destruction. This catches the default period/budget every new unit gets. Utilization is represented as a fixed-point value: budget is left shifted by RTDS_UTIL_SHIFT (20 bits) and divided by period. A plain "(budget << RTDS_UTIL_SHIFT) / period" risks overflowing the multiply for large enough budgets. Rather than widen the arithmetic to tolerate any input, the input itself is bounded: rt_validate_params() rejects any budget above RTDS_MAX_BUDGET, chosen as the largest value that can be left-shifted by RTDS_UTIL_SHIFT without overflowing 64 bits, so the shift in rt_unit_utilization() can never overflow. A cpupool's capacity rt_utilization_cap() scales with the number of scheduling resources in it. It is calculated as: (number of sched_resources * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100), where RTDS_UTIL_CAP_PCT controls how much of that capacity can actually be reserved; at 100% (its current value), all of it can be. Signed-off-by: Furkan Caliskan --- v2: - Renamed rt_admission_test() to rt_try_set_utilization() and changed its return type from int to bool, since it doesn't just test but also commits the new utilization on success. --- xen/common/sched/rt.c | 105 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 104 insertions(+), 1 deletion(-) diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c index 0e9f04ea72..acebbbe57e 100644 --- a/xen/common/sched/rt.c +++ b/xen/common/sched/rt.c @@ -114,6 +114,24 @@ */ #define RTDS_MAX_PRIORITY_LEVEL (~0U) +/* + * Fixed-point scale for utilization (budget/period) + */ +#define RTDS_UTIL_SHIFT 20 +#define RTDS_UTIL_SCALE (1ULL << RTDS_UTIL_SHIFT) + +/* + * Largest budget safe to left-shift by RTDS_UTIL_SHIFT without + * overflowing 64 bits. Enforced in rt_validate_params(). + */ +#define RTDS_MAX_BUDGET_BITS (64 - RTDS_UTIL_SHIFT) +#define RTDS_MAX_BUDGET ((1ULL << RTDS_MAX_BUDGET_BITS) - 1) + +/* + * % of a cpupool's sched_resource capacity admitted units may sum up to. + */ +#define RTDS_UTIL_CAP_PCT 100 + /* * UPDATE_LIMIT_SHIFT: a constant used in rt_update_deadline(). When finding * the next deadline, performing addition could be faster if the difference @@ -195,6 +213,9 @@ struct rt_private { struct list_head replq; /* ordered list of units that need replenishment */ cpumask_t tickled; /* cpus been tickled */ + + /* Sum of admitted units' (budget/period), scaled by RTDS_UTIL_SCALE */ + uint64_t utilization; }; /* @@ -635,6 +656,54 @@ replq_reinsert(const struct scheduler *ops, struct rt_unit *svc) set_timer(&rt_priv(ops)->repl_timer, rearm_svc->cur_deadline); } +/* + * budget << RTDS_UTIL_SHIFT can't overflow: rt_validate_params() + * caps budget at RTDS_MAX_BUDGET. period == 0 means "no + * reservation" (a unit being removed), not an error. + */ +static uint64_t +rt_unit_utilization(s_time_t period, s_time_t budget) +{ + if ( period <= 0 ) + return 0; + + return ((uint64_t)budget << RTDS_UTIL_SHIFT) / (uint64_t)period; +} + +/* + * Utilization capacity of the cpupool domain d resides in. + */ +static uint64_t +rt_utilization_cap(const struct domain *d) +{ + unsigned int cpus = cpumask_weight(cpupool_domain_master_cpumask(d)); + + return (uint64_t)cpus * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100; +} + +/* + * Replaces a unit's reservation and updates prv->utilization + * to match. Growth that would push utilization over the + * cpupool's cap is refused. Removing a unit or shrinking + * a unit's reservation always succeed. + */ +static bool +rt_try_set_utilization(struct rt_private *prv, const struct domain *d, + s_time_t old_period, s_time_t old_budget, + s_time_t new_period, s_time_t new_budget) +{ + uint64_t old_util = rt_unit_utilization(old_period, old_budget); + uint64_t new_util = rt_unit_utilization(new_period, new_budget); + uint64_t total = prv->utilization - old_util + new_util; + + if ( new_util > old_util && total > rt_utilization_cap(d) ) + return false; + + prv->utilization = total; + + return true; +} + /* * Pick a valid resource for the unit vc * Valid resource of an unit is intesection of unit's affinity @@ -864,6 +933,7 @@ rt_free_domdata(const struct scheduler *ops, void *data) static void * cf_check rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) { + struct rt_private *prv = rt_priv(ops); struct rt_unit *svc; /* Allocate per-UNIT info */ @@ -881,9 +951,30 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) __set_bit(__RTDS_extratime, &svc->flags); svc->priority_level = 0; svc->period = RTDS_DEFAULT_PERIOD; + if ( !is_idle_unit(unit) ) + { + unsigned long flags; + bool admitted; + svc->budget = RTDS_DEFAULT_BUDGET; + spin_lock_irqsave(&prv->lock, flags); + admitted = rt_try_set_utilization(prv, unit->domain, 0, 0, + svc->period, svc->budget); + spin_unlock_irqrestore(&prv->lock, flags); + + if ( !admitted ) + { + printk(XENLOG_WARNING + "RTDS: ADMISSION CONTROL: refusing unit %u of d%d," + " would exceed utilization capacity of the cpupool\n", + unit->unit_id, unit->domain->domain_id); + xfree(svc); + return NULL; + } + } + SCHED_STAT_CRANK(unit_alloc); return svc; @@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) static void cf_check rt_free_udata(const struct scheduler *ops, void *priv) { + struct rt_private *prv = rt_priv(ops); struct rt_unit *svc = priv; + if ( svc && !is_idle_unit(svc->unit) ) + { + unsigned long flags; + + spin_lock_irqsave(&prv->lock, flags); + rt_try_set_utilization(prv, svc->unit->domain, + svc->period, svc->budget, 0, 0); + spin_unlock_irqrestore(&prv->lock, flags); + } + xfree(svc); } @@ -1389,7 +1491,8 @@ rt_validate_params(const struct xen_domctl_sched_rtds *rtds, s_time_t b = MICROSECS(rtds->budget); if ( p < RTDS_MIN_PERIOD || p > RTDS_MAX_PERIOD || - b < RTDS_MIN_BUDGET || b > p ) + b < RTDS_MIN_BUDGET || b > p || + b > (s_time_t)RTDS_MAX_BUDGET ) return -EINVAL; *period = p; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:10:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:10:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424862.1649088 (Exim 4.92) (envelope-from ) id 1x7TfX-0002Nw-IA; Fri, 18 Sep 2026 08:10:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424862.1649088; Fri, 18 Sep 2026 08:10:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TfX-0002NW-Cd; Fri, 18 Sep 2026 08:10:03 +0000 Received: by outflank-mailman (input) for mailman id 1424862; Fri, 18 Sep 2026 08:10:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TfW-00027S-KP for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:10:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TfV-003rgf-Hi for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:10:01 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacf1cb-8faa-0a2a0a5109dd-0a2a450288be-40 for ; Fri, 18 Sep 2026 10:10:01 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacf1d9-6ca4-0a2a45020019-4a7de14cbc85-3 for ; Fri, 18 Sep 2026 10:10:01 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6350faaso225108f8f.0 for ; Fri, 18 Sep 2026 01:10:01 -0700 (PDT) Received: from notebook.. ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48720083c19sm2174133f8f.31.2026.09.18.01.09.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 01:10:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789719001; x=1790323801; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=iQ/UHhRs/oHG8h8cgbtjbUFCoCrSiy2F1gF60N4pmIY=; b=sfLLBW/R8y0at93WFhcddCN1BliksEKbbK2IkJDR8KCP8cyd8j1Jcveoa/eHfJJDGI EmW6nbnlbPPW72Wc0wjhO3lobxsV8KT/kUGnwFapfJx2PZn9xP8eZlw336ybqwrezYUA BJzl7zvroRS7g6ihfOMrP2TlvKa1xYzDhDcvLlwHUBPup1Ls7LjG9PUgfrXoDVpAAKy8 zuZ90Qnevzbj/07rldV5bvTCho192J+CUFGanuDuaO9r1YKiJ0JRRsL+bAspr2VJp51k eoyw3alZiIidzjpvDzt3frG8np/ucEBMMMHvLXayReFE8skrplPOSyXDmlK2la8DJoQC x/dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789719001; x=1790323801; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=iQ/UHhRs/oHG8h8cgbtjbUFCoCrSiy2F1gF60N4pmIY=; b=ddJVuKENdV1+73egEWyDtCo+u2VKk/7nC9AVozScOuzbrGRjJF0QQnM07fQDqfRosn JsN8e3EAn98Zfqb7yloSWqbS3uIATDlOGD9n6i9UHiMRwemv5JF5o2b3E/D9HKvkCNow bu6eHqqwBZOWDG3ylwFn2oWDzs4of5RHI5JfW1y4zIEAtvzzCupVLCr2+QAWaTLYl+Bk SsAvrH3l7oQ1mhVUzY+c85lEDApWARrdnAsJz/ps3X/QZLGyNHfIzxcrWDA/B8HdvlzR +k4s3KU0uRQQMoJjDp62WebfJUDtJFyd29FEyTLtkXOi+CS38ymN8xEXw5Mlhw5ppI4w /R7w== X-Gm-Message-State: AFuF++kuuXDAL277wtCz4yTZH+xGU2ssGixQ/Q4oSAHcYRPpGzUZTSZm iwdi3Oc8IKoeYFnpAeIug/3HLNEd1VgmSNmLZ54h+qaHTM517+hPJzifUlQ6tw== X-Gm-Gg: AYBFou0k2U3QUMYutNCsuA5VNAgFFP58lSAn2JzDU3BeT+cwQtT54Fr1+Xdg6mUYDZ5 hAgMP3lv5NcdHILv2lEh1mliymWZn0D7MH+Zu8m7FEWAgWZH3x0BGIMwKdQwAkz0eGEj/WFKzfm ShTxj9Z2/HVkGYzKpjV7bHaztCtPqEVyjzLnrYd6atf2/JZYi1cojCRQf7OrWQxK3Kd13wutbVW xpNcj2YiNuxiEh9p/OL3sQTDbQBSEgzaf/al/wEpFyG/8jrVHNxVF2KRbye7he6vO3w8RLNJCB7 YlNrJESkjh05+sr5I1T6qDsg1ilDG0TQlI8FvfaIfDBZgnNY6lPpQLDchJi/DG25J9/7R5/1Q2R EUX0TutLDI5WO9/W6xLA5eN2Oq7cboR8W0pR/qsGDxXJACkeDOYbObWpXb/Q0SN4709/69cjOsT BEyJqJy6+NtbDmJe230NHtEn7dsSUVl48LBu2RKcSOMyTbKDKU2RQdEPKpUEuieRuSpoXugUo= X-Received: by 2002:a5d:64c8:0:b0:487:fb0:9ff with SMTP id ffacd0b85a97d-4871e2177a0mr2376821f8f.22.1789719000677; Fri, 18 Sep 2026 01:10:00 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, Furkan Caliskan Subject: [PATCH v2 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds Date: Fri, 18 Sep 2026 11:09:32 +0300 Message-Id: <20260918080935.35498-3-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260918080935.35498-1-frn1furkan10@gmail.com> References: <20260918080935.35498-1-frn1furkan10@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1789719001-67EBB2AC-C9E7D528/0/0 X-purgate-type: clean X-purgate-size: 3359 Now that we have introduced admission control for new and removed units. Extend it to XEN_DOMCTL_SCHEDOP_putinfo and putvcpuinfo, so growing an existing reservation via xl sched-rtds is checked too. putinfo sets the same (period, budget) for every unit of a domain at once, so it tests the whole domain's utilization delta atomically, rather than unit-by-unit, which could spuriously reject an overall-acceptable change depending on iteration order. putvcpuinfo changes one unit at a time, so it just calls rt_try_set_utilization() directly. Signed-off-by: Furkan Caliskan --- v2: - Use ENOSPC instead of EINVAL. - Unlock prv->lock before setting rc, not after. --- xen/common/sched/rt.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c index acebbbe57e..fbebd82c78 100644 --- a/xen/common/sched/rt.c +++ b/xen/common/sched/rt.c @@ -1527,11 +1527,43 @@ rt_dom_cntl( op->u.rtds.budget = RTDS_DEFAULT_BUDGET / MICROSECS(1); break; case XEN_DOMCTL_SCHEDOP_putinfo: + { + uint64_t dom_old_util = 0, new_util, new_total; + unsigned int nr_units = 0; + rc = rt_validate_params(&op->u.rtds, &period, &budget); if ( rc ) break; + new_util = rt_unit_utilization(period, budget); + spin_lock_irqsave(&prv->lock, flags); + + /* + * Same (period, budget) for every unit of d: test and commit + * the domain's whole utilization delta atomically, rather + * than unit-by-unit, which could spuriously reject an + * overall-acceptable change depending on iteration order. + */ + for_each_sched_unit ( d, unit ) + { + svc = rt_unit(unit); + dom_old_util += rt_unit_utilization(svc->period, svc->budget); + nr_units++; + } + + new_total = prv->utilization - dom_old_util + + (uint64_t)nr_units * new_util; + + if ( new_total > prv->utilization && new_total > rt_utilization_cap(d) ) + { + spin_unlock_irqrestore(&prv->lock, flags); + rc = -ENOSPC; + break; + } + + prv->utilization = new_total; + for_each_sched_unit ( d, unit ) { svc = rt_unit(unit); @@ -1540,6 +1572,7 @@ rt_dom_cntl( } spin_unlock_irqrestore(&prv->lock, flags); break; + } case XEN_DOMCTL_SCHEDOP_getvcpuinfo: case XEN_DOMCTL_SCHEDOP_putvcpuinfo: while ( index < op->u.v.nr_vcpus ) @@ -1584,6 +1617,15 @@ rt_dom_cntl( spin_lock_irqsave(&prv->lock, flags); svc = rt_unit(d->vcpu[local_sched.vcpuid]->sched_unit); + + if ( !rt_try_set_utilization(prv, d, svc->period, svc->budget, + period, budget) ) + { + spin_unlock_irqrestore(&prv->lock, flags); + rc = -ENOSPC; + break; + } + svc->period = period; svc->budget = budget; if ( local_sched.u.rtds.flags & XEN_DOMCTL_SCHEDRT_extra ) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:10:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:10:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424863.1649096 (Exim 4.92) (envelope-from ) id 1x7Tfa-00036L-Ns; Fri, 18 Sep 2026 08:10:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424863.1649096; Fri, 18 Sep 2026 08:10:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Tfa-00036B-KN; Fri, 18 Sep 2026 08:10:06 +0000 Received: by outflank-mailman (input) for mailman id 1424863; Fri, 18 Sep 2026 08:10:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7TfY-0002oA-W8 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:10:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7TfY-003rpJ-Cm for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:10:04 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacf1d5-8faa-0a2a0a5109dd-0a2a4505aa90-26 for ; Fri, 18 Sep 2026 10:10:04 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacf1dc-4cb1-0a2a45050019-4a7de14cad4f-3 for ; Fri, 18 Sep 2026 10:10:04 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485ac898fa4so340638f8f.0 for ; Fri, 18 Sep 2026 01:10:04 -0700 (PDT) Received: from notebook.. ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48720083c19sm2174133f8f.31.2026.09.18.01.10.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 01:10:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789719004; x=1790323804; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=vuTMyyL/j+Gx6XXHaxE1E56hGhzahr3nj7I37fciPF4=; b=BPn3lU5V6hCjNbI3xSkqgCdensJJpQQbT2iguZiHMzvo6vzaidPevcKnJ7TmsuBroh pPLkiY8IgBm8pgyHCEdec9+MAgvPakc4w5B881EmJpRX7Fh8opmzeX0YoMaLkGQU9Xj+ J67wPoHAFyj0Nl3Y49yV8psJHg9xd+o0F2cF2yMKTG89SgsZXN496t3WwpezrjI/NIDw e5DNAaIDWSzLjH23xMWS08K2Z+VtyNNJE43b7a3W2XGk5VkiCEbktOnyxwpXsMKXbUOc Eq2zCA2ONk8G0QBkSGrviIi9wN5OK4mu+2I3q2vjWsaEqDsiLy4UXweJZcZRMWTzH2PD j9rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789719004; x=1790323804; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=vuTMyyL/j+Gx6XXHaxE1E56hGhzahr3nj7I37fciPF4=; b=D8mo0yc2ZB7ItwSSK38TdiLq0qiThjskXfPwH+TACtIvPp0e6CM0a2IH3QUWgC11N7 1aYyq9CJlmo3tnuVxrt27j6+10EvbnYxWwjh416LLv7vymzk+ejS6gynvAkyLwD4VN3U /8U5DR4EJr5LXf4InGEf6E9E7+zF5oAAPjK09Ysu9huwVqe7dJbsXjBFJiI0RA359hP5 y0BbWWHQW0DQv0thDdaD1eGIVU9UsgwnW8jbX/AfaUJKAkcAXZk3vt+qHarlgkjYH0Nl ScD4IXLs3HkhEEJ75fNbJzPV0jNfLqGP7+U7yNGjUDOmDHae8c7ezzoPrx/13EumDVmJ JNVQ== X-Gm-Message-State: AFuF++mIEZEl0CLN2xmJXKDoUvI05S4ZhtJjzSjHE3RPr4gKiRTDH5Of y9h0t0IYrg5qSnJTacf+bSt6BJTI1CHmjAImULlVOlDd/Zb1ZACttNJXEbAzMQ== X-Gm-Gg: AYBFou0jT5dlfpHN90zuuWWhVSzZjP0t7KdgFUqdD8t1vW5nPQFAn65EoLtW+6wjSIo zCXCRE3LAlCvw7KYu1TxhupxhoktmqohfhQKLjeE69gqmVdYe6G2ElGBuOt0RzaapAUW8ss5YDA VY4jqZgrX/ZnHDRXMM9/D5ACQuQEYe+46rzcl5bE5cj3/LFBsIG5BFpsstm0IC75h+0Q/UdnZFu O9R3g8xg1ksm28W6x+VVcJuaZ0sM9M6ZGiiRJbHA1MfaO4kQ/VdkL5MXGlUvQsHtldizV9LoakN cICW1BS07KyDfcqn6adc4rV/x2RW7yCYmSdu/LPULmX/93YZFxDkfzMh9Ff+L9jt0eip8he5kPu 8n3epiFNNlq6puAqgmTQ+aru6+g6Ks5LvYjQ/1MBctlFxnTBJbxF/Zi5sBHFd2CPhRtuwl30Hne UyASG5ux7r1YIPUwicxTRvpEKPN1Og8LFZdXbT3DmHnjCLAK54BvFObmovRHvceYr6AIMejzOmG 1MAzXULgQw= X-Received: by 2002:a05:6000:178a:b0:487:1266:5be7 with SMTP id ffacd0b85a97d-4871e26674emr2167416f8f.26.1789719003772; Fri, 18 Sep 2026 01:10:03 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, Furkan Caliskan Subject: [PATCH v2 3/5] xen/sched: rtds: report utilization and cap via debug key Date: Fri, 18 Sep 2026 11:09:33 +0300 Message-Id: <20260918080935.35498-4-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260918080935.35498-1-frn1furkan10@gmail.com> References: <20260918080935.35498-1-frn1furkan10@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1789719004-F52A32A1-AA1690FC/0/0 X-purgate-type: clean X-purgate-size: 1224 Print a cpupool's admitted utilization against its capacity in the 'r' debug ky (xl debug-keys r), so an operator can see the total usage of a cpupool. Signed-off-by: Furkan Caliskan Reviewed-by: Juergen Gross --- xen/common/sched/rt.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c index fbebd82c78..342f9b3a51 100644 --- a/xen/common/sched/rt.c +++ b/xen/common/sched/rt.c @@ -399,12 +399,22 @@ rt_dump(const struct scheduler *ops) const struct rt_unit *svc; const struct rt_dom *sdom; unsigned long flags; + uint64_t cap; spin_lock_irqsave(&prv->lock, flags); if ( list_empty(&prv->sdom) ) goto out; + cap = (uint64_t)cpumask_weight(ops->cpupool->res_valid) * + RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100; + + if ( cap ) + printk("Utilization: %llu%% of capacity\n", + (unsigned long long)(prv->utilization * 100 / cap)); + else + printk("Utilization: cpupool has no capacity\n"); + runq = rt_runq(ops); depletedq = rt_depletedq(ops); replq = rt_replq(ops); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:10:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:10:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424864.1649105 (Exim 4.92) (envelope-from ) id 1x7Tfc-0003SP-Vf; Fri, 18 Sep 2026 08:10:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424864.1649105; Fri, 18 Sep 2026 08:10:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Tfc-0003S0-RH; Fri, 18 Sep 2026 08:10:08 +0000 Received: by outflank-mailman (input) for mailman id 1424864; Fri, 18 Sep 2026 08:10:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Tfb-0003I6-FI for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:10:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Tfa-00AVDl-RW for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:10:06 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacf1db-2eae-0a2a0a5409dd-0a2a450ae71c-36 for ; Fri, 18 Sep 2026 10:10:06 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacf1de-f2d2-0a2a450a0019-4a7de14cddc8-3 for ; Fri, 18 Sep 2026 10:10:06 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-48583cc7ab1so183992f8f.2 for ; Fri, 18 Sep 2026 01:10:06 -0700 (PDT) Received: from notebook.. ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48720083c19sm2174133f8f.31.2026.09.18.01.10.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 01:10:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789719006; x=1790323806; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Oy/dbkoBMnHERlUH5IsXUjgHEA7CUR5ZyPf4nBEOh8U=; b=PSIuIZyfWVsMX8HhApYfOCQ0f4VlMMmbm6mQiQoig7p/yFbchSsWSs/vRsgD2P8BNt JUtbRY+Bdl7EWHCDjP5Q7XFMTYPYN6gLx1dENQUC7FBWobj5/iw8ce2bXmTQ7u5mJv9P xRms9f6PbJJrsRmCRfzja+wt2FhyoZk11jWTFbplWnT7pxtZn2hrj0vSFrdIjzsrZHDQ c6DMlqZ6vBS8b6zM1KIrG57LJAf7zrLUg1ip5+Z/8NB3EX7yh8WnoH9rE8OnaMiC+rfK F8+1Jb5yBhkzdzD7qElF05JGCHvJCcvFepvqsjQNOSFUw7KZRAbskFvqU9SE1147PF+J 69tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789719006; x=1790323806; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Oy/dbkoBMnHERlUH5IsXUjgHEA7CUR5ZyPf4nBEOh8U=; b=U9Jb7MakEZJiv2033e6a7pPsqwgoU6Fb34SrKFRn7K/xJHImdr6wTmh84nYsOiE5tA nh1MkNMMAFAMdOHFTNmoX3GQ0tBxR3+F+JX7F9fOXl7NvEmk50gY9iL5EGk2cJsWV95C uLGhk6J2chBZZXoc/Zy3jGycPZTogAOraZQ5zYN7kpn4JIUWVwZHTEhYT9l6loQhMWrA i+PBLhFeqlRQnfqlHgYM6yfVt9zeskf+d7qUfT5pF8pycQcgFVKFoHkW4yexZztfCeAM nkVYaLH8gX0OMeeCNNqm5aDHRGVAEJB+gajFPcqw/CvlKAjA7QwT53iJqlx0hr0G8TmD nXfA== X-Gm-Message-State: AFuF++nPHklu17pKmWwB3hZlP+3chrw8VsW+hwh+23thJ4NpUUUt4DiY 1/Oq/N61CwSTnieUve15n4ZV+ZQq2Va1yrZe5rqF1TqvBPHahHxkU95xUerXew== X-Gm-Gg: AYBFou1WpQVrPgY7LR18rPzfVCvjg9LoWm1Gsigu3iILFNfVOMY5Zz6HX6DgyBc4Ezg /Z4J9cw9gnzPtt7bY1mfrJGDDU4kWHMIvSejZXjQMZMmCtTQUYtfFp0SjyKrMj3Wg9L8trtW3gH 3e92s1hDaClx2yukpJk9hzItxhYSNqDuZ3kKx2d3T2uvd9dQ+MNfPhOTTDY+P98LLKaZaUwz9/Q myL2hJDrbZzW4bouSuAIVON2ovkFZR+8DBt9kxpDF8g7OgSFUPuqvB4oEg+AgRbwalUH0y4mh0j iislvQqSl+tVTeaHt8ELhuNONi2g8W7RvPJCqenULRyn+FSOmQUpWs+NkGzwMEOHQpNb2teW7eC Qp5CLRngEHYV2ZmOgmO5jlXWSw66d1kMEpYhNbAzYtMQFFpU8O4xYD04uoGmnLz71swWu2UTOVD LwyA7TLqsu37DlCj0p3qwdETu4Wjp8cgHN2xa/1u+ijmFQ2/oi94WaypEnVq+XSxp2ruwP7O7c X-Received: by 2002:a05:6000:2f88:b0:486:f18b:3cf8 with SMTP id ffacd0b85a97d-4871e220ad4mr1998089f8f.22.1789719006031; Fri, 18 Sep 2026 01:10:06 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, Furkan Caliskan Subject: [PATCH v2 4/5] xen/sched: rtds: make admission control cpupool-wide toggleable Date: Fri, 18 Sep 2026 11:09:34 +0300 Message-Id: <20260918080935.35498-5-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260918080935.35498-1-frn1furkan10@gmail.com> References: <20260918080935.35498-1-frn1furkan10@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1789719006-536D6CFC-5B9311D6/0/0 X-purgate-type: clean X-purgate-size: 6019 Add a per-cpupool on/off switch for RTDS admission control via XEN_SYSCTL_scheduler_op, enabled by default, so an operator can disable/enable enforcement for a pool Signed-off-by: Furkan Caliskan --- v2: - Insert a blank line between the two non-fall-through case blocks. - Use uint8_t instead of bool for admission_control_enabled in the public xen_sysctl_rtds_schedule struct. --- xen/common/sched/rt.c | 57 ++++++++++++++++++++++++++++++++++--- xen/include/public/sysctl.h | 5 ++++ 2 files changed, 58 insertions(+), 4 deletions(-) diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c index 342f9b3a51..1c317919ca 100644 --- a/xen/common/sched/rt.c +++ b/xen/common/sched/rt.c @@ -216,6 +216,8 @@ struct rt_private { /* Sum of admitted units' (budget/period), scaled by RTDS_UTIL_SCALE */ uint64_t utilization; + + bool admission_control_enabled; /* on/off flag for admission control. */ }; /* @@ -409,6 +411,9 @@ rt_dump(const struct scheduler *ops) cap = (uint64_t)cpumask_weight(ops->cpupool->res_valid) * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100; + printk("Admission control: %s\n", + prv->admission_control_enabled ? "enabled" : "disabled"); + if ( cap ) printk("Utilization: %llu%% of capacity\n", (unsigned long long)(prv->utilization * 100 / cap)); @@ -694,8 +699,8 @@ rt_utilization_cap(const struct domain *d) /* * Replaces a unit's reservation and updates prv->utilization * to match. Growth that would push utilization over the - * cpupool's cap is refused. Removing a unit or shrinking - * a unit's reservation always succeed. + * cpupool's cap is refused if admission control is enabled. + * Removing a unit or shrinking a unit's reservation always succeed. */ static bool rt_try_set_utilization(struct rt_private *prv, const struct domain *d, @@ -706,7 +711,8 @@ rt_try_set_utilization(struct rt_private *prv, const struct domain *d, uint64_t new_util = rt_unit_utilization(new_period, new_budget); uint64_t total = prv->utilization - old_util + new_util; - if ( new_util > old_util && total > rt_utilization_cap(d) ) + if ( prv->admission_control_enabled && + new_util > old_util && total > rt_utilization_cap(d) ) return false; prv->utilization = total; @@ -773,6 +779,7 @@ rt_init(struct scheduler *ops) INIT_LIST_HEAD(&prv->runq); INIT_LIST_HEAD(&prv->depletedq); INIT_LIST_HEAD(&prv->replq); + prv->admission_control_enabled = true; ops->sched_data = prv; rc = 0; @@ -1565,8 +1572,14 @@ rt_dom_cntl( new_total = prv->utilization - dom_old_util + (uint64_t)nr_units * new_util; - if ( new_total > prv->utilization && new_total > rt_utilization_cap(d) ) + if ( prv->admission_control_enabled && + new_total > prv->utilization && new_total > rt_utilization_cap(d) ) { + printk(XENLOG_WARNING + "RTDS: ADMISSION CONTROL: refusing d%d," + " would exceed utilization capacity of the cpupool\n", + d->domain_id); + spin_unlock_irqrestore(&prv->lock, flags); rc = -ENOSPC; break; @@ -1631,6 +1644,11 @@ rt_dom_cntl( if ( !rt_try_set_utilization(prv, d, svc->period, svc->budget, period, budget) ) { + printk(XENLOG_WARNING + "RTDS: ADMISSION CONTROL: refusing vcpu %u of d%d," + " would exceed utilization capacity of the cpupool\n", + local_sched.vcpuid, d->domain_id); + spin_unlock_irqrestore(&prv->lock, flags); rc = -ENOSPC; break; @@ -1691,6 +1709,34 @@ rt_dom_cntl( return rc; } +#ifdef CONFIG_SYSCTL +static int cf_check +rt_sys_cntl(const struct scheduler *ops, + struct xen_sysctl_scheduler_op *sc) +{ + struct xen_sysctl_rtds_schedule *params = &sc->u.sched_rtds; + struct rt_private *prv = rt_priv(ops); + unsigned long flags; + + switch ( sc->cmd ) + { + case XEN_SYSCTL_SCHEDOP_putinfo: + spin_lock_irqsave(&prv->lock, flags); + prv->admission_control_enabled = params->admission_control_enabled; + spin_unlock_irqrestore(&prv->lock, flags); + break; + + case XEN_SYSCTL_SCHEDOP_getinfo: + spin_lock_irqsave(&prv->lock, flags); + params->admission_control_enabled = prv->admission_control_enabled; + spin_unlock_irqrestore(&prv->lock, flags); + break; + } + + return 0; +} +#endif + /* * The replenishment timer handler picks units * from the replq and does the actual replenishment. @@ -1791,6 +1837,9 @@ static const struct sched_ops sched_rtds_def = { .remove_unit = rt_unit_remove, .adjust = rt_dom_cntl, +#ifdef CONFIG_SYSCTL + .adjust_global = rt_sys_cntl, +#endif .pick_resource = rt_res_pick, .do_schedule = rt_schedule, diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index c7cd9b4eb0..63d0ee062b 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -814,6 +814,10 @@ struct xen_sysctl_credit2_schedule { uint32_t ratelimit_us; }; +struct xen_sysctl_rtds_schedule { + uint8_t admission_control_enabled; +}; + /* XEN_SYSCTL_scheduler_op */ /* Set or get info? */ #define XEN_SYSCTL_SCHEDOP_putinfo 0 @@ -828,6 +832,7 @@ struct xen_sysctl_scheduler_op { } sched_arinc653; struct xen_sysctl_credit_schedule sched_credit; struct xen_sysctl_credit2_schedule sched_credit2; + struct xen_sysctl_rtds_schedule sched_rtds; } u; }; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:10:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:10:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424867.1649115 (Exim 4.92) (envelope-from ) id 1x7Tfg-0003ry-FJ; Fri, 18 Sep 2026 08:10:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424867.1649115; Fri, 18 Sep 2026 08:10:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Tfg-0003rl-Ar; Fri, 18 Sep 2026 08:10:12 +0000 Received: by outflank-mailman (input) for mailman id 1424867; Fri, 18 Sep 2026 08:10:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Tff-0003pZ-Ia for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:10:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Tfe-00G512-VD for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:10:10 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacf1e2-bab6-0a2a0a5309dd-0a2a450ae726-4 for ; Fri, 18 Sep 2026 10:10:10 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacf1e2-f2d2-0a2a450a0019-4a7de14cf5ae-3 for ; Fri, 18 Sep 2026 10:10:10 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843cedd129so242736f8f.0 for ; Fri, 18 Sep 2026 01:10:10 -0700 (PDT) Received: from notebook.. ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48720083c19sm2174133f8f.31.2026.09.18.01.10.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 01:10:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789719010; x=1790323810; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=FHRsXuEnf7BCXLP3eamT1pJU7X7xpT0JlychFCHzOuM=; b=kH8A1dMV3DSmYf7vMFMIhA9Xc+cjJk0NOJvpiZdk03aMOfZuyjK1NDIy9nY/2GDLWT j1vY5CFDiKMKSc02beHBlT1h7pwsl5m7ZRdWaPKLF6wISGTe9o8SbT9PENHoB6BjemGV E/nM9Vl+Q8EkGytUQFNFE68q6RkEq0UQD2UnUXVWDFNP49evvvbqND4v80wFXeDGzCUO znD4sp00M0x8S0f0G9YvOg0dlCOW4mfIfIxJO7pesnCFBY6IlPmYc8DoHBsbxPpGAI10 75XUb/PV7qsqw7N//p33ZlFL1RNGRcKIy3fRIykyn21o7uXkmhpePDlYk0712h9hCHoM wasA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789719010; x=1790323810; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=FHRsXuEnf7BCXLP3eamT1pJU7X7xpT0JlychFCHzOuM=; b=Uc4gRZwidlbwASscGGVLPF0q5QY+k7tWkOe28/n70MkQgJ4Wzf/WCjmjUI9PiQ1G5H il4iuZM7hPscm902TiiiLDQBM7KQuWcVe49mOy1Dv1T89/rMoNG5YYIGfSufM7C1cP5s +Ybj2raMde2gUQi2IQk/LFuzSjoParsbgOwYH39hIqizEpWH6pb2lFLPEFbYkGGJvt2S 8F5TKSkHe2CBGNQSBnhbxlmMsGzpfl0LJ9YaEZwKYEpSZz5rKzAG9xITWeQaM4WN70SM GqCAVo3xfVyTKTlFOgvjCwmoxoJax+MsyB0fwtcPQvjbTXxn8ZM1VmkWI9boX6y3+XaF X+dQ== X-Gm-Message-State: AFuF++kKdgq+8M5beczm8q2v5KhRJkaF2FDnQ+BWwJt5QifbnFalLsYg 2xpuMwDGVRs0BBNiNG/Bk4HhgCPdrpv63MKEb+uq+NhDye336ms9k9foBebTLw== X-Gm-Gg: AYBFou3lCB18iNspFq0f4xwd88YL2QWcRRuALogpXKs5fsYm7hXnq4ZnMZ3Zt5plQvf 9dIZEhsoDSQcecU61/r39H/Pw8LS40lLVA2j5DrAxWHddsv6RL3N/qfhrPiQRPnKAykIoCVG3RR OSU2Xzv8PBNmKPpZXqXf++e7gCrH2a89cbx0D1RYrHXLwIdHf2mtZtvzW0RSOe2Ss1y7LWVMCnu Y97orzXVbc9vF+V9B7vegFKTkrzeqNEJNcapqdNORabLL2KhVBspLtdtNbIeJAIj+FR4pC+WJUr 8OOGfr52ziQdPPBDkPUtwTpl9iADXwgkKfFEz8Vru8N4mhqE+QezSICaqythqIdjeT40LIrFo1P 11no8K9iAZHi96PaBUjCJlF6M6XL7r0axjVm8kanmTO4WdPc6QdFFXEZww0EkGABDAG533DwS0X 6aK2Ihmatl/x+RRImMGWw7AhBkoFgLKgS0hGeN2k375nP3NqlcvgZoDlAuDNUVVpx53kfWZpM= X-Received: by 2002:a05:6000:4b06:b0:487:931:946c with SMTP id ffacd0b85a97d-4871e20cef1mr4744995f8f.1.1789719010064; Fri, 18 Sep 2026 01:10:10 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org, Furkan Caliskan Subject: [PATCH v2 5/5] tools: expose admission control toggle via xl sched-rtds Date: Fri, 18 Sep 2026 11:09:35 +0300 Message-Id: <20260918080935.35498-6-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260918080935.35498-1-frn1furkan10@gmail.com> References: <20260918080935.35498-1-frn1furkan10@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1789719010-52ADCCFC-781E7EAD/0/0 X-purgate-type: clean X-purgate-size: 16058 Wire the per-cpupool admission-control switch through libxl to xl sched-rtds, and document it. Add -s/--schedparam to list or set pool-wide RTDS scheduler parameters, and -a/--admission to enable or disable admission control for a cpupool ("-c pool -s -a 0/1"). Signed-off-by: Furkan Caliskan --- docs/man/xl.1.pod.in | 20 ++++++ tools/golang/xenlight/helpers.gen.go | 23 ++++++ tools/golang/xenlight/types.gen.go | 4 ++ tools/include/libxl.h | 4 ++ tools/include/xenctrl.h | 6 ++ tools/libs/ctrl/xc_rt.c | 40 +++++++++++ tools/libs/light/libxl_sched.c | 46 ++++++++++++ tools/libs/light/libxl_types.idl | 5 ++ tools/xl/xl_cmdtable.c | 8 ++- tools/xl/xl_sched.c | 103 +++++++++++++++++++++++++-- 10 files changed, 254 insertions(+), 5 deletions(-) diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index 88ccf7ad82..51405f4e33 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@ -1230,6 +1230,16 @@ the unreserved system resource. Restrict output to domains in the specified cpupool. +=item B<-s>, B<--schedparam> + +Specify to list or set pool-wide scheduler parameters. + +=item B<-a ADMISSION_CONTROL>, B<--admission=ADMISSION_CONTROL> + +Binary flag to enable or disable admission control for the cpupool. +When enabled (the default), a reservation is rejected if admitting +it would exceed the cpupool's utilization capacity. + =back B @@ -1293,6 +1303,16 @@ e.g., "xl sched-rtds -d vm1 -v 0 -p 100 -b 50 -e 1 -v 3 -p 300 -b 150 -e 0". To change the parameters of all the VCPUs of a domain, use B<-v all>, e.g., "xl sched-rtds -d vm1 -v all -p 500 -b 250 -e 1". +4) Use B<-c CPUPOOL -s> to see whether admission control is enabled +for a cpupool, and B<-c CPUPOOL -s -a> to change it: + + xl sched-rtds -c pool-rt -s + Cpupool pool-rt: sched=RTDS admission-control=enabled + + xl sched-rtds -c pool-rt -s -a 0 + xl sched-rtds -c pool-rt -s + Cpupool pool-rt: sched=RTDS admission-control=disabled + =back =back diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index b0c09da910..18ab0731ef 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -4192,6 +4192,29 @@ func (x *SchedCredit2Params) toC(xc *C.libxl_sched_credit2_params) (err error){x return nil } +// NewSchedRtdsParams returns an instance of SchedRtdsParams initialized with defaults. +func NewSchedRtdsParams() (*SchedRtdsParams, error) { +var ( +x SchedRtdsParams +xc C.libxl_sched_rtds_params) + +C.libxl_sched_rtds_params_init(&xc) + +if err := x.fromC(&xc); err != nil { +return nil, err } + +return &x, nil} + +func (x *SchedRtdsParams) fromC(xc *C.libxl_sched_rtds_params) error { + x.AdmissionControlEnabled = bool(xc.admission_control_enabled) + + return nil} + +func (x *SchedRtdsParams) toC(xc *C.libxl_sched_rtds_params) (err error){xc.admission_control_enabled = C.bool(x.AdmissionControlEnabled) + + return nil + } + // NewDomainRemusInfo returns an instance of DomainRemusInfo initialized with defaults. func NewDomainRemusInfo() (*DomainRemusInfo, error) { var ( diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index e0fd78ec03..897100d9b6 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -1231,6 +1231,10 @@ type SchedCredit2Params struct { RatelimitUs int } +type SchedRtdsParams struct { +AdmissionControlEnabled bool +} + type DomainRemusInfo struct { Interval int AllowUnsafe Defbool diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 7c098edab6..ff993c38b7 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -2797,6 +2797,10 @@ int libxl_sched_credit2_params_get(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit2_params *scinfo); int libxl_sched_credit2_params_set(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit2_params *scinfo); +int libxl_sched_rtds_params_get(libxl_ctx *ctx, uint32_t poolid, + libxl_sched_rtds_params *scinfo); +int libxl_sched_rtds_params_set(libxl_ctx *ctx, uint32_t poolid, + libxl_sched_rtds_params *scinfo); /* Scheduler Per-domain parameters */ diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h index 9f00d4a19d..6f4ea7ca62 100644 --- a/tools/include/xenctrl.h +++ b/tools/include/xenctrl.h @@ -897,6 +897,12 @@ int xc_sched_rtds_vcpu_get(xc_interface *xch, uint32_t domid, struct xen_domctl_schedparam_vcpu *vcpus, uint32_t num_vcpus); +int xc_sched_rtds_params_set(xc_interface *xch, + uint32_t cpupool_id, + struct xen_sysctl_rtds_schedule *schedule); +int xc_sched_rtds_params_get(xc_interface *xch, + uint32_t cpupool_id, + struct xen_sysctl_rtds_schedule *schedule); int xc_sched_arinc653_schedule_set( diff --git a/tools/libs/ctrl/xc_rt.c b/tools/libs/ctrl/xc_rt.c index 3cb3fbb923..fb3f567d4f 100644 --- a/tools/libs/ctrl/xc_rt.c +++ b/tools/libs/ctrl/xc_rt.c @@ -130,3 +130,43 @@ int xc_sched_rtds_vcpu_get(xc_interface *xch, return rc; } + +int xc_sched_rtds_params_set(xc_interface *xch, + uint32_t cpupool_id, + struct xen_sysctl_rtds_schedule *schedule) +{ + struct xen_sysctl sysctl = {}; + + sysctl.cmd = XEN_SYSCTL_scheduler_op; + sysctl.u.scheduler_op.cpupool_id = cpupool_id; + sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RTDS; + sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo; + + sysctl.u.scheduler_op.u.sched_rtds = *schedule; + + if ( do_sysctl(xch, &sysctl) ) + return -1; + + *schedule = sysctl.u.scheduler_op.u.sched_rtds; + + return 0; +} + +int xc_sched_rtds_params_get(xc_interface *xch, + uint32_t cpupool_id, + struct xen_sysctl_rtds_schedule *schedule) +{ + struct xen_sysctl sysctl = {}; + + sysctl.cmd = XEN_SYSCTL_scheduler_op; + sysctl.u.scheduler_op.cpupool_id = cpupool_id; + sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RTDS; + sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_getinfo; + + if ( do_sysctl(xch, &sysctl) ) + return -1; + + *schedule = sysctl.u.scheduler_op.u.sched_rtds; + + return 0; +} diff --git a/tools/libs/light/libxl_sched.c b/tools/libs/light/libxl_sched.c index 2d6635dae7..ae4379cf09 100644 --- a/tools/libs/light/libxl_sched.c +++ b/tools/libs/light/libxl_sched.c @@ -397,6 +397,52 @@ int libxl_sched_credit2_params_set(libxl_ctx *ctx, uint32_t poolid, return rc; } +int libxl_sched_rtds_params_get(libxl_ctx *ctx, uint32_t poolid, + libxl_sched_rtds_params *scinfo) +{ + struct xen_sysctl_rtds_schedule sparam; + int r, rc; + GC_INIT(ctx); + + r = xc_sched_rtds_params_get(ctx->xch, poolid, &sparam); + if (r < 0) { + LOGE(ERROR, "getting RTDS scheduler parameters"); + rc = ERROR_FAIL; + goto out; + } + + scinfo->admission_control_enabled = sparam.admission_control_enabled; + + rc = 0; +out: + GC_FREE; + return rc; +} + +int libxl_sched_rtds_params_set(libxl_ctx *ctx, uint32_t poolid, + libxl_sched_rtds_params *scinfo) +{ + struct xen_sysctl_rtds_schedule sparam; + int r, rc; + GC_INIT(ctx); + + sparam.admission_control_enabled = scinfo->admission_control_enabled; + + r = xc_sched_rtds_params_set(ctx->xch, poolid, &sparam); + if (r < 0) { + LOGE(ERROR, "Setting RTDS scheduler parameters"); + rc = ERROR_FAIL; + goto out; + } + + scinfo->admission_control_enabled = sparam.admission_control_enabled; + + rc = 0; +out: + GC_FREE; + return rc; +} + static int sched_credit2_domain_get(libxl__gc *gc, uint32_t domid, libxl_domain_sched_params *scinfo) { diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index a7893460f0..d3121ea277 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -1286,6 +1286,11 @@ libxl_sched_credit2_params = Struct("sched_credit2_params", [ ("ratelimit_us", integer), ], dispose_fn=None) +libxl_sched_rtds_params = Struct("sched_rtds_params", [ + ("admission_control_enabled", bool), + ], dispose_fn=None) + + libxl_domain_remus_info = Struct("domain_remus_info",[ ("interval", integer), ("allow_unsafe", libxl_defbool), diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c index 502244f683..e48d5c5edc 100644 --- a/tools/xl/xl_cmdtable.c +++ b/tools/xl/xl_cmdtable.c @@ -295,13 +295,19 @@ const struct cmd_spec cmd_table[] = { { "sched-rtds", &main_sched_rtds, 0, 1, "Get/set rtds scheduler parameters", - "[-d [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]] [-e[=Extratime]]]", + "[-d [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]] [-e[=Extratime]]]\n" + " [-c -s [-a[=ADMISSION_CONTROL]]]", "-d DOMAIN, --domain=DOMAIN Domain to modify\n" "-v VCPUID/all, --vcpuid=VCPUID/all VCPU to modify or output;\n" " Using '-v all' to modify/output all vcpus\n" "-p PERIOD, --period=PERIOD Period (us)\n" "-b BUDGET, --budget=BUDGET Budget (us)\n" "-e Extratime, --extratime=Extratime Extratime (1=yes, 0=no)\n" + "-c CPUPOOL, --cpupool=CPUPOOL Restrict output to domains in CPUPOOL\n" + "-s, --schedparam List or set pool-wide scheduler parameters\n" + "-a ADMISSION_CONTROL, --admission=ADMISSION_CONTROL\n" + " Enable or disable admission control for the cpupool\n" + " (1=enabled, 0=disabled); requires -s\n" }, { "domid", &main_domid, 0, 0, diff --git a/tools/xl/xl_sched.c b/tools/xl/xl_sched.c index 73cd7040cd..7257d1854b 100644 --- a/tools/xl/xl_sched.c +++ b/tools/xl/xl_sched.c @@ -246,6 +246,28 @@ static int sched_credit2_pool_output(uint32_t poolid) return 0; } +static int sched_rtds_params_set(int poolid, + libxl_sched_rtds_params *scinfo) +{ + if (libxl_sched_rtds_params_set(ctx, poolid, scinfo)) { + fprintf(stderr, "libxl_sched_rtds_params_set failed.\n"); + return 1; + } + + return 0; +} + +static int sched_rtds_params_get(int poolid, + libxl_sched_rtds_params *scinfo) +{ + if (libxl_sched_rtds_params_get(ctx, poolid, scinfo)) { + fprintf(stderr, "libxl_sched_rtds_params_get failed.\n"); + return 1; + } + + return 0; +} + static int sched_rtds_domain_output( int domid) { @@ -339,10 +361,15 @@ static int sched_rtds_vcpu_output_all(int domid, static int sched_rtds_pool_output(uint32_t poolid) { - char *poolname; + libxl_sched_rtds_params scparam; + char *poolname = libxl_cpupoolid_to_name(ctx, poolid); - poolname = libxl_cpupoolid_to_name(ctx, poolid); - printf("Cpupool %s: sched=RTDS\n", poolname); + if (sched_rtds_params_get(poolid, &scparam)) + printf("Cpupool %s: [sched params unavailable]\n", poolname); + else + printf("Cpupool %s: sched=RTDS admission-control=%s\n", + poolname, + scparam.admission_control_enabled ? "enabled" : "disabled"); free(poolname); return 0; @@ -715,6 +742,8 @@ int main_sched_credit2(int argc, char **argv) * -d [domid] -v [vcpuid 1] [params] -v [vcpuid 2] [params] ... : * Set per-VCPU params for domain * -d [domid] -v all [params] : Set all per-VCPU params for domain + * -c [cpupool] -s : List pool-wide scheduling parameters for cpupool + * -c [cpupool] -s -a [0|1] : Set admission control for cpupool */ int main_sched_rtds(int argc, char **argv) { @@ -736,7 +765,10 @@ int main_sched_rtds(int argc, char **argv) bool opt_b = false; bool opt_e = false; bool opt_v = false; + bool opt_s = false; + bool opt_a = false; bool opt_all = false; /* output per-dom parameters */ + bool admission_control = false; int opt, i, rc, r; static struct option opts[] = { {"domain", 1, 0, 'd'}, @@ -745,10 +777,12 @@ int main_sched_rtds(int argc, char **argv) {"extratime", 1, 0, 'e'}, {"vcpuid",1, 0, 'v'}, {"cpupool", 1, 0, 'c'}, + {"schedparam", 0, 0, 's'}, + {"admission", 1, 0, 'a'}, COMMON_LONG_OPTS }; - SWITCH_FOREACH_OPT(opt, "d:p:b:e:v:c", opts, "sched-rtds", 0) { + SWITCH_FOREACH_OPT(opt, "d:p:b:e:v:c:a:s", opts, "sched-rtds", 0) { case 'd': dom = optarg; break; @@ -801,6 +835,19 @@ int main_sched_rtds(int argc, char **argv) case 'c': cpupool = optarg; break; + case 's': + opt_s = true; + break; + case 'a': + if (strcmp(optarg, "0") && strcmp(optarg, "1")) + { + fprintf(stderr, "Invalid admission_control value.\n"); + r = EXIT_FAILURE; + goto out; + } + admission_control = strtol(optarg, NULL, 10); + opt_a = true; + break; } if (cpupool && (dom || opt_p || opt_b || opt_e || opt_v || opt_all)) { @@ -809,6 +856,11 @@ int main_sched_rtds(int argc, char **argv) r = EXIT_FAILURE; goto out; } + if (opt_s && (dom || opt_p || opt_b || opt_e || opt_v || opt_all)) { + fprintf(stderr, "-s cannot be combined with domain/VCPU options.\n"); + r = EXIT_FAILURE; + goto out; + } if (!dom && (opt_p || opt_b || opt_e || opt_v)) { fprintf(stderr, "Missing parameters.\n"); r = EXIT_FAILURE; @@ -831,6 +883,49 @@ int main_sched_rtds(int argc, char **argv) r = EXIT_FAILURE; goto out; } + if (opt_a && !opt_s) { + fprintf(stderr, "-a/--admission requires -s/--schedparam.\n"); + r = EXIT_FAILURE; + goto out; + } + + if (opt_s) + { + libxl_sched_rtds_params scparam; + uint32_t poolid = 0; + + if (cpupool) { + if (libxl_cpupool_qualifier_to_cpupoolid(ctx, cpupool, + &poolid, NULL) || + !libxl_cpupoolid_is_valid(ctx, poolid)) { + fprintf(stderr, "Unknown cpupool \'%s\'\n", cpupool); + r = EXIT_FAILURE; + goto out; + } + } + + if (!opt_a) { /* output pool-wide scheduling parameters */ + if (sched_rtds_pool_output(poolid)) { + r = EXIT_FAILURE; + goto out; + } + } else { /* set pool-wide scheduling parameters */ + if (sched_rtds_params_get(poolid, &scparam)) { + r = EXIT_FAILURE; + goto out; + } + + scparam.admission_control_enabled = admission_control; + + if (sched_rtds_params_set(poolid, &scparam)) { + r = EXIT_FAILURE; + goto out; + } + } + + r = EXIT_SUCCESS; + goto out; + } if ((!dom) && opt_all) { /* get all domain's per-vcpu rtds scheduler parameters */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:45:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:45:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424960.1649139 (Exim 4.92) (envelope-from ) id 1x7UDT-0002Od-5o; Fri, 18 Sep 2026 08:45:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424960.1649139; Fri, 18 Sep 2026 08:45:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UDT-0002OW-2x; Fri, 18 Sep 2026 08:45:07 +0000 Received: by outflank-mailman (input) for mailman id 1424960; Fri, 18 Sep 2026 08:45:05 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UDQ-0002OQ-Pq for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:45:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7UDP-00GBNl-Ub for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:45:03 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacf9fc-8faa-0a2a0a5109dd-0a2a4506cdca-46 for ; Fri, 18 Sep 2026 10:45:03 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacfa0e-195a-0a2a45060019-b9ff1c22b4d3-3 for ; Fri, 18 Sep 2026 10:45:02 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0b3b0c18000072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 18 Sep 2026 08:45:00 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id E4D56820E1; Fri, 18 Sep 2026 10:44:59 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=7jy0xTNRqgNKUDYhh+aSRoS48Toxky/Fb6QdDUlvdnQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=SLMgt/voJQ0o0PtRorkn+Y+vVA1ooN02MX8vbllvUJBGuakdKWuV+Y266TwwTjcl80xjgEoss A51F1WGbdD1hhcFoYEJ9XOu/KJ8mKE93vRtRp6T5qn9/rrRyJwXiPIBGLhr23/1oGgzUA00V2qj VHOnhl+8EtsYHf37FqbP8JhmfGXMXS+yE3DgcVLJM0WPgQwWFCeA2X3jBMdEw0UiBPW1ggKnhe/ wHB56EmEwKE+gnqvaofYiSeDomdZ1wO0Cz2cuLYZO/rgpkTAKLtYBcs9X9vx4l9tLriSQqTqJe8 D+6vjgOsWxKdL489cHF5Sw9VhCr3ZZVqQhhoxjHE63vA== X-Zone-Loop: 633e9b565c2e6551920da11f2a04d160ec16b36d772f x-campaign-type: default x-transaction-id: 726e4d17-f28c-41b8-b75d-51213537b2bb x-swg-uid: 01-af0af1b7-0fb3-4353-b42d-336e642ea682 X-Mailer: Sweego Message-ID: <1789721100.8631fc262581453bbf619ec5b2062170.1a0b3b0c18000072c4@vates.tech> x-swg-bid: 1789721100.8631fc262581453bbf619ec5b2062170.1a0b3b0c18000072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 23/39] xen/riscv: look up the exception table for any trap taken in Xen context From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Fri, 18 Sep 2026 10:44:52 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789721094; l=1765; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=RmMnfB4XxmKrTffUuXoweGsD8YT7e++sjPW9+OJLNZs=; b=B73cUk7TwHYnJasxV3VuafpIFlFdakB1rJFrJawelQKHF79FYtISqq5u202sDBbKwYm4QT9UM OKcrRYeHMUeDFV6U8RHt1H/cJR7Sp3fENZlj2V2oDsEJn9JyfV5ABIn X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789721100156 X-purgate-ID: tlsNG-16d1c6/1789721103-F7ACA77B-0BBC81A5/0/0 X-purgate-type: clean X-purgate-size: 1765 > do_trap() consulted the exception table only for CAUSE_ILLEGAL_INSTRUCTION, > which covers csr_read_safe() but not the hlv/hlvx sequences reading guest > memory: those fault with load/store (guest) page fault causes and would > reach do_unexpected_trap() instead of their fixup. > > Move the lookup ahead of the cause switch, and gate it on the trap having > been taken in Xen context and not being an interrupt: > > - sepc of a trap taken from the guest is a guest VA/PA, which the > guest can point at an address listed in the exception table; Xen would > then act on that entry and, for EX_TYPE_TRAP_INFO, write through a > pointer fully under guest control. Entries are matched by exact address, > so this needs no more than a numerical collision. > > - an interrupt taken at an address listed in the table would otherwise be > "fixed up" as if the access itself had faulted, silently skipping it and > handing the caller the interrupt's scause as a fault cause. > > Returning early skips check_for_pcpu_work(), which is correct: that only > runs for traps taken from the guest. > > With that in place a G-stage fault reaching the switch can no longer have > been caused by an hlv/hlvx covered by an entry, so anything left must have > come from the guest; assert as much. What means `assert as much` here? As you referencing any assert in the code, because in this patch, I couldn't find any. > > Cache the "trap came from the guest" test in a local, it is now used four > times. Nit: By reading this sentence, I would expect to have the introduction of `from_guest` local here instead of in patch cc2d3b97e8 xen/riscv: add guest page fault handling stub -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 18 08:45:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 08:45:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424961.1649147 (Exim 4.92) (envelope-from ) id 1x7UDY-0002bW-CU; Fri, 18 Sep 2026 08:45:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424961.1649147; Fri, 18 Sep 2026 08:45:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UDY-0002bP-9r; Fri, 18 Sep 2026 08:45:12 +0000 Received: by outflank-mailman (input) for mailman id 1424961; Fri, 18 Sep 2026 08:45:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x7UDW-0002b8-Ps for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 08:45:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7UDW-005NnV-6c for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:45:10 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacfa10-e002-0a2a0a5209dd-0a2a4506a144-10 for ; Fri, 18 Sep 2026 10:45:09 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacfa14-195a-0a2a45060019-b9ff1c23a1e5-3 for ; Fri, 18 Sep 2026 10:45:08 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0b3b0c3ad00072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 18 Sep 2026 08:45:01 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 5B8ED821ED; Fri, 18 Sep 2026 10:45:00 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=cB51r+lZrmiPfz+T3Gfa8J2oPhSh0gpzC4SIRfovPlc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=jrsK/EGBrHucTrIs+1eUtIGQ0pnwzrosVJ/4br/33JYMpwE8bQtNkFqsBzuSc3RLtTtfEIx34 zEz8g8Pr2Hqk7RxDkBvSxJFALZqyaiE86atlHYT2PCfBdmpidnOgdLyqJWQo/8Nq7A7U/kQOOty YI/QFFan5fOXv72UwkkqmPjbGtbOy3Qy9/gM0waL7M4OO7W2oYaTSHC3iVFhR1Wjmsjg3Mrkeg2 XD9K+tLTerfAuiNSK2eiOuYsoXugcPFUgWpsnIxBgvecA7oMrl/sNCnQDH6mtl1vaaOWR1KHNUR VJMRrugok8ruje0eQMZG1JIDDAk6VOr/efWcQbbhQkoA== X-Zone-Loop: 838f895215de527d5e6bda2e77c1bee5b38a7077956e x-campaign-type: default x-transaction-id: dadd2cb1-cf33-4e9b-b298-007b18a64040 x-swg-uid: 01-9023a72b-dff1-4074-954f-772a454d07cb X-Mailer: Sweego Message-ID: <1789721101.8631fc262581453bbf619ec5b2062170.1a0b3b0c3ad00072c4@vates.tech> x-swg-bid: 1789721101.8631fc262581453bbf619ec5b2062170.1a0b3b0c3ad00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 24/39] xen/riscv: add helpers for decoding a trapped load or store From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com> References: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 18 Sep 2026 10:44:52 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789721094; l=16982; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Dg2QiUp8Y1lpu0ImOFAoAE+mxFvJ5sseFP0IZrp5/SM=; b=Y1HmtScKXHDumUg3arsjOASHXNwGhqRhx73/mkyBWQDcJ4P6lEE/wCuQQAYGCy/+0Tdiu8kUb Bw5DhnAvt5XD3PsMb2xMn0lJWRN/dEGlsOMStQADiPX/rEs/lYZlFdI X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789721100586 X-purgate-ID: tlsNG-16d1c6/1789721108-F4C0777B-722D6683/10/73395122804 X-purgate-type: spam X-purgate-size: 16982 > emulate_load() and emulate_store() will both need to obtain the > instruction which caused a guest MMIO trap, decode it, and locate the > register operand it names. Add what the two share, ahead of either of > them being implemented: struct decoded_insn, insn_fetch_faulted(), > decode_ldst_insn(), guest_xlen(), guest_gpr() and advance_pc(). > > The mask/match chain is adapted from Linux's KVM RISC-V implementation. Nit: maybe you could add the Origin: trailer as mentioned in the sending-patches.adoc. > > Nothing calls any of this yet, so tag the functions __maybe_unused to > keep the build going; the tags go away once emulate_load() and > emulate_store() gain their bodies later. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c > index ff530ef2df..81a50643a5 100644 > --- a/xen/arch/riscv/emulate.c > +++ b/xen/arch/riscv/emulate.c > @@ -5,6 +5,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -13,9 +14,29 @@ > #include > #include > #include > +#include > +#include > #include > #include > > +/* > + * Determine the trapped load or store instruction which caused a guest MMIO > + * trap. > + */ > +struct decoded_insn { > + /* The instruction itself, and its length in bytes. */ > + unsigned long insn; > + unsigned int insn_len; > + /* Width of the memory access, in bytes. */ > + unsigned int len; > + /* Number of the register operand: rd for a load, rs2 for a store. */ > + unsigned int reg; > + /* The access is a store rather than a load. */ > + bool is_write; > + /* The load zero-extends its result rather than sign-extending it. */ > + bool is_unsigned; > +}; > + > /* > * The hardware-reported details of a guest page fault, gathered once by > * handle_guest_page_fault() and passed down to the emulation of the faulted > @@ -39,6 +60,71 @@ struct guest_fault { > paddr_t gpa; > }; > > +static bool is_load_guest_page_fault(unsigned long scause) > +{ > + return scause == CAUSE_LOAD_GUEST_PAGE_FAULT; > +} > + > +static __maybe_unused void advance_pc(struct cpu_user_regs *regs, > + unsigned int step) > +{ > + regs->sepc += step; > +} > + > +/* > + * The effective XLEN of the guest at the point of the trap: hstatus.VSXL for a > + * trap taken from VS-mode, vsstatus.UXL for one taken from VU-mode. > + * > + * VSXL is consulted whichever mode the trap came from, as it also gives the > + * width of vsstatus itself: where VSXL says 32, that register has no UXL field > + * to consult and VU-mode is 32-bit as well, there being nothing to configure. > + * > + * It is needed to decode a trapped instruction: the encodings which exist only > + * for XLEN=64 must not be recognized for a 32-bit guest. Besides those simply > + * being reserved there, the compressed ones are ambiguous: C.LD and C.FLW > + * share the encoding 0x6000 (mask 0xe003), and likewise C.SD/C.FSW, > + * C.LDSP/C.FLWSP and C.SDSP/C.FSWSP. > + * > + * IS_ENABLED() can't be used here as HSTATUS_VSXL is defined for > + * __riscv_xlen == 64 only, the field not existing on RV32 in the first place. > + */ > +static __maybe_unused unsigned int guest_xlen(const struct cpu_user_regs *regs) > +{ > +#ifdef CONFIG_RISCV_32 > + return 32; > +#else > + unsigned long xl = MASK_EXTR(regs->hstatus, HSTATUS_VSXL); > + > + if ( (xl == XLEN_FIELD_64) && !(regs->sstatus & SSTATUS_SPP) ) > + xl = MASK_EXTR(csr_read(CSR_VSSTATUS), SSTATUS64_UXL); > + > + switch ( xl ) > + { > + case XLEN_FIELD_32: > + return 32; > + > + case XLEN_FIELD_64: > + return 64; > + > + default: > + /* > + * The field holds nothing else in practice: XLEN_FIELD_128 would mean > + * RV128, which no implementation provides, and the only value left is > + * reserved. ASSERT_UNREACHABLE() being debug-only, a width still has > + * to be answered in release builds. > + * > + * Answer 32, that being the safe way to be wrong: the decoder then > + * fails to recognize the RV64-only encodings and emulation gives up. > + * Answering 64 for what may well be a 32-bit guest would instead have > + * it take C.FLW for C.LD and C.FSW for C.SD (see above), i.e. quietly > + * emulate an access of the wrong width against the wrong register. > + */ > + ASSERT_UNREACHABLE(); > + return 32; > + } > +#endif > +} > + > /* > * Is @htinst one of the pseudoinstructions reported for a guest page fault > * taken on an implicit memory access done for VS-stage address translation? > @@ -87,6 +173,250 @@ static void resolve_faulting_gpa(struct guest_fault *gf) > (htinst_is_pseudo(gf->htinst) ? 0 : (gf->stval & 3)); > } > > +/* > + * Where the value of a decoded instruction's register operand is held. > + * > + * Relies on x0..x31 being laid out at the start of struct cpu_user_regs in > + * architectural register-number order; see the comment there. > + */ > +static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs, > + unsigned int reg) > +{ > + ASSERT(reg < 32); > + > + return REG_PTR(reg, 0, regs); > +} > + > +/* > + * Obtain the instruction which caused a guest MMIO trap, filling in > + * @di->insn and @di->insn_len. It either comes transformed in htinst, or has > + * to be fetched from guest memory. > + * > + * Returns true if the fetch faulted in turn; the resulting trap has then > + * already been redirected to the guest and there is nothing further for the > + * caller to do. Where it returns false, @di has been filled in and emulation > + * is to continue. > + */ > +static bool __maybe_unused insn_fetch_faulted(const struct guest_fault *gf, > + struct decoded_insn *di) > +{ > + unsigned long htinst = gf->htinst; > + > + /* > + * A pseudoinstruction says nothing about the instruction the guest was > + * executing, and comes with a guest physical address which isn't the one > + * that instruction accessed. handle_guest_page_fault() deals with such a > + * fault on its own, so no emulation can ever start for one. > + */ > + ASSERT(!htinst_is_pseudo(htinst)); > + > + if ( htinst & BIT(0, UL) ) > + { > + /* > + * Bit[0] == 1 implies trapped instruction value is > + * transformed instruction or custom instruction. > + * > + * The transformation always yields the 32-bit format, with bits[1:0] > + * holding a marker instead of the original opcode bits: bit[0] set to > + * flag the transformation, bit[1] clear if the trapped instruction > + * was a compressed one. Restoring the opcode bits makes the value the > + * valid 32-bit encoding decode_ldst_insn() matches against. Its > + * INSN_MASK_C_* cases exist for the branch below, where a compressed > + * instruction is read from guest memory as is: a trapped one arrives > + * here already expanded to its 32-bit equivalent, and the opcode bits > + * just restored keep it from matching those cases anyway. > + * > + * The length then cannot come from the value anymore, only from > + * bit[1]. And only a 16- or a 32-bit instruction is ever reported > + * this way: the standard load and store instructions the hardware > + * transforms are all of one of these two lengths, anything else comes > + * as the zero special value handled below. > + */ > + di->insn = htinst | INSN_16BIT_MASK; > + di->insn_len = (htinst & BIT(1, UL)) ? 4 : 2; > + } > + else > + { > + const struct cpu_user_regs *regs = gf->regs; > + struct trap_info utrap = {}; > + > + /* > + * Bit[0] == 0 implies trapped instruction value is > + * zero or special value. With the pseudoinstructions ruled out > + * above, only zero is left: the instruction has to be read from > + * guest memory. > + */ > + > + di->insn = riscv_read_guest(regs->sepc, true, &utrap); > + if ( utrap.scause ) > + { > + /* > + * If during getting of trapped instruction a fault happen in > + * G-stage translation then CAUSE_LOAD_GUEST_PAGE_FAULT is > + * generated. Such faults during this operation is considered as > + * bus error. > + */ > + if ( is_load_guest_page_fault(utrap.scause) ) > + utrap.scause = CAUSE_FETCH_ACCESS; > + > + utrap.sepc = regs->sepc; > + > + trap_redirect(&utrap); > + > + return true; > + } > + > + /* > + * riscv_read_guest() fetches at most two halfwords, so a wider > + * encoding has been read in part only and cannot be decoded here. > + * > + * Report an illegal instruction, which is what the guest would have > + * got for such an encoding anyway: the ISA defines no instruction > + * wider than 32 bits. > + */ > + if ( !INSN_IS_16BIT(di->insn) && !INSN_IS_32BIT(di->insn) ) > + { > + utrap.sepc = regs->sepc; > + utrap.scause = CAUSE_ILLEGAL_INSTRUCTION; > + /* > + * stval is left zero: the spec allows that for an illegal > + * instruction, and only part of the instruction is in hand. > + */ > + > + trap_redirect(&utrap); > + > + return true; > + } > + > + di->insn_len = INSN_LEN(di->insn); > + } > + > + return false; > +} > + > +/* > + * Decode the load or store instruction fetched into @di, filling in the > + * remaining fields of it (@di->insn and @di->insn_len are filled by > + * insn_fetch_faulted()). > + * > + * @xlen is the effective XLEN of the guest, needed as > + * the encodings which exist for XLEN=64 only must not be recognized for a > + * 32-bit guest. > + * > + * Returns false if the instruction is not a load or store which can be > + * emulated here. > + */ > +static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di, > + unsigned int xlen) > +{ > + unsigned long insn = di->insn; > + /* Register fields of the uncompressed forms ... */ > + unsigned int rd = RV_RD(insn); > + unsigned int rs2 = RV_RS2(insn); > + /* > + * ... and of the compressed ones, where the 3-bit field selects one of > + * x8..x15, while the stack-pointer-relative forms have a full-width one. > + */ > + unsigned int rs2s = RVC_RS2S(insn); > + unsigned int rs2c = RVC_RS2(insn); > + This naming are confusing because above you described di->reg to be rd for load and rs2 for store but here ... > + di->is_write = false; > + di->is_unsigned = false; > + di->reg = rd; > + > + if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB ) > + di->len = 1; > + else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU ) > + { > + di->len = 1; > + di->is_unsigned = true; > + } > + else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH ) > + di->len = 2; > + else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU ) > + { > + di->len = 2; > + di->is_unsigned = true; > + } > + else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW ) > + di->len = 4; > + else if ( xlen == 64 && (insn & INSN_MASK_LWU) == INSN_MATCH_LWU ) > + { > + di->len = 4; > + di->is_unsigned = true; > + } > + else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW ) > + { > + di->len = 4; > + di->reg = rs2s; ... you assigned rs2s for a load. According to the spec, it should be rd'. I would suggest something generic to load and store. Maybe rxs with a comment to explain it concerns rs2' for store and rd' for load. /* * ... and of the compressed ones, where the 3-bit field selects one of * x8..x15, while the stack-pointer-relative forms have a full-width one. * rxs is named after that field's spec mnemonic, rd'/rs2': rd' for * compressed loads, rs2' for compressed stores. */ unsigned int rxs = RVC_RS2S(insn); > + } > + /* c.lwsp and c.ldsp are reserved with rd being x0. */ > + else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP && rd ) > + di->len = 4; > + else if ( xlen == 64 && (insn & INSN_MASK_LD) == INSN_MATCH_LD ) > + di->len = 8; > + else if ( xlen == 64 && (insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD ) > + { > + di->len = 8; > + di->reg = rs2s; > + } > + else if ( xlen == 64 && (insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP && > + rd ) > + di->len = 8; > + else if ( (insn & INSN_MASK_SB) == INSN_MATCH_SB ) > + { > + di->len = 1; > + di->is_write = true; > + di->reg = rs2; > + } > + else if ( (insn & INSN_MASK_SH) == INSN_MATCH_SH ) > + { > + di->len = 2; > + di->is_write = true; > + di->reg = rs2; > + } > + else if ( (insn & INSN_MASK_SW) == INSN_MATCH_SW ) > + { > + di->len = 4; > + di->is_write = true; > + di->reg = rs2; > + } > + else if ( (insn & INSN_MASK_C_SW) == INSN_MATCH_C_SW ) > + { > + di->len = 4; > + di->is_write = true; > + di->reg = rs2s; > + } > + else if ( (insn & INSN_MASK_C_SWSP) == INSN_MATCH_C_SWSP ) > + { > + di->len = 4; > + di->is_write = true; > + di->reg = rs2c; > + } > + else if ( xlen == 64 && (insn & INSN_MASK_SD) == INSN_MATCH_SD ) > + { > + di->len = 8; > + di->is_write = true; > + di->reg = rs2; > + } > + else if ( xlen == 64 && (insn & INSN_MASK_C_SD) == INSN_MATCH_C_SD ) > + { > + di->len = 8; > + di->is_write = true; > + di->reg = rs2s; > + } > + else if ( xlen == 64 && (insn & INSN_MASK_C_SDSP) == INSN_MATCH_C_SDSP ) > + { > + di->len = 8; > + di->is_write = true; > + di->reg = rs2c; > + } > + else > + return false; > + > + return true; > +} > + > static int emulate_load(const struct guest_fault *gf) > { > return -EOPNOTSUPP; > diff --git a/xen/arch/riscv/include/asm/guest_access.h b/xen/arch/riscv/include/asm/guest_access.h > index 8d679319de..39c28dd2ec 100644 > --- a/xen/arch/riscv/include/asm/guest_access.h > +++ b/xen/arch/riscv/include/asm/guest_access.h > @@ -5,6 +5,7 @@ > #include > > struct domain; > +struct trap_info; > > unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len); > unsigned long raw_copy_from_guest(void *to, const void *from, unsigned len); > @@ -25,6 +26,9 @@ unsigned long raw_clear_guest(void *to, unsigned int len); > unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, > unsigned long len); > > +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, > + struct trap_info *trap); > + > #endif /* ASM__RISCV__GUEST_ACCESS_H */ > /* > * Local variables: > diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h > index b2071f4758..656a5fcccb 100644 > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -65,6 +65,14 @@ > #define SSTATUS64_UXL MSTATUS_UXL > #define SSTATUS64_SD MSTATUS64_SD > > +/* > + * Width encoded by the MXL, SXL, UXL and VSXL fields, all of which share one > + * encoding. 0 is reserved. > + */ > +#define XLEN_FIELD_32 _UL(1) > +#define XLEN_FIELD_64 _UL(2) > +#define XLEN_FIELD_128 _UL(3) > + > #if __riscv_xlen == 64 > #define HSTATUS_VSXL _UL(0x300000000) > #define HSTATUS_VSXL_SHIFT 32 > @@ -896,6 +904,8 @@ > (RV_X(x, 7, 2) << 6)) > #define RVC_SDSP_IMM(x) ((RV_X(x, 10, 3) << 3) | \ > (RV_X(x, 7, 3) << 6)) > +#define RV_RD(insn) RV_X(insn, SH_RD, 5) > +#define RV_RS2(insn) RV_X(insn, SH_RS2, 5) Nit: format -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:07:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:07:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1424986.1649158 (Exim 4.92) (envelope-from ) id 1x7UYm-0006EI-72; Fri, 18 Sep 2026 09:07:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1424986.1649158; Fri, 18 Sep 2026 09:07:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UYm-0006E7-2a; Fri, 18 Sep 2026 09:07:08 +0000 Received: by outflank-mailman (input) for mailman id 1424986; Fri, 18 Sep 2026 09:07:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UYk-0006E1-5j for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:07:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7UYi-00GDL7-2S for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:07:04 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacff2b-8faa-0a2a0a5109dd-0a2a4501bd44-16 for ; Fri, 18 Sep 2026 11:07:03 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacff37-5984-0a2a45010019-4a7de18dce96-3 for ; Fri, 18 Sep 2026 11:07:03 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7d2bb404so1495525e9.1 for ; Fri, 18 Sep 2026 02:07:03 -0700 (PDT) Received: from [172.18.88.57] (195-200-20-130.mclarenap.oninferno.net. [195.200.20.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd204d89sm164994375e9.3.2026.09.18.02.07.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 02:07:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789722423; x=1790327223; darn=lists.xenproject.org; h=content-type: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:content-type; bh=ouDNE0rDoiixgMyNSmCiJpla05ZJvb0lVlXPtaxqtkI=; b=dlB0hGmnQyOMzYTKUoR74MWi1VwYUs7bqr+sTiXmNZryXrX5YP96ptyBuAEhqUbOKj KUBFQTztjPuZ9lyOE2Z1fkKUmNRMANsGUrIiNl0phclW/FI93JLBtyxsupk/YJiX32kf QDunCF+9eDAJ/oU+lNOpxUMC4spxieD541MZlOsrAXta3O3PGtTvVbcyIwqYASMl8Bxg KTZGU74ggFbnHoZ0MAGT56oaFNPMjNesqQDH0QAK7BrvbYQFfIoRgSNuFQIoLg8j1NCK iGT3wl5Ba2k+zVI6co3zvK6mIQ2Byh/Tp3WnddU1fuIP+BGegdVAxHNutDzpOtlxcyMh 6TNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789722423; x=1790327223; h=content-type: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 :content-type; bh=ouDNE0rDoiixgMyNSmCiJpla05ZJvb0lVlXPtaxqtkI=; b=1zM1cE0IlQCsWfLIh4zu17lIoXqHsn85OYOmPqodVcZhVSDl9LV/X/OHOjEGkVSHLR yyS12m2QGCkJ1milQK6Pd34SdzlCGJY/0G5sREfNywO/A7B32tBAUB42m3L0f0OAHpq+ yR+E3esQAus+e3uoI4sNyRefZufT8GlBFb6LP1pep8wonr7J9pbgp7WrfEQPzV2b5Q7D JSLiIhhW1voQ1IaoAfjtx58aXy+VbPtXbDTGj42immqEh6ildPknH6YjwWT/E6SQ9aO1 dIIPz7sVSl0H0vX0ZeP3d+j9GRceIBFDJnkOPgXV0QyHnLoPFQ1zzff3Yo9dbc9Jvb7x zFLA== X-Forwarded-Encrypted: i=1; AKwUvBzfoQDh6TOJCddTDk1FA+vn8mR90OrPVYIKt/jxF10zN/wRy8usUGI+xa4Khtx6AFtvWZvxzRKtBTk=@lists.xenproject.org X-Gm-Message-State: AFuF++mPjdh+Bg3O1PMMn1BK3QhEfBeeqwyboa471ofZ2cw+wwbEkCcn EqGsWdIZmd3BubtDil3qiDKK8HjVp5YeoGjLeUDQlS9qZuX3z0jIEh/PVJYsvWapRr8= X-Gm-Gg: AYBFou0yxWbzKbUkzLeu1adlx+fhUo8L+ZHQUyGFrGJxKBC1cmpOrjli14jAntsq1aU 5uyMraNK1146KKHO19P4GG2vCzm6gbX9tbdhjG1Xp56TDGB7Xd5JV6RdXBAEOQHfpEeVmcTaLHL zI+P6CUjkYVFH9TY0SKLvXQNs19Z8Kihm+77CWbmF7DjASkteaW8VbuwNj07zi7tLj/6QuXiLJK qtLwfMU/huJ3fTKjwiyenEliYk7kkw5EugxlrrXik8lEgOCH0eagapTiD5ClunNNm1j9FIgGNuT js0bd4TnmcD8pZn+nd9SnTZSK8ihVgaWuw7vjoLS8VK7HnX3pBwADhlFv1lSws2c6xjeKCHy5R3 EcRwLMD+Yly+SPC0lShmAqGLzFVVDvJkfiZ0NpW5WyJk6FA/AbUZscHpEit1Xs+Zg2Fys2csUgS uTbPBf+glKjv1C96Du/8C5M6zCKBiEaaZlITapXPQ/R9Y4Agg38Ao9KGd1Mo50OLBasnjMd0Trb 8WQtI/MjNMpTeTemVGQQhbjUHUgKc8RJyMT5kA= X-Received: by 2002:a05:600c:83c9:b0:49c:f13e:e4d with SMTP id 5b1f17b1804b1-49fc4ff402cmr24978935e9.10.1789722423006; Fri, 18 Sep 2026 02:07:03 -0700 (PDT) Message-ID: <3fe03cde-a614-48e2-920a-3116661e886b@suse.com> Date: Fri, 18 Sep 2026 11:06:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org References: <20260918080935.35498-1-frn1furkan10@gmail.com> <20260918080935.35498-2-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260918080935.35498-2-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------cGS3MeBSQi3ObU09OPpPdfhb" X-purgate-ID: tlsNG-d62444/1789722423-BCF47757-97E33486/35/110847 X-purgate-type: clean X-purgate-size: 18566 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------cGS3MeBSQi3ObU09OPpPdfhb Content-Type: multipart/mixed; boundary="------------nXGT6hNqYecyPk5f5l73YXw0"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org Message-ID: <3fe03cde-a614-48e2-920a-3116661e886b@suse.com> Subject: Re: [PATCH v2 1/5] xen/sched: rtds: add global-EDF utilization admission control References: <20260918080935.35498-1-frn1furkan10@gmail.com> <20260918080935.35498-2-frn1furkan10@gmail.com> In-Reply-To: <20260918080935.35498-2-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------nXGT6hNqYecyPk5f5l73YXw0 Content-Type: multipart/mixed; boundary="------------nl82mkcGPkkA8mDEZQKYRBzm" --------------nl82mkcGPkkA8mDEZQKYRBzm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTguMDkuMjYgMTA6MDksIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gUlREUyBoYXMg bm8gYWRtaXNzaW9uIGNvbnRyb2w6IG5vdGhpbmcgc3RvcHMgdGhlIHN1bSBvZiBhbGwgYWRt aXR0ZWQNCj4gdW5pdHMnIChidWRnZXQvcGVyaW9kKSByZXNlcnZhdGlvbnMgaW4gYSBjcHVw b29sIGZyb20gZXhjZWVkaW5nDQo+IHdoYXQgaXRzIHBDUFVzIGNhbiBhY3R1YWxseSBwcm92 aWRlLiBPbmNlIHRoYXQgaGFwcGVucywgbm9uZSBvZiB0aGUNCj4gRURGIGRlYWRsaW5lIGd1 YXJhbnRlZXMgdGhpcyBzY2hlZHVsZXIgaXMgYnVpbHQgYXJvdW5kIHN0aWxsIGhvbGQNCj4g Zm9yIHRoZSB1bml0cyBzaGFyaW5nIHRoYXQgcG9vbC4NCj4gDQo+IEludHJvZHVjZSBhZG1p c3Npb24gY29udHJvbCB0byBwcmV2ZW50IHRoaXM6IHJlamVjdCBhIHJlc2VydmF0aW9uDQo+ IHdoZW5ldmVyIGFkbWl0dGluZyBpdCB3b3VsZCBwdXNoIGEgY3B1cG9vbCdzIHVuaXRzIG92 ZXIgaXRzIGNhcGFjaXR5Lg0KPiBUcmFjayBhIHJ1bm5pbmcgdXRpbGl6YXRpb24gdG90YWwg cGVyIGNwdXBvb2wsIGFuZCBlbmZvcmNlIGl0IGluDQo+IHJ0X2FsbG9jX3VkYXRhKCkvcnRf ZnJlZV91ZGF0YSgpLCB0aGUgcGFpcmVkIGxpZmVjeWNsZSBob29rcyBmb3IgYQ0KPiB1bml0 J3MgY3JlYXRpb24gYW5kIGRlc3RydWN0aW9uLiBUaGlzIGNhdGNoZXMgdGhlIGRlZmF1bHQN Cj4gcGVyaW9kL2J1ZGdldCBldmVyeSBuZXcgdW5pdCBnZXRzLg0KPiANCj4gVXRpbGl6YXRp b24gaXMgcmVwcmVzZW50ZWQgYXMgYSBmaXhlZC1wb2ludCB2YWx1ZTogYnVkZ2V0IGlzDQo+ IGxlZnQgc2hpZnRlZCBieSBSVERTX1VUSUxfU0hJRlQgKDIwIGJpdHMpIGFuZCBkaXZpZGVk IGJ5IHBlcmlvZC4NCj4gQSBwbGFpbiAiKGJ1ZGdldCA8PCBSVERTX1VUSUxfU0hJRlQpIC8g cGVyaW9kIiByaXNrcyBvdmVyZmxvd2luZw0KPiB0aGUgbXVsdGlwbHkgZm9yIGxhcmdlIGVu b3VnaCBidWRnZXRzLiBSYXRoZXIgdGhhbiB3aWRlbiB0aGUNCj4gYXJpdGhtZXRpYyB0byB0 b2xlcmF0ZSBhbnkgaW5wdXQsIHRoZSBpbnB1dCBpdHNlbGYgaXMgYm91bmRlZDoNCj4gcnRf dmFsaWRhdGVfcGFyYW1zKCkgcmVqZWN0cyBhbnkgYnVkZ2V0IGFib3ZlIFJURFNfTUFYX0JV REdFVCwNCj4gY2hvc2VuIGFzIHRoZSBsYXJnZXN0IHZhbHVlIHRoYXQgY2FuIGJlIGxlZnQt c2hpZnRlZCBieQ0KPiBSVERTX1VUSUxfU0hJRlQgd2l0aG91dCBvdmVyZmxvd2luZyA2NCBi aXRzLCBzbyB0aGUgc2hpZnQgaW4NCj4gcnRfdW5pdF91dGlsaXphdGlvbigpIGNhbiBuZXZl ciBvdmVyZmxvdy4NCj4gDQo+IEEgY3B1cG9vbCdzIGNhcGFjaXR5IHJ0X3V0aWxpemF0aW9u X2NhcCgpIHNjYWxlcyB3aXRoIHRoZSBudW1iZXIgb2YNCj4gc2NoZWR1bGluZyByZXNvdXJj ZXMgaW4gaXQuIEl0IGlzIGNhbGN1bGF0ZWQgYXM6DQo+IChudW1iZXIgb2Ygc2NoZWRfcmVz b3VyY2VzICogUlREU19VVElMX1NDQUxFICogUlREU19VVElMX0NBUF9QQ1QgLyAxMDApLA0K PiB3aGVyZSBSVERTX1VUSUxfQ0FQX1BDVCBjb250cm9scyBob3cgbXVjaCBvZiB0aGF0IGNh cGFjaXR5IGNhbg0KPiBhY3R1YWxseSBiZSByZXNlcnZlZDsgYXQgMTAwJSAoaXRzIGN1cnJl bnQgdmFsdWUpLCBhbGwgb2YgaXQgY2FuIGJlLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogRnVy a2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21haWwuY29tPg0KPiAtLS0NCj4gdjI6DQo+ ICAgLSBSZW5hbWVkIHJ0X2FkbWlzc2lvbl90ZXN0KCkgdG8gcnRfdHJ5X3NldF91dGlsaXph dGlvbigpIGFuZCBjaGFuZ2VkDQo+ICAgICBpdHMgcmV0dXJuIHR5cGUgZnJvbSBpbnQgdG8g Ym9vbCwgc2luY2UgaXQgZG9lc24ndCBqdXN0IHRlc3QgYnV0DQo+ICAgICBhbHNvIGNvbW1p dHMgdGhlIG5ldyB1dGlsaXphdGlvbiBvbiBzdWNjZXNzLg0KPiAtLS0NCj4gICB4ZW4vY29t bW9uL3NjaGVkL3J0LmMgfCAxMDUgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKystDQo+ICAgMSBmaWxlIGNoYW5nZWQsIDEwNCBpbnNlcnRpb25zKCspLCAxIGRl bGV0aW9uKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9zY2hlZC9ydC5jIGIv eGVuL2NvbW1vbi9zY2hlZC9ydC5jDQo+IGluZGV4IDBlOWYwNGVhNzIuLmFjZWJiYmU1N2Ug MTAwNjQ0DQo+IC0tLSBhL3hlbi9jb21tb24vc2NoZWQvcnQuYw0KPiArKysgYi94ZW4vY29t bW9uL3NjaGVkL3J0LmMNCj4gQEAgLTExNCw2ICsxMTQsMjQgQEANCj4gICAgKi8NCj4gICAj ZGVmaW5lIFJURFNfTUFYX1BSSU9SSVRZX0xFVkVMICh+MFUpDQo+ICAgDQo+ICsvKg0KPiAr ICogRml4ZWQtcG9pbnQgc2NhbGUgZm9yIHV0aWxpemF0aW9uIChidWRnZXQvcGVyaW9kKQ0K PiArICovDQo+ICsjZGVmaW5lIFJURFNfVVRJTF9TSElGVCAgICAgMjANCj4gKyNkZWZpbmUg UlREU19VVElMX1NDQUxFICAgICAoMVVMTCA8PCBSVERTX1VUSUxfU0hJRlQpDQo+ICsNCj4g Ky8qDQo+ICsgKiBMYXJnZXN0IGJ1ZGdldCBzYWZlIHRvIGxlZnQtc2hpZnQgYnkgUlREU19V VElMX1NISUZUIHdpdGhvdXQNCj4gKyAqIG92ZXJmbG93aW5nIDY0IGJpdHMuIEVuZm9yY2Vk IGluIHJ0X3ZhbGlkYXRlX3BhcmFtcygpLg0KPiArICovDQo+ICsjZGVmaW5lIFJURFNfTUFY X0JVREdFVF9CSVRTICAoNjQgLSBSVERTX1VUSUxfU0hJRlQpDQo+ICsjZGVmaW5lIFJURFNf TUFYX0JVREdFVCAgICAgICAoKDFVTEwgPDwgUlREU19NQVhfQlVER0VUX0JJVFMpIC0gMSkN Cj4gKw0KPiArLyoNCj4gKyAqICUgb2YgYSBjcHVwb29sJ3Mgc2NoZWRfcmVzb3VyY2UgY2Fw YWNpdHkgYWRtaXR0ZWQgdW5pdHMgbWF5IHN1bSB1cCB0by4NCj4gKyAqLw0KPiArI2RlZmlu ZSBSVERTX1VUSUxfQ0FQX1BDVCAgIDEwMA0KPiArDQo+ICAgLyoNCj4gICAgKiBVUERBVEVf TElNSVRfU0hJRlQ6IGEgY29uc3RhbnQgdXNlZCBpbiBydF91cGRhdGVfZGVhZGxpbmUoKS4g V2hlbiBmaW5kaW5nDQo+ICAgICogdGhlIG5leHQgZGVhZGxpbmUsIHBlcmZvcm1pbmcgYWRk aXRpb24gY291bGQgYmUgZmFzdGVyIGlmIHRoZSBkaWZmZXJlbmNlDQo+IEBAIC0xOTUsNiAr MjEzLDkgQEAgc3RydWN0IHJ0X3ByaXZhdGUgew0KPiAgICAgICBzdHJ1Y3QgbGlzdF9oZWFk IHJlcGxxOyAgICAgLyogb3JkZXJlZCBsaXN0IG9mIHVuaXRzIHRoYXQgbmVlZCByZXBsZW5p c2htZW50ICovDQo+ICAgDQo+ICAgICAgIGNwdW1hc2tfdCB0aWNrbGVkOyAgICAgICAgICAv KiBjcHVzIGJlZW4gdGlja2xlZCAqLw0KPiArDQo+ICsgICAgLyogU3VtIG9mIGFkbWl0dGVk IHVuaXRzJyAoYnVkZ2V0L3BlcmlvZCksIHNjYWxlZCBieSBSVERTX1VUSUxfU0NBTEUgKi8N Cj4gKyAgICB1aW50NjRfdCB1dGlsaXphdGlvbjsNCj4gICB9Ow0KPiAgIA0KPiAgIC8qDQo+ IEBAIC02MzUsNiArNjU2LDU0IEBAIHJlcGxxX3JlaW5zZXJ0KGNvbnN0IHN0cnVjdCBzY2hl ZHVsZXIgKm9wcywgc3RydWN0IHJ0X3VuaXQgKnN2YykNCj4gICAgICAgICAgIHNldF90aW1l cigmcnRfcHJpdihvcHMpLT5yZXBsX3RpbWVyLCByZWFybV9zdmMtPmN1cl9kZWFkbGluZSk7 DQo+ICAgfQ0KPiAgIA0KPiArLyoNCj4gKyAqIGJ1ZGdldCA8PCBSVERTX1VUSUxfU0hJRlQg Y2FuJ3Qgb3ZlcmZsb3c6IHJ0X3ZhbGlkYXRlX3BhcmFtcygpDQo+ICsgKiBjYXBzIGJ1ZGdl dCBhdCBSVERTX01BWF9CVURHRVQuIHBlcmlvZCA9PSAwIG1lYW5zICJubw0KPiArICogcmVz ZXJ2YXRpb24iIChhIHVuaXQgYmVpbmcgcmVtb3ZlZCksIG5vdCBhbiBlcnJvci4NCj4gKyAq Lw0KPiArc3RhdGljIHVpbnQ2NF90DQo+ICtydF91bml0X3V0aWxpemF0aW9uKHNfdGltZV90 IHBlcmlvZCwgc190aW1lX3QgYnVkZ2V0KQ0KPiArew0KPiArICAgIGlmICggcGVyaW9kIDw9 IDAgKQ0KPiArICAgICAgICByZXR1cm4gMDsNCj4gKw0KPiArICAgIHJldHVybiAoKHVpbnQ2 NF90KWJ1ZGdldCA8PCBSVERTX1VUSUxfU0hJRlQpIC8gKHVpbnQ2NF90KXBlcmlvZDsNCj4g K30NCj4gKw0KPiArLyoNCj4gKyAqIFV0aWxpemF0aW9uIGNhcGFjaXR5IG9mIHRoZSBjcHVw b29sIGRvbWFpbiBkIHJlc2lkZXMgaW4uDQo+ICsgKi8NCj4gK3N0YXRpYyB1aW50NjRfdA0K PiArcnRfdXRpbGl6YXRpb25fY2FwKGNvbnN0IHN0cnVjdCBkb21haW4gKmQpDQo+ICt7DQo+ ICsgICAgdW5zaWduZWQgaW50IGNwdXMgPSBjcHVtYXNrX3dlaWdodChjcHVwb29sX2RvbWFp bl9tYXN0ZXJfY3B1bWFzayhkKSk7DQo+ICsNCj4gKyAgICByZXR1cm4gKHVpbnQ2NF90KWNw dXMgKiBSVERTX1VUSUxfU0NBTEUgKiBSVERTX1VUSUxfQ0FQX1BDVCAvIDEwMDsNCj4gK30N Cj4gKw0KPiArLyoNCj4gKyAqIFJlcGxhY2VzIGEgdW5pdCdzIHJlc2VydmF0aW9uIGFuZCB1 cGRhdGVzIHBydi0+dXRpbGl6YXRpb24NCj4gKyAqIHRvIG1hdGNoLiBHcm93dGggdGhhdCB3 b3VsZCBwdXNoIHV0aWxpemF0aW9uIG92ZXIgdGhlDQo+ICsgKiBjcHVwb29sJ3MgY2FwIGlz IHJlZnVzZWQuIFJlbW92aW5nIGEgdW5pdCBvciBzaHJpbmtpbmcNCj4gKyAqIGEgdW5pdCdz IHJlc2VydmF0aW9uIGFsd2F5cyBzdWNjZWVkLg0KPiArICovDQo+ICtzdGF0aWMgYm9vbA0K PiArcnRfdHJ5X3NldF91dGlsaXphdGlvbihzdHJ1Y3QgcnRfcHJpdmF0ZSAqcHJ2LCBjb25z dCBzdHJ1Y3QgZG9tYWluICpkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICBzX3RpbWVf dCBvbGRfcGVyaW9kLCBzX3RpbWVfdCBvbGRfYnVkZ2V0LA0KPiArICAgICAgICAgICAgICAg ICAgICAgICBzX3RpbWVfdCBuZXdfcGVyaW9kLCBzX3RpbWVfdCBuZXdfYnVkZ2V0KQ0KPiAr ew0KPiArICAgIHVpbnQ2NF90IG9sZF91dGlsID0gcnRfdW5pdF91dGlsaXphdGlvbihvbGRf cGVyaW9kLCBvbGRfYnVkZ2V0KTsNCj4gKyAgICB1aW50NjRfdCBuZXdfdXRpbCA9IHJ0X3Vu aXRfdXRpbGl6YXRpb24obmV3X3BlcmlvZCwgbmV3X2J1ZGdldCk7DQo+ICsgICAgdWludDY0 X3QgdG90YWwgICAgPSBwcnYtPnV0aWxpemF0aW9uIC0gb2xkX3V0aWwgKyBuZXdfdXRpbDsN Cj4gKw0KPiArICAgIGlmICggbmV3X3V0aWwgPiBvbGRfdXRpbCAmJiB0b3RhbCA+IHJ0X3V0 aWxpemF0aW9uX2NhcChkKSApDQo+ICsgICAgICAgIHJldHVybiBmYWxzZTsNCj4gKw0KPiAr ICAgIHBydi0+dXRpbGl6YXRpb24gPSB0b3RhbDsNCj4gKw0KPiArICAgIHJldHVybiB0cnVl Ow0KPiArfQ0KPiArDQo+ICAgLyoNCj4gICAgKiBQaWNrIGEgdmFsaWQgcmVzb3VyY2UgZm9y IHRoZSB1bml0IHZjDQo+ICAgICogVmFsaWQgcmVzb3VyY2Ugb2YgYW4gdW5pdCBpcyBpbnRl c2VjdGlvbiBvZiB1bml0J3MgYWZmaW5pdHkNCj4gQEAgLTg2NCw2ICs5MzMsNyBAQCBydF9m cmVlX2RvbWRhdGEoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCB2b2lkICpkYXRhKQ0K PiAgIHN0YXRpYyB2b2lkICogY2ZfY2hlY2sNCj4gICBydF9hbGxvY191ZGF0YShjb25zdCBz dHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCBzY2hlZF91bml0ICp1bml0LCB2b2lkICpk ZCkNCj4gICB7DQo+ICsgICAgc3RydWN0IHJ0X3ByaXZhdGUgKnBydiA9IHJ0X3ByaXYob3Bz KTsNCj4gICAgICAgc3RydWN0IHJ0X3VuaXQgKnN2YzsNCj4gICANCj4gICAgICAgLyogQWxs b2NhdGUgcGVyLVVOSVQgaW5mbyAqLw0KPiBAQCAtODgxLDkgKzk1MSwzMCBAQCBydF9hbGxv Y191ZGF0YShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIHN0cnVjdCBzY2hlZF91bml0 ICp1bml0LCB2b2lkICpkZCkNCj4gICAgICAgX19zZXRfYml0KF9fUlREU19leHRyYXRpbWUs ICZzdmMtPmZsYWdzKTsNCj4gICAgICAgc3ZjLT5wcmlvcml0eV9sZXZlbCA9IDA7DQo+ICAg ICAgIHN2Yy0+cGVyaW9kID0gUlREU19ERUZBVUxUX1BFUklPRDsNCj4gKw0KPiAgICAgICBp ZiAoICFpc19pZGxlX3VuaXQodW5pdCkgKQ0KPiArICAgIHsNCj4gKyAgICAgICAgdW5zaWdu ZWQgbG9uZyBmbGFnczsNCj4gKyAgICAgICAgYm9vbCBhZG1pdHRlZDsNCj4gKw0KPiAgICAg ICAgICAgc3ZjLT5idWRnZXQgPSBSVERTX0RFRkFVTFRfQlVER0VUOw0KPiAgIA0KPiArICAg ICAgICBzcGluX2xvY2tfaXJxc2F2ZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQo+ICsgICAgICAg IGFkbWl0dGVkID0gcnRfdHJ5X3NldF91dGlsaXphdGlvbihwcnYsIHVuaXQtPmRvbWFpbiwg MCwgMCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz dmMtPnBlcmlvZCwgc3ZjLT5idWRnZXQpOw0KDQpOaXQ6IHRoaXMgbGluZSBzZWVtcyB0byBi ZSBpbmRlbnRlZCBvbmUgc3BhY2UgdG9vIG11Y2guIFNhbWUgLi4uDQoNCj4gKyAgICAgICAg c3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQo+ICsNCj4gKyAg ICAgICAgaWYgKCAhYWRtaXR0ZWQgKQ0KPiArICAgICAgICB7DQo+ICsgICAgICAgICAgICBw cmludGsoWEVOTE9HX1dBUk5JTkcNCj4gKyAgICAgICAgICAgICAgICAgICAiUlREUzogQURN SVNTSU9OIENPTlRST0w6IHJlZnVzaW5nIHVuaXQgJXUgb2YgZCVkLCINCj4gKyAgICAgICAg ICAgICAgICAgICAiIHdvdWxkIGV4Y2VlZCB1dGlsaXphdGlvbiBjYXBhY2l0eSBvZiB0aGUg Y3B1cG9vbFxuIiwNCj4gKyAgICAgICAgICAgICAgICAgICB1bml0LT51bml0X2lkLCB1bml0 LT5kb21haW4tPmRvbWFpbl9pZCk7DQo+ICsgICAgICAgICAgICB4ZnJlZShzdmMpOw0KPiAr ICAgICAgICAgICAgcmV0dXJuIE5VTEw7DQo+ICsgICAgICAgIH0NCj4gKyAgICB9DQo+ICsN Cj4gICAgICAgU0NIRURfU1RBVF9DUkFOSyh1bml0X2FsbG9jKTsNCj4gICANCj4gICAgICAg cmV0dXJuIHN2YzsNCj4gQEAgLTg5Miw4ICs5ODMsMTkgQEAgcnRfYWxsb2NfdWRhdGEoY29u c3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBzdHJ1Y3Qgc2NoZWRfdW5pdCAqdW5pdCwgdm9p ZCAqZGQpDQo+ICAgc3RhdGljIHZvaWQgY2ZfY2hlY2sNCj4gICBydF9mcmVlX3VkYXRhKGNv bnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywgdm9pZCAqcHJpdikNCj4gICB7DQo+ICsgICAg c3RydWN0IHJ0X3ByaXZhdGUgKnBydiA9IHJ0X3ByaXYob3BzKTsNCj4gICAgICAgc3RydWN0 IHJ0X3VuaXQgKnN2YyA9IHByaXY7DQo+ICAgDQo+ICsgICAgaWYgKCBzdmMgJiYgIWlzX2lk bGVfdW5pdChzdmMtPnVuaXQpICkNCj4gKyAgICB7DQo+ICsgICAgICAgIHVuc2lnbmVkIGxv bmcgZmxhZ3M7DQo+ICsNCj4gKyAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUoJnBydi0+bG9j aywgZmxhZ3MpOw0KPiArICAgICAgICBydF90cnlfc2V0X3V0aWxpemF0aW9uKHBydiwgc3Zj LT51bml0LT5kb21haW4sDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN2 Yy0+cGVyaW9kLCBzdmMtPmJ1ZGdldCwgMCwgMCk7DQoNCi4uLiBoZXJlLg0KDQo+ICsgICAg ICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KPiArICAg IH0NCj4gKw0KPiAgICAgICB4ZnJlZShzdmMpOw0KPiAgIH0NCj4gICANCj4gQEAgLTEzODks NyArMTQ5MSw4IEBAIHJ0X3ZhbGlkYXRlX3BhcmFtcyhjb25zdCBzdHJ1Y3QgeGVuX2RvbWN0 bF9zY2hlZF9ydGRzICpydGRzLA0KPiAgICAgICBzX3RpbWVfdCBiID0gTUlDUk9TRUNTKHJ0 ZHMtPmJ1ZGdldCk7DQo+ICAgDQo+ICAgICAgIGlmICggcCA8IFJURFNfTUlOX1BFUklPRCB8 fCBwID4gUlREU19NQVhfUEVSSU9EIHx8DQo+IC0gICAgICAgICBiIDwgUlREU19NSU5fQlVE R0VUIHx8IGIgPiBwICkNCj4gKyAgICAgICAgIGIgPCBSVERTX01JTl9CVURHRVQgfHwgYiA+ IHAgfHwNCj4gKyAgICAgICAgIGIgPiAoc190aW1lX3QpUlREU19NQVhfQlVER0VUICkNCj4g ICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPiAgIA0KPiAgICAgICAqcGVyaW9kID0gcDsN Cg0KV2l0aCBhYm92ZSBmaXhlZDoNCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpn cm9zc0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo= --------------nl82mkcGPkkA8mDEZQKYRBzm Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------nl82mkcGPkkA8mDEZQKYRBzm-- --------------nXGT6hNqYecyPk5f5l73YXw0-- --------------cGS3MeBSQi3ObU09OPpPdfhb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqs/wkFAwAAAAAACgkQsN6d1ii/Ey9+ Uwf/dQQRdOEjral9P6cztakPfEMLH+S5CqkXtHfxwvz22zEXcx+zeYE7kpnOjOhOOOXHm7vl7qqI JZausgUxTznBlQzKH151HtzimlOFBB4Gic6O+wC3u+Ox2dj84m8mZlhurGL+owBnFYz51RKIePk1 5CsI3ewmQdTIPU3mc0pNuHjvyKl/oUig/ch3yR0n4N8e0WKLG2FM7iUuDE/X3nO1PslRvhCuU0zx JWpRApsVgHZmj91jTGMLQhZDyqnPeKjqzN0R794fQoMwD7JcP5z9tS5y2nGIWeDTH8ZxQvsauhxp cWDrWNom+z/7Kgse/rQzz6VCzDPq/JJ5JKksQndpIQ== =W0TV -----END PGP SIGNATURE----- --------------cGS3MeBSQi3ObU09OPpPdfhb-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:09:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:09:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425002.1649165 (Exim 4.92) (envelope-from ) id 1x7UbG-0006vm-He; Fri, 18 Sep 2026 09:09:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425002.1649165; Fri, 18 Sep 2026 09:09: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 1x7UbG-0006vf-Ed; Fri, 18 Sep 2026 09:09:42 +0000 Received: by outflank-mailman (input) for mailman id 1425002; Fri, 18 Sep 2026 09:09:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UbF-0006vZ-Dm for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:09:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7UbE-0044y6-Qa for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:09:40 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aacffcc-e002-0a2a0a5209dd-0a2a450abc7e-42 for ; Fri, 18 Sep 2026 11:09:40 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aacffd4-f2d2-0a2a450a0019-4a7de18cda0a-3 for ; Fri, 18 Sep 2026 11:09:40 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccead2aecso2485975e9.0 for ; Fri, 18 Sep 2026 02:09:40 -0700 (PDT) Received: from [172.18.88.57] (195-200-20-130.mclarenap.oninferno.net. [195.200.20.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd225898sm149690625e9.9.2026.09.18.02.09.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 02:09:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789722580; x=1790327380; darn=lists.xenproject.org; h=content-type: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:content-type; bh=4pbAVd85TCjqoPT0n6RX7sA3GT9XAtOIfbocwj4B7zM=; b=EVRQdJXWD7DO+NsiBIc3czP7VglJsA7LBf85fa28k7MnfgnQhoK5rCJKqnYD0cktrG LIxZuwiJpRW7PekbJdmlqegNSa6N9SHZGR5M/9oClY9WW2Sg2IgyK12Op3pcflw5Rmqg /9Y6UXpIrDWn8Zk71jVLetX/dURAT0UK8bqyqsXFuxz/mOv2fGx7MNqpxzc2xbxCXDG0 VqaKStQSbLXcQgc4150u3n0C+R0vvV8P37iNU+7Hc+NDMMp+/ytMIgcgEluuKyD0YC4e i4agGQ6HORHTYSWbWnBcTLMGmJGdvtbOv3XBIDHN+onbHZ067rlHcxlqwuk8kD9HFdIH gX7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789722580; x=1790327380; h=content-type: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 :content-type; bh=4pbAVd85TCjqoPT0n6RX7sA3GT9XAtOIfbocwj4B7zM=; b=T8IWHBbv49N5tf7zedBSDiQIwK+yY2KsLewXYEYVwkLX9CMfxQG1eObfXpN2B17SPb WqzfO3aQuH1xgaj65bhTgF4p7l1uHczAGkCPceesHnru52GfvuSsMwQGDTrZsnjJ5sAT SF1OELTq91pE9qT8aWk4sYDkdEduFXF5XG89mpyxgcGIOr36itRUTke9RfKZ3lLX9UcW tzdnAu3z/SfjBeTe/dR62J1F06mABCMdRLlg+59Z1kI5e0gwcrHVLwImpXRtkTwaXtyV S5KiNB3fRahl+CK7Sz1JWOkb0CbdkmTRWP0EUKdX6+A1dZey6wQ+11CRqeLoSCCoKOE1 vGfA== X-Forwarded-Encrypted: i=1; AKwUvBwDOi0S1qKrMz5fKxOgKrteRxGL3QteVIlTzrMofwqFmiYMl719uJJ1zajdbVd82uRC5D6VpAGIzMU=@lists.xenproject.org X-Gm-Message-State: AFuF++kAgZuViJ1N4QW5YRK3seQlhLoGFCnjOwpWlsurv6sKbv8c3Flf 2XAUrzHdmE16cijxSg2mPTZPwIpBWfS1EJfig3Gt2DzalDqrZ3U0JAmiwACPt8D2be8= X-Gm-Gg: AYBFou31LuWLO2W9W2Jil6hQRxDqLx2/Nw3uAT1pz9oiPipXKmaf8KdcX20cvOYzroH JGN0SksILhS03sna3jHufLZ1bkQ0GBt/ERB6GtKxICia5XUZHq4FkHZPb5nL0U5yadew7GXf7Y0 L0PMDqrRaKzUrnGB6nrivGecEqB2sVqDlH7KPpD7fe2nD0BxSTBzE0fKn1KyYtCQZmoO4B09RVz QELrNv5q5QgzcqacuaVXHZumn3YZy2uqZi8OrJVCIdNy9JXkTUXcSQzHZEJsE2BPrXEu8F0QJf2 fj4pQ9WdS2xpo4eNJs0GgRc0LH19xGLrHzkz/CPcZY9a21re0N+8fdPUc4xOoxvmCWxKzbdM/aN 8ofl8CvUIC2z8kLDb47LRltMkccG9lYUItlV4Nq48ZLC+mVAbRdNN5Q0g6PGcGYlwCJEsEClq4D pH4J4kFWNfcU9rhyKQBz7ZOJvK+IMVb8Muv6lFeOraV8b0zlHCUiyGK8KBZn4eAuqz+YFzLNjkU Soc5KZR8uya41KQHMebKrq9wLPSISoCPyM+Hjk= X-Received: by 2002:a05:600c:1f8b:b0:49c:cee2:1697 with SMTP id 5b1f17b1804b1-49fc5745fc0mr20476465e9.16.1789722580149; Fri, 18 Sep 2026 02:09:40 -0700 (PDT) Message-ID: <86c6c469-1351-45a7-8c09-8914ce44c17f@suse.com> Date: Fri, 18 Sep 2026 11:09:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org References: <20260918080935.35498-1-frn1furkan10@gmail.com> <20260918080935.35498-3-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260918080935.35498-3-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------zaQkt0RjOKjlMvpOzjrGJxpv" X-purgate-ID: tlsNG-4011c0/1789722580-4B4D7CFC-7FC96A89/35/110847 X-purgate-type: clean X-purgate-size: 8672 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------zaQkt0RjOKjlMvpOzjrGJxpv Content-Type: multipart/mixed; boundary="------------XwWPDD6i0p6lKYzQXM1MZzCJ"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org Message-ID: <86c6c469-1351-45a7-8c09-8914ce44c17f@suse.com> Subject: Re: [PATCH v2 2/5] xen/sched: rtds: enforce admission control in xl sched-rtds References: <20260918080935.35498-1-frn1furkan10@gmail.com> <20260918080935.35498-3-frn1furkan10@gmail.com> In-Reply-To: <20260918080935.35498-3-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------XwWPDD6i0p6lKYzQXM1MZzCJ Content-Type: multipart/mixed; boundary="------------CKhYrEjS8L7gv44CW04Bclei" --------------CKhYrEjS8L7gv44CW04Bclei Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTguMDkuMjYgMTA6MDksIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gTm93IHRoYXQg d2UgaGF2ZSBpbnRyb2R1Y2VkIGFkbWlzc2lvbiBjb250cm9sIGZvciBuZXcgYW5kDQo+IHJl bW92ZWQgdW5pdHMuIEV4dGVuZCBpdCB0byBYRU5fRE9NQ1RMX1NDSEVET1BfcHV0aW5mbyBh bmQNCj4gcHV0dmNwdWluZm8sIHNvIGdyb3dpbmcgYW4gZXhpc3RpbmcgcmVzZXJ2YXRpb24g dmlhDQo+IHhsIHNjaGVkLXJ0ZHMgaXMgY2hlY2tlZCB0b28uDQo+IA0KPiBwdXRpbmZvIHNl dHMgdGhlIHNhbWUgKHBlcmlvZCwgYnVkZ2V0KSBmb3IgZXZlcnkgdW5pdCBvZiBhDQo+IGRv bWFpbiBhdCBvbmNlLCBzbyBpdCB0ZXN0cyB0aGUgd2hvbGUgZG9tYWluJ3MgdXRpbGl6YXRp b24NCj4gZGVsdGEgYXRvbWljYWxseSwgcmF0aGVyIHRoYW4gdW5pdC1ieS11bml0LCB3aGlj aCBjb3VsZA0KPiBzcHVyaW91c2x5IHJlamVjdCBhbiBvdmVyYWxsLWFjY2VwdGFibGUgY2hh bmdlIGRlcGVuZGluZyBvbg0KPiBpdGVyYXRpb24gb3JkZXIuDQo+IA0KPiBwdXR2Y3B1aW5m byBjaGFuZ2VzIG9uZSB1bml0IGF0IGEgdGltZSwgc28gaXQganVzdCBjYWxscw0KPiBydF90 cnlfc2V0X3V0aWxpemF0aW9uKCkgZGlyZWN0bHkuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBG dXJrYW4gQ2FsaXNrYW4gPGZybjFmdXJrYW4xMEBnbWFpbC5jb20+DQpSZXZpZXdlZC1ieTog SnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg== --------------CKhYrEjS8L7gv44CW04Bclei Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------CKhYrEjS8L7gv44CW04Bclei-- --------------XwWPDD6i0p6lKYzQXM1MZzCJ-- --------------zaQkt0RjOKjlMvpOzjrGJxpv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqs/7kFAwAAAAAACgkQsN6d1ii/Ey+J jAf/b3eVGoFjW0lfQm4/qlx2P30RqrCKUsnJug94tNdpXL6VSv+9+FaZOJgWrTAh5Vl7gTw6UGZI s5jEArn5NbYTgFg+CQQi0/4ZQXwQi5CrSF2rzxAmqd+xdF4Vcpw/33xUrmgOM3PhPiIjd9T95dfU 8fiZaL6wfKV1TUhth14dYngdov+/s3PMntXwrD6ZyKAVWnUlQ46lG5HgYyZHoV3hq0EA955JhM0Y rjmV5za43WjmFgkx0jFO1i4x+LcLE2hKbFlUC0VI7Nod+8/Rv5Zn9jOHhy+5YX7kH9xi9f9wwUL5 jOQsKm4i/NOFn1dP/AFON/jd2zsNTZ9KHvA+kcKb0Q== =UMjs -----END PGP SIGNATURE----- --------------zaQkt0RjOKjlMvpOzjrGJxpv-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:17:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:17:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425015.1649175 (Exim 4.92) (envelope-from ) id 1x7UiG-0000CN-A5; Fri, 18 Sep 2026 09:16:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425015.1649175; Fri, 18 Sep 2026 09:16:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UiG-0000CG-6S; Fri, 18 Sep 2026 09:16:56 +0000 Received: by outflank-mailman (input) for mailman id 1425015; Fri, 18 Sep 2026 09:16:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x7UiF-0000C9-Dm for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:16:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7UiE-00GHMU-K3 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:16:54 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad0186-8faa-0a2a0a5109dd-0a2a450c86f2-2 for ; Fri, 18 Sep 2026 11:16:54 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad0186-f479-0a2a450c0019-b9ff1c23ae03-3 for ; Fri, 18 Sep 2026 11:16:54 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0b3cde12700072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 18 Sep 2026 09:16:49 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id A20C78224D; Fri, 18 Sep 2026 11:16:48 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=RsgrKGQ7K/SkL1SaY4LmgOlRzzi05DdCQVjWzygGJMM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=nhz0zw3fPin6lW4M2p2m94xFDMP7KSREZ197ySLYv1poMDNtkUnvYweKhB03XSpRk5SxK4mDv xkkE9/Lr5Hvf3RTtSo/7N/VNftGWK8pC5xT5303TnIQIie+F2iKvRw0mUGItkoefBMxgytncnIe gbGRgVRbBchkN5e1gRav0iETpFymaV+1u72cIyTkmkgeAe/DvltVx0Z2tHjdRWuMf9XY2gmk42Y tLVwQXT/OO24vNvItjNXSDEYhw7t37pYz1i5vjizJ0p1o10TW7jToUQDr75d+lJNuaxqdieTT8c Dddf2Swe4vZL7OF5iQ3IgCM5qJoclPMjJj0djCrLJ37A== X-Zone-Loop: 206898d69f5ad650ab3547d4d51c28b1c791970ea0e5 x-campaign-type: default x-transaction-id: 9062a508-4d17-411c-ac67-f3f954d61b42 x-swg-uid: 01-ae25bea2-ff1b-463c-bd4a-f25c08ffb89a X-Mailer: Sweego Message-ID: <1789723009.8631fc262581453bbf619ec5b2062170.1a0b3cde12700072c4@vates.tech> x-swg-bid: 1789723009.8631fc262581453bbf619ec5b2062170.1a0b3cde12700072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 25/39] xen/riscv: add guest load emulation for trapped MMIO accesses From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <7cf3203f8f826eefa1b24bb2dedbd76c0b611dc1.1787838835.git.oleksii.kurochko@gmail.com> References: <7cf3203f8f826eefa1b24bb2dedbd76c0b611dc1.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 18 Sep 2026 11:16:41 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789723003; l=2973; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=7M53VUWqG8Pa5m8oDt0++Lpm1slYVlSiB31RvmnHOPE=; b=FStnODzc25STTxD55J3bUhSeAGc4Ym/SyzYB5XXvRuwjmWw0e/bRMmbkdBYLWpBsp2SRb0i27 n81FhLS0Hm5Br6JAj8srcdEoBWaZAOk9QT2xBRYmj2K++pb9aOIYbdJ X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789723008882 X-purgate-ID: tlsNG-d25034/1789723014-00ECAA5B-126267E9/10/73395122804 X-purgate-type: spam X-purgate-size: 2973 > Implement emulate_load() on top of the decoding interface introduced by > the previous patch: fetch the trapped instruction, decode it, dispatch > the access to a registered MMIO handler via do_mmio(), write the result > back into the destination register and step over the instruction. > > Xen dispatches MMIO synchronously to an in-hypervisor handler, so unlike > KVM RISC-V there is no userspace exit/return step and no equivalent of > the kvm_io_bus_read() / KVM_EXIT_MMIO / kvm_riscv_vcpu_mmio_return() > split; the result is consumed in place. > > Sign extension is done here rather than in the handlers: a signed load > is normalized by a shift pair, so a handler need only report the value > it read. > > At the moment vINTC is the only backend registered with the MMIO > dispatch, so in practice this only covers vINTC traps. An access which > no handler claims currently crashes the domain; injecting an access > fault into the guest instead is left for later. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c > index 81a50643a5..e52f285180 100644 > --- a/xen/arch/riscv/emulate.c > +++ b/xen/arch/riscv/emulate.c > @@ -5,7 +5,6 @@ > */ > > #include > -#include > #include > #include > #include > @@ -15,6 +14,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -65,8 +65,7 @@ static bool is_load_guest_page_fault(unsigned long scause) > return scause == CAUSE_LOAD_GUEST_PAGE_FAULT; > } > > -static __maybe_unused void advance_pc(struct cpu_user_regs *regs, > - unsigned int step) > +static void advance_pc(struct cpu_user_regs *regs, unsigned int step) > { > regs->sepc += step; > } > @@ -88,7 +87,7 @@ static __maybe_unused void advance_pc(struct cpu_user_regs *regs, > * IS_ENABLED() can't be used here as HSTATUS_VSXL is defined for > * __riscv_xlen == 64 only, the field not existing on RV32 in the first place. > */ > -static __maybe_unused unsigned int guest_xlen(const struct cpu_user_regs *regs) > +static unsigned int guest_xlen(const struct cpu_user_regs *regs) > { > #ifdef CONFIG_RISCV_32 > return 32; > @@ -179,8 +178,7 @@ static void resolve_faulting_gpa(struct guest_fault *gf) > * Relies on x0..x31 being laid out at the start of struct cpu_user_regs in > * architectural register-number order; see the comment there. > */ > -static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs, > - unsigned int reg) Could we unified this function with regs_get_gpr()? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:17:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:17:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425016.1649184 (Exim 4.92) (envelope-from ) id 1x7UiM-0000Qq-FU; Fri, 18 Sep 2026 09:17:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425016.1649184; Fri, 18 Sep 2026 09:17:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UiM-0000Qj-Ct; Fri, 18 Sep 2026 09:17:02 +0000 Received: by outflank-mailman (input) for mailman id 1425016; Fri, 18 Sep 2026 09:17:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UiL-0000QB-5S for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:17:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7UiK-00GHMU-IU for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:17:00 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad0186-8faa-0a2a0a5109dd-0a2a450c86f2-12 for ; Fri, 18 Sep 2026 11:17:00 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad018c-f479-0a2a450c0019-b9ff1c239065-3 for ; Fri, 18 Sep 2026 11:17:00 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0b3cde27700072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 18 Sep 2026 09:16:49 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 05198821D1; Fri, 18 Sep 2026 11:16:49 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=NQ7mTRKVDEB6fRstnYIa6ATYk6cckZmxDMGQQWu4Fc4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=WGYBBDf6zgGzgSiYBua4w0liVkVWyFrp+VZmLDi4iouVofy1Ffp6oHhZXjdT8iV6uuLqHy5EI 91mc3VyeeCdxSUZH8YtmKMzjhpy0E0dzx6f3EWzmrQf0qp4Y5mWmRFDHlVxvtDjlp6KbyJVAkJn x295y8l/aGelDYCwqRZ6e1DHlLu0GBEWeV0ye4u0lr2Qi2akWKYkE1iB7EfY9t9cBnWfpuXv7Kw T5DXSBP05D2KiLL0iN5KOMtkRBgLgohDAClmtvqqqn68HLAcq1TeM9wbvxrlBodN2mC0CjtrxPl uZ+KSmzKxML/krPTQaAPKB9pcX6C1yLuNL/DSEvE+bOA== X-Zone-Loop: 4f4a8f6b99f510ecb19c6342dafea56953718dd986b4 x-campaign-type: default x-transaction-id: 236d961b-c099-498b-bc5c-a2455ba21376 x-swg-uid: 01-3b5c3e5d-3a04-4c85-8eb4-262804a1c0b6 X-Mailer: Sweego Message-ID: <1789723009.8631fc262581453bbf619ec5b2062170.1a0b3cde27700072c4@vates.tech> x-swg-bid: 1789723009.8631fc262581453bbf619ec5b2062170.1a0b3cde27700072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 26/39] xen/riscv: add guest store emulation for trapped MMIO accesses From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> References: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 18 Sep 2026 11:16:41 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789723003; l=1397; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=9YyJslwHpU7d8knvzTM+PA8SN4zacuZ2Z9IddfF2HJc=; b=tJEWqwOeEuSsfzjy0LXFGg6b/C1A1gL4x5B9ILnnFw0y2fMvPm+odTTvOBznWP1r8eOtV8Hyb PeJUtC0yaIFDUxk8bQkIN4XSZySgD9jDgIEwhQnUW9xgliKBlUyt5pK X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789723009225 X-purgate-ID: tlsNG-d25034/1789723020-03ED2A5B-69D228FD/0/0 X-purgate-type: clean X-purgate-size: 1397 > Extend the guest page fault handler with store emulation to support MMIO > write accesses. > > The instruction decode mirrors emulate_load() and, like it, is adapted > from Linux's KVM RISC-V implementation. As with the load path, the > completion is synchronous through try_handle_mmio() rather than KVM's > userspace exit/return split, since Xen's MMIO handlers run in the > hypervisor. Faults taken while re-reading the trapped instruction are > handled by decode_ldst_insn(), shared with the load path. > > When a guest store instruction faults, the trapped instruction is decoded > using HTINST or, if unavailable, fetched via unprivileged access. At the Nit: commit message restates the HTINST-or-unprivileged-fetch decode mechanism, which is already described in the prep patch introducing decode_ldst_insn()/insn_fetch_faulted(), and isn't repeated in emulate_load()'s commit message. Suggest trimming for symmetry with the load commit, e.g.: When a guest store instruction faults, the trapped instruction is decoded via decode_ldst_insn(), shared with the load path. At the moment only virtual interrupt controller (vINTC) traps are expected to occur, since it is currently the only backend registered with the MMIO handler dispatch, so in practice the store is emulated via the vINTC backend. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:17:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:17:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425020.1649193 (Exim 4.92) (envelope-from ) id 1x7UiY-0000mP-Mi; Fri, 18 Sep 2026 09:17:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425020.1649193; Fri, 18 Sep 2026 09:17:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UiY-0000mI-JW; Fri, 18 Sep 2026 09:17:14 +0000 Received: by outflank-mailman (input) for mailman id 1425020; Fri, 18 Sep 2026 09:17:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7UiX-0000lY-C5 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:17:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7UiW-008h8D-Ov for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:17:12 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad0188-bab6-0a2a0a5309dd-0a2a450796fe-32 for ; Fri, 18 Sep 2026 11:17:12 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad0198-b4ea-0a2a45070019-4a7de18cbdd4-3 for ; Fri, 18 Sep 2026 11:17:12 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b91369d18so4236165e9.0 for ; Fri, 18 Sep 2026 02:17:12 -0700 (PDT) Received: from [172.18.88.57] (195-200-20-130.mclarenap.oninferno.net. [195.200.20.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd225898sm150134065e9.9.2026.09.18.02.16.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 02:17:11 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789723032; x=1790327832; darn=lists.xenproject.org; h=content-type: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:content-type; bh=CZcUhFz75ZWOoJCk4PFLmwb+gcGUHGOb/sbvfW40GZY=; b=bAuproyoSqulyWNwpdXaqEbbhGJ33cHYUuCHpTW8VTOhkbay5rlQcHzSVjkuixFmzW ByYpbeYU4HHOxln6kyz07AqscKjLTC/zbK0lvywevhv1rkhGWTBoqu4S5bzRTF6ZZNqM jTAODW4YF05gNbdP8dkr8AysEL6BTsVFaSG5ptmhwtYvjDPzhaEMfzPE5fJfq7nu34rf innupSlfC/e59VjrTAVLn062qtiSwmBgPGDJwswGJGV72TKTULg3Ll0++NA07v4z/wkI Bp3A/s+GLPHKiOtmSxHogZGWnRsm4C0I0f4R4YCsvqyAzGatmQJevQmX8aZoqrJuSRzr cfuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789723032; x=1790327832; h=content-type: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 :content-type; bh=CZcUhFz75ZWOoJCk4PFLmwb+gcGUHGOb/sbvfW40GZY=; b=h9DXw3NT9lcHI2Qq9zU/vsghXtMsqC+BdA7j1Oqu7uWJsGXq8GsiX//KoYWHjJYdGq 2GgVtofKAX3UM166VjDkYa4y5OhT6yxlkRWIprwf8eTU4mg+Hx4xb1ZKSvOUgk09MZ5i 95JquCRMqLJkkRiERs2hduXOvCQFvwMMEmOGJBtAFqrPRcuMit9MEK9udZdaFthSyq5p m+KxYaHTQl2idccRm85TUZkoJF0y/9MWJYCPmCBzSU1FgEVAh5vDkxISWDgJR8afZ1vw +ctdLgz/BKjN8GA2+JcESPyBflb68Sy6qc9F07fswnaLwKwBw/PN64+8Uo9OMcLLzis+ rTTQ== X-Forwarded-Encrypted: i=1; AKwUvByTqXN7DqAvRDv2Fh6dEO6c2MIVZfeheMi3ksm/3POFmoMQcCVC5VKAsg+ZO+Cw9djC9XsPsuAlf2I=@lists.xenproject.org X-Gm-Message-State: AFuF++kTIIJtrVpYFjekubHGRi3gmv57WVklGf0UuV7SiXezWAelKTw4 ReIR4FEbVln7mtgjKbhSc9jWeMxDw+txAhEeVsJQiyHRqkH9cK+bQCApMz5b21sXxEE= X-Gm-Gg: AYBFou3G1jUUodqwEt/41wfQvO5hJb+MLAlHr7h3nWQLKIv1lOg4KA5/aogdReQ2pM7 SXNl7sD+AeV4hp7AWHR5NtLdWTPnqn1rUPpdM2nE38zNSZPXNxlQHRG0+cYxr/gx35nn4IrBJ0w xHtc6q67wU/nSvzTrxZ/WtTD4ccUDEZUeRIHQ4OJ/Pe4m1qUq8iD9eXizZRSKPdMMvBiSxdMQKd ymmlwoQTdfKJ72BsgU2vUv5deFfsmt0/ZkPfJdpg9+2ue6a8poSE/cNi/LpWjnn+picdweeU6fZ bet4ZXSmMQznjUoAFxhQx6pp4ieIAAd0K+6NZEaVTD2R17BxehRd95ityOEakuaH6da8R08ESYA 4d2mUGxnYHv2diaNf3Lvlo1Ep4WPa8qysyB89RuH/zA9UfBYKTd3swSQd6nAA/BVafkXjtr5mbs 6I+9/ogJqkd7VyBCbTJMg6odk2T4dhZYuuOTzJwA9hSkdYRH+HuryJvEa88jlpD3tEAPyFoA5WH gHz5sD7jwKsD7pketeylTXVIjRqtgW2/Y7LaRI= X-Received: by 2002:a05:600c:674f:b0:49c:dc14:d681 with SMTP id 5b1f17b1804b1-49fc56dbcb5mr20744365e9.3.1789723032023; Fri, 18 Sep 2026 02:17:12 -0700 (PDT) Message-ID: Date: Fri, 18 Sep 2026 11:16:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] xen/sched: rtds: make admission control cpupool-wide toggleable To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org References: <20260918080935.35498-1-frn1furkan10@gmail.com> <20260918080935.35498-5-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260918080935.35498-5-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0vxOyawpLT1zKa15vqSHUPXy" X-purgate-ID: tlsNG-ef75cf/1789723032-36CDFAE4-78C7C25C/35/110847 X-purgate-type: clean X-purgate-size: 8118 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0vxOyawpLT1zKa15vqSHUPXy Content-Type: multipart/mixed; boundary="------------TQYFgNNoXv8WFVZufrbHthf7"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org Message-ID: Subject: Re: [PATCH v2 4/5] xen/sched: rtds: make admission control cpupool-wide toggleable References: <20260918080935.35498-1-frn1furkan10@gmail.com> <20260918080935.35498-5-frn1furkan10@gmail.com> In-Reply-To: <20260918080935.35498-5-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------TQYFgNNoXv8WFVZufrbHthf7 Content-Type: multipart/mixed; boundary="------------jyUfGzAcOqHuF0Cmd0NqiqvF" --------------jyUfGzAcOqHuF0Cmd0NqiqvF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTguMDkuMjYgMTA6MDksIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gQWRkIGEgcGVy LWNwdXBvb2wgb24vb2ZmIHN3aXRjaCBmb3IgUlREUyBhZG1pc3Npb24gY29udHJvbCB2aWEN Cj4gWEVOX1NZU0NUTF9zY2hlZHVsZXJfb3AsIGVuYWJsZWQgYnkgZGVmYXVsdCwgc28gYW4g b3BlcmF0b3IgY2FuDQo+IGRpc2FibGUvZW5hYmxlIGVuZm9yY2VtZW50IGZvciBhIHBvb2wN Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IEZ1cmthbiBDYWxpc2thbiA8ZnJuMWZ1cmthbjEwQGdt YWlsLmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNv bT4NCg0KDQpKdWVyZ2VuDQo= --------------jyUfGzAcOqHuF0Cmd0NqiqvF Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------jyUfGzAcOqHuF0Cmd0NqiqvF-- --------------TQYFgNNoXv8WFVZufrbHthf7-- --------------0vxOyawpLT1zKa15vqSHUPXy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqtAVwFAwAAAAAACgkQsN6d1ii/Ey+c lgf+K8oO4XT2fRH8qdSy4nVl1CvGNA6VEuBUOH/HLNcWKXzKETfQtZg8YN9l4kFhsjWxlRyHD7wl k/tamv+Q64cuI54AIA1pqqa6ezrVkoc+9tgpClLr0fR1yg1wJ9e2Hd9Jx9ZZEMxx/+zh7M1nryHm SWqJpOqdAbIrf/rhC0Wmt0oGhHEg6xeQh3IPBcGl8QWg6zGUS1M0lsU0OSpwLzUldPVP1aSHcO+u 4ImtkY5DACpJnA4iaRwHiLXIXTiWgyui4vZSJePST2//h0PzmBHRXbOxrah9zb/WHpSMfUYsi+AT E5e/RCFkb/d5tPzDmFri96L90N5hbhoUuJmUzy5gTQ== =t+Bk -----END PGP SIGNATURE----- --------------0vxOyawpLT1zKa15vqSHUPXy-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:21:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:21:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425038.1649202 (Exim 4.92) (envelope-from ) id 1x7Umu-0002wV-C8; Fri, 18 Sep 2026 09:21:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425038.1649202; Fri, 18 Sep 2026 09:21:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Umu-0002wO-8z; Fri, 18 Sep 2026 09:21:44 +0000 Received: by outflank-mailman (input) for mailman id 1425038; Fri, 18 Sep 2026 09:21:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Umt-0002wI-2S for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:21:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Ums-00BnNQ-FG for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:21:42 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad029c-bab6-0a2a0a5309dd-0a2a45029a6c-20 for ; Fri, 18 Sep 2026 11:21:42 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad02a6-6ca4-0a2a45020019-b9ff1c23b15d-3 for ; Fri, 18 Sep 2026 11:21:42 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0b3d2454000072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 18 Sep 2026 09:21:37 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 639E2820E3; Fri, 18 Sep 2026 11:21:36 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=UOM25LSPPP3/4I8O84HDA4IQydPDOie/ahFidAghSHA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=evAIaSdHbtygyjJR06C6IYlENSP78efmOPxqBoQyvfGkUDecWuTvy6ct7Yq2ZnaYrq4zwFYIS Ydg5K/8z54kkcZd5K2O6auhTUYPxhMpLFKBCOo8YjD2URH6HeFWqF+TROIzYRWTa6+DI5TeJrK1 b069z/sIFpkbeuvAgDw7E71b+8o/EwAEj8G8t2qAg2qUauKTJ3Sy6GRIA0e4oNsxhJ+zAaLiO4u tjHxDCDm6+RdqyJD3iEv+AVdLJx3oIP8kXCJGC6ngSM7g9EfkY+wsD46dNQcGvFpfx0BjeQvZDh X9pjHRIe7IbAgTiIYLAa0K5lkS/2IVbtiimrv+C8zkgw== X-Zone-Loop: 88998e8a40861dccdab1b95f9e4f8dd18177cfef6039 x-campaign-type: default x-transaction-id: 7424afb5-a667-4fce-ad23-2c1fba2d945e x-swg-uid: 01-7c0b6ab0-ca17-4835-8d44-52217f678979 X-Mailer: Sweego Message-ID: <1789723297.8631fc262581453bbf619ec5b2062170.1a0b3d2454000072c4@vates.tech> x-swg-bid: 1789723297.8631fc262581453bbf619ec5b2062170.1a0b3d2454000072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed From: Baptiste Le Duc To: Jan Beulich Cc: Oleksii Kurochko , Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org In-Reply-To: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> References: <63eb5954-0c34-4cec-9037-b25724b68f47@suse.com> Date: Fri, 18 Sep 2026 11:21:30 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1789723291; l=1602; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=XF+DjpkZ5bbLAmRm1I58wMYZUqH/4T5AvmRWgGWvcbw=; b=l5Hevoostmi6RAC2nwtWCWClbj+F4AhoWRvi9NMy21Y6PejrEBC7RLV/imiDT77EEI+VmXPgb 4ghyMjwcwLzCY6Ae+WECoX4bcp1jTscv7d7hQoR74vYFRQzxSOF8UUw X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789723296609 X-purgate-ID: tlsNG-720697/1789723302-F28B42AC-C92D6645/0/0 X-purgate-type: clean X-purgate-size: 1606 On 2026-09-14 14:12:07+02:00, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: > > > The IMSIC vsfile mapping is performed in continue_new_vcpu(), since the > > target pCPU must be known at that point. It is therefore possible for > > imsic_migrate_vcpu() to be called before continue_new_vcpu() has > > executed, in which case v->arch.last_pcpu is NR_CPUS and there is nothing > > to migrate. > > > > Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > > against silent incorrect behaviour or unexpected panics in guest VMs until > > the function is fully implemented. > > This doesn't adequately describe the change made: The BUG_ON() was already > there. > > > --- a/xen/arch/riscv/imsic.c > > +++ b/xen/arch/riscv/imsic.c > > @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, > > > > void imsic_migrate_vcpu(struct vcpu *v) > > { > > + /* > > + * The scheduler can mark a freshly created vCPU's unit as migrated and > > + * invoke this before the vCPU has ever run (see the migrated branch in > > + * schedule()). No need to do migration for such vCPUs as they aren't fully > > + * initialized (for example, context_switch() will be called after > > + * imsic_migrate_vcpu()). > > + */ > > + if ( v->arch.last_cpu == NR_CPUS ) > > May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a > good sentinel. If we/you decided to switch to ~0, >= here would continue to > be correct. I also agree that ~0 would be better. > > Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:25:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:25:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425045.1649211 (Exim 4.92) (envelope-from ) id 1x7Uq9-0003RX-P0; Fri, 18 Sep 2026 09:25:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425045.1649211; Fri, 18 Sep 2026 09:25:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Uq9-0003RQ-MC; Fri, 18 Sep 2026 09:25:05 +0000 Received: by outflank-mailman (input) for mailman id 1425045; Fri, 18 Sep 2026 09:25:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Uq8-0003RK-Sh for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:25:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Uq8-00DuQ1-8o for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:25:04 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad034f-8faa-0a2a0a5109dd-0a2a4503ea48-44 for ; Fri, 18 Sep 2026 11:25:04 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad036f-fae8-0a2a45030019-4a7de18dd212-3 for ; Fri, 18 Sep 2026 11:25:03 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49cd5462b69so2765975e9.1 for ; Fri, 18 Sep 2026 02:25:03 -0700 (PDT) Received: from notebook.. ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd24034esm171027215e9.15.2026.09.18.02.25.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 02:25:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789723503; x=1790328303; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=txnRHfHrPg7CoDqc49cB1JdTECz0cbXf16sWY0sZ6Kw=; b=a99sCE5LTbb8qa79yC29/kXjKrD2kMvN4B4A2ujcCEtVETxBfWVaCM3rHiq2qPrUBN CdiiwZEIcz902L2pTZGKYi7JLNhcHaKELFrQR8QLTpi+bipLk/rnAsr6pbD2HufwqbMV Xh1w4TKMoFYiMaNlAHVQCjt9YeTOLUoBDxO7tTPlSaU8uRWEYuro8zjTge3yqOCx2+iN WaPbA0OAPfE//3OCgIOcv/3wK1KWJgMxpTk2CHAvVVnILr6gmtiUDEMjCwM3U2GXdlCk 0/fu2Z4TYHnkDIUjP1y1X/PkLdUDc/uxJBzaACJOqfjoh8GjYqDXnp2B3S97dHQlSIls 9FMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789723503; x=1790328303; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=txnRHfHrPg7CoDqc49cB1JdTECz0cbXf16sWY0sZ6Kw=; b=cb0FTaLO40PQbhkBXwy8ic0v/CW0Bcd+RDN+jLBwUYbx2fvRW6pPeWbHGMCtXc5Y2W 6Upgvyacsp9ABAX9FFQNH8URnKrE2a3kpezbCYgFuAfae3k10DiuDSHrJ4IZycODjl0o XmLXpHugoSVsiZUk6QkjGdkJy19ccRStec91Ui364D5JEaeG4AYKEajPO/kT3EeXfeta GZQKyecZgmKm4ImdxGkJPEbDz6eHhOG1PnrvSOY09As0OAqF1JDvAFyIvyANW+C9z3Cb sKW40WsyltKzefvtsxTGcCtEWlAvokFZjQOTwe9uy1Fo23hWXX69IwbNrjWvpKHgPPd6 F3YA== X-Gm-Message-State: AFuF++llGM6UDmuJKjBz+FqfuupA2wyVcD7+XpUcb0dk8KpHoupOvZd9 NNj9xRHSS0FwFCiIVZsODXgt5/PLCRulitjlC0gGgpv/UJl8uhznCOSzcwnGUQ== X-Gm-Gg: AYBFou0a5cgcglEVmyvHeAmBzvTyIPiZ1oIooEYXqtLQ6zi+MatmGKageyHSvhfC/Dl aAJnrtrBriBxuTvF0ltyAaqx5ziOFja53rrv1p5Afp0scCbhgiP5n2h/15yZPLJ92vCQ5LX0/s6 jzvxFPdB22zgVNyEI7XBLfL/9OAjK7I/+UF7N8Et5MI0tKPcO/WSfHyoWxfmkADNNQVRq8zyKjs Pydp/d6jwU/hD+90bfGpPyj0J8lRd851MVx1rbbz8s6w35mgffoQiYtnLhkSZTMLRW0QbY52nox xHbqs1pLIAP0bvbkGpLhWGBhdh8mS8P+OCsEL+YGNLeb/WLprFI/aEOHzOGsJ72kxSuZrZjctML E0sIVUrfi4VaGGfpS0n5HTvlPvKguC/mKMXIn48XiErucnfu5r0Y5uVNUkc6Swmckg99EO0R5aq 2eu3Fl8tmH1gd2lJHfulWyLZ1l6up6P8wUFFdh5wzcnvPCV+DXSdhIeGimAC/jd+NKhqH1p0w= X-Received: by 2002:a05:600c:6211:b0:49f:bc28:e8b1 with SMTP id 5b1f17b1804b1-49fc5735be7mr45459495e9.14.1789723503074; Fri, 18 Sep 2026 02:25:03 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, Furkan Caliskan Subject: [PATCH v3 1/5] xen/sched: rtds: add global-EDF utilization admission control Date: Fri, 18 Sep 2026 12:24:33 +0300 Message-Id: <20260918092433.42891-1-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260918080935.35498-2-frn1furkan10@gmail.com> References: <20260918080935.35498-2-frn1furkan10@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1789723503-6CADC4E9-9852616C/0/0 X-purgate-type: clean X-purgate-size: 7193 RTDS has no admission control: nothing stops the sum of all admitted units' (budget/period) reservations in a cpupool from exceeding what its pCPUs can actually provide. Once that happens, none of the EDF deadline guarantees this scheduler is built around still hold for the units sharing that pool. Introduce admission control to prevent this: reject a reservation whenever admitting it would push a cpupool's units over its capacity. Track a running utilization total per cpupool, and enforce it in rt_alloc_udata()/rt_free_udata(), the paired lifecycle hooks for a unit's creation and destruction. This catches the default period/budget every new unit gets. Utilization is represented as a fixed-point value: budget is left shifted by RTDS_UTIL_SHIFT (20 bits) and divided by period. A plain "(budget << RTDS_UTIL_SHIFT) / period" risks overflowing the multiply for large enough budgets. Rather than widen the arithmetic to tolerate any input, the input itself is bounded: rt_validate_params() rejects any budget above RTDS_MAX_BUDGET, chosen as the largest value that can be left-shifted by RTDS_UTIL_SHIFT without overflowing 64 bits, so the shift in rt_unit_utilization() can never overflow. A cpupool's capacity rt_utilization_cap() scales with the number of scheduling resources in it. It is calculated as: (number of sched_resources * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100), where RTDS_UTIL_CAP_PCT controls how much of that capacity can actually be reserved; at 100% (its current value), all of it can be. Signed-off-by: Furkan Caliskan Reviewed-by: Juergen Gross --- v3: - Fixed indentation. --- xen/common/sched/rt.c | 105 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 104 insertions(+), 1 deletion(-) diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c index 0e9f04ea72..ff561ec1c9 100644 --- a/xen/common/sched/rt.c +++ b/xen/common/sched/rt.c @@ -114,6 +114,24 @@ */ #define RTDS_MAX_PRIORITY_LEVEL (~0U) +/* + * Fixed-point scale for utilization (budget/period) + */ +#define RTDS_UTIL_SHIFT 20 +#define RTDS_UTIL_SCALE (1ULL << RTDS_UTIL_SHIFT) + +/* + * Largest budget safe to left-shift by RTDS_UTIL_SHIFT without + * overflowing 64 bits. Enforced in rt_validate_params(). + */ +#define RTDS_MAX_BUDGET_BITS (64 - RTDS_UTIL_SHIFT) +#define RTDS_MAX_BUDGET ((1ULL << RTDS_MAX_BUDGET_BITS) - 1) + +/* + * % of a cpupool's sched_resource capacity admitted units may sum up to. + */ +#define RTDS_UTIL_CAP_PCT 100 + /* * UPDATE_LIMIT_SHIFT: a constant used in rt_update_deadline(). When finding * the next deadline, performing addition could be faster if the difference @@ -195,6 +213,9 @@ struct rt_private { struct list_head replq; /* ordered list of units that need replenishment */ cpumask_t tickled; /* cpus been tickled */ + + /* Sum of admitted units' (budget/period), scaled by RTDS_UTIL_SCALE */ + uint64_t utilization; }; /* @@ -635,6 +656,54 @@ replq_reinsert(const struct scheduler *ops, struct rt_unit *svc) set_timer(&rt_priv(ops)->repl_timer, rearm_svc->cur_deadline); } +/* + * budget << RTDS_UTIL_SHIFT can't overflow: rt_validate_params() + * caps budget at RTDS_MAX_BUDGET. period == 0 means "no + * reservation" (a unit being removed), not an error. + */ +static uint64_t +rt_unit_utilization(s_time_t period, s_time_t budget) +{ + if ( period <= 0 ) + return 0; + + return ((uint64_t)budget << RTDS_UTIL_SHIFT) / (uint64_t)period; +} + +/* + * Utilization capacity of the cpupool domain d resides in. + */ +static uint64_t +rt_utilization_cap(const struct domain *d) +{ + unsigned int cpus = cpumask_weight(cpupool_domain_master_cpumask(d)); + + return (uint64_t)cpus * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100; +} + +/* + * Replaces a unit's reservation and updates prv->utilization + * to match. Growth that would push utilization over the + * cpupool's cap is refused. Removing a unit or shrinking + * a unit's reservation always succeed. + */ +static bool +rt_try_set_utilization(struct rt_private *prv, const struct domain *d, + s_time_t old_period, s_time_t old_budget, + s_time_t new_period, s_time_t new_budget) +{ + uint64_t old_util = rt_unit_utilization(old_period, old_budget); + uint64_t new_util = rt_unit_utilization(new_period, new_budget); + uint64_t total = prv->utilization - old_util + new_util; + + if ( new_util > old_util && total > rt_utilization_cap(d) ) + return false; + + prv->utilization = total; + + return true; +} + /* * Pick a valid resource for the unit vc * Valid resource of an unit is intesection of unit's affinity @@ -864,6 +933,7 @@ rt_free_domdata(const struct scheduler *ops, void *data) static void * cf_check rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) { + struct rt_private *prv = rt_priv(ops); struct rt_unit *svc; /* Allocate per-UNIT info */ @@ -881,9 +951,30 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) __set_bit(__RTDS_extratime, &svc->flags); svc->priority_level = 0; svc->period = RTDS_DEFAULT_PERIOD; + if ( !is_idle_unit(unit) ) + { + unsigned long flags; + bool admitted; + svc->budget = RTDS_DEFAULT_BUDGET; + spin_lock_irqsave(&prv->lock, flags); + admitted = rt_try_set_utilization(prv, unit->domain, 0, 0, + svc->period, svc->budget); + spin_unlock_irqrestore(&prv->lock, flags); + + if ( !admitted ) + { + printk(XENLOG_WARNING + "RTDS: ADMISSION CONTROL: refusing unit %u of d%d," + " would exceed utilization capacity of the cpupool\n", + unit->unit_id, unit->domain->domain_id); + xfree(svc); + return NULL; + } + } + SCHED_STAT_CRANK(unit_alloc); return svc; @@ -892,8 +983,19 @@ rt_alloc_udata(const struct scheduler *ops, struct sched_unit *unit, void *dd) static void cf_check rt_free_udata(const struct scheduler *ops, void *priv) { + struct rt_private *prv = rt_priv(ops); struct rt_unit *svc = priv; + if ( svc && !is_idle_unit(svc->unit) ) + { + unsigned long flags; + + spin_lock_irqsave(&prv->lock, flags); + rt_try_set_utilization(prv, svc->unit->domain, + svc->period, svc->budget, 0, 0); + spin_unlock_irqrestore(&prv->lock, flags); + } + xfree(svc); } @@ -1389,7 +1491,8 @@ rt_validate_params(const struct xen_domctl_sched_rtds *rtds, s_time_t b = MICROSECS(rtds->budget); if ( p < RTDS_MIN_PERIOD || p > RTDS_MAX_PERIOD || - b < RTDS_MIN_BUDGET || b > p ) + b < RTDS_MIN_BUDGET || b > p || + b > (s_time_t)RTDS_MAX_BUDGET ) return -EINVAL; *period = p; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:36:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:36:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425058.1649219 (Exim 4.92) (envelope-from ) id 1x7V0e-0005LB-MX; Fri, 18 Sep 2026 09:35:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425058.1649219; Fri, 18 Sep 2026 09:35:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7V0e-0005L4-Ju; Fri, 18 Sep 2026 09:35:56 +0000 Received: by outflank-mailman (input) for mailman id 1425058; Fri, 18 Sep 2026 09:35:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7V0d-0005Ky-Ea for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:35:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7V0c-00DwtY-QL for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:35:54 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad05f5-bab6-0a2a0a5309dd-0a2a45049cf0-22 for ; Fri, 18 Sep 2026 11:35:54 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad05fa-b57f-0a2a45040019-4a7de14cb864-3 for ; Fri, 18 Sep 2026 11:35:54 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485b1d2874fso171865f8f.0 for ; Fri, 18 Sep 2026 02:35:54 -0700 (PDT) Received: from [172.18.138.134] ([185.104.138.149]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fc7ce03e7sm44036515e9.3.2026.09.18.02.35.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 02:35:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789724154; x=1790328954; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VfRaF/hsbUyxrZV7v2ViXYuo1EVlbPXCSn+xARdM3vY=; b=OS4H/R+3977XsM5ddJhiTcJWgSli42Zh1955AwnVtTEtKJNa1NAXBpxqwTgC0HuyN7 QEJGi2y4ed6jFV8ws0gJLbRvwflrfrbJqv7cz3GOH4B7/WP8jpBSFFXTE9o5Dsqjqit1 pYJE/DhZ0hIsymzih1o5VOaxcomnDzHZQh3esFK1xLkt7IzknVH9xnW+mEW9PMiesdSk nCrOJrwZaS6bjvWoCi4doaB+eYsirGzMaJ6YqGRe0kfidvATfkdZYEExoxLWVGiH0EEr 0WK0Yq2RITMuyK3vumeVTIuMuTfy1jn8CVzIKscBQ4TKkp0mI9pJgeYDOlQc8ke3++Cd vDBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789724154; x=1790328954; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=VfRaF/hsbUyxrZV7v2ViXYuo1EVlbPXCSn+xARdM3vY=; b=jBj1JQ76wvX7JKH1cVA8TGQDe8freo72W1jBmInf57CSlA2OW/NxDHKPaSphBVSePD hoJndRpHxQMVjls+L8wsfD3V+9fameNozLfbmFqm9DGQeVjlmRadjR5GYoNeCmRFhYpA mZVQ1i7W55VgmQGamPcUceTclx920ZzR/OIZqqOXrz8ECVcLrWUiTgLvjnX8sns/PHSo Kxk7SM/uqolcyjVXJxTEzgRjxddmIls/XH5OboLdsTkEoBq6tjGz0Q0IMfxRqXo+WhRh mmKQGuHm9nluHr2cx5yrFK8sL41MIqtgnvBOYBS7Gzd99f1gCWAUVKcyR5PLdk3tTvdu pbvg== X-Forwarded-Encrypted: i=1; AKwUvBwi8rwA0NgEk96Dha9E+EHB+UdOlHxeWDc/jLMKpgUXE826RJnfmhGMhypZYVRBw61YRl1UvyX65XE=@lists.xenproject.org X-Gm-Message-State: AFuF++kU+v3ofjCaKImCc8eoo7vUCAykiOzJEgFXqQawlr4QSuzefwXN 0cAXjG90oxMIHN4ncaitECaNU/nwo/lx2rVgMCkkDV0u1vDOC4DWgDhLqdEjDOIq9w== X-Gm-Gg: AYBFou39H0DHkB6kYLNmml5e2RFiNndon49yrvUyx5qrqFeBM4mPiB29IaRP1OZGG9v ViK4gf2xhiVfAfNaGHqc0e16znsZwM69bLKjt2Dqixx5Y0LIr6y8g+7Q+o7VcHt0zWIfUOb06vE Lc59ji3SoPh/bx7gi2fz56/F3hJEWbNd5cvIRytrjMBqbazx9l1EQGtkmWkH8seWuBdmwQ6SDWI KblGpVjZ1QHSkcSMFKn8/obAO4O+zOMAo2RnB534Zpskxa4cbvF0fBlBqgmBXrySEFp/eW2iQ5z mC7OSlSygedZ4DjXWAh6EtkOkmRMcKelE+r156PTshlyoj1v9psdWBGEh+a3A+Olf1KPREEE7SE tKcH3FJ2aLi1BRzETw3Rqtwyp1K+SFZzhXUS6PhFpWW6aRs0NGlMp/zX0euVbvgQhNH4ZYVsv6p Va9gR/dGLkfAOKJ/B8zHJr/l3wPFhMgeoHQfc5hKnM+0zsqmXnq+P9CuLkMypmh9NJXGUya4frM qTgVYC0/3I= X-Received: by 2002:a05:600c:37c3:b0:49c:e37e:4389 with SMTP id 5b1f17b1804b1-49fc4f8528cmr25463345e9.4.1789724154107; Fri, 18 Sep 2026 02:35:54 -0700 (PDT) Message-ID: <12da547c-a67a-4f46-bee5-666cc26fc976@suse.com> Date: Fri, 18 Sep 2026 11:35:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs: clarify tag sequence in sending-patches To: Juergen Gross Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260918065614.11003-1-jgross@suse.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <20260918065614.11003-1-jgross@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1789724154-583C0B50-580795D2/0/0 X-purgate-type: clean X-purgate-size: 407 On 18.09.2026 08:56, Juergen Gross wrote: > Make clear what an "Assisted-by: tag tag relates to in > sending-patches.pandoc. I guess when committing I'll take the liberty to replace the redundant "tag" with the missing closing double quote. > Add the possibility to clarify how AI was used. > > Signed-off-by: Juergen Gross Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:37:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:37:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425070.1649228 (Exim 4.92) (envelope-from ) id 1x7V2E-0005q6-WD; Fri, 18 Sep 2026 09:37:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425070.1649228; Fri, 18 Sep 2026 09:37:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7V2E-0005pz-Ta; Fri, 18 Sep 2026 09:37:34 +0000 Received: by outflank-mailman (input) for mailman id 1425070; Fri, 18 Sep 2026 09:37:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7V2D-0005pg-TY for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:37:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7V2D-00GLKG-AV for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:37:33 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad0654-bab6-0a2a0a5309dd-0a2a450c817e-20 for ; Fri, 18 Sep 2026 11:37:33 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad065d-f479-0a2a450c0019-4a7de14c9772-3 for ; Fri, 18 Sep 2026 11:37:33 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-48434392b02so353749f8f.3 for ; Fri, 18 Sep 2026 02:37:33 -0700 (PDT) Received: from [172.18.88.57] (195-200-20-130.mclarenap.oninferno.net. [195.200.20.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4872008023dsm2644975f8f.29.2026.09.18.02.37.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 02:37:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789724253; x=1790329053; darn=lists.xenproject.org; h=content-type: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:content-type; bh=ef8/aV/5M4MuqPSDzS8MlKHz1mREss2PWghUjltIh5U=; b=by2e/BflvH/RaSIbQRFlsQcrgihtknv+7OKRmPSf28+OF85zHhwcf/gIVbYV0/nfxG KXSv0SWgEv3FiIHN9uKgKvrKMnW7mF/Az2yK/q6cnROqt6oF4LGvS6Ag+cNDzd+u1Vxu V3eSijsSkdm0FznJsltd2LwIB9uSbYuDgW2aqiWgyWenUGdky/l5e17uAT1hGUxPZDKr uuWBsrUeWDw3zfomyUe/cS8iBHkfcl0f6SAveE8jXjtnmnR703NP9zwmJv6ynNa2x6en M3Aoy/qzEp0lGXXXSdX14CnHiRPXdjPDF8ifM+mbfTOAMoeyPEsvy+2WFjyEpb4LOPa+ FxYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789724253; x=1790329053; h=content-type: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 :content-type; bh=ef8/aV/5M4MuqPSDzS8MlKHz1mREss2PWghUjltIh5U=; b=z9Z5rDRxIoz5dgkWN61c4wFieDTfiTilVSk2U8f2BmR7lN8cgAYKbc0KaaY6ZI/65S dy4JVxIf31Hs1mMVthik75reYG3wGjPd71sz8xAeLBREH9sVeP3tnFPptuarpaC5ta0y 6+30PNuRmnEvy/LI6bHrgHS50IhgC5T6rlajfTJCnFtyEP6/x5wnHO04MAqwJOowhI2Q bh+hTFcCNkI3hFQph/4CpvAVtCGZHhCC0TdgwZCZgqQxpXlD8scc2jqQgDM6vF6dfBPW nNHJFqzUoQS9oAIXSJkUmu/5vXWFVhL+3FyUgGCT2tESZNpdMrbtI5NBwWmSFrIbV5UH NaSQ== X-Forwarded-Encrypted: i=1; AKwUvBwfkrI/8+eEUW7zcek6iQ3jcsf3GjQMi30jVTsHgwrXl2y9JwWof88uJLe+w974fUgZJrumEmJn8PA=@lists.xenproject.org X-Gm-Message-State: AFuF++l+Bb96mtChfwDHkKReB/SM3bfv/yRfMjH92NQIbfOqbSjiLrYj k4hN0dQSYDxpMcEbGkJ2kyFHiS2sDknd08d/g/oqta5Mo/D7gcpoV1+ZuFiXWPzsCKM= X-Gm-Gg: AYBFou3AAq51AjnJsvTMTTDffpDx7eUjBlL9RR59Qual17xFifpH3PAvy/BSMAkOCUC RkGvG4UAhzgDh5wpLEQAPnUitnIFJW9HX/hPjxITvPTxUeXcb6qZiY3Ly/bXRXvgdxF3mpnq+XY 7gGoIRDxIMxOHBHqT9HiYsHXogkBfGGnv1DegPOA/nk/dw2IOaPdPRgY9xCkeykB0aEzSNDTIyr KZvmb30t/MCY5s3FnlKUP6h9I5jmpzHlbqZWtdqI9WB7iVNKbg39lahBos1kiEdjX6iRQ/IG/OX qkPNfnfNbY0z7Vy3YO4p76ZYBSO1EuDdHcIru+OtTq3uHjynM/QoAwk2XVy1txZkuNCgNQcSL1O CFhJJ/qV6l3JmYZ8KCpiTtbBjxthYkopkI5OSKLhO1dpMAo0UdCSelwX1nLgrEol7FWZiaT02mz D/aLhb62yP5LqTDJLBO2VHi2FhoFB2iedDpMHG9ZfvTrMFuosWl22vsP21eQnimxVwDCPCHsl84 Q8iWLUbrq7cOVO6zV/ut7GYUVRk3wUy9HCyYSM= X-Received: by 2002:a05:6000:18a9:b0:487:88b:4681 with SMTP id ffacd0b85a97d-4871e21aa62mr4758197f8f.10.1789724252034; Fri, 18 Sep 2026 02:37:32 -0700 (PDT) Message-ID: <82467099-4168-4618-8d33-119d2f505a10@suse.com> Date: Fri, 18 Sep 2026 11:37:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/5] tools: expose admission control toggle via xl sched-rtds To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org References: <20260918080935.35498-1-frn1furkan10@gmail.com> <20260918080935.35498-6-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260918080935.35498-6-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------4m4tloNBtRlg2QpqnNioGKh8" X-purgate-ID: tlsNG-d25034/1789724253-51D34A5B-48AF1B4B/35/110847 X-purgate-type: clean X-purgate-size: 26891 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------4m4tloNBtRlg2QpqnNioGKh8 Content-Type: multipart/mixed; boundary="------------58v0cEotoY9vT72QFNgbnwhu"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, dfaggioli@suse.com, anthony.perard@vates.tech, julien@xen.org Message-ID: <82467099-4168-4618-8d33-119d2f505a10@suse.com> Subject: Re: [PATCH v2 5/5] tools: expose admission control toggle via xl sched-rtds References: <20260918080935.35498-1-frn1furkan10@gmail.com> <20260918080935.35498-6-frn1furkan10@gmail.com> In-Reply-To: <20260918080935.35498-6-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------58v0cEotoY9vT72QFNgbnwhu Content-Type: multipart/mixed; boundary="------------8FOHKea6wjpsew6i0U9miZK0" --------------8FOHKea6wjpsew6i0U9miZK0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTguMDkuMjYgMTA6MDksIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gV2lyZSB0aGUg cGVyLWNwdXBvb2wgYWRtaXNzaW9uLWNvbnRyb2wgc3dpdGNoIHRocm91Z2ggbGlieGwNCj4g dG8geGwgc2NoZWQtcnRkcywgYW5kIGRvY3VtZW50IGl0Lg0KPiANCj4gQWRkIC1zLy0tc2No ZWRwYXJhbSB0byBsaXN0IG9yIHNldCBwb29sLXdpZGUgUlREUyBzY2hlZHVsZXINCj4gcGFy YW1ldGVycywgYW5kIC1hLy0tYWRtaXNzaW9uIHRvIGVuYWJsZSBvciBkaXNhYmxlIGFkbWlz c2lvbg0KPiBjb250cm9sIGZvciBhIGNwdXBvb2wgKCItYyBwb29sIC1zIC1hIDAvMSIpLg0K PiANCj4gU2lnbmVkLW9mZi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21h aWwuY29tPg0KPiAtLS0NCj4gICBkb2NzL21hbi94bC4xLnBvZC5pbiAgICAgICAgICAgICAg ICAgfCAgMjAgKysrKysrDQo+ICAgdG9vbHMvZ29sYW5nL3hlbmxpZ2h0L2hlbHBlcnMuZ2Vu LmdvIHwgIDIzICsrKysrKw0KPiAgIHRvb2xzL2dvbGFuZy94ZW5saWdodC90eXBlcy5nZW4u Z28gICB8ICAgNCArKw0KPiAgIHRvb2xzL2luY2x1ZGUvbGlieGwuaCAgICAgICAgICAgICAg ICB8ICAgNCArKw0KPiAgIHRvb2xzL2luY2x1ZGUveGVuY3RybC5oICAgICAgICAgICAgICB8 ICAgNiArKw0KPiAgIHRvb2xzL2xpYnMvY3RybC94Y19ydC5jICAgICAgICAgICAgICB8ICA0 MCArKysrKysrKysrKw0KPiAgIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfc2NoZWQuYyAgICAg ICB8ICA0NiArKysrKysrKysrKysNCj4gICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVz LmlkbCAgICAgfCAgIDUgKysNCj4gICB0b29scy94bC94bF9jbWR0YWJsZS5jICAgICAgICAg ICAgICAgfCAgIDggKystDQo+ICAgdG9vbHMveGwveGxfc2NoZWQuYyAgICAgICAgICAgICAg ICAgIHwgMTAzICsrKysrKysrKysrKysrKysrKysrKysrKystLQ0KPiAgIDEwIGZpbGVzIGNo YW5nZWQsIDI1NCBpbnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQ0KPiANCg0KLi4uDQoN Cj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2luY2x1ZGUvbGlieGwuaCBiL3Rvb2xzL2luY2x1ZGUv bGlieGwuaA0KPiBpbmRleCA3YzA5OGVkYWI2Li5mZjk5M2MzOGI3IDEwMDY0NA0KPiAtLS0g YS90b29scy9pbmNsdWRlL2xpYnhsLmgNCj4gKysrIGIvdG9vbHMvaW5jbHVkZS9saWJ4bC5o DQo+IEBAIC0yNzk3LDYgKzI3OTcsMTAgQEAgaW50IGxpYnhsX3NjaGVkX2NyZWRpdDJfcGFy YW1zX2dldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgcG9vbGlkLA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfc2NoZWRfY3JlZGl0Ml9wYXJhbXMg KnNjaW5mbyk7DQo+ICAgaW50IGxpYnhsX3NjaGVkX2NyZWRpdDJfcGFyYW1zX3NldChsaWJ4 bF9jdHggKmN0eCwgdWludDMyX3QgcG9vbGlkLA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgbGlieGxfc2NoZWRfY3JlZGl0Ml9wYXJhbXMgKnNjaW5mbyk7DQo+ ICtpbnQgbGlieGxfc2NoZWRfcnRkc19wYXJhbXNfZ2V0KGxpYnhsX2N0eCAqY3R4LCB1aW50 MzJfdCBwb29saWQsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhs X3NjaGVkX3J0ZHNfcGFyYW1zICpzY2luZm8pOw0KPiAraW50IGxpYnhsX3NjaGVkX3J0ZHNf cGFyYW1zX3NldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgcG9vbGlkLA0KPiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9zY2hlZF9ydGRzX3BhcmFtcyAqc2Np bmZvKTsNCg0KV2hlbiBhZGRpbmcgbmV3IGZ1bmN0aW9ucyB0byBsaWJ4bC5oLCB5b3UgbmVl ZCB0byBhZGQgYSAiTElCWExfSEFWRV8uLi4iICNkZWZpbmUNCmZvciBzaWduYWxsaW5nIHRo YXQgYWRkaXRpb24gKHNlZSBuZWFyIHRoZSB0b3Agb2YgbGlieGwuaCkuDQoNCj4gICANCj4g ICAvKiBTY2hlZHVsZXIgUGVyLWRvbWFpbiBwYXJhbWV0ZXJzICovDQo+ICAgDQo+IGRpZmYg LS1naXQgYS90b29scy9pbmNsdWRlL3hlbmN0cmwuaCBiL3Rvb2xzL2luY2x1ZGUveGVuY3Ry bC5oDQo+IGluZGV4IDlmMDBkNGExOWQuLjZmNGVhN2NhNjIgMTAwNjQ0DQo+IC0tLSBhL3Rv b2xzL2luY2x1ZGUveGVuY3RybC5oDQo+ICsrKyBiL3Rvb2xzL2luY2x1ZGUveGVuY3RybC5o DQo+IEBAIC04OTcsNiArODk3LDEyIEBAIGludCB4Y19zY2hlZF9ydGRzX3ZjcHVfZ2V0KHhj X2ludGVyZmFjZSAqeGNoLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQz Ml90IGRvbWlkLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5f ZG9tY3RsX3NjaGVkcGFyYW1fdmNwdSAqdmNwdXMsDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdWludDMyX3QgbnVtX3ZjcHVzKTsNCj4gK2ludCB4Y19zY2hlZF9ydGRzX3Bh cmFtc19zZXQoeGNfaW50ZXJmYWNlICp4Y2gsDQo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHVpbnQzMl90IGNwdXBvb2xfaWQsDQo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHN0cnVjdCB4ZW5fc3lzY3RsX3J0ZHNfc2NoZWR1bGUgKnNjaGVkdWxlKTsNCj4g K2ludCB4Y19zY2hlZF9ydGRzX3BhcmFtc19nZXQoeGNfaW50ZXJmYWNlICp4Y2gsDQo+ICsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGNwdXBvb2xfaWQsDQo+ICsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCB4ZW5fc3lzY3RsX3J0ZHNfc2No ZWR1bGUgKnNjaGVkdWxlKTsNCj4gICANCj4gICBpbnQNCj4gICB4Y19zY2hlZF9hcmluYzY1 M19zY2hlZHVsZV9zZXQoDQo+IGRpZmYgLS1naXQgYS90b29scy9saWJzL2N0cmwveGNfcnQu YyBiL3Rvb2xzL2xpYnMvY3RybC94Y19ydC5jDQo+IGluZGV4IDNjYjNmYmI5MjMuLmZiM2Y1 NjdkNGYgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2xpYnMvY3RybC94Y19ydC5jDQo+ICsrKyBi L3Rvb2xzL2xpYnMvY3RybC94Y19ydC5jDQo+IEBAIC0xMzAsMyArMTMwLDQzIEBAIGludCB4 Y19zY2hlZF9ydGRzX3ZjcHVfZ2V0KHhjX2ludGVyZmFjZSAqeGNoLA0KPiAgIA0KPiAgICAg ICByZXR1cm4gcmM7DQo+ICAgfQ0KPiArDQo+ICtpbnQgeGNfc2NoZWRfcnRkc19wYXJhbXNf c2V0KHhjX2ludGVyZmFjZSAqeGNoLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB1aW50MzJfdCBjcHVwb29sX2lkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzdHJ1Y3QgeGVuX3N5c2N0bF9ydGRzX3NjaGVkdWxlICpzY2hlZHVsZSkNCj4gK3sNCj4g KyAgICBzdHJ1Y3QgeGVuX3N5c2N0bCBzeXNjdGwgPSB7fTsNCj4gKw0KPiArICAgIHN5c2N0 bC5jbWQgPSBYRU5fU1lTQ1RMX3NjaGVkdWxlcl9vcDsNCj4gKyAgICBzeXNjdGwudS5zY2hl ZHVsZXJfb3AuY3B1cG9vbF9pZCA9IGNwdXBvb2xfaWQ7DQo+ICsgICAgc3lzY3RsLnUuc2No ZWR1bGVyX29wLnNjaGVkX2lkID0gWEVOX1NDSEVEVUxFUl9SVERTOw0KPiArICAgIHN5c2N0 bC51LnNjaGVkdWxlcl9vcC5jbWQgPSBYRU5fU1lTQ1RMX1NDSEVET1BfcHV0aW5mbzsNCj4g Kw0KPiArICAgIHN5c2N0bC51LnNjaGVkdWxlcl9vcC51LnNjaGVkX3J0ZHMgPSAqc2NoZWR1 bGU7DQo+ICsNCj4gKyAgICBpZiAoIGRvX3N5c2N0bCh4Y2gsICZzeXNjdGwpICkNCj4gKyAg ICAgICAgcmV0dXJuIC0xOw0KPiArDQo+ICsgICAgKnNjaGVkdWxlID0gc3lzY3RsLnUuc2No ZWR1bGVyX29wLnUuc2NoZWRfcnRkczsNCj4gKw0KPiArICAgIHJldHVybiAwOw0KPiArfQ0K PiArDQo+ICtpbnQgeGNfc2NoZWRfcnRkc19wYXJhbXNfZ2V0KHhjX2ludGVyZmFjZSAqeGNo LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBjcHVwb29sX2lk LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGVuX3N5c2N0bF9y dGRzX3NjaGVkdWxlICpzY2hlZHVsZSkNCj4gK3sNCj4gKyAgICBzdHJ1Y3QgeGVuX3N5c2N0 bCBzeXNjdGwgPSB7fTsNCj4gKw0KPiArICAgIHN5c2N0bC5jbWQgPSBYRU5fU1lTQ1RMX3Nj aGVkdWxlcl9vcDsNCj4gKyAgICBzeXNjdGwudS5zY2hlZHVsZXJfb3AuY3B1cG9vbF9pZCA9 IGNwdXBvb2xfaWQ7DQo+ICsgICAgc3lzY3RsLnUuc2NoZWR1bGVyX29wLnNjaGVkX2lkID0g WEVOX1NDSEVEVUxFUl9SVERTOw0KPiArICAgIHN5c2N0bC51LnNjaGVkdWxlcl9vcC5jbWQg PSBYRU5fU1lTQ1RMX1NDSEVET1BfZ2V0aW5mbzsNCj4gKw0KPiArICAgIGlmICggZG9fc3lz Y3RsKHhjaCwgJnN5c2N0bCkgKQ0KPiArICAgICAgICByZXR1cm4gLTE7DQo+ICsNCj4gKyAg ICAqc2NoZWR1bGUgPSBzeXNjdGwudS5zY2hlZHVsZXJfb3AudS5zY2hlZF9ydGRzOw0KPiAr DQo+ICsgICAgcmV0dXJuIDA7DQo+ICt9DQo+IGRpZmYgLS1naXQgYS90b29scy9saWJzL2xp Z2h0L2xpYnhsX3NjaGVkLmMgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX3NjaGVkLmMNCj4g aW5kZXggMmQ2NjM1ZGFlNy4uYWU0Mzc5Y2YwOSAxMDA2NDQNCj4gLS0tIGEvdG9vbHMvbGli cy9saWdodC9saWJ4bF9zY2hlZC5jDQo+ICsrKyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxf c2NoZWQuYw0KPiBAQCAtMzk3LDYgKzM5Nyw1MiBAQCBpbnQgbGlieGxfc2NoZWRfY3JlZGl0 Ml9wYXJhbXNfc2V0KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBwb29saWQsDQo+ICAgICAg IHJldHVybiByYzsNCj4gICB9DQo+ICAgDQo+ICtpbnQgbGlieGxfc2NoZWRfcnRkc19wYXJh bXNfZ2V0KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBwb29saWQsDQo+ICsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX3NjaGVkX3J0ZHNfcGFyYW1zICpzY2luZm8p DQo+ICt7DQo+ICsgICAgc3RydWN0IHhlbl9zeXNjdGxfcnRkc19zY2hlZHVsZSBzcGFyYW07 DQo+ICsgICAgaW50IHIsIHJjOw0KPiArICAgIEdDX0lOSVQoY3R4KTsNCj4gKw0KPiArICAg IHIgPSB4Y19zY2hlZF9ydGRzX3BhcmFtc19nZXQoY3R4LT54Y2gsIHBvb2xpZCwgJnNwYXJh bSk7DQo+ICsgICAgaWYgKHIgPCAwKSB7DQo+ICsgICAgICAgIExPR0UoRVJST1IsICJnZXR0 aW5nIFJURFMgc2NoZWR1bGVyIHBhcmFtZXRlcnMiKTsNCj4gKyAgICAgICAgcmMgPSBFUlJP Ul9GQUlMOw0KPiArICAgICAgICBnb3RvIG91dDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBz Y2luZm8tPmFkbWlzc2lvbl9jb250cm9sX2VuYWJsZWQgPSBzcGFyYW0uYWRtaXNzaW9uX2Nv bnRyb2xfZW5hYmxlZDsNCj4gKw0KPiArICAgIHJjID0gMDsNCj4gK291dDoNCj4gKyAgICBH Q19GUkVFOw0KPiArICAgIHJldHVybiByYzsNCj4gK30NCj4gKw0KPiAraW50IGxpYnhsX3Nj aGVkX3J0ZHNfcGFyYW1zX3NldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgcG9vbGlkLA0K PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9zY2hlZF9ydGRzX3Bh cmFtcyAqc2NpbmZvKQ0KPiArew0KPiArICAgIHN0cnVjdCB4ZW5fc3lzY3RsX3J0ZHNfc2No ZWR1bGUgc3BhcmFtOw0KPiArICAgIGludCByLCByYzsNCj4gKyAgICBHQ19JTklUKGN0eCk7 DQo+ICsNCj4gKyAgICBzcGFyYW0uYWRtaXNzaW9uX2NvbnRyb2xfZW5hYmxlZCA9IHNjaW5m by0+YWRtaXNzaW9uX2NvbnRyb2xfZW5hYmxlZDsNCj4gKw0KPiArICAgIHIgPSB4Y19zY2hl ZF9ydGRzX3BhcmFtc19zZXQoY3R4LT54Y2gsIHBvb2xpZCwgJnNwYXJhbSk7DQo+ICsgICAg aWYgKHIgPCAwKSB7DQo+ICsgICAgICAgIExPR0UoRVJST1IsICJTZXR0aW5nIFJURFMgc2No ZWR1bGVyIHBhcmFtZXRlcnMiKTsNCj4gKyAgICAgICAgcmMgPSBFUlJPUl9GQUlMOw0KPiAr ICAgICAgICBnb3RvIG91dDsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICBzY2luZm8tPmFkbWlz c2lvbl9jb250cm9sX2VuYWJsZWQgPSBzcGFyYW0uYWRtaXNzaW9uX2NvbnRyb2xfZW5hYmxl ZDsNCj4gKw0KPiArICAgIHJjID0gMDsNCj4gK291dDoNCj4gKyAgICBHQ19GUkVFOw0KPiAr ICAgIHJldHVybiByYzsNCj4gK30NCj4gKw0KPiAgIHN0YXRpYyBpbnQgc2NoZWRfY3JlZGl0 Ml9kb21haW5fZ2V0KGxpYnhsX19nYyAqZ2MsIHVpbnQzMl90IGRvbWlkLA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2RvbWFpbl9zY2hlZF9wYXJh bXMgKnNjaW5mbykNCj4gICB7DQo+IGRpZmYgLS1naXQgYS90b29scy9saWJzL2xpZ2h0L2xp YnhsX3R5cGVzLmlkbCBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsDQo+IGlu ZGV4IGE3ODkzNDYwZjAuLmQzMTIxZWEyNzcgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2xpYnMv bGlnaHQvbGlieGxfdHlwZXMuaWRsDQo+ICsrKyBiL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxf dHlwZXMuaWRsDQo+IEBAIC0xMjg2LDYgKzEyODYsMTEgQEAgbGlieGxfc2NoZWRfY3JlZGl0 Ml9wYXJhbXMgPSBTdHJ1Y3QoInNjaGVkX2NyZWRpdDJfcGFyYW1zIiwgWw0KPiAgICAgICAo InJhdGVsaW1pdF91cyIsIGludGVnZXIpLA0KPiAgICAgICBdLCBkaXNwb3NlX2ZuPU5vbmUp DQo+ICAgDQo+ICtsaWJ4bF9zY2hlZF9ydGRzX3BhcmFtcyA9IFN0cnVjdCgic2NoZWRfcnRk c19wYXJhbXMiLCBbDQo+ICsgICAgKCJhZG1pc3Npb25fY29udHJvbF9lbmFibGVkIiwgYm9v bCksDQo+ICsgICAgXSwgZGlzcG9zZV9mbj1Ob25lKQ0KPiArDQo+ICsNCj4gICBsaWJ4bF9k b21haW5fcmVtdXNfaW5mbyA9IFN0cnVjdCgiZG9tYWluX3JlbXVzX2luZm8iLFsNCj4gICAg ICAgKCJpbnRlcnZhbCIsICAgICAgICAgICAgIGludGVnZXIpLA0KPiAgICAgICAoImFsbG93 X3Vuc2FmZSIsICAgICAgICAgbGlieGxfZGVmYm9vbCksDQo+IGRpZmYgLS1naXQgYS90b29s cy94bC94bF9jbWR0YWJsZS5jIGIvdG9vbHMveGwveGxfY21kdGFibGUuYw0KPiBpbmRleCA1 MDIyNDRmNjgzLi5lNDhkNWM1ZWRjIDEwMDY0NA0KPiAtLS0gYS90b29scy94bC94bF9jbWR0 YWJsZS5jDQo+ICsrKyBiL3Rvb2xzL3hsL3hsX2NtZHRhYmxlLmMNCj4gQEAgLTI5NSwxMyAr Mjk1LDE5IEBAIGNvbnN0IHN0cnVjdCBjbWRfc3BlYyBjbWRfdGFibGVbXSA9IHsNCj4gICAg ICAgeyAic2NoZWQtcnRkcyIsDQo+ICAgICAgICAgJm1haW5fc2NoZWRfcnRkcywgMCwgMSwN Cj4gICAgICAgICAiR2V0L3NldCBydGRzIHNjaGVkdWxlciBwYXJhbWV0ZXJzIiwNCj4gLSAg ICAgICJbLWQgPERvbWFpbj4gWy12Wz1WQ1BVSUQvYWxsXV0gWy1wWz1QRVJJT0RdXSBbLWJb PUJVREdFVF1dIFstZVs9RXh0cmF0aW1lXV1dIiwNCj4gKyAgICAgICJbLWQgPERvbWFpbj4g Wy12Wz1WQ1BVSUQvYWxsXV0gWy1wWz1QRVJJT0RdXSBbLWJbPUJVREdFVF1dIFstZVs9RXh0 cmF0aW1lXV1dXG4iDQo+ICsgICAgICAiICAgICAgICAgICAgICAgIFstYyA8Q3B1cG9vbD4g LXMgWy1hWz1BRE1JU1NJT05fQ09OVFJPTF1dXSIsDQo+ICAgICAgICAgIi1kIERPTUFJTiwg LS1kb21haW49RE9NQUlOICAgICBEb21haW4gdG8gbW9kaWZ5XG4iDQo+ICAgICAgICAgIi12 IFZDUFVJRC9hbGwsIC0tdmNwdWlkPVZDUFVJRC9hbGwgICAgVkNQVSB0byBtb2RpZnkgb3Ig b3V0cHV0O1xuIg0KPiAgICAgICAgICIgICAgICAgICAgICAgICBVc2luZyAnLXYgYWxsJyB0 byBtb2RpZnkvb3V0cHV0IGFsbCB2Y3B1c1xuIg0KPiAgICAgICAgICItcCBQRVJJT0QsIC0t cGVyaW9kPVBFUklPRCAgICAgUGVyaW9kICh1cylcbiINCj4gICAgICAgICAiLWIgQlVER0VU LCAtLWJ1ZGdldD1CVURHRVQgICAgIEJ1ZGdldCAodXMpXG4iDQo+ICAgICAgICAgIi1lIEV4 dHJhdGltZSwgLS1leHRyYXRpbWU9RXh0cmF0aW1lIEV4dHJhdGltZSAoMT15ZXMsIDA9bm8p XG4iDQo+ICsgICAgICAiLWMgQ1BVUE9PTCwgLS1jcHVwb29sPUNQVVBPT0wgIFJlc3RyaWN0 IG91dHB1dCB0byBkb21haW5zIGluIENQVVBPT0xcbiINCj4gKyAgICAgICItcywgLS1zY2hl ZHBhcmFtICAgICAgICAgICAgICAgTGlzdCBvciBzZXQgcG9vbC13aWRlIHNjaGVkdWxlciBw YXJhbWV0ZXJzXG4iDQo+ICsgICAgICAiLWEgQURNSVNTSU9OX0NPTlRST0wsIC0tYWRtaXNz aW9uPUFETUlTU0lPTl9DT05UUk9MXG4iDQo+ICsgICAgICAiICAgICAgICAgICAgICAgRW5h YmxlIG9yIGRpc2FibGUgYWRtaXNzaW9uIGNvbnRyb2wgZm9yIHRoZSBjcHVwb29sXG4iDQo+ ICsgICAgICAiICAgICAgICAgICAgICAgKDE9ZW5hYmxlZCwgMD1kaXNhYmxlZCk7IHJlcXVp cmVzIC1zXG4iDQo+ICAgICAgIH0sDQo+ICAgICAgIHsgImRvbWlkIiwNCj4gICAgICAgICAm bWFpbl9kb21pZCwgMCwgMCwNCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3hsL3hsX3NjaGVkLmMg Yi90b29scy94bC94bF9zY2hlZC5jDQo+IGluZGV4IDczY2Q3MDQwY2QuLjcyNTdkMTg1NGIg MTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL3hsL3hsX3NjaGVkLmMNCj4gKysrIGIvdG9vbHMveGwv eGxfc2NoZWQuYw0KPiBAQCAtMjQ2LDYgKzI0NiwyOCBAQCBzdGF0aWMgaW50IHNjaGVkX2Ny ZWRpdDJfcG9vbF9vdXRwdXQodWludDMyX3QgcG9vbGlkKQ0KPiAgICAgICByZXR1cm4gMDsN Cj4gICB9DQo+ICAgDQo+ICtzdGF0aWMgaW50IHNjaGVkX3J0ZHNfcGFyYW1zX3NldChpbnQg cG9vbGlkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfc2No ZWRfcnRkc19wYXJhbXMgKnNjaW5mbykNCj4gK3sNCj4gKyAgICBpZiAobGlieGxfc2NoZWRf cnRkc19wYXJhbXNfc2V0KGN0eCwgcG9vbGlkLCBzY2luZm8pKSB7DQo+ICsgICAgICAgIGZw cmludGYoc3RkZXJyLCAibGlieGxfc2NoZWRfcnRkc19wYXJhbXNfc2V0IGZhaWxlZC5cbiIp Ow0KPiArICAgICAgICByZXR1cm4gMTsNCj4gKyAgICB9DQo+ICsNCj4gKyAgICByZXR1cm4g MDsNCj4gK30NCj4gKw0KPiArc3RhdGljIGludCBzY2hlZF9ydGRzX3BhcmFtc19nZXQoaW50 IHBvb2xpZCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX3Nj aGVkX3J0ZHNfcGFyYW1zICpzY2luZm8pDQo+ICt7DQo+ICsgICAgaWYgKGxpYnhsX3NjaGVk X3J0ZHNfcGFyYW1zX2dldChjdHgsIHBvb2xpZCwgc2NpbmZvKSkgew0KPiArICAgICAgICBm cHJpbnRmKHN0ZGVyciwgImxpYnhsX3NjaGVkX3J0ZHNfcGFyYW1zX2dldCBmYWlsZWQuXG4i KTsNCj4gKyAgICAgICAgcmV0dXJuIDE7DQo+ICsgICAgfQ0KPiArDQo+ICsgICAgcmV0dXJu IDA7DQo+ICt9DQo+ICsNCj4gICBzdGF0aWMgaW50IHNjaGVkX3J0ZHNfZG9tYWluX291dHB1 dCgNCj4gICAgICAgaW50IGRvbWlkKQ0KPiAgIHsNCj4gQEAgLTMzOSwxMCArMzYxLDE1IEBA IHN0YXRpYyBpbnQgc2NoZWRfcnRkc192Y3B1X291dHB1dF9hbGwoaW50IGRvbWlkLA0KPiAg IA0KPiAgIHN0YXRpYyBpbnQgc2NoZWRfcnRkc19wb29sX291dHB1dCh1aW50MzJfdCBwb29s aWQpDQo+ICAgew0KPiAtICAgIGNoYXIgKnBvb2xuYW1lOw0KPiArICAgIGxpYnhsX3NjaGVk X3J0ZHNfcGFyYW1zIHNjcGFyYW07DQo+ICsgICAgY2hhciAqcG9vbG5hbWUgPSBsaWJ4bF9j cHVwb29saWRfdG9fbmFtZShjdHgsIHBvb2xpZCk7DQo+ICAgDQo+IC0gICAgcG9vbG5hbWUg PSBsaWJ4bF9jcHVwb29saWRfdG9fbmFtZShjdHgsIHBvb2xpZCk7DQo+IC0gICAgcHJpbnRm KCJDcHVwb29sICVzOiBzY2hlZD1SVERTXG4iLCBwb29sbmFtZSk7DQo+ICsgICAgaWYgKHNj aGVkX3J0ZHNfcGFyYW1zX2dldChwb29saWQsICZzY3BhcmFtKSkNCj4gKyAgICAgICAgcHJp bnRmKCJDcHVwb29sICVzOiBbc2NoZWQgcGFyYW1zIHVuYXZhaWxhYmxlXVxuIiwgcG9vbG5h bWUpOw0KPiArICAgIGVsc2UNCj4gKyAgICAgICAgcHJpbnRmKCJDcHVwb29sICVzOiBzY2hl ZD1SVERTIGFkbWlzc2lvbi1jb250cm9sPSVzXG4iLA0KPiArICAgICAgICAgICAgICAgIHBv b2xuYW1lLA0KPiArICAgICAgICAgICAgICAgIHNjcGFyYW0uYWRtaXNzaW9uX2NvbnRyb2xf ZW5hYmxlZCA/ICJlbmFibGVkIiA6ICJkaXNhYmxlZCIpOw0KPiAgIA0KPiAgICAgICBmcmVl KHBvb2xuYW1lKTsNCj4gICAgICAgcmV0dXJuIDA7DQo+IEBAIC03MTUsNiArNzQyLDggQEAg aW50IG1haW5fc2NoZWRfY3JlZGl0MihpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQo+ICAgICog LWQgW2RvbWlkXSAtdiBbdmNwdWlkIDFdIFtwYXJhbXNdIC12IFt2Y3B1aWQgMl0gW3BhcmFt c10gLi4uICA6DQo+ICAgICogU2V0IHBlci1WQ1BVIHBhcmFtcyBmb3IgZG9tYWluDQo+ICAg ICogLWQgW2RvbWlkXSAtdiBhbGwgW3BhcmFtc10gIDogU2V0IGFsbCBwZXItVkNQVSBwYXJh bXMgZm9yIGRvbWFpbg0KPiArICogLWMgW2NwdXBvb2xdIC1zICA6IExpc3QgcG9vbC13aWRl IHNjaGVkdWxpbmcgcGFyYW1ldGVycyBmb3IgY3B1cG9vbA0KPiArICogLWMgW2NwdXBvb2xd IC1zIC1hIFswfDFdICA6IFNldCBhZG1pc3Npb24gY29udHJvbCBmb3IgY3B1cG9vbA0KPiAg ICAqLw0KPiAgIGludCBtYWluX3NjaGVkX3J0ZHMoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQ0K PiAgIHsNCj4gQEAgLTczNiw3ICs3NjUsMTAgQEAgaW50IG1haW5fc2NoZWRfcnRkcyhpbnQg YXJnYywgY2hhciAqKmFyZ3YpDQo+ICAgICAgIGJvb2wgb3B0X2IgPSBmYWxzZTsNCj4gICAg ICAgYm9vbCBvcHRfZSA9IGZhbHNlOw0KPiAgICAgICBib29sIG9wdF92ID0gZmFsc2U7DQo+ ICsgICAgYm9vbCBvcHRfcyA9IGZhbHNlOw0KPiArICAgIGJvb2wgb3B0X2EgPSBmYWxzZTsN Cj4gICAgICAgYm9vbCBvcHRfYWxsID0gZmFsc2U7IC8qIG91dHB1dCBwZXItZG9tIHBhcmFt ZXRlcnMgKi8NCj4gKyAgICBib29sIGFkbWlzc2lvbl9jb250cm9sID0gZmFsc2U7DQo+ICAg ICAgIGludCBvcHQsIGksIHJjLCByOw0KPiAgICAgICBzdGF0aWMgc3RydWN0IG9wdGlvbiBv cHRzW10gPSB7DQo+ICAgICAgICAgICB7ImRvbWFpbiIsIDEsIDAsICdkJ30sDQo+IEBAIC03 NDUsMTAgKzc3NywxMiBAQCBpbnQgbWFpbl9zY2hlZF9ydGRzKGludCBhcmdjLCBjaGFyICoq YXJndikNCj4gICAgICAgICAgIHsiZXh0cmF0aW1lIiwgMSwgMCwgJ2UnfSwNCj4gICAgICAg ICAgIHsidmNwdWlkIiwxLCAwLCAndid9LA0KPiAgICAgICAgICAgeyJjcHVwb29sIiwgMSwg MCwgJ2MnfSwNCj4gKyAgICAgICAgeyJzY2hlZHBhcmFtIiwgMCwgMCwgJ3MnfSwNCj4gKyAg ICAgICAgeyJhZG1pc3Npb24iLCAxLCAwLCAnYSd9LA0KPiAgICAgICAgICAgQ09NTU9OX0xP TkdfT1BUUw0KPiAgICAgICB9Ow0KPiAgIA0KPiAtICAgIFNXSVRDSF9GT1JFQUNIX09QVChv cHQsICJkOnA6YjplOnY6YyIsIG9wdHMsICJzY2hlZC1ydGRzIiwgMCkgew0KPiArICAgIFNX SVRDSF9GT1JFQUNIX09QVChvcHQsICJkOnA6YjplOnY6YzphOnMiLCBvcHRzLCAic2NoZWQt cnRkcyIsIDApIHsNCj4gICAgICAgY2FzZSAnZCc6DQo+ICAgICAgICAgICBkb20gPSBvcHRh cmc7DQo+ICAgICAgICAgICBicmVhazsNCj4gQEAgLTgwMSw2ICs4MzUsMTkgQEAgaW50IG1h aW5fc2NoZWRfcnRkcyhpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQo+ICAgICAgIGNhc2UgJ2Mn Og0KPiAgICAgICAgICAgY3B1cG9vbCA9IG9wdGFyZzsNCj4gICAgICAgICAgIGJyZWFrOw0K PiArICAgIGNhc2UgJ3MnOg0KPiArICAgICAgICBvcHRfcyA9IHRydWU7DQo+ICsgICAgICAg IGJyZWFrOw0KPiArICAgIGNhc2UgJ2EnOg0KPiArICAgICAgICBpZiAoc3RyY21wKG9wdGFy ZywgIjAiKSAmJiBzdHJjbXAob3B0YXJnLCAiMSIpKQ0KPiArICAgICAgICB7DQo+ICsgICAg ICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkludmFsaWQgYWRtaXNzaW9uX2NvbnRyb2wgdmFs dWUuXG4iKTsNCj4gKyAgICAgICAgICAgIHIgPSBFWElUX0ZBSUxVUkU7DQo+ICsgICAgICAg ICAgICBnb3RvIG91dDsNCj4gKyAgICAgICAgfQ0KPiArICAgICAgICBhZG1pc3Npb25fY29u dHJvbCA9IHN0cnRvbChvcHRhcmcsIE5VTEwsIDEwKTsNCj4gKyAgICAgICAgb3B0X2EgPSB0 cnVlOw0KPiArICAgICAgICBicmVhazsNCj4gICAgICAgfQ0KPiAgIA0KPiAgICAgICBpZiAo Y3B1cG9vbCAmJiAoZG9tIHx8IG9wdF9wIHx8IG9wdF9iIHx8IG9wdF9lIHx8IG9wdF92IHx8 IG9wdF9hbGwpKSB7DQo+IEBAIC04MDksNiArODU2LDExIEBAIGludCBtYWluX3NjaGVkX3J0 ZHMoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQ0KPiAgICAgICAgICAgciA9IEVYSVRfRkFJTFVS RTsNCj4gICAgICAgICAgIGdvdG8gb3V0Ow0KPiAgICAgICB9DQo+ICsgICAgaWYgKG9wdF9z ICYmIChkb20gfHwgb3B0X3AgfHwgb3B0X2IgfHwgb3B0X2UgfHwgb3B0X3YgfHwgb3B0X2Fs bCkpIHsNCj4gKyAgICAgICAgZnByaW50ZihzdGRlcnIsICItcyBjYW5ub3QgYmUgY29tYmlu ZWQgd2l0aCBkb21haW4vVkNQVSBvcHRpb25zLlxuIik7DQo+ICsgICAgICAgIHIgPSBFWElU X0ZBSUxVUkU7DQo+ICsgICAgICAgIGdvdG8gb3V0Ow0KPiArICAgIH0NCj4gICAgICAgaWYg KCFkb20gJiYgKG9wdF9wIHx8IG9wdF9iIHx8IG9wdF9lIHx8IG9wdF92KSkgew0KPiAgICAg ICAgICAgZnByaW50ZihzdGRlcnIsICJNaXNzaW5nIHBhcmFtZXRlcnMuXG4iKTsNCj4gICAg ICAgICAgIHIgPSBFWElUX0ZBSUxVUkU7DQo+IEBAIC04MzEsNiArODgzLDQ5IEBAIGludCBt YWluX3NjaGVkX3J0ZHMoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQ0KPiAgICAgICAgICAgciA9 IEVYSVRfRkFJTFVSRTsNCj4gICAgICAgICAgIGdvdG8gb3V0Ow0KPiAgICAgICB9DQo+ICsg ICAgaWYgKG9wdF9hICYmICFvcHRfcykgew0KPiArICAgICAgICBmcHJpbnRmKHN0ZGVyciwg Ii1hLy0tYWRtaXNzaW9uIHJlcXVpcmVzIC1zLy0tc2NoZWRwYXJhbS5cbiIpOw0KPiArICAg ICAgICByID0gRVhJVF9GQUlMVVJFOw0KPiArICAgICAgICBnb3RvIG91dDsNCj4gKyAgICB9 DQo+ICsNCj4gKyAgICBpZiAob3B0X3MpDQo+ICsgICAgew0KPiArICAgICAgICBsaWJ4bF9z Y2hlZF9ydGRzX3BhcmFtcyBzY3BhcmFtOw0KPiArICAgICAgICB1aW50MzJfdCBwb29saWQg PSAwOw0KPiArDQo+ICsgICAgICAgIGlmIChjcHVwb29sKSB7DQo+ICsgICAgICAgICAgICBp ZiAobGlieGxfY3B1cG9vbF9xdWFsaWZpZXJfdG9fY3B1cG9vbGlkKGN0eCwgY3B1cG9vbCwN Cj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZwb29saWQsIE5VTEwpIHx8DQo+ICsgICAgICAgICAgICAgICAgIWxpYnhsX2NwdXBv b2xpZF9pc192YWxpZChjdHgsIHBvb2xpZCkpIHsNCj4gKyAgICAgICAgICAgICAgICBmcHJp bnRmKHN0ZGVyciwgIlVua25vd24gY3B1cG9vbCBcJyVzXCdcbiIsIGNwdXBvb2wpOw0KPiAr ICAgICAgICAgICAgICAgIHIgPSBFWElUX0ZBSUxVUkU7DQo+ICsgICAgICAgICAgICAgICAg Z290byBvdXQ7DQo+ICsgICAgICAgICAgICB9DQo+ICsgICAgICAgIH0NCj4gKw0KPiArICAg ICAgICBpZiAoIW9wdF9hKSB7IC8qIG91dHB1dCBwb29sLXdpZGUgc2NoZWR1bGluZyBwYXJh bWV0ZXJzICovDQo+ICsgICAgICAgICAgICBpZiAoc2NoZWRfcnRkc19wb29sX291dHB1dChw b29saWQpKSB7DQo+ICsgICAgICAgICAgICAgICAgciA9IEVYSVRfRkFJTFVSRTsNCj4gKyAg ICAgICAgICAgICAgICBnb3RvIG91dDsNCj4gKyAgICAgICAgICAgIH0NCj4gKyAgICAgICAg fSBlbHNlIHsgLyogc2V0IHBvb2wtd2lkZSBzY2hlZHVsaW5nIHBhcmFtZXRlcnMgKi8NCj4g KyAgICAgICAgICAgIGlmIChzY2hlZF9ydGRzX3BhcmFtc19nZXQocG9vbGlkLCAmc2NwYXJh bSkpIHsNCj4gKyAgICAgICAgICAgICAgICByID0gRVhJVF9GQUlMVVJFOw0KPiArICAgICAg ICAgICAgICAgIGdvdG8gb3V0Ow0KPiArICAgICAgICAgICAgfQ0KPiArDQo+ICsgICAgICAg ICAgICBzY3BhcmFtLmFkbWlzc2lvbl9jb250cm9sX2VuYWJsZWQgPSBhZG1pc3Npb25fY29u dHJvbDsNCg0KSSdkIHByZWZlcjoNCisgICAgICAgICAgICBzY3BhcmFtID0geyAuYWRtaXNz aW9uX2NvbnRyb2xfZW5hYmxlZCA9IGFkbWlzc2lvbl9jb250cm9sLCB9Ow0KDQpUaGlzIHdp bGwgbm90IGxldCBhbnkgbGF0ZXIgYWRkZWQgZmllbGRzIHVuZGVmaW5lZC4NCg0KDQpKdWVy Z2VuDQo= --------------8FOHKea6wjpsew6i0U9miZK0 Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------8FOHKea6wjpsew6i0U9miZK0-- --------------58v0cEotoY9vT72QFNgbnwhu-- --------------4m4tloNBtRlg2QpqnNioGKh8 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqtBkcFAwAAAAAACgkQsN6d1ii/Ey+U Rgf+I5rGQYh1DstZRml4myELTrbfc/FNnlJ9+bIMSY9AKhN6JKYAqQWPbUKxKAipyzo811AseqPa mmSP4K0It+J5aqx+tpic0kpN77cNe6ZvgeK8LELSXNxYVXpinU1dQjUw+m+Get00bw0KZ5jMpjGf 17bX2PAChNE6YS+KJAUh05ShzpKVjbAYMxbTFENe4Hg6lVSCkjJ36tKhpfNxbQfODbDSbgjFwuMI UkdtiELrVg2DitGmc/tYSlNOiE86pz/1cog5q8LaZbhIuXzYLPWPjq9MnumCDuPHS64UwtxN3cQH XcZf2nUJS3BBSGaGkBO2RpfulMr5LgxB5Kff3tgeiQ== =nQmB -----END PGP SIGNATURE----- --------------4m4tloNBtRlg2QpqnNioGKh8-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:40:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:40:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425082.1649238 (Exim 4.92) (envelope-from ) id 1x7V55-0007ct-GI; Fri, 18 Sep 2026 09:40:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425082.1649238; Fri, 18 Sep 2026 09:40:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7V55-0007cm-DO; Fri, 18 Sep 2026 09:40:31 +0000 Received: by outflank-mailman (input) for mailman id 1425082; Fri, 18 Sep 2026 09:40:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7V54-0007cg-Cc for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:40:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7V53-00AmjB-5z for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:40:29 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad0702-8faa-0a2a0a5109dd-0a2a4506be14-34 for ; Fri, 18 Sep 2026 11:40:29 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad070c-195a-0a2a45060019-4a7de18caf34-3 for ; Fri, 18 Sep 2026 11:40:29 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e2406so2717085e9.1 for ; Fri, 18 Sep 2026 02:40:28 -0700 (PDT) Received: from [172.18.138.134] ([185.104.138.149]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd1d0978sm140552405e9.2.2026.09.18.02.40.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 02:40:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789724428; x=1790329228; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=JkNFZK8zTFrojIsmneiElLQx70lonjihw5v2IEa9ZLw=; b=g8oNRoTn15JQ/HpIqVh5yOLRhNhbJ2eGiTIGHktyxiRaFuwKTZuk7RR3imyNKhMuY+ LR3Ejm3UGicJPWmXhmuBD87PuZ0DU0x1HLV2lf+9CtLqtsn4To+uZ+1BIP14+QsK14va ArFV8DQTaj8wrxbByZONVq6YPyCqL2s66QtiqW89Sa9+51oe7GWzlmuFvgrJbO8HLcw7 JH+7O5uUuMF7/GwGCNcInlCvRl1D3uvdxjQ8CNkWrrBiXhyfx0Jt0BYa6fTbOuSksuVE Dc79HFPp1p6H0uUqYaWOpnj3ApL7wfzVnlacInX8sRSGBbOM6E5HF1on4+OaeE6m0CSU kApA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789724428; x=1790329228; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=JkNFZK8zTFrojIsmneiElLQx70lonjihw5v2IEa9ZLw=; b=AzU7duVc4WQyLtJFx+9K2QkU6BF6HTX0BMcl2J9ZPu+5ozD0tEwDFLvKVIQiT3CxIJ 4vfROmLp4PklojiVM0ILZja1fbP7rrDWfBT/a0oO0TnxExJeLmioXC7KlkfiTZ68pBtv OKY+33DzR9L0LOAaMPMSwi3Cqy5f5QeSDJxxBQ5NPJORV3tIYtRBgzjiY/HLJP/5NjLj 8Ruzey1lSQ6AXj/BKkajMnIsK4r91eijdksZArj2WpfynnzQQNReQAwvOyuBXZLpx8R1 FuqpH81NddEhcH2D51GpVJbWrkQwI8S/Yxf75hFUg14+M/1KH9cCQXpv59UM24DxBxBV O3Qw== X-Forwarded-Encrypted: i=1; AKwUvBy1hLGAK5QRAoYi9CFCJVy67K1JbW7fYx78fSATxcTnzmMyBIuLhrHFTn0rOP04MzTOP7Oa5Y+MqtE=@lists.xenproject.org X-Gm-Message-State: AFuF++kTalnOLiUTU+7TF90M/7jbInTiavRM2Ky8j5XvrDP/Nbyc5pvo PyGh61MY98+Uz2eamOdughKCqH9eMt3LrUO+hK1aHDWcyVCBaW13sWvZET4PXuxnQQ== X-Gm-Gg: AYBFou2gJfgJr57JlZB9/tZSsLrVHhCw73DQ2qeEgyo/sBq101B3veQeBBWGm5yeL86 vONFgKi7Y0ZWNwkDK8eFqDMq2twG2Xk/8nUX+2EicrQWNi3xbdhdUMkx2Jiod/t6EsyOiovnil7 WUrnsZa3Rs+zR1I0G8Xy5MO3QMDCYXdnBkcFMDHfNfmnwhqt1Om+1u0lPJu83jzu1HUV0JPGO4A 1744k9Pbll87K3QPimXsERoyWli5zAx9LTzgdilhio2G4TuEJVDb2D4cdWR50K2GvljI7Gv2lY6 QtXFrFQfrwYXVHUVKppLxqd5RHF9+k8hJC9A3kZ+HMczGRYJ9+QJ04GEuUaqzcpNJBnh+Or05xw nNbbGX8xhj4ZBxTbawJsDi2DdrwzPXVtdolXsFOWPRA/Co5IGAFwBGtu8klPsHWHuQq8ywwdkvB bovp05i+9E+Uf+DtTv9lkw4BapujYGsjhGF2tByNJ4dqa59fc/OdX3B3U6kRHod//Xn7qvMdx6w z3kCiB/w80= X-Received: by 2002:a05:600c:83c9:b0:49c:f13e:e4d with SMTP id 5b1f17b1804b1-49fc4ff402cmr26600375e9.10.1789724428452; Fri, 18 Sep 2026 02:40:28 -0700 (PDT) Message-ID: Date: Fri, 18 Sep 2026 11:40:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Furkan Caliskan Cc: jgross@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, xen-devel@lists.xenproject.org References: <20260918080935.35498-2-frn1furkan10@gmail.com> <20260918092433.42891-1-frn1furkan10@gmail.com> Content-Language: en-US From: Jan Beulich In-Reply-To: <20260918092433.42891-1-frn1furkan10@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789724429-FCE0677B-73ED34CB/0/0 X-purgate-type: clean X-purgate-size: 2077 On 18.09.2026 11:24, Furkan Caliskan wrote: > RTDS has no admission control: nothing stops the sum of all admitted > units' (budget/period) reservations in a cpupool from exceeding > what its pCPUs can actually provide. Once that happens, none of the > EDF deadline guarantees this scheduler is built around still hold > for the units sharing that pool. > > Introduce admission control to prevent this: reject a reservation > whenever admitting it would push a cpupool's units over its capacity. > Track a running utilization total per cpupool, and enforce it in > rt_alloc_udata()/rt_free_udata(), the paired lifecycle hooks for a > unit's creation and destruction. This catches the default > period/budget every new unit gets. > > Utilization is represented as a fixed-point value: budget is > left shifted by RTDS_UTIL_SHIFT (20 bits) and divided by period. > A plain "(budget << RTDS_UTIL_SHIFT) / period" risks overflowing > the multiply for large enough budgets. Rather than widen the > arithmetic to tolerate any input, the input itself is bounded: > rt_validate_params() rejects any budget above RTDS_MAX_BUDGET, > chosen as the largest value that can be left-shifted by > RTDS_UTIL_SHIFT without overflowing 64 bits, so the shift in > rt_unit_utilization() can never overflow. > > A cpupool's capacity rt_utilization_cap() scales with the number of > scheduling resources in it. It is calculated as: > (number of sched_resources * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100), > where RTDS_UTIL_CAP_PCT controls how much of that capacity can > actually be reserved; at 100% (its current value), all of it can be. > > Signed-off-by: Furkan Caliskan > Reviewed-by: Juergen Gross > --- > v3: > - Fixed indentation. Looks like you re-sent only this one patch as v3. Such can be a little confusing. We tend to call such version 2.1 or 2.5 (using this example), to better identify that it is not a while new version of a series. Just for possible future situations like this one. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:42:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:42:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425088.1649246 (Exim 4.92) (envelope-from ) id 1x7V6g-00087k-Pn; Fri, 18 Sep 2026 09:42:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425088.1649246; Fri, 18 Sep 2026 09:42:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7V6g-00087d-ND; Fri, 18 Sep 2026 09:42:10 +0000 Received: by outflank-mailman (input) for mailman id 1425088; Fri, 18 Sep 2026 09:42:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7V6e-00087T-Ue for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:42:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7V6e-004BAg-BB for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:42:08 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad076e-8faa-0a2a0a5109dd-0a2a4506c780-8 for ; Fri, 18 Sep 2026 11:42:08 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad076f-195a-0a2a45060019-4a7de14cb8a3-3 for ; Fri, 18 Sep 2026 11:42:07 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485b1d2874fso174555f8f.0 for ; Fri, 18 Sep 2026 02:42:07 -0700 (PDT) Received: from [172.18.88.57] (195-200-20-130.mclarenap.oninferno.net. [195.200.20.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd1d0d0bsm140631665e9.1.2026.09.18.02.42.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 02:42:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789724527; x=1790329327; darn=lists.xenproject.org; h=content-type: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:content-type; bh=xZxmXurO/zMXpYcPg73jUkm+aHbQJfB2CaH7jtLdvEM=; b=FeSgR1wH2JVemYH8FOl8bsf0wlkSg1vJ9DJALluQDyeVPuyNIUyucE+My2NlzgJgzE o/9HRPQIru0kekLJlB9VtQCmxVWXIPLqP1eFn59yceG+xp2FTU2LEnY3EJiY48xrWT2K zb7QmHAQdKyymWxobNcX6eZBl/5LhfgnI+2l2JkL5S0viJqq2zkGmAloVuVXrXBjC7OU gf1vq/PzWdBiVdLv/muoWaHfMoNl+wbIhwwKB/CMzFBbao05cAGkcDJgsl904sRx3ZlS tsx9VSyvxTHsKlyRS1ABTxCaDtfsnylQOp9Wd/iYKpG06sylgJcY2PkZemjuU4rHB63B TtXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789724527; x=1790329327; h=content-type: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 :content-type; bh=xZxmXurO/zMXpYcPg73jUkm+aHbQJfB2CaH7jtLdvEM=; b=uDwg/3t8lawkLBHl6UVaWvRly2za89id8RnuRFQpcmNzwdqIUw37V49E0jP/XOi5Q+ csXKD7+r3nq+9I7M5Dv/qyt2U6Cn+I3JgSXOkQsvNvWsZz9zzUWgfUvwoSdvNbFj92na UQg7eiqorMioZTf1+FSTaiEwXk87aLkCyBj/O44PnJiIXFZGwyWdYXg+l9e+iPEFzPoe KdKCDQ+AN73eO+lMSJ9wWNskZPYlsjoa8uSGgPommrkN9Po8rUm040IYzSBSWHCrqz8p Gn2X+Vnadla0VvAuVP9O3Edl/nwunzDfg0pzA9mHuE9FyTzMUBnXsHbe1iK2hy1QDfvj q/6Q== X-Forwarded-Encrypted: i=1; AKwUvByZBTgjIg2La33/E7cCXwu5SwG8xPoeoUcBKgPx0mI7gGZ39l7M4pf+ySm723/zmba0f4vgzZOSrnk=@lists.xenproject.org X-Gm-Message-State: AFuF++k+qrJdpIsmYrKx9V9OdQWzX/nBA9RRTlpSsStjO143199mFsTF Tgv1nEUMbDOD/pR5Q5Q3JmNcDt08x3esuYu24M3hlR3PnSUgIuVfewWBy7wzOmdvHxk= X-Gm-Gg: AYBFou0RjXgXhrHk/sbgMrPsbdDKKv2i0QPDrCJeHoqMlbcL9P3+hdF9Z8x2JKxzX8y 6gtbVOPDivO3onvefVEKcleFQ68jU1qiE6xQVC9d0szREvLRLaeZDgyP9np438TRJmgD6vspcGR 3bzuLViEiQ0dPEN6pbLyHoQoKQTjL0Cjdo6sjL0eysj5pndxC7Uc9Zhjp5pR1aPs0do8zWS/i9t NyYv5OnBiZZACGe6KZRpQRCys8QZAAx+4/5wGVM7URrO6YbwIKPTS4/x0TM2UGIHJ4YEGTnpv8o xuvJpLpPo0vBryM+7XFJAR3UqDkIsX66XO0/J8Zjpwzwt73zCK7g8MaLwHIDkbkfQKOW/751zMk 2PgO3mFajLq6J5z5TedFzy5wzSFnYSuNeMMIS4W2yzPSA1+7zjO0bQlpu3JX4X4P3bAfop6Dc+y JDE3M2keLL2XAcqTweg+8O6oYfS6qskRsNArbPf2MOITRMXVTJOpGUUurdC5EL4aGVKTs4J3Rdt 9vBk3vH6H7NVOzzWiRh6nhHh7HziyDJUR7l0VQNiQIzQLwzgg== X-Received: by 2002:a05:600c:4714:b0:49e:6581:7baf with SMTP id 5b1f17b1804b1-49fc4f72886mr28083875e9.2.1789724527375; Fri, 18 Sep 2026 02:42:07 -0700 (PDT) Message-ID: <7999b875-7683-41b3-bb2c-6e7616238e20@suse.com> Date: Fri, 18 Sep 2026 11:41:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs: clarify tag sequence in sending-patches To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260918065614.11003-1-jgross@suse.com> <12da547c-a67a-4f46-bee5-666cc26fc976@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <12da547c-a67a-4f46-bee5-666cc26fc976@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------oVGnxEFt7MNBMmHJIZgTQyu3" X-purgate-ID: tlsNG-16d1c6/1789724528-FDC0F77B-B28DFC0F/35/110847 X-purgate-type: clean X-purgate-size: 8507 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------oVGnxEFt7MNBMmHJIZgTQyu3 Content-Type: multipart/mixed; boundary="------------PQqTuVme0I989NuOfeja3ojI"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org Message-ID: <7999b875-7683-41b3-bb2c-6e7616238e20@suse.com> Subject: Re: [PATCH] docs: clarify tag sequence in sending-patches References: <20260918065614.11003-1-jgross@suse.com> <12da547c-a67a-4f46-bee5-666cc26fc976@suse.com> In-Reply-To: <12da547c-a67a-4f46-bee5-666cc26fc976@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------PQqTuVme0I989NuOfeja3ojI Content-Type: multipart/mixed; boundary="------------FaBuzmlOBhJ1xYrvtVSkJaUa" --------------FaBuzmlOBhJ1xYrvtVSkJaUa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTguMDkuMjYgMTE6MzUsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxOC4wOS4yMDI2 IDA4OjU2LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gTWFrZSBjbGVhciB3aGF0IGFuICJB c3Npc3RlZC1ieTogdGFnIHRhZyByZWxhdGVzIHRvIGluDQo+PiBzZW5kaW5nLXBhdGNoZXMu cGFuZG9jLg0KPiANCj4gSSBndWVzcyB3aGVuIGNvbW1pdHRpbmcgSSdsbCB0YWtlIHRoZSBs aWJlcnR5IHRvIHJlcGxhY2UgdGhlIHJlZHVuZGFudA0KPiAidGFnIiB3aXRoIHRoZSBtaXNz aW5nIGNsb3NpbmcgZG91YmxlIHF1b3RlLg0KDQpPaCwgc3VyZSwgc29ycnkgZm9yIHRoYXQg dHlwby4gSSBibGFtZSBpdCBvbiBkb2luZyB0aGlzIG9uIHRoZSB0cmFpbi4gOi0pDQoNCj4g DQo+PiBBZGQgdGhlIHBvc3NpYmlsaXR5IHRvIGNsYXJpZnkgaG93IEFJIHdhcyB1c2VkLg0K Pj4NCj4+IFNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4N Cj4gDQo+IEFja2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQoNClRo YW5rcywNCg0KDQpKdWVyZ2VuDQo= --------------FaBuzmlOBhJ1xYrvtVSkJaUa Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------FaBuzmlOBhJ1xYrvtVSkJaUa-- --------------PQqTuVme0I989NuOfeja3ojI-- --------------oVGnxEFt7MNBMmHJIZgTQyu3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqtB0gFAwAAAAAACgkQsN6d1ii/Ey8J 0wf/cvq2aOi8G6jDf14YmAjPsyrKICQKL6kBV9QJEOW3WoC56RyBUPEdIp7F1Ne/iDAub+k10baR v8k6lVIFP1xsEz6PL11oEsbuG+bRmfzibrXkpTqkas3P8CtHQVnxi13brsy22H0InTwBWzOSj+mw knLb2L808jD0ziySYR3OvnnMLTCJ+P3/TjC1BqfJwCG+UWyokLkfn3AwZlpzjYNxD+gdsNlRv9Tt RDhpPyHaDPzWFWhYwwcsctKp3VNtuSu6b2QKDsmajSRR8YaY4igRJoWnqEcixrwLJFHGt1TdkyyN rW0KyN4yVXlLYWkmx65W8LQZnLJwwGTb2IrPLVPAWw== =SKI8 -----END PGP SIGNATURE----- --------------oVGnxEFt7MNBMmHJIZgTQyu3-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 09:53:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 09:53:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425102.1649255 (Exim 4.92) (envelope-from ) id 1x7VGu-0001cR-Nv; Fri, 18 Sep 2026 09:52:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425102.1649255; Fri, 18 Sep 2026 09:52:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7VGu-0001cK-LF; Fri, 18 Sep 2026 09:52:44 +0000 Received: by outflank-mailman (input) for mailman id 1425102; Fri, 18 Sep 2026 09:52:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7VGt-0001cE-Ko for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 09:52:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7VGs-004DTz-JN for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:52:42 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad09dc-2eae-0a2a0a5409dd-0a2a4507b2ea-26 for ; Fri, 18 Sep 2026 11:52:42 +0200 Received: from [74.125.225.91] (helo=mail-wr2-f27.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad09e7-b4ea-0a2a45070019-4a7de15b8004-3 for ; Fri, 18 Sep 2026 11:52:39 +0200 Received: by mail-wr2-f27.google.com with SMTP id ffacd0b85a97d-4843796e373so271454f8f.1 for ; Fri, 18 Sep 2026 02:52:39 -0700 (PDT) Received: from [192.168.1.109] ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4872008fe3csm2806756f8f.37.2026.09.18.02.52.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 02:52:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789725159; x=1790329959; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Q/0aBLZ40qPCDMQW2ETkl5PuRjguo7TqETKUQV49c7Q=; b=T7z0+6FBfPRAUlKRYt2uNUFMdtPH4wkFC8XIQdztcbbN7qQbMg1DR2pcDpOiAqCjTf YVCpAJtvTAmmw8cGQIi/hVdoTXsqa/DZ+5FUbbCgmxiNGr6IcwSuJfLhgcqHhZ0valy9 T6t3x26GLJdsk8ieTAdNKB/xhnZVeTDVYhQx8LXhImfRCc3ZpmSxFPtjV6O3jEuO3Dc/ 0XYTmPkAwlAJC/kkGmk0XlfbGZrt18UzsfQrZSEHVw9SW6kQvlsX74cRVwU2crSdKyrK 8pRvm8Bm3AfqdajCCZfoYpffixka07ygU2J49wcj17woGPZCBjJt9MMLG+4vKzKeydwp 943w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789725159; x=1790329959; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=Q/0aBLZ40qPCDMQW2ETkl5PuRjguo7TqETKUQV49c7Q=; b=yZyRiA4QHtIC64RUp3ltumsAFsOcq1mwnNJV/AarMKU+dCGevQ8w5Ax+exGQRpxpXH PUOVzJK0GSy6ad32qbyj5s04NTmxISHgtRtsK2o27DvV1+9XRjBmG071VX0BiUXfIkAZ Rx4Y41wovl7mrFsL4KlpM7KU+Kk2C2OetweQY5WfwQyheITlckw4epJ6+8uJDvf+TAka Nqb6pcXSvhSv52sAZIiwqMRUFXgjSHEkbBnAecrBERYl5EsT413AO4rdoOjTXlwjGCV0 IybpEuqaTir0UbpV60DYjEgoPi7BvUW+5uF2dVpt1HGfKixoA1KF8fbm1sbINB6ktZNL cboA== X-Forwarded-Encrypted: i=1; AKwUvBwxF67ZbCDv3SAc9NJXghDYv/QTmYfbn6yfMzjRf2TU987hY8LKRXu58Rsdm+cTHDMovgw8qpfn5Io=@lists.xenproject.org X-Gm-Message-State: AFuF++lbUyi2niPmFOSpfEBF6p/xQ/PErPlbw62q1kvoraQ9eJQscwxR YoetcPodTXEq53YX9ERVay6k6zcrPlA/ZLNw5uOPiiKZKJftrPQpRhNLtJxDXg== X-Gm-Gg: AYBFou3QEyMXUaNUXdEVkPcIdPvQ/PANg4/zPjv1zJxoOG0fSDgFhK7X3AzqB8YWKmg dqiLEuM+tuI5qLbY9M1y68iZUf8qAcZr8j5h0os3pYcaTjs5Gv7Z6tfv/+88I6bSHR7G4w4lgto DC5O5V6b2oGRm/84X+MciKuMaA2/njjgVRDn2BTP+7KuES3pigdAVDrot/KD6+SIUieXuRxZvRO E1MpFhSNfcT233PcYzxWm9/JkBfltMfvtfOjsiZx/DOCKkchvz37jpK576MLoOFKPDcukiIfN1+ E4+uw18/AyS3gNUkL90hDkvV4IJ4Kc/LfPvq5WiD4L0k6syfwM8ptun+HIt6oVJ7cYa+nPtwc11 Zid1aLVKr0mYxJMFlPM31isTpUD9oqOZHrhDrKX+ZWoJvvBDO0glTZ5XGentIGbai1nHahbTxiF X4yXB0k82HExMnznKy33aR80tvoUpk1gy9XxUrHxawzoJPrUMKv/4ite4rQk5yFRW4rHDVLnaO3 q94DQ== X-Received: by 2002:a05:6000:310c:b0:487:732:9964 with SMTP id ffacd0b85a97d-4871e220623mr2359795f8f.13.1789725159045; Fri, 18 Sep 2026 02:52:39 -0700 (PDT) Message-ID: Date: Fri, 18 Sep 2026 12:52:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/5] xen/sched: rtds: add global-EDF utilization admission control To: Jan Beulich Cc: jgross@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, xen-devel@lists.xenproject.org References: <20260918080935.35498-2-frn1furkan10@gmail.com> <20260918092433.42891-1-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789725159-A48C9AE4-561DEAA6/0/0 X-purgate-type: clean X-purgate-size: 2224 On 9/18/26 12:40, Jan Beulich wrote: > On 18.09.2026 11:24, Furkan Caliskan wrote: >> RTDS has no admission control: nothing stops the sum of all admitted >> units' (budget/period) reservations in a cpupool from exceeding >> what its pCPUs can actually provide. Once that happens, none of the >> EDF deadline guarantees this scheduler is built around still hold >> for the units sharing that pool. >> >> Introduce admission control to prevent this: reject a reservation >> whenever admitting it would push a cpupool's units over its capacity. >> Track a running utilization total per cpupool, and enforce it in >> rt_alloc_udata()/rt_free_udata(), the paired lifecycle hooks for a >> unit's creation and destruction. This catches the default >> period/budget every new unit gets. >> >> Utilization is represented as a fixed-point value: budget is >> left shifted by RTDS_UTIL_SHIFT (20 bits) and divided by period. >> A plain "(budget << RTDS_UTIL_SHIFT) / period" risks overflowing >> the multiply for large enough budgets. Rather than widen the >> arithmetic to tolerate any input, the input itself is bounded: >> rt_validate_params() rejects any budget above RTDS_MAX_BUDGET, >> chosen as the largest value that can be left-shifted by >> RTDS_UTIL_SHIFT without overflowing 64 bits, so the shift in >> rt_unit_utilization() can never overflow. >> >> A cpupool's capacity rt_utilization_cap() scales with the number of >> scheduling resources in it. It is calculated as: >> (number of sched_resources * RTDS_UTIL_SCALE * RTDS_UTIL_CAP_PCT / 100), >> where RTDS_UTIL_CAP_PCT controls how much of that capacity can >> actually be reserved; at 100% (its current value), all of it can be. >> >> Signed-off-by: Furkan Caliskan >> Reviewed-by: Juergen Gross >> --- >> v3: >> - Fixed indentation. > > Looks like you re-sent only this one patch as v3. Such can be a little > confusing. We tend to call such version 2.1 or 2.5 (using this example), > to better identify that it is not a while new version of a series. Just > for possible future situations like this one. > > Jan Thanks, I'll keep it in mind for next time. Furkan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 10:41:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 10:41:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425118.1649265 (Exim 4.92) (envelope-from ) id 1x7W25-00007t-BA; Fri, 18 Sep 2026 10:41:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425118.1649265; Fri, 18 Sep 2026 10:41:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7W25-00007k-7f; Fri, 18 Sep 2026 10:41:29 +0000 Received: by outflank-mailman (input) for mailman id 1425118; Fri, 18 Sep 2026 10:41:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7W24-000065-0g for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:41:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7W22-00AyQX-QB for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 12:41:26 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad1556-8faa-0a2a0a5109dd-0a2a4505c584-2 for ; Fri, 18 Sep 2026 12:41:26 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad1556-4cb1-0a2a45050019-4a7de18dd180-3 for ; Fri, 18 Sep 2026 12:41:26 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e83a388f8so3677985e9.1 for ; Fri, 18 Sep 2026 03:41:26 -0700 (PDT) Received: from notebook.. ([88.230.43.170]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fbd24034esm177231125e9.15.2026.09.18.03.41.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 03:41:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789728086; x=1790332886; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JOJ74v/vCGAVFOz41fLecfvlvMNA2bb5S4xdvE9EXk0=; b=nhDH0tjMDlpJf7ak8mKMT3L3LdFgH6f+6NOTUZW4fO7k2ojX50EK+txdRxo0jcKoaX 7LxqjqdEQlWNG4ySyK9KvJQzccEahlnZIatjVTDfpxexiiqXlDeQhGBP6A4+laKVBem4 kTmfnvhnZxbE6J52XAq3eSBLrWD7mdsu/RVjMbfB+HzXXtkiuilQcGJceShPp1W/HA9h LKdhktAgk8Kb74gOWFREKikqNtgIeu/Hu/J5sHEd20/9M2YIPcPa1JVBFLVUUC4cGmSk +aP8Ju3WqsUXP1Po2j9D+RaF7an8QFYSx2TlQdnpkEybXgzeL6hQIM0cBfhv+J6kMBkv d/Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789728086; x=1790332886; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=JOJ74v/vCGAVFOz41fLecfvlvMNA2bb5S4xdvE9EXk0=; b=E/XmwfT+JpQlN7fflgQksHDmCV4P6jp8KmM9BbWwfBaUMrhTwNiuSgf0iaIMw5WTE0 rTD7cFOlFpqSoeu8LMY0EoYC5rCUBNCMeMJU1c/ukjNs+gzu7bDFmJ0MXNMcX77Y8uKz 3rQWqBy3Ef2YkigMXfnaoCgOUmRK37SF8Nx4GcXOFtMRdozgbv6bfiugjJvx6AtjArBi ByZq2QKNvBdNFguFC8dlQLHPRDKD56vLIexbF4PSqbKIoSM/6C2jALJOYBANtEDnSo0E peFNOD7Hz0H8c+qi2xr7IKzXd66T2D/EZJYDJtL+WWdvK4jvtoqrAYsxbVe6MT+CRUek TSOQ== X-Gm-Message-State: AFuF++kuk1Dk0PJCVLc0qinF2cPWkqG9NE0ZYVfBPlsxqOcc0Uz8wsv3 QEnpMDMmjw/CjExiBvcUPoTvF29ML9dX1fyDR1yJyCxZ2oxQUlIhc2fMXyzgfA== X-Gm-Gg: AYBFou2WrCrikze8V891P5mhNS6ql7m74bHNkyobXH7+zrrDiv45GhAD2ZQ6WX+KcXw 2F9jSBIY6mJcbT54jAIgYbqW/yJ7RaM88eHI+nHMejqeEdYI8ZtncIIB8HrnRtBXdcrVQHnqM35 23mO10UdAu+XWgBfIKk4798m/7aCkK/RAUWmDcGpjjedW9HHl3eekSGc3yY9ZnuDjA0NjR5I+8J SC5X8ehB7xvDIAxS/LcAXHOkBUli7rgdS59yp395lR1EJotoX+hJiouFV/6PEdCwqvHvdAVp223 ctK3ClgcxizA7oVrxMmKoXDe3hzenDPzKqrDhsdVYvbMRdpn996G0eyMVjpDFXG9nEex2FApO/D Sd15DqBiBBvL9VW/rM/hWpNHBaGiEz5S4dU2Hhz1LTJWGSUJ0HkRcr4DWawaKgK6MEdiZdPuJO1 RDR0fhoGXk2Rvlw45bpwZ9Veu582MUlImxUQgJbQx4A0lNE7ZFBWQBHnHDIwf6O2GNa9SBusTg X-Received: by 2002:a05:600c:4e14:b0:49f:bd3c:bc19 with SMTP id 5b1f17b1804b1-49fc572eff5mr25642445e9.20.1789728086014; Fri, 18 Sep 2026 03:41:26 -0700 (PDT) From: Furkan Caliskan To: xen-devel@lists.xenproject.org Cc: jgross@suse.com, jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, anthony.perard@vates.tech, Furkan Caliskan Subject: [PATCH v2.1 5/5] tools: expose admission control toggle via xl sched-rtds Date: Fri, 18 Sep 2026 13:41:06 +0300 Message-Id: <20260918104106.53530-1-frn1furkan10@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260918080935.35498-6-frn1furkan10@gmail.com> References: <20260918080935.35498-6-frn1furkan10@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1789728086-73ABF2A1-EA48E5A1/0/0 X-purgate-type: clean X-purgate-size: 16574 Wire the per-cpupool admission-control switch through libxl to xl sched-rtds, and document it. Add -s/--schedparam to list or set pool-wide RTDS scheduler parameters, and -a/--admission to enable or disable admission control for a cpupool ("-c pool -s -a 0/1"). Signed-off-by: Furkan Caliskan --- v2.1: - Add LIBXL_HAVE_SCHED_RTDS_PARAMS macro. - Fully initialize scparam via compound literal instead of get-then-modify. --- docs/man/xl.1.pod.in | 20 ++++++ tools/golang/xenlight/helpers.gen.go | 23 ++++++ tools/golang/xenlight/types.gen.go | 4 ++ tools/include/libxl.h | 12 ++++ tools/include/xenctrl.h | 6 ++ tools/libs/ctrl/xc_rt.c | 40 +++++++++++ tools/libs/light/libxl_sched.c | 46 ++++++++++++ tools/libs/light/libxl_types.idl | 5 ++ tools/xl/xl_cmdtable.c | 8 ++- tools/xl/xl_sched.c | 100 +++++++++++++++++++++++++-- 10 files changed, 259 insertions(+), 5 deletions(-) diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index 88ccf7ad82..51405f4e33 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@ -1230,6 +1230,16 @@ the unreserved system resource. Restrict output to domains in the specified cpupool. +=item B<-s>, B<--schedparam> + +Specify to list or set pool-wide scheduler parameters. + +=item B<-a ADMISSION_CONTROL>, B<--admission=ADMISSION_CONTROL> + +Binary flag to enable or disable admission control for the cpupool. +When enabled (the default), a reservation is rejected if admitting +it would exceed the cpupool's utilization capacity. + =back B @@ -1293,6 +1303,16 @@ e.g., "xl sched-rtds -d vm1 -v 0 -p 100 -b 50 -e 1 -v 3 -p 300 -b 150 -e 0". To change the parameters of all the VCPUs of a domain, use B<-v all>, e.g., "xl sched-rtds -d vm1 -v all -p 500 -b 250 -e 1". +4) Use B<-c CPUPOOL -s> to see whether admission control is enabled +for a cpupool, and B<-c CPUPOOL -s -a> to change it: + + xl sched-rtds -c pool-rt -s + Cpupool pool-rt: sched=RTDS admission-control=enabled + + xl sched-rtds -c pool-rt -s -a 0 + xl sched-rtds -c pool-rt -s + Cpupool pool-rt: sched=RTDS admission-control=disabled + =back =back diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index b0c09da910..18ab0731ef 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -4192,6 +4192,29 @@ func (x *SchedCredit2Params) toC(xc *C.libxl_sched_credit2_params) (err error){x return nil } +// NewSchedRtdsParams returns an instance of SchedRtdsParams initialized with defaults. +func NewSchedRtdsParams() (*SchedRtdsParams, error) { +var ( +x SchedRtdsParams +xc C.libxl_sched_rtds_params) + +C.libxl_sched_rtds_params_init(&xc) + +if err := x.fromC(&xc); err != nil { +return nil, err } + +return &x, nil} + +func (x *SchedRtdsParams) fromC(xc *C.libxl_sched_rtds_params) error { + x.AdmissionControlEnabled = bool(xc.admission_control_enabled) + + return nil} + +func (x *SchedRtdsParams) toC(xc *C.libxl_sched_rtds_params) (err error){xc.admission_control_enabled = C.bool(x.AdmissionControlEnabled) + + return nil + } + // NewDomainRemusInfo returns an instance of DomainRemusInfo initialized with defaults. func NewDomainRemusInfo() (*DomainRemusInfo, error) { var ( diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index e0fd78ec03..897100d9b6 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -1231,6 +1231,10 @@ type SchedCredit2Params struct { RatelimitUs int } +type SchedRtdsParams struct { +AdmissionControlEnabled bool +} + type DomainRemusInfo struct { Interval int AllowUnsafe Defbool diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 7c098edab6..617ce973b2 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -229,6 +229,14 @@ */ #define LIBXL_HAVE_SCHED_RTDS 1 +/* + * LIBXL_HAVE_SCHED_RTDS_PARAMS indicates that libxl has the + * libxl_sched_rtds_params type, along with library functions + * libxl_sched_rtds_params_get/set to get and set pool-wide RTDS + * scheduler parameters for a given cpupool. + */ +#define LIBXL_HAVE_SCHED_RTDS_PARAMS 1 + /* * LIBXL_HAVE_SCHED_NULL indicates that the 'null' static scheduler * is available. @@ -2797,6 +2805,10 @@ int libxl_sched_credit2_params_get(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit2_params *scinfo); int libxl_sched_credit2_params_set(libxl_ctx *ctx, uint32_t poolid, libxl_sched_credit2_params *scinfo); +int libxl_sched_rtds_params_get(libxl_ctx *ctx, uint32_t poolid, + libxl_sched_rtds_params *scinfo); +int libxl_sched_rtds_params_set(libxl_ctx *ctx, uint32_t poolid, + libxl_sched_rtds_params *scinfo); /* Scheduler Per-domain parameters */ diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h index 9f00d4a19d..6f4ea7ca62 100644 --- a/tools/include/xenctrl.h +++ b/tools/include/xenctrl.h @@ -897,6 +897,12 @@ int xc_sched_rtds_vcpu_get(xc_interface *xch, uint32_t domid, struct xen_domctl_schedparam_vcpu *vcpus, uint32_t num_vcpus); +int xc_sched_rtds_params_set(xc_interface *xch, + uint32_t cpupool_id, + struct xen_sysctl_rtds_schedule *schedule); +int xc_sched_rtds_params_get(xc_interface *xch, + uint32_t cpupool_id, + struct xen_sysctl_rtds_schedule *schedule); int xc_sched_arinc653_schedule_set( diff --git a/tools/libs/ctrl/xc_rt.c b/tools/libs/ctrl/xc_rt.c index 3cb3fbb923..fb3f567d4f 100644 --- a/tools/libs/ctrl/xc_rt.c +++ b/tools/libs/ctrl/xc_rt.c @@ -130,3 +130,43 @@ int xc_sched_rtds_vcpu_get(xc_interface *xch, return rc; } + +int xc_sched_rtds_params_set(xc_interface *xch, + uint32_t cpupool_id, + struct xen_sysctl_rtds_schedule *schedule) +{ + struct xen_sysctl sysctl = {}; + + sysctl.cmd = XEN_SYSCTL_scheduler_op; + sysctl.u.scheduler_op.cpupool_id = cpupool_id; + sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RTDS; + sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo; + + sysctl.u.scheduler_op.u.sched_rtds = *schedule; + + if ( do_sysctl(xch, &sysctl) ) + return -1; + + *schedule = sysctl.u.scheduler_op.u.sched_rtds; + + return 0; +} + +int xc_sched_rtds_params_get(xc_interface *xch, + uint32_t cpupool_id, + struct xen_sysctl_rtds_schedule *schedule) +{ + struct xen_sysctl sysctl = {}; + + sysctl.cmd = XEN_SYSCTL_scheduler_op; + sysctl.u.scheduler_op.cpupool_id = cpupool_id; + sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_RTDS; + sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_getinfo; + + if ( do_sysctl(xch, &sysctl) ) + return -1; + + *schedule = sysctl.u.scheduler_op.u.sched_rtds; + + return 0; +} diff --git a/tools/libs/light/libxl_sched.c b/tools/libs/light/libxl_sched.c index 2d6635dae7..ae4379cf09 100644 --- a/tools/libs/light/libxl_sched.c +++ b/tools/libs/light/libxl_sched.c @@ -397,6 +397,52 @@ int libxl_sched_credit2_params_set(libxl_ctx *ctx, uint32_t poolid, return rc; } +int libxl_sched_rtds_params_get(libxl_ctx *ctx, uint32_t poolid, + libxl_sched_rtds_params *scinfo) +{ + struct xen_sysctl_rtds_schedule sparam; + int r, rc; + GC_INIT(ctx); + + r = xc_sched_rtds_params_get(ctx->xch, poolid, &sparam); + if (r < 0) { + LOGE(ERROR, "getting RTDS scheduler parameters"); + rc = ERROR_FAIL; + goto out; + } + + scinfo->admission_control_enabled = sparam.admission_control_enabled; + + rc = 0; +out: + GC_FREE; + return rc; +} + +int libxl_sched_rtds_params_set(libxl_ctx *ctx, uint32_t poolid, + libxl_sched_rtds_params *scinfo) +{ + struct xen_sysctl_rtds_schedule sparam; + int r, rc; + GC_INIT(ctx); + + sparam.admission_control_enabled = scinfo->admission_control_enabled; + + r = xc_sched_rtds_params_set(ctx->xch, poolid, &sparam); + if (r < 0) { + LOGE(ERROR, "Setting RTDS scheduler parameters"); + rc = ERROR_FAIL; + goto out; + } + + scinfo->admission_control_enabled = sparam.admission_control_enabled; + + rc = 0; +out: + GC_FREE; + return rc; +} + static int sched_credit2_domain_get(libxl__gc *gc, uint32_t domid, libxl_domain_sched_params *scinfo) { diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index a7893460f0..d3121ea277 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -1286,6 +1286,11 @@ libxl_sched_credit2_params = Struct("sched_credit2_params", [ ("ratelimit_us", integer), ], dispose_fn=None) +libxl_sched_rtds_params = Struct("sched_rtds_params", [ + ("admission_control_enabled", bool), + ], dispose_fn=None) + + libxl_domain_remus_info = Struct("domain_remus_info",[ ("interval", integer), ("allow_unsafe", libxl_defbool), diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c index 502244f683..e48d5c5edc 100644 --- a/tools/xl/xl_cmdtable.c +++ b/tools/xl/xl_cmdtable.c @@ -295,13 +295,19 @@ const struct cmd_spec cmd_table[] = { { "sched-rtds", &main_sched_rtds, 0, 1, "Get/set rtds scheduler parameters", - "[-d [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]] [-e[=Extratime]]]", + "[-d [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]] [-e[=Extratime]]]\n" + " [-c -s [-a[=ADMISSION_CONTROL]]]", "-d DOMAIN, --domain=DOMAIN Domain to modify\n" "-v VCPUID/all, --vcpuid=VCPUID/all VCPU to modify or output;\n" " Using '-v all' to modify/output all vcpus\n" "-p PERIOD, --period=PERIOD Period (us)\n" "-b BUDGET, --budget=BUDGET Budget (us)\n" "-e Extratime, --extratime=Extratime Extratime (1=yes, 0=no)\n" + "-c CPUPOOL, --cpupool=CPUPOOL Restrict output to domains in CPUPOOL\n" + "-s, --schedparam List or set pool-wide scheduler parameters\n" + "-a ADMISSION_CONTROL, --admission=ADMISSION_CONTROL\n" + " Enable or disable admission control for the cpupool\n" + " (1=enabled, 0=disabled); requires -s\n" }, { "domid", &main_domid, 0, 0, diff --git a/tools/xl/xl_sched.c b/tools/xl/xl_sched.c index 73cd7040cd..4477f71e67 100644 --- a/tools/xl/xl_sched.c +++ b/tools/xl/xl_sched.c @@ -246,6 +246,28 @@ static int sched_credit2_pool_output(uint32_t poolid) return 0; } +static int sched_rtds_params_set(int poolid, + libxl_sched_rtds_params *scinfo) +{ + if (libxl_sched_rtds_params_set(ctx, poolid, scinfo)) { + fprintf(stderr, "libxl_sched_rtds_params_set failed.\n"); + return 1; + } + + return 0; +} + +static int sched_rtds_params_get(int poolid, + libxl_sched_rtds_params *scinfo) +{ + if (libxl_sched_rtds_params_get(ctx, poolid, scinfo)) { + fprintf(stderr, "libxl_sched_rtds_params_get failed.\n"); + return 1; + } + + return 0; +} + static int sched_rtds_domain_output( int domid) { @@ -339,10 +361,15 @@ static int sched_rtds_vcpu_output_all(int domid, static int sched_rtds_pool_output(uint32_t poolid) { - char *poolname; + libxl_sched_rtds_params scparam; + char *poolname = libxl_cpupoolid_to_name(ctx, poolid); - poolname = libxl_cpupoolid_to_name(ctx, poolid); - printf("Cpupool %s: sched=RTDS\n", poolname); + if (sched_rtds_params_get(poolid, &scparam)) + printf("Cpupool %s: [sched params unavailable]\n", poolname); + else + printf("Cpupool %s: sched=RTDS admission-control=%s\n", + poolname, + scparam.admission_control_enabled ? "enabled" : "disabled"); free(poolname); return 0; @@ -715,6 +742,8 @@ int main_sched_credit2(int argc, char **argv) * -d [domid] -v [vcpuid 1] [params] -v [vcpuid 2] [params] ... : * Set per-VCPU params for domain * -d [domid] -v all [params] : Set all per-VCPU params for domain + * -c [cpupool] -s : List pool-wide scheduling parameters for cpupool + * -c [cpupool] -s -a [0|1] : Set admission control for cpupool */ int main_sched_rtds(int argc, char **argv) { @@ -736,7 +765,10 @@ int main_sched_rtds(int argc, char **argv) bool opt_b = false; bool opt_e = false; bool opt_v = false; + bool opt_s = false; + bool opt_a = false; bool opt_all = false; /* output per-dom parameters */ + bool admission_control = false; int opt, i, rc, r; static struct option opts[] = { {"domain", 1, 0, 'd'}, @@ -745,10 +777,12 @@ int main_sched_rtds(int argc, char **argv) {"extratime", 1, 0, 'e'}, {"vcpuid",1, 0, 'v'}, {"cpupool", 1, 0, 'c'}, + {"schedparam", 0, 0, 's'}, + {"admission", 1, 0, 'a'}, COMMON_LONG_OPTS }; - SWITCH_FOREACH_OPT(opt, "d:p:b:e:v:c", opts, "sched-rtds", 0) { + SWITCH_FOREACH_OPT(opt, "d:p:b:e:v:c:a:s", opts, "sched-rtds", 0) { case 'd': dom = optarg; break; @@ -801,6 +835,19 @@ int main_sched_rtds(int argc, char **argv) case 'c': cpupool = optarg; break; + case 's': + opt_s = true; + break; + case 'a': + if (strcmp(optarg, "0") && strcmp(optarg, "1")) + { + fprintf(stderr, "Invalid admission_control value.\n"); + r = EXIT_FAILURE; + goto out; + } + admission_control = strtol(optarg, NULL, 10); + opt_a = true; + break; } if (cpupool && (dom || opt_p || opt_b || opt_e || opt_v || opt_all)) { @@ -809,6 +856,11 @@ int main_sched_rtds(int argc, char **argv) r = EXIT_FAILURE; goto out; } + if (opt_s && (dom || opt_p || opt_b || opt_e || opt_v || opt_all)) { + fprintf(stderr, "-s cannot be combined with domain/VCPU options.\n"); + r = EXIT_FAILURE; + goto out; + } if (!dom && (opt_p || opt_b || opt_e || opt_v)) { fprintf(stderr, "Missing parameters.\n"); r = EXIT_FAILURE; @@ -831,6 +883,46 @@ int main_sched_rtds(int argc, char **argv) r = EXIT_FAILURE; goto out; } + if (opt_a && !opt_s) { + fprintf(stderr, "-a/--admission requires -s/--schedparam.\n"); + r = EXIT_FAILURE; + goto out; + } + + if (opt_s) + { + libxl_sched_rtds_params scparam; + uint32_t poolid = 0; + + if (cpupool) { + if (libxl_cpupool_qualifier_to_cpupoolid(ctx, cpupool, + &poolid, NULL) || + !libxl_cpupoolid_is_valid(ctx, poolid)) { + fprintf(stderr, "Unknown cpupool \'%s\'\n", cpupool); + r = EXIT_FAILURE; + goto out; + } + } + + if (!opt_a) { /* output pool-wide scheduling parameters */ + if (sched_rtds_pool_output(poolid)) { + r = EXIT_FAILURE; + goto out; + } + } else { /* set pool-wide scheduling parameters */ + scparam = (libxl_sched_rtds_params){ + .admission_control_enabled = admission_control, + }; + + if (sched_rtds_params_set(poolid, &scparam)) { + r = EXIT_FAILURE; + goto out; + } + } + + r = EXIT_SUCCESS; + goto out; + } if ((!dom) && opt_all) { /* get all domain's per-vcpu rtds scheduler parameters */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 10:45:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 10:45:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425125.1649273 (Exim 4.92) (envelope-from ) id 1x7W61-0000dn-Q6; Fri, 18 Sep 2026 10:45:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425125.1649273; Fri, 18 Sep 2026 10:45:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7W61-0000dg-NP; Fri, 18 Sep 2026 10:45:33 +0000 Received: by outflank-mailman (input) for mailman id 1425125; Fri, 18 Sep 2026 10:45:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7W5z-0000da-VN for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 10:45:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7W5z-00E9Zo-BV for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 12:45:31 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad1648-bab6-0a2a0a5309dd-0a2a450192ca-14 for ; Fri, 18 Sep 2026 12:45:31 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad164b-5984-0a2a45010019-4a7de14cfaac-3 for ; Fri, 18 Sep 2026 12:45:31 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485933b24c3so320775f8f.0 for ; Fri, 18 Sep 2026 03:45:31 -0700 (PDT) Received: from [172.18.88.57] (195-200-21-10.mclarenap.oninferno.net. [195.200.21.10]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-487200829e1sm3467986f8f.34.2026.09.18.03.45.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 03:45:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789728330; x=1790333130; darn=lists.xenproject.org; h=content-type: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:content-type; bh=pVFaPzgQabGuwBinOS6glveWG3MNC30bB6PKbBItSZ4=; b=Ubm8DQlwVk6hpZE2jqzbOm4JKR8kS0/C08Hd4cDHEm/QnthgwtgVKSuSKLOkKFemyS CxmKBqaTPHkvc/r8CufWPvKFLp1j84MFFetXFHAj3uVZuX/DFuvqXuU4skRApdZMwF/R NzWAjiWyNTgqt4t1QcyNsj8caoQrHrP8uN6NEQNplG6YUPB7Mre3YaWgoRVAbmYj28jr GvcPw/lejN41scZCCskMiUlALvDRLvnFdrha+2Dsx7a0bMn6ZKAtgx4+tuUAFrm4+6Av 8rBQ8L34hyRk42B6AEqTYeMBkFD5R5aIcpiaqiWNoD6vNxpbLWf++6X92mYuTUn12b+2 eTpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789728330; x=1790333130; h=content-type: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 :content-type; bh=pVFaPzgQabGuwBinOS6glveWG3MNC30bB6PKbBItSZ4=; b=LnC4xMV2YO/7ScrOYGsF9I2rMSsN0rpGemUwlstPmd2EXi8/T4sVV4TFlPNt3oQJgm k9+sooSlPpRJtVSWVk8D19h5HlxBCt9v90BfPACFG6Xn7A4e1Jx3+iSkP7aIqdU/SF+V 8T3UO4LLiPhc3kmb0+3KrdwsK3CN9kdyYdn2lUP85m8ALcbW9l+KRgi0cEaobNhPvcQL 0X07DDWO74TRQ29A9iec2/8j5I/2/kWAyJHirSMK5xXPE7Ic85FEsG5APIGLHDf6zmxg M3c4dcY/4g71mGgKhpqCKQ7MJOrQaggZ5cD/TmWw2x2YXrmo/6GcqKJZpOcfM/phuXqA FNiQ== X-Forwarded-Encrypted: i=1; AKwUvBwTs1+5258/1HnMlaDlmlLqHJqg6+Rr9uyTLt3hBbBVZK9W5KRqnOch+bNMzoIO6AFRrzMDkcW4DzY=@lists.xenproject.org X-Gm-Message-State: AFuF++k1dCaEd4kNMuonIqlgWZRm4fimSo7HQuamLxA8Ls8pRuDJTWkT g5X2XmKhQoUdKHMp0exAIsYV6UJI34WmZl6w7yW/Vk/2mCcKTV8DaFKfSKkybOrPW3o= X-Gm-Gg: AYBFou1NZfEKR3nv0ZYt4wF+5OsC8AGLev/YvO3QG8e5wiV5/wZxk44MoPgXSEHsWrw F3UEKAsZ4gZwjdhIFuHaQuC6Rqg+oYcZJOf/fYQR5FcxQO840iPHHfo/VOPAOWQbNbQSWNOkPpY oJR6Bv56aUT1sYJvFgK8AgmRuuXknpJsRV7cE6ns7359VHtZ7Loa1kiJHSD7ZA/cbL/ILKRWv0u Chjqr57fimt7LzSFVTmMz5l616UvFPuvohQkVzN25wyxJzPfOwP8bj+/0fAb4oDDq+QDNJ0Uu17 +UlvPObw+76/DlFBbmeDjGwcRiBY6pU84CbZuaKC3uGXwrOuYvjEHOFi4juQA4JMNYbtSaCLtQt gAAB8AJ1BFca3cfaNalzA6VYFyUf240ZNzco5siQuFZw3o+JMtyrfgOw9XySpYv75cAKdTIAAsm bn96ULAIqq8CGw2qd+RU0IW4j+BlxIayjz9HxqDprqhq60/CSO1oQg1tfo316+i0CYX9jF3m9sa R5cQx0UYmXglI+wR8NK1WQAC0k0Sf1IHL5+ X-Received: by 2002:adf:e194:0:b0:484:3326:983b with SMTP id ffacd0b85a97d-4871e26857cmr2276582f8f.26.1789728330552; Fri, 18 Sep 2026 03:45:30 -0700 (PDT) Message-ID: Date: Fri, 18 Sep 2026 12:45:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2.1 5/5] tools: expose admission control toggle via xl sched-rtds To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, anthony.perard@vates.tech References: <20260918080935.35498-6-frn1furkan10@gmail.com> <20260918104106.53530-1-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260918104106.53530-1-frn1furkan10@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------qolC5t00v0sn0YXzX9NkP4jm" X-purgate-ID: tlsNG-d62444/1789728331-1D272757-BD6691A1/35/110847 X-purgate-type: clean X-purgate-size: 8225 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------qolC5t00v0sn0YXzX9NkP4jm Content-Type: multipart/mixed; boundary="------------ocV9MkhPfQk7QPOqiVeAgqHc"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Furkan Caliskan , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, anthony.perard@vates.tech Message-ID: Subject: Re: [PATCH v2.1 5/5] tools: expose admission control toggle via xl sched-rtds References: <20260918080935.35498-6-frn1furkan10@gmail.com> <20260918104106.53530-1-frn1furkan10@gmail.com> In-Reply-To: <20260918104106.53530-1-frn1furkan10@gmail.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------ocV9MkhPfQk7QPOqiVeAgqHc Content-Type: multipart/mixed; boundary="------------2hIBDS0bWyumzw0zq0795Mr7" --------------2hIBDS0bWyumzw0zq0795Mr7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTguMDkuMjYgMTI6NDEsIEZ1cmthbiBDYWxpc2thbiB3cm90ZToNCj4gV2lyZSB0aGUg cGVyLWNwdXBvb2wgYWRtaXNzaW9uLWNvbnRyb2wgc3dpdGNoIHRocm91Z2ggbGlieGwNCj4g dG8geGwgc2NoZWQtcnRkcywgYW5kIGRvY3VtZW50IGl0Lg0KPiANCj4gQWRkIC1zLy0tc2No ZWRwYXJhbSB0byBsaXN0IG9yIHNldCBwb29sLXdpZGUgUlREUyBzY2hlZHVsZXINCj4gcGFy YW1ldGVycywgYW5kIC1hLy0tYWRtaXNzaW9uIHRvIGVuYWJsZSBvciBkaXNhYmxlIGFkbWlz c2lvbg0KPiBjb250cm9sIGZvciBhIGNwdXBvb2wgKCItYyBwb29sIC1zIC1hIDAvMSIpLg0K PiANCj4gU2lnbmVkLW9mZi1ieTogRnVya2FuIENhbGlza2FuIDxmcm4xZnVya2FuMTBAZ21h aWwuY29tPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29t Pg0KDQoNCkp1ZXJnZW4NCg== --------------2hIBDS0bWyumzw0zq0795Mr7 Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------2hIBDS0bWyumzw0zq0795Mr7-- --------------ocV9MkhPfQk7QPOqiVeAgqHc-- --------------qolC5t00v0sn0YXzX9NkP4jm Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqtFkgFAwAAAAAACgkQsN6d1ii/Ey+l xgf/WanTtS5BLUxKANXe7G7zE87ZMTdRi+o+rBt5/9SB2L99Ei7W3QjNFD9NLfly8w56mhH0Oj/g 8NEGtHRMnD0efqQEzkoWM+smkWKPAk37fZpi2fSrsURjEpQ2ZTziZB826gML533EGrx0tpiHqtAq H/uxEeiAkPiadESwBbphRvBcqnozdJQ9+bfGXtkIdiBM0wSkIl5CJAHu7w3/n3Nt3m//UipiDxJ8 mTSzACcDTlff8PtdmPECHsqzWHByxsXJAH//o3MCUEqMxwI6qUY9VqX/yeM0ancBtEJLvoZTc0V5 RVc69QgirGCa0hT09LTn8fipQcEx3QMdLPsmS0LNOQ== =QrEt -----END PGP SIGNATURE----- --------------qolC5t00v0sn0YXzX9NkP4jm-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 11:40:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 11:40:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425181.1649283 (Exim 4.92) (envelope-from ) id 1x7Wws-0000Eb-NU; Fri, 18 Sep 2026 11:40:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425181.1649283; Fri, 18 Sep 2026 11:40:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Wws-0000EU-Kf; Fri, 18 Sep 2026 11:40:10 +0000 Received: by outflank-mailman (input) for mailman id 1425181; Fri, 18 Sep 2026 11:40:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Wwr-0000EA-LI for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:40:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Wwr-00CBMm-1x for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 13:40:09 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad2314-2eae-0a2a0a5409dd-0a2a4503d444-24 for ; Fri, 18 Sep 2026 13:40:08 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad2317-fae8-0a2a45030019-aa0a857c7833-3 for ; Fri, 18 Sep 2026 13:40:08 +0200 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-664-RljFhzjcNa6PdeDGbFls5A-1; Fri, 18 Sep 2026 07:40:06 -0400 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-530d028f779so7419361cf.2 for ; Fri, 18 Sep 2026 04:40:05 -0700 (PDT) Received: from localhost (bras-vprn-aurron9134w-lp130-03-174-91-117-74.dsl.bell.ca. [174.91.117.74]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-532a19a4fa5sm11367371cf.13.2026.09.18.04.40.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 04:40:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:content-type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789731607; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NkBLN6iytHxigslhO22YLF7Mj8QQdsoSIRTOupiudCQ=; b=BIGwUnQS4CreXwhsunC/+t8/4d28AItgbLMQ6KlnyYKtxgHr5METY5Pv7OX1cVshcan/3p lwMBOUweCSu+/jUcC1UhM3IRNbeIOsmPRlgHSIib45sp0EEHjp2dHVZXl8lxBBdiuI6+rA shP2o6IQWdamJhmgzD/Pv/K5xWhirfI= X-MC-Unique: RljFhzjcNa6PdeDGbFls5A-1 X-Mimecast-MFC-AGG-ID: RljFhzjcNa6PdeDGbFls5A_1789731605 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789731605; x=1790336405; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=NkBLN6iytHxigslhO22YLF7Mj8QQdsoSIRTOupiudCQ=; b=UiTRPxJbgvORnmq8bZ+WJStkwKRsVe6/YaU/FdqaXrL8h8ERIZCRYjrDjspacT1Cs8 4bC9saVz3Y49eXHz4M6eZhRw8QiCzOQM3up2zBK/u4OGTC9DH7gZ3XlGO1++nuyfvcza I9bOs0c8WAYJOhLmBm8eUARlBozNWFAOTZb57I3bm0YYAANKQYDiDuPd/qniWukJA5DM iYuLNveu4bMyBIenoB7qa0PXSQ9R9cjzH070raeDMSrO1mz4iYQvXSi+HQsXZHJZNr8S zQrTLYhm4AZUKsnQUBtUVwqK+4pcTx+b/eQNlmK6az+K0Sffll830d5xODN3gyeV96+6 dP8A== X-Forwarded-Encrypted: i=1; AKwUvBx3Hnto0XTCZSb2SIPT3sQ4UwJreTCnZq1aFAMvTnCoxfqx8NbMcBIQzRYi5DU3/Sc5rW52Qq5cAgs=@lists.xenproject.org X-Gm-Message-State: AFuF++kg/JUwbzc0J8DX0/vT/ylz5JjjhWcEBvBrbGeppuBwHaLWKm7n 0szf/o/yyun0kbB2ocDAdA8SOM7yTY4tjKxwknEk33LVBLQ0duyOY/piJPHRH0PwDT5q3yxoqFF JjPdn8UAtmHYisqRcibOT5Z8Yh2OJGFwwsp+1BOG8eyxv8Y8KZsK9plAlMW1OBfMznSFs X-Gm-Gg: AYBFou3ufbauND5NNKOy+GuoZz64hDcxHRaId64MTyXOgbGcx19tx3B71j49lG2NWOq KL2Ccgh9vmh/tu1/GoOKHvPDp25eJln+SYpvV9qJMvMV4yLL80MhUcgUtF/njhSaeDxR52MeI5p bctkAzVb2RH0SZ/O957TQMGLWWenscdKdGG/fBsXTZAt7qHbPwgmNRt7DL3S62MyU9ANhNvYkdV prJp+WWVX+fofTTH16ch3PlDdm1+w58L+5A5aHJcn2Z8f1zT9nhg6TnY6O0eH4j7K4M/MerSEv4 pLis4HNHuzwTrhxH2P0fOEZJ237v20NpluaN3MLM3Aep0lAtElf8QhWoLRHKuSucHHo/RAAW+tN 86wJvvdbsDmuj900KJPijaxKpWci0QNTRs+kVX3UOr77h+GvySdJisylEuF8= X-Received: by 2002:ac8:5dd2:0:b0:531:214b:42b with SMTP id d75a77b69052e-5329e48fed1mr32543671cf.40.1789731605274; Fri, 18 Sep 2026 04:40:05 -0700 (PDT) X-Received: by 2002:ac8:5dd2:0:b0:531:214b:42b with SMTP id d75a77b69052e-5329e48fed1mr32543271cf.40.1789731604756; Fri, 18 Sep 2026 04:40:04 -0700 (PDT) From: Peter Xu To: qemu-devel@nongnu.org Cc: Peter Xu , Paolo Bonzini , Richard Henderson , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , xen-devel@lists.xenproject.org Subject: [PULL 04/11] xen-mapcache: Remove 32bit support Date: Fri, 18 Sep 2026 07:39:19 -0400 Message-ID: <20260918113926.831204-5-peterx@redhat.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918113926.831204-1-peterx@redhat.com> References: <20260918113926.831204-1-peterx@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: rpY_kR2O1po8q49keBN0pdJ7V3BaLDxszMYA40eNPtY_1789731605 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true X-purgate-ID: tlsNG-33051d/1789731608-6ECCB4E9-C9A000B8/0/0 X-purgate-type: clean X-purgate-size: 1444 QEMU has switched to 64bit-only hosts for all system emulations. Reviewed-by: Richard Henderson Link: https://lore.kernel.org/r/20260818172012.3052821-5-peterx@redhat.com Cc: Stefano Stabellini Cc: Anthony PERARD Cc: "Edgar E. Iglesias" Cc: xen-devel@lists.xenproject.org Signed-off-by: Peter Xu --- hw/xen/xen-mapcache.c | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c index 85cf0cf359..e30c07c2ee 100644 --- a/hw/xen/xen-mapcache.c +++ b/hw/xen/xen-mapcache.c @@ -26,11 +26,7 @@ #include #include -#if HOST_LONG_BITS == 32 -# define MCACHE_MAX_SIZE (1UL<<31) /* 2GB Cap */ -#else -# define MCACHE_MAX_SIZE (1UL<<35) /* 32GB Cap */ -#endif +#define MCACHE_MAX_SIZE (1UL << 35) /* 32GB Cap */ /* This is the size of the virtual address space reserve to QEMU that will not * be use by MapCache. @@ -151,11 +147,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque) exit(EXIT_FAILURE); } - if (HOST_LONG_BITS == 32) { - bucket_shift = 16; - } else { - bucket_shift = 20; - } + bucket_shift = 20; if (geteuid() == 0) { rlimit_as.rlim_cur = RLIM_INFINITY; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 11:53:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 11:53:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425198.1649292 (Exim 4.92) (envelope-from ) id 1x7X9Y-00020s-Tf; Fri, 18 Sep 2026 11:53:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425198.1649292; Fri, 18 Sep 2026 11:53:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7X9Y-00020l-Pt; Fri, 18 Sep 2026 11:53:16 +0000 Received: by outflank-mailman (input) for mailman id 1425198; Fri, 18 Sep 2026 11:53:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x7X9X-00020f-7t for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:53:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7X9W-004asM-K8 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 13:53:14 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad2623-e002-0a2a0a5209dd-0a2a450ad36a-18 for ; Fri, 18 Sep 2026 13:53:14 +0200 Received: from [209.85.221.51] (helo=mail-wr1-f51.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad262a-f2d2-0a2a450a0019-d155dd33a80a-3 for ; Fri, 18 Sep 2026 13:53:14 +0200 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-48431648f33so712284f8f.0 for ; Fri, 18 Sep 2026 04:53:14 -0700 (PDT) Received: from ?IPV6:2a02:778:142:8f01:2700:bad4:284c:5aa5? ([2a02:778:142:8f01:2700:bad4:284c:5aa5]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4872008fe3csm3571728f8f.37.2026.09.18.04.53.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 04:53:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789732394; x=1790337194; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=y0tWxbj9cGkYXEJPFzDR5FglFp8Hk9hDzsHv6lnfQ2E=; b=HI6wW3E+PXI6M3bDZslyjnv4oXdgfhGq6H2XZlnBkch/7uN27MUth+bHDi1ZerWp2R DmOx4y+5M1aHHNpCcrzR7vk/UJtOQh+v31M3TKn+0lC8pbPqDnOaEbyq7YAw6aao9MXG KjuqtbDFUFS+52vDbBFwsYZJttnnglrawk1p/AMi0h14sYenSeejSRngm4C132Fh3RJa gZp2ckVEVjrLFOXeNdgCpz4ttQO8LkvpVwPRafRzHECby3/7cYRqU1zQseV4rJkj6SqA GjA1bcxTZ+QAbriH0YCPlVyvefFQhxVy3AypZXBaYHIqALWGq8l24Xfo9mLZEDQE8QNy /YZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789732394; x=1790337194; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=y0tWxbj9cGkYXEJPFzDR5FglFp8Hk9hDzsHv6lnfQ2E=; b=iSk0Qfpvdu9XgQZ89SMOSXPLW3vwJDuZZ25Q1QbVzkJ58DERB/z84yPu0w1XkTFWrj k1vdxxVhTJHGcmxn4OFGKZijRh4YlBbqb7I3jEfITQ2RcKbrqsE1W8KVUHWr0rmF/jcq X5chBkY/7eqYgEzk/0bArIkH93QY9edr7ehr+0YlNUUmfAWNwjsEtskPnbcCdi0MyBVA a2Nj1g2k/nArP3XtK/tR+/k8uU67sD9mswHWpIxRCS6/Cl5Bgn1OoEL3X+3Urqpg5Gru d5Bb+5cEPyvR76z1U5HvYCC/1AOVxKiK7M7KffGZFlqp8x8AWcw4DMpMebRlFlIcSbba eW4A== X-Forwarded-Encrypted: i=1; AKwUvBx2jb+a6FwX70Dvhg4b/4A40lXx/BAaXl04lUdob0KEnhQbesOgROuiXntaVd57j/uZ3VuiUBWsprM=@lists.xenproject.org X-Gm-Message-State: AFuF++lRiGKY/oPrAdluxxS78qk1Xp4xsh9iW9emkOqLbE8wnh9XpmV1 /nJV4ybysga7j2lBXSMsZuETmYa69rEYvaM2MJRw57p64y3exi8S2Dyu X-Gm-Gg: AYBFou2IUtzL1RT+JR5x0BjVhK4O9oXh9JGLixZMeDdM/ThNbtCeljBsILjU93+D4bt ZJtJ2KTpxLiA6vgLED8KjvzW/IQpYmaOEE0QWpndch46Hl91IoT0flYj2IhveozKKtH28CtdSQm fbZtuN6N1eneB4C+acTsf+O0iBEBFJlpBqdnqCKyp+JgAZ8w5jwXIGCOiogaSc5qYLL478pM+nP /0X9DhGZPwoV6/UDwSRK91RIEg5CeVMHl3ji55e65S7o8u5E9v1JWaYAxmjw/41kpeJSwgzxyxL hSiEcUFXyS1TljyWE99r3VU2aBuYVmrdPH5hMIw15llePzWi0wdtUjG+Smbt6MJ/Uh8XaTZSdjY cnCBNpHIg4opPHVdPSM7lVI0dQcEqT6KiFtvuJiXB45jQIseLj6zjf+3CVRUdsjKl1zOhStFn8p hguHbL+Fckw6qnuyGQnGMz3LGGGGb7msKi3yxcrCbvGhSUEls3CDwmwrfiFNpTCMVP8mASdlE1J aSIJi9AwE+suaY6y2n/wOEqzv+xYf4YMdJTGrec4oVziaGR1SeRtQ== X-Received: by 2002:a05:6000:468c:b0:487:152:e57c with SMTP id ffacd0b85a97d-48713aff8dbmr7318615f8f.1.1789732393638; Fri, 18 Sep 2026 04:53:13 -0700 (PDT) Message-ID: <2e07e5e8-bd6c-4ec9-b656-6fa8c61bb456@gmail.com> Date: Fri, 18 Sep 2026 13:53:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> <45f6e417-ea0e-470c-bfae-e163a65b48d0@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <45f6e417-ea0e-470c-bfae-e163a65b48d0@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789732394-59DDFCFC-9B653AE7/10/73395122804 X-purgate-type: spam X-purgate-size: 3088 On 9/14/26 3:27 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> During migration of a virtual hart to a different guest interrupt file, >> straggler MSIs from the APLIC could arrive at the old interrupt file >> after the switch. >> >> genmsi is used despite not supporting guest interrupt files because the >> AIA spec guarantees that all MSIs previously sent from the APLIC to the >> same hart are visible at the hart's IMSIC before the extempore MSI from >> genmsi becomes visible. > > Hmm. As indicated, I'm learning RISC-V as I'm reviewing patches. This > paragraph, if left as is, would make sure I simply can't ack the patch. > I just don't understand what is being talked about. I can guess parts, > but for example I don't know what "genmsi" is. I will reword then commit message in the following way: ``` When a vCPU is moved to a different guest interrupt file, MSIs that the APLIC has already sent towards the old file may still be in flight. They must land before the old file's state is saved and the switch is done, otherwise they would be lost. To wait for them, use the APLIC's genmsi register. Writing it makes the APLIC itself send an MSI (an "extempore" MSI) with a given interrupt identity to a given hart. genmsi can only target the hart's supervisor- level interrupt file, not a guest one, but the AIA spec guarantees that all MSIs previously sent by the same APLIC to the same hart become visible at the hart's IMSIC before the extempore MSI does. So once the extempore MSI has been delivered, no older MSI from this APLIC to the hart can still be in flight, whichever interrupt file it targets. The last interrupt identity (nr_ids) is reserved for this purpose. ``` > >> @@ -205,6 +207,30 @@ void aplic_hw_write_reg(unsigned int offset, uint32_t value) >> spin_unlock_irqrestore(&aplic.lock, flags); >> } >> >> +/* >> + * As needed, synchronize with all IOMMUs and APLICs to ensure that no >> + * straggler MSIs will arrive at the old interrupt file after this step. >> + */ >> +void aplic_genmsi_barrier(void) >> +{ >> + const struct imsic_config *imsic = imsic_get_config(); >> + unsigned int cpu = smp_processor_id(); >> + unsigned long flags; >> + uint32_t val; >> + >> + val = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >> + (imsic->sync_id & APLIC_TARGET_EIID); > > Along the lines of a question on an earlier patch: What if this ANDing > actually chops off bits? I will do then the same as I did in aplic_set_irq_affinity() (i mentioned that in the one of the replies connected to this function in this patch series): /* * sync_id is nr_ids, which imsic_parse_node() limits to IMSIC_MAX_ID, * so it always fits into the EIID field. */ BUILD_BUG_ON(IMSIC_MAX_ID > MASK_EXTR(~0U, APLIC_TARGET_EIID)); ASSERT(imsic->sync_id <= IMSIC_MAX_ID); val = MASK_INSR(aplic_hart_index(cpu), APLIC_TARGET_HART_IDX) | imsic->sync_id; Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 18 11:58:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 11:58:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425210.1649304 (Exim 4.92) (envelope-from ) id 1x7XEY-0002gJ-F9; Fri, 18 Sep 2026 11:58:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425210.1649304; Fri, 18 Sep 2026 11:58:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7XEY-0002gC-CV; Fri, 18 Sep 2026 11:58:26 +0000 Received: by outflank-mailman (input) for mailman id 1425210; Fri, 18 Sep 2026 11:58:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7XEX-0002g6-K4 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:58:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7XEW-00BBGi-WF for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 13:58:25 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad275f-8faa-0a2a0a5109dd-0a2a4503dc2c-10 for ; Fri, 18 Sep 2026 13:58:24 +0200 Received: from [103.168.172.153] (helo=fhigh-a2-smtp.messagingengine.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad275f-fae8-0a2a45030019-67a8ac99832f-3 for ; Fri, 18 Sep 2026 13:58:24 +0200 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id 6D5F8140009A; Fri, 18 Sep 2026 07:58:23 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Fri, 18 Sep 2026 07:58:23 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Sep 2026 07:58:22 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:Message-ID:MIME-Version:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:Message-ID:MIME-Version:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm1; t=1789732703; x=1789819103; bh=O3 uG9dqlPfb/Zs/qiRaK9/x7Wn0S0Gv8fLS9Aik8M68=; b=u0KMFC5C64CX7QoFd9 aZna7k3j5Agxnaq3je1WW4Z9l8eQVFRTJufxU4M2Hog2kwNxyQsTH1YD3k9s5Jbk 3d9r3jM8ztK+MaGJm2RFhxh0dTMeXjnJGGOrvtzGxn4HMQBzw1GGwNpxjaXNHevb gBibsBADL9yKq8c0x8apSENBE7yuE9MZ8jqRuxMJN2alj1UkBl//W7c4+vLO8FGi dngMT48hTGAPbIpJ8y5ZSzcHeDqPCzcnfvBIKZ3YYnbW4CB+6iVTJyK++ILsBuZV Bq2bUPcr84jD82LghkOI6dKX1NmEGyFBTc4l9KbSzqnBRKb8J/W5Ue5HqJWelw+U LP/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1789732703; x= 1789819103; bh=O3uG9dqlPfb/Zs/qiRaK9/x7Wn0S0Gv8fLS9Aik8M68=; b=m J6RypAQodPKuLqC3/EtPJMNDRwF4/fV4LdGT7cJtt2V7BvRMmwSPxFxavVFzqrHz Ierh+BIAcAmdWoWeYu+PoqGvnC8Dm7JboWR9LK+xZeT2QkS2JVfJ1ltyTGeLAHnw Az6qXut88n3bnjcfdWZa2iw8Ijve6FStBEEWFyf49iDkXsszljzKJd3JgWP6/OZ+ stX+HQr/CIX25Q9ewHuaz7rHFzD191vr9upr4skoH1svbV8KZCXRn8TfmYwRGJRI 4E8CxQcmq4nrRUBbLCpaxbYjlh+/B7zWf02nr7zSBWOZYcmYLWgxOMoiN/wWKy3e 8jSnQLqLErBrjCI9RI6iA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE/2Gn5ijyLCaoq8oPOQ4LbUZIcnZMUOtxDnZTdxIuzLNE/cOOhMZe6fx+T8iiIAX IgmmoGimADrV5G1RRbZsjkfi67c3P7VVPoaGS9LR8JQr9fDW5DVpkcA+jIhc0WPeg3AAJo aLNLNzLVkJ98LAejSQ+yinThiyREwGNv18pb/gBu4CSkAbi75sbh9pqTZXlpbgGJDj95L6 n6Ca6Bdt5cjNB7AFMJSmpFsrJr4pcF9rEjFSI37yw4golBrVkt4vN/0HXG9JSu/NlEaqn+ tyMXKc4SvP7JzYozfie9ehzqDoJX7h9xnG6PQesyDLSjMmTu6DpAL0W23pblgHKQ0jb0AM iqgWEf4E1dv406yaVnNkpJVcnbk/HpPwR+RJFu0GVnKcVJoSx9Ai4vc1qI+plSahr8d7hG ZWJDO6Kr6eRCz/p7s8MAMhlLBQAXPVpdNBYfIV1dV7tvc4gFKL5MIed+Fas8NRMaMH/CwH a8DOsf17t/WxKYe38NQ/IkGi57ueC6nzY6RsLOyd1AYx3xd6y9szv+eU2tCfnlZ2NO6Ap7 qUY8ZZPcoRBe/iInPFVRRlCs8Wqr47p2y5keudK+OSTPO2EgtkKKtku43yLoYqagWX63Zw a/6V8H9ZRmAoayZQYCfleAOo2pge1IB3bheo3vZRCsN4OigRpUpnmStt9q+A X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Fri, 18 Sep 2026 13:58:20 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Denis Mukhin Cc: xen-devel Subject: Zen5 runner access Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dMebaTGnIpaxfV48" Content-Disposition: inline X-purgate-ID: tlsNG-33051d/1789732704-77AF14E9-9F12E21C/0/0 X-purgate-type: clean X-purgate-size: 1879 --dMebaTGnIpaxfV48 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Sep 2026 13:58:20 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: Denis Mukhin Cc: xen-devel Subject: Zen5 runner access Hi, After some debugging, the AMD Zen5 gitlab runner seems to be working now. You can add it to your repo by going to https://gitlab.com/xen-project/people/dmukhin/xen/-/settings/ci_cd Runners -> Other available project runners and add hal9021 to your repo. This relies on temporary access I granted you, so you need to click it in the next two weeks. Then grab top commit from https://gitlab.com/xen-project/people/marmarek/xen/-/commits/automation-hw21 that actually defines some jobs on it - edit it to your liking to run tests you want there. And then, you can also select which jobs to run while pushing stuff to gitlab, for example like this: git push gitlab -o ci.variable=3DSELECTED_JOBS_ONLY=3D"/zen5-.*|alpine-3.24= -x86_64-gcc-debug/" --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --dMebaTGnIpaxfV48 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqtJ1wACgkQ24/THMrX 1yxHZgf+I+CoXmc1svMVnblyDYhgx5HHCdWSUTM0vijrQIUFRarYidlyft5TBGBw DYA07Tfxi29j8LjsRkAmzm/8BHuH+MM4YCUzGOg9ar2z8lk44QBdWz62CMzsvzqH KueZYVDn1HmnKpuEKNnVYBWy0s0MOh66VphOLM1ailuuPJTO123sShOSGcznQB2j X9msvdLLRjs7AbtzeG6fOCeFsGX79ljT5l4/mDD65rM+MIxM9yel9LRNGRLbuhFS 0dTItQPp3i1oHD41oLNsfUxnr0/05hIu5mA7YFnL8eAkWDVBJrlqtUJnY+zVrSmV EAzlzWuhHvZ5a+nBhqVZDE4EFTywyw== =/1bt -----END PGP SIGNATURE----- --dMebaTGnIpaxfV48-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 12:38:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 12:38:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425251.1649314 (Exim 4.92) (envelope-from ) id 1x7Xr0-0008SD-In; Fri, 18 Sep 2026 12:38:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425251.1649314; Fri, 18 Sep 2026 12:38:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Xr0-0008S6-Ev; Fri, 18 Sep 2026 12:38:10 +0000 Received: by outflank-mailman (input) for mailman id 1425251; Fri, 18 Sep 2026 12:38:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x7Xqy-0008S0-Qw for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 12:38:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Xqy-005ael-7X for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:38:08 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad30a7-2eae-0a2a0a5409dd-0a2a4502a246-20 for ; Fri, 18 Sep 2026 14:38:08 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad30af-6ca4-0a2a45020019-4a7de18cab94-3 for ; Fri, 18 Sep 2026 14:38:08 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49e69b9e16aso7528735e9.1 for ; Fri, 18 Sep 2026 05:38:08 -0700 (PDT) Received: from [172.18.138.134] ([185.104.138.149]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fc7cfd1dasm53323355e9.9.2026.09.18.05.38.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 05:38:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789735087; x=1790339887; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=TMbZVRoEVv18/M/zoCZMGwivp/WJPkEWRsrNCnLDBuY=; b=TBm63X+HB1E6hZNgVdd04kLlIyrgRegk+nWeV3k/w3Ezh8cO2KZSuuZtMBKiz+Dh6i ghK6v6GWSVU/py+ZpSekJhaecQW95RYGKee7PVcoZa0ncktweZS2P3uwqWSqitdq5w50 qkfxj92LFrY3dGlJ59Own+psDQ1ZEiGeDiXjAgiXur/Fl2guZGs5lz0FaAdlIGe6vFZA NQ+Rch+Zdbs6baPYpOr2ea4l14SyW/FsnyvPMADu8asg374WAHQNueU1ghLWL3LLCfnZ luYZx0wAvvwAdEhJkh5grbeQOtVUBxw9m6o93OQ6Sm9PCx8cgtKZ8tUzDRVr5IQClDWi 6bgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789735087; x=1790339887; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=TMbZVRoEVv18/M/zoCZMGwivp/WJPkEWRsrNCnLDBuY=; b=P4O3gdbO7Iic+3dNg4ggOsXmjD3wIvwh4g6fisNdTlh8bEbCxm9MoRqqBuoOHxGy3L CVu4easkd5otq8PT2BwrH5UOiR1mE73xRx10lWNivCoYSeoITj1P5OrwQc6YLubaTk0s 0caFYQa9rVOD5ux5eW8fRbOGBOY2Y+x6zsL01Y7rlYjhRApGaV2Hk66ZFdYQGKP/0eMX Fil88prnQ6NX8auoRPSHkpoY9nvTe19GWGEZNZmg5oZflo39BDVTK1ThPJWoPjuAMaEg lVE9WyjrhL4F/1C3fDdhMNxBAP2YoneomiM1U11hFC5pdAcBMBPGI1ybw1NfRE7XwB/2 RddQ== X-Forwarded-Encrypted: i=1; AKwUvBzNDSoQK5IVYu2lt/3MyggN1O6Da0Qlz6xPr5NOYNS+G0oSi7c1eOqWd3EehwJDk88XY3LdPR/P7js=@lists.xenproject.org X-Gm-Message-State: AFuF++kXcPzWuAUI3v2hGmAmehXgq+UTDoMgTdpyJCRHUXkdx+2mfNUw vgLo107RwuT+g73QzAl+FCiL9/6Ubd92ypgW9mRll8jbm9Ll8tlPNzjl1QFlelNB/A== X-Gm-Gg: AYBFou2wvoYjFD4L8oAptZRMBj4MpvDya9jvlL+qDYQjr2tPgRgI6i482RgEO/sPm1m PkmMxPEeTuBsUiZunuCesQLnhSsgYv5WKl7eb5ThL/ef0sQMD+4WCg+sAqZs1z8LoypH0pZ2973 iTOWLaKw4rViAjO89uTcoivNZ9lRFGe79HdqnA1d3Iu9dwF/1ybeFABvLg6P/J/qR/OXYhpbGLx 7YvOw5qaDwouESo6Xka8g5bzVsIzK/hMKK0Vr2Zy7j4vF6rNvDAe9X4EYg8wk6cVkm0+OGCHUBB H+G9YFuQLmbFzFsS8Szj4Rx0ubDKlKJ4Z1vWxpAZngs+dVB1ILwqcTK8XdwyEx5IiGJMKeP3Uto Cq2cKIUQSf2XaGbJkYuPJwO9EllUj5udrvnDmh8MorwcgCa/9ZjFR8PMhFSZXH/ddKjbx5GGDCc qDHxCYJRn4u1AwZafymjIN7y5Ugvs8dDz2VGs+NQJKewTqbfDLfdIMtnNLl7/ByPNvN+CiAZhv2 y+G6WBO9PYB0crL+pPgsg== X-Received: by 2002:a05:600c:154b:b0:49c:fa21:1c89 with SMTP id 5b1f17b1804b1-49fc5748e61mr31680575e9.30.1789735087642; Fri, 18 Sep 2026 05:38:07 -0700 (PDT) Message-ID: <7124bd3f-1479-4685-a090-e05251eff53f@suse.com> Date: Fri, 18 Sep 2026 14:38:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 35/39] xen/riscv: add basic VGEIN management for AIA guests To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789735088-30BC02AC-A92B8B85/10/73395122804 X-purgate-type: spam X-purgate-size: 1086 On 27.08.2026 17:21, Oleksii Kurochko wrote: > It was decided to add support for IMSIC from the start instead of having APLIC > operate in direct delivery mode, as it requires a trap-and-emulation approach, > which is not optimal from a performance standpoint. > > AIA provides a hardware-accelerated mechanism for delivering external > interrupts to domains via "guest interrupt files" located in IMSIC. > A single physical hart can implement multiple such files (up to GEILEN), > allowing several virtual harts to receive interrupts directly from hardware. > > Introduce per-CPU tracking of guest interrupt file identifiers (VGEIN) > for systems implementing AIA specification. Each CPU maintains > a bitmap describing which guest interrupt files are currently in use. > > Implement helpers to initialize the bitmap based on the number of available > guest interrupt files (GEILEN), assign a VGEIN to a vCPU, and release it > when no longer needed. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Fri Sep 18 12:52:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 12:52:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425277.1649324 (Exim 4.92) (envelope-from ) id 1x7Y4f-0002nk-MJ; Fri, 18 Sep 2026 12:52:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425277.1649324; Fri, 18 Sep 2026 12:52:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Y4f-0002nd-HX; Fri, 18 Sep 2026 12:52:17 +0000 Received: by outflank-mailman (input) for mailman id 1425277; Fri, 18 Sep 2026 12:52:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Y4d-0002nX-Em for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 12:52:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Y4c-004kqc-RB for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:52:14 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad33fe-8faa-0a2a0a5109dd-0a2a4505ecf6-4 for ; Fri, 18 Sep 2026 14:52:14 +0200 Received: from [52.101.193.21] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad33fd-4cb1-0a2a45050019-3465c1154d13-3 for ; Fri, 18 Sep 2026 14:52:14 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by BY5PR03MB5250.namprd03.prod.outlook.com (2603:10b6:a03:220::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Fri, 18 Sep 2026 12:52:11 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.011; Fri, 18 Sep 2026 12:52:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Y6qs26shRJFp6KryPukZbZG/6k193NLLT48LfZTmJz2i15Da5zUwglqJirgxNOS5GD6AMpr0sWsumUndxBK+7u3Df1rOyE3vbOgOoEnwOiHIrhrobgdqG8tyru3lillOCUTuVjfkP8VZ5dlMOI9NBI8zbo3J8r4oEubNazwUnISlw5sjQUdivIx4LagsmJ8eIn+3Crl5bD3LbmqPb1CgNPv8VVOuU3AKNwKl7jMhQDGNjTT1Eq3CPlkUHmVR6z97FWkTYMPo6DeJNEPL+vwnGe/B8cWaFqkYkeaXiFqbEcjR6v9OT3UMc0eKX6J+D4oRMwfQ06JxWJTIEHa2eNl8cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8WDCeOiqix8ITahgpJOXT6M0qAhwYtBhqLH5O0uJYcw=; b=QT9y+g2DoB5kF7zp0yiEY8DgGNk29ZK7w+cs8TPcEfUuz0oCGgDt8mLiUMGnUOSa7D4GOQdOGfaioP8JK4bBQ1GubsSYVbM6OFyWCnAJz8MY39A3dDmZKbqScUMAX/aEQ3dMdBN1kLj3BkjheKFGdOdIrXu2iblIRvDxAEjDG6PwBPsbqojlL8KOE3dNf6XI4OcrAUI79HYRUyuBX1gWaLNMnNK8mV/N0cCN7dHJgntMmRtx+AL6JTrZIQ5YpeYSygz2J0T72KY6A92HZfnXKnoIhsInAwYdtwKNdubbZQRYRJnKKZ+QLKDsELKf5vGq17yZuZjijtUEl1ni2URYwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8WDCeOiqix8ITahgpJOXT6M0qAhwYtBhqLH5O0uJYcw=; b=RDMuDjGksZ7DjR3rVmqKTJn737rvP55sNc9M4vOOfkQ19r27gmQMtvHCToH1jznz6pSR3nHOerX7GQYcmaK2Aueu7sPMPlIrYYsIHJjZbZRTNxGvfQvuAxgGd8Q3g8M1zU5hZefAm/rEuCOVg3EuFWNjIyGP0T0weP2eQ5k++1Y= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH] nestedsvm: Don't set VMCB(1-2)'s NP_ENABLE and N_CR3 during VMEXIT to L1 Date: Fri, 18 Sep 2026 13:52:05 +0100 Message-ID: <20260918125205.374168-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.55.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0507.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:272::17) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|BY5PR03MB5250:EE_ X-MS-Office365-Filtering-Correlation-Id: 720baa5f-9696-4d29-2c8f-08df1583a75c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|366016|10067099003|56012099006|11063799006|18002099003; X-Microsoft-Antispam-Message-Info: /vBGiVJ8bwEfk7QkHjzENd4o5cnqmboiU+UDfS/Q7eTB+cdTLmmr8AYg/Iz0ejJ6zHhu/UQh7YLvCazdZxnO3y5oAYlDCv075intNmosjOxCQ+9iTs+F2CGoXG46n78zXn3C6v6tuD7Tfk9CoLbrI1q5Ga2KenxMu3YgHl8xlPJFDTOF5hmdw30nJbdfpW+upD59vr+4W9rsrgDd7CpjGvinWyWuQfISB5ISrKuOB6NaRCOIG8fx9UEeStLKPG6+h3FqpiupwrPERsCf33A4doWGkMU6/LdXADQF9W0bOX+GcCpfV+nkdSY9egGLcUv5vCK6Oi/yGuzXJGHVqnzY30dqDZQMW6oJGsKZHTNupWaCvlVDl5ahr7zrN3QC5C8doiQdu9jnefqX6Dfi0cU1F9gWXnDU43+mS65Rs9tSB82MLv/dNsZZdDlhfAO4S9FcxY1kBacNKOk6XXINZ03HC1l+Hl3kI0ysm5cL4mxXlt8G9DofSs5ldPwYs3i9om1UbRQmhYsUUAByov4wlOiWThrywABtV99FU67O9XCx4A1UVCKEn2JajYUHX8uspYQF3Cm9VOAvqOU5OdJn7lgeEj6Z/xCuz5Ip7/tUqtP23j+esF0lCwYi44liqrP3VXIgcwDp8vdNCKWAYgOLhTzemdUeqiySCsaRzV+mrVNMat8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(366016)(10067099003)(56012099006)(11063799006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?1iJXpChjhtHVAJ2lo2rPFk3KaXDAeP9yHfeWUrbMcMlbkWEzwQsqY7d7lNPx?= =?us-ascii?Q?JlJn2XmCWxrzapgv1op4vnjduk0O01MxXkC48Zt8Kg5RXXuQnL2/FZD5KfT/?= =?us-ascii?Q?MirvnRozA0PCt2/8j3D9kPLxQobsx8mZXZERp/PryUG5oI1IUWJynxDWLUg6?= =?us-ascii?Q?Xc9qrXfWTs6+X3r4abiGCgcmk0osRBZXbM+NfzVAC1sKN+qgHjoQdIsBTPIV?= =?us-ascii?Q?UgacIU8cgnCBIKEw4FOJL+zBTiUgEmi/nIOFDtQ+qMF1jr73Td17MaHdzRvQ?= =?us-ascii?Q?occb2dO5W0cNtD68muQyuu6uNGnFvFS0rR3lwH7Gkmz5r87KFK9BYsmpTm66?= =?us-ascii?Q?EpJQ+cNHJeqieDE39YzqkD/mMOO2ExvTcetvv+kQGdD16Ln6JW3aPt1/iked?= =?us-ascii?Q?sQdoHIujkO533cttkJL4sWDLmeoiXKE+eZvLsYBPvOKl8R6JS6b2iGtD3Ofw?= =?us-ascii?Q?sDPiW0FZT8fXTtCyCekofzihKz9k8RGgKhoUZB33d5FpiWnzBDlbioh3xXb7?= =?us-ascii?Q?6iBSE7qATKKATX4PaKwqH0K+TYJNPZTtv0OR8nJu5e+wcKPiN9+5xmTMAZ8w?= =?us-ascii?Q?zHrXxHtThwAiapKFMyCDWb4wxsPBV/uCVtmcypW1kmlTAKhnLcoSNo+XCG3N?= =?us-ascii?Q?WKlUnPAFFRtpapGvFbNT19ADLr5IVc33fa3jh+OkVDN2HbZrX0VK2G9Mr6fN?= =?us-ascii?Q?o6U8VxiXhfbAqs5P3Fgh9IxZjExQS8iE40PkSpFf+qiRXMBsBhmlLa7eqAs1?= =?us-ascii?Q?a6a635Gy91jHqwjwPYi7jNeSySt9mC7ZoRlqdQRZv8ZOVfh2WzE64wSWr4Bf?= =?us-ascii?Q?iBTiwSWHSPhVVcMSqV8fNtzND1z8Bm6AY+QAeCEPaWewp6ao67YHwq/YWxd8?= =?us-ascii?Q?FKjwUUd9AR5k/lUAZkRa0sOLbhbzYYnlGSBBP7XPKJR5QmI0gR2iNwQ/UE1J?= =?us-ascii?Q?veUyoi6eMt7BvgD+Q+a5NFqH8+I/VlZKgbhBwk9Mr+45IhBstgSm6p9f7gTh?= =?us-ascii?Q?j/oqHefLnbZinQvpJsAvbs+mPkO5F5HnzRbMufl664ypayIRRUGSRH+5Uft9?= =?us-ascii?Q?Ob4Qkw9VAUl5kAjwBpXf5Ypao+feq6SxUu75DfyCUqpRWsyxxRQ8YTSkyJLo?= =?us-ascii?Q?7un7rEcLr3C/aGUsK8gOenUrgalxIDOrPQaTDwlIZ5f/gL+Ju/6uU0Gz7j8+?= =?us-ascii?Q?8DpEo07ih35W4RZJlCdAN2uDcBUQMzW74HHzUtETjs5naRQsoyx+HGL7Mn7w?= =?us-ascii?Q?OGRBAlxyZiRolDkcQRCkLIK6B+0pxvOeYV71VeMIuYbvp0vn7nWSWL4TFHMz?= =?us-ascii?Q?aa4IzSS/Pjz8bRtZK1wTifXmm9u5rNZTCB1ce07RnqzP2W3udomxz1pf/5wK?= =?us-ascii?Q?nvVQKfLG5jnmbh6qCJo8dkhozTU+I7ukmrXzWN5PoLVy8gt4gQXjt/Y3BtKQ?= =?us-ascii?Q?BjEd8yNW5WuiJo8yFWZKIb1EjOVsRoLRtXtlF5DoVhoLPqOg9bIyKx2jJwyl?= =?us-ascii?Q?kIS+fZNiYIPFOdYMcvq+EvCFWfDUQynhWNx1QY9TE1BHQn2oPFdCTt7976Cw?= =?us-ascii?Q?cEh+Xt9gBQIdOScj0pAe7xM/hfcSUKHBE4Y1VXC2saq2eRBscCQmF16cFphm?= =?us-ascii?Q?0Lak+w/R1C5WXsIVowk0qJg+8CaAnbplkreav6+S6iucfbEBnkoxo2jan5nP?= =?us-ascii?Q?sKb6mFXaNB4/AoZyJUYi464QQwSLnO9uvRRbGoa9Bs0XwAFH6/MMWZDSiNhQ?= =?us-ascii?Q?Xn0A/oYd4qLrRr9aRi1DljXxDRKQNy0=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 720baa5f-9696-4d29-2c8f-08df1583a75c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 12:52:10.4377 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Bf+yn9iBaN8UO29sdesy6uXtRM5bafIf93gwDOY2LbZnix6R5IblihCQRE68xrsw8Yt9An1dItmAFUfo3sifbzXV4vTVfqt3ImmjO5hLM4I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5250 X-purgate-ID: tlsNG-c201ff/1789735934-71CA82A1-DFC3D292/0/0 X-purgate-type: clean X-purgate-size: 2454 As per the VMRUN pseudocode in APM Vol 3 3.38, the VMCB's NP_ENABLE and N_CR3 fields are not set during a VMEXIT so don't do this when updating VMCB(1-2). At the same time, cleanup the somewhat bogus and irrelevant comments. Not clearing N_CR3 does not introduce a security hole as stated since L1 can set it regardless and it is never used directly when running L2. Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/svm/nestedsvm.c | 32 +------------------------------- 1 file changed, 1 insertion(+), 31 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index a8b15d6eae05..c62fca571d75 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1023,37 +1023,6 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) ns_vmcb->event_inj.raw = 0; - /* Nested paging mode */ - if ( nestedhvm_paging_mode_hap(v) ) - { - /* host nested paging + guest nested paging. */ - vmcb_set_np(ns_vmcb, vmcb_get_np(n2vmcb)); - ns_vmcb->_cr3 = n2vmcb->_cr3; - /* The vmcb->h_cr3 is the shadowed h_cr3. The original - * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, - * hence we keep the ns_vmcb->h_cr3 value. */ - } - else if ( paging_mode_hap(v->domain) ) - { - /* host nested paging + guest shadow paging. */ - vmcb_set_np(ns_vmcb, false); - /* Throw h_cr3 away. Guest is not allowed to set it or - * it can break out, otherwise (security hole!) */ - ns_vmcb->_h_cr3 = 0x0; - /* Stop intercepting #PF (already done above - * by restoring cached intercepts). */ - ns_vmcb->_cr3 = n2vmcb->_cr3; - } - else - { - /* host shadow paging + guest shadow paging. */ - vmcb_set_np(ns_vmcb, false); - ns_vmcb->_h_cr3 = 0x0; - /* The vmcb->_cr3 is the shadowed cr3. The original - * unshadowed guest cr3 is kept in ns_vmcb->_cr3, - * hence we keep the ns_vmcb->_cr3 value. */ - } - /* LBR virtualization - keep lbr control as is */ /* NextRIP */ @@ -1083,6 +1052,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* CRn */ ns_vmcb->_cr4 = n2vmcb->_cr4; + ns_vmcb->_cr3 = n2vmcb->_cr3; ns_vmcb->_cr0 = n2vmcb->_cr0; /* DRn */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 12:53:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 12:53:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425283.1649331 (Exim 4.92) (envelope-from ) id 1x7Y5S-0003EA-Rp; Fri, 18 Sep 2026 12:53:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425283.1649331; Fri, 18 Sep 2026 12:53:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Y5S-0003E1-PB; Fri, 18 Sep 2026 12:53:06 +0000 Received: by outflank-mailman (input) for mailman id 1425283; Fri, 18 Sep 2026 12:53:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Y5R-0003Dt-A5 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 12:53:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Y5Q-004l4O-Mk for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:53:04 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad341e-8faa-0a2a0a5109dd-0a2a450ab8d2-18 for ; Fri, 18 Sep 2026 14:52:59 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad342b-f2d2-0a2a450a0019-4a7de18dd2db-3 for ; Fri, 18 Sep 2026 14:52:59 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49cd5462b69so4066565e9.1 for ; Fri, 18 Sep 2026 05:52:59 -0700 (PDT) Received: from [172.18.138.134] ([185.104.138.149]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4871ff3ae1fsm3689424f8f.8.2026.09.18.05.52.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 05:52:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789735979; x=1790340779; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rLfgc6+yuqe7f6diCPn3aKlcAw9KvU3+mrO5QDX8jZM=; b=IYgc1/AjFjstvP16V3OArTW8LMmZHwIENVujGsH8N7HWuSnhAqEDmf5/3bdUYZlbSY E4Ot07pXE4J18iXoBXGQxIj0mwIkUIMwN92uwTJOXStMJbL1cIqc+HuOFa/kuN3zfLiJ 73mkuitRfyu+33Nk4ZnkUo4PFaWdofxiXIBB1I7TTFqDDUnrV4sRZ2bdBi05pOdF7y2P 42ATGt3bIGsXSA3JYwzbWhT9JNZUykbuRaZ7ZgX0+kaJwtYZhe9hKkTgtT/+aJyvPlFM 537ukNf8aOqi2lsLncZBFc1Jz7qx9djJR7hZEo2fufatgkYAK4WTGrrx47uYdfv7mGJG quHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789735979; x=1790340779; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=rLfgc6+yuqe7f6diCPn3aKlcAw9KvU3+mrO5QDX8jZM=; b=QpOXPDDjn86jrjqQiibKYz0ZOap64Dac2QtmzkWui75k26GnAf0i7aKf2921GRXn8H lR9FELxYte1qfY6sc5tnDpXwdhJduaB400i1kfOpDUQ+svVw9EBY9KRvDv61dJ3flgAI PRO34+Cn2aeAk4PKLgGRIm9b4tEyhBWD1Ni9UnpjrPig3XMkOO87Tskxkm8vbn6IZmtE P4b1ryRr0Ne7FNKzLjfTcqPLfSoLu/zHmlqbuRkil/qvziLDFi3gYLg3gJSdNV+PrNLE vaJFzq57DOiztIlVawNvcvq3ZpPfiznxxCQyDpIDaVB5N7H+AQbh6PCLhviXYw+FSXZm WeRQ== X-Forwarded-Encrypted: i=1; AKwUvBxAyq6jfbmmpT9maV7oHd/YMPasdzM39QP5QBeq49Bo/0Xmb/mpRJ4teOW8+VpU0TpYIUc4e/4wwQc=@lists.xenproject.org X-Gm-Message-State: AFuF++l/XHy84tBQBXhLeP44Qav0Tn0WIxI1pHTrqcqmiJ0r6uuM0q12 +l0uxPEZr5+i+47vbQqZURn43oU6LU19u+YMx84Hi+HLh25jal9blX+dDJ5wO0zfpw== X-Gm-Gg: AYBFou3mgbAW/I6qNbVDRcYe1TIDNnrxs/nwD9evOeiyGaU4Cu7h0aqS1UtKyF137AM zrM6LIHKGMFZhp6z5WqeaiglITUs9t3qfgvQC1N+7oY06OIq0nhvynNDJtjhtmt4GIVUVIWk1j+ Cj95akgZVb/yvb1cq4URqZVD4EAeogrcWSsfH2lwlWqOkJiws4lf57o3OU2VsUisqE/Zt1mp8r3 oD+1Y6nizXouFzoVz+w3ikT8YtK1OgNgjUr/skYWwLFsMTHDALr66YqZ45Q/+LzPt1XOIPogNMy /DSMkd2j2Qa4B038MApYskxFSby8mUMoL4XNvfsKdrvAftmugn6kCzjUsbkqJoaqC2jvvinn1sf GpeKvAEniLUECxV0cYcNA7N8sZVlK2AQh5W2tepEWYUVd146LXiY4o0ksRXgML2CSLhC4xCxy/x 93FXj3224ES2/ojkYVjukYKabtB9diQQwMYN9Ixi3d+ZzBsnXHtmyJBXCi1e1+DioPYDcVViivO WNpQim5FlQ= X-Received: by 2002:a05:600c:1f95:b0:49f:bcb7:8e9 with SMTP id 5b1f17b1804b1-49fc5726c1fmr60163275e9.9.1789735979021; Fri, 18 Sep 2026 05:52:59 -0700 (PDT) Message-ID: <9260a8cb-66f0-4eba-b630-666039bf2e72@suse.com> Date: Fri, 18 Sep 2026 14:52:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789735979-58BC8CFC-44CBF150/0/0 X-purgate-type: clean X-purgate-size: 4385 On 27.08.2026 17:21, Oleksii Kurochko wrote: > @@ -62,23 +69,25 @@ static int cf_check cpu_callback(struct notifier_block *nfb, > unsigned long action, void *hcpu) > { > unsigned int cpu = (unsigned long)hcpu; > - int rc = 0; > > switch ( action ) > { > case CPU_STARTING: > - rc = vgein_init(); > + { > + int rc = vgein_init(); > + > if ( rc ) > printk(XENLOG_ERR "AIA: failed to init vgein for CPU%u: %d\n", > cpu, rc); > break; > + } > > case CPU_DYING: > vgein_deinit(); > break; > } > > - return notifier_from_errno(rc); > + return NOTIFY_DONE; > } What is this hunk doing in this patch? Was this meant to be merged into the prior one? But then - why? > @@ -168,3 +181,36 @@ void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) > __func__, v, vgein_id, cpu, vgein->bmp); > #endif > } > + > +void hgei_interrupt(void) > +{ > + unsigned long hgei_mask, flags; > + struct vgein_ctrl *vgein = &this_cpu(vgein); > + > + hgei_mask = csr_read(CSR_HGEIP) & csr_read(CSR_HGEIE); Misra, aiui, isn't going to like this. You may want to split it up. > + csr_clear(CSR_HGEIE, hgei_mask); > + > + spin_lock_irqsave(&vgein->lock, flags); > + > + for_each_set_bit ( guest_file_id, hgei_mask ) > + { > + /* > + * guest_file_id shouldn't be zero, as it will indicate that no > + * guest external interrupt source is selected for VS-level external > + * interrupts. > + */ > + ASSERT(guest_file_id); While it only affects debug builds, this check still needlessly is done on every loop iteration, when doing it once ahead of the loop would suffice. > + if ( vgein->owners[guest_file_id] ) > + { > +#ifdef VGEIN_DEBUG > + gprintk(XENLOG_DEBUG, "%s: kick ->%pv, hgei_mask(%#lx)\n", > + __func__, vgein->owners[guest_file_id], hgei_mask); > +#endif This can ocur very frequently (when VGEIN_DEBUG is defined). A trace record may be a better alternative. > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -136,6 +136,8 @@ static void vcpu_csr_init(struct vcpu *v) > v->arch.hstateen0 = (hstateen0 & csr_masks.hstateen0) | > csr_masks.ro_one.hstateen0; > } > + > + v->arch.hie = MIP_SGEIP; Neither part of the rhs identifier has anything to do with the CSR having its default value set here. That's perhaps again a piece of RISC-V I'm missing, but I can't make sense of this. > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -510,12 +510,31 @@ void cf_check imsic_ctxt_switch_from(struct vcpu *v) > > write_lock_irqsave(&imsic_state->vsfile_lock, flags); > imsic_state->vsfile_cpu = v->processor; > + /* > + * Start to observe the VS-file from HS-mode: while the vCPU isn't > + * running an interrupt pending in its VS-file is reported through HGEIP > + * instead of being delivered to VS-mode, which lets Xen wake the vCPU up. > + */ > + csr_set(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); > write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > } It is suspicious for the HGEIE write to be the last step. How's this free of a window where an interrupt is lost. (Sorry, likely another blind spot of mine wrt RISC-V.) > void cf_check imsic_ctxt_switch_to(struct vcpu *v) > { > - /* Nothing to do */ > + struct vimsic_state *imsic_state = v->arch.vimsic_state; > + unsigned long flags; > + > + /* A s/w VS-file is never observed through HGEIP. */ > + if ( !vcpu_guest_file_id(v) ) > + return; > + > + /* > + * The vCPU is about to run, so hstatus.VGEIN delivers the VS-file's > + * interrupts to it directly and there is nothing left for Xen to observe. > + */ > + read_lock_irqsave(&imsic_state->vsfile_lock, flags); > + csr_clear(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); > + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > } How can this be a read-lock when you write a CSR? Or else - why is locking here necessary in the firt place? Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 12:58:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 12:58:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425295.1649342 (Exim 4.92) (envelope-from ) id 1x7YAJ-0003xO-DY; Fri, 18 Sep 2026 12:58:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425295.1649342; Fri, 18 Sep 2026 12:58:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7YAJ-0003xH-9z; Fri, 18 Sep 2026 12:58:07 +0000 Received: by outflank-mailman (input) for mailman id 1425295; Fri, 18 Sep 2026 12:58:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7YAH-0003xB-C6 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 12:58:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7YAG-006At9-Kp for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:58:04 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad3547-bab6-0a2a0a5309dd-0a2a4508dffc-46 for ; Fri, 18 Sep 2026 14:58:04 +0200 Received: from [148.163.158.5] (helo=mx0b-001b2d01.pphosted.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad355b-f659-0a2a45080019-94a39e05e4cc-3 for ; Fri, 18 Sep 2026 14:58:04 +0200 Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68IA2ka3990915; Fri, 18 Sep 2026 12:57:18 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gmxcvfgrx-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 18 Sep 2026 12:57:17 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.18.1.11/8.18.1.11) with ESMTP id 68I9oGpj507832; Fri, 18 Sep 2026 12:57:16 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4gra3yxedq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Sep 2026 12:57:16 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 68ICvEb851904874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Sep 2026 12:57:14 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9D53820043; Fri, 18 Sep 2026 12:57:14 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EB2DB20040; Fri, 18 Sep 2026 12:57:13 +0000 (GMT) Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown [9.224.92.206]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTPS; Fri, 18 Sep 2026 12:57:13 +0000 (GMT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=vvXTEBXtIpBfma8CBebbY+SSqqX1Qu WR6+4vIHcllvk=; b=byvnC9DgZuLKYo4mY9QFMiFQ6Zc5eAvVokdOQ/jMnu/ROL Ihy697HfGNSs027KQksAAkjwX7YaRrLsOO1g/6wd0s+CHm/STBQ5bGQE02PrUNuG /jNGEuQyMJ0GgJpPIZLUjqfcXRUhYNBUGxSiAGrMMe/ZN3ie+9Negm0sXqB2qPGg G78+ulSPRFoKyeDh2Y4ugEz6Mth2PVTjmT/mNSj1OZo6IEDn3Mmfrt4AuGBiF3It 82M05ljqdaF9c5/06LrZaWpRH1x7tFsqkPtu0asE5M/h1WbsI4/lZhbLwmk3A6qp RqNdQRRqouleichhat5Xw20CbOufAHP17/U7CBSg== Date: Fri, 18 Sep 2026 14:57:12 +0200 From: Alexander Gordeev To: "David Hildenbrand (Arm)" Cc: Muhammad Usama Anjum , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values Message-ID: References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE4MDE3NyBTYWx0ZWRfX0a+YmMinfqLY thIpqQ3k+YsaEL1Nu5Xtb4MVEpoHSHo6PXFxsq+F/Wx3xKw0f3hhtQwBUt801YS/UAG/0atek9m HF3E84n9wG4sj7upDsGZ+DoHJXM8gUk= X-Proofpoint-ORIG-GUID: m4DES1QILxZeg9-Jkqr1aSPqQzDTxZM1 X-Proofpoint-GUID: m4DES1QILxZeg9-Jkqr1aSPqQzDTxZM1 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE4MDE3NyBTYWx0ZWRfX/T2l95nFB1Uq xYhD9MK3T3CmjxCnR5kdtXxgndhWw6MxRYXoXqGlboj2UoA37O8EdLIe4YiWjjUCSxbCjYPDLdb zLflGPxTioAC9+xJzOGZkBco09vb3ShkcVMCROX8/GZfFwvrgzmx7n0qXL0rX5zPKB/njtDxwgb gMHToemhE70TFtiB9Pj1PeVjgH1oGQscKJTsEGRxHL5kVet2L1efcSErMDeLFJpVDhkGjX606/4 v67gUAI8g2+alWIwtI8/jPJ+6ph22PnYWj6b88V7/Iglrvc/jT0GvjzhQ6L6hTrFOvO8q+nsLfd IM1uuwdfshQ6+5Im7f+26qdGKHnOEavHW8zEdphBYVrG/drJ0FH1jWiiDkeaELYlUGloVtsBlh+ 7nM/BRgAPEjc6uhD2wSkdjVssp3wph+7cmdpYUKnvEQX/Ft2fdQFowSRajI1e1u1DVerG791p4M bjrU9H6l+Tvys0K+DAw== X-Authority-Analysis: v=2.4 cv=F+7C5ahN c=1 sm=1 tr=0 ts=6aad352d cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=kj9zAlcOel0A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=36OLCuKFP8Pi5wnj2vYA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-18_03,2026-09-16_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 suspectscore=0 phishscore=0 clxscore=1011 malwarescore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 impostorscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609180177 X-purgate-ID: tlsNG-c1860d/1789736284-CC77387B-635A3935/0/0 X-purgate-type: clean X-purgate-size: 604 On Fri, Sep 11, 2026 at 06:55:18PM +0200, David Hildenbrand (Arm) wrote: Hi David, Muhammad, Sorry for the long delay. > Unless there is more feedback on the overall approach, the next step for this is > to have at least one architecture support posted. > > We should only merge this if at least one architecture (better two? :) arm64 and > s390x? ) would merge the architecture bits. I am going to give it a try, hopefully next week. > That is, we should get an ACK from the arch maintainer son the common code bits > and the arch bits. > > -- > Cheers, Thanks! > David From xen-devel-bounces@lists.xenproject.org Fri Sep 18 13:14:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 13:14:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425319.1649349 (Exim 4.92) (envelope-from ) id 1x7YQO-0006z0-Q4; Fri, 18 Sep 2026 13:14:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425319.1649349; Fri, 18 Sep 2026 13:14:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7YQO-0006yt-NV; Fri, 18 Sep 2026 13:14:44 +0000 Received: by outflank-mailman (input) for mailman id 1425319; Fri, 18 Sep 2026 13:14:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7YQN-0006yn-IU for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 13:14:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7YQL-00CRVo-8w for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 15:14:41 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad3939-2eae-0a2a0a5409dd-0a2a4501c9b4-14 for ; Fri, 18 Sep 2026 15:14:41 +0200 Received: from [52.101.62.13] (helo=DM5PR21CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad393f-5984-0a2a45010019-34653e0d704e-3 for ; Fri, 18 Sep 2026 15:14:40 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CH4PR03MB7724.namprd03.prod.outlook.com (2603:10b6:610:244::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Fri, 18 Sep 2026 13:14:31 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.011; Fri, 18 Sep 2026 13:14:31 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=d849NjUXKlFA1XwqhQJo0e4lgI1pF4j7iUBSVjIMiOSFwCa6+yAlpizJoDVs3jfaJ1f3X1pVNDi5Gy4WWaajVLjVv4EGcpm3CTTY3jK7Y/J84hV4/eErIpy49OE7xeTKwVWOA/Xspq/lTFo06uxDAd0V6HIzpM1SHGC+tE9FX6EMlBtxMDLBpYsVpdLHfl3F8Lk7vqaNnbSvHtvrTPPyM7G2KTOPWSQh25BvPbwQHcYiDO8o3tnVTELKQd2MibIwL8RcnHV7CY2ky23EV9hnZSb93FZtcXfqJJPvEyTC1zp3lJRCY+KuXpadJ9mD2/TI/nUUGARyX/sCiNTQ5h++Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S4ifpLomry5gMeyeT/ahOwYrLfz80Zmfr7qTuPsi0dw=; b=ELBlQOlb4nn3Z4YoS9jpHVgceKSD99SIwEBZ4sxIOxVhYPQcZLWtPtzVM+aZoubxcyUkToLMtZabuAgkxbtmN81VZ+gbPvw3uybf5TcmfsR6+kt4U0MyZaCnAmSxzuOWfUpR6KZpl5R6eV0NMtY6JgqVLnHMcaADjXgrdlH8RZCuuGBho1aDyoXF37hdJW4mws9EK4Xe8tf7Frm/uGtWb5abWw25wvn/uiPPKIJLH3RO+cHqGTolm6ws2zmijc5Ipq/8U055ZJ+ZTgWvLsn1+A5dmRTcmdseCFR2veIwHoG99xotsD6TQo3cmRmTBs3kNmy/uz+GWqq5lfkuPEoDnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S4ifpLomry5gMeyeT/ahOwYrLfz80Zmfr7qTuPsi0dw=; b=RQOdB5t0X0BUU1BqQKEpybuu2zilzFIrFW7Qen5u0/ZqbKmjgFrbLsb6ejI9+5COzQao9/A37S45ZsRf/sYtXUDARkIlFbrlNIeW7IJFJVSuRcXgHpC4AUwy4+Fc93p0K+FfwelRjd7zhIgwfrWSd1knR7/oaLFg/SOatV7nNYk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0bf76f4f-8762-4e28-9964-479400e8ec76@citrix.com> Date: Fri, 18 Sep 2026 14:14:26 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PULL 04/11] xen-mapcache: Remove 32bit support To: Peter Xu , qemu-devel@nongnu.org Cc: Paolo Bonzini , Richard Henderson , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , xen-devel@lists.xenproject.org References: <20260918113926.831204-1-peterx@redhat.com> <20260918113926.831204-5-peterx@redhat.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <20260918113926.831204-5-peterx@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0511.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::18) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|CH4PR03MB7724:EE_ X-MS-Office365-Filtering-Correlation-Id: 29166d1c-218f-433b-2fb5-08df1586c673 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|22082099003|18002099003|56012099006|10067099003|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: bd16kEWStNhP7tjXnPvxBAexvu4kTw/qVsLqc+7gGEcwn0511TC9YmclncCouC8boYJe946eRIU/vjGcMxA2bXtf1vJQrZnsxMkg4oQb2zOorpjnTvh58idT7zHVt4fTYt6biDtf65JBZiZI24ULcgRJnhOYn6l1yC3qFbfpwm3jjTaDMElZPCwqcbNHf8+MjPGw+C+4QNbnTp3z2q3hTWTkANHKADIzHOAuf+ajY3HS7rz4QbwjpfJzSFz7WiJ/mkeexICwYkSg/XNu9eHvjRnFlCTjv8WCZWh9iavB4QSLM2p18jcvZxx05VlTYZ79Oj61MMSjyVz2bBp+jtypVJT4c7VaCjKxvx/buUqajp82ZcZdwdCTfqMAVVu+nilutVBMV1vKDtjPSX6R6GRJQuxlfiz1Dg70sY3MV+DViSbeRIHshFTgBjaFYuiJrjS6ixNNQG+CpymgsYZzfqvbZT1BY6zZGhponuS+kTKy8CqxRIwFOwT9qo7poLp5I7HnQM4LjBVpL8n70sDzOzT6Y9YuTL1JDzCNKGh4YRUqYCsGOeQvZyxO9ULYHIyxXf8JP0MJ4n6KrBk0KZ+w9alh4ZvJ8ayoo4izCyC+UFDkZtWWPDiL2Sl1thIaXJe5euqFvHbsHmsmtUljBOuxvuFlrd9nUyOqZ6kA9Sn2zZqgQIA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(22082099003)(18002099003)(56012099006)(10067099003)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QlVibkhpQ2grTjV0akhRZWhrRnBoSnh1SHplSVhZS0FrNWU5NVgrWG14UW9T?= =?utf-8?B?RUt5MERDOCthZENsai94Z0pvVnM3UU1la0UxMUhxeVloWmdVOFRvUzlKS0JJ?= =?utf-8?B?S1BCQ0JZejB0dHVGcXZacTZ3azZqZDZ6MkdpOEtpdGJMWGlGZ0d4MWJkbjhX?= =?utf-8?B?N3RMRWpUVGxaNjRUVWppZ1l5eVkzUUxtRGJHa0llVkhoUDBTdG81T29SN3N2?= =?utf-8?B?eHovYjBYQmJrcEw2bFRzbHRMeWJQeHFFWitBOE9NeTZUakprK1k1MzhTS0VQ?= =?utf-8?B?aStJOUo0cVhhNEtTenBiZXlka09yWStiTUV5OHVrN0piV0tHL2JYUHl0Y3dm?= =?utf-8?B?dDNuZEpPR1dMTk5tZGpNYTQrWGdBMFlCbnVWblVMTzRwQ2tGVmcyV2loT1lp?= =?utf-8?B?QmdSa0FTaGZTTmQ3ciswdHZqc2NVeVVxYXR0VU1DZndSajg1WXNWTlFmNHBE?= =?utf-8?B?dk05VEp1eWVEeFNJbVBQQ0taU2hnUk5temQ3dDh1VGhvSEF5RjJQYTk5dDFy?= =?utf-8?B?NmZkRlRFUVI1K0IzM1ozbzNsZmtHajZDQUszS2I1a01MRE9sZDVIQzZudVho?= =?utf-8?B?cUxXZ1NxMFVmb29lMVp3ZUcwSUZncS9OUnZ4VStyZEpqMTBnK2l3cjd5TVY0?= =?utf-8?B?SE1jZUtJSENPM3ZWSTRuVytMbUZRNzE1bWJoeE42azhtcGkwNXQ1Z3FwdGZk?= =?utf-8?B?Zm9ZUDdrRDRrd3V1N1RuUkhJdDQ1ZTlzSkhTWlRVN3o2c3g0S2xLZnhmVHdq?= =?utf-8?B?RjMySWo0bTUvTXZRY1dra2pvMEhHOExMMG9HaUd4ZWlnd3VVWkxhRmlrQmpu?= =?utf-8?B?cWNQaTd1U2tWUld3NDliZGVuR1A5cWFXVGd6bjRYTjFMTFYzV1ZReVp3Y2o4?= =?utf-8?B?bXFtaEx0OUdNS3A4UlFsS0ZFL2lTemplRVIybkUvd1ZCSVhXNWIwMG4zRWFI?= =?utf-8?B?SW8wMTZvYk5BemhtQ0txRUNuQjlmS2R2ZUJDNDBDQ2VOMVQrcDZSRC9mcGhU?= =?utf-8?B?aDZiVU8yVTJsaE9Fb3ZKckhwQkRzM0xxVER1Rm5TeHVhdTNVWFErWmp3bFBx?= =?utf-8?B?cGp1elluZjlQRXlRZmJSWHMvT3N5ZTZuQlZ4ZmNvMkZ6VVFraGtRYUgraFVH?= =?utf-8?B?ZkFFQ3FDRE41dnJvUXJ0Y21JWWhPeXdjRTZmRGtEenhJT28ya0NHL2JGMHM2?= =?utf-8?B?NHdqQnRGSjNWbGg2MGx1M0sxSEJ2aEh4dXMxWjllVktneFN6UHdva2F5Vk9a?= =?utf-8?B?ZmdGSFVRZUJPTVlOQ1R4SmltTzRuNms5M09DVitTZ2tDdGZETWJ2akRYNXRV?= =?utf-8?B?UTZBdjUydVJFK2NMRmlLTllvUFUzcUp2aGNScEUwUVh4SU1Na28xdWVIY01v?= =?utf-8?B?Tk5HYk4zU2hrQWRBSTBQN21kWVpRSTRnYUZKNEZ0MndhbFBZdjA0KzVWK2Qv?= =?utf-8?B?eDZmRk8xYUExUVNzeFhmdStQRzFBa2VucGU5SzIwRGtOSDFQaFhhUnA3eFJY?= =?utf-8?B?dHpQY3krd3M4ZDdEMEFrS0xnanY3WHhTUkkxRWg4UGswOTNINVZVTFlVeGRC?= =?utf-8?B?L20rNE9vcVhFckVlQ25UU3N1SGhBQlU4MFNUZE41dXNtSm1nR2lORXp0ZDIz?= =?utf-8?B?VjRQdWpTdHZ5cWNJYVFoNEVkTVpPLzBiWkxuSHRvcnR4WWJBSzJQcGlLano0?= =?utf-8?B?bHY0eGxWb0tmZERvOHhueU02Vkg3UW9uOU5Od0s1d242eUFIcmdCTmhBUWkw?= =?utf-8?B?bjF4TE5zOG9GbWdDaFRwRWdiZTNXTHhqU25mc0IwYVc5dWQ0Vyt3RERvRWdI?= =?utf-8?B?c1RiS0llYVc4dzBoOXZGT2xRbnVZNFhmWkkzMkU4OStBTmNjak1qNWE4aHMy?= =?utf-8?B?d3Y4UTY4c0xhNVFnSVFIUnhGRWJLdzJSRUFTcFY3MVlmYUtiV3d2QUdZVHBO?= =?utf-8?B?Mzd6ZXRlS1M3NVR6Y3pVSCt3YldMN3hRNDlnMnp3STFWOTI5bUxweEkyUTVE?= =?utf-8?B?NHViN1c2Qm83QmR0b0dQTUZqS0NFSDYxMS8xUUtWa29MSE8xckNrWFFBaVRq?= =?utf-8?B?RUlXUGNscTIrV1I3ODNydENldzhLRXdKZkJmcStrL1lUMm5pcWRkbzBoZDNs?= =?utf-8?B?UlpWdUxpYkpxV1dJVHlaUnczeGF2LzZmN2lraE5SWThLSWxkdStjWGlFS3hQ?= =?utf-8?B?ckEvWVRoUzUwRVFhMGhmU1FyZVpsK3hwbk1mTTc4enZreVJudXROTzU0eE5x?= =?utf-8?B?L1hVTVMxYjZxc1lGNElPVGZqZVdzUWIrakRvNFc3RllPajg3TW1yQkRGdklz?= =?utf-8?B?R21ML0plN1gySHB4TUtucjRWMG5uRU51OGYyUjhwdHBvVEtjazlWMk9UblpH?= =?utf-8?Q?VX1JCpNY0eO3A+ks=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29166d1c-218f-433b-2fb5-08df1586c673 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 13:14:31.0591 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tW6vK0g1vQsAcvSTVZpPioCjRl/taSdWqB57snQdVUJJVQzuBJWd2QRIgKvCy750KVjU6Tm4cpbJnB38KQQTND1yG9l2862clC2BqW/qEy4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7724 X-purgate-ID: tlsNG-d62444/1789737281-1D47D757-95DCDC44/0/0 X-purgate-type: clean X-purgate-size: 1938 On 9/18/26 12:39 PM, Peter Xu wrote: > QEMU has switched to 64bit-only hosts for all system emulations. > > Reviewed-by: Richard Henderson > Link: https://lore.kernel.org/r/20260818172012.3052821-5-peterx@redhat.com > Cc: Stefano Stabellini > Cc: Anthony PERARD > Cc: "Edgar E. Iglesias" > Cc: xen-devel@lists.xenproject.org > Signed-off-by: Peter Xu > --- > hw/xen/xen-mapcache.c | 12 ++---------- > 1 file changed, 2 insertions(+), 10 deletions(-) > > diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c > index 85cf0cf359..e30c07c2ee 100644 > --- a/hw/xen/xen-mapcache.c > +++ b/hw/xen/xen-mapcache.c > @@ -26,11 +26,7 @@ > #include > #include > > -#if HOST_LONG_BITS == 32 > -# define MCACHE_MAX_SIZE (1UL<<31) /* 2GB Cap */ > -#else > -# define MCACHE_MAX_SIZE (1UL<<35) /* 32GB Cap */ > -#endif > +#define MCACHE_MAX_SIZE (1UL << 35) /* 32GB Cap */ > > /* This is the size of the virtual address space reserve to QEMU that will not > * be use by MapCache. > @@ -151,11 +147,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque) > exit(EXIT_FAILURE); > } > > - if (HOST_LONG_BITS == 32) { > - bucket_shift = 16; > - } else { > - bucket_shift = 20; > - } > + bucket_shift = 20; > > if (geteuid() == 0) { > rlimit_as.rlim_cur = RLIM_INFINITY; Using a local variable here to store a constant is a bit weird and its only use is to be stored as MapCache.bucket_shift and MapCache.bucket_size which are effectively constant. Not sure why this isn't just a couple of #defines at the top and used everywhere bucket_shift and bucket_size is needed. Perhaps that is further cleanup to be done separately... Ross From xen-devel-bounces@lists.xenproject.org Fri Sep 18 13:41:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 13:41:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425429.1649375 (Exim 4.92) (envelope-from ) id 1x7YqZ-00047C-5f; Fri, 18 Sep 2026 13:41:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425429.1649375; Fri, 18 Sep 2026 13:41:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7YqZ-000474-29; Fri, 18 Sep 2026 13:41:47 +0000 Received: by outflank-mailman (input) for mailman id 1425429; Fri, 18 Sep 2026 13:41:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7YqY-00046y-0c for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 13:41:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7YqW-00H3bU-Py for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 15:41:44 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad3f96-8faa-0a2a0a5109dd-0a2a450cc534-6 for ; Fri, 18 Sep 2026 15:41:44 +0200 Received: from [170.10.129.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad3f97-f479-0a2a450c0019-aa0a817cb93b-3 for ; Fri, 18 Sep 2026 15:41:44 +0200 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-171-1SauZwYKM9iiP2SvQtFw5Q-1; Fri, 18 Sep 2026 09:41:41 -0400 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-93a0b66ecd9so102336485a.2 for ; Fri, 18 Sep 2026 06:41:41 -0700 (PDT) Received: from localhost ([2605:8d80:6cca:5143:ebc:a1f4:364f:cf43]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93be0efd37bsm141509485a.38.2026.09.18.06.41.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 06:41:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789738903; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fA+YtUCi0+i0hv6NQ/TTYdlAyqtE/zN8XZqq/DhWBp0=; b=drTdKTH0xRN5Sew06FAoEOEwM921o3pV5nvd5gb0O2ndIM+PwnkvXJlK0wxgrZoodjqe+r qMg3NAnzOSWjvzSuTm3+uv+2bTDg1c4v/RxXJxXe3+xke+9ERnzNM6gQ0ONCRms3Vq4gbk vXqg4Ea+Q2vEht9u42PP8p1qmDgA2z0= X-MC-Unique: 1SauZwYKM9iiP2SvQtFw5Q-1 X-Mimecast-MFC-AGG-ID: 1SauZwYKM9iiP2SvQtFw5Q_1789738901 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789738901; x=1790343701; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=fA+YtUCi0+i0hv6NQ/TTYdlAyqtE/zN8XZqq/DhWBp0=; b=V2xbH8TKHcj/qxEkgKZ+m1iMdpMSf/rZI/Qd4Y4477C8RC6OiByc5Odo7lcxUCGyNd X0RL6jDEg/DUJV8cXV8urGQY7Xnnui/kyVWVCUrOWliZALNerrRLK/4Cb5XjkVx71l/7 7XtQNZCAqVtMmVr8owXgU5VcWLn1rlsf12UzjsbQQud4p58YUqFp2QKkv+TxDOnY4fWQ 2LeOOQsL/ArWt6mkUEy4jbFSb4T6SF8bdTaQnLR2uJYP20qrnPUNGVTC5XMXRry/awY4 sx01UhXEpZdzQ0268OYXUl5qXi2c32JCYFIMqLk369wD09QmwlVAkMqGsXb2YrE6QahG wjLg== X-Forwarded-Encrypted: i=1; AKwUvBxdMG4OQUvTsj+fqWsbtuTSlRu7haP6eS1Hw34bEK/V6Oz63+jh0plAX+Dy8GlW8yN0419GMLGgiPg=@lists.xenproject.org X-Gm-Message-State: AFuF++luDD+JlQXqucBdVRKeC/XV8JJKsL14XqzfRpGtvYMPa/DNHDxt lyU2ieZxd2tothX9ZuyHf86pF35Bxo5XkyK+jUAFslS+BGDQu/g4QmLpsnvY9uTxWROffBio2ZK P6hd+OtW7DwDygR+pjZl37ejrPatTeB+teoDsL0J64SThHBsr/JB1Jif44pk6rXUFJSy8 X-Gm-Gg: AYBFou0YaOlRQ/i3/B9kq2Qx69Slz2Z08RKIQ8OifKEvRXnVvltC7MKPG5eDZLhKglE 1eAVttK1R5pMziezcfapzLKUTMbNWsLt+5q8miZ4z/Xloug/fG0r/+tgKGeLzuHkCQ0tphy/vpO LLl2jhv9SjrwRlDWIdMjTg/rq38PNWyDptg/gV0gF/k1cZpLevkE40Eyp7quhWlOdFzMOiu6gxk +XL47HdRN6RR3mQiVvcMZYwWIxGGrsbahD+5GkXMcmLKiwwRAM8gBU4UQABsWpyYm1/TAtk+IVN 8gO3XN6jxJjnSfbKjT8O3cc45n+9CT7yG7rWmyhdZHHsaJZrFguYUQ6Y1sEEs3E3crKPRzE= X-Received: by 2002:a05:620a:44d4:b0:939:a45b:76ee with SMTP id af79cd13be357-93bdc70bf55mr372481885a.23.1789738900964; Fri, 18 Sep 2026 06:41:40 -0700 (PDT) X-Received: by 2002:a05:620a:44d4:b0:939:a45b:76ee with SMTP id af79cd13be357-93bdc70bf55mr372473185a.23.1789738900043; Fri, 18 Sep 2026 06:41:40 -0700 (PDT) Date: Fri, 18 Sep 2026 09:41:36 -0400 From: Peter Xu To: Ross Lagerwall Cc: qemu-devel@nongnu.org, Paolo Bonzini , Richard Henderson , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , xen-devel@lists.xenproject.org Subject: Re: [PULL 04/11] xen-mapcache: Remove 32bit support Message-ID: References: <20260918113926.831204-1-peterx@redhat.com> <20260918113926.831204-5-peterx@redhat.com> <0bf76f4f-8762-4e28-9964-479400e8ec76@citrix.com> MIME-Version: 1.0 In-Reply-To: <0bf76f4f-8762-4e28-9964-479400e8ec76@citrix.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: KKwNbS9kMepvI91Jk-fFWhUfEHrQWmcFHGxiH74flUY_1789738901 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-purgate-ID: tlsNG-d25034/1789738904-012C8A5B-6EA0E32C/0/0 X-purgate-type: clean X-purgate-size: 2657 On Fri, Sep 18, 2026 at 02:14:26PM +0100, Ross Lagerwall wrote: > On 9/18/26 12:39 PM, Peter Xu wrote: > > QEMU has switched to 64bit-only hosts for all system emulations. > > > > Reviewed-by: Richard Henderson > > Link: https://lore.kernel.org/r/20260818172012.3052821-5-peterx@redhat.com > > Cc: Stefano Stabellini > > Cc: Anthony PERARD > > Cc: "Edgar E. Iglesias" > > Cc: xen-devel@lists.xenproject.org > > Signed-off-by: Peter Xu > > --- > > hw/xen/xen-mapcache.c | 12 ++---------- > > 1 file changed, 2 insertions(+), 10 deletions(-) > > > > diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c > > index 85cf0cf359..e30c07c2ee 100644 > > --- a/hw/xen/xen-mapcache.c > > +++ b/hw/xen/xen-mapcache.c > > @@ -26,11 +26,7 @@ > > #include > > #include > > -#if HOST_LONG_BITS == 32 > > -# define MCACHE_MAX_SIZE (1UL<<31) /* 2GB Cap */ > > -#else > > -# define MCACHE_MAX_SIZE (1UL<<35) /* 32GB Cap */ > > -#endif > > +#define MCACHE_MAX_SIZE (1UL << 35) /* 32GB Cap */ > > /* This is the size of the virtual address space reserve to QEMU that will not > > * be use by MapCache. > > @@ -151,11 +147,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque) > > exit(EXIT_FAILURE); > > } > > - if (HOST_LONG_BITS == 32) { > > - bucket_shift = 16; > > - } else { > > - bucket_shift = 20; > > - } > > + bucket_shift = 20; > > if (geteuid() == 0) { > > rlimit_as.rlim_cur = RLIM_INFINITY; > > Using a local variable here to store a constant is a bit weird and its only use > is to be stored as MapCache.bucket_shift and MapCache.bucket_size which are > effectively constant. Not sure why this isn't just a couple of #defines at the > top and used everywhere bucket_shift and bucket_size is needed. Perhaps that is > further cleanup to be done separately... True.. It's my bad not noticing that relevant people were not properly copied when sending the patches; I thought each patch will have its own set of CC from get_maintainers.pl, but it didn't actually work and I didn't notice. I only notice it when I was just to send a pull, hence added Cc: explicitly at least in the pull sent, feeling that these changes are mostly cosmotic and safe. It'll be great if this can be done separately, makes me easier. If there's any strong feeling on any of the changes, please speak and then I'll redo the work. Thanks, -- Peter Xu From xen-devel-bounces@lists.xenproject.org Fri Sep 18 13:48:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 13:48:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425438.1649384 (Exim 4.92) (envelope-from ) id 1x7YxM-0004n1-Pw; Fri, 18 Sep 2026 13:48:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425438.1649384; Fri, 18 Sep 2026 13:48:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7YxM-0004mu-NL; Fri, 18 Sep 2026 13:48:48 +0000 Received: by outflank-mailman (input) for mailman id 1425438; Fri, 18 Sep 2026 13:48:46 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7YxK-0004mo-Hj for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 13:48:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7YxJ-00EgV6-4q for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 15:48:45 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4134-8faa-0a2a0a5109dd-0a2a4508e680-8 for ; Fri, 18 Sep 2026 15:48:45 +0200 Received: from [40.107.201.46] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad413b-f659-0a2a45080019-286bc92e158b-3 for ; Fri, 18 Sep 2026 15:48:44 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by PH0PR03MB989304.namprd03.prod.outlook.com (2603:10b6:510:3c0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Fri, 18 Sep 2026 13:48:41 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.011; Fri, 18 Sep 2026 13:48:41 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fYi63ZaEttOFVb2RmS1acD1WLf9u2N2dGQ5EWgQJzHdgXSAzRPq8Owpm3YTSbLXKfkbhioap5D11FyjX+B93EI3EzmJMIjj1PzTLo+a3xaXWbOYEKYgEU/ZLxn0Axr9POM6OtLweq9yAHcy71euQ4ENVqRMejwbyHyUyXBvypDKeGQKWAnNAVRr5djqr6AAdPA9sAzPu9LbTQSLq0hfl293cfjmysSZD9PXHKPiyp3tzyOf8CJPa8LuRF1+4MSOikKvntV06k9AXdBsKSqIJiR7rjsUii1XIXIWNAln31KzKpCFf+FgjbSxSNWhZsCzaEvzTM/1wiJx2vqRWT4POGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iSvoD2QhDS7LRDfKxNZb6FGqDEVd/0RqYV2zQj9z1YU=; b=l3DKRq2D34QFWU5SzXTzr18IrCHUZbW3/dfGn8AcRfFMREjUYxI7Ca/M3fcDNoL2SPQpU/jv1ddgIeBoJagfteL3TfwnbBFASmcjxrgJITmcQYxLt/i1R2dXdpKaiHpnRxEStGmqi16+eJzXeWFoJACLfAz7giywR9IObGBiP0KUk29yjGkNYSIib0GbvWNArmxwVjZG3DzdpogkcJmOX2kxFnYZdCx8gSK59d2q5ZOtoBWXw7MjdXMM+8Hyn8WERYdaYVZuWUbr3OFKeBMaWBIUmxAE+v2Vd7mXgi69dXy6uU+NdJ3fu6reOOGh1m2SzZ/Ztot3VQB/xoWEv5+T3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iSvoD2QhDS7LRDfKxNZb6FGqDEVd/0RqYV2zQj9z1YU=; b=0J8ZXumleJzWpJJ93ohnBSIuS/FhkX5bY/k8hQL75dytUWNvsmSG53TA7iSGOvhbtYMl29mhswPdvjqUWocEEGE3X1R0kjw8leINiQAbT/9LC6y7bIdtEeBIVtP6PxsiM4uAmoiHKPNCXaWpEwYTqVq7N5qKsSg25EoW93SI/8w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 18 Sep 2026 14:48:35 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 3/5] x86: Track vcpu context switches and introduce needs_tlb_flush field To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509308.8631fc262581453bbf619ec5b2062170.19fb8a5e798000e099@vates.tech> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <1785509308.8631fc262581453bbf619ec5b2062170.19fb8a5e798000e099@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0373.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::18) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|PH0PR03MB989304:EE_ X-MS-Office365-Filtering-Correlation-Id: 161f2922-103d-4618-be69-08df158b8c90 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|56012099006|11063799006|4143699003|22082099003|18002099003|10067099003; X-Microsoft-Antispam-Message-Info: fILLBlzrG/7Pma2jRIrh195S7wpWksHaKqSiTiGknAWQdC2YnoFUHuAmwlvNPCWWngeGoDN3DarpbcLhM4qRg6/OqG323CBCsvsP4E3/lR97KR6o1PSGgyhB1nl83Bteh6dssYVgXNOv4ShGgqMUg7XnDZZIL24PEAurecO3JFiOVKbk43tkh9jPt2ZqeHTsvff/heeRWgM1RojT4d16QA9CUQE7UqMFBXvSf8+j3slkG9zmjU64W6Ym+DhJj5qY6Ack4vHJHrujhCWcpEWOR5n6wp6iRpSEpT8RCHq3S0s5X+801/tDaJiC7DpV1KZVVZ8PK8dY5LYmpY8bvBFtYTNa9AlhpZoLTWBFmdyL4DZ8tNLgMYtQB1R4X9NxBNAUUMd70uqd1hOu8oT6mQmjjOyrnp0JERFoLMZVRpUHtdilxE6Yek0kfkNEbXMgtUXlWYmIdmCunQsWViCa8BIf1UzdgAlTpM/3N6GEGZ0dXu5rS2jt07z2BP0l+1m/r0hMrgjW+YRDbaGk46aS2FYNFJFtWj8CwEOCv3e68BeSLhZoETT9VVlmsCOYyQbGorLMnUgWatgv91Q2W4K0JlbRfQRDviAQU4kQNq5t/QNQK+7xa4ouQ5sUoLZdE9cq4mIe+UUDUcdVh9sogpGTxCmjWg1GPwAFCDddj24JQz3J66w= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eU1lMlFNaGVFRjI1STFnTW4zR01kcVRNK1RReEE2QzIrZVlJckI3WExqN01G?= =?utf-8?B?V2VweDZxTkdjenBoc2gyTmFlRzhJQUI0R2U3ckRaQm1jR09DQmc1a0hySHJ2?= =?utf-8?B?VzQrRXp2VTE1cWlPVTNEWVNVUU9uMlR3dlpHZTZZQm52NlFSbEYzejVOZmFz?= =?utf-8?B?cm9pd0I1ejJuMXpuR244NVlhdmFlZndLeFFFemNxR1RWRWJEZTdoTHE0SlVu?= =?utf-8?B?M0xLOHorUGJhTUdKdlU0NjFDays4d2JISXJaeFU1SWZBSVZRZXM4ejNmRXo4?= =?utf-8?B?OHZ6a1ZBdWNhbGU4TURxM2pENmc3ZStkSTYrZGMxT0hKTks5TEtnRkhzU3hW?= =?utf-8?B?K3JybCtZR01mQ2ZTMkk5OUJIYU5DSUZ2UmtOVVlqeGNOZFM0eVFEWk9aU2I2?= =?utf-8?B?Z2tBaXpESnpMVytHY3d3MUpXeXVTamFSRmFOSG5xbVRuNGFmN1BwS216Sk1R?= =?utf-8?B?bGdEUWhVMCs0MHJqcXAyVE1QMzYxZzR6LzBNNlRmSEhGVzYvL3BJOHpjUEdZ?= =?utf-8?B?YmFsbWNrb3dkOElud3Z6bGU0TGxBUUFUNzNqUHJqaFA1azBmRHJNRFBJWFMy?= =?utf-8?B?ZzRlOVFtaExNNktJK0laUlpsUGQ4UkVUY3VUZjJ6QnFKNmw5WURQSEJXb3Yv?= =?utf-8?B?Z1V1SGgwdks4UWlpUmRQVy85Rnd2Mk9iS1lvaTZSeUg4Rk9BT09FeXM1N2p5?= =?utf-8?B?aEgwUVFyWEx1YVR4VCtOVlBaU0ZnQlRQV25tOS90REVydk9TcE9QVnpsZ0sv?= =?utf-8?B?Z1JGdTEvcndMeUplQ2hDN2FHZnYvckR2UEcrcjBCRXdyY09uSXRCTU5JK1B3?= =?utf-8?B?RzdJTDlxdkhXK1U3T1BlUEYyOStDQWJUT1hRaXBlTDNnYndlWklwd0pkRjhF?= =?utf-8?B?bnVPTXhacm80MmZZbXB2NStLcE5STjhpdzYvcUU4UTlVR3N1bWtEM083QWRa?= =?utf-8?B?ZEVRSlc0WkVJTFBwcUxlT01SZFlZRDdQb3pLNU54N3QyUlY0ekhXakpxR1Vw?= =?utf-8?B?MlN0TG1JQ011UXVCSVJVSVk0Z2Q2SFRZOUNrQlk4YXpJdGxJeU1UdVREcEZR?= =?utf-8?B?dCtIbmJCc2cwZ2xjZi9VN1M3NXYrcDk1aTJSU043NFVtUFRleWxHK3N0Z1JT?= =?utf-8?B?Q3JZNmhmSmJ0N3dEdmlLRXdRekdLdGRWczVGSnRqNVcxRWF5ai9pcTZsUDlJ?= =?utf-8?B?SFFtNTBlT21ha3dVa1ZmVkNJUUFFYjVSS3prVUl2TFNzMzFiS2NZVmVXZ1k3?= =?utf-8?B?UHhqRnhSWloyYmZidGw2RDFNNS84aXloSEh2djVpYlRLRjlmc1VzdVVENkRa?= =?utf-8?B?NkVmZjhoS3piM000NkhPenBkcXRWb1R1eGpjaFFHVWNzWVNYMWE0S2ZsT0wy?= =?utf-8?B?QkdZUHRnaUJmR3dBWllIK05RdEhIdE5rN2JMSlhmTzZvNjNOV2FqR0dMMlVm?= =?utf-8?B?Smg5T2hsdWNBQkU1S2ZTSFVuUEkyM04zY3BGS2VkM0lycDFrQmdHNGwxQW9l?= =?utf-8?B?U2VGT20wVGhWbFgrSkxmV2s4VEplZGJRNEJpeVR3UUVYNXNyN1RJZkhhUnhw?= =?utf-8?B?S1FBdmZjSUJDV1FkY2Q5RElOS0ZNREU3bVJYSTEwQzJ2T1ZGb0l2aUtGUG83?= =?utf-8?B?NmdMcEJWcHFkbk5BbVJjenpWWHg4eU56dTBtc3RJZ25MdGt2Q0dCUmdYdWpK?= =?utf-8?B?bENtT09Qc21WTXd5cEFiQjJBSC8xbDVVSWdZVTR0Y0cyNkxMdk05QlhxaEtq?= =?utf-8?B?dHQwdm1VekJlSnZ1aXJzcm9EWjQwWkx5enpzRHorR05mSW81TFFFWjdsanpk?= =?utf-8?B?VDJ6MytFTHJEOUNKYzVGRktVS3dZa3pFbFpJYUhWUnlDOS9md0tabnR0ODFs?= =?utf-8?B?OU1EY0cxbm1YVDVuU0I0STYrRUd1NkI1UTZNdlBrNDA3Rk1HdDVMRnB4UVc1?= =?utf-8?B?REFITENyVm5vWXBrTnlsQWIrUzZCTXg1N0JFREJkVVNVWlc5dnBoTm1lOU12?= =?utf-8?B?SnN4aHZYWW4rVG5CMW1pWnAzMzA4SmpCTytNVDlXRG4rRFR6TUNvdlNvRXFt?= =?utf-8?B?N3lDVnhac0JQaW5nR3puOXBYMC8zVCs2dXdtQ1hXNSs4b0twV0ZqTGRPTmhJ?= =?utf-8?B?NDNRWFJ3L0VYdWxtK3NYQ3c4VWp3UDl3RUo1Y1pLcjNmL2dydHdhOG8yMitz?= =?utf-8?B?bG80aTAyeEEyMlplblBaeUwvTm1vMXk1VUFDMUthMTJ4LzBPU01uMUNIYmxi?= =?utf-8?B?ODRzQVg3djNjTUdxOWdha1dlRTQveWc5RG9pRXlIanMvVVZJZEF0SG95WHBY?= =?utf-8?B?QXgyTmtXeHRLSFZxZ1FjUCtVUnJuMjAvTXFSYU9hNUp2WnpHb21VdnNsNG9T?= =?utf-8?Q?bME6bR2NRG4b6mlc=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 161f2922-103d-4618-be69-08df158b8c90 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 13:48:41.5097 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: xTtLgh5IyyXGglv8L++adRCeOshStmcBPd+HOlOZmCWUl46iRFc6p9LPnqbVoDOtujOFYi2+ilcwVWqHNZCDGjbcZEMxuIA8Ds7rYVaqnjM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB989304 X-purgate-ID: tlsNG-c1860d/1789739325-D755C87B-A84A6015/0/0 X-purgate-type: clean X-purgate-size: 2179 On 7/31/26 3:46 PM, Teddy Astie wrote: > Introduce needs_tlb_flush that indicate that the vCPU related TLB > needs to be flushed before entering this domain. This is intended > to be used later for using the same ASID for all vCPU of a domain. > > Also track vCPU context switch to determine : > - per vcpu "latest_cpu" that tracks which pCPU last ran this vCPU, > this is used to know whether our current TLB (of our pCPU) state > is stale. > Schedule a TLB flush if the vCPU ran on another pCPU previously. > - per pCPU "latest_vcpu" (per domain) that tracks which vCPU the > TLB+ASID/VPID is holding onto. > Schedule a TLB flush if this pCPU hasn't ran this vCPU previously > (which can happen if we context-switch multiples vCPUs of a same > domain on a same pCPU). > > If ASID use is disabled, unconditionnaly perform a TLB flush. > > Signed-off-by: Teddy Astie > --- > v2: Merge several patches into one, move logic to context_switch(), > move fields to arch_vcpu/arch_domain, consider !asid_enabled case. > --- > xen/arch/x86/domain.c | 26 ++++++++++++++++++++++++++ > xen/arch/x86/include/asm/domain.h | 6 ++++++ > 2 files changed, 32 insertions(+) > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index 996b50af7a..27155546ca 100644 > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -874,6 +875,13 @@ int arch_domain_create(struct domain *d, > > spec_ctrl_init_domain(d); > > + rc = -ENOMEM; > + d->arch.latest_vcpu = xvmalloc_array(int, nr_cpu_ids); Does this work with pCPU hotplug or do you need to use NR_CPUS? > + if ( !d->arch.latest_vcpu ) > + goto fail; > + for (unsigned int i = 0; i < nr_cpu_ids; i++) > + d->arch.latest_vcpu[i] = -1; > + The other arches define INVALID_VCPU_ID to be MAX_VIRT_CPUS. Not sure if it is worth doing the same for x86? Ross From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425495.1649419 (Exim 4.92) (envelope-from ) id 1x7ZuW-0004i2-2R; Fri, 18 Sep 2026 14:49:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425495.1649419; Fri, 18 Sep 2026 14:49:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuV-0004hr-VI; Fri, 18 Sep 2026 14:49:55 +0000 Received: by outflank-mailman (input) for mailman id 1425495; Fri, 18 Sep 2026 14:49:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuT-0004gK-Tt for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:49:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7ZuT-009hUR-Ab for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:49:53 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f7a-e002-0a2a0a5209dd-0a2a450c824a-40 for ; Fri, 18 Sep 2026 16:49:53 +0200 Received: from [74.125.230.235] (helo=mail-qk2-f43.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f8e-f479-0a2a450c0019-4a7de6eb9422-3 for ; Fri, 18 Sep 2026 16:49:51 +0200 Received: by mail-qk2-f43.google.com with SMTP id af79cd13be357-93910cc46c7so64988585a.3 for ; Fri, 18 Sep 2026 07:49:51 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93be0e90276sm152288185a.21.2026.09.18.07.49.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742990; x=1790347790; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=n57jpnbqR3xEpFvVL4pj+x/9TynCnpwMD9+qM+zc540=; b=obcMTyDqmBcYTxnvLA82tgwSacvI6i7PRIPfpNn/dXRTTd5CjE4YXV84Dc6p9+yZ4Z 6HFNIl1Xxy4yH/nuxldhwzrWT1ive5gBF28iXyAjvW71eQZm9Msiiv5Kmzc8yjcyW9dB rcsfQUIjd6pw4OA5b0OpuFTWe2Iq9Ns8JxEaOa1YCS01ovKuziiDFORbB+bXTzCUc+Nj MCh5TZ3f/Xxd1I6a+TDF8weKZhbhS4prF149xctCVVmclKjoX/727lClZzHDP/oxyxFg LjYwwttB7+5OYjexn46WIIsqnVFAZkcBXpzzXykknCdHuZhtVZPgvy4jBjyDxwBZNvYd Vplw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742990; x=1790347790; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=n57jpnbqR3xEpFvVL4pj+x/9TynCnpwMD9+qM+zc540=; b=T3EhY/yQ208Ft1BXxWfQP6K2u3zzZ2aRUBRm3kbBlGXwv1JAgsdnr+mq0Ege6cxTg2 feQgPxaxD439795D/WsUCieHAF/LZeYOnjFffg3EmB1E1NGoLK7/HM0k0m3LaN4lNJl2 IhUXeCb3xmUIJPjJ/DgsHyzOMes6SBS3e41YXWBslW7oPgFBFVS/d21KJIQ6/hPZ2i5Z KOd2Kf0XotlRdOyvuZrYww2kxTtaGBmD+CU+mNcsuxUI13NLrw3QGwEbfW0QWPXWbOwy VNbHAW8IjK2Y3+zyHRaWxnT3Keb3F/Qh+68F2A0PAWnN2vuf5qZEnrhWPJZF8/yqQKYX FIAQ== X-Forwarded-Encrypted: i=1; AKwUvBwjNnoTow5U4GJmgeN6lE9zNssHQiyqrhzVlBP7lO8eHsXj//hzh4xf76TSF5gQUmQ9TIW2fwK1FR4=@lists.xenproject.org X-Gm-Message-State: AFuF++mdTSVhkCwx5kSyScjK66T45BvsiXGnjvzXFfevTzDO7b0GCBss hvLZDuI2mbJPz37Jl3Q1NgmQVMswVKNWWwsDTMC2Awk1KV3Nm9gzmQkFOyACPaq2AAU= X-Gm-Gg: AYBFou2NHTz172ie584vk7d+Ll66ez9l8imDIhIM0rwJv9/us5IOkW7RlHD4XDC1v2B A/ifmqG+bTcN2M003weKd6iejqE4BMJVAck3ljZFo0HNKM7wOupHLCevzYh5Yvx77qhI2ZeQYVf Oq0ib7tNLOaU1i3rPfC/N47lWwFdv0EteknVE6fVslY6FF57S/g0iygvO64mYYURdc2ktKrBwsd HL8oIUOFdeGM2rZyXmVkiF7G4AFcd+ezgZSIdgFzjr73CdvoQlq0UC0bQ/gaWtN6GVVImq78OYm BNH2qHG+l762P65t8QsKMro5Xi582BI42yx4i4/83FyK1OnbfS7jReSlD2qkTD4eSh/9JtUZuxd oTyNhdDKSyzzM7aI+K+eTQ6q3J1yKM1kKnLnXC8qpvpczByPhOCy9tlx4HsO8jYc5W0G/eJ4BZz lKN8C6jynvhAUN+v9LePv39qrOAp0DHMwP6aY9ieWn45Dzb/hyCxl8wb/3Si5AYpKjBGkG23qPN vqpfHBtypJtT+3sts1VJk5JxAiFNueQR5v02ehaoMs99YpPHtJ7VJDO X-Received: by 2002:a05:620a:1724:b0:939:365a:49a5 with SMTP id af79cd13be357-93bdc6e5e09mr400777085a.27.1789742989989; Fri, 18 Sep 2026 07:49:49 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:22 +0000 Subject: [PATCH RFC v4 03/13] kprobes: Expose the optprobe jump window to Tasks RCU MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-3-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=7473; i=josef@toxicpanda.com; h=from:subject:message-id; bh=97rXNEsO0S02JFiFJq38moNkWCht7E9TlyxYtLTVeYI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLDPJjh7XcPwoZnncjeIz0ekrFrEehwu9vxSbP/wbLngYBuNUBgEdoEdYmb8mwvrWGuV6QiYW9q iu8TI3m4Kfgo= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d25034/1789742991-50D3CA5B-AAE1A061/0/0 X-purgate-type: clean X-purgate-size: 7475 kprobe_optimizer() is the one synchronize_rcu_tasks() user that is not about trampoline text: it waits for tasks that were interrupted on an instruction boundary inside the bytes it is about to overwrite with the optimized jump, so that none of them resumes into the middle of the new instruction. Those bytes are ordinary kernel or module text with no Tasks Trace reader around them, so on CONFIG_TASKS_RCU_TRAMPOLINE_READERS kernels the irq-exit quiescent-state check has to be told about them. Add kprobe_in_optimized_region(), a lockless and conservative form of get_optimized_kprobe() that reports whether any registered kprobe lies within MAX_OPTIMIZED_LENGTH before the given address regardless of its optimization state, and have rcu_tasks_trampoline_text() consult it for core and module text so that a task interrupted there becomes a holdout rather than a quiescent event. The hash walk only runs while kprobe_optimizer() is actually inside its synchronize_rcu_tasks(), tracked by a flag it sets around the call; otherwise the check is a single load. That check cannot see a task that was already preempted in the region before the flag went up (possibly before the kprobe even existed), and the new grace period does not otherwise wait for a preempted task to run again, so before synchronize_rcu_tasks() the optimizer calls rcu_tasks_wait_irq_preempted() to wait until no parked task's recorded irq-exit preemption IP is inside such a region; its leading synchronize_rcu() also publishes the flag to every (interrupts- disabled) check in flight. The kprobe hash is RCU-protected and every free path waits for a grace period after unhashing, so the lockless walk from the irq-exit path is safe. On other configurations the flag is set and cleared but nothing reads it and rcu_tasks_wait_irq_preempted() is a stub; the classic implementation already waits for such tasks. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/kprobes.h | 8 +++++++- kernel/kprobes.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++ kernel/rcu/tasks.h | 11 ++++++++--- 3 files changed, 65 insertions(+), 4 deletions(-) diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h index e6de7ae55bda..74cc48c04417 100644 --- a/include/linux/kprobes.h +++ b/include/linux/kprobes.h @@ -530,11 +530,17 @@ static inline bool is_kprobe_insn_slot(unsigned long addr) } #endif /* !CONFIG_KPROBES */ -#ifndef CONFIG_OPTPROBES +#ifdef CONFIG_OPTPROBES +bool kprobe_in_optimized_region(unsigned long addr); +#else /* !CONFIG_OPTPROBES */ static inline bool is_kprobe_optinsn_slot(unsigned long addr) { return false; } +static inline bool kprobe_in_optimized_region(unsigned long addr) +{ + return false; +} #endif /* !CONFIG_OPTPROBES */ #ifdef CONFIG_KRETPROBES diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 6337da5cab9e..e460fba83e4a 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -511,6 +511,48 @@ static struct kprobe *get_optimized_kprobe(kprobe_opcode_t *addr) return NULL; } +/* + * True while kprobe_optimizer() is waiting for its Tasks RCU grace period. + * Only in that window can an interruption inside an optprobe's jump region + * matter to it, so kprobe_in_optimized_region() does no work otherwise. + */ +static bool kprobe_optimizer_waiting; + +/** + * kprobe_in_optimized_region - Could @addr be inside bytes a jump-optimized + * kprobe replaces? + * @addr: kernel text address, typically an interrupted instruction pointer + * + * kprobe_optimizer() relies on synchronize_rcu_tasks() to wait for tasks that + * were interrupted on an instruction boundary inside the region about to be + * overwritten by the optimized jump. Where Tasks RCU is built on + * reader-marked trampolines that region has no reader, so the irq-exit + * quiescent-state check asks this instead (see rcu_tasks_trampoline_text()). + * This is the lockless, conservative form of get_optimized_kprobe(): it does + * not care whether the kprobe found is, or ever will be, optimized. May be + * called from any context with preemption disabled; the kprobe hash is + * RCU-protected and every free path waits for a grace period after unhashing. + * + * The hash walk only runs while the optimizer is actually waiting. A task + * that was preempted in such a region before the flag went up is invisible + * to that check, so the optimizer first waits those out by their recorded + * preemption IP (rcu_tasks_wait_irq_preempted(), whose leading + * synchronize_rcu() also publishes the flag to every check in flight). + */ +bool kprobe_in_optimized_region(unsigned long addr) +{ + int i; + + if (!READ_ONCE(kprobe_optimizer_waiting)) + return false; + + for (i = 1; i < MAX_OPTIMIZED_LENGTH / sizeof(kprobe_opcode_t); i++) + if (get_kprobe((kprobe_opcode_t *)addr - i)) + return true; + return false; +} +NOKPROBE_SYMBOL(kprobe_in_optimized_region); + /* Optimization staging list, protected by 'kprobe_mutex' */ static LIST_HEAD(optimizing_list); static LIST_HEAD(unoptimizing_list); @@ -644,8 +686,16 @@ static void kprobe_optimizer(void) * to 2nd-Nth byte of jump instruction. This wait is for avoiding it. * Note that on non-preemptive kernel, this is transparently converted * to synchronoze_sched() to wait for all interrupts to have completed. + * kprobe_optimizer_waiting lets a reader-marked-trampoline Tasks RCU + * recognise tasks interrupted in such a region while we wait, and + * rcu_tasks_wait_irq_preempted() (a no-op elsewhere) first waits + * out any that were preempted there before we said so; see + * kprobe_in_optimized_region(). */ + WRITE_ONCE(kprobe_optimizer_waiting, true); + rcu_tasks_wait_irq_preempted(kprobe_in_optimized_region); synchronize_rcu_tasks(); + WRITE_ONCE(kprobe_optimizer_waiting, false); /* Step 3: Optimize kprobes after quiesence period */ do_optimize_kprobes(); diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index f03be742be48..eb1388dd8a61 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1005,7 +1005,9 @@ bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) * trampolines, kprobe slots and other dynamically allocated text; this * deliberately does not ask is_ftrace_trampoline() and friends, since * text being torn down may already be unregistered there); - * - whatever the architecture adds via arch_rcu_tasks_trampoline_text(). + * - whatever the architecture adds via arch_rcu_tasks_trampoline_text(); + * - the bytes after a kprobe that a pending jump optimization is about to + * overwrite, the one synchronize_rcu_tasks() user with no trampoline. * * A false positive only makes the task a holdout until its next quiescent * event. Called with interrupts disabled from the irq-exit path. @@ -1013,8 +1015,11 @@ bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) bool rcu_tasks_trampoline_text(unsigned long ip) { if (core_kernel_text(ip)) - return arch_rcu_tasks_trampoline_text(ip); - return !is_module_text_address(ip); + return arch_rcu_tasks_trampoline_text(ip) || + kprobe_in_optimized_region(ip); + if (is_module_text_address(ip)) + return kprobe_in_optimized_region(ip); + return true; } NOKPROBE_SYMBOL(rcu_tasks_trampoline_text); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425498.1649446 (Exim 4.92) (envelope-from ) id 1x7ZuZ-0005Nx-1Y; Fri, 18 Sep 2026 14:49:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425498.1649446; Fri, 18 Sep 2026 14:49:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuY-0005Nq-U9; Fri, 18 Sep 2026 14:49:58 +0000 Received: by outflank-mailman (input) for mailman id 1425498; Fri, 18 Sep 2026 14:49:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuX-00057Q-Lt for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:49:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7ZuX-0054h4-2d for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:49:57 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f8b-8faa-0a2a0a5109dd-0a2a450bb8d4-18 for ; Fri, 18 Sep 2026 16:49:57 +0200 Received: from [74.125.230.209] (helo=mail-qk2-f17.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f94-b7e8-0a2a450b0019-4a7de6d1806a-3 for ; Fri, 18 Sep 2026 16:49:56 +0200 Received: by mail-qk2-f17.google.com with SMTP id af79cd13be357-93910ca5aa7so73891185a.1 for ; Fri, 18 Sep 2026 07:49:56 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9125808d8fcsm14099356d6.45.2026.09.18.07.49.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742995; x=1790347795; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=9lDajmUPmaz8BTxhPEk6XaACKGtk0v9RwI05AN+Obys=; b=iu8PZYYhVy56tQ09y3Ij134WzEnOsZy5ohnNPTqGAxeyMYvujJZ8bzzrvtDXnXhrl1 UrsS1mUjG8Wm+h1pfbNMYNDMtXwIoOHvotlrONC/YBSZnrsR7mWom4iOhPiJ8OVSqsjY v3wqM1yhnrnTj9cZ+y2YHwIUWMB5kbFjoSjpTV4n1+Hr/m+hgIgSe4eb017UPDu+x3CG o4ITiCkckYZR0hTmS9wjToy+s53S18N3yk5h/TbBS527Ng39Vv6Q7Yv0IWKn5/PEaQCE fUz9aiuiUQqPMlJgIpi5xA3lTdoHKfjOmJiEyEkotBZYrpmwbxDwXdOoCQROv/+qN1Ws CGnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742995; x=1790347795; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9lDajmUPmaz8BTxhPEk6XaACKGtk0v9RwI05AN+Obys=; b=Ly+HXYxEFUtlRZ43Mxj0qQvsZn2O71B538bUGKUUp22si1Zyve6WJJhj7ci59Lm+Gl Plbr4xNwB0pWqSWN/X7kgvIVlqjvjYUQ6px3Vb6uQRUnZu+s4LYUr9Law0+jUTYjyMg8 hPxegL3npF6r2CdWoW3AJKnO5JkrbfqVTo6FqynWn5W1+Bapl6JCR8uWQZ8JdJu+zVuJ wpasdoSStXVnx+3FtwrxC5WNlTRWtQK2tHxQzgW5+bdGeNV3uGHrJlbP9ApDAxwjnWec ORIR25Zvxxbm6cVIjkZRHYjewFkAxUfD7zBF69VmNwzcY6aHi2oWAYMW8/ZEUCsN9FsX 68JA== X-Forwarded-Encrypted: i=1; AKwUvBwm/wx7AGPZa3nnpTRg0abt4CUZ3P1lViWNGw8x67Ul8II39v5eHvm+a+EcJN55IGItsQ3nTDPJvsQ=@lists.xenproject.org X-Gm-Message-State: AFuF++ksecH852WEL8ntEiQk6mOrw7VlwvgIvxcgXrL5Jx+q+295NrAd pWvFA9vPUcIEjcHEXUV9lWqIUOfXZNefesSDM7szPgBdtAtIPQBcJK0EIUGo1WdRxCM= X-Gm-Gg: AYBFou03a+eZ5ofL4Y1CAsVd7IeKs/MKhSujSQyoGTtZe8+w4R5XrlcbNLLkskYdkCB ePwuU/EYRT9mkg7N8Jltmj6WHvWSc4m/pmFHxTmew3tkDtActpzTSRTygoDfNqTxSgY/OOSoD/P 3O8f1ZRhpKBPHYVXFWIABAzhToxd6fELtj1uOoAjsT9wE4HVzYtUhO62ybPefuKxEV7s+s/VmqM qH9aI4X6eZr6J0HrX8ISaRn1q2SHYFR91lMW4QP1F+VWa6Lj5KbO3ONaN2jLyFLwBR6895uDzc/ 7q5a9zSQFCruB9TWRiSW/22YEwjHbJoI4Jc5D7PiEV5CRflVPD9f+jCbSCLd/PdqsZINi9G+f4X UytoYZWAM9mLlhXZRtfv8JYQfNBWNfOGyB7tcp2Z8DXwSffFMGB6q5xxQvsSeXsL4zhA0sgIdbM AlisOofnMiVU33+VuvH0V/3cvy5+R0nw+0XrlBeRXFEMNgLnSfUMB1D/LxusWtSVJiVpp5WeyGK iRFf6yi0j7yrz9nwot1wkNspWq5MyZv6RsVbfkIXhOqml+xrcUHLtjb X-Received: by 2002:a05:620a:2591:b0:939:3626:558b with SMTP id af79cd13be357-93bdc6e9664mr386099885a.5.1789742995331; Fri, 18 Sep 2026 07:49:55 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:25 +0000 Subject: [PATCH RFC v4 06/13] x86/kprobes: Take a Tasks Trace reader in the optprobe template MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-6-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=3977; i=josef@toxicpanda.com; h=from:subject:message-id; bh=cyOEpv7E+99KbsYBQF12i4qmiz/SB2W5CJ1v6BiG3CI=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QEjEDkoMCTK8/SkEBNPAmAQa/DHNGXCcOq6l1exqCfOV/HOva5SRV+bPucef9uXdDcfTxk/sgpw 4F0zavhp0AA0= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1789742997-A92CC9EA-AB086A2A/0/0 X-purgate-type: clean X-purgate-size: 3979 The jump-optimized kprobe template calls optimized_callback() from a dynamically allocated slot with preemption enabled, and only Tasks RCU keeps that slot alive under a task preempted in the callback. For HAVE_RCU_TRAMPOLINE_READERS that means the template must be a Tasks Trace reader across the call, so open-code rcu_read_lock_trace() and rcu_read_unlock_trace() around it as ftrace_64.S does. The template lives in .rodata and is memcpy()d into each slot without relocation processing, so the references to current_task and rcu_tasks_trace_srcu_struct are absolute (R_X86_64_32S, relocated for KASLR like any other) rather than %rip-relative. %rax and %rcx have already been saved by SAVE_REGS_STRING and are dead after the call. The slot itself is dynamically allocated text, so the instructions before the lock and after the unlock are covered by the irq-exit check. 64-bit only; 32-bit x86 does not take part. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/kernel/kprobes/opt.c | 44 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c index 3f8fea52619f..68a5de6cdabe 100644 --- a/arch/x86/kernel/kprobes/opt.c +++ b/arch/x86/kernel/kprobes/opt.c @@ -31,6 +31,7 @@ #include #include #include +#include #include "common.h" @@ -101,6 +102,47 @@ static void synthesize_set_arg1(kprobe_opcode_t *addr, unsigned long val) *(unsigned long *)addr = val; } +/* + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace() around the call + * to optimized_callback(), see CONFIG_HAVE_RCU_TRAMPOLINE_READERS and the + * equivalent macros in ftrace_64.S. The template is memcpy()d into the slot + * without relocation processing, so memory references must be absolute + * rather than %rip-relative. %rax and %rcx are free at both points. + */ +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB +#define OPTPROBE_TRACE_RCU_MB " lock addl $0, -4(%rsp)\n" +#else +#define OPTPROBE_TRACE_RCU_MB +#endif +#define OPTPROBE_TRACE_RCU_READ_LOCK \ + " movq %gs:current_task, %rcx\n" \ + " movl " __stringify(TASK_trc_reader_nesting) "(%rcx), %eax\n" \ + " incl " __stringify(TASK_trc_reader_nesting) "(%rcx)\n" \ + " testl %eax, %eax\n" \ + " jnz 1f\n" \ + " movq rcu_tasks_trace_srcu_struct+" __stringify(SRCU_srcu_ctrp) ", %rax\n" \ + " incq %gs:" __stringify(SRCU_CTR_srcu_locks) "(%rax)\n" \ + " movq %rax, " __stringify(TASK_trc_reader_scp) "(%rcx)\n" \ + OPTPROBE_TRACE_RCU_MB \ + "1:\n" +#define OPTPROBE_TRACE_RCU_READ_UNLOCK \ + " movq %gs:current_task, %rcx\n" \ + " movl " __stringify(TASK_trc_reader_nesting) "(%rcx), %eax\n" \ + " subl $1, %eax\n" \ + " jnz 2f\n" \ + " movq " __stringify(TASK_trc_reader_scp) "(%rcx), %rax\n" \ + " movl $0, " __stringify(TASK_trc_reader_nesting) "(%rcx)\n" \ + OPTPROBE_TRACE_RCU_MB \ + " incq %gs:" __stringify(SRCU_CTR_srcu_unlocks) "(%rax)\n" \ + " jmp 3f\n" \ + "2: movl %eax, " __stringify(TASK_trc_reader_nesting) "(%rcx)\n" \ + "3:\n" +#else +#define OPTPROBE_TRACE_RCU_READ_LOCK +#define OPTPROBE_TRACE_RCU_READ_UNLOCK +#endif + asm ( ".pushsection .rodata\n" ".global optprobe_template_entry\n" @@ -114,6 +156,7 @@ asm ( "optprobe_template_clac:\n" ASM_NOP3 SAVE_REGS_STRING + OPTPROBE_TRACE_RCU_READ_LOCK " movq %rsp, %rsi\n" ".global optprobe_template_val\n" "optprobe_template_val:\n" @@ -122,6 +165,7 @@ asm ( ".global optprobe_template_call\n" "optprobe_template_call:\n" ASM_NOP5 + OPTPROBE_TRACE_RCU_READ_UNLOCK /* Copy 'regs->flags' into 'regs->ss'. */ " movq 18*8(%rsp), %rdx\n" " movq %rdx, 20*8(%rsp)\n" -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425494.1649411 (Exim 4.92) (envelope-from ) id 1x7ZuS-0004Tl-NY; Fri, 18 Sep 2026 14:49:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425494.1649411; Fri, 18 Sep 2026 14:49:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuS-0004TK-Jw; Fri, 18 Sep 2026 14:49:52 +0000 Received: by outflank-mailman (input) for mailman id 1425494; Fri, 18 Sep 2026 14:49:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuQ-0004Jj-PW for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:49:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7ZuQ-005x6C-6B for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:49:50 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f8b-8faa-0a2a0a5109dd-0a2a450bb8d4-6 for ; Fri, 18 Sep 2026 16:49:50 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f8c-b7e8-0a2a450b0019-4a7de68cdb8a-3 for ; Fri, 18 Sep 2026 16:49:49 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-90cdfe57a3aso8181896d6.2 for ; Fri, 18 Sep 2026 07:49:49 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9125800e368sm14410356d6.8.2026.09.18.07.49.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742988; x=1790347788; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=myll629Qfz4YrwGmTVALnxB11mMoUz/LpucXoYBTMJw=; b=EjZgc89KV7RMXxLJneS+v2ivNOFtQy5l0Vl/J2uwPGqbtaSCQtVrPQSNxPD6b581Fb m1s79hnTEfDZ8koj6V+T9DtPD1brRdNs//rZkkpZG1Xv/7ZzeiNjfPBrHSBc70r4q4Yb 7/GgSIHq7iu2s2BGlJ/pPuO+mouhI/E1hD+nYGw9VdjLeaPZ//u4ZS5U5I6agWAoodph 39j6ta5timG81LXRrNYOiZqhdL4uMp903XdNYnNU/dyLj+hV7E587c4hIRynEnu34tiq y59kmqxZDqrlNQr7Cl/NPbb4eMkvEr2IGvNzHB4uQxz3x2rzvuMYOYTFUXeQ4vjoSZ3x 4GbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742988; x=1790347788; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=myll629Qfz4YrwGmTVALnxB11mMoUz/LpucXoYBTMJw=; b=KMJx5YjTKl7nGHItOjNdIHa/i7xGMV9zRLYSsQ64vU0kLHFHseMhWoLxjZlIUAicB9 wwcke6/ODYjCuKI6rs5T6nUSBJNukh3E9cGLoZSgQySHhNSFcOET+kBnfF10Y0g23mkL TdJV+5E94LKYS+QR1PGhKlu1BQVDgpb00zPh/y2APdg5MjNEleF73t6wZz3tyEOpnY5t f0wNHOqOiI/aDOcsFBQP+a+zI7NHRkG7mD4TrX9DV4dh8e7/YPN7yJveto4B9kr+wQn+ aIwHYE5PCIvn8H4PfJGNftY85E51MKDRX01CU3zlaPLnlIdBL/b/X91dSsAkql4uvUSj yEHQ== X-Forwarded-Encrypted: i=1; AKwUvBy0gcWehFyNpg8g0RSlGVplGp2fL1i6/k9kznw06/3btdqgjGa1KOYdZtog9bukvSfGdk6b6bRqX58=@lists.xenproject.org X-Gm-Message-State: AFuF++lv3PyoIarWx/QP2XR9uaci7ccsax1Gbv6vIsgPbKPoGgOqLQi+ eBJoJR+Vq0O5sztExy/pv5YMhaJmlmpaelvfMJdqjbLFRD+kdWdy0SFapAbM/4pLqwA= X-Gm-Gg: AYBFou2I5YdF2Z7apKvQJIpnlHWiFInQ3a8Dg5OGnvt570icXAed0I//ep8txx6gRBa OCbvgaV+ZtJWYvdpvfh9+AM1M06D9QGscvx5/kC76BgzrwJTqYfxY0vOhNzsMBBr27xakCvB6ZD e12c0CKv0J5LgwrGOcO3n7b0P7iJkbu4r7QMi8caHGPNDUitO2W97culyYx6WBv7LcLF2kN9lVV FijHGoK05CWQq2QRYB4yxTDoWdwrUI5bVVL1nFfpeo4YvcaypLqf40zrC0VLr71eD5F7xE+qus7 gWITRiZ6moS+4QV+u3R2gmN8IRff2Y/MRf5bxk4fu9gzKrGuK+fJroOatGLgUy5bgHjCLwLn3VB AeoyzZFKFtHq82tMISaIr1u72BCbHunxvOLopIs8RPn0VDb+an65bsUNv0aTix5xTmEgZP+ycS6 ggGeuprWuEHqaROh8SW98956WhIo7aJzEK56CdSc1opZtu6HaCQQON/UUNgcXF2uo1KvfFyKccH mpcpjEzoUwqb6f1Ij3U5+aiS9myZf+JrMlaNAqlEBQcYGNDtQEH8F+xULY9A9tZSxI= X-Received: by 2002:a05:620a:2983:b0:93b:d7a3:45d3 with SMTP id af79cd13be357-93bdc8b6a27mr357058685a.60.1789742988018; Fri, 18 Sep 2026 07:49:48 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:21 +0000 Subject: [PATCH RFC v4 02/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-2-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742979; l=31523; i=josef@toxicpanda.com; h=from:subject:message-id; bh=qhXNBlJJp01Ei07kqFZDAUfEsCu0gSp6eIBNqqgCukM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QKxRe2CaBiEe6pLgkvnyEKMb+x/jOl++z2W4Kx5A0gKz1iBWZzIljfaAJXHRJiKTIhXpTun61uP /1AaTpYl8kwI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1789742990-AB0DD9EA-432FAF65/0/0 X-purgate-type: clean X-purgate-size: 31525 Tasks RCU waits for every task to pass through a voluntary context switch, usermode or idle, because a preempted task might be sitting in a trampoline that is about to be freed and nothing marks it as such. With PREEMPT_LAZY that is a poor fit for servers: cond_resched() is a no-op, so a CPU-bound kthread only ever leaves the CPU by preemption, and one such kthread holds every synchronize_rcu_tasks() caller -- ftrace and BPF trampoline teardown under their mutexes, the kprobe jump optimizer under text_mutex and cpus_read_lock() -- hostage for as long as it runs. Following the discussion on v2, take the other road: let the architecture make its trampolines Tasks Trace RCU readers. When an architecture selects HAVE_RCU_TRAMPOLINE_READERS it promises that every trampoline whose lifetime Tasks RCU guards enters rcu_read_lock_trace() (or its assembly equivalent) before calling out and leaves it before returning, so a task anywhere inside such a call-out, preempted or not, is an ordinary Tasks Trace reader. That leaves the few instructions of trampoline text before the reader is entered and after it is left (plus, in a later patch, the bytes a kprobe jump optimization is about to overwrite). A task can only linger there by being interrupted there, and such text never calls anything that schedules, so instead of tracking tasks we track CPUs: every pass through __schedule() is a per-CPU quiescent event, except that the one context switch that can catch a task at an arbitrary instruction -- a preemption from irq exit -- first records the interrupted IP in the task and parks it on a per-CPU list for the duration (reusing the fields and lists the classic flavor keeps for its exit-path bookkeeping), and, if the IP is inside such "unmarked" text, puts the task on a short holdout list; the task takes itself off at its next context switch outside such a preemption or irq-exit check that finds it elsewhere. Usermode (the existing tick hook, or a nohz_full CPU in an RCU extended quiescent state) and idle count as well. rcu_tasks_trampoline_text() does the classification: anything outside core and module text, plus an arch hook for things like static ftrace stubs and return thunks. The grace period, run by the existing rcu_tasks kthread so that call_rcu_tasks(), synchronize_rcu_tasks() and rcu_barrier_tasks() keep their names and callers, is: wait for every online CPU to context switch or be seen in an RCU extended quiescent state (nudging stragglers with resched_cpu() after a jiffy), drain the holdout list as it stood, synchronize_rcu_tasks_trace() for everything inside the readers, then one more CPU pass and drain for tasks that have since left the reader into the trailing instructions. That is bounded by a few jiffies, preempt-off latency and an SRCU grace period rather than by the longest stretch any task runs without sleeping, needs no per-task scan, and makes cond_resched_tasks_rcu_qs() unnecessary on such architectures. Unlike the classic flavor it also waits for an idle task caught in a trampoline, since an idle CPU only counts while RCU is not watching it. rcu_tasks_wait_irq_preempted() walks the parked lists for the one caller (the kprobe jump optimizer, later in the series) that makes ordinary text unsafe to be parked in and so has to wait out tasks that were preempted there before it said so. The classic implementation is untouched and remains the default; the new one is built only as CONFIG_TASKS_RCU_TRAMPOLINE_READERS when the architecture opts in and uses the generic irq entry code, whose reschedule check gains the rcu_tasks_irq_resched() call. Nothing selects it yet. Suggested-by: Paul E. McKenney Suggested-by: Alexei Starovoitov Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/rcupdate.h | 24 ++- include/linux/sched.h | 1 + kernel/entry/common.c | 8 +- kernel/fork.c | 1 + kernel/rcu/Kconfig | 22 +++ kernel/rcu/tasks.h | 459 ++++++++++++++++++++++++++++++++++++++++++++++- kernel/rcu/update.c | 2 + 7 files changed, 508 insertions(+), 9 deletions(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 44c07a66edff..79e4b14f83b9 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -50,6 +50,23 @@ token_context_lock_instance(RCU, RCU_BH); /* Exported common interfaces */ void call_rcu(struct rcu_head *head, rcu_callback_t func); void rcu_barrier_tasks(void); + +/* + * Trampoline-reader Tasks RCU (CONFIG_TASKS_RCU_TRAMPOLINE_READERS), see + * kernel/rcu/tasks.h. rcu_tasks_irq_resched_enter()/_exit() bracket the + * irq-exit preemption; rcu_tasks_trampoline_text() and the arch_ override + * classify an interrupted IP; rcu_tasks_wait_irq_preempted() lets a caller + * wait out tasks already preempted somewhere it is about to make unsafe. + */ +void rcu_tasks_irq_resched_enter(unsigned long ip); +void rcu_tasks_irq_resched_exit(void); +bool rcu_tasks_trampoline_text(unsigned long ip); +bool arch_rcu_tasks_trampoline_text(unsigned long ip); +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)); +#else +static inline void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)) { } +#endif void synchronize_rcu(void); /* @@ -180,11 +197,16 @@ static inline void rcu_nocb_flush_deferred_wakeup(void) { } #ifdef CONFIG_TASKS_RCU_GENERIC # ifdef CONFIG_TASKS_RCU -# define rcu_tasks_classic_qs(t, preempt) \ +# ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +void rcu_tasks_note_qs(struct task_struct *t, bool preempt); +# define rcu_tasks_classic_qs(t, preempt) rcu_tasks_note_qs((t), (preempt)) +# else +# define rcu_tasks_classic_qs(t, preempt) \ do { \ if (!(preempt) && READ_ONCE((t)->rcu_tasks_holdout)) \ WRITE_ONCE((t)->rcu_tasks_holdout, false); \ } while (0) +# endif void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func); void synchronize_rcu_tasks(void); void rcu_tasks_torture_stats_print(char *tt, char *tf); diff --git a/include/linux/sched.h b/include/linux/sched.h index 8b3d47a325cc..15beb44caa2c 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -957,6 +957,7 @@ struct task_struct { u8 rcu_tasks_holdout; u8 rcu_tasks_idx; int rcu_tasks_idle_cpu; + unsigned long rcu_tasks_irq_ip; struct list_head rcu_tasks_holdout_list; int rcu_tasks_exit_cpu; struct list_head rcu_tasks_exit_list; diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e4acd50bd81a..94318519998c 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include @@ -141,8 +142,13 @@ void raw_irqentry_exit_cond_resched(struct pt_regs *regs) rcu_irq_exit_check_preempt(); if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) WARN_ON_ONCE(!on_thread_stack()); - if (need_resched() && arch_irqentry_exit_need_resched()) + if (need_resched() && arch_irqentry_exit_need_resched()) { + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_tasks_irq_resched_enter(instruction_pointer(regs)); preempt_schedule_irq(); + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_tasks_irq_resched_exit(); + } } } #ifdef CONFIG_PREEMPT_DYNAMIC diff --git a/kernel/fork.c b/kernel/fork.c index 416758c8a3d4..8077336bb136 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1871,6 +1871,7 @@ static inline void rcu_copy_process(struct task_struct *p) p->rcu_tasks_holdout = false; INIT_LIST_HEAD(&p->rcu_tasks_holdout_list); p->rcu_tasks_idle_cpu = -1; + p->rcu_tasks_irq_ip = 0; INIT_LIST_HEAD(&p->rcu_tasks_exit_list); #endif /* #ifdef CONFIG_TASKS_RCU */ #ifdef CONFIG_TASKS_TRACE_RCU diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index 332df7a7a634..bbab14bc14c3 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -107,6 +107,28 @@ config TASKS_RCU default NEED_TASKS_RCU && PREEMPTION select IRQ_WORK +config HAVE_RCU_TRAMPOLINE_READERS + bool + help + Select this if the architecture uses the generic irq entry code and + every trampoline whose lifetime Tasks RCU guards on it (ftrace + trampolines, kprobe out-of-line and optimized-probe slots, BPF + trampolines, out-of-line ftrace direct-call trampolines) enters a + Tasks Trace RCU read-side critical section before calling out of + the trampoline and leaves it before returning, and any core text + that runs on behalf of such a trampoline outside that reader is + reported by arch_rcu_tasks_trampoline_text(). The assembly readers + use the this_cpu_inc() form of SRCU-fast, hence !NEED_SRCU_NMI_SAFE. + +config TASKS_RCU_TRAMPOLINE_READERS + def_bool TASKS_RCU && HAVE_RCU_TRAMPOLINE_READERS && GENERIC_IRQ_ENTRY && !NEED_SRCU_NMI_SAFE + select TASKS_TRACE_RCU + help + Implement the Tasks RCU grace period as a per-CPU pass over + context switches and irq-exit reschedules outside trampoline text + plus a Tasks Trace RCU grace period, instead of waiting for every + task to voluntarily context switch. See kernel/rcu/tasks.h. + config FORCE_TASKS_RUDE_RCU bool "Force selection of Tasks Rude RCU" depends on RCU_EXPERT diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 627295396cd9..f03be742be48 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -152,7 +152,7 @@ static struct rcu_tasks rt_name = \ .kname = #rt_name, \ } -#ifdef CONFIG_TASKS_RCU +#if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) /* Report delay of scan exiting tasklist in rcu_tasks_postscan(). */ static void tasks_rcu_exit_stall(struct timer_list *unused); @@ -802,7 +802,7 @@ static void rcu_tasks_torture_stats_print_generic(struct rcu_tasks *rtp, char *t #endif // #ifndef CONFIG_TINY_RCU -#if defined(CONFIG_TASKS_RCU) +#if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) //////////////////////////////////////////////////////////////////////// // @@ -897,10 +897,444 @@ static void rcu_tasks_wait_gp(struct rcu_tasks *rtp) rtp->postgp_func(rtp); } -#endif /* #if defined(CONFIG_TASKS_RCU) */ +#endif /* #if defined(CONFIG_TASKS_RCU) && !defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) */ #ifdef CONFIG_TASKS_RCU +static int rcu_tasks_lazy_ms = -1; +module_param(rcu_tasks_lazy_ms, int, 0444); + +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + +//////////////////////////////////////////////////////////////////////// +// +// Tasks RCU for architectures whose trampolines are Tasks Trace RCU +// readers (CONFIG_HAVE_RCU_TRAMPOLINE_READERS). +// +// On these architectures every piece of text whose lifetime Tasks RCU +// guards -- ftrace trampolines, kprobe optinsn slots, BPF trampoline +// images, out-of-line ftrace direct-call trampolines -- enters a Tasks +// Trace RCU read-side critical section before calling out of itself and +// leaves it before returning, so a task anywhere inside such a call-out, +// preempted or not, is an ordinary rcu_read_lock_trace() reader and +// synchronize_rcu_tasks_trace() waits for it. +// +// What that cannot cover is the handful of instructions in the trampoline +// before the reader is entered and after it is left, and the one user that +// has no trampoline at all: the bytes after a kprobe that the jump +// optimizer is about to overwrite. A task can only linger in such +// "unmarked" text by being interrupted there; unmarked text never calls +// anything that could schedule. So a context switch on a CPU tells us that +// whatever that CPU was running is out of unmarked text, with one +// exception: a preemption from the irq-exit path, which can happen at any +// instruction boundary. That path has the interrupted pt_regs in hand, so +// just before it preempts it records the IP in the task and checks it +// (rcu_tasks_trampoline_text()); if it is inside unmarked text the task +// goes on a short holdout list first, and takes itself off again at its +// next context switch outside such a preemption or its next irq-exit +// check that finds it elsewhere. With that, every pass through +// __schedule() is a per-CPU quiescent event, as are usermode and idle. +// +// A grace period is then: +// +// 1. Wait for every online CPU to context switch or be found in an RCU +// extended quiescent state (deep idle, nohz_full userspace), nudging +// stragglers with resched_cpu(). Afterwards no task is in the leading +// unmarked instructions of a dying trampoline unless it is on the +// holdout list. +// 2. Wait for the holdout list (as it stood) to drain. +// 3. synchronize_rcu_tasks_trace(), for everything inside the readers. +// 4. Repeat 1 and 2 for tasks that have since left the reader and are in +// the trailing unmarked instructions. +// +// which is bounded by a few jiffies plus preempt-off latency plus an SRCU +// grace period, independent of how long any task runs without sleeping. +// Unlike the classic implementation this does wait for an idle task caught +// in a trampoline, since an idle CPU only counts while RCU is not watching +// it. + +static void rcu_tasks_tramp_wait_gp(struct rcu_tasks *rtp); +void call_rcu_tasks(struct rcu_head *rhp, rcu_callback_t func); +DEFINE_RCU_TASKS(rcu_tasks, rcu_tasks_tramp_wait_gp, call_rcu_tasks, "RCU Tasks"); + +/* Per-CPU count of Tasks RCU quiescent events, and the GP kthread's snapshot. */ +static DEFINE_PER_CPU(unsigned long, rcu_tasks_qs_seq); +static DEFINE_PER_CPU(unsigned long, rcu_tasks_qs_snap); + +/* + * Tasks currently switched out by an irq-exit preemption are kept, with the + * interrupted IP, on the per-CPU rtp_exit_list of the CPU that preempted them + * (reusing the list, lock and task_struct fields the classic flavor uses for + * its exit-path bookkeeping, which this flavor does not need), so that + * rcu_tasks_wait_irq_preempted() can find them without a tasklist scan and + * regardless of where they are in exit. + */ + +/* Tasks last seen preempted inside unmarked trampoline text. */ +static LIST_HEAD(rcu_tasks_tramp_holdouts); +static DEFINE_RAW_SPINLOCK(rcu_tasks_tramp_lock); + +/* CPUs / holdouts the current grace period is still waiting for. */ +static struct cpumask rcu_tasks_pending_cpus; +static LIST_HEAD(rcu_tasks_gp_holdouts); + +/** + * arch_rcu_tasks_trampoline_text - Does the architecture treat @ip as unmarked trampoline text? + * @ip: kernel text address inside core kernel text + * + * See rcu_tasks_trampoline_text(). Architectures override this to flag + * core text that runs on behalf of a trampoline outside its Tasks Trace + * reader, e.g. static ftrace entry stubs or return thunks that hold a + * trampoline address they are about to jump to. + */ +bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) +{ + return false; +} + +/** + * rcu_tasks_trampoline_text - Is @ip in text Tasks RCU protects but no reader marks? + * @ip: an interrupted instruction pointer + * + * True when a task interrupted at @ip may be executing, or about to enter + * or return into, text whose lifetime depends on synchronize_rcu_tasks() + * without being inside the Tasks Trace reader that text takes around its + * call-outs: + * + * - anything outside core kernel and module text (ftrace and BPF + * trampolines, kprobe slots and other dynamically allocated text; this + * deliberately does not ask is_ftrace_trampoline() and friends, since + * text being torn down may already be unregistered there); + * - whatever the architecture adds via arch_rcu_tasks_trampoline_text(). + * + * A false positive only makes the task a holdout until its next quiescent + * event. Called with interrupts disabled from the irq-exit path. + */ +bool rcu_tasks_trampoline_text(unsigned long ip) +{ + if (core_kernel_text(ip)) + return arch_rcu_tasks_trampoline_text(ip); + return !is_module_text_address(ip); +} +NOKPROBE_SYMBOL(rcu_tasks_trampoline_text); + +/* Note a Tasks RCU quiescent event on this CPU. */ +static void rcu_tasks_qs_event(void) +{ + unsigned long *seq; + + guard(preempt_notrace)(); + seq = this_cpu_ptr(&rcu_tasks_qs_seq); + /* Order a preceding rcu_tasks_tramp_hold() before the count. */ + smp_store_release(seq, *seq + 1); +} + +static void rcu_tasks_tramp_hold(struct task_struct *t) +{ + unsigned long flags; + + if (t->rcu_tasks_holdout) + return; + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); + list_add_tail(&t->rcu_tasks_holdout_list, &rcu_tasks_tramp_holdouts); + WRITE_ONCE(t->rcu_tasks_holdout, true); + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); +} + +static void rcu_tasks_tramp_release(struct task_struct *t) +{ + unsigned long flags; + + if (likely(!t->rcu_tasks_holdout)) + return; + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); + list_del_init(&t->rcu_tasks_holdout_list); + WRITE_ONCE(t->rcu_tasks_holdout, false); + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); +} + +/** + * rcu_tasks_irq_resched_enter - Tasks RCU hook for the irq-exit reschedule check + * @ip: instruction pointer of the interrupted (task-level) context + * + * Called with interrupts disabled when an interrupt returning to kernel + * mode is about to preempt_schedule_irq(), the one context switch that can + * catch a task inside unmarked trampoline text. Record where the task is + * parked for as long as it is (rcu_tasks_wait_irq_preempted() looks at + * that), and if it is inside such text make it a holdout before + * __schedule() reports the quiescent event; if it is not, this is as good + * as a voluntary switch for ending an earlier hold. + */ +void rcu_tasks_irq_resched_enter(unsigned long ip) +{ + struct task_struct *t = current; + struct rcu_tasks_percpu *rtpcp = this_cpu_ptr(rcu_tasks.rtpcpu); + + lockdep_assert_irqs_disabled(); + WRITE_ONCE(t->rcu_tasks_irq_ip, ip); + t->rcu_tasks_exit_cpu = smp_processor_id(); + raw_spin_lock_rcu_node(rtpcp); + list_add(&t->rcu_tasks_exit_list, &rtpcp->rtp_exit_list); + raw_spin_unlock_rcu_node(rtpcp); + + if (unlikely(rcu_tasks_trampoline_text(ip))) + rcu_tasks_tramp_hold(t); + else + rcu_tasks_tramp_release(t); +} +NOKPROBE_SYMBOL(rcu_tasks_irq_resched_enter); + +/** + * rcu_tasks_irq_resched_exit - preempt_schedule_irq() has returned + * + * The task is running again (possibly elsewhere) and about to return to the + * interrupted context; it is no longer parked anywhere. + */ +void rcu_tasks_irq_resched_exit(void) +{ + struct task_struct *t = current; + struct rcu_tasks_percpu *rtpcp = per_cpu_ptr(rcu_tasks.rtpcpu, t->rcu_tasks_exit_cpu); + + lockdep_assert_irqs_disabled(); + raw_spin_lock_rcu_node(rtpcp); + list_del_init(&t->rcu_tasks_exit_list); + raw_spin_unlock_rcu_node(rtpcp); + WRITE_ONCE(t->rcu_tasks_irq_ip, 0); +} +NOKPROBE_SYMBOL(rcu_tasks_irq_resched_exit); + +/** + * rcu_tasks_note_qs - Tasks RCU hook for a context switch or explicit QS + * @t: current + * @preempt: this is a preemption rather than a voluntary switch + * + * Every pass through __schedule() (and cond_resched_tasks_rcu_qs(), and a + * tick from userspace or idle) is a quiescent event for this CPU: unmarked + * trampoline text never calls anything that schedules, and the irq-exit + * path has already made @t a holdout if it is preempting inside such text. + * Any of these outside an irq-exit preemption also shows @t itself to be + * outside, ending an earlier hold -- including cond_resched() under + * PREEMPT_DYNAMIC's none/voluntary modes, where the irq-exit path is off. + */ +void rcu_tasks_note_qs(struct task_struct *t, bool preempt) +{ + WARN_ON_ONCE(t != current); + if (!READ_ONCE(t->rcu_tasks_irq_ip)) + rcu_tasks_tramp_release(t); + rcu_tasks_qs_event(); +} +EXPORT_SYMBOL_GPL(rcu_tasks_note_qs); /* cond_resched_tasks_rcu_qs() */ + +/** + * rcu_tasks_wait_irq_preempted - wait for tasks irq-preempted inside @inside + * @inside: predicate on a task's recorded irq-exit preemption IP + * + * For a caller about to make some ordinary text unsafe to be parked in + * (the kprobe jump optimizer): once the caller has arranged for + * rcu_tasks_trampoline_text() to cover that text, new irq-exit preemptions + * there become holdouts, but a task preempted there earlier is invisible + * to the grace period. Wait until no parked task's recorded preemption IP + * is inside; a following synchronize_rcu_tasks() then covers the rest. + * The leading synchronize_rcu() orders the caller's arrangement against + * preemptions in flight, which run with interrupts disabled. + */ +void rcu_tasks_wait_irq_preempted(bool (*inside)(unsigned long ip)) +{ + struct task_struct *t; + unsigned long flags; + int cpu, kick; + bool found; + + synchronize_rcu(); + for (;;) { + found = false; + for_each_possible_cpu(cpu) { + struct rcu_tasks_percpu *rtpcp = per_cpu_ptr(rcu_tasks.rtpcpu, cpu); + + kick = -1; + raw_spin_lock_irqsave_rcu_node(rtpcp, flags); + list_for_each_entry(t, &rtpcp->rtp_exit_list, rcu_tasks_exit_list) { + if (inside(READ_ONCE(t->rcu_tasks_irq_ip))) { + found = true; + if (task_curr(t)) + kick = task_cpu(t); + } + } + raw_spin_unlock_irqrestore_rcu_node(rtpcp, flags); + if (kick >= 0) + resched_cpu(kick); + } + if (!found) + return; + schedule_timeout_uninterruptible(1); + } +} + +/* Has @cpu passed a quiescent event since the snapshot, or need it not? */ +static bool rcu_tasks_cpu_quiescent(int cpu) +{ + if (!cpu_online(cpu)) + return true; + /* Pairs with the release in rcu_tasks_qs_event(). */ + if (smp_load_acquire(per_cpu_ptr(&rcu_tasks_qs_seq, cpu)) != + per_cpu(rcu_tasks_qs_snap, cpu)) + return true; + /* + * Idle or nohz_full userspace in an RCU extended quiescent state: no + * task-level kernel frames can be live in a trampoline there, and + * whatever ran before has switched out. An idle CPU that RCU is + * watching (an interrupt from idle, or the traceable part of the idle + * loop) is deliberately not let through: the idle task may be in a + * trampoline with that interrupt on top, and since it is never + * preempted from irq exit nothing else would catch it. It gets the + * resched_cpu() like anyone else and counts once the idle loop itself + * schedules, which it cannot do from inside a trampoline. + */ + return !(ct_rcu_watching_cpu(cpu) & CT_RCU_WATCHING); +} + +/* Rate-limited stall report; returns true if the caller should add detail. */ +static bool rcu_tasks_tramp_stall(struct rcu_tasks *rtp, unsigned long *lastreport, + const char *what) +{ + int rtst = READ_ONCE(rcu_task_stall_timeout); + + if (rtst <= 0 || !time_after(jiffies, *lastreport + rtst)) + return false; + *lastreport = jiffies; + pr_err("INFO: %s: %s, grace period %lu is %lu jiffies old\n", rtp->kname, + what, rcu_seq_current(&rtp->tasks_gp_seq), jiffies - rtp->gp_start); + return true; +} + +/* + * Steps 1/4: wait until every online CPU has context switched or is in an + * RCU extended quiescent state. A CPU that has neither after a jiffy is + * asked to switch with resched_cpu(), which takes it through + * rcu_tasks_irq_resched_enter() and __schedule() (or, from userspace, a + * guest or the idle loop, straight to __schedule()). + */ +static void rcu_tasks_tramp_wait_cpus(struct rcu_tasks *rtp, unsigned long *lastreport) +{ + struct cpumask *pending = &rcu_tasks_pending_cpus; + unsigned long start; + int cpu; + + /* + * The quiescent events run with preemption (in practice interrupts) + * disabled, so after this any event we go on to count began after the + * caller's updates -- the unpublished trampoline, and whatever + * rcu_tasks_trampoline_text() consults -- were visible to it. + */ + synchronize_rcu(); + + start = jiffies; + for_each_online_cpu(cpu) { + per_cpu(rcu_tasks_qs_snap, cpu) = READ_ONCE(per_cpu(rcu_tasks_qs_seq, cpu)); + __cpumask_set_cpu(cpu, pending); + } + /* Snapshots before the checks below; pairs with rcu_tasks_qs_event(). */ + smp_mb(); + + for (;;) { + for_each_cpu(cpu, pending) + if (rcu_tasks_cpu_quiescent(cpu)) + __cpumask_clear_cpu(cpu, pending); + if (cpumask_empty(pending)) + break; + if (time_after(jiffies, start)) { + for_each_cpu(cpu, pending) + resched_cpu(cpu); + rtp->n_ipis += cpumask_weight(pending); + } + schedule_timeout_idle(1); + if (rcu_tasks_tramp_stall(rtp, lastreport, "CPUs without a quiescent event")) + pr_err("\tCPUs: %*pbl\n", cpumask_pr_args(pending)); + } +} + +/* + * Steps 2/4: wait for the tasks that were holdouts when we looked to stop + * being holdouts. They are moved to a private list so that tasks becoming + * holdouts later (in live trampolines) cannot keep us here; each removes + * itself via rcu_tasks_tramp_release() wherever it is queued. + */ +static void rcu_tasks_tramp_wait_holdouts(struct rcu_tasks *rtp, unsigned long *lastreport) +{ + struct task_struct *t; + unsigned long flags; + int cpu; + + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); + list_splice_tail_init(&rcu_tasks_tramp_holdouts, &rcu_tasks_gp_holdouts); + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); + + for (;;) { + struct cpumask *kick = &rcu_tasks_pending_cpus; + struct task_struct *show[8]; + int nshow = 0, i; + bool empty, report; + + report = rcu_tasks_tramp_stall(rtp, lastreport, + "tasks preempted in trampoline text"); + cpumask_clear(kick); + raw_spin_lock_irqsave(&rcu_tasks_tramp_lock, flags); + empty = list_empty(&rcu_tasks_gp_holdouts); + list_for_each_entry(t, &rcu_tasks_gp_holdouts, rcu_tasks_holdout_list) { + if (task_curr(t)) + __cpumask_set_cpu(task_cpu(t), kick); + if (report && nshow < ARRAY_SIZE(show)) + show[nshow++] = get_task_struct(t); + } + raw_spin_unlock_irqrestore(&rcu_tasks_tramp_lock, flags); + /* Never printk under the lock the irq-exit path takes. */ + for (i = 0; i < nshow; i++) { + sched_show_task(show[i]); + put_task_struct(show[i]); + } + if (empty) + break; + for_each_cpu(cpu, kick) + resched_cpu(cpu); + rtp->n_ipis += cpumask_weight(kick); + schedule_timeout_idle(1); + } +} + +/* Wait for one trampoline-reader Tasks RCU grace period. */ +static void rcu_tasks_tramp_wait_gp(struct rcu_tasks *rtp) +{ + unsigned long lastreport = jiffies; + + set_tasks_gp_state(rtp, RTGS_WAIT_SCAN_HOLDOUTS); + rcu_tasks_tramp_wait_cpus(rtp, &lastreport); + rcu_tasks_tramp_wait_holdouts(rtp, &lastreport); + + set_tasks_gp_state(rtp, RTGS_WAIT_READERS); + synchronize_rcu_tasks_trace(); + + set_tasks_gp_state(rtp, RTGS_SCAN_HOLDOUTS); + rcu_tasks_tramp_wait_cpus(rtp, &lastreport); + rcu_tasks_tramp_wait_holdouts(rtp, &lastreport); + + set_tasks_gp_state(rtp, RTGS_POST_GP); +} + +static int __init rcu_spawn_tasks_kthread(void) +{ + rcu_tasks.gp_sleep = HZ / 10; + if (rcu_tasks_lazy_ms >= 0) + rcu_tasks.lazy_jiffies = msecs_to_jiffies(rcu_tasks_lazy_ms); + rcu_tasks.wait_state = TASK_IDLE; + rcu_spawn_tasks_kthread_generic(&rcu_tasks); + return 0; +} + +void exit_tasks_rcu_start(void) { } +void exit_tasks_rcu_finish(void) { } + +#else /* #ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ + //////////////////////////////////////////////////////////////////////// // // Simple variant of RCU whose quiescent states are voluntary context @@ -1173,6 +1607,8 @@ static void tasks_rcu_exit_stall(struct timer_list *unused) #endif // #ifndef CONFIG_TINY_RCU } +#endif /* #else #ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ + /** * call_rcu_tasks() - Queue an RCU for invocation task-based grace period * @rhp: structure to be used for queueing the RCU updates. @@ -1187,6 +1623,12 @@ static void tasks_rcu_exit_stall(struct timer_list *unused) * primitives analogous to rcu_read_lock() and rcu_read_unlock() because * this primitive is intended to determine that all tasks have passed * through a safe state, not so much for data-structure synchronization. + * On CONFIG_TASKS_RCU_TRAMPOLINE_READERS kernels a preemption outside + * trampoline text also ends one, and a reader whose protected window + * spans preemptible code must additionally be a Tasks Trace RCU reader + * (rcu_read_lock_trace(), as the trampolines there take around their + * call-outs); an arbitrary stretch of preemptible kernel code is not + * protected. * * See the description of call_rcu() for more detailed information on * memory ordering guarantees. @@ -1205,7 +1647,9 @@ EXPORT_SYMBOL_GPL(call_rcu_tasks); * executing rcu-tasks read-side critical sections have elapsed. These * read-side critical sections are delimited by calls to schedule(), * cond_resched_tasks_rcu_qs(), idle execution, userspace execution, calls - * to synchronize_rcu_tasks(), and (in theory, anyway) cond_resched(). + * to synchronize_rcu_tasks(), and (in theory, anyway) cond_resched(); + * on CONFIG_TASKS_RCU_TRAMPOLINE_READERS kernels also by preemption + * outside trampoline text, see call_rcu_tasks(). * * This is a very specialized primitive, intended only for a few uses in * tracing and other situations requiring manipulation of function @@ -1233,9 +1677,7 @@ void rcu_barrier_tasks(void) } EXPORT_SYMBOL_GPL(rcu_barrier_tasks); -static int rcu_tasks_lazy_ms = -1; -module_param(rcu_tasks_lazy_ms, int, 0444); - +#ifndef CONFIG_TASKS_RCU_TRAMPOLINE_READERS static int __init rcu_spawn_tasks_kthread(void) { rcu_tasks.gp_sleep = HZ / 10; @@ -1251,6 +1693,7 @@ static int __init rcu_spawn_tasks_kthread(void) rcu_spawn_tasks_kthread_generic(&rcu_tasks); return 0; } +#endif /* #ifndef CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ #if !defined(CONFIG_TINY_RCU) void show_rcu_tasks_classic_gp_kthread(void) @@ -1279,6 +1722,7 @@ void rcu_tasks_get_gp_data(int *flags, unsigned long *gp_seq) } EXPORT_SYMBOL_GPL(rcu_tasks_get_gp_data); +#ifndef CONFIG_TASKS_RCU_TRAMPOLINE_READERS /* * Protect against tasklist scan blind spot while the task is exiting and * may be removed from the tasklist. Do this by adding the task to yet @@ -1322,6 +1766,7 @@ void exit_tasks_rcu_finish(void) list_del_init(&t->rcu_tasks_exit_list); raw_spin_unlock_irqrestore_rcu_node(rtpcp, flags); } +#endif /* #ifndef CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ #else /* #ifdef CONFIG_TASKS_RCU */ void exit_tasks_rcu_start(void) { } diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c index b62735a67884..a122b8d1effb 100644 --- a/kernel/rcu/update.c +++ b/kernel/rcu/update.c @@ -40,7 +40,9 @@ #include #include #include +#include #include +#include #include #include #include -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425493.1649403 (Exim 4.92) (envelope-from ) id 1x7ZuQ-0004Gn-ES; Fri, 18 Sep 2026 14:49:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425493.1649403; Fri, 18 Sep 2026 14:49:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuQ-0004Gg-AV; Fri, 18 Sep 2026 14:49:50 +0000 Received: by outflank-mailman (input) for mailman id 1425493; Fri, 18 Sep 2026 14:49:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuO-00044D-LS for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:49:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7ZuN-009hUR-Ce for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:49:47 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f6d-e002-0a2a0a5209dd-0a2a450b91f8-48 for ; Fri, 18 Sep 2026 16:49:47 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f8a-b7e8-0a2a450b0019-4a7de6ccecb9-3 for ; Fri, 18 Sep 2026 16:49:47 +0200 Received: by mail-qk2-f12.google.com with SMTP id d75a77b69052e-52fb76bcb1fso8330261cf.0 for ; Fri, 18 Sep 2026 07:49:46 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-532abe9a4f4sm3338251cf.0.2026.09.18.07.49.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742986; x=1790347786; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=fr6kFLYx3hqPZHfOilkUN+oxGtJHBsVQ4xuLKdXd4To=; b=JhaSd2xNUVF5PguyAOIqoKUcaNDq3UxXn5XklTEgGJoEsAs+AKpmlYiO0SIKJhxGEu 2OjMQ1y0tEfJuM1n0E983oHuH4eIk9+EDdMfJ4S9gjizwRqCNPx0EWsEaF0leGINc4vk WIs+6PEyKnA2FqgyBD6BZib08I0dsHFG+7m46PqCnBtW4PXki7rFzht17Ydmaswt53Os bKufQUafKX4Sy/Q4s9rjvJkf9LfHGps3sclazSPQIzMWicrvvUI7cARBtWVIEo5R3sxH T1/MMK3x3cBKjPzN/bqfQM2Wskk4Aqk3yvS8+G3kAcN04eFcZOOuSUxxS5NbuuXaoEfA 9cbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742986; x=1790347786; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=fr6kFLYx3hqPZHfOilkUN+oxGtJHBsVQ4xuLKdXd4To=; b=XiHlSRtnxE4xpGCamaIxzUV0E5uFsDsEuXYG+5HnQWXa26iNOtqiy/NwmKFEI5W99+ O3UYHLfzS9IqBiFRv4oG/pSkRewY52Wi3xFMbHhPGH65zo0oGOWhK8nobVE6xtT8kClG uwM3A9tIz91pV3Lf/LgkY23kmCYHz75dvPdSmGWKRUVYzw+XXXJtjebWBjS/5m4+JM8n TQxGY0VZOh2oVSZTYg8jARu9qd+YwP1Q6xn+rfrr+I5Oir8GES+ashhE8hxFd9gWZ3Xt TwDu+y8sQ3IU918nXnS2aU2+k+lALkQXIO9aIejLRFGwv5umTpuw2QqBwH0xy9GInaEG qomQ== X-Forwarded-Encrypted: i=1; AKwUvBwvPNDrftaBQ8xMGAXdMdZ4JilynE9q9v53vJ3embnHajMk94j6hnXkTcFbSh0/JKof3hUdB10zbaY=@lists.xenproject.org X-Gm-Message-State: AFuF++nGfieXMVm3W7IFsPLoDIEyxg5gKtLF8heQDKtpfZ2zm1ncfcts mQlOmDCbvjI1xXFDz2ISVe9WFYG8PzEJFoJcHKmLNQfHieocJ206WuK9tNJa/CT89lE= X-Gm-Gg: AYBFou3c5npRsPd75fULZ80tON6hVMs5fhCCwnr32opQE3Kvo8uXwwNL0Fzvbd4e2EY N3HETnh+r4YTqWsUs18sPnYEd5gtl2XZJVVaaIjJC+coAdx4LNk/8lWzOMIlysDZmZ1Ypxodl7l kQXcfJehjCuOymLpTSaI5yqzwP1rEQMVkZKWVWhninhYiiw7Y+nj2gnjQlOWZ/Ik5ciRdMxjhze raV9rIGYmJJqKmBR8jpoT6g+u7TQ6rnMtyuEUIFI8GMne3slfT97waBZgsjbQpqaNNRAENviRVZ kS3QBnFZ4G93ltD17Pdk2kfr8XfzzfTYiZ9ovdyD7verJWjCU0zLsGNzOH36GZ8Z2SHwtlvCfS/ GwmBsWqesOu8ntYMfrAxT5f7JSvXkBGdgGHVjx8RFq31965AbBRHUUrK5KM/THDaHlX+QVAZkFl 8eKMy1IZXU8LHMW551khMO/3U8Nrz/20cjofnqshjwlJTh2ml5qIvslJ78TZjfxoeDl5Cdl+2hg fyFKtTdL9FbJ0uaqIf69+NyCy4pJDgNbzplZ2pSDdkrQ8jzqcwxOefeEVyunnv6RdE= X-Received: by 2002:a05:622a:652:b0:530:efbc:9a8e with SMTP id d75a77b69052e-5329e3767camr46085191cf.5.1789742985599; Fri, 18 Sep 2026 07:49:45 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:20 +0000 Subject: [PATCH RFC v4 01/13] entry: Pass pt_regs to irqentry_exit_cond_resched() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-1-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742979; l=4297; i=josef@toxicpanda.com; h=from:subject:message-id; bh=vAWpKfoMcBcYFQiIgPpQZt2gAuw45VdrXu4vr32WnR0=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QLUE3k3CkS2ybrdoKxDg2rM2yr7vcCp6RSWtB3hgoOxoISfCxswmRrxWH4MEQd0eZavwNPRgmIn mcD0WDNOMyg4= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1789742987-AA4DB9EA-73F16DD6/0/0 X-purgate-type: clean X-purgate-size: 4299 The irq-exit preemption path is about to need the interrupted context's registers to decide whether the preemption may be reported to Tasks RCU as a quiescent state. irqentry_exit_to_kernel_mode_preempt() already has them; hand them down through irqentry_exit_cond_resched(), its PREEMPT_DYNAMIC static-call and static-key variants, and raw_irqentry_exit_cond_resched(). The only caller outside the generic entry code is Xen PV's upcall handler, which has regs as well. No functional change. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 13 +++++++------ kernel/entry/common.c | 6 +++--- 3 files changed, 11 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 2c64b388f616..3d85035f5624 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -739,7 +739,7 @@ __visible noinstr void xen_pv_evtchn_do_upcall(struct pt_regs *regs) inhcall = get_and_clear_inhcall(); if (inhcall && !WARN_ON_ONCE(state.exit_rcu)) { - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); instrumentation_end(); restore_inhcall(inhcall); } else { diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index 0bb6c03481fa..e19b41ee6b18 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -343,24 +343,25 @@ typedef struct irqentry_state { /** * irqentry_exit_cond_resched - Conditionally reschedule on return from interrupt + * @regs: Pointer to pt_regs of interrupted context * * Conditional reschedule with additional sanity checks. */ -void raw_irqentry_exit_cond_resched(void); +void raw_irqentry_exit_cond_resched(struct pt_regs *regs); #ifdef CONFIG_PREEMPT_DYNAMIC #if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL) #define irqentry_exit_cond_resched_dynamic_enabled raw_irqentry_exit_cond_resched #define irqentry_exit_cond_resched_dynamic_disabled NULL DECLARE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); -#define irqentry_exit_cond_resched() static_call(irqentry_exit_cond_resched)() +#define irqentry_exit_cond_resched(regs) static_call(irqentry_exit_cond_resched)(regs) #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void); -#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs); +#define irqentry_exit_cond_resched(regs) dynamic_irqentry_exit_cond_resched(regs) #endif #else /* CONFIG_PREEMPT_DYNAMIC */ -#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() +#define irqentry_exit_cond_resched(regs) raw_irqentry_exit_cond_resched(regs) #endif /* CONFIG_PREEMPT_DYNAMIC */ /** @@ -465,7 +466,7 @@ static inline void irqentry_exit_to_kernel_mode_preempt(struct pt_regs *regs, return; if (IS_ENABLED(CONFIG_PREEMPTION)) - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); } /** diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e3d381fd3d25..e4acd50bd81a 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -134,7 +134,7 @@ static inline bool arch_irqentry_exit_need_resched(void); static inline bool arch_irqentry_exit_need_resched(void) { return true; } #endif -void raw_irqentry_exit_cond_resched(void) +void raw_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!preempt_count()) { /* Sanity check RCU and thread stack */ @@ -150,11 +150,11 @@ void raw_irqentry_exit_cond_resched(void) DEFINE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void) +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) return; - raw_irqentry_exit_cond_resched(); + raw_irqentry_exit_cond_resched(regs); } #endif #endif -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425496.1649426 (Exim 4.92) (envelope-from ) id 1x7ZuW-0004kq-Eq; Fri, 18 Sep 2026 14:49:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425496.1649426; Fri, 18 Sep 2026 14:49:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuW-0004kO-6q; Fri, 18 Sep 2026 14:49:56 +0000 Received: by outflank-mailman (input) for mailman id 1425496; Fri, 18 Sep 2026 14:49:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuU-0004gV-6t for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:49:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7ZuT-0054h4-K5 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:49:53 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f85-8faa-0a2a0a5109dd-0a2a4506b4ba-32 for ; Fri, 18 Sep 2026 16:49:53 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f90-195a-0a2a45060019-4a7de6ccdddf-3 for ; Fri, 18 Sep 2026 16:49:53 +0200 Received: by mail-qk2-f12.google.com with SMTP id d75a77b69052e-530e28a62abso11097351cf.1 for ; Fri, 18 Sep 2026 07:49:53 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-532a19a5ce3sm14843771cf.12.2026.09.18.07.49.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:51 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742992; x=1790347792; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=cjEABplA81VfGcXS6Z1Q3Y7Xt5Unb50ofxErtTl6HPY=; b=oVOsWb1uu7G1/KWzNdrb+K6tlGrWQQfJXrgP/yh5l7HBkpyVd5K/O0W7LG4A2zVmD5 jPCDrwFeVmHVnoGrxyBzPwOZepOgalpNkxmfcOTskWTtjHmNLd5aORZbu0DcRbFa2g1h MN2MaQr17qXRQEegdLacnAhPf5RYBVKKbiLcGbstuAkcSFs9Iv2KXeeELZ2kJzukU9Ll 25t5puE6paTM5fOVaqWkPs7mGQflFbsE4e2tc9OG8Myv14Kf64fzDqWGW6FbkjinefJd VJkZ46AkxKJ0A5HhaRrIpHpdhyFD2kEJ9CoteR0NBw63zCFGJrhiPguujwmsMxnDTgvA IcYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742992; x=1790347792; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=cjEABplA81VfGcXS6Z1Q3Y7Xt5Unb50ofxErtTl6HPY=; b=Hn9Xpqp+fOO6iIN0CbDhMUUiyVWdXgB0c7JX8/cv+kkV5WFF6qHxRoYKRUxY/xg6Hn oqq32/bineZCBkREKEgkR/RUxIP7FVo8u3imixrXuXyKvlFLpt+1M6aVcq+EnQDVbSoJ OK/PERJSrsppJIwVg/JemyqxfvcjiL8h35BZjOopJ9ot4NJWPL41+ZeoMypPpLgixbX8 W9pYajxuyYGNDgdIMj0y0llMUqOm/EAvdm/PoFPAtLjaU58/GRzzpulb5Sdb4FKZ2aE+ /ktOLPQaeomhrFOQEW2xuBxx2YGpbWfgqslwKJaQWdEldIuDFigLpoeOzCwfJM/+poCW bC/g== X-Forwarded-Encrypted: i=1; AKwUvBwtNL74APxGkUbWKsVAIt+30mwlgY0FrxNgatz6BWWinCrGU8863RN4dsi7bKLLKf3AWBkqGvsgvVg=@lists.xenproject.org X-Gm-Message-State: AFuF++lp+mMd47QFtRMqB/KnR1v53hHUZknEGzGPTu3vMawQpvibI1hP aWcqlj/O4TreKhzaFlLgX1al6oh4gJgaM5GtiNjjkx1rcM47esgiGbNZUPx73hjL6iE= X-Gm-Gg: AYBFou1WpKgE7GqieRlmEibgKojboCbtgZypCKjHdEySKaS1KWnr0ZNGLblQtCdCb8B igVmgT3LXe/mOBAHxdJGI4trtczy58sJcJKt2YQUyiUxIhfON2mbELlZXg3oWbated68jWK8GJN t4Xiu9e3hXhwgsTI8/KCkInHv8sTSRUoGj4JM8FF1OCE5JPivkh0JqVJOp3005Xc2gT405BlRzN OJ9ECsxOjwtOyC8NRGLZMphkh7NoRGTGyAAbUNWWIPwMf77la+G9pW2jrsvznFul2EPKUSBchXE WRNu14gipFbVfoyRInXUaAT1KcdIjo23HMnizW8mWCjdTA4E32YXR6SwIhxZvHrgupLHSXAZehY aOM2Jtq6YPFJjaZwSYcqc2eWlrYym96VxuuSjmDmA9/zcqKjMKEo7irtpuo8qDrcBCfodYyZGcU Y3w2b6HmSAIwzBHDmekdcSsYhO12fCRm8scPnNBSmceJUjeU5ZgbURZTGsW9tyHsNs+0JaE2Z9W uN9JKjO9BxF1jogOfxNcUNdwAdBaNVoeqSzZgXw/YdY0a/qQFC/AcRvAg== X-Received: by 2002:ac8:7f0d:0:b0:52f:9e5c:33ff with SMTP id d75a77b69052e-5329e3767d5mr46806381cf.13.1789742991795; Fri, 18 Sep 2026 07:49:51 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:23 +0000 Subject: [PATCH RFC v4 04/13] ftrace: Mark modules hosting direct-call trampolines for Tasks RCU MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-4-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=7065; i=josef@toxicpanda.com; h=from:subject:message-id; bh=WxuURWfyPfVrbwoJYzsme+dJrO0g2fOexfelnDzg3io=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QOzJNf4EPWurTiDx3kIhXFyZwPBWmFPff1giOF5VzhAiMbXyfZ1cbtvqDh0lVG3P1j1LapzQR9r O/9+GtEnVpA0= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-16d1c6/1789742993-F560A77B-3845039B/0/0 X-purgate-type: clean X-purgate-size: 7067 An out-of-line direct trampoline registered with register_ftrace_direct() is kept alive only by Tasks RCU while a task executes it or is preempted in something it called; ftrace_shutdown()'s synchronize_rcu_tasks() is what stops rmmod freeing it under such a task. Where Tasks RCU is built on reader-marked trampolines, such a trampoline must be a Tasks Trace reader across its call-out like the ftrace and BPF trampolines are, so document that in register_ftrace_direct(). That still leaves the few instructions before the reader is entered and after it is left. For BPF images those are in dynamically allocated text that rcu_tasks_trampoline_text() already treats as unmarked trampoline text, but the in-tree samples (and any similar user) place their trampolines in module .text. Add a sticky module::ftrace_direct_tramp flag (under CONFIG_TASKS_RCU_TRAMPOLINE_READERS, its only consumer), set by every register/modify path when the direct address is module text, and have rcu_tasks_trampoline_text() treat a task interrupted anywhere in such a module as a potential holdout. Other modules' text is unaffected. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/module.h | 7 +++++++ kernel/rcu/tasks.h | 18 +++++++++++++++--- kernel/trace/ftrace.c | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 61 insertions(+), 3 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 96cc98568eea..82ca4f774725 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -521,6 +521,13 @@ struct module { unsigned int num_ftrace_callsites; unsigned long *ftrace_callsites; #endif +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + /* + * An ftrace direct-call trampoline lives in this module's text; see + * rcu_tasks_trampoline_text(). Sticky once set. + */ + bool ftrace_direct_tramp; +#endif #ifdef CONFIG_KPROBES void *kprobes_text_start; unsigned int kprobes_text_size; diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index eb1388dd8a61..42ea6e0e61cb 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1006,6 +1006,8 @@ bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) * deliberately does not ask is_ftrace_trampoline() and friends, since * text being torn down may already be unregistered there); * - whatever the architecture adds via arch_rcu_tasks_trampoline_text(); + * - the text of a module that hosts an out-of-line ftrace direct-call + * trampoline (see ftrace_direct_mark_module()); * - the bytes after a kprobe that a pending jump optimization is about to * overwrite, the one synchronize_rcu_tasks() user with no trampoline. * @@ -1014,12 +1016,22 @@ bool __weak arch_rcu_tasks_trampoline_text(unsigned long ip) */ bool rcu_tasks_trampoline_text(unsigned long ip) { + bool ret = true; + if (core_kernel_text(ip)) return arch_rcu_tasks_trampoline_text(ip) || kprobe_in_optimized_region(ip); - if (is_module_text_address(ip)) - return kprobe_in_optimized_region(ip); - return true; + +#ifdef CONFIG_MODULES + scoped_guard(rcu) { + struct module *mod = __module_text_address(ip); + + if (mod) + ret = READ_ONCE(mod->ftrace_direct_tramp) || + kprobe_in_optimized_region(ip); + } +#endif + return ret; } NOKPROBE_SYMBOL(rcu_tasks_trampoline_text); diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 53d5db60bfa5..f69f71591358 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6076,6 +6076,29 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) ops->trampoline = 0; } +/* + * A direct trampoline may live in module text rather than in dynamically + * allocated text that rcu_tasks_trampoline_text() recognises on its own (see + * samples/ftrace/ftrace-direct*.c). The trampoline itself must be a Tasks + * Trace reader across its call-out (see register_ftrace_direct()); marking the + * owning module here covers the instructions before it enters that reader and + * after it leaves it, where a task interrupted in the module's text must not be + * counted as Tasks-RCU quiescent, so that ftrace_shutdown()'s + * synchronize_rcu_tasks() still keeps the module text from being freed under + * it. + */ +static void ftrace_direct_mark_module(unsigned long addr) +{ +#if defined(CONFIG_MODULES) && defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) + struct module *mod; + + guard(rcu)(); + mod = __module_text_address(addr); + if (mod) + WRITE_ONCE(mod->ftrace_direct_tramp, true); +#endif +} + /** * register_ftrace_direct - Call a custom trampoline directly * for multiple functions registered in @ops @@ -6090,6 +6113,17 @@ static void reset_direct(struct ftrace_ops *ops, unsigned long addr) * and save the parameters of the function being traced, and restore them * (or inject new ones if needed), before returning. * + * Nothing but Tasks RCU keeps the trampoline at @addr alive while a task is + * executing it or is preempted in something it called. On architectures that + * select HAVE_RCU_TRAMPOLINE_READERS, Tasks RCU only waits for such a task if + * it is a Tasks Trace RCU reader, so the trampoline must enter one + * (rcu_read_lock_trace() or an assembly equivalent) before calling out and + * leave it before returning, just as that option requires of the in-kernel + * ftrace and BPF trampolines. The few instructions before and after are + * covered by the irq-exit check: automatically for trampolines outside kernel + * and module text (e.g. BPF images), and via ftrace_direct_mark_module() for + * trampolines in module text. + * * Returns: * 0 on success * -EINVAL - The @ops object was already registered with this call or @@ -6169,6 +6203,7 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) ops->flags |= MULTI_FLAGS; ops->trampoline = FTRACE_REGS_ADDR; ops->direct_call = addr; + ftrace_direct_mark_module(addr); err = register_ftrace_function_nolock(ops); if (err) @@ -6237,6 +6272,8 @@ __modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) lockdep_assert_held_once(&direct_mutex); + ftrace_direct_mark_module(addr); + /* Enable the tmp_ops to have the same functions as the direct ops */ ftrace_ops_init(&tmp_ops); tmp_ops.func_hash = ops->func_hash; @@ -6419,6 +6456,7 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash) hlist_for_each_entry(entry, &hash->buckets[i], hlist) { if (__ftrace_lookup_ip(direct_functions, entry->ip)) goto out_unlock; + ftrace_direct_mark_module(entry->direct); } } @@ -6702,6 +6740,7 @@ int update_ftrace_direct_mod(struct ftrace_ops *ops, struct ftrace_hash *hash, b tmp = __ftrace_lookup_ip(direct_hash, entry->ip); if (!tmp) continue; + ftrace_direct_mark_module(entry->direct); tmp->direct = entry->direct; } } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425492.1649392 (Exim 4.92) (envelope-from ) id 1x7ZuO-00044L-6t; Fri, 18 Sep 2026 14:49:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425492.1649392; Fri, 18 Sep 2026 14:49:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuO-00044E-3q; Fri, 18 Sep 2026 14:49:48 +0000 Received: by outflank-mailman (input) for mailman id 1425492; Fri, 18 Sep 2026 14:49:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuN-000447-7x for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:49:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7ZuL-005x6C-O0 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:49:45 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f65-8faa-0a2a0a5109dd-0a2a45088c44-48 for ; Fri, 18 Sep 2026 16:49:45 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f88-f659-0a2a45080019-4a7de68cfae6-3 for ; Fri, 18 Sep 2026 16:49:45 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-91235f46716so8083386d6.1 for ; Fri, 18 Sep 2026 07:49:45 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91257f2e58asm14263116d6.2.2026.09.18.07.49.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742984; x=1790347784; darn=lists.xenproject.org; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=uOvKZ7jMCmx8fIKUFee0Ich1k1yQqSbNT6X8Lv9nECM=; b=APX8OvT7pkb9r7E39tTToae961z+AnlcLyY69YsWoZINiweiy/ZJTavI8uW+UoG5Qq D++trAMnf8MO/8eIM5qjawIShA094oHg0Xs0RClr4s9L5Tc83W8TxU9AEkypt4GFn95v Hm0Kw4jgw19MiyETH9kLSLwrrYlE5gUUMJ+rayH/uR2VWOdIeA1EgQImm7aRUA3ZsIjC GqRxkM4H1Q4qVzOzSZHW90BTPYdaOXDIU2+LVqHKgOtZ8j/fYX4+mgwOFXxPCxuCqLg1 dxdUinOkz8KPkzJ5lBsVBNbZvbUAZMKEaloqGWUmtVdOQHtGeGsQMwCRRi9+Vw1nAuXN sgNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742984; x=1790347784; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=uOvKZ7jMCmx8fIKUFee0Ich1k1yQqSbNT6X8Lv9nECM=; b=ExbJKbTSnQP6mQ5jeJXd42VbKYCK95R3EuAOAR0OM6Gd/bXdtoFupj+EhRwK9AWywH M+0eoaOtVh0pWnsWwUcmMOnTHJm4ZIkP1ABfVF4XITLgztf3WCTl5jsgM2wKWiluzKuA cx+wx7sRa0j2SwzKOZkMtv9XUSUxXfg25jp9JWWGtS+MePmryFFgDBFO04oXApj+n/10 jg9ObFiz4ZOdu9BNNDH56pDIVz72JaTbhA4RKycBfpwszVsKKGVedaBcegBmacVfsmbO WCsqVspYwiANovB/IawwHiM7fTK5BEKOMOLOJ71CkTW4xXcW3YJwOKLVdag8b+gHdNBR Ov6w== X-Forwarded-Encrypted: i=1; AKwUvBy7qBeaMhKFd0TmQ15ggkfL63UuLiRME9NiiqXOnCj8AWMe6/WGYiTb6i1vPi+hd6ahFxcPVUO3Xb8=@lists.xenproject.org X-Gm-Message-State: AFuF++lV2w0JzCih7ytiEK4/+3k84W44KV6Jfj8/XC7Qo4ihjdaQC4ht hH3pQd0f7alAozib9lVWwsKtpKgEVH1nIOOVkSP3YRVpQ/Ko2Tl15yGJ8KgA/vLaoQw= X-Gm-Gg: AYBFou2QCn3UH+Iss0fmNC8lW/Ju/lYfEpGAsDRp04b/CNdmfYcMz2AZLNYpiPqU3i2 7vVW7YOBdq6W4/Uoy+3nbpClA9U/6UhIp1qmXYWnheAPnHSNYL6XS7WBKwoI0lHUMKEf4SGvEma IJvp4KC4iXnNp4YhaI/T+WNWHUxguG7OzHbWmD8Vfn6PKarvg8WiuZgEeS1RaLzSI1G/PONZGp2 8iqhoIxPWxgisX7aIqiYfWnNejtrS7YzhxCu3UUSoTfG/X16P51yO9T0OFl/kbdtvJoX71XhK5I aR05kMOc5wUvOjNI+BaAt8PhuBayDnwN+MpQS+fnZ0+uZ434z5H8Q8z2nH3nzPVLpFibfg3LYzh wEALmnlRc0jx4+/4pp7k5rSqf6axpq56QCKjoQEJ52JSYp1dEMkOe008fCxkcIfgN3bDffF/GGj F4koQrHnQPTz8LLhePL3SMMv/7EcNmiWO46CxmyDQqFQRg3gnNPuOL1JmEvX1jUYfP4EQBr/YNC 2odd7XYidgZ65WIMikoWCu24fVz3unDWXI1IrHwsdo/VTghLLvQBCOv X-Received: by 2002:ad4:4ae2:0:b0:910:1989:a61a with SMTP id 6a1803df08f44-91254b8fdebmr32250336d6.9.1789742983465; Fri, 18 Sep 2026 07:49:43 -0700 (PDT) From: Josef Bacik Subject: [PATCH RFC v4 00/13] rcu-tasks: build Tasks RCU on Tasks Trace readers in trampolines Date: Fri, 18 Sep 2026 14:49:19 +0000 Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAHBPrWoC/4XOwU7DMAwG4FeZciYsSd1O44Q0iQfgijg4jkszW NslWTU09d1Jw2USmzj6j/3lv4jIwXMUT6uLCDz56Ic+D/CwEtRh/8HSuzwLo0yjtlpJCzLQSSa Mn1GOgfkwJnmMEpRuW6ihqWkj8nV+av25yG/i9WUn3n/DeLJ7prSYy5rFyNIG7Klboq9xbWFdw lu/LBedj2kI36XxpAv/b7lJSyUdQLNtgUgr/ZyGs6cRe4ePNBxKuclcY/o+ZjLGiNhodsYh3MS qa6y+j1UZU+gqRUA18+YPNs/zD+q4d2SmAQAA X-Change-ID: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742979; l=12201; i=josef@toxicpanda.com; h=from:subject:message-id; bh=nVRI2iS5SJPI0UIAyaf7kiy21X18lzaxRK2+gPRlH0U=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QGSSszuFkwNYW13g7UbMZ/uKcGE7zBiDRtSatX6MTARbwezhPrC0ErVvu6KywLXNx40Pit80HwV IpJmIrJhiigM= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-c1860d/1789742985-CD34D87B-970EB052/0/0 X-purgate-type: clean X-purgate-size: 12203 v1: https://lore.kernel.org/all/20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com/ v2: https://lore.kernel.org/all/20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com/ v3: https://lore.kernel.org/all/20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com/ v3->v4: - BPF: the reader is emitted by the x86-64/arm64 JIT around the fentry/fmod_ret and fexit regions instead of taken in the C glue (Alexei). - An idle CPU only counts as quiescent while in an RCU EQS (Sashiko). - Dropped the rcu_read_lock_trace() lockdep/inline patch; BPF CI bot nits. v2->v3: - Reworked per Alexei and Paul: trampolines take rcu_read_lock_trace(), and Tasks RCU on x86-64/arm64 becomes a per-CPU pass plus a Tasks Trace grace period instead of a new per-task counter. v1->v2: - Sashiko/AI review fixes, Paul's and Steve's comments (see v2 changelog). What it does now: Every trampoline whose lifetime Tasks RCU guards (ftrace_caller and its copies, the optprobe template, BPF trampolines, out-of-line direct-call trampolines) takes rcu_read_lock_trace() around its call-out, open-coded in asm / by the JIT. That leaves the few trampoline instructions outside the reader, the static ftrace stubs and x86 return thunks that carry a trampoline address, and the kprobe jump-optimization window. A task can only linger in those by being interrupted there, so on x86-64 and arm64 the Tasks RCU grace period becomes: wait for every CPU to pass through __schedule() or sit in an EQS (the irq-exit preemption checks the interrupted IP first and briefly makes a task caught in such text a holdout), then synchronize_rcu_tasks_trace(), then one more pass for the trailing instructions. It runs from the existing rcu_tasks kthread, so call_rcu_tasks() and friends keep their names and callers; there is no task-list scan and no dependence on voluntary context switches, and cond_resched_tasks_rcu_qs() becomes unnecessary there. Other architectures keep the classic implementation. Testing is still QEMU: x86-64 PREEMPT_LAZY (PREEMPT_RCU=n) and PREEMPT_DYNAMIC, PROVE_RCU, lockdep. synchronize_rcu_tasks() against a 30s in-kernel spinner is 20-70ms (classic: 29.7s), ftrace instance teardown ~0.2s, optprobe register+unregister ~0.6s, the direct samples cycle in about a second, and fentry+fexit attach/hammer/detach on do_sys_openat2 and hrtimer_interrupt runs and detaches in 50-100ms with the return-to-user reader assertion quiet. arm64 is build-tested; hardware numbers for both are still owed. Open questions: - Paul: whether an alternate gp_func on the rcu_tasks kthread is acceptable as the first step, with Frederic's core-RCU variant as the follow-on you suggested. - The open-coded reader is ~9 instructions each side in ftrace_caller and at four points in the BPF trampoline. rcu_read_lock_tasks_trace() would be shorter but needs a slot for the cookie. - CONFIG_TASKS_TRACE_RCU_NO_MB depends on RCU_EXPERT, so non-expert x86/arm64 builds get the smp_mb() in the reader despite ARCH_WANTS_NO_INSTR; the asm follows the C but that looks unintended. --- Original email (v1) --- Tasks RCU only treats a voluntary context switch, usermode or idle as a quiescent state, because a preempted task may be sitting in a trampoline that is about to be freed. That was a fine trade when PREEMPT_NONE servers compiled Tasks RCU away and PREEMPT desktops rarely ran long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: Tasks RCU is now real on server configs, and cond_resched() is a no-op, so a CPU-bound kthread or kworker only ever loses the CPU by being preempted, which is exactly the event Tasks RCU refuses to count. The way this showed up for us was a cgroup writeback worker draining a very large cgwb for around eleven minutes on an arm64 box. Nothing wrong with that on its own, but a BPF program detach on another CPU went bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() while holding trampoline_mutex, forty-odd tasks piled up behind the mutex, and the hung task detector panicked the machine. The kprobe jump optimizer is worse in principle: it does synchronize_rcu_tasks() under kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running kthread can stall static key updates and CPU hotplug for its whole run. The current answer is to find each such loop and add cond_resched_tasks_rcu_qs() to it, which is the kind of annotation PREEMPT_LAZY was supposed to let us stop writing. This series tries the other direction: have the trampolines say when a task is inside them, so that a preemption anywhere else can be a quiescent state. - task_struct grows an int, rcu_tramp_nesting. Every trampoline whose lifetime Tasks RCU guards increments it before calling out and decrements it before returning: ftrace_caller and its dynamic copies, the BPF trampoline (which drops it again around the call to the original function, since im->pcref covers that), the x86 optprobe template, and out-of-line register_ftrace_direct() trampolines. Only current writes it and nested users are balanced, so it is a plain non-atomic inc/dec, one load of current plus one RMW per entry/exit. - The inc/dec are inside the trampoline, so there is a window of a few instructions on each side where the count is zero but the task is in (or on its way into) trampoline text. Nothing there can be preempted synchronously, only from an interrupt, so the irq-exit preemption path looks at regs->ip and holds the count across preempt_schedule_irq() when the IP is somewhere the counter cannot cover: outside core and module text (all the dynamically allocated trampolines and slots), in the static ftrace stubs or the x86 return thunks that still hold a direct-call target, in a module that hosts its own direct trampoline, or inside the bytes after a kprobe that the jump optimizer may be about to rewrite (the one synchronize_rcu_tasks() user that is not about trampolines at all). - With those in place, rcu_tasks_classic_qs() also clears the holdout flag on a preemption when the count is zero, on architectures that opt in. x86-64 and arm64 do so here. Everyone else keeps the voluntary-only rule and is untouched apart from the (unused) field. A running holdout already gets poked via rcu_request_urgent_qs_task(), which makes the next tick set NEED_RESCHED, so with this the resulting preemption retires it and a Tasks RCU grace period is bounded by roughly a tick plus the longest preempt-off section rather than by the longest stretch without a voluntary schedule(). Patches 1-12 are scaffolding and change no behaviour on their own; patch 13 flips the rule and selects the option for the two architectures. Testing so far is QEMU only: x86-64, PREEMPT_LAZY with PREEMPT_RCU=n, PROVE_RCU and lockdep, with and without PREEMPT_DYNAMIC. A kthread spinning in-kernel for 30s with the function tracer, an ftrace kprobe, an optimized kprobe and fentry/fexit programs attached: synchronize_rcu_tasks() goes from 29.7s to 0.1-0.3s, tearing down a DYNAMIC ftrace_ops (tracefs instance function -> nop) from 27s to 0.2-0.8s, and the ftrace-direct sample modules load, fire and unload in about 2.5s each while the spinner runs, with no warnings and the new return-to-user assertion quiet. arm64 is build-tested only at this point; real hardware numbers for both are the obvious next step and I did not want to sit on the idea waiting for them. Things I would particularly like opinions on: - Whether hooking rcu_tasks_classic_qs() is the right place, or whether Paul would rather see this expressed differently inside Tasks RCU. - return_to_handler and the rethook/kretprobe trampolines are not instrumented. Their C callees take the ftrace recursion lock before touching any ops and the trampolines themselves are static text, so I believe they do not need it, but I would like Steven and Masami to confirm. - The register_ftrace_direct() contract change: out-of-line direct trampolines now have to maintain the count themselves (the samples are converted). I do not know of out-of-tree users beyond BPF, but this is the one place an existing user could be silently weakened. - Whether arm64 folks are comfortable with the ldr/add/str in ftrace_caller and the BPF trampoline, and with treating all of ftrace_caller as trampoline text for the IP check. - If this holds up, cond_resched_tasks_rcu_qs() and rcu_softirq_qs_periodic() become unnecessary on the opted-in architectures; I have not touched them here. Based on v7.3-rc2+ (893e11787f78). --- Josef Bacik (13): entry: Pass pt_regs to irqentry_exit_cond_resched() rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines kprobes: Expose the optprobe jump window to Tasks RCU ftrace: Mark modules hosting direct-call trampolines for Tasks RCU x86/ftrace: Take a Tasks Trace reader around ftrace_caller's call-out x86/kprobes: Take a Tasks Trace reader in the optprobe template bpf, x86: Take a Tasks Trace reader in the trampoline around its call-outs arm64: ftrace: Take a Tasks Trace reader around ftrace_caller's call-out bpf, arm64: Take a Tasks Trace reader in the trampoline around its call-outs samples: ftrace: Make the direct-call trampolines Tasks Trace readers rcutorture: Make Tasks RCU readers Tasks Trace readers where required rcu-tasks-trace: Assert no reader is held on return to userspace x86, arm64: Build Tasks RCU on Tasks Trace readers in trampolines .../RCU/Design/Requirements/Requirements.rst | 24 ++ Documentation/RCU/checklist.rst | 7 +- arch/arm64/Kconfig | 1 + arch/arm64/kernel/asm-offsets.c | 8 + arch/arm64/kernel/entry-ftrace.S | 74 ++++ arch/arm64/kernel/ftrace.c | 20 + arch/arm64/net/bpf_jit_comp.c | 90 ++++ arch/x86/Kconfig | 1 + arch/x86/kernel/asm-offsets.c | 8 + arch/x86/kernel/ftrace.c | 43 ++ arch/x86/kernel/ftrace_64.S | 69 +++ arch/x86/kernel/kprobes/opt.c | 44 ++ arch/x86/kernel/vmlinux.lds.S | 4 + arch/x86/net/bpf_jit_comp.c | 113 +++++ arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 15 +- include/linux/kprobes.h | 8 +- include/linux/module.h | 7 + include/linux/rcupdate.h | 24 +- include/linux/rcupdate_trace.h | 7 + include/linux/sched.h | 1 + kernel/entry/common.c | 14 +- kernel/fork.c | 1 + kernel/kprobes.c | 50 +++ kernel/rcu/Kconfig | 28 +- kernel/rcu/rcutorture.c | 10 + kernel/rcu/tasks.h | 476 ++++++++++++++++++++- kernel/rcu/update.c | 2 + kernel/trace/ftrace.c | 39 ++ samples/ftrace/ftrace-direct-modify.c | 9 + samples/ftrace/ftrace-direct-multi-modify.c | 9 + samples/ftrace/ftrace-direct-multi.c | 5 + samples/ftrace/ftrace-direct-too.c | 5 + samples/ftrace/ftrace-direct.c | 5 + samples/ftrace/ftrace-direct.h | 126 ++++++ 35 files changed, 1326 insertions(+), 23 deletions(-) --- base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8 change-id: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 Best regards, -- Josef Bacik From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425497.1649439 (Exim 4.92) (envelope-from ) id 1x7ZuX-00059O-P6; Fri, 18 Sep 2026 14:49:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425497.1649439; Fri, 18 Sep 2026 14:49:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuX-000597-K3; Fri, 18 Sep 2026 14:49:57 +0000 Received: by outflank-mailman (input) for mailman id 1425497; Fri, 18 Sep 2026 14:49:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuW-0004ic-AE for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:49:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7ZuV-0054gK-Jm for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:49:55 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f71-bab6-0a2a0a5309dd-0a2a4507c416-44 for ; Fri, 18 Sep 2026 16:49:55 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f92-b4ea-0a2a45070019-4a7de68c8b0c-3 for ; Fri, 18 Sep 2026 16:49:55 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-9106feddbdfso7371256d6.0 for ; Fri, 18 Sep 2026 07:49:54 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9125800e368sm14412066d6.8.2026.09.18.07.49.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742994; x=1790347794; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=pPH1+eiN4EhHtK6rDK3I01/qZvQ6oNbinGntBhruq3Q=; b=i+Idf0G0nZ3uTlabI3uFjNO/t9kVswVLJb7snaSrP3fRvh1bqvyICrIqqIu9utHrKT ojZShzk3duHWyjYd7hLeQQUKv9OsNOL9JJjJU9KshuGYTiENQ8/6CNG6um+vbSJbcC9a hG3FEUu4WbApAdBRgAYXsxyU5lddTJF8z/0/I75ny1mQGWq75ByuqJqUS4ifTzWrtggw 01TD6708hgWx7LBC1SFUiccGcQ+o799QM4x9yrjHmSFa0myO69wmB8vzUEDeAT8zz3fG hIvTUE7jlNVmFkoaPgbIngyKYVmJaj4ovDlSawVVKeETe00iTkW5OhDMliX4EAy1vvus cPGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742994; x=1790347794; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=pPH1+eiN4EhHtK6rDK3I01/qZvQ6oNbinGntBhruq3Q=; b=y0wFHl+Z5G6ny7wf2Bo6N869ivLb//rrgEVBB20JjqApUyLscLN15qpYnnvmgoR+s4 2QQ+cg0yHY9KUAaYXM7iTVpOgzV832FxFyXHBU9LASzgzy7NN0y1ytyyrWYZWkccUOvc vWtAqsZQa/ygiIanQNHZabeWMgk2LmCme5faIVy1KlXqFvP31cbnDSqULHgCNWcmX4pS OQ6R7IUnH3MwK8jrArwFWXTxzHD2yfDZZXYd4FpkBb/9LZvO87wI2adVhJEZJ14SKN6r grckJ8bhiyZAMHA+2kwykNOVSwo1zY0b1MBVQ/wF31fCU7bGyak5QDbEaPMSH6pMdNIM LjCQ== X-Forwarded-Encrypted: i=1; AKwUvBzFjcFDl4c2MtUhr82FGhQeq39eszoqinoKDaYBzQ461c31z3fnbdzXSxlxtHuZ4IZv3pfGwP2lf1k=@lists.xenproject.org X-Gm-Message-State: AFuF++nFXPKb/JjwfMlo2Em3f9Jw+rqJZGS4gawS+2fFABY4Qiox+l2o XmArg5YT2D/kIWdkvI+KpWvcoml00VEiJbJIlj4lK7j/uYhEL9TVqwNPntmO21QLaE4= X-Gm-Gg: AYBFou1kkNrt7WTVgWzSK4s27qqltEjAgVW5qc7I6uj5CdoeN+HokllO4ccy+i0GkiU ApucfqAGzbe47C2Oa3oghPTOPbe6mo8G2HE/spKanh7on/eF98IeeHE0hGB4GWn8Zf15fKPswpq RGoL8lKpWh+ZiFYFl7r8ckWbjPy8BtKR6HU8MWLuyxFnY7ZilAbJ2aDojLbMfxHYy9kBwL/WA9S b8EBRrG1tzTHwc2kpHvbGnLwELZVBM/Ng8TFI/HLOdj+kpI7jSUsaA8gAJtO+k9uoHnqdHSIcQB ONOt5zlDp3fMn3SwiBdXW4Ct5RpX4NTipU4cGWFOauQfuFgAIrgJikojpfH4tlT8qBJ4BExgPEq 1hRGc8TTr845EIq7YW+pXr7SOsbGxvhCR8wAzLVESyz+B8o3XK+xIfOOCFZhvxxVOi+xKcaAVs/ 9zcDipkZz/tnFeuBVLHWnBEInP0lCLXqoLVhsmkvw3Y0x7ZnPqtOMKfljsFT/UGk5ZoRQJpFnuZ zug9mQPaMmMc5wCOhkrHUAEV1w7vK8p1uE3bc2qoELRXbWpRgZvjVE7d6rPWLhMqzQ= X-Received: by 2002:a05:6214:5d02:b0:910:705a:2c5e with SMTP id 6a1803df08f44-91254bcf2c3mr42299806d6.18.1789742993553; Fri, 18 Sep 2026 07:49:53 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:24 +0000 Subject: [PATCH RFC v4 05/13] x86/ftrace: Take a Tasks Trace reader around ftrace_caller's call-out MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-5-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=9964; i=josef@toxicpanda.com; h=from:subject:message-id; bh=EBgIXBiL5Z/I6XbFK2Nq9sAUVoT2dZ9k9OxjIjZChGA=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QE5RsSfIxHeGJCFPi3zOG/JnoKeCeLOBzXS0wrZafOedFHnVb+Jk6Kqa2Y7pWw6LloZYUQvCiGv 7bLPKG2JGuwc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ef75cf/1789742995-A6AD8AE4-89A271E0/0/0 X-purgate-type: clean X-purgate-size: 9966 For HAVE_RCU_TRAMPOLINE_READERS the ftrace trampolines must be Tasks Trace RCU readers while they call out, since that -- and not the absence of a voluntary context switch -- is what synchronize_rcu_tasks() will wait for before ftrace_shutdown() frees a dynamic trampoline or its ops. Open-code rcu_read_lock_trace() and rcu_read_unlock_trace() in ftrace_caller and ftrace_regs_caller: bump current->trc_reader_nesting and, for the outermost reader, do the SRCU-fast per-CPU increment on rcu_tasks_trace_srcu_struct and stash the counter pointer in current->trc_reader_scp, exactly as the C inlines do (including the smp_mb() when CONFIG_TASKS_TRACE_RCU_NO_MB is not set). The lock sits before the function_trace_op load, because between that load and the call the ops pointer is protected only by Tasks RCU, and the unlock after the call returns. The sequences are inside the region that create_trampoline() copies for per-ops trampolines; their %rip-relative references are fixed up by text_poke_apply_relocation() like CALL_DEPTH_ACCOUNT's. %rax and %rcx are dead at both points. Two pieces of core text still run outside that reader while holding the address of a Tasks-RCU-protected trampoline they are about to enter: the static stubs themselves, whose direct-call tails keep a BPF trampoline address on the stack until the final RET, and, under CONFIG_MITIGATION_RETHUNK, the return thunk that RET expands to. Add an ftrace_static_tramp_end marker after ftrace_stub_direct_tramp and linker symbols around .text..__x86.return_thunk and .text..__x86.rethunk_safe, and provide arch_rcu_tasks_trampoline_text() covering [ftrace_caller, ftrace_static_tramp_end) and both thunk ranges so the irq-exit check treats a task interrupted there as a holdout. All of this is built only under CONFIG_TASKS_RCU_TRAMPOLINE_READERS, which x86 does not enable until a later patch. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/kernel/asm-offsets.c | 8 +++++ arch/x86/kernel/ftrace.c | 43 +++++++++++++++++++++++++++ arch/x86/kernel/ftrace_64.S | 69 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/vmlinux.lds.S | 4 +++ 4 files changed, 124 insertions(+) diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c index 081816888f7a..876c3986419a 100644 --- a/arch/x86/kernel/asm-offsets.c +++ b/arch/x86/kernel/asm-offsets.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -46,6 +47,13 @@ static void __used common(void) #ifdef CONFIG_STACKPROTECTOR OFFSET(TASK_stack_canary, task_struct, stack_canary); #endif +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + OFFSET(TASK_trc_reader_nesting, task_struct, trc_reader_nesting); + OFFSET(TASK_trc_reader_scp, task_struct, trc_reader_scp); + OFFSET(SRCU_srcu_ctrp, srcu_struct, srcu_ctrp); + OFFSET(SRCU_CTR_srcu_locks, srcu_ctr, srcu_locks); + OFFSET(SRCU_CTR_srcu_unlocks, srcu_ctr, srcu_unlocks); +#endif BLANK(); OFFSET(pbe_address, pbe, address); diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index 17d6edfcb7e0..9babaed483eb 100644 --- a/arch/x86/kernel/ftrace.c +++ b/arch/x86/kernel/ftrace.c @@ -275,6 +275,49 @@ static inline void tramp_free(void *tramp) execmem_free(tramp); } +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +extern void ftrace_static_tramp_end(void); +extern char __return_thunk_start[], __return_thunk_end[]; +extern char __rethunk_safe_start[], __rethunk_safe_end[]; + +/* + * The SRCU-fast increments in TRACE_RCU_READ_LOCK/UNLOCK (ftrace_64.S) are the + * this_cpu_inc() form. + */ +static_assert(!IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE)); + +/* + * See rcu_tasks_trampoline_text(). Some core kernel text behaves like a + * trampoline for Tasks RCU purposes because a task executing there outside + * any Tasks Trace reader may still be about to enter a Tasks-RCU-protected + * trampoline whose address it already holds: + * + * - the static ftrace_caller / ftrace_regs_caller / ftrace_stub_direct_tramp + * stubs, which carry a direct-call target on the stack until their final + * RET, and + * - the return thunks that RET expands to under CONFIG_MITIGATION_RETHUNK, + * which run after leaving the stubs above and before landing in that + * target. + */ +bool arch_rcu_tasks_trampoline_text(unsigned long ip) +{ + if (ip >= (unsigned long)ftrace_caller && + ip < (unsigned long)ftrace_static_tramp_end) + return true; +#ifdef CONFIG_MITIGATION_RETPOLINE + if (ip >= (unsigned long)__return_thunk_start && + ip < (unsigned long)__return_thunk_end) + return true; +#endif +#ifdef CONFIG_MITIGATION_SRSO + if (ip >= (unsigned long)__rethunk_safe_start && + ip < (unsigned long)__rethunk_safe_end) + return true; +#endif + return false; +} +#endif /* CONFIG_TASKS_RCU_TRAMPOLINE_READERS */ + /* Defined as markers to the end of the ftrace default trampolines */ extern void ftrace_regs_caller_end(void); extern void ftrace_caller_end(void); diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index 62c1c93aa1c6..5d8cb3861978 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -145,6 +146,53 @@ SYM_FUNC_END(ftrace_stub_graph) #ifdef CONFIG_DYNAMIC_FTRACE +/* + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace(), see + * include/linux/rcupdate_trace.h and CONFIG_HAVE_RCU_TRAMPOLINE_READERS: the + * trampoline and the ftrace_ops it is about to load are kept alive by Tasks + * RCU only while we are inside this reader, so the lock must precede the + * function_trace_op load and the unlock must follow the call. These live + * inside the region copied into dynamic trampolines; the %rip-relative + * references are fixed up by text_poke_apply_relocation() in + * create_trampoline(). Clobbers %rax, %rcx and flags. + */ +.macro TRACE_RCU_READ_LOCK +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + movq PER_CPU_VAR(current_task), %rcx + movl TASK_trc_reader_nesting(%rcx), %eax + incl TASK_trc_reader_nesting(%rcx) + testl %eax, %eax + jnz .Ltrl_nested_\@ + movq rcu_tasks_trace_srcu_struct+SRCU_srcu_ctrp(%rip), %rax + incq %gs:SRCU_CTR_srcu_locks(%rax) + movq %rax, TASK_trc_reader_scp(%rcx) +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB + lock addl $0, -4(%rsp) /* smp_mb() */ +#endif +.Ltrl_nested_\@: +#endif +.endm + +.macro TRACE_RCU_READ_UNLOCK +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + movq PER_CPU_VAR(current_task), %rcx + movl TASK_trc_reader_nesting(%rcx), %eax + subl $1, %eax + jnz .Ltru_nested_\@ + /* Outermost: pick up scp before an interrupt can see nesting == 0. */ + movq TASK_trc_reader_scp(%rcx), %rax + movl $0, TASK_trc_reader_nesting(%rcx) +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB + lock addl $0, -4(%rsp) /* smp_mb() */ +#endif + incq %gs:SRCU_CTR_srcu_unlocks(%rax) + jmp .Ltru_done_\@ +.Ltru_nested_\@: + movl %eax, TASK_trc_reader_nesting(%rcx) +.Ltru_done_\@: +#endif +.endm + SYM_FUNC_START(__fentry__) ANNOTATE_NOENDBR CALL_DEPTH_ACCOUNT @@ -163,6 +211,8 @@ SYM_FUNC_START(ftrace_caller) leaq MCOUNT_REG_SIZE+8(%rsp), %rcx movq %rcx, RSP(%rsp) + TRACE_RCU_READ_LOCK + SYM_INNER_LABEL(ftrace_caller_op_ptr, SYM_L_GLOBAL) ANNOTATE_NOENDBR /* Load the ftrace_ops into the 3rd parameter */ @@ -181,6 +231,8 @@ SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) ANNOTATE_NOENDBR call ftrace_stub + TRACE_RCU_READ_UNLOCK + /* Handlers can change the RIP */ movq RIP(%rsp), %rax movq %rax, MCOUNT_REG_SIZE(%rsp) @@ -209,6 +261,8 @@ SYM_FUNC_START(ftrace_regs_caller) CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK + SYM_INNER_LABEL(ftrace_regs_caller_op_ptr, SYM_L_GLOBAL) ANNOTATE_NOENDBR /* Load the ftrace_ops into the 3rd parameter */ @@ -246,6 +300,8 @@ SYM_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL) ANNOTATE_NOENDBR call ftrace_stub + TRACE_RCU_READ_UNLOCK + /* Copy flags back to SS, to restore them */ movq EFLAGS(%rsp), %rax movq %rax, MCOUNT_REG_SIZE(%rsp) @@ -328,6 +384,19 @@ SYM_FUNC_START(ftrace_stub_direct_tramp) RET SYM_FUNC_END(ftrace_stub_direct_tramp) +/* + * [ftrace_caller, ftrace_static_tramp_end) is treated as trampoline text by + * rcu_tasks_trampoline_text(): outside TRACE_RCU_READ_LOCK/UNLOCK the stubs + * may still hold a direct-call trampoline address (ORIG_RAX / the return + * address they RET to) that only Tasks RCU keeps alive. With return thunks + * the RET itself runs elsewhere; arch_rcu_tasks_trampoline_text() covers + * those too. + */ +SYM_CODE_START_NOALIGN(ftrace_static_tramp_end) + UNWIND_HINT_UNDEFINED + ANNOTATE_NOENDBR +SYM_CODE_END(ftrace_static_tramp_end) + #else /* ! CONFIG_DYNAMIC_FTRACE */ SYM_FUNC_START(__fentry__) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 2438b89a4620..e546283dc267 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -151,7 +151,9 @@ SECTIONS * definition. */ . = srso_alias_untrain_ret | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20); + __rethunk_safe_start = .; *(.text..__x86.rethunk_safe) + __rethunk_safe_end = .; #endif ALIGN_ENTRY_TEXT_END @@ -162,7 +164,9 @@ SECTIONS SOFTIRQENTRY_TEXT #ifdef CONFIG_MITIGATION_RETPOLINE *(.text..__x86.indirect_thunk) + __return_thunk_start = .; *(.text..__x86.return_thunk) + __return_thunk_end = .; #endif STATIC_CALL_TEXT *(.gnu.warning) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425499.1649456 (Exim 4.92) (envelope-from ) id 1x7Zub-0005gJ-Gd; Fri, 18 Sep 2026 14:50:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425499.1649456; Fri, 18 Sep 2026 14:50:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zub-0005g8-CS; Fri, 18 Sep 2026 14:50:01 +0000 Received: by outflank-mailman (input) for mailman id 1425499; Fri, 18 Sep 2026 14:49:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7ZuZ-0005U8-Kw for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:49:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7ZuZ-0054h4-1p for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:49:59 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f97-8faa-0a2a0a5109dd-0a2a4507eda8-0 for ; Fri, 18 Sep 2026 16:49:59 +0200 Received: from [209.85.160.171] (helo=mail-qt1-f171.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f95-b4ea-0a2a45070019-d155a0aba40a-3 for ; Fri, 18 Sep 2026 16:49:58 +0200 Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-52ff0eea420so6539841cf.0 for ; Fri, 18 Sep 2026 07:49:58 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-532ac48df0fsm2560241cf.6.2026.09.18.07.49.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742997; x=1790347797; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Tx2UYwtxbz9ZqVNvSp5mlXDS3jyz+Ej3sfBe8tuEQZo=; b=E2IjlHcSBercr7jNqDVvN2nxUYcKbDPPAxG954ib+qwqRPH4B2zHgxgl3Mf5wLPlJF NpB9PJTUt/CLqL+PafCC6572u3RtwiGzrZGJYwP15sR35Y/fcGPgZANWrf9XWN93Sf51 a5mt5LWiXYXQSP5HFcwvF4yIGw5n2l6Nt9xOGyFCk1aqHDvi/TBHXJwRKBWvQHOxetuM QIr1W2qL4j4ndipkysE0HkFfxxVkFzzcSG9cxOl0i6wXf2p1bFr9ls71fX076STrb/A1 7KrRgghjFfBAt0KuZrqqtK4a9RxnGtWVcu6cdpEX/Hxj+qjxHcSDLMHs7q9QR6+Ymulm mG5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742997; x=1790347797; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Tx2UYwtxbz9ZqVNvSp5mlXDS3jyz+Ej3sfBe8tuEQZo=; b=laKZIP2poUZGfHVY5ctY7ZF53zLCo7wV8Z+LiuJGj9FhdVyYgBUaHC0w8Pn13h4026 YxfD6WnPcV9GJODJ2L56NJpEADVE2hJrBgF51RFYxuW0ds5h6EB8FrKNZH4h1LeNVnlZ RO90gynm3w29kVrE63a5gJ2kgCMKd8SpqGiDsgFu6nJezEkVzvTXK5Wk8u4CyvwPm4RA Md5vWtopRPIvSQdq7GHW/WRw5OpYdGIyXgUypzcgKrkNuyreSvSZGgt4CGRGfwe6GWHx Oh8TR6m/tRFJr1pMkAVYyo3ut0uoBoJtb92kJWkhjPat6ksHuw9//o5+rQGh+Dgvx8H1 ANKA== X-Forwarded-Encrypted: i=1; AKwUvBxT+1JA0ELvlBm1nF8GrTbPGP79cyNoK+w5vgukIdK0xFAT/Q1WBGZTyl0YwAli2uePxN4UvGmpycE=@lists.xenproject.org X-Gm-Message-State: AFuF++lPxhu5MNLBz3IBI4rOZUZ2o71PJJaCUyiRNXYo+Xjaj6Jl/mno e+raof6OnTut7SIom8jVuKkx4b7AH4RjcRMWic9fuXBwafXHeQckKCyKLUrlR3BWYRc= X-Gm-Gg: AYBFou3jx5kaxcbz563ef8oXnms7Nx4tYqGhhVy4DscApVyUVX06Hw+R+sg1L8idlKJ FUMluPzzv1IxkQUmhSA0eUYpE5F7RPmREurvE5xS85JxosVDW+tvp0a2kbm+7Y9BX+QC+4K87YX qX5Em2zOcjHzlcrPnL4LcEOr3kQHyWbYJ5GAtRwkrnLIbA0LUuOx/IGnMApEonXHaY7eNjdwnfO GYtl6jTZw4MFxzEinx3ELSKTZMubW15rEr7waVOybr4lFrI1t5dL48Sf8evZ6T3dDPLDjs6XNou AYRYxzYs+CmjjcSXPIxB/SZboIEyNaBCGRkZOK49iN5De0CcE3v+E5o7aRfblreL7hpJnzfHboR Q1HaYzGAVjxidiHIVyrJmB47GhTHPgeMlW4Q4iOVq7cWMG60r2qOucvyaqYnPt9WdRf7hjNHEZ0 aEpXGRDDFxISZQVkBfpqA+ye8NU8kyzZrHaOq/f8/1y+NZgrs0iO4V5CNatfYFAZn+UvbSLLWFL ocywhJ15DhobhQvSDxUsrSD8/Yku3lXFUactiVjdLVq2qOCJOZ06rY6 X-Received: by 2002:ac8:5f4f:0:b0:531:e51:12f9 with SMTP id d75a77b69052e-5328cfc0a9fmr106591791cf.24.1789742997160; Fri, 18 Sep 2026 07:49:57 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:26 +0000 Subject: [PATCH RFC v4 07/13] bpf, x86: Take a Tasks Trace reader in the trampoline around its call-outs MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-7-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=8086; i=josef@toxicpanda.com; h=from:subject:message-id; bh=JGl/QtTBddM7nyy/qfbMR7PzifAXs0WCS5aHiUuitqA=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QIEBfe7NVaGlqFqLQwZKbFw8BpHmlfuvIjJBnOTYn9qtDCjTJL+2uxQrDvhCu7CSaCn6ZdAis0V Bpsr/bJffvAk= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ef75cf/1789742999-35EC6AE4-2408CD1E/0/0 X-purgate-type: clean X-purgate-size: 8088 On HAVE_RCU_TRAMPOLINE_READERS kernels Tasks RCU keeps a BPF trampoline image allocated only while a task using it is a Tasks Trace RCU reader or is executing text that rcu_tasks_trampoline_text() recognises. The image itself is such text, but the C glue and the programs it calls are not, and only sleepable programs take rcu_read_lock_trace() today. Have the x86-64 JIT open-code rcu_read_lock_trace() and rcu_read_unlock_trace() in the trampoline, as ftrace_64.S does for ftrace_caller: one reader from just after the frame is set up to just before the original function is called, covering __bpf_tramp_enter() and the fentry and fmod_ret programs, and a second one from just after the original function returns to just before the final register restore, covering the fexit programs and __bpf_tramp_exit(). The original function itself runs outside both, since it may run for a long time and the image is pinned by im->pcref across it. Trampolines that do not call the original function get a single reader around all their programs. The second reader is entered before ip_after_call, so the ip_after_call -> ip_epilogue jump that bpf_tramp_image_put() patches in is inside it, and the fmod_ret early-exit branch lands after that point still holding the first reader, so exactly one is held on every path. The sequence uses r10 and r11, which are scratch at each emission point, and references current_task and rcu_tasks_trace_srcu_struct by absolute sign-extended address, the form the JIT already relies on for this_cpu_off. Sleepable programs' own rcu_read_lock_trace() simply nests. Nothing is emitted on other configurations. Suggested-by: Alexei Starovoitov Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/net/bpf_jit_comp.c | 113 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c index 2853e87797a7..c991f7ceacdf 100644 --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -722,6 +723,97 @@ static void emit_indirect_jump(u8 **pprog, int bpf_reg, u8 *ip) *pprog = prog; } +/* + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace() for the + * trampoline, see CONFIG_HAVE_RCU_TRAMPOLINE_READERS and the equivalent + * macros in arch/x86/kernel/ftrace_64.S. The image is not relocated, so + * current_task and rcu_tasks_trace_srcu_struct are referenced by absolute + * (sign-extended 32-bit) address, the form the JIT already relies on for + * this_cpu_off. Uses r10 and r11, which are scratch at every emission + * point, and clobbers flags. + * + * lock: unlock: + * mov r11, gs:[current_task] mov r11, gs:[current_task] + * mov r10d, [r11+nesting] mov r10d, [r11+nesting] + * inc dword ptr [r11+nesting] sub r10d, 1 + * test r10d, r10d jnz 2f + * jnz 1f mov r10, [r11+scp] + * mov r10, [&srcu.srcu_ctrp] mov dword ptr [r11+nesting], 0 + * inc qword ptr gs:[r10+locks] (smp_mb) + * mov [r11+scp], r10 inc qword ptr gs:[r10+unlocks] + * (smp_mb) jmp 3f + * 1: 2: mov [r11+nesting], r10d + * 3: + */ +static void emit_trace_rcu_reader(u8 **pprog, bool lock) +{ +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + const u32 nesting = offsetof(struct task_struct, trc_reader_nesting); + const u32 scp = offsetof(struct task_struct, trc_reader_scp); + const bool mb = !IS_ENABLED(CONFIG_TASKS_TRACE_RCU_NO_MB); + u8 *prog = *pprog; + + BUILD_BUG_ON(IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE)); + BUILD_BUG_ON(offsetof(struct srcu_ctr, srcu_locks) != 0); + BUILD_BUG_ON(offsetof(struct srcu_ctr, srcu_unlocks) != 8); + + /* mov r11, gs:[abs32 current_task] */ + EMIT2(0x65, 0x4C); + EMIT3(0x8B, 0x1C, 0x25); + EMIT((u32)(unsigned long)¤t_task, 4); + /* mov r10d, dword ptr [r11 + nesting] */ + EMIT3(0x45, 0x8B, 0x93); + EMIT(nesting, 4); + + if (lock) { + /* inc dword ptr [r11 + nesting] */ + EMIT3(0x41, 0xFF, 0x83); + EMIT(nesting, 4); + /* test r10d, r10d */ + EMIT3(0x45, 0x85, 0xD2); + /* jnz 1f */ + EMIT2(X86_JNE, 8 + 4 + 7 + (mb ? 6 : 0)); + /* mov r10, qword ptr [abs32 &rcu_tasks_trace_srcu_struct.srcu_ctrp] */ + EMIT4(0x4C, 0x8B, 0x14, 0x25); + EMIT((u32)(unsigned long)&rcu_tasks_trace_srcu_struct.srcu_ctrp, 4); + /* inc qword ptr gs:[r10] */ + EMIT4(0x65, 0x49, 0xFF, 0x02); + /* mov qword ptr [r11 + scp], r10 */ + EMIT3(0x4D, 0x89, 0x93); + EMIT(scp, 4); + /* smp_mb(): lock add dword ptr [rsp - 4], 0 */ + if (mb) + EMIT2_off32(0xF0, 0x83, 0x00FC2444); + /* 1: */ + } else { + /* sub r10d, 1 */ + EMIT4(0x41, 0x83, 0xEA, 0x01); + /* jnz 2f */ + EMIT2(X86_JNE, 7 + 11 + (mb ? 6 : 0) + 5 + 2); + /* mov r10, qword ptr [r11 + scp] */ + EMIT3(0x4D, 0x8B, 0x93); + EMIT(scp, 4); + /* mov dword ptr [r11 + nesting], 0 */ + EMIT3(0x41, 0xC7, 0x83); + EMIT(nesting, 4); + EMIT(0, 4); + if (mb) + EMIT2_off32(0xF0, 0x83, 0x00FC2444); + /* inc qword ptr gs:[r10 + 8] */ + EMIT4(0x65, 0x49, 0xFF, 0x42); + EMIT1(0x08); + /* jmp 3f */ + EMIT2(0xEB, 7); + /* 2: mov dword ptr [r11 + nesting], r10d */ + EMIT3(0x45, 0x89, 0x93); + EMIT(nesting, 4); + /* 3: */ + } + + *pprog = prog; +#endif +} + static void emit_return(u8 **pprog, u8 *ip) { u8 *prog = *pprog; @@ -3610,6 +3702,16 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im /* mov QWORD PTR [rbp - rbx_off], rbx */ emit_stx(&prog, BPF_DW, BPF_REG_FP, BPF_REG_6, -rbx_off); + /* + * Tasks RCU keeps this image alive only while we are a Tasks Trace + * reader; the instructions before this point (and after the final + * unlock) are covered by the irq-exit IP check. One reader spans + * __bpf_tramp_enter() and the fentry/fmod_ret progs, a second one + * the fexit progs and __bpf_tramp_exit(); the original function runs + * outside both, with the image pinned by im->pcref instead. + */ + emit_trace_rcu_reader(&prog, true); + func_meta = nr_regs; /* Store number of argument registers of the traced function */ emit_store_stack_imm64(&prog, BPF_REG_0, -func_meta_off, func_meta); @@ -3660,6 +3762,7 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im } if (flags & BPF_TRAMP_F_CALL_ORIG) { + emit_trace_rcu_reader(&prog, false); restore_regs(m, &prog, regs_off); save_args(m, &prog, arg_stack_off, true, flags, 0); @@ -3682,6 +3785,13 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im } /* remember return value in a stack for bpf prog to access */ emit_stx(&prog, BPF_DW, BPF_REG_FP, BPF_REG_0, -8); + /* + * Second reader. Taken before ip_after_call so that the + * ip_after_call -> ip_epilogue jump patched in at teardown is + * inside it too; the fmod_ret early exit jumps past this still + * holding the first reader, so either way exactly one is held. + */ + emit_trace_rcu_reader(&prog, true); im->ip_after_call = image + (prog - (u8 *)rw_image); emit_nops(&prog, X86_PATCH_SIZE); } @@ -3737,6 +3847,9 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im LOAD_TRAMP_TAIL_CALL_CNT_PTR(stack_size); } + /* Remaining instructions are covered by the irq-exit IP check. */ + emit_trace_rcu_reader(&prog, false); + /* restore return value of orig_call or fentry prog back into RAX */ if (save_ret) emit_ldx(&prog, BPF_DW, BPF_REG_0, BPF_REG_FP, -8); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425500.1649465 (Exim 4.92) (envelope-from ) id 1x7Zuc-00060c-SX; Fri, 18 Sep 2026 14:50:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425500.1649465; Fri, 18 Sep 2026 14:50:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zuc-0005zu-Lh; Fri, 18 Sep 2026 14:50:02 +0000 Received: by outflank-mailman (input) for mailman id 1425500; Fri, 18 Sep 2026 14:50:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zub-0005eZ-B7 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:50:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Zua-009hUR-O7 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:50:00 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f96-e002-0a2a0a5209dd-0a2a450294da-8 for ; Fri, 18 Sep 2026 16:50:00 +0200 Received: from [74.125.230.231] (helo=mail-qk2-f39.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f97-6ca4-0a2a45020019-4a7de6e78069-3 for ; Fri, 18 Sep 2026 16:50:00 +0200 Received: by mail-qk2-f39.google.com with SMTP id af79cd13be357-939922847efso75293985a.0 for ; Fri, 18 Sep 2026 07:50:00 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93be0edf295sm154059185a.33.2026.09.18.07.49.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789742999; x=1790347799; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ua8lq0Nx07F8Y+BgJ1JiUwgoDOin8IZmspGmQtj7ybE=; b=q1gCAUv1aEiFmrLPdSmiHNUL6z93tRHYEGz2qkyOaTmDmm5HhrExX3g0xKtVnit9cQ ogwB2c3hXMCmkBiLJG5pIrPDKO0Jd8DlxamvAyiGFY17ekLBjeG12HkuDaOu5myo2AfF 4Z6BegArpnV/zLQblbS9FGQDbC4AE7T3Z7CS5BGOav0mYMZ7yGIKxjFq55dABo205FSz i6pwdwMljIjzdHCKfc2/uwYTo2v4PCJzUnAqWchH3+ALq4II1y/84eIJ+kZwzCRItMx/ eUzsfcL8lgpKZNJ9u8DyMo/G486RKdzHm7d2gN9l8lKROepmaD3l41OFQZbsrBVkZyHP Ympg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789742999; x=1790347799; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ua8lq0Nx07F8Y+BgJ1JiUwgoDOin8IZmspGmQtj7ybE=; b=WRQqFWl2ijc8p2H/IfDJuYKsXCDrkUDSN5zs9htluRQxYAEHUFWqqhONps3H/bEisa 8SrAl3yeLe93l7LRzAl5vKCOg1yRYzr8X/bc7/pSeXq4IAgzXXq+pvKJ9D/RjGVDANiJ bSnL5UPqJoGAwEzpE8WdjyRn9CXy6VcR6wJxbAx48ExxVim0S8B42oY5mdYEP78DNsdk QuDnxquzA3Q/mAKbaYRu5UTzRLsw/M1AFAnPwQUEwlZOGxlnZXomq52kc+0v55+2dkQG A0znCF9mARSeTARYi5BlCXNEubB+JCNftWOD4t64s1DZKdGBsin4+lV0t9RJm0hzMRze 0jnA== X-Forwarded-Encrypted: i=1; AKwUvBy2i+WfG2HdX/0wXFCysSMOw7BK7FFMi89t6hlBHPAYrIwOSYBfUsNZ6rIrhk4AhJcnq8XxWFojxSA=@lists.xenproject.org X-Gm-Message-State: AFuF++lYDBBUvPX4TTZ69HzMxwcfL6nKksjXk6dagBpCPE+IL3hgxwMJ GqX3SKaw0R/ESUeOfjblFa4rRlCJYyH0P+Cy8YVSX86bpa86MAib4IYru+6e8RQU7lg= X-Gm-Gg: AYBFou3K6HsiEtugPMYgv0xSCUEsMHNP5cRZolDEjj6S/5Km2/avYZ0OtWjWpcsTehf nzlxRNdkbp9FRKNaZkHEMnL+DbzOq+pLl4ZT8BIAZCcmjNH383FaWIDCHjJZknzrb0xL8B8S3cN mBYRg3+v4yOEdzg3+jyjLmR4xehkByzQLue43KpPXqYyFWpflpCy6g8ZcoAXW+FfGwQqra2AyrO WBbc0hzi1sCfiS9hhOGXQt9+UtdmKik/1afDtiy6hv0hBvopzbBQ9RqJsbF/Lgh7KAUOxpYuure 65p1JWL4dvZFiJTpuAjRr/G0J6BbNj8lZPnxGLoa9XsV9ij/Ko+xn9GoeJLC8ZONoT9YGGDeYO+ bsXtglLOhpI0QKPEUyiljP9rNHBSP7dxlx/U4bZJk19YHiGcc7/UL9ym+WJUNtVIGM0L06nerOJ mHRwZXzdnZdoGfLRgefnwb6elLqt/oS1gtrcqB5QZD6aoyQVeiCKwo8V8A3qdSMi34Q8WND0993 OEnDUrQ4tAdYkChNe7cr1DV6E4nnfJdQd9jBYVwNaLmTgzuDatloLaC X-Received: by 2002:a05:620a:1a05:b0:939:733d:cbe0 with SMTP id af79cd13be357-93bdc65cdefmr384366585a.3.1789742998818; Fri, 18 Sep 2026 07:49:58 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:27 +0000 Subject: [PATCH RFC v4 08/13] arm64: ftrace: Take a Tasks Trace reader around ftrace_caller's call-out MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-8-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=7839; i=josef@toxicpanda.com; h=from:subject:message-id; bh=Aqm0C5BBMBkqFusbG93kcm6leRi28F4VKStTPzg6dAE=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QBDwhofZWNUZ4nqzwdQchm82AWmFCaXImzqI0Y5t/lZTWR+xCeGh1w/K8fFkLJ01W3nr6p09Evj VkL1iXbfRFwc= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1789743000-666B72AC-9C8E0CBE/0/0 X-purgate-type: clean X-purgate-size: 7841 For HAVE_RCU_TRAMPOLINE_READERS the ftrace trampoline must be a Tasks Trace RCU reader while it calls out, since that is what synchronize_rcu_tasks() will wait for before ftrace_shutdown() frees an ftrace_ops (or, with CALL_OPS, lets its owner free it) under a task preempted in the callback. Open-code rcu_read_lock_trace() and rcu_read_unlock_trace() around the call to ops->func in ftrace_caller: bump current->trc_reader_nesting via sp_el0 and, for the outermost reader, do the SRCU-fast per-CPU increment on rcu_tasks_trace_srcu_struct and stash the counter pointer in current->trc_reader_scp, as the C inlines do (including the dmb when CONFIG_TASKS_TRACE_RCU_NO_MB is not set). The per-CPU increment is an LL/SC add on this CPU's counter; being migrated between reading the per-CPU offset and the store-exclusive only means another CPU's counter is incremented atomically instead, which SRCU sums over anyway. x12-x16 are free at both points. arm64 has no return thunks and, with CALL_OPS, no dynamic ftrace trampolines, but ftrace_caller itself carries the ops pointer in x11 from before the reader is entered and a direct-call BPF trampoline address in x17 until the final br/ret after it is left, so mark the end of the static trampoline text and provide arch_rcu_tasks_trampoline_text() covering [ftrace_caller, ftrace_static_tramp_end). Built only under CONFIG_TASKS_RCU_TRAMPOLINE_READERS, which arm64 does not enable until a later patch. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/arm64/kernel/asm-offsets.c | 8 +++++ arch/arm64/kernel/entry-ftrace.S | 74 ++++++++++++++++++++++++++++++++++++++++ arch/arm64/kernel/ftrace.c | 20 +++++++++++ 3 files changed, 102 insertions(+) diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 9c853ed3ceab..f6a8fb1f9b43 100644 --- a/arch/arm64/kernel/asm-offsets.c +++ b/arch/arm64/kernel/asm-offsets.c @@ -10,6 +10,7 @@ #include #include +#include #include #include #include @@ -39,6 +40,13 @@ int main(void) DEFINE(TSK_STACK, offsetof(struct task_struct, stack)); #ifdef CONFIG_STACKPROTECTOR DEFINE(TSK_STACK_CANARY, offsetof(struct task_struct, stack_canary)); +#endif +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + DEFINE(TSK_TRC_READER_NESTING, offsetof(struct task_struct, trc_reader_nesting)); + DEFINE(TSK_TRC_READER_SCP, offsetof(struct task_struct, trc_reader_scp)); + DEFINE(SRCU_SRCU_CTRP, offsetof(struct srcu_struct, srcu_ctrp)); + DEFINE(SRCU_CTR_SRCU_LOCKS, offsetof(struct srcu_ctr, srcu_locks)); + DEFINE(SRCU_CTR_SRCU_UNLOCKS, offsetof(struct srcu_ctr, srcu_unlocks)); #endif BLANK(); DEFINE(THREAD_CPU_CONTEXT, offsetof(struct task_struct, thread.cpu_context)); diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S index 025140caafe7..fc2805eb9e15 100644 --- a/arch/arm64/kernel/entry-ftrace.S +++ b/arch/arm64/kernel/entry-ftrace.S @@ -14,6 +14,72 @@ #include #ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS +/* + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace(), see + * include/linux/rcupdate_trace.h and CONFIG_HAVE_RCU_TRAMPOLINE_READERS. The + * whole of ftrace_caller is treated as trampoline text by the irq-exit check + * (see arch_rcu_tasks_trampoline_text()), so these only need to bracket the + * call out to ops->func; everything before the lock and after the unlock, + * including the direct-call tails that carry a BPF trampoline address in x17, + * is covered by that. + * + * The SRCU-fast per-CPU increment is done LL/SC on this CPU's counter; being + * migrated between reading the per-CPU offset and the store-exclusive only + * means another CPU's counter is (atomically) incremented, which SRCU sums + * over anyway. Ordering between the nesting count and the scp stash only + * matters against interrupts on this CPU, which observe program order. + * Clobbers x12-x16 and the flags. + */ + .macro trace_rcu_srcu_inc, addr:req, tmp:req, wtmp2:req +8888: ldxr \tmp, [\addr] + add \tmp, \tmp, #1 + stxr \wtmp2, \tmp, [\addr] + cbnz \wtmp2, 8888b + .endm + + .macro trace_rcu_read_lock +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + mrs x12, sp_el0 // current + ldr w13, [x12, #TSK_TRC_READER_NESTING] + add w14, w13, #1 + str w14, [x12, #TSK_TRC_READER_NESTING] + cbnz w13, .Ltrl_nested\@ // interrupted a reader: done + ldr_l x13, rcu_tasks_trace_srcu_struct + SRCU_SRCU_CTRP + str x13, [x12, #TSK_TRC_READER_SCP] + get_this_cpu_offset x14 + add x14, x14, x13 + add x14, x14, #SRCU_CTR_SRCU_LOCKS + trace_rcu_srcu_inc x14, x15, w16 +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB + dmb ish +#endif +.Ltrl_nested\@: +#endif + .endm + + .macro trace_rcu_read_unlock +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + mrs x12, sp_el0 // current + ldr w13, [x12, #TSK_TRC_READER_NESTING] + subs w13, w13, #1 + b.ne .Ltru_nested\@ + /* Outermost: pick up scp before an interrupt can see nesting == 0. */ + ldr x14, [x12, #TSK_TRC_READER_SCP] + str wzr, [x12, #TSK_TRC_READER_NESTING] +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB + dmb ish +#endif + get_this_cpu_offset x15 + add x14, x14, x15 + add x14, x14, #SRCU_CTR_SRCU_UNLOCKS + trace_rcu_srcu_inc x14, x15, w16 + b .Ltru_done\@ +.Ltru_nested\@: + str w13, [x12, #TSK_TRC_READER_NESTING] +.Ltru_done\@: +#endif + .endm + /* * Due to -fpatchable-function-entry=2, the compiler has placed two NOPs before * the regular function prologue. For an enabled callsite, ftrace_init_nop() and @@ -94,6 +160,8 @@ SYM_CODE_START(ftrace_caller) stp x29, x30, [sp, #FREGS_SIZE] add x29, sp, #FREGS_SIZE + trace_rcu_read_lock + /* Prepare arguments for the tracer func */ sub x0, x30, #AARCH64_INSN_SIZE // ip (callsite's BL insn) mov x1, x9 // parent_ip (callsite's LR) @@ -111,6 +179,8 @@ SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL) bl ftrace_stub // func(ip, parent_ip, op, regs) #endif + trace_rcu_read_unlock + /* * At the callsite x0-x8 and x19-x30 were live. Any C code will have preserved * x19-x29 per the AAPCS, and we created frame records upon entry, so we need @@ -178,6 +248,10 @@ SYM_CODE_START(ftrace_stub_direct_tramp) SYM_CODE_END(ftrace_stub_direct_tramp) #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */ +/* End of [ftrace_caller, ...) for arch_rcu_tasks_trampoline_text(). */ +SYM_CODE_START(ftrace_static_tramp_end) +SYM_CODE_END(ftrace_static_tramp_end) + #else /* CONFIG_DYNAMIC_FTRACE_WITH_ARGS */ /* diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c index e1a3c0b3a051..5f4193f15cd9 100644 --- a/arch/arm64/kernel/ftrace.c +++ b/arch/arm64/kernel/ftrace.c @@ -17,6 +17,26 @@ #include #include +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS +extern void ftrace_static_tramp_end(void); + +/* The SRCU-fast increments in entry-ftrace.S are the this_cpu_inc() form. */ +static_assert(!IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE)); + +/* + * See rcu_tasks_trampoline_text(). ftrace_caller and ftrace_stub_direct_tramp + * are core kernel text but must be treated as trampolines: a task interrupted + * in them outside the Tasks Trace reader may be carrying an ops pointer (x11) + * or a direct-call BPF trampoline address (x17) whose lifetime is guarded only + * by Tasks RCU. + */ +bool arch_rcu_tasks_trampoline_text(unsigned long ip) +{ + return ip >= (unsigned long)ftrace_caller && + ip < (unsigned long)ftrace_static_tramp_end; +} +#endif + #ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS struct fregs_offset { const char *name; -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425505.1649474 (Exim 4.92) (envelope-from ) id 1x7Zuh-0006wu-BU; Fri, 18 Sep 2026 14:50:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425505.1649474; Fri, 18 Sep 2026 14:50:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zuh-0006wB-5p; Fri, 18 Sep 2026 14:50:07 +0000 Received: by outflank-mailman (input) for mailman id 1425505; Fri, 18 Sep 2026 14:50:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zuf-0006du-I5 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:50:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Zue-0054nV-V1 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:50:04 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f8b-8faa-0a2a0a5109dd-0a2a450bb8d4-34 for ; Fri, 18 Sep 2026 16:50:04 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f9b-b7e8-0a2a450b0019-4a7de6ccadd4-3 for ; Fri, 18 Sep 2026 16:50:04 +0200 Received: by mail-qk2-f12.google.com with SMTP id af79cd13be357-939695b5741so77872185a.1 for ; Fri, 18 Sep 2026 07:50:04 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93be0cd1807sm155785785a.4.2026.09.18.07.50.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:50:01 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789743003; x=1790347803; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Nk/uI/WquaXkRgHHd/dzhScVzrCkrWpp6IlwsBXJcUg=; b=caweufXTUdydEpY+1sjgq5PBziP0tWwC6FwroISpqzZOIFhDozqGYFyIDsE50GH64h U7HxwV6hVrk74OoMneABgCt8MDbeTerDH4fFZeZB+DlLWgLKruXiAhhq89XSVGhDubC6 6gM8hC3IxseJyiuyxQ+qd599l66zsLn8ABw25LNhWyB013BCuiQ/xFI7vdP6uOt/fuWM /olbXsu5LytxOjA68Ppo5rbHvLStBlvQQTsx2WF/SkCd21Zmj6OUo4feI6ZSk+ueUNzu 4ZEIbdiOop9Y0tnZDHEqREGMqTRzEfyb45c+wfwtFsQpjQynWkSg46kIb47HVOnazpds Qm0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789743003; x=1790347803; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Nk/uI/WquaXkRgHHd/dzhScVzrCkrWpp6IlwsBXJcUg=; b=flxY+hioavvEZOMlj8e62ljSNYfpwLtiQCy4Ls0IhHTs0xtHXPOg4g2Ka0sVLC/Wdo pX5cTpeSg8vyMW0fbbe86F5vL9q9baly8JXw+TaO+s95WktyliFQutnVM1R26p5Z6MVc NoT3wnMXA8/Pn3DfPi1wgffCRRKgtj5uvxlBAX8rztXCztm9KYjoVYD7VDOxoWOq12vo PToSET656M7X5x8BYnb+4twOP+bNwimX6d8eplXdRQB1ZfpWzzUqy6kQD1IHKGNAUrqF gttJYiBKU9vgDccX0i6EUp6gUDZ9dxZrUCvVQhf0LkZwQurF3Rn5vMG99XDOsPv/eKTI 5LKg== X-Forwarded-Encrypted: i=1; AKwUvBwPP/TIqmWK/s1t9bBl5ONdaJdnO+idElC+TijZ0mdA4vvPvseHobLdT0UDSIGU4xs16WpO+NaEZDg=@lists.xenproject.org X-Gm-Message-State: AFuF++nXu3Ghb10gzL5i0ibNvxjTPUWJhbON6QMtWHpr09lNbwA9XfYF gLDk085tdYx12VsfsvDuFrrB5c1ajwgZr0PdW62LHG1diDZT+xqMBkHT2DVNmOGE6To= X-Gm-Gg: AYBFou142nJ/WrmU2QYLhnODQZOpldZNAUHZXgjwUiXELqlCyJdASgSHU/kmuaQT5cX aHCtW77HNscJJ5CwVQuLgffQ0F+Mj4kuxpPu2bcHhTpbLcRo+ey2FIM0+2Tc2jirpBTJEZm8Opq W9HJ+QSoUCjiWSEAaGHhUxSMlYUIK8VUbIncqDZLuPb7OFyv4L+F0aeSueKiijyL9ur9OFlMEEj UU0Tce9yELoLTkgoWnHgN/7O4+zcW4N9Utv8Am7eTpFZJEsb/zJici6rAJxbSv2wHtMb1CW4gAv rSY4QPoUmSg8d7IUCPmyP01axW9rm2frYFHwTyvtKUchyPsdGN82V6umKqjiagjbyxY9maBF9PX tTFQdMq8c2dJiaeZ1loAtYmKrsAVcjuHf1irUVbJ+r0gSCD0Dwf/bMOK123Et4yVO9JHjl+cczi NEcNAAWhJaVxKHA6Pk55/6H6njuvCRsbzektOcVOb3+BQeJ5WNSyhlhx0UdsyaTo1ZrkKbww4o1 rZaQ6z/GhYpLQUcroXwHX+irhiRT7CJSFj77GFrAKrBhrAexXf3dxeh X-Received: by 2002:a05:620a:40d1:b0:939:6dfc:8abd with SMTP id af79cd13be357-93bdc7ab0bemr371381385a.52.1789743002924; Fri, 18 Sep 2026 07:50:02 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:29 +0000 Subject: [PATCH RFC v4 10/13] samples: ftrace: Make the direct-call trampolines Tasks Trace readers MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-10-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=13193; i=josef@toxicpanda.com; h=from:subject:message-id; bh=I7rYeQZ4spsxQVfaE2Sayb+dFXGxTZqIS2lZCUAJvtU=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QKXeVxQcH6ty+hUqDmOn27Ev2Cl/LtWOK4T4/1GJkZcNB9TzuskGzxBUIC7NaI2lvgHsCIRsimJ ERl1bJQ3J9QQ= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-42698a/1789743004-AA2C49EA-D3384BF3/0/0 X-purgate-type: clean X-purgate-size: 13195 The sample direct trampolines are exactly the kind of out-of-line register_ftrace_direct() user whose lifetime depends on Tasks RCU waiting for a task inside them: nothing else stops rmmod while a task is preempted in my_direct_func(). On HAVE_RCU_TRAMPOLINE_READERS architectures that wait only covers Tasks Trace RCU readers, so give the samples a small shared header with rcu_read_lock_trace() and rcu_read_unlock_trace() open-coded as instruction strings for x86-64 and arm64 -- the same sequences as ftrace_64.S and entry-ftrace.S, using caller-saved non-argument scratch registers -- and bracket every call-out with them. The instructions outside the bracket are module text, covered by ftrace_direct_mark_module(). Other architectures get empty definitions. Assisted-by: LLM Signed-off-by: Josef Bacik --- samples/ftrace/ftrace-direct-modify.c | 9 ++ samples/ftrace/ftrace-direct-multi-modify.c | 9 ++ samples/ftrace/ftrace-direct-multi.c | 5 ++ samples/ftrace/ftrace-direct-too.c | 5 ++ samples/ftrace/ftrace-direct.c | 5 ++ samples/ftrace/ftrace-direct.h | 126 ++++++++++++++++++++++++++++ 6 files changed, 159 insertions(+) diff --git a/samples/ftrace/ftrace-direct-modify.c b/samples/ftrace/ftrace-direct-modify.c index 164d9dd6fd92..937c8d8c2a1b 100644 --- a/samples/ftrace/ftrace-direct-modify.c +++ b/samples/ftrace/ftrace-direct-modify.c @@ -2,6 +2,7 @@ #include #include #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -73,7 +74,9 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " call my_direct_func1\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp1, .-my_tramp1\n" @@ -85,7 +88,9 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " call my_direct_func2\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp2, .-my_tramp2\n" @@ -141,11 +146,13 @@ asm ( " .globl my_tramp1\n" " my_tramp1:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #16\n" " stp x9, x30, [sp]\n" " bl my_direct_func1\n" " ldp x30, x9, [sp]\n" " add sp, sp, #16\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp1, .-my_tramp1\n" @@ -153,11 +160,13 @@ asm ( " .globl my_tramp2\n" " my_tramp2:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #16\n" " stp x9, x30, [sp]\n" " bl my_direct_func2\n" " ldp x30, x9, [sp]\n" " add sp, sp, #16\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp2, .-my_tramp2\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-multi-modify.c b/samples/ftrace/ftrace-direct-multi-modify.c index b03766c6217b..e12e5c8b83f0 100644 --- a/samples/ftrace/ftrace-direct-multi-modify.c +++ b/samples/ftrace/ftrace-direct-multi-modify.c @@ -2,6 +2,7 @@ #include #include #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -77,10 +78,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func1\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp1, .-my_tramp1\n" @@ -92,10 +95,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func2\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp2, .-my_tramp2\n" @@ -154,6 +159,7 @@ asm ( " .globl my_tramp1\n" " my_tramp1:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -162,6 +168,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp1, .-my_tramp1\n" @@ -169,6 +176,7 @@ asm ( " .globl my_tramp2\n" " my_tramp2:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -177,6 +185,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp2, .-my_tramp2\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-multi.c b/samples/ftrace/ftrace-direct-multi.c index 3fe6ddaf0b69..a970464ed378 100644 --- a/samples/ftrace/ftrace-direct-multi.c +++ b/samples/ftrace/ftrace-direct-multi.c @@ -3,6 +3,7 @@ #include /* for handle_mm_fault() */ #include +#include "ftrace-direct.h" #include #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include @@ -56,10 +57,12 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " movq 8(%rbp), %rdi\n" " call my_direct_func\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -101,6 +104,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -109,6 +113,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct-too.c b/samples/ftrace/ftrace-direct-too.c index bf2411aa6fd7..abc098c2ab7a 100644 --- a/samples/ftrace/ftrace-direct-too.c +++ b/samples/ftrace/ftrace-direct-too.c @@ -3,6 +3,7 @@ #include /* for handle_mm_fault() */ #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -61,6 +62,7 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " pushq %rsi\n" " pushq %rdx\n" @@ -70,6 +72,7 @@ asm ( " popq %rdx\n" " popq %rsi\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -110,6 +113,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #48\n" " stp x9, x30, [sp]\n" " stp x0, x1, [sp, #16]\n" @@ -119,6 +123,7 @@ asm ( " ldp x0, x1, [sp, #16]\n" " ldp x2, x3, [sp, #32]\n" " add sp, sp, #48\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct.c b/samples/ftrace/ftrace-direct.c index 5368c8c39cbb..99b65ad2fccc 100644 --- a/samples/ftrace/ftrace-direct.c +++ b/samples/ftrace/ftrace-direct.c @@ -3,6 +3,7 @@ #include /* for wake_up_process() */ #include +#include "ftrace-direct.h" #if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32) #include #endif @@ -54,9 +55,11 @@ asm ( " pushq %rbp\n" " movq %rsp, %rbp\n" CALL_DEPTH_ACCOUNT + TRACE_RCU_READ_LOCK " pushq %rdi\n" " call my_direct_func\n" " popq %rdi\n" + TRACE_RCU_READ_UNLOCK " leave\n" ASM_RET " .size my_tramp, .-my_tramp\n" @@ -97,6 +100,7 @@ asm ( " .globl my_tramp\n" " my_tramp:" " hint 34\n" // bti c + TRACE_RCU_READ_LOCK " sub sp, sp, #32\n" " stp x9, x30, [sp]\n" " str x0, [sp, #16]\n" @@ -104,6 +108,7 @@ asm ( " ldp x30, x9, [sp]\n" " ldr x0, [sp, #16]\n" " add sp, sp, #32\n" + TRACE_RCU_READ_UNLOCK " ret x9\n" " .size my_tramp, .-my_tramp\n" " .popsection\n" diff --git a/samples/ftrace/ftrace-direct.h b/samples/ftrace/ftrace-direct.h new file mode 100644 index 000000000000..726f67048ff5 --- /dev/null +++ b/samples/ftrace/ftrace-direct.h @@ -0,0 +1,126 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef _SAMPLES_FTRACE_DIRECT_H +#define _SAMPLES_FTRACE_DIRECT_H + +#include + +/* + * A direct-call trampoline is entered with no lock, refcount or RCU marker + * held; only Tasks RCU keeps it (and, for a module, its text) alive while a + * task is inside it or preempted in something it called. On architectures + * that select HAVE_RCU_TRAMPOLINE_READERS, Tasks RCU only waits for such a + * task while it is a Tasks Trace RCU reader, so the trampoline must enter one + * before calling out and leave it afterwards, exactly like the ftrace and BPF + * trampolines do. See register_ftrace_direct(). The instructions before the + * lock and after the unlock are covered by ftrace_direct_mark_module(). + * + * These are rcu_read_lock_trace() / rcu_read_unlock_trace() open-coded as + * instruction strings for use inside the samples' asm() trampolines, after + * the versions in arch/x86/kernel/ftrace_64.S and + * arch/arm64/kernel/entry-ftrace.S. The scratch registers are caller-saved + * and not argument registers, so they are dead on entry to and exit from an + * fentry trampoline; the flags are clobbered. + * + * The generated asm-offsets.h is only pulled in on the architectures that need + * it here: it is not generally safe to include from C (e.g. PPC32's TASK_SIZE + * and arm64's TRAMP_VALIAS clash with the C definitions). + */ +#if defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) && defined(CONFIG_X86_64) + +#include + +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB +#define TRACE_RCU_MB " lock addl $0, -4(%rsp)\n" +#else +#define TRACE_RCU_MB +#endif + +#define TRACE_RCU_READ_LOCK \ + " movq %gs:current_task(%rip), %r11\n" \ + " movl " __stringify(TASK_trc_reader_nesting) "(%r11), %r10d\n" \ + " incl " __stringify(TASK_trc_reader_nesting) "(%r11)\n" \ + " testl %r10d, %r10d\n" \ + " jnz 771f\n" \ + " movq rcu_tasks_trace_srcu_struct+" __stringify(SRCU_srcu_ctrp) "(%rip), %r10\n" \ + " incq %gs:" __stringify(SRCU_CTR_srcu_locks) "(%r10)\n" \ + " movq %r10, " __stringify(TASK_trc_reader_scp) "(%r11)\n" \ + TRACE_RCU_MB \ + "771:\n" + +#define TRACE_RCU_READ_UNLOCK \ + " movq %gs:current_task(%rip), %r11\n" \ + " movl " __stringify(TASK_trc_reader_nesting) "(%r11), %r10d\n" \ + " subl $1, %r10d\n" \ + " jnz 772f\n" \ + " movq " __stringify(TASK_trc_reader_scp) "(%r11), %r10\n" \ + " movl $0, " __stringify(TASK_trc_reader_nesting) "(%r11)\n" \ + TRACE_RCU_MB \ + " incq %gs:" __stringify(SRCU_CTR_srcu_unlocks) "(%r10)\n" \ + " jmp 773f\n" \ + "772: movl %r10d, " __stringify(TASK_trc_reader_nesting) "(%r11)\n" \ + "773:\n" + +#elif defined(CONFIG_TASKS_RCU_TRAMPOLINE_READERS) && defined(CONFIG_ARM64) + +#include +#include +/* arm64's asm-offsets.h redefines TRAMP_VALIAS from . */ +#pragma push_macro("TRAMP_VALIAS") +#undef TRAMP_VALIAS +#include +#pragma pop_macro("TRAMP_VALIAS") + +#ifndef CONFIG_TASKS_TRACE_RCU_NO_MB +#define TRACE_RCU_MB " dmb ish\n" +#else +#define TRACE_RCU_MB +#endif + +#define TRACE_RCU_SRCU_CTRP "rcu_tasks_trace_srcu_struct+" __stringify(SRCU_SRCU_CTRP) + +/* x14 = this CPU's offset; then atomically increment the long at x14 + \areg */ +#define TRACE_RCU_PERCPU_INC(areg) \ + ALTERNATIVE(" mrs x14, tpidr_el1\n", " mrs x14, tpidr_el2\n", \ + ARM64_HAS_VIRT_HOST_EXTN) \ + " add x14, x14, " areg "\n" \ + "778: ldxr x15, [x14]\n" \ + " add x15, x15, #1\n" \ + " stxr w16, x15, [x14]\n" \ + " cbnz w16, 778b\n" + +#define TRACE_RCU_READ_LOCK \ + " mrs x12, sp_el0\n" \ + " ldr w13, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + " add w14, w13, #1\n" \ + " str w14, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + " cbnz w13, 771f\n" \ + " adrp x13, " TRACE_RCU_SRCU_CTRP "\n" \ + " ldr x13, [x13, #:lo12:" TRACE_RCU_SRCU_CTRP "]\n" \ + " str x13, [x12, #" __stringify(TSK_TRC_READER_SCP) "]\n" \ + " add x13, x13, #" __stringify(SRCU_CTR_SRCU_LOCKS) "\n" \ + TRACE_RCU_PERCPU_INC("x13") \ + TRACE_RCU_MB \ + "771:\n" + +#define TRACE_RCU_READ_UNLOCK \ + " mrs x12, sp_el0\n" \ + " ldr w13, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + " subs w13, w13, #1\n" \ + " b.ne 772f\n" \ + " ldr x13, [x12, #" __stringify(TSK_TRC_READER_SCP) "]\n" \ + " str wzr, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + TRACE_RCU_MB \ + " add x13, x13, #" __stringify(SRCU_CTR_SRCU_UNLOCKS) "\n" \ + TRACE_RCU_PERCPU_INC("x13") \ + " b 773f\n" \ + "772: str w13, [x12, #" __stringify(TSK_TRC_READER_NESTING) "]\n" \ + "773:\n" + +#else + +#define TRACE_RCU_READ_LOCK +#define TRACE_RCU_READ_UNLOCK + +#endif + +#endif /* _SAMPLES_FTRACE_DIRECT_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425507.1649482 (Exim 4.92) (envelope-from ) id 1x7Zuj-0007Sf-Kj; Fri, 18 Sep 2026 14:50:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425507.1649482; Fri, 18 Sep 2026 14:50:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zuj-0007S9-G8; Fri, 18 Sep 2026 14:50:09 +0000 Received: by outflank-mailman (input) for mailman id 1425507; Fri, 18 Sep 2026 14:50:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zuh-0006wl-EH for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:50:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Zug-005xCM-Q6 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:50:06 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f98-2eae-0a2a0a5409dd-0a2a4506e5f6-22 for ; Fri, 18 Sep 2026 16:50:06 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f9d-195a-0a2a45060019-4a7de68c8bbd-3 for ; Fri, 18 Sep 2026 16:50:06 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-9106feddbdfso7373286d6.0 for ; Fri, 18 Sep 2026 07:50:06 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91258056195sm14090716d6.29.2026.09.18.07.50.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:50:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789743005; x=1790347805; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=MkP56mJgKixcgLXoBxrfzz0NyJo14L+hjKFrNfKE/2k=; b=oitv45/HloBF5CYKR9vhIZtUqRDyE9wkT8jqBe5a6FjD83th4tMWgDXs6ZPuHVzaGo s/OUrrts1mGXK82yUnFZHOgcee06h3U+sgGtYSORmIXbbZmsVXCcdjvdG9noDIIizFF7 aXPutAOcCnvtuIfZcza/8ltnD014/8jO1k+bEOkAQKrjAZ35x2N91zXSdgiwQlysXUi5 p1Y4PQ6Hb6vbpW4stLn3nFu7NFx1OPAGnGksN2w/ZpKp+C19Loo3owH4bDfy+AylwbTz AyJNGOEAKnRZNzFKIeO8jhufYU114pidolQ2b0nHnsMISR4vxjgeMicR3SyI8xqvJ7MZ Rw5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789743005; x=1790347805; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=MkP56mJgKixcgLXoBxrfzz0NyJo14L+hjKFrNfKE/2k=; b=blJmUlnEUnlsGpB4gaepRr0B6pGeW7LPJ30fAHj7fEk/DGExBiZLxYFJtX/2uW6StV VpIZSzBpRjQSTn2EvaywuDXS2YhXMC3rrv2oEIrgaGa3IZf+nOSAZ7QweydDGlbIMtWm nG26hooxRRxKg6SOUxoPWJMdNsoQuCPXa2EXujpQhJBBnk3vYDOLrVtsE5kij72bIPqB R5LVqC1yzN4S9Omps/xv9GRkZ6BqCBB/mJ3FNB6Vfs3o78K3LuwAgHjCCD31PbWvoLUD iIJLPGLuBkfnYDgKet77F5dXtzYom1EA/jdkj4WndVXv0p6v9WpM+kPWZpphPGVRgLYi SR6w== X-Forwarded-Encrypted: i=1; AKwUvBxPp3qy9MYE/peqXud2H/WCiiDAE3v3EOZEzOeSE1y3PLNNUlymMsha2Xnk0BWSzq6IuDsb3B1Zwa8=@lists.xenproject.org X-Gm-Message-State: AFuF++mgWSFL2yaS7auHh5qR8JcjYIl8HNTZn3Se3ai0UNvtpMsOVis7 ATuC4oVdnazr2Uyy4lufTJRWDrZisg4P060VkO3fPXWg0sYvP3nrwH0h4gd1Tt7WYFM= X-Gm-Gg: AYBFou0+i9qUED7OOSvGQOANgA1VaRLWpjehkIqc4C6t9knRt1WYKAAScc0sIXoboe+ K9NdEhaRQOdnmrU8t/Bm9vWc0mo1k6CqujQnq8wbSH3jlC48pzzr8lK3RG1sUF52VJQicFvf150 j1auIz1L9OHrzwckWmsoJJ5xKCyiMM1D63Nebsaj1rrsk4VZ2ueV64kJUqoW0yBITvopOhogklY dYZp7oKGbwWNy6aBYTCMi23M9Q8UXqJaO8UkuCwnn1ad5yjr5QI60T+I+TWPBd00cUX2UCiQwbk X48p6UUrmTILG1asERygmU0x/rPi5Jjf5rw7Pa2Z57Yskh3zSX2wiFnI+2RQcE/QjQbkondi/V6 GjqFE9XEyNd44HHOtWAObhNbRHkXFkkLMY+6lbUBiI+9KbqsAqXe0i5K/fvPOXOr3T0PvlcCadf RuWOh4vE+ym8OVhTgjco1lnIvmIwoBbg3O6OxoJCbfJKPSC6R7b1lOejTzOugKiI/FXDDA7MvRq DlJGP2wydbDRVtDmtKmMJYV5hA+xiI++pV2ACsK3U4SRidDpelpu8ux X-Received: by 2002:a05:6214:1307:b0:910:4a86:5969 with SMTP id 6a1803df08f44-91254bd5293mr46077526d6.23.1789743004909; Fri, 18 Sep 2026 07:50:04 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:30 +0000 Subject: [PATCH RFC v4 11/13] rcutorture: Make Tasks RCU readers Tasks Trace readers where required MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-11-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=1716; i=josef@toxicpanda.com; h=from:subject:message-id; bh=O8YdW4YSHUYyF3GwEQN16WzJM7UkZZFfh8RzVwv7xJM=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QCK2SKWNSvb8uUIHABRfNQrEJPCWCZeIZnAqX/3f5X/BpUmomCy4y1MVWrdYzX/ihyvEJhShdIA kincQ831+1ws= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-16d1c6/1789743006-FE47377B-DAF0A557/0/0 X-purgate-type: clean X-purgate-size: 1718 rcutorture's "tasks" flavor has empty readlock/readunlock hooks because a classic Tasks RCU reader is simply code that does not block. Under CONFIG_TASKS_RCU_TRAMPOLINE_READERS a preemption outside trampoline text is also a quiescent state, and the thing real readers (trampolines) do to stay protected across their call-outs is take rcu_read_lock_trace(), so have the torture readers do the same there. Otherwise a preempted torture reader would rightly be treated as quiescent and the test would report false-positive too-short grace periods. Assisted-by: LLM Signed-off-by: Josef Bacik --- kernel/rcu/rcutorture.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index 794937e13e7c..ab870ef09af0 100644 --- a/kernel/rcu/rcutorture.c +++ b/kernel/rcu/rcutorture.c @@ -1142,13 +1142,23 @@ static struct rcu_torture_ops trivial_preempt_ops = { * Definitions for RCU-tasks torture testing. */ +/* + * A classic Tasks RCU reader is any stretch of kernel code that does not + * voluntarily block. With CONFIG_TASKS_RCU_TRAMPOLINE_READERS a preemption + * outside trampoline text also ends it, and what a trampoline does to stay + * protected across its call-out is take a Tasks Trace reader, so model that. + */ static int tasks_torture_read_lock(void) { + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_read_lock_trace(); return 0; } static void tasks_torture_read_unlock(int idx) { + if (IS_ENABLED(CONFIG_TASKS_RCU_TRAMPOLINE_READERS)) + rcu_read_unlock_trace(); } static void rcu_tasks_torture_deferred_free(struct rcu_torture *p) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425509.1649488 (Exim 4.92) (envelope-from ) id 1x7Zuk-0007a9-E3; Fri, 18 Sep 2026 14:50:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425509.1649488; Fri, 18 Sep 2026 14:50:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zuk-0007Yo-4D; Fri, 18 Sep 2026 14:50:10 +0000 Received: by outflank-mailman (input) for mailman id 1425509; Fri, 18 Sep 2026 14:50:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zui-0007GO-Jh for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:50:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Zui-009ha3-0e for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:50:08 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f96-e002-0a2a0a5209dd-0a2a450294da-18 for ; Fri, 18 Sep 2026 16:50:08 +0200 Received: from [74.125.230.141] (helo=mail-qv2-f13.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4f99-6ca4-0a2a45020019-4a7de68d8058-3 for ; Fri, 18 Sep 2026 16:50:02 +0200 Received: by mail-qv2-f13.google.com with SMTP id 6a1803df08f44-90cdfc9b6e3so9327956d6.1 for ; Fri, 18 Sep 2026 07:50:02 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93be0e95a4asm151763985a.18.2026.09.18.07.49.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:49:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789743001; x=1790347801; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Q8bPS+4IlAeB++9fkK/U7jkDL1GJ1oJuOJz5hfsv6cg=; b=Wwprqy+zlj0lZVzG+Bme27kUhv6Qvn/3LCKyK4nmM7Ejxm+MFWSp25P3ipS5JT9eV2 Igs9p1phJetTI2qFzl/AhrSHwz9dA1+HG7WyXwCe0IcEVJCUKCoqmGvLal26JfmKJrwo +qp5sSVGVMk4Ric6dwSyJktF7QMXcdO6RZPB1sbPvYNe9ztZgBBNRqgtutA1EW/tRomL kSYA65y0hPgaQGyoXnOPoWpJhFfc9d6l6al5duIbJDO+dFQvtX2jxX1vUIOmL7PsW1fz jFre/LyX+ZJ3ZKHyZ7K7Q+vTagyvfVwji7rL+UU/Hd97lizKTakoKbGkNUrH2Ma4HlqG rpdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789743001; x=1790347801; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Q8bPS+4IlAeB++9fkK/U7jkDL1GJ1oJuOJz5hfsv6cg=; b=bfBuoQrKuy3tTYsTgj73mAVtjEc/JfFq3D4SdFk+8CWlIPujqWYyh4SVD/hpAIxsoi 4ffnJqHTZ2S+r9I8udaa9iBEZxVJCqSUBVvKyFbgiA5a/MOs9a9Jjb3XHNX7pDsOWPQI jgDHL2ICzB5PT17GaoFGjJ1tSxWCdYVoJkPCbzlwGOCtreUIeIN1ICeIfBPyrgyHIym8 keVkD2tiD+OevxI7kGEtkJQOMWxK5H20b5i+nBhH1eZnfHaYD1HrkhwEAmp8/YmRmdML CiDuMR2vKf1QIBfup/4xqydDFBxcRwzJBKUTBDGBntiWY2EZdg7ytGQIRtNETJM6syOM daqg== X-Forwarded-Encrypted: i=1; AKwUvBzR/duahPry7kFyipESCKxNUXlHlC2l6fFGRmg5+pkOiVnbdkEwfi+9HoEJsQT1Eizcz/zpbvYQENg=@lists.xenproject.org X-Gm-Message-State: AFuF++kxlk5tftl4WyE/FYwElwGV41z59V7SXHWMYI/VxpaTCwQcXird zeHfnTn483Z9jSm9pZ6qnm2/UgAtp7U8piQO5s7zjjBU3Jjt9D/Tmp8jHLqQLlOgWSA= X-Gm-Gg: AYBFou3e+LWt/prxi1OQbP70P35F2nXVDsy07oV4b1OURlay3SN20wmjg5LMiAtCgAn Nc9vz5XwlIiEAEJhOn2qwFAgj56ljxDg794sTZiLC/d9Jp69sWl5shWKCXbT+k3+h3rmT651itE x0uZvIIZbvM3KSBlqIxlcOnJKPyrz7Jf5RpZ+ZYxU0J8xU7Oag8zefQ3Qi0Web+FPqUkaM2X46y LbFyib72iuBtmNGU1T28ji5bu4KgPfCO1fTJ1e1wqsbXa8nXrFCYWVBb/SxvgX7p5xster0lvQb BEHA0/yLBL1eq7ZJvLCwELed3zbA4fkbggKDyV4BzL0mTV88n+jRA/FVKv2t//j+DsiCUciHb8A RP67wMU2JTYRIHDGNfwDVLFptJXjcJSN7slyk+z1HlpgkVSoT58caMCN4ruhohYCLpz2mKGwcX8 ZGQ4+iYURNOd6QIKRHR/MUeNACI3Vc2JUlnDiAF+OVGBiePOVrzAjWqzu+bj+k7X6KDvfCsroUS DhcPyOPeY8VtQ0PSDmbEtCqbcQqyA5JvninXGvrBasF1L9L3MuRGPiT X-Received: by 2002:a05:620a:a2c1:20b0:93b:e9d2:5ece with SMTP id af79cd13be357-93be9d25ee8mr69803785a.39.1789743000697; Fri, 18 Sep 2026 07:50:00 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:28 +0000 Subject: [PATCH RFC v4 09/13] bpf, arm64: Take a Tasks Trace reader in the trampoline around its call-outs MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-9-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=7138; i=josef@toxicpanda.com; h=from:subject:message-id; bh=yHC4KMZfT4OhoIiDiBb7tvVf2glio0Mt2yiw+oyROR0=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QMextWmuyzGMJVeNI8yxyv6Z0gZzWAgn/7KthFAEN2WlTA4mSkVfiREApm3yp97Xx2XO4eWHESm TkxgsjmQ6cwg= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1789743002-F14AE2AC-8470F112/0/0 X-purgate-type: clean X-purgate-size: 7140 Same scheme as x86: have the arm64 BPF JIT open-code rcu_read_lock_trace() and rcu_read_unlock_trace() in the trampoline, one reader from after the callee-saved registers are stored to just before the original function is called (covering __bpf_tramp_enter() and the fentry/fmod_ret programs) and a second from just after it returns to just before those registers are restored (covering the fexit programs and __bpf_tramp_exit()), with the original function itself outside both and pinned by im->pcref. The second reader is entered before ip_after_call and the fmod_ret cbnz lands past it still holding the first, so exactly one is held on every path; trampolines without an original call get a single reader. The sequence mirrors entry-ftrace.S: current via sp_el0, trc_reader_nesting bumped, and for the outermost reader the SRCU-fast per-CPU counter incremented LL/SC and the counter pointer stashed in trc_reader_scp (plus the dmb when CONFIG_TASKS_TRACE_RCU_NO_MB is not set). x10-x15 are scratch at every emission point. Nothing is emitted on other configurations. Suggested-by: Alexei Starovoitov Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/arm64/net/bpf_jit_comp.c | 90 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index c18e005a41db..87f9d53caf2c 100644 --- a/arch/arm64/net/bpf_jit_comp.c +++ b/arch/arm64/net/bpf_jit_comp.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -2591,6 +2592,74 @@ static void emit_arena_arg_conv(struct jit_ctx *ctx, u8 dst, u8 src, bool nullab emit(A64_SUB(0, dst, src, base_lo), ctx); } +/* + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace() for the + * trampoline, see CONFIG_HAVE_RCU_TRAMPOLINE_READERS and the equivalent macros + * in arch/arm64/kernel/entry-ftrace.S. The SRCU-fast per-CPU increment is an + * LL/SC add on this CPU's counter; being migrated between reading the per-CPU + * offset and the store-exclusive only means another CPU's counter is + * incremented atomically instead, which SRCU sums over anyway. Uses x10-x15, + * which are scratch at every emission point, and the flags. + */ +static void emit_trace_rcu_reader(struct jit_ctx *ctx, bool lock) +{ +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS + const int nesting = offsetof(struct task_struct, trc_reader_nesting); + const int scp = offsetof(struct task_struct, trc_reader_scp); + const bool mb = !IS_ENABLED(CONFIG_TASKS_TRACE_RCU_NO_MB); + const u8 tsk = A64_R(10), n = A64_R(11), tmp = A64_R(12); + const u8 ctr = A64_R(13), addr = A64_R(14), val = A64_R(15); + + BUILD_BUG_ON(IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE)); + /* LDR/STR (immediate, unsigned offset) ranges */ + BUILD_BUG_ON((nesting & 3) || nesting >= SZ_16K || (scp & 7) || scp >= SZ_32K); + + emit(A64_MRS_SP_EL0(tsk), ctx); /* current */ + emit(A64_LDR32I(n, tsk, nesting), ctx); + if (lock) { + emit(A64_ADD_I(0, tmp, n, 1), ctx); + emit(A64_STR32I(tmp, tsk, nesting), ctx); + /* interrupted a reader: done */ + emit(A64_CBNZ(0, n, 12 + mb), ctx); + /* scp = rcu_tasks_trace_srcu_struct.srcu_ctrp; current->trc_reader_scp = scp */ + emit_addr_mov_i64(ctr, (u64)&rcu_tasks_trace_srcu_struct.srcu_ctrp, ctx); + emit(A64_LDR64I(ctr, ctr, 0), ctx); + emit(A64_STR64I(ctr, tsk, scp), ctx); + } else { + emit(A64_SUB_I(0, n, n, 1), ctx); + /* still nested: just store the count */ + emit(A64_CBNZ(0, n, 11 + mb), ctx); + /* outermost: pick up scp before an interrupt can see nesting == 0 */ + emit(A64_LDR64I(ctr, tsk, scp), ctx); + emit(A64_STR32I(A64_ZR, tsk, nesting), ctx); + if (mb) + emit(A64_DMB_ISH, ctx); + } + /* this_cpu_inc(scp->srcu_locks / srcu_unlocks) */ + if (cpus_have_cap(ARM64_HAS_VIRT_HOST_EXTN)) + emit(A64_MRS_TPIDR_EL2(addr), ctx); + else + emit(A64_MRS_TPIDR_EL1(addr), ctx); + emit(A64_ADD(1, addr, addr, ctr), ctx); + if (!lock) + emit(A64_ADD_I(1, addr, addr, offsetof(struct srcu_ctr, srcu_unlocks)), ctx); + emit(A64_LDXR(1, val, addr), ctx); + emit(A64_ADD_I(1, val, val, 1), ctx); + emit(A64_STXR(1, val, addr, tmp), ctx); + emit(A64_CBNZ(0, tmp, -3), ctx); + if (lock) { + if (mb) + emit(A64_DMB_ISH, ctx); + /* 1: */ + } else { + emit(A64_B(2), ctx); + /* 2: */ + emit(A64_STR32I(n, tsk, nesting), ctx); + /* 3: */ + } +#endif +} + static void save_args(struct jit_ctx *ctx, int bargs_off, int oargs_off, const struct btf_func_model *m, const struct arg_aux *a, bool for_call_origin, bool is_struct_ops, u64 arena_base) @@ -2854,6 +2923,16 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, emit(A64_STR64I(A64_R(19), A64_SP, regs_off), ctx); emit(A64_STR64I(A64_R(20), A64_SP, regs_off + 8), ctx); + /* + * Tasks RCU keeps this image alive only while we are a Tasks Trace + * reader; the instructions before this point (and after the final + * unlock) are covered by the irq-exit IP check. One reader spans + * __bpf_tramp_enter() and the fentry/fmod_ret progs, a second one the + * fexit progs and __bpf_tramp_exit(); the original function runs + * outside both, with the image pinned by im->pcref instead. + */ + emit_trace_rcu_reader(ctx, true); + if (flags & BPF_TRAMP_F_CALL_ORIG) { /* for the first pass, assume the worst case */ if (!ctx->image) @@ -2898,12 +2977,20 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, if (flags & BPF_TRAMP_F_CALL_ORIG) { /* the original func takes kernel addresses, never converted ones */ save_args(ctx, bargs_off, oargs_off, m, a, true, is_struct_ops, 0); + emit_trace_rcu_reader(ctx, false); /* call original func */ emit(A64_LDR64I(A64_R(10), A64_SP, retaddr_off), ctx); emit(A64_ADR(A64_LR, AARCH64_INSN_SIZE * 2), ctx); emit(A64_RET(A64_R(10)), ctx); /* store return value */ emit(A64_STR64I(A64_R(0), A64_SP, retval_off), ctx); + /* + * Second reader. Taken before ip_after_call so that the branch + * to the epilogue patched in at teardown is inside it too; the + * fmod_ret early exit lands past this still holding the first + * reader, so either way exactly one is held. + */ + emit_trace_rcu_reader(ctx, true); /* reserve a nop for bpf_tramp_image_put */ im->ip_after_call = ctx->ro_image + ctx->idx; emit(A64_NOP, ctx); @@ -2945,6 +3032,9 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im, if (flags & BPF_TRAMP_F_RESTORE_REGS) restore_args(ctx, bargs_off, a->regs_for_args); + /* Remaining instructions are covered by the irq-exit IP check. */ + emit_trace_rcu_reader(ctx, false); + /* restore callee saved register x19 and x20 */ emit(A64_LDR64I(A64_R(19), A64_SP, regs_off), ctx); emit(A64_LDR64I(A64_R(20), A64_SP, regs_off + 8), ctx); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425514.1649500 (Exim 4.92) (envelope-from ) id 1x7Zum-00089q-KA; Fri, 18 Sep 2026 14:50:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425514.1649500; Fri, 18 Sep 2026 14:50:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zum-00089d-E4; Fri, 18 Sep 2026 14:50:12 +0000 Received: by outflank-mailman (input) for mailman id 1425514; Fri, 18 Sep 2026 14:50:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zul-0007jO-12 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:50:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Zuk-00H86X-Dy for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:50:10 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f95-bab6-0a2a0a5309dd-0a2a450c97a2-30 for ; Fri, 18 Sep 2026 16:50:10 +0200 Received: from [74.125.230.140] (helo=mail-qv2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4fa1-f479-0a2a450c0019-4a7de68c96db-3 for ; Fri, 18 Sep 2026 16:50:10 +0200 Received: by mail-qv2-f12.google.com with SMTP id 6a1803df08f44-910704e63a9so3889226d6.0 for ; Fri, 18 Sep 2026 07:50:10 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9125802d79bsm13900886d6.24.2026.09.18.07.50.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:50:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789743009; x=1790347809; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=z+PbvTl7j6crAVqwwSi1N6wOs6bBuNm88XPaAXlYwG4=; b=sXcL3pFGVgeuE0lXG7/9XBlY3HQ6gJKvg/8Cc9C2cksY/3BQejrWKQVq71UmsJcDu4 CP0Pdmso4SjOcKtX3/gJYP2BN3uRYxe9+0Hw6MtTA1bKV9hjeQJ30vmGcAEmpWhYDNyl U+fN0GnGjLw0XH/x6L3oKEpkAlVI2nv8Oz3LIi1CeuaE4e9Ie1AZ7Hy8s5e2tW1t8lnS kG7i0kNUuW8nNvUVvYlgdsxw9NtKVhLZiZWIbDry8yTXfz18FcNnZOEixj2UqysuaU5w 9J5ffXJWSFKjE7cyqhmaCQ8ZLkscQ97E72/7DPxA1m4rSNQYtIkrY9Tdt6bWjuBF4wFL 0BIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789743009; x=1790347809; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=z+PbvTl7j6crAVqwwSi1N6wOs6bBuNm88XPaAXlYwG4=; b=yElr8aszEA56Prl1trERMJauTUY04i3pDQnZNbOdaXcYYxTX+FVpt+6k2NfwxQxQyF X8nEXcZMpKks/+OM0Y0mhLBE5joIXfU3j5LXTJ/HG2nxtzUZDoC9qP5nJxNUhb+Gs3Vo lIdGIaOZdmF8Az3OVtcnGIEItLqZM+lcTaxad7rmDYuuZm6ce0sem43feMGR+sZijHnh 9Wn/L5JTFxP8skwGHM0C5u6kK36rmj/5Wcou/BUoaC48LTlXsX8nBxopKFVFXih5zW8k 87JDPvF70ElJfffMlNHbiDKV5sqwqXV+fdyoGukIfPXOpJZCU0Izo+Q4zcCGMfFIgQxJ dC5A== X-Forwarded-Encrypted: i=1; AKwUvBwiZtVVEZkU6vRCIkQlehdbJEiC9owMB/5VXZ4okBKze6BONqVeixNBZDuYYrTI2r7oQDgN2PDKoag=@lists.xenproject.org X-Gm-Message-State: AFuF++kJFpR6BmRhYwRKuHe7bS5Xzuo1JSkFLjA+9dGJOXTRMp4s/bSx NnWHo65jSMqqSSDQAXqadHAYwcp3o2h2XfUhXdfqHS4DUC/P/8XqSNtEbE5KLAfANtY= X-Gm-Gg: AYBFou2yN94QrQph2i8CxR89mH7czovlVxrdHQITrsrQ0Pml2zpnpNOP6gQfzq2Cwi9 ud5ATIYO7DASxMJ/hUZT/gDRnEWk/FXdUCJTYa+LtCYcmjJBdo3WGZi92oLFiZAoAhKmHq42Lvh Ea93pkbG7WrMLBk7dupZqlBsveK5m/PiB122K8SMKmzZDUPfJ+m8gZrouFiiXLNVVll77ISAXXH 2aD/55rh+T/L8CP2lJgyGKrcGjX7HvL+AVcisA27IXElOykfhJYxXcbyitrjIzH4NXRl6D2JAGi xW/XnBbtg8xhyluoN+spT9Dam0hXggZIEfpuQ2Ri1IAyiWSeuRkKruFmZh/IdVoRIlfKMP/y9Uh zoAVvqpiQsy8BNPSoPFU8uOVeyfJRt1cuCDJw9Wm+MjY8s64PDUqgN+T5CjXOPvTZs+Hqatjsfx qV0r9lcJSMUBAUp3ftVIbo82QWY9Nfj95Mg/J1wZkj6MsIaIgaHz+jUnA+ac9l0j8ncIlSvOn49 yEfhD2gUSUR93hbjiS1ajQT7YjmKyTCodIz+ekGxCZY3N222ucaXh7hfA== X-Received: by 2002:a05:6214:ca6:b0:912:3d05:eb11 with SMTP id 6a1803df08f44-91254e4feadmr40041586d6.5.1789743008667; Fri, 18 Sep 2026 07:50:08 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:31 +0000 Subject: [PATCH RFC v4 12/13] rcu-tasks-trace: Assert no reader is held on return to userspace MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-12-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=2581; i=josef@toxicpanda.com; h=from:subject:message-id; bh=FRa7j81kn+FZifN+tU/RXt2NlHMQaOXWqjJvWoyULIE=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QAsi6H715Q7GMOS9YXNtKesBwx2lesjeCIIWVvPLg8W7bMTSPfSKqF2zG8KnHJqpv18BR10X5Rc 7g2eq40cmPAk= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-d25034/1789743010-00ECAA5B-BB1B51ED/0/0 X-purgate-type: clean X-purgate-size: 2583 With trampolines now taking rcu_read_lock_trace() open-coded from assembly and JIT-emitted code, an unbalanced reader would silently turn every later Tasks Trace grace period on that task into a stall. No task can legitimately reach userspace with current->trc_reader_nesting non-zero, so under CONFIG_PROVE_RCU check it in the generic entry code's return-to-user validation, next to the existing kmap and lockdep assertions. Compiles away otherwise. Assisted-by: LLM Signed-off-by: Josef Bacik --- include/linux/irq-entry-common.h | 2 ++ include/linux/rcupdate_trace.h | 7 +++++++ 2 files changed, 9 insertions(+) diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index e19b41ee6b18..d42568a488a7 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -214,6 +215,7 @@ static __always_inline void __exit_to_user_mode_validate(void) { /* Ensure that kernel state is sane for a return to userspace */ kmap_assert_nomap(); + rcu_tasks_trace_assert_idle(); lockdep_assert_irqs_disabled(); lockdep_sys_exit(); } diff --git a/include/linux/rcupdate_trace.h b/include/linux/rcupdate_trace.h index 273c59a03251..6034c6b19479 100644 --- a/include/linux/rcupdate_trace.h +++ b/include/linux/rcupdate_trace.h @@ -211,6 +211,12 @@ unsigned long rcu_tasks_trace_batches_completed(void); // Placeholders to enable stepwise transition. void __init rcu_tasks_trace_suppress_unused(void); +/* A task must never reach userspace inside an rcu_read_lock_trace() reader. */ +static inline void rcu_tasks_trace_assert_idle(void) +{ + WARN_ON_ONCE(IS_ENABLED(CONFIG_PROVE_RCU) && READ_ONCE(current->trc_reader_nesting)); +} + #else static inline unsigned long rcu_tasks_trace_batches_completed(void) { return 0; } /* @@ -220,6 +226,7 @@ static inline unsigned long rcu_tasks_trace_batches_completed(void) { return 0; static inline void call_rcu_tasks_trace(struct rcu_head *rhp, rcu_callback_t func) { BUG(); } static inline void rcu_read_lock_trace(void) { BUG(); } static inline void rcu_read_unlock_trace(void) { BUG(); } +static inline void rcu_tasks_trace_assert_idle(void) { } #endif /* #ifdef CONFIG_TASKS_TRACE_RCU */ DEFINE_LOCK_GUARD_0(rcu_tasks_trace, -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 14:50:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 14:50:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425520.1649510 (Exim 4.92) (envelope-from ) id 1x7Zup-0000Fu-TQ; Fri, 18 Sep 2026 14:50:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425520.1649510; Fri, 18 Sep 2026 14:50:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zup-0000FE-Ol; Fri, 18 Sep 2026 14:50:15 +0000 Received: by outflank-mailman (input) for mailman id 1425520; Fri, 18 Sep 2026 14:50:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7Zuo-0008PH-2F for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 14:50:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7Zun-00H86X-Ev for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:50:13 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad4f8a-bab6-0a2a0a5309dd-0a2a4504a334-32 for ; Fri, 18 Sep 2026 16:50:13 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad4fa3-b57f-0a2a45040019-4a7de6ccf00b-3 for ; Fri, 18 Sep 2026 16:50:12 +0200 Received: by mail-qk2-f12.google.com with SMTP id d75a77b69052e-52fb76ef19aso7956491cf.2 for ; Fri, 18 Sep 2026 07:50:12 -0700 (PDT) Received: from toxicpanda.com (ec2-34-228-114-98.compute-1.amazonaws.com. [34.228.114.98]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-532aac41311sm5612191cf.10.2026.09.18.07.50.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:50:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1789743011; x=1790347811; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=A8c5rUXaTXu9B0UqDL2lNbjmJqabE8+fQOLsAHyr+Co=; b=RrtbBLuO81ggjT/jg5rcGpFCBb1wap4lt4eXzYssx9gOx7qVYHx84f8IvvVH1C2n3v 0J1H4hsfijtC7dNtXattJ5A6krhl8fKegVIFA23L+QL5B8Hfj62ICcKGUgWgLFARS06d C7HqyvzRottBa7PMJew8i6x2j9ihU43a4Py1ku8p9X3+4U3HNyGtpQZ9VC91ACBIYRCR oRbSVXFJk0dLNXKVuqsYDwsQBJrUQ+X7o93FL554ayaoQsjZg1Tw6AYnIvs4AjmhPOYJ fQGySwmYTXTcfW/h485ZLE8ehGAG25PCpzQX79lDWKeBoA+VJ3tpKUre/YUSV0udvfGd 06nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789743011; x=1790347811; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=A8c5rUXaTXu9B0UqDL2lNbjmJqabE8+fQOLsAHyr+Co=; b=nhMGYRJyGWTGsimErcPGAK1ElO2mPEv2z58HBGb7Bar8rNpoVK1ug8+NV1wf/idwAi 5vUEe7f91oACy82rigJL4MopcTuaOZaLDX2LyApa05i9mgUqopbcV115/rnmRP1wd27c iT4yYSYa06k1wvSW2i9BoPKQbi5AIYq9RIRDKjwzCO7zfy3+J477Mazcg/rMw3dDe4HS kU8oA7Fx9ULoJQvaC25e5PlMW/St4SBFaX/0PhOQdIMQKpah0rBuELNK9nspFnMzZM/G k5NFxFyc9W8weylywa8mGJBxkoBqCUJwl7TOec/eA4jSPNj6x+wFP9sJjk9QKOtenooY gd/Q== X-Forwarded-Encrypted: i=1; AKwUvBzLJ0ClcwmEhbaH/EEGEulrLJynphdvS59tKbVavZj0Dyo/v+VjAw9rWiKxgYGUG6IEvzrfWejp1SE=@lists.xenproject.org X-Gm-Message-State: AFuF++nh32iyUUkfy2T0EcZzb1/plmokomv3Llw7w0ALPeYt8zpGmx7u jRmm2ImG/K+hkkYbfpAj5HPDY6eooB++cQX3RTTDxPOSnS9IUbugDFpntlxmpVYtUg0= X-Gm-Gg: AYBFou3opspiqGHuinxLW9/VWtOwi6iQEiJx9RleWrXhQKilwFDTOzcZznzEVneTckt hBHQ5XoceIjp3r4wOi2InsORlVI+zSpb27iwSgeT5f5xZRU0PD57QDj3K2ssD07AwK6d3obIRcZ CGBRoe0YLb8DkbY2BD3ze/RsGO+fELyi9I5pYl9z/BRW/bq0/E+fqdR8dLF9bt7EV8OfhhEiGGL VELt8KKGbJnoB6Bzo3LcmpincNICe/SMnADhOrHj/WaY/1YPHnG0NYCWlwc3NKAXjRO4BpkV9nX l7U/4odmM2/v0ixAlGjkdFwvA8/s2ZhNQZt2OeKJyhCox2H3PbrCw3Moew2P3QQwN+pEnP8KJ2a 24LdsAwVTG/wCl/+DDyG3X06uFqyFAZavQUFIinW4/T+mqTy5pADH/dq7oY5Ns0VFeZ35/Kti2T /FHbYk68TMBT7MAf/IhBGSIgFAwx6mw0rn9XRRJQqJgUZcZ0EWEa1dP6A0EcoU421+WznYCx1KK X3jFKV8zieDgd9jXi2mK/PcS1nX8CovegCmPFUVCnuMvpGr/w5CabcM X-Received: by 2002:a05:622a:2606:b0:532:9add:50bb with SMTP id d75a77b69052e-5329e402a69mr42121701cf.75.1789743010763; Fri, 18 Sep 2026 07:50:10 -0700 (PDT) From: Josef Bacik Date: Fri, 18 Sep 2026 14:49:32 +0000 Subject: [PATCH RFC v4 13/13] x86, arm64: Build Tasks RCU on Tasks Trace readers in trampolines MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260918-b4-rcu-tasks-preempt-qs-v4-13-63f0e9d69661@toxicpanda.com> References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1789742980; l=6284; i=josef@toxicpanda.com; h=from:subject:message-id; bh=VsJyzZYJ6ksShlnC7Yiz29R4LafGY+0/mhkU2yBL4O8=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QEwAhBVideBDLteTwvOfpHAYkoAWUm3JvOEwqQNA35GYhU6H/frrHaAxlVzl5POPAnXUpm7Q7V1 WCFlv6PR8OAI= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-ebf023/1789743012-502E4B50-B2ABC6E4/0/0 X-purgate-type: clean X-purgate-size: 6286 With the preceding patches every trampoline whose lifetime Tasks RCU guards on x86-64 and arm64 -- ftrace_caller and its copies, the optprobe template, BPF trampolines, and the sample direct-call trampolines -- is a Tasks Trace RCU reader around its call-out, and the text outside that reader is known to rcu_tasks_trampoline_text(). Select HAVE_RCU_TRAMPOLINE_READERS on both (x86-64 with SMP for Tree SRCU and DYNAMIC_FTRACE, which is where its ftrace_caller changes and arch_rcu_tasks_trampoline_text() live; arm64 with DYNAMIC_FTRACE_WITH_ARGS likewise), which switches CONFIG_TASKS_RCU to the implementation added earlier in the series: a Tasks RCU grace period becomes a per-CPU pass over context switches and irq-exit reschedules outside trampoline text plus a Tasks Trace grace period, bounded by a few jiffies and preempt-off latency instead of by the longest stretch any task runs without sleeping. Other architectures keep the classic implementation. Update Documentation/RCU and the FORCE_TASKS_RCU help text to describe the variant and the obligation it places on trampolines. Assisted-by: LLM Signed-off-by: Josef Bacik --- .../RCU/Design/Requirements/Requirements.rst | 24 ++++++++++++++++++++++ Documentation/RCU/checklist.rst | 7 ++++++- arch/arm64/Kconfig | 1 + arch/x86/Kconfig | 1 + kernel/rcu/Kconfig | 6 ++++-- 5 files changed, 36 insertions(+), 3 deletions(-) diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 8101fe6229d5..c059c463e083 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -2756,6 +2756,30 @@ synchronize_rcu(), and rcu_barrier(), respectively. In three APIs are therefore implemented by separate functions that check for voluntary context switches. +Architectures that select ``CONFIG_HAVE_RCU_TRAMPOLINE_READERS`` keep the +same three APIs but implement the grace period differently +(``CONFIG_TASKS_RCU_TRAMPOLINE_READERS``). There, every trampoline whose +lifetime Tasks RCU guards enters a Tasks Trace RCU read-side critical +section (rcu_read_lock_trace() or its assembly equivalent) before calling +out and leaves it before returning, so a task anywhere inside such a +call-out is an ordinary Tasks Trace reader whether or not it is +preempted. The few trampoline instructions outside that reader can only +be occupied by a task that was interrupted there, so the grace period +additionally waits for each CPU to pass through a context switch, and the +irq-exit preemption path, the only switch that can catch a task inside +such text (rcu_tasks_trampoline_text()), briefly makes such a task a +holdout until it is next seen elsewhere. On such kernels an involuntary +context switch outside trampoline text *is* a Tasks-RCU quiescent state, +a Tasks RCU grace period no longer depends on how long any task runs +without sleeping, cond_resched_tasks_rcu_qs() is unnecessary, and the +obligation moves to the trampolines: anything that relies on +synchronize_rcu_tasks() to protect code a task may be preempted in must +take the Tasks Trace reader (see register_ftrace_direct()), or, where +that is impossible because the code is ordinary text with no trampoline +of its own, make it known to rcu_tasks_trampoline_text() and wait out +tasks already parked there with rcu_tasks_wait_irq_preempted(), as the +kprobe jump optimizer does. + Tasks Rude RCU ~~~~~~~~~~~~~~ diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 4b30f701225f..87dd506bffef 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -252,7 +252,12 @@ over a rather long period of time, but improvements are always welcome! a. If the updater uses synchronize_rcu_tasks() or call_rcu_tasks(), then the readers must refrain from executing voluntary context switches, that is, from - blocking. + blocking. On architectures that select + CONFIG_HAVE_RCU_TRAMPOLINE_READERS a reader must in + addition be a Tasks Trace RCU reader (that is what the + trampolines there do around their call-outs) or be text + that rcu_tasks_trampoline_text() recognises; an arbitrary + stretch of preemptible kernel code is not protected. b. If the updater uses call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then the diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b5a51b0ef944..bf0e56006863 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -218,6 +218,7 @@ config ARM64 select HAVE_PERF_REGS select HAVE_PERF_USER_STACK_DUMP select HAVE_PREEMPT_DYNAMIC_KEY + select HAVE_RCU_TRAMPOLINE_READERS if DYNAMIC_FTRACE_WITH_ARGS select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_RELIABLE_STACKTRACE select HAVE_POSIX_CPU_TIMERS_TASK_WORK diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 15fd9ec5ecac..64c3814eb745 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -288,6 +288,7 @@ config X86 select MMU_GATHER_RCU_TABLE_FREE select MMU_GATHER_MERGE_VMAS select HAVE_POSIX_CPU_TIMERS_TASK_WORK + select HAVE_RCU_TRAMPOLINE_READERS if X86_64 && SMP && DYNAMIC_FTRACE select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_RELIABLE_STACKTRACE if UNWINDER_ORC || STACK_VALIDATION select HAVE_FUNCTION_ARG_ACCESS_API diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig index bbab14bc14c3..341b68b972ef 100644 --- a/kernel/rcu/Kconfig +++ b/kernel/rcu/Kconfig @@ -95,8 +95,10 @@ config FORCE_TASKS_RCU help This option force-enables a task-based RCU implementation that uses only voluntary context switch (not preemption!), - idle, and user-mode execution as quiescent states. Not for - manual selection in most cases. + idle, and user-mode execution as quiescent states, or, on + HAVE_RCU_TRAMPOLINE_READERS architectures, the variant built on + Tasks Trace RCU readers in trampolines. Not for manual + selection in most cases. config NEED_TASKS_RCU bool -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 18 15:15:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 15:15:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425627.1649520 (Exim 4.92) (envelope-from ) id 1x7aIu-0006yG-2L; Fri, 18 Sep 2026 15:15:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425627.1649520; Fri, 18 Sep 2026 15:15:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7aIt-0006y8-Ue; Fri, 18 Sep 2026 15:15:07 +0000 Received: by outflank-mailman (input) for mailman id 1425627; Fri, 18 Sep 2026 15:15:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7aIs-0006xt-HE for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 15:15:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7aIr-006X1o-QT for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 17:15:05 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad556c-8faa-0a2a0a5109dd-0a2a4503aefe-36 for ; Fri, 18 Sep 2026 17:15:05 +0200 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad5577-fae8-0a2a45030019-cddcb4839146-3 for ; Fri, 18 Sep 2026 17:15:05 +0200 Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68IF0X5u1234167 for ; Fri, 18 Sep 2026 15:15:03 GMT Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4gs7jk81ua-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 18 Sep 2026 15:15:02 +0000 (GMT) Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2d6f80c76e6so17559445ad.3 for ; Fri, 18 Sep 2026 08:15:02 -0700 (PDT) Received: from localhost ([143.246.51.243]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ddb73db302sm10267015ad.2.2026.09.18.08.14.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 08:15:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-Id:Mime-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="In-Reply-To:References:To:From:Subject:Cc:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= klACuV7fdAYuSy7gHXP/AwNMnEDjRFePgshatLjHrOQ=; b=DTqEyIFwhXRJLNu9 IeYZsHOrKbXijwmdqq+ZxiPvyfet/fCUB0waQ1XFZArweh0RjYYUmoxq7nl/JEN1 Uy5NmhOd1qusEnfpTpqRg8agzbrAvS7pZSvHR/ylobOfF2XYjSV1/YXA1xxh8us/ 0WSRuT7kO6kdLHoxx0I2EyTlfaVrjEBLOT5OPcRGUnOIkfZCR1Q/Gs7QFtUyIHF/ pYQtElGkrqyBwxzixxweaHTo1wj2rjXG06RAMMI+IEvfVga5JiRCPKr59GAZzH1x JMF+HWQl287jMZVbazg42u8QTxVQ95BPg7psGMdFhgyAH+3PsFf8v+fRdN7V6mJV VeUpRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1789744502; x=1790349302; darn=lists.xenproject.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=klACuV7fdAYuSy7gHXP/AwNMnEDjRFePgshatLjHrOQ=; b=C8ZOREXWTdqaM32xy1hknWSzg/v9reA94UVS5j5jZcqUXY3kz00zGlvCSLmcJwD0xb u+WQRRYBOyyGwcUfUenuteqIfePxzJjyHjL10hoWQsZ+MIcmuUEazbkbNhXmMuTcS0iw 7A3pcuOJ3O1Xlp3B1YqyZkeEYp0o8eA6vNayoXEdOAyCJ6QEZmrxyebCP/zpIvLlQozc 9AyxYwoup7xMSPwGtzoDj0Kzp41zsOHmx7g1Xbxv+aUS4S0w679X5Nu8Ey1STsDfZP2n Mt4CaWrpi9LLRdHqBV0hs/HhG3YP2ZBGpYPoQxJqZUzAfh7UmSwx+Y4AZxErvpushHqT 1A2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789744502; x=1790349302; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=klACuV7fdAYuSy7gHXP/AwNMnEDjRFePgshatLjHrOQ=; b=dcATbVbkgunAM44znTV8E22GiIazj3n/D5syqyOvfQ9O0uOBoLfTRssLhf4TUVzg8Y S4F0LRVCba//ed9UPZ/UIT1FouMoVbmvmfz3ayMv3EzmRgjzDOOvql823c4zJ8d5irbd 5GmQ9jIKyqbg+5J/tHUCnhWqDrcctRHIgp2GBcxXIfBB81CFq8bG7AZlFtoc4Ife54qq IkeUgr5B3o6xHO2hrQHT+OLW/8kt77Zeoc9jjbJP8h73u3/YVRQNYhbUdpVycopTfW4y 2HFaw9oyREcj8ICnh+5oA/y7hLb1E0VqLKstZzvdL0/L9iOkDqUQc+G95YdRyPv2Ppcp BmcA== X-Forwarded-Encrypted: i=1; AKwUvBzq5JOlxrnf8CUMkkopJdNAZi+QAm4AuUtdd8+IBfd3XSkl3Nmodkx99TCG9KbJAaMWJr0THlxlji4=@lists.xenproject.org X-Gm-Message-State: AFuF++mo9CmEtQcO+aZj2CPVFj9mdzlhNzoMpNQwzl4G1MMBqCkg/Ksy FVeKe19OzQKa6haBntRijvW2yFMSDgM30bEpX/Ts7Z/PTYl/6lwg4Fs257Q15RZpfnEpFSkGJk8 lHkx4AF4FrYDU9qfoQAejysKqf+07VTNSJdzUPcXheaOdZBz8hdtE/tD79NFY+66tK3pvZw== X-Gm-Gg: AYBFou0uwMYi78V0jfW5g0DwAqsCvVBgUe9PbErncAiPeXWUXF7ec1bWNKTqQhi6yIh dJQFv299sU4fl0QvKd2eB1nu1xYY71huvfcdqxdXjGpTetCCvwviiR4p3ZvgwpMzKR7LfcchfVq jjeZ+VUb707ffYh/ETum03ixyCsXoo87v0Ot/ej1omQV/id3YLXCNcxWOkguvwz6EAHN/1aq8tW zsl2BLF/duGgt1nCeBG+UW4hSHZY7XszaS2GIvxb+02JXM9Pim9dcBstf+S630z+TijLJXwmk/t yczxDLQGk3aa4C9ljmOWO63n1pNGn1o6SrMaQUzsZdI8OHbTK/BakN1PtVdtai5uvirq6cXScqs kO+b1cg== X-Received: by 2002:a17:903:906:b0:2dd:c053:e669 with SMTP id d9443c01a7336-2ddc053e6a2mr4635015ad.47.1789744501633; Fri, 18 Sep 2026 08:15:01 -0700 (PDT) X-Received: by 2002:a17:903:906:b0:2dd:c053:e669 with SMTP id d9443c01a7336-2ddc053e6a2mr4634335ad.47.1789744501092; Fri, 18 Sep 2026 08:15:01 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 18 Sep 2026 23:14:35 +0800 Message-Id: Cc: , , , , , Subject: Re: [PATCH v3 2/2] drm/imx: replace struct drm_simple_display_pipe with regular atomic helpers From: "Ze Huang" To: "Thomas Zimmermann" , "Ze Huang" , "Alexey Brodkin" , "Maarten Lankhorst" , "Maxime Ripard" , "David Airlie" , "Simona Vetter" , "Joel Stanley" , "Andrew Jeffery" , "Frank Li" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "Linus Walleij" , "Hans de Goede" , "Alex Lanzano" , "Oleksandr Andrushchenko" , "Philipp Zabel" , =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= , "Marian Cichy" X-Mailer: aerc 0.22.0.r10.g73f20125 References: <20260727-drm-simple-kms-removal-v3-0-de36e534f7a1@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-2-de36e534f7a1@oss.qualcomm.com> <8e4c84be-5c89-4d84-adda-aad4c7de0c8a@suse.de> In-Reply-To: <8e4c84be-5c89-4d84-adda-aad4c7de0c8a@suse.de> X-Proofpoint-ORIG-GUID: MLiBPxhPjqk70rc0NIv2TKBkaJ0hli2i X-Proofpoint-GUID: MLiBPxhPjqk70rc0NIv2TKBkaJ0hli2i X-Authority-Analysis: v=2.4 cv=FeSiV5+6 c=1 sm=1 tr=0 ts=6aad5576 cx=c_pps a=MTSHoo12Qbhz2p7MsH1ifg==:117 a=LNnhWNgewsfctp/cwirQdA==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=P-IC7800AAAA:8 a=EUspDBNiAAAA:8 a=nI5uWgR6GCbiVoZM8DwA:9 a=QEXdDO2ut3YA:10 a=GvdueXVYPmCkWapjIL-Q:22 a=d3PnA9EDa4IxuAV0gXij:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE4MDIxNyBTYWx0ZWRfX9GkqI9kUxNdH xaJowi0Bfn5ZoxL6BBdj96wirRi1/XCkMnxIBzKji0T0axJhprJyqeBmYuE4uL1xi/7xrIz5EzT JyJGH0rVQmGeF55c3M0EXNM8vimI/RVCGMasWcCBVlbKeV/JGNcITRAijjaSy7CpSmBr+D9IFxS waqdEFvsUFfRLoFqxzBzVx+7CiqNDQCiwl1BkxiMmktsKBY+GZj1rk2tGiu56ctcDgts/pysEfk zNq22JZ1MMQ6EiZvz/Pdi53wrG++Ye+V7MeScJq1l8OSkQhHGcHPIMv+VvunlVg4+JDKxp/ewZ3 nQpw751461wPQ3niEDWh3WiA963ahVKSj/4yRqdZ6D9jdoQ5tBeFDpJUr95qydBBtlc23S21HVi 7ehDuHleJK+yGH1CWosj9DPdGuJmC9OpNb7DRdxKDrvc4ETkllGmoqjv69aoE6cKNHA1aUYUVCb sKrke2p7YwCqQcL96Uw== X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE4MDIxNyBTYWx0ZWRfX6WfenxViJ08H Z4E4KMnqr4xWRG4clvJMFxCxkElNE8bx1p+3xTwj6p7NF7vGZyXRsZigG7IDsMVkXfn8wLTNyba 3lgZRn9RR4QUJRIAnQNpiXp6etVujx4= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-18_04,2026-09-16_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 impostorscore=0 suspectscore=0 clxscore=1015 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609180217 X-purgate-ID: tlsNG-33051d/1789744505-772F54E9-0DECE7E2/0/0 X-purgate-type: clean X-purgate-size: 1526 On Wed Sep 16, 2026 at 2:50 PM CST, Thomas Zimmermann wrote: > Hi > > Am 26.07.26 um 21:42 schrieb Ze Huang: >> Convert i.MX LCDC to explicit primary plane, CRTC and encoder objects. >> Keep no-scaling plane check and GEM framebuffer prepare callback from >> simple-KMS path. >> >> Wire the vblank lifecycle explicitly with CRTC vblank callbacks and >> drm_crtc_vblank_on()/drm_crtc_vblank_off(). Use the old CRTC state in th= e >> disable path for clock unwinding so the clock reference count remains >> paired with the previous active state. >> >> Signed-off-by: Ze Huang >> --- >> + [ ... ] >> +static void imx_lcdc_crtc_helper_atomic_flush(struct drm_crtc *crtc, >> + struct drm_atomic_commit *commit) >> +{ >> + struct drm_crtc_state *new_crtc_state =3D drm_atomic_get_new_crtc_stat= e(commit, crtc); >> + struct drm_pending_vblank_event *event =3D new_crtc_state->event; >> + >> + if (!event) >> + return; >> + >> + new_crtc_state->event =3D NULL; >> + >> + spin_lock_irq(&crtc->dev->event_lock); >> + if (new_crtc_state->active && drm_crtc_vblank_get(crtc) =3D=3D 0) >> + drm_crtc_arm_vblank_event(crtc, event); >> + else >> + drm_crtc_send_vblank_event(crtc, event); >> + spin_unlock_irq(&crtc->dev->event_lock); >> } > > Please use drm_crtc_vblank_atomic_flush(). [1] > > [1]=20 > https://elixir.bootlin.com/linux/v7.2.5/source/drivers/gpu/drm/drm_vblank= _helper.c#L51 Thanks! will follow > > Best regards > Thomas > From xen-devel-bounces@lists.xenproject.org Fri Sep 18 15:22:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 15:22:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425647.1649527 (Exim 4.92) (envelope-from ) id 1x7aQ0-0000he-NT; Fri, 18 Sep 2026 15:22:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425647.1649527; Fri, 18 Sep 2026 15:22:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7aQ0-0000hX-Kd; Fri, 18 Sep 2026 15:22:28 +0000 Received: by outflank-mailman (input) for mailman id 1425647; Fri, 18 Sep 2026 15:22:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7aPz-0000hR-G0 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 15:22:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7aPx-005980-Go for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 17:22:25 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad572e-8faa-0a2a0a5109dd-0a2a4508e0fe-4 for ; Fri, 18 Sep 2026 17:22:25 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad5731-f659-0a2a45080019-4a7de18de40d-3 for ; Fri, 18 Sep 2026 17:22:25 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e8185e037so5346135e9.3 for ; Fri, 18 Sep 2026 08:22:25 -0700 (PDT) Received: from ?IPV6:2003:ca:b735:68a5:80e:d31a:d029:ea6f? (p200300cab73568a5080ed31ad029ea6f.dip0.t-ipconnect.de. [2003:ca:b735:68a5:80e:d31a:d029:ea6f]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fc521f5d9sm1924285e9.2.2026.09.18.08.22.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 08:22:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789744945; x=1790349745; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=m1acggxj5Mxmu56PtXNj/cLaMh5dmNk3kCC62oFD/yI=; b=A+dklrSwakxNEIbEUjN3TMf7f8YYb/NCjMjioqzaVT3llfFeDBdUx400U4AxyDjBw1 6N0eENeW1Q1KCOtaAyR1C++yM+pfKX/Kw4YcHAmdeOR0ZjQPNhgh595MmX9RPMMy8znq uw9mUz7vhx4tr0wun3aTak/31OuE3ooqu+EQ9ss7V0NJLOdh81MESb/4MfwIIYEQNLaG 92GX2kRtgAXzvJWB4sFhgkCSCJ3MbB3mJvIBJ6vHWW4QYbllhyWa4XMcQ+FW5FfpP2Ow kiKYe5LIG7KKsGK13va2rg+Zt/Kp7GVrfiUwvZttC1RCcbKKOMHuE/40eqXDoxKwFm9Y WC0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789744945; x=1790349745; h=content-transfer-encoding:content-type: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:content-type; bh=m1acggxj5Mxmu56PtXNj/cLaMh5dmNk3kCC62oFD/yI=; b=UFrn5gy1oEbpuEHOYO3C0yHA9xu1GG8LAoscjBqN2CkLaYk8dBhlTt+wyOXj4WijQN 9vj/5zyo03a1qel4t0pFLu0TupFJj/cVTavlaIn2rCREE+/P83Oblni5JkLG4j0LfbiC bpEAwqnVXQvRest45gO6UqYHk025MUvro2Vzs81CNE3yGRCVBEEJ+0DPTXlnYlQnrcA7 8W5dslUshYXtuhQZ3qYTqWewjxRaPhDv71j3A8y5RnNxKHFAsmLiQEtUsqMrWx2Z1ila bw0OHcK9nB8M6gh6kS+RoEpbBt5uSNXEqmyOWww55qWy5Zq/fhbFFg6An+eeDXUsYouq oklg== X-Forwarded-Encrypted: i=1; AKwUvBxR3f9xaXewDn2ohtpiGNguiFk9qLYqabMyDUvHZdOXIql5ij0AzRMgzZPUaRzwQO42RK1MVPTguDY=@lists.xenproject.org X-Gm-Message-State: AFuF++lchvp9CTRtIMXasg4gF+lxl3MZfh56d2ycDnJd+meIKCUXrhuT zfj7QbJyVVH3dW7AwhL8BHrKKBEV+fG4snNedfbpFQlafT6S7SInRltpV/eYXgB3XA== X-Gm-Gg: AYBFou1PZplRW+2hWGkH+cdf25V4HsvRb/3529FWh9pYa4ZDBA3OcXyXplAQFZQmnJG BawKLs8RtdNGI7tkKHlLzglv8Fq8jZNFKbx2Y6g/36+mBdRZibLHjfKuOEgbEEEd0FRXrSZooKP SoO2D+q4WHcG2g+sXu5qJgSoCjEUbNQ7vfmrkzS5IGBAGGU9lig18rsNj/4MlWB4FyhnetshP7J o0Cet3pDeum96wd0O7zuQLkbIEzXQQUwWoTjchgprzW3v/np9LQ/LdtLhYgG5awmTkKWEtFZ3Cg hBQ5lyaqKQrcTaYdgH6l44s7jOiLY9z5edEESfF/Y16Z2GnW2koQM7ElzNOpN0xppVQqdGl+1WS RZJ96sMVf8f2lOTMpQn8R7W6WLakM4GQEYnHk6n8+B5HbasFlYSTT+bwHyK6pme1KxvmZaU5c2q MmNthU5IdK4B8gJiEFXL6clUL60gUkc0wS6BuLDmLPtP6cn7M4oMDQUq8+11yib6nBc1WDuSpeQ hud583WO3T0Kp0jRuZfjj2EjETy2kLuuvbYXLLsqY9/3GOxFON4FsvcDjrm6r2uCZjedf9WuChU qIPjZYjH9Uw3yE6SN536gA++XscS X-Received: by 2002:a05:600c:3b8e:b0:49f:bc43:9e96 with SMTP id 5b1f17b1804b1-49fc57144aamr48915195e9.8.1789744944711; Fri, 18 Sep 2026 08:22:24 -0700 (PDT) Message-ID: <6f663204-fb2d-4b52-b703-188abdf074c8@suse.com> Date: Fri, 18 Sep 2026 17:22:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 3/5] x86: Track vcpu context switches and introduce needs_tlb_flush field To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509308.8631fc262581453bbf619ec5b2062170.19fb8a5e798000e099@vates.tech> 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: 8bit X-purgate-ID: tlsNG-c1860d/1789744945-D4F4F87B-6F135618/0/0 X-purgate-type: clean X-purgate-size: 700 On 18.09.2026 15:48, Ross Lagerwall wrote: > On 7/31/26 3:46 PM, Teddy Astie wrote: >> --- a/xen/arch/x86/domain.c >> +++ b/xen/arch/x86/domain.c >> @@ -38,6 +38,7 @@ >>   #include >>   #include >>   #include >> +#include >>     #include >>   #include >> @@ -874,6 +875,13 @@ int arch_domain_create(struct domain *d, >>         spec_ctrl_init_domain(d); >>   +    rc = -ENOMEM; >> +    d->arch.latest_vcpu = xvmalloc_array(int, nr_cpu_ids); > > Does this work with pCPU hotplug or do you need to use NR_CPUS? nr_cpu_ids covers all CPUs which may ever come online. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 16:27:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 16:27:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425697.1649538 (Exim 4.92) (envelope-from ) id 1x7bQz-0000wr-Vu; Fri, 18 Sep 2026 16:27:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425697.1649538; Fri, 18 Sep 2026 16:27:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7bQz-0000wj-Ru; Fri, 18 Sep 2026 16:27:33 +0000 Received: by outflank-mailman (input) for mailman id 1425697; Fri, 18 Sep 2026 16:27:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7bQx-0000wd-QK for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:27:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7bQx-009uTL-75 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 18:27:31 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad6667-8faa-0a2a0a5109dd-0a2a4508b50a-20 for ; Fri, 18 Sep 2026 18:27:31 +0200 Received: from [52.101.48.18] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad6670-f659-0a2a45080019-34653012a72a-3 for ; Fri, 18 Sep 2026 18:27:30 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by BL1PR03MB6054.namprd03.prod.outlook.com (2603:10b6:208:312::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Fri, 18 Sep 2026 16:27:26 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.011; Fri, 18 Sep 2026 16:27:25 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h6TKt9smSsmxtXWLIpC3By/m3Dl6Y+38HyV/Eh0ODw+derbhW2ZEWkaIjDC+t1Qc20ZBkj+R4k01/usmsCHpk+IlB87riGkp52W2yvrmvuPlC3NxgfFAYWEtiyXGFr+a60Vu3nTfmN5ERn0OZVVzckwv/i6mG6ghO+RVctU5YDRbqiqHFzx3VOmOh1Rpz+VPcUOualWc5AX2CtdnYqrtjObjAWULeHnjLcGnSmd37GTc8mBP3rgSEPLVQwdAvtBiAwnbabq2TQcv9wNvBYmb6j2EhHmR6JHxtc3Vy7MsL9f07cJDECMtP4UVl3ezd8jds7p4yLIV1iP3aksboCEoeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=So1xpV/B6653OOrWe30XTAZ2TVKKJQzsmIqjPj5c4wg=; b=PH5d8cJNH+0bv8s8fjf0uKhs2q7qt8nMkDyPSfMrShdWCD/8zyxV3PG2KoiJqU0+nLPIJbuMC1T1+Qsnja5WJ3LciF3t+Y6iIjgofacyOqBO2oJf9ZEq8KFSZcslIKmR0pzCxXIdCsMSxeOeKHDUeb1q0j/M5BYODPD7J4JstYkS5jeXZL+9RTsCOLVzBXoY16Jl4D/lECnUjgkHrZaGWONWfKCx1jP83XrReYUBNlU4ww5j+8PIYfm1IyS/xYsXjw1GXllQMTYxKSTc3e938/6A+561qn9AZAJvgw6GYfocFrrKCIaYAZZfqJFD4LKjfsF8R07Uts58TH+H+lXuOg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=So1xpV/B6653OOrWe30XTAZ2TVKKJQzsmIqjPj5c4wg=; b=NK/ubke81S6BggIm26WKhaQ0ys3IqPhZMhECpSkWn2IB5cXVZTxHJpXsyVo7iI7ZfYMUpnZRuGjZq3YszNtFWLl3sjl2AtRKMLE5oafpU1OTZYn1H38lMEKkdjvgGmE58zruOYNLm2wlbL2tQypxqPECVBs30GSwcfhuJ3a0z18= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0b4a8cb9-e398-43a5-8f68-2c36d245c88d@citrix.com> Date: Fri, 18 Sep 2026 17:27:21 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 4/5] x86/hvm: Transition to needs_tlb_flush logic, use per-domain ASID To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Jason Andryuk , Tim Deegan References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509309.8631fc262581453bbf619ec5b2062170.19fb8a5ecef000e099@vates.tech> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <1785509309.8631fc262581453bbf619ec5b2062170.19fb8a5ecef000e099@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0144.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c4::17) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|BL1PR03MB6054:EE_ X-MS-Office365-Filtering-Correlation-Id: 4be1162c-596b-45de-cfd4-08df15a1b992 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7416014|23010399003|6133799003|3023799007|10067099003|4143699003|56012099006|11063799006|5023799004|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: btDe1//jeJ0LEuLOGngRIoiEiF2xyIOOmx6tpSq2f4DRM+cxkBf5rGotcdHMo3WQ83LXLbcVlrIZix22LMaarJz8obrLBdd0TaTGC6ZFmREQA66qy4B8CFRe0FQGpZUGsu+GggEu73gSwXSvrgf3nLeN4GBavprNd/TizCCrzLsnMRUJuAtfO6Y4AvfzW9ELytnNQ9mTTQI4AiOKxsobv9Ld047Jz6+qnOhXwY9SU5E2MOhMrltJTKU3uZwHMGK2ZxiiIcgtykzRGSxfrve810aAlfdVVo6xwIjdTANFSIQGkEsmsqDq2n6Bcggl1IFitWVSmSKbmrWGNyEKoK/gEapNZ3KneGhIVgMliYu58U2V4VSCiHSRYAsgpqRCbrDYWxMRlZyza++AqDdzL+J1XoSqWsM5PJSPfFATqDewRwgpCUl/U0yEG+2lkwgGwl4u4tymdjgOlKmX/doh4BTwgWtiM0t+k8Co5K6FZngK3DlMqa1Wyt0sQMAk/INQhLu/b47Rq1YnlZzFgrwpI7iUEklIex2kPzEu77jJRQjJRVLZQL2IDCQpvA2DY9Cq1dEm2VfyJ4RvfnCigYdktHAuE7BNXNfVb00jsQkc8dEoi3M343YPNxmkjVZYUNJ6Iho3SF97dCIoGHIogJEA6b75N/kei+tOOXV+tv/1p5bKkYU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7416014)(23010399003)(6133799003)(3023799007)(10067099003)(4143699003)(56012099006)(11063799006)(5023799004)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SVlaS29xMndjOEMyOWRZeVdHQTU1N201YmJ5SUpyZFpoTDc5ZHREQ2kvMEdQ?= =?utf-8?B?a0lyVThRQTNNUGszdGc5TklZbUprWDRodHBWRzA0SHcraVFHNytQcXExRity?= =?utf-8?B?QVJsYkE2MXRqK2xHa3o5SG1qRi9KVUNGcHltenZqdUl2NFFKMHB3dlozUHRK?= =?utf-8?B?WXM4QU5WRWtVWWVOL2tON2pBSEc1NCtybFFRa2Jqa2NNL2w2aXh3OUhHcU5z?= =?utf-8?B?TVRrdFkxRk50WlF4dWxuUEVLMEZsck5XcUtFODVwOW1VN09LQndGNXlSM3pZ?= =?utf-8?B?emFBNW82S1Z2ZmRBTzR1WXRJRUJ0ZDVNaUNZL1Z3VzZXTE5sK095Q0FtSnpB?= =?utf-8?B?WCtOcnZQVmNvOHcvY0FnL0VKYXM5QUovY0I0Y1RYeURKek5GdFpHbG5QUmQx?= =?utf-8?B?UlRkK05PMUw3dG52azNaVmVrc3NUTWM3dGFIUDhrOEo5a2t5ZzFYZjE0Rm1a?= =?utf-8?B?dHVUWG12VExqdEJISXpJTWwvTEUrUHU4dXBmanpPVENVVkpLaGRTWnJBR1Np?= =?utf-8?B?TzNISUVvNXlxb3NZbmJZZmZsY09UVVNmbUV6aDRja2F4NjIvSWw4YVZ1V1pK?= =?utf-8?B?RnJETFdtSUhxb1A3L1VqSXZ1OEtuVlBHaDE4VzNEZ25ZTE1EUHJNMFNoRXhr?= =?utf-8?B?M0xUS1pwZ0pVZXVOcG14eFZvUEdYWDV3eEpqWFd6UXR6MC82OXZSVFlQcFNu?= =?utf-8?B?K011d1hIeklNSFJpYzBSMTcxR0lmajR0eW9nZmNpeTJDT2ZpQmladHgzRzhP?= =?utf-8?B?M0hoVEFjZXRoM09ScFhxeVd5RWVCWHdoL3BWM1pHcyt6Mi9tZjMrT0oxOVpw?= =?utf-8?B?OE5iZUtoUzhHY0FBVTIvSzg1a21Bd0gzZlltWjFua2M1M0gxbGdNUVVKVFh0?= =?utf-8?B?cEJqaWw0VlhLS041MGV0OXhUN29wVUVtLzVZVmJTOGtyR0ZRbTVpQ3ZqUGVn?= =?utf-8?B?ckpvL3l4MzZQNzBpbDc2d2FsUVZGN1RubFRsUm90aldMcFRPTGRoRkVuT2Ja?= =?utf-8?B?Z0ZYRDl4V2RNREJ2VGVwWlBKVzhFNDdMTHh5cjQ2aUtYeWNkMERnT0l5TzZ3?= =?utf-8?B?SU9XVnYxN3NjamZpejVlWGhTcm9LUU1ERlJQRDFTVWFPQk5WU1Zxb3JvUDY1?= =?utf-8?B?ZW1vR2FIN1gweGVhZUtiNzhvNnV4Nllpb3VGdnl6NDVFNEk2bzZrNzdEVGl1?= =?utf-8?B?YkF5UmhyWXh6WEVYWU1zUHRFWVlUVzh6WnBxaXFrVTkwUXo4T3ArNTNVWVNR?= =?utf-8?B?SXRISmZsMy9nQXBWY3RGcWYzWnY2MUdYQS9mMXE4WEM0RnZhNkNRMVFEK0x0?= =?utf-8?B?SUgzV0E1NjF2TVFGMTRxdForRUZ2L1NCMmlLL3VHaHc3TFVJNFlqV0o0WHps?= =?utf-8?B?S2V1OTNsaHVyUXI1SU54NE1uK2l2U1BFdlBxVUZzaUc4Z1J4WUZZeDU2MjRx?= =?utf-8?B?UXB4aXFqbmFXOXl0dGpINlQzSG9zYm5xNWxmNk1LM2x0QlMwNkE1Q1dIeHZK?= =?utf-8?B?a3BNeVJ6WjlhN2RyVUxTWjcwMStxbFFJNGc3RS9sMTdTWk5laEVKeVJHdkRD?= =?utf-8?B?eHIxVGFvMFZ5MFpNOHpXRzQ0Nmp2RXBJK2pnRXN6TVRUVWNkbWN4S3l0MjVY?= =?utf-8?B?YWc4QnBUSXVUQm11ZHloMTUzTzVwaXZhSU12MUU2ZE52TGRPTm1zMFk3eEtI?= =?utf-8?B?V3lTM1dKSkNMZ2tZZUFOTzhacmo5VEQyZ2RZQk9zRXBRZ0QzbFQvVEVRZUY3?= =?utf-8?B?MkZwVDZQUjNYa1RSaVg1SWlvSzRLUjA3SHVjQW9NMGRoOXRSRklRdldGVkxE?= =?utf-8?B?amY2WVYvZGJoZG9GSzRURXRyN28vQWNtZExmeHZQUnVxbVBvMmNGWFlxbTJp?= =?utf-8?B?VHovZzVZK1VJMU9OaGJyZkNPWFJpRWJoc2xLMVYzUTZNN0Y4SloxZ0xZNi9j?= =?utf-8?B?QWVqOHdTakhSRXFqNElFYkxSbVNEenFmcTRSbyt6aHJ2cTN2MEh3b2lOTFRm?= =?utf-8?B?Y2hhb2NsbVEyUE0zeVZnQXlSNHlRZkhBUjg3Vjh2NFVLMHNyQnRBMCtLbnRR?= =?utf-8?B?WmhMSWZmcjd4bXhGekVnM1ExRVRJZDk3bzgrNGhNU1dUdnIvN0NwbXhaNktj?= =?utf-8?B?OS90RmgwVzRkTjE4NGIwbU1uR1NKekpLWDY5TWNSVzhnYjFvNWlSSG5KZzRQ?= =?utf-8?B?dkMwSFl5NXFKcVp0ZDNKWTBmQmhUcFB4aCs3R2ZQMnVWSjVkaDhJakpWanlZ?= =?utf-8?B?eVg5dGlGeGVvK3loZ3hIbTJxcjFHc1d2WHR2SC9TRmdFZ0RyRHd6WHo1MGtZ?= =?utf-8?B?NnRTNFRZWjZnbDZ1Z0Jyc29ITTVON0Z0OHhYVnVVVWZmWmYzUGE0REdqaGNS?= =?utf-8?Q?04JS+lfHUd4niP34=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4be1162c-596b-45de-cfd4-08df15a1b992 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 16:27:25.8964 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: KW1H6+f+ZnZsv4vIkSKYSDnHxuys52XbuuiNN/RlT94Ou6INUfiBJ4NQYBbTtN0VlZ6K7+r4XBms6ivjb8dfvrKTQEuYd+gUMD/MdxRjrVk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6054 X-purgate-ID: tlsNG-c1860d/1789748851-CE14687B-670FFE69/0/0 X-purgate-type: clean X-purgate-size: 52682 On 7/31/26 3:46 PM, Teddy Astie wrote: > Change the ASID model where all vCPU of a domain share the same ASID > as required by AMD SEV and broadcast TLB flushing features (AMD INVLPGB). > > ASID 1 is reserved as a placeholder for "no domain ASID", and used when > either ASID are not supported or no more ASID is available for use. > In this case, we always flush the TLB when from and to such domain's > vCPU. > > Moreover, centralize the TLB flushing logic to use needs_tlb_flush, if > a full TLB flush needs to be performed for the vCPU, either through > SVM tlb_control or VMX invvpid before entering the guest. > > As a result, drop ASID tickling logic, which is now redundant with the > needs_tlb_flush mechanism introduced previously. Also take the opportunity > to drop some now unused helpers now that FLUSH_HVM_ASID_CORE is dropped. > > Signed-off-by: Teddy Astie > --- > This patch is particularly hard to split as the required changes needs > to come all at once. > > Some questions : > - On Intel, with "ASID disabled", should we distinguish between using sentinel > "VPID=1" (with single-context flush of VPID=1) with disabling VPID (through > SECONDARY_EXEC_ENABLE_VPID) which implies flushing all VPID=0 (Xen/PV ones) TLB > entries on vmenter ? > Of course, hardware without VPID support can't use VPID=1 and will behave with > VPID disabled. > > - I tested it on both Intel and AMD platforms without much issues, but didn't > performed tests with nested virt which has tricky interactions with these > changes. > > docs/misc/xen-command-line.pandoc | 2 +- > xen/arch/x86/flushtlb.c | 22 +--- > xen/arch/x86/hvm/asid.c | 169 +++++++++++-------------- > xen/arch/x86/hvm/emulate.c | 2 +- > xen/arch/x86/hvm/hvm.c | 14 +- > xen/arch/x86/hvm/nestedhvm.c | 7 +- > xen/arch/x86/hvm/svm/asid.c | 67 +++++++--- > xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- > xen/arch/x86/hvm/svm/svm.c | 35 +++-- > xen/arch/x86/hvm/svm/svm.h | 4 - > xen/arch/x86/hvm/vmx/vmcs.c | 6 +- > xen/arch/x86/hvm/vmx/vmx.c | 66 +++++----- > xen/arch/x86/hvm/vmx/vvmx.c | 4 +- > xen/arch/x86/include/asm/flushtlb.h | 7 - > xen/arch/x86/include/asm/hvm/asid.h | 30 ++--- > xen/arch/x86/include/asm/hvm/domain.h | 1 + > xen/arch/x86/include/asm/hvm/hvm.h | 15 +-- > xen/arch/x86/include/asm/hvm/svm.h | 5 + > xen/arch/x86/include/asm/hvm/vcpu.h | 10 +- > xen/arch/x86/include/asm/hvm/vmx/vmx.h | 4 +- > xen/arch/x86/mm/hap/hap.c | 9 +- > xen/arch/x86/mm/p2m.c | 6 +- > xen/arch/x86/mm/paging.c | 2 +- > xen/arch/x86/mm/shadow/multi.c | 12 +- > 24 files changed, 241 insertions(+), 260 deletions(-) > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index 1c711fa980..f59c14d447 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -208,7 +208,7 @@ to appropriate auditing by Xen. Argo is disabled by default. > > Default: `true` > > Permit Xen to use Address Space Identifiers. This is an optimisation which > -tags the TLB entries with an ID per vcpu. This allows for guest TLB flushes > +tags the TLB entries with an ID per domain. This allows for guest TLB flushes > to be performed without the overhead of a complete TLB flush. > > ### async-show-all (x86) > diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c > index 5e2ed50ec9..478a3f4962 100644 > --- a/xen/arch/x86/flushtlb.c > +++ b/xen/arch/x86/flushtlb.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -119,7 +120,6 @@ void switch_cr3_cr4(struct vcpu *v, unsigned long cr3, unsigned long cr4) > > if ( tlb_clk_enabled ) > t = pre_flush(); > - hvm_flush_guest_tlbs(); > > old_cr4 = read_cr4(); > ASSERT(!(old_cr4 & X86_CR4_PCIDE) || !(old_cr4 & X86_CR4_PGE)); > @@ -224,9 +224,6 @@ unsigned int flush_area_local(const void *va, unsigned int flags) > do_tlb_flush(); > } > > - if ( flags & FLUSH_HVM_ASID_CORE ) > - hvm_flush_guest_tlbs(); > - > if ( flags & (FLUSH_CACHE_EVICT | FLUSH_CACHE_WRITEBACK) ) > { > const struct cpuinfo_x86 *c = ¤t_cpu_data; > @@ -316,18 +313,13 @@ void cache_writeback(const void *addr, unsigned int size) > asm volatile ("sfence" ::: "memory"); > } > > -unsigned int guest_flush_tlb_flags(const struct domain *d) > -{ > - bool shadow = paging_mode_shadow(d); > - bool asid = is_hvm_domain(d) && (cpu_has_svm || shadow); > - > - return (shadow ? FLUSH_TLB : 0) | (asid ? FLUSH_HVM_ASID_CORE : 0); > -} > - > void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask) > { > - unsigned int flags = guest_flush_tlb_flags(d); > + struct vcpu *v; > + > + if ( paging_mode_shadow(d) ) > + flush_tlb_mask(mask); > > - if ( flags ) > - flush_mask(mask, flags); > + for_each_vcpu(d, v) > + v->arch.needs_tlb_flush = true; > } > diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c > index 935cae3901..1a21125161 100644 > --- a/xen/arch/x86/hvm/asid.c > +++ b/xen/arch/x86/hvm/asid.c > @@ -5,138 +5,115 @@ > * Copyright (c) 2009, Citrix Systems, Inc. > */ > > +#include > #include > #include > #include > -#include > -#include > -#include > +#include > +#include > + > +#include > #include > > /* Xen command-line option to enable ASIDs */ > static bool __read_mostly opt_asid_enabled = true; > boolean_param("asid", opt_asid_enabled); > > +bool __read_mostly asid_enabled = false; > +static unsigned long __ro_after_init *asid_bitmap; > +static unsigned long __ro_after_init asid_count; > +static DEFINE_SPINLOCK(asid_lock); > + > /* > - * ASIDs partition the physical TLB. In the current implementation ASIDs are > - * introduced to reduce the number of TLB flushes. Each time the guest's > - * virtual address space changes (e.g. due to an INVLPG, MOV-TO-{CR3, CR4} > - * operation), instead of flushing the TLB, a new ASID is assigned. This > - * reduces the number of TLB flushes to at most 1/#ASIDs. The biggest > - * advantage is that hot parts of the hypervisor's code and data retain in > - * the TLB. > - * > * Sketch of the Implementation: > + * ASIDs are assigned uniquely per domain and doesn't change during the lifecycle of the > + * domain. Once vcpus are initialized and are up, we assign the same ASID to all vcpus > + * of that domain at the first VMRUN. In order to process a TLB flush on a vcpu, we set > + * needs_tlb_flush to schedule a TLB flush for the next VMRUN (e.g using tlb control > + * field of VMCB). > * > - * ASIDs are a CPU-local resource. As preemption of ASIDs is not possible, > - * ASIDs are assigned in a round-robin scheme. To minimize the overhead of > - * ASID invalidation, at the time of a TLB flush, ASIDs are tagged with a > - * 64-bit generation. Only on a generation overflow the code needs to > - * invalidate all ASID information stored at the VCPUs with are run on the > - * specific physical processor. This overflow appears after about 2^80 > - * host processor cycles, so we do not optimize this case, but simply disable > - * ASID useage to retain correctness. > + * We reserve ASID=1 as being the ASID used when none other is available (or with asid > + * use disabled). Multiples domains may use this ASID, thus we need to systematically > + * flush the TLB for this one when switching between vCPUs with ASID=1. > */ > > -/* Per-CPU ASID management. */ > -struct hvm_asid_data { > - uint64_t core_asid_generation; > - uint32_t next_asid; > - uint32_t max_asid; > - bool disabled; > -}; > - > -static DEFINE_PER_CPU(struct hvm_asid_data, hvm_asid_data); > - > -void hvm_asid_init(unsigned int nasids) > +int __init hvm_asid_init(unsigned long nasids) > { > - static int8_t __ro_after_init g_disabled = -1; > - struct hvm_asid_data *data = &this_cpu(hvm_asid_data); > + ASSERT(nasids); > > - data->max_asid = nasids - 1; > - data->disabled = !opt_asid_enabled || (nasids <= 1); > + asid_count = nasids; > + asid_enabled = opt_asid_enabled && (nasids > 1); > > - if ( g_disabled < 0 ) > - { > - g_disabled = data->disabled; > - printk("HVM: ASIDs %sabled\n", data->disabled ? "dis" : "en"); > - } > - else if ( g_disabled != data->disabled ) > - printk("HVM: CPU%u: ASIDs %sabled\n", smp_processor_id(), > - data->disabled ? "dis" : "en"); > + asid_bitmap = xvzalloc_array(unsigned long, BITS_TO_LONGS(asid_count + 1)); > + if ( !asid_bitmap ) > + return -ENOMEM; Should there be a sanity check to avoid an excessive allocation? E.g. If running under another hypervisor, it might set nasids to ~0 while with one per domain we need no more than ~64k. > > - /* Zero indicates 'invalid generation', so we start the count at one. */ > - data->core_asid_generation = 1; > + printk("HVM: ASIDs %sabled (count=%lu)\n", asid_enabled ? "en" : "dis", asid_count); > > - /* Zero indicates 'ASIDs disabled', so we start the count at one. */ > - data->next_asid = 1; > -} > + /* ASID 0 and 1 are reserved, mark it as permanently used */ > + set_bit(0, asid_bitmap); > + set_bit(1, asid_bitmap); > > -void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid) > -{ > - write_atomic(&asid->generation, 0); > + return 0; > } > > -void hvm_asid_flush_vcpu(struct vcpu *v) > +int hvm_asid_alloc(struct hvm_asid *asid) > { Can this be implemented in terms of hvm_asid_alloc_range() as these functions seem to be mostly duplicated? > - hvm_asid_flush_vcpu_asid(&v->arch.hvm.n1asid); > - hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); > -} > + unsigned long new_asid; > > -void hvm_asid_flush_core(void) > -{ > - struct hvm_asid_data *data = &this_cpu(hvm_asid_data); > + if ( !asid_enabled ) > + { > + asid->asid = 1; > + return 0; > + } > > - if ( data->disabled ) > - return; > + spin_lock(&asid_lock); > + new_asid = find_first_zero_bit(asid_bitmap, asid_count); > + if ( new_asid > asid_count ) > + return -ENOSPC; > > - if ( likely(++data->core_asid_generation != 0) ) > - return; > + set_bit(new_asid, asid_bitmap); > > - /* > - * ASID generations are 64 bit. Overflow of generations never happens. > - * For safety, we simply disable ASIDs, so correctness is established; it > - * only runs a bit slower. > - */ > - printk("HVM: ASID generation overrun. Disabling ASIDs.\n"); > - data->disabled = 1; > + asid->asid = new_asid; > + spin_unlock(&asid_lock); > + return 0; > } > > -bool hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid) > +int hvm_asid_alloc_range(struct hvm_asid *asid, unsigned long min, unsigned long max) > { > - struct hvm_asid_data *data = &this_cpu(hvm_asid_data); > + unsigned long new_asid; > + > + if ( WARN_ON(min >= asid_count) ) > + return -EINVAL; > > - /* On erratum #170 systems we must flush the TLB. > - * Generation overruns are taken here, too. */ > - if ( data->disabled ) > - goto disabled; > + if ( !asid_enabled ) > + return -EOPNOTSUPP; > > - /* Test if VCPU has valid ASID. */ > - if ( read_atomic(&asid->generation) == data->core_asid_generation ) > - return 0; > + spin_lock(&asid_lock); > + new_asid = find_next_zero_bit(asid_bitmap, asid_count, min); > + if ( new_asid > max || new_asid > asid_count ) > + return -ENOSPC; > > - /* If there are no free ASIDs, need to go to a new generation */ > - if ( unlikely(data->next_asid > data->max_asid) ) > - { > - hvm_asid_flush_core(); > - data->next_asid = 1; > - if ( data->disabled ) > - goto disabled; > - } > + set_bit(new_asid, asid_bitmap); > > - /* Now guaranteed to be a free ASID. */ > - asid->asid = data->next_asid++; > - write_atomic(&asid->generation, data->core_asid_generation); > + asid->asid = new_asid; > + spin_unlock(&asid_lock); > + return 0; > +} > > - /* > - * When we assign ASID 1, flush all TLB entries as we are starting a new > - * generation, and all old ASID allocations are now stale. > - */ > - return (asid->asid == 1); > +void hvm_asid_free(struct hvm_asid *asid) > +{ > + ASSERT( asid->asid ); > > - disabled: > - asid->asid = 0; > - return 0; > + if ( !asid_enabled || asid->asid == 1 ) > + return; > + > + ASSERT( asid->asid < asid_count ); > + > + spin_lock(&asid_lock); > + WARN_ON(!test_bit(asid->asid, asid_bitmap)); > + clear_bit(asid->asid, asid_bitmap); > + spin_unlock(&asid_lock); > } > > /* > diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c > index 2efb1d4f08..259a2b0caf 100644 > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -2655,7 +2655,7 @@ static int cf_check hvmemul_tlb_op( > case x86emul_invpcid: > if ( x86emul_invpcid_type(aux) != X86_INVPCID_INDIV_ADDR ) > { > - hvm_asid_flush_vcpu(current); > + current->arch.needs_tlb_flush = true; > break; > } > aux = x86emul_invpcid_pcid(aux); > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index a75ccb57bf..283dcad691 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -715,6 +715,10 @@ int hvm_domain_initialise(struct domain *d, > if ( rc ) > goto fail2; > > + rc = hvm_asid_alloc(&d->arch.hvm.asid); > + if ( rc ) > + goto fail2; > + Don't you need to free the asid if the subsequent function call(s) fail? > rc = alternative_call(hvm_funcs.domain_initialise, d); > if ( rc != 0 ) > goto fail2; > @@ -795,7 +799,7 @@ void hvm_domain_destroy(struct domain *d) > list_del(&ioport->list); > xfree(ioport); > } > - > + hvm_asid_free(&d->arch.hvm.asid); > destroy_vpci_mmcfg(d); > } > > @@ -1613,7 +1617,7 @@ int hvm_vcpu_initialise(struct vcpu *v) > int rc; > struct domain *d = v->domain; > > - hvm_asid_flush_vcpu(v); > + v->arch.needs_tlb_flush = true; > > spin_lock_init(&v->arch.hvm.tm_lock); > INIT_LIST_HEAD(&v->arch.hvm.tm_list); > @@ -4085,6 +4089,11 @@ static void hvm_s3_resume(struct domain *d) > } > } > > +int hvm_flush_tlb(const unsigned long *vcpu_bitmap) > +{ > + return current->domain->arch.paging.flush_tlb(vcpu_bitmap); > +} > + > static int hvmop_flush_tlb_all(void) > { > if ( !is_hvm_domain(current->domain) ) > @@ -5461,4 +5470,3 @@ int hvm_copy_context_and_params(struct domain *dst, struct domain *src) > * indent-tabs-mode: nil > * End: > */ > - > diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c > index bddd77d810..61e866b771 100644 > --- a/xen/arch/x86/hvm/nestedhvm.c > +++ b/xen/arch/x86/hvm/nestedhvm.c > @@ -12,6 +12,7 @@ > #include > #include /* for local_event_delivery_(en|dis)able */ > #include /* for paging_mode_hap() */ > +#include > > static unsigned long *shadow_io_bitmap[3]; > > @@ -36,13 +37,11 @@ nestedhvm_vcpu_reset(struct vcpu *v) > hvm_unmap_guest_frame(nv->nv_vvmcx, 1); > nv->nv_vvmcx = NULL; > nv->nv_vvmcxaddr = INVALID_PADDR; > - nv->nv_flushp2m = 0; > + nv->nv_flushp2m = true; > nv->nv_p2m = NULL; > nv->stale_np2m = false; > nv->np2m_generation = 0; > > - hvm_asid_flush_vcpu_asid(&nv->nv_n2asid); > - > alternative_vcall(hvm_funcs.nhvm_vcpu_reset, v); > > /* vcpu is in host mode */ > @@ -86,7 +85,7 @@ static void cf_check nestedhvm_flushtlb_ipi(void *info) > * This is cheaper than flush_tlb_local() and has > * the same desired effect. > */ > - hvm_asid_flush_core(); > + WARN_ON(hvm_flush_tlb(NULL)); IIUC, nestedhvm_vmcx_flushtlb() IPIs multiple pCPUs to run nestedhvm_flushtlb_ipi() and each of those calls flushes the TLB of every vCPU in whatever domain "current" points to and then triggers a VMEXIT on the relevant pCPUs. (Or current might be a shadow domain or the idle domain and do something different...) Is this what you intended because it doesn't seem right to me? > vcpu_nestedhvm(v).nv_p2m = NULL; > vcpu_nestedhvm(v).stale_np2m = true; > } > diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c > index 53aa5d0512..44d2138895 100644 > --- a/xen/arch/x86/hvm/svm/asid.c > +++ b/xen/arch/x86/hvm/svm/asid.c > @@ -1,39 +1,46 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > /* > - * asid.c: handling ASIDs in SVM. > + * asid.c: handling ASIDs/VPIDs. > * Copyright (c) 2007, Advanced Micro Devices, Inc. > */ > > +#include > + > #include > #include > #include > +#include > > #include "svm.h" > #include "vmcb.h" > > -void svm_asid_init(const struct cpuinfo_x86 *c) > +void __init svm_asid_init(void) > { > - unsigned int nasids = 0; > + unsigned int cpu, nasids = cpuid_ebx(0x8000000aU); > + > + if ( !nasids ) > + nasids = 1; > > - /* Check for erratum #170, and leave ASIDs disabled if it's present. */ > - if ( !cpu_has_amd_erratum(c, AMD_ERRATUM_170) ) > - nasids = cpuid_ebx(0x8000000aU); > + for_each_present_cpu(cpu) > + { > + /* Check for erratum #170, and leave ASIDs disabled if it's present. */ > + if ( cpu_has_amd_erratum(&cpu_data[cpu], AMD_ERRATUM_170) ) > + { > + printk(XENLOG_WARNING "Disabling ASID due to errata 170 on CPU%u\n", cpu); > + nasids = 1; > + } > + } > > - hvm_asid_init(nasids); > + BUG_ON(hvm_asid_init(nasids)); > } > > /* > - * Called directly before VMRUN. Checks if the VCPU needs a new ASID, > - * assigns it, and if required, issues required TLB flushes. > + * Called directly at the first VMRUN/VMENTER of a vcpu to assign the ASID/VPID. Mentioning VMENTER and VPID is not relevent in this AMD code. > */ > -void svm_asid_handle_vmrun(void) > +void svm_vcpu_assign_asid(struct vcpu *v) > { > - struct vcpu *curr = current; > - struct vmcb_struct *vmcb = curr->arch.hvm.svm.vmcb; > - struct hvm_vcpu_asid *p_asid = > - nestedhvm_vcpu_in_guestmode(curr) > - ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid; > - bool need_flush = hvm_asid_handle_vmenter(p_asid); > + struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; > + struct hvm_asid *p_asid = &v->domain->arch.hvm.asid; > > /* ASID 0 indicates that ASIDs are disabled. */ > if ( p_asid->asid == 0 ) > @@ -44,11 +51,31 @@ void svm_asid_handle_vmrun(void) > return; > } > > - if ( vmcb_get_asid(vmcb) != p_asid->asid ) > - vmcb_set_asid(vmcb, p_asid->asid); > + /* In case ASIDs are disabled, as ASID = 0 is reserved, guest can use 1 instead. */ > + vmcb_set_asid(vmcb, asid_enabled ? p_asid->asid : 1); > +} > + > +/* Call to make a TLB flush at the next VMRUN. */ > +void svm_vcpu_set_tlb_control(struct vcpu *v) > +{ > + struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; > + > + /* > + * If the vcpu is already running, the tlb control flag may not be > + * processed and will be cleared at the next VMEXIT, which will undo > + * what we are trying to do. > + */ > + WARN_ON(v != current && v->is_running); > + > + vmcb->tlb_control = > + cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL; > +} > + > +void svm_vcpu_clear_tlb_control(struct vcpu *v) > +{ > + struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; > > - /* We can't rely on TLB_CTRL_FLUSH_ASID as all ASIDs are stale here. */ > - vmcb->tlb_control = need_flush ? TLB_CTRL_FLUSH_ALL : TLB_CTRL_NO_FLUSH; > + vmcb->tlb_control = TLB_CTRL_NO_FLUSH; > } > > /* > diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c > index b06124c2c9..c712b98256 100644 > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -5,6 +5,7 @@ > * > */ > > +#include > #include > #include > #include > @@ -633,7 +634,6 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, > if ( svm->ns_asid != vmcb_get_asid(ns_vmcb)) > { > nv->nv_flushp2m = 1; > - hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); > svm->ns_asid = vmcb_get_asid(ns_vmcb); > } Removing this flush seems wrong. If VMCB(1-2) has switched to a new ASID but VMCB(0-2) always uses the same ASID (same as VMCB(0-1) IIUC), then we surely need to flush the TLB for correctness. > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 38c61db1d7..e9026e0ae5 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -137,14 +138,17 @@ static void cf_check svm_update_guest_cr( > if ( !nestedhvm_enabled(v->domain) ) > { > if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) ) > - hvm_asid_flush_vcpu(v); > + v->arch.needs_tlb_flush = true; > } > else if ( nestedhvm_vmswitch_in_progress(v) ) > ; /* CR3 switches during VMRUN/VMEXIT do not flush the TLB. */ > else if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) ) > - hvm_asid_flush_vcpu_asid( > - nestedhvm_vcpu_in_guestmode(v) > - ? &vcpu_nestedhvm(v).nv_n2asid : &v->arch.hvm.n1asid); > + { > + if (nestedhvm_vcpu_in_guestmode(v)) > + vcpu_nestedhvm(v).nv_flushp2m = true; > + else > + v->arch.needs_tlb_flush = true; Flushing the nested P2M when running in guest mode isn't correct. L2 changing its guest CR3 can't affect the nested page tables. > + } > break; > case 4: > value = HVM_CR4_HOST_MASK; > @@ -952,8 +956,7 @@ static void noreturn cf_check svm_do_resume(void) > v->arch.hvm.svm.launch_core = smp_processor_id(); > hvm_migrate_timers(v); > hvm_migrate_pirqs(v); > - /* Migrating to another ASID domain. Request a new ASID. */ > - hvm_asid_flush_vcpu(v); > + v->arch.needs_tlb_flush = true; Isn't this flush when moving to a different pCPU already handled by the context switch logic in the previous patch? > } > > if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) ) > @@ -980,13 +983,14 @@ void asmlinkage svm_vmenter_helper(void) > > ASSERT(hvmemul_cache_disabled(curr)); > > - svm_asid_handle_vmrun(); > - > TRACE_TIME(TRC_HVM_VMENTRY | > (nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0)); > > svm_sync_vmcb(curr, vmcb_needs_vmsave); > > + if ( test_and_clear_bool(curr->arch.needs_tlb_flush) ) > + svm_vcpu_set_tlb_control(curr); > + > vmcb->rax = regs->rax; > vmcb->rip = regs->rip; > vmcb->rsp = regs->rsp; > @@ -1107,6 +1111,8 @@ static int cf_check svm_vcpu_initialise(struct vcpu *v) > return rc; > } > > + svm_vcpu_assign_asid(v); > + > return 0; > } > > @@ -1532,9 +1538,6 @@ static int _svm_cpu_up(bool bsp) > /* check for erratum 383 */ > svm_init_erratum_383(c); > > - /* Initialize core's ASID handling. */ > - svm_asid_init(c); > - > /* Initialize OSVW bits to be used by guests */ > svm_host_osvw_init(); > > @@ -2289,7 +2292,7 @@ static void svm_invlpga_intercept( > { > svm_invlpga(linear, > (asid == 0) > - ? v->arch.hvm.n1asid.asid > + ? v->domain->arch.hvm.asid.asid > : vcpu_nestedhvm(v).nv_n2asid.asid); If we only ever use the L1 domain's ASID, INVLPGA on any other ASID is surely not correct - it could belong to some other L1 VM. The existing code is also incorrect - L1 invalidating using an ASID other than the last ASID it used would not do the correct thing AFAICT. > } > > @@ -2311,8 +2314,8 @@ static bool cf_check is_invlpg( > > static void cf_check svm_invlpg(struct vcpu *v, unsigned long linear) > { > - /* Safe fallback. Take a new ASID. */ > - hvm_asid_flush_vcpu(v); > + /* Schedule a tlb flush on the VCPU. */ > + v->arch.needs_tlb_flush = true; > } > > static bool cf_check svm_get_pending_event( > @@ -2482,6 +2485,8 @@ const struct hvm_function_table * __init start_svm(void) > svm_function_table.caps.hap_superpage_2mb = true; > svm_function_table.caps.hap_superpage_1gb = cpu_has_page1gb; > > + svm_asid_init(); > + > return &svm_function_table; > } > > @@ -2539,6 +2544,8 @@ void asmlinkage svm_vmexit_handler(void) > (vlapic_get_reg(vlapic, APIC_TASKPRI) & 0x0F)); > } > > + svm_vcpu_clear_tlb_control(v); > + Is there a reason to split updating tlb_control into a clear and then later a potential set? This way there are either 1 or 2 writes to it whereas if you unconditionally set it before VMRUN there would only ever be 1 write. > exit_reason = vmcb->exitcode; > > if ( hvm_long_mode_active(v) ) > diff --git a/xen/arch/x86/hvm/svm/svm.h b/xen/arch/x86/hvm/svm/svm.h > index cfa411ad5a..901354e914 100644 > --- a/xen/arch/x86/hvm/svm/svm.h > +++ b/xen/arch/x86/hvm/svm/svm.h > @@ -12,12 +12,8 @@ > #include > > struct cpu_user_regs; > -struct cpuinfo_x86; > struct vcpu; > > -void svm_asid_init(const struct cpuinfo_x86 *c); > -void svm_asid_handle_vmrun(void); > - > unsigned long *svm_msrbit(unsigned long *msr_bitmap, uint32_t msr); > void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len); > > diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c > index 8e52ef4d49..3916ae4468 100644 > --- a/xen/arch/x86/hvm/vmx/vmcs.c > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -778,8 +779,6 @@ static int _vmx_cpu_up(bool bsp) > > this_cpu(vmxon) = 1; > > - hvm_asid_init(cpu_has_vmx_vpid ? (1u << VMCS_VPID_WIDTH) : 0); > - > if ( cpu_has_vmx_ept ) > ept_sync_all(); > > @@ -1903,7 +1902,7 @@ void cf_check vmx_do_resume(void) > */ > v->arch.hvm.vmx.hostenv_migrated = 1; > > - hvm_asid_flush_vcpu(v); > + v->arch.needs_tlb_flush = true; > } > > debug_state = v->domain->debugger_attached > @@ -2116,7 +2115,6 @@ void vmcs_dump_vcpu(struct vcpu *v) > (SECONDARY_EXEC_ENABLE_VPID | SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) ) > printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n", > vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL)); > - > vmx_vmcs_exit(v); > } > > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index 269ca56433..a531145218 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -25,6 +25,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -834,6 +835,18 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v) > vmx_update_secondary_exec_control(v); > } > > + if ( asid_enabled ) > + { > + v->arch.hvm.vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_VPID; > + vmx_update_secondary_exec_control(v); > + } > + else > + { > + v->arch.hvm.vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_VPID; > + vmx_update_secondary_exec_control(v); > + } > + > + > /* > * We can safely pass MSR_SPEC_CTRL through to the guest, even if STIBP > * isn't enumerated in hardware, as SPEC_CTRL_STIBP is ignored. > @@ -1510,7 +1523,7 @@ static void cf_check vmx_handle_cd(struct vcpu *v, unsigned long value) > vmx_set_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW); > > wbinvd(); /* flush possibly polluted cache */ > - hvm_asid_flush_vcpu(v); /* invalidate memory type cached in TLB */ > + v->arch.needs_tlb_flush = true; /* invalidate memory type cached in TLB */ > v->arch.hvm.vmx.cache_mode = CACHE_MODE_NO_FILL; > } > else > @@ -1519,7 +1532,7 @@ static void cf_check vmx_handle_cd(struct vcpu *v, unsigned long value) > vmx_set_guest_pat(v, *pat); > if ( !is_iommu_enabled(v->domain) || iommu_snoop ) > vmx_clear_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW); > - hvm_asid_flush_vcpu(v); /* no need to flush cache */ > + v->arch.needs_tlb_flush = true; > } > } > } > @@ -1871,7 +1884,7 @@ static void cf_check vmx_update_guest_cr( > __vmwrite(GUEST_CR3, v->arch.hvm.hw_cr[3]); > > if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) ) > - hvm_asid_flush_vcpu(v); > + v->arch.needs_tlb_flush = true; > break; > > default: > @@ -3168,6 +3181,8 @@ const struct hvm_function_table * __init start_vmx(void) > lbr_tsx_fixup_check(); > ler_to_fixup_check(); > > + BUG_ON(hvm_asid_init(cpu_has_vmx_vpid ? (1u << VMCS_VPID_WIDTH) : 1)); > + > return &vmx_function_table; > } > > @@ -4931,9 +4946,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) > { > struct vcpu *curr = current; > struct domain *currd = curr->domain; > - u32 new_asid, old_asid; > - struct hvm_vcpu_asid *p_asid; > - bool need_flush; > + struct hvm_asid *p_asid; > > ASSERT(hvmemul_cache_disabled(curr)); > > @@ -4949,33 +4962,9 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) > if ( nestedhvm_vcpu_in_guestmode(curr) ) > p_asid = &vcpu_nestedhvm(curr).nv_n2asid; > else > - p_asid = &curr->arch.hvm.n1asid; > - > - old_asid = p_asid->asid; > - need_flush = hvm_asid_handle_vmenter(p_asid); > - new_asid = p_asid->asid; > - > - if ( unlikely(new_asid != old_asid) ) > - { > - __vmwrite(VIRTUAL_PROCESSOR_ID, new_asid); > - if ( !old_asid && new_asid ) > - { > - /* VPID was disabled: now enabled. */ > - curr->arch.hvm.vmx.secondary_exec_control |= > - SECONDARY_EXEC_ENABLE_VPID; > - vmx_update_secondary_exec_control(curr); > - } > - else if ( old_asid && !new_asid ) > - { > - /* VPID was enabled: now disabled. */ > - curr->arch.hvm.vmx.secondary_exec_control &= > - ~SECONDARY_EXEC_ENABLE_VPID; > - vmx_update_secondary_exec_control(curr); > - } > - } > + p_asid = &currd->arch.hvm.asid; > > - if ( unlikely(need_flush) ) > - vpid_sync_all(); > + __vmwrite(VIRTUAL_PROCESSOR_ID, p_asid->asid); > > if ( paging_mode_hap(curr->domain) ) > { > @@ -4984,12 +4973,18 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) > unsigned int inv = 0; /* None => Single => All */ > struct ept_data *single = NULL; /* Single eptp, iff inv == 1 */ > > + if ( test_and_clear_bool(curr->arch.needs_tlb_flush) ) > + { > + inv = 1; > + single = ept; > + } > + > if ( cpumask_test_cpu(cpu, ept->invalidate) ) > { > cpumask_clear_cpu(cpu, ept->invalidate); > > /* Automatically invalidate all contexts if nested. */ > - inv += 1 + nestedhvm_enabled(currd); > + inv = 1 + nestedhvm_enabled(currd); > single = ept; > } > > @@ -5018,6 +5013,11 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) > __invept(inv == 1 ? INVEPT_SINGLE_CONTEXT : INVEPT_ALL_CONTEXT, > inv == 1 ? single->eptp : 0); > } > + else /* Shadow paging */ > + { > + if ( test_and_clear_bool(curr->arch.needs_tlb_flush) ) > + vpid_sync_vcpu_context(curr); > + } > > out: > if ( unlikely(curr->arch.hvm.vmx.lbr_flags & LBR_FIXUP_MASK) ) > diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c > index e4cdfe55c1..5c0e1226c4 100644 > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -1253,7 +1253,7 @@ static void virtual_vmentry(struct cpu_user_regs *regs) > > if ( nvmx->guest_vpid != new_vpid ) > { > - hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); > + v->arch.needs_tlb_flush = true; > nvmx->guest_vpid = new_vpid; > } > } > @@ -2052,7 +2052,7 @@ static int nvmx_handle_invvpid(struct cpu_user_regs *regs) > case INVVPID_INDIVIDUAL_ADDR: > case INVVPID_SINGLE_CONTEXT: > case INVVPID_ALL_CONTEXT: > - hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(current).nv_n2asid); > + hvm_flush_tlb(NULL); > break; > default: > vmfail(regs, VMX_INSN_INVEPT_INVVPID_INVALID_OP); > diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/include/asm/flushtlb.h > index 345677eb72..081e5a1188 100644 > --- a/xen/arch/x86/include/asm/flushtlb.h > +++ b/xen/arch/x86/include/asm/flushtlb.h > @@ -125,12 +125,6 @@ void switch_cr3_cr4(struct vcpu *v, unsigned long cr3, unsigned long cr4); > #define FLUSH_VCPU_STATE 0x1000 > /* Flush the per-cpu root page table */ > #define FLUSH_ROOT_PGTBL 0x2000 > -#if CONFIG_HVM > - /* Flush all HVM guests linear TLB (using ASID/VPID) */ > -#define FLUSH_HVM_ASID_CORE 0x4000 > -#else > -#define FLUSH_HVM_ASID_CORE 0 > -#endif > #if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING) > /* > * Adding this to the flags passed to flush_area_mask will prevent using the > @@ -190,7 +184,6 @@ void flush_area_mask(const cpumask_t *mask, const void *va, > > static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) {} > > -unsigned int guest_flush_tlb_flags(const struct domain *d); > void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask); > > #endif /* __FLUSHTLB_H__ */ > diff --git a/xen/arch/x86/include/asm/hvm/asid.h b/xen/arch/x86/include/asm/hvm/asid.h > index 25ba57e768..b6df5cda35 100644 > --- a/xen/arch/x86/include/asm/hvm/asid.h > +++ b/xen/arch/x86/include/asm/hvm/asid.h > @@ -8,25 +8,25 @@ > #ifndef __ASM_X86_HVM_ASID_H__ > #define __ASM_X86_HVM_ASID_H__ > > +#include > +#include > > -struct vcpu; > -struct hvm_vcpu_asid; > +struct hvm_asid { > + uint32_t asid; > +}; > > -/* Initialise ASID management for the current physical CPU. */ > -void hvm_asid_init(unsigned int nasids); > +#ifdef CONFIG_HVM > +extern bool asid_enabled; > +#else > +#define asid_enabled (false) > +#endif > > -/* Invalidate a particular ASID allocation: forces re-allocation. */ > -void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid); > +/* Initialise ASID management distributed across all CPUs. */ > +int hvm_asid_init(unsigned long nasids); > > -/* Invalidate all ASID allocations for specified VCPU: forces re-allocation. */ > -void hvm_asid_flush_vcpu(struct vcpu *v); > - > -/* Flush all ASIDs on this processor core. */ > -void hvm_asid_flush_core(void); > - > -/* Called before entry to guest context. Checks ASID allocation, returns a > - * boolean indicating whether all ASIDs must be flushed. */ > -bool hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid); > +int hvm_asid_alloc(struct hvm_asid *asid); > +int hvm_asid_alloc_range(struct hvm_asid *asid, unsigned long min, unsigned long max); > +void hvm_asid_free(struct hvm_asid *asid); > > #endif /* __ASM_X86_HVM_ASID_H__ */ > > diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h > index dd7fa96aad..194343d9bf 100644 > --- a/xen/arch/x86/include/asm/hvm/domain.h > +++ b/xen/arch/x86/include/asm/hvm/domain.h > @@ -140,6 +140,7 @@ struct hvm_domain { > } write_map; > > struct hvm_pi_ops pi_ops; > + struct hvm_asid asid; > > union { > struct vmx_domain vmx; > diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h > index e7c1364802..935d9e7548 100644 > --- a/xen/arch/x86/include/asm/hvm/hvm.h > +++ b/xen/arch/x86/include/asm/hvm/hvm.h > @@ -274,6 +274,8 @@ int hvm_domain_initialise(struct domain *d, > void hvm_domain_relinquish_resources(struct domain *d); > void hvm_domain_destroy(struct domain *d); > > +int hvm_flush_tlb(const unsigned long *vcpu_bitmap); > + > int hvm_vcpu_initialise(struct vcpu *v); > void hvm_vcpu_destroy(struct vcpu *v); > void hvm_vcpu_down(struct vcpu *v); > @@ -497,17 +499,6 @@ static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset) > alternative_vcall(hvm_funcs.set_tsc_offset, v, offset); > } > > -/* > - * Called to ensure than all guest-specific mappings in a tagged TLB are > - * flushed; does *not* flush Xen's TLB entries, and on processors without a > - * tagged TLB it will be a noop. > - */ > -static inline void hvm_flush_guest_tlbs(void) > -{ > - if ( hvm_enabled ) > - hvm_asid_flush_core(); > -} > - > static inline unsigned int > hvm_get_cpl(struct vcpu *v) > { > @@ -901,8 +892,6 @@ static inline int hvm_cpu_up(void) > > static inline void hvm_cpu_down(void) {} > > -static inline void hvm_flush_guest_tlbs(void) {} > - > static inline void hvm_invlpg(const struct vcpu *v, unsigned long linear) > { > ASSERT_UNREACHABLE(); > diff --git a/xen/arch/x86/include/asm/hvm/svm.h b/xen/arch/x86/include/asm/hvm/svm.h > index a35a61273b..1877bb149a 100644 > --- a/xen/arch/x86/include/asm/hvm/svm.h > +++ b/xen/arch/x86/include/asm/hvm/svm.h > @@ -9,6 +9,11 @@ > #ifndef __ASM_X86_HVM_SVM_H__ > #define __ASM_X86_HVM_SVM_H__ > > +void svm_asid_init(void); > +void svm_vcpu_assign_asid(struct vcpu *v); > +void svm_vcpu_set_tlb_control(struct vcpu *v); > +void svm_vcpu_clear_tlb_control(struct vcpu *v); > + > /* > * PV context switch helpers. Prefetching the VMCB area itself has been shown > * to be useful for performance. > diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/include/asm/hvm/vcpu.h > index 2a14fa0a63..8ad2ab2910 100644 > --- a/xen/arch/x86/include/asm/hvm/vcpu.h > +++ b/xen/arch/x86/include/asm/hvm/vcpu.h > @@ -9,6 +9,7 @@ > #define __ASM_X86_HVM_VCPU_H__ > > #include > +#include > #include > #include > #include > @@ -16,11 +17,6 @@ > #include > #include > > -struct hvm_vcpu_asid { > - uint64_t generation; > - uint32_t asid; > -}; > - > struct hvm_vcpu_io { > /* > * HVM emulation: > @@ -76,7 +72,7 @@ struct nestedvcpu { > bool stale_np2m; /* True when p2m_base in VMCx02 is no longer valid */ > uint64_t np2m_generation; > > - struct hvm_vcpu_asid nv_n2asid; > + struct hvm_asid nv_n2asid; For SVM, after the change to svm_asid_handle_vmrun AFAICT nothing sets this other than nestedhvm_vcpu_reset. > > bool nv_vmentry_pending; > bool nv_vmexit_pending; > @@ -140,8 +136,6 @@ struct hvm_vcpu { > /* (MFN) hypervisor page table */ > pagetable_t monitor_table; > > - struct hvm_vcpu_asid n1asid; > - > u64 msr_tsc_adjust; > > union { > diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h > index 08854c36ca..e0d4389f20 100644 > --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h > +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h > @@ -463,7 +463,7 @@ static inline void vpid_sync_vcpu_context(const struct vcpu *v) > if ( unlikely(!cpu_has_vmx_vpid_invvpid_single_context) ) > type = INVVPID_ALL_CONTEXT; > > - __invvpid(type, v->arch.hvm.n1asid.asid, 0); > + __invvpid(type, v->domain->arch.hvm.asid.asid, 0); > } > > static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva) > @@ -484,7 +484,7 @@ static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva) > if ( unlikely(!cpu_has_vmx_vpid_invvpid_single_context) ) > type = INVVPID_ALL_CONTEXT; > > - __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva); > + __invvpid(type, v->domain->arch.hvm.asid.asid, (u64)gva); > } > > static inline void vpid_sync_all(void) > diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c > index 5ccb80bda5..156734d3e0 100644 > --- a/xen/arch/x86/mm/hap/hap.c > +++ b/xen/arch/x86/mm/hap/hap.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -750,18 +751,16 @@ static bool cf_check flush_tlb(const unsigned long *vcpu_bitmap) > if ( !flush_vcpu(v, vcpu_bitmap) ) > continue; > > - hvm_asid_flush_vcpu(v); > - > cpu = read_atomic(&v->dirty_cpu); > if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v->is_running ) > __cpumask_set_cpu(cpu, mask); > } > > + guest_flush_tlb_mask(d, mask); > + > /* > * Trigger a vmexit on all pCPUs with dirty vCPU state in order to force an > - * ASID/VPID change and hence accomplish a guest TLB flush. Note that vCPUs > - * not currently running will already be flushed when scheduled because of > - * the ASID tickle done in the loop above. > + * ASID/VPID flush and hence accomplish a guest TLB flush. > */ > on_selected_cpus(mask, NULL, NULL, 0); > > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c > index 027b9ae69b..9879b4840b 100644 > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -1440,7 +1440,7 @@ p2m_flush(struct vcpu *v, struct p2m_domain *p2m) > ASSERT(v->domain == p2m->domain); > vcpu_nestedhvm(v).nv_p2m = NULL; > p2m_flush_table(p2m); > - hvm_asid_flush_vcpu(v); > + v->arch.needs_tlb_flush = true; > } > > void > @@ -1499,7 +1499,7 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m) > > static void nvcpu_flush(struct vcpu *v) > { > - hvm_asid_flush_vcpu(v); > + v->arch.needs_tlb_flush = true; > vcpu_nestedhvm(v).stale_np2m = true; > } > > @@ -1619,7 +1619,7 @@ void np2m_schedule(int dir) > if ( !np2m_valid ) > { > /* This vCPU's np2m was flushed while it was not runnable */ > - hvm_asid_flush_core(); > + curr->arch.needs_tlb_flush = true; > vcpu_nestedhvm(curr).nv_p2m = NULL; > } > else > diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c > index 14ab7defd8..06053d9a06 100644 > --- a/xen/arch/x86/mm/paging.c > +++ b/xen/arch/x86/mm/paging.c > @@ -938,7 +938,7 @@ void paging_update_nestedmode(struct vcpu *v) > else > /* TODO: shadow-on-shadow */ > v->arch.paging.nestedmode = NULL; > - hvm_asid_flush_vcpu(v); > + v->arch.needs_tlb_flush = true; This unconditional flush is done on every L2 exit to L0. That shouldn't be necessary, but that's not specifically a problem with this patch. > } > > int __init paging_set_allocation(struct domain *d, unsigned int pages, > diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c > index 1b0477ed2b..107d0829f2 100644 > --- a/xen/arch/x86/mm/shadow/multi.c > +++ b/xen/arch/x86/mm/shadow/multi.c > @@ -81,12 +81,6 @@ const char *const fetch_type_names[] = { > > static pagetable_t cf_check sh_update_cr3(struct vcpu *v, bool noflush); > > -/* Helper to perform a local TLB flush. */ > -static void sh_flush_local(const struct domain *d) > -{ > - flush_local(guest_flush_tlb_flags(d)); > -} > - > #if GUEST_PAGING_LEVELS >= 4 && defined(CONFIG_PV32) > #define ASSERT_VALID_L2(t) \ > ASSERT((t) == SH_type_l2_shadow || (t) == SH_type_l2h_shadow) > @@ -2945,7 +2939,8 @@ static bool cf_check sh_invlpg(struct vcpu *v, unsigned long linear) > if ( mfn_to_page(sl1mfn)->u.sh.type > == SH_type_fl1_shadow ) > { > - sh_flush_local(v->domain); > + flush_tlb_local(); > + v->arch.needs_tlb_flush = true; > return false; > } > > @@ -3160,7 +3155,8 @@ sh_update_linear_entries(struct vcpu *v) > * linear pagetable to read a top-level shadow page table entry. But, > * without this change, it would fetch the wrong value due to a stale TLB. > */ > - sh_flush_local(d); > + flush_tlb_local(); > + v->arch.needs_tlb_flush = true; > } > > static pagetable_t cf_check sh_update_cr3(struct vcpu *v, bool noflush) Booting Hyper-V on my AMD test machine with our internal nested virt branch + this patch series fails: (XEN) [ 88.003415] Assertion 'local_irq_is_enabled()' failed at common/smp.c:53 (XEN) [ 88.003419] ----[ Xen-4.23.0 x86_64 debug=y Not tainted ]---- (XEN) [ 88.003421] CPU: 11 (XEN) [ 88.003422] RIP: e008:[] on_selected_cpus+0x9a/0xd4 (XEN) [ 88.003428] RFLAGS: 0000000000010046 CONTEXT: hypervisor (d1v0) (XEN) [ 88.003431] rax: 0000000000000046 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 88.003433] rdx: 0000000000000000 rsi: 0000000000000000 rdi: ffff8310510ddaf0 (XEN) [ 88.003435] rbp: ffff8310510d7cd8 rsp: ffff8310510d7cb0 r8: ffff8310510ddaf0 (XEN) [ 88.003436] r9: ffff8310510eae70 r10: ffff8310510d8230 r11: ffff8310510d7f08 (XEN) [ 88.003438] r12: ffff8310510ddaf0 r13: 000000000000000b r14: ffff83107c52d000 (XEN) [ 88.003440] r15: ffff83107c52d000 cr0: 0000000080050033 cr4: 0000000000f506e0 (XEN) [ 88.003441] cr3: 000000107c51c000 cr2: 0000000000000000 (XEN) [ 88.003443] fsb: 0000000000000000 gsb: fffff87bd9e3b000 gss: 0000000000000000 (XEN) [ 88.003445] ds: 0000 es: 0000 fs: 0000 gs: 0020 ss: 0000 cs: e008 (XEN) [ 88.003447] Xen code around (on_selected_cpus+0x9a/0xd4): (XEN) [ 88.003448] 41 5f 5d e9 60 6a fc ff d6 4c 89 35 f7 9e a0 00 4c 89 3d f8 9e a0 00 (XEN) [ 88.003455] Xen stack trace from rsp=ffff8310510d7cb0: (XEN) [ 88.003457] ffff82d04031fac2 ffff83100c11d000 ffff82d040c45498 0000000000000001 (XEN) [ 88.003459] ffff82d040313e5e ffff8310510d7ce8 ffff82d04031fb33 ffff8310510d7cf8 (XEN) [ 88.003462] ffff82d0403098d2 ffff8310510d7d10 ffff82d040313e94 000000000000000b (XEN) [ 88.003464] ffff8310510d7d28 ffff82d04023b6b1 ffff82d040c45498 ffff8310510d7d40 (XEN) [ 88.003467] ffff82d04037ab68 ffff8310140aefb0 ffff8310510d7d78 ffff82d04023b59f (XEN) [ 88.003469] ffff83107c52c2f0 ffff83107c52d538 ffff83107c52d000 0000000000004d01 (XEN) [ 88.003472] ffff83107c52d000 ffff8310510d7d90 ffff82d040313fce ffff83107c52c2f0 (XEN) [ 88.003474] ffff8310510d7db8 ffff82d040330164 ffff83107c52c2f0 ffff83107c52d538 (XEN) [ 88.003477] ffff8310510d7fff ffff8310510d7dd8 ffff82d040330259 ffff83107c52d4e8 (XEN) [ 88.003479] ffff83107c52d538 ffff8310510d7e00 ffff82d0403305bc ffff83100c11d000 (XEN) [ 88.003482] 0000000000004d01 0000000000004901 ffff8310510d7e38 ffff82d04030b25f (XEN) [ 88.003484] 00000000c0000080 0000000000000001 00000000c0000080 0000000000000001 (XEN) [ 88.003487] ffff83100c11d000 ffff8310510d7e80 ffff82d04030b580 0000000000000000 (XEN) [ 88.003489] 0000000000000000 ffff8310510d7f08 ffff83100c119000 ffff83100c11d000 (XEN) [ 88.003492] 0000000000000002 0000000000000000 ffff8310510d7ef8 ffff82d0402e71db (XEN) [ 88.003494] ffff82d0402024f2 ffff82d0402024f8 ffff82d0402024f2 ffff82d0402024f8 (XEN) [ 88.003497] ffff82d0402024f2 ffff82d0402024f8 ffff82d0402024f2 ffff82d0402024f8 (XEN) [ 88.003499] ffff83100c11d000 0000000000000000 0000000000000000 0000000000000000 (XEN) [ 88.003502] 0000000000000000 00007cefaef280d7 ffff82d040202542 0000000000000000 (XEN) [ 88.003504] fffff87bd9e00000 0000000000000000 0000000000000400 ffffe70000005a40 (XEN) [ 88.003507] Xen call trace: (XEN) [ 88.003508] [] R on_selected_cpus+0x9a/0xd4 (XEN) [ 88.003512] [] S arch/x86/mm/hap/hap.c#__flush_tlb+0x84/0xd4 (XEN) [ 88.003514] [] F arch/x86/mm/hap/hap.c#flush_tlb+0x21/0x27 (XEN) [ 88.003518] [] F hvm_flush_tlb+0x21/0x2a (XEN) [ 88.003520] [] F arch/x86/hvm/nestedhvm.c#nestedhvm_flushtlb_ipi+0x36/0x51 (XEN) [ 88.003522] [] F smp_call_function_interrupt+0x63/0xd2 (XEN) [ 88.003525] [] F smp_send_call_function_mask+0x3c/0x3f (XEN) [ 88.003527] [] F on_selected_cpus+0xb9/0xd4 (XEN) [ 88.003529] [] F nestedhvm_vmcx_flushtlb+0x21/0x4b (XEN) [ 88.003532] [] F p2m_flush_table_locked+0xb8/0x167 (XEN) [ 88.003534] [] F arch/x86/mm/p2m.c#p2m_flush_table+0x46/0x330 (XEN) [ 88.003537] [] F p2m_flush_nestedp2m+0x42/0x4f (XEN) [ 88.003540] [] F hvm_set_efer+0x15a/0x167 (XEN) [ 88.003543] [] F hvm_msr_write_intercept+0x314/0x3f8 (XEN) [ 88.003546] [] F svm_vmexit_handler+0x12e9/0x1925 (XEN) [ 88.003549] [] F svm_asm_do_resume+0x162/0x172 (XEN) [ 88.003550] (XEN) [ 88.511287] (XEN) [ 88.513714] **************************************** (XEN) [ 88.520429] Panic on CPU 11: (XEN) [ 88.524600] Assertion 'local_irq_is_enabled()' failed at common/smp.c:53 (XEN) [ 88.533449] **************************************** Ross From xen-devel-bounces@lists.xenproject.org Fri Sep 18 16:58:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 16:58:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425720.1649546 (Exim 4.92) (envelope-from ) id 1x7bvF-00053G-6K; Fri, 18 Sep 2026 16:58:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425720.1649546; Fri, 18 Sep 2026 16:58:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7bvF-000539-3B; Fri, 18 Sep 2026 16:58:49 +0000 Received: by outflank-mailman (input) for mailman id 1425720; Fri, 18 Sep 2026 16:58:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7bvD-000532-IK for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 16:58:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7bvC-00F6tx-VQ for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 18:58:46 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad6da4-e002-0a2a0a5209dd-0a2a45089a5c-30 for ; Fri, 18 Sep 2026 18:58:46 +0200 Received: from [205.220.168.131] (helo=mx0a-0031df01.pphosted.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad6dc4-f659-0a2a45080019-cddca8838444-3 for ; Fri, 18 Sep 2026 18:58:46 +0200 Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68IGoBf11347056 for ; Fri, 18 Sep 2026 16:58:44 GMT Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4gs72u0nwm-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 18 Sep 2026 16:58:44 +0000 (GMT) Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-cc4b524ce78so668414a12.2 for ; Fri, 18 Sep 2026 09:58:44 -0700 (PDT) Received: from localhost ([143.246.51.243]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cc5c50e7433sm1426162a12.28.2026.09.18.09.58.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 09:58:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-Id:Mime-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="In-Reply-To:References:To:From:Subject:Cc:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= FmJ9l5QFBMMe48wI+FnvFQSDXsCaB79a0WihlyuJstA=; b=F862iJklfTEspXfc UjvRsNylWUiwop35P1muhLn10HTOL/M7stdoCV5Frgx1dJJyqJCtb9FvturdV8sv z3alBIEzMWiVlVthfKBVozYtF7rTFVwi4etMJQaCL3Xb1OMzWcr3mo94SqS0NKef R2spGU2cf3Z4YDgyNC0YvETba6iLNRQtX+MmCmDbez6Y2pZzcL6/1A49LPfbZR3+ EwSgfygJ0q8qQ9GphKHYvddiZI3X3ZqEQSOuyLKfi60D+5Gm3ZpMKc/Bkp7QtCxC 19jlA5mLGS4eEQmM2YLhernOpYqFKGMWVlTYHqEyqO4snc1SdLMMuu7ckn2KAGe8 b6XcSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1789750723; x=1790355523; darn=lists.xenproject.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=FmJ9l5QFBMMe48wI+FnvFQSDXsCaB79a0WihlyuJstA=; b=jJDLv31yYeE5dDXlp/Z9G1ste+iKtZbbWSH+zJOxQFPXy8UUS8Jtwo+K07Qew524DD 1sW9li8r6RRgC55Xvi6u3w8t6co2pF49NimKVdzTDs4vVopWyB3xVSwh9iq5EjdYwDiI D4pSovVB0wYPhknEIbZcqFZRLm13JDD8kzzGrvBCjc7kxtPZKCPMR3Q45b43mLOqUTi7 tRjUNREct8Us3trDGAh1Q19F8AeJpfYE432ajvLBamCNROXzi2SNYvMHGPWzlO8CsWar IuJQhFhVrOajc9wZCPXVO21sZiQz+RAxpGmjywiTvoVFv05oVZaPOFD+vv0piHkZVLbq dqJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789750723; x=1790355523; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=FmJ9l5QFBMMe48wI+FnvFQSDXsCaB79a0WihlyuJstA=; b=tU4YtYH9Es7E0vVATWwD6tIh6VDKHzGy+2FoBAAbnrGJKL7e9uOHs4jvhYvTfpbwkF ywH2/aJFNKHiZ0QbNsOVVzNm25v05sAMQgbLIgA0GBXZx7pwuQGvTsIJ9A5W2UwtENEa BHGAwdHXpC0CyUb3XTUO+AW9U5tzjAOTaVqzMlyDF4a38FC0wu8ryGoqz/5esmTaf5Np T55IYHNqyswhMMr/7b1BUGMpuc1v8zgCXOJZuyI4YI9QJ+rwUEJUagoKpp/C3Y4pd0c2 oSYk9DLv5L3f0CUf30DRSlZsWFSNkL7/TgknibgE4q8SFn6b9hRDBdK2c47zivUNQi+z oKfQ== X-Forwarded-Encrypted: i=1; AKwUvBzJ9LFyAOCsFLNFJl0SPTigRrHyZd5eVz6EHWaXY+BFNm6K9egLonjBboO0J0+SknsUXKB5lq7Hioo=@lists.xenproject.org X-Gm-Message-State: AFuF++kzcVmzp92E9cFoZWMZIivFhBG1VBYL9q4c/Ts7zf5YfVFLCLLP +aMbFIUajar5x3/IhEJ5Pe7yWaK8Otksi+sjWHo1jByUOp3RNGcBE6ucIwBTDHuuV6lW5zNVmGi zXx8Ym1KBrcjzTFqNQTi8kS+Z0PX98sSrwWjFAghDtqx5wiIBqs3VpSSTWymGm6ndkKzG8w== X-Gm-Gg: AYBFou23DctS1WmDjS2Q9YgNErTHba57V6nZQXvR4J88+bnHXejJr39sPAR1Fr4CSvI VmM+ETivJ3zefXSDVry0l/QkymKuOEJNvy2FH8a5F1v94u+p439Nb38wwQiP9/F4WOoz3HHezbr JY/+BznbTwCtXL+m4uP42VsPC5ND/eUJ3PLLRNWHznrvJhZbkflGfF3StU+rYLU10/5XAK/BxAG Ukh8FELrSdaBWd16G7pDGGP+JKx1iZIZS+MH9NZuU7uUggVROrbPdRWxacBeOfbaHStm9D6zqCQ kptyMleQTrJXHhXbObZWlWuL/EOipJi7jf+2SDZc2xw1WaIB0JzCTFS+kJx9zfPo+Z2arrB3jdS 2rYCJYw== X-Received: by 2002:a05:6a20:d707:b0:3dd:a195:fa0e with SMTP id adf61e73a8af0-3dda195fd95mr361304637.51.1789750723373; Fri, 18 Sep 2026 09:58:43 -0700 (PDT) X-Received: by 2002:a05:6a20:d707:b0:3dd:a195:fa0e with SMTP id adf61e73a8af0-3dda195fd95mr361267637.51.1789750722830; Fri, 18 Sep 2026 09:58:42 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 19 Sep 2026 00:58:17 +0800 Message-Id: Cc: , , , , , Subject: Re: [PATCH v3 1/2] drm/imx/lcdc: avoid duplicate clk_per enable From: "Ze Huang" To: "Thomas Zimmermann" , "Ze Huang" , "Alexey Brodkin" , "Maarten Lankhorst" , "Maxime Ripard" , "David Airlie" , "Simona Vetter" , "Joel Stanley" , "Andrew Jeffery" , "Frank Li" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "Linus Walleij" , "Hans de Goede" , "Alex Lanzano" , "Oleksandr Andrushchenko" , "Philipp Zabel" , =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= , "Marian Cichy" X-Mailer: aerc 0.22.0.r10.g73f20125 References: <20260727-drm-simple-kms-removal-v3-0-de36e534f7a1@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-1-de36e534f7a1@oss.qualcomm.com> In-Reply-To: X-Proofpoint-ORIG-GUID: 6QyOg1d8mn6FBGxlNMoJl3GAz_eJW4o9 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE4MDI0MiBTYWx0ZWRfX/Z52rwxuHshd oAD8GbFJBCoOxMTTtZB6vnbIxbrqtER/xbcwN0e4UJkg7JxRSMA+uYJRbNnIJ0t5vguibPHZYCu 1ZOF5JzQW4aVmiMxZDaBIkZD1i2N3fA= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE4MDI0MiBTYWx0ZWRfX4NAr/0gOaw10 A4hou6QvCPAIXKuKpK2gXyIckKyrJY5pjNle+PNu8fPOgV01FiEfA8onKUl7dLtBtSkjs4sh4Lg iDf7aikjLSIQXelS6O/Mxc9k8njXypi6ksyr1QBPlsZQLN9wVWX2DfVLZ9Q3RpO/qKwsI+iDJu0 6S4E1yZYxOTlBnqXpe4gE1WHY5+abCGbafLxz+jzKrBTi6lZiqKIxjl+xiZCbNLJlW9AXdS4tVB mgsSJEccP2elBF8q7USjmnqskpGx119kJLensAGq7PP4SbXIoEYmluUNtXSsHUkysqqQAMhOWWL XucVBI3wwOriB2CV3JDfv7scQty7YtRDXNB6GM7Wd4STaKD+83pgqaxEVeDL9Ojqk5+SfM14gL2 pXJxaliUaAxhQSZYqrRiVAoX+lM0z7ipvv2VW6JaTLp4vSQNpzhizsPSx4Xd11z1Q/eMY95uQ2t ee+UO3ennUA8HJP1PCw== X-Proofpoint-GUID: 6QyOg1d8mn6FBGxlNMoJl3GAz_eJW4o9 X-Authority-Analysis: v=2.4 cv=DO8acCNb c=1 sm=1 tr=0 ts=6aad6dc4 cx=c_pps a=Qgeoaf8Lrialg5Z894R3/Q==:117 a=LNnhWNgewsfctp/cwirQdA==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22 a=EUspDBNiAAAA:8 a=gNeoJdBQTLUQTwsD9V0A:9 a=QEXdDO2ut3YA:10 a=x9snwWr2DeNwDh03kgHS:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-18_05,2026-09-16_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 suspectscore=0 bulkscore=0 adultscore=0 spamscore=0 malwarescore=0 phishscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609180242 X-purgate-ID: tlsNG-c1860d/1789750726-D4D7087B-B6522880/0/0 X-purgate-type: clean X-purgate-size: 2316 On Wed Sep 16, 2026 at 2:24 PM CST, Thomas Zimmermann wrote: > Hi > > Am 26.07.26 um 21:42 schrieb Ze Huang: >> The simple-KMS helper calls the pipe update after enabling the CRTC. >> On an enable commit, imx_lcdc_pipe_enable() already programs the >> mode and enables clk_per. The following pipe update sees the plane move >> from no CRTC to the active CRTC, treats it as a mode update, and calls >> imx_lcdc_update_hw_registers() again. >> >> That second call has no old CRTC state to disable clk_per first, but it >> enables clk_per again at the end. The disable path only drops one >> reference, leaving clk_per enabled after each on/off cycle. >> >> Skip the register update from the pipe update path when the CRTC already >> needs a modeset. The enable path has already programmed the hardware for >> that commit; keep the event handling in pipe update unchanged. > Thanks for your review. > That seems reasonable. Once the driver uses regular DRM helpers instead= =20 > of simple_kms,=20 > it can all be untangled and this test won't be necessary any longer. Yes, that's the goal. IMO it's better to spilt the operations in imx_lcdc_update_hw_registers() or distinguish the caller. However, it might be risky to make big changes without hardware validation, I think it accpetable for now. > >> >> Fixes: c87e859cdeb5 ("drm/imx/lcdc: Implement DRM driver for imx25") >> Signed-off-by: Ze Huang > > Acked-by: Thomas Zimmermann > >> --- >> drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c b/drivers/gpu/drm/imx/l= cdc/imx-lcdc.c >> index f52832b43aca..81024f7d9e96 100644 >> --- a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c >> +++ b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c >> @@ -311,7 +311,8 @@ static void imx_lcdc_pipe_update(struct drm_simple_d= isplay_pipe *pipe, >> else if (old_crtc !=3D crtc) >> mode_changed =3D true; >> =20 >> - imx_lcdc_update_hw_registers(pipe, old_state, mode_changed); >> + if (!drm_atomic_crtc_needs_modeset(crtc->state)) >> + imx_lcdc_update_hw_registers(pipe, old_state, mode_changed); >> =20 >> if (event) { >> crtc->state->event =3D NULL; >> From xen-devel-bounces@lists.xenproject.org Fri Sep 18 17:05:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 17:05:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425729.1649556 (Exim 4.92) (envelope-from ) id 1x7c1v-0006bZ-TS; Fri, 18 Sep 2026 17:05:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425729.1649556; Fri, 18 Sep 2026 17:05:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7c1v-0006bS-PY; Fri, 18 Sep 2026 17:05:43 +0000 Received: by outflank-mailman (input) for mailman id 1425729; Fri, 18 Sep 2026 17:05:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7c1v-0006bK-9Q for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 17:05:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7c1t-006mVJ-T5 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 19:05:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad6f54-e002-0a2a0a5209dd-0a2a450b858c-26 for ; Fri, 18 Sep 2026 19:05:41 +0200 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad6f64-b7e8-0a2a450b0019-cddcb483e4a6-3 for ; Fri, 18 Sep 2026 19:05:41 +0200 Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68IGoPFV1211846 for ; Fri, 18 Sep 2026 17:05:39 GMT Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4gs23922r6-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 18 Sep 2026 17:05:39 +0000 (GMT) Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2dc7337e2a7so12882595ad.0 for ; Fri, 18 Sep 2026 10:05:39 -0700 (PDT) Received: from localhost ([143.246.51.243]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ddb75ae73csm11519845ad.57.2026.09.18.10.05.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 10:05: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-Id:Mime-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="In-Reply-To:References:To:From:Subject:Cc:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= QMjXKTddFP/KRl7r6fg9f8x2YOcB9udmZHxfTy35BWA=; b=WMMuEWXHWJBv/taD f9QZUlE46GdUzuTjYYf/C3doWA0kR+Y5MgruXgzoDKrnaUUWblDlcnoq62X0pGZb /qbl9/Nh08g2JIywKdvQgqoIFODG95dmBYMwKhKE8pfH/9GV1s9uiIZ/ny0o1Ct9 AxCx/8lN1sOSKnfJuvaS1JUg9GiNW/atd+A2FpRM9LBALe3ZTIKYfBJ7XUzkVsAm /0Sfv53h7nA91Txh3LNTG0XJ02vyxwLdjN4jnrj+2hSOYEPJdtabTGR3PdaWxCxi qwYwhp2WIMT4a5wkgjtCyWIgf1y9m/+GKe3lh+g7l4PT8AQ6cRmW8HyvIVAcaiX9 oOwVlA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1789751139; x=1790355939; darn=lists.xenproject.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=QMjXKTddFP/KRl7r6fg9f8x2YOcB9udmZHxfTy35BWA=; b=Ji0Cq8X43PZ/3yRrGbdtrbHFI3r86UiL3YIFbijELY74R76aWW98PHB4UOHEINxyTf LYYjdgH9dsmc8daZ5BvBOh5Mi0iziJJFBw8UUuWCLR4T2KEfe8QNZ87CPypCBWnXyh3x KcVXfa5LwXfMfJ7nhA/1Mld/DjfrrmLkY1Frj7wbu+yWva0qwg0oCFWHo0fPcx1/ifwe 8OrYVFaszWUx9oK96z2l0zDO0g3gRGgdHRRurlo3bp/KmdYJhak9ZH1i/rs+BZsh41ca W1G9vlaL0L8ifctTlvv6vCLiSrqFcalkV1Lip4koK36WJ9iFS5511T7uVUBi/+0+uE35 OQjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789751139; x=1790355939; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=QMjXKTddFP/KRl7r6fg9f8x2YOcB9udmZHxfTy35BWA=; b=K/NqFZeuhRj0EJV2AUAM+WhHHUlWtRtjBGzcBe6923lXOYbH1w5918LgBDL8Pzeoug xflggiz0oObidY4luuRfzsY2srhdelXrFX3GrJ6czm18+uOkPIKMPFrZkwk0x8fjB3YQ 95qcOfW98STBlSsHnExt7+aIwmgcmOuxwKDDHh1+wFuiVjY1I9OpHwWwPDt45MMkf8/h fmgocK3VWpGb8IwJD9XM943vIRn9z0MvW9UCtj5QezedQzbSzERXQS8/LmRL4GbgNvce ITru7qY/ybpwuPtvOrb/jG/qrZC+gCpKfm4XpUksF3Lf5aiI9fS+aX+QhtSrCtdsQ/M/ ifJA== X-Forwarded-Encrypted: i=1; AKwUvBxjnJV8fIGuwR268d5zlDjjbxO61aLL/gFTjCDJeJUycXDSG1saUggmRMg3yuwQD3wvvL/JpC5+diY=@lists.xenproject.org X-Gm-Message-State: AFuF++nN4kQsCVT6aa9QOHv9xdRIX4v+R4E0qnleN5NeND+jbirimZGG wVqB7TtcCKExhr6z+bJ4++7rF4/+1tFmB3uSeUQU7YbEfTBObzmQ8sqLPct7bFwBvDV4mWVTX7y aOMLmyHx+fM2H0BxxV1UO0LuGRz3sgodUVne3oDbCkjx3hix6ryLigZcsqvtKYGWLGchW7w== X-Gm-Gg: AYBFou3eroPvzJ6PUHeU1vSOzR/FhexQCZOKnvRW2m5zxvLV8EycTvdslb2q4vlNOjP joXwOzc7BMTlIW/JyUHxyXfUZRgue++0RNwD0WU4B+RD31pfzUGlKMqjWFghCVCwuN5YNmTzqua BDl7hxwFd2bhZ0g5SFDTh+nGLiPDyDi615iYDRxj60ytpr/gXgGclvzmCNR5JyMVbYAP5NZ6+Cw Bz3fVwU2+jZvI6kA6usQtMblMt+1BbijcaIep2eY/eKNrV32kabx3Msj+x7y5K7JRpnX8usf8Nr 3RO+E38gM4ifx6d5VhWUr9aHxxBgtRvR0ijwQ8CtIYW5rCfCwMt8yzSM31Fe1Lbvn40cjilPM+W 1F5/7DQ== X-Received: by 2002:a17:902:fc50:b0:2dd:c053:e0f6 with SMTP id d9443c01a7336-2ddc053e13emr7876625ad.37.1789751138499; Fri, 18 Sep 2026 10:05:38 -0700 (PDT) X-Received: by 2002:a17:902:fc50:b0:2dd:c053:e0f6 with SMTP id d9443c01a7336-2ddc053e13emr7876085ad.37.1789751137947; Fri, 18 Sep 2026 10:05:37 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 19 Sep 2026 01:05:13 +0800 Message-Id: Cc: "Ze Huang" , "Alexey Brodkin" , "Maarten Lankhorst" , "David Airlie" , "Simona Vetter" , "Joel Stanley" , "Andrew Jeffery" , "Frank Li" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "Linus Walleij" , "Hans de Goede" , "Alex Lanzano" , "Oleksandr Andrushchenko" , "Philipp Zabel" , =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= , "Marian Cichy" , , , , , , Subject: Re: [PATCH v3 2/2] drm/imx: replace struct drm_simple_display_pipe with regular atomic helpers From: "Ze Huang" To: "Maxime Ripard" , "Thomas Zimmermann" X-Mailer: aerc 0.22.0.r10.g73f20125 References: <20260727-drm-simple-kms-removal-v3-0-de36e534f7a1@oss.qualcomm.com> <20260727-drm-simple-kms-removal-v3-2-de36e534f7a1@oss.qualcomm.com> <8e4c84be-5c89-4d84-adda-aad4c7de0c8a@suse.de> In-Reply-To: X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE4MDI0NSBTYWx0ZWRfXz9lnGZRlra3V w0w99TSEKX/5CQgtJyckvjLQnx3/1HX8ueBQ5cW8Cy2bGMe6D/KBukHwiKoXLV1KuJXyevmpluN JmoxOGsraYuOgmgY9nSW8Zv1fFzfK68= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE4MDI0NSBTYWx0ZWRfX3Vm8f3f+XIak /Aq1RrGImoDR/CDaSN3V27L5sPSrBhOsJNE0FnGDIWwMp3qTkhzFFoDw27VhzRVMKCAj+luDQFw P7ka4wu235mRT1sU7/sycC2gJ2wxpsGXdhRpAY/oJP4iYvsGnChpBhgx1fyh1ZXUChJM7LpJEOH GvUeTw4vWB5sZbvKjCdw9jmd80HUHloFIxhYpByG0wYRIhBbzKdnJy5684Y1FDHSOZ0DMQ2+KI6 c2m0v1lK33sP1wkqtD9zUM4Z3Fvmjjnyctq14dwHn4YPBj8sKUZ4rk1edY1C/+Eo8xo3fmy9Q6G QOvDcEl8wBFOAHr3B07YCzJLFLmEYIwkyE6P4BYxH/c3krA0VTl+ZAHVuvb6NWbK+tMSMlTsZ7v 5FyQz68LUVGtRS+htSSxVaJKBK3rumzxD3PH2+pyd1Riyjz0Ny1V+Xpx2f+hCtgp0b9MnGYEEFy O564Iyz+86isDd+mPRA== X-Proofpoint-ORIG-GUID: 7H4dEN8HV7w13PDUh-9Jw7JTAefMxiJO X-Authority-Analysis: v=2.4 cv=I7zw19gg c=1 sm=1 tr=0 ts=6aad6f63 cx=c_pps a=IZJwPbhc+fLeJZngyXXI0A==:117 a=LNnhWNgewsfctp/cwirQdA==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=IqZAcGRvIuv5jEvzszIA:9 a=QEXdDO2ut3YA:10 a=uG9DUKGECoFWVXl0Dc02:22 X-Proofpoint-GUID: 7H4dEN8HV7w13PDUh-9Jw7JTAefMxiJO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-18_05,2026-09-16_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 clxscore=1015 impostorscore=0 priorityscore=1501 adultscore=0 phishscore=0 malwarescore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609180245 X-purgate-ID: tlsNG-42698a/1789751141-A8CCF9EA-D6827E69/0/0 X-purgate-type: clean X-purgate-size: 702 On Wed Sep 16, 2026 at 3:46 PM CST, Maxime Ripard wrote: > On Wed, Sep 16, 2026 at 08:50:21AM +0200, Thomas Zimmermann wrote: >> > +static const struct drm_plane_funcs imx_lcdc_plane_funcs =3D { >> > + .update_plane =3D drm_atomic_helper_update_plane, >> > + .disable_plane =3D drm_atomic_helper_disable_plane, >> > + .destroy =3D drm_plane_cleanup, >> > + .reset =3D drm_atomic_helper_plane_reset, > > Also, this needs to be drm_atomic_helper_plane_create_state > >> > +static const struct drm_crtc_funcs imx_lcdc_crtc_funcs =3D { >> > + .reset =3D drm_atomic_helper_crtc_reset, > > and drm_atomic_helper_crtc_create_state > > Maxime Thanks for the reminder. Will do. Ze From xen-devel-bounces@lists.xenproject.org Fri Sep 18 20:11:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 20:11:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425856.1649563 (Exim 4.92) (envelope-from ) id 1x7evg-0004r3-42; Fri, 18 Sep 2026 20:11:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425856.1649563; Fri, 18 Sep 2026 20:11:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7evg-0004qu-1H; Fri, 18 Sep 2026 20:11:28 +0000 Received: by outflank-mailman (input) for mailman id 1425856; Fri, 18 Sep 2026 20:11:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7eve-0004qo-Pf for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 20:11:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7eve-000F4A-6g for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 22:11:26 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad9ad6-e002-0a2a0a5209dd-0a2a450c8966-20 for ; Fri, 18 Sep 2026 22:11:26 +0200 Received: from [209.85.208.181] (helo=mail-lj1-f181.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad9aed-f479-0a2a450c0019-d155d0b5a819-3 for ; Fri, 18 Sep 2026 22:11:26 +0200 Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-3a49a40209dso13095811fa.0 for ; Fri, 18 Sep 2026 13:11:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1789762285; cv=none; d=google.com; s=arc-20260327; b=UlTreZ9Rz2TZlelQx3rlI3wBpj/j0XvQQKxZRc7yUP1ACyvhmBVdN/K6gcjD8+5KKp w+bA5R7lGG+Fs+AtlUiXRR73I5f5DSNxuea4BmNNS+QNMxLcVLp6+xS4/ZjNr2YsoUx/ gMpVoe8JDldUDTJLIOTbJaBjzOI10NSFEaR2wc/ubTw+jZRC4D/1FTjQPvnK+HZ2oWvb Y1aYLhN4nj4BH2GAKML23EYwHiIrKbN/Zk3SrCFy1+Z20orqFfOpxFHJGJH/kGl2FxIq L/yBkKMVIs7pA5sOPlY9QtHQ2CTjmWFFqv2w04Z7eOJqVaRyXPr730RWdcnmxcCiuc6P wn1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RjXqA35r57hnuOa5Guy5jxZ/xx19lYaIb7I9ZDD1OL4=; fh=8qrorWp5mU6HGMgfX45u2S7N0Hai0jOoVMQ5u+MxS64=; b=iQGxcw3cjg1wKK8Bv2BlEO+GtzT18g3KGI9qRI+fPsndcb/PJTbiiDa+GVBg4C0hJI IOeIxBMABRA/hEsxwLP+LYx2jBsiO8qQn3LoM0CKeH1B6AxNzO7BhkQTcrcYuHkGBa8f 9LTUYUL8DC9Unt1WOerqeV0opqPVt3KF2k+Mj3b92pLZgCY9ref/9gZzVNKO2C8A7p+X +TVvGAUe0MFIY6EV/No2qVZW5nCc1iqervvSEZDkFMzfs8+z8p0etFo26ciy3rB2pUIa tNSLh0IWGjmovWmIi2EOTRQG2d4Ipw0ZNefaWNpfcRnMh1Fm3u90GiGLc4YQT9Grl9cv 3q5g==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789762285; x=1790367085; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=RjXqA35r57hnuOa5Guy5jxZ/xx19lYaIb7I9ZDD1OL4=; b=TnFHH8iTEYNBa+vb179BavuFFsG2UxxXO9VLu8ofzkqyQIycWDv+fg5hrxZIaNScnF T1+o/dLYDr4Ps0a8PtrIJ5tuyCCXq9NLuM8maIOnOTq8fZ/sx2cIlEjYISd1BOCGy5hE fcLk16C4/+9o2RwFUROmcre7bCtDkHWSeQY9+hyeov/y+EULNmjgVPsgZmOIIX1c1b07 15qWtFo0NT8dL34iEQ2WIRR2A187l/RP8aAnl4X3L//Qm7jlMNK9chmUkiCFPDVgUe95 mFxO3J07NIFNRulE9wdj7k1rVTn9kuzO62627c4dtMj20FYpDY8gwO5lXciQ0G0rK7lj cZFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789762285; x=1790367085; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=RjXqA35r57hnuOa5Guy5jxZ/xx19lYaIb7I9ZDD1OL4=; b=ZEvMVhv6g4uE8LIRwmys+47p5BAlb62BhWnje8gIiV/WnxfpqZHRBE31+OQdV+sK4F UrjAw+THff0CrgEVLllZpAkwKijPUzj75ba8sBqukahFB7daDyWY/aasNKq/5jQbcJhA UgsDwqyyyGumxr7xvYrNCSvty5z7F4d+spHtWa3vZRHknIt4FjL+SuYlwK8WwDXeC6SP saQ9PFday1Y/tHxlBXpiKktdgSMcinqfFUagAVPyvd2pk8u12eO3CQmZDvixOAK/w520 k95vEBc15+f1SYyNzQP34dswm0dyVMpEfH8hxS6r+D3U2K//YrFIWIYfjTOxxYRMGEgj yDGw== X-Forwarded-Encrypted: i=1; AKwUvBwSYlAGfEmOiUPlZDf2Bj/LRAx9TWxgftpNZJ4+NuVcbM3MHSonqcJiSHL3qLbLZZL5ypNGU1OBDzQ=@lists.xenproject.org X-Gm-Message-State: AFuF++mMWrqxhyTD93AeojwfcpHO8nu9B7xiV6Udp0sHnbJB4fhAFtCY WrqHUw5c5GkT59xzkKCZDIp2pCeU4EJ3LUZi/9NsBQXiOIFG3NqgeFPOlVtWmH5+J9YURAAI7m7 O6KuwvDuTX7Vmp71i894sV0NE2vz5ia0= X-Gm-Gg: AYBFou3+gPGbgignZJIPFnzZLrDPyX+xp+rSYuD4wnWxsr2AgwKTH1/ybJtcxGtruBA KNz3lKJq7ihpC//tWuFkuAhM/LAq/9trT7GiHlmosWawPkDjIkJqqsZb8KwiCMeaGTW9U2LMnW+ Pg2uRhGRn/Xi+3czRB9nYVjtwcEO4KLhDUEKYNTSq1RB0+iYEE8HBEcivgMmd4c464qGQ+TU6Bs K8jWaSvzYdoOSoT4A2SPKU2I7hFQZqGx59IVsPWltm4dJvGoDESiWAQGTd5OFh9CPT94Qt2ywUF Ge4zI2bnTIv2F8Lq53SIWc1L3oFcvWirpmESRdaecWBq1hUDOr/EYZEM X-Received: by 2002:a05:651c:a332:b0:3a4:8e54:562 with SMTP id 38308e7fff4ca-3a5e72887c0mr23728131fa.7.1789762285055; Fri, 18 Sep 2026 13:11:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mykola Kvach Date: Fri, 18 Sep 2026 23:11:14 +0300 X-Gm-Features: AcwNN1V_KbA5WvJDMDtxQRX4T9C_CIgIZ4qrzFv_OucX5rM4pnYoOhtBfvIduYM Message-ID: Subject: Re: [RFC PATCH 00/19] GICv4 Support for Xen To: Bertrand Marquis Cc: Mykyta Poturai , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1789762286-00ECAA5B-12A38958/0/0 X-purgate-type: clean X-purgate-size: 9942 Hi, Following up with another round of tests for this RFC. The posted series covers GICv4.0; I tested an expanded version with additional patches for GICv4.1 on AWS c7g.metal. The extra patches add GICv4.1 ITS commands, vPE table and residency handling, default doorbells and direct vSGI delivery, plus interrupt-state fixes. The results below apply to this extended series, not to the posted RFC alone. Source branches: Network OFF/ON: [1] Network BASE: [2] NVMe OFF/ON: [3] Additional patches after the rebased GICv4.0 part: [4] Workloads run in Dom0 with Credit2 and iommu=3Dno. Within each test series, OFF and ON use the same Xen binary with direct mode disabled or enabled. Network tests also include a matched BASE build without the series. All network builds have CONFIG_DEBUG disabled. The network sender is c8gn.4xlarge. ON versus OFF: - NVMe: peak IOPS are unchanged. Scheduled Dom0 time per I/O falls by 4.2-6.1%; handled Xen IPIs fall by 98.2-99.7% at total QD64. - UDP4: received PPS is almost unchanged; scheduled Dom0 time/GiB falls by 7.6-10.0%. - UDP8: received PPS rises by 1.7-12.9% at the same offered rates; scheduled Dom0 time/GiB falls by 16.8-24.0%. The PPS gain is subject to the CPU0 interrupt-routing limitation described below. The UDP tests use 64-byte payloads at total offered rates of 800, 896 and 1000 Mbit/s. The PPS differences describe packet delivery at these rates, not a measured increase in maximum sustainable PPS. The UDP8 PPS gain needs a qualification. In BASE/OFF, all recorded physical LPI-handler entries occur on pCPU0, even though guest IRQ handling is spread across vCPUs. At a total input of 800 Mbit/s, vCPU0 accumulates about 30 scheduled seconds in a 30-second trial, and its flow receives only about 8.7 Mbit/s in OFF out of the requested 100 Mbit/s. ON receives almost the full rate on that flow. This is consistent with a CPU0 bottleneck in BASE/OFF. The PPS gain may therefore reflect relief of that bottleneck, rather than only a lower cost of injecting each vLPI. =D0=A8 have not tested OFF with physical LPIs distributed across CPUs, so we cannot separate these effects. The result applies to the tested configurations; it is not an isolated measurement of the direct-vLPI speedup. There are also limits and worse results: - TCP throughput is almost unchanged. Actual generator TX queues differ from the requested placement in 15 of 18 trials, which limits CPU-cost comparisons. TCP1 ON has more IPIs. - Storage tail latency changes in both directions. Some normal ON trials have more long completions. The four-volume sweep has a maximum completion time of 26.8 ms OFF versus 62.5 ms ON. A separate ON contention trial has a 1.050-second outlier. Their causes are not established. - The shared-CPU contention test stays near 100 IOPS in both modes, with about 100 ON worker doorbells/s. Separate GICv3 FVP tests using virtio storage show sensitivity to CPU/IRQ placement. They are supporting controls, not a direct comparison with AWS. The report covers 96 NVMe, 72 Xen network and 18 native UDP trials. The network tests and each NVMe queue-depth sweep have one boot per mode; the initial NVMe pairs also differ in CPU placement. Repeated trials within a boot do not measure boot-to-boot variation. The CPU figures measure scheduled Dom0 time, not total host CPU use. NVMe CPU ratios cover the full sweep and include completed I/Os from both measured trials and warmups. IPI counters measure handled events, not the time spent handling them. These results provide performance evidence in favour of the extended series, mainly lower scheduled Dom0 time and fewer IPIs in the NVMe and UDP tests. They do not show gains in every workload or replace correctness and maintainability review. The report [5] includes the detailed results and limitations. The same repository contains raw logs, statistics and test scripts. Best regards, Mykola [1] https://github.com/xakep-amatop/xen/tree/gicv4-bench-v3 [2] https://github.com/xakep-amatop/xen/tree/gicv4-bench-v3-base [3] https://github.com/xakep-amatop/xen/tree/gicv4-bench-v3-nvme [4] https://github.com/xakep-amatop/xen/compare/c368b2ece40787d3fa333b1b824= e0dc89dd585c9...2b54d02e5bb6c038396c8aae5bd9dad00cc3697e [5] https://github.com/xakep-amatop/giv4-benchmark/blob/v3-benchmarks/repor= t.pdf On Tue, Mar 17, 2026 at 11:11=E2=80=AFAM Mykola Kvach wrote: > > Hi Bertrand, > > On Tue, Feb 3, 2026 at 12:02=E2=80=AFPM Bertrand Marquis > wrote: > > > > Hi Mykyta, > > > > We have a number of series from you which have not been merged yet and > > reviewing them all in parallel might be challenging. > > > > Would you mind giving us a status and maybe priorities on them. > > > > I could list the following series: > > - GICv4 > > - CPU Hotplug on arm > > - PCI enumeration on arm > > - IPMMU for pci on arm > > - dom0less for pci passthrough on arm > > - SR-IOV for pvh > > - SMMU for pci on arm > > - MSI injection on arm > > - suspend to ram on arm > > > > There might be others feel free to complete the list. > > > > On GICv4... > > > > > On 2 Feb 2026, at 17:14, Mykyta Poturai wro= te: > > > > > > This series introduces GICv4 direct LPI injection for Xen. > > > > > > Direct LPI injection relies on the GIC tracking the mapping between p= hysical and > > > virtual CPUs. Each VCPU requires a VPE that is created and registered= with the > > > GIC via the `VMAPP` ITS command. The GIC is then informed of the curr= ent > > > VPE-to-PCPU placement by programming `VPENDBASER` and `VPROPBASER` in= the > > > appropriate redistributor. LPIs are associated with VPEs through the = `VMAPTI` > > > ITS command, after which the GIC handles delivery without trapping in= to the > > > hypervisor for each interrupt. > > > > > > When a VPE is not scheduled but has pending interrupts, the GIC raise= s a per-VPE > > > doorbell LPI. Doorbells are owned by the hypervisor and prompt resche= duling so > > > the VPE can drain its pending LPIs. > > > > > > Because GICv4 lacks a native doorbell invalidation mechanism, this se= ries > > > includes a helper that invalidates doorbell LPIs via synthetic =E2=80= =9Cproxy=E2=80=9D devices, > > > following the approach used until GICv4.1. > > > > > > All of this work is mostly based on the work of Penny Zheng > > > and Luca Fancellu . And = also from > > > Linux patches by Mark Zyngier. > > > > > > Some patches are still a little rough and need some styling fixes and= more > > > testing, as all of them needed to be carved line by line from a giant= ~4000 line > > > patch. This RFC is directed mostly to get a general idea if the propo= sed > > > approach is suitable and OK with everyone. And there is still an open= question > > > of how to handle Signed-off-by lines for Penny and Luca, since they h= ave not > > > indicated their preference yet. > > > > I would like to ask how much performance benefits you could > > have with this. > > Adding GICv4 support is adding a lot of code which will have to be main= tained > > and tested and there should be a good improvement to justify this. > > > > Did you do some benchmarks ? what are the results ? > > > > At the time where we started to work on that at Arm, we ended up in the= conclusion > > that the complexity in Xen compared to the benefit was not justifying i= t hence why > > this work was stopped in favor of other features that we thought would = be more > > beneficial to Xen (like PCI passthrough or SMMUv3). > > I have been asked to run benchmarks for this series, so here is a short > update from my side. > > Test setup: > > - AWS c7g bare metal > - Linux bare-metal reference and Xen dom0 runs > - fio random-read workloads on an NVMe-backed EBS volume (gp3, 160G, 80k = iops) > - Main workloads: > > - 4k, iodepth=3D1 > - 16k, iodepth=3D1 > - 4k, iodepth=3D4 > - 4k, iodepth=3D1, numjobs=3D4 > - 5 repetitions per configuration, looking mainly at median values > - Main Xen comparison was done with the default scheduler (credit2), > direct LPIs OFF vs ON > > Summary: > > - With credit2, enabling direct LPIs gave a small but repeatable IOPS > improvement across all tested workloads, roughly in the 0.8-1.1% range. > - Mean completion latency also improved consistently. > - The clearest gain was in tail latency. In the 4k randread, > iodepth=3D1, numjobs=3D4 case, p99.9 improved by about 41% and p99.99 by > about 34% with direct LPIs enabled. > - In this setup, switching from credit2 to null did not materially change > median throughput, so the observed improvement appears to come primarily > from the interrupt delivery path rather than from the scheduler choice. > > A few caveats: > > - This was a low-contention setup with only dom0 using 8 CPUs, so it did = not > exercise heavy VCPU migration or scheduler pressure. > - I also tried an artificially constrained NVMe host queue depth > configuration, but I am treating that only as a stress/control case and > not as the main result. > > A full benchmark report is available here: > https://github.com/xakep-amatop/giv4-benchmark/blob/main/report.pdf > > The same repository also contains the raw benchmark result archives used = for > the analysis. > > So, based on these measurements, there does appear to be a measurable > benefit from direct LPI injection, with the strongest effect showing up i= n > tail latency rather than in median throughput. > > If you need any additional benchmark results or specific test cases, plea= se > let me know. > > Best regards, > Mykola > > > > > Cheers > > Bertrand > > From xen-devel-bounces@lists.xenproject.org Fri Sep 18 20:29:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 20:29:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425869.1649573 (Exim 4.92) (envelope-from ) id 1x7fDB-0006me-I2; Fri, 18 Sep 2026 20:29:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425869.1649573; Fri, 18 Sep 2026 20:29:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7fDB-0006mX-Ex; Fri, 18 Sep 2026 20:29:33 +0000 Received: by outflank-mailman (input) for mailman id 1425869; Fri, 18 Sep 2026 20:29:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7fD9-0006mR-Mh for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 20:29:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7fD8-00AMvM-Mp for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 22:29:30 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad9ef7-8faa-0a2a0a5109dd-0a2a4508c7aa-18 for ; Fri, 18 Sep 2026 22:29:30 +0200 Received: from [148.163.143.241] (helo=mx0b-00498f03.pphosted.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad9f29-f659-0a2a45080019-94a38ff11326-3 for ; Fri, 18 Sep 2026 22:29:30 +0200 Received: from pps.filterd (m0367128.ppops.net [127.0.0.1]) by mx0b-00498f03.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68IKF3Fj2733445 for ; Fri, 18 Sep 2026 20:29:29 GMT Received: from co1pr03cu002.outbound.protection.outlook.com (mail-westus2azon11010037.outbound.protection.outlook.com [52.101.46.37]) by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4gsbr9rbgj-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Fri, 18 Sep 2026 20:29:28 +0000 (GMT) Received: from BN1PR14CA0026.namprd14.prod.outlook.com (2603:10b6:408:e3::31) by CH9PR16MB390768.namprd16.prod.outlook.com (2603:10b6:610:33a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Fri, 18 Sep 2026 20:29:26 +0000 Received: from BN5PEPF00046989.namprd02.prod.outlook.com (2603:10b6:408:e3:cafe::8d) by BN1PR14CA0026.outlook.office365.com (2603:10b6:408:e3::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.12 via Frontend Transport; Fri, 18 Sep 2026 20:29:25 +0000 Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by BN5PEPF00046989.mail.protection.outlook.com (10.167.245.38) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Fri, 18 Sep 2026 20:29:25 +0000 Received: from pps.filterd (m0373461.ppops.net [127.0.0.1]) by mx0b-00498f04.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68IKCJcP566546 for ; Fri, 18 Sep 2026 16:29:25 -0400 Received: from smtp-us.ser.proofpoint.com (pmta-usw.ser.proofpoint.com [34.209.42.160]) by mx0b-00498f04.pphosted.com (PPS) with ESMTPS id 4gnnc7ym46-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 18 Sep 2026 16:29:24 -0400 (EDT) Received: from localhost ([19.12.76.222]) by cmsmtp with ESMTPSA id 7fD0xDPVVDCvh7fD1xIEOs; Fri, 18 Sep 2026 20:29:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ppford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=fail header.s=selector2-azureford-onmicrosoft-com header.d=azureford.onmicrosoft.com header.i="@azureford.onmicrosoft.com"; dkim=pass header.s=ppserprodsaar header.d=saarlouis.ford.com header.i="@saarlouis.ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=ppfserpocford header.d=ford.com header.i="@ford.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=ppford; bh=ImK ihgVYYeqtDgPRyVBS/ngR6EsgHV2ulJgp21CGLIs=; b=is/JIvjsyyPDLKUWLC3 okadhYt1LFUh4EQFI3UbfVnxtvf7SKj3I9Pnqa88eT5y2ne6vufvxPmaRMOBgQ0z uUC2Tag6qAq2zHX7Z13J4cpXuRm6zcLNN4UuokS0pAebG+cbM1tlSQOCegjdn4vs hi3vRe3a3+BLGofjRlSMXzRsnG4SKQhEno05v+q8NqxFGj65UxnsmSkDZMOVW9Ot +gKiEh5lSa7WndfdKXc6Aborpv0ZSd8Oaie+ujY0aybf+VK1ly40xlgU42gz2ggT Ul/dbTlWHd+Es0ZMXRsV5Bw74RtcHTAfWEoG6SMUruycyyd1u8EDvgKyRU0LabWE LHQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KxSB42msDky1hLm4dFIZgWzzpP9TAFQoNaEz58XnWIRWy0eOFN1ka+BL9Ctg/oSu9p2SMu+Qk28u51y15mw0NRkoHl69wfyDACUQlZgqGO6yX/ItJ88ZBtBh7Oi3L4ng3rk4Xx8F2lnzXCOGpO2fbsUs7Y7Q4dWRLmmi1LH2JQ/6q44fUxFFjUt+6juYclRjR3ONhNZjgnv2F4PXhDPf8oKm/bGC+iNIkhxJ0zwLqW9OCS/YJxDaGOoSxHMQ4ErE0GC1MuBGtNU7eKfFawbx5dNmiNAJlamUfjG4h0BpHXEf3HqPkxvKHOs3R7nkyx1SylBcPS4FNdMrzZ0hhtmx5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Bv7kxj4BdMlu+VZ2+qb8knG7rLAwHsxaH+hgEYah3dc=; b=AOET3tnp2ZOPGtdT/+FisPsy88F8gcqEUPtN7YpQgc7G/Ft08Y5r7/7EGoSgd8AqwrN7TrjWl7L+C9W/jDjPMU5zHz60gy20YdLtG5B7GhXRGLXZ8uJJXQH1+w46HLhgZr2VI+hYbMvEwwvQjYu7f9t5wTd6evA6ex0BDnZCf+LM9aK4p9A5h92jZr8MG550RL0Xax49TdlaGwewxqg4PyA9EFOQ9zcYAbTTn+u7CmejawIrY1GpuNePS/sP7QS8ACnFemXYBpwHRR+9C9UYien8AD5RK85n3RNiehGPR59y/vBBKRFjtALdJOVhV/k+H8QkKo3JRSxtUArXjzw4yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 148.163.138.245) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=ford.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=ford.com; dkim=pass (signature was verified) header.d=saarlouis.ford.com; dkim=pass (signature was verified) header.d=ford.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azureford.onmicrosoft.com; s=selector2-azureford-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bv7kxj4BdMlu+VZ2+qb8knG7rLAwHsxaH+hgEYah3dc=; b=I5kh59X5Vjxu84+kd0PhRanXcNoT5Fg8wlCvDGHpeg69DqYYKMa4OJAQFhttFGSPSNXi/Ox3PAKLsFpdyJdxAECGOAzUZ8PJM6OshMgl8TrGVXd8KwPPaVzwZDD7Tsr6mWkV6jdr6vMxYsgCgwKDjvjyj0E1+dqF8PoZEn0O7bk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 148.163.138.245) smtp.mailfrom=ford.com; dkim=pass (signature was verified) header.d=saarlouis.ford.com;dkim=pass (signature was verified) header.d=ford.com;dmarc=pass action=none header.from=ford.com; Received-SPF: Pass (protection.outlook.com: domain of ford.com designates 148.163.138.245 as permitted sender) receiver=protection.outlook.com; client-ip=148.163.138.245; helo=mx0b-00498f04.pphosted.com; pr=C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= saarlouis.ford.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to; s=ppserprodsaar; bh=ImKihgVYYeqtDgPRyVBS/ngR6EsgHV2 ulJgp21CGLIs=; b=hfdZ/06Uxg+X1sZkUFXru9OBYNh3h1B8bPEVsQFJrdu2JG+ vc1ICdfk/p0L67gW9/uNdo3lfmAZPSlfY/gZXnEG/vvWk/atU0todUwXkVrRfYjh SedIBH/u/YwSujaWPOLM2LDdrGjffk8AxXg+DsqZRZXny6QmoF4b+kSfiYXTE7DD VIHXL9t8M1O+t5NuRUMwaKNDUh3ZyASghtJ3MWfDwoKRZ6Li3DDwd+l3pzgvqSYh pUKI+9HsyHNHH3YHD+YwUBp3TdFMqfw5fadBL3/WfeGMRxLUECo+KjCozU0ekSJw HTbmW3d0SPPsgf3lBliDjjklF1bsUobVGqZgNxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ford.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=ppfserpocford; bh=ImKihgVYYeqtDgPRyVBS/ngR6EsgHV2ulJgp21CGLIs=; b=S9SePF5mu2/9 WZ14rPKO6rGW+VT14OFrDuuMIsm/7noA6m+XZHmKMMjLDroQmG0gjH6sa9/98onT m6DXILgAlv9MS59is0d7cVzkqTQrbNCuancTy+8fHRLhPBy3dsNEVJftktxAktUa 373K9yXZACw+W/Jl3Dj1bFFAU5e7PMSQY49bTX4N5novXEcq/+e2OCgUh3vynLSC BlIpLsg8g4zvasXH4UEgQ+EY/eHteIIA9/iNL46xBEfb59a0QiurKyOp19r0WFxN D2KNUvqMYDtkrNTVRsHIkJYc+Ce9roJY+wyE2R/r0m26AUp9pi4YSyGpGs1+GZuA 31gKzs7UmQ== X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7 X-Cloudmark-MID: 7fD0xDPVVDCvh7fD1xIEOs X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe From: dmukhin@ford.com Date: Fri, 18 Sep 2026 13:29:22 -0700 To: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= Cc: Denis Mukhin , xen-devel Subject: Re: Zen5 runner access Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: PSER-M365-App: SER-APP X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-18_06,2026-09-16_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 adultscore=0 spamscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609180294 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN5PEPF00046989:EE_|CH9PR16MB390768:EE_ X-MS-Office365-Filtering-Correlation-Id: b417992f-3c80-4fcc-34e8-08df15c38827 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|23010399003|36860700016|56012099006|11063799006|10067099003|18002099003|22082099003|13003099007; X-Microsoft-Antispam-Message-Info: ROgu/QCGJYGwAo0FAwSyhqVq+R/Keum0eTI1iEkRQSshzW2sP6W2f/TTf0MyP9fTbJtmehpE6zfF+jGnh5QtDICFqlap+/GQPOutAfUj81nzkCDfB+BxHTYbtmjhY6cqBRnJLYAEaPHjKEWnhxqQaSbBM+xcAwPCJZBdOTXSz9KlWs0K1V0pacxPMDOywak19A7Dd183g3sgH28khj8gAtjokGFcPNoljm2rfPBmgqTEUs5QC8pNtcBQjfzXKI1jN/yQVDlNZeVlJo5ryS7O8xQDLBs1MwXgFipy+64b4IbXNetsmUsCPEItNQ3Lr8+FrGBjN5pugD2Hw/ztgwo/66tO2sb7YHkRvUjv8lUbIc+9ocevhUjd/tB3U0exkvXkBfxdlsRPy5wU0JLVUvLwE3CrUGuzf5pWc5SUFfkbBRU73CDL2bdpw/ATnMaEvIY9yOuuLMSB9HKapHRycus2S0IHB3Om2YHg97BtKeNYIfBvtijZTv3yWoVhUYczuQ9M3eU17caiKoXyaomQd2FJD/oZ+6rBiWxXNDPlQN+fU3KMmLP1mG4hywj+c+Q29ryrG08yjIF+myhoyUBDH5E5WloLwIiaKermzBETnQ7xe81NatWSJSMFpDMG15edFNNdjDv/BhD8kuS5aZLDDirNyoNIPHRO3PnsyCHeYo2xzKtqopxzqGjGSLMlHdoAxkxlx01CV/LWzY590zDpEJHpvw== X-Forefront-Antispam-Report: CIP:148.163.138.245;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mx0b-00498f04.pphosted.com;PTR:mx0b-00498f04.pphosted.com;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(23010399003)(36860700016)(56012099006)(11063799006)(10067099003)(18002099003)(22082099003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: kcfkMpk9Vzcy9Uh/MO0laODw/iIP9r9IApYz7QAHoXjDDE5knnxuPCcdbdEqSD+P38VgMA6J6JVBoZFrqu2Omgygi/Svy5NxqLHXSn0wZ5h/xKSuWQtAbmQKtYup5qChCLDGrXXSqr7NJN/+j8gIinbhIH2mY0P+MjOztNtopqCZ/L9PD0zSMk3JxdT5V+M6/66RWMLu83VF4kJ13NkM/p2UFIpM5xRcZ4/e/7zBiTR9CNH0C7TyGHRYBNYkNOv0XKNNyzJG4Vo1TL0Bwxurz5/7qAjeLG6Pa6O9UzLu8Z5fB6Xw5f87Ph82nIKT9dVS6ogv01tdgTYkaisqeOQCToChxS4vBbJqY67HZ6Hcw42Jicapo6o6mHaFvS06ee9EUqvV88LIbu3HJnNorDrZuFiMqJG77aAxuf8a0x2f2rRTJkLPXgh6KArIdR1XTLfH X-Exchange-RoutingPolicyChecked: iy7+Gb1TpEEzLL5fox0C4BSV/aTApMp2pR7/0/hX6XX+4PWguXhPJ7hh7FMdvgZypbtsCdUx1m1ufsxBJil77Cz3e2Vx8vxFVv9gb1LmxOBVT1i50CYQWVPC3axcKyXVF7PK+1kOgWjsMKuvB1OVTu1YrWY5+sOZxlLFIxB2X8SpVbffXV/bW7QcU0F/fWe+2j9IVu3k6BAvbN6MgcgB1vQEP/buQ7NCtYwg4WQ29u91uZ/KLxD4I8q/G5ANbXJIsBNDO6jUiBEygTafVKBSGOyvsZRddtE6bxEZN00MrlmrrDRyYv2ANx3L9yDDbu2rErNl9WNW/gPKNkuFAapMIA== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: L6+Ninu/VHD73gu8MUOrMsxv9PMyyb8AHxw+AZD39RSLnXxLCFRdAYgalvdNIpO3rqReri7OHUJ+8SevnnN5kMtDNSvrvozn3tIGNA4W+wepEg0GUSD1Wic/9i3HSj4HORFL4tlEddEboCdsxJeuV9NKkx2n6CyUWnN5ta9SP6juVU53+xo3raMyn6xDTjFTA99Vv3CQIniCTDxCHMN+aKZ6fPsiSQkWNXqye4wcMDjRfzNk0I5L34faprRyOQNaZkC41kt3WucVPEQDGegXzGf7I1O9baCCpKszGal4xY3LlgPTBzqjxhiURZTa/YR0L115k9GWDGR5lLFF580pvh/Ltjam8Rw5bfl+9Uf2JEpvlYwm5RJqhAEGpZ42ALLNewKXbRks0xv+RSAR455ZqNzDdJmmiVl+wRnbbWkqeaGl9Mz7cI3rehp+ZVRv/8t+U3jPQN5Wk+SxPYQA6ziylYgFA6wjUWlr5il99nh/wswCEUWJl2QkAcUQ9l2b7kt2j6m/UF3A+M6NM4C2DDGuykMfQq138PgkxyMhy7bNrpq6G+YO2UAao8UJDEcE8HSukdMPMu2i0lLRJdvQrhVIPJtbAn+8hgU23aLb3BTcnxQQqkgX8/p8aVKWKBHgRxwzqsZXlBnFTluAXd13oI3l/Q== X-OriginatorOrg: ford.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 20:29:25.6104 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b417992f-3c80-4fcc-34e8-08df15c38827 X-MS-Exchange-CrossTenant-Id: c990bb7a-51f4-439b-bd36-9c07fb1041c0 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c990bb7a-51f4-439b-bd36-9c07fb1041c0;Ip=[148.163.138.245];Helo=[mx0b-00498f04.pphosted.com] X-MS-Exchange-CrossTenant-AuthSource: BN5PEPF00046989.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH9PR16MB390768 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE4MDI5NCBTYWx0ZWRfXz+zwOSfKMFXm Ni5Rc7bjv3KEJQAnJz46D562vmVEb++Fh6h+ika1/UrEUhuGi/Oz89FVnsIguTIa1AUROR4tLwD meAUcqMaSD6Gli4BtybHohDgzQnHySZ4QZODvrtgW+SMG03Ofhfi X-Proofpoint-GUID: uTDC2Wavo4i7LUIpyQfpMQFoZ9lodQYA X-Authority-Analysis: v=2.4 cv=E5dYNqdl c=1 sm=1 tr=0 ts=6aad9f28 cx=c_pps a=gjcLB77VbSPYcqvaeYBpgA==:117 a=b7IhknPlfT0FN1EembXvig==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=8nJEP1OIZ-IA:10 a=VdqzKS8jKosA:10 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=WER9OelvoqQQjwJToBYG:22 a=p0WdMEafAAAA:8 a=NSgd35z21Kgu57nUP4gA:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10 a=P0bj-C3X3jJDpopQwM1U:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE4MDI5NCBTYWx0ZWRfX9DAqyHCwzO2R ljB/VC3ArVcj75ypZSLnCGcidxRhQ+cXI3xIkXifmsknQEqeiU3FlWy8uWWkgWBSowPMJ0HWX48 Ghg8DFeC3CGp+WBYe3MrkTBQUcR8yWLw+QI46DDH1BQixv40+MhTqx0Go3pQcEdn4hI91LuBTYF M1RG0IM++amHwB6daUVBGsT1oPvY7s/zcrCegec8FL6I2iP9qjMTzKB/KQYPGVhINcq5eAsUs7M V7Gi/civHFirrvcxviXHmQ9X/TWATUOBvexEODROW0OAtTj1wmgzYMtS6uWGeg+F8+EJ7wirqe5 LQR+1/fjBABkYzd+T1z1V2lbJYgP676rlGGPg1F4G4Gr09xKglscoVj0MSvuxLpDmmo0s255cER ipJ/xfa/o444sUgkEIQK20bW8+jlc6kBNvBJyRSi9b8gaopFu1FxJMORdBr65CFphAsA9oH1Tr7 dvGVn5K99HA95tGsuAQ== X-Proofpoint-ORIG-GUID: uTDC2Wavo4i7LUIpyQfpMQFoZ9lodQYA X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-18_06,2026-09-16_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 adultscore=0 phishscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609180294 X-purgate-ID: tlsNG-c1860d/1789763370-CCB7187B-0F5DA67F/0/0 X-purgate-type: clean X-purgate-size: 1222 Hi Marek! Thanks for help! On Fri, Sep 18, 2026 at 01:58:20PM +0200, Marek Marczykowski-Grecki wrote: > Hi, > > After some debugging, the AMD Zen5 gitlab runner seems to be working > now. You can add it to your repo by going to > https://gitlab.com/xen-project/people/dmukhin/xen/-/settings/ci_cd > Runners -> Other available project runners and add hal9021 to your repo. > This relies on temporary access I granted you, so you need to click it > in the next two weeks. I have added the runner to the project, it shows up in Runners -> Available project runners > > Then grab top commit from > https://gitlab.com/xen-project/people/marmarek/xen/-/commits/automation-hw21 > that actually defines some jobs on it - edit it to your liking to run > tests you want there. > > And then, you can also select which jobs to run while pushing stuff to > gitlab, for example like this: > > git push gitlab -o ci.variable=SELECTED_JOBS_ONLY="/zen5-.*|alpine-3.24-x86_64-gcc-debug/" I picked up new zen5 jobs, but looks like I need some other permissions as I cannot schedule on any hardware runner. All jobs are deployed on qemu runners only for my gitlab account. Thanks, Denis From xen-devel-bounces@lists.xenproject.org Fri Sep 18 20:49:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 20:49:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425877.1649582 (Exim 4.92) (envelope-from ) id 1x7fW7-0001LN-2F; Fri, 18 Sep 2026 20:49:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425877.1649582; Fri, 18 Sep 2026 20:49:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7fW6-0001LG-V4; Fri, 18 Sep 2026 20:49:06 +0000 Received: by outflank-mailman (input) for mailman id 1425877; Fri, 18 Sep 2026 20:49:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7fW5-0001LA-Dn for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 20:49:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7fW4-0008AX-4C for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 22:49:04 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aada36a-8faa-0a2a0a5109dd-0a2a4502db10-46 for ; Fri, 18 Sep 2026 22:49:03 +0200 Received: from [103.168.172.151] (helo=fout-a8-smtp.messagingengine.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aada3be-6ca4-0a2a45020019-67a8ac9780e1-3 for ; Fri, 18 Sep 2026 22:49:03 +0200 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id 67CA1EC0235; Fri, 18 Sep 2026 16:49:02 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Fri, 18 Sep 2026 16:49:02 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Sep 2026 16:49:01 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1789764542; x=1789850942; bh=p2p/4uYr0I/aihI2ELL4FmxsnHFyMYZQmjAUpbmhG+s=; b= hkxdaJhW3D/wak12v0LL2jsjmhoegMsPUifKezqGJDp9WDtjCDHjIaeuAXw45fBI 6O/VimDBnwNTcZRn9XwJVffC8qoIBEj4oetV4pLwpiLqa/nEVLktSDb/ouxyUWgv g756A7TFW7I1FfUu6vZKis0Rdyr3j6DwGq8aBWaxgWuUs2vApyeAgqVEYjaUqBrg Qc8I479Sw8kZgNphCt4csQp9OYvclMtdNJRSFsTWSbC/J0WGFC92NPO/GNlcZML5 EZ+b90f8cTy6wNIMpblVacGKIavv1KCB342zA9g5GEJg0aorweuStp4cGXa3oVFS REXdK8jIgYWnSuOanbTD7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1789764542; x=1789850942; bh=p2p/4uYr0I/aihI2ELL4FmxsnHFyMYZQmjA UpbmhG+s=; b=rAiJfJppqfGMAz5maA+EbO6AgI/72ACaDtt+uuvbfbKr3ggOpHs mEiXGCVOdGBIpk3w0MWfWfUOHKZTMuyuaGuVsM0BgV3K18AHj4RlJw/yakiW1UUG pZ57abWBslOMriGEI19oiwXhhRZsm+K3Ysgq/P0iJT5etj03VBUHXgrZhKJlIMjc UER6+yeGS5et7I9enUQPzd0bCVHdVeh3JnZ+KgiWbTtMpcNA+T47m0KJY9j6Hv65 LC3xdl/am/OUx5sFzuDC5Owj7jlih4pe2M2upaj+C0BquLTJjtB8pBg83ge7vg3f vT0guJ88hsNUPd8ArygfXsGgf7OeuXk2uPg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEGbZ++pOBa/piXTt+TzFEIGUtgrdG8sX0kR2cOhDstNI6INc+AGnk4gS+nnrHTJJ PpPIitRV/2SDd98pXqNKF9kL7IZmdNBS/ssIvhDUyP+zGz20Bc4BV//Dm9Rrf2VmjT04WE kwCcqxF+w5s+JtsyVs/IT/cuolZ+Av7CTevAU7XIaE4GNZGb48NaaG9CrzkXXLo1/rUxxB QU6niHjcV2lUolkq0UZYrVnD+Kfn0AEukOAKP8CoPW8RLY7a7wSDCiFVuhGi00gLinkFlO JWVd4CATC7Qhn4DvUBTS32d0Yh7A9heeYhIdjO1NZKU/7acW3v8L0VUK3/2TizQg9vk2ou dAI/X56+w7FJdOWfRPCgxWT+10abT9+B3tOCRHjwfYMUTYfDZIOkZ+KhfTa2WaLc3wslGw NgfTLdsa0vW5YnrXDl9ugS3aME9bpofOgR3gJZIbC/6ZpdWYlHS4CHUuenb2b5tJ9B5B84 8AShVI5zK6fPXnU2EBbtCD2yOJx5P5nqukCbsq6oKDsUpvZ3XGaPseuPPtfuxAAgvhuKoL 2LLPR45fn+IphhSEKHpLK0QP5v1pn5x9EsGYb555SiAMYIdODtx+a1r1TbOVrLg5qEa6gb baMal1/HanAVY05uAlQrRdMO330G48DGNSZ2PGSyHmMfD5zEJEZw2K2kA8kw X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Fri, 18 Sep 2026 22:48:58 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: dmukhin@ford.com Cc: Denis Mukhin , xen-devel Subject: Re: Zen5 runner access Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B81z5Jnaq4Cyy6lj" Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-720697/1789764543-30FCE2AC-1E954742/0/0 X-purgate-type: clean X-purgate-size: 2790 --B81z5Jnaq4Cyy6lj Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Sep 2026 22:48:58 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: dmukhin@ford.com Cc: Denis Mukhin , xen-devel Subject: Re: Zen5 runner access On Fri, Sep 18, 2026 at 01:29:22PM -0700, dmukhin@ford.com wrote: > Hi Marek! >=20 > Thanks for help! >=20 > On Fri, Sep 18, 2026 at 01:58:20PM +0200, Marek Marczykowski-G=C3=B3recki= wrote: > > Hi, > >=20 > > After some debugging, the AMD Zen5 gitlab runner seems to be working > > now. You can add it to your repo by going to > > https://gitlab.com/xen-project/people/dmukhin/xen/-/settings/ci_cd > > Runners -> Other available project runners and add hal9021 to your repo. > > This relies on temporary access I granted you, so you need to click it > > in the next two weeks. >=20 > I have added the runner to the project, it shows up in >=20 > Runners -> Available project runners >=20 > >=20 > > Then grab top commit from > > https://gitlab.com/xen-project/people/marmarek/xen/-/commits/automation= -hw21 > > that actually defines some jobs on it - edit it to your liking to run > > tests you want there. > >=20 > > And then, you can also select which jobs to run while pushing stuff to > > gitlab, for example like this: > >=20 > > git push gitlab -o ci.variable=3DSELECTED_JOBS_ONLY=3D"/zen5-.*|alpine-= 3.24-x86_64-gcc-debug/" >=20 > I picked up new zen5 jobs, but looks like I need some other permissions > as I cannot schedule on any hardware runner. >=20 > All jobs are deployed on qemu runners only for my gitlab account. Ah, gitlab config specifies it's enabled only on protected branches. You can either mark relevant branch as protected (if going this way, I'd recommend still allowing force-push), or edit automation/gitlab-ci/test.yaml to remove `$CI_COMMIT_REF_PROTECTED =3D=3D "true"` part. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --B81z5Jnaq4Cyy6lj Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqto7sACgkQ24/THMrX 1yxTSwgAjUcr45hC85amHG2fmM5rw8v5RWVoLFWP8dhjKVG9ViSuA+RniGOSAsu8 N1rGFRM4CqLjRXFc4l6beDsHxfyRCnqzdnwPhU7QLYCp8eKF9vZNWMz58d7pZpa8 x0QJbWJ7GgzU0pWBqbNLG1/LyxXyct7zn5ul4Ef9MogSSEqoyytpMA5H76Hfyds5 t+ugcaTuQzLzggeXwopULmqlrLVVL+XvvZPTjyoM9Ofw50BM2w3yeiPeg7Cm3y4Z hp9EKIBdDOZlFddrKDsGpW5N29LkXyY3F5W24LWk7rdANAGi+zRsA8efCQIR8o4O +EzYHsmd3qrVe9QU9ej5hSNHKb9/uw== =LQ7r -----END PGP SIGNATURE----- --B81z5Jnaq4Cyy6lj-- From xen-devel-bounces@lists.xenproject.org Fri Sep 18 21:23:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 21:23:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425901.1649590 (Exim 4.92) (envelope-from ) id 1x7g3P-0006fh-Iy; Fri, 18 Sep 2026 21:23:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425901.1649590; Fri, 18 Sep 2026 21:23:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7g3P-0006fa-G8; Fri, 18 Sep 2026 21:23:31 +0000 Received: by outflank-mailman (input) for mailman id 1425901; Fri, 18 Sep 2026 21:23:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7g3M-0006fU-Vq for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 21:23:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7g3M-000LVx-Cb for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 23:23:28 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aadab98-8faa-0a2a0a5109dd-0a2a4509a87a-8 for ; Fri, 18 Sep 2026 23:23:28 +0200 Received: from [205.220.165.32] (helo=mx0a-00069f02.pphosted.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aadabce-be1a-0a2a45090019-cddca5208dfc-3 for ; Fri, 18 Sep 2026 23:23:27 +0200 Received: from pps.filterd (m0333521.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68IKlCgQ166503; Fri, 18 Sep 2026 21:23:15 GMT Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4gmwn9ac06-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Sep 2026 21:23:14 +0000 (GMT) Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.7/8.18.1.7) with ESMTP id 68ILJqMW029893; Fri, 18 Sep 2026 21:23:13 GMT Received: from sj2pr03cu001.outbound.protection.outlook.com (mail-westusazon11012038.outbound.protection.outlook.com [52.101.43.38]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 4gmw6gu76p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 18 Sep 2026 21:23:13 +0000 (GMT) Received: from SA3PR10MB7041.namprd10.prod.outlook.com (2603:10b6:806:320::18) by DS0PR10MB6174.namprd10.prod.outlook.com (2603:10b6:8:c2::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.5; Fri, 18 Sep 2026 21:23:10 +0000 Received: from SA3PR10MB7041.namprd10.prod.outlook.com ([fe80::e593:4c8b:434c:76d6]) by SA3PR10MB7041.namprd10.prod.outlook.com ([fe80::e593:4c8b:434c:76d6%6]) with mapi id 15.21.0428.004; Fri, 18 Sep 2026 21:23:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=corp-2025-04-25 header.d=oracle.com header.i="@oracle.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=selector2-oracle-onmicrosoft-com header.d=oracle.onmicrosoft.com header.i="@oracle.onmicrosoft.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2025-04-25; bh=0SM+epRE0CJpSQ6kUZJcVL3gxlMNc0Dr5pLnjM53r7c=; b= VpY6v+iUL/cAcLSBGlNywBS9VocbyBlLv05lnqHgxEMWdWn1DJFcAaXdbg1RFmlx nbLA0RtfQGm9/4nW+JZezz6XrV5JMp63ggYGWNrA/NQfi7ZqRAuMpBUdbalUmQX4 S+E+oX3aRM8z/I8oSDBSikyt6aCTcyYLP5OsZPuTJOvrIXso24IYFtWPBT7j8Qbv CD16LMkb95xknOsYF86+tFsgsuLQRNDJa9AO6k1z0+0T1bBOFCl4ZTtsj0OASWGE wRC284C8CnwkF2qXEaiUmJLngFoeFd2PJSyfo6CJxR88twn7AIu2mw7QJaIGlOBu 2DAA+p8iAdgvl66zLDU9Mw== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kZd1v+6YjK39LILPJ6yPbER9wmSkJFDo8D4wxwc8GCFTJFbbGKZIIjNrRg6KZPaPEb5JSMRJ2VRr7QXpS+wvA2d+oEarNOK8sAF02cojEUzPYAm3vQzZFAuSejn879WJV/Gvlvf0wrqrvFKFZPqthhBx+GglHmhcQSRcrFZheL+3bLxtnlzZk1eiNkr8MdUGgU1ULiK/Meqrm7iLmr3/SvIaer9RFLFSuPMdOSV2E0Uu5uNFEpE1opb6gwp9gNzf6MERInXvflmTMMIYAeWLliMDGKBJJxwHrxXu1ePytSTDnWtuhvk6K0lsPzkX5LR0CdwHxpvOIwtW0CaY2G28nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0SM+epRE0CJpSQ6kUZJcVL3gxlMNc0Dr5pLnjM53r7c=; b=n5uAzU169Oz2oWdijDnHNuj7TReBk2RoEY6MjU49QrtTGeANInyDaUNuPcL7lkM04vaIhyRfepnq0ijujeljEGb11bJgvVuONzwfinE034BqxQLaRKbHE6Hx86RKTRvp8kO/n0/b2UUdFGk/LldLmPueBH6EdReY5Nb5msri8S0CT8JN6P2ei5VnQH9WOlqOl2fzPyxCHVLvF6ko5cG7q6G42iKLwle7ZQsgxVNFY8U34+DL373vGuRliyffIoCc14lWVmSIxQ9W4oHyUIWnNNuuh2U4HHn8TuXm+jsgSiUejb99bhitFmfMAsJiYC+9Hqj4RYQ8Vr13QwIAlTtoWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0SM+epRE0CJpSQ6kUZJcVL3gxlMNc0Dr5pLnjM53r7c=; b=BuQIY7lerBpPnA6o+ZSfVq0oHHtQ7bOKk7wGxr0zW0ARznJ9R3Pu48ysn4sK9WWkMiHdNEEItZO9Sk/4ID+rBgiPXyzr6mNoBYB4xBVMXWq5hmHsxq1yWEneUYWuXydgw70rio/Vy34jH3bLBNCBsbHDtrTLHeiF0Y2Rk6hNsfI= Message-ID: <1da5f563-9fb3-4043-b13e-fa7a4f390911@oracle.com> Date: Fri, 18 Sep 2026 14:23:08 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/1] static-memory: allow skipping the cache flush To: "Grall, Julien" , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20260829050611.3353566-1-Jan.SetjeEilers@oracle.com> Content-Language: en-US From: Jan Setje-Eilers Autocrypt: addr=Jan.SetjeEilers@oracle.com; keydata= xsDNBGetHhIBDACa4fBRw0+D/y8p0kzZyJ+K5pisnqCKCFVKtAhVYFJjzEoUvVtqKJpjZaWp JtlNQ05u3GZKofFptGJmXJZtttujfE6iWqjFVcm1SUo8kSRSLQ+AxtfAot319Do73k/uhfQM 71+cX5pO6EybCrr962npOEfe6yNbZ3UmszrbmRORw3aI9g/VHmC1SwFj3Gq0KHBQvEB89J6F iDgrHGnQVyQDmCBF6n6mqSJFV/fWK6XeGSj/T/R+8osU0FpXcsZ4OCY9eyJ23zY1M2f2VEV4 B61+UW8orqgXe3mADI0yLP0onViD2UHqV6EDjLWN1ukUkJUoPWzv65LyU1sAw0rKPELvcl4/ rzJPiO8FNMjTp4jibe46Spyh5BKYxN54m8zAF9D9uHA1IX9pJpNRS2uKEnZWHJx1Ew2GZINv 8VDhpPxJP4p4ArZMSzAsNKYSqyuXyQ8Fcn7DCwI8E4tl6tRNacBkf1ByF30oYFYFg1pbMIQm 4z9BY01cBMB59/50dy3QF3MAEQEAAc0tSmFuIFNldGplLUVpbGVycyA8SmFuLlNldGplRWls ZXJzQG9yYWNsZS5jb20+wsENBBMBCAA3FiEEvrH8dyNhbaVzmqUqqJoDwbaIAmsFAmetHhIF CQWjmoACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRComgPBtogCa8z7C/9cotiLsRfmhl4NV+bo 40hXUXFNqgr63P7/KekI2TnDfV5Ilsy9UcXWFZC8hGGLVPTvZB0Mrf9jsTPvqm8gykr7E5Ig Hqu4U2RP2/aBu943Nhf+bf+s0MluJu6zZoI0G3WvoX5SzSdBJM6MPyyYnC9v9f7AFL3iGRaM 2/XY1to7hhxMX0Y+iRYi30GMvaZtZk8zLn7CEj91kwAUDM8a+5oUPLgV7UsKJrZ+dPSzkavQ 4jND6CY6Ln4EALdwyheNHkcgUNe/784jrnmFS+7uPX0uO80d9P1XBGv/7sgDssvGTpNAxO6K zdns59r+oCIeb1DrfuqPGPEa12IKkSjlbaf67WMr14yQv6kfgzvYfNOjTktKpQvjyZCfC+5k Hi+LYfh9AItZTTcDl0D7neTfD6gkFyNKG7c11usFnb3ge7EiV+a+/HKQh+pUeYdL1DOJc0K4 YuvPyQZQuHIRp89EDlsxZA3sNelO7qGe7BtezD9CEbl33W4DcITMjfrFoJUPaoPOwM0EZ60e EgEMAL8iSzF7Xf1zSD/RovAnH6iVjVwsDyd6oKU/2t4DdupE1vrcYBj1D/rUPKLI/O5xgT0t I1uWLp2+45uN/CQDDiyE5+Wcp9cbhV9eyTfFJ1PrGB7EDthKhvZb89f7tG9wI60QPBTmVIRl Fn1QtBGxij6YR+Su/054SW0g5O1ywT6HZy9ebdNfx/jSTM1FTSvP6JNSJoHVwLeHgaZHOTqe hJHalwGQJIxU7jSmMgvIF/c6SrJyQhjlH+th0hev83DhoK1JEUZWwEuz3yrALwr20DV8f81D qUqiGPalGsi46h6hj+M8QEyHS3sFeDA//ZvDU5sOecPgmRm6QyRRFXyuHV/b3jBYJJcc4tdI wJ7de8Np2/yctt9OlvvNP/KQdz7HbdVMdCXWtxgjMcalzseE3w2IH6SIxQ2Fwwzr6BZUYx92 ePxU6EJfveCpizfZBKRnjYdl/gLJJEW322QDnZFpI6FPaLnGgPjMhFuz1qQAPYmRByC4W029 jE+4cS93yyFScwARAQABwsD8BBgBCAAmFiEEvrH8dyNhbaVzmqUqqJoDwbaIAmsFAmetHhIF CQWjmoACGwwACgkQqJoDwbaIAmvmZgv8DAZ8XQnunSonH0N5HMa9qaQafl07cfd8jVk4IFH9 UPIH0463s/0oVJV1hlcqqqk0nZKwobflIrehB/TSSaLnAoy9b2raOKNbj0ppZdoGCm+S3z67 O1c7cx8vQ+nnSe4E+Ko/J/8e4FOYhFUOc4lmIn4ByK+SBKitAkOYI64ugunvGZLj1TV+b1Wf wiWaJUGmzZkjIU2T6J8W1riYn1KW2uNheJQU4/sVtBc6j/hIqccTKBpx0qTszeZnFa28aGkg t2BXv2TqaA7yzbLymTRG4JHRlc9LQ2tHjIjkRBGXpiOG26S7JoeHz+QCqSK2XPp+LP5/XhTk Vvb8FjeyBuJ+Q5RK2vYk6Ws5ua4G1p2AUs0w5SpRxpLUTuTVlntyXQfp7Pa42oX364UOGNrY c+ddxSb+KW13sbIRslW8+LWdvNH/VgPKC3SkblSG5H/e3sfLsA3DAmu886allZ82imnPRlYH /epCCdHbjMyPhatWd4WT2RFakWMvkwGDSJUd50h8 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PH8P221CA0065.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:349::13) To SA3PR10MB7041.namprd10.prod.outlook.com (2603:10b6:806:320::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA3PR10MB7041:EE_|DS0PR10MB6174:EE_ X-MS-Office365-Filtering-Correlation-Id: e3025e6f-ae2d-4cdb-3e69-08df15cb0a42 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|7416014|366016|376014|10067099003|4143699003|18002099003|56012099006|22082099003; X-Microsoft-Antispam-Message-Info: uPFudcZS88ljvDzZFHhA99ucJ/i2mC4OFUoTpGG0+gGajRX/ABToSfWYMLGyWy2hzzjgiGYfa4cOaWldnyB+YZpOoSjUgMAciC+7MYlC2gRnQGuE4QtwV072PAWVImbDH/W8AkSNGp9XlYCXEDelVz/X/edIfhYIPX++lB1uHZo14TIK/aWRc3ecjY96V6yvaEFCgDACoK9WLdKG7y6Y0yX4RId7ChLo/xcZuXKR/G1XKHpWXz6erMyPp8utyijo1KeJwqL3L3fJ53CJSEV59P0WpYuI7Q5ei1FCz6MMcMewylhs5gM9e3bUfp/4NHoGBjGe9wzlMUs/qiK6CHDW10bj4ldh6MrbP+BgnhNakNpNSrEzfiN4pHcxiB9/Gqc8D/2PK5ntz73hf6CUjFGReqcW9bj//ewa6H8358ozozH4ykd4VcEhcStP36m2xQrqFclVh3oadWNMmo7DyotYsUnP1FAHbgQrN/zXMIYf6DKlnAg3wQFfe7MDDCxsdLA801i7vQVOr42d6b+X9x3ebU200aK6K2eNvfhWZPx6vxz5fQzgEdO0rdZhR11o4x2mD+asY81JK/tG8MW0Pm+rGbSaCSIZkdu1icxPVh0LJG1J/uitmaBmgVuqYiczz+lq/6Ln8pUI8ScBaGtoiYRzqiuSJq5wa9Uee5UaosW+kug= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR10MB7041.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(7416014)(366016)(376014)(10067099003)(4143699003)(18002099003)(56012099006)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SU9La2laSUdCemx4YlBMV3lNOXNKcjViblFWM1c4UlZKckRWYkpybTA0a1hO?= =?utf-8?B?cGRyaTBWOGp5QWRydWdQUlZPYXZCWjlMazFNeE40RGZsc2lPcWhwTW5naG1j?= =?utf-8?B?TDNrbjdXUnoxUDZqbUlUZ0ZFQmQ1RTUrVVNzSlgrUkNwdFdLT3JPcjllOENY?= =?utf-8?B?YlpiaWNaR0daV083VmxQRk1NVFZtUWdLc0MzUDE0LzFkNlRlM2RsWDZSdENa?= =?utf-8?B?MlFZVHpmK2M4OERQSk41dXVXVXdIUnJNYWpJclJrSks4TGY3NHllSDk1ZFZI?= =?utf-8?B?S1UrSGM4K3NxWlh3YVdVZUhBUUJzSFY2c1FlNlFKU2tqazJqckpFMnA4L1gw?= =?utf-8?B?d1dUZk5oRjJ2eEp1aTN4d2pLMm9vMkNxU1kyRjUwMDdod3ZZVXN5c2lObC9q?= =?utf-8?B?dzhzVHVOVnRRRHEzRmozTkFzaEFraU1DNXRuMVE4a3Uva1ZrbHl6amVtUUlT?= =?utf-8?B?N2hpSm1RbDRwV3V6Um1kN2NQMDRMOWlJYUxnc0EwL0Z5UFJIK2preGhkOFlx?= =?utf-8?B?Q3RJNUVkdkN6MUtaSEVVUURMVDJqMTRSbCttbGQ1U3lSZ1gzZFkrbzEvb1hv?= =?utf-8?B?Q0xETisvN1dBZ2tsbVB1UHNLMThNV0FqSnZBVkM2QXhtUHp1SGRxenhub2pC?= =?utf-8?B?eENXQlJGVW83RkcyWURVZ1JhcHl5N3VkRGl4bmxMWGVFaDlWUi9tbUVzTDVn?= =?utf-8?B?NjBUQjhTVmhvazd2MkJKMFV4bUN6c1VQREJ5TEZPZVpoZitaMDYyazRUVlNU?= =?utf-8?B?Q1hEZ3dlSSszMFBsU1BpR3JOcCtGY05xSmEvM0RvakZNeHQ0bjI4UGprenFp?= =?utf-8?B?R3JJTWZqbUgzbE5sL3R1U204VWhkeGNVYkYxMDhSTStWZWdrRUlnWmJNWElJ?= =?utf-8?B?S1c3Y044Z1FjNWx4bHRxMUp4RzBtT0NsbEJvZXQwTzFiR1FqdnZQRnJiZUZq?= =?utf-8?B?UlFMMVlHcUp3QXlHTEM2dW9Fb1hyMGcvbEdiZFROT2hFZGNqN0Z6RWVOWlRP?= =?utf-8?B?c3d1VjB0bWxnOXF2RzRLRDkxUS9HMDk5TTNvUEM0bU01STNhTnM3emFXQ3Vy?= =?utf-8?B?Mll4OHA5bWpQNjJmMHpwMlpaa0U0TThtbGE5SHF0UTdxZHlKY2FWc1BxcTVC?= =?utf-8?B?aW9xMjhSS3YvcnNna2s1NVZMaS95eFNKdGlwNlBuc2N3N2RuSVNsS1lOZkRz?= =?utf-8?B?cEkvQ2orR21TOHd5MFlGSzhJd0hOc2crRklQd2NWMVBoU2puRGxVOUtKM1BK?= =?utf-8?B?K1JZNjlPUGNXK0VXeGdpQWdhcDMyOE5iOXE1RXZyOFIwSXExL3ZyZEE5VkRF?= =?utf-8?B?VlpvV3BaYXNOMjZNelZKNmJ3Z0VMV2ZUSWNYVkdPdy9ZZWxERU1aRUxNSHd2?= =?utf-8?B?WC9lNXhrY1VxRDh5V3dBRit1TU5KdnpoV3Z4RUdTWHVHeCt4ZWplM2RrOG4r?= =?utf-8?B?dTZmcDN0Qnh5aXcrTHhrVCtMRGtIT3FNQThnR3p2eS9kaEFZVjFIUVlkeXkz?= =?utf-8?B?SkxteHJGNmI0azFHemNhOEl5ZXRHaTMwK3lNS3pTSnV3MGlCVWVkU0VjSEFL?= =?utf-8?B?V0ttOWRBMy9GL1pqSVAycGhGaGhTR1IxS1NlR1k4VDQ1Y0RjbEM0L0htS1l2?= =?utf-8?B?S3RDa3NtcGxsMXJCQThvL09CSDhac2dlUlJ6STUyRSt3SThna1c2V3pKc3pM?= =?utf-8?B?bWVNajBDM2Q5aDlubjJORzQvbmlsVWRjRlJDNGRwR2Z6dWtOWHdZKzR2NkhO?= =?utf-8?B?RWd2TEF6NG51UlFyU2JjL2F6NW8wSm5YY1UvUWNiVXhneWlXMHVLWEZkbHYv?= =?utf-8?B?WDZaNFFOTEdST2RPdEptS2w2eFFlcVhjbnJTc1dsMUFSVXI3ZXh1Rm5BUW9P?= =?utf-8?B?dEw2MUxNR3JQb2VoR1BvOW1lRmFBUmE0T3ZBNG5aMWpubGhrbmFhUnMzangw?= =?utf-8?B?dUR4YnVzSHIwZXZYYm1Zd281K3ZmNFMra2xIeTA5MFlHL2tnMEYzNXZNREZs?= =?utf-8?B?Y2lZL05pZHlISENWTUNjTmU2SGg0czYxcEVEZ2wzdGxhWERlRmQ5dVN2NVpn?= =?utf-8?B?MkxJMm9ObE40NEE3cldCYjFVMmpWaStrd0FMM0ZGQ092UGxIcFV3cEpsWmo1?= =?utf-8?B?RDJNbXByVnRKN2FpLzh0RzhjZTJRLy8wYW1zYzdEa0VIVnRyeFRHWExsUFZv?= =?utf-8?B?YVFYaUtXMlh6NG5ma1NVNmVJa2lKdW9VOWlLRXRLM21zTmd4RmkzMVB0bEdk?= =?utf-8?B?blhUUFVuay83d1dCQjJKMUNqK0VmcklWQUptZTMvTkJycWhVVnQxZnZsdVVY?= =?utf-8?B?VHhJOEJ6VEtRWjgwTW81dWtYYVcvcXc0WDA3U3BtbUhQUjR3OFVBZ0MyUXBT?= =?utf-8?Q?AB3BO+Hhg9GunwRw=3D?= X-Exchange-RoutingPolicyChecked: Z2Ungg1phSQoHopf8sFqFEkY6q4KpR9axQ86f/l7K1+y2G3JOX9s/p6LKDVLL2N+c/OEhxes8lqlF4epSqQlCSxk3WXJPfEFxwED4gMAGVsDx+c1Se7b6izRLESM1s+89x0TONubGMEFE/MaoXTzYyR6qw5nXBGwI8oaieLWnd2B3MgtO1UBBu87enL7R3IKg3JMFI4KCRSAqaNLlu9Hdzk9+gDmGvTPWLIunPzyYHzNoTlotLg1+jb1xzPBVbQEzJTB/I7R6wJB/1Mfc6t3oi8LTx3ii9G19emmCOo9VWMQGR0jLPonnCDDDC/2DgcZgp/io5IMcqq8HEzWHtSF6g== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 8Wa7mDNmjqCsymT+sRgByk+P+SqpQLswoUCfTDs7hsM5N2VfVgkZyE5ukbF30XM3F+Yfh3Pdes/xo6dzirpSY+jj5ALcSkqZvVVRNm5kp8dQ6boSSjSJyO+UsXs4qISaiH+dpGu1kJ3dqS9dgxtyOT/m9U2LiYiq/8alJiFVNXLMBjVuArHjQ3ZBrXdvCpLgovYmNjdgW2yXK3CraH9jtewcTEsDZHkjQB4Cw1bclHVpKclSgKZNXcdQhoZgli63RQgFsbWUDxKyxREsKL3/uIS1bBju8E52uZC4+8X9mK3cWtooIV8CY1dmt4xEgAsGB3a9hiitHQiDJbrsW73z9ynLIhdBVgsoBe6SrXV+H0Nngx3+D5MRur4Rj6FWN2hSLP7rZc8YUSG8g/FLjzgagCASk7/B7jC6Ltzu51aiG3CD9ibV/NxUDntd5mt1KhHJ+idUodV0xATZzrkfOua1lz2Y4dttPQEsSZwv8Qsnh/KuAfYtjVsA6JE6fU+8aI35gGYB8G/DIFv6XEy8XK5ufMvnSmkvr2LaNof9w4hjj5TRsK6uxXfhoL10RJwX5+yG05Qjr+3n7t1p/I32xGD1yh9QjhvW4aRw7mcgbs5QUt8= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: e3025e6f-ae2d-4cdb-3e69-08df15cb0a42 X-MS-Exchange-CrossTenant-AuthSource: SA3PR10MB7041.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 21:23:10.6006 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Tf4GmYMJI7thgYIHOUYXZVvNl2rniQsyBshj6NAZFxIY2ofNguo9oq8EV6mh4MGr0dp2rrD7IlvOmAcSi09uPUu4VEOYv1ANCTjL1nf4seg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB6174 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-18_06,2026-09-16_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 phishscore=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2609040000 definitions=main-2609180308 X-Proofpoint-GUID: x2AGS0BwpT7c39hw1dZJ4Qh49EtUGwUn X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE4MDMwOCBTYWx0ZWRfX1VW/WojzhTbL qv03GmFm6nMjAAo0b5xXxUhGWZrbNC2HMDH9qONcJgo/zgAxmdbR2qhYxIC9oMs0xxZFBAbOGou D7hLE3m0QZDTmbhx5rsAkpWL2d+CgYPtXIKKDHEnY9L2aAeicREL X-Proofpoint-ORIG-GUID: x2AGS0BwpT7c39hw1dZJ4Qh49EtUGwUn X-Authority-Analysis: v=2.4 cv=c9k+0h9l c=1 sm=1 tr=0 ts=6aadabc2 cx=c_pps a=XiAAW1AwiKB2Y8Wsi+sD2Q==:117 a=XiAAW1AwiKB2Y8Wsi+sD2Q==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22 a=jiCTI4zE5U7BLdzWsZGv:22 a=x0eKOSpe3m1H3M0S9YoZ:22 a=ZYxcR6NyhFUkZoqTm-MA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE4MDMwOCBTYWx0ZWRfX209Dk0fpVunO fFgxpljj4zjLNX21ohkrmP+vrEbv2spkrA7mUJMWY7gaMdfMqt/ex8vbB0pSokCbQQbTSADnAru /RP65QIU/LzQH93N4xhfYHzHjhLVWFUZCCahydF8RICdzrGv7H6ifM8SESVBkMU/IztRLsTc6Nc jHnbAOJn5e7jqIG5ISz1yelaqNWoqEJRhOJKqJDqXuGxZNs8XXTz1lMZHzrPsYpDAbJeXnpPTVT +VUMUHIGQm56uL7oC32COzG0twII1TOwfKk432TgwaQKCdtrTvXjOgDYo97wHP3gVPZq/JRIXDI cijdCvgcLCDwqERMMMpqo46HlowDIWUyAV8dAyCJuPNFNlM0O3d10SQtT2X19Nw/kzhzqSIEG2o 7vXCEafqOjkKFZCt85Wsrl1wy3qGIWL+DgH7T6SJYO6ZrXgzdKFbIDwcFtF5BmuVPHPNAakedxw rQ4gYMd7iutO4EkY0zw== X-purgate-ID: tlsNG-bad1c0/1789766608-BD6C2034-47E9F844/0/0 X-purgate-type: clean X-purgate-size: 3508 On 9/17/26 04:06, Grall, Julien wrote: Hi! > Sorry for the late answer. The topic is a bit tricky. Thanks for replying regardless. FWIW I tried to get some feedback internally as well, and it seemed like no one wanted to get involved. :) > On 29/08/2026 07:06, Jan Setje-Eilers wrote: >> Hi all, >> >> I would like feedback on whether Xen needs to flush every page in a >> dom0less xen,static-mem bank before assigning it to a guest. >> >> Static-memory support is currently enabled only on Arm, where I am using >> and testing this change. Its implementation and acquisition path are in >> common code, so this RFC is about the generic static-memory path. >> >> The current code cleans and invalidates every page in the bank. This is a >> safe default, but walking a large bank can add several seconds to boot even >> though Xen only writes the pages used for the guest kernel, initrd, and >> device tree. >> >> Here, cleaning refers to cache maintenance, not boot scrubbing. With >> bootscrub=1 or the default bootscrub=idle, Xen assigns dom0less static >> banks before boot scrubbing starts. The pages are no longer free, so boot >> scrubbing does not clear them. >> >> My starting point is that if a platform permits the untouched pages to be >> cleared before guest start, the guest cannot depend on their initial >> contents. This is a platform policy assumption, not something Xen's boot >> scrubbing establishes. Xen already cleans each page it writes during >> domain construction. >> >> Would it therefore be reasonable to let a platform skip the full-bank >> flush, provided it can also guarantee that the untouched pages are absent >> from all caches and that firmware, DMA, EL3 services, and other CPUs do not >> write them before guest start? > > IIUC, the cache flush was mainly added to prevent memory leaking between > two guests if they are the MMU off (see XSA-364). I think what you wrote > makes sense, but I would prefer Arm to confirm this is fine. For Xen ... Yes, I think in a world where guests are coming and going, and smaller, this flush seems relatively sensible. >> I am using no-staticmem-cache-flush with bootscrub=0 on a 64-bit Arm >> system with two dom0less guests. Both guests boot normally. Skipping the >> flush reduced Xen startup from about five seconds to about one second. > > ... I think the slow down you describe could also happen when a dynamic > VM is created (e.g. via xl). > > A few years ago, Arm introduced FEAT_FWB to rework how stage-2 + stage-1 > memory attributes works. Currently in Xen, we are using the "old" > approach where the used attributes is the strongest of the two. For > instance, the guest has the MMU off, then the access will bypass the > cache. With FEAT_FWB, you can force the memory attributes to be > cacheable even when the MMU is off. > > I believe FEAT_FWB should solve the problem you have (assume your HW > supports it). In term of effort, it is mostly updating the stage-2 > memory attributes and then getting rid of some cache operations (include > set/way emulation) when the feature is enabled. I found that as well, but at least some of my hardware is from just before that shows up. > BTW, how much memory do you give to the domain? 4 seconds difference > seems quite a lot. This is two domains: 15 1/4 G to one and 4 1/4 G to the other. It really stood out when we did a boot time reduction exercise. -jan From xen-devel-bounces@lists.xenproject.org Fri Sep 18 21:26:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 18 Sep 2026 21:26:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425910.1649600 (Exim 4.92) (envelope-from ) id 1x7g6N-0007GQ-3S; Fri, 18 Sep 2026 21:26:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425910.1649600; Fri, 18 Sep 2026 21:26:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7g6N-0007GJ-0l; Fri, 18 Sep 2026 21:26:35 +0000 Received: by outflank-mailman (input) for mailman id 1425910; Fri, 18 Sep 2026 21:26:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7g6L-0007GB-UW for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 21:26:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7g6L-007EQD-BX for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 23:26:33 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aadac7a-bab6-0a2a0a5309dd-0a2a4504e610-16 for ; Fri, 18 Sep 2026 23:26:33 +0200 Received: from [74.125.228.42] (helo=mail-pz2-f42.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aadac87-b57f-0a2a45040019-4a7de42aa754-3 for ; Fri, 18 Sep 2026 23:26:33 +0200 Received: by mail-pz2-f42.google.com with SMTP id 41be03b00d2f7-cc1ceb47d55so264591a12.1 for ; Fri, 18 Sep 2026 14:26:32 -0700 (PDT) Received: from localhost ([153.61.198.254]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39e6cb427casm1165720a91.17.2026.09.18.14.26.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2026 14:26:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="In-Reply-To:References:Cc:To:From:Subject:Message-Id:Date:Content-Type:Content-Transfer-Encoding:Mime-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789766791; x=1790371591; darn=lists.xenproject.org; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=D3SEXFUxByL8NwUA0aascO5krkdBelJ+D590uzi7yTc=; b=UNHs+MiHd2nfXX+g1Zs+29XnW3IMxTi3uEwxBn/R7Ng/bUxqhK7x6VckNm7rmGWK+N ayqnrS0rvUgLu+C2eHUnAVYcHlIdp0MEJZE4trNybOaRR7HmzmA+X35UmTxYmK8GmEOO NitypRppCOg1SAVFqpRyp2bykY/l1JL0PQnykpy3iiVLi8pG2CAbVXaiN1LtXZ3ar9Cs /cwmYUBAIChYb3cmOmBEtJ+tDbfNUQm5TiFWnxEgXDgf4ZPGP3VwwK+ULgrwibdtWBgr 9no/PT+4Tx85lhLmXaHNX3Kzf96g9h3WGs1s47CLcH8+ob8B1HK6AkWi/ItlwjwxnsTv eMKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789766791; x=1790371591; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=D3SEXFUxByL8NwUA0aascO5krkdBelJ+D590uzi7yTc=; b=o0Fkj1q1oxT5ubgcKt5DtIe67+H77F7Rw4OMMNWONHSk5I6+SbT0cFRCatvUh5q20i gbykyrdkXQz89kFNYOqXdebvtBrOwqAK1SAw1pwp/uupCZDxweFjqalX1zVlw2gCwaee qCreTVdof2Z8h3D1ykfyhUTRUJGtkpjxjeeGho7OOUvWbdcN/Hz3xy4OTbwq+EAcAvhC mG9RC82eEKqdHTADqmhHF24MBnuxmKXuZ3g91qfKU830YyoxSnGiqQ3qZhWGMvBK6Y38 1HtYChPemH7RwdEDQ0n1tZiQR4h/JceCA0AEsHbxJ37QkECQcfQ7UQ7S7Bwsk5B3bKMb ct7A== X-Forwarded-Encrypted: i=1; AKwUvBzWUoE4dvGrPoNmQZ0owMTmGzI/FnKzWtSk3WV+WBmz7PXe4i98vZhE14gU8uEFHVAtWx11Ydq9Ghc=@lists.xenproject.org X-Gm-Message-State: AFuF++mycoL0qf1mVONs/ZXFOdS074+pnqOTt4XjMsN0u7n8xYIVw4nm ilvIfwILdsoqc8Q8FbewkEH+A+fNfmQAHsdJ6l19Yoq6Huqov/X6tbm+ X-Gm-Gg: AYBFou1ZVTlYiMASB6Y2RzR4Tf6j3nZEsFBk9y0/TKs1vUhYbt3NsR8F8aVyJNHlfFy 6U6xj0zTUWHLENJS2REyKOrtGeWGXSHtJhUKqm8qW0jCqrB+s9ztn51u+j89zrmFu9fL6hVJRCZ afmSl9ZivwyBX5FWxAd1hVkt5Msu1WKhWaugJgDl8UWIizWFXJA+3jhjwzbbnunrwLmb774yQ72 LKKGJgkNEmO/94N5UzngcyvS0L+EpzrxW8kuQ3GiRRNyyByNs8zhMof7o4JRcB111ij3a3ye9XM AnulYdZyZ6O6U1c+HGSgv429yohTgOZiZ8oUavvwgcAbZDsN8qkjnApxPmDYlGTipuQ2n05dzWj GoGhO/oAmgzFuj2o93TsWOLaHvtzaF1BVih4nmVf05KeiEQCWE114oPgYti5kTIZ7DT6EvtKB9q VwXpwXCuA38qjCYvnpjWMEZWWw7+4KBdBHoo2iVpfkQy5DlkRhRH+5r2emE0bfox8yULuFeKhum JQ+bDL7rumYdD+WXDBBq4eZ3xSmFILbsnyZw12HtVJ4utx+JyvFhvoQg4BIIWE2OjyuIypYkOA3 kEgH X-Received: by 2002:a17:90b:2584:b0:39e:6c68:fd89 with SMTP id 98e67ed59e1d1-39e6c68feb9mr902813a91.30.1789766791008; Fri, 18 Sep 2026 14:26:31 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 18 Sep 2026 21:26:29 +0000 Message-Id: Subject: Re: [PATCH RFC v4 07/13] bpf, x86: Take a Tasks Trace reader in the trampoline around its call-outs From: "Alexei Starovoitov" To: "Josef Bacik" , "Paul E. McKenney" , "Frederic Weisbecker" , "Neeraj Upadhyay" , "Joel Fernandes" , "Boqun Feng" , "Thomas Gleixner" , "Peter Zijlstra" , "Steven Rostedt" , "Masami Hiramatsu" , "Mark Rutland" , "Jiri Olsa" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , , "Catalin Marinas" , "Will Deacon" , "Puranjay Mohan" , "Xu Kuohai" , "Paul E. McKenney" , "Frederic Weisbecker" , "Neeraj Upadhyay" , "Joel Fernandes" , "Boqun Feng" , "Thomas Gleixner" , "Peter Zijlstra" , "Steven Rostedt" , "Masami Hiramatsu" , "Mark Rutland" , "Jiri Olsa" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , , "Catalin Marinas" , "Will Deacon" , "Puranjay Mohan" , "Xu Kuohai" Cc: "Andy Lutomirski" , "Josh Triplett" , "Uladzislau Rezki" , "Mathieu Desnoyers" , "Lai Jiangshan" , "Zqiang" , "Juergen Gross" , "Luis Chamberlain" , "Ihor Solodrai" , , , , , , , "Andy Lutomirski" , "Josh Triplett" , "Uladzislau Rezki" , "Mathieu Desnoyers" , "Lai Jiangshan" , "Zqiang" , "Juergen Gross" , "Luis Chamberlain" , "Ihor Solodrai" , , , , , , X-Mailer: aerc 0.17.0 References: <20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com> <20260918-b4-rcu-tasks-preempt-qs-v4-7-63f0e9d69661@toxicpanda.com> In-Reply-To: <20260918-b4-rcu-tasks-preempt-qs-v4-7-63f0e9d69661@toxicpanda.com> X-purgate-ID: tlsNG-ebf023/1789766793-C10DDB50-9A27AA68/0/0 X-purgate-type: clean X-purgate-size: 4865 On Fri Sep 18, 2026 at 2:49 PM UTC, Josef Bacik wrote: > On HAVE_RCU_TRAMPOLINE_READERS kernels Tasks RCU keeps a BPF trampoline > image allocated only while a task using it is a Tasks Trace RCU reader > or is executing text that rcu_tasks_trampoline_text() recognises. The > image itself is such text, but the C glue and the programs it calls are > not, and only sleepable programs take rcu_read_lock_trace() today. > > Have the x86-64 JIT open-code rcu_read_lock_trace() and > rcu_read_unlock_trace() in the trampoline, as ftrace_64.S does for > ftrace_caller: one reader from just after the frame is set up to just > before the original function is called, covering __bpf_tramp_enter() > and the fentry and fmod_ret programs, and a second one from just after > the original function returns to just before the final register > restore, covering the fexit programs and __bpf_tramp_exit(). The > original function itself runs outside both, since it may run for a long > time and the image is pinned by im->pcref across it. Trampolines that > do not call the original function get a single reader around all their > programs. The second reader is entered before ip_after_call, so the > ip_after_call -> ip_epilogue jump that bpf_tramp_image_put() patches in > is inside it, and the fmod_ret early-exit branch lands after that point > still holding the first reader, so exactly one is held on every path. > > The sequence uses r10 and r11, which are scratch at each emission point, > and references current_task and rcu_tasks_trace_srcu_struct by absolute > sign-extended address, the form the JIT already relies on for > this_cpu_off. Sleepable programs' own rcu_read_lock_trace() simply > nests. Nothing is emitted on other configurations. > > Suggested-by: Alexei Starovoitov > Assisted-by: LLM > Signed-off-by: Josef Bacik > --- > arch/x86/net/bpf_jit_comp.c | 113 ++++++++++++++++++++++++++++++++++++++= ++++++ > 1 file changed, 113 insertions(+) > > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c > index 2853e87797a7..c991f7ceacdf 100644 > --- a/arch/x86/net/bpf_jit_comp.c > +++ b/arch/x86/net/bpf_jit_comp.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -722,6 +723,97 @@ static void emit_indirect_jump(u8 **pprog, int bpf_r= eg, u8 *ip) > *pprog =3D prog; > } > =20 > +/* > + * Open-coded rcu_read_lock_trace() / rcu_read_unlock_trace() for the > + * trampoline, see CONFIG_HAVE_RCU_TRAMPOLINE_READERS and the equivalent > + * macros in arch/x86/kernel/ftrace_64.S. The image is not relocated, s= o > + * current_task and rcu_tasks_trace_srcu_struct are referenced by absolu= te > + * (sign-extended 32-bit) address, the form the JIT already relies on fo= r > + * this_cpu_off. Uses r10 and r11, which are scratch at every emission > + * point, and clobbers flags. > + * > + * lock: unlock: > + * mov r11, gs:[current_task] mov r11, gs:[current_task] > + * mov r10d, [r11+nesting] mov r10d, [r11+nesting] > + * inc dword ptr [r11+nesting] sub r10d, 1 > + * test r10d, r10d jnz 2f > + * jnz 1f mov r10, [r11+scp] > + * mov r10, [&srcu.srcu_ctrp] mov dword ptr [r11+nesting]= , 0 > + * inc qword ptr gs:[r10+locks] (smp_mb) > + * mov [r11+scp], r10 inc qword ptr gs:[r10+unloc= ks] > + * (smp_mb) jmp 3f > + * 1: 2: mov [r11+nesting], r10d > + * 3: > + */ > +static void emit_trace_rcu_reader(u8 **pprog, bool lock) > +{ > +#ifdef CONFIG_TASKS_RCU_TRAMPOLINE_READERS > + const u32 nesting =3D offsetof(struct task_struct, trc_reader_nesting); > + const u32 scp =3D offsetof(struct task_struct, trc_reader_scp); nesting_off ? scp_off ? Otherwise EMIT(nesting, 4); is a bit confusing. > + const bool mb =3D !IS_ENABLED(CONFIG_TASKS_TRACE_RCU_NO_MB); > + u8 *prog =3D *pprog; > + > + BUILD_BUG_ON(IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE)); > + BUILD_BUG_ON(offsetof(struct srcu_ctr, srcu_locks) !=3D 0); > + BUILD_BUG_ON(offsetof(struct srcu_ctr, srcu_unlocks) !=3D 8); Looks too hardcoded here. Why not to use the same approach as with offsetof() few lines above? Overall looks ok, but I wonder what Paul will say that rcu_read_lock_tasks_trace() becomes baked in into JITs and will be pretty hard to change. We also lose rcu_tt lockdep runtime checks. So lockdep might get confused? From xen-devel-bounces@lists.xenproject.org Sat Sep 19 07:43:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 19 Sep 2026 07:43:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425190.1649608 (Exim 4.92) (envelope-from ) id 1x7pjA-0005Nc-O5; Sat, 19 Sep 2026 07:43:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425190.1649608; Sat, 19 Sep 2026 07:43:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7pjA-0005NV-L8; Sat, 19 Sep 2026 07:43:16 +0000 Received: by outflank-mailman (input) for mailman id 1425190; Fri, 18 Sep 2026 11:44:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7X0c-0000ld-T1 for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:44:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7X0c-005RYQ-9F for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 13:44:02 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad23e9-bab6-0a2a0a5309dd-0a2a45019ee2-36 for ; Fri, 18 Sep 2026 13:44:02 +0200 Received: from [209.85.214.176] (helo=mail-pl1-f176.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad2400-5984-0a2a45010019-d155d6b0a9df-3 for ; Fri, 18 Sep 2026 13:44:02 +0200 Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2db710396ffso13752705ad.1 for ; Fri, 18 Sep 2026 04:44:01 -0700 (PDT) Received: from 73ebd4c7787b ([183.194.144.114]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-144ce02b063sm3404520c88.9.2026.09.18.04.43.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 04:43:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789731840; x=1790336640; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=z+gIlvnIDxGsE2zs/bxvoadgXEzUPdH93sukY7i/YsA=; b=F8oElvNM0pb5LiWHm6DkhSa3JuppfKE0/7YzK0ZodNKIziII51cXNnmU3klMaU6Lsw JAldqTaW4+wdHHf1lj6SzabXgx/pejNMBbzmXS+HQqiYh3f902FmXQUbf9QzmyiutHK/ zO/QBH5vs944Ms8kVLiU0OCWFcScFmGxmgL6yu/wfIS8sPhga70mYvOxW+9RpiP2AK88 SWLOVR663nYuBHlucQbaauXq6smQet3g0YEX7w0geiP0wddDCppIy6OQs0Xl0BaUloBM e26+hYxmqyxKdDokHdHfErQ9KUb/n4aPvYZybum3/wK4hltKmc//cBxGuZJkCOs0Hez0 yZxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789731840; x=1790336640; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=z+gIlvnIDxGsE2zs/bxvoadgXEzUPdH93sukY7i/YsA=; b=wyBpJH51U0PwMLo6ZvuMG3l5auW4NrkOEtElTbOy/8+mEq6RZXrXUz4axolDN4TzLl LcqZ679BE66k0Q3ZiWFWuMSmw4ACS2CDWXRsY54DypcEzYJdqPgODXC4j0oWbTWaWrpU vI87mnFe1ZyxuM0F5dkEpcmkvE6vP6PajIFbzyiaJdc6urv95jL59sYMcuZt+D5sXFH0 Mw/GXONaHLCCDKm3UR0NEjhmB+QHrpzrXFul7ry7I+Ww2shv1pYxOgHBXRKvU16iLqmm 1UlgZiJYzj1SK3OmVmkFM6555Di4Z/jL42F8zyN8M7UFAQb5/KK1MlGx2Gewg1EkrCHC LMGw== X-Forwarded-Encrypted: i=1; AKwUvBxpSnS2R8SziIbhwmcfb7qibAqoUsnHKc6P8dInzM+S+Wn4QOih8WSIEEyDxO8ZXiXYK1DpXUxdOmk=@lists.xenproject.org X-Gm-Message-State: AFuF++l8S64LAoFEla7kf/EKMTL8TdURc9d1tMihkTcR3WMcjC2Da/7c umss3uQcS2oO42ejGAF0bGQyL5eupbhPusRw7DfbZEXv3UBkXmXDBqEO X-Gm-Gg: AYBFou0C+sz0H0F4912SUOrQqZZRLZGTe2XgESisWhJg8JXgiXH0R2HaxlYRnC9FVkK 1OSGnEjY4eXdZfh/yIHf4Vy6GowjLOVfe9dI1wNkMJN9XKtHEsLD6CriVUmLLfkFNphodjOm7aE 4ByVSNTgrdc69ybY7a5g0LPCXmhXsrpACy/dj139Gxfbd3y4rOU5NeAU1r4GoHqeIKto/Lx0RY0 t1HYs8P2D3vcETT/tWvLBsXDCUIkQza15Srx+JijPrZ801MOEMYF7mMN4JHyoFG/yZx+wrnyVhC AxQL6TdNyhyfDXf4+QfXS9iOSaFgqJAfE34e1NqkHdpgIYMw/nGLR8ATTgNhIiRnhIzkTmPpr8g 2Zs0x0ZeIGx6nfFU/xmcId+csGT7YGoOaMmQZ66w7OlKlucKzyv40OZBxKZeaes69gHFyCdhZOG Wx22FV3aCH8FmrVNGNjlhLqoNfvMiTxiRi3ir++wi/OiaypdoXHBZg6AYCyLk/3G4izXYI/5Bt7 PBsCBau++Y= X-Received: by 2002:a17:90b:3b52:b0:39e:fe9:c5b8 with SMTP id 98e67ed59e1d1-39e35df66f8mr9845308a91.10.1789731839978; Fri, 18 Sep 2026 04:43:59 -0700 (PDT) From: Yuchao Zhang To: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Juergen Gross , Stefano Stabellini , Jens Axboe Cc: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Yuchao Zhang Subject: [PATCH 0/1] xen-blkfront: unbind irq before tearing down ring and shadow requests Date: Fri, 18 Sep 2026 19:43:53 +0800 Message-ID: <20260918114354.3660102-1-ndaugoing@gmail.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1789731842-C5341757-69EEE914/0/0 X-purgate-type: clean X-purgate-size: 1669 Hi Roger, Juergen, Stefano, and Jens, This patch addresses a race condition during device disconnect and ring teardown in drivers/block/xen-blkfront.c. Problem: In blkif_free_ring(), the driver currently cleans up all persistent grants, frees indirect pages, frees the shadow request structures (rinfo->shadow[i].grants_used and rinfo->shadow[i].sg), and tears down the shared ring via xenbus_teardown_ring(). Only after all these deallocations does it invoke unbind_from_irqhandler(). Because the event channel interrupt (blkif_interrupt) remains active throughout this teardown procedure, a completion interrupt received from the backend runs blkif_interrupt() concurrently on another CPU. Since blkif_free_ring() tears the ring and shadow structures down without holding rinfo->ring_lock, this races against the cleanup loop, leading to use-after-free and NULL pointer dereferences when accessing rinfo->ring.sring, rinfo->shadow[id].grants_used, or rinfo->shadow[id].sg. Fix: Move unbind_from_irqhandler() to the beginning of blkif_free_ring(). This immediately unbinds the event channel and synchronizes with any in-flight interrupt handlers via free_irq(), guaranteeing that no interrupts execute concurrently while ring memory, grants, and shadow structures are being freed. This matches the teardown ordering already used in drivers/net/xen-netfront.c (xennet_disconnect_backend()). Best regards, Yuchao Zhang Yuchao Zhang (1): xen-blkfront: unbind irq before tearing down ring and shadow requests drivers/block/xen-blkfront.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Sat Sep 19 07:43:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 19 Sep 2026 07:43:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1425192.1649614 (Exim 4.92) (envelope-from ) id 1x7pjB-0005Q7-1c; Sat, 19 Sep 2026 07:43:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1425192.1649614; Sat, 19 Sep 2026 07:43:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7pjA-0005Q0-SJ; Sat, 19 Sep 2026 07:43:16 +0000 Received: by outflank-mailman (input) for mailman id 1425192; Fri, 18 Sep 2026 11:44:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7X0g-0000m8-1K for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 11:44:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7X0f-005RYQ-EP for xen-devel@lists.xenproject.org; Fri, 18 Sep 2026 13:44:05 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aad23ec-bab6-0a2a0a5309dd-0a2a4504d3ce-46 for ; Fri, 18 Sep 2026 13:44:05 +0200 Received: from [74.125.228.12] (helo=mail-pz2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aad2403-b57f-0a2a45040019-4a7de40cb4c9-3 for ; Fri, 18 Sep 2026 13:44:05 +0200 Received: by mail-pz2-f12.google.com with SMTP id d2e1a72fcca58-85469e211a0so744071b3a.1 for ; Fri, 18 Sep 2026 04:44:04 -0700 (PDT) Received: from 73ebd4c7787b ([183.194.144.114]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-144ce02b063sm3404520c88.9.2026.09.18.04.44.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 04:44:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789731843; x=1790336643; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LQcaFZ1+zYaV5pEknG6YG0muENfu4eg72I6eX4kOQzo=; b=nrCtgIqp6oi7QgbotHWv7xoHCuTh3C9rSpz8fgBGGz8EowRRI6bZhcTpbOAlH50D+q lD6bIU14t6RD4T4iIGcXaXquwiCJ0f7PNgOUF2sKwYE9uVHXe9JAvDJHrrTqxkZL4Kec clsB+2VuLpsMpXAuKmC4h1Pq64vf99p7QoXxfNZ/uvSEMzCrS7a6qy7JcK3RGIK/AT9u SS51G5yMxfMf2vXo5bg09msDe+EiXoDqbHF3F62/JcHCO9yqkradAEt+wouhckA3AcTc nGwP0WKZpLbzJrCYaCwG4hp1DOVpuxY/jlyjrEjz7bOA/6xaJAfKHNXANjsUXK8BRw9v 6SLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789731843; x=1790336643; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=LQcaFZ1+zYaV5pEknG6YG0muENfu4eg72I6eX4kOQzo=; b=YU/SJl4lldsuJtUjTIElMGLs+l36pxCpUH5ZFl20bwGKq+++AM3GPuHRTr+DkiFzEA sF7Oz5e0ZBWlRBOSbzKjNseQSgDK2nkGiW1BvS+nZ9vfFCUNiG6WYM0uNuEidaSlQ9nH tkR7Ie9W2PjzE5QnTQs8TOusdJaL3vkKLzhak0eWCYa+mp5eYFmowZG8VlGvRYa6llI+ hZGnm99ipl9eQofilGIdlztGv4e4vmB+9jYj3lwEiIpoRINIDRqsv6SrVtubLzozIueB 98zH4S+aQIIfd0twazNzK5NXuRaOIiZwmth4mMZ9fPbtxgyDXQvwhtQEoNezU0GNhwBy p6cw== X-Forwarded-Encrypted: i=1; AKwUvBwR07DcHWgg291NPQt0a/PbfjKagvzeMCM6ADiTASI1kxE2yYP3O03Paxa7ugpYSPau2tJLohq1qc4=@lists.xenproject.org X-Gm-Message-State: AFuF++kTxKi+ECOqS7wuQIgsCr3vpx+6lWfcaEEi7fNrO4lXe4iyCZtd 6s6SpjVPjSGpihI4kUrc3xAi67mNKJ3irk2zvzSJaHCkRNXJNI36ywoPU+2KVusXj8IiXg== X-Gm-Gg: AYBFou0cIyzNwOrKfcY5fgOT/YW1vgvzGuVHRtBqL7yjfpoKXP9GEWywZpKagoWQy+O KNcPCmOUwWFDiXAKaRhCNl+t9O7PLISfJGha0k1OZov/X2RgNkbl7GeNgNF3KCiwWOD1MZT40ks TE1qkTTMUoSw7iQKDqtjHbC2fvYNTcC8ib42tZr6kE018V+TG/EuR8UedQnigHGB+vKOtpj+GE+ bnrrOiNewRCWEg7eBuzULhOHa1BgtzKdt1xOVd88DINnbtvrmovOjA1k7HydXVPK4CICYfabtta WcMBJeH9oyrjAPlSDLwuwjYk1INfLNkhuZFl3jagdIBHJBjMJdFRjuLXF2kHmnaxgCvoT3BcEmf 7R8jWf2L0PEy016SWq9mazFfOpqcmncMV+CAJ4tfpEoEoQ6PregwybrudhOSjxSFtCmL38169d7 gUaB0hbITdT2ucnEgJZEEdiFNOC93f0Pl3i+4umG7dDya6+npWU8QfxdvJFyQls48x7jwRpHLKi O6mSVyW/bs= X-Received: by 2002:a05:6a21:9204:b0:3d1:e510:905f with SMTP id adf61e73a8af0-3dd8c3fd351mr4731985637.1.1789731843082; Fri, 18 Sep 2026 04:44:03 -0700 (PDT) From: Yuchao Zhang To: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Juergen Gross , Stefano Stabellini , Jens Axboe Cc: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Yuchao Zhang Subject: [PATCH 1/1] xen-blkfront: unbind irq before tearing down ring and shadow requests Date: Fri, 18 Sep 2026 19:43:54 +0800 Message-ID: <20260918114354.3660102-2-ndaugoing@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260918114354.3660102-1-ndaugoing@gmail.com> References: <20260918114354.3660102-1-ndaugoing@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1789731845-536C2B50-215AD034/0/0 X-purgate-type: clean X-purgate-size: 2391 In blkif_free_ring(), the driver tears down the ring's persistent grants, shadow request arrays, and shared ring structure (xenbus_teardown_ring), and only calls unbind_from_irqhandler() at the very end. While blkif_free_ring() is freeing persistent grants and clearing the shadow array, the event channel interrupt (blkif_interrupt) is still registered and active. If an interrupt arrives from the backend during this teardown window, blkif_interrupt() reads rinfo->ring.sring and, via blkif_completion(), accesses rinfo->shadow[id].grants_used and rinfo->shadow[id].sg. blkif_free_ring() tears these structures down without holding rinfo->ring_lock, and the handler only checks info->connected at entry, so this is a real race resulting in a use-after-free or NULL pointer dereference. Fix this by moving unbind_from_irqhandler() to the beginning of blkif_free_ring(). Calling unbind_from_irqhandler() first frees the IRQ and synchronizes with any in-flight interrupt handlers on other CPUs before ring memory and shadow request structures are deallocated, matching the teardown order in drivers/net/xen-netfront.c. Fixes: 907c3eb18e0b ("xen-blkfront: convert to blk-mq APIs") Cc: stable@vger.kernel.org Signed-off-by: Yuchao Zhang --- drivers/block/xen-blkfront.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8dad7bf5f664..e70b78ca4df2 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1210,6 +1210,10 @@ static void blkif_free_ring(struct blkfront_ring_info *rinfo) struct blkfront_info *info = rinfo->dev_info; int i, j, segs; + if (rinfo->irq) + unbind_from_irqhandler(rinfo->irq, rinfo); + rinfo->evtchn = rinfo->irq = 0; + /* * Remove indirect pages, this only happens when using indirect * descriptors but not persistent grants @@ -1292,10 +1296,6 @@ static void blkif_free_ring(struct blkfront_ring_info *rinfo) /* Free resources associated with old device channel. */ xenbus_teardown_ring((void **)&rinfo->ring.sring, info->nr_ring_pages, rinfo->ring_ref); - - if (rinfo->irq) - unbind_from_irqhandler(rinfo->irq, rinfo); - rinfo->evtchn = rinfo->irq = 0; } static void blkif_free(struct blkfront_info *info, int suspend) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Sat Sep 19 07:50:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 19 Sep 2026 07:50:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1426080.1649627 (Exim 4.92) (envelope-from ) id 1x7pq9-0007U2-MN; Sat, 19 Sep 2026 07:50:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1426080.1649627; Sat, 19 Sep 2026 07:50:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7pq9-0007Tv-JZ; Sat, 19 Sep 2026 07:50:29 +0000 Received: by outflank-mailman (input) for mailman id 1426080; Sat, 19 Sep 2026 07:46:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7pmi-0006L5-JQ for xen-devel@lists.xenproject.org; Sat, 19 Sep 2026 07:46:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7pmi-006jXm-0V for xen-devel@lists.xenproject.org; Sat, 19 Sep 2026 09:46:56 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aae3def-2eae-0a2a0a5409dd-0a2a4503cc38-2 for ; Sat, 19 Sep 2026 09:46:56 +0200 Received: from [74.125.227.136] (helo=mail-pj2-f8.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aae3dee-fae8-0a2a45030019-4a7de3889794-3 for ; Sat, 19 Sep 2026 09:46:55 +0200 Received: by mail-pj2-f8.google.com with SMTP id d9443c01a7336-2d8fcda61c8so6253305ad.1 for ; Sat, 19 Sep 2026 00:46:55 -0700 (PDT) Received: from ethan-latitude5420.. (host-127-24.cafrjco.fresno.ca.us.clients.pavlovmedia.net. [68.180.127.24]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-144d54af4d5sm4304553c88.2.2026.09.19.00.46.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Sep 2026 00:46:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789804014; x=1790408814; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=0WlyPHwpsJQj7McTxWFAv7Df5j2tDpqRuiibzqiyHFE=; b=Qwwyw/ZZmqMR0PxYYr2KKao/ek/X5UotKqX+ADCMf2ewhvmIiOBCOPrGqUT0J9JqeD uHSURA9Y+iItjVEf3801x/+84lWK1KH34nQY1ttjlhz+KbGpIu7Laa2JaIbGhIE782Cr u79SF90IFfIqTFX+i2Z72ZMf/cPRTvhGfSaORj9PrcnRXWKd9N5Qf53VXjW8rw/Vp/Vl buefrb0SWsqZlFYYDxqYtdO0fy8xILt2Ha/omNmwHdlV7BUsXScHzcaDP/Pv+Tvw4azQ Vs3RENV/31hJY3BrmXWbRvtttSknSQ1PR4WNGw3/R7pCzY8dTNT4hyZdCi27Whdd4rAn veXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789804014; x=1790408814; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=0WlyPHwpsJQj7McTxWFAv7Df5j2tDpqRuiibzqiyHFE=; b=oRs74ZePGTTok9h1c27e+a9b+udttEEkQBHHLqI/hMbbL57wKGodE7Fqn/IbMBdmj1 ZNMhwrHrrS6upeWdUaxrb8vcXcWR9ZSGNbY5cDZZvYyeN59CiV9t2adHjMErf1q8RgiM LvlfbvBu5boJYCvfUDd/Ex8uJBVmV7rwP1RNE8EmMRQHmau8hyf9HJkI5R5gJuCF9RlI 2ZssldqIili8HdPTHXlAb+NQsl5zby6pjVbuvpDNjIv8UMqj5oPmc5ot1V3CgqoJf474 ecVPv8CDXXtKuHufDDOu14pEQylSDxV+QQhf24EPxDtslGashBcLdNIPOffP4q3GofGI nhNw== X-Forwarded-Encrypted: i=1; AKwUvBya8ztYZVfSbFSg2ti/2MtAC4TDqyGnN0BHS2c5HqxZKzPp9u/Vruo+nhMW0tiXt5I0kc3qTam3z3I=@lists.xenproject.org X-Gm-Message-State: AFuF++kR3X2KfTe7X3EXp9GZ7T0mDBAQkMjWShEhgO3iZI6DsJKeLGMH BPogDmDVk/ORvcJAgYTp6hYxYM97bRDvvO7zEMru6wMXBA7qcIgXTEsF X-Gm-Gg: AYBFou1Hu+6IilAEvaHiG5NWlek5A9xS8fG5fjHya1PSElUc8KWfQmOLXb9LGfx5D5u 8w6tkMKPyw8KEoJVlHotXOc4R4YzuFhitSFp+Lopl/XNsBrJRSeXJXdkTxUE0xNKr5icThJtqJf g5moFVh2KR64JcagTxBrLAjOpuR+Mojq/A/4BIw0oKK5u+ilWo05nZpsD3iR03AuFsxHyGK/YNu 9RBk3WnG++vfUPGHVjnSXnIESzkaUPCtKubuts9bhfflfUZyFIaXvyQrQ4sLbMHBY12aVpq+Yuf 22qEa/bamaBeK/Oz1JVHAKP2Grffr4QLOfBIP2IcUq/bqKpDH2jxkXZfo4muQuBbgjCeBYTcLXI spUM548mONuVvDH8fCUUPT5EkOPJBj5B8QI9ZPZucDrXepZrQ+it4fKiWHAphsFJ2+pfaBm4OGZ 7WYD2rpmTT9Ty2SlolxycNAhJMAMFkYsa3GDus7OSfQ8xan8iMpPrw7Sr6gSVj1MwpYMGh2WGzD MtvHCmnq8ge511L7KZgLoGK5ghiPhcJvgyQVRjugG+jIVsuFB0f2d/ytshR9QDTz0M7LSumdfsH RYnoVawps47IDJ1l6LSQqKDcXJTckTx/A/vsAAhNuP6zWYk2Oxp6p1ZUYWyNSMQm X-Received: by 2002:a05:6a21:6816:b0:3dd:55f2:9785 with SMTP id adf61e73a8af0-3dd8c565ca5mr10244270637.26.1789804013834; Sat, 19 Sep 2026 00:46:53 -0700 (PDT) From: Ethan Nelson-Moore To: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org Cc: Ethan Nelson-Moore , Juergen Gross , Stefano Stabellini Subject: [PATCH] xen: remove unused hvm_vcpu.h header Date: Sat, 19 Sep 2026 00:46:43 -0700 Message-ID: <20260919074650.453007-1-enelsonmoore@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1789804015-7488A4E9-C63DE999/0/0 X-purgate-type: clean X-purgate-size: 3743 The header appears to have been unused ever since it was added to the kernel in commit cee2cfb7d18d ("xen/pvh: Import PVH-related Xen public interfaces"). Remove it. Signed-off-by: Ethan Nelson-Moore --- include/xen/interface/hvm/hvm_vcpu.h | 116 --------------------------- 1 file changed, 116 deletions(-) delete mode 100644 include/xen/interface/hvm/hvm_vcpu.h diff --git a/include/xen/interface/hvm/hvm_vcpu.h b/include/xen/interface/hvm/hvm_vcpu.h deleted file mode 100644 index cbf93493275c..000000000000 --- a/include/xen/interface/hvm/hvm_vcpu.h +++ /dev/null @@ -1,116 +0,0 @@ -/* SPDX-License-Identifier: MIT */ -/* - * Copyright (c) 2015, Roger Pau Monne - */ - -#ifndef __XEN_PUBLIC_HVM_HVM_VCPU_H__ -#define __XEN_PUBLIC_HVM_HVM_VCPU_H__ - -#include "../xen.h" - -struct vcpu_hvm_x86_32 { - uint32_t eax; - uint32_t ecx; - uint32_t edx; - uint32_t ebx; - uint32_t esp; - uint32_t ebp; - uint32_t esi; - uint32_t edi; - uint32_t eip; - uint32_t eflags; - - uint32_t cr0; - uint32_t cr3; - uint32_t cr4; - - uint32_t pad1; - - /* - * EFER should only be used to set the NXE bit (if required) - * when starting a vCPU in 32bit mode with paging enabled or - * to set the LME/LMA bits in order to start the vCPU in - * compatibility mode. - */ - uint64_t efer; - - uint32_t cs_base; - uint32_t ds_base; - uint32_t ss_base; - uint32_t es_base; - uint32_t tr_base; - uint32_t cs_limit; - uint32_t ds_limit; - uint32_t ss_limit; - uint32_t es_limit; - uint32_t tr_limit; - uint16_t cs_ar; - uint16_t ds_ar; - uint16_t ss_ar; - uint16_t es_ar; - uint16_t tr_ar; - - uint16_t pad2[3]; -}; - -/* - * The layout of the _ar fields of the segment registers is the - * following: - * - * Bits [0,3]: type (bits 40-43). - * Bit 4: s (descriptor type, bit 44). - * Bit [5,6]: dpl (descriptor privilege level, bits 45-46). - * Bit 7: p (segment-present, bit 47). - * Bit 8: avl (available for system software, bit 52). - * Bit 9: l (64-bit code segment, bit 53). - * Bit 10: db (meaning depends on the segment, bit 54). - * Bit 11: g (granularity, bit 55) - * Bits [12,15]: unused, must be blank. - * - * A more complete description of the meaning of this fields can be - * obtained from the Intel SDM, Volume 3, section 3.4.5. - */ - -struct vcpu_hvm_x86_64 { - uint64_t rax; - uint64_t rcx; - uint64_t rdx; - uint64_t rbx; - uint64_t rsp; - uint64_t rbp; - uint64_t rsi; - uint64_t rdi; - uint64_t rip; - uint64_t rflags; - - uint64_t cr0; - uint64_t cr3; - uint64_t cr4; - uint64_t efer; - - /* - * Using VCPU_HVM_MODE_64B implies that the vCPU is launched - * directly in long mode, so the cached parts of the segment - * registers get set to match that environment. - * - * If the user wants to launch the vCPU in compatibility mode - * the 32-bit structure should be used instead. - */ -}; - -struct vcpu_hvm_context { -#define VCPU_HVM_MODE_32B 0 /* 32bit fields of the structure will be used. */ -#define VCPU_HVM_MODE_64B 1 /* 64bit fields of the structure will be used. */ - uint32_t mode; - - uint32_t pad; - - /* CPU registers. */ - union { - struct vcpu_hvm_x86_32 x86_32; - struct vcpu_hvm_x86_64 x86_64; - } cpu_regs; -}; -typedef struct vcpu_hvm_context vcpu_hvm_context_t; - -#endif /* __XEN_PUBLIC_HVM_HVM_VCPU_H__ */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Sat Sep 19 16:58:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 19 Sep 2026 16:58:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1426456.1649636 (Exim 4.92) (envelope-from ) id 1x7yNq-0005Tg-04; Sat, 19 Sep 2026 16:57:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1426456.1649636; Sat, 19 Sep 2026 16:57:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7yNp-0005TY-Rt; Sat, 19 Sep 2026 16:57:49 +0000 Received: by outflank-mailman (input) for mailman id 1426456; Sat, 19 Sep 2026 16:57:48 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x7yNn-0005TP-UD for xen-devel@lists.xenproject.org; Sat, 19 Sep 2026 16:57:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x7yNn-00FAjM-B9 for xen-devel@lists.xenproject.org; Sat, 19 Sep 2026 18:57:47 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaebee6-2eae-0a2a0a5409dd-0a2a4505ecbc-18 for ; Sat, 19 Sep 2026 18:57:47 +0200 Received: from [140.77.166.138] (helo=sonata.ens-lyon.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaebf0a-4cb1-0a2a45050019-8c4da68ad02c-3 for ; Sat, 19 Sep 2026 18:57:47 +0200 Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id A7E4EA02EB; Sat, 19 Sep 2026 18:57:46 +0200 (CEST) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0dv8dflxbNV; Sat, 19 Sep 2026 18:57:46 +0200 (CEST) Received: from end (lfbn-bor-1-980-210.w90-120.abo.wanadoo.fr [90.120.173.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id 470ECA01F4; Sat, 19 Sep 2026 18:57:46 +0200 (CEST) Received: from samy by end with local (Exim 4.100) (envelope-from ) id 1x7yNl-0000000Bk3N-2kMG; Sat, 19 Sep 2026 18:57:45 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1789837066; bh=x2rPBn3+93eD4n3f0kucW1BWRjSamWxCzqKS1cFOmIs=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=Ue5rZiCS0jwWtbgzmQhoeFXknojdSPopoVEZqHY2Q8/N1OFXR/Sb1FcIART8Bgqwo XKgPMQXfGZ4hCBfjL1CbQrdacljJTbXsmRJwxVvPv2dSnOXSHYDqPDlUaDUn7ODMqP vNo4jCoXsAVRGBLZPe7AgdPEb0zyghhqjd63+rKY+Yv6juKbpFW7FEnHL4DK6TDVXX E7LRRCegmh1NmH7Mr0ifCLj+bSfI2TA0TWiZWy+o55qcyLG+2zKkDxMiHaIPENcUUZ tFU7g7AMAtA30uKIXWbDxh+I61LkiEf7Zz3YDiAs+Ai9IfUEAkibeOGEgEQipH0daR yMoxSfz1Tx3Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1789837066; bh=x2rPBn3+93eD4n3f0kucW1BWRjSamWxCzqKS1cFOmIs=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=Ue5rZiCS0jwWtbgzmQhoeFXknojdSPopoVEZqHY2Q8/N1OFXR/Sb1FcIART8Bgqwo XKgPMQXfGZ4hCBfjL1CbQrdacljJTbXsmRJwxVvPv2dSnOXSHYDqPDlUaDUn7ODMqP vNo4jCoXsAVRGBLZPe7AgdPEb0zyghhqjd63+rKY+Yv6juKbpFW7FEnHL4DK6TDVXX E7LRRCegmh1NmH7Mr0ifCLj+bSfI2TA0TWiZWy+o55qcyLG+2zKkDxMiHaIPENcUUZ tFU7g7AMAtA30uKIXWbDxh+I61LkiEf7Zz3YDiAs+Ai9IfUEAkibeOGEgEQipH0daR yMoxSfz1Tx3Dg== Date: Sat, 19 Sep 2026 18:57:45 +0200 From: Samuel Thibault To: Jan Beulich , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: xen-devel@lists.xenproject.org, Anthony PERARD Subject: Re: [PATCH 2/4] stubdom: remove pciutils Message-ID: Mail-Followup-To: Samuel Thibault , Jan Beulich , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel@lists.xenproject.org, Anthony PERARD MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: I am not organized X-purgate-ID: tlsNG-c201ff/1789837067-F5EA92A1-A8B26DCB/0/0 X-purgate-type: clean X-purgate-size: 1442 Hello, I have submitted the pciutils MiniOS port to upstream (which I should probably have done 18 years ago :) https://github.com/pciutils/pciutils/pull/235 https://github.com/pciutils/pciutils/pull/236 Jan Beulich, le mer. 19 août 2026 08:40:37 +0200, a ecrit: > On 18.08.2026 23:42, Samuel Thibault wrote: > > Jürgen Groß, le mar. 18 août 2026 07:43:34 +0200, a ecrit: > >> On 17.08.26 18:37, Samuel Thibault wrote: > >>> Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit: > >> What about adding a comment to the stubdom Makefile in a separate patch, like: > >> > >> # pciutils support has been removed with commit , revert that patch > >> # in case it is needed again. > >> > >> I think this would be preferable over unused and probably bit-rotten code in > >> the repository. We can point people to pciutils through such a comment. Jürgen Groß, le mer. 19 août 2026 09:12:00 +0200, a ecrit: > On 18.08.26 23:42, Samuel Thibault wrote: > > I don't see why it would be bit-rotten, since the pciutils version in > > used is fixed, it's a library that has a quite stable API, and the pci > > xen interface is supposed to keep backward compatibility. > > Then I'd rather add it to Mini-OS (probably behind another CONFIG option) than > having it in the Xen tree. Mmm, but how? We don't really want to pull the whole pciutils build into mini-os :) With regards, Samuel From xen-devel-bounces@lists.xenproject.org Sun Sep 20 03:33:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 20 Sep 2026 03:33:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1426641.1649645 (Exim 4.92) (envelope-from ) id 1x88Ii-0005Vn-EE; Sun, 20 Sep 2026 03:33:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1426641.1649645; Sun, 20 Sep 2026 03:33:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x88Ii-0005Vf-9P; Sun, 20 Sep 2026 03:33:12 +0000 Received: by outflank-mailman (input) for mailman id 1426641; Sun, 20 Sep 2026 03:33:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x88Ih-0005VZ-03 for xen-devel@lists.xenproject.org; Sun, 20 Sep 2026 03:33:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x88Ig-00F0tH-DK for xen-devel@lists.xenproject.org; Sun, 20 Sep 2026 05:33:10 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaf53d7-bab6-0a2a0a5309dd-0a2a450caee4-16 for ; Sun, 20 Sep 2026 05:33:10 +0200 Received: from [160.101.131.9] (helo=na1pdmzitismtp02.tibco.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaf53f5-f479-0a2a450c0019-a0658309e718-3 for ; Sun, 20 Sep 2026 05:33:10 +0200 Received: from xenrt10716048 (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTP id 8188383DA34E; Sat, 19 Sep 2026 23:30:57 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Lin Liu To: xen-devel@lists.xenproject.org Cc: Lin Liu , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH] x86/nSVM: Don't clear TLB_CONTROL on #VMEXIT Date: Sun, 20 Sep 2026 03:33:06 +0000 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1789875190-77AD4A5B-42AF16B1/0/0 X-purgate-type: clean X-purgate-size: 1119 nsvm_vmcb_prepare4vmexit() zeroes TLB_CONTROL in the L1-provided VMCB. That VMCB is mapped writable, so the store lands in L1's memory and L1 sees a field it wrote come back as 0. APM vol 2 rev 3.45 15.16.1 (p.550): "The VMRUN instruction reads, but does not change, the value of the TLB_CONTROL field." Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") Assisted-by: Claude:claude-opus-5 Signed-off-by: Lin Liu --- xen/arch/x86/hvm/svm/nestedsvm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index a8b15d6eae..1ac2e57b3b 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -991,9 +991,6 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* ASID */ /* vmcb_set_asid(ns_vmcb, vmcb_get_asid(n2vmcb)); */ - /* TLB control */ - ns_vmcb->tlb_control = 0; - /* Virtual Interrupts */ ns_vmcb->_vintr = n2vmcb->_vintr; if ( !svm->ns_hostflags.fields.vintrmask ) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Sep 20 18:58:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 20 Sep 2026 18:58:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1426948.1649654 (Exim 4.92) (envelope-from ) id 1x8Mjg-0006C8-7T; Sun, 20 Sep 2026 18:58:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1426948.1649654; Sun, 20 Sep 2026 18:58:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Mjg-0006C0-2m; Sun, 20 Sep 2026 18:58:00 +0000 Received: by outflank-mailman (input) for mailman id 1426948; Sun, 20 Sep 2026 18:57:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Mje-0006Bu-7J for xen-devel@lists.xenproject.org; Sun, 20 Sep 2026 18:57:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Mjd-00A1Ik-Ha for xen-devel@lists.xenproject.org; Sun, 20 Sep 2026 20:57:57 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab02c64-8faa-0a2a0a5109dd-0a2a450592c2-44 for ; Sun, 20 Sep 2026 20:57:57 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab02cb4-4cb1-0a2a45050019-b9ff1c229669-3 for ; Sun, 20 Sep 2026 20:57:56 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c02e920400072c4.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 20 Sep 2026 18:57:52 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id C02B88122C; Sun, 20 Sep 2026 20:57:50 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=CfY+Qr7ruLH0DzTt08bPMhcwcpLiIiRaaixLr8qwoNQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=l2PYwBMXe8iw8tuHijUx0G37E1Uy280eb95O4EEZWv+ipRGzzVfF55mgJ+sycibJTdx4K8FSg MfcNAWQrQdopo/FoqyfbMUMPFIkPsihX7TRjdNZNTuIjjJQHagq2zImJbymf6ZvbGnhN5toNQF2 VzJYrInFiFhzSXStCeusj6af56K7XZW/vn/jhVHa2/YkNbsMHfUYYeSDYThBqgpgwZK1Tr1ImtV KDOmAW6XV8o/t9JGLca4KNKFOfdTE6zAFA3XEwV4oj78KwXQBmgqBce8v5hjhIvCVD2Iij6jzjU 6RJJVQa4/2lmGAUiStizjEYYNsyB7m9YMey4f7Sbx2Lg== X-Zone-Loop: 6b0b6f668fcbbc9a9c72f49ef5bd0bcb2909d740d1f8 x-campaign-type: default x-transaction-id: bfe6d20b-be3c-4996-aff0-7c4680007fe5 x-swg-uid: 01-f9093745-2215-44be-938c-2ee94e09f04f X-Mailer: Sweego Message-ID: <1789930672.8631fc262581453bbf619ec5b2062170.1a0c02e920400072c4@vates.tech> x-swg-bid: 1789930672.8631fc262581453bbf619ec5b2062170.1a0c02e920400072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Sun, 20 Sep 2026 20:57:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Don't clear TLB_CONTROL on #VMEXIT To: Lin Liu , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk References: Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------cWwYWl0VZV0KrmeAEOC7nfEB" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789930670934 X-purgate-ID: tlsNG-c201ff/1789930677-F64B42A1-8AD231DB/0/0 X-purgate-type: clean X-purgate-size: 6288 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------cWwYWl0VZV0KrmeAEOC7nfEB Content-Type: multipart/mixed; boundary="------------MugX0LNgEVw04fn9RsC7Ai9I"; protected-headers="v1"; hp="clear" Message-ID: <25b0a9d2-b94b-4571-8842-0c7b5c0499de@vates.tech> Date: Sun, 20 Sep 2026 20:57:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Don't clear TLB_CONTROL on #VMEXIT To: Lin Liu , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk References: Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: --------------MugX0LNgEVw04fn9RsC7Ai9I Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjAvMDkvMjAyNiDDoCAwNTozNywgTGluIExpdSBhIMOpY3JpdMKgOg0KPiBuc3ZtX3Zt Y2JfcHJlcGFyZTR2bWV4aXQoKSB6ZXJvZXMgVExCX0NPTlRST0wgaW4gdGhlIEwxLXByb3Zp ZGVkIFZNQ0IuDQo+IFRoYXQgVk1DQiBpcyBtYXBwZWQgd3JpdGFibGUsIHNvIHRoZSBzdG9y ZSBsYW5kcyBpbiBMMSdzIG1lbW9yeSBhbmQgTDENCj4gc2VlcyBhIGZpZWxkIGl0IHdyb3Rl IGNvbWUgYmFjayBhcyAwLg0KPiANCj4gQVBNIHZvbCAyIHJldiAzLjQ1IDE1LjE2LjEgKHAu NTUwKTogIlRoZSBWTVJVTiBpbnN0cnVjdGlvbiByZWFkcywgYnV0DQo+IGRvZXMgbm90IGNo YW5nZSwgdGhlIHZhbHVlIG9mIHRoZSBUTEJfQ09OVFJPTCBmaWVsZC4iDQo+IA0KPiBGaXhl czogOWE3NzllNGZjMTYxICgiSW1wbGVtZW50IFNWTSBzcGVjaWZpYyBwYXJ0IGZvciBOZXN0 ZWQgVmlydHVhbGl6YXRpb24iKQ0KPiBBc3Npc3RlZC1ieTogQ2xhdWRlOmNsYXVkZS1vcHVz LTUNCj4gU2lnbmVkLW9mZi1ieTogTGluIExpdSA8bGluLmxpdTAxQGNpdHJpeC5jb20+DQo+ IC0tLQ0KPiAgIHhlbi9hcmNoL3g4Ni9odm0vc3ZtL25lc3RlZHN2bS5jIHwgMyAtLS0NCj4g ICAxIGZpbGUgY2hhbmdlZCwgMyBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS94 ZW4vYXJjaC94ODYvaHZtL3N2bS9uZXN0ZWRzdm0uYyBiL3hlbi9hcmNoL3g4Ni9odm0vc3Zt L25lc3RlZHN2bS5jDQo+IGluZGV4IGE4YjE1ZDZlYWUuLjFhYzJlNTdiM2IgMTAwNjQ0DQo+ IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL25lc3RlZHN2bS5jDQo+ICsrKyBiL3hlbi9h cmNoL3g4Ni9odm0vc3ZtL25lc3RlZHN2bS5jDQo+IEBAIC05OTEsOSArOTkxLDYgQEAgbnN2 bV92bWNiX3ByZXBhcmU0dm1leGl0KHN0cnVjdCB2Y3B1ICp2LCBzdHJ1Y3QgY3B1X3VzZXJf cmVncyAqcmVncykNCj4gICAgICAgLyogQVNJRCAqLw0KPiAgICAgICAvKiB2bWNiX3NldF9h c2lkKG5zX3ZtY2IsIHZtY2JfZ2V0X2FzaWQobjJ2bWNiKSk7ICovDQo+ICAgDQo+IC0gICAg LyogVExCIGNvbnRyb2wgKi8NCj4gLSAgICBuc192bWNiLT50bGJfY29udHJvbCA9IDA7DQo+ IC0NCj4gICAgICAgLyogVmlydHVhbCBJbnRlcnJ1cHRzICovDQo+ICAgICAgIG5zX3ZtY2It Pl92aW50ciA9IG4ydm1jYi0+X3ZpbnRyOw0KPiAgICAgICBpZiAoICFzdm0tPm5zX2hvc3Rm bGFncy5maWVsZHMudmludHJtYXNrICkNCg0KUmV2aWV3ZWQtYnk6IFRlZGR5IEFzdGllIDx0 ZWRkeS5hc3RpZUB2YXRlcy50ZWNoPg0K --------------MugX0LNgEVw04fn9RsC7Ai9I-- --------------cWwYWl0VZV0KrmeAEOC7nfEB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqwLK4FAwAAAAAACgkQZg+p0QLLz9C0 6gv9Gxu5D7v8C4T1+vu32t50YKAN63F1A3uofFRcfCBX+wPb0X43Y3IjO3RSl2sexfrneEZOeolP H4Y3TAKvw6DCDEBN1SOEtkIxzyI3AfR/CelzJbmZl5gtUNrZEbktSHS1HTaKE77EScowFaHtgVhk HD5dDSr1SIm7DXkoalIqjTFc2tXI9uswN9xKU4Pt+o0jZMx8pYpiNOhs2ChQ+c7+8uOXTFQrdHen QTex+aRgZ0/5r05Ksc01Hel3Y962+oc+vI121/cEU9AqMZb3eMCppuiij3OoY4CDKhKOgHYDiQuG ni7erL/QeofWms3FnrECdUXCMHiySmGnsn8IMCy7/A9PbVbf7c+wDLT+eQapSweGZbahjpOxo7BI i7pchiXLpNCwhAQsP9md+M22qZL36EdBar3srF4M98UWv2uq0laMQu445+a2HYy7R90zxWoWJtaj IBh4lAKcYydt5kQdurKlXzMZQ55GK1UvL0ux8C63QFdEuT/N5QsZX3VBrvGk =ulns -----END PGP SIGNATURE----- --------------cWwYWl0VZV0KrmeAEOC7nfEB-- From xen-devel-bounces@lists.xenproject.org Sun Sep 20 19:10:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 20 Sep 2026 19:10:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1426955.1649663 (Exim 4.92) (envelope-from ) id 1x8Mw4-0000cu-7v; Sun, 20 Sep 2026 19:10:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1426955.1649663; Sun, 20 Sep 2026 19:10:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Mw4-0000cn-4d; Sun, 20 Sep 2026 19:10:48 +0000 Received: by outflank-mailman (input) for mailman id 1426955; Sun, 20 Sep 2026 19:10:47 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Mw3-0000cf-2Y for xen-devel@lists.xenproject.org; Sun, 20 Sep 2026 19:10:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Mw1-0023cb-Hp for xen-devel@lists.xenproject.org; Sun, 20 Sep 2026 21:10:45 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab02f74-e002-0a2a0a5209dd-0a2a4507842e-30 for ; Sun, 20 Sep 2026 21:10:45 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab02fb4-b4ea-0a2a45070019-b9ff1c12988d-3 for ; Sun, 20 Sep 2026 21:10:45 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c03a526800072c4.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 20 Sep 2026 19:10:42 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id CE9BB82323; Sun, 20 Sep 2026 21:10:41 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=vd2emGBAA1YVEyr1TJTV6aQL+nPL02cQ9qt2KbopMns=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=CZNyWUaEUnckdkJSeGG2voVE4Ys3h0jc26HNm34kczDanc+d9maSyTDnSOr1ZqSUKKt8Nkh1W nMRY3IwBoQiAJMGR3+sgOW5+rPq1O2VazwnkLCTwZV50DcIwIMok+W9XvNNHrnIRNtfQ70rcbKA Bc5JWv5EYkg++4Qdra/aWSssmt87vTRPIYeMziCtglsaADJmHKUSyzUogsPAX8xCJioqGFhdH2o TcEIZ9GiP0sF1+8b/A+4rhfAcoUjkb9R0pGcJs57kUpGAykHRQW9R56jRv8zcX/nGYdHQ7ApIqV KC/cgsi1hvXTeJ/1nksrC3SxhrLbWhGo1Rjg7cpyx/vQ== X-Zone-Loop: 97ba5823c31eff2700d8d9b5587dffc20b84a634f22a x-campaign-type: default x-transaction-id: 2c22e0c4-f3f7-49c3-b313-7e95d2e3b159 x-swg-uid: 01-08a99b0c-a3ae-46c8-9379-c82e421f6bc8 X-Mailer: Sweego Message-ID: <1789931442.8631fc262581453bbf619ec5b2062170.1a0c03a526800072c4@vates.tech> x-swg-bid: 1789931442.8631fc262581453bbf619ec5b2062170.1a0c03a526800072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Sun, 20 Sep 2026 21:10:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] nestedsvm: Don't set VMCB(1-2)'s NP_ENABLE and N_CR3 during VMEXIT to L1 To: Ross Lagerwall , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk References: <20260918125205.374168-1-ross.lagerwall@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260918125205.374168-1-ross.lagerwall@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------800bwqfyCx0oDVZhxFjVwudK" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789931441989 X-purgate-ID: tlsNG-ef75cf/1789931445-A5EC6AE4-A8E2573B/0/0 X-purgate-type: clean X-purgate-size: 8380 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------800bwqfyCx0oDVZhxFjVwudK Content-Type: multipart/mixed; boundary="------------fzkdCnuWyFaSh1PIQ2B2crs4"; protected-headers="v1"; hp="clear" Message-ID: <957665ac-02f3-4c03-aa15-86cdadc498b8@vates.tech> Date: Sun, 20 Sep 2026 21:10:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] nestedsvm: Don't set VMCB(1-2)'s NP_ENABLE and N_CR3 during VMEXIT to L1 To: Ross Lagerwall , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk References: <20260918125205.374168-1-ross.lagerwall@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <20260918125205.374168-1-ross.lagerwall@citrix.com> --------------fzkdCnuWyFaSh1PIQ2B2crs4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTgvMDkvMjAyNiDDoCAxNDo1NCwgUm9zcyBMYWdlcndhbGwgYSDDqWNyaXTCoDoNCj4g QXMgcGVyIHRoZSBWTVJVTiBwc2V1ZG9jb2RlIGluIEFQTSBWb2wgMyAzLjM4LCB0aGUgVk1D QidzIE5QX0VOQUJMRSBhbmQNCj4gTl9DUjMgZmllbGRzIGFyZSBub3Qgc2V0IGR1cmluZyBh IFZNRVhJVCBzbyBkb24ndCBkbyB0aGlzIHdoZW4gdXBkYXRpbmcNCj4gVk1DQigxLTIpLiBB dCB0aGUgc2FtZSB0aW1lLCBjbGVhbnVwIHRoZSBzb21ld2hhdCBib2d1cyBhbmQgaXJyZWxl dmFudA0KPiBjb21tZW50cy4gTm90IGNsZWFyaW5nIE5fQ1IzIGRvZXMgbm90IGludHJvZHVj ZSBhIHNlY3VyaXR5IGhvbGUgYXMNCj4gc3RhdGVkIHNpbmNlIEwxIGNhbiBzZXQgaXQgcmVn YXJkbGVzcyBhbmQgaXQgaXMgbmV2ZXIgdXNlZCBkaXJlY3RseSB3aGVuDQo+IHJ1bm5pbmcg TDIuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBSb3NzIExhZ2Vyd2FsbCA8cm9zcy5sYWdlcndh bGxAY2l0cml4LmNvbT4NCj4gLS0tDQo+ICAgeGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVk c3ZtLmMgfCAzMiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgIDEgZmls ZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMzEgZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZm IC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMgYi94ZW4vYXJjaC94 ODYvaHZtL3N2bS9uZXN0ZWRzdm0uYw0KPiBpbmRleCBhOGIxNWQ2ZWFlMDUuLmM2MmZjYTU3 MWQ3NSAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMN Cj4gKysrIGIveGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMNCj4gQEAgLTEwMjMs MzcgKzEwMjMsNiBAQCBuc3ZtX3ZtY2JfcHJlcGFyZTR2bWV4aXQoc3RydWN0IHZjcHUgKnYs IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPiAgIA0KPiAgICAgICBuc192bWNiLT5l dmVudF9pbmoucmF3ID0gMDsNCj4gICANCj4gLSAgICAvKiBOZXN0ZWQgcGFnaW5nIG1vZGUg Ki8NCj4gLSAgICBpZiAoIG5lc3RlZGh2bV9wYWdpbmdfbW9kZV9oYXAodikgKQ0KPiAtICAg IHsNCj4gLSAgICAgICAgLyogaG9zdCBuZXN0ZWQgcGFnaW5nICsgZ3Vlc3QgbmVzdGVkIHBh Z2luZy4gKi8NCj4gLSAgICAgICAgdm1jYl9zZXRfbnAobnNfdm1jYiwgdm1jYl9nZXRfbnAo bjJ2bWNiKSk7DQo+IC0gICAgICAgIG5zX3ZtY2ItPl9jcjMgPSBuMnZtY2ItPl9jcjM7DQo+ IC0gICAgICAgIC8qIFRoZSB2bWNiLT5oX2NyMyBpcyB0aGUgc2hhZG93ZWQgaF9jcjMuIFRo ZSBvcmlnaW5hbA0KPiAtICAgICAgICAgKiB1bnNoYWRvd2VkIGd1ZXN0IGhfY3IzIGlzIGtl cHQgaW4gbnNfdm1jYi0+aF9jcjMsDQo+IC0gICAgICAgICAqIGhlbmNlIHdlIGtlZXAgdGhl IG5zX3ZtY2ItPmhfY3IzIHZhbHVlLiAqLw0KPiAtICAgIH0NCj4gLSAgICBlbHNlIGlmICgg cGFnaW5nX21vZGVfaGFwKHYtPmRvbWFpbikgKQ0KPiAtICAgIHsNCj4gLSAgICAgICAgLyog aG9zdCBuZXN0ZWQgcGFnaW5nICsgZ3Vlc3Qgc2hhZG93IHBhZ2luZy4gKi8NCj4gLSAgICAg ICAgdm1jYl9zZXRfbnAobnNfdm1jYiwgZmFsc2UpOw0KPiAtICAgICAgICAvKiBUaHJvdyBo X2NyMyBhd2F5LiBHdWVzdCBpcyBub3QgYWxsb3dlZCB0byBzZXQgaXQgb3INCj4gLSAgICAg ICAgICogaXQgY2FuIGJyZWFrIG91dCwgb3RoZXJ3aXNlIChzZWN1cml0eSBob2xlISkgKi8N Cj4gLSAgICAgICAgbnNfdm1jYi0+X2hfY3IzID0gMHgwOw0KPiAtICAgICAgICAvKiBTdG9w IGludGVyY2VwdGluZyAjUEYgKGFscmVhZHkgZG9uZSBhYm92ZQ0KPiAtICAgICAgICAgKiBi eSByZXN0b3JpbmcgY2FjaGVkIGludGVyY2VwdHMpLiAqLw0KPiAtICAgICAgICBuc192bWNi LT5fY3IzID0gbjJ2bWNiLT5fY3IzOw0KPiAtICAgIH0NCj4gLSAgICBlbHNlDQo+IC0gICAg ew0KPiAtICAgICAgICAvKiBob3N0IHNoYWRvdyBwYWdpbmcgKyBndWVzdCBzaGFkb3cgcGFn aW5nLiAqLw0KPiAtICAgICAgICB2bWNiX3NldF9ucChuc192bWNiLCBmYWxzZSk7DQo+IC0g ICAgICAgIG5zX3ZtY2ItPl9oX2NyMyA9IDB4MDsNCj4gLSAgICAgICAgLyogVGhlIHZtY2It Pl9jcjMgaXMgdGhlIHNoYWRvd2VkIGNyMy4gVGhlIG9yaWdpbmFsDQo+IC0gICAgICAgICAq IHVuc2hhZG93ZWQgZ3Vlc3QgY3IzIGlzIGtlcHQgaW4gbnNfdm1jYi0+X2NyMywNCj4gLSAg ICAgICAgICogaGVuY2Ugd2Uga2VlcCB0aGUgbnNfdm1jYi0+X2NyMyB2YWx1ZS4gKi8NCj4g LSAgICB9DQo+IC0+ICAgICAgIC8qIExCUiB2aXJ0dWFsaXphdGlvbiAtIGtlZXAgbGJyIGNv bnRyb2wgYXMgaXMgKi8NCj4gICANCj4gICAgICAgLyogTmV4dFJJUCAqLw0KPiBAQCAtMTA4 Myw2ICsxMDUyLDcgQEAgbnN2bV92bWNiX3ByZXBhcmU0dm1leGl0KHN0cnVjdCB2Y3B1ICp2 LCBzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCj4gICANCj4gICAgICAgLyogQ1JuICov DQo+ICAgICAgIG5zX3ZtY2ItPl9jcjQgPSBuMnZtY2ItPl9jcjQ7DQo+ICsgICAgbnNfdm1j Yi0+X2NyMyA9IG4ydm1jYi0+X2NyMzsNCj4gICAgICAgbnNfdm1jYi0+X2NyMCA9IG4ydm1j Yi0+X2NyMDsNCj4gICANCg0KSSB3b3VsZCBzdWdnZXN0IHRvIGdyb3VwIGFsbCB0aGUgQ1Ju ICh0aGUgQ1IyIHBhcnQgaXMgY3VycmVudGx5IA0Kc2VwYXJhdGVkKS4gVGhhdCBjYW4gYmUg ZG9uZSBzZXBhcmF0ZWx5Lg0KDQo+ICAgICAgIC8qIERSbiAqLw0KDQpSZXZpZXdlZC1ieTog VGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+DQoNClRlZGR5DQo= --------------fzkdCnuWyFaSh1PIQ2B2crs4-- --------------800bwqfyCx0oDVZhxFjVwudK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqwL7EFAwAAAAAACgkQZg+p0QLLz9Bj mAv/eoG2vrcIjYpbJKOWKa40Lb8Ziu59BK/kHYuZ3UxjwyE6JnZO4Hc+lF1gr5aQxjHuSP97OWfr 3Tsz5vDW7DgJbo41sdr1sXirRwn8HNBe246ppXM2YFnRueLHae8JeY2opBFK5bHY4j6gMA9bOHK6 fq8mDWxfohoEvuKpDl5CdVeXUHlHY9tylx9pTu+kpwX3rdxtaRh+akh9Dq91fvNFYl7DxEBi39U1 yIgoxI+YQlS2MsXZb/DHhhvm3DgbiC49poVgjFPRZgbEHR3eS6pITLT5VKR0yBfh2D8XDpUBCRBr W81kOK+KsAWuf3zbPy3AGBaptEodA7XJuDpeh5HKYImuZgy14V1bg+dKyKbi3VpkrsDJoDRafGQH H92HtasmEew8hLedfnajd0JvrFy7IfqxsWDkKAik8u3XbYT6NQRepvJdW+aEdyt4cHbjKkH5cLHi hertE6UoZvCES2Xqzi849dVYBUvQBaA8gdJMYVn/ALVSMJpxzzw6Z7PHCLtU =cdgH -----END PGP SIGNATURE----- --------------800bwqfyCx0oDVZhxFjVwudK-- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 02:28:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 02:28:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427029.1649680 (Exim 4.92) (envelope-from ) id 1x8Tlm-000892-LG; Mon, 21 Sep 2026 02:28:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427029.1649680; Mon, 21 Sep 2026 02:28:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Tlm-00088v-IT; Mon, 21 Sep 2026 02:28:38 +0000 Received: by outflank-mailman (input) for mailman id 1427029; Mon, 21 Sep 2026 02:28:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Tlk-00088f-TF for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 02:28:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Tlk-00H6CK-AN for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 04:28:36 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab095e9-2eae-0a2a0a5409dd-0a2a4509e752-34 for ; Mon, 21 Sep 2026 04:28:35 +0200 Received: from [52.101.201.36] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab09652-be1a-0a2a45090019-3465c924c330-3 for ; Mon, 21 Sep 2026 04:28:35 +0200 Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DM4PR12MB7719.namprd12.prod.outlook.com (2603:10b6:8:101::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 02:28:20 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%6]) with mapi id 15.21.0428.014; Mon, 21 Sep 2026 02:28:20 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RRFY7uye0kx9GQjjkISBpRHpDPL29B8yQ8lXNXezss2d2gGhkyEutGGa453W1maOcE5lOC0c87pJYQSpAovCTeVp79gCbcGzIb1UsGjMcEkg6D7MwCpdDlVlVV64xw/2hfSWrKZ+SSEKkb92rUy2RuT1uPDh0D26tF1YqL0Ii6SAoNeZbcf6UGGOB8Cjxc7LkJ46mn16Qo2DbtAaHvqdi200cHvnlPNSPKi1AQ9JNz/U9PCYDi6j9gB2V2wfxR78nSAq7MrEsu7e20E+bbhKT0llTFJRt22gtee/mIbq4YYaUQwPmTQjBgkQQZBvXGPy8J/wMOTso6+IukkamcdsZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CTl7/MYdyvkpIqnqDSwOLFKKPNvDoeCHW7e7oy+63k0=; b=C4tE/dxsYHZQAyzC2DHfdVYqYy6Byc+yhITkYPh+yeVAmZJldjQuSs1hcIMiS9tHypL7L7UsSL5kASM8SXhAAa6ZXtRXCRE6wssr8zCstro7lTgF+RYkma/KGDucTovMozlA1dD3O/L7ZTqandjqyjNP/AWQbqxiEDj6Havc3M7kDYSNdgLyW0Bp7UA+UbK7zLx7xNqT+CNh4IgyQx4jUCdUTRp/MneciXqrB7gt9ucSbri5bbULTtdf2w1tV9i2dHX5+zqsasXbq9olvlUVQBDSogo4z+v2r8TR8Zmk024RYV0RjwxIotJoU1ipBUV4/1wPuYECVSZkDv4hmEIfBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CTl7/MYdyvkpIqnqDSwOLFKKPNvDoeCHW7e7oy+63k0=; b=fEXTqQxIw31L8b/z2am/tbWCoSGLWor9huaABv/x7xO/ux5Vo7KYzrKY0kLSbPSsVlIWvou7Cidj/Ich23k2IsLy0eViq/qPUwVYgWStZgMSFCf5K2OeSVfKb/zUn1YeuUql3/xMHIwHA+2U4sUTKe43+NwjTxEfNPKqY1TxKW4++6qxXGCXv2ORuACN4FESbTm7chTOCAB1KQTHvtIyYdapyNsELsFXg3k6KBHYTJ6misbEwJSVUf0IfSbN1YgJAIXjww+rlfKmtfdqE7nqZHyBhhEua/pP4J85O6YSeSRsIRKSXo+2XC0Hg7/qsOXLAtaDI/t4eXjNVE9C0LJoCA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; From: Zi Yan Subject: [PATCH v5 00/17] Remove PG_private by using page/folio->private checks instead Date: Sun, 20 Sep 2026 22:27:56 -0400 Message-Id: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-B4-Tracking: v=1; b=H4sIAAAAAAAC/23OzWrDMAzA8VcpPs/Dlr932nuUUjxHbnVoEpxiW krevU4YdKM5/gX6SQ82YSGc2NfuwQpWmmjoW5iPHUvn2J+QU9eagQArHHhe8DJU5OPpOBaq8Yo 8ZQxgk8teJdb2xoKZbqu5P7Q+03Qdyn09UeUy/dWU3NCq5IJLDSm4n6iMhe++UkfxMw0XtnAVX oTfJqARylovTUhdQP9GqBcRhNsiVCNsRIAcugDu/Qv9h5Bqi9CN8NobI7IzTuM/Yp7nJ2Wbryl 8AQAA X-Change-ID: 20260728-remove-pg_private-cfe926c7f83c To: David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zi Yan , Minchan Kim , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, Oscar Salvador , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Tal Zussman , Gao Xiang , Jan Kara , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-trace-kernel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , ceph-devel@vger.kernel.org, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org, Baoquan He , Pasha Tatashin , Pratyush Yadav , Jonathan Corbet , Dave Young , Shuah Khan , kexec@lists.infradead.org, linux-doc@vger.kernel.org X-Mailer: b4 0.16.0 X-ClientProxiedBy: YQZPR01CA0096.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:84::29) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DM4PR12MB7719:EE_ X-MS-Office365-Filtering-Correlation-Id: cd7bc866-ada1-4775-a366-08df1788007e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|23010399003|366016|921020|3023799007|6133799003|10067099003|56012099006|5023799004|11063799006|18002099003; X-Microsoft-Antispam-Message-Info: jVeqbV/tHFeiMu+SHY69AVMUwlHgvJsFntwh78c0mOcyBYkE8gAjYMbep7rFh8vHMGgr8l7yUZE0wDAJUPHvuknsIrb4O+8a8CBU5khXkWuMT+npJhPIuSRVZKqAXkS6AUfSBuwwxl7f3QNiNU+g4Qk/Qz5PmSRNx55YKYEiDYSb55PzugiK3ZDls1OYDO3v7MpXnErGtt8oYnSGtUru5y3fimvQH+lf0rZLZm2+oXMLQNsu83LlHdG99VtP6Njhe6MJbXuqX8q5F1rD/jCXNX2wYn8PLKDDdgZykqjyL1BvD6H14oNNo+G/QudzvRY77JbHnOJfhGWnIp1dSLfxa+OjBX1b80BYxzKQd0bAchUIwnQFMIHAezbWzJ08R1jRMcq/11N0FReMEhWF1GPfKuMEh04duME2n6TloQln/Qc99yjLw0DDTr0X5vL3NJ+tlN/aSUtrzclqW5fsIDUHFOW6X4ryYk8GRDzm3ohrdzu2gWRCEg90EEJqKp6rzqFAuUndZvP/69JkVVw0lhJSQaPElhG/kpxVTut8iWtLi3QBhQpc2G+2oWMnQmTrxW20F4aQlX5gRFsRrHp4w+zciUct2j0VVdvsbZ8trJDLj+mGNgdE1I25ddAnyDjmbr8eeckeeGIqtfjL1uI3WeoeM99Xa9VuytHz5wAtj5HVOXJq3cDZ4gqbt9qr5aDkOV+74+B9ckF4Zxx/OgvbcR51ZA== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(23010399003)(366016)(921020)(3023799007)(6133799003)(10067099003)(56012099006)(5023799004)(11063799006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eWpRa1g4TTBZTnQ2bnRZS3h1WFA4c1gzWm4xSFB3Z3JNZFZJcGk1cm5aVGF0?= =?utf-8?B?dnhIY3hJdDBSaWxZTnVHR3BrTGRGUGZScHI3MVFrbTcxbEJ6d3dBN3NRcy9T?= =?utf-8?B?RlZ6STN1Yi9VMnlOSTJodjA3M0dqK0Z3TG5KNnI0M2VNUGh4NVU1SFk3Vmk5?= =?utf-8?B?ekZmTXpEUnZveFdHdFpMMkRmdjBtT3JNV2l6L29NUmdYZjFHZWpSMVE0V2ln?= =?utf-8?B?bDNWZktoRjZEbGRtUHBxSmp3OGdZc2hBeFVvUyt6ajVQMkE2OXNqbHFJS2Vu?= =?utf-8?B?ekduYlJVZkI0ek44NXdvMW5KUW55aXdRR0JPd3lPeE53Y0ZuZjJOb2VkMTYx?= =?utf-8?B?c1cvSHh0S3RCNWxQT3J5cTJBazg2WVc3dUdXeUxkQ0FnMHZhM3ppdWY5TFhl?= =?utf-8?B?djhIcHdTNlFtZEswcHZCUkZyKzlwMVRjS1VkejhESlZFa1U0d1hmVXFzcDZw?= =?utf-8?B?V0VUcktpRmNCZTNWaXNuR0dQVTNueThqQzFidFJxOTA2YU5hOTdoYmZGNllx?= =?utf-8?B?eUl0K1RLU2V2QmZzWnErVk8vSmhOYkVFQk9YRFdwdXJ1WWNxQk9vc3NWTE9B?= =?utf-8?B?TEdYdUNQUHRUS1crNjA0T2hJUUtySSsya3czK2dDbUJGMTNPbDJyWEVYNk5q?= =?utf-8?B?K3Azc2hTWUNKdnNIalZiMjdhVzJ0OThLWkg4ckU2ZkRnTzFzUjdKRGZSRXpr?= =?utf-8?B?cGl1dGo0bTRqRzdQSldDQWM0bnpXdWxqNG9rdDh2TklqR0VaelNVYkVPTkVB?= =?utf-8?B?YzhBN3ljUFkzeUxvOUloZndyNjY5Z3FSL0FDeHIreXBsZWplL1I5TmhQREw5?= =?utf-8?B?dm1TTm9wdldrc1ZIK2RUWHJVZnEvbjlPMTVKSGhoSXdLc0tPK0pjSnJmWHY1?= =?utf-8?B?NStheFlWUExNS3RLLzAvYmhSVmk2S3V0bS94Q2ZySlJtYUYxQlkrZkRhU0Zh?= =?utf-8?B?YjdnQkZua05CS29Ua2pxUWUzNjRuRHltQnhRWVIxVFBQN0pDSWhSOWZuNDhE?= =?utf-8?B?M21oR0ZLL2ZSaUdnWThwb3NtQmtrZmc1dkpSMmxPMU05VWppWlJYVFZUVHlz?= =?utf-8?B?MW50Qm5TVE1zbElPMWVURFhNdG5VbjVzdnNvZW1wTE85Sm4raEh6ZW4rVFBC?= =?utf-8?B?RExVc0s0M2R3QkNMK2J0Z2RxM1NVMW5OU05XS3h1M09YQlZWMTNqMFZTVXM4?= =?utf-8?B?dVJjdUdvR1Ird3lBekVGd1ZWVndnWEFNbTU3ME50dzh0L0l4WUhDb2tVcmUx?= =?utf-8?B?aTJiNG9pS3NhN0xJU2hxMU1xSEFYNDA0UVpCSy9nSFhuV3RaZkxpcmdFZ2x0?= =?utf-8?B?Z205cTB0WG5USUdJeGJHOEF0R3hJay9aZUVnVUhCc1JudVFGL0g1alFyeG9C?= =?utf-8?B?UHUybldqS3BvRGx6MDc0bnpwS1VOYkNmRnVEdE1qQ2l0Mm9NODBqdVV1UEtZ?= =?utf-8?B?Zm9pZWF6K2hSVFg3M0l4K3FDNko3Sy9vQ3UwdWNad3ZyQ1FOeHpGNlc5aytt?= =?utf-8?B?cXZRQUl2T0xUTkRoWno1TFZZV3NDMXZEWk9uNk1Nc1VYM2VBNEprVVd3cTkz?= =?utf-8?B?S3lrTkZLRjJDNWpqdWtENkcrN3pMbjV0RUt5UlVodzRFZGtRWkhTdndBMncx?= =?utf-8?B?Zk5Wd2d4NTdTb3BNaDNlSndvV1RaUXM1QXB4SGNVKzlWRVBEYlRaRk5idmRr?= =?utf-8?B?UTM3cDJsQlMxczBjaW90R29ickJTME02UXRDME0yM0NBMGV0cVB2c3BHVEVQ?= =?utf-8?B?RktwK1MyT3kzMXlzbStCazF5YTJCMitHbWRra2ErWXRXYmE3aGU3bFRGSnZW?= =?utf-8?B?VkhqUXhjZ0NaQU0zUjFJNHBiTWMxUUR1cmxBN1BwZFp4RGNYRlFpTjJSTlZn?= =?utf-8?B?dGRDdGR3OHpiem1nbGl6cHdlWWtGdlZ2Vnp3aG04bUJBNFd3c2l1Rlh5MG54?= =?utf-8?B?dGM0NW9MbFhucmFOMG1FSmVxQXh2MG5SM0xQNnc0MklWMFgzQ1V2NTF2a3h1?= =?utf-8?B?OGRvcCtxcWRVcTdwMVlzWW94aGhsd0dMVFZZaWhQejRjeGdMZ1hyOG5wTGJ4?= =?utf-8?B?cFRlQm9UTlp1ZU44MW9kVWNoSnh0TlpsZ2gwaWNFRG5DMG9xMVVOTWtuOUZv?= =?utf-8?B?RDZVSHZaaWtaZmpNTzI3Z0h4OWlGd3o4YmxmRFhlT0U2YmRxaEVEaGNZWU1u?= =?utf-8?B?UUdoUWw3dUg3TVZLS3p2VTZmUEZZTU5JZnRPWXR5VW5QMzkwKzZlRUFUVU0y?= =?utf-8?B?TE9xTFllTWRMTjFwRWxKd2tmU1hUaXlRSHJTbjRuOGdSclhTa284U28vQ1FT?= =?utf-8?Q?F1TFjtIkGgWhFLH9mx?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd7bc866-ada1-4775-a366-08df1788007e X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 02:28:20.2879 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vyBX7Kyzqii8eJcu8TMIvK1/ygKw2l6cNqXR5BHUUQfr5ne4lK/kybDBlk0qcMdP X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7719 X-purgate-ID: tlsNG-bad1c0/1789957715-BE4DB034-6FCEA7CB/0/0 X-purgate-type: clean X-purgate-size: 12707 Hi all, This patchset removes PG_private to make space for upcoming PG_folio for identifying pages from a folio (more details in Note below). Instead of checking PG_private, all code is changed to check page/folio->private != NULL instead. MM people are cc'd on all patches and subsystem people are cc'd on the cover letter and corresponding patches. This patchset is on top of commit ef0ea92854987 ("mm: zswap: return -ENOENT when the swap device is gone") from mm-new, which is the same base as V4 of this patchset and no conflict is found during the rebase. I also tried to cherry pick the remaining patches from mm-everything on top of this patchset and find no conflict. Patch 10 and Patch 13 are the only two patches without any Ack or Rb tag. Overview === Most code uses folio_attach/detach/change_private() functions, so folio refcount is increased and decreased when folio->private is set and reset, respectively. There is no need to change them. Changes are needed for exceptional users: 1. zsmalloc uses PG_private to indicate first component zpdesc page and page->private is used to store zspage in zpdesc. To remove PG_private, is_first_zpdesc() is replaced by pointer comparison. 2. kernel/events/ring_buffer.c stores page order in page->private. Replacing PG_private with page->private != NULL works. 3. drivers/xen/grant-table.c stores xen_page_foreign in page->private, where on 32-bit, a pointer to xen_page_foreign is stored; on 64-bit, page->private is used as xen_page_foreign. PG_private check is replaced by page->private != NULL on 32-bit for xen_page_foreign deallocation. On 64-bit, page->private is cleared unconditionally since {domid=0, gref=0} (xen_page_foreign can be 0) is valid. 4. fs/crypto/crypto.c stores a folio pointer in page->private, PG_private checks are replaced by page->private != NULL. 5. fs/erofs has two different uses: 5a. folio->private is used to form a reversed list of the outputs of readahead_folio(). readahead_folio_last() is added to output folios in reversed order, so that ->private is no longer needed. 5b. folio->private is used as an in-flight I/O counter. Convert the code to use folio_attach/detach/get_private() and add bias==1 to the counter to avoid folio->private being zero. 6. fs/nfs/write.c: folio refcount maintenance is in a bigger scope than folio->private. So folio_attach/detach/get_private() is not used. Nothing to change. 7. fs/f2fs uses attach_page_private() to first reset folio->private then immediately sets PAGE_PRIVATE_NOT_POINTER bit on it. Change it to use attach_page_private() to set PAGE_PRIVATE_NOT_POINTER bit directly to avoid folio->private == NULL gap inside set_page_private_##name(). 8. hugetlb uses folio_change_private(folio, NULL) without folio refcount maintenance. Change it to folio->private = NULL. After the above changes, PG_private ops are converted to page/folio->private ops. folio_has_attached_private() is added to check filesystem-only private data by excluding swapcache and hugetlb folios, because swapcache folios overlap swp_entry_t swap with ->private and hugetlb sets its own flags in ->private. Note === 1. KPF_PRIVATE is removed after PG_private is removed. 2. Documentation/mm/hugetlbfs_reserv.rst is outdated, so I did not remove PG_private related text. It should be rewritten. 3. PG_folio is planned to be set on every page from a folio in page_rmappable_folio(), so folios with any order (currently PG_large_rmappable is used to identify >0 order folios, but not order-0 folios) can be identified. Then vm_insert_*() can correctly reject all folios and rmap code will only see folios. Eventually, page_folio() will return NULL for non-folio pages by checking PG_folio, but before that all existing users that treat compound pages as folios will need to be converted. Tests === 1. allmodconfig build passed. 2. zsmalloc is tested using ext4 on a 1GB lz4 zram: 2a. zram load + zsmalloc compaction; 2b. concurrent zspage migration via memory compaction; 2c. confirmed that multi-page zspages actually formed. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_zsmalloc.md 3. erofs is tested on images created with -C4096 and lz4hc, lzma, deflate, and zstd algorithms: 3a. cold read of all files, verify checksums match source; 3b. readahead + reclaim/migration race. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_erofs.md 4. fscrypt is tested on software-encrypted ext4 with writes to exercise bounce pages. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_fscrypt.md 5. f2fs is tested on an image with inline_data,compress_algorithm=lz4: 5a. INLINE_INODE — lots of tiny files; 5b. REF_RESOURCE + general writeback — buffered write churn with fsync; 5c. ONGOING_MIGRATION — force GC / page migration; 5d. ATOMIC_WRITE — atomic-write ioctl path. Details: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/test_f2fs.md (I did not run xfstests) 6. MM selftests passed. LLM use === Claude was used to form a concrete plan on what code needs to be changed and how to change them. The plan was reviewed by Codex until no issue was spotted. Plan is at: https://github.com/x-y-z/linux-dev/blob/b4/remove-pg_private/plan.md I then followed the plan to make code changes. I did bounce ideas with Claude how to change fs/erofs, since I did not like the original idea. After each change, I asked Claude to review my code and git commit message. I also asked Claude to give me test plans (see above). At last, Codex was used to review all patches. Comments and suggestions are welcome. Thanks. Assisted-by: LLM Signed-off-by: Zi Yan --- Changes in v5: 1. replaced md patches (patch 13 and 14 in v4) with Matthew Wilcox's version (see Matthew's replies to v4). 2. used data_race() inside folio_test_private() and PagePrivate(), so that the new versions can be used without KCSAN warnings while not holding folio lock like before. 3. moved folio_has_attached_private() implementation detail comment next to the code. - Link to v4: https://patch.msgid.link/20260913-remove-pg_private-v4-0-848550f7574e@nvidia.com Changes in v4: 1. dropped set_page_private(0) in balloon_retrieve(), since page->private is cleared at that point. 2. simplified the comment in add_hugetlb_folio(). 3. additional cleanup for f2fs to remove fio->page uses and convert PAGE_PRIVATE_* flags and helper to folio-only. 4. added a comment for __readahead_advance(). 5. added core-mm split/migration interaction information on newly added folio_attach/detach_private() for erofs. 6. renamed folio_test_fs_private() to folio_has_attached_private() and merged the commit introducing folio_test_fs_private() into its prior commit. 7. adjusted the patch subject: "treewide: remove folio_set/clear_private() *usage*" 8. split "treewide: replace PagePrivate() with page_private()" into three. 9. moved some comments in "treewide: remove PagePrivate() and PG_private from comments and docs" to prior patches along with code changes. 10. used PG_folio instead of __PG_folio to avoid additional code change in __def_pageflag_names(). - Link to v3: https://patch.msgid.link/20260907-remove-pg_private-v3-0-6ae22f9d9272@nvidia.com Changes in v3: 1. changed folio_test_fs_private() to check PG_swapbacked instead of PG_swapcache for excluding swapcache folios. Because folio->private and PG_swapcache are not set as a whole, making folio_test_fs_private() give false positive, whereas PG_swapbacked is always set for swapcache folios. 2. added __DEF_PAGEFLAG_NAME() to show __PG_folio instead of open code. 3. f2fs change is picked up at https://git.kernel.org/jaegeuk/f2fs/c/5ad9409a9533, mm-new currently does not have it, so the patch is sent for MM testing purpose. - Link to v2: https://patch.msgid.link/20260831-remove-pg_private-v2-0-3668159cd9e8@nvidia.com Changes in v2: 1. removed is_first_zpdesc() in patch 1 and open coded the checks. 2. fixed wording in patch 2's commit message and clarified page_private() also works when ring buffer's AUX page order is 0. 3. removed the empty loop in 64-bit gnttab_pages_set_private(). 4. clarified folio->private will be reset to NULL by fscrypt_free_bounce_page() in the commit message. 5. clarified why hugetlb needs to restore hugetlb_vmemmap_optimized. 6. renamed readahead_folio_reverse() readahead_folio_last() and reimplemented readahead_folio_last() by adding a new readahead_control private member, _forward, and a new helper __readahead_advance(). 7. added a bias, 1, to erofs I/O counter, so that folio->private stays non NULL between folio_attach_private() and folio_detach_private(). 8. converted more call sites to use folio_test_fs_private(). - Link to v1: https://lore.kernel.org/r/20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com --- Matthew Wilcox (Oracle) (3): md: Use folio_alloc_buffers() md: Use folio APIs in free_page() md: Remove the last use of page_buffers() Zi Yan (14): mm/zsmalloc: replace PG_private with pointer comparison perf/ring_buffer: stop using PG_private as AUX page high-order marker xen/grant-table: stop setting PG_private on pages for grant mapping fscrypt: stop setting PG_private on bounce page mm/hugetlb: use direct assignment instead of folio_change_private() f2fs: stop using PG_private f2fs: convert the ->private flag helpers to folio-only erofs: mm/pagemap: add readahead_folio_last() to avoid folio->private erofs: use folio_attach/detach_private() instead of direct assignment mm/page-flags: check page/folio->private instead of PG_private treewide: remove folio_set/clear_private() usage ceph: replace PagePrivate() with page_private() treewide: remove PagePrivate() and PG_private from comments and docs mm/page-flags: remove PG_private Documentation/admin-guide/kdump/vmcoreinfo.rst | 2 +- Documentation/filesystems/vfs.rst | 6 +- arch/x86/events/intel/bts.c | 3 - arch/x86/events/intel/pt.c | 6 +- drivers/md/md-bitmap.c | 18 +++-- drivers/xen/grant-table.c | 11 ++- fs/buffer.c | 8 --- fs/ceph/addr.c | 8 +-- fs/crypto/crypto.c | 2 - fs/erofs/data.c | 16 +++-- fs/erofs/zdata.c | 13 +--- fs/f2fs/compress.c | 35 +++++---- fs/f2fs/data.c | 2 +- fs/f2fs/f2fs.h | 99 ++++++++++---------------- fs/f2fs/segment.c | 2 +- fs/nfs/file.c | 4 +- fs/nfs/write.c | 2 - fs/proc/page.c | 1 - fs/ubifs/file.c | 8 +-- include/linux/buffer_head.h | 8 +-- include/linux/kernel-page-flags.h | 1 - include/linux/mm.h | 34 +++++---- include/linux/mm_types.h | 4 +- include/linux/page-flags.h | 51 ++++++++++--- include/linux/pagemap.h | 64 ++++++++++++++--- include/trace/events/mmflags.h | 2 +- include/trace/events/pagemap.h | 2 +- kernel/events/ring_buffer.c | 7 +- kernel/vmcore_info.c | 1 - mm/huge_memory.c | 2 +- mm/hugetlb.c | 7 +- mm/migrate.c | 3 +- mm/page-writeback.c | 2 +- mm/vmscan.c | 2 +- mm/zpdesc.h | 2 +- mm/zsmalloc.c | 24 ++----- tools/mm/page-types.c | 2 - 37 files changed, 238 insertions(+), 226 deletions(-) --- base-commit: ef0ea92854987c1e61cd72e100c8b61b485955d8 change-id: 20260728-remove-pg_private-cfe926c7f83c Best regards, -- Yan, Zi From xen-devel-bounces@lists.xenproject.org Mon Sep 21 02:28:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 02:28:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427028.1649672 (Exim 4.92) (envelope-from ) id 1x8Tlj-0007wH-Cb; Mon, 21 Sep 2026 02:28:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427028.1649672; Mon, 21 Sep 2026 02:28:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Tlj-0007w7-6r; Mon, 21 Sep 2026 02:28:35 +0000 Received: by outflank-mailman (input) for mailman id 1427028; Mon, 21 Sep 2026 02:28:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Tlg-0007vi-TH for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 02:28:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Tle-00H6CK-40 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 04:28:30 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab09620-2eae-0a2a0a5409dd-0a2a4507b12a-12 for ; Mon, 21 Sep 2026 04:28:29 +0200 Received: from [52.101.57.35] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0964c-b4ea-0a2a45070019-346539233f7e-3 for ; Mon, 21 Sep 2026 04:28:29 +0200 Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DM4PR12MB7719.namprd12.prod.outlook.com (2603:10b6:8:101::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 02:28:22 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%6]) with mapi id 15.21.0428.014; Mon, 21 Sep 2026 02:28:22 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=temperror header.s=selector2 header.d=Nvidia.com header.i="@Nvidia.com" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mxfrvHFGH3yAq6mvYcNLbZ0IqZFUyPWdnkfA/522kXJR0gEeqNt/tqPpfHQS4mx000iSFdPIb44vlQh/XkiT6mdJWFd6rTwtX9PwNlsj4wk2B5QWYTRVGzpOyRXqpcfH3gb2Cgcrl2BS1GFabrbU+vgIIY64VjGT1I54kOiPijYo+nQnYbMHxEzx/ZzyPz901QrlDgsLbcwuuYGswFBMbkmV/575MCAVwLUdSHKsGvMqUSxT+NCjZR+EfMT2HuckozbttfAD5/D/boM627VlxldlHggzFbwA48BJl2SIdPHkcymTmWnPqVSaEVTHqVaVyEm1UxbjFNn/rB882YCAyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UpMC3DPaCgBSCOyBuao6sjqogivZ56QdijQSKHRf1os=; b=eu7FsLlPmwiAuNBwcBYej/R+MzZ6r9fWggo9aWrAMrVk+cltCA8IDWdtzksXWPqmlAdGTn4t68wdX362UEngkBR+82HRiMk/v9BQm+g2k/S+FNdyhJR4Za192W8fdA6iWeBnRqjusOwB3YFtc9cSOAwK8UDNODeExKpY5Z2+9FaoTZnXGmaD1k5rZFKYaLqRO23i4b/hEAOtVGNhJh3usmPQ0CUB0aZbB3JAcSJt1JHXshnfcIcSXAL0Xg05yc3BgsSSnEIAYChUYBlygLhj4wDLB9P4vJWva+Xu9N2ZQAYzAx2d52ioroE80okKmIJ51UxwLko6qwXt7kQPl+yCuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UpMC3DPaCgBSCOyBuao6sjqogivZ56QdijQSKHRf1os=; b=Z0N6nmJU0+AU3bupI5n4kRfItzpwj53epV4JQKpd5OfQF2AKZzNH5ZNE0yG+ShpAstFHZSbIzZkyiD59BcPwAObKyMGKo3YTKOrzU6aqy31V7Zxi8GBBVLX8K6YqNuMDYXzMYpgBt1JxEwAMDEWHjOtvTwj6CPJkAxXTyhtB6V4GQYdXmPwvZbOfH2k1O76jxxWqmuYWm31g390EQskXBiEaH55XTeC/TTnEG949NxFGG7e2qbGFl091RIDPSrcWz4T776y3sCU9E3/ZXmI6auFVqoBAl9TvATrB/wUc+vuOj+P9MR+nnbb1PuuF0+wPi2DzLHlIZLzxpPp1uYfbTg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; From: Zi Yan Date: Sun, 20 Sep 2026 22:27:59 -0400 Subject: [PATCH v5 03/17] xen/grant-table: stop setting PG_private on pages for grant mapping Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260920-remove-pg_private-v5-3-bb68b6a21869@nvidia.com> References: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> In-Reply-To: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> To: David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zi Yan , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org X-Mailer: b4 0.16.0 X-ClientProxiedBy: MN2PR07CA0006.namprd07.prod.outlook.com (2603:10b6:208:1a0::16) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DM4PR12MB7719:EE_ X-MS-Office365-Filtering-Correlation-Id: d3dac128-597d-4394-e183-08df178801eb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|23010399003|366016|921020|10067099003|56012099006|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 36kkqR4p5YHKuN1SERPlBIsWYUfE9RFpZ5J4etwUmJVpKUH3zsMuomA6AO3t6mKX7KbAV6Dv5xyYzTyKFgqolwMOMSU/mXU17776DcbsZ5EU++dcUjizE0KpjyORdod6p3BUPJ7Q25uheQ/XHNPxzSMg+BuI4ZgTk9TefDPFRneyBWMBfUWhwk4sygZIJhwLzHiZC1CV9s71N4KAvuiLUoz3sEg9OzTy4j36gegADSd6JhBGKCEvipvQAl/VyVymogchy7ZSaXQMth7f3ybi+L/Wv3zVuevdsdSjsLHo5C9kQugpsXystEKdMz/vaM9SQJQA485gN6CgHGBfKd/oW2r4rgMT49xN6TXtDM26TRgb1J0X+8TtfrU4R64RNCifVNREO1a4zNfv4mR7fZjPLOTvxmhwDQNxiKyg+drzMVb+H1ajTYavRyQLKJvvqjBuFpkQrSg2RrElUhIIPSIi3NdMOWxXqPt8lwFsQYn1cd6VDHeADOqGKiPdBx2//I+reHvDBOSKenoY3HMiYYY2XtFsIOzOTKoOZPMlm+FF2GVkaT6IOjKAg5bYpyzRM2z8dTy4inkt9CC/eanyRoZ5Zbw6yzHfQ/zZDsLrVgCtdNMwtvKj0pUXKOtw8fZSYscd8V19YOw1sZtilHyRMpwV0xaqzRDSoKNVeBeR3QuHJ/unHA0lLe+tarY0++miEnL7h3+sU903iB9L+yq24UhYgg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(23010399003)(366016)(921020)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a1lqYmhQVUl5ZTRqVW5FT0JmUDhjbXAyRXlUL2I2S3dBUXg0OHJjNUlmQy95?= =?utf-8?B?TUZzTmw0clBtbWVCVW40bTBnVkw0emFPWHgzUGN3WXc0b3p6ZWJoNDAyRFQy?= =?utf-8?B?V3EycTVFSXBKSWhmQ2piY1NaaHd0bERiNWJ1Y0NUSy80WnhWaWNLN3FXZ204?= =?utf-8?B?SENvcnE2T1NoL1AwUTBBRTVXekpPSnNXN2NSTDJRdWwxNjJFb0J1aXh2TFF3?= =?utf-8?B?OUlFeTYzdXIrb3BvbEN4ejJ0YnRhSThjMWlGaDVBamlGUTNqbVVHbmx1eEM3?= =?utf-8?B?bTQ0N3RkVFNpd3puT2ZCelVWN3o0S3hDSUQwRDUwWmtRcVYrbndFY1dKVGpG?= =?utf-8?B?cWtmUVhtOFhCVU1uRWVVbzh6dldMbjZ0cWlkdTFNdWNVTlAyRFltMTI2TXBD?= =?utf-8?B?RUp5Z0JhUHlzbVRnc3JVaXVUcU8xZmh1WmJ4VlFFMitlZGVCemdFb2FYRkRa?= =?utf-8?B?RGVWYWZ3aTh2c1N1b1k1YVJ5eFY0cUFFbmVvU2NKd1R5ZEZwWENmUThSaFFk?= =?utf-8?B?K1Z4bVJyOHNjR09ZN2tGRmhQcUd5Y0NMTnpzZkpKdkdFc3FjUzRYT2UweFhY?= =?utf-8?B?Tm9zMU9DZUxhRXlRYVl0UXlieVdla2tYSHhKbEdPd2xkRzJzMGhXVFpSRDFm?= =?utf-8?B?cUxPL1JDMmhMVUErSGkyWDVBQkphS3lWTzhJMUNlMWYwc1FLTEwraW9qSEF0?= =?utf-8?B?Nzl0NUx6U241VXhRcFY0YkZmWkVKcWMvTDhsVHZWRGxQOWFxS0U3K0FSVjgx?= =?utf-8?B?TzVNak5VRW1FUDVWUlRRV1d6bFZkVWJRMllqUzNVektocnNlcVhJM0dqMW95?= =?utf-8?B?SGlUQnpPRXZGbTRadTFEQWRidlkwMEpQQ25meWt5bVdtNzd4bnhzM1FKL1JF?= =?utf-8?B?SEIySjd0K3JWdE0wQXdQeGVVOExFTnd1cDVuQytmTEROa0ZNQ0s0VGpWYWZQ?= =?utf-8?B?Ry9TbzBlY0p1dlA2aXNOMDRYQUxvTGVGSm9Qc3NUZjJJUzJvRWVIQnB0TG8x?= =?utf-8?B?THdQNVNoZXkzQjRldGlJK3pKNHFoNllhRnhTcmt6WWNyMmpZR1ZBODd4WnBu?= =?utf-8?B?cklqRDBVZE4wZExFOENmZ1ZvNS85clI5QS9ETDM4RHBnd09HRklYTmVVenZa?= =?utf-8?B?WFBUMWprb3lobUkrZ0Z2c2g0Z2d2WGp0TWoxRE5WdjV3UE9rektyVFVWaDZG?= =?utf-8?B?cU9pUmsvZU5YaHUxQW5iUVZrdkg4dDN4ZWM1SzhpdWZwYUVUd1ByQXlEVHFF?= =?utf-8?B?cXViOXdvcFV6Rldnei9mVHdFaHE4QVRtZTdQS0VrZ0svV25nTVYyL2NKVFB5?= =?utf-8?B?NTNmOGkySFgybzZrcytLOUkrZFptUUxaY0dVQ0kycUh4cVpSeDJITXZJWGVM?= =?utf-8?B?dmJianlaNW92U3hqK2dKazZpRXNGOVMzaENXSkVoL3FiWWdqVWtHWnFGNis2?= =?utf-8?B?ZmZsQXRleXFuYWdqMTRCMElBN3BBd0wzVEtYeHBhYU9XKzVmU0VlVHVuVGVK?= =?utf-8?B?NUVDZUdlSE1iNmthaENqcVJTZXBPM0pKQ1pTdFR4akdSWDc3VTlpZTdidUhh?= =?utf-8?B?RVBzS0NGR29uY3pVNUQyM0ZFL1VybnQxdnR3Qlh6V3JqOTc1MGNIYytTK3hC?= =?utf-8?B?ZmxpZXlKSWhsbitLVW5yTHZ6Rkp4YTl3UmNXQmlMZGF2ajNOUGNOWENwQWZi?= =?utf-8?B?VmZiazBUV2RkSGQxQkF1RExRU3k5dS9HYnh2MUhRNUM1Q1pTaDdUcDZ5U09P?= =?utf-8?B?Ny9QanJzbUVEdjdINUFJbk85c25OS01CODAzakdickYyeGp5dmRMNWNZc2V2?= =?utf-8?B?RDhDcTBlNnBXaDhTdFllWE8xMUJqQnlNRHJDNVB4OERFSGdxVXQxcy9kY3hm?= =?utf-8?B?Qko4YmFWakJjcHNLRVprUzJGdnd3UDdUd0JlUjBGcm1nOHJtQWxyQ1FaWFB6?= =?utf-8?B?bGU2bDcxV0t6MHprdHJyczNnMzVFMGJZRnZRSnBjejNUOEVqb3Mvdnp5MTB4?= =?utf-8?B?aFN2TWRNMXgzRDl4eGkzNXBpSHJMSEdoWDZsbTcvTzMwTW1WYUNmRDFhNUdu?= =?utf-8?B?L3l6TU53c3FnS0hoNk85ZVczemtQakJlS25Ucy9oeGFLOGoybCtkUExrcEpI?= =?utf-8?B?V1h3aDNPcTdLMC9ldythSXZidGU3dW03a2xsQ0JuS1lza3EzbzRSZldBTHY1?= =?utf-8?B?SUpFeW8yU1o5dit6Wm9sMm1VRDhpcHRwU0poMlRkZjZ1UlA5cEFnMDUrcHN3?= =?utf-8?B?b1JvT3dsWWNmMDFzMWZ1VVJ1TWZydmoyYzRBVFdNZWNtcWxxMUw4Ykp1N1Ja?= =?utf-8?Q?oEYSwmZT8r+icpO+ej?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3dac128-597d-4394-e183-08df178801eb X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 02:28:22.6170 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: RnizZyuJDDjv7oxstG8ppNpr2WexaCqnVhUrv82Iszs9S8SGxiz7xwhWCXJT2rEI X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7719 X-purgate-ID: tlsNG-ef75cf/1789957709-A60C5AE4-179AF199/0/0 X-purgate-type: clean X-purgate-size: 2085 gnttab_alloc_pages() stores xen_page_foreign in page->private. On 32-bit, a pointer to an allocated xen_page_foreign is stored; on 64-bit, xen_page_foreign is stored inline. Checking page->private != NULL is enough to tell whether a xen_page_foreign needs to be freed on 32-bit and page->private is zeroed unconditionally on 64-bit. It prepares for a future commit that remove PG_private. No functional change intended. Assisted-by: LLM To: Juergen Gross To: Stefano Stabellini Cc: Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org Cc: linux-kernel@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Zi Yan --- drivers/xen/grant-table.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 69922be28b54c..993f89f048e21 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -863,10 +863,10 @@ EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames); int gnttab_pages_set_private(int nr_pages, struct page **pages) { +#if BITS_PER_LONG < 64 int i; for (i = 0; i < nr_pages; i++) { -#if BITS_PER_LONG < 64 struct xen_page_foreign *foreign; foreign = kzalloc_obj(*foreign); @@ -874,9 +874,9 @@ int gnttab_pages_set_private(int nr_pages, struct page **pages) return -ENOMEM; set_page_private(pages[i], (unsigned long)foreign); -#endif - SetPagePrivate(pages[i]); } +#endif + /* Data is stored in page->private on 64-bit */ return 0; } @@ -1031,12 +1031,11 @@ void gnttab_pages_clear_private(int nr_pages, struct page **pages) int i; for (i = 0; i < nr_pages; i++) { - if (PagePrivate(pages[i])) { #if BITS_PER_LONG < 64 + if (page_private(pages[i])) kfree((void *)page_private(pages[i])); #endif - ClearPagePrivate(pages[i]); - } + set_page_private(pages[i], 0); } } EXPORT_SYMBOL_GPL(gnttab_pages_clear_private); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 04:09:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 04:09:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427057.1649691 (Exim 4.92) (envelope-from ) id 1x8VL4-0003yl-Ss; Mon, 21 Sep 2026 04:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427057.1649691; Mon, 21 Sep 2026 04:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8VL4-0003ye-Og; Mon, 21 Sep 2026 04:09:10 +0000 Received: by outflank-mailman (input) for mailman id 1427057; Mon, 21 Sep 2026 04:09:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8VL3-0003yY-2V for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 04:09:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8VL1-0053qN-3e for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 06:09:07 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0adcb-8faa-0a2a0a5109dd-0a2a4505c33c-36 for ; Mon, 21 Sep 2026 06:09:06 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0ade0-4cb1-0a2a45050019-ac6904fe890c-3 for ; Mon, 21 Sep 2026 06:09:05 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id BDFEF60213; Mon, 21 Sep 2026 04:09:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63C301F000FF; Mon, 21 Sep 2026 04:09:00 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=korg header.d=linux-foundation.org header.i="@linux-foundation.org" header.h="Date:From:To:Cc:Subject:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1789963743; bh=LZ736WQSm180sbvHtkV3uFqBg4iSSs3xixQmjdddUBk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=fgqpk7b6eCfprR7zmZiJy9qBQZJsbM5f8s3hI8e6nM8wYRmEU0CAVWtHGL4kzcQi0 wEjzAZst11LRJ9q6W6kXCFZAXji7jeST+bAFloveBQOKkO+TvLOqlAUkcR9HD/Se9Q iZwtpMlXm4chDCNpRM7SRsEPxwlhnoNITtr0Iqy0= Date: Sun, 20 Sep 2026 21:08:59 -0700 From: Andrew Morton To: Zi Yan Cc: David Hildenbrand , "Matthew Wilcox (Oracle)" , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "H. Peter Anvin" , linux-perf-users@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, Oscar Salvador , Chao Yu , linux-f2fs-devel@lists.sourceforge.net, Tal Zussman , Gao Xiang , Jan Kara , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-trace-kernel@vger.kernel.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , ceph-devel@vger.kernel.org, Richard Weinberger , Zhihao Cheng , linux-mtd@lists.infradead.org, Baoquan He , Pasha Tatashin , Pratyush Yadav , Jonathan Corbet , Dave Young , Shuah Khan , kexec@lists.infradead.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v5 00/17] Remove PG_private by using page/folio->private checks instead Message-Id: <20260920210859.a0f75483dc4a12202c8b9516@linux-foundation.org> In-Reply-To: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> References: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789963746-24B1D2A1-082707C6/0/0 X-purgate-type: clean X-purgate-size: 8434 On Sun, 20 Sep 2026 22:27:56 -0400 Zi Yan wrote: > Hi all, > > This patchset removes PG_private to make space for upcoming PG_folio for > identifying pages from a folio (more details in Note below). Instead of > checking PG_private, all code is changed to check page/folio->private != > NULL instead. Thanks, I updated mm-unstable to this version. > Changes in v5: > 1. replaced md patches (patch 13 and 14 in v4) with Matthew Wilcox's > version (see Matthew's replies to v4). > 2. used data_race() inside folio_test_private() and PagePrivate(), so that > the new versions can be used without KCSAN warnings while not holding > folio lock like before. > 3. moved folio_has_attached_private() implementation detail comment next to > the code. Here's how v5 altered mm.git: drivers/md/md-bitmap.c | 17 ++++++++--------- fs/buffer.c | 8 -------- include/linux/buffer_head.h | 2 +- include/linux/mm.h | 3 +-- include/linux/page-flags.h | 30 +++++++++++++++++++----------- include/trace/events/pagemap.h | 3 +-- mm/huge_memory.c | 3 +-- mm/page-writeback.c | 3 +-- 8 files changed, 32 insertions(+), 37 deletions(-) --- a/drivers/md/md-bitmap.c~b +++ a/drivers/md/md-bitmap.c @@ -516,7 +516,8 @@ static void end_bitmap_write(struct bio static void write_file_page(struct bitmap *bitmap, struct page *page, int wait) { - struct buffer_head *bh = (struct buffer_head *)page_private(page); + struct folio *folio = page_folio(page); + struct buffer_head *bh = folio_buffers(folio); while (bh && bh->b_blocknr) { atomic_inc(&bitmap->pending_writes); @@ -533,18 +534,15 @@ static void write_file_page(struct bitma static void free_buffers(struct page *page) { - struct buffer_head *bh = (struct buffer_head *)page_private(page); - - if (!bh) - return; + struct folio *folio = page_folio(page); + struct buffer_head *bh = folio_detach_private(folio); while (bh) { struct buffer_head *next = bh->b_this_page; free_buffer_head(bh); bh = next; } - detach_page_private(page); - put_page(page); + folio_put(folio); } /* read a page from a file. @@ -559,6 +557,7 @@ static int read_file_page(struct file *f { int ret = 0; struct inode *inode = file_inode(file); + struct folio *folio = page_folio(page); struct buffer_head *bh; sector_t block, blk_cur; unsigned long blocksize = i_blocksize(inode); @@ -566,12 +565,12 @@ static int read_file_page(struct file *f pr_debug("read bitmap file (%dB @ %llu)\n", (int)PAGE_SIZE, (unsigned long long)index << PAGE_SHIFT); - bh = alloc_page_buffers(page, blocksize); + bh = folio_alloc_buffers(folio, blocksize, GFP_NOFS | __GFP_ACCOUNT); if (!bh) { ret = -ENOMEM; goto out; } - attach_page_private(page, bh); + folio_attach_private(folio, bh); blk_cur = index << (PAGE_SHIFT - inode->i_blkbits); while (bh) { block = blk_cur; --- a/fs/buffer.c~b +++ a/fs/buffer.c @@ -773,14 +773,6 @@ no_grow: } EXPORT_SYMBOL_GPL(folio_alloc_buffers); -struct buffer_head *alloc_page_buffers(struct page *page, unsigned long size) -{ - gfp_t gfp = GFP_NOFS | __GFP_ACCOUNT; - - return folio_alloc_buffers(page_folio(page), size, gfp); -} -EXPORT_SYMBOL_GPL(alloc_page_buffers); - static inline void link_dev_buffers(struct folio *folio, struct buffer_head *head) { --- a/include/linux/buffer_head.h~b +++ a/include/linux/buffer_head.h @@ -175,6 +175,7 @@ static inline unsigned long bh_offset(co return (unsigned long)(bh)->b_data & (page_size(bh->b_page) - 1); } +/* If we *know* folio->private refers to buffer_heads */ #define folio_buffers(folio) folio_get_private(folio) void buffer_check_dirty_writeback(struct folio *folio, @@ -191,7 +192,6 @@ void folio_set_bh(struct buffer_head *bh unsigned long offset); struct buffer_head *folio_alloc_buffers(struct folio *folio, unsigned long size, gfp_t gfp); -struct buffer_head *alloc_page_buffers(struct page *page, unsigned long size); struct buffer_head *create_empty_buffers(struct folio *folio, unsigned long blocksize, unsigned long b_state); void end_buffer_read_sync(struct buffer_head *bh, int uptodate); --- a/include/linux/mm.h~b +++ a/include/linux/mm.h @@ -3052,9 +3052,8 @@ static inline int folio_expected_ref_cou ref_count += !!data_race(folio->mapping) << order; /* * One reference from filesystem private data. - * Use data_race() since folio might not be locked. */ - ref_count += data_race(folio_has_attached_private(folio)); + ref_count += folio_has_attached_private(folio); } /* One reference per page table mapping. */ --- a/include/linux/page-flags.h~b +++ a/include/linux/page-flags.h @@ -576,7 +576,12 @@ FOLIO_FLAG(swapbacked, FOLIO_HEAD_PAGE) static __always_inline bool folio_test_private(const struct folio *folio) { - return folio->private; + /* + * data_race() is added for readers without holding the folio lock. + * Only the NULL/non-NULL answer is used and both are valid while + * private is being attached or detached, so the race is benign. + */ + return data_race(folio->private); } FOLIO_FLAG(private_2, FOLIO_HEAD_PAGE) @@ -1199,20 +1204,23 @@ static __always_inline void __ClearPageA * @folio: The folio to check. * * Use this in code that may encounter swapcache or hugetlb folios but only - * wants to detect attached private data. Swapcache stores swp_entry_t in - * folio->swap, a union with folio->private, and hugetlb stores its own flags - * in folio->private; both are excluded. - * - * NOTE: For swapcache, folio->swap.val PG_swapcache are not set as a whole, - * so folio_test_swapcache() is not reliable to exclude swapcache. - * Use folio_test_swapbacked() instead, since it remains set when a folio is - * added to/removed from swapcache. + * wants to detect attached private data. * - * Return: true if folio->private is set and the folio is neither swapcache - * nor hugetlb. + * Return: true if the folio has private data attached. */ static inline bool folio_has_attached_private(const struct folio *folio) { + /* + * Swapcache stores swp_entry_t in folio->swap, a union with + * folio->private, and hugetlb stores its own flags in folio->private; + * both are excluded. + * + * NOTE: For swapcache, folio->swap.val PG_swapcache are not set as + * a whole, so folio_test_swapcache() is not reliable to exclude + * swapcache. Use folio_test_swapbacked() instead, since it remains set + * when a folio is added to/removed from swapcache. + */ + return folio_test_private(folio) && !folio_test_swapbacked(folio) && !folio_test_hugetlb(folio); } --- a/include/trace/events/pagemap.h~b +++ a/include/trace/events/pagemap.h @@ -22,8 +22,7 @@ (folio_test_swapcache(folio) ? PAGEMAP_SWAPCACHE : 0) | \ (folio_test_swapbacked(folio) ? PAGEMAP_SWAPBACKED : 0) | \ (folio_test_mappedtodisk(folio) ? PAGEMAP_MAPPEDDISK : 0) | \ - /* data_race() is used to read attached private locklessly */ \ - (data_race(folio_has_attached_private(folio)) ? PAGEMAP_BUFFERS : 0) \ + (folio_has_attached_private(folio) ? PAGEMAP_BUFFERS : 0) \ ) TRACE_EVENT(mm_lru_insertion, --- a/mm/huge_memory.c~b +++ a/mm/huge_memory.c @@ -4845,9 +4845,8 @@ static int split_huge_pages_pid(int pid, * For folios with private, split_huge_page_to_list_to_order() * will try to drop it before split and then check if the folio * can be split or not. So skip the check here. - * data_race() is used to read attached private locklessly. */ - if (!data_race(folio_has_attached_private(folio)) && + if (!folio_has_attached_private(folio) && folio_expected_ref_count(folio) != folio_ref_count(folio)) goto next; --- a/mm/page-writeback.c~b +++ a/mm/page-writeback.c @@ -2705,8 +2705,7 @@ bool filemap_dirty_folio(struct address_ if (folio_test_set_dirty(folio)) return false; - /* data_race() is used to read attached private locklessly */ - __folio_mark_dirty(folio, mapping, !data_race(folio_has_attached_private(folio))); + __folio_mark_dirty(folio, mapping, !folio_has_attached_private(folio)); if (mapping->host) { /* !PageAnon && !swapper_space */ _ From xen-devel-bounces@lists.xenproject.org Mon Sep 21 04:32:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 04:32:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427065.1649698 (Exim 4.92) (envelope-from ) id 1x8VhM-0008Hg-MG; Mon, 21 Sep 2026 04:32:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427065.1649698; Mon, 21 Sep 2026 04:32:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8VhM-0008HZ-Jf; Mon, 21 Sep 2026 04:32:12 +0000 Received: by outflank-mailman (input) for mailman id 1427065; Mon, 21 Sep 2026 04:32:10 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8VhK-0008HT-IE for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 04:32:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8VhJ-00HIfj-00 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 06:32:09 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0b346-e002-0a2a0a5209dd-0a2a4501a460-4 for ; Mon, 21 Sep 2026 06:32:08 +0200 Received: from [40.107.201.18] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0b347-5984-0a2a45010019-286bc91288ef-3 for ; Mon, 21 Sep 2026 06:32:08 +0200 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by BY5PR03MB5316.namprd03.prod.outlook.com (2603:10b6:a03:220::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.15; Mon, 21 Sep 2026 04:32:04 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%5]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 04:32:03 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=c8oBqs7hBsvLAzDnPL8iMYkBYLNewWGLj94mV02M3Nf8JovSHhapI/0VDui1XE6ZgZcMAWF1Xe/Y9z8/Zz6ESWaRbCnkdrnZZDCf7+C1d0SvmalPAHRI5IxY8tAwP67KHhg68ThjiXHNGxzB+arPnqjoWQm5kjxkJe8vSzLldZ0xxT5p8u/RzJunElafqvBxOuzkFvGC6AV5Dj/0TvEag70ySKIi7oZ4wiqrQRlh52GMCr+XMGa0rK9moxX6dvuGlIWXGTBXzQEUB6BRR6S7QvG0oaSTN51OLui4IuYeP+r93fbgTPcv2vosJfEGmZPZaXeobJ9oFoleWpvQUeZGcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+Xa8mDS+ZPHMGi8DYJMltSSDqsfscHsv2U1xU2PtIlQ=; b=sPTmLGJ3x0bF9l71qUeTN1+453iUADVecLdw8xywvw9kZYcNrzcG7tcuO66CUTkCh+xntpD6KvChdPtKYEmPuIsmnd1zzxLyfLvtAcE/N8xWGZTPLb9198PTJIAHdiFa4xfUrJRRvhJKvTxQuXb2e7oAPpeht0havGqfJDTTkvMaQX3D8o3Pe4tmtHOQhcQYd9fABwgOpMHDiWEGJo5C8Zu96XysXNzUtRjZTdw/eHNz5rQ9WpMetT7ILWR+X4nwVXj6Q4uPFjvO1uDEDOGX9MnEyp0iRPB1LUdAnQwQZtSwh8fPQX8eJyIGUDVn3rUNWXpmvNNdeUyaBTf0XkA9Sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Xa8mDS+ZPHMGi8DYJMltSSDqsfscHsv2U1xU2PtIlQ=; b=lCvU4cJ6Dv2ZRjbKud2jsaYPIvrznNQkc9DYeCQCDH3x67/m34idr+yRv8zmjzBfP5Gz4qCqZFpskindNQwV03JqwOw7VhmzQOgceIBfv2xl25rKSxs/2v+7k+es//QOdULpOVWx7RKTt6PE3afWkM+AkNvOVXOm459X/oIRZCM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Stephen Cheng To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Stephen Cheng , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH] x86/nSVM: Don't zero the l1 guest's N_CR3 on #VMEXIT Date: Mon, 21 Sep 2026 12:31:48 +0800 Message-ID: <20260921043148.562181-1-stephen.cheng@citrix.com> X-Mailer: git-send-email 2.49.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI3PR01CA0007.apcprd01.prod.exchangelabs.com (2603:1096:4:296::8) To CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR03MB7889:EE_|BY5PR03MB5316:EE_ X-MS-Office365-Filtering-Correlation-Id: fa6a274c-7d44-4ef4-3c82-08df17994930 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|18002099003|56012099006|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: 2ynYqEjqoiU+TFad77ro/lJa65INhc6RiaMfj9s2DnXbBkkKjreE/nrwKnUCotLEHkVNCbXzyeEk3lRiVg6URiK74vDqOcV8ha5klcNlE0CKKigiI25UiBHYIqk9wMf5LhZm+8quPM1e4e2WhzSxm7bpzMDnhqd/S2DzIu6jWwFxvezGw9qS38UwKa2Sq16+UBbMcP4XlWsUomJzcbiT2HT5O9GktdWUXjpwfbBtRZmKApGzE+V7LVuEZ0xCs4343rlHXkgdaUiyvz91xD6jo+HFfVD1NW7ngbQr/qod26/f0IMAl1hwIour7ODoD8ygEcpOdq+qb/NvdwhXh5f5ydgSnmmzkM0Ah7udjCLhxUthtbflpfKrq97xuaRhYbxptm47fngPQMa8l6HSyJATatwfXyXWsGCfOKQX4ulNK3eSXM5PfQf2B7P4w6TDl+lVomaToZcNW8oYGMj6WjXsMVE+U08UhYz/Wxtf9iLDFBnbMChYFHsMekiTkhM/uNifSOfwaD/g0PoH3yVY/wvVsRVjy45+4w1VWGZgAMoE+c8s6kwbVuhs007oqxxdObPfiWtACqxmre5fJMy0Z+VC+rvTFjUtW21+J0X7FM0LKwuGl7xE6pNu3H1cEWM56GU92yNFXZU2+XtjBplX5J3Yrittwv8XIvXiNd5rK4yOv6Q= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR03MB7889.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(18002099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?5+jg+gcNZa7lrUYZiSIvEME6HjxnhGNJU22ImmOf3/I0XaUrrMrggYsBCwJX?= =?us-ascii?Q?MdhQq+pzo/LKTwon6+L9HAPWgQLYcJDz+61MrealvTL+Ooj+QiULlwvLdnM5?= =?us-ascii?Q?qugpezpPzfKIkbxCPVTpjTnhbg4OQJUcrV5zhzc3NtlbHYj0hcGRUvGzq9rU?= =?us-ascii?Q?GosLA1Jm6mx0niXLds6huToT9ovv0zo4k8d2Fr0t+BQtt3QBvlBroPSdysF1?= =?us-ascii?Q?TZoCMd5nd06Wzo0Ns2iG4U+mdi4vJj+5F4tNnIvPNA5/Uk46VCkKuZv3ie/l?= =?us-ascii?Q?3RIIm3SMrbCu1nQ+8KckzwwxXsW2K6/f3n2YUjK+uWelHnkzyVWTSi1ehMPa?= =?us-ascii?Q?3nwaDMTgEOHmHyQ1H8jtaTk8ev7X3esznWb6kFNXSCFQxrZzoE23/Kv7U0wz?= =?us-ascii?Q?XfiGftcd9bDqvjBdN0KLuEFkhgWNzdlJfQU6JFmhsAb4q1CwMWTuUdrFHZjL?= =?us-ascii?Q?GSx9tvF9CjqRj2NRlmKjqIdWr8vvdhqspFUbcfp3xw5R6oaulkPyjeY5jkZM?= =?us-ascii?Q?YZ17RVS4H6V1EPMPuaxFEFPDeX2053CxMRTMrnYtCCFuhVFUWPgsIR8eSsXU?= =?us-ascii?Q?N+oLtl4QRoDVGSAVw4iMfFGpZMZJC/8ZVOCfEHGzW3lDXO+Kdrh5TjaES4u2?= =?us-ascii?Q?jd42c+qQPL4QCvtCmHB/DiKqNaoFbi0vdU5PcHeZ1/slQlLB2Fwxk/3ddXAz?= =?us-ascii?Q?mMOG9gvitqkFXpAKem68mv60rth1pTf/gB06tY3FYGKb5IZ7JfoPQQp+u0Sf?= =?us-ascii?Q?cZaosSYG3fSZZAOSUlRoqTOodaiPOEcU3UR5quS6t1LIyzXKjF63lFvgDiqY?= =?us-ascii?Q?hNh39PuXg96MGWX2xhBZ6GmqoRvozAeMAgcoRhBAwoQid6eqqdmcNUTA1ntI?= =?us-ascii?Q?5m/gYpKwICHpBEMlsj17HDntHawS1F95IaOuqifqwSn9a6f0YmSDTljbYD82?= =?us-ascii?Q?DA15r8TUz6qctMvN2ES9aAXWW4IX5XiT4Y7kIGlMGSu7Ai4m2lxMp0Y5CHwc?= =?us-ascii?Q?bM5teeENglEajvjOiDriTCUi+1crMRmAFJKKdo5CSU1aKdJCrRSouLvhaSd3?= =?us-ascii?Q?k/QBI76f4wFH757MoiJrefdnNckw3SGJdZslfNJga41qjqpYF8DPKRKNOzHz?= =?us-ascii?Q?mggLKc7XWxV1tafNaHQh1rDZf4WYcdqWUOwpuY+IZkMntFZ0Nw8vIQb5eRaB?= =?us-ascii?Q?2boqeuf5bGYFM/LuO5GnEeazu4MjMfoIkK5k4eSIAQAzpW4nlUMLz/CkyXhQ?= =?us-ascii?Q?Q/PBlPsPkJ/C/oVBAYAWMA9cIun1jXTc+hmPt0XyAbkZGFrCWHf2kOtufHrR?= =?us-ascii?Q?YZRyPNa8w/fgYB0q2j8I8LYGI5jVgWvFeKbtRnDLzE3X7VZFBJr2uVX8UM0C?= =?us-ascii?Q?ssYGm2Z5YLJq0RZu5lrPd2k1Oe8oMI2ELNH4Qe2PRatIqRa83gUmiC9VH+Fq?= =?us-ascii?Q?hSCZfz9PO1eiEsUmaaedbEg9YUd3ws6MaRFpXCZumwzTx3NBkhwqSIkwHJER?= =?us-ascii?Q?JWYMVRoQjo5LOYtv8e7gujBHdENz5CT+EguK4Lz79vap/PG8Z9/bNXAUT7yw?= =?us-ascii?Q?3ZHkeUeqeE81ekDwubfWA9/ITX057I7ZwErOehyQ23zHwzew2HF4Gguq9V64?= =?us-ascii?Q?pX4wso4BOc9XHkGlV7WP3w4/fmDh7Vn9ljJMX02+cnpPDZFrq574iYfRF4R8?= =?us-ascii?Q?g63oYaO2KpAWT/nYHp74RdhJKPGDNIkcF6O45EiJ8a0VMT3q+57mfrC7sCJ9?= =?us-ascii?Q?uD15EgTtLQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa6a274c-7d44-4ef4-3c82-08df17994930 X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 04:32:03.8345 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 2HpmiPmDiYaOb+ZnzbKT0qy27+rbvcZHp6b6YbOLoSPkMTS5uCMS8i3BH4MZu0JKNxJ5O0t6nmFp/kfTz/y4UI62gSGHXMFqdPpjILLv43Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5316 X-purgate-ID: tlsNG-d62444/1789965128-1EC61757-00F27468/0/0 X-purgate-type: clean X-purgate-size: 2471 Xen's emulated #VMEXIT writes a VMCB field that a real #VMEXIT leaves alone. nsvm_vmcb_prepare4vmexit() zeroes ns_vmcb->_h_cr3 when the l1 guest runs its l2 guest with nested paging off. Hardware writes back guest state and the exit-information fields (AMD APM vol 2 rev 3.44 section 15.6); N_CR3 is neither, and section 15.25.4 says so by name: "nCR3 is not saved back into the VMCB". An l1 guest that sets N_CR3 once and reuses the VMCB finds it zeroed. The comment defending it - the guest "is not allowed to set" h_cr3, "otherwise (security hole!)" - is wrong. ns_vmcb is a live mapping of l1 guest memory, so the guest can write the field again before the next VMRUN. Drop both assignments and that comment. Assisted-by: Claude:claude-opus-5 Signed-off-by: Stephen Cheng --- xen/arch/x86/hvm/svm/nestedsvm.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index a8b15d6eae..54c62d1474 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1023,7 +1023,10 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) ns_vmcb->event_inj.raw = 0; - /* Nested paging mode */ + /* + * Nested paging mode. ns_vmcb->_h_cr3 is left alone: hardware does not + * save N_CR3 back into the VMCB on #VMEXIT. + */ if ( nestedhvm_paging_mode_hap(v) ) { /* host nested paging + guest nested paging. */ @@ -1037,9 +1040,6 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) { /* host nested paging + guest shadow paging. */ vmcb_set_np(ns_vmcb, false); - /* Throw h_cr3 away. Guest is not allowed to set it or - * it can break out, otherwise (security hole!) */ - ns_vmcb->_h_cr3 = 0x0; /* Stop intercepting #PF (already done above * by restoring cached intercepts). */ ns_vmcb->_cr3 = n2vmcb->_cr3; @@ -1048,7 +1048,6 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) { /* host shadow paging + guest shadow paging. */ vmcb_set_np(ns_vmcb, false); - ns_vmcb->_h_cr3 = 0x0; /* The vmcb->_cr3 is the shadowed cr3. The original * unshadowed guest cr3 is kept in ns_vmcb->_cr3, * hence we keep the ns_vmcb->_cr3 value. */ -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 04:59:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 04:59:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1426884.1649707 (Exim 4.92) (envelope-from ) id 1x8W80-0002ib-NA; Mon, 21 Sep 2026 04:59:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1426884.1649707; Mon, 21 Sep 2026 04:59:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8W80-0002iU-Jy; Mon, 21 Sep 2026 04:59:44 +0000 Received: by outflank-mailman (input) for mailman id 1426884; Sun, 20 Sep 2026 15:48:27 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8JmE-0008LN-CT for xen-devel@lists.xenproject.org; Sun, 20 Sep 2026 15:48:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8JmC-00B7qG-Pr for xen-devel@lists.xenproject.org; Sun, 20 Sep 2026 17:48:25 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0000c-8faa-0a2a0a5109dd-0a2a450cabac-12 for ; Sun, 20 Sep 2026 17:48:24 +0200 Received: from [54.36.140.180] (helo=5.mo533.mail-out.ovh.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab00047-f479-0a2a450c0019-36248cb4b9b1-3 for ; Sun, 20 Sep 2026 17:48:23 +0200 Received: from director5.derp.mail-out.ovh.net (director5.derp.mail-out.ovh.net [79.137.60.225]) by mo533.mail-out.ovh.net (Postfix) with ESMTPS id 4hnrP31b1Rz5vRc; Sun, 20 Sep 2026 15:48:22 +0000 (UTC) Received: from director5.derp.mail-out.ovh.net (director5.derp.mail-out.ovh.net. [127.0.0.1]) by director5.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Sun, 20 Sep 2026 15:48:22 +0000 (UTC) Received: from mta3.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.110.43.5]) by director5.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4hnrP263ghz6MfW; Sun, 20 Sep 2026 15:48:22 +0000 (UTC) Received: from mailstore7.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.1.8.7]) by mta3.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTP id 2BE61941C46; Sun, 20 Sep 2026 15:48:22 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo-selector-1 header.d=trinity-net.com header.i="@trinity-net.com" header.h=From Date: Sun, 20 Sep 2026 15:48:21 +0000 (UTC) From: Support TRINITY To: regressions , linux-acpi , linux-pm , stable , xen-devel , linux-kernel Message-ID: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> Subject: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_272724280_77477482.1789919301849" X-Originating-IP: [213.169.178.160] X-Authenticated-User: support@trinity-net.com Thread-Index: J0WC9Lz/JqqsW8wEjua4qngWayI/rQ== Thread-Topic: ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot x-ovh-tracer-id: 19703252068169243 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: dmFkZTFbQLjH9qbyLulfAQ1H8t7HZfyq59xaXhsT3Do+N2Ltq2bnE4tgFywJE93y/iDr7ru0k06ap9akNcZDZvVSIVMVWyRDLhCoxZM/vRuejdZEEdzPgbfrO1FhlsP5K4qqoPk0Gj+QvuPjQdWYwWSDOc9BdLRRfiIkHvgnn68NwSJ38seQvvr2hwMKmB7QkB0y6LvcF2Ng1crjBP2apaZ1IpJtRG2WMbzP7uF00Q6qlbx7QOtzDra0kYvFxmZoSFuO5SeX5Q61oRtBYbdQTzIm/sz/Qum4B0ZkBmRezj/Lsuei4VoEmPzsAE0NwvlT8jccU3eTzOM6IJgplkbB4YdWssuAOwrTRyAl8uJbEmS8+1DygT8cSmZHMISl3UjF6+y2R5l6k89J56eb5sI/994XY0GVN1tSPeoQM2WcigkXCpXx3CCEgVrYcT1Ws+PP5QcPjq2DEBFPb0HDjBEGK0Rx6DVvPzbv0xQc6K90ytkVpdB/xk98EN4GQJmXaIajnhBCSkyEa10x0/0kZpUhVu4lYrDLy7rrTpedKC53O/EXr32T2JtFL2ze/rAQ7/hJVDkzu9+G1dmrXm2EyWbp4yo8uqThm+GIcr8A/mOfRdvW0HWCvj1ujXY/3hRKhJO4Hk8tDLm1Jys+26EQKH9jNB3P2nVYivb3UHqGIPllk1uTFqcsGA DKIM-Signature: a=rsa-sha256; bh=8tyVAIP3ha57xPwpoAUiImLWABThlAja3KfJ/07UdNQ=; c=relaxed/relaxed; d=trinity-net.com; h=From; s=ovhmo-selector-1; t=1789919303; v=1; b=e1i0jEmdNrm4gy1acYoOKPH8MMSKT7Pq3NNllhBrmIBbMOkmbh1dCBfmjztmetfaUQYdDd98 6x1CLTNdj8cvJM5iKh9Y/ROusDeUII2YtM/Za/Hj/o8ctvvpt9AqUVAWtNTS73HSTvR0uwA5B3n cXF6EgI1oZdrdIWMaENiCNsDZkDWpIbyk8eLfwRMRbnIE7jDsdfBYTRZHb7chquVSVZM3hhuHeC ziHU5B9eTXHInWziZqTDKvW57XEYt3y7L3XYD/synwwYbZtBe4GYbWpe6t083tieIvCMazYRpkq 9+5ogbHyhO6D6v3ttjrnzL4J3lDpGB8PAOdrsXTLofPig== X-purgate-ID: tlsNG-d25034/1789919304-50520A5B-10E9C74A/0/0 X-purgate-type: clean X-purgate-size: 36660 ------=_Part_272724280_77477482.1789919301849 Content-Type: multipart/alternative; boundary="=_20c5ede6-89f0-4cdd-87a1-792e3faa35b4" --=_20c5ede6-89f0-4cdd-87a1-792e3faa35b4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello, I am reporting a bare-metal Xen dom0 boot regression seen with Linux 6.18.52. On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on bare metal, while Linux 6.18.52 consistently black-screens before dom0 userspace/networking comes up. #regzbot introduced: v6.18.51..v6.18.52 #regzbot title: ACPI processor/cpuidle lifecycle change breaks bare-metal Xen dom0 boot #regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447 Tested results: - Linux 6.18.51-r0, Xen dom0, bare metal: boots - Linux 6.18.52-r0, Xen dom0, bare metal: black screen before userspace/network - Linux 6.18.52-r0, Xen domU: boots - Linux 6.18.52-r0 with Xenbus notifier change reverted: still fails - Linux 6.18.52-r0 with only ACPI processor/cpuidle changes reverted: boots - Linux 6.18.52-r0 with refined ACPI idle lifecycle patch: boots Affected hardware tested: - Intel Core i7-4785T thin mini-ITX, 16 GB DDR3 - Intel N305 thin mini-ITX, 16 GB DDR5 - Supermicro / Intel Xeon E5-1650, 32 GB DDR3 The successful boot used the regular Xen command line: multiboot2 /boot/xen.gz cpufreq=xen:performance module2 /boot/vmlinuz-lts modules=loop,squashfs,sd-mod,usb-storage,xfs quiet module2 /boot/initramfs-lts No IOMMU workaround, serial console parameter, debug parameter, storage workaround, or Xen command-line change was required. The regression was narrowed to ACPI processor/cpuidle changes between 6.18.51 and 6.18.52, specifically the idle-driver registration lifecycle. The working 6.18.51-style behavior registers the ACPI idle driver from acpi_processor_power_init() and unregisters it from acpi_processor_power_exit(). The failing 6.18.52 behavior registers the ACPI idle driver globally from acpi_processor_driver_init() before driver_register(). A first ACPI-only revert confirmed the regression source. A refined candidate patch was then prepared to preserve the working ACPI idle lifecycle while keeping unrelated 6.18.52 safety fixes, including: - _LPI bounds checks - cpufreq notifier cleanup on acpi_processor_driver_init() failure The refined candidate patch modifies only: - drivers/acpi/processor_driver.c - drivers/acpi/processor_idle.c - include/acpi/processor.h It does not modify Xen, Xenbus, IOMMU, APIC, PCI/ASPM, intel_idle, syscore, USB, storage, XFS, networking, printk, or the cpuidle core API. The earlier cpuidle_disabled() workaround is not included. The refined patch has been rebuilt and boot-tested successfully as Xen dom0 on bare metal on TRINITY-EDGE. This issue is currently visible to Alpine users because the Alpine v3.24 stable repository contains: alpine-release 3.24.2-r0 linux-lts 6.18.52-r0 Systems tracking Alpine 3.24 stable / latest-stable may therefore receive Linux 6.18.52 as the default LTS kernel. Attachments: - revert-acpi-idle-registration-lifecycle.patch - APKBUILD The original Alpine report is here: https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447 Please let me know if this should be submitted as a formal patch with Signed-off-by, or if there is a better upstream fix/dependency that should be backported instead. Regards, Tony BONNIN --=_20c5ede6-89f0-4cdd-87a1-792e3faa35b4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hello,

I am reporting a bare-metal Xen dom0 boot regression seen with Linux 6.18.52.

On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on bare metal, while Linux 6.18.52 consistently black-screens before dom0 userspace/networking comes up.

#regzbot introduced: v6.18.51..v6.18.52
#regzbot title: ACPI processor/cpuidle lifecycle change breaks bare-metal Xen dom0 boot
#regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447

Tested results:

  • Linux 6.18.51-r0, Xen dom0, bare metal: boots
  • Linux 6.18.52-r0, Xen dom0, bare metal: black screen before userspace/network
  • Linux 6.18.52-r0, Xen domU: boots
  • Linux 6.18.52-r0 with Xenbus notifier change reverted: still fails
  • Linux 6.18.52-r0 with only ACPI processor/cpuidle changes reverted: boots
  • Linux 6.18.52-r0 with refined ACPI idle lifecycle patch: boots

Affected hardware tested:

  • Intel Core i7-4785T thin mini-ITX, 16 GB DDR3
  • Intel N305 thin mini-ITX, 16 GB DDR5
  • Supermicro / Intel Xeon E5-1650, 32 GB DDR3

The successful boot used the regular Xen command line:

multiboot2 /boot/xen.gz cpufreq=xen:performance
module2 /boot/vmlinuz-lts modules=loop,squashfs,sd-mod,usb-storage,xfs quiet
module2 /boot/initramfs-lts

No IOMMU workaround, serial console parameter, debug parameter, storage workaround, or Xen command-line change was required.

The regression was narrowed to ACPI processor/cpuidle changes between 6.18.51 and 6.18.52, specifically the idle-driver registration lifecycle.

The working 6.18.51-style behavior registers the ACPI idle driver from acpi_processor_power_init() and unregisters it from acpi_processor_power_exit().

The failing 6.18.52 behavior registers the ACPI idle driver globally from acpi_processor_driver_init() before driver_register().

A first ACPI-only revert confirmed the regression source. A refined candidate patch was then prepared to preserve the working ACPI idle lifecycle while keeping unrelated 6.18.52 safety fixes, including:

  • _LPI bounds checks
  • cpufreq notifier cleanup on acpi_processor_driver_init() failure

The refined candidate patch modifies only:

  • drivers/acpi/processor_driver.c
  • drivers/acpi/processor_idle.c
  • include/acpi/processor.h

It does not modify Xen, Xenbus, IOMMU, APIC, PCI/ASPM, intel_idle, syscore, USB, storage, XFS, networking, printk, or the cpuidle core API.

The earlier cpuidle_disabled() workaround is not included.

The refined patch has been rebuilt and boot-tested successfully as Xen dom0 on bare metal on TRINITY-EDGE.

This issue is currently visible to Alpine users because the Alpine v3.24 stable repository contains:

alpine-release 3.24.2-r0
linux-lts 6.18.52-r0

Systems tracking Alpine 3.24 stable / latest-stable may therefore receive Linux 6.18.52 as the default LTS kernel.

Attachments:

  • revert-acpi-idle-registration-lifecycle.patch
  • APKBUILD

The original Alpine report is here:

https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447

Please let me know if this should be submitted as a formal patch with Signed-off-by, or if there is a better upstream fix/dependency that should be backported instead.

Regards,

Tony BONNIN

--=_20c5ede6-89f0-4cdd-87a1-792e3faa35b4-- ------=_Part_272724280_77477482.1789919301849 Content-Type: text/plain; name=APKBUILD Content-Disposition: attachment; filename=APKBUILD Content-Transfer-Encoding: base64 IyBNYWludGFpbmVyOiBOYXRhbmFlbCBDb3BhIDxuY29wYUBhbHBpbmVsaW51eC5vcmc+CgpfZmxh dm9yPSR7RkxBVk9SOi1sdHN9CnBrZ25hbWU9bGludXgtJF9mbGF2b3IKcGtndmVyPTYuMTguNTIK X2tlcm52ZXI9JHtwa2d2ZXIlLip9CnBrZ3JlbD0wCnBrZ2Rlc2M9IkxpbnV4IGx0cyBrZXJuZWwi CnVybD0iaHR0cHM6Ly93d3cua2VybmVsLm9yZyIKZGVwZW5kcz0iaW5pdHJhbWZzLWdlbmVyYXRv ciIKX2RlcGVuZHNfZGV2PSJwZXJsIGdtcC1kZXYgbXBjMS1kZXYgbXBmci1kZXYgZWxmdXRpbHMt ZGV2IGJhc2ggZmxleCBiaXNvbiB6c3RkIgptYWtlZGVwZW5kcz0iJF9kZXBlbmRzX2RldiBzZWQg aW5zdGFsbGtlcm5lbCBiYyBsaW51eC1oZWFkZXJzIGxpbnV4LWZpcm13YXJlLWFueSBvcGVuc3Ns LWRldj4zIG1hd2sKCWRpZmZ1dGlscyBlbGZ1dGlscyBmaW5kdXRpbHMgenN0ZCBwYWhvbGUgcHl0 aG9uMyBnY2M+PTEzLjEuMV9naXQyMDIzMDYyNCBicGZ0b29sIgpvcHRpb25zPSIhc3RyaXAgIWNo ZWNrIgpzb3VyY2U9Imh0dHBzOi8vY2RuLmtlcm5lbC5vcmcvcHViL2xpbnV4L2tlcm5lbC92JHtw a2d2ZXIlJS4qfS54L2xpbnV4LSRfa2VybnZlci50YXIueHoKCTAwMDEtcG93ZXJwYy1ib290LXdy YXBwZXItQWRkLXotbm90ZXh0LWZsYWctZm9yLXBwYzY0bGUucGF0Y2gKCTAwMDIteDg2LUNvbXBy ZXNzLXZtbGludXgtd2l0aC16c3RkLTE5LWluc3RlYWQtb2YtMjIucGF0Y2gKCTAwMDMta2V4ZWMt YWRkLWtleGVjX2xvYWRfZGlzYWJsZWQtYm9vdC1vcHRpb24ucGF0Y2gKCTAwMDQtb2JqdG9vbC1y ZXNwZWN0LUFXSy1zZXR0aW5nLnBhdGNoCgkwMDA1LXBvd2VycGMtY29uZmlnLWRlZmFuZy1nY2Mt Y2hlY2stZm9yLXN0YWNrLXByb3RlY3Rvci0ucGF0Y2gKCTAwMDEteDg2LUNQVS1BTUQtYXZvaWQt cHJpbnRpbmctcmVzZXQtcmVhc29ucy1vbi1YZW4tZG9tVS5wYXRjaAoJcmV2ZXJ0LWFjcGktaWRs ZS1yZWdpc3RyYXRpb24tbGlmZWN5Y2xlLnBhdGNoCglzb3BoZ28tZml4ZXMucGF0Y2gKCglsdHMu YWFyY2g2NC5jb25maWcKCWx0cy5hcm12Ny5jb25maWcKCWx0cy5sb29uZ2FyY2g2NC5jb25maWcK CWx0cy5wcGM2NGxlLmNvbmZpZwoJbHRzLnJpc2N2NjQuY29uZmlnCglsdHMuczM5MHguY29uZmln CglsdHMueDg2LmNvbmZpZwoJbHRzLng4Nl82NC5jb25maWcKCgl2aXJ0LmFhcmNoNjQuY29uZmln Cgl2aXJ0LmFybXY3LmNvbmZpZwoJdmlydC5wcGM2NGxlLmNvbmZpZwoJdmlydC54ODYuY29uZmln Cgl2aXJ0Lng4Nl82NC5jb25maWcKCSIKCiMgQWxsb3cgYWRkaW5nIGN1c3RvbSBmbGF2b3IgY29u ZmlnIHZpYSBGTEFWT1IgdmFyCiMgVGhlIGNvbmZpZyBmaWxlIHNob3VsZCBiZSBuYW1lZCAke0ZM QVZPUn0uJHtDQVJDSH0uY29uZmlnCmlmIFsgLW4gIiRGTEFWT1IiIF07IHRoZW4KCXNvdXJjZT0i JHNvdXJjZQoJJHtGTEFWT1J9LiR7Q0FSQ0h9LmNvbmZpZyIKZmkKCnN1YnBhY2thZ2VzPSIkcGtn bmFtZS1kZXY6X2RldjokQ0JVSUxEX0FSQ0ggJHBrZ25hbWUtZG9jIgpmb3IgX2kgaW4gJHNvdXJj ZTsgZG8KCWNhc2UgJF9pIGluCgkqLiRDQVJDSC5jb25maWcpCgkJX2Y9JHtfaSUuIiRDQVJDSCIu Y29uZmlnfQoJCWlmIFsgLW4gIiRGTEFWT1IiIF0gJiYgWyAiJF9mIiAhPSAiJEZMQVZPUiIgXTsg dGhlbgoJCQkjIHNraXAgZmxhdm9ycyB0aGF0IGRvbid0IG1hdGNoCgkJCWNvbnRpbnVlCgkJZmkK CQlfZmxhdm9ycz0iJF9mbGF2b3JzICRfZiIKCQlpZiBbICJsaW51eC0kX2YiICE9ICIkcGtnbmFt ZSIgXTsgdGhlbgoJCQlzdWJwYWNrYWdlcz0iJHN1YnBhY2thZ2VzIGxpbnV4LSRfZjo6JENCVUlM RF9BUkNIIGxpbnV4LSRfZi1kZXY6X2RldjokQ0JVSUxEX0FSQ0giCgkJZmkKCQk7OwoJZXNhYwpk b25lCmJ1aWxkZGlyPSIkc3JjZGlyIi9saW51eC0kX2tlcm52ZXIKCmlmIFsgIiR7cGtndmVyJS4w fSIgPSAiJHBrZ3ZlciIgXTsgdGhlbgoJIyBQcmVwZW5kIHRvIGFwcGx5IGZpcnN0Cglzb3VyY2U9 InBhdGNoLSRwa2d2ZXIucGF0Y2gueHo6Omh0dHBzOi8vY2RuLmtlcm5lbC5vcmcvcHViL2xpbnV4 L2tlcm5lbC92JHtwa2d2ZXIlJS4qfS54L3BhdGNoLSRwa2d2ZXIueHogJHNvdXJjZSIKZmkKYXJj aD0iYWxsICFhcm1oZiIKbGljZW5zZT0iR1BMLTIuMC1vbmx5IgoKIyBzZWNmaXhlcyBhcmUgbm90 IHRyYWNrZWQKIyBodHRwczovL2dpdGxhYi5hbHBpbmVsaW51eC5vcmcvYWxwaW5lL2Fwb3J0cy8t L3dvcmtfaXRlbXMvMTgxOTQKCnByZXBhcmUoKSB7CglkZWZhdWx0X3ByZXBhcmUKCgkjIHJlbW92 ZSBsb2NhbHZlcnNpb24gZnJvbSBwYXRjaCBpZiBhbnkKCXJtIC1mIGxvY2FsdmVyc2lvbioKfQoK X2tlcm5lbGFyY2goKSB7Cglsb2NhbCBhcmNoPSIkMSIKCWNhc2UgIiRhcmNoIiBpbgoJCWFhcmNo NjQqKSBhcmNoPSJhcm02NCIgOzsKCQlhcm0qKSBhcmNoPSJhcm0iIDs7CgkJcHBjKikgYXJjaD0i cG93ZXJwYyIgOzsKCQlzMzkwKikgYXJjaD0iczM5MCIgOzsKCQlyaXNjdiopIGFyY2g9InJpc2N2 IiA7OwoJCWxvb25nYXJjaDY0KSBhcmNoPSJsb29uZ2FyY2giIDs7Cgllc2FjCgllY2hvICIkYXJj aCIKfQoKX3ByZXBhcmVjb25maWcoKSB7Cglsb2NhbCBfZmxhdm9yPSIkMSIKCWxvY2FsIF9hcmNo PSIkMiIKCWxvY2FsIF9jb25maWc9JF9mbGF2b3IuJF9hcmNoLmNvbmZpZwoJbG9jYWwgX2J1aWxk ZGlyPSIkc3JjZGlyIi9idWlsZC0kX2ZsYXZvci4kX2FyY2gKCW1rZGlyIC1wICIkX2J1aWxkZGly IgoJZWNobyAiLSRwa2dyZWwtJF9mbGF2b3IiID4gIiRfYnVpbGRkaXIiL2xvY2FsdmVyc2lvbi1h bHBpbmUKCgljcCAiJHNyY2RpciIvJF9jb25maWcgIiRfYnVpbGRkaXIiLy5jb25maWcKCW1zZyAi Q29uZmlndXJpbmcgJF9mbGF2b3Iga2VybmVsICgkX2FyY2gpIgoJbWFrZSAtQyAiJGJ1aWxkZGly IiBcCgkJTz0iJF9idWlsZGRpciIgXAoJCUFSQ0g9IiQoX2tlcm5lbGFyY2ggJF9hcmNoKSIgXAoJ CW9sZGRlZmNvbmZpZwoKCWlmIGdyZXAgIkNPTkZJR19NT0RVTEVfU0lHPXkiICIkX2J1aWxkZGly Ii8uY29uZmlnID4vZGV2L251bGw7IHRoZW4KCQlpZiBbIC1mICIkS0VSTkVMX1NJR05JTkdfS0VZ IiBdOyB0aGVuCgkJCXNlZCAtaSAtZSAiczpeQ09ORklHX01PRFVMRV9TSUdfS0VZPS4qOkNPTkZJ R19NT0RVTEVfU0lHX0tFWT1cIiRLRVJORUxfU0lHTklOR19LRVlcIjoiIFwKCQkJCSIkX2J1aWxk ZGlyIi8uY29uZmlnCgkJCW1zZyAiVXNpbmcgJEtFUk5FTF9TSUdOSU5HX0tFWSB0byBzaWduICRf Zmxhdm9yIGtlcm5lbCAoJF9hcmNoKSBtb2R1bGVzIgoJCWVsc2UKCQkJd2FybmluZyAiS0VSTkVM X1NJR05JTkdfS0VZIHdhcyBub3Qgc2V0LiBBIHNpZ25pbmcga2V5IHdpbGwgYmUgZ2VuZXJhdGVk LCBidXQgM3JkIgoJCQl3YXJuaW5nICJwYXJ0eSBtb2R1bGVzIGNhbiBub3QgYmUgc2lnbmVkIgoJ CWZpCglmaQp9CgpsaXN0Y29uZmlncygpIHsKCWZvciBpIGluICRzb3VyY2U7IGRvCgkJY2FzZSAi JGkiIGluCgkJCSouY29uZmlnKSBlY2hvICRpOzsKCQllc2FjCglkb25lCn0KCnByZXBhcmVjb25m aWdzKCkgewoJZm9yIF9jb25maWcgaW4gJChsaXN0Y29uZmlncyk7IGRvCgkJbG9jYWwgX2ZsYXZv cj0ke19jb25maWclJS4qfQoJCWxvY2FsIF9hcmNoPSR7X2NvbmZpZyUuY29uZmlnfQoJCV9hcmNo PSR7X2FyY2gjKi59CgkJbG9jYWwgX2J1aWxkZGlyPSIkc3JjZGlyIi9idWlsZC0kX2ZsYXZvci4k X2FyY2gKCQlfcHJlcGFyZWNvbmZpZyAiJF9mbGF2b3IiICIkX2FyY2giCglkb25lCn0KCiMgdGhp cyBpcyBzdXBwb3NlZCB0byBiZSBydW4gYmVmb3JlIHZlcnNpb24gaXMgYnVtcGVkIHNvIHdlIGNh biBjb21wYXJlCiMgd2hhdCBuZXcga2VybmVsIGNvbmZpZyBrbm9icyBhcmUgaW50cm9kdWNlZApw cmVwYXJldXBkYXRlKCkgewoJY2xlYW4gJiYgZmV0Y2ggJiYgdW5wYWNrICYmIHByZXBhcmUgJiYg ZGVwcwoJcHJlcGFyZWNvbmZpZ3MKCXJtIC1yICIkYnVpbGRkaXIiCn0KCnVwZGF0ZWNvbmZpZ3Mo KSB7CglpZiAhIFsgLWQgIiRidWlsZGRpciIgXTsgdGhlbgoJCWRlcHMgJiYgZmV0Y2ggJiYgdW5w YWNrICYmIHByZXBhcmUKCWZpCglmb3IgX2NvbmZpZyBpbiAke0NPTkZJR1M6LSQobGlzdGNvbmZp Z3MpfTsgZG8KCQltc2cgInVwZGF0aW5nICRfY29uZmlnIgoJCWxvY2FsIF9mbGF2b3I9JHtfY29u ZmlnJSUuKn0KCQlsb2NhbCBfYXJjaD0ke19jb25maWclLmNvbmZpZ30KCQlfYXJjaD0ke19hcmNo IyoufQoJCWxvY2FsIF9idWlsZGRpcj0iJHNyY2RpciIvYnVpbGQtJF9mbGF2b3IuJF9hcmNoCgkJ bWtkaXIgLXAgIiRfYnVpbGRkaXIiCgkJZWNobyAiLSRwa2dyZWwtJF9mbGF2b3IiID4gIiRfYnVp bGRkaXIiL2xvY2FsdmVyc2lvbi1hbHBpbmUKCQlsb2NhbCBhY3Rpb25zPSJsaXN0bmV3Y29uZmln IG9sZGNvbmZpZyIKCQlpZiAhIFsgLWYgIiRfYnVpbGRkaXIiLy5jb25maWcgXTsgdGhlbgoJCQlj cCAiJHNyY2RpciIvJF9jb25maWcgIiRfYnVpbGRkaXIiLy5jb25maWcKCQkJYWN0aW9ucz0ib2xk ZGVmY29uZmlnIgoJCWZpCgkJZW52IHwgZ3JlcCBeQ09ORklHXyA+PiAiJF9idWlsZGRpciIvLmNv bmZpZyB8fCB0cnVlCgkJbWFrZSAtajEgLUMgIiRidWlsZGRpciIgXAoJCQlPPSIkX2J1aWxkZGly IiBcCgkJCUFSQ0g9IiQoX2tlcm5lbGFyY2ggJF9hcmNoKSIgXAoJCQkkYWN0aW9ucyBzYXZlZGVm Y29uZmlnCgoJCWNwICIkX2J1aWxkZGlyIi9kZWZjb25maWcgIiRzdGFydGRpciIvJF9jb25maWcK CWRvbmUKfQoKc2V0X2tidWlsZF90aW1lc3RhbXAoKSB7CgkjIEtCVUlMRF9CVUlMRF9USU1FU1RB TVAgbmVlZHMgdG8gYmUgcGFyc2FibGUgYnkgYnVzeWJveCBkYXRlCglleHBvcnQgS0JVSUxEX0JV SUxEX1RJTUVTVEFNUD0iJChkYXRlICcrJVktJW0tJWQgJUg6JU06JVMnIC11JHtTT1VSQ0VfREFU RV9FUE9DSDorZCBAJFNPVVJDRV9EQVRFX0VQT0NIfSkiCn0KCmJ1aWxkKCkgewoJdW5zZXQgTERG TEFHUwoJIyBmb3Igc29tZSByZWFzb24gdGhlc2Ugc29tZXRpbWVzIGxlYWsgaW50byB0aGUga2Vy bmVsIGJ1aWxkLAoJIyAtV2Vycm9yPWZvcm1hdC1zZWN1cml0eSBicmVha3Mgc29tZSBzdHVmZgoJ dW5zZXQgQ0ZMQUdTIENQUEZMQUdTIENYWEZMQUdTCglzZXRfa2J1aWxkX3RpbWVzdGFtcAoJZm9y IGkgaW4gJF9mbGF2b3JzOyBkbwoJCV9wcmVwYXJlY29uZmlnICIkaSIgIiRDQVJDSCIKCWRvbmUK CWZvciBpIGluICRfZmxhdm9yczsgZG8KCQltc2cgIkJ1aWxkaW5nICRpIGtlcm5lbCIKCQljZCAi JHNyY2RpciIvYnVpbGQtJGkuJENBUkNICgoJCSMgc2V0IG9yZyBpbiBjZXJ0IGZvciBtb2R1bGVz IHNpZ25pbmcKCQkjIGh0dHBzOi8vd3d3Lmtlcm5lbC5vcmcvZG9jL2h0bWwvdjYuMS9hZG1pbi1n dWlkZS9tb2R1bGUtc2lnbmluZy5odG1sI2dlbmVyYXRpbmctc2lnbmluZy1rZXlzCgkJbWtkaXIg LXAgY2VydHMKCQlzZWQgLWUgJ3MvI08gPSBVbnNwZWNpZmllZCBjb21wYW55L08gPSBhbHBpbmVs aW51eC5vcmcvJyBcCgkJCSIkYnVpbGRkaXIiL2NlcnRzL2RlZmF1bHRfeDUwOS5nZW5rZXkgXAoJ CQk+IGNlcnRzL3g1MDkuZ2Vua2V5CgoJCW1ha2UgQVJDSD0iJChfa2VybmVsYXJjaCAkQ0FSQ0gp IiBcCgkJCUNDPSIke0NDOi1nY2N9IiBcCgkJCUFXSz0iJHtBV0s6LW1hd2t9IiBcCgkJCUtCVUlM RF9CVUlMRF9WRVJTSU9OPSIkKChwa2dyZWwgKyAxICkpLUFscGluZSIKCgkJaWYgZ3JlcCAtcSAn XkNPTkZJR19ERUJVR19JTkZPX0JURj15JyAuY29uZmlnOyB0aGVuCgkJCSMgR2VuZXJhdGUgdm1s aW51eC5oCgkJCWJwZnRvb2wgYnRmIGR1bXAgZmlsZSB2bWxpbnV4IGZvcm1hdCBjID4gdm1saW51 eC5oCgoJCQlpZiBbICIkQ0FSQ0giID0gInBwYzY0bGUiIF07IHRoZW4KCQkJCSMgcHBjNjRsZSBp bnN0YWxscyB0aGUgdW5jb21wcmVzc2VkIHZtbGludXgsIHdoaWNoIGlzIGV4dHJlbWVseQoJCQkJ IyBsYXJnZSB3aXRoIEJURiBkZWJ1Z2luZm8gdW5sZXNzIHN0cmlwcGVkCgkJCQlldS1zdHJpcCAt LXJlbW92ZS1jb21tZW50IHZtbGludXgKCQkJZmkKCQlmaQoJZG9uZQp9CgpfcGFja2FnZSgpIHsK CWxvY2FsIF9idWlsZGZsYXZvcj0iJDEiIF9vdXRkaXI9IiQyIgoJc2V0X2tidWlsZF90aW1lc3Rh bXAKCgljZCAiJHNyY2RpciIvYnVpbGQtJF9idWlsZGZsYXZvci4kQ0FSQ0gKCWxvY2FsIF9hYmlf cmVsZWFzZT0iJChtYWtlIC1zIGtlcm5lbHJlbGVhc2UpIgoJIyBtb2R1bGVzX2luc3RhbGwgc2Vl bXMgdG8gcmVnZW5lcmF0ZSBhIGRlZmVjdCBNb2R1bGVzLnN5bXZlcnMgb24gczM5MHguIFdvcmsK CSMgYXJvdW5kIGl0IGJ5IGJhY2tpbmcgaXQgdXAgYW5kIHJlc3RvcmUgaXQgYWZ0ZXIgbW9kdWxl c19pbnN0YWxsCgljcCBNb2R1bGUuc3ltdmVycyBNb2R1bGUuc3ltdmVycy5iYWNrdXAKCglta2Rp ciAtcCAiJF9vdXRkaXIiL2Jvb3QgIiRfb3V0ZGlyIi9saWIvbW9kdWxlcwoKCWxvY2FsIF9pbnN0 YWxsCgljYXNlICIkQ0FSQ0giIGluCgkJYXJtKnxhYXJjaDY0fHJpc2N2KikgX2luc3RhbGw9Inpp bnN0YWxsIGR0YnNfaW5zdGFsbCI7OwoJCSopIF9pbnN0YWxsPWluc3RhbGw7OwoJZXNhYwoKCW1h a2UgbW9kdWxlc19pbnN0YWxsICRfaW5zdGFsbCBcCgkJQVJDSD0iJChfa2VybmVsYXJjaCAkQ0FS Q0gpIiBcCgkJSU5TVEFMTF9NT0RfUEFUSD0iJF9vdXRkaXIiIFwKCQlJTlNUQUxMX01PRF9TVFJJ UD0xIFwKCQlJTlNUQUxMX1BBVEg9IiRfb3V0ZGlyIi9ib290IFwKCQlJTlNUQUxMX0RUQlNfUEFU SD0iJF9vdXRkaXIvYm9vdC9kdGJzLSRfYnVpbGRmbGF2b3IiCgoJY3AgTW9kdWxlLnN5bXZlcnMu YmFja3VwIE1vZHVsZS5zeW12ZXJzCgoJcm0gLWYgIiRfb3V0ZGlyIi9saWIvbW9kdWxlcy8iJF9h YmlfcmVsZWFzZSIvYnVpbGQgXAoJCSIkX291dGRpciIvbGliL21vZHVsZXMvIiRfYWJpX3JlbGVh c2UiL3NvdXJjZQoJcm0gLXJmICIkX291dGRpciIvbGliL2Zpcm13YXJlCgoJaW5zdGFsbCAtRCAt bTY0NCBpbmNsdWRlL2NvbmZpZy9rZXJuZWwucmVsZWFzZSBcCgkJIiRfb3V0ZGlyIi91c3Ivc2hh cmUva2VybmVsLyRfYnVpbGRmbGF2b3Iva2VybmVsLnJlbGVhc2UKCglsbiAtc2YgL2Jvb3Qvdm1s aW51ei0iJF9idWlsZGZsYXZvciIgXAoJCSIkX291dGRpciIvbGliL21vZHVsZXMvIiRfYWJpX3Jl bGVhc2UiL3ZtbGludXoKfQoKIyBtYWluIGZsYXZvciBpbnN0YWxscyBpbiAkcGtnZGlyCnBhY2th Z2UoKSB7CglkZXBlbmRzPSIkZGVwZW5kcyBsaW51eC1maXJtd2FyZS1hbnkiCgoJX3BhY2thZ2Ug IiRfZmxhdm9yIiAiJHBrZ2RpciIKCgkjIGNvcHkgZmlsZXMgZm9yIGxpbnV4LWx0cy1kb2Mgc3Vi IHBhY2thZ2UKCW1rZGlyIC1wICIkcGtnZGlyIi91c3Ivc2hhcmUvZG9jCgljcCAtciAiJGJ1aWxk ZGlyIi9Eb2N1bWVudGF0aW9uIFwKCQkiJHBrZ2RpciIvdXNyL3NoYXJlL2RvYy9saW51eC1kb2Mt IiRwa2d2ZXIiLwoJIyByZW1vdmUgZmlsZXMgdGhhdCBhcmVuJ3QgcGFydCBvZiB0aGUgZG9jdW1l bnRhdGlvbiBpdHNlbGYKCWZvciBub25kb2MgaW4gXAoJCS5naXRpZ25vcmUgY29uZi5weSBkb2N1 dGlscy5jb25mIFwKCQlLY29uZmlnIE1ha2VmaWxlCglkbwoJCXJtICIkcGtnZGlyIi91c3Ivc2hh cmUvZG9jL2xpbnV4LWRvYy0iJHBrZ3ZlciIvIiRub25kb2MiCglkb25lCgkjIGNyZWF0ZSAvdXNy L3NoYXJlL2RvYy9saW51eC1kb2Mgc3ltbGluawoJY2QgIiRwa2dkaXIiL3Vzci9zaGFyZS9kb2M7 IGxuIC1zIGxpbnV4LWRvYy0iJHBrZ3ZlciIgbGludXgtZG9jCn0KCiMgc3ViZmxhdm9ycyBpbnN0 YWxsIGluICRzdWJwa2dkaXIKdmlydCgpIHsKCV9wYWNrYWdlIHZpcnQgIiRzdWJwa2dkaXIiCn0K Cl9kZXYoKSB7Cglsb2NhbCBfZmxhdm9yPSQoZWNobyAkc3VicGtnbmFtZSB8IHNlZCAtRSAncy8o XmxpbnV4LXwtZGV2JCkvL2cnKQoJbG9jYWwgX2J1aWxkZGlyPSIkc3JjZGlyIi9idWlsZC0kX2Zs YXZvci4kQ0FSQ0gKCWxvY2FsIF9hYmlfcmVsZWFzZT0iJChtYWtlIC1DICIkX2J1aWxkZGlyIiAt cyBrZXJuZWxyZWxlYXNlKSIKCWxvY2FsIF9rYXJjaD0iJChfa2VybmVsYXJjaCAkQ0FSQ0ggfCBz ZWQgJ3MveDg2XzY0L3g4Ni8nKSIKCSMgY29weSB0aGUgb25seSB0aGUgcGFydHMgdGhhdCB3ZSBy ZWFsbHkgbmVlZCBmb3IgYnVpbGQgM3JkIHBhcnR5CgkjIGtlcm5lbCBtb2R1bGVzIGFuZCBpbnN0 YWxsIHRob3NlIGFzIC91c3Ivc3JjL2xpbnV4LWhlYWRlcnMsCgkjIHNpbWxhciB0byB3aGF0IHVi dW50dSBkb2VzCgkjCgkjIHRoaXMgd2F5IHlvdSBkb250IG5lZWQgdG8gaW5zdGFsbCB0aGUgMzAw LTQwMCBrZXJuZWwgc291cmNlcyB0bwoJIyBidWlsZCBhIHRpbnkga2VybmVsIG1vZHVsZQoJIwoJ cGtnZGVzYz0iSGVhZGVycyBhbmQgc2NyaXB0IGZvciB0aGlyZCBwYXJ0eSBtb2R1bGVzIGZvciAk X2ZsYXZvciBrZXJuZWwiCglkZXBlbmRzPSIkX2RlcGVuZHNfZGV2IgoJbG9jYWwgZGlyPSIkc3Vi cGtnZGlyIi91c3Ivc3JjL2xpbnV4LWhlYWRlcnMtIiRfYWJpX3JlbGVhc2UiCglzZXRfa2J1aWxk X3RpbWVzdGFtcAoKCSMgZmlyc3Qgd2UgaW1wb3J0IGNvbmZpZywgcnVuIHByZXBhcmUgdG8gc2V0 IHVwIGZvciBidWlsZGluZwoJIyBleHRlcm5hbCBtb2R1bGVzLCBhbmQgY3JlYXRlIHRoZSBzY3Jp cHRzCglta2RpciAtcCAiJGRpciIKCWNwIC1hICIkX2J1aWxkZGlyIi8uY29uZmlnICIkX2J1aWxk ZGlyIi9sb2NhbHZlcnNpb24tYWxwaW5lIFwKCQkiJGRpciIvCgoJaW5zdGFsbCAtRCAtdCAiJGRp ciIvY2VydHMgIiRfYnVpbGRkaXIiL2NlcnRzL3NpZ25pbmdfa2V5Lng1MDkgfHwgOgoKCSMgSW5z dGFsbCB2bWxpbnV4LmgKCWlmIGdyZXAgLXEgJ15DT05GSUdfREVCVUdfSU5GT19CVEY9eScgIiRf YnVpbGRkaXIiLy5jb25maWc7IHRoZW4KCQlpbnN0YWxsIC1EbTY0NCAiJF9idWlsZGRpciIvdm1s aW51eC5oIC10ICIkZGlyLyIKCWZpCgoJbWFrZSAtQyAiJGJ1aWxkZGlyIiBcCgkJTz0iJGRpciIg XAoJCUFSQ0g9IiQoX2tlcm5lbGFyY2ggJENBUkNIKSIgXAoJCUFXSz0iJHtBV0s6LW1hd2t9IiBc CgkJcHJlcGFyZSBtb2R1bGVzX3ByZXBhcmUgc2NyaXB0cwoKCSMgcmVtb3ZlIHRoZSBzdHVmZiB0 aGF0IHBvaW50cyB0byByZWFsIHNvdXJjZXMuIHdlIHdhbnQgM3JkIHBhcnR5CgkjIG1vZHVsZXMg dG8gYmVsaWV2ZSB0aGlzIGlzIHRoZSBzb3VyY2VzCglybSAiJGRpciIvTWFrZWZpbGUgIiRkaXIi L3NvdXJjZQoKCSMgY29weSB0aGUgbmVlZGVkIHN0dWZmIGZyb20gcmVhbCBzb3VyY2VzCgkjCgkj IHRoaXMgaXMgdGFrZW4gZnJvbSB1YnVudHUga2VybmVsIGJ1aWxkIHNjcmlwdAoJIyBodHRwOi8v a2VybmVsLnVidW50dS5jb20vZ2l0L3VidW50dS91YnVudHUtemVzdHkuZ2l0L3RyZWUvZGViaWFu L3J1bGVzLmQvMy1iaW5hcnktaW5kZXAubWsKCWNkICIkYnVpbGRkaXIiCglmaW5kIC4gIC1wYXRo ICcuL2luY2x1ZGUvKicgLXBydW5lIFwKCQktbyAtcGF0aCAnLi9zY3JpcHRzLyonIC1wcnVuZSAt byAtdHlwZSBmIFwKCQlcKCAtbmFtZSAnTWFrZWZpbGUqJyAtbyAtbmFtZSAnS2NvbmZpZyonIC1v IC1uYW1lICdLYnVpbGQqJyAtbyBcCgkJICAgLW5hbWUgJyouc2gnIC1vIC1uYW1lICcqLnBsJyAt byAtbmFtZSAnKi5sZHMnIC1vIC1uYW1lICdQbGF0Zm9ybScgXCkgXAoJCS1wcmludCB8IGNwaW8g LXBkbSAiJGRpciIKCgljcCAtYSBzY3JpcHRzIGluY2x1ZGUgIiRkaXIiCgoJZmluZCAiYXJjaC8k X2thcmNoIiAidG9vbHMvaW5jbHVkZSIgInRvb2xzL2FyY2gvJF9rYXJjaCIgLXR5cGUgZiAtcGF0 aCAnKi9pbmNsdWRlLyonIFwKCQktcHJpbnQgfCBjcGlvIC1wZG0gIiRkaXIiCgoJaW5zdGFsbCAt RG02NDQgIiRzcmNkaXIiL2J1aWxkLSRfZmxhdm9yLiRDQVJDSC9Nb2R1bGUuc3ltdmVycyBcCgkJ IiRkaXIiL01vZHVsZS5zeW12ZXJzCgoJIyByZW1vdmUgdW5uZWVkZWQgdGhpbmdzCgltc2cgIlJl bW92aW5nIGRvY3VtZW50YXRpb24uLi4iCglybSAtciAiJGRpciIvRG9jdW1lbnRhdGlvbgoJc2Vk IC1pIC1lICcvRG9jdW1lbnRhdGlvbi9kJyAiJGRpciIvS2NvbmZpZwoJZmluZCAiJGRpciIgLXR5 cGUgZiBcKCAtbmFtZSAnKi5vJyAtbyAtbmFtZSAnKi5jbWQnIFwpIC1leGVjIHJtIC12IC0tIHt9 ICsKCglta2RpciAtcCAiJHN1YnBrZ2RpciIvbGliL21vZHVsZXMvIiRfYWJpX3JlbGVhc2UiCgls biAtc2YgL3Vzci9zcmMvbGludXgtaGVhZGVycy0iJF9hYmlfcmVsZWFzZSIgXAoJCSIkc3VicGtn ZGlyIi9saWIvbW9kdWxlcy8iJF9hYmlfcmVsZWFzZSIvYnVpbGQKfQoKc2hhNTEyc3Vtcz0iCmYx YzMyMzAzYThlYjdmMjBjN2Y1YzhkNTkyYTIzMTQwZmY4ODAwNzVkMGU0MTUxYmY5NmQ1YjAzNjVm ZjY0YjM1MzI0NzUzODk0ZDhiYTgyMmFkNzk3ZTY3M2IyYTg3OGYxOGQ2YTJmNTU3ZGQ2ZDNhY2Ex ZmNjOGQ0ZTU3NjRkICBwYXRjaC02LjE4LjUyLnBhdGNoLnh6Cjg4NTk5ZmZkZWM5NmQxNTBjMWZl YjliMjYxYmE5M2JiMDMwMWE5ZDBlMWFkNmJlZjdhZWFiMWY1MzcyY2JmYzU3ZDhiNDNjN2U5MDJi ZDhmNzY5MjFkMWRiZDgxODk2NjNjMTQyZWE4NjllNTFkMGUyYjQ4M2IxNTBlZTAwZmUwICBsaW51 eC02LjE4LnRhci54egpiMjk2NzE3ZWYwY2Q2Mzk3ODE0MmI0ZDQ3YjNiYzQ5ZmFhMDRkYWY3N2Ux MTVlNzAyYmE2MTFjYzI1NGE2ZTc4MmNkYWI3ZDU2MzllNzI0Y2Q1ZjAyOWNmYjZhM2RjMzNjMzAz NmYzNDZkNjgxZDFmZGZlMGRmNzIzYzdlMDMyMSAgMDAwMS1wb3dlcnBjLWJvb3Qtd3JhcHBlci1B ZGQtei1ub3RleHQtZmxhZy1mb3ItcHBjNjRsZS5wYXRjaAowNTVlMTBlN2IzZTAwYmIzNjIxMzg5 MzE1ZDUyMDZhOGZlYjUwMjJhMWYwZGM1MWMzYWExMDdmYWNmZTgzZDE5MWRhMDVhNTAyYTBjNjI0 ODhiZTcyOTk2NzdhNjNjMWRhODRmODdjNDJjYmYzMTI1Nzg4YzU2ZGI2N2U4MTBlZSAgMDAwMi14 ODYtQ29tcHJlc3Mtdm1saW51eC13aXRoLXpzdGQtMTktaW5zdGVhZC1vZi0yMi5wYXRjaAplMWQy ZDUzNThmNWI4MTg5MjM2MTA4OTczMzk1ZjAwZWFmY2U4ZGI2ZDViYWFmNTUwMjViMTM2MGYwOGFi N2NmZmM5MzBkMzgxODcxOWYyMjBiOThlN2U4NTQxY2M4YTdmMDU2NjExYjZlMjkwZjIyNGExMDJj MWFkZGJlMzRhYyAgMDAwMy1rZXhlYy1hZGQta2V4ZWNfbG9hZF9kaXNhYmxlZC1ib290LW9wdGlv bi5wYXRjaAoyOGM4M2JlNGM5NzE1MjAwMTM4MWNkNWUzYThhY2I4NTUyYTQyZDlkYWM5YWFlYzhm MDk2ZTM3NjJiNzk0NDAzNWFhNWE0MzYzZmI0NjAyZjliYjQyN2M0ZjcyY2ZkMmY5OTZhMGE3MjVm N2Y5ZTA3YWIyNTAzMTc5ODVhZmY5ZSAgMDAwNC1vYmp0b29sLXJlc3BlY3QtQVdLLXNldHRpbmcu cGF0Y2gKNWNlNzk0MTZmOGYxMTFjMzYzOTM3MTg2NTZlM2VlYjRjYjBhZGNjZDExN2RjZjY2MTg3 NmQxNTY0MDEwZTVjNThiNjM1MWNjNDExNmQxODdkMGE5YTgzOGJjY2EwZmVjYzIzNmQ4MWFjNzFh ZmI5NDBiODljY2IxNGYyMWUxNzkgIDAwMDUtcG93ZXJwYy1jb25maWctZGVmYW5nLWdjYy1jaGVj ay1mb3Itc3RhY2stcHJvdGVjdG9yLS5wYXRjaAo0ZTcyYWY4ZTc3YTU1NWQyYTg1MDgzN2I2NGE1 MjVhNTFkNWQxMTgwNDg1ODRkYzNlYTBkMGU4NjIwYmI1NmJmNTZiNjlhOTRhYTY3ZGFjODc5Yjg0 MWM5YmEwMzNlMzNkOTQ2MTBkYTAwMjhmZGU3YjY2MDJhZDJmZTYzZjAyZiAgMDAwMS14ODYtQ1BV LUFNRC1hdm9pZC1wcmludGluZy1yZXNldC1yZWFzb25zLW9uLVhlbi1kb21VLnBhdGNoCmY1Yzlj OTllNjM3ZWI0N2M1ODJlMmRiNTdjMjYwOWJlODAzYzZkNjAzNzcxN2E5NDlhMGRkMTgxYmE1MGNk NGVhMTk2NzhkYTgxZGVkOWRlNzM3ZTE2NjljYTgxZjM3MWE0ODA5MjU4YTcxZWI3ZmVmNzNlNDYy MTJiMWNkZmFiICByZXZlcnQtYWNwaS1pZGxlLXJlZ2lzdHJhdGlvbi1saWZlY3ljbGUucGF0Y2gK ODU1NTIyYjgxNmJiYjJiMDczODI1MWNmMjQ3MTRjMjU2NmM3YWFjYWQzOWFhZjZhZGNlYmQwYTI1 NmQxMWY2NGZmMjc2MmVjZGFjZTBhYjFiYWMzOGRiODdmZDU3OTg2M2Y4NTJmNzk5MzU2YTM2OGYw NTdjMTY2ZTRkZWIwM2MgIHNvcGhnby1maXhlcy5wYXRjaApmYzY5MTU4ZDMxZDlkM2M5NTFkMDU3 YWVlMDEzOTdmNDZjNWE3MjQ2MjMzNGYxNGI3OWFhNTM4Mjk0YzE5MDAzMzhiYzZhZjE1NGM5YmRh MDUxZmIyOWVmZjExNTQxZDhjMTg5M2Q3MzVhMTJiN2JhZmI4NmNkYjBmOThhNTQ4NSAgbHRzLmFh cmNoNjQuY29uZmlnCmU4MDM2ZGM3Yjc0ZmZhMDlmODRjMGQxMzI0NmE2MzdhYTczMjZkZjNkYTM3 MjlhMTU4MTc3YmU5YjQ3MDM2ZmYwNmQ1ZGVkMjg4NmI1NjdiNTVmYWM0NGRjYjkzN2NhNzI3MTc1 MWNhNWRjNWE3YmZlZDVhOTFkZjFlY2FmNGNlICBsdHMuYXJtdjcuY29uZmlnCjZiMmFmODgxNjcy MzQ4MjhjOTc5M2FlZWZjOGNjYzBlZDVhZTdkNjgxNGJiYWZmMzBhOTFjMGIzMzZiOTVlMjAwODY5 NzYwOGM5NjMwZTg1MDdhNDkzZTAyZDNhN2ZjNzk4ZTQ5MDQ2N2VhYzk2OWVkZTE0ZGI5YjkyZTIx ZTE3ICBsdHMubG9vbmdhcmNoNjQuY29uZmlnCjc3YTg0YThhM2IxYWUyODlmZTg4YWVmOTE4M2Yy ZWFmYzQ5Mzc5ZjU1ZTc3NDU3MDA1MzQ4MDFhNTZjMGY3ZjBkOTAwYWYxOWEyMzFkMjVlNDhjN2Fj YWI0NmYyM2E4OGRmMTUwNDRkOWVmZTRmZjE2ODgxYzQzOTg0Y2RjNDBjICBsdHMucHBjNjRsZS5j b25maWcKMmJmMTA2Y2Q3ZGRjMDRkY2I2OWM2OWFlNzNlOWExZjk1Yjk2NDE5MDMwMWMyNzI4NTZl YTdlZTY4ODIwZDc3YWNlYWE5MGVkZWRhNzQxZGEwZWM5MzU1ZmM5NDJhZDk2NDdlZjNlM2M0OWIy MzI0NTVkOTNhNGY3MjdiOGJjZDkgIGx0cy5yaXNjdjY0LmNvbmZpZwozNDYyMmIwMmJhZjA1YWM5 ZjlkZmEzY2JjZDgxNzM2OGI5ZWEwYmMyMDU2YTU1ZTRjYWI3NzBlMGUwMTAwZjhjZGM5ZGRiMGI2 OGJiZGZlMzgxZjZmM2Q4YjFhODFiYmQ1NWY1NmRiNDNhODI0YjY5MWY4Nzg4OTA3ZWQ2ZmEyMyAg bHRzLnMzOTB4LmNvbmZpZwozMzkwM2UzYTg3NzczNGFiNWYzZmQyYjAzNTg5ODE3ZGM5OTZmNTEx NGU2NmEzNGFiZTMwYWUxMzdiNjFkZTY5NjA0NzhmZDRkMzMxNzRkYTMxOTkzOWJmNGI3N2Q3YWJh ODA5Y2NmNTU2NmFjZjQ2OTQ2ZmNhNDc2ZjAzZTM1ZiAgbHRzLng4Ni5jb25maWcKMzJkYjEwMDYw OTg3NjU0YzUxNTM0MmVhYmFkOTlmZjY4NDcxYWNhNzM5MTU5YTZkY2JmNzliMjE1N2UwZGJlMTUx MzhiZTY3YmQyNWFjZjMyNmVhZTEzZTE3OTBmMDdjNzdmMTc5ZTNmMjFmOWJhOWZmZDM0MGE5MTAw NmQ1Y2QgIGx0cy54ODZfNjQuY29uZmlnCmZmYmU2MTA2OTE4NGE0NmJhZjkwY2JmZmViYTU1MTJk ZjdlMGQwYjExYzI0MDRmNjI5YWQ2OThiZGZiNjE5OTI2OTYxODAxM2FiZGMyODk1YTliYzk2MGJi NWUwNDI1ZWU0ZjhhOTI4ZmNhMDhhYWU1YjVmZjk3ZTQ5MDIzZTNmICB2aXJ0LmFhcmNoNjQuY29u ZmlnCjc3YjZkZmU2NjVkZGQzYTg5NmE0YTllNzgwN2Q2ZDJhZmY3ZDMyNzBlYjk4YTczNDJjZDA4 YTUzMDQ0NDZhNjJkNDc1NWFkODBlNWEwZGY0MDRlMTgwOTczOGY1YjllODIyMDE3NDMyODljMzM0 ODk5MzA3NGQ3MjNiNTk5MGMxICB2aXJ0LmFybXY3LmNvbmZpZwo3MTQ1NjQ0ZjI5NTBmZjE2YTE1 ODA2MGNiNDI2NjQzMWIzZjY5NmJmYmEyM2JjODRkNTcwZTgxMzU4ODkwMjRmM2U5MmNkZWFjNjFi ZGY0ZmY0OTBjZjBlNmYwMDY1Y2E3ZWJkMDUwOGVmZmY2YTkxZTFlYWI4ZTZmNjU1ZWVmNCAgdmly dC5wcGM2NGxlLmNvbmZpZwo2YWNjNmQzZTU0YTcwZWI4Y2ZjMzVkYTgyNDU4OWFkNDUxNjdjMTM4 MGUwYzRhMDFiYzQ3OWY5NjVhMjRkZTljMDdlYzE3YzdlNWJhMDQ1YTljZTBhMTFhNzg1OGZmMTY1 OWVhYzk4ODhlYmI2MTc0YzZiZGQzNDFlNTE0YjgzNCAgdmlydC54ODYuY29uZmlnCjBkYTM0ZmQ4 NjdmNzk3MDA0MzY5ZTc1MTU3ZTc2NDYwNDA5M2QxYWU5NTdmYzY4NmZlMjM0M2VjYjMwYTI3MWJj NWMwYWQ4NzY1MjZmZTU5NTRjZjViZjZlM2FmZmI3MWRiYTNhODAyZjkwODkyNzFjZDUxZTFjMmZh NDExMjAxICB2aXJ0Lng4Nl82NC5jb25maWcKIgo= ------=_Part_272724280_77477482.1789919301849 Content-Type: text/x-diff; name=revert-acpi-idle-registration-lifecycle.patch Content-Disposition: attachment; filename=revert-acpi-idle-registration-lifecycle.patch Content-Transfer-Encoding: base64 UmV2ZXJ0IHRoZSBBQ1BJIGlkbGUgZHJpdmVyIHJlZ2lzdHJhdGlvbiBsaWZlY3ljbGUgaW50cm9k dWNlZCBieSB1cHN0cmVhbQpjb21taXQgMTNlYmVlZjZhMWI5ICgiQUNQSTogcHJvY2Vzc29yOiBp ZGxlOiBPcHRpbWl6ZSBBQ1BJIGlkbGUgZHJpdmVyCnJlZ2lzdHJhdGlvbiIpLgoKVGhhdCBjaGFu Z2UgbW92ZWQgQUNQSSBpZGxlIGRyaXZlciByZWdpc3RyYXRpb24gb3V0IG9mCmFjcGlfcHJvY2Vz c29yX3Bvd2VyX2luaXQoKSBhbmQgYWhlYWQgb2YgZHJpdmVyX3JlZ2lzdGVyKCkuIFRoaXMgYnJl YWtzIHRoZQplc3RhYmxpc2hlZCBsaWZlY3ljbGUgb24gWGVuIGRvbTAsIHdoZXJlIGNwdWlkbGUg aXMgZGlzYWJsZWQgZHVyaW5nIGVhcmx5CmFyY2hpdGVjdHVyZSBzZXR1cC4gUmVzdG9yZSB0aGUg Ni4xOC41MSBwZXItcHJvY2Vzc29yIHJlZ2lzdHJhdGlvbiBiZWhhdmlvci4KCktlZXAgdW5yZWxh dGVkIDYuMTguNTIgZml4ZXMsIG5vdGFibHkgX0xQSSBib3VuZHMgdmFsaWRhdGlvbiBhbmQgY3B1 ZnJlcQpub3RpZmllciBjbGVhbnVwIG9uIGluaXRpYWxpemF0aW9uIGZhaWx1cmUuCgpkaWZmIC0t Z2l0IGEvZHJpdmVycy9hY3BpL3Byb2Nlc3Nvcl9kcml2ZXIuYyBiL2RyaXZlcnMvYWNwaS9wcm9j ZXNzb3JfZHJpdmVyLmMKaW5kZXggMDY1ODliZjQ4Li4xNzRkZmIwYWMgMTAwNjQ0Ci0tLSBhL2Ry aXZlcnMvYWNwaS9wcm9jZXNzb3JfZHJpdmVyLmMKKysrIGIvZHJpdmVycy9hY3BpL3Byb2Nlc3Nv cl9kcml2ZXIuYwpAQCAtMjU5LDExICsyNTksOSBAQCBzdGF0aWMgaW50IF9faW5pdCBhY3BpX3By b2Nlc3Nvcl9kcml2ZXJfaW5pdCh2b2lkKQogCQlhY3BpX3Byb2Nlc3Nvcl9pZ25vcmVfcHBjX2lu aXQoKTsKIAl9CiAKLQlhY3BpX3Byb2Nlc3Nvcl9yZWdpc3Rlcl9pZGxlX2RyaXZlcigpOwotCiAJ cmVzdWx0ID0gZHJpdmVyX3JlZ2lzdGVyKCZhY3BpX3Byb2Nlc3Nvcl9kcml2ZXIpOwogCWlmIChy ZXN1bHQgPCAwKQotCQlnb3RvIHVucmVnaXN0ZXJfaWRsZV9kcnY7CisJCWdvdG8gdW5yZWdpc3Rl cl9jcHVmcmVxOwogCiAJcmVzdWx0ID0gY3B1aHBfc2V0dXBfc3RhdGUoQ1BVSFBfQVBfT05MSU5F X0RZTiwKIAkJCQkgICAiYWNwaS9jcHUtZHJ2Om9ubGluZSIsCkBAIC0yODksOSArMjg3LDcgQEAg c3RhdGljIGludCBfX2luaXQgYWNwaV9wcm9jZXNzb3JfZHJpdmVyX2luaXQodm9pZCkKIGVycjoK IAlkcml2ZXJfdW5yZWdpc3RlcigmYWNwaV9wcm9jZXNzb3JfZHJpdmVyKTsKIAotdW5yZWdpc3Rl cl9pZGxlX2RydjoKLQlhY3BpX3Byb2Nlc3Nvcl91bnJlZ2lzdGVyX2lkbGVfZHJpdmVyKCk7Ci0K K3VucmVnaXN0ZXJfY3B1ZnJlcToKIAlpZiAoYWNwaV9wcm9jZXNzb3JfY3B1ZnJlcV9pbml0KSB7 CiAJCWNwdWZyZXFfdW5yZWdpc3Rlcl9ub3RpZmllcigmYWNwaV9wcm9jZXNzb3Jfbm90aWZpZXJf YmxvY2ssCiAJCQkJCSAgICBDUFVGUkVRX1BPTElDWV9OT1RJRklFUik7CkBAIC0zMTUsNyArMzEx LDYgQEAgc3RhdGljIHZvaWQgX19leGl0IGFjcGlfcHJvY2Vzc29yX2RyaXZlcl9leGl0KHZvaWQp CiAJY3B1aHBfcmVtb3ZlX3N0YXRlX25vY2FsbHMoaHBfb25saW5lKTsKIAljcHVocF9yZW1vdmVf c3RhdGVfbm9jYWxscyhDUFVIUF9BQ1BJX0NQVURSVl9ERUFEKTsKIAlkcml2ZXJfdW5yZWdpc3Rl cigmYWNwaV9wcm9jZXNzb3JfZHJpdmVyKTsKLQlhY3BpX3Byb2Nlc3Nvcl91bnJlZ2lzdGVyX2lk bGVfZHJpdmVyKCk7CiB9CiAKIG1vZHVsZV9pbml0KGFjcGlfcHJvY2Vzc29yX2RyaXZlcl9pbml0 KTsKZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfaWRsZS5jIGIvZHJpdmVycy9h Y3BpL3Byb2Nlc3Nvcl9pZGxlLmMKaW5kZXggNWM2ZjczNmJhLi43YjRlOTQ4ZmEgMTAwNjQ0Ci0t LSBhL2RyaXZlcnMvYWNwaS9wcm9jZXNzb3JfaWRsZS5jCisrKyBiL2RyaXZlcnMvYWNwaS9wcm9j ZXNzb3JfaWRsZS5jCkBAIC04MzEsMTMgKzgzMSwxOSBAQCBzdGF0aWMgaW50IGFjcGlfcHJvY2Vz c29yX3NldHVwX2NzdGF0ZXMoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwcikKIAlyZXR1cm4gMDsK IH0KIAotc3RhdGljIGlubGluZSB2b2lkIGFjcGlfcHJvY2Vzc29yX3VwZGF0ZV9tYXhfY3N0YXRl KHZvaWQpCitzdGF0aWMgaW5saW5lIHZvaWQgYWNwaV9wcm9jZXNzb3JfY3N0YXRlX2ZpcnN0X3J1 bl9jaGVja3Modm9pZCkKIHsKKwlzdGF0aWMgaW50IGZpcnN0X3J1bjsKKworCWlmIChmaXJzdF9y dW4pCisJCXJldHVybjsKIAlkbWlfY2hlY2tfc3lzdGVtKHByb2Nlc3Nvcl9wb3dlcl9kbWlfdGFi bGUpOwogCW1heF9jc3RhdGUgPSBhY3BpX3Byb2Nlc3Nvcl9jc3RhdGVfY2hlY2sobWF4X2NzdGF0 ZSk7CiAJaWYgKG1heF9jc3RhdGUgPCBBQ1BJX0NfU1RBVEVTX01BWCkKIAkJcHJfbm90aWNlKCJw cm9jZXNzb3IgbGltaXRlZCB0byBtYXggQy1zdGF0ZSAlZFxuIiwgbWF4X2NzdGF0ZSk7CiAKKwlm aXJzdF9ydW4rKzsKKwogCWlmIChub2NzdCkKIAkJcmV0dXJuOwogCkBAIC04NDYsNyArODUyLDcg QEAgc3RhdGljIGlubGluZSB2b2lkIGFjcGlfcHJvY2Vzc29yX3VwZGF0ZV9tYXhfY3N0YXRlKHZv aWQpCiAjZWxzZQogCiBzdGF0aWMgaW5saW5lIGludCBkaXNhYmxlZF9ieV9pZGxlX2Jvb3RfcGFy YW0odm9pZCkgeyByZXR1cm4gMDsgfQotc3RhdGljIGlubGluZSB2b2lkIGFjcGlfcHJvY2Vzc29y X3VwZGF0ZV9tYXhfY3N0YXRlKHZvaWQpIHsgfQorc3RhdGljIGlubGluZSB2b2lkIGFjcGlfcHJv Y2Vzc29yX2NzdGF0ZV9maXJzdF9ydW5fY2hlY2tzKHZvaWQpIHsgfQogc3RhdGljIGludCBhY3Bp X3Byb2Nlc3Nvcl9nZXRfY3N0YXRlX2luZm8oc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwcikKIHsK IAlyZXR1cm4gLUVOT0RFVjsKQEAgLTEzNjUsNTkgKzEzNzEsNyBAQCBpbnQgYWNwaV9wcm9jZXNz b3JfcG93ZXJfc3RhdGVfaGFzX2NoYW5nZWQoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwcikKIAly ZXR1cm4gMDsKIH0KIAotdm9pZCBhY3BpX3Byb2Nlc3Nvcl9yZWdpc3Rlcl9pZGxlX2RyaXZlcih2 b2lkKQotewotCXN0cnVjdCBhY3BpX3Byb2Nlc3NvciAqcHI7Ci0JaW50IHJldCA9IC1FTk9ERVY7 Ci0JaW50IGNwdTsKLQotCS8qCi0JICogSWYgYSBjcHVpZGxlIGRyaXZlciBpcyBhbHJlYWR5IHJl Z2lzdGVyZWQsIHRoZXJlIGlzIG5vIG5lZWQgdG8KLQkgKiBldmFsdWF0ZSBfQ1NUIG9yIGF0dGVt cHQgdG8gcmVnaXN0ZXIgdGhlIEFDUEkgaWRsZSBkcml2ZXIuCi0JICovCi0JaWYgKGNwdWlkbGVf Z2V0X2RyaXZlcigpKSB7Ci0JCXByX2RlYnVnKCJjcHVpZGxlIGRyaXZlciAlcFMgYWxyZWFkeSBy ZWdpc3RlcmVkLlxuIiwgY3B1aWRsZV9nZXRfZHJpdmVyKCkpOwotCQlyZXR1cm47Ci0JfQotCi0J YWNwaV9wcm9jZXNzb3JfdXBkYXRlX21heF9jc3RhdGUoKTsKLQotCS8qCi0JICogQUNQSSBpZGxl IGRyaXZlciBpcyB1c2VkIGJ5IGFsbCBwb3NzaWJsZSBDUFVzLgotCSAqIFVzZSB0aGUgcHJvY2Vz c29yIHBvd2VyIGluZm8gb2Ygb25lIGluIHRoZW0gdG8gc2V0IHVwIGlkbGUgc3RhdGVzLgotCSAq IE5vdGUgdGhhdCB0aGUgZXhpc3RpbmcgaWRsZSBoYW5kbGVyIHdpbGwgYmUgdXNlZCBvbiBwbGF0 Zm9ybXMgdGhhdAotCSAqIG9ubHkgc3VwcG9ydCBDMS4KLQkgKi8KLQlmb3JfZWFjaF9wb3NzaWJs ZV9jcHUoY3B1KSB7Ci0JCXByID0gcGVyX2NwdShwcm9jZXNzb3JzLCBjcHUpOwotCQlpZiAoIXBy KQotCQkJY29udGludWU7Ci0KLQkJcmV0ID0gYWNwaV9wcm9jZXNzb3JfZ2V0X3Bvd2VyX2luZm8o cHIpOwotCQlpZiAoIXJldCkgewotCQkJcHItPmZsYWdzLnBvd2VyX3NldHVwX2RvbmUgPSAxOwot CQkJYWNwaV9wcm9jZXNzb3Jfc2V0dXBfY3B1aWRsZV9zdGF0ZXMocHIpOwotCQkJYnJlYWs7Ci0J CX0KLQl9Ci0KLQlpZiAocmV0KSB7Ci0JCXByX2RlYnVnKCJObyBBQ1BJIHBvd2VyIGluZm9ybWF0 aW9uIGZyb20gYW55IENQVXMuXG4iKTsKLQkJcmV0dXJuOwotCX0KLQotCXJldCA9IGNwdWlkbGVf cmVnaXN0ZXJfZHJpdmVyKCZhY3BpX2lkbGVfZHJpdmVyKTsKLQlpZiAocmV0KSB7Ci0JCXByX2Rl YnVnKCJyZWdpc3RlciAlcyBmYWlsZWQuXG4iLCBhY3BpX2lkbGVfZHJpdmVyLm5hbWUpOwotCQly ZXR1cm47Ci0JfQotCXByX2RlYnVnKCIlcyByZWdpc3RlcmVkIHdpdGggY3B1aWRsZS5cbiIsIGFj cGlfaWRsZV9kcml2ZXIubmFtZSk7Ci19Ci0KLXZvaWQgYWNwaV9wcm9jZXNzb3JfdW5yZWdpc3Rl cl9pZGxlX2RyaXZlcih2b2lkKQotewotCWNwdWlkbGVfdW5yZWdpc3Rlcl9kcml2ZXIoJmFjcGlf aWRsZV9kcml2ZXIpOwotfQorc3RhdGljIGludCBhY3BpX3Byb2Nlc3Nvcl9yZWdpc3RlcmVkOwog CiBpbnQgYWNwaV9wcm9jZXNzb3JfcG93ZXJfaW5pdChzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnBy KQogewpAQCAtMTQyNywxMCArMTM4MSwyNyBAQCBpbnQgYWNwaV9wcm9jZXNzb3JfcG93ZXJfaW5p dChzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByKQogCWlmIChkaXNhYmxlZF9ieV9pZGxlX2Jvb3Rf cGFyYW0oKSkKIAkJcmV0dXJuIDA7CiAKKwlhY3BpX3Byb2Nlc3Nvcl9jc3RhdGVfZmlyc3RfcnVu X2NoZWNrcygpOworCiAJaWYgKCFhY3BpX3Byb2Nlc3Nvcl9nZXRfcG93ZXJfaW5mbyhwcikpCiAJ CXByLT5mbGFncy5wb3dlcl9zZXR1cF9kb25lID0gMTsKIAorCS8qCisJICogSW5zdGFsbCB0aGUg aWRsZSBoYW5kbGVyIGlmIHByb2Nlc3NvciBwb3dlciBtYW5hZ2VtZW50IGlzIHN1cHBvcnRlZC4K KwkgKiBOb3RlIHRoYXQgdGhlIGV4aXN0aW5nIGlkbGUgaGFuZGxlciBpcyB1c2VkIG9uIHBsYXRm b3JtcyB0aGF0IG9ubHkKKwkgKiBzdXBwb3J0IEMxLgorCSAqLwogCWlmIChwci0+ZmxhZ3MucG93 ZXIpIHsKKwkJLyogUmVnaXN0ZXIgYWNwaV9pZGxlX2RyaXZlciBpZiBub3QgYWxyZWFkeSByZWdp c3RlcmVkICovCisJCWlmICghYWNwaV9wcm9jZXNzb3JfcmVnaXN0ZXJlZCkgeworCQkJYWNwaV9w cm9jZXNzb3Jfc2V0dXBfY3B1aWRsZV9zdGF0ZXMocHIpOworCQkJcmV0dmFsID0gY3B1aWRsZV9y ZWdpc3Rlcl9kcml2ZXIoJmFjcGlfaWRsZV9kcml2ZXIpOworCQkJaWYgKHJldHZhbCkKKwkJCQly ZXR1cm4gcmV0dmFsOworCQkJcHJfZGVidWcoIiVzIHJlZ2lzdGVyZWQgd2l0aCBjcHVpZGxlXG4i LAorCQkJCSBhY3BpX2lkbGVfZHJpdmVyLm5hbWUpOworCQl9CisKIAkJZGV2ID0ga3phbGxvYyhz aXplb2YoKmRldiksIEdGUF9LRVJORUwpOwogCQlpZiAoIWRldikKIAkJCXJldHVybiAtRU5PTUVN OwpAQCAtMTQ0MywxMSArMTQxNCwxNCBAQCBpbnQgYWNwaV9wcm9jZXNzb3JfcG93ZXJfaW5pdChz dHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByKQogCQkgKi8KIAkJcmV0dmFsID0gY3B1aWRsZV9yZWdp c3Rlcl9kZXZpY2UoZGV2KTsKIAkJaWYgKHJldHZhbCkgeworCQkJaWYgKGFjcGlfcHJvY2Vzc29y X3JlZ2lzdGVyZWQgPT0gMCkKKwkJCQljcHVpZGxlX3VucmVnaXN0ZXJfZHJpdmVyKCZhY3BpX2lk bGVfZHJpdmVyKTsKIAogCQkJcGVyX2NwdShhY3BpX2NwdWlkbGVfZGV2aWNlLCBwci0+aWQpID0g TlVMTDsKIAkJCWtmcmVlKGRldik7CiAJCQlyZXR1cm4gcmV0dmFsOwogCQl9CisJCWFjcGlfcHJv Y2Vzc29yX3JlZ2lzdGVyZWQrKzsKIAl9CiAJcmV0dXJuIDA7CiB9CkBAIC0xNDYxLDYgKzE0MzUs MTAgQEAgaW50IGFjcGlfcHJvY2Vzc29yX3Bvd2VyX2V4aXQoc3RydWN0IGFjcGlfcHJvY2Vzc29y ICpwcikKIAogCWlmIChwci0+ZmxhZ3MucG93ZXIpIHsKIAkJY3B1aWRsZV91bnJlZ2lzdGVyX2Rl dmljZShkZXYpOworCQlhY3BpX3Byb2Nlc3Nvcl9yZWdpc3RlcmVkLS07CisJCWlmIChhY3BpX3By b2Nlc3Nvcl9yZWdpc3RlcmVkID09IDApCisJCQljcHVpZGxlX3VucmVnaXN0ZXJfZHJpdmVyKCZh Y3BpX2lkbGVfZHJpdmVyKTsKKwogCQlrZnJlZShkZXYpOwogCX0KIApkaWZmIC0tZ2l0IGEvaW5j bHVkZS9hY3BpL3Byb2Nlc3Nvci5oIGIvaW5jbHVkZS9hY3BpL3Byb2Nlc3Nvci5oCmluZGV4IGZm ODY0YzFjZS4uZDBlY2NiZDkyIDEwMDY0NAotLS0gYS9pbmNsdWRlL2FjcGkvcHJvY2Vzc29yLmgK KysrIGIvaW5jbHVkZS9hY3BpL3Byb2Nlc3Nvci5oCkBAIC00MjMsOCArNDIzLDYgQEAgaW50IGFj cGlfcHJvY2Vzc29yX3Bvd2VyX2luaXQoc3RydWN0IGFjcGlfcHJvY2Vzc29yICpwcik7CiBpbnQg YWNwaV9wcm9jZXNzb3JfcG93ZXJfZXhpdChzdHJ1Y3QgYWNwaV9wcm9jZXNzb3IgKnByKTsKIGlu dCBhY3BpX3Byb2Nlc3Nvcl9wb3dlcl9zdGF0ZV9oYXNfY2hhbmdlZChzdHJ1Y3QgYWNwaV9wcm9j ZXNzb3IgKnByKTsKIGludCBhY3BpX3Byb2Nlc3Nvcl9ob3RwbHVnKHN0cnVjdCBhY3BpX3Byb2Nl c3NvciAqcHIpOwotdm9pZCBhY3BpX3Byb2Nlc3Nvcl9yZWdpc3Rlcl9pZGxlX2RyaXZlcih2b2lk KTsKLXZvaWQgYWNwaV9wcm9jZXNzb3JfdW5yZWdpc3Rlcl9pZGxlX2RyaXZlcih2b2lkKTsKICNl bHNlCiBzdGF0aWMgaW5saW5lIGludCBhY3BpX3Byb2Nlc3Nvcl9wb3dlcl9pbml0KHN0cnVjdCBh Y3BpX3Byb2Nlc3NvciAqcHIpCiB7Cgo= ------=_Part_272724280_77477482.1789919301849-- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 05:30:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 05:30:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427083.1649717 (Exim 4.92) (envelope-from ) id 1x8WbS-0007y9-4i; Mon, 21 Sep 2026 05:30:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427083.1649717; Mon, 21 Sep 2026 05:30:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8WbS-0007y2-1h; Mon, 21 Sep 2026 05:30:10 +0000 Received: by outflank-mailman (input) for mailman id 1427083; Mon, 21 Sep 2026 05:30:08 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8WbQ-0007xw-Kj for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 05:30:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8WbP-005UFM-Nz for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 07:30:07 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0c0c5-2eae-0a2a0a5409dd-0a2a4505c29c-12 for ; Mon, 21 Sep 2026 07:30:07 +0200 Received: from [52.101.61.1] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0c0db-4cb1-0a2a45050019-34653d018eee-3 for ; Mon, 21 Sep 2026 07:30:04 +0200 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by DM4PR03MB6936.namprd03.prod.outlook.com (2603:10b6:8:48::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 05:29:31 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%5]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 05:29:31 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dyzml29YmQDf5slJAdv80yxAFwrT902mNoECEA4OhMbczlmWMgM1+IS2kb3VRwUun8JXEU5mSz/37QBvKRhB8cwI/jV7kRFiv+cp4OsIRwIQ0McxhephGnObC7u6nh7uTewsXgv+IVbjhdvlp33tUBw+QEADrnERK1QRYFLroCQ2rk1ykagMek3u/nnzuQkQNJEuq1esxa0DU4zgWooBqyMKnE3Q97VTXbz2oAF7T7jibKeZ5SuJyoWMUAGhAfEalhWSe//sRQPQowJc2QSfE1CDeFexvm2nW3UgSsOcrK3RGqidI/EzALQfHzCduFfKzWsuFUrs7bH/JgHLJpPEBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kzsOpapdRzQqFqWrZYgLA7mNlw9zTY9QDIWtDtt1w38=; b=xQQAoiuPKB/XbpZJqoEKexYTNRjKhS5NBhSRoOIFcIlHx6qUWPr9AgSGemiqY86FFGnubuE1DcWvDciBVj4MuGe9wC9iyUWwD842iMUQ2sCCUHnUCehXqA2VOZPF+VHmSViF08O/OCkJuy+azjfhTZ9D79yo7OEi7qLJaD6X13G7WT1b8QWWLJwQBMhvqxmcgV69WvT8PgqPgPyL0/w9rTmeqsy+LH6TmYCIFjwbtgSx6Ubek1wL2CwYi8jBLoUc3ACIvIjiwMCQNqGdtXR5Wf+OmejSe1fudCAm5OhszUlrJ7eo88Gl2eNl7mYS3RaqjcUIpVK/8kWlK36phKpmLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kzsOpapdRzQqFqWrZYgLA7mNlw9zTY9QDIWtDtt1w38=; b=r5SKyKZOH5abtVIvZGP7LbVFe8bAk1qLcpQpGl+5lcI+vMuaTQTXuPciJTfF10mjKDAwejbiXnVPqXNEb+9sRVKGcs856loPwwYEQctsMGMj72gotHQtccWz79+FFYR+FKIGYoJTlOPZKMFi3f5u4U88zxYlGxpnYbWVifoXQjw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Stephen Cheng To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Stephen Cheng , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: [PATCH v3] x86/svm: require VMSAVEvirt for nested virt Date: Mon, 21 Sep 2026 13:29:09 +0800 Message-ID: <20260921052910.580298-1-stephen.cheng@citrix.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20260727071709.196088-1-stephen.cheng@citrix.com> References: <20260727071709.196088-1-stephen.cheng@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU0P306CA0035.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:29::16) To CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR03MB7889:EE_|DM4PR03MB6936:EE_ X-MS-Office365-Filtering-Correlation-Id: 043f297b-063c-4a8e-3a9a-08df17a15030 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|6133799003|22082099003|18002099003|56012099006|5023799004|11063799006|10067099003|3023799007; X-Microsoft-Antispam-Message-Info: jEzGD114D4tupxpwiZkLDtUrFO4qO4LZrv2+Q1/J9ISdEOiiiRC+b2C8Y/Dg/LE6QrKQyg88cYr4S0zDoHNHqVrYbjCAR3KTa3wTZ6WZ9aiAfqzdOKw1ILe0fAFFQrOfrnb5Yxy5zjpsVKzbbeE1AifkpG1Nf6IjmZ4SCisy8Au9p3yQ/33e24SOdutrykjvn2l4NzpWVZlW3+SuF7o+W8BONZlsCnGD4mrVwQBklWpfHWEhpfGyWejhp4AHOxBu2DIK8rd3Vtc5WTVtnBRS6p8G0SR4YbOoOoVXFtjOIccshSGctb1rWVxyCkFsvUVLXjnCcYjc7VYmkqM23kumDibYDlBD57raHEZ0bA+T2B0piDg8hcYeJUJakr05RYIpbZsUxHEYRSnLtczRGCn/cWpAaqCNkxjsgJSWmL0NAt+slWvL/jRlhar7zIkn3S6XYgFrZXEHgYPUdJEGRbbiBfWjkoHouAMVPmPUE00VAMhig+1hJS2VK0kHLCdwxZw1fLESs4IbW5g74e7Cv9leNgYZrptcO9W1wGYMeXfJV3JrkTKZLet65PCPkC26QAQLseqBFXyjxxyeO1kj+PMGWojv53Ex46ii1d/hV/GHydw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR03MB7889.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(6133799003)(22082099003)(18002099003)(56012099006)(5023799004)(11063799006)(10067099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?QDcpEwicQ7c1cWlUahQisGJcJeBncVNxywaQW4ax2POhos2Z6TmhGbLewHRx?= =?us-ascii?Q?562I7N1pBABmsHNtyg03hS8oi884hM3c77Hxu1Ig+eWSzm4ADcT/MCPyLJEq?= =?us-ascii?Q?fzT+2oHrFieMJyuZZEWDhbZrszQBOmRe3xSkJceA/xvsjfAY07XVdPIBgS5H?= =?us-ascii?Q?DXMSv7B/mzsedsGzZeuVOVrWLIapo1PT4Pu2lR4P02HHrFveRzjSuBoRSNxu?= =?us-ascii?Q?GuOd7pg8cib1PhTD4yydjxdRsEeltM5QURAVCcOhvlBwiU4PKzAh4LrzmQ2Q?= =?us-ascii?Q?TVG2VQLMJK3UJ6SBeH9fuGQ37QZ1v8bxAhoJQyiajOqFI4oTPXtKrWg71KHB?= =?us-ascii?Q?lOAZxBMQOmm6+9wOe97+X7mN6F5Fz22V6oGJbvuiKeWCRBgDcmeRhxmtBm0I?= =?us-ascii?Q?A3rUgvRDlT2gMKkxvX3Vd58/5u5zp4mXc/JZo4M5kvwpMNoyKf9lCZNzXte/?= =?us-ascii?Q?VjgvWPnP2AkpIRu9Vlx70BDqOZ7vw+0kyNhWQcgfg/Pvxd78Oi/OBD/bPYYA?= =?us-ascii?Q?5HGp1hC28rG5PDezh+MVZ4WcgQO+K8l1VfywFW/xfTBF7CfIFqiRmxLjE6l3?= =?us-ascii?Q?qPyhZstZHJkELtYXx3h0sRvma1WirsbKEZied0P9tyXHIaT6HQ3OJ0ZPjxa3?= =?us-ascii?Q?zsAKmFgb+g6T7/t4GIfWLSQ42sAoqyvHlu6aLCmzq7dTwU+Q5Y7R6p6HuMyV?= =?us-ascii?Q?Vw9KVMSEwRUpkVyd6/F4FJ/loepwSb3GwH5NItkZ4sGwwdmH9z6GNCOD4XST?= =?us-ascii?Q?NiyE7OaGo03ZEqH0JjtOgpA/iF8/6xBZiX73HegF7QbzVft1i70B8MDzasal?= =?us-ascii?Q?616w7ztW8tiK/rrK50MObqxQDw1DOm1iL+B/MriIBijXe4xLP/NVYjJvrHS0?= =?us-ascii?Q?zDsF2MQHpwd3o/FeA/9QURcGFpszv5KEVHE4pySLMCOMwa96U50A+vB9aBID?= =?us-ascii?Q?d6gmNprQQBqQ/OXOuIRe++V7uFo7Q4f0meFfeQkkYTCgaAW8hvzyt+hMuI9i?= =?us-ascii?Q?Rip6fCFqhBCI1t5qfrHaOwG0OVDdBOvrGaMtBR/sJnjpxQDOgcGwWruLGHfU?= =?us-ascii?Q?jWGwjzmSVOcUP5tX79wC3oVJ6PNe1k663D3mD9wKcklWyfX1AOAIwtKAfpy/?= =?us-ascii?Q?LSf5sVXTKCGILoFFJDeZHjpnAZuIXghPsR3H2uf7bNmjYn30YrPxCtpMAwVl?= =?us-ascii?Q?d81RoatL9T1/Y4Ymde1yqte/3VIHz7HAJAAlQ2HEjfc8K5a4WAE184yzP4I6?= =?us-ascii?Q?UTmBeXVyS2CdmjYGWmI+/8KI0qzIxOXcuL8IjJ0+A1Flo7AiNyCPf2H32L9V?= =?us-ascii?Q?hMstR9scWU+B1Lutk81iMn54dDXlZw8uBcUAGG3r8DBtePKswieLpkMEuDDM?= =?us-ascii?Q?VqSf4D+/rHFq2sjcwKRmlZ5Pdqb6PQ3wD0/kmcRgkWtcnrqIRX3HGrNR/Shf?= =?us-ascii?Q?BbUQRUmSUyn7gFwOdCC/US+DkPES21zc8+91bwe+jpoZ3W1xcOhL7MW6H/5N?= =?us-ascii?Q?LjZp18OGJZ1exyjYKRwnTqWH4+RwkctTptnrrl3KK68VajaUxGvmou/oJG/M?= =?us-ascii?Q?KIw8QpiOClRxPUTtWkqMVubPoRivarLAgwQXK81drRTYuIyb+L7+O3GRoEpC?= =?us-ascii?Q?11bBm+pDJjz09wiQMVyzGDYdHz0rav3f8UYeQH/QczptMo5MJegtL1zHOtfq?= =?us-ascii?Q?2cnCO3LSfVkA2niE6Y4/JkFFU+OBEFrFqkN6U9sujsYhtnv6TmYb5AMNc2o6?= =?us-ascii?Q?Nox4CZ+FeQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 043f297b-063c-4a8e-3a9a-08df17a15030 X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 05:29:31.5437 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sFsxc31iRth5YXyDlgEENrZQTZPELT1Yhqv9ux/R1TJ5Dcf1FpumuFLWxrZVRQZq/9k8im7Uva0OZEuKxAqhKmpwEDWS2f6Eb016Q7Gv6Cs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6936 X-purgate-ID: tlsNG-c201ff/1789968604-243112A1-FC72515E/0/0 X-purgate-type: clean X-purgate-size: 4743 Virtual VMLOAD/VMSAVE lets an L1 guest execute VMLOAD and VMSAVE without intercepts. Without it, Xen has to map the L1-provided VMCB and re-execute each instruction in L0, handling a complex, security-sensitive subset of state on the way. Make VMSAVEvirt a hard requirement for nested SVM. The cpu_has_svm_vloadsave test in svm_nested_features_on_efer_update() is then redundant, as nested virt now requires the feature, and is dropped. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Stephen Cheng --- Changes in v3: - Rebase onto staging. No functional change from v2. Changes in v2: - Keep the VMLOAD/VMSAVE handlers rather than removing them; the insn emulator will need them wired up regardless of older parts (Jan). Jan - v2 dropped the handler removal you objected to, but got no response. Resending rebased in case it was missed. v1: https://lore.kernel.org/xen-devel/20260727071709.196088-1-stephen.cheng@citrix.com/ v2: https://lore.kernel.org/xen-devel/20260730030303.71388-1-stephen.cheng@citrix.com/ docs/designs/nested-svm-cpu-features.md | 17 +++++++++++++++++ xen/arch/x86/hvm/svm/nestedsvm.c | 16 +++++++++++----- 2 files changed, 28 insertions(+), 5 deletions(-) diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md index ce168e68e1b..eed40a958c4 100644 --- a/docs/designs/nested-svm-cpu-features.md +++ b/docs/designs/nested-svm-cpu-features.md @@ -109,3 +109,20 @@ leaf 8000000A:edx Using it in L0 reduces the chance that we'll make some sort of error in the decode path. And if hardware supports it, it's easy enough to provide to the L1. + +- 15 `VLoadSave` *Virtual VMLOAD/VMSAVE*: Require for L0 + + Without this feature Xen has to intercept the L1 hypervisor's VMLOAD + and VMSAVE instructions and emulate them by re-executing the real + instruction on a mapped copy of the L1-supplied VMCB. That path + handles a complex, security-sensitive subset of state (the hidden + segment descriptors for FS/GS/TR/LDTR plus the SYSCALL/SYSENTER + MSRs), so on faithfulness grounds we'd much rather let the hardware + do it. When present, the instructions execute natively in the guest + without a #VMEXIT, which is both simpler and faster. + + Whether to provide it to the L1 is a separate question, deliberately + left for a later change. It needs care over whether an L2's + `vloadsave_enable` should follow L0's setting or L1's, and over what + should happen if L1 leaves the feature disabled without intercepting + VMLOAD/VMSAVE. diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index a8b15d6eae0..6f9ba3c89a1 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -573,7 +573,10 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) /* Keep the host values of the fs, gs, ldtr, tr, kerngsbase, * star, lstar, cstar, sfmask, sysenter_cs, sysenter_esp, - * sysenter_eip. These are handled via VMSAVE/VMLOAD emulation. + * sysenter_eip. These are not transferred by VMRUN/#VMEXIT; they + * are moved directly to/from the L1-provided VMCB by the guest's + * own VMSAVE/VMLOAD, which run natively (VMSAVEvirt is required + * for nested virt). */ /* PAT */ @@ -1108,7 +1111,10 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* Keep the l2 guest values of the fs, gs, ldtr, tr, kerngsbase, * star, lstar, cstar, sfmask, sysenter_cs, sysenter_esp, - * sysenter_eip. These are handled via VMSAVE/VMLOAD emulation. + * sysenter_eip. These are not transferred by VMRUN/#VMEXIT; they + * are moved directly to/from the L1-provided VMCB by the guest's + * own VMSAVE/VMLOAD, which run natively (VMSAVEvirt is required + * for nested virt). */ /* CR2 */ @@ -1559,8 +1565,7 @@ void svm_nested_features_on_efer_update(struct vcpu *v) if ( nsvm_efer_svm_enabled(v) ) { if ( !vmcb->virt_ext.fields.vloadsave_enable && - paging_mode_hap(v->domain) && - cpu_has_svm_vloadsave ) + paging_mode_hap(v->domain) ) { vmcb->virt_ext.fields.vloadsave_enable = 1; general2_intercepts = vmcb_get_general2_intercepts(vmcb); @@ -1618,5 +1623,6 @@ void __init start_nested_svm(struct hvm_function_table *hvm_function_table) cpu_has_svm_lbrv && cpu_has_svm_nrips && cpu_has_svm_flushbyasid && - cpu_has_svm_decode; + cpu_has_svm_decode && + cpu_has_svm_vloadsave; } -- 2.49.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 05:47:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 05:47:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427089.1649726 (Exim 4.92) (envelope-from ) id 1x8Wrq-0001Cr-Fo; Mon, 21 Sep 2026 05:47:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427089.1649726; Mon, 21 Sep 2026 05:47:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Wrq-0001Cj-CE; Mon, 21 Sep 2026 05:47:06 +0000 Received: by outflank-mailman (input) for mailman id 1427089; Mon, 21 Sep 2026 05:47:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Wro-0001Cd-CV for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 05:47:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Wrn-00FizV-9j for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 07:47:03 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0c4d0-2eae-0a2a0a5409dd-0a2a450a80de-22 for ; Mon, 21 Sep 2026 07:47:03 +0200 Received: from [52.101.85.71] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0c4d5-f2d2-0a2a450a0019-34655547b0d2-3 for ; Mon, 21 Sep 2026 07:47:02 +0200 Received: from CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) by IA6PR03MB944787.namprd03.prod.outlook.com (2603:10b6:208:5ed::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 05:46:58 +0000 Received: from CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767]) by CO1PR03MB7889.namprd03.prod.outlook.com ([fe80::2d02:5605:87a2:6767%5]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 05:46:58 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SkiDLzM4es5p2hDxDG+cNQE8TxnKGqOMPZO2ibTTGevkaTOKHUKpNhCqL194IVvg+dXgT0rlI/o81fhSgpXkIDagbFXky+3HCbQZPSHgUyjlV9H365NBsyTEO64mIOb8TqufRYc+e5rIbFyQqh5J0FXxKS/ZPPIEoOI8diJ+FxzspiI4HBy1GP913cDhu9ldQuPveR30Wx0HW7aLfNwwskRd1QEN9DwDFf5THRG/iY6vF6oVTmI3F4mGJEUKy74MBDlvvXv8GwIJkr07n1HQ4YZtAh2osXpADqtzTdO0zpWlqXlax62is75XhNpr89sE9RDDWl0sSH4yY7xJ94HzLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bz6kdJz6bJBZUYmXnNYr5Ji6cJljDt0qMhmgmep5HH8=; b=HyFACjZqX/q90fj2MlN2krRvqx1LdiMNFoI0KlguHn6+tJlBzqNcxPFSn1P0JCYZKxg0btG1LmfAQN04sJ1/j3zKq9hxUf571jXBOkUkl+Tq8w+vNkyAz2BkbZ3sgR24uEI97WCj34RjoIYYjL78uHhAoa7zLOGUXdxEP0L33mSuekWo2onjWxUHc99UwCu8elZbdBRi6w0GlxBT7R2dOCP7zGSZ0ayeimHZdgTEN8fFK3HdWGHJq0sVBO2Wau6lqP0x5BcsuPD3Sg28/s6MW643fdWo7pYYfHPoGGYLz4GXPOk0+MJfj1dH7YoRsTzt76S6t2pqKfzReIQlf1XvNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bz6kdJz6bJBZUYmXnNYr5Ji6cJljDt0qMhmgmep5HH8=; b=IdeN5wxXaytY33F6tjaWQkndsVUGzAQ6Ht6FJwgMRKheH7AKYkxVOpYJvaJQQkvAITz8T4sZesK33VzB9q4497BfO5EchUeFcqk9tu8lc+09RCOlpmCKi7+Eq/V9SH1G6+Y/bwMeTrvh+uBHN4JG9kNxnYPEQ6F+XMqYj6toHHQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Stephen Cheng To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH] x86/nSVM: Don't zero the l1 guest's N_CR3 on #VMEXIT Date: Mon, 21 Sep 2026 13:42:01 +0800 Message-ID: <20260921134201.811248@citrix.com> In-Reply-To: <20260921043148.562181-1-stephen.cheng@citrix.com> References: <20260921043148.562181-1-stephen.cheng@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: KU2P306CA0066.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:39::17) To CO1PR03MB7889.namprd03.prod.outlook.com (2603:10b6:303:275::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PR03MB7889:EE_|IA6PR03MB944787:EE_ X-MS-Office365-Filtering-Correlation-Id: 6f3af6a6-9d56-4063-37d3-08df17a3c04c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|56012099006|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: gulpprvHemPXDaVroR2TbGzv8IacUdIsiKL4UGfVDCP8Scd++9Xe1t1wZ5CKFLrDdmKsuDMT3Vy8X5Td8MzjcWAfNq5GkIhEU4jda4FIMjTzzUrBoiVbEUL35yJgvOTcSRfBwwBtrK82ZW7Q0ZUix04ZZRS3z7WdoHlw1npXP8tenSbq5lO+gPjHB7A7qfqVatoT07iQlaY7BSKJUN+ld0Mj/lNiqNJxgNm8X8etSQMgHMh3w/IrwYTqHhEZK06cFhIQLq4+8gvx1x/4iZKlze1C6iEeYNmsMdSsBM3WWlGVL+bRH3XM3NlcXs0iWedcIAuW5sTFxLAr5kQrQa20Fg9Bp1cu7dMnVhNp2nHTbuNvrwy8LnztHG2aYZccwCSsZh6zD5bOSQ7F+lYWLBXGJ7RrC9O2uXcwhRky+py/oupiPyhhQsq+irsd2D8t2m7oI4tjh30f59l7lnnTmtR5kQcSD3BsmS3eyPfXQOGu6UCiZmbIVL7/Pxt7Mb30rGYHJdmvkEPFE5t9W/vzLxhoKLxYwtkw52ax+iv6Y9cQ9cjjRuDYbQIL/gElTlBft3kphWcFVqE/ykmR/XPCuOsymNybXVk4MWeDq4EdyaILMl+3t2yOBzEoP7OVlfjjoIs0 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR03MB7889.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WEdsejlEK005K29XTDhvOTFTUUVEVGp1bWdmVHVvcmxyUzFFZ1hCYVpXQjVK?= =?utf-8?B?d0Jnbk9oWjdYS2R2Y1lEUGtDQUl3SnFJSVRkMlJETEVVaHUzQjZKaHJ1bXEw?= =?utf-8?B?aHYzRW9jdDNFRkt5MmhYYUJ2cENKckR0UXZpQ2NyMzhZM3NJclF4alpNWmkz?= =?utf-8?B?UHc2V05pNnhDQ2N0Nlk1ekRtZFNkNW5JeitWUmx3OXdBV0RpLzFYZHk2NzND?= =?utf-8?B?cGl2ZUdtU0Z0c1hCcjY0Z1paMzV6cG5EME05SEdnZ0EvUXlaNjYwU0RqM0Zl?= =?utf-8?B?SVVyNTlRU0d5bTBNWE5jUUg1b3l0MG5abkFHTFR1NVRFU2xwSTV5K0graFhr?= =?utf-8?B?TFBxejcrZnp1KzJSZk5MMmpvREcrR0NDaktxRTlxeFVtRnNqRi9mS3VpcmNZ?= =?utf-8?B?QzdlU3l3MzR2d0svWTJyNU9VdE84R2xXd0VMZEx6UCtEdSsxenU2M3BaOGRN?= =?utf-8?B?b1ZKMFdUQ2kzZWU0RWFtSkhicmxkbUJmNVZQQlVvTHdDM3cxMVhPeE5qbC90?= =?utf-8?B?UGNaSzkzNjkvZy9mNjdKZFplL1AwSGtiOXBiYWtzd0QxSnB1OUhkRlRQekNl?= =?utf-8?B?dTNSdzl1YTArWjUxQ2xQU2trT2Y5UVo0RHZvMDRaRXZSY1lreGpHTmZDaFlI?= =?utf-8?B?RDRzanphTXZyQWRkUSs0cG4wWW90L0h0Sk9oei9pYUNZWktodEZ4ZWZpK0dL?= =?utf-8?B?VlkydVRRUUtlV3RDYkdlQnBRU3FhMHBKU3hhYlN0ZGs0N0NzQ3B4SURpT0pK?= =?utf-8?B?clZYajkwaXRJbWwwdGF3aTJxcERyQitzNDBhVVJXQTFBalNSQlFBQjV3d3Jm?= =?utf-8?B?cW1UYkpZUStaTWE4UTlBbG50MWxQM1F5RkZ0cWhIaFc4dGdZcHFwMVd1VW9G?= =?utf-8?B?VklnaGpONERPenFjQjYwZzZ0TU04elJVRSsrR1ZSZHpYWE9TUkMwTzkwODZJ?= =?utf-8?B?YzJzUGdIZlRtREhteHYyelFxdk5jS0w4NzRDc3ptaFFYcEpwUTRXWjJ5cGsv?= =?utf-8?B?WmN2c1lESjJPNnBwZ0Y4ekQ3aDRVbGo0SkpDVSsrdU92bk9SMHpVSVV6czUr?= =?utf-8?B?WGY4U0xnY3g1VW04WXkzU2RJVFBtMUVhR01tQ3dhdnVDWUJ3TVZJdWs3K3VR?= =?utf-8?B?OU82cDlxZUdoM08yeVFEUzkyN0FFWkJnOVNBK3VUYVJLOUVibTNUWmtXZENT?= =?utf-8?B?TUJvbXkrOWUyV05zZEkzYlh6S3ZtRkhRTHNyb2RVc3daVW5jSHpEV0RIVVp0?= =?utf-8?B?ay83OHArbmIzL21yMGZad1ByeHlxVksyOHVlZFJkcXZaVlJtWmViZHV2NHdB?= =?utf-8?B?b201d05Vd2RUNU84R2N1UkFsbHg1TFZTeExOamt2ZVd6bHA2d0dpVGhiaS9l?= =?utf-8?B?aGh3UkN5NFZIYUxueFFGTUtjM2ptMmJiN1lvM3VqVXZSZXBvYmYyc2lHV3dx?= =?utf-8?B?Zm16dVUrRVNmaExQdW01aVYzVFdkTWlRN2t3c2tibURrYWpYc24wVURwUWNy?= =?utf-8?B?R0VHQlpmQzFmVEVKU2dmTTc5MWZwMFc5Qy9sY1hWMDg2NzNuVzNkbUI2TGZP?= =?utf-8?B?WGEvS1d0TUR0R3VzY1U0L3cyeGRUbVBlenoraEFtTExIdXozbnJuZnVHdC80?= =?utf-8?B?OXZINFE1OWtqNFhhaVdkNUdkMzI3dHJKdW1CS1N3dGhrTVBKWmtkaVhrcndv?= =?utf-8?B?SWlXWHRmNWZVdVZSTWlhYmJxVHhKQmhOMlBtanYvc1VrK21DaGtnZG1mVDZL?= =?utf-8?B?czNxSm1Ebkp3SXk0WDNXZlptRUpmSlBlUE80UFp6TjBUYW1tTDNLL2RPcm1E?= =?utf-8?B?U24zdjNxemRXbW1OMlREa2d0Z05adXcrVW1kTXlaTWNvTWEyNkhsNEpWMmxN?= =?utf-8?B?eDZHRTZTVGE3NitjTDlMVWZnRVNGb0d6d05sK3BLclZjNC84N1VFNk4vZjVU?= =?utf-8?B?aDI4ODBkVS91dUlzSEhCQlFmKzlNejgvZkNBbjZqVE1LK1ZGQmZrb0RBWHgw?= =?utf-8?B?cS9JOWxVRTU4TXY0bDBkQ0Y0OFFQVVpPQ2pBLzl4eXo0cFk0RVpvMHBQc3cz?= =?utf-8?B?dk9NcUlOV2o3WFU1UUxqY3paa0JWckk2RE9IZDNFU28vN3lYVXRvSW9Yd0h2?= =?utf-8?B?MnMwK1VkUFRXZWJWeWorK041bk03TklqRjlCN1FBREFTWlRXSXBWTG91MjJC?= =?utf-8?B?UGtPTHBrSXNDTXlDWFQ3a0VsZTZQQUw5UUVXaFVxY1hwUktFSmpIaU44aW1D?= =?utf-8?B?aDlHbE1RcDBVS0ptY0h2OHJndkc4K1Z0bkQ1U2k4Zmt4RUN5Z3VVamZYVHhO?= =?utf-8?B?UVZibUZ6LzMvaFBkQi82QzZoYko2ZGR6UVkrcmhrYjB3bkRBdnRlUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f3af6a6-9d56-4063-37d3-08df17a3c04c X-MS-Exchange-CrossTenant-AuthSource: CO1PR03MB7889.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 05:46:58.4354 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 3ii9Sh6d/N11kGLaHXX700LbaJP168ZJxOCWwP1lGrDq4k3y1a6u7iA/AYbR4+z8XuTWywcyP02PUKXNynVDl3qLD6//dwBLzIETpnMcK30= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA6PR03MB944787 X-purgate-ID: tlsNG-4011c0/1789969623-4B6D6CFC-A64C27DB/0/0 X-purgate-type: clean X-purgate-size: 375 Please drop this one. Ross posted a fix for the same thing three days before mine, which I missed: https://lore.kernel.org/xen-devel/20260918125205.374168-1-ross.lagerwall@citrix.com/ His patch also drops the NP_ENABLE writes, so it covers strictly more than mine. Sorry for the noise. Worth mentioning: I have an XTF test that catches this issue. Stephen From xen-devel-bounces@lists.xenproject.org Mon Sep 21 07:01:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 07:01:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427102.1649735 (Exim 4.92) (envelope-from ) id 1x8Y17-0002K2-Is; Mon, 21 Sep 2026 07:00:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427102.1649735; Mon, 21 Sep 2026 07:00:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Y17-0002Jv-Fe; Mon, 21 Sep 2026 07:00:45 +0000 Received: by outflank-mailman (input) for mailman id 1427102; Mon, 21 Sep 2026 07:00:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Y15-0002Jp-84 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 07:00:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Y14-00BIjj-Ka for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:00:42 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0d61a-2eae-0a2a0a5409dd-0a2a450bae24-0 for ; Mon, 21 Sep 2026 09:00:42 +0200 Received: from [91.218.175.183] (helo=mta0.migadu.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0d619-b7e8-0a2a450b0019-5bdaafb7aac2-3 for ; Mon, 21 Sep 2026 09:00:41 +0200 Received: by smtp.migadu.com with ESMTPS id 6ebfb9316ecf8394; Mon, 21 Sep 2026 07:00:40 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=key1 header.d=linux.dev header.i="@linux.dev" header.h="From:To:Subject:Date:Message-ID:MIME-Version:Content-Type" X-Envelope-To: xen-devel@lists.xenproject.org DKIM-Signature: a=rsa-sha256; bh=TLZQlQIDzt2OohWOO5wD38jaj3Gdn2F1Ht1VsE34Ej0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789974040; v=1; x=1790578840; b=I6PFtfnLwAItmk5ez6jrUL842Fp5IqmdFIy/CLempbTd9dRNLwt0e1m45kgHAwjtXINEYp0O Y0Q2roic6ZdTUhReWoIjh7sxlul64e4Ki/jC7lQNY2VSG21brJpeAgfPjvkyCG2+gB6ry4aGB/q 6in6CziMVVAW4Eh9y8dfa9Gg= X-Envelope-To: xen-devel@lists.xenproject.org X-Mizu-Trace-ID: 6ebfb9316ecf8394 X-Migadu-Flow: FLOW_OUT Message-ID: <01cfa2f8-753b-428b-932f-470a46221b4d@linux.dev> Date: Mon, 21 Sep 2026 15:00:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 03/17] xen/grant-table: stop setting PG_private on pages for grant mapping Content-Language: en-US To: Zi Yan Cc: linux-mm@kvack.org, David Hildenbrand , "Liam R. Howlett" , Dev Jain , Barry Song , Lorenzo Stoakes , Alistair Popple , Suren Baghdasaryan , Muchun Song , Johannes Weiner , Andrew Morton , Nico Pache , Michal Hocko , Mike Rapoport , Kairui Song , linux-kernel@vger.kernel.org, "Matthew Wilcox (Oracle)" , Baolin Wang , Ryan Roberts , Juergen Gross , Gregory Price , Qi Zheng , Stefano Stabellini , Shakeel Butt , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Ying Huang , Usama Arif , Vlastimil Babka References: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> <20260920-remove-pg_private-v5-3-bb68b6a21869@nvidia.com> From: Lance Yang In-Reply-To: <20260920-remove-pg_private-v5-3-bb68b6a21869@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789974042-AB2DC9EA-168DB269/0/0 X-purgate-type: clean X-purgate-size: 941 On 2026/9/21 10:27, Zi Yan wrote: > gnttab_alloc_pages() stores xen_page_foreign in page->private. On 32-bit, a > pointer to an allocated xen_page_foreign is stored; on 64-bit, > xen_page_foreign is stored inline. Checking page->private != NULL is enough > to tell whether a xen_page_foreign needs to be freed on 32-bit and > page->private is zeroed unconditionally on 64-bit. > > It prepares for a future commit that remove PG_private. > > No functional change intended. > > Assisted-by: LLM > To: Juergen Gross > To: Stefano Stabellini > Cc: Oleksandr Tyshchenko > Cc: xen-devel@lists.xenproject.org > Cc: linux-kernel@vger.kernel.org > Reviewed-by: David Hildenbrand (Arm) > Signed-off-by: Zi Yan > --- Nothing jumped out at me, feel free to add: Reviewed-by: Lance Yang From xen-devel-bounces@lists.xenproject.org Mon Sep 21 08:04:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 08:04:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427124.1649743 (Exim 4.92) (envelope-from ) id 1x8Z0H-0001tf-EK; Mon, 21 Sep 2026 08:03:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427124.1649743; Mon, 21 Sep 2026 08:03:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Z0H-0001tY-BA; Mon, 21 Sep 2026 08:03:57 +0000 Received: by outflank-mailman (input) for mailman id 1427124; Mon, 21 Sep 2026 08:03:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8Z0F-0001tQ-Qk for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 08:03:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Z0F-001Nyr-08 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:03:55 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0e4ea-2eae-0a2a0a5409dd-0a2a4503ac00-0 for ; Mon, 21 Sep 2026 10:03:54 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0e4ea-fae8-0a2a45030019-4a7de18c8dfd-3 for ; Mon, 21 Sep 2026 10:03:54 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49d097b4939so13012135e9.0 for ; Mon, 21 Sep 2026 01:03:54 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fcd068059sm221379895e9.5.2026.09.21.01.03.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 01:03:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789977834; x=1790582634; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=28DxKa1M9r8vKCI/HR58KiCHbwp2JgT/M3PBAN4MVGg=; b=JtKJS91Z89WVE22L/VGA9KBg58VBRruk/kEZ0bS/QZtXcrEBoYQ+4aZcs18fShaeZB F581z+mm5c9lSY+Bepsz3jCZfkKXeCAH+l5g1kW+BrGuPlLuwBtl8WmHGTSDdXCVyJDL Mc+PC4AzIAHs2JhN+zL8DdnIBziZkDec6XVUwMYPR6RpRow58UEu0jY5w0sJce3f+gED dXQ3YMCScUQXiNlpFIw7hyTc/RO0S6KbDDnoAyyjz8eqALcANS4gihEa0cIAjR2h7WNo FQQmwwUXCaJIHQSzqN52xfXdaaA2I0ua8PFy4TlMbHde0XbA1qX8qK+jBGcGosRzhnrg LsGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789977834; x=1790582634; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=28DxKa1M9r8vKCI/HR58KiCHbwp2JgT/M3PBAN4MVGg=; b=le3dMig5cBQ9J9ZhqVOGvZqvajwbCR9ecZShJXUVNQBH6Sp5qm+AKLjpxlesOfVBPL UH8WMXIgMUpezfrsSQ6rgbtnKvDceuAKLkfQAr3jZDZROIyeSoQYMwfHtRQ/mZUKcQIz A6nFkr229uGfbOP8np7jB2sSKFUqYwcyCj9nvm+baZwZ7vfYJORAOajPikF8JUwuluwQ fbN17YNtXchohXLKG+t/H8fFViK54iOtd4PGtHMfpssI3mdXxViIkK6KrV35ICmr2Yqt F3InX3Kmuh5H0bsgDkuoAZF2KtOJ2sPKB3/DT6pcTq3pqGiZTX95ALgMQp4jGqo+uheV gF0A== X-Forwarded-Encrypted: i=1; AKwUvBy6SP22r+YHVIUKYa/fC5/2IDjCianop18ijZjA1zS4C9YL8gvszAZtfFTOJE7BJre8PRVOWZnqQ/w=@lists.xenproject.org X-Gm-Message-State: AFuF++kgyYN5n9eN9l1IQAmu+2T3sqGPyIqUk6+dhK1nPfPgwuC9hwI9 VN0Ook5PoacB48LjyiRzj4/cLCUre9My1U5yLRcE3Lc01FduXi37FbxJ X-Gm-Gg: AYBFou2cEpt64snD+p9Fo8jTpzyNdIDMvNHGTbf702Mk5Rz09sZHlwOiaWcXXCnEfeY YvFeTZShh/A3LzzeHld997Bq3S9BIlE3vM6CaWgqWsuLon0xHSakzXu/wW+1m5QyhIOvHT3oiGy GYlZx5j+ADTJbyPoIxp3u087Eftqy0Qyfrpc91qV0gO8n0MPRvUKcsLkamIWSkabGXW2j5IBCp1 mS2wDcMurzBpx1tzdx2TGB68WStPE0p6FQ9AswZU3ZIl1LLpDWg8J2vgrAJfzP27B6f7skrjB0C Q46DELMnysIecprt/jJi/Q2/s06C5X0Zlm3PNfjTzLW8iIsbnyeTHggAOBIZOtGBFR+ZJE36IRK OBYDHphlT5D1fSfTRmB9TuJkJBrez6AzUoLlbCwWQ7gpFwksKZMvt0XvHvtdRaJrR7qJk99ZPSl UujGkQht6kstQHPfOrmdWAGYmN09wkpopDG7xA+a4D+bJbCLAHT89UPBA9pEfv329YBZbCranbx 2uD9HMsMfllsdfd7ZurTZq1HYNTIsZ+gjw/0cVjNWnsC+qqOQ== X-Received: by 2002:a05:600c:468d:b0:49d:1f32:c911 with SMTP id 5b1f17b1804b1-49fc5687b5fmr140359845e9.3.1789977834129; Mon, 21 Sep 2026 01:03:54 -0700 (PDT) Message-ID: <9929eb6a-d7b8-4a39-b726-82290983e9f3@gmail.com> Date: Mon, 21 Sep 2026 10:03:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> <2394a616-16be-4657-be17-0a2dafebaeee@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2394a616-16be-4657-be17-0a2dafebaeee@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789977834-756834E9-7BFA9BA2/10/73395122804 X-purgate-type: spam X-purgate-size: 5960 On 9/14/26 5:02 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> @@ -60,6 +61,12 @@ static unsigned int __ro_after_init guest_num_msis; >> #define IMSIC_DISABLE_EITHRESHOLD 1 >> #define IMSIC_ENABLE_EITHRESHOLD 0 >> >> +#define imsic_csr_read(c) \ >> +({ \ >> + csr_write(CSR_SISELECT, (c)); \ > > Nit: Excess parentheses again. I will drop them. > >> @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) >> spin_unlock(&imsic_cfg.lock); >> } >> >> +static bool imsic_local_is_pending(unsigned int id) >> +{ >> + unsigned long isel = >> + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0; >> + unsigned long bit = BIT(id % BITS_PER_LONG, UL); > > Both can be unsigned int, can't they? Yes, agreed. Both isel and bit fit within unsigned int. I will update them in the next version. > >> + return !!(imsic_csr_read(isel) & bit); >> +} > > No need for !! here. > > What about endianness, btw? Does the IMSIC always match the CPU (and > its setting)? No, the IMSIC does not dynamically adapt its register interfaces based on the CPU's runtime endianness configuration (e.g. mstatus.SBE/MBE): - CSR Accesses (imsic_csr_read): Indirect CSR accesses (siselect/sireg or miselect/mireg) operate using standard RISC-V CSR instructions at current XLEN width. Values are read and written directly into architectural GPRs without byte-swapping. - MMIO Ports: For incoming device MSIs, IMSIC uses fixed memory-mapped offsets: offset 0x000 (seteipnum_le) always expects Little-Endian, while offset 0x004 (seteipnum_be) expects Big-Endian. - Memory-Resident Interrupt Files (MRIF): For virtualized environments, MRIF structures in memory are strictly defined in Little-Endian byte order regardless of whether the CPU harts operate in Big-Endian or Little-Endian mode. > > Overall, what does "local" in the function name signify? (For a static > function, the "imsic" prefix may also be unnecessary.) It signifies that local (on which code is executed now) hart's IMSIC CSRs (isel and ireg in the case of imsic_csr_read()) are touched. > >> @@ -497,6 +523,27 @@ static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), >> on_selected_cpus(cpumask_of(cpu), func, data, 1); >> } >> >> +/* >> + * Ensure that all the MSIs the APLIC has already generated for the hart this >> + * runs on have really reached the hart's IMSIC. >> + * >> + * The barrier is the one described by the AIA specification in >> + * "Synchronizing interactions between a hart and the APLIC": ask the APLIC to >> + * send an MSI to the hart itself and wait until it shows up as pending in the >> + * hart's own interrupt file. As it says nothing about MSIs on their way to >> + * any other hart, it has to be executed by the pCPU owning the interrupt file >> + * the MSIs were being sent to. >> + */ >> +static void cf_check imsic_aplic_sync(void *data) > > If the parameter isn't used, maybe best to name it "unused"? Makes sense to me. I will do that in the next version + I will update the type to 'struct imsic_vsfile_data *' as it was suggested for imsic_call_on_cpu() in "Re: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file". > >> @@ -848,8 +899,22 @@ void imsic_migrate_vcpu(struct vcpu *v) >> if ( v->arch.last_cpu == NR_CPUS ) >> return; >> >> + read_lock_irqsave(&imsic_state->vsfile_lock, flags); >> + old_vsfile_id = imsic_state->guest_file_id; >> + old_vsfile_cpu = imsic_state->vsfile_cpu; >> + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >> + >> + /* >> + * We don't support SW interrupt files at the moment. Bail out before >> + * anything is touched, as the old file has no owning pCPU in that case >> + * and there is nothing to retarget the producers away from. >> + */ >> + if ( old_vsfile_cpu == NR_CPUS ) >> + panic("IMSIC SW-file isn't supported\n"); >> + >> /* >> * At this point, all interrupt producers are still using the old IMSIC >> + * VS-file so we first move all interrupt producers to the new IMSIC >> * VS-file. >> */ > > Isn't the new part of the comment premature? Moving doesn't start until ... > >> @@ -870,5 +935,43 @@ void imsic_migrate_vcpu(struct vcpu *v) >> /* Zero-out new IMSIC VS-file */ >> imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); >> >> + /* Update G-stage mapping for the new IMSIC VS-file */ >> + if ( imsic_map_guest_file(v, new_vsfile_hgei) ) >> + { >> + domain_crash(v->domain, "Migration to hw interrupt file failed\n"); >> + >> + return; >> + } >> + >> + imsic_update_state(v, new_vsfile_hgei); >> + >> + /* >> + * TODO: Modify the relevant translation tables at all IOMMUs so that MSIs >> + * for this virtual interrupt file are now sent to the new physical >> + * interrupt file. >> + */ >> + if ( iommu_enabled ) >> + printk_once("IMSIC: IOMMU MSI retargeting is not implemented\n"); >> + >> + /* >> + * If any interrupts at an APLIC are forwarded by MSIs to the old interrupt >> + * file, reconfigure the APLIC to send them to the new interrupt file. >> + */ >> + aplic_reconfigure_target(v, old_vsfile_id, old_vsfile_cpu); > > ... here, as it looks. At some point I agree but the steps before are preparation of moving and is a part of moving process. Then probably it make sense to reword the comment to: /* * At this point, all interrupt producers are still using the old IMSIC * VS-file. Allocate and clear the new one before redirecting anything * to it. */ Would it be better? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Sep 21 08:07:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 08:07:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427133.1649752 (Exim 4.92) (envelope-from ) id 1x8Z3v-0002a0-0O; Mon, 21 Sep 2026 08:07:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427133.1649752; Mon, 21 Sep 2026 08:07: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 1x8Z3u-0002Zt-Ty; Mon, 21 Sep 2026 08:07:42 +0000 Received: by outflank-mailman (input) for mailman id 1427133; Mon, 21 Sep 2026 08:07:41 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Z3t-0002Zn-HY for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 08:07:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Z3s-003WJZ-Fs for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:07:40 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0e5c4-bab6-0a2a0a5309dd-0a2a450b9b8a-48 for ; Mon, 21 Sep 2026 10:07:40 +0200 Received: from [52.101.72.114] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0e5cb-b7e8-0a2a450b0019-346548729991-3 for ; Mon, 21 Sep 2026 10:07:40 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by AS2PR03MB8772.eurprd03.prod.outlook.com (2603:10a6:20b:553::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 08:07:37 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 08:07:37 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Y8eETPZwqVGqcJG1FMpkf9H6RYhiZT1uGmT0mysveGHlHcqrPbNgvz+w7Wj/YZ0e5uz+vMIwRMvxl2TyCfr0Eins/IsIL0avOF565HtvmNhvSU4N5BUCGXNQnuyFyY/Vu++NIT0nGhxUKQb26Woh23XLH4YY8SdKoHigJDMCCnbCMEBx60eAwJIAP4TAMAhyRdnpM52tP1+9qo56KyCbq5pr3+Mhj1LRRORQY3avFcrEdryT2E8NkhXAY0fz8D2M78cpLu6v6jf1A7uHPYdYDG/nPB7bjqfhEPr0yoB+r0zghplGbG7U9iKjGPvzmk3xaZIADfAJF5ljFd2EqM5+zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lvwLDzR5sUVcCzmMmiZ74UtWe5DtMurUl/eWE9De9aM=; b=AY7+wVrrCWUrCyYEZsSOD8bAwu3O7sUt+0X2U9/d+A3uqKNbKj79MDf7aCDZeKRh9U7QnJ9CvH78alQkQdHrQL20a/AB2h8EOZf+NUMjywSbEps8FyTKgICQ9ECPEKYvwhiqTFfNwhAZc5GgJogHHealvo6PtAj/ftczequtbTFq/zW+w9+9T22K8+SMf0Z9wL6oQDgYK/Uz7ofoApWUykvz64R200PnmhJtVz3MjUwjkO4phRxVFD2tAYXOq/FHaGsrIYqiIsn7E7AO7YCBWMuuDyG+5/WNOMfMIz3dtuX3KJ6AsL1IUUratMJZtaklGtXIX4UrS4AeramH9DvUTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lvwLDzR5sUVcCzmMmiZ74UtWe5DtMurUl/eWE9De9aM=; b=aVEWXGSlfCzktiz1zZ/viRBDfIyQdFxPTGfAgbzR7z83uXpztlb8c624uWwEkgXNk75qMcy7A78JJMDjP5ZYQ1IQPX6v+JE9GbYml4smfW6hJ2rdQGM6sVwYjBSxshGNGXviC1eq51hESj3W08Rx56GP9mBaVL2QzoYTQ8pDxav8GKcurMR/8Mm/I2K725e1ETSn22ny33OIe50BftQpvZ6Wt7PM6mUf0arsIIJjK01R3xu9PcB1pQLvC9yZXmZSlQoi1S9IAzGCWGUN0xTnQZjOlQCKDhyZIiKL419K6GBZTa0apIeyBfXlzpXgUnRje3VG6whsd3leSNgn1QjK4g== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Mon, 21 Sep 2026 11:07:32 +0300 From: Mykola Kvach To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v3 1/4] xen/arm: make is_espi() a pure range predicate Message-ID: Mail-Followup-To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel References: <8e42437f8abca2722f1a2e2568bbb5b938c23e85.1787050437.git.mykola_kvach@epam.com> <87o6erxd1a.fsf@epam.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87o6erxd1a.fsf@epam.com> X-ClientProxiedBy: WA1PEPF00005B70.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::609) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS2PR03MB8772:EE_ X-MS-Office365-Filtering-Correlation-Id: d700d524-afd7-4ea4-b084-08df17b76645 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|11063799006|6133799003|10067099003|5023799004|4143699003|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: IcjFi/PNRTsX9Ll+JUC8yFCasv+/ijU3K7zl1o7RJB3jX9Z/plzuh0iZlaN7NcLA+SZUzdIL84rFT9zthuWhzvGGC6C0inh83niEoDTPoEPR0N11zfOClODGZ3fLvbxqzOED/SQebleaF3THOktQfiKYSVDVlHI0c1bo3LsvyyumILB/rkEnqldk6J3X12DXONyJ2fXshE7n57Qaz564x9nvpGVtpRCpwtyTISYYfJiae0jtreFsQOY/gGyfdYRb38oTIMRz6SN1TGW/BSx7tXcqF3ehkBF1XfszoJhng7+3kz2q2OpcEuzvOq4nMV0Nq9tvMdyu8e1m1A+M7hB39uvDNlM2km2XycIc7xgV7GxeCDSU2q2bcRpPT0+jb68gY9fKSIm76Cmx059DxLV9MoovJk6tjlYH+MTSQYOR7wzfB05iIq9xIG1Ihth7oVRnaBtRrplz8RVYG4aw9Z/8Uwy9Hv40NvlCqXrT0nyse56pUDShkZg8EDjnIAI3RWGW2JQyxBpucrdFo4CT/KUdiqzW4GC+o/WwueNC9c/zEXanTSmeKXEa4AtF+ySwhlA80ACPKd8o48xNhsegVkShCYmNQXMd081iza0+MfY7ORMHkHgrcG6O4xaik89aiCWo X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(11063799006)(6133799003)(10067099003)(5023799004)(4143699003)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b0tpQ2orNmRaU3VUaTRyR0NvaFlXa1NLRlhEYlNaYVZhMjZsY0dKUGNhWllK?= =?utf-8?B?N0dhWGJnQitWSTkxeXNHRlFlanBrVzhEMzc1dXU0M3hkajVTb3JOTGk0M1M4?= =?utf-8?B?UXRUeG00N1dpblNvRk5ld1gvcm5iSUEzTWl0T0hVdTB2Z0FBL0VBeERJZW1H?= =?utf-8?B?Q2t1dFZLZmd1cVFoKy80Z3J0RGd2bnJaR1NKOGl5bmVWNmhzN0lsUlFWaXBs?= =?utf-8?B?ekdxRVZuR2pwNWQ3SHhxNlB5MVBwUyt0Q013STNkMDZzZlZpOGhDa1p2SC9S?= =?utf-8?B?ZjN6RmZ0SlgyZU5YWFZOVlJFS2tMVUFPS0N4eldMdEs3Si8rbzFqbnRmaWFJ?= =?utf-8?B?bi9GZG53SytBWUduQ2hvL1I5eXl4UW9pSEViSCtvMEQ0YzdZQ01TY0gzZ1I3?= =?utf-8?B?Y2svdTNrdG50K0UzOVBPclhteDJiT1FTS25Fd1VZSUl2MFFUNTMrb1lkcEky?= =?utf-8?B?OCtsbHp6RGZwNXdBV3N2VUJTNFd1cCtUS3NJc29DVStCQ0FZTzVlczNqRW5P?= =?utf-8?B?bjVrNjJDU3krTUVCbklFVXdjUnNMS0hYVHozQmR4RG4rYjYwV2kvK0lhWFdD?= =?utf-8?B?UFpzK2g4bzdyN0Evbzk1eGhWSmVpeGVOSS9CKy84am1nRmJFaXNIUVNFSUEz?= =?utf-8?B?aldXRVFITWdYNkZGTjk0MUdleS9CWWEyVmRqMlZGNk5Ja0hjNWlWMDJZMmRW?= =?utf-8?B?bWpqZmFBNDNVVlJzWEJ6bmI0YWhzbXA3OG9uU1dRQ21JTVdoaHpPajVWSThC?= =?utf-8?B?VHVBeVY1c2l2a1c4bmdOelB1cTRMb0VZemRiVEJYNTJySWR5NE4waWwrbGVr?= =?utf-8?B?VkZoZEZxdDF2c0JPcVdjaDdIUkJwdEMwdEVBNmQ5c0I3WTNpK3YvaVY0OC8r?= =?utf-8?B?Qkk5Q0dIR0U2YW5xRUg2NDkxTEZqMEdDbEE0SExOcGs5cExNMTErbWREU2s5?= =?utf-8?B?OU1IVHNCTU1uay9kWVExWHRUMGE1bnJZQXlUMGRSNllVazVyM0RnWXhzQUhk?= =?utf-8?B?R2F3a29IRGdTT2FqUjBEaE1STFpiQTFjd0s2SVAxbERxbGR1aVk3eDVwMnh1?= =?utf-8?B?VkdVbUt1bk9tWkxrRjZNeUJReGxRcnNEZnk0R2h5Zm8xWWQ2YUFlaVYwUlMz?= =?utf-8?B?UndpYjZTT1F0aE1Nemx4UXh5M3hEK3hOUHpZSk9PQ3ZwazMzSVg3b3VFM0Zl?= =?utf-8?B?OHFpVTd4NTZnSW10ZUZOa2pka3dLTU1oeGFVVFR5RE1RZ1RjR0NwVkRzQTIw?= =?utf-8?B?KzlHNklCYXN0UTRUaHRkV3BnMWRBYUpaQ3IvUG4zRm0zNjU0OXRYMGUvZ2xM?= =?utf-8?B?ekRxeXJCL0Q3OG5oYmhjcDFFcWk0S0NsVlZFQ0o3ck1iVmNnTW1sdVNud3ZB?= =?utf-8?B?UENrZU1iMkJRZkJSNGNYM0JwVDRoZjBPU2tDSTZ3Wk51QTlhN0RpSXc2R3lC?= =?utf-8?B?TERHWkw3TkRnRW5MaWhibGNodStVUzhNc0ttSXNrM0FjYXpEajMrNW9CWGIy?= =?utf-8?B?blJFK3FUTWZhOVEzazlQbjZ1VzJOdmFNUmRXZkY4Ty90S3lpT2NnUUFPWUdG?= =?utf-8?B?OHRsSk5iOVRKMDJuRCthdGFYOGJ1Q1VVbEhuWFFWSGM3U2xYNEZ4U3dLYmRG?= =?utf-8?B?aitVNTZyckd6NkI0QUdhdXVwam4rMlFwNzJiVUs4MWhYc2E4SHcvay9ZWHkv?= =?utf-8?B?S1RLSVExd0l2ZzlmMzIreDU5eWFsYlNOVUx3bjdHMHpTYmNVbWlnbjZaQ3VU?= =?utf-8?B?QUxwK3M3ekJkK2hPN2Q3dTR1eXF6VjYzWmxCMEc2NEU5L3EwK1VDQk4xM05O?= =?utf-8?B?eG5vSHJHZzMrOWJ1cEF5SkRvWkRoVzV1WnN1Mzg1RFc3emN4dG1MOXR3aGFF?= =?utf-8?B?TmRjMTNPYVI3TDNWRks1SUlmVzBCNUM3ZGtyVkpkdnBFT0I4SnYvRjFqWU1D?= =?utf-8?B?SU9TamRLNENwZU1QTkdzRksySnNlOXFrNUhWWTQybGZMUnA4QTY1c2k2Tk13?= =?utf-8?B?MHl2ZmgvcmtjVHlxVjhlSHNxTWp5MFdITWwzZ2JPL3FiVTl0Z2RtQlptNVd0?= =?utf-8?B?aDQvcVV1SmUweW0yU3k0eHlwSkxhUWNzMk5MNlQyOEdJUjFuRjlzVE0rRm5p?= =?utf-8?B?TktMY09RbzNFdDJDc3RiMGFsSUQyYjRwcGRDUXFtRS81ak5NK2JleCs1eHdj?= =?utf-8?B?Y3F3QnhvdlY1eW5wdkRIZk40NEdGeE9VOWNVcGV0VGg5c3M2bTNjU3FWZ014?= =?utf-8?B?RWRsanlLMWg3UFN1ejdrQUovcHorM0h2WkhZSEFBdGJPV0NNcEJ5VlMwblJI?= =?utf-8?B?Vjh4VEljZE83cEZza0t2WWRaRkVVc2FJMUNKZjU3ZjM0aGNWRlZNUT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: d700d524-afd7-4ea4-b084-08df17b76645 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 08:07:37.4839 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Xjs1m6vFimVYurXNaUwa4ZJv4XKEiLGjwB+wiCP9YzEarix25TxoHOFNTu19lvQLQgIr81nl4bLVluA7j9rcIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB8772 X-purgate-ID: tlsNG-42698a/1789978060-A9AC09EA-B50BE743/0/0 X-purgate-type: clean X-purgate-size: 5294 Hi Volodymyr, Thank you for the review. On Tue, Aug 25, 2026 at 03:24:44AM +0300, Volodymyr Babchuk wrote: > Hi Mykola, > > Mykola Kvach writes: > > > is_espi() currently changes its result according to CONFIG_GICV3_ESPI > > and asserts when an eSPI INTID is passed to a build without eSPI > > support. > > Probably you want to reword this part of the commit message. I think you > wanted to say that "assertion fails when an eSPI INTID is passed to a > build without eSPI support". Sure, I'll make the assertion failure explicit in the wording. > > > This makes a range predicate carry configuration policy and > > causes callers to depend on its hidden side effects. > > I'm not sure that I got this. I meant that is_espi() does more than check the INTID range. With CONFIG_GICV3_ESPI=n, it returns false and asserts if an eSPI INTID is passed. The callers rely on these checks too. I will explain this directly in the commit message. > > > > > Make is_espi() report only whether an INTID is in the architectural > > eSPI range. Gate eSPI handling explicitly at call sites and preserve > > the debug checks on paths where an eSPI is invalid without compiled-in > > support. > > > > Signed-off-by: Mykola Kvach > > --- > > Changes in v3: > > - New preparatory cleanup requested during review. > > --- > > xen/arch/arm/gic.c | 5 ++++- > > xen/arch/arm/include/asm/irq.h | 11 ----------- > > xen/arch/arm/vgic.c | 4 ++-- > > 3 files changed, 6 insertions(+), 14 deletions(-) > > > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > > index 078049e741..075e1d2c50 100644 > > --- a/xen/arch/arm/gic.c > > +++ b/xen/arch/arm/gic.c > > @@ -348,7 +348,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq) > > /* Reading IRQ will ACK it */ > > irq = gic_hw_ops->read_irq(); > > > > - if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(irq) ) > > + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq)); > > I am not sure that it is a good idea to put ASSERT on value that we got > from external source. What if Xen is build without CONFIG_GICV3_ESPI but > hardware really reports an eSPI? This assertion already exists inside is_espi(). It was added by commit 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range"). Before this patch, gic_interrupt() already called is_espi() with the INTID read from hardware. If the hardware reported an eSPI with CONFIG_GICV3_ESPI=n, that assertion would already fail. I moved the check to the caller to keep the same behavior while making is_espi() only check the INTID range. Leonid explained the reason for the assertion in [1]. Without eSPI support, an eSPI INTID could lead to an access outside the regular irq_desc[] array. The assertion was also present in v7 of the original series, which you reviewed in [2]. We can discuss changing how this case is handled, but my aim here was to keep the existing behavior. > > > + > > + if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || > > + (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)) ) > > { > > isb(); > > do_IRQ(regs, irq, is_fiq); > > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h > > index 09788dbfeb..c29f3d04a3 100644 > > --- a/xen/arch/arm/include/asm/irq.h > > +++ b/xen/arch/arm/include/asm/irq.h > > @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq) > > > > static inline bool is_espi(unsigned int irq) > > { > > -#ifdef CONFIG_GICV3_ESPI > > return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID; > > -#else > > - /* > > - * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is > > - * disabled. Returning false allows the compiler to optimize the code > > - * when the config is disabled, while the assert ensures that out-of-range > > - * array resources are not accessed. > > - */ > > - ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID)); > > - return false; > > -#endif > > } > > > > static inline unsigned int espi_intid_to_idx(unsigned int intid) > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > > index e5aca17dcb..e14123a30a 100644 > > --- a/xen/arch/arm/vgic.c > > +++ b/xen/arch/arm/vgic.c > > @@ -718,8 +718,9 @@ struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq) > > unsigned int idx; > > > > ASSERT(irq >= NR_LOCAL_IRQS); > > + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq)); > > > > - if ( is_espi(irq) ) > > + if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq) ) > > { > > unsigned int nr_spis = d->arch.vgic.nr_spis; > > > > @@ -949,4 +950,3 @@ void vgic_check_inflight_irqs_pending(struct vcpu *v, unsigned int rank, uint32_ > > * indent-tabs-mode: nil > > * End: > > */ > > - > > Please refrain from unneeded changes. Ack. Best regards, Mykola [1] https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00380.html [2] https://lists.xenproject.org/archives/html/xen-devel/2025-09/msg00422.html From xen-devel-bounces@lists.xenproject.org Mon Sep 21 08:11:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 08:11:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427139.1649762 (Exim 4.92) (envelope-from ) id 1x8Z7t-00046o-FS; Mon, 21 Sep 2026 08:11:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427139.1649762; Mon, 21 Sep 2026 08:11:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Z7t-00046h-CP; Mon, 21 Sep 2026 08:11:49 +0000 Received: by outflank-mailman (input) for mailman id 1427139; Mon, 21 Sep 2026 08:11:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Z7r-00046b-9y for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 08:11:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Z7q-000Jz5-If for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:11:46 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0e6b4-e002-0a2a0a5209dd-0a2a450bdefa-34 for ; Mon, 21 Sep 2026 10:11:46 +0200 Received: from [40.107.208.61] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0e6c0-b7e8-0a2a450b0019-286bd03d48bd-3 for ; Mon, 21 Sep 2026 10:11:46 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by PH0PR03MB989332.namprd03.prod.outlook.com (2603:10b6:510:120::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Mon, 21 Sep 2026 08:09:48 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 08:09:48 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Tvs2/sdIvNt0bb9Wi1LkBdNcwqCteg9DHmbvTyg5TSZVhPt3FZ4zUXIU2Ug5cMacC3V1gboiRzytxFOm3L2ZwSBu7c5igz/kS9o3NJM4WiD2tPm+n6mZxeG+aE+4QJR4dH74SENB19MoiKqCwoRZNKU1el8mbfqlNJXljdA1sXVnkm8mco46FoR6c1iddT44onOi/WmuO42/M5i8HOlROoUPi4+1j2Scalr+RsMXLLJLwgxe2gtcn6shxpjKuWUyU8fPbAHxxU2pka4i94X8/ltYt4s1kaAqBETk/7ZURNpCA/pYmqdofguFHuJHm+x3CxqdXV1xmP30TCZx9RXnZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SU30me+7oUzPyjyBP7bGt/BtRwrgcEiRGeIVhWCmOoc=; b=Il6fYLt/3++NIUR3KVZ2BEwXpq51j2woLG2zYnQjKJCUewKNUabgGiPelLBwQ2FsxxKUUW+/Wj9umaP/bYDdGea6pFjBlMvZO7VJGZqCgUPsVedGBQlPF5qVFu72MQIDvK5BgiLMCmvZ1WBY+faUMOsvXS9gOn66qb3jg2LzYFYKfBCG19rgKdI0HdYRLcpwX1Ff1DWXw3Y5ZP5ZajQ7m8D2SDpmFxdJ8EfIdKZJx+Q6AX4f8mZb99ZgWpUc6jzt7ey2kgV1E2upRXZo7DQpkVBruz0SKIM18Pq/R0jyMEaxRVoTEs2gKbpv1mJ+KMhZDflRaJAytFTok93qpnYOeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SU30me+7oUzPyjyBP7bGt/BtRwrgcEiRGeIVhWCmOoc=; b=vq+jaTfpzhQ2zpzWSYlChW0DAankvMlS4cpjA6+oTUpHmWYyq1EgmR1sl23/C6qEpWFyKaQO5F+RZuEW2bvrs4KR9wyUBL+ZSCkz6X1MAmfj6T3sMYYwiUz4F/dbWof16XLUx5YFgC2P2hvubNBa74GKmyfe1FatFu+qEpsTgAg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3283039d-e0cf-4d84-9fe9-ccef041fddfb@citrix.com> Date: Mon, 21 Sep 2026 09:09:43 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] nestedsvm: Don't set VMCB(1-2)'s NP_ENABLE and N_CR3 during VMEXIT to L1 To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk References: <20260918125205.374168-1-ross.lagerwall@citrix.com> <1789931442.8631fc262581453bbf619ec5b2062170.1a0c03a526800072c4@vates.tech> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <1789931442.8631fc262581453bbf619ec5b2062170.1a0c03a526800072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0511.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::18) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|PH0PR03MB989332:EE_ X-MS-Office365-Filtering-Correlation-Id: 8676fcd6-cb68-453b-d594-08df17b7b46b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|11063799006|56012099006|4143699003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: ZEYOZ7rXi9rLlnEQNk4dOv8gA4bjlNwDXpq4oPpykv9G4O2vDv7rqX02RYR88ib5q3b3zrj4+HrQyjAL9k0wn0l++gR4Q3UIaqgqOi9fKvT/nmcJqhmLwh0cucEwYc+y6bBmB8RMctyECss2b4LCIaf3su/3THwO2V3rIoyOQiDTSrjv0EDPnrMA/fFTmwo0PRe4Rn3AYJ2/zpPIxgzJ1CeRf3xuQRvOeLiWr80j2veYQXdBzTbXVPGMNZG/o7bTuvwVm0/HV6YP0HjvckKi24oi7gS6oD5L2VyyWk55JKimlRGe/BWeD7Fgermkb96HiO/pF6cEY4kHZOvmLCECtPUTrKD3Gk4IT4HhVmKpWMVqvuXSxNxOwY5vW/XNLM7jciIvYBl/txlrbm/P3KghiFQfALo4KNhi0RN3UikZ9noAjtJ/HzNl0VX+wwSrkyROlKKBfZWXE4/yeL/0Hf8c6Fhou7diSHfxlOreVPTnwyaiDGOKn4f9i8NGCLtyQ+MMwpi4L4GpkIRihF4UJ8TxeGR1C3GV7WsFthDKSooZS9KuwB6V4UCsumUdAzMNYbz6zzaNh0PNtT4T+I4Sf8bAjxFUL/Y6XOGjFPzzcwxZR78s3OJiTCa/kvfi8X/4TJz4IdxJE3sJOPvyLtRbcDOjHIaVvQIWfYTq9G2TjdBKm5o= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(11063799006)(56012099006)(4143699003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VzFyL3o1ditvTTNWODlZOVNLYmFsQjJRajFoWFlRTU1yVkE4UUd4a3FIOFF2?= =?utf-8?B?clBYeVFac2VOcTVSaGhQMXpOVHFaOW1QMVhmVTNBU002NktBS2FxamhKcC9l?= =?utf-8?B?dUxRVFNMYXJXbEVoQk0wNHNHbTZKVDBLaVkydGdNNW5pU1hnL2thTWZuUm5G?= =?utf-8?B?aEJPeG5tS1Y1dTU4SjlSVFp1ZmxkTHhCL1dOWGRpejY1RGtZNEFHeS9tZElC?= =?utf-8?B?c3hrQmVyZW51UGhWd2ZQaVBJa0FQNDQ3UlBLQUsyVU16VGd2TGx1bEtQZ2ZM?= =?utf-8?B?OWl6dkpIUXhaT1JIWVhUTnYwUzNzZmdIdUp4ejFkckhOU2VnZi9xdGxvK0FL?= =?utf-8?B?SExTNVYrS2ozMktTN1FJZ3pLQWU2ellkSUZNcmhKcWYrT3EvNHg0NCt5bUpZ?= =?utf-8?B?QnJaOXY3cWJkcHR5SkttWWtvaGVBbklJWjZyU3dIblRtRHkrZTd3ZWlSSTl3?= =?utf-8?B?WTcwWHpNVnIydmZub2pXNXZlcVI4aFlVWlZ6UGJEYllhNDhoNlZHVEVCUmto?= =?utf-8?B?eitPdTNaeG00UHpiSnEyelhFeXFZeVNLS2RIZGlhaWNWSHk4akZ2RDcyeUJw?= =?utf-8?B?N2J0Z1lxY3EyK2RIdm04TkczTTgrSys3UTlyZTYyTGVrWGd3a3dmaUE1Vm1L?= =?utf-8?B?TEc3NGhqNS9lYXNLeWdtTEI1cHF2NncwTTZKdXlzaFFkTVdEUXBHMlhjdGlJ?= =?utf-8?B?d3FQOGRLR3NpS2xVOHdYdWM2Z0xQcnhiaW1lQmpxd0tqRkdmeTNJalBkSWZR?= =?utf-8?B?SnRUVWwzZ2xtZnhlVXkxdFNaVHNJTHowM25ETDVQOWlnSTZhRStXNlIzRGRC?= =?utf-8?B?WktEVHhkOWlpUklLeDJoMDVxU3M5WEZiSzNtTXJLQjJMYmxWeTBTcVd1WjBv?= =?utf-8?B?WXlxb2lUeXBMMnNMQWhMcUt2UnJqSXNveTdWYmYvZjlwbG9Cb29FalI4Rk9R?= =?utf-8?B?NEIrSk5Md0c3NHNiZUdiTFB6eThGUVpQNUo5ZFpHQ2dFbTRmaVcxUDUzMlp0?= =?utf-8?B?RHA3UkV5dWR1dzhTRUJ2OUFxVGJBbXdpUzMrcDI4eFVSQi8yWHBrMGhMbVBH?= =?utf-8?B?VTlqazdnLzhXQnBDQndueUZQcDVRcndNVXhyQkNVQy9TOTlSa0UxM1Y2QUg5?= =?utf-8?B?UXZlaWwrc25tNm83V2Q5UjhnMEpQejVSQWszbnNBZngyL2pvM21CYmErK1lH?= =?utf-8?B?MGxnaE80K2c2Q0x0VjNBMkZhek40V2ZYYmxpZG01bldWRFNjMG9QQ000Z0Fk?= =?utf-8?B?MVMvdFpIdVc2blZseGtWQkZWWXczdDlTelpQb2ZlbGlaMXRvakRSWmE2UWg1?= =?utf-8?B?K1lWMDQreGJBZE1JOGZIY1NId3Z5SHJWcHJHRTJmS0wrQnBYNUduWUVpQkRa?= =?utf-8?B?bFlsM0hlc1pXVm9HdjQ0UGJ6bW13NGVJWWpVWDA3RlZpaXhZNGN1UnhlbFBp?= =?utf-8?B?WkhFT1NnY1ZEeVkzSHVFbjJCbS90aDJvOWV2ZEtaZEVha2xUR1VBNmh2ZXVE?= =?utf-8?B?bDltNkllc2Z4QVR5SnJoN2dpaW1oMFRDZGlkQU1DaER2Z2hyU0lrY1JQc3I3?= =?utf-8?B?WCtyVkNPTTl3aHhGeWJWaGRzbVZCdEcxeUpFRW5pd1ptSzFOUm5hRFhGekk2?= =?utf-8?B?Snh5K2lhVDMyNVVTQ1N2Ui9LdUQvNDV3NU9JWlZ0a0NsS01BYS9VcFVJQUFB?= =?utf-8?B?Z3VKL0Jxc29NcFVTUzNqWThjZmFrN29nUkF1cm11QXhXVkxEcy9VeTF1RVk2?= =?utf-8?B?d2RCejVDMG5pTHptWnNvUEVxTUlRT3RVR2ZDZzlDNjhjQXgzUFJGbmpjdGsw?= =?utf-8?B?WGhRT1J6TlY0QXJ1YU5QNDFKTkU5K2FmeHFncXZ0MlJDY01DU1UvcUE0bnlP?= =?utf-8?B?ZWZwYWlLaUxvczNsTnRldGovRThHeFNFYTlGV3hDNVIycTdFYVVPa3AwbEZF?= =?utf-8?B?a1paVkMrd3l6WU9OdVYvTG9mbTZBaExYSkZjYi9vOFN5K0ZUVTVMMmt2a1RM?= =?utf-8?B?NzI2UmZlLzFWc3hTdDI3VXRTdXNhZnlXWnVWcEhyaUhSNEdCU3MxUXQ3UnEw?= =?utf-8?B?OExLUGN4R1NXZVJEdGV6am56Tk14OGREVnRVSWRZOG0vMSszSDFyRUJ3OS9F?= =?utf-8?B?T1U0bjB0UXBTdEw3ODkrNVFnZUo1ZjB1WUZpb2g4bGJzL2s4UEpBQnFOYW1D?= =?utf-8?B?ODdnOThwRTd0UExmU3IrV2hrUmN5OVRocUEvNkQvOTZWNEdPeWF5eU5QQUFI?= =?utf-8?B?bjlIeUt5V0RwbTlLNDhVTzVqZm0vMDlPRkQxczRnb3d3cEVqcmNCV0hickpI?= =?utf-8?B?QnhXL3lia2xIeXVUcFBYMDlQU0tMY3I1bHlkRDFNcmVweVVYVnBtLzFpV2J3?= =?utf-8?Q?Jg+FpsHjTMgNs0Y0=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8676fcd6-cb68-453b-d594-08df17b7b46b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 08:09:48.4963 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dbEskV57CFlAyeQcJoBSyvZXIM9X97VtvKoGk1aS+OLnqxHgKJyWnQ5uLwDysUqrGOjhNwdL98du7bupg6qgXWZFxDuM1Ack0R7D8rLuZOQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB989332 X-purgate-ID: tlsNG-42698a/1789978306-1AEDE9EA-831DEDDB/0/0 X-purgate-type: clean X-purgate-size: 3071 On 9/20/26 8:10 PM, Teddy Astie wrote: > Le 18/09/2026 à 14:54, Ross Lagerwall a écrit : >> As per the VMRUN pseudocode in APM Vol 3 3.38, the VMCB's NP_ENABLE and >> N_CR3 fields are not set during a VMEXIT so don't do this when updating >> VMCB(1-2). At the same time, cleanup the somewhat bogus and irrelevant >> comments. Not clearing N_CR3 does not introduce a security hole as >> stated since L1 can set it regardless and it is never used directly when >> running L2. >> >> Signed-off-by: Ross Lagerwall >> --- >> xen/arch/x86/hvm/svm/nestedsvm.c | 32 +------------------------------- >> 1 file changed, 1 insertion(+), 31 deletions(-) >> >> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c >> index a8b15d6eae05..c62fca571d75 100644 >> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >> @@ -1023,37 +1023,6 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >> ns_vmcb->event_inj.raw = 0; >> - /* Nested paging mode */ >> - if ( nestedhvm_paging_mode_hap(v) ) >> - { >> - /* host nested paging + guest nested paging. */ >> - vmcb_set_np(ns_vmcb, vmcb_get_np(n2vmcb)); >> - ns_vmcb->_cr3 = n2vmcb->_cr3; >> - /* The vmcb->h_cr3 is the shadowed h_cr3. The original >> - * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, >> - * hence we keep the ns_vmcb->h_cr3 value. */ >> - } >> - else if ( paging_mode_hap(v->domain) ) >> - { >> - /* host nested paging + guest shadow paging. */ >> - vmcb_set_np(ns_vmcb, false); >> - /* Throw h_cr3 away. Guest is not allowed to set it or >> - * it can break out, otherwise (security hole!) */ >> - ns_vmcb->_h_cr3 = 0x0; >> - /* Stop intercepting #PF (already done above >> - * by restoring cached intercepts). */ >> - ns_vmcb->_cr3 = n2vmcb->_cr3; >> - } >> - else >> - { >> - /* host shadow paging + guest shadow paging. */ >> - vmcb_set_np(ns_vmcb, false); >> - ns_vmcb->_h_cr3 = 0x0; >> - /* The vmcb->_cr3 is the shadowed cr3. The original >> - * unshadowed guest cr3 is kept in ns_vmcb->_cr3, >> - * hence we keep the ns_vmcb->_cr3 value. */ >> - } >> -> /* LBR virtualization - keep lbr control as is */ >> /* NextRIP */ >> @@ -1083,6 +1052,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >> /* CRn */ >> ns_vmcb->_cr4 = n2vmcb->_cr4; >> + ns_vmcb->_cr3 = n2vmcb->_cr3; >> ns_vmcb->_cr0 = n2vmcb->_cr0; > > I would suggest to group all the CRn (the CR2 part is currently separated). That can be done separately. > Indeed. The APM says... "Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context:" ... so ideally we would rearrange this function to match the order specified (though it shouldn't make a functional difference). Ross From xen-devel-bounces@lists.xenproject.org Mon Sep 21 08:28:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 08:28:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427149.1649772 (Exim 4.92) (envelope-from ) id 1x8ZOC-00060O-Pv; Mon, 21 Sep 2026 08:28:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427149.1649772; Mon, 21 Sep 2026 08:28:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ZOC-00060H-Lt; Mon, 21 Sep 2026 08:28:40 +0000 Received: by outflank-mailman (input) for mailman id 1427149; Mon, 21 Sep 2026 08:28:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ZOA-00060A-Sy for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 08:28:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8ZOA-00GI9r-5z for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:28:38 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0eab0-8faa-0a2a0a5109dd-0a2a4502ddae-26 for ; Mon, 21 Sep 2026 10:28:38 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0eab0-6ca4-0a2a45020019-4a7de18ce1b4-3 for ; Mon, 21 Sep 2026 10:28:33 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49e69b9e16aso27716865e9.1 for ; Mon, 21 Sep 2026 01:28:32 -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-49fcd0eabfcsm219672175e9.3.2026.09.21.01.28.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 01:28:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789979312; x=1790584112; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=0+e5laBwizznHgMWVoPgYtecdciPAQTbOYaLJI6fY4Y=; b=IAIPzWtAW9RNSYuuDb9lqaSvnRchlEWta305KWfjf1OFQAD5zbDZVz4fy+zaOLR0RQ 1UQmOcbvmFE8l+hry/wWKVHd8XUQossf5HqWYu5uZ2ZfXYjTiHU6wTh3ptBmJlodeNbB h3xuGTx57pLRSG1MGKJD/A9/x8aN9U+tlSRa+XDUWs3cj1xvHqtwxaMiMiBLyrSw4AwW tWRXqvmsKrU+7bnHhhEv8nY067kd/LYCmA7QT7le/LbfSRdHdazx/UtOY08OvBigARtq /anFQ5HEpLnTqFy66J9VWdepidxA5upB7KIBoF2y7girf98TB7FO0kzHmGCkmSKhf/Lu bpdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789979312; x=1790584112; h=content-transfer-encoding:content-type: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:content-type; bh=0+e5laBwizznHgMWVoPgYtecdciPAQTbOYaLJI6fY4Y=; b=jaLRVtu3qexiLNSVj5Y05dJouM2HD5JbUL3LgoRnynBYLqgJda/N6HLS2nK/LFu3q3 W3Nk+zOlA3suSHl/fCQbMCPNhDqWjFM+bzSznwuOZFbc3MF0J1f4EHMmHi1ozabPz18P 37H/Lp4wP70/xljf7Ik0jVDSbpxDMzifM8vkndn3krTDoT1YtHIVNPvoDPHpu5mk9w3n mGNS/4sk/Jr6CvxqyC3oKnbO6r3qIrFngQkvTSh3sIOHJ2pnzI0ZCMz0HUeqIYoBD4WQ 2Rh365taRYhzYzCecms7HzEQgsNT8geAJpJMbug0dktBlFVenPDFLaPtbyReH8bX04df lhvg== X-Forwarded-Encrypted: i=1; AKwUvBwjzId65FGtPbhpX9ONd/vm5Hq5IX6G0iMoW3ZS6TJQodtYEjm/eJ8S6+oX88+sAKc4X7wRlDkGiaY=@lists.xenproject.org X-Gm-Message-State: AFuF++lSfQFL4FCaBgt27u1lzC35AkQ0icyotAFDEY1C00lW+tqkZXkR 6URBoGuLaYCVvxkKjCCeOl5KyBauu8ayrKQN2RfHeRGZ6CKGquiqGOnCXTxPtsQOWQ== X-Gm-Gg: AYBFou3e8blxc5690FKK8XA0VGKN/Z91ryXwnGBmg5yNyF9kd/u3q9ag2jPZ2yZaxCs NluM+M53d4+8cahBv+5zn+WjE6zpi6WsHFvnKsjZcUp9AH3kzIGhrwOX7CycREiC5cuYqFsS2CI XcFpFMiEDl1MEJAUJxydC4PeWH3HcngFMZSPxhkoocZdiWL/OFCG/8WGI96UOVO71GAYZtAnYas S37TIJvI2SayliRAYpbZTF4kWm2EZfffb0fhTPTOlCG7/d+GvAtwcqgRXm68fIMGeDqYIJYvJfF WefHt2lcVo76qP7Dxbuk0egOaO+FkxP049EP4TL9c/rZAahudBYm6pyiW91D362mMbM/J0NPDHn dDl4gV5kAoQj4YAai2Y9wQlqPlOFF7WMTgR6CuN7We4cgmSsFPqUi8ztYa42Q8NSvN8ZJ0Etqhf Pq5uPkCI0fJ1P0bhht1F+7H4H0DnVTG3gT250uBhWlEHqBv3JbpY7RTVRC8PewU6O8yyfHJXW1A GaqWHJOO5I9Nv3/92PlKYB+D8xcnH5OCB+f8K6gJD0OhcV2c6zo9X3mzhQIKQ== X-Received: by 2002:a05:600c:a403:b0:49f:d377:ac24 with SMTP id 5b1f17b1804b1-49fd377ac55mr29928225e9.3.1789979312537; Mon, 21 Sep 2026 01:28:32 -0700 (PDT) Message-ID: <815bf929-57be-4b31-b3a9-a3720f5cd88e@suse.com> Date: Mon, 21 Sep 2026 10:28:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> <2394a616-16be-4657-be17-0a2dafebaeee@suse.com> <9929eb6a-d7b8-4a39-b726-82290983e9f3@gmail.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: <9929eb6a-d7b8-4a39-b726-82290983e9f3@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789979318-666B72AC-C6E18C37/0/0 X-purgate-type: clean X-purgate-size: 4294 On 21.09.2026 10:03, Oleksii Kurochko wrote: > On 9/14/26 5:02 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) >>> spin_unlock(&imsic_cfg.lock); >>> } >>> >>> +static bool imsic_local_is_pending(unsigned int id) >>> +{ >>> + unsigned long isel = >>> + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0; >>> + unsigned long bit = BIT(id % BITS_PER_LONG, UL); >> >> Both can be unsigned int, can't they? > > Yes, agreed. Both isel and bit fit within unsigned int. I will update > them in the next version. > >> >>> + return !!(imsic_csr_read(isel) & bit); >>> +} >> >> No need for !! here. >> >> What about endianness, btw? Does the IMSIC always match the CPU (and >> its setting)? > > No, the IMSIC does not dynamically adapt its register interfaces based > on the CPU's runtime endianness configuration (e.g. mstatus.SBE/MBE): > > - CSR Accesses (imsic_csr_read): Indirect CSR accesses (siselect/sireg > or miselect/mireg) operate using standard RISC-V CSR instructions at > current XLEN width. Values are read and written directly into > architectural GPRs without byte-swapping. I.e. you need you add endianness conversion. >> Overall, what does "local" in the function name signify? (For a static >> function, the "imsic" prefix may also be unnecessary.) > > It signifies that local (on which code is executed now) hart's IMSIC > CSRs (isel and ireg in the case of imsic_csr_read()) are touched. That's the expected thing for CSR access, though. >>> @@ -848,8 +899,22 @@ void imsic_migrate_vcpu(struct vcpu *v) >>> if ( v->arch.last_cpu == NR_CPUS ) >>> return; >>> >>> + read_lock_irqsave(&imsic_state->vsfile_lock, flags); >>> + old_vsfile_id = imsic_state->guest_file_id; >>> + old_vsfile_cpu = imsic_state->vsfile_cpu; >>> + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >>> + >>> + /* >>> + * We don't support SW interrupt files at the moment. Bail out before >>> + * anything is touched, as the old file has no owning pCPU in that case >>> + * and there is nothing to retarget the producers away from. >>> + */ >>> + if ( old_vsfile_cpu == NR_CPUS ) >>> + panic("IMSIC SW-file isn't supported\n"); >>> + >>> /* >>> * At this point, all interrupt producers are still using the old IMSIC >>> + * VS-file so we first move all interrupt producers to the new IMSIC >>> * VS-file. >>> */ >> >> Isn't the new part of the comment premature? Moving doesn't start until ... >> >>> @@ -870,5 +935,43 @@ void imsic_migrate_vcpu(struct vcpu *v) >>> /* Zero-out new IMSIC VS-file */ >>> imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); >>> >>> + /* Update G-stage mapping for the new IMSIC VS-file */ >>> + if ( imsic_map_guest_file(v, new_vsfile_hgei) ) >>> + { >>> + domain_crash(v->domain, "Migration to hw interrupt file failed\n"); >>> + >>> + return; >>> + } >>> + >>> + imsic_update_state(v, new_vsfile_hgei); >>> + >>> + /* >>> + * TODO: Modify the relevant translation tables at all IOMMUs so that MSIs >>> + * for this virtual interrupt file are now sent to the new physical >>> + * interrupt file. >>> + */ >>> + if ( iommu_enabled ) >>> + printk_once("IMSIC: IOMMU MSI retargeting is not implemented\n"); >>> + >>> + /* >>> + * If any interrupts at an APLIC are forwarded by MSIs to the old interrupt >>> + * file, reconfigure the APLIC to send them to the new interrupt file. >>> + */ >>> + aplic_reconfigure_target(v, old_vsfile_id, old_vsfile_cpu); >> >> ... here, as it looks. > > At some point I agree but the steps before are preparation of moving and > is a part of moving process. > > Then probably it make sense to reword the comment to: > > /* > * At this point, all interrupt producers are still using the old IMSIC > * VS-file. Allocate and clear the new one before redirecting anything > * to it. > */ > > Would it be better? Imo yes. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 08:43:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 08:43:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427159.1649779 (Exim 4.92) (envelope-from ) id 1x8Zce-0000Fk-33; Mon, 21 Sep 2026 08:43:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427159.1649779; Mon, 21 Sep 2026 08:43:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Zcd-0000Fd-Vx; Mon, 21 Sep 2026 08:43:35 +0000 Received: by outflank-mailman (input) for mailman id 1427159; Mon, 21 Sep 2026 08:43:34 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Zcc-0000FH-TQ for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 08:43:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Zcc-000ReK-6A for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:43:34 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0ee31-8faa-0a2a0a5109dd-0a2a4501c7d2-20 for ; Mon, 21 Sep 2026 10:43:33 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0ee35-5984-0a2a45010019-4a7de14cf7ae-3 for ; Mon, 21 Sep 2026 10:43:33 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485ac898fa4so2307611f8f.0 for ; Mon, 21 Sep 2026 01:43:33 -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 ffacd0b85a97d-48724583250sm21083999f8f.22.2026.09.21.01.43.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 01:43:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789980213; x=1790585013; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=MmSBsavPa9iLNV0IyjqD5m1QBa+Jzn+kQXoCp/wH6w0=; b=c5EschBbbObNrdx6yPu1sGHTn8QgC/enI4ZbmwtHkbEmC0nbF9OsP2p8HURwdqbu9w 9nGN8UQGULziPDW0dxKSc4tt4ziQKyH13JtpzZgF+O588uD9J7gZm+Mc30713+VIRXU8 kgKrJuHviUO2Fi6SjxdudurEF2DGYsp1jTUtDJs5UCZKfYQBzbN36/MtaUGeJ2ZaE5QG +NW02U9/pcWw03lipc21HH98fu0Rso91bu9H8CoP/UTEOCI41mYncLZWsEcZcWIjjDVw FzdQv5hBJ95OrU8L0p+ryShEiU8Em1Lce/Dm1ylBdHmPZCgL1fdFqLcBLFr6oM05XVWi n/XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789980213; x=1790585013; h=content-transfer-encoding:content-type: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:content-type; bh=MmSBsavPa9iLNV0IyjqD5m1QBa+Jzn+kQXoCp/wH6w0=; b=JOmRv0cXczdWPkgh3MMlpkQMPPdmQYx/nBQgjljVOE2UaefCC206+uYPgcJfYzOzKP 6CtoQPkx6SYmyAvKkRruPvhVJbWIAoWu7HlYSwkEoxy3CeFpds4K0iWxyVdY7SS+uNdX 4mU7DtSV5S9CIMoEoy3yIYFmsJ4oa38He/F2WytrK9lcSPbhbwzLfl2Ar0uwxGlgtXp3 n9mE4lqi1SyLmLYSMKOBBX7bSxnaLdRYcYoUSJc9aUzde3pnIHSIEUSmHOW8PSPEpjGf 96ODJxqPmljZU6EMM1ML638ufAr2xoW40vZvdnOrOUhqOfi0OiPcegdmdPZzH0nrjijC CfcQ== X-Forwarded-Encrypted: i=1; AKwUvBw5eYh62jfvRrtydbcjQizjvXVKBai7Zm86uTyQ0kAW5oVYb8vme4pS0QX4BpaqyGiONxG0C19mJGM=@lists.xenproject.org X-Gm-Message-State: AFuF++kwK906Q8VwAUYgzbuc5qvKm8dAI15zKzBkqg+BEi8CqfKyk5VN Bz0amiGiefGQeTtBz2qEEW6pPaYKnMziz4NTMFgie7lfZ+R7IYlZuvEDFHd67TKCqg== X-Gm-Gg: AYBFou1tnNdcf5nU+iZpIKgKWRder5JVKWeB3HfKl6zaQD4VgZ8mOaDJRt770yWCwSs 3s3onOr/suPX0vSgyI1wCu3BaT8kkVl7ejB8Y9vAB2dn8uTUV5L1Ju6yfvUSYaB2Vl9wnDx3Q/U VBF8NNitv5ZKsSLlzmlkoV58+zxJ9f7MXwTblOZRVNsx8Gy1R+YDnVU+jtiH9JIuemnhW/qzDy8 sEfW58n72Bz0XAPKNQzxDD7XFlDLoqSQa6tA+aV8BtVnoB/IYCXBn0wnCmIFlxtDq0h/scJfrwf YnhiTtShEnfJQ8BZLuunglLn3W/3wrzicN0UDPacQuqXpYGp4FC9CzrNVI6FBFhoDifjj4XSgMY 9U6sUsboBsl0RW+ddVpe/xiNSHCg9UGdk3woqWPC2xmaJ20e7kQ3zxOZtqhTrAsxt5tL88wweuK 6WkqL4+lXrBf2ST6QN9et/yoz+EX+N56ihD6lhORqkSjDm3YW5/eNGHWLGn4zh+N4CeNqRQd6yI L/Ra87Iodecz1/REb28mr+3Z1KRMb6zbfMYk2oPrDQJY3llp++8jezZciCwjw== X-Received: by 2002:a05:6000:2884:b0:487:360:5be1 with SMTP id ffacd0b85a97d-4871e2112femr14096932f8f.8.1789980213398; Mon, 21 Sep 2026 01:43:33 -0700 (PDT) Message-ID: <09190c27-fd5f-4f7b-9d2b-be03785c7bbc@suse.com> Date: Mon, 21 Sep 2026 10:43:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] stubdom: remove build of zlib To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Anthony PERARD , Samuel Thibault , xen-devel@lists.xenproject.org References: <20260917075351.37208-1-jgross@suse.com> <20260917075351.37208-3-jgross@suse.com> <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@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: 8bit X-purgate-ID: tlsNG-d62444/1789980213-BCF47757-20A7A38F/0/0 X-purgate-type: clean X-purgate-size: 1088 On 17.09.2026 14:31, Jürgen Groß wrote: > On 17.09.26 12:51, Jan Beulich wrote: >> On 17.09.2026 09:53, Juergen Gross wrote: >>> The last users of zlib for stubdoms have been removed. >> >> Looking at patch 1, I can't really conclude whether that's where the last >> user disappeared (no occurrence of "zlib" in that patch), or whether this >> patch really could go in right away. Please clarify. > > It can go in right away. The last user disappeared with commit > 6a94eaa2bf3fa06b05ed2dad3dd9116060235326. Apparently not: names.c:18:10: fatal error: zlib.h: No such file or directory #include ^~~~~~~~ compilation terminated. : recipe for target 'names.o' failed make[3]: *** [names.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory '/builds/xen-project/hardware/xen-staging/stubdom/pciutils-x86_64/lib' Makefile:37: recipe for target 'lib/libpci.a' failed make[2]: *** [lib/libpci.a] Error 2 make[2]: Leaving directory '/builds/xen-project/hardware/xen-staging/stubdom/pciutils-x86_64' Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 08:50:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 08:50:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427166.1649790 (Exim 4.92) (envelope-from ) id 1x8Zj1-0001q2-Op; Mon, 21 Sep 2026 08:50:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427166.1649790; Mon, 21 Sep 2026 08:50:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Zj1-0001pv-Kz; Mon, 21 Sep 2026 08:50:11 +0000 Received: by outflank-mailman (input) for mailman id 1427166; Mon, 21 Sep 2026 08:50:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8Zj0-0001pp-DG for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 08:50:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Ziz-00CPc3-QN for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:50:09 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0efc0-8faa-0a2a0a5109dd-0a2a4502d2a4-10 for ; Mon, 21 Sep 2026 10:50:09 +0200 Received: from [74.125.225.88] (helo=mail-wr2-f24.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0efc1-6ca4-0a2a45020019-4a7de1588072-3 for ; Mon, 21 Sep 2026 10:50:09 +0200 Received: by mail-wr2-f24.google.com with SMTP id ffacd0b85a97d-482f63546c3so2097846f8f.1 for ; Mon, 21 Sep 2026 01:50:09 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4885a0549c3sm8650879f8f.25.2026.09.21.01.50.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 01:50:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789980609; x=1790585409; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=kMNDPIW1M+Dnfnntk5+ZE4qyCf9pl2+3W+E2riidDAQ=; b=OHdLd8iG3AAEykemnzEYZ6wJW6ca78hFheu4kM8hSKXNo7iGoFOLc9aD0R7v3Tb37R eoXrNp4EKhdQ1tywhgSBV62gkMnVld7tEQ5Wu4PDLSYSFR47ziMpZOqpuml10BTrboia Pvi7MHnqhjcdfX44xQLOP0Bq8eKRrzCbq3HgwjgrsVnx2ITeoPoTzX2bomjoxOpBS80v DghjzpA+nf754QJjimczfnIofUbWOnkuHlkiSjgYS1GmFQtK2CxexxMiw0N1kKjI6g+t JU/JYeAbxFqQ5VBVLIO7e5NUWH6nfPn0+W/PTt5eO4O2SdTHTSp8jT5fmmeDjD/cxoJI PLXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789980609; x=1790585409; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=kMNDPIW1M+Dnfnntk5+ZE4qyCf9pl2+3W+E2riidDAQ=; b=fQ39Uw5DYJp9y2Yq6B/rxNjC5UXextylOubUbuRIhRDQDhb+OhwB61XahWrlkzv6na iFkPhC7/SBYzf1RkRM0jX4S972hmMCDZV7+u7O/BaHGxEQGMsw3XONSJxsAbuwqojDvC Pc+qQYXa5gW9YIT8n9QVv/31iDngx8wWFz0JJ95d7C+CGlfAHSjlk3weuEPAAkRLGg7v 9tOOYnh+h0iSkBP+KQY13iaLA9CwBzg5Yfd7H1kG3eUdh6B9Yn51owaYxORkcyP/bwQg MS7OiBz8TGSavgfdypCfNofQEUUqmKirjtjSn5ugfhsBl3gGyI0l5r829fOPlxTgDthq vOFg== X-Forwarded-Encrypted: i=1; AKwUvBwKg3uzm+VQLRrF17R61fcYowb4icl2Ps+ZtF2XKSdNpqNDHwL18BdP5+rwWaHW5wT8uE2QCvXCIao=@lists.xenproject.org X-Gm-Message-State: AFuF++lysLCqTSAYYwSj7TUkX7KYvMsHHRYWuRL9hhMTMXekKj2iyrJb F6uO0OrnPTUZDWS4ujA44LjFL5jF+fGuwtp6hNucRgK5M4k2oGBeBMgk X-Gm-Gg: AYBFou2Hcf0GThiF1/J3ox/b3c/Uz89jDBO9xfldSlyB63c7bTjXNke5wpApjL8qila 0lwKKAEbZFIQywoz1I4glV1HgQmB1UuLcGRmjo/1IJ87rujlgHPJFBl4Lz0+eX6LWaVuh5BLv26 aEoiLhtkL/M2ScFmD38LicpUE6q/GS4ZbPBgnUdlav9pl09hbft3fUsc0/Xq/jPHAyRBtI0M5lb q9Oo/PUxrjtJR6ox+WgbP6cPFPQYf6hWzhUBP/9zRh1SFR89EdpsyC/8dky3MBCuPAC5LY1ORdm WJuu6AXEnijlMuob4AKQx4RGTJFhTU+EHHRLMZOzSjll2vl7ub8VmOGtz3awM1iuP/RaoifPUhK 2x5BodzLv2rNlvyER2G24Wjcy/V2DoQoGfFPFoVfqt0MRuOBGqMttxAE5xQB+8vHe5V7Cfxglkd +ioc0EncLQNI1TMkhXAbVtOMcwqj9rUMU6R6eDQHJyJRdoW618h5AJGTTPiE9/p/nAi7fb0lyAt Y4ZD6b5/X24M1vTBQbTLL3cAkeq9K89AnPvfiH4JwnM8GaUzA== X-Received: by 2002:a05:6000:65a:b0:488:5d38:71fe with SMTP id ffacd0b85a97d-4885d387deamr1436148f8f.39.1789980609095; Mon, 21 Sep 2026 01:50:09 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 10:50:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> <2394a616-16be-4657-be17-0a2dafebaeee@suse.com> <9929eb6a-d7b8-4a39-b726-82290983e9f3@gmail.com> <815bf929-57be-4b31-b3a9-a3720f5cd88e@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <815bf929-57be-4b31-b3a9-a3720f5cd88e@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789980609-664B62AC-E419220D/10/73395122804 X-purgate-type: spam X-purgate-size: 2989 On 9/21/26 10:28 AM, Jan Beulich wrote: > On 21.09.2026 10:03, Oleksii Kurochko wrote: >> On 9/14/26 5:02 PM, Jan Beulich wrote: >>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>> @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) >>>> spin_unlock(&imsic_cfg.lock); >>>> } >>>> >>>> +static bool imsic_local_is_pending(unsigned int id) >>>> +{ >>>> + unsigned long isel = >>>> + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0; >>>> + unsigned long bit = BIT(id % BITS_PER_LONG, UL); >>> Both can be unsigned int, can't they? >> Yes, agreed. Both isel and bit fit within unsigned int. I will update >> them in the next version. Sorry for not noticing that in first reply but local variable `bit` should be unsigned long as if id % 64 >= 32 we will have overflow of 'unsigned int'. >> >>>> + return !!(imsic_csr_read(isel) & bit); >>>> +} >>> No need for !! here. >>> >>> What about endianness, btw? Does the IMSIC always match the CPU (and >>> its setting)? >> No, the IMSIC does not dynamically adapt its register interfaces based >> on the CPU's runtime endianness configuration (e.g. mstatus.SBE/MBE): >> >> - CSR Accesses (imsic_csr_read): Indirect CSR accesses (siselect/sireg >> or miselect/mireg) operate using standard RISC-V CSR instructions at >> current XLEN width. Values are read and written directly into >> architectural GPRs without byte-swapping. > I.e. you need you add endianness conversion. I think I don't really get why. My understanding is that endianness is about an access to memory. We don't have here load/store instruction or an explicit access to memory. We have here only CSR instruction which loads value from IMSIC register to GPR w/ an access to any memory. Probably I wasn't clear here "he IMSIC does not dynamically adapt its register interfaces based on the CPU's runtime endianness configuration (e.g. mstatus.SBE/MBE):" and it would be better to reply as: ``` endianness (mstatus.SBE/MBE) only governs memory accesses, whereas eipK is accessed via CSR instructions, which transfer an XLEN-wide value between the CSR and a GPR with no notion of byte order. The AIA spec defines eipK in terms of bit significance (bit i of eipK is identity K*32+i), so BIT(id % BITS_PER_LONG) is correct regardless of the CPU's data endianness. Endianness only matters for the memory-mapped seteipnum register, which is why the spec provides both seteipnum_le and seteipnum_be. ``` > >>> Overall, what does "local" in the function name signify? (For a static >>> function, the "imsic" prefix may also be unnecessary.) >> It signifies that local (on which code is executed now) hart's IMSIC >> CSRs (isel and ireg in the case of imsic_csr_read()) are touched. > That's the expected thing for CSR access, though. Fair enough. I'll drop both the "imsic_" prefix and "local" and rename it to irq_is_pending(). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Sep 21 08:54:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 08:54:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427174.1649798 (Exim 4.92) (envelope-from ) id 1x8Zmg-0002Kq-5c; Mon, 21 Sep 2026 08:53:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427174.1649798; Mon, 21 Sep 2026 08:53:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Zmg-0002Kj-32; Mon, 21 Sep 2026 08:53:58 +0000 Received: by outflank-mailman (input) for mailman id 1427174; Mon, 21 Sep 2026 08:53:57 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Zmf-0002Kd-Bd for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 08:53:57 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8Zmd-008rqg-2i; Mon, 21 Sep 2026 08:53:56 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8Zme-002r2m-0y; Mon, 21 Sep 2026 08:53:56 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=j9P5IzcnsxyRAqDpvNcnpBgNxEYwl4pMZd6R+JZ9D/4=; b=r19DQLbGWTcCMulgr2xxfE+TM/ lNBxVn9zBF7oojKwuuP3Jptv4iTyKBjhz1Hkch38vbuutb6KQ0KD7Z7gelexyIlit+WAL7LIfwpPB lbK9XglMAU5MQlEqKZjEcKxuQ0UtYJ1vmGwC+6CRLS0bLhfSUISiq0lo08BM922JsXdE=; Date: Mon, 21 Sep 2026 10:53:49 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 1/4] x86/pagewalk: avoid ACCESS_ONCE() in compound literals Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Sep 03, 2026 at 01:51:28PM +0200, Jan Beulich wrote: > Compound literals are also covered by Misra C:2012 rule 13.1 > ("Initializer lists shall not contain persistent side effects"), and > (sadly?) that rule also applies to lists with just a single element, or > more generally with just a single side effect. Use intermediate variables > to overcome this as well as ACCESS_ONCE()'s restriction to be usable on > scalar types only. > > No functional change intended. > > Fixes: 0345b835dc97 ("x86/pagewalk: Read guest PTEs with ACCESS_ONCE()") > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/mm/guest_walk.c > +++ b/xen/arch/x86/mm/guest_walk.c > @@ -129,7 +129,9 @@ guest_walk_tables(const struct vcpu *v, > guest_l4_table_offset(va) * sizeof(gw->l4e); > if ( !hvmemul_read_cache(v, l4gpa, &gw->l4e, sizeof(gw->l4e)) ) > { > - gw->l4e = (guest_l4e_t){ ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4) }; > + guest_intpte_t l4e = ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4); > + > + gw->l4e = (guest_l4e_t){ l4e }; Did you consider using the l4e_from_intpte() and similar helpers here and below? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 21 08:59:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 08:59:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427180.1649807 (Exim 4.92) (envelope-from ) id 1x8Zre-0002ws-MX; Mon, 21 Sep 2026 08:59:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427180.1649807; Mon, 21 Sep 2026 08:59:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Zre-0002wl-Ja; Mon, 21 Sep 2026 08:59:06 +0000 Received: by outflank-mailman (input) for mailman id 1427180; Mon, 21 Sep 2026 08:59:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8Zrd-0002we-1G for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 08:59:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8Zrb-00Bk2b-Mh for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:59:03 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0f1d7-bab6-0a2a0a5309dd-0a2a450795b4-4 for ; Mon, 21 Sep 2026 10:59:03 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0f1d7-b4ea-0a2a45070019-4a7de18c8851-3 for ; Mon, 21 Sep 2026 10:59:03 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd38e0e5dso37412605e9.2 for ; Mon, 21 Sep 2026 01:59:03 -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-49fcd0eab91sm233225835e9.1.2026.09.21.01.59.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 01:59:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789981143; x=1790585943; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=CF+LTBgrshrKpLW3AvQ5YjW1U8anP4gog0bJPHNpTso=; b=CIbn/05cEV+HtIljshbTiKL12k7EnHZbcsQTuQk1/3anOISLlifxrQmNee+T+Lbowd zwdNMY00C0MJjzSnWiEVPIbSMWC6wfaR/Ulv7sb2ElMB1TAHWdIYtXpi6qQf/wQmofNF NzbRH4Ci+9JW5xrFQ1eZ6s7XRhf/of5uVqhK91fMJsMvYBYRFVc+yxXzEpJ98Q+7F4WT wRDHBUfS510R2vqOXU/s2jrPL6TIPtemTlLBpBqkS5Y7x9yfF0T/fOm8Or38VnYk8wbw tC4AgPVuZqRKCR1bJCJSpS7gJDPD1HZWf2jVVXo+JhqaZX/mWo1dhqIu8Vf5OtnysEMS gUJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789981143; x=1790585943; h=content-transfer-encoding:content-type: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:content-type; bh=CF+LTBgrshrKpLW3AvQ5YjW1U8anP4gog0bJPHNpTso=; b=hMyzEem/SzvQcquvUWvW4lqPiukOo/MIgDNDkLAu37YlQRoVA5FUDkbIIeEtUWhITp Y2n0rHK7v04npSD+c4aj3cBXlm8ln4UtqctU0XisvCS+iX8WFyN9zNQDWfYTEn1+yBJQ SFTzJz7uu1aKT8Ee0foJfMje4mgA9LgER3ew2N+r6S75Gsh2bInNNRoBZJETINuerHrO i+et14/lsqh/kMLy42E17BNrXtpxaLM287WnhfmznQ+cY9YKydYEQEQp20BclAcgH4uZ bUDIpLv7BBKExWmhapKPeIBC3A6WUn90dW154YbmNdZjFwLP0N0ReaviKVUknGFaFCHA xA/g== X-Gm-Message-State: AFuF++kvme0KXyrruIUOkMjy60/+AD/ltKyeleHxI4lUmjjKRZ24WSGa VAy17c8YDq8EEE0enoEe4VT4c8g0/0t8yPbZ8PujfyQk46J0hCfHvs6xF3TaBoH0vg== X-Gm-Gg: AYBFou0jULXG8FW0p8tuH8AA4J6kfCWu/74he7T6PnofwAXd75nSnVeWwf3Gq3Ve5k2 LPl55Zx6nyD77D8TI9NEpiQbNiLVj2CSJHkSC0kXNEeO0BNb5seqfZffpQ4vb1hmkXAA18MpMBh 0s5ooQt9iOjZ34e5DFhV9hMK5YxR9WVq6EgiCm9/D4wX4kYmj6A4zNl8oI6TGWHO6BSUFriif5G 68gD0X/oo0lTuRH+5QmQ1NImvlKWO5/U6ylFW1e330vFbgcAdZb6CU0iLbqiDRT3DmO8rOzdOPz sXQIEYvQ9TvxCGvAily5lSY7JmJAvecXwYdLoXW1jU5pD9oJeVlx3MIZ30KnfiUQ9I6+HQJjDud vN2IUzeYe5d3LdjZy0TOkH2vF32osPiBC6HtZAaFS3c9lvNYOeWJfKEfyuPVtqcRk13AVZE65pP Bdym83II8Zfuh4ijo8Vc1Rj/KL6go3HZyDxVg+sMEgsz71Ox2cblOSnbQQu1EAmkhDwOFbcgUuo EzmRW2WWUlkTiCQoQxZu2xWbkQ81zGkgf0dh5ody4FKqtzQQf7toVEcsUoIVg== X-Received: by 2002:a05:600c:8b03:b0:499:a277:e8b5 with SMTP id 5b1f17b1804b1-49fc566e609mr129475225e9.3.1789981142824; Mon, 21 Sep 2026 01:59:02 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 10:59:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] x86/pagewalk: avoid ACCESS_ONCE() in compound literals To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie References: 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: 8bit X-purgate-ID: tlsNG-ef75cf/1789981143-364DBAE4-31F6FB70/0/0 X-purgate-type: clean X-purgate-size: 1411 On 21.09.2026 10:53, Roger Pau Monné wrote: > On Thu, Sep 03, 2026 at 01:51:28PM +0200, Jan Beulich wrote: >> Compound literals are also covered by Misra C:2012 rule 13.1 >> ("Initializer lists shall not contain persistent side effects"), and >> (sadly?) that rule also applies to lists with just a single element, or >> more generally with just a single side effect. Use intermediate variables >> to overcome this as well as ACCESS_ONCE()'s restriction to be usable on >> scalar types only. >> >> No functional change intended. >> >> Fixes: 0345b835dc97 ("x86/pagewalk: Read guest PTEs with ACCESS_ONCE()") >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/mm/guest_walk.c >> +++ b/xen/arch/x86/mm/guest_walk.c >> @@ -129,7 +129,9 @@ guest_walk_tables(const struct vcpu *v, >> guest_l4_table_offset(va) * sizeof(gw->l4e); >> if ( !hvmemul_read_cache(v, l4gpa, &gw->l4e, sizeof(gw->l4e)) ) >> { >> - gw->l4e = (guest_l4e_t){ ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4) }; >> + guest_intpte_t l4e = ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4); >> + >> + gw->l4e = (guest_l4e_t){ l4e }; > > Did you consider using the l4e_from_intpte() and similar helpers here > and below? No, I didn't, as they aren't applicable to guest_le_t. guest_intpte_t aliases intpte_t only for GUEST_PAGING_LEVELS > 2. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 09:08:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 09:08:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427191.1649815 (Exim 4.92) (envelope-from ) id 1x8a0X-0004fu-H7; Mon, 21 Sep 2026 09:08:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427191.1649815; Mon, 21 Sep 2026 09:08:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8a0X-0004fn-Dw; Mon, 21 Sep 2026 09:08:17 +0000 Received: by outflank-mailman (input) for mailman id 1427191; Mon, 21 Sep 2026 09:08:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8a0V-0004fg-Df for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:08:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8a0U-006I6B-Av for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:08:14 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0f3fe-8faa-0a2a0a5109dd-0a2a4504eb1e-0 for ; Mon, 21 Sep 2026 11:08:14 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0f3fe-b57f-0a2a45040019-4a7de18c9b92-3 for ; Mon, 21 Sep 2026 11:08:14 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso23208375e9.3 for ; Mon, 21 Sep 2026 02:08:14 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fc52a5b6esm132645815e9.4.2026.09.21.02.08.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 02:08:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789981694; x=1790586494; darn=lists.xenproject.org; h=content-type: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:content-type; bh=RPErNZG8IlmwDWCzvPzHpBex+Z0N6oXDUtKvqtBA5Es=; b=brD4dn8umWhkp2+4GKcbQbroBScALdCWRf3Tqgdjc3kuOkEi+paW8jrMoYb+7/swKi Qor/+HsEp5xfrBUnx2BVnnD0Iv9xWIa9p0RKpE/fgcN1GeuYXd4szNwtDbQ1f4G7466S oo964XqCu63rbvgHbcW/ewTQX6sIdzyQMaP0hLCSVrLkSa8KSYj/ALx2gzcoyS1d4jBW gpWWsaXpFPv0ga4OYg0gbFg6+d0uOuTbcCRB+M9zc8PfuFThfMXSdaLLH/R31Il5Ngu2 a3sJIKAY/rDwaKP1jtaw13jHESMNlI3CNNBktOJSr2B5Lcwj2qDdC/3iHnyAOg8gxrny uUNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789981694; x=1790586494; h=content-type: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 :content-type; bh=RPErNZG8IlmwDWCzvPzHpBex+Z0N6oXDUtKvqtBA5Es=; b=LlNXGSJoYKKnYGG1XBMJuujiJwGT82HuIdX1mdhCxnhxussRQ6X8Vxb+ZL6tDNEDop 9/R58DSnQls5NC7EORNNBk5oKb4SuEEb1LT5ypWYA7x8qBjOxOFzr26qJextTcdMJrcf J54omSkFTeBkylnHDgrj7W2ewecohFWic9RciPHz/qYL+NyDRDZav65GZ5D899k1SuqG WA9tYmXT8Nfz0LISBe9svJfqDGiGEbdMF4FFw8aCBgd+xTs5AZnRCNHAUiiwuIsIi7my KTHMEcQxE9VfYaBn66OaVLLTwiClK9a2vMp8QHUaXy/lbQVSzQtZ8XE2ICzT0BPhBGMc Wpxw== X-Forwarded-Encrypted: i=1; AKwUvBy/mkcgDWbGVa/zEJGl+zFUZm2U7l8Xu2utBZSI1wVPQoZNI2bAw9lhQnkEoSRMHVyv/5zupIQ8AdY=@lists.xenproject.org X-Gm-Message-State: AFuF++k1ps3aMs89dqC2O7EPIzPMt2RnqHmB89WqLDQzZpEE4Oav/Tnn 4A3feFjdtBMAp2qj7mDqSCDmACs8tIvBRneTVNUGEQskdCjWQQw9UDrIsOej8+WoUQ4= X-Gm-Gg: AYBFou0ppLLtSbKQr8vhoNn3GIxGkyNxiNzNxzjp8guHqOcdYh4JYsSSyHMOg5IswwW ilfNS9frwGZ3VgjjNIyeqdcmc42hD/3LCq3oN0KxVKDP0D6ULTHZFt202MKpDeQN1C77YWulR7N 9cyvI+Gu1a7R0vuYLW2Os9QPK1njKdUiraz2Fzk1P5FzXc4G1Br6k6T0vS+Ly/lAHkloZz2eH86 myoVXoJhY1KGQbnJEwY5e9QtNkvKQwghyLFTuRxAxA/msa8QqglLpOGXEm7G5Cgyg6eDF0IZWXY YofrZZxZIxorKau3/zdfPdMQ+oAZGyh4rT86FwZ42PHgmqo3Vb0oVJgQ2bD0DBO3S3/jZl/684x qhyV2SLpo6EDjTRmH7r/sEkgU+Hz2apcBCGHHZAkzV5jIHArMFvRkTa17i9lrJ8jbvireQ2PC2/ VHyP2AMupnMgE2+nPizuddwDdQxn+apZOBDRx7ZECNJXF2J4mvuCi2TEFrrmIPa3shcwtRxIz5I 2XYpyuBALGE48xqG8qNDUvQ/TS+5xm93HP3j0sYgV+0Mn6E1p2AY6ZabYW+NxqTWmNsg5ZcTwes toQrx+g8xU+G7m3Yk6cBodKz X-Received: by 2002:a05:600c:83cd:b0:49c:c0d4:53d9 with SMTP id 5b1f17b1804b1-49fc56f7a11mr118173935e9.14.1789981693611; Mon, 21 Sep 2026 02:08:13 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 11:08:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] stubdom: remove build of zlib To: Jan Beulich Cc: Anthony PERARD , Samuel Thibault , xen-devel@lists.xenproject.org References: <20260917075351.37208-1-jgross@suse.com> <20260917075351.37208-3-jgross@suse.com> <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@suse.com> <09190c27-fd5f-4f7b-9d2b-be03785c7bbc@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <09190c27-fd5f-4f7b-9d2b-be03785c7bbc@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------M4vCLbVHTSP0rWrWxCBAgdet" X-purgate-ID: tlsNG-ebf023/1789981694-C22D4B50-F0CEE8BA/35/110847 X-purgate-type: clean X-purgate-size: 9804 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------M4vCLbVHTSP0rWrWxCBAgdet Content-Type: multipart/mixed; boundary="------------GC7n4NqRYBzRgc080pet7zK7"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Jan Beulich Cc: Anthony PERARD , Samuel Thibault , xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH v2 2/4] stubdom: remove build of zlib References: <20260917075351.37208-1-jgross@suse.com> <20260917075351.37208-3-jgross@suse.com> <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@suse.com> <09190c27-fd5f-4f7b-9d2b-be03785c7bbc@suse.com> In-Reply-To: <09190c27-fd5f-4f7b-9d2b-be03785c7bbc@suse.com> Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------GC7n4NqRYBzRgc080pet7zK7 Content-Type: multipart/mixed; boundary="------------UThrPfXKhZV9NJ90dVF0zQAB" --------------UThrPfXKhZV9NJ90dVF0zQAB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjEuMDkuMjYgMTA6NDMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNy4wOS4yMDI2 IDE0OjMxLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMTcuMDkuMjYgMTI6NTEsIEph biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDE3LjA5LjIwMjYgMDk6NTMsIEp1ZXJnZW4gR3Jv c3Mgd3JvdGU6DQo+Pj4+IFRoZSBsYXN0IHVzZXJzIG9mIHpsaWIgZm9yIHN0dWJkb21zIGhh dmUgYmVlbiByZW1vdmVkLg0KPj4+DQo+Pj4gTG9va2luZyBhdCBwYXRjaCAxLCBJIGNhbid0 IHJlYWxseSBjb25jbHVkZSB3aGV0aGVyIHRoYXQncyB3aGVyZSB0aGUgbGFzdA0KPj4+IHVz ZXIgZGlzYXBwZWFyZWQgKG5vIG9jY3VycmVuY2Ugb2YgInpsaWIiIGluIHRoYXQgcGF0Y2gp LCBvciB3aGV0aGVyIHRoaXMNCj4+PiBwYXRjaCByZWFsbHkgY291bGQgZ28gaW4gcmlnaHQg YXdheS4gUGxlYXNlIGNsYXJpZnkuDQo+Pg0KPj4gSXQgY2FuIGdvIGluIHJpZ2h0IGF3YXku IFRoZSBsYXN0IHVzZXIgZGlzYXBwZWFyZWQgd2l0aCBjb21taXQNCj4+IDZhOTRlYWEyYmYz ZmEwNmIwNWVkMmRhZDNkZDkxMTYwNjAyMzUzMjYuDQo+IA0KPiBBcHBhcmVudGx5IG5vdDoN Cj4gDQo+IG5hbWVzLmM6MTg6MTA6IGZhdGFsIGVycm9yOiB6bGliLmg6IE5vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnkNCj4gICAjaW5jbHVkZSA8emxpYi5oPg0KPiAgICAgICAgICAgIF5+ fn5+fn5+DQo+IGNvbXBpbGF0aW9uIHRlcm1pbmF0ZWQuDQo+IDxidWlsdGluPjogcmVjaXBl IGZvciB0YXJnZXQgJ25hbWVzLm8nIGZhaWxlZA0KPiBtYWtlWzNdOiAqKiogW25hbWVzLm9d IEVycm9yIDENCj4gbWFrZVszXTogKioqIFdhaXRpbmcgZm9yIHVuZmluaXNoZWQgam9icy4u Li4NCj4gbWFrZVszXTogTGVhdmluZyBkaXJlY3RvcnkgJy9idWlsZHMveGVuLXByb2plY3Qv aGFyZHdhcmUveGVuLXN0YWdpbmcvc3R1YmRvbS9wY2l1dGlscy14ODZfNjQvbGliJw0KPiBN YWtlZmlsZTozNzogcmVjaXBlIGZvciB0YXJnZXQgJ2xpYi9saWJwY2kuYScgZmFpbGVkDQo+ IG1ha2VbMl06ICoqKiBbbGliL2xpYnBjaS5hXSBFcnJvciAyDQo+IG1ha2VbMl06IExlYXZp bmcgZGlyZWN0b3J5ICcvYnVpbGRzL3hlbi1wcm9qZWN0L2hhcmR3YXJlL3hlbi1zdGFnaW5n L3N0dWJkb20vcGNpdXRpbHMteDg2XzY0Jw0KPiANCj4gSmFuDQoNCk9oLCB0aGVuIHlvdSBj YW4ganVzdCBpZ25vcmUgVjIgb2YgdGhlIHNlcmllcywgSSBndWVzcy4NCg0KSSdsbCBzZW5k IFYzIHVzaW5nIHRoZSBvcmlnaW5hbCBwYXRjaCBzZXF1ZW5jZS4NCg0KU2FtdWVsLCBjYW4g eW91IHBsZWFzZSBjbGFyaWZ5IHdoYXQgeW91IGV4YWN0bHkgbWVhbnQgd2l0aDoNCg0KICAg V2UgY2FuIHBvaW50IHBlb3BsZSB0byBwY2l1dGlscyB0aHJvdWdoIHN1Y2ggYSBjb21tZW50 Lg0KDQpEbyB5b3UgbWVhbiBwb2ludGluZyBhdCB0aGUgdXBzdHJlYW0gcGNpdXRpbHMsIG9y IHRoZSBzdHViZG9tIG9uZSB1c2luZyB0aGUNCmNvbW1pdC1pZCBvZiB0aGUgcmVtb3ZhbCBw YXRjaD8NCg0KDQpKdWVyZ2VuDQo= --------------UThrPfXKhZV9NJ90dVF0zQAB Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------UThrPfXKhZV9NJ90dVF0zQAB-- --------------GC7n4NqRYBzRgc080pet7zK7-- --------------M4vCLbVHTSP0rWrWxCBAgdet Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqw8/wFAwAAAAAACgkQsN6d1ii/Ey83 NQf/RumQfNCKYWOutorUtC5QN/r/h1AyAK0tXKBWcxuQyXvKMF0O3ihdxUbkjd0YBlB+B4Tam7uE lg5taWvKwHUEbT/BaIU1EPyka1ouMDnEHb6yRgAHBgqI/cC+RdxEuPbt1X9eOOdg43vCp8JUB/rM GauoYGk2q5IBF+jPANEqPFRn7NZgyzPw47tZhR0/urk5w/qoGijV1KiqtmhHmgaIuYa28pGClUPG aQRtnCoTrgilZb/Saqq1C/BDSxfuXkZd9iO0jAyinCDS4h21VO5vxnWzBhgOS+IgHTEhcV065CyO ub7Cg1tEjSfSR0dQmyuQpiIrrlZN3fmsyn8sRQGl4g== =X1Ai -----END PGP SIGNATURE----- --------------M4vCLbVHTSP0rWrWxCBAgdet-- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 09:09:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 09:09:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427199.1649826 (Exim 4.92) (envelope-from ) id 1x8a1L-0005An-UA; Mon, 21 Sep 2026 09:09:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427199.1649826; Mon, 21 Sep 2026 09:09:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8a1L-0005Ag-PW; Mon, 21 Sep 2026 09:09:07 +0000 Received: by outflank-mailman (input) for mailman id 1427199; Mon, 21 Sep 2026 09:09:06 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8a1K-0005AY-Fz for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:09:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8a1J-00GT62-Si for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:09:05 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0f42e-2eae-0a2a0a5409dd-0a2a450b932e-22 for ; Mon, 21 Sep 2026 11:09:05 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0f431-b7e8-0a2a450b0019-4a7de18cb5af-3 for ; Mon, 21 Sep 2026 11:09:05 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e4ad9so15286945e9.2 for ; Mon, 21 Sep 2026 02:09:05 -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-49fcd8bf159sm201577865e9.10.2026.09.21.02.09.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 02:09:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:To:Autocrypt:Subject:From:Cc:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789981745; x=1790586545; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:to:autocrypt:subject:from:cc :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=RFcNKegHtotmqjANQv/qcMVWd9EXDbLYWAnNH+/hM7s=; b=J8zPTrWCCag+7gdTo4yBEhHAwy4PpIp5TsORvMlB8xcHCchOPYgzgOQn8G7TSAJSAV iMVeMAEhZrZZa1TpQJDh58o4aTbPe7ZImdGHI/ZwRQkZu5NQ0vRWbGtx0JF/DLlQUTZ2 1mWBKyJst1b2YNF3R6swB2O0USGhu7Opy8Q3GfG3VfuTJ1kcjqW9DE3XIq3SzSoWKPFc QUfwxQ9OGhBe6VgzQ3E68M0E1/X4tc4RZi6QUyK10Zmr+Fw7T2jKIR+4dh9qUO5y+7Cp GQuamg/T9Vflcgu0ohkSFPLpGVuUdmMSgxtcjZSL0Dndka69CGuj77Ekh8iq1t/klV9h CRpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789981745; x=1790586545; h=content-transfer-encoding:content-type:to:autocrypt:subject:from:cc :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=RFcNKegHtotmqjANQv/qcMVWd9EXDbLYWAnNH+/hM7s=; b=U9ecAz+hp8pJSPoh+721iirvcncGxN7vLDsAIW3t8ZXWhvObeSMBHGQ70mpcuvZQyl CwOysGOTk6I4ct2ngHF2TLHlWGQdaeSStOYMsBwBVxJVlHnzlqrckoVW7GaivYVB9wpq G+J+1Yf5jp2rQDDu0mSvbxy2NiY+aA3Y7mtZWuL5OTN16A2vGzDKp4UFfG2h+QRXQXn6 2Qo/oIpE0VZx4QjJK0rzC1MzBRwvopuGc4xGeVwC0S/7sDT2nxPV7gmF14P1ktf0yQZ+ Rn0MGN7VxhRPr8T/LGSav2FSM4OGpLQ0gJ5GElr1Y7VZAZXWU9aWENt/JUnSjZKzHZGD VNEQ== X-Gm-Message-State: AFuF++kX/U5K59VSeMSG4hWswuiQZNkRQCEbey9ANJ3aV0QXpBD43RLR dxEg6htjHh4W+r34YcVW+8d0Iwx4hBbQHYnXUrrQzs4sDMUyg1h1eVknHf9PnYagaxW1rWSWA+C Br2ZZ4g== X-Gm-Gg: AYBFou1cxunEl2MOuFLWbzxaOHCSB8gRbYWEbUtD5Ll5soZSZ5n2W/fl1ewp5dfRYyn MaKIaJEgjRwyHUYOn2JoX5hvyirZ4uTc+j33RcObEQPBrNYdQRuH5roFrjHcjp0VZ+9QLwY7/l8 +XU3o4/NTqNluiMn6kyMVoA7nB3jv/2Z32+Z2iwb4tVdCzu7iq85BXH5OSexm6IS7VhtAJsxBrE Tx/w0urrOETvmMrjgwt3AaEZlWx9LogF8TWL5pzgZAWnjk2AtjAhs79fEcYuLMv7qi1C0X0mOLZ gcVFZZOgOSeXOeaekfjMj9s4u4Gur8dnHs1Besq/4rXRpJQXsApDJS/CA7viZsax96eSLOGfJPT vyyOLhW0Ed9nY/lmj+NFTrNgfEKZr/gYArALZ2aS4aG7t/LxH9fH/GXxtDhsGSW1U5Bcf90eauk bPAqYudYxnyWp1TqeGQDSOXG71IoZySnJne+k9Lg+D430wx8y+8tv8yIWFW16xGANHHPQAN/N/l d351jFql1/qVbp83gc9VHi1ED25eCmnT5G48QmneunudvJ6OzfzXQVkcBgouSt67jHqVoflnQ== X-Received: by 2002:a05:600c:34d4:b0:49c:fc6e:a3d5 with SMTP id 5b1f17b1804b1-49fc574f51cmr131032715e9.20.1789981744894; Mon, 21 Sep 2026 02:09:04 -0700 (PDT) Message-ID: <7e332eec-5c5c-4c1b-aeeb-c65e046b1318@suse.com> Date: Mon, 21 Sep 2026 11:09:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US Cc: Marek Marczykowski , Daniel Smith From: Jan Beulich Subject: [PATCH] EFI: refine cfgfile buffer allocation 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 To: "xen-devel@lists.xenproject.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789981745-1A4DB9EA-3D69D33B/0/0 X-purgate-type: clean X-purgate-size: 1888 Use of AllocateMaxAddress requires that the variable pointed to by the last argument of ->AllocatePages() is initialized. For cfgfile buffers we don't need AllocateMaxAddress though, at which point initialization of "addr" also isn't necessary anymore. Mirror the lack of address constraint also to the main / central buffer allocation in read_file(). Fixes: df75f77092c1 ("EFI: avoid OOB config file reads") Assisted-by: Sashiko + Opus 5.0 Reported-by: George Dunlap Signed-off-by: Jan Beulich --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -878,8 +878,13 @@ static bool __init read_file(EFI_FILE_HA what = L"Allocation"; file->addr = min(1UL << (32 + PAGE_SHIFT), HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START); - /* For config files allocate an extra byte to put a NUL there. */ - ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData, + /* + * For config files allocate an extra byte to put a NUL there. There's + * also no constraint on addresses for them. + */ + ret = efi_bs->AllocatePages(file != &cfg ? AllocateMaxAddress + : AllocateAnyPages, + EfiLoaderData, PFN_UP(size + (file == &cfg)), &file->addr); if ( EFI_ERROR(ret) ) goto fail; @@ -931,7 +936,7 @@ static bool __init read_section(const EF if ( file == &cfg && file->size && !iscntrl(file->str[file->size - 1]) ) { EFI_PHYSICAL_ADDRESS addr; - EFI_STATUS ret = efi_bs->AllocatePages(AllocateMaxAddress, + EFI_STATUS ret = efi_bs->AllocatePages(AllocateAnyPages, EfiLoaderData, PFN_UP(file->size + 1), &addr); From xen-devel-bounces@lists.xenproject.org Mon Sep 21 09:17:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 09:17:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427208.1649834 (Exim 4.92) (envelope-from ) id 1x8a99-0006p5-JP; Mon, 21 Sep 2026 09:17:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427208.1649834; Mon, 21 Sep 2026 09:17:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8a99-0006oy-Gq; Mon, 21 Sep 2026 09:17:11 +0000 Received: by outflank-mailman (input) for mailman id 1427208; Mon, 21 Sep 2026 09:17:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8a98-0006os-Hw for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:17:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8a97-006JkE-1t for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:17:09 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0f60b-2eae-0a2a0a5409dd-0a2a4506e068-28 for ; Mon, 21 Sep 2026 11:17:08 +0200 Received: from [52.101.56.9] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0f613-195a-0a2a45060019-3465380913f8-3 for ; Mon, 21 Sep 2026 11:17:08 +0200 Received: from BN9PR03CA0779.namprd03.prod.outlook.com (2603:10b6:408:13a::34) by LV9PR12MB9781.namprd12.prod.outlook.com (2603:10b6:408:2f6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 09:17:04 +0000 Received: from BN1PEPF0000468D.namprd05.prod.outlook.com (2603:10b6:408:13a:cafe::98) by BN9PR03CA0779.outlook.office365.com (2603:10b6:408:13a::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.16 via Frontend Transport; Mon, 21 Sep 2026 09:17:04 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF0000468D.mail.protection.outlook.com (10.167.243.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Mon, 21 Sep 2026 09:17:03 +0000 Received: from espagarciav-lx01.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 21 Sep 2026 04:17:02 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k8cgpro8oTlppAbECpLtXbFe107WM4ctDpwfEevtMe71trkoLDEoaBBmGto9XTi/KJoM6YQaLC3QK9leb+7saNGmImi23amAtCeFMy+zv0nwhl+mYzEBPXb+OQORSG+2QOem0lC+a/oboeTog9nQxo0DsT384QOYNxawZ8WEdNn8SeUZursCFrD7R7Dbb6oTys9yZYJHutN8bD6hycBq4Um17eCXSKc8/8MIhO0R54CUT1/IQa2hBj4oR6Cv+FJCQUNh+VK/VQbYmHSdNGfINStBAdLPZZVeEONoICmKY0/jq9GdKoi4mchZuht87H0wXd+Sul8qNHUtYvuR1sqZpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QpG4PP+LdqdKmBVP32nleuKcECNMY4ZmvUOiP88omMY=; b=HIJfN4CXIskeTQJbjmEliqsXJwSZq82ECOoHWFfS+YC7ghNB0Jmgu/V1PbWMmW3H7BCQv3PJcL53qx3ZTrpbBrhJ1IVKmqX4hnoBkrxcVm/1+RFhaDg4BXwGBjg/iSlXfAjdabUHmmj+1ApFqmix+DD37jX6s0/r6P5efhUg9EJsYNN7MQsW1HJrjenRjimMAjPWQ7gGXp/4pVEszEPg3N6gsNNC19lgpkLD7jk3SBRDb2eAHnIPEM6UdcFR0Mt/CQKJpDiUyH8TWMqsOGSM5LHiU9+7HXKanADqwbVMwfACSIwJfClgLwxp9kb01wBPnmIJo9I0QZL5nzMSUJyvXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QpG4PP+LdqdKmBVP32nleuKcECNMY4ZmvUOiP88omMY=; b=sD39krAT8PNO+G6d02gCQ52I6KIdJxe1ulgABa6I/ZsDD5t/cH4IIC1r28tFCcKEmfzB3BN1IMpwOnOEX04j77pn1sj/EZw/P5TTaBoVpie2MoA9oqaO7QYOAJGWxbd2Nd/kC4RFc6TIHHrGwdVp0F4fbRgshiQCAnuExxjBaRw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/vpmu: Fix incorrect printk format specifiers Date: Mon, 21 Sep 2026 11:16:50 +0200 Message-ID: <20260921091651.34761-1-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0000468D:EE_|LV9PR12MB9781:EE_ X-MS-Office365-Filtering-Correlation-Id: ee7107e5-78ec-4219-aab6-08df17c119e1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|36860700016|1800799024|82310400026|56012099006|11063799006|10067099003|18002099003; X-Microsoft-Antispam-Message-Info: UfQbwf7clVfOwmOjat/N10Xe7hXOJtYjgJp34or9Fvlq0ULMYFOo6GoXhdK9AUNIH3Grb+4D3oF2Ryg55ssL1hSdH36pstypz4XEU3g75lRfZmPnCpoduPaKJ1+dS0C0OfW1bOEByEFsPLjew8Nb4dFmwyKhlXS5rF7iuAm5VMbp3440SP6sZf9GwtCrhzFOteQE9U1eUkRcfE38TrwD9g0nTI/EHH4pgz/NYrbcxjGzuRsrOQjuwHT/OqpvwLwwlD1Fy3aR8H0b3JBWEhUKmDlbX79o5ec3rqVIFGeAJ37iHWccuDuyo6kx46lSsw5nYUd0FTUyFiiZP8Y7M9y+WPAEaMc9kdLwP3NQ+83Gc/o031hDU4sE0oSUyYtvxtWsHGp6QCtdYEmZxXap41ypVkOT225fVH6zPRPs2NLNYfJbPPDxN4N1EjkcP3GqjWW0sGdom0gaPn7di6X7JK9q81vQV8K2aieABWf4QY/GMg9gAn35z07ycUlt8nItxQgC7GvAJVGIijMJzLye+d9pMSw12caEUea2R209fOEK6VMm9du0ovlUkR5uhztuveY9Ut35UESY3H4F5nO8QxWsEwlVHyW4JDWC8hUeFj5V2INPIvPTRpuNVYGoTfm5HMIsH7Z467x9nv8KZTxAvtxYwA8rygfiC/IO9AOD2m3jjdxzTBoBRM+i8/aYcDdWZoM89ZXkkma2mqkfna5M+7sVMg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(23010399003)(36860700016)(1800799024)(82310400026)(56012099006)(11063799006)(10067099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 2qTTg0hMI/zxVqJGEEHIPnkij8LpbDfuNFcv14kUgu5TCGSv6lOTyaMhSjbOQLpd3VanakA21hWSVpNNR/y6YqaAlAbY8w/bo/vILHVh34VLDIE+zHCQR85vhKw3/NwOpv8AbOOsiAFAr88RxsaVEs/brcfTvgfJwNL0z7+xzR3Ngwf4Aj3pDE+8CttuQQ2GWHyuXRBHisbNu41WwBHh2ionMgaUixSKtoJfYZVbMbTDTZx/4lpC0u14bGnh/+oTWXeAe6nYmxhyxDIA1X6T5e/LwGMnGiemjyP3/hdoiNs6wpFn8Gq4M8TGHBv4fa+VOdhG16dBYr/U6jes4fI48wD/cewabfDZ8L6e406iw4rZYABiewQBRTqzkeq/U0zuG5lzdkt2qCgWsNZ9sFKMF+kSF9iy2JoggNVrSHwJh8zjkUvUpX8HbGmDeE2zXmfx X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 09:17:03.9855 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ee7107e5-78ec-4219-aab6-08df17c119e1 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF0000468D.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR12MB9781 X-purgate-ID: tlsNG-16d1c6/1789982228-FDE0E77B-C5C10649/0/0 X-purgate-type: clean X-purgate-size: 1370 The patch in Fixes adjusted two vendor variables from uint8_t and plain int to to unsigned int. But they were both used later in printks with the %d specifier rather than %u. Adjust accordingly. Fixes: 39a9a49449d7 ("x86: Remove x86 prefixed names from x86/cpu/ files") Signed-off-by: Alejandro Vallejo --- xen/arch/x86/cpu/vpmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c index 470f5ec98d..e0f7edded3 100644 --- a/xen/arch/x86/cpu/vpmu.c +++ b/xen/arch/x86/cpu/vpmu.c @@ -417,7 +417,7 @@ static int vpmu_arch_initialise(struct vcpu *v) { if ( vpmu_mode != XENPMU_MODE_OFF ) { - printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %d. " + printk(XENLOG_G_WARNING "VPMU: Unknown CPU vendor %u. " "Disabling VPMU\n", vendor); opt_vpmu_enabled = 0; vpmu_mode = XENPMU_MODE_OFF; @@ -849,7 +849,7 @@ static int __init cf_check vpmu_init(void) #endif default: - printk(XENLOG_WARNING "VPMU: Unknown CPU vendor: %d. " + printk(XENLOG_WARNING "VPMU: Unknown CPU vendor: %u. " "Turning VPMU off.\n", vendor); break; } base-commit: adbbbd47a1fad8e3bc1ab65c555f11d831fd6681 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 09:26:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 09:26:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427215.1649843 (Exim 4.92) (envelope-from ) id 1x8aHn-0000Bc-Dq; Mon, 21 Sep 2026 09:26:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427215.1649843; Mon, 21 Sep 2026 09:26:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8aHn-0000BV-Az; Mon, 21 Sep 2026 09:26:07 +0000 Received: by outflank-mailman (input) for mailman id 1427215; Mon, 21 Sep 2026 09:26:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8aHm-0000BP-C4 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:26:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8aHl-000cyJ-8j for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:26:05 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0f827-2eae-0a2a0a5409dd-0a2a450a8ade-36 for ; Mon, 21 Sep 2026 11:26:04 +0200 Received: from [40.107.200.31] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0f82b-f2d2-0a2a450a0019-286bc81f4d44-4 for ; Mon, 21 Sep 2026 11:26:04 +0200 Received: from BN0PR04CA0189.namprd04.prod.outlook.com (2603:10b6:408:e9::14) by CY8PR12MB8297.namprd12.prod.outlook.com (2603:10b6:930:79::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 09:25:58 +0000 Received: from BN7PEPF0000009C.namprd04.prod.outlook.com (2603:10b6:408:e9:cafe::1f) by BN0PR04CA0189.outlook.office365.com (2603:10b6:408:e9::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.16 via Frontend Transport; Mon, 21 Sep 2026 09:25:58 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN7PEPF0000009C.mail.protection.outlook.com (10.167.248.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Mon, 21 Sep 2026 09:25:58 +0000 Received: from espagarciav-lx01.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 21 Sep 2026 04:25:55 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kYXUJf7ROEIPC9cdTJCqdCh6uZiTRSx233tw0ONufMntRQ/Z/rLSSvIlsNXcRrLOZ03JcMJtzCx/ZMlDS/TTiXtRV5Fa+x4MqW2HdjUPmKxtJ1EM886LFq4J4KZS0Q/mBV29zNW+MgoFvBv2gV7z/1xtQWz/UtzPWbqJDt6fK4Qil5iDH7yvQabkMiH1H5RRDyI/Z7FvgWZMvFS1gWnIiHqw43IbIhlo3eWF/ZUYrmBushz5HxqGhu9MTjpVca4W/MyBHY735QLBqX3d8gW6c3fcM7rMZ5lfC7nYLeyYTVSRni4DaHn56Q51cbz1rCWLxOQdoJHliWtyIL2yz3zfLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Sgk6kE+hr6M+rgcsXPhKjfl2VOBlqviynvvQD3lGOLA=; b=PtJhh96/IirjzwsFLyHizmkO1X25m5M8HLuAGXN99rL1roFOeknmd3yysdCB2nzkgA4cOhkRy8WCOPbAbM5YR+A08ntQNOyKHqyGBj8OYFkYgZkChVlsAHJpDE6IG3xIxHCA/XSWeDjPXAjsKPiF2cdt13OhCEVUfaEGIpHzIJ8P9hSJ1LHhBqb8k0+5LwBxXPhEJEINPADFihlvkVpY85J1/iR97ipgosvJPZazpDzKcayHsdShhtBfzUpUJ6lqmgF/BXBCy8ZDTkrW4FccHQIJR+GDJ9kPc7rBgfTptLQ/TX9pe44YMFzZKpiRMnw2nK27DfErWZDgPmVhZeEMZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sgk6kE+hr6M+rgcsXPhKjfl2VOBlqviynvvQD3lGOLA=; b=CUQonjFXdWI2mtx/76UE79h+G8q9Ohm/y/CwD970d7YDldo9R3qf5ey99CtXqzGJYuKsqpRm/hciZDkJOeXbHWvH8JKYIORsq3I5t3qgNUtY8gbq+nrVSV72i+WKhT4fj8V8eh/8O8M4mWPAsREM4SPI8xlwz3N71sLgGV3oVgI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86emul: Cache the amd_like() output on x86_emulate() entry Date: Mon, 21 Sep 2026 11:25:44 +0200 Message-ID: <20260921092545.37148-1-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN7PEPF0000009C:EE_|CY8PR12MB8297:EE_ X-MS-Office365-Filtering-Correlation-Id: 38b0c500-7f0d-4e80-0e12-08df17c25850 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|23010399003|30052699003|1800799024|36860700016|18002099003|56012099006|5023799004|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: TmDWdj6uDgGkSiCiEagNEhTHaoN+ajIsVPfTZpD0G+LCwkwv4xnbT/Y50qJg6vcYMeNwYep/9ixKMjZfYk4IKDz9tzNt/wQJQzB9Q6EL3sRKEweQQ0Nwq0fo9chgzeIv6oOooMrj7CA1vIujnPdGcMKDPvijFVP0NG2EvS6Hzj/yIvYOM6xoRauRuBhifGyexM1zzCtklwVG7vXXB6CZNqLiz4oT92ckH4pq0B9UmMhr6sHU6ARDRfozTBZxh1o7xUWSRqit4UQyUtNWNECfO9zRRYlNVI2FTP+4mYlOob8htVkKpsdTy725/UlhY17c6JRPD0q8XTRzlj+bPbLNJIXPH3Gmwrx/FRBXMH3TmiBrHyEomFN3k/U3/O0jsIC0KWibThHI+xInH8iKERYZgjABd9NR5llq1At+8LRGcMrExshTUXDy+9ZKAa5A37aqmhHj6bOrLD742Ofz+J3Cl9jsU5A4pIZWixmo6X+Y5+/oB7K6e9ZwUc3owEq+Ll3QLgSgR5wADJd/xUvSnNx4M5iQ09ttmdKgzK8zHRm0jtxBAjAVelmQaAP2biEJfocUh3e+pOlFHMP3UjcNg6MkO6RnN/wGp1loMzs7DWuc6H07g/7qGOilCiK5desyPBchKNbr9bOdS8f8lv2+AZHJ1gj4ChjIy0zzzQQnpPOK9g0= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(23010399003)(30052699003)(1800799024)(36860700016)(18002099003)(56012099006)(5023799004)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: p6NGicflLDJqW+Q9J3sQ+19P8FZiNRDmxisftiSBHc0nvpKPr64QTo9FV5ehE/ACPlev43M05w1MYsPqXH8dd4IeIUvGBCNQaDrcinJRWBjPc7TFnbcYaveXgyw16vAIyBHgpdiKED68paFxi5VoXIpIOnEggWqNMq0AQzulsDzSfAOV4+Vc87HoK6KkSukDSpPYC2vNKh+Rf2YWe7aUHH84/PcttvYE/fnF7z+NAifgIh+/4TnGfbuW3UFuXmByMHnp1e1xJZEnVl6kUXeoZNdBrYUYauefPR1aUURDDQ+9awoU8MwZPgDmnKiHQddPyR9YdnrwzpSfLyUL+x3/8WEkx99b88nGOoUUu+AsZTJSkt09sPi5ClFipSxlr9NXh2sUEJcmcQiEqHMgU1nxlMcmDRlo5nDylMF3SUfPRt3WUmCFucEVtbkHQ7IuPj+R X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 09:25:58.2195 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 38b0c500-7f0d-4e80-0e12-08df17c25850 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN7PEPF0000009C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8297 X-purgate-ID: tlsNG-4011c0/1789982764-593C4CFC-33ED520E/0/0 X-purgate-type: clean X-purgate-size: 5983 The current code instantiates amd_like() way too many times, leading to codegen explosion. Unconditionally call it early on, and use that variable everywhere. This shrinks the emulator by ~3KiB. No a functional change. Signed-off-by: Alejandro Vallejo --- pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2860748404 (it's red because of an caching issue and personal branch name conventions it's just arm. x86 passes in full) bloat-o-meter before-after patch. add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-3366 (-3366) Function old new delta x86_emulate 209351 205985 -3366 Total: Before=3617694, After=3614328, chg -0.09% --- xen/arch/x86/x86_emulate/x86_emulate.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c index 89c37fea2c..c69ef0781e 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -363,7 +363,7 @@ do { \ #define jmp_rel(rel) \ do { \ unsigned long ip = _regs.r(ip) + (int)(rel); \ - if ( op_bytes == 2 && (amd_like(ctxt) || !mode_64bit()) ) \ + if ( op_bytes == 2 && (is_amd_like || !mode_64bit()) ) \ ip = (uint16_t)ip; \ else if ( !mode_64bit() ) \ ip = (uint32_t)ip; \ @@ -576,7 +576,7 @@ static inline void put_loop_count( * zero extend relevant registers first when using 32-bit \ * addressing in 64-bit mode. \ */ \ - if ( !amd_like(ctxt) && mode_64bit() && ad_bytes == 4 ) \ + if ( !is_amd_like && mode_64bit() && ad_bytes == 4 ) \ { \ _regs.r(cx) = 0; \ if ( extend_si ) _regs.r(si) = (uint32_t)_regs.r(si); \ @@ -1310,6 +1310,7 @@ x86_emulate( /* Shadow copy of register state. Committed on successful emulation. */ struct cpu_user_regs _regs = *ctxt->regs; const struct cpu_policy *__maybe_unused cp = ctxt->cpu_policy; + bool is_amd_like = amd_like(ctxt); struct x86_emulate_state state; int rc; uint8_t b, d, *opc = NULL; @@ -1810,7 +1811,7 @@ x86_emulate( if ( ea.type == OP_REG ) src.val = *ea.reg; else if ( (rc = read_ulong(ea.mem.seg, ea.mem.off, &src.val, - (op_bytes == 2 && !amd_like(ctxt) + (op_bytes == 2 && !is_amd_like ? 2 : 4), ctxt, ops)) ) goto done; @@ -2356,7 +2357,7 @@ x86_emulate( case 0xc2: /* ret imm16 (near) */ case 0xc3: /* ret (near) */ - op_bytes = (op_bytes == 4 || !amd_like(ctxt)) && mode_64bit() + op_bytes = (op_bytes == 4 || !is_amd_like) && mode_64bit() ? 8 : op_bytes; if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val), &dst.val, op_bytes, ctxt, ops)) != 0 || @@ -3089,7 +3090,7 @@ x86_emulate( if ( (rc = ops->read_msr(MSR_EFER, &msr_val, ctxt)) != X86EMUL_OKAY ) goto done; generate_exception_if((msr_val & EFER_SCE) == 0, X86_EXC_UD); - generate_exception_if(!amd_like(ctxt) && !mode_64bit(), X86_EXC_UD); + generate_exception_if(!is_amd_like && !mode_64bit(), X86_EXC_UD); if ( (rc = ops->read_msr(MSR_STAR, &msr_val, ctxt)) != X86EMUL_OKAY ) goto done; @@ -3174,7 +3175,7 @@ x86_emulate( if ( (rc = ops->read_msr(MSR_EFER, &msr_val, ctxt)) != X86EMUL_OKAY ) goto done; generate_exception_if(!(msr_val & EFER_SCE), X86_EXC_UD); - generate_exception_if(!amd_like(ctxt) && !mode_64bit(), X86_EXC_UD); + generate_exception_if(!is_amd_like && !mode_64bit(), X86_EXC_UD); generate_exception_if(!mode_ring0(), X86_EXC_GP, 0); generate_exception_if(!in_protmode(ctxt, ops), X86_EXC_GP, 0); #ifdef __x86_64__ @@ -3200,7 +3201,7 @@ x86_emulate( sreg.attr = 0xcf3; /* G+DB+P+DPL3+S+Data */ /* Only the selector part of SS gets updated by AMD and alike. */ - if ( amd_like(ctxt) ) + if ( is_amd_like ) { fail_if(!ops->read_segment); if ( (rc = ops->read_segment(x86_seg_ss, &sreg, @@ -3924,7 +3925,7 @@ x86_emulate( case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ vcpu_must_have(sep); - generate_exception_if(amd_like(ctxt) && ctxt->lma, X86_EXC_UD); + generate_exception_if(is_amd_like && ctxt->lma, X86_EXC_UD); generate_exception_if(!in_protmode(ctxt, ops), X86_EXC_GP, 0); fail_if(ops->read_msr == NULL); @@ -3973,7 +3974,7 @@ x86_emulate( case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ vcpu_must_have(sep); - generate_exception_if(amd_like(ctxt) && ctxt->lma, X86_EXC_UD); + generate_exception_if(is_amd_like && ctxt->lma, X86_EXC_UD); generate_exception_if(!mode_ring0(), X86_EXC_GP, 0); generate_exception_if(!in_protmode(ctxt, ops), X86_EXC_GP, 0); base-commit: adbbbd47a1fad8e3bc1ab65c555f11d831fd6681 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 09:30:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 09:30:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427224.1649851 (Exim 4.92) (envelope-from ) id 1x8aMT-0001tj-0n; Mon, 21 Sep 2026 09:30:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427224.1649851; Mon, 21 Sep 2026 09:30:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8aMS-0001tc-UM; Mon, 21 Sep 2026 09:30:56 +0000 Received: by outflank-mailman (input) for mailman id 1427224; Mon, 21 Sep 2026 09:30:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8aMR-0001tW-G6 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:30:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8aMQ-000dyp-NT for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:30:54 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0f93d-8faa-0a2a0a5109dd-0a2a4509a4d2-44 for ; Mon, 21 Sep 2026 11:30:54 +0200 Received: from [52.101.193.56] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0f94c-be1a-0a2a45090019-3465c138dda7-4 for ; Mon, 21 Sep 2026 11:30:54 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS0PR03MB989641.namprd03.prod.outlook.com (2603:10b6:8:42d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 09:30:51 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 09:30:50 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=e1tenzf8E8FQtiue0XOA76iDamTmJ/flH1hsyyYL240roZYH0AwS3DuTk23tC8Fk8JzqGPFla2UJmNzWKNCrm5Tc6HWGCItehx/VLQFWCyENgbeuXzKtFlAM8RnmLwZGnKlrZYKOmh24O6D5OYA1ROUUdGiLK3RTPNsfmbbldw6XoH4vn1prNoH9GTt733210QIkUzd96gUgGAWPDY0L11CF9Tjs9xsYWqq18tns6h3kOEOQoupi+uaYjD62QRZbwFJrgDa0GduBbjJe/vJkO/tXgIl1w/48ZkPBTe7mHd23R3QbL63a8kbpRVrYzBd0WVGqetaKMenIMtjiYrNn+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xlu0HBkNmf5O71CsMFcUk28PJfUO1lhHD0wPbP0jm+I=; b=yXG2bEbMvxS5Hxf3IfHDTDGlY3XZzC/jX1SHrpmhwJYH9MU5UMgp6p7AOsK3YK8PXWfN6ayoFY11LLX1JEaLKEdm3+8Gf/goiA8BDWvemd/g3c/qBhS7so7nQGvTxz0tOyJSFL6p/sEqj3Uo1Tsq985x3Ka8p/ZIIPqXPgbjdSHojvnHdNwyvwun6I/5+feyimNy2N2XJDry8/G6bAc3ZX+KStMwjLPH/ye5eZnl7p4ST4r0amLKqj4Cf2C7SlHK5posE5SxuxlPZUuBX61NBLOCbmmElZHBERD3z/2SXSCGuVZVaM6IS0/7oNoYhrqdwbWwbEpFNtOXcRBIB2KaKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xlu0HBkNmf5O71CsMFcUk28PJfUO1lhHD0wPbP0jm+I=; b=PT0xhqRjZcBVPGjxXaVhNorq1Re4BNngrrGV1tGTAQvk68YHcBHRJgqDawAYbuzoSdjBj0yq3ssM8xngrms9CGIq6DwlGCf08/i7jLrxqGCmel7IXafgo3jcuQsfO8qb9MSuUzK2vG0NEaHyFTCiGTkc2O9zsbjZyLd79WGaL1A= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <489f6ce6-2be7-4c94-bcf0-21fc6993f98c@citrix.com> Date: Mon, 21 Sep 2026 10:30:46 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH] x86/vpmu: Fix incorrect printk format specifiers To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260921091651.34761-1-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260921091651.34761-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VI1P195CA0086.EURP195.PROD.OUTLOOK.COM (2603:10a6:802:59::39) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS0PR03MB989641:EE_ X-MS-Office365-Filtering-Correlation-Id: a21d3ab8-2dae-478b-e034-08df17c306a5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|10067099003|11063799006|18002099003|22082099003|56012099006; X-Microsoft-Antispam-Message-Info: QevdCnU/SKErE2oNTMwoF4giwlmFSmCAHOvXQbXrUAIxQZasS0m2MYdRzoHzCt/3RkjPIB561fEwjDyOT9jQF8m1xqa/uO44AjdDXgHpN2Uyomu7dD/phF3WVraGzcyTDI9+jIIn4mlq60DFHNmjZtsfOIw1J0fkx18PmZK2PuC8EFJbxn79vsPrAdUF4QSTVjNrGipT+Vl8+RNOu2ttVrLJTnz+IZg+bH9+nSuoChJH7454Db0K5pbhMO5YPD/x9c/3XAX/78XLooN1dWl1GgVz0kXWGoB7FpivKvwxxS/WeehFgQptq4rDBAR1C7jUCNIzADrg5L1odKFlIJ8ClxvSklQqd0IDNjgujG3LRrWSNktGcONpS2T5ciIXeAQesduqNBad6t4glUMJFC78w8IXwFUVRgrizq4b+LdkF105GPzlUwCNDUMHVJoP77G4zSy5FV59Yh6JN3DaTXCAMjyS3G983wQg020N9FOCR73RikguuUzBZSKY9J1pyOrQaCouzJIDCG0ulMDW95lTvNPWuSDCcI8n9KcWwWuHh43/J0VjwPZnSnlpbrNTg3S5VbRlBzR9TUtU8FlMeImZW8bBwLWlzod19BQASt62kOE9c09uSXBKCWkI6+o34buVkjCMm80Quc/ytC6sPTl/BpzYM1vWVFHvAM99dSDCfBs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(10067099003)(11063799006)(18002099003)(22082099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U1lTcnAwMnNxdzdEVG4wMmxlaVZKb1h4RXNXaVFVZ2hYRHJUTlpxa0xtRUhm?= =?utf-8?B?MmYycEpNaTBmc3o5akxtdmdhMytKZnJ5eUpnM3BSSVJFRjNaQTFERTk1MnIv?= =?utf-8?B?emdnRnFBa2Y1NzZQYWpzWHdJazRwQ3FVaWU0cU9FcVFKV2VheDNNaThLcnZW?= =?utf-8?B?UGw3U0VidzYwMmFBWFM3SzJGMytPNnlRUVVSQW0rZ25HU2JGUm8zUEQwekgy?= =?utf-8?B?ajNJWEI1NTdwWWRzWGdGQUVqT0QvQmFpQy9KN3h5ZDg3NFJoRCtGbWZJd1dj?= =?utf-8?B?a01wOG5mL2JkRWVFcVVNeFNpYU1KS1VqWnRZY0ZFZkdGeUh3M0V4cEpHdHNz?= =?utf-8?B?SmE1V0xaM3h5Zjl0MEE0SGVoY3BCVjUxT3BnTmFPTkozMEhvd2psb2hWTlZv?= =?utf-8?B?U04vdDNkMmt4aG5VeWcyaG1aS0NZYXVKVVRPS3JUbUFQN3cwUE5wZUFscHJM?= =?utf-8?B?VkpxMmJaSHhHMW1OamNJeGdYUTVWYkZkNWRBdmJ5TFZkZFkxeW14NlZ0WTV6?= =?utf-8?B?aXNXK1hhV0hGWWsyQzNFZEhoMHV3VTR6VDlIMUg0UjhHYmJVN3oyY1E2VlVO?= =?utf-8?B?bTdHMFdxcTVUb3NZdXYwWmRrMklJSmNBa1N2WVVselhtLzRDVUZuSkZKV0Yz?= =?utf-8?B?cGtiSG90Y1ZqSEJ0QlNUSDIrSGJxMmtJUFRxR3QrY2VKVlhlR2xlcWxjamd2?= =?utf-8?B?aThHTVJ0NFlFb0NaMU8yOFhWR3lXQVZ1b2pmSzZCM1Z1QXZJeWNuamNyQzFl?= =?utf-8?B?QmRLN1o3eG9ORVNTRDlKT0dLMDBhUitMZ3JpOTRNMERoRTJzVm1TempaYTNH?= =?utf-8?B?T3FFTThSbzQveWp4L0RwS29TTENmaGpQUENJSlNLaTFxZktVMWRyaW1JeVYr?= =?utf-8?B?aVdLMUJZRVB6TjYyTm1WNkMwMlhzMXQ3akRZQis3YnBjaXNBbm1GbVRBUkI1?= =?utf-8?B?dy9jLzlNMmRvQmwvdzRFWG9BZVpudEtrZ2FkVVRZSHJDZlIxNGlEYnBVYXdJ?= =?utf-8?B?bWRXRklFUzdJdmpOcURKZG5NWjdDWEhCeFhINXZta0ExMVA3UVlkSzM0cWNO?= =?utf-8?B?cG11ckZXbUMybndVMDR2cytBRzZUWERPdExXNzJ0MGszdFJlVUFMbStDYjdF?= =?utf-8?B?bTRnZlh4Z25lc2kzWnpEOHhNMmxzWi9PVVBueDhISElPOVFVL2NUbEhybHo5?= =?utf-8?B?U0piRDY4YTZHN21wQWdDY0dLRDdjYTNzSC9nYUY3Ynp2NXlxVnBxbG9ubkFX?= =?utf-8?B?RURIVEdXQlErNis1cVVYYWF2WWdBaUlkbmIrRVE2dzdlZnNVaEl4SHdDblZD?= =?utf-8?B?TmRqVFlqQW83UmJUdGFKUVhJbmVIc0w4elkyeGNmVDdvcmovV1VrVkNxUjZs?= =?utf-8?B?TDNzay9rT3RQa1dhL1owSXdKMHk5YktZQXVpcEpTemFhWXlXdmhFdUM0di96?= =?utf-8?B?VU1mczVmUHpCZThKOE5VbWZ0UWJlYmxTdEZIVFQzbGMzWE9UVmc2WFc1RHBs?= =?utf-8?B?TGpWaDdmallCWDFoOTFRWVBqczJSYlJBOElvRzU1ajhzK0g3blNnNFlEbjRl?= =?utf-8?B?N0ZwVE1VbnMxOFQzL3pXbEl0cHBlYVZXMUNwNEUrQnJTcVhmd20xQXdWNnlq?= =?utf-8?B?NjdFQ2NrMlUxWUxFdmdwTHVtMzJBcytyNmd5TGhuQTdwSk1mNHFVNDV2WHdI?= =?utf-8?B?WUNBVXc4RFo1TkVOUlIvTWJ6SHlaMjB5cE1HaVUxMWNhT0hBdUR6L3Q0NnNX?= =?utf-8?B?YkVnaDAvUFNzMmR6dk01cVNtcWNqK2ZMaXR6c2RkYWltYjZTM1ZmS0g1ODkz?= =?utf-8?B?ZlRQSGxNQ3lHY3c3cUFZOE9TNVd4dlo5NHV5VWM4eU5FdU9YYUJJNDJvaXEr?= =?utf-8?B?ZzE0NXo5YUplSEJKVTZWSWE0QkhSNGFsUWNQaTNDWnRiakNxN1M3Y3ZpZzFT?= =?utf-8?B?cVpYeEF0Q29mODc2NGhPeHNpZUJSTXZrSmxGRTkyazlmVWVEa2NtVmhnc0Iw?= =?utf-8?B?RWJxV1lzcWtwZmhFTExJOFJlODdlb0orZTlLWWxXdnA2azJTK0FyM1pyeHdv?= =?utf-8?B?T2FqK2gwWGlyRG44T2lZc0Urb3VrREZTaDZGODZsRTV1c1dUaW5YTmRjTDcv?= =?utf-8?B?OHh6T1dSV0hUZlJ2U29HU0toME9aMDhWU1RTaUY3R1FRWHNOTWhtTWw1cnlx?= =?utf-8?B?aTFWNUtLbU9OQ2tMTEhoN2ZRSU1MVXhuWThDNkxJRFpVVDRRdHJIVXYrOFoz?= =?utf-8?B?dWZ3MWxrd2U1UlFCTWlwUEROSGlXVkdWbEZXTmJFcXRjN1Zsc3Y5SXR0UnBF?= =?utf-8?B?NDlEUXFLU3FXemJ4ZklmNzJacWdSR01YamI2L3NGbFdLTVFOTElwbWQ0c2Zy?= =?utf-8?Q?UYbSEULi895X/2RA=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a21d3ab8-2dae-478b-e034-08df17c306a5 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 09:30:50.8448 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: BrMH/n0rodDzSUnBCHaSjoDE/jx+nNpwYTvczy46vL+TO86Rbg/QvqDOgZvKUFCtxvsq3vphd+tTjpPgBbgT/k9cFKVjRdSk0Rd/EooauDE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB989641 X-purgate-ID: tlsNG-bad1c0/1789983054-3B6D2034-A356410B/0/0 X-purgate-type: clean X-purgate-size: 560 On 21/09/2026 10:16 am, Alejandro Vallejo wrote: > The patch in Fixes adjusted two vendor variables from uint8_t and plain > int to to unsigned int. But they were both used later in printks with > the %d specifier rather than %u. Adjust accordingly. > > Fixes: 39a9a49449d7 ("x86: Remove x86 prefixed names from x86/cpu/ files") > Signed-off-by: Alejandro Vallejo If this is going to be a problem, then shouldn't we turn -Wformat-signedness on? For the patch, Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Sep 21 09:38:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 09:38:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427231.1649862 (Exim 4.92) (envelope-from ) id 1x8aTr-0002bU-Oj; Mon, 21 Sep 2026 09:38:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427231.1649862; Mon, 21 Sep 2026 09:38:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8aTr-0002bM-L8; Mon, 21 Sep 2026 09:38:35 +0000 Received: by outflank-mailman (input) for mailman id 1427231; Mon, 21 Sep 2026 09:38:33 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8aTp-0002bG-Si for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:38:33 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8aTm-008sVj-1X; Mon, 21 Sep 2026 09:38:30 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8aTm-006IIf-2z; Mon, 21 Sep 2026 09:38:30 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=EzYlQ1oqZU6GvVE+84SeCPxWxElZBzucNgw2Qhmh2Lg=; b=UBWawS4To53/6rURwNJLFQp9nw 5rTraV0kDPxHAH91XCUw51qaZii5Pdn2b7KgBi4Olfj/V6yOpXuzmKjQcCY7+teP6Wx3rQ/QQW0ID K0+c27Hqcg8dtn71ojFKeBy2Ko66ZXhLNstmyA5OKu5M3tLcEJDb6sHYKv77i2Gj6gkc=; Date: Mon, 21 Sep 2026 11:38:28 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Yuchao Zhang Cc: Juergen Gross , Stefano Stabellini , Jens Axboe , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/1] xen-blkfront: unbind irq before tearing down ring and shadow requests Message-ID: References: <20260918114354.3660102-1-ndaugoing@gmail.com> <20260918114354.3660102-2-ndaugoing@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260918114354.3660102-2-ndaugoing@gmail.com> On Fri, Sep 18, 2026 at 07:43:54PM +0800, Yuchao Zhang wrote: > In blkif_free_ring(), the driver tears down the ring's persistent grants, > shadow request arrays, and shared ring structure (xenbus_teardown_ring), > and only calls unbind_from_irqhandler() at the very end. > > While blkif_free_ring() is freeing persistent grants and clearing the > shadow array, the event channel interrupt (blkif_interrupt) is still > registered and active. If an interrupt arrives from the backend during > this teardown window, blkif_interrupt() reads rinfo->ring.sring and, > via blkif_completion(), accesses rinfo->shadow[id].grants_used and > rinfo->shadow[id].sg. blkif_free_ring() tears these structures down > without holding rinfo->ring_lock, and the handler only checks > info->connected at entry, so this is a real race resulting in a > use-after-free or NULL pointer dereference. > > Fix this by moving unbind_from_irqhandler() to the beginning of > blkif_free_ring(). Calling unbind_from_irqhandler() first frees the > IRQ and synchronizes with any in-flight interrupt handlers on other CPUs > before ring memory and shadow request structures are deallocated, > matching the teardown order in drivers/net/xen-netfront.c. > > Fixes: 907c3eb18e0b ("xen-blkfront: convert to blk-mq APIs") Are you sure this is the commit that introduced the issue? I think it's: 11659569f720 xen/blkfront: split per device io_lock The commit that split the lock and removed the usage of rinfo->ring_lock in the interrupt handler. > Cc: stable@vger.kernel.org > Signed-off-by: Yuchao Zhang > --- > drivers/block/xen-blkfront.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > index 8dad7bf5f664..e70b78ca4df2 100644 > --- a/drivers/block/xen-blkfront.c > +++ b/drivers/block/xen-blkfront.c > @@ -1210,6 +1210,10 @@ static void blkif_free_ring(struct blkfront_ring_info *rinfo) > struct blkfront_info *info = rinfo->dev_info; > int i, j, segs; > > + if (rinfo->irq) > + unbind_from_irqhandler(rinfo->irq, rinfo); > + rinfo->evtchn = rinfo->irq = 0; Please add a comment that interrupt teardown must be done ahead of freeing of queue related data, otherwise the interrupt handler can race with the cleanup. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 21 09:42:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 09:42:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427236.1649870 (Exim 4.92) (envelope-from ) id 1x8aY2-00044n-74; Mon, 21 Sep 2026 09:42:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427236.1649870; Mon, 21 Sep 2026 09:42:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8aY2-00044g-48; Mon, 21 Sep 2026 09:42:54 +0000 Received: by outflank-mailman (input) for mailman id 1427236; Mon, 21 Sep 2026 09:42:52 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8aY0-00044a-59 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:42:52 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8aXy-008sYl-3B; Mon, 21 Sep 2026 09:42:51 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8aXz-006cSh-1S; Mon, 21 Sep 2026 09:42:51 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=g6kbeO4YasL2v/bIQY1nMXhKyG8Bpejd5kFTWbcqW9o=; b=rXRh81LbK0pO4lHzfc9I0VnrxI W2Wp6qpgtSArYxJnPcPRCWCrbyrMLR6tMUxjhWq1CxkrvrvXAGyYrSbK6XhfylpPzHe+HiloVFAft feh6dEUK/5LV9hUb/rU5nO54eKGCpt7vazvLG0z5gWjABgo3a9h9vAKpQ6lhkqYakA1k=; Date: Mon, 21 Sep 2026 11:42:49 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 1/4] x86/pagewalk: avoid ACCESS_ONCE() in compound literals Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Sep 21, 2026 at 10:59:09AM +0200, Jan Beulich wrote: > On 21.09.2026 10:53, Roger Pau Monné wrote: > > On Thu, Sep 03, 2026 at 01:51:28PM +0200, Jan Beulich wrote: > >> Compound literals are also covered by Misra C:2012 rule 13.1 > >> ("Initializer lists shall not contain persistent side effects"), and > >> (sadly?) that rule also applies to lists with just a single element, or > >> more generally with just a single side effect. Use intermediate variables > >> to overcome this as well as ACCESS_ONCE()'s restriction to be usable on > >> scalar types only. > >> > >> No functional change intended. > >> > >> Fixes: 0345b835dc97 ("x86/pagewalk: Read guest PTEs with ACCESS_ONCE()") > >> Signed-off-by: Jan Beulich > >> > >> --- a/xen/arch/x86/mm/guest_walk.c > >> +++ b/xen/arch/x86/mm/guest_walk.c > >> @@ -129,7 +129,9 @@ guest_walk_tables(const struct vcpu *v, > >> guest_l4_table_offset(va) * sizeof(gw->l4e); > >> if ( !hvmemul_read_cache(v, l4gpa, &gw->l4e, sizeof(gw->l4e)) ) > >> { > >> - gw->l4e = (guest_l4e_t){ ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4) }; > >> + guest_intpte_t l4e = ACCESS_ONCE(l4p[guest_l4_table_offset(va)].l4); > >> + > >> + gw->l4e = (guest_l4e_t){ l4e }; > > > > Did you consider using the l4e_from_intpte() and similar helpers here > > and below? > > No, I didn't, as they aren't applicable to guest_le_t. guest_intpte_t > aliases intpte_t only for GUEST_PAGING_LEVELS > 2. Right, as otherwise it's a 32bit PTE. Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 21 09:51:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 09:51:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427248.1649879 (Exim 4.92) (envelope-from ) id 1x8agW-0005kN-0l; Mon, 21 Sep 2026 09:51:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427248.1649879; Mon, 21 Sep 2026 09:51:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8agV-0005kG-Tq; Mon, 21 Sep 2026 09:51:39 +0000 Received: by outflank-mailman (input) for mailman id 1427248; Mon, 21 Sep 2026 09:51:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8agV-0005kA-77 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 09:51:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8agU-00Gbt7-6U for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:51:38 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab0fe29-8faa-0a2a0a5109dd-0a2a45019048-6 for ; Mon, 21 Sep 2026 11:51:38 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab0fe2a-5984-0a2a45010019-4a7de44ce8ca-3 for ; Mon, 21 Sep 2026 11:51:38 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a98505364aso4548661a12.3 for ; Mon, 21 Sep 2026 02:51:38 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6aa67e1a45esm3966885a12.25.2026.09.21.02.51.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 02:51: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789984298; x=1790589098; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/IxU85Q5+hlg74zBf1mzGGMbph3ImCEiXQwned8esM8=; b=SHv3e7O4zCtels+lm1HpGPB/LbZJuBz5NppcONb+MndBZJxMMxnG2BuJhDyBXknlZ9 379aamO41YUvtFT72/ieAzKED9Hqb7URLPptu1F3irv7tr2E/HFSIKogr+cIzqWKng8R 8U1dKLK3rYHYDu6E70C53892P6ErHDDyzyWvZP/+aTp2myZ6N8M6l+ypeDjYaMlNl5tq VjH3XPi+ALeq9EpIj5WNFt6cgQ7grRLDRvz0VTBKUZjmD4h0ncRuVsQtRCFbTnkEh4UJ F4WnsbBNBLUwKeBoNmAlds6S4q6U0muvErx39ZgQokWeDk6orU47Em74TOswUkuYvOXl pplA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789984298; x=1790589098; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=/IxU85Q5+hlg74zBf1mzGGMbph3ImCEiXQwned8esM8=; b=mMgOuLotWl0EbEwGmVS9Qz0j97hgCO0lGjebZHm1vtUBE+qyMYUqZR0HW4Kz4cUnsF OroIgN1r2QI3kRTqtUvwEKKtA5BorHL4fdX6ObbinJv7nGwnBWmF62WB/BlkFNiIMjkb +EfhUER+4S3QKw0Iz1n4zdGaWTMvKAt7lZ3O9Cl56lquvOW/SQlTdEJY7WM4veQV8tMj JtWWbUASx7XmeGj29qlZ0zlsoKBld1PVzh24K6MyQ1H89BHTSkbb+nN+c89qu7Mx8Euw /P9vF8YYFh+Sj3vsqUW86Hx3udNPCxxFrp04U4V+tVDHO42ZLhmdPv4EW/b2850wjzxt NsgQ== X-Forwarded-Encrypted: i=1; AKwUvBwBylV6pHgSYdpnCtoTBZXXIgPAeA/UcYx8hEMIA78b0BiOfkAMIBOG7FkpXuBfxpNzq51agA16fPA=@lists.xenproject.org X-Gm-Message-State: AFuF++k9C2/LaEfPuG559WTkg8nPu4anwbpqwbJy39oIJ5fU6v5M+UoO nTJLIBNRAIpHobpJQYrGoi26MBZTeqmi2MOUhNiYL1OVc1jtLXUYEG0g X-Gm-Gg: AYBFou0VvJRjoK8fPGGkp/I4s6Qe+ohmArLHf0osVm0LdnsnrqCpyE9a7bWE9AZl2fs BdsWl6/xMk1qp48B52ChROK4SM3UNiZuo9aiLtNIOvPbwKme08gjMjlSoYwQkCwxQL4x9rz4Ouc dAOjAgMvy/uJ1hcyVOROdfJOhHev+lpTqLIwmRuTfB3M3X2G63sySJ/h9Xt0T73mnqyAMWQHTsq +IeWY8oKwkz6qkbksyFr6t3Uoa0IPs41jlETgOJW6m6tPCSfiqeEf8isDLVdfvwtfwMp6Vy5DH6 uf/oHtulQLdyxKKKMKce+A00OtdeT0O8FQe8yjB2S9shG+RnoLPFGaaLI3dYrVcAzlYFxwLbuGE jzQdoFPDVoTX4I+cEBAyfslhphrhAoULPyrhIoIvkFUf66YElOUcUiB5XtJoUAu5jU3VIzif2g+ 4iqIl2KmfnIqd61FFUZMEDtTr/w4LE8AX0jdTPHhuwjIMxtBAveGTxysuLGb8+6gUikjpHd7WlW Dm/WRpo21rEdc+ozLmRAbnTzpHQChcKjzabd/K7qU13p/5jhw== X-Received: by 2002:a05:6402:510d:b0:6a9:b519:eb3f with SMTP id 4fb4d7f45d1cf-6aa53cb3d0bmr7327483a12.29.1789984297540; Mon, 21 Sep 2026 02:51:37 -0700 (PDT) Message-ID: <323b4219-113e-4592-88a9-d16b92ca12d4@gmail.com> Date: Mon, 21 Sep 2026 11:51:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1789984298-BC95A757-82F58171/10/73395122804 X-purgate-type: spam X-purgate-size: 4901 On 9/14/26 5:15 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> At the old interrupt file, dump to memory all the eip and eie arrays). >> After this step is done, the old interrupt file is no longer in use so >> old intrrupt file VGEIN could be released. >> >> Restoring of old interrupt file state will be done in follow-up >> patch. >> >> There are cases where it is needed to specify on which cpu it is >> necessary to VGEIN should be released so update vgein_release() to >> deal with that. > > Beside this being difficult to parse, it looks like it is inapplicable? As > said ... > >> Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard >> against silent incorrect behaviour or unexpected panics in guest VMs until >> the function is fully implemented. >> >> vgein_release() is stub for now and will be introduced later. > > ... also here? Agree that paragraph should be dropped, it ins't applicable anymore. > >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -56,6 +56,24 @@ static unsigned int __ro_after_init guest_num_msis; >> */ >> #define GUEST_IMSIC_MAX_MSIS 255U >> >> +/* >> + * The interrupt identities an IMSIC interrupt file provides are 0 (which is >> + * never valid, but still occupies a bit) up to IMSIC_MAX_ID inclusive, so >> + * IMSIC_MAX_ID + 1 bits have to be covered. >> + */ >> +#define IMSIC_MAX_EIX DIV_ROUND_UP(IMSIC_MAX_ID + 1, BITS_PER_TYPE(uint64_t)) > > As before - plain 64 please, or it needs to become clear where the uint64_t > is actually coming from. I will use plain 64. > >> +struct imsic_mrif_eix { >> + unsigned long eip[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; >> + unsigned long eie[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; > > Same here. Yet better may be to use DECLARE_BITMAP()? It will be better. I'll use: DECLARE_BITMAP(eip, 64); DECLARE_BITMAP(eie, 64); > >> @@ -85,6 +103,15 @@ do { \ >> csr_clear(CSR_SIREG, v); \ >> } while (0) >> >> +#define imsic_vs_csr_swap(c, v) \ >> +({ \ >> + unsigned long r_; \ >> + \ >> + csr_write(CSR_VSISELECT, (c)); \ >> + r_ = csr_swap(CSR_VSIREG, (v)); \ >> + r_; \ >> +}) > > Excess parentheses again. Plus - what use is r_ here? r_ stands for `return value` but it should be dropped as it could be done so imsic_vs_csr_swap() just returns a value directly: #define imsic_vs_csr_swap(c, v) \ ({ \ csr_write(CSR_VSISELECT, c); \ csr_swap(CSR_VSIREG, v); \ }) > >> @@ -130,6 +157,21 @@ do { \ >> imsic_switchcase_32(F, ireg + 0, ##__VA_ARGS__) \ >> imsic_switchcase_32(F, ireg + 32, ##__VA_ARGS__) >> >> +static unsigned long imsic_eix_swap(unsigned int ireg, unsigned long val) >> +{ >> + switch ( ireg ) >> + { >> + imsic_switchcase_64(imsic_switchcase_ret, IMSIC_EIP0, >> + imsic_vs_csr_swap, val) >> + imsic_switchcase_64(imsic_switchcase_ret, IMSIC_EIE0, >> + imsic_vs_csr_swap, val) >> + default: >> + ASSERT_UNREACHABLE(); >> + } > > There still wants to "break" in the default case. > I'll add. >> @@ -973,5 +1071,11 @@ void imsic_migrate_vcpu(struct vcpu *v) >> * to the new IMSIC VS-file. >> */ >> >> + /* Read and clear register state from old IMSIC VS-file */ >> + imsic_vsfile_read_clear(old_vsfile_id, old_vsfile_cpu, nr_hw_eix, &tmrif); > > Why is &tmrif being passed into the function, when it's not otherwise used > here? The function could itself have a suitable local var. > tmrif isn't a scratch buffer local to the read: it carries the register state of the old interrupt file over to the new one. In this patch it's only filled in, but the next patch ("restore register state in the new IMSIC VS-file") passes the same buffer, via vsfile_data.mrif, to imsic_vsfile_local_update() on the new pCPU. By then the old file has been cleared and released, so the state has to live in the caller. I'll add a sentence to this patch's description saying the dumped state is consumed by the following patch: The state is dumped into a buffer provided by the caller rather than one local to imsic_vsfile_read_clear(), as it has to outlive the old interrupt file: once that file is released, the state is still needed to be restored into the new interrupt file. Just to emphasize that in code I will use vsfile_data.mrif instead of &tmrif: imsic_vsfile_read_clear(old_vsfile_id, old_vsfile_cpu, vsfile_data.nr_eix, vsfile_data.mrif); Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Sep 21 10:01:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 10:01:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427289.1650000 (Exim 4.92) (envelope-from ) id 1x8apx-00007e-2t; Mon, 21 Sep 2026 10:01:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427289.1650000; Mon, 21 Sep 2026 10:01:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8apw-00007X-Vo; Mon, 21 Sep 2026 10:01:24 +0000 Received: by outflank-mailman (input) for mailman id 1427289; Mon, 21 Sep 2026 10:01:24 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8apv-00007R-6B for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:01:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8apu-00Cfdc-HX for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:01:22 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1006b-e002-0a2a0a5209dd-0a2a4506a45e-30 for ; Mon, 21 Sep 2026 12:01:22 +0200 Received: from [188.68.63.162] (helo=relay.yourmailgateway.de) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab10071-195a-0a2a45060019-bc443fa2baf9-3 for ; Mon, 21 Sep 2026 12:01:22 +0200 Received: from mors-relay-8201.netcup.net (localhost [127.0.0.1]) by mors-relay-8201.netcup.net (Postfix) with ESMTPS id 4hpJdV2sb7z4NRn; Mon, 21 Sep 2026 12:00:46 +0200 (CEST) Received: from policy01-mors.netcup.net (unknown [46.38.225.35]) by mors-relay-8201.netcup.net (Postfix) with ESMTPS id 4hpJdV27C2z4NRh; Mon, 21 Sep 2026 12:00:46 +0200 (CEST) Received: from mxe9fb.netcup.net (unknown [10.243.12.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by policy01-mors.netcup.net (Postfix) with ESMTPS id 4hpJdS65cXz8td8; Mon, 21 Sep 2026 12:00:44 +0200 (CEST) Received: from [IPV6:2a02:8108:8984:1d00:a0cf:1912:4be:477f] (unknown [IPv6:2a02:8108:8984:1d00:a0cf:1912:4be:477f]) by mxe9fb.netcup.net (Postfix) with ESMTPSA id 5AA1A5FA21; Mon, 21 Sep 2026 12:00:39 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=key2 header.d=leemhuis.info header.i="@leemhuis.info" header.h="Date:Subject:To:References:From:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=leemhuis.info; s=key2; t=1789984846; bh=8EDrVz3B5Ui9t+59/tsVLp1aP1KLxbEoqN01RrOD6w8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=N+muyZXc8ymigm1X4WJYdQfg2FAM32UXD62GkYAoXAwUrk7y9wSeo8wrc/kijMJRV y5tWKY3o2n02jG8BFKiSIVU0+QItf44A8F/uAvgSzG094QdLpHkIhB2vYGkX46B20i VN8otbW9QVGTprs7yAikun99LjJZdMuY8JvNPtYmNbSMCRCvzKBQOTZyd8gdjxZZ5l DyvixvqPU0uzZ2XY48NNI84277giq0riOIyvt5KdUAjXgXxXqYHUF2UnaCKvpjyJhB wokbeEO1V5wZCwoLz8JbmY9fO/UzY31upQSqXV2mNt9yhCmfs119MpbQUfndGp34Ma 0jJsS2X3dDAMA== X-Virus-Scanned: Debian amavisd-new at policy01-mors.netcup.net X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: mxe9fb; spf=pass (sender IP is 2a02:8108:8984:1d00:a0cf:1912:4be:477f) smtp.mailfrom=regressions@leemhuis.info smtp.helo=[IPV6:2a02:8108:8984:1d00:a0cf:1912:4be:477f] Received-SPF: pass (mxe9fb: connection is authenticated) Message-ID: <8aaad113-1952-4655-978d-0cdd8b048064@leemhuis.info> Date: Mon, 21 Sep 2026 12:00:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot To: Support TRINITY , regressions , linux-acpi , linux-pm , stable , xen-devel , linux-kernel References: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> From: Thorsten Leemhuis Content-Language: de-DE, en-US In-Reply-To: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <178998483973.134331.13310613659725459518@mxe9fb.netcup.net> X-Rspamd-Server: rspamd-worker-8404 X-Rspamd-Queue-Id: 5AA1A5FA21 X-NC-CID: jHAYD1xjKcSrG8HKUMDccnDoibkQCgWtGfye6GROeeyolTZ1i1c= X-purgate-ID: tlsNG-16d1c6/1789984882-FEC7777B-42F7454D/0/0 X-purgate-type: clean X-purgate-size: 3947 On 9/20/26 17:48, Support TRINITY wrote: > > I am reporting a bare-metal *Xen* dom0 boot regression seen with *Linux > 6.18.52.* Thx for the report. There is one somewhat important detail that was missing (hope I didn't miss it): Is latest 7.3-rc also affected? And if it is: does that partial revert help there, too? Ciao, Thorsten > On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on > bare metal, while Linux 6.18.52 *consistently black-screens before dom0 > userspace/networking comes up.* > > #regzbot introduced: v6.18.51..v6.18.52 > #regzbot title: ACPI processor/cpuidle lifecycle change breaks bare- > metal Xen dom0 boot > #regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/ > work_items/18447 work_items/18447> > > Tested results: > > * Linux 6.18.51-r0, Xen dom0, bare metal: boots > * Linux 6.18.52-r0, Xen dom0, bare metal: black screen before > userspace/network > * Linux 6.18.52-r0, Xen domU: boots > * Linux 6.18.52-r0 with Xenbus notifier change reverted: still fails > * Linux 6.18.52-r0 with only ACPI processor/cpuidle changes reverted: > boots > * Linux 6.18.52-r0 with refined ACPI idle lifecycle patch: boots > > Affected hardware tested: > > * Intel Core i7-4785T thin mini-ITX, 16 GB DDR3 > * Intel N305 thin mini-ITX, 16 GB DDR5 > * Supermicro / Intel Xeon E5-1650, 32 GB DDR3 > > The successful boot used the regular Xen command line: > > multiboot2 /boot/xen.gz cpufreq=xen:performance > module2 /boot/vmlinuz-lts modules=loop,squashfs,sd-mod,usb-storage,xfs quiet > module2 /boot/initramfs-lts > > No IOMMU workaround, serial console parameter, debug parameter, storage > workaround, or Xen command-line change was required. > > The regression was narrowed to *ACPI processor/cpuidle* changes between > 6.18.51 and 6.18.52, specifically the idle-driver registration lifecycle. > > The working 6.18.51-style behavior registers the ACPI idle driver from > *acpi_processor_power_init()* and unregisters it from > *acpi_processor_power_exit().* > > The failing 6.18.52 behavior registers the ACPI idle driver globally > from *acpi_processor_driver_init()* before *driver_register().* > > A first ACPI-only revert confirmed the regression source. A refined > candidate patch was then prepared to preserve the working ACPI idle > lifecycle while keeping unrelated 6.18.52 safety fixes, including: > > * _LPI bounds checks > * cpufreq notifier cleanup on *acpi_processor_driver_init()* failure > > The refined candidate patch modifies only: > > * *drivers/acpi/processor_driver.c* > * *drivers/acpi/processor_idle.c* > * *include/acpi/processor.h* > > It does not modify Xen, Xenbus, IOMMU, APIC, PCI/ASPM, intel_idle, > syscore, USB, storage, XFS, networking, printk, or the cpuidle core API. > > The earlier cpuidle_disabled() workaround is not included. > > The refined patch has been rebuilt and boot-tested successfully as Xen > dom0 on bare metal on TRINITY-EDGE. > > This issue is currently visible to *Alpine* users because the *Alpine > v3.24 *stable repository contains: > > alpine-release 3.24.2-r0 > *linux-lts 6.18.52-r0* > > Systems tracking Alpine 3.24 stable / latest-stable may therefore > receive Linux 6.18.52 as the default LTS kernel. > > Attachments: > > * revert-acpi-idle-registration-lifecycle.patch > * APKBUILD > > The original Alpine report is here: > > https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447 > > > Please let me know if this should be submitted as a formal patch with > Signed-off-by, or if there is a better upstream fix/dependency that > should be backported instead. > > Regards, > > *Tony BONNIN* > #regzbot introduced: 6cffb59ee50ea4 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 10:18:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 10:18:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427297.1650008 (Exim 4.92) (envelope-from ) id 1x8b69-0002Bz-A4; Mon, 21 Sep 2026 10:18:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427297.1650008; Mon, 21 Sep 2026 10:18:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8b69-0002Bs-7C; Mon, 21 Sep 2026 10:18:09 +0000 Received: by outflank-mailman (input) for mailman id 1427297; Mon, 21 Sep 2026 10:18:08 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8b68-0002Bm-2W for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:18:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8b67-000mKC-1e for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:18:07 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1045b-bab6-0a2a0a5309dd-0a2a4503c99e-10 for ; Mon, 21 Sep 2026 12:18:06 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1045e-fae8-0a2a45030019-4a7de18d9680-3 for ; Mon, 21 Sep 2026 12:18:06 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e71cdb22bso20553425e9.2 for ; Mon, 21 Sep 2026 03:18:06 -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-49fcd10273fsm222706655e9.7.2026.09.21.03.18.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 03:18:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789985886; x=1790590686; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=gD+9XwafO3d+jB6LE/VzAZr+e9liNr2SBRBvi63UD8o=; b=DEHmFi/LzmXrNmmxElrZd/R8h/lw67FJrG2DHuxUsc7Q8TO7KfFRLByMtIhQUJBg4O MhXD5Cd474BRNpA+hd9fsbobzZIkza6uYJvScHf0TV1dQoHYB7HenYNIIm/1vu24/d/y 6ijDJR6yDGbRNfKs/6KZGGm1nvwlupifWTf6M5N2Nieartm6ishWEDIVkgB8Xvgmd+WN rd0Oso+uC/vFRw+gtzRCJJY51JQqvaz4xMifCbkvX+Qd80J6EvawknT2z9F6WgIXxU5R OzvJecpOU6T+y4lzwImYvN9YgqWTktRZswELy5wNCBgO4TemZ+S/CZA+yEWc3XC8MjU4 ykZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789985886; x=1790590686; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=gD+9XwafO3d+jB6LE/VzAZr+e9liNr2SBRBvi63UD8o=; b=wlVpB+ZnII9TT0NQgYjS7QU7k8EvocMlppcYVhnKxzUFOwTu2Kcd1ybqnuq4wRR/TE szB/eFxh3KRaZFMZEPkT9rmzZQ0t2K82JXKawPFvJq3xK/UbyrAx3SCjuGNcUaO/Rhxt AjjIQ7ImqwcUCsTjJ5QlpD7WDWxoaa7L34xROkGIeiQpILAVG0RoopTeAcU0ty+pkC0T AJxQHrJn++uOk9ZlKMDO6DOS/+OVZNsLuy+Z2qhfR/AIIBH4+NKYA9U2i1bZWf1G80WW x+BJY4crHlL9XPHgqe5YSRuh8WaRv76T1WrQzKpHxJXnQOTeJNtX51YR1oEq6OI+O6Zo rQYQ== X-Gm-Message-State: AFuF++lB85KwiIxrWna0+q3kVo3itSOHs9FhX0QnV0coF3u51WP2TeiF OVpQNfe4Urd60PdFCmhAkMR7HqO1qs1+r6W2OAcwPSDeVgGRHF1uv24F5qvXxA443ndpJcpDqkT lkj/ahw== X-Gm-Gg: AYBFou0cDApRAK8q60KZcURrj8jU+mjqmKu8OIb6vo2kxUgfH6Dc7eMEw3rTTOW56mh ByxFD5aVLUfubtcKOhyZR0b3p2bp5A+U3JbwrHwkpD4Tjz9mOY9k2wasojTKxIDW6BgTuzXY5rm XVReZi82MpI3p/7I2kD1sxog/lHXhJFIV/29Vy4JbeKi0qzyv4XkZbC/CvQveq7e7p+LuSpeNlb xnbqpRAp47WiUEhWvg1xiLFmNNr90zfZD5MduGtVYeEuW18tKODXtBHfQBvluzP58IgTigSaS4/ 8nXwlo9Cfwl7JvH/95CnlU4aBL6xE1L3q3bKTXIPhY+VifuwJ0e8rwVvqmRqN8LKeXWPgTS2pgV MpoDj9KoVjeKNPvj48NAnuqwwBxs7NbjEHWwV5gfUK3s20zHm3VgAvZiKhelcKsXDoLj92S8g8X NXgzf7uE6A95/hYDpuaXZOym5wAX+tHgq7/zWZcgXYVo4MFtZSadRlDubGy28/Ox5eChinQY6nZ T7/xiYt6iQjnkCNR08NBF3I1SzaDwqTwEQbomZvZWRFe66rcQtjXcfAwFIe2oo= X-Received: by 2002:a05:600c:4e50:b0:49d:17d8:abec with SMTP id 5b1f17b1804b1-49fc5728fa5mr129494685e9.21.1789985886420; Mon, 21 Sep 2026 03:18:06 -0700 (PDT) Message-ID: <5654aeb7-7742-41c6-a382-e1afac9d3bb8@suse.com> Date: Mon, 21 Sep 2026 12:18:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Barr Detwix From: Jan Beulich Subject: [PATCH] x86/mkelf32: correct VA/PA of PT_NOTE / .note 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1789985886-760FE4E9-8CFC103A/0/0 X-purgate-type: clean X-purgate-size: 969 For the .p_paddr, .p_vaddr, and .sh_addr fields the image load base (passed in by command line argument) also needs taking into account. It is _not_ merely the delta between incoming PT_NOTE and PT_LOAD segments. (The fields aren't really used anywhere, so this is largely a cosmetic issue; static analysis tools may be affected, though.) Fixes: a353cab905af ("build_id: Provide ld-embedded build-ids") Reported-by: Barr Detwix Signed-off-by: Jan Beulich --- a/xen/arch/x86/boot/mkelf32.c +++ b/xen/arch/x86/boot/mkelf32.c @@ -362,7 +362,7 @@ int main(int argc, char **argv) (void)lseek(infd, offset, SEEK_SET); note_sz = in64_phdr.p_memsz; - note_base = in64_phdr.p_vaddr - note_base; + note_base = in64_phdr.p_vaddr - note_base + loadbase; if ( in64_phdr.p_offset < offset || in64_phdr.p_offset + in64_phdr.p_filesz > offset + dat_siz ) From xen-devel-bounces@lists.xenproject.org Mon Sep 21 10:34:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 10:34:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427306.1650018 (Exim 4.92) (envelope-from ) id 1x8bLM-00051i-H2; Mon, 21 Sep 2026 10:33:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427306.1650018; Mon, 21 Sep 2026 10:33:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8bLM-00051d-Di; Mon, 21 Sep 2026 10:33:52 +0000 Received: by outflank-mailman (input) for mailman id 1427306; Mon, 21 Sep 2026 10:33:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8bLL-00051X-8H for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:33:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8bLK-00C4CP-Cs for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:33:50 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab10803-8faa-0a2a0a5109dd-0a2a45019582-40 for ; Mon, 21 Sep 2026 12:33:50 +0200 Received: from [40.93.194.19] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1080c-5984-0a2a45010019-285dc213eaa8-3 for ; Mon, 21 Sep 2026 12:33:49 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by DM4PR12MB8476.namprd12.prod.outlook.com (2603:10b6:8:17e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Mon, 21 Sep 2026 10:33:44 +0000 Received: from BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740]) by BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740%3]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 10:33:44 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Wb185xC2RV/lH2iVx6cGcXNmSCc1iwYTXJBJ5YdOioEYGR271Ko57Zw4aMHkefcTlR1dTK9+gLApR/g2Na2lE1DzywhlHexqGQX7iAgi/gZzJ+F4F5LEygReRsiN6EdE3dSU4TW+DU5cxNIdp7AMH3UhI2QgPwSPRgEgz3OuWI+QrOeffTFOq3goH+KPGKM42YuOZb+vGXGby1fV2Cwk8dao7eJOHVZ6UlnBETj0/7Um2+0VT9JMeTjLys8wAkiqOG1rapBMFH1mTIQlAtY3V2NXu8RxrjGSpz1VK1fjAzpJYpgA9BrWzxw5EWIYEpljHdbjcdHI2ns//EXeuib/ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hUGcZx9JMM0CLlYcat79eCQxbX9srWdY91u4plhDTHs=; b=EUkYv1Qaylsk4mJa5usppPLmc6LWCw/nM93V/66ECKmPNSZsnVt3AoaMHNNo3wpdnhPvlB8CZNAy6Tr3+LPWfBylkmk/H+b9MU5ajOo1l46yu/lMi8zfYP0tBvi7No340Bp05ziwbMVSSq7A/EHpULLIMFQhh3Ta0MDfJTDvZYFPC1EkCZzVXRqcvWkpRvTxt9Ai9hGk+tBxEC0p3bSWn8VHxgPV26K3xkHOe4F3ogpVj8tiwCBs8byK5yjSYc4mozUq4B1xFPQI63u2cVylGIL56M4O6O4FdMOgxhpW0jogMj3ZNZBBBtm96wgAW5Hxj5UVuHfGOtdNrwaRNd2A2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hUGcZx9JMM0CLlYcat79eCQxbX9srWdY91u4plhDTHs=; b=bgS5Wcx1BpqgpmbenQ4VTWtwomRqR+FolFDfwU9dBiYyNIoNgcSZdatBBdQYocZuX/oi1WVabn12hHSpWPKpk9qwW+4cy6vpKmJZNt+qYr2rdJ3Etc4bWJ6XaqS80Ud8qsj1FZiE3ZcUBAEQ53I3/OTxl2ipAmZqM7FeY7o/mEY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 21 Sep 2026 12:33:40 +0200 Message-Id: Cc: "Jan Beulich" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Teddy Astie" Subject: Re: [PATCH] x86/vpmu: Fix incorrect printk format specifiers From: "Alejandro Vallejo" To: "Andrew Cooper" , X-Mailer: aerc 0.17.0 References: <20260921091651.34761-1-alejandro.garciavallejo@amd.com> <489f6ce6-2be7-4c94-bcf0-21fc6993f98c@citrix.com> In-Reply-To: <489f6ce6-2be7-4c94-bcf0-21fc6993f98c@citrix.com> X-ClientProxiedBy: MA3P292CA0026.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:47::11) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|DM4PR12MB8476:EE_ X-MS-Office365-Filtering-Correlation-Id: cb2c4a2c-1e87-488d-f2ef-08df17cbcf86 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|366016|18002099003|22082099003|11063799006|56012099006|10067099003|4143699003; X-Microsoft-Antispam-Message-Info: nzbIDUQz1ELFD7R6O+HAJ7jU4Wvp/1besIX4tgpesQPwl7ZagTqH0Phh82kUzgsdINLTogMgTpgSMkZcp7NSGlYAyQMzODaxTAXuequTIQOLP3XsQHAONgWVC7UjNu93HkY7Qme2MFg7n3p9ys4/EiAiDtt7iTpoje3eBRQn45tiAFz5g26mftL5cC0DLf29Xne+9cfParUJiJpAseqeH7S5F1RzGwWa05lx6yPesoE/TT8fwdF6hRoAyComnysw8kGt1HQtqSuww+XSGpCZBmiTH8uyBAFc0Xs89hfe14EGupl3oWwkvm47M4drlYfMsgvWQxdlhGxCfsW0GRTRVxiaOvVNtXI2J2sC9klsAzOufQ2ZiS3mVfOGhe2Iz2P0eEqZkrqfY0OgRdx9Tor5a56w/t6Idx/+o19Ftmty507jvQicg3KX3zgkRtrPn48KOxSvoXB7mgk6aHCuSA8YHO0DCMt+ntQJsbXFmPcU8S+ZMEWNbUO5J3u2G/Rc/T+7T6SQcdD7gKkBulkDKW0iHqrGwxcGqNtXlqwMZ1tVlU3m7/F7Xx6AbrwZ572exsh+Ga+2ctEDzfHTul05Z4iuCjeJsL89203z13sCAXHyu/mHTWlxSf/pHYelR9WXEgBg4xqtO9bEVtm0615s7wiMwBBr5aF+njn6l9LoQiq9AxY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB4999.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(366016)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZFJydG9tRUZ4TzA1MWN2VU5OdVUvSTNkMVVMZy84NU9RN3hObStyTGF2MjJx?= =?utf-8?B?amtWSGsrMDRrZU9KSFNXR25Va29nT2xTWjJJcDE5WlFlWlNma1pvNFRQSDBN?= =?utf-8?B?NlNxdmpzVkdYNWdkM2JKQTBSMGZQeGFobDF2T1UvaUlqekl4RVJiOUZ5c0Vz?= =?utf-8?B?YVRtTlg5RkNuQzVFMWlQWDNrUGJnNTYwTDRndFRyZ3lxa0VpUnJycUZwTnRE?= =?utf-8?B?aWJUNG8ramRJVXhtdW5DMlJ2dUlVK3ZiTnFyQzJTaUlSLzVCZGh4SXZiVzhY?= =?utf-8?B?M0lCbjNtT1RWUTcrRUlDTE9tamk1NU9tTVhnSUcyUUtld3VwOW53dFR4ek56?= =?utf-8?B?ek1rQkcvUmJsclRrcjVoOUN3MGx2a05wRkNyVUh1bVlTUzlZQ2xTNVF6L0xa?= =?utf-8?B?bHFLSjEwOGh3UEJaL3BNQXJFYXVOTHo0QnR3WnNyMndCV25GTnBwYW9tNm96?= =?utf-8?B?anRRd1dZQTZ6YkJtOUtjZEU5dmZmNk4vby8wNkxkZ0I4V1NESnhjU295c3g2?= =?utf-8?B?SVhES2xVVWZUMkhpQXI0RmJUVzV1K1Q2OXlqZVdmekpVMXJLWXJwaEt4QWxz?= =?utf-8?B?U0VJNEJkZTZlRDkxZEFNUGtRUmhuVFNpd2tsTmRmZmVCamEvUWY0ZzBoaDkw?= =?utf-8?B?Sk9NdG5lV3BpM0x3c2FETTdraEtzVjA2NXNFOStXNklzSEs3YzRtZi8xMndI?= =?utf-8?B?NWgzOTA1SHpxSnI1YjZ1a2NWOExuWm9OYW5mQU4zTWkvK2dUVU9IUjlrTWVl?= =?utf-8?B?cUlHQy9oSXV1WDMwSTdub2htSnYzOSsremNSa2oreTVHYnQ5ZHFsNlNOQ0Ux?= =?utf-8?B?blg4WFA0cThXaVlDdjV2S0dUTEhxMEdhb2tSRlVPMGFGdWpXeGZSTEs4SXVO?= =?utf-8?B?NXQxSTgxS0NFUDhVYUZtQUpPWHNwM2FDUTFRRHBLRHFGYVRvbmN2Z0ZHdHYy?= =?utf-8?B?OG5taEdsckxWV3hFN2swdHliVFVBRy9rRzVCa0RYZFZHaU1aajF4VmRDK2lW?= =?utf-8?B?WHhVcXNtbkI0YVl0VndhbTduWHgrWElPaVlnbmJGQzdEZTFkR1A0bTFOOEpI?= =?utf-8?B?U0xJR2pzZ2x0MDRJeGxOblRuWTVaaW9MRmpST1RNckMzQ0ZJd1cvaHAvVWJi?= =?utf-8?B?bDY2NThiMTlGWEIvVVpWakI3V2QwaUJWK3NtWkZtdERVdEZub0M1SG9rK0pB?= =?utf-8?B?dFBudHhORHRXQkpSWXNVbWI2NHRRMnRwOXVMUVpCdktMNUNINEVRampSeURv?= =?utf-8?B?OFJJLzh0WTlrWjBBUy8wMG1RV3Y2QmhEeGN3bWhoaWRZMGtxRGtEZjBKZ1dS?= =?utf-8?B?V0hscVl0SHVqZk9uQ0V4SnZwU0JUZFd2VkVMMnhjSE95RDRxeElHNHdjNkZn?= =?utf-8?B?MS91azg1b2N3UHNGaW9VMHZSZXUvNDI4c2tkaU9nMjNrWDNCWTlTSnFSM2VL?= =?utf-8?B?ei9BMUEwNUZmS1piS2V6bU5UVW9TTFluMy9pMkttVGdBUXRzTjN0azJLZkhY?= =?utf-8?B?TkV1VnhHRUxDZlArYi84VTB5RmhDOHplOXdlaTZDRkpqRHhuNW0wQmcxZ3N6?= =?utf-8?B?R2tQMFdPSlVEMC9SV01OS3Qzd1dhaWVXQ1psZGpXNDBvRmpzK1F2UjAvQ0Fn?= =?utf-8?B?VE9KZE5qdTlFSEQ4NVR3UHd3V3NTeDdnMmgrMExWUGhhUUs4ZmdCM1kvbHRP?= =?utf-8?B?R3J6ODNEUXphYzlIS2t5UW1JckZyeDBrVkNBUTdoTWhXUmJldUpCYVhuQnZS?= =?utf-8?B?YU9VZnVwVWJNQnBDVmxBS3hCbW5yT0JmcEpYdDd5bzhzaktoSldEdW9qcW54?= =?utf-8?B?MWoyclhONXFLM0xsdHdEazd0SFEwc3VycmpWOXprMVdXRE1acTNlNXAyOURh?= =?utf-8?B?ZWpYc09FZWRXQmNvcUVzb285VFFoUllBY2N2RVRBaXduUXRzVGdWMEcyNkIr?= =?utf-8?B?UTZiOEkrUUxMMjQ1RDA1cGtKdjJHcVRMR0lkV1pFcksvU0NNOHF2V0puRVlC?= =?utf-8?B?MGRkbDdLV3BHNlhTcnlzMHlEWElBakhTWG9aODdpRGo5ZXlnQ2x0MkhnMWN2?= =?utf-8?B?dHRuajZCbzIvWHRLN2RRQVY2SkYyMEFaWUlQSVZWbHhyOEc3UkJPcko0RzFw?= =?utf-8?B?dW5tTkhWWnorcUJCQmZUdjl6STBqRVpOVDBXTjUwcmJNUHgrS1lkTHdteHFH?= =?utf-8?B?dGYwakFlV0crbEZlY3FNTzNqTGkydjZtWXlvS3VyMUNaZUsrSi9CY1pPcmdu?= =?utf-8?B?MDlrelFRR3Nmem4yT1NBM1RpZkhySEQ2bGExVGZYdkU3dnFGcUtMVjZ0VWN6?= =?utf-8?Q?PUvP4JN04kqbzRw1BR?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb2c4a2c-1e87-488d-f2ef-08df17cbcf86 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 10:33:43.9381 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QEY3itFH1ljDxEEaF7rLWcJdURWDleURruZkwqzc2/TPLMIjdZEqmjNPfDDWndaohbfaxd6n7EcyVwoOE8QrkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8476 X-purgate-ID: tlsNG-d62444/1789986830-1FC69757-73E7BD21/0/0 X-purgate-type: clean X-purgate-size: 781 On Mon Sep 21, 2026 at 11:30 AM CEST, Andrew Cooper wrote: > On 21/09/2026 10:16 am, Alejandro Vallejo wrote: > > The patch in Fixes adjusted two vendor variables from uint8_t and plain > > int to to unsigned int. But they were both used later in printks with > > the %d specifier rather than %u. Adjust accordingly. > > > > Fixes: 39a9a49449d7 ("x86: Remove x86 prefixed names from x86/cpu/ file= s") > > Signed-off-by: Alejandro Vallejo > > If this is going to be a problem, then shouldn't we turn > -Wformat-signedness on? I tried that before sending, but that needs a whole new series. Things are not quite as clean as I'd hope. > > For the patch, Acked-by: Andrew Cooper Thanks Alejandro From xen-devel-bounces@lists.xenproject.org Mon Sep 21 10:58:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 10:58:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427320.1650028 (Exim 4.92) (envelope-from ) id 1x8bj5-0008CO-Bn; Mon, 21 Sep 2026 10:58:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427320.1650028; Mon, 21 Sep 2026 10:58:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8bj5-0008CD-7B; Mon, 21 Sep 2026 10:58:23 +0000 Received: by outflank-mailman (input) for mailman id 1427320; Mon, 21 Sep 2026 10:58:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8bj3-0008C7-Nh for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 10:58:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8bj3-00C7z2-4V for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:58:21 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab10dc6-e002-0a2a0a5209dd-0a2a450693b4-16 for ; Mon, 21 Sep 2026 12:58:21 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab10dcc-195a-0a2a45060019-4a7de18c93f1-3 for ; Mon, 21 Sep 2026 12:58:20 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccead2aecso13324655e9.0 for ; Mon, 21 Sep 2026 03:58:20 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fcce144b1sm359201755e9.0.2026.09.21.03.58.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 03:58:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789988300; x=1790593100; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=8BmhJF9Srm/q9STvUy4g6zTuDbV/sf9+RAd0+jQagXU=; b=jNrII/E/vdYSau1hdW0ww95ixmZ4hNwXPUhem6OQ2yoE6u1FPUQ4QluFOV4oxznPoF 5x6n5jWh+yJC6eNwoZoX/+ZeIWExTrXHd5NpQCUIlDcUaev6Mdms8TvI2zbetAF7UDqd GzF6qJV1dezCuOt6q7uGfs4riqH/gMXDrgLka/GBQryweXUtfGy2RLkRNdXtp8Ien24+ E9Gdn1huWscyU6yCzRbr+Uw4sKCZ+E5inUCDS5hxGRvNeK/wKL1UmRs4LqkZWoMMGc2E BB+ZImIIb76A6hyEQPVdTiDx9800gh0dkjLwry6I84VI9hMTpg10/ySBp2Mj4WUG01T2 RKQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789988300; x=1790593100; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=8BmhJF9Srm/q9STvUy4g6zTuDbV/sf9+RAd0+jQagXU=; b=pgSsAv0FdqXGRRZKWOxC4l+aDV1ug9rWzZ9JKjovCjD2JnCgKKm5kZv0lew8xwskhq ffesAq/anp+e2EJ1oLv8nD3fi39BldB4PtQtTw48npPOtYY0sfREv6oOJqIw8IM2lAVP 8qpUZZc0V5KFTqRSLXPVITrnhteSnzQt7mRZh5Txcc/gUt1hCFdX4Q+qUrxEzm1Mq0ix 9rfGVCSHmCYFbr42FTstUZRY8gY/NP/9zSs5PYcx0+967b+h6F1X2OJO9dEW3u8k0yFr pZwZMXb6FuZF8J4GfWJ0yg/YtP01ddVN6EWC64CTW2SZjS1YQcRh0UKMA/3pX5PqwF3R 3XEQ== X-Forwarded-Encrypted: i=1; AKwUvBxzRPFuXEYHXgkwmmQq4ZShHX7FZIjBSXf29oVWmV7JC8+9MN3iCqmA+87xWohfA76IrYpRIL2wka4=@lists.xenproject.org X-Gm-Message-State: AFuF++l5sxpy9k5RTtIZjLHgYHLLCmc5Dvg+QHify0B64ZETqcnheeo5 RqrBOMPFV6qCAN78T1ThcDcKY/628QnY5QAlO/+7snx4HIdczcRd/kWO X-Gm-Gg: AYBFou3jMKShNvKlW3BONGiDVfQJkK6+xB3cpwRJhwycYg0XsK/I8ilb4ybJdC+cB9Y gFwUnKaQwyrHPk7dicpFMBVXtzdTUgk2aW9N1fOMmIWPwS9esuk5ZzhfTl4EcGKjE8brK1gmMpd URX1WOxd9c894DqfECsi9gOBr4cKpvR/Lpi1qtUzufTdLgPXFUXg2QsqMkfgL5fd4at4a/DKFIh u32PyfSCaH6r1ez1XUtpQM1dHwa0Jg+7d68DTDXyONfRHmEaR6LsNmocKQ9aVQWOHSbppotu94d JsOKcFYqP8wrmfIVpgux9G4vdD50x24XhSWCmNzs+oyrFoi/fbT1lk6dZ3lJjuGe25/AU1r0rTz PFxbDLgXooN7fhlLn2W1iGa9wyZfu34aSm6Z+RtVbFVi6hopu7KXXttfUGvyWo87xEG6Sq1kaaj GtPjlbVZlb5p5g+qUGwjxyyG0op4miYneNell4rRdrMP5Ox9DhxL8In0s3uIKPsD8kS4wCLO/S7 xS7ewHPA+3Ut4IlgiRphcjCDQ5TTrzlMV3OUbkqoUjZXAhDzg== X-Received: by 2002:a05:600c:8584:b0:49f:cbf1:e76d with SMTP id 5b1f17b1804b1-49fcbf1e9a5mr86658985e9.0.1789988299626; Mon, 21 Sep 2026 03:58:19 -0700 (PDT) Message-ID: <7bdcfb63-62a2-4b44-8a29-572c7558ed78@gmail.com> Date: Mon, 21 Sep 2026 12:58:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 34/39] xen/riscv: restore register state in the new IMSIC VS-file To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8672bc80-38a5-43b5-a5d0-40a33dcb01dd@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8672bc80-38a5-43b5-a5d0-40a33dcb01dd@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1789988300-FC20077B-45F9A06C/10/73395122804 X-purgate-type: spam X-purgate-size: 2259 On 9/14/26 5:21 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> @@ -630,13 +649,13 @@ static void cf_check imsic_vsfile_local_read_clear(void *data) >> old_vsiselect = csr_read(CSR_VSISELECT); >> old_hstatus = csr_read(CSR_HSTATUS); >> new_hstatus = old_hstatus & ~HSTATUS_VGEIN; >> - new_hstatus |= ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT; >> + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); > > Please put into final shape upon introduction. Oh, right, this ... > >> csr_write(CSR_HSTATUS, new_hstatus); >> >> /* >> - * There is no need to use atomic functions version to store >> - * values in MRIF because imsic_vsfile_read_clear() is always called >> - * with pointer to temporary MRIF on stack. >> + * No atomic accessors are needed to store the values into the MRIF here, >> + * as imsic_vsfile_read_clear() is always called with a pointer to a >> + * temporary MRIF on the stack. >> */ > > Same for this comment perhaps. ... and this should be part of prev. patch. > >> @@ -1077,5 +1140,12 @@ void imsic_migrate_vcpu(struct vcpu *v) >> /* Free-up old IMSIC VS-file */ >> vgein_release(v, old_vsfile_id, old_vsfile_cpu); >> >> - BUG_ON("unimplemented"); >> + /* Restore register state in the new IMSIC VS-file */ >> + vsfile_data.mrif = &tmrif; > > Ah, here &tmrif is used a 2nd time. I think it could be dropped and just properly init vsfile_data.mrif during declaration: struct imsic_vsfile_data vsfile_data = { .nr_eix = imsic_nr_eix(), .mrif = &(struct imsic_mrif){ }, }; and then use vsfile.mrif instead of &tmrif. > >> + imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_update, &vsfile_data); >> + >> + /* Set VCPU HSTATUS.VGEIN to new IMSIC VS-file */ >> + vcpu_guest_cpu_user_regs(v)->hstatus &= ~HSTATUS_VGEIN; >> + vcpu_guest_cpu_user_regs(v)->hstatus |= >> + MASK_INSR(new_vsfile_hgei, HSTATUS_VGEIN); > > Nit: Indentation. > > Other comments on earlier patches apply here (and possibly elsewhere) as > well. Just ftaod. I will fix them. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Sep 21 11:07:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 11:07:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427328.1650035 (Exim 4.92) (envelope-from ) id 1x8bre-0001PL-6u; Mon, 21 Sep 2026 11:07:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427328.1650035; Mon, 21 Sep 2026 11:07:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8bre-0001PE-4D; Mon, 21 Sep 2026 11:07:14 +0000 Received: by outflank-mailman (input) for mailman id 1427328; Mon, 21 Sep 2026 11:07:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8brc-0001P8-FF for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:07:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8brb-004Cjv-2L for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:07:11 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab10fc9-2eae-0a2a0a5409dd-0a2a45058a42-40 for ; Mon, 21 Sep 2026 13:07:10 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab10fde-4cb1-0a2a45050019-4a7de14cf58e-3 for ; Mon, 21 Sep 2026 13:07:10 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843cedd129so1681431f8f.0 for ; Mon, 21 Sep 2026 04:07:10 -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 ffacd0b85a97d-48724562aebsm23719685f8f.14.2026.09.21.04.07.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 04:07:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789988830; x=1790593630; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Xw4VBxE983YnbFcLC0GprfU1PlpsmJOR3YiKLobcOzM=; b=cYBkooQUXnXxKj4wOV36XwR6FSYia6SRA4c9U6lIQjsEYcz5nccMnN/IT3l7odt2EF vs/JA343tjX/q1MK3p6TkErqr2LPCtAYAt2zOB9NW2keiUYZGPq5Zd/QZpW8s+vJkcMy KNpDs6gvXxpG/KcnF5ZE5IEB5UIYncxQpasvCaLQHOJ1dbSjaEqlcRgd2EqazDk55hH1 hANp+vcVbfogE0gL9JsPpuxMtWUuQkoOLyfOeNnoSbYUzKwRQs6t0TXaOcBYXbeOfxlZ 4RWjUOTmd33s0EizdJdrixzN/oGaPF5E1+WC1whUy/UOZK8CO4RBGQ34kDtB7ieLbyAC reQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789988830; x=1790593630; h=content-transfer-encoding:content-type: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:content-type; bh=Xw4VBxE983YnbFcLC0GprfU1PlpsmJOR3YiKLobcOzM=; b=JAD9SeL/FeVuJFTtiHZLzPSSryut9gOR4hUZM4iALh0yHKr8l3ClPhG4QaMCvpmJV6 Q5xaAYN7trFHOTO65gI0wkyIFOX5Dz36JnQAuK9ZNUXGzdVYd3TQxN797tuKW95+g1v1 /HnohIGGosWd9ZxXuwxmDo17hVIy7oywZheMKJJp0OoJT8Wtj6Cs8eLccHuobkUcBTpI FRjuMi9IcHlV6E7k5RPBOYOOA1EOgNnaPHQgGAFD1ImAp3d6K63xuXwUBFFfON03a+JS RiLfzjV1XHctbbFsdEfTobP/7c9eHKfJk2VICSrmzyIL5Z1Wvy6EWUFEqwq2ktAzbRxB 6CKA== X-Forwarded-Encrypted: i=1; AKwUvBwoNMX+zhypY9T6tkbjqZz5iil/Le2nrbQAAiQXQtEfgZR8G4mbSJnsyAOQuMw1Z3+xeC8XnDetgk8=@lists.xenproject.org X-Gm-Message-State: AFuF++nV7LNzi4sUr4vjPmZ5gm/Qp8KGk6dI4VKz/9HnwWCiIvfWqrY5 F6ZPM3zovN65awfQNXzFQtspSM+0kuG/y0vOz456aRM6si6kb1q8FZKBhafuB15qNw== X-Gm-Gg: AYBFou0hU1nJ6/aJjO45HB6Ac6ryi8IBGxaN44+OPYuIskaLX7S0sP/UxH9dvGhCXT7 Btog+Cf2Z3BetFL4nccAdJBFTuUs6s49zzhJgQ5jaPvjkcxhcYgcSmHbqS7a/nTTX4iazvF6nGR hLoxjMZW6i4SkeSzkV57UF/ngkjGtTOC74iEb1GxapFvoB/2GJw7XkWJ6DYvI/CtWGPr7FDheIQ XCBjM8caf8udgGn8D2oBrZZBKNhmhNT84Wkyh/H72bd6ibnRLjhXwyEV1eZgDbzZ0PAw11BTm+r whAQiqf3CBnGPa9WStXf0HgBG/CmMHOJsfszSDlUYW3eOH1lSXpAK8b6RCkqDkXUDVggqMBZ5OA r7luUxOaLAn3bS4VGXdO8o57ixI5OjZVqzLxXQsK/YVt3t0v/TYN8NrQwt1hmjVdwfxOU7qWqjp EpGZRH0FHvFPTUDBXxDGH8eOacQci4qYuJvhwlFvfNQJHHBpyhR4GQSMcnwKiCch7huXv7+gJMP NVpgH2X4kWDe4IfKAQde2x+RcgJ/JWOpkQamlwRFQn87v14LN1NbhjCY6N7FMw= X-Received: by 2002:a05:6000:2c0a:b0:487:27f6:a4cf with SMTP id ffacd0b85a97d-48727f6a6d5mr10055095f8f.31.1789988830406; Mon, 21 Sep 2026 04:07:10 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 13:07:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] vmx: Handle TDX instruction exit reasons To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1789049962.8631fc262581453bbf619ec5b2062170.1a08bb0014d000c4f3@vates.tech> 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: <1789049962.8631fc262581453bbf619ec5b2062170.1a08bb0014d000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789988830-F7CB82A1-C1D262CB/0/0 X-purgate-type: clean X-purgate-size: 568 On 10.09.2026 16:17, Teddy Astie wrote: > On hardware that supports TDX, guests can cause VMEXIT related to > TDX instructions (SEAMCALL and TDCALL) regardless of VMCS configuration. Can they? SEAMCALL pseudocode has ELSIF IA32_SEAMRR_MASK.VALID = 0 or events blocked by MOV SS THEN #GP(0); ELSIF SEAM is globally disabled THEN VMFailInvalid; For TDCALL I see IF not in SEAM non-root operation and not in VMX non-root operation THEN #UD; which may indeed not be sufficient, but the SEAMCALL conditions shouldn't be met under present Xen? Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 11:21:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 11:21:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427340.1650045 (Exim 4.92) (envelope-from ) id 1x8c54-0004Lp-AR; Mon, 21 Sep 2026 11:21:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427340.1650045; Mon, 21 Sep 2026 11:21:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8c54-0004Li-7d; Mon, 21 Sep 2026 11:21:06 +0000 Received: by outflank-mailman (input) for mailman id 1427340; Mon, 21 Sep 2026 11:21:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8c53-0004Lc-KX for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:21:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8c53-00Cw3G-0v for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:21:05 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab11320-8faa-0a2a0a5109dd-0a2a4505c368-4 for ; Mon, 21 Sep 2026 13:21:04 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab11320-4cb1-0a2a45050019-4a7de14cbb3f-3 for ; Mon, 21 Sep 2026 13:21:04 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843f22dc83so2026113f8f.1 for ; Mon, 21 Sep 2026 04:21:04 -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 ffacd0b85a97d-48724460964sm23503451f8f.7.2026.09.21.04.21.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 04:21:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789989664; x=1790594464; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=QVffXoYueTw4wefpnWYLUUvPFBee2WkB5xh1yrvBjrk=; b=fF2AENHSYEgeUXM/6Thl2W8F6dYoWUpYOia6Cm6BXE1UmbkpwCglQkbf1nJkrR6LPk i2qV38mk79hragJtCevv2y9qfi3fEVl/fv2jKPrr0ngEd10UwjQCkRrDtAUUQALICmji mueUT389Tvm4klAg085ZHh9YY+naNHvlQCasT4WDKgOMNmba2DNbseUCsZeP4aHmeku2 77n+w6CJKDSYH8qMb2jYz2edeiKhf2mXiFOs3AbmE/Wppdtwcd/blnQGBERIC7yJ45tS CvSOQ+floU+ZEZVlxFLKLwUKvD7wKC0szdpOtvU0moaq/mDk6oR5vzFFdfLdveoeQz/w YP6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789989664; x=1790594464; h=content-transfer-encoding:content-type: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:content-type; bh=QVffXoYueTw4wefpnWYLUUvPFBee2WkB5xh1yrvBjrk=; b=vnzZyX0ugwTV/KbhYkg51rdToob/kgkW+U/t+oDzG14jT8S65MHjSEr+DMmUi3ljDq ctEjVafsfi72V+Mh2oVjsbA9EVDXObvIqYNy/TnzFLDuxRLfFOz6EA82X9Zsy/aJyLET raV86Kqq7TeSVYJzxEBUIyDR6UJUYQ5IzQX75Ae9lhum3Cv9kbSNicEwg+7JfNbY4c8R AIlHAnt0uDMjZRT894xAO6TBfKYqakLMFUjIBtrOk5b7SMOxrr4QKb85kBPE04tUEd/l zbd690haiR3L6/QHhXyPvs5zmp5mXfgYQMGw/zXVr4q6zfVM1oZ7oYBv9kodjv0Qoz5V +iXg== X-Forwarded-Encrypted: i=1; AKwUvBzqn3rqosEgaiyoL3AaeOJwUd4zsSnrkZoxdZeRsylmb7wy2FeropFsthZo8H0EIFwNB6l+Z7MYwLo=@lists.xenproject.org X-Gm-Message-State: AFuF++mPKxJYXzuh982k0R3FMTLpRw9VPA+K8Kh9p/XqpnKh4Fhi6CAL DrOuf5fAgAnCfiMiCD2AUQX8XwCU/fK+iLohzOyFAMaGXLA5NMcmY7Q1hN53KMSkdA== X-Gm-Gg: AYBFou0DioGO6xTHIQFP7DyLf3k2Yu5UEdkMU8w5SGi8seUgmmAhHEbEWyoU8lrWpy2 5U6W4rpQSY1+WMjdoqPkci2NZXX2fZridXj2wyGNJb5U/MMyynHNqZX7v1cRMzD/5Pl2IIumczv jWCcGXcINvFMQIUCXz1CGncPZzUeHl25p0ZwAHYektIyof1xwsWvQx5NFjXC1U4fayCyZOYZcSV fhGB8UoSDrIKIzlBRjh2rBAV+keOX+qu+MmqAuc12tSkMmrlZxLj2Oujx4ZEndxYDZ7HEcXDaBA qBXCKfIx8wMazj3bZxvnHLIdp1k9vdWYThLu4vnVP2AGIk+pkJzUx49F6fTX7CmnBOVU3Pu2IIq DvzTCNZeXY2lvE4s2mYAwy16CIfJv8Bt5TVEBChhb5ZjzaXeg50ejtIHIxSynDWlmm6zxhMTyvN u1MuEHYV26aaFX0NKMInUhqTSEXe4jK72nkHKQiYf7tLJSxifbbXrguTcNuxOqU6ypVmQvxGTHp uEewhxZbtPASqWhR665CjCmQBOI+Yzd6codktHTcr/IqsmoEuONYL58wBqajDg= X-Received: by 2002:a05:6000:24c3:b0:487:b4d:8810 with SMTP id ffacd0b85a97d-4871e3a9f00mr16352453f8f.39.1789989664220; Mon, 21 Sep 2026 04:21:04 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 13:21:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/svm: Fix VMLOAD/VMSAVE state handling when using nested virt To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260911151250.1232332-1-ross.lagerwall@citrix.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: <20260911151250.1232332-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1789989664-F70B22A1-04B0D44D/0/0 X-purgate-type: clean X-purgate-size: 838 On 11.09.2026 17:12, Ross Lagerwall wrote: > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -444,30 +444,30 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) > > static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) > { > - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; > + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; Here and elsewhere you assume that vcpu_nestedhvm() is legitimate to use even in the non-nested case. I think that's heading in the wrong direction; I think that a hypothetical mode with CONFIG_NESTED=n and the entire struct nestedvcpu wrapped in #ifdef CONFIG_NESTED should still be possible to put in place, without meaningful rearrangements or renaming besides the adding of the respective #if{,n}def. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 11:25:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 11:25:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427348.1650055 (Exim 4.92) (envelope-from ) id 1x8c9f-0004sf-SY; Mon, 21 Sep 2026 11:25:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427348.1650055; Mon, 21 Sep 2026 11:25:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8c9f-0004sY-OR; Mon, 21 Sep 2026 11:25:51 +0000 Received: by outflank-mailman (input) for mailman id 1427348; Mon, 21 Sep 2026 11:25:50 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8c9e-0004sS-69 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:25:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8c9d-00CE6N-0r for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:25:49 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab11439-8faa-0a2a0a5109dd-0a2a4509b64a-14 for ; Mon, 21 Sep 2026 13:25:48 +0200 Received: from [40.107.130.122] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1143c-be1a-0a2a45090019-286b827ad6f1-3 for ; Mon, 21 Sep 2026 13:25:48 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by DBAPR03MB6613.eurprd03.prod.outlook.com (2603:10a6:10:19b::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.15; Mon, 21 Sep 2026 11:25:46 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 11:25:46 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IDmn9iy6RL9NmuXy2lUNoTGZxVvGOBTYr4Z/Y/nRr/G1gxbxh9ZJ6otfCsjixq9AY34i2fw+bc06AV5NQ8iiheGdP/IeD23st/2hPCm5Z9uQ05sB2ygKyVxXfU6JwuXrWUWIfek+qsYGzQ4zKqcIw8gl4kwMuBsZJOTTRgmd2E92VB2bQzWmaHmDfXnNCtR4rR1bGTjQ+I+tOEgzpeT0nZcjnVlth4/7aM9Hd1zBJXLORRcWfTIzA/yStL7EUHuRBSixJbQvKDBVsiyL25/rUQUaGlMYS7cXgFkE991ssNyxl0LdV1gf8yAlWkGoTAx3Ca2uDx7DYIurDHmQgSjWnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gInDqvUmat87BsFtiV4wX/Ma1zOReKqD0U48CEuYybA=; b=sv4Rc03R5jRvwCO8Oyg9awrJDtybqVDMeaXL4dTVTRlXUd87d/VJ+f+YtceADbpoRzRa5m+ziLV6kEpECO7DB1JnA8KNzXcpyepNtP/A++jQMPY5CochoNTyQsEjBo5gvgYTmxGfE79euNwucT1FVAj/wxemSocsJ8ASgBvlxXU0dGuuchuGflr6RXCkUU0h8JEGZmKdS1bWUG6Php4mBlcYrdD7MrZ6ClQ9AAjYL4OWdw/p7EO3Jp9wGudJ06K+i3Qfq8M9MZmyl6QUsnuFV2Zg+VrAmmnscSisQBr3KEmcj7lEXfucyw9n/xKFigTC6uzZi74e3n2ChMcOXwgoZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gInDqvUmat87BsFtiV4wX/Ma1zOReKqD0U48CEuYybA=; b=SSDDfFdlqJ+pPCdpKg0/u4lXj+xFOpnoOm46vQ0bm9vkTtrfn6d+0t9ObWXznxNEKunrK7rSCmyYWInnJhOq+hG79e4CGeU18tIqq0JSeJHzBxB/vcInfGMfsuyzPhjXz2YGxkRN1p83ILNzLJbwNAN/uIxVYO3KTWmYESrmsPbeoNOg6/9yKOR3i8oxFrn+FxgbyP/TNFf8VNKicmaqlHfwUviOxphg5WdnOdjyb0ucflWepD4DWATwk7+jQwH1/E/+omnT4SjOggj6BPunExIxocPbi48SEbOPYb10BAClLd0d+I9VvaoQf1aDuWlmqvTBSqlNeCtUYvzc8X9ahQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Mon, 21 Sep 2026 14:25:42 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH v3 1/4] xen/arm: make is_espi() a pure range predicate Message-ID: Mail-Followup-To: "Orzel, Michal" , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <8e42437f8abca2722f1a2e2568bbb5b938c23e85.1787050437.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: WA1PEPF00005B86.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::618) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|DBAPR03MB6613:EE_ X-MS-Office365-Filtering-Correlation-Id: bb0d6446-8934-499b-b80c-08df17d314a8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|10067099003|56012099006|6133799003|22082099003|18002099003|4143699003|11063799006|5023799004; X-Microsoft-Antispam-Message-Info: imzUX6YiR7EqwvfI6TRzZKd5KZH85Dobk1sQd/OLqzkUhatX0DtQQipUMvsS6udTN6676DZMayvXuhpu2NDE63QEZzKfINTaJ9KbLEggHCnL9JC2R2R0nHzIueroYAgbZ+SY2sizVPwLrDTCEclAnX4RpSbkpipO+sgSQThc+O3PFhntoFLijT8yzlBK6vbtmSoS7B2W1UgjTtWwqnzXFRNKAip1KtwF7aR+E0RFtWNsxXSk43l5180qO6icBOdg921ve87Lz9hh/U1x/+9AY9MeLWy/Z0g01lgMATO6iz5dyENVU1usXVhOPW8rtqPPVKE6/pTF6jCnEx5fcWkyxR1iBPfEY7DP57W8v0BBtcfVY0KrEK6XV7ZaQwSkoQVuCWGyOet4KCYAs70tFOceGybIEIUhk0/yu0kw571DRY6Rb6gVmpnobPSIn1Phnzf7fSoJ4/NKgSxnloDabE74yNcaYMeZWOXFnXfHD6KC3MjpN2tOWJQZezcCK18CEWae9HcSF9zLn6vRdkBqzcpClps7Ry3oLSy1qi0S7iK6V5/minArmmrO4lh/q91KGk80t9N/0IVTHyMb2nfJVahHiMPp2Xvyf1rkRXZe6gUDzrp712IwCL0D0wrtdgqlk9IhE1xO7egmcyMhJkOR8MAfnnjNr0wytPw/hlIGLkbiqLY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(10067099003)(56012099006)(6133799003)(22082099003)(18002099003)(4143699003)(11063799006)(5023799004);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c0txSjhDenVsUjFzUmk3QVczTmczeHgxREZ5QzFDU1VoOHcybjM0K3pzNXR3?= =?utf-8?B?bkVsM2w5c2VubjdyZ0phQVI5U0JpTkJlb3UyZG5KdjJ2MFg4VGtWT2trWnN4?= =?utf-8?B?bmJoaXh4NnpPcjlKM21DY2ZKK2RyQmQ1dTcyd1Q5U3FmcDJCNWRHWWhKaDZt?= =?utf-8?B?SkVZUm5ZbjNFWHMvNEE3TFEveEp6ck1hcXRvSXNMOFMwcnBLT1dpNm16ZXZH?= =?utf-8?B?MjZFMFFkL0QzU3o4QVErUmFWb2RMcTV3Zm9DT2w0RjhiRWNWWTRNaUJTTTVt?= =?utf-8?B?TlluUGgySkljbUhtWS9paGliM2RxVE1vNUlsb1dyMGNYZGxIZnVqcTNaYVlJ?= =?utf-8?B?Szhjb2NMMWp3VzczZ1EyVE1KdVBLdjRURUtKd3d5c3paWE41RXFvaUZvZDNB?= =?utf-8?B?emFGZG5NOTZpNmdac0dLajVoVjF2akRLc09LTTY3c3ZCUnhBZnhrNnREMEdQ?= =?utf-8?B?aHl5V1VoOWhHNEE4U2l6blR5eFIxYkg2NzVyd0dsNFNYSmpubkMrQ0U2Z1Nt?= =?utf-8?B?T1kyTk0wdEpPRWFpWE1wc2Y5WHlXOFVjUHdWZ0hlVmZjM0hWTHRkdGNtbENO?= =?utf-8?B?M3ZTM3AxMGh6dHExMzZkMHRWOElVSkE5bDBoY2lsUnBKdzRyUVp2cnNpb3RU?= =?utf-8?B?bGpBbnFoTE52dW8vSVdmVE9Nd1hKcnFMSzNCcFUyeVRadFNUN1E0NEhVazdJ?= =?utf-8?B?clpqOGp4Q3dEeW5TQUFpNGY3YTRnQTVIK0M2NER5MUVrMzFvbUdZTzBaQisw?= =?utf-8?B?Ukgvbm9oNGpEenBmWFV6c3lXdURuNHRWKzExS241RjBBS1hCRmdjQzZmcEpj?= =?utf-8?B?aTdGRGFIMHgrK09qSW9uY0JWNTYxNTVLZCtKVmh3S0VNMWRXUHFUcGRjQWN4?= =?utf-8?B?UkxxbVdUSWdSVnlldkVRZ3VKaXcxYkk0VWVpdStJTDRZcVREcncyUDU5NTZs?= =?utf-8?B?MWE3SDBnaWFZS29DL1UvNzRycjllVXhWMDdVaE1RU0dSeHZqeG1PVU12b3F1?= =?utf-8?B?UG9vZXRNRnkyUjY0RTJQdE5aM3NoaUZrOXBnUjZLTEh3RFRrNEpIc3lBQVZE?= =?utf-8?B?UDVnbnFwN0EvMklsRE1BYkZ5MzJwOXhFTkdjcFd3NnRQMDZNcGFVSCs0ZDIv?= =?utf-8?B?enc2cFdydlJZaE5MWkljUGdQeVlNOXF5V2lUZVFIR1FZNDBMcTFkOWJPd01J?= =?utf-8?B?VWN4aHRIR2FZTndwK0NFdzZ0RnFuN0tQNGlKSGFGRW8zSVJqMWhnMk1zbmha?= =?utf-8?B?dWlnUE5YMmxrbFljN1B2ajRLK0dMdVNuTElYR2JnZlFnd1IvNjRqUHJINDVy?= =?utf-8?B?YnhweTgzbVM1TTFiUVJ5bzBMa0ZodkwvemRZaEdPa3RhelZlQmprYVgrY09n?= =?utf-8?B?aWVPVWNSRmdUR1pNODhheXVSeXNVM1M5ejZ3dGhMdVdLcG43MWMxa3EzRkcw?= =?utf-8?B?RjNKYmVObGQ0RUwzNzQ3NU9KMGJObjVSaUZjd2VtOGJIZkZXQk9keS85WExr?= =?utf-8?B?TTZIbkZNVzRqV1JWS3dZcFlEM0h2OUNLRlZSOCtuaVFjTnB2TStwMmdvWWs5?= =?utf-8?B?c3krb3RzL0MrNVU3RXhQd0FKVXFPOVZYekRkcXhud3B4aWF3clQrY09oaDVz?= =?utf-8?B?TGxqallUZWZFNnNGVWFobUpHRmJ6K1FEZG10MnBTUlJzeUdnZWc3ZjNtZ0xq?= =?utf-8?B?MExjbndUcUhETytqZjE4SXBmOEtRc2M3VkNYNnM5Z2k5K0lJZHpIM0c1ZUpv?= =?utf-8?B?clA4U0dIcTBlSkZsU0NUd0VqLzdaUzNoOENlbDA4SjBsemVObHdMOFNzdnZO?= =?utf-8?B?Sm5ZNnZCa2JJMXJ6SEEvcmVHZStPL05vUlcvSVAzMUw5VDFPa1hVYzlXNllY?= =?utf-8?B?MitUZ0NhY1pNRVByOW9OS25BOWZmODAvcVFwQW1pSUlMRWp4M1ZZdjFLYXNS?= =?utf-8?B?ODhBRVhNRHQzQlVGUWgyQjJmYk1aMDMvY0lOQ2dnMC9sbDlZZjBrZHJnbnJC?= =?utf-8?B?bzkzYzRvRzNEYnIzWU9Rc3VyTVM5NGluQVNyQzBHOG5oZDJTTHBNeENicVJW?= =?utf-8?B?L3lCbjB0NWhtTDZERFI5SmJFQ2lHN2F5a2wxaURYdjhsSTR0KzJkeWYyaWEw?= =?utf-8?B?bHVYNHlnanc2dHZOVmFHbkpQMm02ZWQwTTlvTXEvZjZVUEs0elJGZmZ0TW95?= =?utf-8?B?YnQ3MVdoSTgvVW5NazVMUURRZlJvdFRwNDAySm5RTXhSTzNPZVY0K09vbzJR?= =?utf-8?B?QnlsT3k0M1FGa1dVN1BBdUZhZVEreXhZV29Qb1dtQmtmVHJiRTBqL0xoa3p3?= =?utf-8?B?aXBZVDJ1akxXWFlzVE15STd4VXpPVThyNWQveWU5ZUJOQUpLQXNtUT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: bb0d6446-8934-499b-b80c-08df17d314a8 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 11:25:46.4383 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 6yIH/5DtaUZ4vNs33oOnaEStFW4AfqNNITsR7Pke/aUZDR8bQrpnKH3lhcPP3AK/0jQY19MjNYTvCT+gnYEGkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6613 X-purgate-ID: tlsNG-bad1c0/1789989948-FD469034-9F88B93B/0/0 X-purgate-type: clean X-purgate-size: 4316 Hi Michal, Thank you for the review. On Fri, Sep 11, 2026 at 01:03:28PM +0200, Orzel, Michal wrote: > > > On 18-Aug-26 13:32, Mykola Kvach wrote: > > is_espi() currently changes its result according to CONFIG_GICV3_ESPI > > and asserts when an eSPI INTID is passed to a build without eSPI > > support. This makes a range predicate carry configuration policy and > > causes callers to depend on its hidden side effects. > > > > Make is_espi() report only whether an INTID is in the architectural > > eSPI range. Gate eSPI handling explicitly at call sites and preserve > > the debug checks on paths where an eSPI is invalid without compiled-in > > support. > > > > Signed-off-by: Mykola Kvach > > --- > > Changes in v3: > > - New preparatory cleanup requested during review. > > --- > > xen/arch/arm/gic.c | 5 ++++- > > xen/arch/arm/include/asm/irq.h | 11 ----------- > > xen/arch/arm/vgic.c | 4 ++-- > > 3 files changed, 6 insertions(+), 14 deletions(-) > > > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > > index 078049e741..075e1d2c50 100644 > > --- a/xen/arch/arm/gic.c > > +++ b/xen/arch/arm/gic.c > > @@ -348,7 +348,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq) > > /* Reading IRQ will ACK it */ > > irq = gic_hw_ops->read_irq(); > > > > - if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(irq) ) > > + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq)); > > + > > + if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || > > + (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)) ) > Take a look at LPIs that are also protected by CONFIG option. We don't ASSERT > because they are gone in a release build. We want to BUG() for eSPIs same as for > LPIs if we cannot continue with this condition (we haven't configured/enabled > them, so it's impossible condition where something went wrong). Here you should > just BUG(). I will replace ASSERT with BUG_ON() and remove the extra config check in IRQ dispatch. > > > { > > isb(); > > do_IRQ(regs, irq, is_fiq); > > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h > > index 09788dbfeb..c29f3d04a3 100644 > > --- a/xen/arch/arm/include/asm/irq.h > > +++ b/xen/arch/arm/include/asm/irq.h > > @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq) > > > > static inline bool is_espi(unsigned int irq) > > { > > -#ifdef CONFIG_GICV3_ESPI > > return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID; > > -#else > > - /* > > - * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is > > - * disabled. Returning false allows the compiler to optimize the code > > - * when the config is disabled, while the assert ensures that out-of-range > > - * array resources are not accessed. > > - */ > > - ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID)); > > - return false; > > -#endif > > } > > > > static inline unsigned int espi_intid_to_idx(unsigned int intid) > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > > index e5aca17dcb..e14123a30a 100644 > > --- a/xen/arch/arm/vgic.c > > +++ b/xen/arch/arm/vgic.c > > @@ -718,8 +718,9 @@ struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq) > > unsigned int idx; > > > > ASSERT(irq >= NR_LOCAL_IRQS); > > + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(irq)); > > > > - if ( is_espi(irq) ) > > + if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq) ) > Following the LPIs, irq_to_pending() returns NULL if they are not supported and > we somehow ended up here. We should do the same here without using IS_ENABLED > and ASSERT. Note though that for that, some call sites need to be enabled not to > dereference NULL. I will add an espi_to_pending() stub that returns NULL when eSPI support is disabled. I checked the callers. They already handle NULL, check the IRQ range or register rank, or use allocated IRQs. I did not find a need for extra NULL checks. I tested the proposed change on QEMU and FVP with eSPI, ITS and debug support on and off. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Mon Sep 21 11:36:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 11:36:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427359.1650064 (Exim 4.92) (envelope-from ) id 1x8cJS-0006b4-Rq; Mon, 21 Sep 2026 11:35:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427359.1650064; Mon, 21 Sep 2026 11:35:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8cJS-0006ax-OU; Mon, 21 Sep 2026 11:35:58 +0000 Received: by outflank-mailman (input) for mailman id 1427359; Mon, 21 Sep 2026 11:35:57 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8cJR-0006ar-6c for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:35:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8cJQ-006lN6-JO for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:35:56 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1169b-bab6-0a2a0a5309dd-0a2a4507c036-6 for ; Mon, 21 Sep 2026 13:35:56 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1169c-b4ea-0a2a45070019-4a7de18c9259-3 for ; Mon, 21 Sep 2026 13:35:56 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49d1ca5b0d6so21115205e9.0 for ; Mon, 21 Sep 2026 04:35:56 -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-49fcd10d21asm275792325e9.12.2026.09.21.04.35.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 04:35:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789990556; x=1790595356; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=ThUHx8jzT/Saq/lfPNNpnxBYhWVh0VLHw76lSWYKo/g=; b=KGRVN4iHCmC7tpUiXXeU1GIGsk6UMU6fmT16LvsHAeJ9PMfB51beviHfdjBxeJ8OTL cCqEUlbAjj63QdA5JjzlMGK1y//bFm+KbwbXe1YHBTP8zD8TQcx/OYdplXNcAIwJWmst q1saAXiaDi4Kp1ED/Hg7jJFe8WvbPAoDcwBVgRIkYqvJqdobdsuosb1auUYMQDYtNT2M 9hr1vLgegeDuldtx6XFT8quMoTTjuo3QvVOdKzbyXMaZMBtmUIAWcmPbpbzm93mW9wM4 EMapzGWtJ6MAH8Ksudxo/PxG3s8UwDxb7fPkeZIcR4VPNfoqHBnMejZZyRdDW/9n2Zsl pBEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789990556; x=1790595356; h=content-transfer-encoding:content-type: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:content-type; bh=ThUHx8jzT/Saq/lfPNNpnxBYhWVh0VLHw76lSWYKo/g=; b=qgnlgOCbNZJl5o6EnkxVNb453cfd9F39PaTzb7xQc8n0oHTG38SCxAMrY0v7E6Vi4Q k6gXFnxJzJQlRUrrcOBQZFV0J2CzWxpQQQvjYOuSkKZ84QBI7ZKWCOIgWkia7DTlBBV1 eAoVnq3DZvAqWU+wBOcPEomwRFAIFlK0g3v2kdo2q6TEgu6cmh32m0UDcJJ0t7dO4jfJ 36URoOaP1u01bPsSmeOzuEcXPBeAqPEZiaIHhl7TWcO+NMPZGfwZOu4SSrdohK7fGcTM OqWaqU3VhpadrS4Zd2QBolY5YHJqpb+PSq2/s/gNXsVNmwqzazxuysxn+fFUEKdSVxGA 3C4g== X-Forwarded-Encrypted: i=1; AKwUvBzN7EsDIjZdfww8CJnFtC+fS73O0tZo+mBNoAY4hvV1dnqRjsXTs+WzUBJeRnPTdk+Xxhc/iWs4EC0=@lists.xenproject.org X-Gm-Message-State: AFuF++kszqqDpM9sYSnRZUa7PFYVc8spAUIhpWSRAILqGle4ITmdR4Px GfafAYl3OcVzOxmqEdOo1ZYe1hEHSlq/M8Xqa0FV9RgnxvChLiCIEilKV6yGv7aRWw== X-Gm-Gg: AYBFou0OKSv33+BtiVmyl9VwtKKcD7MmgIikHHwUxwRVfZhgPOgMV0zNMHGcwhdWDpL wwdxpXpvIJqsmoS7uWfErrd/TDgMwkG0RX6hYJ0Q56wJnTw4SyDzZELe2mYDc6KjVUm2tzaDqFS cFc7mT8xl/CWrnZ5BG1EAIeYm/LEeE5Qa4JURJKkDY2w2AwMn6dGQH/Nv+Mv64QYRi2J4kXVsyE JUucRlcQr4yiRzmRDoh8j6bSiU1YgQ3lSbYWGABtN5Iif/yOktC91wXI0/fgS/8ZeqTmFxGXwJT KEuTC/QPiFYjBhY2Gb8+JxeOq0XMU4mcWgeRy50IC0UTk9UVCBmJcW+xK9Er/neDV4Y0pvQlYeD JRZkRwu/UOuN8Fcv9MOEh4NE4pAQ9FcnGO4Sq3sMzvqjg+xcOI4Fz71e1HxHhzyR4j1JyaWBDQr 5C8u+ixYUhVOq/hoYkhGALc+V1HdVDrv8RSGYbYPgS9rv0u4Ahd5RqioVskYtFZnBcgicsMtm9q zofCVogecg4HLhAKFM3oajHzh1QPBzM1k38MsiHVgMbXdCGbX4aRrEFs+6dunteREg235uJ X-Received: by 2002:a05:600c:3556:b0:49c:ffab:551f with SMTP id 5b1f17b1804b1-49fc5737c38mr152592965e9.22.1789990555779; Mon, 21 Sep 2026 04:35:55 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 13:36:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 37/39] xen/riscv: map IMSIC interrupt file for vCPUs To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-ef75cf/1789990556-344CBAE4-2D68E887/10/73395122804 X-purgate-type: spam X-purgate-size: 3669 On 27.08.2026 17:21, Oleksii Kurochko wrote: > A guest running in VS-mode expects its own IMSIC S-file at offset 0 of its > guest-physical IMSIC block. Physically, the guest-file (G-file) assigned to > this vCPU lives at a hart-relative offset given by guest_file_id (assigned > via the vGEIN allocator). Therefore, imsic_map_guest_file() uses stage-2 > translation to redirect the guest's fixed per-vCPU GPA page (offset 0) to > the specific physical guest-file page. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich perhaps with ... > @@ -537,9 +538,72 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v) > read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > } > > +/* > + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU > + * into the domain's stage-2 guest-physical address space. > + * > + * In the machine's physical address space (SPA), each hart's IMSIC > + * supervisor-level file (S-file) is located at offset 0 of its address block, > + * followed contiguously by GEILEN guest files at offsets of 1, 2, ..., N pages. > + * > + * Because a guest OS running in VS-mode expects its own supervisor-level > + * interrupt file to be at offset 0 of its guest-physical IMSIC block, the > + * hypervisor must use stage-2 address translation to map the vCPU's > + * guest-physical "supervisor" page (GPA offset 0) to the specific > + * physical guest file page (SPA offset guest_file_id) on the physical hart. > + * > + * A vCPU runs on the pCPU the scheduler picked for it (v->processor), and > + * the guest file it is given (guest_file_id, from the vGEIN allocator) > + * belongs to that very pCPU's IMSIC. A guest_file_id of 0 indicates that no > + * hardware guest file is selected (matching the architectural behavior where > + * vGEIN = 0 in the hstatus CSR selects no guest external interrupt source), > + * requiring the VS-file to be emulated in software. > + * > + * Consequently the mapping installed here is only valid as long as the vCPU > + * stays on that pCPU. When it migrates, a VS-file is acquired on the new > + * pCPU and mapped at the very same GFN, so the stale mapping needs no > + * explicit tear-down: it is simply replaced. > + * > + * The base guest-physical address advertised to the guest in the device > + * tree matches offset 0 of the vCPU's virtual IMSIC block. Stage-2 > + * translation ensures that guest supervisor accesses to this page are > + * transparently routed to the real hardware VS-file granted to it on > + * the pCPU it currently runs on. > + */ > int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) > { > - return -EOPNOTSUPP; > + struct domain *d = v->domain; > + unsigned int cpu = v->processor; > + paddr_t gaddr = GUEST_IMSIC_S_BASE + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id); > + paddr_t paddr, guest_offset; > + int res; > + > + /* Nothing to map in the case of sw interrupt file. */ > + if ( !vsfile_id ) > + return 0; > + > + guest_offset = vsfile_id * IMSIC_MMIO_PAGE_SZ; > + > + paddr = imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset + > + guest_offset; > + > +#ifdef IMSIC_DEBUG > + printk(XENLOG_DEBUG > + "%s: %pv: ga(%#"PRIpaddr") -> pa(%#"PRIpaddr"), cpu(%u), " > + "guest_file_id(%u) base_addr(%#"PRIpaddr") offset(%#lx)\n", > + __func__, v, gaddr, paddr, cpu, vsfile_id, > + imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset); ... this also converted to dprintk(), or at least using XENLOG_G_DEBUG. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 11:39:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 11:39:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427366.1650072 (Exim 4.92) (envelope-from ) id 1x8cNC-0007Bs-9Q; Mon, 21 Sep 2026 11:39:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427366.1650072; Mon, 21 Sep 2026 11:39:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8cNC-0007Bl-6P; Mon, 21 Sep 2026 11:39:50 +0000 Received: by outflank-mailman (input) for mailman id 1427366; Mon, 21 Sep 2026 11:39:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8cNA-0007Bf-VX for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:39:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8cNA-004JDL-2s for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:39:48 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1177f-2eae-0a2a0a5409dd-0a2a4501d81a-20 for ; Mon, 21 Sep 2026 13:39:47 +0200 Received: from [52.101.52.51] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab11782-5984-0a2a45010019-34653433c42b-3 for ; Mon, 21 Sep 2026 13:39:47 +0200 Received: from MN0P223CA0010.NAMP223.PROD.OUTLOOK.COM (2603:10b6:208:52b::16) by DM4PR12MB6256.namprd12.prod.outlook.com (2603:10b6:8:a3::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.14; Mon, 21 Sep 2026 11:39:42 +0000 Received: from BN3PEPF0000B076.namprd04.prod.outlook.com (2603:10b6:208:52b:cafe::98) by MN0P223CA0010.outlook.office365.com (2603:10b6:208:52b::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.15 via Frontend Transport; Mon, 21 Sep 2026 11:39:42 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF0000B076.mail.protection.outlook.com (10.167.243.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Mon, 21 Sep 2026 11:39:42 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 21 Sep 2026 06:39:42 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Mon, 21 Sep 2026 06:39:40 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KzaZvVI34vZB7J8aFNL5J2ogwBYt9MYSaOFgozyveQN6Nq5Y7bB5KTEwWQmkvzdb4VoJjRysOXGQm9X5qVfhf3k4WZWPe/LEFiXkxCF/Bi6TFSIuPSwzuHTa/o9NKrEPjUdq0X35MdeBgFkP0Wp6xzfAg6W0PqqZyayv238XoxBhXhpOXvL/FJT+BjRzac3ju9G/9SU5J0l/LisPlXi9ah0cqPNosr214QvCl0uKiCT1g2rRc0wlV/fvuxy85fLdNA84LifVkJsOZflg8Vg6ue4tLH0/Yaq2hq3NZG3R5UqS+nKmuYHfZFOoj28bz2Ychutc8jX/rIEJCVPm9hTTYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KzQ7LLWlZC3JrWkqZmzW7lahXvFV5zhCK8GWBe6fcVA=; b=Wvnina/dgpnJATiiw/9fltoBxO9+mRe4m6ym/rJ9ifQJzeivsFmjk1BpduynbseGuOl0uyKFG/r0GuTegyW40QwjCLUNwerQVOp83CKvuzNXE+xQQfihj2XOWJbalk7vff5nDKh70o2C5rZCbdHKZOdDTplQGueG/7Ig9vuPXQxrVPgHYUoFPYXTgmdPRGJUkvmPOAGTSKPelgmkWqNxfvH2C1LIXFJbZcKzuiyeTrIpIktWJxX9ttJNgf+kZbhpn2efN3vjZ4JlRoOJbvr3YDZkHbHcwVkBU5elM47TYDt07SUBJdx6N061JNhT4ZFnxge5Jx6SpBMEW0xZHLOJdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KzQ7LLWlZC3JrWkqZmzW7lahXvFV5zhCK8GWBe6fcVA=; b=4EnscFP5OsE7KTG8GJPePxGZ5p3ikVr4VMWbucK5uhM3fcyGyvVqgQ08La5B/Ir3vvAk9fuhK0WOw5FEYy2P4qKx43F/X2hweGT22WpJ7EO6r3yCOuWo2m7fgQyo2MfKgM1Xp5iLtyKdMzZ7FGvKbEx1B9+As9J/z+uttMaXpCg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: Date: Mon, 21 Sep 2026 13:39:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/6] Arm: split xen-syms linking rule To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B076:EE_|DM4PR12MB6256:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d12ac6d-3c00-4a40-85fc-08df17d5072e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|1800799024|82310400026|23010399003|10067099003|4143699003|11063799006|56012099006|6133799003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: GD+M10gZfjFQSwbkT6xhuA0HsVJjdoOrWK91WZZsxewBcLVMiU6JGj3SQlo9UO4EpHmGFv0Lz9ogOh44n3TZDBULYDfkIgCkBr6EbKVWvLibT4LKw1jdDpkLQq7Hw3rn2Z01TOu3E344Vy4A61ZsmYPgnQ7kUSi8ILsCDl/p+uYDf+NRLSkdUN23DVwB5JvLgZxsm0v6wo1kTylKPxuKQQqVhHL7QayaWjEzkRl7OjlAJNE5ahq2jKmS1KsJ+FL4M7Gyg1BdKCWkIKweS0ueXlOCx9CRl4m/4FvdQDWRo9trCem+z1n6ijJ6VYPV6Nk8LrG7d3VdOChH00EYp3bgMlLnWs0Rxqtx7suvfmgaasJ2e6kAxM93JrbOsAmyEe+O6GexKsGtpx2/QtXQFH6AVZAtfBQz13WrK78qReCPRgrSOhGmDNTewgoE21dJ2SBbe/LazN99VaB6MhR1WbtGx3Yy7G/mUzE4lnEB3h5dAQ5e7sjiBRiR6ZHCl/kPgMty7e+gSIzdaR7e6hKTX47lJWfw+gs2Zup7S5OYvIxNkn/32tVyJ1+oWUz1CVSoaAhnBNyg6AZFLXE8KlAfb01sdj+doQSPnJsw3TIPoAQVFjwqwZFzbMJerk1i31HSvk1+FIPabluupdXRQDEqRgHHtR/1aZek8NABvR9JPYZojB9DOKJUxR1LxjP4m89Z++UrPF/2n0eZdi+x6IZYozaFIg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(1800799024)(82310400026)(23010399003)(10067099003)(4143699003)(11063799006)(56012099006)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Rl3Zvqgc9rTJB9Qozco2U7GsDJCLSyUsyHbF0Su5Rc7oSd0thhmNjTz9yQ2chnDrA9Va98cQWCij0yAoo6Nt24pEAcsmGVyLJ90hMeuu7qRHPtD73suRiE4SJXukOA2AEtRRhMaLVzAccr74bQh0g3gm6VYiSI7/wv/wEJnWw0VMCKGL+HZRTpjpOJPm4W6mqSzzBntXMSK90JhRT20ddbDsp5WJaTx514xZFGExC6UB7RfDfGlqEuLosky8P7021hdF2iIJ2qD/YwVfGNRWKgEXTF4p2qTeSmaT1t8HvKsnwpCaH4xa8eJpeplxR26+XlQ0LcqLHZ4NHqiQUE60X1E0L/ppz32M7kd0YQt68MaemyM5Y1De27caSKjeYeaWgQwFe8MowjsO180wF++jwisFCpveADbEulduopW9SqK1XsntCRDljL2J/Ackiqkh X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 11:39:42.5431 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2d12ac6d-3c00-4a40-85fc-08df17d5072e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B076.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6256 X-purgate-ID: tlsNG-d62444/1789990787-BF262757-6F3B2E42/0/0 X-purgate-type: clean X-purgate-size: 1173 On 08-Sep-26 14:28, Jan Beulich wrote: > Doing so, besides (hopefully) adding clarity (not the least by way of > [re-]using pattern rules where possible), also avoids explicit recursive > $(MAKE) invocations. > > By re-using the generic rules introduced when the respective x86 rule was > split, > - the .map file now isn't created after the final binary anymore, > - --strip-debug is passed to $(LD) during early linking passes (for > consistency the option is also explicitly added to the optional linking > pass rule), > - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are > now properly respected. > Orphan section checking, otoh, is getting suppressed for now, until the > about a dozen warnings which would result have been taken care of. > > While the 4th linking step continues to be avoided when possible, a > redundant invocation of $(NM) and tools/symbols (plus the assembling of > the resulting .S file) is hopefully deemed acceptable. > > Signed-off-by: Jan Beulich > Reviewed-by: Anthony PERARD Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 21 11:46:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 11:46:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427375.1650081 (Exim 4.92) (envelope-from ) id 1x8cTb-0000K2-UL; Mon, 21 Sep 2026 11:46:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427375.1650081; Mon, 21 Sep 2026 11:46:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8cTb-0000Jv-Qw; Mon, 21 Sep 2026 11:46:27 +0000 Received: by outflank-mailman (input) for mailman id 1427375; Mon, 21 Sep 2026 11:46:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8cTa-0000Jp-3Q for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 11:46:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8cTY-00DcHU-NA for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:46:24 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1190b-bab6-0a2a0a5309dd-0a2a4508befe-48 for ; Mon, 21 Sep 2026 13:46:24 +0200 Received: from [162.55.131.47] (helo=support.bugseng.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1190f-f659-0a2a45080019-a237832f9d4c-3 for ; Mon, 21 Sep 2026 13:46:23 +0200 Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id EAF3C4EE0059; Mon, 21 Sep 2026 13:46:22 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; none Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1789991183; b=MHkuIqLM/wFBF/0znD+m3Lev8QkrMthFyniw1h5+LqPumXO2Z69nXqKZwI74SsqTh2lU YLLy4sob9Rr0dgAdfIx71g8KBe88mL9AwZwhL936H2t0k6v3czFSlv11UmiA1vUbPOkio KmnZVB9nZrI5Lb0t7Uy+sdjXfNN1WEHgwN0mX7j8VebtsUt9KlW4pNFnrEfz2rcVgPCFu PxEmykvYX6dAs4JglMnBaea22lHUANDYvdCesMWcENy9g+YXFuYZOYITHsyeQ371P2i4A JVQh3RR9YSUAC5X36CyovoW5/LKubB2+ipAoJAR1WIzBJabykyOkhINAgyDRoqduuUCC/ Mb5pUkblSJxqbbpn0YdNVnv3TIh0ei1OtwINVX/Zqw+WmuBf3KuxpB4An9U9vjSHv1s7a Ae3QK6HKN3CkSDuZfBjXnn+ucTqndKJgMcjNl0F2VCmz8hZX7weVrI5UQQEDRqfBDi7kL CkrqOHgX/m5SUXAsIohRDlqNqmy3ni/YyaKGG+eD69NCLdJwYuLoazGY0HrEzg/eaWElb uoLiIH03sd/FUpBl5aFAJLkRqeljge7cJq+xfqzAtHOgNs0ydbMWOejdInc4ZXt1JIhtK ycsU/59t2J8l14FdwRaja+an5JL5Bsioucl0liXwWkZMkXTZx/zkmVd1SsjNoP4= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1789991183; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=daGJpK86flBg+IdzsKG9T9TtHsVol6t4gicRS7tin1Q=; b=KiFhWHLQEDkFPL+5IitwXaDTtvB+oGeGu9qXfF4ZoINh8FOqCDQGVVdKB97/id01DXvU 9NjAfKK0xr9LfvNt+rubCkN4BRP5p2C5hZYuaiXLjIny2FLZoB1X0v6x/5k/8dkA2r9z2 TtShdUsnelzoj50lTB+hws2T0EYkl+iY8WqdcIToFLxY7GLxezvLkucThWyoEzaPovuhA nQS4iMniKLIm1D0BsDHeyV+PmA/Nbd4Z0DIUF7dHeAYMErb7LFHmNKtaoTJIyNhhdnQ2f bvYbXJr5DNT1DEoZnOue7ONV3WtwNFa5hvkASsiEpRM1waDYsGT5lyTT8K/0Zk2rvb02v xChdh0NyPquoXoWu8G0Z2N0ED+aqxcHI0tFpDm4dB45yfnzohdsvvh4VVCRzfiM+JzC4X jadtj09WzPiGOdJCgJdx1Ogq5OAINw/6eAIgEWzzRMUS89SvTipKyK94e5pAMHYWQ90hZ tUZqZDM8W8/g0xkWXIQ/gSDtVr+CE9y+kKPLGMSaJqCXrOjkGvOSTe6ZsxvXpWU0SNrDC zhr2kjCKk7ZokS8iqWtBabfcV2tJ6pf7GqDFpIzO5jlQNbdtHavtWhRvFi621N53WXA2Y wnfNhkHDik44AWiwZDIfTmdoDyomcTSwUQ2+I11Na4IOxQtPvR8a2zfgzEb23Bk= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Mon, 21 Sep 2026 13:46:22 +0200 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH 08/14] Arm/guestcopy: deviate copy_guest() uses just like their x86 counterparts In-Reply-To: References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1789991183-D7B5987B-C22E9037/0/0 X-purgate-type: clean X-purgate-size: 2910 On 2026-09-02 08:33, Jan Beulich wrote: > Like x86/HVM's __hvm_copy(), Arm's copy_guest() is used for both > to-guest > and from-guest copying. Naturally in the latter case the hypervisor > buffer > needs writing to, hence the function parameter cannot be > pointer-to-const. > > No functional change intended. > > Signed-off-by: Jan Beulich Reviewed-by: Nicola Vetrini See comment below, but I can do as a follow-up if you'd like. > --- > Of course for both the pre-existing x86 deviation and the new Arm one > it > might be more robust if the deviation was also limited to the > respective > source file. Can this be expressed together with the needed regex? Yes, e.g. -config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(^xen/arch/arm/...$)&&text(^.*copy_guest.*COPY_to_guest doesn't modify.*$)))"} not compile-tested, so YMMV. > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -433,6 +433,12 @@ Fixing this violation would require to i > > -config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"} > -doc_end > > +-doc_begin="Function copy_guest() in xen/arch/arm/guestcopy.c is a > double-use > +function, where the parameter needs to not be const because it can be > set for > +write or not" > +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*copy_guest.*COPY_to_guest > doesn't modify.*$)))"} > +-doc_end > + > -doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a > double-use > function, where the parameter needs to not be const because it can be > set for > write or not" > --- a/xen/arch/arm/guestcopy.c > +++ b/xen/arch/arm/guestcopy.c > @@ -109,14 +109,16 @@ static unsigned long copy_guest(void *bu > > unsigned long raw_copy_to_guest(void *to, const void *from, unsigned > int len) > { > - return copy_guest((void *)from, (vaddr_t)to, len, > - GVA_INFO(current), COPY_to_guest | COPY_linear); > + return copy_guest((void *)from, /* COPY_to_guest doesn't modify */ > + (vaddr_t)to, len, GVA_INFO(current), > + COPY_to_guest | COPY_linear); > } > > unsigned long raw_copy_to_guest_flush_dcache(void *to, const void > *from, > unsigned int len) > { > - return copy_guest((void *)from, (vaddr_t)to, len, > GVA_INFO(current), > + return copy_guest((void *)from, /* COPY_to_guest doesn't modify */ > + (vaddr_t)to, len, GVA_INFO(current), > COPY_to_guest | COPY_flush_dcache | > COPY_linear); > } -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:08:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:08:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427393.1650090 (Exim 4.92) (envelope-from ) id 1x8coU-0003VF-M7; Mon, 21 Sep 2026 12:08:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427393.1650090; Mon, 21 Sep 2026 12:08:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8coU-0003V8-JS; Mon, 21 Sep 2026 12:08:02 +0000 Received: by outflank-mailman (input) for mailman id 1427393; Mon, 21 Sep 2026 12:08:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8coT-0003V2-Dc for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:08:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8coS-00H2q9-6i for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:08:00 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab11e12-8faa-0a2a0a5109dd-0a2a45098916-46 for ; Mon, 21 Sep 2026 14:07:59 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab11e1f-be1a-0a2a45090019-b9ff1c238c49-3 for ; Mon, 21 Sep 2026 14:07:59 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c3dda3d100072c4.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 21 Sep 2026 12:07:57 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id D352D81038; Mon, 21 Sep 2026 14:07:56 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=O65EXIF7HisMV2bCmSIZewpYY3sknTxvXnrdk1UNrrc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=lQCRPvv1tCZkibBd0s0kgAJTFV0rMpiSMnUhmM5e8fupxqHykc7ai8NtFHJpa1pqzQfpzc6pt LzfYbYVtZGDbZTwq5K6RPNR7ZdHEUTLLByyvVpDSLBP5vbPgN0Uy4CJ12uFch6ZnrqOIjO+scSl CXqrrc8cWuecVNfPXsogbKrXaYuJAR2XlkolutNdIXhKXbRN1Q0p/4t5rrBeq43qdN2cIhM/bEj 5uEClGleaVkBTWhwun2osqlfHHZq8IgEn8DSa2S3eMWcURAJhS2J6kT5XTtuiwaNtkRBB87k3GD x9ravqfo10hnJAiV+pb8urc4sfcfJxelFHdnMH0TGd/A== X-Zone-Loop: d39fb3a66c6bf88412421e552e8b24a99b571269b2b6 x-campaign-type: default x-transaction-id: 92310eea-b395-422a-9ee1-91af3eb16236 x-swg-uid: 01-7d4da256-67c7-4dea-b167-f878d7e8dc3d X-Mailer: Sweego Message-ID: <1789992477.8631fc262581453bbf619ec5b2062170.1a0c3dda3d100072c4@vates.tech> x-swg-bid: 1789992477.8631fc262581453bbf619ec5b2062170.1a0c3dda3d100072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 21 Sep 2026 14:07:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] vmx: Handle TDX instruction exit reasons To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1789049962.8631fc262581453bbf619ec5b2062170.1a08bb0014d000c4f3@vates.tech> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------tTLUA3GxVoj75Je0Tsp040XN" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789992476978 X-purgate-ID: tlsNG-bad1c0/1789992479-3A0C5034-1F831EA1/0/0 X-purgate-type: clean X-purgate-size: 6364 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------tTLUA3GxVoj75Je0Tsp040XN Content-Type: multipart/mixed; boundary="------------hnikHOMjpaNb9fu0hZyBU03P"; protected-headers="v1"; hp="clear" Message-ID: <3cfd39cf-a235-41ce-bae8-7898e3265dcf@vates.tech> Date: Mon, 21 Sep 2026 14:07:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] vmx: Handle TDX instruction exit reasons To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1789049962.8631fc262581453bbf619ec5b2062170.1a08bb0014d000c4f3@vates.tech> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: --------------hnikHOMjpaNb9fu0hZyBU03P Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMjEvMDkvMjAyNiDDoCAxMzowNywgSmFuIEJldWxpY2ggYSDDqWNyaXTCoDoNCj4gT24g MTAuMDkuMjAyNiAxNjoxNywgVGVkZHkgQXN0aWUgd3JvdGU6DQo+PiBPbiBoYXJkd2FyZSB0 aGF0IHN1cHBvcnRzIFREWCwgZ3Vlc3RzIGNhbiBjYXVzZSBWTUVYSVQgcmVsYXRlZCB0bw0K Pj4gVERYIGluc3RydWN0aW9ucyAoU0VBTUNBTEwgYW5kIFREQ0FMTCkgcmVnYXJkbGVzcyBv ZiBWTUNTIGNvbmZpZ3VyYXRpb24uDQo+IA0KPiBDYW4gdGhleT8gU0VBTUNBTEwgcHNldWRv Y29kZSBoYXMNCj4gDQo+IEVMU0lGIElBMzJfU0VBTVJSX01BU0suVkFMSUQgPSAwIG9yIGV2 ZW50cyBibG9ja2VkIGJ5IE1PViBTUw0KPiBUSEVOICNHUCgwKTsNCj4gRUxTSUYgU0VBTSBp cyBnbG9iYWxseSBkaXNhYmxlZA0KPiBUSEVOIFZNRmFpbEludmFsaWQ7DQo+IA0KDQpFYXJs aWVyIGluIHRoZSBpZiBjaGFpbiwgdGhlcmUgaXMNCg0KRUxTSUYgaW4gVk1YIG5vbi1yb290 IG9wZXJhdGlvbg0KVEhFTiBWTSBleGl0Ow0KDQpXaGVuIHJ1bm5pbmcgaW5zaWRlIHRoZSBn dWVzdCwgd2UncmUgZWZmZWN0aXZlbHkgaW4gVk1YIG5vbi1yb290IG1vZGUsIA0Kd2hpY2gg d291bGQgdHJpZ2dlciB0aGUgVk1FWElULg0KDQpUaGlzIGlzc3VlIGlzIGRvY3VtZW50ZWQg aW4gYSBkZWRpY2F0ZWQgSW50ZWwgYWR2aXNvcnkgWzFdICh0aGVyZSBpcyANCmFsc28gbWlj cm9jb2RlIGJ1ZyBDVkUtMjAyNC0yMjM3NCB3aGljaCBtYWtlcyBpdCB0cmlnZ2VyYWJsZSBm cm9tIGd1ZXN0IA0KdXNlcmxhbmQpLg0KDQpbMV0gDQpodHRwczovL3d3dy5pbnRlbC5jb20v Y29udGVudC9kYW0vd3d3L3B1YmxpYy91cy9lbi9zZWN1cml0eS1hZHZpc29yeS9kb2N1bWVu dHMvaW50ZWxfdGR4X2pvaW50X3NlY3VyaXR5X3Jldmlld193aXRoX21pY3Jvc29mdC5wZGYg DQooVnVsbmVyYWJpbGl0eSA2KQ0KDQo+IEZvciBURENBTEwgSSBzZWUNCj4gDQo+IElGIG5v dCBpbiBTRUFNIG5vbi1yb290IG9wZXJhdGlvbiBhbmQgbm90IGluIFZNWCBub24tcm9vdCBv cGVyYXRpb24NCj4gVEhFTiAjVUQ7DQo+IA0KPiB3aGljaCBtYXkgaW5kZWVkIG5vdCBiZSBz dWZmaWNpZW50LCBidXQgdGhlIFNFQU1DQUxMIGNvbmRpdGlvbnMgc2hvdWxkbid0DQo+IGJl IG1ldCB1bmRlciBwcmVzZW50IFhlbj8NCj4gDQoNClREQ0FMTCBwcm9iYWJseSBkb24ndCBu ZWVkIGl0LCBidXQgSSBkb24ndCB0aGluayB0aGlzIGlzIHdyb25nIHRvIHRyZWF0IA0KaXQg c2ltaWxhcmx5IChsaWtlIEtWTSBkb2VzIFsyXSkuDQoNCj4gSmFuDQoNClsyXSBodHRwczov L2xvcmUua2VybmVsLm9yZy9hbGwvMjAyNTEwMTYxODIxNDguNjkwODUtMi1zZWFuamNAZ29v Z2xlLmNvbS8NCg== --------------hnikHOMjpaNb9fu0hZyBU03P-- --------------tTLUA3GxVoj75Je0Tsp040XN Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqxHhwFAwAAAAAACgkQZg+p0QLLz9Bs 2Qv9G89HFbMUeqjbIsnl+YvyYIfVbx5nReqSaEx9+MxedLu4I3/0ruYJxJn38NxRxZ0kPn9BxQzN OOWvYfLPYk7NB7BJBXGK3qm7p2/CEDB7QuEEugp7am9C4FqAYBhhap2FHoEK5y0au+LToYKFQvOU bpNaWEepAlVkEU1/DfNaH8Jmt3pkcP+j1BfCte+MHkJa1Jd/BsiWQylnoivuIC1SzS5FFSDaGCiU +9VJlOIR9piE7ovWLV9Y4vsSr5gDaxDT/Vfh5nY6xm8ThaeqSTZ2B8f3485MWr0s5p4A8n5ly2CI rgglila4glNHjhATGNBKQkzKitL+T4Q3Jcq8LWluv9iAyNZ23RmwOq9C4ATCJvAd+176ZktF5+8C qx70yJNk9JQaJLsBpwgS/k0magshaCZ04Jkg5Fie5ddaERxwnVWM9yRwA+MGG9+x6aVG6ruodBpZ GN26yeeH7nTw8dmxR3FcQx3WrhfkwB7hCmyhr9L8DOqL3JRitsiTk1G5uxeL =i3Hc -----END PGP SIGNATURE----- --------------tTLUA3GxVoj75Je0Tsp040XN-- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:12:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:12:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427402.1650099 (Exim 4.92) (envelope-from ) id 1x8cso-00056A-5Z; Mon, 21 Sep 2026 12:12:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427402.1650099; Mon, 21 Sep 2026 12:12:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8cso-000563-2Z; Mon, 21 Sep 2026 12:12:30 +0000 Received: by outflank-mailman (input) for mailman id 1427402; Mon, 21 Sep 2026 12:12:29 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8csn-00055e-0T for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:12:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8csm-00CN3C-DY for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:12:28 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab11f1e-bab6-0a2a0a5309dd-0a2a450bc24c-22 for ; Mon, 21 Sep 2026 14:12:24 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab11f28-b7e8-0a2a450b0019-4a7de18d83c3-3 for ; Mon, 21 Sep 2026 14:12:24 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b965f447cso24210555e9.3 for ; Mon, 21 Sep 2026 05:12:24 -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-49fcd10d21asm278602195e9.12.2026.09.21.05.12.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 05:12:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789992744; x=1790597544; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=1icWTVR4aykELK2fSXaTK/2jheqnZdDIm5jSa+FsCB4=; b=ekR9soY4+xWfP4y/qt3kCZf4SeYOGrLIdPC4i5xao6wUz8gLT4qytMBOPMophkXTyX 0BAbEX50OfxZ4AAehXO+7nF8neB7PR9fSkAk9Z3Ej+qyIOrz/oxmlhmZFldORDyhSeWq nb+uU7X/63l/qmnZ5+63JUEwS60aue6+46HsdHDHUW0mB4d3gc4nMl/vtMdEes+H13Gf Avo64GuI8BsiQVTxsa45llPAlNkz2owA6uqQUGYSw2VEbN8M+sGQatTPrk3aXw6bE7qi +24ahR0f51xNl/n6Xbk2V5FAmmX2aD6mOZlr4pBse1QLcJpJ8cs1If7550FBoLp8Cvxt QyuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789992744; x=1790597544; h=content-transfer-encoding:content-type: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:content-type; bh=1icWTVR4aykELK2fSXaTK/2jheqnZdDIm5jSa+FsCB4=; b=HFB11JwySPdgYwPY0/Z9K1gFI5NdfZe+t5uQ4A99SFhskO2wUF+YJHOBmodHOjHi3C foIonvln8yvzA7nb32UeRDr6C602nAAxixUAuz8lQx2P1pAkbcm3a3AQjNz2ySMadmRP RpVQ4NtCURDwJ4hutxhSXvbMRIYSozIRJY/algxsLnBjE8/NSlRQxxrPrnc3liihOHim B2oPU4vltMFv3e+7MnzX28+BlMe8VN96BH+NT8Cjh5j1MUV8R4fY3aohdY7j/J2zHUzX fWqDMv3CSUhEPB0/ALECap2OhRaYbQsGk9Xa1Fbkhmc5qXgHtp6eTGJOYxpurbEqtl+z Q54Q== X-Forwarded-Encrypted: i=1; AKwUvByfTp0zhIV+rM4seQuX4itmy68b8OFhekfF/ZGjq1IxvVgigub7G+ua1J8eS5V8CEqEuF5k66yzrTg=@lists.xenproject.org X-Gm-Message-State: AFuF++nOfED5EIkG65t3gEZcgr38nSMJaSOOycesq259DYy3pmNtVhPP pjutKa4dD2CW9V3bbbIaf6QlLoMTkqRQrKNj1XssEBFIxIPYAW8SbgO0DfnKm1Acbw== X-Gm-Gg: AYBFou2qzhtFa02mWfk71U4o6CiW2r5mHZsCiGk94h7/vmexOT+vlOQGcBnjz7dQ1ng 3smTLPdJTPh5OWDZPQxmlCBwX4EL5E6RZpVC5TaxwHz9xBPnBO5jg5zsnQH/pVJyjy9iGX/TCAu bqheA4cX++YrJrLaG1jaMtUZCHtXOIAvLJvOEne/885Zbbhbg6We2RtReV91TM+Xq7STS3wp4wQ z3zQ01IujyjJ4Y1deHNl9PbX++H6+2UrDzIN6KF9B3hdZddqX69CHZH/08z6czQfTPczhGqz2mT h3Vb0X2gFGqbfoJUhdelqmeokafXmzk4IoAZnFJiHxCPoHBtWN90SdC+XloNQeZAJAO4vPEuhEF aJo6gTu9Q6G9zkD74mPyHB//xFWLJslUTgr0AgqC6eOD3g9tS2STDSDRFcqSwtdI8XEybRmjcwt MrgMEgH0AdTW7G5g6CHNrKjamblFU2s1i7KZVBuuWyfa93mbQwDHwXuP4ZFyafNeiLXUFktpvL7 MWFQYo2Wax8TBFuG+rUoTIknx737/aq17edlXPg0tXSLHxD/jctp1fLKxZ7QQ== X-Received: by 2002:a05:600c:1d25:b0:49f:d753:3de9 with SMTP id 5b1f17b1804b1-49fd7533df5mr9117195e9.33.1789992743901; Mon, 21 Sep 2026 05:12:23 -0700 (PDT) Message-ID: <8dbc4ba6-bf92-4e9f-b4b6-7286d5a96443@suse.com> Date: Mon, 21 Sep 2026 14:12:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-42698a/1789992744-1A2C49EA-84EE93AE/0/0 X-purgate-type: clean X-purgate-size: 6208 On 27.08.2026 17:21, Oleksii Kurochko wrote: > continue_new_vcpu() is the arch hook invoked the first time a freshly > created vCPU is scheduled. Implement both cases it has to cover: > - for the idle vCPU, switch to its own stack and jump to idle_loop(); > - for a guest vCPU, restore hstatus and enter the guest through the new > return_to_new_vcpu() path in entry.S, which loads sepc, passes the > hart id in a0 and the DTB address in a1 as expected by the RISC-V > boot protocol, sets sstatus.SPP and executes sret. Is this a requirement for all CPUs, or just for the boot one? (I can't quite see why secondary processors would need passing a DTB address.) > Interrupts have to stay disabled across the restore. The trap entry > logic implicitly clears hstatus.SPV, so an interrupt taken between the > write of hstatus and sret would make sret return to HS-mode instead of > VS-mode, and restoring SPV afterwards is non-trivial. Instead interrupts > are simply kept off and sstatus.SPIE is set, so that SIE is restored from > SPIE once sret has been executed. As written this reads as if the guest would be responsible for doing this. Isn't it rather SRET itself which does this? > Also, it follows what hardware will do > with real CPU which is also started with interrupts disabled. Further up, aiui, you talk about the host's interrupt state. How vCPU-s are started, however, is virtual interrupt state. Mixing both isn't very helpful. > Introduce get_cpu_info() and reset_stack_and_jump() in asm/current.h, > needed by the above. get_cpu_info() is a macro rather than a static > inline because asm/current.h is pulled in by before > this_cpu() is defined and before completes struct vcpu. This is odd, given the similarity to Arm. They get away without using "current", and hence without using this_cpu(). > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -8,10 +8,13 @@ > #include > #include > > +#include > +#include > #include > #include > #include > #include > +#include > #include > #include > #include What makes these additions necessary here? > @@ -140,9 +143,43 @@ static void vcpu_csr_init(struct vcpu *v) > v->arch.hie = MIP_SGEIP; > } > > +static void schedule_tail(struct vcpu *prev); > +static void noreturn idle_loop(void); > +void noreturn return_to_new_vcpu(void); For this last one: asmlinkage? > static void continue_new_vcpu(struct vcpu *prev) > { > - BUG_ON("unimplemented\n"); > + schedule_tail(prev); > + > + if ( is_idle_vcpu(current) ) > + reset_stack_and_jump(idle_loop); > + else This is the kind of "else" which I consider particularly confusing: It suggests that the if() body can actually be exited at the bottom, when (by the name "reset_stack_and_jump") it hopefully cannot. > + { > + /* > + * During a context switch to a new vCPU, interrupts must be disabled > + * to guarantee that the vCPU's CSR state can be safely restored into > + * the hart without being clobbered by an interrupt trap. > + * > + * For example, when return_to_new_vcpu() finishes, it executes sret. > + * At that point, the hart checks hstatus.SPV=1 and sstatus.SPP=1 in > + * order to return from HS-mode into VS-mode. If an interrupt were to > + * arrive before sret, the trap entry logic would implicitly clear > + * hstatus.SPV to 0. Correctly restoring it afterwards is non-trivial, > + * and if left as 0, sret would incorrectly return to HS-mode instead > + * of VS-mode. > + * > + * To avoid this, interrupts are kept disabled during the restore. > + * Additionally, setting sstatus.SPIE=1 ensures that after sret is > + * executed (as sstatus.SIE will be loaded from SPIE), HS-mode will > + * continue to receive interrupts normally. > + */ > + local_irq_disable(); > + csr_set(CSR_SSTATUS, SSTATUS_SPIE); > + > + csr_write(CSR_HSTATUS, vcpu_guest_cpu_user_regs(current)->hstatus); > + > + reset_stack_and_jump(return_to_new_vcpu); What are the criteria by which you split CSR accesses between doing some here and some in return_to_new_vcpu()? In particular you set sstatus.SPIE here but sstatus.SPP there, when both could - I think - be done with a single CSR access. > --- a/xen/arch/riscv/entry.S > +++ b/xen/arch/riscv/entry.S > @@ -143,3 +143,26 @@ FUNC(__context_switch) > > ret > END(__context_switch) > + > +/* t0 is used as a temporary reg and is clobbered to oblivion */ > +FUNC(return_to_new_vcpu) > + /* Swap tp with sscratch */ > + csrrw tp, CSR_SSCRATCH, tp What is this about? I'm not aware of any counterpart code, yet all on its own this I can't see it being overly useful. > + /* Set vCPU registers */ > + REG_L t0, CPU_USER_REGS_SEPC(sp) > + csrw sepc, t0 > + > + /* Hartid goes to a0 */ > + REG_L a0, CPU_USER_REGS_A0(sp) > + > + /* DTB goes to a1 */ > + REG_L a1, CPU_USER_REGS_A1(sp) The fields loaded are merely .a0 and .a1 of the register struct. There's nothing here making sure (all on its own) that what is loaded is what is said by the comments. If e.g. the first comment was /* .a0 holds the hart id */ or some such to remind readers what is being loaded without giving the impression that the correct value is _established_ here, that may be better. > + /* Set guest mode to supervisor */ > + li t0, SSTATUS_SPP > + csrs CSR_SSTATUS, t0 > + > + /* Enter guest */ > + sret > +END(return_to_new_vcpu) Aiui SRET does not switch stacks. Shouldn't you therefore clear sp here? And perhaps also other GPRs, not the least ra? Exposing hypervisor register values to guests is, well, a bit of a problem. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:15:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:15:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427410.1650108 (Exim 4.92) (envelope-from ) id 1x8cw5-0005b3-Lm; Mon, 21 Sep 2026 12:15:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427410.1650108; Mon, 21 Sep 2026 12:15:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8cw5-0005aw-HS; Mon, 21 Sep 2026 12:15:53 +0000 Received: by outflank-mailman (input) for mailman id 1427410; Mon, 21 Sep 2026 12:15:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8cw4-0005aq-8P for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:15:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8cw3-002G81-LV for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:15:51 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab11ff5-e002-0a2a0a5209dd-0a2a4503cc42-10 for ; Mon, 21 Sep 2026 14:15:51 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab11ff7-fae8-0a2a45030019-4a7de14c858c-3 for ; Mon, 21 Sep 2026 14:15:51 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-484366874b0so1675841f8f.2 for ; Mon, 21 Sep 2026 05:15:51 -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 ffacd0b85a97d-48854e5a2c1sm15791661f8f.34.2026.09.21.05.15.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 05:15:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789992951; x=1790597751; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=+/dM4Ux0dkSickL/pOo7+kU1nYl1BV/rrNnYgFUfD74=; b=SYNipcO617gaChA9SYbQdZ3ApwhLet5/QxBwmnBd4CkDDitPh9db/1rI1qnuSQuoqe /Msjh6pYvS4SExakRNxTcGsNY0hu6BuVFjUH/fpo/NGXgds3FO2GH7mBYOOHJSpJIHD6 +repXHQU7jKudQ9wTtxWKEDRK0wBQlskiatdEESE7Ppft4DNDbUv+vByUYrRo3JGkei1 VSOy9nUSQHn7dqFy/Zi8GjoxMTlwNrZDTbr8P26ASrSEs55yYjuG1CnK2T/dQursIjuR xVdhq/G+p80Ob8rga/MeABjoT6SWSBXI6Q5KnsvKf5ZJCXJv57PrplAtKmMLv/H0tASL DZiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789992951; x=1790597751; h=content-transfer-encoding:content-type: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:content-type; bh=+/dM4Ux0dkSickL/pOo7+kU1nYl1BV/rrNnYgFUfD74=; b=t18suZcUY59dQTRLsjhOpFM0EpcdwxD9tfx+jab0WtvZ8DPS8FocRW1QPQ1IwV6lB0 oA+hQ9DcPNdERACMGzIUK8SGgQMM48DCv0Ko8NoZ19r9wQcs7AhJxqqLTRQsg+BH5WyR TXdSE5wRK5X5WCUyIV2ZfbW8jr7QJmY2+6H9MoxuIv2RArm2p4IwBOunCzqS3QdYUv5D Zr/2UEfVWsTJVN2UYvybknDuP40xX4t0wVCpqUP8lVL1JYaANzA2dKR8EfmqqpuEOrO3 tMw3M2LT5VAp6xetjQ0EkJ3TRLrPPkqo78zKX54ybBSIgXXHvWZCeCRj4wb0eUBya5fb 7kew== X-Gm-Message-State: AFuF++mBmM5CN9z+bBMn6xEoFj5yxuPM5QgzW6J8ZrMHwCDEz9qUgz00 DdHy0oAx0716CgfE5CeoUM1h5geroJLJ8cz6Z3jHk4FbPvYNLon1IpdYHEO9b4eogw== X-Gm-Gg: AYBFou1hDLvNAaou5h7pB2R4i0YTNCtz+zT/W5hwSiUm0bySzT7lYRRiFKDU9gW2PW8 EAYRx8ZfGZEPtuweiSeFyZ8ToStMOq8fO8k+R3PRvZPTPKm18ZlK2kEiOiY4icmDAJCB2BuFBdk 9ZW/Ypu2+RWjXGL9y8GYdwXSUuzx/yZbglfKsuC5Cc2E4fKO2kWMq3N6Yvi4ju+q3tTgo04UeSx o/bS4hz89Y/efpRQ1cd8CuDcB5syByTKoRQSYgVWrOo7Me6wAs2MP/RyjIZF/r8AeA3JOYoNevy AIqEZ0K7rRJFSLRG9LxqIRWsgF0JwPufECAfS6qrL/hz4P5QqfBsrTnVUNMe3SnbKv7X/Xkz0rN l6OYcIQ3Y7Mzq4IY20RFVHTPOrL2XsCSWrNilXEHvuvHcpyoHfYkheYiU42Ota+vwOc6GIEVME3 BwfNXszTi7gQ1T7l7IioXKeD+XvQoHrkF9u5jjJLS7QDDYzRLFxorjOTqKxZxx1y7qlNjWmtG0d TrBPJVJxfc+bHaIsyXbNePZ7CCyIiHzXtTij1znB+1AAUeenec1nb9N8MQ6dkQ= X-Received: by 2002:a5d:64c6:0:b0:487:27f6:a4d4 with SMTP id ffacd0b85a97d-48727f6a6f2mr10176191f8f.36.1789992951024; Mon, 21 Sep 2026 05:15:51 -0700 (PDT) Message-ID: <14f72d9b-56f8-49a4-9795-d8e25ae269cd@suse.com> Date: Mon, 21 Sep 2026 14:15:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/14] Arm/guestcopy: deviate copy_guest() uses just like their x86 counterparts To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@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 X-purgate-ID: tlsNG-33051d/1789992951-6E6CE4E9-7179B077/0/0 X-purgate-type: clean X-purgate-size: 1106 On 21.09.2026 13:46, Nicola Vetrini wrote: > On 2026-09-02 08:33, Jan Beulich wrote: >> Like x86/HVM's __hvm_copy(), Arm's copy_guest() is used for both >> to-guest >> and from-guest copying. Naturally in the latter case the hypervisor >> buffer >> needs writing to, hence the function parameter cannot be >> pointer-to-const. >> >> No functional change intended. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Nicola Vetrini Thanks. > See comment below, but I can do as a follow-up if you'd like. > >> --- >> Of course for both the pre-existing x86 deviation and the new Arm one >> it >> might be more robust if the deviation was also limited to the >> respective >> source file. Can this be expressed together with the needed regex? > > Yes, e.g. > > -config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(^xen/arch/arm/...$)&&text(^.*copy_guest.*COPY_to_guest > doesn't modify.*$)))"} > > not compile-tested, so YMMV. Yes, please make this a follow-up, then also covering the x86 counterpart. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:24:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:24:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427420.1650116 (Exim 4.92) (envelope-from ) id 1x8d4X-0007Mu-Ga; Mon, 21 Sep 2026 12:24:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427420.1650116; Mon, 21 Sep 2026 12:24:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8d4X-0007Mn-Di; Mon, 21 Sep 2026 12:24:37 +0000 Received: by outflank-mailman (input) for mailman id 1427420; Mon, 21 Sep 2026 12:24:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8d4V-0007Mh-RL for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:24:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8d4S-006Ypt-RR for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:24:32 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab121f1-e002-0a2a0a5209dd-0a2a4507ddc2-36 for ; Mon, 21 Sep 2026 14:24:32 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab12200-b4ea-0a2a45070019-4a7de18deb2d-3 for ; Mon, 21 Sep 2026 14:24:32 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49d1fb0cf5eso20664165e9.3 for ; Mon, 21 Sep 2026 05:24:32 -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-49fc57547easm246167125e9.3.2026.09.21.05.24.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 05:24:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789993472; x=1790598272; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=UOWzjm9V2HkBkqE5Ilftrs+3ip0tzKvIaFfS8Kt3HCk=; b=RkDxwd9ZKaAYyRyI5SI3rzd9E5D2LPdSFvD0at+AxJxHMopY+KKPN7UlAU69kaipnW JZ/vZcrnoyv6mdUovMF971YKUPNEb28aazeOBJQ3+65M334BF0G1reOYuN6Y4irrqm3E TB7+lZWFiwRMgSBgkTjEgCL+vyHU5oUE19kyym2R+nYDZ9yUqLc2nA81yxP11kgykjYp mlmP8VdkmW+CYS2mfYoQYK7JpDtsUBxxfixv+QlbYpcKpUkCaYye0H6Y94hXnyARgQBE YsHXDjT6g5Y+LkevQVLzWMs0wJUmqS50NFQvBfPT7ogxUoJj8CYS+tFwMsVMmr6DN8f2 g0sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789993472; x=1790598272; h=content-transfer-encoding:content-type: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:content-type; bh=UOWzjm9V2HkBkqE5Ilftrs+3ip0tzKvIaFfS8Kt3HCk=; b=hV4NOzOw2vQ8QGkNWtUpfQw8fbAfRpf6bbxxpkDZx3JhUSHdQZ5qVHoaAF1WxpKA7t vbb1tfbKq8u6gw3yPmr2tkjHmBnWVNwlIJxHYv42+X/DFK0/kUoelUusLx7MqEzMGU6n +tUNgxDk7gPpPLDUAAuAv9CYwxisn2Vs6qdG8I9XMwOb2nUo22LkcANUHOpkX2JEqQW8 5ZvCSgiiqcaNenCIOU7mqwf4koJ7wE4uslwlNQ7KuGGhaGYqhlo5IcasFt81PNMSP+Xk iM+jWKS/+yKq42MebvBx19gd19X1uXTinKkO6r6HehGVkG7ndcjUERjVpcBP4kBZNlbi ARPg== X-Forwarded-Encrypted: i=1; AKwUvBwxBQOv8SmvsbseyXrK5BpS2h22nPcLgAGINp13KKrnF6sWdgamrm15uQ2947hu7CmJlnCHbU7JzSA=@lists.xenproject.org X-Gm-Message-State: AFuF++k4x9H+qAdNKBqvzRfWF24oa0+Lm7tccf4ib89gg1YgfKE6c15e 2h5C4RvA/dyUC6szoQ4XuxHIRYq0MMQzs/bx/5Ax1s7831Iq3tXwVWKF+WYqHt2xoQ== X-Gm-Gg: AYBFou2cMdGpNRkVaNWSM06TvjiwKzFFWbzF6v4rKTwTHv0mJdHvq3K4FQq4nGZs1/z Fxu5S9lIe3Ls6zA7HHQQyg4Aiuc6QiG94t3p9v3o1dZzQDc5PPWg1XG9t69UgZ/bbyNRBJSwi1E lJWRxSXLgwlLYbCTvG4KqiVUAN08qfH2lpb38VjvY9CkoHKWOIdBLQkLF+Wfp/n6Taq86iav9ZT 6cfBJCybskW807CYrvPwU4R73UsPbG5+SlVrrEbAhCqxAJbNGlR2kt5Z8UclWRETpSV1optWfpu 85PzuRkVJtn/3tJhYuQ2XDKf8kj9FU4dmfhJ79wE0LgcxuH2/RGXV8LTti1QtQqt24sa+oQgaRo qQFwoGMibfiA5netl3AkTQUWUsHuqOsUvKQW12A3moZUCXmxH3KI0IKf/fLH9sNvvD4d85Qc2Uu u2Tx7aDCaa8SaRymmNAS3JQXydhY77GeAFJGJezdifC7XLk3hZaDDppuvGClBaD1DmO2Lhw/k3a vZnaNl4Y5r+pjW5fTZSyBZXy/rZ8ZxhuIme27pMD7WUhsjffJfStUdAGlOte1g= X-Received: by 2002:a05:600c:474c:b0:49c:f512:2361 with SMTP id 5b1f17b1804b1-49fc569587bmr157732555e9.14.1789993472118; Mon, 21 Sep 2026 05:24:32 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 14:24:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] vmx: Handle TDX instruction exit reasons To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1789049962.8631fc262581453bbf619ec5b2062170.1a08bb0014d000c4f3@vates.tech> 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: <1789049962.8631fc262581453bbf619ec5b2062170.1a08bb0014d000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1789993472-A66DAAE4-104FB882/0/0 X-purgate-type: clean X-purgate-size: 833 On 10.09.2026 16:17, Teddy Astie wrote: > On hardware that supports TDX, guests can cause VMEXIT related to > TDX instructions (SEAMCALL and TDCALL) regardless of VMCS configuration. > > Currently, that causes the domain to crash when a domain tries to > use these instructions in kernel-mode, and emit #UD when used in user-mode. > > Adjust the behavior so that the guest always gets #UD when trying to > use these instructions regardless of the privilege level that the vCPU > is running. > > In the nested virtualization case, also reinject the exit reason to L1 > rather than failing on "Unhandled nested vmexit" (leading to a L1 crash > that can be caused by L2 by executing one of the TDX instructions). > > Signed-off-by: Teddy Astie Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:32:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:32:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427426.1650126 (Exim 4.92) (envelope-from ) id 1x8dBj-0000X5-84; Mon, 21 Sep 2026 12:32:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427426.1650126; Mon, 21 Sep 2026 12:32:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dBj-0000Wy-4L; Mon, 21 Sep 2026 12:32:03 +0000 Received: by outflank-mailman (input) for mailman id 1427426; Mon, 21 Sep 2026 12:32:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dBh-0000Wp-Al for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:32:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8dBg-00D8OV-2A for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:32:00 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab123b7-2eae-0a2a0a5409dd-0a2a450a9e98-38 for ; Mon, 21 Sep 2026 14:31:59 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab123bf-f2d2-0a2a450a0019-4a7de18ca70f-3 for ; Mon, 21 Sep 2026 14:31:59 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d822dso20123545e9.2 for ; Mon, 21 Sep 2026 05:31:59 -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-49fcd8bf159sm213526515e9.10.2026.09.21.05.31.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 05:31:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789993919; x=1790598719; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=/1kl2NJfxaX+sX2BnLCJ2xm8QIrtkOnD1LC4q+3z4FE=; b=IayEs0zgb2r4ge/Ttv9tNZrZGq8RBRID6SocrGNamPNuaHKGXqobksdudEoShwbvZf qQTqnykHQ6jQoilurUOl4YN7E74f6AC+PhZoXMK5l1WtKvrAKTLJB4VRX+S695M2NoAk JyCsUOxeP0pRJIe6+wZ1Zsz4jHzaVhaV9w3639cgGsUSHbrb7xI97ewUutSiAgef/HDS IJWiQQ0O3oWG1rjShCTNadhYs1fLEWVUzGN0oPnh00dGtkpNeGKOnug6qpH/U8oSgZ/J QvqpEMHqqIxj6L1TwewU68SKPoPE/pVh11sPAiSCMbpVPYPJR4XJ1xIsS2VHtPbYC+x1 11Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789993919; x=1790598719; h=content-transfer-encoding:content-type: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:content-type; bh=/1kl2NJfxaX+sX2BnLCJ2xm8QIrtkOnD1LC4q+3z4FE=; b=hbrt3NhnEOcK6x4bdDRfzuSTAoonhfu/wJb2nwYhCLAbnjwODaPJrAVVe8zqSDAJAM KhIRUK/vEySIlts20woEdnFiZe/SDkOfMp/uc2DABOO3xm+x3cSzlFRz3KdtkIXzsxXR aXIH2y8aSYiumVsp1BrxyGcfg0LrKXIFGTX+IoPhLB1z4Zynb6pp4ce0E6pYvZbnrcmm TffDX/nhMCNGyC5xJY/QousVUvAzETF7erYICszYFlwDh2n23rYirF7RotbyLYHooX57 S7fFHuHYpQKtXSAyp2otQ2ozSrAD9JcBcEWSpc22jvA4XjMve8mZ+Vq2eZCzuLgB3H/Q Tg+w== X-Forwarded-Encrypted: i=1; AKwUvBwtA563kxZ909wCks6hY1AC1B9M71DwLkeK9mIOH+aw1nnFTnAVVTTrtNs/bCBRBHbhFGbhnhkyBlU=@lists.xenproject.org X-Gm-Message-State: AFuF++n0wtxs0VbBLcMrVN5jV+PiElVMbijF7nZfNZVLgqsWrRih2GMI OYYdtnmuWZYwFqIE2Q0h+pc+wn197gdeRuJz+8HdumwU+gdkdz87XH71pMQePWXmQA== X-Gm-Gg: AYBFou3vNyBuxxrihdb3wpX1LWlF8VeDYZ0EROpqgod/fBqA+lZDZDXKvqcN3lG2ARw js1jN0VeQW0bpNdFZ16SmcUzIWUJ7HZGtGtUH/57op+MRZKTETUBWyvXlmJkoXbtqv3m1I1EHIw DgtHqRDsdvk+RwrT9CiEt+wl8BdPuHvAwGS6eZdZhem68FjtZS4whsPk2QYWa/OxAnFHq4ELTvB x6Mi3zrJlLnBhdJ4Ud/jkezTnehPXAJGKla0ME8Gm+UY8vhLcy4Sqjg9WO+0ktlDZb5HRyuyXiX h93YHZmoi5nugNVNOrNgY279962tCvH6nKwcESJTmBLWpTKehsG9pd0w0QeFxGQOmkRLfoVy+L1 zYtJcolIJqURScfRh78ioyvyXpSRRU0kRqApcAH4DxE2FocIdsQnpB6BNom+4xUOUWQoDrrHwqh VgDY/ynRSvrjmEck2UB1aVk6PHs9Bu7aWhpOv+RhRheuTAP2wyLD3tdzIlhbffvbSgBERQ9aYmT NVCAJ2DnAfE/Owfs1/kp2Qj4/2FIDwoQIciK9jDTcQzWmXm6jNiLDjssZM2ip/4igKBBqR3 X-Received: by 2002:a05:600c:3b96:b0:49f:ce73:4a with SMTP id 5b1f17b1804b1-49fce7300a2mr110119755e9.34.1789993919463; Mon, 21 Sep 2026 05:31:59 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 14:32:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 39/39] xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4df9cf63943d0f371c8a25c6c9e84adbd3083a61.1787838835.git.oleksii.kurochko@gmail.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: <4df9cf63943d0f371c8a25c6c9e84adbd3083a61.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789993919-5A7DACFC-BD3D779E/0/0 X-purgate-type: clean X-purgate-size: 965 On 27.08.2026 17:21, Oleksii Kurochko wrote: > Introduce imsic_vsfile_attach() to initialize the AIA-related state needed > for a vCPU to have a working guest interrupt file. > > A guest (VS) interrupt file must be mapped to one of a pCPU's > hardware interrupt files (if they exist), so the pCPU a vCPU will actually > run on needs to be known first. arch_vcpu_create() is therefore not a > suitable place to call vcpu_aia_init(), since the pCPU assigned to a > vCPU can still change before it is first scheduled. To avoid > reassigning the VS interrupt file id and remapping it to a different > pCPU's hardware interrupt file, imsic_vsfile_attach() is called from a > later point in the scheduling path (e.g. continue_new_vcpu()). Hmm, why does first-time handling need to be this different from the handling of a vCPU moving across pCPU-s? The sole difference should be "no state to load" vs "load state that was saved on the old pCPU". Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:35:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:35:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427434.1650134 (Exim 4.92) (envelope-from ) id 1x8dF9-00017E-L6; Mon, 21 Sep 2026 12:35:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427434.1650134; Mon, 21 Sep 2026 12:35:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dF9-000177-ID; Mon, 21 Sep 2026 12:35:35 +0000 Received: by outflank-mailman (input) for mailman id 1427434; Mon, 21 Sep 2026 12:35:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dF8-000170-90 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:35:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8dF7-00DnJf-6H for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:35:33 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1248b-bab6-0a2a0a5309dd-0a2a4502a8ac-30 for ; Mon, 21 Sep 2026 14:35:33 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab12494-6ca4-0a2a45020019-4a7de18cdc26-3 for ; Mon, 21 Sep 2026 14:35:33 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ce364488dso7736145e9.0 for ; Mon, 21 Sep 2026 05:35:32 -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-49fcd090f0csm296990095e9.15.2026.09.21.05.35.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 05:35:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789994132; x=1790598932; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Tw8g040qgQwYAeyUufOKDezHhqEpig8j5wfPO/OZbIA=; b=HO+s7a41wm+VJl4qYJPc8g1bszrKmtPhJaSebjpG/CyHfDFPS23raR7fXsMs0CtUAz nvjWQFVt+k/vooDve05b2vhZPdbc72Ymg0i0V/PdHMjGGpN9zK1DA4igWArzfjQeSCmW +3ta1G0sZbEdBfV3LcSN1oyjDyDtjl7BP5sVFnJdQrLeNRdKciu7cR8QXsu+8r75b97Y CN6SsxrcdImW0Zo5drl4jBeG7TiUXzJoVexu8LMnzR/mr6vb0/73OVB1zPAwxZr6NMvu nk8LKDKoWmncoqsZg4ijjQOA7lsfB5N6Fa006pe3iPncNogf5qcyDrOYtVQPJGsAdc85 s82g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789994132; x=1790598932; h=content-transfer-encoding:content-type: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:content-type; bh=Tw8g040qgQwYAeyUufOKDezHhqEpig8j5wfPO/OZbIA=; b=y5atuwk8ZwLBao/4mDLlhLMpOJC2G7apToRzeKKWyHgFO8NLBrxUTC/aBPOxlhzNJy 4gke/Z5bo1M00cJIN5Bi0LnD696CncPaOR76hrUiHgtxCCwaovzI+0KGGO2f9+YAvMgx MPg/+yRSrqvjAV5/mk9Og1p5djTAik7BUHzeiWVZ0uYJne3i6SaDbP0vT+8C49GC3kzN INRU+uZAh6WIYNpZmI6tMG8RzdD4+yPFpRMP/bY1URQAAtO5JJtQGUS1gIOPjeOtnzUP xNhZXZbtxzBBTj6Fo6FItGJC4YCICDO+WQcMiDQ3LNSA9srZNch3qaJcwlm/nFLVRKXj nvkQ== X-Forwarded-Encrypted: i=1; AKwUvBz+8OZRcLOiRftoPRI57gfl9hMsU3NQdDxKGJNZiG4zYZlrJnaXGgA6kutnYcuzJsFKSbaU3rp8+7E=@lists.xenproject.org X-Gm-Message-State: AFuF++kPR7M551vIfaveVMZRNUyIqjtvi6xjWW1nlc2U3dVVD3gVtENB ESDac2i0/CXhjaX50d795mpoTF9zjCYBVV/ZwMEE6P3cYW1teu0O80nTyN7cCKlryA== X-Gm-Gg: AYBFou1CiP8ZjfraUyuE63eRt2PTbanIUL86bEVI1HLva3cWHaKqznd/+uh19UWtyWN ItpPLJuNf6mEODx2ShteO55g4SwWZ1yZ2ZfqgLQkhpOlQ8AVgrv2qjOQeAil9iqLSxaoH1+yddj 9NVVii19mR9dAarE+uXuc0PeXAHRiQZZLA0pRw76KPeSpYNNwuckeXcPBaw88K085Pxd3NT9S8E 5sILcHsyDNnaFZeGNb7MbxyJ0Dq8byrSXxT5Sj44bq0/d5rA8n/CNn6cmG9m/n7BBuzKwjRvuY5 tZw4CJQAXZm9RrCwt1flkMPOv60JmfJipxNzmf/u3JOmjDQyUy5xXXWsPg1WiN7JNmnzG6TkWct 2+aTXVmVMQ30UUKSVj9hoIn9Sjj9+ukiQDOvHL4m2DO4GsNlyp/OSLz4JbQt+FA3mz2Yi3ztGWf +/snI+y3xb2L97rWuLmiK+PPfrAPd813AEarQJot5qMgSdWIqaYYc5OXm2G14YPSWD5/X93nWka 2KHjIy8mNICvxK1rQZqkqdIAsBJMtoF2ZMeYFPgWksuxWbGbJKZRZ1DF76GJeo= X-Received: by 2002:a05:600c:1990:b0:49f:c1fd:60e1 with SMTP id 5b1f17b1804b1-49fc500c5c8mr165498215e9.15.1789994132466; Mon, 21 Sep 2026 05:35:32 -0700 (PDT) Message-ID: <9203f2b1-ed6d-48b3-b89f-da4b6058dec6@suse.com> Date: Mon, 21 Sep 2026 14:35:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] x86/svm: require VMSAVEvirt for nested virt To: Stephen Cheng Cc: Ross Lagerwall , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260727071709.196088-1-stephen.cheng@citrix.com> <20260921052910.580298-1-stephen.cheng@citrix.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: <20260921052910.580298-1-stephen.cheng@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1789994133-309C32AC-19522F49/0/0 X-purgate-type: clean X-purgate-size: 1140 On 21.09.2026 07:29, Stephen Cheng wrote: > Virtual VMLOAD/VMSAVE lets an L1 guest execute VMLOAD and VMSAVE > without intercepts. Without it, Xen has to map the L1-provided VMCB > and re-execute each instruction in L0, handling a complex, > security-sensitive subset of state on the way. > > Make VMSAVEvirt a hard requirement for nested SVM. The > cpu_has_svm_vloadsave test in svm_nested_features_on_efer_update() is > then redundant, as nested virt now requires the feature, and is > dropped. > > Assisted-by: Claude:claude-opus-4-8 > Signed-off-by: Stephen Cheng > --- > Changes in v3: > - Rebase onto staging. No functional change from v2. > > Changes in v2: > - Keep the VMLOAD/VMSAVE handlers rather than removing them; the insn > emulator will need them wired up regardless of older parts (Jan). > > Jan - v2 dropped the handler removal you objected to, but got no > response. Resending rebased in case it was missed. No, it wasn't missed. I'm hesitant acking certain nested-virt changes, at least without giving in particular Andrew ample time to comment. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:43:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:43:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427447.1650145 (Exim 4.92) (envelope-from ) id 1x8dMk-0002qn-E1; Mon, 21 Sep 2026 12:43:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427447.1650145; Mon, 21 Sep 2026 12:43:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dMk-0002qg-9y; Mon, 21 Sep 2026 12:43:26 +0000 Received: by outflank-mailman (input) for mailman id 1427447; Mon, 21 Sep 2026 12:43:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dMj-0002qa-0Z for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:43:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8dMi-00DpC6-D4 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:43:24 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1266a-bab6-0a2a0a5309dd-0a2a4508a650-2 for ; Mon, 21 Sep 2026 14:43:24 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1266b-f659-0a2a45080019-b9ff1c22ab57-3 for ; Mon, 21 Sep 2026 14:43:24 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c3fdfa2c00072c4.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 21 Sep 2026 12:43:16 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id E5A4181D1D; Mon, 21 Sep 2026 14:43:15 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=trSW28bbnFjhU58RiED3jIaS5MHYmlubY2tsEF4Xi64=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=gOiqHwE7/3CAeMqMOGTffPWpOlFhV0n2Fb0vExMe+QwwVjeEWh5Qfgj8NgtEkA++YLqPq/sw4 baDP7wrL/DQpGhYeEeNMg1cvR0ERA8wdBDUp36Pkt9s1ujVKhGTgkbHn1fH7PaL2ueAAqBqBhzd t/CzNf9t3gwQVAzhlSAWFelyATYWxhTLXMyc7sQUAmamLinJ3/D+wILlOz4/XrikB3TtoWbuHhj zqaOJH+Ohw8QLkQNIKhY92RTNBztUurYKzRANHQwYAMzsnivExnGP9wzj7Vxp76FEqjAJjJXM4i wkGNDT6ApBuhFV8MRI8Mn/wxUndoCm4h8qj+ApSKwZeg== X-Zone-Loop: 9b8ebdd3842a839d84696709f3db82e18c29933345aa x-campaign-type: default x-transaction-id: 28885734-849a-4e36-9f70-4002b699c2f9 x-swg-uid: 01-e2c0d260-a534-4bdb-90a0-c50706a54e63 X-Mailer: Sweego Message-ID: <1789994596.8631fc262581453bbf619ec5b2062170.1a0c3fdfa2c00072c4@vates.tech> x-swg-bid: 1789994596.8631fc262581453bbf619ec5b2062170.1a0c3fdfa2c00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 21 Sep 2026 14:43:15 +0200 From: Anthony PERARD To: "Orzel, Michal" Cc: Julian Vetter , xen-devel@lists.xenproject.org, Oleksii Kurochko , Community Manager , Andrew Cooper , Jan Beulich , Julien Grall , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie Subject: Re: [PATCH v5 3/6] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130863.8631fc262581453bbf619ec5b2062170.1a090827272000c4f3@vates.tech> <3c3c203d-7951-4340-a926-67b92224d531@amd.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3c3c203d-7951-4340-a926-67b92224d531@amd.com> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2a3.ae71483d88675bb7.1a0c3fdf79e.1b971fcd853fd7e=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789994596258 X-purgate-ID: tlsNG-c1860d/1789994604-CF15E87B-9669C04F/0/0 X-purgate-type: clean X-purgate-size: 4086 ---=Part.2a3.ae71483d88675bb7.1a0c3fdf79e.1b971fcd853fd7e=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 16, 2026 at 03:08:13PM +0200, Orzel, Michal wrote: >=20 >=20 > On 11-Sep-26 14:47, Julian Vetter wrote: > > XEN_DOMCTL_CONFIG_GIC_NATIVE lets the toolstack ask Xen to silently > > resolve the domain's GIC version to whatever the host hardware has=2E = Xen > > then writes the resolved value back into the same in/out > > xen_arch_domainconfig the toolstack used as input, which is the kind o= f > > API abuse we're trying to get rid of=2E The struct passed to createdom= ain > > should only be an input parameter=2E > >=20 > > Move the "pick the best available GIC version" decision to the > > toolstack, using the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 capability bits > > already exposed via XEN_SYSCTL_physinfo: > >=20 > > * libxl__arch_domain_build_info_setdefault() resolves the GIC version > > against those bits before the config is built=2E An unspecified ver= sion > > becomes v3 if available, else v2, else fails=2E An explicitly reque= sted > > v2/v3 is validated against the same bits, so a version the host > > cannot provide is directly rejected in the toolstack=2E > > * The Python xc=2Edomain_create() binding does the same via a call to > > xc_physinfo()=2E > > * libxl__arch_domain_prepare_config() therefore only ever sees a > > concrete v2/v3 request and just validates it=2E The GIC_NATIVE case= is > > dropped since setdefault() always resolves it first=2E > >=20 > > The LIBXL_GIC_VERSION enum value 0 is renamed from DEFAULT to NONE to > > reflect that it now only means "the user did not pick a version"=2E > > setdefault() resolves it before anything else can observe it, so there > > is no longer a "default" left in the config=2E The xl=2Ecfg(5) gic_ver= sion > > documentation is updated to match=2E > >=20 > > This guarantees no toolstack path can still produce > > XEN_DOMCTL_CONFIG_GIC_NATIVE, in preparation for removing it from the > > Xen side and from the ABI entirely=2E > >=20 > > Signed-off-by: Julian Vetter > > --- > > Changes in v5: > > - Go back to the initial per-version arch_capabilities_arm_gic_{v2,v3}= () > > helpers instead of a generic arch_capabilities_arm_has(caps, mask) > > - Validate an explicitly requested GIC version against the host > > capabilities, not just resolve an unspecified one > > - Rename LIBXL_GIC_VERSION_DEFAULT to LIBXL_GIC_VERSION_NONE > This one is on me=2E I just realized that libxl compares user provided s= tring with > the IDL types, so a xl=2Ecfg file specifying "default" would fail now=2E= This would > be wrong given that libxl API is stable=2E Let's keep the DEFAULT as it = was (for Yes please :-) "default" is fine=2E That option could even be removed from the config file, and only allow users to choose between v2 and v3 option, or remove the option from the config file to let the tool stack decide=2E We could simply document both v2 and v3, and say that if the config option isn't given, libxl will try v3, then v2=2E (and probably keep the gic_version=3Ddefault working, so that existing config don't break as there isn't a need to break them=2E) "none" is definitely wrong, because it should mean start without any GIC=2E I need to review the rest of the change now=2E > NONE you would also need to change the golang bindings)=2E With that cha= nged: > Acked-by: Michal Orzel >=20 > You will still need Rb from Anthony as toolstack maintainer=2E FYI, it's the other way around, you need at least an Acked-by from a maintainer, and you should supply a Reviewed-by instead for part of the code you don't maintained=2E ;-) That's documented in the MAINTAINERS=2E Cheers, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.2a3.ae71483d88675bb7.1a0c3fdf79e.1b971fcd853fd7e=--- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:49:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:49:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427456.1650153 (Exim 4.92) (envelope-from ) id 1x8dSk-0003av-5E; Mon, 21 Sep 2026 12:49:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427456.1650153; Mon, 21 Sep 2026 12:49:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dSk-0003ao-1g; Mon, 21 Sep 2026 12:49:38 +0000 Received: by outflank-mailman (input) for mailman id 1427456; Mon, 21 Sep 2026 12:49:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dSi-0003ai-TT for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:49:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8dSg-002NU5-IX for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:49:34 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab127d6-8faa-0a2a0a5109dd-0a2a4507e26a-20 for ; Mon, 21 Sep 2026 14:49:34 +0200 Received: from [52.101.85.1] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab127dc-b4ea-0a2a45070019-346555017df9-3 for ; Mon, 21 Sep 2026 14:49:34 +0200 Received: from DM6PR01CA0002.prod.exchangelabs.com (2603:10b6:5:296::7) by PH8PR12MB7304.namprd12.prod.outlook.com (2603:10b6:510:217::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 12:49:28 +0000 Received: from CH3PEPF00000017.namprd21.prod.outlook.com (2603:10b6:5:296:cafe::a7) by DM6PR01CA0002.outlook.office365.com (2603:10b6:5:296::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.16 via Frontend Transport; Mon, 21 Sep 2026 12:49:28 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CH3PEPF00000017.mail.protection.outlook.com (10.167.244.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.0 via Frontend Transport; Mon, 21 Sep 2026 12:49:28 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Mon, 21 Sep 2026 07:49:28 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Mon, 21 Sep 2026 07:49:24 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=seVw+26CtGkeTeR3xtAy/OJSAad8OvIM2ZK+5j8gyXpQhzeNkTzVNgWrQc19iaAMKiOG+bprcPXtjS9s8qxT0gpfHBkRN9D6kVH2QbW7JyeigORM47BOafFuF4UPXYHJoIoTJEEyZFd3psbs7bX2uaIyjuxZDXGcFveqjdEEdglzRirieAiuKHSXpnPhIBVhc8OgQbkv+U1xJdrEpEJN5cLSccFUxr7ZnXszf00gluw1tukpnBPYSFwoc2MSBRxPVLSI+Lb8glWWL2U+Ayd8NfKeZtV6Z5KKFSa7ADRBM3nk2CPlFJq89/e3fEfgiNBNau8jZ3uteVT7pKTbH4lHcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9aol8pHVSNyj5hhGBucXXZZ6eSC02o6zs3duNNyjmY0=; b=pVScH2JN794U7cdBJo7HShwX3tQ54V2qPqGsfy7ShQTp1XIwN0riJeXis+CpSgq1VmHSgQQPWya+vk4GHGO9s7bC6sMefe9XCRXNJ8ukK/dgFdmJB2Gsm8xYEDGK3Ne+JqQJgdZB2dVoqR23sfHYbnVqGMkQtFNO4AQ5XjuzFRaD58f3Yqdf8QedYxIoR/+zsffxFSUer6WV3za0S3EMvExSIN4Onzzv+tJb8y7MT3RqYlPn+zJOR5hfjdJyZpr071mf6dCBxu3i/+FmsPh9Oco7kDFhBZKICxfIq1LQVtX1SkMaQe7BijS8Q2SrsW2BZlPA2ksDfSH/bd51/BLLiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9aol8pHVSNyj5hhGBucXXZZ6eSC02o6zs3duNNyjmY0=; b=Z8HLHCfhVHkozhv5AIEefRG+yrZOHihz+ddha9czhmIRYXZvEdznYFm3L/2eAA2wwH89CfQwVD7gsWOhHnKSJFXa2TTilKOa82Icu3Mg6EHBedNUQGbeRASAg5wV5lENdnG56B/tTMJu31mNk2dcqjk4UyMg3Yte2p6ibXBo6AU= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: Date: Mon, 21 Sep 2026 14:49:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 3/6] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE To: Anthony PERARD CC: Julian Vetter , , Oleksii Kurochko , Community Manager , Andrew Cooper , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130863.8631fc262581453bbf619ec5b2062170.1a090827272000c4f3@vates.tech> <3c3c203d-7951-4340-a926-67b92224d531@amd.com> <1789994596.8631fc262581453bbf619ec5b2062170.1a0c3fdfa2c00072c4@vates.tech> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1789994596.8631fc262581453bbf619ec5b2062170.1a0c3fdfa2c00072c4@vates.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF00000017:EE_|PH8PR12MB7304:EE_ X-MS-Office365-Filtering-Correlation-Id: de17b262-c201-4a7c-eab6-08df17dec62e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|23010399003|376014|7416014|82310400026|1800799024|10067099003|6133799003|11063799006|5023799004|22082099003|18002099003|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: 7RuzCGGuw3oZ/uB/FTfQ/iiTjEYtzYhGB5lWSp6Daqy87mRBabL9vNfAkM8fAo0XpbLQ24mwt4XKO9yzBj/o+MO+IQOQT/mPHHJk/W1ukOrjJB06pPaJF3RLKZFxR2LVBaUPHGaCpIbVxIN1hqh+dOOW36xs/grwshxSblYShH69Ef66bINCRfrsZJ6skRBriNUVMjkaYBlSW3zGbPV7YRJTSXq8b4z0KW3mUWIlbsGFTRMOjqLa2a/CcVMjHDZkeDQ1L8N4zkAiKTJ8Vz7GaRnxbN0YEMDjvZUHDA3I5NR7LoDwqaq4DX+OxQunmQ7PFRSmghxNLrtG3FFeXWhHBFwpFH3rf8zu7Q65TC9pl2H+fV8MIG+aHt6MhficIMPj7pLBD9i3Fq/ESBEjJGI2fd2sGjtaFNwRKDXqX/D48VvIFf8SaaZUs4R09nsXwjHeo2t7uQuYuaOoa165VJlkLauog28iuHPevNLZ7vVJ7NymNtvBQGGgBlKwuzacwAYN20aP/sGJoANJgKZkBIgdxFQeKFSXjdRMjwVT3AKM1exF4CiuUOqbbRH3xFQ8rrQ3afCBZC+oX4Fmq68twhbvXx7E6VFmLxf/tAtILIpj5MFPpBJzPAG7yh13GAc6xauofj6Re1wuQRUYdPOCkOTRf9KbIAGD0VUahExLaw7buMmPYtDcAq1hANPK465ky8MMQoV8cpmEu5SLWrZ6Th8YBg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(23010399003)(376014)(7416014)(82310400026)(1800799024)(10067099003)(6133799003)(11063799006)(5023799004)(22082099003)(18002099003)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: uSHZDT/yg1beeJQa3NxkGMZcs4h0pkWcV7vgFry25dejUCHrsHDpJshmTalYJamHktmXkr9oWLSEVUxJhn/w+IC0HRAOOMK1NErxSHlxNSfPcc+Mfei8B1XK3ifq/qAwQEIlMz0iYH7flBCp7fhykRueCJ7wIS8QWdA0x+OV8w3DRSl81kz2vhssWhe9yo5KSCXfEbHBzq0igDxJTpk5x5qMdB9aG6TbnzNYnNHMsTRK3JQmrfF3cePIZi7KMNfAv+ermOFjV6YLqM5qwrHQniGeszt5B7WifJb2FGXV2ZjL4G7DjmEa0xP0l3aqP6aiTjakNihfBltOrguYPMS+/AiFVQa16WwHYMM+2uIblgzZ+rhh8moDoU0MDfqqYQ+ULkyFkd5fFiTBUXjsE6OoSCXcjped1U2Mx9EcOpqqoR2ncf6WReTe2FDUuS5dHsgX X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 12:49:28.4490 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de17b262-c201-4a7c-eab6-08df17dec62e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF00000017.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7304 X-purgate-ID: tlsNG-ef75cf/1789994974-A6AD8AE4-1A9F3886/0/0 X-purgate-type: clean X-purgate-size: 3780 On 21-Sep-26 14:43, Anthony PERARD wrote: > On Wed, Sep 16, 2026 at 03:08:13PM +0200, Orzel, Michal wrote: >> >> >> On 11-Sep-26 14:47, Julian Vetter wrote: >>> XEN_DOMCTL_CONFIG_GIC_NATIVE lets the toolstack ask Xen to silently >>> resolve the domain's GIC version to whatever the host hardware has. Xen >>> then writes the resolved value back into the same in/out >>> xen_arch_domainconfig the toolstack used as input, which is the kind of >>> API abuse we're trying to get rid of. The struct passed to createdomain >>> should only be an input parameter. >>> >>> Move the "pick the best available GIC version" decision to the >>> toolstack, using the XEN_SYSCTL_PHYSCAP_ARM_GIC_V2/V3 capability bits >>> already exposed via XEN_SYSCTL_physinfo: >>> >>> * libxl__arch_domain_build_info_setdefault() resolves the GIC version >>> against those bits before the config is built. An unspecified version >>> becomes v3 if available, else v2, else fails. An explicitly requested >>> v2/v3 is validated against the same bits, so a version the host >>> cannot provide is directly rejected in the toolstack. >>> * The Python xc.domain_create() binding does the same via a call to >>> xc_physinfo(). >>> * libxl__arch_domain_prepare_config() therefore only ever sees a >>> concrete v2/v3 request and just validates it. The GIC_NATIVE case is >>> dropped since setdefault() always resolves it first. >>> >>> The LIBXL_GIC_VERSION enum value 0 is renamed from DEFAULT to NONE to >>> reflect that it now only means "the user did not pick a version". >>> setdefault() resolves it before anything else can observe it, so there >>> is no longer a "default" left in the config. The xl.cfg(5) gic_version >>> documentation is updated to match. >>> >>> This guarantees no toolstack path can still produce >>> XEN_DOMCTL_CONFIG_GIC_NATIVE, in preparation for removing it from the >>> Xen side and from the ABI entirely. >>> >>> Signed-off-by: Julian Vetter >>> --- >>> Changes in v5: >>> - Go back to the initial per-version arch_capabilities_arm_gic_{v2,v3}() >>> helpers instead of a generic arch_capabilities_arm_has(caps, mask) >>> - Validate an explicitly requested GIC version against the host >>> capabilities, not just resolve an unspecified one >>> - Rename LIBXL_GIC_VERSION_DEFAULT to LIBXL_GIC_VERSION_NONE >> This one is on me. I just realized that libxl compares user provided string with >> the IDL types, so a xl.cfg file specifying "default" would fail now. This would >> be wrong given that libxl API is stable. Let's keep the DEFAULT as it was (for > > Yes please :-) "default" is fine. That option could even be removed from > the config file, and only allow users to choose between v2 and v3 > option, or remove the option from the config file to let the tool stack > decide. We could simply document both v2 and v3, and say that if the > config option isn't given, libxl will try v3, then v2. (and probably > keep the gic_version=default working, so that existing config don't > break as there isn't a need to break them.) > > "none" is definitely wrong, because it should mean start without any > GIC. > > I need to review the rest of the change now. > >> NONE you would also need to change the golang bindings). With that changed: >> Acked-by: Michal Orzel >> >> You will still need Rb from Anthony as toolstack maintainer. > > FYI, it's the other way around, you need at least an Acked-by from a > maintainer, and you should supply a Reviewed-by instead for part of the > code you don't maintained. ;-) That's documented in the MAINTAINERS. Yes :) I definitely meant Ab but somehow ended up writing Rb. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Sep 21 12:51:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 12:51:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427462.1650161 (Exim 4.92) (envelope-from ) id 1x8dUG-00052G-Eg; Mon, 21 Sep 2026 12:51:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427462.1650161; Mon, 21 Sep 2026 12:51:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dUG-000529-Bz; Mon, 21 Sep 2026 12:51:12 +0000 Received: by outflank-mailman (input) for mailman id 1427462; Mon, 21 Sep 2026 12:51:10 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dUE-000521-Av for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 12:51:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8dUD-00HBUk-AF for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:51:09 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab12836-8faa-0a2a0a5109dd-0a2a450cd200-36 for ; Mon, 21 Sep 2026 14:51:09 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1283c-f479-0a2a450c0019-b9ff1c12b153-3 for ; Mon, 21 Sep 2026 14:51:09 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c4051b5b00072c4.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 21 Sep 2026 12:51:04 +0000 Received: from [192.168.1.18] (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie) by mail2.vates.fr (Postfix) with ESMTPSA id 33DFC81CC2; Mon, 21 Sep 2026 14:51:03 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=otU8jkb1ESJfl6ruxOWD5jq8zh1VAHtRquoul63uS3A=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=IM82ySJYHfWPOHgEcOk51PvkwxBIWyUmPyZNORf/FbEUSZPxcxxgJTPebt3/8kT8UNAdoELkZ /GHpFkHSIL9lrcQFX5WBmM1SKINgC6tdkRorUzIXM4lDBBgrrkihn3EWGPVhOzaHR9YeGuADkLR bSGOdslz1eNUUSH02D5SB2c/nuITXR9OxZCiZLhrETlUFAnLJIYfYwli6jEuOF+OnF+4ZQvYOj3 2E8BKr5UETfAYPbXsdjVEEMxZru1B30WAfjzISv6/+rmlYQl+1yD+pMQcgcb4+oYa+1ANvwdogj 7ke7RTcbevRaVh8jZjJYskxTr6LgWWqbqYkfUN5fQx2g== X-Zone-Loop: 67316118091cbb76ad3d9058e6a238cf9c7fcb47aec1 x-campaign-type: default x-transaction-id: 7dab13ea-2a2c-4085-8181-cc069d3380fb x-swg-uid: 01-f15f6e4b-962f-4a15-b341-d4a0b199073d X-Mailer: Sweego Message-ID: <1789995064.8631fc262581453bbf619ec5b2062170.1a0c4051b5b00072c4@vates.tech> x-swg-bid: 1789995064.8631fc262581453bbf619ec5b2062170.1a0c4051b5b00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 21 Sep 2026 14:51:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 4/5] x86/hvm: Transition to needs_tlb_flush logic, use per-domain ASID To: Ross Lagerwall , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Jason Andryuk , Tim Deegan References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509309.8631fc262581453bbf619ec5b2062170.19fb8a5ecef000e099@vates.tech> <0b4a8cb9-e398-43a5-8f68-2c36d245c88d@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <0b4a8cb9-e398-43a5-8f68-2c36d245c88d@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------9YSV82vC95ZDfyhI4bYj32Qy" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789995063491 X-purgate-ID: tlsNG-d25034/1789995069-51B359FB-3E43E116/0/0 X-purgate-type: clean X-purgate-size: 87101 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------9YSV82vC95ZDfyhI4bYj32Qy Content-Type: multipart/mixed; boundary="------------TiQbcPbcRGxP9nCxRii9P66V"; protected-headers="v1"; hp="clear" Message-ID: Date: Mon, 21 Sep 2026 14:51:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 4/5] x86/hvm: Transition to needs_tlb_flush logic, use per-domain ASID To: Ross Lagerwall , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Jason Andryuk , Tim Deegan References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509309.8631fc262581453bbf619ec5b2062170.19fb8a5ecef000e099@vates.tech> <0b4a8cb9-e398-43a5-8f68-2c36d245c88d@citrix.com> Content-Language: en-US From: Teddy Astie Autocrypt: addr=teddy.astie@vates.tech; keydata= xsDNBGn5sK8BDACuzSrrTjpVf4ay06OYB6yY0J1PqKffihoNMtrQRZjAHxoAPC7LTBVHV/XO Zw5HJc+9R71z1JV+iYg6z3jPziGKzX8Fj3ZXlzJPmpf1PuETH3KdbvtJT4ny+OGntnJntUoR KRPhTirr6yNeBk/637O3CQXjtqFUPZnko8OI/o1yawIBhJJAWicutjkkUgd28Bh6HV9EIumH tCBgn5/1A/fpm9624MMgYLsA8qjC4XsoovQvFCaO8HEhvfzrrTZHjn/nPeB9SigxIxXW8YaT VqMdqul07o72m3eA2mf+LMu9a04FX/d4wbxBLtELm+1jIrbtyaFZEMOLv/haSiS/Lj3btJH/ EoucejoZ5SH49ksmVAmKOLktOaTQ8b2gEvP7iaKiIiszCCtOSRohr+2GvDsDeLvVZnlR3I+S PhHar7TPKjFz0G3DPNolyjXywNqOAMpomSPi8lSwjAFsxOtQbcck/qRGRSNk4DAmH70pA+89 MXfQXZ3qt1Q01B1+sU0I8xsAEQEAAc0kVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZhdGVz LnRlY2g+wsENBBMBCAA3FiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sK8FCQWjmoACGwME CwkIBwUVCAkKCwUWAgMBAAAKCRBmD6nRAsvP0ID6DACGOktArFbLKHNzuyOVCskwfUZPla6Z pd3GZ8r61SrAKePIr2BnpgPkd0hV3bSRkRLIrgjzR2NRCzfp0x0HfuhcYfAYPR46XHTvjaJE v99sT/vGUG1BZguYDOScSEpgSNaNlYum3RKZbMuROxdK8G+YHccJY8PvWSq2K2yiae2KGiAv 1yjnZxug9/PtDfX8vQFUSg2w1ukRDf50wvDohN1zUQfFtofOP2xCRsDZiHAlQ0pF+aUjXQhP eP3IdpfWc8cyRLXF06Rk46YMYCytweGtGdHcqAfrVthl84129ZPN422k/voW0sm14gjYlGcT UwgnYlFRk2FLq0QeKEDcS0aj3o3EVAQCrayoGzi1pnlIKE3PRGUcUzjGVvzQ/po24gOjwba9 Egr/Wmu3MQlx/7A8zT5QBzF/n+RYdLNQ0Eu6YnUwf0Z1uieqNaon+olyIRFiLb/hCZHO6ekN f5vrm2clHUbQAYaPQebknujoKBo6ZLHg0WM1gZS01Gz+aUpKsUfOwM0EafmwsAEMAKiQiZa3 yQMmc/h3sDbfVHPSiBA4IMI/NAB7IotzPHq1GzCpsoVILAhF/INbWjxJ3DbVf+en3/FvdVZg 2S38xtnth0njNdlVKpyxm054phKjbdoFDwaknWolS4hrddTmetSG5/52AjtmPFtlXAk0NmLv fJnW3seXVQbgM7sW/MNXPP5UKDpkGnLhnvej+GU0s3109sJeXT5ImVdphFs9cvyZyBT9t1Pb Rowv58EgV0zE4hbAeVkULAbxFV5b/ExTjjGVHoX7CVhWxvCiTqCUoXZRkUE9C3FnkzEFRkKb Yu6NCfiHfEyB3Xyg9hfdrRgjMRq907zCof+nDtWxGz1MSEuvTj1g9GZ049Bennqzjc/Q+0ov XoK4jm+Py0FiUGUaA6yhexficjH+kCR/xDbVnWrMhSLB4AuTBT9HjfZI6gk3uYLhoT8Pig4/ eVtR2Q1wZIJsFToR6ofGuyECwFcs+PUXN7fmGRSiPXgjAr/zIUBdW0VWCE3OGPNqtRk2E5s6 IQARAQABwsD8BBgBCAAmFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmn5sLAFCQWjmoACGwwA CgkQZg+p0QLLz9DncQwAg76IehTemLIfrB8T9WIBZrI4kUV7G7a4rjiVoUiHYN5QwhnbZnsa JDlt+Ezoqy/510eo2bCSzvW5xXYPgyjcuOPwgQo1Qp764QxyX6rld2f2RcWkDuBHun55ZWXj by8o21ginPRwruBVYY5rVf3DV1iBu4NurUeHtyFk/dS0XTOQi2wVUb17sW/+ybCEokdVacZG zOqP/OmwHrF8ylXlXnhQq6e3r+J+T8fuoGJelm/CJiMwyP6cEWE8sxVqX/iqwjwUYkuOCpE+ lOWSvdNHgoEkWR0RXBPQjnGmLKbfTl/QDXLk6NP2/r9uxm2HL6Ei3QJKSEdrp+XZaVnk/Off O485NOTKwGOxyWb006cTMh53xPkAJFQu4Tvdj+odsHz88jqw5wfPG0BYWx0I/FspYj7N9kZR 8ULR9nX0LvpzJ/kB4NgHIUt8YtIL6ZSfM2dbF7fKzvx1UqFfvozJZwFzfEieJLXa4nlGgR6D x9fhaZEsniw8/bYgC3igkk5YJiOa In-Reply-To: <0b4a8cb9-e398-43a5-8f68-2c36d245c88d@citrix.com> --------------TiQbcPbcRGxP9nCxRii9P66V Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TGUgMTgvMDkvMjAyNiDDoCAxODozMCwgUm9zcyBMYWdlcndhbGwgYSDDqWNyaXTCoDoNCj4g T24gNy8zMS8yNiAzOjQ2IFBNLCBUZWRkeSBBc3RpZSB3cm90ZToNCj4+IENoYW5nZSB0aGUg QVNJRCBtb2RlbCB3aGVyZSBhbGwgdkNQVSBvZiBhIGRvbWFpbiBzaGFyZSB0aGUgc2FtZSBB U0lEDQo+PiBhcyByZXF1aXJlZCBieSBBTUQgU0VWIGFuZCBicm9hZGNhc3QgVExCIGZsdXNo aW5nIGZlYXR1cmVzIChBTUQgSU5WTFBHQikuDQo+Pg0KPj4gQVNJRCAxIGlzIHJlc2VydmVk IGFzIGEgcGxhY2Vob2xkZXIgZm9yICJubyBkb21haW4gQVNJRCIsIGFuZCB1c2VkIHdoZW4N Cj4+IGVpdGhlciBBU0lEIGFyZSBub3Qgc3VwcG9ydGVkIG9yIG5vIG1vcmUgQVNJRCBpcyBh dmFpbGFibGUgZm9yIHVzZS4NCj4+IEluIHRoaXMgY2FzZSwgd2UgYWx3YXlzIGZsdXNoIHRo ZSBUTEIgd2hlbiBmcm9tIGFuZCB0byBzdWNoIGRvbWFpbidzDQo+PiB2Q1BVLg0KPj4NCj4+ IE1vcmVvdmVyLCBjZW50cmFsaXplIHRoZSBUTEIgZmx1c2hpbmcgbG9naWMgdG8gdXNlIG5l ZWRzX3RsYl9mbHVzaCwgaWYNCj4+IGEgZnVsbCBUTEIgZmx1c2ggbmVlZHMgdG8gYmUgcGVy Zm9ybWVkIGZvciB0aGUgdkNQVSwgZWl0aGVyIHRocm91Z2gNCj4+IFNWTSB0bGJfY29udHJv bCBvciBWTVggaW52dnBpZCBiZWZvcmUgZW50ZXJpbmcgdGhlIGd1ZXN0Lg0KPj4NCj4+IEFz IGEgcmVzdWx0LCBkcm9wIEFTSUQgdGlja2xpbmcgbG9naWMsIHdoaWNoIGlzIG5vdyByZWR1 bmRhbnQgd2l0aCB0aGUNCj4+IG5lZWRzX3RsYl9mbHVzaCBtZWNoYW5pc20gaW50cm9kdWNl ZCBwcmV2aW91c2x5LiBBbHNvIHRha2UgdGhlIA0KPj4gb3Bwb3J0dW5pdHkNCj4+IHRvIGRy b3Agc29tZSBub3cgdW51c2VkIGhlbHBlcnMgbm93IHRoYXQgRkxVU0hfSFZNX0FTSURfQ09S RSBpcyBkcm9wcGVkLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IFRlZGR5IEFzdGllIDx0ZWRk eS5hc3RpZUB2YXRlcy50ZWNoPg0KPj4gLS0tDQo+PiBUaGlzIHBhdGNoIGlzIHBhcnRpY3Vs YXJseSBoYXJkIHRvIHNwbGl0IGFzIHRoZSByZXF1aXJlZCBjaGFuZ2VzIG5lZWRzDQo+PiB0 byBjb21lIGFsbCBhdCBvbmNlLg0KPj4NCj4+IFNvbWUgcXVlc3Rpb25zIDoNCj4+IMKgIC0g T24gSW50ZWwsIHdpdGggIkFTSUQgZGlzYWJsZWQiLCBzaG91bGQgd2UgZGlzdGluZ3Vpc2gg YmV0d2VlbiANCj4+IHVzaW5nIHNlbnRpbmVsDQo+PiDCoMKgwqAgIlZQSUQ9MSIgKHdpdGgg c2luZ2xlLWNvbnRleHQgZmx1c2ggb2YgVlBJRD0xKSB3aXRoIGRpc2FibGluZyBWUElEIA0K Pj4gKHRocm91Z2gNCj4+IMKgwqDCoCBTRUNPTkRBUllfRVhFQ19FTkFCTEVfVlBJRCkgd2hp Y2ggaW1wbGllcyBmbHVzaGluZyBhbGwgVlBJRD0wIA0KPj4gKFhlbi9QViBvbmVzKSBUTEIN Cj4+IMKgwqDCoCBlbnRyaWVzIG9uIHZtZW50ZXIgPw0KPj4gwqDCoMKgIE9mIGNvdXJzZSwg aGFyZHdhcmUgd2l0aG91dCBWUElEIHN1cHBvcnQgY2FuJ3QgdXNlIFZQSUQ9MSBhbmQgd2ls bCANCj4+IGJlaGF2ZSB3aXRoDQo+PiDCoMKgwqAgVlBJRCBkaXNhYmxlZC4NCj4+DQo+PiDC oCAtIEkgdGVzdGVkIGl0IG9uIGJvdGggSW50ZWwgYW5kIEFNRCBwbGF0Zm9ybXMgd2l0aG91 dCBtdWNoIGlzc3VlcywgDQo+PiBidXQgZGlkbid0DQo+PiDCoMKgwqAgcGVyZm9ybWVkIHRl c3RzIHdpdGggbmVzdGVkIHZpcnQgd2hpY2ggaGFzIHRyaWNreSBpbnRlcmFjdGlvbnMgDQo+ PiB3aXRoIHRoZXNlDQo+PiDCoMKgwqAgY2hhbmdlcy4NCj4+DQo+PiDCoCBkb2NzL21pc2Mv eGVuLWNvbW1hbmQtbGluZS5wYW5kb2PCoMKgwqDCoMKgIHzCoMKgIDIgKy0NCj4+IMKgIHhl bi9hcmNoL3g4Ni9mbHVzaHRsYi5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzC oCAyMiArLS0tDQo+PiDCoCB4ZW4vYXJjaC94ODYvaHZtL2FzaWQuY8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCB8IDE2OSArKysrKysrKysrKy0tLS0tLS0tLS0tLS0tDQo+PiDC oCB4ZW4vYXJjaC94ODYvaHZtL2VtdWxhdGUuY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8 wqDCoCAyICstDQo+PiDCoCB4ZW4vYXJjaC94ODYvaHZtL2h2bS5jwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgfMKgIDE0ICstDQo+PiDCoCB4ZW4vYXJjaC94ODYvaHZtL25l c3RlZGh2bS5jwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqAgNyArLQ0KPj4gwqAgeGVuL2Fy Y2gveDg2L2h2bS9zdm0vYXNpZC5jwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgNjcgKysr KysrKy0tLQ0KPj4gwqAgeGVuL2FyY2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmPCoMKgwqDC oMKgwqAgfMKgwqAgMiArLQ0KPj4gwqAgeGVuL2FyY2gveDg2L2h2bS9zdm0vc3ZtLmPCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIDM1ICsrKy0tDQo+PiDCoCB4ZW4vYXJjaC94ODYv aHZtL3N2bS9zdm0uaMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoCA0IC0NCj4+IMKg IHhlbi9hcmNoL3g4Ni9odm0vdm14L3ZtY3MuY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKg wqAgNiArLQ0KPj4gwqAgeGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmPCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfMKgIDY2ICsrKysrLS0tLS0NCj4+IMKgIHhlbi9hcmNoL3g4Ni9odm0v dm14L3Z2bXguY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqAgNCArLQ0KPj4gwqAgeGVu L2FyY2gveDg2L2luY2x1ZGUvYXNtL2ZsdXNodGxiLmjCoMKgwqAgfMKgwqAgNyAtDQo+PiDC oCB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZtL2FzaWQuaMKgwqDCoCB8wqAgMzAgKyst LS0NCj4+IMKgIHhlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9odm0vZG9tYWluLmjCoCB8wqDC oCAxICsNCj4+IMKgIHhlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9odm0vaHZtLmjCoMKgwqDC oCB8wqAgMTUgKy0tDQo+PiDCoCB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZtL3N2bS5o wqDCoMKgwqAgfMKgwqAgNSArDQo+PiDCoCB4ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZt L3ZjcHUuaMKgwqDCoCB8wqAgMTAgKy0NCj4+IMKgIHhlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz bS9odm0vdm14L3ZteC5oIHzCoMKgIDQgKy0NCj4+IMKgIHhlbi9hcmNoL3g4Ni9tbS9oYXAv aGFwLmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoCA5ICstDQo+PiDCoCB4ZW4v YXJjaC94ODYvbW0vcDJtLmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzC oMKgIDYgKy0NCj4+IMKgIHhlbi9hcmNoL3g4Ni9tbS9wYWdpbmcuY8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgfMKgwqAgMiArLQ0KPj4gwqAgeGVuL2FyY2gveDg2L21tL3NoYWRv dy9tdWx0aS5jwqDCoMKgwqDCoMKgwqDCoCB8wqAgMTIgKy0NCj4+IMKgIDI0IGZpbGVzIGNo YW5nZWQsIDI0MSBpbnNlcnRpb25zKCspLCAyNjAgZGVsZXRpb25zKC0pDQo+Pg0KPj4gZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyBiL2RvY3MvbWlz Yy94ZW4tIA0KPj4gY29tbWFuZC1saW5lLnBhbmRvYw0KPj4gaW5kZXggMWM3MTFmYTk4MC4u ZjU5YzE0ZDQ0NyAxMDA2NDQNCj4+IC0tLSBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5l LnBhbmRvYw0KPj4gKysrIGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jDQo+ PiBAQCAtMjA4LDcgKzIwOCw3IEBAIHRvIGFwcHJvcHJpYXRlIGF1ZGl0aW5nIGJ5IFhlbi7C oCBBcmdvIGlzIGRpc2FibGVkIA0KPj4gYnkgZGVmYXVsdC4NCj4+IMKgID4gRGVmYXVsdDog YHRydWVgDQo+PiDCoCBQZXJtaXQgWGVuIHRvIHVzZSBBZGRyZXNzIFNwYWNlIElkZW50aWZp ZXJzLsKgIFRoaXMgaXMgYW4gDQo+PiBvcHRpbWlzYXRpb24gd2hpY2gNCj4+IC10YWdzIHRo ZSBUTEIgZW50cmllcyB3aXRoIGFuIElEIHBlciB2Y3B1LsKgIFRoaXMgYWxsb3dzIGZvciBn dWVzdCBUTEIgDQo+PiBmbHVzaGVzDQo+PiArdGFncyB0aGUgVExCIGVudHJpZXMgd2l0aCBh biBJRCBwZXIgZG9tYWluLsKgIFRoaXMgYWxsb3dzIGZvciBndWVzdCANCj4+IFRMQiBmbHVz aGVzDQo+PiDCoCB0byBiZSBwZXJmb3JtZWQgd2l0aG91dCB0aGUgb3ZlcmhlYWQgb2YgYSBj b21wbGV0ZSBUTEIgZmx1c2guDQo+PiDCoCAjIyMgYXN5bmMtc2hvdy1hbGwgKHg4NikNCj4+ IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvZmx1c2h0bGIuYyBiL3hlbi9hcmNoL3g4Ni9m bHVzaHRsYi5jDQo+PiBpbmRleCA1ZTJlZDUwZWM5Li40NzhhM2Y0OTYyIDEwMDY0NA0KPj4g LS0tIGEveGVuL2FyY2gveDg2L2ZsdXNodGxiLmMNCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9m bHVzaHRsYi5jDQo+PiBAQCAtMTMsNiArMTMsNyBAQA0KPj4gwqAgI2luY2x1ZGUgPHhlbi9z b2Z0aXJxLmg+DQo+PiDCoCAjaW5jbHVkZSA8YXNtL2NhY2hlLmg+DQo+PiDCoCAjaW5jbHVk ZSA8YXNtL2ZsdXNodGxiLmg+DQo+PiArI2luY2x1ZGUgPGFzbS9odm0vaHZtLmg+DQo+PiDC oCAjaW5jbHVkZSA8YXNtL2ludnBjaWQuaD4NCj4+IMKgICNpbmNsdWRlIDxhc20vbm9wcy5o Pg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQo+PiBAQCAtMTE5LDcgKzEyMCw2IEBA IHZvaWQgc3dpdGNoX2NyM19jcjQoc3RydWN0IHZjcHUgKnYsIHVuc2lnbmVkIGxvbmcgDQo+ PiBjcjMsIHVuc2lnbmVkIGxvbmcgY3I0KQ0KPj4gwqDCoMKgwqDCoCBpZiAoIHRsYl9jbGtf ZW5hYmxlZCApDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgdCA9IHByZV9mbHVzaCgpOw0KPj4g LcKgwqDCoCBodm1fZmx1c2hfZ3Vlc3RfdGxicygpOw0KPj4gwqDCoMKgwqDCoCBvbGRfY3I0 ID0gcmVhZF9jcjQoKTsNCj4+IMKgwqDCoMKgwqAgQVNTRVJUKCEob2xkX2NyNCAmIFg4Nl9D UjRfUENJREUpIHx8ICEob2xkX2NyNCAmIFg4Nl9DUjRfUEdFKSk7DQo+PiBAQCAtMjI0LDkg KzIyNCw2IEBAIHVuc2lnbmVkIGludCBmbHVzaF9hcmVhX2xvY2FsKGNvbnN0IHZvaWQgKnZh LCANCj4+IHVuc2lnbmVkIGludCBmbGFncykNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIGRvX3RsYl9mbHVzaCgpOw0KPj4gwqDCoMKgwqDCoCB9DQo+PiAtwqDCoMKgIGlmICgg ZmxhZ3MgJiBGTFVTSF9IVk1fQVNJRF9DT1JFICkNCj4+IC3CoMKgwqDCoMKgwqDCoCBodm1f Zmx1c2hfZ3Vlc3RfdGxicygpOw0KPj4gLQ0KPj4gwqDCoMKgwqDCoCBpZiAoIGZsYWdzICYg KEZMVVNIX0NBQ0hFX0VWSUNUIHwgRkxVU0hfQ0FDSEVfV1JJVEVCQUNLKSApDQo+PiDCoMKg wqDCoMKgIHsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBjb25zdCBzdHJ1Y3QgY3B1aW5mb194 ODYgKmMgPSAmY3VycmVudF9jcHVfZGF0YTsNCj4+IEBAIC0zMTYsMTggKzMxMywxMyBAQCB2 b2lkIGNhY2hlX3dyaXRlYmFjayhjb25zdCB2b2lkICphZGRyLCB1bnNpZ25lZCANCj4+IGlu dCBzaXplKQ0KPj4gwqDCoMKgwqDCoCBhc20gdm9sYXRpbGUgKCJzZmVuY2UiIDo6OiAibWVt b3J5Iik7DQo+PiDCoCB9DQo+PiAtdW5zaWduZWQgaW50IGd1ZXN0X2ZsdXNoX3RsYl9mbGFn cyhjb25zdCBzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gLXsNCj4+IC3CoMKgwqAgYm9vbCBzaGFk b3cgPSBwYWdpbmdfbW9kZV9zaGFkb3coZCk7DQo+PiAtwqDCoMKgIGJvb2wgYXNpZCA9IGlz X2h2bV9kb21haW4oZCkgJiYgKGNwdV9oYXNfc3ZtIHx8IHNoYWRvdyk7DQo+PiAtDQo+PiAt wqDCoMKgIHJldHVybiAoc2hhZG93ID8gRkxVU0hfVExCIDogMCkgfCAoYXNpZCA/IEZMVVNI X0hWTV9BU0lEX0NPUkUgOiAwKTsNCj4+IC19DQo+PiAtDQo+PiDCoCB2b2lkIGd1ZXN0X2Zs dXNoX3RsYl9tYXNrKGNvbnN0IHN0cnVjdCBkb21haW4gKmQsIGNvbnN0IGNwdW1hc2tfdCAN Cj4+ICptYXNrKQ0KPj4gwqAgew0KPj4gLcKgwqDCoCB1bnNpZ25lZCBpbnQgZmxhZ3MgPSBn dWVzdF9mbHVzaF90bGJfZmxhZ3MoZCk7DQo+PiArwqDCoMKgIHN0cnVjdCB2Y3B1ICp2Ow0K Pj4gKw0KPj4gK8KgwqDCoCBpZiAoIHBhZ2luZ19tb2RlX3NoYWRvdyhkKSApDQo+PiArwqDC oMKgwqDCoMKgwqAgZmx1c2hfdGxiX21hc2sobWFzayk7DQo+PiAtwqDCoMKgIGlmICggZmxh Z3MgKQ0KPj4gLcKgwqDCoMKgwqDCoMKgIGZsdXNoX21hc2sobWFzaywgZmxhZ3MpOw0KPj4g K8KgwqDCoCBmb3JfZWFjaF92Y3B1KGQsIHYpDQo+PiArwqDCoMKgwqDCoMKgwqAgdi0+YXJj aC5uZWVkc190bGJfZmx1c2ggPSB0cnVlOw0KPj4gwqAgfQ0KPj4gZGlmZiAtLWdpdCBhL3hl bi9hcmNoL3g4Ni9odm0vYXNpZC5jIGIveGVuL2FyY2gveDg2L2h2bS9hc2lkLmMNCj4+IGlu ZGV4IDkzNWNhZTM5MDEuLjFhMjExMjUxNjEgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC94 ODYvaHZtL2FzaWQuYw0KPj4gKysrIGIveGVuL2FyY2gveDg2L2h2bS9hc2lkLmMNCj4+IEBA IC01LDEzOCArNSwxMTUgQEANCj4+IMKgwqAgKiBDb3B5cmlnaHQgKGMpIDIwMDksIENpdHJp eCBTeXN0ZW1zLCBJbmMuDQo+PiDCoMKgICovDQo+PiArI2luY2x1ZGUgPHhlbi9lcnJuby5o Pg0KPj4gwqAgI2luY2x1ZGUgPHhlbi9pbml0Lmg+DQo+PiDCoCAjaW5jbHVkZSA8eGVuL2xp Yi5oPg0KPj4gwqAgI2luY2x1ZGUgPHhlbi9wYXJhbS5oPg0KPj4gLSNpbmNsdWRlIDx4ZW4v c2NoZWQuaD4NCj4+IC0jaW5jbHVkZSA8eGVuL3NtcC5oPg0KPj4gLSNpbmNsdWRlIDx4ZW4v cGVyY3B1Lmg+DQo+PiArI2luY2x1ZGUgPHhlbi9zcGlubG9jay5oPg0KPj4gKyNpbmNsdWRl IDx4ZW4veHZtYWxsb2MuaD4NCj4+ICsNCj4+ICsjaW5jbHVkZSA8YXNtL2JpdG9wcy5oPg0K Pj4gwqAgI2luY2x1ZGUgPGFzbS9odm0vYXNpZC5oPg0KPj4gwqAgLyogWGVuIGNvbW1hbmQt bGluZSBvcHRpb24gdG8gZW5hYmxlIEFTSURzICovDQo+PiDCoCBzdGF0aWMgYm9vbCBfX3Jl YWRfbW9zdGx5IG9wdF9hc2lkX2VuYWJsZWQgPSB0cnVlOw0KPj4gwqAgYm9vbGVhbl9wYXJh bSgiYXNpZCIsIG9wdF9hc2lkX2VuYWJsZWQpOw0KPj4gK2Jvb2wgX19yZWFkX21vc3RseSBh c2lkX2VuYWJsZWQgPSBmYWxzZTsNCj4+ICtzdGF0aWMgdW5zaWduZWQgbG9uZyBfX3JvX2Fm dGVyX2luaXQgKmFzaWRfYml0bWFwOw0KPj4gK3N0YXRpYyB1bnNpZ25lZCBsb25nIF9fcm9f YWZ0ZXJfaW5pdCBhc2lkX2NvdW50Ow0KPj4gK3N0YXRpYyBERUZJTkVfU1BJTkxPQ0soYXNp ZF9sb2NrKTsNCj4+ICsNCj4+IMKgIC8qDQo+PiAtICogQVNJRHMgcGFydGl0aW9uIHRoZSBw aHlzaWNhbCBUTEIuwqAgSW4gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gDQo+PiBBU0lE cyBhcmUNCj4+IC0gKiBpbnRyb2R1Y2VkIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIFRMQiBm bHVzaGVzLsKgIEVhY2ggdGltZSB0aGUgDQo+PiBndWVzdCdzDQo+PiAtICogdmlydHVhbCBh ZGRyZXNzIHNwYWNlIGNoYW5nZXMgKGUuZy4gZHVlIHRvIGFuIElOVkxQRywgTU9WLVRPLXtD UjMsIA0KPj4gQ1I0fQ0KPj4gLSAqIG9wZXJhdGlvbiksIGluc3RlYWQgb2YgZmx1c2hpbmcg dGhlIFRMQiwgYSBuZXcgQVNJRCBpcyBhc3NpZ25lZC4gIA0KPj4gVGhpcw0KPj4gLSAqIHJl ZHVjZXMgdGhlIG51bWJlciBvZiBUTEIgZmx1c2hlcyB0byBhdCBtb3N0IDEvI0FTSURzLsKg IFRoZSBiaWdnZXN0DQo+PiAtICogYWR2YW50YWdlIGlzIHRoYXQgaG90IHBhcnRzIG9mIHRo ZSBoeXBlcnZpc29yJ3MgY29kZSBhbmQgZGF0YSANCj4+IHJldGFpbiBpbg0KPj4gLSAqIHRo ZSBUTEIuDQo+PiAtICoNCj4+IMKgwqAgKiBTa2V0Y2ggb2YgdGhlIEltcGxlbWVudGF0aW9u Og0KPj4gKyAqIEFTSURzIGFyZSBhc3NpZ25lZCB1bmlxdWVseSBwZXIgZG9tYWluIGFuZCBk b2Vzbid0IGNoYW5nZSBkdXJpbmcgDQo+PiB0aGUgbGlmZWN5Y2xlIG9mIHRoZQ0KPj4gKyAq IGRvbWFpbi4gT25jZSB2Y3B1cyBhcmUgaW5pdGlhbGl6ZWQgYW5kIGFyZSB1cCwgd2UgYXNz aWduIHRoZSBzYW1lIA0KPj4gQVNJRCB0byBhbGwgdmNwdXMNCj4+ICsgKiBvZiB0aGF0IGRv bWFpbiBhdCB0aGUgZmlyc3QgVk1SVU4uIEluIG9yZGVyIHRvIHByb2Nlc3MgYSBUTEIgZmx1 c2ggDQo+PiBvbiBhIHZjcHUsIHdlIHNldA0KPj4gKyAqIG5lZWRzX3RsYl9mbHVzaCB0byBz Y2hlZHVsZSBhIFRMQiBmbHVzaCBmb3IgdGhlIG5leHQgVk1SVU4gKGUuZyANCj4+IHVzaW5n IHRsYiBjb250cm9sDQo+PiArICogZmllbGQgb2YgVk1DQikuDQo+PiDCoMKgICoNCj4+IC0g KiBBU0lEcyBhcmUgYSBDUFUtbG9jYWwgcmVzb3VyY2UuwqAgQXMgcHJlZW1wdGlvbiBvZiBB U0lEcyBpcyBub3QgDQo+PiBwb3NzaWJsZSwNCj4+IC0gKiBBU0lEcyBhcmUgYXNzaWduZWQg aW4gYSByb3VuZC1yb2JpbiBzY2hlbWUuwqAgVG8gbWluaW1pemUgdGhlIA0KPj4gb3Zlcmhl YWQgb2YNCj4+IC0gKiBBU0lEIGludmFsaWRhdGlvbiwgYXQgdGhlIHRpbWUgb2YgYSBUTEIg Zmx1c2gswqAgQVNJRHMgYXJlIHRhZ2dlZCANCj4+IHdpdGggYQ0KPj4gLSAqIDY0LWJpdCBn ZW5lcmF0aW9uLsKgIE9ubHkgb24gYSBnZW5lcmF0aW9uIG92ZXJmbG93IHRoZSBjb2RlIG5l ZWRzIHRvDQo+PiAtICogaW52YWxpZGF0ZSBhbGwgQVNJRCBpbmZvcm1hdGlvbiBzdG9yZWQg YXQgdGhlIFZDUFVzIHdpdGggYXJlIHJ1biANCj4+IG9uIHRoZQ0KPj4gLSAqIHNwZWNpZmlj IHBoeXNpY2FsIHByb2Nlc3Nvci7CoCBUaGlzIG92ZXJmbG93IGFwcGVhcnMgYWZ0ZXIgYWJv dXQgMl44MA0KPj4gLSAqIGhvc3QgcHJvY2Vzc29yIGN5Y2xlcywgc28gd2UgZG8gbm90IG9w dGltaXplIHRoaXMgY2FzZSwgYnV0IHNpbXBseSANCj4+IGRpc2FibGUNCj4+IC0gKiBBU0lE IHVzZWFnZSB0byByZXRhaW4gY29ycmVjdG5lc3MuDQo+PiArICogV2UgcmVzZXJ2ZSBBU0lE PTEgYXMgYmVpbmcgdGhlIEFTSUQgdXNlZCB3aGVuIG5vbmUgb3RoZXIgaXMgDQo+PiBhdmFp bGFibGUgKG9yIHdpdGggYXNpZA0KPj4gKyAqIHVzZSBkaXNhYmxlZCkuIE11bHRpcGxlcyBk b21haW5zIG1heSB1c2UgdGhpcyBBU0lELCB0aHVzIHdlIG5lZWQgDQo+PiB0byBzeXN0ZW1h dGljYWxseQ0KPj4gKyAqIGZsdXNoIHRoZSBUTEIgZm9yIHRoaXMgb25lIHdoZW4gc3dpdGNo aW5nIGJldHdlZW4gdkNQVXMgd2l0aCBBU0lEPTEuDQo+PiDCoMKgICovDQo+PiAtLyogUGVy LUNQVSBBU0lEIG1hbmFnZW1lbnQuICovDQo+PiAtc3RydWN0IGh2bV9hc2lkX2RhdGEgew0K Pj4gLcKgwqAgdWludDY0X3QgY29yZV9hc2lkX2dlbmVyYXRpb247DQo+PiAtwqDCoCB1aW50 MzJfdCBuZXh0X2FzaWQ7DQo+PiAtwqDCoCB1aW50MzJfdCBtYXhfYXNpZDsNCj4+IC3CoMKg IGJvb2wgZGlzYWJsZWQ7DQo+PiAtfTsNCj4+IC0NCj4+IC1zdGF0aWMgREVGSU5FX1BFUl9D UFUoc3RydWN0IGh2bV9hc2lkX2RhdGEsIGh2bV9hc2lkX2RhdGEpOw0KPj4gLQ0KPj4gLXZv aWQgaHZtX2FzaWRfaW5pdCh1bnNpZ25lZCBpbnQgbmFzaWRzKQ0KPj4gK2ludCBfX2luaXQg aHZtX2FzaWRfaW5pdCh1bnNpZ25lZCBsb25nIG5hc2lkcykNCj4+IMKgIHsNCj4+IC3CoMKg wqAgc3RhdGljIGludDhfdCBfX3JvX2FmdGVyX2luaXQgZ19kaXNhYmxlZCA9IC0xOw0KPj4g LcKgwqDCoCBzdHJ1Y3QgaHZtX2FzaWRfZGF0YSAqZGF0YSA9ICZ0aGlzX2NwdShodm1fYXNp ZF9kYXRhKTsNCj4+ICvCoMKgwqAgQVNTRVJUKG5hc2lkcyk7DQo+PiAtwqDCoMKgIGRhdGEt Pm1heF9hc2lkID0gbmFzaWRzIC0gMTsNCj4+IC3CoMKgwqAgZGF0YS0+ZGlzYWJsZWQgPSAh b3B0X2FzaWRfZW5hYmxlZCB8fCAobmFzaWRzIDw9IDEpOw0KPj4gK8KgwqDCoCBhc2lkX2Nv dW50ID0gbmFzaWRzOw0KPj4gK8KgwqDCoCBhc2lkX2VuYWJsZWQgPSBvcHRfYXNpZF9lbmFi bGVkICYmIChuYXNpZHMgPiAxKTsNCj4+IC3CoMKgwqAgaWYgKCBnX2Rpc2FibGVkIDwgMCAp DQo+PiAtwqDCoMKgIHsNCj4+IC3CoMKgwqDCoMKgwqDCoCBnX2Rpc2FibGVkID0gZGF0YS0+ ZGlzYWJsZWQ7DQo+PiAtwqDCoMKgwqDCoMKgwqAgcHJpbnRrKCJIVk06IEFTSURzICVzYWJs ZWRcbiIsIGRhdGEtPmRpc2FibGVkID8gImRpcyIgOiAiZW4iKTsNCj4+IC3CoMKgwqAgfQ0K Pj4gLcKgwqDCoCBlbHNlIGlmICggZ19kaXNhYmxlZCAhPSBkYXRhLT5kaXNhYmxlZCApDQo+ PiAtwqDCoMKgwqDCoMKgwqAgcHJpbnRrKCJIVk06IENQVSV1OiBBU0lEcyAlc2FibGVkXG4i LCBzbXBfcHJvY2Vzc29yX2lkKCksDQo+PiAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBkYXRhLT5kaXNhYmxlZCA/ICJkaXMiIDogImVuIik7DQo+PiArwqDCoMKgIGFzaWRfYml0 bWFwID0geHZ6YWxsb2NfYXJyYXkodW5zaWduZWQgbG9uZywgDQo+PiBCSVRTX1RPX0xPTkdT KGFzaWRfY291bnQgKyAxKSk7DQo+PiArwqDCoMKgIGlmICggIWFzaWRfYml0bWFwICkNCj4+ ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4gLUVOT01FTTsNCj4gDQo+IFNob3VsZCB0aGVyZSBi ZSBhIHNhbml0eSBjaGVjayB0byBhdm9pZCBhbiBleGNlc3NpdmUgYWxsb2NhdGlvbj8gRS5n LiBJZg0KPiBydW5uaW5nIHVuZGVyIGFub3RoZXIgaHlwZXJ2aXNvciwgaXQgbWlnaHQgc2V0 IG5hc2lkcyB0byB+MCB3aGlsZSB3aXRoIA0KPiBvbmUgcGVyDQo+IGRvbWFpbiB3ZSBuZWVk IG5vIG1vcmUgdGhhbiB+NjRrLg0KPiANCg0KSW5kZWVkLCBJIGRpZG4ndCBjb25zaWRlciB0 aGF0IEFNRCBoYWQgKGFuZCBlbnVtZXJhdGVzKSAzMi1iaXRzIEFTSURzLiANCk9ubHkgSW50 ZWwgdXNlcyAxNi1iaXRzIFZQSURzLg0KDQpMaW1pdGluZyB0byA2NGsgc2VlbXMgd2lzZSwg dGhlIHJlbWFpbmluZyBxdWVzdGlvbiBpcyB0aGF0IEknbSBub3Qgc3VyZSANCmlmIHdlIHdh bnQgdG8gbWFrZSB0aGF0IGNvbmZpZ3VyYWJsZS4NCg0KPj4gLcKgwqDCoCAvKiBaZXJvIGlu ZGljYXRlcyAnaW52YWxpZCBnZW5lcmF0aW9uJywgc28gd2Ugc3RhcnQgdGhlIGNvdW50IGF0 IA0KPj4gb25lLiAqLw0KPj4gLcKgwqDCoCBkYXRhLT5jb3JlX2FzaWRfZ2VuZXJhdGlvbiA9 IDE7DQo+PiArwqDCoMKgIHByaW50aygiSFZNOiBBU0lEcyAlc2FibGVkIChjb3VudD0lbHUp XG4iLCBhc2lkX2VuYWJsZWQgPyAiZW4iIDogDQo+PiAiZGlzIiwgYXNpZF9jb3VudCk7DQo+ PiAtwqDCoMKgIC8qIFplcm8gaW5kaWNhdGVzICdBU0lEcyBkaXNhYmxlZCcsIHNvIHdlIHN0 YXJ0IHRoZSBjb3VudCBhdCBvbmUuICovDQo+PiAtwqDCoMKgIGRhdGEtPm5leHRfYXNpZCA9 IDE7DQo+PiAtfQ0KPj4gK8KgwqDCoCAvKiBBU0lEIDAgYW5kIDEgYXJlIHJlc2VydmVkLCBt YXJrIGl0IGFzIHBlcm1hbmVudGx5IHVzZWQgKi8NCj4+ICvCoMKgwqAgc2V0X2JpdCgwLCBh c2lkX2JpdG1hcCk7DQo+PiArwqDCoMKgIHNldF9iaXQoMSwgYXNpZF9iaXRtYXApOw0KPj4g LXZvaWQgaHZtX2FzaWRfZmx1c2hfdmNwdV9hc2lkKHN0cnVjdCBodm1fdmNwdV9hc2lkICph c2lkKQ0KPj4gLXsNCj4+IC3CoMKgwqAgd3JpdGVfYXRvbWljKCZhc2lkLT5nZW5lcmF0aW9u LCAwKTsNCj4+ICvCoMKgwqAgcmV0dXJuIDA7DQo+PiDCoCB9DQo+PiAtdm9pZCBodm1fYXNp ZF9mbHVzaF92Y3B1KHN0cnVjdCB2Y3B1ICp2KQ0KPj4gK2ludCBodm1fYXNpZF9hbGxvYyhz dHJ1Y3QgaHZtX2FzaWQgKmFzaWQpDQo+PiDCoCB7DQo+IA0KPiBDYW4gdGhpcyBiZSBpbXBs ZW1lbnRlZCBpbiB0ZXJtcyBvZiBodm1fYXNpZF9hbGxvY19yYW5nZSgpIGFzIHRoZXNlIA0K PiBmdW5jdGlvbnMNCj4gc2VlbSB0byBiZSBtb3N0bHkgZHVwbGljYXRlZD8NCj4gDQoNCnll cw0KDQo+PiAtwqDCoMKgIGh2bV9hc2lkX2ZsdXNoX3ZjcHVfYXNpZCgmdi0+YXJjaC5odm0u bjFhc2lkKTsNCj4+IC3CoMKgwqAgaHZtX2FzaWRfZmx1c2hfdmNwdV9hc2lkKCZ2Y3B1X25l c3RlZGh2bSh2KS5udl9uMmFzaWQpOw0KPj4gLX0NCj4+ICvCoMKgwqAgdW5zaWduZWQgbG9u ZyBuZXdfYXNpZDsNCj4+IC12b2lkIGh2bV9hc2lkX2ZsdXNoX2NvcmUodm9pZCkNCj4+IC17 DQo+PiAtwqDCoMKgIHN0cnVjdCBodm1fYXNpZF9kYXRhICpkYXRhID0gJnRoaXNfY3B1KGh2 bV9hc2lkX2RhdGEpOw0KPj4gK8KgwqDCoCBpZiAoICFhc2lkX2VuYWJsZWQgKQ0KPj4gK8Kg wqDCoCB7DQo+PiArwqDCoMKgwqDCoMKgwqAgYXNpZC0+YXNpZCA9IDE7DQo+PiArwqDCoMKg wqDCoMKgwqAgcmV0dXJuIDA7DQo+PiArwqDCoMKgIH0NCj4+IC3CoMKgwqAgaWYgKCBkYXRh LT5kaXNhYmxlZCApDQo+PiAtwqDCoMKgwqDCoMKgwqAgcmV0dXJuOw0KPj4gK8KgwqDCoCBz cGluX2xvY2soJmFzaWRfbG9jayk7DQo+PiArwqDCoMKgIG5ld19hc2lkID0gZmluZF9maXJz dF96ZXJvX2JpdChhc2lkX2JpdG1hcCwgYXNpZF9jb3VudCk7DQo+PiArwqDCoMKgIGlmICgg bmV3X2FzaWQgPiBhc2lkX2NvdW50ICkNCj4+ICvCoMKgwqDCoMKgwqDCoCByZXR1cm4gLUVO T1NQQzsNCj4+IC3CoMKgwqAgaWYgKCBsaWtlbHkoKytkYXRhLT5jb3JlX2FzaWRfZ2VuZXJh dGlvbiAhPSAwKSApDQo+PiAtwqDCoMKgwqDCoMKgwqAgcmV0dXJuOw0KPj4gK8KgwqDCoCBz ZXRfYml0KG5ld19hc2lkLCBhc2lkX2JpdG1hcCk7DQo+PiAtwqDCoMKgIC8qDQo+PiAtwqDC oMKgwqAgKiBBU0lEIGdlbmVyYXRpb25zIGFyZSA2NCBiaXQuwqAgT3ZlcmZsb3cgb2YgZ2Vu ZXJhdGlvbnMgbmV2ZXIgDQo+PiBoYXBwZW5zLg0KPj4gLcKgwqDCoMKgICogRm9yIHNhZmV0 eSwgd2Ugc2ltcGx5IGRpc2FibGUgQVNJRHMsIHNvIGNvcnJlY3RuZXNzIGlzIA0KPj4gZXN0 YWJsaXNoZWQ7IGl0DQo+PiAtwqDCoMKgwqAgKiBvbmx5IHJ1bnMgYSBiaXQgc2xvd2VyLg0K Pj4gLcKgwqDCoMKgICovDQo+PiAtwqDCoMKgIHByaW50aygiSFZNOiBBU0lEIGdlbmVyYXRp b24gb3ZlcnJ1bi4gRGlzYWJsaW5nIEFTSURzLlxuIik7DQo+PiAtwqDCoMKgIGRhdGEtPmRp c2FibGVkID0gMTsNCj4+ICvCoMKgwqAgYXNpZC0+YXNpZCA9IG5ld19hc2lkOw0KPj4gK8Kg wqDCoCBzcGluX3VubG9jaygmYXNpZF9sb2NrKTsNCj4+ICvCoMKgwqAgcmV0dXJuIDA7DQo+ PiDCoCB9DQo+PiAtYm9vbCBodm1fYXNpZF9oYW5kbGVfdm1lbnRlcihzdHJ1Y3QgaHZtX3Zj cHVfYXNpZCAqYXNpZCkNCj4+ICtpbnQgaHZtX2FzaWRfYWxsb2NfcmFuZ2Uoc3RydWN0IGh2 bV9hc2lkICphc2lkLCB1bnNpZ25lZCBsb25nIG1pbiwgDQo+PiB1bnNpZ25lZCBsb25nIG1h eCkNCj4+IMKgIHsNCj4+IC3CoMKgwqAgc3RydWN0IGh2bV9hc2lkX2RhdGEgKmRhdGEgPSAm dGhpc19jcHUoaHZtX2FzaWRfZGF0YSk7DQo+PiArwqDCoMKgIHVuc2lnbmVkIGxvbmcgbmV3 X2FzaWQ7DQo+PiArDQo+PiArwqDCoMKgIGlmICggV0FSTl9PTihtaW4gPj0gYXNpZF9jb3Vu dCkgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybiAtRUlOVkFMOw0KPj4gLcKgwqDCoCAv KiBPbiBlcnJhdHVtICMxNzAgc3lzdGVtcyB3ZSBtdXN0IGZsdXNoIHRoZSBUTEIuDQo+PiAt wqDCoMKgwqAgKiBHZW5lcmF0aW9uIG92ZXJydW5zIGFyZSB0YWtlbiBoZXJlLCB0b28uICov DQo+PiAtwqDCoMKgIGlmICggZGF0YS0+ZGlzYWJsZWQgKQ0KPj4gLcKgwqDCoMKgwqDCoMKg IGdvdG8gZGlzYWJsZWQ7DQo+PiArwqDCoMKgIGlmICggIWFzaWRfZW5hYmxlZCApDQo+PiAr wqDCoMKgwqDCoMKgwqAgcmV0dXJuIC1FT1BOT1RTVVBQOw0KPj4gLcKgwqDCoCAvKiBUZXN0 IGlmIFZDUFUgaGFzIHZhbGlkIEFTSUQuICovDQo+PiAtwqDCoMKgIGlmICggcmVhZF9hdG9t aWMoJmFzaWQtPmdlbmVyYXRpb24pID09IGRhdGEtPmNvcmVfYXNpZF9nZW5lcmF0aW9uICkN Cj4+IC3CoMKgwqDCoMKgwqDCoCByZXR1cm4gMDsNCj4+ICvCoMKgwqAgc3Bpbl9sb2NrKCZh c2lkX2xvY2spOw0KPj4gK8KgwqDCoCBuZXdfYXNpZCA9IGZpbmRfbmV4dF96ZXJvX2JpdChh c2lkX2JpdG1hcCwgYXNpZF9jb3VudCwgbWluKTsNCj4+ICvCoMKgwqAgaWYgKCBuZXdfYXNp ZCA+IG1heCB8fCBuZXdfYXNpZCA+IGFzaWRfY291bnQgKQ0KPj4gK8KgwqDCoMKgwqDCoMKg IHJldHVybiAtRU5PU1BDOw0KPj4gLcKgwqDCoCAvKiBJZiB0aGVyZSBhcmUgbm8gZnJlZSBB U0lEcywgbmVlZCB0byBnbyB0byBhIG5ldyBnZW5lcmF0aW9uICovDQo+PiAtwqDCoMKgIGlm ICggdW5saWtlbHkoZGF0YS0+bmV4dF9hc2lkID4gZGF0YS0+bWF4X2FzaWQpICkNCj4+IC3C oMKgwqAgew0KPj4gLcKgwqDCoMKgwqDCoMKgIGh2bV9hc2lkX2ZsdXNoX2NvcmUoKTsNCj4+ IC3CoMKgwqDCoMKgwqDCoCBkYXRhLT5uZXh0X2FzaWQgPSAxOw0KPj4gLcKgwqDCoMKgwqDC oMKgIGlmICggZGF0YS0+ZGlzYWJsZWQgKQ0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg Z290byBkaXNhYmxlZDsNCj4+IC3CoMKgwqAgfQ0KPj4gK8KgwqDCoCBzZXRfYml0KG5ld19h c2lkLCBhc2lkX2JpdG1hcCk7DQo+PiAtwqDCoMKgIC8qIE5vdyBndWFyYW50ZWVkIHRvIGJl IGEgZnJlZSBBU0lELiAqLw0KPj4gLcKgwqDCoCBhc2lkLT5hc2lkID0gZGF0YS0+bmV4dF9h c2lkKys7DQo+PiAtwqDCoMKgIHdyaXRlX2F0b21pYygmYXNpZC0+Z2VuZXJhdGlvbiwgZGF0 YS0+Y29yZV9hc2lkX2dlbmVyYXRpb24pOw0KPj4gK8KgwqDCoCBhc2lkLT5hc2lkID0gbmV3 X2FzaWQ7DQo+PiArwqDCoMKgIHNwaW5fdW5sb2NrKCZhc2lkX2xvY2spOw0KPj4gK8KgwqDC oCByZXR1cm4gMDsNCj4+ICt9DQo+PiAtwqDCoMKgIC8qDQo+PiAtwqDCoMKgwqAgKiBXaGVu IHdlIGFzc2lnbiBBU0lEIDEsIGZsdXNoIGFsbCBUTEIgZW50cmllcyBhcyB3ZSBhcmUgDQo+ PiBzdGFydGluZyBhIG5ldw0KPj4gLcKgwqDCoMKgICogZ2VuZXJhdGlvbiwgYW5kIGFsbCBv bGQgQVNJRCBhbGxvY2F0aW9ucyBhcmUgbm93IHN0YWxlLg0KPj4gLcKgwqDCoMKgICovDQo+ PiAtwqDCoMKgIHJldHVybiAoYXNpZC0+YXNpZCA9PSAxKTsNCj4+ICt2b2lkIGh2bV9hc2lk X2ZyZWUoc3RydWN0IGh2bV9hc2lkICphc2lkKQ0KPj4gK3sNCj4+ICvCoMKgwqAgQVNTRVJU KCBhc2lkLT5hc2lkICk7DQo+PiAtIGRpc2FibGVkOg0KPj4gLcKgwqDCoCBhc2lkLT5hc2lk ID0gMDsNCj4+IC3CoMKgwqAgcmV0dXJuIDA7DQo+PiArwqDCoMKgIGlmICggIWFzaWRfZW5h YmxlZCB8fCBhc2lkLT5hc2lkID09IDEgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybjsN Cj4+ICsNCj4+ICvCoMKgwqAgQVNTRVJUKCBhc2lkLT5hc2lkIDwgYXNpZF9jb3VudCApOw0K Pj4gKw0KPj4gK8KgwqDCoCBzcGluX2xvY2soJmFzaWRfbG9jayk7DQo+PiArwqDCoMKgIFdB Uk5fT04oIXRlc3RfYml0KGFzaWQtPmFzaWQsIGFzaWRfYml0bWFwKSk7DQo+PiArwqDCoMKg IGNsZWFyX2JpdChhc2lkLT5hc2lkLCBhc2lkX2JpdG1hcCk7DQo+PiArwqDCoMKgIHNwaW5f dW5sb2NrKCZhc2lkX2xvY2spOw0KPj4gwqAgfQ0KPj4gwqAgLyoNCj4+IGRpZmYgLS1naXQg YS94ZW4vYXJjaC94ODYvaHZtL2VtdWxhdGUuYyBiL3hlbi9hcmNoL3g4Ni9odm0vZW11bGF0 ZS5jDQo+PiBpbmRleCAyZWZiMWQ0ZjA4Li4yNTlhMmIwY2FmIDEwMDY0NA0KPj4gLS0tIGEv eGVuL2FyY2gveDg2L2h2bS9lbXVsYXRlLmMNCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9odm0v ZW11bGF0ZS5jDQo+PiBAQCAtMjY1NSw3ICsyNjU1LDcgQEAgc3RhdGljIGludCBjZl9jaGVj ayBodm1lbXVsX3RsYl9vcCgNCj4+IMKgwqDCoMKgwqAgY2FzZSB4ODZlbXVsX2ludnBjaWQ6 DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCB4ODZlbXVsX2ludnBjaWRfdHlwZShhdXgp ICE9IFg4Nl9JTlZQQ0lEX0lORElWX0FERFIgKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHsN Cj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGh2bV9hc2lkX2ZsdXNoX3ZjcHUoY3VycmVu dCk7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjdXJyZW50LT5hcmNoLm5lZWRzX3Rs Yl9mbHVzaCA9IHRydWU7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBicmVhazsN Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB9DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgYXV4ID0g eDg2ZW11bF9pbnZwY2lkX3BjaWQoYXV4KTsNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94 ODYvaHZtL2h2bS5jIGIveGVuL2FyY2gveDg2L2h2bS9odm0uYw0KPj4gaW5kZXggYTc1Y2Ni NTdiZi4uMjgzZGNhZDY5MSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vaHZt LmMNCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMNCj4+IEBAIC03MTUsNiArNzE1 LDEwIEBAIGludCBodm1fZG9tYWluX2luaXRpYWxpc2Uoc3RydWN0IGRvbWFpbiAqZCwNCj4+ IMKgwqDCoMKgwqAgaWYgKCByYyApDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgZ290byBmYWls MjsNCj4+ICvCoMKgwqAgcmMgPSBodm1fYXNpZF9hbGxvYygmZC0+YXJjaC5odm0uYXNpZCk7 DQo+PiArwqDCoMKgIGlmICggcmMgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIGdvdG8gZmFpbDI7 DQo+PiArDQo+IA0KPiBEb24ndCB5b3UgbmVlZCB0byBmcmVlIHRoZSBhc2lkIGlmIHRoZSBz dWJzZXF1ZW50IGZ1bmN0aW9uIGNhbGwocykgZmFpbD8NCj4gDQoNClllcywgdGhlIGh2bV9m cmVlX2FzaWQgY2FsbCBpcyBpbiBodm1fZG9tYWluX2Rlc3Ryb3koKSwgSSBndWVzcyBpdCB3 b3VsZCANCmJlIGJldHRlciB0byBoYXZlIGl0IGluIGh2bV9kb21haW5fcmVsaW5xdWlzaF9y ZXNvdXJjZXMoKSBzbyB0aGF0IGl0J3MgDQpjYWxsZWQgYnkgdGhlIGVycm9yIGhhbmRsaW5n IG9mIGh2bV9kb21haW5faW5pdGlhbGlzZSgpIHRvby4NCg0KPj4gwqDCoMKgwqDCoCByYyA9 IGFsdGVybmF0aXZlX2NhbGwoaHZtX2Z1bmNzLmRvbWFpbl9pbml0aWFsaXNlLCBkKTsNCj4+ IMKgwqDCoMKgwqAgaWYgKCByYyAhPSAwICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBnb3Rv IGZhaWwyOw0KPj4gQEAgLTc5NSw3ICs3OTksNyBAQCB2b2lkIGh2bV9kb21haW5fZGVzdHJv eShzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGxpc3RfZGVsKCZp b3BvcnQtPmxpc3QpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHhmcmVlKGlvcG9ydCk7DQo+ PiDCoMKgwqDCoMKgIH0NCj4+IC0NCj4+ICvCoMKgwqAgaHZtX2FzaWRfZnJlZSgmZC0+YXJj aC5odm0uYXNpZCk7DQo+PiDCoMKgwqDCoMKgIGRlc3Ryb3lfdnBjaV9tbWNmZyhkKTsNCj4+ IMKgIH0NCj4+IEBAIC0xNjEzLDcgKzE2MTcsNyBAQCBpbnQgaHZtX3ZjcHVfaW5pdGlhbGlz ZShzdHJ1Y3QgdmNwdSAqdikNCj4+IMKgwqDCoMKgwqAgaW50IHJjOw0KPj4gwqDCoMKgwqDC oCBzdHJ1Y3QgZG9tYWluICpkID0gdi0+ZG9tYWluOw0KPj4gLcKgwqDCoCBodm1fYXNpZF9m bHVzaF92Y3B1KHYpOw0KPj4gK8KgwqDCoCB2LT5hcmNoLm5lZWRzX3RsYl9mbHVzaCA9IHRy dWU7DQo+PiDCoMKgwqDCoMKgIHNwaW5fbG9ja19pbml0KCZ2LT5hcmNoLmh2bS50bV9sb2Nr KTsNCj4+IMKgwqDCoMKgwqAgSU5JVF9MSVNUX0hFQUQoJnYtPmFyY2guaHZtLnRtX2xpc3Qp Ow0KPj4gQEAgLTQwODUsNiArNDA4OSwxMSBAQCBzdGF0aWMgdm9pZCBodm1fczNfcmVzdW1l KHN0cnVjdCBkb21haW4gKmQpDQo+PiDCoMKgwqDCoMKgIH0NCj4+IMKgIH0NCj4+ICtpbnQg aHZtX2ZsdXNoX3RsYihjb25zdCB1bnNpZ25lZCBsb25nICp2Y3B1X2JpdG1hcCkNCj4+ICt7 DQo+PiArwqDCoMKgIHJldHVybiBjdXJyZW50LT5kb21haW4tPmFyY2gucGFnaW5nLmZsdXNo X3RsYih2Y3B1X2JpdG1hcCk7DQo+PiArfQ0KPj4gKw0KPj4gwqAgc3RhdGljIGludCBodm1v cF9mbHVzaF90bGJfYWxsKHZvaWQpDQo+PiDCoCB7DQo+PiDCoMKgwqDCoMKgIGlmICggIWlz X2h2bV9kb21haW4oY3VycmVudC0+ZG9tYWluKSApDQo+PiBAQCAtNTQ2MSw0ICs1NDcwLDMg QEAgaW50IGh2bV9jb3B5X2NvbnRleHRfYW5kX3BhcmFtcyhzdHJ1Y3QgZG9tYWluIA0KPj4g KmRzdCwgc3RydWN0IGRvbWFpbiAqc3JjKQ0KPj4gwqDCoCAqIGluZGVudC10YWJzLW1vZGU6 IG5pbA0KPj4gwqDCoCAqIEVuZDoNCj4+IMKgwqAgKi8NCj4+IC0NCj4+IGRpZmYgLS1naXQg YS94ZW4vYXJjaC94ODYvaHZtL25lc3RlZGh2bS5jIGIveGVuL2FyY2gveDg2L2h2bS9uZXN0 ZWRodm0uYw0KPj4gaW5kZXggYmRkZDc3ZDgxMC4uNjFlODY2Yjc3MSAxMDA2NDQNCj4+IC0t LSBhL3hlbi9hcmNoL3g4Ni9odm0vbmVzdGVkaHZtLmMNCj4+ICsrKyBiL3hlbi9hcmNoL3g4 Ni9odm0vbmVzdGVkaHZtLmMNCj4+IEBAIC0xMiw2ICsxMiw3IEBADQo+PiDCoCAjaW5jbHVk ZSA8YXNtL2h2bS9uZXN0ZWRodm0uaD4NCj4+IMKgICNpbmNsdWRlIDxhc20vZXZlbnQuaD7C oCAvKiBmb3IgbG9jYWxfZXZlbnRfZGVsaXZlcnlfKGVufGRpcylhYmxlICovDQo+PiDCoCAj aW5jbHVkZSA8YXNtL3BhZ2luZy5oPiAvKiBmb3IgcGFnaW5nX21vZGVfaGFwKCkgKi8NCj4+ ICsjaW5jbHVkZSA8YXNtL2h2bS9hc2lkLmg+DQo+PiDCoCBzdGF0aWMgdW5zaWduZWQgbG9u ZyAqc2hhZG93X2lvX2JpdG1hcFszXTsNCj4+IEBAIC0zNiwxMyArMzcsMTEgQEAgbmVzdGVk aHZtX3ZjcHVfcmVzZXQoc3RydWN0IHZjcHUgKnYpDQo+PiDCoMKgwqDCoMKgIGh2bV91bm1h cF9ndWVzdF9mcmFtZShudi0+bnZfdnZtY3gsIDEpOw0KPj4gwqDCoMKgwqDCoCBudi0+bnZf dnZtY3ggPSBOVUxMOw0KPj4gwqDCoMKgwqDCoCBudi0+bnZfdnZtY3hhZGRyID0gSU5WQUxJ RF9QQUREUjsNCj4+IC3CoMKgwqAgbnYtPm52X2ZsdXNocDJtID0gMDsNCj4+ICvCoMKgwqAg bnYtPm52X2ZsdXNocDJtID0gdHJ1ZTsNCj4+IMKgwqDCoMKgwqAgbnYtPm52X3AybSA9IE5V TEw7DQo+PiDCoMKgwqDCoMKgIG52LT5zdGFsZV9ucDJtID0gZmFsc2U7DQo+PiDCoMKgwqDC oMKgIG52LT5ucDJtX2dlbmVyYXRpb24gPSAwOw0KPj4gLcKgwqDCoCBodm1fYXNpZF9mbHVz aF92Y3B1X2FzaWQoJm52LT5udl9uMmFzaWQpOw0KPj4gLQ0KPj4gwqDCoMKgwqDCoCBhbHRl cm5hdGl2ZV92Y2FsbChodm1fZnVuY3Mubmh2bV92Y3B1X3Jlc2V0LCB2KTsNCj4+IMKgwqDC oMKgwqAgLyogdmNwdSBpcyBpbiBob3N0IG1vZGUgKi8NCj4+IEBAIC04Niw3ICs4NSw3IEBA IHN0YXRpYyB2b2lkIGNmX2NoZWNrIG5lc3RlZGh2bV9mbHVzaHRsYl9pcGkodm9pZCAqaW5m bykNCj4+IMKgwqDCoMKgwqDCoCAqIFRoaXMgaXMgY2hlYXBlciB0aGFuIGZsdXNoX3RsYl9s b2NhbCgpIGFuZCBoYXMNCj4+IMKgwqDCoMKgwqDCoCAqIHRoZSBzYW1lIGRlc2lyZWQgZWZm ZWN0Lg0KPj4gwqDCoMKgwqDCoMKgICovDQo+PiAtwqDCoMKgIGh2bV9hc2lkX2ZsdXNoX2Nv cmUoKTsNCj4+ICvCoMKgwqAgV0FSTl9PTihodm1fZmx1c2hfdGxiKE5VTEwpKTsNCj4gDQo+ IElJVUMsIG5lc3RlZGh2bV92bWN4X2ZsdXNodGxiKCkgSVBJcyBtdWx0aXBsZSBwQ1BVcyB0 byBydW4NCj4gbmVzdGVkaHZtX2ZsdXNodGxiX2lwaSgpIGFuZCBlYWNoIG9mIHRob3NlIGNh bGxzIGZsdXNoZXMgdGhlIFRMQiBvZiANCj4gZXZlcnkgdkNQVQ0KPiBpbiB3aGF0ZXZlciBk b21haW4gImN1cnJlbnQiIHBvaW50cyB0byBhbmQgdGhlbiB0cmlnZ2VycyBhIFZNRVhJVCBv biB0aGUNCj4gcmVsZXZhbnQgcENQVXMuDQo+IA0KPiAoT3IgY3VycmVudCBtaWdodCBiZSBh IHNoYWRvdyBkb21haW4gb3IgdGhlIGlkbGUgZG9tYWluIGFuZCBkbyBzb21ldGhpbmcNCj4g ZGlmZmVyZW50Li4uKQ0KPiANCj4gSXMgdGhpcyB3aGF0IHlvdSBpbnRlbmRlZCBiZWNhdXNl IGl0IGRvZXNuJ3Qgc2VlbSByaWdodCB0byBtZT8NCj4gDQoNClRoZSBuZXN0ZWQgbG9naWMg cHJvYmFibHkgZG9uJ3QgbWF0Y2ggd2hhdCBpcyBpbnRlbmRlZCAoaXQncyBtb3N0bHkgYSAN CmF0dGVtcHQgYXQgbWFraW5nIHRoaW5ncyBjb21waWxlKS4NCg0KQnV0IG92ZXJhbGwsIElJ VUMsIHRoaXMgZnVuY3Rpb24gaXMgY2FsbGVkIGFmdGVyIHdlIGludmFsaWRhdGVkIHRoZSAN Cm5lc3RlZCBwMm0gdGFibGUuIEkgaGFkIGluIG1pbmQgcmV0aGlua2luZyB0aGUgVExCIGZs dXNoaW5nIG1vZGVsIA0KdG93YXJkcyBiZXR0ZXIgc3BsaXRpbmcgU0xBVC1yZWxhdGVkIGZs dXNoZXMgYW5kIGd1ZXN0IHNvIHRoYXQgaXQgDQpkb2Vzbid0IGVuZCB1cCBhd2t3YXJkLg0K DQo+PiDCoMKgwqDCoMKgIHZjcHVfbmVzdGVkaHZtKHYpLm52X3AybSA9IE5VTEw7DQo+PiDC oMKgwqDCoMKgIHZjcHVfbmVzdGVkaHZtKHYpLnN0YWxlX25wMm0gPSB0cnVlOw0KPj4gwqAg fQ0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL2FzaWQuYyBiL3hlbi9h cmNoL3g4Ni9odm0vc3ZtL2FzaWQuYw0KPj4gaW5kZXggNTNhYTVkMDUxMi4uNDRkMjEzODg5 NSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL2FzaWQuYw0KPj4gKysr IGIveGVuL2FyY2gveDg2L2h2bS9zdm0vYXNpZC5jDQo+PiBAQCAtMSwzOSArMSw0NiBAQA0K Pj4gwqAgLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KPj4g wqAgLyoNCj4+IC0gKiBhc2lkLmM6IGhhbmRsaW5nIEFTSURzIGluIFNWTS4NCj4+ICsgKiBh c2lkLmM6IGhhbmRsaW5nIEFTSURzL1ZQSURzLg0KPj4gwqDCoCAqIENvcHlyaWdodCAoYykg MjAwNywgQWR2YW5jZWQgTWljcm8gRGV2aWNlcywgSW5jLg0KPj4gwqDCoCAqLw0KPj4gKyNp bmNsdWRlIDx4ZW4vY3B1bWFzay5oPg0KPj4gKw0KPj4gwqAgI2luY2x1ZGUgPGFzbS9hbWQu aD4NCj4+IMKgICNpbmNsdWRlIDxhc20vaHZtL25lc3RlZGh2bS5oPg0KPj4gwqAgI2luY2x1 ZGUgPGFzbS9odm0vc3ZtLmg+DQo+PiArI2luY2x1ZGUgPGFzbS9wcm9jZXNzb3IuaD4NCj4+ IMKgICNpbmNsdWRlICJzdm0uaCINCj4+IMKgICNpbmNsdWRlICJ2bWNiLmgiDQo+PiAtdm9p ZCBzdm1fYXNpZF9pbml0KGNvbnN0IHN0cnVjdCBjcHVpbmZvX3g4NiAqYykNCj4+ICt2b2lk IF9faW5pdCBzdm1fYXNpZF9pbml0KHZvaWQpDQo+PiDCoCB7DQo+PiAtwqDCoMKgIHVuc2ln bmVkIGludCBuYXNpZHMgPSAwOw0KPj4gK8KgwqDCoCB1bnNpZ25lZCBpbnQgY3B1LCBuYXNp ZHMgPSBjcHVpZF9lYngoMHg4MDAwMDAwYVUpOw0KPj4gKw0KPj4gK8KgwqDCoCBpZiAoICFu YXNpZHMgKQ0KPj4gK8KgwqDCoMKgwqDCoMKgIG5hc2lkcyA9IDE7DQo+PiAtwqDCoMKgIC8q IENoZWNrIGZvciBlcnJhdHVtICMxNzAsIGFuZCBsZWF2ZSBBU0lEcyBkaXNhYmxlZCBpZiBp dCdzIA0KPj4gcHJlc2VudC4gKi8NCj4+IC3CoMKgwqAgaWYgKCAhY3B1X2hhc19hbWRfZXJy YXR1bShjLCBBTURfRVJSQVRVTV8xNzApICkNCj4+IC3CoMKgwqDCoMKgwqDCoCBuYXNpZHMg PSBjcHVpZF9lYngoMHg4MDAwMDAwYVUpOw0KPj4gK8KgwqDCoCBmb3JfZWFjaF9wcmVzZW50 X2NwdShjcHUpDQo+PiArwqDCoMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoCAvKiBDaGVjayBm b3IgZXJyYXR1bSAjMTcwLCBhbmQgbGVhdmUgQVNJRHMgZGlzYWJsZWQgaWYgaXQncyANCj4+ IHByZXNlbnQuICovDQo+PiArwqDCoMKgwqDCoMKgwqAgaWYgKCBjcHVfaGFzX2FtZF9lcnJh dHVtKCZjcHVfZGF0YVtjcHVdLCBBTURfRVJSQVRVTV8xNzApICkNCj4+ICvCoMKgwqDCoMKg wqDCoCB7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwcmludGsoWEVOTE9HX1dBUk5J TkcgIkRpc2FibGluZyBBU0lEIGR1ZSB0byBlcnJhdGEgMTcwIA0KPj4gb24gQ1BVJXVcbiIs IGNwdSk7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBuYXNpZHMgPSAxOw0KPj4gK8Kg wqDCoMKgwqDCoMKgIH0NCj4+ICvCoMKgwqAgfQ0KPj4gLcKgwqDCoCBodm1fYXNpZF9pbml0 KG5hc2lkcyk7DQo+PiArwqDCoMKgIEJVR19PTihodm1fYXNpZF9pbml0KG5hc2lkcykpOw0K Pj4gwqAgfQ0KPj4gwqAgLyoNCj4+IC0gKiBDYWxsZWQgZGlyZWN0bHkgYmVmb3JlIFZNUlVO LsKgIENoZWNrcyBpZiB0aGUgVkNQVSBuZWVkcyBhIG5ldyBBU0lELA0KPj4gLSAqIGFzc2ln bnMgaXQsIGFuZCBpZiByZXF1aXJlZCwgaXNzdWVzIHJlcXVpcmVkIFRMQiBmbHVzaGVzLg0K Pj4gKyAqIENhbGxlZCBkaXJlY3RseSBhdCB0aGUgZmlyc3QgVk1SVU4vVk1FTlRFUiBvZiBh IHZjcHUgdG8gYXNzaWduIHRoZSANCj4+IEFTSUQvVlBJRC4NCj4gDQo+IE1lbnRpb25pbmcg Vk1FTlRFUiBhbmQgVlBJRCBpcyBub3QgcmVsZXZlbnQgaW4gdGhpcyBBTUQgY29kZS4NCj4g DQoNCnllcw0KDQo+PiDCoMKgICovDQo+PiAtdm9pZCBzdm1fYXNpZF9oYW5kbGVfdm1ydW4o dm9pZCkNCj4+ICt2b2lkIHN2bV92Y3B1X2Fzc2lnbl9hc2lkKHN0cnVjdCB2Y3B1ICp2KQ0K Pj4gwqAgew0KPj4gLcKgwqDCoCBzdHJ1Y3QgdmNwdSAqY3VyciA9IGN1cnJlbnQ7DQo+PiAt wqDCoMKgIHN0cnVjdCB2bWNiX3N0cnVjdCAqdm1jYiA9IGN1cnItPmFyY2guaHZtLnN2bS52 bWNiOw0KPj4gLcKgwqDCoCBzdHJ1Y3QgaHZtX3ZjcHVfYXNpZCAqcF9hc2lkID0NCj4+IC3C oMKgwqDCoMKgwqDCoCBuZXN0ZWRodm1fdmNwdV9pbl9ndWVzdG1vZGUoY3VycikNCj4+IC3C oMKgwqDCoMKgwqDCoCA/ICZ2Y3B1X25lc3RlZGh2bShjdXJyKS5udl9uMmFzaWQgOiAmY3Vy ci0+YXJjaC5odm0ubjFhc2lkOw0KPj4gLcKgwqDCoCBib29sIG5lZWRfZmx1c2ggPSBodm1f YXNpZF9oYW5kbGVfdm1lbnRlcihwX2FzaWQpOw0KPj4gK8KgwqDCoCBzdHJ1Y3Qgdm1jYl9z dHJ1Y3QgKnZtY2IgPSB2LT5hcmNoLmh2bS5zdm0udm1jYjsNCj4+ICvCoMKgwqAgc3RydWN0 IGh2bV9hc2lkICpwX2FzaWQgPSAmdi0+ZG9tYWluLT5hcmNoLmh2bS5hc2lkOw0KPj4gwqDC oMKgwqDCoCAvKiBBU0lEIDAgaW5kaWNhdGVzIHRoYXQgQVNJRHMgYXJlIGRpc2FibGVkLiAq Lw0KPj4gwqDCoMKgwqDCoCBpZiAoIHBfYXNpZC0+YXNpZCA9PSAwICkNCj4+IEBAIC00NCwx MSArNTEsMzEgQEAgdm9pZCBzdm1fYXNpZF9oYW5kbGVfdm1ydW4odm9pZCkNCj4+IMKgwqDC oMKgwqDCoMKgwqDCoCByZXR1cm47DQo+PiDCoMKgwqDCoMKgIH0NCj4+IC3CoMKgwqAgaWYg KCB2bWNiX2dldF9hc2lkKHZtY2IpICE9IHBfYXNpZC0+YXNpZCApDQo+PiAtwqDCoMKgwqDC oMKgwqAgdm1jYl9zZXRfYXNpZCh2bWNiLCBwX2FzaWQtPmFzaWQpOw0KPj4gK8KgwqDCoCAv KiBJbiBjYXNlIEFTSURzIGFyZSBkaXNhYmxlZCwgYXMgQVNJRCA9IDAgaXMgcmVzZXJ2ZWQs IGd1ZXN0IGNhbiANCj4+IHVzZSAxIGluc3RlYWQuICovDQo+PiArwqDCoMKgIHZtY2Jfc2V0 X2FzaWQodm1jYiwgYXNpZF9lbmFibGVkID8gcF9hc2lkLT5hc2lkIDogMSk7DQo+PiArfQ0K Pj4gKw0KPj4gKy8qIENhbGwgdG8gbWFrZSBhIFRMQiBmbHVzaCBhdCB0aGUgbmV4dCBWTVJV Ti4gKi8NCj4+ICt2b2lkIHN2bV92Y3B1X3NldF90bGJfY29udHJvbChzdHJ1Y3QgdmNwdSAq dikNCj4+ICt7DQo+PiArwqDCoMKgIHN0cnVjdCB2bWNiX3N0cnVjdCAqdm1jYiA9IHYtPmFy Y2guaHZtLnN2bS52bWNiOw0KPj4gKw0KPj4gK8KgwqDCoCAvKg0KPj4gK8KgwqDCoMKgICog SWYgdGhlIHZjcHUgaXMgYWxyZWFkeSBydW5uaW5nLCB0aGUgdGxiIGNvbnRyb2wgZmxhZyBt YXkgbm90IGJlDQo+PiArwqDCoMKgwqAgKiBwcm9jZXNzZWQgYW5kIHdpbGwgYmUgY2xlYXJl ZCBhdCB0aGUgbmV4dCBWTUVYSVQsIHdoaWNoIHdpbGwgdW5kbw0KPj4gK8KgwqDCoMKgICog d2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIGRvLg0KPj4gK8KgwqDCoMKgICovDQo+PiArwqDCoMKg IFdBUk5fT04odiAhPSBjdXJyZW50ICYmIHYtPmlzX3J1bm5pbmcpOw0KPj4gKw0KPj4gK8Kg wqDCoCB2bWNiLT50bGJfY29udHJvbCA9DQo+PiArwqDCoMKgwqDCoMKgwqAgY3B1X2hhc19z dm1fZmx1c2hieWFzaWQgPyBUTEJfQ1RSTF9GTFVTSF9BU0lEIDogDQo+PiBUTEJfQ1RSTF9G TFVTSF9BTEw7DQo+PiArfQ0KPj4gKw0KPj4gK3ZvaWQgc3ZtX3ZjcHVfY2xlYXJfdGxiX2Nv bnRyb2woc3RydWN0IHZjcHUgKnYpDQo+PiArew0KPj4gK8KgwqDCoCBzdHJ1Y3Qgdm1jYl9z dHJ1Y3QgKnZtY2IgPSB2LT5hcmNoLmh2bS5zdm0udm1jYjsNCj4+IC3CoMKgwqAgLyogV2Ug Y2FuJ3QgcmVseSBvbiBUTEJfQ1RSTF9GTFVTSF9BU0lEIGFzIGFsbCBBU0lEcyBhcmUgc3Rh bGUgDQo+PiBoZXJlLiAqLw0KPj4gLcKgwqDCoCB2bWNiLT50bGJfY29udHJvbCA9IG5lZWRf Zmx1c2ggPyBUTEJfQ1RSTF9GTFVTSF9BTEwgOiANCj4+IFRMQl9DVFJMX05PX0ZMVVNIOw0K Pj4gK8KgwqDCoCB2bWNiLT50bGJfY29udHJvbCA9IFRMQl9DVFJMX05PX0ZMVVNIOw0KPj4g wqAgfQ0KPj4gwqAgLyoNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaHZtL3N2bS9u ZXN0ZWRzdm0uYyBiL3hlbi9hcmNoL3g4Ni9odm0vc3ZtLyANCj4+IG5lc3RlZHN2bS5jDQo+ PiBpbmRleCBiMDYxMjRjMmM5Li5jNzEyYjk4MjU2IDEwMDY0NA0KPj4gLS0tIGEveGVuL2Fy Y2gveDg2L2h2bS9zdm0vbmVzdGVkc3ZtLmMNCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9odm0v c3ZtL25lc3RlZHN2bS5jDQo+PiBAQCAtNSw2ICs1LDcgQEANCj4+IMKgwqAgKg0KPj4gwqDC oCAqLw0KPj4gKyNpbmNsdWRlIDxhc20vaHZtL2FzaWQuaD4NCj4+IMKgICNpbmNsdWRlIDxh c20vaHZtL3N1cHBvcnQuaD4NCj4+IMKgICNpbmNsdWRlIDxhc20vaHZtL3N2bS5oPg0KPj4g wqAgI2luY2x1ZGUgPGFzbS9odm0vbmVzdGVkaHZtLmg+DQo+PiBAQCAtNjMzLDcgKzYzNCw2 IEBAIG5zdm1fdmNwdV92bWVudHJ5KHN0cnVjdCB2Y3B1ICp2LCBzdHJ1Y3QgDQo+PiBjcHVf dXNlcl9yZWdzICpyZWdzLA0KPj4gwqDCoMKgwqDCoCBpZiAoIHN2bS0+bnNfYXNpZCAhPSB2 bWNiX2dldF9hc2lkKG5zX3ZtY2IpKQ0KPj4gwqDCoMKgwqDCoCB7DQo+PiDCoMKgwqDCoMKg wqDCoMKgwqAgbnYtPm52X2ZsdXNocDJtID0gMTsNCj4+IC3CoMKgwqDCoMKgwqDCoCBodm1f YXNpZF9mbHVzaF92Y3B1X2FzaWQoJnZjcHVfbmVzdGVkaHZtKHYpLm52X24yYXNpZCk7DQo+ PiDCoMKgwqDCoMKgwqDCoMKgwqAgc3ZtLT5uc19hc2lkID0gdm1jYl9nZXRfYXNpZChuc192 bWNiKTsNCj4+IMKgwqDCoMKgwqAgfQ0KPiANCj4gUmVtb3ZpbmcgdGhpcyBmbHVzaCBzZWVt cyB3cm9uZy4gSWYgVk1DQigxLTIpIGhhcyBzd2l0Y2hlZCB0byBhIG5ldyBBU0lEIA0KPiBi dXQNCj4gVk1DQigwLTIpIGFsd2F5cyB1c2VzIHRoZSBzYW1lIEFTSUQgKHNhbWUgYXMgVk1D QigwLTEpIElJVUMpLCB0aGVuIHdlIA0KPiBzdXJlbHkNCj4gbmVlZCB0byBmbHVzaCB0aGUg VExCIGZvciBjb3JyZWN0bmVzcy4NCj4gDQoNClllcywgSSB0aGluayB3ZSBpZGVhbGx5IHdh bnQgc29tZSBmb3JtIG9mIHZBU0lEOyBzbyB0aGF0IGNhbiBoYXZlIGJldHRlciANCmhldXJp c3RpY3Mgb24gd2hlbiB0byBmbHVzaC4NCg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4 Ni9odm0vc3ZtL3N2bS5jIGIveGVuL2FyY2gveDg2L2h2bS9zdm0vc3ZtLmMNCj4+IGluZGV4 IDM4YzYxZGIxZDcuLmU5MDI2ZTBhZTUgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC94ODYv aHZtL3N2bS9zdm0uYw0KPj4gKysrIGIveGVuL2FyY2gveDg2L2h2bS9zdm0vc3ZtLmMNCj4+ IEBAIC0yNyw2ICsyNyw3IEBADQo+PiDCoCAjaW5jbHVkZSA8YXNtL2h2bS9uZXN0ZWRodm0u aD4NCj4+IMKgICNpbmNsdWRlIDxhc20vaHZtL3N1cHBvcnQuaD4NCj4+IMKgICNpbmNsdWRl IDxhc20vaHZtL3N2bS5oPg0KPj4gKyNpbmNsdWRlIDxhc20vaHZtL2FzaWQuaD4NCj4+IMKg ICNpbmNsdWRlIDxhc20vaTM4Ny5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9pZHQuaD4NCj4+ IMKgICNpbmNsdWRlIDxhc20vaW9jYXAuaD4NCj4+IEBAIC0xMzcsMTQgKzEzOCwxNyBAQCBz dGF0aWMgdm9pZCBjZl9jaGVjayBzdm1fdXBkYXRlX2d1ZXN0X2NyKA0KPj4gwqDCoMKgwqDC oMKgwqDCoMKgIGlmICggIW5lc3RlZGh2bV9lbmFibGVkKHYtPmRvbWFpbikgKQ0KPj4gwqDC oMKgwqDCoMKgwqDCoMKgIHsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmICgg IShmbGFncyAmIEhWTV9VUERBVEVfR1VFU1RfQ1IzX05PRkxVU0gpICkNCj4+IC3CoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaHZtX2FzaWRfZmx1c2hfdmNwdSh2KTsNCj4+ICvC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdi0+YXJjaC5uZWVkc190bGJfZmx1c2gg PSB0cnVlOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIH0NCj4+IMKgwqDCoMKgwqDCoMKgwqDC oCBlbHNlIGlmICggbmVzdGVkaHZtX3Ztc3dpdGNoX2luX3Byb2dyZXNzKHYpICkNCj4+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDsgLyogQ1IzIHN3aXRjaGVzIGR1cmluZyBWTVJV Ti9WTUVYSVQgZG8gbm90IGZsdXNoIHRoZSANCj4+IFRMQi4gKi8NCj4+IMKgwqDCoMKgwqDC oMKgwqDCoCBlbHNlIGlmICggIShmbGFncyAmIEhWTV9VUERBVEVfR1VFU1RfQ1IzX05PRkxV U0gpICkNCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGh2bV9hc2lkX2ZsdXNoX3ZjcHVf YXNpZCgNCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbmVzdGVkaHZtX3Zj cHVfaW5fZ3Vlc3Rtb2RlKHYpDQo+PiAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg ID8gJnZjcHVfbmVzdGVkaHZtKHYpLm52X24yYXNpZCA6ICZ2LT5hcmNoLmh2bS5uMWFzaWQp Ow0KPj4gK8KgwqDCoMKgwqDCoMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlm IChuZXN0ZWRodm1fdmNwdV9pbl9ndWVzdG1vZGUodikpDQo+PiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHZjcHVfbmVzdGVkaHZtKHYpLm52X2ZsdXNocDJtID0gdHJ1ZTsN Cj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGVsc2UNCj4+ICvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgdi0+YXJjaC5uZWVkc190bGJfZmx1c2ggPSB0cnVlOw0KPiANCj4g Rmx1c2hpbmcgdGhlIG5lc3RlZCBQMk0gd2hlbiBydW5uaW5nIGluIGd1ZXN0IG1vZGUgaXNu J3QgY29ycmVjdC4gTDIgDQo+IGNoYW5naW5nDQo+IGl0cyBndWVzdCBDUjMgY2FuJ3QgYWZm ZWN0IHRoZSBuZXN0ZWQgcGFnZSB0YWJsZXMuDQo+IA0KPj4gK8KgwqDCoMKgwqDCoMKgIH0N Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBicmVhazsNCj4+IMKgwqDCoMKgwqAgY2FzZSA0Og0K Pj4gwqDCoMKgwqDCoMKgwqDCoMKgIHZhbHVlID0gSFZNX0NSNF9IT1NUX01BU0s7DQo+PiBA QCAtOTUyLDggKzk1Niw3IEBAIHN0YXRpYyB2b2lkIG5vcmV0dXJuIGNmX2NoZWNrIHN2bV9k b19yZXN1bWUodm9pZCkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB2LT5hcmNoLmh2bS5zdm0u bGF1bmNoX2NvcmUgPSBzbXBfcHJvY2Vzc29yX2lkKCk7DQo+PiDCoMKgwqDCoMKgwqDCoMKg wqAgaHZtX21pZ3JhdGVfdGltZXJzKHYpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGh2bV9t aWdyYXRlX3BpcnFzKHYpOw0KPj4gLcKgwqDCoMKgwqDCoMKgIC8qIE1pZ3JhdGluZyB0byBh bm90aGVyIEFTSUQgZG9tYWluLsKgIFJlcXVlc3QgYSBuZXcgQVNJRC4gKi8NCj4+IC3CoMKg wqDCoMKgwqDCoCBodm1fYXNpZF9mbHVzaF92Y3B1KHYpOw0KPj4gK8KgwqDCoMKgwqDCoMKg IHYtPmFyY2gubmVlZHNfdGxiX2ZsdXNoID0gdHJ1ZTsNCj4gDQo+IElzbid0IHRoaXMgZmx1 c2ggd2hlbiBtb3ZpbmcgdG8gYSBkaWZmZXJlbnQgcENQVSBhbHJlYWR5IGhhbmRsZWQgYnkg dGhlIA0KPiBjb250ZXh0DQo+IHN3aXRjaCBsb2dpYyBpbiB0aGUgcHJldmlvdXMgcGF0Y2g/ DQo+IA0KDQp5ZXMNCg0KPj4gwqDCoMKgwqDCoCB9DQo+PiDCoMKgwqDCoMKgIGlmICggIXZj cHVfZ3Vlc3Rtb2RlICYmICF2bGFwaWNfaHdfZGlzYWJsZWQodmxhcGljKSApDQo+PiBAQCAt OTgwLDEzICs5ODMsMTQgQEAgdm9pZCBhc21saW5rYWdlIHN2bV92bWVudGVyX2hlbHBlcih2 b2lkKQ0KPj4gwqDCoMKgwqDCoCBBU1NFUlQoaHZtZW11bF9jYWNoZV9kaXNhYmxlZChjdXJy KSk7DQo+PiAtwqDCoMKgIHN2bV9hc2lkX2hhbmRsZV92bXJ1bigpOw0KPj4gLQ0KPj4gwqDC oMKgwqDCoCBUUkFDRV9USU1FKFRSQ19IVk1fVk1FTlRSWSB8DQo+PiDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAobmVzdGVkaHZtX3ZjcHVfaW5fZ3Vlc3Rtb2RlKGN1cnIp ID8gDQo+PiBUUkNfSFZNX05FU1RFREZMQUcgOiAwKSk7DQo+PiDCoMKgwqDCoMKgIHN2bV9z eW5jX3ZtY2IoY3Vyciwgdm1jYl9uZWVkc192bXNhdmUpOw0KPj4gK8KgwqDCoCBpZiAoIHRl c3RfYW5kX2NsZWFyX2Jvb2woY3Vyci0+YXJjaC5uZWVkc190bGJfZmx1c2gpICkNCj4+ICvC oMKgwqDCoMKgwqDCoCBzdm1fdmNwdV9zZXRfdGxiX2NvbnRyb2woY3Vycik7DQo+PiArDQo+ PiDCoMKgwqDCoMKgIHZtY2ItPnJheCA9IHJlZ3MtPnJheDsNCj4+IMKgwqDCoMKgwqAgdm1j Yi0+cmlwID0gcmVncy0+cmlwOw0KPj4gwqDCoMKgwqDCoCB2bWNiLT5yc3AgPSByZWdzLT5y c3A7DQo+PiBAQCAtMTEwNyw2ICsxMTExLDggQEAgc3RhdGljIGludCBjZl9jaGVjayBzdm1f dmNwdV9pbml0aWFsaXNlKHN0cnVjdCANCj4+IHZjcHUgKnYpDQo+PiDCoMKgwqDCoMKgwqDC oMKgwqAgcmV0dXJuIHJjOw0KPj4gwqDCoMKgwqDCoCB9DQo+PiArwqDCoMKgIHN2bV92Y3B1 X2Fzc2lnbl9hc2lkKHYpOw0KPj4gKw0KPj4gwqDCoMKgwqDCoCByZXR1cm4gMDsNCj4+IMKg IH0NCj4+IEBAIC0xNTMyLDkgKzE1MzgsNiBAQCBzdGF0aWMgaW50IF9zdm1fY3B1X3VwKGJv b2wgYnNwKQ0KPj4gwqDCoMKgwqDCoCAvKiBjaGVjayBmb3IgZXJyYXR1bSAzODMgKi8NCj4+ IMKgwqDCoMKgwqAgc3ZtX2luaXRfZXJyYXR1bV8zODMoYyk7DQo+PiAtwqDCoMKgIC8qIElu aXRpYWxpemUgY29yZSdzIEFTSUQgaGFuZGxpbmcuICovDQo+PiAtwqDCoMKgIHN2bV9hc2lk X2luaXQoYyk7DQo+PiAtDQo+PiDCoMKgwqDCoMKgIC8qIEluaXRpYWxpemUgT1NWVyBiaXRz IHRvIGJlIHVzZWQgYnkgZ3Vlc3RzICovDQo+PiDCoMKgwqDCoMKgIHN2bV9ob3N0X29zdndf aW5pdCgpOw0KPj4gQEAgLTIyODksNyArMjI5Miw3IEBAIHN0YXRpYyB2b2lkIHN2bV9pbnZs cGdhX2ludGVyY2VwdCgNCj4+IMKgIHsNCj4+IMKgwqDCoMKgwqAgc3ZtX2ludmxwZ2EobGlu ZWFyLA0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAoYXNpZCA9PSAw KQ0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA/IHYtPmFyY2guaHZtLm4x YXNpZC5hc2lkDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgID8gdi0+ZG9t YWluLT5hcmNoLmh2bS5hc2lkLmFzaWQNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgOiB2Y3B1X25lc3RlZGh2bSh2KS5udl9uMmFzaWQuYXNpZCk7DQo+IA0KPiBJ ZiB3ZSBvbmx5IGV2ZXIgdXNlIHRoZSBMMSBkb21haW4ncyBBU0lELCBJTlZMUEdBIG9uIGFu eSBvdGhlciBBU0lEIGlzIA0KPiBzdXJlbHkNCj4gbm90IGNvcnJlY3QgLSBpdCBjb3VsZCBi ZWxvbmcgdG8gc29tZSBvdGhlciBMMSBWTS4gVGhlIGV4aXN0aW5nIGNvZGUgaXMgDQo+IGFs c28NCj4gaW5jb3JyZWN0IC0gTDEgaW52YWxpZGF0aW5nIHVzaW5nIGFuIEFTSUQgb3RoZXIg dGhhbiB0aGUgbGFzdCBBU0lEIGl0IHVzZWQNCj4gd291bGQgbm90IGRvIHRoZSBjb3JyZWN0 IHRoaW5nIEFGQUlDVC4NCj4gDQoNCkkgdGhpbmsgaXQncyBnb2luZyB0byBiZSBhIGJpdCBt b3JlIGNvbXBsaWNhdGVkLCBhdCBsZWFzdCBpbiB0aGUgbmVzdGVkIA0KTlBUIGNhc2Ugd2hl cmUgd2UgYWxzbyBuZWVkIHRvIHJlc2V0IHNoYWRvdyBTTEFULg0KDQpXaXRoIE5QVCwgdGhl IFRMQiBtYXBzIGEgR1ZBIGludG8gYSBTUEEgYnVpbHQgZnJvbSBnQ1IzK25DUjMsIHdpdGgg dGhpcyANCmluc3RydWN0aW9uIGZsdXNoaW5nIGEgc3BlY2lmaWMgR1ZBIG1hcHBpbmcuICJJ biBwcmluY2lwbGUiLCBhIFZNTSBpcyANCmFsbG93ZWQgdG8gdXNlIHRoaXMgdG8gZmx1c2gg YSBHVkEgYWZ0ZXIgYSAobmVzdGVkKSBTTEFUIG1vZGlmaWNhdGlvbiANCndhcyBtYWRlLg0K DQpJbiBvdXIgY2FzZSwgdGhhdCBtZWFucyB0aGF0IHdlIGFsc28gbmVlZCB0byBpbnZhbGlk YXRlIHRoZSBzaGFkb3cgU0xBVCwgDQp0byBoYW5kbGUgY2FzZXMgd2hlcmUgdGhlIGd1ZXN0 IGV4cGVjdCBTTEFUIGNoYW5nZXMgdG8gcmVmbGVjdCBpbiB0aGUgDQpuZXcgVExCIGVudHJ5 Lg0KDQpCdXQgd2UgY2FuIHN0aWxsIHVzZSBJTlZMUEdBIG9uIHRoZSBob3N0LCBhcyB0aGUg b3RoZXIgZXhpc3RpbmcgbWFwcGluZ3MgDQpvZiB0aGUgQVNJRCBhcmVuJ3Qgc3VkZGVuZGx5 IG1hZGUgaW52YWxpZCBldmVuIGlmIHRoZSBzaGFkb3cgU0xBVCANCmRvZXNuJ3QgZXhpc3Qg YW55bW9yZSAoYSBzaW1wbGVyIGFsdGVybmF0aXZlIGlzIHRvIGNvbXBsZXRlbHkgZmx1c2gg dGhlIA0KVExCLCBzbyB3ZSBkb24ndCBoYXZlIG91dCBvZiBzeW5jIHNoYWRvdyBTTEFUIGFu ZCBBU0lEKS4NCg0KPj4gwqAgfQ0KPj4gQEAgLTIzMTEsOCArMjMxNCw4IEBAIHN0YXRpYyBi b29sIGNmX2NoZWNrIGlzX2ludmxwZygNCj4+IMKgIHN0YXRpYyB2b2lkIGNmX2NoZWNrIHN2 bV9pbnZscGcoc3RydWN0IHZjcHUgKnYsIHVuc2lnbmVkIGxvbmcgbGluZWFyKQ0KPj4gwqAg ew0KPj4gLcKgwqDCoCAvKiBTYWZlIGZhbGxiYWNrLiBUYWtlIGEgbmV3IEFTSUQuICovDQo+ PiAtwqDCoMKgIGh2bV9hc2lkX2ZsdXNoX3ZjcHUodik7DQo+PiArwqDCoMKgIC8qIFNjaGVk dWxlIGEgdGxiIGZsdXNoIG9uIHRoZSBWQ1BVLiAqLw0KPj4gK8KgwqDCoCB2LT5hcmNoLm5l ZWRzX3RsYl9mbHVzaCA9IHRydWU7DQo+PiDCoCB9DQo+PiDCoCBzdGF0aWMgYm9vbCBjZl9j aGVjayBzdm1fZ2V0X3BlbmRpbmdfZXZlbnQoDQo+PiBAQCAtMjQ4Miw2ICsyNDg1LDggQEAg Y29uc3Qgc3RydWN0IGh2bV9mdW5jdGlvbl90YWJsZSAqIF9faW5pdCANCj4+IHN0YXJ0X3N2 bSh2b2lkKQ0KPj4gwqDCoMKgwqDCoCBzdm1fZnVuY3Rpb25fdGFibGUuY2Fwcy5oYXBfc3Vw ZXJwYWdlXzJtYiA9IHRydWU7DQo+PiDCoMKgwqDCoMKgIHN2bV9mdW5jdGlvbl90YWJsZS5j YXBzLmhhcF9zdXBlcnBhZ2VfMWdiID0gY3B1X2hhc19wYWdlMWdiOw0KPj4gK8KgwqDCoCBz dm1fYXNpZF9pbml0KCk7DQo+PiArDQo+PiDCoMKgwqDCoMKgIHJldHVybiAmc3ZtX2Z1bmN0 aW9uX3RhYmxlOw0KPj4gwqAgfQ0KPj4gQEAgLTI1MzksNiArMjU0NCw4IEBAIHZvaWQgYXNt bGlua2FnZSBzdm1fdm1leGl0X2hhbmRsZXIodm9pZCkNCj4+IMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKHZsYXBpY19nZXRfcmVnKHZsYXBpYywgQVBJQ19U QVNLUFJJKSAmIDB4MEYpKTsNCj4+IMKgwqDCoMKgwqAgfQ0KPj4gK8KgwqDCoCBzdm1fdmNw dV9jbGVhcl90bGJfY29udHJvbCh2KTsNCj4+ICsNCj4gDQo+IElzIHRoZXJlIGEgcmVhc29u IHRvIHNwbGl0IHVwZGF0aW5nIHRsYl9jb250cm9sIGludG8gYSBjbGVhciBhbmQgdGhlbiAN Cj4gbGF0ZXIgYQ0KPiBwb3RlbnRpYWwgc2V0PyBUaGlzIHdheSB0aGVyZSBhcmUgZWl0aGVy IDEgb3IgMiB3cml0ZXMgdG8gaXQgd2hlcmVhcyBpZiB5b3UNCj4gdW5jb25kaXRpb25hbGx5 IHNldCBpdCBiZWZvcmUgVk1SVU4gdGhlcmUgd291bGQgb25seSBldmVyIGJlIDEgd3JpdGUu DQo+IA0KDQpZZXMsIEkgd2FzIGFsc28gdGhpbmtpbmcgYWJvdXQgbWVyZ2luZyBzdm1fdmNw dV9jbGVhcl90bGJfY29udHJvbCgpIGludG8gDQpzdm1fdmNwdV9zZXRfdGxiX2NvbnRyb2wo KSBieSBhZGRpbmcgYSBib29sZWFuIHBhcmFtZXRlci4NCg0KPj4gwqDCoMKgwqDCoCBleGl0 X3JlYXNvbiA9IHZtY2ItPmV4aXRjb2RlOw0KPj4gwqDCoMKgwqDCoCBpZiAoIGh2bV9sb25n X21vZGVfYWN0aXZlKHYpICkNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaHZtL3N2 bS9zdm0uaCBiL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL3N2bS5oDQo+PiBpbmRleCBjZmE0MTFh ZDVhLi45MDEzNTRlOTE0IDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS9zdm0v c3ZtLmgNCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9odm0vc3ZtL3N2bS5oDQo+PiBAQCAtMTIs MTIgKzEyLDggQEANCj4+IMKgICNpbmNsdWRlIDx4ZW4vdHlwZXMuaD4NCj4+IMKgIHN0cnVj dCBjcHVfdXNlcl9yZWdzOw0KPj4gLXN0cnVjdCBjcHVpbmZvX3g4NjsNCj4+IMKgIHN0cnVj dCB2Y3B1Ow0KPj4gLXZvaWQgc3ZtX2FzaWRfaW5pdChjb25zdCBzdHJ1Y3QgY3B1aW5mb194 ODYgKmMpOw0KPj4gLXZvaWQgc3ZtX2FzaWRfaGFuZGxlX3ZtcnVuKHZvaWQpOw0KPj4gLQ0K Pj4gwqAgdW5zaWduZWQgbG9uZyAqc3ZtX21zcmJpdCh1bnNpZ25lZCBsb25nICptc3JfYml0 bWFwLCB1aW50MzJfdCBtc3IpOw0KPj4gwqAgdm9pZCBfX3VwZGF0ZV9ndWVzdF9laXAoc3Ry dWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MsIHVuc2lnbmVkIGludCANCj4+IGluc3RfbGVuKTsN Cj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaHZtL3ZteC92bWNzLmMgYi94ZW4vYXJj aC94ODYvaHZtL3ZteC92bWNzLmMNCj4+IGluZGV4IDhlNTJlZjRkNDkuLjM5MTZhZTQ0Njgg MTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZteC92bWNzLmMNCj4+ICsrKyBi L3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZtY3MuYw0KPj4gQEAgLTIwLDYgKzIwLDcgQEANCj4+ IMKgICNpbmNsdWRlIDxhc20vY3VycmVudC5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9mbHVz aHRsYi5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9odm0vaHZtLmg+DQo+PiArI2luY2x1ZGUg PGFzbS9odm0vYXNpZC5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9odm0vaW8uaD4NCj4+IMKg ICNpbmNsdWRlIDxhc20vaHZtL25lc3RlZGh2bS5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9o dm0vdm14L3ZtY3MuaD4NCj4+IEBAIC03NzgsOCArNzc5LDYgQEAgc3RhdGljIGludCBfdm14 X2NwdV91cChib29sIGJzcCkNCj4+IMKgwqDCoMKgwqAgdGhpc19jcHUodm14b24pID0gMTsN Cj4+IC3CoMKgwqAgaHZtX2FzaWRfaW5pdChjcHVfaGFzX3ZteF92cGlkID8gKDF1IDw8IFZN Q1NfVlBJRF9XSURUSCkgOiAwKTsNCj4+IC0NCj4+IMKgwqDCoMKgwqAgaWYgKCBjcHVfaGFz X3ZteF9lcHQgKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGVwdF9zeW5jX2FsbCgpOw0KPj4g QEAgLTE5MDMsNyArMTkwMiw3IEBAIHZvaWQgY2ZfY2hlY2sgdm14X2RvX3Jlc3VtZSh2b2lk KQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgKi8NCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB2 LT5hcmNoLmh2bS52bXguaG9zdGVudl9taWdyYXRlZCA9IDE7DQo+PiAtwqDCoMKgwqDCoMKg wqAgaHZtX2FzaWRfZmx1c2hfdmNwdSh2KTsNCj4+ICvCoMKgwqDCoMKgwqDCoCB2LT5hcmNo Lm5lZWRzX3RsYl9mbHVzaCA9IHRydWU7DQo+PiDCoMKgwqDCoMKgIH0NCj4+IMKgwqDCoMKg wqAgZGVidWdfc3RhdGUgPSB2LT5kb21haW4tPmRlYnVnZ2VyX2F0dGFjaGVkDQo+PiBAQCAt MjExNiw3ICsyMTE1LDYgQEAgdm9pZCB2bWNzX2R1bXBfdmNwdShzdHJ1Y3QgdmNwdSAqdikN Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgIChTRUNPTkRBUllfRVhFQ19FTkFCTEVfVlBJRCB8 IA0KPj4gU0VDT05EQVJZX0VYRUNfRU5BQkxFX1ZNX0ZVTkNUSU9OUykgKQ0KPj4gwqDCoMKg wqDCoMKgwqDCoMKgIHByaW50aygiVmlydHVhbCBwcm9jZXNzb3IgSUQgPSAweCUwNHggVk1m dW5jIGNvbnRyb2xzID0gDQo+PiAlMDE2bHhcbiIsDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB2bXIxNihWSVJUVUFMX1BST0NFU1NPUl9JRCksIHZtcihWTV9GVU5D VElPTl9DT05UUk9MKSk7DQo+PiAtDQo+PiDCoMKgwqDCoMKgIHZteF92bWNzX2V4aXQodik7 DQo+PiDCoCB9DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMg Yi94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYw0KPj4gaW5kZXggMjY5Y2E1NjQzMy4uYTUz MTE0NTIxOCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jDQo+ PiArKysgYi94ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYw0KPj4gQEAgLTI1LDYgKzI1LDcg QEANCj4+IMKgICNpbmNsdWRlIDxhc20vZnNnc2Jhc2UuaD4NCj4+IMKgICNpbmNsdWRlIDxh c20vZ2Ric3guaD4NCj4+IMKgICNpbmNsdWRlIDxhc20vZ3Vlc3QtbXNyLmg+DQo+PiArI2lu Y2x1ZGUgPGFzbS9odm0vYXNpZC5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9odm0vZW11bGF0 ZS5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9odm0vaHZtLmg+DQo+PiDCoCAjaW5jbHVkZSA8 YXNtL2h2bS9tb25pdG9yLmg+DQo+PiBAQCAtODM0LDYgKzgzNSwxOCBAQCBzdGF0aWMgdm9p ZCBjZl9jaGVjayANCj4+IHZteF9jcHVpZF9wb2xpY3lfY2hhbmdlZChzdHJ1Y3QgdmNwdSAq dikNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB2bXhfdXBkYXRlX3NlY29uZGFyeV9leGVjX2Nv bnRyb2wodik7DQo+PiDCoMKgwqDCoMKgIH0NCj4+ICvCoMKgwqAgaWYgKCBhc2lkX2VuYWJs ZWQgKQ0KPj4gK8KgwqDCoCB7DQo+PiArwqDCoMKgwqDCoMKgwqAgdi0+YXJjaC5odm0udm14 LnNlY29uZGFyeV9leGVjX2NvbnRyb2wgfD0gDQo+PiBTRUNPTkRBUllfRVhFQ19FTkFCTEVf VlBJRDsNCj4+ICvCoMKgwqDCoMKgwqDCoCB2bXhfdXBkYXRlX3NlY29uZGFyeV9leGVjX2Nv bnRyb2wodik7DQo+PiArwqDCoMKgIH0NCj4+ICvCoMKgwqAgZWxzZQ0KPj4gK8KgwqDCoCB7 DQo+PiArwqDCoMKgwqDCoMKgwqAgdi0+YXJjaC5odm0udm14LnNlY29uZGFyeV9leGVjX2Nv bnRyb2wgJj0gDQo+PiB+U0VDT05EQVJZX0VYRUNfRU5BQkxFX1ZQSUQ7DQo+PiArwqDCoMKg wqDCoMKgwqAgdm14X3VwZGF0ZV9zZWNvbmRhcnlfZXhlY19jb250cm9sKHYpOw0KPj4gK8Kg wqDCoCB9DQo+PiArDQo+PiArDQo+PiDCoMKgwqDCoMKgIC8qDQo+PiDCoMKgwqDCoMKgwqAg KiBXZSBjYW4gc2FmZWx5IHBhc3MgTVNSX1NQRUNfQ1RSTCB0aHJvdWdoIHRvIHRoZSBndWVz dCwgZXZlbiANCj4+IGlmIFNUSUJQDQo+PiDCoMKgwqDCoMKgwqAgKiBpc24ndCBlbnVtZXJh dGVkIGluIGhhcmR3YXJlLCBhcyBTUEVDX0NUUkxfU1RJQlAgaXMgaWdub3JlZC4NCj4+IEBA IC0xNTEwLDcgKzE1MjMsNyBAQCBzdGF0aWMgdm9pZCBjZl9jaGVjayB2bXhfaGFuZGxlX2Nk KHN0cnVjdCB2Y3B1IA0KPj4gKnYsIHVuc2lnbmVkIGxvbmcgdmFsdWUpDQo+PiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCB2bXhfc2V0X21zcl9pbnRlcmNlcHQodiwgTVNSX0lBMzJf Q1JfUEFULCBWTVhfTVNSX1JXKTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHdi aW52ZCgpO8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLyogZmx1c2ggcG9zc2libHkg cG9sbHV0ZWQgY2FjaGUgKi8NCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGh2bV9hc2lk X2ZsdXNoX3ZjcHUodik7IC8qIGludmFsaWRhdGUgbWVtb3J5IHR5cGUgY2FjaGVkIA0KPj4g aW4gVExCICovDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2LT5hcmNoLm5lZWRzX3Rs Yl9mbHVzaCA9IHRydWU7IC8qIGludmFsaWRhdGUgbWVtb3J5IHR5cGUgDQo+PiBjYWNoZWQg aW4gVExCICovDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2LT5hcmNoLmh2bS52 bXguY2FjaGVfbW9kZSA9IENBQ0hFX01PREVfTk9fRklMTDsNCj4+IMKgwqDCoMKgwqDCoMKg wqDCoCB9DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgZWxzZQ0KPj4gQEAgLTE1MTksNyArMTUz Miw3IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIHZteF9oYW5kbGVfY2Qoc3RydWN0IHZjcHUg DQo+PiAqdiwgdW5zaWduZWQgbG9uZyB2YWx1ZSkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIHZteF9zZXRfZ3Vlc3RfcGF0KHYsICpwYXQpOw0KPj4gwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgaWYgKCAhaXNfaW9tbXVfZW5hYmxlZCh2LT5kb21haW4pIHx8IGlvbW11 X3Nub29wICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdm14X2Ns ZWFyX21zcl9pbnRlcmNlcHQodiwgTVNSX0lBMzJfQ1JfUEFULCANCj4+IFZNWF9NU1JfUlcp Ow0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaHZtX2FzaWRfZmx1c2hfdmNwdSh2KTsg Lyogbm8gbmVlZCB0byBmbHVzaCBjYWNoZSAqLw0KPj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKg wqAgdi0+YXJjaC5uZWVkc190bGJfZmx1c2ggPSB0cnVlOw0KPj4gwqDCoMKgwqDCoMKgwqDC oMKgIH0NCj4+IMKgwqDCoMKgwqAgfQ0KPj4gwqAgfQ0KPj4gQEAgLTE4NzEsNyArMTg4NCw3 IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIHZteF91cGRhdGVfZ3Vlc3RfY3IoDQo+PiDCoMKg wqDCoMKgwqDCoMKgwqAgX192bXdyaXRlKEdVRVNUX0NSMywgdi0+YXJjaC5odm0uaHdfY3Jb M10pOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGlmICggIShmbGFncyAmIEhWTV9VUERBVEVf R1VFU1RfQ1IzX05PRkxVU0gpICkNCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGh2bV9h c2lkX2ZsdXNoX3ZjcHUodik7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2LT5hcmNo Lm5lZWRzX3RsYl9mbHVzaCA9IHRydWU7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgYnJlYWs7 DQo+PiDCoMKgwqDCoMKgIGRlZmF1bHQ6DQo+PiBAQCAtMzE2OCw2ICszMTgxLDggQEAgY29u c3Qgc3RydWN0IGh2bV9mdW5jdGlvbl90YWJsZSAqIF9faW5pdCANCj4+IHN0YXJ0X3ZteCh2 b2lkKQ0KPj4gwqDCoMKgwqDCoCBsYnJfdHN4X2ZpeHVwX2NoZWNrKCk7DQo+PiDCoMKgwqDC oMKgIGxlcl90b19maXh1cF9jaGVjaygpOw0KPj4gK8KgwqDCoCBCVUdfT04oaHZtX2FzaWRf aW5pdChjcHVfaGFzX3ZteF92cGlkID8gKDF1IDw8IFZNQ1NfVlBJRF9XSURUSCkgOiANCj4+ IDEpKTsNCj4+ICsNCj4+IMKgwqDCoMKgwqAgcmV0dXJuICZ2bXhfZnVuY3Rpb25fdGFibGU7 DQo+PiDCoCB9DQo+PiBAQCAtNDkzMSw5ICs0OTQ2LDcgQEAgYm9vbCBhc21saW5rYWdlIHZt eF92bWVudGVyX2hlbHBlcihjb25zdCBzdHJ1Y3QgDQo+PiBjcHVfdXNlcl9yZWdzICpyZWdz KQ0KPj4gwqAgew0KPj4gwqDCoMKgwqDCoCBzdHJ1Y3QgdmNwdSAqY3VyciA9IGN1cnJlbnQ7 DQo+PiDCoMKgwqDCoMKgIHN0cnVjdCBkb21haW4gKmN1cnJkID0gY3Vyci0+ZG9tYWluOw0K Pj4gLcKgwqDCoCB1MzIgbmV3X2FzaWQsIG9sZF9hc2lkOw0KPj4gLcKgwqDCoCBzdHJ1Y3Qg aHZtX3ZjcHVfYXNpZCAqcF9hc2lkOw0KPj4gLcKgwqDCoCBib29sIG5lZWRfZmx1c2g7DQo+ PiArwqDCoMKgIHN0cnVjdCBodm1fYXNpZCAqcF9hc2lkOw0KPj4gwqDCoMKgwqDCoCBBU1NF UlQoaHZtZW11bF9jYWNoZV9kaXNhYmxlZChjdXJyKSk7DQo+PiBAQCAtNDk0OSwzMyArNDk2 Miw5IEBAIGJvb2wgYXNtbGlua2FnZSB2bXhfdm1lbnRlcl9oZWxwZXIoY29uc3Qgc3RydWN0 IA0KPj4gY3B1X3VzZXJfcmVncyAqcmVncykNCj4+IMKgwqDCoMKgwqAgaWYgKCBuZXN0ZWRo dm1fdmNwdV9pbl9ndWVzdG1vZGUoY3VycikgKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHBf YXNpZCA9ICZ2Y3B1X25lc3RlZGh2bShjdXJyKS5udl9uMmFzaWQ7DQo+PiDCoMKgwqDCoMKg IGVsc2UNCj4+IC3CoMKgwqDCoMKgwqDCoCBwX2FzaWQgPSAmY3Vyci0+YXJjaC5odm0ubjFh c2lkOw0KPj4gLQ0KPj4gLcKgwqDCoCBvbGRfYXNpZCA9IHBfYXNpZC0+YXNpZDsNCj4+IC3C oMKgwqAgbmVlZF9mbHVzaCA9IGh2bV9hc2lkX2hhbmRsZV92bWVudGVyKHBfYXNpZCk7DQo+ PiAtwqDCoMKgIG5ld19hc2lkID0gcF9hc2lkLT5hc2lkOw0KPj4gLQ0KPj4gLcKgwqDCoCBp ZiAoIHVubGlrZWx5KG5ld19hc2lkICE9IG9sZF9hc2lkKSApDQo+PiAtwqDCoMKgIHsNCj4+ IC3CoMKgwqDCoMKgwqDCoCBfX3Ztd3JpdGUoVklSVFVBTF9QUk9DRVNTT1JfSUQsIG5ld19h c2lkKTsNCj4+IC3CoMKgwqDCoMKgwqDCoCBpZiAoICFvbGRfYXNpZCAmJiBuZXdfYXNpZCAp DQo+PiAtwqDCoMKgwqDCoMKgwqAgew0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLyog VlBJRCB3YXMgZGlzYWJsZWQ6IG5vdyBlbmFibGVkLiAqLw0KPj4gLcKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgY3Vyci0+YXJjaC5odm0udm14LnNlY29uZGFyeV9leGVjX2NvbnRyb2wgfD0N Cj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU0VDT05EQVJZX0VYRUNfRU5B QkxFX1ZQSUQ7DQo+PiAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2bXhfdXBkYXRlX3NlY29u ZGFyeV9leGVjX2NvbnRyb2woY3Vycik7DQo+PiAtwqDCoMKgwqDCoMKgwqAgfQ0KPj4gLcKg wqDCoMKgwqDCoMKgIGVsc2UgaWYgKCBvbGRfYXNpZCAmJiAhbmV3X2FzaWQgKQ0KPj4gLcKg wqDCoMKgwqDCoMKgIHsNCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC8qIFZQSUQgd2Fz IGVuYWJsZWQ6IG5vdyBkaXNhYmxlZC4gKi8NCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKg IGN1cnItPmFyY2guaHZtLnZteC5zZWNvbmRhcnlfZXhlY19jb250cm9sICY9DQo+PiAtwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH5TRUNPTkRBUllfRVhFQ19FTkFCTEVfVlBJ RDsNCj4+IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZteF91cGRhdGVfc2Vjb25kYXJ5X2V4 ZWNfY29udHJvbChjdXJyKTsNCj4+IC3CoMKgwqDCoMKgwqDCoCB9DQo+PiAtwqDCoMKgIH0N Cj4+ICvCoMKgwqDCoMKgwqDCoCBwX2FzaWQgPSAmY3VycmQtPmFyY2guaHZtLmFzaWQ7DQo+ PiAtwqDCoMKgIGlmICggdW5saWtlbHkobmVlZF9mbHVzaCkgKQ0KPj4gLcKgwqDCoMKgwqDC oMKgIHZwaWRfc3luY19hbGwoKTsNCj4+ICvCoMKgwqAgX192bXdyaXRlKFZJUlRVQUxfUFJP Q0VTU09SX0lELCBwX2FzaWQtPmFzaWQpOw0KPj4gwqDCoMKgwqDCoCBpZiAoIHBhZ2luZ19t b2RlX2hhcChjdXJyLT5kb21haW4pICkNCj4+IMKgwqDCoMKgwqAgew0KPj4gQEAgLTQ5ODQs MTIgKzQ5NzMsMTggQEAgYm9vbCBhc21saW5rYWdlIHZteF92bWVudGVyX2hlbHBlcihjb25z dCANCj4+IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gwqDCoMKgwqDCoMKgwqDC oMKgIHVuc2lnbmVkIGludCBpbnYgPSAwOyAvKiBOb25lID0+IFNpbmdsZSA9PiBBbGwgKi8N Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBzdHJ1Y3QgZXB0X2RhdGEgKnNpbmdsZSA9IE5VTEw7 IC8qIFNpbmdsZSBlcHRwLCBpZmYgaW52ID09IDEgKi8NCj4+ICvCoMKgwqDCoMKgwqDCoCBp ZiAoIHRlc3RfYW5kX2NsZWFyX2Jvb2woY3Vyci0+YXJjaC5uZWVkc190bGJfZmx1c2gpwqAg KQ0KPj4gK8KgwqDCoMKgwqDCoMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlu diA9IDE7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzaW5nbGUgPSBlcHQ7DQo+PiAr wqDCoMKgwqDCoMKgwqAgfQ0KPj4gKw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGlmICggY3B1 bWFza190ZXN0X2NwdShjcHUsIGVwdC0+aW52YWxpZGF0ZSkgKQ0KPj4gwqDCoMKgwqDCoMKg wqDCoMKgIHsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNwdW1hc2tfY2xlYXJf Y3B1KGNwdSwgZXB0LT5pbnZhbGlkYXRlKTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIC8qIEF1dG9tYXRpY2FsbHkgaW52YWxpZGF0ZSBhbGwgY29udGV4dHMgaWYgbmVzdGVk LiAqLw0KPj4gLcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaW52ICs9IDEgKyBuZXN0ZWRodm1f ZW5hYmxlZChjdXJyZCk7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpbnYgPSAxICsg bmVzdGVkaHZtX2VuYWJsZWQoY3VycmQpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgc2luZ2xlID0gZXB0Ow0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIH0NCj4+IEBAIC01MDE4 LDYgKzUwMTMsMTEgQEAgYm9vbCBhc21saW5rYWdlIHZteF92bWVudGVyX2hlbHBlcihjb25z dCBzdHJ1Y3QgDQo+PiBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgX19pbnZlcHQoaW52ID09IDEgPyBJTlZFUFRfU0lOR0xFX0NPTlRFWFQg OiANCj4+IElOVkVQVF9BTExfQ09OVEVYVCwNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIGludiA9PSAxID8gc2luZ2xlLT5lcHRwwqDCoMKgwqDC oMKgwqDCoMKgIDogMCk7DQo+PiDCoMKgwqDCoMKgIH0NCj4+ICvCoMKgwqAgZWxzZSAvKiBT aGFkb3cgcGFnaW5nICovDQo+PiArwqDCoMKgIHsNCj4+ICvCoMKgwqDCoMKgwqDCoCBpZiAo IHRlc3RfYW5kX2NsZWFyX2Jvb2woY3Vyci0+YXJjaC5uZWVkc190bGJfZmx1c2gpICkNCj4+ ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZwaWRfc3luY192Y3B1X2NvbnRleHQoY3Vycik7 DQo+PiArwqDCoMKgIH0NCj4+IMKgwqAgb3V0Og0KPj4gwqDCoMKgwqDCoCBpZiAoIHVubGlr ZWx5KGN1cnItPmFyY2guaHZtLnZteC5sYnJfZmxhZ3MgJiBMQlJfRklYVVBfTUFTSykgKQ0K Pj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3Z2bXguYyBiL3hlbi9hcmNo L3g4Ni9odm0vdm14L3Z2bXguYw0KPj4gaW5kZXggZTRjZGZlNTVjMS4uNWMwZTEyMjZjNCAx MDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3Z2bXguYw0KPj4gKysrIGIv eGVuL2FyY2gveDg2L2h2bS92bXgvdnZteC5jDQo+PiBAQCAtMTI1Myw3ICsxMjUzLDcgQEAg c3RhdGljIHZvaWQgdmlydHVhbF92bWVudHJ5KHN0cnVjdCBjcHVfdXNlcl9yZWdzIA0KPj4g KnJlZ3MpDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCBudm14LT5ndWVzdF92cGlkICE9 IG5ld192cGlkICkNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCB7DQo+PiAtwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBodm1fYXNpZF9mbHVzaF92Y3B1X2FzaWQoJnZjcHVfbmVzdGVkaHZtKHYp Lm52X24yYXNpZCk7DQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2LT5hcmNoLm5lZWRz X3RsYl9mbHVzaCA9IHRydWU7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBudm14 LT5ndWVzdF92cGlkID0gbmV3X3ZwaWQ7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgfQ0KPj4g wqDCoMKgwqDCoCB9DQo+PiBAQCAtMjA1Miw3ICsyMDUyLDcgQEAgc3RhdGljIGludCBudm14 X2hhbmRsZV9pbnZ2cGlkKHN0cnVjdCANCj4+IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQo+PiDC oMKgwqDCoMKgIGNhc2UgSU5WVlBJRF9JTkRJVklEVUFMX0FERFI6DQo+PiDCoMKgwqDCoMKg IGNhc2UgSU5WVlBJRF9TSU5HTEVfQ09OVEVYVDoNCj4+IMKgwqDCoMKgwqAgY2FzZSBJTlZW UElEX0FMTF9DT05URVhUOg0KPj4gLcKgwqDCoMKgwqDCoMKgIGh2bV9hc2lkX2ZsdXNoX3Zj cHVfYXNpZCgmdmNwdV9uZXN0ZWRodm0oY3VycmVudCkubnZfbjJhc2lkKTsNCj4+ICvCoMKg wqDCoMKgwqDCoCBodm1fZmx1c2hfdGxiKE5VTEwpOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKg IGJyZWFrOw0KPj4gwqDCoMKgwqDCoCBkZWZhdWx0Og0KPj4gwqDCoMKgwqDCoMKgwqDCoMKg IHZtZmFpbChyZWdzLCBWTVhfSU5TTl9JTlZFUFRfSU5WVlBJRF9JTlZBTElEX09QKTsNCj4+ IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vZmx1c2h0bGIuaCBiL3hl bi9hcmNoL3g4Ni8gDQo+PiBpbmNsdWRlL2FzbS9mbHVzaHRsYi5oDQo+PiBpbmRleCAzNDU2 NzdlYjcyLi4wODFlNWExMTg4IDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gveDg2L2luY2x1 ZGUvYXNtL2ZsdXNodGxiLmgNCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9m bHVzaHRsYi5oDQo+PiBAQCAtMTI1LDEyICsxMjUsNiBAQCB2b2lkIHN3aXRjaF9jcjNfY3I0 KHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBsb25nIA0KPj4gY3IzLCB1bnNpZ25lZCBsb25n IGNyNCk7DQo+PiDCoCAjZGVmaW5lIEZMVVNIX1ZDUFVfU1RBVEUgMHgxMDAwDQo+PiDCoMKg IC8qIEZsdXNoIHRoZSBwZXItY3B1IHJvb3QgcGFnZSB0YWJsZSAqLw0KPj4gwqAgI2RlZmlu ZSBGTFVTSF9ST09UX1BHVEJMIDB4MjAwMA0KPj4gLSNpZiBDT05GSUdfSFZNDQo+PiAtIC8q IEZsdXNoIGFsbCBIVk0gZ3Vlc3RzIGxpbmVhciBUTEIgKHVzaW5nIEFTSUQvVlBJRCkgKi8N Cj4+IC0jZGVmaW5lIEZMVVNIX0hWTV9BU0lEX0NPUkUgMHg0MDAwDQo+PiAtI2Vsc2UNCj4+ IC0jZGVmaW5lIEZMVVNIX0hWTV9BU0lEX0NPUkUgMA0KPj4gLSNlbmRpZg0KPj4gwqAgI2lm IGRlZmluZWQoQ09ORklHX1BWKSB8fCBkZWZpbmVkKENPTkZJR19TSEFET1dfUEFHSU5HKQ0K Pj4gwqAgLyoNCj4+IMKgwqAgKiBBZGRpbmcgdGhpcyB0byB0aGUgZmxhZ3MgcGFzc2VkIHRv IGZsdXNoX2FyZWFfbWFzayB3aWxsIHByZXZlbnQgDQo+PiB1c2luZyB0aGUNCj4+IEBAIC0x OTAsNyArMTg0LDYgQEAgdm9pZCBmbHVzaF9hcmVhX21hc2soY29uc3QgY3B1bWFza190ICpt YXNrLCBjb25zdCANCj4+IHZvaWQgKnZhLA0KPj4gwqAgc3RhdGljIGlubGluZSB2b2lkIGZs dXNoX3BhZ2VfdG9fcmFtKHVuc2lnbmVkIGxvbmcgbWZuLCBib29sIA0KPj4gc3luY19pY2Fj aGUpIHt9DQo+PiAtdW5zaWduZWQgaW50IGd1ZXN0X2ZsdXNoX3RsYl9mbGFncyhjb25zdCBz dHJ1Y3QgZG9tYWluICpkKTsNCj4+IMKgIHZvaWQgZ3Vlc3RfZmx1c2hfdGxiX21hc2soY29u c3Qgc3RydWN0IGRvbWFpbiAqZCwgY29uc3QgY3B1bWFza190IA0KPj4gKm1hc2spOw0KPj4g wqAgI2VuZGlmIC8qIF9fRkxVU0hUTEJfSF9fICovDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2Fy Y2gveDg2L2luY2x1ZGUvYXNtL2h2bS9hc2lkLmggYi94ZW4vYXJjaC94ODYvIA0KPj4gaW5j bHVkZS9hc20vaHZtL2FzaWQuaA0KPj4gaW5kZXggMjViYTU3ZTc2OC4uYjZkZjVjZGEzNSAx MDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9odm0vYXNpZC5oDQo+ PiArKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZtL2FzaWQuaA0KPj4gQEAgLTgs MjUgKzgsMjUgQEANCj4+IMKgICNpZm5kZWYgX19BU01fWDg2X0hWTV9BU0lEX0hfXw0KPj4g wqAgI2RlZmluZSBfX0FTTV9YODZfSFZNX0FTSURfSF9fDQo+PiArI2luY2x1ZGUgPHhlbi9z dGRib29sLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9zdGRpbnQuaD4NCj4+IC1zdHJ1Y3QgdmNw dTsNCj4+IC1zdHJ1Y3QgaHZtX3ZjcHVfYXNpZDsNCj4+ICtzdHJ1Y3QgaHZtX2FzaWQgew0K Pj4gK8KgIHVpbnQzMl90IGFzaWQ7DQo+PiArfTsNCj4+IC0vKiBJbml0aWFsaXNlIEFTSUQg bWFuYWdlbWVudCBmb3IgdGhlIGN1cnJlbnQgcGh5c2ljYWwgQ1BVLiAqLw0KPj4gLXZvaWQg aHZtX2FzaWRfaW5pdCh1bnNpZ25lZCBpbnQgbmFzaWRzKTsNCj4+ICsjaWZkZWYgQ09ORklH X0hWTQ0KPj4gK2V4dGVybiBib29sIGFzaWRfZW5hYmxlZDsNCj4+ICsjZWxzZQ0KPj4gKyNk ZWZpbmUgYXNpZF9lbmFibGVkIChmYWxzZSkNCj4+ICsjZW5kaWYNCj4+IC0vKiBJbnZhbGlk YXRlIGEgcGFydGljdWxhciBBU0lEIGFsbG9jYXRpb246IGZvcmNlcyByZS1hbGxvY2F0aW9u LiAqLw0KPj4gLXZvaWQgaHZtX2FzaWRfZmx1c2hfdmNwdV9hc2lkKHN0cnVjdCBodm1fdmNw dV9hc2lkICphc2lkKTsNCj4+ICsvKiBJbml0aWFsaXNlIEFTSUQgbWFuYWdlbWVudCBkaXN0 cmlidXRlZCBhY3Jvc3MgYWxsIENQVXMuICovDQo+PiAraW50IGh2bV9hc2lkX2luaXQodW5z aWduZWQgbG9uZyBuYXNpZHMpOw0KPj4gLS8qIEludmFsaWRhdGUgYWxsIEFTSUQgYWxsb2Nh dGlvbnMgZm9yIHNwZWNpZmllZCBWQ1BVOiBmb3JjZXMgcmUtIA0KPj4gYWxsb2NhdGlvbi4g Ki8NCj4+IC12b2lkIGh2bV9hc2lkX2ZsdXNoX3ZjcHUoc3RydWN0IHZjcHUgKnYpOw0KPj4g LQ0KPj4gLS8qIEZsdXNoIGFsbCBBU0lEcyBvbiB0aGlzIHByb2Nlc3NvciBjb3JlLiAqLw0K Pj4gLXZvaWQgaHZtX2FzaWRfZmx1c2hfY29yZSh2b2lkKTsNCj4+IC0NCj4+IC0vKiBDYWxs ZWQgYmVmb3JlIGVudHJ5IHRvIGd1ZXN0IGNvbnRleHQuIENoZWNrcyBBU0lEIGFsbG9jYXRp b24sIA0KPj4gcmV0dXJucyBhDQo+PiAtICogYm9vbGVhbiBpbmRpY2F0aW5nIHdoZXRoZXIg YWxsIEFTSURzIG11c3QgYmUgZmx1c2hlZC4gKi8NCj4+IC1ib29sIGh2bV9hc2lkX2hhbmRs ZV92bWVudGVyKHN0cnVjdCBodm1fdmNwdV9hc2lkICphc2lkKTsNCj4+ICtpbnQgaHZtX2Fz aWRfYWxsb2Moc3RydWN0IGh2bV9hc2lkICphc2lkKTsNCj4+ICtpbnQgaHZtX2FzaWRfYWxs b2NfcmFuZ2Uoc3RydWN0IGh2bV9hc2lkICphc2lkLCB1bnNpZ25lZCBsb25nIG1pbiwgDQo+ PiB1bnNpZ25lZCBsb25nIG1heCk7DQo+PiArdm9pZCBodm1fYXNpZF9mcmVlKHN0cnVjdCBo dm1fYXNpZCAqYXNpZCk7DQo+PiDCoCAjZW5kaWYgLyogX19BU01fWDg2X0hWTV9BU0lEX0hf XyAqLw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9odm0vZG9t YWluLmggYi94ZW4vYXJjaC94ODYvIA0KPj4gaW5jbHVkZS9hc20vaHZtL2RvbWFpbi5oDQo+ PiBpbmRleCBkZDdmYTk2YWFkLi4xOTQzNDNkOWJmIDEwMDY0NA0KPj4gLS0tIGEveGVuL2Fy Y2gveDg2L2luY2x1ZGUvYXNtL2h2bS9kb21haW4uaA0KPj4gKysrIGIveGVuL2FyY2gveDg2 L2luY2x1ZGUvYXNtL2h2bS9kb21haW4uaA0KPj4gQEAgLTE0MCw2ICsxNDAsNyBAQCBzdHJ1 Y3QgaHZtX2RvbWFpbiB7DQo+PiDCoMKgwqDCoMKgIH0gd3JpdGVfbWFwOw0KPj4gwqDCoMKg wqDCoCBzdHJ1Y3QgaHZtX3BpX29wcyBwaV9vcHM7DQo+PiArwqDCoMKgIHN0cnVjdCBodm1f YXNpZCBhc2lkOw0KPj4gwqDCoMKgwqDCoCB1bmlvbiB7DQo+PiDCoMKgwqDCoMKgwqDCoMKg wqAgc3RydWN0IHZteF9kb21haW4gdm14Ow0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4 Ni9pbmNsdWRlL2FzbS9odm0vaHZtLmggYi94ZW4vYXJjaC94ODYvIA0KPj4gaW5jbHVkZS9h c20vaHZtL2h2bS5oDQo+PiBpbmRleCBlN2MxMzY0ODAyLi45MzVkOWU3NTQ4IDEwMDY0NA0K Pj4gLS0tIGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2h2bS9odm0uaA0KPj4gKysrIGIv eGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2h2bS9odm0uaA0KPj4gQEAgLTI3NCw2ICsyNzQs OCBAQCBpbnQgaHZtX2RvbWFpbl9pbml0aWFsaXNlKHN0cnVjdCBkb21haW4gKmQsDQo+PiDC oCB2b2lkIGh2bV9kb21haW5fcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAq ZCk7DQo+PiDCoCB2b2lkIGh2bV9kb21haW5fZGVzdHJveShzdHJ1Y3QgZG9tYWluICpkKTsN Cj4+ICtpbnQgaHZtX2ZsdXNoX3RsYihjb25zdCB1bnNpZ25lZCBsb25nICp2Y3B1X2JpdG1h cCk7DQo+PiArDQo+PiDCoCBpbnQgaHZtX3ZjcHVfaW5pdGlhbGlzZShzdHJ1Y3QgdmNwdSAq dik7DQo+PiDCoCB2b2lkIGh2bV92Y3B1X2Rlc3Ryb3koc3RydWN0IHZjcHUgKnYpOw0KPj4g wqAgdm9pZCBodm1fdmNwdV9kb3duKHN0cnVjdCB2Y3B1ICp2KTsNCj4+IEBAIC00OTcsMTcg KzQ5OSw2IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBodm1fc2V0X3RzY19vZmZzZXQoc3RydWN0 IHZjcHUgDQo+PiAqdiwgdWludDY0X3Qgb2Zmc2V0KQ0KPj4gwqDCoMKgwqDCoCBhbHRlcm5h dGl2ZV92Y2FsbChodm1fZnVuY3Muc2V0X3RzY19vZmZzZXQsIHYsIG9mZnNldCk7DQo+PiDC oCB9DQo+PiAtLyoNCj4+IC0gKiBDYWxsZWQgdG8gZW5zdXJlIHRoYW4gYWxsIGd1ZXN0LXNw ZWNpZmljIG1hcHBpbmdzIGluIGEgdGFnZ2VkIFRMQiBhcmUNCj4+IC0gKiBmbHVzaGVkOyBk b2VzICpub3QqIGZsdXNoIFhlbidzIFRMQiBlbnRyaWVzLCBhbmQgb24gcHJvY2Vzc29ycyAN Cj4+IHdpdGhvdXQgYQ0KPj4gLSAqIHRhZ2dlZCBUTEIgaXQgd2lsbCBiZSBhIG5vb3AuDQo+ PiAtICovDQo+PiAtc3RhdGljIGlubGluZSB2b2lkIGh2bV9mbHVzaF9ndWVzdF90bGJzKHZv aWQpDQo+PiAtew0KPj4gLcKgwqDCoCBpZiAoIGh2bV9lbmFibGVkICkNCj4+IC3CoMKgwqDC oMKgwqDCoCBodm1fYXNpZF9mbHVzaF9jb3JlKCk7DQo+PiAtfQ0KPj4gLQ0KPj4gwqAgc3Rh dGljIGlubGluZSB1bnNpZ25lZCBpbnQNCj4+IMKgIGh2bV9nZXRfY3BsKHN0cnVjdCB2Y3B1 ICp2KQ0KPj4gwqAgew0KPj4gQEAgLTkwMSw4ICs4OTIsNiBAQCBzdGF0aWMgaW5saW5lIGlu dCBodm1fY3B1X3VwKHZvaWQpDQo+PiDCoCBzdGF0aWMgaW5saW5lIHZvaWQgaHZtX2NwdV9k b3duKHZvaWQpIHt9DQo+PiAtc3RhdGljIGlubGluZSB2b2lkIGh2bV9mbHVzaF9ndWVzdF90 bGJzKHZvaWQpIHt9DQo+PiAtDQo+PiDCoCBzdGF0aWMgaW5saW5lIHZvaWQgaHZtX2ludmxw Zyhjb25zdCBzdHJ1Y3QgdmNwdSAqdiwgdW5zaWduZWQgbG9uZyANCj4+IGxpbmVhcikNCj4+ IMKgIHsNCj4+IMKgwqDCoMKgwqAgQVNTRVJUX1VOUkVBQ0hBQkxFKCk7DQo+PiBkaWZmIC0t Z2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2h2bS9zdm0uaCBiL3hlbi9hcmNoL3g4 Ni8gDQo+PiBpbmNsdWRlL2FzbS9odm0vc3ZtLmgNCj4+IGluZGV4IGEzNWE2MTI3M2IuLjE4 NzdiYjE0OWEgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZt L3N2bS5oDQo+PiArKysgYi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZtL3N2bS5oDQo+ PiBAQCAtOSw2ICs5LDExIEBADQo+PiDCoCAjaWZuZGVmIF9fQVNNX1g4Nl9IVk1fU1ZNX0hf Xw0KPj4gwqAgI2RlZmluZSBfX0FTTV9YODZfSFZNX1NWTV9IX18NCj4+ICt2b2lkIHN2bV9h c2lkX2luaXQodm9pZCk7DQo+PiArdm9pZCBzdm1fdmNwdV9hc3NpZ25fYXNpZChzdHJ1Y3Qg dmNwdSAqdik7DQo+PiArdm9pZCBzdm1fdmNwdV9zZXRfdGxiX2NvbnRyb2woc3RydWN0IHZj cHUgKnYpOw0KPj4gK3ZvaWQgc3ZtX3ZjcHVfY2xlYXJfdGxiX2NvbnRyb2woc3RydWN0IHZj cHUgKnYpOw0KPj4gKw0KPj4gwqAgLyoNCj4+IMKgwqAgKiBQViBjb250ZXh0IHN3aXRjaCBo ZWxwZXJzLsKgIFByZWZldGNoaW5nIHRoZSBWTUNCIGFyZWEgaXRzZWxmIGhhcyANCj4+IGJl ZW4gc2hvd24NCj4+IMKgwqAgKiB0byBiZSB1c2VmdWwgZm9yIHBlcmZvcm1hbmNlLg0KPj4g ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9odm0vdmNwdS5oIGIveGVu L2FyY2gveDg2LyANCj4+IGluY2x1ZGUvYXNtL2h2bS92Y3B1LmgNCj4+IGluZGV4IDJhMTRm YTBhNjMuLjhhZDJhYjI5MTAgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC94ODYvaW5jbHVk ZS9hc20vaHZtL3ZjcHUuaA0KPj4gKysrIGIveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNtL2h2 bS92Y3B1LmgNCj4+IEBAIC05LDYgKzksNyBAQA0KPj4gwqAgI2RlZmluZSBfX0FTTV9YODZf SFZNX1ZDUFVfSF9fDQo+PiDCoCAjaW5jbHVkZSA8eGVuL3Rhc2tsZXQuaD4NCj4+ICsjaW5j bHVkZSA8YXNtL2h2bS9hc2lkLmg+DQo+PiDCoCAjaW5jbHVkZSA8YXNtL2h2bS92bGFwaWMu aD4NCj4+IMKgICNpbmNsdWRlIDxhc20vaHZtL3ZteC92bWNzLmg+DQo+PiDCoCAjaW5jbHVk ZSA8YXNtL2h2bS92bXgvdnZteC5oPg0KPj4gQEAgLTE2LDExICsxNyw2IEBADQo+PiDCoCAj aW5jbHVkZSA8YXNtL210cnIuaD4NCj4+IMKgICNpbmNsdWRlIDxwdWJsaWMvaHZtL2lvcmVx Lmg+DQo+PiAtc3RydWN0IGh2bV92Y3B1X2FzaWQgew0KPj4gLcKgwqDCoCB1aW50NjRfdCBn ZW5lcmF0aW9uOw0KPj4gLcKgwqDCoCB1aW50MzJfdCBhc2lkOw0KPj4gLX07DQo+PiAtDQo+ PiDCoCBzdHJ1Y3QgaHZtX3ZjcHVfaW8gew0KPj4gwqDCoMKgwqDCoCAvKg0KPj4gwqDCoMKg wqDCoMKgICogSFZNIGVtdWxhdGlvbjoNCj4+IEBAIC03Niw3ICs3Miw3IEBAIHN0cnVjdCBu ZXN0ZWR2Y3B1IHsNCj4+IMKgwqDCoMKgwqAgYm9vbCBzdGFsZV9ucDJtOyAvKiBUcnVlIHdo ZW4gcDJtX2Jhc2UgaW4gVk1DeDAyIGlzIG5vIGxvbmdlciANCj4+IHZhbGlkICovDQo+PiDC oMKgwqDCoMKgIHVpbnQ2NF90IG5wMm1fZ2VuZXJhdGlvbjsNCj4+IC3CoMKgwqAgc3RydWN0 IGh2bV92Y3B1X2FzaWQgbnZfbjJhc2lkOw0KPj4gK8KgwqDCoCBzdHJ1Y3QgaHZtX2FzaWQg bnZfbjJhc2lkOw0KPiANCj4gRm9yIFNWTSwgYWZ0ZXIgdGhlIGNoYW5nZSB0byBzdm1fYXNp ZF9oYW5kbGVfdm1ydW4gQUZBSUNUIG5vdGhpbmcgc2V0cyB0aGlzDQo+IG90aGVyIHRoYW4g bmVzdGVkaHZtX3ZjcHVfcmVzZXQuDQo+IA0KPj4gwqDCoMKgwqDCoCBib29sIG52X3ZtZW50 cnlfcGVuZGluZzsNCj4+IMKgwqDCoMKgwqAgYm9vbCBudl92bWV4aXRfcGVuZGluZzsNCj4+ IEBAIC0xNDAsOCArMTM2LDYgQEAgc3RydWN0IGh2bV92Y3B1IHsNCj4+IMKgwqDCoMKgwqAg LyogKE1GTikgaHlwZXJ2aXNvciBwYWdlIHRhYmxlICovDQo+PiDCoMKgwqDCoMKgIHBhZ2V0 YWJsZV90wqDCoMKgwqDCoMKgwqDCoCBtb25pdG9yX3RhYmxlOw0KPj4gLcKgwqDCoCBzdHJ1 Y3QgaHZtX3ZjcHVfYXNpZCBuMWFzaWQ7DQo+PiAtDQo+PiDCoMKgwqDCoMKgIHU2NMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG1zcl90c2NfYWRqdXN0Ow0KPj4gwqDCoMKg wqDCoCB1bmlvbiB7DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2luY2x1ZGUvYXNt L2h2bS92bXgvdm14LmggYi94ZW4vYXJjaC94ODYvIA0KPj4gaW5jbHVkZS9hc20vaHZtL3Zt eC92bXguaA0KPj4gaW5kZXggMDg4NTRjMzZjYS4uZTBkNDM4OWYyMCAxMDA2NDQNCj4+IC0t LSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9odm0vdm14L3ZteC5oDQo+PiArKysgYi94 ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vaHZtL3ZteC92bXguaA0KPj4gQEAgLTQ2Myw3ICs0 NjMsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgdnBpZF9zeW5jX3ZjcHVfY29udGV4dChjb25z dCANCj4+IHN0cnVjdCB2Y3B1ICp2KQ0KPj4gwqDCoMKgwqDCoCBpZiAoIHVubGlrZWx5KCFj cHVfaGFzX3ZteF92cGlkX2ludnZwaWRfc2luZ2xlX2NvbnRleHQpICkNCj4+IMKgwqDCoMKg wqDCoMKgwqDCoCB0eXBlID0gSU5WVlBJRF9BTExfQ09OVEVYVDsNCj4+IC3CoMKgwqAgX19p bnZ2cGlkKHR5cGUsIHYtPmFyY2guaHZtLm4xYXNpZC5hc2lkLCAwKTsNCj4+ICvCoMKgwqAg X19pbnZ2cGlkKHR5cGUsIHYtPmRvbWFpbi0+YXJjaC5odm0uYXNpZC5hc2lkLCAwKTsNCj4+ IMKgIH0NCj4+IMKgIHN0YXRpYyBpbmxpbmUgdm9pZCB2cGlkX3N5bmNfdmNwdV9ndmEoc3Ry dWN0IHZjcHUgKnYsIHVuc2lnbmVkIGxvbmcgDQo+PiBndmEpDQo+PiBAQCAtNDg0LDcgKzQ4 NCw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCB2cGlkX3N5bmNfdmNwdV9ndmEoc3RydWN0IHZj cHUgDQo+PiAqdiwgdW5zaWduZWQgbG9uZyBndmEpDQo+PiDCoMKgwqDCoMKgIGlmICggdW5s aWtlbHkoIWNwdV9oYXNfdm14X3ZwaWRfaW52dnBpZF9zaW5nbGVfY29udGV4dCkgKQ0KPj4g wqDCoMKgwqDCoMKgwqDCoMKgIHR5cGUgPSBJTlZWUElEX0FMTF9DT05URVhUOw0KPj4gLcKg wqDCoCBfX2ludnZwaWQodHlwZSwgdi0+YXJjaC5odm0ubjFhc2lkLmFzaWQsICh1NjQpZ3Zh KTsNCj4+ICvCoMKgwqAgX19pbnZ2cGlkKHR5cGUsIHYtPmRvbWFpbi0+YXJjaC5odm0uYXNp ZC5hc2lkLCAodTY0KWd2YSk7DQo+PiDCoCB9DQo+PiDCoCBzdGF0aWMgaW5saW5lIHZvaWQg dnBpZF9zeW5jX2FsbCh2b2lkKQ0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tbS9o YXAvaGFwLmMgYi94ZW4vYXJjaC94ODYvbW0vaGFwL2hhcC5jDQo+PiBpbmRleCA1Y2NiODBi ZGE1Li4xNTY3MzRkM2UwIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gveDg2L21tL2hhcC9o YXAuYw0KPj4gKysrIGIveGVuL2FyY2gveDg2L21tL2hhcC9oYXAuYw0KPj4gQEAgLTI3LDYg KzI3LDcgQEANCj4+IMKgICNpbmNsdWRlIDxhc20vcDJtLmg+DQo+PiDCoCAjaW5jbHVkZSA8 YXNtL2RvbWFpbi5oPg0KPj4gwqAgI2luY2x1ZGUgPHhlbi9udW1hLmg+DQo+PiArI2luY2x1 ZGUgPGFzbS9odm0vYXNpZC5oPg0KPj4gwqAgI2luY2x1ZGUgPGFzbS9odm0vbmVzdGVkaHZt Lmg+DQo+PiDCoCAjaW5jbHVkZSA8cHVibGljL3NjaGVkLmg+DQo+PiBAQCAtNzUwLDE4ICs3 NTEsMTYgQEAgc3RhdGljIGJvb2wgY2ZfY2hlY2sgZmx1c2hfdGxiKGNvbnN0IHVuc2lnbmVk IA0KPj4gbG9uZyAqdmNwdV9iaXRtYXApDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCAh Zmx1c2hfdmNwdSh2LCB2Y3B1X2JpdG1hcCkgKQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgY29udGludWU7DQo+PiAtwqDCoMKgwqDCoMKgwqAgaHZtX2FzaWRfZmx1c2hfdmNw dSh2KTsNCj4+IC0NCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBjcHUgPSByZWFkX2F0b21pYygm di0+ZGlydHlfY3B1KTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoIGNwdSAhPSB0aGlz X2NwdSAmJiBpc192Y3B1X2RpcnR5X2NwdShjcHUpICYmIHYtIA0KPj4gPmlzX3J1bm5pbmcg KQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgX19jcHVtYXNrX3NldF9jcHUoY3B1 LCBtYXNrKTsNCj4+IMKgwqDCoMKgwqAgfQ0KPj4gK8KgwqDCoCBndWVzdF9mbHVzaF90bGJf bWFzayhkLCBtYXNrKTsNCj4+ICsNCj4+IMKgwqDCoMKgwqAgLyoNCj4+IMKgwqDCoMKgwqDC oCAqIFRyaWdnZXIgYSB2bWV4aXQgb24gYWxsIHBDUFVzIHdpdGggZGlydHkgdkNQVSBzdGF0 ZSBpbiBvcmRlciANCj4+IHRvIGZvcmNlIGFuDQo+PiAtwqDCoMKgwqAgKiBBU0lEL1ZQSUQg Y2hhbmdlIGFuZCBoZW5jZSBhY2NvbXBsaXNoIGEgZ3Vlc3QgVExCIGZsdXNoLiBOb3RlIA0K Pj4gdGhhdCB2Q1BVcw0KPj4gLcKgwqDCoMKgICogbm90IGN1cnJlbnRseSBydW5uaW5nIHdp bGwgYWxyZWFkeSBiZSBmbHVzaGVkIHdoZW4gc2NoZWR1bGVkIA0KPj4gYmVjYXVzZSBvZg0K Pj4gLcKgwqDCoMKgICogdGhlIEFTSUQgdGlja2xlIGRvbmUgaW4gdGhlIGxvb3AgYWJvdmUu DQo+PiArwqDCoMKgwqAgKiBBU0lEL1ZQSUQgZmx1c2ggYW5kIGhlbmNlIGFjY29tcGxpc2gg YSBndWVzdCBUTEIgZmx1c2guDQo+PiDCoMKgwqDCoMKgwqAgKi8NCj4+IMKgwqDCoMKgwqAg b25fc2VsZWN0ZWRfY3B1cyhtYXNrLCBOVUxMLCBOVUxMLCAwKTsNCj4+IGRpZmYgLS1naXQg YS94ZW4vYXJjaC94ODYvbW0vcDJtLmMgYi94ZW4vYXJjaC94ODYvbW0vcDJtLmMNCj4+IGlu ZGV4IDAyN2I5YWU2OWIuLjk4NzliNDg0MGIgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC94 ODYvbW0vcDJtLmMNCj4+ICsrKyBiL3hlbi9hcmNoL3g4Ni9tbS9wMm0uYw0KPj4gQEAgLTE0 NDAsNyArMTQ0MCw3IEBAIHAybV9mbHVzaChzdHJ1Y3QgdmNwdSAqdiwgc3RydWN0IHAybV9k b21haW4gKnAybSkNCj4+IMKgwqDCoMKgwqAgQVNTRVJUKHYtPmRvbWFpbiA9PSBwMm0tPmRv bWFpbik7DQo+PiDCoMKgwqDCoMKgIHZjcHVfbmVzdGVkaHZtKHYpLm52X3AybSA9IE5VTEw7 DQo+PiDCoMKgwqDCoMKgIHAybV9mbHVzaF90YWJsZShwMm0pOw0KPj4gLcKgwqDCoCBodm1f YXNpZF9mbHVzaF92Y3B1KHYpOw0KPj4gK8KgwqDCoCB2LT5hcmNoLm5lZWRzX3RsYl9mbHVz aCA9IHRydWU7DQo+PiDCoCB9DQo+PiDCoCB2b2lkDQo+PiBAQCAtMTQ5OSw3ICsxNDk5LDcg QEAgc3RhdGljIHZvaWQgYXNzaWduX25wMm0oc3RydWN0IHZjcHUgKnYsIHN0cnVjdCANCj4+ IHAybV9kb21haW4gKnAybSkNCj4+IMKgIHN0YXRpYyB2b2lkIG52Y3B1X2ZsdXNoKHN0cnVj dCB2Y3B1ICp2KQ0KPj4gwqAgew0KPj4gLcKgwqDCoCBodm1fYXNpZF9mbHVzaF92Y3B1KHYp Ow0KPj4gK8KgwqDCoCB2LT5hcmNoLm5lZWRzX3RsYl9mbHVzaCA9IHRydWU7DQo+PiDCoMKg wqDCoMKgIHZjcHVfbmVzdGVkaHZtKHYpLnN0YWxlX25wMm0gPSB0cnVlOw0KPj4gwqAgfQ0K Pj4gQEAgLTE2MTksNyArMTYxOSw3IEBAIHZvaWQgbnAybV9zY2hlZHVsZShpbnQgZGlyKQ0K Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaWYgKCAhbnAybV92YWxpZCApDQo+PiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIC8qIFRoaXMgdkNQVSdzIG5wMm0gd2FzIGZsdXNoZWQgd2hpbGUgaXQg d2FzIG5vdCANCj4+IHJ1bm5hYmxlICovDQo+PiAtwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIGh2bV9hc2lkX2ZsdXNoX2NvcmUoKTsNCj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgY3Vyci0+YXJjaC5uZWVkc190bGJfZmx1c2ggPSB0cnVlOw0KPj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2Y3B1X25lc3RlZGh2bShjdXJyKS5u dl9wMm0gPSBOVUxMOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfQ0KPj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZWxzZQ0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNo L3g4Ni9tbS9wYWdpbmcuYyBiL3hlbi9hcmNoL3g4Ni9tbS9wYWdpbmcuYw0KPj4gaW5kZXgg MTRhYjdkZWZkOC4uMDYwNTNkOWEwNiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL3g4Ni9t bS9wYWdpbmcuYw0KPj4gKysrIGIveGVuL2FyY2gveDg2L21tL3BhZ2luZy5jDQo+PiBAQCAt OTM4LDcgKzkzOCw3IEBAIHZvaWQgcGFnaW5nX3VwZGF0ZV9uZXN0ZWRtb2RlKHN0cnVjdCB2 Y3B1ICp2KQ0KPj4gwqDCoMKgwqDCoCBlbHNlDQo+PiDCoMKgwqDCoMKgwqDCoMKgwqAgLyog VE9ETzogc2hhZG93LW9uLXNoYWRvdyAqLw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHYtPmFy Y2gucGFnaW5nLm5lc3RlZG1vZGUgPSBOVUxMOw0KPj4gLcKgwqDCoCBodm1fYXNpZF9mbHVz aF92Y3B1KHYpOw0KPj4gK8KgwqDCoCB2LT5hcmNoLm5lZWRzX3RsYl9mbHVzaCA9IHRydWU7 DQo+IA0KPiBUaGlzIHVuY29uZGl0aW9uYWwgZmx1c2ggaXMgZG9uZSBvbiBldmVyeSBMMiBl eGl0IHRvIEwwLiBUaGF0IHNob3VsZG4ndCBiZQ0KPiBuZWNlc3NhcnksIGJ1dCB0aGF0J3Mg bm90IHNwZWNpZmljYWxseSBhIHByb2JsZW0gd2l0aCB0aGlzIHBhdGNoLg0KPiANCg0KDQoN Cj4+IMKgIH0NCj4+IMKgIGludCBfX2luaXQgcGFnaW5nX3NldF9hbGxvY2F0aW9uKHN0cnVj dCBkb21haW4gKmQsIHVuc2lnbmVkIGludCBwYWdlcywNCj4+IGRpZmYgLS1naXQgYS94ZW4v YXJjaC94ODYvbW0vc2hhZG93L211bHRpLmMgYi94ZW4vYXJjaC94ODYvbW0vc2hhZG93LyAN Cj4+IG11bHRpLmMNCj4+IGluZGV4IDFiMDQ3N2VkMmIuLjEwN2QwODI5ZjIgMTAwNjQ0DQo+ PiAtLS0gYS94ZW4vYXJjaC94ODYvbW0vc2hhZG93L211bHRpLmMNCj4+ICsrKyBiL3hlbi9h cmNoL3g4Ni9tbS9zaGFkb3cvbXVsdGkuYw0KPj4gQEAgLTgxLDEyICs4MSw2IEBAIGNvbnN0 IGNoYXIgKmNvbnN0IGZldGNoX3R5cGVfbmFtZXNbXSA9IHsNCj4+IMKgIHN0YXRpYyBwYWdl dGFibGVfdCBjZl9jaGVjayBzaF91cGRhdGVfY3IzKHN0cnVjdCB2Y3B1ICp2LCBib29sIA0K Pj4gbm9mbHVzaCk7DQo+PiAtLyogSGVscGVyIHRvIHBlcmZvcm0gYSBsb2NhbCBUTEIgZmx1 c2guICovDQo+PiAtc3RhdGljIHZvaWQgc2hfZmx1c2hfbG9jYWwoY29uc3Qgc3RydWN0IGRv bWFpbiAqZCkNCj4+IC17DQo+PiAtwqDCoMKgIGZsdXNoX2xvY2FsKGd1ZXN0X2ZsdXNoX3Rs Yl9mbGFncyhkKSk7DQo+PiAtfQ0KPj4gLQ0KPj4gwqAgI2lmIEdVRVNUX1BBR0lOR19MRVZF TFMgPj0gNCAmJiBkZWZpbmVkKENPTkZJR19QVjMyKQ0KPj4gwqAgI2RlZmluZSBBU1NFUlRf VkFMSURfTDIodCkgXA0KPj4gwqDCoMKgwqDCoCBBU1NFUlQoKHQpID09IFNIX3R5cGVfbDJf c2hhZG93IHx8ICh0KSA9PSBTSF90eXBlX2wyaF9zaGFkb3cpDQo+PiBAQCAtMjk0NSw3ICsy OTM5LDggQEAgc3RhdGljIGJvb2wgY2ZfY2hlY2sgc2hfaW52bHBnKHN0cnVjdCB2Y3B1ICp2 LCANCj4+IHVuc2lnbmVkIGxvbmcgbGluZWFyKQ0KPj4gwqDCoMKgwqDCoCBpZiAoIG1mbl90 b19wYWdlKHNsMW1mbiktPnUuc2gudHlwZQ0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgPT0g U0hfdHlwZV9mbDFfc2hhZG93ICkNCj4+IMKgwqDCoMKgwqAgew0KPj4gLcKgwqDCoMKgwqDC oMKgIHNoX2ZsdXNoX2xvY2FsKHYtPmRvbWFpbik7DQo+PiArwqDCoMKgwqDCoMKgwqAgZmx1 c2hfdGxiX2xvY2FsKCk7DQo+PiArwqDCoMKgwqDCoMKgwqAgdi0+YXJjaC5uZWVkc190bGJf Zmx1c2ggPSB0cnVlOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiBmYWxzZTsNCj4+ IMKgwqDCoMKgwqAgfQ0KPj4gQEAgLTMxNjAsNyArMzE1NSw4IEBAIHNoX3VwZGF0ZV9saW5l YXJfZW50cmllcyhzdHJ1Y3QgdmNwdSAqdikNCj4+IMKgwqDCoMKgwqDCoCAqIGxpbmVhciBw YWdldGFibGUgdG8gcmVhZCBhIHRvcC1sZXZlbCBzaGFkb3cgcGFnZSB0YWJsZSBlbnRyeS4g DQo+PiBCdXQsDQo+PiDCoMKgwqDCoMKgwqAgKiB3aXRob3V0IHRoaXMgY2hhbmdlLCBpdCB3 b3VsZCBmZXRjaCB0aGUgd3JvbmcgdmFsdWUgZHVlIHRvIGEgDQo+PiBzdGFsZSBUTEIuDQo+ PiDCoMKgwqDCoMKgwqAgKi8NCj4+IC3CoMKgwqAgc2hfZmx1c2hfbG9jYWwoZCk7DQo+PiAr wqDCoMKgIGZsdXNoX3RsYl9sb2NhbCgpOw0KPj4gK8KgwqDCoCB2LT5hcmNoLm5lZWRzX3Rs Yl9mbHVzaCA9IHRydWU7DQo+PiDCoCB9DQo+PiDCoCBzdGF0aWMgcGFnZXRhYmxlX3QgY2Zf Y2hlY2sgc2hfdXBkYXRlX2NyMyhzdHJ1Y3QgdmNwdSAqdiwgYm9vbCBub2ZsdXNoKQ0KPiAN Cj4gQm9vdGluZyBIeXBlci1WIG9uIG15IEFNRCB0ZXN0IG1hY2hpbmUgd2l0aCBvdXIgaW50 ZXJuYWwgbmVzdGVkIHZpcnQgDQo+IGJyYW5jaCArDQo+IHRoaXMgcGF0Y2ggc2VyaWVzIGZh aWxzOg0KPiANCj4gKFhFTikgW8KgwqAgODguMDAzNDE1XSBBc3NlcnRpb24gJ2xvY2FsX2ly cV9pc19lbmFibGVkKCknIGZhaWxlZCBhdCANCj4gY29tbW9uL3NtcC5jOjUzDQo+IChYRU4p IFvCoMKgIDg4LjAwMzQxOV0gLS0tLVsgWGVuLTQuMjMuMMKgIHg4Nl82NMKgIGRlYnVnPXnC oCBOb3QgdGFpbnRlZCBdLS0tLQ0KPiAoWEVOKSBbwqDCoCA4OC4wMDM0MjFdIENQVTrCoMKg wqAgMTENCj4gKFhFTikgW8KgwqAgODguMDAzNDIyXSBSSVA6wqDCoMKgIGUwMDg6WzxmZmZm ODJkMDQwMjNiNTgwPl0gDQo+IG9uX3NlbGVjdGVkX2NwdXMrMHg5YS8weGQ0DQo+IChYRU4p IFvCoMKgIDg4LjAwMzQyOF0gUkZMQUdTOiAwMDAwMDAwMDAwMDEwMDQ2wqDCoCBDT05URVhU OiBoeXBlcnZpc29yIChkMXYwKQ0KPiAoWEVOKSBbwqDCoCA4OC4wMDM0MzFdIHJheDogMDAw MDAwMDAwMDAwMDA0NsKgwqAgcmJ4OiAwMDAwMDAwMDAwMDAwMDAwICAgDQo+IHJjeDogMDAw MDAwMDAwMDAwMDAwMA0KPiAoWEVOKSBbwqDCoCA4OC4wMDM0MzNdIHJkeDogMDAwMDAwMDAw MDAwMDAwMMKgwqAgcnNpOiAwMDAwMDAwMDAwMDAwMDAwICAgDQo+IHJkaTogZmZmZjgzMTA1 MTBkZGFmMA0KPiAoWEVOKSBbwqDCoCA4OC4wMDM0MzVdIHJicDogZmZmZjgzMTA1MTBkN2Nk OMKgwqAgcnNwOiBmZmZmODMxMDUxMGQ3Y2IwICAgDQo+IHI4OsKgIGZmZmY4MzEwNTEwZGRh ZjANCj4gKFhFTikgW8KgwqAgODguMDAzNDM2XSByOTrCoCBmZmZmODMxMDUxMGVhZTcwwqDC oCByMTA6IGZmZmY4MzEwNTEwZDgyMzAgICANCj4gcjExOiBmZmZmODMxMDUxMGQ3ZjA4DQo+ IChYRU4pIFvCoMKgIDg4LjAwMzQzOF0gcjEyOiBmZmZmODMxMDUxMGRkYWYwwqDCoCByMTM6 IDAwMDAwMDAwMDAwMDAwMGIgICANCj4gcjE0OiBmZmZmODMxMDdjNTJkMDAwDQo+IChYRU4p IFvCoMKgIDg4LjAwMzQ0MF0gcjE1OiBmZmZmODMxMDdjNTJkMDAwwqDCoCBjcjA6IDAwMDAw MDAwODAwNTAwMzMgICANCj4gY3I0OiAwMDAwMDAwMDAwZjUwNmUwDQo+IChYRU4pIFvCoMKg IDg4LjAwMzQ0MV0gY3IzOiAwMDAwMDAxMDdjNTFjMDAwwqDCoCBjcjI6IDAwMDAwMDAwMDAw MDAwMDANCj4gKFhFTikgW8KgwqAgODguMDAzNDQzXSBmc2I6IDAwMDAwMDAwMDAwMDAwMDDC oMKgIGdzYjogZmZmZmY4N2JkOWUzYjAwMCAgIA0KPiBnc3M6IDAwMDAwMDAwMDAwMDAwMDAN Cj4gKFhFTikgW8KgwqAgODguMDAzNDQ1XSBkczogMDAwMMKgwqAgZXM6IDAwMDDCoMKgIGZz OiAwMDAwwqDCoCBnczogMDAyMMKgwqAgc3M6IA0KPiAwMDAwwqDCoCBjczogZTAwOA0KPiAo WEVOKSBbwqDCoCA4OC4wMDM0NDddIFhlbiBjb2RlIGFyb3VuZCA8ZmZmZjgyZDA0MDIzYjU4 MD4gDQo+IChvbl9zZWxlY3RlZF9jcHVzKzB4OWEvMHhkNCk6DQo+IChYRU4pIFvCoMKgIDg4 LjAwMzQ0OF3CoCA0MSA1ZiA1ZCBlOSA2MCA2YSBmYyBmZiA8ZDY+IGQ2IDRjIDg5IDM1IGY3 IDllIGEwIA0KPiAwMCA0YyA4OSAzZCBmOCA5ZSBhMCAwMA0KPiAoWEVOKSBbwqDCoCA4OC4w MDM0NTVdIFhlbiBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODMxMDUxMGQ3Y2IwOg0KPiAo WEVOKSBbwqDCoCA4OC4wMDM0NTddwqDCoMKgIGZmZmY4MmQwNDAzMWZhYzIgZmZmZjgzMTAw YzExZDAwMCANCj4gZmZmZjgyZDA0MGM0NTQ5OCAwMDAwMDAwMDAwMDAwMDAxDQo+IChYRU4p IFvCoMKgIDg4LjAwMzQ1OV3CoMKgwqAgZmZmZjgyZDA0MDMxM2U1ZSBmZmZmODMxMDUxMGQ3 Y2U4IA0KPiBmZmZmODJkMDQwMzFmYjMzIGZmZmY4MzEwNTEwZDdjZjgNCj4gKFhFTikgW8Kg wqAgODguMDAzNDYyXcKgwqDCoCBmZmZmODJkMDQwMzA5OGQyIGZmZmY4MzEwNTEwZDdkMTAg DQo+IGZmZmY4MmQwNDAzMTNlOTQgMDAwMDAwMDAwMDAwMDAwYg0KPiAoWEVOKSBbwqDCoCA4 OC4wMDM0NjRdwqDCoMKgIGZmZmY4MzEwNTEwZDdkMjggZmZmZjgyZDA0MDIzYjZiMSANCj4g ZmZmZjgyZDA0MGM0NTQ5OCBmZmZmODMxMDUxMGQ3ZDQwDQo+IChYRU4pIFvCoMKgIDg4LjAw MzQ2N13CoMKgwqAgZmZmZjgyZDA0MDM3YWI2OCBmZmZmODMxMDE0MGFlZmIwIA0KPiBmZmZm ODMxMDUxMGQ3ZDc4IGZmZmY4MmQwNDAyM2I1OWYNCj4gKFhFTikgW8KgwqAgODguMDAzNDY5 XcKgwqDCoCBmZmZmODMxMDdjNTJjMmYwIGZmZmY4MzEwN2M1MmQ1MzggDQo+IGZmZmY4MzEw N2M1MmQwMDAgMDAwMDAwMDAwMDAwNGQwMQ0KPiAoWEVOKSBbwqDCoCA4OC4wMDM0NzJdwqDC oMKgIGZmZmY4MzEwN2M1MmQwMDAgZmZmZjgzMTA1MTBkN2Q5MCANCj4gZmZmZjgyZDA0MDMx M2ZjZSBmZmZmODMxMDdjNTJjMmYwDQo+IChYRU4pIFvCoMKgIDg4LjAwMzQ3NF3CoMKgwqAg ZmZmZjgzMTA1MTBkN2RiOCBmZmZmODJkMDQwMzMwMTY0IA0KPiBmZmZmODMxMDdjNTJjMmYw IGZmZmY4MzEwN2M1MmQ1MzgNCj4gKFhFTikgW8KgwqAgODguMDAzNDc3XcKgwqDCoCBmZmZm ODMxMDUxMGQ3ZmZmIGZmZmY4MzEwNTEwZDdkZDggDQo+IGZmZmY4MmQwNDAzMzAyNTkgZmZm ZjgzMTA3YzUyZDRlOA0KPiAoWEVOKSBbwqDCoCA4OC4wMDM0NzldwqDCoMKgIGZmZmY4MzEw N2M1MmQ1MzggZmZmZjgzMTA1MTBkN2UwMCANCj4gZmZmZjgyZDA0MDMzMDViYyBmZmZmODMx MDBjMTFkMDAwDQo+IChYRU4pIFvCoMKgIDg4LjAwMzQ4Ml3CoMKgwqAgMDAwMDAwMDAwMDAw NGQwMSAwMDAwMDAwMDAwMDA0OTAxIA0KPiBmZmZmODMxMDUxMGQ3ZTM4IGZmZmY4MmQwNDAz MGIyNWYNCj4gKFhFTikgW8KgwqAgODguMDAzNDg0XcKgwqDCoCAwMDAwMDAwMGMwMDAwMDgw IDAwMDAwMDAwMDAwMDAwMDEgDQo+IDAwMDAwMDAwYzAwMDAwODAgMDAwMDAwMDAwMDAwMDAw MQ0KPiAoWEVOKSBbwqDCoCA4OC4wMDM0ODddwqDCoMKgIGZmZmY4MzEwMGMxMWQwMDAgZmZm ZjgzMTA1MTBkN2U4MCANCj4gZmZmZjgyZDA0MDMwYjU4MCAwMDAwMDAwMDAwMDAwMDAwDQo+ IChYRU4pIFvCoMKgIDg4LjAwMzQ4OV3CoMKgwqAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMx MDUxMGQ3ZjA4IA0KPiBmZmZmODMxMDBjMTE5MDAwIGZmZmY4MzEwMGMxMWQwMDANCj4gKFhF TikgW8KgwqAgODguMDAzNDkyXcKgwqDCoCAwMDAwMDAwMDAwMDAwMDAyIDAwMDAwMDAwMDAw MDAwMDAgDQo+IGZmZmY4MzEwNTEwZDdlZjggZmZmZjgyZDA0MDJlNzFkYg0KPiAoWEVOKSBb wqDCoCA4OC4wMDM0OTRdwqDCoMKgIGZmZmY4MmQwNDAyMDI0ZjIgZmZmZjgyZDA0MDIwMjRm OCANCj4gZmZmZjgyZDA0MDIwMjRmMiBmZmZmODJkMDQwMjAyNGY4DQo+IChYRU4pIFvCoMKg IDg4LjAwMzQ5N13CoMKgwqAgZmZmZjgyZDA0MDIwMjRmMiBmZmZmODJkMDQwMjAyNGY4IA0K PiBmZmZmODJkMDQwMjAyNGYyIGZmZmY4MmQwNDAyMDI0ZjgNCj4gKFhFTikgW8KgwqAgODgu MDAzNDk5XcKgwqDCoCBmZmZmODMxMDBjMTFkMDAwIDAwMDAwMDAwMDAwMDAwMDAgDQo+IDAw MDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KPiAoWEVOKSBbwqDCoCA4OC4wMDM1 MDJdwqDCoMKgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDdjZWZhZWYyODBkNyANCj4gZmZmZjgy ZDA0MDIwMjU0MiAwMDAwMDAwMDAwMDAwMDAwDQo+IChYRU4pIFvCoMKgIDg4LjAwMzUwNF3C oMKgwqAgZmZmZmY4N2JkOWUwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIA0KPiAwMDAwMDAwMDAw MDAwNDAwIGZmZmZlNzAwMDAwMDVhNDANCj4gKFhFTikgW8KgwqAgODguMDAzNTA3XSBYZW4g Y2FsbCB0cmFjZToNCj4gKFhFTikgW8KgwqAgODguMDAzNTA4XcKgwqDCoCBbPGZmZmY4MmQw NDAyM2I1ODA+XSBSIG9uX3NlbGVjdGVkX2NwdXMrMHg5YS8weGQ0DQo+IChYRU4pIFvCoMKg IDg4LjAwMzUxMl3CoMKgwqAgWzxmZmZmODJkMDQwMzFmYWMyPl0gUyBhcmNoL3g4Ni9tbS9o YXAvIA0KPiBoYXAuYyNfX2ZsdXNoX3RsYisweDg0LzB4ZDQNCj4gKFhFTikgW8KgwqAgODgu MDAzNTE0XcKgwqDCoCBbPGZmZmY4MmQwNDAzMWZiMzM+XSBGIGFyY2gveDg2L21tL2hhcC8g DQo+IGhhcC5jI2ZsdXNoX3RsYisweDIxLzB4MjcNCj4gKFhFTikgW8KgwqAgODguMDAzNTE4 XcKgwqDCoCBbPGZmZmY4MmQwNDAzMDk4ZDI+XSBGIGh2bV9mbHVzaF90bGIrMHgyMS8weDJh DQo+IChYRU4pIFvCoMKgIDg4LjAwMzUyMF3CoMKgwqAgWzxmZmZmODJkMDQwMzEzZTk0Pl0g RiBhcmNoL3g4Ni9odm0vIA0KPiBuZXN0ZWRodm0uYyNuZXN0ZWRodm1fZmx1c2h0bGJfaXBp KzB4MzYvMHg1MQ0KPiAoWEVOKSBbwqDCoCA4OC4wMDM1MjJdwqDCoMKgIFs8ZmZmZjgyZDA0 MDIzYjZiMT5dIEYgDQo+IHNtcF9jYWxsX2Z1bmN0aW9uX2ludGVycnVwdCsweDYzLzB4ZDIN Cj4gKFhFTikgW8KgwqAgODguMDAzNTI1XcKgwqDCoCBbPGZmZmY4MmQwNDAzN2FiNjg+XSBG IA0KPiBzbXBfc2VuZF9jYWxsX2Z1bmN0aW9uX21hc2srMHgzYy8weDNmDQo+IChYRU4pIFvC oMKgIDg4LjAwMzUyN13CoMKgwqAgWzxmZmZmODJkMDQwMjNiNTlmPl0gRiBvbl9zZWxlY3Rl ZF9jcHVzKzB4YjkvMHhkNA0KPiAoWEVOKSBbwqDCoCA4OC4wMDM1MjldwqDCoMKgIFs8ZmZm ZjgyZDA0MDMxM2ZjZT5dIEYgDQo+IG5lc3RlZGh2bV92bWN4X2ZsdXNodGxiKzB4MjEvMHg0 Yg0KPiAoWEVOKSBbwqDCoCA4OC4wMDM1MzJdwqDCoMKgIFs8ZmZmZjgyZDA0MDMzMDE2ND5d IEYgDQo+IHAybV9mbHVzaF90YWJsZV9sb2NrZWQrMHhiOC8weDE2Nw0KPiAoWEVOKSBbwqDC oCA4OC4wMDM1MzRdwqDCoMKgIFs8ZmZmZjgyZDA0MDMzMDI1OT5dIEYgYXJjaC94ODYvbW0v IA0KPiBwMm0uYyNwMm1fZmx1c2hfdGFibGUrMHg0Ni8weDMzMA0KPiAoWEVOKSBbwqDCoCA4 OC4wMDM1MzddwqDCoMKgIFs8ZmZmZjgyZDA0MDMzMDViYz5dIEYgDQo+IHAybV9mbHVzaF9u ZXN0ZWRwMm0rMHg0Mi8weDRmDQo+IChYRU4pIFvCoMKgIDg4LjAwMzU0MF3CoMKgwqAgWzxm ZmZmODJkMDQwMzBiMjVmPl0gRiBodm1fc2V0X2VmZXIrMHgxNWEvMHgxNjcNCj4gKFhFTikg W8KgwqAgODguMDAzNTQzXcKgwqDCoCBbPGZmZmY4MmQwNDAzMGI1ODA+XSBGIA0KPiBodm1f bXNyX3dyaXRlX2ludGVyY2VwdCsweDMxNC8weDNmOA0KPiAoWEVOKSBbwqDCoCA4OC4wMDM1 NDZdwqDCoMKgIFs8ZmZmZjgyZDA0MDJlNzFkYj5dIEYgDQo+IHN2bV92bWV4aXRfaGFuZGxl cisweDEyZTkvMHgxOTI1DQo+IChYRU4pIFvCoMKgIDg4LjAwMzU0OV3CoMKgwqAgWzxmZmZm ODJkMDQwMjAyNTQyPl0gRiANCj4gc3ZtX2FzbV9kb19yZXN1bWUrMHgxNjIvMHgxNzINCj4g KFhFTikgW8KgwqAgODguMDAzNTUwXQ0KPiAoWEVOKSBbwqDCoCA4OC41MTEyODddDQo+IChY RU4pIFvCoMKgIDg4LjUxMzcxNF0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KPiAoWEVOKSBbwqDCoCA4OC41MjA0MjldIFBhbmljIG9uIENQVSAxMToNCj4g KFhFTikgW8KgwqAgODguNTI0NjAwXSBBc3NlcnRpb24gJ2xvY2FsX2lycV9pc19lbmFibGVk KCknIGZhaWxlZCBhdCANCj4gY29tbW9uL3NtcC5jOjUzDQo+IChYRU4pIFvCoMKgIDg4LjUz MzQ0OV0gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiANCg0K SSBkaWRuJ3QgbWFkZSB0ZXN0aW5nIGFyb3VuZCBuZXN0ZWQgdmlydCwgSSBndWVzcyBJIG5l ZWQgdG8gaW52ZXN0aWdhdGUgDQptb3JlIG9uIHRoaXMgY2FzZS4NCg0KPiBSb3NzDQoNCg== --------------TiQbcPbcRGxP9nCxRii9P66V-- --------------9YSV82vC95ZDfyhI4bYj32Qy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGAIew9LzHY3pdrqtZg+p0QLLz9AFAmqxKDYFAwAAAAAACgkQZg+p0QLLz9DV RgwAlBCT0BIk6qErker/ejyI6qdoLOXBXcehbz4TdagRJYRvOiJLyefb/3MgJeUX7oP4Q/pFInHh JuwHXxvwtRuQNTVU4Gt+WfGJMzF8JG6jRc6Ee1H34sDNYcR9/Ll/oTNfoILz6VPRDjtsPGdEQn5r E6puMR48d3io1OxtThJMQXRXfMGloYP6EZSYKK2eeL9w9TMEswQDEo4haaDHSSROqvR0lBCPUHie Z7PaWHCgsm+ga5Mczj995hC0vDvOFOdeQAyUFahcD22BTqtKPJE7UR8ezqqptI99lEH2l2DJsZs/ UaqzNwGwn9vxaWw4/121Ezzkemb0VkGJTwRqesWSHrPKBhiYdJlLGvtNdMQHPcm6xjx2G+T7N2SE rnmK71nECGiR+6J3SHf47nyfyvw3UUlRbb/djg/xX579l+QM0qNYBKkqqPDPNtitlURNXyAfv89O Szo68U4Bgr9utaII709qTHh5N5tjuU//BKHlKbxwufs7ifrwzH/0UkOSqi7V =Gysj -----END PGP SIGNATURE----- --------------9YSV82vC95ZDfyhI4bYj32Qy-- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 13:07:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 13:07:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427472.1650170 (Exim 4.92) (envelope-from ) id 1x8djd-00074q-TC; Mon, 21 Sep 2026 13:07:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427472.1650170; Mon, 21 Sep 2026 13:07:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8djd-00074j-Ps; Mon, 21 Sep 2026 13:07:05 +0000 Received: by outflank-mailman (input) for mailman id 1427472; Mon, 21 Sep 2026 13:07:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8djc-00074d-J4 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:07:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8djb-006gR3-LI for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:07:04 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab12bed-bab6-0a2a0a5309dd-0a2a45018a90-38 for ; Mon, 21 Sep 2026 15:07:02 +0200 Received: from [51.83.49.234] (helo=1.mo17.mail-out.ovh.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab12bf5-5984-0a2a45010019-335331eac877-3 for ; Mon, 21 Sep 2026 15:07:01 +0200 Received: from director1.derp.mail-out.ovh.net (director1.derp.mail-out.ovh.net [79.137.60.221]) by mo17.mail-out.ovh.net (Postfix) with ESMTPS id 4hpNmN6xM4z82jT; Mon, 21 Sep 2026 13:07:00 +0000 (UTC) Received: from director1.derp.mail-out.ovh.net (director1.derp.mail-out.ovh.net. [127.0.0.1]) by director1.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Mon, 21 Sep 2026 13:07:00 +0000 (UTC) Received: from mta3.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.110.58.168]) by director1.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4hpNmN4r0rz6GrY; Mon, 21 Sep 2026 13:07:00 +0000 (UTC) Received: from mailstore7.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.1.8.7]) by mta3.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTP id C7A14941C53; Mon, 21 Sep 2026 13:06:59 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo-selector-1 header.d=trinity-net.com header.i="@trinity-net.com" header.h=From Date: Mon, 21 Sep 2026 13:06:59 +0000 (UTC) From: Support TRINITY To: Thorsten Leemhuis Cc: regressions , linux-acpi , linux-pm , stable , xen-devel , linux-kernel Message-ID: <8375109.285919554.1789996019673.JavaMail.zimbra@trinity-net.com> In-Reply-To: <8aaad113-1952-4655-978d-0cdd8b048064@leemhuis.info> References: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> <8aaad113-1952-4655-978d-0cdd8b048064@leemhuis.info> Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [185.208.84.41] X-Authenticated-User: support@trinity-net.com Thread-Topic: ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot Thread-Index: xFt9ystRsn0Dmv4s3yH1kJqjVpPWwg== x-ovh-tracer-id: 3167156440896468507 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: dmFkZTEHV8uBM0suxcILPQHuI4B8S1OlSB/YHVb8/g14zw22rJSYP6YTO3+DnqnA+Iiq/RUcQphEfXjDQ/UHfZZSRJNBTelxXbMRNo3B0LhXj3vb0nz7rj1ftl80sdRSdU+oOTu0saDMx0LVlG6WOGEqrqskthR2jdSTt/m2u4IWuJa+w4JHgqqm3bofnzgYZpue/RkXIZtFa6K1rRNM6DEitB5WBe4SeO6p8zXCFjrVomW2QLcnNQPNdv8+vC1FxRa52dzN59qcPZ5o+LlrnzTh84iUnjzdKGw0B/OBYdviw4vd1Ytcba8j7YxDIHQnBvrObdbKHApuFDwTESa88H6ObHc8Qpf0kIMm5KQGY76Vgq/nmjcmlpm3/WsIJxP9rJ0XzKduzBF2pfhPzpVG/m9x9wE42vnJDzk/0u9Klx7f/4Aqcqcv8VX46u3StkL/4QXyF1ZJgJUUSOK88EcjfPcjYladpDkqwrhuGI3+9CqS6owu58W5g1iIFxUQ88WPn/zfdGO9Mr+EUIVBk2+d6X1m+J0O4oZVS8AsQnvHFKSOntrHeUqs8fwukXDiKFOpaDYXKNLmYHXW3NBy3oZWCWU8/9bfzy8003z/9iAhiVVZzehFLAkFTlcZKZEAaN3QVu6H4/nqzz5+FfiZU4y4JY4d0tvBdf22J9dWgJsYyWSGFRDEJQ DKIM-Signature: a=rsa-sha256; bh=QD4uKSRlS28zp5D1m/z675fqJs3w1celrAPe2tovDvQ=; c=relaxed/relaxed; d=trinity-net.com; h=From; s=ovhmo-selector-1; t=1789996021; v=1; b=vTiMaFm6OJNBaQJZhBE6oZXC6f+0KXjkr0BPkQ0mDJ9O0sKMaJAAUVD8gVPYo2XQXRZHoEVY woIukHkU1/wY4grSFnD1ep7In4CdeKPQfEC8dpZ6xkYSIK0J6RUc3ykHMxt13Hycc7+593qgcxP 9qEwYu6k6BvnPWRAut4BRcVnH32ar2bmS85enSKkK3c36/6nrL0VCyrscLliGcMZ2dkMN8MAokS XCuI+DJ69RWcpSpVD+s+mdNZPBcGXsPloVYNG/Mye6bTjmlx82d2id5VliQG8KYGRjSIi8hX8/u 7kW1WAQKTjB101q9b4AW3pJ3pEM2+GmieCKPhv6F0wsZw== X-purgate-ID: tlsNG-d62444/1789996022-C5540757-C65B7C7D/0/0 X-purgate-type: clean X-purgate-size: 4963 Hello Thorsten, Thanks for the follow-up. I have not tested latest 7.3-rc yet. So far, the regression was only tested= and isolated on the Alpine linux-lts 6.18.51 -> 6.18.52 path. I will now test: latest 7.3-rc as-is on the affected bare-metal Xen dom0 host; latest 7.3-rc with the same partial ACPI processor/cpuidle lifecycle revert= applied. I will report back with the results. Regards, Tony -----Message original----- De: Thorsten Leemhuis =C3=A0: Support TRINITY ; regressions ; linux-acpi ; linux-pm ; stable ; xen-devel ; linux-kernel Envoy=C3=A9: lundi 21 septembre 2026 12:01 CEST Sujet : Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks ba= re-metal Xen dom0 boot On 9/20/26 17:48, Support TRINITY wrote: > > I am reporting a bare-metal *Xen* dom0 boot regression seen with *Linux > 6.18.52.* Thx for the report. There is one somewhat important detail that was missing (hope I didn't miss it): Is latest 7.3-rc also affected? And if it is: does that partial revert help there, too? Ciao, Thorsten > On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on > bare metal, while Linux 6.18.52 *consistently black-screens before dom0 > userspace/networking comes up.* >=20 > #regzbot introduced: v6.18.51..v6.18.52 > #regzbot title: ACPI processor/cpuidle lifecycle change breaks bare- > metal Xen dom0 boot > #regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/ > work_items/18447 work_items/18447> >=20 > Tested results: >=20 > * Linux 6.18.51-r0, Xen dom0, bare metal: boots > * Linux 6.18.52-r0, Xen dom0, bare metal: black screen before > userspace/network > * Linux 6.18.52-r0, Xen domU: boots > * Linux 6.18.52-r0 with Xenbus notifier change reverted: still fails > * Linux 6.18.52-r0 with only ACPI processor/cpuidle changes reverted: > boots > * Linux 6.18.52-r0 with refined ACPI idle lifecycle patch: boots >=20 > Affected hardware tested: >=20 > * Intel Core i7-4785T thin mini-ITX, 16 GB DDR3 > * Intel N305 thin mini-ITX, 16 GB DDR5 > * Supermicro / Intel Xeon E5-1650, 32 GB DDR3 >=20 > The successful boot used the regular Xen command line: >=20 > multiboot2 /boot/xen.gz cpufreq=3Dxen:performance > module2 /boot/vmlinuz-lts modules=3Dloop,squashfs,sd-mod,usb-storage,xfs = quiet > module2 /boot/initramfs-lts >=20 > No IOMMU workaround, serial console parameter, debug parameter, storage > workaround, or Xen command-line change was required. >=20 > The regression was narrowed to *ACPI processor/cpuidle* changes between > 6.18.51 and 6.18.52, specifically the idle-driver registration lifecycle. >=20 > The working 6.18.51-style behavior registers the ACPI idle driver from > *acpi_processor_power_init()* and unregisters it from > *acpi_processor_power_exit().* >=20 > The failing 6.18.52 behavior registers the ACPI idle driver globally > from *acpi_processor_driver_init()* before *driver_register().* >=20 > A first ACPI-only revert confirmed the regression source. A refined > candidate patch was then prepared to preserve the working ACPI idle > lifecycle while keeping unrelated 6.18.52 safety fixes, including: >=20 > * _LPI bounds checks > * cpufreq notifier cleanup on *acpi_processor_driver_init()* failure >=20 > The refined candidate patch modifies only: >=20 > * *drivers/acpi/processor_driver.c* > * *drivers/acpi/processor_idle.c* > * *include/acpi/processor.h* >=20 > It does not modify Xen, Xenbus, IOMMU, APIC, PCI/ASPM, intel_idle, > syscore, USB, storage, XFS, networking, printk, or the cpuidle core API. >=20 > The earlier cpuidle_disabled() workaround is not included. >=20 > The refined patch has been rebuilt and boot-tested successfully as Xen > dom0 on bare metal on TRINITY-EDGE. >=20 > This issue is currently visible to *Alpine* users because the *Alpine > v3.24 *stable repository contains: >=20 > alpine-release 3.24.2-r0 > *linux-lts 6.18.52-r0* >=20 > Systems tracking Alpine 3.24 stable / latest-stable may therefore > receive Linux 6.18.52 as the default LTS kernel. >=20 > Attachments: >=20 > * revert-acpi-idle-registration-lifecycle.patch > * APKBUILD >=20 > The original Alpine report is here: >=20 > https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447 > >=20 > Please let me know if this should be submitted as a formal patch with > Signed-off-by, or if there is a better upstream fix/dependency that > should be backported instead. >=20 > Regards, >=20 > *Tony BONNIN* >=20 #regzbot introduced: 6cffb59ee50ea4 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 13:07:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 13:07:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427476.1650183 (Exim 4.92) (envelope-from ) id 1x8dkB-0007UP-4i; Mon, 21 Sep 2026 13:07:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427476.1650183; Mon, 21 Sep 2026 13:07:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dkB-0007UI-22; Mon, 21 Sep 2026 13:07:39 +0000 Received: by outflank-mailman (input) for mailman id 1427476; Mon, 21 Sep 2026 13:07:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dkA-0007SW-Eq for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:07:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8dk9-001Gzs-RR for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:07:37 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab12c12-8faa-0a2a0a5109dd-0a2a4508a708-16 for ; Mon, 21 Sep 2026 15:07:37 +0200 Received: from [74.125.228.140] (helo=mail-ej2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab12c19-f659-0a2a45080019-4a7de48cbfd0-3 for ; Mon, 21 Sep 2026 15:07:37 +0200 Received: by mail-ej2-f12.google.com with SMTP id a640c23a62f3a-c254f55eff0so439706866b.0 for ; Mon, 21 Sep 2026 06:07:37 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2a358ff8edsm309389866b.61.2026.09.21.06.07.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 06:07:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789996057; x=1790600857; darn=lists.xenproject.org; h=content-type:in-reply-to:autocrypt:from:content-language:references :to:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=nbudeLwfAr9oq/ZGTRMn4oQtid64vUTUavDW3H+Cnak=; b=gMKNInVlqoUZ0OuuWYA4GS07s0Wlns3vWo1tpgRQA/DB22vUvu/ncARj+mkWeHvxyd gDE/exku6MNE0wEJZMdxUtO/4ziyCMq8wV/q7Keo9kFxhP3MfOPozDQkTjura5m6wEHi uiFSgk7+ik8bST8wPL6D++SWnBOgF1JMOjIejRtCqqdKLS+WSVNJdBD4F/kHwOd/Q7J/ PlCcwgIJ1xRlC1bZiZ5hwFmFYYxDSq3b+12un81p8Sc0/hlWURqfEDL+zMAWHPCtjIzJ dczncI7vVfJTdpC6xHgFlKxuEPa/t4k7v0WdcZZ7alFaXJVjGWaYonuaCy8VVyVwZk8E HDxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789996057; x=1790600857; h=content-type:in-reply-to:autocrypt:from:content-language:references :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 :content-type; bh=nbudeLwfAr9oq/ZGTRMn4oQtid64vUTUavDW3H+Cnak=; b=bScvtqFL6RgsTAjx6XX0R5q1Y7zmMsucZ9hBECd7360UbEHa2eCVvT1qt5mLDyy3nx aFEQnyzn4veAaQUwQaI3nDZ93EMVHMvjg6pWYmJG7capLbSKvoJQ2aA+oedxalWqb70x o+ZKcCmTAzAzdf8qktiWd2SLDeauTD+DaDarUkBbMbmxZpKTzEkik8KuhbuTalBoaHaR ISCKY0m4+kAb3N69H//y1FhZ3zD0Vjo5zuYDHmo24t8auFWI4v138uJLXoJf9/0Cf0Ua psBey52tjsdGxbqfwRMcJu9x7Xmkfs5CGU/3wHzZ2dNuDEqrDYpboD/aKsVMI0uNYIY5 Yjiw== X-Forwarded-Encrypted: i=1; AKwUvBy7UnlxKTzkVNzaMbRHfcewXi2ZQntVa0wsQtb4e+VU9eaByFWZbCZ80sZDCJbeNuEOdQMCwG8sS1A=@lists.xenproject.org X-Gm-Message-State: AFuF++nOjVuvNzAK1+UD44l05Wi57Ls5PTUcvzOyADQQPI7dDc4AZZSa krTaAhlDlsmJO8gKfvjebi+ktFYkr9f/RAm08BBZ1JnplyLfi87pd+eGTsyDaqbMAeE= X-Gm-Gg: AYBFou3tOKK6rXtpeuYqq0V5AocF8Jj4XafZF5n07qWLLljCOpaOA2DU651IrrgYGSW 0Vn0R4i1ScO5o9noGx0BsN0xTgFikYPnUaLgJgzOX0E2/0FsLYLbf6DyCl0rFJA6Xj6xDNhZpsj Cb9Q6TR01w1cqSymsHot9k6D/KtB8EIVtv+90AHgwJ7nKCwRjgrEbdztZ9NsJRCAtWOONuumK5s RLm3VkY8sAWHU6ES71s3IzDCB6JLrLe6i1EaApxWoop+wAyutLL6rsnEpPQSpxCITb5Wo9nLYSk 1EQHI5bMzjuc/mBlAh7Zi+XICWx93sMIzCe0YRXgDVNF1q4Ur7U93m81d56kOIJOnS8kW/Z6cqM 5amxLXW+D0OUPjddEuCjT8QdFkjXVI9W3GThH9SmOxk7/KYZO/Q6mnO5Uwv9bSmDKnpIyJx2D8N vSabqK10JZAskKQOA0Gl7QYQv661eZt7sY1tmOmZP3/esXFsEz9eTZcG7eKRSEpjUAoGQ+bwnCj F/JGEvhW/At0Qd5lJDLup1VsEVMP3B9hln6vMDruWWd4QPF26PNScgkDwoPynu0uFJ5BiSQPX0Y c6iM6EVRIy5zxYfBomy/e1aEKsrRVS6XSoc= X-Received: by 2002:a17:907:948a:b0:c25:68c2:7b94 with SMTP id a640c23a62f3a-c2a156595dcmr885996666b.8.1789996057145; Mon, 21 Sep 2026 06:07:37 -0700 (PDT) Message-ID: <1f814c72-6fa2-4177-8da0-e17e0406e473@suse.com> Date: Mon, 21 Sep 2026 15:07:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] stubdom: remove pciutils To: Samuel Thibault , Jan Beulich , xen-devel@lists.xenproject.org, Anthony PERARD References: Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------T0Q9AglYbuwjn9X0Cp79imCv" X-purgate-ID: tlsNG-c1860d/1789996057-CD94A87B-40D73CAE/35/110847 X-purgate-type: clean X-purgate-size: 10300 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------T0Q9AglYbuwjn9X0Cp79imCv Content-Type: multipart/mixed; boundary="------------uXWrswsV74pQfI2mCP07Ag2V"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Samuel Thibault , Jan Beulich , xen-devel@lists.xenproject.org, Anthony PERARD Message-ID: <1f814c72-6fa2-4177-8da0-e17e0406e473@suse.com> Subject: Re: [PATCH 2/4] stubdom: remove pciutils References: In-Reply-To: Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------uXWrswsV74pQfI2mCP07Ag2V Content-Type: multipart/mixed; boundary="------------ULdRt57aM0dnajw0JzDvTfsX" --------------ULdRt57aM0dnajw0JzDvTfsX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTkuMDkuMjYgMTg6NTcsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4gSGVsbG8sDQo+ IA0KPiBJIGhhdmUgc3VibWl0dGVkIHRoZSBwY2l1dGlscyBNaW5pT1MgcG9ydCB0byB1cHN0 cmVhbSAod2hpY2ggSSBzaG91bGQNCj4gcHJvYmFibHkgaGF2ZSBkb25lIDE4IHllYXJzIGFn byA6KQ0KPiANCj4gaHR0cHM6Ly9naXRodWIuY29tL3BjaXV0aWxzL3BjaXV0aWxzL3B1bGwv MjM1DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9wY2l1dGlscy9wY2l1dGlscy9wdWxsLzIzNg0K PiANCj4gSmFuIEJldWxpY2gsIGxlIG1lci4gMTkgYW/Du3QgMjAyNiAwODo0MDozNyArMDIw MCwgYSBlY3JpdDoNCj4+IE9uIDE4LjA4LjIwMjYgMjM6NDIsIFNhbXVlbCBUaGliYXVsdCB3 cm90ZToNCj4+PiBKw7xyZ2VuIEdyb8OfLCBsZSBtYXIuIDE4IGFvw7t0IDIwMjYgMDc6NDM6 MzQgKzAyMDAsIGEgZWNyaXQ6DQo+Pj4+IE9uIDE3LjA4LjI2IDE4OjM3LCBTYW11ZWwgVGhp YmF1bHQgd3JvdGU6DQo+Pj4+PiBKdWVyZ2VuIEdyb3NzLCBsZSBsdW4uIDE3IGFvw7t0IDIw MjYgMTA6MjQ6MDIgKzAyMDAsIGEgZWNyaXQ6DQo+Pj4+IFdoYXQgYWJvdXQgYWRkaW5nIGEg Y29tbWVudCB0byB0aGUgc3R1YmRvbSBNYWtlZmlsZSBpbiBhIHNlcGFyYXRlIHBhdGNoLCBs aWtlOg0KPj4+Pg0KPj4+PiAjIHBjaXV0aWxzIHN1cHBvcnQgaGFzIGJlZW4gcmVtb3ZlZCB3 aXRoIGNvbW1pdCA8Y29tbWl0LWlkPiwgcmV2ZXJ0IHRoYXQgcGF0Y2gNCj4+Pj4gIyBpbiBj YXNlIGl0IGlzIG5lZWRlZCBhZ2Fpbi4NCj4+Pj4NCj4+Pj4gSSB0aGluayB0aGlzIHdvdWxk IGJlIHByZWZlcmFibGUgb3ZlciB1bnVzZWQgYW5kIHByb2JhYmx5IGJpdC1yb3R0ZW4gY29k ZSBpbg0KPj4+PiB0aGUgcmVwb3NpdG9yeS4NCj4gDQo+IFdlIGNhbiBwb2ludCBwZW9wbGUg dG8gcGNpdXRpbHMgdGhyb3VnaCBzdWNoIGEgY29tbWVudC4NCj4gDQo+IErDvHJnZW4gR3Jv w58sIGxlIG1lci4gMTkgYW/Du3QgMjAyNiAwOToxMjowMCArMDIwMCwgYSBlY3JpdDoNCj4+ IE9uIDE4LjA4LjI2IDIzOjQyLCBTYW11ZWwgVGhpYmF1bHQgd3JvdGU6DQo+Pj4gSSBkb24n dCBzZWUgd2h5IGl0IHdvdWxkIGJlIGJpdC1yb3R0ZW4sIHNpbmNlIHRoZSBwY2l1dGlscyB2 ZXJzaW9uIGluDQo+Pj4gdXNlZCBpcyBmaXhlZCwgaXQncyBhIGxpYnJhcnkgdGhhdCBoYXMg YSBxdWl0ZSBzdGFibGUgQVBJLCBhbmQgdGhlIHBjaQ0KPj4+IHhlbiBpbnRlcmZhY2UgaXMg c3VwcG9zZWQgdG8ga2VlcCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5Lg0KPj4NCj4+IFRoZW4g SSdkIHJhdGhlciBhZGQgaXQgdG8gTWluaS1PUyAocHJvYmFibHkgYmVoaW5kIGFub3RoZXIg Q09ORklHIG9wdGlvbikgdGhhbg0KPj4gaGF2aW5nIGl0IGluIHRoZSBYZW4gdHJlZS4NCj4g DQo+IE1tbSwgYnV0IGhvdz8gV2UgZG9uJ3QgcmVhbGx5IHdhbnQgdG8gcHVsbCB0aGUgd2hv bGUgcGNpdXRpbHMgYnVpbGQgaW50bw0KPiBtaW5pLW9zIDopDQoNClRCSCwgSSBkb24ndCBz ZWUgd2h5IHRoZSB3aG9sZSBNaW5pLU9TIHNwZWNpZmljIHN0dWJkb20gbWF6ZSBzaG91bGQg YmUgaW4gdGhlDQpYZW4gcmVwb3NpdG9yeS4gVGhpbmtpbmcgYWJvdXQgdGhlIGhvb3BzIEkg aGFkIHRvIGp1bXAgdGhyb3VnaCBmb3IgZG9pbmcgc29tZQ0Kb2YgdGhlIE1pbmktT1MgY2xl YW51cHMgKGVzcGVjaWFsbHkgcmVnYXJkaW5nIGNvbmZpZyBvcHRpb25zKSwgaGF2aW5nIGFs bCBvZg0KdGhlIHN0dWJkb20gc3R1ZmYgaW4gTWluaS1PUyBvciBhbiBleHRyYSByZXBvc2l0 b3J5IHdvdWxkIHByb2JhYmx5IGJlIGNsZWFuZXIuDQoNClRoaXMgaXMgdHJ1ZSBlc3BlY2lh bGx5IG5vdywgYXMgbm9uZSBvZiB0aGUgc3R1YmRvbSByZW1haW5zIHJlYWxseSBkZXBlbmQg b24NCnRoZSBYZW4gdmVyc2lvbiBhbnkgbG9uZ2VyIChhcGFydCBmcm9tIHRoZSByZXF1aXJl bWVudCB0byB1c2UgYSBmYWlybHkgbmV3DQpYZW4pLg0KDQpPVE9IIGJlZm9yZSBtb3Zpbmcg c3R1YmRvbSB0byBNaW5pLU9TLCBVTklLUkFGVCBzZWVtcyB0byBiZSBhIHZhbGlkIGFsdGVy bmF0aXZlLg0KDQoNCkp1ZXJnZW4NCg== --------------ULdRt57aM0dnajw0JzDvTfsX Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------ULdRt57aM0dnajw0JzDvTfsX-- --------------uXWrswsV74pQfI2mCP07Ag2V-- --------------T0Q9AglYbuwjn9X0Cp79imCv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqxLBgFAwAAAAAACgkQsN6d1ii/Ey8U Rwf/SVdGsCtZjGZ7wyYcLHmhac5kCtjgS/pjRDllMNZo9i00L31KlJtTb4vZeJkkRaVV5pqdat0W x1tHVyhMA6VzpPWxXA2yJSCXrN3LWi4tqBdF4mTdatZq+wG4/6BO7CuQMS/lVk5IQsQHbX9Nx1Tj QJIiojsTcJtkWCGMi/xwuIaZwOwCfPptSMWe0q89zXnPy2usFm+QfMQ/JfEgqpisxtWwHdJT3nPg TQW4qOGmg6R69A876oCgR0sO4dn49drN+u+pvRFWuTMAA4UpHNk2VvnwJtyrIlstGk+AlgCgpUQI MxgxmJ/np2t8yhZL5gvTT7WXCkXwk2qRpmz9rGerRw== =6o/a -----END PGP SIGNATURE----- --------------T0Q9AglYbuwjn9X0Cp79imCv-- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 13:10:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 13:10:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427488.1650197 (Exim 4.92) (envelope-from ) id 1x8dmt-0000sK-Ic; Mon, 21 Sep 2026 13:10:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427488.1650197; Mon, 21 Sep 2026 13:10:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dmt-0000sD-FL; Mon, 21 Sep 2026 13:10:27 +0000 Received: by outflank-mailman (input) for mailman id 1427488; Mon, 21 Sep 2026 13:10:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dms-0000s7-QC for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:10:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8dms-004c6H-6y for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:10:26 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab12cb7-2eae-0a2a0a5409dd-0a2a45089868-34 for ; Mon, 21 Sep 2026 15:10:26 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab12cc1-f659-0a2a45080019-b9ff1c12a51d-3 for ; Mon, 21 Sep 2026 15:10:26 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c416b9f500072c4.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 21 Sep 2026 13:10:18 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 0A2438236E; Mon, 21 Sep 2026 15:10:18 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=nCqC2331MjRiCMTlXk/sFtiMnaqgnV+5UhfQCvL7aHA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=fACMaIIOa3n+ji3So+dsMM7/RTxo9JbT40jmT83mOQjk6yP5I3rfCuG2Ws0DktdpiSbWd6QMY /EYGlBSRsN6/KyTgK18gyU0STRY5kd8QcT5tg8FUAHmuBBwxWX4I8CgxfJ36IAXVrzY1634wSW1 vQP3Zc01l/cGko9jcG+34ZVl9tkvG91tMZFLzbhJ00q9jGCQew48yIC+9qThnAb7QMhdw12ospt 0woeeDfl1ZjvUWCNokQo0Tln4Mh7aizZqSJk8et+heO4FcwSLMakaclXRyLF7LiiNDb8389A2I9 e4AYBbo/X4QgknSXWk+i3e0NlaskUhzY+/EDG4cYljbg== X-Zone-Loop: 88dfb9f25510bcbd8d3d0b6b46200586a6e8033c28c1 x-campaign-type: default x-transaction-id: 90b432ab-18b7-4701-8231-689efd1e4384 x-swg-uid: 01-a6e60efc-8944-4964-9402-3665669f10c0 X-Mailer: Sweego Message-ID: <1789996218.8631fc262581453bbf619ec5b2062170.1a0c416b9f500072c4@vates.tech> x-swg-bid: 1789996218.8631fc262581453bbf619ec5b2062170.1a0c416b9f500072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 21 Sep 2026 15:10:17 +0200 From: Anthony PERARD To: Julian Vetter Cc: xen-devel@lists.xenproject.org, Oleksii Kurochko , Community Manager , Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie Subject: Re: [PATCH v5 3/6] tools/arm: choose GIC version explicitly instead of relying on GIC_NATIVE References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130863.8631fc262581453bbf619ec5b2062170.1a090827272000c4f3@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1789130863.8631fc262581453bbf619ec5b2062170.1a090827272000c4f3@vates.tech> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2aa.ba8194a23281630a.1a0c416b7e2.953cc8d2724fa953=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1789996218338 X-purgate-ID: tlsNG-c1860d/1789996226-CE94287B-B3A48B91/0/0 X-purgate-type: clean X-purgate-size: 3349 ---=Part.2aa.ba8194a23281630a.1a0c416b7e2.953cc8d2724fa953=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 11, 2026 at 02:47:33PM +0200, Julian Vetter wrote: > diff --git a/docs/man/xl=2Ecfg=2E5=2Epod=2Ein b/docs/man/xl=2Ecfg=2E5=2E= pod=2Ein > index d34951edb9=2E=2E6a5e75eeab 100644 > --- a/docs/man/xl=2Ecfg=2E5=2Epod=2Ein > +++ b/docs/man/xl=2Ecfg=2E5=2Epod=2Ein > @@ -3081,15 +3081,16 @@ Emulate a GICv2 > Emulate a GICv3=2E Note that the emulated GIC does not support the > GICv2 compatibility mode=2E > =20 > -=3Ditem B > +=3Ditem B > =20 > -Emulate the same version as the native GIC hardware used by the host wh= ere > -the domain was created=2E > +Let the toolstack choose the GIC version: GICv3 if the host supports it= , > +otherwise GICv2=2E This is the default when C is not speci= fied=2E > =20 > =3Dback > =20 > This requires hardware compatibility with the requested version, either > -natively or via hardware backwards compatibility support=2E > +natively or via hardware backwards compatibility support=2E The GIC ver= sions > +the host can emulate for a guest are reported via C=2E I'm sorry, but I don't think this information is useful in a man page of a CLI=2E As a user of `xl`, I have no idea what XEN_SYSCTL_physinfo mean=2E=2E=2E or how to call it=2E > diff --git a/tools/include/xen-tools/arm-arch-capabilities=2Eh b/tools/i= nclude/xen-tools/arm-arch-capabilities=2Eh > index 4aa4c6c34a=2E=2E21e3c73bd1 100644 > diff --git a/tools/libs/light/libxl_arm=2Ec b/tools/libs/light/libxl_arm= =2Ec > index 7e9f8a1bc3=2E=2E283cfb749b 100644 > --- a/tools/libs/light/libxl_arm=2Ec > +++ b/tools/libs/light/libxl_arm=2Ec > @@ -1800,6 +1797,48 @@ int libxl__arch_domain_build_info_setdefault(libx= l__gc *gc, > /* Trapping of unmapped accesses enabled by default=2E */ > libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, true); > =20 > + /* > + * Resolve the GIC version against the host capabilities reported b= y > + * XEN_SYSCTL_physinfo=2E If the user didn't request a specific ver= sion, pick > + * the best one available=2E Otherwise validate the requested versi= on here, > + * so a bad request fails early instead of in the hypervisor=2E > + */ > + { > + bool has_v3 =3D arch_capabilities_arm_gic_v3(physinfo->arch_cap= abilities); > + bool has_v2 =3D arch_capabilities_arm_gic_v2(physinfo->arch_cap= abilities); > + > + switch (b_info->arch_arm=2Egic_version) { > + case LIBXL_GIC_VERSION_NONE: > + if (has_v3) > + b_info->arch_arm=2Egic_version =3D LIBXL_GIC_VERSION_V3= ; > + else if (has_v2) > + b_info->arch_arm=2Egic_version =3D LIBXL_GIC_VERSION_V2= ; > + else { > + LOG(ERROR, "No supported GIC version found on this host= "); > + return ERROR_FAIL; > + } As you use a block for the else case, could you use a block for every branch of the if ? Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.2aa.ba8194a23281630a.1a0c416b7e2.953cc8d2724fa953=--- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 13:19:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 13:19:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427500.1650215 (Exim 4.92) (envelope-from ) id 1x8dva-0001mn-Hs; Mon, 21 Sep 2026 13:19:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427500.1650215; Mon, 21 Sep 2026 13:19:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dva-0001me-EV; Mon, 21 Sep 2026 13:19:26 +0000 Received: by outflank-mailman (input) for mailman id 1427500; Mon, 21 Sep 2026 13:19:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8dvY-0001mY-SF for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:19:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8dvX-00DHcR-5U for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:19:23 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab12edb-2eae-0a2a0a5409dd-0a2a450acac4-0 for ; Mon, 21 Sep 2026 15:19:23 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab12eda-f2d2-0a2a450a0019-4a7de14ca92d-3 for ; Mon, 21 Sep 2026 15:19:23 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-48449f62b93so982667f8f.0 for ; Mon, 21 Sep 2026 06:19:22 -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 ffacd0b85a97d-48724591eaasm22819134f8f.26.2026.09.21.06.19.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 06:19:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789996762; x=1790601562; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=wesuiiPKWwECUVFEKc2smBqRk4pjb0hFu7bZpfujw/U=; b=Tmjt78yDGxGJwtbF0aCTer2+8ZQrZy72Jwc7X5DdPx2pHYHb5LjQgyp5g5IuHhXEvs 2whoZrsh2wfq0mreaDvuIoXpu5EwaxZb8yU45FdEXB3hM3Yn4qZbSsJx0zB9+fJyn2zA HCuUDRcNdGZSgZKeh9/IeiBkwfF2Pssa2PLa5JwDwBfFe79wAq5fJATbtMoaBSHYsw78 8l1q1k5bOoif/+u1sf7j7GveSh/ZHEcgXw5W8rFJNybMEQafyNKKVxiGNDCM6ptkt7Rg s0vFeUZueVZyMM3OIBkGx1y6mcr2NLh8t6p+FEjEMPnnmiXKYpsqgX1kXY4EA4pgWMoi FhfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789996762; x=1790601562; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wesuiiPKWwECUVFEKc2smBqRk4pjb0hFu7bZpfujw/U=; b=en3KbxrukNLplrObczhAMcj1BHhaQCPDS4HRrRJjPwQMf+dRgrJrpL6U+SpZvwfSCD 5OWqoTx6JLD7NyjBor312PE5x/VF0ae99rWqd0aTfFrm1sCDqVPF4UNMF5hfCflVR4Og 1xxMMauxunqIa5wsUpe9x2wAS2iBDBVY+JueUHGDNlBxRg1aDUsPuCogkzorj9K7/c+H Bwdy41K9GQWpYorswcMhbZNz8jHHltXZZgK4u35Hh3Eg5oUW2b3roF2timEEqp6MUzsz IpYQ+sdV+z094UFJerVM4aWkvlfrwzPmX8oERHfOs7rcLJdi8U6uEpTxaVSstxYfpGrr s6gg== X-Gm-Message-State: AFuF++kVejtZkDevwWAiIFnSieiH5Fg/IoxBBonB8VP+Pp652GTIt7tP 1KtvTinwk1WRCKCwtgumkxXQXwp909hB/VPAkZiNDLyuYfacotzRnwV9RNCrK00tQ9c0wy1ZXF8 cBYrosA== X-Gm-Gg: AYBFou0YKnutHmLeuUzxk9nwmEH7JTCawRf91e7diVkXq4W44hPXQmz0UTd/dIhXpXH PylsC5jwUrGGNXSzsyfLO6bs4WxS/UtYd0LXlKt5/f7ujGdofoj9Ftiun1U1b3OtvRN1rXp7sKq mhU3nt8dIj4LoLFFLx5AUd8dlCQhZRjHXCEb+Y9fbBccjLa0ecaFesReadFNziKnp7F9sLkJIU0 Xdcl1OxR/rqksSM7l+lVtMVXAmUWvRqY0nX881T2ZtATK1ssbdwa/8NxoddGQOFcJPUIyH8jKxC kzzuSy8D3a1P10aIQHDvPkibtK2WymPbWMuWp+VMFpRU8KsUhKzOpPsGPsMrWtf3sBixgP2Yxj/ 4UJ7i0YGrc+ocTReWf1MQRFloT7syNJ5CRLdLr92mMsHev0uUwSjCjaZP8IDZpRVjogIa/Wzapc xukpScK4Z56BpsEbEtZg2f+sCZvYBmOFi+23JWxejtFGSrAhIBUU6BQfzBqZAZjJcxNryMJbCt/ MwONPNMLyQ1btuhmSz4wg5cEyZZTk/BLddp7wxMNjwOPp7qD8muX3kIoUEVdA== X-Received: by 2002:a05:6000:25c8:b0:488:5589:d358 with SMTP id ffacd0b85a97d-4885589d3efmr7698166f8f.18.1789996762440; Mon, 21 Sep 2026 06:19:22 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 15:19:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/HVM: replace paging_mode_hap() uses 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1789996763-508CDCFC-114C4D77/0/0 X-purgate-type: clean X-purgate-size: 10516 HVM guests cannot run without either HAP or shadow enabled. While paging_mode_shadow() is compile-time-constant when SHADOW_PAGING=n, paging_mode_hap() isn't. Hence the former is preferred to leverage DCE. In svm_update_guest_cr() combine two adjacent conditionals. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -473,7 +473,7 @@ static int __init pvh_populate_p2m(struc } } - if ( using_vmx() && paging_mode_hap(d) && !vmx_unrestricted_guest(v) ) + if ( using_vmx() && !paging_mode_shadow(d) && !vmx_unrestricted_guest(v) ) { /* * Since Dom0 cannot be migrated, we will only setup the --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -8,7 +8,7 @@ #include #include #include -#include /* paging_mode_hap */ +#include /* paging_mode_(hap|shadow)() */ #include /* for local_event_delivery_(en|dis)able */ #include /* p2m_get_pagetable, p2m_get_nestedp2m */ #include @@ -243,7 +243,7 @@ static int nsvm_vcpu_hostrestore(struct /* host nested paging + guest nested paging. */ /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ } - else if ( paging_mode_hap(v->domain) ) + else if ( !paging_mode_shadow(v->domain) ) { /* host nested paging + guest shadow paging. */ /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ @@ -525,7 +525,7 @@ static int nsvm_vmcb_prepare4vmrun(struc if ( rc != X86EMUL_OKAY ) gdprintk(XENLOG_ERR, "hvm_set_cr3 failed, rc: %u\n", rc); } - else if ( paging_mode_hap(v->domain) ) + else if ( !paging_mode_shadow(v->domain) ) { /* host nested paging + guest shadow paging. */ vmcb_set_np(n2vmcb, true); @@ -1033,7 +1033,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, * unshadowed guest h_cr3 is kept in ns_vmcb->h_cr3, * hence we keep the ns_vmcb->h_cr3 value. */ } - else if ( paging_mode_hap(v->domain) ) + else if ( !paging_mode_shadow(v->domain) ) { /* host nested paging + guest shadow paging. */ vmcb_set_np(ns_vmcb, false); @@ -1260,7 +1260,7 @@ nestedsvm_check_intercepts(struct vcpu * /* host nested paging + guest nested paging */ return NESTEDHVM_VMEXIT_HOST; } - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { if ( is_intercepted ) return NESTEDHVM_VMEXIT_FATALERROR; @@ -1559,7 +1559,7 @@ void svm_nested_features_on_efer_update( if ( nsvm_efer_svm_enabled(v) ) { if ( !vmcb->virt_ext.fields.vloadsave_enable && - paging_mode_hap(v->domain) && + !paging_mode_shadow(v->domain) && cpu_has_svm_vloadsave ) { vmcb->virt_ext.fields.vloadsave_enable = 1; --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -113,7 +113,8 @@ static void cf_check svm_update_guest_cr switch ( cr ) { case 0: - if ( paging_mode_hap(v->domain) ) + value = v->arch.hvm.guest_cr[0]; + if ( !paging_mode_shadow(v->domain) ) { uint32_t intercepts = vmcb_get_cr_intercepts(vmcb); @@ -122,9 +123,7 @@ static void cf_check svm_update_guest_cr monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) ) vmcb_set_cr_intercepts(vmcb, intercepts | CR_INTERCEPT_CR3_WRITE); } - - value = v->arch.hvm.guest_cr[0]; - if ( paging_mode_shadow(v->domain) ) + else value |= X86_CR0_PG | X86_CR0_WP; vmcb_set_cr0(vmcb, value); break; @@ -148,7 +147,7 @@ static void cf_check svm_update_guest_cr break; case 4: value = HVM_CR4_HOST_MASK; - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) value &= ~X86_CR4_PAE; value |= v->arch.hvm.guest_cr[4]; @@ -418,7 +417,7 @@ static int svm_vmcb_restore(struct vcpu svm_update_guest_cr(v, 0, 0); svm_update_guest_cr(v, 4, 0); - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { vmcb_set_np(vmcb, true); vmcb_set_g_pat(vmcb, MSR_IA32_CR_PAT_RESET /* guest PAT */); @@ -2519,7 +2518,7 @@ void asmlinkage svm_vmexit_handler(void) regs, !(vmcb_get_efer(vmcb) & EFER_LMA) || !(vmcb->cs.l)); v->arch.hvm.guest_cr[2] = vmcb_get_cr2(vmcb); - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { v->arch.hvm.guest_cr[0] = vmcb_get_cr0(vmcb); v->arch.hvm.guest_cr[3] = v->arch.hvm.hw_cr[3] = vmcb_get_cr3(vmcb); --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -143,7 +143,7 @@ static int construct_vmcb(struct vcpu *v vmcb->_exception_intercepts = HVM_TRAP_MASK; - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { vmcb_set_np(vmcb, true); /* enable nested paging */ vmcb->_g_pat = MSR_IA32_CR_PAT_RESET; /* guest PAT */ --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -1141,7 +1141,7 @@ static int construct_vmcs(struct vcpu *v SECONDARY_EXEC_ENABLE_VM_FUNCTIONS | SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS); - if ( paging_mode_hap(d) ) + if ( !paging_mode_shadow(d) ) { v->arch.hvm.vmx.exec_control &= ~(CPU_BASED_INVLPG_EXITING | CPU_BASED_CR3_LOAD_EXITING | @@ -1203,7 +1203,7 @@ static int construct_vmcs(struct vcpu *v vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_CS, VMX_MSR_RW); vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_ESP, VMX_MSR_RW); vmx_clear_msr_intercept(v, MSR_IA32_SYSENTER_EIP, VMX_MSR_RW); - if ( paging_mode_hap(d) && (!is_iommu_enabled(d) || iommu_snoop) ) + if ( !paging_mode_shadow(d) && (!is_iommu_enabled(d) || iommu_snoop) ) vmx_clear_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW); if ( (vmexit_ctl & VM_EXIT_CLEAR_BNDCFGS) && (vmentry_ctl & VM_ENTRY_LOAD_BNDCFGS) ) @@ -1327,7 +1327,7 @@ static int construct_vmcs(struct vcpu *v __vmwrite(VMCS_LINK_POINTER, ~0UL); v->arch.hvm.vmx.exception_bitmap = HVM_TRAP_MASK - | (paging_mode_hap(d) ? 0 : (1U << X86_EXC_PF)); + | (!paging_mode_shadow(d) ? 0 : (1U << X86_EXC_PF)); if ( cpu_has_vmx_notify_vm_exiting ) __vmwrite(NOTIFY_WINDOW, vm_notify_window); @@ -1347,7 +1347,7 @@ static int construct_vmcs(struct vcpu *v __vmwrite(TPR_THRESHOLD, 0); } - if ( paging_mode_hap(d) ) + if ( !paging_mode_shadow(d) ) { struct p2m_domain *p2m = p2m_get_hostp2m(d); struct ept_data *ept = &p2m->ept; @@ -1377,7 +1377,7 @@ static int construct_vmcs(struct vcpu *v vmx_vlapic_msr_changed(v); - if ( opt_l1d_flush && paging_mode_hap(d) ) + if ( opt_l1d_flush && !paging_mode_shadow(d) ) rc = vmx_add_msr(v, MSR_FLUSH_CMD, FLUSH_CMD_L1D, VMX_MSR_GUEST_LOADONLY); --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1707,7 +1707,7 @@ static void cf_check vmx_update_guest_cr if ( paging_mode_shadow(v->domain) ) hw_cr0_mask |= X86_CR0_WP; - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { /* Manage GUEST_CR3 when CR0.PE=0. */ uint32_t old_ctls = v->arch.hvm.vmx.exec_control; @@ -1772,7 +1772,7 @@ static void cf_check vmx_update_guest_cr /* Fallthrough: Changing CR0 can change some bits in real CR4. */ case 4: v->arch.hvm.hw_cr[4] = HVM_CR4_HOST_MASK; - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) v->arch.hvm.hw_cr[4] &= ~X86_CR4_PAE; if ( !nestedhvm_vcpu_in_guestmode(v) ) @@ -1792,7 +1792,7 @@ static void cf_check vmx_update_guest_cr * two subtly complicated cases. */ - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { /* * On hardware lacking the Unrestricted Guest feature (or with @@ -1824,7 +1824,7 @@ static void cf_check vmx_update_guest_cr * unconditionally trapping more CR4 bits, at which point the * performance benefit of doing this is quite dubious. */ - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { /* * Update CR4 host mask to only trap when the guest tries to set @@ -1860,7 +1860,7 @@ static void cf_check vmx_update_guest_cr break; case 3: - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) ) v->arch.hvm.hw_cr[3] = @@ -4190,7 +4190,7 @@ void asmlinkage vmx_vmexit_handler(struc hvm_sanitize_regs_fields(regs, !(cs_ar_bytes & X86_SEG_AR_CS_LM_ACTIVE)); - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) { /* * Xen allows the guest to modify some CR4 bits directly, update cached @@ -4977,7 +4977,7 @@ bool asmlinkage vmx_vmenter_helper(const if ( unlikely(need_flush) ) vpid_sync_all(); - if ( paging_mode_hap(curr->domain) ) + if ( !paging_mode_shadow(curr->domain) ) { struct ept_data *ept = &p2m_get_hostp2m(currd)->ept; unsigned int cpu = smp_processor_id(); --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -2458,7 +2458,7 @@ int nvmx_n2_vmexit_handler(struct cpu_us */ if ( vector == X86_EXC_PF ) { - if ( paging_mode_hap(v->domain) ) + if ( !paging_mode_shadow(v->domain) ) nvcpu->nv_vmexit_pending = 1; } else if ( (intr_info & valid_mask) == valid_mask ) From xen-devel-bounces@lists.xenproject.org Mon Sep 21 13:24:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 13:24:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427524.1650286 (Exim 4.92) (envelope-from ) id 1x8e0b-0003pZ-NH; Mon, 21 Sep 2026 13:24:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427524.1650286; Mon, 21 Sep 2026 13:24:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8e0b-0003pS-Jg; Mon, 21 Sep 2026 13:24:37 +0000 Received: by outflank-mailman (input) for mailman id 1427524; Mon, 21 Sep 2026 13:24:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8e0a-0003p4-JR for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:24:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8e0Z-00HIAx-S3 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:24:35 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1300d-8faa-0a2a0a5109dd-0a2a4509ddbc-12 for ; Mon, 21 Sep 2026 15:24:35 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab13013-be1a-0a2a45090019-4a7de14ced68-3 for ; Mon, 21 Sep 2026 15:24:35 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f633ece3so2289002f8f.3 for ; Mon, 21 Sep 2026 06:24:35 -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 ffacd0b85a97d-487244229d5sm23866013f8f.2.2026.09.21.06.24.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 06:24:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1789997075; x=1790601875; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=lN3f4g6EEth6PzAQzBFAZRMSXOjaInLqdUI9Im+f83s=; b=R/bDHD45SGi1z08PxEJlLWZ5Z8cua5L7Ub3fQ38KJZ+0Rn2uCdq1cAswehl78+AlXq KM4a42lPtK/I3uARMruNFsl9a4UZIb1lv9cLhVzBXAPqgQiuyjSXV/g0rYbooVBN80jF CVU4LnjNCZ4dBwF0E8ovP8rQ1vcFh6lErBG2BrrQgSx7NYNX3P+/Hd+Zg4k4ozzCrwFJ 0DdSu2PvLC4tbChXh8a6KeVRbClRMsYXKF72TzRJ1XWzi1ftsxOG0zaNS2uqnJV174T4 iub9DIJGOuzh8CkpL+7PNByGbJRH6cOPBbDj8nUzfmdQJjtmHa1n+f9Dm91Uqf9yY+oC Ok4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789997075; x=1790601875; h=content-transfer-encoding:content-type: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:content-type; bh=lN3f4g6EEth6PzAQzBFAZRMSXOjaInLqdUI9Im+f83s=; b=QpsN2SADO6MN4gFYeLjc+jlzWrxXPISy2FQxMaOF+o5Eoa2YterhDxsCZaMRlpnexg l2iweKkJXQOxWEhRbuHZYGXezPyAtHxuZFHcJ158hvZDzckGArOhaShBwr/xFjWgHsKw VLngkRWV/yejAOU7djIl96ADXvb9mVJq6UQbgTIEVqT1UZ7xtA+PqTAqMEK9zsQgn2uX WIPvTO2iNtuU9IcrB56meHv4VCH+Q0c6oY6hTPTcgO3QAMD98l/5/hcJaQSWfxDdvFgT pnHqLeNnmxWb1S6vacElPFrjBZ7wnWTD+kI7guzlLuog/0DV6umzQvVlR/GGiueGIGmf 5XGw== X-Forwarded-Encrypted: i=1; AKwUvBwgLSPKkv8qOzF3cW2Fm+73OBGCRyt9oXNfQkJ24yk9G6nhfLo1VATaQPlPH3av3IeLvUEJ5rkE+dQ=@lists.xenproject.org X-Gm-Message-State: AFuF++k70vLz9aOZJokireF23FLTP/aXxPEj49eSlq3r5aK6GwBoq472 mdIb8dCjE5gjJC0fhVpg3n4W51Ca5VHB5uH2D8lwy8+LszvMc8YTQFjIV3bYYLvOog== X-Gm-Gg: AYBFou3K+pgZEthKgKKn5GDEAwRlyrFW80jHSpLBQ8PnBjKOWa54nlxWTX6GkL6SZhw 53jyIbjZHi8tUFqo2WJyeo77xWYsEvLmlngjBfwze2gh3dqSy8kKYw3GMdq2auQCtb51evCFQhP Br/Eufnz/KNsRro92HMI3QsI7UX0vyGfCwhOLDyzOnS9wFi7LGct4E98z0QHTdlTVbQiJDg3zy8 HPmbDX2bGCj2lQyhKJuCEN+L2aTV7iAGn2RNRbQ9Q6qt0bni64umZ6Vp6tSqexZKyC2PbYuJp89 EK8GVBkUvMYwzQuPJhbrJBMz3wVLaBXyVQZGWp1AT9UT69H1fmAGG/GguW4m4kBi5mpaYqdJvA4 ec5AQNovCRvNMvto7lZE9LuuZueT2A3DtKIb623rUP/nfzBxavnLM0EdOOGjr99JwTGsU/Q0i7c J3aBT7Hg89YyKbe+1HR5rqZPkIQW6knARWVRbiBPqn1I+LkwGmp48V95HwVlmgV+dcUSPDRq6Sv F5ZJoC8KK/JyoSoHhB0oRbV3VEmd9cmex1ak5HSZgkCfJ5HkLyVF+fLv74S9n8= X-Received: by 2002:a05:6000:220e:b0:487:9a8:9f31 with SMTP id ffacd0b85a97d-4871e368258mr16252151f8f.41.1789997075058; Mon, 21 Sep 2026 06:24:35 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 15:24:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 4/5] x86/hvm: Transition to needs_tlb_flush logic, use per-domain ASID To: Teddy Astie , Ross Lagerwall Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Jason Andryuk , Tim Deegan , xen-devel@lists.xenproject.org References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509309.8631fc262581453bbf619ec5b2062170.19fb8a5ecef000e099@vates.tech> <0b4a8cb9-e398-43a5-8f68-2c36d245c88d@citrix.com> <1789995064.8631fc262581453bbf619ec5b2062170.1a0c4051b5b00072c4@vates.tech> 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: <1789995064.8631fc262581453bbf619ec5b2062170.1a0c4051b5b00072c4@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1789997075-FDC6D034-F6934EA9/0/0 X-purgate-type: clean X-purgate-size: 4906 On 21.09.2026 14:51, Teddy Astie wrote: > Le 18/09/2026 à 18:30, Ross Lagerwall a écrit : >> On 7/31/26 3:46 PM, Teddy Astie wrote: >>> --- a/xen/arch/x86/hvm/asid.c >>> +++ b/xen/arch/x86/hvm/asid.c >>> @@ -5,138 +5,115 @@ >>>    * Copyright (c) 2009, Citrix Systems, Inc. >>>    */ >>> +#include >>>   #include >>>   #include >>>   #include >>> -#include >>> -#include >>> -#include >>> +#include >>> +#include >>> + >>> +#include >>>   #include >>>   /* Xen command-line option to enable ASIDs */ >>>   static bool __read_mostly opt_asid_enabled = true; >>>   boolean_param("asid", opt_asid_enabled); >>> +bool __read_mostly asid_enabled = false; >>> +static unsigned long __ro_after_init *asid_bitmap; >>> +static unsigned long __ro_after_init asid_count; >>> +static DEFINE_SPINLOCK(asid_lock); >>> + >>>   /* >>> - * ASIDs partition the physical TLB.  In the current implementation >>> ASIDs are >>> - * introduced to reduce the number of TLB flushes.  Each time the >>> guest's >>> - * virtual address space changes (e.g. due to an INVLPG, MOV-TO-{CR3, >>> CR4} >>> - * operation), instead of flushing the TLB, a new ASID is assigned. >>> This >>> - * reduces the number of TLB flushes to at most 1/#ASIDs.  The biggest >>> - * advantage is that hot parts of the hypervisor's code and data >>> retain in >>> - * the TLB. >>> - * >>>    * Sketch of the Implementation: >>> + * ASIDs are assigned uniquely per domain and doesn't change during >>> the lifecycle of the >>> + * domain. Once vcpus are initialized and are up, we assign the same >>> ASID to all vcpus >>> + * of that domain at the first VMRUN. In order to process a TLB flush >>> on a vcpu, we set >>> + * needs_tlb_flush to schedule a TLB flush for the next VMRUN (e.g >>> using tlb control >>> + * field of VMCB). >>>    * >>> - * ASIDs are a CPU-local resource.  As preemption of ASIDs is not >>> possible, >>> - * ASIDs are assigned in a round-robin scheme.  To minimize the >>> overhead of >>> - * ASID invalidation, at the time of a TLB flush,  ASIDs are tagged >>> with a >>> - * 64-bit generation.  Only on a generation overflow the code needs to >>> - * invalidate all ASID information stored at the VCPUs with are run >>> on the >>> - * specific physical processor.  This overflow appears after about 2^80 >>> - * host processor cycles, so we do not optimize this case, but simply >>> disable >>> - * ASID useage to retain correctness. >>> + * We reserve ASID=1 as being the ASID used when none other is >>> available (or with asid >>> + * use disabled). Multiples domains may use this ASID, thus we need >>> to systematically >>> + * flush the TLB for this one when switching between vCPUs with ASID=1. >>>    */ >>> -/* Per-CPU ASID management. */ >>> -struct hvm_asid_data { >>> -   uint64_t core_asid_generation; >>> -   uint32_t next_asid; >>> -   uint32_t max_asid; >>> -   bool disabled; >>> -}; >>> - >>> -static DEFINE_PER_CPU(struct hvm_asid_data, hvm_asid_data); >>> - >>> -void hvm_asid_init(unsigned int nasids) >>> +int __init hvm_asid_init(unsigned long nasids) >>>   { >>> -    static int8_t __ro_after_init g_disabled = -1; >>> -    struct hvm_asid_data *data = &this_cpu(hvm_asid_data); >>> +    ASSERT(nasids); >>> -    data->max_asid = nasids - 1; >>> -    data->disabled = !opt_asid_enabled || (nasids <= 1); >>> +    asid_count = nasids; >>> +    asid_enabled = opt_asid_enabled && (nasids > 1); >>> -    if ( g_disabled < 0 ) >>> -    { >>> -        g_disabled = data->disabled; >>> -        printk("HVM: ASIDs %sabled\n", data->disabled ? "dis" : "en"); >>> -    } >>> -    else if ( g_disabled != data->disabled ) >>> -        printk("HVM: CPU%u: ASIDs %sabled\n", smp_processor_id(), >>> -               data->disabled ? "dis" : "en"); >>> +    asid_bitmap = xvzalloc_array(unsigned long, >>> BITS_TO_LONGS(asid_count + 1)); >>> +    if ( !asid_bitmap ) >>> +        return -ENOMEM; >> >> Should there be a sanity check to avoid an excessive allocation? E.g. If >> running under another hypervisor, it might set nasids to ~0 while with >> one per >> domain we need no more than ~64k. > > Indeed, I didn't consider that AMD had (and enumerates) 32-bits ASIDs. > Only Intel uses 16-bits VPIDs. > > Limiting to 64k seems wise, Why 64k, when there can be at most 32k domains? > the remaining question is that I'm not sure > if we want to make that configurable. Unless there are significant savings to be had, I'd say stick to the smaller of what hardware offers and 32k. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 13:39:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 13:39:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427548.1650344 (Exim 4.92) (envelope-from ) id 1x8eEk-00069V-BV; Mon, 21 Sep 2026 13:39:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427548.1650344; Mon, 21 Sep 2026 13:39:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eEk-00069O-8J; Mon, 21 Sep 2026 13:39:14 +0000 Received: by outflank-mailman (input) for mailman id 1427548; Mon, 21 Sep 2026 13:39:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eEi-00069I-Vl for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:39:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8eEi-00CeaP-8q for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:39:12 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab13369-e002-0a2a0a5209dd-0a2a4501ee10-46 for ; Mon, 21 Sep 2026 15:39:12 +0200 Received: from [40.93.195.52] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1337e-5984-0a2a45010019-285dc3349f90-3 for ; Mon, 21 Sep 2026 15:39:11 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SA3PR03MB020706.namprd03.prod.outlook.com (2603:10b6:806:591::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 13:39:08 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 13:39:07 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uqwyuzpskpk6dwDFeNjv9lC2vwM5rQFBNYIF8dC7UYQ1e3MygS8jjf6hgZOsLcytRGIphMYTXAD22i6CWjFJ8sYlIRYLAP9h7+4sPPKxqQPE8EbYFmnH8oEjp3Qyaa8KU8wH0R11Tec3TrokS2efI/q62Dfw1GNMWipJJLtQ+HMKFHxmLmUMGy0iLf8HetCYMGXuDpfHWOoxH7TyZX3JtC/5Yl4osz3d7Otq6FiRMdgBZXOTQAoqifh38JgrwvtP68iCl3xiQaMYQVis2MZejyf656Q3762nJVts2QtjWw3TzXGWAuV+60LZTnz7pbzpOlxkugm8OeuRU/M3eSb1jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WrLFG9FFUFFZmttykjJC+qRvnHJhAxZQltz3JBjvxHw=; b=h8EDuxRd8JF2F6QiqxQl/bZoXOp46g3fpPo37sUS79bj6KCbT0CQofLv6R1DjnZCJVMsHwkrqmvdx1Zm3sfntzefaDrg0x6Xhe41DtYwzfTwDpnVpskObuzRnOOIJc38+H4ACJ9r9O5IddA0wBLtxe+SqnZu7PzZBWcfEcPVWuMxFQRcvLvjfQWn5vnNcNIOMnTDIhfIRnoaIJGkhnXzp1daKNtR7Fe7l/E4chVdCA6Zr+a8GlUQ5UdznpFJPHxFe3VnIgmizjRNiBlx6rzMFoWESNPr/5L05HGgdMnFYcqPa3i2m8L6XZwoHPbJ61cjAAlEEfiLHcldcWad8aP8Gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WrLFG9FFUFFZmttykjJC+qRvnHJhAxZQltz3JBjvxHw=; b=MqqLoZa8sWgOkaKI1Q6v9iUWGXCTh12elJNUS0xnamEDci0ctiplThqgrP09pKQeIAcdwNEisLqBh/d51gOyFBXObcX0w3JhQYnMrN791jhFRZUowJLr93oWc7WIuQhmbC+2HxolBF9G1fdGBe/2xbbSWsVFk1mDfit/tmBb3tw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <14cc2bd1-168f-4420-ab1d-5d2d76315ec9@citrix.com> Date: Mon, 21 Sep 2026 14:39:01 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 4/5] x86/hvm: Transition to needs_tlb_flush logic, use per-domain ASID To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Jason Andryuk , Tim Deegan References: <1785509179.8631fc262581453bbf619ec5b2062170.19fb8a3efe8000e099@vates.tech> <1785509309.8631fc262581453bbf619ec5b2062170.19fb8a5ecef000e099@vates.tech> <0b4a8cb9-e398-43a5-8f68-2c36d245c88d@citrix.com> <1789995064.8631fc262581453bbf619ec5b2062170.1a0c4051b5b00072c4@vates.tech> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <1789995064.8631fc262581453bbf619ec5b2062170.1a0c4051b5b00072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DU2PR04CA0328.eurprd04.prod.outlook.com (2603:10a6:10:2b5::33) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SA3PR03MB020706:EE_ X-MS-Office365-Filtering-Correlation-Id: e958b353-ca7d-4f07-fc20-08df17e5b5eb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|7416014|376014|6133799003|3023799007|10067099003|11063799006|4143699003|56012099006|5023799004|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: FBmqYvsKNNT20BqVD1UpuJHpqdINz9JRLxczTYw8so82F81gC7D31YY8TksIAPdM7ikbDVPOlSJtEctbTzrQIihhi0vF9w5V+t03uNw+ba47gu1SedqW8fEj96uh/dvk0GyhyF+VtltFqEnqHbsl+nGwOVWl4aI4o/8P0vC2Rkk+oPtPtLCKmSimr7dCNy5OvxmT5r4C9xyc9LmbvByyuHn1jNVJOxFuEvafbeoxDM2F9+/eNjyVQkJ7Pl2LIdIgx2TQr1lMYHnWaQfLKiyLWN6e9wvGf1BV0i+ClKn3YNW16pq9ERzNP4GhihNcHxJEzra4ytcniN78tymSxZDezeKCZtfZdRobntm45m/xtj3CmvqN47moWmETls355uJS3Pj+BFmARHyNw0lDg88JxK5BpknvTdHuhC7vvxPJ6f9bD5rY2xW9EIHaCSWPR2qc8b/j9smmbxB3beyT5O4C6SpPwV4SoUIFxdqGB1eETIlKieLZ+XTuPm88jg7XlyqJiWKXQUunKQwSjFVe8fVLZ21dbsZ21kDdU1UQGAimNWoN2/rHKeaz4RX87ZzGenjXNFBd5skJGaZ+VRI1MJDgN8n2abEdRkK7GHO3lVd7yXF8S0MaQpYmueV6GfILbVeEczoIm+o11JGE73tW/5Crz8r8nZ9zDsW88OJGKV44XiQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(7416014)(376014)(6133799003)(3023799007)(10067099003)(11063799006)(4143699003)(56012099006)(5023799004)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aUJrV3lqYm9tYVJyTTZaay9DSlhEeklFZHloaDhsWGJ1UDY1NVFZbHlySUZ1?= =?utf-8?B?aFlVb0NlR0dIeTAyaWpSOUVZOFR5aDNvOUdDL3hNeGorYW1mcGFheDNwNkdm?= =?utf-8?B?RDkwSTdjYkRXR2xWaDk3M0tNUkt4dU40R0d5RURXSS90MWpOcWpBSEZ0TGZt?= =?utf-8?B?RTRYc01Hd0tyUVFSaXNzVkhQaG9CTUNGUGpJeUo2cEFYWnFUVzdOd1dYZEQw?= =?utf-8?B?dEVjajJNRlduNVQ0Qm8zR2Jyd0tvYmtVWlBiKzNEbC9tVllRNUpaNS9iSmxl?= =?utf-8?B?VXBreVlsYUZFMXR1OXFob1JyVEt4T0g2czI3Z0F5NU80WWhhSW9ndGFEb1Yz?= =?utf-8?B?ZEptUUVHUUplSDNlcHBHTVlveGYzbmw1NXkrR1d5QmhrQW5FWWVzZzBqZXhC?= =?utf-8?B?Ym1YRWFEMVRmU3N3ZlkvQ001WXd4dkRGQVVpNCszT3dxOHpuMGJvUWdtMHNv?= =?utf-8?B?WEZ0TGQwUDVWZmxsU0tDMWdzT1pkS3ZHeXBRYWRvazhHMGtsN3Z6NGtpUHJH?= =?utf-8?B?R0dZR2FnV0NNZjRqRERGbjl6NnREK3o0a1lGWGM5aWozaDJHOEwwN0Y0S3Vj?= =?utf-8?B?S21RMkI1R2gwVXVZTTdGQ3pBYVlSWGQ4MlE3SkJZaGFIdkl5eGpvbm5jL0Mr?= =?utf-8?B?c0JjdjhiY0phWDQzYVpybVlGQklCOE5WN3BtUG9ZUWY2c1Q5Wm5qVG1OWkVU?= =?utf-8?B?N21BRGZjQUJYbWpnWllMYTR2YVRFZWhabS9rVFB3NzV0WGh1WmV0cU5hcUl2?= =?utf-8?B?V01lQSttaGNkcGdMenkrVDJPVEJ0SlpIKzhKZFdHcUE0djJJWGJrWE9vTGli?= =?utf-8?B?REg3TjVDUXhyS25aWVFnTHc5V0xtM0pMV2VxM1hucjN1TDdnNHUvSDExTzgr?= =?utf-8?B?cU14UzUybndQckw0M0ZLdzFhODROcm9NUStKeE1ZRTcrdDEyb3hWNW5udDhT?= =?utf-8?B?cXpVOHg0b1Y3OFRQQkJLaUVPQmNZRWhFby9yNXRPaEJUVkNTYmNpRXcxczZs?= =?utf-8?B?WkpiRVl3bTN2cEpHTUdPaGFuVlUxYlVqSDNqWVYyLzhzQkNwQnN0K3QweENI?= =?utf-8?B?SWpZRlBzNWtNNmk0TStJcHpkS05aYkw3ZDZuV3Q4eFZ1MkxyQ1hUazVkenhj?= =?utf-8?B?TWJQZG5WdVRrZ28rbVpoLzAvWnp1N1N5MmdIbXhZQmw4VlBOS3dzTlhxbTVr?= =?utf-8?B?YWpuYUZoSGk3NDhpMUo5QThPMHRCQkI5dUtJZG5GaVl4RURtaTQyaS9LekVl?= =?utf-8?B?dGloejdRMkdPQlBHZEM5RzlDcXVGamJQSDRQNlBrWTlxOGdFVW1XMjFWQ2s3?= =?utf-8?B?My9mTWVtYnJGL3FxeklMRlMxd1BqS1Jxa09kSW1kU2p0YzUvTU1OdG0xL0lu?= =?utf-8?B?eWx5WEpvTHBHUWh0Z0pkK1c2SGRSVUY3WENCNVppU042cEpVaE1QR0xXbUtk?= =?utf-8?B?czY4YmlqSmtNOERzdUNTSXg3eHlKcmM0SDlIRjFyVjNicmkxNzNqOG5FWUhy?= =?utf-8?B?ZnVFcm50NTQ3NFp6cENwSmxOa2x3ODF2eGlpM1ZSdTI1enpwSWFjNDk3KzhE?= =?utf-8?B?U2ZPY0hNUnl3aEg2N0MwTEZXL29iQ2VWQnlhQkxFZjBlVU5JZ2gxTGFaWXpx?= =?utf-8?B?K1FRdHFVWGxXWVJsY0c0UWc2V1lOM0tqRmlMenFUMU9lSUY5cEpCODlSMHVC?= =?utf-8?B?OStNQzlPNXhmejB1MjFFTGdSZmtaeXgyVGJVd2o4b3Iwd01sNkVHQ3BRL09r?= =?utf-8?B?L3RhU2EvSC82WnNGRWROWXZkU2R5YWhHSnRnUUFhVkszRG1HNVh4MzNRVHcx?= =?utf-8?B?MU9IQ29Banpmelh3ekdiUWRsTVVPUEZoWVphTlRmSHdwTDJrOGhpL3FxYTVz?= =?utf-8?B?TnJRV09FdVEvM1VhUVZtWDZhRVpQUnQxUUZWZy9sa3FJYkovbUNwME41WUN0?= =?utf-8?B?M0JKcXY4SXdFVGQ1RnFmcGZLOUU1ZDhwb1Z1OWE4bko0cHFCdDdIbDhhTDlV?= =?utf-8?B?ZGxGeWliZ0tqQmp5RWlNVkVlWTN1QVBHV1htRXgxK2hmaXZ2NWlKcGQ5cFdF?= =?utf-8?B?V09iL1FLSjFYcDlMNlArR1Bjd21sU2k2Q2FGN3U5WDdXdU1NRjJFSUVVMlg2?= =?utf-8?B?RzU4dDR0enJVV2JOMHJFdDNGOFJSenZBbkxsTDFhcTdiVzFSN1RGN3NuMnVn?= =?utf-8?B?QTV0SWhzOVNoVjRHQUR1VG80MXZ6YkZVdGJMT2gyK2w0MFJBanVMNVhCbkxI?= =?utf-8?B?TEVIY1NOMTlRWlFmaC9ONlZlbUU0MXhPWEpVaEFKd3FobWpzSURIUnIveVZk?= =?utf-8?B?S08wdkdsYy80M1dNeVRsUkZtbFNrY2lSclVyYk8wK21HKzlnR0JDWDZSYVRa?= =?utf-8?Q?0ALvkBvfWOshICcs=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e958b353-ca7d-4f07-fc20-08df17e5b5eb X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 13:39:07.8922 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: u5Y0x/AQlCPW4KA9t4OgzOLgD3rnCDq9Tc3NzXACHl5oZ15fPIlt6I1GaUQIfEFu49x3S1N0Rjv/DwkV4hWro2ugImcD/FE1iJkysoTNIws= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB020706 X-purgate-ID: tlsNG-d62444/1789997952-BD67C4F7-9AD95341/0/0 X-purgate-type: clean X-purgate-size: 62213 On 9/21/26 1:51 PM, Teddy Astie wrote: > Le 18/09/2026 à 18:30, Ross Lagerwall a écrit : >> On 7/31/26 3:46 PM, Teddy Astie wrote: >>> Change the ASID model where all vCPU of a domain share the same ASID >>> as required by AMD SEV and broadcast TLB flushing features (AMD INVLPGB). >>> >>> ASID 1 is reserved as a placeholder for "no domain ASID", and used when >>> either ASID are not supported or no more ASID is available for use. >>> In this case, we always flush the TLB when from and to such domain's >>> vCPU. >>> >>> Moreover, centralize the TLB flushing logic to use needs_tlb_flush, if >>> a full TLB flush needs to be performed for the vCPU, either through >>> SVM tlb_control or VMX invvpid before entering the guest. >>> >>> As a result, drop ASID tickling logic, which is now redundant with the >>> needs_tlb_flush mechanism introduced previously. Also take the opportunity >>> to drop some now unused helpers now that FLUSH_HVM_ASID_CORE is dropped. >>> >>> Signed-off-by: Teddy Astie >>> --- >>> This patch is particularly hard to split as the required changes needs >>> to come all at once. >>> >>> Some questions : >>> - On Intel, with "ASID disabled", should we distinguish between using sentinel >>> "VPID=1" (with single-context flush of VPID=1) with disabling VPID (through >>> SECONDARY_EXEC_ENABLE_VPID) which implies flushing all VPID=0 (Xen/PV ones) TLB >>> entries on vmenter ? >>> Of course, hardware without VPID support can't use VPID=1 and will behave with >>> VPID disabled. >>> >>> - I tested it on both Intel and AMD platforms without much issues, but didn't >>> performed tests with nested virt which has tricky interactions with these >>> changes. >>> >>> docs/misc/xen-command-line.pandoc | 2 +- >>> xen/arch/x86/flushtlb.c | 22 +--- >>> xen/arch/x86/hvm/asid.c | 169 +++++++++++-------------- >>> xen/arch/x86/hvm/emulate.c | 2 +- >>> xen/arch/x86/hvm/hvm.c | 14 +- >>> xen/arch/x86/hvm/nestedhvm.c | 7 +- >>> xen/arch/x86/hvm/svm/asid.c | 67 +++++++--- >>> xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- >>> xen/arch/x86/hvm/svm/svm.c | 35 +++-- >>> xen/arch/x86/hvm/svm/svm.h | 4 - >>> xen/arch/x86/hvm/vmx/vmcs.c | 6 +- >>> xen/arch/x86/hvm/vmx/vmx.c | 66 +++++----- >>> xen/arch/x86/hvm/vmx/vvmx.c | 4 +- >>> xen/arch/x86/include/asm/flushtlb.h | 7 - >>> xen/arch/x86/include/asm/hvm/asid.h | 30 ++--- >>> xen/arch/x86/include/asm/hvm/domain.h | 1 + >>> xen/arch/x86/include/asm/hvm/hvm.h | 15 +-- >>> xen/arch/x86/include/asm/hvm/svm.h | 5 + >>> xen/arch/x86/include/asm/hvm/vcpu.h | 10 +- >>> xen/arch/x86/include/asm/hvm/vmx/vmx.h | 4 +- >>> xen/arch/x86/mm/hap/hap.c | 9 +- >>> xen/arch/x86/mm/p2m.c | 6 +- >>> xen/arch/x86/mm/paging.c | 2 +- >>> xen/arch/x86/mm/shadow/multi.c | 12 +- >>> 24 files changed, 241 insertions(+), 260 deletions(-) >>> >>> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen- command-line.pandoc >>> index 1c711fa980..f59c14d447 100644 >>> --- a/docs/misc/xen-command-line.pandoc >>> +++ b/docs/misc/xen-command-line.pandoc >>> @@ -208,7 +208,7 @@ to appropriate auditing by Xen. Argo is disabled by default. >>> > Default: `true` >>> Permit Xen to use Address Space Identifiers. This is an optimisation which >>> -tags the TLB entries with an ID per vcpu. This allows for guest TLB flushes >>> +tags the TLB entries with an ID per domain. This allows for guest TLB flushes >>> to be performed without the overhead of a complete TLB flush. >>> ### async-show-all (x86) >>> diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c >>> index 5e2ed50ec9..478a3f4962 100644 >>> --- a/xen/arch/x86/flushtlb.c >>> +++ b/xen/arch/x86/flushtlb.c >>> @@ -13,6 +13,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -119,7 +120,6 @@ void switch_cr3_cr4(struct vcpu *v, unsigned long cr3, unsigned long cr4) >>> if ( tlb_clk_enabled ) >>> t = pre_flush(); >>> - hvm_flush_guest_tlbs(); >>> old_cr4 = read_cr4(); >>> ASSERT(!(old_cr4 & X86_CR4_PCIDE) || !(old_cr4 & X86_CR4_PGE)); >>> @@ -224,9 +224,6 @@ unsigned int flush_area_local(const void *va, unsigned int flags) >>> do_tlb_flush(); >>> } >>> - if ( flags & FLUSH_HVM_ASID_CORE ) >>> - hvm_flush_guest_tlbs(); >>> - >>> if ( flags & (FLUSH_CACHE_EVICT | FLUSH_CACHE_WRITEBACK) ) >>> { >>> const struct cpuinfo_x86 *c = ¤t_cpu_data; >>> @@ -316,18 +313,13 @@ void cache_writeback(const void *addr, unsigned int size) >>> asm volatile ("sfence" ::: "memory"); >>> } >>> -unsigned int guest_flush_tlb_flags(const struct domain *d) >>> -{ >>> - bool shadow = paging_mode_shadow(d); >>> - bool asid = is_hvm_domain(d) && (cpu_has_svm || shadow); >>> - >>> - return (shadow ? FLUSH_TLB : 0) | (asid ? FLUSH_HVM_ASID_CORE : 0); >>> -} >>> - >>> void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask) >>> { >>> - unsigned int flags = guest_flush_tlb_flags(d); >>> + struct vcpu *v; >>> + >>> + if ( paging_mode_shadow(d) ) >>> + flush_tlb_mask(mask); >>> - if ( flags ) >>> - flush_mask(mask, flags); >>> + for_each_vcpu(d, v) >>> + v->arch.needs_tlb_flush = true; >>> } >>> diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c >>> index 935cae3901..1a21125161 100644 >>> --- a/xen/arch/x86/hvm/asid.c >>> +++ b/xen/arch/x86/hvm/asid.c >>> @@ -5,138 +5,115 @@ >>> * Copyright (c) 2009, Citrix Systems, Inc. >>> */ >>> +#include >>> #include >>> #include >>> #include >>> -#include >>> -#include >>> -#include >>> +#include >>> +#include >>> + >>> +#include >>> #include >>> /* Xen command-line option to enable ASIDs */ >>> static bool __read_mostly opt_asid_enabled = true; >>> boolean_param("asid", opt_asid_enabled); >>> +bool __read_mostly asid_enabled = false; >>> +static unsigned long __ro_after_init *asid_bitmap; >>> +static unsigned long __ro_after_init asid_count; >>> +static DEFINE_SPINLOCK(asid_lock); >>> + >>> /* >>> - * ASIDs partition the physical TLB. In the current implementation ASIDs are >>> - * introduced to reduce the number of TLB flushes. Each time the guest's >>> - * virtual address space changes (e.g. due to an INVLPG, MOV-TO-{CR3, CR4} >>> - * operation), instead of flushing the TLB, a new ASID is assigned. This >>> - * reduces the number of TLB flushes to at most 1/#ASIDs. The biggest >>> - * advantage is that hot parts of the hypervisor's code and data retain in >>> - * the TLB. >>> - * >>> * Sketch of the Implementation: >>> + * ASIDs are assigned uniquely per domain and doesn't change during the lifecycle of the >>> + * domain. Once vcpus are initialized and are up, we assign the same ASID to all vcpus >>> + * of that domain at the first VMRUN. In order to process a TLB flush on a vcpu, we set >>> + * needs_tlb_flush to schedule a TLB flush for the next VMRUN (e.g using tlb control >>> + * field of VMCB). >>> * >>> - * ASIDs are a CPU-local resource. As preemption of ASIDs is not possible, >>> - * ASIDs are assigned in a round-robin scheme. To minimize the overhead of >>> - * ASID invalidation, at the time of a TLB flush, ASIDs are tagged with a >>> - * 64-bit generation. Only on a generation overflow the code needs to >>> - * invalidate all ASID information stored at the VCPUs with are run on the >>> - * specific physical processor. This overflow appears after about 2^80 >>> - * host processor cycles, so we do not optimize this case, but simply disable >>> - * ASID useage to retain correctness. >>> + * We reserve ASID=1 as being the ASID used when none other is available (or with asid >>> + * use disabled). Multiples domains may use this ASID, thus we need to systematically >>> + * flush the TLB for this one when switching between vCPUs with ASID=1. >>> */ >>> -/* Per-CPU ASID management. */ >>> -struct hvm_asid_data { >>> - uint64_t core_asid_generation; >>> - uint32_t next_asid; >>> - uint32_t max_asid; >>> - bool disabled; >>> -}; >>> - >>> -static DEFINE_PER_CPU(struct hvm_asid_data, hvm_asid_data); >>> - >>> -void hvm_asid_init(unsigned int nasids) >>> +int __init hvm_asid_init(unsigned long nasids) >>> { >>> - static int8_t __ro_after_init g_disabled = -1; >>> - struct hvm_asid_data *data = &this_cpu(hvm_asid_data); >>> + ASSERT(nasids); >>> - data->max_asid = nasids - 1; >>> - data->disabled = !opt_asid_enabled || (nasids <= 1); >>> + asid_count = nasids; >>> + asid_enabled = opt_asid_enabled && (nasids > 1); >>> - if ( g_disabled < 0 ) >>> - { >>> - g_disabled = data->disabled; >>> - printk("HVM: ASIDs %sabled\n", data->disabled ? "dis" : "en"); >>> - } >>> - else if ( g_disabled != data->disabled ) >>> - printk("HVM: CPU%u: ASIDs %sabled\n", smp_processor_id(), >>> - data->disabled ? "dis" : "en"); >>> + asid_bitmap = xvzalloc_array(unsigned long, BITS_TO_LONGS(asid_count + 1)); >>> + if ( !asid_bitmap ) >>> + return -ENOMEM; >> >> Should there be a sanity check to avoid an excessive allocation? E.g. If >> running under another hypervisor, it might set nasids to ~0 while with one per >> domain we need no more than ~64k. >> > > Indeed, I didn't consider that AMD had (and enumerates) 32-bits ASIDs. Only Intel uses 16-bits VPIDs. > > Limiting to 64k seems wise, the remaining question is that I'm not sure if we want to make that configurable. > >>> - /* Zero indicates 'invalid generation', so we start the count at one. */ >>> - data->core_asid_generation = 1; >>> + printk("HVM: ASIDs %sabled (count=%lu)\n", asid_enabled ? "en" : "dis", asid_count); >>> - /* Zero indicates 'ASIDs disabled', so we start the count at one. */ >>> - data->next_asid = 1; >>> -} >>> + /* ASID 0 and 1 are reserved, mark it as permanently used */ >>> + set_bit(0, asid_bitmap); >>> + set_bit(1, asid_bitmap); >>> -void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid) >>> -{ >>> - write_atomic(&asid->generation, 0); >>> + return 0; >>> } >>> -void hvm_asid_flush_vcpu(struct vcpu *v) >>> +int hvm_asid_alloc(struct hvm_asid *asid) >>> { >> >> Can this be implemented in terms of hvm_asid_alloc_range() as these functions >> seem to be mostly duplicated? >> > > yes > >>> - hvm_asid_flush_vcpu_asid(&v->arch.hvm.n1asid); >>> - hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); >>> -} >>> + unsigned long new_asid; >>> -void hvm_asid_flush_core(void) >>> -{ >>> - struct hvm_asid_data *data = &this_cpu(hvm_asid_data); >>> + if ( !asid_enabled ) >>> + { >>> + asid->asid = 1; >>> + return 0; >>> + } >>> - if ( data->disabled ) >>> - return; >>> + spin_lock(&asid_lock); >>> + new_asid = find_first_zero_bit(asid_bitmap, asid_count); >>> + if ( new_asid > asid_count ) >>> + return -ENOSPC; >>> - if ( likely(++data->core_asid_generation != 0) ) >>> - return; >>> + set_bit(new_asid, asid_bitmap); >>> - /* >>> - * ASID generations are 64 bit. Overflow of generations never happens. >>> - * For safety, we simply disable ASIDs, so correctness is established; it >>> - * only runs a bit slower. >>> - */ >>> - printk("HVM: ASID generation overrun. Disabling ASIDs.\n"); >>> - data->disabled = 1; >>> + asid->asid = new_asid; >>> + spin_unlock(&asid_lock); >>> + return 0; >>> } >>> -bool hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid) >>> +int hvm_asid_alloc_range(struct hvm_asid *asid, unsigned long min, unsigned long max) >>> { >>> - struct hvm_asid_data *data = &this_cpu(hvm_asid_data); >>> + unsigned long new_asid; >>> + >>> + if ( WARN_ON(min >= asid_count) ) >>> + return -EINVAL; >>> - /* On erratum #170 systems we must flush the TLB. >>> - * Generation overruns are taken here, too. */ >>> - if ( data->disabled ) >>> - goto disabled; >>> + if ( !asid_enabled ) >>> + return -EOPNOTSUPP; >>> - /* Test if VCPU has valid ASID. */ >>> - if ( read_atomic(&asid->generation) == data->core_asid_generation ) >>> - return 0; >>> + spin_lock(&asid_lock); >>> + new_asid = find_next_zero_bit(asid_bitmap, asid_count, min); >>> + if ( new_asid > max || new_asid > asid_count ) >>> + return -ENOSPC; >>> - /* If there are no free ASIDs, need to go to a new generation */ >>> - if ( unlikely(data->next_asid > data->max_asid) ) >>> - { >>> - hvm_asid_flush_core(); >>> - data->next_asid = 1; >>> - if ( data->disabled ) >>> - goto disabled; >>> - } >>> + set_bit(new_asid, asid_bitmap); >>> - /* Now guaranteed to be a free ASID. */ >>> - asid->asid = data->next_asid++; >>> - write_atomic(&asid->generation, data->core_asid_generation); >>> + asid->asid = new_asid; >>> + spin_unlock(&asid_lock); >>> + return 0; >>> +} >>> - /* >>> - * When we assign ASID 1, flush all TLB entries as we are starting a new >>> - * generation, and all old ASID allocations are now stale. >>> - */ >>> - return (asid->asid == 1); >>> +void hvm_asid_free(struct hvm_asid *asid) >>> +{ >>> + ASSERT( asid->asid ); >>> - disabled: >>> - asid->asid = 0; >>> - return 0; >>> + if ( !asid_enabled || asid->asid == 1 ) >>> + return; >>> + >>> + ASSERT( asid->asid < asid_count ); >>> + >>> + spin_lock(&asid_lock); >>> + WARN_ON(!test_bit(asid->asid, asid_bitmap)); >>> + clear_bit(asid->asid, asid_bitmap); >>> + spin_unlock(&asid_lock); >>> } >>> /* >>> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c >>> index 2efb1d4f08..259a2b0caf 100644 >>> --- a/xen/arch/x86/hvm/emulate.c >>> +++ b/xen/arch/x86/hvm/emulate.c >>> @@ -2655,7 +2655,7 @@ static int cf_check hvmemul_tlb_op( >>> case x86emul_invpcid: >>> if ( x86emul_invpcid_type(aux) != X86_INVPCID_INDIV_ADDR ) >>> { >>> - hvm_asid_flush_vcpu(current); >>> + current->arch.needs_tlb_flush = true; >>> break; >>> } >>> aux = x86emul_invpcid_pcid(aux); >>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c >>> index a75ccb57bf..283dcad691 100644 >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -715,6 +715,10 @@ int hvm_domain_initialise(struct domain *d, >>> if ( rc ) >>> goto fail2; >>> + rc = hvm_asid_alloc(&d->arch.hvm.asid); >>> + if ( rc ) >>> + goto fail2; >>> + >> >> Don't you need to free the asid if the subsequent function call(s) fail? >> > > Yes, the hvm_free_asid call is in hvm_domain_destroy(), I guess it would be better to have it in hvm_domain_relinquish_resources() so that it's called by the error handling of hvm_domain_initialise() too. > >>> rc = alternative_call(hvm_funcs.domain_initialise, d); >>> if ( rc != 0 ) >>> goto fail2; >>> @@ -795,7 +799,7 @@ void hvm_domain_destroy(struct domain *d) >>> list_del(&ioport->list); >>> xfree(ioport); >>> } >>> - >>> + hvm_asid_free(&d->arch.hvm.asid); >>> destroy_vpci_mmcfg(d); >>> } >>> @@ -1613,7 +1617,7 @@ int hvm_vcpu_initialise(struct vcpu *v) >>> int rc; >>> struct domain *d = v->domain; >>> - hvm_asid_flush_vcpu(v); >>> + v->arch.needs_tlb_flush = true; >>> spin_lock_init(&v->arch.hvm.tm_lock); >>> INIT_LIST_HEAD(&v->arch.hvm.tm_list); >>> @@ -4085,6 +4089,11 @@ static void hvm_s3_resume(struct domain *d) >>> } >>> } >>> +int hvm_flush_tlb(const unsigned long *vcpu_bitmap) >>> +{ >>> + return current->domain->arch.paging.flush_tlb(vcpu_bitmap); >>> +} >>> + >>> static int hvmop_flush_tlb_all(void) >>> { >>> if ( !is_hvm_domain(current->domain) ) >>> @@ -5461,4 +5470,3 @@ int hvm_copy_context_and_params(struct domain *dst, struct domain *src) >>> * indent-tabs-mode: nil >>> * End: >>> */ >>> - >>> diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c >>> index bddd77d810..61e866b771 100644 >>> --- a/xen/arch/x86/hvm/nestedhvm.c >>> +++ b/xen/arch/x86/hvm/nestedhvm.c >>> @@ -12,6 +12,7 @@ >>> #include >>> #include /* for local_event_delivery_(en|dis)able */ >>> #include /* for paging_mode_hap() */ >>> +#include >>> static unsigned long *shadow_io_bitmap[3]; >>> @@ -36,13 +37,11 @@ nestedhvm_vcpu_reset(struct vcpu *v) >>> hvm_unmap_guest_frame(nv->nv_vvmcx, 1); >>> nv->nv_vvmcx = NULL; >>> nv->nv_vvmcxaddr = INVALID_PADDR; >>> - nv->nv_flushp2m = 0; >>> + nv->nv_flushp2m = true; >>> nv->nv_p2m = NULL; >>> nv->stale_np2m = false; >>> nv->np2m_generation = 0; >>> - hvm_asid_flush_vcpu_asid(&nv->nv_n2asid); >>> - >>> alternative_vcall(hvm_funcs.nhvm_vcpu_reset, v); >>> /* vcpu is in host mode */ >>> @@ -86,7 +85,7 @@ static void cf_check nestedhvm_flushtlb_ipi(void *info) >>> * This is cheaper than flush_tlb_local() and has >>> * the same desired effect. >>> */ >>> - hvm_asid_flush_core(); >>> + WARN_ON(hvm_flush_tlb(NULL)); >> >> IIUC, nestedhvm_vmcx_flushtlb() IPIs multiple pCPUs to run >> nestedhvm_flushtlb_ipi() and each of those calls flushes the TLB of every vCPU >> in whatever domain "current" points to and then triggers a VMEXIT on the >> relevant pCPUs. >> >> (Or current might be a shadow domain or the idle domain and do something >> different...) >> >> Is this what you intended because it doesn't seem right to me? >> > > The nested logic probably don't match what is intended (it's mostly a attempt at making things compile). > > But overall, IIUC, this function is called after we invalidated the nested p2m table. I had in mind rethinking the TLB flushing model towards better spliting SLAT-related flushes and guest so that it doesn't end up awkward. After a nested P2M flush, we IPI the other CPUs using the nested P2M to reload the correct nested P2M and flush the TLB, so I think all this needs to do is set the needs_tlb_flush flag (see the attached patch). > >>> vcpu_nestedhvm(v).nv_p2m = NULL; >>> vcpu_nestedhvm(v).stale_np2m = true; >>> } >>> diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c >>> index 53aa5d0512..44d2138895 100644 >>> --- a/xen/arch/x86/hvm/svm/asid.c >>> +++ b/xen/arch/x86/hvm/svm/asid.c >>> @@ -1,39 +1,46 @@ >>> /* SPDX-License-Identifier: GPL-2.0-only */ >>> /* >>> - * asid.c: handling ASIDs in SVM. >>> + * asid.c: handling ASIDs/VPIDs. >>> * Copyright (c) 2007, Advanced Micro Devices, Inc. >>> */ >>> +#include >>> + >>> #include >>> #include >>> #include >>> +#include >>> #include "svm.h" >>> #include "vmcb.h" >>> -void svm_asid_init(const struct cpuinfo_x86 *c) >>> +void __init svm_asid_init(void) >>> { >>> - unsigned int nasids = 0; >>> + unsigned int cpu, nasids = cpuid_ebx(0x8000000aU); >>> + >>> + if ( !nasids ) >>> + nasids = 1; >>> - /* Check for erratum #170, and leave ASIDs disabled if it's present. */ >>> - if ( !cpu_has_amd_erratum(c, AMD_ERRATUM_170) ) >>> - nasids = cpuid_ebx(0x8000000aU); >>> + for_each_present_cpu(cpu) >>> + { >>> + /* Check for erratum #170, and leave ASIDs disabled if it's present. */ >>> + if ( cpu_has_amd_erratum(&cpu_data[cpu], AMD_ERRATUM_170) ) >>> + { >>> + printk(XENLOG_WARNING "Disabling ASID due to errata 170 on CPU%u\n", cpu); >>> + nasids = 1; >>> + } >>> + } >>> - hvm_asid_init(nasids); >>> + BUG_ON(hvm_asid_init(nasids)); >>> } >>> /* >>> - * Called directly before VMRUN. Checks if the VCPU needs a new ASID, >>> - * assigns it, and if required, issues required TLB flushes. >>> + * Called directly at the first VMRUN/VMENTER of a vcpu to assign the ASID/VPID. >> >> Mentioning VMENTER and VPID is not relevent in this AMD code. >> > > yes > >>> */ >>> -void svm_asid_handle_vmrun(void) >>> +void svm_vcpu_assign_asid(struct vcpu *v) >>> { >>> - struct vcpu *curr = current; >>> - struct vmcb_struct *vmcb = curr->arch.hvm.svm.vmcb; >>> - struct hvm_vcpu_asid *p_asid = >>> - nestedhvm_vcpu_in_guestmode(curr) >>> - ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid; >>> - bool need_flush = hvm_asid_handle_vmenter(p_asid); >>> + struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; >>> + struct hvm_asid *p_asid = &v->domain->arch.hvm.asid; >>> /* ASID 0 indicates that ASIDs are disabled. */ >>> if ( p_asid->asid == 0 ) >>> @@ -44,11 +51,31 @@ void svm_asid_handle_vmrun(void) >>> return; >>> } >>> - if ( vmcb_get_asid(vmcb) != p_asid->asid ) >>> - vmcb_set_asid(vmcb, p_asid->asid); >>> + /* In case ASIDs are disabled, as ASID = 0 is reserved, guest can use 1 instead. */ >>> + vmcb_set_asid(vmcb, asid_enabled ? p_asid->asid : 1); >>> +} >>> + >>> +/* Call to make a TLB flush at the next VMRUN. */ >>> +void svm_vcpu_set_tlb_control(struct vcpu *v) >>> +{ >>> + struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; >>> + >>> + /* >>> + * If the vcpu is already running, the tlb control flag may not be >>> + * processed and will be cleared at the next VMEXIT, which will undo >>> + * what we are trying to do. >>> + */ >>> + WARN_ON(v != current && v->is_running); >>> + >>> + vmcb->tlb_control = >>> + cpu_has_svm_flushbyasid ? TLB_CTRL_FLUSH_ASID : TLB_CTRL_FLUSH_ALL; >>> +} >>> + >>> +void svm_vcpu_clear_tlb_control(struct vcpu *v) >>> +{ >>> + struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; >>> - /* We can't rely on TLB_CTRL_FLUSH_ASID as all ASIDs are stale here. */ >>> - vmcb->tlb_control = need_flush ? TLB_CTRL_FLUSH_ALL : TLB_CTRL_NO_FLUSH; >>> + vmcb->tlb_control = TLB_CTRL_NO_FLUSH; >>> } >>> /* >>> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/ nestedsvm.c >>> index b06124c2c9..c712b98256 100644 >>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >>> @@ -5,6 +5,7 @@ >>> * >>> */ >>> +#include >>> #include >>> #include >>> #include >>> @@ -633,7 +634,6 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, >>> if ( svm->ns_asid != vmcb_get_asid(ns_vmcb)) >>> { >>> nv->nv_flushp2m = 1; >>> - hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); >>> svm->ns_asid = vmcb_get_asid(ns_vmcb); >>> } >> >> Removing this flush seems wrong. If VMCB(1-2) has switched to a new ASID but >> VMCB(0-2) always uses the same ASID (same as VMCB(0-1) IIUC), then we surely >> need to flush the TLB for correctness. >> > > Yes, I think we ideally want some form of vASID; so that can have better heuristics on when to flush. > Perhaps - or we flush on every L1/L2 transition like KVM does. Discussed further below... >>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c >>> index 38c61db1d7..e9026e0ae5 100644 >>> --- a/xen/arch/x86/hvm/svm/svm.c >>> +++ b/xen/arch/x86/hvm/svm/svm.c >>> @@ -27,6 +27,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -137,14 +138,17 @@ static void cf_check svm_update_guest_cr( >>> if ( !nestedhvm_enabled(v->domain) ) >>> { >>> if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) ) >>> - hvm_asid_flush_vcpu(v); >>> + v->arch.needs_tlb_flush = true; >>> } >>> else if ( nestedhvm_vmswitch_in_progress(v) ) >>> ; /* CR3 switches during VMRUN/VMEXIT do not flush the TLB. */ >>> else if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) ) >>> - hvm_asid_flush_vcpu_asid( >>> - nestedhvm_vcpu_in_guestmode(v) >>> - ? &vcpu_nestedhvm(v).nv_n2asid : &v->arch.hvm.n1asid); >>> + { >>> + if (nestedhvm_vcpu_in_guestmode(v)) >>> + vcpu_nestedhvm(v).nv_flushp2m = true; >>> + else >>> + v->arch.needs_tlb_flush = true; >> >> Flushing the nested P2M when running in guest mode isn't correct. L2 changing >> its guest CR3 can't affect the nested page tables. >> >>> + } >>> break; >>> case 4: >>> value = HVM_CR4_HOST_MASK; >>> @@ -952,8 +956,7 @@ static void noreturn cf_check svm_do_resume(void) >>> v->arch.hvm.svm.launch_core = smp_processor_id(); >>> hvm_migrate_timers(v); >>> hvm_migrate_pirqs(v); >>> - /* Migrating to another ASID domain. Request a new ASID. */ >>> - hvm_asid_flush_vcpu(v); >>> + v->arch.needs_tlb_flush = true; >> >> Isn't this flush when moving to a different pCPU already handled by the context >> switch logic in the previous patch? >> > > yes > >>> } >>> if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) ) >>> @@ -980,13 +983,14 @@ void asmlinkage svm_vmenter_helper(void) >>> ASSERT(hvmemul_cache_disabled(curr)); >>> - svm_asid_handle_vmrun(); >>> - >>> TRACE_TIME(TRC_HVM_VMENTRY | >>> (nestedhvm_vcpu_in_guestmode(curr) ? TRC_HVM_NESTEDFLAG : 0)); >>> svm_sync_vmcb(curr, vmcb_needs_vmsave); >>> + if ( test_and_clear_bool(curr->arch.needs_tlb_flush) ) >>> + svm_vcpu_set_tlb_control(curr); >>> + >>> vmcb->rax = regs->rax; >>> vmcb->rip = regs->rip; >>> vmcb->rsp = regs->rsp; >>> @@ -1107,6 +1111,8 @@ static int cf_check svm_vcpu_initialise(struct vcpu *v) >>> return rc; >>> } >>> + svm_vcpu_assign_asid(v); >>> + >>> return 0; >>> } >>> @@ -1532,9 +1538,6 @@ static int _svm_cpu_up(bool bsp) >>> /* check for erratum 383 */ >>> svm_init_erratum_383(c); >>> - /* Initialize core's ASID handling. */ >>> - svm_asid_init(c); >>> - >>> /* Initialize OSVW bits to be used by guests */ >>> svm_host_osvw_init(); >>> @@ -2289,7 +2292,7 @@ static void svm_invlpga_intercept( >>> { >>> svm_invlpga(linear, >>> (asid == 0) >>> - ? v->arch.hvm.n1asid.asid >>> + ? v->domain->arch.hvm.asid.asid >>> : vcpu_nestedhvm(v).nv_n2asid.asid); >> >> If we only ever use the L1 domain's ASID, INVLPGA on any other ASID is surely >> not correct - it could belong to some other L1 VM. The existing code is also >> incorrect - L1 invalidating using an ASID other than the last ASID it used >> would not do the correct thing AFAICT. >> > > I think it's going to be a bit more complicated, at least in the nested NPT case where we also need to reset shadow SLAT. > > With NPT, the TLB maps a GVA into a SPA built from gCR3+nCR3, with this instruction flushing a specific GVA mapping. "In principle", a VMM is allowed to use this to flush a GVA after a (nested) SLAT modification was made. > > In our case, that means that we also need to invalidate the shadow SLAT, to handle cases where the guest expect SLAT changes to reflect in the new TLB entry. > > But we can still use INVLPGA on the host, as the other existing mappings of the ASID aren't suddendly made invalid even if the shadow SLAT doesn't exist anymore (a simpler alternative is to completely flush the TLB, so we don't have out of sync shadow SLAT and ASID). I spoke with Andrew about this previously. INVLPGA takes a guest virtual address, therefore there is no sensible way that the L1 VMM can use this instruction to invalidate mappings in the TLB after modifying the NPT(1-2) and so we don't need to worry about invalidating this. INVLPGA is only to be used with shadow page tables in which case there is no NPT(0-2) to invalidate. As per the APM: "The input address is always interpreted as a guest virtual address, so INVLPGA is typically meaningful only when used with shadow page tables; it does not provide a means to invalidate a nested translation by guest physical address." > >>> } >>> @@ -2311,8 +2314,8 @@ static bool cf_check is_invlpg( >>> static void cf_check svm_invlpg(struct vcpu *v, unsigned long linear) >>> { >>> - /* Safe fallback. Take a new ASID. */ >>> - hvm_asid_flush_vcpu(v); >>> + /* Schedule a tlb flush on the VCPU. */ >>> + v->arch.needs_tlb_flush = true; >>> } >>> static bool cf_check svm_get_pending_event( >>> @@ -2482,6 +2485,8 @@ const struct hvm_function_table * __init start_svm(void) >>> svm_function_table.caps.hap_superpage_2mb = true; >>> svm_function_table.caps.hap_superpage_1gb = cpu_has_page1gb; >>> + svm_asid_init(); >>> + >>> return &svm_function_table; >>> } >>> @@ -2539,6 +2544,8 @@ void asmlinkage svm_vmexit_handler(void) >>> (vlapic_get_reg(vlapic, APIC_TASKPRI) & 0x0F)); >>> } >>> + svm_vcpu_clear_tlb_control(v); >>> + >> >> Is there a reason to split updating tlb_control into a clear and then later a >> potential set? This way there are either 1 or 2 writes to it whereas if you >> unconditionally set it before VMRUN there would only ever be 1 write. >> > > Yes, I was also thinking about merging svm_vcpu_clear_tlb_control() into svm_vcpu_set_tlb_control() by adding a boolean parameter. > >>> exit_reason = vmcb->exitcode; >>> if ( hvm_long_mode_active(v) ) >>> diff --git a/xen/arch/x86/hvm/svm/svm.h b/xen/arch/x86/hvm/svm/svm.h >>> index cfa411ad5a..901354e914 100644 >>> --- a/xen/arch/x86/hvm/svm/svm.h >>> +++ b/xen/arch/x86/hvm/svm/svm.h >>> @@ -12,12 +12,8 @@ >>> #include >>> struct cpu_user_regs; >>> -struct cpuinfo_x86; >>> struct vcpu; >>> -void svm_asid_init(const struct cpuinfo_x86 *c); >>> -void svm_asid_handle_vmrun(void); >>> - >>> unsigned long *svm_msrbit(unsigned long *msr_bitmap, uint32_t msr); >>> void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len); >>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c >>> index 8e52ef4d49..3916ae4468 100644 >>> --- a/xen/arch/x86/hvm/vmx/vmcs.c >>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >>> @@ -20,6 +20,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -778,8 +779,6 @@ static int _vmx_cpu_up(bool bsp) >>> this_cpu(vmxon) = 1; >>> - hvm_asid_init(cpu_has_vmx_vpid ? (1u << VMCS_VPID_WIDTH) : 0); >>> - >>> if ( cpu_has_vmx_ept ) >>> ept_sync_all(); >>> @@ -1903,7 +1902,7 @@ void cf_check vmx_do_resume(void) >>> */ >>> v->arch.hvm.vmx.hostenv_migrated = 1; >>> - hvm_asid_flush_vcpu(v); >>> + v->arch.needs_tlb_flush = true; >>> } >>> debug_state = v->domain->debugger_attached >>> @@ -2116,7 +2115,6 @@ void vmcs_dump_vcpu(struct vcpu *v) >>> (SECONDARY_EXEC_ENABLE_VPID | SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) ) >>> printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n", >>> vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL)); >>> - >>> vmx_vmcs_exit(v); >>> } >>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c >>> index 269ca56433..a531145218 100644 >>> --- a/xen/arch/x86/hvm/vmx/vmx.c >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c >>> @@ -25,6 +25,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -834,6 +835,18 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v) >>> vmx_update_secondary_exec_control(v); >>> } >>> + if ( asid_enabled ) >>> + { >>> + v->arch.hvm.vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_VPID; >>> + vmx_update_secondary_exec_control(v); >>> + } >>> + else >>> + { >>> + v->arch.hvm.vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_VPID; >>> + vmx_update_secondary_exec_control(v); >>> + } >>> + >>> + >>> /* >>> * We can safely pass MSR_SPEC_CTRL through to the guest, even if STIBP >>> * isn't enumerated in hardware, as SPEC_CTRL_STIBP is ignored. >>> @@ -1510,7 +1523,7 @@ static void cf_check vmx_handle_cd(struct vcpu *v, unsigned long value) >>> vmx_set_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW); >>> wbinvd(); /* flush possibly polluted cache */ >>> - hvm_asid_flush_vcpu(v); /* invalidate memory type cached in TLB */ >>> + v->arch.needs_tlb_flush = true; /* invalidate memory type cached in TLB */ >>> v->arch.hvm.vmx.cache_mode = CACHE_MODE_NO_FILL; >>> } >>> else >>> @@ -1519,7 +1532,7 @@ static void cf_check vmx_handle_cd(struct vcpu *v, unsigned long value) >>> vmx_set_guest_pat(v, *pat); >>> if ( !is_iommu_enabled(v->domain) || iommu_snoop ) >>> vmx_clear_msr_intercept(v, MSR_IA32_CR_PAT, VMX_MSR_RW); >>> - hvm_asid_flush_vcpu(v); /* no need to flush cache */ >>> + v->arch.needs_tlb_flush = true; >>> } >>> } >>> } >>> @@ -1871,7 +1884,7 @@ static void cf_check vmx_update_guest_cr( >>> __vmwrite(GUEST_CR3, v->arch.hvm.hw_cr[3]); >>> if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) ) >>> - hvm_asid_flush_vcpu(v); >>> + v->arch.needs_tlb_flush = true; >>> break; >>> default: >>> @@ -3168,6 +3181,8 @@ const struct hvm_function_table * __init start_vmx(void) >>> lbr_tsx_fixup_check(); >>> ler_to_fixup_check(); >>> + BUG_ON(hvm_asid_init(cpu_has_vmx_vpid ? (1u << VMCS_VPID_WIDTH) : 1)); >>> + >>> return &vmx_function_table; >>> } >>> @@ -4931,9 +4946,7 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) >>> { >>> struct vcpu *curr = current; >>> struct domain *currd = curr->domain; >>> - u32 new_asid, old_asid; >>> - struct hvm_vcpu_asid *p_asid; >>> - bool need_flush; >>> + struct hvm_asid *p_asid; >>> ASSERT(hvmemul_cache_disabled(curr)); >>> @@ -4949,33 +4962,9 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) >>> if ( nestedhvm_vcpu_in_guestmode(curr) ) >>> p_asid = &vcpu_nestedhvm(curr).nv_n2asid; >>> else >>> - p_asid = &curr->arch.hvm.n1asid; >>> - >>> - old_asid = p_asid->asid; >>> - need_flush = hvm_asid_handle_vmenter(p_asid); >>> - new_asid = p_asid->asid; >>> - >>> - if ( unlikely(new_asid != old_asid) ) >>> - { >>> - __vmwrite(VIRTUAL_PROCESSOR_ID, new_asid); >>> - if ( !old_asid && new_asid ) >>> - { >>> - /* VPID was disabled: now enabled. */ >>> - curr->arch.hvm.vmx.secondary_exec_control |= >>> - SECONDARY_EXEC_ENABLE_VPID; >>> - vmx_update_secondary_exec_control(curr); >>> - } >>> - else if ( old_asid && !new_asid ) >>> - { >>> - /* VPID was enabled: now disabled. */ >>> - curr->arch.hvm.vmx.secondary_exec_control &= >>> - ~SECONDARY_EXEC_ENABLE_VPID; >>> - vmx_update_secondary_exec_control(curr); >>> - } >>> - } >>> + p_asid = &currd->arch.hvm.asid; >>> - if ( unlikely(need_flush) ) >>> - vpid_sync_all(); >>> + __vmwrite(VIRTUAL_PROCESSOR_ID, p_asid->asid); >>> if ( paging_mode_hap(curr->domain) ) >>> { >>> @@ -4984,12 +4973,18 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) >>> unsigned int inv = 0; /* None => Single => All */ >>> struct ept_data *single = NULL; /* Single eptp, iff inv == 1 */ >>> + if ( test_and_clear_bool(curr->arch.needs_tlb_flush) ) >>> + { >>> + inv = 1; >>> + single = ept; >>> + } >>> + >>> if ( cpumask_test_cpu(cpu, ept->invalidate) ) >>> { >>> cpumask_clear_cpu(cpu, ept->invalidate); >>> /* Automatically invalidate all contexts if nested. */ >>> - inv += 1 + nestedhvm_enabled(currd); >>> + inv = 1 + nestedhvm_enabled(currd); >>> single = ept; >>> } >>> @@ -5018,6 +5013,11 @@ bool asmlinkage vmx_vmenter_helper(const struct cpu_user_regs *regs) >>> __invept(inv == 1 ? INVEPT_SINGLE_CONTEXT : INVEPT_ALL_CONTEXT, >>> inv == 1 ? single->eptp : 0); >>> } >>> + else /* Shadow paging */ >>> + { >>> + if ( test_and_clear_bool(curr->arch.needs_tlb_flush) ) >>> + vpid_sync_vcpu_context(curr); >>> + } >>> out: >>> if ( unlikely(curr->arch.hvm.vmx.lbr_flags & LBR_FIXUP_MASK) ) >>> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c >>> index e4cdfe55c1..5c0e1226c4 100644 >>> --- a/xen/arch/x86/hvm/vmx/vvmx.c >>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c >>> @@ -1253,7 +1253,7 @@ static void virtual_vmentry(struct cpu_user_regs *regs) >>> if ( nvmx->guest_vpid != new_vpid ) >>> { >>> - hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(v).nv_n2asid); >>> + v->arch.needs_tlb_flush = true; >>> nvmx->guest_vpid = new_vpid; >>> } >>> } >>> @@ -2052,7 +2052,7 @@ static int nvmx_handle_invvpid(struct cpu_user_regs *regs) >>> case INVVPID_INDIVIDUAL_ADDR: >>> case INVVPID_SINGLE_CONTEXT: >>> case INVVPID_ALL_CONTEXT: >>> - hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(current).nv_n2asid); >>> + hvm_flush_tlb(NULL); >>> break; >>> default: >>> vmfail(regs, VMX_INSN_INVEPT_INVVPID_INVALID_OP); >>> diff --git a/xen/arch/x86/include/asm/flushtlb.h b/xen/arch/x86/ include/asm/flushtlb.h >>> index 345677eb72..081e5a1188 100644 >>> --- a/xen/arch/x86/include/asm/flushtlb.h >>> +++ b/xen/arch/x86/include/asm/flushtlb.h >>> @@ -125,12 +125,6 @@ void switch_cr3_cr4(struct vcpu *v, unsigned long cr3, unsigned long cr4); >>> #define FLUSH_VCPU_STATE 0x1000 >>> /* Flush the per-cpu root page table */ >>> #define FLUSH_ROOT_PGTBL 0x2000 >>> -#if CONFIG_HVM >>> - /* Flush all HVM guests linear TLB (using ASID/VPID) */ >>> -#define FLUSH_HVM_ASID_CORE 0x4000 >>> -#else >>> -#define FLUSH_HVM_ASID_CORE 0 >>> -#endif >>> #if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING) >>> /* >>> * Adding this to the flags passed to flush_area_mask will prevent using the >>> @@ -190,7 +184,6 @@ void flush_area_mask(const cpumask_t *mask, const void *va, >>> static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) {} >>> -unsigned int guest_flush_tlb_flags(const struct domain *d); >>> void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask); >>> #endif /* __FLUSHTLB_H__ */ >>> diff --git a/xen/arch/x86/include/asm/hvm/asid.h b/xen/arch/x86/ include/asm/hvm/asid.h >>> index 25ba57e768..b6df5cda35 100644 >>> --- a/xen/arch/x86/include/asm/hvm/asid.h >>> +++ b/xen/arch/x86/include/asm/hvm/asid.h >>> @@ -8,25 +8,25 @@ >>> #ifndef __ASM_X86_HVM_ASID_H__ >>> #define __ASM_X86_HVM_ASID_H__ >>> +#include >>> +#include >>> -struct vcpu; >>> -struct hvm_vcpu_asid; >>> +struct hvm_asid { >>> + uint32_t asid; >>> +}; >>> -/* Initialise ASID management for the current physical CPU. */ >>> -void hvm_asid_init(unsigned int nasids); >>> +#ifdef CONFIG_HVM >>> +extern bool asid_enabled; >>> +#else >>> +#define asid_enabled (false) >>> +#endif >>> -/* Invalidate a particular ASID allocation: forces re-allocation. */ >>> -void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid); >>> +/* Initialise ASID management distributed across all CPUs. */ >>> +int hvm_asid_init(unsigned long nasids); >>> -/* Invalidate all ASID allocations for specified VCPU: forces re- allocation. */ >>> -void hvm_asid_flush_vcpu(struct vcpu *v); >>> - >>> -/* Flush all ASIDs on this processor core. */ >>> -void hvm_asid_flush_core(void); >>> - >>> -/* Called before entry to guest context. Checks ASID allocation, returns a >>> - * boolean indicating whether all ASIDs must be flushed. */ >>> -bool hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid); >>> +int hvm_asid_alloc(struct hvm_asid *asid); >>> +int hvm_asid_alloc_range(struct hvm_asid *asid, unsigned long min, unsigned long max); >>> +void hvm_asid_free(struct hvm_asid *asid); >>> #endif /* __ASM_X86_HVM_ASID_H__ */ >>> diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/ include/asm/hvm/domain.h >>> index dd7fa96aad..194343d9bf 100644 >>> --- a/xen/arch/x86/include/asm/hvm/domain.h >>> +++ b/xen/arch/x86/include/asm/hvm/domain.h >>> @@ -140,6 +140,7 @@ struct hvm_domain { >>> } write_map; >>> struct hvm_pi_ops pi_ops; >>> + struct hvm_asid asid; >>> union { >>> struct vmx_domain vmx; >>> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/ include/asm/hvm/hvm.h >>> index e7c1364802..935d9e7548 100644 >>> --- a/xen/arch/x86/include/asm/hvm/hvm.h >>> +++ b/xen/arch/x86/include/asm/hvm/hvm.h >>> @@ -274,6 +274,8 @@ int hvm_domain_initialise(struct domain *d, >>> void hvm_domain_relinquish_resources(struct domain *d); >>> void hvm_domain_destroy(struct domain *d); >>> +int hvm_flush_tlb(const unsigned long *vcpu_bitmap); >>> + >>> int hvm_vcpu_initialise(struct vcpu *v); >>> void hvm_vcpu_destroy(struct vcpu *v); >>> void hvm_vcpu_down(struct vcpu *v); >>> @@ -497,17 +499,6 @@ static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset) >>> alternative_vcall(hvm_funcs.set_tsc_offset, v, offset); >>> } >>> -/* >>> - * Called to ensure than all guest-specific mappings in a tagged TLB are >>> - * flushed; does *not* flush Xen's TLB entries, and on processors without a >>> - * tagged TLB it will be a noop. >>> - */ >>> -static inline void hvm_flush_guest_tlbs(void) >>> -{ >>> - if ( hvm_enabled ) >>> - hvm_asid_flush_core(); >>> -} >>> - >>> static inline unsigned int >>> hvm_get_cpl(struct vcpu *v) >>> { >>> @@ -901,8 +892,6 @@ static inline int hvm_cpu_up(void) >>> static inline void hvm_cpu_down(void) {} >>> -static inline void hvm_flush_guest_tlbs(void) {} >>> - >>> static inline void hvm_invlpg(const struct vcpu *v, unsigned long linear) >>> { >>> ASSERT_UNREACHABLE(); >>> diff --git a/xen/arch/x86/include/asm/hvm/svm.h b/xen/arch/x86/ include/asm/hvm/svm.h >>> index a35a61273b..1877bb149a 100644 >>> --- a/xen/arch/x86/include/asm/hvm/svm.h >>> +++ b/xen/arch/x86/include/asm/hvm/svm.h >>> @@ -9,6 +9,11 @@ >>> #ifndef __ASM_X86_HVM_SVM_H__ >>> #define __ASM_X86_HVM_SVM_H__ >>> +void svm_asid_init(void); >>> +void svm_vcpu_assign_asid(struct vcpu *v); >>> +void svm_vcpu_set_tlb_control(struct vcpu *v); >>> +void svm_vcpu_clear_tlb_control(struct vcpu *v); >>> + >>> /* >>> * PV context switch helpers. Prefetching the VMCB area itself has been shown >>> * to be useful for performance. >>> diff --git a/xen/arch/x86/include/asm/hvm/vcpu.h b/xen/arch/x86/ include/asm/hvm/vcpu.h >>> index 2a14fa0a63..8ad2ab2910 100644 >>> --- a/xen/arch/x86/include/asm/hvm/vcpu.h >>> +++ b/xen/arch/x86/include/asm/hvm/vcpu.h >>> @@ -9,6 +9,7 @@ >>> #define __ASM_X86_HVM_VCPU_H__ >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -16,11 +17,6 @@ >>> #include >>> #include >>> -struct hvm_vcpu_asid { >>> - uint64_t generation; >>> - uint32_t asid; >>> -}; >>> - >>> struct hvm_vcpu_io { >>> /* >>> * HVM emulation: >>> @@ -76,7 +72,7 @@ struct nestedvcpu { >>> bool stale_np2m; /* True when p2m_base in VMCx02 is no longer valid */ >>> uint64_t np2m_generation; >>> - struct hvm_vcpu_asid nv_n2asid; >>> + struct hvm_asid nv_n2asid; >> >> For SVM, after the change to svm_asid_handle_vmrun AFAICT nothing sets this >> other than nestedhvm_vcpu_reset. >> >>> bool nv_vmentry_pending; >>> bool nv_vmexit_pending; >>> @@ -140,8 +136,6 @@ struct hvm_vcpu { >>> /* (MFN) hypervisor page table */ >>> pagetable_t monitor_table; >>> - struct hvm_vcpu_asid n1asid; >>> - >>> u64 msr_tsc_adjust; >>> union { >>> diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/ include/asm/hvm/vmx/vmx.h >>> index 08854c36ca..e0d4389f20 100644 >>> --- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h >>> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h >>> @@ -463,7 +463,7 @@ static inline void vpid_sync_vcpu_context(const struct vcpu *v) >>> if ( unlikely(!cpu_has_vmx_vpid_invvpid_single_context) ) >>> type = INVVPID_ALL_CONTEXT; >>> - __invvpid(type, v->arch.hvm.n1asid.asid, 0); >>> + __invvpid(type, v->domain->arch.hvm.asid.asid, 0); >>> } >>> static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva) >>> @@ -484,7 +484,7 @@ static inline void vpid_sync_vcpu_gva(struct vcpu *v, unsigned long gva) >>> if ( unlikely(!cpu_has_vmx_vpid_invvpid_single_context) ) >>> type = INVVPID_ALL_CONTEXT; >>> - __invvpid(type, v->arch.hvm.n1asid.asid, (u64)gva); >>> + __invvpid(type, v->domain->arch.hvm.asid.asid, (u64)gva); >>> } >>> static inline void vpid_sync_all(void) >>> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c >>> index 5ccb80bda5..156734d3e0 100644 >>> --- a/xen/arch/x86/mm/hap/hap.c >>> +++ b/xen/arch/x86/mm/hap/hap.c >>> @@ -27,6 +27,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> @@ -750,18 +751,16 @@ static bool cf_check flush_tlb(const unsigned long *vcpu_bitmap) >>> if ( !flush_vcpu(v, vcpu_bitmap) ) >>> continue; >>> - hvm_asid_flush_vcpu(v); >>> - >>> cpu = read_atomic(&v->dirty_cpu); >>> if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) && v- >is_running ) >>> __cpumask_set_cpu(cpu, mask); >>> } >>> + guest_flush_tlb_mask(d, mask); >>> + >>> /* >>> * Trigger a vmexit on all pCPUs with dirty vCPU state in order to force an >>> - * ASID/VPID change and hence accomplish a guest TLB flush. Note that vCPUs >>> - * not currently running will already be flushed when scheduled because of >>> - * the ASID tickle done in the loop above. >>> + * ASID/VPID flush and hence accomplish a guest TLB flush. >>> */ >>> on_selected_cpus(mask, NULL, NULL, 0); >>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c >>> index 027b9ae69b..9879b4840b 100644 >>> --- a/xen/arch/x86/mm/p2m.c >>> +++ b/xen/arch/x86/mm/p2m.c >>> @@ -1440,7 +1440,7 @@ p2m_flush(struct vcpu *v, struct p2m_domain *p2m) >>> ASSERT(v->domain == p2m->domain); >>> vcpu_nestedhvm(v).nv_p2m = NULL; >>> p2m_flush_table(p2m); >>> - hvm_asid_flush_vcpu(v); >>> + v->arch.needs_tlb_flush = true; >>> } >>> void >>> @@ -1499,7 +1499,7 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m) >>> static void nvcpu_flush(struct vcpu *v) >>> { >>> - hvm_asid_flush_vcpu(v); >>> + v->arch.needs_tlb_flush = true; >>> vcpu_nestedhvm(v).stale_np2m = true; >>> } >>> @@ -1619,7 +1619,7 @@ void np2m_schedule(int dir) >>> if ( !np2m_valid ) >>> { >>> /* This vCPU's np2m was flushed while it was not runnable */ >>> - hvm_asid_flush_core(); >>> + curr->arch.needs_tlb_flush = true; >>> vcpu_nestedhvm(curr).nv_p2m = NULL; >>> } >>> else >>> diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c >>> index 14ab7defd8..06053d9a06 100644 >>> --- a/xen/arch/x86/mm/paging.c >>> +++ b/xen/arch/x86/mm/paging.c >>> @@ -938,7 +938,7 @@ void paging_update_nestedmode(struct vcpu *v) >>> else >>> /* TODO: shadow-on-shadow */ >>> v->arch.paging.nestedmode = NULL; >>> - hvm_asid_flush_vcpu(v); >>> + v->arch.needs_tlb_flush = true; >> >> This unconditional flush is done on every L2 exit to L0. That shouldn't be >> necessary, but that's not specifically a problem with this patch. >> > > > >>> } >>> int __init paging_set_allocation(struct domain *d, unsigned int pages, >>> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/ multi.c >>> index 1b0477ed2b..107d0829f2 100644 >>> --- a/xen/arch/x86/mm/shadow/multi.c >>> +++ b/xen/arch/x86/mm/shadow/multi.c >>> @@ -81,12 +81,6 @@ const char *const fetch_type_names[] = { >>> static pagetable_t cf_check sh_update_cr3(struct vcpu *v, bool noflush); >>> -/* Helper to perform a local TLB flush. */ >>> -static void sh_flush_local(const struct domain *d) >>> -{ >>> - flush_local(guest_flush_tlb_flags(d)); >>> -} >>> - >>> #if GUEST_PAGING_LEVELS >= 4 && defined(CONFIG_PV32) >>> #define ASSERT_VALID_L2(t) \ >>> ASSERT((t) == SH_type_l2_shadow || (t) == SH_type_l2h_shadow) >>> @@ -2945,7 +2939,8 @@ static bool cf_check sh_invlpg(struct vcpu *v, unsigned long linear) >>> if ( mfn_to_page(sl1mfn)->u.sh.type >>> == SH_type_fl1_shadow ) >>> { >>> - sh_flush_local(v->domain); >>> + flush_tlb_local(); >>> + v->arch.needs_tlb_flush = true; >>> return false; >>> } >>> @@ -3160,7 +3155,8 @@ sh_update_linear_entries(struct vcpu *v) >>> * linear pagetable to read a top-level shadow page table entry. But, >>> * without this change, it would fetch the wrong value due to a stale TLB. >>> */ >>> - sh_flush_local(d); >>> + flush_tlb_local(); >>> + v->arch.needs_tlb_flush = true; >>> } >>> static pagetable_t cf_check sh_update_cr3(struct vcpu *v, bool noflush) >> >> Booting Hyper-V on my AMD test machine with our internal nested virt branch + >> this patch series fails: >> >> (XEN) [ 88.003415] Assertion 'local_irq_is_enabled()' failed at common/smp.c:53 >> (XEN) [ 88.003419] ----[ Xen-4.23.0 x86_64 debug=y Not tainted ]---- >> (XEN) [ 88.003421] CPU: 11 >> (XEN) [ 88.003422] RIP: e008:[] on_selected_cpus+0x9a/0xd4 >> (XEN) [ 88.003428] RFLAGS: 0000000000010046 CONTEXT: hypervisor (d1v0) >> (XEN) [ 88.003431] rax: 0000000000000046 rbx: 0000000000000000 rcx: 0000000000000000 >> (XEN) [ 88.003433] rdx: 0000000000000000 rsi: 0000000000000000 rdi: ffff8310510ddaf0 >> (XEN) [ 88.003435] rbp: ffff8310510d7cd8 rsp: ffff8310510d7cb0 r8: ffff8310510ddaf0 >> (XEN) [ 88.003436] r9: ffff8310510eae70 r10: ffff8310510d8230 r11: ffff8310510d7f08 >> (XEN) [ 88.003438] r12: ffff8310510ddaf0 r13: 000000000000000b r14: ffff83107c52d000 >> (XEN) [ 88.003440] r15: ffff83107c52d000 cr0: 0000000080050033 cr4: 0000000000f506e0 >> (XEN) [ 88.003441] cr3: 000000107c51c000 cr2: 0000000000000000 >> (XEN) [ 88.003443] fsb: 0000000000000000 gsb: fffff87bd9e3b000 gss: 0000000000000000 >> (XEN) [ 88.003445] ds: 0000 es: 0000 fs: 0000 gs: 0020 ss: 0000 cs: e008 >> (XEN) [ 88.003447] Xen code around (on_selected_cpus+0x9a/0xd4): >> (XEN) [ 88.003448] 41 5f 5d e9 60 6a fc ff d6 4c 89 35 f7 9e a0 00 4c 89 3d f8 9e a0 00 >> (XEN) [ 88.003455] Xen stack trace from rsp=ffff8310510d7cb0: >> (XEN) [ 88.003457] ffff82d04031fac2 ffff83100c11d000 ffff82d040c45498 0000000000000001 >> (XEN) [ 88.003459] ffff82d040313e5e ffff8310510d7ce8 ffff82d04031fb33 ffff8310510d7cf8 >> (XEN) [ 88.003462] ffff82d0403098d2 ffff8310510d7d10 ffff82d040313e94 000000000000000b >> (XEN) [ 88.003464] ffff8310510d7d28 ffff82d04023b6b1 ffff82d040c45498 ffff8310510d7d40 >> (XEN) [ 88.003467] ffff82d04037ab68 ffff8310140aefb0 ffff8310510d7d78 ffff82d04023b59f >> (XEN) [ 88.003469] ffff83107c52c2f0 ffff83107c52d538 ffff83107c52d000 0000000000004d01 >> (XEN) [ 88.003472] ffff83107c52d000 ffff8310510d7d90 ffff82d040313fce ffff83107c52c2f0 >> (XEN) [ 88.003474] ffff8310510d7db8 ffff82d040330164 ffff83107c52c2f0 ffff83107c52d538 >> (XEN) [ 88.003477] ffff8310510d7fff ffff8310510d7dd8 ffff82d040330259 ffff83107c52d4e8 >> (XEN) [ 88.003479] ffff83107c52d538 ffff8310510d7e00 ffff82d0403305bc ffff83100c11d000 >> (XEN) [ 88.003482] 0000000000004d01 0000000000004901 ffff8310510d7e38 ffff82d04030b25f >> (XEN) [ 88.003484] 00000000c0000080 0000000000000001 00000000c0000080 0000000000000001 >> (XEN) [ 88.003487] ffff83100c11d000 ffff8310510d7e80 ffff82d04030b580 0000000000000000 >> (XEN) [ 88.003489] 0000000000000000 ffff8310510d7f08 ffff83100c119000 ffff83100c11d000 >> (XEN) [ 88.003492] 0000000000000002 0000000000000000 ffff8310510d7ef8 ffff82d0402e71db >> (XEN) [ 88.003494] ffff82d0402024f2 ffff82d0402024f8 ffff82d0402024f2 ffff82d0402024f8 >> (XEN) [ 88.003497] ffff82d0402024f2 ffff82d0402024f8 ffff82d0402024f2 ffff82d0402024f8 >> (XEN) [ 88.003499] ffff83100c11d000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) [ 88.003502] 0000000000000000 00007cefaef280d7 ffff82d040202542 0000000000000000 >> (XEN) [ 88.003504] fffff87bd9e00000 0000000000000000 0000000000000400 ffffe70000005a40 >> (XEN) [ 88.003507] Xen call trace: >> (XEN) [ 88.003508] [] R on_selected_cpus+0x9a/0xd4 >> (XEN) [ 88.003512] [] S arch/x86/mm/hap/ hap.c#__flush_tlb+0x84/0xd4 >> (XEN) [ 88.003514] [] F arch/x86/mm/hap/ hap.c#flush_tlb+0x21/0x27 >> (XEN) [ 88.003518] [] F hvm_flush_tlb+0x21/0x2a >> (XEN) [ 88.003520] [] F arch/x86/hvm/ nestedhvm.c#nestedhvm_flushtlb_ipi+0x36/0x51 >> (XEN) [ 88.003522] [] F smp_call_function_interrupt+0x63/0xd2 >> (XEN) [ 88.003525] [] F smp_send_call_function_mask+0x3c/0x3f >> (XEN) [ 88.003527] [] F on_selected_cpus+0xb9/0xd4 >> (XEN) [ 88.003529] [] F nestedhvm_vmcx_flushtlb+0x21/0x4b >> (XEN) [ 88.003532] [] F p2m_flush_table_locked+0xb8/0x167 >> (XEN) [ 88.003534] [] F arch/x86/mm/ p2m.c#p2m_flush_table+0x46/0x330 >> (XEN) [ 88.003537] [] F p2m_flush_nestedp2m+0x42/0x4f >> (XEN) [ 88.003540] [] F hvm_set_efer+0x15a/0x167 >> (XEN) [ 88.003543] [] F hvm_msr_write_intercept+0x314/0x3f8 >> (XEN) [ 88.003546] [] F svm_vmexit_handler+0x12e9/0x1925 >> (XEN) [ 88.003549] [] F svm_asm_do_resume+0x162/0x172 >> (XEN) [ 88.003550] >> (XEN) [ 88.511287] >> (XEN) [ 88.513714] **************************************** >> (XEN) [ 88.520429] Panic on CPU 11: >> (XEN) [ 88.524600] Assertion 'local_irq_is_enabled()' failed at common/smp.c:53 >> (XEN) [ 88.533449] **************************************** >> > > I didn't made testing around nested virt, I guess I need to investigate more on this case. > The rough patch below fixes the Nested Virt issues. The overall change makes it similar to how KVM Nested SVM works currently - L1 and L2 share the same ASID and the TLB is flushed on every L1/L2 transition. This is not ideal from a performance perspective. However, AFAICT the performance of KVM Nested SVM is acceptable in spite of this. Perhaps this will do for now, then if we need to do something more complicated like vASIDs later, we can? Ross ----- >-8 ------------------- diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c index 61e866b771a2..ef29521f3695 100644 --- a/xen/arch/x86/hvm/nestedhvm.c +++ b/xen/arch/x86/hvm/nestedhvm.c @@ -37,7 +37,7 @@ nestedhvm_vcpu_reset(struct vcpu *v) hvm_unmap_guest_frame(nv->nv_vvmcx, 1); nv->nv_vvmcx = NULL; nv->nv_vvmcxaddr = INVALID_PADDR; - nv->nv_flushp2m = true; + nv->nv_flushp2m = 0; nv->nv_p2m = NULL; nv->stale_np2m = false; nv->np2m_generation = 0; @@ -85,7 +85,7 @@ static void cf_check nestedhvm_flushtlb_ipi(void *info) * This is cheaper than flush_tlb_local() and has * the same desired effect. */ - WARN_ON(hvm_flush_tlb(NULL)); + v->arch.needs_tlb_flush = true; vcpu_nestedhvm(v).nv_p2m = NULL; vcpu_nestedhvm(v).stale_np2m = true; } diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index f42a249b1341..e6100db76eba 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -199,6 +199,9 @@ static int nsvm_vcpu_hostrestore(struct vcpu *v, struct cpu_user_regs *regs) ASSERT(n1vmcb != NULL); ASSERT(n2vmcb != NULL); + /* Unconditional flush during L2->L1 */ + v->arch.needs_tlb_flush = true; + /* * nsvm_vmcb_prepare4vmexit() already saved register values * handled by VMSAVE/VMLOAD into n1vmcb directly. @@ -437,7 +440,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) if ( rc ) return rc; - /* ASID - Emulation handled in hvm_asid_handle_vmenter() */ + n2vmcb->_asid = n1vmcb->_asid; /* TLB control */ n2vmcb->tlb_control = ns_vmcb->tlb_control; @@ -655,6 +658,9 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, svm->ns_vmcb_guestcr3 = ns_vmcb->_cr3; svm->ns_vmcb_hostcr3 = ns_vmcb->_h_cr3; + /* Unconditional flush during L1->L2 */ + v->arch.needs_tlb_flush = true; + /* Convert explicitely to boolean. Deals with l1 guests * that use flush-by-asid w/o checking the cpuid bits */ nv->nv_flushp2m = !!ns_vmcb->tlb_control; diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 3b24aea5ab22..2519a332901c 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -144,10 +144,7 @@ static void cf_check svm_update_guest_cr( ; /* CR3 switches during VMRUN/VMEXIT do not flush the TLB. */ else if ( !(flags & HVM_UPDATE_GUEST_CR3_NOFLUSH) ) { - if (nestedhvm_vcpu_in_guestmode(v)) - vcpu_nestedhvm(v).nv_flushp2m = true; - else - v->arch.needs_tlb_flush = true; + v->arch.needs_tlb_flush = true; } break; case 4: @@ -2294,10 +2291,7 @@ static void svm_vmexit_do_invalidate_cache(struct cpu_user_regs *regs, static void svm_invlpga_intercept( struct vcpu *v, unsigned long linear, uint32_t asid) { - svm_invlpga(linear, - (asid == 0) - ? v->domain->arch.hvm.asid.asid - : vcpu_nestedhvm(v).nv_n2asid.asid); + svm_invlpga(linear, v->domain->arch.hvm.asid.asid); } static void svm_invlpg_intercept(unsigned long linear) diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c index 4fb15ebfd3a3..b3f5caa68424 100644 --- a/xen/arch/x86/mm/paging.c +++ b/xen/arch/x86/mm/paging.c @@ -927,6 +927,7 @@ void paging_dump_vcpu_info(struct vcpu *v) #ifdef CONFIG_HVM void paging_update_nestedmode(struct vcpu *v) { + const struct paging_mode *orig = v->arch.paging.nestedmode; ASSERT(nestedhvm_enabled(v->domain)); if (nestedhvm_paging_mode_hap(v)) /* nested-on-nested */ @@ -934,7 +935,9 @@ void paging_update_nestedmode(struct vcpu *v) else /* TODO: shadow-on-shadow */ v->arch.paging.nestedmode = NULL; - v->arch.needs_tlb_flush = true; + + if ( orig != v->arch.paging.nestedmode ) + v->arch.needs_tlb_flush = true; } int __init paging_set_allocation(struct domain *d, unsigned int pages, From xen-devel-bounces@lists.xenproject.org Mon Sep 21 13:45:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 13:45:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427559.1650353 (Exim 4.92) (envelope-from ) id 1x8eKy-0007jq-3q; Mon, 21 Sep 2026 13:45:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427559.1650353; Mon, 21 Sep 2026 13:45:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eKy-0007jj-0V; Mon, 21 Sep 2026 13:45:40 +0000 Received: by outflank-mailman (input) for mailman id 1427559; Mon, 21 Sep 2026 13:45:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eKw-0007jN-Aj for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:45:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8eKv-004iH1-BD for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:45:37 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab134ea-8faa-0a2a0a5109dd-0a2a450489da-40 for ; Mon, 21 Sep 2026 15:45:36 +0200 Received: from [40.93.201.3] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab134ff-b57f-0a2a45040019-285dc9032496-3 for ; Mon, 21 Sep 2026 15:45:36 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by CH3PR12MB583062.namprd12.prod.outlook.com (2603:10b6:610:363::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 13:45:33 +0000 Received: from BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740]) by BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740%3]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 13:45:33 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gIfxxN1rbzRyReJZf96pA2tayyreT90A/0bkfZMYh+UtpK1Br5UGV0fC1pGU/Ach6c6mZ1knbu9sJeO11wdaiJ4spC/xqaS8pB4QPgxYrDdL+n6Uze6MemDBhSfO9G+T8b8qjFvMCdoKu0mx5w8vZOOsznlZ+gkP1qMFDnOcqh5FMgJT8C/01MjHWpsXPCgO1GLHSKWFngRHvwf09/0cEUZvNxJBhOuSPxwJ0ggqiQ117Mql/Ad3oWHr6pDx5zZiIKPjpumqQZ27SJQ+E8BVCgqejmrsb5uUUsCoAiiaJWLCCVdwnBjOd5GRWqaSziLn6163p5UIvAYx+E+Ofi1LWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GRdMISli17M+yC8zih0JwBATihEq8UyVr/fg5WG9xB0=; b=uY9ToNmb5OIsRmCkQVnpNucbaIWzy+uduRajlXn52MZnVPE/xvw8meIOjnPGMruTOxiKulk7n9OFCdo6Q9rSM3YorOz2c0ejxNbD9P8PK6zWcdpvA1WzTHfojbA/xD9Urmk03mDbohbrneiUgNhK3rNy2mVfnL1yIhCnbDvl/dY0Cii8DwKB8TUPUtvIAQk/Wk2x6/LbLHPudECT3LAvblKtFp2WZd42iMkoZMkscIDSZUqJhpU/CSC3raOXoyk1tXceUXTPvX0B8nTgkkfkddioXYvAHvrrYDkdFf5DwN+xbAzzCv7k6PtMUwhiR3YQO8qLoVEpHnyOiTDT73mH5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GRdMISli17M+yC8zih0JwBATihEq8UyVr/fg5WG9xB0=; b=gTaTVgiwy/bCxRWih7wI5ENkLBKoILYCGzuFwNzmxLRGMzU8OHSgTisG8+wQ8BNND2Dd5NMOVQtPCxUNy1RXne/VstJp72SiZPPiczudciW7+jM9bZ+DrP0lJEzc1qPaYP4nhSlY+CbS8/KaJQhxCIQYydHfvBs3UNSddvXnbGg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 21 Sep 2026 15:45:29 +0200 Message-Id: Cc: "Andrew Cooper" , "Teddy Astie" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/HVM: replace paging_mode_hap() uses From: "Alejandro Vallejo" To: "Jan Beulich" , "xen-devel@lists.xenproject.org" X-Mailer: aerc 0.17.0 References: In-Reply-To: X-ClientProxiedBy: MA3P292CA0038.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:46::7) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|CH3PR12MB583062:EE_ X-MS-Office365-Filtering-Correlation-Id: 62e264c7-b7fc-49d0-194b-08df17e69bb1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|10067099003|11063799006|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: vKvTpRZNS2syJJKo5/v5Nqu2dmlnsJPuI2ZJI+SdHBBsBGBsVfat9udDcDsF4sOu2APwfaRPciTNH5m73sOUfhTUyADEfHc3RS1FNUEIpp3tPHw3wIndhPAYcJ39e5EgpakZdzV0HiGvb2ZfjSqJXXCkM7jOUlKbEf2qRH35m0f5IbDycjEOYApLUJGrOB97Ktv2o202Jd+H/hP7O77aZI7ugNbO3aAzcHewkWjsX92VhbR/ONejrLCyFLD6+0NrW/WcL569zn2FYC9GmeeGkl/FDhSRT6JFcBm4DnpQ/Z2t6OW2zjUdY+1+lsWdzqomI5qEbN4YHjumfcDzVgfDhVmXpEBdPBkgyExvvVf8U5bUWp6PQKs2RfinvxtmBQp6tA7mgwZfUZ8yMWTr1Z9cakcBR5yjuMeskUUnZVW4zSDdq7KP7ok0oX3R/1c6tuS7Vub+YVhpNriswr4/K1tQwTXd9vJIjQGOYrFo8thdfxG25l13vJ0lhR/JOMeOeglGnQG+DDW1BeT4+vsXR7/3AMBq3XlWnGXjx8ounJ7+obEcygGDfReW5uHJFTXpX+PkNkCmCeukB7rjz6j1s8upO+bsrMRGMcvsIQmYwZDOout3fV58n4l/bHC64hY6pJuIva1ck0LJCXqDpckTfm7WOemZPX75wnV9XlO8RQ+AQSg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB4999.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M0t6RExMdWNndDlaTWJVS3VYdGp0UTRyZzZzck03eXl1UmlLcGtJMU0xUk1L?= =?utf-8?B?TFNuRjMrU0RIR2h4cWNkMnBlanV3Y3NOamVrL1NBWWtucHNFejlaUkJJM2xq?= =?utf-8?B?NWQrNEFhZnUvbGFLejRON1Zac0FDd0tiZFdHdGxYOGRJMm05ZklHR0hzVm12?= =?utf-8?B?RGE3VFZVV3pXdVRiK2M2SWVQdlJJc0JQVzA5UHUxSHhwcm1HUEdHMnU2ckE1?= =?utf-8?B?cTJVYUplSUlMTmYvZTFJYS85bTVSb1MvME9lcEFPdmtUNzdkbDhINHdCdzh3?= =?utf-8?B?SGFkL3BUVStQWXVYZ1lrOW0rUDM1TkFJOEhpUXN5eHhUM1kyTkkvRjVUR1NF?= =?utf-8?B?UXpHQjdWWXFuUXRSMTBPajNuVE1VZnNnV0RROEZwdG1LSlN3alNIMUlCR1Nz?= =?utf-8?B?cDRCMi9Sa3VGaXBMZzRGWEY1ck12ZEtXMUZhRjE3Tk9yNkxxazRac3E0bk5q?= =?utf-8?B?Tm85cURHd05pOUdzLzZRV2JCSGtTQlptb1M3aUdoOEtlN1gzR2JuZUJ6QkMr?= =?utf-8?B?YUp3eWNXWjN1MnVGcVRXYTBsMWVHTUxEbCtaM08rYTQzaGFURVRtOGpxanJI?= =?utf-8?B?eUpMUFJFWjJleGxPeTlxQUhYZVFlL3RNOVFIUGNqOXpMcitsVUdxNTdCWmha?= =?utf-8?B?bE11OThoR1F2SG9zeHg4dGZSWFRwa0RzazF4VStTZTVrcHAwR1cvM3NkSnY2?= =?utf-8?B?bENoZnJidGNvRWdIS1kxVnkwKzR6RXZmUnV0UHZrOHEyeGZNMEhUODBSK1ho?= =?utf-8?B?WTFZU3JJZm9UUXgweHZSVFhYU055VkV2SjQxMklGRVpzSlRGTDhLNlQ4SWpQ?= =?utf-8?B?aGIyZzVDUHNadFgxS1RaZEtWV29RRFdrUFNmTjErV1J1bWF0SWZvRllBYmVk?= =?utf-8?B?UjQwdENtSXFza0oxd1MzNVZFYVNXcEhFSEZBS0Ric3RoRW5lSlVZZk80aWtH?= =?utf-8?B?SVEzRTVZdkxiem40UDVGMTFQalVmWG5hcE45bk92Z3VOOTFZTkdweERTMnIw?= =?utf-8?B?Tk9LTWxTaGd1S2F3eFpUNUg1ZWowbU9HNzAybWNwenpaNEp3RVYwSkZrZmxY?= =?utf-8?B?a0NyVVlwM1NNN1VUYzlqRmszaElzenhieGRIWlFrbkFOUXAzWUlBdFVqdGRF?= =?utf-8?B?UUlHNVptK1Zod1FLSjFYY0Z0cWxBc1VRcTVRZ0Z3alVLeHg2VjQ5ZndjNDJB?= =?utf-8?B?ZmMwM2ZETkZoMFlOWDM5ckxIQXp1NEtNQ1FHdk5mOE5DZU1uQUhIOCtKSU10?= =?utf-8?B?Q2U2aGUzSGQxOWk4cnl1T1FxQ1FGdW9vVE1uSXFQdmllOGV2b3hqMDdBOVRG?= =?utf-8?B?OUp5YjBVaHBrME5Qcmowb2xoSTBtOWRJdkJSQ3lsZThZSmk1dDZKSEttSDc0?= =?utf-8?B?K3lEWTdEL0lVcXNBdFplL3JKRE5jMVBmZUN6S0oxTDRHK1ZQQmYwUXhzNDhu?= =?utf-8?B?eVlKTUVLdUs3YVpGUkFnQmxrK2ZVOWdHaTdQdHdjYXVCcCthd2JWb0JsUzN1?= =?utf-8?B?c0pxUzBUZi9GYThKbmU5QWgrK1hDRnZXN2I4ZmZ1S3FEWEpJL0J2V0dReHRJ?= =?utf-8?B?RGtvdGkwSmhQQUM2ZGxyVEFYOURiWW5DbzVsOE9DUmJyak92d3NCTi9hbWNy?= =?utf-8?B?Nzd6eHd0Mm15T3huRFlFVkFCT2txMU5ZUG84ajVuNnh3ZWsxMDUvemtNcm1K?= =?utf-8?B?WVp2NVR2K2phOE5CZ1dMZUx0cnllMXpVNXJWb2hwMDF4RXZkOUE3S0lWWW1X?= =?utf-8?B?aDdMaEtHQm83SlFvYUNsVjVUYXlzaTVmZGE5dlVsVFFXcDE3THJ1ME9MSk45?= =?utf-8?B?czVIT2R5aDYvQU5Gd3hCaXlLWjdkM1V3a1hvMzlSbEk4SVlBNytsNlltTGhP?= =?utf-8?B?WXhDbFI0Z2ZFeGJWREQyNitycFo3aXRURFg5bHBIQjRUWXJ3ZkhZdzhqeDVW?= =?utf-8?B?azJoQWdCR0dkRk0vMFp2ZUJJT1ZzNGFKUmwvSG15VlJiQmE4ZStDQ1hIaWZ0?= =?utf-8?B?VTkyNHBCc09xVm9WSDV3QjJqb05YS2daNGtiWU5MTnlFY2N6Y0plZW05c1Rn?= =?utf-8?B?NnBaR1phV0pIRUVSTlR2MFdXeU1LMW9FWmluOWZ2eUdsOHNyNXcrS3dmSE5r?= =?utf-8?B?Q1k1QUxnY0xWTURpUWxxa2pBTUYxTFJMQVIvWU1pSDYvc3E3RWFLWFBXUVN4?= =?utf-8?B?cHZyR0ZvRSs2VUVxYmx0WTd6a3ArSlhyWEhySlE2aEpERzV6K3JuWjl3aFNQ?= =?utf-8?B?MUVjS2NOeklmTUNUN2pDMExtV3dtVC9OUmFlTGI2bU1jNjdCYS9XZ1pCQkph?= =?utf-8?Q?1JSbfdTWuHssF35W5V?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62e264c7-b7fc-49d0-194b-08df17e69bb1 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 13:45:33.3196 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: a4d20aF3pV/APrzLLMjBhcb/vUj2it/PjGRw6pj1yLOzTAwNCTY2exyqaZpWFXcQjApGIJydFBIk8JyXNbj1lg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB583062 X-purgate-ID: tlsNG-ebf023/1789998336-585C7B50-83884C6F/0/0 X-purgate-type: clean X-purgate-size: 2101 On Mon Sep 21, 2026 at 3:19 PM CEST, Jan Beulich wrote: > HVM guests cannot run without either HAP or shadow enabled. While > paging_mode_shadow() is compile-time-constant when SHADOW_PAGING=3Dn, > paging_mode_hap() isn't. Hence the former is preferred to leverage DCE. > > In svm_update_guest_cr() combine two adjacent conditionals. > > Signed-off-by: Jan Beulich Yes, please. Reviewed-by: Alejandro Vallejo A couple of nits below. Take them or leave them. > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -113,7 +113,8 @@ static void cf_check svm_update_guest_cr > switch ( cr ) > { > case 0: > - if ( paging_mode_hap(v->domain) ) > + value =3D v->arch.hvm.guest_cr[0]; > + if ( !paging_mode_shadow(v->domain) ) > { > uint32_t intercepts =3D vmcb_get_cr_intercepts(vmcb); > =20 > @@ -122,9 +123,7 @@ static void cf_check svm_update_guest_cr > monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) ) > vmcb_set_cr_intercepts(vmcb, intercepts | CR_INTERCEPT_CR= 3_WRITE); > } > - > - value =3D v->arch.hvm.guest_cr[0]; > - if ( paging_mode_shadow(v->domain) ) > + else > value |=3D X86_CR0_PG | X86_CR0_WP; nit: This would be clearer with the polarity reversed. Check shadow first and have hap later. It'd also make the diff (marginally) smaller too. > vmcb_set_cr0(vmcb, value); > break; > --- a/xen/arch/x86/hvm/vmx/vmcs.c > +++ b/xen/arch/x86/hvm/vmx/vmcs.c [snip] > v->arch.hvm.vmx.exception_bitmap =3D HVM_TRAP_MASK > - | (paging_mode_hap(d) ? 0 : (1U << X86_EXC_PF)); > + | (!paging_mode_shadow(d) ? 0 : (1U << X86_EXC_PF)); nit: Shouldn't | be on the prior line? It was there before, but seeing how you're adjusting indentation might as well move that char. In the same vein as before, it'd be a bit clearer with the polarity inverted (shadow() ? bit : 0 ) Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Sep 21 13:58:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 13:58:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427567.1650362 (Exim 4.92) (envelope-from ) id 1x8eWz-00019q-4A; Mon, 21 Sep 2026 13:58:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427567.1650362; Mon, 21 Sep 2026 13:58:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eWz-00019j-1M; Mon, 21 Sep 2026 13:58:05 +0000 Received: by outflank-mailman (input) for mailman id 1427567; Mon, 21 Sep 2026 13:58:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eWx-00019d-LA for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 13:58:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8eWw-00DOQd-EF for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:58:02 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab137d6-8faa-0a2a0a5109dd-0a2a4509b368-16 for ; Mon, 21 Sep 2026 15:58:01 +0200 Received: from [192.198.163.16] (helo=mgamail.intel.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab137e7-be1a-0a2a45090019-c0c6a310e870-3 for ; Mon, 21 Sep 2026 15:58:00 +0200 Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2026 06:57:58 -0700 Received: from ettammin-mobl3.ger.corp.intel.com (HELO [10.245.244.155]) ([10.245.244.155]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2026 06:57:56 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=Intel header.d=intel.com header.i="@intel.com" header.h="Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Transfer-Encoding:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789999081; x=1821535081; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=X4CIZgjHO+2VErvGmXm3RXicCWQqYRcidFvptKdOGZQ=; b=aesnMmFAuFgbYDzXYkR8IDHrqSxbdn906+O4w8zWuKOMu3iJ7qFW0UZ9 DwEMfwWpPDA2PyRHgi74UiGt6tBNI90DaC8Yz505BsqfknB4NK7rSPvth mY/Juf7axkKGSSWTJymPRMrFIKximsnCKNhhGSCC7Z09O2LUZmhJu4FfY NYUrGQkNDkRniDWUFS4VoMfqutjnzI8v7vZLX421MqIVpMs1jDztxwizB eDqU1nJwgU4Y8DbqBbWGznIZk9Js2awt2b2O1xvimBPwHetzXZBlQfqjH f4TK5kay39KgmB2jn3FQH3tcQjdYA0/epAleDtAWvhlV4ZIXO4Sr5hVUC w==; X-CSE-ConnectionGUID: P0ipv8CFSSWfaBP8Dt7luw== X-CSE-MsgGUID: 6Yx4XgC5ThibSK2ntFzcCg== X-IronPort-AV: E=McAfee;i="6800,10657,11912"; a="78071828" X-IronPort-AV: E=Sophos;i="6.27,114,1787036400"; d="scan'208";a="78071828" X-CSE-ConnectionGUID: nqRK0NXaTM2/w38HemOK1A== X-CSE-MsgGUID: qeLthCnqTnyTD5B7vyXXzw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,114,1787036400"; d="scan'208";a="272824849" Message-ID: <49da6f28a4ba582d32ac6cdccd6dea65d75eefbf.camel@linux.intel.com> Subject: Re: [PATCH v2] drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Szymon =?UTF-8?Q?Aceda=C5=84ski?= , intel-xe@lists.freedesktop.org Cc: matthew.brost@intel.com, rodrigo.vivi@intel.com, maarten.lankhorst@linux.intel.com, hch@lst.de, bob.beckett@collabora.com, dri-devel@lists.freedesktop.org, marmarek@invisiblethingslab.com, xen-devel@lists.xenproject.org, stable@vger.kernel.org Date: Mon, 21 Sep 2026 15:57:49 +0200 In-Reply-To: <20260916173030.3223833-1-accek@invisiblethingslab.com> References: <20260916173030.3223833-1-accek@invisiblethingslab.com> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) MIME-Version: 1.0 X-purgate-ID: tlsNG-bad1c0/1789999081-3A0C5034-C2A1810F/0/0 X-purgate-type: clean X-purgate-size: 3011 On Wed, 2026-09-16 at 19:30 +0200, Szymon Aceda=C5=84ski wrote: > Fix display corruption on Xen PV dom0, where DMA buffers are not > guaranteed machine-contiguous, in which case bounce buffering kicks > in, breaking xe's memory coherency assumptions. >=20 > Apply the same workaround i915 carries in i915_sg_segment_size() > since > commit 78a07fe777c4 ("drm/i915: stop abusing swiotlb_max_segment"). >=20 > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel > GPUs") > Reported-by: Marek Marczykowski-G=C3=B3recki > > Closes: > https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8382 > Link: https://lore.kernel.org/xen-devel/aYtznP_tT6xNPwf-@mail-itl/ > Link: > https://lore.kernel.org/all/20221020110308.1582518-1-hch@lst.de/=C2=A0# > i915 counterpart > Cc: Christoph Hellwig > Cc: Robert Beckett > Cc: stable@vger.kernel.org=C2=A0# v6.8+ > Signed-off-by: Szymon Aceda=C5=84ski > --- > v2: > =C2=A0- Imperative language in the commit message (Thomas Hellstr=C3=B6m) > =C2=A0- CC the authors of the original i915 workaround (Thomas Hellstr=C3= =B6m) Reviewed-by: Thomas Hellstr=C3=B6m >=20 > =C2=A0drivers/gpu/drm/xe/xe_bo.h | 19 +++++++++++++++++++ > =C2=A01 file changed, 19 insertions(+) >=20 > diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h > index 290ca62..341fa93 100644 > --- a/drivers/gpu/drm/xe/xe_bo.h > +++ b/drivers/gpu/drm/xe/xe_bo.h > @@ -9,6 +9,8 @@ > =C2=A0#include > =C2=A0#include > =C2=A0 > +#include > + > =C2=A0#include "xe_bo_types.h" > =C2=A0#include "xe_ggtt.h" > =C2=A0#include "xe_macros.h" > @@ -574,6 +576,23 @@ static inline unsigned int > xe_sg_segment_size(struct device *dev) > =C2=A0 struct scatterlist __maybe_unused sg; > =C2=A0 size_t max =3D BIT_ULL(sizeof(sg.length) * 8) - 1; > =C2=A0 > + /* > + * For Xen PV guests pages aren't contiguous in DMA > (machine) address > + * space.=C2=A0 The DMA API takes care of that both in > dma_alloc_* (by > + * calling into the hypervisor to make the pages contiguous) > and in > + * dma_map_* (by bounce buffering).=C2=A0 But xe (like i915, see > commit > + * 78a07fe777c4) ignores the coherency aspects of the DMA > API and thus > + * can't cope with bounce buffering actually happening, so > add a hack > + * here to force small allocations and mappings when running > in PV > + * mode on Xen. > + * > + * Note this will still break if bounce buffering is > required for other > + * reasons, like confidential computing hypervisors or PCIe > root ports > + * with addressing limitations. > + */ > + if (xen_pv_domain()) > + return PAGE_SIZE; > + > =C2=A0 max =3D min_t(size_t, max, dma_max_mapping_size(dev)); > =C2=A0 > =C2=A0 /* >=20 > base-commit: baafc300cd079a5210c1e70e5ea3d93518e40b38 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:01:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:01:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427576.1650370 (Exim 4.92) (envelope-from ) id 1x8eaB-0002km-IO; Mon, 21 Sep 2026 14:01:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427576.1650370; Mon, 21 Sep 2026 14:01:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eaB-0002kf-Fk; Mon, 21 Sep 2026 14:01:23 +0000 Received: by outflank-mailman (input) for mailman id 1427576; Mon, 21 Sep 2026 14:01:22 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8eaA-0002kZ-2Q for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:01:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8ea9-00Cj9K-FS for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:01:21 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab138b1-2eae-0a2a0a5409dd-0a2a450bd130-2 for ; Mon, 21 Sep 2026 16:01:21 +0200 Received: from [74.125.228.76] (helo=mail-ed2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab138b1-b7e8-0a2a450b0019-4a7de44cee43-3 for ; Mon, 21 Sep 2026 16:01:21 +0200 Received: by mail-ed2-f12.google.com with SMTP id 4fb4d7f45d1cf-6a98604f6b4so4303357a12.2 for ; Mon, 21 Sep 2026 07:01:21 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6aa67c6f08fsm4303325a12.4.2026.09.21.07.01.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 07:01:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789999281; x=1790604081; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=j9ecClcqKW23CSOksqZ/k7uqVZyp4FeUorxA6jT1FlQ=; b=nLktRQF3hJTfxB549t1PtxpTUWWlPlxVOxo9zoZ2t22P6x4M4FTC+8UoF+fozOxJL8 F/AsSN6n6HC5AdWEQ8xK4Fc8YMlNzqvWy2qoWSD1F6kaHt4PPyI1o0Hgt8f7MlCcMDSX QcdSRSsH5xKBcPSZp0ee1gj0nRbLauuSaxpCuBZbIbFepb5JDuO+Zpywji+nJ/Fk6OqT /Cr/El6imN2YNx++NGh3UdtEk8niiHKFaunY/zTcFBobJ67ixq+wajqyrpLi1L2g67RI QM61z+XyJSj1u3rQsys+vWoNPS8QDp09uGuqGi2CAWy9mFiFhwq1RElvJSZWOkCfpKgO xy9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789999281; x=1790604081; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=j9ecClcqKW23CSOksqZ/k7uqVZyp4FeUorxA6jT1FlQ=; b=i1MGVW06RGYpsOxpmVFPE4UDym9sGzPcTGtSk9UW74eVfWBCek0bGRresXzvr3DZ2d ezAEppMp1B0DtrFiN6gKDE5u1dpItzPcnK8z8mNtRNxKfyIIU+nvS+oiq3YtFqaHoM+O 8zHdmeTjVqjUnMtqR0Pouv8TgJ9bGkp/MgJ5rLZQhi41Bm/luB3og3dNh2JwZdhFiBWN oXA8SMd9yBJWwUW/7h2ZwyeK4SDjbPx7eXiWMDTCOyGgYKTWYZEIZbvn0/FSMUl1v7Zh qc29fPMpdhMaCSjcJwthgA92TnHMrl5b3gN2pPtqKOCjGskQ4C4EXp0GqWiiEqBmv25a 0zYQ== X-Forwarded-Encrypted: i=1; AKwUvBzbuJejHAmreIL9j0qGDWGfbJj7O8P8gUKeKvYinkb5fLMYhpaYLFEPTolLj2irpLMQzee2k5D7XPc=@lists.xenproject.org X-Gm-Message-State: AFuF++nDTkS6u7/lWNc7rXLlhtdAZUcskxrKIGmRMys8bNvfFlrTuu2X xM4E8TtEUW7q/CKDN6/57TSgoxSsfNZYEWY9Rh8T12WZyMXAaPYxADWf X-Gm-Gg: AYBFou0y40EZ/aitwqNM4kRFQaonQxKLMJbDTE9AVYN8AYWL0w209rskwiRfUAnfSA/ hQd2oby21NFj/c38y0sN2A556KuJEjxLkzUx4UucZaQGh5xr1GNIlIiHVevSVzrsgDKhzMMPYGf 7G7O8btVDWBpiD9TEpyEbrANGkGFAc3TN1af93qv1jwDBmTnVifaJxbxbFu/7hNXRXGMTP23EKH /D5EoIMLoJe9kH4NG2rjXRYNlPLJr1VaF+n+GuZQmb/lO6bMpbMDzOc4f6Bwzdhx1ghEF9dWoDL G338WFrAQdUtWuSn+RISlbTvNdGnosyXpeNSZk1xPbZM/3g2gNOQBu6mgthHp/gNa48isUkQZrt 1LIsDd5IeMKwucDthrgfViAs+NiHUlq4y0OohZ3P7XeeaB9Zl9sK/e0e8/YsKXgUwyNAanuLSnu tzY5lzjRN5R8BH8kndYWDHbb2nmsHMdFzId6rM09UsPVTQGBL0ANOke+pdvsE2F2uXzB6+yZILy 4BNZAAfWu/qDVphvB6K8BsyIbh0AkjxH/5qNfLdRnVKHNjMuTZzGttldi5k X-Received: by 2002:a05:6402:1e92:b0:6aa:985c:7bae with SMTP id 4fb4d7f45d1cf-6aa985c7caemr558322a12.20.1789999280506; Mon, 21 Sep 2026 07:01:20 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 16:01:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9260a8cb-66f0-4eba-b630-666039bf2e72@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <9260a8cb-66f0-4eba-b630-666039bf2e72@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1789999281-19AC09EA-8BA7ADC9/10/73395122804 X-purgate-type: spam X-purgate-size: 8235 On 9/18/26 2:52 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> @@ -62,23 +69,25 @@ static int cf_check cpu_callback(struct notifier_block *nfb, >> unsigned long action, void *hcpu) >> { >> unsigned int cpu = (unsigned long)hcpu; >> - int rc = 0; >> >> switch ( action ) >> { >> case CPU_STARTING: >> - rc = vgein_init(); >> + { >> + int rc = vgein_init(); >> + >> if ( rc ) >> printk(XENLOG_ERR "AIA: failed to init vgein for CPU%u: %d\n", >> cpu, rc); >> break; >> + } >> >> case CPU_DYING: >> vgein_deinit(); >> break; >> } >> >> - return notifier_from_errno(rc); >> + return NOTIFY_DONE; >> } > > What is this hunk doing in this patch? Was this meant to be merged into the > prior one? Yes, it was meant to be a part of prev. patch. > But then - why? I had a case with what rc returns but looking at my downstream branches I don't face this case anymore so this hunk should be just dropped. > >> @@ -168,3 +181,36 @@ void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) >> __func__, v, vgein_id, cpu, vgein->bmp); >> #endif >> } >> + >> +void hgei_interrupt(void) >> +{ >> + unsigned long hgei_mask, flags; >> + struct vgein_ctrl *vgein = &this_cpu(vgein); >> + >> + hgei_mask = csr_read(CSR_HGEIP) & csr_read(CSR_HGEIE); > > Misra, aiui, isn't going to like this. You may want to split it up. I will write in the following way then: hgei_mask = csr_read(CSR_HGEIP); hgei_mask &= csr_read(CSR_HGEIE); > >> + csr_clear(CSR_HGEIE, hgei_mask); >> + >> + spin_lock_irqsave(&vgein->lock, flags); >> + >> + for_each_set_bit ( guest_file_id, hgei_mask ) >> + { >> + /* >> + * guest_file_id shouldn't be zero, as it will indicate that no >> + * guest external interrupt source is selected for VS-level external >> + * interrupts. >> + */ >> + ASSERT(guest_file_id); > > While it only affects debug builds, this check still needlessly is > done on every loop iteration, when doing it once ahead of the loop > would suffice. Good point. I will do in the following way then before the loop: /* * Bit 0 of HGEIP/HGEIE is read-only zero: guest interrupt file ID 0 * means that no guest external interrupt source is selected. */ ASSERT(!(hgei_mask & 1)); > >> + if ( vgein->owners[guest_file_id] ) >> + { >> +#ifdef VGEIN_DEBUG >> + gprintk(XENLOG_DEBUG, "%s: kick ->%pv, hgei_mask(%#lx)\n", >> + __func__, vgein->owners[guest_file_id], hgei_mask); >> +#endif > > This can ocur very frequently (when VGEIN_DEBUG is defined). A > trace record may be a better alternative. Agree, it would be nice but tracing isn't ready for RISC-V. Considering that we haven't had any issue with hgei interrupt for a long time I will just drop gprintk() for now and use `trace record` when functionality will be ready. > >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -136,6 +136,8 @@ static void vcpu_csr_init(struct vcpu *v) >> v->arch.hstateen0 = (hstateen0 & csr_masks.hstateen0) | >> csr_masks.ro_one.hstateen0; >> } >> + >> + v->arch.hie = MIP_SGEIP; > > Neither part of the rhs identifier has anything to do with the CSR > having its default value set here. That's perhaps again a piece of > RISC-V I'm missing, but I can't make sense of this. All interrupt pending/enable CSRs share one bit layout (bit N corresponds to interrupt cause N), which is why MIP_SGEIP happened to be numerically right. I'll use BIT(IRQ_S_GEXT, UL) instead and add a comment: hie.SGEIE is what allows the SGEI raised through hgeie to be taken by Xen at all, while hie's VS-level bits alias the guest's vsie and are left cleared. I will apply the following change: - v->arch.hie = MIP_SGEIP; + /* + * Enable SGEIs, so that a guest interrupt file marked in HGEIE while + * the vCPU is descheduled can raise an interrupt to Xen. + * + * The VS-level bits of hie alias the guest's vsie, which is saved and + * restored separately, so they are left clear here. + */ + v->arch.hie = BIT(IRQ_S_GEXT, UL); > >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -510,12 +510,31 @@ void cf_check imsic_ctxt_switch_from(struct vcpu *v) >> >> write_lock_irqsave(&imsic_state->vsfile_lock, flags); >> imsic_state->vsfile_cpu = v->processor; >> + /* >> + * Start to observe the VS-file from HS-mode: while the vCPU isn't >> + * running an interrupt pending in its VS-file is reported through HGEIP >> + * instead of being delivered to VS-mode, which lets Xen wake the vCPU up. >> + */ >> + csr_set(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); >> write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >> } > > It is suspicious for the HGEIE write to be the last step. How's this free > of a window where an interrupt is lost. (Sorry, likely another blind spot > of mine wrt RISC-V.) There's no window: a guest interrupt file's hgeip bit is level-sensitive, i.e. it reflects whether the file currently has a pending-and-enabled interrupt (the MSI itself stays latched in the file's eip[] until the guest claims it), and hip.SGEIP is simply (hgeip & hgeie) != 0. So an MSI arriving after the vCPU stopped running but before hgeie is set raises an SGEI as soon as the bit is set, taken once interrupts are re-enabled. I'll extend the comment to say so: /* * Start to observe the VS-file from HS-mode: while the vCPU isn't * running an interrupt pending in its VS-file is reported through HGEIP * instead of being delivered to VS-mode, which lets Xen wake the vCPU up. * * HGEIP is level-sensitive, reflecting the VS-file's current state, so * an interrupt that became pending before this point raises an SGEI as * soon as the bit is set in HGEIE; nothing is lost in between. */ Does it make sense? > >> void cf_check imsic_ctxt_switch_to(struct vcpu *v) >> { >> - /* Nothing to do */ >> + struct vimsic_state *imsic_state = v->arch.vimsic_state; >> + unsigned long flags; >> + >> + /* A s/w VS-file is never observed through HGEIP. */ >> + if ( !vcpu_guest_file_id(v) ) >> + return; >> + >> + /* >> + * The vCPU is about to run, so hstatus.VGEIN delivers the VS-file's >> + * interrupts to it directly and there is nothing left for Xen to observe. >> + */ >> + read_lock_irqsave(&imsic_state->vsfile_lock, flags); >> + csr_clear(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); >> + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >> } > > How can this be a read-lock when you write a CSR? But here is a protection of ->guest_file_id not of write to a CSR and we want to not have a change of ->guest_file_id during an update of CSR_HGEIE. > Or else - why is locking > here necessary in the firt place? Strictly speaking no locking is needed with the current implementation: HGEIE is local to this pCPU, and guest_file_id can't change concurrently. It's updated either by this very pCPU ahead of switching the vCPU in (imsic_migrate_vcpu() called from schedule(), imsic_vsfile_attach() right after), or while the vCPU can't be scheduled: sched_unit_migrate_finish() defers to unit_context_saved() while the unit is running, and sched_move_domain() pauses the domain. (and the similar are true for imsic_ctxt_switch_from()) But IMO we should keep around ->vsfile_lock to not miss the case where some case will update ->guest_file_id in parallel with imsic_ctxt_switch_to(). Does it make to continue to have read_lock_irqsave(...->vsfile_lock, ...) here just for potential future cases? Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:07:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:07:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427584.1650381 (Exim 4.92) (envelope-from ) id 1x8efh-0003Rc-8f; Mon, 21 Sep 2026 14:07:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427584.1650381; Mon, 21 Sep 2026 14:07:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8efh-0003RV-4y; Mon, 21 Sep 2026 14:07:05 +0000 Received: by outflank-mailman (input) for mailman id 1427584; Mon, 21 Sep 2026 14:07:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eff-0003RP-F1 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:07:03 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8efd-008yZX-1w; Mon, 21 Sep 2026 14:07:01 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8efe-00EEH3-0F; Mon, 21 Sep 2026 14:07:01 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=AW89nSFl2DlhdpwtKR1mRTOJ8GHcG2o4/yDHd1XsqHc=; b=PBWUV/WT4EOEW/NSTX5LjT6LLP QWjvnjCLKqe0zed9m3hn6/LxCziUnPLCYOnP6M9B7U1AZ9+PR9uNA/rCWEn7VA7Fh/LbB/MQTmBYt wh+k+giBqcL/XnJSptNmxJ/+T8j3E4pNH4xX1EmeTsl51wVlmlIlpL1ictEB6OyKjVbc=; Date: Mon, 21 Sep 2026 16:06:55 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Alejandro Vallejo Cc: Jan Beulich , "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH] x86/HVM: replace paging_mode_hap() uses Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Sep 21, 2026 at 03:45:29PM +0200, Alejandro Vallejo wrote: > On Mon Sep 21, 2026 at 3:19 PM CEST, Jan Beulich wrote: > > HVM guests cannot run without either HAP or shadow enabled. While > > paging_mode_shadow() is compile-time-constant when SHADOW_PAGING=n, > > paging_mode_hap() isn't. Hence the former is preferred to leverage DCE. > > > > In svm_update_guest_cr() combine two adjacent conditionals. > > > > Signed-off-by: Jan Beulich > > Yes, please. > > Reviewed-by: Alejandro Vallejo > > A couple of nits below. Take them or leave them. > > > --- a/xen/arch/x86/hvm/svm/svm.c > > +++ b/xen/arch/x86/hvm/svm/svm.c > > @@ -113,7 +113,8 @@ static void cf_check svm_update_guest_cr > > switch ( cr ) > > { > > case 0: > > - if ( paging_mode_hap(v->domain) ) > > + value = v->arch.hvm.guest_cr[0]; > > + if ( !paging_mode_shadow(v->domain) ) > > { > > uint32_t intercepts = vmcb_get_cr_intercepts(vmcb); > > > > @@ -122,9 +123,7 @@ static void cf_check svm_update_guest_cr > > monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) ) > > vmcb_set_cr_intercepts(vmcb, intercepts | CR_INTERCEPT_CR3_WRITE); > > } > > - > > - value = v->arch.hvm.guest_cr[0]; > > - if ( paging_mode_shadow(v->domain) ) > > + else > > value |= X86_CR0_PG | X86_CR0_WP; > > nit: This would be clearer with the polarity reversed. Check shadow > first and have hap later. It'd also make the diff (marginally) smaller too. > > > vmcb_set_cr0(vmcb, value); > > break; > > --- a/xen/arch/x86/hvm/vmx/vmcs.c > > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > > [snip] > > > v->arch.hvm.vmx.exception_bitmap = HVM_TRAP_MASK > > - | (paging_mode_hap(d) ? 0 : (1U << X86_EXC_PF)); > > + | (!paging_mode_shadow(d) ? 0 : (1U << X86_EXC_PF)); > > nit: Shouldn't | be on the prior line? It was there before, but seeing > how you're adjusting indentation might as well move that char. > > In the same vein as before, it'd be a bit clearer with the polarity > inverted (shadow() ? bit : 0 ) I agree with both suggestions in principle, always better if we can avoid negations. Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:08:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:08:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427591.1650389 (Exim 4.92) (envelope-from ) id 1x8ehU-00049a-In; Mon, 21 Sep 2026 14:08:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427591.1650389; Mon, 21 Sep 2026 14:08:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ehU-00049T-Fk; Mon, 21 Sep 2026 14:08:56 +0000 Received: by outflank-mailman (input) for mailman id 1427591; Mon, 21 Sep 2026 14:08:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ehT-00049A-BO for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:08:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8ehS-006sLz-OE for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:08:54 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab13a74-8faa-0a2a0a5109dd-0a2a4501e9c6-2 for ; Mon, 21 Sep 2026 16:08:54 +0200 Received: from [52.101.61.57] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab13a74-5984-0a2a45010019-34653d39a278-3 for ; Mon, 21 Sep 2026 16:08:54 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by DM6PR12MB4436.namprd12.prod.outlook.com (2603:10b6:5:2a3::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 14:08:30 +0000 Received: from BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740]) by BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740%3]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 14:08:30 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VTvCXgdyXfdgdtGIM8Hbh/LvYn6PCPWtm2LBHo2enisQlHxnPHvQ1zuuX0w4DqnIeoPENFEZcAxplGCfCgbVeKBtxRpuqautClMWVH0IPfHlF6DWTOqj3nabp8XaWtK69HBAXSRyvNzsgQ/VbG/fDyVCqR3Z2O+f3/gbkghOH5XKS+NkaQL4i2ZAa3oPhIygT3dOibXymTA2xu0S9XCWnV+RgQzCA4mmGKmyQIbzoGaC5Q+Ior/GVj3In+cn+ECzZUo8NaMVAxurhK4bGEdK4FwZUG2MSyXCdpjVZUUBG4SWsArVixU8nwetGhIoSlNT64sO15AXzz+tBDD0/ehFgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DNVH4bE2jIJZ98SIyat7oDSZ1XLOwqVrLXxcDv8/2Go=; b=UP8x3XUXjmEcbJH26hA6D98Cfe7MVzP6hESMljpIqvsDfPhcfeD91jhRIk5kLyfDjw9DuhFgWkpT91Ondgnp8iwF1mk07RY7ucAxgcuZY+TWwPBHrqw3Ri3ksPHSD/ouiIwsxJRpNNYpNz0PqR1TXQ4GRpG2YPIRHzA+IVViH5g+nn8a8v9DVLjszKywb4Zq2TKlfCXUv+CnFnLtQsaWwDUqS5SDjhey5NJVal/kaHaVVBENIuS8ogw7suXysYCPynvXfLHzcUHBcNAr7Bbw7mGIHQTHZefYDZc4ctLwEoBz63R7SQjvYc3VfZm8nJx3OmZq3Mm4q/atgAYsCmD0dg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DNVH4bE2jIJZ98SIyat7oDSZ1XLOwqVrLXxcDv8/2Go=; b=Mc1hAmZgc8+lVJ1+HFuRcYjjVUlaTw+5EUfXLytohfZaC+x6SuW13WTO1WoNplG8Cj78EDFRgatZVWtl0BCqtoxDbVogya2gdwcQu9gIGAXXmf0BG/ny/ikJ3NEPnj+dxLGGbTIVecGqqH4O3xayn/4OcF3ib6TtsnLnU5EZQ9k= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 21 Sep 2026 16:08:26 +0200 Message-Id: Subject: Re: [PATCH v2 2/6] automation/qtb: add jinja2 device trees for riscv64 smoke tests From: "Alejandro Vallejo" To: "Baptiste Le Duc" , Cc: "Doug Goldstein" , "Stefano Stabellini" X-Mailer: aerc 0.17.0 References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech> In-Reply-To: <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech> X-ClientProxiedBy: MA2P292CA0024.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::6) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|DM6PR12MB4436:EE_ X-MS-Office365-Filtering-Correlation-Id: e64c50f4-f356-4559-f431-08df17e9d0b0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|10067099003|11063799006|6133799003|22082099003|18002099003|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: /Sy4XUOnJIXITEX6rIIyqofb/lK0x0WdJLt3J3/XdMAdGeiElOS1lrPjfnMW5Rmjtgu2CZXEwzl9PDKQUb1AguSZP/DGgmxGX2NyLLe2Dj/ZtjkRxsDZUDT1UIgO0LR7J5onZn/evL4f6yV0ENC/3bvUhQDmVy39my3BYH9IQEPVKbQk5ZlAKk8CVKCJKu6HaLB9q9ncxssRXhWhQSqnhNfAw3TwWNpl1Uh6AE99ZpIwxGL4yo6rEpSlN5AnWnwh8uHU4hjxUe9tcrUMgMnTDS/FXK1mi9x22/wk9gBx8QNnWn+XR/u7nyo4t6VI56gNxK03PSFNzIsvFYUkoMSr+VmmodUyY04CWdhTifuJjpvqNQHtm7yBnywkqc3mDmxywoX2qe3s5/IJ03UwCLmnB6Jnthun4nsUw96D4z/CPCEMPc5zdtIEkboZY81YL1UTGsYA34BpwfKqOUujis4akTizS0W8TxawL30yklRyhjf885ERIkkxYQQwjdIK9tzwMrMGGHZQwZA6NAIFnOjG6kvquZI92QdBpugnkEb1ZYaWuHF3uT4ZiH+8HPW8wIVlXqNAh8eztFwkrm+/gaT8vH8YkHAT1hYlLTjTNiFnhZvwGfOEthOFsEBQcRLtqDbAkOBbNMotWCN/XxEyXMjQxQTE+ka4uUgeLz8qs7ntxNM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB4999.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(10067099003)(11063799006)(6133799003)(22082099003)(18002099003)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WENOU25nZlpYZ2hYMDZWMXI0R2ZJN3QzSWFzNEFBeXRmTXhYVlZiUG5sRkxB?= =?utf-8?B?RDJRRmVoMGxhUUMvcGFzTTdYbzFBcnJFUHkxdUVER2ptcUV5YmozQUgrdjNW?= =?utf-8?B?bi85c0VOWjl2R0pKajExWVFpM0h0eVI5T09sUDgrTGpYWjJDMEVzeGxyRGRK?= =?utf-8?B?NU5XamlRS2UrSDZKcmtmdFdGOVhpL014anJiTjM5SDBVcTZoZUQ3MEtKY2J0?= =?utf-8?B?SjlwOVQvK0N3RUVGUTdOdi9DQXR1ZVM5SGRhb0FMdHhOa3dScXZJNDJLekha?= =?utf-8?B?V0h6TnNSa3BoRzRkaVZweDhrUnRwU0JuN0dYdHJvR0o1WmFjVzhmOFdzcGtE?= =?utf-8?B?aTBiT0ptTVdDMG1IRGlLbTF4Y3c4TEJiQThrVzVQaFRYb05vSXF1YUt1bUxt?= =?utf-8?B?c0N6TFB4WFJRSWN4di81QWx1UGdyaEpFZldWTkZ2M0pJd0xIK05rdGNQZnd5?= =?utf-8?B?NE1VUDB5Z3ZVS0M5M2N0TWRrUVFPRExMTitwa1h5QTlPT2VWT3pMMU9veHI4?= =?utf-8?B?SFppYTJpamRnNWp5djJxMlh6dmlkcTJRUFFveFJLcEpobzhvSnIveWpQMkg0?= =?utf-8?B?bm5Yc0RBMjhxTVhKejlyWllVbm0zanAzRXFPQVlBek1vazdlZjBMNjVPYmRU?= =?utf-8?B?Qm5ENjR4NzVQVlVuSGphalYybnFqc3RyQmgxOU9DcmtTbEJHK2ZZMDM0VkFP?= =?utf-8?B?WGdNOWpsdWhEaWdKV0hWQUpRK1lUUTNMSGtMbFVJNE5EYXovbERWMVhSWGR6?= =?utf-8?B?N2ViSmRnbjVMZDF1MVl4WHdsUE0rZlMxeUlNTmN3V0ZBajlSMHd5ejhacXRI?= =?utf-8?B?NEZlSkFaTVRnSjRvSEJKdnJHRGZQYUxpdEEyRTNvNTVIT3FLRlpNa1J0ek1x?= =?utf-8?B?bnVTMk1VS21XaFhvZFcvZ3k2bVoyRWRpQU95Yms2SkZPWHZ0cTU0Z2NER1Ew?= =?utf-8?B?Y1A5c1d4dGRVMjdTSXZSdGVJMlU3RXprdTlSTjBMcDVCYlR4RXdzaW5OTW16?= =?utf-8?B?bjJXdVFUNVRkcjFCZ203N1FuZDN5NnJQV2xuY2NRK3NJZDN3YnQ4S3NIVFFH?= =?utf-8?B?b3NkRXFqUXd6aTBJZ05QOXRNWjlycjBqTHJKWm1seUw1ZW5kczJ6MVdES0pL?= =?utf-8?B?MmdHK3R5UjJDZHpEZ0xoWEMrL2p1bnFaaDlRZWsyalNrRklHODR5LzBnMTN0?= =?utf-8?B?WWhEYy9mcDlOeWtxT3UwdjlpY0lUWUpGdlJBOVh0aWJWeWtZNXhDbVRWdE9E?= =?utf-8?B?SGQyeTcybVZKQWpacWV1cXJGN3llNHQyenNtaDhIOUYyQ0FpdFpTdXRXWWg3?= =?utf-8?B?by9jYUp1NXpydFQxSHdVUVIxRkQ3STYxQzFCSWljWTg1cnJSWVVJQkRQU3FG?= =?utf-8?B?ZG1XVkJlK2R5WktUdW5lZjlFZUFJVGsyTWwzVHd0RXFONVRsdzBiVVltTm9O?= =?utf-8?B?NDAveTdRSkQ4QUZRZVBIeDdBWDdpUmMzZkhsbTdlNmUrRjhYaUc3Z0JCNnFz?= =?utf-8?B?Mld2K21ZMGsrczhWa3NjbW8zVkR6YjZ0Kzh2MHZYNXN4WVVSazQvdjRsdks3?= =?utf-8?B?RVMxeXIraTF1S1BmMDFxNnBoRlhsR1dscys4U3hvUmtkN2J3OThQeFpZaEV2?= =?utf-8?B?TmUrY3FOR0pFcTU2WWNZcmhpRnYzWmNvbzc3dk9UY050Q0dkaE9YbkE2cGhL?= =?utf-8?B?YkgzbTF6Um16RDNXTWJBMVdaUS9mZDBodWZIUlF5alRrV05CdUFJbzArWjV0?= =?utf-8?B?ZGUxcTllWGwyZEcwSmZZNERpVi94WEk0VUpYakg3WWdJR2c5aEhUQ0IzYTdW?= =?utf-8?B?WnlvN1VhVkw2aE8yYjhmUGtNZ2NrN0V4REgrbm1FR3lmNU56Yjh1cWpGQWc2?= =?utf-8?B?MlNhNEMzOHdablZTTjNmS3VsN1hvNXBFV1pOa1VtYWE3UWZaZzhmZUE0RDhC?= =?utf-8?B?a0VUT1Y2MDZWWlphKzlFM0s0LzYvVUR6cElZSHl3bzFodnVpSlBDU3VFcUhn?= =?utf-8?B?cmk4V0NYVHAwMnFuR05OK0ZrK3NzN25nSVA1UElHTisvVUFmc1JvZXo4U3VJ?= =?utf-8?B?blYzdStjckV1TXdUSm05YzRuZXhCTkh3MmozYWk2bVlYQ0E3ZUJiSEhnY0dN?= =?utf-8?B?VWJoY1EwdlNseE5mRFJsbWpyTys1VTk4SmpNZ3FsRDQ5NVdRaS92cUdOTGhC?= =?utf-8?B?VDJ6c2V3aG15c0tZNXlDNURTUGtCUXNOTWVqNXEvK1dCcUhpSllRcGplSFQz?= =?utf-8?B?M0d3Q05hSDlLZXFCMGEzeitXNjUrWFJYbG5Oam9qRlF4bE1WNXNSazFhcS9a?= =?utf-8?Q?UikT0thwjjcYq2j6qv?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: e64c50f4-f356-4559-f431-08df17e9d0b0 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 14:08:30.7341 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: d+G2NSUPjACHO0SMZ/gS+lcbHEJIshcRzLfH7P2KwVDe+T4em0qoMRofWSjfmYU+Fwcfq3G95ohwaeabndxa9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4436 X-purgate-ID: tlsNG-d62444/1789999734-BEC61757-F5B1156C/0/0 X-purgate-type: clean X-purgate-size: 8019 On Thu Aug 27, 2026 at 11:42 AM CEST, Baptiste Le Duc wrote: > The dom0less RISC-V smoke tests need a host device tree describing the > platform (CPUs, APLIC/IMSIC, uart). It varies per machine (hart count, MM= U > type), so a single static .dts cannot cover the test matrix. > > Add dts/qemu-host.dts.j2, a template of the QEMU virt platform in > aia=3Daplic-imsic mode: per-hart cpu/cpu-intc nodes, the M- and S-mode AP= LIC > and IMSIC pairs, CLINT and the ns16550a uart. It takes ncpus, mmu_type an= d > xen_bootargs as arguments. Alternatively, why not query it from qemu itself? See "-machine dumpdtb=3Ddump.dtb" in "qemu-smoke-dom0less-arm64.sh" Then you can use fdtput to add nodes as needed, with all hardware being consistent with QEMU without undue magic replacements. Having a configurable .dts seems like a silent mistake about to happen. Check out that file of arm automation for DTB manipulation. I think it's best if all DTB ports behave the same way. Cheers, Alejandro > > Values QEMU hardcodes are set as named constants matching their source > symbols (QEMU_UART0_IRQ, QEMU_IRQCHIP_NUM_SOURCES, ...) rather than > open-coded, so a QEMU-side change is easy to trace. > > The template is inert on its own: the generated dtb will be used in next > patch. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > .../scripts/qtb/riscv/dts/qemu-host.dts.j2 | 160 ++++++++++++++++++ > 1 file changed, 160 insertions(+) > create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > > diff --git a/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 b/automati= on/scripts/qtb/riscv/dts/qemu-host.dts.j2 > new file mode 100644 > index 0000000000..13a8e983ce > --- /dev/null > +++ b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > @@ -0,0 +1,160 @@ > +/dts-v1/; > + > +{#- > + * Jinja2 QEMU "virt" platform device tree for Xen RISC-V tests. > + * > + * Interrupt controller: APLIC in MSI mode + IMSIC > + * (QEMU -M virt,aia=3Daplic-imsic). > + * > + * Rendered by xen_dt.py. > + * > + * Variables: > + * ncpus - number of physical harts (int, >=3D 1= ) > + * mmu_type - Xen host MMU type, e.g. "sv39" (string) > + * xen_bootargs - Xen command line (string) > + * > + * Per-hart nodes are labelled cpu / cpu_intc and referenced with = &label. > + * > + * No `aia-guests=3DN`, so no VS-mode guest files: IMSIC reg size is > + * ncpus * page size. > +-#} > +{#- Values QEMU hardcodes, need to be described to Xen -#} > +{%- set QEMU_TIMEBASE_FREQUENCY =3D 10000000 %} {#- RISCV_ACLINT_DEFAU= LT_TIMEBASE_FREQ -#} > +{%- set QEMU_IRQCHIP_NUM_SOURCES =3D 96 %} {#- VIRT_IRQCHIP_NUM_S= OURCES (virt.h) -#} > +{%- set QEMU_IRQCHIP_NUM_MSIS =3D 255 %} {#- VIRT_IRQCHIP_NUM_M= SIS -#} > +{%- set QEMU_UART_CLOCK_FREQUENCY =3D 3686400 %} {#- create_fdt_uart() = -#} > +{%- set QEMU_UART0_IRQ =3D 10 %} {#- UART0_IRQ -#} > +{%- set QEMU_IMSIC_PAGE_SZ =3D 0x1000 %} {#- IMSIC_MMIO_PAGE_SZ= -#} > + > +{%- set IRQ_TYPE_LEVEL_HIGH =3D 4 %} > +{%- set APLIC_IRQ_CELLS =3D 2 %} > + > +{%- set IRQ_M_SOFT =3D 3 %} > +{%- set IRQ_M_TIMER =3D 7 %} > +{%- set IRQ_S_EXT =3D 9 %} > +{%- set IRQ_M_EXT =3D 11 %} > + > +/ { > + #address-cells =3D <0x02>; > + #size-cells =3D <0x02>; > + compatible =3D "riscv-virtio"; > + model =3D "riscv-virtio,qemu"; > + > + memory@80000000 { > + device_type =3D "memory"; > + reg =3D <0x00 0x80000000 0x00 0x80000000>; > + }; > + > + cpus { > + #address-cells =3D <0x01>; > + #size-cells =3D <0x00>; > + timebase-frequency =3D <{{ QEMU_TIMEBASE_FREQUENCY }}>; > +{% for i in range(ncpus) %} > + cpu{{ i }}: cpu@{{ i }} { > + device_type =3D "cpu"; > + reg =3D <0x{{ '%x' % i }}>; > + status =3D "okay"; > + compatible =3D "riscv"; > + riscv,cbop-block-size =3D <0x40>; > + riscv,cboz-block-size =3D <0x40>; > + riscv,cbom-block-size =3D <0x40>; > + riscv,isa =3D "rv64imafdch_zicntr_zicsr_zifencei_zihintpause= _zihpm_zba_zbb_zbs_smstateen_svpbmt_smaia_ssaia"; > + mmu-type =3D "riscv,{{ mmu_type }}"; > + > + cpu{{ i }}_intc: interrupt-controller@{{ i }} { > + #interrupt-cells =3D <0x01>; > + interrupt-controller; > + compatible =3D "riscv,cpu-intc"; > + }; > + }; > +{% endfor %} > + cpu-map { > + > + cluster0 { > +{% for i in range(ncpus) %} > + core{{ i }} { > + cpu =3D <&cpu{{ i }}>; > + }; > +{% endfor %} > + }; > + }; > + }; > + > + soc { > + #address-cells =3D <0x02>; > + #size-cells =3D <0x02>; > + compatible =3D "simple-bus"; > + ranges; > + > + serial@10000000 { > + interrupts =3D <{{ QEMU_UART0_IRQ }} {{ IRQ_TYPE_LEVEL_HIGH = }}>; > + interrupt-parent =3D <&aplic_s>; > + clock-frequency =3D <{{ QEMU_UART_CLOCK_FREQUENCY }}>; > + reg =3D <0x00 0x10000000 0x00 0x100>; > + compatible =3D "ns16550a"; > + }; > + > + aplic_s: aplic@d000000 { > + riscv,num-sources =3D <{{ QEMU_IRQCHIP_NUM_SOURCES }}>; > + reg =3D <0x00 0xd000000 0x00 0x8000>; > + msi-parent =3D <&imsic_s>; > + interrupt-controller; > + #interrupt-cells =3D <{{ APLIC_IRQ_CELLS }}>; > + compatible =3D "riscv,aplic"; > + }; > + > + aplic@c000000 { > + riscv,delegate =3D <&aplic_s 0x01 {{ QEMU_IRQCHIP_NUM_SOURCE= S }}>; > + riscv,children =3D <&aplic_s>; > + riscv,num-sources =3D <{{ QEMU_IRQCHIP_NUM_SOURCES }}>; > + reg =3D <0x00 0xc000000 0x00 0x8000>; > + msi-parent =3D <&imsic_m>; > + interrupt-controller; > + #interrupt-cells =3D <{{ APLIC_IRQ_CELLS }}>; > + compatible =3D "riscv,aplic"; > + }; > + > + imsic_s: imsics@28000000 { > + riscv,num-ids =3D <{{ QEMU_IRQCHIP_NUM_MSIS }}>; > + reg =3D <0x00 0x28000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSI= C_PAGE_SZ) }}>; > + interrupts-extended =3D < > + {%- for i in range(ncpus) %} > + &cpu{{ i }}_intc {{ IRQ_S_EXT }} > + {%- endfor %} > + >; > + msi-controller; > + interrupt-controller; > + #interrupt-cells =3D <0x00>; > + compatible =3D "riscv,imsics"; > + }; > + > + imsic_m: imsics@24000000 { > + riscv,num-ids =3D <{{ QEMU_IRQCHIP_NUM_MSIS }}>; > + reg =3D <0x00 0x24000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSI= C_PAGE_SZ) }}>; > + interrupts-extended =3D < > + {%- for i in range(ncpus) %} > + &cpu{{ i }}_intc {{ IRQ_M_EXT }} > + {%- endfor %} > + >; > + msi-controller; > + interrupt-controller; > + #interrupt-cells =3D <0x00>; > + compatible =3D "riscv,imsics"; > + }; > + > + clint@2000000 { > + interrupts-extended =3D < > + {%- for i in range(ncpus) %} > + &cpu{{ i }}_intc {{ IRQ_M_SOFT }} &cpu{{ i }}_intc {= { IRQ_M_TIMER }} > + {%- endfor %} > + >; > + reg =3D <0x00 0x2000000 0x00 0x10000>; > + compatible =3D "sifive,clint0", "riscv,clint0"; > + }; > + }; > + > + chosen { > + stdout-path =3D "/soc/serial@10000000"; > + xen,xen-bootargs =3D "{{ xen_bootargs }}"; > + }; > +}; From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:16:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:16:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427598.1650398 (Exim 4.92) (envelope-from ) id 1x8eow-0005kf-AA; Mon, 21 Sep 2026 14:16:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427598.1650398; Mon, 21 Sep 2026 14:16:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eow-0005kY-63; Mon, 21 Sep 2026 14:16:38 +0000 Received: by outflank-mailman (input) for mailman id 1427598; Mon, 21 Sep 2026 14:16:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8eou-0005kQ-Q3 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:16:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8eou-00E8iT-2f for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:16:36 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab13c2c-e002-0a2a0a5209dd-0a2a4502e4f0-40 for ; Mon, 21 Sep 2026 16:16:35 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab13c43-6ca4-0a2a45020019-b9ff1c23989d-3 for ; Mon, 21 Sep 2026 16:16:35 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c4534c3a00072c4.00a for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 21 Sep 2026 14:16:28 +0000 Received: from l14 (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: anthony.perard) by mail2.vates.fr (Postfix) with ESMTPSA id 0388481CD9; Mon, 21 Sep 2026 16:16:27 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=pOGCXt6vkCQlwrtS3DnhULGdJQA42r2yTBWcqvBKXss=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=l3USAwaXsfEkrTMnZDawZpzX4yBTAEtUQdvpUboSqUepF1WOsK3AX3dDyI6sTzWNa4kZua8Ub RpIKBj8063B6t/RDV6wR52weSgnMnUyWk1coH/rheg0vsNE86fofZ4V/IbeSw1ef67KFjJcDDUw RbpJVpjHc6ko39G9enfpRFIk2BNCEjau7J8D1ieHxH3z5rJ5payeYsvnoF/fotmwv/H+EPm556R OBKQDxdK8Jpltk6OSUcg8gWHNgMJuWFV7feDvs8pGdahQYScwvTxOikHXrf63RVHvXS1POlvrXT /oibblNsXT3xbcmILldsJ3hIjBFcxDHKEgqeNuXJ0IXQ== X-Zone-Loop: 3a9441f31822fecd954392836c5ef1b4d450c1300250 x-campaign-type: default x-transaction-id: 06c5598e-38eb-4d58-8439-75c73379deef x-swg-uid: 01-6f3484ae-ac9e-4747-bacf-3fbe651426a1 X-Mailer: Sweego Message-ID: <1790000188.8631fc262581453bbf619ec5b2062170.1a0c4534c3a00072c4@vates.tech> x-swg-bid: 1790000188.8631fc262581453bbf619ec5b2062170.1a0c4534c3a00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 21 Sep 2026 16:16:26 +0200 From: Anthony PERARD To: Julian Vetter Cc: xen-devel@lists.xenproject.org, Oleksii Kurochko , Community Manager , Andrew Cooper , Michal Orzel , Jan Beulich , Julien Grall , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Stefano Stabellini , Juergen Gross , Andrii Sultanov , Guillaume Thouvenin , Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Moisieiev , Timothy Pearson , Alistair Francis , Connor Davis , Teddy Astie Subject: Re: [PATCH v5 5/6] xen/arm: report clock_frequency via sysctl physinfo, not createdomain References: <1789130592.8631fc262581453bbf619ec5b2062170.1a0907e5286000c4f3@vates.tech> <1789130864.8631fc262581453bbf619ec5b2062170.1a0908275e9000c4f3@vates.tech> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1789130864.8631fc262581453bbf619ec5b2062170.1a0908275e9000c4f3@vates.tech> X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.2b3.72d97aefce43d207.1a0c4534933.334128e23dbc3fbb=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790000187699 X-purgate-ID: tlsNG-720697/1790000195-F2AB52AC-8920BDEE/0/0 X-purgate-type: clean X-purgate-size: 4214 ---=Part.2b3.72d97aefce43d207.1a0c4534933.334128e23dbc3fbb=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 11, 2026 at 02:47:35PM +0200, Julian Vetter wrote: > diff --git a/tools/libs/light/libxl=2Ec b/tools/libs/light/libxl=2Ec > index a1fe16274d=2E=2Eec7e6d3f65 100644 > --- a/tools/libs/light/libxl=2Ec > +++ b/tools/libs/light/libxl=2Ec > @@ -410,6 +410,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinf= o *physinfo) > physinfo->cap_gnttab_v2 =3D > !!(xcphysinfo=2Ecapabilities & XEN_SYSCTL_PHYSCAP_gnttab_v2); > physinfo->arch_capabilities =3D xcphysinfo=2Earch_capabilities; > + physinfo->arch_clock_frequency_hz =3D xcphysinfo=2Earch_clock_frequ= ency_hz; That new field name doesn't really make sense=2E How a clock can be arch specific? Which clock, I'm sure they can be many? (also a comment about that new field in `libxl_physinfo` which is said to be ARM only, which doesn't make sense because every CPU architectures needs a clock, or many)=2E Anyway, if the name is acceptable in the hypervisor public interfaces, so be it=2E > diff --git a/tools/libs/light/libxl_arm=2Ec b/tools/libs/light/libxl_arm= =2Ec > index 283cfb749b=2E=2E3d232040c9 100644 > --- a/tools/libs/light/libxl_arm=2Ec > +++ b/tools/libs/light/libxl_arm=2Ec > @@ -252,6 +252,9 @@ int libxl__arch_domain_save_config(libxl__gc *gc, > libxl__domain_build_state *state, > const struct xen_domctl_createdomain= *config) > { > + libxl_physinfo info; > + int rc; > + > switch (config->arch=2Egic_version) { > case XEN_DOMCTL_CONFIG_GIC_V2: > d_config->b_info=2Earch_arm=2Egic_version =3D LIBXL_GIC_VERSION= _V2; > @@ -264,7 +267,23 @@ int libxl__arch_domain_save_config(libxl__gc *gc, > return ERROR_FAIL; > } > =20 > - state->clock_frequency =3D config->arch=2Eclock_frequency; > + libxl_physinfo_init(&info); > + rc =3D libxl_get_physinfo(CTX, &info); Could you move both call to the beginning of the function? It might be useful to more than just the new code=2E > + if (rc) { > + LOG(ERROR, "failed to get physinfo"); > + libxl_physinfo_dispose(&info); It would be better if there's only a single call of this function throughout the function, and so only a single error path=2E Could you an "out" label at the end a of function, and =2E=2E > + return ERROR_FAIL; =2E=2E this and the `_dispose()` call can be replace by `goto out`; No need to change the value of `rc`, it's already set by a libxl function so it can be returned=2E > + } > + /* > + * Pass the timer frequency on to the guest DT only when Xen took i= t from > + * the host DT (XEN_SYSCTL_PHYSCAP_ARM_TIMER_DT_FREQ)=2E Otherwise = the guest > + * gets the right value from CNTFRQ_EL0=2E > + */ > + if (arch_capabilities_arm_timer_dt_freq(info=2Earch_capabilities)) > + state->clock_frequency =3D info=2Earch_clock_frequency_hz; > + else > + state->clock_frequency =3D 0; Add here: rc =3D 0; out: > + libxl_physinfo_dispose(&info); > =20 > return 0; Then replace the return by `return rc`; Then, replace every `return X` in the function by rc =3D X; goto out; That error handling style is used in many places in libxl=2E > } > diff --git a/tools/libs/light/libxl_types=2Eidl b/tools/libs/light/libxl= _types=2Eidl > index 8699ab3013=2E=2Ee2e4be7323 100644 > --- a/tools/libs/light/libxl_types=2Eidl > +++ b/tools/libs/light/libxl_types=2Eidl > @@ -1201,6 +1201,7 @@ libxl_physinfo =3D Struct("physinfo", [ > ("cap_gnttab_v1", bool), > ("cap_gnttab_v2", bool), > ("arch_capabilities", uint32), > + ("arch_clock_frequency_hz", uint32), # ARM only > ], dir=3DDIR_OUT) > =20 > libxl_connectorinfo =3D Struct("connectorinfo", [ Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vate= s solutions web: https://vates=2Etech ---=Part.2b3.72d97aefce43d207.1a0c4534933.334128e23dbc3fbb=--- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:30:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:30:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427611.1650406 (Exim 4.92) (envelope-from ) id 1x8f25-0000Ly-EJ; Mon, 21 Sep 2026 14:30:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427611.1650406; Mon, 21 Sep 2026 14:30:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8f25-0000Lr-BP; Mon, 21 Sep 2026 14:30:13 +0000 Received: by outflank-mailman (input) for mailman id 1427611; Mon, 21 Sep 2026 14:30:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8f23-0000Ll-Dc for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:30:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8f22-002hdr-HW for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:30:10 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab13f6e-8faa-0a2a0a5109dd-0a2a4509de40-10 for ; Mon, 21 Sep 2026 16:30:09 +0200 Received: from [192.198.163.7] (helo=mgamail.intel.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab13f6e-be1a-0a2a45090019-c0c6a307741d-3 for ; Mon, 21 Sep 2026 16:30:08 +0200 Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2026 07:30:06 -0700 Received: from ettammin-mobl3.ger.corp.intel.com (HELO [10.245.244.155]) ([10.245.244.155]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2026 07:30:03 -0700 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=Intel header.d=intel.com header.i="@intel.com" header.h="Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Transfer-Encoding:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1790001008; x=1821537008; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=KEIz1oZeYNGf2W1PHV/FBKWoGPCq3tTSHeCdI8YHNSU=; b=HJ4yMHewQXjuw680xaWwAsA24xsPxXxeOZ8wmkWJVoJXdQ4eEHXci6ai ZjAhw6j2OIkQxthSe5PPRvNNmAltd2KO7aCoa3GyhQtLUWCps/LszcL3t +EgViCxfDiWAk0pRW8pvlyTyqSTlVUZaa31bG35TbN6gjoT8sd/ewtJ2L D/ZhjqniAUhvTgYLQVnu62m7slJXuLLd/GuvtnBbZchgTLttUv39mNHVb gtKFcdRUhJRuQ+P8DOZTzf/UfV5nooAxMw69F+ji1dpI6DU4m4IbVk9BE yU04TjsCs12hubdZLhXZ5KoZipGpeQx8bailT8siOvtAxRNzHWpgi0mCy Q==; X-CSE-ConnectionGUID: ATmBgQN4Q7i0WDqMIDQTbg== X-CSE-MsgGUID: 9XtS2wy6SVGwLCj9QXG2Dg== X-IronPort-AV: E=McAfee;i="6800,10657,11912"; a="116042568" X-IronPort-AV: E=Sophos;i="6.27,114,1787036400"; d="scan'208";a="116042568" X-CSE-ConnectionGUID: kjkLvVcGQfSuVkimgMKulQ== X-CSE-MsgGUID: q9iUGYRaTnOT4JEfU+z5Iw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,114,1787036400"; d="scan'208";a="298923086" Message-ID: <466d03e5725bdda886a53b395e102c121e110c1d.camel@linux.intel.com> Subject: Re: [PATCH v2] drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Szymon =?UTF-8?Q?Aceda=C5=84ski?= , intel-xe@lists.freedesktop.org Cc: matthew.brost@intel.com, rodrigo.vivi@intel.com, maarten.lankhorst@linux.intel.com, hch@lst.de, bob.beckett@collabora.com, dri-devel@lists.freedesktop.org, marmarek@invisiblethingslab.com, xen-devel@lists.xenproject.org, stable@vger.kernel.org Date: Mon, 21 Sep 2026 16:30:01 +0200 In-Reply-To: <49da6f28a4ba582d32ac6cdccd6dea65d75eefbf.camel@linux.intel.com> References: <20260916173030.3223833-1-accek@invisiblethingslab.com> <49da6f28a4ba582d32ac6cdccd6dea65d75eefbf.camel@linux.intel.com> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) MIME-Version: 1.0 X-purgate-ID: tlsNG-bad1c0/1790001009-BF2DC034-6AA6D7C7/0/0 X-purgate-type: clean X-purgate-size: 3329 On Mon, 2026-09-21 at 15:57 +0200, Thomas Hellstr=C3=B6m wrote: > On Wed, 2026-09-16 at 19:30 +0200, Szymon Aceda=C5=84ski wrote: > > Fix display corruption on Xen PV dom0, where DMA buffers are not > > guaranteed machine-contiguous, in which case bounce buffering kicks > > in, breaking xe's memory coherency assumptions. > >=20 > > Apply the same workaround i915 carries in i915_sg_segment_size() > > since > > commit 78a07fe777c4 ("drm/i915: stop abusing swiotlb_max_segment"). > >=20 > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel > > GPUs") > > Reported-by: Marek Marczykowski-G=C3=B3recki > > > > Closes: > > https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8382 > > Link: https://lore.kernel.org/xen-devel/aYtznP_tT6xNPwf-@mail-itl/ > > Link: > > https://lore.kernel.org/all/20221020110308.1582518-1-hch@lst.de/=C2=A0# > > i915 counterpart > > Cc: Christoph Hellwig > > Cc: Robert Beckett > > Cc: stable@vger.kernel.org=C2=A0# v6.8+ > > Signed-off-by: Szymon Aceda=C5=84ski > > --- > > v2: > > =C2=A0- Imperative language in the commit message (Thomas Hellstr=C3=B6= m) > > =C2=A0- CC the authors of the original i915 workaround (Thomas > > Hellstr=C3=B6m) >=20 > Reviewed-by: Thomas Hellstr=C3=B6m Pushed to drm-xe-next. Thanks. /Thomas >=20 >=20 > >=20 > > =C2=A0drivers/gpu/drm/xe/xe_bo.h | 19 +++++++++++++++++++ > > =C2=A01 file changed, 19 insertions(+) > >=20 > > diff --git a/drivers/gpu/drm/xe/xe_bo.h > > b/drivers/gpu/drm/xe/xe_bo.h > > index 290ca62..341fa93 100644 > > --- a/drivers/gpu/drm/xe/xe_bo.h > > +++ b/drivers/gpu/drm/xe/xe_bo.h > > @@ -9,6 +9,8 @@ > > =C2=A0#include > > =C2=A0#include > > =C2=A0 > > +#include > > + > > =C2=A0#include "xe_bo_types.h" > > =C2=A0#include "xe_ggtt.h" > > =C2=A0#include "xe_macros.h" > > @@ -574,6 +576,23 @@ static inline unsigned int > > xe_sg_segment_size(struct device *dev) > > =C2=A0 struct scatterlist __maybe_unused sg; > > =C2=A0 size_t max =3D BIT_ULL(sizeof(sg.length) * 8) - 1; > > =C2=A0 > > + /* > > + * For Xen PV guests pages aren't contiguous in DMA > > (machine) address > > + * space.=C2=A0 The DMA API takes care of that both in > > dma_alloc_* (by > > + * calling into the hypervisor to make the pages > > contiguous) > > and in > > + * dma_map_* (by bounce buffering).=C2=A0 But xe (like i915, > > see > > commit > > + * 78a07fe777c4) ignores the coherency aspects of the DMA > > API and thus > > + * can't cope with bounce buffering actually happening, so > > add a hack > > + * here to force small allocations and mappings when > > running > > in PV > > + * mode on Xen. > > + * > > + * Note this will still break if bounce buffering is > > required for other > > + * reasons, like confidential computing hypervisors or > > PCIe > > root ports > > + * with addressing limitations. > > + */ > > + if (xen_pv_domain()) > > + return PAGE_SIZE; > > + > > =C2=A0 max =3D min_t(size_t, max, dma_max_mapping_size(dev)); > > =C2=A0 > > =C2=A0 /* > >=20 > > base-commit: baafc300cd079a5210c1e70e5ea3d93518e40b38 From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:35:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:35:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427617.1650416 (Exim 4.92) (envelope-from ) id 1x8f77-0000uM-0e; Mon, 21 Sep 2026 14:35:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427617.1650416; Mon, 21 Sep 2026 14:35:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8f76-0000uF-U8; Mon, 21 Sep 2026 14:35:24 +0000 Received: by outflank-mailman (input) for mailman id 1427617; Mon, 21 Sep 2026 14:35:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8f75-0000u9-2C for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:35:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8f72-001Wx0-FB for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:35:20 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1409c-2eae-0a2a0a5409dd-0a2a450cc2ea-26 for ; Mon, 21 Sep 2026 16:35:20 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab140a7-f479-0a2a450c0019-4a7de14cad5b-3 for ; Mon, 21 Sep 2026 16:35:19 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485ac898fa4so2683903f8f.0 for ; Mon, 21 Sep 2026 07:35:19 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48724589c02sm22699876f8f.24.2026.09.21.07.35.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 07:35:18 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790001319; x=1790606119; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zKWmacSRjEOWwCwtTdSF25dMhGAD5KW/oGGRtVIBG5I=; b=OXKLfgMSEvaRGdH6J46tlV0kJTNe2lc1FN++h9jQWIDqQEvk4gjPnIo6n78OAXIUWT jVfddJtZhkzAd+Q9Ka/Td81LCCqxb+I+b0t6zFbnmQ1IUPF/vs5cZB+NisrGbmkNbSUG YzHiW6SDP4PS+4ynKsiL2UWAF7poNVGodZVLeTFXGF7zmXcnD/JysbF6T3LQPSTjpbfF xOSVvYB3Q4Ojq/JFWCru/NgtMkVc1+RWT5gC0pbh5+Fg1sZMKIVGfo/6uDwRGGnp95a7 a44y/hd81eMWh/f9VfCqX76bXzxE8wsjq4jwvVJ4k08P1/7IDyFJdgXo2Ej+5cn3vPtO PeEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790001319; x=1790606119; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=zKWmacSRjEOWwCwtTdSF25dMhGAD5KW/oGGRtVIBG5I=; b=a/kI67TLFgCl36pve/Fb5u/k0O+fz2ejAIIr/qjG1VnxdDuSqzocbCvbUmsm8Xkywy KqrVzHrWmdcQ5xDH3QapkIoPfy72eHYpwh84ZhnPtV8HOMNq0RzRDNFPQQI892oglaw7 zejfcP/WpkxXvtk78rDPS4f5GtFsolC2F2LuifGHZit8uBM0eAU4bRsSyta/xOvHlEnU 3mAuxH5Yqu3JVQ1teutZAiye6EfqdgEjnVedv2ZyvEDbjptjb84hVAsjldH6gKeiQScM RDA6Q/ILRRdb+F8PSepmJaW6olcmcdp3GegBPdEFC2AmwfnaTSHSEHyW9Uu3u6jVF1LU pEPA== X-Forwarded-Encrypted: i=1; AKwUvByFRgeiJl3Fk1qyE/fQNv2bdHTsTKCTgWifdhZIpLKhaA9+r5eGHz9geLzXi4hfs2yLDKG/+W54Z0I=@lists.xenproject.org X-Gm-Message-State: AFuF++mYqi3ECN84mvyW8F748EMv+lkf/xai4oJTazvXei5Q2ztyrNpu WCif/l3AAeb5ba1TNBiVngA2itI0llmLb1RKcrwhwwRmD9ERp4fPLlW5 X-Gm-Gg: AYBFou2J0eegqGA0ILi4IF3gvHJNq4ET6URuDOsGTGUQ4vfyLCL1FbDoBeWtsDK6IDb kFEjqzOkPVTG7AH1DWGeQwNjUCPi/pRKR8/ZvKd/yFvSp7xvsd0+9QOKtcNg/QYFuOZz2S+9Wq3 H+VFsMtGwxTqYRuDMguwM4o0kWPlTA36IIKsct5T+9Ar+PkCnGHDtAGwGKIIiDOFwDohcSag2P0 FBAAM2VlmrCIxStX6lpINEaXGeLq7udLzrEASBATyRvntpA+ibG35FbT1GAyHRW5H1lZwSKQt4R r9SFdG3HLI2it7Vui+nAT64KS9UOYkcmPTkcJ4tWdjWB3FIltaPprj2rM8H+Q53N1TkUtP34WPU P8XTAtiXjXXKPYwPpThLYyWA9HzsaSk+0Uj2f35O8JbTupMI/dLi/kiyeFIQHqm4d5bWafEovve 3Ka4++JeLJ9/GMfd/r63pxzj3NrEiQ7BgaEynQu5dtq/VmKQMXg192hnHKBFujUARFNQnsIw7Al htsc8TJ8+sxhheyj1+O5YOuamt9xVDgUiZUwSlew6qK3ZJ9GQ== X-Received: by 2002:a05:6000:220e:b0:487:9a8:9f31 with SMTP id ffacd0b85a97d-4871e368258mr16602561f8f.41.1790001319199; Mon, 21 Sep 2026 07:35:19 -0700 (PDT) Message-ID: <4c3a1826-fb74-4907-add5-4e06d6094995@gmail.com> Date: Mon, 21 Sep 2026 16:35:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 37/39] xen/riscv: map IMSIC interrupt file for vCPUs To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790001319-034D7A5B-BAF1555C/10/73395122804 X-purgate-type: spam X-purgate-size: 3850 On 9/21/26 1:36 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> A guest running in VS-mode expects its own IMSIC S-file at offset 0 of its >> guest-physical IMSIC block. Physically, the guest-file (G-file) assigned to >> this vCPU lives at a hart-relative offset given by guest_file_id (assigned >> via the vGEIN allocator). Therefore, imsic_map_guest_file() uses stage-2 >> translation to redirect the guest's fixed per-vCPU GPA page (offset 0) to >> the specific physical guest-file page. >> >> Signed-off-by: Oleksii Kurochko > > Acked-by: Jan Beulich Thanks. > perhaps with ... > >> @@ -537,9 +538,72 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v) >> read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >> } >> >> +/* >> + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU >> + * into the domain's stage-2 guest-physical address space. >> + * >> + * In the machine's physical address space (SPA), each hart's IMSIC >> + * supervisor-level file (S-file) is located at offset 0 of its address block, >> + * followed contiguously by GEILEN guest files at offsets of 1, 2, ..., N pages. >> + * >> + * Because a guest OS running in VS-mode expects its own supervisor-level >> + * interrupt file to be at offset 0 of its guest-physical IMSIC block, the >> + * hypervisor must use stage-2 address translation to map the vCPU's >> + * guest-physical "supervisor" page (GPA offset 0) to the specific >> + * physical guest file page (SPA offset guest_file_id) on the physical hart. >> + * >> + * A vCPU runs on the pCPU the scheduler picked for it (v->processor), and >> + * the guest file it is given (guest_file_id, from the vGEIN allocator) >> + * belongs to that very pCPU's IMSIC. A guest_file_id of 0 indicates that no >> + * hardware guest file is selected (matching the architectural behavior where >> + * vGEIN = 0 in the hstatus CSR selects no guest external interrupt source), >> + * requiring the VS-file to be emulated in software. >> + * >> + * Consequently the mapping installed here is only valid as long as the vCPU >> + * stays on that pCPU. When it migrates, a VS-file is acquired on the new >> + * pCPU and mapped at the very same GFN, so the stale mapping needs no >> + * explicit tear-down: it is simply replaced. >> + * >> + * The base guest-physical address advertised to the guest in the device >> + * tree matches offset 0 of the vCPU's virtual IMSIC block. Stage-2 >> + * translation ensures that guest supervisor accesses to this page are >> + * transparently routed to the real hardware VS-file granted to it on >> + * the pCPU it currently runs on. >> + */ >> int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) >> { >> - return -EOPNOTSUPP; >> + struct domain *d = v->domain; >> + unsigned int cpu = v->processor; >> + paddr_t gaddr = GUEST_IMSIC_S_BASE + (IMSIC_MMIO_PAGE_SZ * v->vcpu_id); >> + paddr_t paddr, guest_offset; >> + int res; >> + >> + /* Nothing to map in the case of sw interrupt file. */ >> + if ( !vsfile_id ) >> + return 0; >> + >> + guest_offset = vsfile_id * IMSIC_MMIO_PAGE_SZ; >> + >> + paddr = imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset + >> + guest_offset; >> + >> +#ifdef IMSIC_DEBUG >> + printk(XENLOG_DEBUG >> + "%s: %pv: ga(%#"PRIpaddr") -> pa(%#"PRIpaddr"), cpu(%u), " >> + "guest_file_id(%u) base_addr(%#"PRIpaddr") offset(%#lx)\n", >> + __func__, v, gaddr, paddr, cpu, vsfile_id, >> + imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset); > > ... this also converted to dprintk(), or at least using XENLOG_G_DEBUG. I will convert to dprintk(). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:37:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:37:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427623.1650425 (Exim 4.92) (envelope-from ) id 1x8f9H-0001R6-CW; Mon, 21 Sep 2026 14:37:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427623.1650425; Mon, 21 Sep 2026 14:37:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8f9H-0001Qz-9j; Mon, 21 Sep 2026 14:37:39 +0000 Received: by outflank-mailman (input) for mailman id 1427623; Mon, 21 Sep 2026 14:37:37 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8f9F-0001PY-NM for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:37:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8f9F-004rkC-3z for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:37:37 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1412c-8faa-0a2a0a5109dd-0a2a450887d4-10 for ; Mon, 21 Sep 2026 16:37:36 +0200 Received: from [52.101.201.10] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1412e-f659-0a2a45080019-3465c90a5e1b-3 for ; Mon, 21 Sep 2026 16:37:36 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by PH8PR12MB6843.namprd12.prod.outlook.com (2603:10b6:510:1ca::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 14:37:30 +0000 Received: from BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740]) by BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740%3]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 14:37:30 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mU7hCQUFQHGI9+Hznpo8mcP0qeOouANLFT2YBxTaz/+5ex0txAjm7ipqv/D55r6jq8WsjkjI2A0OX1adk4yVegi8/1tcYPaJttItMJgTHdIymcgxpiTV94Srj8eqYW+eOFK3U5WUIm7jlXevL2CQzdmhRbEv1w2nkvwwuitigoKyXgK9gq0xP2wbWMNrdzQejj9xhHeNPZHD2qqpizfjQlfUKYGPOlY1F5wfJiSAPhQ9UKadcEcjwoePyAQjZ2OqbIiF4iW3uRA2m/gGTCU+u6+3k9XGZi4WrdxwOUlIPsnugu/Yuj6ECa6T+g2uej6lcPyMLw1sp6vMGWBM+L2/Ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2NcxDG8WB5e1spVO79Dkhf7xcitYgWM44esyJgxgGC0=; b=HOzCK+fBJR5Ocu+NTpJXIIaIarkBsAguMATFZkmxVQupf4iccdHikgo7Em6d7Bp7XD6Mwsjjnt6VVTGARjfLv8hYYDxYB+b1A+dtht0dyYjlVAVdhBPB7qDyOHzd28NWVGnqCNjMC7v14EyVCKPB/AYrM4iTTYfLH4kR6zioN/C33Y3fMkoiZTSl7qbo4fcrmTMznH58RrObZKTdJSlCz9M0vzH18FrO42nd7kDmJFShAKNy9+Cw5TJrv5lB2DcHKKrZQrGFoLU7UjtGobP6+/JhOI4KUTWhJD19vycavkZ3+5WW4jUvKkzuM8dlPBBrbQ3r2hv1gq60ZPmsWH/RyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2NcxDG8WB5e1spVO79Dkhf7xcitYgWM44esyJgxgGC0=; b=W96XRGlJhVUxhb/XN6fyhTVmA49Gq4v984iiMbDdG5vk3lx1dLadeyvru31oL/SgDNnhALrQtgCrEdcek5J2W68LLG0QjnwRuNiQL6pzEpJnCLnC2/QjSN+8dc6/sx9xQNqzYignrCU8rht/AGCjMCrN+i4lGgTf8u0BqfobnUc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 21 Sep 2026 16:37:26 +0200 Message-Id: From: "Alejandro Vallejo" To: "Baptiste Le Duc" , Cc: "Doug Goldstein" , "Stefano Stabellini" Subject: Re: [PATCH v2 6/6] CI: run the riscv64 smoke test via QTB framework console-test X-Mailer: aerc 0.17.0 References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@vates.tech> In-Reply-To: <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@vates.tech> X-ClientProxiedBy: MA3P292CA0073.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::13) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|PH8PR12MB6843:EE_ X-MS-Office365-Filtering-Correlation-Id: 092276e9-cb9f-4e0c-67af-08df17edddcc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|11063799006|56012099006|4143699003|10067099003|3023799007|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: N1NeMrH6kF+FqB5sW5NcvMZQeGDosa1GGpNNSLzbYL8Unq8xiYi315/aE3YrZgBi+P0Czck7g62m1qFxW6U8IePqjUjOhWuM0hmCvdJeRY3oj02p0aF15XbvGxcupR81KVNLB1QUfKWau+WsHzkxTkyX2/MEDQ0xj4RCt4uAksHxqlCK8CSzdod0WkOH26Yoewv8qA58nApErAAvWyGNt1Wr7nx+fTCVis2FyQqUiFu8PggnQ5gflGYQJFzykwV04VnZYD/vV6JpoyB5hpbPs88C2z0ITEpbyFhkxpSdCgcojhqsQr4NiZ6CYuXPgEzkk1TbXQWxMXNiF3LT92IQoegYDERExypEyuI5smA0p0rqKwl1BwWXKNymUX/lqxWIDts4WVlpd5GV9f/CB0TpGrubkiWQln4bWc2gNXY8gZY9uLDbTrka3k3U6j9siGKMfH2hsyqF3YUe6dpTOAzzxgwo8AyHeYOUkOT43fc6XdzidDOfiR38Atkw+1gnEM/IOl3YFZ8wEDhDVXmZLyHANR7PTY2UL3MBRThLPXQyv/29g+t7FUXpLotYrDfbvvevI5ZK8d5KXVxhcyDClzyWE26dFC/yT7hqiU+BiINFkeE8/vSu759IxHJOSsbMYidi X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB4999.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(11063799006)(56012099006)(4143699003)(10067099003)(3023799007)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WXJWeTR6WkVpY1cxSDY3SVAxdVJHbnVaRW9jOVZmQnVIZUFtYXI2dDlnTEQy?= =?utf-8?B?Y1BnaTdxc2xIRWRUS0srdDRQS3lLZ1dVcmxrYkhiSjNiNEJucTEvQkN0OXB0?= =?utf-8?B?c2NsajhPNGUyUk5uaVZ0T1poOUJHRWc1aGRpaWN0MFVWU2Z0TzczRXdydkky?= =?utf-8?B?UVBIcDJnb3dCdXVQOFBYOWw5cXJlbVJyZllOcjMyY2tPWHBORzlsSUdiVnJ3?= =?utf-8?B?SlNxQVdIUUxlcHYvUlhxVURlaGlWTTZZR0JXTVlXbmRIYVMyQzRvSUtWaUxo?= =?utf-8?B?dmRQc29RYzRnUGJvNjdzakYwRS91RG4vaTJZeWVJeVorclFnVXF6alI0Vzho?= =?utf-8?B?Mk9IdTlvSXlpejZjc0ZhK01MVnpoaUR4MDRjQkg1WElqQ3l1OCtPdDRCRms5?= =?utf-8?B?WG9PSVJLUFNic3VBLzlmbCsyalpXdHByc2o3RTVNSHlmYW8zclVQdG8yVXBs?= =?utf-8?B?WXFRd1RqWGZjSjdIUWZpRk1hSVRsSlVFeWtrYkR3ZGUwQWZ6ZG5tU0xXSGtK?= =?utf-8?B?Q09CMHNmdTFYUHhTenJrZkxJY3N3anJ1dnNvb205eE9QSk1uUVJMQWNLa1px?= =?utf-8?B?N1U5emdXczNMNDhkM2pvVS83L0FQYnVCczV6VzU0NUhtNTdZMGxXcy8yT1ZR?= =?utf-8?B?WHVGZWUySzRjS0FtSHJRZG1GYnVaYWFlMTUwU2FKU216RzY5ZU5ZbExDU1B3?= =?utf-8?B?bnUvU0cwVGNFSWhWWGdoU0pRSE1ia0xBNTVOcVZtcXYvMStnZjdEYm5SeThV?= =?utf-8?B?ZWkycUJUM2UwdUFCaFJPSEUxU1R4OGV2Nk81ZEdxU051UHlmcFlUYzUxTUlL?= =?utf-8?B?Z0RNWWpBejJadWk5b1BxMHovK24zbGRvMjVrZk5jVzIvUmxiOEMzMVpWcTVs?= =?utf-8?B?blBDMTZWa0g4WlFqdGVCL1lyT2F6QXJjb2d0aTBvK05kRmxnMlBLaUNlQlJW?= =?utf-8?B?dzV5UW5MS3RaZGs2VGRNTHJNN1VxK2pXNnZYbzJGcUNqa1ZwaGpBQmRIR20w?= =?utf-8?B?TkZhclRMZ2N3V1lIYWE1M2VXdkFFaDg5SkZsNlJNaTBtMEU4U1orWEZ3MHFV?= =?utf-8?B?SWdPczlma1FnT2F5M2EwUEZOUmN3RUpXL0VUMy9ZckVEdlU3VWpOYWJKRk5w?= =?utf-8?B?SjVLbzFlQkcyeXFuQ2UvczQ3UFVRZUV5Q0RjNVZoWTR6Y3JyaWJmWldKMm84?= =?utf-8?B?b0FXeCtzeFJRcmxlTEI5MGdFWHRPdFRTc0VLUG5TZVkxQ0gxaWlHMkhBUG9t?= =?utf-8?B?blErditJTjNtMFQxNzNNNkpJT3RBbEZpYTJMQVBCVVFnbHMvRktVdkZPS0lQ?= =?utf-8?B?SUVNSWVNK0xwcmZmNDBTc3hMUHdJamhQenk5RThGWGFNdHdKMHZsMWZsN2FN?= =?utf-8?B?bTZJb3NCUy9aSG8vZmJuc1RPTGJYN3RQMjIxOFQ3RFJmQjhHT2hnUE1jMjFR?= =?utf-8?B?eEJpbVZnc25FWmJMWDhPZEJkVEtrYU1DS3JZY215SG1VTUlUZUlOTk05dDRl?= =?utf-8?B?aHM2UTlaRjRyUHJYdEhoWnRoWTkyZWdvTjFzVlBRWmFudXN4NHBreXU5eUxM?= =?utf-8?B?M1UrNWFjdVBuamlCdUJiV3kwZHhndW94ZzZ6NzZuQUhRZnBFS1J5N0ZMcVVE?= =?utf-8?B?dXNCMzdnODNQRlR0VVFjWHYzMGxyaDNWYzVaWG5PRnJ1cEtzdXNWbktEQjkz?= =?utf-8?B?U1Vkb2xCSWdQMWtHc0xsbWdHQzhsWnhHOUZ2a3poRFhRek15UDRPNFFpS24z?= =?utf-8?B?d1lqUHVMelo0VXowZlM5OEtEN0RDTFowWitqbW1HMXlWSUJabnF4bTVnZW9x?= =?utf-8?B?MytTWWlLSVg4d3QzQ1B4TjZLNGU3VnE5L1ZGZnZHUis0VjJpb2tScmgxNGx4?= =?utf-8?B?ZXZHelNvYXRlZEIwSXA2R2lUYW9mL1I1dWhxQ01kcDRTaWIzRzVKY05NUE5V?= =?utf-8?B?R1hmbFpaelZnUzBSV20xMjNyUEloNnlPWThSdkd5b0YvOEZVREdKWHh4a0p2?= =?utf-8?B?QkVMcGRWeURvVmVPSkExM1Y5TlJCY3FwSXl2dWFSRnI3NHVRN3JONjRqVXBo?= =?utf-8?B?N1U0WU0vSDhhMG5mWnUzMUlKZUIwM284WmpmZGtzVVFTQTJGMHNPL0FHbUtp?= =?utf-8?B?TFE3Yms2S2cvZ0s2YzNZZG83bUVjZ2hXdk1yRzQybUora1FuSXpUdnR0azlt?= =?utf-8?B?dllpM2dmTmlxZjBBOTFMK05RaW1FQlBzUzFESURhV3QrcUgyTFdpVy8vblBj?= =?utf-8?B?NXR6bmhYWkgvYjFZTjBIcmpNRVdXelNiOWJvbWdpMGk5L2ZUVVZ0aFRud3F0?= =?utf-8?Q?GqdBqwfnNm1CvDVQ7i?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 092276e9-cb9f-4e0c-67af-08df17edddcc X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 14:37:30.6472 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ZdVDumclfXJ1WH17SQuP8S3mrxvCrMq1Zp8MgA2BD+qMXAllj8ahzDuAxxdFTYYPeTEQJY0CTt0kud+3uSSzLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6843 X-purgate-ID: tlsNG-c1860d/1790001456-D574B87B-E0C64BC2/0/0 X-purgate-type: clean X-purgate-size: 5089 On Thu Aug 27, 2026 at 11:42 AM CEST, Baptiste Le Duc wrote: > qemu-smoke-riscv64-gcc drove QEMU through > automation/scripts/qemu-smoke-riscv64.sh, an expect wrapper whose machine > description (cpus, memory, device tree, console wiring) lived in the scri= pt > itself. The QTB framework now owns all of that: machines come from the > shared catalog, expectations from the test type's own YAML. > > Turn .qemu-riscv64 into a template running qemu_smoke_riscv64.py r= un > in the qtb-riscv64 container, machine and test picked per job > through QTB_TEST_TYPE/QTB_TEST. The container comes from the test-artifac= ts > registry, hence the new ARTIFACTS_REGISTRY next to the existing > ARTIFACTS_REPO/ARTIFACTS_BRANCH. QTB_BINARIES_DIR points at the artifacts > of the job (Xen only currently, but aims to have initrd and linux images > when dom0less will be supported). QTB_LOG_DIR collects the per-console > logs, kept on failure and on success. > > Point qemu-smoke-riscv64-gcc at that template, running the console-test > type on dom0less-1smp-0domu-1vcpu-aplic-imsic-null: a Xen-only machine, s= o > the smoke check is Xen's own "All set up" on console 0, the same string t= he > expect script waited for. > > Drop automation/scripts/qemu-smoke-riscv64.sh as it has no caller left in > the CI after this patch and drop smoke.serial from the .qemu-riscv64 > artifacts since no riscv64 job uses it anymore, the logs are now kept und= er > QTB_LOG_DIR. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc This is all quite large and monolithic to review quickly, but I can already tell you that replacing a <50LoC test with such a massive infra bench is probably not quite what you want at this point in time. IMO, you ought to keep the existing test in place and perhaps integrate the new infra with new tests that would be complicated without it. Things like injecting bizarre interrupts (NMI?) and capture expected behaviour. Or even duplicating the existing test would be fine. Build confidence in it and only after you really trust it do remove your previous smoke. My .05 cents at least. Cheers, Alejandro > --- > .gitlab-ci.yml | 3 +++ > automation/gitlab-ci/test.yaml | 20 ++++++++++++++------ > automation/scripts/qemu-smoke-riscv64.sh | 19 ------------------- > 3 files changed, 17 insertions(+), 25 deletions(-) > delete mode 100755 automation/scripts/qemu-smoke-riscv64.sh > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index f42a9abeaa..15f93b8634 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -11,6 +11,9 @@ variables: > ARTIFACTS_BRANCH: > description: "Branch in test-artifacts to use" > value: master > + ARTIFACTS_REGISTRY: > + description: "Registry holding the test-artifacts containers" > + value: registry.gitlab.com/xen-project/hardware/test-artifacts > LINUX_JOB_X86_64: > description: "Job name in test-artifacts to use for Linux x86_64" > value: linux-6.6.56-x86_64 > diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.y= aml > index 61adc1baff..e9dd147380 100644 > --- a/automation/gitlab-ci/test.yaml > +++ b/automation/gitlab-ci/test.yaml > @@ -72,14 +72,21 @@ > TEST_TIMEOUT_OVERRIDE: 120 > =20 > .qemu-riscv64: > + image: ${ARTIFACTS_REGISTRY}/${CONTAINER} > extends: .test-jobs-common > variables: > - CONTAINER: debian:13-riscv64 > - LOGFILE: qemu-smoke-riscv64.log > + CONTAINER: debian:13-qtb-riscv64 > + QTB_LOG_DIR: qtb-logs > + QTB_BINARIES_DIR: ${CI_PROJECT_DIR}/binaries > + script: > + - ./automation/scripts/qemu_smoke_riscv64.py > + ${QTB_TEST_TYPE} > + run > + ${QTB_TEST} > + --log-dir ${QTB_LOG_DIR} > artifacts: > paths: > - - smoke.serial > - - '*.log' > + - ${QTB_LOG_DIR} > when: always > tags: > - x86_64 > @@ -779,8 +786,9 @@ qemu-xtf-argo-x86_64-gcc-debug: > =20 > qemu-smoke-riscv64-gcc: > extends: .qemu-riscv64 > - script: > - - ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee ${LOGFILE} > + variables: > + QTB_TEST_TYPE: console-test > + QTB_TEST: dom0less-1smp-0domu-1vcpu-aplic-imsic-null > needs: > - debian-13-riscv64-gcc-debug > =20 > diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/script= s/qemu-smoke-riscv64.sh > deleted file mode 100755 > index c0b1082a08..0000000000 > --- a/automation/scripts/qemu-smoke-riscv64.sh > +++ /dev/null > @@ -1,19 +0,0 @@ > -#!/bin/bash > - > -set -ex -o pipefail > - > -# Run the test > -rm -f smoke.serial > - > -export TEST_CMD=3D"qemu-system-riscv64 \ > - -M virt,aia=3Daplic-imsic \ > - -cpu rv64,svpbmt=3Don \ > - -smp 1 \ > - -nographic \ > - -m 2g \ > - -kernel binaries/xen" > - > -export TEST_LOG=3D"smoke.serial" > -export PASSED=3D"All set up" > - > -./automation/scripts/console.exp |& sed 's/\r\+$//' From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:39:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:39:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427630.1650434 (Exim 4.92) (envelope-from ) id 1x8fBK-0002Aw-Qf; Mon, 21 Sep 2026 14:39:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427630.1650434; Mon, 21 Sep 2026 14:39:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fBK-0002Ap-Ny; Mon, 21 Sep 2026 14:39:46 +0000 Received: by outflank-mailman (input) for mailman id 1427630; Mon, 21 Sep 2026 14:39:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fBJ-0002Aj-Hh for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:39:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8fBI-007Gq4-Kc for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:39:44 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab14194-8faa-0a2a0a5109dd-0a2a4503c794-42 for ; Mon, 21 Sep 2026 16:39:44 +0200 Received: from [52.101.193.31] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab141ae-fae8-0a2a45030019-3465c11fdc83-3 for ; Mon, 21 Sep 2026 16:39:44 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by PH8PR12MB999321.namprd12.prod.outlook.com (2603:10b6:510:40e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 14:39:39 +0000 Received: from BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740]) by BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740%3]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 14:39:39 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QzIUuNkzN6szTu6xsloIIGC3F71I9Q02XGfCxFrt4Htza4h4UoV/T20NOVfkUHKcEcP6QiEWqHjR89DInEjgI3ryqbhHZLTANQQAJnSNNBVKZYDOyqCC8UJ80cNDndhEEbWCK4ApJNzxpUiJquMoB+MS6bjB18ikDlAdPzu19BKPw06lWVcM7DWcr4PV8Rf1rndmXpKRBr7RaIrePct27AxrOvdeLI78LVA2X9r5lYYgzhQV+EXbYwGFaic4OWMpbPVJFIFxLafB+RlNbqC8UsT7EvhjAK8Fr6UajwbbUGdizgyiydzQYAVHMn/fv1XUiRb4bwRml8fvUYlbnjZeOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gT+t27osKtV55UohSlWhFHu4gLqd2cAfltY7uhyf/fw=; b=tjGzHhZeC8e9K2qcU6ShGKCB+IVAT7vr9lL8xuH+hwaS072GzA5uKOKMUpJpLIaUO7iMd7r4PEoDRtudUiOvbfHnodvR1JEDawWZlI+GBEtScs+cnSUuJ/6gaJGwukOJAe2ladCIsF7hMsRTkXvU9R805sY7j9tF3iaEWBUCu4ViittTkcDA4wv3vnZqlRrwF6xCNw0FU9N6z33uD5Xte+4jZ0wZ46MGFmikzK1vS6C1GLjrekxsxo2mStB1azOthBHmsMw0QMThjrLzi4I5asX10WvojZ3/tQ2lQ7PaO/vTzC5wRqZUzWEJueuS5lkyEyrzzkLpc2YjdGEiXWiWMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gT+t27osKtV55UohSlWhFHu4gLqd2cAfltY7uhyf/fw=; b=094Dn2BRDVxs24ightV3ES18sZwLzQ9T/Tgl+r5v+kIY5xlOylV2iNH1SydHW98gJzyoaTW3LdXJ0qBpbA4ifebRoZLba8B/kC1Cr10DvWNkf7Zy3mglLTkU1rS8C7GXpOPhySxaiIxkp8MJyTfDifuWaMe8+tKHZyzKVkMe7ZQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 21 Sep 2026 16:39:35 +0200 Message-Id: Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , "Doug Goldstein" Subject: Re: [PATCH v2 0/6] automation: add QTB test framework for riscv64 smoke tests From: "Alejandro Vallejo" To: "Baptiste Le Duc" , , X-Mailer: aerc 0.17.0 References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> In-Reply-To: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> X-ClientProxiedBy: MA3P292CA0009.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::10) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|PH8PR12MB999321:EE_ X-MS-Office365-Filtering-Correlation-Id: 710700f0-7081-4f8a-f6fe-08df17ee2aa0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016|23010399003|56012099006|10067099003|11063799006|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: Ia4g8aZToaIkBe4ZNyM0dYAXTvpL9mBdj0pkVnWorZCOLUMVvdAwfaNy+T91v7xMEUKmiTVFJ2JbiflNtHZnwUUmyUe5aFBy+pifsdcka4uGjf3k21zQtVYYhjdhe1Ep8pmkLRcmeytxURhtu1l+YizQPzbC2ue92X50yirN/Lokv5MRciSAdQnLd3w4dB2Y6bNBkQlZwyO/neZOF78zrJtocXP4lC9rV1fG6Wmz+N+NiV0/eCVNRDOJ5CpELdoObZq75L/8jX+d0OeZAS3/Os5Z34UHQXBmgPNNVoNCZVL7Lnwy+jE9m5M/UCh2saAGdG0DD5FjP8wBGhtoT0BG8eG8aH2fVuQtnZGH56aIx7+DVpcVCV8uR/OQd2qWGiLGYNqfn3sX3cl/RY92eRx1+WQD50c8iTqT9+PVCYaw/sEhMVsYMURsAEDqNiX/qQpe2jA9db8b1Ljl7ggxxUJu+VqrWMIXiMpn8bBCtDe1WnYR3P5XTKE8a4kV4+k3v0HeJwvdQp6xBRaA50vzIpaT6EFh5o01lF40D01v7ctgUu1xVoeGUOT4Mxw281Cu5ZRATizswMuxtqVQY2lrCd5c+n5t0ACxUAVWGFPzm03gJpHynKeM6aA60Vo43TMWJiRI X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB4999.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(23010399003)(56012099006)(10067099003)(11063799006)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Snl3VFcwNjcrVUw4K1Ywd3VOVFJqWitGc1QrR3VyVXJKdndvYVpkalpxTGFQ?= =?utf-8?B?WnNRRHR6aW1JYWw2cFZ2bzFFbXgxVTM5dFNiT0cyUDRmdEFadDhlekxTL1N2?= =?utf-8?B?cDYybkNKb3U2Z3FxVWErSGpCUFZxSlZ0UTN1T0xzRTFMRFJqc0NBYjA4NTF3?= =?utf-8?B?dlVxcjY3aVVmdGdQZHhPcU0yeXFVV0YxYWZXejg4L0IzNDBtb25aUVI3bzd0?= =?utf-8?B?aGxJK3lBaUxLRVVsZnppUjB2eDUwbUZ4VjNZTDV2ZTNjK0Z5L21ydm5ZQWpv?= =?utf-8?B?c3pEUFdsbHJJdEpEVk5UcWMwRExGblN6VXdEVEVuVHBGMVZsZ1p0UzVTVGRE?= =?utf-8?B?dGJaZnkyRTZwUDFYM2RUc0ErZHJSbmhHbTZkL3UzdnI1MzI1emh5S1IvcmRO?= =?utf-8?B?VjRqWm1qazdONXlkSjAvMmtab0dwZWZFMVlCOG5LM1piNkJGTE00R2JBTHBy?= =?utf-8?B?eFlnbWxGU0w2ME5oV0hsaGVQcWE1anVydWdETDhUdU43RzFVUWllVXJrb3lS?= =?utf-8?B?SDRTcUxwRStDa2ROSmFxV1Z1TThIeEpkclNpMHhIR2F5a1diWXBZdW54Qmgr?= =?utf-8?B?bFc2ajRpaFM4MWtzMVNQT0R3VGVQZEx4VmdYNVh5NWxIbTNBNDZ2R3ZyZk1v?= =?utf-8?B?Y0t0ZE50dVppYXZTQThTNkpiTVpiZ01IK01sVVFzQ0UzNWVRckxCRHQrN3k0?= =?utf-8?B?a0hJSmU4N0Q0ZXFRbjRtbVpIc2tWeVpDeVZvQXczUXZRUUxPc0doa0VGUzNB?= =?utf-8?B?Q2k2TEJUOTlERnlFTS9KcjVKL0lhcDEyNzU1RXl0bENvUktJNUljc2JXc1RP?= =?utf-8?B?UVlaalNySERlTzNEMnNYYmNVeXNqOUh5MzZpSitwVjVreWFPRzhJdHR5TDRY?= =?utf-8?B?cmc1YkdKODRKN2d6QUZwcmwxb3V2MHEwTjhkOVJnL2lIR1YzMkIrcXFFWjN1?= =?utf-8?B?MEx6TGM2bENPSzFmTk9rSW9tY2UvTVdiMnQxaXc1VnU5L1h1SnVXY3pjSzR1?= =?utf-8?B?SlAxZERuOGtjdmlDZDhTc1g5ZEhDVzZXQWNKQlowd3A3L3pha2I1QnlXanJE?= =?utf-8?B?Vk0yd2xOM1ZmUEVjT3JIYkkxQ2tRcy9hRWpXcDdaZm9ONjkxWHBjSjRUMEtN?= =?utf-8?B?TG9pZEM0VTFPUzlXYXFnY0NzY1NlSnNxWmU1M1piSTBWeWZndVkwTjdNTCsx?= =?utf-8?B?eWRpNkh4dFJaRTlmNWtMS1owN25WdFlWMW9FcW1SeHlSQ0UwQXpsVWxNTnJ4?= =?utf-8?B?RWFXTFdwSUdva2ZhZFhhcjk5eDYyTSthZStrRWVWWEtleFR0dkIybjhjT1Ba?= =?utf-8?B?MnE1cXcxb0o2UE1FV2xKZlg1M21XZ01QT0k0NDRKZDJqN2NVMmNTbFo4VmZT?= =?utf-8?B?RzlhQmsybDRtaVVaQ05HZi9udnVDcm11cHpxWkY0c2tRNk9USkxkSFJZWGpD?= =?utf-8?B?NHEwZUFGR0tiN0lXdFZzR1R2dE1Ta3JzN3dvMzJQU2NLWXJhY2htWGdETkxP?= =?utf-8?B?d3lZWmZRMGcrSHczUHlYT1lOQ2pqME55ZnVtakMxbVd6Yy9ERmRKV0NzM2Vp?= =?utf-8?B?Y2JKa0VRekJRTUZPczd0bC9PbkV3aEh4ekVmby93d1pJQ0hWc3Y3N1dMYTB6?= =?utf-8?B?SFg5WEZpNGRpNytKQ3E5ZUZlY1J0dDF1MjlhOStpMXpnOWNZbGNTVE9rUFdH?= =?utf-8?B?WnhiVzBDZmpTZTdGakduZ1doU3J4ZFQ1VUtzUjlWdnVSWHg5R0hubS9Ya2FN?= =?utf-8?B?bW82TmxwcDg1VUM5T2F4bGZ2TEJRd1JuT3pqRmxqbTRLbU5wVFc4SUQ0WW5q?= =?utf-8?B?VURINEg3SjFJQUZwbHIvQjhKeFRjS2srME9RTDF1bkZ3MjBTN2RrRlhTZ1NH?= =?utf-8?B?d3VGWGtYa3NHZ2hKY0NnY3MwekRyTXZ0c2NQUm53T1ptaUVCNkdQZEhybU0x?= =?utf-8?B?YVh5SzBUSysxZklRYzUyeGdDK2oxU0lrTTJORmpTME80SGtVOWlOcHFmTlpD?= =?utf-8?B?ckx5Y1pOUU9mMytqMnVDWUh5Q3VicWhFRG1aeHRQRUVkWnYxOXJveDhWN0VU?= =?utf-8?B?UVlKWWRlNTFIM2Vzdk14RjNIdDJqTmdrYUlsZjdkT3lqQU0yUVFuSFBlcjZH?= =?utf-8?B?T2h3Qnc5MDRrck1DR1k4bEI3VmJSOFlFYmwxcmJXUlNaREc3eXlEN1JGekU5?= =?utf-8?B?REI4dmVBQ1pCbGF1RFZOUE9uR2ZHTUUwOGRZUG9lN1VZeE1IeUpNQ1pMWTRL?= =?utf-8?B?SEEyaCt5U1lUTzNqMVpGNDFrSlltRDZUd0JHSktSdGZwT25aVjdJa0Y2RUM3?= =?utf-8?Q?q+1tcIPzi6nbA/IS0F?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 710700f0-7081-4f8a-f6fe-08df17ee2aa0 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 14:39:39.5693 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1stA75IHURvis2rCFzLAqX/4EgExXmqr+x7wUTLUKGw4pqINXbLMMHh77ZWl6+5J8Oj8K/yWLbCWnQfB1J4Wbw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB999321 X-purgate-ID: tlsNG-33051d/1790001584-6D0D94E9-F8A89367/0/0 X-purgate-type: clean X-purgate-size: 8891 On Thu Aug 27, 2026 at 11:35 AM CEST, Baptiste Le Duc wrote: > v1 was posted on 2026-08-10 with no response yet (13 business days). This > v2 also fixes a bug flagged during internal review, see "Changes since v1= " > below. > > Xen is being made safety certifiable to IEC 61508 SIL 3 and ISO 26262 ASI= L > D, with Arm and x86 as the current targets [1]. Evidence at those levels = is > requirements based testing plus structural coverage, produced automatical= ly > and repeatably in CI. > > QTB (QEMU Test Bench) [2] is the framework AMD wrote for it as part of th= e > Xen safety initiative. It drives a live QEMU instance over qtest, QMP and > GDB, so a test has full access to the machine while emulation runs: read > and write the consoles, inspect registers and memory, inject interrupts a= nd > faults, all from Python and all reproducible in a pipeline. QTB is not > upstream in QEMU yet, but is planned to be. > > RISC-V is not in the certification scope today. It is also the youngest > port, so it has close to no test infrastructure to undo, which makes it t= he > cheapest place to adopt QTB. Starting the riscv64 tests on the framework > now means the port grows its tests in the shape certification asks for as > the port itself grows, instead of a pile of expect scripts to convert lat= er > if riscv64 ever becomes a certification target. It also puts a second > architecture on QTB, which is useful to the framework itself before it is > proposed to QEMU upstream. > > Concretely, the riscv64 CI coverage today is one expect script, > automation/scripts/qemu-smoke-riscv64.sh, which boots Xen alone under QEM= U > and greps a single string out of one serial console. The machine it boots > is hardcoded, so a second configuration means a second script, and a test > with a DomU in it means growing guest handling from scratch. > > This series replaces that script with a data-driven framework using QTB. = A > machine is a YAML entry (pcpus, scheduler, interrupt controller, boot > arguments), a test type is a small Python class saying what to do with a > booted machine, and a test binds a machine to that type's expectations. > Adding a configuration to CI is then a config change and a job stanza. > > Patch 1 goes to test-artifacts [3] and must land first, since patches 2-6 > run inside the container it adds. Patches 2-6 go to xen.git. > > test-artifacts [3]: > - Add a QTB container to run the Xen riscv64 tests > debian:13-qtb-riscv64, carrying qemu.qtb from AMD's QEMU fork and the > dtc/fdt dependencies the framework needs at run time. > > xen.git: > - automation/qtb: add jinja2 device trees for riscv64 smoke tests > The host tree varies with hart count, MMU type and device set, so it = is > rendered per machine from a template rather than shipping one static > .dts per configuration. > - automation/qtb: add Python QTB framework with the console-test type > The base layer every test type builds on (machine catalog lookup, hos= t > DT generation, QEMU invocation, per-console log capture) plus the fir= st > test type, which asserts every string listed in console-test.yaml is > printed on the expected console. > - automation/qtb: add unit tests for the QTB framework > pytest coverage of the QEMU-agnostic parts, for developers only. > - automation/qtb: add QTB framework README > How to add a machine, add a test type and run one locally. > - CI: run the riscv64 smoke test via QTB framework console-test > Repoints qemu-smoke-riscv64-gcc at the framework and drops > qemu-smoke-riscv64.sh, which then has no caller left. > > Testing: Unit tests + QEMU only, as the existing riscv64 CI does. > qemu-smoke-riscv64-gcc runs the same check as before. > > The catalog ships a single Xen-only machine, since Xen cannot boot a DomU > on RISC-V yet. DomU machines plus an irq-test type using QTest interrupt > injection follow once DomU support lands. > > CI pipeline: > https://gitlab.com/xen-project/people/baptleduc/xen/-/pipelines/279590704= 2 > > [1] https://elisa.tech/blog/2026/07/22/the-final-phase-of-xen-safety-solv= ing-coverage-and-residual-gaps-stefano-stabellini-amd/ > [2] https://gitlab.com/xen-project/people/amd/qemu/-/tree/safety > [3] https://gitlab.com/xen-project/hardware/test-artifacts > [4] https://lore.kernel.org/xen-devel/1786980254.8631fc262581453bbf619ec5= b2062170.1a01052c27d000c4f3@vates.tech/ These patches are way too coarse to be looked at carefully, imo. It'd help a lot if you managed to split further up the series until each patch is <200LoC at least. Otherwise it's just a an exercise in frustration just to find out how everything works. Even at 200 it's annoying, but it's manageable at least. Cheers, Alejandro > > --- > Changes since v1: > - Resolve qemu-system-riscv64 from $PATH instead of pinning qemu-9.0.0 in > test.yaml, dropping the now-unneeded OpenSBI entry too: the > 13-qtb-riscv64 container already bundles both (flagged by Zheng Zhang > during internal review [4]). Also drops the qemu-9.0.0-riscv64 > test-artifacts dependency noted above. > > Baptiste Le Duc (5): > automation/qtb: add jinja2 device trees for riscv64 smoke tests > automation/qtb: add Python QTB framework with the console-test type > automation/qtb: add unit tests for the QTB framework > automation/qtb: add QTB framework README > CI: run the riscv64 smoke test via QTB framework console-test > > .gitlab-ci.yml | 3 + > automation/gitlab-ci/test.yaml | 20 +- > automation/scripts/qemu-smoke-riscv64.sh | 19 -- > automation/scripts/qemu_smoke_riscv64.py | 122 ++++++++++ > automation/scripts/qtb/__init__.py | 2 + > automation/scripts/qtb/riscv/README.md | 182 +++++++++++++++ > automation/scripts/qtb/riscv/__init__.py | 9 + > automation/scripts/qtb/riscv/config.py | 119 ++++++++++ > automation/scripts/qtb/riscv/config.yaml | 17 ++ > .../qtb/riscv/console_test/__init__.py | 4 + > .../qtb/riscv/console_test/console-test.yaml | 18 ++ > .../qtb/riscv/console_test/console_test.py | 145 ++++++++++++ > automation/scripts/qtb/riscv/dt.py | 57 +++++ > .../scripts/qtb/riscv/dts/qemu-host.dts.j2 | 160 +++++++++++++ > automation/scripts/qtb/riscv/machine.py | 57 +++++ > automation/scripts/qtb/riscv/paths.py | 60 +++++ > automation/scripts/qtb/riscv/qtb_test.py | 53 +++++ > automation/scripts/qtb/riscv/unit/__init__.py | 2 + > automation/scripts/qtb/riscv/unit/conftest.py | 42 ++++ > .../scripts/qtb/riscv/unit/test_config.py | 121 ++++++++++ > .../qtb/riscv/unit/test_console_test.py | 217 ++++++++++++++++++ > automation/scripts/qtb/riscv/unit/test_dt.py | 99 ++++++++ > .../scripts/qtb/riscv/unit/test_machine.py | 60 +++++ > .../scripts/qtb/riscv/unit/test_temp_dir.py | 42 ++++ > .../scripts/qtb/riscv/unit/test_xen_dt.py | 46 ++++ > automation/scripts/qtb/riscv/xen_dt.py | 58 +++++ > 26 files changed, 1709 insertions(+), 25 deletions(-) > delete mode 100755 automation/scripts/qemu-smoke-riscv64.sh > create mode 100755 automation/scripts/qemu_smoke_riscv64.py > create mode 100644 automation/scripts/qtb/__init__.py > create mode 100644 automation/scripts/qtb/riscv/README.md > create mode 100644 automation/scripts/qtb/riscv/__init__.py > create mode 100644 automation/scripts/qtb/riscv/config.py > create mode 100644 automation/scripts/qtb/riscv/config.yaml > create mode 100644 automation/scripts/qtb/riscv/console_test/__init__.py > create mode 100644 automation/scripts/qtb/riscv/console_test/console-tes= t.yaml > create mode 100644 automation/scripts/qtb/riscv/console_test/console_tes= t.py > create mode 100644 automation/scripts/qtb/riscv/dt.py > create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > create mode 100644 automation/scripts/qtb/riscv/machine.py > create mode 100644 automation/scripts/qtb/riscv/paths.py > create mode 100644 automation/scripts/qtb/riscv/qtb_test.py > create mode 100644 automation/scripts/qtb/riscv/unit/__init__.py > create mode 100644 automation/scripts/qtb/riscv/unit/conftest.py > create mode 100644 automation/scripts/qtb/riscv/unit/test_config.py > create mode 100644 automation/scripts/qtb/riscv/unit/test_console_test.p= y > create mode 100644 automation/scripts/qtb/riscv/unit/test_dt.py > create mode 100644 automation/scripts/qtb/riscv/unit/test_machine.py > create mode 100644 automation/scripts/qtb/riscv/unit/test_temp_dir.py > create mode 100644 automation/scripts/qtb/riscv/unit/test_xen_dt.py > create mode 100644 automation/scripts/qtb/riscv/xen_dt.py From xen-devel-bounces@lists.xenproject.org Mon Sep 21 14:56:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 14:56:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427640.1650443 (Exim 4.92) (envelope-from ) id 1x8fR1-00054V-3G; Mon, 21 Sep 2026 14:55:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427640.1650443; Mon, 21 Sep 2026 14:55:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fR1-00054O-0N; Mon, 21 Sep 2026 14:55:59 +0000 Received: by outflank-mailman (input) for mailman id 1427640; Mon, 21 Sep 2026 14:55:58 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fR0-00054I-1D for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 14:55:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8fQy-00DYVI-Ts for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:55:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab14565-e002-0a2a0a5209dd-0a2a4506b338-48 for ; Mon, 21 Sep 2026 16:55:56 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1457c-195a-0a2a45060019-4a7de18cdd02-3 for ; Mon, 21 Sep 2026 16:55:56 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d3920so21375875e9.1 for ; Mon, 21 Sep 2026 07:55:56 -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-49fcd115dcbsm232267515e9.15.2026.09.21.07.55.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 07:55:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790002556; x=1790607356; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=JJSPnhpBfQDvLzWMDKDLPoJA2wV83c4JXvRKt8rLBRs=; b=SHHYoRMrYQfI1bpdluZgNOB/8civXMTkF4kNkxS1zcy664j5PfEHSxJ9KA8VgLsQZZ mrWm/Uu5+z2C5CE3/8EfpHcVYY6S9ez2Duq6eSA9PemqEVcE9/HV5WJoohfAW1kp49vt E4QcEWQVZbaNZenSqnnPgMZ1V/sArcWwUIACgSBhs498Gyn1qlEPJmC1SlU2YwTxxUwo mAVvyobU1R34pWT/gd8cA5MJmvD11mbRZw3OfSOXTRE5LcFgdpWWjaelwlylMGnuAuuk tyQbSkOPawcHaAjAYGZQhX9km9LDs6U0oncoC6gaa2fqj1peMPrlhe+uEX0pivDOHFUm eB8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790002556; x=1790607356; h=content-transfer-encoding:content-type: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:content-type; bh=JJSPnhpBfQDvLzWMDKDLPoJA2wV83c4JXvRKt8rLBRs=; b=2q5EEFrM3BpuQWjXQdMjhHmdmb50LeE53ohr/1wIqyMFfQRjDzgAYxJGTTSQ5fqUlU rupfwiNT187ZujJdAkvkKl6FMSIMrVR+fsJfgKtICqjxekxWZXfxYGJbWNbjzyRjlExs XMYkhPEVNEUN5sOHvGzkPHGkTw4uNU2bN7bBBagHFtas8+ocwh58VQWTa7jQfgyTjvaf I+c68Jhrh9+IMmvSThVU9AhKV/ikFx8JTAS4FqDS9YwHwOY9IDQvaTf3FooIzxnhNEtW B5TALwdYaAbFf5qmqVO33QCTVEFao7eO2K+jHorws9t6L5OgxE0A1/0lkq/LAdmagyZr a2Sw== X-Forwarded-Encrypted: i=1; AKwUvBwTeaL37nfFt1SgSHAfKlvPTAzxjOSgTu7PV83ZAvXzBPZ7DldHlGkRiLnc4mG2jWYhDkiN8InsVUg=@lists.xenproject.org X-Gm-Message-State: AFuF++nK4vuItLHRcLq9J91bVZQcoi/h1graSyxNTFwyoljrh9c/aKjq Tr+NYYwvOQIBJgFFAqzHF/wxXhBBMRiycjJtrr7GoHreJEw4N8VGaUglTH9yAGb8Kg== X-Gm-Gg: AYBFou3xR6NaEzhh6888Ige5tQ9x3R6ZgLXLlLHxhFKSxgw9iuqfQq7+Aa2Tnd53ng8 Lbri0WSS4bnOJS7w4G4n4mtpiiZRfC+1mWKan7kGSp+ocVns39FiZm9jAwkST5RyC3UYH0wIYjD yL1W7nMJvkyS83uNn7rlY4OhRI5dXcalxa282rQeQd4xUzzxq2yoLWSB2EHpGmOHkw6Ana4TBrQ mqLe/PR8ciP1DkTfzhWB0zOtksYMVDCn9uvzKyxOmJKr5wy8JjURJ5TCjEKamS1nKkB3qrnPrRR zCUiXbDZe1HQwgLJ1IYkwR/mZ0WRkUJpERSq0tALy8VIwY1stOO7CDuuSUTSHlf0AKU8wodoVhk csJjXSn6wBUg6sa8Bryozc9BBl11kmwjPpW1yynllekRcKLQFixQqPH/QIzJx4sjQaEHlVPyXKi l9RREfg5JxTqRU1TM6kDFR8bXUR3z5E/jcTN20OgWeMdxaHdh+L1hQWqRcnmJUekX/m+3tPXuDB B7l7O1YoPsJh5J4FA+o84fqKJvv0Z2Vq439bvXhL0RoYeN51y4Gjr3eUlbgYoE= X-Received: by 2002:a05:600c:4e4a:b0:49e:6e94:7cae with SMTP id 5b1f17b1804b1-49fc5741495mr154441435e9.28.1790002556162; Mon, 21 Sep 2026 07:55:56 -0700 (PDT) Message-ID: <8f70ec4c-ffb1-4116-9128-1cbdf8d89ce5@suse.com> Date: Mon, 21 Sep 2026 16:56:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/HVM: replace paging_mode_hap() uses To: Alejandro Vallejo , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Teddy Astie , "xen-devel@lists.xenproject.org" References: 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 X-purgate-ID: tlsNG-16d1c6/1790002556-F78CB77B-57F4593C/0/0 X-purgate-type: clean X-purgate-size: 1968 On 21.09.2026 15:45, Alejandro Vallejo wrote: > On Mon Sep 21, 2026 at 3:19 PM CEST, Jan Beulich wrote: >> HVM guests cannot run without either HAP or shadow enabled. While >> paging_mode_shadow() is compile-time-constant when SHADOW_PAGING=n, >> paging_mode_hap() isn't. Hence the former is preferred to leverage DCE. >> >> In svm_update_guest_cr() combine two adjacent conditionals. >> >> Signed-off-by: Jan Beulich > > Yes, please. > > Reviewed-by: Alejandro Vallejo Thanks. >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -113,7 +113,8 @@ static void cf_check svm_update_guest_cr >> switch ( cr ) >> { >> case 0: >> - if ( paging_mode_hap(v->domain) ) >> + value = v->arch.hvm.guest_cr[0]; >> + if ( !paging_mode_shadow(v->domain) ) >> { >> uint32_t intercepts = vmcb_get_cr_intercepts(vmcb); >> >> @@ -122,9 +123,7 @@ static void cf_check svm_update_guest_cr >> monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) ) >> vmcb_set_cr_intercepts(vmcb, intercepts | CR_INTERCEPT_CR3_WRITE); >> } >> - >> - value = v->arch.hvm.guest_cr[0]; >> - if ( paging_mode_shadow(v->domain) ) >> + else >> value |= X86_CR0_PG | X86_CR0_WP; > > nit: This would be clearer with the polarity reversed. Check shadow > first and have hap later. It'd also make the diff (marginally) smaller too. Not sure about diff size, but I deliberately didn't want to inverse polarities anywhere. Switching the predicate I was hoping to be sufficiently uncontroversial (except, as Andrew points out, it having a slightly negative doc effect in a few places). Inverting polarities of if/else-like constructs, otoh, can affect code gen, and we would likely not want to favor shadow over HAP now that shadow is off by default. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 15:08:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 15:08:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427649.1650452 (Exim 4.92) (envelope-from ) id 1x8fd9-0007EW-3G; Mon, 21 Sep 2026 15:08:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427649.1650452; Mon, 21 Sep 2026 15:08:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fd9-0007EP-0N; Mon, 21 Sep 2026 15:08:31 +0000 Received: by outflank-mailman (input) for mailman id 1427649; Mon, 21 Sep 2026 15:08:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fd8-0007Ci-52 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:08:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8fd7-00Cvgz-A5 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:08:29 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab14858-bab6-0a2a0a5309dd-0a2a45088778-22 for ; Mon, 21 Sep 2026 17:08:24 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab14868-f659-0a2a45080019-4a7de18cf104-3 for ; Mon, 21 Sep 2026 17:08:24 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d822dso21681095e9.2 for ; Mon, 21 Sep 2026 08:08:24 -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-49fc6ca43edsm298240995e9.0.2026.09.21.08.08.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 08:08:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790003304; x=1790608104; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Mnv2QTidOl4onXRzfjp9Sqoj5ezvwg+YcGydnDzzmak=; b=Di4XeVwxfctXp1vbCefrpQfq9wdZUdKclYxSvGKOD3PmrLc6K1rO6Z77qttPKIawDw oMVMoreIw+yuBBlVB171QVTgJXLqlhVLvMm2zRbRXTg9IiD9nn9mqm/5zcpllD8nNsAN fcnojP2300TXFBu3sF2gdVNw+mpTtt9+0Q9O46NkIdMQ9OA06zteb/kicjIWsyP7s898 v62vpb8VFWhcLwUsLMzTdSUKVctwmyNS86r62VY9irCgrGLHNoJHL0IotVXa3i9f6oWS bpvM/GpXlXQk3yZtblODVsok+XRl0ti3qBk4PxA5wtH7gmmRFUAyHHak2QwbZ0n/Jqqa 9GnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790003304; x=1790608104; h=content-transfer-encoding:content-type: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:content-type; bh=Mnv2QTidOl4onXRzfjp9Sqoj5ezvwg+YcGydnDzzmak=; b=A0e/kS49F9uRpaIDNV5FdVQ/6E+hml56uNA7Jr4FLQwGUp6jUuCtJUe5u1YvqtMHxF zhfqsL0e2cYckU1dycLF/omBO20iD3N2BoqBbVx/p7JjNoImdWcgeU3Mz9wOkTTnXO/4 v1mepjO7KJ2M+e98KMNuFF0ik8RMHEy3tlp29CQ29tOwI5l7lM/sYMFgBG7/g39/DL/H lRI1XcvWU/fJWZUfiLdJ9Y3G0F3HwWelAIrrxnGA9FPLoC2X2EvfYuTggu+QIqlmAEP2 BtyLNPGoC7LF3E/UO/eo+ecN5OL7iACPSxquRe37RqslyYt16QtWdOYazswVl9SdzPcE a0IQ== X-Forwarded-Encrypted: i=1; AKwUvBzZX16EpOQM/OyJCf7Y5CCZ5A8ybu2Hvz1NEZDR6zLjkBqz5Lmrr3HkyOJhopUKGB09lvAb/ORGgSA=@lists.xenproject.org X-Gm-Message-State: AFuF++l+HyeKzlaKXNwXHaG6ESARi80byqglsXCy3utzAlidLTfDoHW/ pTWtf5zZ+PjcMPXfc5gHjqwVlkIhFalqsDxiwkFMuK1cb8LQt7eISWr4bjAEMTy8Sw== X-Gm-Gg: AYBFou2v9V3GSbJ5cH3DpFI8XPnQXl1jUsj4URA+W8oX5jwz/WU8QlfbulEtxou2W7Q /9absq3BU46fJFDNQ3qdZQ+Mlf2uIsk0FVoxS7BK6Ans0RzC1vKC5+KV0qOVB/cnKN+nRUaGn5j WjxRPKjBAnm3HRZCk3RfnE48giPTDCzAmVlVMITeJNlkhvFtukWqnDrjomYMku6n6vlPtxe3cMe 93cpgjlEjg9l/S+VMT4Uuje8ogbM3bZFSBqbmU7f7Y2e6CavWQ2c7GJ0bFNh5hyLYDLfKS/lU9Z 4L9IV/VWbs10/U50StjpN64gfZul+u6RHJuQ1oq0SBqb4o4IndckYFyNv60x4r4KiM6mtc6L7UN fsN6ExEAE4db3H2quEa4NOJjUM/7jZeYl17PsW4eVbIKpYpOE/Ut0avkqj6oOTXLNBk1GrtSBeH 2bNMCA+SvjsFbmq/Vs7FV0nixNq1XFLtgsmkhcBmFYT4Q0XxwmlHSykAVz02lJXYBCBOmmCfzwC pJtPFQt6hpYIHnTOvolDUnZMPqJq0Ax53vZHHaSizdF/HJLb6TftIIo626zkU26 X-Received: by 2002:a05:600c:5254:b0:493:c47f:3c55 with SMTP id 5b1f17b1804b1-49fc56732aamr155912045e9.5.1790003304186; Mon, 21 Sep 2026 08:08:24 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 17:08:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9260a8cb-66f0-4eba-b630-666039bf2e72@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 X-purgate-ID: tlsNG-c1860d/1790003304-DF6D687B-81384C38/0/0 X-purgate-type: clean X-purgate-size: 5878 On 21.09.2026 16:01, Oleksii Kurochko wrote: > On 9/18/26 2:52 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/domain.c >>> +++ b/xen/arch/riscv/domain.c >>> @@ -136,6 +136,8 @@ static void vcpu_csr_init(struct vcpu *v) >>> v->arch.hstateen0 = (hstateen0 & csr_masks.hstateen0) | >>> csr_masks.ro_one.hstateen0; >>> } >>> + >>> + v->arch.hie = MIP_SGEIP; >> >> Neither part of the rhs identifier has anything to do with the CSR >> having its default value set here. That's perhaps again a piece of >> RISC-V I'm missing, but I can't make sense of this. > > All interrupt pending/enable CSRs share one bit layout (bit N > corresponds to interrupt cause N), which is why MIP_SGEIP happened to be > numerically right. I'll use BIT(IRQ_S_GEXT, UL) instead and add a > comment: hie.SGEIE is what allows the SGEI raised through hgeie to be > taken by Xen at all, while hie's VS-level bits alias the guest's vsie > and are left cleared. I will apply the following change: > > - v->arch.hie = MIP_SGEIP; > + /* > + * Enable SGEIs, so that a guest interrupt file marked in HGEIE while > + * the vCPU is descheduled can raise an interrupt to Xen. > + * > + * The VS-level bits of hie alias the guest's vsie, which is saved and > + * restored separately, so they are left clear here. > + */ > + v->arch.hie = BIT(IRQ_S_GEXT, UL); It's somewhat better this way, yes. And as said - in not looking great to me (doc-wise) is likely an issue of mine, not of yours. >>> --- a/xen/arch/riscv/imsic.c >>> +++ b/xen/arch/riscv/imsic.c >>> @@ -510,12 +510,31 @@ void cf_check imsic_ctxt_switch_from(struct vcpu *v) >>> >>> write_lock_irqsave(&imsic_state->vsfile_lock, flags); >>> imsic_state->vsfile_cpu = v->processor; >>> + /* >>> + * Start to observe the VS-file from HS-mode: while the vCPU isn't >>> + * running an interrupt pending in its VS-file is reported through HGEIP >>> + * instead of being delivered to VS-mode, which lets Xen wake the vCPU up. >>> + */ >>> + csr_set(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); >>> write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >>> } >> >> It is suspicious for the HGEIE write to be the last step. How's this free >> of a window where an interrupt is lost. (Sorry, likely another blind spot >> of mine wrt RISC-V.) > > There's no window: a guest interrupt file's hgeip bit is > level-sensitive, i.e. it reflects whether the file currently has a > pending-and-enabled interrupt (the MSI itself stays latched in the > file's eip[] until the guest claims it), and hip.SGEIP is simply (hgeip > & hgeie) != 0. So an MSI arriving after the vCPU stopped running but > before hgeie is set raises an SGEI as soon as the bit is set, taken once > interrupts are re-enabled. I'll extend the comment to say so: > > /* > * Start to observe the VS-file from HS-mode: while the vCPU isn't > * running an interrupt pending in its VS-file is reported through > HGEIP > * instead of being delivered to VS-mode, which lets Xen wake the > vCPU up. > * > * HGEIP is level-sensitive, reflecting the VS-file's current state, so > * an interrupt that became pending before this point raises an SGEI as > * soon as the bit is set in HGEIE; nothing is lost in between. > */ > > Does it make sense? I think I get what you're trying to explain, but the term "level-sensitive" here doesn't really help. I'm unconvinced you actually mean that, as it requires pins / physical signals, which don't exist with MSI. It feels like you may mean "sticky" instead. >>> void cf_check imsic_ctxt_switch_to(struct vcpu *v) >>> { >>> - /* Nothing to do */ >>> + struct vimsic_state *imsic_state = v->arch.vimsic_state; >>> + unsigned long flags; >>> + >>> + /* A s/w VS-file is never observed through HGEIP. */ >>> + if ( !vcpu_guest_file_id(v) ) >>> + return; >>> + >>> + /* >>> + * The vCPU is about to run, so hstatus.VGEIN delivers the VS-file's >>> + * interrupts to it directly and there is nothing left for Xen to observe. >>> + */ >>> + read_lock_irqsave(&imsic_state->vsfile_lock, flags); >>> + csr_clear(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); >>> + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >>> } >> >> How can this be a read-lock when you write a CSR? > > But here is a protection of ->guest_file_id not of write to a CSR and we > want to not have a change of ->guest_file_id during an update of CSR_HGEIE. > >> Or else - why is locking >> here necessary in the firt place? > > Strictly speaking no locking is needed with the current implementation: > HGEIE is local to this pCPU, and guest_file_id can't change > concurrently. It's updated either by this very pCPU ahead of switching > the vCPU in (imsic_migrate_vcpu() called from schedule(), > imsic_vsfile_attach() right after), or while the vCPU can't be > scheduled: sched_unit_migrate_finish() defers to unit_context_saved() > while the unit is running, and sched_move_domain() pauses the domain. > > (and the similar are true for imsic_ctxt_switch_from()) > > But IMO we should keep around ->vsfile_lock to not miss the case where > some case will update ->guest_file_id in parallel with > imsic_ctxt_switch_to(). > > Does it make to continue to have read_lock_irqsave(...->vsfile_lock, > ...) here just for potential future cases? You get to judge. If the lock typically is uncontended, keeping things as-is may indeed be fine. Introducing a bottleneck "just for potential future cases" otoh wouldn't look overly nice to me. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 15:24:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 15:24:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427658.1650460 (Exim 4.92) (envelope-from ) id 1x8fs4-0001k5-Di; Mon, 21 Sep 2026 15:23:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427658.1650460; Mon, 21 Sep 2026 15:23:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fs4-0001jy-As; Mon, 21 Sep 2026 15:23:56 +0000 Received: by outflank-mailman (input) for mailman id 1427658; Mon, 21 Sep 2026 15:23:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fs2-0001jr-QY for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:23:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8fs1-00DcgC-8R for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:23:53 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab14c08-e002-0a2a0a5209dd-0a2a4507c91a-6 for ; Mon, 21 Sep 2026 17:23:53 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab14c08-b4ea-0a2a45070019-c387df82e38e-3 for ; Mon, 21 Sep 2026 17:23:53 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 89916219B3; Mon, 21 Sep 2026 15:23:44 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 33B9E13793; Mon, 21 Sep 2026 15:23:42 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id UKI5A/5LsWrMfAAAD6G6ig (envelope-from ); Mon, 21 Sep 2026 15:23:42 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790004228; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=/VkC67msFQZzDCHeLIME8y32FTfMzKWh+3d2Bu15lIs=; b=eGWxoMWWjb3KQyPwLxRQ56DQpkuu47zbkNyrbyWWCoS86qr+Oo5WwgNwIoR0fSB2C5Id4S Rwc7fbuSbUSuE0sy2ZvFIkDOceABsXXvFuIGhXCczV73CZDRRcwQcWDgbhGir3pWjGnFjO Mp3WgCJJlNn7gTxAM0lkAwsHcuGvqdk= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=MG0RJ5NW DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790004224; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=/VkC67msFQZzDCHeLIME8y32FTfMzKWh+3d2Bu15lIs=; b=MG0RJ5NWcjT0bvQlmoPyqzoMfwSY52OvREe84/xPqggmc9Jh3O2yB0v8OIg0cMAMHs7eJ7 S9R9zcd/RpnTqTQgUSOAEWXIk56GZ40SwbQQWFMzQesRCvvJyzU/8CcCF4qABST5JrxOGQ cqwdlWChCyZ+ZgdWGE0m3wWY9ArV0WQ= Message-ID: <6df2617a-5bee-4bac-822d-a4ca09c47e76@suse.com> Date: Mon, 21 Sep 2026 17:23:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 00/13] x86/msr: Drop 32-bit MSR interfaces To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, Ingo Molnar Cc: Thomas Gleixner , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Damien Le Moal , Niklas Cassel , David Airlie , Helge Deller , linux-geode@lists.infradead.org, Olivia Mackall , Herbert Xu , Linus Walleij , Bartosz Golaszewski , Arnd Bergmann , Greg Kroah-Hartman , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , xen-devel@lists.xenproject.org References: <20260911074530.3140830-1-jgross@suse.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260911074530.3140830-1-jgross@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------axxK79NgUHTDoQRwnbgWpSYy" X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 89916219B3 X-Spamd-Result: default: False [-3.91 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; SUSPICIOUS_RECIPS(1.50)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MX_GOOD(-0.01)[]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FREEMAIL_CC(0.00)[kernel.org,alien8.de,linux.intel.com,zytor.com,broadcom.com,redhat.com,gmx.de,lists.infradead.org,selenic.com,gondor.apana.org.au,arndb.de,linuxfoundation.org,infradead.org,arm.com,google.com,intel.com,linaro.org,microsoft.com,hygon.cn,amd.com,zhaoxin.com,oracle.com,roeck-us.net,gmail.com,bootlin.com,nod.at,ti.com,lists.xenproject.org]; R_RATELIMIT(0.00)[to_ip_from(RLd6eq7w9gpcedu6aekum1umqh)]; DKIM_TRACE(0.00)[suse.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_GT_50(0.00)[94]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:dkim,suse.com:mid] X-Spam-Flag: NO X-Spam-Score: -3.91 X-purgate-ID: tlsNG-ef75cf/1790004233-A56C2AE4-3072145C/35/110847 X-purgate-type: clean X-purgate-size: 24058 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------axxK79NgUHTDoQRwnbgWpSYy Content-Type: multipart/mixed; boundary="------------T4ZJp6Lhzy2IBIrjLpBsTTw0"; protected-headers="v1" From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, Ingo Molnar Cc: Thomas Gleixner , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Damien Le Moal , Niklas Cassel , David Airlie , Helge Deller , linux-geode@lists.infradead.org, Olivia Mackall , Herbert Xu , Linus Walleij , Bartosz Golaszewski , Arnd Bergmann , Greg Kroah-Hartman , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , xen-devel@lists.xenproject.org Message-ID: <6df2617a-5bee-4bac-822d-a4ca09c47e76@suse.com> Subject: Re: [PATCH v3 00/13] x86/msr: Drop 32-bit MSR interfaces References: <20260911074530.3140830-1-jgross@suse.com> In-Reply-To: <20260911074530.3140830-1-jgross@suse.com> --------------T4ZJp6Lhzy2IBIrjLpBsTTw0 Content-Type: multipart/mixed; boundary="------------dtnWD0jmGt0coRzSWi6oU7rk" --------------dtnWD0jmGt0coRzSWi6oU7rk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SW5nbywNCg0KT24gMTEuMDkuMjYgMDk6NDUsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+IEZv ciBhY2Nlc3NpbmcgdGhlIE1TUiByZWdpc3RlcnMgb24gdGhlIGxvY2FsIENQVSwgdGhlcmUg YXJlIDIgdHlwZXMgb2YNCj4gaW50ZXJmYWNlczogdGhlICJtb2Rlcm4iIDY0LWJpdCBvbmVz IChyZG1zcnEoKSBldGMuKSBhbmQgdGhlIDMyLWJpdA0KPiBvbmVzIChyZG1zcigpIGV0Yy4p IHdoaWNoIGFyZSB1c2luZyB0aGUgdXBwZXIgYW5kIGxvd2VyIDMyLWJpdCBoYWx2ZXMNCj4g b2YgdGhlIDY0LWJpdCB3aWRlIE1TUiByZWdpc3RlciB2YWx1ZXMuDQo+IA0KPiBUaGUgMzIt Yml0IGludGVyZmFjZXMgYXJlIG5vdCBvcHRpbWFsIGZvciAzIHJlYXNvbnM6DQo+IA0KPiAt IFRoZXkgYXJlIGJhc2VkIG9uIHByaW1pdGl2ZXMgdXNpbmcgNjQtYml0IHNpemVkIHZhbHVl cyBhbnl3YXkuDQo+IA0KPiAtIE1vZGVybiB4ODYgQ1BVcyBoYXZlIGFkZGVkIHN1cHBvcnQg Zm9yIE1TUiBhY2Nlc3MgaW5zdHJ1Y3Rpb25zIHVzaW5nDQo+ICAgIGFuIGltbWVkaWF0ZSB2 YWx1ZSBpbnN0ZWFkIG9mIGEgcmVnaXN0ZXIgZm9yIGFkZHJlc3NpbmcgdGhlIE1TUiwNCj4g ICAgd2hpbGUgdGhlIHZhbHVlIGlzIGluIGEgNjQtYml0IHJlZ2lzdGVyLg0KPiANCj4gLSBy ZG1zcigpIGlzIGEgbWFjcm8gc3RvcmluZyB0aGUgdXBwZXIgYW5kIGxvd2VyIDMyLWJpdCBo YWx2ZXMgaW4NCj4gICAgdmFyaWFibGVzIHNwZWNpZmllZCBhcyBtYWNybyBwYXJhbWV0ZXJz LiBUaGlzIGlzIG9ic2N1cmluZyB2YXJpYWJsZQ0KPiAgICBhc3NpZ25tZW50IHRocm91Z2gg YSBtYWNyby4gQWRkaXRpb25hbGx5IHJkbXNycSgpIGlzIG1pbWlja2luZyB0aGlzDQo+ICAg IHBhdHRlcm4gYnkgYmVpbmcgYSBtYWNybywgdG9vLCB3aXRoIHRoZSB0YXJnZXQgdmFyaWFi bGUgc3BlY2lmaWVkIGFzDQo+ICAgIGEgcGFyYW1ldGVyIGFzIHdlbGwuDQo+IA0KPiBGb3Ig dGhvc2UgcmVhc29ucyBkcm9wIHRoZSAzMi1iaXQgaW50ZXJmYWNlcyBmb3IgYWNjZXNzaW5n IHRoZSB4ODYgTVNSDQo+IHJlZ2lzdGVycyBjb21wbGV0ZWx5IGFuZCBvbmx5IHVzZSB0aGUg NjQtYml0IHZhcmlhbnRzLg0KPiANCj4gVGhpcyBhbGxvd3MgdG8gc3dpdGNoIGFsbCAiaGln aC1sZXZlbCIgTVNSIGFjY2VzcyBtYWNyb3MgdG8gaW5saW5lDQo+IGZ1bmN0aW9ucyBpbiB0 aGUgZW5kLg0KPiANCj4gVGhpcyBzZXJpZXMgd2lsbCBiZSB1c2VkIGFzIHRoZSBiYXNlIGZv ciBmdXJ0aGVyIHJlb3JnYW5pc2F0aW9uIG9mIHRoZQ0KPiBNU1IgYWNjZXNzIGZ1bmN0aW9u cywgZXNwZWNpYWxseSBmb3IgY29tcGxldGVseSBpbmxpbmluZyB0aGUgTVNSDQo+IGFjY2Vz cyBpbnN0cnVjdGlvbnMgZXZlbiB3aXRoIHBhcmF2aXJ0dWFsaXphdGlvbiBiZWluZyBhY3Rp dmUuDQo+IA0KPiBCYXNlZCBvbiBrZXJuZWwgNy4zIGFzIG9mIDIwMjYtMDktMTEuDQo+IA0K PiBDaGFuZ2VzIGluIFYyOg0KPiAtIGRyb3BwZWQgYWxyZWFkeSBhcHBsaWVkIHBhdGNoZXMN Cj4gLSBhZGRlZCBwYXRjaCAxDQo+IC0gcmViYXNlZA0KPiANCj4gQ2hhbmdlcyBpbiBWMzoN Cj4gLSBzbWFsbCBmaXhlcyBpbiBwYXRjaGVzIDQgYW5kIDEzDQo+IC0gcmViYXNlZA0KPiAN Cj4gSnVlcmdlbiBHcm9zcyAoMTMpOg0KPiAgICB4ODYvY3B1OiBGaXggY29kaW5nIHN0eWxl IHZpb2xhdGlvbg0KPiAgICB4ODYvbXNyOiBSZW1vdmUgd3Jtc3Jfc2FmZSgpDQo+ICAgIHg4 Ni9tc3I6IFJlbW92ZSByZG1zcl9zYWZlKCkNCj4gICAgZHJpdmVycy9hdGE6IFN0b3AgdXNp bmcgMzItYml0IE1TUiBpbnRlcmZhY2VzDQo+ICAgIGFncC9udmlkaWE6IFN0b3AgdXNpbmcg MzItYml0IE1TUiBpbnRlcmZhY2VzDQo+ICAgIGZiZGV2L2dlb2RlOiBTdG9wIHVzaW5nIDMy LWJpdCBNU1IgaW50ZXJmYWNlcw0KPiAgICBod19yYW5kb20vdmlhLXJuZzogU3RvcCB1c2lu ZyAzMi1iaXQgTVNSIGludGVyZmFjZXMNCj4gICAgZHJpdmVycy9ncGlvOiBTdG9wIHVzaW5n IDMyLWJpdCBNU1IgaW50ZXJmYWNlcw0KPiAgICBkcml2ZXJzL21pc2M6IFN0b3AgdXNpbmcg MzItYml0IE1TUiBpbnRlcmZhY2VzDQo+ICAgIHg4Ni9tc3I6IFJlbW92ZSB3cm1zcigpDQo+ ICAgIHg4Ni9tc3I6IFJlbW92ZSByZG1zcigpDQo+ICAgIHRyZWV3aWRlOiBjb252ZXJ0IHJk bXNycSgpIGZyb20gYSBtYWNybyB0byBhbiBpbmxpbmUgZnVuY3Rpb24NCj4gICAgeDg2L21z cjogU2ltcGxpZnkgc29tZSByZG1zcnEoKSB1c2UgY2FzZXMNCj4gDQo+ICAgYXJjaC94ODYv Y29jby9zZXYvY29yZS5jICAgICAgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gICBhcmNo L3g4Ni9ldmVudHMvYW1kL2Jycy5jICAgICAgICAgICAgICAgICAgICAgfCAgNCArLQ0KPiAg IGFyY2gveDg2L2V2ZW50cy9hbWQvY29yZS5jICAgICAgICAgICAgICAgICAgICB8ICA4ICst LQ0KPiAgIGFyY2gveDg2L2V2ZW50cy9hbWQvaWJzLmMgICAgICAgICAgICAgICAgICAgICB8 IDE4ICsrKy0tLS0NCj4gICBhcmNoL3g4Ni9ldmVudHMvYW1kL2xici5jICAgICAgICAgICAg ICAgICAgICAgfCAxNiArKy0tLS0NCj4gICBhcmNoL3g4Ni9ldmVudHMvYW1kL3Bvd2VyLmMg ICAgICAgICAgICAgICAgICAgfCAgOCArLS0NCj4gICBhcmNoL3g4Ni9ldmVudHMvYW1kL3Vu Y29yZS5jICAgICAgICAgICAgICAgICAgfCAgNCArLQ0KPiAgIGFyY2gveDg2L2V2ZW50cy9j b3JlLmMgICAgICAgICAgICAgICAgICAgICAgICB8IDIwICsrKystLS0tDQo+ICAgYXJjaC94 ODYvZXZlbnRzL2ludGVsL2NvcmUuYyAgICAgICAgICAgICAgICAgIHwgMTUgKystLS0tDQo+ ICAgYXJjaC94ODYvZXZlbnRzL2ludGVsL2NzdGF0ZS5jICAgICAgICAgICAgICAgIHwgIDUg Ky0NCj4gICBhcmNoL3g4Ni9ldmVudHMvaW50ZWwvZHMuYyAgICAgICAgICAgICAgICAgICAg fCAgMiArLQ0KPiAgIGFyY2gveDg2L2V2ZW50cy9pbnRlbC9rbmMuYyAgICAgICAgICAgICAg ICAgICB8IDEwICsrLS0NCj4gICBhcmNoL3g4Ni9ldmVudHMvaW50ZWwvbGJyLmMgICAgICAg ICAgICAgICAgICAgfCAyNSArKystLS0tLS0tDQo+ICAgYXJjaC94ODYvZXZlbnRzL2ludGVs L3A0LmMgICAgICAgICAgICAgICAgICAgIHwgIDYgKy0tDQo+ICAgYXJjaC94ODYvZXZlbnRz L2ludGVsL3A2LmMgICAgICAgICAgICAgICAgICAgIHwgIDQgKy0NCj4gICBhcmNoL3g4Ni9l dmVudHMvaW50ZWwvcHQuYyAgICAgICAgICAgICAgICAgICAgfCAxMiArKy0tLQ0KPiAgIGFy Y2gveDg2L2V2ZW50cy9pbnRlbC91bmNvcmUuYyAgICAgICAgICAgICAgICB8ICA2ICstLQ0K PiAgIGFyY2gveDg2L2V2ZW50cy9pbnRlbC91bmNvcmVfbmhtZXguYyAgICAgICAgICB8ICA0 ICstDQo+ICAgYXJjaC94ODYvZXZlbnRzL2ludGVsL3VuY29yZV9zbmIuYyAgICAgICAgICAg IHwgIDIgKy0NCj4gICBhcmNoL3g4Ni9ldmVudHMvaW50ZWwvdW5jb3JlX3NuYmVwLmMgICAg ICAgICAgfCAgNiArLS0NCj4gICBhcmNoL3g4Ni9ldmVudHMvbXNyLmMgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgMiArLQ0KPiAgIGFyY2gveDg2L2V2ZW50cy9wZXJmX2V2ZW50Lmgg ICAgICAgICAgICAgICAgICB8ICA2ICstLQ0KPiAgIGFyY2gveDg2L2V2ZW50cy9yYXBsLmMg ICAgICAgICAgICAgICAgICAgICAgICB8ICA2ICstLQ0KPiAgIGFyY2gveDg2L2V2ZW50cy96 aGFveGluL2NvcmUuYyAgICAgICAgICAgICAgICB8IDEwICsrLS0NCj4gICBhcmNoL3g4Ni9o eXBlcnYvaHZfYXBpYy5jICAgICAgICAgICAgICAgICAgICAgfCAgOSArKy0tDQo+ICAgYXJj aC94ODYvaHlwZXJ2L2h2X2luaXQuYyAgICAgICAgICAgICAgICAgICAgIHwgMjYgKysrKyst LS0tLQ0KPiAgIGFyY2gveDg2L2h5cGVydi9odl9zcGlubG9jay5jICAgICAgICAgICAgICAg ICB8ICAyICstDQo+ICAgYXJjaC94ODYvaW5jbHVkZS9hc20vYXBpYy5oICAgICAgICAgICAg ICAgICAgIHwgIDcgKy0tDQo+ICAgYXJjaC94ODYvaW5jbHVkZS9hc20vZGVidWdyZWcuaCAg ICAgICAgICAgICAgIHwgIDYgKy0tDQo+ICAgYXJjaC94ODYvaW5jbHVkZS9hc20vZnNnc2Jh c2UuaCAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gICBhcmNoL3g4Ni9pbmNsdWRlL2FzbS9r dm1faG9zdC5oICAgICAgICAgICAgICAgfCAxMCAtLS0tDQo+ICAgYXJjaC94ODYvaW5jbHVk ZS9hc20vbXNyLmggICAgICAgICAgICAgICAgICAgIHwgMzkgKystLS0tLS0tLS0tLS0tDQo+ ICAgYXJjaC94ODYvaW5jbHVkZS9hc20vcGFyYXZpcnQuaCAgICAgICAgICAgICAgIHwgMjYg Ky0tLS0tLS0tLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9hcGljL2FwaWMuYyAgICAgICAgICAg ICAgICAgICB8IDE0ICsrKy0tLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9hcGljL2FwaWNfbnVt YWNoaXAuYyAgICAgICAgICB8ICA2ICstLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9jZXQuYyAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAyICstDQo+ICAgYXJjaC94ODYva2VybmVsL2Nw dS9hbWQuYyAgICAgICAgICAgICAgICAgICAgIHwgMTQgKysrLS0tDQo+ICAgYXJjaC94ODYv a2VybmVsL2NwdS9hcGVyZm1wZXJmLmMgICAgICAgICAgICAgIHwgIDggKy0tDQo+ICAgYXJj aC94ODYva2VybmVsL2NwdS9idWdzLmMgICAgICAgICAgICAgICAgICAgIHwgMTIgKystLS0N Cj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1L2J1c19sb2NrLmMgICAgICAgICAgICAgICAgfCAg OCArLS0NCj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1L2NlbnRhdXIuYyAgICAgICAgICAgICAg ICAgfCAgOCArLS0NCj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1L2NvbW1vbi5jICAgICAgICAg ICAgICAgICAgfCAxMiArKy0tLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9jcHUvZmVhdF9jdGwu YyAgICAgICAgICAgICAgICB8ICA0ICstDQo+ICAgYXJjaC94ODYva2VybmVsL2NwdS9oeWdv bi5jICAgICAgICAgICAgICAgICAgIHwgIDQgKy0NCj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1 L2ludGVsLmMgICAgICAgICAgICAgICAgICAgfCAgNiArLS0NCj4gICBhcmNoL3g4Ni9rZXJu ZWwvY3B1L2ludGVsX2VwYi5jICAgICAgICAgICAgICAgfCAgNCArLQ0KPiAgIGFyY2gveDg2 L2tlcm5lbC9jcHUvbWNlL2FtZC5jICAgICAgICAgICAgICAgICB8ICA0ICstDQo+ICAgYXJj aC94ODYva2VybmVsL2NwdS9tY2UvY29yZS5jICAgICAgICAgICAgICAgIHwgIDggKy0tDQo+ ICAgYXJjaC94ODYva2VybmVsL2NwdS9tY2UvaW5qZWN0LmMgICAgICAgICAgICAgIHwgIDIg Ky0NCj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1L21jZS9pbnRlbC5jICAgICAgICAgICAgICAg fCAxOCArKystLS0tDQo+ICAgYXJjaC94ODYva2VybmVsL2NwdS9tY2UvcDUuYyAgICAgICAg ICAgICAgICAgIHwgIDggKy0tDQo+ICAgYXJjaC94ODYva2VybmVsL2NwdS9tY2Uvd2luY2hp cC5jICAgICAgICAgICAgIHwgIDIgKy0NCj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1L21pY3Jv Y29kZS9pbnRlbC5jICAgICAgICAgfCAgMiArLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9jcHUv bXNoeXBlcnYuYyAgICAgICAgICAgICAgICB8ICA2ICstLQ0KPiAgIGFyY2gveDg2L2tlcm5l bC9jcHUvbXRyci9hbWQuYyAgICAgICAgICAgICAgICB8ICA0ICstDQo+ICAgYXJjaC94ODYv a2VybmVsL2NwdS9tdHJyL2NsZWFudXAuYyAgICAgICAgICAgIHwgIDQgKy0NCj4gICBhcmNo L3g4Ni9rZXJuZWwvY3B1L210cnIvZ2VuZXJpYy5jICAgICAgICAgICAgfCAzMiArKysrKyst LS0tLS0NCj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1L210cnIvbXRyci5jICAgICAgICAgICAg ICAgfCAgMiArLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9jcHUvcmVzY3RybC9jb3JlLmMgICAg ICAgICAgICB8ICAyICstDQo+ICAgYXJjaC94ODYva2VybmVsL2NwdS9yZXNjdHJsL21vbml0 b3IuYyAgICAgICAgIHwgIDQgKy0NCj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1L3Jlc2N0cmwv cHNldWRvX2xvY2suYyAgICAgfCAgNCArLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9jcHUvcmVz Y3RybC9yZHRncm91cC5jICAgICAgICB8ICAyICstDQo+ICAgYXJjaC94ODYva2VybmVsL2Nw dS90b3BvbG9neS5jICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gICBhcmNoL3g4Ni9rZXJu ZWwvY3B1L3RvcG9sb2d5X2FtZC5jICAgICAgICAgICAgfCAgNCArLQ0KPiAgIGFyY2gveDg2 L2tlcm5lbC9jcHUvdHJhbnNtZXRhLmMgICAgICAgICAgICAgICB8ICA4ICstLQ0KPiAgIGFy Y2gveDg2L2tlcm5lbC9jcHUvdHN4LmMgICAgICAgICAgICAgICAgICAgICB8IDEwICsrLS0N Cj4gICBhcmNoL3g4Ni9rZXJuZWwvY3B1L3Vtd2FpdC5jICAgICAgICAgICAgICAgICAgfCAg MiArLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9jcHUvemhhb3hpbi5jICAgICAgICAgICAgICAg ICB8ICA0ICstDQo+ICAgYXJjaC94ODYva2VybmVsL2ZwdS9jb3JlLmMgICAgICAgICAgICAg ICAgICAgIHwgIDIgKy0NCj4gICBhcmNoL3g4Ni9rZXJuZWwvaHBldC5jICAgICAgICAgICAg ICAgICAgICAgICAgfCAgMiArLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9rdm0uYyAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAyICstDQo+ICAgYXJjaC94ODYva2VybmVsL21tY29uZi1m YW0xMGhfNjQuYyAgICAgICAgICAgIHwgIDYgKy0tDQo+ICAgYXJjaC94ODYva2VybmVsL3By b2Nlc3MuYyAgICAgICAgICAgICAgICAgICAgIHwgIDQgKy0NCj4gICBhcmNoL3g4Ni9rZXJu ZWwvcHJvY2Vzc182NC5jICAgICAgICAgICAgICAgICAgfCAxNCArKystLS0NCj4gICBhcmNo L3g4Ni9rZXJuZWwvc2hzdGsuYyAgICAgICAgICAgICAgICAgICAgICAgfCAgOCArLS0NCj4g ICBhcmNoL3g4Ni9rZXJuZWwvdHJhcHMuYyAgICAgICAgICAgICAgICAgICAgICAgfCAgNCAr LQ0KPiAgIGFyY2gveDg2L2tlcm5lbC90c2MuYyAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAyICstDQo+ICAgYXJjaC94ODYva2VybmVsL3RzY19tc3IuYyAgICAgICAgICAgICAgICAg ICAgIHwgIDYgKy0tDQo+ICAgYXJjaC94ODYva2VybmVsL3RzY19zeW5jLmMgICAgICAgICAg ICAgICAgICAgIHwgIDYgKy0tDQo+ICAgYXJjaC94ODYva3ZtL21zcnMuYyAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gICBhcmNoL3g4Ni9rdm0vc3ZtL3BtdS5jICAg ICAgICAgICAgICAgICAgICAgICAgfCAgNCArLQ0KPiAgIGFyY2gveDg2L2t2bS9zdm0vc3Zt LmMgICAgICAgICAgICAgICAgICAgICAgICB8ICA0ICstDQo+ICAgYXJjaC94ODYva3ZtL3Zt eC9uZXN0ZWQuYyAgICAgICAgICAgICAgICAgICAgIHwgIDQgKy0NCj4gICBhcmNoL3g4Ni9r dm0vdm14L3BtdV9pbnRlbC5jICAgICAgICAgICAgICAgICAgfCAgOCArLS0NCj4gICBhcmNo L3g4Ni9rdm0vdm14L3NneC5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgNiArLS0NCj4g ICBhcmNoL3g4Ni9rdm0vdm14L3RkeC5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgMiAr LQ0KPiAgIGFyY2gveDg2L2t2bS92bXgvdm14LmMgICAgICAgICAgICAgICAgICAgICAgICB8 IDQyICsrKysrKysrLS0tLS0tLS0NCj4gICBhcmNoL3g4Ni9rdm0veDg2LmMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgNiArLS0NCj4gICBhcmNoL3g4Ni9saWIvaW5zbi1ldmFs LmMgICAgICAgICAgICAgICAgICAgICAgfCAgNiArLS0NCj4gICBhcmNoL3g4Ni9saWIvbXNy LXNtcC5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgMiArLQ0KPiAgIGFyY2gveDg2L21t L3BhdC9tZW10eXBlLmMgICAgICAgICAgICAgICAgICAgICB8ICAyICstDQo+ICAgYXJjaC94 ODYvcGNpL2FtZF9idXMuYyAgICAgICAgICAgICAgICAgICAgICAgIHwgIDggKy0tDQo+ICAg YXJjaC94ODYvcGxhdGZvcm0vb2xwYy9vbHBjLXhvMS1ydGMuYyAgICAgICAgIHwgIDYgKy0t DQo+ICAgYXJjaC94ODYvcGxhdGZvcm0vb2xwYy9vbHBjLXhvMS1zY2kuYyAgICAgICAgIHwg IDIgKy0NCj4gICBhcmNoL3g4Ni9wb3dlci9jcHUuYyAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAxMCArKy0tDQo+ICAgYXJjaC94ODYvcmVhbG1vZGUvaW5pdC5jICAgICAgICAgICAg ICAgICAgICAgIHwgIDIgKy0NCj4gICBhcmNoL3g4Ni92aXJ0L2h3LmMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgOCArLS0NCj4gICBhcmNoL3g4Ni92aXJ0L3N2bS9zZXYuYyAg ICAgICAgICAgICAgICAgICAgICAgfCAxOCArKystLS0tDQo+ICAgYXJjaC94ODYvdmlydC92 bXgvdGR4L3RkeC5jICAgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gICBhcmNoL3g4Ni94 ZW4vc3VzcGVuZC5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgMiArLQ0KPiAgIGRyaXZl cnMvYWNwaS9wcm9jZXNzb3JfcGVyZmxpYi5jICAgICAgICAgICAgICB8ICAyICstDQo+ICAg ZHJpdmVycy9hdGEvcGF0YV9jczU1MzUuYyAgICAgICAgICAgICAgICAgICAgIHwgMjQgKysr Ky0tLS0tDQo+ICAgZHJpdmVycy9hdGEvcGF0YV9jczU1MzYuYyAgICAgICAgICAgICAgICAg ICAgIHwgMTcgKysrLS0tLQ0KPiAgIGRyaXZlcnMvY2hhci9hZ3AvbnZpZGlhLWFncC5jICAg ICAgICAgICAgICAgICB8IDMyICsrKysrKy0tLS0tLQ0KPiAgIGRyaXZlcnMvY2hhci9od19y YW5kb20vdmlhLXJuZy5jICAgICAgICAgICAgICB8IDI5ICsrKysrLS0tLS0tDQo+ICAgZHJp dmVycy9jcHVmcmVxL2FjcGktY3B1ZnJlcS5jICAgICAgICAgICAgICAgIHwgIDggKy0tDQo+ ICAgZHJpdmVycy9jcHVmcmVxL2FtZC1wc3RhdGUuYyAgICAgICAgICAgICAgICAgIHwgIDQg Ky0NCj4gICBkcml2ZXJzL2NwdWZyZXEvZV9wb3dlcnNhdmVyLmMgICAgICAgICAgICAgICAg fCAyMCArKysrLS0tLQ0KPiAgIGRyaXZlcnMvY3B1ZnJlcS9pbnRlbF9wc3RhdGUuYyAgICAg ICAgICAgICAgICB8IDI4ICsrKysrLS0tLS0tDQo+ICAgZHJpdmVycy9jcHVmcmVxL2xvbmdo YXVsLmMgICAgICAgICAgICAgICAgICAgIHwgMTIgKystLS0NCj4gICBkcml2ZXJzL2NwdWZy ZXEvbG9uZ3J1bi5jICAgICAgICAgICAgICAgICAgICAgfCAxNiArKystLS0NCj4gICBkcml2 ZXJzL2NwdWZyZXEvcG93ZXJub3ctazcuYyAgICAgICAgICAgICAgICAgfCAxMCArKy0tDQo+ ICAgZHJpdmVycy9jcHVmcmVxL3Bvd2Vybm93LWs4LmMgICAgICAgICAgICAgICAgIHwgIDgg Ky0tDQo+ICAgZHJpdmVycy9jcHVmcmVxL3NwZWVkc3RlcC1jZW50cmluby5jICAgICAgICAg IHwgIDQgKy0NCj4gICBkcml2ZXJzL2NwdWZyZXEvc3BlZWRzdGVwLWxpYi5jICAgICAgICAg ICAgICAgfCAxNCArKystLS0NCj4gICBkcml2ZXJzL2VkYWMvYW1kNjRfZWRhYy5jICAgICAg ICAgICAgICAgICAgICAgfCAgNiArLS0NCj4gICBkcml2ZXJzL2dwaW8vZ3Bpby1jczU1MzUu YyAgICAgICAgICAgICAgICAgICAgfCAxMCArKy0tDQo+ICAgZHJpdmVycy9odi9tc2h2X3Z0 bF9tYWluLmMgICAgICAgICAgICAgICAgICAgIHwgIDIgKy0NCj4gICBkcml2ZXJzL2h3bW9u L2h3bW9uLXZpZC5jICAgICAgICAgICAgICAgICAgICAgfCAgNCArLQ0KPiAgIGRyaXZlcnMv aWRsZS9pbnRlbF9pZGxlLmMgICAgICAgICAgICAgICAgICAgICB8IDI2ICsrKysrLS0tLS0N Cj4gICBkcml2ZXJzL21pc2MvY3M1NTM1LW1mZ3B0LmMgICAgICAgICAgICAgICAgICAgfCAz MyArKysrKystLS0tLS0NCj4gICBkcml2ZXJzL210ZC9uYW5kL3Jhdy9jczU1M3hfbmFuZC5j ICAgICAgICAgICAgfCAgNiArLS0NCj4gICBkcml2ZXJzL3BsYXRmb3JtL3g4Ni9pbnRlbC9p ZnMvbG9hZC5jICAgICAgICAgfCAxMCArKy0tDQo+ICAgZHJpdmVycy9wbGF0Zm9ybS94ODYv aW50ZWwvaWZzL3J1bnRlc3QuYyAgICAgIHwgIDggKy0tDQo+ICAgZHJpdmVycy9wbGF0Zm9y bS94ODYvaW50ZWwvcG1jL2NucC5jICAgICAgICAgIHwgIDIgKy0NCj4gICAuLi4vaW50ZWwv c3BlZWRfc2VsZWN0X2lmL2lzc3RfaWZfbWJveF9tc3IuYyAgfCAgNiArLS0NCj4gICAuLi4v aW50ZWwvc3BlZWRfc2VsZWN0X2lmL2lzc3RfdHBtaV9jb3JlLmMgICAgfCAgMiArLQ0KPiAg IGRyaXZlcnMvcGxhdGZvcm0veDg2L2ludGVsX2lwcy5jICAgICAgICAgICAgICB8IDIwICsr KystLS0tDQo+ICAgZHJpdmVycy9wb3dlcmNhcC9pbnRlbF9yYXBsX21zci5jICAgICAgICAg ICAgIHwgIDIgKy0NCj4gICBkcml2ZXJzL3RoZXJtYWwvaW50ZWwvaW50ZWxfaGZpLmMgICAg ICAgICAgICAgfCAgOCArLS0NCj4gICBkcml2ZXJzL3RoZXJtYWwvaW50ZWwvdGhlcm1fdGhy b3QuYyAgICAgICAgICAgfCAyMiArKysrLS0tLQ0KPiAgIGRyaXZlcnMvdGhlcm1hbC9pbnRl bC94ODZfcGtnX3RlbXBfdGhlcm1hbC5jICB8ICA2ICstLQ0KPiAgIGRyaXZlcnMvdmlkZW8v ZmJkZXYvZ2VvZGUvZGlzcGxheV9neC5jICAgICAgICB8ICA4ICstLQ0KPiAgIGRyaXZlcnMv dmlkZW8vZmJkZXYvZ2VvZGUvZ3hmYl9jb3JlLmMgICAgICAgICB8ICAyICstDQo+ICAgZHJp dmVycy92aWRlby9mYmRldi9nZW9kZS9seGZiX29wcy5jICAgICAgICAgIHwgNTAgKysrKysr KysrLS0tLS0tLS0tLQ0KPiAgIGRyaXZlcnMvdmlkZW8vZmJkZXYvZ2VvZGUvc3VzcGVuZF9n eC5jICAgICAgICB8IDI0ICsrKysrLS0tLQ0KPiAgIGRyaXZlcnMvdmlkZW8vZmJkZXYvZ2Vv ZGUvdmlkZW9fZ3guYyAgICAgICAgICB8ICA4ICstLQ0KPiAgIGluY2x1ZGUvbGludXgvY3M1 NTM1LmggICAgICAgICAgICAgICAgICAgICAgICB8IDEwICsrLS0NCj4gICAxMzggZmlsZXMg Y2hhbmdlZCwgNTc1IGluc2VydGlvbnMoKyksIDY5NCBkZWxldGlvbnMoLSkNCj4gDQoNCmFu eXRoaW5nIHlvdSBuZWVkIGZyb20gbWUgdG8gZ2V0IHRoaXMgc2VyaWVzIGludG8gNy40Pw0K DQoNCkp1ZXJnZW4NCg== --------------dtnWD0jmGt0coRzSWi6oU7rk Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------dtnWD0jmGt0coRzSWi6oU7rk-- --------------T4ZJp6Lhzy2IBIrjLpBsTTw0-- --------------axxK79NgUHTDoQRwnbgWpSYy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqxS/0FAwAAAAAACgkQsN6d1ii/Ey96 wwf/dV+nbtFwBzRTdTv3Vx2lVN89DL6TR+euiSyGZLTqPjp0pW5wAtoIwgj4xQNNKLWJK+HdGnQA uIpKCGhzndQjA5/bYZLYAk0U5OVc1x2RrasQn0vel7msJTFqjW6fl3XNodJ40rFbpqoOYqFxBOIq H0xe0vqCJ1u8yj9FZ5+NUOXlGprAqEgyUOFGWWrT237ejyqgKVVw6QS2d/7sDvXFyLeRkG6f/wfH eiUguWe063lhXObtP1J1YAkzAMJBkTuG39L6Tde54kqVIQyIbk9voL4wDHeNYvIpyd2Mk2GSZ+ha kni709pSh+qTNFkR5kCpypyUAeSKftAkqDpPz3fe1A== =q3Lv -----END PGP SIGNATURE----- --------------axxK79NgUHTDoQRwnbgWpSYy-- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 15:26:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 15:26:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427665.1650469 (Exim 4.92) (envelope-from ) id 1x8ful-0002Lk-UY; Mon, 21 Sep 2026 15:26:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427665.1650469; Mon, 21 Sep 2026 15:26:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ful-0002Ld-RV; Mon, 21 Sep 2026 15:26:43 +0000 Received: by outflank-mailman (input) for mailman id 1427665; Mon, 21 Sep 2026 15:26:43 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ful-0002LX-8h for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:26:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8fuk-002qWR-Lu for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:26:42 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab14ca3-bab6-0a2a0a5309dd-0a2a45078188-18 for ; Mon, 21 Sep 2026 17:26:42 +0200 Received: from [209.85.221.46] (helo=mail-wr1-f46.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab14cb2-b4ea-0a2a45070019-d155dd2ea446-3 for ; Mon, 21 Sep 2026 17:26:42 +0200 Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-48586861639so4460f8f.0 for ; Mon, 21 Sep 2026 08:26:42 -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 ffacd0b85a97d-487244608a3sm22580081f8f.8.2026.09.21.08.26.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 08:26:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790004402; x=1790609202; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=DdX4buUzE3yjIfRsl+nmkTj/01kjnaaILXJBm0HCW1E=; b=beMWcwYO5I/DfFnlfsSk1j7uzhYIepA6hUYZR7AsM7CV/SdTXf9+VOFyP5pEs+kqVv cNfWjLMUj0r21OUBeBUJy6WK3qWB1qE6jWuDYB0z59FL5GVZXbwhJxs8sAyWDqVa7e3M gYNDZzxOZrAn8Bep5uX7msqqcXll07U12GRMk6jP51MxR8gaQtDYJX9v98hnYv+A3R1v oljIaZEtik84UMQVtBFBXa+MCCBJ1Q65v2m5zUR9VR785Mv1hOig2vWADmvp0ijmUYAZ +GGNUPy9RNSBglieXLWyhQtccXFXsqlwiAKcss1PaDfIUzhbCHcioHHyhp/k1wOvd1Xq YguA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790004402; x=1790609202; h=content-transfer-encoding:content-type: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:content-type; bh=DdX4buUzE3yjIfRsl+nmkTj/01kjnaaILXJBm0HCW1E=; b=vXZ2XqmUcQ2IwOJ38wdm3DZLWcTEVXsJB0pGXL6qE7hZ+uA++nfKswd1TZfWKKPAwg a996ccqXttQCfPx6G8XiyQ79JgZ5ggi3I3RK4J46LCQseWrXJGpDcg9Ek+p2Ym29DkCU Aqg30TP2A/m9V7UnpHBMDeLqtwTfSoY/bWc+7ckELwUWEozUDWpdj3sjJj6P0JDPO4CL eRDf0Cc8URv3nZZtZYQbtn6vjhcTXLN+8Yx/1eoeFQKKDzSsBuNvyJ1oKh5g11BFO0Hx uJZsac+zY0oypF+qcsiJxJT4VCbdrNC2vXMT6D3WdQLfnJc9WXZfoGSCOL/58WqjyTi2 h+ug== X-Gm-Message-State: AFuF++k6has4capiCvwHKl4ryE6TBObPtEHeTGR8SHLxbJhlkLScngdv lWnvdmGqzTf6miEZ4HnYVX6ZXckffhZhn2kR1RMlliArUjpk8rTqrjco7tWfjzkR2w== X-Gm-Gg: AYBFou3KcckqqCzuqL1bZs1ttJAhuOuYWKhAFcFTI91OuY82JcVuIzC73ppPyJ08u2C TzjUrSrcdcqq7k4tN4bv/IpOxrBzdyO6cA2nOvckb3y0wGQekw9IVVvisRoTcJnFR/3budAViyp wr24ld6zrCuArSS+ob7BbfEk9J9IyyI8Z3VgOJguFnb+pgrTTA8ZTFGvisMSZuh9uM15bRkHhW+ EZXYH+Rj75RTvf1hHDYFKS/6i0KhAAaTIcy9kvCdq/M8XXXg400qMNrrhHJZMJcruC1PCLpXLyp blzvDiAExbGJjUhB5d7jMD/I5HDhMFW4nKarTL9C2j/XxeKUOKGmUKK/kY+FwZCTDGIJjAiL0UX hls4bMp9szHS2nPks71NHaKyuExfFoSJhZyz8Yuf1VozmKx4G9z8mEyNCvi+tJh2EXHUY+aUeL2 OLzI8TSGmjS753couUlr2h+KUhhSaqNMzrZW7VAJ9qtM8QUQli6nK6pqxSHbp8agVJTwoVR+PMf k823uyL2Vp0okb7WKvES8e4NMOYva37w8YerEaNn2IG5XiKLGNM9anPDAHO1A== X-Received: by 2002:a05:6000:41ce:b0:487:462:d85d with SMTP id ffacd0b85a97d-48713c47239mr22961648f8f.18.1790004401859; Mon, 21 Sep 2026 08:26:41 -0700 (PDT) Message-ID: <450d0c5e-2101-4b1c-98fd-2f438bd0ccf3@suse.com> Date: Mon, 21 Sep 2026 17:26:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> 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: <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790004402-368D9AE4-6A015826/0/0 X-purgate-type: clean X-purgate-size: 10629 On 10.09.2026 11:34, Baptiste Le Duc wrote: > p2m_set_permission() only presets the PTE A/D bits when the Svade extension > is present in the device tree. This causes an unhandled page fault when > neither Svade nor Svadu is present (the platform's actual behaviour is then > unknown), and when both are present in the device tree. > > Move the Svade/Svadu resolution out of p2m_set_permission() and into a new > riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). For each of > the four possible Svade/Svadu combinations (inspired by [1]), it decides > whether software has to preset the A/D bits and, if so, sets > RISCV_ISA_EXT_svade to record that decision: > - neither present: assume Svade, since assuming Svade is harmless on real > Svadu hardware, while assuming Svadu on real Svade hardware risks an > unhandled page fault > - only Svade present: assume Svade > - only Svadu present: leave A/D management to hardware > - both present: Svade wins until Xen supports the SBI FWFT call needed to > enable hardware updating of A/D bits, so assume Svade and warn that > dropping 'svade' from the DT is the only way to get Svadu. > > [1] https://lwn.net/Articles/980016/ > > Fixes: ff14053983b0 ("xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration") > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v1: > - change commit title > - expose RISCV_ISA_EXT_svadu so the two extensions can be told apart. > - move the Svade/Svadu resolution to a new riscv_resolve_ad_scheme(), > called once from riscv_fill_hwcap(). > - expose sbi_probe_extension() (was static) to probe for SBI FWFT. > - stop presetting A/D bits unconditionally in p2m_set_permission(), do it > only when Svade is present. > --- > xen/arch/riscv/cpufeature.c | 59 +++++++++++++++++++++++++++++++++ > xen/arch/riscv/include/asm/cpufeature.h | 1 + > xen/arch/riscv/include/asm/sbi.h | 8 +++++ > xen/arch/riscv/p2m.c | 47 ++++++++++---------------- > 4 files changed, 86 insertions(+), 29 deletions(-) > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > index 92235fdfd5..19454544a7 100644 > --- a/xen/arch/riscv/cpufeature.c > +++ b/xen/arch/riscv/cpufeature.c > @@ -18,6 +18,7 @@ > > #include > #include > +#include > > #ifdef CONFIG_ACPI > # error "cpufeature.c functions should be updated to support ACPI" > @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) > return false; > } > > +/* > + * Svade and Svadu extensions represent two schemes for managing the PTE A/D > + * bits. When the PTE A/D bits need to be set, the Svade extension indicates > + * that a page fault will be raised. In contrast, the Svadu extension supports > + * hardware updating of the PTE A/D bits. > + * > + * There are 4 possible combinations of these extensions in the device tree. > + * The default hardware behavior for each is: > + * > + * 1) Neither Svade nor Svadu present in DT => It is technically unknown > + * whether the platform uses Svade or Svadu. Xen should be prepared to > + * handle either hardware updating of the PTE A/D bits or page faults when > + * they need updating. In that case, Xen assumes Svade because it's > + * harmless if the platform is actually Svadu, while assuming Svadu on real > + * Svade hardware risks an unhandled page fault. > + * > + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. > + * > + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. > + * > + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off > + * at boot time by setting A/D bits. To use Svadu, the supervisor must > + * explicitly enable it using the SBI FWFT extension. > + * > + * The Svade extension is mandatory and the Svadu extension is optional in the > + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose > + * option 3. Platforms aware of the profile can choose option 4, and Xen won't > + * get the benefit of Svadu until the SBI FWFT extension is available. > + * > + * In other words, hardware manages the A/D bits on its own only in case 3, in > + * all the other cases software has to preset them. Instead of open coding this > + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is > + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. > + */ > +static void __init riscv_resolve_ad_scheme(void) > +{ > + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); > + > + /* Case 3: leave the A/D bits management to hardware. */ > + if ( svadu && !svade ) > + return; > + > + /* Case 4 */ > + if ( svadu && svade ){ > + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ Nit (style): Brace placement. Furthermore this is written in a way which Misra would call "dead code". I'd like to suggest (leaving out comments): if ( svadu ) { if ( !svade ) return; if ( !sbi_probe_extension(SBI_EXT_FWFT) ) printk(...); } > + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" > + "RISC-V: Defaulting to software A/D updates (Svade).\n" > + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); Nit (style): Indentation (in multiple ways). Furthermore XENLOG_* needs repeating after every newline. > + } > + } > + > + /* Cases 1, 2: Xen assume Svade to be enabled */ > + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); Isn't this a lie (to ourselves) then? > --- a/xen/arch/riscv/include/asm/sbi.h > +++ b/xen/arch/riscv/include/asm/sbi.h > @@ -30,6 +30,7 @@ > #define SBI_EXT_BASE 0x10 > #define SBI_EXT_RFENCE 0x52464E43 > #define SBI_EXT_TIME 0x54494D45 > +#define SBI_EXT_FWFT 0x46574654 > > /* SBI function IDs for BASE extension */ > #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 > @@ -138,6 +139,13 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, > int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, > size_t size, unsigned long vmid); > > +/** > + * Check if an SBI extension ID is supported or not. > + * @extid: The extension ID to be probed. > + * > + * @return: 1 or an extension specific nonzero value if yes, 0 otherwise. > + */ > +int sbi_probe_extension(long extid); > /* Nit (style): Also add a blank line. > --- a/xen/arch/riscv/p2m.c > +++ b/xen/arch/riscv/p2m.c > @@ -586,42 +586,31 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_cache) > > static void p2m_set_permission(pte_t *e, p2m_type_t t) > { > + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); > + > e->pte &= ~PTE_ACCESS_MASK; > > e->pte |= PTE_USER; > > /* > - * Two schemes to manage the A and D bits are defined: > - * • The Svade extension: when a virtual page is accessed and the A bit > - * is clear, or is written and the D bit is clear, a page-fault > - * exception is raised. > - * • When the Svade extension is not implemented, the following scheme > - * applies. > - * When a virtual page is accessed and the A bit is clear, the PTE is > - * updated to set the A bit. When the virtual page is written and the > - * D bit is clear, the PTE is updated to set the D bit. When G-stage > - * address translation is in use and is not Bare, the G-stage virtual > - * pages may be accessed or written by implicit accesses to VS-level > - * memory management data structures, such as page tables. > - * Thereby to avoid a page-fault in case of Svade is available, it is > - * necessary to set A and D bits. > - * > - * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI > - * delegates page faults to a lower privilege mode and so OpenSBI > - * isn't expect to handle page-faults occured in lower modes. > - * By setting the A/D bits here, page faults that would otherwise > - * be generated due to unset A/D bits will not occur in Xen. > - * > - * Currently, Xen on RISC-V does not make use of the information > - * that could be obtained from handling such page faults, which > - * could otherwise be useful for several use cases such as demand > - * paging, cache-flushing optimizations, memory access tracking,etc. > + * riscv_fill_hwcap() sets either RISCV_ISA_EXT_svade or > + * RISCV_ISA_EXT_svadu (mutually exclusive) depending on the Svade/Svadu > + * device tree combination (see riscv_resolve_ad_scheme()): > + * - RISCV_ISA_EXT_svade means that software is responsible for the A/D > + * bits. > + * - RISCV_ISA_EXT_svadu means the hardware is responsible for the A/D > + * bits. > * > - * To support the more general case and the optimizations mentioned > - * above, it would be better to stop setting the A/D bits here and > - * instead handle page faults that occur due to unset A/D bits. > + * Currently, when RISCV_ISA_EXT_svade is set, Xen doesn't track A/D > + * bits, so it does not make use of the information that could be > + * obtained from handling the resulting page faults, which could > + * otherwise be useful for several use cases such as demand paging, > + * cache-flushing optimizations, memory access tracking, etc. To avoid > + * such a page fault, Xen presets the A and D bits instead. > */ > - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > + ASSERT(svade != svadu); /* exactly one of svade/svadu must be set by riscv_fill_hwcap() */ Here I'm lost: riscv_resolve_ad_scheme() specifically handles the "both set" case. How can you then assert that exactly one of them is set? Apart from this the line is also too long and the comment doesn't match our style. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 15:28:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 15:28:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427673.1650480 (Exim 4.92) (envelope-from ) id 1x8fwc-0002uw-9D; Mon, 21 Sep 2026 15:28:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427673.1650480; Mon, 21 Sep 2026 15:28:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fwc-0002up-5f; Mon, 21 Sep 2026 15:28:38 +0000 Received: by outflank-mailman (input) for mailman id 1427673; Mon, 21 Sep 2026 15:28:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8fwb-0002ud-E8 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:28:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8fwZ-001fNp-Qw for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:28:35 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab14d09-8faa-0a2a0a5109dd-0a2a45099806-48 for ; Mon, 21 Sep 2026 17:28:35 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab14d1d-be1a-0a2a45090019-aceafc1f8d18-3 for ; Mon, 21 Sep 2026 17:28:31 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 18FDB42A04 for ; Mon, 21 Sep 2026 15:28:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1AD91F0089A for ; Mon, 21 Sep 2026 15:28:28 +0000 (UTC) Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-3a49a40209dso72161fa.0 for ; Mon, 21 Sep 2026 08:28:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790004509; bh=4ns94LogX5OA2pP65C8E1PBfvQ7/rCEkhv9gb+l2PE4=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=fu0cIiDQD/YqTDk1JAy5zclqVsYW+2AjMfmGi0g4fmMhZsovzfkIUp/mfOa2PgMNR g2oQwxBh8UFDVkFNNcONs2kKLkg2LAAqBaB2Ed+QwBSkoZrrMLhNZ51aBUv4MtUU4i nsRb3doYkD2eNFLNHYZDB9vLdiNx+xkBhF1mV+7WdXGJgtewIZqdNIuOBf6ruZxUQD vMb4ug3Sk2CTOFq1IRL19IJVZNWt8/HbNgCwLLg3clsBKEO2orufxth9zXFq57nqN1 UmUz26i+2SFaqoWVVxftYbTKufFW/BN08nnTiCPQJCQ85JibDVVdzDDqr8z56j04HN KJqm7XTlQJtjA== X-Forwarded-Encrypted: i=1; AKwUvBxC3VMzo9Mxm6RWkIAtvq7RzaZeV5nWD1zeXbxg0S/TdHG4EUEShwhLv95l51U/N/G3jnUnyUdfPxE=@lists.xenproject.org X-Gm-Message-State: AFuF++nR3SqgTZ3uV/2i4PsfwkoQtpKuEIYu2JrmOV7zPzUWjqr4M7DY tfqQoRva7pKVL/rK5SPLUY/ukaxPqIdh8FelnlMq28BESLJECTX6AkOJTPKEi4eGpy9stoNv1bC 25q4QKzL4dd42hydIL+vFrYtHz7UGcr4= X-Received: by 2002:a05:651c:a208:20b0:3a5:f142:af6e with SMTP id 38308e7fff4ca-3a5f142b0a9mr21380951fa.21.1790004507202; Mon, 21 Sep 2026 08:28:27 -0700 (PDT) MIME-Version: 1.0 References: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> In-Reply-To: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> From: "Rafael J. Wysocki (Intel)" Date: Mon, 21 Sep 2026 17:26:55 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1UxyJztudU9HEP_x1NXmMgrHZXRAKUGqrNcukJ4vaLpZv_8ujS2owei2hI Message-ID: Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot To: Support TRINITY Cc: regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Huisong Li Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1790004511-BEAD8034-F20C1AC6/0/0 X-purgate-type: clean X-purgate-size: 3919 On Sun, Sep 20, 2026 at 5:48=E2=80=AFPM Support TRINITY wrote: > > Hello, > > I am reporting a bare-metal Xen dom0 boot regression seen with Linux 6.18= .52. > > On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on bare= metal, while Linux 6.18.52 consistently black-screens before dom0 userspac= e/networking comes up. > > #regzbot introduced: v6.18.51..v6.18.52 > #regzbot title: ACPI processor/cpuidle lifecycle change breaks bare-metal= Xen dom0 boot > #regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/work_items/= 18447 > > Tested results: > > Linux 6.18.51-r0, Xen dom0, bare metal: boots > Linux 6.18.52-r0, Xen dom0, bare metal: black screen before userspace/net= work I'm wondering what's special about Xen dom0 bare metal. Does adding processor=3Dnocst to the kernel command line help, by any chanc= e? > Linux 6.18.52-r0, Xen domU: boots > Linux 6.18.52-r0 with Xenbus notifier change reverted: still fails > Linux 6.18.52-r0 with only ACPI processor/cpuidle changes reverted: boots > Linux 6.18.52-r0 with refined ACPI idle lifecycle patch: boots > > Affected hardware tested: > > Intel Core i7-4785T thin mini-ITX, 16 GB DDR3 > Intel N305 thin mini-ITX, 16 GB DDR5 > Supermicro / Intel Xeon E5-1650, 32 GB DDR3 > > The successful boot used the regular Xen command line: > > multiboot2 /boot/xen.gz cpufreq=3Dxen:performance > module2 /boot/vmlinuz-lts modules=3Dloop,squashfs,sd-mod,usb-storage,xfs = quiet > module2 /boot/initramfs-lts > > No IOMMU workaround, serial console parameter, debug parameter, storage w= orkaround, or Xen command-line change was required. > > The regression was narrowed to ACPI processor/cpuidle changes between 6.1= 8.51 and 6.18.52, specifically the idle-driver registration lifecycle. > > The working 6.18.51-style behavior registers the ACPI idle driver from ac= pi_processor_power_init() and unregisters it from acpi_processor_power_exit= (). > > The failing 6.18.52 behavior registers the ACPI idle driver globally from= acpi_processor_driver_init() before driver_register(). > > A first ACPI-only revert confirmed the regression source. A refined candi= date patch was then prepared to preserve the working ACPI idle lifecycle wh= ile keeping unrelated 6.18.52 safety fixes, including: > > _LPI bounds checks > cpufreq notifier cleanup on acpi_processor_driver_init() failure > > The refined candidate patch modifies only: > > drivers/acpi/processor_driver.c > drivers/acpi/processor_idle.c > include/acpi/processor.h > > It does not modify Xen, Xenbus, IOMMU, APIC, PCI/ASPM, intel_idle, syscor= e, USB, storage, XFS, networking, printk, or the cpuidle core API. > > The earlier cpuidle_disabled() workaround is not included. > > The refined patch has been rebuilt and boot-tested successfully as Xen do= m0 on bare metal on TRINITY-EDGE. > > This issue is currently visible to Alpine users because the Alpine v3.24 = stable repository contains: > > alpine-release 3.24.2-r0 > linux-lts 6.18.52-r0 > > Systems tracking Alpine 3.24 stable / latest-stable may therefore receive= Linux 6.18.52 as the default LTS kernel. > > Attachments: > > revert-acpi-idle-registration-lifecycle.patch > APKBUILD > > The original Alpine report is here: > > https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18447 > > Please let me know if this should be submitted as a formal patch with Sig= ned-off-by, or if there is a better upstream fix/dependency that should be = backported instead. The patch is essentially a revert of commit 13ebeef6a1b9 ("ACPI: processor: idle: Optimize ACPI idle driver registration") which I'd rather not do without knowing what exactly is going on. At this point it looks like a missing check somewhere or similar, so it would be good to find out where exactly it crashes. From xen-devel-bounces@lists.xenproject.org Mon Sep 21 15:35:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 15:35:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427681.1650487 (Exim 4.92) (envelope-from ) id 1x8g2z-0004VW-SN; Mon, 21 Sep 2026 15:35:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427681.1650487; Mon, 21 Sep 2026 15:35:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8g2z-0004VP-Pp; Mon, 21 Sep 2026 15:35:13 +0000 Received: by outflank-mailman (input) for mailman id 1427681; Mon, 21 Sep 2026 15:35:12 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8g2y-0004VI-TL for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:35:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8g2x-000524-0C for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:35:11 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab14ea7-e002-0a2a0a5209dd-0a2a4509c27a-12 for ; Mon, 21 Sep 2026 17:35:10 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab14eae-be1a-0a2a45090019-4a7de18cb9ee-3 for ; Mon, 21 Sep 2026 17:35:10 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd4ba9f68so43717925e9.1 for ; Mon, 21 Sep 2026 08:35:10 -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-49fcd115dcbsm234844005e9.15.2026.09.21.08.35.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 08:35:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790004910; x=1790609710; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=zqH4ELkHW3x44HV78MoN5EZNURTa3QJZ+kK8Ogv0hM4=; b=LKHEmCuZTvJKqn/oZ3IcXfMjm7to93+ykZ2g0JfDAMnQ6LSp+x5IZmZfSn6XglXyE4 /Ifg2Ub00J+ZmysTjB4QKsDbpk/BeBINnSURfX67cTz41SKN7taoaM0vriUMVjGg45NC jsnXdzbfLseO7Cw1Eb3fMYIWMADjgnEOwNBJ5qeqdlTBY3RerR5as+9imGYlV+20UHF+ CZgrFtIbgjIeolEZNjWh8Aq+WCi0nmKYMY4ugL97DCPwglWHSvMGzlqJv3ECjPfGT4pG 4hI8IbYaG90FSsnQeEGXzg9k38DCRv6piymSjG756vm0Q1ZTxH64c+/d6xcDG92i2PiZ /qXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790004910; x=1790609710; h=content-transfer-encoding:content-type: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:content-type; bh=zqH4ELkHW3x44HV78MoN5EZNURTa3QJZ+kK8Ogv0hM4=; b=SRppkVsHHXsk3AAB3utsVwY3zR91u20Hf8HOQBNbkURD/9rVBpXj4E2AwAx7zeBXKC 9+e2o1zPiJl4kmw1PWr8Up+IdDbcvcmaOwSPHl0AGjYaY/wojsMtntlQrwfmnh7PmsHv X21/qBv+iGIqGtCxyXZKmZRPEprxv8jXLuBx0hWtuUwX4JgSIveFcGU1yIEqVb9cBMrp /CqXCpv/QCPqfh0wgTXpnt4RnevxnQA3TyBUv8SQj30IRW++GahnDZWNQhsGitEPQI0D ITLq3+VEVSpjRCSa8KQHWrXxTMsNEiN93Ge2NPu+QsqOqZ880OJrLZ4om6IXKciHikpH UvKQ== X-Gm-Message-State: AFuF++lt3FOsuWB2M66lsMBaWrEdi+r0XzRGm4Y8UruCCmmiJr5XKP8G V0jthYpn9QC+wPh+8wR0rfB20cEM9ri2Jfnk/nVEdzUhyaXTM2UwP6+Per5WO8LNUQ== X-Gm-Gg: AYBFou04PHpBzMQ7Qfq8CroMa1SpW4y6NJslNUmkikHICqMQqjVubF3uhjThjf2Q4Gd 8W++8HitZR/+iudQLOVEHPUA0FiOTquTVaE0mJ0rtHVT2aN/vuVdZX3RN2bFlOZm30PLcN3f/9I 8PeyrDucgIHjcWOcQY1fI1Z3zC9AFJFXCNm+1qq4nlW8Cc4qu4fw1WDpvwHSOMBasjfOtT7eqdU FgHUY1tem2JXTzzCumS5rBi4SJgwuU6YARxtsUBVn10SQlez2g2qjWQ8A2SPejrIZXbIETbdFmB OCmUqJjAsf0HwoBmeATxUCkZUQevVCDHHwQwVOn2zgtabVzoBaGMarmvngOqMTykXgBrWQ0RvnP 5G+HbxU8wUNR4vbPElrD/lS+YRXuazlUHhv0P+mCxOfNl3Bc9xOwyODtZEH0HkdDv6u3u/nkN0Y icUwnw3cqXk/P4C5RC02pDalcLPzM4Lv+K9RAiXy1Z1uNkuSsnj58pUKHTW52PLgzhAEKbKtBoE yaOQjZkz3yM0TN/BxbaKdS92PmrpNcPFPlTqzcTleML+OYeIU6MMpznYMSfh3x0Pql0igSu X-Received: by 2002:a05:600c:358c:b0:499:be2d:c290 with SMTP id 5b1f17b1804b1-49fc56b4ebemr190181535e9.9.1790004910250; Mon, 21 Sep 2026 08:35:10 -0700 (PDT) Message-ID: <925a17b9-2be0-441a-b49c-8a8bbf51d633@suse.com> Date: Mon, 21 Sep 2026 17:35:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] xen/riscv: set A/D bits in Xen's page-table mappings under Svade To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3@vates.tech> 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: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1790004910-3B2DC034-C787A5C4/0/0 X-purgate-type: clean X-purgate-size: 840 On 10.09.2026 11:34, Baptiste Le Duc wrote: > The previous patch set A/D bits in case of the Svade extension for G-stage As I think I have said before - no "the previous patch" or anything alike please in descriptions. > --- a/xen/arch/riscv/mm.c > +++ b/xen/arch/riscv/mm.c > @@ -140,7 +140,7 @@ static void __init setup_initial_mapping(struct mmu_desc *mmu_desc, > case 1: /* Level 0 */ > { > unsigned long paddr = (page_addr - map_start) + pa_start; > - unsigned int permissions = PTE_LEAF_DEFAULT; > + unsigned int permissions = PAGE_HYPERVISOR_RW; The variable was already not named entirely adequately, as PTE_VALID is only somewhat a "permission". Now it clearly holds more than just permission bits, so want to be given a better name. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 15:56:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 15:56:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427694.1650496 (Exim 4.92) (envelope-from ) id 1x8gNo-0007aN-K6; Mon, 21 Sep 2026 15:56:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427694.1650496; Mon, 21 Sep 2026 15:56:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gNo-0007aG-HW; Mon, 21 Sep 2026 15:56:44 +0000 Received: by outflank-mailman (input) for mailman id 1427694; Mon, 21 Sep 2026 15:56:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gNm-0007aA-TG for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:56:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8gNm-00546Y-72 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:56:42 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab153a8-bab6-0a2a0a5309dd-0a2a4501cada-24 for ; Mon, 21 Sep 2026 17:56:42 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab153b9-5984-0a2a45010019-a06583089440-3 for ; Mon, 21 Sep 2026 17:56:42 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 170CC44B8956; Mon, 21 Sep 2026 11:54:39 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Abdelkareem Abdelsaamad To: xen-devel@lists.xenproject.org, jbeulich@suse.com Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: Re: [PATCH v4] x86/nSVM: Check injected event consistency Date: Mon, 21 Sep 2026 16:50:56 +0100 Message-ID: <20260921155103.3243475-1-abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790006202-1E867757-AD78F3BA/0/0 X-purgate-type: clean X-purgate-size: 5890 On 07.09.2026 08:50, Jan Beulich wrote: >On 06.09.2026 15:11, Abdelkareem Abdelsaamad wrote: >> On 26.08.2026 15:33, Jan Beulich wrote: >>> On 23.08.2026 18:11, Abdelkareem Abdelsaamad wrote: >>>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>>> @@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) >>>> svm_dump_sel(" TR", &vmcb->tr); >>>> } >>>> >>>> +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, >>>> + uint8_t vmcb_injected_vector) >>>> +{ >>>> + switch ( vmcb_injected_vector ) >>>> + { >>>> + case X86_EXC_DE: >>>> + case X86_EXC_DB: >>>> + case X86_EXC_BP: >>>> + case X86_EXC_UD: >>>> + case X86_EXC_NM: >>>> + case X86_EXC_DF: >>>> + case X86_EXC_TS: >>>> + case X86_EXC_NP: >>>> + case X86_EXC_SS: >>>> + case X86_EXC_GP: >>>> + case X86_EXC_PF: >>>> + case X86_EXC_MF: >>>> + case X86_EXC_AC: >>>> + case X86_EXC_MC: >>> >>> Is #MC valid to inject without CR4.MCE set? >> The testing I performed (see previous comment) does not show that set CR4.MCE >> is required for the valid injection. > >I find this worrying. Roger, any chance you could try to find out whether >that's perhaps more an erratum than intended behavior? > I believe X86_EXC_MC was introduced long before AMD CPUs with SVM. Therefore, on all the SVM-capable CPUs I am targeting, it is valid to trigger this exception vector regardless of whether the guest has explicitly opted in for the capability. That said, if Roger can double-check and confirm this behavior, it would be highly appreciated. >>>> + return true; >>>> + >>>> + case X86_EXC_OF: >>>> + case X86_EXC_BR: >>>> + return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l; >>>> + >>>> + case X86_EXC_VC: >>>> + return vmcb_get_sev_es(vmcb); >>>> + >>>> + case X86_EXC_CP: >>>> + return vmcb_get_cr4(vmcb) & X86_CR4_CET; >>> >>> ... e.g. here. That is, if a CR4 (or other) check is needed here, but not >>> for #XM (or #SX), that's surely worth (briefly) commenting upon. The more >>> that, afaics, none of this is spelled out in the PM. >> In my testing, the hardware behavior differs across the generations support for >> the Control-flow Enforcement Technology (CET): >> - Naples (No hardware support): Injecting the event when the feature is >> completely unsupported by the CPU results in VMEXIT_INVALID. The VMCB's CR4 >> bit is not set as it is expected. >> - Genoa (Hardware support exists): If the CPU supports the feature but the >> guest has not enabled it in CR4 (not opted-in), injecting the event >> results in a triple fault. I am accordingly checking for the CPU feature and >> report it as invalid. > >A guest triple fault, I assume? Yes, that is correct. I meant a guest triple fault. > I'm not entirely convinced this is a sufficient >indication of injection being permitted, even though I agree it very much looks >so. Then again, like above, I'm also unconvinced this is actually intended >behavior. Guests unaware of a feature (and hence not enabling it) should never >observe exceptions related to only that feature. The testing, I performed shows the following behavior across the CPU generations: - On CPUU generations that support the feature (e.g., Genoa supporting Control-flow Enforcement Technology / CET), the injection results in a guest triple fault. If the the guest did not opt-in for the CET feature. No VMEXIT_INVALID results by the injection. - On older hardware generations that completely lack the feature (e.g., Naples), the injection immediately results in a VMEXIT_INVALID. The current hardware behavior seems to depend on whether the underlying physical CPU understands the feature, rather than whether the guest has opted into it via CR4. The patch expands this to consider the injection will result in VMEXIT_INVALID if the guest did not opt into the feature. Are you suggesting to reather explicitly check the CPU model/generation instead of checking X86_CR4_CET? For example, allowing the injection on Genoa platforms regardless of whether the guest has enabled the CET capability? I am concerned that handling this via CPU model checks might introduce architectural edge cases and/or add maintenance complication—what are your thoughts on that approach? >>>> @@ -392,6 +436,20 @@ bool svm_vmcb_isvalid( >>>> PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n", >>>> vmcb->event_inj.raw); >>>> >>>> + if ( !vmcb->event_inj.v ) >>>> + PRINTF("eventinj: valid bit is not set (%#"PRIx64")\n", >>>> + vmcb->event_inj.raw); >>> >>> I understand the parentheses in the log message here. Yet ... >>> >>>> + if ( !((1 << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) ) >>> >>> If vmcb_injected_type really could take all possible uint8_t values (see >>> below), this shift would be at risk of becoming UB. And uint8_t is a >>> stronger hint that all possible values may appear than unsigned int is. >> I am OK to change to unsigned int for safety with future possible extensions. >>> >>>> + PRINTF("eventinj: Invalid Injected Event Type: (%#"PRIx8")\n", >>>> + vmcb_injected_type); >>> >>> ... what purpose do they serve here (and below)? >> I did it just to go with the previous format but I am OK to drop in v5. > >You did notice the difference in message type, though? Where parentheses >are used in existing messages, the values put there serve as auxiliary >information to the wording used. Whereas here you plainly dump a value, >without saying what exactly is wrong (that's actually said by the value >dumped). Got it. I will drop the parentheses in v5. From xen-devel-bounces@lists.xenproject.org Mon Sep 21 15:57:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 15:57:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427698.1650506 (Exim 4.92) (envelope-from ) id 1x8gO6-0007rz-QR; Mon, 21 Sep 2026 15:57:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427698.1650506; Mon, 21 Sep 2026 15:57:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gO6-0007rs-NY; Mon, 21 Sep 2026 15:57:02 +0000 Received: by outflank-mailman (input) for mailman id 1427698; Mon, 21 Sep 2026 15:57:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gO5-0007r5-B1 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 15:57:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8gO4-0078y9-1g for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:57:00 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab153c0-8faa-0a2a0a5109dd-0a2a4508a5ba-12 for ; Mon, 21 Sep 2026 17:56:59 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab153cb-f659-0a2a45080019-4a7de18cdc63-3 for ; Mon, 21 Sep 2026 17:56:59 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ce364488dso8635595e9.0 for ; Mon, 21 Sep 2026 08:56:59 -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-49fcd07cca6sm236288425e9.11.2026.09.21.08.56.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 08:56:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790006219; x=1790611019; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=jUtow8Uf9yxDMJ8PoFWIAMmTgPt2YQ5jPZTRbsIUPBo=; b=IdXcf2dw6n9Uj/n8STn0D5SnpoFHYXxWSliNJHVyO8w6rseLHBzwBIMuh5DBZ9ahd3 AS5DsCJk+YMw0VQ4fMcq/9/F6V0hUaZ9rEBzWDcKFusn+v+ryVu5cS2/bpAis80in4JF +0OcugkUXSdw8qs3VD/GBXm99tLGaMB7sypMqc1/xvhyU/VCfB47womVhJL4CMOJbUjf Ea3WRCaHlJmMPD9mtK99wV8Nh/VJepvZPrwmF0IW1to8oCeCyKEmjAN8tJciuQzLEBR3 nIKwZsOroDpH0mn4bOLsxlyMILQn024GKLA9fUAD2VWn7LlWVfVduBUmh/41XMotcPQ3 E04A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790006219; x=1790611019; h=content-transfer-encoding:content-type: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:content-type; bh=jUtow8Uf9yxDMJ8PoFWIAMmTgPt2YQ5jPZTRbsIUPBo=; b=VkIc5RZJVdxe0HwggqqYZKfhnTpkhP3FmKzZDV7p5RSSn4SQPxy+nMQOdNy4lGLi+f Tp8W9Au57/tOHrdF18E6tvPN3kX3gBTKFHGphNDfLVfD9YI2ORRvja9yLuREFo8PfzOT ZYiMpVj/Z6ZgmVY3Jd/OtJ1X+ZXivnOp56Ex+dUnHsv11tuwHsUIQRezu84XwNbdHLo9 4gf1LqPLv/XLwaur+eVoysLQwgcyp8tW7hsUqM5h/nxT0PRj8Uvuz+P7Ntk/puo/D0hY P2BC8OhDoKVIC5bPMj6mZStXy7ZOLpB/nYgWHxKg9byZiWNTbIvPruWIuynAazAMmz0T yumQ== X-Gm-Message-State: AFuF++koOsUhKfD+YdwMZyx1eZpbNIuR22MAda3CnEU3ETH4hzx08/l5 N/9o8e4mQZQrpIFRtddciKsgY/5ATHdjdFoaHm2HCP40DTalKWMGLkjQpWFsMLhF/A== X-Gm-Gg: AYBFou3o2ZnstTrWtGPNHHZcgv1axYpz86kPkqJkccQ1sQ49/A5+CxBE5k/v/DvHbaC tG5OVr1W+i7EcR8Y2Vcs07WYYZIRh/cnhaZ5c1ksiJ2vakGuHRcDjFiS15yrq+d65VrVVvV03Zl Mj/j/xp8m79pF0jjQ3b7ieA35LfC8VFi+rszHTw1POxnllz4al/KWy9VvF03B9CHjPMKfSmdlTu 344pA2aO/Hr0zGkTcrs8MbLdKmGLg1edaTyMX4bu6cH6udaCGj9cHv/PoMlgDRs7JE2WGRP1C3y +2cXb4NcK4cLkEtBQg+5bpyG7jsAy2trSN6xU/7IG/p8um+cdUCtg8sFF6nriF4QxXmNOHGbE6P Uctps2RM9T+0ko18/eGp1Ssng0kDlOP7I/M9NMQHP7+xkUhVJ4QakSYJiXo4QpDTtkMCmeRda33 TxZGBmxB6tiBNMrC5xMt2qggiyr5UfZw1beoH9MRkAFzCTKvGjgQAimJmCjwPALUnPZfZUQ5gqp RL0+heSIxpAXT2wvxaHghIgZ0SsN5YysPHcLZ05jOvWXFXzkb9G0NIIyiC2aw== X-Received: by 2002:a05:600c:3e16:b0:49e:715d:95ca with SMTP id 5b1f17b1804b1-49fd8a69266mr755935e9.13.1790006219373; Mon, 21 Sep 2026 08:56:59 -0700 (PDT) Message-ID: <9ea9edfc-be76-4507-8b71-a483daa9e7d5@suse.com> Date: Mon, 21 Sep 2026 17:57:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/6] xen/riscv: make Svpbmt no longer a required extension To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3@vates.tech> 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: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1790006219-CF95A87B-E12904DB/0/0 X-purgate-type: clean X-purgate-size: 4312 On 10.09.2026 11:34, Baptiste Le Duc wrote: > Without the Svpbmt extension, memory attributes (such as cacheability and > ordering) are strictly tied to physical address ranges and enforced by the > hardware's Physical Memory Attributes (PMA) checker. > > In this configuration, supervisor software relies on the platform's memory > map: > - peripheral device registers (MMIO) are physically mapped into > hardware-defined I/O regions (which are implicitly non-cacheable and > strongly-ordered) > - regular RAM is mapped as cacheable main memory. > > S-mode paging can safely map these physical ranges without specifying > page-based memory types in the PTEs, as the hardware MMU and PMA pipeline > will correctly bypass caches for MMIO accesses and use caches for RAM > accesses, based on the target physical address. Provided firmware got absolutely everything right. > Furthermore, on platforms that either feature fully hardware-coherent DMA > or don't expose non-coherent DMA agents to the OS, page-level programmatic > cache control via Svpbmt is not required, making it safe to boot and run > when Svpbmt is absent. Yet a fully coherent platform should also be possible to somehow identify? > Drop Svpbmt from required_extensions. Introduce svpbmt_enabled, a > __ro_after_init flag computed once in init_csr_masks() from ISA > availability and the henvcfg.PBMTE bit. Xen cannot read menvcfg.PBMTE > directly, since menvcfg is M-mode-only and unreadable from HS-mode, but the > spec guarantees henvcfg.PBMTE reads as zero whenever menvcfg.PBMTE is zero, > so checking henvcfg.PBMTE alone is sufficient. I don't understand this logic. If menvcfg.PBMTE is non-zero, we know nothing about (or from) henvcfg.PBMTE's setting. > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -47,6 +47,8 @@ static struct csr_masks __ro_after_init csr_masks; > #define HENVCFG_VALID_MASK 0xe0000003000000ffUL > #define HSTATEEN0_VALID_MASK 0xde00000000000007UL > > +bool __ro_after_init svpbmt_enabled; > + > void __init init_csr_masks(void) > { > /* > @@ -79,6 +81,10 @@ void __init init_csr_masks(void) > INIT_RO_ONE_MASK(HSTATEEN0, hstateen0); > } > > + svpbmt_enabled = (riscv_isa_extension_available(NULL, > + RISCV_ISA_EXT_svpbmt)) && (ENVCFG_PBMTE & > + csr_masks.henvcfg); Line wrapping wants doing entirely differently here. One of the style- conforming options is svpbmt_enabled = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) && (csr_masks.henvcfg & ENVCFG_PBMTE); > --- a/xen/arch/riscv/include/asm/page.h > +++ b/xen/arch/riscv/include/asm/page.h > @@ -11,6 +11,7 @@ > #include > > #include > +#include > #include > > #define VPN_MASK (PAGETABLE_ENTRIES - 1UL) > @@ -42,7 +43,21 @@ > * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > * 11 - Rsvd Reserved for future standard use > + * > + * These bits are only meaningful when Svpbmt is enabled. Otherwise they must > + * stay 0 (PMA). > */ > +extern bool svpbmt_enabled; > +static inline unsigned long pte_pbmt_nocache(void) > +{ > + return svpbmt_enabled ? BIT(61, UL) : 0; > +} > + > +static inline unsigned long pte_pbmt_io(void) > +{ > + return svpbmt_enabled ? BIT(62, UL) : 0; > +} Why open-code ... > #define PTE_PBMT_NOCACHE BIT(61, UL) > #define PTE_PBMT_IO BIT(62, UL) ... what is still available here? > @@ -53,6 +68,7 @@ > #define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE | PTE_ACCESSED) > > #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW > + > /* > * PAGE_HYPERVISOR_NOCACHE is used for ioremap(). > * Stray change? > @@ -82,7 +98,7 @@ enum pbmt_type { > > #define PTE_ACCESS_MASK (PTE_READABLE | PTE_WRITABLE | PTE_EXECUTABLE) > > -#define PTE_PBMT_MASK (PTE_PBMT_NOCACHE | PTE_PBMT_IO) > +#define PTE_PBMT_MASK (BIT(61, UL) | BIT(62, UL)) I don't understand the need for this change. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 16:00:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 16:00:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427717.1650515 (Exim 4.92) (envelope-from ) id 1x8gRB-0001bh-7e; Mon, 21 Sep 2026 16:00:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427717.1650515; Mon, 21 Sep 2026 16:00:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gRB-0001ba-4h; Mon, 21 Sep 2026 16:00:13 +0000 Received: by outflank-mailman (input) for mailman id 1427717; Mon, 21 Sep 2026 16:00:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gR9-0001bU-Eg for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:00:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8gR8-0054h6-Rc for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 18:00:10 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab15474-2eae-0a2a0a5409dd-0a2a4501a538-46 for ; Mon, 21 Sep 2026 18:00:10 +0200 Received: from [52.101.56.9] (helo=BN1PR04CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab15484-5984-0a2a45010019-34653809fded-3 for ; Mon, 21 Sep 2026 18:00:05 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB8253.namprd03.prod.outlook.com (2603:10b6:806:460::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Mon, 21 Sep 2026 16:00:03 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 16:00:03 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fLRz+PsGzZtMdYYpuh0sDGb3eyoC0SmzXufAIgUR81suGyU/6dsN+p0SOK3PRITzGTynjeKfPWoOWTRPaGpsMWPtvOhSR9miFI2mHixpUZmGFTiiOUWzUkUorPHHqdxfob/AdmmabtMZ94BcT7Y469fP/2Bbg23d6D9nZLggDoaX2YNDSVsD0A7k8eaeW5w4XNBgIHKwCCWkibLu0aq3RmC8yKWoBQM9NQUEralDXAzQgOrDHW6aypuKiNpzrOnx7kgWQ36vzXRWJIWRf8Q+WdC+po6nAjGIkLC3d+FuWtvU3VOanBB//vcM2GR2aLFh6FOik3HUqeKVOsh9sFU0jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3OhYU2mB4nT2Ah5/JwcFnN31S/X7UCpA604MkY/mE3w=; b=ql4MXFcnUcZHbPC9fr5aS8iWZCViX5wkX5DfeXlGEdZ6aeWIwo4AOx4IN7f6Tb9ztlVyItTEu6oyVPaQr/w/PeQ0FsGovDUy/c2rF7UelowAFOZUy/gR4IBAsz2HI6rHMDsyv8Io79l/06rrtOHtmhKkjzNcNqzEv1JPK+JCn/N9bdgBSnoSAM2H75WYaWiUPrpsS4a1xzV7X1WQx/fwPT/9F9JqkElNBnpPC97gVCr3mM/8Ix0BqnESl7NiqE1CPPrUAWEpTgps8bEUo8f4ZExnlMxGC3j3MUz9OApl2Rbg5PFRQ81gCLuRC3A/BNTjWt7fUkFam+dee9HsZbUWXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3OhYU2mB4nT2Ah5/JwcFnN31S/X7UCpA604MkY/mE3w=; b=DidH0/H0W+cBbsr92NS6y69cVLtRtWuDKJenfpqr2oNzr8xkosfc51wlcgba0sUQaNwhyUmxVo6XCY4i0ln2CjMHIlTyui2NIF2wYG4zcMmf94EsTBMtIqd+qS38lxa1VLwJVu1XfWZDGcogwBbp64tqMh20Hdf87oJUF9K7znA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1cef5505-79f5-4319-8334-d3ee809bde7d@citrix.com> Date: Mon, 21 Sep 2026 16:59:59 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH] x86/vpmu: Fix incorrect printk format specifiers To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260921091651.34761-1-alejandro.garciavallejo@amd.com> <489f6ce6-2be7-4c94-bcf0-21fc6993f98c@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO6P123CA0030.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:313::10) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB8253:EE_ X-MS-Office365-Filtering-Correlation-Id: aa44f648-ff41-465b-f834-08df17f96590 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|10067099003|11063799006|4143699003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: epkqAdUmssvIxVMPyMC5DaoiPL2K96wYqsN5UM/QYPSvBR6mt+vnijASG/g9ojeDG+9aFuU02peogOqUPGrDU9jHaDu3Drjsqk0oGH/SfqDOQBioFuryTuKRRdPtIuZXHtF9O1Oq8NvCbx4tCIcUqqMJdzxb13bekGcsx7txGUA4loV2M0uVCZgcWSPmM7BMvvNksJxlIzIzUU6WaP7/YMp/4v7Kprd0lMtSXPwRlENddn/AwE0aSeuGqmYvouCYUCSVoBGrxvPrRZrpEumiv2LoqUn1LpYpsObu+Femybax+OtlrhiVpJXt2WTDwfrG0zOqB6m+T2D1+kWMFSMJQUo8xJ4eWB0QIFBQubdD5okJHJMJRau2LaHisk76jLWvFahVBeZZSqIR4uBqtQMQu7UmP10QWqLOmtNaCsHHRvPugavJY7edi0FDaeFI6jJZwDNrbGK2V/4ek9sroIqPE5aMJiVgYpcNdqK7KF2zKFiTrnM8nhzokfsrV3YU6gQXkzuW/gxBBuac2ygQhI9Km8eZ0JjLhC+RPWdR1BuSi1qBTtNeGUto+Fm5KPQ36C7RfgD6i4uWq227T/4bVLO9GxnhYgUOEdGCxymzLp6qLqineznqYlbSd2N8zFQaBpemrcL4Dq3qEhoTzHYFjSquUWpnGS0tTIGcICdjf5+xz1k= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(10067099003)(11063799006)(4143699003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VkE2QWVzU1JkSmhCMXZTSHlqQ3lUZjBicjFqOExVOEQzb1NMaVp5NXBTclpj?= =?utf-8?B?eURDQ3FPdHlzN2hvTWtNMWtiOUlUMmUxZkZXMmJ0aGV1NDhtQVpoS0IyUEVX?= =?utf-8?B?L3hXVldzQjhqa1NYbTYwOWNZdnVEVmNLVTlOdFJ0UjdzeUE0VFhhY3lhWEla?= =?utf-8?B?S1JWeVZoaWZzbVJsVysybmp4Q3JQK2gxNWlmVjVTVnZRWmpHdFpCRnFEQVdO?= =?utf-8?B?Mkl3anNaZ0RUV0pXRXF5NE5lRk80cFI4eXhPcjNZelg3dzkvUHhuOXp2UDJP?= =?utf-8?B?MVdteHAwTkwyRXBMVThrZnd1NXNNSURyNTZ4a1NyU0VRdU1ZV1prdXNyNE9t?= =?utf-8?B?eEU4dUFkNStPL2xBZTVUamlPckJQZ1hvaW1HMkdjYm9Ea05aZVA0R2pNNExK?= =?utf-8?B?alpPckhHZllGdWlybWtSa0ZxMzh6M0pIbkc4cmRUMTRmdTZjZFFXWWdpSjVo?= =?utf-8?B?Zlg2MXRiSGlBN2Z1RlhMOHZxNHpKdDEyWEo0ZmVkdU4xVTVtNXZkNTVkd2hK?= =?utf-8?B?U3Y5bzBZdjBBUGdsWS9XVTlvV2Q2OU1uVnNLS2szT3FaK1FFWnJSNUtPSGlB?= =?utf-8?B?b0tadklLdE8xQm9tYnpCbXhLQi8rbUJxUGdwbXRDdkcxTUZQOGt0aUl2ODNO?= =?utf-8?B?dFNGanQ3N0Vtd0srMHhJMUo1dVRZU2JxSzk2M044SVo5TmExeW5xS0w1Vkh1?= =?utf-8?B?dXh4bGlzVmdUTEcrVHNaek5pcGdvSUNDc1JTYjl4YU9KSm0rQnRGZG1tV0pl?= =?utf-8?B?N1JGUnJIYWRMZDAxemZQT21KTE10WmxIbUhLaVFkYSt3alg2bGV1bG1QWnAz?= =?utf-8?B?Y1luRi9Jb3VNMTdIQk9IYXFpU0lVeUNobm0wWlRyenVwWEl4aC9QZC9IOVVk?= =?utf-8?B?V1ppUkRiUjVSQzlQNHpPVmRNbXhuYkpxL2YyUDFOS240eTdBcTBKVFZ3WHhD?= =?utf-8?B?ZERDSFUzQ0FDVDlVT29CQi9DTXg0Rkhua2l2MGNtYjVoa1BwS1JjVkc4TWR2?= =?utf-8?B?NE9OYlQzZW1YRnI5cDhSODAvMTJTK1dxMldxbVI3cnROZTFzckNWdjRUV1U5?= =?utf-8?B?UHk3ZytHdTI3RGd2RHQyejFSSzZ6YWxWRDZoSzhidEZWanFUT0h1YjRVMDFX?= =?utf-8?B?dXBFLzBheW5OK3NkcmlqWWNFd3hTVGkzdUVzdW9WdXVtVU9RaGttTXVVL0lj?= =?utf-8?B?aEtnTkdib1lGMHpDSE5RTmQ0S05TZGl5RTJnQm1MaUxnNTBlckVXSXV5OHVG?= =?utf-8?B?STI2TnA0VWR5M0JWblpNekh5SE1lQ2x5bnJVY2FsRG5mVFFxYkxzamJhdzRU?= =?utf-8?B?dzFaVTkyeEY3NnJ6OXY0V00yUVlTaVdhbi9UckJZTE0zdjk0c05nKy9vdW1Q?= =?utf-8?B?ZEFuMjZvOE9qRVdQd2IyT3F0MjlMOEZUMk14RTRMYWsvOFVFQ3dkQ1NJbEly?= =?utf-8?B?Rm95NFY1WE53TXJ6aHJpbStsd2FWV0svTHFoajBkU3RDTzYrM0EzN1VSMWgx?= =?utf-8?B?V2NnRFUrRm5lVVduZng3blc3ZzZRK0xOZWhIcU45ajQ4eWlKNUd6bnlVTlZ2?= =?utf-8?B?KzRscDRWMmJYVmJDb0U1bVFnK0ZIaXdpOUsyNzFLQ3QwQ05KYjRrN3RwMFBo?= =?utf-8?B?N0lqaHhOV2pPNmUwU3hnalZrM3djWjhmK0h0RGdNazBNRlZ3R3RXTDdyMStW?= =?utf-8?B?alUzbGM3RzFoZFg2MmFzT0lMR1JlTzl0akM1NFJSdXZ3Z0NPejBOeUpMWnlD?= =?utf-8?B?T1JpK2plNERPSFdkRk95TmF0MGVVdU1hdlVDOWxwRWxIWTNQTFJNYVJCZ2Rn?= =?utf-8?B?bC9BalFBNWRRQTdnMGN6ZFI3Um1wNEdhc09WUkVHTzRtTGlhSHQ3d29uUGxO?= =?utf-8?B?L1JrM3oxUXFESkQzYnFqZjMrRlpQY2JTenBkMFJ1SXQ1Z0pDRUZpc3orSTU0?= =?utf-8?B?aFZxUXJPV0hCTFdkUStVeXNQM2dpRGFONEZsY2VyWktFQ2F6MmVvc1d2U0Fz?= =?utf-8?B?S0tGSE9IdFBhR1VpVWNUMkR5UVVBRWRzM1QzTERXSTRNdTYxcGpHc2FMclNj?= =?utf-8?B?SE9tS25mOVlybjdLcHBBNnhGWGNCTER1cVRXVFdMQzkrV2dCL2c1MGxoc2c4?= =?utf-8?B?a1J4bk1STVRvNmtkalQrZ0cvTEdwVEF3ajd5SVRFUVZxWFFqRDZyV0Fzb29H?= =?utf-8?B?UnAwcUU4Y01NaGVlczNIaEhZNDNSWlg3UmpPeHk4SVMybFdDUUMyOWhLdDFh?= =?utf-8?B?RGNYbEowUTlmbThjQUVGcHE5UEpVdzBsQkgyZVJIdmJ3a0p4VkI2REJ3b0Fi?= =?utf-8?B?TWdId1RTWXBZOEFDSmY3QmR2WWVuWFpSaFZ5b0tadSs1MTRxZFgxQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa44f648-ff41-465b-f834-08df17f96590 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 16:00:02.9940 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: b66VBh5+CuURAsUKxm3aDSAzRRFW+5NP5qw0Pe9C0OeWO0JXYraQaY+tEPg2F7fICyGMS1YYhe0MkTHwe3WjcLQzSUvhlZOtykFGDbtqaF4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB8253 X-purgate-ID: tlsNG-d62444/1790006410-BFA6E757-2031CBE4/0/0 X-purgate-type: clean X-purgate-size: 827 On 21/09/2026 11:33 am, Alejandro Vallejo wrote: > On Mon Sep 21, 2026 at 11:30 AM CEST, Andrew Cooper wrote: >> On 21/09/2026 10:16 am, Alejandro Vallejo wrote: >>> The patch in Fixes adjusted two vendor variables from uint8_t and plain >>> int to to unsigned int. But they were both used later in printks with >>> the %d specifier rather than %u. Adjust accordingly. >>> >>> Fixes: 39a9a49449d7 ("x86: Remove x86 prefixed names from x86/cpu/ files") >>> Signed-off-by: Alejandro Vallejo >> If this is going to be a problem, then shouldn't we turn >> -Wformat-signedness on? > I tried that before sending, but that needs a whole new series. Things > are not quite as clean as I'd hope. Well, it's going to keep on regressing until -Wformat-signedness is in place. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Sep 21 16:01:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 16:01:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427724.1650524 (Exim 4.92) (envelope-from ) id 1x8gSA-0002ES-Jf; Mon, 21 Sep 2026 16:01:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427724.1650524; Mon, 21 Sep 2026 16:01:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gSA-0002EL-Gc; Mon, 21 Sep 2026 16:01:14 +0000 Received: by outflank-mailman (input) for mailman id 1427724; Mon, 21 Sep 2026 16:01:13 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gS9-0002EF-Jh for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:01:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8gS9-0079oW-0V for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 18:01:13 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab154c8-bab6-0a2a0a5309dd-0a2a450a9bd4-4 for ; Mon, 21 Sep 2026 18:01:12 +0200 Received: from [74.125.225.103] (helo=mail-wr2-f39.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab154c8-f2d2-0a2a450a0019-4a7de1678076-3 for ; Mon, 21 Sep 2026 18:01:12 +0200 Received: by mail-wr2-f39.google.com with SMTP id ffacd0b85a97d-482f633ece3so2452228f8f.3 for ; Mon, 21 Sep 2026 09:01:12 -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 ffacd0b85a97d-48724460898sm22720256f8f.9.2026.09.21.09.01.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 09:01:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790006472; x=1790611272; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=qgQz7Jfd9wETL2veMKW7K1+Bq6adGZsDysw0mhmkPAU=; b=SU2ebhivthaKqb0jPiVEeOU5tpMJEgMdI7A+VrUJe18dAJQLBzZhqpQNq1P3reSqYP bYq+CEqfHH0LiA2NlaUvHS6sfsTRNnJuQPwNIoM0CiX0c+ctZoC1kOqsC5hXt1RwgfJa HL3bEZ3ydhneXNivGGkcPufdvpi28iLyuJxlZi1TY20TOjmtyw6imx7SCsOkRrbShwUa H4MHMwQ12/4LdqVnDdDqjWXyQIMAe7r6Pn2SvxUjDLZOBX9y4D8VVoQHFd3mlSN1csuC g43y/h/0bqn//riau0KFNVCj1puVXF5B7aCJ080CJMDFmddd8153R6sxYXFDlUpHqdkq IoBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790006472; x=1790611272; h=content-transfer-encoding:content-type: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:content-type; bh=qgQz7Jfd9wETL2veMKW7K1+Bq6adGZsDysw0mhmkPAU=; b=dBA9v1etEPuIF8222i1+yV7osbG/qUZ32p6NzLWQWb5JoaAIHasv4b83sX5mPPKMsP OkS5F1hqYzf+Ku9qDvIjFW79bXY2iQiiad8pC1qQlaVRCGsaJnNdoNo6OvDy7EcN7IH3 4mV8HU9cnQeQwyP/1Eu4SNXb0bcXdHjEqh6L33oKSP5Lma2JmfmOHdcDrta6VGqDb0Y3 YGshZx9+YXAnfJUJItvUMFtNV1W0AUZfLLCqBWpvHOhWhGmvLThK9VYXxEQ4J0OTsdD5 diD5OXG05jCniZNEcP32rtBUxEfYXtqX0OxKLMHq/p2/1g+fyBQHMP0r/ub1TaEymELM ahZQ== X-Forwarded-Encrypted: i=1; AKwUvBzOVnJmWiZSAhCvH1LhCf1RSxnEiyBV0BkheACrl6HjiK7U3/xSsDAUtBibMvZqw/xpHLRsOmftbkQ=@lists.xenproject.org X-Gm-Message-State: AFuF++nKo3YoC8VhKH5Iw13FIv9Oev74RHnXfytiyWFdnBqk4hkMR3tw u4Tnm1HtS5KDlHruSc8gxtKGo3CuTGaVkJcV80DIBtpQDs5gwAY+FU0c9im8uyW1Cw== X-Gm-Gg: AYBFou357O42unVCJCAlw8TJbp8W/UoUXP0/HpeOvZo8OiASZNG+RGAbmzLr74wJDqV OgEO/9RALZnRdZXJJ51fLcgUgvfVOLB6i/OL8ND1CB81NPOEJC6QhRXU0OiWjs3WDj1/tJPs9lT tlPwpY5SuZfHnSY4fbizPu3CZhEhx4KrVJ2ZxReHENZLM3qKRZweWnU+TK/OS1jQzvd0ZUWEJSh CA2qzNs4f31WWuK39qAaa2yUorQ7Smnan51LarXkdWzsBIQRd7JOKNdZUhTp2U8mKsyMia+zZf9 cqQ6S2pmbWkqXLqiHns6kVLGzXQ8uG7QxFYVXQx740qFsOgnYqLYy8L4UGtgjhVK4lDA6K3gRiK GsPkUL+neKrncJvyGFdZYDfMD7rDXv1qbcM86E1GwbpT/YQ/EOsEY4XMAx/7/C6NYMZAbNAwGIK F6wNtxy+UWQ3s5ZYn7l5jNOrM9QSm/WsuZjurh9yBSbC4zR7IRZdE+Wz/4EDuOs+slzhO6oe9HQ JkP2fv49IWqfoCIslr3Ps6wHn0fqUMPsgkc4kjBEGkkWoRrGMSt8kKjGRJgUw== X-Received: by 2002:a05:600c:3e06:b0:49e:8238:6feb with SMTP id 5b1f17b1804b1-49fc56daf07mr169600375e9.14.1790006472378; Mon, 21 Sep 2026 09:01:12 -0700 (PDT) Message-ID: Date: Mon, 21 Sep 2026 18:01:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] x86/nSVM: Check injected event consistency To: Abdelkareem Abdelsaamad Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20260921155103.3243475-1-abdelkareem.abdelsaamad@citrix.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: <20260921155103.3243475-1-abdelkareem.abdelsaamad@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790006472-53ED2CFC-0F5833FC/0/0 X-purgate-type: clean X-purgate-size: 3207 On 21.09.2026 17:50, Abdelkareem Abdelsaamad wrote: > On 07.09.2026 08:50, Jan Beulich wrote: >> On 06.09.2026 15:11, Abdelkareem Abdelsaamad wrote: >>> On 26.08.2026 15:33, Jan Beulich wrote: >>>> On 23.08.2026 18:11, Abdelkareem Abdelsaamad wrote: >>>>> + case X86_EXC_OF: >>>>> + case X86_EXC_BR: >>>>> + return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l; >>>>> + >>>>> + case X86_EXC_VC: >>>>> + return vmcb_get_sev_es(vmcb); >>>>> + >>>>> + case X86_EXC_CP: >>>>> + return vmcb_get_cr4(vmcb) & X86_CR4_CET; >>>> >>>> ... e.g. here. That is, if a CR4 (or other) check is needed here, but not >>>> for #XM (or #SX), that's surely worth (briefly) commenting upon. The more >>>> that, afaics, none of this is spelled out in the PM. >>> In my testing, the hardware behavior differs across the generations support for >>> the Control-flow Enforcement Technology (CET): >>> - Naples (No hardware support): Injecting the event when the feature is >>> completely unsupported by the CPU results in VMEXIT_INVALID. The VMCB's CR4 >>> bit is not set as it is expected. >>> - Genoa (Hardware support exists): If the CPU supports the feature but the >>> guest has not enabled it in CR4 (not opted-in), injecting the event >>> results in a triple fault. I am accordingly checking for the CPU feature and >>> report it as invalid. >> >> A guest triple fault, I assume? > Yes, that is correct. I meant a guest triple fault. >> I'm not entirely convinced this is a sufficient >> indication of injection being permitted, even though I agree it very much looks >> so. Then again, like above, I'm also unconvinced this is actually intended >> behavior. Guests unaware of a feature (and hence not enabling it) should never >> observe exceptions related to only that feature. > The testing, I performed shows the following behavior across the CPU > generations: > - On CPUU generations that support the feature (e.g., Genoa supporting > Control-flow Enforcement Technology / CET), the injection results in > a guest triple fault. If the the guest did not opt-in for the CET feature. > No VMEXIT_INVALID results by the injection. > - On older hardware generations that completely lack the feature (e.g., Naples), > the injection immediately results in a VMEXIT_INVALID. > > The current hardware behavior seems to depend on whether the underlying > physical CPU understands the feature, rather than whether the guest has opted > into it via CR4. The patch expands this to consider the injection will result > in VMEXIT_INVALID if the guest did not opt into the feature. > > Are you suggesting to reather explicitly check the CPU model/generation instead > of checking X86_CR4_CET? For example, allowing the injection on Genoa platforms > regardless of whether the guest has enabled the CET capability? I am concerned > that handling this via CPU model checks might introduce architectural edge > cases and/or add maintenance complication—what are your thoughts on that > approach? No, I'm not suggesting to go by CPU model. That would be wrong in certain migration scenarios, afaict. Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 16:15:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 16:15:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427752.1650537 (Exim 4.92) (envelope-from ) id 1x8gfj-00049h-R3; Mon, 21 Sep 2026 16:15:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427752.1650537; Mon, 21 Sep 2026 16:15:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gfj-00049a-OU; Mon, 21 Sep 2026 16:15:15 +0000 Received: by outflank-mailman (input) for mailman id 1427752; Mon, 21 Sep 2026 16:15:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8gfi-00049T-Ij for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:15:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8gfh-00Dj9s-FU for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 18:15:13 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab15809-8faa-0a2a0a5109dd-0a2a4506dcbc-34 for ; Mon, 21 Sep 2026 18:15:13 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab15811-195a-0a2a45060019-b9ff1c228781-3 for ; Mon, 21 Sep 2026 18:15:13 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c4bff57900072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 21 Sep 2026 16:15:09 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id CD00580B5E; Mon, 21 Sep 2026 18:15:08 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=2c6HMFbObZqp9M8tEUOgquC1OeMDygg1yWrZjcnVNus=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=FCx593TiAl23R5zH7Da28DNdMcGTPL+o3FOWDIszz9yxJYLvBrG+sDQZfaitJv2O7kcdEKHA6 0G5k1fwLHXJlLPQ7Cv+s63uFkWmfAjqt16rQqtXxa6/dhuO9q+WHp2X33071HSuWacJvyGRnu1R P2cFKpe1Oyg15SBeMmpSnKhpsUzR1zlMduLcsPvG2x11jvV+YMLTUybvhhHL0O6kZwMu6tuPr99 jmEUWWYPLcP1I4tNwjCDFWyA3rUjA15suwNffqBp15fD0PF8b/7MjsXHJBsa0VqmyMHypKkJXok OLn/wQnDVPGUxF2HiLpAiuZLtL+Y4UIU8he+VKjK1Dng== X-Zone-Loop: 66803f35ba05bc9aa7abaa99e81e6389fe02bc6e9d1a x-campaign-type: default x-transaction-id: b1189af5-d8ef-4555-805c-a72dee02ca9f x-swg-uid: 01-e94081c9-8dc9-4f77-876b-67bdf94f80e9 X-Mailer: Sweego Message-ID: <1790007309.8631fc262581453bbf619ec5b2062170.1a0c4bff57900072c4@vates.tech> x-swg-bid: 1790007309.8631fc262581453bbf619ec5b2062170.1a0c4bff57900072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Mon, 21 Sep 2026 18:15:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file To: Oleksii Kurochko , xen-devel@lists.xenproject.org References: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> From: Baptiste Le Duc Content-Language: en-US Cc: Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Autocrypt: addr=baptiste.le-duc@vates.tech; keydata= xsBNBGoPSX8BCADSuTikqW3FD4mscQugY1thRaKlIhcJ2G9YCWYXAlp+xosvTlzfIftOZZim 750MLvyKtLPkQzB6TZtFZBiexSraaF/MdDKRTT5DcVa3r7ZnHgqMclWlPa4ioysS4yFcJanL cyNOT7HUFvIdirMMqiViedfYtS0GORPBBPVISD6ClMz3ecHIxqllfq9CHYQn4amKEfHmh6tm Rufo4Gjl6x8cUFZZlRQf+aCmUzdSPA0P5u3sueYH1uEz4w/jbD53MlKqzCvxUeOsfS2swTQA 6mS9jIgOjNadpUTOzKfDHMgFirtG+HFpm45Nwp6KQizxgDVOfTnOfVHm5Gwqm3ETl9y5ABEB AAHNPEJhcHRpc3RlIExlIER1YyAoVmF0ZXMgWXViaWtleSkgPGJhcHRpc3RlLmxlLWR1Y0B2 YXRlcy50ZWNoPsLAjgQTAQoAOBYhBGiSJ6HgW88MgT/gfu2Cu2XL9M6QBQJqD0l/AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO2Cu2XL9M6QuMcH/ihiy/Nrxp919AmY0ENnc0NK r/2LDvW/hrX4FfbpxAmrGmQ7MU1aQTk0JDbfcsG8OYH6wO5sqnXb1gz50YrEdpfVSbHz5YTZ EhDIxE4g7NrvJZh3Qc0m0CAyjYTNHen7J6olVaCMjrOH7uRHUYZ7Pl3am9mZosfLmez/aWJO a6ihQxBXHI75brlk1teIURkep2kP7P0Flmfl4cA//saREoTF7GXCtjOSQk/xg8PP0Sswqp5G TdJptn3FQn6lAzfz0eFSYqkaoX2c2k1MDa7o+UX9cfGPL8ybMKnYkasLxck6eOWGJWf+YTrm ga/r0kBaftmqNDgt5nI2jNTDwZcT9g3OwE0Eag9JfwEIAM6IWbuBSvz+erv27oGDDpo8M6Fp dGUvft7v+WceHUfxiXpYFx9qgIU6XGy6y+3lJMAvNcltS8DuhioqMlfKRSYGKZlpliY65dNP 557IuM4ctVJ+I9CVclvv9eahARQKgF5auLJAAlvGSmU+ufNvlwTUmLIRcrPviTmB6X5jJYc+ fiNeyI0HcsgcN21C0r62tUCypuZ+vgEJXw2bx1V8mVGZKxdGJPh58QF6kRK+xmd4kEComLGV BeM6BcVOtEjDcGNC0tLhXb0p9g1Ys55iA8sd6s4WacyolW2J6rwmcOkjiWexWw1caYgIWAV1 004M3gwUaOz0dGq2i7HQ0AiVfVkAEQEAAcLAdgQYAQoAIBYhBGiSJ6HgW88MgT/gfu2Cu2XL 9M6QBQJqD0l/AhsMAAoJEO2Cu2XL9M6QovYH/RjstyL5o/V5K74ylBtz0j5t3pLX5JKbwApi 656rGgDdqElImyvvZppNMl/mgHNzvxmfFAhJXnSX9f1fqVEQKOGEhLUastnl/ssBiE5x7btM V0GAffxXbXJZbVv4b/DI+gVrOPc2YXlVwruapvTZNtD3hqPrkjrmq5WTtGR2loIVSe62hmh0 BGD2Fy79b/hYWyBqhayPBEjwGW75u4/yn+Yqy1PgG3hIcvg7GSuT3akhHZSB2Mbguzcoyf9Q DJl6t33JxPRkkNrEdkPPmRlQCTSiUkVjKqMDF3jlINWsJ5t4jKFsNF91ksdw7aQgiX+tQIpE ugMC1NuNi5dDGip66bw= In-Reply-To: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790007309060 X-purgate-ID: tlsNG-16d1c6/1790007313-FE67277B-BE7FC686/10/73395122804 X-purgate-type: spam X-purgate-size: 10263 On 8/27/26 5:24 PM, Oleksii Kurochko wrote: > Implement first steps of migration a vCPU to a different guest interrupt file > procedure: > - At the old interrupt file, save to memory the values of registers > eidelivery and eithreshold, and set eidelivery = 0. > - At the new interrupt file, set eidelivery = 0, and zero all > implemented interrupt-pending bits (the eip array). > > The following steps will be introduced in follow-up patches. > > Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > against silent incorrect behaviour or unexpected panics in guest VMs until > the function is fully implemented. > > vgein_assign() will be introduced later in a separate patch, for not it is > only stub. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v2: > - New patch. > --- > --- > xen/arch/riscv/aia.c | 9 ++ > xen/arch/riscv/imsic.c | 159 +++++++++++++++++++++++++++++++ > xen/arch/riscv/include/asm/aia.h | 4 + > xen/include/xen/config.h | 1 + > 4 files changed, 173 insertions(+) > > diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c > index e31c9c2d24b6..75c82bcfa1b3 100644 > --- a/xen/arch/riscv/aia.c > +++ b/xen/arch/riscv/aia.c > @@ -1,8 +1,10 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > > +#include > #include > #include > #include > +#include > #include > > #include > @@ -21,3 +23,10 @@ void __init aia_init(void) > > _aia_usable = true; > } > + > +unsigned int vgein_assign(struct vcpu *v) > +{ > + BUG_ON("unimplemented\n"); > + > + return 0; > +} > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index ad7fbe708bfd..516f0105352a 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -26,6 +26,7 @@ > #include > #include > > +#include > #include > > #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ) > @@ -77,6 +78,64 @@ do { \ > csr_clear(CSR_SIREG, v); \ > } while (0) > > +#define imsic_vs_csr_write(c, v) \ > +do { \ > + csr_write(CSR_VSISELECT, (c)); \ > + csr_write(CSR_VSIREG, (v)); \ > +} while ( 0 ) > + > +/* > + * Generic switchcase expansion pyramid. > + * F is the per-operation leaf macro, ireg is the base register index. > + * Optional extra args (e.g. an operation and/or a value) are forwarded to F > + * via __VA_ARGS__. > + * > + * imsic_switchcase_break(ireg, op, v) - emit "case ireg: op(ireg,v); break;" > + * imsic_switchcase_ret(ireg, op, ...) - emit "case ireg: return op(ireg[,v]);" > + * The variadic tail is optional so the same leaf works for both read (no v) > + * and swap (with v). > + */ > +#define imsic_switchcase_break(ireg, op, v) \ > + case ireg: \ > + op(ireg, v); \ > + break; > + > +#define imsic_switchcase_ret(ireg, op, ...) \ > + case ireg: \ > + return op(ireg, ##__VA_ARGS__); > + > +#define imsic_switchcase_2(F, ireg, ...) \ > + F(ireg + 0, ##__VA_ARGS__) \ > + F(ireg + 1, ##__VA_ARGS__) > +#define imsic_switchcase_4(F, ireg, ...) \ > + imsic_switchcase_2(F, ireg + 0, ##__VA_ARGS__) \ > + imsic_switchcase_2(F, ireg + 2, ##__VA_ARGS__) > +#define imsic_switchcase_8(F, ireg, ...) \ > + imsic_switchcase_4(F, ireg + 0, ##__VA_ARGS__) \ > + imsic_switchcase_4(F, ireg + 4, ##__VA_ARGS__) > +#define imsic_switchcase_16(F, ireg, ...) \ > + imsic_switchcase_8(F, ireg + 0, ##__VA_ARGS__) \ > + imsic_switchcase_8(F, ireg + 8, ##__VA_ARGS__) > +#define imsic_switchcase_32(F, ireg, ...) \ > + imsic_switchcase_16(F, ireg + 0, ##__VA_ARGS__) \ > + imsic_switchcase_16(F, ireg + 16, ##__VA_ARGS__) > +#define imsic_switchcase_64(F, ireg, ...) \ > + imsic_switchcase_32(F, ireg + 0, ##__VA_ARGS__) \ > + imsic_switchcase_32(F, ireg + 32, ##__VA_ARGS__) > + > +static void imsic_eix_write(unsigned int ireg, unsigned long val) > +{ > + switch ( ireg ) > + { > + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIP0, > + imsic_vs_csr_write, val) > + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIE0, > + imsic_vs_csr_write, val) > + default: > + ASSERT_UNREACHABLE(); > + } > +} > + > unsigned int vcpu_guest_file_id(const struct vcpu *v) > { > return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); > @@ -389,6 +448,76 @@ int cf_check vcpu_imsic_init(struct vcpu *v) > return 0; > } > > +/* > + * Arguments of the imsic_vsfile_local_*() helpers, which are executed by the > + * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). > + */ > +struct imsic_vsfile_data { > + unsigned int hgei; > + unsigned int nr_eix; > + struct imsic_mrif *mrif; > +}; > + > +/* > + * Execute func() on the pCPU which owns the IMSIC interrupt file func() is > + * going to work with. > + * > + * An IMSIC VS-file is reachable only through hstatus.VGEIN of the hart the > + * file belongs to, and a guest interrupt file index is meaningless on any > + * other hart, so such work always has to be done by that very hart. > + * > + * The local case runs with IRQs disabled to provide func() with the same > + * environment it is given when it is called from the function call IPI > + * handler. > + */ > +static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), > + void *data) > +{ > + if ( cpu == smp_processor_id() ) > + { > + unsigned long flags; > + > + local_irq_save(flags); > + func(data); > + local_irq_restore(flags); > + } > + else > + on_selected_cpus(cpumask_of(cpu), func, data, 1); > +} > + > +static void cf_check imsic_vsfile_local_clear(void *data) I think the remark from Jan to direclty pass the type instead of void could be applied here. > +{ > + unsigned int i; > + const struct imsic_vsfile_data *idata = data; > + unsigned long new_hstatus, old_hstatus, old_vsiselect; > + > + /* We can only zero-out if we have a IMSIC VS-file */ > + if ( !idata->hgei ) > + return; > + > + old_vsiselect = csr_read(CSR_VSISELECT); > + old_hstatus = csr_read(CSR_HSTATUS); > + new_hstatus = old_hstatus & ~HSTATUS_VGEIN; > + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); > + csr_write(CSR_HSTATUS, new_hstatus); > + > + imsic_vs_csr_write(IMSIC_EIDELIVERY, 0); > + imsic_vs_csr_write(IMSIC_EITHRESHOLD, 0); > + > + for ( i = 0; i < idata->nr_eix; i++ ) > + { > + imsic_eix_write(IMSIC_EIP0 + i * 2, 0); > + imsic_eix_write(IMSIC_EIE0 + i * 2, 0); > +#ifdef CONFIG_RISCV_32 > + imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); > + imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); > +#endif > + } > + > + csr_write(CSR_HSTATUS, old_hstatus); > + csr_write(CSR_VSISELECT, old_vsiselect); > +} > + > void cf_check vcpu_imsic_deinit(struct vcpu *v) > { > XVFREE(v->arch.vimsic_state); > @@ -689,6 +818,14 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, > > void imsic_migrate_vcpu(struct vcpu *v) > { > + unsigned int new_vsfile_hgei; > + unsigned int new_vsfile_cpu; > + unsigned int nr_hw_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, > + BITS_PER_TYPE(uint64_t)); This value appears to remain constant after initialization, since it depends directly on the hw, so it is not necessary to calculate it each time. > + struct imsic_vsfile_data vsfile_data = { > + .nr_eix = nr_hw_eix, > + }; > + > /* > * The scheduler can mark a freshly created vCPU's unit as migrated and > * invoke this before the vCPU has ever run (see the migrated branch in > @@ -699,5 +836,27 @@ void imsic_migrate_vcpu(struct vcpu *v) > if ( v->arch.last_cpu == NR_CPUS ) > return; > > + /* > + * At this point, all interrupt producers are still using the old IMSIC > + * VS-file. > + */ > + > + /* > + * Latch the pCPU the new interrupt file is taken from: vgein_assign() > + * allocates it from v->processor's pool of guest interrupt files, and > + * only that hart can access the file afterwards. > + */ > + new_vsfile_cpu = v->processor; > + > + new_vsfile_hgei = vgein_assign(v); > + > + /* We don't support SW interrupt files at the moment. */ > + BUG_ON(!new_vsfile_hgei); > + > + vsfile_data.hgei = new_vsfile_hgei; > + > + /* Zero-out new IMSIC VS-file */ > + imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); > + > BUG_ON("unimplemented"); > } > diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/aia.h > index aaa4bf91fc75..53a1efb042f8 100644 > --- a/xen/arch/riscv/include/asm/aia.h > +++ b/xen/arch/riscv/include/asm/aia.h > @@ -3,8 +3,12 @@ > #ifndef RISCV_AIA_H > #define RISCV_AIA_H > > +struct vcpu; > + > bool aia_usable(void); > > void aia_init(void); > > +unsigned int vgein_assign(struct vcpu *v); > + > #endif /* RISCV_AIA_H */ > diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h > index dddc8e1920fe..0e29976e8203 100644 > --- a/xen/include/xen/config.h > +++ b/xen/include/xen/config.h > @@ -100,6 +100,7 @@ > #define BITS_PER_INT (BITS_PER_BYTE * __SIZEOF_INT__) > #define BITS_PER_LONG (BITS_PER_BYTE * BYTES_PER_LONG) > #define BITS_PER_LLONG (BITS_PER_BYTE * __SIZEOF_LONG_LONG__) > +#define BITS_PER_TYPE(type) (sizeof(type) * BITS_PER_BYTE) > > /* It is assumed that sizeof(void *) == __alignof(void *) */ > #define POINTER_ALIGN __SIZEOF_POINTER__ From xen-devel-bounces@lists.xenproject.org Mon Sep 21 16:44:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 16:44:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427771.1650546 (Exim 4.92) (envelope-from ) id 1x8h8C-0008EL-1a; Mon, 21 Sep 2026 16:44:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427771.1650546; Mon, 21 Sep 2026 16:44:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8h8B-0008EE-Ui; Mon, 21 Sep 2026 16:44:39 +0000 Received: by outflank-mailman (input) for mailman id 1427771; Mon, 21 Sep 2026 16:44:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8h8A-0008E8-2G for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:44:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8h89-00D9Kf-FM for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 18:44:37 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab15ec5-bab6-0a2a0a5309dd-0a2a45029d2c-42 for ; Mon, 21 Sep 2026 18:44:37 +0200 Received: from [103.168.172.153] (helo=fhigh-a2-smtp.messagingengine.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab15ef4-6ca4-0a2a45020019-67a8ac998841-3 for ; Mon, 21 Sep 2026 18:44:36 +0200 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id C92B914000BD; Mon, 21 Sep 2026 12:44:35 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 21 Sep 2026 12:44:35 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Sep 2026 12:44:33 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1790009075; x=1790095475; bh=zjivBsa9hsRYHRNcFKFS9TSN3LLieSyZGZ06Ds3oU04=; b= ETOnTJrWCFgnFf/C6RW39dzZVGm9alXCueR8hrIYvyhVK8RxNGOJ3OBhs38QifwK Gd/b0d8HjsrrNbRIEKPqx/2AZwA8lrpMeqkU9fgFMkFLA1an3zIpHfKWcYIsn0CI aKtNx2/7C4QYRxoPxjGafhTx+EInGybRln/BP8LTVlQevCgBsVu5GpS6RIvARYlD dFRTcZvm06/nhqQ3uj6a1EBIltNrr7VfTvD1ct1HsppWzC9XyaD3jh2/85aWS5vC txPKZ3eIWTWEIne68UlhLAOTEkaXyBUCKK211Mpdcr/Z85aKHUv1AdkFpifKBbjH jNIULI84Px6RykN2jLUoHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1790009075; x=1790095475; bh=zjivBsa9hsRYHRNcFKFS9TSN3LLieSyZGZ0 6Ds3oU04=; b=VKcMeiVtck82x1r/UyvCXPeKBPcVIOpbiLym7cqzPvPhJLsdZp1 9s+QNXETbUNvzxGoGahycJ7vl1NOZ045Vvl+lF58R7PcoLvhGtv9g9lQFTKe0xka IL9yBbYA3v8iaW8ZB9xuc9hIc1+XR1N8qYSrCLIhKrNUyrhWPu9X+KyFBMuP0uCm 9RsBxp6aM4gF/lPyXboPKE8bnOsMI3s7kcF5HKhdkLD2WVzir4SuEXpzeRHjYyy/ uceQqwtXZWhQKJ2mvaDFAJMtcgStz9u6RGqkfikyY7n/LxaTpDGgIVEPkzI+ES1z QU45+tsWIgJiLG6lggy9LF9WgS/CAl/ZStw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEeJuUSXcXeoFym2RhUCdnjC1hVcyJNbiXzRJfWYXLtKAJXYGAPCakl5qcp6/SKXs MGNNYK1DQXRQ2t//wFMwqiisHDJwLqn7jO49xQPd0WPBSlYe9lDssGROHDQsS8Bk7FlTe6 0EvM8fIU92OKf3+3Gigm9Qce8DcAbAIPunT5xFIRRF3Ty8X1bTicArUlkdPTZol/UiwrKd Hobiz/pIFccJHnBJIevVebKUXyOh1TNjvla/N5w0hybdKG7+G/uRJtzwe5hkpZvwhe8zUR 2+UHThMzf4dYYKG+me1Y9hzKWbr+1QfhRSj7X745j7VRthIymvfnGMWTNMvihukkwdkZl+ qHJZYmWrhaTHFuidDeOXKl58oQjIrx8ft2kjCTJdv/Q4FvyJ4tprsGwOBViHTQREvOU+Xe a16oR2BSKbPhYqK61AcYux0Y71upCmsQiYMaql4UhguxQE1QfvDkh+iz9MIpgmPqWSiaqn bwMcE4vt5kvoLHIkEVw8zx2GdJ3213MnEjFRH4vW4CjcZ6+uSS4YGiDlAlmCsMXxvguEDv 18N/psr8ZwybdP1rujQDtYLnfDep6bjEx8oioZ/A6UfJ8+mw5/yQpC30VzG4PhYCYqkbk9 FRaVrq5qGyQEBQTDZpgAPeYS6mPpd6ZgO0JPOPln4Vv9dzAyne0/GJjgpNTg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 21 Sep 2026 18:44:31 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: "Rafael J. Wysocki (Intel)" Cc: Support TRINITY , regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Huisong Li Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot Message-ID: References: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Lth3KI9EydCmQGrl" Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-720697/1790009077-670B02AC-B1CC4B66/0/0 X-purgate-type: clean X-purgate-size: 6501 --Lth3KI9EydCmQGrl Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Sep 2026 18:44:31 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: "Rafael J. Wysocki (Intel)" Cc: Support TRINITY , regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Huisong Li Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot On Mon, Sep 21, 2026 at 05:26:55PM +0200, Rafael J. Wysocki (Intel) wrote: > On Sun, Sep 20, 2026 at 5:48=E2=80=AFPM Support TRINITY wrote: > > > > Hello, > > > > I am reporting a bare-metal Xen dom0 boot regression seen with Linux 6.= 18.52. > > > > On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on ba= re metal, while Linux 6.18.52 consistently black-screens before dom0 usersp= ace/networking comes up. > > > > #regzbot introduced: v6.18.51..v6.18.52 > > #regzbot title: ACPI processor/cpuidle lifecycle change breaks bare-met= al Xen dom0 boot > > #regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/work_item= s/18447 > > > > Tested results: > > > > Linux 6.18.51-r0, Xen dom0, bare metal: boots > > Linux 6.18.52-r0, Xen dom0, bare metal: black screen before userspace/n= etwork >=20 > I'm wondering what's special about Xen dom0 bare metal. >=20 > Does adding processor=3Dnocst to the kernel command line help, by any cha= nce? It does not. > The patch is essentially a revert of commit 13ebeef6a1b9 ("ACPI: > processor: idle: Optimize ACPI idle driver registration") which I'd > rather not do without knowing what exactly is going on. >=20 > At this point it looks like a missing check somewhere or similar, so > it would be good to find out where exactly it crashes. I can reproduce the crash, I get this: [ 3.525669] BUG: kernel NULL pointer dereference, address: 0000000000000= 008 [ 3.525677] #PF: supervisor read access in kernel mode [ 3.525681] #PF: error_code(0x0000) - not-present page [ 3.525685] PGD 0 P4D 0=20 [ 3.525688] Oops: Oops: 0000 [#1] SMP NOPTI [ 3.525693] CPU: 0 UID: 0 PID: 21 Comm: cpuhp/0 Not tainted 6.18.52-1.qu= bes.23.fc41.x86_64 #1 PREEMPT(full)=20 [ 3.525700] Hardware name: Micro-Star International Co., Ltd. MS-7E06/PR= O Z790-P WIFI (MS-7E06), BIOS Dasharo (coreboot+UEFI) v0.9.1 01/17/2024 [ 3.525706] RIP: e030:cpuidle_register_device+0xd2/0x350 [ 3.525714] Code: 00 00 8b 55 04 49 89 c5 49 89 d4 81 fa ff 1f 00 00 0f = 87 68 02 00 00 48 8b 04 d5 c0 a0 19 82 48 83 3c 18 00 0f 85 ad 48 12 ff <49= > 8b 7d 08 48 89 14 24 e8 31 73 30 ff 84 c0 0f 84 72 01 00 00 41 [ 3.525723] RSP: e02b:ffffc90040133db8 EFLAGS: 00010246 [ 3.525727] RAX: ffff888235f5c000 RBX: ffffffff834d4d40 RCX: 00000000000= 00000 [ 3.525732] RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffff888101c= 39c00 [ 3.525736] RBP: ffff888101c39c00 R08: 4ec4ec4ec4ec4ec5 R09: ffff888101c= 39c00 [ 3.525740] R10: ffffc90040133df8 R11: 0000000000000000 R12: 00000000000= 00000 [ 3.525744] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff834= d4d40 [ 3.525752] FS: 0000000000000000(0000) GS:ffff888235f5c000(0000) knlGS:= 0000000000000000 [ 3.525757] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.525761] CR2: 0000000000000008 CR3: 000000000242c000 CR4: 00000000000= 50660 [ 3.525768] Call Trace: [ 3.525771] [ 3.525775] acpi_processor_power_init+0xde/0x150 [ 3.525782] ? __pfx_acpi_soft_cpu_online+0x10/0x10 [ 3.525787] acpi_soft_cpu_online+0x123/0x170 [ 3.525792] cpuhp_invoke_callback+0x134/0x470 [ 3.525797] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 3.525802] cpuhp_thread_fun+0xa2/0x170 [ 3.525806] smpboot_thread_fn+0xf3/0x220 [ 3.525810] kthread+0xfc/0x240 [ 3.525814] ? __pfx_kthread+0x10/0x10 [ 3.525818] ? __pfx_kthread+0x10/0x10 [ 3.525822] ret_from_fork+0x158/0x170 [ 3.525827] ? __pfx_kthread+0x10/0x10 [ 3.525830] ret_from_fork_asm+0x1a/0x30 [ 3.525835] [ 3.525837] Modules linked in: [ 3.525842] CR2: 0000000000000008 [ 3.525845] ---[ end trace 0000000000000000 ]--- [ 3.525849] RIP: e030:cpuidle_register_device+0xd2/0x350 [ 3.525854] Code: 00 00 8b 55 04 49 89 c5 49 89 d4 81 fa ff 1f 00 00 0f = 87 68 02 00 00 48 8b 04 d5 c0 a0 19 82 48 83 3c 18 00 0f 85 ad 48 12 ff <49= > 8b 7d 08 48 89 14 24 e8 31 73 30 ff 84 c0 0f 84 72 01 00 00 41 [ 3.525862] RSP: e02b:ffffc90040133db8 EFLAGS: 00010246 [ 3.525866] RAX: ffff888235f5c000 RBX: ffffffff834d4d40 RCX: 00000000000= 00000 [ 3.525870] RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffff888101c= 39c00 [ 3.525874] RBP: ffff888101c39c00 R08: 4ec4ec4ec4ec4ec5 R09: ffff888101c= 39c00 [ 3.525878] R10: ffffc90040133df8 R11: 0000000000000000 R12: 00000000000= 00000 [ 3.525882] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff834= d4d40 [ 3.525889] FS: 0000000000000000(0000) GS:ffff888235f5c000(0000) knlGS:= 0000000000000000 [ 3.525894] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.525898] CR2: 0000000000000008 CR3: 000000000242c000 CR4: 00000000000= 50660 [ 3.525904] Kernel panic - not syncing: Fatal exception [ 3.525931] Kernel Offset: disabled And I have also another data point: Linux 7.2.6 is _not_ affected. And similarly, Linux 7.3-rc3 works fine (haven't tried -rc4 yet). --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --Lth3KI9EydCmQGrl Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqxXu8ACgkQ24/THMrX 1yxeNAf8CqjSP8UmFu0EwOUBtvbUXkkKyQgSNjKPFIYIh4LYPPhWtXqrWzp3GKn4 1QbwQSmgEPWpJjLi5/zkNGpJ75gPkJbzDCcD82D39fYjcncHWfD2LCh7LHHOM94J 1z+dqF6L6llqEgeKxcFNDX8eWopBznsp5XNv0wVtYAlt9Qdl89FGYg5qsFecbwno aDEuUVfT46CQ6+6+eY/mNyifgQcNlFnmShIOR0OXjKghsOzNwU+Geyin3/Kylh/g 9adNQ+eNkUod/gidhUZxUS0O2Q3ZDlM2CHnkItGEWj3vu8OTsvUZrBcussfKnPHD 60t/CiN4kdY1vKqB0SqRGgKmVy4d9w== =n6Pq -----END PGP SIGNATURE----- --Lth3KI9EydCmQGrl-- From xen-devel-bounces@lists.xenproject.org Mon Sep 21 17:04:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 17:04:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427781.1650555 (Exim 4.92) (envelope-from ) id 1x8hQm-0002oD-Lk; Mon, 21 Sep 2026 17:03:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427781.1650555; Mon, 21 Sep 2026 17:03:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8hQm-0002o6-Ih; Mon, 21 Sep 2026 17:03:52 +0000 Received: by outflank-mailman (input) for mailman id 1427781; Mon, 21 Sep 2026 17:03:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8hQl-0002o0-Aj for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:03:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8hQj-00DBYV-92 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 19:03:49 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab16370-bab6-0a2a0a5309dd-0a2a450b984e-6 for ; Mon, 21 Sep 2026 19:03:49 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab16374-b7e8-0a2a450b0019-b9ff1c12a72d-3 for ; Mon, 21 Sep 2026 19:03:48 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c4ec74f000072c4.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 21 Sep 2026 17:03:45 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 1AD698115F; Mon, 21 Sep 2026 19:03:45 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=nFN7+0Yt3+MnStuj92rJ7nzyMbzgriCI4a7p5fqJd3g=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=YxwCr3ol7fTxAJnM+GrTXXDGGKfIxM24CuMCK7LdS2JUefhEA2rLNwD5AFrYlryAxQUB09pIo 1ajVsV9Si7mCjDCUYB6YdJ7Vu0HFmbexh7zmUp21cfyfMLQy14ibDs9C2OICu1hFl8Z4/TTVIlH IMP0hoyPcHN2k68BlHvmbSx1UikX72PxLVWf0oRV3GtItfOz4jAIlWjiXcu5LWcWnSi6utGke+S ndMW+GVPFA5KU8/3sNbUeYAhiwK+FYvqOK2boxcmNxSlthA6Ruhnq17xbyFvM+WHsH4+FBNaPF1 zohjcbx9wu8LEkVrbTVsZ/QShkW1X6ermyo6rGlsK/Nw== X-Zone-Loop: 1d52740d9342a53dd63c30c3576c447c708fb3e5ba3a x-campaign-type: default x-transaction-id: ea8baf98-ea3f-4d79-ad40-0fc26f7ebde9 x-swg-uid: 01-1ab7c777-214b-4db6-8eb7-d3bd7c7e8d62 X-Mailer: Sweego Message-ID: <1790010225.8631fc262581453bbf619ec5b2062170.1a0c4ec74f000072c4@vates.tech> x-swg-bid: 1790010225.8631fc262581453bbf619ec5b2062170.1a0c4ec74f000072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <450d0c5e-2101-4b1c-98fd-2f438bd0ccf3@suse.com> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> <450d0c5e-2101-4b1c-98fd-2f438bd0ccf3@suse.com> Date: Mon, 21 Sep 2026 19:03:39 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790010219; l=12521; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ZrRyxxlRPHz5I5lHZ2pJSefPtiVW4YoKEOxkzdtW4hE=; b=XHZ16m5qViLmyfz9Edg+6l/zcIS3nsA9f/OrLTN/eXFYH13C71VFuSpTBhjgO/Ep4GJYdmjVb 3kOtdYWKqQ4AjUfFZXvjyF6LhgWjnvCyPJkE6FsQ15yN1z/FtVs8K6B X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790010225291 X-purgate-ID: tlsNG-42698a/1790010229-182F49EA-9D536384/0/0 X-purgate-type: clean X-purgate-size: 12525 On 2026-09-21 17:26:47+02:00, Jan Beulich wrote: > On 10.09.2026 11:34, Baptiste Le Duc wrote: > > > p2m_set_permission() only presets the PTE A/D bits when the Svade extension > > is present in the device tree. This causes an unhandled page fault when > > neither Svade nor Svadu is present (the platform's actual behaviour is then > > unknown), and when both are present in the device tree. > > > > Move the Svade/Svadu resolution out of p2m_set_permission() and into a new > > riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). For each of > > the four possible Svade/Svadu combinations (inspired by [1]), it decides > > whether software has to preset the A/D bits and, if so, sets > > RISCV_ISA_EXT_svade to record that decision: > > - neither present: assume Svade, since assuming Svade is harmless on real > > Svadu hardware, while assuming Svadu on real Svade hardware risks an > > unhandled page fault > > - only Svade present: assume Svade > > - only Svadu present: leave A/D management to hardware > > - both present: Svade wins until Xen supports the SBI FWFT call needed to > > enable hardware updating of A/D bits, so assume Svade and warn that > > dropping 'svade' from the DT is the only way to get Svadu. > > > > [1] https://lwn.net/Articles/980016/ > > > > Fixes: ff14053983b0 ("xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration") > > Assisted-by: Claude:claude-opus-5 > > Signed-off-by: Baptiste Le Duc > > --- > > Changes since v1: > > - change commit title > > - expose RISCV_ISA_EXT_svadu so the two extensions can be told apart. > > - move the Svade/Svadu resolution to a new riscv_resolve_ad_scheme(), > > called once from riscv_fill_hwcap(). > > - expose sbi_probe_extension() (was static) to probe for SBI FWFT. > > - stop presetting A/D bits unconditionally in p2m_set_permission(), do it > > only when Svade is present. > > --- > > xen/arch/riscv/cpufeature.c | 59 +++++++++++++++++++++++++++++++++ > > xen/arch/riscv/include/asm/cpufeature.h | 1 + > > xen/arch/riscv/include/asm/sbi.h | 8 +++++ > > xen/arch/riscv/p2m.c | 47 ++++++++++---------------- > > 4 files changed, 86 insertions(+), 29 deletions(-) > > > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > > index 92235fdfd5..19454544a7 100644 > > --- a/xen/arch/riscv/cpufeature.c > > +++ b/xen/arch/riscv/cpufeature.c > > @@ -18,6 +18,7 @@ > > > > #include > > #include > > +#include > > > > #ifdef CONFIG_ACPI > > # error "cpufeature.c functions should be updated to support ACPI" > > @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) > > return false; > > } > > > > +/* > > + * Svade and Svadu extensions represent two schemes for managing the PTE A/D > > + * bits. When the PTE A/D bits need to be set, the Svade extension indicates > > + * that a page fault will be raised. In contrast, the Svadu extension supports > > + * hardware updating of the PTE A/D bits. > > + * > > + * There are 4 possible combinations of these extensions in the device tree. > > + * The default hardware behavior for each is: > > + * > > + * 1) Neither Svade nor Svadu present in DT => It is technically unknown > > + * whether the platform uses Svade or Svadu. Xen should be prepared to > > + * handle either hardware updating of the PTE A/D bits or page faults when > > + * they need updating. In that case, Xen assumes Svade because it's > > + * harmless if the platform is actually Svadu, while assuming Svadu on real > > + * Svade hardware risks an unhandled page fault. > > + * > > + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. > > + * > > + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. > > + * > > + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off > > + * at boot time by setting A/D bits. To use Svadu, the supervisor must > > + * explicitly enable it using the SBI FWFT extension. > > + * > > + * The Svade extension is mandatory and the Svadu extension is optional in the > > + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose > > + * option 3. Platforms aware of the profile can choose option 4, and Xen won't > > + * get the benefit of Svadu until the SBI FWFT extension is available. > > + * > > + * In other words, hardware manages the A/D bits on its own only in case 3, in > > + * all the other cases software has to preset them. Instead of open coding this > > + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is > > + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. > > + */ > > +static void __init riscv_resolve_ad_scheme(void) > > +{ > > + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > > + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); > > + > > + /* Case 3: leave the A/D bits management to hardware. */ > > + if ( svadu && !svade ) > > + return; > > + > > + /* Case 4 */ > > + if ( svadu && svade ){ > > + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ > > Nit (style): Brace placement. Sorry for that. I will fix that in v3. > Furthermore this is written in a way which Misra would call "dead code". I'd > like to suggest (leaving out comments): > > if ( svadu ) > { > if ( !svade ) > return; > > if ( !sbi_probe_extension(SBI_EXT_FWFT) ) > printk(...); > } I assume you are referring to Misra C:2012 Rule 13.5 "The right operand of a logical && or || operand shall not contain persistent side effect" If yes, IMO, I think it doesn't apply here as `svade` is evaluated before the `if` so there is no side effect that wouldn't have been executed in case of svadu=false. > > > + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" > > + "RISC-V: Defaulting to software A/D updates (Svade).\n" > > + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); > > Nit (style): Indentation (in multiple ways). Furthermore XENLOG_* needs > repeating after every newline. > > > + } > > + } > > + > > + /* Cases 1, 2: Xen assume Svade to be enabled */ > > + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); > > Isn't this a lie (to ourselves) then? If you are talking about case 1: [1] Yes, it's technically a lie for boards shipped before the svade/svadu extension was ratified (e.g., HiFive Premier P550). These extensions merely formalized a mechanism that already existed in hardware. [2] For boards that do support svade, we could enforce DT declaration by adding it to `required_extension` as they are explicitly supporting it. However, doing so would cause boards without svade/svadu support (as described above) to hit a panic during boot. So in both case ([1], [2]), the svade extension exist either implicitely or explicitly. Therefore, force it doesn't compromize anything. > > > --- a/xen/arch/riscv/include/asm/sbi.h > > +++ b/xen/arch/riscv/include/asm/sbi.h > > @@ -30,6 +30,7 @@ > > #define SBI_EXT_BASE 0x10 > > #define SBI_EXT_RFENCE 0x52464E43 > > #define SBI_EXT_TIME 0x54494D45 > > +#define SBI_EXT_FWFT 0x46574654 > > > > /* SBI function IDs for BASE extension */ > > #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 > > @@ -138,6 +139,13 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, > > int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, > > size_t size, unsigned long vmid); > > > > +/** > > + * Check if an SBI extension ID is supported or not. > > + * @extid: The extension ID to be probed. > > + * > > + * @return: 1 or an extension specific nonzero value if yes, 0 otherwise. > > + */ > > +int sbi_probe_extension(long extid); > > /* > > Nit (style): Also add a blank line. > > > --- a/xen/arch/riscv/p2m.c > > +++ b/xen/arch/riscv/p2m.c > > @@ -586,42 +586,31 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_cache) > > > > static void p2m_set_permission(pte_t *e, p2m_type_t t) > > { > > + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > > + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); > > + > > e->pte &= ~PTE_ACCESS_MASK; > > > > e->pte |= PTE_USER; > > > > /* > > - * Two schemes to manage the A and D bits are defined: > > - * • The Svade extension: when a virtual page is accessed and the A bit > > - * is clear, or is written and the D bit is clear, a page-fault > > - * exception is raised. > > - * • When the Svade extension is not implemented, the following scheme > > - * applies. > > - * When a virtual page is accessed and the A bit is clear, the PTE is > > - * updated to set the A bit. When the virtual page is written and the > > - * D bit is clear, the PTE is updated to set the D bit. When G-stage > > - * address translation is in use and is not Bare, the G-stage virtual > > - * pages may be accessed or written by implicit accesses to VS-level > > - * memory management data structures, such as page tables. > > - * Thereby to avoid a page-fault in case of Svade is available, it is > > - * necessary to set A and D bits. > > - * > > - * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI > > - * delegates page faults to a lower privilege mode and so OpenSBI > > - * isn't expect to handle page-faults occured in lower modes. > > - * By setting the A/D bits here, page faults that would otherwise > > - * be generated due to unset A/D bits will not occur in Xen. > > - * > > - * Currently, Xen on RISC-V does not make use of the information > > - * that could be obtained from handling such page faults, which > > - * could otherwise be useful for several use cases such as demand > > - * paging, cache-flushing optimizations, memory access tracking,etc. > > + * riscv_fill_hwcap() sets either RISCV_ISA_EXT_svade or > > + * RISCV_ISA_EXT_svadu (mutually exclusive) depending on the Svade/Svadu > > + * device tree combination (see riscv_resolve_ad_scheme()): > > + * - RISCV_ISA_EXT_svade means that software is responsible for the A/D > > + * bits. > > + * - RISCV_ISA_EXT_svadu means the hardware is responsible for the A/D > > + * bits. > > * > > - * To support the more general case and the optimizations mentioned > > - * above, it would be better to stop setting the A/D bits here and > > - * instead handle page faults that occur due to unset A/D bits. > > + * Currently, when RISCV_ISA_EXT_svade is set, Xen doesn't track A/D > > + * bits, so it does not make use of the information that could be > > + * obtained from handling the resulting page faults, which could > > + * otherwise be useful for several use cases such as demand paging, > > + * cache-flushing optimizations, memory access tracking, etc. To avoid > > + * such a page fault, Xen presets the A and D bits instead. > > */ > > - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > > + ASSERT(svade != svadu); /* exactly one of svade/svadu must be set by riscv_fill_hwcap() */ > > Here I'm lost: riscv_resolve_ad_scheme() specifically handles the "both set" > case. How can you then assert that exactly one of them is set? Because in the future, with SBI FWFT support, both extensions could be supported by the hardware and listed in the DT. Xen could still assume that only Svadu is turned-off at boot time but then, to use Svadu, it should explicitly enable it by using SBI FWFT extension. I agree it's not needed right now. I'll drop it until then. > > Apart from this the line is also too long and the comment doesn't match our > style. > > Jan From xen-devel-bounces@lists.xenproject.org Mon Sep 21 17:13:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 17:13:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427786.1650564 (Exim 4.92) (envelope-from ) id 1x8haH-0004V3-GI; Mon, 21 Sep 2026 17:13:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427786.1650564; Mon, 21 Sep 2026 17:13:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8haH-0004Ug-DP; Mon, 21 Sep 2026 17:13:41 +0000 Received: by outflank-mailman (input) for mailman id 1427786; Mon, 21 Sep 2026 17:13:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8haF-0004Ua-QJ for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:13:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8haE-007IXz-FJ for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 19:13:38 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab165c0-2eae-0a2a0a5409dd-0a2a450cc6fc-12 for ; Mon, 21 Sep 2026 19:13:38 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab165c1-f479-0a2a450c0019-a0658308949c-3 for ; Mon, 21 Sep 2026 19:13:38 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 8D35944CEFD4; Mon, 21 Sep 2026 13:11:35 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Abdelkareem Abdelsaamad To: xen-devel@lists.xenproject.org, jbeulich@suse.com Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: Re: [PATCH v4] x86/nSVM: Check injected event consistency Date: Mon, 21 Sep 2026 18:07:57 +0100 Message-ID: <20260921170757.3244601-1-abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1790010818-774D7A5B-A6DDC86E/0/0 X-purgate-type: clean X-purgate-size: 2052 On 07.09.2026 08:36, Jan Beulich wrote: >On 06.09.2026 15:22, Abdelkareem Abdelsaamad wrote: >>>>> @@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) >>>>> svm_dump_sel(" TR", &vmcb->tr); >>>>> } >>>>> >>>>> +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, >>>>> + uint8_t vmcb_injected_vector) >>>>> +{ >>>>> + switch ( vmcb_injected_vector ) >>>>> + { >>>>> + case X86_EXC_DE: >>>>> + case X86_EXC_DB: >>>>> + case X86_EXC_BP: >>>>> + case X86_EXC_UD: >>>>> + case X86_EXC_NM: >>>>> + case X86_EXC_DF: >>>>> + case X86_EXC_TS: >>>>> + case X86_EXC_NP: >>>>> + case X86_EXC_SS: >>>>> + case X86_EXC_GP: >>>>> + case X86_EXC_PF: >>>>> + case X86_EXC_MF: >>>>> + case X86_EXC_AC: >>>>> + case X86_EXC_MC: >>>> >>>> Is #MC valid to inject without CR4.MCE set? >>> The testing I performed (see previous comment) does not show that set CR4.MCE >>> is required for the valid injection. >>>>> + case X86_EXC_XM: >>>> >>>> As before: Doesn't #XM (AMD: #XF) require CR4.OSXMMEXCPT to be set? >>> The testing I performed (see previous comment) does not show that set CR4.MCE >>> is required for the valid injection. >> I meant ..does not show that set CR4.OSXMMEXCPT is required. >>>> >>>> Again as before: Is #SX really permitted without any constraints? You did >>>> reply to both comments on v3, but that outcome isn't reflected here. The >>>> more that what you said there could equally apply ... >>> The testing I performed (see the first comment) does not show that set CR4.MCE >>> is required for the valid injection. >> I meant ..does not show that any CR4 bit is required. > >And I didn't mention CR4. I intentionally said "without any constraints". I believe the Security Exception (Vector 30) is architecturally valid on AMD Naples (EPYC 7001) and Rome (EPYC 7002) platforms. Event injection of vector 30 then does not require specific guest enablement I am aware of. From xen-devel-bounces@lists.xenproject.org Mon Sep 21 17:31:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 17:31:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427807.1650572 (Exim 4.92) (envelope-from ) id 1x8hrp-0007MW-RV; Mon, 21 Sep 2026 17:31:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427807.1650572; Mon, 21 Sep 2026 17:31:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8hrp-0007MP-On; Mon, 21 Sep 2026 17:31:49 +0000 Received: by outflank-mailman (input) for mailman id 1427807; Mon, 21 Sep 2026 17:31:49 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8hrp-0007MJ-3h for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:31:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8hrj-00DEuM-2u for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 19:31:48 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab169dd-2eae-0a2a0a5409dd-0a2a4505ad1e-46 for ; Mon, 21 Sep 2026 19:31:42 +0200 Received: from [40.107.209.46] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab169fc-4cb1-0a2a45050019-286bd12ee1fb-3 for ; Mon, 21 Sep 2026 19:31:41 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by PH7PR12MB7209.namprd12.prod.outlook.com (2603:10b6:510:204::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Mon, 21 Sep 2026 17:31:38 +0000 Received: from BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740]) by BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740%3]) with mapi id 15.21.0428.015; Mon, 21 Sep 2026 17:31:37 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Oc8CxIFP16jmiHSJ6EqHK1JMJbjRZJIS8OepnxKDxowtD4ibJTnU9wzW7Lvdk2pTZIOoJ/Cwnj9toPXPYjx5VNMa4RSfIVCqqJRxQ8NvUYDcNO/OxuuxP3u6cb3uyjIIPuvuIqh8xSTuYKpMmUAQjdbYf4vltzms89EIavHi93GkviDasmUXUm+MjAK4R5JhyVf7R9ul5Jo4TsjC3JXPO5B8EzZAqgZysQmNDfY66OJY9O4xuLKTbJEM0jVIlRTzagRgEwGVmVE8s4xtOJQ1RqQwOLhfgrDww/dI+SUCA6l2VynsM3bq4Y/GOpRN31JtSbfi4xTqpL7zu7qs+1Z8tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qT6YvApqICwnus4uJaLBtTpqiU9RiIFrSXWT8PiYie0=; b=jxZRLmdle+Z6qSptGYIETFQbqOqMhTZtUmLU5YU1Vg90K68KmU9fHhYWnKirXF/hSmMKI2v1u6LZ2oi/onp8lQXMjo9CD0NVmOWJLgv8l3Rny6HR26Bhp2v6JtZjGb4nLrqwhUiVQDD7izh4fiBalMFF0uky4rg+PEoMklYho64A+a4PYGl3Ho0/efe6UwbDgPC/7Ujx39HQN4++OxqbtmAwQimf+2/u8qV60uCmH1AB0DQlpZiXOv4K2F1AkzacxcR+ELpSaY/UeXqIYPW+1GDVJPT6pUvUT57UxU46WN0M5zo9ljRVkNQ51p2ytQpCbW/jcELG3YUiygFjNkECww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qT6YvApqICwnus4uJaLBtTpqiU9RiIFrSXWT8PiYie0=; b=xodNreDstgFCFTG6BGuPVesANvct8JQrkWb7mwIWPmJl1sD7WNWVeFUHWaH06jAChaMO1GW5bJu0Xq495GHxCGWnueq3VMrte6yDpruoA6XSG7M1ns6f5sLpzXRzEJNTquYx51AEmYPKhBAhh73gQjSkA8A0bH+7mI8dWFTkUjE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 21 Sep 2026 19:31:34 +0200 Message-Id: Cc: "Jan Beulich" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Teddy Astie" Subject: Re: [PATCH] x86/vpmu: Fix incorrect printk format specifiers From: "Alejandro Vallejo" To: "Andrew Cooper" , X-Mailer: aerc 0.17.0 References: <20260921091651.34761-1-alejandro.garciavallejo@amd.com> <489f6ce6-2be7-4c94-bcf0-21fc6993f98c@citrix.com> <1cef5505-79f5-4319-8334-d3ee809bde7d@citrix.com> In-Reply-To: <1cef5505-79f5-4319-8334-d3ee809bde7d@citrix.com> X-ClientProxiedBy: MA2P292CA0029.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::19) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|PH7PR12MB7209:EE_ X-MS-Office365-Filtering-Correlation-Id: d582f2d4-ac80-434d-cc89-08df180630d2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|11063799006|10067099003|4143699003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: CSL0YU0xRSwCwMCXJEK2JRKXvJ9v4YmNGBcmhuPgg5VbiN3nQEtXX8shzA3AL/foipRr9VHRRNrDH8B1ymFbaJbTb+gRL/yzarPezMyNXBgbGLNlfZLN1LMRT+Pq5ioa/uR6v655RVeQF2EmbGvHnEiYQgc+Ah7VKCArCQHIBfywg5FKLWJfy496wBVT+SY/8nMmkgupHqDzo3bwlYRQNPQeU74Seer3kK2SQuq4BudcaSX2tg7l50KSO6vYyw/oBvzwGY1J4/pTHxrj6alipnqtL7DED5LNHbXAdo3N0qml1JHhuczHmGnnDRJNB24vL/CIFZYvNr3K4CDnQ2OstobrU3d6OsTfKGKiGTB1GcTnwYzAvTBy2uy+7QbkRPEClxk9a5V0KFUOR8FVjggxJ2isqUaUtlJHk2+dwXzAfatnbtxSgxDxQhUdMGuPrHbtDQG4lQo20d0GHJhl2/GGufq2yZEMZoA1YthkWzjLLtxcZiVLPbDdKn8braUHLSdiMBUWR39vg+nWlmPyh2iC94GjF+SQg1xVXl8iXJJQ3ErtzsC1faPti69JgZaqWZ8T8pa/lBC0f+DT5H9+Klz7AkmDWaoCqRd1Bc+wAnjSfenFxxZftWgq00D7qDOVoaJRMW/wFGxhual2wZLI8U53Aj3/5rUUZY437Isq5lDun2c= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB4999.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(11063799006)(10067099003)(4143699003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?czR4Rk5JR2ZxMDVZT3pZaVFKR2crTEttWC81dnBUQ2huNzBCelZROThoTE8y?= =?utf-8?B?c1daaW0xVTFHaS9WSW1jSFljZFc5d3luTjlKT1Vtb1BwQ09GeWVoQ1V4NWdE?= =?utf-8?B?T2hMbjBIejhsR1dTQmlZMWxOcEtmcmNEaGhUaU5Vay85WlpyTGsvUVFnNERj?= =?utf-8?B?NTVEWEx0VktVOEVuMXBVRVptQWtxcjFpUTU1cHV0czJjTFdXbCtlb1g2Ly9o?= =?utf-8?B?Um95RWVWRDdnVVpUVHZNVHdzdTZFTXRFTkZBYW03Zk5zLy9JaGdLUDFjc05M?= =?utf-8?B?ZDNMY28xbGpvak5yQmw3bTJvUU12cjNhaEVtQ0lGQkgzZ21NNEkzQzlMUjVi?= =?utf-8?B?UWUzb3Q0TjFYbVdjZkFvNnhrMXR0NG5iZzl6M0F1UU5SUTk3MjFla1NUcEtV?= =?utf-8?B?RjZhVDJsTnFpV1ZLTmlrS0svWG5DMXBCOFllNjVFS1VtclRrK0RTcjgzem1S?= =?utf-8?B?RjUveXBSeFhkWkI3OGxrQmJhR2tRREZpNlFqQTZmUEpmc2l1MnRHT0RlcGM5?= =?utf-8?B?dklnMUFWZjQ1VXBieWZ6VGNjQU5heXFZckhlZ0tkUHplak01blZFL29HazR2?= =?utf-8?B?SlA1OWRZME1IWmFxZzNuaE9XTnQzcHRIVWdjV2FLTU9VcG9MN0laVHlEOVVY?= =?utf-8?B?SUR2ZGRrR0lpZ004RXV3eHdYaFRvOVc2R1NFYjdHWWdDbmNrUEZmQkhIYjZR?= =?utf-8?B?c25BODR0VG1QVGM0eXFBd241RVVhb0MrdWtvZlU0UWQzSWVGMEZZR3dsMHh6?= =?utf-8?B?SVAycTRyVEtFenY1cWthZkJhWDRLL1FLUEZDNHhqa0ttSVRKaUZ0N3d2N1RX?= =?utf-8?B?bnMwYi9ZSjlUU0pUMjVoTlpTT3BRUXE1Q1dhQ0ExU2ZBVG9nRnl6K1l2QmRS?= =?utf-8?B?TGJ1QVFGb3JLSDBGcW9ONkZpdmhwaHFrTldXUTlTRkZISUNYb1N6cHhZZHFi?= =?utf-8?B?eTREUW9yRGRiR2dwV0VrWE5CVEMzR3lwVGhUWW9hQ1hHQ3dLQ0Y4Y2hENlBP?= =?utf-8?B?SDhWVjA3OUF5a1FnYWZLTGJoMWJBODl3VHZZSlJlcUVQVFJRWjNBY2hvamUr?= =?utf-8?B?cGZ0NUZwd3pONnplYTEyaFZzTCtVdTBONDhNdUI5U2V6ZHpzaTdhMlhvNDV4?= =?utf-8?B?dHZLWWFuOVZzWk5Oc3ByTXNadXJQUDQ2L29iZnV6TkxSVnFoaCtBWGVyL01n?= =?utf-8?B?c3d2NmFXbTBuNjg2Y3hZK0dSRU91NnIxdkMxeXRUVUhmcFFFNGlJRk15UVBw?= =?utf-8?B?M3UrUkFoeFhqSEtEaWVidXI5ZFkyR0RTaDhzR2ZxaEUzQUdjTDNDM3N3b3oz?= =?utf-8?B?bGp1aSsvVG9vUmFuK2w4b1lQTHFROHNSR0FBK0xoM21nQmRGZTlnNEV1MjYr?= =?utf-8?B?V0QwQW9aQXYrbEVGQjhBUlRWS0ZwVUJPcjBOSVgwMzBnYXhSZGhFQlZSQW9Z?= =?utf-8?B?cDBIZndHY1VqdE1qaGF4bmZ2SmVpYUdQeVRQK3ZVVTM3WndMWkluQWdhNnZ2?= =?utf-8?B?OFRIcXpXTi9MYWtyN0JzSkhRcllucXdRNzdyRVc4REFtQjJhc3J5UC9zWldz?= =?utf-8?B?SGc1anduTHB1M3UwbXVIYjM3MC91K3pPYzhIUk5HdlEwM3BjYk10UjhkVXBT?= =?utf-8?B?SHUyRjFBVW9WdVg2Q1gzVnEySWlFQ0ovYjQzM0Uxb0x0SFU5NmllQ0NkaFpk?= =?utf-8?B?cXdZUUpoV3Ewejg5eWlLOHBqUFcyWHN1cHpOQXJaYWdrcnF2VXF1Y0xUNFRS?= =?utf-8?B?aW5PTC9xOEZUajZXaUsxM2lZKzNLRFpRSVMyb0JPdFZQemdYYkV4aU11ajNG?= =?utf-8?B?aFNOMmU1YlZnejVZb3dQSzZDUnk4V1d5KzVDWkFZRGVsaGhSajMvSUdUWlg2?= =?utf-8?B?cWI5NXYrMTVkVjBqYjQ0aDkvOEw4Y0YzMHcvV2haczdldWVFc1d6ejNHdSt0?= =?utf-8?B?ZzVKUnFzNGVRelZudUk3U0J5YUF6N2hIVmhJZWNRaS9DR2p6NGo5amdkQllT?= =?utf-8?B?NmVKSFpBWXVTekpYNFBVNmU0NjkyQSs1dnR4ZmNBZjBBTU5VcXVvazd0ckRC?= =?utf-8?B?QVMxL3VJbVUzUHN4a2QrWHMvb3dmTEZZUTRDUlYvM0hwMDV1VWcwWXhVbm45?= =?utf-8?B?cjArbDlZektMUXVuaU81MUNKdytMSTJvN2RHSUJXMEdQS2ZOOW5CR21hUjVa?= =?utf-8?B?RW4wYUxMTnAvWmJodWFocGtXM1NCVlBlQTBWOVJJMEwyYisrbGs1aFJCVzBs?= =?utf-8?B?ZGQyaGc4ZjE5eWJzcng1eDBSSzg4RFUxMVN2ZUZoTDJWVzZoWDJZdWlaVU5p?= =?utf-8?Q?IVctBlTqcnQO0tI3L5?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: d582f2d4-ac80-434d-cc89-08df180630d2 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2026 17:31:37.8856 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Nvd7M/NM9zmLbdE5BZtN1sCjIG6HcZxDRvIFnyfJ0twvnBw15o6iN8VWQ/93Pbqiz+ycWFxarPLXcovF5Aw8ww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7209 X-purgate-ID: tlsNG-c201ff/1790011902-722AB2A1-D73AC3A0/0/0 X-purgate-type: clean X-purgate-size: 1199 On Mon Sep 21, 2026 at 5:59 PM CEST, Andrew Cooper wrote: > On 21/09/2026 11:33 am, Alejandro Vallejo wrote: > > On Mon Sep 21, 2026 at 11:30 AM CEST, Andrew Cooper wrote: > >> On 21/09/2026 10:16 am, Alejandro Vallejo wrote: > >>> The patch in Fixes adjusted two vendor variables from uint8_t and pla= in > >>> int to to unsigned int. But they were both used later in printks with > >>> the %d specifier rather than %u. Adjust accordingly. > >>> > >>> Fixes: 39a9a49449d7 ("x86: Remove x86 prefixed names from x86/cpu/ fi= les") > >>> Signed-off-by: Alejandro Vallejo > >> If this is going to be a problem, then shouldn't we turn > >> -Wformat-signedness on? > > I tried that before sending, but that needs a whole new series. Things > > are not quite as clean as I'd hope. > > Well, it's going to keep on regressing until -Wformat-signedness is in > place. > > ~Andrew In case it wasn't obvious, I agree. I just happened to bump into these while refactoring that general area for another series and I'd rather fix them separately rather than bundling it in a 15+ patch series.=20 In due course it shall be done. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Sep 21 17:46:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 17:46:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427828.1650581 (Exim 4.92) (envelope-from ) id 1x8i6H-00013k-5j; Mon, 21 Sep 2026 17:46:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427828.1650581; Mon, 21 Sep 2026 17:46:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8i6H-00013d-3C; Mon, 21 Sep 2026 17:46:45 +0000 Received: by outflank-mailman (input) for mailman id 1427828; Mon, 21 Sep 2026 17:46:44 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8i6F-00013X-6B for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 17:46:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8i6D-00DGdE-V8 for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 19:46:41 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab16d78-2eae-0a2a0a5409dd-0a2a4504e454-14 for ; Mon, 21 Sep 2026 19:46:41 +0200 Received: from [178.33.249.249] (helo=5.mo565.mail-out.ovh.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab16d81-b57f-0a2a45040019-b221f9f9ca31-3 for ; Mon, 21 Sep 2026 19:46:41 +0200 Received: from director4.derp.mail-out.ovh.net (director4.derp.mail-out.ovh.net [79.137.60.37]) by mo565.mail-out.ovh.net (Postfix) with ESMTPS id 4hpVz44v6yz63W1; Mon, 21 Sep 2026 17:46:40 +0000 (UTC) Received: from director4.derp.mail-out.ovh.net (director4.derp.mail-out.ovh.net. [127.0.0.1]) by director4.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Mon, 21 Sep 2026 17:46:40 +0000 (UTC) Received: from mta6.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.110.188.54]) by director4.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4hpVz43BNwz1xvB; Mon, 21 Sep 2026 17:46:40 +0000 (UTC) Received: from mailstore7.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.1.8.7]) by mta6.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTP id 4D00F8E1BC7; Mon, 21 Sep 2026 17:46:39 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo-selector-1 header.d=trinity-net.com header.i="@trinity-net.com" header.h=From Date: Mon, 21 Sep 2026 17:46:39 +0000 (UTC) From: Support TRINITY To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Cc: "Rafael J. Wysocki (Intel)" , regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Huisong Li Message-ID: <750088883.289173062.1790012799166.JavaMail.zimbra@trinity-net.com> In-Reply-To: References: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [213.169.178.160] X-Authenticated-User: support@trinity-net.com Thread-Topic: ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot Thread-Index: JJ5MX6sCvA3YfJ8XBKw+R8eVLKlrew== x-ovh-tracer-id: 7890306548001371756 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: dmFkZTGzUGnqSG7fSU4vc1J/EOhw0keWUraYqIl+GujdRSX+o6s5CmvuG878t9CnLVy/dOzT9c5Wno/vmvzTE/kpj9cKFal6oOeRUTJpeBxtdOzcq9ArTwZAOopcvTsus+hI48lwvR3/EDxL6AeT8kaXBVqATYCWxGtk2M4D939oYnPD0pN5JlAtuqbP42lvWE7s6c/6uagGp5/KZRwC3MdpS+FYNYare6+Y+GgWSCsajU2GnorlsO9l4ZWxu2YnIl90kkMpGO3Op8wnuKxiUxFHjVrX5JpUJ7/JwTFTmlf2t0B0mPW0wl6h4V5KlF4kBWDyp1l6z7z7n9Yq7FHAzmhgxPtdooQgzZwd95jedm/YQsNjk8+dbr6uUBQVomff0zO1BOc0MEz8gOTVxkZ+odwEPj0YilwjJvhGJnDR/ElIfHhNho44wLpbNjVnQptFUBgp7spYHcFNV9CAiIMrXSLLbUf+njlMYFfUBwFnBTg/n5rDYat1rGgqDwJcy3qi4zqIOQ8VJc6toExjaHjhRHuXb52y4Yry5V5rPcm4GF6V7vH+hNwymq2qkAUdnUEoFTOTnw8Tw79SBOxgBQNHbZj+AIfqsYIj6YbkWYCFSUzOSyPX5T8ZszCFXBv1gEzOeTYJ1G5eMjdkHPdEE0n+W8KzkUqsh8xM3C840MQJE1V9Ci5GdA DKIM-Signature: a=rsa-sha256; bh=eEs26H6jLMUFSrdB4SPeZDbYEEF2DnyaqQKffkYXWGQ=; c=relaxed/relaxed; d=trinity-net.com; h=From; s=ovhmo-selector-1; t=1790012801; v=1; b=C0F6xWsZon2nfRwJgLBZ3xh/yqLzy9xne1B/f+hbh7D2sH3MowiOWITJOdecH/SZZtQm5gMX jjZ6CvKtOpUNsHzkrapCHgSwX4TxIi0erF16qw+yOcHFuebM3VVKN+snKyqRw/AzZy06CqiFaNh jBYYryK2zor8ATmCl6ANR4JRbrRXrxSie/hNA9X5eFObEKFYgMFQwD53cmQeyPmNHtposqhwW3k lnlAlcVU3l8FcXoyDI0E0mYCX2nt3Ero4ut1xHvqkJ3/jM8iOd835+eJ75Vsu5lf/0tVjGrcxnp rmPHi95aXuUVYv9a6WIQuBYoABsYnhs5IesMFLuNbWKfQ== X-purgate-ID: tlsNG-ebf023/1790012801-C24CBB50-04A53CAB/0/0 X-purgate-type: clean X-purgate-size: 7817 Hello, Thank you, this matches what I see on the affected Alpine Xen dom0 systems. I also tested Linux 6.18.52 with processor=3Dnocst on the Linux kernel Result: it still fails with the same black screen before dom0 userspace and networking come up. Marek's trace looks consistent with the failure mode I isolated: the crash happens from acpi_processor_power_init() while registering the cpuidle device. The working patch I tested is not a plain full revert of 6.18.52 ACPI processor changes. It restores only the previous ACPI idle driver registration lifecycle, where the ACPI idle driver is registered from acpi_processor_power_init() before the first per-CPU cpuidle device is registered, and unregistered from acpi_processor_power_exit() after the last one is removed. Compared with my first ACPI-only test revert, the refined patch keeps the unrelated 6.18.52 safety/error-handling changes, including the _LPI bounds checks and the cpufreq notifier cleanup on acpi_processor_driver_init() failure. So yes, it is very close to a targeted revert of commit 13ebeef6a1b9 ("ACPI: processor: idle: Optimize ACPI idle driver registration"), but it is intentionally narrowed to the idle registration lifecycle instead of reverting all surrounding ACPI processor changes. I agree that this points to a missing ordering/lifetime check rather than a storage, Xenbus, IOMMU, APIC, networking, or initramfs issue. I have not tested Linux 6.18.53 yet. Based on the 6.18.53 changelog, I did not see any ACPI processor/cpuidle change that appears to address this regression. Given Marek's additional data point that Linux 7.3-rc3 works fine, this looks more likely to be a stable/backport regression in 6.18.52 than a current mainline regression. I had already started a 7.3-rc4 build locally before seeing Marek's reply, so I can still report that result if useful, but it may be less important now than identifying the missing dependency or ordering check around commit 13ebeef6a1b9 in the 6.18 stable backport. Regards, Tony -----Message original----- De: Marek Marczykowski-G=C3=B3recki =C3=A0: Rafael J. Wysocki (Intel) Cc: Support TRINITY ; regressions ; linux-acpi ; linux-pm ; xen-devel ; linux-kernel = ; Huisong Li Envoy=C3=A9: lundi 21 septembre 2026 18:44 CEST Sujet : Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks ba= re-metal Xen dom0 boot On Mon, Sep 21, 2026 at 05:26:55PM +0200, Rafael J. Wysocki (Intel) wrote: > On Sun, Sep 20, 2026 at 5:48=E2=80=AFPM Support TRINITY wrote: > > > > Hello, > > > > I am reporting a bare-metal Xen dom0 boot regression seen with Linux 6.= 18.52. > > > > On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on ba= re metal, while Linux 6.18.52 consistently black-screens before dom0 usersp= ace/networking comes up. > > > > #regzbot introduced: v6.18.51..v6.18.52 > > #regzbot title: ACPI processor/cpuidle lifecycle change breaks bare-met= al Xen dom0 boot > > #regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/work_item= s/18447 > > > > Tested results: > > > > Linux 6.18.51-r0, Xen dom0, bare metal: boots > > Linux 6.18.52-r0, Xen dom0, bare metal: black screen before userspace/n= etwork >=20 > I'm wondering what's special about Xen dom0 bare metal. >=20 > Does adding processor=3Dnocst to the kernel command line help, by any cha= nce? It does not. > The patch is essentially a revert of commit 13ebeef6a1b9 ("ACPI: > processor: idle: Optimize ACPI idle driver registration") which I'd > rather not do without knowing what exactly is going on. >=20 > At this point it looks like a missing check somewhere or similar, so > it would be good to find out where exactly it crashes. I can reproduce the crash, I get this: [ 3.525669] BUG: kernel NULL pointer dereference, address: 0000000000000= 008 [ 3.525677] #PF: supervisor read access in kernel mode [ 3.525681] #PF: error_code(0x0000) - not-present page [ 3.525685] PGD 0 P4D 0=20 [ 3.525688] Oops: Oops: 0000 [#1] SMP NOPTI [ 3.525693] CPU: 0 UID: 0 PID: 21 Comm: cpuhp/0 Not tainted 6.18.52-1.qu= bes.23.fc41.x86_64 #1 PREEMPT(full)=20 [ 3.525700] Hardware name: Micro-Star International Co., Ltd. MS-7E06/PR= O Z790-P WIFI (MS-7E06), BIOS Dasharo (coreboot+UEFI) v0.9.1 01/17/2024 [ 3.525706] RIP: e030:cpuidle_register_device+0xd2/0x350 [ 3.525714] Code: 00 00 8b 55 04 49 89 c5 49 89 d4 81 fa ff 1f 00 00 0f = 87 68 02 00 00 48 8b 04 d5 c0 a0 19 82 48 83 3c 18 00 0f 85 ad 48 12 ff <49= > 8b 7d 08 48 89 14 24 e8 31 73 30 ff 84 c0 0f 84 72 01 00 00 41 [ 3.525723] RSP: e02b:ffffc90040133db8 EFLAGS: 00010246 [ 3.525727] RAX: ffff888235f5c000 RBX: ffffffff834d4d40 RCX: 00000000000= 00000 [ 3.525732] RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffff888101c= 39c00 [ 3.525736] RBP: ffff888101c39c00 R08: 4ec4ec4ec4ec4ec5 R09: ffff888101c= 39c00 [ 3.525740] R10: ffffc90040133df8 R11: 0000000000000000 R12: 00000000000= 00000 [ 3.525744] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff834= d4d40 [ 3.525752] FS: 0000000000000000(0000) GS:ffff888235f5c000(0000) knlGS:= 0000000000000000 [ 3.525757] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.525761] CR2: 0000000000000008 CR3: 000000000242c000 CR4: 00000000000= 50660 [ 3.525768] Call Trace: [ 3.525771] [ 3.525775] acpi_processor_power_init+0xde/0x150 [ 3.525782] ? __pfx_acpi_soft_cpu_online+0x10/0x10 [ 3.525787] acpi_soft_cpu_online+0x123/0x170 [ 3.525792] cpuhp_invoke_callback+0x134/0x470 [ 3.525797] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 3.525802] cpuhp_thread_fun+0xa2/0x170 [ 3.525806] smpboot_thread_fn+0xf3/0x220 [ 3.525810] kthread+0xfc/0x240 [ 3.525814] ? __pfx_kthread+0x10/0x10 [ 3.525818] ? __pfx_kthread+0x10/0x10 [ 3.525822] ret_from_fork+0x158/0x170 [ 3.525827] ? __pfx_kthread+0x10/0x10 [ 3.525830] ret_from_fork_asm+0x1a/0x30 [ 3.525835] [ 3.525837] Modules linked in: [ 3.525842] CR2: 0000000000000008 [ 3.525845] ---[ end trace 0000000000000000 ]--- [ 3.525849] RIP: e030:cpuidle_register_device+0xd2/0x350 [ 3.525854] Code: 00 00 8b 55 04 49 89 c5 49 89 d4 81 fa ff 1f 00 00 0f = 87 68 02 00 00 48 8b 04 d5 c0 a0 19 82 48 83 3c 18 00 0f 85 ad 48 12 ff <49= > 8b 7d 08 48 89 14 24 e8 31 73 30 ff 84 c0 0f 84 72 01 00 00 41 [ 3.525862] RSP: e02b:ffffc90040133db8 EFLAGS: 00010246 [ 3.525866] RAX: ffff888235f5c000 RBX: ffffffff834d4d40 RCX: 00000000000= 00000 [ 3.525870] RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffff888101c= 39c00 [ 3.525874] RBP: ffff888101c39c00 R08: 4ec4ec4ec4ec4ec5 R09: ffff888101c= 39c00 [ 3.525878] R10: ffffc90040133df8 R11: 0000000000000000 R12: 00000000000= 00000 [ 3.525882] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff834= d4d40 [ 3.525889] FS: 0000000000000000(0000) GS:ffff888235f5c000(0000) knlGS:= 0000000000000000 [ 3.525894] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.525898] CR2: 0000000000000008 CR3: 000000000242c000 CR4: 00000000000= 50660 [ 3.525904] Kernel panic - not syncing: Fatal exception [ 3.525931] Kernel Offset: disabled And I have also another data point: Linux 7.2.6 is _not_ affected. And similarly, Linux 7.3-rc3 works fine (haven't tried -rc4 yet). --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab From xen-devel-bounces@lists.xenproject.org Mon Sep 21 17:54:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 17:54:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427764.1650591 (Exim 4.92) (envelope-from ) id 1x8iDw-0002l7-Tp; Mon, 21 Sep 2026 17:54:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427764.1650591; Mon, 21 Sep 2026 17:54:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8iDw-0002l0-Qv; Mon, 21 Sep 2026 17:54:40 +0000 Received: by outflank-mailman (input) for mailman id 1427764; Mon, 21 Sep 2026 16:28:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8gsq-0005zp-Bp for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 16:28:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8gsp-0059C1-Gf for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 18:28:47 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab15b2f-e002-0a2a0a5209dd-0a2a450a9c90-8 for ; Mon, 21 Sep 2026 18:28:47 +0200 Received: from [74.125.228.12] (helo=mail-pz2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab15b3d-f2d2-0a2a450a0019-4a7de40cb546-3 for ; Mon, 21 Sep 2026 18:28:47 +0200 Received: by mail-pz2-f12.google.com with SMTP id d2e1a72fcca58-8631d0023daso2349552b3a.2 for ; Mon, 21 Sep 2026 09:28:46 -0700 (PDT) Received: from SANGHOON. ([1.220.132.212]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cc72aee0fbasm3746033a12.25.2026.09.21.09.28.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 09:28:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790008125; x=1790612925; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ySNS+GwrhibfzjzLbLOnb295wmy2g2Ft16DvkrgaNXI=; b=GBGAgbM4cXGR1NqBuBKqr+HlU/ZQh54f5yER2/9ZUCTjBEgIljRpx0BROTfUmrxwQI eL7dkk9mM4k31JbRrEHybJvEoOb2PNjzkgb4zYa4YcA0PyuW4E/qjsYAQw6Vf2cpVj+Q 3bMv0d/cLZI+wMU/dR+rBlMcMhr/JiL7hecwmNYKgn+vlfvcmOOqTQFxbQefyr5L+6wh nEVLTSGNTqW3aqLLicSzwI6YtiA5RIuV872gaF9geKKRqhn5wVQIlWNHym3X+MIzyxfZ sE9B/6ux4QK2oH5459AcCO7BC1A94nj+JNg9pvBdDFw3Gu5E8Ld5MC5WNZHtwzQYUNur HUxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790008125; x=1790612925; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=ySNS+GwrhibfzjzLbLOnb295wmy2g2Ft16DvkrgaNXI=; b=l1jXrNulWf0pPyTKcnCLPbQ3y45EVGv2UA5zJNliNh+WVRGebLnX0ng4oioAXKIoH5 fORSxwS8XqU5NXS9aZ2KFt3jCr7QBNXjyU7Sx4d2KHxLvyfbBgUXErPaYo2KevoGNuwa ebpl4IYimTYqp7A77E0iP5wUJ9/8yQB7kr5VAZps5+HSZ9ylMRA4oK4RIQQp6/4094ja aWatfYTq97W3l0rAKF1MewkKivIz8YafZGZkbyM8LhQW041QnGZbaaXEV0WOzRZSGaZK M3f83TJTwJICVwGBThiw6CfuFxsFRtbEqoq1pQt4AC1mFQnXHSgkaLxdsmsnr/FpNcLV TUOQ== X-Forwarded-Encrypted: i=1; AKwUvBwfhWiva0meoCZR+nla3utjvi8K3+tgj0JcSjN1DTfSlRoH426gCur861MPyMMlfBNcR9aMU2lA3fk=@lists.xenproject.org X-Gm-Message-State: AFuF++mYiKmmQzYFlBKZzHRvtjEmX2uYThEpf6Z2z/duIpLkfaESgdS7 tVygoVBREEZH7pnLjk92BCOcrijJ+B6N/M1mFYi6OSbBwNQJxvlSdXp2GSnKAtar X-Gm-Gg: AYBFou1mw/moaFR7RXgPxKA0ScpFnnexIHur0yOx8exbpt12Vd0j/P9SdNbzIXYQ3xs NBexo9p2iITevHwRuM/ZJNGEbBVh8+iz7TGdFemZINzLyiZWY5G84mkx4EdHybi7JMdzQN7YFL0 ldjDHsxDZnxqEdVGsEV/Y9JFit+FRImq6DEMxlabljV17zULt5rVGVBFLu0PG638ttWeQNynVyn nwu9stXIP0ypMQUajU1JS75/QtXQbGTL+PaDpsSQ4QIv3H+632pJno4a1Cubbb7U2pCE1EBMN7s NMf7O9a2lgKgtI6c7a+zB1RLtn0i4Yh8+ImDkNg1waJDTcWxZlVm4mVtSOspItkwxXcS6mPNtEO wRGq0P1lSKqn4e+5DaUn1oLv9wawVHMGXC1ANfmg7yr3MKcgwEZyV7h0zB1PU/OndGLyUi5BClJ UHw0wLfgDwu72RlK8ckIomxoyRhM0rrTwKgcmE/E8aIZt72y3WB+fQBImJ6XKTDRKOY9evxtEpW 2NiN3kIX9v2wDfil0Vb0+k6 X-Received: by 2002:a05:6a20:c90e:b0:3dd:a195:dd5f with SMTP id adf61e73a8af0-3dda195e43fmr11708071637.65.1790008125115; Mon, 21 Sep 2026 09:28:45 -0700 (PDT) From: Sang-Hoon Choi To: Juergen Gross , Stefano Stabellini Cc: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Changyul Lee Subject: [RFC] xen/pvcalls: possible bind/disconnect mapping lifetime race Date: Tue, 22 Sep 2026 01:28:34 +0900 Message-ID: <179000811428.1227592.17782105050930623388.idr-bug-82@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1790008127-599C1CFC-F483B92E/0/0 X-purgate-type: clean X-purgate-size: 2363 Hi, I would like to report a possible race between pvcalls_back_bind() and backend_disconnect(), found during source review. The source reviewed is mainline commit 5dd1818b15d98d4a20806cd00b1b40320b06004f. pvcalls_back_bind() inserts a new sockpass_mapping into socketpass_mappings under socket_lock, then drops that lock before installing the socket callbacks: radix_tree_insert(..., map); up(&fedata->socket_lock); write_lock_bh(&map->sock->sk->sk_callback_lock); map->saved_data_ready = map->sock->sk->sk_data_ready; map->sock->sk->sk_user_data = map; map->sock->sk->sk_data_ready = pvcalls_pass_sk_data_ready; backend_disconnect() takes socket_lock, removes passive mappings, and calls pvcalls_back_release_passive(). That function restores the socket callback, releases the socket, destroys the workqueue, and frees the mapping. The request IRQ is unbound only after this cleanup. If disconnect overlaps the threaded request handler, this appears to allow the mapping to be freed between insertion and callback setup: bind handler disconnect ------------ ---------- insert map drop socket_lock take socket_lock remove and release map access map->sock A draft change holds socket_lock through callback setup. This preserves the socket_lock -> sk_callback_lock order used during disconnect and addresses the interval above. It is not a complete teardown fix: an in-flight handler could still insert a mapping after disconnect has finished walking the tree. Quiescing the request IRQ before freeing mappings may be the better approach, but needs a separate teardown and deadlock review. The narrow draft was compile-checked as pvcalls-back.o with W=1 in an x86 allmodconfig build at the commit above and passed checkpatch. It has not been tested in a Xen frontend/backend setup. There is no runtime reproducer or sanitizer trace, and no security impact has been established. XEN_PVCALLS_BACKEND is marked experimental in Kconfig. Is there synchronization outside these functions that prevents the request handler from overlapping backend_disconnect()? Reported-by: Changyul Lee Assisted-by: LLM Thanks, Sang-Hoon Choi From xen-devel-bounces@lists.xenproject.org Mon Sep 21 18:05:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 18:05:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427844.1650600 (Exim 4.92) (envelope-from ) id 1x8iO3-0004a0-Q5; Mon, 21 Sep 2026 18:05:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427844.1650600; Mon, 21 Sep 2026 18:05:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8iO3-0004Zt-N5; Mon, 21 Sep 2026 18:05:07 +0000 Received: by outflank-mailman (input) for mailman id 1427844; Mon, 21 Sep 2026 18:05:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8iO2-0004Zn-2R for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 18:05:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8iO1-00DvTr-0U for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 20:05:05 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab171c1-2eae-0a2a0a5409dd-0a2a450bdb16-28 for ; Mon, 21 Sep 2026 20:05:04 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab171cf-b7e8-0a2a450b0019-aceafc1f9f04-3 for ; Mon, 21 Sep 2026 20:05:04 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id AFEF543E19 for ; Mon, 21 Sep 2026 18:05:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9046C1F0089E for ; Mon, 21 Sep 2026 18:05:02 +0000 (UTC) Received: by mail-lr2-f12.google.com with SMTP id 38308e7fff4ca-3a59fa3112cso29355011fa.3 for ; Mon, 21 Sep 2026 11:05:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790013902; bh=z+XbqSwIlygDp/k2jWmjBOZ00p46tZ3MqZOaYtXteAg=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=FFXk9FkAVeSJkZn2IAoXZobgrULqUsGgEK+GSFO8kHuCe/vAqr1KbzXEq5dAjhDRB AZ15mJ6dw4r6oBCKcL+x3+kCCD+ceJHbbt06Z/sWJWtWit2O3AOKCz7pyU/vxDOutQ MfzfRvx1FZATnhYHsNd1YXwgkdT6Y+HEr2VRhaezyYiJ5SPTJydrBrBDrF62HW+aY+ bh7BrvPWfgIMgsSXXqfa0JHvRmjoB9RB0o/kMZ3b4B6PS5hCBC/Oe6WtlR/Z+j/3jA zIWHyLjsEuCd9rcjwnHZMndwHNw/ngfc2pDF/+/Xy8da/oUcjgxLrP7vZCV9xIvwYm GUsH9AXs4CEng== X-Forwarded-Encrypted: i=1; AKwUvBwuPnM9M/PCSt3Qv4eTFuJ5S6kNZh1J0EwIDQebRzUtb/3qEE/EMTbXgpl/NxfohpT/xPgI6aUVXww=@lists.xenproject.org X-Gm-Message-State: AFuF++nNaXtBSDirskZOyysmeI+OirhKjAtQY/n4Z44iaeRGpIQf7Khe Umr2A4CYnLI7AfcFvKLAIC10hxADSEc74yn+6HktlK4hE4PleySc658ElAFuyfVhGzm6mcZnKUb IxZyTNmn0IooiUMs/bHcD8XggV0M8xdM= X-Received: by 2002:a2e:be28:0:b0:39f:1b37:82bd with SMTP id 38308e7fff4ca-3a5fbe6a277mr23646281fa.11.1790013900691; Mon, 21 Sep 2026 11:05:00 -0700 (PDT) MIME-Version: 1.0 References: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> In-Reply-To: From: "Rafael J. Wysocki (Intel)" Date: Mon, 21 Sep 2026 20:03:28 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1Vj0ZFSOOwh98D75XigHm-CPGlbbuwMjMKPEsP5Ta1JIqAFG3h-Yf_ZOC8 Message-ID: Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Cc: "Rafael J. Wysocki (Intel)" , Support TRINITY , regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Huisong Li , Stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1790013904-190CD9EA-171FA82A/0/0 X-purgate-type: clean X-purgate-size: 5820 On Mon, Sep 21, 2026 at 6:44=E2=80=AFPM Marek Marczykowski-G=C3=B3recki wrote: > > On Mon, Sep 21, 2026 at 05:26:55PM +0200, Rafael J. Wysocki (Intel) wrote= : > > On Sun, Sep 20, 2026 at 5:48=E2=80=AFPM Support TRINITY wrote: > > > > > > Hello, > > > > > > I am reporting a bare-metal Xen dom0 boot regression seen with Linux = 6.18.52. > > > > > > On affected systems, Linux 6.18.51 boots successfully as Xen dom0 on = bare metal, while Linux 6.18.52 consistently black-screens before dom0 user= space/networking comes up. > > > > > > #regzbot introduced: v6.18.51..v6.18.52 > > > #regzbot title: ACPI processor/cpuidle lifecycle change breaks bare-m= etal Xen dom0 boot > > > #regzbot link: https://gitlab.alpinelinux.org/alpine/aports/-/work_it= ems/18447 > > > > > > Tested results: > > > > > > Linux 6.18.51-r0, Xen dom0, bare metal: boots > > > Linux 6.18.52-r0, Xen dom0, bare metal: black screen before userspace= /network > > > > I'm wondering what's special about Xen dom0 bare metal. > > > > Does adding processor=3Dnocst to the kernel command line help, by any c= hance? > > It does not. > > > The patch is essentially a revert of commit 13ebeef6a1b9 ("ACPI: > > processor: idle: Optimize ACPI idle driver registration") which I'd > > rather not do without knowing what exactly is going on. > > > > At this point it looks like a missing check somewhere or similar, so > > it would be good to find out where exactly it crashes. > > I can reproduce the crash, I get this: > > [ 3.525669] BUG: kernel NULL pointer dereference, address: 00000000000= 00008 > [ 3.525677] #PF: supervisor read access in kernel mode > [ 3.525681] #PF: error_code(0x0000) - not-present page > [ 3.525685] PGD 0 P4D 0 > [ 3.525688] Oops: Oops: 0000 [#1] SMP NOPTI > [ 3.525693] CPU: 0 UID: 0 PID: 21 Comm: cpuhp/0 Not tainted 6.18.52-1.= qubes.23.fc41.x86_64 #1 PREEMPT(full) > [ 3.525700] Hardware name: Micro-Star International Co., Ltd. MS-7E06/= PRO Z790-P WIFI (MS-7E06), BIOS Dasharo (coreboot+UEFI) v0.9.1 01/17/2024 > [ 3.525706] RIP: e030:cpuidle_register_device+0xd2/0x350 > [ 3.525714] Code: 00 00 8b 55 04 49 89 c5 49 89 d4 81 fa ff 1f 00 00 0= f 87 68 02 00 00 48 8b 04 d5 c0 a0 19 82 48 83 3c 18 00 0f 85 ad 48 12 ff <= 49> 8b 7d 08 48 89 14 24 e8 31 73 30 ff 84 c0 0f 84 72 01 00 00 41 > [ 3.525723] RSP: e02b:ffffc90040133db8 EFLAGS: 00010246 > [ 3.525727] RAX: ffff888235f5c000 RBX: ffffffff834d4d40 RCX: 000000000= 0000000 > [ 3.525732] RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffff88810= 1c39c00 > [ 3.525736] RBP: ffff888101c39c00 R08: 4ec4ec4ec4ec4ec5 R09: ffff88810= 1c39c00 > [ 3.525740] R10: ffffc90040133df8 R11: 0000000000000000 R12: 000000000= 0000000 > [ 3.525744] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff8= 34d4d40 > [ 3.525752] FS: 0000000000000000(0000) GS:ffff888235f5c000(0000) knlG= S:0000000000000000 > [ 3.525757] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 3.525761] CR2: 0000000000000008 CR3: 000000000242c000 CR4: 000000000= 0050660 > [ 3.525768] Call Trace: > [ 3.525771] > [ 3.525775] acpi_processor_power_init+0xde/0x150 > [ 3.525782] ? __pfx_acpi_soft_cpu_online+0x10/0x10 > [ 3.525787] acpi_soft_cpu_online+0x123/0x170 > [ 3.525792] cpuhp_invoke_callback+0x134/0x470 > [ 3.525797] ? __pfx_smpboot_thread_fn+0x10/0x10 > [ 3.525802] cpuhp_thread_fun+0xa2/0x170 > [ 3.525806] smpboot_thread_fn+0xf3/0x220 > [ 3.525810] kthread+0xfc/0x240 > [ 3.525814] ? __pfx_kthread+0x10/0x10 > [ 3.525818] ? __pfx_kthread+0x10/0x10 > [ 3.525822] ret_from_fork+0x158/0x170 > [ 3.525827] ? __pfx_kthread+0x10/0x10 > [ 3.525830] ret_from_fork_asm+0x1a/0x30 > [ 3.525835] > [ 3.525837] Modules linked in: > [ 3.525842] CR2: 0000000000000008 > [ 3.525845] ---[ end trace 0000000000000000 ]--- > [ 3.525849] RIP: e030:cpuidle_register_device+0xd2/0x350 > [ 3.525854] Code: 00 00 8b 55 04 49 89 c5 49 89 d4 81 fa ff 1f 00 00 0= f 87 68 02 00 00 48 8b 04 d5 c0 a0 19 82 48 83 3c 18 00 0f 85 ad 48 12 ff <= 49> 8b 7d 08 48 89 14 24 e8 31 73 30 ff 84 c0 0f 84 72 01 00 00 41 > [ 3.525862] RSP: e02b:ffffc90040133db8 EFLAGS: 00010246 > [ 3.525866] RAX: ffff888235f5c000 RBX: ffffffff834d4d40 RCX: 000000000= 0000000 > [ 3.525870] RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffff88810= 1c39c00 > [ 3.525874] RBP: ffff888101c39c00 R08: 4ec4ec4ec4ec4ec5 R09: ffff88810= 1c39c00 > [ 3.525878] R10: ffffc90040133df8 R11: 0000000000000000 R12: 000000000= 0000000 > [ 3.525882] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff8= 34d4d40 > [ 3.525889] FS: 0000000000000000(0000) GS:ffff888235f5c000(0000) knlG= S:0000000000000000 > [ 3.525894] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 3.525898] CR2: 0000000000000008 CR3: 000000000242c000 CR4: 000000000= 0050660 > [ 3.525904] Kernel panic - not syncing: Fatal exception > [ 3.525931] Kernel Offset: disabled > > And I have also another data point: Linux 7.2.6 is _not_ affected. And > similarly, Linux 7.3-rc3 works fine (haven't tried -rc4 yet). So it is likely that the patch in question went into 6.18.y without a dependency. Let's see. In 6.18.52, acpi_processor_power_init() is called in the !cpuidle_get_driver() case, which does not happen in the mainline. AFAICS, 6.18.y needs to pick up commit 0089ce1c056a ("ACPI: processor: Update cpuidle driver check in __acpi_processor_start()") whose Fixes: tag should really point to 13ebeef6a1b9 which is a re-introduction of 7a8c994cbb2d originally fixed by 8a1b5d412cb4. Thanks! From xen-devel-bounces@lists.xenproject.org Mon Sep 21 18:07:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 18:07:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427852.1650608 (Exim 4.92) (envelope-from ) id 1x8iQP-00059R-9B; Mon, 21 Sep 2026 18:07:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427852.1650608; Mon, 21 Sep 2026 18:07:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8iQP-00059K-6H; Mon, 21 Sep 2026 18:07:33 +0000 Received: by outflank-mailman (input) for mailman id 1427852; Mon, 21 Sep 2026 18:07:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8iQO-00059E-9d for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 18:07:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8iQN-007iEg-JP for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 20:07:31 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab17256-e002-0a2a0a5209dd-0a2a450886e0-32 for ; Mon, 21 Sep 2026 20:07:31 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab17262-f659-0a2a45080019-ac6904fec8f4-3 for ; Mon, 21 Sep 2026 20:07:31 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id CACEC60008 for ; Mon, 21 Sep 2026 18:07:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84C171F00893 for ; Mon, 21 Sep 2026 18:07:29 +0000 (UTC) Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-3a20f06cce6so1573581fa.1 for ; Mon, 21 Sep 2026 11:07:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="References:In-Reply-To:From:Date:Subject:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790014049; bh=CXAb4qXyR2HfG3h9rl85FbZFF/8Yznox3qCpzfz2vLc=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=KwmKbVo0csnD4CmZHT5I4JlGgwZz0kbNccMAmxxOhOHxFof1fwqdDWo2aSHrIL53T HAO53hejB/8hedynkRgQJII8/yNDXorvZeBIn1tfrR7s65FFWSCqnVWIL9oXfmXkv+ aLOOnoEZFsHPIBCd0J+UgcDbaBl8KE0UHXrOHWgAhXHSieOkx8oUCviTjMBIDlPf6+ hi0DlflroupOUR+NBkgrT2nXpmCVHtnP55A6gFCQ2uaT+YH9Q8/ivFFnVxcb5uyobo x78vn1XquG/M9pbaoeXM8hoV2aE7KcgzdAg4Rr5P7EpAzAPQZ+CdmCK8GT2cfOmfbV zHgC8tu/PMH4g== X-Forwarded-Encrypted: i=1; AKwUvBwYL1lc1WrBOgCuY4djiVMyovqyGrEX7Wnq21lJIkf0icLei7vKUUrb+7vmjIxHz9eyOLGq4V3ZFSc=@lists.xenproject.org X-Gm-Message-State: AFuF++ksGVGqDrR2wJBE/a2kTCx7eVjm4SX0rIIZYxGzknbu3k2LIFUz SAJIxUqTUP48/MYXPBOWIOwVwxDkaKFq1P7O+I4XV4vgrnIBL13EsILCoYzE6Ug/LmQSrwpZM3a UZQdT7AFdTWlY1x16uu0vcX8WaZm8p08= X-Received: by 2002:a05:651c:a332:b0:3a3:61ec:43c2 with SMTP id 38308e7fff4ca-3a624db5e2fmr1038641fa.19.1790014047909; Mon, 21 Sep 2026 11:07:27 -0700 (PDT) MIME-Version: 1.0 References: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> <750088883.289173062.1790012799166.JavaMail.zimbra@trinity-net.com> In-Reply-To: <750088883.289173062.1790012799166.JavaMail.zimbra@trinity-net.com> From: "Rafael J. Wysocki (Intel)" Date: Mon, 21 Sep 2026 20:05:57 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1V_NwSYYWm7WSWXzLbFIgtKPrMvHv-S_2NNL56zDEZOELuQBCN1u-UNlmU Message-ID: Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot To: Support TRINITY Cc: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , "Rafael J. Wysocki (Intel)" , regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c1860d/1790014051-D795A87B-4B8000C6/0/0 X-purgate-type: clean X-purgate-size: 695 On Mon, Sep 21, 2026 at 7:46=E2=80=AFPM Support TRINITY wrote: > > Hello, > > Thank you, this matches what I see on the affected Alpine Xen dom0 > systems. > > I also tested Linux 6.18.52 with processor=3Dnocst on the Linux kernel > > Result: it still fails with the same black screen before dom0 userspace > and networking come up. > > Marek's trace looks consistent with the failure mode I isolated: the > crash happens from acpi_processor_power_init() while registering the > cpuidle device. I think I know what the problem is, see https://lore.kernel.org/linux-acpi/CAJZ5v0h4giv53a2mPvJYT=3DfvBTj7vVXs=3Db7= +qC2Q2L35qSTOSA@mail.gmail.com/ From xen-devel-bounces@lists.xenproject.org Mon Sep 21 18:29:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 21 Sep 2026 18:29:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427865.1650619 (Exim 4.92) (envelope-from ) id 1x8ilk-0008Or-0h; Mon, 21 Sep 2026 18:29:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427865.1650619; Mon, 21 Sep 2026 18:29:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ilj-0008Ok-SV; Mon, 21 Sep 2026 18:29:35 +0000 Received: by outflank-mailman (input) for mailman id 1427865; Mon, 21 Sep 2026 18:29:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ilj-0008Oe-5D for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 18:29:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8ili-00EiAx-6g for xen-devel@lists.xenproject.org; Mon, 21 Sep 2026 20:29:34 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1774f-2eae-0a2a0a5409dd-0a2a4507c880-42 for ; Mon, 21 Sep 2026 20:29:34 +0200 Received: from [46.105.44.31] (helo=5.mo564.mail-out.ovh.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1778d-b4ea-0a2a45070019-2e692c1fbd41-3 for ; Mon, 21 Sep 2026 20:29:34 +0200 Received: from director2.derp.mail-out.ovh.net (director2.derp.mail-out.ovh.net [79.137.60.36]) by mo564.mail-out.ovh.net (Postfix) with ESMTPS id 4hpWwY16nJz87rB; Mon, 21 Sep 2026 18:29:33 +0000 (UTC) Received: from director2.derp.mail-out.ovh.net (director2.derp.mail-out.ovh.net. [127.0.0.1]) by director2.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Mon, 21 Sep 2026 18:29:33 +0000 (UTC) Received: from mta7.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.109.231.30]) by director2.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4hpWwY0Jt5z1xp3; Mon, 21 Sep 2026 18:29:33 +0000 (UTC) Received: from mailstore7.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.1.8.7]) by mta7.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTP id 2C3E3B81C5B; Mon, 21 Sep 2026 18:29:32 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo-selector-1 header.d=trinity-net.com header.i="@trinity-net.com" header.h=From Date: Mon, 21 Sep 2026 18:29:32 +0000 (UTC) From: Support TRINITY To: "Rafael J. Wysocki (Intel)" Cc: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= , "Rafael J. Wysocki (Intel)" , regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Stable Message-ID: <1909296988.289641012.1790015372050.JavaMail.zimbra@trinity-net.com> In-Reply-To: References: <905771062.272724286.1789919301858.JavaMail.zimbra@trinity-net.com> <750088883.289173062.1790012799166.JavaMail.zimbra@trinity-net.com> Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [213.169.178.160] X-Authenticated-User: support@trinity-net.com Thread-Topic: ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot Thread-Index: NJLEBWSSWTxHlP+F8t+OBJCvRxFPqg== x-ovh-tracer-id: 8614541665962587675 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: dmFkZTGlMSjzMXFz4ipw5mo6C1GD1JTY1bhHZVs/p5Nv78Znzkhq/k5NZSemwOJrLkzTGnUzuV0P/CTidewhj7HXiC0xfdN+5BaQEY8b3Kwct82UB6zjNGfqm7kJb4ttjwgACxdgPLh28GyRgxbQdrzMMGLFU4TEKIBs/Hh/ceN1Ms8ygaAkZa73h/yWpK10Zk+rPH2CFV4DqCBe6v/FcGsC5wPEGnDFVYlvd9IBdmSLOpOraDnlklBSiGLwer90wPuuQCpMujjVvhFtN0P1Oz74+OkrfJx/Jy5A4CUoHvG19uKnRaPEM3CpSTQsCAUgou9SCvuq9JVZsKk9ivIous6fBlSjZ7Z7/Jjn5OzVnC++aJqeBliXUKmxjzvGg2M6Fd0m0BF5aPPVc2cc37vdPCpjL5mXCfVqvzWz4U18syj1KDv4yjaiMSHUk46h3992+zDjBAWdKcBQ6W7VWeiG9YtWP5EimiGuAjzW05zdL4fyq5avG/IGV9b4I/zT3euOpFSSmXC60MqmO9zIXqVc3KJH753bxtVK4VKSCbhNwoX2cX3XzYsiLX8Yvh8tULu32jL5zJ423LULpLitttfsvYREBBOP4sKgzZmb719gBBRa/EV02sDW8ufbUjS6z10SAS7esMwLu1EOHzNBh3dEpP0E4RRroixZggB5S1JvVPhXSCiYtA DKIM-Signature: a=rsa-sha256; bh=IevpoNZUdNHiZNaAd8TIxxp6Ai1AoI8OzFr7NwXjpT8=; c=relaxed/relaxed; d=trinity-net.com; h=From; s=ovhmo-selector-1; t=1790015373; v=1; b=SWCas21S6jgUkey7Pctwpi5A1HH+1Teaj1FMFU60FF+y6ADgSfJkAx0zCroA2Q+A+PuHs1+s 1g0+8j4nyaGafOo/4es9hi5OFB+M5U7l00jYO38PRNAQNnGL+DcOBaBlcMynflLysfjtgbK9STj K7peWk5eJEJs2dHYQ+PzyDaJ+nfqJR8HQc7Nq2xTzZ7Z3Di2xncyVKULZt/8C/VfSmKy1tVV3be lVhVJS16oZDxnDLi4BwQgPWxE1DXQLXMexKnIjff0a+HNED62AYx0U8TabTrTaztf4RhgVRR7Gd x4HFNYwju0WotFHLv5drWc7SVfZOP++XWpGv89qzL33hw== X-purgate-ID: tlsNG-ef75cf/1790015374-A7CD7AE4-50AB1B90/0/0 X-purgate-type: clean X-purgate-size: 2043 Hello, Thank you, that makes sense and matches the behavior I observed. The Alpine 6.18.52 kernel fails as Xen dom0, while restoring the previous ACPI idle registration lifecycle makes it boot again. That is consistent with 13ebeef6a1b9 being present in 6.18.y without the later dependency that avoids calling acpi_processor_power_init() in the !cpuidle_get_driver(= ) case. I will try testing 6.18.52 with commit 0089ce1c056a ("ACPI: processor: Update cpuidle driver check in __acpi_processor_start()") applied, instead of using my lifecycle revert. If that boots successfully on the affected Alpine Xen dom0 hosts, I will report the result here. Thanks, Tony -----Message original----- De: Rafael J. Wysocki (Intel) =C3=A0: Support TRINITY Cc: Marek Marczykowski-G=C3=B3recki ; Rafa= el J. Wysocki (Intel) ; regressions ; linux-acpi ; linux-pm ; xen-devel ; linux-kernel ; Stable Envoy=C3=A9: lundi 21 septembre 2026 20:07 CEST Sujet : Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks ba= re-metal Xen dom0 boot On Mon, Sep 21, 2026 at 7:46=E2=80=AFPM Support TRINITY wrote: > > Hello, > > Thank you, this matches what I see on the affected Alpine Xen dom0 > systems. > > I also tested Linux 6.18.52 with processor=3Dnocst on the Linux kernel > > Result: it still fails with the same black screen before dom0 userspace > and networking come up. > > Marek's trace looks consistent with the failure mode I isolated: the > crash happens from acpi_processor_power_init() while registering the > cpuidle device. I think I know what the problem is, see https://lore.kernel.org/linux-acpi/CAJZ5v0h4giv53a2mPvJYT=3DfvBTj7vVXs=3Db7= +qC2Q2L35qSTOSA@mail.gmail.com/ From xen-devel-bounces@lists.xenproject.org Tue Sep 22 00:14:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 00:14:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427934.1650627 (Exim 4.92) (envelope-from ) id 1x8o9R-0000zn-7l; Tue, 22 Sep 2026 00:14:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427934.1650627; Tue, 22 Sep 2026 00:14:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8o9R-0000zf-30; Tue, 22 Sep 2026 00:14:25 +0000 Received: by outflank-mailman (input) for mailman id 1427934; Tue, 22 Sep 2026 00:14:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8o9P-0000zZ-Ui for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 00:14:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8o9O-00Dvsi-IG for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 02:14:22 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1c820-e002-0a2a0a5209dd-0a2a4503c75a-6 for ; Tue, 22 Sep 2026 02:14:22 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1c857-fae8-0a2a45030019-aceafc1fa014-3 for ; Tue, 22 Sep 2026 02:14:17 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 22E4542A2E; Tue, 22 Sep 2026 00:14:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF3581F000FF; Tue, 22 Sep 2026 00:14:13 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790036055; bh=iRwgTG+6pfPpNDDDQwwShuFshTcDHmTBQfdIOhFcbFo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=P193QOsBKu0TrKC+zUIj1uuiNMIYQeodQt0ffKeSbEhYAKz/ySoyGKe2khENAQHtV K3zSNNoq8USY+LQE+U0ViH5nZdxrdFk0c2A5YXZPCFgXfqFINXwIpaPFjpQVUxpEGZ GxvuJo39u/e32KnUjSydY+YNwKBxO4wBDv24+kKBs62ooDkUGjc1BPYQGGxAbEhUKY lz3EPSunIMasrmMKlGaf8Tu1yQBV8+6oFFFbW/PWummR7xtp8QYxclVBZ8wbPqFyEj AGHA7CsfcmBm+FmUYJVShhPE02VmbuePMdJt4rO/lNG89fuHCaafdR8ZU95qHNg75f BS89yVTa1KVXA== Date: Mon, 21 Sep 2026 17:14:09 -0700 (PDT) From: Stefano Stabellini To: Jan Beulich cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini Subject: Re: [PATCH 6/6] automation/Eclair: tag rules 18.1 and 18.2 as clean In-Reply-To: <486cf199-33fa-4373-965c-d59a782ae6d4@suse.com> Message-ID: <22bc8842-8540-36a4-28fc-5a6e0d933f4a@kernel.org> References: <486cf199-33fa-4373-965c-d59a782ae6d4@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-purgate-ID: tlsNG-33051d/1790036062-770F64E9-36839A19/0/0 X-purgate-type: clean X-purgate-size: 571 On Wed, 9 Sep 2026, Jan Beulich wrote: > Remaining (x86) 18.2 violations were addressed. 18.1 was already clean > everywhere. > > Signed-off-by: Jan Beulich Assuming they are still clean: Acked-by: Stefano Stabellini > --- a/automation/eclair_analysis/ECLAIR/tagging.ecl > +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl > @@ -80,6 +80,8 @@ MC3A2.R17.3|| > MC3A2.R17.4|| > MC3A2.R17.5|| > MC3A2.R17.6|| > +MC3A2.R18.1|| > +MC3A2.R18.2|| > MC3A2.R18.6|| > MC3A2.R18.8|| > MC3A2.R19.1|| > From xen-devel-bounces@lists.xenproject.org Tue Sep 22 00:59:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 00:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427942.1650636 (Exim 4.92) (envelope-from ) id 1x8or5-0006LS-E9; Tue, 22 Sep 2026 00:59:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427942.1650636; Tue, 22 Sep 2026 00:59:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8or5-0006LL-Am; Tue, 22 Sep 2026 00:59:31 +0000 Received: by outflank-mailman (input) for mailman id 1427942; Tue, 22 Sep 2026 00:59:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8or4-0006LF-Bq for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 00:59:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8or3-005z60-LT for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 02:59:29 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1d2ec-e002-0a2a0a5209dd-0a2a4501db2e-0 for ; Tue, 22 Sep 2026 02:59:24 +0200 Received: from [52.101.65.89] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1d2ec-5984-0a2a45010019-34654159cabb-3 for ; Tue, 22 Sep 2026 02:59:24 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS8PR03MB6983.eurprd03.prod.outlook.com (2603:10a6:20b:23d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 00:59:22 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 00:59:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gfa256eFZ1FOCcE+3D8x5OrE8JxyFpw3k0VKM+wTMbNsCdJ3d7zLV67/UBz7qGw5uqDe7eLg7gabhv+1zDW+W+ZlKt4uWmxD4wP91XvuuyHIqHE7z2Dozt8ILtDFtTJA0vtNthRzS3N3JPENztiYQE9HkYPiJg87N2dxSqg8B3YldaJLiDy7+pDlEhZbYq6ETcCXpo+uH9SxGWWRxsaJQm4miGXnEVGyZ3N76j7sfIhbCfG+0VPwj4opfbv7iDSSdU4lg0JNsyhcT1VhSHB4Lsn6gyCKER46eIbYBtau7EE3TxZIEfMOV9QvUeHM3alcnxCjo4zcIJQluCBvG20N4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T58ry/DBgQKEZ7zfvIu9jQc53/jaEQ7W+BUtqbBmDpY=; b=Zae/xFnkQqA0+5CAbEdsE11ioMCOF4HPCrLmcF1HwkLp5fooqBMotidJ6j5rnfR5CvGNPPZ4devJrSIxIBlKLiUm7+EZeOcLbiw1IZoYiaaBaWopVst6Klm2TukvBP4qHpAZG0vuXzlKZ3e4fISVcsAp8WeBDjpb93IjP3KFBzNOCwSvfA9r2vpObWb8Spq0HpgFdSDO3Cn6GiNuVbQbLPRJ0HiZ0GdG82eal8vHm4FeSvfa2Hq3/S997IzGwg6YGHTSe+DDkYf6/S+UINY4S3XdMIXTrzOm1MlZXahMp+C6zsnCyrVsN5XnkxCkJHx8vcIeockfeNQcJD4bxatZWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T58ry/DBgQKEZ7zfvIu9jQc53/jaEQ7W+BUtqbBmDpY=; b=OHxg5Ml4jh891Pw5XonTmFyWwogCozLgQEApVVUk4Ih7uXTwTD6HbT9evg/XDBrRJ5pLsCHup7Ek6PFqCTLVfLEHzEzeBN1Q/VQOCEd9OyOmKmQYo1pn1LvdViYijwj432e7gaqoWiSNBq50wtBIzXRGKleKxHyNge3k6PU/lw7FikYo6PV+zC9iK97ZdHWtfT7FYos5R7Qj/bwr3i/ACwjYDvYBUAfr10r1fPBOyNdF9iH5E6nswvbPpx4RWpNM3oV73qGB9M26zQOj9nh/gr1oUEpWXinG5aZ6VX4uq52hsdaFsEG2Y8HHnMT5F4cW+JQUR+qS/DqxaaP/mDbRQw== From: Volodymyr Babchuk To: Mykyta Poturai CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v9 2/6] arm/irq: Migrate IRQs during CPU up/down operations Thread-Topic: [PATCH v9 2/6] arm/irq: Migrate IRQs during CPU up/down operations Thread-Index: AQHdLu5Yaco3oEokpUOTU00/bV2IRA== Date: Tue, 22 Sep 2026 00:59:21 +0000 Message-ID: <87se3285jr.fsf@epam.com> References: <55f4839f427df6675a621bb61bfbdac4fb089382.1787042017.git.mykyta_poturai@epam.com> In-Reply-To: <55f4839f427df6675a621bb61bfbdac4fb089382.1787042017.git.mykyta_poturai@epam.com> (Mykyta Poturai's message of "Tue, 18 Aug 2026 08:48:29 +0000") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS8PR03MB6983:EE_ x-ms-office365-filtering-correlation-id: 29752742-92dc-4443-2574-08df1844bd06 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|376014|1800799024|366016|23010399003|38070700021|4143699003|10067099003|11063799006|56012099006|18002099003|22082099003; x-microsoft-antispam-message-info: 5cmUGc0tuaNYmecftMfrokGRzzj3dwSbTquLOwmbVvjaBut8JTtYkBH8f0yzT8pLVeimuLuueCwKTP0M8wlsYswj5Aw38JqccEjKQIcRINd4Gwh/h/5n6gC5GoYf69fw3DWR7IVKk2/g5C6x+Xo6VYAfawoBsDqX+tgm2h+7BX5mVPx1f8m+QfJ/V1hb3rMZWvy99NFDdsdOi/qBTp030Ac+H2p+BD9aj+bWUI5WWNORNMDW7tqPHX2d4yqYRe/Sizgou60k570xJ60iP0y3czp5kXQVgOQ+VqcaeYzp5LxIW+XjEVKLxbE4tTi3DkCD+/piKk6eQiG18FvgM0oRLYw4M7LbBT7btTi8XE38i+1ETufXUNdhLErw7v/qOW7LfCZ5LMzrLaut+3eyX6LF/dvOvdtRPi/A77O8KewSvETJbS9LYgHMU7OQ1dGJ/yqJ5eJLT42JHlr2+5oPOzdX7p+A49uTHkS/b6BV5tsDC1uiXqP0ZaumqmompqR6ILnpe/IQdnQTHauak8VuYHQIqIuAKPLza8C+AFVobNP/etHr5/HlJs4MpPsQcjj/GxDUSCvf1whTw25gGdDQl9/neh0yFzY5T4FqTRhHVZXJhF8rJr3+l2xYYi1nNUE0LVGI4KwOmN0fQ9p2xVOeAGwDHlr5mNqAGUP1wKoiLPYL/Fe8q70sICVgwvqIhI40Ggy7218WebwVBrx030u93RIQ4m9+9SXJil7MGntKdd/ZOKo= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(376014)(1800799024)(366016)(23010399003)(38070700021)(4143699003)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?M/MagcjHs43vQtDxLf7at4N+3mP+rYQYX01j/mHzcJJbYB+sAAxqLaBCrN?= =?iso-8859-1?Q?2E9QlAG+MQIuLusuuFiE3vX21FJlPg4ZOoQhsRTwcvdimoFqKmg6MR0ssw?= =?iso-8859-1?Q?XPknAPgMJorRzmuiOo2xpi+0nvL4lubix/Hss1B3kUKLnzkQlYtCikOqW8?= =?iso-8859-1?Q?h6zPCIJytEuYcQRsv3h25SdycF8YaisDglacTT4EZa+lrdE0oCR0eI8/z8?= =?iso-8859-1?Q?JDN6wJQpdAHUJeDyn+vYuvpN0Ea1zkjHLcNtZXJBBo6goZOWi6lM0XZ58W?= =?iso-8859-1?Q?4QtqZ9GPkjF1/BB5rOQXs0TGlmnp00s8t2CbK7d75s0ES+AFN6peghw32x?= =?iso-8859-1?Q?Rqq9aFe81/UqZvDHh/WE22WpflmxfrwAPJ6SB6svbh6hMK+eakVfL3LxqK?= =?iso-8859-1?Q?dt9ErGuUamdnSRwlEGX6Y8G6Lrhd2zL6mo/fSYWlM7txZQxvMWp0+sLZy4?= =?iso-8859-1?Q?JiA+icJw+j/i2g+dRcNry5CsTYRu56AD2YSgKpx2HLdfxVE+tmfTYNZhSD?= =?iso-8859-1?Q?kwen6SG8LkcMdlkurOyni6W+ugkzYMEpkJugct/N7qvi84CTy79RM4Rxg0?= =?iso-8859-1?Q?55RyzWNf1Pti45XBnRt99wYobj/yZ9FMYUcReFLS+kHo7okrflamh3sB2b?= =?iso-8859-1?Q?knvLoYAu5UEjyvHckm/JbMmQ86Rcrs+7sTruZjwOGl/9I/QzJgroXpN8y+?= =?iso-8859-1?Q?nu5PrHZxy1BWJrMoi1dgFF8PfZC5dA8juRb6WBfXOkG0HPW4Iellrf1+++?= =?iso-8859-1?Q?z3muZvYZO6t1Xg0n/Y6UQsg0Y9sMA8RqwVhmCUDPsCEZudPwfl57EiqpIx?= =?iso-8859-1?Q?O6na/7zfb2n7X8mz6QtUGVVrAQvLz9+svXK50ZjqpTXDTTZ3lQeOs65LBs?= =?iso-8859-1?Q?zShcU0jVR+BFy6fbrpEKV3gk/MTgm9Bn/haKQ8SL5B/jrva309SGG93Ha9?= =?iso-8859-1?Q?dsOJRBy+Ed5BkHvqs9bmyCTP5aenTnLJb+B7sU1Zw+G/Njq5NJtgeY3ffr?= =?iso-8859-1?Q?pZiXJYsEFNBsmOWIWPH/bR3ARipt5ZDkZHE508Prb/bmm6NZ+FI6U0BZsD?= =?iso-8859-1?Q?ELVA5T+2hNVfaV/tbh9z0+F8W2rEW3gBloV72nGo4DKngELjmwlh0aZlTd?= =?iso-8859-1?Q?fpGQg0Nfc4S3/KP+4GaWdRH5Yjqng1Y2XIsGcpdahPmccwzQ2Im3yMfPbc?= =?iso-8859-1?Q?D2CTujcbRYF/1shdYWKAXIWMB/LwSvYKr6uJ+5Y4MW/ilRielEmQnD0Mrb?= =?iso-8859-1?Q?h/cv5Cgi2JqY7542j2KMgJ6/y4loMvX0j9RoNZm2MfQ6DWpaYcsZn6/3vQ?= =?iso-8859-1?Q?gGKZu/EsGYtLIuGTxeP4X5SIPln4vPhvE1+DjI7eCmbi1BaMc/Zin9L0dk?= =?iso-8859-1?Q?QZOMQ+D/hB+vi2e3npOYeK1KNJspkieIfo9tg10H21VWcUc+qECyCvmw1Y?= =?iso-8859-1?Q?ZMfr3w0dh9Xn+5LU7vNcN2DqPmpoARpUDKeRlVw05qfpBD4fp8i5bH5Yh1?= =?iso-8859-1?Q?U00/MTCQTl9Jwxlwmy/02bZjn1DHf/EeGLCaVUOVNGGzMYa0EzycHOe442?= =?iso-8859-1?Q?UBhFEJXvcwUuuQY8WANemyncEMNUOcnoyC50t864WvvkPqEPXr0K32J2fm?= =?iso-8859-1?Q?ayK2TNUdO7OtiK1+uj14VsKWCp4HfnIHL66nHSgcfG+yewXHmPKIxyFVPf?= =?iso-8859-1?Q?c3rOEMqvJ8rmCG/2lqM2JRkKiNFo0cLOKLtTbFitkFN5l/sFRL4NSVk14l?= =?iso-8859-1?Q?tT2khCpAnIY/U4iCu0BcgtAYlF7it/zcznt+0BX/wTj0gZL3QPM/QUPnHj?= =?iso-8859-1?Q?3pzZEJCwf3XtAQ+A+FvnS5pDrkNevLU=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29752742-92dc-4443-2574-08df1844bd06 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 00:59:21.7908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PG56hwps7zZ2+mglwmAKX6nw6/O1k95Y3H3Pwbia5BDBYfUrnUBAx4K58+pbTo0+D8AWaxhi/W4n2mRETL8N1Mo9+S9lMuXGqWkYsUrh8BE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6983 X-purgate-ID: tlsNG-d62444/1790038764-1E867757-CD6C4A72/0/0 X-purgate-type: clean X-purgate-size: 5588 Hi Mykyta, Mykyta Poturai writes: > Move IRQs from dying CPU to the online ones when a CPU is getting > offlined. When onlining, rebalance all IRQs in a round-robin fashion. > Guest-bound IRQs are already handled by scheduler in the process of > moving vCPUs to active pCPUs, so we only need to handle IRQs used by Xen > itself. > > Signed-off-by: Mykyta Poturai > --- > v8->v9: > * replace CONFIG_CPU_HOTPLUG with CONFIG_CPU_ONLINE_OFFLINE > > v7->v8: > * check only existings ESPIs > > v6->v7: > * replace ifdef with IS_ENABLED > > v5->v6: > * don't do any balancing on boot > * only do balancing when cpu hotplug is enabled > > v4->v5: > * handle CPU onlining as well > * more comments > * fix crash when ESPI is disabled > * don't assume CPU 0 is a boot CPU > * use insigned int for irq number > * remove assumption that all irqs a bound to CPU 0 by default from the > commit message > > v3->v4: > * patch introduced > --- > xen/arch/arm/include/asm/irq.h | 6 ++++ > xen/arch/arm/irq.c | 60 ++++++++++++++++++++++++++++++++++ > xen/arch/arm/smpboot.c | 7 ++++ > 3 files changed, 73 insertions(+) > > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/ir= q.h > index 09788dbfeb..d043360135 100644 > --- a/xen/arch/arm/include/asm/irq.h > +++ b/xen/arch/arm/include/asm/irq.h > @@ -126,6 +126,12 @@ bool irq_type_set_by_domain(const struct domain *d); > void irq_end_none(struct irq_desc *irq); > #define irq_end_none irq_end_none > =20 > +#ifdef CONFIG_CPU_ONLINE_OFFLINE > +void rebalance_irqs(unsigned int from, bool up); > +#else > +static inline void rebalance_irqs(unsigned int from, bool up) {} > +#endif > + > #endif /* _ASM_HW_IRQ_H */ > /* > * Local variables: > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > index 7204bc2b68..6445183f5c 100644 > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -158,6 +158,61 @@ static int init_local_irq_data(unsigned int cpu) > return 0; > } > =20 > +#ifdef CONFIG_CPU_ONLINE_OFFLINE > +static int cpu_next; > + > +static void balance_irq(int irq, unsigned int from, bool up) > +{ > + struct irq_desc *desc =3D irq_to_desc(irq); > + unsigned long flags; > + > + ASSERT(!cpumask_empty(&cpu_online_map)); > + > + spin_lock_irqsave(&desc->lock, flags); > + if ( likely(!desc->action) ) > + goto out; > + > + if ( likely(test_bit(_IRQ_GUEST, &desc->status) || > + test_bit(_IRQ_MOVE_PENDING, &desc->status)) ) > + goto out; > + > + /* > + * Setting affinity to a mask of multiple CPUs causes the GIC driver= s to > + * select one CPU from that mask. If the dying CPU was included in t= he IRQ's > + * affinity mask, we cannot determine exactly which CPU the interrup= t is > + * currently routed to, as GIC drivers lack a concrete get_affinity = API. So > + * to be safe we must reroute it to a new, definitely online, CPU. I= n the > + * case of CPU going down, we move only the interrupt that could res= ide on > + * it. Otherwise, we rearrange all interrupts in a round-robin fashi= on. > + */ > + if ( !up && !cpumask_test_cpu(from, desc->affinity) ) > + goto out; > + > + cpu_next =3D cpumask_cycle(cpu_next, &cpu_online_map); > + irq_set_affinity(desc, cpumask_of(cpu_next)); > + > +out: > + spin_unlock_irqrestore(&desc->lock, flags); > +} > + > +void rebalance_irqs(unsigned int from, bool up) > +{ > + int irq; > + > + if ( cpumask_empty(&cpu_online_map) ) > + return; > + > + for ( irq =3D NR_LOCAL_IRQS; irq < NR_IRQS; irq++ ) > + balance_irq(irq, from, up); > + > +#ifdef CONFIG_GICV3_ESPI > + for ( irq =3D ESPI_BASE_INTID; irq < ESPI_BASE_INTID + gic_number_es= pis(); > + irq++ ) > + balance_irq(irq, from, up); > +#endif > +} > +#endif /* CONFIG_CPU_ONLINE_OFFLINE */ > + > static int cpu_callback(struct notifier_block *nfb, unsigned long action= , > void *hcpu) > { > @@ -172,6 +227,11 @@ static int cpu_callback(struct notifier_block *nfb, = unsigned long action, > printk(XENLOG_ERR "Unable to allocate local IRQ for CPU%u\n"= , > cpu); > break; > + case CPU_ONLINE: > + if ( IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) && > + system_state >=3D SYS_STATE_active ) > + rebalance_irqs(cpu, true); > + break; > } > =20 > return notifier_from_errno(rc); > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > index 1806c47a08..239d4a7a25 100644 > --- a/xen/arch/arm/smpboot.c > +++ b/xen/arch/arm/smpboot.c > @@ -433,6 +433,13 @@ void __cpu_disable(void) > =20 > smp_mb(); > =20 > + /* > + * Now that the interrupts are cleared and the CPU marked as offline= , > + * move interrupts out of it > + */ You are using CPU notifier for "up" path, but calling rebalance_irqs() directly in "down" path. Is there a particular reason for this? Cursory check of set_affinity() does not show need for alive CPU, unless I am missing something of course. > + if ( IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) > + rebalance_irqs(cpu, false); > + > /* Return to caller; eventually the IPI mechanism will unwind and th= e=20 > * scheduler will drop to the idle loop, which will call stop_cpu().= */ > } --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:01:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:01:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427950.1650645 (Exim 4.92) (envelope-from ) id 1x8otQ-0007AT-Sk; Tue, 22 Sep 2026 01:01:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427950.1650645; Tue, 22 Sep 2026 01:01:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8otQ-0007AM-Q0; Tue, 22 Sep 2026 01:01:56 +0000 Received: by outflank-mailman (input) for mailman id 1427950; Tue, 22 Sep 2026 01:01:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8otO-0007AB-Vr for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:01:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8otO-0083LZ-Cl for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:01:54 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1d35b-bab6-0a2a0a5309dd-0a2a4501cf8a-36 for ; Tue, 22 Sep 2026 03:01:54 +0200 Received: from [52.101.70.104] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1d382-5984-0a2a45010019-3465466853ae-3 for ; Tue, 22 Sep 2026 03:01:54 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS8PR03MB6983.eurprd03.prod.outlook.com (2603:10a6:20b:23d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 01:01:52 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 01:01:52 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V6jFh3FUxHD6JtragXCT163sn0ZDeP57TS22uxq3DgduXerMAsXVeww45jA+g1GBwCTJGfguYX7K/b/QcjTL0LJBlZ6jgQhF8o1QgwMnB7eTPSx3xo13jV3xq12b8vdbazmBK8Gg8XCVJJVWJRzeknL/8eAvgZvacw37JzQECaksHJp7NjXFUPVgXXf3fT3NTMKZuIoIVOBtt6pSBB/wPfxCclWPt9jCGQC2MYuxH/LBeBzqmKpYLov35FE1kvmYgt6wdSPWHSayftyZZOSZnQK2D5Ms232agPIw0CoDdkquzZ1o7Dp6wWlXTDQCgbcDuQjkGNlzHMtjM5xZ5yVNQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EQzKRBWF6B2CBNr6xD6cAOpWpwOvRDBT5Kxk16BgexQ=; b=x033st7BJ3RIi3sAIcKxY6hUV80F+Hwy3hNDuLByByfKNtEYUgFVtVt0eCBtbV0+RoknsiqvJ9xT21ZsZ3uive8yw5AP9f/txBSUtxgl5juoXeV55HnNRcbssyy4R2A+8uJQ1I06x5buJmqZup+VXVu8iot2sfUUvXWs75axIZrm1oo6bjohcDTKexjf31Hitgfw9po1GIAyMticHqexCO7uXaLcovnHV25b7xtAKbomxWV3Pz2GTpPOVv06jI1TQ0r4q9fYZMpWQUHOtv9+gCF21rjYJ98ABUQk/Vs3np6fvgXHEWs+JER2/AB1jU1Ux7y7d28+71qnf96jexGWtQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EQzKRBWF6B2CBNr6xD6cAOpWpwOvRDBT5Kxk16BgexQ=; b=BKPC/Ur9Y5env3JNrpbwUozy/I8bSRbcGQ9H6NK+iDwKAfo8Uvb4Q0M0ug+XwrwDD0Jzh375Ve3+LwYXIchVATASAwWls2s/qkLkculvGuBoe819VPE9l/vlc1IyXjtbflTyr0lKuEFLGVrbRsr4irzso2NPmJy9sDRjpwYc0Qw1jDt4poreSd0/xWMFAl82wkYLVFiyrX3w+0DsdBUgk5RSuRuWH1fxhj6AVGBQAHFqfVN+epZW1kp4SlHRfIgPxKnWZ+wXliJA7B/UQlx27GU617ZiuIFvpOZMc/kgxvTOoQQkWQaCWYyUzvGe+keU1zBzjKV4bpfgGhfkyEF7jQ== From: Volodymyr Babchuk To: Mykyta Poturai CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v9 2/6] arm/irq: Migrate IRQs during CPU up/down operations Thread-Topic: [PATCH v9 2/6] arm/irq: Migrate IRQs during CPU up/down operations Thread-Index: AQHdLu5Yaco3oEokpUOTU00/bV2IRA== Date: Tue, 22 Sep 2026 01:01:52 +0000 Message-ID: <87jyoe85fk.fsf@epam.com> References: <55f4839f427df6675a621bb61bfbdac4fb089382.1787042017.git.mykyta_poturai@epam.com> In-Reply-To: <55f4839f427df6675a621bb61bfbdac4fb089382.1787042017.git.mykyta_poturai@epam.com> (Mykyta Poturai's message of "Tue, 18 Aug 2026 08:48:29 +0000") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS8PR03MB6983:EE_ x-ms-office365-filtering-correlation-id: 741de943-639a-4e67-4838-08df18451700 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|376014|1800799024|366016|23010399003|38070700021|4143699003|10067099003|11063799006|56012099006|18002099003|22082099003; x-microsoft-antispam-message-info: Y3w64xKjYoaZcIGxrZ8OUvTeCsPB09JpOUcQYFVkm4xdYS5eL19Vj60fEP69sSJdpgrwZdCPz7r5r6l4ded/8ctgSAa0l1zS5skuF2Z+MVytsM1pfdMwKMTviDA7BVLtO0vtE6JxQMwtvIp54f64caNZjZNUYdc0uQgYxdyPvPD344NssLBnyuk0kNsgbggewZ5sKZoEHjWbNvplmT3AVcLNculSWc7kQ2c0daa69jA3/rc2Zww44MmMznx5URgQ3DWowCVMkO0PcfnS36ZlXfpxZsA0Gj6XCWBgF98MisH9n58bJDQdEXq/N5uu7rnoxVOWcenYggIee3OQ8cpawGtRzLjzRbURGkl00itQquJP/Uf2T/kF1rOxcrVoTzmjAIvYCX1xnHO9b/EiW4T5W4LT6Gs1vaMnKwnRpJITd+oIDbI5iHQ0W8lktxCI7sdY+Rq2Kj2fLUhg7oeuAT3PTOEoTudPQX8OMJDhzfiMqEWFMJMzjM0xRKQgHh8TKYlN+jVYJ9YPahslI04fvCGZjSwNEOWynYV8cq/CGAaHyzcYjvAcJCGB8am8JI12LXdviVGliKs3Wg3NlGkiLTQdcnEEmqUrKewUUowadzJPs8hT3tsjC6n3QjsjP8PAhvrf6t1emxdJyF8be6lA8w2fHQSjRtLz16SubvRMHo8BbLGrHsOVFBFzvxDYHAI3qmdcVlUERUvQUIm8bMZJhDQAuTGW0ndqM9JNPpeGF2ddeAU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(376014)(1800799024)(366016)(23010399003)(38070700021)(4143699003)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?oFtBzJOMCnt+akzESWkyKoQV/P5/PIc9DUqlIW/DJccNSQCyG2+sPbn0JS?= =?iso-8859-1?Q?8oudXew5aovdzKI63ng9v8IDQIoqFq+kDukdhkHlhaqKqN67ufxzKNdT5U?= =?iso-8859-1?Q?Kn1ww5Ch5qwEWx+g9Z1n6oJtHbeV/PaziWQdfM13dXKTltSYshYUUOdWnD?= =?iso-8859-1?Q?RFd90dGFsQrrrSP08jIpy1fROnRSomlEDlmczRG59/hCcMOfLIZ2IPx3Lx?= =?iso-8859-1?Q?EhJlzI0DZIvgM2/Xwu5Hdnpn7+QK+GJLDcK8WsrGGLozrnWM6ZD5jIIagH?= =?iso-8859-1?Q?ihU0ei8J4z82ZcTiqV2uKaK6QqkAbsJRYp7gdb1hVIDD98jSfqCFj21+sD?= =?iso-8859-1?Q?IHN69W3VDecFnAZE9HfldUyw87pB2dt4OOroEb/oConl7A2BBbkpw7KNqh?= =?iso-8859-1?Q?fmsuOTzFoQYnvqVXwfVaF6NFnsfyFEdBgNQUGn7G8iR+RtyXhuskyiyGdR?= =?iso-8859-1?Q?N3/Ar7qFwR75SbuBcZ8K6mLHQXEEPQ01dIwPxMgp3sK1kDY0JauLBEXk/Z?= =?iso-8859-1?Q?2j2ueGkUjshMxtXGKpcWeoF49A7jVu2eUiNUZHHc49ARvZZ2po17+1qXN9?= =?iso-8859-1?Q?YtXM5OUNyOWztOdUGkc9s68ZuMFcT/kHsLOVvTrmkIfdyWS3Y9nbjfIwk/?= =?iso-8859-1?Q?WmgpQCCKxYCJV9N6u4gl1AQGLx8wV/tLoNcxzE7mXHCO3W3CGCs4EMIUi+?= =?iso-8859-1?Q?4zgN62MjGYP46B0kn1DBo/K4h9kSF8jHQyBEoj14CHXQUvoDUIyEQsf7xF?= =?iso-8859-1?Q?gWuJWuf/OohscquLf2TqpNQgqSN9Zcj+P8uiyCPs1NZdSQNXQgHNNfC77+?= =?iso-8859-1?Q?1MWxcCW8FBdeL1DguU2O5Wdevm9ZrKwcqOvq8HvR6z9lqE0aC44EVnIejJ?= =?iso-8859-1?Q?Y0PR8d9RWgDXT75T2s3cvJh9Xu7QUNWl4rH1j8bv5HO92/474pauhBNuTB?= =?iso-8859-1?Q?oKg1z5gWWCEY/e+O+jkhjS4pUk5S54j+E4KcEzCt3m8f9oiIgZ/vDSW2c0?= =?iso-8859-1?Q?r+vaLjIUkjOfbO7LwDRIanP3APDgaZgNFzZpLhPdJ5axPOXrrkmkx9VzXn?= =?iso-8859-1?Q?gOY09qusvMH4YnAHreSzeJvCGFY1jXyM0DzU6ybznyf9Y5mMk1PR8dl/2u?= =?iso-8859-1?Q?FOxsnEuxIPCPEfTt1jxrlaueE3kmL73pJK5dQmSMmW2bJhneFdsl4HZe9e?= =?iso-8859-1?Q?UTQItua9yQJK4ihav6zI98/QCzWusi3SkvfyNJ+++7IanWgcuyNX2KE38Y?= =?iso-8859-1?Q?f3t5L4KKtPeTsdVr7Zdw1OU9/3cRxP1Tn6sD41TrB3pEJvt09zx62an52Z?= =?iso-8859-1?Q?PGGqf4qngewfY3CoK6Y7Wcz4qz6zCyfgjTKoOJ5L/x/cvdW4AR4UhfWYlx?= =?iso-8859-1?Q?oXtfBy2QZNBnvhCDhFNjrixa3RuQGUl5JUkabFim/gA+szlSXGueMweXL0?= =?iso-8859-1?Q?rvydesKYwjWpYxiuLpBwX05YJDbzh7hb7ID6OF0Rdptd/Dkc4K2dA60Lc8?= =?iso-8859-1?Q?Ujj8DRyktiop2hXrComnCS8gtFQDtgSJsyXK94Mx1hdtgWoYxBOy5e02OX?= =?iso-8859-1?Q?eWu03Ne66ou9FIxhz30p03L6E0fKj5xjU5WOR8n+MVN6U1IrA2fARNvD9q?= =?iso-8859-1?Q?cue6J/7mxTXmcQdcYlJQzkAq42amwGwQ74koM4777ZcGlou5NWWhyvRzKY?= =?iso-8859-1?Q?HcVh93SnE6kwdOGhAXEg2/sUHhJz+IqflhGAcTLAwYBkjQW8eaOOpVIh0v?= =?iso-8859-1?Q?zSHL2gxjn6nMgeEyJtq/KaC0mTklR9h/bwwJSK71KwxEFd7XSzGDmWPlHl?= =?iso-8859-1?Q?1uBWJWuumpRGWV7Z7zSQMfFOoMxi2yc=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 741de943-639a-4e67-4838-08df18451700 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 01:01:52.7331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pfFwIrllRJs69p5c8xeQd8hCMB7yCJnZwTzkeMnT7IeSirQ6Z70sAiD8mO6BHAEginwUguhXvBKfn/Cu1F32TBCw/UsWB6FKLZFEJOiUPEI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6983 X-purgate-ID: tlsNG-d62444/1790038914-BCD44757-97E60B74/0/0 X-purgate-type: clean X-purgate-size: 5493 Sorry, forgot to comment one more thing... Mykyta Poturai writes: > Move IRQs from dying CPU to the online ones when a CPU is getting > offlined. When onlining, rebalance all IRQs in a round-robin fashion. > Guest-bound IRQs are already handled by scheduler in the process of > moving vCPUs to active pCPUs, so we only need to handle IRQs used by Xen > itself. > > Signed-off-by: Mykyta Poturai > --- > v8->v9: > * replace CONFIG_CPU_HOTPLUG with CONFIG_CPU_ONLINE_OFFLINE > > v7->v8: > * check only existings ESPIs > > v6->v7: > * replace ifdef with IS_ENABLED > > v5->v6: > * don't do any balancing on boot > * only do balancing when cpu hotplug is enabled > > v4->v5: > * handle CPU onlining as well > * more comments > * fix crash when ESPI is disabled > * don't assume CPU 0 is a boot CPU > * use insigned int for irq number > * remove assumption that all irqs a bound to CPU 0 by default from the > commit message > > v3->v4: > * patch introduced > --- > xen/arch/arm/include/asm/irq.h | 6 ++++ > xen/arch/arm/irq.c | 60 ++++++++++++++++++++++++++++++++++ > xen/arch/arm/smpboot.c | 7 ++++ > 3 files changed, 73 insertions(+) > > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/ir= q.h > index 09788dbfeb..d043360135 100644 > --- a/xen/arch/arm/include/asm/irq.h > +++ b/xen/arch/arm/include/asm/irq.h > @@ -126,6 +126,12 @@ bool irq_type_set_by_domain(const struct domain *d); > void irq_end_none(struct irq_desc *irq); > #define irq_end_none irq_end_none > =20 > +#ifdef CONFIG_CPU_ONLINE_OFFLINE > +void rebalance_irqs(unsigned int from, bool up); > +#else > +static inline void rebalance_irqs(unsigned int from, bool up) {} > +#endif > + > #endif /* _ASM_HW_IRQ_H */ > /* > * Local variables: > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > index 7204bc2b68..6445183f5c 100644 > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -158,6 +158,61 @@ static int init_local_irq_data(unsigned int cpu) > return 0; > } > =20 > +#ifdef CONFIG_CPU_ONLINE_OFFLINE > +static int cpu_next; This variable is used only in balance_irq(). Maybe make it static for that function? No need in keeping it global. > + > +static void balance_irq(int irq, unsigned int from, bool up) > +{ > + struct irq_desc *desc =3D irq_to_desc(irq); > + unsigned long flags; > + > + ASSERT(!cpumask_empty(&cpu_online_map)); > + > + spin_lock_irqsave(&desc->lock, flags); > + if ( likely(!desc->action) ) > + goto out; > + > + if ( likely(test_bit(_IRQ_GUEST, &desc->status) || > + test_bit(_IRQ_MOVE_PENDING, &desc->status)) ) > + goto out; > + > + /* > + * Setting affinity to a mask of multiple CPUs causes the GIC driver= s to > + * select one CPU from that mask. If the dying CPU was included in t= he IRQ's > + * affinity mask, we cannot determine exactly which CPU the interrup= t is > + * currently routed to, as GIC drivers lack a concrete get_affinity = API. So > + * to be safe we must reroute it to a new, definitely online, CPU. I= n the > + * case of CPU going down, we move only the interrupt that could res= ide on > + * it. Otherwise, we rearrange all interrupts in a round-robin fashi= on. > + */ > + if ( !up && !cpumask_test_cpu(from, desc->affinity) ) > + goto out; > + > + cpu_next =3D cpumask_cycle(cpu_next, &cpu_online_map); > + irq_set_affinity(desc, cpumask_of(cpu_next)); > + > +out: > + spin_unlock_irqrestore(&desc->lock, flags); > +} > + > +void rebalance_irqs(unsigned int from, bool up) > +{ > + int irq; > + > + if ( cpumask_empty(&cpu_online_map) ) > + return; > + > + for ( irq =3D NR_LOCAL_IRQS; irq < NR_IRQS; irq++ ) > + balance_irq(irq, from, up); > + > +#ifdef CONFIG_GICV3_ESPI > + for ( irq =3D ESPI_BASE_INTID; irq < ESPI_BASE_INTID + gic_number_es= pis(); > + irq++ ) > + balance_irq(irq, from, up); > +#endif > +} > +#endif /* CONFIG_CPU_ONLINE_OFFLINE */ > + > static int cpu_callback(struct notifier_block *nfb, unsigned long action= , > void *hcpu) > { > @@ -172,6 +227,11 @@ static int cpu_callback(struct notifier_block *nfb, = unsigned long action, > printk(XENLOG_ERR "Unable to allocate local IRQ for CPU%u\n"= , > cpu); > break; > + case CPU_ONLINE: > + if ( IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) && > + system_state >=3D SYS_STATE_active ) > + rebalance_irqs(cpu, true); > + break; > } > =20 > return notifier_from_errno(rc); > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > index 1806c47a08..239d4a7a25 100644 > --- a/xen/arch/arm/smpboot.c > +++ b/xen/arch/arm/smpboot.c > @@ -433,6 +433,13 @@ void __cpu_disable(void) > =20 > smp_mb(); > =20 > + /* > + * Now that the interrupts are cleared and the CPU marked as offline= , > + * move interrupts out of it > + */ > + if ( IS_ENABLED(CONFIG_CPU_ONLINE_OFFLINE) ) > + rebalance_irqs(cpu, false); > + > /* Return to caller; eventually the IPI mechanism will unwind and th= e=20 > * scheduler will drop to the idle loop, which will call stop_cpu().= */ > } --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:13:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:13:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427961.1650654 (Exim 4.92) (envelope-from ) id 1x8p4i-0000Sq-RP; Tue, 22 Sep 2026 01:13:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427961.1650654; Tue, 22 Sep 2026 01:13:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8p4i-0000Sj-Ol; Tue, 22 Sep 2026 01:13:36 +0000 Received: by outflank-mailman (input) for mailman id 1427961; Tue, 22 Sep 2026 01:13:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8p4g-0000SY-PT for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:13:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8p4g-003qz4-1n for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:13:34 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1d5cf-8faa-0a2a0a5109dd-0a2a4505b1b4-48 for ; Tue, 22 Sep 2026 03:13:33 +0200 Received: from [52.101.66.136] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1d63d-4cb1-0a2a45050019-34654288197a-3 for ; Tue, 22 Sep 2026 03:13:33 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS8PR03MB6837.eurprd03.prod.outlook.com (2603:10a6:20b:292::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 01:13:32 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 01:13:31 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cTXd7jkNXhRS83Q/c+BFetqNOSz1ZoTFBh21pe9a1u99UWSeEayLfko3R0l5PJgPc5NpFmcClXGDmwQSwos/MG3f8mua42NIPQjhYIBzyl+Pf0g0cFlSceUyjQ4Xw9vuArd5oUxNsRJmb2S/c5vzXVvmNOWvJF6WpFULaDYLhX6yy+5sXrHxcF9HZqlHVb+5h/vpRwQi1RZgq7G3mo9QaJko7CG7hANq2xXmyfQOvJQivoUz2O7BazhuW5JhWje7kzMTfTRgJEl5LnJ7/KCQD+pNISiTFOgp7pUFMSPGyznfEZFU07wfR8MHVbK5JD1j+hweb43KT81j4k/quyObWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ztP34H4MVWpWaa9/hwAntMYQxA8O1MoNEGSQSzmeJaU=; b=t/xSxlS7WokXMKmS8SrzzToEZ4fEYVLZWXrtG3ShFZTVkBK1b4qAJ9dgf47FWpw4TLChaZRHUiprIC/yO6f5er/eVKuHI5okGCCuShr7BakLt4cdX+Tw4/1jJYtWFAaXZXTCJQU95C4lcCGY/4ohHschNVDh7fCKEnS8+JlFqne1CkqDdO5r7HcX6SJTr0U8ZB4sMi/J1kEiwyP8UJ0pECOGgTocxXPc3RAHqlFUWrGvgRm0BpXdGmKnB7MeJ43ph8UirUGBv4GpraLJDxPzlG/wlBJiAz7qIRrWO8BbJzJ5c3V2Ok3eI135FeOnud7N5Y6GtKlSgUQ+OeAK6Rul3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ztP34H4MVWpWaa9/hwAntMYQxA8O1MoNEGSQSzmeJaU=; b=Siple0QQ+bFl/REW9uifpKScdDFnsqkhaagknJGtk/deY4SvXD3ad6+xIc08oLL4DcZoAcvuCeMtTTy+wTJdSpGiIUxZFrfQtluPq8mqhUysnM2UtUiIkViDX6yIYr9nuzh+XwCJ9PIrZMq2txMOS+nJUGZhnZTwvLAGXoLFsfhXjXn1ebUcrbM4Pcnn/83m+VJiUUQfT5sM0qhapPiXq1l9moJNHKoq+Wbd3k1swygGADXrg+jm24sw/CcLTICGxdpDIx9KDbKHS+fjMWP1Ju1MKbSUjVUpBLNeXDT+bzCkzR95c5rkcvyWP5iQvZUg0A6aP7AjHHa9xWyD0lbPgg== From: Volodymyr Babchuk To: Mykyta Poturai CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini Subject: Re: [PATCH v9 6/6] docs: Document CPU hotplug Thread-Topic: [PATCH v9 6/6] docs: Document CPU hotplug Thread-Index: AQHdLu5n5DTKasDPakWayAUOcTtpgw== Date: Tue, 22 Sep 2026 01:13:31 +0000 Message-ID: <87bj9q84w5.fsf@epam.com> References: <70484b3362f3b816bf4ed5f70c374c198a8a6eea.1787042017.git.mykyta_poturai@epam.com> In-Reply-To: <70484b3362f3b816bf4ed5f70c374c198a8a6eea.1787042017.git.mykyta_poturai@epam.com> (Mykyta Poturai's message of "Tue, 18 Aug 2026 08:48:31 +0000") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS8PR03MB6837:EE_ x-ms-office365-filtering-correlation-id: 208866ba-5a86-4edb-892e-08df1846b7a8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|42112799006|366016|1800799024|6133799003|22082099003|18002099003|38070700021|56012099006|11063799006|4143699003|10067099003; x-microsoft-antispam-message-info: fn7cSyRdChKCrZ4aBuLiv81xZv5j71sdEhpmeaLqetxFYSnqbMBBLA4mn3npYCaIkQOwjH4fgljCBzXTewsQUvU8B7RZmWRaRGGIXs193VcTCZw/0+oqMkAlbc7yjNJ5VNr4K7QjSthwvlWN6P4kvxLH4oElm69P0nKJVX2IQzKNQInP5cAhvaJzHV9FN95Kcee6l/H9/Q6ZGOnO6j1s1q2yScMEoPrm5XdJrPkgr1T4NnkP73aWJ7SJu9FMYxsAzxC3OeyuXGuQAev+HQZI/4A62XoetlG0FECeovNUtBuccQtMm3zE1nETPhVwDkok2SQ3Q6Pw3+3U17F+CrA3PpL4iDkw8KfmUQOdakMjBLZ7kYtGo6oItXJlRbHY/4DIEPydd6i5BDxDmkvNqJSeETVB4JGLN07j3VByGfKOKlCDTLtmmbYtb4lbD9CaTdfYN2ahDkfpn8Ftl/xwgvvDam+A2XLgeCHPWl3vmngZ1wH//0T52rxIvo9TRdhV+zb6U90JP/okW2dQc26cbim9JO0+m4Cjh1uAIT0TiywQWbRxoXn7CmCXpUjCOuQtKMb0xAlrLR6C5h1JsKF8stMYZixSfnNMrgsSWuYNmwnQA16+d8rFXQb80W8JPPk5ewoqCs6mDs1XwuTtdNo4VroI4tilAfjiD1mNXDbF57yrEQZMtCtV0/iJd0VYXn82XorGRS84o5OQmO6hqJqNPXbkd9MwYm9zHbVH4Y8jEr0gBUc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(42112799006)(366016)(1800799024)(6133799003)(22082099003)(18002099003)(38070700021)(56012099006)(11063799006)(4143699003)(10067099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?AEmo3MVR/DsJdMp2PQrc/6+C7LRV8VWRvNNDGAK2cH8a8vWvF4jMYUsT3M?= =?iso-8859-1?Q?4j+sy0EudN6eke4ePBnxlWf64NUy6+ty4f/4cQiNTeELy2dLYB/rVmFvi8?= =?iso-8859-1?Q?6z9pVfT0ic2H7wioMQQr30HYcwtn+mjF9sjt4CMhV0lLcIpSIKzPNZTRx+?= =?iso-8859-1?Q?jb74TVHIY5/YhCnwzI98uEhUFGNR9BRxwICqxmNzrWf2MFsCvIM6pofejq?= =?iso-8859-1?Q?sKYde7aXbW6wbUtqK+VHjWcHeOQaTvpZpysruoBfUsrbH9ewlFmaBlzwUa?= =?iso-8859-1?Q?xFclms3/shdTS5in6NtgDRWoHt0VVidP99OiEy7bisoF4NT5IkZH3MiTy3?= =?iso-8859-1?Q?80eWAd60lGkcgJTv9PZ0sUxl4+LoQSmuxQF+jr44eQOtYcNoJ1r8CsQJiz?= =?iso-8859-1?Q?WFBt9v43+yA+wCuT8tfiZ6alJMs3lC+U5lp8yTP7khAsjOG/Tc88yJCVbF?= =?iso-8859-1?Q?BG57wPoPE2+zPYvraU5RB4rjPxhV0qWnAcuEHGNEjLMX4FI1pZuDUCZPef?= =?iso-8859-1?Q?de5MRUY5+jdbkmxexzdS4ERmOLbXfrucSCK/YzxcjzeClNVyxKy0NeR6C6?= =?iso-8859-1?Q?fBhkGM9uCrvdFltXZ+4eL/ZQNbav+ZqKhGaWKAaPxy3ri1WJ055O/vOBv7?= =?iso-8859-1?Q?B0kJSvLl2I+CvzxU+nH8VBB/wC+fcKblcAKdOnNowCaUUiu8pd1VdPwGFB?= =?iso-8859-1?Q?nA7fZIpvjC13N4Bi0WqURulOLisgh8/osFE2ubJ5ntOifWgr2vQ8Rzb9qx?= =?iso-8859-1?Q?+acgIFO/IIUwTDBeBUCVbRgAgNPo9/t0JrBbTLcu0QuSIzRIAmky7gzwzK?= =?iso-8859-1?Q?tz1dl9xUY1QVsD29/ukRzD3bCdSeva8XpsGzzcxXMaEMsFoVb/DU4gMRL4?= =?iso-8859-1?Q?hXOXjdSm2deEyemKCB0vdeqVO+B6I+Fm94RpbtoGppOzkbCCthwNqdTcss?= =?iso-8859-1?Q?YX2F2KnvICqazwD4/y/sdF1rlv7+b3Y4ZgwCB/G0X5oZdTArkpciq/BnUf?= =?iso-8859-1?Q?2K/PYgIX1G6FU7GWyVDDcaZcfQag4Trz5sxF+HfiYbWHGhoVlQsP7H+e2/?= =?iso-8859-1?Q?5u5mHs+ytr52Ya1lpk6KjtySNZUkhllLsT2zWM4ABWt7wibUKHnBt0YsQG?= =?iso-8859-1?Q?PUrJRA8NdPu2wBMNf3QI6NKx5CD3ABnwP8l3+/FlrVAHvJTDr1ZvY+gIYy?= =?iso-8859-1?Q?N1tQ2T3oaUX/8a5V0pcWgzQdgWmttNOxyykdS8vGx1gmp+DDDkftzwldqc?= =?iso-8859-1?Q?KX/o0ZWXyb3a10BIdwRDAhoAsWjVXPsmZBg7ak6qIO97tIOu0WlE2tB019?= =?iso-8859-1?Q?Hx5Y6WOmdE/sV28+mwSepGvoH3G8gPn7UYIYmpEoWZCDO6hky3fKGvmTLh?= =?iso-8859-1?Q?VDeoQMEGiTNNAXfmslZPRUIqfaMo2j+DPSQaDSN2/uCH3NA7SUprf6dGfb?= =?iso-8859-1?Q?KzeHcq6PpBI0S1WILilcO7IAIpPYdzz/OOS5WNmL0ucCU26aYXXV+dVw/+?= =?iso-8859-1?Q?BF+cM+90k4pgIuovYOCFwkY6cVB5YSmmUr4rnLhl0i+853T0mDtLHDrm9C?= =?iso-8859-1?Q?2jUOoxJAJlQ/UVjDyCCRY4T/LqitWa6z3ja4DopDqvRy5WuGw4cBIg3ZY3?= =?iso-8859-1?Q?v2QUMBVus0vPjAq29YlgdhA3eiNZGjpmzJbo7sbDQ6aB5Iazk5nKyzw1mu?= =?iso-8859-1?Q?mcDsoSQzLVyJQw7bJkj2R82PyR0lCUns+eOV82Pq7roJec2RyyEHYE/I+d?= =?iso-8859-1?Q?HS/TcVzqFVjJToPv8cbMtIZp0voEXAJcTO1dQYGjiQ4T+xDDYEjljIM87J?= =?iso-8859-1?Q?1FyCz95imxN6lhv9BfG81eMX1Ci1D5o=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 208866ba-5a86-4edb-892e-08df1846b7a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 01:13:31.7858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: N98D5yeuQNQ0Q03hpL1wF+obEP58XFwZGOCLxv5SytujqkKP3MKdiXrBjleZKF66JoINxcOcCYdUr6RrYGvNg5CkflXxFJpdp2MkP1PmSF8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6837 X-purgate-ID: tlsNG-c201ff/1790039613-736BD2A1-0AC223FD/0/0 X-purgate-type: clean X-purgate-size: 4751 Hi, Mykyta Poturai writes: I have a couple of questions, please see below > Signed-off-by: Mykyta Poturai > --- > v8->v9: > * fix typos > > v7->v8: > * remove support status update > * update config option name > > v6->v7: > * add testing and limitations > > v5->v6: > * no changes > > v4->v5: > * s/supported/implemented/ > * update SUPPORT.md > > v3->v4: > * update configuration section > > v2->v3: > * patch introduced > --- > docs/misc/cpu-hotplug.txt | 98 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 98 insertions(+) > create mode 100644 docs/misc/cpu-hotplug.txt > > diff --git a/docs/misc/cpu-hotplug.txt b/docs/misc/cpu-hotplug.txt > new file mode 100644 > index 0000000000..4f6068db30 > --- /dev/null > +++ b/docs/misc/cpu-hotplug.txt > @@ -0,0 +1,98 @@ > +CPU Hotplug > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +CPU hotplug is a feature that allows pCPU cores to be added to or remove= d from a > +running system without requiring a reboot. It is implemented on x86 and = Arm64 > +architectures. > + > +Implementation Details > +---------------------- > + > +CPU hotplug is implemented through the `XEN_SYSCTL_CPU_HOTPLUG_*` sysctl= calls. > +The specific calls are: > + > +- `XEN_SYSCTL_CPU_HOTPLUG_ONLINE`: Brings a pCPU online > +- `XEN_SYSCTL_CPU_HOTPLUG_OFFLINE`: Takes a pCPU offline > +- `XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE`: Enables SMT threads (x86 only) > +- `XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE`: Disables SMT threads (x86 only) > + > +All cores can be disabled, assuming hardware support, except for the boo= t core. > +Sysctl calls are routed to the boot core before doing any actual up/down > +operations on other cores. > + > +If there are Xen-bound interrupts pinned to the pCPU being offlined, the= y will > +be automatically migrated to other online pCPUs. Interrupts used by gues= t > +domains are handled by the scheduler when it reschedules the vCPUs to a = new, > +online, pCPU. When a pCPU is being onlined, some Xen-bound interrupts wi= ll get > +redistributed to the newly onlined pCPU to prevent imbalance. > + > +If pCPU being offlined has some vCPUs pinned to it, they will be automat= ically > +unpinned and migrated to other online pCPUs. > + > +Limitations > +----------- > + > +On Arm64 cpu hotplug is currently not compatible with ITS, due to an iss= ue with > +the redistributor assignment. In this case you probably want to make sure that CONFIG_CPU_ONLINE_OFFLINE is incompatible with CONFIG_HAS_ITS > + > +On Arm64 there can be problems with FFA if secure FW supports the notifi= cation > +ABI, and with TEE, as both use non-static IRQ actions. Could you please elaborate on this? AFAIK, OP-TEE has own cpu_up/cpu_down callbacks, so it should know which CPUs are online. > + > +Configuration > +------------- > + > +The presence of the feature is controlled by CONFIG_CPU_ONLINE_OFFLINE o= ption. > +It is enabled by default on x86 architecture. On Arm64, the option is di= sabled > +by default and marked as EXPERT. xen-hptool userspace tool is built > +unconditionally. > + > +Usage > +----- > + > +Disable core: > + > +$ xen-hptool cpu-offline 2 > +Prepare to offline CPU 2 > +(XEN) Removing cpu 2 from runqueue 0 > +CPU 2 offlined successfully > + > +Enable core: > + > +$ xen-hptool cpu-online 2 > +Prepare to online CPU 2 > +(XEN) Bringing up CPU2 > +(XEN) GICv3: CPU2: Found redistributor in region 0 @00000a004005c000 > +(XEN) CPU2: Guest atomics will try 1 times before pausing the domain > +(XEN) CPU 2 booted. > +(XEN) Adding cpu 2 to runqueue 0 > +CPU 2 onlined successfully > + > +Disabling a core with pinned vCPUs: > + > +$ xl vcpu-pin 0 3 3 3 > +$ xl vcpu-pin 0 2 3 3 > +$ xl vcpu-pin 0 1 3 3 > +$ xl vcpu-pin 0 0 3 3 > +$ xen-hptool cpu-offline 3 > +Prepare to offline CPU 3 > +(XEN) Breaking affinity for d0v0 > +(XEN) Breaking affinity for d0v1 > +(XEN) Breaking affinity for d0v2 > +(XEN) Breaking affinity for d0v3 > +(XEN) Removing cpu 3 from runqueue 0 > +CPU 3 offlined successfully > + > +Testing > +------- > + > +The CPU hotplug feature has been tested on both x86 and Arm64 QEMU setup= s and on > +R-Car Gen5 (Arm64) hardware. > + > +The tests included: > +- Offlining and onlining cores with no pinned vCPUs > +- Offlining cores with pinned vCPUs > +- Offlining cores with Xen-bound interrupts > +- Offlining all cores except the boot core > +- Offlining the boot core (expected to fail) > +- Enabling and disabling SMT threads (x86 only) > +- Offlining cores to which guests with passthrough devices are pinned --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:24:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:24:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427969.1650662 (Exim 4.92) (envelope-from ) id 1x8pEz-0002Cz-Oe; Tue, 22 Sep 2026 01:24:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427969.1650662; Tue, 22 Sep 2026 01:24:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pEz-0002Cs-LX; Tue, 22 Sep 2026 01:24:13 +0000 Received: by outflank-mailman (input) for mailman id 1427969; Tue, 22 Sep 2026 01:24:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pEy-0002Cm-Uy for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:24:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pEx-00FPmq-Or for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:24:11 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1d893-2eae-0a2a0a5409dd-0a2a4506bc4a-20 for ; Tue, 22 Sep 2026 03:24:11 +0200 Received: from [52.101.84.81] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1d8bb-195a-0a2a45060019-34655451fcc3-3 for ; Tue, 22 Sep 2026 03:24:11 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by PA4PR03MB7456.eurprd03.prod.outlook.com (2603:10a6:102:ee::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 01:24:06 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 01:24:06 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HvfKMmHTleRBI1pDwQjiVRhIQIIrIyzyYJNI5o/EIfQOY2lpfnKlH3QyclIYvP3UkZdMvIJn76yA/Zv2L0iGNIf9YNPTEyHEWlybDtO/z8zSqDcOqGDH8RGV/YRM86odlRjC4L4nOCkDsFkGxmRWt2TBLf1Vxpo9mPClU8yNA6OBMiSbs1wVzMjvuGNHBIAOJwIS2nAz2ZWbNxi9BHRVjm3YM5rWLKuhFG7WEZz/yZB+EJ3kgLMVTC+SRenFVCJr+3v1aMT2H9lm2QG63yE2UPKWsQ8pQNetNXxnlYV+I77l7pD3xAS+R6l+ZjAUCfX9OErnnwwkozAHZyrec31aXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FFkLjgcY5vFbcVBbMNc6DQ0M31JpYAiTXQSw2Doajqo=; b=Vq0ucSRl+lG2GOEBa5J3+eJ7XGJye/zkN+u04P3W0Ie/XRnJ0VteKv1lAcssIyPnVzQDjSfNVyCj4/l6vnpIctRKm28L1yB0zeKYcxNO0zbkB3EHOfFrZPvPy+Wcotp69vDbtZW6pqvWXgK/p3HCrvwos9nX5o6DW9FroIWuv9VuXsjYL3HsakStMoIr9zs13h/gG/Me7gMwyFxFVFciZ8EioM/nkpRMBGrBApQwFwje9gtZCpfr1AomCpBMQ9w45DuhqHImMsu3V2ozYv79pFxawaNvSO4Y8gN1HDFau/adp3L4bdCAEBaKj07qGpGbQFBc/oBbXfZZ4hVapitaOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FFkLjgcY5vFbcVBbMNc6DQ0M31JpYAiTXQSw2Doajqo=; b=K0u2H+9ateCfIgteT+km5GgFwW0a6IO60dU6kmrdOua2aLmJXGFM2z/uxL2r5qKf3LFXmkAf/wStVQe08biuqxt5D02QAZTe52pu8uPQhU6yyG33B0yvMrDRGFy8T+d2Odwq5RNQkShksGBfpNKd9VIcRP+LLqwW7JB2lj6Rr4LYPWoo/SHPNxvAzsnH2ScoP2VaBOfWkKRV6e8MHn3a8onVTD9nd59SzO1GsVF6FI7Z55yN/on9sARcKw9G8ccSmgt0/muQkcarJw6ayT0jlBxejL0tkUP2+YhfpV1Lx/9KTEtiMdv/G4F+HoCrbbMWbprnrd0Mm2sMUJQxwTVuDQ== From: Volodymyr Babchuk To: Jan Beulich CC: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH 01/14] lib: obey to Misra rule 11.8 where possible Thread-Topic: [PATCH 01/14] lib: obey to Misra rule 11.8 where possible Thread-Index: AQHdOqSP/YfdAsU2nkefZ0kBfbUzQg== Date: Tue, 22 Sep 2026 01:24:06 +0000 Message-ID: <8733v284ej.fsf@epam.com> References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <12d3f4cc-e3c3-4f2a-a791-724271473fb9@suse.com> In-Reply-To: <12d3f4cc-e3c3-4f2a-a791-724271473fb9@suse.com> (Jan Beulich's message of "Wed, 2 Sep 2026 08:30:02 +0200") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|PA4PR03MB7456:EE_ x-ms-office365-filtering-correlation-id: 1ff4ce41-082e-4f2b-0145-08df184831d7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|42112799006|10067099003|11063799006|3023799007|6133799003|22082099003|18002099003|56012099006|4143699003|38070700021; x-microsoft-antispam-message-info: nTf3+zrXUxebORWXSFSLaEszNYhZIhnScepHPsUUYRxPfNPcVukpYqobx1nHTu/kCFpM5E5yr7KqTO0IC5rqEkTX02nInkMRYSpgvr2De66CEB4DlRUEvT/0sY/Ep8zGhQXE/kUw+UBC8dZ2EquxhAAr8hcUrB840y8ZzvuJf4Ywd6ElYj/XF26mW4B849YwYKosB6rkxsTU5doKx3h5DlyRnaNWWIDm3O64VbB3MzUMLSDLyk5vMBcGuQni7LNwWjngL0R6DPPSi5435qYeXKqC8AJg9TcZpvE2dPRQg2c9mDzPfRUU8DPdCxKuBVAAR64pTJerM20PVTaj08TobER1eWwHa/yU+Jot4CtWdeTgLaERNM6AabIpQzqR65MnE4kn9jQOMqVIGEUs5C66RyEBu4QAJWsuNauSg3sdWytxP/Rclm/FyYHqEoY5MwK3ui+Gfuh22BduBuhbwZqdDGCjIY39YmqaHduOd0yBRNsZ7S08WvOuKoUph0yWjS4BuTY8q+o8IQFXlqlambRW/GuKl25GB+sOraa4P7txXlJrlZ1hztanPi7oAKRgiJXnmBVp+qRzZZQhFz6WN++yUl3MC1p7f4tdf+8ImGfkZc3LQPcQqbc+VkcAoF03Mc5NQVnpa8Osj3j/itKov/mnqE0l5brljTark/PHKxM3SrM+oV48JJK+EfiilXzISt8kTVAvwU8G3KoW+ZXSeQgD74UbinQ3NkdM7KkkC2H9N3s= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(42112799006)(10067099003)(11063799006)(3023799007)(6133799003)(22082099003)(18002099003)(56012099006)(4143699003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?/r9LBPnMfEhNTd6PlSKzKZ0xzSs8k6gVs5Q30GnGl8XxYNypnsIODkYlv8?= =?iso-8859-1?Q?kqcc9yDbulL+bFYyzNr0f37E74P/W2nKvef9S4FuvyVOXS3I0BDNpFbppe?= =?iso-8859-1?Q?YFlRi6UlYukOD8OLUpAiLTS1U0HG8P9nmBDkNhS1MYiRAcyKE8b4tACzcg?= =?iso-8859-1?Q?jAFXiEqULZZXNNJwVwwg6ZFPVQhwsv4qOwNIEStOBn+wTiynOzn1IKWp1v?= =?iso-8859-1?Q?PTSI6GhXZF7a+TnkOGbJyAA06tGRpNIQZRwj+kDAdQT4coscY+fXLVocwd?= =?iso-8859-1?Q?rhKNn58o4pU3R73Z+Uwgv85TJ7vLEF6bQp/wei80pAeu6vwCo6Y0Pl7WZN?= =?iso-8859-1?Q?rLnbKH8TjGlKdPYTdlXWvoA4Co29E0oayZntXP+Ze59SejeG9ZYeOxnAYk?= =?iso-8859-1?Q?35uDbJFbRwGOuJT1Q93b9I15WX5iu3ja0mubum/88V5Yw0/JBO6ykjplsI?= =?iso-8859-1?Q?8nHaLPatDl5ZiaT9kzm1KZ9GxWgKvfGlElXh2+D/hMOGISg/td1UustRIL?= =?iso-8859-1?Q?hjrdtz6S12saers3Yq1b8deDyS4PE59zwJOTUa0/mPld4NBFvVAkBky4KD?= =?iso-8859-1?Q?V9H61ctnSQrsfLATOQkpYYRQpg1i3EmRrr56PApsLu1Qv+cwEZ22Lct5bx?= =?iso-8859-1?Q?z/xYY6JZWq3uhATUHiG/hdfZM4MIEA3hZEBtOHseXDHwAjd6TPme159nP0?= =?iso-8859-1?Q?4GXf/jRni5sY2EHGUqa2hEj+MBjI7qPjdmGu0to7wMob+ilD1QQBNrAlLz?= =?iso-8859-1?Q?vFkjomnJow2fKm5A/gX+B84T0gq/pW+emLUtk43ULvfuaiRhjIzQZ/Wq1e?= =?iso-8859-1?Q?y0RosbV3AdPFspNB5cixX6+FKV+dugAyGcz1q/0taE7DNc3UeqvDSKXjgJ?= =?iso-8859-1?Q?ENXT7X1PDeI9QPXzzYQBZtJcWp+gOZmAs+TpQedazYlGvD694XbcdFKHns?= =?iso-8859-1?Q?tWe5QyeFIzugo/F41k7ocWyAarHX8Y/iIyU2LKCPe7W39GF4Q6qilltGGW?= =?iso-8859-1?Q?Xg3j+FXinDaagcuUIwTn2uH/l+JiLPpcdh46CcplH2IxTCpA9Nd0vibgDl?= =?iso-8859-1?Q?LYQ1+Sdi47xURmESwUxnam2Jm4rjTdae/eLkAEWE3TqXAHTDJGI5UQXOAm?= =?iso-8859-1?Q?SU5zxulPh3php9ioAFJPTYvNjVmXfRJ7DvwwmN3yXJrraGRTT2Go/b5/eY?= =?iso-8859-1?Q?1uOJWzCXn8ITRjm5/dofZsNpkzOILMQLCTktDVP86HzlbGxknFKSCCjJ06?= =?iso-8859-1?Q?jYwh3LwnEY0dSzr2dvul6W5k0xh3EfqSbJ/vR9ml2QW/9eOovpWBPNlEAz?= =?iso-8859-1?Q?mB3S7CQG4GunCSI+5/Hbsl03s/BXlLN42QXQL8zi4b1p+VsqjxioQXmeNC?= =?iso-8859-1?Q?rafGQBjCoDOAPtz0BJZTkTjbpgypn8UMQ1KJaV8UFn+Fx2oDHZ34SJ6Bnp?= =?iso-8859-1?Q?TRZWo+bH6UIDjcaUVYXADUBuW6TiW8W3wFUGG6qojlTfd6w6DnIElguLFQ?= =?iso-8859-1?Q?qdB/P88t/LmVyrCFNaD5WZ/jgJsjQPnCuRITEDmbTO912T1WRGRVGBRHIx?= =?iso-8859-1?Q?KkUCnc1lvp5mWglriGa6NAafAjPHMtSxEw936W7nTh2WKYKIER6U8jkfmA?= =?iso-8859-1?Q?OSqSbagS2uHTMZ4+2xuInIDd6awkStp9B09vs7QW4XoMBuQAXKSXDWfePL?= =?iso-8859-1?Q?RHzZEMxx2NSNyUmrkmvZiUN/yZlBMsvZA5f6ZOxLzBNIKBIVWaHnBRvKkX?= =?iso-8859-1?Q?vw5FL16nrZM5JWZv4h/71ZAMmtLASlqftQl77a4RC/P+zTSQYDVSKBRPdH?= =?iso-8859-1?Q?vpoFtSUQvJ70L3HCDAZ4Tncs8NpOa4Y=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ff4ce41-082e-4f2b-0145-08df184831d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 01:24:06.2683 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XOjvVxA5cK8dVphpKgykx0dxfDijMOmGIwJZP6cJjzGIzsJHWUZ1S2iZ4ypF5s2j+4gePJlQe1VEHUpSntYsENJtwntOeYdNGg9dz9fQK6Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7456 X-purgate-ID: tlsNG-16d1c6/1790040251-F520877B-B0CB7199/0/0 X-purgate-type: clean X-purgate-size: 3130 Hi Jan, Jan Beulich writes: > Casting away const-ness (or volatile-ness) is never a good idea, but > some library functions (e.g. strchr()) require doing so. Where not > required, remove / replace respective casts. > > While there convert touched functions to Xen style. > > No functional change intended. > > Signed-off-by: Jan Beulich Reviewed-by: Volodymyr Babchuk > > --- a/xen/lib/memcpy.c > +++ b/xen/lib/memcpy.c > @@ -15,12 +15,13 @@ > */ > void *(memcpy)(void *dest, const void *src, size_t n) > { > - char *tmp =3D (char *) dest, *s =3D (char *) src; > + char *tmp =3D dest; > + const char *s =3D src; > =20 > - while (n--) > - *tmp++ =3D *s++; > + while ( n-- ) > + *tmp++ =3D *s++; > =20 > - return dest; > + return dest; > } > =20 > /* > --- a/xen/lib/memmove.c > +++ b/xen/lib/memmove.c > @@ -14,21 +14,25 @@ > */ > void *(memmove)(void *dest, const void *src, size_t n) > { > - char *tmp, *s; > + char *tmp; > + const char *s; > =20 > - if (dest <=3D src) { > - tmp =3D (char *) dest; > - s =3D (char *) src; > - while (n--) > - *tmp++ =3D *s++; > - } else { > - tmp =3D (char *) dest + n; > - s =3D (char *) src + n; > - while (n--) > - *--tmp =3D *--s; > - } > + if ( dest <=3D src ) > + { > + tmp =3D dest; > + s =3D src; > + while ( n-- ) > + *tmp++ =3D *s++; > + } > + else > + { > + tmp =3D dest + n; > + s =3D src + n; > + while ( n-- ) > + *--tmp =3D *--s; > + } > =20 > - return dest; > + return dest; > } > =20 > /* > --- a/xen/lib/strcmp.c > +++ b/xen/lib/strcmp.c > @@ -11,16 +11,15 @@ > */ > int (strcmp)(const char *cs, const char *ct) > { > - unsigned char *csu =3D (unsigned char *)cs; > - unsigned char *ctu =3D (unsigned char *)ct; > - int res; > + const unsigned char *csu =3D (const void *)cs; > + const unsigned char *ctu =3D (const void *)ct; > + int res; > =20 > - while (1) { > - if ((res =3D *csu - *ctu++) !=3D 0 || !*csu++) > - break; > - } > + for ( ; ; ) > + if ( (res =3D *csu - *ctu++) !=3D 0 || !*csu++ ) > + break; > =20 > - return res; > + return res; > } > =20 > /* > --- a/xen/lib/strncmp.c > +++ b/xen/lib/strncmp.c > @@ -12,17 +12,18 @@ > */ > int (strncmp)(const char *cs, const char *ct, size_t count) > { > - unsigned char *csu =3D (unsigned char *)cs; > - unsigned char *ctu =3D (unsigned char *)ct; > - int res =3D 0; > + const unsigned char *csu =3D (const void *)cs; > + const unsigned char *ctu =3D (const void *)ct; > + int res =3D 0; > =20 > - while (count) { > - if ((res =3D *csu - *ctu++) !=3D 0 || !*csu++) > - break; > - count--; > - } > + while ( count ) > + { > + if ( (res =3D *csu - *ctu++) !=3D 0 || !*csu++ ) > + break; > + count--; > + } > =20 > - return res; > + return res; > } > =20 > /* --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:36:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:36:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427978.1650671 (Exim 4.92) (envelope-from ) id 1x8pQU-0004Fg-S6; Tue, 22 Sep 2026 01:36:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427978.1650671; Tue, 22 Sep 2026 01:36:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQU-0004FZ-PO; Tue, 22 Sep 2026 01:36:06 +0000 Received: by outflank-mailman (input) for mailman id 1427978; Tue, 22 Sep 2026 01:36:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQS-0004FT-SK for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:36:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pQR-003tGf-7v for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:36:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1db67-8faa-0a2a0a5109dd-0a2a4504bc24-10 for ; Tue, 22 Sep 2026 03:36:02 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1db81-b57f-0a2a45040019-d561b3388042-3 for ; Tue, 22 Sep 2026 03:36:02 +0200 Received: from 186-249-150-130.shared.desktop.com.br ([186.249.150.130] helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x8pQL-005NkF-NW; Tue, 22 Sep 2026 03:35:58 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:From" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version: Message-Id:Date:Subject:From:From:Reply-To; bh=S1EgHIylds1ROVkxx4WLm8LwHoN49L9fR7QZ0PSDjlM=; b=mJpvDkNfkVfqiiMatI5KEUuKqI Nk71VHx66H0j9T9L/fZnd403I9wLGzc6TUuCO9rzxO6V82sBQne0ln70rjx1C8q/sQO3kafqcWwqr vOIzMoQ4aWA3HlxxsLi3WqfzLmxQxm5YeYRgNjYl4iDammiYbdGcyCGH4xTnXmlF5wdRZTmTRzSBV aQgmksxVJnZPQ2eihbLUNnsWosZrr/vXGI86fPFcyVU9o1Hlfkja/6nGtVGe+F861XohfkfRImSU0 iAlEXVy+0dsFMJx8b6gywB/MkUqcMk1eSJ4u05ILjaAmHF/UzUSFGjQSt03XYpvfI7M8+IJbTK1JS IiVlsSGg==; From: Mauricio Faria de Oliveira Subject: [PATCH v10 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN) Date: Mon, 21 Sep 2026 22:36:31 -0300 Message-Id: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAJ/bsWoC/33SwW7DIAwA0F+pOI8JDNhhp/3HtAMhpkXrkiqZo k1V/320l0QD7WhLfrZlX8XCc+ZFvByuYuY1L3kaS6DV00HEUxiPLPNQEgIUoLIA8rKe5EdYwij zeM4jS+QUIlHSPZAoZZeZU/5+mG/vJT7l5Wuafx4tVn3P/oOtWipJjNpbY2308JqP4ZzDc5w+x V1bYS9QQ4AiQHTUd0NMCUMlmE1woBqCKULPAxP6iBypEuxewIZgixCMVowBHMehEtwmoGnN4Ir gIKToyffc6UrATSClGwLetwjeK+uGFHyqBNoJ0BKoCKYrAwSnIidVCd1eMA2hK0LUCSFqh8nV1 /Sb0DX/wReBSXEyPbn+zzVvt9svp9zQCcICAAA= X-Change-ID: 20260422-pvh-kasan-inline-6efac77f1b27 To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira X-Mailer: b4 0.14.2 X-purgate-ID: tlsNG-ebf023/1790040962-526CAB50-AC4EA478/0/0 X-purgate-type: clean X-purgate-size: 8730 The issue of unbootable VMs with CONFIG_PVH due to CONFIG_KASAN is back. Booting directly from vmlinux (instead of bzImage) now fails with gcc-14/15 (but works with gcc-12/13) if CONFIG_KASAN_GENERIC is set, on Ubuntu 25.10. The PVH code is required/supposed not to use the KASAN memory access check in the kernel entry point as KASAN has not yet been setup, or an exception is hit and the boot fails. This was previously described and addressed with __builtin_mem{cmp,set}(): - commit 661362e3dcab ("xen, pvh: fix unbootable VMs (PVH + KASAN - AMD_MEM_ENCRYPT)") - commit 416a33c9afce ("x86/cpu: fix unbootable VMs by inlining memcmp() in hypervisor_cpuid_base()") - commit fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()") However, even with __builtin the compiler may decide to use the out of line function instead of the inline implementation. So, that does not really fix the issue unconditionally; see details below. In order to address this, it's required to switch to inline implementations that do not depend on the compiler. There's such a memset() in and memcmp() in 'boot/string.c'. Use them instead of builtins in PVH entry. Testing: - Booting from vmlinux (fixed) and bzImage (still works) using allnoconfig + CONFIG_PVH + CONFIG_KASAN with gcc-12/13/14/15. - Building with CONFIG_KEXEC_FILE, CONFIG_CFI and !CONFIG_KASAN with LLVM 20 (check for a build error not caught previously). Details/Debugging: - Only CONFIG_PVH (works): make allnoconfig ./scripts/config \ -e 64BIT -e HYPERVISOR_GUEST -e PVH \ -e SERIAL_8250 -e SERIAL_8250_CONSOLE make olddefconfig make -j$(nproc) vmlinux qemu-system-x86_64 \ -accel kvm -nodefaults -nographic -serial stdio \ -kernel vmlinux -append 'console=ttyS0' ... SeaBIOS (version ...) Booting from ROM... Linux version ... ... - With CONFIG_KASAN (fails) ./scripts/config -e KASAN make olddefconfig make -j$(nproc) vmlinux qemu-system-x86_64 \ -accel kvm -nodefaults -nographic -serial stdio \ -kernel vmlinux -append 'console=ttyS0' ... SeaBIOS (version ...) Booting from ROM... - Debugging: Enable debug info and rebuild. QEMU: enable and wait for GDB, stop rebooting, remain running. qemu-system-x86_64 \ -s -S -no-reboot -no-shutdown \ gdb vmlinux (gdb) target remote localhost:1234 ... (gdb) c ... Thread 2 received signal SIGQUIT, Quit. ... (gdb) info threads Id Target Id Frame 1 Thread 1.1 (CPU#0 [running]) bytes_is_nonzero ( start=0xfffffbfff031eebe , size=1) at .../linux/mm/kasan/generic.c:98 * 2 Thread 1.2 (CPU#1 [halted ]) 0x00000000000fd0a9 in ?? () ... (gdb) thr 1 ... (gdb) bt #0 bytes_is_nonzero (start=0xfffffbfff031eebe , size=1) at .../linux/mm/kasan/generic.c:98 #1 memory_is_nonzero (start=0xfffffbfff031eebe, end=0xfffffbfff031eebf) at .../linux/mm/kasan/generic.c:115 #2 memory_is_poisoned_n (addr=0xffffffff818f75f0, size=8) at .../linux/mm/kasan/generic.c:140 #3 memory_is_poisoned (addr=0xffffffff818f75f0, size=8) at .../linux/mm/kasan/generic.c:172 #4 check_region_inline (addr=0xffffffff818f75f0, size=8, write=false, ret_ip=18446744071585002062) at .../linux/mm/kasan/generic.c:191 #5 kasan_check_range (addr=addr@entry=0xffffffff818f75f0, size=size@entry=8, write=write@entry=false, ret_ip=18446744071585002062) at .../linux/mm/kasan/generic.c:200 #6 0xffffffff813eb283 in __asan_loadN (addr=addr@entry=0xffffffff818f75f0, size=size@entry=8) at .../linux/mm/kasan/generic.c:278 #7 0xffffffff815df24e in memcmp (cs=cs@entry=0xffffffff818f75f0, ct=ct@entry=0x1be2fe4, count=, count@entry=12) at .../linux/lib/string.c:683 #8 0xffffffff81ba2323 in cpuid_base_hypervisor (sig=0xffffffff818f75f0 "XenVMMXenVMM", leaves=2) at .../linux/arch/x86/include/asm/cpuid/api.h:206 #9 xen_cpuid_base () at .../linux/arch/x86/include/asm/xen/hypervisor.h:46 #10 xen_prepare_pvh () at .../linux/arch/x86/platform/pvh/enlighten.c:119 #11 0x0000000001ba2588 in ?? () #12 0x0000000000000000 in ?? () (gdb) Frames #7-#8 show the non-builtin memcmp() (lib/string.c) was called even with __builtin_memcmp() being used in cpuid_base_hypervisor(). Signed-off-by: Mauricio Faria de Oliveira --- Changes in v10: - Patch 1: - retain the "cc" clobber commented out (Borislav Petkov) - explain based on compiler implementation, not documentation (Borislav Petkov, Michael Matz) - Patch 2: - remove single quotes from filenames in commit message (Borislav Petkov) - simplify function comment (Borislav Petkov) - Patch 4: - combine Patch 5 from v9 (Borislav Petkov) - update function name: s/hypervisor_base_cpuid/cpuid_base_hypervisor/g - slightly modify the commit message. - Link to v9: https://lore.kernel.org/r/20260822-pvh-kasan-inline-v9-0-e70ef3b75b6a@igalia.com Changes in v9: - Patch 1: new patch in v9 to fix the patch submitted separately in v8. - Rebased to next-20260821. - Link to v8: https://lore.kernel.org/r/20260723-pvh-kasan-inline-v8-0-c1f62c156f52@igalia.com Changes in v8: - Patch 2 in v7 was submitted separately as requested, and the rest of this series was rebased on top of it (Borislav Petkov). Link: https://lore.kernel.org/all/20260723-x86-memcmp-asm-v2-1-d93ecb43797f@igalia.com/ - Patch 2 in v8: - Mention 'No functional changes' (Borislav Petkov). - Remove comment at the top of the header (Borislav Petkov). - Link to v7: https://lore.kernel.org/r/20260721-pvh-kasan-inline-v7-0-38979a50cef0@igalia.com Changes in v7: - Patch 2 (added): - Address pre-existing issues in 'asm' (Borislav Petkov, Sashiko). - Link to v6: https://lore.kernel.org/r/20260701-pvh-kasan-inline-v6-0-ba99045dfa9f@igalia.com Changes in v6: - Patch 1: - Explain the return value difference between __inline_memcmp() and memcmp(). - Patch 2 (added): - Group __inline string functions in . - Link to v5: https://lore.kernel.org/r/20260630-pvh-kasan-inline-v5-0-52afc979be81@igalia.com Changes in v5: - Create a minimal separate header in instead, to be used by 'boot/setup.c' and (Borislav Petkov). - Patch 1 (in v4/v3) is no longer needed; removed. - Patch 1 (in v5): - Briefly mention there are issues with . - Remove 'Reviewed-by: Jurgen Gross' to be conservative (same code change and result, but the means changed). - Link to v4: https://lore.kernel.org/r/20260526-pvh-kasan-inline-v4-0-a310e6a25ecd@igalia.com Changes in v4: - Patch 1: address Juergen's feedback: - s/In next patch/In a future patch/. - Move footnote (Reasons not to include...) after "---". - Add 'Reviewed-by: Juergen Gross' in patches 1 and 2 as well. - Link to v3: https://lore.kernel.org/r/20260520-pvh-kasan-inline-v3-0-bede769c6ec7@igalia.com Changes in v3: - Create and use a separate header for inline string functions to fix a build error reported by kernel test robot (patch 1). - That also removes '#ifndef _SETUP/#endif' in . - Link to v2: https://lore.kernel.org/r/20260427-pvh-kasan-inline-v2-0-2c57b8dcff6a@igalia.com Changes in v2: - Add comment about the return value of __inline_memcmp() in patch 1. (v3: now 2) - Add 'Reviewed-by: Juergen Gross' in patches 2 and 3 (v3: now 3 and 4). - Link to v1: https://lore.kernel.org/r/20260422-pvh-kasan-inline-v1-0-7e6194344c92@igalia.com --- Mauricio Faria de Oliveira (4): x86/boot: comment out and document redundant "cc" clobber in memcmp() x86/asm, x86/boot: expose inline memcmp() x86/asm: group inline string functions x86/cpuid: fix unbootable VMs by really inlining memcmp() in cpuid_base_hypervisor() and xen_prepare_pvh() arch/x86/boot/string.c | 13 ++------- arch/x86/include/asm/cpuid/api.h | 2 +- arch/x86/include/asm/shared/string.h | 52 ++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/string.h | 21 +-------------- arch/x86/platform/pvh/enlighten.c | 3 ++- 5 files changed, 58 insertions(+), 33 deletions(-) --- base-commit: 5c4d4169604b335c38bbc79bc1fc03042981fc6f change-id: 20260422-pvh-kasan-inline-6efac77f1b27 Best regards, -- Mauricio Faria de Oliveira From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:36:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:36:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427979.1650680 (Exim 4.92) (envelope-from ) id 1x8pQZ-0004SX-2Y; Tue, 22 Sep 2026 01:36:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427979.1650680; Tue, 22 Sep 2026 01:36:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQY-0004SQ-Vs; Tue, 22 Sep 2026 01:36:10 +0000 Received: by outflank-mailman (input) for mailman id 1427979; Tue, 22 Sep 2026 01:36:09 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQX-0004S6-Qh for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:36:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pQW-00172J-S7 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:36:08 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1db73-2eae-0a2a0a5409dd-0a2a4501cc06-20 for ; Tue, 22 Sep 2026 03:36:08 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1db87-5984-0a2a45010019-d561b338ace6-3 for ; Tue, 22 Sep 2026 03:36:08 +0200 Received: from 186-249-150-130.shared.desktop.com.br ([186.249.150.130] helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x8pQV-005NkF-4j; Tue, 22 Sep 2026 03:36:07 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type: MIME-Version:Subject:Date:From:From:Reply-To; bh=wN61/NMUXl8+9R6hcjMozN8cH7kE8ssen0RwmNOyhaw=; b=CrVUaQ0+B87GdmscCHTnNP8VEF +qdlqxIhIySV9oSq9UbjJGCumPJ4KKHHlB77hnREOlp4czDEjNMYy24Y8eXEYPYbFVWGU6Bhe0r0O eXI8EUm+awT/31kIviX4jw87FCtRKUq778TW4GMw0jRNAZLCOHqn0gTxh+XpWo4tJSrA+Slu7zKmC InK+jrO8tkCBmcldBgv2KVpZ+FZVjbX9sOjWOzQMMBxPVV2inqpbQkrbofSozJ02mGnD81wWTKoKP KXESrL2cNTaAqNgrS5nzkqoKQAjJX+CM0yU2BvoMvGPj+OQAM6lwOFbYgPnb/Frw8FROzTo2IhQIH nvRatv2w==; From: Mauricio Faria de Oliveira Date: Mon, 21 Sep 2026 22:36:32 -0300 Subject: [PATCH v10 1/4] x86/boot: comment out and document redundant "cc" clobber in memcmp() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260921-pvh-kasan-inline-v10-1-08da47943d8e@igalia.com> References: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> In-Reply-To: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira X-Mailer: b4 0.14.2 X-purgate-ID: tlsNG-d62444/1790040968-C4B45757-CF54A35B/0/0 X-purgate-type: clean X-purgate-size: 1895 The "cc" clobber remains recognized for source compatibility, but it has no meaning anymore; it is automatically generated without condition-code constraints (explanation in [1]; related code in gcc [2] and clang [3]). Comment out the redundant "cc" clobber for documentation purposes. Reported-by: "H. Peter Anvin" Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/ Link: https://lore.kernel.org/all/57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de/ [1] Link: https://github.com/gcc-mirror/gcc/blob/78d4ac73dd391005b895a6148cd9831e28e1208b/gcc/config/i386/i386.cc#L25355-L25363 [2] Link: https://github.com/llvm/llvm-project/blob/6dfe1677ab8dffbc6ec13d53a1e0215d75147689/clang/lib/Basic/Targets/X86.h#L299-L301 [3] Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()") Signed-off-by: Mauricio Faria de Oliveira --- arch/x86/boot/string.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c index 1632d40e1f545ae0665597069b568ea6b6c263e5..e10260ed58b69fc734a4e63f15785a643f414441 100644 --- a/arch/x86/boot/string.c +++ b/arch/x86/boot/string.c @@ -36,11 +36,15 @@ int memcmp(const void *s1, const void *s2, size_t len) /* * Make sure ZF is properly set in the len==0 case because in it, * RCX==0 and the REPE; CMPSB won't get executed. + * + * The "cc" clobber has no meaning anymore, just source compatibility. + * On x86 the flag status bits are automatically added to the clobber + * set when there are no =@ccXY constraints. Keep it as documentation. */ asm volatile("test %3, %3\n\t" "repe cmpsb" : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) - : : "cc", "memory"); + : : /* "cc", */ "memory"); return diff; } -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:36:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:36:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427980.1650691 (Exim 4.92) (envelope-from ) id 1x8pQh-0004j4-AG; Tue, 22 Sep 2026 01:36:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427980.1650691; Tue, 22 Sep 2026 01:36:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQh-0004it-6Q; Tue, 22 Sep 2026 01:36:19 +0000 Received: by outflank-mailman (input) for mailman id 1427980; Tue, 22 Sep 2026 01:36:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQf-0004hr-GG for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:36:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pQe-00Ee9j-Kc for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:36:16 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1db62-e002-0a2a0a5209dd-0a2a4503e1f0-44 for ; Tue, 22 Sep 2026 03:36:15 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1db8f-fae8-0a2a45030019-d561b338d8ce-3 for ; Tue, 22 Sep 2026 03:36:15 +0200 Received: from 186-249-150-130.shared.desktop.com.br ([186.249.150.130] helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x8pQc-005NkF-0M; Tue, 22 Sep 2026 03:36:14 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type: MIME-Version:Subject:Date:From:From:Reply-To; bh=j9CxFCWuPrvGlLqznnNoJgjx2OHznuUku/3wRXkyArk=; b=L0/vA5CkOQE34d8kurstyXKXMd lHLDh/ey5KyOtpiMjY+BGOESVYS31Wt/ziwV+XCmlCgmrWP3DVjLKHR1/SjTBaerDhXthhtLYKjPp ccpPKU0bquKjhsW3FRuX414I6hM/xsBkgIMXTVwOHUWgYOF6oyHfPn2jV6glcREYLCz/C4AyurK+y GFlgIqH89YGxE77Su4xXzx27M5P7IxSe44MF7I6vXW2Mkm6OAIlO4uHwbybv8ZD2lOpHFoPs17HIH hQg1Pd3WXC5MklfBe6qmbxxYLfqLNw+MfB+aYCHNYFCb1L94385Gg0neNNicnYmQlk5Q8lwBjUodw yEheJjVg==; From: Mauricio Faria de Oliveira Date: Mon, 21 Sep 2026 22:36:33 -0300 Subject: [PATCH v10 2/4] x86/asm, x86/boot: expose inline memcmp() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260921-pvh-kasan-inline-v10-2-08da47943d8e@igalia.com> References: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> In-Reply-To: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira X-Mailer: b4 0.14.2 X-purgate-ID: tlsNG-33051d/1790040975-6FCC34E9-584DA3F3/0/0 X-purgate-type: clean X-purgate-size: 3044 Move the inline memcmp function currently only available in boot/string.c into the shared string function header to be reused. This is not done through to avoid pulling unnecessary code in boot/string.c that causes build errors in boot/compressed/string.c and purgatory/purgatory.ro. No functional changes. Signed-off-by: Mauricio Faria de Oliveira --- Thanks to David Laight for noticing the return value difference between inline and regular memcmp(). --- arch/x86/boot/string.c | 17 ++--------------- arch/x86/include/asm/shared/string.h | 31 +++++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 15 deletions(-) diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c index e10260ed58b69fc734a4e63f15785a643f414441..be454a6864225f3a972c3e81826b77ed4e8a57fe 100644 --- a/arch/x86/boot/string.c +++ b/arch/x86/boot/string.c @@ -15,6 +15,7 @@ #include #include #include +#include #include "ctype.h" #include "string.h" @@ -31,21 +32,7 @@ int memcmp(const void *s1, const void *s2, size_t len) { - bool diff; - - /* - * Make sure ZF is properly set in the len==0 case because in it, - * RCX==0 and the REPE; CMPSB won't get executed. - * - * The "cc" clobber has no meaning anymore, just source compatibility. - * On x86 the flag status bits are automatically added to the clobber - * set when there are no =@ccXY constraints. Keep it as documentation. - */ - asm volatile("test %3, %3\n\t" - "repe cmpsb" - : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) - : : /* "cc", */ "memory"); - return diff; + return __inline_memcmp(s1, s2, len); } /* diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h new file mode 100644 index 0000000000000000000000000000000000000000..6291653fe629babf15e29060b013d357d8eacf4c --- /dev/null +++ b/arch/x86/include/asm/shared/string.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_X86_SHARED_STRING_H +#define _ASM_X86_SHARED_STRING_H + +/* + * Returns: 0 (equal) + * 1 (not equal) + * + * In contrast, the regular memcmp() follows glibc return value semantics. + */ +static __always_inline int __inline_memcmp(const void *s1, const void *s2, size_t len) +{ + bool diff; + + /* + * Make sure ZF is properly set in the len==0 case because in it, + * RCX==0 and the REPE; CMPSB won't get executed. + * + * The "cc" clobber has no meaning anymore, just source compatibility. + * On x86 the flag status bits are automatically added to the clobber + * set when there are no =@ccXY constraints. Keep it as documentation. + */ + asm volatile("test %3, %3\n\t" + "repe cmpsb" + : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) + : : /* "cc", */ "memory"); + + return diff; +} + +#endif /* _ASM_X86_SHARED_STRING_H */ -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:36:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:36:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427983.1650700 (Exim 4.92) (envelope-from ) id 1x8pQo-00051i-I4; Tue, 22 Sep 2026 01:36:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427983.1650700; Tue, 22 Sep 2026 01:36:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQo-00051U-Cd; Tue, 22 Sep 2026 01:36:26 +0000 Received: by outflank-mailman (input) for mailman id 1427983; Tue, 22 Sep 2026 01:36:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQm-0004zp-FB for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:36:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pQl-00172J-SX for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:36:23 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1daab-2eae-0a2a0a5409dd-0a2a450aec12-48 for ; Tue, 22 Sep 2026 03:36:23 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1db97-f2d2-0a2a450a0019-d561b338b002-3 for ; Tue, 22 Sep 2026 03:36:23 +0200 Received: from 186-249-150-130.shared.desktop.com.br ([186.249.150.130] helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x8pQk-005NkF-GM; Tue, 22 Sep 2026 03:36:22 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type: MIME-Version:Subject:Date:From:From:Reply-To; bh=/0RnjeWeqK4aiVrc0W7dEG+Kp++1YdIPUBuPx6eJkJo=; b=piMg6SB47ayxfzarEnOYpmtKR1 uTyjJv5bKFQt0uxq8Ag9kFZz9ttM441plX3lbFarwhxbBiykQOHq7yMtEeKdDfdiv1Qz4f6b7WxPI re8ZfcQihykfWDfPCO7HAXelkL09g8BbUqwzyjjRalKtqJ3Zk/cCH0sjfA4fSYHw7T3jiqshaYj5a JrvKdiI3RLfmxVtbnq/svAvDHhrmtXlZWsOxxOYAv8sTx2hFZGK8Byn6bwXfGbtbvtODi7GFGtDfa XwIFcmSatLglcOYEcod85tibWAYZct+YJAhZldjDa6mOmc9MlMshgoWNG981zxVioPDZYwzoyUajw IGF/86yQ==; From: Mauricio Faria de Oliveira Date: Mon, 21 Sep 2026 22:36:34 -0300 Subject: [PATCH v10 3/4] x86/asm: group inline string functions MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260921-pvh-kasan-inline-v10-3-08da47943d8e@igalia.com> References: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> In-Reply-To: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira X-Mailer: b4 0.14.2 X-purgate-ID: tlsNG-4011c0/1790040983-50ACCCFC-3F9B2406/0/0 X-purgate-type: clean X-purgate-size: 2172 Group the __inline string functions in the same header. Use since __inline_memcmp() must remain there for use by arch/x86/boot/string.c. No functional changes. Signed-off-by: Mauricio Faria de Oliveira --- arch/x86/include/asm/shared/string.h | 21 +++++++++++++++++++++ arch/x86/include/asm/string.h | 21 +-------------------- 2 files changed, 22 insertions(+), 20 deletions(-) diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h index 6291653fe629babf15e29060b013d357d8eacf4c..6bef90d62a21138ec56c939ffc474732999bf465 100644 --- a/arch/x86/include/asm/shared/string.h +++ b/arch/x86/include/asm/shared/string.h @@ -2,6 +2,27 @@ #ifndef _ASM_X86_SHARED_STRING_H #define _ASM_X86_SHARED_STRING_H +static __always_inline void *__inline_memcpy(void *to, const void *from, size_t len) +{ + void *ret = to; + + asm volatile("rep movsb" + : "+D" (to), "+S" (from), "+c" (len) + : : "memory"); + return ret; +} + +static __always_inline void *__inline_memset(void *s, int v, size_t n) +{ + void *ret = s; + + asm volatile("rep stosb" + : "+D" (s), "+c" (n) + : "a" ((uint8_t)v) + : "memory"); + return ret; +} + /* * Returns: 0 (equal) * 1 (not equal) diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h index 9cb5aae7fba9ffcf0f5af8f939d30467750ccaa9..dbf59f0d4cca71e2ddce0d8764aeec8782236669 100644 --- a/arch/x86/include/asm/string.h +++ b/arch/x86/include/asm/string.h @@ -8,25 +8,6 @@ # include #endif -static __always_inline void *__inline_memcpy(void *to, const void *from, size_t len) -{ - void *ret = to; - - asm volatile("rep movsb" - : "+D" (to), "+S" (from), "+c" (len) - : : "memory"); - return ret; -} - -static __always_inline void *__inline_memset(void *s, int v, size_t n) -{ - void *ret = s; - - asm volatile("rep stosb" - : "+D" (s), "+c" (n) - : "a" ((uint8_t)v) - : "memory"); - return ret; -} +#include #endif /* _ASM_X86_STRING_H */ -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:36:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:36:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1427989.1650707 (Exim 4.92) (envelope-from ) id 1x8pQw-0005VB-RZ; Tue, 22 Sep 2026 01:36:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1427989.1650707; Tue, 22 Sep 2026 01:36:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQw-0005V3-Oc; Tue, 22 Sep 2026 01:36:34 +0000 Received: by outflank-mailman (input) for mailman id 1427989; Tue, 22 Sep 2026 01:36:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pQv-0005RG-Io for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:36:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pQu-00Ee9j-W5 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:36:33 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1db99-e002-0a2a0a5209dd-0a2a450adcd2-12 for ; Tue, 22 Sep 2026 03:36:32 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1db9f-f2d2-0a2a450a0019-d561b338c86c-3 for ; Tue, 22 Sep 2026 03:36:32 +0200 Received: from 186-249-150-130.shared.desktop.com.br ([186.249.150.130] helo=[127.0.1.1]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x8pQs-005NkF-MI; Tue, 22 Sep 2026 03:36:30 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Cc:To:Message-Id:Content-Transfer-Encoding:Content-Type: MIME-Version:Subject:Date:From:From:Reply-To; bh=vD0k0Ck20NkaSxC+0yD9Mf/6md9yMaogJma8MOuOCCM=; b=IpObFzvx6OMOkVteh8tSW55725 2zMdnjO0AJ2F0aI9fUvhxpgfdu/a6I9p52vKandRvZpy811pd5QsAzeLT/t2csxIKraMucDaL0qK3 wDdUbce7+tYpFzUxggUko7j5ytHpdkWEYoxjRl5FsXaFi4DWreCxw5pC9s08IqQZAL4fpxpoKyO// 15N6GxwY/ukBdeX1IJse6gmHiNXxbBgb7YcSysNJZYCe4TD5O4Ob8SSyVot0nDIzg2M0rdiW/5UOj C5ZRct7ITrl98hI4NnU1kPPKGt5yondaXCc53o1YApMrXrXBuUJT6pwyMqUPIpmBlKI/weInDJwpV XY9F7PhQ==; From: Mauricio Faria de Oliveira Date: Mon, 21 Sep 2026 22:36:35 -0300 Subject: [PATCH v10 4/4] x86/cpuid: fix unbootable VMs by really inlining memcmp() in cpuid_base_hypervisor() and xen_prepare_pvh() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260921-pvh-kasan-inline-v10-4-08da47943d8e@igalia.com> References: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> In-Reply-To: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Mauricio Faria de Oliveira X-Mailer: b4 0.14.2 X-purgate-ID: tlsNG-4011c0/1790040992-5A3DCCFC-1BAD1775/0/0 X-purgate-type: clean X-purgate-size: 2662 Even with __builtin the compiler may decide to use the out of line function instead of the inline implementation. The existing code is broken with gcc-14/15 but not gcc-12/13 (Ubuntu 25.10) and vmlinux no longer boots with CONFIG_PVH if CONFIG_KASAN_GENERIC is set. The instrumented out of line function performs a memory access to a region not yet initialized by KASAN, as it is still in the PVH kernel entry point. For testing purposes, if the size argument in cpuid_base_hypervisor() is reduced from 12 to 8 the compiler decides to use the inline implementation. In xen_prepare_pvh(), it (still) decides to use the inline implementation (at least in these compiler versions), but it is not guaranteed to remain. Switch the builtin to the inline implementation to address this. Fixes: 416a33c9afce ("x86/cpu: fix unbootable VMs by inlining memcmp() in hypervisor_cpuid_base()") Fixes: fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()") Signed-off-by: Mauricio Faria de Oliveira Reviewed-by: Juergen Gross --- arch/x86/include/asm/cpuid/api.h | 2 +- arch/x86/platform/pvh/enlighten.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h index 82eddfa2347b32b76c2ea9b85f005ca5416ac71f..2d9f3d4d63de6e721f275d9e80d372edbdfedf30 100644 --- a/arch/x86/include/asm/cpuid/api.h +++ b/arch/x86/include/asm/cpuid/api.h @@ -204,7 +204,7 @@ static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves) * from PVH early boot code before instrumentation is set up * and memcmp() itself may be instrumented. */ - if (!__builtin_memcmp(sig, signature, 12) && + if (!__inline_memcmp(sig, signature, 12) && (leaves == 0 || ((eax - base) >= leaves))) return base; } diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c index f2053cbe9b0ce3d2178938269607c652ae8f528e..cb442cbd9d828619421babb281bfe9759edbca8a 100644 --- a/arch/x86/platform/pvh/enlighten.c +++ b/arch/x86/platform/pvh/enlighten.c @@ -8,6 +8,7 @@ #include #include #include +#include #include @@ -129,7 +130,7 @@ void __init xen_prepare_pvh(void) * This must not compile to "call memset" because memset() may be * instrumented. */ - __builtin_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams)); + __inline_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams)); hypervisor_specific_init(xen_guest); -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:38:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:38:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428011.1650718 (Exim 4.92) (envelope-from ) id 1x8pTD-0006xN-7r; Tue, 22 Sep 2026 01:38:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428011.1650718; Tue, 22 Sep 2026 01:38:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pTD-0006xG-41; Tue, 22 Sep 2026 01:38:55 +0000 Received: by outflank-mailman (input) for mailman id 1428011; Tue, 22 Sep 2026 01:38:54 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pTC-0006xA-FJ for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:38:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pTB-002gUU-Ro for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:38:53 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1dc09-e002-0a2a0a5209dd-0a2a45038a50-8 for ; Tue, 22 Sep 2026 03:38:53 +0200 Received: from [40.107.130.117] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1dc2d-fae8-0a2a45030019-286b8275a079-3 for ; Tue, 22 Sep 2026 03:38:53 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by DU0PR03MB8764.eurprd03.prod.outlook.com (2603:10a6:10:410::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 01:38:50 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 01:38:49 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ke65qUcf3o2jVUC/74NBANBgtqwHL6SWTn8Bxoo5+HZ/WN6WX3/U1f3oD4xCs3LQfa6vwVBimby72KWg383IPnBkRYGYvoWMOcc1CviaOf5uH/r/Tn94s7HA6rHwq0gjwAIGhBhtP+baE+50m77m244VXzcZN+YQE+ZMkzpDmZt0t0nl1QyqFYFMkl/IhkYrGgEZrZzBXXBPeDgvSfjRb8TdLdfTEE4siBXgnAp4G+TbAGbKr8cRUNwsIOlZ1tRpvdoeA8F9HBSH+SOBMxeK373i8Ikp9zq/Usw0yUmvboW3fg/jDLOVCrrue+ZTJzT0QpUwPgj0ENfs3gmj/Krc7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CsMUKnh3vh9o89yTEYUUhLjALRKkl1FwoelPpntop3g=; b=pRP5OrXrYOk+6yDbosOiDBqYfmY2nR4gxJlKOTY47dfg8nAdST6qgrdsxaXm7xWcuwgStTRMNnxFWsqLBSKZDuD77WDIo5diXjLlXEW0IsnUyDWuw8v+ueXKhi2VLuwp+4wzXSc6+5cvlHc0sLCunUU0RxNuY7OnKakjX4fvQ5J4xpymkZBzz8jJgtrCFnOln7Y6BoAjKsuNXP5xUj8/aTnfzyDHeLtCvUzbT+EXcV9THiFDQGLB20J8nv+aFxtSycz6LrcA0QE9aSonkJkpGH8/hxMIZbzPZvPC9x69oRWM6SNx7kppLGJ/CQldw3CdQqC8EgxARt/XWznG6HxdUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CsMUKnh3vh9o89yTEYUUhLjALRKkl1FwoelPpntop3g=; b=gKo/DNhP4gVEiOD2avnmuJf0qqNN+VOo+WP74ytaSWpAu0Lz5LYb0fcd3AugJ2nPX9bQ2dcTJM6tN0iozk/e57kWkgxopRRgw9vq5prh76yylZ/RitVmeyDCEpoNNHc1bpzJ5iAawcv5TImk4UvuINd2d+JTva1LSuPVx+owSubE4toXmUTgTAssC78MDeqHpjMKaJjQUzbdGSuL2uxAmVK7VkSN1xZkEBVgV2Kq3XoWOE56fp9gDpG7cSB9apIPqIXQBijxvbJUdhmmhqFrTjDCc/3m05279bIiPPqKVh+J2/0XE1ckPb+uSOKu06mc6add9zFIRNv0d7c0/qVPeA== From: Volodymyr Babchuk To: Jan Beulich CC: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Bertrand Marquis Subject: Re: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code Thread-Topic: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code Thread-Index: AQHdOqUePUfY0zBPU0K0F/hx5odMHA== Date: Tue, 22 Sep 2026 01:38:49 +0000 Message-ID: <87qzim6p5i.fsf@epam.com> References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> In-Reply-To: (Jan Beulich's message of "Wed, 2 Sep 2026 08:34:09 +0200") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|DU0PR03MB8764:EE_ x-ms-office365-filtering-correlation-id: 0fa83995-07f5-41f3-acc1-08df184a4087 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|42112799006|7416014|38070700021|10067099003|56012099006|11063799006|4143699003|18002099003|22082099003; x-microsoft-antispam-message-info: xuIxhnhKopfxHoKlW8At3FzZA1wvJw2FVbqSXNyiVTESuc+xcEpvct4Dcb61JuA610aajbCHv2ZOgW08IU2yF5Hjx/Xi4P19ObmDykVAcW9HGph6v2nVHRfVFyJdL95M+nIOHiaL+AHK4ihddUHHePJUG+VfZNfRwjMsZccr3Th3kxXJ1tFb2cFQwY4czG7bQ2yQR3bgZxfwSmLETsNmJv2D/UqcbJJl1enlhE+34ZMy/j4XV2LsSNJBNF+MAbxk4xwReWKDy+43JOfpCYQQR58c/Ovd6Z4+H6WLV8XufxUNN2DKGnQetSCiU5ZteiLyYRYYkdTQi3a6w2CPA0XiwM92nnnfHBCNnNnx7yRLY+zwNNh5vrY33iehdtKrtIRWNIMcog56HL+rox+pjpYvflEQmzMlAg4mfzdTDHfugksUjg70JGZVidnJqL5yAgegAT0DU1M0/nJNa4XvlvoDnDswEvy84HhplKOu/Uw1Y7CQCmrubfH+V8IhESZGXoy71AZkxw/ofxYZhy85XZYZMwSt9jCtlvipR/iS5XFbXpmopSp7pZrA3EkwA1bkgf8q9Fez6lMXcA9xxTjRcvXUGetjQIBXNb/Y4saY1MOBAMhVgTjvX9ErfKPSptc7QSTR3rM3J3dyf9171AXrYcWx/F/rLgjZod2Z9wtszmpUmgIWmKmeRcGnQhZxO5KofZn4s4+tt2AuIB78y77Yl3o7D7V9fYUA1sDYtlgnuLh2G+Q= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(42112799006)(7416014)(38070700021)(10067099003)(56012099006)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?2QeU7vFajhkBUE/P09vwE0bN5Jv7xBlNWvjER/uvR1tedlH8zmbzwhsuhd?= =?iso-8859-1?Q?9p48oeBMCChqfX7vspgPw8wlmgIOCWEjoDADDScKE5zL8/pCt41dgQb14S?= =?iso-8859-1?Q?+YCF0VOXRq37VyEYAn5b0YrWdRnKj0u402/Mb7mXK50NYXRNUIccfzKJrs?= =?iso-8859-1?Q?1R3XI1iM21Whtm2rN2SXEhmMWI90M+fuI7Kmyijd9FcCUvlNIhSDQ3YJgh?= =?iso-8859-1?Q?BZMK2byLTO9dCypWdrvGmQZEbLk8HkkJBQnl+87ajO3DPJRUcdUPBUUKtE?= =?iso-8859-1?Q?G6LdlAiyNR2ktdRZhyjkiQldy7JDKnzmxKLhuN7tHa+n2H+EdfY8RNSjkJ?= =?iso-8859-1?Q?B6YuOY2m1jqsT9xlcGh6zJyc/oBzdyJNX9bixDkQ44eT2clF7wGmTKUj5V?= =?iso-8859-1?Q?gkSgtV4HgEvPB3oKKBUy+e15BMvP6jt+Nbxz+Bka/W6GtpOerK7Ip/llBD?= =?iso-8859-1?Q?spoCIBznFD+sWXGth17UZbIDPnYTr+GmVVGd5M9U8EtK/R3VM8jCSYv6S0?= =?iso-8859-1?Q?/akUmWpQN0lnfSyyS1kkZ6BGF9WZ3uHufdxkWXHnph4SSw/y2M9JXHPGfD?= =?iso-8859-1?Q?OUb5+sukWsZBaY3WbRfwU589ilIqdALCiYKUUtQ7xtgur0fA5hF0vb0veP?= =?iso-8859-1?Q?zrPR5bWku5QWp3HUmMAGH3cdUCQTswmofWfUpuDAwHX69OslJFx8aOMe6u?= =?iso-8859-1?Q?RIyU5VHBpQ0qokQjKCif7SGD9wyztgh+WH37OhyLcCD5quAx+907WaEspD?= =?iso-8859-1?Q?JhcL+dMCireSbxYupqf4agiS+1WLdPc5nSLxlV62Yt7MCf8iHrVZchc3xn?= =?iso-8859-1?Q?fXV4TKB05nSWQXPb9u2SfVOLgz4HG+6TK8dfUheU4QfhQHpF4EnVbStaXw?= =?iso-8859-1?Q?ugHSGtDGWL5RrqDbRA5RBobQB7CDl3+Qw9h7pakvq8VhlsnZ4FnmtMfYWD?= =?iso-8859-1?Q?BtH73g5W6KdxtDuNdyNN87flgsy8RPBmZ+0WrlUlDDCJ0vN0nm4XeSCXaC?= =?iso-8859-1?Q?CFEKgcMma146qc166JQJx+XZ/QMeLlzV5oxjfvMssK7LDVZVF+8m4F+E/w?= =?iso-8859-1?Q?HmU3JirGv/qHxhkOzy6uPUeHjor4whCQ5pzlNglRpQmKqY2qMYaQX2eKoZ?= =?iso-8859-1?Q?P+7ItC9nxXLMNxnp97BnqlyDeeKXN//pQ3yuGUudINgFX6QlQB+whx0hPi?= =?iso-8859-1?Q?Ag9l98ZAbC2s6w2ISzz9zesFFxfD9JYRkCoyHFwBMPritxRnMWriyu7JQ7?= =?iso-8859-1?Q?VGcV4X8YGz45O/UY00ouK4JtefyJ51zrIEu5HtVGcvDo1YrOPj/GGSFQc/?= =?iso-8859-1?Q?opFt9Y4XATXKHei/29FJVP4G5i07BD/1IiF4BzOlnRmZm1cGQyjAOB+yaV?= =?iso-8859-1?Q?m/9s9at7K5I++0LEUtFEg7OA16gnil+gdr/Q0sVlWZiK+rRuWjM2o6ijif?= =?iso-8859-1?Q?Ex8Y7K7SGE0qocurCPH9tH3FVkcFoe9jo+utGtH9UXnZ6N5cOny2OgTues?= =?iso-8859-1?Q?AuMylMl8NtH3Y0o5jn6iKi14+1LbQOh3vHaqxFQAEVoqD5yjM+tHFObumf?= =?iso-8859-1?Q?futcuvua6vhvToEZW76TeB2EgBu1/nT1gyftEYw02xH2TszUXlb8YirSJw?= =?iso-8859-1?Q?FxvgzwFPpRKdzP7vbVWwWzR0m8VtQMEcZ9Y5r+1dLrXQ7jIY5FbZNGk3tH?= =?iso-8859-1?Q?Arpdpkrmu//B+mO69UUKgTcupMEYnTdFW6Fw8txQOAwZWDleOGxvpVlfF9?= =?iso-8859-1?Q?vg7mq4x95963hlvgNfc+0d19dYeBa6hHq7efIgF3ve8/UT1iIY+8UcIkDH?= =?iso-8859-1?Q?+iZ27Va7UrwQKAXR7rtVZrsWwqc08B0=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0fa83995-07f5-41f3-acc1-08df184a4087 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 01:38:49.9016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6X2UosTAelHqX5M8zjUtBS9t9ld3M5OXBpUMegWQHbZCXwS4NOQ0enOAF1CRfH0bFl4ZENjl9yfRLKH6iIaoJC3TtL32zb/8LfJnAlX8910= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8764 X-purgate-ID: tlsNG-33051d/1790041133-6D0D94E9-38833626/0/0 X-purgate-type: clean X-purgate-size: 2174 Hi Jan, Jan Beulich writes: > Outside of drivers/acpi/tables/ (which is excluded from Eclair reporting > for dubious reasons), arch/arm/acpi/domain_build.c is the only user of > ACPI_COMPARE_NAME(). Make the macro const correct, at the expense of > introducing a "const" variant of ACPI_CAST_PTR(), and at the expense of I think you can avoid adding ACPI_CAST_PTR() by providing a const type. Like this: +#define ACPI_COMPARE_NAME(a, b) (*ACPI_CAST_PTR (const u32, a) =3D= =3D \ + *ACPI_CAST_PTR (const u32, b)) > altering an imported file. > > No functional change intended. > > Signed-off-by: Jan Beulich > > --- a/xen/include/acpi/acmacros.h > +++ b/xen/include/acpi/acmacros.h > @@ -103,6 +103,7 @@ > * Pointer manipulation > */ > #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) > +#define ACPI_CAST_CPTR(t, p) ((const t *) (const acpi_uintptr= _t) (p)) > #define ACPI_CAST_INDIRECT_PTR(t, p) ((t **) (acpi_uintptr_t) (p)) > #define ACPI_ADD_PTR(t,a,b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR= (u8,(a)) + (acpi_native_uint)(b))) > #define ACPI_PTR_DIFF(a,b) (acpi_native_uint) (ACPI_CAST_PT= R (u8,(a)) - ACPI_CAST_PTR (u8,(b))) > @@ -116,9 +117,12 @@ > #define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i) > =20 > #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED > -#define ACPI_COMPARE_NAME(a,b) (*ACPI_CAST_PTR (u32,(a)) =3D=3D= *ACPI_CAST_PTR (u32,(b))) > +#define ACPI_COMPARE_NAME(a, b) (*ACPI_CAST_CPTR (u32, a) =3D=3D= \ > + *ACPI_CAST_CPTR (u32, b)) > #else > -#define ACPI_COMPARE_NAME(a,b) (!ACPI_STRNCMP (ACPI_CAST_PTR (c= har,(a)), ACPI_CAST_PTR (char,(b)), ACPI_NAME_SIZE)) > +#define ACPI_COMPARE_NAME(a, b) (!ACPI_STRNCMP (ACPI_CAST_CPTR (= char, a), \ > + ACPI_CAST_CPTR (= char, b), \ > + ACPI_NAME_SIZE)) > #endif > =20 > /* --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:46:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:46:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428019.1650726 (Exim 4.92) (envelope-from ) id 1x8pa6-0008Vl-T3; Tue, 22 Sep 2026 01:46:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428019.1650726; Tue, 22 Sep 2026 01:46:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pa6-0008Ve-QI; Tue, 22 Sep 2026 01:46:02 +0000 Received: by outflank-mailman (input) for mailman id 1428019; Tue, 22 Sep 2026 01:46:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pa5-0008VY-Db for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:46:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pa4-00E4mF-GM for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:46:00 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1ddd8-8faa-0a2a0a5109dd-0a2a4503c75c-0 for ; Tue, 22 Sep 2026 03:46:00 +0200 Received: from [40.107.130.128] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1ddd7-fae8-0a2a45030019-286b8280da70-3 for ; Tue, 22 Sep 2026 03:46:00 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by GVUPR03MB11257.eurprd03.prod.outlook.com (2603:10a6:150:33e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 01:45:54 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 01:45:54 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h8A+e2xOEXN2W+H7ieUZzy+qMwjBNidLC4hbYn8pCcoOVUaXnBdOoll6L6gpDC8bcCzwlmVhSa3w9nfRsAbZrG1DZ2oQWwvpz3j4MCU6s1lIx/pytwuSsUhEaHxlpMM4kLNxQhHEoWQ4R5QXiJ3j3Vt5B7GQ4LhQGnDYODtSign+m2NZ0+2+yod4GJWTcoBOM+frSUVjR2F2y7dSy9VOEWucRiV4RnWsUA/Mybq2XKIjbjTU4VGt6t3oCtLhf68Nk/oNwzOuP2ktBa9+gC/1629qk9bBr6R+o+XauyOGx1USV7rLcCIO0YVjFIxbcSlJ5kHXo61G4mxpjSQ0JypOxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MPkawwD+HSAfDUsETDFv9ZVFdYkVi5OEd0ksNR02mWk=; b=N8AthuQrVBT1NiQ/Gj35VNIKB9orsZQMEdTnm2894ZMl1ooTb5/rmMyzUVAyvpTJRriYUnBL4fquSpXzA5u5lK9KKwdhdkkJErmkFT4lWShuFHMqIqyjWULxtZWvn8MSRw96wVlzjkup5ChbkEuclSjc0G6t+66+UMLiX/jlMHrQat0EyEKxKwnwNopU5lA+Yx0WQK1X5zKTL5ENfnMYR78ITG5r+Fd6Ok79Jet+nZAM270FnXIyKO8N0nZ31i+VyHN94Up6CrlF2bRitkFxzUkjzpmcZv+ATbiQR+aoyj/IUP+vWFpNkn7OZQqTnPPAZ+zClven2fMYwbAeymgzKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MPkawwD+HSAfDUsETDFv9ZVFdYkVi5OEd0ksNR02mWk=; b=cVsFBxIchGZhhCZE5PWegA9s+/p2BSAmmi9ApLe9HZ32/E63UEZb3JaR9I28UzjKi9HfRZ7NgcPXh9ewJ48hc5AlM6yrqijhJlKw9Z3qORN1S1frw8SlFyNpCXObPFe5Fe/20+GmZnOJwjqUSXHqOINhv1nOkOF8z7R1it0MWx+aCsGaRitakxCO7KYBMdrH8dwLdz8VzUy5zaeweZ3LDcsVNOOe+EnlY306hR8LxrvQNC/7QCOuGT0xA5u2nG9dEkE0xadxPHowTsvJvHPuysewO3tqKBNNIm7F9mCOfPooVqFk2YdthSUxmjICCAHNYa4DDqkz0mp2EatyfFHn4Q== From: Volodymyr Babchuk To: Jan Beulich CC: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH 10/14] ELF/notes: use pointer-to-const by default in ELFNOTE_...() Thread-Topic: [PATCH 10/14] ELF/notes: use pointer-to-const by default in ELFNOTE_...() Thread-Index: AQHdOqU2Vkz5DOI+4USs/ahFyLHJfA== Date: Tue, 22 Sep 2026 01:45:54 +0000 Message-ID: <87fqz26otq.fsf@epam.com> References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <8fe86787-7590-44f1-be4f-461b61d7669b@suse.com> In-Reply-To: <8fe86787-7590-44f1-be4f-461b61d7669b@suse.com> (Jan Beulich's message of "Wed, 2 Sep 2026 08:34:45 +0200") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|GVUPR03MB11257:EE_ x-ms-office365-filtering-correlation-id: 9b77da91-7d4c-4af6-d097-08df184b3db0 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|42112799006|366016|23010399003|376014|38070700021|3023799007|10067099003|11063799006|56012099006|4143699003|22082099003|18002099003; x-microsoft-antispam-message-info: TXV5p8Oesz44ojly5+kpcoxvWYB8yx06JiT/rRQpFOB/Qmis0xlSZtd1nZHfETOmfL4lvydyWERuh6L2Ua1GCwyzuOvGcTJqMRBXU/ciNAnrT5cMMeyhDpNe5LHRjPSHjgLeUK1CyEEC/pSRWfY8qmnHz5xLEYnPTsnhYY58YdXdwTO+7b2xLD7Yv5AcdPypMYyOB4A4DqbrgfL5b2ZJPiihQbaCD3N/5Yl7kHvh5QvMPHeiwfCvZu4Z8lKU7GnKHj2AhjiAIYGaTMQB+0YUNBvJ5Xj2lQEEe05bul1HYfRdLa6ZeOp9Pna3vy40HMG8/wDvkrxVCc4hPmQj37i7sj3IGRV+2ysu+CZYAg2zbrZTtbJ2maooNxsLiJQnbGGLUa81bujjYQYKO7/fxoUsmACvz/aKSw2A2gNHjxT3TUk8ruwtiZ2xIfRC9WggpK6Jah1YHoDfhhASojIGx1XzIWBn5rDNeoS5mM6nvHv0aK6Bi+4O7pbwgEkmKMyfhl1gnliFAGKkvT96qnB4HihKMywKCwYmm1Vds7kjMfki42AllcEwUVisM/egA2hzR5CwQowEJbf3UZBj6syHBAoAVLZiejby0DS5gHxdbzbJ824Kw+icHrt03QJbVdsNWeGdGCuC/XV3sDYXEwNsrUSNC2b79dmtzw59nRHol6x+YHpLaaDiAiQ5X+8fEPMdrVCSmtKQOgYgL8eIdIPlKG7cYY9xAOZR0SI6nx+qTYyiYpk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(42112799006)(366016)(23010399003)(376014)(38070700021)(3023799007)(10067099003)(11063799006)(56012099006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?0Suwsx7MBBP1cAiDdT49sua9Q7eN6T4PZW2FTP5jO3z3dco6NdCkc/UIiH?= =?iso-8859-1?Q?LFOxDJjajnT33JVBvJ6jMcxGS1YbIOZLIMD2UBnJxlXl+dsc/3w6D/3Jqz?= =?iso-8859-1?Q?wL2Bg9sCN5sQ250KN7Qu96QNgmCbHxG99lE0ymZBmE/6A7guQGzEH2GK4v?= =?iso-8859-1?Q?Zg1dRg/2za59v6HOwrjPM8jBXooMyQhibAzTorzZnWkdWMklAQ455L/Q8n?= =?iso-8859-1?Q?aPuTR7ZLMK1XlASfeJuzhgexRJU8AInG/pq16d/HyTrojPCS0c1jxA0pPF?= =?iso-8859-1?Q?NAfRG/u2uvEuYMeFzFYFj5oH/T/5cPdV4FqKWBG8f/8Ub81gN0KCPY+I7/?= =?iso-8859-1?Q?X25wQC2hK7U3IXj9QCzroMDQnB52iuH1Nu6qTTwoYlt5ZXr9KU5Sc+VNfu?= =?iso-8859-1?Q?qX+o1A1rw/JeEu2dqjQ+mD3xIXRSMRrtV0TBLI7hVtDezdwM/sHiq78J1T?= =?iso-8859-1?Q?kSlS6CqIGl6tEzZ7yrLWeZZSPGDRA7Y6LYtJyj9begSXaZ2ZnDnvRipnfZ?= =?iso-8859-1?Q?Xc25GqgZ1Ve/HXj4YsneyfwJPY+YhSBcGDn8VUXh2lRRbY733k2cPUkY+g?= =?iso-8859-1?Q?6fXwIwkIH3cD6GeqbmBNGuVxvN87JgHxkwWso9Nhi/FIPTjrqHl/eWpMcj?= =?iso-8859-1?Q?7HaXi3xKDPdC0SYbmUHboP+Xr9S1I2bZtpN7ADVPxTD5UhmPZlijGzVaYn?= =?iso-8859-1?Q?5A/LtATYkpEC5lOe8s5ruJbr5TdjgPLVyLw5hhau5W8hG544N+7HgkwwWF?= =?iso-8859-1?Q?JDljYNFVtXRVNkbwDj/0tc6gBD7Ir0J2St7eJKpoFodwuaoC8FuLEKQd1P?= =?iso-8859-1?Q?gkzO6oYrPdnFrh2/abQwWPFvbODd+LtBNkLx5cpYDv/EwpsHKFR46xSNB/?= =?iso-8859-1?Q?hrK7lJEbc0yLe0sd+e5Vq1XEca6RUh8ochvCl2VlyCttyinfMaa+gW3DL3?= =?iso-8859-1?Q?kIWpd06leNm+t544qmyhtWcgIIFt94fCkMqZDs+wxV84ANc+6KUAzfSMAt?= =?iso-8859-1?Q?XefTXIRKiuiy+eMCw6gZJzUa24khct8rCngXlwDxk7u55HQTEHp15+GlVC?= =?iso-8859-1?Q?aX4WzDjkxcPCLwkKJNg/Hx7W51gXfGy3+TyChKK0iyn4aujmtw63ZY0hhi?= =?iso-8859-1?Q?CB6PsBTwUJpOolBfHOv/iSmkzAFEmZw/aaVGVbFCcZHzA7F4OoapHlHnqj?= =?iso-8859-1?Q?feMEqVyKiYWsztxYicnCHujZQwoj2fmihheMBsbzDL01SMuNgY7AeQtVm4?= =?iso-8859-1?Q?kEGCdTPvidPF3Jqm0L7Fy5JZsFs833gpBJ3LRZWu1vk4hk7RvuLH7hPG5W?= =?iso-8859-1?Q?Kw8m2al1+tJsPsMJCpPjnqUmyURk5I2JoaNxYndwj3ncuBWxnN2GYiQwtk?= =?iso-8859-1?Q?ftJPeUw4ASAFadW57NMb7cOKbjKilpVq3nLICiLQskv7GA/Mp2WOo6MxWx?= =?iso-8859-1?Q?BYBTs+IhCwF0HuID7yE03LN79OLbfthE7GWHlIMRczqiEd5JmHAsXf4nq5?= =?iso-8859-1?Q?XQbnf+VvjghspUftfy8RlPFTL0IWQ2jetJ80TDPkmyNlxkFM4P6PEWfdt3?= =?iso-8859-1?Q?e9fSjImcgnUmAs0aR1bxKuk0HA9vT27J6hktxhm27dgyL4aOpJD8/H4YBr?= =?iso-8859-1?Q?qiCAnt1IXWXDV2yqlyEp8MNHGAGY3WUjhdrKqgSg322Dc+uLXTMPl2MlBP?= =?iso-8859-1?Q?CWuEXXXaaRSBH5uJVyOcAIP3IQ2Tjbq8bI0A/k9vXTYL0iDFYw82cRIHiH?= =?iso-8859-1?Q?ppXyPRbu0+obwxuXS+VI9uDa23PwlPythRZlBrDey4atgo7AuImfEk7jvT?= =?iso-8859-1?Q?1pRIDOgnyMDXnxt3Tn4vkUfeZ9TegZk=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9b77da91-7d4c-4af6-d097-08df184b3db0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 01:45:54.6019 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JKRWKgYXX8KlVzUNdoryT7fL1Nu5wAVMutV7MM57bL7HcxwWFdFS6uIFSj30y8e4GCAOd+3etebUZ0jnDWOJDjXDHcGrDCoP8a8PS7qemRQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11257 X-purgate-ID: tlsNG-33051d/1790041560-764FC4E9-FF04FAB5/0/0 X-purgate-type: clean X-purgate-size: 1792 Hi Jan, Jan Beulich writes: > Not doing so results in a number of Misra rule 11.8 (casting away of > const-ness) violations. We need to allow kexec to use pointer to non- > const though, so provide a means to override the default. > > For ELFNOTE_NEXT() we can do better and simply re-apply the type of the > incoming pointer. > > Signed-off-by: Jan Beulich > > --- a/xen/common/kexec.c > +++ b/xen/common/kexec.c > @@ -6,6 +6,9 @@ > * - Magnus Damm > */ > =20 > +/* We're producing ELF notes here. */ > +#define ELFNOTE_CONST Frankly, it feels backwards. When reading this line of code I am assuming that you are adding constness to ELF notes because you are defining ELFNOTE_CONST. And I had to check the elf.h to understand that you are doing exactly opposite. I am pretty sure that other people will confused by this as well. > + > #include > #include > #include > --- a/xen/include/xen/elf.h > +++ b/xen/include/xen/elf.h > @@ -29,9 +29,14 @@ > =20 > #include > =20 > +#ifndef ELFNOTE_CONST > +#define ELFNOTE_CONST const > +#endif > + > #define ELFNOTE_ALIGN(_n_) (((_n_)+3)&~3) > -#define ELFNOTE_NAME(_n_) ((char*)(_n_) + sizeof(*(_n_))) > +#define ELFNOTE_NAME(_n_) ((ELFNOTE_CONST char *)(_n_) + sizeof(*(_n_))) > #define ELFNOTE_DESC(_n_) (ELFNOTE_NAME(_n_) + ELFNOTE_ALIGN((_n_)->name= sz)) > -#define ELFNOTE_NEXT(_n_) ((Elf_Note *)(ELFNOTE_DESC(_n_) + ELFNOTE_ALIG= N((_n_)->descsz))) > +#define ELFNOTE_NEXT(_n_) ((typeof(_n_))(ELFNOTE_DESC(_n_) + \ > + ELFNOTE_ALIGN((_n_)->descsz))) > =20 > #endif /* __XEN_ELF_H__ */ --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 01:47:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 01:47:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428026.1650736 (Exim 4.92) (envelope-from ) id 1x8pbS-0000b8-B9; Tue, 22 Sep 2026 01:47:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428026.1650736; Tue, 22 Sep 2026 01:47:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pbS-0000b1-7n; Tue, 22 Sep 2026 01:47:26 +0000 Received: by outflank-mailman (input) for mailman id 1428026; Tue, 22 Sep 2026 01:47:24 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8pbQ-0000av-8l for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 01:47:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8pbP-00E4rP-M2 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:47:23 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1de25-8faa-0a2a0a5109dd-0a2a450cbbc4-4 for ; Tue, 22 Sep 2026 03:47:23 +0200 Received: from [52.101.65.105] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1de2b-f479-0a2a450c0019-3465416981af-3 for ; Tue, 22 Sep 2026 03:47:23 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by GVUPR03MB11257.eurprd03.prod.outlook.com (2603:10a6:150:33e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 01:47:21 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 01:47:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CcqhSefTJ8UTG5UEu4NrlEHR/1RPImnioC3u1El6JsiYk2hCsgALmn3yfIeu6sXSykj9R4PEnXo8reRRqsAf7fk+fnehLeKN7g5cvKnLuZeZoO9UJWqxbSnAlA1sxwiF43uEb9OAI5sOzfSftz/gWsDc4KHrVvzwE161xZnZ2u0s47Rm5oAhOWGVQAhZ6t6H410fdzGOxfmor4gmYf8vyo8I+0JtdaZ4J30Nrdl/hL5m4cQHqon5O1Ve0xfqIto0KslNUpibPsR+Xj2x08nWPREqCTvZLo/fdpoQG6rguTn4PzipZyp8RmoMyLnccqjbEWt+FGwaTlstf/jn46pzsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ABjxkqnr7LrSZ7UP9i5GI6jpB4IZ0Q931uLfva6gBHU=; b=y95KIFS5i9f1kzH0Y0mNkl1nLU+6h6YnNxiUHgpMLxcW+YAh0XDfQZplV6AacKMaqzPLCqCIRKLvEptX3rX8ls9go0P4jmJv7LX1hfPoG6U/5SJ09cG17LyNmeujia0SV03ZuqBrQDDxZ1Dk8HcZBcK2MjyzYMjdcDDY0cIlhLlzExCM1T0vPwYgFG8oMhULkGa2bfpjrPzmWeI0rJDndIqJryUtLa7GoUjSLfB517JnnF8y2jRheDgkd2qzatjynfiSJShAEUfLMcoKFV4cI/UD+PFT/Y1hB8pSWYz0HV76R7gRsw8Xjw7/sgtyy9E9+Gar51UqxcGJMCX06ZpFXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ABjxkqnr7LrSZ7UP9i5GI6jpB4IZ0Q931uLfva6gBHU=; b=PQ2hEfAhW5TLB6cTBA9e87LpOUgKRD8o0qXhY7oN0RjcRxQ7+jxIPyuxtYNd/uJ1o5feJycQ4ACyeTy2+LmEN6iA03MFxOZO6sdIckvj1YFFhWP07w1c/x2/ObFrY2oelaS2vp+CZG9UN/74mshuZ4i7JlrfLXCH2rSC0FDZFoH3scr3qjbtTcIxZDnFz1ud/GaaT4OZEglvjkWvdSjE6xVKxdoXMf1CV0AFdvuap798alLYatBNgfnazR1t/FLCxXvQjJhKM4T0R29cljIM960P+wJKOuHQH3A5xSZtpQD9UKz/xgyIG8NEBDHoxrsCpZ8a2F2b2xtvB/PD/WDpbA== From: Volodymyr Babchuk To: Jan Beulich CC: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH 11/14] crypto/vmac: don't cast away const-ness in aes_key_setup() Thread-Topic: [PATCH 11/14] crypto/vmac: don't cast away const-ness in aes_key_setup() Thread-Index: AQHdOqU/WljR8KEAWECIzLfq3OQ1uQ== Date: Tue, 22 Sep 2026 01:47:21 +0000 Message-ID: <877bke6orb.fsf@epam.com> References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <1faace7c-2425-4691-b23b-3ffe033e5bc2@suse.com> In-Reply-To: <1faace7c-2425-4691-b23b-3ffe033e5bc2@suse.com> (Jan Beulich's message of "Wed, 2 Sep 2026 08:35:10 +0200") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|GVUPR03MB11257:EE_ x-ms-office365-filtering-correlation-id: 2815586a-16b1-4982-bbf7-08df184b7173 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|42112799006|366016|23010399003|376014|38070700021|10067099003|11063799006|56012099006|4143699003|22082099003|18002099003; x-microsoft-antispam-message-info: sVy5WZXdI+E9YvfF8sVqrP+oCixKGLgt7YT/uyM8lujJh3wP+5J3oH5jpTE+FM1x7fP72hZBTNOgM+D9DuSXRF92U2P0jBr/VV3jIVOaK3P6njmuiHaBBYGsTEhEVPUjCTPrf3ByfQTc2K1bWdSHFUiUXlqol4BjvBRPQvmP/M7cUSRFU+ELvpJkFEDAx5H21EXBBl6ihRVcfGuEixtbLRPPpxJFhKuHth5RRvykX0Ho5ibKJefFgJKkuX1LR73yY/uejQn8IxUMu4rgbzRYI3b2q2tX55dySukEo6h/9QE9sxpqewmrNoNxndelK5BKw3qyHPVqgjv8ONY4jEmnAzaMO1rabK5RqVhgKUNUVC2DZWuqwMR8ATCPMqpZr9ehg0uMJlTBqxXIk+DSlVYez1VSSQN/m3Bc+Opl0D/sYp4kYS9rGE5jJF37yTAeT59eBmVE6l4dB837gLQxBey40GHbVmvHGX1dS3l/KXP5THZHgZMCV2Ma3wwTuNbG4osFOo1GQXw3yZgFJfJCjOJz5QcPuq+KFmoLZw5jedUse4w90Bb4bhJemM6K73wZYv0fPLNvoAs8rNkwVFpC3A8vLM5nR3Yr5pGvlUU/ajL+NMH8qSHHZcU51ISUcJE4jIjGwSZyc/YVmfLRcDFILnQhObUJx/7r8ujAESw9OqhAGYcUB1nAfcjh2/6HK5tVw2C6zceKj9fa9deLoQGH0lxjJaDZkNiDJofeMsVOFWdtfMU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(42112799006)(366016)(23010399003)(376014)(38070700021)(10067099003)(11063799006)(56012099006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?fC5ylRB8RPjezt2J8c2kV+k0qnjbTT0yB8mJyjAsxldGbAyBoHnQqjv/Co?= =?iso-8859-1?Q?uTNS63/o5LnYSvyUm0XDKlnJ4CE8/rFRgYL02efS6fhyZcLygVg8GmYnxN?= =?iso-8859-1?Q?jXIu3v17gID2Q1gVhtEfkR1ahZUJ8vnQvXWn+87LikdY37O1NG7t/dTJq2?= =?iso-8859-1?Q?NZY6ZYz/ExecR9rCZbe03frNHrE1WOGEvMgss4jK6nxhq13Z2kFHqS1DLo?= =?iso-8859-1?Q?bMuLD7Md1vwGHapkK+Qa+lNjXrFmltMrsXUj5RvoOfq220en1b3L+t04S3?= =?iso-8859-1?Q?wrRW90UJoD5l7UykvirkD4k8XESUFBk/09XjD7RUCA0hb4ZiK4PGFsrxcU?= =?iso-8859-1?Q?W7j6NYBaoa4aY17m/EZBo5d+svuxe+aX+9IzNBF14zD1uNtF7ZQQn9M5g0?= =?iso-8859-1?Q?NE+eB1wItz7ql7eWnfaYifF5pkDufIWOJtFIgyvKHxtG/ncwF1SL8XI5VC?= =?iso-8859-1?Q?snZt+Cqw7uSqBB9C0mRATRXO5RR8jQ1veypbLGKO/ZHmjNq53NenPf2obo?= =?iso-8859-1?Q?CyI/rylScc96r8GcFbpL7M4pTb2ulmCvO2mrEgqqSXVc0dAPp8wUGcVAZc?= =?iso-8859-1?Q?gKBJuNJVXcKI/uL28x8Jce2MYiHuNn45c0SCYz5fA7du66iaEPiThjFWcS?= =?iso-8859-1?Q?WUzQzIlI+E3ukCgLc+uYxorIrrSRdcwDLkbzy0NN7wNyjUMWi3vpFJXqps?= =?iso-8859-1?Q?qHsrqyo0iA4428u71cJphaVoXWV6W6xFbu2n34ZkLyCp75l9w1GWSpIZm4?= =?iso-8859-1?Q?aaoS2xV+s1ncpE8fI3KEGvKzG+OVPQfvNxq1ASdS1fjZVNjQIZv6eFmaKw?= =?iso-8859-1?Q?hfSEsOzS4hxjf11ASjoolFGkYh/q/UO6ztZmknpoTdC/w7yyHtRjd9HdGL?= =?iso-8859-1?Q?yoBb6yup7KdGy7D4ewlc+g5btVYm6TPszqTtmZn1df6PXH90hakRUYx7eq?= =?iso-8859-1?Q?v4APiMkg/w13p3lRw9CiR3UinVHkpyGoeEEXSqDqTRaKqpdCTqW74kgDIs?= =?iso-8859-1?Q?PFavoFf0KtkWJ7glLQa0nX+244e+mZ77IAZHrIbtj4zc8SmstbvQ6vKQID?= =?iso-8859-1?Q?m0ErrIIFy6ButmFVXtFJt3PIalpqgYDe6aQqhoa9gby+RArKDfW+RZkTd5?= =?iso-8859-1?Q?s6UvAq6ta7dwWv8PcS9gudk2wlXgmncF4L3axVQNXxHi303wMK0RNoBw6u?= =?iso-8859-1?Q?7KGxwr6Lfzv0h4tomAiaanl4HFBXM8VK/hXAkY97Cc9qqfRvAVmb0Oh21v?= =?iso-8859-1?Q?Tnj/NZwyTHBjNHiBfLeWhZVsJP9ahydZQ9hiURxKSSnI055/+cAHsXeJaX?= =?iso-8859-1?Q?IgLW6i8mqCIHxqlzC1b3mrPNNfCIuDy8bcEdC7rL+W6xJOb+OECh5/HH7g?= =?iso-8859-1?Q?SCSfJGRrB+wgqU1DbV70OdHIVMHNZoehZPIwBapEwC+pt1Fbk+PrDU0zgp?= =?iso-8859-1?Q?TH2bQE95AXF7w3Cm7PbVH/SBE/8Qt1Eq+zaxuwduwF4k+zaGk30ED+FogB?= =?iso-8859-1?Q?Zea9JtMWlZKm/EiFZ4XPeU0Eq1emEArpAjVVKKFfohuso1IpAy0W+aQY63?= =?iso-8859-1?Q?IGOTp34yDewERllkaNgkgSZrLWHfd/Z+gWprAD5IpIfHYh/Q8zWgc+Tbe+?= =?iso-8859-1?Q?0/VqRLOuLzehNw6NcppmOaI8Jf0gA9RzZXbaDRydmwYZP6J8MuLYnujIuz?= =?iso-8859-1?Q?7T3GqORjcK4NJJKolY+f/K2VCvJvqKM/iQ0KdC5bRZuzHfCkIx2dmX/n5c?= =?iso-8859-1?Q?2DCTBJRiaSP38smmgW6iSHUs+Px8u1tdSmheo/5nWK7uvdSbpDEs21fhzQ?= =?iso-8859-1?Q?7rFP+ZKA+0j52zULIS6wlhhYFkrto1w=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2815586a-16b1-4982-bbf7-08df184b7173 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 01:47:21.4437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CKgyutQK11O26aMrcPTCw+Lbf1Npjm34+j5mn+S1zwl1sNIISa0ZszkjLNS+rGW9TRj4GuJ+a+VyA2Efjm6HsS9cmLIC4yaUF8gvl5j7LcU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVUPR03MB11257 X-purgate-ID: tlsNG-d25034/1790041643-76ADCA5B-A40C5CBC/0/0 X-purgate-type: clean X-purgate-size: 928 Jan Beulich writes: > vmac_set_key() passes in a pointer-to-const, which has const-ness removed > despite rijndaelKeySetupEnc() properly taking pointer-to-const. > > No functional change. > > Signed-off-by: Jan Beulich Reviewed-by: Volodymyr Babchuk > --- > I was wondering whether I shouldn't adjust the adjacent aes_encryption() > right away as well. > > --- a/xen/include/crypto/vmac.h > +++ b/xen/include/crypto/vmac.h > @@ -69,7 +69,7 @@ typedef u32 aes_int_key[4*(VMAC_KEY_LEN/ > (u8 *)(in), (u8 *)(out)) > #define aes_key_setup(user_key,int_key) \ > rijndaelKeySetupEnc((u32 *)(int_key), \ > - (u8 *)(user_key), \ > + (const u8 *)(user_key), \ > VMAC_KEY_LEN) > #endif > =20 --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 02:17:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 02:17:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428035.1650744 (Exim 4.92) (envelope-from ) id 1x8q4g-0005YS-J7; Tue, 22 Sep 2026 02:17:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428035.1650744; Tue, 22 Sep 2026 02:17:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8q4g-0005YL-GC; Tue, 22 Sep 2026 02:17:38 +0000 Received: by outflank-mailman (input) for mailman id 1428035; Tue, 22 Sep 2026 02:17:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8q4e-0005YD-Ml for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 02:17:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8q4d-001AWr-3D for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 04:17:35 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1e4b5-bab6-0a2a0a5309dd-0a2a4502d680-48 for ; Tue, 22 Sep 2026 04:17:34 +0200 Received: from [74.125.230.235] (helo=mail-qk2-f43.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1e53d-6ca4-0a2a45020019-4a7de6eb8efd-3 for ; Tue, 22 Sep 2026 04:17:34 +0200 Received: by mail-qk2-f43.google.com with SMTP id af79cd13be357-939109fafd6so299779185a.3 for ; Mon, 21 Sep 2026 19:17:34 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.250]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93c1d03b89bsm20446685a.9.2026.09.21.19.17.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 19:17:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Date:Subject:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1790043453; x=1790648253; darn=lists.xenproject.org; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=7yngsc33kpqZ/ZfiC2TEEvVYs9QbDT9O0cYlk8EaRyg=; b=pzaGdN74l8thAnrm2NR6Wr/uJyKV1PLfTx/+ZLgGUkv42SJNR9x5A8jR5fCSsm8VPR 2UzdjWhC7NE/z3b6TbXhYeLKLvvQBZA/h2iwgtavKE7KckbkZihPv0t/VCRHLm/dKglT 6Fuark7p19/vvjWJyYdDDc1teaR12/RkJwY/+L8l9iT90E2qzeOkMQ2lHgEtQpR/jH3G MtTqb/ThUe7RHYkO1JN+50sz6rSqTDW479szkTEI2rA0+y5rImr3sFlXvJ/9zL9qu9T0 SUrn/cG8PF0GF+sPIm7Z892SkilVzC5m30RED62flX2bA2P3RfXMrVGdeut4crj8PVHa R4Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790043453; x=1790648253; h=cc:to:content-transfer-encoding:content-type:mime-version :message-id:date:subject:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=7yngsc33kpqZ/ZfiC2TEEvVYs9QbDT9O0cYlk8EaRyg=; b=NnD0myaNjrvkvGASfD4ErmKOZngXN2K6+9rUqxx750bI5fqk+fSODOHuDylyJU+w8I WkArHazdPAnrL1r8TyW5IK3pIJw0Igaww+cU32P6o4RET+s55Caoj186jM+yIlaNIsPN fsQdBAJNFnY5nFZhOvarWONS6j3sqXY5vImuNzqb9esNcuyB+lPlMXUW83KxXRJ9UeOd Ihtbgzsy8WRjD9Xo5YnJ/16zKAyXNiVF5ai92ds/7NPyS4pSLpJmr7Bbp6m66mw32jbi tAY7IhpwVYb9BuVcUXhqSxzGOZLPEdX2zCJp07p9PkqeDkKxBQ0DU3141c3jOA27rb/V rexA== X-Forwarded-Encrypted: i=1; AKwUvBw/hOjI+VDrjuPKV2Ulgy8II/FS3xqS8idjg8gCsdO0yS7hXIEUAWgTgJyQhwWFhWVHFsdTBwYahMg=@lists.xenproject.org X-Gm-Message-State: AFuF++mtCVpipHcJePid6KUghFFb/hNoe2zxUvR0ZQfmoOVEG546V4qD yoNBnCyIaDIPhSUliDZkxwDoBcfo3B83jUQC/PtcYvHUyolq/2yx4kBvEWbu4QkMdIw= X-Gm-Gg: AYBFou2b22gehUfsHs3n0/TDQR0934bVaP6V6LmTbrfn+vPsnMxsFHxf3S3RgM73et8 wx1lCGDE1/7OfiQNh+U6ODluQDYOvE3aBXmWBLQhvQ6LBBJIF+jrmuxhNpM7lcv4NbA0CKA3wSN Rn+t9uia9mXTZuziqMA1GC6ZeQX13Ts8psBEtKVLycjR+H5DcNvw+tJQpMiHX1WefI37gHUDPbi 9CI2U3SeUVsWvUIG/i83asVcJoTpLtKBEpcuVYjKyOAJOcC/PX4e/lHBE2QqOVA8nzBKEIdDPnS DKEv1rKitLauQttUIsGhIRP1NutRP++diC0yDJ/b4PQ9yCk0KSQ+mZcjnbenNzJPMchSAitgvzi KMDptY2oGCwcq7h7G7iVU3p321jp6DRpnvQtpTInB5BYEui004ZFdKe8MIGy1tIQUrMoIg/x5Az WAdfmokNvY4yP2WJjI04IICd2BmbWIitWYeDfHw5m8lJzhmqk2fjWD2cSfg8CqgrjWtxl5k9vk4 qwyVbHLI70HRbg= X-Received: by 2002:a05:620a:404b:b0:939:f188:6d97 with SMTP id af79cd13be357-93c15e4935fmr353334985a.48.1790043452487; Mon, 21 Sep 2026 19:17:32 -0700 (PDT) From: Josef Bacik Subject: [PATCH v5 00/13] rcu-tasks: build Tasks RCU on Tasks Trace readers in trampolines Date: Tue, 22 Sep 2026 02:16:36 +0000 Message-Id: <20260922-b4-rcu-tasks-preempt-qs-v5-0-feaf7a32168c@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAAblsWoC/4XPwU6EMBAG4FfZ9GzdFqZd8eR7GA/DdJDqLmDLk jUb3t0WLyRCPP7Tzte/dxE5eI7i+XAXgScffd+lYB4Oglrs3ll6l7IoVGFVpZWsQQa6yhHjZ5R DYL4Mo/yKEpRuGjBgDZ1E2k5Hjb8t8uvbb47X+oNpzFy+UWNkWQfsqM2j83Cs4bgMtx7IG62PY x++l7KTzvL/vSYtlXQAtmqASCv9MvY3TwN2Dh+pv4hcbirWmN7HioQxIlrNrnAIm1i5xsw+ViZ MoSsVARnm0yYGa+xpH4OE2bJRXDlbWfv3m/M8/wCHDGV77gEAAA== X-Change-ID: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1790043414; l=12509; i=josef@toxicpanda.com; h=from:subject:message-id; bh=Lun0LDlv1NRasQcxE3cO2Jn1N9Nm2f7VrQlujNHSP0s=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QCy+K/VPDPjFXXQoMumAgwGrCCnuSOd34VYBogHqbuvsVSYgEOGOHk+6J4iv/lyG08jRDdsEHRU 11xeh2HoKIQU= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-720697/1790043454-F2EB32AC-ECBADEC0/0/0 X-purgate-type: clean X-purgate-size: 12511 v1: https://lore.kernel.org/all/20260910-b4-rcu-tasks-preempt-qs-v1-0-d4469f4cc101@toxicpanda.com/ v2: https://lore.kernel.org/all/20260911-b4-rcu-tasks-preempt-qs-v2-0-eaaa61ed2da4@toxicpanda.com/ v3: https://lore.kernel.org/all/20260915-b4-rcu-tasks-preempt-qs-v3-0-0ad30c4c5ee7@toxicpanda.com/ v4: https://lore.kernel.org/all/20260918-b4-rcu-tasks-preempt-qs-v4-0-63f0e9d69661@toxicpanda.com/ v4->v5: - Dropped the RFC tag. - JIT emitters: *_off naming and offsetof() for the srcu_ctr counters instead of hardcoded 0/8 (Alexei); note the open-coded copies at rcu_read_lock_trace(). v3->v4: - BPF: the reader is emitted by the x86-64/arm64 JIT around the fentry/fmod_ret and fexit regions instead of taken in the C glue (Alexei). - An idle CPU only counts as quiescent while in an RCU EQS (Sashiko). - Dropped the rcu_read_lock_trace() lockdep/inline patch; BPF CI bot nits. v2->v3: - Reworked per Alexei and Paul: trampolines take rcu_read_lock_trace(), and Tasks RCU on x86-64/arm64 becomes a per-CPU pass plus a Tasks Trace grace period instead of a new per-task counter. v1->v2: - Sashiko/AI review fixes, Paul's and Steve's comments (see v2 changelog). What it does now: Every trampoline whose lifetime Tasks RCU guards (ftrace_caller and its copies, the optprobe template, BPF trampolines, out-of-line direct-call trampolines) takes rcu_read_lock_trace() around its call-out, open-coded in asm / by the JIT. That leaves the few trampoline instructions outside the reader, the static ftrace stubs and x86 return thunks that carry a trampoline address, and the kprobe jump-optimization window. A task can only linger in those by being interrupted there, so on x86-64 and arm64 the Tasks RCU grace period becomes: wait for every CPU to pass through __schedule() or sit in an EQS (the irq-exit preemption checks the interrupted IP first and briefly makes a task caught in such text a holdout), then synchronize_rcu_tasks_trace(), then one more pass for the trailing instructions. It runs from the existing rcu_tasks kthread, so call_rcu_tasks() and friends keep their names and callers; there is no task-list scan and no dependence on voluntary context switches, and cond_resched_tasks_rcu_qs() becomes unnecessary there. Other architectures keep the classic implementation. Testing is still QEMU: x86-64 PREEMPT_LAZY (PREEMPT_RCU=n) and PREEMPT_DYNAMIC, PROVE_RCU, lockdep. synchronize_rcu_tasks() against a 30s in-kernel spinner is 20-70ms (classic: 29.7s), ftrace instance teardown ~0.2s, optprobe register+unregister ~0.6s, the direct samples cycle in about a second, and fentry+fexit attach/hammer/detach on do_sys_openat2 and hrtimer_interrupt runs and detaches in 50-100ms with the return-to-user reader assertion quiet. arm64 is build-tested; hardware numbers for both are still owed. Notes: - This is the alternate-gp_func-on-the-rcu_tasks-kthread form; folding the IP check into core RCU along the lines Frederic sketched is left as the follow-on Paul suggested. - The open-coded reader is ~9 instructions each side in ftrace_caller and at four points in the BPF trampoline. rcu_read_lock_tasks_trace() would be shorter but needs a slot for the cookie; also a possible follow-on. - CONFIG_TASKS_TRACE_RCU_NO_MB depends on RCU_EXPERT, so non-expert x86/arm64 builds get the smp_mb() in the reader despite ARCH_WANTS_NO_INSTR; the asm follows the C here. --- Original email (v1) --- Tasks RCU only treats a voluntary context switch, usermode or idle as a quiescent state, because a preempted task may be sitting in a trampoline that is about to be freed. That was a fine trade when PREEMPT_NONE servers compiled Tasks RCU away and PREEMPT desktops rarely ran long-lived in-kernel loops. PREEMPT_LAZY changes both halves at once: Tasks RCU is now real on server configs, and cond_resched() is a no-op, so a CPU-bound kthread or kworker only ever loses the CPU by being preempted, which is exactly the event Tasks RCU refuses to count. The way this showed up for us was a cgroup writeback worker draining a very large cgwb for around eleven minutes on an arm64 box. Nothing wrong with that on its own, but a BPF program detach on another CPU went bpf_trampoline_update() -> ftrace_shutdown() -> synchronize_rcu_tasks() while holding trampoline_mutex, forty-odd tasks piled up behind the mutex, and the hung task detector panicked the machine. The kprobe jump optimizer is worse in principle: it does synchronize_rcu_tasks() under kprobe_mutex, text_mutex and cpus_read_lock(), so one long-running kthread can stall static key updates and CPU hotplug for its whole run. The current answer is to find each such loop and add cond_resched_tasks_rcu_qs() to it, which is the kind of annotation PREEMPT_LAZY was supposed to let us stop writing. This series tries the other direction: have the trampolines say when a task is inside them, so that a preemption anywhere else can be a quiescent state. - task_struct grows an int, rcu_tramp_nesting. Every trampoline whose lifetime Tasks RCU guards increments it before calling out and decrements it before returning: ftrace_caller and its dynamic copies, the BPF trampoline (which drops it again around the call to the original function, since im->pcref covers that), the x86 optprobe template, and out-of-line register_ftrace_direct() trampolines. Only current writes it and nested users are balanced, so it is a plain non-atomic inc/dec, one load of current plus one RMW per entry/exit. - The inc/dec are inside the trampoline, so there is a window of a few instructions on each side where the count is zero but the task is in (or on its way into) trampoline text. Nothing there can be preempted synchronously, only from an interrupt, so the irq-exit preemption path looks at regs->ip and holds the count across preempt_schedule_irq() when the IP is somewhere the counter cannot cover: outside core and module text (all the dynamically allocated trampolines and slots), in the static ftrace stubs or the x86 return thunks that still hold a direct-call target, in a module that hosts its own direct trampoline, or inside the bytes after a kprobe that the jump optimizer may be about to rewrite (the one synchronize_rcu_tasks() user that is not about trampolines at all). - With those in place, rcu_tasks_classic_qs() also clears the holdout flag on a preemption when the count is zero, on architectures that opt in. x86-64 and arm64 do so here. Everyone else keeps the voluntary-only rule and is untouched apart from the (unused) field. A running holdout already gets poked via rcu_request_urgent_qs_task(), which makes the next tick set NEED_RESCHED, so with this the resulting preemption retires it and a Tasks RCU grace period is bounded by roughly a tick plus the longest preempt-off section rather than by the longest stretch without a voluntary schedule(). Patches 1-12 are scaffolding and change no behaviour on their own; patch 13 flips the rule and selects the option for the two architectures. Testing so far is QEMU only: x86-64, PREEMPT_LAZY with PREEMPT_RCU=n, PROVE_RCU and lockdep, with and without PREEMPT_DYNAMIC. A kthread spinning in-kernel for 30s with the function tracer, an ftrace kprobe, an optimized kprobe and fentry/fexit programs attached: synchronize_rcu_tasks() goes from 29.7s to 0.1-0.3s, tearing down a DYNAMIC ftrace_ops (tracefs instance function -> nop) from 27s to 0.2-0.8s, and the ftrace-direct sample modules load, fire and unload in about 2.5s each while the spinner runs, with no warnings and the new return-to-user assertion quiet. arm64 is build-tested only at this point; real hardware numbers for both are the obvious next step and I did not want to sit on the idea waiting for them. Things I would particularly like opinions on: - Whether hooking rcu_tasks_classic_qs() is the right place, or whether Paul would rather see this expressed differently inside Tasks RCU. - return_to_handler and the rethook/kretprobe trampolines are not instrumented. Their C callees take the ftrace recursion lock before touching any ops and the trampolines themselves are static text, so I believe they do not need it, but I would like Steven and Masami to confirm. - The register_ftrace_direct() contract change: out-of-line direct trampolines now have to maintain the count themselves (the samples are converted). I do not know of out-of-tree users beyond BPF, but this is the one place an existing user could be silently weakened. - Whether arm64 folks are comfortable with the ldr/add/str in ftrace_caller and the BPF trampoline, and with treating all of ftrace_caller as trampoline text for the IP check. - If this holds up, cond_resched_tasks_rcu_qs() and rcu_softirq_qs_periodic() become unnecessary on the opted-in architectures; I have not touched them here. Based on v7.3-rc2+ (893e11787f78). --- Josef Bacik (13): entry: Pass pt_regs to irqentry_exit_cond_resched() rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines kprobes: Expose the optprobe jump window to Tasks RCU ftrace: Mark modules hosting direct-call trampolines for Tasks RCU x86/ftrace: Take a Tasks Trace reader around ftrace_caller's call-out x86/kprobes: Take a Tasks Trace reader in the optprobe template bpf, x86: Take a Tasks Trace reader in the trampoline around its call-outs arm64: ftrace: Take a Tasks Trace reader around ftrace_caller's call-out bpf, arm64: Take a Tasks Trace reader in the trampoline around its call-outs samples: ftrace: Make the direct-call trampolines Tasks Trace readers rcutorture: Make Tasks RCU readers Tasks Trace readers where required rcu-tasks-trace: Assert no reader is held on return to userspace x86, arm64: Build Tasks RCU on Tasks Trace readers in trampolines .../RCU/Design/Requirements/Requirements.rst | 24 ++ Documentation/RCU/checklist.rst | 7 +- arch/arm64/Kconfig | 1 + arch/arm64/kernel/asm-offsets.c | 8 + arch/arm64/kernel/entry-ftrace.S | 74 ++++ arch/arm64/kernel/ftrace.c | 20 + arch/arm64/net/bpf_jit_comp.c | 93 ++++ arch/x86/Kconfig | 1 + arch/x86/kernel/asm-offsets.c | 8 + arch/x86/kernel/ftrace.c | 43 ++ arch/x86/kernel/ftrace_64.S | 69 +++ arch/x86/kernel/kprobes/opt.c | 44 ++ arch/x86/kernel/vmlinux.lds.S | 4 + arch/x86/net/bpf_jit_comp.c | 107 +++++ arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 15 +- include/linux/kprobes.h | 8 +- include/linux/module.h | 7 + include/linux/rcupdate.h | 24 +- include/linux/rcupdate_trace.h | 13 + include/linux/sched.h | 1 + kernel/entry/common.c | 14 +- kernel/fork.c | 1 + kernel/kprobes.c | 50 +++ kernel/rcu/Kconfig | 28 +- kernel/rcu/rcutorture.c | 10 + kernel/rcu/tasks.h | 476 ++++++++++++++++++++- kernel/rcu/update.c | 2 + kernel/trace/ftrace.c | 39 ++ samples/ftrace/ftrace-direct-modify.c | 9 + samples/ftrace/ftrace-direct-multi-modify.c | 9 + samples/ftrace/ftrace-direct-multi.c | 5 + samples/ftrace/ftrace-direct-too.c | 5 + samples/ftrace/ftrace-direct.c | 5 + samples/ftrace/ftrace-direct.h | 126 ++++++ 35 files changed, 1329 insertions(+), 23 deletions(-) --- base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8 change-id: 20260910-b4-rcu-tasks-preempt-qs-401ff45465c7 Best regards, -- Josef Bacik From xen-devel-bounces@lists.xenproject.org Tue Sep 22 02:18:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 02:18:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428039.1650752 (Exim 4.92) (envelope-from ) id 1x8q5A-00061i-Sn; Tue, 22 Sep 2026 02:18:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428039.1650752; Tue, 22 Sep 2026 02:18:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8q5A-00061b-Q8; Tue, 22 Sep 2026 02:18:08 +0000 Received: by outflank-mailman (input) for mailman id 1428039; Tue, 22 Sep 2026 02:18:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8q59-00061B-RU for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 02:18:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8q59-00Eheo-0N for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 04:18:07 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1e535-2eae-0a2a0a5409dd-0a2a4506bae2-12 for ; Tue, 22 Sep 2026 04:18:06 +0200 Received: from [74.125.230.204] (helo=mail-qk2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1e55d-195a-0a2a45060019-4a7de6ccfa52-3 for ; Tue, 22 Sep 2026 04:18:06 +0200 Received: by mail-qk2-f12.google.com with SMTP id af79cd13be357-93910cc46c4so350494485a.2 for ; Mon, 21 Sep 2026 19:18:06 -0700 (PDT) Received: from toxicpanda.com ([153.61.196.252]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9140249fcedsm4328836d6.12.2026.09.21.19.18.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 19:18:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=toxicpanda.com header.i="@toxicpanda.com" header.h="Cc:To:In-Reply-To:References:Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda.com; s=google; t=1790043485; x=1790648285; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=fr6kFLYx3hqPZHfOilkUN+oxGtJHBsVQ4xuLKdXd4To=; b=IEzMxAN+rOCd5LxBM6pqB++JkE9jCOoxDF3Sjd5g1Rhfpv+LooHlXQ3pBoo0rMR706 BDUFNkRUNUaGQZEpdCE6c22BCBNsREePD1DfEieYnCEFodYYjrXiviSU5vK45IK7Bm+Z cwxoAqXFD0meV164Kb930VgcxfiqgiTBGqEoQMz9Pt4+m+jB8A6as5pCyGiTT/xqvxe1 +t8WKkonmawXBgrB6fyUT2D1N283cGcT9qpvUa04Z7HxlhwA1xZpinkjXvJ6Xpb59OE7 h+31cV3Z3JYr/6hAptfGVH3iPtfXTS3rqCoLsMVCuEo54blWCS1plmm50lINfZE/U7GS N0yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790043485; x=1790648285; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=fr6kFLYx3hqPZHfOilkUN+oxGtJHBsVQ4xuLKdXd4To=; b=UhABwAJXEOLmLPUBiJj83UB1+vDHXuOUX1aSdZDGMemSiwdk0NNO90xHe5r1AItS5D DFS/LEJJvJVWougbdG//HS8SEBOp0py1tzDWGoAxhmS2hApFNzrzNFuIoGEcQEgqG4bz Z2/B9tOFxbyBS8qQ5cBgopQuKRJzkcbT9HUFHq8TOihWYfUizxI6f21sVlMfXXD56ojZ maEi5LNLKXdBg/7eQBd2Yvf+qQtb/e9uXk03zoHImTdUVhE8QUn1esoTL4WPCrrgbS9/ E/qZc9H7DKMyqUnph/yboCI/Y7hHWWg01QoitTs0bIbwL7MxB42vZt0RCpqTYwygCpkU v32g== X-Forwarded-Encrypted: i=1; AKwUvByawODQNEd2QzQZxi8vdpeYKUd815BKFdM/ZNx+lL5eahVho92j/ObWs/KjU7rsrBlir9HEpPeWApA=@lists.xenproject.org X-Gm-Message-State: AFuF++koaazYX3IMgcZy6Yp/blgo7EpfU9qQZxqTt4HSZov/DKQWKXXv RXS12OrxI/Kauxxbhmv2pMySBinDfcWECaAa0uYQI033mvmq6sjB5J1RAr6NYI/7Do4= X-Gm-Gg: AYBFou0Gc1lTHTXEe0kS2u/z9A+KE4RVz+lli2/CAYsFTfHEa3668HP+W0EqCVyZtoI 7J1WYS+h8OyQ1nCAQ7vHtBnICundXUI+tcrPwcNf/9tMRNRjh+zqNsHyRJpKp3VzEJL5CwoP54A +X7SPkSUVL40o4GZ9WYXRMfl9uG5iWmsc+H5p9NWdZfTGEj8i3wA1l+QdecFi1CTpYR4afaIA/V PMWMuIChZjjW7D+E4/jm3i3spy/9psaBqhZGuhEu0NgHtat7YMj+731FCQkwSRrKoSP3cSsx6Cj J1XlMH2gcpnnT55cgxVgzLdQeyTjA8Lc3K+pGQL7nXuJROC4q8Ap6Mt5qvSQLO7DtNGc0Nyq4Je kCp9odKRYNrfrMxT/WsJPrMqbHOA4jjywFkfWllrl4rY0LEYiv9lK0I5PD4ZHvy6FfelVmgX00d lLZu0nlce7iCfgd+nqaxiEtlsfNX5Y+I6a+VnlIpp69SKhEJDCAWUppXqqxVMb4yYcZPwaXw4mZ 9JU6V2szEQTJTow X-Received: by 2002:a05:6214:5a03:b0:912:517b:40e7 with SMTP id 6a1803df08f44-914008ed42amr14860406d6.46.1790043484934; Mon, 21 Sep 2026 19:18:04 -0700 (PDT) From: Josef Bacik Date: Tue, 22 Sep 2026 02:16:37 +0000 Subject: [PATCH v5 01/13] entry: Pass pt_regs to irqentry_exit_cond_resched() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-b4-rcu-tasks-preempt-qs-v5-1-feaf7a32168c@toxicpanda.com> References: <20260922-b4-rcu-tasks-preempt-qs-v5-0-feaf7a32168c@toxicpanda.com> In-Reply-To: <20260922-b4-rcu-tasks-preempt-qs-v5-0-feaf7a32168c@toxicpanda.com> To: "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , Masami Hiramatsu , Mark Rutland , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , x86@kernel.org, Catalin Marinas , Will Deacon , Puranjay Mohan , Xu Kuohai Cc: Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Andy Lutomirski , Josh Triplett , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juergen Gross , Luis Chamberlain , Ihor Solodrai , linux-kernel@vger.kernel.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, xen-devel@lists.xenproject.org, Josef Bacik X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openssh-sha256; t=1790043415; l=4297; i=josef@toxicpanda.com; h=from:subject:message-id; bh=vAWpKfoMcBcYFQiIgPpQZt2gAuw45VdrXu4vr32WnR0=; b=U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUBr36M/n0nWN0DNbnxwzIiCZez6MG JiruuNaSCI/zXsAAAAGcGF0YXR0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5AAAA QJZQ8OVKV4ex7QXCRnDIWeOdIBw1npa21e7Ec8iP2g5SnTyEwvqUXRliURdbJUraDntoDBPA85n hygkY9cznKg8= X-Developer-Key: i=josef@toxicpanda.com; a=openssh; fpr=SHA256:C8kOX2QUJCMqnCX+KEeoqRAjLo9L+ELOSH2NSAJHqGA X-purgate-ID: tlsNG-16d1c6/1790043486-F4A0477B-31FF6834/0/0 X-purgate-type: clean X-purgate-size: 4299 The irq-exit preemption path is about to need the interrupted context's registers to decide whether the preemption may be reported to Tasks RCU as a quiescent state. irqentry_exit_to_kernel_mode_preempt() already has them; hand them down through irqentry_exit_cond_resched(), its PREEMPT_DYNAMIC static-call and static-key variants, and raw_irqentry_exit_cond_resched(). The only caller outside the generic entry code is Xen PV's upcall handler, which has regs as well. No functional change. Assisted-by: LLM Signed-off-by: Josef Bacik --- arch/x86/xen/enlighten_pv.c | 2 +- include/linux/irq-entry-common.h | 13 +++++++------ kernel/entry/common.c | 6 +++--- 3 files changed, 11 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index 2c64b388f616..3d85035f5624 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -739,7 +739,7 @@ __visible noinstr void xen_pv_evtchn_do_upcall(struct pt_regs *regs) inhcall = get_and_clear_inhcall(); if (inhcall && !WARN_ON_ONCE(state.exit_rcu)) { - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); instrumentation_end(); restore_inhcall(inhcall); } else { diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h index 0bb6c03481fa..e19b41ee6b18 100644 --- a/include/linux/irq-entry-common.h +++ b/include/linux/irq-entry-common.h @@ -343,24 +343,25 @@ typedef struct irqentry_state { /** * irqentry_exit_cond_resched - Conditionally reschedule on return from interrupt + * @regs: Pointer to pt_regs of interrupted context * * Conditional reschedule with additional sanity checks. */ -void raw_irqentry_exit_cond_resched(void); +void raw_irqentry_exit_cond_resched(struct pt_regs *regs); #ifdef CONFIG_PREEMPT_DYNAMIC #if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL) #define irqentry_exit_cond_resched_dynamic_enabled raw_irqentry_exit_cond_resched #define irqentry_exit_cond_resched_dynamic_disabled NULL DECLARE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); -#define irqentry_exit_cond_resched() static_call(irqentry_exit_cond_resched)() +#define irqentry_exit_cond_resched(regs) static_call(irqentry_exit_cond_resched)(regs) #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void); -#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs); +#define irqentry_exit_cond_resched(regs) dynamic_irqentry_exit_cond_resched(regs) #endif #else /* CONFIG_PREEMPT_DYNAMIC */ -#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() +#define irqentry_exit_cond_resched(regs) raw_irqentry_exit_cond_resched(regs) #endif /* CONFIG_PREEMPT_DYNAMIC */ /** @@ -465,7 +466,7 @@ static inline void irqentry_exit_to_kernel_mode_preempt(struct pt_regs *regs, return; if (IS_ENABLED(CONFIG_PREEMPTION)) - irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(regs); } /** diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e3d381fd3d25..e4acd50bd81a 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -134,7 +134,7 @@ static inline bool arch_irqentry_exit_need_resched(void); static inline bool arch_irqentry_exit_need_resched(void) { return true; } #endif -void raw_irqentry_exit_cond_resched(void) +void raw_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!preempt_count()) { /* Sanity check RCU and thread stack */ @@ -150,11 +150,11 @@ void raw_irqentry_exit_cond_resched(void) DEFINE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); #elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void) +void dynamic_irqentry_exit_cond_resched(struct pt_regs *regs) { if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) return; - raw_irqentry_exit_cond_resched(); + raw_irqentry_exit_cond_resched(regs); } #endif #endif -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 02:23:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 02:23:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428052.1650761 (Exim 4.92) (envelope-from ) id 1x8qAj-0007gQ-FD; Tue, 22 Sep 2026 02:23:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428052.1650761; Tue, 22 Sep 2026 02:23:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8qAj-0007gJ-CC; Tue, 22 Sep 2026 02:23:53 +0000 Received: by outflank-mailman (input) for mailman id 1428052; Tue, 22 Sep 2026 02:23:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8qAi-0007gD-Pb for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 02:23:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8qAh-00E8PL-L2 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 04:23:51 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1e65e-8faa-0a2a0a5109dd-0a2a450cdbee-26 for ; Tue, 22 Sep 2026 04:23:51 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1e6b6-f479-0a2a450c0019-ac6904fecc0c-3 for ; Tue, 22 Sep 2026 04:23:51 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 67CA8600CB; Tue, 22 Sep 2026 02:23:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E6B21F000FF; Tue, 22 Sep 2026 02:23:48 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790043829; bh=aT3WSQsjijWvUk3bgetXyUamJ9XvWlHmx7vZ7os7un8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hKKB/1C3uOnDztTuRZBpSndHcV/CYFBsxhOq0o8XdkWY3qE1c7b98xtaVX+vAYANG zcCzllxjA2umT2xCRjwRacv+3UDVqE09H2wtsS2wNf6U4j/2tBNyNHGlFY702LKojn F90c7qQt3DUlbjupiinYJlyNser2hzkwVl48m9q3VOrKDqMb8R6dqU0rdtPBfXS3G3 ojMs1TJyIpAEH6JNn7XOkj55Np/Lo9yyGHNcKlLXkGJmtUOXd4MTXM153gguPjgHcE VZn8auKZa1V58AYvMNL5q+RGqlrLSbzNo4KnouZj0TuNLC14b639ZGpy/a/CzIG1e1 M/yGCgcWPhMcw== From: Sasha Levin To: "Rafael J. Wysocki (Intel)" Cc: Sasha Levin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Stable , Support TRINITY Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot Date: Mon, 21 Sep 2026 22:23:38 -0400 Message-ID: <2026-09-21-daily-reply-0001-re-acpi-cpuidle-xen-dom0-6-18@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <1909296988.289641012.1790015372050.JavaMail.zimbra@trinity-net.com> References: <1909296988.289641012.1790015372050.JavaMail.zimbra@trinity-net.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1790043831-038D5A5B-E767F415/0/0 X-purgate-type: clean X-purgate-size: 299 > I will try testing 6.18.52 with commit 0089ce1c056a ("ACPI: processor: > Update cpuidle driver check in __acpi_processor_start()") applied, > instead of using my lifecycle revert. Queued for 6.18, thanks. Please still post the result of that test once you have it. -- Thanks, Sasha From xen-devel-bounces@lists.xenproject.org Tue Sep 22 03:58:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 03:58:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428071.1650770 (Exim 4.92) (envelope-from ) id 1x8reU-0002k9-Sr; Tue, 22 Sep 2026 03:58:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428071.1650770; Tue, 22 Sep 2026 03:58: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 1x8reU-0002k2-Pd; Tue, 22 Sep 2026 03:58:42 +0000 Received: by outflank-mailman (input) for mailman id 1428071; Tue, 22 Sep 2026 03:58:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8reS-0002ju-Ij for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 03:58:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8reQ-001Ji1-VQ for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 05:58:38 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab1fcee-bab6-0a2a0a5309dd-0a2a450aebd8-0 for ; Tue, 22 Sep 2026 05:58:38 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab1fcee-f2d2-0a2a450a0019-416d716cec86-3 for ; Tue, 22 Sep 2026 05:58:38 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 010DB40E00E8; Tue, 22 Sep 2026 03:58:38 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nvhTkD8QdV62; Tue, 22 Sep 2026 03:58:34 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 9C87740E01DD; Tue, 22 Sep 2026 03:58:19 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1790049514; bh=MBq9MKoqYDyi6jKC6qgxnxmzVGaLBF4/RDqvU1A6oxw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MD0icsezxahjSvGTzX7FuWBeB30RgBBn2pASpPs5UbhD28SWShZh1cuuJam39GZwS Leo1YpaiXthWZboMxhxUFwUsdViaKjhrZxp4WH9EtpIe0CHu9obPwjWYpN46+CeT45 dmeg2+agTy4z79x+WebZLBYYWkldkNgqEgRyB/uhN/5FqCjJMDt9a0gtSTkjc8V82s +teTqJJsO/KCTXjMYhngD517M/Ivi9A8c9MJITaY99PisJGYHhtbelIh/Y42leqgvO SN2oOSrpC7qYV/wJHKhATS9vxorQnilOVpRpwlvfD6fTFwxDtPjsa3NU6R2J/TK6w/ iSWA/QbGYuSudg0Z79sVPpYFAFzxDttoyG9Xd2Wv0FWkDjx3gd4p56i8/YAz2mp9By Z1injbFi78Mzzc4c9z0pBRvjoc0yeyPVWQl7yPECF4ahcR6qIOqwt5iaZ0SdRi7MkW iBxT+ISyQi/M+hwCZARNJLwaWsFW0K1HoRZE8y96uJxpOZoTXVF+qBOnG6qeA7Rznn fBw/zstrEUhKUCEaxS3KeaZ4xbUifJ7+11/KViXmXBALyV75IckGDvNDeNR4iWSRgQ Ggnewov4IZGcegK/2w2kQOlDVzVio+nouBuj3xLmhaDl94ZxduZ3VsWm4xAXigikdF n/a/iOXxZ2UB85X1u/Us7llA= Date: Mon, 21 Sep 2026 20:58:15 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v10 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN) Message-ID: <20260922035815.GFarH819yHRX8WWnG9@fat_crate.local> References: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> X-purgate-ID: tlsNG-4011c0/1790049518-4B8D5CFC-0C32788E/0/0 X-purgate-type: clean X-purgate-size: 1495 On Mon, Sep 21, 2026 at 10:36:31PM -0300, Mauricio Faria de Oliveira wrote: > The issue of unbootable VMs with CONFIG_PVH due to CONFIG_KASAN is back. > > Booting directly from vmlinux (instead of bzImage) now fails with gcc-14/15 > (but works with gcc-12/13) if CONFIG_KASAN_GENERIC is set, on Ubuntu 25.10. > > The PVH code is required/supposed not to use the KASAN memory access check > in the kernel entry point as KASAN has not yet been setup, or an exception > is hit and the boot fails. > > This was previously described and addressed with __builtin_mem{cmp,set}(): > - commit 661362e3dcab ("xen, pvh: fix unbootable VMs (PVH + KASAN - AMD_MEM_ENCRYPT)") > - commit 416a33c9afce ("x86/cpu: fix unbootable VMs by inlining memcmp() in hypervisor_cpuid_base()") > - commit fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()") > > However, even with __builtin the compiler may decide to use the out of line > function instead of the inline implementation. So, that does not really fix > the issue unconditionally; see details below. So, this whole deal doesn't sound to me like we need to backport it to stable - it rather looks more like fixing some configs which want to enable KASAN on PVH guests. In that case, I'll queue this for 7.4. If this needs to go to stable, then there better be a pretty good reason for it. Right? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Tue Sep 22 05:05:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 05:05:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428079.1650780 (Exim 4.92) (envelope-from ) id 1x8sge-0003at-DR; Tue, 22 Sep 2026 05:05:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428079.1650780; Tue, 22 Sep 2026 05:05:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8sge-0003am-Ac; Tue, 22 Sep 2026 05:05:00 +0000 Received: by outflank-mailman (input) for mailman id 1428079; Tue, 22 Sep 2026 04:16:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8rve-0005ct-MY for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 04:16:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8rvd-0048zA-H1 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:16:25 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab20104-8faa-0a2a0a5109dd-0a2a4506c046-24 for ; Tue, 22 Sep 2026 06:16:25 +0200 Received: from [74.125.227.139] (helo=mail-pj2-f11.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab20117-195a-0a2a45060019-4a7de38bde87-3 for ; Tue, 22 Sep 2026 06:16:25 +0200 Received: by mail-pj2-f11.google.com with SMTP id 98e67ed59e1d1-398a384b5f7so2214693a91.0 for ; Mon, 21 Sep 2026 21:16:24 -0700 (PDT) Received: from nzzhao-ThinkCentre-M760t.mioffice.cn ([43.224.245.179]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3a0674d65d4sm2204031a91.15.2026.09.21.21.16.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 21:16:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790050583; x=1790655383; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JDLbvCKUB+a+IDR0laoJE09QGbcCCmet6VJT4AONztI=; b=Yr64FpSFTB+kfunZOesJqW4HNkMWeQFcIhKv9N+Op5AD0id34lPrveZJL3i0BORsf9 sAIebmtK1+o7BMbVWlNi67xz0FE2YfrmVzqpTzMABe+qBEsSlnY8UV6yj0sxg7m2mvzh H/Rkm+SgkIjsCgHhSmD69X2Kg8SZgnfPpO4iivj+np6uBZGA8twqiTSHnbGeXcgAgrom lXC/c0UaKvcPhbjOt/CvRSUJRK3+vUiP19m/sL6gU4rTVsr5RxiKJmS+ryPY6Bm10++0 cnxPer19AOF10E1TikKZdXpCUw1kJncNAoqJtltNyR+tCBwrEXdS82Ab34hykRrIRE2h lVoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790050583; x=1790655383; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=JDLbvCKUB+a+IDR0laoJE09QGbcCCmet6VJT4AONztI=; b=Pyiywdz7QkloURkz5ABCha+9DHRGWqziiMigxrUJ+OI4iCQl/6kJGv/gJaUD9KXPfz fILs9wWqguhOSVs9wrDSw1Yz4VKHtnXTfCWg2iTOBUk/hVmLBuC2M+u1eCtIkvi88Hej 9UcFNFyi6R8nf/CA53BwGrswh1BO+UOzeH5pY7jwqzX4d5Xng/Da19vcML9f8ISldRbw UNwH1tuH/0Gifj3bniJVlfr7dq6PXSOVtuTsNNMlIIAH4wjF9GXb/F4QY9ZIorck0cC+ CybVGBq6dkSrBjZCYibq/hKtZkBIzammWrQFNDSlvP8qC1CPrmvSHJPJHbGLe557OCA7 2+Mw== X-Forwarded-Encrypted: i=1; AKwUvBwFOsJFSmLwFcVUaDknEQ4tlBtEoEf+HTxYRI1ywqqmyWZzXS5btQHNladJSDaffI9bdZBlW8U6pJk=@lists.xenproject.org X-Gm-Message-State: AFuF++lmlrFRfpRM+pMe0vJVSvFTlYslF3eZ75/7E9WQPemKzFQhw/A4 Gi/CQ9Gtw1ias9Elb/glcF6IIP2MiKBFUCMZdNdtuFGEKKkPDwGkOBwj X-Gm-Gg: AYBFou1IhBLaHI02mRMtucJemPLewQuPTROOsFdbG2RS3rh78BjWVWBMsUZyg1K1d7d t21LfTPDPzULe7XY+cwWzgD9xof7cBLTQOwHNiormgDUgYI6RndcvxZ72sT7/09W/vwKJDiQeKC OQZdJkw2qVkTqhpJ6+SkcRVw6KUp23T1aYWzlBTV7SP6oBxY50znPGB2ue3cau/Hy4CTfzWuMFH QX7719iNHzxf0YWNYYvkOOfVMPBDOVeJ97o/4gAf9vewNBiSQcrNsnUw4+xWnS3mh345agd8FdQ IcuuZsAXfS/qB5gLoDDHr+QmexNb0sP00aT+/MajXn1cBU6LR9M1mamsGTbh8+sS7oh/hJZCBq2 t8i05kf1XQk1gZe67ezwbrVkHdy7HJ5E8jYubqCieJcuqu8DREoYIe26Xh9ehv4G31V3TPwndzA 2HndxuZqStcNoQ+xjMJWM+r517fLKArDCnzzmKD+JI3ENUXHzI3bLSQrsL2/bZgVt17wJMpW7JS 7pQn+fdmmG2M4WyBSJgXsQ8LkHJ9It8FInu X-Received: by 2002:a17:90b:56c5:b0:39d:f95d:bd08 with SMTP id 98e67ed59e1d1-39e55008a3amr25857593a91.14.1790050583196; Mon, 21 Sep 2026 21:16:23 -0700 (PDT) From: Nanzhe Zhao X-Google-Original-From: Nanzhe Zhao To: Zi Yan Cc: David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song , Mark Rutland , Ian Rogers , Jan Kara , linux-doc@vger.kernel.org, Alex Markuze , Peter Zijlstra , kexec@lists.infradead.org, Dave Hansen , Dave Young , Adrian Hunter , linux-mm@kvack.org, Hongbo Li , "H. Peter Anvin" , Chunhai Guo , Shuah Khan , Tal Zussman , Baoquan He , Matthew Brost , Anna Schumaker , Stefano Stabellini , Yue Hu , Rakie Kim , Minchan Kim , Richard Weinberger , x86@kernel.org, ceph-devel@vger.kernel.org, Eric Biggers , Alexander Shishkin , Ingo Molnar , Viacheslav Dubeyko , Wei Xu , xen-devel@lists.xenproject.org, Gao Xiang , Masami Hiramatsu , Joshua Hahn , Byungchul Park , James Clark , Arnaldo Carvalho de Melo , linux-fscrypt@vger.kernel.org, Borislav Petkov , Steven Rostedt , linux-mtd@lists.infradead.org, Axel Rasmussen , Jeffle Xu , Namhyung Kim , Jaegeuk Kim , Yuanchu Xie , Ilya Dryomov , Oscar Salvador , Juergen Gross , Pratyush Yadav , linux-nfs@vger.kernel.org, "Theodore Y. Ts'o" , Oleksandr Tyshchenko , Jonathan Corbet , Pasha Tatashin , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-perf-users@vger.kernel.org, Sergey Senozhatsky , Thomas Gleixner , Jiri Olsa , linux-fsdevel@vger.kernel.org, Mathieu Desnoyers , linux-trace-kernel@vger.kernel.org, linux-erofs@lists.ozlabs.org, Trond Myklebust , Chao Yu , Daeho Jeong Subject: Re: [PATCH v5 00/17] Remove PG_private by using page/folio->private checks instead Date: Tue, 22 Sep 2026 12:16:00 +0800 Message-ID: <20260922041600.1240429-1-zhaonanzhe@xiaomi.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> References: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790050585-F7CCD77B-1B725A83/0/0 X-purgate-type: clean X-purgate-size: 716 Hi Zi Yan, Thanks for the series. The cleanup is a nice help for the f2fs large-folio work -- it removes the page-based private-flag plumbing that my series would otherwise have to carry itself. My large-folio series v2 [1] can be rebased on top of this series. The only overlap is the PAGE_PRIVATE_* flag helpers, which I can re-express on top of the F2FS_FOLIO_PRIVATE_* names while keeping the f2fs_folio_state indirection. Jaegeuk, do you have a preference on the ordering here? My personal suggestion would be to review and merge this series first, and I'll rebase on top of it. [1] https://lore.kernel.org/linux-f2fs-devel/20260915041909.2903887-1-zhaonanzhe@xiaomi.com/ Thanks, Nanzhe From xen-devel-bounces@lists.xenproject.org Tue Sep 22 05:11:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 05:11:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428100.1650790 (Exim 4.92) (envelope-from ) id 1x8snD-0005Ly-5v; Tue, 22 Sep 2026 05:11:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428100.1650790; Tue, 22 Sep 2026 05:11:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8snD-0005Lr-1o; Tue, 22 Sep 2026 05:11:47 +0000 Received: by outflank-mailman (input) for mailman id 1428100; Tue, 22 Sep 2026 05:11:46 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8snC-0005Ll-58 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 05:11:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8snB-008U41-Eg for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:11:45 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab20e0c-e002-0a2a0a5209dd-0a2a4506a232-18 for ; Tue, 22 Sep 2026 07:11:45 +0200 Received: from [52.101.65.105] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab20e10-195a-0a2a45060019-3465416938c5-3 for ; Tue, 22 Sep 2026 07:11:45 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by GV2PR03MB11789.eurprd03.prod.outlook.com (2603:10a6:150:36f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 05:11:41 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 05:11:40 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xRKFM+zIqEPS2Pr/L9Rr3+LP7fF9dY4J4BcaQzhKy6cs5TOGkFH8OSQmHs2OlWUucbPVLbEMGyToxaJQU08bCxiaZZ6BaXRDqnaFM2jkPvlxTa4JEGTJEkJGfyfuJj2jtisW2wWUaZAs8CHIHSL9y2p1siH1XR1MCr4cbdP1i03/2i4kvDhXiaT3NVZTrCo44ut3qeWSMGuN3ab/i6PhoiDCLvhdhqv/XwZD+OtBZdTGJM//zWM3YS54AD0es3HCAdg9FvzSj/VcUmHkCv/NK4CcsQ6Tqx0x4dweVLSHanYnRut99lCL1UW3lYAYOMEgQiaTrFPARC7dbI4gTga5Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VPCuvSRLUYD57vrjBunyS6HWGCVwnF9nbgRZK71kh2g=; b=lHEcjqSKj/gpaYOkkClmbYE4P1ytQEEnw+II0uvWioHsfSrmKSgn4NsZn00UhJ1+li7/MEDsGsfHeMUANHELa8RTEbELf2LDwXPGGDWfnQhNk4KZgxdNrIs+Z4uD2Y2lxMhYm8MtmbS9d2UJ1eNPA/+UmNYIoj/h/671eiHP1G5C8knoZ7tEOGeKWwN3zILZg7wlolCVTne3RLGbQj3w/hHvKD1xUfrOu3lZPpCamMoWS5iNa4a/VRIOyGlmldxaRAzYLQ271R8UIM5gWmGzK7SFdUKgFIqZsL0BvywWDEa7qlDFDYp4HkE6L2f/kLnV+2KD+lxMqyGk8spiXLhRGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VPCuvSRLUYD57vrjBunyS6HWGCVwnF9nbgRZK71kh2g=; b=EHpOEOG9ZuV6GWheRDZk8Hn4IhKboE2AIQ/znyAUr0Oi1kM1AnIgjLpRJtcY/LAv/j4xGssv8B6ktC5EqdBIbuIv1RnxS2Tdd4v+Q9aO8zPqnDppt0GdF56o4nsLUeEV8kMjTe2ZKjDY+cVrwdeAZxkvgVQajU6gz0isAT3NtDt2ZLBJopA3CDRFvIUoE8wQaQt+12DyzXxLjMLSnaiJo9p8Qeq0ui308F6x0oub5n/CY4KeK4tbUREFuA2PNEMGbFFmPFXP43G214GzfmbvLVcxK5Hr+BWqyWtXUWvlD+9vavm1M7UfFBjddm5AqNpiluZ6zB6IC4U0/GtX+i+HEQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Tue, 22 Sep 2026 08:11:36 +0300 From: Mykola Kvach To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v3 2/4] xen/arm: validate IRQs before descriptor lookup Message-ID: Mail-Followup-To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel References: <355ff5a0aab671894a527ccb7b5999db6b168de3.1787050437.git.mykola_kvach@epam.com> <87fr03xcr1.fsf@epam.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87fr03xcr1.fsf@epam.com> X-ClientProxiedBy: WA2PEPF000008BE.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::691) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|GV2PR03MB11789:EE_ X-MS-Office365-Filtering-Correlation-Id: 03ddb63f-bcca-49c3-8b89-08df1867fc79 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|11063799006|56012099006|4143699003|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: VTZ/AY800Z6fFVDfTrEqw0LEta+WnysYhj9QxelRU02gv3kP6uZZP0VtLQWSUo9mWXVN7WtwYHdwSaH5IZqyF3lUCIFbR0uH7ysMhfdPrGzjphvs1kSuw/BSlvZTiejWH114ZMP5W/1F1x2/FuMdw+8+rUBe4sgFGvcpg6z1WT9M7J7rH7nkNsqgVsPBiAjSzvVJYmZr+hJI5irgPeQUFt/r7YHBcKneKHABM8XW7arC/29thvGr19wkeO4yrbtNXkxIzAjhT09asNUVxwgQ02DxUZsacBIUOsbSm6qMRySTZ3mL0H8ltveTCbaNQjOa7USZbVv8t17yheOMk8kSXZtaBSlChllwGIPQRgqpoi/dMWaAGg0DnylyvuIIYFaKNcOCHObLKdB6XxmW00dXGr+wO5Tk+LA2pEyUhtqJc8T63EAROvdjzuzYEFABo7GPX92m3kSg26m1Iu6GV8d2Es0omABrZ30e+EYVxifak6xOAR5cVmsYJUnP9slIWGzn/yjUZlrT3L3QN2BuGpNRu77/BjQAYB9FxzYgOq0G2mDGtfQzEKbDM57iE6QsE2QBL5MdKDC4NzzFWd8oCqJEAh4fcKn8xS5k8ccElTpitXWS3H3AcexsCEuBJQ+C7b6mFHaBWuBZFCjsVs+NBxXCo23cWx58KestgkLvzfLTcUc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(11063799006)(56012099006)(4143699003)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?LzQrajdqY0VtWnlQSXBadk5MSzkrcUFKZHQvLzlQNXd4QnAwMU5Vb3pub1pU?= =?utf-8?B?QzN0eU5Gcm5mc3lySWVJSFNGMXd6dlIwZHoxRGN1R3NpZk1zdHFmSFhzc055?= =?utf-8?B?amg3WGJaa0xJOGk0czNZN3BYMzRtdGVXdmZYUklWdnFudUJaeDhKZTI4NDUy?= =?utf-8?B?VUNiWGpPM2lPdXZlZWZJOU4xY0RrVFFLMjMxWkE3ZjRCUmhnOXhTb0FXWFps?= =?utf-8?B?UzBZbXBhdVYweDJiQW5QQWxDSitJcS9jbk9pQVVUZjhmYjBvNkgrLy9ObXFo?= =?utf-8?B?MGVlVHdOcFRXYjJkQ2pYYjBsRE1FeVlCcGxmQ0p5WWhRR0dKTGRFOGpDVHk5?= =?utf-8?B?VzYvUVZzZVRQV2x0R0QyNElOK1ZBdU1pZXBqTC9WbDZCVng1N2pOODZMOGNv?= =?utf-8?B?aGI5c1FHVUF3bk5Ldk4zSXpEZWgyMHEyVXB5RW4zZkxBYTZQcWFlOE9oNTBM?= =?utf-8?B?UUdaU3RwSnNYSWdYcmpZMXgvWENFa01KMW1jb1VwMGpWdUFjUU1xbUw2LzBv?= =?utf-8?B?NnRWNlZwZzYrYUMxa01PYkV4OXVETituMzRnNTRTRmpSdVZqMzJManhYSlNn?= =?utf-8?B?a2g1Y2NVdXRlczNtQW4rc0VvbXBSVXhCWXUxODd3eHRSTHFLcDJheXdJeThj?= =?utf-8?B?WUZMTEFrSGZhMUFxMjY1Ym1NRG05aE9kS3hXSEZZK3NTUG5qcDMxb0U1NHZU?= =?utf-8?B?REhlaDBpdU1PNmZXRXhlM2hjbmU2QmVJTDNYeDNIRkJEdThXc3R6N25OdkJK?= =?utf-8?B?ME44dENnTUZLNnIyYjhsRm9tdHNNWE9hQ0lMSi9FOXFGUmhGQVRQVzJxV2VO?= =?utf-8?B?UERvaVNTOTk3YVNvalg1a2RHa242MmU2Q0dFWGtxQXBKbURBOWwrdy8xZmY0?= =?utf-8?B?bTBwTmlTNDI3ZTdiejNvR2pFck50dWpIczErUkgxZ1hNczhRQXNrelVkRUdN?= =?utf-8?B?YkNnNUNFQkZZSk9rbXdLS3JiTUg2V3YrMUY4UUVkcGpVUE5xOTJZUXFLZmtY?= =?utf-8?B?WTFEZ1RWcWdSZ0ZhRHpQVmp0UmtFZW0vR0ZFM0hkeEpKZmxoNVg2dHVJNGZr?= =?utf-8?B?blZHWmsvT2h1ZUpxemM4TGwwQTlCZUluVVRCOGU3WEJ2eUNxb2E3ek9NUmda?= =?utf-8?B?T0g4eEFmNHhuS0ovbDVIYVhycE9YczRqNFZ5WFlMLzlSMWhBVHpzWmhhTCtR?= =?utf-8?B?aDIzSDJhTTVyY3R4V082dktUNlQ2aXBTZzFDMERsS00xdEtNOEhOeTk3Y3JV?= =?utf-8?B?azJwMUxuYldEMTNQMjBwTWh4eElhb01oVFlSS21wZDNBTFV0WXVPa1NaU2JS?= =?utf-8?B?ZXBFbGNtTDljcjNNVVhuUDhmU0RwUXowOVFtZDBrUUtOeUhIdEg4VU5RYVFK?= =?utf-8?B?ZVJmQTV2ZU9nVlgwNWRESm4xTGNzYXVHQXQ3b0dPa3hwUlU3SEJzS0x4RjQz?= =?utf-8?B?VVhnKzVuWXlqaTNaTkhheVVFSlhJdGVJNXVZdktWa0hHc1RuWGVBYlNCTWFO?= =?utf-8?B?MHcwcUR1NDdTcncyOEgxbnRXMS85QytMYUZIU1BkME8zaS9CQkQxQWdmNm9h?= =?utf-8?B?d21zcVl2c0RkYlBFdGxUNmFCOGhuaVpQT1hLWXJta0tIMGdHNGk5SnVXeEpv?= =?utf-8?B?aVRleHkrakZEbGlDNkZySUpidS9PbUpzZ1k3dmVXa0JFWThYZGh5K3NmSVZ3?= =?utf-8?B?dmJubks1bGI0aHdzYTF6aEJwaTlaS0E4Q2JwVWQrL25UZkpWb1l5a0lIZVd0?= =?utf-8?B?Q3Q3eTJiTExtNWtsMCtaTHFNU1BDYUwra3U5SGJCVnpsWmlya3pFQXFXaG9Z?= =?utf-8?B?Vms5aW8rSDdqckw5YjUwVzF4aVNtOExnTDFkOFY2ck0vZUxVc0VqM25ZSE1n?= =?utf-8?B?L1pjdTBFckMrdlRkd0hEUVRXNDMvbkJ3OTJrcGczK3l4aDhSRGxrYTl6QXpq?= =?utf-8?B?a3g1MXVJWWhPSHZHTEpkVmZkeVVLWGkxMVFDZHRwODc3UWZxd0EwRW5ZYVpC?= =?utf-8?B?dUZoRkhRSlY5ellJVlN2emg2ZUN6cGphU2Q0NEtsVFlQNU8vdS9CQWpaT3c0?= =?utf-8?B?NG8yYkV2aFZiK3k0VEZGaUZabFAvWUNISW5vaUx6aDZlajJHM3c1bE9BUUsr?= =?utf-8?B?MlNoOFQwYno0eFgzcFFRdXVIWlpEVjhXTFZGeTgwTjhnZnAvdzZUZ1RqWHQ0?= =?utf-8?B?amxGczlvK2YxK2NqSVV3RkROdlRxTGc2bXZYRFF4SVZZZmRiVURnOE1DOWVC?= =?utf-8?B?cDBxeVREbGsweCt2Z0hMTmdaRWhYM1RQYUNuU3V2UzcrTUZON2JubE00V21r?= =?utf-8?B?QlVGSmdwRGJlNktxYjlMbTlmUHhZM3gxNFU3eDdSQXdlZWZrRndnZz09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03ddb63f-bcca-49c3-8b89-08df1867fc79 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 05:11:40.8717 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 4nZZtsIN4wWPEORBs5PS6Z2YsA/huaxFFD4eGOgt2W3+PTCOVR+OH70WGLLZo/kZmM1WGCHCzO0v4sMYrmWOvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11789 X-purgate-ID: tlsNG-16d1c6/1790053905-F687577B-0A75B97E/0/0 X-purgate-type: clean X-purgate-size: 2764 On Tue, Aug 25, 2026 at 03:30:43AM +0300, Volodymyr Babchuk wrote: > Hi, > > Mykola Kvach writes: > > > GICv3 eSPI support makes nr_irqs span the architectural INTID namespace > > through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[] > > and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs. > > INTIDs 1024 through 4095 have no backing descriptors. > > > > Validation based only on nr_irqs accepts an INTID in this gap. > > __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or > > update unrelated Xen memory. > > > > Reject INTIDs that the GIC reports as unimplemented in setup_irq() before > > looking up a descriptor. irq_set_spi_type() can run before the implemented > > GIC line counts are available, so validate descriptor-backed ranges there > > before looking up a descriptor. > > > > Assert the regular descriptor bound in __irq_to_desc() so direct callers > > cannot silently index the sparse gap in debug builds. > > > > Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range") > > Signed-off-by: Mykola Kvach > > --- > > Changes in v3: > > - Add the requested bound assertion and retain the SPI-only comment. > > > > Changes in v2: > > - Validate descriptor-backed ranges in irq_set_spi_type(). > > - Validate implemented GIC lines in setup_irq(). > > - Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled. > > --- > > xen/arch/arm/irq.c | 26 ++++++++++++++++++++++---- > > 1 file changed, 22 insertions(+), 4 deletions(-) > > > > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > > index 73e58a5108..bf14180f97 100644 > > --- a/xen/arch/arm/irq.c > > +++ b/xen/arch/arm/irq.c > > @@ -23,6 +23,12 @@ const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ? > > (ESPI_MAX_INTID + 1) : > > NR_IRQS; > > > > +static bool irq_has_desc(unsigned int irq) > > You are using this function only in one place, where you are actually > testing for SPI. So, maybe introduce irq_is_spi() helper instead? And > use it below? I will keep irq_has_desc() and use it in __irq_to_desc() too, as Michal suggested. This will keep the range checks in sync. > > > +{ > > + return irq < NR_IRQS || > > + (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); > > +} > > + > > static unsigned int local_irqs_type[NR_LOCAL_IRQS]; > > static DEFINE_SPINLOCK(local_irqs_type_lock); > > > > @@ -76,7 +82,6 @@ static int __init init_espi_data(void) > > return 0; > > } > > #else > > - > > Please, no unnecessary changes Ack. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 22 05:20:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 05:20:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428106.1650799 (Exim 4.92) (envelope-from ) id 1x8svE-0006jM-UZ; Tue, 22 Sep 2026 05:20:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428106.1650799; Tue, 22 Sep 2026 05:20:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8svE-0006iu-Pw; Tue, 22 Sep 2026 05:20:04 +0000 Received: by outflank-mailman (input) for mailman id 1428106; Tue, 22 Sep 2026 05:20:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8svD-0006BF-2X for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 05:20:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8svB-006Px7-LX for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:20:01 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab20fe9-e002-0a2a0a5209dd-0a2a4504b3b6-34 for ; Tue, 22 Sep 2026 07:20:01 +0200 Received: from [40.107.159.115] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab21001-b57f-0a2a45040019-286b9f738fb0-3 for ; Tue, 22 Sep 2026 07:20:01 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by DB9PR03MB8303.eurprd03.prod.outlook.com (2603:10a6:10:37e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 05:19:59 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 05:19:59 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yNeFeRPj5ZpsZ8bp4hqEWSlNg13z5NKjJt1eUBuKptJaaTS6ngwo+UwAdJUAXnpNnJ9Et7I6vYsEsSDk99UBuh6G8Xkww8VsQKDy6RMFP2Z6/fYOb3HhHKdrkiJSpYo67f6jZyTT01Oj3IxRzN7RSObjPpPhO9vtlaAtSBZ56sGTcJ2pPKTqOtmw+o/OhYKkMaA/M+xxCJuqjeRcD2Ull3wPYqsxig2Y4nMc2D9vHmP+0riXbhevnVUBy0XiSk0HDTGwvKIsD5Uq0r1l7vb/PlVwn6cnFGoGiyAa58RZaZjKjKcFRsI9FstFJzCiTaBAX0PwwF/xFjHIQPNoS64Z7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vGDhDbXuVaAP6C+unbfLmIltTL5fRqzXWcgSLJjMI1Y=; b=SXl+v6jkPs4vadNlWpjOa6qnQzOCtBNpMphSSVeT/g3XXlsEPfrDaszZoG7AHc3A88I01yHKBYGlsHbc/lUhwoJ7OrmtH4Zr50j5A9uhuEj3KgijTKxrRVvZtUJOwMfY8TajAofR/qMRgqeAiBCNSb0Xy0jd6bJycJCv2uAYi4gAX79tmQnHWhxqNi0DcK0YFFf88w8Hc/yXEpl6/17Qu11vbwFL3nS77Le0yI7oYuinOpoX0u+fIUWbx9KJjiO3VdZGJNggVbTO8ufxlTsRv06fh3/0SfNf+QPdzny+T9N9UJgccYvbFNvc61YYfwZo1/GZtfdggjuzlO3cnexikA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vGDhDbXuVaAP6C+unbfLmIltTL5fRqzXWcgSLJjMI1Y=; b=odei0alLPWUqL6+4H45OyCzaemagbwbw5KtONrbpFWt5FbxxupP/BP/2xKxYNmWzSaRVcagmEjmLzLnOltS9p/6BNgUr2YQfWll97W4h+08JRqHrpqONtXLhkjKcyVX9lJnDG/30NTgG3RGgdWPDPVq6egtkzazEoRIKI44JpZMy2wzYlJ9xwKUaZWb1AcKCrX+e9ZlP3CdF8XRgEWAskEpxqyIMZvCTakWdSP5jMZrVGUSDgfiIlHaUF2UdWxvyZuJF0VU8Qt6MZmu7a9oWDt07Krpi21nSk/3yjq5EJEhRGFZk3MNUAA+/o4Xw1faGqyj5k0rqRfgrxNjN4LLz3Q== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Tue, 22 Sep 2026 08:19:55 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: Re: [PATCH v3 2/4] xen/arm: validate IRQs before descriptor lookup Message-ID: Mail-Followup-To: "Orzel, Michal" , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis References: <355ff5a0aab671894a527ccb7b5999db6b168de3.1787050437.git.mykola_kvach@epam.com> <87fr03xcr1.fsf@epam.com> <4eba243f-01cb-49a6-9f6f-edab49d5901b@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4eba243f-01cb-49a6-9f6f-edab49d5901b@amd.com> X-ClientProxiedBy: WA0P291CA0011.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::23) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|DB9PR03MB8303:EE_ X-MS-Office365-Filtering-Correlation-Id: 1d92058b-04c5-4d16-2514-08df186925c3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|22082099003|18002099003|11063799006|56012099006|4143699003|10067099003; X-Microsoft-Antispam-Message-Info: cjGcKvUHnUTcdRNfVf0s/W5/DPCPBSBketGFMRB6bo00Mko/OcLkRigfOWp93aItMmvhUvnbSYQ/D2beXg6xrm7pGpk5wHby5vxY7jKzVIN38gF08fw5OUZFcKtIxWMJewh23Yy841N1eaPwuidWtbAz7g1fO0c6vktnn70JXusoLPP/pt2/JrYIBlR2JjBVuABRKQ8W3ubYKLujRe7m8VKKzmPb1LKq6B8RpNdfdi27sHmTIFNDr7tjatUcV93KUc1Ic9CMok+h/MJicXUEEimaCZ2Bcieyk//T1LrP9Qln4I0RCl1tW+fmuEwCADF7Wwm4ITjT5DMSU2PTd9WsaKELTP9T/kQ+fhxSDpOb5yrhLAPqZSq2bKzcOCya7jRgYW7nkoA8S6u/tKI3v4nFcl+BpAjzki1KXkEVNZgqpVjQ2UIwB+PGlyx0D0gQJJPHxU7zGHsJwYza0Skc8kTH9IyWMU/K+jmrZzGmS7qJSTJTTWctp0ImMyTrvbjmO+pMXfRElMI6oSqtD0Jfda8P6xEiWuuxJCtq0adUkPoYui8UdzdQNiFgFlVpkpQgntGp/8gQ+1qfOgPDAlSpentWmug4pRhPdWz+1YS4jsIiPSrUvUV0pO4hC4LA48e/aJOGQ6rjStwnj75641f1FeF2Ywzijh7g2SKumeXn1JThteQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(22082099003)(18002099003)(11063799006)(56012099006)(4143699003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OU5VZTVWdGFNZHB2QjUrU1lvT01McEN3bngwUnFDQ2p3Z3lCN21iejdCYTFk?= =?utf-8?B?ZEh5bno0eUN3WEljTi9tS3VGdW93ZGhsT0lJMzFlVzBucUNFUTZEaHRHNCtp?= =?utf-8?B?U2pGK3V6cXdCN1M3S2ptMm9jeWFudkhHNTZJaEJ6ZkI2aURZRE5yTTVvU1R4?= =?utf-8?B?YmErM3A5T3B4MjRBY3dIWXNPaEZVb3dHVGUzZEZqSkRremJORTg5OTY1NWpi?= =?utf-8?B?UkhacDJwQVY1elNvbldpakVPL0NwY2VMSm9nWnR5TThXSUNFOGJGTUhjSEZq?= =?utf-8?B?RlIwVitYL2ZobUZ3dXRnNG9aVGkzY3liZ1kydzdKRnNoVUdER3FMWlA5VWc2?= =?utf-8?B?bk1nYzg2cUt6bEQzL214NFhmbzlpN2V3T3J5S01zUHd5M3dlWjI2b29SdjJO?= =?utf-8?B?YTdSV1Zrd0pSRUVDcFNsU2FnN3hyUWc5NEF3SDhNRXN2YXk4dlNzR3JPVEtK?= =?utf-8?B?SVIwZ3JpUzdrMXRRSW1UY1grcGo0S05ZYi9TaDc5Wm5VL284TlZIekN5MkdQ?= =?utf-8?B?bGhmbXVYVEx3T0V3SnFiSGtSSHMvQXhyKzBDWkM3WWR1VmhNUmhralpVZVY0?= =?utf-8?B?WENJWXJVL0JxcW5JVkxOajNjVXZ2MEVMc0NMSjl5Q2RWSUZIWWx3UHpMdFYr?= =?utf-8?B?SXg3QW9RWmJJdlFCUS9BeVV3WHk2UUJIT2VIaEllbFA2VVNRU1dleEdlV3ly?= =?utf-8?B?MndFM1QrVFhLbm5LMS9yZEJZM040aWt1QkxJZnBmMDNxQ3ozSnNLUmdGUXI4?= =?utf-8?B?YU9Fc0dyNWQwZ2VTV3F6VXJ5dzdkY1FveU9oVHRvc3pCUEhsOUE3bE9ZYWJy?= =?utf-8?B?ZE5kdlkxWjZEVnpLSkxKMGVMRTVIRXk1cFpvSnZ0V0dOWEpRWmlKSDlLWWxP?= =?utf-8?B?dGw2TW41ZlZFSURLSjZzTFJZYlFJelY4Qkc4eDRqL0lXT0NoUkROWkNwU3Zl?= =?utf-8?B?R1E2TGs1VUJsKzk4NFYyS1pTd3FHUDJmS25Ka2xDZ2NoNU53dGpha0lsODZD?= =?utf-8?B?cGs1R2dyckhROU5UZXFRUU5VVTJBWGFqaGZ3dVk1c0N3TlFiWGtXaFRmaHNl?= =?utf-8?B?V1FDYU1zaFB0WjNNa2U1T3JXcFd2cTdHTnBrQlVDVHFyaW1vV1pYS29pY2Rj?= =?utf-8?B?TUM1b3NHRldESFJMUjE4MU1OVHF1MHRoKzA2NjJMK2YxWHlob2ZwZlEwR01U?= =?utf-8?B?WDFWSytkZXBSeW9yQUcrMWZBczdCMXVPMHpLSGYrSU9YeUJ6ZkZSQkdEcDl5?= =?utf-8?B?dWV3ODB3aWQ5N2hIbkd3UENOM2svaWpiYTlRUVExVHRhMnl6VS9uUTU0eFpB?= =?utf-8?B?TVhtYmpTVlMzSUIzMkZvanp2dEp3M05NMWVPU3JqNGcrMitUNC9JOFpPY3gv?= =?utf-8?B?cko3Y2k0OXBYVFhBVXJBQU4xdjlMUGhaOE80WTJDMzZZZHAxMWR1Q0xCRWVi?= =?utf-8?B?bDB0cnB3N00xTkNTNFFhYmhLOHRzTS9hck5WMlhDVkJzdnRibzgxOU1rcmIy?= =?utf-8?B?c2U3bnRucjhzclliaEFNL1NMWHY1c1NOL1RMNzhleXdOU3p4TVBWeWlFb3VQ?= =?utf-8?B?NnJNdUU5Z096eEtzZ1BVQUZuSGlmL0o5cGNIL0ErbWxqeW5lOTQwTTIweWpG?= =?utf-8?B?MGFRMktHYnRvTGIvbmFSb0NMb1VwR1JiUkpodDNtZ1V1OXd0TTB0WlZlMnFX?= =?utf-8?B?eVFNdWNNMms1YmxPMWY5SUZqYUVJdWtKbldHd3EvbmVkRDQvcXBTODBjb2lp?= =?utf-8?B?SDZ2VFdNQnV4M3lyK3QwSTNRbGJDYkVMbEU0bUdIZVJqQnY4TituenI3M050?= =?utf-8?B?eFRlbkh6ZU9WMFlBT2t0SW9zUzhUSHhsZlU0eE1YV0huZXZUNEQ5d3ByVUY2?= =?utf-8?B?SU1PL1ZQdVM4QUluWHZ3ZXFCRElpMGd3UW83ZGdvWjNuVVZIN1BVVTFtOVRS?= =?utf-8?B?SHlFR2RrM3lTSUcyaTJXRVJ4WXZWVHlObHJDMkhJOHM0YzJqNHg3M24wOXVr?= =?utf-8?B?UGdnemtQT0p4Z1ZjT0tWaXEzTGs5bDMrY1dOeE9tQ0Y4aHpZOTJXS0FBTGNy?= =?utf-8?B?a1FobXF5TmpwVHl6ZUxxZFF5ZW9uME9TM3FwcWZqbFFWeTNPbTVYUzdZZHgr?= =?utf-8?B?UjcwVGlJZVpqQ3NSMHpCcHovYjB6MUg1cjliR0UrVVAzSm1QNzdsajVCOVk0?= =?utf-8?B?akxPSjFSSnBXbktvYVJubUVVc0tjbDZwNHRyK3BEc0R4V0ZRUGxGdlZBQW9X?= =?utf-8?B?c2hTbGZJeTBHMGkwQ0s3bmFuVXJ6ZlJZWHFRekRYWkF4NWZwTHlFZzJHUkxP?= =?utf-8?B?TXdIL0docWYvQkgrV1dRaXozdTQ5QmhFVTVVTEpOQzJYczcyVENNZz09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d92058b-04c5-4d16-2514-08df186925c3 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 05:19:59.5155 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5yQAXJaUoWG7kDR2zuDPE/sSccWKVlBg8Q44/cOMZrSdbH9gwuWB3ochmKbBWq0jxodqbfQTD3rhR8/hxykQ+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB8303 X-purgate-ID: tlsNG-ebf023/1790054401-51ED6B50-E25DF726/0/0 X-purgate-type: clean X-purgate-size: 3939 On Mon, Sep 14, 2026 at 05:20:44PM +0200, Orzel, Michal wrote: > > > On 25-Aug-26 02:30, Volodymyr Babchuk wrote: > > Hi, > > > > Mykola Kvach writes: > > > >> GICv3 eSPI support makes nr_irqs span the architectural INTID namespace > >> through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[] > >> and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs. > >> INTIDs 1024 through 4095 have no backing descriptors. > >> > >> Validation based only on nr_irqs accepts an INTID in this gap. > >> __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or > >> update unrelated Xen memory. > >> > >> Reject INTIDs that the GIC reports as unimplemented in setup_irq() before > >> looking up a descriptor. irq_set_spi_type() can run before the implemented > >> GIC line counts are available, so validate descriptor-backed ranges there > >> before looking up a descriptor. > >> > >> Assert the regular descriptor bound in __irq_to_desc() so direct callers > >> cannot silently index the sparse gap in debug builds. > >> > >> Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range") > >> Signed-off-by: Mykola Kvach > >> --- > >> Changes in v3: > >> - Add the requested bound assertion and retain the SPI-only comment. > >> > >> Changes in v2: > >> - Validate descriptor-backed ranges in irq_set_spi_type(). > >> - Validate implemented GIC lines in setup_irq(). > >> - Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled. > >> --- > >> xen/arch/arm/irq.c | 26 ++++++++++++++++++++++---- > >> 1 file changed, 22 insertions(+), 4 deletions(-) > >> > >> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > >> index 73e58a5108..bf14180f97 100644 > >> --- a/xen/arch/arm/irq.c > >> +++ b/xen/arch/arm/irq.c > >> @@ -23,6 +23,12 @@ const unsigned int nr_irqs = IS_ENABLED(CONFIG_GICV3_ESPI) ? > >> (ESPI_MAX_INTID + 1) : > >> NR_IRQS; > >> > >> +static bool irq_has_desc(unsigned int irq) > > > > You are using this function only in one place, where you are actually > > testing for SPI. So, maybe introduce irq_is_spi() helper instead? And > > use it below? > It can stay as is but: > - move it next to __irq_to_desc(), > - use it also as ASSERT(irq_has_desc(irq)) in __irq_to_desc() instead of the > assertion you just added. > This way the two stay in sync. I will move irq_has_desc() next to __irq_to_desc() and add ASSERT(irq_has_desc(irq)) at the start of __irq_to_desc(). > > > > >> +{ > >> + return irq < NR_IRQS || > >> + (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); > >> +} > >> + > >> static unsigned int local_irqs_type[NR_LOCAL_IRQS]; > >> static DEFINE_SPINLOCK(local_irqs_type_lock); > >> > >> @@ -76,7 +82,6 @@ static int __init init_espi_data(void) > >> return 0; > >> } > >> #else > >> - > > > > Please, no unnecessary changes > > > >> static int __init init_espi_data(void) > >> { > >> return 0; > >> @@ -95,6 +100,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq) > >> return espi_to_desc(irq); > >> #endif > >> > >> + ASSERT(irq < NR_IRQS); > check_timer_irq_cfg() in time.c calls irq_to_desc() on timer_irq[], and on the > GTDT path those are not validated. Patch 4 already handles this. It checks irq_set_type() before saving each timer IRQ and stops boot if GTDT setup fails. > > >> + > >> return &irq_desc[irq-NR_LOCAL_IRQS]; > >> } > >> > >> @@ -416,6 +423,9 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new) > >> struct irq_desc *desc; > >> bool disabled; > >> > >> + if ( !gic_is_valid_line(irq) ) > Please add a printk message to inform the user. Ack. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 22 05:26:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 05:26:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428112.1650807 (Exim 4.92) (envelope-from ) id 1x8t1J-0007aj-HC; Tue, 22 Sep 2026 05:26:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428112.1650807; Tue, 22 Sep 2026 05:26:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8t1J-0007aa-E4; Tue, 22 Sep 2026 05:26:21 +0000 Received: by outflank-mailman (input) for mailman id 1428112; Tue, 22 Sep 2026 05:26:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8t1I-0007aU-5d for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 05:26:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8t1H-001VvB-7L for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:26:19 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab21175-bab6-0a2a0a5309dd-0a2a4501ed80-4 for ; Tue, 22 Sep 2026 07:26:19 +0200 Received: from [40.107.130.124] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2117a-5984-0a2a45010019-286b827c671b-4 for ; Tue, 22 Sep 2026 07:26:19 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by DB9PR03MB8303.eurprd03.prod.outlook.com (2603:10a6:10:37e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 05:26:17 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 05:26:17 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k0o4NwVJVHu0UnaSq1bF7eZ+QNe1mIVG1pRU39f241mC4HSWlRN2rsEQnD3jlEw2VYKb+AS5fYeQrbpXRGI7kVQJwjTVjdMutECI6uMYtOk6gYhr8w0CgB+nXNpASduMCPHt44/AzDjWBh61bKKLY5H77V/ViJ7Un0sL0KwocvpAvcQganP9ZPjD/BTIG+qJ+8LE5XhS8MpuPwXv5smQasPhAtBQSCpy17lpBgCBMCy7jKoKw5Curg9mfDUxpo/miFRnW8Wlwk0cSb4jh7b1xwNZiySHeRmxl14OOO8qZ2HLwGQp8fcmpZBQI0UrleXPnLbyrtfuks/KKp+0bvOJ8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QkzG1G/uSLHdxO2Qo/R8DUfiJJyJT4LbFRZ/pEkIQVI=; b=OX3qD8baVHhJTopI65oowxBGKwfCXDV9ZaiQQQWxFQkwoqVvfNlhrXlFtI62N2zh3ra2wn+JXLY5szvISCPbHCAY9or0JK7llOEsyl2Zv8dqY5ieD6Q8yFIcfJY7kHu6tKAYoQTLiDAsZcgj91FSpKBy3S/4ivcTWwrOefbAwrFNkkcHiTXN6ysGvj1wT8mezIUABVnxuDQSgAMSxvIUMuO0fsDkhBMGXzBv26KP4QZeshafG62xCWD2QEEt5mcNMh7k3yMdqNOGl7VrFU6OnPx3YREP73rRCREuKI6nohvdHtiXlzCTpxizn/Hu8yt+Q/aZgkqp2eP7k5Afe3B7cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QkzG1G/uSLHdxO2Qo/R8DUfiJJyJT4LbFRZ/pEkIQVI=; b=dUZH+Gh/3xk7JdBbQleKClWa0ICz7li3tj9mvhmY/DUOPd/LX5o8TTcxfn4hLK9bL4rZRZoTE6VLmGG96VmeDhG1iZkO36x7qXZG0rUYQUjBxzDkkKuNL1S+7vVXEbeF8xJDV945pTfExojt+3hzlwyzLRQssSS2v1MJR8kRXpe1H8U/0jHYnQ358GAXeImzv8YSD5e53CKjWIMIOQrcMhYn4qlM0CKpfrGSJhoGFgN8glhPGq5lVjHKvPa7JPW3CcLS/OsPQRlRXgK/C83otgIN7zCKyNh2E0zFVKsXW/+JZXwOcuPrSXgeRZpAnIg83T9ATlGWlwEyWfGww4pOwA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Tue, 22 Sep 2026 08:26:12 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: Re: [PATCH v3 3/4] xen/arm: vgic: free eSPIs using the bitmap index Message-ID: Mail-Followup-To: "Orzel, Michal" , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis References: <874igjxcjs.fsf@epam.com> <2e0f1fcf-dfcd-4a26-8124-4b7da0ca4f83@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2e0f1fcf-dfcd-4a26-8124-4b7da0ca4f83@amd.com> X-ClientProxiedBy: WA1PEPF00005B7A.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::616) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|DB9PR03MB8303:EE_ X-MS-Office365-Filtering-Correlation-Id: e2f27b79-892f-4396-ec6a-08df186a0690 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|6133799003|22082099003|18002099003|11063799006|56012099006|4143699003|10067099003; X-Microsoft-Antispam-Message-Info: w1J5pJ7IhM+rqfWyOIc1N1i8tAQqG1VLKutJOWViHkALY+M7/UYq6v9jgrYFdST/kt0LMif03O4o2M3a+etlBRVG/Pv/R92posA9CZnA/aLJpciNDtYEVbqVpoPcCKfBBHGa+GXjqJYIQ4COY6C2fTw9aXdxc87oRScmc9CFUbw78x90JBn4wpbVajH/dPNrLzoxl87aE0QNAu6KJGsS38lkPLFbDIy2cmGOq1ICudUc47ymehkxjxo8/3Ny0gJx+Y5c0qfgVManMm8YfXXngslEbsbzKkyqX8xqDp2btZeVnivRQK56JbJQPPHrCDVc8hiSSe2z3/2FTRLUTL90UJa5dS46DyNcXUupz77/tjpY6exC64mH9sl94v3/0Lnx4j9wbUTUB2aNYppp998hwZKwGfvEjRBT+C2+yeOxswqYB4Du81YvuRGAZYeGQkao0usctalyxcEx/dF+UOt89Q0lk4bgaUfWfmWN6RUPT4/9AmebsfEvFNBPOGTpG//tNMLsrvMZ47CK8GDZKxBdYh9YpIkmGWSU4Zh53NkcHhOxl2083si4FacHHbDtqy/yjayFv65EBx4psReTFh1XpT2Rf6gH+HddJSNY2ShawvAyO4oCYtU+mxYfLx4gWT0F1gWvjIzw1NmZJLP5YmLr9xtNWKlH0QENxQtcvZc9FPw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(6133799003)(22082099003)(18002099003)(11063799006)(56012099006)(4143699003)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M2E1YU11ZlhuSHdtWE1jMnN5OC8xdEJkSlM2UFJvWGtKUFZ5aGp0WnUzWWVy?= =?utf-8?B?cW1lTzVqVC9oZWxweUtCNDdZU2JwME5zMkhuOTVJUXVVSk1aK0FmQVgyTzY0?= =?utf-8?B?MFFqSndmUGFDZ1RvVWYyd1cwTTQ0ZXp2RWlKTkE3YVBqWUY5RFFjWEN4Yldx?= =?utf-8?B?blZYUEx3QzAvLzUwZDBzZkNEMzhtV1Nvc0M4UUdZUEFuNmQrVVcrQU52Z0Jo?= =?utf-8?B?YkY1OGw4cUZuRytKamJySW1HYzF3RGZJZUZsT3F5b2VtaXJ5bW1EcU5LR20y?= =?utf-8?B?azlCc21QRlF3N2lrS1RSL04xZGt1NStRYXAzbjk5amZMYzh1RTcwbytVUzJj?= =?utf-8?B?M0ZjOUVJN0R4UlFMUThlVkFCL3EreVljWXF0RUFLaUlaUXdjZkR1bUJtNWll?= =?utf-8?B?SWE4dGE2Nll5eHpjSk5aZUJWU0hNQlp5eFhzeWVENzg4Und5MG5YSWtMVENY?= =?utf-8?B?MUxDS0FKSmVVSmR5V0Z5bWNpbkRBQTdjekZNUHdGTURtY1ZEWm1YZXNVNlow?= =?utf-8?B?b2J3dkZHZCswdXBZZ1lYaFBVZVJCNG0xQStGQTV5VG5TNFBPcTJnVjZPOXhC?= =?utf-8?B?aUwvUmlXYmtsak1xUGF5K2pEenN6OWx5bGg1UGpDbzgxdnB1QUZyWjVNMTBy?= =?utf-8?B?SEdNMk4wbTFQSUZSaTJ5S2xXUlhnOGg1RGk3MHp4UHVHbnFiL1d3U0NrbzRU?= =?utf-8?B?UEtvMlpRK0hCemY3N2ZZdUcxK0JOdGNyTU8rRXMxeE9aZ0lUYjBFOXVDeUgy?= =?utf-8?B?MHhyYkhibkloeVRtZWpuc0VYcDJHUnZXZ3JLYkNkdjhqNzJ1eG1zWXB2UnA3?= =?utf-8?B?Y2lMNWZJeGRJaGpQM25wR21DaitJY1lZWGtIYXdmUFZsVTlEa3RFSjY5eTly?= =?utf-8?B?dEJ0U2hJUFhPb2VCU3VYM1IwR29LU1d0c2Z1RVRoZWV6dW1FUUM4cVdWcGM5?= =?utf-8?B?VzRrbUVyTFlpMExSY25EdXRNR2huUDltcnVzT3dZWGhqeWFGK1hoSjBQV2pj?= =?utf-8?B?NStRVVo4ZVFSSmlyNkdHYVpyVWdOZlgxL3R4T3hhano2RVEyemhMR0hneVlj?= =?utf-8?B?blFlRlR1TEVXV2R0Rk5oZ1RjRytBeUFyTldHRzhBclM4Qk02WHpQZEs2UGh0?= =?utf-8?B?ejh5YittZzNYb21IOWdWNTJUR2FsN2Q5bjlQalRYTFEzVU42QTEwT1JYWURG?= =?utf-8?B?WXBTM3NQTGgvWUNYUUh5UXVhNThIdWZZaXRZSGF0anpHUEhKeDcyNSswTm5B?= =?utf-8?B?L2FlN1FJUWRYa3lRNkpqcmRkeDRoUnQ2N29WY2c3ckxCbG5paThrU2JkcHBO?= =?utf-8?B?TGlEU2IwYUI4K1B3ZmJTTjU3bmxiWllTMWxGS0MwSDJOcXowTkFCYm9PMTJz?= =?utf-8?B?ZHdtRW0yRUM5R1FXM0grbnBoeXBqbkYxbzJFaGU4TTVmUTUzRUdUOGxYT2U2?= =?utf-8?B?UmFReHFocnpJWDMyUjg4UUN6dWhVZWlpMktVNDNhaW91WXZabkRBdDB0TnJR?= =?utf-8?B?MlJYUWxyZlRyQW5HRkVaMFY4VlhuMWhFWFdKZEdvMU9EdHY0dDZUdnYxOGFq?= =?utf-8?B?RCt5dHJ0K0JORlNyZW4zMUZjeVJLeHdDR3pJQ2UrRlJKS2JIUmJyRGhKcEhH?= =?utf-8?B?NENDVHovTjRUNFhyMVRFNnMxSFNoZ28zbytLUzJ4WHZHTUNpM3hPektUcDVK?= =?utf-8?B?eUhjZGdDTlFWU2pmcUlTdDB6aXkyQ095cmVkSVBFSzJDZGJ4YU94ZHZTV1R3?= =?utf-8?B?eTVkQ0hkN2w4RFdZdnBVSVBXdXZncWFpWFBtY0puZFcwRVV6ZjMrQWE3emJx?= =?utf-8?B?NkR2ZTVwNGF4SXhTTStOdGFoMmt5UkNleWZKelBqd21RUzVBNXRTQUpjUnRW?= =?utf-8?B?VUdPNHhQSklMaUZ6T1I5dXZYMWgyaGZCb2JUNUFLdnAwWm1lNnNjMHJGK2xO?= =?utf-8?B?TnptR1BNRW1jcFkvWVF4SnppU3FKOEFlZjEvcFI3bTJHV0lrWjUwWVFHWS9R?= =?utf-8?B?MUhOYVREazBleU9tTElMalhxMVJ6eGNZVDNqVUFPUVI4K1dKRFovYjduRGZN?= =?utf-8?B?NjZiSVhWNjhUa21CTFEyT1JEMXN1UWlaVmQ0RUdIdU5ucDJRUWtiTklNZUJM?= =?utf-8?B?NEFnOHhrSUJINHpkZkI5QmZ4TWhidFpHUm0zeGtrakVJZ0lSMXNRUWpqTXJk?= =?utf-8?B?SkcyZzR5d0dkazFHbmIwT3psN1c1UHZ2V3FlRDJzRlpMUzZQa2ZWREtOWEpa?= =?utf-8?B?bGJJb1NQZmxLRGYyQXE2YWpqeVJxSmpLeW5xdlhHTUNTUjUrWmE5elFNNWNX?= =?utf-8?B?TzNzUWFaNklzZFQxZGRtK3l2MTh4VHFCbFh2NUNtRWdqcEtXNEFUQT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2f27b79-892f-4396-ec6a-08df186a0690 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 05:26:16.9831 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YWg8UPPMF9GUBk6gEyecGrpudp6xajOTi41Tt3W6rilJoZF64LXaeZ6KZYKxMtGi0xkOvLGEBQcjgVFSoZWmFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB8303 X-purgate-ID: tlsNG-d62444/1790054779-BE465757-87861756/0/0 X-purgate-type: clean X-purgate-size: 2019 On Mon, Sep 14, 2026 at 05:55:29PM +0200, Orzel, Michal wrote: > > > On 25-Aug-26 02:35, Volodymyr Babchuk wrote: > > Hi, > > > > > > I have only one small question to this patch. Please see below. > > > > Mykola Kvach writes: > > > >> The allocated_irqs bitmap in the existing vGIC implementation stores eSPI > >> allocation bits immediately after the regular vIRQ bits. > >> vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index, > >> but vgic_free_virq() used the raw INTID. > >> > >> Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit. > >> This writes beyond allocated_irqs and leaves the intended eSPI bit set. > >> Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind, > >> and during vPL011 teardown. > >> > >> Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving > >> and freeing vIRQs. Validate a vIRQ before clearing its allocation bit. > >> > >> Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended SPIs") > >> Signed-off-by: Mykola Kvach > >> --- > >> Changes in v3: > >> - Adapt virq_to_idx() to the configuration-neutral is_espi() helper. > >> > >> Changes in v2: > >> - Call is_espi() without a configuration guard. > >> --- > >> xen/arch/arm/vgic.c | 27 ++++++++++++++++----------- > >> 1 file changed, 16 insertions(+), 11 deletions(-) > >> > >> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > >> index e14123a30a..e541348a5c 100644 > >> --- a/xen/arch/arm/vgic.c > >> +++ b/xen/arch/arm/vgic.c > >> @@ -33,6 +33,16 @@ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx) > >> return idx; > >> } > >> > >> +static inline unsigned int virq_to_idx(struct domain *d, unsigned int virq) > Please add a comment at the top of the function about the layout these two > helpers encode to prevent such problems in the future. Ack. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 22 05:58:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 05:58:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428121.1650815 (Exim 4.92) (envelope-from ) id 1x8tWi-0003S3-Vd; Tue, 22 Sep 2026 05:58:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428121.1650815; Tue, 22 Sep 2026 05:58:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8tWi-0003Rw-Ss; Tue, 22 Sep 2026 05:58:48 +0000 Received: by outflank-mailman (input) for mailman id 1428121; Tue, 22 Sep 2026 05:58:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8tWh-0003Rq-56 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 05:58:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8tWe-008aJw-9r for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:58:44 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2190a-e002-0a2a0a5209dd-0a2a4507bb50-6 for ; Tue, 22 Sep 2026 07:58:44 +0200 Received: from [140.77.166.138] (helo=sonata.ens-lyon.org) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab21913-b4ea-0a2a45070019-8c4da68a9d3a-3 for ; Tue, 22 Sep 2026 07:58:44 +0200 Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id A0251A1B39; Tue, 22 Sep 2026 07:58:43 +0200 (CEST) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8216Fqrn58Z; Tue, 22 Sep 2026 07:58:43 +0200 (CEST) Received: from end (unknown [212.133.41.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id 30F47A1AB4; Tue, 22 Sep 2026 07:58:43 +0200 (CEST) Received: from samy by end with local (Exim 4.100) (envelope-from ) id 1x8tWc-00000005kqi-06Ue; Tue, 22 Sep 2026 07:58:42 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1790056723; bh=kB21aFMYP3Wne3A5TEiMM2DbLMErC5eSQEttNviZ/58=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=chz+wkXslWRW8Wj9Ol4P6vplS/tMsVh0ADnWHDSg49QFO2jJSaHbZkFOu1So18xQK hQwUjlwFKhVcCKwnWBXc838/D8jEPNutG6oHPCYaJyQLtmDpmfSuN3xqh+Mha7zMnv brAkv9CtXAHPk0UwcQRatRPsA1qvjrlhbaA44Zu9AFKXzRkoq1df5tQDx+5gzm9hwS TG8k7dk1LkhbijO3WYmCTyxC2qw+D+32ZL6MzUXeXKedWynZwl21w77ET8A8rF/L/u bv+rnqeRvrp38ant23myEpEvjlhj65cKaqCGinE0PHk6ScWt7iKN0H//26OqhSXbMO ZQYbKfrpZDGQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1790056723; bh=kB21aFMYP3Wne3A5TEiMM2DbLMErC5eSQEttNviZ/58=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=chz+wkXslWRW8Wj9Ol4P6vplS/tMsVh0ADnWHDSg49QFO2jJSaHbZkFOu1So18xQK hQwUjlwFKhVcCKwnWBXc838/D8jEPNutG6oHPCYaJyQLtmDpmfSuN3xqh+Mha7zMnv brAkv9CtXAHPk0UwcQRatRPsA1qvjrlhbaA44Zu9AFKXzRkoq1df5tQDx+5gzm9hwS TG8k7dk1LkhbijO3WYmCTyxC2qw+D+32ZL6MzUXeXKedWynZwl21w77ET8A8rF/L/u bv+rnqeRvrp38ant23myEpEvjlhj65cKaqCGinE0PHk6ScWt7iKN0H//26OqhSXbMO ZQYbKfrpZDGQQ== Date: Tue, 22 Sep 2026 07:58:41 +0200 From: Samuel Thibault To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Jan Beulich , xen-devel@lists.xenproject.org, Anthony PERARD Subject: Re: [PATCH 2/4] stubdom: remove pciutils Message-ID: Mail-Followup-To: Samuel Thibault , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , Jan Beulich , xen-devel@lists.xenproject.org, Anthony PERARD References: <1f814c72-6fa2-4177-8da0-e17e0406e473@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1f814c72-6fa2-4177-8da0-e17e0406e473@suse.com> Organization: I am not organized X-purgate-ID: tlsNG-ef75cf/1790056724-368D9AE4-918F4A22/0/0 X-purgate-type: clean X-purgate-size: 2389 Jürgen Groß, le lun. 21 sept. 2026 15:07:36 +0200, a ecrit: > On 19.09.26 18:57, Samuel Thibault wrote: > > I have submitted the pciutils MiniOS port to upstream (which I should > > probably have done 18 years ago :) > > > > https://github.com/pciutils/pciutils/pull/235 > > https://github.com/pciutils/pciutils/pull/236 > > > > Jan Beulich, le mer. 19 août 2026 08:40:37 +0200, a ecrit: > > > On 18.08.2026 23:42, Samuel Thibault wrote: > > > > Jürgen Groß, le mar. 18 août 2026 07:43:34 +0200, a ecrit: > > > > > On 17.08.26 18:37, Samuel Thibault wrote: > > > > > > Juergen Gross, le lun. 17 août 2026 10:24:02 +0200, a ecrit: > > > > > What about adding a comment to the stubdom Makefile in a separate patch, like: > > > > > > > > > > # pciutils support has been removed with commit , revert that patch > > > > > # in case it is needed again. > > > > > > > > > > I think this would be preferable over unused and probably bit-rotten code in > > > > > the repository. > > > > We can point people to pciutils through such a comment. > > > > Jürgen Groß, le mer. 19 août 2026 09:12:00 +0200, a ecrit: > > > On 18.08.26 23:42, Samuel Thibault wrote: > > > > I don't see why it would be bit-rotten, since the pciutils version in > > > > used is fixed, it's a library that has a quite stable API, and the pci > > > > xen interface is supposed to keep backward compatibility. > > > > > > Then I'd rather add it to Mini-OS (probably behind another CONFIG option) than > > > having it in the Xen tree. > > > > Mmm, but how? We don't really want to pull the whole pciutils build into > > mini-os :) > > TBH, I don't see why the whole Mini-OS specific stubdom maze should be in the > Xen repository. It used to be at least because Xen itself was using stubdom for ioemu. Nowadays stubdom-ioemu is away, but stubdom/ still builds xenstore, so it makes sense that it's xen that builds it along building the non-stubdom version. > Thinking about the hoops I had to jump through for doing some > of the Mini-OS cleanups (especially regarding config options), having all of > the stubdom stuff in Mini-OS or an extra repository would probably be cleaner. I don't really see how that will help with the config options management? It will however make its buildability checks less apparent to xen developers. Samuel From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:17:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:17:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428129.1650825 (Exim 4.92) (envelope-from ) id 1x8toR-0006Qs-C6; Tue, 22 Sep 2026 06:17:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428129.1650825; Tue, 22 Sep 2026 06:17:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8toR-0006Ql-8t; Tue, 22 Sep 2026 06:17:07 +0000 Received: by outflank-mailman (input) for mailman id 1428129; Tue, 22 Sep 2026 06:17:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8toQ-0006Qf-M8 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:17:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8toP-008e8k-OC for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:17:05 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab21d50-bab6-0a2a0a5309dd-0a2a4503887c-40 for ; Tue, 22 Sep 2026 08:17:05 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab21d61-fae8-0a2a45030019-4a7de18cfa5f-3 for ; Tue, 22 Sep 2026 08:17:05 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd38e0e5dso53037235e9.2 for ; Mon, 21 Sep 2026 23:17:05 -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 ffacd0b85a97d-48862773ee0sm2354674f8f.6.2026.09.21.23.17.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 23:17:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790057825; x=1790662625; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=XDy25AsiPQQ0/kOXjGObCG5owFOtemmkgGYA1xSR6mY=; b=NM3aVv0q0QphDegy/LRnuRSTSxAxFqDw4q/8dz4E9AIUCfcQanPfw2jVcL6tiqQh9G uFAITOOuj76BhR2HnjeCOOIBfCP6nMcefjLEOeL/kn1hhEIhzSR9F6j7pnO8aeKf886q BZYfGAjKNQPunISHENzSNXhzjBnTA+WZS6Tn+r2AuFi0++ecnLpammUIIkPAkuXha1TF KvhslKjW+Ac4qp4LOmNOy5dhENm9kYHhXV0dm2/iyergPZZzl8xK32VYxDTR82h0NujO LPP80oq6C0p1Q+3KdiixYugmjj/0WzIlKWPHTniEup0S0h9xZJ/d90sU5iQiP1apTsaU h/hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790057825; x=1790662625; h=content-transfer-encoding:content-type: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:content-type; bh=XDy25AsiPQQ0/kOXjGObCG5owFOtemmkgGYA1xSR6mY=; b=CoTv5ZFFJb7qzSvoR1AMQiJmaAAuAoghSLQ7FkPbCGznk05tX+mACc1lyiRHmu4vFc lTBvEDVya13eWVprcaQDo/56ECvPO8QBqU3I9033eUSIfK40HGPDj411AmqvnoOyw/wQ eFpeoC4lw+jd40QhXKPl2IAJCyJyyu1V1uDSPXtyKdJ3j/BnFEODf+LLxahs49mBlCee X+NnBAhdb3ZmyB3owGIYAiUU+K3BvtOCy7n2xz7amoT6K3CbfZkIyvzeU5E2CWO7HBUR rdZSzkleTIHse0YNA741bCo2oOToKk54lCqSfmIQaZQ6x4YfeIKs+fAIMTLCatz4YJfr zz/A== X-Forwarded-Encrypted: i=1; AKwUvBwxzaq8wPwzHCg60FigcOvCkgE+UZevyWoYS01vxlYkjweYlNb49ft/nFW8YcD5FeepZMOtQoVozl8=@lists.xenproject.org X-Gm-Message-State: AFuF++lkUDpASSBoMkCwDz6RBtDShkIWf4rBDVkBW4NQBMXR38Pcq3uu WZFNv6ZRE5z1rNxIBIIDE5b+FsIHdOOymp2DLJo9//Tb9xxODLgdk+zIn6nucdT2/A== X-Gm-Gg: AYBFou0/WpZuhmG7A8nCtm5NnBorXxOH1es8ZAEvcl45zxS0pa+fblm0API82BGGQa5 x4ltYIc6+p4jW9KhrFtWelYhTBfMbD+zcquZZdRCP5akBd8QAm15qhPAKjRgmLXu7iB2ZGh9OT6 TcwvqCITOjz/WV3nTDEQTPNgl04EdvvCrUV5X2r7QbynRKAsaqOFAnCWdVxWT7gq8IzYpm+64gI 0dAsU19xgqRr2tkBgjD6I18uOoLnlUq3J/H2iqHpvaxABcVqI5SxK5Hw+1ipwL1G8c60d8H1h0b EKcLBRlRprCcC38m8l2FBihNRM2zz26vp/qgqd+/B43xHtawOICOtQOyeHexy2oJhW2M5msaLZ3 FzPO7VL5UySGqmwB9M9/RDbrOQAsd4KDj/qRT9p4XVrcxLd9VRPhnNEmGj+PXcrF8KCpkk2jEQp 39DUSlwTPce6dFcy8eqYZ0SDIyiAoFhou+vOCWZzDO1DZrZxEq18Ao6vfVjJDjqzc2VOhJsuSNQ ZyhXw96K6LYNaYX/+lVQ5c1bIjtZXAs7fKgNNx7Ja9Vj4+yEtUkXl3/sBSpGen97DYo6p76 X-Received: by 2002:a05:600c:3493:b0:49f:bd3c:bc21 with SMTP id 5b1f17b1804b1-49fc573b55emr175518145e9.28.1790057824830; Mon, 21 Sep 2026 23:17:04 -0700 (PDT) Message-ID: <2be442bd-6f1c-4790-ba57-a98c481ab07f@suse.com> Date: Tue, 22 Sep 2026 08:17:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] x86/nSVM: Check injected event consistency To: Abdelkareem Abdelsaamad Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <20260921170757.3244601-1-abdelkareem.abdelsaamad@citrix.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: <20260921170757.3244601-1-abdelkareem.abdelsaamad@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1790057825-6E8CD4E9-5213A339/0/0 X-purgate-type: clean X-purgate-size: 2426 On 21.09.2026 19:07, Abdelkareem Abdelsaamad wrote: > On 07.09.2026 08:36, Jan Beulich wrote: >> On 06.09.2026 15:22, Abdelkareem Abdelsaamad wrote: >>>>>> @@ -320,6 +320,44 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) >>>>>> svm_dump_sel(" TR", &vmcb->tr); >>>>>> } >>>>>> >>>>>> +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, >>>>>> + uint8_t vmcb_injected_vector) >>>>>> +{ >>>>>> + switch ( vmcb_injected_vector ) >>>>>> + { >>>>>> + case X86_EXC_DE: >>>>>> + case X86_EXC_DB: >>>>>> + case X86_EXC_BP: >>>>>> + case X86_EXC_UD: >>>>>> + case X86_EXC_NM: >>>>>> + case X86_EXC_DF: >>>>>> + case X86_EXC_TS: >>>>>> + case X86_EXC_NP: >>>>>> + case X86_EXC_SS: >>>>>> + case X86_EXC_GP: >>>>>> + case X86_EXC_PF: >>>>>> + case X86_EXC_MF: >>>>>> + case X86_EXC_AC: >>>>>> + case X86_EXC_MC: >>>>> >>>>> Is #MC valid to inject without CR4.MCE set? >>>> The testing I performed (see previous comment) does not show that set CR4.MCE >>>> is required for the valid injection. >>>>>> + case X86_EXC_XM: >>>>> >>>>> As before: Doesn't #XM (AMD: #XF) require CR4.OSXMMEXCPT to be set? >>>> The testing I performed (see previous comment) does not show that set CR4.MCE >>>> is required for the valid injection. >>> I meant ..does not show that set CR4.OSXMMEXCPT is required. >>>>> >>>>> Again as before: Is #SX really permitted without any constraints? You did >>>>> reply to both comments on v3, but that outcome isn't reflected here. The >>>>> more that what you said there could equally apply ... >>>> The testing I performed (see the first comment) does not show that set CR4.MCE >>>> is required for the valid injection. >>> I meant ..does not show that any CR4 bit is required. >> >> And I didn't mention CR4. I intentionally said "without any constraints". > I believe the Security Exception (Vector 30) is architecturally valid on AMD > Naples (EPYC 7001) and Rome (EPYC 7002) platforms. Event injection of vector 30 > then does not require specific guest enablement I am aware of. IOW another one of those cases where an unaware guest can be sent an exception which may end up killing that guest? Hmm... Not your fault of course, yet still problematic. May want making explicit in the description (maybe even a code comment) then, I think. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:21:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:21:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428135.1650834 (Exim 4.92) (envelope-from ) id 1x8tsQ-0007yx-RP; Tue, 22 Sep 2026 06:21:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428135.1650834; Tue, 22 Sep 2026 06:21:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8tsQ-0007yq-Ob; Tue, 22 Sep 2026 06:21:14 +0000 Received: by outflank-mailman (input) for mailman id 1428135; Tue, 22 Sep 2026 06:21:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8tsP-0007yk-T7 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:21:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8tsO-004QvI-W3 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:21:13 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab21e48-bab6-0a2a0a5309dd-0a2a45049ccc-14 for ; Tue, 22 Sep 2026 08:21:12 +0200 Received: from [74.125.228.145] (helo=mail-ej2-f17.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab21e58-b57f-0a2a45040019-4a7de491802d-3 for ; Tue, 22 Sep 2026 08:21:12 +0200 Received: by mail-ej2-f17.google.com with SMTP id a640c23a62f3a-c29d50b7cf9so557919766b.2 for ; Mon, 21 Sep 2026 23:21:12 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2a9c62dc31sm34293066b.59.2026.09.21.23.21.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 23:21:10 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790058072; x=1790662872; darn=lists.xenproject.org; h=content-type:in-reply-to:autocrypt:from:content-language:references :to:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=6C7LIWiXbu4EQkQm8bd44AKIo0GAwrlrmy/9RmiMiWE=; b=DwEDeKqDPjTlObJHv12wJY2BqJgQRVPuwliBGwo6RqsSxarhbj5ulCPbJHaldzrkEs HyjkHSa0PiFQQKhDT2uncJSuaVDABlwFMHLcCHF14752WHNqcmwvhth4gJL/83xczZyz rgyziJzBbHeDS2aLB0HTRUaCiz/6XDfaL99dCeiGEDAnTmkkzDtfcctJ2NCcvQvp+sey tva3BYcNw+tJTZoMccTq861GQieOyET1CvpUSpV6VZ9L4X70s0OPizGKZ2bY0iMjV6n4 8TBOTlAur/ymWPORRiJtTEprBPBpu1pBa4SYk6oDyGaAAaLTlIa+Us3POQ0KMudFVloY Cs8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790058072; x=1790662872; h=content-type:in-reply-to:autocrypt:from:content-language:references :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 :content-type; bh=6C7LIWiXbu4EQkQm8bd44AKIo0GAwrlrmy/9RmiMiWE=; b=CQsB4y9jIJlSBrvzM8MgWKT4UANbwzZFr6ucQtfduW6/F00FyKqngrOeiTRIboHDyk cBeW4WbqW1KqivYN4Az+RWFIyQzPRwF0Qgpl1f80u6vxgouEXvkc2qonSybKzx6yEHIM N1o8GC+MqL2TwkutoWzxvARU9Ewj6KyHcE4vAsAonjdygVjlfLHhI3AJRNoYTAgcGQL4 6j48DLi29POvnHfyDwD7FMJYGQpYrkbzsi+DuPlSBLhncxzP18wjwE5+Qakw/Ot/FZrh bAu955XRuQGpcUdcJz07qJFbkdRlTbITYHbIbIugJl08Jbd/j7LYPN0Ef2Z7FTFSyqor mvUA== X-Forwarded-Encrypted: i=1; AKwUvBySF9gpJAARvDfhdjd4dYdmCHpr7wgXUBB4VFtPg4d7HsvxpcSlM+SrFTCViS8/rFlwtai4TuPLv9I=@lists.xenproject.org X-Gm-Message-State: AFuF++kNOtGXPtan0agE95kNKVWiLSUYynTxkb8GufW3yG8nieFtrL6x p6WrxKdxd8wZPVkL9CROujM9/t8jVRgcnSgGOT08UiRsjqLEIDdQFrQicyzRsa/HDt0= X-Gm-Gg: AYBFou0zN2w5YrIcy912bJo/ibIg7MckbDWwJgMC5ECIiZEAENmVAcZ6x1/uiBx83zV vqm9OxMNYfM5GF4NejkpPXw1HpmRQSuiiYyStsZEcGtLj8F93V5WztX5kcqyimP+94s1OhBg7Ej FOfbFXnh2aSyQpZsjwdh5ADTFU9MTi8cTA/MM7rK8MLw1+oHif9tT8UfsCtCgH2jTMDAsyhomMV AIYa48grMa/7VOMlSMWWeiFe6JL95vza9RXU1T5x4iMByXc3SfbhkH0orEysH562eerXOE6oV0/ XuKQoTrGQnwK4spRMyQjCwsRl3LnKr4M7MEiA3W+sm+UaEsn7hJYjQASTsDQ0YYRWiZQMpM51qT zUtX7A3JcaHuNkdoKPgjSi/eYyvHBG6ofO3p8HeG/k2HNfpAukg4UxPZea8tTTt5+oKNy8V6ph0 da8Pf/q+6R+Gmxadd66updmL2yYkK256rb98hlXXlEQM+m1DFvnlc1kDLhGFYML8xukbvAJ5//j 74geEWXZc0NszffRct2X/6ykkQ+OI60fwOjJWOJtqxcOLJoK3uXSVo/GD6BuVfPZC9xf5lzTrjd 8AvbZ2O7kzyRCa0CEz4g931w X-Received: by 2002:a17:907:6092:b0:c29:4b79:e417 with SMTP id a640c23a62f3a-c2a157fab34mr1084149866b.16.1790058072157; Mon, 21 Sep 2026 23:21:12 -0700 (PDT) Message-ID: <624eb81f-9134-4181-9021-b315cf2fb10d@suse.com> Date: Tue, 22 Sep 2026 08:21:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] stubdom: remove pciutils To: Samuel Thibault , Jan Beulich , xen-devel@lists.xenproject.org, Anthony PERARD References: <1f814c72-6fa2-4177-8da0-e17e0406e473@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------xrhDtI5LTaLjWk0MmX4sWtQV" X-purgate-ID: tlsNG-ebf023/1790058072-518D1B50-522A0190/35/110847 X-purgate-type: clean X-purgate-size: 11289 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------xrhDtI5LTaLjWk0MmX4sWtQV Content-Type: multipart/mixed; boundary="------------btL7pXQBiFTagmflgxX0ZSjE"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Samuel Thibault , Jan Beulich , xen-devel@lists.xenproject.org, Anthony PERARD Message-ID: <624eb81f-9134-4181-9021-b315cf2fb10d@suse.com> Subject: Re: [PATCH 2/4] stubdom: remove pciutils References: <1f814c72-6fa2-4177-8da0-e17e0406e473@suse.com> In-Reply-To: Autocrypt-Gossip: 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 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------btL7pXQBiFTagmflgxX0ZSjE Content-Type: multipart/mixed; boundary="------------pyS0kHsSAoI1xImeFrSWoHlN" --------------pyS0kHsSAoI1xImeFrSWoHlN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjIuMDkuMjYgMDc6NTgsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4gSsO8cmdlbiBH cm/DnywgbGUgbHVuLiAyMSBzZXB0LiAyMDI2IDE1OjA3OjM2ICswMjAwLCBhIGVjcml0Og0K Pj4gT24gMTkuMDkuMjYgMTg6NTcsIFNhbXVlbCBUaGliYXVsdCB3cm90ZToNCj4+PiBJIGhh dmUgc3VibWl0dGVkIHRoZSBwY2l1dGlscyBNaW5pT1MgcG9ydCB0byB1cHN0cmVhbSAod2hp Y2ggSSBzaG91bGQNCj4+PiBwcm9iYWJseSBoYXZlIGRvbmUgMTggeWVhcnMgYWdvIDopDQo+ Pj4NCj4+PiBodHRwczovL2dpdGh1Yi5jb20vcGNpdXRpbHMvcGNpdXRpbHMvcHVsbC8yMzUN Cj4+PiBodHRwczovL2dpdGh1Yi5jb20vcGNpdXRpbHMvcGNpdXRpbHMvcHVsbC8yMzYNCj4+ Pg0KPj4+IEphbiBCZXVsaWNoLCBsZSBtZXIuIDE5IGFvw7t0IDIwMjYgMDg6NDA6MzcgKzAy MDAsIGEgZWNyaXQ6DQo+Pj4+IE9uIDE4LjA4LjIwMjYgMjM6NDIsIFNhbXVlbCBUaGliYXVs dCB3cm90ZToNCj4+Pj4+IErDvHJnZW4gR3Jvw58sIGxlIG1hci4gMTggYW/Du3QgMjAyNiAw Nzo0MzozNCArMDIwMCwgYSBlY3JpdDoNCj4+Pj4+PiBPbiAxNy4wOC4yNiAxODozNywgU2Ft dWVsIFRoaWJhdWx0IHdyb3RlOg0KPj4+Pj4+PiBKdWVyZ2VuIEdyb3NzLCBsZSBsdW4uIDE3 IGFvw7t0IDIwMjYgMTA6MjQ6MDIgKzAyMDAsIGEgZWNyaXQ6DQo+Pj4+Pj4gV2hhdCBhYm91 dCBhZGRpbmcgYSBjb21tZW50IHRvIHRoZSBzdHViZG9tIE1ha2VmaWxlIGluIGEgc2VwYXJh dGUgcGF0Y2gsIGxpa2U6DQo+Pj4+Pj4NCj4+Pj4+PiAjIHBjaXV0aWxzIHN1cHBvcnQgaGFz IGJlZW4gcmVtb3ZlZCB3aXRoIGNvbW1pdCA8Y29tbWl0LWlkPiwgcmV2ZXJ0IHRoYXQgcGF0 Y2gNCj4+Pj4+PiAjIGluIGNhc2UgaXQgaXMgbmVlZGVkIGFnYWluLg0KPj4+Pj4+DQo+Pj4+ Pj4gSSB0aGluayB0aGlzIHdvdWxkIGJlIHByZWZlcmFibGUgb3ZlciB1bnVzZWQgYW5kIHBy b2JhYmx5IGJpdC1yb3R0ZW4gY29kZSBpbg0KPj4+Pj4+IHRoZSByZXBvc2l0b3J5Lg0KPj4+ DQo+Pj4gV2UgY2FuIHBvaW50IHBlb3BsZSB0byBwY2l1dGlscyB0aHJvdWdoIHN1Y2ggYSBj b21tZW50Lg0KPj4+DQo+Pj4gSsO8cmdlbiBHcm/DnywgbGUgbWVyLiAxOSBhb8O7dCAyMDI2 IDA5OjEyOjAwICswMjAwLCBhIGVjcml0Og0KPj4+PiBPbiAxOC4wOC4yNiAyMzo0MiwgU2Ft dWVsIFRoaWJhdWx0IHdyb3RlOg0KPj4+Pj4gSSBkb24ndCBzZWUgd2h5IGl0IHdvdWxkIGJl IGJpdC1yb3R0ZW4sIHNpbmNlIHRoZSBwY2l1dGlscyB2ZXJzaW9uIGluDQo+Pj4+PiB1c2Vk IGlzIGZpeGVkLCBpdCdzIGEgbGlicmFyeSB0aGF0IGhhcyBhIHF1aXRlIHN0YWJsZSBBUEks IGFuZCB0aGUgcGNpDQo+Pj4+PiB4ZW4gaW50ZXJmYWNlIGlzIHN1cHBvc2VkIHRvIGtlZXAg YmFja3dhcmQgY29tcGF0aWJpbGl0eS4NCj4+Pj4NCj4+Pj4gVGhlbiBJJ2QgcmF0aGVyIGFk ZCBpdCB0byBNaW5pLU9TIChwcm9iYWJseSBiZWhpbmQgYW5vdGhlciBDT05GSUcgb3B0aW9u KSB0aGFuDQo+Pj4+IGhhdmluZyBpdCBpbiB0aGUgWGVuIHRyZWUuDQo+Pj4NCj4+PiBNbW0s IGJ1dCBob3c/IFdlIGRvbid0IHJlYWxseSB3YW50IHRvIHB1bGwgdGhlIHdob2xlIHBjaXV0 aWxzIGJ1aWxkIGludG8NCj4+PiBtaW5pLW9zIDopDQo+Pg0KPj4gVEJILCBJIGRvbid0IHNl ZSB3aHkgdGhlIHdob2xlIE1pbmktT1Mgc3BlY2lmaWMgc3R1YmRvbSBtYXplIHNob3VsZCBi ZSBpbiB0aGUNCj4+IFhlbiByZXBvc2l0b3J5Lg0KPiANCj4gSXQgdXNlZCB0byBiZSBhdCBs ZWFzdCBiZWNhdXNlIFhlbiBpdHNlbGYgd2FzIHVzaW5nIHN0dWJkb20gZm9yIGlvZW11Lg0K DQpJdCB1c2VkIHRvIGJlIHRoYXQgd2F5IGJlY2F1c2UgTWluaS1PUyB3YXMgaW5pdGlhbGx5 IGEgcGFydCBvZiB0aGUgWGVuDQpyZXBvc2l0b3J5Lg0KDQpUaGlzIGlzIG5vIGxvbmdlciB0 aGUgY2FzZS4NCg0KPiBOb3dhZGF5cyBzdHViZG9tLWlvZW11IGlzIGF3YXksIGJ1dCBzdHVi ZG9tLyBzdGlsbCBidWlsZHMgeGVuc3RvcmUsDQo+IHNvIGl0IG1ha2VzIHNlbnNlIHRoYXQg aXQncyB4ZW4gdGhhdCBidWlsZHMgaXQgYWxvbmcgYnVpbGRpbmcgdGhlDQo+IG5vbi1zdHVi ZG9tIHZlcnNpb24uDQoNCkkgYWdyZWUgaXQgbWFrZXMgc2Vuc2UgdGhhdCB4ZW4gaXMgdHJp Z2dlcmluZyB0aGUgYnVpbGQsIGxpa2UgaXQgaXMgZG9pbmcNCml0IGZvciBlLmcuIHFlbXUu IFFlbXUgaXMgYSBnb29kIGV4YW1wbGUgaG93IGl0IHNob3VsZCBiZTogYSBjb25maWd1cmUg Y2FsbA0KYW5kIHRoZW4gYSBtYWtlIGNhbGwsIGJvdGggdXNpbmcgdGhlIHFlbXUgYnVpbGQg bWVjaGFuaXNtcy4NCg0KQnV0IGhhdmluZyB0aGUgbm9uLVhlbiBsaWJyYXJpZXMgcmVsYXRl ZCB0byBNaW5pLU9TIGFuZCB0aGUgcmVsYXRlZCBwYXRjaGVzDQp0byBiZSBhYmxlIHRvIHVz ZSB0aGVtIHdpdGggTWluaS1PUyBpbiB0aGUgWGVuIHRyZWUgaXMgbWFraW5nIHRoaW5ncyBt dWNoDQpoYXJkZXIgdGhhbiB0aGV5IHNob3VsZCBiZS4NCg0KQnVpbGRpbmcgYSBYZW5zdG9y ZSBzdHViZG9tIHNob3VsZCBqdXN0IHRyaWdnZXIgdGhlIE1pbmktT1MgYnVpbGQgd2l0aCBz b21lDQpjb25maWd1cmF0aW9uIG9wdGlvbnMsIGluY2x1ZGluZyB0aGUgcG9pbnRpbmcgdG8g dGhlIFhlbnN0b3JlIHNvdXJjZSBkaXJlY3RvcnkNCmFuZCBhIG1ha2UgdGFyZ2V0IGZvciB0 aGUgWGVuc3RvcmUgbWFrZSBpbnZvY2F0aW9uLg0KDQoNCkp1ZXJnZW4NCg== --------------pyS0kHsSAoI1xImeFrSWoHlN Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------pyS0kHsSAoI1xImeFrSWoHlN-- --------------btL7pXQBiFTagmflgxX0ZSjE-- --------------xrhDtI5LTaLjWk0MmX4sWtQV Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmqyHlYFAwAAAAAACgkQsN6d1ii/Ey/4 AAf/VJ9kvF9fZ0ZLXhCk38AeojDuFe92yVFmI6iyTYqtU4FqWWo5Va3OvYpI0QesadQJmPutY2wq pX4caCENFvXdO8dr3XWGc8XsPi6JxOresOwS/7UwkDtshZ8V2LKvQa7w5P8QDVMXdRqXaxLpI+a0 I5a2lPEAHb5lheIEAuue9kyPCE6MWQupuJMDKexGy/MAFCN71Q3MI7ILkBPLITD0Cq39/DqeUnIg aguERjbTrsezc6DXHEyKauEBh1XzmeojX2s2N6OyTvajpTREvlVTiFaK8Qh9jSLpScjbkRx3FOKg AjfpNNYAj7/g6FadfVBD21aWtN6xlWN6raZLCGGfxA== =yXTL -----END PGP SIGNATURE----- --------------xrhDtI5LTaLjWk0MmX4sWtQV-- From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:24:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:24:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428143.1650843 (Exim 4.92) (envelope-from ) id 1x8tve-00005E-Ai; Tue, 22 Sep 2026 06:24:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428143.1650843; Tue, 22 Sep 2026 06:24:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8tve-000050-7Y; Tue, 22 Sep 2026 06:24:34 +0000 Received: by outflank-mailman (input) for mailman id 1428143; Tue, 22 Sep 2026 06:24:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8tvc-00004u-Gf for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:24:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8tvb-004RUU-QO for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:24:31 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab21f12-e002-0a2a0a5209dd-0a2a4503872a-46 for ; Tue, 22 Sep 2026 08:24:31 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab21f1f-fae8-0a2a45030019-4a7de14cacab-3 for ; Tue, 22 Sep 2026 08:24:31 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f635552aso3066283f8f.2 for ; Mon, 21 Sep 2026 23:24:31 -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 ffacd0b85a97d-48862795232sm2477190f8f.32.2026.09.21.23.24.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 23:24:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790058271; x=1790663071; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=+i/FLEpoYM3jyVxrmr+96M+gRgikrqxasWb8sYr+7H8=; b=Q74m+fWe2mbDj/ZvUpVAXVh8dNyWA/suP4iCoy4qYHommLoqE+dVqsvKKgwoOlzMw7 0+9JxmB6wTX3Dyuc6f/vqXYQaRwY5aaNRX1hzl/oU+d53Yl62fvs4C/wFptNH62QzIgW 3A7DjjHTVMCXxF/PoizgbaRhyuQSz6tXUjRXY4QfMJf2YUIX97bgzPnYbWS+DLv+i67k Nqgs2tn13ZKw98ybiOalJo3/zC/8pkdtVXpPFLsFINZB8LLHGFFW6r9Xd4FIjgoSqVSj VD33Rp78ojNJz4ejraMWn8KrMHaKQmUti+UeQGv3Pan43hI2FnGYlK75e083VPUqW0k2 viFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790058271; x=1790663071; h=content-transfer-encoding:content-type: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:content-type; bh=+i/FLEpoYM3jyVxrmr+96M+gRgikrqxasWb8sYr+7H8=; b=ZSM5nt4X0LzyF1o1tLvSQF2krYDDa2ziTV8COfFH7hSZRhBt8/kGBMagahjK/mvRZM RkZ9J7M83IWki6SODSwURqVByIjlZ8vLxebZgnCUfLjgxdIA0dkZaXJZV20g+4xqFJOa VYh+W5WwtS4louMCTa5fuxiKcLuR2Ti7efjKa7WKTlCRo/NaUsVdsWAQjXXE7q3Mi51X dmQWqq3JSIB/r3PQDlAtWxmF9Xao652ipDsClDIvIDZulx20YoCMkTROySmZm1zhywa5 Cfdc/4gCQw/cqyz+G7UPnbz+IgK26r7ppJaNfdHP9gQUJdaN1OWfVcGuWkagA2L+/MrU SCUQ== X-Gm-Message-State: AFuF++lrSxtJZmIAgqVs7WlhYfUYSka+srLoHe0IBMufodxVvLJvn7HJ KmMCEw8Tg5TpWtfQ/Is5CMHA87Dwa+x5lgdcnyjzhs3MdX/7drsGGbupCHNPATg6WA== X-Gm-Gg: AYBFou0f9xZ6L7Jh2jeEtRgBXdw8hlBkIrGHPoandS69hgGufPVMYD2tkQg9sByu1z5 GLwUvgNt+zOoUWYodsPtzJBkR8KbEw+CKJv0oaJERXGWvYCIOO3mGFVBkxOmee8UUhjNYl4F9Ts A3LXf5a6nfoAS4A51XQ2pax6cvxaGTx0Suh1uG8nJA+HBXalvUy0eNu7Jenxi8WdF4/fQrpYAUD 0m2PfLa4x30ZZZRjLR7sHRo5agxjcK3MV1R9tahUZDt75QcgQ7iEEReMZOV4VWE030uqR02zCpu zKUKDsCvdKgpEn4dPspddWeOOQrMaUQRJp8f8uAXCca6KiDbbG+UHpzXNBQw5aogfNC0IM3GHgN RVcWAR2UHs/5/IDFXz0OlcRU91YbzYmcfyp7PGsCQf1AJ5qsnL+fmEEUB/+Ld6k0WlEOXRY+D0p 5BVRGKFofIG3EC3wghyuhbU0tFdWaTC0SUakYBKRQBrxFur3Edsg3Cm4kQPDl7cDsTAnOY+GV9e /gsnX+mEiANvewUWOU6FT7/CTv5tFjz9ZUAd38OqjtRxD1zJ5KuREn1xoKwig== X-Received: by 2002:a5d:6f05:0:b0:487:d7e:52c7 with SMTP id ffacd0b85a97d-4871e255cf1mr16460189f8f.19.1790058271144; Mon, 21 Sep 2026 23:24:31 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 08:24:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> <450d0c5e-2101-4b1c-98fd-2f438bd0ccf3@suse.com> <1790010225.8631fc262581453bbf619ec5b2062170.1a0c4ec74f000072c4@vates.tech> 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: <1790010225.8631fc262581453bbf619ec5b2062170.1a0c4ec74f000072c4@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1790058271-750864E9-FE9BCA50/0/0 X-purgate-type: clean X-purgate-size: 5266 On 21.09.2026 19:03, Baptiste Le Duc wrote: > On 2026-09-21 17:26:47+02:00, Jan Beulich wrote: >> On 10.09.2026 11:34, Baptiste Le Duc wrote: >>> @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) >>> return false; >>> } >>> >>> +/* >>> + * Svade and Svadu extensions represent two schemes for managing the PTE A/D >>> + * bits. When the PTE A/D bits need to be set, the Svade extension indicates >>> + * that a page fault will be raised. In contrast, the Svadu extension supports >>> + * hardware updating of the PTE A/D bits. >>> + * >>> + * There are 4 possible combinations of these extensions in the device tree. >>> + * The default hardware behavior for each is: >>> + * >>> + * 1) Neither Svade nor Svadu present in DT => It is technically unknown >>> + * whether the platform uses Svade or Svadu. Xen should be prepared to >>> + * handle either hardware updating of the PTE A/D bits or page faults when >>> + * they need updating. In that case, Xen assumes Svade because it's >>> + * harmless if the platform is actually Svadu, while assuming Svadu on real >>> + * Svade hardware risks an unhandled page fault. >>> + * >>> + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. >>> + * >>> + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. >>> + * >>> + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off >>> + * at boot time by setting A/D bits. To use Svadu, the supervisor must >>> + * explicitly enable it using the SBI FWFT extension. >>> + * >>> + * The Svade extension is mandatory and the Svadu extension is optional in the >>> + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose >>> + * option 3. Platforms aware of the profile can choose option 4, and Xen won't >>> + * get the benefit of Svadu until the SBI FWFT extension is available. >>> + * >>> + * In other words, hardware manages the A/D bits on its own only in case 3, in >>> + * all the other cases software has to preset them. Instead of open coding this >>> + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is >>> + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. >>> + */ >>> +static void __init riscv_resolve_ad_scheme(void) >>> +{ >>> + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); >>> + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); >>> + >>> + /* Case 3: leave the A/D bits management to hardware. */ >>> + if ( svadu && !svade ) >>> + return; >>> + >>> + /* Case 4 */ >>> + if ( svadu && svade ){ >>> + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ >> >> Nit (style): Brace placement. > Sorry for that. I will fix that in v3. >> Furthermore this is written in a way which Misra would call "dead code". I'd >> like to suggest (leaving out comments): >> >> if ( svadu ) >> { >> if ( !svade ) >> return; >> >> if ( !sbi_probe_extension(SBI_EXT_FWFT) ) >> printk(...); >> } > I assume you are referring to Misra C:2012 Rule 13.5 "The right operand > of a logical && or || operand shall not contain persistent side effect" > > If yes, IMO, I think it doesn't apply here as `svade` is evaluated > before the `if` so there is no side effect that wouldn't have been > executed in case of svadu=false. No, there's nothing side-effect-ish here. With "svadu && !svade" in the first if(), the rhs of "svadu && svade" in the second one is dead code: Things would function the same with it dropped. >>> + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" >>> + "RISC-V: Defaulting to software A/D updates (Svade).\n" >>> + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); >> >> Nit (style): Indentation (in multiple ways). Furthermore XENLOG_* needs >> repeating after every newline. >> >>> + } >>> + } >>> + >>> + /* Cases 1, 2: Xen assume Svade to be enabled */ >>> + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); >> >> Isn't this a lie (to ourselves) then? > If you are talking about case 1: > [1] Yes, it's technically a lie for boards shipped before > the svade/svadu extension was ratified (e.g., HiFive Premier P550). > These extensions merely formalized a mechanism that already existed in > hardware. Wait, how do you know this for _all_ boards anyone may ever have made? And for all qemu (and alike) versions which supported RISC-V? > [2] For boards that do support svade, we could enforce DT > declaration by adding it to `required_extension` as they are > explicitly supporting it. However, doing so would cause boards > without svade/svadu support (as described above) to hit a panic > during boot. > > So in both case ([1], [2]), the svade extension exist either implicitely or > explicitly. Therefore, force it doesn't compromize anything. If, despite my comment above, this is indeed what is wanted, I think it requires a little more commentary. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:26:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:26:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428149.1650851 (Exim 4.92) (envelope-from ) id 1x8txb-0000bC-Ki; Tue, 22 Sep 2026 06:26:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428149.1650851; Tue, 22 Sep 2026 06:26:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8txb-0000b5-Hm; Tue, 22 Sep 2026 06:26:35 +0000 Received: by outflank-mailman (input) for mailman id 1428149; Tue, 22 Sep 2026 06:26:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8txa-0000au-5q for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:26:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8txZ-004Rnx-Ie for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:26:33 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab21f8f-8faa-0a2a0a5109dd-0a2a4506e306-24 for ; Tue, 22 Sep 2026 08:26:33 +0200 Received: from [140.77.166.138] (helo=sonata.ens-lyon.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab21f99-195a-0a2a45060019-8c4da68ab53e-3 for ; Tue, 22 Sep 2026 08:26:33 +0200 Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id 020CEA1B39; Tue, 22 Sep 2026 08:26:33 +0200 (CEST) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_dzSoLLs6mJ; Tue, 22 Sep 2026 08:26:32 +0200 (CEST) Received: from end (unknown [212.133.41.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id 66F2FA1AB4; Tue, 22 Sep 2026 08:26:32 +0200 (CEST) Received: from samy by end with local (Exim 4.100) (envelope-from ) id 1x8txV-00000005pQf-05Yy; Tue, 22 Sep 2026 08:26:29 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1790058393; bh=pjuFor96sFNkkiXu5u9PhE8S37iExvNJpi6S87/8E8Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cxLPVxLonV/K5AfnmZ7jXLQPlqlUOQ7jbeT1Z90vNmAnF0Ubm5FneGBvetzhDvY+8 YdPfmrye6sNuCeouENKf/WqyRtcIqlvMeHHt4JmCtBMgMV/CbT9k1VTJbPdbpUEnLG TUyt1WpqYlXwqHKPrxDHehIxna+Axl6ULr8lEOjkb9RlHnOhdPhBlyYKPrO+FDMWjj a5gnXLbP4oH36uUQ47lR5d0y5NAZpL7zC4vyGoaxNrHgVNG1bI3nku3BItGMzmWyd/ Vwv+fB3kXuRDKe7anmLhLeOwJbNSNrPYmMiqJ3kq6LHPIsY6niMRs7KlGi4efvBmqD soppYtNMGlhjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1790058392; bh=pjuFor96sFNkkiXu5u9PhE8S37iExvNJpi6S87/8E8Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pTfyQrcZE4aq9DOaKaX+KbkvSxhSk9wDB734smklqaHddNp/KKAhOj8RXxMzlq20L qypca5C/7bAseDfwyjHVGbsjB58ZsTksbHqVfG/5okPIRXiOJpJnwBpC/ICA9FylvR 6UipEEoqQdYykwnNHJ3X/Vm/eIK8qmayhG+48Jgop7alEo8dPt6FgXAXShCL0mEmnZ V5UCQPLcx5RaR/cEiqAgnaRtu8Ebfkz58RqhcpkB5x3kPC5PBxQpGobaaECRrEo/fX 9gUuvOc+VbEUmPd+uuQuAc6yeKtoRA/VNN14fVUj7BH+VHbcuamwY3ygPsa/PhL7YB IQ10VMT7KdElQ== Date: Tue, 22 Sep 2026 08:26:29 +0200 From: Samuel Thibault To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Jan Beulich , xen-devel@lists.xenproject.org, Anthony PERARD Subject: Re: [PATCH 2/4] stubdom: remove pciutils Message-ID: Mail-Followup-To: Samuel Thibault , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , Jan Beulich , xen-devel@lists.xenproject.org, Anthony PERARD References: <1f814c72-6fa2-4177-8da0-e17e0406e473@suse.com> <624eb81f-9134-4181-9021-b315cf2fb10d@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <624eb81f-9134-4181-9021-b315cf2fb10d@suse.com> Organization: I am not organized X-purgate-ID: tlsNG-16d1c6/1790058393-FE27077B-80C55E08/0/0 X-purgate-type: clean X-purgate-size: 979 Jürgen Groß, le mar. 22 sept. 2026 08:21:09 +0200, a ecrit: > On 22.09.26 07:58, Samuel Thibault wrote: > > Nowadays stubdom-ioemu is away, but stubdom/ still builds xenstore, > > so it makes sense that it's xen that builds it along building the > > non-stubdom version. > > I agree it makes sense that xen is triggering the build, like it is doing > it for e.g. qemu. Qemu is a good example how it should be: a configure call > and then a make call, both using the qemu build mechanisms. > > But having the non-Xen libraries related to Mini-OS and the related patches > to be able to use them with Mini-OS in the Xen tree is making things much > harder than they should be. > > Building a Xenstore stubdom should just trigger the Mini-OS build with some > configuration options, including the pointing to the Xenstore source directory > and a make target for the Xenstore make invocation. Ok, if it ends up being simpler then that's all good. Samuel From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:32:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:32:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428157.1650862 (Exim 4.92) (envelope-from ) id 1x8u3h-0002K9-97; Tue, 22 Sep 2026 06:32:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428157.1650862; Tue, 22 Sep 2026 06:32:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8u3h-0002K1-52; Tue, 22 Sep 2026 06:32:53 +0000 Received: by outflank-mailman (input) for mailman id 1428157; Tue, 22 Sep 2026 06:32:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8u3f-0002Jv-GI for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:32:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8u3e-003Fsu-Ds for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:32:50 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22112-2eae-0a2a0a5409dd-0a2a4509a1a6-0 for ; Tue, 22 Sep 2026 08:32:50 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22112-be1a-0a2a45090019-4a7de14c985e-3 for ; Tue, 22 Sep 2026 08:32:50 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f633cd80so1756274f8f.2 for ; Mon, 21 Sep 2026 23:32:50 -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 ffacd0b85a97d-48862774543sm2789232f8f.11.2026.09.21.23.32.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 23:32:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790058770; x=1790663570; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=2TO59/nBjTVigmtq+fqciQQ+MZL7u5Nzo1s2mKXfA8Q=; b=fV4cq2ARzFDyWS4Fv3YmWcxyFr/sLUIqRU2cjvZNiQb9DygXVb31qZg9g3KA3aO0PA L2MZ0L3dTvuqqxHA/xE2U/e5kKR7A9IpZCYCjzztBjCjP2JHT9912uMMCs0LqPfHfBo2 swAOLBPhgttHTCoPh3uofXKbztOvLsTNWyARH7ZCDonAshjvxtvXKHI2o3lhpSn22n1c lc3mMCxCShGAkiy/AWK9cLwxm1pe2v7uTtPOB0ioflZZl4cCuCwXdGU2qKQt13sEjp5M U3wf0/9OvrCLLISG35U6bUQNJusOY8EN5/qYh/IEvshKx34gw8xTBXdif+eSutiT+cj3 mSlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790058770; x=1790663570; h=content-transfer-encoding:content-type: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:content-type; bh=2TO59/nBjTVigmtq+fqciQQ+MZL7u5Nzo1s2mKXfA8Q=; b=tlR+hOWrQaFm+bT0pRh4G9CKRQb19dPhK7VfF7dMXkCDlCQXzkCJPG4nTVRXr28tdo XONyBsbuB4pYvienU0gmvNe1V/VAoViQtKrLYnIQqCkhYhmGVQRdH0K5FT/PEDgXCIwJ kU+sgYmZmWyIdhGdVQHXeAUytNwh7uUhjt35s8G6nxF94SKBWR8Mxg++E0hvFbd0P0dv ESPp+XzJPIs0834RL85xBB2fZV8WMaBBjjCEywBpC2ZxHOG4p0GjdLIltm1Zd3lYyehk ra+6jEvKvfo85vOcIeM0XMJJR5AGQWQQHzUumldQBKWX+00VOmB0Oys8kBbyEJpv7csy clvA== X-Forwarded-Encrypted: i=1; AKwUvBwlC7U3zrYsfX3HKD441hQMthx+Qt/mNkmJQq5vYjbbxvXMne12q+7g/JmhwPDCt8DMBAMJZWZCfE8=@lists.xenproject.org X-Gm-Message-State: AFuF++kjOwx84r77cxfYsp+qOZwPyeVUooXA+dLVIRWh4I4uhMSeBDzs 36nA/BoGquyQrgKk2xrdWGZLlcHQSxe8p46SgwhS9JReCA4XfcgCrlRIt6iVFfGOFg== X-Gm-Gg: AYBFou3zvno+oPieQ3t6el8IYqVQDVWRDuUHg5LhvmQTEyayEFhdePuvO5pezM3+N2q hc2h0ZycMQ1EVJdhMzIRvd9INXBr0AQk3/r1AqO30hbUNPC2q4ubUoSaHlLyIqWFfWmbjp/BtIh QVajFIXNtIRw1NBP5Wy8pTc/IUyw3AoYnHgsz/2nv7Qi5dcYtmuEcJaEU2WQKQqEblnO0/LlpeP 3Ok2VeXzjg3/Q2h4+L4uB/ECTWjwEie6vfwdllcujKxZ9XKIdzdXX2MSAuTNnph0n19ntTN22AH bsCZowfe3bSFN3B7wUv7I55siSs08V9v0hFmRXNEX0TIIimKCpaHoKIwFJnoXJNbHQmk4ntkojA YlwF9BhKMbUS3/XxgOVtEmHw6bjcA6AWsKXXDq9E/TUWm6CpnUqrgYUSFJ7QuQEYweptYQzxy0I uMJmDRI1/qF+VPJo7kQSlVkjwK0vS315it5WpZECSXGbehctJUxUoI+5dzyU+U859MVzsl+iHWg SKX6iqctiBHUcDaqGgT6kiLANhwi1KR+PhiM0/r5PJhjmhr459hoJC+zT0aXw== X-Received: by 2002:a5d:5d84:0:b0:485:ac0e:6fb2 with SMTP id ffacd0b85a97d-4871e2279f7mr20035744f8f.18.1790058769709; Mon, 21 Sep 2026 23:32:49 -0700 (PDT) Message-ID: <8419536a-5e73-4718-a700-6bce5b8c71f8@suse.com> Date: Tue, 22 Sep 2026 08:32:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file To: Baptiste Le Duc Cc: Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko , xen-devel@lists.xenproject.org References: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> <1790007309.8631fc262581453bbf619ec5b2062170.1a0c4bff57900072c4@vates.tech> 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: <1790007309.8631fc262581453bbf619ec5b2062170.1a0c4bff57900072c4@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1790058770-FD06B034-2E59D5B0/0/0 X-purgate-type: clean X-purgate-size: 2677 On 21.09.2026 18:15, Baptiste Le Duc wrote: > On 8/27/26 5:24 PM, Oleksii Kurochko wrote: >> @@ -389,6 +448,76 @@ int cf_check vcpu_imsic_init(struct vcpu *v) >> return 0; >> } >> >> +/* >> + * Arguments of the imsic_vsfile_local_*() helpers, which are executed by the >> + * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). >> + */ >> +struct imsic_vsfile_data { >> + unsigned int hgei; >> + unsigned int nr_eix; >> + struct imsic_mrif *mrif; >> +}; >> + >> +/* >> + * Execute func() on the pCPU which owns the IMSIC interrupt file func() is >> + * going to work with. >> + * >> + * An IMSIC VS-file is reachable only through hstatus.VGEIN of the hart the >> + * file belongs to, and a guest interrupt file index is meaningless on any >> + * other hart, so such work always has to be done by that very hart. >> + * >> + * The local case runs with IRQs disabled to provide func() with the same >> + * environment it is given when it is called from the function call IPI >> + * handler. >> + */ >> +static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), >> + void *data) >> +{ >> + if ( cpu == smp_processor_id() ) >> + { >> + unsigned long flags; >> + >> + local_irq_save(flags); >> + func(data); >> + local_irq_restore(flags); >> + } >> + else >> + on_selected_cpus(cpumask_of(cpu), func, data, 1); >> +} >> + >> +static void cf_check imsic_vsfile_local_clear(void *data) > I think the remark from Jan to direclty pass the type instead of void > could be applied here. No, the function pointer is passed to ... >> @@ -699,5 +836,27 @@ void imsic_migrate_vcpu(struct vcpu *v) >> if ( v->arch.last_cpu == NR_CPUS ) >> return; >> >> + /* >> + * At this point, all interrupt producers are still using the old IMSIC >> + * VS-file. >> + */ >> + >> + /* >> + * Latch the pCPU the new interrupt file is taken from: vgein_assign() >> + * allocates it from v->processor's pool of guest interrupt files, and >> + * only that hart can access the file afterwards. >> + */ >> + new_vsfile_cpu = v->processor; >> + >> + new_vsfile_hgei = vgein_assign(v); >> + >> + /* We don't support SW interrupt files at the moment. */ >> + BUG_ON(!new_vsfile_hgei); >> + >> + vsfile_data.hgei = new_vsfile_hgei; >> + >> + /* Zero-out new IMSIC VS-file */ >> + imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); ... imsic_call_on_cpu() here, which in turn passes it to on_selected_cpus(). Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:36:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:36:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428164.1650869 (Exim 4.92) (envelope-from ) id 1x8u79-0002pq-M0; Tue, 22 Sep 2026 06:36:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428164.1650869; Tue, 22 Sep 2026 06:36:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8u79-0002pj-JC; Tue, 22 Sep 2026 06:36:27 +0000 Received: by outflank-mailman (input) for mailman id 1428164; Tue, 22 Sep 2026 06:36:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8u77-0002pd-Ir for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:36:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8u76-008hhd-Vv for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:36:25 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab221e0-e002-0a2a0a5209dd-0a2a4505eb56-28 for ; Tue, 22 Sep 2026 08:36:24 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab221e8-4cb1-0a2a45050019-4a7de18caa3b-3 for ; Tue, 22 Sep 2026 08:36:24 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd5462b69so19934965e9.1 for ; Mon, 21 Sep 2026 23:36:24 -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-49fdaa4e47csm55392655e9.1.2026.09.21.23.36.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 23:36:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790058984; x=1790663784; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=ySpO8zLkhZzTz7pj7WmyA9l3Ff2FfjURPFQzBaa68ek=; b=GdunEhu1vU3n75UwkIGmuD8vcmKK4ls+zJN8GC2q/ToJE8DdMWhTKZ69Spt9NyDrxW 8ACNbSaB2CgCmCdt2s84y8a4XZRVh176a6+OSmUHlBXir+xK+V7r9WI9tdxaomih7eAe k9WmMADpgoSKk0KVLq0k4j2f9I1vcjkOo4AurG+KOgltj0+JJcBwWg4oeWIVaLD/5eJY bN5yMmvKmEk0rYzAF/SWOft2NP1zuNElAosworX8i01j5xCdINW93rgXvxWmI2WnnO4R yZPkYq3Mg6xpiWyw8WAHpIKIdWdJiaXc3OErqz6VLcL6unGsJ4ptNJskMgea5QKEcpW0 niHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790058984; x=1790663784; h=content-transfer-encoding:content-type: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:content-type; bh=ySpO8zLkhZzTz7pj7WmyA9l3Ff2FfjURPFQzBaa68ek=; b=TerB9tzxDEr9Zm/NcVX9MIyNPwwCNHc7DwrLywfjSsnCcIn66wioocEKsx7UxBDatQ z6pzxBg5cp0rUL7AFLsuQN2lc3Vrw3cKYcaQ0QM8aveZVNfCOF43Uy8ekunNxLj0sZLT aNhnG+EGzTkRoZZswPKYM8DEOGYN0lLztR2DkFsHJaa19XVnsdflFqUjBFVJamMX28PQ 99CInQRBfkqyYwwinYyNGg46RC2IoUNZy4LyDSoUPobS5nsJRvf9w8HgrCz3WRU4zpcb jjokmbtEXaMuShvaJewac2brE15mzQ5iiEy+5lsaWcHEIGNZf9/Kb2yDTdXXoyQrBtfH eAkQ== X-Gm-Message-State: AFuF++mDOq/dwYk7wdzN8jdyS6/P5mZN1++nSpjVtvlUsuB7TqCpinTf XRNdJ3ex78qmnUgwU4THNZSvIyekGsa5x0fcfoyAjFx3CUcQ/tILTsU+HhKzVd3Yuw== X-Gm-Gg: AYBFou1HpIFPPB3LBeG3GIWmV4lu+1+cXpUEC4QZMsLUDRqMxFNw/TyGm+ccYWfGRPt 3rnhQxEOsjABsKu6WgbydsqcKYXsdP4ZNEIrVLoUTQhbxKOdczjy//nIahGLimEaZufzhIJUt8I yUjnF4NwLdRau8yCbelOWPiYFhODp6HLORAb5Cp/5QVadn9JzISPz72k9m3MPyDpakznmOuJpMk WY/lYdseGeyFoS96urqJj/4jFJq3pd6nyXvo1AN7qvoZ43bG4NxqBR5FZfBVC5Phe6NyYrDp/hX fNcY5q77Beklv1cR/20ZUERS1PbpCqZ8ESu+NUQIonr3K1I8EGYz42vnRXDL2UuvPjQqRxGY77W i7xNQ4jsBn33LVjelDqZAnLIVJMBQEBUZ0PYYn/KvnnCTogto2eUqcVF8O5zk2lMASx2JNINJAj F0mv/105BSlsVN5hJHccEYTdT2iTXD1rqzgwfmfCctx8XpnpiMdHPH/0Hi3PQSDqoVKUXGaBmkm WKeyDO+qeV6E4qHM2JxQziw3oMChpLt/O7WNCrhL6a3RStSGPdoS/J85DMxLU2aF7rolUKngw== X-Received: by 2002:a05:600c:5489:b0:49c:dca4:94c with SMTP id 5b1f17b1804b1-49fc573579amr236387705e9.13.1790058984379; Mon, 21 Sep 2026 23:36:24 -0700 (PDT) Message-ID: <162997df-6c5f-4f1c-b01f-16f6c2e4e0c6@suse.com> Date: Tue, 22 Sep 2026 08:36:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 10/14] ELF/notes: use pointer-to-const by default in ELFNOTE_...() To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <8fe86787-7590-44f1-be4f-461b61d7669b@suse.com> <87fqz26otq.fsf@epam.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: <87fqz26otq.fsf@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790058984-F5EA92A1-BEB482D9/0/0 X-purgate-type: clean X-purgate-size: 1296 On 22.09.2026 03:45, Volodymyr Babchuk wrote: > Jan Beulich writes: >> Not doing so results in a number of Misra rule 11.8 (casting away of >> const-ness) violations. We need to allow kexec to use pointer to non- >> const though, so provide a means to override the default. >> >> For ELFNOTE_NEXT() we can do better and simply re-apply the type of the >> incoming pointer. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/common/kexec.c >> +++ b/xen/common/kexec.c >> @@ -6,6 +6,9 @@ >> * - Magnus Damm >> */ >> >> +/* We're producing ELF notes here. */ >> +#define ELFNOTE_CONST > > Frankly, it feels backwards. When reading this line of code I am > assuming that you are adding constness to ELF notes because you are > defining ELFNOTE_CONST. And I had to check the elf.h to understand that > you are doing exactly opposite. I am pretty sure that other people will > confused by this as well. Well, that's certainly possible. Yet then you or them are asked to make an alternative suggestion. An option I could think of would be to merely rename what is ELFNOTE_CONST right now, to no longer have the word "CONST" in it. ELFNOTE_MODIFIER maybe, albeit that reads a little clumsy to me. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:39:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:39:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428172.1650879 (Exim 4.92) (envelope-from ) id 1x8uAT-0003ad-8b; Tue, 22 Sep 2026 06:39:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428172.1650879; Tue, 22 Sep 2026 06:39:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAT-0003aW-5l; Tue, 22 Sep 2026 06:39:53 +0000 Received: by outflank-mailman (input) for mailman id 1428172; Tue, 22 Sep 2026 06:39:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAR-0003aP-R9 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:39:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uAR-008iIB-2y for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:39:51 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab222ab-bab6-0a2a0a5309dd-0a2a45068b34-36 for ; Tue, 22 Sep 2026 08:39:51 +0200 Received: from [52.101.69.128] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab222b6-195a-0a2a45060019-346545800f7e-3 for ; Tue, 22 Sep 2026 08:39:51 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by DBAPR03MB6565.eurprd03.prod.outlook.com (2603:10a6:10:195::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 06:39:48 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 06:39:48 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r5T3Wwt2O+pfbXn/VONfM1aU9kbmJts/TCCtehrymI3tphR6ve9ve/9c09qPiLRoC4U6U1gMFsXIAtb2TZ6yfbi4HhXtMmEcOIZJ7a50QaKXBDn6PzfZUBKKJvY84LCALEOt2MgkA5Bd/GB4nvonvoQtVkTZ9H6QEDLIul2P/vcLkVu9L+Frq4WsDHxDuMKyXUiWMIYt7tgmpc0gm6KX5HaiUZtt4t7GbPx9TcbtTTJSZw2Jk1EK7OTX5Kv8Xao0xNzEuxhDsjoU+eyiK5OBBPfWTs3yKghkPK2vBJ3iCVz6kgSp2lksQoydtdyUnpwPB9lFpQ7WQSNQu7B0M5aJtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BkE4kVFHXRYexVWKiajm86ZbpkVDEaJuKyl2Ebglm9Y=; b=OeVMO9LBDqMaIRtjmcG/Ep+5FqyH8wLBkII7ZnpSOR82GTUfTEsLYAX+tZYi79o1ECI6KRo11+PRsPc2bTS113hHjXUqvgB23qi59cyLkqJCQCgdnE6jWeTo8yYry5gx0F9eV0ZNkuMKd8+dgaStm6H7QDUEEVTHGN7U2OSPnrma4zH3q+gPLhh4vcRSUs5rxritH9Y35vqFTMnBDJdv7PYZqAm0YXaYkhGu8Su8maeOgBRVd3R6Q6vLhZXE1w6Bz+gz3kudqh5KRUqga9bTbkwLM3S9JyQKSSRWAbj0mFn021dTpw+pKEJ51qEMOcqxSjizrpNVylAJHaT7STMWBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BkE4kVFHXRYexVWKiajm86ZbpkVDEaJuKyl2Ebglm9Y=; b=su5wyfmIQPYXZ/ZeefLUll7WfZpTbLRh3gLsSABgVTBOhEfdZS7i62NZIK2/5k66tqFsmhAvLzFq3LyATwbfS695JassJy3/b81D7q7wTvYfy5dPoniZ6FynhLI2n+VXHDzkJXmzuY6Sia+vWiMHlKDTMpH6oaklZEEbDsTfFzCw0TO+MnzGGD/KmVjkbZDz9yAR/ZbR5/IgVb062t8mXS8ePkcpubRY1Jbh0Z2d/vAgRUxzYWxTu/WWGIeFI8cK4WLter1RBrCR7xRiJJF8Ep0UiJ/NtYfr+A+mpuca5JheVxYrsIPw+eIoWwpzemZOXd+ePeocxHj3WUu/oAonmA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jens Wiklander Subject: [PATCH v4 0/4] xen/arm: Fix eSPI IRQ handling Date: Tue, 22 Sep 2026 09:39:28 +0300 Message-ID: X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA1PEPF00005B7B.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::613) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|DBAPR03MB6565:EE_ X-MS-Office365-Filtering-Correlation-Id: 9aaf9d0d-3bbf-4081-f319-08df18744bd7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|7416014|376014|10067099003|11063799006|6133799003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: DfRSt8qqz9jkmBOTS3juVKaVj8vDWYcl6S1mrqOqoc6uzmIifFTBqdjeQqNaBnUymN9JC6tb0ogWNEkOpTccIuYUTxXcZnKLIkn/AuLwbUOrviEEuMkm5alB/mD4GlPI5rfUjsqQA+pWXJu9400y+VOOKbuvi/aAFXbNyxhCRehJsCgSEtrIRF6a1lp3ItjZE91M3xyhP6X2iKgMKqLjE3AgcOZ5xxZ7iJzLHiSOG0QJgsdhvtklMzU3hrsiiqZCUSORjVM1bCc4S1XkySHpjudOte5LfSM1LQP7MUQoqqH7BBiwkQ7+mbsNsMns6zHa+3svZ9w4iZSWx2dmLJj93GuTmaqzYOjKTK7QD/fe2Zq5EA1K1eDNaZCANxCTJZEHKTBNM6vY6NLSh0JNu/HY9NuN8PH011TxwoaI3r7UADHeRdkn6GlX/JHZGZaEQ9JdQ+Y331164M3V9e0IAdOS1f5HAvs4gtxdXitDuFfy2+lRBo1lKu/fzKQISKnL5ieNswaIfsAD1y4Jm9LNBuqF9WxtKl1by0K4/6V2NWnHbNWqGXI2AY9N13yaiiNbiQ4OeGntqudzN+V0n4WFwBeBCIX2WObDQOQmD+lZET0Wzekx8+bkSZZa7kUYKkv4gz9+3RkIvN4Pd06YyA5IRFkpRBQmpi6uXxSyYmHd0q4MB+w= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(7416014)(376014)(10067099003)(11063799006)(6133799003)(18002099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?lvZW1H4OB+CelqRAOFl/XW6Hq/SpgDFlQJareTMKnJMPB7WgJOv/nYxFMEAp?= =?us-ascii?Q?5TC/iYEu9wearS1/0NLbJNJ2GLFla8HD2ApdZtH+Z5pIbJzyFA5A0/V00nxt?= =?us-ascii?Q?/mI08KCPjs6hk99KCx2ediK1HUJnNy4aMMoyjNrP0127xbvV00V30+sIY8s7?= =?us-ascii?Q?jHwFo4zvznnxNOW9dgGImUXJ5OIE17esVqw+gorSw83VX3U4My+oE7cQXWVY?= =?us-ascii?Q?dEv/TeycMDV6V0vGOpP/q68reqP7bGR9CEzVPOtwiLbLa4FnJ5gBcMFmN0w4?= =?us-ascii?Q?+zMteuRBHeJNuqGF9M1cnByPpCHt9X5p7Oc6eKyiNimMoWJ73Y2PAWwoSuf8?= =?us-ascii?Q?tcS27M5H5JWSditvslX8w9ygz0FjEIM3Nw/mFn41ZdrfhvrQRY8DDGrpgj2G?= =?us-ascii?Q?VmWZL7n0q9fafnGXZUNXt2+2kzL1qmY2vSpi61EKtA4bPwGRlRP6zOyxNezf?= =?us-ascii?Q?xVwa84fqTcVpq7LuMZ9vF5Ib3zRuUSMI5YQ5/mNZq4R2pgJuZoas4Uv0Y3wB?= =?us-ascii?Q?cKSD8KAQTwS0KHoKwSHOcCDJ31Dl6F8djLkUVSUekLneUzi3qLd3KChzJ+Hh?= =?us-ascii?Q?fCQ8+bzSnVhMRG18J0Qx1w2DjSWYmFvVC4I4XY9i60sFansaZCb+DkupfvU2?= =?us-ascii?Q?NniRvZXk+DXL/GTRLps4klhn4TOnTf+R06B37oWrjDXglwL1gUxDfnX/0w2+?= =?us-ascii?Q?MRrj3QdgY/BIK5fWN0rmOsRfc38miHvt8u7bJDdBiwhIqBlx8zffw8Hwk25D?= =?us-ascii?Q?QNDG2RQK5zBT7O7T23ra1165CgZuJ/YIDmghBJsJ7xuAhCtHu5WmBZGbRrTQ?= =?us-ascii?Q?AAi9UiFZ0E+mLAswYbLEqC5/9mEslwGzLbhUWO+CDn4o5gZFCBfjEXTcMa5i?= =?us-ascii?Q?z2fUODrbdP3FuOts33PFDd2rEUn0nFZK7MxCw7zYV5sbicYyeroAm9gQ+jD6?= =?us-ascii?Q?wiiQIH3RCRxVHUooIHszXtchILV6Cy5v6Ot2BzoPvmeAMQY8oKW3D0rSj8oI?= =?us-ascii?Q?GfuJslRpotMNZOp9anTqo+EBp8xMycCffM9FkuI2+m/kZ+E5mGo5oUq0T+X0?= =?us-ascii?Q?WpslWcmnohAjpo9N7AyLEtlTDuM7KiWBoHlgoC1vPOeHawCv35otut2b3HxU?= =?us-ascii?Q?a7JCPgmzUNcbE6oFyGEQL+UMYxk2v1kNGTQcbdoG7yl/P566Zt5qjPGtt1/X?= =?us-ascii?Q?sMFzqbuA9hn3nPA2h/7WIJ6jFRn+E+nH7oE+v1HdOKPE8OZdeeckgKVMrCuP?= =?us-ascii?Q?2yg7fkTb1Me+me/MU7g1qV8Zs/buxBDXYehdrs7A0ag6sUu2XRt7e1nOV5uC?= =?us-ascii?Q?bD/BKFVfWbJ+q4SZ8exeCqKjyQX/9yPqTzz3yjucUetMoz48IuDBl+YiLeBG?= =?us-ascii?Q?9OMPQYn7sU6+whXOpgMcLiWXjV9ppFO5AFiydyL19+5DcLD5ceDD2amIdI+e?= =?us-ascii?Q?FrqxE5UiDofmZhfH052eH/RpDdTlhtiKeqn78DyVAuQrsviSARHl+sgeD9oz?= =?us-ascii?Q?5LBZbNzRnermMjCzddg8vVMzhELpg7Hhhb5nKisZbjRSfzv1dmfuQroM5aRY?= =?us-ascii?Q?pf48J/KIUVvp56s/d4E+inX1/lPEKFGutXp7m9uaR5M8Ily+MG7FZ16hkoLN?= =?us-ascii?Q?8/kV/ZFRIo7908xPSnbBlUGFRjzbWc023m9b9wfw/gge5FNSXtTEoTbHX5la?= =?us-ascii?Q?ONiA49oVahxI3TD8mqq6zaj0REuJs16e790ObmW7rhf/gEMPEh8+3dJiwINJ?= =?us-ascii?Q?5m19sgbtqA=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9aaf9d0d-3bbf-4081-f319-08df18744bd7 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 06:39:48.3503 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zbmEuwiSQfB1TpomqcxIaNbRlXdl8vedH0xgqYZyZIVQElbdm/2K9Pj9J4FqY5ClfziptHZPAT9Cw1YPKrSJoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6565 X-purgate-ID: tlsNG-16d1c6/1790059191-1F4C977B-0CBFD5A2/0/0 X-purgate-type: clean X-purgate-size: 4220 This series fixes sparse eSPI INTID handling and checks errors returned by irq_set_type(). Patch 1 makes is_espi() check the architectural INTID range regardless of CONFIG_GICV3_ESPI. If the GIC reports an eSPI without compiled-in support, Xen stops with BUG_ON(). Virtual eSPI pending lookups return NULL when eSPI support is disabled. Xen has IRQ descriptors for INTIDs below NR_IRQS and, with eSPI support, for eSPIs starting at 4096. It has no descriptors for INTIDs 1024 through 4095. Patch 2 checks INTIDs in setup_irq() and irq_set_spi_type() before these functions look up a descriptor. irq_set_spi_type() checks descriptor ranges because it can run before the GIC line counts are known. setup_irq() uses the line counts once they are available. Patch 3 fixes the vGIC allocation bitmap. Reserving an eSPI used a compact bitmap index, but freeing it used the raw virtual INTID. This could write past the bitmap and leave the eSPI reserved. Patch 4, introduced in v2, checks errors from irq_set_type() in the GTDT, MADT, SPCR, and FF-A paths. GTDT and MADT could keep a rejected timer or maintenance INTID and later use it in a direct descriptor lookup. This patch also fixes MISRA C Rule 17.7 violations. Additional testing during v4 review, before the final edits: - Patch 1: QEMU and FVP tests with CONFIG_GICV3_ESPI, CONFIG_HAS_ITS, and CONFIG_DEBUG enabled and disabled. - Patch 1: pending lookup checks for all eSPI INTIDs, including NULL results without eSPI support. - Patch 1: physical and virtual eSPI delivery on FVP, including delivery to both vCPUs and retriggering an active eSPI. - Patch 1: injected an unsupported physical eSPI and confirmed BUG_ON() in both debug and release builds. - Patch 2: Arm64 builds with CONFIG_GICV3_ESPI and CONFIG_DEBUG enabled and disabled. Testing on v3: - Arm64 debug builds with CONFIG_ACPI=y and CONFIG_FFA=y, both with and without CONFIG_GICV3_ESPI. - FVP Device Tree boot with 64 eSPIs; Linux dom0 started. - QEMU virt UEFI/ACPI boot to a dom0 initramfs shell; this covered the GTDT, GICv3 MADT, and PL011 SPCR paths. Changes in v4: - Use BUG_ON() when the GIC reports an eSPI without compiled-in support. - Return NULL for virtual eSPI pending lookups when support is disabled. - Remove the redundant CONFIG_GICV3_ESPI check in IRQ dispatch. - Share irq_has_desc() with the assertion in __irq_to_desc(). - Log invalid IRQs rejected by setup_irq(). - Document the compressed vIRQ allocation bitmap above the conversion helpers, with an ASCII diagram and a reference to struct vgic_dist. - Clarify the is_espi() commit message and drop unrelated blank-line removals. - Add Reviewed-by tags. Changes in v3: - Add a preparatory patch making is_espi() a pure range predicate and move configuration policy and debug checks to callers. - Add the requested assertion before regular descriptor lookup. - Avoid partial MADT and UART state updates after irq_set_type() failures. - Apply cosmetic cleanups from review. Changes in v2: - Check descriptor ranges in irq_set_spi_type() and implemented GIC lines in setup_irq(). - Keep the is_espi() debug check when CONFIG_GICV3_ESPI is disabled. - Remove a redundant CONFIG_GICV3_ESPI guard from the vGIC code. - Add patch 3 to check irq_set_type() errors in the GTDT, MADT, SPCR, and FF-A paths. - Target master instead of the 4.22 release. Mykola Kvach (4): xen/arm: make is_espi() a pure range predicate xen/arm: validate IRQs before descriptor lookup xen/arm: vgic: free eSPIs using the bitmap index xen/arm: handle irq_set_type() failures xen/arch/arm/gic-v2.c | 15 ++++--- xen/arch/arm/gic-v3.c | 15 ++++--- xen/arch/arm/gic.c | 2 + xen/arch/arm/include/asm/irq.h | 11 ------ xen/arch/arm/irq.c | 28 +++++++++++-- xen/arch/arm/tee/ffa_notif.c | 11 +++++- xen/arch/arm/time.c | 18 +++++++-- xen/arch/arm/vgic.c | 72 ++++++++++++++++++++++------------ xen/drivers/char/ns16550.c | 8 +++- xen/drivers/char/pl011.c | 4 +- 10 files changed, 125 insertions(+), 59 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:39:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:39:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428173.1650888 (Exim 4.92) (envelope-from ) id 1x8uAU-0003n8-EY; Tue, 22 Sep 2026 06:39:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428173.1650888; Tue, 22 Sep 2026 06:39:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAU-0003n1-Bk; Tue, 22 Sep 2026 06:39:54 +0000 Received: by outflank-mailman (input) for mailman id 1428173; Tue, 22 Sep 2026 06:39:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAT-0003aV-DY for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:39:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uAS-00FEyU-FE for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:39:52 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab222ae-8faa-0a2a0a5109dd-0a2a4504c478-16 for ; Tue, 22 Sep 2026 08:39:52 +0200 Received: from [52.101.65.119] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab222b8-b57f-0a2a45040019-34654177a68f-3 for ; Tue, 22 Sep 2026 08:39:52 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by DBAPR03MB6565.eurprd03.prod.outlook.com (2603:10a6:10:195::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 06:39:50 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 06:39:50 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HfOirm0atRTWtptmPUdFok9YZoTbz92YaxcLzhL0kSMVb6ejaeqBWPaieZP/gnb7OeQquIm8KFWmJdvwAPL8Dbcg7owv4+UWspsr/6r7Y8sovdIu2JoxZKMl4dZPnQoJO/um/ihyk8hGxYMzEbBdseTVfZ78pX6klfLUVIEOkQml0bVZERb2hik6rI4SacW9F7fQheoBc9dUEFVJoh2+jm4Pg8tmAyZVBmbyDdKl+C4Ftg6Bh3jqPpIRG3/hGBLlFRBJ6F6PUg4QifZTj9pS3IwLBHy1H/8ljfsONhNDZ6tBhLvYjafMpIhc8RC3di6B1x1MkbqsRhtpfSVdgvIjJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oYZ+bXzlGIKtldd4l5jsQnzQLEtJHAU5cxG43Pee86g=; b=VIESPDDcUqwIvpK7dBkK6Q3aG08HW4QzkFRFqWTjt4F3PzNsbTq7TYp9rk4dJK42DK9W64cX888nlnSn/oUZUlmGmAanQwk2pFpWHWm3HHGq9kqggBXi5Qtf8vVAEAhVbrWlCvfsxqBJyG/D0k4sXMeY5YZm/bhE3SwCnXtjjr3sF1bM/7NZx9hsQhoPWPw1ze5ap7BNJETZJHtKfw46NsvwNTIk4b56TxS4SnwX+WWdEB8Uy6cxF+tw25VYItNuT9AHgLmUhhJfc+FjOYHplBJjcpYEPYOryi5iJ673DSn9j/Q9IWAqgW/ng5SHPObNaTDZZy5lMl0V+oRvhBWLJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oYZ+bXzlGIKtldd4l5jsQnzQLEtJHAU5cxG43Pee86g=; b=G3cgMZ1Ix7nGx9T7+qJnljo114YbRpsNxk1xU3QsadO7U0y838PRB8IeSpaVJ288XMruJtwMTjMfj7jV6+mXNHBGIPALGRr12kHd3jR7HIHS+bEofmn9ZD4IJSfasL1CBIrIwOtCLjw4Fz+irbx6E6yfCC73+7QqZkiK2tOwevf63wI00vLM42ZdguGuQibcXp0ZPH65PpZt5SrFtmkEL8IRp4egS5mm+Fg+aOUs2ZJg4DJ39juZM32rAevkxCJ30LTzQaahQ3WIkV1bUyqZlnkbU2uC3H1mnln3iwAid6PdKj/h0heU3qBOvhpOyRIHj/8F5xHeLCr/tgCjvyv29A== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4 1/4] xen/arm: make is_espi() a pure range predicate Date: Tue, 22 Sep 2026 09:39:29 +0300 Message-ID: <802ae2dd44556a292d98f1d52d3c88ce4fa5034b.1790056623.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA1PEPF00005B7B.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::613) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|DBAPR03MB6565:EE_ X-MS-Office365-Filtering-Correlation-Id: 3e2d626f-92a4-4fad-2889-08df18744d6e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|10067099003|11063799006|22082099003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: 92QCq/Sbxg6lMtAiINgcd93XgKhhM+4jZjTUIpOMm+hjgGXQVRsIig7VZeiS8KnZc73Zr74+z+Nsltw2ZkYRPeeLm0UvltUXwY2nvY7VGPqwQ/ev5N2Iw+zDwC/WeK8EJ/YTIFwLnn3GQkYkOktwZHxv2O47fCwNDVCehdFChwcab+80gAO6n6lYSb7jz8t8UJtuAoKg2qxAZ4USXcyAcO+pKYdy4fuU/UlOHipJ5MSQMMIP1nptuvzQsQ+MGMox2wj4sQKVtsBMayj4HMFwAIr/AQGoaYbIx9Aba9YRoJnQFrDdXV3awCFDdbLOSNL0fsBOstl4X3ERhXNwb3GznRHEuuquFUrCJeLFMowy6SR8qZd8/jGinoQvdu7txx2B2dCbI+JhfxQRSRBJ0y5+Dre5jFw2P7CPIaXe2MiOgYkk97dr+3AEFsT3dKcOV8gyYNE7oOtQw8tbcdu4SUYKDJ0DBYGSwemZKEo7PaxkYYnmb9cGiebB0ORjhA5Ao5NTpwNczGi3p6uDOGHe65sEorFAGXYeIZfmeZN6ztcgh799uz76L0RkZalvPi4eluZUUWkFDltr0ae63mOcZTaM+AkMT1h/4CCyJu+EMejJFacjAJlb2GJsfWL/+9Oc2VNpsLNbNXKmt++HoPZw9cbaVzf5jbXcKlZ//DUwEUUTtD8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(10067099003)(11063799006)(22082099003)(18002099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yadC843HNMa5u/MgFZf4kFLWMKqYOLKkTPUQC2IpNqESuqoNvpQkpPKLP1sM?= =?us-ascii?Q?CnMehMQvg2Tir9B0ln5aKXcXyw81PQ+7m74TqDFuYeRMrOxR+T7lsCp588jl?= =?us-ascii?Q?oF2Wv+p0mWLaJLxpaFOQvFK9c7SKwEMCIKDy0egLyZ4McvHdd9FxdIl3IXBm?= =?us-ascii?Q?aAhcdUqnrUzG9rOw/6AivGC1eIgIY9GXhEXlslRNGVwE3pQRnVMMFIU2jD9w?= =?us-ascii?Q?k7H57mZCx1x5lkI5uYDUwX+2DDv33Hmx0VT3pjlqcVcIgpjLWcbkPvfscEes?= =?us-ascii?Q?mTrFccHAyxUP+68eSVs8C2N5lRJg8NnCi2ter+YP2cUarRPX+t+e6RDs7zZU?= =?us-ascii?Q?rE8pqa+T0//D0rtCtN2cJzFxVvgKcovFEyZ7GWJu9wq4t63JN20LqBCU/Iyy?= =?us-ascii?Q?6KLW4p15sgNLsIx0jQlrASi6oTZ9cIdJXdY0VEa6RDyks/3KK3RE9ULMIBqR?= =?us-ascii?Q?d9HIKoGJNKhBwCvlW9DaONYepCcutbv4KNqVAG+i7abg0de4ZgDfhxpEpsc7?= =?us-ascii?Q?Ycb6g99TatvGENKyJbOI9NcrCBnQvAL5znOd7Ff0GvwyxSrq8fa1YJg0d6Mx?= =?us-ascii?Q?M6IRM/4rNo+LdZipeu97D1JV5/wz/A3GmnHMPwHwY6vxoC004lLHmMzvtOl9?= =?us-ascii?Q?JY8bCsTGR/iL5P5j+iI6caK3M2ADEmXOvRAgTCSNbKAAmFuOA0T2wsOxXa1u?= =?us-ascii?Q?ok3hK7cLPlmbzC9hN4HMsy+vv/Xh39xIlu9PIzRDsLeo5+qwfzqRb69VHFvC?= =?us-ascii?Q?fkp50IMHvDrshpozf2cDql3nrRo27pJOPFtUwrSumMKGMf25qSCF2BvxShcJ?= =?us-ascii?Q?Mo8nEIn+ycc/4BRz0TVrhOp+mIHyTjLBnKB4x0+0rBtsoe7sAU5v+b9xKxGO?= =?us-ascii?Q?gBYl7u8Ki28c23bg33ZeOxFYNM5i+7ac3V/bPHegma/B1iT5Vu4fzIqM+hbT?= =?us-ascii?Q?JIJlYaTwvtfYOgIbRdnQtxr3elyPl+1XMohKM9cfuEO1i06DkoUtXMiK75H6?= =?us-ascii?Q?ZgityJkKYq2ExbeR00PIZBpNoS6bfndeyA/iqF1rlIroHZTRFmX+zilkU4m1?= =?us-ascii?Q?qJTspb0oOB15s+PMBj7JO5sZF4SbpUJC33DoTTNysJK3gskfu1FCGkCxjotU?= =?us-ascii?Q?g+/J2PIpzBdPuo/3lh4DdqqzHtq2uvmMAx95hf7dQmcIKbxxqa5v66Jb7N3C?= =?us-ascii?Q?ISwBYU2bMGsFfZBO23IbsSgShC7KJBJQV/HbiYou0aQhQw8K/PNJepddfi3E?= =?us-ascii?Q?+2Zp0XfC6inaEmtl1nWXmC8h+YPM/brUxy0LGHMIGEUL6gJoIVxI6TQVvpwj?= =?us-ascii?Q?0V2Csfec7aSa5jZuPKcGJizDr+EJ1ZulnHAL09mEvrHylnJAqcMQexKfDFF6?= =?us-ascii?Q?9qD03FniMFhJY5FC2JWsAscmImUjptqlHan1Y/Fo3PLWF1PtKNkmJCjRI/Ns?= =?us-ascii?Q?94/egTmBN/6Ru1tj0wt4ZVEohptqcjCHkg7CAyQ50yRB3HZfkijlGMdlYcW0?= =?us-ascii?Q?gzAg5EXXrelKUPwGvPp+C+XK8qtrq/1OcN58ZyJvvDeQvCiqbKS3Dq++oQ8D?= =?us-ascii?Q?W3aWAhUh4K8DGM1fXjugW2nQlSE6Lsn+EIImHDSGeoXiEI5sAPaYfTYrfmBR?= =?us-ascii?Q?4GMZsNENH26qMXU+6SSF5/v5NwgXVLrbRjrkjnp9eGPh0wqmaTMjZiySWZay?= =?us-ascii?Q?5WrtS2t0/ffTnGoyt/HiyGJ8zqz8ZoS6M3nJH5kv59EAKgM/5dzOagKIOUlc?= =?us-ascii?Q?SBmsdI0M3A=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e2d626f-92a4-4fad-2889-08df18744d6e X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 06:39:50.7793 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1NSkub0pYOylFPN7mAQEVlf2WV6SgLq4eZK25zXUs3tBd2S22g8L7eUdHWtjXwbqf/mMZNQJ56LclvZdCu1dDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6565 X-purgate-ID: tlsNG-ebf023/1790059192-C14D3B50-71BE1FE5/0/0 X-purgate-type: clean X-purgate-size: 4772 is_espi() currently changes its result according to CONFIG_GICV3_ESPI. Without eSPI support, it returns false, and its assertion fails if an eSPI INTID is passed. Callers therefore use it both to identify eSPIs and to exclude eSPI handling when support is disabled. Make is_espi() report only whether an INTID is in the architectural eSPI range. Check for eSPI support at the call sites. Use BUG_ON() if the GIC reports an eSPI without compiled-in support, matching the handling of unsupported LPIs. Return NULL from spi_to_pending() for an eSPI when support is disabled, using an espi_to_pending() stub. Signed-off-by: Mykola Kvach --- Changes in v4: - Clarify the existing is_espi() behavior in the commit message. - Drop the unrelated blank-line removal in vgic.c. - Use BUG_ON() if the GIC reports an eSPI without eSPI support. - Drop the redundant CONFIG_GICV3_ESPI check in IRQ dispatch. - Return NULL for virtual eSPI lookup when eSPI support is disabled. Changes in v3: - New preparatory cleanup requested during review. --- xen/arch/arm/gic.c | 2 ++ xen/arch/arm/include/asm/irq.h | 11 ----------- xen/arch/arm/vgic.c | 30 ++++++++++++++++-------------- 3 files changed, 18 insertions(+), 25 deletions(-) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 078049e741..3a7f972826 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -348,6 +348,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq) /* Reading IRQ will ACK it */ irq = gic_hw_ops->read_irq(); + BUG_ON(!IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); + if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(irq) ) { isb(); diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h index 09788dbfeb..c29f3d04a3 100644 --- a/xen/arch/arm/include/asm/irq.h +++ b/xen/arch/arm/include/asm/irq.h @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq) static inline bool is_espi(unsigned int irq) { -#ifdef CONFIG_GICV3_ESPI return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID; -#else - /* - * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is - * disabled. Returning false allows the compiler to optimize the code - * when the config is disabled, while the assert ensures that out-of-range - * array resources are not accessed. - */ - ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID)); - return false; -#endif } static inline unsigned int espi_intid_to_idx(unsigned int intid) diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index e5aca17dcb..e04678f134 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -62,6 +62,13 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]; } +static struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) +{ + unsigned int idx = espi_intid_to_idx(irq) + d->arch.vgic.nr_spis; + + return &d->arch.vgic.pending_irqs[idx]; +} + #else static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank) { @@ -78,6 +85,11 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, ASSERT_UNREACHABLE(); return NULL; } + +static struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) +{ + return NULL; +} #endif static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, @@ -696,8 +708,8 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, /* * Returns the pointer to the struct pending_irq belonging to the given * interrupt. - * This can return NULL if called for an LPI which has been unmapped - * meanwhile. + * This can return NULL for an eSPI when support is disabled, or for an + * LPI which has been unmapped meanwhile. */ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq) { @@ -715,22 +727,12 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq) struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq) { - unsigned int idx; - ASSERT(irq >= NR_LOCAL_IRQS); if ( is_espi(irq) ) - { - unsigned int nr_spis = d->arch.vgic.nr_spis; - - idx = espi_intid_to_idx(irq) + nr_spis; - } - else - { - idx = irq - NR_LOCAL_IRQS; - } + return espi_to_pending(d, irq); - return &d->arch.vgic.pending_irqs[idx]; + return &d->arch.vgic.pending_irqs[irq - NR_LOCAL_IRQS]; } void vgic_clear_pending_irqs(struct vcpu *v) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:39:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:39:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428174.1650897 (Exim 4.92) (envelope-from ) id 1x8uAW-00041B-Ld; Tue, 22 Sep 2026 06:39:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428174.1650897; Tue, 22 Sep 2026 06:39:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAW-00040y-Ij; Tue, 22 Sep 2026 06:39:56 +0000 Received: by outflank-mailman (input) for mailman id 1428174; Tue, 22 Sep 2026 06:39:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAV-0003uo-Ja for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:39:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uAU-00G1WI-ID for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:39:54 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab222af-2eae-0a2a0a5409dd-0a2a450c8692-32 for ; Tue, 22 Sep 2026 08:39:54 +0200 Received: from [52.101.69.102] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab222ba-f479-0a2a450c0019-346545668e0c-3 for ; Tue, 22 Sep 2026 08:39:54 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by DBAPR03MB6565.eurprd03.prod.outlook.com (2603:10a6:10:195::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 06:39:53 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 06:39:52 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sXQPhxKfaxX68aY78DehFyCla3z7hSC3x0AupTj2AiVa1ABSaNIGhEJxCFuVpfqID6K4m0Sfr23jTS6Q2eK/igWY8qTAC5rbSl+D3BREP83CvOTvWGmwNgzoVYfM2NuotvHL+7vUlfCVKhLaXvEZDPqT0nYjgUdEId/Ln/1FppYknc5E/CMPmU2Qzr4P98Dn5hGb6hNwv+y9TPtzVWNpkeXfaX+kL/sr47ViB8R39r4+hOGcJ9tkEeQS7tjH8JADEOlxBqOVoyh8jMFn4k5dUbD/hpw9XyaCAslGyohg5UG+2KmUoGM3FDj6fRMhBEf09kmWrbGY1ZcqJTOYuoaLZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HSVOOjM+X1r+ZDTIJgdpekSUFlEb6s9XKd+BtJCbN6Y=; b=SLpjTvpg0x3ov1BJ6e1IyXiLTRxYYfmB5fMwLfbQYel2tquRDatZd2vK6GpOlFEzfVWpTfbOSmUSblFBpjicKjuZtWWS7L5NhZWb9Ld1j27UvTUfVtE7aUETHh+KI+ss6yKWTn/CijBBRXSH/gkRRfJS8NRWYu3FR4syQz5uwmod5gQK6RRxgStAVl3rg9dZeRgmiOzcDDQ/PxXB2gXNdTivjF19UHGi3/wYWexHAkriPAnIJbtlwSyNg3G/3wkPzzgeZ7EHbdzqcgWdG9Cd1N9xT8VhniplJQ17i8B7pW+EVUT0zGA+lfhJeDGg6PBkLK8LGEnsxXVwRjE5BRCCuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HSVOOjM+X1r+ZDTIJgdpekSUFlEb6s9XKd+BtJCbN6Y=; b=vKMVn0HN5LveEbt2TP+s2EwwxohynsluIt+wdimFcravUlmFNOvAY7yAl/yXLFsmTcaZ6xNARsxMxnTv9/ajb7P3IKlASBzCurjF/VksSrWff1rPVtdg2Xt1oyV4B0d4uec9zpV8PXYdwqM6d5MfIcic+/NB2ggCfViLBzNE6P26tSXr3Ow2kknB+4JoNr3xjlT0EztcZkGs1FZlrIbfjL+pWt4vcTDYq0zLv98HjQxfDKOl7EUfrfvMCffQ+7Vp9r5M334ufwoWPo5WI0EZh8Tz8N82i66abgEauoPOG71QVD1NJ8He8TXqugnzueSbY8gJvza6xABJnSBdGswBpQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4 2/4] xen/arm: validate IRQs before descriptor lookup Date: Tue, 22 Sep 2026 09:39:30 +0300 Message-ID: <6a94111e53249fc449b3df7700f37e026d522fc6.1790056623.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA1PEPF00005B7B.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::613) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|DBAPR03MB6565:EE_ X-MS-Office365-Filtering-Correlation-Id: f9ea5197-4c87-4fc6-7529-08df18744ea1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|10067099003|11063799006|22082099003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: +Gm/5nfZJkYONp5u88yj6CoFXJL7zevoQtbXe7chaOOotOSRZIT9q3zrAlY6sNPdq2eFEoJD/N0qOwcMqIIBWXSG92s9zOF5dDZo8FxUaSgESALv+6yh6lEcslxyUXg8l+GkAgMAQktYIOVuYiUzDm3gtdNCzlAyAw/mjRZni3+Urqb1ITym9ryj/ms+C0NodK3L4jUsz5DeA9hi+eoMdbkV/rNQa6sEk/Kr+GAq3AkvF3VR/ECQbjEClojUCvKo1ixL2AovMuNO3/scgEYpFQyHCeAhL/by3Djz2cfoUj/OVZQjmyBVs0SmjwN3ljtbdFt3WV5OsqvVhl3/i5OFuv12UeW7Mnj9o2OafMSHY5LnklIv+6lOHmABCMHHEAeUACSVSHZDacJ5ERsEyjawkQOKyrdHG6SPf004lMk1oKv1Ae4XExh/6gY5VFbBMXpZiqNSSqx5MJ8b06mCj0dodYrkh4vVFdqYYoNdgK8anNRGp+uwTQduC8JDcG8v8IZUiJlI5pWJHJABRreog8SXLG3LmvawgU+iIaRXf7iZiZeLZXYHQdOQwH3SFohwPwJAs4vzgNWKBRZxu5+K/r+DLeKwihCUepnUa39j2XgrpzT9dTk8VJHtzbGT2HSWI9qv7823iOYapHBL9nlal8HR6YoIWnOKZnjM1i93igDrzX4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(10067099003)(11063799006)(22082099003)(18002099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?X+5MD5DROwpSrTwLlMZ30xUW/o5P9NiYfgAYY95tRg7I6cVejiorryZoVDns?= =?us-ascii?Q?xkUVx6kOM86ToACvIOBKqj3gjs+Z/JeyjRKYZVgVXjzZFtOwqeUvzgZzZ15f?= =?us-ascii?Q?sfUo9fwVjqVYNvsgvaEcByG8c6tfFGrmbSIhpGb3mzcNXe/SKPTRPkUuKeRE?= =?us-ascii?Q?Bxd0bP8MDYUjtmt7Ww/3pXcT6HWNNCm3WDBfCrxD+Ky0TKni0GS9VJa/2ZkO?= =?us-ascii?Q?q9c16ytynHr+u+rjJFAkkQy/JtncFgENQd3LLp35J32sckPx4OX1kHOZozFj?= =?us-ascii?Q?52oBndgAG8Bf804RpyGziFQxifmw1PYljJYY+669RyrgR8yceTMPwAam79r1?= =?us-ascii?Q?ASYes1gKzD940ZCvrmhpllPbs77QUle7JDArzHwMrOivPW7XGvNnaw6teJTp?= =?us-ascii?Q?TpH2fEcaEWHgAqBo7a5FYJK+gYhz2dlN/eKd44K2+y/tDdVyQ3vfDXorw4ba?= =?us-ascii?Q?MpEwAnxkCgi7h0sDzrW6T2zOD2JxJ4fOsvpjo0JYv1Tnw9YUf0tK4+0eeA3J?= =?us-ascii?Q?R5ntjBXLwiY7RP522JW638uBeFGypePp8nhS+CqVM5utrXk4TYjnnlPNmqzo?= =?us-ascii?Q?oS6VDZeJbMBEo5W3Cc4vW61FqCVogwj0BMQyKDkfW+QrXmQqtz8yG25P802S?= =?us-ascii?Q?ko8BWezUlH5vpIQgoMSmE4VpUxv4VR5YmcqHL6LsvsAvKII7jnYOxyv+TTt+?= =?us-ascii?Q?1a9Vvyf2tnWcCprXh8551n23RyZ7Va3IWc4qLoQzXZkL4WLIZvE2Qd7/yi9o?= =?us-ascii?Q?/Ef643YzUdof47j035u/O66T3eghePuXdAh2UOW6Zbwc6bjG6kz5iFysuv/R?= =?us-ascii?Q?Mfmkhp8I45571RXzT/orgrZsl5WrplXTOwO2KTvG6vxO1ErXil7mZ22vUf3n?= =?us-ascii?Q?42DuxVF0hqfrHQ+2kGrk1vLRbJN6J7PIN3O2OSsDypJXrEky6VDbJBzxJhtL?= =?us-ascii?Q?eP5U9rBXfwYq9Qx6amihOwA5D5wcVxJnK2PHHhoZzD4w3FMYgWp6/yXR7SJv?= =?us-ascii?Q?mtaWHyM4DEevTQZsQs8ULy5aL4peB/961udjiiZm0NVvv11b1TZbacNzHa/n?= =?us-ascii?Q?kmlNixZ5nVnXRK3mA4GWEjabI6J/UBvX9xIaMQM38CqNMauuoC3fpLDA8h13?= =?us-ascii?Q?6zcXocDGZCBR4k0UxNHvAVfauC3Maz86ZvKOKehmnaCk4LliFwb4P9kFC45l?= =?us-ascii?Q?h9Ns5DVF9OXQ8KSV7g+B+1J3zeKY9AdEkk+FmzgUNGSSw/id8uSYIISy8ewr?= =?us-ascii?Q?lM+cwHi6ZY61fq/e7buNEPP2lkneci0OHO6c3ez/AjeByqRVHbTf8QDyV8zm?= =?us-ascii?Q?l6eHhxFu+CWEbbOTw9ZDscJ5CWl9ms2Bj4Oueaz6zILE8+FhV7XVhlNrK3Yc?= =?us-ascii?Q?M/4rpGNaK1UcTt18wwz6wK9oZBkCLzaA2ZqqQOhnrPlyCYcfgPQY8087dHV4?= =?us-ascii?Q?CPflmDbUxGJo1cC3qdK45aftBy4jnNq9ELkZc2kEigMe5WernCKbJPZmBuOf?= =?us-ascii?Q?RbOlFLW0K/eUANpQVY+kbN1qghvZtTo9zG6jyMeSEUABhKl0CB2aObg8fNfI?= =?us-ascii?Q?MWSLgQBGF+bSsya3iyH9Fg8NemTueuBgmnSfsLOYOEwxLvAjrMZY36Wla51D?= =?us-ascii?Q?g6vGbCVzRyzfT7UB4P7yXDvcNg239zk9xGZSz3bHBc4AIrNIWaQBwveuEIfx?= =?us-ascii?Q?SRU5owGSR0Bb6WxrSk4TdfoJKxtdVfj3G67lxaQ4mrXDpDxuWe3ASZt0AVBn?= =?us-ascii?Q?73PnrpHYvg=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9ea5197-4c87-4fc6-7529-08df18744ea1 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 06:39:52.8106 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: V4gri+UUYSA2SmkehAEb3cfk9oE1uGiVllFkHE5ey95wDkbSQGv9T/RS4VQ3GNAqEreA6hynfsPlYqaJNVaXzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR03MB6565 X-purgate-ID: tlsNG-d25034/1790059194-76EDAA5B-109ED293/0/0 X-purgate-type: clean X-purgate-size: 3643 GICv3 eSPI support makes nr_irqs span the architectural INTID namespace through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[] and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs. INTIDs 1024 through 4095 have no backing descriptors. Validation based only on nr_irqs accepts an INTID in this gap. __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or update unrelated Xen memory. Reject INTIDs that the GIC reports as unimplemented in setup_irq() before looking up a descriptor. irq_set_spi_type() can run before the implemented GIC line counts are available, so validate descriptor-backed ranges there before looking up a descriptor. Use the same descriptor range check in irq_set_spi_type() and the assertion in __irq_to_desc() to keep them in sync. Log the IRQ number when setup_irq() rejects an invalid line. Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range") Signed-off-by: Mykola Kvach --- Changes in v4: - Share irq_has_desc() with the assertion in __irq_to_desc(). - Log invalid IRQs rejected by setup_irq(). - Drop the unrelated blank line removal. Changes in v3: - Add the requested bound assertion and retain the SPI-only comment. Changes in v2: - Validate descriptor-backed ranges in irq_set_spi_type(). - Validate implemented GIC lines in setup_irq(). - Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled. --- xen/arch/arm/irq.c | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 73e58a5108..8d3517e761 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -85,6 +85,12 @@ static int __init init_espi_data(void) static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc); +static bool irq_has_desc(unsigned int irq) +{ + return irq < NR_IRQS || + (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); +} + struct irq_desc *__irq_to_desc(unsigned int irq) { if ( irq < NR_LOCAL_IRQS ) @@ -95,6 +101,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq) return espi_to_desc(irq); #endif + ASSERT(irq_has_desc(irq)); + return &irq_desc[irq-NR_LOCAL_IRQS]; } @@ -416,6 +424,12 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new) struct irq_desc *desc; bool disabled; + if ( !gic_is_valid_line(irq) ) + { + printk(XENLOG_ERR "Cannot set up IRQ %u: invalid GIC interrupt\n", irq); + return -EINVAL; + } + desc = irq_to_desc(irq); spin_lock_irqsave(&desc->lock, flags); @@ -647,13 +661,21 @@ static bool irq_validate_new_type(unsigned int curr, unsigned int new) int irq_set_spi_type(unsigned int spi, unsigned int type) { unsigned long flags; - struct irq_desc *desc = irq_to_desc(spi); + struct irq_desc *desc; int ret = -EBUSY; - /* This function should not be used for other than SPIs */ - if ( spi < NR_LOCAL_IRQS ) + /* + * This function should not be used for other than SPIs. + * + * The implemented GIC line counts are not available when early + * callers configure IRQ types. Check descriptor storage here; setup_irq() + * validates the implemented line before the interrupt is used. + */ + if ( spi < NR_LOCAL_IRQS || !irq_has_desc(spi) ) return -EINVAL; + desc = irq_to_desc(spi); + spin_lock_irqsave(&desc->lock, flags); if ( !irq_validate_new_type(desc->arch.type, type) ) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:40:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:40:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428176.1650906 (Exim 4.92) (envelope-from ) id 1x8uAc-0004Mg-1H; Tue, 22 Sep 2026 06:40:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428176.1650906; Tue, 22 Sep 2026 06:40:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAb-0004M6-UI; Tue, 22 Sep 2026 06:40:01 +0000 Received: by outflank-mailman (input) for mailman id 1428176; Tue, 22 Sep 2026 06:40:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAa-0004JV-Bz for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:40:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uAZ-008iOm-P6 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:39:59 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab222b0-bab6-0a2a0a5309dd-0a2a4502801c-42 for ; Tue, 22 Sep 2026 08:39:59 +0200 Received: from [40.107.162.74] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab222bf-6ca4-0a2a45020019-286ba24a3324-4 for ; Tue, 22 Sep 2026 08:39:59 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by FRZPR03MB11709.eurprd03.prod.outlook.com (2603:10a6:d10:1cc::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 06:39:56 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 06:39:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Xjx2TLcvDjS5EE0l43sBO3t1m8Q9B3yd7dPTcr43HpaGe/iwp6GDHyL9pPy2DiOb6F1ERu5NuFw0IMDyfxULYnyOJVqgEnZ0iWgvMSQ+w3AjouQBgl3shaKICV309de51hSUu1YKL0itHrLyN2F3hUkzXpi/X9OZUxkWr/zlftyYLPbTrrGqeDscWCiUQC0vZdhXdsZ7EbTZkloC6I2D6i93NjpUCYqbLcZvTzZP8ZNw0zXc4owQRBvbJvoKD8BqxfU1E5C41WEqX3ySA2lY7+NaX1W8+6p2msCFdUfiAFBiwSVAkPjaskkf18e187AXvh33vmyQR7wg8HdH6boDfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aQ+q+RYL0t82mCteCYDjy8hoTMUCSmEYX+bs4IRR+vg=; b=RH0BRtYJY5SZCT5rb8uY5SKTZYYCvHJ8ZvPF9v4YanYuqTirKTVtI63XfV54KiBHnsjDhT1VWj3I6E/8jyivydXlEq91bMeMe0zuNdZqS/8mcFY3eHDAZUSqHCb8pmCFh+9BfKdNypVv3SdIYg6oPhrbxNJIRFQqMavdmkyTKkV1qmaqcNY8kKkV0avLKoH/xBsfSJZIsBbmZrmatGtCSmJp90MDLiUC7MyWKdxSEMc/tWhrwdj3ndLT4JqfZU/2QC9jnuvkGPsD51fyBp/itff5BQKdQVklCJt+jLbS96bSdksLNCtYkh0YOBO7na04ZzMvWXNVo1nDYLm37gQtiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aQ+q+RYL0t82mCteCYDjy8hoTMUCSmEYX+bs4IRR+vg=; b=oKeam5CvwKszz+c541EUTJHq/f/AGVjudsCJUibDoe48w070La+XgjnlEmIUHjxPgZF37YRW0NsgitNMPSk6lMaYbGp21lluXnGuqOZlLy/6KzqTC4y0CSNJbercOsnZ7YUqvM7mnlf6h+S8fHW7HATeOkhnMyh84hP7yIPPeYw1xtDXJtd+I3/fwiSpEEsnYeWC+P20w1PFkNNCHEnKQXhuFTrOQz0Hv7wsI14eZMX1iQpzggwruLUpvnfX7RyeFV3mcHrT++TDY2Iyybi6Npf29BVCaEITn9lQzmaxbz3sXOBAgyIZXqfN9LAj/otvRN7SrxaYlOmcLjOE+LiQ3Q== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4 3/4] xen/arm: vgic: free eSPIs using the bitmap index Date: Tue, 22 Sep 2026 09:39:31 +0300 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA1PEPF00005B7B.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::613) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|FRZPR03MB11709:EE_ X-MS-Office365-Filtering-Correlation-Id: edef451b-d97f-472d-b56d-08df18745016 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|6133799003|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: 3YG9CV5RKJPMbu9y9vn/uLvH8Tacw1wRbzgVTTbewg2vcPm9QkLZUuPDn9xDtSr8ieeIcsY3Jrfe80Ei46Ht9FdFnS8EnG9wEWF8bYcLKiEnAP7/jXTSQfwpR56qFCXSBaBYutUsTKzTKNsmlttAKHhw0W+naDXiqA3H1vrTwMYk2EPIQ0ZlqwndzSmAUNoalHUGKBWkBeBi3RDFHOP47J80Ir/YgHtouv0g8YHietP74B3sRXGGAEzCn7zlS7h+u+8sbglZCs1366HKok25HtBSOpzc6UBXXJAhu4eWEpza6MxN39ElSIE9fCTbQpYBuJnbhU1yIGZccIxR62uixe+jcqE0fEKPxq3MnApWsr4N14t+Nn7C7LMlpuDiUa/1svGnoXLD7RiZ4cyegt3W9eIli6DRpF7R6sCI9nhc7f1DK0zOx5RFWMPRIV3pLdztlHCei+KowpSRkHtlLNgv9UYOfAtLH2afH2CUUmrBO4rEmABqtk2V+B5t2z5lP8eEW1J0dqtx+U2A4ATvozKmLpNWE6onnZnP5/3venLy5UNGNZMu7QTFlM4iD6GtTomdDoH7Y8f8NKq5TUmduwWuNPOodzh7j9pOryUodh/l9gDL4JfupUZ3shkzlJcYgarrOBjCUpHtzbt721AowRxsCHkp0fSgOesujHCzHq1mcd0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(6133799003)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yvfjHRSKJZXolZGXmocPgJvoWkJYW09lkLbgT1fud3h6qOPX/Tld/YTf4miT?= =?us-ascii?Q?gckeys7CFfNDJwxWs2i+2P1ZaMJ7ju5SYtoCDSQp4lfZ56U5E4IbTepv7hUM?= =?us-ascii?Q?mQEQF3iJDXtw4DyxgbtZ9RdiV3Y75R+jw+V3A09HGSvQAN4mshNJMKjuda76?= =?us-ascii?Q?IVpu92zJjJaExOLBq4SpFYQ1j+8Cea6hanbabTDNtOEtSCIbHTcsFO9BZtSM?= =?us-ascii?Q?5cVJbs+PlfsjdWQlKDB2314wYRFLFilNlukZEpyU2Jgo0oHXC9HM0UZFVZOc?= =?us-ascii?Q?TTkekwba14njNE9+dI+HtRjenACswkSuAssgdwkabBkSm3JS8C4wL+5vqWf6?= =?us-ascii?Q?738JywFQLMFBDlKZ+NxFB9XqP1l0ifyIgIKxXnFew4L7cekDJDPU28xMDtGo?= =?us-ascii?Q?1bA1X2t7Cm/8+wWvM/RqV6iwcqqP5Yn5Z8NaqN9yr43koKe1PlUdanlDT/Gu?= =?us-ascii?Q?nebpR0wtVuGnBwRqY69hiIJebCs/EqMxHQMdIwxWDZa9WMZ6dRIpSGzREkqg?= =?us-ascii?Q?sfem5nYjQPV00uye7n+LYDx4q41ZUxJBysCZp6wyCbR20cI+x67/YL6OM4WW?= =?us-ascii?Q?xsp/EYqmkTlZwq6o2zZkLAxkv6x7HavAKNx2MjmvL6EBAzaMSYFAGMztGjzB?= =?us-ascii?Q?3aPrFiIeMYc2z5pFRLi8q4/tTlQcTcox6nPZr+7KwtCR6JzH8Cvlf5CAP9yX?= =?us-ascii?Q?xBtnfP0xxjdgR7Jv91NjdMUm/kYK0auXdtL/P9ckuLFm4LAhrJraKIyxcP/L?= =?us-ascii?Q?rh61oqBJQapSUaEw4jfh0SLVc5B9eUWsbDsQ9e3m3l7NpA6xQHRrv1vJbbgS?= =?us-ascii?Q?C+Ww1yIxQqX7amgOuFbSfsv0Z6FHI1EvUszey2rOU7QZ6YDjs5esSL8Wkzi2?= =?us-ascii?Q?RxbHiSBL4ttAuU3v47QFNalRBmOZ3plxLNIyR+NfnfqcQlprxzIGFWyduM5z?= =?us-ascii?Q?xpfjZwmw4x0aeMc4jAwdnnf8jq4ZC4+Ov/HmBC/Qt3J4Wr461NcLt9u7MpuR?= =?us-ascii?Q?3xcFXWtIunDZxBnV0/f4h12VPay17cJLHafd6R60iW8+hYhThkLDchUQZDmA?= =?us-ascii?Q?7yZ7HJAYoSs+gJ+8BC72wkiHkZ4Yg8/T3Q4ZXStNE+YsvDx8DNwAf33R4cRw?= =?us-ascii?Q?Ct4si8uzgX8gCU0ouKMiFY+oKpjgASeOwyJSERjwQ4ab2xkORQVfN27styOu?= =?us-ascii?Q?mz8WZ8h94inQyMdCx/Mc0VXjHJnIqo7h1uIbxjkAK3cnDpeY6uli9miqwZpw?= =?us-ascii?Q?wuN819OVAjdsdMvvgLr83rUpicpcRkao9djaAHYl5fUAiul8o/XncpP+pcVp?= =?us-ascii?Q?/gre3pksBemAAKAvcXjnlSBtF14ezWYavB/HlqlQsohToO52YX9vL7Eo25Lz?= =?us-ascii?Q?o0QKUtMjy7sueB8xSVD1j3gYvXpuS8ilPzUKEBS4s43liEYui916q/Yyyjps?= =?us-ascii?Q?P/KBAqOjjU7THlmVU+bxk/iBfU2/Em749B6qjdmp0hnMKZ4HIVg51bh9Gfbo?= =?us-ascii?Q?EjdEHW2yMjQ+FQtOVJGG81KeK/7QYlk4vijbTB/e5YhHu9P1RvhPS9KpP4e/?= =?us-ascii?Q?disjaAk5j8hIz5o0Xapy/ijcVqRiAbrxRh0p9buwD4gQHNMC5o5jCUeUXcB6?= =?us-ascii?Q?5fBvdDYGdzwjtR6fMgh5Q7ZdeYXHNdJ70VFkyNsiG6/ibc8Wsb7ChN/l/M9J?= =?us-ascii?Q?8F8MoWNBLgdy2DvcE/7/pPHgGVaUpmw37LhBN3DgYS3K0v4uB/dc1EG93QNe?= =?us-ascii?Q?ZJnI4Sjlhw=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: edef451b-d97f-472d-b56d-08df18745016 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 06:39:55.8854 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: f2p7KhD0iUAoLDc3bbll4ZTUaTabtoCz1NOnkiJIUk592/v8JUOjyFbmFAiZDDDws+LgkfW53i0RUVGCw1X6hA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRZPR03MB11709 X-purgate-ID: tlsNG-720697/1790059199-303C42AC-7AC7D563/0/0 X-purgate-type: clean X-purgate-size: 3872 The allocated_irqs bitmap in the existing vGIC implementation stores eSPI allocation bits immediately after the regular vIRQ bits. vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index, but vgic_free_virq() used the raw INTID. Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit. This writes beyond allocated_irqs and leaves the intended eSPI bit set. Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind, and during vPL011 teardown. Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving and freeing vIRQs. Validate a vIRQ before clearing its allocation bit. Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended SPIs") Signed-off-by: Mykola Kvach Reviewed-by: Michal Orzel --- Changes in v4: - Document the compressed bitmap layout with an ASCII diagram above the conversion helpers and refer to struct vgic_dist for the full layout. Changes in v3: - Adapt virq_to_idx() to the configuration-neutral is_espi() helper. Changes in v2: - Call is_espi() without a configuration guard. --- xen/arch/arm/vgic.c | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index e04678f134..5b15b98ac3 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -25,6 +25,21 @@ #include +/* + * The allocated_irqs bitmap is compressed: eSPI bits immediately follow + * regular IRQ bits, skipping the gap in the INTID space. + * + * +-----------+-----------+-------------------+-------------------+ + * | SGIs | PPIs | SPIs | eSPIs | + * +-----------+-----------+-------------------+-------------------+ + * 0 16 32 vgic_num_irqs(d) + * + * INTID ESPI_BASE_INTID maps to bitmap index vgic_num_irqs(d). + * The following idx_to_virq() and virq_to_idx() convert between INTIDs + * and bitmap indexes. + * + * See also the allocated_irqs comment in struct vgic_dist. + */ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx) { if ( idx >= vgic_num_irqs(d) ) @@ -33,6 +48,16 @@ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx) return idx; } +static inline unsigned int virq_to_idx(struct domain *d, unsigned int virq) +{ + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(virq)); + + if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(virq) ) + return espi_intid_to_idx(virq) + vgic_num_irqs(d); + + return virq; +} + bool vgic_is_valid_line(struct domain *d, unsigned int virq) { #ifdef CONFIG_GICV3_ESPI @@ -850,19 +875,11 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr) bool vgic_reserve_virq(struct domain *d, unsigned int virq) { - unsigned int idx = virq; - if ( !vgic_is_valid_line(d, virq) ) return false; - if ( is_espi(virq) ) - { - unsigned int num_regular_irqs = vgic_num_irqs(d); - - idx = espi_intid_to_idx(virq) + num_regular_irqs; - } - - return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs); + return !test_and_set_bit(virq_to_idx(d, virq), + d->arch.vgic.allocated_irqs); } int vgic_allocate_virq(struct domain *d, bool spi) @@ -899,7 +916,10 @@ int vgic_allocate_virq(struct domain *d, bool spi) void vgic_free_virq(struct domain *d, unsigned int virq) { - clear_bit(virq, d->arch.vgic.allocated_irqs); + if ( !vgic_is_valid_line(d, virq) ) + return; + + clear_bit(virq_to_idx(d, virq), d->arch.vgic.allocated_irqs); } unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:40:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:40:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428177.1650916 (Exim 4.92) (envelope-from ) id 1x8uAe-0004v7-AM; Tue, 22 Sep 2026 06:40:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428177.1650916; Tue, 22 Sep 2026 06:40:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAe-0004uh-5j; Tue, 22 Sep 2026 06:40:04 +0000 Received: by outflank-mailman (input) for mailman id 1428177; Tue, 22 Sep 2026 06:40:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uAc-0004Uk-Hx for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:40:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uAb-006dEr-V1 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:40:01 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab222bf-e002-0a2a0a5209dd-0a2a450bc35c-10 for ; Tue, 22 Sep 2026 08:40:01 +0200 Received: from [52.101.69.84] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab222c1-b7e8-0a2a450b0019-34654554fa92-3 for ; Tue, 22 Sep 2026 08:40:01 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by FRZPR03MB11709.eurprd03.prod.outlook.com (2603:10a6:d10:1cc::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 06:40:00 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 06:40:00 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MXL9t3KlhV7hawE5DBO1/kiI5YfsvwCMotTQ+7eSRYZAXQnXVvML5C5tUyiHHOWdu7kz2buPTJKaF7HyhoNShkWDcqpGX8s0RhosmeSucmKEFaf5NRvPvsvCWq1Q0hyqpAeCJlcC+8ssuQz9IaBDSrLIxoY1zs5DJz8GtDZz4YHFgkjM7yTsLMMaeqzaYwxetcSrVMvd0gFDJ2bwNt1jCnlNwjza36Ojco1M8WpIilT4/7KLwuPNcRcgE9Hlp7ofHrs5ejDnbha+XxQK0UoG/b6WKSMYA58maJT5gycoFYfz6ieoToXsOpeOKgoLHJcxpT24y+LUj3FGBAGXwLsWVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2cKreGMUElULo1QhsKeoGyzZB+m+nWVmEkjFZ6Y0E/o=; b=per9VJBhHS0WI6vjKHSYHdP9kXXHSVg8+7OiWLzdjaV6wTdHDIf+ldzZ2jrL4NkVbavbYX0STa3Z+SZlBMO7Byv6DpJE6/s96UMjBi1KhD2MkSFvZ6b/WO2lY0ViBSv778D+uHpjzqoMCZxhLfYUXIilYak+L9KPHy7De95Y1/IOK3udJ7g/hFv9fQ72gXGtE0aM1CCfNnu7IzYs1MfmOf5LSo2ZxhYVQtPfLMTdqCl9bi/qTQuRvQyKNyrAb1Ez1KJkJG8UTMxrizncEgR7IZEzLNC7Zl2SbAmIeaSQGpJfu5OdYvi8PdrreNTJGC48gNfP4HOGlsKOyQbVPsRN6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2cKreGMUElULo1QhsKeoGyzZB+m+nWVmEkjFZ6Y0E/o=; b=hU/VcaomblbdUuqp65K+tA9902Q22o/jR2R5fSxXmag7E+fQ3wN7hwm2uZwEGDQdISLSxIf2f5+V3SxGve6oPLDfLMF04+W/W3RZKXDZbX/LHMrExCcOPwhGv9a78vDfb2u10HgVwJJj9lX/JRO7Hu4u46MMwlvQkjkmBFLTmKfe95q5MsN+VBUHTvYLd5L04jLYYu1wwmZfY2OF45a8nnQDTNL24NfM9tAwkbzS1hkMQ3/hCU1EylG7qnSnc7ekF9FkbcW6aePleMV9gazOxmMeudxtkvbQpwvyvFsHpTWmGbFUztIeLC79imdryuxSPQdQxvlWfBIXWUq0kKE48A== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jens Wiklander , Volodymyr Babchuk Subject: [PATCH v4 4/4] xen/arm: handle irq_set_type() failures Date: Tue, 22 Sep 2026 09:39:32 +0300 Message-ID: <85c5f8f04b19eea8d32e875a8b7e94f4ebb88292.1790056623.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA1PEPF00005B7B.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::613) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|FRZPR03MB11709:EE_ X-MS-Office365-Filtering-Correlation-Id: b9454439-9a24-484a-5102-08df187452e2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|23010399003|366016|6133799003|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: sUaeZcfEWsfWgbF09lIKlCd44Q+srzeqsyZB9RmvLpO6p05sv9l2YWxFdaFPaIY4IUtrXL++HHDzILCqBEHhV7QViu7UICTT3jFSh8iH66kZo7jPJUxEkzKebxrRqpfdPbdIEzSx6PUf/BSKhaq11UU8dB/wrOOqJGwHdbf8n8U1WJTy94jxIbA9IPnBQzS1ZDRixgNOhSmj0Hx9Ig1A6RjjerTHqpCu7PWgQohrvGxdKM5fqxVYiqYY+oB/DL2NjsOxpQvmi9QKpS6GsgVxeB+Lv31xQP9QSiq8VLdrGFHjHSMdzBKpObte+uAMOj5tQK8+0hvk8UsvSxcnKuRBwMgm4FcqDxsGPEPlmvoL5Bc7BTKodm3KLh+F9dWSriHTQbhbC2d1jh+BdeF1DdRzMPA7AcmOAUSC2EUiKPZiELvMHIiKgVRqTbLuV+4rBCEdsaE3X0TLbk4TDMTsEIemNvcmMb+erXvVV11Nyg3XfaQcerMo8PRMTkfftk5E+iZFzxHOuU7IXhapQamm3JskkFtsXJQYT2rCk8G4azgYcfkEpxY/L3mP56eoMyQSsr/gwkyRio+bgiQcYSfjXp/kRXGJa1sG9sJSxbS2XBbvcuVLUtko677HzjyXbzCnoWY85hU3gVv4OF0G7c3TIvNbPme8vQwDhycOZeUaVvl4JJA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(23010399003)(366016)(6133799003)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RZSJ+kUxijYejledWBimWehGJfHXUAq4D0kio7zGv6ilPfkIz14R0exZumsp?= =?us-ascii?Q?bcyfsNeT49mriCQfSX5R9hx5g/B1tjOJ1XWLJc1tvBy3l51Sj7SuT5DoFNxh?= =?us-ascii?Q?dfIEWaILGbyVqJdo4pPUIPgFATy/tUUHuO7RPLn98vRTHgRmyINztQiW0Y6O?= =?us-ascii?Q?5YYNoXx/cTWh5LGTCPJtbMbaC4f5YDDNAZZsP2z2r/swHIoretnVYycFBr/w?= =?us-ascii?Q?YBcgmSC4/b8P9QJxdBqN7f5V2hajJBIoHjHumDtuL7OyPpu4t4rhDxTySnTw?= =?us-ascii?Q?kFfvNNzlV+0iBz5glYlaS0JyUxg6jMCGV78J+suENdFxeXj+41C3c3vfznSI?= =?us-ascii?Q?K2DpYlx+P0cwV16EydBQR04PVxcAMWwFv1b1JR7wRFdnoEI34Jp4/RX1U4Zu?= =?us-ascii?Q?n9bJCztYtbgVBtO3s4nU4SXI0u6YUnH/njyGLkyzBjl8o4iWbAeFyd72uGW9?= =?us-ascii?Q?RclQfi9f4vr15uIlhuJWyBvXtNXisIjgRyB3CN7KYlTYXcd3i7FQGDird329?= =?us-ascii?Q?WMESftz3OgN+WGPcA5O8TGuC+2HTtYo1V8DKuERWPE6CxpCCKm13uJ+XN472?= =?us-ascii?Q?OLMJ60lvSq68TvIdgIXcBuz9S0BbY7i8fgbT24neI8kutaOJG6WROZa6wqP5?= =?us-ascii?Q?pnFv3Gkgua1JbyooqUpJcOkq/IWNRpJrCsegFsyq2/Zf4UDLp5WSnD3Es49/?= =?us-ascii?Q?nabwfdRAq2J5Kae4tIPS9ohtjSuhGmgh2ogs6xOjpa0hnrFe/33amk8WPGCn?= =?us-ascii?Q?2UiuuV+4JeXN7GOlZbm6ZQaXI3ocH/3LY4m1oeMuCswpWjrscMYrK9RGvmSl?= =?us-ascii?Q?tOvFhOJ6dqLkOtkYmUCqZ9RBEs2Dy2whViQcVtbwaNFdR0OflaPPKdtmSkSS?= =?us-ascii?Q?YfxchiwKVJBC6bnA5bfR7UtjECFAjEEGKt2CkVV69FPi/PBrXMELFRq8Q3Bx?= =?us-ascii?Q?YCEUWyKHCkGN2RX1+Us05l+8DwMxRXo5QxglIhCe08WeqT58OSMf2lNZiWA4?= =?us-ascii?Q?8KI5vopgwD3G2XAARSEoIXmGbff8Rn1vrItkE36+kWh5AgnjRpZ+G9AzHjiv?= =?us-ascii?Q?diSJ3tYIPnCWUQUBOWekxes/qR9oDeX3Q1kNkWy7xYcp27x1KWWxiXZTvijV?= =?us-ascii?Q?QfKspCHmSi0E2X72D0Lup8i9o7m7QNzAwwBrZFX9/Dk+VXGKw6HcXzU2KX9a?= =?us-ascii?Q?7yKoBnsIGpkzWjkGPDLAmSHkKNS+BooeyO9k2rzOhGPn4Ro0z16r0/E4plOH?= =?us-ascii?Q?1/R/W0Gm8PQ8mYDtiy9j+iqGV/5WUCgRr3tiwccExH8/chkYhDFKnlixi4H1?= =?us-ascii?Q?XHeAxmVjIt0wbn3Oct/nFpGAGxQVaGqzVh/zKkM5LFBFU2OO266FdKj14NCJ?= =?us-ascii?Q?UVvNpGcPCeGXzS9R6cVKuKQCK5jJxKnL2P8f+enOxlOeo/+5VWvqgpplsYWi?= =?us-ascii?Q?AR1oizeymG8KKRy3+ogxeDR7WkgJP5vwJquSvR9ka0OXdI6i9HVwU2bN6R+m?= =?us-ascii?Q?ZpE+l4Xj+WJ6cSTFulGdfwWHE+qLRD/1xnSsUCrhhDzXm4X9RgOS1aOyzu2K?= =?us-ascii?Q?vTKheeaps1lTKyX1jt2R0+RMCBF5VHIsH5HF1VS506fN8ZW86ssq37jp0tow?= =?us-ascii?Q?jWSVqh7tL8ODy+wW/5CaOSjyjNGCSuCGGS9VGeRUCFKnmyJBUXI4XzxqGujY?= =?us-ascii?Q?rp0ICrT0Qf6CQIb89+j1dEDFcljjLnFkGrR2lOL0KXL6OzITggvV4uEH62DB?= =?us-ascii?Q?u7yVNs8HBg=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9454439-9a24-484a-5102-08df187452e2 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 06:39:59.9608 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: MD5bZgr04u74Qqp8rz18uQEocvPpxd9RSS93/Xv4lRvCcNeW3TSpyViII/s7X7VLD0SS7DN7Sj3W9L2omidBoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRZPR03MB11709 X-purgate-ID: tlsNG-42698a/1790059201-A94C39EA-FEEC95D8/0/0 X-purgate-type: clean X-purgate-size: 8128 Several Arm firmware initialization paths discard irq_set_type()'s return value, violating MISRA C Rule 17.7. If trigger configuration fails, initialization continues with an IRQ that was not configured as requested. GTDT and MADT retain rejected timer and maintenance INTIDs. check_timer_irq_cfg() and release_irq() later perform unconditional descriptor lookups on those values. Xen has no backing descriptors for INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds access. Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store timer INTIDs only after successful trigger configuration, make GTDT parsing failure fatal, and stop UART or notification setup when trigger configuration fails. Signed-off-by: Mykola Kvach Reviewed-by: Volodymyr Babchuk Reviewed-by: Michal Orzel --- Changes in v3: - Avoid partial state updates and simplify maintenance IRQ setup. Changes in v2: - New patch. --- xen/arch/arm/gic-v2.c | 15 +++++++++------ xen/arch/arm/gic-v3.c | 15 +++++++++------ xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++- xen/arch/arm/time.c | 18 ++++++++++++++---- xen/drivers/char/ns16550.c | 8 ++++++-- xen/drivers/char/pl011.c | 4 +++- 6 files changed, 51 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index d05c574d88..87eda9d322 100644 --- a/xen/arch/arm/gic-v2.c +++ b/xen/arch/arm/gic-v2.c @@ -1166,17 +1166,20 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header, /* Read from APIC table and fill up the GIC variables */ if ( cpu_base_assigned == 0 ) { + int rc; + + rc = irq_set_type(processor->vgic_interrupt, + processor->flags & ACPI_MADT_VGIC_IRQ_MODE ? + IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK); + + if ( rc ) + return rc; + cbase = processor->base_address; csize = SZ_8K; hbase = processor->gich_base_address; vbase = processor->gicv_base_address; gicv2_info.maintenance_irq = processor->vgic_interrupt; - - if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE ) - irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH); - else - irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK); - cpu_base_assigned = 1; } else diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index acdac22953..b32a9b5009 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -1743,15 +1743,18 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header, /* Read from APIC table and fill up the GIC variables */ if ( !cpu_base_assigned ) { + int rc; + + rc = irq_set_type(processor->vgic_interrupt, + processor->flags & ACPI_MADT_VGIC_IRQ_MODE ? + IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK); + + if ( rc ) + return rc; + cbase = processor->base_address; vbase = processor->gicv_base_address; gicv3_info.maintenance_irq = processor->vgic_interrupt; - - if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE ) - irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH); - else - irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK); - cpu_base_assigned = 1; } else diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index 186e726412..d08d0a3366 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -407,7 +407,16 @@ void ffa_notif_init(void) irq = resp.a2; notif_sri_irq = irq; if ( irq >= NR_GIC_SGI ) - irq_set_type(irq, IRQ_TYPE_EDGE_RISING); + { + ret = irq_set_type(irq, IRQ_TYPE_EDGE_RISING); + if ( ret ) + { + printk(XENLOG_ERR + "ffa: irq_set_type irq %u failed: error %d\n", + irq, ret); + return; + } + } ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL); if ( ret ) { diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index be54b87438..ccfb76e20f 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -60,20 +60,27 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header) { u32 irq_type; struct acpi_table_gtdt *gtdt; + int rc; gtdt = container_of(header, struct acpi_table_gtdt, header); /* Initialize all the generic timer IRQ variable from GTDT table */ irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el1_flags); - irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); + rc = irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); + if ( rc ) + return rc; timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt; irq_type = acpi_get_timer_irq_type(gtdt->virtual_timer_flags); - irq_set_type(gtdt->virtual_timer_interrupt, irq_type); + rc = irq_set_type(gtdt->virtual_timer_interrupt, irq_type); + if ( rc ) + return rc; timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt; irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el2_flags); - irq_set_type(gtdt->non_secure_el2_interrupt, irq_type); + rc = irq_set_type(gtdt->non_secure_el2_interrupt, irq_type); + if ( rc ) + return rc; timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt; return 0; @@ -81,7 +88,10 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header) static void __init preinit_acpi_xen_time(void) { - acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init); + int rc = acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init); + + if ( rc ) + panic("Timer: Failed to configure interrupts from GTDT: %d\n", rc); } #else static void __init preinit_acpi_xen_time(void) { } diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 120ac09d23..eb608ab8b4 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -1928,6 +1928,7 @@ static int __init ns16550_acpi_uart_init(const void *data) struct acpi_table_header *table; struct acpi_table_spcr *spcr; acpi_status status; + int rc; /* * Same as the DT part. * Only support one UART on ARM which happen to be ns16550_com[0]. @@ -1959,6 +1960,11 @@ static int __init ns16550_acpi_uart_init(const void *data) return -EINVAL; } + /* The trigger/polarity information is not available in spcr. */ + rc = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); + if ( rc ) + return rc; + ns16550_init_common(uart); /* @@ -1975,8 +1981,6 @@ static int __init ns16550_acpi_uart_init(const void *data) uart->reg_shift = spcr->serial_port.bit_offset; uart->reg_width = spcr->serial_port.access_width; - /* The trigger/polarity information is not available in spcr. */ - irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); uart->irq = spcr->interrupt; uart->vuart.base_addr = uart->io_base; diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c index a336241033..97c53c11e0 100644 --- a/xen/drivers/char/pl011.c +++ b/xen/drivers/char/pl011.c @@ -363,7 +363,9 @@ static int __init pl011_acpi_uart_init(const void *data) spcr->interface_type == ACPI_DBG2_SBSA_32); /* trigger/polarity information is not available in spcr */ - irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); + res = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); + if ( res ) + return res; /* TODO - mmio32 proper handling (for now set to true) */ res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address, -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:40:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:40:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428203.1650923 (Exim 4.92) (envelope-from ) id 1x8uB4-0006q2-N3; Tue, 22 Sep 2026 06:40:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428203.1650923; Tue, 22 Sep 2026 06:40:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uB4-0006pv-KF; Tue, 22 Sep 2026 06:40:30 +0000 Received: by outflank-mailman (input) for mailman id 1428203; Tue, 22 Sep 2026 06:40:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uB3-0006pd-LA for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:40:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uB3-00FFAr-21 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:40:29 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab222da-8faa-0a2a0a5109dd-0a2a4505bbc2-4 for ; Tue, 22 Sep 2026 08:40:29 +0200 Received: from [140.77.166.138] (helo=sonata.ens-lyon.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab222dc-4cb1-0a2a45050019-8c4da68aec6c-3 for ; Tue, 22 Sep 2026 08:40:28 +0200 Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id 87D1DA48B8; Tue, 22 Sep 2026 08:40:28 +0200 (CEST) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTYKII3fA-hX; Tue, 22 Sep 2026 08:40:28 +0200 (CEST) Received: from end (unknown [212.133.41.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id E7EA0A1BC6; Tue, 22 Sep 2026 08:40:27 +0200 (CEST) Received: from samy by end with local (Exim 4.100) (envelope-from ) id 1x8uAz-00000005s74-15lP; Tue, 22 Sep 2026 08:40:25 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1790059228; bh=2cxc3TuQvyCkPh46rnZm8LQN7bXu7Mdt2ZjnZMKcfcM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h2ppNzJ7nxCPRoNIpS3Bz/ANsEB3mpubETlOA3l58HWPf94Vvvw/wxwdPqWpK7eZl a/eXVx7xvY3BlI2arr58UQ6LRj/5uadxMOETBlQBUaumqTii5KY1zamPfXCgoxcX7A tgoeqwpiJHs0m4IHSP7ha+DPLF1kuDn6OC+ojRBsFNwa2sJY7I06OTK8/V+UNPT+vo vIBR0kemZxCPRdCm1VXnOoO7VFEgz2Q7UX5Ok4SWvznIDfx4TzG7a55wUV1rlygM6b h1zmBBiHEOPj1Mwcy58F6mLlY85LMkUZOmeCDj5jI9XBdWudMkXmglEyQnlgTjK0SI Lp9nwSOaPhYWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1790059228; bh=2cxc3TuQvyCkPh46rnZm8LQN7bXu7Mdt2ZjnZMKcfcM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h2ppNzJ7nxCPRoNIpS3Bz/ANsEB3mpubETlOA3l58HWPf94Vvvw/wxwdPqWpK7eZl a/eXVx7xvY3BlI2arr58UQ6LRj/5uadxMOETBlQBUaumqTii5KY1zamPfXCgoxcX7A tgoeqwpiJHs0m4IHSP7ha+DPLF1kuDn6OC+ojRBsFNwa2sJY7I06OTK8/V+UNPT+vo vIBR0kemZxCPRdCm1VXnOoO7VFEgz2Q7UX5Ok4SWvznIDfx4TzG7a55wUV1rlygM6b h1zmBBiHEOPj1Mwcy58F6mLlY85LMkUZOmeCDj5jI9XBdWudMkXmglEyQnlgTjK0SI Lp9nwSOaPhYWA== Date: Tue, 22 Sep 2026 08:40:25 +0200 From: Samuel Thibault To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Jan Beulich , Anthony PERARD , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 2/4] stubdom: remove build of zlib Message-ID: Mail-Followup-To: Samuel Thibault , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , Jan Beulich , Anthony PERARD , xen-devel@lists.xenproject.org References: <20260917075351.37208-1-jgross@suse.com> <20260917075351.37208-3-jgross@suse.com> <6f9965b4-4d06-46a2-ae18-8014b1a1c4cf@suse.com> <09190c27-fd5f-4f7b-9d2b-be03785c7bbc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: I am not organized X-purgate-ID: tlsNG-c201ff/1790059228-722AB2A1-B018D235/0/0 X-purgate-type: clean X-purgate-size: 437 Hello, Jürgen Groß, le lun. 21 sept. 2026 11:08:12 +0200, a ecrit: > > We can point people to pciutils through such a comment. > > Do you mean pointing at the upstream pciutils, or the stubdom one using the > commit-id of the removal patch? I mean pointing at the upstream pciutils, more specifically https://github.com/pciutils/pciutils/pull/236 Or upstream's README.MiniOS itself once the PR gets merged. Samuel From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:48:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:48:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428215.1650933 (Exim 4.92) (envelope-from ) id 1x8uID-0007lM-E3; Tue, 22 Sep 2026 06:47:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428215.1650933; Tue, 22 Sep 2026 06:47:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uID-0007kr-9v; Tue, 22 Sep 2026 06:47:53 +0000 Received: by outflank-mailman (input) for mailman id 1428215; Tue, 22 Sep 2026 06:47:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uIB-0007jX-Lj for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:47:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uIA-006eoT-Of for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:47:50 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2248c-2eae-0a2a0a5409dd-0a2a4506dd58-26 for ; Tue, 22 Sep 2026 08:47:50 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22496-195a-0a2a45060019-4a7de18ceefd-3 for ; Tue, 22 Sep 2026 08:47:50 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccfd61ecaso32506715e9.3 for ; Mon, 21 Sep 2026 23:47:50 -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-49fdad2a3e0sm36681415e9.5.2026.09.21.23.47.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2026 23:47:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790059670; x=1790664470; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=9GsuyaOOPvxk/zCyls58dU6bakHBAdEItiM4x6nF+IA=; b=UPjp5f4vR04xmNRGAcu+RGX2K+lHExvQWAZtgokg2lggBQ0AfpKbriBIV0505IMGbt dJP9UEDflfNSSwGKmtJ3vS0s0agJVurfCxLHAGj37MixTlRmXf9Yfma4oSUMbtb1j2MG bYS4NnG5q4ZsDkFUx4eUBXD7qvJWOQpF7xGuGUnVBDXU6Bo1bZY92tc321ptaLNRGG8/ 1pgCqUb0EkJM5PrbkgkvoIXbKQakibFGjhljVqTk3aOKByUxxe23/G8XTthMGojN7K4u vVb2/AxQW3JvMe1EVFZ++IAAQ9SDxsv0p4b7mCRm/lkSOXv74DNxaWDlI6e/gtR+RNJ4 fk5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790059670; x=1790664470; h=content-transfer-encoding:content-type: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:content-type; bh=9GsuyaOOPvxk/zCyls58dU6bakHBAdEItiM4x6nF+IA=; b=pOEZlknfZVPSk1Pqbo7ihUb2bmU7KM2Kzgfq31FD3gLqWeA2OfD4Fq9ic4+jkYUAqP stEuIizH/lzJiiMRfRPVxgTUg2lBNrkDdsIdIiVisth8eYmjJRVJIZFxRkNZg4I2SkrV XSu7yUmKwSdFuSoaSbiUgL+4n6I9lfrrJQ6N5uukxZlzr6MfnEr4zYVIlIDjz6yqwXqB rDRZ6+tlqm9ooL4fFfmZ72TxjOJfrh8Z9HpkTpQccEswT0UFY+oJ92w2fKfZ81FkjCnM Pb7WpbTZ0gU6sGXsfgwHEke8+gBmjvlhO1b996/tyuRrV6K1MpDPzzfoQduOXmMFxpA8 fAQw== X-Gm-Message-State: AFuF++lOEspjBxMXV1IhKYAHtoYU9dOex+bUpmXsbtjHhhAzctDHQF/C wpht3tpxzDHuW5VUP/hP3kDjW7+kTvPNs/Nio3MSWayaJF3VZUR9GyYvInyONytg4w== X-Gm-Gg: AYBFou3he7e4UxODM16QDKBK5PUkFarhjEslEGUJSFEjwg56MwnJf4HTHuhO1/AtjNL RzcsP1mLwi4ivKDqWSmJwA3L+zJmosmg25dGD02WDhXjaQNdiNWcQGjAEb1XqEO1swNt7/ujZ5Z GY/Hd92Te0MGCWVXMzVxX9+BZ9xgaFjpQDof6vk4mvZFwF822+iua/0Ge6CQABRXYdDnq9q7ugg zfdtutZKDnmKh2lDJu/DxJgnrOiSw+FQkH7htlprkEHm+8sVc0FHkOt5k62cOWtgoTz1VWI4O0B nh7JpMTas59VVGvFtKmpMcUi81xzuNkwqZIV9lLnvKQaK7TUZwwpHiyxHGyqtWAW4g9T/KlxCSL /1tzECE/GzTmpDo0pdxTnRzt0tuGPjxRFLay4upOTz304069DdULrfeo9CQS/MybffoETA1uS4t OEOr+OwataV/YGTVhiE5jGR6HZ5tK1QcWNi2sKsR73bswy2hCgyt4NNJg0kQERocgw1ndaNIsHX wXQCAeFmkgozanxYvMgm5GDlKpoUBswD4gRDhe8cjeVRqtSCsQG2hYuBE1A9Q== X-Received: by 2002:a05:600c:1d16:b0:49f:bc8a:b103 with SMTP id 5b1f17b1804b1-49fc55c5361mr205757875e9.0.1790059670040; Mon, 21 Sep 2026 23:47:50 -0700 (PDT) Message-ID: <8fd025af-f429-488e-9977-aec3fea2e78b@suse.com> Date: Tue, 22 Sep 2026 08:47:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <87qzim6p5i.fsf@epam.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: <87qzim6p5i.fsf@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1790059670-1F0C777B-ECBAD272/0/0 X-purgate-type: clean X-purgate-size: 1538 On 22.09.2026 03:38, Volodymyr Babchuk wrote: > Jan Beulich writes: >> Outside of drivers/acpi/tables/ (which is excluded from Eclair reporting >> for dubious reasons), arch/arm/acpi/domain_build.c is the only user of >> ACPI_COMPARE_NAME(). Make the macro const correct, at the expense of >> introducing a "const" variant of ACPI_CAST_PTR(), and at the expense of > > I think you can avoid adding ACPI_CAST_PTR() by providing a const > type. Like this: > > +#define ACPI_COMPARE_NAME(a, b) (*ACPI_CAST_PTR (const u32, a) == \ > + *ACPI_CAST_PTR (const u32, b)) I don't think so. You did notice ... >> --- a/xen/include/acpi/acmacros.h >> +++ b/xen/include/acpi/acmacros.h >> @@ -103,6 +103,7 @@ >> * Pointer manipulation >> */ >> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) >> +#define ACPI_CAST_CPTR(t, p) ((const t *) (const acpi_uintptr_t) (p)) ... this, I assume. On the surface it looks odd, because one would expect acpi_uintptr_t to be a scalar type, like uintptr_t is. But it isn't: #ifndef acpi_uintptr_t #define acpi_uintptr_t void * #endif The only alternative I see (somewhat more risky overall) would be to introduce #define acpi_uintptr_t uintptr_t in acpi/platform/aclinux.h (or, imo less desirable, acpi/platform/acenv.h). Then what you suggest would no longer cast away const-ness at any of the individual casting steps. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 06:55:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 06:55:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428222.1650941 (Exim 4.92) (envelope-from ) id 1x8uPC-00018E-3X; Tue, 22 Sep 2026 06:55:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428222.1650941; Tue, 22 Sep 2026 06:55:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uPC-000187-0S; Tue, 22 Sep 2026 06:55:06 +0000 Received: by outflank-mailman (input) for mailman id 1428222; Tue, 22 Sep 2026 06:55:04 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uP9-000181-UP for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 06:55:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uP8-006g9H-UM for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:55:02 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2263e-2eae-0a2a0a5409dd-0a2a450b91c2-20 for ; Tue, 22 Sep 2026 08:55:02 +0200 Received: from [74.125.229.204] (helo=mail-lf2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22646-b7e8-0a2a450b0019-4a7de5ccfad7-3 for ; Tue, 22 Sep 2026 08:55:02 +0200 Received: by mail-lf2-f12.google.com with SMTP id 2adb3069b0e04-5b5e4f1744fso6030642e87.2 for ; Mon, 21 Sep 2026 23:55:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790060102; cv=none; d=google.com; s=arc-20260327; b=oGrCG/MD/NwEBYbNnTAYHXZrdha6w+MwGys4TIHE6xRgQTCfQ7sdLAopSKIRjzkeDi klwOO/iUiUc4PsdG3ymXSPDeJH9V0+9n+rQcLShm+3OQnFNf1pvfTwwiskr18VabBm7J T33skjmSyiRstXPtm9CvvcbWwktWwoFBaTOPt39Py45GZ3hqOH8ZIQmfUOsVdkwdnpij XEaow5/7XunCo/A1da6eli4v+J7iPIn6HJCjSRf4Zj3HKSba49lX0oWRelTYjWU8Am4S IxqxBi8Yxm/MqNMDvXT2ZzRco3oKnubk8HtiYPr9xusq3bwxXPXiIjrQazI72Cy8E2oL Gqmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=C5Cby2x6R5Lck1bQdug4hFfsKnrpZeWjQW7PzU5S5/8=; fh=luf8Gx1Gk9RFA/BMjBjqkQvMmZugGcf74W+gbCAAuto=; b=VRESyi2+M3zyO5JTixw6jrZDPcxWvDt4CML/LrWlGhP1CmBpvadIxUgRngHxpL1HT2 MsuK7o7mEWZkrCCApXUtzuSP8tIu9Lf3hA69baHZ2Cu3sNSEtKw27T5rDfd9y9at0RKj xKgko3Rv8mdyua3p9ZYtEpHp2i+hCfwtWWZYGCthJ0tZoak7AWPWXlLJV7gjLCxTLjg2 BsvSkMXFLDcSf6XemlNJ8hEToHATqwKL2Txp8fDllPkrMefKehK51TOinnDZ7rf/r966 EHDYeYWXYT3n0pgpWHYy4/dF7h3geuO+oF7y0KsZdBgwnRkAGUetqN0YXvoe4fL+uYp5 6JEA==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790060102; x=1790664902; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=C5Cby2x6R5Lck1bQdug4hFfsKnrpZeWjQW7PzU5S5/8=; b=mxMf5ThL6tNQ2lDNBQ5tKhGWebH7SLF/boGUl5Z4Fco3yyidRM1lL6vDyXnQX5NM8j hwl1Bup6dtzJ+RNRBwlk6NJVKzg2JLI3suXzxDjSvUijYuR5wPplU90f02KlZvRMZJ7n dn2k36Og08F34iHNYDiVaZ/T3jH0kULrj8dy6RLr43NDzx/OFpOUOgkUGjL+bDn0yzuh dyTXG74gNTxuhzzMK5Oq7kqgU7DJXFy6/5PDWifp7h7NKCpaJR9SHiyS4dMf/haVWw3T 92qCYsZdEUtarVc6EVdrBkJSHO9rRMI191NLaZxBnKUMSftzo/4lDhTN4/P0NLoQDLHw fJZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790060102; x=1790664902; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=C5Cby2x6R5Lck1bQdug4hFfsKnrpZeWjQW7PzU5S5/8=; b=jCbmER4OhZMiP6FrKBvKsUsl+W6JVvCIBHqGgX1EtyZ4FzYaFGbfc10WOxUtiwoQCg 3U4OiIq1ZwsHuNY12/2h51jydShV1cvnEFprPlt+gjuNiNM4tdR0Rf61VM1xjgSfB3PQ ToOYSUrqqyUuvxuZTc8zmniTHSEV51QSXtIznEUgjkbww5hus5tgPRPdf0RLuz0b5mXb +X7EBUJDEaYfkVwKHytQX13xcZ5lGUCmFYb5UjUm5FjWvkHkf7AuEmYIsoRKz+InCgVc exnCUWT1MAtRvyn4DDwGr4ktJkJl1GNp2eYvIhrqwCmHeAoK3y79EPQMnHt7EcmRoGOq lXLQ== X-Forwarded-Encrypted: i=1; AKwUvByiTKr6N7lz8psNkckD1/jy0GR8lSJH4vqw95JAvGsqXjhtCXKfuRuI+CS1z/NEL/6piD5WokRamdQ=@lists.xenproject.org X-Gm-Message-State: AFuF++ks2s1Nhut6uCWfKGQqdu57gUOIKldvvkDY6q1V5WXjF/Z4uV6s BZskAsGGrN8QERXSuKMjF9G0Tvby9k057NGij7jT1fFvDSEstAuq1Kjp1j94gAiZiSnTj+K9+3b omATHsiapCGLAJmjqFG+ezzpgJEUZKmk= X-Gm-Gg: AYBFou0id1GuAv0HbKZpQmwQyjPREjZo0MsOBPSkG2k8Qsxl/5BgL0UYYLrM2lDmrdr 2rR85cdX8MGyrJ64bg+u06XZrIfFuke8SCDVBVQ3S4mdkxaSVPndmOY2gu5B8fP4MV49vJxub8a 0rkP72jkS8Dq7yzRo6qKdqw2Or59zw4TPp+Q5rnrM4NT32WbiR+cMyIXE7BT9AtQjVnq8QFNsbV ov7NPln0YObRrRa7bHy89gjf10SzAph/q1VlnSwg0UFCywYbVKdtNk2mCC5XCLbFj0WR8Avm6tq u9JQAxqwAgleNYwxaImv0WOh5kpSOLgt4lLCjCYy6cn29sjNanPcRRU= X-Received: by 2002:a05:6512:318d:b0:5b8:9a27:9042 with SMTP id 2adb3069b0e04-5b8c17f205amr3902011e87.2.1790060101895; Mon, 21 Sep 2026 23:55:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mykola Kvach Date: Tue, 22 Sep 2026 09:54:48 +0300 X-Gm-Features: AcwNN1VU4ziKDcpv8mBkqCE3dFzyINy_uBpRRSNWl-ddJ-W4EnzMyjEyNVXNJKk Message-ID: Subject: Re: [PATCH v3] xen/arm: derive GIC CPU interface ID fields from the vGIC To: "Orzel, Michal" Cc: Mykola Kvach , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1790060102-A86CA9EA-8AB55045/0/0 X-purgate-type: clean X-purgate-size: 7809 Hi Michal, Thank you for the review. On Tue, Aug 18, 2026 at 5:48=E2=80=AFPM Orzel, Michal wrote: > > > > On 18-Aug-26 11:19, Mykola Kvach wrote: > > Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo, > > which is initialized from the sanitized host CPU feature state. This > > does not necessarily match the virtual interrupt controller configured > > for a domain. > > > > A vGICv2 domain can therefore observe a nonzero GIC field when the host > > supports the GIC system register interface, even though Xen disables th= at > > interface for the domain. On a GICv4.1-capable host, a vGICv3 domain ca= n > > observe encoding 0b0011, although Xen exposes only its vGICv3 model. > > > > Derive the fields from the domain's vGIC version instead. Expose 0b0000 > > for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the > > ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through > > CP15 in AArch32 state. Leave the alias unchanged when AArch32 is > > unavailable. > > > > Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64") > > Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers") > > Signed-off-by: Mykola Kvach > > --- > > Changes in v3: > > - Add direct dependencies for the shared ID register helpers. > > - Move ID_PFR1_GIC_SHIFT to the common CP15 register header. > > - Apply cosmetic fixes from review. > > > > Changes in v2: > > - Share the GIC ID field helpers between the AArch64 and AArch32 paths. > > - Parenthesize the individual ASSERT conditions. > > - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable. > > - Target master instead of the 4.22 release. > > > > v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.17= 83675708.git.mykola._5Fkvach@epam.com/ > > --- > > xen/arch/arm/arm64/cpufeature.c | 1 + > > xen/arch/arm/arm64/vsysreg.c | 18 +++++++++++++++- > > xen/arch/arm/include/asm/arm64/sysregs.h | 1 - > > xen/arch/arm/include/asm/cpregs.h | 1 + > > xen/arch/arm/include/asm/vreg.h | 26 ++++++++++++++++++++++++ > > xen/arch/arm/vcpreg.c | 12 ++++++++++- > > 6 files changed, 56 insertions(+), 3 deletions(-) > > > > diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufe= ature.c > > index 6fb8974ade..8bae8915e8 100644 > > --- a/xen/arch/arm/arm64/cpufeature.c > > +++ b/xen/arch/arm/arm64/cpufeature.c > > @@ -72,6 +72,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.= c > > index d9e3619dfb..4fb50b6972 100644 > > --- a/xen/arch/arm/arm64/vsysreg.c > > +++ b/xen/arch/arm/arm64/vsysreg.c > > @@ -20,6 +20,7 @@ > > > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -298,7 +299,18 @@ void do_sysreg(struct cpu_user_regs *regs, > > * to identify the processor features > > */ > > GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0) > > - GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1) > > + case HSR_SYSREG_ID_PFR1_EL1: > > + { > > + register_t guest_reg_value =3D domain_cpuinfo.pfr32.bits[1]; > > + > > + if ( cpu_feature64_has_el0_32(&domain_cpuinfo) ) > This check deserves a comment. Ack. > > + guest_reg_value =3D id_reg_set_gic_field(guest_reg_value, > > + ID_PFR1_GIC_SHIFT, > > + v->domain); > > + > > + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, = 1, > > + guest_reg_value); > > + } > > GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2) > > GENERATE_TID3_INFO(ID_DFR0_EL1, dbg32, 0) > > GENERATE_TID3_INFO(ID_DFR1_EL1, dbg32, 1) > > @@ -337,6 +349,10 @@ void do_sysreg(struct cpu_user_regs *regs, > > guest_reg_value |=3D (sysval << ID_AA64PFR0_SVE_SHIFT) & m= ask; > > } > > > > + guest_reg_value =3D id_reg_set_gic_field(guest_reg_value, > > + ID_AA64PFR0_GIC_SHIFT, > > + v->domain); > > + > > return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, = 1, > > guest_reg_value); > > } > > diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/in= clude/asm/arm64/sysregs.h > > index f3c11d871e..c0a6827b08 100644 > > --- a/xen/arch/arm/include/asm/arm64/sysregs.h > > +++ b/xen/arch/arm/include/asm/arm64/sysregs.h > > @@ -438,7 +438,6 @@ > > #define MVFR1_FPDNAN_SHIFT 4 > > #define MVFR1_FPFTZ_SHIFT 0 > > > > -#define ID_PFR1_GIC_SHIFT 28 > > #define ID_PFR1_VIRT_FRAC_SHIFT 24 > > #define ID_PFR1_SEC_FRAC_SHIFT 20 > > #define ID_PFR1_GENTIMER_SHIFT 16 > > diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/a= sm/cpregs.h > > index a7503a190f..79203324fa 100644 > > --- a/xen/arch/arm/include/asm/cpregs.h > > +++ b/xen/arch/arm/include/asm/cpregs.h > > @@ -114,6 +114,7 @@ > > #define MPIDR p15,0,c0,c0,5 /* Multiprocessor Affinity Reg= ister */ > > #define ID_PFR0 p15,0,c0,c1,0 /* Processor Feature Register = 0 */ > > #define ID_PFR1 p15,0,c0,c1,1 /* Processor Feature Register = 1 */ > > +#define ID_PFR1_GIC_SHIFT 28 > It does not look nice to split CP15 encoding list with this macro. Furthe= rmore, > it looks a bit odd to move just GIC and not the other fields. Also, how a= bout > moving the block to asm/sysregs.h? You would not need to include cpregs.h= then. I moved it to cpregs.h following your suggestion in v2 [1]. I will move the whole ID_PFR1_*_SHIFT block to asm/sysregs.h. > > > #define ID_PFR2 p15,0,c0,c3,4 /* Processor Feature Register = 2 */ > > #define ID_DFR0 p15,0,c0,c1,2 /* Debug Feature Register 0 */ > > #define ID_DFR1 p15,0,c0,c3,5 /* Debug Feature Register 1 */ > > diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm= /vreg.h > > index 387ce76e7e..bb6c904f2e 100644 > > --- a/xen/arch/arm/include/asm/vreg.h > > +++ b/xen/arch/arm/include/asm/vreg.h > > @@ -4,11 +4,37 @@ > > #ifndef __ASM_ARM_VREG__ > > #define __ASM_ARM_VREG__ > > > > +#include > > +#include > > +#include > > + > > +#include > > + > > typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *= r, > > bool read); > > typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *= r, > > bool read); > > > > +#define ID_REG_GIC_WIDTH 4 > > + > > +static inline unsigned int vgic_id_gic_field(const struct domain *d) > > +{ > > + ASSERT((d->arch.vgic.version =3D=3D GIC_V2) || > > + (d->arch.vgic.version =3D=3D GIC_V3)); > > + > > + return d->arch.vgic.version =3D=3D GIC_V3; > Wouldn't this be a violation of MISRA C R10.3? Yes. I will return 1U or 0U explicitly: return d->arch.vgic.version =3D=3D GIC_V3 ? 1U : 0U; Best regards, Mykola [1] https://patchew.org/Xen/f46f9e6ebb12d8402fa72b1641796f33e24c539f.178639= 5761.git.mykola._5Fkvach@epam.com/#103a2e50-0391-4bad-b9e7-d00c36c76a54@amd= .com From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:05:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:05:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428230.1650950 (Exim 4.92) (envelope-from ) id 1x8uYj-00034z-TR; Tue, 22 Sep 2026 07:04:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428230.1650950; Tue, 22 Sep 2026 07:04:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uYj-00034s-Qn; Tue, 22 Sep 2026 07:04:57 +0000 Received: by outflank-mailman (input) for mailman id 1428230; Tue, 22 Sep 2026 07:04:55 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uYh-00034m-Oh for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:04:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uYg-001n67-HN for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:04:54 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22893-8faa-0a2a0a5109dd-0a2a4503d7e4-8 for ; Tue, 22 Sep 2026 09:04:54 +0200 Received: from [74.125.230.76] (helo=mail-lr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22896-fae8-0a2a45030019-4a7de64ca4dd-3 for ; Tue, 22 Sep 2026 09:04:54 +0200 Received: by mail-lr2-f12.google.com with SMTP id 38308e7fff4ca-3a2ff16c0e6so27080161fa.0 for ; Tue, 22 Sep 2026 00:04:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790060694; cv=none; d=google.com; s=arc-20260327; b=IvqtidKDLQdYD+WGubrQIUc4xIRHJ0VpvNrZHb1+7sx8DEMMpf/6nSCczsFXOY/fOG JEAeXTqyjIvJNNTZPDMOW8GOwkzJulX22wqj+IpQujPT7EDM9fQZp0p5qdX6qLrby3X4 amol0Msr6PYCSCIwZyvL7/ZReYZT9j5z3+DFtd8aj3uKsnXhfYRQe75Wn/B5E2PhpEY4 uHUnt5ZkGLBoMXc7aRz1/1p6LGwMpSU1nLGRx2gwk/9xCAfqFGPtYSG/CMNqXFETBQ0F HH8qJaYXpINX7a1APQ21m7XrR0zPLWoA2YllN44M1NEtFUB3wddPB3nU2McPbrYqQLcc cbjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=u5KLci8axsBZKa2iGs/VF/tpFsisOqj9U943YBJ6gIE=; fh=xkGovUztO+7tl6B9I9GHgFuTbTxdlGwkEzwa8Ij88OQ=; b=ibV2NX65RKv2VZKXnEolFu/fOG87V8d/dJBCoOM7Uh1a4qU8LqIdOLVG/xDIIqDwYN 0Ck9H6+EgUQOmZbiFb3QJf311CrBNnhIYV+zc4pCuuwsIO780lhdVL0ekIzk6L4o9pxF kBL6IwwRR+CnkvW4oAPFNIwJp5MToEtiPK5b+ttr+T7528ZCGKmC35MIXcrAk6U7v+xa tU+hNzd1ckU8QtKedOif7IP5XV6s5dm6okXrglESfUTPGCxL/mBUd4U+TrvGqksH8XjK j1sXrMWwk23BZxidI0BCJ6YyQ8yP1uf/1paeBfX2DKX+f80DNmKTJGBw+hD2B6CKDHkH fVdQ==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790060694; x=1790665494; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=u5KLci8axsBZKa2iGs/VF/tpFsisOqj9U943YBJ6gIE=; b=DTAw9jDUKOAPAhxsI4mUm1VnUZ+sB1+yYmzIuoG0dKKYy6vpq8NT9D552KXjRdIrOU W6lVyrzdyg506K+PX7qEAXEEYhLRqQLo+3h6hgcjsJTs9YI+f0bS62k0nws+utmb3GUe BmQyONhS14llvs0AqqHOx/91a6Asye/uBb2YLKjRul2C/6P1TMK6RHfcZtYBqxfJ6Dkv k/mm6ElPfH5uuejqOD8ddin5XIjkvdbMjA0nMipiisx7kUCZlWKktObV8xvZy0hOdtIB Mrh9TZe2Cy0Gxuhfsx8AeNHGRJURqehUky/YQ73voWFuP6OLc+6ajeP8Cgx3Utw3pQSj Gi0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790060694; x=1790665494; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=u5KLci8axsBZKa2iGs/VF/tpFsisOqj9U943YBJ6gIE=; b=H6/sAEPChVFp4c4/lM/3UpOTAea1wAjhgNxC+IUnd4ruuVhDm/+y7yiFXlrk4pmFBu Cue0WSi6NT8AcJIVRyVuEKbsk5eMKX/7NRG9zFe/95Z9DYZ2NQR6ixQj1MLzOnlF8Kxt VzsUP3m+opwOlj1VVLh/YcKd8b3511x8/kKxjWBxDHT6FohyscjTQXqOEOd/Bb0+sEBM C1GRpTKDZDiIsN2Pn6PwutTgUnT6aD4GBrU6jmAI8kisitoNY0s+aj3JM16fbIDhIzjF spzoi/yyeyp6ebZiWpgAUfKtR47qW7glaLURW+jwUnYaGVkbQqV0NorptE3PdDzRHw+F bwZw== X-Gm-Message-State: AFuF++lo4kY6pCDkzKYqaDDoeoBbPyGsWxrXYaIUak8ryxiSL8vufqQZ P4HZG9sTxtxeJsLDIUoFwyRrr4QbbhTDUbvcs3fknIFAQYIrB8Zxy7xzm3tDn9dpWdZhuE0QJgT ne/kvnP3hGT2tsEvhhpd7WbezXIl5F0Y= X-Gm-Gg: AYBFou1wlhEt6juS86oH5LknJqUB8l/KylnVhWwRV8b3EZTbSySNHSQDvP7v+RZWgTp OTmFo0viq6WjANY+fvXFRgrVMdVqemwLF4UspZygBZO0whRB9B+936IR8kBh0+eOUuAN+5iGMoY YdOK5DZM/uynzv8g79axCs27BcmkpcBpU/sGQeAejOc7Jr2KUzU5IWcbqFLqP7Mzz3fd9qKaZWI VD2FIf5o3YS82I5K8rurnE5VxvNy4L8JVokp5ki7W5SMfgK64EeJHaVuwqHL3YnqY112Z2Z3njL /SB0e2Eu1EBYNCKGDNI2bfDE0kU4WXaH7rhmVVoPe8mgdLLKtsE8Tg== X-Received: by 2002:a05:651c:555:b0:3a4:9eb9:b99e with SMTP id 38308e7fff4ca-3a5fbe69c92mr32878761fa.12.1790060693474; Tue, 22 Sep 2026 00:04:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mykola Kvach Date: Tue, 22 Sep 2026 10:04:42 +0300 X-Gm-Features: AcwNN1VNhVTMm-f0Ez_W10Ey-T_SsP__u-NBkE927JyjfmMf2l1GbH7YE5sNz4k Message-ID: Subject: Ping: [PATCH v12 00/13] Add initial Xen Suspend-to-RAM support on ARM64 To: Mykola Kvach Cc: Xen-devel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jens Wiklander , Rahul Singh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-33051d/1790060694-772F54E9-49A9190D/0/0 X-purgate-type: clean X-purgate-size: 9420 Hi all, Just a gentle ping on this series. I would appreciate any further review or feedback when you have a chance. Thanks, Mykola On Thu, Aug 27, 2026 at 7:22=E2=80=AFPM Mykola Kvach wrote: > > This is part 2 of the ARM Xen system suspend/resume patch series, based > on earlier work by Mirela Simonovic and Mykyta Poturai. > > Part 1, covering guest suspend functionality, is already in mainline. > > NOTE: Host-wide suspend/resume support is guarded by CONFIG_SYSTEM_SUSPEN= D, > which can currently only be selected when UNSUPPORTED is set, and thus th= e > host suspend backend is neither enabled by default nor built in supported > configurations. The separate HAS_HWDOM_SYSTEM_SUSPEND policy bit only cha= nges > how ARM treats SHUTDOWN_suspend from the hardware domain; it does not ena= ble > the host-wide suspend backend by itself. > > This version is ported to Xen master and includes extensive improvements > based on reviewer feedback. The patch series restructures code to improve > robustness and maintainability, and implements initial ARM64 host-wide > Suspend-to-RAM support driven by control-domain PSCI SYSTEM_SUSPEND > requests. vPSCI also exposes SYSTEM_SUSPEND as a domain suspend operation > for all domains; attempt-time host-suspend policy failures are reported a= s > PSCI_DENIED rather than hidden through PSCI_FEATURES. > > Key updates in this series: > - Introduced architecture-specific suspend/resume infrastructure > - Integrated GICv2/GICv3 suspend and resume, including memory-backed con= text > save/restore with error handling > - Added time and IRQ suspend/resume hooks, ensuring correct timer/interr= upt > state across suspend cycles > - Implemented proper PSCI SYSTEM_SUSPEND invocation and version checks > - Added vPSCI SYSTEM_SUSPEND policy for domain suspend and host-wide > control-domain sequencing > - Improved state management and recovery in error cases during suspend/r= esume > - Added support for IPMMU-VMSA/SMMUv3 context save/restore > - Added support for GICv3 eSPI registers context save/restore > - Added support for ITS registers context save/restore > --- > > Link to CI: https://gitlab.com/xen-project/people/mykola_kvach/xen/-/pipe= lines/2796733872 > --- > > TODOs: > - Enable "xl suspend" support on ARM > - Add suspend/resume CI test for ARM (QEMU if feasible) > - PCI suspend ? > --- > > Detailed changelogs can be found in each patch. > > Changes in v12: > - Rebase onto the latest master. > - Updated patch 12; all other patches are unchanged. > No functional changes. > > Changes in v11: > - Keep SMMUv3 reset helpers in init text when CONFIG_SYSTEM_SUSPEND is > disabled. > - Update host suspend policy blockers after review: make the runtime gate > __ro_after_init, log the SMMUv3 MSI blocker only once, and wrap the Arm > IOMMU blocker in CONFIG_SYSTEM_SUSPEND. > > Changes in v10: > - Clarify the vPSCI SYSTEM_SUSPEND policy summary: keep SYSTEM_SUSPEND > advertised once implemented and return PSCI_DENIED, rather than > PSCI_NOT_SUPPORTED, for attempt-time host-suspend policy failures. > - Tighten GICv2/GICv3 suspend/resume based on review feedback: avoid > reserved interrupt register ranges, check visible active-priority state= , > restore configuration before enable state, and re-enable the redistribu= tor > before restoring CPU/virtual interface state on abort paths. > - Refine ITS resume so MAPC is replayed only for ITS-backed collections a= nd > clarify the collection-ID assumptions. > - Rework IPMMU and SMMUv3 resume/suspend handling, including root-before-= cache > IPMMU restore ordering and disabling SMMU interrupt generation before > suspend. > - Save and restore CNTHCTL_EL2 in the arm64 CPU resume context and simpli= fy > the resume trampoline/context hand-off. > - Re-apply boot CPU errata/workaround handling after SYSTEM_SUSPEND and m= ove > set_init_ttbr() declaration to asm/mmu/mm.h. > - Update patch 12 details: shorten SYSTEM_SUSPEND blocker logs, use %pd f= or > control-domain logging, mark serial_suspend_available as __ro_after_ini= t, > and mention the xen/suspend.h struct domain forward declaration. > > Changes in v9: > - Split the control-domain SYSTEM_SUSPEND flow so host availability, > runtime blockers and domain-readiness checks are handled separately fro= m > the host suspend backend. > - Gate vPSCI SYSTEM_SUSPEND on cached host PSCI support and Xen runtime > suspend blockers, and log firmware support during initialization. > - Fold the arm64 resume trampoline into the CPU context save/restore patc= h > and use asm-offsets-generated RESUME_CTX_* definitions for the assembly > save/restore path. > - Tighten the GICv2/GICv3/ITS/IPMMU/SMMUv3 suspend/resume paths based on > review feedback, including state-save/restore fixes and safer failure > handling. > - Reorder the host suspend/resume phases so timer and GIC state are > handled with local IRQs disabled and restored before console/IOMMU > resume. > > Changes in v8: > - Rebased to latest master and refreshed the series accordingly. > - Added a new GICv3 patch to tolerate retained redistributor LPI state > across CPU_OFF/CPU_ON. > - GICv2 suspend now disables the CPU interface and distributor before > saving state. > - GICv3 suspend/resume fixes the redistributor base used for LPI state. > - ITS and SMMUv3 suspend/resume paths were tightened, with safer > restore/rollback handling and stricter fatal-error handling. > - System suspend now checks that all domains are already in > SHUTDOWN_suspend before proceeding, and renames the hardware-domain > suspend capability/helper for clearer semantics. > - Fixed alignment/cleanup issues in the low-level suspend/resume code. > > Changes in v7: > - Timer helper renamed/clarified; virtual/hyper/phys handling documented. > - GICv2 uses one context block; restore saved CTLR; panic on alloc failur= e. > - GICv3/eSPI/ITS always suspend/resume; restore LPI/eSPI; rdist timeout. > - IPMMU suspend context allocated before PCI setup. > - System suspend: control domain drives host suspend. > - Dropped v6 IRQ descriptor restore patches; use setup_irq and re-registe= r > local IRQs on resume instead. > > For earlier changelogs, please refer to the previous cover letters. > > Mirela Simonovic (5): > xen/arm: Add suspend and resume timer helpers > xen/arm: gic-v2: Implement GIC suspend/resume functions > xen/arm64: Save/restore CPU context across SYSTEM_SUSPEND > xen/arm: Implement PSCI SYSTEM_SUSPEND call (host interface) > xen/arm: Add host system suspend backend > > Mykola Kvach (7): > xen/arm: gic-v3: tolerate retained redistributor LPI state across > CPU_OFF > xen/arm: gic-v3: Implement GICv3 suspend/resume functions > xen/arm: gic-v3: add ITS suspend/resume support > xen/arm: tee: keep init_tee_secondary() for hotplug and resume > xen/arm: ffa: fix notification SRI across CPU hotplug/suspend > xen/arm: smmu-v3: add suspend/resume handlers > xen/arm: Add vPSCI SYSTEM_SUSPEND policy > > Oleksandr Tyshchenko (1): > iommu/ipmmu-vmsa: Implement suspend/resume callbacks > > xen/arch/arm/Kconfig | 2 + > xen/arch/arm/Makefile | 1 + > xen/arch/arm/arm64/asm-offsets.c | 21 + > xen/arch/arm/arm64/head.S | 122 ++++++ > xen/arch/arm/cpuerrata.c | 7 +- > xen/arch/arm/gic-v2.c | 226 +++++++++++ > xen/arch/arm/gic-v3-its.c | 146 ++++++- > xen/arch/arm/gic-v3-lpi.c | 80 +++- > xen/arch/arm/gic-v3.c | 482 ++++++++++++++++++++++- > xen/arch/arm/gic.c | 35 ++ > xen/arch/arm/include/asm/arm64/sysregs.h | 5 + > xen/arch/arm/include/asm/cpuerrata.h | 1 + > xen/arch/arm/include/asm/gic.h | 16 + > xen/arch/arm/include/asm/gic_v3_defs.h | 3 + > xen/arch/arm/include/asm/gic_v3_its.h | 28 ++ > xen/arch/arm/include/asm/mmu/mm.h | 2 + > xen/arch/arm/include/asm/psci.h | 4 + > xen/arch/arm/include/asm/suspend.h | 37 ++ > xen/arch/arm/include/asm/time.h | 5 + > xen/arch/arm/mmu/smpboot.c | 2 +- > xen/arch/arm/psci.c | 38 +- > xen/arch/arm/suspend.c | 210 ++++++++++ > xen/arch/arm/tee/ffa_notif.c | 63 ++- > xen/arch/arm/tee/tee.c | 2 +- > xen/arch/arm/time.c | 44 ++- > xen/arch/arm/vpsci.c | 120 +++++- > xen/common/Kconfig | 3 + > xen/common/domain.c | 7 +- > xen/drivers/char/serial.c | 12 + > xen/drivers/passthrough/arm/iommu.c | 6 + > xen/drivers/passthrough/arm/ipmmu-vmsa.c | 323 ++++++++++++++- > xen/drivers/passthrough/arm/smmu-v3.c | 203 ++++++++-- > xen/include/xen/list.h | 14 + > xen/include/xen/serial.h | 1 + > xen/include/xen/suspend.h | 2 + > 35 files changed, 2169 insertions(+), 104 deletions(-) > create mode 100644 xen/arch/arm/suspend.c > > -- > 2.43.0 > > From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:10:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:10:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428240.1650959 (Exim 4.92) (envelope-from ) id 1x8udy-00052w-I1; Tue, 22 Sep 2026 07:10:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428240.1650959; Tue, 22 Sep 2026 07:10:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8udy-00052p-FR; Tue, 22 Sep 2026 07:10:22 +0000 Received: by outflank-mailman (input) for mailman id 1428240; Tue, 22 Sep 2026 07:10:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8udx-00052j-OD for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:10:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8udx-004bhv-0k for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:10:21 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab229d2-2eae-0a2a0a5409dd-0a2a4502a2d4-20 for ; Tue, 22 Sep 2026 09:10:16 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab229d8-6ca4-0a2a45020019-4a7de14cdcd2-3 for ; Tue, 22 Sep 2026 09:10:16 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356256so1241317f8f.1 for ; Tue, 22 Sep 2026 00:10:16 -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-49fd8ce2623sm68941855e9.13.2026.09.22.00.10.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 00:10:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790061016; x=1790665816; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=cOkYijdAVOZot9RPBs6dzUlH7Fn/J9eNT9BPy4D9aR8=; b=AHx34gplSkXBZ+JMcZNhOEQw0FaEBMiSen1sonmlM9udgeyFQdzZNEIJXgeiXGDXJv /Qgvmb3xdDqexv+OJLrW+dlggDY9yI9HDVXVnm+L0xb59MA2tVDX87PuV/2cGXx5IXu0 W57wRknKn6tYqfAnBfjFKqfPzqScU4Ha5qvSM2h36LyPxx/8LUDfvN4i5xZ79eZNCTu/ Eq3xP8pncZmUzWiusRZWC+YXq9PQYVTtkPVwhrTe5zCSJlfRGkuITlE9YbVJwYxC8IqD I9TI7zJcG+3KChO5sViNmQA0Wif0EPzdpvFzUK0nK9sifU3kQ+hTvQgeX1mBI3z5hDFD W7QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790061016; x=1790665816; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=cOkYijdAVOZot9RPBs6dzUlH7Fn/J9eNT9BPy4D9aR8=; b=eCgjjWnF3+ZHo+41FhZ93QwPoSpBlYKwzAYGsopY6Es0S15IlK8dvHae6sCiQUeLCc W/bKOjGNlKymc8lMcvswEYHN3Qk2Dz4bKJRD5yWN2DCko6687zLmD2TrR48UCb+5ufFk iMgYsKmArhmsU7bCGGQiQJzFLrYvtzy25iL6oTFHSauh6kV3mfEnIvVVcj6cGbr/4ODO DMZ0XTBsMxAg9eij4O7Igu6WlrAVstI5Mit8g3WZDjL8SxcKDW7CQr1KYuI3AbJMIO02 n9exgnuH0MZ453zu8959D4dI12N/ZXMovNCRud6uyCvt+qKGw78WX6rsGmrcjYn+O9lv wnqA== X-Gm-Message-State: AFuF++kV4TuxGorzS/7nE/yctBfNzXg+nBgDhIrcBfkJfz+BWEbJHCOf TfnmiHfwGra1sWTV+GIuDK0ZNTFVP5j84Y1jBV/S39hqEwKuPlHyV6RsA6fF6KZZErU/zOSL3Vm cR0oeag== X-Gm-Gg: AYBFou2eGCvYPbhPqTxAWZMT/KTmzGVBzJBYAMzcuik3bxgcIMDw6OSng0V2/G/HuhH EBAgaR2fDEiK5zcUHgob/44OIA2B9WCDQkp/Vqb/2v95WmnLa7UT5GocM/fLpE2l5iEtSGz3Usg aXrPseqEoopw/SFW1HfD6mU8TshIkea455FzkPm0HnAonuUm0YBo/UDQq1gmreHgsPc2r/Vm24P H+zn5sxRfg++nsrar5gp2uwvCMgGVRlC8eEpcCbKg9dIsYjfsPnzwSsuHMddG1YDVoilKrk/5o/ 2pK+jySc/sy5mKjTbcfDHWEYF1c9ACRB7v4+DIMiC4FBaZCaI6zTQthd+V5/E+gIQX63EeLmuxm Sa8h2/PGNUZ9RDUezDNMNJR0GnDlQJoKBtvaWZNBSjiuHfqEq/kwR0IERGw5soZ2l24+MKG/dfM i8fTVFhh5YKMAQ2iRhqWTI7xMBeQVN3v4uHeIkxNhiNhqPAxHxH0ldd1HIgNmML5kdMrY/J+oQ1 oImymLeAoNtllmbhNAwDPpFHtFKAbirs1db/Iz0lfuAX7SeQT59PU+oDXvO/g== X-Received: by 2002:a05:600c:4e53:b0:49f:ce79:7a8d with SMTP id 5b1f17b1804b1-49fd8a731c2mr25925425e9.17.1790061015669; Tue, 22 Sep 2026 00:10:15 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 09:10:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] ACPI: prune undue ia64 leftover 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1790061016-31FD62AC-6B238355/0/0 X-purgate-type: clean X-purgate-size: 917 This undoes the part of 3b0246ea0347 ("Fix ia64 tools build") which was missed by e567964a54b8 ("tools: drop ia64 support"). Signed-off-by: Jan Beulich --- The other ia64 oddity (in acpi/actypes.h) was truly inherited from Linux. Imo 37dbdb0a00d8 ("[SOLARIS] Fix Xen build. ACPI headers aren't Linux-specific") really also wants undoing, but that would require other acpi/platform/ac.h to be introduced. Or we could switch to having acpi/platform/acxen.h in place of acpi/platform/aclinux.h. --- a/xen/include/acpi/platform/acenv.h +++ b/xen/include/acpi/platform/acenv.h @@ -136,9 +136,7 @@ /*! [Begin] no source code translation */ -#if defined(__XEN_TOOLS__) && defined(__ia64__) -#include "ac_ia64_tools.h" -#elif 1 /*defined(_LINUX) || defined(__linux__)*/ +#if 1 /*defined(_LINUX) || defined(__linux__)*/ #include "aclinux.h" #elif defined(_AED_EFI) From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:21:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:21:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428247.1650968 (Exim 4.92) (envelope-from ) id 1x8uop-0006qi-GK; Tue, 22 Sep 2026 07:21:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428247.1650968; Tue, 22 Sep 2026 07:21:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uop-0006qb-Dh; Tue, 22 Sep 2026 07:21:35 +0000 Received: by outflank-mailman (input) for mailman id 1428247; Tue, 22 Sep 2026 07:21:34 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uoo-0006qV-Ae for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:21:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uom-00EmXl-6v for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:21:32 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22c74-2eae-0a2a0a5409dd-0a2a4502b74e-32 for ; Tue, 22 Sep 2026 09:21:32 +0200 Received: from [52.101.84.116] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22c7b-6ca4-0a2a45020019-34655474e0a3-4 for ; Tue, 22 Sep 2026 09:21:32 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by AMDPR03MB911350.eurprd03.prod.outlook.com (2603:10a6:20b:70a::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 07:21:29 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 07:21:29 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pYmXLfc2GdMvAGHPiwhlb9ULxTuTwppB1W360L8jodIees0GU1JThtsG/qGMqWUfs87Wh1MtoHfFT1b7qVKlbYW6rGSyGAZat4ZPX31l9ctlc2E3sNDcpDZsNUvnqR0xIaM++62RnwC1wFcI4rmKMDbwUm0PcI5BCxL8V0TT4edS8PeUwv9mEOmdR8/BYinJoKjUlEX+DrD88QAhmf4g9EnDU2Cp+gPDyIb8chtZojOObP3Q+HtZGNWWzdu0yl2G1sW+Av/ddkmBwYriE35TCyn9hY5Ewx4RCW/gphAGuzPDjvnF9RsSH/hR1nKDK/dDs/jU74bfyyj2nLJ+svQ7PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5X82O2FYdGtqPgQok93ByL/AQH724MAEtocmniCunyg=; b=jpA4fO+2upAGlB79Eiz9SyuyVBP5xGc+JnU0mII8IQMPrl6n5xAHriz8SzWS7t6Y45QWdjNJwca73H86+CSIKzwFzTZ/RAh3il6epvzIXuj4shmAOkElTcet94F662MAJfjDX2Z9ogyGo7a2l9Hvs4kSFdaoi5Wd5GXMMotPAUjfd+cpQm+dHCQp5gHUcSimlPBQ8EAxEpscBfAF0sp2RRoOgFl4A5l2QeHmiLKApLV1faHxXH1nSUw/g/kfMU4Hj9x7h75r6EiliJ0ULqMIUtJSy2R1R99jzeVDyEqayVac+yyWALYRTF3HxhOQ2Wc/z3xXlqyeO1Hyu9TpZ9TRxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5X82O2FYdGtqPgQok93ByL/AQH724MAEtocmniCunyg=; b=JDnDF5FrKzdaIcDTL6Dp0z57qlfpResO8aN3LxmziBHOvfXkY1U/BrcGffwDfv8NT9cSQt4z1sHEiBwWPaRbTsPV/GD4vcPsJbbbxiDPWWZDnOcmaN9kbLec5yobQ/b5FdL8oJt5Eclef6fx3YwOLgSdaXHm/V4dv84oJEoCfPOlTB+/QdkGms8N+TOkt+5nzBgni694IXcsiiNyHOUqLOOPYFxW/JHW6yDPoKyH8kRwzDeJlspUa0gsDU2AwjMwGA1J+DB6ybBaEtFRknZxB75Y2GZGF08NV3+DMdhTcMTGV+8Q8iOuG3E549lqzM8bchjr4P0kaNMEw1gJ9q6tSQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4] xen/arm: derive GIC CPU interface ID fields from the vGIC Date: Tue, 22 Sep 2026 10:21:20 +0300 Message-ID: <1101ee75414ec2e6bec05d34118c4fa7f8b60bcf.1790060180.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA2PEPF000008A2.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::658) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AMDPR03MB911350:EE_ X-MS-Office365-Filtering-Correlation-Id: 1da05b48-576b-44d0-e7c7-08df187a1ef5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|56012099006|5023799004|11063799006|10067099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: aRTGr1hi4R27TN428QtO30CCgFB3CsxtyMfoDRy/Xan8BZ+TYOq6FQYlMpb0VBuTyhX8vdVZ+XzEKg1FY/AoIYMFUx2E8JfYQvEJBwxjqM8pOocCCcdsvBQeOTwUw/dH8fppWb/mWaRHM1LbDRG/dH2oYFJmPxpxfaLLkNC/TFurtXiYU5+jpdMVD58O7rOwrtvELIVIfTcpQVi79zGyzCvO/lbu+HWNSqGbmgLxR2tZba97etdO5hhHYOVjDfryK0Ln+qcDKrdG1bByP6mUEzg6OrsFAyy/dnafVMP+4HrG83MAj3RUeLGsrHwmUA7AaJAHXQukFwfaRuC0/K3mvk/ayLcRMIIARSkkUYEIh5H77UKZbYBxZLMQrzXXMQQv7gbO2ts1x1YGW/ZYqWBwCUfgMtKbCvjLV6lSGpr7vCTl7flUYTfpr9HWIZJjFcVCwAIL4toWciEV5837GVBiX0BQRXwJkFIp/86/U6KTlpYMKPRQBnzECdWCe7hrSWtkMI6ZVPhlix+3jbq1MrmoJuA77v6ckLrnrWSOI8aNTD1NzmpB1W6ftWVAixBCk0rap+w2Wb7JoY3ttKzUWMnnauVShevagd9rFywIwvZ00vDKP+TIiSnqufgKN2IOF/0W X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(56012099006)(5023799004)(11063799006)(10067099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ro3YUHyKUHlnAip0TfqtfRTIDLMysyFBjdysWIKwRaPCJrxLHwza8hCsXu5n?= =?us-ascii?Q?SO5FiXdPOM+dMcnqNs7Y71ywjZIXKEVWLjHgXmO7Ekq5Wpnp8Kxm9Xdp9P/R?= =?us-ascii?Q?3/t+doi7bL4flyAk7V4q6KmtqCvaeYRakZN2Zurzlzrg1Q2Tb7LJvsVq66H1?= =?us-ascii?Q?xpcSwXY+jF4n+UUs/VqOzP5Ih1E3fu2fuiFynZAoifG1isfpJ76C+T8Yy0fm?= =?us-ascii?Q?DeV+6pf+YA2NpyZWhHnUklCLjQKb7awyOufN13UeRV4ayqTA6053aI4rFrYb?= =?us-ascii?Q?da3UQbDl9bHh8qCBrCTUltOIRgiUzVMMrUwCOB+39EC2oiKiwWlMxFYtL97G?= =?us-ascii?Q?1sodFjnzNAuXH2iCo7XD0nLuxf14JpGYjUewx5rlGiEudz2NabeTW3SijvhU?= =?us-ascii?Q?3B7F//GBdid3DtZiM3GTUinPJT4LM3ndOLbWNRpJqauiQUp6Yy1NV6eRtbFD?= =?us-ascii?Q?vHB4AlxWjo2DzWSz7G1YXSq0JebgM/kNdYo04pfKP/7TpZ4nP6H2sz/CObPV?= =?us-ascii?Q?4/GxRWnyInOkxBqF6qPHCszbqoJ0oYYlqpjAHKrYu7P7QBZ5LTOiEhK8eS7T?= =?us-ascii?Q?WaV/jTToAZl0O6QKYejhFlvzKbWXqMajcqi5eBhFRwNEBJ4NwyVGcFQ0Mn6Z?= =?us-ascii?Q?i4QSFi7tqsJwKIfuqMBcv8N6WwGmeZgLjbHGVymIWlhv7Cp8MihmzIauD8dl?= =?us-ascii?Q?ScweOe+JPZy16AAqLfrpTeosLCsG7PRKDau8BV5mKYNJ3qEftPigGUZB1lTR?= =?us-ascii?Q?F2EvWgsh/VmRC3S/l4cXnqoLnm8e+PzRJDO2YQhAQzpbWoO7dIVhVgVTAV9y?= =?us-ascii?Q?eZzuk4G/GsSrIfv6vqe8J/isJF6NSmWcIeNCnnY2wSsDsZNn3mv3D1H7SjDf?= =?us-ascii?Q?Mm/BlrdsfzOLbiI/WEc/NfwXUYT5nZ4J4V8tFqOoIINLuHagQtXtHoaJ4Opo?= =?us-ascii?Q?a63vPRgUnuT90KpJQLTaZGNIpSPJRY8wbjyTWhNrb6rCDNG/XhjO4sLNuaBm?= =?us-ascii?Q?KFMNMsP4qBntvh4Ph1+1GBhiInFg1Q7BPf6y6iJKaT1bXUshqAnJIJ8Mso1q?= =?us-ascii?Q?xEnSBm9D9ye22TiVytaQSrCzMj5e+aumXd3M65vtpIFlt/CM18/USP5bzQhC?= =?us-ascii?Q?z57t7lSJ5iw49HW+G9AG5NjqIfDI953DBz9rj8NquqRODTdsxUol+9HQ7IWf?= =?us-ascii?Q?8GNs1JHGf3/hnC9jxyUBz0vACRqWYz5w6xK78KZ4+xED7cGfkuw/B405fIjY?= =?us-ascii?Q?QTbTD5POfb1it55fD7j7hgAxF9Ox26BFhrXFzkcRjvM4ezoLGcScQMfI3SOO?= =?us-ascii?Q?uQCLE6F+Xx0JhK56vA+KPynBGj3f6f3EOcMNfXwVT9/MTVLfrQ1JYVrcMwk8?= =?us-ascii?Q?o6AVmfQf7F0JdP4z73ko67O2ZhBhw/CXq897JUz+QbX1EeKq7Nq7BfgY527/?= =?us-ascii?Q?9UhZTFNZALs72a7gmJjM3r59WRCGy4E0UaftrFF6lgHeYCn2WULHK8sIW5vp?= =?us-ascii?Q?FKCFk/S8/d0NFPECAjlDByiQ/EjZZprxptAfYpvdnr1G1Gkl1Q6/rQEV91nF?= =?us-ascii?Q?wbFYz0MgGDQ/G5L4aBewE4XIKh+qzReN49fPb9hP/x6m9MTNbanp5NYQo3vR?= =?us-ascii?Q?23ZtArqxnLNkJuExIZ8+66LbWrninE6K4x9Sk3LsMjCCony+HcUpczxmcNDQ?= =?us-ascii?Q?RZXsPFrwMlUZ2rvlHq8/NA0Br8eUz2JYq5d5kPz0znnyDL7nYvwgN4W0L7a2?= =?us-ascii?Q?R0hb26tZBw=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1da05b48-576b-44d0-e7c7-08df187a1ef5 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 07:21:29.7281 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hBrMkF9/ybQSb+ojwFiRb6bZOVYZiQq9TC6kPYuWRRDp2lv07OUuC4TWUVjnOFubXgpvA2CEAc+UCY5p3V0mdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMDPR03MB911350 X-purgate-ID: tlsNG-720697/1790061692-66EB32AC-0E37B018/0/0 X-purgate-type: clean X-purgate-size: 7651 Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo, which is initialized from the sanitized host CPU feature state. This does not necessarily match the virtual interrupt controller configured for a domain. A vGICv2 domain can therefore observe a nonzero GIC field when the host supports the GIC system register interface, even though Xen disables that interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can observe encoding 0b0011, although Xen exposes only its vGICv3 model. Derive the fields from the domain's vGIC version instead. Expose 0b0000 for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through CP15 in AArch32 state. Leave the alias unchanged when AArch32 is unavailable. Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64") Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers") Signed-off-by: Mykola Kvach --- Changes in v4: - Explain why ID_PFR1_EL1 is left unchanged without AArch32 EL0 support. - Move all ID_PFR1_*_SHIFT definitions to the common asm/sysregs.h and remove the unused cpregs.h includes from the ARM64 files. - Return explicit unsigned GIC field values to avoid MISRA C Rule 10.3. Changes in v3: - Add direct dependencies for the shared ID register helpers. - Move ID_PFR1_GIC_SHIFT to the common CP15 register header. - Apply cosmetic fixes from review. Changes in v2: - Share the GIC ID field helpers between the AArch64 and AArch32 paths. - Parenthesize the individual ASSERT conditions. - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable. - Target master instead of the 4.22 release. v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/ --- xen/arch/arm/arm64/vsysreg.c | 21 ++++++++++++++++++- xen/arch/arm/include/asm/arm64/sysregs.h | 9 -------- xen/arch/arm/include/asm/sysregs.h | 9 ++++++++ xen/arch/arm/include/asm/vreg.h | 26 ++++++++++++++++++++++++ xen/arch/arm/vcpreg.c | 12 ++++++++++- 5 files changed, 66 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c index 66f4f23bb3..2912445301 100644 --- a/xen/arch/arm/arm64/vsysreg.c +++ b/xen/arch/arm/arm64/vsysreg.c @@ -299,7 +299,22 @@ void do_sysreg(struct cpu_user_regs *regs, * to identify the processor features */ GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0) - GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1) + case HSR_SYSREG_ID_PFR1_EL1: + { + register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1]; + + /* + * Preserve the sanitized ID_PFR1_EL1 value when AArch32 EL0 + * is not supported, as for the other AArch32 ID registers. + */ + if ( cpu_feature64_has_el0_32(&domain_cpuinfo) ) + guest_reg_value = id_reg_set_gic_field(guest_reg_value, + ID_PFR1_GIC_SHIFT, + v->domain); + + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, + guest_reg_value); + } GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2) case HSR_SYSREG_ID_DFR0_EL1: @@ -362,6 +377,10 @@ void do_sysreg(struct cpu_user_regs *regs, guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask; } + guest_reg_value = id_reg_set_gic_field(guest_reg_value, + ID_AA64PFR0_GIC_SHIFT, + v->domain); + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, guest_reg_value); } diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h index f3c11d871e..f6ece8f972 100644 --- a/xen/arch/arm/include/asm/arm64/sysregs.h +++ b/xen/arch/arm/include/asm/arm64/sysregs.h @@ -438,15 +438,6 @@ #define MVFR1_FPDNAN_SHIFT 4 #define MVFR1_FPFTZ_SHIFT 0 -#define ID_PFR1_GIC_SHIFT 28 -#define ID_PFR1_VIRT_FRAC_SHIFT 24 -#define ID_PFR1_SEC_FRAC_SHIFT 20 -#define ID_PFR1_GENTIMER_SHIFT 16 -#define ID_PFR1_VIRTUALIZATION_SHIFT 12 -#define ID_PFR1_MPROGMOD_SHIFT 8 -#define ID_PFR1_SECURITY_SHIFT 4 -#define ID_PFR1_PROGMOD_SHIFT 0 - #define MVFR2_FPMISC_SHIFT 4 #define MVFR2_SIMDMISC_SHIFT 0 diff --git a/xen/arch/arm/include/asm/sysregs.h b/xen/arch/arm/include/asm/sysregs.h index f6af987ef5..8dcf82a694 100644 --- a/xen/arch/arm/include/asm/sysregs.h +++ b/xen/arch/arm/include/asm/sysregs.h @@ -9,6 +9,15 @@ # error "unknown ARM variant" #endif +#define ID_PFR1_GIC_SHIFT 28 +#define ID_PFR1_VIRT_FRAC_SHIFT 24 +#define ID_PFR1_SEC_FRAC_SHIFT 20 +#define ID_PFR1_GENTIMER_SHIFT 16 +#define ID_PFR1_VIRTUALIZATION_SHIFT 12 +#define ID_PFR1_MPROGMOD_SHIFT 8 +#define ID_PFR1_SECURITY_SHIFT 4 +#define ID_PFR1_PROGMOD_SHIFT 0 + #ifndef __ASSEMBLER__ #include diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h index 387ce76e7e..96de1c4916 100644 --- a/xen/arch/arm/include/asm/vreg.h +++ b/xen/arch/arm/include/asm/vreg.h @@ -4,11 +4,37 @@ #ifndef __ASM_ARM_VREG__ #define __ASM_ARM_VREG__ +#include +#include +#include + +#include + typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r, bool read); typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r, bool read); +#define ID_REG_GIC_WIDTH 4 + +static inline unsigned int vgic_id_gic_field(const struct domain *d) +{ + ASSERT((d->arch.vgic.version == GIC_V2) || + (d->arch.vgic.version == GIC_V3)); + + return d->arch.vgic.version == GIC_V3 ? 1U : 0U; +} + +static inline register_t id_reg_set_gic_field(register_t val, + unsigned int shift, + const struct domain *d) +{ + register_t mask = GENMASK(shift + ID_REG_GIC_WIDTH - 1, shift); + + return (val & ~mask) | + ((register_t)vgic_id_gic_field(d) << shift); +} + static inline bool vreg_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr, vreg_reg_fn_t fn) { diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c index 3c315be9fd..9811902684 100644 --- a/xen/arch/arm/vcpreg.c +++ b/xen/arch/arm/vcpreg.c @@ -316,7 +316,17 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr) * to identify the processor features */ GENERATE_TID3_INFO(ID_PFR0, pfr32, 0) - GENERATE_TID3_INFO(ID_PFR1, pfr32, 1) + case HSR_CPREG32(ID_PFR1): + { + register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1]; + + guest_reg_value = id_reg_set_gic_field(guest_reg_value, + ID_PFR1_GIC_SHIFT, + v->domain); + + return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1, + guest_reg_value); + } GENERATE_TID3_INFO(ID_PFR2, pfr32, 2) case HSR_CPREG32(ID_DFR0): -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:21:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:21:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428250.1650978 (Exim 4.92) (envelope-from ) id 1x8upD-00079Q-O6; Tue, 22 Sep 2026 07:21:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428250.1650978; Tue, 22 Sep 2026 07:21:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8upD-00079I-Kb; Tue, 22 Sep 2026 07:21:59 +0000 Received: by outflank-mailman (input) for mailman id 1428250; Tue, 22 Sep 2026 07:21:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8upC-00078r-CO for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:21:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8upB-00Emhp-Lf for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:21:57 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22c87-e002-0a2a0a5209dd-0a2a45049ba2-38 for ; Tue, 22 Sep 2026 09:21:57 +0200 Received: from [74.125.227.171] (helo=mail-pj2-f43.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22c94-b57f-0a2a45040019-4a7de3ab88b0-3 for ; Tue, 22 Sep 2026 09:21:57 +0200 Received: by mail-pj2-f43.google.com with SMTP id d9443c01a7336-2d9004a1ac0so24804555ad.3 for ; Tue, 22 Sep 2026 00:21:57 -0700 (PDT) Received: from localhost.localdomain ([2409:8a1e:2e81:7320:b94b:d1b8:4cbd:b7e1]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2df5d057f55sm4912055ad.73.2026.09.22.00.21.52 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 22 Sep 2026 00:21:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790061715; x=1790666515; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=i6+9O7L6qCQ5h69lNzkhEL6SI6PUQRg+/hzlVyYHi4k=; b=Tu96gy8l5YRKKEwKJjG9RoIDmJe8FRk6NZxrr92C8/ks/OAtPOOxORdzfBfUuu6Ntb Tp53KQQgh9g6XpgaPirbqrmzwNN+//M96YXWscViotZ6tZCcKy0289LiVv71fi1R/xkx AygVaHknZYYsXnTu8IKTZRMXyhfm9+5EqBH66NeDYAejRgvlGP2ps/bB/jlOcJNKr3Cx 5YlQl+O98/hjpDs9nZ9QGDwMbw4N/PM6gq7J8PYD74HJCKNTSjhZg2wygGffqcSOHGJd SEbjwPjWkih3DRlJvuxqNz0f9Tm4SD4B74uHILQ8hP8nu7jUGyMpxL17sbx2s9IxXZze plKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790061715; x=1790666515; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=i6+9O7L6qCQ5h69lNzkhEL6SI6PUQRg+/hzlVyYHi4k=; b=D4HV+LG3p17vZQbgM0hRE9pbC8xum//hJV1Q9zy3PabAircC7aBELP24yOKMth7Wl5 1x0pzktoajiyLane4PbyN1TUnQ8I3pLQ8ipa+eBvYVWQia31o0F7jkDRWFjnA26P16QI kL5IbqEeG72/u7x5F9qQ3C88sRJ3js4v7Pk8/T0wEkWbzt6h8Jm1i+Wb69sdwZfW+L34 YTAYSV9LZutpwbgY9XtZuo8Mr5wl5twBOk3KAfXpUvomQ6R2oFFYuU1Sd8TiAMbIaSIH VbB6HB6lUbPA/jqlmjuVjLGzuN0U9Ez1Sojd3Qtl6w2YP0sTbzM+j36LS9XiD9aGR/cs FaNw== X-Forwarded-Encrypted: i=1; AKwUvBzp336nYfIKKt0vGk2h9PsjM66qtgDFwRVsBsBpWQaejZoimSJIjYBvXO73Ocmd+TG23OW25r80+1Q=@lists.xenproject.org X-Gm-Message-State: AFuF++ntkGl1RYSfHj4ggwn7REYksK85LBgiR9Xi6x1Vd5VUOa0tE0Je 7citf0r+EGcaWzMIyDMRW3nVMkkoFQpS+DHTo7gGSZFekg2YjzSUZQ7Q X-Gm-Gg: AYBFou0tQeZxSKp3XTkUbzxdGg0QIojFJFukU3DOoBMJUs1BP7get42pVKDGVVHnz6A Tso1Ag68mE99+CljeHPHhFKCxdlYkphtTDMVGgNHa1I+Q8UM/Q6+Ufc2wCLevgXHYFm2C0e05Sb vHqUiA6Av/NwqtmmNc50+PEP/6p5F4keOxajXN45hyT9Td0axJa6hogUKGfK3I5/KKWqzkgqgJq yXyYHPg59tsi0esLQMhW5tWW88bAcZllTRlm5n7HURzUSqq040owBcf7Dj3/jD4q4Wp9tIraoOD VNn1JTJpfYPbfkMS9iB+Xn7L5tA26PqzryyWGkxRLE7A8JRiCf4exjrS+Jzs3CP+/uarlV8oskO HsYPoQyUrLg001lhOy2+5i6t49yOToSYjh8Lhiw8ur3e50/6AQxaKxTRuQ//bbaErDjxB0WCKf8 a4w9zcdM38ubNhYxj0sI/hJuSmN/UL53oTrW0lOkv0Wx25OXlFCYK6mFh913FFZwNdIoi8mnjO+ WGzEcyTN0qwEGWSZy3HlA4961P+arf+43YzjTk= X-Received: by 2002:a17:902:ec81:b0:2dd:c100:80b2 with SMTP id d9443c01a7336-2df60b61d54mr3177535ad.45.1790061715434; Tue, 22 Sep 2026 00:21:55 -0700 (PDT) From: Yuchao Zhang To: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Juergen Gross , Stefano Stabellini , Jens Axboe Cc: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Yuchao Zhang Subject: Re: [PATCH 1/1] xen-blkfront: unbind irq before tearing down ring and shadow requests Date: Tue, 22 Sep 2026 15:21:46 +0800 Message-ID: <20260922072146.34611-1-ndaugoing@gmail.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790061717-C1CD7B50-F5E84877/0/0 X-purgate-type: clean X-purgate-size: 516 Hi Roger, Thanks for the review and catching the right origin commit. You are completely right: commit 11659569f720 ("xen/blkfront: split per device io_lock") removed the lock protection from the interrupt handler and introduced the race window. I have updated the Fixes tag to point to 11659569f720 and added the requested comment before unbind_from_irqhandler() explaining that interrupt teardown must precede queue data cleanup. v2 patch has been sent as reply to this thread. Thanks, Yuchao From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:22:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:22:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428253.1650986 (Exim 4.92) (envelope-from ) id 1x8upL-0007Vr-2n; Tue, 22 Sep 2026 07:22:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428253.1650986; Tue, 22 Sep 2026 07:22:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8upL-0007Vk-09; Tue, 22 Sep 2026 07:22:07 +0000 Received: by outflank-mailman (input) for mailman id 1428253; Tue, 22 Sep 2026 07:22:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8upJ-0007Sb-PG for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:22:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8upJ-00Emhp-5p for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:22:05 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22c98-e002-0a2a0a5209dd-0a2a4508eb76-14 for ; Tue, 22 Sep 2026 09:22:05 +0200 Received: from [74.125.228.43] (helo=mail-pz2-f43.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22c9b-f659-0a2a45080019-4a7de42b90f5-3 for ; Tue, 22 Sep 2026 09:22:04 +0200 Received: by mail-pz2-f43.google.com with SMTP id d2e1a72fcca58-85469a34908so3391216b3a.0 for ; Tue, 22 Sep 2026 00:22:04 -0700 (PDT) Received: from localhost.localdomain ([2409:8a1e:2e81:7320:b94b:d1b8:4cbd:b7e1]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cc756a317ccsm443117a12.14.2026.09.22.00.22.00 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 22 Sep 2026 00:22:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790061723; x=1790666523; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=YwywWDLrZalzz03FLTpDP9g/tBAvW+/0SJTZpW2eZ4M=; b=RuK/TTBImkyXQb3o7OjTT672ya12xkfQc5Dy3RTnystnwrdPiflVsTIiJPXOTT5Ki+ HvOAhu86y2/luLO1JBSaguzBpQtAX/VVroUzFOeDsZ6QbE8/pFkrWI+n4AhKPTc3Oy2B 58V2ms5S2TYJgUyj0eHaQ27GZNMoiM5osiF43n7q53c/E5+VWMSLZcCilAtRjKOzCQIv JFgVMOOsq21mlaGFrLGaWQVC02YCbwt338cJRQBDmMHJbHvI0XamBCZDhSYj72hOUmYA QWiBXUwNcfuEfM+FTqSpvJMU6mElNHEPvslydl6GBhd99H6jEhVPjHMtMHJUIcPgH25c Vjxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790061723; x=1790666523; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=YwywWDLrZalzz03FLTpDP9g/tBAvW+/0SJTZpW2eZ4M=; b=NF+5W3u7wPm6W1i5DArKqCp12PQ9JB4hVic399fJuksb9k7g8e01nTNKSlbhLjiQ03 PxrlgWROIdEj4qYCLxYbzB7xRI2KHR/LmPYsfeKEAJev+pnssKAirVaqrc5yAkSe8Hh8 ojLgdSGEMoO0PVaC4SA3OvuNJvAufmxtlNyl8BJsGvJ+Ps9hQhoBxDtDarQKwjM0Cb0P 2FVBom4OZ9pWQyXcX8yiAvtJmAffXluEg1ev6qI37lp3SxJVMdhL4Y9x1f3/h4+CSVE4 K07b8H7mmBtGlM9MHV3D9HBWBK+2jDHJMoniE/rprG8XodoJZpuzj3HAZeBOp1X89Skw D8fw== X-Forwarded-Encrypted: i=1; AKwUvBzPHiPdvEIqDze2HMBH3l+JZcvnAkYS8vLJFfJDpMoYungB8qKUgu0RZ3UuKJXamdVGs6k/OKHEryA=@lists.xenproject.org X-Gm-Message-State: AFuF++m3h4aopEAXY6bO1SNIQtPkv7mk9NB4CRRjXcTdgK1ZuKpz2PM8 MI+mbBiDoVc4raL7m/RJDzf7yad72cyvdPCk//s8+Wo0VBJfEI7tEU6t X-Gm-Gg: AYBFou2pEKOZIkUj1SXa9UARm3lbOXvhU74S3nsRa3Q06bA01CxOCKqB5uW388YcXI6 6LV1twBhMny4KI4qPOMoSNtLsj8FovMC+25CGBI37K8GS9N6GWJHKaLAVvHjuhh8zI2YZEssmjk qgD2QT+dz5Ja4DF6EPsDUdjUsDQ+x/7xePS17yuYswhhwGTrsyh+aGgPIo2/HyGxzWfA2SwkL96 fIaZW4qCeHwSC9OmWzbetxgba+ozVI9P/nW2YmACcQLPOuyQu7eGGE7PACe7+QgNtdI3E2vJFaO ttWzvFaQFrvUfx85lq3A67yRM5dwMnAVt1g9adMpR2jYiawu8nCXw8Kba4bXYi87ZIVY3EQ3gB8 UWC3hxmZnGfYwX2pIssZ54ZynMAiPVxEeMHFteHcvLqXdGjQgw984qEw0IEduetrMAvNkA1DPWk Js7kGCTX3+Gjl7EgWPQEGVo8WQKExD/tYKm4n9ya5wxO1ZGQ07YWHcf90IXch4dZIZaKU5zen3v Fov1cY9Yng0m+0siFDX+VXZXl9NlCp05Ftb0kU= X-Received: by 2002:a05:6a20:734f:b0:3dd:a007:cb35 with SMTP id adf61e73a8af0-3ddec82175emr329149637.49.1790061722924; Tue, 22 Sep 2026 00:22:02 -0700 (PDT) From: Yuchao Zhang To: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Juergen Gross , Stefano Stabellini , Jens Axboe Cc: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Yuchao Zhang Subject: [PATCH v2] xen-blkfront: unbind irq before tearing down ring and shadow requests Date: Tue, 22 Sep 2026 15:21:55 +0800 Message-ID: <20260922072155.34625-1-ndaugoing@gmail.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790061725-CCB7187B-A8CEF1EC/0/0 X-purgate-type: clean X-purgate-size: 2777 In blkif_free_ring(), the driver tears down the ring's persistent grants, shadow request arrays, and shared ring structure (xenbus_teardown_ring), and only calls unbind_from_irqhandler() at the very end. While blkif_free_ring() is freeing persistent grants and clearing the shadow array, the event channel interrupt (blkif_interrupt) is still registered and active. If an interrupt arrives from the backend during this teardown window, blkif_interrupt() reads rinfo->ring.sring and, via blkif_completion(), accesses rinfo->shadow[id].grants_used and rinfo->shadow[id].sg. blkif_free_ring() tears these structures down without holding rinfo->ring_lock, and the handler only checks info->connected at entry, so this is a real race resulting in a use-after-free or NULL pointer dereference. Fix this by moving unbind_from_irqhandler() to the beginning of blkif_free_ring(). Calling unbind_from_irqhandler() first frees the IRQ and synchronizes with any in-flight interrupt handlers on other CPUs before ring memory and shadow request structures are deallocated, matching the teardown order in drivers/net/xen-netfront.c. Fixes: 11659569f720 ("xen/blkfront: split per device io_lock") Cc: stable@vger.kernel.org Signed-off-by: Yuchao Zhang --- v2: - Update Fixes tag to 11659569f720 ("xen/blkfront: split per device io_lock") per Roger Pau Monné. - Add comment in blkif_free_ring() noting that interrupt teardown must precede freeing queue-related data. drivers/block/xen-blkfront.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8dad7bf5f664..86f5dd3aced1 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1210,6 +1210,14 @@ static void blkif_free_ring(struct blkfront_ring_info *rinfo) struct blkfront_info *info = rinfo->dev_info; int i, j, segs; + /* + * Interrupt teardown must be done ahead of freeing queue-related + * data, otherwise the interrupt handler can race with the cleanup. + */ + if (rinfo->irq) + unbind_from_irqhandler(rinfo->irq, rinfo); + rinfo->evtchn = rinfo->irq = 0; + /* * Remove indirect pages, this only happens when using indirect * descriptors but not persistent grants @@ -1292,10 +1300,6 @@ static void blkif_free_ring(struct blkfront_ring_info *rinfo) /* Free resources associated with old device channel. */ xenbus_teardown_ring((void **)&rinfo->ring.sring, info->nr_ring_pages, rinfo->ring_ref); - - if (rinfo->irq) - unbind_from_irqhandler(rinfo->irq, rinfo); - rinfo->evtchn = rinfo->irq = 0; } static void blkif_free(struct blkfront_info *info, int suspend) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:28:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:28:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428270.1651005 (Exim 4.92) (envelope-from ) id 1x8uvH-0000KF-UL; Tue, 22 Sep 2026 07:28:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428270.1651005; Tue, 22 Sep 2026 07:28:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvH-0000K8-RA; Tue, 22 Sep 2026 07:28:15 +0000 Received: by outflank-mailman (input) for mailman id 1428270; Tue, 22 Sep 2026 07:28:14 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvG-0000JU-If for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:28:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uvF-001rYI-IU for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:28:13 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22e0c-bab6-0a2a0a5309dd-0a2a450aa13e-8 for ; Tue, 22 Sep 2026 09:28:13 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22e0d-f2d2-0a2a450a0019-c387df8287ba-3 for ; Tue, 22 Sep 2026 09:28:13 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id CCED421BF7; Tue, 22 Sep 2026 07:28:04 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 63928139EE; Tue, 22 Sep 2026 07:28:04 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id WhhIDwQusmrYXQAAD6G6ig (envelope-from ); Tue, 22 Sep 2026 07:28:04 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062088; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gNU5oRuJIuG3Y0rVj31YQTVP9ThCsk+DPbMgbbWkpiE=; b=mC/lZ4tEt1WHa24yBI43/CGOU/wusKn6mMIAvhLl3zUA76Lm3quK7TY6g4W2YoDN491AMr dqoil3V+UOdjUBYp5LVTHUnHy5JJ9UPb4gAVyBoadNRlpp5Llc6YnOeyT4JKLOma//d3II DoilIbpm+vKbnlDvw5jpyaGCbXqjCS8= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062084; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gNU5oRuJIuG3Y0rVj31YQTVP9ThCsk+DPbMgbbWkpiE=; b=RF1h5M0QIuxPIW5VgPvIZfQ48eeut6pDRGfm3UXQuGKU0EFvKsCeDgnoLFrPOg4M31WnH9 C9yYBIWsBMCQ0G3jqa7nb8493emX3YILAXLhnt86rRygVLdU5h2/JLm5xwvzDzzReWxxxB XbJbzzxebXc1gXipolgPz8fKPCn6W54= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD , Andrew Cooper Subject: [PATCH v3 1/4] tools/libxenguest: remove Mini-OS specific parts Date: Tue, 22 Sep 2026 09:27:08 +0200 Message-ID: <20260922072711.385956-2-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260922072711.385956-1-jgross@suse.com> References: <20260922072711.385956-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.80 X-Spam-Level: X-Spamd-Result: default: False [-2.80 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.997]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; URIBL_BLOCKED(0.00)[citrix.com:email,suse.com:mid,suse.com:email]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-purgate-ID: tlsNG-4011c0/1790062093-528DDCFC-17E8130B/35/110847 X-purgate-type: clean X-purgate-size: 11536 The last Mini-OS use case of libxenguest is gone, so remove the Mini-OS specific parts of libxenguest. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper --- tools/libs/guest/Makefile.common | 15 ------ tools/libs/guest/xg_dom_decompress_unsafe.c | 48 ------------------- tools/libs/guest/xg_dom_decompress_unsafe.h | 28 ----------- .../guest/xg_dom_decompress_unsafe_bzip2.c | 14 ------ .../libs/guest/xg_dom_decompress_unsafe_lz4.c | 39 --------------- .../guest/xg_dom_decompress_unsafe_lzma.c | 14 ------ .../guest/xg_dom_decompress_unsafe_lzo1x.c | 44 ----------------- .../libs/guest/xg_dom_decompress_unsafe_xz.c | 46 ------------------ .../guest/xg_dom_decompress_unsafe_zstd.c | 44 ----------------- 9 files changed, 292 deletions(-) delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.h delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzma.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_xz.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_zstd.c diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common index 86b1f160e5..47b3a52360 100644 --- a/tools/libs/guest/Makefile.common +++ b/tools/libs/guest/Makefile.common @@ -1,8 +1,3 @@ -ifeq ($(CONFIG_LIBXC_MINIOS),y) -# Save/restore of a domain is currently incompatible with a stubdom environment -override CONFIG_MIGRATE := n -endif - OBJS-y += xg_private.o OBJS-y += xg_domain.o OBJS-y += xg_suspend.o @@ -55,16 +50,6 @@ OBJS-$(CONFIG_X86) += xg_dom_x86.o OBJS-$(CONFIG_X86) += xg_cpuid_x86.o OBJS-$(CONFIG_ARM) += xg_dom_arm.o -ifeq ($(CONFIG_LIBXC_MINIOS),y) -OBJS-y += xg_dom_decompress_unsafe.o -OBJS-y += xg_dom_decompress_unsafe_bzip2.o -OBJS-y += xg_dom_decompress_unsafe_lz4.o -OBJS-y += xg_dom_decompress_unsafe_lzma.o -OBJS-y += xg_dom_decompress_unsafe_lzo1x.o -OBJS-y += xg_dom_decompress_unsafe_xz.o -OBJS-y += xg_dom_decompress_unsafe_zstd.o -endif - CFLAGS += -D__XEN_TOOLS__ CFLAGS += -include $(XEN_ROOT)/tools/config.h CFLAGS += -iquote ../../../xen/common/libelf diff --git a/tools/libs/guest/xg_dom_decompress_unsafe.c b/tools/libs/guest/xg_dom_decompress_unsafe.c deleted file mode 100644 index 21d964787d..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe.c +++ /dev/null @@ -1,48 +0,0 @@ -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -static struct xc_dom_image *unsafe_dom; -static unsigned char *output_blob; -static unsigned int output_size; - -static void unsafe_error(const char *msg) -{ - xc_dom_panic(unsafe_dom->xch, XC_INVALID_KERNEL, "%s", msg); -} - -static int unsafe_flush(void *src, unsigned int size) -{ - void *n = realloc(output_blob, output_size + size); - if (!n) - return -1; - output_blob = n; - - memcpy(&output_blob[output_size], src, size); - output_size += size; - return size; -} - -int xc_dom_decompress_unsafe( - decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size) -{ - int ret; - - unsafe_dom = dom; - output_blob = NULL; - output_size = 0; - - ret = fn(dom->kernel_blob, dom->kernel_size, NULL, unsafe_flush, NULL, NULL, unsafe_error); - - if (ret) - free(output_blob); - else { - *blob = output_blob; - *size = output_size; - } - - return ret; -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe.h b/tools/libs/guest/xg_dom_decompress_unsafe.h deleted file mode 100644 index 5bc2222076..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe.h +++ /dev/null @@ -1,28 +0,0 @@ -#ifdef __MINIOS__ -# include "../../xen/include/xen/decompress.h" -#else -typedef int decompress_fn(unsigned char *inbuf, unsigned int len, - int (*fill)(void*, unsigned int), - int (*flush)(void*, unsigned int), - unsigned char *outbuf, unsigned int *posp, - void (*error)(const char *x)); -#endif - -#define cf_check /* No Control Flow Integriy checking */ - -int xc_dom_decompress_unsafe( - decompress_fn fn, struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); - -int xc_try_bzip2_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_lz4_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_lzma_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_lzo1x_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_xz_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); -int xc_try_zstd_decode(struct xc_dom_image *dom, void **blob, size_t *size) - __attribute__((visibility("internal"))); diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c b/tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c deleted file mode 100644 index 9d3709e6cc..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c +++ /dev/null @@ -1,14 +0,0 @@ -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -#include "../../xen/common/bunzip2.c" - -int xc_try_bzip2_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(bunzip2, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_lz4.c b/tools/libs/guest/xg_dom_decompress_unsafe_lz4.c deleted file mode 100644 index 405143aa61..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_lz4.c +++ /dev/null @@ -1,39 +0,0 @@ -#include -#include -#include -#include - -#include INCLUDE_ENDIAN_H - -#define XG_NEED_UNALIGNED -#include "xg_private.h" -#include "xg_dom_decompress.h" - -#define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS - -typedef uint8_t u8; -typedef uint16_t u16; -typedef uint32_t u32; -typedef uint64_t u64; - -#define likely(a) a -#define unlikely(a) a - -static inline uint16_t le16_to_cpu(uint16_t v) -{ -#if BYTE_ORDER == BIG_ENDIAN - return __builtin_bswap16(v); -#else - return v; -#endif -} - -#include "../../xen/include/xen/lz4.h" -#include "../../xen/common/decompress.h" -#include "../../xen/common/unlz4.c" - -int xc_try_lz4_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unlz4, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_lzma.c b/tools/libs/guest/xg_dom_decompress_unsafe_lzma.c deleted file mode 100644 index 5d178f0c43..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_lzma.c +++ /dev/null @@ -1,14 +0,0 @@ -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -#include "../../xen/common/unlzma.c" - -int xc_try_lzma_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unlzma, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c b/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c deleted file mode 100644 index 356f228718..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c +++ /dev/null @@ -1,44 +0,0 @@ -#include -#include -#include -#include INCLUDE_ENDIAN_H -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -typedef uint8_t u8; -typedef uint32_t u32; -typedef uint16_t u16; -typedef uint64_t u64; - -#define likely(a) a -#define noinline -#define unlikely(a) a - -static inline uint16_t be16_to_cpu(const uint16_t v) -{ -#if BYTE_ORDER == LITTLE_ENDIAN - return __builtin_bswap16(v); -#else - return v; -#endif -} - -static inline uint32_t be32_to_cpu(const uint32_t v) -{ -#if BYTE_ORDER == LITTLE_ENDIAN - return __builtin_bswap32(v); -#else - return v; -#endif -} - -#include "../../xen/common/lzo.c" -#include "../../xen/common/unlzo.c" - -int xc_try_lzo1x_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unlzo, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c deleted file mode 100644 index 0501f7f693..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c +++ /dev/null @@ -1,46 +0,0 @@ -#include -#include INCLUDE_ENDIAN_H -#include -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -// TODO -#define XZ_DEC_X86 - -typedef uint8_t u8; -typedef uint16_t u16; -typedef uint32_t u32; -typedef uint32_t __le32; - -static inline uint32_t cpu_to_le32(const uint32_t v) -{ -#if BYTE_ORDER == BIG_ENDIAN - return __builtin_bswap32(v); -#else - return v; -#endif -} - -static inline uint32_t le32_to_cpu(const uint32_t v) -{ -#if BYTE_ORDER == BIG_ENDIAN - return __builtin_bswap32(v); -#else - return v; -#endif -} - -#define __force -#define always_inline - -#include "../../xen/common/unxz.c" - -int xc_try_xz_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unxz, dom, blob, size); -} diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c deleted file mode 100644 index 319816a390..0000000000 --- a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c +++ /dev/null @@ -1,44 +0,0 @@ -#include -#include INCLUDE_ENDIAN_H -#include -#include -#include -#include - -#include "xg_private.h" -#include "xg_dom_decompress_unsafe.h" - -typedef uint8_t u8; - -typedef uint16_t __u16; -typedef uint32_t __u32; -typedef uint64_t __u64; - -typedef uint16_t __le16; -typedef uint32_t __le32; -typedef uint64_t __le64; - -typedef uint16_t __be16; -typedef uint32_t __be32; -typedef uint64_t __be64; - -#define attr_const -#define __force -#define always_inline -#define noinline -#define __packed __attribute__((__packed__)) - -#undef ERROR - -#define __TYPES_H__ /* xen/types.h guard */ -#include "../../xen/include/xen/byteorder.h" -#include "../../xen/include/xen/unaligned.h" -#include "../../xen/include/xen/xxhash.h" -#include "../../xen/lib/xxhash64.c" -#include "../../xen/common/unzstd.c" - -int xc_try_zstd_decode( - struct xc_dom_image *dom, void **blob, size_t *size) -{ - return xc_dom_decompress_unsafe(unzstd, dom, blob, size); -} -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:28:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:28:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428269.1650996 (Exim 4.92) (envelope-from ) id 1x8uvD-00005y-Nb; Tue, 22 Sep 2026 07:28:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428269.1650996; Tue, 22 Sep 2026 07:28:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvD-00005r-KZ; Tue, 22 Sep 2026 07:28:11 +0000 Received: by outflank-mailman (input) for mailman id 1428269; Tue, 22 Sep 2026 07:28:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvD-00005l-1N for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:28:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uvC-006ohb-9e for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:28:10 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22e01-bab6-0a2a0a5309dd-0a2a4507de46-12 for ; Tue, 22 Sep 2026 09:28:10 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22e07-b4ea-0a2a45070019-c387df83b9da-3 for ; Tue, 22 Sep 2026 09:28:07 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 3AAFB1F795; Tue, 22 Sep 2026 07:27:59 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id BB02A136D9; Tue, 22 Sep 2026 07:27:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id jCX2Iv4tsmrOXQAAD6G6ig (envelope-from ); Tue, 22 Sep 2026 07:27:58 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062083; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=LJn2zeN0M+10y/8TBN7n6W0PJIw8Oa1ZM82bWvdXuUg=; b=Hw7DaKrtvFw8/YlzhggqrZHR3TzZOgS7UM8IcC7CKMpUnvqDlx6qnpFvPZQT+tQA0E2HBH j6pAcsDMXOEzkK2lRI0cyj4cJdPVoc8Moq0nGYcZtvsA3fqXTavPEFl7nrMI9UWONqMsA8 8xkcBgsds3bWAaBcJjK97Hc3VtUNexc= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=cDe4KhP7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062079; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=LJn2zeN0M+10y/8TBN7n6W0PJIw8Oa1ZM82bWvdXuUg=; b=cDe4KhP7M3sVEdaqiTT90T26NED0phcPXSm/AX8AB3Wt9QIPUUlebzmYBhHT0VZCPEO8ZY pudiVAsSFob8RpVXKF45yNcEPZLcXY6vcxAKq9IpOP0LSo49ETB+to4wXKZPahgumZcKa6 yxhKUWbvj5FTRWMGHkJtguVXTdzOk3A= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD , Samuel Thibault , Oleksii Kurochko , Community Manager Subject: [PATCH v3 0/4] stubdom: remove building unused libraries Date: Tue, 22 Sep 2026 09:27:07 +0200 Message-ID: <20260922072711.385956-1-jgross@suse.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.51 X-Rspamd-Queue-Id: 3AAFB1F795 X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Level: X-Rspamd-Action: no action X-Spamd-Result: default: False [-1.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_DN_SOME(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; URIBL_BLOCKED(0.00)[suse.com:dkim,suse.com:mid]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[suse.com,vates.tech,ens-lyon.org,gmail.com,xenproject.org]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,changelog.md:url,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]; TAGGED_RCPT(0.00)[]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received]; DKIM_TRACE(0.00)[suse.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com] X-Spam-Flag: NO X-purgate-ID: tlsNG-ef75cf/1790062087-A4AC8AE4-B1AAC23C/35/110847 X-purgate-type: clean X-purgate-size: 2473 Pciutils and zlib are no longer used by any stubdom since removal of grub-pv, so they can be removed from the stubdom build system. Changes in V2: - removed patch 1 of V1 as already applied - added new patch 1 from another series which was not yet applied - switched sequence of patches (swapped patch 2 and 3), as the drop of pciutils is still under discussion Changes in V3: - undo the patch swap of V2 due to patch dependencies - add comment in patch 2 pointing at upstream pciutils Juergen Gross (4): tools/libxenguest: remove Mini-OS specific parts stubdom: remove pciutils stubdom: remove build of zlib CHANGELOG: add removal of grub-pv CHANGELOG.md | 2 + config/Stubdom.mk.in | 6 - stubdom/.gitignore | 2 - stubdom/Makefile | 56 +--- stubdom/configure | 36 --- stubdom/configure.ac | 2 - stubdom/libpci.config.h | 5 - stubdom/libpci.config.mak | 7 - stubdom/pciutils.patch | 298 ------------------ tools/libs/guest/Makefile.common | 15 - tools/libs/guest/xg_dom_decompress_unsafe.c | 48 --- tools/libs/guest/xg_dom_decompress_unsafe.h | 28 -- .../guest/xg_dom_decompress_unsafe_bzip2.c | 14 - .../libs/guest/xg_dom_decompress_unsafe_lz4.c | 39 --- .../guest/xg_dom_decompress_unsafe_lzma.c | 14 - .../guest/xg_dom_decompress_unsafe_lzo1x.c | 44 --- .../libs/guest/xg_dom_decompress_unsafe_xz.c | 46 --- .../guest/xg_dom_decompress_unsafe_zstd.c | 44 --- 18 files changed, 7 insertions(+), 699 deletions(-) delete mode 100644 stubdom/libpci.config.h delete mode 100644 stubdom/libpci.config.mak delete mode 100644 stubdom/pciutils.patch delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe.h delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_bzip2.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lz4.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzma.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_lzo1x.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_xz.c delete mode 100644 tools/libs/guest/xg_dom_decompress_unsafe_zstd.c -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:28:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:28:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428271.1651013 (Exim 4.92) (envelope-from ) id 1x8uvN-0000b1-9D; Tue, 22 Sep 2026 07:28:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428271.1651013; Tue, 22 Sep 2026 07:28:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvN-0000au-6A; Tue, 22 Sep 2026 07:28:21 +0000 Received: by outflank-mailman (input) for mailman id 1428271; Tue, 22 Sep 2026 07:28:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvL-0000Za-Ks for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:28:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uvL-00Eo3r-1U for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:28:19 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22df2-8faa-0a2a0a5109dd-0a2a450bdc5e-32 for ; Tue, 22 Sep 2026 09:28:18 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22e12-b7e8-0a2a450b0019-c387df8299a0-3 for ; Tue, 22 Sep 2026 09:28:18 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 456FA21BF8; Tue, 22 Sep 2026 07:28:10 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 00A5A136D9; Tue, 22 Sep 2026 07:28:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id X8CIMgkusmrhXQAAD6G6ig (envelope-from ); Tue, 22 Sep 2026 07:28:09 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062094; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=npFnjA2jMKW2pNnX2vyNdCreZVze0ugNf58tc8Gqhw4=; b=OuMD4OoYyQag6DCSCAk0IibNF6l0wCgjq1R/tgfD9tYZKoN6n/3+486SI08I9f6Ec4jWl5 9jfVQZ0h8SuGBlq+CAErSnnQWY2m03unNFI2apJbmxrjurnGGZnjQA2XsF7+o1cTSVoWU/ YVTo/LIrb1bVsqLjEX3sP6UsuMp9sCE= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=PHQfBRrk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062090; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=npFnjA2jMKW2pNnX2vyNdCreZVze0ugNf58tc8Gqhw4=; b=PHQfBRrkSmM0tWdcBHDrGTHnYEgiyuv2lNLE7TA//9f06AX/JBMYDwkxLeW9cZnI0Vp2iL md0wWyyocMdILhzSMToSXJkN3chMd8Bo1sxDpCs1+pIFPt9B8esYpYtT9pnN6OYaTq1mPg lc5t100noKIlGcRbYiawk24PCsjUEsE= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Samuel Thibault , Anthony PERARD Subject: [PATCH v3 2/4] stubdom: remove pciutils Date: Tue, 22 Sep 2026 09:27:09 +0200 Message-ID: <20260922072711.385956-3-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260922072711.385956-1-jgross@suse.com> References: <20260922072711.385956-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -3.01 X-Rspamd-Queue-Id: 456FA21BF8 X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Level: X-Rspamd-Action: no action X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email,suse.com:mid,gnu.org:url,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; URIBL_BLOCKED(0.00)[gnu.org:url,suse.com:dkim,suse.com:email,suse.com:mid,citrix.com:email]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[suse.com:+] X-Spam-Flag: NO X-purgate-ID: tlsNG-42698a/1790062098-18CCF9EA-AA00819F/35/110847 X-purgate-type: clean X-purgate-size: 16442 There is no user of libpci left in stubdoms. Remove libpci from the stubdom build system. Signed-off-by: Juergen Gross --- V3: - add comment regarding upstream pciutils (Samuel Thibault) --- config/Stubdom.mk.in | 3 - stubdom/.gitignore | 1 - stubdom/Makefile | 36 +---- stubdom/configure | 21 --- stubdom/configure.ac | 1 - stubdom/libpci.config.h | 5 - stubdom/libpci.config.mak | 7 - stubdom/pciutils.patch | 298 -------------------------------------- 8 files changed, 6 insertions(+), 366 deletions(-) delete mode 100644 stubdom/libpci.config.h delete mode 100644 stubdom/libpci.config.mak delete mode 100644 stubdom/pciutils.patch diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in index 0d70d03941..b90eaee75a 100644 --- a/config/Stubdom.mk.in +++ b/config/Stubdom.mk.in @@ -14,9 +14,6 @@ STUBDOM_INSTALL := @STUBDOM_INSTALL@ ZLIB_VERSION := @ZLIB_VERSION@ ZLIB_URL := @ZLIB_URL@ -LIBPCI_VERSION := @LIBPCI_VERSION@ -LIBPCI_URL := @LIBPCI_URL@ - NEWLIB_VERSION := @NEWLIB_VERSION@ NEWLIB_URL := @NEWLIB_URL@ diff --git a/stubdom/.gitignore b/stubdom/.gitignore index 08f2e9b432..8c6dc00f83 100644 --- a/stubdom/.gitignore +++ b/stubdom/.gitignore @@ -23,7 +23,6 @@ /mk-headers-* /newlib-1.* /newlib-x86* -/pciutils-* /pkg-config/* /polarssl-* /tpm_emulator-* diff --git a/stubdom/Makefile b/stubdom/Makefile index 40b6ececf1..254f8d2fc8 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -122,33 +122,10 @@ $(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) $(MAKE) DESTDIR= libz.a && \ $(MAKE) DESTDIR= install ) -############## -# Cross-libpci -############## - -pciutils-$(LIBPCI_VERSION).tar.bz2: - $(FETCHER) $@ $(LIBPCI_URL)/$@ - -pciutils-$(XEN_TARGET_ARCH): pciutils-$(LIBPCI_VERSION).tar.bz2 - tar xjf $< - mv pciutils-$(LIBPCI_VERSION) $@ - patch -d $@ -p1 < pciutils.patch - touch $@ - -LIBPCI_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libpci.a -.PHONY: cross-libpci -cross-libpci: $(LIBPCI_STAMPFILE) -$(LIBPCI_STAMPFILE): pciutils-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) $(ZLIB_STAMPFILE) - ( cd $< && \ - cp ../libpci.config.h lib/config.h && \ - chmod u+w lib/config.h && \ - echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h && \ - ln -sf ../../libpci.config.mak lib/config.mk && \ - $(MAKE) DESTDIR= CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \ - $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/ && \ - $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci && \ - $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \ - ) +####################################################################### +# There used to be a slightly modified version of pciutils, this is now +# available under https://github.com/pciutils/pciutils/pull/236 +####################################################################### ###### # lwIP @@ -250,7 +227,7 @@ cross-tpmemu: $(TPMEMU_STAMPFILE) ####### .PHONY: $(CROSS_ROOT) -$(CROSS_ROOT): cross-newlib cross-zlib cross-libpci +$(CROSS_ROOT): cross-newlib cross-zlib ####### # libraries under tools/libs @@ -477,7 +454,7 @@ clean: crossclean: clean rm -fr $(CROSS_ROOT) rm -fr newlib-$(XEN_TARGET_ARCH) - rm -fr zlib-$(XEN_TARGET_ARCH) pciutils-$(XEN_TARGET_ARCH) + rm -fr zlib-$(XEN_TARGET_ARCH) rm -fr libs-$(XEN_TARGET_ARCH) rm -fr xenstore xenstorepvh rm -fr gmp-$(XEN_TARGET_ARCH) @@ -502,7 +479,6 @@ downloadclean: patchclean rm -f zlib-$(ZLIB_VERSION).tar.gz rm -f gmp-$(GMP_VERSION).tar.bz2 rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz - rm -f pciutils-$(LIBPCI_VERSION).tar.bz2 rm -f lwip-$(LWIP_VERSION).tar.gz rm -f polarssl-$(POLARSSL_VERSION)-gpl.tgz diff --git a/stubdom/configure b/stubdom/configure index 689ff4d6ed..f3d63dceff 100755 --- a/stubdom/configure +++ b/stubdom/configure @@ -634,8 +634,6 @@ LWIP_VERSION LWIP_URL NEWLIB_VERSION NEWLIB_URL -LIBPCI_VERSION -LIBPCI_URL ZLIB_VERSION ZLIB_URL INSTALL_DATA @@ -725,7 +723,6 @@ LDFLAGS LIBS CPPFLAGS ZLIB_URL -LIBPCI_URL NEWLIB_URL LWIP_URL GMP_URL @@ -1376,7 +1373,6 @@ Some influential environment variables: CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory ZLIB_URL Download url for zlib - LIBPCI_URL Download url for libpci NEWLIB_URL Download url for newlib LWIP_URL Download url for lwip GMP_URL Download url for libgmp @@ -4038,23 +4034,6 @@ ZLIB_VERSION="1.2.3" -if test "x$LIBPCI_URL" = "x" -then : - - if test "x$extfiles" = "xy" -then : - LIBPCI_URL=\$\(XEN_EXTFILES_URL\) -else $as_nop - LIBPCI_URL="https://mirrors.edge.kernel.org/pub/software/utils/pciutils" -fi - -fi -LIBPCI_VERSION="2.2.9" - - - - - if test "x$NEWLIB_URL" = "x" then : diff --git a/stubdom/configure.ac b/stubdom/configure.ac index 6ff3ab0ee9..d3d2a840d3 100644 --- a/stubdom/configure.ac +++ b/stubdom/configure.ac @@ -39,7 +39,6 @@ AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake]) # Stubdom libraries version and url setup AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3]) -AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], [https://mirrors.edge.kernel.org/pub/software/utils/pciutils]) AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], [https://sourceware.org/ftp/newlib]) AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], [https://download.savannah.gnu.org/releases/lwip]) AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [https://gmplib.org/download/gmp/archive]) diff --git a/stubdom/libpci.config.h b/stubdom/libpci.config.h deleted file mode 100644 index 28c2f6ab31..0000000000 --- a/stubdom/libpci.config.h +++ /dev/null @@ -1,5 +0,0 @@ -#define PCI_OS_MINIOS -#define PCI_HAVE_STDINT_H -#define PCI_PATH_IDS_DIR "." -#define PCI_COMPRESSED_IDS -#define PCI_IDS "pci.ids.gz" diff --git a/stubdom/libpci.config.mak b/stubdom/libpci.config.mak deleted file mode 100644 index 5c8632cf07..0000000000 --- a/stubdom/libpci.config.mak +++ /dev/null @@ -1,7 +0,0 @@ -LIBZ=-lz -LDLIBS+=$(LIBZ) -PCI_OS_MINIOS=1 -PCI_HAVE_STDINT_H=1 -PCI_PATH_IDS_DIR=. -PCI_COMPRESSED_IDS=1 -PCI_IDS=pci.ids.gz diff --git a/stubdom/pciutils.patch b/stubdom/pciutils.patch deleted file mode 100644 index 5ab84d6cce..0000000000 --- a/stubdom/pciutils.patch +++ /dev/null @@ -1,298 +0,0 @@ -diff -urN pciutils-2.2.9.orig/lib/access.c pciutils-2.2.9/lib/access.c ---- pciutils-2.2.9.orig/lib/access.c 2007-02-06 11:59:43.000000000 +0000 -+++ pciutils-2.2.9/lib/access.c 2008-06-30 19:07:09.713187000 +0100 -@@ -57,6 +57,11 @@ - #else - NULL, - #endif -+#ifdef PCI_OS_MINIOS -+ &pm_minios, -+#else -+ NULL, -+#endif - }; - - struct pci_access * ---- pciutils-2.2.9.orig/lib/pci.h 2006-09-09 13:46:06.000000000 +0100 -+++ pciutils-2.2.9/lib/pci.h 2008-06-30 18:56:15.350111000 +0100 -@@ -33,6 +33,7 @@ - PCI_ACCESS_NBSD_LIBPCI, /* NetBSD libpci */ - PCI_ACCESS_OBSD_DEVICE, /* OpenBSD /dev/pci */ - PCI_ACCESS_DUMP, /* Dump file (params: filename) */ -+ PCI_ACCESS_MINIOS, /* MiniOS */ - PCI_ACCESS_MAX - }; - ---- pciutils-2.2.9.orig/lib/internal.h 2006-09-09 11:52:47.000000000 +0100 -+++ pciutils-2.2.9/lib/internal.h 2008-07-01 10:46:24.968202000 +0100 -@@ -37,4 +37,4 @@ - - extern struct pci_methods pm_intel_conf1, pm_intel_conf2, pm_linux_proc, - pm_fbsd_device, pm_aix_device, pm_nbsd_libpci, pm_obsd_device, -- pm_dump, pm_linux_sysfs; -+ pm_dump, pm_linux_sysfs, pm_minios; ---- pciutils-2.2.9.orig/lib/Makefile 2007-10-19 13:41:34.000000000 +0100 -+++ pciutils-2.2.9/lib/Makefile 2008-07-01 12:13:14.400525000 +0100 -@@ -46,6 +46,12 @@ - PCILIB=libpciutils.a - endif - -+ifdef PCI_OS_MINIOS -+XEN_ROOT=$(CURDIR)/../../.. -+include $(XEN_ROOT)/Config.mk -+OBJS += minios.o -+endif -+ - all: $(PCILIB) $(PCILIBPC) - - $(PCILIB): $(OBJS) ---- pciutils-2.2.9.orig/lib/types.h 2009-07-14 18:18:59.000000000 +0200 -+++ pciutils-2.2.9/lib/types.h 2009-07-14 18:19:16.000000000 +0200 -@@ -20,10 +20,12 @@ typedef DWORD u32; - typedef uint8_t u8; - typedef uint16_t u16; - typedef uint32_t u32; -+typedef uint64_t u64; - #else - typedef u_int8_t u8; - typedef u_int16_t u16; - typedef u_int32_t u32; -+typedef u_int64_t u64; - #endif - - #ifdef PCI_HAVE_64BIT_ADDRESS - ---- pciutils-2.2.9.orig/lib/minios.c 1970-01-01 01:00:00.000000000 +0100 -+++ pciutils-2.2.9/lib/minios.c 2008-07-01 12:31:40.554260000 +0100 -@@ -0,0 +1,106 @@ -+/* -+ * The PCI Library -- MiniOS PCI frontend access -+ * -+ * Samuel Thibault , 2008 -+ * -+ * Can be freely distributed and used under the terms of the GNU GPL. -+ */ -+ -+#include -+#include -+#include -+#include "internal.h" -+ -+static int -+minios_detect(struct pci_access *a) -+{ -+ return 1; -+} -+ -+static void -+minios_init(struct pci_access *a) -+{ -+} -+ -+static void -+minios_cleanup(struct pci_access *a) -+{ -+ shutdown_pcifront(NULL); -+} -+ -+static void -+minios_scan(struct pci_access *a) -+{ -+ void func(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun) -+ { -+ struct pci_dev *d = pci_alloc_dev(a); -+ -+ d->domain = domain; -+ d->bus = bus; -+ d->dev = slot; -+ d->func = fun; -+ -+ pci_link_dev(a, d); -+ } -+ -+ pcifront_scan(NULL, func); -+} -+ -+static int -+minios_read(struct pci_dev *d, int pos, byte *buf, int len) -+{ -+ unsigned int val; -+ switch (len) { -+ case 1: -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) -+ return 0; -+ * buf = val; -+ return 1; -+ case 2: -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) -+ return 0; -+ *(u16 *) buf = cpu_to_le16((u16) val); -+ return 1; -+ case 4: -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) -+ return 0; -+ *(u32 *) buf = cpu_to_le32((u32) val); -+ return 1; -+ default: -+ return pci_generic_block_read(d, pos, buf, len); -+ } -+} -+ -+static int -+minios_write(struct pci_dev *d, int pos, byte *buf, int len) -+{ -+ unsigned int val; -+ switch (len) { -+ case 1: -+ val = * buf; -+ break; -+ case 2: -+ val = le16_to_cpu(*(u16 *) buf); -+ break; -+ case 4: -+ val = le32_to_cpu(*(u32 *) buf); -+ break; -+ default: -+ return pci_generic_block_write(d, pos, buf, len); -+ } -+ return !pcifront_conf_write(NULL, d->domain, d->bus, d->dev, d->func, pos, len, val); -+} -+ -+struct pci_methods pm_minios = { -+ "MiniOS-device", -+ NULL, /* config */ -+ minios_detect, -+ minios_init, -+ minios_cleanup, -+ minios_scan, -+ pci_generic_fill_info, -+ minios_read, -+ minios_write, -+ NULL, /* dev_init */ -+ NULL /* dev_cleanup */ -+}; ---- pciutils-2.2.9/lib/generic.c 2007-02-06 12:00:05.000000000 +0000 -+++ pciutils-2.2.9-mine/lib/generic.c 2008-07-01 19:13:52.289949000 +0100 -@@ -74,6 +74,19 @@ - pci_generic_scan_bus(a, busmap, 0); - } - -+static u32 pci_size(u32 base, u32 maxbase, u32 mask) -+{ -+ u32 size = mask & maxbase; -+ if (!size) -+ return 0; -+ size = (size & ~(size-1)) - 1; -+ -+ if (base == maxbase && ((base | size) & mask) != mask) -+ return 0; -+ -+ return size + 1; -+} -+ - int - pci_generic_fill_info(struct pci_dev *d, int flags) - { -@@ -114,23 +127,61 @@ - if (!x || x == (u32) ~0) - continue; - if ((x & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) -- d->base_addr[i] = x; -- else -+ { -+ d->base_addr[i] = x & PCI_BASE_ADDRESS_IO_MASK; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); -+ d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_IO_MASK); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x); -+ } -+ } -+ else - { - if ((x & PCI_BASE_ADDRESS_MEM_TYPE_MASK) != PCI_BASE_ADDRESS_MEM_TYPE_64) -- d->base_addr[i] = x; -+ { -+ d->base_addr[i] = x & PCI_BASE_ADDRESS_MEM_MASK; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); -+ d->size[i] = pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4); -+ d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_MEM_MASK); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x); -+ } -+ } - else if (i >= cnt-1) - a->warning("%04x:%02x:%02x.%d: Invalid 64-bit address seen for BAR %d.", d->domain, d->bus, d->dev, d->func, i); - else - { - u32 y = pci_read_long(d, PCI_BASE_ADDRESS_0 + (++i)*4); - #ifdef PCI_HAVE_64BIT_ADDRESS -- d->base_addr[i-1] = x | (((pciaddr_t) y) << 32); -+ d->base_addr[i-1] = (x | (((pciaddr_t) y) << 32)) & PCI_BASE_ADDRESS_MEM_MASK; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); -+ d->size[i-1] = pci_size(y, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4) | -+ pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), 0xffffffff ); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, y); -+ } - #else - if (y) - a->warning("%04x:%02x:%02x.%d 64-bit device address ignored.", d->domain, d->bus, d->dev, d->func); - else -- d->base_addr[i-1] = x; -+ { -+ d->base_addr[i-1] = x & PCI_BASE_ADDRESS_MEM_MASK; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0); -+ d->size[i-1] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4), PCI_BASE_ADDRESS_MEM_MASK); -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x); -+ } -+ } - #endif - } - } -@@ -154,10 +205,19 @@ - { - u32 u = pci_read_long(d, reg); - if (u != 0xffffffff) -- d->rom_base_addr = u; -+ { -+ d->rom_base_addr = u; -+ if (flags & PCI_FILL_SIZES) -+ { -+ u32 size; -+ pci_write_long(d, reg, ~0); -+ d->rom_size = pci_read_long(d, reg); -+ pci_write_long(d, reg, u); -+ } -+ } - } - } -- return flags & ~PCI_FILL_SIZES; -+ return flags; - } - - static int -diff -uNpbE -uNpbEr pciutils-2.2.9.orig/lib/sysdep.h pciutils-2.2.9/lib/sysdep.h ---- pciutils-2.2.9.orig/lib/sysdep.h 2007-02-06 12:00:18.000000000 +0000 -+++ pciutils-2.2.9/lib/sysdep.h 2009-07-22 16:26:30.000000000 +0100 -@@ -32,6 +32,10 @@ typedef u16 word; - - #else - -+#ifdef PCI_OS_MINIOS -+#include -+#endif -+ - #ifdef PCI_OS_LINUX - #include - #define BYTE_ORDER __BYTE_ORDER -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:28:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:28:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428273.1651024 (Exim 4.92) (envelope-from ) id 1x8uvS-0000sq-Is; Tue, 22 Sep 2026 07:28:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428273.1651024; Tue, 22 Sep 2026 07:28:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvS-0000sh-EF; Tue, 22 Sep 2026 07:28:26 +0000 Received: by outflank-mailman (input) for mailman id 1428273; Tue, 22 Sep 2026 07:28:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvR-0000r7-4W for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:28:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uvQ-00Eo3r-H0 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:28:24 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22e18-8faa-0a2a0a5109dd-0a2a45018594-0 for ; Tue, 22 Sep 2026 09:28:24 +0200 Received: from [195.135.223.130] (helo=smtp-out1.suse.de) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22e18-5984-0a2a45010019-c387df82a256-3 for ; Tue, 22 Sep 2026 09:28:24 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D791E21B41; Tue, 22 Sep 2026 07:28:15 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 90275139EE; Tue, 22 Sep 2026 07:28:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 9yUzGg8usmroXQAAD6G6ig (envelope-from ); Tue, 22 Sep 2026 07:28:15 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062100; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4Tjr53TjzcY2Euedmp8hrOEc/dVhYgBczdwHGnlXh3I=; b=khWsM89GcYA3GmZK4tEG5MibBYrKM2jGN4fay/U4NmK86rl6nQsxlujDNpkbdwQbYdh7YH A1k0KAfHyX4MLX2FWcbRePtA6p8yRFfwSl4FQiOASqvFNtHfxVGfh5ANPO+RO/7lQVfxeC 03+lHCc9MUVsKL0TgSqA1Q+5rK8yDtk= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=hButAnh+ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062095; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4Tjr53TjzcY2Euedmp8hrOEc/dVhYgBczdwHGnlXh3I=; b=hButAnh+DgsJr29lUq3PqaQGoq3ZofNiuxYx96sB5oxBh3ve7pIBPdJkn3eD9ZUyZIeChg Lsgur0FGs9qd/+c8SPTRxjVUrIIF2fW95u0oj2d0nPIeH30KvHklZBIEh8S8ftCKZfSxyj QePI4lVwszQhEXOCCKZvJDD8q7z5pjQ= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD , Samuel Thibault Subject: [PATCH v3 3/4] stubdom: remove build of zlib Date: Tue, 22 Sep 2026 09:27:10 +0200 Message-ID: <20260922072711.385956-4-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260922072711.385956-1-jgross@suse.com> References: <20260922072711.385956-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: D791E21B41 X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[gnu.org:url,suse.com:dkim,suse.com:email,suse.com:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]; URIBL_BLOCKED(0.00)[gnu.org:url,suse.com:dkim,suse.com:email,suse.com:mid,ens-lyon.org:email]; DKIM_TRACE(0.00)[suse.com:+] X-Spam-Flag: NO X-Spam-Score: -3.01 X-purgate-ID: tlsNG-d62444/1790062104-1F46D757-3C6A3E53/35/110847 X-purgate-type: clean X-purgate-size: 4680 The last users of zlib for stubdoms have been removed. Remove zlib from the stubdom build system, too. Signed-off-by: Juergen Gross Acked-by: Samuel Thibault --- config/Stubdom.mk.in | 3 --- stubdom/.gitignore | 1 - stubdom/Makefile | 24 +----------------------- stubdom/configure | 15 --------------- stubdom/configure.ac | 1 - 5 files changed, 1 insertion(+), 43 deletions(-) diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in index b90eaee75a..dc0a3b54b3 100644 --- a/config/Stubdom.mk.in +++ b/config/Stubdom.mk.in @@ -11,9 +11,6 @@ STUBDOM_TARGETS := @STUBDOM_TARGETS@ STUBDOM_BUILD := @STUBDOM_BUILD@ STUBDOM_INSTALL := @STUBDOM_INSTALL@ -ZLIB_VERSION := @ZLIB_VERSION@ -ZLIB_URL := @ZLIB_URL@ - NEWLIB_VERSION := @NEWLIB_VERSION@ NEWLIB_URL := @NEWLIB_URL@ diff --git a/stubdom/.gitignore b/stubdom/.gitignore index 8c6dc00f83..e5d5744361 100644 --- a/stubdom/.gitignore +++ b/stubdom/.gitignore @@ -29,4 +29,3 @@ /vtpm/vtpm_manager.h /xenstore /xenstorepvh -/zlib-* diff --git a/stubdom/Makefile b/stubdom/Makefile index 254f8d2fc8..164694dd14 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -102,26 +102,6 @@ $(NEWLIB_STAMPFILE): mk-headers-$(XEN_TARGET_ARCH) newlib-$(NEWLIB_VERSION) $(MAKE) DESTDIR= && \ $(MAKE) DESTDIR= install ) -############ -# Cross-zlib -############ - -zlib-$(ZLIB_VERSION).tar.gz: - $(FETCHER) $@ $(ZLIB_URL)/$@ - -zlib-$(XEN_TARGET_ARCH): zlib-$(ZLIB_VERSION).tar.gz - tar xzf $< - mv zlib-$(ZLIB_VERSION) $@ - -ZLIB_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libz.a -.PHONY: cross-zlib -cross-zlib: $(ZLIB_STAMPFILE) -$(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) - ( cd $< && \ - CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" CC=$(CC) ./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf && \ - $(MAKE) DESTDIR= libz.a && \ - $(MAKE) DESTDIR= install ) - ####################################################################### # There used to be a slightly modified version of pciutils, this is now # available under https://github.com/pciutils/pciutils/pull/236 @@ -227,7 +207,7 @@ cross-tpmemu: $(TPMEMU_STAMPFILE) ####### .PHONY: $(CROSS_ROOT) -$(CROSS_ROOT): cross-newlib cross-zlib +$(CROSS_ROOT): cross-newlib ####### # libraries under tools/libs @@ -454,7 +434,6 @@ clean: crossclean: clean rm -fr $(CROSS_ROOT) rm -fr newlib-$(XEN_TARGET_ARCH) - rm -fr zlib-$(XEN_TARGET_ARCH) rm -fr libs-$(XEN_TARGET_ARCH) rm -fr xenstore xenstorepvh rm -fr gmp-$(XEN_TARGET_ARCH) @@ -476,7 +455,6 @@ patchclean: crossclean .PHONY: downloadclean downloadclean: patchclean rm -f newlib-$(NEWLIB_VERSION).tar.gz - rm -f zlib-$(ZLIB_VERSION).tar.gz rm -f gmp-$(GMP_VERSION).tar.bz2 rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz rm -f lwip-$(LWIP_VERSION).tar.gz diff --git a/stubdom/configure b/stubdom/configure index f3d63dceff..1a5687d32b 100755 --- a/stubdom/configure +++ b/stubdom/configure @@ -634,8 +634,6 @@ LWIP_VERSION LWIP_URL NEWLIB_VERSION NEWLIB_URL -ZLIB_VERSION -ZLIB_URL INSTALL_DATA INSTALL_SCRIPT INSTALL_PROGRAM @@ -722,7 +720,6 @@ CFLAGS LDFLAGS LIBS CPPFLAGS -ZLIB_URL NEWLIB_URL LWIP_URL GMP_URL @@ -1372,7 +1369,6 @@ Some influential environment variables: LIBS libraries to pass to the linker, e.g. -l CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory - ZLIB_URL Download url for zlib NEWLIB_URL Download url for newlib LWIP_URL Download url for lwip GMP_URL Download url for libgmp @@ -4023,17 +4019,6 @@ fi # Stubdom libraries version and url setup -if test "x$ZLIB_URL" = "x" -then : - - ZLIB_URL=\$\(XEN_EXTFILES_URL\) -fi -ZLIB_VERSION="1.2.3" - - - - - if test "x$NEWLIB_URL" = "x" then : diff --git a/stubdom/configure.ac b/stubdom/configure.ac index d3d2a840d3..34a47c95e1 100644 --- a/stubdom/configure.ac +++ b/stubdom/configure.ac @@ -38,7 +38,6 @@ AC_PROG_INSTALL AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake]) # Stubdom libraries version and url setup -AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3]) AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], [https://sourceware.org/ftp/newlib]) AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], [https://download.savannah.gnu.org/releases/lwip]) AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [https://gmplib.org/download/gmp/archive]) -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 07:28:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 07:28:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428279.1651031 (Exim 4.92) (envelope-from ) id 1x8uva-0001MW-VZ; Tue, 22 Sep 2026 07:28:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428279.1651031; Tue, 22 Sep 2026 07:28:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uva-0001MK-SK; Tue, 22 Sep 2026 07:28:34 +0000 Received: by outflank-mailman (input) for mailman id 1428279; Tue, 22 Sep 2026 07:28:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8uvZ-0001K9-Uy for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 07:28:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8uvZ-009DGb-BU for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:28:33 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab22e21-2eae-0a2a0a5409dd-0a2a450c8838-4 for ; Tue, 22 Sep 2026 09:28:33 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab22e1d-f479-0a2a450c0019-c387df83b1de-3 for ; Tue, 22 Sep 2026 09:28:30 +0200 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7DB6A1F795; Tue, 22 Sep 2026 07:28:21 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2D6F7136D9; Tue, 22 Sep 2026 07:28:21 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id nxbLARUusmrvXQAAD6G6ig (envelope-from ); Tue, 22 Sep 2026 07:28:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062105; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rJBC93oeDjibAmlMfbYh+ITd4umiwKFoqqHnj9UduOs=; b=DHRFTgN57jTQGdepCokZoWlo3oxCZjcWbtXntwb/mXINALjFpe1rW6+kWFOUO/c3yblhSZ Q0i5xG+qTiKKmdb0JqdVXmRmLLZoyvEUqxb0jcytVorBVr+SF7fulI2WNj88MIEe4gQUAL 3y0Sgh2I7Cp3lNLMJGQ5t4gh+YRdnFo= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790062101; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rJBC93oeDjibAmlMfbYh+ITd4umiwKFoqqHnj9UduOs=; b=j6JzmN1UJz/GzzUKge36krtWThORSWcChbUnWliTQ4YvtaAWthC/5dpVFMAm8FGLk/Khmw rH//We8WPp2eIrcmtE0ypa2WmOEzehViyPFShDJ7HhkPJtMmxxH/gxtud5qzIICqOnyf1t 5/UqQ8Vxsy2HFOK9e8RV/Bv6LnVXgyg= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Oleksii Kurochko , Community Manager Subject: [PATCH v3 4/4] CHANGELOG: add removal of grub-pv Date: Tue, 22 Sep 2026 09:27:11 +0200 Message-ID: <20260922072711.385956-5-jgross@suse.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260922072711.385956-1-jgross@suse.com> References: <20260922072711.385956-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.30 X-Spam-Level: X-Spamd-Result: default: False [-1.30 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; FREEMAIL_CC(0.00)[suse.com,gmail.com,xenproject.org]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; URIBL_BLOCKED(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[changelog.md:url,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCPT_COUNT_THREE(0.00)[4]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FREEMAIL_ENVRCPT(0.00)[gmail.com] X-Spam-Flag: NO X-purgate-ID: tlsNG-d25034/1790062110-50B3DA5B-5CB900BB/35/110847 X-purgate-type: clean X-purgate-size: 782 Signed-off-by: Juergen Gross --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index aa1a777dd4..a2dd01037b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,6 +23,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) The only known user was the classic-xen fork of Linux. This does not affect Xen kexec support in the kexec-tools package. - The example stubdom "c-stubdom" has been removed. + - The grub-pv stubdom has been removed. A grub-pv stubdom from an older + Xen version (e.g. 4.22) will still work with Xen 4.23. ## [4.22.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=staging) - 2026-07-30 -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 08:11:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 08:11:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428316.1651042 (Exim 4.92) (envelope-from ) id 1x8vbK-00010O-Em; Tue, 22 Sep 2026 08:11:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428316.1651042; Tue, 22 Sep 2026 08:11: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 1x8vbK-00010H-As; Tue, 22 Sep 2026 08:11:42 +0000 Received: by outflank-mailman (input) for mailman id 1428316; Tue, 22 Sep 2026 08:11:41 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8vbJ-00010B-0x for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:11:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8vbH-00Aglh-1B; Tue, 22 Sep 2026 08:11:39 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8vbH-003Y6G-2h; Tue, 22 Sep 2026 08:11:39 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=X91pxvR+jE8Uqo8RaBUigBsnsZa62rFkSkc2AZXv4wI=; b=E1MRdjswulurd4vmzlJH9z3ZNm nbseEQLrwbGpVz0zIujKOOpjpfzbVEZAkZ9p9zQX9kNu5SmbsrDS0i12r8IR0aN2L+GEk1yZ7Nxhl Dr493zBjedqcxpToYA06YQrIJ0vHrjw6QTAfsHN55mm08yLNU03drBz0HNnP2qotwAYY=; Date: Tue, 22 Sep 2026 10:11:37 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH v2 1/2] symbols: drop _{s,e}extratext Message-ID: References: <69cbb2b8-8fed-4aa0-b1c6-0cbe135cb062@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <69cbb2b8-8fed-4aa0-b1c6-0cbe135cb062@suse.com> On Tue, Aug 25, 2026 at 04:27:57PM +0200, Jan Beulich wrote: > We're only about 18.5 years late with this: See Linux commit a3b81113fb66 > ("remove support for un-needed _extratext section"), i.e. from the 2.6.25 > dev cycle. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Sep 22 08:12:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 08:12:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428321.1651050 (Exim 4.92) (envelope-from ) id 1x8vcQ-0001SG-Lq; Tue, 22 Sep 2026 08:12:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428321.1651050; Tue, 22 Sep 2026 08:12:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8vcQ-0001S9-JA; Tue, 22 Sep 2026 08:12:50 +0000 Received: by outflank-mailman (input) for mailman id 1428321; Tue, 22 Sep 2026 08:12:49 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8vcP-0001S1-IZ for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:12:49 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8vcO-00AgsG-14; Tue, 22 Sep 2026 08:12:48 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8vcO-003bxv-2e; Tue, 22 Sep 2026 08:12:48 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=6VTN88SjBuYNs1nRC0ISw/3lDgxFPUOXRaAn6oA/2TI=; b=mKseR2icXmN0MVatlBCFyDVGQr zpqBsYeQAwtZ+xiKsLreYfGDZaYUdEbWZJD+um+oSbCaSHAt079pS1BWm01b6+9w1T06igUJqZ8uU rbFolLl06GhIhMv3au009RvCByI47lnN+8wYRTECYQBDLIFdNW/o2Wpd/QRB76w74tGk=; Date: Tue, 22 Sep 2026 10:12:46 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH v2 2/2] symbols: also special-case symbols aliasing _sinittext Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Aug 25, 2026 at 04:29:25PM +0200, Jan Beulich wrote: > A recent 4.22 randconfig build job hit a situation where (LIVEPATCH=n, > i.e. --all-symbols not specified) both __note_gnu_build_id_end and > _erodata aliased _sinittext on the 1st linking pass, but they didn't on > the 2nd one. As a result two fewer symbols were emitted on the 2nd pass, > causing $(call compare-symbol-tables, ...) to fail. > > Extend the existing "corner case" by also considering aliases with > _sinittext (_stext really shouldn't have anything ahead of it), but > discard only non-text symbols. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné (with the _sextratext mention removed) Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Sep 22 08:23:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 08:23:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428330.1651059 (Exim 4.92) (envelope-from ) id 1x8vmx-0003A1-KM; Tue, 22 Sep 2026 08:23:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428330.1651059; Tue, 22 Sep 2026 08:23:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8vmx-00039u-HS; Tue, 22 Sep 2026 08:23:43 +0000 Received: by outflank-mailman (input) for mailman id 1428330; Tue, 22 Sep 2026 08:23:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8vmw-00039o-5K for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:23:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8vmt-00F1Un-U9 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:23:39 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab23b0a-e002-0a2a0a5209dd-0a2a4503dcd8-14 for ; Tue, 22 Sep 2026 10:23:39 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab23b0b-fae8-0a2a45030019-4a7de18d9609-3 for ; Tue, 22 Sep 2026 10:23:39 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e71cdb22bso28526125e9.2 for ; Tue, 22 Sep 2026 01:23:39 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fd8b97385sm60771805e9.2.2026.09.22.01.23.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 01:23:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:Subject:From:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790065419; x=1790670219; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=RbzJwYzlXEAdBV4JQhB+dJYYKzQBYazVAXgi+oR0Bz4=; b=TU6o/gEDJ/SHm5pp1Zfn18/1jQlxj7SCBKORdHDUsj36Hlxydc18MCo/Ef5Unl5Zzh OcrBLEuahgsnOTgm3GoaSpFp/1zf/hZdAr4vfcwZfZIRwpwcufpvyRTNTqj+sii+geu3 VoxoMQd0zH48wnUfcqAQHR/YXhR6K6LlnVJzkVgGgVmcA/BQ6Do0WJt8/Ip6Bdy7La1I QFAozvURCiQeMRlmu+qcjyCB7K39PZY5q3uHAO61KvlpzwOrHPdkUFEEZj5abhIKTFTf utgznaJfs03KRcGhTMobhBHhrNhrtlFcbMuTJwUmpGnRM3kJiXelMFRBrLI05VFvE3xQ 7CAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790065419; x=1790670219; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=RbzJwYzlXEAdBV4JQhB+dJYYKzQBYazVAXgi+oR0Bz4=; b=hSTVOSjqRt6m8Nf687HzaurHwn1+2t5bSKt5o9jwVhmtvBcMtxta118eGG7ut7L8p6 RcNxdzYM1NASmb/dve8hb5MtALpR2H9cji+R1TjsIzH70mByGBC/F2gN+VN9W1/VPNA9 FM4i+XQ966sKMyKvC1+mSLm6IAKexqLRgDaodYNV5GtDo5FD48QvoWVos5PgLopxCzn5 BQOG7JK11y4eeBq9Xxb5AMRXJoEhtVCG+cSWm4by0FJk/yGZi0vhTLy13P8juMLG7dfT Ajz1zo4fAf/Z7GTp57mbkKyBZTtXyW3E5IidoUQuPMAa2NS84gBRlGUuiR4gvdyBiuX2 IK+Q== X-Forwarded-Encrypted: i=1; AKwUvBzOZGAgBqYZFs4P30zC+BaPKc4PP5AEfz+9bKs74GdMYF19dztnAJRw5xT9i81AGtr+UyvIz+n1K0k=@lists.xenproject.org X-Gm-Message-State: AFuF++mPp6Oh/dKIdJmP0Rk9ud4U/fG9tUQvK1DMYS+Bo8CFVT69GyIp aP8AYRTQMS6Jvx46ZF2g/oxN5kDlm3LqtyprYNHbAyqRYZ4lqaBgkIgN X-Gm-Gg: AYBFou3j/NCeLfOKbxxo2Rf2ebDi9wZabirDcPDx//pedhg7NxDcvYYtn2XVuzaD1Qf rxspu3Ghj2cIX/lMAlA/PSebUmn9opYHUNIlNjW+nEKkrMaEPvy+EzN8EBMFBS/UbSj/PTde9d9 Ieq3KbWe4RVdNsxWI3I71Yj7TRDZ7Nuc1H1o2X0sydiq3gcLSXs4d1rAAI6rdZLL0ouUsxjZQ8Y B5pB7k53L3HLC9hSTCAC5k6QjY68wZcTu4FcwpfMzp/JsVEhZrP0rAYD5IGovY5iBt5382wdxN0 IqWoGdHsEiA7zjilnlujseWhd6lxEqaPNyvdnzdkDPbL1WHCWpKCOm2zlvBYiLpGrNAtnKcv0jf +CUYvVpeWFkMci31XeD0sqB+3/eyiv29vLckQvorLrIlG06FSb4z0yGcN9zIw0Eo9Hs4OX8OoPa +Tv705a6rcy+hEqe1HeT6GewVj4Ip+ExgJyLnGEta1bLALYSpK3WJPyqHMFijZBrExdA3Dd+n/0 YFDYCGFEl9enjqiJostpSzRvbLkAbsL1Hb8xQEO2uk8TAHk5w== X-Received: by 2002:a05:600c:3e0b:b0:49b:d03:8d3a with SMTP id 5b1f17b1804b1-49fc5687115mr170537275e9.11.1790065419017; Tue, 22 Sep 2026 01:23:39 -0700 (PDT) Message-ID: <96f66feb-8889-4475-b39f-ed52b1f58a68@gmail.com> Date: Tue, 22 Sep 2026 10:23:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu() To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8dbc4ba6-bf92-4e9f-b4b6-7286d5a96443@suse.com> Content-Language: en-US In-Reply-To: <8dbc4ba6-bf92-4e9f-b4b6-7286d5a96443@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1790065419-6C2E04E9-DEF6DF2E/10/73395122804 X-purgate-type: spam X-purgate-size: 13308 On 9/21/26 2:12 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> continue_new_vcpu() is the arch hook invoked the first time a freshly >> created vCPU is scheduled. Implement both cases it has to cover: >> - for the idle vCPU, switch to its own stack and jump to idle_loop(); >> - for a guest vCPU, restore hstatus and enter the guest through the new >> return_to_new_vcpu() path in entry.S, which loads sepc, passes the >> hart id in a0 and the DTB address in a1 as expected by the RISC-V >> boot protocol, sets sstatus.SPP and executes sret. > > Is this a requirement for all CPUs, or just for the boot one? (I can't > quite see why secondary processors would need passing a DTB address.) It is requirement for boot one. For secondary processors it is HSM boot data which is passed to sbi_hsm_hart_start() and then intercpeted by Xen. At the moment of writing of this commit message we have only boot CPU and so only DTB could be passed. I can update the commit message and the comment in return_to_new_vcpu() to tell that it could be DTB address for boot cpu and/or for secondary CPUs HSM boot data or it will be better to add info about HSM boot data during and an introduction of secondary CPUs support? > >> Interrupts have to stay disabled across the restore. The trap entry >> logic implicitly clears hstatus.SPV, so an interrupt taken between the >> write of hstatus and sret would make sret return to HS-mode instead of >> VS-mode, and restoring SPV afterwards is non-trivial. Instead interrupts >> are simply kept off and sstatus.SPIE is set, so that SIE is restored from >> SPIE once sret has been executed. > > As written this reads as if the guest would be responsible for doing this. > Isn't it rather SRET itself which does this? IIUC to which part you refer then yes, it is SRET itself which does this. So some re-wording should be done ... > >> Also, it follows what hardware will do >> with real CPU which is also started with interrupts disabled. > > Further up, aiui, you talk about the host's interrupt state. How vCPU-s > are started, however, is virtual interrupt state. Mixing both isn't > very helpful. ...: Interrupts have to stay disabled across the restore. The trap entry logic implicitly clears hstatus.SPV, so an interrupt taken between the write of hstatus and sret would make sret return to HS-mode instead of VS-mode, and restoring SPV afterwards is non-trivial. Hence interrupts are kept disabled, and sstatus.SPIE is set so that sret itself re-enables them (SIE := SPIE) as part of entering the guest. Then it will be also need to update the comment inside continue_new_vcpu() to: - * To avoid this, interrupts are kept disabled during the restore. - * Additionally, setting sstatus.SPIE=1 ensures that after sret is - * executed (as sstatus.SIE will be loaded from SPIE), HS-mode will - * continue to receive interrupts normally. + * To avoid this, interrupts are kept disabled during the restore, + * and sstatus.SPIE is set so that sret itself re-enables them + * (SIE := SPIE) as part of entering the guest. */ Would it be the wording okay for you now? > >> Introduce get_cpu_info() and reset_stack_and_jump() in asm/current.h, >> needed by the above. get_cpu_info() is a macro rather than a static >> inline because asm/current.h is pulled in by before >> this_cpu() is defined and before completes struct vcpu. > > This is odd, given the similarity to Arm. They get away without using > "current", and hence without using this_cpu(). Arm calculates struct cpu_info * based on sp register + STACK_SIZE: static inline struct cpu_info *get_cpu_info(void) { #ifdef __clang__ unsigned long sp; asm ("mov %0, sp" : "=r" (sp)); #else register unsigned long sp asm ("sp"); #endif return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info)); } what is equal to current->arch.cpu_info as I can see based on how both arch-es are initializing v->arch.cpu_info what is used in RISC-V. > >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -8,10 +8,13 @@ >> #include >> #include >> >> +#include >> +#include >> #include >> #include >> #include >> #include >> +#include >> #include >> #include >> #include > > What makes these additions necessary here? None, they are leftovers from an earlier version of this patch. I'll drop them; will be added by the patch which starts using imsic_vsfile_attach(). > >> @@ -140,9 +143,43 @@ static void vcpu_csr_init(struct vcpu *v) >> v->arch.hie = MIP_SGEIP; >> } >> >> +static void schedule_tail(struct vcpu *prev); >> +static void noreturn idle_loop(void); >> +void noreturn return_to_new_vcpu(void); > > For this last one: asmlinkage? Will add. > >> static void continue_new_vcpu(struct vcpu *prev) >> { >> - BUG_ON("unimplemented\n"); >> + schedule_tail(prev); >> + >> + if ( is_idle_vcpu(current) ) >> + reset_stack_and_jump(idle_loop); >> + else > > This is the kind of "else" which I consider particularly confusing: It > suggests that the if() body can actually be exited at the bottom, when > (by the name "reset_stack_and_jump") it hopefully cannot. Agreed, the "else" isn't needed here. I kept it only because it looked more symmetric to me, but I'll drop it and move its body out to the same level as the if(). > >> + { >> + /* >> + * During a context switch to a new vCPU, interrupts must be disabled >> + * to guarantee that the vCPU's CSR state can be safely restored into >> + * the hart without being clobbered by an interrupt trap. >> + * >> + * For example, when return_to_new_vcpu() finishes, it executes sret. >> + * At that point, the hart checks hstatus.SPV=1 and sstatus.SPP=1 in >> + * order to return from HS-mode into VS-mode. If an interrupt were to >> + * arrive before sret, the trap entry logic would implicitly clear >> + * hstatus.SPV to 0. Correctly restoring it afterwards is non-trivial, >> + * and if left as 0, sret would incorrectly return to HS-mode instead >> + * of VS-mode. >> + * >> + * To avoid this, interrupts are kept disabled during the restore. >> + * Additionally, setting sstatus.SPIE=1 ensures that after sret is >> + * executed (as sstatus.SIE will be loaded from SPIE), HS-mode will >> + * continue to receive interrupts normally. >> + */ >> + local_irq_disable(); >> + csr_set(CSR_SSTATUS, SSTATUS_SPIE); >> + >> + csr_write(CSR_HSTATUS, vcpu_guest_cpu_user_regs(current)->hstatus); >> + >> + reset_stack_and_jump(return_to_new_vcpu); > > What are the criteria by which you split CSR accesses between doing some here > and some in return_to_new_vcpu()? In particular you set sstatus.SPIE here but > sstatus.SPP there, when both could - I think - be done with a single CSR > access. There was no real criterion (and SPIE is set here only for better explanation of the comment). I'll move all the CSR setup sret depends on (hstatus, sepc, sstatus.SPP and sstatus.SPIE) into return_to_new_vcpu(), like the regular return-to-guest path in entry.S already does, and set SPP and SPIE with a single CSR access there. Only local_irq_disable() will stay in continue_new_vcpu(). I will do the following: + * return_to_new_vcpu() sets up hstatus.SPV, sstatus.SPP and sepc so + * that sret enters the guest in VS-mode. A trap taken in HS-mode + * overwrites all of them (trap entry clears hstatus.SPV in particular), + * so interrupts have to stay disabled until sret. They are re-enabled by + * sret itself, as return_to_new_vcpu() also sets sstatus.SPIE. */ local_irq_disable(); - csr_set(CSR_SSTATUS, SSTATUS_SPIE); - - csr_write(CSR_HSTATUS, vcpu_guest_cpu_user_regs(current)->hstatus); reset_stack_and_jump(return_to_new_vcpu); and then: -/* t0 is used as a temporary reg and is clobbered to oblivion */ +/* + * Enter a vCPU for the first time. Must be called with interrupts disabled, + * see continue_new_vcpu(). + * + * t0 is used as a temporary reg and is clobbered to oblivion. + */ FUNC(return_to_new_vcpu) /* Swap tp with sscratch */ csrrw tp, CSR_SSCRATCH, tp /* Set vCPU registers */ + REG_L t0, CPU_USER_REGS_HSTATUS(sp) + csrw CSR_HSTATUS, t0 + REG_L t0, CPU_USER_REGS_SEPC(sp) - csrw sepc, t0 + csrw CSR_SEPC, t0 /* Hartid goes to a0 */ REG_L a0, CPU_USER_REGS_A0(sp) /* DTB goes to a1 */ REG_L a1, CPU_USER_REGS_A1(sp) - /* Set guest mode to supervisor */ - li t0, SSTATUS_SPP + /* Return to (V)S-mode, with interrupts re-enabled by sret */ + li t0, SSTATUS_SPP | SSTATUS_SPIE csrs CSR_SSTATUS, t0 /* Enter guest */ sret END(return_to_new_vcpu) > >> --- a/xen/arch/riscv/entry.S >> +++ b/xen/arch/riscv/entry.S >> @@ -143,3 +143,26 @@ FUNC(__context_switch) >> >> ret >> END(__context_switch) >> + >> +/* t0 is used as a temporary reg and is clobbered to oblivion */ >> +FUNC(return_to_new_vcpu) >> + /* Swap tp with sscratch */ >> + csrrw tp, CSR_SSCRATCH, tp > > What is this about? I'm not aware of any counterpart code, yet all on its > own this I can't see it being overly useful. It will be needed later when a guest will be able to launch to distinguish in handle_trap() [1] if a trap is from guest or not. I can drop it for now and re-introduce it with the code of handle_trap() or as an option I could update the comment above to: /* * SSCRATCH holds this hart's struct pcpu_info while a guest runs and * is zero while Xen runs, so that a trap handler can tell the two * apart: tp is Xen's pointer to pcpu_info in Xen context, but belongs * to the guest once sret has been executed. Establish that by swapping * the two here; the trap path swaps them back. */ csrrw tp, CSR_SSCRATCH, tp (but then the last part will point to the part which isn't yet introduced so probably it will be better to drop this line for now) [1] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/entry.S?ref_type=heads&blame=1#L15 > >> + /* Set vCPU registers */ >> + REG_L t0, CPU_USER_REGS_SEPC(sp) >> + csrw sepc, t0 >> + >> + /* Hartid goes to a0 */ >> + REG_L a0, CPU_USER_REGS_A0(sp) >> + >> + /* DTB goes to a1 */ >> + REG_L a1, CPU_USER_REGS_A1(sp) > > The fields loaded are merely .a0 and .a1 of the register struct. There's > nothing here making sure (all on its own) that what is loaded is what is > said by the comments. If e.g. the first comment was /* .a0 holds the > hart id */ or some such to remind readers what is being loaded without > giving the impression that the correct value is _established_ here, that > may be better. I will re-word the comments in suggested way: - /* Hartid goes to a0 */ + /* .a0 holds the hart id */ REG_L a0, CPU_USER_REGS_A0(sp) - /* DTB goes to a1 */ + /* .a1 holds the address of the DTB */ REG_L a1, CPU_USER_REGS_A1(sp) > >> + /* Set guest mode to supervisor */ >> + li t0, SSTATUS_SPP >> + csrs CSR_SSTATUS, t0 >> + >> + /* Enter guest */ >> + sret >> +END(return_to_new_vcpu) > > Aiui SRET does not switch stacks. Shouldn't you therefore clear sp here? > And perhaps also other GPRs, not the least ra? Exposing hypervisor > register values to guests is, well, a bit of a problem. Good point, sret leaves all GPRs as they are, so the guest would indeed see Xen's sp, ra and friends. Only a0 and a1 are architecturally meaningful for a booting hart, so I'll clear every other GPR right before sret. I will add the following before sret: /* * sret doesn't switch stacks and leaves the GPRs alone, so every * register which isn't meaningful to the vCPU being started has to be * cleared here: otherwise the guest would see Xen's values, sp (this * vCPU's Xen stack) and ra among them. */ .irp reg, ra, sp, gp, tp, t0, t1, t2, s0, s1, a2, a3, a4, a5, a6, a7, \ s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, t3, t4, t5, t6 mv \reg, zero .endr Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 08:32:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 08:32:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428344.1651068 (Exim 4.92) (envelope-from ) id 1x8vuv-0004oK-EP; Tue, 22 Sep 2026 08:31:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428344.1651068; Tue, 22 Sep 2026 08:31:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8vuv-0004oD-Be; Tue, 22 Sep 2026 08:31:57 +0000 Received: by outflank-mailman (input) for mailman id 1428344; Tue, 22 Sep 2026 08:31:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8vuu-0004o7-MG for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:31:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8vuu-004tUI-30 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:31:56 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab23ce9-2eae-0a2a0a5409dd-0a2a4503cc10-46 for ; Tue, 22 Sep 2026 10:31:56 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab23cfb-fae8-0a2a45030019-4a7de14cf476-3 for ; Tue, 22 Sep 2026 10:31:56 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6350faaso2085473f8f.0 for ; Tue, 22 Sep 2026 01:31:55 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fdaaf97e2sm19216765e9.2.2026.09.22.01.31.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 01:31:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790065915; x=1790670715; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tgcJQ1EkTs4OdwdBZBzk1zepujWAGbFG1iorfIXmLPU=; b=Bs4ha95jl2nDJBO0/LjTpDzngMXT7Ug0ZVYDddkoixsLQMGhU1Slq7whxVeMChUIFH mM+kbYgIq3GSbVhc1/O84Pzy7YnZcn/7HzMNYHz8v+lwL6AK4BkjLxHmxhKOyqO52zSo 5AweWoQKE6OEpHelTRymFNvsZalCWTJj+8Rdo/QbD13vy9hTeUSXDFdLDzbVihBO7zsz UUz/ka9+fm3NsrzCSxBGf3O10k1/5QX5MSMiKZPEI3bjOwN1h2BPPmM1FJJTZtCpGOiJ if/c43/OaMPKvJ/uN5DKB4+pYl0szmN2wkR+CTJrAPh8csgeukdeAc5ptkiaWaTbAxs5 6iZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790065915; x=1790670715; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=tgcJQ1EkTs4OdwdBZBzk1zepujWAGbFG1iorfIXmLPU=; b=d5lbd8RgxdWsW//Ayl8Qm8R+3JIDTJ08uu1HpCqyu8+NrXzVGBkCqFRXLKNSUx22Uc upDFLZtodYx0eTFZpez68Ycg+OfeSoLm1XQWG0SrZs36No1MkS5M4zAknk/hp/VzU9gD 7CcI1m6/goepukgDBlK+IBRadBCiqdhoZbXzHV/gOX7B/SUlNZCH/mb4NWiunL60vVRT AsIK+nVEG/PDNSABZme1PVrrIB7MWmmK9fcOqALOLu6WoXDXjJkpcY19e6vnsmc8IJLl EaeIbAHFtM05K+I4TWV64lNJLsIY+atqpzfD+c8riOfsI8btemD7Rpae7JiyA9Oz3TWs hW/w== X-Forwarded-Encrypted: i=1; AKwUvByrxMgz+9RTIuuxWeXhWx2mUl9cxefU3VC5/9+AhrP//OQJI5sKSTFsg5vJpt34C1W0ULOhlJZVa4g=@lists.xenproject.org X-Gm-Message-State: AFuF++nnUw2AdFN8VgCo95zs+gQyftIQddI2ogZswR4z53tG217XHj9G N1F2YXq7m4yGQzKaq5QD2joGZJ62Vd6+Kpk/OtSgj+FkAv2swdJqYNlI X-Gm-Gg: AYBFou1FiQafvbCwEPJeZTjpgHjs7DcKSFo24NheVqaJO51YYwZllf4mClsd7Q9J/JI 3d+dgAUFOZ2Jt5udVpKBNVhDy7TXCs++2xaqUWsT5uK6qu0GByOjT5mlMNgebI2OxGhmAy4uMps eGP4Ep2pxaIpZ3F19sLP6EQwvCNjgiiv+QNwVtK27ecn4K10qXMyXJu28QDNnwMMFfnkmaJ21Xq 31R5A7KEyn/wtpWFNnVtoeV+NljK7NAGInuPwmYFI9bxT4WSgHysvz6bDsDiXoHJ0ws5q1nWbfg D8i7tys61kivxIpFM0xIMTJyNZUEFUPKLjPkuAhEfMKEtaEsSWh/7yn7RRva2bMWk0umG0eesKH /fmVnIzmCwcoNvmJgwpFXPbi/GMJMwTvkesKMJzFg1J/brKJ/ys2AosVRF2DhSoeNWE+nhELjum AZHseqwS69SvTntjzSai760BOBF/k9RMB+qt/6SLJyAM1HUl3T1FrnBLtqZXpRCslSdMV0WNZa3 5bY+KvI30uo15F1fC+QPx77BCYci1iFrlI= X-Received: by 2002:a05:600c:4505:b0:49a:a101:4157 with SMTP id 5b1f17b1804b1-49fc56db92fmr189278855e9.7.1790065915272; Tue, 22 Sep 2026 01:31:55 -0700 (PDT) Message-ID: <1b7b29da-bc22-4fff-8e1a-92cedcd0cf22@gmail.com> Date: Tue, 22 Sep 2026 10:31:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 39/39] xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4df9cf63943d0f371c8a25c6c9e84adbd3083a61.1787838835.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1790065916-6CADC4E9-A719443A/10/73395122804 X-purgate-type: spam X-purgate-size: 1293 On 9/21/26 2:32 PM, Jan Beulich wrote: > On 27.08.2026 17:21, Oleksii Kurochko wrote: >> Introduce imsic_vsfile_attach() to initialize the AIA-related state needed >> for a vCPU to have a working guest interrupt file. >> >> A guest (VS) interrupt file must be mapped to one of a pCPU's >> hardware interrupt files (if they exist), so the pCPU a vCPU will actually >> run on needs to be known first. arch_vcpu_create() is therefore not a >> suitable place to call vcpu_aia_init(), since the pCPU assigned to a >> vCPU can still change before it is first scheduled. To avoid >> reassigning the VS interrupt file id and remapping it to a different >> pCPU's hardware interrupt file, imsic_vsfile_attach() is called from a >> later point in the scheduling path (e.g. continue_new_vcpu()). > > Hmm, why does first-time handling need to be this different from the > handling of a vCPU moving across pCPU-s? The sole difference should be > "no state to load" vs "load state that was saved on the old pCPU". > Generally I think it could be the same but not all the steps done in migration functions aren't needed for new vCPU (despite of the fact they aren't harmful). For new vCPU it seems to me it is enough only to attach h/w interrupt file to vCPU. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 08:35:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 08:35:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428351.1651077 (Exim 4.92) (envelope-from ) id 1x8vyN-0005KN-S0; Tue, 22 Sep 2026 08:35:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428351.1651077; Tue, 22 Sep 2026 08:35:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8vyN-0005KG-PC; Tue, 22 Sep 2026 08:35:31 +0000 Received: by outflank-mailman (input) for mailman id 1428351; Tue, 22 Sep 2026 08:35:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8vyM-0005KA-ED for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:35:30 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8vyJ-00AiKl-0a; Tue, 22 Sep 2026 08:35:27 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8vyJ-005P5n-1y; Tue, 22 Sep 2026 08:35:27 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=in5miQYTc3LbtSaYzXdTxL0Fg8Xm0nJOMms6+76vWBc=; b=dc3dEUSsMAiLyhZ8Hulk5Iludw a1IqcerfvlF8rbrGAMO1ZHwlkGEc8HTyQ9PMLEeJZGYxPQEoVNSzaczEQqV/2T0N9mBwIWO5oMboL ne5HW3VXVPbSBhMOOT6abD4yoSCDsZvM5Wj46NvfDSW3owHMAO2xylkUtiW89XR3nK5c=; Date: Tue, 22 Sep 2026 10:35:25 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Yuchao Zhang Cc: Juergen Gross , Stefano Stabellini , Jens Axboe , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2] xen-blkfront: unbind irq before tearing down ring and shadow requests Message-ID: References: <20260922072155.34625-1-ndaugoing@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260922072155.34625-1-ndaugoing@gmail.com> On Tue, Sep 22, 2026 at 03:21:55PM +0800, Yuchao Zhang wrote: > In blkif_free_ring(), the driver tears down the ring's persistent grants, > shadow request arrays, and shared ring structure (xenbus_teardown_ring), > and only calls unbind_from_irqhandler() at the very end. > > While blkif_free_ring() is freeing persistent grants and clearing the > shadow array, the event channel interrupt (blkif_interrupt) is still > registered and active. If an interrupt arrives from the backend during > this teardown window, blkif_interrupt() reads rinfo->ring.sring and, > via blkif_completion(), accesses rinfo->shadow[id].grants_used and > rinfo->shadow[id].sg. blkif_free_ring() tears these structures down > without holding rinfo->ring_lock, and the handler only checks > info->connected at entry, so this is a real race resulting in a > use-after-free or NULL pointer dereference. > > Fix this by moving unbind_from_irqhandler() to the beginning of > blkif_free_ring(). Calling unbind_from_irqhandler() first frees the > IRQ and synchronizes with any in-flight interrupt handlers on other CPUs > before ring memory and shadow request structures are deallocated, > matching the teardown order in drivers/net/xen-netfront.c. > > Fixes: 11659569f720 ("xen/blkfront: split per device io_lock") > Cc: stable@vger.kernel.org > Signed-off-by: Yuchao Zhang Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Sep 22 08:46:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 08:46:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428358.1651085 (Exim 4.92) (envelope-from ) id 1x8w9J-0006yS-RV; Tue, 22 Sep 2026 08:46:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428358.1651085; Tue, 22 Sep 2026 08:46:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8w9J-0006yL-Ol; Tue, 22 Sep 2026 08:46:49 +0000 Received: by outflank-mailman (input) for mailman id 1428358; Tue, 22 Sep 2026 08:46:48 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8w9I-0006yF-4F for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:46:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8w9H-0028cQ-Dx for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:46:47 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab24072-bab6-0a2a0a5309dd-0a2a4504d552-0 for ; Tue, 22 Sep 2026 10:46:42 +0200 Received: from [52.101.193.54] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab24070-b57f-0a2a45040019-3465c1366ca3-3 for ; Tue, 22 Sep 2026 10:46:42 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB7078.namprd03.prod.outlook.com (2603:10b6:a03:4d7::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 08:46:37 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 08:46:37 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SwMHdulPSk4/my4FmdiPgr/WHvuT8OZGaw1tx0ODvU3gZJPSVBA97msMlFBS8DvnCHfXSrRxozKqQo3pvikrCYFy/FEKmpskLhMf9tSKHQ2bPwMP1nOYIvu4fVuKPWrhr4xDKSJN29ZE/1k18KIuiC8JWFUDEb2RF0V67j8c37jknK9PVYF4abcztayvf5KVBJgVIFJ1OlBqBWfKifoxnlS3Uzp1IBJ00P1AtGuGL3xtnqigG5iMBMwkuPED+ArGS0osQ51nqQggjDpNr7sjBJy5DYWlQ+9z0DcRLw6Xsr//ulF702pxPfgzHHvrVqgbSCGDAW/ETZ/1DVULvnMD8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6S8Qlml4KIcmFt9GBxd9qkw/xMiL535E7cdJGNOeYxk=; b=KwObllsNzF4RXQK/Qi0kTLs0AVNzdiofZadNR4AI6hPAOaeK44hTQAkq2I0mEiIj9a6WZkdOCQVO1MsebyOHT0cSy1hId9QN/Z3dpMM/rAIN735bMWq5IDgHWD8KAXH6exvv7IATD2BLhsCHH2Lm1nT/KkSHnvssteyML/VDw9LTEqu9RGOU6G7XuZ5t4/QwTFJXxnk2Lo6Orx6zbvjZu3p5EitgvdYgU7kXmcuonkn/EF1pvH2qZY+ERLPdsgq4ErSw2Fqvg0om0OrLHQqrt44HcG44dXEiyL/4YaFd6bNF8rs8Oqxy+12gIPty45l48fAhXIxbubjVgxTsY/3ojQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6S8Qlml4KIcmFt9GBxd9qkw/xMiL535E7cdJGNOeYxk=; b=iHQfzaICQWgz+4MJOVkAjloYztF4wtSPSRoIDn83fTfiWV3DHXi3FYnqrdxOMq7tCe+UVUhfRAvuwO3E6/MmH99luaOMw9LHg39Os/AmxfwbfC3KfVlM+2CTGqXoMKotFyO+IM2goXa4efCAdosWPh4Ddl2/zlsy6jUMh30VuoE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0581fc21-f2db-441b-92ff-0c7da6e8d443@citrix.com> Date: Tue, 22 Sep 2026 09:46:34 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] ACPI: prune undue ia64 leftover To: Jan Beulich , "xen-devel@lists.xenproject.org" References: Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0170.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:312::9) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB7078:EE_ X-MS-Office365-Filtering-Correlation-Id: 96d7aa61-9418-4263-f401-08df1886036c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|11063799006|56012099006|10067099003|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: Lppdp0H3p/r9kwP2kDAZwXU4+CaQIhpt0iS2l4dtaeUegQsrpp0+MA/gfyRmpxnCrzeoe+2mgCb+xCEgZ5T3YAtU0qivcgBGbFB+9vYjxfC2I4ZVrtG7dI3hRZuRf3bB1VjCpXD+8wFTxi2LZE1qDxI5771avFaPKhqpnKOaO23W5LxJe2uES/sDhRkId9KjkCbGrXM9EGlTltelk6FLXmJFE2w102tCU1Mct17sA1ZbYO/RVAuUFTM85UE6TqHPtBmZJv3JQJJVSbtZs0a1TzLdY/HXdf47LVn5gWtlBw2HKSYtuUS2alUdAnNfsvO0jg8moMZx08MPu6SNSIdA1eDl/LYfIxarHJfs/xYln7UL2m7TC7I4uLKguFq8t+vCM//7mAFiPeiollK3mTFJWUiILwY+FRvJcOyS5RXqOj3RKvTtQNl/QYS5GCQvow6ebiRivN5BKvbbsuhmplSkaadrgRFWhyTP2IWmNejXdGOvS6DbYPmoYaPeMqE4hxls7RpkJR09LPJu31a9rrYZYAPUoKJjHmI+SHR0pU94nlXC+UNy4SNY+Wp/8wEq4YKCTifVRFzCVtr2MiYj8RRcM1CLCWYJYIjkV7Mlf+tpptUSPWV8PT0VczRl3Amg9j7MTPbUFu+8KA/i+IsrdXKruUt9ZK1/krkG7VNOGnrn/80= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(11063799006)(56012099006)(10067099003)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TTRYeUF1K244bWxCakZ6Rk0zMmJoaTdZYlVKelp2b0xGSHludU9uQ2hiUkpa?= =?utf-8?B?U0dqeTgrZmxQNStzc0NTMG8xZER0UWZETGl1bDhjV0Y1SUhXdFhqYlJvbGFB?= =?utf-8?B?MVFhWERTT2ZoL1dkNHYwR2p6L0lEZHptOUs2dFUvQ1RCNk16MjVDRXpKRlRW?= =?utf-8?B?WUE0UU5lamtZV2pqVk9vNDB1SzZKK2NOa3l3YnNJY1V0MnJEZ01BL3h1R3Rs?= =?utf-8?B?SHlLajNvM1RZNitRWXNDMHJwM3V0REw4ekJrN0c0ZWo3NUY4V2ttZ09xU0Rl?= =?utf-8?B?aS9sbWJpSUZHTVRtTWcraDZkNG1YUDBBYkhHVEFSb05oSXMram9lQUh2cW0x?= =?utf-8?B?eTV1SVlVWTFBTkt0bG5WTjVBRUZ4L1JualNXQnVZaW9wOE5GV3R5S3RQeUk3?= =?utf-8?B?QzZjMDNMMHVSTUlPRzdXWElvdFlJbmQ0NWZnNlkyNnE5WjFsdGx0R0ZtOExh?= =?utf-8?B?WUFnaWJ3WE9ZQjRVSDhrNzFhblY2NlJYTkJqejhjZFR3am52dkxmaGc0dzYr?= =?utf-8?B?QTJpS01nQloyK0t2MHBjM054ZnVoZUIrZXB1d3hvNkRSbjBvMStLNENMdS9G?= =?utf-8?B?alVpNVBvaGFxbjdFOVBiZWlpTEd4TzhVeUNaOFlEdEJBUXNVaXo2UW55bEs2?= =?utf-8?B?MHZHSnc0WUNkb0w4SFNIeDhzNVNuWFQ0NDNhRmlRejFaQmtDajd5THAzdi9u?= =?utf-8?B?eWlDNTBVak9zRTdXWjRwUEh0ZnZFUHZHc3VUblBENmMyVEsyWEMxTExjRko1?= =?utf-8?B?YWFyQzUya25IdllUK2dVTU83cmQ1SFl4L0NycTdSYXpyUXZQcFhTVGFLOWMr?= =?utf-8?B?NFRiUVFvTUg5SmVxQVJ0SkVoQWhQZmJBU3JZMFRHM2NPMC9wUWZLUVZ1Q204?= =?utf-8?B?cWJjTFc0dGFsSHZ4SThhcm8xbUcyczFJMlJWaStuUFJsSm9IbGEzLzd0REFx?= =?utf-8?B?Z0hVOTcvYUYyWVphWlo3MDlDa1AwWVQ5Mzh4TFhwcmFTUXg4NnVCRHVJTVNX?= =?utf-8?B?cWJtcFNFV3AwYUVTWVpBOWFKc2dUNlN4ZG10bkdPeWtVejhDN01lZVR1Q1kz?= =?utf-8?B?ZzVmc1NmK1duUTZXRGVyS1BhOFBrNmM3YjZVeHZjVThXNjc3QzMxK291M3hi?= =?utf-8?B?ZlVMYjMySVM1OGtWODQ0eUJ0TmtYT3RWQk9pQnNYNDJPSjIrOGU1YlpMck1G?= =?utf-8?B?cGZOaXFodXRsQ3BlVWVhbXBNSCtRUHhZY2tYVEFaR1VoOEx5QUMzOUFjNmJz?= =?utf-8?B?ZE5XUDZlTEFsMXo5ejZ0TDNUanlNaG1GdGJYSy9qRXdiVUJYVVk1NnhtMFBR?= =?utf-8?B?QlpHcHpNbVI4dEJsN29ZbDNXbUtVZDV1WXF5REtWNFl6TjVUc3VQZmoyMThZ?= =?utf-8?B?ODRkTlhzdWQzVlVod3pGNWhUQmhyK25JN2tEZVVhZVd0b2FTUTV6elBzeXNC?= =?utf-8?B?RUUzTFJUbExmcHZtc0VaMmNYSXdFTWpoL2l5NnNhUWJnU2RZeEczWVBxeHJl?= =?utf-8?B?ekVsbUFqaTN4SlR6RXVpcnhpZk1QS2kvUEU4czEyZ08xVENEREV4c1N5T1FN?= =?utf-8?B?cUhrUDhsWHNvK2tudkZNRVdGY2g3RGpKWFRXYWN0Mkh3TVJsc3Y2N29XbEwz?= =?utf-8?B?Z0RtTnhQczZMMi9hVFFYREtXUUkwc3d4YndMZTY4MlovS2Q5Rmg4N050Y3dN?= =?utf-8?B?MnhOcjJEeUxjNjJPMEJVb3QzdndnYzRUNWN0N3E2VzFZVCtJVnVqSjNWejAz?= =?utf-8?B?Y2F6VTYwSnAwbC9oRVc5Uzg4eWJYbnJVYjJFQlh0TllDQkhqdnQ1TE0wejE2?= =?utf-8?B?dkJKRlBGeGZrRDJ4VkJ1WENsN0pxV1lhWCtZZ0FXQmwzWFVTYmJZS29IWHU4?= =?utf-8?B?VGdNZHFMNE8wQXhQbTdVd001d0hzZjluVWp1Q1JxNnpSRytaMzdOTzloYWFi?= =?utf-8?B?RXliOVBncFhwVW1WK01hVGYydFVMU2R5MGhaQklvNkllV0hwN1NldHczRElZ?= =?utf-8?B?UDhSMFdvTU02cVUzaWF4MmZOdWdmREVVOUlxTklCeEVnYys5a3YvVFZYRUFq?= =?utf-8?B?TGFpSmF3Y20wMzhlRVgwUTVNSC9TYVA0NnBab0hjU0ZXY1lUbGY5c0R5UkdU?= =?utf-8?B?bUdhMmwwcS9BdytJQ3hJVDJtdDhvRmFCTmhPanRmYkpDcHJHc2tnVWVkSmta?= =?utf-8?B?V0IwVlRXdng3bm1SOEFqMFN3bkpRcWtIRmxoMGlKUnl1RFZjSUcvVWRzNlcx?= =?utf-8?B?Vnl5dUtXK2dKQVRacmx6WXY4UG81Y1hQOFgwNUg1bVZCbC9jS2JLZWY4dWhG?= =?utf-8?B?S2czUVAxT2o0UlVjZzN4NU42Vm8wdUdwVFk1L0ZuS2ZYVWUxeEhxQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96d7aa61-9418-4263-f401-08df1886036c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 08:46:37.3608 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: byvgdsDnBPOf2ZLCSp79RCvDcwFN129tT8kTqD//DxUFOL+pazQfWMrdw1t0Y8D84RoRq+iDw0JyKqZ+C90dacLaocJNzkOfQRrHbkU+wkA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB7078 X-purgate-ID: tlsNG-ebf023/1790066802-51AD0B50-404EDCFC/0/0 X-purgate-type: clean X-purgate-size: 284 On 22/09/2026 8:10 am, Jan Beulich wrote: > This undoes the part of 3b0246ea0347 ("Fix ia64 tools build") which was > missed by e567964a54b8 ("tools: drop ia64 support"). > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Sep 22 08:50:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 08:50:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428363.1651094 (Exim 4.92) (envelope-from ) id 1x8wCU-0008UW-8c; Tue, 22 Sep 2026 08:50:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428363.1651094; Tue, 22 Sep 2026 08:50:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8wCU-0008UN-5N; Tue, 22 Sep 2026 08:50:06 +0000 Received: by outflank-mailman (input) for mailman id 1428363; Tue, 22 Sep 2026 08:50:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8wCS-0008Dp-Sb for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 08:50:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8wCR-00Fi8m-Ts for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:50:03 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab24132-bab6-0a2a0a5309dd-0a2a4507b85a-46 for ; Tue, 22 Sep 2026 10:50:03 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2413b-b4ea-0a2a45070019-4a7de18cb208-3 for ; Tue, 22 Sep 2026 10:50:03 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49e620fa473so23332985e9.1 for ; Tue, 22 Sep 2026 01:50:03 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4886277e611sm3494914f8f.18.2026.09.22.01.50.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 01:50:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790067003; x=1790671803; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ugtLLQkFC9t7ZU6phzkW64agO8NV8EwcdJmof6b8lXs=; b=e4hj2SAZd3LedsZX1pMUvOo2/jszo/h5fOrtPp8CZ/6XuPiJ7Q+Ycd+hZ2TqL3pL0V 4cMizM5JtCO/O9TLbfM94rUN9+5zGeHxShCZp1Dw4dTdsnWka+9iiendFF4Dt3zcY5bT HzitLUSIQ9wWKJfc/zWDOu16vP9XcsMDWD7lvRz7U1tWI2gkT25MRxq55jhNrBY2wesL 0qH7VUBMv0cIUIlZY4NddlFhYSqKHM/DSsSMNaGkQO4gRX1bbHLVjy0uqwTw+5TBkNo3 scwUoiNTmkOxAxu/MZEyL9c9viPXS5K9ggcRIkFi40QLot1MniE6B8KSmFEUPbI5LoOm VWZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790067003; x=1790671803; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=ugtLLQkFC9t7ZU6phzkW64agO8NV8EwcdJmof6b8lXs=; b=eKCywP2vlrg6YpkVTnFYqc7Xo3Kho3qMwMld8+u2ra3a8eL/PTmHTgQMty2hHpMH5e oX74Z7uooqUoh343c/RKQ44rgr5TYmbtTRO68nGzx67tTHDgaDjNDfdRmZM8jV77jmUe UBlm7cq7Wwu2cfy5zU3sWU5mB9i8PODXoZfJbUyrqtVDXa4U6UiiZpa0S+JH8OpZ3PS9 9Oio0mM9QEGuqZrb4GTMAj348CUeLXKhCxjVy6SqnlfPJOJPRg94uEddlmah6gKaQAXg XLQds7TiWSL0kXOPhheZJch9hFUOs+pGanjcS+HJhJ1kheVFf9zfOZIWzqT8/ELi4u2I t14g== X-Forwarded-Encrypted: i=1; AKwUvBw0nMxjmEIv5x+9segVCNA6KgXFFkV3jOYK4CU3e8kGnvvmrRQfra5Ds1HguUWQKfqMwIKLCY5drQM=@lists.xenproject.org X-Gm-Message-State: AFuF++n8Cw0BhmPbTFEzw4jgLEsRTb8nc90GAL5Nwdd4nZEpMkxAhrqY 7v1kyZOhpw400kjNnBDEBP954Jbd61iqIItyHZDedTPbIIitL1epr6K4 X-Gm-Gg: AYBFou2xY2+yEZBHoGKPHJk0Ip5XuehOLQL9sS4YNZkvO6HFb4IsKNuX7eqWduCKg3s DOLwcjTmvRgvqfDw4pmHWfT54N+ExcaXmFQ/kIvqp5//6zAQHPED4sjrfs7f5CZTaWOFdXymti6 Hk0/PqwlikfzG64KMRRN4/3txt7rFJXFDmkPg4EY4cQz+B0IjJxMrqsdz2167DnRx/YLeLNPH2M c5cpduwYOvdg3KwvC/cxXZnVxFD4nJ6BOZ5nYrRtdxeYl5U7Nxob8eDlO57QZNUArwLrnlZSozo f4fqRp2uA/3sgCqxAzEotDa+NRXeeRCMTrSV95G7nzdjXqXvS/vRglyF3vBhqMjcgBu84VREsLL +nsvLT9X+q310atbaunQ255kGNOpJMsAkWFHHvJUb5JwiEweZc0NOzh8FmKmozGWJu40gWvvVVf g6Z4LWhQhx/q+4j4Y+gF28Hj6+l+Sefukfa/NDomOge2JOK289f2jAbIGoUj5Nle6ZNlwIc3G6V tS1b/9PBSf7y0A7mYlmSzy1Hwy93/rUiCVCrRXLytIqw7oVow== X-Received: by 2002:a05:600c:46c7:b0:49d:7fc:5dc5 with SMTP id 5b1f17b1804b1-49fc56dba6emr176849145e9.1.1790067003172; Tue, 22 Sep 2026 01:50:03 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 10:50:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation To: SeungJu Cheon Cc: Jan Beulich , Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> <68ab5241-7301-4988-9420-bcccc4b16e3d@suse.com> <071ed630-4c72-4df1-b15e-3037e3f076ba@gmail.com> <48857983-ac79-44a0-8a11-93f62ac3d0c4@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790067003-A56C2AE4-80A11160/10/73395122804 X-purgate-type: spam X-purgate-size: 2887 On 9/12/26 10:50 AM, SeungJu Cheon wrote: > On Thu, Sep 10, 2026 at 04:24:06PM +0200, Oleksii Kurochko wrote: > [...] >> In v3 I'll (a) stop using ->processor and take the (guest_file_id, >> vsfile_cpu) pair, which imsic_update_state() updates atomically under >> vsfile_lock, and (b) do the snapshot plus the h/w TARGET write under >> aplic.lock, which aplic_reconfigure_target() also holds. As >> imsic_update_state() completes before aplic_reconfigure_target() (also that >> could be checked in this patch series and is introduced a little bit later. >> Probably I have to re-order some patches again) takes the lock, the emulated >> write either happens before the scan (and gets fixed up, or skipped as >> already correct) or after it (and sees the new location). >> >> Any better option I have now? > > Unless I am missing something, the snapshot also needs to handle the > case where the target vCPU has not been attached yet: > vcpu_guest_file_id() returns zero until the vCPU has gone through > imsic_vsfile_attach(), i.e. until it is scheduled for the first time, > and vsfile_cpu is NR_CPUS until then. > > With the current code, a write targeting such a vCPU makes > aplic_msi_target_gen() program Guest Index 0 into the physical APLIC > target register. According to AIA section 4.5.16, Guest Index 0 selects > the hart's supervisor-level interrupt file rather than a VS-level guest > interrupt file. Could this cause the MSI to be delivered to Xen's own > interrupt file with the EIID supplied by the guest? > > I also could not find where such a target would be updated once the > VS-file is attached. imsic_migrate_vcpu() reprograms the relevant > targets during migration, but the initial imsic_vsfile_attach() path > does not appear to replay targets which were written before the > attachment. > > Whether a write targeting an unattached vCPU should be supported seems > like a separate question. Independently of that choice, would it make > sense to avoid programming the physical TARGET register while > guest_file_id is zero? The virtual target could either be rejected, or > retained in the shadow target[] and programmed once the VS-file is > attached. If the target vCPU hasn't attached yet it means that continue_to_new_vcpu() for it wasn't called so it will be rejected by target register emulated code: ... target_vcpu = domain_vcpu(currd, guest_hart_idx); if ( !target_vcpu ) { gdprintk(XENLOG_ERR, "Invalid vCPU id in target register\n"); /* Ignore such writings */ return true; } ... (probably we should back to this question in v3 of this patch as several things were updated and some of your concerns mentioned here looks to me not really possible) Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 09:18:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 09:18:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428381.1651103 (Exim 4.92) (envelope-from ) id 1x8wdX-0003Yk-Ea; Tue, 22 Sep 2026 09:18:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428381.1651103; Tue, 22 Sep 2026 09:18:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8wdX-0003Yd-Bt; Tue, 22 Sep 2026 09:18:03 +0000 Received: by outflank-mailman (input) for mailman id 1428381; Tue, 22 Sep 2026 09:18:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8wdV-0003YX-LV for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:18:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8wdU-003s7Y-Nb for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:18:00 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab247bc-bab6-0a2a0a5309dd-0a2a450283c6-38 for ; Tue, 22 Sep 2026 11:18:00 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab247c6-6ca4-0a2a45020019-b9ff1c128df9-3 for ; Tue, 22 Sep 2026 11:17:58 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c868594900072c4.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 09:17:56 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 0DF5581B88; Tue, 22 Sep 2026 11:17:56 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=Ey+VyVbFYdwB/cAkjwXzT2mnm7rY6FcAP6/4dCNmN4s=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=M4IS4VFm4+hfM1D69LgCYwCNcSXDIrsrz39AGf1vU3oY0ADUtg0zwrY5YBKNyrnjy1sjIU2Xz Q9WTHBk9Gmlv1WdLaQ3GfilJxlcKi+Xd19soRHSZ9du8wOvmvMI24TWaKzxRPx6lrWbApvkiyDa pN1CY2uZnOnXZHAQUAhnlyfV0ExmJtgm61lDjPZv/sgpStf1qNqzMSlEPj49K5gNuskP5g5sawS sQSTg6eV0bWEBnJKOfRk5F0X7AEwZ/Pyvfd5FlbtKDvyli1fqUweglEK8nXaKBSIxOqb0ScS8LU s/DcpY3YBWVkTxp9d4V09DCFuGXKzY9e179Gaes0Ia+g== X-Zone-Loop: de9b7c4808def73ec177634e76e66c17e1798e92caea x-campaign-type: default x-transaction-id: e26c2122-091e-4562-8b0c-55dd9452c0e1 x-swg-uid: 01-8aeca70a-1403-475f-b1b4-8ca2649d775d X-Mailer: Sweego Message-ID: <1790068677.8631fc262581453bbf619ec5b2062170.1a0c868594900072c4@vates.tech> x-swg-bid: 1790068677.8631fc262581453bbf619ec5b2062170.1a0c868594900072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling From: Baptiste Le Duc To: Jan Beulich Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> <450d0c5e-2101-4b1c-98fd-2f438bd0ccf3@suse.com> <1790010225.8631fc262581453bbf619ec5b2062170.1a0c4ec74f000072c4@vates.tech> Date: Tue, 22 Sep 2026 11:17:50 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790068670; l=6981; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=UYVrUyLKG+qpxD4aojxjl9DRgwJXPjGMib3r+pnhyQg=; b=tpCE5owuukW7NPO9561rhcr7WHjPSTkeY/VDUSIBiuyIdppllr0kRsk3KyWerA5NbFhsP1nCG 5uo5YcgoJbeBU7idwVcbnvRtuQhk/RNssbqDTqLUQclTQpcO2I8Wfv4 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790068676250 X-purgate-ID: tlsNG-720697/1790068678-676BF2AC-FC5D502B/0/0 X-purgate-type: clean X-purgate-size: 6985 On 2026-09-22 08:24 +0200, Jan Beulich wrote: > On 21.09.2026 19:03, Baptiste Le Duc wrote: > > On 2026-09-21 17:26:47+02:00, Jan Beulich wrote: > >> On 10.09.2026 11:34, Baptiste Le Duc wrote: > >>> @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) > >>> return false; > >>> } > >>> > >>> +/* > >>> + * Svade and Svadu extensions represent two schemes for managing the PTE A/D > >>> + * bits. When the PTE A/D bits need to be set, the Svade extension indicates > >>> + * that a page fault will be raised. In contrast, the Svadu extension supports > >>> + * hardware updating of the PTE A/D bits. > >>> + * > >>> + * There are 4 possible combinations of these extensions in the device tree. > >>> + * The default hardware behavior for each is: > >>> + * > >>> + * 1) Neither Svade nor Svadu present in DT => It is technically unknown > >>> + * whether the platform uses Svade or Svadu. Xen should be prepared to > >>> + * handle either hardware updating of the PTE A/D bits or page faults when > >>> + * they need updating. In that case, Xen assumes Svade because it's > >>> + * harmless if the platform is actually Svadu, while assuming Svadu on real > >>> + * Svade hardware risks an unhandled page fault. > >>> + * > >>> + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. > >>> + * > >>> + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. > >>> + * > >>> + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off > >>> + * at boot time by setting A/D bits. To use Svadu, the supervisor must > >>> + * explicitly enable it using the SBI FWFT extension. > >>> + * > >>> + * The Svade extension is mandatory and the Svadu extension is optional in the > >>> + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose > >>> + * option 3. Platforms aware of the profile can choose option 4, and Xen won't > >>> + * get the benefit of Svadu until the SBI FWFT extension is available. > >>> + * > >>> + * In other words, hardware manages the A/D bits on its own only in case 3, in > >>> + * all the other cases software has to preset them. Instead of open coding this > >>> + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is > >>> + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. > >>> + */ > >>> +static void __init riscv_resolve_ad_scheme(void) > >>> +{ > >>> + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > >>> + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); > >>> + > >>> + /* Case 3: leave the A/D bits management to hardware. */ > >>> + if ( svadu && !svade ) > >>> + return; > >>> + > >>> + /* Case 4 */ > >>> + if ( svadu && svade ){ > >>> + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ > >> > >> Nit (style): Brace placement. > > Sorry for that. I will fix that in v3. > >> Furthermore this is written in a way which Misra would call "dead code". I'd > >> like to suggest (leaving out comments): > >> > >> if ( svadu ) > >> { > >> if ( !svade ) > >> return; > >> > >> if ( !sbi_probe_extension(SBI_EXT_FWFT) ) > >> printk(...); > >> } > > I assume you are referring to Misra C:2012 Rule 13.5 "The right operand > > of a logical && or || operand shall not contain persistent side effect" > > > > If yes, IMO, I think it doesn't apply here as `svade` is evaluated > > before the `if` so there is no side effect that wouldn't have been > > executed in case of svadu=false. > > No, there's nothing side-effect-ish here. With "svadu && !svade" in the > first if(), the rhs of "svadu && svade" in the second one is dead code: > Things would function the same with it dropped. Ok, now I understand, thanks. I'll fix it in next round. > > >>> + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" > >>> + "RISC-V: Defaulting to software A/D updates (Svade).\n" > >>> + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); > >> > >> Nit (style): Indentation (in multiple ways). Furthermore XENLOG_* needs > >> repeating after every newline. > >> > >>> + } > >>> + } > >>> + > >>> + /* Cases 1, 2: Xen assume Svade to be enabled */ > >>> + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); > >> > >> Isn't this a lie (to ourselves) then? > > If you are talking about case 1: > > [1] Yes, it's technically a lie for boards shipped before > > the svade/svadu extension was ratified (e.g., HiFive Premier P550). > > These extensions merely formalized a mechanism that already existed in > > hardware. > > Wait, how do you know this for _all_ boards anyone may ever have made? We don't know but based on [1] and my commit message, if neither Svade nor Svadu are present in DT then it is technically unknown whether the platform uses Svade or Svade. Hypervisor may then assume Svade to be present and enabled or it can discover based on mvendorid, marchid, and mimpid. For this patch, I choose to have the Hypervisor assumed Svade. Saying that, I agree that it doesn't make sense to manually have set Svade extension in the isa bitfield as we could just preset A/D bits regardless of Svade/Svadu during the p2m_set_permission(). It's what kvm explains in kvm_riscv_gstage_map_page(): /* * A RISC-V implementation can choose to either: * 1) Update 'A' and 'D' PTE bits in hardware * 2) Generate page fault when 'A' and/or 'D' bits are not set * PTE so that software can update these bits. * * We support both options mentioned above. To achieve this, we * always set 'A' and 'D' PTE bits at time of creating G-stage * mapping. To support KVM dirty page logging with both options * mentioned above, we will write-protect G-stage PTEs to track * dirty pages. */ [1] https://lore.kernel.org/lkml/20240628093711.11716-1-yongxuan.wang@sifive.com/#t > And for all qemu (and alike) versions which supported RISC-V? Concerning qemu, you're right, in case when (!svade && !svadu) they use by default Svadu (hw updating) for backward compatibility. > > > [2] For boards that do support svade, we could enforce DT > > declaration by adding it to `required_extension` as they are > > explicitly supporting it. However, doing so would cause boards > > without svade/svadu support (as described above) to hit a panic > > during boot. > > > > So in both case ([1], [2]), the svade extension exist either implicitely or > > explicitly. Therefore, force it doesn't compromize anything. > > If, despite my comment above, this is indeed what is wanted, I think it > requires a little more commentary. > > Jan > > > From xen-devel-bounces@lists.xenproject.org Tue Sep 22 09:32:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 09:32:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428404.1651165 (Exim 4.92) (envelope-from ) id 1x8wr7-0006f4-3f; Tue, 22 Sep 2026 09:32:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428404.1651165; Tue, 22 Sep 2026 09:32:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8wr7-0006ex-03; Tue, 22 Sep 2026 09:32:05 +0000 Received: by outflank-mailman (input) for mailman id 1428404; Tue, 22 Sep 2026 09:32:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8wr5-0006ep-4P for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:32:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8wr3-007HYj-TC for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:32:01 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab24b11-8faa-0a2a0a5109dd-0a2a4507a43e-2 for ; Tue, 22 Sep 2026 11:32:01 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab24b11-b4ea-0a2a45070019-4a7de18dca93-3 for ; Tue, 22 Sep 2026 11:32:01 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912d3920so26669105e9.1 for ; Tue, 22 Sep 2026 02:32:01 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48862793528sm3070982f8f.36.2026.09.22.02.31.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 02:32:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790069521; x=1790674321; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Y6txrKKIdewS/4IWM8zB6ZXA+n+6Cw235XWiPcZD5b0=; b=Z8oyp1nKygwRFE1hQI8DrstfianxjkJp8Spntpt+o6/ybjJ47EoyJnAUyVKdQ5Z6QM JxC7F5y8n4LXNNy8Q0pO/qDF4ot5Ykl7BQDfm0SC6mKwr4NZeLDD95InXM/KCdNQTzp4 Yg3NtgAFVs8vBLahOaWkSGAfJT6q6+oiK4vzpu9706dBy8FJSGiUPd4LxokfhntOM8QV SI+SZ2Yd90zEQC+gYyLX3PIUDCYU82XN2hJyR5WcKaOuYibKLkJl2wk/AA/kO1IZCtkf ypYunbUQDiO5hjzE1ySDgeWteYeD0b1MtRGMRGTdlWFxEsyXX4z1zcNc6E+FJmjNreKX W7vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790069521; x=1790674321; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=Y6txrKKIdewS/4IWM8zB6ZXA+n+6Cw235XWiPcZD5b0=; b=eE1EuKnbzLF7WubyRjyOGijLAi+YRlFFuC+4dHMqfSNBHpFjCu9C3aQUQXClCNGWT1 XBbC2OPO2lBi82l05CP2CRvvg7Pp7XSFNy3VEsOFZTif48zumlE0C667cfNTQW8qtThW S0ZTNdCPOqo/F/OOOl7ZzPnXxFzKh8WTekmT43KE0T/f461SJVpo/e944/VlAFHYRF4R hmqteog+TDyPnnflXQa/hRaA9vs8ZqeWHNxVmoJCPILyBK2kiasg4AhDGihBlU1hlkiI SCBPE+nD/PgQZigmrtilaZ1BFUrkdlMuMKWtd8UPZjVL17lfci9ofWldkIb8QQPJSjaG keWQ== X-Gm-Message-State: AFuF++nykX+MnhNnMzL0ahw0RcSE1K3EYf7BJ/wLaXv2bRbXDjWmhRvX ce1yoT+1afGCrTLkbFRO5+pS7xdrKa/sVnum5hlCCbnJ4JIQ4r6zU4N5 X-Gm-Gg: AYBFou1yDcXuzJx1m+V40OI0kkYoK1kVP8JOAXuiwWqd0pNR1Ha3WX+bIct/HFrUWQ8 C1+tDT/Wmu4fZSQMklPmv9M5gYn7xYb5oEy4tJ0SnIx8OskOZiNWAQAj4G0bBUDo+fGAzqgybbR PXZcHYn+J3ssajjIb7uA4q+yHm68nq6gH/FArK+ehBSfGwO4GJtTU2vVaRWzyNWEVIVW/6wFUup Ahjw7vCiuFPzana92FMw/kIUk/ONo1vG4axj8l1J8BhBDTdkln1IzGNY+efkEzTL+HQVE4JI1tk XH+3BO2IMSxkgaURnSvvmHOq8vO6tWLL5IfM91gAGzC4z/9mRByYlnxn3UkyTba5N9xbsK3FmAE lqJN850vw44utf0v4TzepE8khZ/3tsKNsn8FJXtXoKqj1NqC5Bh+V/66zc2VDYX+XGA34DM/HDm j7W4bpdO0TsTNyYANpYq+Tsm3nmHkm2hDJzx6IlxqDM3IM9nowoOiD2U3SGN1OSLZRq0oDdl5fk XEWD6KW0+1ERpJrf0ivgLNYihNVDBHhTOZYANl3JeD2q4Sjo1Q= X-Received: by 2002:a05:600c:4e8f:b0:49c:fc6c:be19 with SMTP id 5b1f17b1804b1-49fc574c2b9mr197641595e9.31.1790069520632; Tue, 22 Sep 2026 02:32:00 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 11:31:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 23/39] xen/riscv: look up the exception table for any trap taken in Xen context To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789721100.8631fc262581453bbf619ec5b2062170.1a0b3b0c18000072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789721100.8631fc262581453bbf619ec5b2062170.1a0b3b0c18000072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790069521-3C411AE4-A8230B4B/10/73395122804 X-purgate-type: spam X-purgate-size: 2257 On 9/18/26 10:44 AM, Baptiste Le Duc wrote: >> do_trap() consulted the exception table only for CAUSE_ILLEGAL_INSTRUCTION, >> which covers csr_read_safe() but not the hlv/hlvx sequences reading guest >> memory: those fault with load/store (guest) page fault causes and would >> reach do_unexpected_trap() instead of their fixup. >> >> Move the lookup ahead of the cause switch, and gate it on the trap having >> been taken in Xen context and not being an interrupt: >> >> - sepc of a trap taken from the guest is a guest VA/PA, which the >> guest can point at an address listed in the exception table; Xen would >> then act on that entry and, for EX_TYPE_TRAP_INFO, write through a >> pointer fully under guest control. Entries are matched by exact address, >> so this needs no more than a numerical collision. >> >> - an interrupt taken at an address listed in the table would otherwise be >> "fixed up" as if the access itself had faulted, silently skipping it and >> handing the caller the interrupt's scause as a fault cause. >> >> Returning early skips check_for_pcpu_work(), which is correct: that only >> runs for traps taken from the guest. >> >> With that in place a G-stage fault reaching the switch can no longer have >> been caused by an hlv/hlvx covered by an entry, so anything left must have >> come from the guest; assert as much. > What means `assert as much` here? As you referencing any assert in the code, > because in this patch, I couldn't find any. It refers to the BUG_ON(!from_guest) in the guest page fault case of do_trap(). That BUG_ON() (and the comment above it) ended up in "xen/riscv: add guest page fault handling stub" when the series was reordered, so this sentence is stale. I will drop 'assert as much' from commit message. >> >> Cache the "trap came from the guest" test in a local, it is now used four >> times. > Nit: By reading this sentence, I would expect to have the introduction > of `from_guest` local here instead of in patch cc2d3b97e8 > xen/riscv: add guest page fault handling stub > `from_guest` is introduced in "xen/riscv: add guest page fault handling stub" so it is a stale part of the commit message. Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 09:35:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 09:35:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428411.1651174 (Exim 4.92) (envelope-from ) id 1x8wu2-0007Co-FG; Tue, 22 Sep 2026 09:35:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428411.1651174; Tue, 22 Sep 2026 09:35:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8wu2-0007Cg-CF; Tue, 22 Sep 2026 09:35:06 +0000 Received: by outflank-mailman (input) for mailman id 1428411; Tue, 22 Sep 2026 09:35:05 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8wu1-0007CW-Ac for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:35:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8wu0-007I6H-NY for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:35:04 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab24bbc-bab6-0a2a0a5309dd-0a2a4504d164-36 for ; Tue, 22 Sep 2026 11:35:04 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab24bc8-b57f-0a2a45040019-b9ff1c23ab3f-3 for ; Tue, 22 Sep 2026 11:35:04 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c877f7de00072c4.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 09:35:00 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id CBAFA81DBE; Tue, 22 Sep 2026 11:34:59 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=RVehtOiNO368PKacXNEj57lZ8HSUNGevRwXwpFLJTZ4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=K4cSdBAGEr/U9/A4/O7IZrxgZ1kLp0ekfxPVEo2P8mnx1s16HbHju/LLd4ph/QYWC5JXPawa9 CD628BqcyGDArpxODnsJY8Zqkc8YxaX4F+T3GuuQEhguFc7RdFW0DgCVVDLLVRCKq6NBsfpcU8k UJtxWiNm780LlJIX03jKAsTKfD93fuW5BsK7cpRchqxvhpt4qornD9pMuGRkob4/2n8aQdM2bpK DE4H+p4M+grfZqskhem5yLJmT7sH/j069V/Pcz3rOHKamdjiqz+cZ3LMAouRwzYXzI/01ZKpmSX z3igiJgyCyLVsAiHd/U0CxhkhEIdvbFHnPCcD16cyCug== X-Zone-Loop: f1a5f5ad25b63c403131ed89a54b9e4b7e1cedc7dd33 x-campaign-type: default x-transaction-id: f524bc06-081d-4175-b818-450274836687 x-swg-uid: 01-57d4bece-be98-4c4c-91f5-f617b4a93418 X-Mailer: Sweego Message-ID: <1790069700.8631fc262581453bbf619ec5b2062170.1a0c877f7de00072c4@vates.tech> x-swg-bid: 1790069700.8631fc262581453bbf619ec5b2062170.1a0c877f7de00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 6/6] CI: run the riscv64 smoke test via QTB framework console-test From: Baptiste Le Duc To: Alejandro Vallejo Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini In-Reply-To: References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823789.8631fc262581453bbf619ec5b2062170.1a0429a155d000c4f3@vates.tech> Date: Tue, 22 Sep 2026 11:34:54 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790069694; l=5865; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ZLWLsKxExfBqzvdQb0cfTR7YXVQ+4A2Io838q9LVL5g=; b=ckErGsj57ggV5a6/Z2WQKTDe+V/XNMTfsCN9bPCH2T1bgsCn95fBlzA4OBFMxePZu41iW7LW2 D+5yNr4VxfwBgwVfkIcrGfYzQWFaEdJNiIJKNr19rKm3ZnAdp6JWcjU X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790069699927 X-purgate-ID: tlsNG-ebf023/1790069704-C36C2B50-26F894B0/0/0 X-purgate-type: clean X-purgate-size: 5869 On 2026-09-21 16:37 +0200, Alejandro Vallejo wrote: > On Thu Aug 27, 2026 at 11:42 AM CEST, Baptiste Le Duc wrote: > > qemu-smoke-riscv64-gcc drove QEMU through > > automation/scripts/qemu-smoke-riscv64.sh, an expect wrapper whose machine > > description (cpus, memory, device tree, console wiring) lived in the script > > itself. The QTB framework now owns all of that: machines come from the > > shared catalog, expectations from the test type's own YAML. > > > > Turn .qemu-riscv64 into a template running qemu_smoke_riscv64.py run > > in the qtb-riscv64 container, machine and test picked per job > > through QTB_TEST_TYPE/QTB_TEST. The container comes from the test-artifacts > > registry, hence the new ARTIFACTS_REGISTRY next to the existing > > ARTIFACTS_REPO/ARTIFACTS_BRANCH. QTB_BINARIES_DIR points at the artifacts > > of the job (Xen only currently, but aims to have initrd and linux images > > when dom0less will be supported). QTB_LOG_DIR collects the per-console > > logs, kept on failure and on success. > > > > Point qemu-smoke-riscv64-gcc at that template, running the console-test > > type on dom0less-1smp-0domu-1vcpu-aplic-imsic-null: a Xen-only machine, so > > the smoke check is Xen's own "All set up" on console 0, the same string the > > expect script waited for. > > > > Drop automation/scripts/qemu-smoke-riscv64.sh as it has no caller left in > > the CI after this patch and drop smoke.serial from the .qemu-riscv64 > > artifacts since no riscv64 job uses it anymore, the logs are now kept under > > QTB_LOG_DIR. > > > > Assisted-by: Claude:claude-opus-5 > > Signed-off-by: Baptiste Le Duc > Hi Alejandro, > This is all quite large and monolithic to review quickly, but I can > already tell you that replacing a <50LoC test with such a massive > infra bench is probably not quite what you want at this point in time. Thanks a lot for this quick review. Sorry for these long patches, I will split them to make the review easier. > > IMO, you ought to keep the existing test in place and perhaps integrate > the new infra with new tests that would be complicated without it. > Things like injecting bizarre interrupts (NMI?) and capture expected > behaviour. > > Or even duplicating the existing test would be fine. Build confidence in > it and only after you really trust it do remove your previous smoke. Oh I don't know we could proceed this way... Duplicate seems then to be a good idea. The aim of this patch series was above all to introduce the the core framework which will be used to inject interrupts. console_test.py replaces the old smoke test but adds per-domU console testing, which goes beyond the original scope. I'll trim it to match. > My .05 cents at least. Thanks again! > Cheers, > Alejandro > > > --- > > .gitlab-ci.yml | 3 +++ > > automation/gitlab-ci/test.yaml | 20 ++++++++++++++------ > > automation/scripts/qemu-smoke-riscv64.sh | 19 ------------------- > > 3 files changed, 17 insertions(+), 25 deletions(-) > > delete mode 100755 automation/scripts/qemu-smoke-riscv64.sh > > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > > index f42a9abeaa..15f93b8634 100644 > > --- a/.gitlab-ci.yml > > +++ b/.gitlab-ci.yml > > @@ -11,6 +11,9 @@ variables: > > ARTIFACTS_BRANCH: > > description: "Branch in test-artifacts to use" > > value: master > > + ARTIFACTS_REGISTRY: > > + description: "Registry holding the test-artifacts containers" > > + value: registry.gitlab.com/xen-project/hardware/test-artifacts > > LINUX_JOB_X86_64: > > description: "Job name in test-artifacts to use for Linux x86_64" > > value: linux-6.6.56-x86_64 > > diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml > > index 61adc1baff..e9dd147380 100644 > > --- a/automation/gitlab-ci/test.yaml > > +++ b/automation/gitlab-ci/test.yaml > > @@ -72,14 +72,21 @@ > > TEST_TIMEOUT_OVERRIDE: 120 > > > > .qemu-riscv64: > > + image: ${ARTIFACTS_REGISTRY}/${CONTAINER} > > extends: .test-jobs-common > > variables: > > - CONTAINER: debian:13-riscv64 > > - LOGFILE: qemu-smoke-riscv64.log > > + CONTAINER: debian:13-qtb-riscv64 > > + QTB_LOG_DIR: qtb-logs > > + QTB_BINARIES_DIR: ${CI_PROJECT_DIR}/binaries > > + script: > > + - ./automation/scripts/qemu_smoke_riscv64.py > > + ${QTB_TEST_TYPE} > > + run > > + ${QTB_TEST} > > + --log-dir ${QTB_LOG_DIR} > > artifacts: > > paths: > > - - smoke.serial > > - - '*.log' > > + - ${QTB_LOG_DIR} > > when: always > > tags: > > - x86_64 > > @@ -779,8 +786,9 @@ qemu-xtf-argo-x86_64-gcc-debug: > > > > qemu-smoke-riscv64-gcc: > > extends: .qemu-riscv64 > > - script: > > - - ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee ${LOGFILE} > > + variables: > > + QTB_TEST_TYPE: console-test > > + QTB_TEST: dom0less-1smp-0domu-1vcpu-aplic-imsic-null > > needs: > > - debian-13-riscv64-gcc-debug > > > > diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh > > deleted file mode 100755 > > index c0b1082a08..0000000000 > > --- a/automation/scripts/qemu-smoke-riscv64.sh > > +++ /dev/null > > @@ -1,19 +0,0 @@ > > -#!/bin/bash > > - > > -set -ex -o pipefail > > - > > -# Run the test > > -rm -f smoke.serial > > - > > -export TEST_CMD="qemu-system-riscv64 \ > > - -M virt,aia=aplic-imsic \ > > - -cpu rv64,svpbmt=on \ > > - -smp 1 \ > > - -nographic \ > > - -m 2g \ > > - -kernel binaries/xen" > > - > > -export TEST_LOG="smoke.serial" > > -export PASSED="All set up" > > - > > -./automation/scripts/console.exp |& sed 's/\r\+$//' > > > From xen-devel-bounces@lists.xenproject.org Tue Sep 22 09:56:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 09:56:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428447.1651275 (Exim 4.92) (envelope-from ) id 1x8xF1-0003IM-4R; Tue, 22 Sep 2026 09:56:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428447.1651275; Tue, 22 Sep 2026 09:56:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xF1-0003IE-1E; Tue, 22 Sep 2026 09:56:47 +0000 Received: by outflank-mailman (input) for mailman id 1428447; Tue, 22 Sep 2026 09:56:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xEz-0003I1-4T for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 09:56:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8xEx-005Ec8-Px for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:56:43 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab250db-8faa-0a2a0a5109dd-0a2a4506b934-2 for ; Tue, 22 Sep 2026 11:56:43 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab250db-195a-0a2a45060019-4a7de14cbb0b-3 for ; Tue, 22 Sep 2026 11:56:43 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843f22dc83so2833160f8f.1 for ; Tue, 22 Sep 2026 02:56:43 -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 ffacd0b85a97d-48862774543sm4224894f8f.11.2026.09.22.02.56.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 02:56:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790071003; x=1790675803; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=TROsMyFOjYUy/gyXB882VmN50PjnTVwwmj/TjE1k1Os=; b=bXSJV6LafcX/jcJ/tCwyAfyA/EL6s3K3F/EZ6qXC+HnnN1o4Gqa/tvNAvKdwiWVKfc sKThEu4FMKCjBH0/RWVdrzgfyVUOgRjGAo0SnjIHQjIZCwbqeTy8bNWGUfcBiI5loxUQ IuhSkioG3jUGxFBK69U46ATEd7DSb33n2E3G7dnmcAPQ0FBgx1Sz+jVG8Qg1Xf60LLgH eAccI6Mf1YnHBivGPYnGw7WUUUzEe33QiarkPjB/DIhahLj9MUxrMHITYjL050yY3fcA HtQXAmcQt0Gv58xDRWxRI1DxBTHCqX0Tkhmw2Gc/z8oL2E24O0/v6BaO0KC3nee25JQw wmSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790071003; x=1790675803; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=TROsMyFOjYUy/gyXB882VmN50PjnTVwwmj/TjE1k1Os=; b=u4gy8VdNvlMJVFiLx22Zp5e1SeOl0OVlIl/8BFUFeD9Fpko4WNt1kFlTztYS9wzyRU J2tyExPiQAeiV5QBmhU+uvq13ymzpZV+gTV68oQkcsVgJBukuntIsfkPwef1jESQcJic LhOc4gxJAVLaEqX7SDVIV5Pu3e13uvzJfSUlR4+p3Ysek+781DP0SGuCGZN2tiCdoiGU O9kPOSSH26kBynYAR5tEc4emj2O0eQnK2zN6vWhgJB7kANomyDTwGbkIJvpyDBnJQRMU hOmkk7e4kyaD6WW0jv2bptceXx57GSiKk/RwL6/QzNo2Q0MW75qPDnfKrWR7pbeMg4We VDOA== X-Gm-Message-State: AFuF++lCLTs+YnA1Xonc9NJkgvpDtdudSMMMgChzq9uOZVpYz4o0jEMa nmGa26pYtjJDg+0WiD6oG1p29h+x5j6c5/jaAlR7g1b0NlEBBARV0koAPlQIllxX+O70pB3STFr Iriv5fA== X-Gm-Gg: AYBFou0WZA9Q+auJt2uIwsSi8Oqf/8hTZ/yqndquWqzdMj1WNhQ4j+RA68VyjHKlrNk 4uJsY5x/FcaLTyzkJNgurBpJO8WrWonBgV13Y6j6Ztkd100uaBWjNXjPfwjdhmSmNT3jvP+ues9 VZp24vT4OJOh8lw1s43fqhHIjOeXAdwXtd/42hKVXZkda5udBoDDPEyU3hfifTGBVBl2S1lwGEw vXeqgZx+bb0AbiyHq2g5dVBcCHalsEZHSlkwLVmDUeyz20hCD1wUt0mulDQWB8wolQswNlDD7Mn FEq9OxUVUOGXQBBPpv3+dtPUNXG/6CxxAZZm8tVkl4P1jcPGuDMYsQ1GEKt+2Cjy/QqeIy78dUo K57RwTnKCVLX4oszFqHawtcvbw5/fc4G+tJfpcKkG1jjL+xtmGuYh4qDkfnPpJpKpOjw8jlc37r iHmDQr2F7PVzsgEUDdPGLgi+qmqbx/HQ1HATQwjZwjxuwrv0D4ucihmmJ463OirI25SU9VLLEU0 BjVODP7rDQX5DSMBsN7E2SDjgat3AY8PYkDfZcFmwsEkIPb+/R9aN5BBrq/Pg== X-Received: by 2002:a05:6000:4b14:b0:487:f18:9a3e with SMTP id ffacd0b85a97d-4871e3aa52fmr18678967f8f.43.1790071002602; Tue, 22 Sep 2026 02:56:42 -0700 (PDT) Message-ID: <8b679f4c-17e6-49ef-8a7d-390e10452904@suse.com> Date: Tue, 22 Sep 2026 11:56:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/6] Arm: split xen-syms linking rule From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk References: <153fd1b8-810a-4091-84d5-5395d83f2ee9@suse.com> Content-Language: en-US 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 X-purgate-ID: tlsNG-16d1c6/1790071003-F7ECC77B-CA4F5B5C/0/0 X-purgate-type: clean X-purgate-size: 1598 On 08.09.2026 14:28, Jan Beulich wrote: > Doing so, besides (hopefully) adding clarity (not the least by way of > [re-]using pattern rules where possible), also avoids explicit recursive > $(MAKE) invocations. > > By re-using the generic rules introduced when the respective x86 rule was > split, > - the .map file now isn't created after the final binary anymore, > - --strip-debug is passed to $(LD) during early linking passes (for > consistency the option is also explicitly added to the optional linking > pass rule), > - CONFIG_{SUPPRESS_DUPLICATE_SYMBOL_WARNINGS,ENFORCE_UNIQUE_SYMBOLS} are > now properly respected. > Orphan section checking, otoh, is getting suppressed for now, until the > about a dozen warnings which would result have been taken care of. Similarly, for randconfig, I had to suppress ENFORCE_UNIQUE_SYMBOLS=y for the time being, with the incremental patch below. I'm about to submit a patch to undo that (by first fixing the collisions). As per https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2870284545 the issues were: Arm64: Duplicate symbol 'head.o#fail' (a0000200544 != a0000200178) Arm32: Duplicate symbol 'head.o#fail' (200178 != 200650) Jan --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -91,6 +91,9 @@ include scripts/Makefile.link # Suppress orphan section checking for the time being. orphan-handling-y := +# Downgrade duplicate symbol errors to warnings for the time being. +syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --warn-dup + .PHONY: include include: From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:04:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:04:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428459.1651283 (Exim 4.92) (envelope-from ) id 1x8xMi-0005J1-R3; Tue, 22 Sep 2026 10:04:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428459.1651283; Tue, 22 Sep 2026 10:04:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xMi-0005Iu-OS; Tue, 22 Sep 2026 10:04:44 +0000 Received: by outflank-mailman (input) for mailman id 1428459; Tue, 22 Sep 2026 10:04:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xMg-0005Ig-EJ for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:04:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8xMf-00FzmI-RN for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:04:41 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab252b6-e002-0a2a0a5209dd-0a2a4501e8fa-10 for ; Tue, 22 Sep 2026 12:04:41 +0200 Received: from [46.105.55.200] (helo=6.mo563.mail-out.ovh.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab252b8-5984-0a2a45010019-2e6937c8b1cb-3 for ; Tue, 22 Sep 2026 12:04:41 +0200 Received: from director6.derp.mail-out.ovh.net (director6.derp.mail-out.ovh.net [79.137.60.226]) by mo563.mail-out.ovh.net (Postfix) with ESMTPS id 4hpwgX32ZXz5xBq; Tue, 22 Sep 2026 10:04:40 +0000 (UTC) Received: from director6.derp.mail-out.ovh.net (director6.derp.mail-out.ovh.net. [127.0.0.1]) by director6.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP for ; Tue, 22 Sep 2026 10:04:40 +0000 (UTC) Received: from mta2.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.110.96.120]) by director6.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4hpwgX1hzLz46XY; Tue, 22 Sep 2026 10:04:40 +0000 (UTC) Received: from mailstore7.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.1.8.7]) by mta2.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTP id 47B7F3E1C79; Tue, 22 Sep 2026 10:04:39 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=ovhmo-selector-1 header.d=trinity-net.com header.i="@trinity-net.com" header.h=From Date: Tue, 22 Sep 2026 10:04:39 +0000 (UTC) From: Support TRINITY To: Sasha Levin Cc: "Rafael J. Wysocki (Intel)" , Sasha Levin , Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= , regressions , linux-acpi , linux-pm , xen-devel , linux-kernel , Stable Message-ID: <85435495.299101679.1790071479170.JavaMail.zimbra@trinity-net.com> In-Reply-To: <2026-09-21-daily-reply-0001-re-acpi-cpuidle-xen-dom0-6-18@kernel.org> References: <1909296988.289641012.1790015372050.JavaMail.zimbra@trinity-net.com> <2026-09-21-daily-reply-0001-re-acpi-cpuidle-xen-dom0-6-18@kernel.org> Subject: Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [93.25.54.230] X-Authenticated-User: support@trinity-net.com Thread-Topic: ACPI processor/cpuidle change in 6.18.52 breaks bare-metal Xen dom0 boot Thread-Index: K73oORQOTU57TlGFBhdBixjIo6r4Nw== x-ovh-tracer-id: 5960514109192304155 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: dmFkZTGW2IyZ/YhHU9dSERzRYRpzlG0d5PBjuMM0K21jz02Okjd/bCKxP1ZZRuOy/r/ltrGOr888QHzjvDzzQi0zj0e4dR+2bAR/+R5MiSycoysPZjrO4AkftF3W8vsz6sYndEZb11LXltTssTuH3cOm3NP7FMwSfLDM4TpFiRM0f8kwLKIjc1sjh1mq+V1a49WPCknOvHd+6HbFREV6QWabnMcF1iWJPn/XdJ0h2YIJrvYkDioxQiNhuucf8YCjEDugAeC6CDc9v8yBLGuRKHaDh9Y8a4rat0hJKtkf+jmC5RDEOsrwiNA929B7TyYqVi76j6YnQg/UkD3KxtM3T+NyePm/nl6lpqhjSrJb6CIlzOTm/ovxqvyM2s2w067weK8F5tLYlwMR2Q4VYJhw8iC7LtzUqXb2LH6+jU92iwCRleThQlUbC6Z0fWGXQfVKe4/w49zB011P8Ps0Iup2oL1EEdCa6P77NRQcwCybSn1jRzIEmGpOdnRHRv4ibhop54BmayavlnDMye4CjEtUYTGHMQHGopXIAm5faRbrlXNuaaotm+LIjnskpaFCxAyxdETDPsxHH6oU9AbDWl+48A9jqIizrN9dsRSHih4XBZTE8ST0EAJ+tO6BWBDGbkn26cy5ORq+weZ/21z56gDpsC6jogFYmRcUYq8kXsp3AQpEO5fC7g DKIM-Signature: a=rsa-sha256; bh=SQqW3vRIkopO+wMee+p+HGuzJFeS+9zxJ92hnhTL4vE=; c=relaxed/relaxed; d=trinity-net.com; h=From; s=ovhmo-selector-1; t=1790071480; v=1; b=VaG/sPRT/5Wkmyg6O2UgpCTVF3vInOg+yIy0yxjvtzD+plqdz/3Jn8A2tgKtSc4LHHhFb9A2 TaHW5/PY2TSRsydiH3xeLpmPt/o4ErSwqQ/dBL6rslyZnGDs5zfOTBKOuQx1dxeGg6+wTqHc6HH i4NejfDLPmyb8yaJHV2TSSmhLfJbbFTxt4DsXcO4PvvlJibEsebZPiZSZFWKWszTcZ/SFnE3on6 5y2aKAVehynIDD4854CTMrOL+J7+kFigmlPlagWvJ92YgDZoMKz8t0xgKOL9me0y2n8zlWvMpG5 6GLGQLBsnGp6ZFcqqQF64ERmSEuMxY8baALBB9axwHFtg== X-purgate-ID: tlsNG-d62444/1790071481-BEE60757-469D8914/0/0 X-purgate-type: clean X-purgate-size: 1533 I have now tested Linux 6.18.52 with commit: 0089ce1c056a ("ACPI: processor: Update cpuidle driver check in __acpi_proce= ssor_start()") applied on the affected Alpine Xen dom0 bare-metal host. Result: it boots successfully. Xen dom0 comes up correctly, /proc/xen is mounted, xenstored starts, SSH is reachable, and xl info, xl list, etc... work as expected. So this confirms that 0089ce1c056a fixes the regression on this affected Alpine system. Thank you Rafael for identifying the missing stable dependency. Regards, Tony -----Message original----- De: Sasha Levin =C3=A0: Rafael J. Wysocki (Intel) Cc: Sasha Levin ; Marek Marczykowski-G=C3=B3recki ; regressions ; lin= ux-acpi ; linux-pm ; = xen-devel ; linux-kernel ; Stable ; Support TRINITY Envoy=C3=A9: mardi 22 septembre 2026 04:23 CEST Sujet : Re: [REGRESSION] ACPI processor/cpuidle change in 6.18.52 breaks ba= re-metal Xen dom0 boot > I will try testing 6.18.52 with commit 0089ce1c056a ("ACPI: processor: > Update cpuidle driver check in __acpi_processor_start()") applied, > instead of using my lifecycle revert. Queued for 6.18, thanks. Please still post the result of that test once you have it. --=20 Thanks, Sasha From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428467.1651302 (Exim 4.92) (envelope-from ) id 1x8xQv-0006Or-Fz; Tue, 22 Sep 2026 10:09:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428467.1651302; Tue, 22 Sep 2026 10:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQv-0006Ok-DM; Tue, 22 Sep 2026 10:09:05 +0000 Received: by outflank-mailman (input) for mailman id 1428467; Tue, 22 Sep 2026 10:09:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQu-0006Ga-Fs for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:04 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xQt-00Ao1x-2c; Tue, 22 Sep 2026 10:09:04 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xQu-00DE8C-12; Tue, 22 Sep 2026 10:09:04 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=H/MbAY1eGqbTAnphWhom0M3ym5qcu8LUIEqlrx+aImc=; b=JM9IUQ4VbldbOLucyunP3iJ5F/ VR5KVOpiwzw5fjUPZtqXz+w+aZhSRvxNauAJ6yFShHcpXsehCPo2BL/mApqJ5FiO9alKYYb9ltQ2h AL17E26dztPG+ZWB3IUbGcakTknoXvAzQtEEeUOXqpnh6jm4TzGlfPMFxvxMOGKrYmK4=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 01/13] pytest: Add fixture to prepare rootfs Date: Tue, 22 Sep 2026 12:08:48 +0200 Message-ID: <20260922100900.29129-2-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD It's slyghtly more complicated than the QubeOS's test script as we try here to create a small rootfs with just enough for setting up the network, then once Linux is booted we load the rest, that is Xen's toolstack. Loading the full rootfs at netboot on the moonshot takes more than 10 minutes, while download it once Linux is booted is much faster. The network configuration should be flexible enough, we can select static IP or DHCP, and setup VLAN if needed. I've mainly only tested static IP + VLAN. Signed-off-by: Anthony PERARD --- automation/pytest/lib/__init__.py | 0 automation/pytest/lib/boot_binary.py | 212 +++++++++++++++++++++++++++ automation/pytest/test_boot.py | 32 ++++ 3 files changed, 244 insertions(+) create mode 100644 automation/pytest/lib/__init__.py create mode 100644 automation/pytest/lib/boot_binary.py create mode 100644 automation/pytest/test_boot.py diff --git a/automation/pytest/lib/__init__.py b/automation/pytest/lib/__init__.py new file mode 100644 index 000000000000..e69de29bb2d1 diff --git a/automation/pytest/lib/boot_binary.py b/automation/pytest/lib/boot_binary.py new file mode 100644 index 000000000000..d8f503ead9f2 --- /dev/null +++ b/automation/pytest/lib/boot_binary.py @@ -0,0 +1,212 @@ +from pathlib import Path +import shlex +import stat +import subprocess +from textwrap import dedent + + +def cpio_archive_from_dir(root: Path, output: Path) -> None: + subprocess.run(f"find . | cpio -H newc --owner=0:0 -o | gzip >> {output}", + shell=True, + cwd=root, + check=True) + + +def concatenate_cpios(archives: list[Path], output: Path) -> None: + paths = shlex.join([str(p) for p in archives]) + subprocess.run(f"cat {paths} > {output}", + shell=True, + check=True) + + +class BootBinary: + def __init__(self, tmp_path: Path, xenroot: Path, + pxe_host: str, + http_pxe_path: str, + vlan_id: int | None = None, + static_ip: str | None = None, + static_gateway: str | None = None, + static_dns: str | None = None, + static_ipv6: str | None = None, + boot_script: str | None = None, + ) -> None: + self.vlan_id = vlan_id + self.pxe_host = pxe_host + self.http_pxe_path = http_pxe_path + self.static_ip = static_ip + self.static_gateway = static_gateway + self.static_dns = static_dns + self.static_ipv6 = static_ipv6 + self.boot_script = boot_script + + # Minimal rootfs + rootfs_path = tmp_path / "rootfs_minimal" + rootfs_path.mkdir() + self.prepare_minimal_rootfs(rootfs_path, xenroot) + self.rootfs_dir = rootfs_path + + # Rootfs for dom0 + rootfs_path = tmp_path / "rootfs_dom0" + rootfs_path.mkdir() + self.prepare_dom0_rootfs(rootfs_path, xenroot) + self.rootfs_dom0_dir = rootfs_path + + + def prepare_minimal_rootfs(self, rootfs_path: Path, xenroot: Path) -> None: + script_pre_xen = dedent(f"""\ + #!/bin/ash + set -xe + + wget http://{self.pxe_host}/{self.http_pxe_path}/dom0-rootfs.cpio.gz -O /root/dom0-rootfs.cpio.gz + cd / + gzip -d < /root/dom0-rootfs.cpio.gz | while cpio -iu; do :; done + /etc/local.d/xen.start + """) + + bridge_port = "eth0" + cfg_vlan = "" + if self.vlan_id: + bridge_port = f"eth0.{self.vlan_id}" + cfg_vlan = f"""\ + auto {bridge_port} + iface {bridge_port} inet manual + vlan-raw-device eth0 + # Remove all ipv6 route, they are duplicates from + # the one added to the bridge interface + post-up ip -6 route flush dev $IFACE + """ + + cfg_addr = "" + if self.static_ip and self.static_gateway: + cfg_addr = f"""\ + use static + address {self.static_ip} + gateway {self.static_gateway} + """ + else: + cfg_addr = """\ + use dhcp + """ + + if self.static_ip and not self.static_gateway: + cfg_addr += f"""\ + address {self.static_ip} + """ + + cfg_addr_v6 = "" + if self.static_ipv6: + cfg_addr_v6 = f"""\ + address {self.static_ipv6} + """ + + network_interfaces = dedent(f"""\ + {cfg_vlan} + + auto xenbr0 + iface xenbr0 + {cfg_addr} + bridge-ports {bridge_port} + bridge-stp 0 + {cfg_addr_v6} + """) + + etc_networkd_d = rootfs_path / "etc/network" + etc_networkd_d.mkdir(parents=True) + (etc_networkd_d / "interfaces").write_text(network_interfaces) + + # if static + if self.static_dns: + dns_config = dedent(f"""\ + nameserver {self.static_dns} + """) + (rootfs_path / "etc/resolv.conf").write_text(dns_config) + + # rc-update add networking boot + runlevel_boot_d = rootfs_path / "etc/runlevels/boot" + runlevel_boot_d.mkdir(parents=True) + (runlevel_boot_d / "networking").symlink_to("/etc/init.d/networking") + + local_d_dir = rootfs_path / "etc/local.d" + local_d_dir.mkdir(parents=True) + + pre_xen_start_script = local_d_dir / "pre-xen.start" + pre_xen_start_script.write_text(script_pre_xen) + pre_xen_start_script.chmod(stat.S_IRUSR | stat.S_IXUSR) + + # rootfs archive + rootfs = [] + # Uncompressed first! Then compressed cpio archives! + rootfs.append(xenroot / "binaries/ucode.cpio") + rootfs.append(xenroot / "binaries/rootfs.cpio.gz") + cpio_rootfs = xenroot / "binaries/pre-dom0-rootfs.cpio.gz" + concatenate_cpios(rootfs, cpio_rootfs) + cpio_archive_from_dir(rootfs_path, cpio_rootfs) + + self.minimal_rootfs = cpio_rootfs + + def prepare_dom0_rootfs(self, rootfs_path: Path, xenroot: Path) -> None: + etc = rootfs_path / "etc" + etc.mkdir() + + local_d_dir = etc / "local.d" + local_d_dir.mkdir() + + script_xen = dedent("""\ + #!/bin/bash + + bash /etc/init.d/xencommons start + """) + if self.boot_script: + script_xen += self.boot_script + + xen_start_script = local_d_dir / "xen.start" + xen_start_script.write_text(script_xen) + xen_start_script.chmod(stat.S_IRUSR | stat.S_IWUSR | stat.S_IXUSR) + + etc_default = etc / "default" + etc_default.mkdir() + + xencommons_default = etc_default / "xencommons" + xencommons_default.write_text(dedent(""" + XENCONSOLED_TRACE=all + QEMU_XEN=/bin/false + """)) + + (rootfs_path / "var/log/xen/console").mkdir(parents=True) + + root_home_dir = rootfs_path / "root" + root_home_dir.mkdir(parents=True) + run_tool_tests_script = xenroot / "automation/scripts/run-tools-tests" + run_tool_tests_script.copy_into(root_home_dir, preserve_metadata=True) + + # VM config file + etc_xen = etc / "xen" + etc_xen.mkdir() + domU_type = "hvm" + domU_vif = "'bridge=xenbr0'" + (etc_xen / "domU.cfg").write_text(dedent(f"""\ + type = '{domU_type}' + name = 'domU' + kernel = '/boot/vmlinuz-domU' + ramdisk = '/boot/initrd-domU' + cmdline = 'root=/dev/ram0 console=hvc0' + memory = 512 + vif = [ {domU_vif} ] + disk = [ ] + """)) + + # rootfs archive + rootfs_dom0 = [] + # Uncompressed first! Then compressed cpio archives! + rootfs_dom0.append(xenroot / "binaries/xen-tools.cpio.gz") + cpio_rootfs = xenroot / "binaries/dom0-rootfs.cpio.gz" + concatenate_cpios(rootfs_dom0, cpio_rootfs) + cpio_archive_from_dir(rootfs_path, cpio_rootfs) + + self.xen_tools_rootfs = cpio_rootfs + + def minimal(self) -> Path: + return self.minimal_rootfs + + def dom0_tools(self) -> Path: + return self.xen_tools_rootfs diff --git a/automation/pytest/test_boot.py b/automation/pytest/test_boot.py new file mode 100644 index 000000000000..230cee96d0ba --- /dev/null +++ b/automation/pytest/test_boot.py @@ -0,0 +1,32 @@ +import os +from pathlib import Path +import pytest + +from lib.boot_binary import BootBinary + + +@pytest.fixture +def xenroot_path() -> Path: + return Path("../..").resolve() + + +@pytest.fixture +def prepare_rootfs(tmp_path: Path, + xenroot_path: Path, + ) -> BootBinary: + static_gateway = os.environ['HOST_IP_GATEWAY'] + http_pxe_path = os.environ["PXE_HTTP_PATH"] + + boot_script = f"echo Dom0 ready\n" + + return BootBinary(tmp_path, + xenroot_path, + vlan_id=int(os.environ['HOST_IP_VLANID']), + pxe_host=os.environ["PXE_HOST"], + http_pxe_path=http_pxe_path, + static_ip=os.environ['HOST_IP4'], + static_gateway=static_gateway, + static_dns=static_gateway, + static_ipv6=os.environ['HOST_IP6'], + boot_script=boot_script, + ) -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428466.1651293 (Exim 4.92) (envelope-from ) id 1x8xQu-0006CK-A4; Tue, 22 Sep 2026 10:09:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428466.1651293; Tue, 22 Sep 2026 10:09:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQu-0006CD-7C; Tue, 22 Sep 2026 10:09:04 +0000 Received: by outflank-mailman (input) for mailman id 1428466; Tue, 22 Sep 2026 10:09:03 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQt-0006C5-LZ for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:03 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xQs-00Ao1o-2D; Tue, 22 Sep 2026 10:09:03 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xQt-00DE8C-0Z; Tue, 22 Sep 2026 10:09:02 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: Message-ID:Date:Subject:Cc:To:From; bh=drharIiHk6QqThLjE77hRf70xicJ/qQxf9KOTnsZsJo=; b=pKL8ucXNrv46HWABhKHXocxTn9 ZiQiHi7TmxSVhg8wKhTXMy/2c1fjkd4GkKIF/szVHr6YnS/HbuYMXtKjCKsfPAip8VfpGGH0EwD3M hQGu5f3lI/TCAzTixs+44Kcd6VVH6TRFnowNxpnCSjAjVxnEWwBLqaOnhWoMt3qzZ11A=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 00/13] Running bare-metal tests with "pytest" Date: Tue, 22 Sep 2026 12:08:47 +0200 Message-ID: <20260922100900.29129-1-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD Patch series available in this git branch: https://xenbits.xenproject.org/git-http/people/aperard/xen-unstable.git br.ci.bare-metal-with-pytest-v1 Hi, I wanted to add some new machine to our GitLab CI, but I didn't want to duplicate yet another time the existing shell script. They are good to get the ball rolling but are getting harder to maintain as more test are been added, and don't share common code between machines. So, I've start work on something based on `pytest` which I hope will be easier to maintain and extend and use to add new machines. It's still Work In Progress. Here is the current result: https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/16529107619 In this pipeline, the artifact use are a bit different from master; linux is built with network driver, and vlan; the rootfs is from Marek's patch series, with networking and dropbear service enabled. Next: I'd like to at least have a new fixture that give a started Host that a test can ssh into. Then maybe a new class "Host" which could have functions for ssh and getting the serial console output. Don't go to much into detail review, I'm more interested of a general overview, and to present what I have so far. Some runes: - uv run mypy . to check the code, at least the types used. other code check could be added, and run by the pipeline - uv run pytest to run the whole test suite - uv run pytest test_boot.py::test_xen_tools_tests to run just one test I did create an Arch Linux docker image with pytest, but paramiko got too new to be used, so I've started to use `uv` to deal with the dependencies. `mypy` always needed to be run with `uv` due to missing types for paramiko (not packaged in Arch Linux). So the image is useless, and I'll look for a different image later, for now just Arch Linux with `uv` installed. Thanks, Anthony PERARD (13): pytest: Add fixture to prepare rootfs Creating new python project pytest: Add fixture to prepare the tftp server pytest: Add fixture that boot a machine pytest: Introduce reading the console, and add a test We need an older version of paramiko. pytest: Add random string to look for in the logs pytest: Run run-tools-tests over ssh on the test machine pytest: Generate a rootfs for a guest pytest: Add guest test pytest: Add config to enable live log, and disable ssh/paramiko logging pytest: Add example .env for options for the tests gitlab-ci: Add job for moonshot with pytest automation/gitlab-ci/test.yaml | 21 +++ automation/pytest/.env | 19 ++ automation/pytest/conftest.py | 6 + automation/pytest/lib/__init__.py | 0 automation/pytest/lib/boot_binary.py | 261 +++++++++++++++++++++++++++ automation/pytest/lib/ipmi.py | 155 ++++++++++++++++ automation/pytest/lib/net_boot.py | 60 ++++++ automation/pytest/pyproject.toml | 17 ++ automation/pytest/pytest.toml | 13 ++ automation/pytest/test_boot.py | 237 ++++++++++++++++++++++++ 10 files changed, 789 insertions(+) create mode 100644 automation/pytest/.env create mode 100644 automation/pytest/conftest.py create mode 100644 automation/pytest/lib/__init__.py create mode 100644 automation/pytest/lib/boot_binary.py create mode 100644 automation/pytest/lib/ipmi.py create mode 100644 automation/pytest/lib/net_boot.py create mode 100644 automation/pytest/pyproject.toml create mode 100644 automation/pytest/pytest.toml create mode 100644 automation/pytest/test_boot.py -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428468.1651310 (Exim 4.92) (envelope-from ) id 1x8xQw-0006bz-PO; Tue, 22 Sep 2026 10:09:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428468.1651310; Tue, 22 Sep 2026 10:09:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQw-0006bs-Ma; Tue, 22 Sep 2026 10:09:06 +0000 Received: by outflank-mailman (input) for mailman id 1428468; Tue, 22 Sep 2026 10:09:05 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQv-0006RK-Kc for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:05 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xQu-00Ao27-32; Tue, 22 Sep 2026 10:09:05 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xQv-00DE8C-1U; Tue, 22 Sep 2026 10:09:05 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=wrPZcuAXdEWAGjj1WBjrDx+MHluEOn4L26I9H5HEfgg=; b=RrHt68DlEjnQipELy4DNLB4DSZ iJTE8QgWyM+nniSfSwx/2H/NSiPan0CdGuvHLMTMwdKduhk6usdCgSfw99/W2Rf/DOME4EDP/Fp3g yBI0U7bsBM30s5zar9dNwtvCdyvHjKgHE9YSoOmKDeAuLPnACDqrEsHa5zBBkiFePfhM=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 02/13] Creating new python project Date: Tue, 22 Sep 2026 12:08:49 +0200 Message-ID: <20260922100900.29129-3-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD This can by use by `uv` for example. Signed-off-by: Anthony PERARD --- uv run mypy . --- automation/pytest/pyproject.toml | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 automation/pytest/pyproject.toml diff --git a/automation/pytest/pyproject.toml b/automation/pytest/pyproject.toml new file mode 100644 index 000000000000..3180b2555029 --- /dev/null +++ b/automation/pytest/pyproject.toml @@ -0,0 +1,12 @@ +[project] +name = "xen-ci-intree" +version = "0.1.0" +requires-python = ">=3.14" +dependencies = [ + "pip>=26.0.1", + "pytest>=9.0.2", +] +[dependency-groups] +dev = [ + "mypy", +] -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428469.1651320 (Exim 4.92) (envelope-from ) id 1x8xQy-0006ot-0D; Tue, 22 Sep 2026 10:09:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428469.1651320; Tue, 22 Sep 2026 10:09:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQx-0006om-TJ; Tue, 22 Sep 2026 10:09:07 +0000 Received: by outflank-mailman (input) for mailman id 1428469; Tue, 22 Sep 2026 10:09:06 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQw-0006bn-Ix for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:06 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xQw-00Ao2I-0I; Tue, 22 Sep 2026 10:09:06 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xQw-00DE8C-1x; Tue, 22 Sep 2026 10:09:06 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=m5pcMrpsVzkcznQskoFs5fpPn/HZg88On5QggZelYuc=; b=mEhbB726wfIqB6nZLNEs7MDb20 xL/TX3pqFrZvTHl9dSnWWgRJO8h4r2fDOf2Nn/cmNWNn9Ve5+TWp4HCv6fhlusZhHADnYzqiPBKgv I567QOvIddWZM/x/Aps+0K3r3nkmgTyK1Y9+xIJTXv8H1ZXag+Vp0lev7wDetSCQblCY=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 03/13] pytest: Add fixture to prepare the tftp server Date: Tue, 22 Sep 2026 12:08:50 +0200 Message-ID: <20260922100900.29129-4-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD Prepare the netboot config, and upload the necessary files. Signed-off-by: Anthony PERARD --- automation/pytest/lib/net_boot.py | 60 +++++++++++++++++++++++++++++++ automation/pytest/pyproject.toml | 2 ++ automation/pytest/test_boot.py | 11 ++++++ 3 files changed, 73 insertions(+) create mode 100644 automation/pytest/lib/net_boot.py diff --git a/automation/pytest/lib/net_boot.py b/automation/pytest/lib/net_boot.py new file mode 100644 index 000000000000..50d2cfaa5aaa --- /dev/null +++ b/automation/pytest/lib/net_boot.py @@ -0,0 +1,60 @@ +import io +import logging +import os +import paramiko +from pathlib import Path +import textwrap + + +class NetBoot: + def grub_script(self) -> str: + http_pxe_path = os.environ['PXE_HTTP_PATH'] + tftp_path = f"(http)/{http_pxe_path}" + console_opts = "console=vga,com1" + + xen_cmdline_opts = [ + console_opts, + "loglvl=all", + "guest_loglvl=all", + "dom0_mem=4G", + "console_timestamps=boot", + "watchdog", + "noreboot", + ] + xen_cmdline = " ".join(xen_cmdline_opts) + linux_cmdline = "console=hvc0 root=/dev/ram0 earlyprintk=xen" + script = textwrap.dedent(f"""\ + echo \"Loading xen\" + multiboot2 {tftp_path}/xen {xen_cmdline} + echo \"Loading vmlinuz\" + module2 {tftp_path}/bzImage {linux_cmdline} + echo \"Loading initrd\" + module2 --nounzip {tftp_path}/pre-dom0-rootfs.cpio.gz + echo \"Booting\" + boot + """) + + return script + + def prepare_tftp(self, xenroot: Path, rootfss: list[Path]) -> None: + username = os.environ['PXE_SSH_USER'] + hostname = os.environ['PXE_HOST'] + remote_path = Path(os.environ['PXE_SSH_PATH']) + + binaries_path = xenroot / "binaries" + binaries = [] + for b1 in ["xen", "bzImage"]: + binaries.append(binaries_path / b1) + binaries += rootfss + + ssh = paramiko.client.SSHClient() + ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) + ssh.connect(hostname, username=username) + with ssh.open_sftp() as sftp: + for b2 in binaries: + logging.debug(f" put {b2}, to {remote_path / b2.name}") + sftp.put(str(b2), str(remote_path / b2.name), confirm=True) + grub_script = io.BytesIO(self.grub_script().encode('utf-8')) + sftp.putfo(grub_script, str(remote_path / "grub.cfg"), + confirm=True) + ssh.close() diff --git a/automation/pytest/pyproject.toml b/automation/pytest/pyproject.toml index 3180b2555029..78f60c4f8e77 100644 --- a/automation/pytest/pyproject.toml +++ b/automation/pytest/pyproject.toml @@ -3,8 +3,10 @@ name = "xen-ci-intree" version = "0.1.0" requires-python = ">=3.14" dependencies = [ + "paramiko>=4.0.0", "pip>=26.0.1", "pytest>=9.0.2", + "types-paramiko>=4.0.0.20260322", ] [dependency-groups] dev = [ diff --git a/automation/pytest/test_boot.py b/automation/pytest/test_boot.py index 230cee96d0ba..661c2a59e4fe 100644 --- a/automation/pytest/test_boot.py +++ b/automation/pytest/test_boot.py @@ -3,6 +3,7 @@ from pathlib import Path import pytest from lib.boot_binary import BootBinary +from lib.net_boot import NetBoot @pytest.fixture @@ -30,3 +31,13 @@ def prepare_rootfs(tmp_path: Path, static_ipv6=os.environ['HOST_IP6'], boot_script=boot_script, ) + + +@pytest.fixture +def prepare_netboot(prepare_rootfs: BootBinary, xenroot_path: Path) -> None: + netboot = NetBoot() + rootfs_paths = [ + prepare_rootfs.minimal(), + prepare_rootfs.dom0_tools(), + ] + netboot.prepare_tftp(xenroot_path, rootfs_paths) -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428470.1651328 (Exim 4.92) (envelope-from ) id 1x8xQz-00071n-72; Tue, 22 Sep 2026 10:09:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428470.1651328; Tue, 22 Sep 2026 10:09:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQz-00071e-4U; Tue, 22 Sep 2026 10:09:09 +0000 Received: by outflank-mailman (input) for mailman id 1428470; Tue, 22 Sep 2026 10:09:07 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQx-0006oL-Ln for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:07 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xQx-00Ao2U-0j; Tue, 22 Sep 2026 10:09:07 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xQx-00DE8C-2R; Tue, 22 Sep 2026 10:09:07 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=EZSW/BF9mMmUonbwLJFPmPKsbgF7MFx2YuFv+VyC5TQ=; b=SzR99WPYlckt9ZceJ+XwhMyLb8 lcFIIs0ULG/7EnPojaqbf/pRVOT83KtjZxhTTIWGg/IKbhq3pCrlcjOSb+CWbq0hTRb4yEYxGwvkj QLHV1dPx7mduE+5CsaMusYwyMVVNeYhChsH42NNBIIdTuchCe2DKoKG5QOntx/vUWrNk=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 04/13] pytest: Add fixture that boot a machine Date: Tue, 22 Sep 2026 12:08:51 +0200 Message-ID: <20260922100900.29129-5-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD .. and power it off once a test using the fixture is done. This IPMI class is using the `ssh` console of an HP Moonshot 1500 Chassis. Signed-off-by: Anthony PERARD --- Maybe we could rename the class to Machine as a lib to control the machine behavior, and access it's console. --- automation/pytest/lib/ipmi.py | 69 ++++++++++++++++++++++++++++++++++ automation/pytest/test_boot.py | 17 +++++++++ 2 files changed, 86 insertions(+) create mode 100644 automation/pytest/lib/ipmi.py diff --git a/automation/pytest/lib/ipmi.py b/automation/pytest/lib/ipmi.py new file mode 100644 index 000000000000..0d3b085f704c --- /dev/null +++ b/automation/pytest/lib/ipmi.py @@ -0,0 +1,69 @@ +import logging +import paramiko +import re + + +class IPMI: + def __init__(self, *, + hostname: str, + username: str, + password: str, + blade_node: str, + ) -> None: + self.hostname = hostname + self.username = username + self.password = password + self.blade_node = blade_node + + self.channel = None + + def _new_client(self): + ssh = paramiko.client.SSHClient() + ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) + ssh.connect(self.hostname, + username=self.username, + password=self.password) + return ssh + + def _run_cmd(self, command: str, debug_print: bool = True) -> str: + with self._new_client() as ssh: + stdin, stdout, stderr = ssh.exec_command(command) + output = stdout.read().decode() + if debug_print: + for line in output.splitlines(): + if line in ['']: + continue + logging.debug(line.rstrip()) + # the command's exit status (0 = success, 1 = failure) + # stdout.channel.recv_exit_status() + return output + + def _power(self, state: str) -> None: + assert state in ["on", "off force"] + logging.info(f"Set power {state.split(' ')[0]} {self.blade_node}") + command = f"set node power {state} {self.blade_node}" + output = self._run_cmd(command, debug_print=False) + m = re.search(f"{self.blade_node}: #Node 1 (.*)\\r$", + output, + flags=re.M) + if m: + logging.info(f"-> {m[1]}") + else: + logging.warning(f"Failed to parse 'set power' command output: '{output}'") + + def power_status(self): + command = f"show node power {self.blade_node}" + output = self._run_cmd(command, debug_print=False) + m = re.search(f"{self.blade_node}: #Node 1\\r\\n\\s+Power State: (\\S+)\\r$", + output, + flags=re.M) + if m: + logging.info(f"Machine is {m[1]}") + else: + logging.warning(f"Failed to match for \"Power State\" in '{output}'") + + def power_on(self): + self._power('on') + + def power_off(self): + self._power('off force') diff --git a/automation/pytest/test_boot.py b/automation/pytest/test_boot.py index 661c2a59e4fe..b7610736fa25 100644 --- a/automation/pytest/test_boot.py +++ b/automation/pytest/test_boot.py @@ -1,9 +1,11 @@ import os from pathlib import Path import pytest +from typing import Generator from lib.boot_binary import BootBinary from lib.net_boot import NetBoot +from lib.ipmi import IPMI @pytest.fixture @@ -41,3 +43,18 @@ def prepare_netboot(prepare_rootfs: BootBinary, xenroot_path: Path) -> None: prepare_rootfs.dom0_tools(), ] netboot.prepare_tftp(xenroot_path, rootfs_paths) + + +@pytest.fixture +def machine_on_ipmi(prepare_netboot: None) -> Generator[IPMI]: + ipmi = IPMI( + hostname=os.environ['IPMI_HOSTNAME'], + username=os.environ['MOON_CONSOLE_USER'], + password=os.environ['MOON_CONSOLE_PASS'], + blade_node=os.environ['IPMI_BLADE_NODE'], + ) + ipmi.power_off() + ipmi.power_status() + ipmi.power_on() + yield ipmi + ipmi.power_off() -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428471.1651337 (Exim 4.92) (envelope-from ) id 1x8xR0-0007EX-DY; Tue, 22 Sep 2026 10:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428471.1651337; Tue, 22 Sep 2026 10:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR0-0007EQ-Am; Tue, 22 Sep 2026 10:09:10 +0000 Received: by outflank-mailman (input) for mailman id 1428471; Tue, 22 Sep 2026 10:09:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xQy-00070A-RU for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xQy-00Ao2h-1A; Tue, 22 Sep 2026 10:09:08 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xQy-00DE8C-2t; Tue, 22 Sep 2026 10:09:08 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=E1LH+34AS/zTBhZzWE2Tec45KIoMgC4W9seEEpRboRo=; b=1cnzPWZ/y+7519jE3Oa6zQtntx ftqwiO5uPq2hggQD2+YgnlQdwIbyt8rzCI62Tfcdc2EOSbMrY6YtjLlDgjiGEmroILcpROhKHV6ew KrkHL3ruS44zvUFx5fUvKWBa/Ok5Cv8byuIM29mR15hhSOg4PHXZ5tHNtoDCQqFm1Kx8=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 05/13] pytest: Introduce reading the console, and add a test Date: Tue, 22 Sep 2026 12:08:52 +0200 Message-ID: <20260922100900.29129-6-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD The test will do more than just checking dom0 booted in a later patch. Signed-off-by: Anthony PERARD --- automation/pytest/lib/ipmi.py | 86 ++++++++++++++++++++++++++++++++ automation/pytest/pyproject.toml | 1 + automation/pytest/test_boot.py | 24 +++++++++ 3 files changed, 111 insertions(+) diff --git a/automation/pytest/lib/ipmi.py b/automation/pytest/lib/ipmi.py index 0d3b085f704c..bda5d8077577 100644 --- a/automation/pytest/lib/ipmi.py +++ b/automation/pytest/lib/ipmi.py @@ -1,6 +1,8 @@ import logging import paramiko import re +import time +from typing import Generator class IPMI: @@ -67,3 +69,87 @@ class IPMI: def power_off(self): self._power('off force') + + def get_console(self): + logging.info(f"Start console acquisition on {self.blade_node}") + ssh = self._new_client() + channel = ssh.invoke_shell() + + output = "" + logging.debug("wait for prompt") + while True: + if channel.recv_ready(): + output += channel.recv(9999).decode('utf-8') + # wait for prompt + logging.debug(output) + if output.strip().endswith('hpiLO->'): + logging.debug("got prompt") + break + elif channel.exit_status_ready(): + raise Exception("Shell closed unexpectedly.") + else: + time.sleep(0.1) # Wait a bit for more output + + logging.debug("run connect node vsp acquire") + cmd = f"connect node vsp acquire {self.blade_node}\n" + channel.send(cmd) + + self.channel = channel + + def console_output_generator(self) -> Generator[str]: + if not self.channel: + raise Exception("Must call get_console") + channel = self.channel + previous_output = '' + # `count` when this reach 0, we had a line from the console that isn't + # finished, like a prompt, for sometime already, so display it in the + # debug. + count = 0 + ansi_escape = re.compile(r''' + \x1B # ESC + (?: # 7-bit C1 Fe (except CSI) + [@-Z\\-_] + | # or [ for CSI, followed by a control sequence + \[ + [0-?]* # Parameter bytes + [ -/]* # Intermediate bytes + [@-~] # Final byte + ) + ''', re.VERBOSE) + while True: + if channel.recv_ready(): + output = previous_output + output += channel.recv(9999).decode('utf-8') + output_lines = output.splitlines(keepends=True) + for line in output_lines[:-1]: + line = ansi_escape.sub('', line) + line = line.rstrip() + if line in ['', '\r', '\r\n']: + continue + logging.debug(line) + yield line + previous_output = output_lines[-1] + if previous_output.endswith('\n'): + line = previous_output + line = ansi_escape.sub('', line) + line = line.rstrip() + if line not in ['', '\r', '\r\n']: + logging.debug(line) + previous_output = '' + count = 0 + else: + count = 20 + # previous_output = output[-len(expect):] + # Check if the shell closed unexpectedly + elif channel.exit_status_ready(): + raise Exception("Shell closed unexpectedly.") + else: + if count > 1: + count -= 1 + elif count == 1: + line = previous_output + line = ansi_escape.sub('', line) + if line not in ['\r']: + logging.debug("XXXXX output buffer: %s XXXXXX" % repr(line)) + count -= 1 + time.sleep(0.5) # Wait a bit for more output diff --git a/automation/pytest/pyproject.toml b/automation/pytest/pyproject.toml index 78f60c4f8e77..4ab7094e0d84 100644 --- a/automation/pytest/pyproject.toml +++ b/automation/pytest/pyproject.toml @@ -6,6 +6,7 @@ dependencies = [ "paramiko>=4.0.0", "pip>=26.0.1", "pytest>=9.0.2", + "pytest-timeout>=2.4.0", "types-paramiko>=4.0.0.20260322", ] [dependency-groups] diff --git a/automation/pytest/test_boot.py b/automation/pytest/test_boot.py index b7610736fa25..158f1a30dcb6 100644 --- a/automation/pytest/test_boot.py +++ b/automation/pytest/test_boot.py @@ -1,3 +1,4 @@ +import logging import os from pathlib import Path import pytest @@ -53,8 +54,31 @@ def machine_on_ipmi(prepare_netboot: None) -> Generator[IPMI]: password=os.environ['MOON_CONSOLE_PASS'], blade_node=os.environ['IPMI_BLADE_NODE'], ) + # start console + ipmi.get_console() ipmi.power_off() ipmi.power_status() ipmi.power_on() yield ipmi ipmi.power_off() + + +@pytest.mark.timeout(600) +def test_xen_tools_tests(machine_on_ipmi: IPMI, + ) -> None: + expect_string = "Dom0 ready" + for line in machine_on_ipmi.console_output_generator(): + # + # Wait for `expect_string` for the test to succeed + # + if expect_string in line: + logging.info(f"got expect_string '{line}'.") + break + # + # Some common expected or not console outputs. + # + if "Latest ChangeSet:" in line: + logging.info(f"Test xen build from '{line}'.") + if "Manual reset required ('noreboot' specified)" in line: + # Test failed, could wait a bit before failing the test. + logging.error("Xen panic") -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428472.1651341 (Exim 4.92) (envelope-from ) id 1x8xR0-0007HF-LB; Tue, 22 Sep 2026 10:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428472.1651341; Tue, 22 Sep 2026 10:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR0-0007H2-HR; Tue, 22 Sep 2026 10:09:10 +0000 Received: by outflank-mailman (input) for mailman id 1428472; Tue, 22 Sep 2026 10:09:10 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR0-0007DN-1Y for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:10 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xQz-00Ao2s-1d; Tue, 22 Sep 2026 10:09:09 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xR0-00DE8C-09; Tue, 22 Sep 2026 10:09:09 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=/T7l5iO1dXbkzvS8G10wVZoy6AS2fih5DyiAKEvAhIQ=; b=Pu86ouqZl6A08svoclKdBsNkO2 +P0nYkh7Ox0AQavyyAE8PeEIadRCPrQNH41ihaK0yqpn44PKbgcnfJIBgQIc2gKSGBQQ/K01zY78g tgl09v+hEuPOgA1Cz6i1Nun3rrng1ZEsFa+zVtDcYlm8C+urc2iRP7Mv0aTbcCM36Kqc=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 06/13] We need an older version of paramiko. Date: Tue, 22 Sep 2026 12:08:53 +0200 Message-ID: <20260922100900.29129-7-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD To connect to the moonshot controller over ssh. Signed-off-by: Anthony PERARD --- automation/pytest/pyproject.toml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/automation/pytest/pyproject.toml b/automation/pytest/pyproject.toml index 4ab7094e0d84..c54c1338f656 100644 --- a/automation/pytest/pyproject.toml +++ b/automation/pytest/pyproject.toml @@ -3,7 +3,8 @@ name = "xen-ci-intree" version = "0.1.0" requires-python = ">=3.14" dependencies = [ - "paramiko>=4.0.0", + # Need paramiko with support for SHA-1 key exchange + "paramiko<5.0.0", "pip>=26.0.1", "pytest>=9.0.2", "pytest-timeout>=2.4.0", -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428473.1651356 (Exim 4.92) (envelope-from ) id 1x8xR1-0007e3-SH; Tue, 22 Sep 2026 10:09:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428473.1651356; Tue, 22 Sep 2026 10:09:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR1-0007dw-PJ; Tue, 22 Sep 2026 10:09:11 +0000 Received: by outflank-mailman (input) for mailman id 1428473; Tue, 22 Sep 2026 10:09:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR1-0007TP-2T for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:11 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xR0-00Ao33-25; Tue, 22 Sep 2026 10:09:10 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xR1-00DE8C-0c; Tue, 22 Sep 2026 10:09:10 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=xsrfE5ntOSeufRj3RlZPqsn9RM3+8iFSAAGbkUyL2x4=; b=F918OzmvRXBlx+JnVvgeFWjMcA yR9nA6x4lQJgt2XxFbxsDy9e920oXWwmXgiYmEWpWGwbr8Y0MfYyL37WTYPrVNfVDSE3S//hEz9RL gi6kqsjyaZIPdMPbhAQF2ghv37Ee29nggdHv3WCWe2FuEzXz3RoJyHcLs/bTq92dqaek=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 07/13] pytest: Add random string to look for in the logs Date: Tue, 22 Sep 2026 12:08:54 +0200 Message-ID: <20260922100900.29129-8-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD This allow to check that we are testing the expected rootfs. Signed-off-by: Anthony PERARD --- automation/pytest/test_boot.py | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/automation/pytest/test_boot.py b/automation/pytest/test_boot.py index 158f1a30dcb6..90d8e00e90d9 100644 --- a/automation/pytest/test_boot.py +++ b/automation/pytest/test_boot.py @@ -2,6 +2,8 @@ import logging import os from pathlib import Path import pytest +import random +import string from typing import Generator from lib.boot_binary import BootBinary @@ -14,14 +16,20 @@ def xenroot_path() -> Path: return Path("../..").resolve() +@pytest.fixture +def boot_string() -> str: + return ''.join(random.choice(string.ascii_letters) for _ in range(16)) + + @pytest.fixture def prepare_rootfs(tmp_path: Path, xenroot_path: Path, + boot_string: str, ) -> BootBinary: static_gateway = os.environ['HOST_IP_GATEWAY'] http_pxe_path = os.environ["PXE_HTTP_PATH"] - boot_script = f"echo Dom0 ready\n" + boot_script = f"echo Dom0 ready {boot_string}\n" return BootBinary(tmp_path, xenroot_path, @@ -65,8 +73,9 @@ def machine_on_ipmi(prepare_netboot: None) -> Generator[IPMI]: @pytest.mark.timeout(600) def test_xen_tools_tests(machine_on_ipmi: IPMI, + boot_string: str, ) -> None: - expect_string = "Dom0 ready" + expect_string = boot_string for line in machine_on_ipmi.console_output_generator(): # # Wait for `expect_string` for the test to succeed -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428474.1651366 (Exim 4.92) (envelope-from ) id 1x8xR4-0007v1-CY; Tue, 22 Sep 2026 10:09:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428474.1651366; Tue, 22 Sep 2026 10:09:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR4-0007um-6m; Tue, 22 Sep 2026 10:09:14 +0000 Received: by outflank-mailman (input) for mailman id 1428474; Tue, 22 Sep 2026 10:09:12 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR2-0007kM-9U for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:12 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xR1-00Ao3C-2Y; Tue, 22 Sep 2026 10:09:12 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xR2-00DE8C-14; Tue, 22 Sep 2026 10:09:12 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=Hwc7/siulS2GTqhirLoPBndfzFNCWOOcNc5vmaXH1ZA=; b=2mE9f1d1Mlu7p1vVgKuzljZlyP DLxEvE+cnn2NRyKZm2pU7aalSuWQEuHOS013o0PFUuFg/9L1qZEmX87FbCQnvC7OUEXg6dSJDwqiL O2L4AAE0N7MO8ShiIrh4QRq29EHkFNA7qUOZnu97g4J8e7Y6IWF+AyJ2WQt5RqKY3bJs=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 08/13] pytest: Run run-tools-tests over ssh on the test machine Date: Tue, 22 Sep 2026 12:08:55 +0200 Message-ID: <20260922100900.29129-9-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD Add a new random ssh public key to the rootfs. Signed-off-by: Anthony PERARD --- automation/pytest/lib/boot_binary.py | 7 +++++ automation/pytest/test_boot.py | 39 ++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) diff --git a/automation/pytest/lib/boot_binary.py b/automation/pytest/lib/boot_binary.py index d8f503ead9f2..1910d1f88fe6 100644 --- a/automation/pytest/lib/boot_binary.py +++ b/automation/pytest/lib/boot_binary.py @@ -23,6 +23,7 @@ class BootBinary: def __init__(self, tmp_path: Path, xenroot: Path, pxe_host: str, http_pxe_path: str, + ssh_pub_keys: str | None = None, vlan_id: int | None = None, static_ip: str | None = None, static_gateway: str | None = None, @@ -37,6 +38,7 @@ class BootBinary: self.static_gateway = static_gateway self.static_dns = static_dns self.static_ipv6 = static_ipv6 + self.ssh_pub_keys = ssh_pub_keys self.boot_script = boot_script # Minimal rootfs @@ -126,6 +128,11 @@ class BootBinary: runlevel_boot_d.mkdir(parents=True) (runlevel_boot_d / "networking").symlink_to("/etc/init.d/networking") + if self.ssh_pub_keys: + home_root_ssh = rootfs_path / "root/.ssh" + home_root_ssh.mkdir(parents=True) + (home_root_ssh / "authorized_keys").write_text(self.ssh_pub_keys) + local_d_dir = rootfs_path / "etc/local.d" local_d_dir.mkdir(parents=True) diff --git a/automation/pytest/test_boot.py b/automation/pytest/test_boot.py index 90d8e00e90d9..039cc36c1a04 100644 --- a/automation/pytest/test_boot.py +++ b/automation/pytest/test_boot.py @@ -1,5 +1,6 @@ import logging import os +import paramiko from pathlib import Path import pytest import random @@ -16,6 +17,11 @@ def xenroot_path() -> Path: return Path("../..").resolve() +@pytest.fixture +def sshkey_for_test() -> paramiko.pkey.PKey: + return paramiko.ecdsakey.ECDSAKey.generate() + + @pytest.fixture def boot_string() -> str: return ''.join(random.choice(string.ascii_letters) for _ in range(16)) @@ -24,6 +30,7 @@ def boot_string() -> str: @pytest.fixture def prepare_rootfs(tmp_path: Path, xenroot_path: Path, + sshkey_for_test: paramiko.pkey.PKey, boot_string: str, ) -> BootBinary: static_gateway = os.environ['HOST_IP_GATEWAY'] @@ -31,6 +38,9 @@ def prepare_rootfs(tmp_path: Path, boot_script = f"echo Dom0 ready {boot_string}\n" + ssh_pub_keys = os.environ['SSH_PUB_KEYS'] + ssh_pub_keys += f"\n{sshkey_for_test.get_name()} {sshkey_for_test.get_base64()}\n" + return BootBinary(tmp_path, xenroot_path, vlan_id=int(os.environ['HOST_IP_VLANID']), @@ -40,6 +50,7 @@ def prepare_rootfs(tmp_path: Path, static_gateway=static_gateway, static_dns=static_gateway, static_ipv6=os.environ['HOST_IP6'], + ssh_pub_keys=ssh_pub_keys, boot_script=boot_script, ) @@ -73,6 +84,7 @@ def machine_on_ipmi(prepare_netboot: None) -> Generator[IPMI]: @pytest.mark.timeout(600) def test_xen_tools_tests(machine_on_ipmi: IPMI, + sshkey_for_test: paramiko.pkey.PKey, boot_string: str, ) -> None: expect_string = boot_string @@ -91,3 +103,30 @@ def test_xen_tools_tests(machine_on_ipmi: IPMI, if "Manual reset required ('noreboot' specified)" in line: # Test failed, could wait a bit before failing the test. logging.error("Xen panic") + ssh = paramiko.client.SSHClient() + ssh.set_missing_host_key_policy(paramiko.client.WarningPolicy) + logging.debug(f"connecting to {os.environ['HOST_IP4'].split('/')[0]}") + ssh.connect(os.environ['HOST_IP4'].split('/')[0], + username='root', + pkey=sshkey_for_test, + timeout=10, + ) + + cmd = '/root/run-tools-tests /usr/lib/xen/tests /tmp/tests-junit.xml' + logging.info(f"Exec command: {cmd}") + stdin, stdout, stderr = ssh.exec_command(cmd) + for output in stdout: + logging.debug(output.strip()) + errormsg = stderr.read() + if errormsg: + logging.info(f"cmd errro: {errormsg!r}") + exit_status = stderr.channel.recv_exit_status() + logging.debug(f"exit status: {exit_status}") + + cmd = 'cat /tmp/tests-junit.xml' + stdin, stdout, stderr = ssh.exec_command(cmd) + junit = stdout.read() + logging.debug(f"got junit result: {junit!r}") + errormsg = stderr.read() + if errormsg: + logging.info(f"cmd errro: {errormsg!r}") -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:09:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:09:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428475.1651374 (Exim 4.92) (envelope-from ) id 1x8xR5-0008B0-MA; Tue, 22 Sep 2026 10:09:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428475.1651374; Tue, 22 Sep 2026 10:09:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR5-00089o-FX; Tue, 22 Sep 2026 10:09:15 +0000 Received: by outflank-mailman (input) for mailman id 1428475; Tue, 22 Sep 2026 10:09:13 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xR3-0007sy-CU for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:09:13 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xR2-00Ao3M-31; Tue, 22 Sep 2026 10:09:13 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xR3-00DE8C-1X; Tue, 22 Sep 2026 10:09:13 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=zGpGZ+j9aQiCtnJa+6UJN2jNBGnn8uaTwN1dX0fpCgY=; b=olxkbERncTc4JTc6v5Lmha2s6K 58/t/1bjdVShM6LmKhCmxliYHydgfN5UcDzLBEtwiqg3Qo9HUZN90OmqC0gSlkBClbyFWLcnHm22s kuOyjnheTRuRzMQ1+FGGXrYxTz8mOiKGL6+pfgXqYwC2hLiNpLtJ3Z/+CqPH8039087c=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 09/13] pytest: Generate a rootfs for a guest Date: Tue, 22 Sep 2026 12:08:56 +0200 Message-ID: <20260922100900.29129-10-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD Signed-off-by: Anthony PERARD --- automation/pytest/conftest.py | 6 ++++ automation/pytest/lib/boot_binary.py | 42 ++++++++++++++++++++++++++++ automation/pytest/test_boot.py | 8 ++++++ 3 files changed, 56 insertions(+) create mode 100644 automation/pytest/conftest.py diff --git a/automation/pytest/conftest.py b/automation/pytest/conftest.py new file mode 100644 index 000000000000..304241ae06ba --- /dev/null +++ b/automation/pytest/conftest.py @@ -0,0 +1,6 @@ +import pytest + + +def pytest_configure(config: pytest.Config) -> None: + config.addinivalue_line("markers", + "guest_boot_script: script to run when the guest boot") diff --git a/automation/pytest/lib/boot_binary.py b/automation/pytest/lib/boot_binary.py index 1910d1f88fe6..9e79b1798908 100644 --- a/automation/pytest/lib/boot_binary.py +++ b/automation/pytest/lib/boot_binary.py @@ -30,6 +30,7 @@ class BootBinary: static_dns: str | None = None, static_ipv6: str | None = None, boot_script: str | None = None, + guest_boot_script: str | None = None, ) -> None: self.vlan_id = vlan_id self.pxe_host = pxe_host @@ -40,6 +41,7 @@ class BootBinary: self.static_ipv6 = static_ipv6 self.ssh_pub_keys = ssh_pub_keys self.boot_script = boot_script + self.guest_boot_script = guest_boot_script # Minimal rootfs rootfs_path = tmp_path / "rootfs_minimal" @@ -53,6 +55,12 @@ class BootBinary: self.prepare_dom0_rootfs(rootfs_path, xenroot) self.rootfs_dom0_dir = rootfs_path + # Guest kernel + rootfs + rootfs_path = tmp_path / "rootfs_domU" + rootfs_path.mkdir() + self.prepare_guest_rootfs(rootfs_path, xenroot) + self.rootfs_guest_dir = rootfs_path + def prepare_minimal_rootfs(self, rootfs_path: Path, xenroot: Path) -> None: script_pre_xen = dedent(f"""\ @@ -212,8 +220,42 @@ class BootBinary: self.xen_tools_rootfs = cpio_rootfs + def prepare_guest_rootfs(self, rootfs_path: Path, xenroot: Path) -> None: + etc = rootfs_path / "etc" + etc.mkdir() + + local_d_dir = etc / "local.d" + local_d_dir.mkdir() + + xen_start_script = local_d_dir / "xen.start" + xen_start_script.write_text(dedent(f"""\ + #!/bin/sh + echo 8 > /proc/sys/kernel/printk + {self.guest_boot_script} + """)) + xen_start_script.chmod(stat.S_IRUSR | stat.S_IWUSR | stat.S_IXUSR) + + (etc / "issue").write_text(dedent("""\ + domU Welcome to Alpine Linux + Kernel \\r on an \\m (\\l) + + """)) + + # rootfs archive + rootfs = [] + # Uncompressed first! Then compressed cpio archives! + rootfs.append(xenroot / "binaries/rootfs.cpio.gz") + cpio_rootfs = xenroot / "binaries/guest-rootfs.cpio.gz" + concatenate_cpios(rootfs, cpio_rootfs) + cpio_archive_from_dir(rootfs_path, cpio_rootfs) + + self.guest_rootfs = cpio_rootfs + def minimal(self) -> Path: return self.minimal_rootfs def dom0_tools(self) -> Path: return self.xen_tools_rootfs + + def guest(self) -> Path: + return self.guest_rootfs diff --git a/automation/pytest/test_boot.py b/automation/pytest/test_boot.py index 039cc36c1a04..5a7ec43fa52b 100644 --- a/automation/pytest/test_boot.py +++ b/automation/pytest/test_boot.py @@ -32,11 +32,17 @@ def prepare_rootfs(tmp_path: Path, xenroot_path: Path, sshkey_for_test: paramiko.pkey.PKey, boot_string: str, + request: pytest.FixtureRequest ) -> BootBinary: static_gateway = os.environ['HOST_IP_GATEWAY'] http_pxe_path = os.environ["PXE_HTTP_PATH"] boot_script = f"echo Dom0 ready {boot_string}\n" + marker = request.node.get_closest_marker("guest_boot_script") + if marker: + guest_boot_script = marker.args[0] + else: + guest_boot_script = None ssh_pub_keys = os.environ['SSH_PUB_KEYS'] ssh_pub_keys += f"\n{sshkey_for_test.get_name()} {sshkey_for_test.get_base64()}\n" @@ -52,6 +58,7 @@ def prepare_rootfs(tmp_path: Path, static_ipv6=os.environ['HOST_IP6'], ssh_pub_keys=ssh_pub_keys, boot_script=boot_script, + guest_boot_script=guest_boot_script, ) @@ -61,6 +68,7 @@ def prepare_netboot(prepare_rootfs: BootBinary, xenroot_path: Path) -> None: rootfs_paths = [ prepare_rootfs.minimal(), prepare_rootfs.dom0_tools(), + prepare_rootfs.guest(), ] netboot.prepare_tftp(xenroot_path, rootfs_paths) -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:20:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:20:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428539.1651382 (Exim 4.92) (envelope-from ) id 1x8xc4-0005DV-JV; Tue, 22 Sep 2026 10:20:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428539.1651382; Tue, 22 Sep 2026 10:20:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xc4-0005DO-Gs; Tue, 22 Sep 2026 10:20:36 +0000 Received: by outflank-mailman (input) for mailman id 1428539; Tue, 22 Sep 2026 10:20:36 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xc3-0005DC-SF for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:20:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8xc3-005Iqa-0v for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:20:35 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab25663-bab6-0a2a0a5309dd-0a2a45058ee6-36 for ; Tue, 22 Sep 2026 12:20:34 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab25672-4cb1-0a2a45050019-4a7de14ce11a-3 for ; Tue, 22 Sep 2026 12:20:34 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f62ccdb1so1366285f8f.1 for ; Tue, 22 Sep 2026 03:20:34 -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 ffacd0b85a97d-4886277e84dsm4193133f8f.20.2026.09.22.03.20.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 03:20:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790072434; x=1790677234; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=NUy6/cLFyqdO0dmZ/aIVtzBYW0tV/zVebq7X+jymWdA=; b=ZzLSNKu1nVuEpyVx3j+ueEEET3KOvmN/ZS0dgwlxFudCppiiHZJpNZaNb3gtseM40O 9C6qAJYUdY9AkbCVm6s1cyHXg0G8stCE9aa0vL89iIusVms5cYcZdpARPwH0wa6X+Wf0 eZj65wAwvhR/8tlvOJuPuLzOTCSj48RUj7EBKtum47ktFnWFk0Un12JIoJApQbDxcRE0 U8jUCpPqjOJP/Cv7aKqMDMGvO7ogTzg5nZhIFgM+aWGW++tzPy1weWoj1cGEsMObdg93 /mGobx1PaDOF/PxilYVpwQleuEwIElbAtEin3s/0p7QtD90bjmsra3fQGqmyZyyhYId9 Qqow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790072434; x=1790677234; h=content-transfer-encoding:content-type: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:content-type; bh=NUy6/cLFyqdO0dmZ/aIVtzBYW0tV/zVebq7X+jymWdA=; b=xP5PaUE3+Ta23HMwJGamm98zi2UgTxCT0m8x9IlYARkWkKDCQlFRF7IZHHvJbtkebN nN88U06fyB+XH59GimZ1/Fdxpc2iW5/O0e8ZNdecaquprGVHEsMv3/dtqIbOAJRsNcsU jiICpW48iOWJi5V6YKZntsXg6b1nH265xOflkLhb5DJ8hFJc8iQjxyrn0ySFsNLITeA3 dKAa15phGAoLL7J1WjjDPa2i+Rk77vRsvp9uXhv1u5vEIFGcNiWwpt9Yd1WuAssXZMRQ AQdiyDJiZAAwkcon6Wx7Yv8/Hc17RzpO0khJ8ci3rrSgydf/DGkoWeWH/lQU/6syF03t w9EQ== X-Forwarded-Encrypted: i=1; AKwUvBwwyBb9GtUvbReSx1KiNkP+OqnU8FJvSnjcV+/DXyknRvXdNfl/7AhpK6lP+N7wiS7zVYcpTlL7mx8=@lists.xenproject.org X-Gm-Message-State: AFuF++k4LC8yDGjzBJn/uH5U+NxwBnfpSBSCITvioNHXNFPZq5mFweRk FuZevvRuJXNQS15HyBgxsHoCEX29SnSeuC++aiuq8eTuCpFnuDN/dS3EcUuF+g96sA== X-Gm-Gg: AYBFou0F3VOObBW8H9RqmVle8HzpsZm7UaiXVdtIn2hyoLOg/iOOknAT4NZ7qDbvEPG wyMbozlXUYPT7cjTL/oLVM3fAQOusNJjUCn85D6yTom35RDJ77NqBBqO2KH3LeDgVjtczjHhDCL MziQhZOLaOx6tfCcuztUvMTqEElwuMo4o0gb0EkSkcpmxJBTUWwEc3Hj5oKDrQdgsATcnaSFWt/ rkuepK5sdAkTeFz2u6tsiYBT4hAdCi9KQ75D+buaL0EUKcXC7gqHwp2dMDqQ43Ttlp0b5/MIxby 5MFtA7qZG6wbEF5OV+TqGuWcQBrtipcmXw807U9JZsZIAV3cDNaLIW3Lm9nVZDlp5PNbDMRZM8r +OeTZgtmk0fd3praf/jlhBfQopdmMKoUjx379YmBfzjfr3C4mkXCxUmJxOFxshjUE7TByCyl3kI s16E8RIRQO/HVdBs3zG2cDqhlFie2N8a6zOl5PC8+Sd1LMaGF9QxUEojOWdg/iV8aV29aAqJj1T rsE+/gBIpG9Qep8re1KOMDkM8pCSdoVBO+opPqu/3FLRnk/nE0uP9xgjWHNyg== X-Received: by 2002:a05:6000:4b1b:b0:487:13a9:80d with SMTP id ffacd0b85a97d-48860ff7d35mr3914753f8f.10.1790072434238; Tue, 22 Sep 2026 03:20:34 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 12:20:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu() To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8dbc4ba6-bf92-4e9f-b4b6-7286d5a96443@suse.com> <96f66feb-8889-4475-b39f-ed52b1f58a68@gmail.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: <96f66feb-8889-4475-b39f-ed52b1f58a68@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790072434-F7CB82A1-C6CCF03B/0/0 X-purgate-type: clean X-purgate-size: 6538 On 22.09.2026 10:23, Oleksii Kurochko wrote: > On 9/21/26 2:12 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> continue_new_vcpu() is the arch hook invoked the first time a freshly >>> created vCPU is scheduled. Implement both cases it has to cover: >>> - for the idle vCPU, switch to its own stack and jump to idle_loop(); >>> - for a guest vCPU, restore hstatus and enter the guest through the new >>> return_to_new_vcpu() path in entry.S, which loads sepc, passes the >>> hart id in a0 and the DTB address in a1 as expected by the RISC-V >>> boot protocol, sets sstatus.SPP and executes sret. >> >> Is this a requirement for all CPUs, or just for the boot one? (I can't >> quite see why secondary processors would need passing a DTB address.) > > It is requirement for boot one. For secondary processors it is HSM boot > data which is passed to sbi_hsm_hart_start() and then intercpeted by Xen. > > At the moment of writing of this commit message we have only boot CPU > and so only DTB could be passed. That you're talking about Xen. Despite Xen being UP only right now, guests still can have more than one vCPU, can't they? > I can update the commit message and the comment in return_to_new_vcpu() > to tell that it could be DTB address for boot cpu and/or for secondary > CPUs HSM boot data or it will be better to add info about HSM boot data > during and an introduction of secondary CPUs support? As per above you want to deal with multi-vCPU guests right now. >>> Interrupts have to stay disabled across the restore. The trap entry >>> logic implicitly clears hstatus.SPV, so an interrupt taken between the >>> write of hstatus and sret would make sret return to HS-mode instead of >>> VS-mode, and restoring SPV afterwards is non-trivial. Instead interrupts >>> are simply kept off and sstatus.SPIE is set, so that SIE is restored from >>> SPIE once sret has been executed. >> >> As written this reads as if the guest would be responsible for doing this. >> Isn't it rather SRET itself which does this? > > IIUC to which part you refer then yes, it is SRET itself which does > this. So some re-wording should be done ... > >> >>> Also, it follows what hardware will do >>> with real CPU which is also started with interrupts disabled. >> >> Further up, aiui, you talk about the host's interrupt state. How vCPU-s >> are started, however, is virtual interrupt state. Mixing both isn't >> very helpful. > > ...: > > Interrupts have to stay disabled across the restore. The trap entry > logic implicitly clears hstatus.SPV, so an interrupt taken between the > write of hstatus and sret would make sret return to HS-mode instead of > VS-mode, and restoring SPV afterwards is non-trivial. Hence interrupts > are kept disabled, and sstatus.SPIE is set so that sret itself > re-enables them (SIE := SPIE) as part of entering the guest. > > Then it will be also need to update the comment inside > continue_new_vcpu() to: > > - * To avoid this, interrupts are kept disabled during the restore. > - * Additionally, setting sstatus.SPIE=1 ensures that after sret is > - * executed (as sstatus.SIE will be loaded from SPIE), HS-mode will > - * continue to receive interrupts normally. > + * To avoid this, interrupts are kept disabled during the restore, > + * and sstatus.SPIE is set so that sret itself re-enables them > + * (SIE := SPIE) as part of entering the guest. > */ > > Would it be the wording okay for you now? I think so, yes. >>> --- a/xen/arch/riscv/entry.S >>> +++ b/xen/arch/riscv/entry.S >>> @@ -143,3 +143,26 @@ FUNC(__context_switch) >>> >>> ret >>> END(__context_switch) >>> + >>> +/* t0 is used as a temporary reg and is clobbered to oblivion */ >>> +FUNC(return_to_new_vcpu) >>> + /* Swap tp with sscratch */ >>> + csrrw tp, CSR_SSCRATCH, tp >> >> What is this about? I'm not aware of any counterpart code, yet all on its >> own this I can't see it being overly useful. > > It will be needed later when a guest will be able to launch to > distinguish in handle_trap() [1] if a trap is from guest or not. I can > drop it for now and re-introduce it with the code of handle_trap() or as > an option I could update the comment above to: > > /* > * SSCRATCH holds this hart's struct pcpu_info while a guest > runs and > * is zero while Xen runs, so that a trap handler can tell the two > * apart: tp is Xen's pointer to pcpu_info in Xen context, but > belongs > * to the guest once sret has been executed. Establish that by > swapping > * the two here; the trap path swaps them back. > */ > csrrw tp, CSR_SSCRATCH, tp > > (but then the last part will point to the part which isn't yet > introduced so probably it will be better to drop this line for now) Yes, introducing it together with the other related pieces is going to be more consistent and easier to follow. >>> + /* Set guest mode to supervisor */ >>> + li t0, SSTATUS_SPP >>> + csrs CSR_SSTATUS, t0 >>> + >>> + /* Enter guest */ >>> + sret >>> +END(return_to_new_vcpu) >> >> Aiui SRET does not switch stacks. Shouldn't you therefore clear sp here? >> And perhaps also other GPRs, not the least ra? Exposing hypervisor >> register values to guests is, well, a bit of a problem. > > Good point, sret leaves all GPRs as they are, so the guest would indeed > see Xen's sp, ra and friends. Only a0 and a1 are architecturally > meaningful for a booting hart, so I'll clear every other GPR right > before sret. > > I will add the following before sret: > > /* > * sret doesn't switch stacks and leaves the GPRs alone, so every > * register which isn't meaningful to the vCPU being started > has to be > * cleared here: otherwise the guest would see Xen's values, sp > (this > * vCPU's Xen stack) and ra among them. > */ > .irp reg, ra, sp, gp, tp, t0, t1, t2, s0, s1, a2, a3, a4, a5, > a6, a7, \ > s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, t3, t4, t5, t6 > mv \reg, zero > .endr At which point discussing the clobbering of t0 in the comment ahead of the function also isn't needed anymore. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:23:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:23:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428546.1651392 (Exim 4.92) (envelope-from ) id 1x8xf5-0005pT-1N; Tue, 22 Sep 2026 10:23:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428546.1651392; Tue, 22 Sep 2026 10:23:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xf4-0005pM-Ug; Tue, 22 Sep 2026 10:23:42 +0000 Received: by outflank-mailman (input) for mailman id 1428546; Tue, 22 Sep 2026 10:23:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xf3-0005pC-B5 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:23:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8xf2-002UxR-OA for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:23:40 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab25707-8faa-0a2a0a5109dd-0a2a4504d678-44 for ; Tue, 22 Sep 2026 12:23:40 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2572c-b57f-0a2a45040019-4a7de18db5d8-3 for ; Tue, 22 Sep 2026 12:23:40 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b91369d18so29647325e9.0 for ; Tue, 22 Sep 2026 03:23:40 -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-49fdab0c240sm28222615e9.4.2026.09.22.03.23.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 03:23:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790072620; x=1790677420; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=t0xXwVHC5NMTpwFI6XhDRiCyEmcfc9jvURgZBwlMrag=; b=VSTfAXB2vwZzdS22Bw9IikIF2+IM2uYRDLXpgz1JWa8CHrOKSbIQvPmElpgfRJQulT iVqtvHpbHarLVjRI4djDp9MCN4TYNMgyXZJpG/x/9SspRNWPxxmRdcHg07qilVOe9SxC D0KSkOUxMmWnjjGVW5/RNLioBqW7Wb20erj5NA8uSixJW3+ZE6Qs69mZ5fhFA7XnacqE bmBmJPlPCoQcrXWqhoKECKTfk0v2hu6oa/WmkN/iXcBwPnqtSZZf/hhgj7TT7jaDgrTk b8St0PYIj9osisiAkPFcPX33g07G2hHtORTKxSg1p3d/Vcxm6WiuPoJhC9UkpKbDF1Of 9bjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790072620; x=1790677420; h=content-transfer-encoding:content-type: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:content-type; bh=t0xXwVHC5NMTpwFI6XhDRiCyEmcfc9jvURgZBwlMrag=; b=1qv2IIm6R8kP5IZ8s9G1h3HsOcLQ0XzbJjhYmMqpGHaprR4kFu37hgJcovVzqmgKrF 5eMIzdrbi0lF9DTyji0NwGfpdNpgyOYp+So2xNmS3tAvA/9WxPbYXe7znBKzbY70naF+ 6km05b+tUEHf98b4WQ2VpxQLoXcZ0aBjmvWhBhuWGwS4gn9O1MNdJgTTOuIQRbnpjPZ5 d//HbVxJkeExfp9kJBbx/QHCT90Q43IHEsEpXe2GYh9wU4je2wb694Sn/OI48v+xqeRm ClqaUOXnc5JisgtA4gQPFq0ot0a9VspLMblQRdLYmYGBLey8aq4fx7TGlmEqg+zieQoX c/Ew== X-Forwarded-Encrypted: i=1; AKwUvBz/1UPqrMhCgqkoOCkIJGEnImgr6NmhzQfAhwVLXo8JdGhQk9oGn/sBlcPTWweE849DIIdO6tkRdGE=@lists.xenproject.org X-Gm-Message-State: AFuF++lbQe5p6AwpjcZRbDUlE4RJF2T+rV1F3AHyV+1R7v9B3moQRpnT KBrjNDVlqPZ8gPgO6D3eEHXyQahtYytwdxvggeqxpzxMgKHYTz8OskphG8vWh3m8bw== X-Gm-Gg: AYBFou0OIKRqS4o9rBfHRTt5SGyAS4hK6iacuRR+BUrdflFCKc/RrAw8SXelLDp7Ac9 8PTE1R/5mCkvl/lnK8csIqAAI4kHnU+o3L5RMdtYQ9OvC0Ek4kjsCh4q5eHoU5AbnKxjzQn22Zh yGf+gzJFRVnS2tuU1dMLLh7mOVdaUqWLotZWq5LrwhHpov77z4k4+KFwl+Nt59fFrZXJ2ToTixe n1GTE2OXDVRg4kbAWgsOJxmjcfRPmZD6Pxn4yXVOyb9zZdg+NQZULMMyZREgPAVI0YexoJ/EExq 5PvTZIW8Q6WNgSJKZgRxj/iQeGdFfOTq+mcTqPkQnebt8AOREkVui2AV+nNlbGYx55HCWWwxR2k NKQ0Vy/Hd7OFM9EVFEr/VLeJhL02EnEvERWGijUBQtDgFj46zxv0Magh2HimqvmXMScBFAM48wN y3FPxPSPSAemZk04WA9luX1zf94+ylOsSsis/Au7zJ5yovSGr5Rbq7fxqp6AfKpN8biFXi9Gsx7 myovjq80taM8Vb/PeehIzvY+F6vzxD2GR6UBpX0DUDE0PU7QsWM4yIaCQh1lVA= X-Received: by 2002:a05:600c:310d:b0:49d:15b9:2a2a with SMTP id 5b1f17b1804b1-49fc5721b9dmr203393485e9.10.1790072620072; Tue, 22 Sep 2026 03:23:40 -0700 (PDT) Message-ID: <8a809ae3-4e30-4287-b43f-cdc3a6f434d4@suse.com> Date: Tue, 22 Sep 2026 12:23:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 39/39] xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu To: Oleksii Kurochko Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4df9cf63943d0f371c8a25c6c9e84adbd3083a61.1787838835.git.oleksii.kurochko@gmail.com> <1b7b29da-bc22-4fff-8e1a-92cedcd0cf22@gmail.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: <1b7b29da-bc22-4fff-8e1a-92cedcd0cf22@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1790072620-C38C1B50-76ECEB2C/0/0 X-purgate-type: clean X-purgate-size: 1536 On 22.09.2026 10:31, Oleksii Kurochko wrote: > On 9/21/26 2:32 PM, Jan Beulich wrote: >> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>> Introduce imsic_vsfile_attach() to initialize the AIA-related state needed >>> for a vCPU to have a working guest interrupt file. >>> >>> A guest (VS) interrupt file must be mapped to one of a pCPU's >>> hardware interrupt files (if they exist), so the pCPU a vCPU will actually >>> run on needs to be known first. arch_vcpu_create() is therefore not a >>> suitable place to call vcpu_aia_init(), since the pCPU assigned to a >>> vCPU can still change before it is first scheduled. To avoid >>> reassigning the VS interrupt file id and remapping it to a different >>> pCPU's hardware interrupt file, imsic_vsfile_attach() is called from a >>> later point in the scheduling path (e.g. continue_new_vcpu()). >> >> Hmm, why does first-time handling need to be this different from the >> handling of a vCPU moving across pCPU-s? The sole difference should be >> "no state to load" vs "load state that was saved on the old pCPU". > > Generally I think it could be the same but not all the steps done in > migration functions aren't needed for new vCPU (despite of the fact they > aren't harmful). For new vCPU it seems to me it is enough only to attach > h/w interrupt file to vCPU. Sure, yet still imo you want to aim at re-using as much code as possible, especially when otherwise you introduce multiple very similar but not exactly identical variants of logic. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:29:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:29:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428556.1651407 (Exim 4.92) (envelope-from ) id 1x8xkP-0006q2-WC; Tue, 22 Sep 2026 10:29:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428556.1651407; Tue, 22 Sep 2026 10:29:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xkP-0006ps-Pb; Tue, 22 Sep 2026 10:29:13 +0000 Received: by outflank-mailman (input) for mailman id 1428556; Tue, 22 Sep 2026 10:29:12 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xkO-0006mx-8k for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:29:12 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xkN-00ApBn-1O; Tue, 22 Sep 2026 10:29:11 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xR4-00DE8C-1z; Tue, 22 Sep 2026 10:09:14 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=0EYmk0NJ/kvSiclNpr9gVl0wT7a9lZ6KKLAdNMnZn+8=; b=0g8vDDC72M9fifW5/z5jWwZDDe n7hUPd2gGJRzFSwarkZyHVAjqpw/lGDU4inJjDrKWlEuGraLJsx2x6d8a077cvulNZaZr7ch29yjc twCdNBUMctcABymJi4huRQ8kK3urMKHgpHa+3CLoEg8ojQ146KhHUegJ/1sXNuXdT5z4=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 10/13] pytest: Add guest test Date: Tue, 22 Sep 2026 12:08:57 +0200 Message-ID: <20260922100900.29129-11-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD Adding a second test, to help show how to improve the fixtures, and needed code in libraries That test copies part of the run tools-test tests, but we could shared that better. Then, we ssh to the host, to both follow the guest log files and to prepare and start the guest, over several SSH channel. tail_log() could go into a lib. And I don't know yet what to do with the collected threads object. I also want to get rid of the guest_boot_script marker, and ssh to the guest instead. Signed-off-by: Anthony PERARD --- automation/pytest/test_boot.py | 97 ++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) diff --git a/automation/pytest/test_boot.py b/automation/pytest/test_boot.py index 5a7ec43fa52b..089aa1e6c063 100644 --- a/automation/pytest/test_boot.py +++ b/automation/pytest/test_boot.py @@ -3,8 +3,11 @@ import os import paramiko from pathlib import Path import pytest +from queue import Queue import random import string +from textwrap import dedent +from threading import Thread from typing import Generator from lib.boot_binary import BootBinary @@ -138,3 +141,97 @@ def test_xen_tools_tests(machine_on_ipmi: IPMI, errormsg = stderr.read() if errormsg: logging.info(f"cmd errro: {errormsg!r}") + + +@pytest.mark.timeout(600) +@pytest.mark.guest_boot_script(dedent(f""" + ifconfig eth0 10.1.105.101 + until ping -c 10 {os.environ["HOST_IP4"].partition('/')[0]}; do + sleep 1 + done + echo \"guest ping test passed\" + """)) +def test_guest( + machine_on_ipmi: IPMI, + sshkey_for_test: paramiko.pkey.PKey, + boot_string: str, + ) -> None: + expect_string = boot_string + for line in machine_on_ipmi.console_output_generator(): + # + # Wait for `expect_string` for the test to succeed + # + if expect_string in line: + logging.info(f"got expect_string '{line}'.") + break + # + # Some common expected or not console outputs. + # + if "Latest ChangeSet:" in line: + logging.info(f"Test xen build from '{line}'.") + if "Manual reset required ('noreboot' specified)" in line: + # Test failed, could wait a bit before failing the test. + logging.error("Xen panic") + + with paramiko.client.SSHClient() as ssh: + threads = [] + ssh_logs: Queue[str] = Queue() + ssh.set_missing_host_key_policy(paramiko.client.WarningPolicy) + logging.debug(f"connecting to {os.environ['HOST_IP4'].split('/')[0]}") + ssh.connect(os.environ['HOST_IP4'].split('/')[0], + username='root', + pkey=sshkey_for_test, + timeout=10, + ) + + def ssh_channel_read(stdout, prefix): + for output in stdout: + ssh_logs.put(f"{prefix}{output.strip()}") + + def tail_log(file: Path, prefix: str): + stdin, stdout, stderr = ssh.exec_command(f"tail -n0 -F {file}") + stdin.close() + # Dirty, should keep `stderr` to clean it up + t = Thread(target=ssh_channel_read, args=(stdout, prefix)) + t.start() + return t + + threads += [ + tail_log(Path("/var/log/xen/console/guest-domU.log"), "(domU) "), + tail_log(Path("/var/log/xen/qemu-dm-domU.log"), "(qemu-dm) "), + ] + + cmd = dedent(f""" + set -x + pxe_host="{os.environ["PXE_HOST"]}" + http_pxe_path="{os.environ["PXE_HTTP_PATH"]}" + wget http://${{pxe_host}}/${{http_pxe_path}}/bzImage -O /boot/vmlinuz-domU + wget http://${{pxe_host}}/${{http_pxe_path}}/guest-rootfs.cpio.gz -O /boot/initrd-domU + xl -Tvvv create /etc/xen/domU.cfg 2>&1 + """) + logging.info(f"Exec command: {cmd}") + stdin, stdout, stderr = ssh.exec_command(cmd) + + # everything is on stderr, both wget and xl output + t = Thread(target=ssh_channel_read, args=(stderr, "")) + t.start() + threads.append(t) + t = Thread(target=ssh_channel_read, args=(stdout, "")) + t.start() + threads.append(t) + + # Log while `xl` is preparing the guest to start + while t.is_alive(): + line = ssh_logs.get() + logging.debug(line) + + xl_exit_status = stderr.channel.recv_exit_status() + assert xl_exit_status == 0 + + # `xl` have exited, continue logging the guest output + while True: + line = ssh_logs.get() + logging.debug(line) + if "guest ping test passed" in line: + logging.info("found expected guest line in logs") + break -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:29:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:29:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428558.1651418 (Exim 4.92) (envelope-from ) id 1x8xkQ-000701-FM; Tue, 22 Sep 2026 10:29:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428558.1651418; Tue, 22 Sep 2026 10:29:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xkQ-0006xh-8R; Tue, 22 Sep 2026 10:29:14 +0000 Received: by outflank-mailman (input) for mailman id 1428558; Tue, 22 Sep 2026 10:29:12 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xkO-0006nG-Sf for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:29:12 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xkO-00ApC1-13; Tue, 22 Sep 2026 10:29:12 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xR5-00DE8C-2X; Tue, 22 Sep 2026 10:09:15 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=h6+SFB0CIizh0TnhNrfS2IIUlkL9246nxzGjrD51H0I=; b=QOWCVPAl1mpKrXFrDY/XE+hiAX Dh/I4r/EWYNQQ/WU0Vd0h0mta+5IW2k5gAZdMOaiIl1nfmgn+H70XESbEiSxlf5jYmBKQ0rA3DqTI 8IcygBJbJc1HJryYo/f0EpMFnr7Ll49mFdGEwPsx4LLS6xv3nRIrwYFBzJWTERiSC37E=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 11/13] pytest: Add config to enable live log, and disable ssh/paramiko logging Date: Tue, 22 Sep 2026 12:08:58 +0200 Message-ID: <20260922100900.29129-12-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD Signed-off-by: Anthony PERARD --- automation/pytest/pytest.toml | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 automation/pytest/pytest.toml diff --git a/automation/pytest/pytest.toml b/automation/pytest/pytest.toml new file mode 100644 index 000000000000..ef61ff74ab47 --- /dev/null +++ b/automation/pytest/pytest.toml @@ -0,0 +1,9 @@ +[pytest] +addopts = [ + "--log-disable=paramiko.transport", + "--log-disable=paramiko.transport.sftp", +] +log_cli_format = "%(asctime)s %(levelname)s %(message)s" +log_cli_date_format = "%H:%M:%S" +log_cli_level = "DEBUG" +log_cli = true -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:29:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:29:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428555.1651400 (Exim 4.92) (envelope-from ) id 1x8xkP-0006nX-Ma; Tue, 22 Sep 2026 10:29:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428555.1651400; Tue, 22 Sep 2026 10:29:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xkP-0006nQ-Jn; Tue, 22 Sep 2026 10:29:13 +0000 Received: by outflank-mailman (input) for mailman id 1428555; Tue, 22 Sep 2026 10:29:12 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xkO-0006mw-8j for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:29:12 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xkN-00ApBl-1B; Tue, 22 Sep 2026 10:29:11 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xR8-00DE8C-0E; Tue, 22 Sep 2026 10:09:17 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=DyHqTO5jwlg+PrrWKnovMacZA2AwSnp3TeyqmfEC+9I=; b=2ufe/gQ6FxZjBTTJ+EIhJFj6qu oHnK5nEjocfkLk2kQBQ2/bzQ/edqnQFg98T0+woqazh7S6E7oTaiOyTqiZKmi4HdDA4iR4xJo+zBC 3WusMl1vVozCgrRKhD7h0eo5WelQQliex/lR8o8HqruvL/YiK2YoNE3EVr37CvtD4XGs=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 13/13] gitlab-ci: Add job for moonshot with pytest Date: Tue, 22 Sep 2026 12:09:00 +0200 Message-ID: <20260922100900.29129-14-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD WIP, use alternative branchs for artefacts - moonshot need kernel with driver for the network card and for vlan - alpine rootfs need network support and sshd Signed-off-by: Anthony PERARD --- automation/gitlab-ci/test.yaml | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml index 61adc1baff30..1f760e24811f 100644 --- a/automation/gitlab-ci/test.yaml +++ b/automation/gitlab-ci/test.yaml @@ -205,6 +205,7 @@ - qubes-hw11 # Test jobs + build-each-commit-gcc: extends: .test-jobs-common variables: @@ -777,6 +778,26 @@ qemu-xtf-argo-x86_64-gcc-debug: needs: - alpine-3.24-x86_64-gcc-debug +broadwell-tools-tests-pv-x86-64-gcc-debug: + extends: .test-jobs-common + variables: + XEN_REGISTRY: registry.gitlab.com/xen-project/people/anthonyper/xen + CONTAINER: archlinux:current-uv + artifacts: + paths: + - smoke.serial + - '*.log' + when: always + reports: + junit: tests-junit.xml + tags: + - vates-moonshot-1 + needs: + - *x86_64-test-needs + - alpine-3.24-x86_64-gcc-debug + script: + - cd automation/pytest && uv run pytest + qemu-smoke-riscv64-gcc: extends: .qemu-riscv64 script: -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:29:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:29:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428557.1651413 (Exim 4.92) (envelope-from ) id 1x8xkQ-0006uv-7L; Tue, 22 Sep 2026 10:29:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428557.1651413; Tue, 22 Sep 2026 10:29:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xkQ-0006tP-0k; Tue, 22 Sep 2026 10:29:14 +0000 Received: by outflank-mailman (input) for mailman id 1428557; Tue, 22 Sep 2026 10:29:12 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xkO-0006nB-S0 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:29:12 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x8xkO-00ApBz-0w; Tue, 22 Sep 2026 10:29:12 +0000 Received: from [2a01:cb15:80c6:e800:b9e9:dfdc:4751:7ecb] (helo=l14.home) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x8xR6-00DE8C-31; Tue, 22 Sep 2026 10:09:16 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=xbKqePSgOa7HquVDUAC/PIH+wy1cBxBCncvcGMMYNw0=; b=w9WFgaeqKb8P/grfPG6dOfj7D3 eOrUekBbBylDc6LCbQGVgOy3X81cse+VLj2PXkFRxPnwBNKHKrWaqSg2gEprousa7rte3MKeGt2Xh TITxUzPAjiUgFeidVwg7G2KZ3jzkS4wINj/P/Sy57nu2mS15F3jHLTpktAyCmw4VgEJ0=; From: Anthony PERARD To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: [RFC XEN PATCH 12/13] pytest: Add example .env for options for the tests Date: Tue, 22 Sep 2026 12:08:59 +0200 Message-ID: <20260922100900.29129-13-anthony@xenproject.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Anthony PERARD All thees could be instead pass to the environment of a gitlab-runner job instead. But that can make developing easier. Signed-off-by: Anthony PERARD --- automation/pytest/.env | 19 +++++++++++++++++++ automation/pytest/pyproject.toml | 1 + automation/pytest/pytest.toml | 4 ++++ 3 files changed, 24 insertions(+) create mode 100644 automation/pytest/.env diff --git a/automation/pytest/.env b/automation/pytest/.env new file mode 100644 index 000000000000..6ac8b6158de8 --- /dev/null +++ b/automation/pytest/.env @@ -0,0 +1,19 @@ +# Test machine +HOST_MAC="ff:ff:ff:ff:ff:ff" +HOST_IP_GATEWAY="203.0.113.1" +HOST_IP_VLANID=42 +HOST_IP4="203.0.113.42/24" +HOST_IP6="2001:db8::1:42/32" + +# IPMI +IPMI_HOSTNAME='moonshot.example.org' +IPMI_BLADE_NODE="c42n1" + +# Network environment +# XXX default value probably not needed with env_files_skip_if_set +PXE_HOST=${PXE_HOST:-pxe.example.org} +PXE_HTTP_PATH="configs/custom/${HOST_MAC}" +PXE_SSH_USER=pxe +PXE_SSH_PATH="pxe/moonshot-c42" + +SSH_PUB_KEYS="ssh-algo AAAArandomstring Not a real key\n" diff --git a/automation/pytest/pyproject.toml b/automation/pytest/pyproject.toml index c54c1338f656..b62befaa07d3 100644 --- a/automation/pytest/pyproject.toml +++ b/automation/pytest/pyproject.toml @@ -7,6 +7,7 @@ dependencies = [ "paramiko<5.0.0", "pip>=26.0.1", "pytest>=9.0.2", + "pytest-env>=1.6.0", "pytest-timeout>=2.4.0", "types-paramiko>=4.0.0.20260322", ] diff --git a/automation/pytest/pytest.toml b/automation/pytest/pytest.toml index ef61ff74ab47..405a56a83301 100644 --- a/automation/pytest/pytest.toml +++ b/automation/pytest/pytest.toml @@ -7,3 +7,7 @@ log_cli_format = "%(asctime)s %(levelname)s %(message)s" log_cli_date_format = "%H:%M:%S" log_cli_level = "DEBUG" log_cli = true + +[pytest_env] +env_files = [".env"] +env_files_skip_if_set = true -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:41:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:41:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428584.1651437 (Exim 4.92) (envelope-from ) id 1x8xvk-0002uA-BZ; Tue, 22 Sep 2026 10:40:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428584.1651437; Tue, 22 Sep 2026 10:40:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xvk-0002u3-88; Tue, 22 Sep 2026 10:40:56 +0000 Received: by outflank-mailman (input) for mailman id 1428584; Tue, 22 Sep 2026 10:40:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xvi-0002ts-IW for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:40:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8xvh-002YWX-Hq for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:40:53 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab25b1a-bab6-0a2a0a5309dd-0a2a450b976e-40 for ; Tue, 22 Sep 2026 12:40:53 +0200 Received: from [52.101.193.10] (helo=CH1PR05CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab25b33-b7e8-0a2a450b0019-3465c10a625b-3 for ; Tue, 22 Sep 2026 12:40:52 +0200 Received: from SJ0PR03CA0073.namprd03.prod.outlook.com (2603:10b6:a03:331::18) by IA0PR12MB8279.namprd12.prod.outlook.com (2603:10b6:208:40c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 10:40:47 +0000 Received: from SJ1PEPF000037B4.namprd05.prod.outlook.com (2603:10b6:a03:331:cafe::12) by SJ0PR03CA0073.outlook.office365.com (2603:10b6:a03:331::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.14 via Frontend Transport; Tue, 22 Sep 2026 10:40:47 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000037B4.mail.protection.outlook.com (10.167.244.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Tue, 22 Sep 2026 10:40:47 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 05:40:46 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 22 Sep 2026 05:40:45 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=u/f8NQ35P2f8Z+yYJ8FYYYgZHaEv3kXAIeq8CQb0LeLYQnIu1ErgkRGGEB406OBV4viDCR1MeNQ9NQ91fcZT+Kg2ejGfnagGBOLwy7nWaqtuONNntFgoWxkh3Bqof/EyOnN/1AZvOVhV/9wtyTBnwraEAv4nAkfe0VCaUgGXdu9pOHc1y+1v/YS/ZCF6p9sM7rqbPT2l03uY46hYGoOd9Xq9AsXqr/gbGuOoIDoY9/InoK025dPbAriPhzaQ4L41aqb58ktZPuba5Ctk5w7XBy7pzkFB9xZMswTmskgq5TBjVqeUXq/SloYVrN19thc407Y0cH0add5mWdkaw09OsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sSXtJlKtuHO38bEmsYe9zHxX98764NQ07GAZX44543w=; b=f4/RoBEx/i4gMDbdwxxCshi+qtDEIkijO5DEfpUf8By8x+M/AR8uGGsRLHKh9/TT9zsQGM8ctJ6I1eAMKXMW4lHS+HZHYhDOZK4fVmnmVQaraOOIipwXIfJDSZO7SjAS7elLly5aqeXVYpd29KrWlC5gYsbMUnI4ybbHU+57mNHopcblqM0IhzXYJkH8sS3c7xBhmMpqazom6t+nfmd33iQz1e91N0nbF0ecg7uHnEF9ThxVUDFz3Of3If2dww0mfQjX0RTLwdv7v/Udseec/AQcYs4G9yTL4wLf433366na+2ae4kkov9SMXMhklTKcY6hu/7KvBIwcnTJjHbWQfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sSXtJlKtuHO38bEmsYe9zHxX98764NQ07GAZX44543w=; b=sOA1n3R8EHCLrHL2wWuPy9Napt90SVQCHixSgtAFiYpxWITGtNsSeffTAvlhz7gwc8RUaJHqr7ev12ia1bfxKfK4Omw8DvUU46zIUnB8y7DepGXgu7mxcESSKbDKicG2cyDlQQOwKL7ve7GKQgdMXu2I4SYTMKh40gXDDkSLUoc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <600256d1-a038-4ceb-a1df-a8d86dfee130@amd.com> Date: Tue, 22 Sep 2026 12:40:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/arm: derive GIC CPU interface ID fields from the vGIC To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <1101ee75414ec2e6bec05d34118c4fa7f8b60bcf.1790060180.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1101ee75414ec2e6bec05d34118c4fa7f8b60bcf.1790060180.git.mykola_kvach@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000037B4:EE_|IA0PR12MB8279:EE_ X-MS-Office365-Filtering-Correlation-Id: 9e17ce70-aed1-46a6-e85f-08df1895f671 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|376014|23010399003|82310400026|6133799003|22082099003|18002099003|5023799004|11063799006|56012099006|10067099003; X-Microsoft-Antispam-Message-Info: ehA/NL4DQD5sQa/bA/jjjCK9mMvC4wGWam4HjsSSSakLw0J0KRJ3PlXsoR4KJCSSP+AD29ga6bmWLdAjsVFChcvEUOy+gWm5WnhoQ8ddjynRCmKxSL9HqoVkRhk2X1dQO7nBDkM+0tFsLtqcw5Iy/04IuTLqY223XJzE5MC3h/+fB2By8kisPY4d/PcV1m14SlEHifqm8+4FRe4N1HSwjFahXj95CoK4f6xdjPBB74o5hBipS58cgucmyEpabZCJ6Da5nsJCOqkqxoIVPvHfMrLst8agCYhWEcX+IypDRb0dbanXxUwqGl+5iWLdcv+ibfmxrHvmLZ5SlgGc2hGk0+kQCFNuadiPBD/b45ICO1FDSXKk9v3WmxkmmoKwI05JleoNVPBs8CTWGTKyQzOZypYlNRSVnIpCoNMkpGp0LHRkiE5holxuakzK1tajQfjfCi3oB6hBbsJCHEafsIItYNNjpPENZWjNHx5fCwDpghi97/Xik9nAsvO+3VCtFqwTzG7OJt7Da/qLAz6cTzXCHATK89CxzK9etfOAA4X4vCm6GbSrwm4yhqYYuKFHQ/T8A6VdNPU+o1OY6rlVVkKmV1rymwOj7jRe2tmMAPuR4W2QxKjqNcGFpfR3SEvDkT4AtM0CQ+t6nN/W375hlSsZrA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700016)(376014)(23010399003)(82310400026)(6133799003)(22082099003)(18002099003)(5023799004)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: fGxMhl9MZKFo5AYJu+gclXmE/jG4NXnxFwifJBru6qUn2VZ/w8LuHDlxdTtFQDV/dqYLaY7HXWy0P5qRhNnVRjbs27A48TjqwXtF3Oa4zQalb9aMcQjyRfu4dzHKve3bc08vcCBecps4SUKaY/AT9yryk1UxsARHJR7t7Z1AVMAuj3l7r8bi0i7M9GziRsi9MqPGc5uiZVsSNN6vDBcB5+D0811BIw52vbIPyyYgcYt4BM6vvGPG+Feat7Cswusp93nSvQNNstyiiZ1pT4xWiv6PKWfvC8qUDuhOj4T4nIldKO6T99fxQVcBlNnYfB71xzl8p9dNZ4KW5QdyE724JcyqB/pbQQg8IJ5nkLHeXt5Jkb1/+SGc9ambZHxSWSpk8VbJly1mRSxExY3vA1kMKPNBIiZQT0u67i6dUqjdeN6KbcvsXuXplk0NtjilkDKH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 10:40:47.2471 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9e17ce70-aed1-46a6-e85f-08df1895f671 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000037B4.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8279 X-purgate-ID: tlsNG-42698a/1790073652-A84CB9EA-11DD97EE/0/0 X-purgate-type: clean X-purgate-size: 7509 On 22-Sep-26 09:21, Mykola Kvach wrote: > Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo, > which is initialized from the sanitized host CPU feature state. This > does not necessarily match the virtual interrupt controller configured > for a domain. > > A vGICv2 domain can therefore observe a nonzero GIC field when the host > supports the GIC system register interface, even though Xen disables that > interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can > observe encoding 0b0011, although Xen exposes only its vGICv3 model. > > Derive the fields from the domain's vGIC version instead. Expose 0b0000 > for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the > ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through > CP15 in AArch32 state. Leave the alias unchanged when AArch32 is > unavailable. > > Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64") > Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers") > Signed-off-by: Mykola Kvach > --- > Changes in v4: > - Explain why ID_PFR1_EL1 is left unchanged without AArch32 EL0 support. > - Move all ID_PFR1_*_SHIFT definitions to the common asm/sysregs.h and > remove the unused cpregs.h includes from the ARM64 files. > - Return explicit unsigned GIC field values to avoid MISRA C Rule 10.3. > > Changes in v3: > - Add direct dependencies for the shared ID register helpers. > - Move ID_PFR1_GIC_SHIFT to the common CP15 register header. > - Apply cosmetic fixes from review. > > Changes in v2: > - Share the GIC ID field helpers between the AArch64 and AArch32 paths. > - Parenthesize the individual ASSERT conditions. > - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable. > - Target master instead of the 4.22 release. > > v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/ > --- > xen/arch/arm/arm64/vsysreg.c | 21 ++++++++++++++++++- > xen/arch/arm/include/asm/arm64/sysregs.h | 9 -------- > xen/arch/arm/include/asm/sysregs.h | 9 ++++++++ > xen/arch/arm/include/asm/vreg.h | 26 ++++++++++++++++++++++++ > xen/arch/arm/vcpreg.c | 12 ++++++++++- > 5 files changed, 66 insertions(+), 11 deletions(-) > > diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c > index 66f4f23bb3..2912445301 100644 > --- a/xen/arch/arm/arm64/vsysreg.c > +++ b/xen/arch/arm/arm64/vsysreg.c > @@ -299,7 +299,22 @@ void do_sysreg(struct cpu_user_regs *regs, > * to identify the processor features > */ > GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0) > - GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1) > + case HSR_SYSREG_ID_PFR1_EL1: > + { > + register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1]; > + > + /* > + * Preserve the sanitized ID_PFR1_EL1 value when AArch32 EL0 > + * is not supported, as for the other AArch32 ID registers. > + */ > + if ( cpu_feature64_has_el0_32(&domain_cpuinfo) ) > + guest_reg_value = id_reg_set_gic_field(guest_reg_value, > + ID_PFR1_GIC_SHIFT, > + v->domain); > + > + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, > + guest_reg_value); > + } > GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2) > > case HSR_SYSREG_ID_DFR0_EL1: > @@ -362,6 +377,10 @@ void do_sysreg(struct cpu_user_regs *regs, > guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask; > } > > + guest_reg_value = id_reg_set_gic_field(guest_reg_value, > + ID_AA64PFR0_GIC_SHIFT, > + v->domain); > + > return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, > guest_reg_value); > } > diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h > index f3c11d871e..f6ece8f972 100644 > --- a/xen/arch/arm/include/asm/arm64/sysregs.h > +++ b/xen/arch/arm/include/asm/arm64/sysregs.h > @@ -438,15 +438,6 @@ > #define MVFR1_FPDNAN_SHIFT 4 > #define MVFR1_FPFTZ_SHIFT 0 > > -#define ID_PFR1_GIC_SHIFT 28 > -#define ID_PFR1_VIRT_FRAC_SHIFT 24 > -#define ID_PFR1_SEC_FRAC_SHIFT 20 > -#define ID_PFR1_GENTIMER_SHIFT 16 > -#define ID_PFR1_VIRTUALIZATION_SHIFT 12 > -#define ID_PFR1_MPROGMOD_SHIFT 8 > -#define ID_PFR1_SECURITY_SHIFT 4 > -#define ID_PFR1_PROGMOD_SHIFT 0 > - > #define MVFR2_FPMISC_SHIFT 4 > #define MVFR2_SIMDMISC_SHIFT 0 > > diff --git a/xen/arch/arm/include/asm/sysregs.h b/xen/arch/arm/include/asm/sysregs.h > index f6af987ef5..8dcf82a694 100644 > --- a/xen/arch/arm/include/asm/sysregs.h > +++ b/xen/arch/arm/include/asm/sysregs.h > @@ -9,6 +9,15 @@ > # error "unknown ARM variant" > #endif > > +#define ID_PFR1_GIC_SHIFT 28 > +#define ID_PFR1_VIRT_FRAC_SHIFT 24 > +#define ID_PFR1_SEC_FRAC_SHIFT 20 > +#define ID_PFR1_GENTIMER_SHIFT 16 > +#define ID_PFR1_VIRTUALIZATION_SHIFT 12 > +#define ID_PFR1_MPROGMOD_SHIFT 8 > +#define ID_PFR1_SECURITY_SHIFT 4 > +#define ID_PFR1_PROGMOD_SHIFT 0 > + > #ifndef __ASSEMBLER__ > > #include > diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h > index 387ce76e7e..96de1c4916 100644 > --- a/xen/arch/arm/include/asm/vreg.h > +++ b/xen/arch/arm/include/asm/vreg.h > @@ -4,11 +4,37 @@ > #ifndef __ASM_ARM_VREG__ > #define __ASM_ARM_VREG__ > > +#include > +#include > +#include > + > +#include > + > typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r, > bool read); > typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r, > bool read); > > +#define ID_REG_GIC_WIDTH 4 > + > +static inline unsigned int vgic_id_gic_field(const struct domain *d) > +{ > + ASSERT((d->arch.vgic.version == GIC_V2) || > + (d->arch.vgic.version == GIC_V3)); > + > + return d->arch.vgic.version == GIC_V3 ? 1U : 0U; > +} > + > +static inline register_t id_reg_set_gic_field(register_t val, > + unsigned int shift, > + const struct domain *d) > +{ > + register_t mask = GENMASK(shift + ID_REG_GIC_WIDTH - 1, shift); > + > + return (val & ~mask) | > + ((register_t)vgic_id_gic_field(d) << shift); No need for split. It would fit 80 chars. > +} This is a header included by a few source files, so the less we expose the better. Please combine vgic_id_gic_field() into id_reg_set_gic_field() given its simplicity and the fact that it is only used in the latter. Also, your new helpers use a vgic.h namespace (this header uses vreg_ prefix). I think it makes sense to s/id_reg_set_gic_field/vreg_id_reg_set_gic_field/ and s/ID_REG_GIC_WIDTH/VREG_ID_REG_GIC_WIDTH/. With that changed: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:41:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:41:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428585.1651446 (Exim 4.92) (envelope-from ) id 1x8xvu-00038o-LL; Tue, 22 Sep 2026 10:41:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428585.1651446; Tue, 22 Sep 2026 10:41:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xvu-00038h-Hj; Tue, 22 Sep 2026 10:41:06 +0000 Received: by outflank-mailman (input) for mailman id 1428585; Tue, 22 Sep 2026 10:41:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8xvt-000385-05 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:41:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8xvs-005Mj6-D7 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:41:04 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab25b39-e002-0a2a0a5209dd-0a2a450c8f74-16 for ; Tue, 22 Sep 2026 12:41:04 +0200 Received: from [209.85.221.50] (helo=mail-wr1-f50.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab25b40-f479-0a2a450c0019-d155dd32a90c-3 for ; Tue, 22 Sep 2026 12:41:04 +0200 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-48442ea8f59so354503f8f.1 for ; Tue, 22 Sep 2026 03:41:04 -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 ffacd0b85a97d-4886277e84dsm4339915f8f.20.2026.09.22.03.41.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 03:41:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790073664; x=1790678464; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ufeWPTw2a32SZPJ7XqPuk3knJu3zYqx8RaOhX4Rhsds=; b=PsLcXOSgdnD2mk6oyCADDAE09QfHh4o4kgZloyWSOF4qbWZelh76OhTTxHpviHUrb7 1IOoU6sYU9nb2BpAJJR5RN7SxSTGRzPrS6OvjLbn2ad8KVFcA8krZGEO463Uo5F9AWpr ai5pkxs+yTrJC95evssN9FdrzISE8nsmjzbV112Dq3l7NhQO7JdYmrv28VT7aG9sff8B 8g7t6xS+wvffU8mWalUGa8rp40ftSKM20UlLwvQAwElLKyk5ZlzjsJRMGj5FPpEjY5N3 zSM/QMhPBkbRM32SFDSjCe0nmp0yZtesxDpMaqbMKGvNU7yDBnQe56vfCRvYeu2cyCEq LsVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790073664; x=1790678464; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ufeWPTw2a32SZPJ7XqPuk3knJu3zYqx8RaOhX4Rhsds=; b=s7izs/90DaCbedHbxfjQDii/ly0Y5LYJs2qNf9aeZKV8aHff3mlFTlsPQ1oy0tthsR h0FYQDLT3GfAMiBDaHubM4dYulVQxWpDSWi5ra2ufInngklymgRW4JMxXEkAGIQfdVka OpftQJMM1Fr5ZTCFgJ1A+j158RP3OLydhGZ8eWcATEo+oSfTt6BdBQJzDIsS4DtK57Ez WX+qcLAjxyxdSJYwgtvJ0KoPhlugFKw7reK2YDbBTJa4+bpp1tjubcWJkuJnaPtCsS4M 9v6jmPTStY14T9LZcOZ96N41cWKJb3gxk1gzRriXgbou34/kLpporj/YlAKR9LtNlNft qwHQ== X-Gm-Message-State: AFuF++m7aq+v/NZImVEd14wrrxqWZ1Ck9G/r403J2YG7oMaiMNXCSh1i YoFUQ2tiT2o84yv/Sd2aa6VsZQS9Qae67JjA7o8z8NomTcS7LTJA/3+IAYktbROvHkUmFstKnjg FGGH7Og== X-Gm-Gg: AYBFou2kL/2y6qDDA2kID09fIrEJGcHGnVxVch0rEspLwZV9Wtyp+J/dulkqeFDaCNF 44oE6F2CNUgXejHd2RrTQkLpMplYajsqq+3CcN0TME8ahC5usLlq2R1S/1SXcxJKo2R7XSj3347 rduRBT4DsudwlJ+7tq4n6Fal+1XcjQ5i7aP0Chxq186iYFVAslmHvci/fQWyB8d18j8tY5dJTbZ 1g2rqX/6HM2FV6W7KNcBb1vIlok/a5kkngI9csfRaE8oOcRtKN0U0sx/3dWAL4qtDQIqu2p9hTN 24DVMcARwi9OiMxp7HWhOlIho1wyMfdACxLsNXeFMa0pi+2uf42cFv4Q2a0g/oXolX0ZQvl9rdB JzM/d8/DIQcObTAgE9o/AjhAOehSymzvlN/pjtR/PDj1YiLD5n3ynTxFF2zftLQYL1wS4IbXwOx EZn+jdT+2IgtOyrPRGNZhqoKoNY0ucQb3k1daA4PsWb+nSohGw3v62WSv5PzYbshb6RVsmoaZ4P 30xyt/RDMf2lsdxSojTdoMM559pAqMZ7w3UdHQoGN928eg7roViVVbJuMHpfHQ= X-Received: by 2002:a05:6000:4303:b0:487:9bb:a875 with SMTP id ffacd0b85a97d-48860f7eb5bmr3761591f8f.3.1790073663620; Tue, 22 Sep 2026 03:41:03 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 12:41:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel From: Jan Beulich Subject: [PATCH] Arm: drop ENFORCE_UNIQUE_SYMBOLS=y workaround again 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790073664-772D8A5B-C538156D/0/0 X-purgate-type: clean X-purgate-size: 2203 Both arm/head.S and arm/mmu/head.S have a local symbol "fail". Without a .file directive locals will be associated with the path-less object filename (head.o). Hence the two symbol names collide. Add .file, also in arm/mpu/head.S for consistency. Signed-off-by: Jan Beulich --- Likely other .S files should also gain .file, but for now that's largely cosmetic and hence is left out. --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -91,9 +91,6 @@ include scripts/Makefile.link # Suppress orphan section checking for the time being. orphan-handling-y := -# Downgrade duplicate symbol errors to warnings for the time being. -syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --warn-dup - .PHONY: include include: --- a/xen/arch/arm/arm32/head.S +++ b/xen/arch/arm/arm32/head.S @@ -17,6 +17,8 @@ * GNU General Public License for more details. */ + .file __FILE__ + #include #include --- a/xen/arch/arm/arm32/mmu/head.S +++ b/xen/arch/arm/arm32/mmu/head.S @@ -5,6 +5,8 @@ * Arm32 MMU specific start-of-day code. */ + .file __FILE__ + #include #include --- a/xen/arch/arm/arm32/mpu/head.S +++ b/xen/arch/arm/arm32/mpu/head.S @@ -3,6 +3,8 @@ * Start-of-day code for an Armv8-R-AArch32 MPU system. */ + .file __FILE__ + #include #include #include --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -20,6 +20,8 @@ * GNU General Public License for more details. */ + .file __FILE__ + #include #include --- a/xen/arch/arm/arm64/mmu/head.S +++ b/xen/arch/arm/arm64/mmu/head.S @@ -5,6 +5,8 @@ * Arm64 MMU specific start-of-day code. */ + .file __FILE__ + #include #include --- a/xen/arch/arm/arm64/mpu/head.S +++ b/xen/arch/arm/arm64/mpu/head.S @@ -3,6 +3,8 @@ * Start-of-day code for an Armv8-R MPU system. */ + .file __FILE__ + #include /* From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:52:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:52:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428619.1651510 (Exim 4.92) (envelope-from ) id 1x8y7G-00063p-6M; Tue, 22 Sep 2026 10:52:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428619.1651510; Tue, 22 Sep 2026 10:52:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8y7G-00063i-3j; Tue, 22 Sep 2026 10:52:50 +0000 Received: by outflank-mailman (input) for mailman id 1428619; Tue, 22 Sep 2026 10:52:49 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8y7F-00063Z-Lt for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:52:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8y7E-00G8kc-J1 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:52:48 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab25df0-e002-0a2a0a5209dd-0a2a45029b06-24 for ; Tue, 22 Sep 2026 12:52:48 +0200 Received: from [52.101.46.19] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab25dfe-6ca4-0a2a45020019-34652e13c1a0-3 for ; Tue, 22 Sep 2026 12:52:48 +0200 Received: from BYAPR21CA0023.namprd21.prod.outlook.com (2603:10b6:a03:114::33) by MW4PR12MB7013.namprd12.prod.outlook.com (2603:10b6:303:218::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 10:52:42 +0000 Received: from CO1PEPF00012E7D.namprd03.prod.outlook.com (2603:10b6:a03:114:cafe::4e) by BYAPR21CA0023.outlook.office365.com (2603:10b6:a03:114::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.14 via Frontend Transport; Tue, 22 Sep 2026 10:52:41 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF00012E7D.mail.protection.outlook.com (10.167.249.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Tue, 22 Sep 2026 10:52:41 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 05:52:40 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 22 Sep 2026 05:52:39 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lORNliHhEIQHm8WgUsefxI0I894/81HMUnpr1oQEiBdSb4a51vJaD4eEEdI3xKcsXW4XHljdW3dyDN36bVlHc87cviiH3/RY/lK3zgVpO4zi8NV/i9dM/j3L9V2EPLsbO+1rc+fsNwoplZNsYUQVq0gU+V7dakuGtEetyvIeAuNsPBrS3RbDll9PgGKfAL6FBg1ASrEfIDQRSBM96PE7fAx2bVEj4CYVEDfmzh48DnMmNdLU4uMzjhTRq7UKULG0muyXK8rXCIicKpn7rM5Igmmcmcn12/mY+sp2pmJt9OKSffyfBL1ieHzXc8UycXnAf/dkR8SsJTUnhe5n5hsqPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wVEbYL0ZEJKb1i/fBd0sHpOSlMSuoxl5jsUjcZAjuoQ=; b=o4f2tKIKt7EMkQIrEX9NIl4r8KvguLAo0vmVzPQMRqJnMe8UnaV1kbbwiK3V7wX34MHQui5zkQPwVVge/SqT6bsGLYRL0u8flIjv7fTUPEG4lm7ZaL79S4oauFdGwE9p1EKbF4bqbjfFXqu3vUEdhrZqm5upAK2QRrdovV/jIfaDoBOU9HHdfOMN+/sQuUt6opg+XOUzl6W3lPkxsCWdz1E0otELY0ZScizefqJ8o2eSSTjMVQJTxCwxRws6LwC6fuUSdyFOFfOo1HuboZfwY0EJTebrZXrRaSxaI/bYNWc2y2vSx5yz8GmrCW/EgS5qFERTFg1gQuV7g82BXBq6ag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wVEbYL0ZEJKb1i/fBd0sHpOSlMSuoxl5jsUjcZAjuoQ=; b=wG36g6flGu/w0w4fEwKL0t8SXJvHuLiM8Xq5ycQ4WIhuKTzwQPYcOUtMyJIl6HHnSm/QJ5by6AYMeBVydzyjqWWZPLLg6Yj3hdeX09U/duy9maJVL51Jul7O66VPmBjD1f1xiTQy9yFuyhcby8fV2yjPBBGmBG3VsfWoMWL9iPk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Tue, 22 Sep 2026 12:52:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Arm: drop ENFORCE_UNIQUE_SYMBOLS=y workaround again To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis References: From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF00012E7D:EE_|MW4PR12MB7013:EE_ X-MS-Office365-Filtering-Correlation-Id: 50798adc-7d88-487b-4489-08df1897a03b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|36860700016|82310400026|3023799007|10067099003|11063799006|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: JlzYl7SCjZZg9e4dDuydbZfXMzvzDeW0rgTOhZ3J6lvFBorfEyWuf08x6EQqPMmsHg6kZDZEB+Jo4WXZEqGXYIRn8YGm1dYG/OzMBgw7p9E9AuEC/mBHtrbswq3oXEWBehj8jaRD4V9qO4g78Ol26SVyc6wlNNiIUQ97SriE6hv4giVaOVE1xoYuTzXc/NkBZQBUDMG4A7L0Bg4X0nEzL8lRE8SJe4bmtrlLEjIUgemLViqy4Q6RSGXnQP9bCN2Dnd7Xsy6mlvfsoTlCUiWcROZn7ejF2RFdUNcWvQXiVi+pkzXy1VIUmaYdmpIAeaR06zq8L+FQhjQZhpnJXxh6MbXNNHECoPJlFnnzoTH/+AoqAimZCsofZipkK52VhKBxdfIuKm3UbV1GLXAZFOlerKAyOWOUgCpOPHbYlnDwf6FBsTFQZee+FqwR+407PXo9cIn+LOfUxo0hVC6hiPsFi8q3NuhYuPfb1I/fUm+In7UNdkMtkgdkX9858v+Ba2y3nMQq8sb3JPbtOmnzZVi4ga4jZiAQ653q6KEz0N0yV17Br2r5Zxll+Zs2rGZUov+WFeomgPFX2okt4FlN96PpAOH8lrsPDeVJkSDvL5FulS9llm5aQExYhvMoZWPdk5rRwjY7LcQVzlez8iVOf53yf9sgI/mLKuDZBja6Mw5RvnfVq3WAyyGjRh+Z1OqfjXogQEwDXDcmWknPvXAxY3+VhQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(36860700016)(82310400026)(3023799007)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: sg1CQeaVlUTmNNpX00/ZvyYIWwOvx1TuBagYl6zex/0Lbv5HWhhQRI+k2uXLNWFa1fJnzIb4hSX2IYOS7XVrTVbuXtjZR6NuRBRj1CDCXS+elswFnr46oUJYW5bgIAMZAs5Yp54MEyiJWb25vh0Wm5Wu163lwYCsaKJP01EEHB48w0Uxs23KAOODjvW1goxzpfRG02C7TMsG60RrKBILIYwGqdmfoEylS62QmXI+sHbVytKDx8SLyKsfwsAVOcIISjUiHVlkTTFZpIc32RT8qV2MuEDeZn+H3SyztCse4pZlCYCjBi+oHFsN005ORRUyVJuxb81LglifuOO+nYZ3+d8ehjxwNZM5dO1+LSX3oARgIk419uXWcPy3Bo7dlhfAO3cg1BN3NNWvovLe3/IC06xGuNEoihuUp7X3CQBhaF5kwQW4789npzkCGErKmLAg X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 10:52:41.5932 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 50798adc-7d88-487b-4489-08df1897a03b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF00012E7D.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7013 X-purgate-ID: tlsNG-720697/1790074368-F3ABD2AC-3AE93D97/0/0 X-purgate-type: clean X-purgate-size: 2550 On 22-Sep-26 12:41, Jan Beulich wrote: > Both arm/head.S and arm/mmu/head.S have a local symbol "fail". > Without a .file directive locals will be associated with the path-less > object filename (head.o). Hence the two symbol names collide. Add .file, > also in arm/mpu/head.S for consistency. > > Signed-off-by: Jan Beulich > --- > Likely other .S files should also gain .file, but for now that's largely > cosmetic and hence is left out. > > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -91,9 +91,6 @@ include scripts/Makefile.link > # Suppress orphan section checking for the time being. > orphan-handling-y := > > -# Downgrade duplicate symbol errors to warnings for the time being. > -syms-warn-dup-$(CONFIG_ENFORCE_UNIQUE_SYMBOLS) := --warn-dup > - > .PHONY: include > include: > > --- a/xen/arch/arm/arm32/head.S > +++ b/xen/arch/arm/arm32/head.S > @@ -17,6 +17,8 @@ > * GNU General Public License for more details. > */ > > + .file __FILE__ > + > #include > #include > > --- a/xen/arch/arm/arm32/mmu/head.S > +++ b/xen/arch/arm/arm32/mmu/head.S > @@ -5,6 +5,8 @@ > * Arm32 MMU specific start-of-day code. > */ > > + .file __FILE__ > + > #include > #include > > --- a/xen/arch/arm/arm32/mpu/head.S > +++ b/xen/arch/arm/arm32/mpu/head.S > @@ -3,6 +3,8 @@ > * Start-of-day code for an Armv8-R-AArch32 MPU system. > */ > > + .file __FILE__ The MPU files are indented with 4 spaces, so please use 4 spaces here and ... > + > #include > #include > #include > --- a/xen/arch/arm/arm64/head.S > +++ b/xen/arch/arm/arm64/head.S > @@ -20,6 +20,8 @@ > * GNU General Public License for more details. > */ > > + .file __FILE__ > + > #include > #include > > --- a/xen/arch/arm/arm64/mmu/head.S > +++ b/xen/arch/arm/arm64/mmu/head.S > @@ -5,6 +5,8 @@ > * Arm64 MMU specific start-of-day code. > */ > > + .file __FILE__ > + > #include > #include > > --- a/xen/arch/arm/arm64/mpu/head.S > +++ b/xen/arch/arm/arm64/mpu/head.S > @@ -3,6 +3,8 @@ > * Start-of-day code for an Armv8-R MPU system. > */ > > + .file __FILE__ ... and here. Other than that: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 22 10:57:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 10:57:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428629.1651519 (Exim 4.92) (envelope-from ) id 1x8yBn-0006n5-Ng; Tue, 22 Sep 2026 10:57:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428629.1651519; Tue, 22 Sep 2026 10:57:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yBn-0006my-Kn; Tue, 22 Sep 2026 10:57:31 +0000 Received: by outflank-mailman (input) for mailman id 1428629; Tue, 22 Sep 2026 10:57:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yBm-0006mo-MR for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 10:57:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8yBm-00GxKi-3E for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:57:30 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab25f07-e002-0a2a0a5209dd-0a2a4505e312-32 for ; Tue, 22 Sep 2026 12:57:30 +0200 Received: from [52.101.70.99] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab25f19-4cb1-0a2a45050019-34654663423e-3 for ; Tue, 22 Sep 2026 12:57:30 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by DB3PR03MB10189.eurprd03.prod.outlook.com (2603:10a6:10:43c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 10:57:21 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 10:57:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QYt6ukm3+hA4xe+h2s3UNMypxsI2Hx80Xju2eR/E2st0urD7ubWmv8EqcKkPrkdsvD9oq5Qx0KQ9FrKtYFhxbkmLYS2UAFIQsgoid3GZTBAmIhytUPdvAPVOJPAfSNJUavO47wBVGlDqxTS3GB+L7qTxutb7LPIPJJp0nuUUhCNDDlMMaCLu+MOG0ikTpvwlSc558vD6b+xUGIkbku1JdiKDtRgh33i+yCJLuRx8bRyhoXVvkHXEZWHNasp5AnrUkbMErpTX6EkgqY+sRx+cC8jL5OeKWBGa39k6k62l8a9K+AgPNH15AEaMv9o+77ad3hJj/MHiSu1kpClfzgXoYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uaOefTgiUQBwZzauMDtdjPiXvVgb18Z1289qApiz8uk=; b=vXpvtHkAl4tXYe1j11kG8yuT3eIX5Exkj+twNOGO7NCMLRfMD+vYRbmlsq0eqknTZj0oqMZwKv9e0q82rZRelZSWxTlg6kYGHX33YnL2dkzJN2NHAbt9Hz7bXHhQxykNdxu+NEBrsaDmZVXGF2KCAmRAUWzrXA7UrYD80vAT+/6Cb8Sh5KuPg+mimvzMN2NZlGOgvrIVarGOeL5uTcS995tHLzlS1w1AATb+ZEpHhBNfsxejsm+PR2K0Ms/uHEruITJmFcYZ0XJpPlGlW3JownmiRP1xMtmnCcd3zIRxttaBfyjMPBNfHsZEJvfol40zz8JEOoJcf76wNONFE69TPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uaOefTgiUQBwZzauMDtdjPiXvVgb18Z1289qApiz8uk=; b=rRv5sEruEokLFBaSh5oLrSTtFe/9pYq9M0VLAHPtCs4F8ktme1Jy9PjC/fmcvf6XAUTgJ4UPjtOqbwpvH3V7qQmxXtASUf2hE4v7kwa6TdYrFqKJ4ltoQ+pE9GhmjIsFtBWm+dHM6KAbRlJhgx/TTW49H8sLq1xD9D0kwaY6zfziSU5UP6YhKZeli9+7/rzGlKrejf50SeeAgrCvPkxa6at4MYRMruDJ1OljuZfA1lcyGus6HvniHyR0nAVZhEwoWVcAmLg9WUgNUS/orty+c+zhuHmoAdFVwVHWzpCUaLZYDy9TYgHj7jf7K9N40PgxZFzgujc4wjTyfUAHw8bBCA== From: Volodymyr Babchuk To: Jan Beulich CC: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Bertrand Marquis Subject: Re: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code Thread-Topic: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code Thread-Index: AQHdOqUePUfY0zBPU0K0F/hx5odMHA== Date: Tue, 22 Sep 2026 10:57:21 +0000 Message-ID: <87y0ct5zan.fsf@epam.com> References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <87qzim6p5i.fsf@epam.com> <8fd025af-f429-488e-9977-aec3fea2e78b@suse.com> In-Reply-To: <8fd025af-f429-488e-9977-aec3fea2e78b@suse.com> (Jan Beulich's message of "Tue, 22 Sep 2026 08:47:48 +0200") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|DB3PR03MB10189:EE_ x-ms-office365-filtering-correlation-id: f4e3107a-cd95-4bf9-12ff-08df18984717 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|1800799024|376014|7416014|23010399003|366016|38070700021|10067099003|56012099006|11063799006|4143699003|18002099003|22082099003; x-microsoft-antispam-message-info: RfqDIyvYGD5uNf4IqQUaeiWOWdvwqrBUM3XvWsh9JfK+NQGPJ+gX/OlFBHGBoYXcpQezUZHvxFBC852OCGQIR7vi/Pb+u9segtLoVzJ/LLyLMY7Ybc7BpTmVf3mppVb2sO9Q8rRKxOztHaP58+YBmUt4AFEQ96DZWCVH6pdNTDEL19RbTvUVl+2yKiba0Zah9iCr3hHfxinPR7mo+nUBaNlGrzVG7sTEmJRDIG1ToMI35FDhvx08hzMgS5rnn15zdKJj70dJlJCi6vDBgmjQ0L8w0EV3IxOPquSKvCrUK5xEoifC2Y29w3OEYOaImf5QHg1DIZfYTu/Rdt6k+ZHsBoi1C9lEKaWH43JudaEbebSE+P/bwc0sl0afab1Ln8+5E7xnSOeWrv0o+wZB/ecPGkAOyU21aZHHZoHStnxPzUqxbmPQzqra1QfaeKLqRwtBh91Gk6nxvS+nggmOVZeDhRgdfmwMY28tpMP4VT0ZcTufWp+9pPeUcpjQofIjqI6ZDbYlRk4d3wbLI5VLZ8tSlv8j1RvnFpwmz1WkbZeAXkVinjwg1ioYrc3huRnxDHu9LrotxmwIlzFU1+sK6YvhNPdWRYxBBwADuj4E9bnLvYBRxLC/G27cHUdjv043It2czmMdy06gC27pfyOKB1pf29YM/lqR9qg23+C/YEkOeM7x0FZhYfGG9ZDLEgXRjrNFwJ1jjFMnO99keAVnXUCWKwKQQvKYvJ5hLtKt/6w2KY0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(1800799024)(376014)(7416014)(23010399003)(366016)(38070700021)(10067099003)(56012099006)(11063799006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?AfTBI+VV/scDJLElWdKL81+l8zYX1kpleurUfflmt/Sq64S/pYMFw/FdEk?= =?iso-8859-1?Q?CSc+3KkPmxKTSPR3WDOZbcqHZL4+2JQ26ChAfNITFAF6fhGuC0pS9bIUlO?= =?iso-8859-1?Q?9Y2h+0BixBcUiROJ+OwHILDvxLW1HmeiIXcqzbsyCW3Ee2kc3OeG4ve3M3?= =?iso-8859-1?Q?u7yKdjJTYXZZCmGJ1Pvu1J+FASdg1Pol20LQEJmEJvtval8i0w2VgwYxW0?= =?iso-8859-1?Q?IF3s7Xfy86Ru5xs829R3/0QhBZUqOvaIKokHnGO4ACVH1rmlJwnpDeqNYf?= =?iso-8859-1?Q?cLbSIyfQjBElyge3wBNpaw6rqbCkNh0eMWiB2AkB0iTeI2pu6QMhLtairZ?= =?iso-8859-1?Q?0RZHEOJjCGfjn6BBUH8xwNP8eeIVe4WlAlB95Erk4Q5iE9ejI17b7Gfruk?= =?iso-8859-1?Q?GlFFMSGoZKjPDKu1uZjypkP8tjr4zvzbRzewHxax3D3pmib4yL2FQZH5p0?= =?iso-8859-1?Q?6f7QMCh1faolk+qW7olBR7GDKBsWxHpLpxUvVnxjxz/dquzpLghONIuX3v?= =?iso-8859-1?Q?OgZDzZBHAJK2GFQvm+ajdAdpuoNm+m5MNJCuQbb9fu/LecFrNVyXmC+rPN?= =?iso-8859-1?Q?B4zKUAmtOZw5gnKDLkF3y4euo72f9PfjRIQVfLqAq2auxh6l9UIJ9EUVHC?= =?iso-8859-1?Q?Fabv3DXDTeAzQKtmFHPor4k1yegsQzTraYGE+fpzm8VMTDGAMDKF//Igdl?= =?iso-8859-1?Q?GIif+zxICnbQWKXRP9lvNV/zs6s96vte5TToFN1GbNOlbH6Z4kk3eCRQ//?= =?iso-8859-1?Q?vtJi+nDE7gso85f7vg1MjtE3YnvRLJ0FnSSqzyplDEUNW23si8Lx2yIuoH?= =?iso-8859-1?Q?169NIUgzYNgV2DBOCCDhdrUy2nT2nIMuJvGAkDC04D++ytjrGcWP48dGVM?= =?iso-8859-1?Q?S8A5gZdl6yigt9LPLH8xwQzTzkyCw4UW4yvc9BL6TiJ9sHT3EE+7iQJ+1s?= =?iso-8859-1?Q?MYuHalvGLhI9MFO1JGDuupKRgBJcpqZVPBN8sRGREksYG3/Bq0yT9qsvEv?= =?iso-8859-1?Q?U1BrI+JHfQiN4dbhtLy5lTNX0W3tgiVIN4eGH7Q3nkxD6WxFo1ML/eVkqp?= =?iso-8859-1?Q?1bwsrrlBRc4nu9Uup8zqUi1iPYhPp+B1mLYag3P2uC2ZwCEl742XeVBlSz?= =?iso-8859-1?Q?vXdvbyvwkl2VU7uNg9cKhC5XP0ChHlMHJ9ghnDnOY3ZCbOmXLgPIaLB2nN?= =?iso-8859-1?Q?3N/Y9P5pNIailewc/4f3yisSmUiW2+/XvOuFhcSbMQMmLV8hodTBnCtqiI?= =?iso-8859-1?Q?8P9R5HwBTDTcunp8LF9wBCo3Kaw+97eI1ROQcnLi/bBf1z1YiNMSUAzH64?= =?iso-8859-1?Q?5kRRvuAX3hNwft60eQ727inedngW+erMMVjgT/01bYqCK9Fi6bYJmVtr+E?= =?iso-8859-1?Q?/a1799V/ywZjvdk4eUqy46O1JcQ7hVptZ3QbKrKmWk6gSil4EwM39aV8vk?= =?iso-8859-1?Q?menhjMm5acjUH/m5ayDfXyorwg6vBynxGjddRYzs7LF96mWKuc44zbp1xb?= =?iso-8859-1?Q?2fhruFfSqfcmAbZmpTEF6YuJMrE/bflXD1VEV8BHcMibabwFtpAwbSqZXl?= =?iso-8859-1?Q?Wt5WULF4s2ffJQ7askwH/K0/Di3jH0a1SkBAiU1badK4oIDWVtG9ZfX14F?= =?iso-8859-1?Q?J1DToH5GbDpd+stXINGgC6g1mHRmMH00qEbeUwgCDrCSG8UHubbJ1ty0/i?= =?iso-8859-1?Q?r2+7aQGMxKCHTpV8R3iw97yLPfnEv2XDRbX+y8flYVnaeEskrt93RQ1iH6?= =?iso-8859-1?Q?wkmSNSPXOzeQD54UWHTmjQ0Q2ySG3I3Y2cO6kLUzHj9IQc+9tbetQn2lq1?= =?iso-8859-1?Q?YSvIN0VQ282V0nKlm7pkxhH3BFJAysM=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4e3107a-cd95-4bf9-12ff-08df18984717 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 10:57:21.6163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 20iVXIVqG9yEA7aWAwm7k/yx7PpX9GIQ36FOcUT1i44qFuWQ8mV5C1G2H9OAYoFYyKLArNDdAwep2BGlSO/E0RWAbkxryufVnSVpjnEOCac= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB10189 X-purgate-ID: tlsNG-c201ff/1790074650-716AD2A1-4CDBC1E8/0/0 X-purgate-type: clean X-purgate-size: 1642 Hi Jan, Jan Beulich writes: > On 22.09.2026 03:38, Volodymyr Babchuk wrote: >> Jan Beulich writes: >>> Outside of drivers/acpi/tables/ (which is excluded from Eclair reportin= g >>> for dubious reasons), arch/arm/acpi/domain_build.c is the only user of >>> ACPI_COMPARE_NAME(). Make the macro const correct, at the expense of >>> introducing a "const" variant of ACPI_CAST_PTR(), and at the expense of >>=20 >> I think you can avoid adding ACPI_CAST_PTR() by providing a const >> type. Like this: >>=20 >> +#define ACPI_COMPARE_NAME(a, b) (*ACPI_CAST_PTR (const u32, a) = =3D=3D \ >> + *ACPI_CAST_PTR (const u32, b)) > > I don't think so. You did notice ... > >>> --- a/xen/include/acpi/acmacros.h >>> +++ b/xen/include/acpi/acmacros.h >>> @@ -103,6 +103,7 @@ >>> * Pointer manipulation >>> */ >>> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) >>> +#define ACPI_CAST_CPTR(t, p) ((const t *) (const acpi_uintp= tr_t) (p)) > > ... this, I assume. On the surface it looks odd, because one would expect > acpi_uintptr_t to be a scalar type, like uintptr_t is. But it isn't: > > #ifndef acpi_uintptr_t > #define acpi_uintptr_t void * > #endif Well, that was unexpected. Talk about principle of least surprise... > > The only alternative I see (somewhat more risky overall) would be to > introduce > > #define acpi_uintptr_t uintptr_t What are the risks? I'd really prefer to have fewer gotchas in the code. --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:01:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:01:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428640.1651533 (Exim 4.92) (envelope-from ) id 1x8yFa-0000IN-Kh; Tue, 22 Sep 2026 11:01:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428640.1651533; Tue, 22 Sep 2026 11:01:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yFa-0000Gy-GG; Tue, 22 Sep 2026 11:01:26 +0000 Received: by outflank-mailman (input) for mailman id 1428640; Tue, 22 Sep 2026 11:01:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yFY-0000FB-Sa for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:01:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8yFX-004CEG-CV for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:01:23 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab25ffa-e002-0a2a0a5209dd-0a2a4503ee46-26 for ; Tue, 22 Sep 2026 13:01:23 +0200 Received: from [202.12.124.158] (helo=fhigh-b7-smtp.messagingengine.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab25ffd-fae8-0a2a45030019-ca0c7c9e852f-3 for ; Tue, 22 Sep 2026 13:01:18 +0200 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id CE4EC7A0013; Tue, 22 Sep 2026 07:01:16 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Tue, 22 Sep 2026 07:01:17 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Sep 2026 07:01:15 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1790074876; x=1790161276; bh=MYygLDtPfb/W4acI0Ri+L3sAyA0P31Lk4K752AAwctE=; b= egsZNAdvumhi+WSmNtrFyNShRyCe8MqML0D9ML/Q6WeHOi4iEJk89cQL/lVZ/tNI kAM7/rrZpNETvpoN/Tau9WDOyrbm8fNLjPC0k6VJ5QKheVH429CiTUHCkh+kyYMX DJrGOLv9VZXR4eEEoI5jLC2tPEAbhdKPZR6vSQjLflZVzhSkGcmAejqM1okg9+j3 ARK3XF9sh6usglrVTeHTpjpB+jL3I3W1uSXII4NbisB8GtsMxiK9Nw/6MVQFG3Kp 642KKKLWoh8Hb6up/zlwnrPQ6Pt88PGZn/mnDe9WV3iOAPjCP5f0UeX/Vir0UtgS AMamFVCGwNrIHuaiGpeuLA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1790074876; x=1790161276; bh=MYygLDtPfb/W4acI0Ri+L3sAyA0P31Lk4K7 52AAwctE=; b=htGiZLzJMd6IA/Kiqcyd99bOLhnw9pSWbQkEFlg+RMmr84sXCFy BuM5c1cYy1QREifVBfn7dAoJ1+dDr/FPFq4fl6eSU3knu2ZjNbvuS1v57iBG9OXO pIgJ+GF37v35erk2eV0PqGQcWw5ubo11YxBEp2wjLlvklKEPVmfYGQUQ661Rr2at kBTGmJqxtvyfPSmx0KRJE9Exc5kykNeO4qBbTXIYiDHRCp1kGzK9wQ6QSJHQv0sB 2dfIgo1saGsujMlJuxV5kTz3POSe6QdSLgt3nxyfkSUYN9ob0mZM+iQarJQksUo8 DRReI3jYrF/9Qef/i8vxoMlYGFPnkChsqeA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTE/CnSKbM///aIgkuD5hcBJHRSc1C2NT3P7sThk0KXRWii2XGNS4/3nW8BtwVlnQf 7hOVZJANrqzgKgprEgxGPySg17ZS6opopFGQdlXN7pQMI0hRw455OKq8RQ9Ge3IyDjNZGC tQybyunHLNgRimMVeV9gAgr9h8mua9QqV4LvwTyDUEEGhJQaHIZY/5TBcGqZy107ybyzwx /cV8A1mtcdp2xFIdQvJwiLfdbjE9fCmd2vfcBuTF8JG9bg+B70Y/LKRj9hBE2HChKvmEqG sJnZA4HGPKWxrEz1juwhT4YRCbTUd+VvZQ6wHeSdfoq0FB6uDjZO6hMavx/k+RQkOu71kR lGjQB8cZjH9THYkWrGvVRQTKWNbCnbtqDbGOPoqqPHUBOtBoLRPCRGevgIE1Urygi0cIBI QN+Z5MUn8sJhy8ppySB5mIMvbupQA9qXJyG4acm7oHumjnTmb4InjSqS3b3prHAYdCxDxA 1Qt7gZHQIsMBG0TLzgU73CyR5L4kLYttMngnAk/iL3AUJCoq1c7JZqraAUve7n3iUnwVfO RFn5Lij4WEBoWyUmOmlQxQxgkOi82cISjU7Wj97Vu8p4tZ4K110fByQ6N8iJ33pocxVjY1 CrLLd4keFsxV5sR9+T/D3Hj8g1syC5Vnt+e0vJaVeHs/nZ44AkSL2MBLZGlg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 22 Sep 2026 13:01:13 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: Re: [RFC XEN PATCH 00/13] Running bare-metal tests with "pytest" Message-ID: References: <20260922100900.29129-1-anthony@xenproject.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="culn7o+zK8dyCUbi" Content-Disposition: inline In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> X-purgate-ID: tlsNG-33051d/1790074883-6F4C74E9-F1916DE1/0/0 X-purgate-type: clean X-purgate-size: 4949 --culn7o+zK8dyCUbi Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2026 13:01:13 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Doug Goldstein , Stefano Stabellini Subject: Re: [RFC XEN PATCH 00/13] Running bare-metal tests with "pytest" On Tue, Sep 22, 2026 at 12:08:47PM +0200, Anthony PERARD wrote: > From: Anthony PERARD >=20 > Patch series available in this git branch: > https://xenbits.xenproject.org/git-http/people/aperard/xen-unstable.git b= r.ci.bare-metal-with-pytest-v1 >=20 > Hi, >=20 > I wanted to add some new machine to our GitLab CI, but I didn't want to > duplicate yet another time the existing shell script. They are good to ge= t the > ball rolling but are getting harder to maintain as more test are been add= ed, > and don't share common code between machines. > > So, I've start work on something based on `pytest` which I hope will be e= asier > to maintain and extend and use to add new machines. Nice! > It's still Work In Progress. >=20 > Here is the current result: > https://gitlab.com/xen-project/people/anthonyper/xen/-/jobs/165291076= 19 Minor readability improvement idea: force color output of pytest. > In this pipeline, the artifact use are a bit different from master; linux= is > built with network driver, and vlan; the rootfs is from Marek's patch ser= ies, > with networking and dropbear service enabled. >=20 > Next: >=20 > I'd like to at least have a new fixture that give a started Host that a t= est > can ssh into. Then maybe a new class "Host" which could have functions fo= r ssh > and getting the serial console output. >=20 > Don't go to much into detail review, I'm more interested of a general ove= rview, > and to present what I have so far. We had a design session on this topic, and we discussed a structural change: have one job per Xen boot flavor (mostly dom0 PV vs PVH, but could be also other settings needing host reboot) and then have pytest run several tests via SSH. The idea is to not waste 2-4 minutes for every ~10 sec test. Yes, it does mean one failed test will likely prevent others in the same job from running (especially in case of Xen panic), but since the intended state is "all green", a single failure is bad already, and this approach should still get you enough information to debug that first failure. In practical terms, it would require most fixtures to be class or session scope, instead of the default test scope. And using more SSH instead of baking tests into startup scripts (already partially done, but may need extending to domU commands too). Other than that, this approach looks nice, and I really like using pytest here, as it makes the structure significantly better. This will likely require a bit of adjustments to handle also other hosts (for example for qubes runners tftp dir is mounted into gitlab's container so there is no need to sftp boot files). But that should be easy to do later, it doesn't change the overall structure much. > Some runes: > - uv run mypy . > to check the code, at least the types used. > other code check could be added, and run by the pipeline > - uv run pytest > to run the whole test suite > - uv run pytest test_boot.py::test_xen_tools_tests > to run just one test >=20 > I did create an Arch Linux docker image with pytest, but paramiko got too= new > to be used, so I've started to use `uv` to deal with the dependencies. `m= ypy` > always needed to be run with `uv` due to missing types for paramiko (not > packaged in Arch Linux). So the image is useless, and I'll look for a dif= ferent > image later, for now just Arch Linux with `uv` installed. FWIW Qubes tests use Alpine container, seems to have all what we need. I see it also has paramiko 4.0.0 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --culn7o+zK8dyCUbi Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqyX/kACgkQ24/THMrX 1yxZBwf/TrOqGCDo6Oi5bGk+C61cwMP0zgcVH1gyo//GF9K0QU58qOZBRwYWfkfv U5hUXvroj8VngUwK/IfGCO3MH8dKkLiSKWFKmO0ajSZBi5BraxHqqzQ4xsZkwfEO 281f5wuqSCAsPod+sVT/M3Wl2Y1FxwL6NP9WZEvHHIRX1dm9aChV4INiO3NLmwN0 jJguLBebbo3tyZOVtvAhOmvoUJJkhM39N7dxAXJjNuo2Nv0Nd2ZKsaC4xfgzSTgl kaPyrXUrmm7dcqFcyZg3h5UuJs3BktSqIAYRo20yBZr4+UFB2BIZeUWNPoVOR3If 3U9ZTEFZZRwV6ugRWogMk90BEFN08g== =7MrS -----END PGP SIGNATURE----- --culn7o+zK8dyCUbi-- From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:01:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:01:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428639.1651529 (Exim 4.92) (envelope-from ) id 1x8yFa-0000Ff-Cu; Tue, 22 Sep 2026 11:01:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428639.1651529; Tue, 22 Sep 2026 11:01:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yFa-0000FY-A0; Tue, 22 Sep 2026 11:01:26 +0000 Received: by outflank-mailman (input) for mailman id 1428639; Tue, 22 Sep 2026 11:01:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yFY-0000FD-RT for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:01:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8yFY-00GAup-8B for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:01:24 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab25ffd-2eae-0a2a0a5409dd-0a2a4508b902-48 for ; Tue, 22 Sep 2026 13:01:24 +0200 Received: from [52.101.83.122] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab26003-f659-0a2a45080019-3465537a834e-3 for ; Tue, 22 Sep 2026 13:01:24 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AM7PR03MB6264.eurprd03.prod.outlook.com (2603:10a6:20b:13d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 11:01:21 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 11:01:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b3tpahzainPqapkGEh7njg4BaCpLABpZpT7tH4S3NgEWao/c7JbIVVvhnomRCIezWoEb6PjuDmrwwx5zmq+nUSFAPT4NMe0PhNkEhCOj5m+YYX12pDi7DolpL/Sa+Z8tCQnoz0LrVjXOo4KDexcb0IQaGQWImgsfsnaXlE65CP++U812tpVCd7y6UF+uOjeCcp8vK8PEwxVRmHylaUBCP5/BAtFQxt+kIY2pN9hAvxdn5oxnzfHkdQtJM8VWR+KYYat/DARDLgTGRg0+8cxYQtVowGXDdON/mVfrPm72K0AWRWwF2sOLd60Osos9F6gRLh81DzpPKwoOXu1aMa1S3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V3W5tUjS+MCwugElpeUBsmEcQeNOhcCMCJZ7r4GSvwY=; b=fN+q7pf8XcB0VQLosIdXzXmCt0RfYSyksXcCsNtjr5uGoOUXDpP3UiH31/k3DwEfkrfv8rpWZS0BIVMxsf9WJdHRoaxzSlEFbVxrtEIxbFGE1LynV52dFeAS4j8rqctjcWHn8oyoRLJHwBC5gv4W8K5ztAM7scG7MToGg9afq8mYnWVxphw4B82++WhbnY2KKkOzBxzwwUHIaYHTbrOA8PXsGwI93CrEpfPjYLiSlHPwM8sbttKzvyTFOTNRv8Gge2op0JsKlEI/t1mpoAvZK2bsCgwjXixAerNoZIGc2sIMduJRsevU2GWex7e5Q46jOP7N6x174emChb1tNZeSPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V3W5tUjS+MCwugElpeUBsmEcQeNOhcCMCJZ7r4GSvwY=; b=Ay9sssYUrTGbzahlMTK9wK1Z7PXVYwh8jKt2iGRRrgAqBtLNgMLOG2jDqqjZoxWWR6mnqnbX8Z5KDtR73fXj1SM2eu/isJZO3fH7wauhqatARwOwM0c37LLfUq7G5g85Oljfo4FwzDNE8AwHSJg3JtYX8bs36qjR+9Nvwy4QtRrQeCvugnYjq0sY8Y6oLdsrtc6hvaa/zqmUUIHr9p1Y/S2IyfiqTnzvFcuHTs1cqAjr4YC3cv7r/sQeknIgt80Vhdrbp+8RlaBzaGkP26dRWKjr2heQdKsIOmMGaPiRe3JYWLL3MpSK/1YKnnhwMBkeC6eoBlnmZSPtlt3NTZZ0TQ== From: Volodymyr Babchuk To: Jan Beulich CC: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: [PATCH 10/14] ELF/notes: use pointer-to-const by default in ELFNOTE_...() Thread-Topic: [PATCH 10/14] ELF/notes: use pointer-to-const by default in ELFNOTE_...() Thread-Index: AQHdOqU2Vkz5DOI+4USs/ahFyLHJfA== Date: Tue, 22 Sep 2026 11:01:21 +0000 Message-ID: <87pky55z3z.fsf@epam.com> References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <8fe86787-7590-44f1-be4f-461b61d7669b@suse.com> <87fqz26otq.fsf@epam.com> <162997df-6c5f-4f1c-b01f-16f6c2e4e0c6@suse.com> In-Reply-To: <162997df-6c5f-4f1c-b01f-16f6c2e4e0c6@suse.com> (Jan Beulich's message of "Tue, 22 Sep 2026 08:36:23 +0200") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AM7PR03MB6264:EE_ x-ms-office365-filtering-correlation-id: 644e0546-61d5-42f9-4c52-08df1898d5f8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|42112799006|38070700021|3023799007|10067099003|56012099006|4143699003|11063799006|22082099003|18002099003; x-microsoft-antispam-message-info: E/7fZkwLIFS8RF5v6qMyDsrbsZqghdoTjb37ySqqh0zi1uSskloHDkRtOZjAxanqY79n5c7IeDlSyIK5oF96NniW0GtIz1L5BPEv+Zcqc0xGZ+1jpOTzyH9WXUKNwatpJmFBZHrHcHS2XcIu6YAs2wg1YgY7Tk+tmVezalCxsHkTXvm5xkarCrlRObB3ZnXE0SwjSd3LeOHTlbIruD2qMGMSOmIN2APiH2tnnt5YDbjuNos4wt7fkLfBWBxc8FrQz3+6J46MF+veI2tLBRGLqQHrIusg7xv6MmUKunkFP6UOL+xKQVfXLqyU7+RCCY8xkr044hvUX6WykoPgIYV1+P2Qoa6DK5aIYN4l/SA92S/NgWPhd4Go+n6l/ZmVtQQj2SB52dFGpYaEcWsPnmDYyHivF0AEs9HNJxaxL2dWMfsmQTlmpRATOvO8iXVPtric5NlMcvChc804uT74V261viqkpoxBZ/LqZnOitg8evvyziFnQjiOwRZfeSWdDqIFmFKiv9RVbLdhCZRV4nCNVB81l/0yuPrhtqfgon1ac2j2YO0MoCyaVQO9vxW+OV4BCvn6Ca+X4LoGM/rJkL49D1XzBk0oZNc4X8ztjN17Q7+J0pfmZ7pgg6TadQ34mAEQtJ9LoW8SU6HOC4ex2fG4pwBr7XA+r2VyORKYxX8uP8M6rXX+uR+/ceSBaZ6vftb3QuAWZNuJV1wwXX8oR7CwlBt4kfikewHtRRWBKw8G8Wpg= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(42112799006)(38070700021)(3023799007)(10067099003)(56012099006)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?fy1yw15Eh+f+hHE4O61nYQiy++uq/0m2JpWAfuEXsVsRKr15+mHTSYHp1s?= =?iso-8859-1?Q?G/RlwY6wQu1xCeZ3V9jbvG9Od3925kGOuGarUHayKnbbM+CGrt3D+4R8ly?= =?iso-8859-1?Q?79BupW9lBjaJ1+UHMSiEINZZ21HxG/sII8JSE28xTKLwBGF6kNbRxpvPiZ?= =?iso-8859-1?Q?nFB8fwno4c4GYmzUe3zkyg5b02CRsttMf/31+MyCwVmph/S58k1mGNF0ph?= =?iso-8859-1?Q?SaS1/bqS9CE+nYeZvbBD8YHq9BwJ83AM41HLXtYaPMssKztObI2cWKsLTq?= =?iso-8859-1?Q?VmWWOnpgKZzX4xMJk7qKRQv809f7q/560SLRf47xyscTgEMwMEZiy8HgL8?= =?iso-8859-1?Q?1WOWQIWi7mpFHYn9Y+lyImTgKmR/BXnMXtilIxWRcPLzMzx3rfX4r6jKOa?= =?iso-8859-1?Q?c2CjpDoJzp5gzUCuizpAa3jstH5PYUatU2jjJiyVWMM0Y8CW43Hkz6guvy?= =?iso-8859-1?Q?yAUNfn5Dv7p9do/4Akauf4O4j88j8nCEZ2qDm3kVlIWvBLovkHPVdrKofB?= =?iso-8859-1?Q?gHD1xkfoRnUiVkzrAZeIi/SVOVUxipkQFUgXjAqPmW4XPY+foqUnIiHmxb?= =?iso-8859-1?Q?f4sa+jEba2pGmJyJPV1bvq6/u9aCQlAydlKiBwkkm71pJa+8vGfUMYVlgr?= =?iso-8859-1?Q?GnyFHNjoGVHUd2sUS3X6bKD81+caa7OP98Q/+GcNIHgO+y05R2837fPzir?= =?iso-8859-1?Q?lNhdl/V22R41qqdRSNk9aks8FdJGlYCBOzufOsKzOyStgFHUTOi1AbBd8q?= =?iso-8859-1?Q?HShMi3j8NijP6flItWN/YIxb7kwzCcPm4/4kcgTT7pbUJCDXTIeW1Sb+HC?= =?iso-8859-1?Q?ZGtpHj/Ak1sm+c6/uG+eL3JHpih19aR9RzrQeJ6eLTvKurTU1WKXQqLKRZ?= =?iso-8859-1?Q?43cWfrjkWIQq6WozRqFRjuNIjyR9d/a11zoaC7O4hFAqWwQ+016jL4Vlvt?= =?iso-8859-1?Q?ovYNmSrhB33UaKngstCLZgpxhJ1vR8EPdaRk5kAfFF6AA7EPJG1iOmV/vV?= =?iso-8859-1?Q?C+HQ3nZNUQEYxgpqt+61cdgVJvZoak9aj+Y/dg30KWu3r8EpSm/9y3XA86?= =?iso-8859-1?Q?cL5I0vosH3ddfo3N54Vg2gLrMqTB+peUNm3f+DFFY3LDFKp76QlZsFTnWS?= =?iso-8859-1?Q?48QPtB9UAiMS+QygBky/xXf3Iz1jvhIF5qvyhKIe19USd2DzZ2cE/8UIhl?= =?iso-8859-1?Q?ELJn7Y0EIDLIBNQYM4BPxQwhHAXLlW6Zu8eFlAySK08YSnsNUNk4hO0Gno?= =?iso-8859-1?Q?i7fdydawiTlhOZ5TSAe2gjqa/w47vKOYTNBg0WHPvysSHDq+xDimipl3m8?= =?iso-8859-1?Q?ZrmdiOKETY6+kBeIyOzSA/L+ViXh9UG3D1AUSMTBM1pMmtUy3qhn1A/fEN?= =?iso-8859-1?Q?huc3zX8v0UD8+cg/g06I6YshGzhseK8W6gTNbejAEHAy6lOTYWijCzO5rm?= =?iso-8859-1?Q?JSdlAFRVwep5n0h4mRHb/vQ5gGDxZaL2NjrT+5GLxflP3cArGp/+sx7cMq?= =?iso-8859-1?Q?0iPPkYJ16szSk2+AO7RZkq0qzZFsvFWRvhnGhjx595j1JP8dIYsE4F7LJo?= =?iso-8859-1?Q?4z2cv9YWg1HNofbGCEICA/Expg8zUGCTjuZkYdh9KImQgIJEStT8lRYROY?= =?iso-8859-1?Q?RdYHYz6mWzjnHkRIXJ3/sBPNEqkBkWGoh9Bu2ykOIYcl2i0xctCTQb0T3K?= =?iso-8859-1?Q?ZF6S2uw8iq8gqtIuiBfR+1j7VSrTyI0hmIwxDDZMTOD/QWW1Z7GStLRh0p?= =?iso-8859-1?Q?xERzij74x9XN6XV5l1snuPfHmtfTrcYuSK/on3Ua7BhbIKD88pq1jSWUnw?= =?iso-8859-1?Q?ktIc9kfWKyL31FUurQyvfNfxeXKZKWc=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 644e0546-61d5-42f9-4c52-08df1898d5f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 11:01:21.3386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QowOWXJip5k5jGfKSValRSm0fh38HsOCxLqustWeAZl6BbocqfbYw1IADDNab58ylMr1VoOFACr5xPhcvbmiazLrKII8+YUD6ISEeBp6Tww= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6264 X-purgate-ID: tlsNG-c1860d/1790074884-D4B7187B-3B676E4D/0/0 X-purgate-type: clean X-purgate-size: 1672 Hi Jan, Jan Beulich writes: > On 22.09.2026 03:45, Volodymyr Babchuk wrote: >> Jan Beulich writes: >>> Not doing so results in a number of Misra rule 11.8 (casting away of >>> const-ness) violations. We need to allow kexec to use pointer to non- >>> const though, so provide a means to override the default. >>> >>> For ELFNOTE_NEXT() we can do better and simply re-apply the type of the >>> incoming pointer. >>> >>> Signed-off-by: Jan Beulich >>> >>> --- a/xen/common/kexec.c >>> +++ b/xen/common/kexec.c >>> @@ -6,6 +6,9 @@ >>> * - Magnus Damm >>> */ >>> =20 >>> +/* We're producing ELF notes here. */ >>> +#define ELFNOTE_CONST >>=20 >> Frankly, it feels backwards. When reading this line of code I am >> assuming that you are adding constness to ELF notes because you are >> defining ELFNOTE_CONST. And I had to check the elf.h to understand that >> you are doing exactly opposite. I am pretty sure that other people will >> confused by this as well. > > Well, that's certainly possible. Yet then you or them are asked to make > an alternative suggestion. An option I could think of would be to merely > rename what is ELFNOTE_CONST right now, to no longer have the word > "CONST" in it. ELFNOTE_MODIFIER maybe, albeit that reads a little clumsy > to me. Taking into account that we need 'const' to be enabled by default, maybe something like that? #ifndef ELFNOTE_NO_CONST #define __ELFNOTE_CONST const #else #define __ELFNOTE_CONST #endif ? And then use #define ELFNOTE_NO_CONST in this hunk --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:03:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:03:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428651.1651547 (Exim 4.92) (envelope-from ) id 1x8yHH-0001GD-UM; Tue, 22 Sep 2026 11:03:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428651.1651547; Tue, 22 Sep 2026 11:03:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yHH-0001G6-RK; Tue, 22 Sep 2026 11:03:11 +0000 Received: by outflank-mailman (input) for mailman id 1428651; Tue, 22 Sep 2026 11:03:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8yHF-0001Fu-Ho for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:03:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8yHE-005R2g-R4 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:03:08 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab26069-e002-0a2a0a5209dd-0a2a4508a5cc-6 for ; Tue, 22 Sep 2026 13:03:08 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2606a-f659-0a2a45080019-4a7de18cbf37-3 for ; Tue, 22 Sep 2026 13:03:06 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd38e0f79so22436045e9.3 for ; Tue, 22 Sep 2026 04:03:06 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fdab8ae6dsm92707795e9.0.2026.09.22.04.03.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 04:03:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790074986; x=1790679786; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rWVdaKk7lkBV1zyykoxHG3CrUBeKB9NFkyrtNEOtJgs=; b=gq831bf4pL4e4cz0i+hQfSscCB10ibvogK+6eBu791/YiiPx28cxZ3EEG/Pj1XRAnq jstkee4Cd8RAvG/2RNOR7ALcHOcWrzrG1b65y6OhzgmemhLZlh+isDjd4ih8OekNE+w9 44jHiydoduAewe9z6USv8qfT4/rgUyNSsZmxHxSahvB7n7OGhx4f/e1MTXxmsAJpI4K3 KAOqJhYgMgvuobUmee2vTMy17cTYPnXQHK08KDIZGmIORa9ejCiTzzzfhETBKMS0/VQC C47ZKBbmPRp2uSaN6PSke3pEiETJIelTFCTXoOy6yZ8AHSg8bp/Za5WV5T5rqHtSSd12 6rCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790074986; x=1790679786; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=rWVdaKk7lkBV1zyykoxHG3CrUBeKB9NFkyrtNEOtJgs=; b=0SsqkDdBMhiOsWG9r7vTkD6YEartRi/dYmUZkd7RNx3UmJUa5yehmhry540uBY48TH 5fiqaZBgvvqho+oG9NtZ8U5D9JK9bDWw9O80WPosnPcP8D9grXqxfz7NydBRh/iqVqT3 8KguDqc0/nzF9q6ddBSee1Aa5QntAVMC3fNd6YC2czl9KP3viVMJzxLZ+EyCwXFnQXx/ Dl88OxeWLI6mJ3xVqavlcD1Qgvix8derr+4vhCXvZTJpcT7EpsSwWg+/ECq4lYX2Thkg G55EbQt+NSHSJ/eq3+UO4EGHkl6tNHk8ndRhYQOcyskqcGotwXmuOJ/cePq85bN9/qTy gilw== X-Gm-Message-State: AFuF++khIEJdk2f7Gpp5fwKSRwvakzvbFe+hEhO2r9t0CiPh6xzWw3lc olame5iO4MOKv+oN309d1HE8Ekb0fWIk/vwrSvgQlWsNeddkDTL9XLdH X-Gm-Gg: AYBFou0C1rCbiJ3GRCV/bAS1EDs+pBok16oAB57W5mgTkpODYnYvydTjp9vu0qqgAs3 hqpq8ZlCBZFenfOxgI6auztgthvoRDqjD+YQJe/5/v9VQ2O4shgF5JNALvr9yjPCKUsXn6A4CCF OCpwemYYVDQbs5ycBtOCjR9LWoxTbMcLN4QATUof0QYoL5azm7dTvwZNJUKk/V9ci4WD8fXb3a3 DyXa+UxJPMcFAEDJGIzoc2BcMfmuMhYim2QQmcclZT1ETPviVKT3FkmmVDK2Kx0x8j+vF/dS2IP YEDlyFVgoWZlGsvsfI/lKZCR1Xnj2E3pOT72X+fBO+juXMMDYT339iYutqJ5UvdxFQFsZCwXR4R P0e1kHjhXtrB1AKx8Iq5vCvOmUP5BCsuL0CeS6XHUVC8I2o7zywk/LQPwtIgJMl6QCwyG5S76ux h5jCPqRuAdsMsCkMK+88A2JcQubNbwaJQRlIEdhr3ESljfMKB2XEtb6laI4P9/3WRYBM1E5LM2e lL/3Jg1MtP4eLKHKzIfzVa7sLPA8ZvLSDmOB1a4lswAuNZ/rA== X-Received: by 2002:a05:600c:c16a:b0:49f:ce78:356e with SMTP id 5b1f17b1804b1-49fce7836b0mr139595575e9.31.1790074986223; Tue, 22 Sep 2026 04:03:06 -0700 (PDT) Message-ID: <028383a7-e806-4219-990b-c982b580edd5@gmail.com> Date: Tue, 22 Sep 2026 13:03:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 24/39] xen/riscv: add helpers for decoding a trapped load or store To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com> <1789721101.8631fc262581453bbf619ec5b2062170.1a0b3b0c3ad00072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789721101.8631fc262581453bbf619ec5b2062170.1a0b3b0c3ad00072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1790074986-CE94287B-223EC513/10/73395122804 X-purgate-type: spam X-purgate-size: 9524 On 9/18/26 10:44 AM, Baptiste Le Duc wrote: >> emulate_load() and emulate_store() will both need to obtain the >> instruction which caused a guest MMIO trap, decode it, and locate the >> register operand it names. Add what the two share, ahead of either of >> them being implemented: struct decoded_insn, insn_fetch_faulted(), >> decode_ldst_insn(), guest_xlen(), guest_gpr() and advance_pc(). >> >> The mask/match chain is adapted from Linux's KVM RISC-V implementation. > Nit: maybe you could add the Origin: trailer as mentioned in the > sending-patches.adoc. I think that I will drop that sentense as the code in v3 is changed pretty significantly so it doesn't too much sense to mention that it was derived from Linux's KVM RISC-V. Basically even if I will put Origin: now here then it will be still pretty hard to undestand what was used or not as I mentioned above there are a lot of changes done in comparison with original. I will take it in mind for my future patches. [...] >> + >> +/* >> + * Decode the load or store instruction fetched into @di, filling in the >> + * remaining fields of it (@di->insn and @di->insn_len are filled by >> + * insn_fetch_faulted()). >> + * >> + * @xlen is the effective XLEN of the guest, needed as >> + * the encodings which exist for XLEN=64 only must not be recognized for a >> + * 32-bit guest. >> + * >> + * Returns false if the instruction is not a load or store which can be >> + * emulated here. >> + */ >> +static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di, >> + unsigned int xlen) >> +{ >> + unsigned long insn = di->insn; >> + /* Register fields of the uncompressed forms ... */ >> + unsigned int rd = RV_RD(insn); >> + unsigned int rs2 = RV_RS2(insn); >> + /* >> + * ... and of the compressed ones, where the 3-bit field selects one of >> + * x8..x15, while the stack-pointer-relative forms have a full-width one. >> + */ >> + unsigned int rs2s = RVC_RS2S(insn); >> + unsigned int rs2c = RVC_RS2(insn); >> + > This naming are confusing because above you described di->reg to be rd > for load and rs2 for store but here ... >> + di->is_write = false; >> + di->is_unsigned = false; > > >> + di->reg = rd; >> + >> + if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB ) >> + di->len = 1; >> + else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU ) >> + { >> + di->len = 1; >> + di->is_unsigned = true; >> + } >> + else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH ) >> + di->len = 2; >> + else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU ) >> + { >> + di->len = 2; >> + di->is_unsigned = true; >> + } >> + else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW ) >> + di->len = 4; >> + else if ( xlen == 64 && (insn & INSN_MASK_LWU) == INSN_MATCH_LWU ) >> + { >> + di->len = 4; >> + di->is_unsigned = true; >> + } > > >> + else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW ) >> + { >> + di->len = 4; > > >> + di->reg = rs2s; > ... you assigned rs2s for a load. According to the spec, it should be rd'. > > I would suggest something generic to load and store. Maybe rxs with a comment to explain it concerns rs2' for store and rd' for load. > > /* > * ... and of the compressed ones, where the 3-bit field selects one of > * x8..x15, while the stack-pointer-relative forms have a full-width one. > * rxs is named after that field's spec mnemonic, rd'/rs2': rd' for > * compressed loads, rs2' for compressed stores. > */ > unsigned int rxs = RVC_RS2S(insn); Good point. It isn't partly applied to what I suggested in one of the reply to Jan B. but I will try to re-use part of your suggestion there. It will look like: static bool decode_ldst_insn(struct decoded_insn *di, unsigned int xlen) { uint32_t insn = di->insn; unsigned int funct3, width_log2; if ( INSN_IS_16BIT(insn) ) { /* * C.LW, C.LD, C.SW and C.SD (bits[1:0] == 00), and their sp-relative * C.*SP forms (bits[1:0] == 10), have bits[15:13] of the form x1y: * x is set for a store, and y selects a width of 4 or 8 bytes. */ funct3 = RV_X(insn, 13, 3); if ( (insn & 1) || !(funct3 & 2) ) return false; di->is_write = funct3 & 4; width_log2 = 2 + (funct3 & 1); /* * The register operand is rd' of a load or rs2' of a store for the * register-relative forms, both being bits[4:2], and rs2 of a store * or rd of a load for the sp-relative ones. */ if ( !(insn & 2) ) /* Quadrant 0: bits[4:2] encode rd' (load) or rs2' (store) */ di->reg = RVC_RS2S(insn); else if ( di->is_write ) /* Quadrant 2 (CSS): bits[6:2] encode rs2 for C.SWSP / C.SDSP */ di->reg = RVC_RS2(insn); else { /* Quadrant 2 (CI): bits[11:7] encode rd for C.LWSP / C.LDSP */ di->reg = RV_RD(insn); /* C.LWSP and C.LDSP are reserved with rd being x0. */ if ( !di->reg ) return false; } } else { /* * funct3[1:0] is log2 of the width in bytes, and funct3[2] selects * zero-extension for a load, while being reserved for a store. */ funct3 = RV_X(insn, 12, 3); width_log2 = funct3 & 3; switch ( insn & INSN_OPCODE_MASK ) { case INSN_OPCODE_LOAD: di->is_unsigned = funct3 & 4; di->reg = RV_RD(insn); break; case INSN_OPCODE_STORE: if ( funct3 & 4 ) return false; di->is_write = true; di->reg = RV_RS2(insn); break; default: return false; } } di->len = 1U << width_log2; /* * No access is wider than XLEN, and one as wide as XLEN exists only in * its sign-extending form: this rules out the encodings which exist for * XLEN=64 only on a 32-bit guest, including C.FLW for C.LD (and alike). */ if ( (di->len * BITS_PER_BYTE > xlen) || (di->is_unsigned && di->len * BITS_PER_BYTE == xlen) ) return false; return true; } > >> + } >> + /* c.lwsp and c.ldsp are reserved with rd being x0. */ >> + else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP && rd ) >> + di->len = 4; >> + else if ( xlen == 64 && (insn & INSN_MASK_LD) == INSN_MATCH_LD ) >> + di->len = 8; >> + else if ( xlen == 64 && (insn & INSN_MASK_C_LD) == INSN_MATCH_C_LD ) >> + { >> + di->len = 8; >> + di->reg = rs2s; >> + } >> + else if ( xlen == 64 && (insn & INSN_MASK_C_LDSP) == INSN_MATCH_C_LDSP && >> + rd ) >> + di->len = 8; >> + else if ( (insn & INSN_MASK_SB) == INSN_MATCH_SB ) >> + { >> + di->len = 1; >> + di->is_write = true; >> + di->reg = rs2; >> + } >> + else if ( (insn & INSN_MASK_SH) == INSN_MATCH_SH ) >> + { >> + di->len = 2; >> + di->is_write = true; >> + di->reg = rs2; >> + } >> + else if ( (insn & INSN_MASK_SW) == INSN_MATCH_SW ) >> + { >> + di->len = 4; >> + di->is_write = true; >> + di->reg = rs2; >> + } >> + else if ( (insn & INSN_MASK_C_SW) == INSN_MATCH_C_SW ) >> + { >> + di->len = 4; >> + di->is_write = true; >> + di->reg = rs2s; >> + } >> + else if ( (insn & INSN_MASK_C_SWSP) == INSN_MATCH_C_SWSP ) >> + { >> + di->len = 4; >> + di->is_write = true; >> + di->reg = rs2c; >> + } >> + else if ( xlen == 64 && (insn & INSN_MASK_SD) == INSN_MATCH_SD ) >> + { >> + di->len = 8; >> + di->is_write = true; >> + di->reg = rs2; >> + } >> + else if ( xlen == 64 && (insn & INSN_MASK_C_SD) == INSN_MATCH_C_SD ) >> + { >> + di->len = 8; >> + di->is_write = true; >> + di->reg = rs2s; >> + } >> + else if ( xlen == 64 && (insn & INSN_MASK_C_SDSP) == INSN_MATCH_C_SDSP ) >> + { >> + di->len = 8; >> + di->is_write = true; >> + di->reg = rs2c; >> + } >> + else >> + return false; >> + >> + return true; >> +} >> + [...] >> +/* >> + * Width encoded by the MXL, SXL, UXL and VSXL fields, all of which share one >> + * encoding. 0 is reserved. >> + */ >> +#define XLEN_FIELD_32 _UL(1) >> +#define XLEN_FIELD_64 _UL(2) >> +#define XLEN_FIELD_128 _UL(3) >> + >> #if __riscv_xlen == 64 >> #define HSTATUS_VSXL _UL(0x300000000) >> #define HSTATUS_VSXL_SHIFT 32 >> @@ -896,6 +904,8 @@ >> (RV_X(x, 7, 2) << 6)) >> #define RVC_SDSP_IMM(x) ((RV_X(x, 10, 3) << 3) | \ >> (RV_X(x, 7, 3) << 6)) >> +#define RV_RD(insn) RV_X(insn, SH_RD, 5) >> +#define RV_RS2(insn) RV_X(insn, SH_RS2, 5) > Nit: format > I think it looks like that because tabs are used there instead of spaces and tabs are there because it was orignally taken from the project which uses tabs. Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:14:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:14:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428667.1651555 (Exim 4.92) (envelope-from ) id 1x8yRm-0003eP-Ul; Tue, 22 Sep 2026 11:14:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428667.1651555; Tue, 22 Sep 2026 11:14:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yRm-0003eI-Rz; Tue, 22 Sep 2026 11:14:02 +0000 Received: by outflank-mailman (input) for mailman id 1428667; Tue, 22 Sep 2026 11:14:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yRl-0003e9-Ot for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:14:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8yRl-00H0l9-5d for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:14:01 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab262f1-2eae-0a2a0a5409dd-0a2a4505c8aa-20 for ; Tue, 22 Sep 2026 13:14:01 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab262f8-4cb1-0a2a45050019-b9ff1c128281-3 for ; Tue, 22 Sep 2026 13:14:01 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c8d2938d00072c4.004 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 11:13:58 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id D0B1681EE1; Tue, 22 Sep 2026 13:13:57 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=Bc983mqIN/OhEzDtgmkssTtzYaGestV8BVI0ZDrJsxk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=BsYiyI9yhNcvUiSPbQaj4luzL8s58y269IOjh5RHsljL9IQhFJfNLIXyDHhtApA/zS1oYOt4E qWvD9SKDmYMvnM29Z5hzH6znWX3QycZontwEQGqjxDpLqInktYiRUcCkoXJBkdC1u3sB+6o7cOV sMw8R73pyi1AN/whCXY+IR1mLaVkMzNoBEUOFq0Xe1J5P7F1TzlYqQmi119OBgqYf6Z+KmffaRc zpIU75FTcD1vymdKc088E/LQvQOfeMQ4etmdpV/PKf/yvFq8Oub7OfAhYHtbxMavjlCHPvApr/f VChcWpKp+1PBoyMecP3dnn0Id1rKifeDJZ7NxltXDFiA== X-Zone-Loop: a7de05ac8a73b9eed75b57e0408ce8ac93261dbce1b1 x-campaign-type: default x-transaction-id: f2216b80-86cd-4816-b31b-8a38f2e3bd66 x-swg-uid: 01-80e48890-03ee-44e2-8077-504920db1cb1 X-Mailer: Sweego Message-ID: <1790075638.8631fc262581453bbf619ec5b2062170.1a0c8d2938d00072c4@vates.tech> x-swg-bid: 1790075638.8631fc262581453bbf619ec5b2062170.1a0c8d2938d00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 2/6] automation/qtb: add jinja2 device trees for riscv64 smoke tests From: Baptiste Le Duc To: Alejandro Vallejo Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini In-Reply-To: References: <1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech> <1787823788.8631fc262581453bbf619ec5b2062170.1a0429a1050000c4f3@vates.tech> Date: Tue, 22 Sep 2026 13:13:52 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790075632; l=8595; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=h+kSThFqulh0xhQbSa4PKy+YKm1jgEnMVYDMs03cUOg=; b=qqjCzbr1Nnq+cY8JsHPAGCi3nBFHQ3lD043vdSe5Ib1cnpIpCht6IQOhhJ5NvWBcZyW1UNA8H xyY0p1zn2tEDYPgcicIskbTzbF+ubPA46IdU2nSya5ozCyTJ1yfRURU X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790075637953 X-purgate-ID: tlsNG-c201ff/1790075641-F5EA92A1-A8744F0E/0/0 X-purgate-type: clean X-purgate-size: 8599 On 2026-09-21 16:08 +0200, Alejandro Vallejo wrote: > On Thu Aug 27, 2026 at 11:42 AM CEST, Baptiste Le Duc wrote: > > The dom0less RISC-V smoke tests need a host device tree describing the > > platform (CPUs, APLIC/IMSIC, uart). It varies per machine (hart count, MMU > > type), so a single static .dts cannot cover the test matrix. > > > > Add dts/qemu-host.dts.j2, a template of the QEMU virt platform in > > aia=aplic-imsic mode: per-hart cpu/cpu-intc nodes, the M- and S-mode APLIC > > and IMSIC pairs, CLINT and the ns16550a uart. It takes ncpus, mmu_type and > > xen_bootargs as arguments. > > Alternatively, why not query it from qemu itself? See > "-machine dumpdtb=dump.dtb" in "qemu-smoke-dom0less-arm64.sh" This matches what we had originally downstream. We found it easier because using a template avoids a series of fdtput calls to add passthrough nodes such as fakedevice nodes that will be introduced in next patch series which are used to assert a manually triggered irq reached the expected smp. > > Then you can use fdtput to add nodes as needed, with all hardware being > consistent with QEMU without undue magic replacements. Having a > configurable .dts seems like a silent mistake about to happen. > > Check out that file of arm automation for DTB manipulation. I think it's > best if all DTB ports behave the same way. > > Cheers, > Alejandro > > > > > Values QEMU hardcodes are set as named constants matching their source > > symbols (QEMU_UART0_IRQ, QEMU_IRQCHIP_NUM_SOURCES, ...) rather than > > open-coded, so a QEMU-side change is easy to trace. > > > > The template is inert on its own: the generated dtb will be used in next > > patch. > > > > Assisted-by: Claude:claude-opus-5 > > Signed-off-by: Baptiste Le Duc > > --- > > .../scripts/qtb/riscv/dts/qemu-host.dts.j2 | 160 ++++++++++++++++++ > > 1 file changed, 160 insertions(+) > > create mode 100644 automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > > > > diff --git a/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > > new file mode 100644 > > index 0000000000..13a8e983ce > > --- /dev/null > > +++ b/automation/scripts/qtb/riscv/dts/qemu-host.dts.j2 > > @@ -0,0 +1,160 @@ > > +/dts-v1/; > > + > > +{#- > > + * Jinja2 QEMU "virt" platform device tree for Xen RISC-V tests. > > + * > > + * Interrupt controller: APLIC in MSI mode + IMSIC > > + * (QEMU -M virt,aia=aplic-imsic). > > + * > > + * Rendered by xen_dt.py. > > + * > > + * Variables: > > + * ncpus - number of physical harts (int, >= 1) > > + * mmu_type - Xen host MMU type, e.g. "sv39" (string) > > + * xen_bootargs - Xen command line (string) > > + * > > + * Per-hart nodes are labelled cpu / cpu_intc and referenced with &label. > > + * > > + * No `aia-guests=N`, so no VS-mode guest files: IMSIC reg size is > > + * ncpus * page size. > > +-#} > > +{#- Values QEMU hardcodes, need to be described to Xen -#} > > +{%- set QEMU_TIMEBASE_FREQUENCY = 10000000 %} {#- RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ -#} > > +{%- set QEMU_IRQCHIP_NUM_SOURCES = 96 %} {#- VIRT_IRQCHIP_NUM_SOURCES (virt.h) -#} > > +{%- set QEMU_IRQCHIP_NUM_MSIS = 255 %} {#- VIRT_IRQCHIP_NUM_MSIS -#} > > +{%- set QEMU_UART_CLOCK_FREQUENCY = 3686400 %} {#- create_fdt_uart() -#} > > +{%- set QEMU_UART0_IRQ = 10 %} {#- UART0_IRQ -#} > > +{%- set QEMU_IMSIC_PAGE_SZ = 0x1000 %} {#- IMSIC_MMIO_PAGE_SZ -#} > > + > > +{%- set IRQ_TYPE_LEVEL_HIGH = 4 %} > > +{%- set APLIC_IRQ_CELLS = 2 %} > > + > > +{%- set IRQ_M_SOFT = 3 %} > > +{%- set IRQ_M_TIMER = 7 %} > > +{%- set IRQ_S_EXT = 9 %} > > +{%- set IRQ_M_EXT = 11 %} > > + > > +/ { > > + #address-cells = <0x02>; > > + #size-cells = <0x02>; > > + compatible = "riscv-virtio"; > > + model = "riscv-virtio,qemu"; > > + > > + memory@80000000 { > > + device_type = "memory"; > > + reg = <0x00 0x80000000 0x00 0x80000000>; > > + }; > > + > > + cpus { > > + #address-cells = <0x01>; > > + #size-cells = <0x00>; > > + timebase-frequency = <{{ QEMU_TIMEBASE_FREQUENCY }}>; > > +{% for i in range(ncpus) %} > > + cpu{{ i }}: cpu@{{ i }} { > > + device_type = "cpu"; > > + reg = <0x{{ '%x' % i }}>; > > + status = "okay"; > > + compatible = "riscv"; > > + riscv,cbop-block-size = <0x40>; > > + riscv,cboz-block-size = <0x40>; > > + riscv,cbom-block-size = <0x40>; > > + riscv,isa = "rv64imafdch_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_smstateen_svpbmt_smaia_ssaia"; > > + mmu-type = "riscv,{{ mmu_type }}"; > > + > > + cpu{{ i }}_intc: interrupt-controller@{{ i }} { > > + #interrupt-cells = <0x01>; > > + interrupt-controller; > > + compatible = "riscv,cpu-intc"; > > + }; > > + }; > > +{% endfor %} > > + cpu-map { > > + > > + cluster0 { > > +{% for i in range(ncpus) %} > > + core{{ i }} { > > + cpu = <&cpu{{ i }}>; > > + }; > > +{% endfor %} > > + }; > > + }; > > + }; > > + > > + soc { > > + #address-cells = <0x02>; > > + #size-cells = <0x02>; > > + compatible = "simple-bus"; > > + ranges; > > + > > + serial@10000000 { > > + interrupts = <{{ QEMU_UART0_IRQ }} {{ IRQ_TYPE_LEVEL_HIGH }}>; > > + interrupt-parent = <&aplic_s>; > > + clock-frequency = <{{ QEMU_UART_CLOCK_FREQUENCY }}>; > > + reg = <0x00 0x10000000 0x00 0x100>; > > + compatible = "ns16550a"; > > + }; > > + > > + aplic_s: aplic@d000000 { > > + riscv,num-sources = <{{ QEMU_IRQCHIP_NUM_SOURCES }}>; > > + reg = <0x00 0xd000000 0x00 0x8000>; > > + msi-parent = <&imsic_s>; > > + interrupt-controller; > > + #interrupt-cells = <{{ APLIC_IRQ_CELLS }}>; > > + compatible = "riscv,aplic"; > > + }; > > + > > + aplic@c000000 { > > + riscv,delegate = <&aplic_s 0x01 {{ QEMU_IRQCHIP_NUM_SOURCES }}>; > > + riscv,children = <&aplic_s>; > > + riscv,num-sources = <{{ QEMU_IRQCHIP_NUM_SOURCES }}>; > > + reg = <0x00 0xc000000 0x00 0x8000>; > > + msi-parent = <&imsic_m>; > > + interrupt-controller; > > + #interrupt-cells = <{{ APLIC_IRQ_CELLS }}>; > > + compatible = "riscv,aplic"; > > + }; > > + > > + imsic_s: imsics@28000000 { > > + riscv,num-ids = <{{ QEMU_IRQCHIP_NUM_MSIS }}>; > > + reg = <0x00 0x28000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC_PAGE_SZ) }}>; > > + interrupts-extended = < > > + {%- for i in range(ncpus) %} > > + &cpu{{ i }}_intc {{ IRQ_S_EXT }} > > + {%- endfor %} > > + >; > > + msi-controller; > > + interrupt-controller; > > + #interrupt-cells = <0x00>; > > + compatible = "riscv,imsics"; > > + }; > > + > > + imsic_m: imsics@24000000 { > > + riscv,num-ids = <{{ QEMU_IRQCHIP_NUM_MSIS }}>; > > + reg = <0x00 0x24000000 0x00 0x{{ '%x' % (ncpus * QEMU_IMSIC_PAGE_SZ) }}>; > > + interrupts-extended = < > > + {%- for i in range(ncpus) %} > > + &cpu{{ i }}_intc {{ IRQ_M_EXT }} > > + {%- endfor %} > > + >; > > + msi-controller; > > + interrupt-controller; > > + #interrupt-cells = <0x00>; > > + compatible = "riscv,imsics"; > > + }; > > + > > + clint@2000000 { > > + interrupts-extended = < > > + {%- for i in range(ncpus) %} > > + &cpu{{ i }}_intc {{ IRQ_M_SOFT }} &cpu{{ i }}_intc {{ IRQ_M_TIMER }} > > + {%- endfor %} > > + >; > > + reg = <0x00 0x2000000 0x00 0x10000>; > > + compatible = "sifive,clint0", "riscv,clint0"; > > + }; > > + }; > > + > > + chosen { > > + stdout-path = "/soc/serial@10000000"; > > + xen,xen-bootargs = "{{ xen_bootargs }}"; > > + }; > > +}; > > > From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:16:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:16:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428673.1651565 (Exim 4.92) (envelope-from ) id 1x8yU6-0004FD-Av; Tue, 22 Sep 2026 11:16:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428673.1651565; Tue, 22 Sep 2026 11:16:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yU6-0004F5-7n; Tue, 22 Sep 2026 11:16:26 +0000 Received: by outflank-mailman (input) for mailman id 1428673; Tue, 22 Sep 2026 11:16:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yU5-0004Ev-1Z for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:16:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8yU4-007bmQ-Am for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:16:24 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab26375-8faa-0a2a0a5109dd-0a2a45048ee6-24 for ; Tue, 22 Sep 2026 13:16:24 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab26387-b57f-0a2a45040019-4a7de14ca393-3 for ; Tue, 22 Sep 2026 13:16:23 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485933b24c3so2171587f8f.0 for ; Tue, 22 Sep 2026 04:16:23 -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 ffacd0b85a97d-4886277def8sm4551088f8f.14.2026.09.22.04.16.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 04:16:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790075783; x=1790680583; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=08ygijsl2MUvkqCJFkjv3KSivHvHs/swscmHdyRMKk4=; b=au4kdU/6kQUCnCy4AnI2ZvMLeAGeXToBvS3D5/IIdmfZWaWnTSeTOXTNumR3Fc+OUN Hm3HOpe5zLEFmStpIH4G+NWtqy25XYKnxntdmg2oUNyRR9Ks3w2tJzEGQRsEMwa817ra NMIaaegtKu/UbAd/ZJJZs1FgBKiaEj4xmMlJOw+uCu8ffvqDMLsZRW6w8lIsmtNmrY9z 5RvHh5FOu1nL4dq0AAjd+Kp6TVhmZpaeetWUh0EwSbkmUSZ6mWxdSu3xihfIYgwOMJWB G1XuxMjT8t6lfH6huve/GJkTfMIIGZhUKBm9dJUbEN7JQrqTpvvGiCt0R5z4i/oTCuiP c1IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790075783; x=1790680583; h=content-transfer-encoding:content-type: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:content-type; bh=08ygijsl2MUvkqCJFkjv3KSivHvHs/swscmHdyRMKk4=; b=cyxchkAkNQsPjasU8ZyI1tdVtRNhst3MUGvmb2vmKDTYZePVX5wSi5xPPv4x2PjEKm iQPPKVoHFSrzLR6yWqydj/hAT5nEATvfZVkIz/tyZrxr9zPfOzHWHgdFllToT8pSR0xo o2uLvgSamyWUAwYUQIvgv+o4SKkjDmXRTiweewo3umEykEcSC9B8ZSbgi1EWkLSh7N0J TAGvughAJoU0NShN/HeGjbQnxLTRlRJC6rXd08R4GunTyHFe0Px70c0j9WyujK7hO6Tj c2weiWdKnW529BRn2bEEr1NJ+St1r7fHufE38YdR4WxfsfoNxu6n4000gwy4Mu2IIXoU 167g== X-Gm-Message-State: AFuF++mUxujeue8+hxrc9zC1oQyCT9HiVVNktnr3dKAZ0LdLuGa75KJK XDKasoOMGIyDHoEBmYQEnDiKrI08Q8Lki1kcR2Y0TGmr1A+yk0eRX9A6WezQHbgsGA== X-Gm-Gg: AYBFou2oIvpL9EL6mHtc4nJ5F+dNj1FjWNzNlGj777QFGSOz1ZGyetK8GOcSNYx70f5 8yzXoCusID1/PnIFNavjmhstZy8HUO+joALUaolD+VO98UUXuaQQfzAk0YxbGNGFkDbGGAWK2Cl 1PskrrtO/5Mj9Np+cX+TzCneLPYL4w9h71l7MnDySejMyqrQgl0ItJlUuBuke5NOdSir6W7yufl VQEWD+0WL+NQFKI0+dNf6OgoNgWwXwb8fvchJkxH2JYKwcZtw9RPTFXdgYr8vadv8b9/NwtYlVy MDrwEat9tWoo/Ht3kad0nRdM0Csj6RPhmMEXh+zCTGMW4Fk+aWpOrp/8r7eRlWroRgRPC7CEYwS aq+ldnY1vxxBhO+SErjCC9AU3Pj8yGyIVNO0ftcmxA2tYHHMScSRIOjCe+yKT8z07mh8nEHklQ4 eEv/TRHaW8/9hW7d0Znt1AwVworHWr0LMtJFMX71FtNy2ZEqYWFmX8E3BbRuFltUMWe0nb8EOAM H7hbxKyEZc9IOSVsqkA9lHHGCagtByG2XN2XT51W2ZsEoP11gKms2+yYxrrN4E= X-Received: by 2002:a05:6000:610:b0:487:1681:2218 with SMTP id ffacd0b85a97d-4871e36bf5amr24472310f8f.45.1790075783452; Tue, 22 Sep 2026 04:16:23 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 13:16:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <87qzim6p5i.fsf@epam.com> <8fd025af-f429-488e-9977-aec3fea2e78b@suse.com> <87y0ct5zan.fsf@epam.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: <87y0ct5zan.fsf@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1790075784-51ED6B50-38F986E8/0/0 X-purgate-type: clean X-purgate-size: 1849 On 22.09.2026 12:57, Volodymyr Babchuk wrote: > Jan Beulich writes: >> On 22.09.2026 03:38, Volodymyr Babchuk wrote: >>> Jan Beulich writes: >>>> Outside of drivers/acpi/tables/ (which is excluded from Eclair reporting >>>> for dubious reasons), arch/arm/acpi/domain_build.c is the only user of >>>> ACPI_COMPARE_NAME(). Make the macro const correct, at the expense of >>>> introducing a "const" variant of ACPI_CAST_PTR(), and at the expense of >>> >>> I think you can avoid adding ACPI_CAST_PTR() by providing a const >>> type. Like this: >>> >>> +#define ACPI_COMPARE_NAME(a, b) (*ACPI_CAST_PTR (const u32, a) == \ >>> + *ACPI_CAST_PTR (const u32, b)) >> >> I don't think so. You did notice ... >> >>>> --- a/xen/include/acpi/acmacros.h >>>> +++ b/xen/include/acpi/acmacros.h >>>> @@ -103,6 +103,7 @@ >>>> * Pointer manipulation >>>> */ >>>> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) >>>> +#define ACPI_CAST_CPTR(t, p) ((const t *) (const acpi_uintptr_t) (p)) >> >> ... this, I assume. On the surface it looks odd, because one would expect >> acpi_uintptr_t to be a scalar type, like uintptr_t is. But it isn't: >> >> #ifndef acpi_uintptr_t >> #define acpi_uintptr_t void * >> #endif > > Well, that was unexpected. Talk about principle of least surprise... > >> The only alternative I see (somewhat more risky overall) would be to >> introduce >> >> #define acpi_uintptr_t uintptr_t > > What are the risks? I'd really prefer to have fewer gotchas in the code. It hides casting away of const-ness. Right here we would like that, yet in the general case I think we don't. Otoh Linux switched to the above in the 5.18 dev cycle. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:18:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:18:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428680.1651574 (Exim 4.92) (envelope-from ) id 1x8yW6-0004zC-Kd; Tue, 22 Sep 2026 11:18:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428680.1651574; Tue, 22 Sep 2026 11:18:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yW6-0004z5-Hs; Tue, 22 Sep 2026 11:18:30 +0000 Received: by outflank-mailman (input) for mailman id 1428680; Tue, 22 Sep 2026 11:18:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yW5-0004ys-9J for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:18:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8yW4-004FIH-0s for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:18:28 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab263fe-e002-0a2a0a5209dd-0a2a4508ecf2-22 for ; Tue, 22 Sep 2026 13:18:28 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab26403-f659-0a2a45080019-4a7de14cec3a-3 for ; Tue, 22 Sep 2026 13:18:27 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843378fb37so1962316f8f.3 for ; Tue, 22 Sep 2026 04:18:27 -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 ffacd0b85a97d-488626d29dasm4678663f8f.0.2026.09.22.04.18.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 04:18:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790075907; x=1790680707; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=NzoSu7oz7FIga5JrfzeKognymuNfSo/D3EKCD7/Ye2s=; b=fNVP6zj8aDaV5KHfh7JV+rQ6LbcJxStMsSPYB/v+26SFm788OoS/mBs4TJcXKS2h2A qLrPl8nNImWXhwSDeZ6Q3kJeBsYWL5hQBzpO2uww4dTyotdIHMGhYwk+yg/CQ+kiiLh5 PPLrJRZUIpo14Ip5QE4rQ14wanti4QB5353RBND91l8bjn2XC3yj6XEFyHZ6/IDiLsWm kIrkgLIGG+KuCgpnNwl/mS9zq79kWrANCxozxgWZK+k5O5DD7MOk9+qD5o3LFmchtRzr MJxodW3yur6WM1dE4JDX216FQZkWs6N+Oo0DgNhAv4OUPcNobWncQ0HxKE5FFyTz/Frt Ce+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790075907; x=1790680707; h=content-transfer-encoding:content-type: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:content-type; bh=NzoSu7oz7FIga5JrfzeKognymuNfSo/D3EKCD7/Ye2s=; b=GUgXPlvqAYdoFNu1NYrgMjCIb8e+pX5ClOWZsWA6CgSuvKytB6pjLPyu6kY59pv769 ZPhZvIYRI8yyCHrCTSYMM5RcSuc69sKeHNkoRtno6HwE4f3bX+wHf73b4tXMYzChF7Cf 29ay1QCj1b8iyMvcQ+iVBHmffx7Sgr+xdK2Mla5mgFTH3VTXRRt2sryW+w4vOFLrsEm9 19bl9aWd49kNY6syl+OI/UeNFjI5oWqu88ahKptMPmY+/PGX3kSeBNM8iasUzZoyUVEN xUZDXk+xK7RP78CPLk2vnIHveepiRLaq9xihjM9XvM6pqbeMR8724i/M89y6NFfF2ZCV ctkQ== X-Gm-Message-State: AFuF++kYCcnbaowgjP9rp0JXQu3/XPLvCeghguLhxbHrTY9mZL9ENJQj l3PGupgTV43qUmB4/fjfmql7LMwxFIEU2Tsxk5T7kUqowVW6GCnRrVL5ypHQIBcexw== X-Gm-Gg: AYBFou3T8AV2GayqqHvHM9h7cCwygxWJnAedkwfjVYZJH4tPwh93rEDsS15fXUEdQA/ XRIXkVfqpMimAJEsMWJFHwAGHAMEkdhGhwbR+b86SIiEc82nt64isVhqVMvDQ6Bw42wvwP4LxTJ repFsyorIJX/1a2EkaGeAP2QEy4D8yO441YANVjaIXShaZMSJmT+5myi2md42WUeSQk9KosC+Lu zcdxAEvKrVo7mLT4Ifags2FEUBlb6MRmoZJLQg6Xzge3AF6gpr2MDLc8K83/5P4BkfTbsUs+BZp hdJhy4Rr0loz4QlfUGCGoupyxuY3n88K5ubF8JPVv55xRQ6JuhHRMyQ60ab5HApHdMfPl7cVAcd CSLp7thsXxsx6t2I6VAVZne+Cm4lhMRV0TeVs4PvjY0e8q7CdSUdUHyWf4vZ2DqFvMjVbmAzsN1 0QieIJZySCUFVYLHihXsWm4ketxS0og+btGHuyuJjVuTygtq51fI58zh2DfnuH2dFC/EkLCHSZo 3X28HOIOzXICl5bG/YQz8+HsvpYQ6EoSXFrbLE1uPseg3y3dx3xcQOCycWve20= X-Received: by 2002:a05:6000:2086:b0:487:662:cb90 with SMTP id ffacd0b85a97d-4871e26949dmr21529963f8f.34.1790075907371; Tue, 22 Sep 2026 04:18:27 -0700 (PDT) Message-ID: <0320daf4-fc62-4b10-a068-0e25f53f3ee9@suse.com> Date: Tue, 22 Sep 2026 13:18:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 10/14] ELF/notes: use pointer-to-const by default in ELFNOTE_...() To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <8fe86787-7590-44f1-be4f-461b61d7669b@suse.com> <87fqz26otq.fsf@epam.com> <162997df-6c5f-4f1c-b01f-16f6c2e4e0c6@suse.com> <87pky55z3z.fsf@epam.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: <87pky55z3z.fsf@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1790075907-D437587B-C129F42E/0/0 X-purgate-type: clean X-purgate-size: 1840 On 22.09.2026 13:01, Volodymyr Babchuk wrote: > Hi Jan, > > Jan Beulich writes: > >> On 22.09.2026 03:45, Volodymyr Babchuk wrote: >>> Jan Beulich writes: >>>> Not doing so results in a number of Misra rule 11.8 (casting away of >>>> const-ness) violations. We need to allow kexec to use pointer to non- >>>> const though, so provide a means to override the default. >>>> >>>> For ELFNOTE_NEXT() we can do better and simply re-apply the type of the >>>> incoming pointer. >>>> >>>> Signed-off-by: Jan Beulich >>>> >>>> --- a/xen/common/kexec.c >>>> +++ b/xen/common/kexec.c >>>> @@ -6,6 +6,9 @@ >>>> * - Magnus Damm >>>> */ >>>> >>>> +/* We're producing ELF notes here. */ >>>> +#define ELFNOTE_CONST >>> >>> Frankly, it feels backwards. When reading this line of code I am >>> assuming that you are adding constness to ELF notes because you are >>> defining ELFNOTE_CONST. And I had to check the elf.h to understand that >>> you are doing exactly opposite. I am pretty sure that other people will >>> confused by this as well. >> >> Well, that's certainly possible. Yet then you or them are asked to make >> an alternative suggestion. An option I could think of would be to merely >> rename what is ELFNOTE_CONST right now, to no longer have the word >> "CONST" in it. ELFNOTE_MODIFIER maybe, albeit that reads a little clumsy >> to me. > > Taking into account that we need 'const' to be enabled by default, maybe > something like that? > > #ifndef ELFNOTE_NO_CONST > #define __ELFNOTE_CONST const > #else > #define __ELFNOTE_CONST > #endif > > ? > > And then use > > #define ELFNOTE_NO_CONST > > in this hunk Can do, just without the leading underscores that you did introduce. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:20:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:20:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428689.1651583 (Exim 4.92) (envelope-from ) id 1x8yXg-0006a7-28; Tue, 22 Sep 2026 11:20:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428689.1651583; Tue, 22 Sep 2026 11:20:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yXf-0006a0-VZ; Tue, 22 Sep 2026 11:20:07 +0000 Received: by outflank-mailman (input) for mailman id 1428689; Tue, 22 Sep 2026 11:20:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8yXe-0006Tn-AL for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:20:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8yXd-007cZi-NP for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:20:05 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab26460-bab6-0a2a0a5309dd-0a2a450ccd5c-8 for ; Tue, 22 Sep 2026 13:20:05 +0200 Received: from [40.107.200.25] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab26464-f479-0a2a450c0019-286bc81968a4-3 for ; Tue, 22 Sep 2026 13:20:05 +0200 Received: from IA4P220CA0005.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:558::9) by DM4PR12MB5745.namprd12.prod.outlook.com (2603:10b6:8:5c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Tue, 22 Sep 2026 11:20:00 +0000 Received: from BN3PEPF0000B06C.namprd21.prod.outlook.com (2603:10b6:208:558:cafe::6e) by IA4P220CA0005.outlook.office365.com (2603:10b6:208:558::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.14 via Frontend Transport; Tue, 22 Sep 2026 11:20:00 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF0000B06C.mail.protection.outlook.com (10.167.243.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.0 via Frontend Transport; Tue, 22 Sep 2026 11:19:59 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 06:19:59 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 06:19:59 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 22 Sep 2026 06:19:58 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ydP17yeqhob6vACnQpPrDMAYuXl4mTD/sjzbT9RIGvOjsNzTeWjiZIPj5pF9a4l67AVoOz4NmTwYKojJfBbIzahqOVWIFarhPMfNCG+udjQdFCyEG9IHyyeHZEhwwpRHCM8FtkccIc7R6k7WcK9SRtiOPPjomrc+1MfW8G4kpg6tPcCpeIE4NpeHvhc//BWA5QoLMRuIEaCRxUSPACMWRmOtnWaUo8/HBoD4x/CK+B5x9aB0REckBgHYIkN6E7cPo9XgBc4yZj9VYoE/0VwTYJ47KAKOM+yjqZIl/RDgEWAiavpusFj6x+lFTt0PrEii407KEkUMlC0/fzSBxySBag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uQxk49AgEydZFEzS/37FzXkLZAyO0irbvK0oJ835BtQ=; b=Mm+XoZZqlGqHLlhHcVyBJq0IvxSjeUNoc7VkCcEiKLeW2mxYsqDpCsaxB6yh66Te0B48xgzUcJh/uU5ECMPLlEpjWVNGx3f4/HFAwdSzaF27FqogfK7EBgD+pXifrCTsDA0/hJwsSrl1UBz4jcZw5/rodAgq9/R8ROmNmLU5ssD8aRGYF17yut+QIXx4GxKCQf1SdvBESbAfQgDmz/kb3fixOVgSZjuo9BOvVens7mGQ0obXIdc34CF01r2YTjIK2PpE05Bu4+ufDo1/Hvpwt/w++ueePAEEzO3yqcNyZL3wSszC7mdUYi/UOygqJdaVpHRwQ/JKaM2F+FPzgnqDWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uQxk49AgEydZFEzS/37FzXkLZAyO0irbvK0oJ835BtQ=; b=GXMXdPHO4IvVDeb6Zbu6w2LzfJyBumqDTcjp584NC/1sPVvaM3dWQAKjNNJTDG3mVm2EO6sr6O/hRYQDd716DjBXG3h6vIuxv2RftMo1T+1rJ79oIuu54GanuUn06NsyNFKiumMHgFpkicFiz5WpJYcFF0ZbEztTZN1S2IdisgA= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: <52255065-80db-4dae-8406-b1f75614ef9a@amd.com> Date: Tue, 22 Sep 2026 13:19:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/4] xen/arm: make is_espi() a pure range predicate To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <802ae2dd44556a292d98f1d52d3c88ce4fa5034b.1790056623.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <802ae2dd44556a292d98f1d52d3c88ce4fa5034b.1790056623.git.mykola_kvach@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06C:EE_|DM4PR12MB5745:EE_ X-MS-Office365-Filtering-Correlation-Id: a411d755-478a-41a7-d34d-08df189b70ba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|36860700016|82310400026|11063799006|10067099003|4143699003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: URgQ9SIIX+R4jdCxYmvRf/5iqxGEI9gKCMUpcyznXvERe6jjhLSeq5qJFGfr1moKD5qd+yiaO0bs43gGOOBzmfpQb7Wew7fWwKNLGIXcqiLNCRrXzT6Ur71GqxzAS4uhna/02xOLqufelQPDaP5jC8Z1sQU97/4h86/ZP9Wc7m/NBYhO18/O2uzY5XkJFfaPvvbTEjJkcv9d3veHP5c/HnTgkx5s4zWoY2UBJp9fkbntVVqfCriRxaAaB8nLQj1NRwvj54+++uWbxocdGooJrzQtOszqvLifNxdi8UraqPNYB3LJS1KIQ0PxxN5jeHhvDI4qCkpQumZ5VpgPz4W4KIVGNjEZDg6/7rV4RPUOdDYRqT8m/gpwYgQBJ3Fn+Bbdk3ok8UrNF+C+nr+eblwbt/R084cTppWQDXKHM0vuLyv+6HGc1hX9TgH1P0H0bpUS0QosrEm0SaLP/hkmJ7eTLKu+uWfolGfuR8kjaGiztnrl8rq1PN/M0nOpET3Qp/k0VUq6IB4Lcq5qT+KcMzF8MEfxYdXa2OweVkqo6Xng45A8Xu99+UIvpLFqDgLVlc5foRwkaneIW/iYA2hMLm87EEh4uobx9/rWDr0xlaCULLrrAkmCtNHris3xxNs1IrwNn36XqXZq9ki3gvNsMI0BvluXQc54o+O8zaVbO9lK9qj6aGRO8aIamzFESEem2kgerHgIwcriJzDpbVtTjj4BJA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(36860700016)(82310400026)(11063799006)(10067099003)(4143699003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ML4dYkPBH5uvU/NtvIAtZSHlLH3pP3hTpizbNrcfjEjiAnbHfsprPBEvfPHHSW+kTqa/M5eN1lfiXD0M2n8zeIGm/10GiKrLx+ljnSZWdDA5EcheU5d3oeN2bf5uIyfMQfyutXc5UzgW9nriDXsj+LKNCLzWqo6tEvSZsr47V0ZNmK7ngCqywxODKNng0WR+fAJypCA2wgRKoAsf2gpM0DTvomG25rF6hFUPjsJ5e4xCeBY12MQ5HG7dxZjbHxDQZCJQKErkNuyuqA9AiPOyVzg2fhTiARv9Ht1yNLzFPxp0OtItGPNkztUbbh0tPerutUod4DjFHMFuJlSRu/OLM0pnaFTptmE5l2Ms3/XsUYTHO9tFC4mlssQoDDMgeaZaxVQDqFWjZUYDxdCNE6638yDHNeK3s/i0S3UVHNXYeoGHG/eMLBikeVMRmG5av0/z X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 11:19:59.9731 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a411d755-478a-41a7-d34d-08df189b70ba X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B06C.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5745 X-purgate-ID: tlsNG-d25034/1790076005-50F3BA5B-8C30C127/0/0 X-purgate-type: clean X-purgate-size: 4849 On 22-Sep-26 08:39, Mykola Kvach wrote: > is_espi() currently changes its result according to CONFIG_GICV3_ESPI. > Without eSPI support, it returns false, and its assertion fails if > an eSPI INTID is passed. Callers therefore use it both to identify > eSPIs and to exclude eSPI handling when support is disabled. > > Make is_espi() report only whether an INTID is in the architectural > eSPI range. Check for eSPI support at the call sites. > > Use BUG_ON() if the GIC reports an eSPI without compiled-in support, > matching the handling of unsupported LPIs. Return NULL from > spi_to_pending() for an eSPI when support is disabled, using an > espi_to_pending() stub. > > Signed-off-by: Mykola Kvach > --- > Changes in v4: > - Clarify the existing is_espi() behavior in the commit message. > - Drop the unrelated blank-line removal in vgic.c. > - Use BUG_ON() if the GIC reports an eSPI without eSPI support. > - Drop the redundant CONFIG_GICV3_ESPI check in IRQ dispatch. > - Return NULL for virtual eSPI lookup when eSPI support is disabled. > > Changes in v3: > - New preparatory cleanup requested during review. > --- > xen/arch/arm/gic.c | 2 ++ > xen/arch/arm/include/asm/irq.h | 11 ----------- > xen/arch/arm/vgic.c | 30 ++++++++++++++++-------------- > 3 files changed, 18 insertions(+), 25 deletions(-) > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index 078049e741..3a7f972826 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -348,6 +348,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq) > /* Reading IRQ will ACK it */ > irq = gic_hw_ops->read_irq(); > > + BUG_ON(!IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); Usually BUG() should come with a comment explaining why we cannot continue. Here it's that without config enabled, there's no descriptor and no pending_irq storage for it. Please add a comment. > + > if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(irq) ) > { > isb(); > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h > index 09788dbfeb..c29f3d04a3 100644 > --- a/xen/arch/arm/include/asm/irq.h > +++ b/xen/arch/arm/include/asm/irq.h > @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq) > > static inline bool is_espi(unsigned int irq) > { > -#ifdef CONFIG_GICV3_ESPI > return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID; > -#else > - /* > - * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is > - * disabled. Returning false allows the compiler to optimize the code > - * when the config is disabled, while the assert ensures that out-of-range > - * array resources are not accessed. > - */ > - ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID)); > - return false; > -#endif > } > > static inline unsigned int espi_intid_to_idx(unsigned int intid) > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > index e5aca17dcb..e04678f134 100644 > --- a/xen/arch/arm/vgic.c > +++ b/xen/arch/arm/vgic.c > @@ -62,6 +62,13 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, > return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]; > } > > +static struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) Constify d, please. Also, use static inline like the surrounding helpers. > +{ > + unsigned int idx = espi_intid_to_idx(irq) + d->arch.vgic.nr_spis; > + > + return &d->arch.vgic.pending_irqs[idx]; > +} > + > #else > static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank) > { > @@ -78,6 +85,11 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, > ASSERT_UNREACHABLE(); > return NULL; > } > + > +static struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) > +{ Add ASSERT_UNREACHABLE() here like for vgic_get_espi_rank(). > + return NULL; > +} > #endif > > static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, > @@ -696,8 +708,8 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, > /* > * Returns the pointer to the struct pending_irq belonging to the given > * interrupt. > - * This can return NULL if called for an LPI which has been unmapped > - * meanwhile. > + * This can return NULL for an eSPI when support is disabled, or for an > + * LPI which has been unmapped meanwhile. This puts LPI and eSPIs on exactly the same level which is not correct. While unmapped LPI can happen, eSPI with support disabled must not. Leave the LPI comment as is and clarify eSPI in one sentence. Otherwsie, LGTM. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:22:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:22:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428697.1651592 (Exim 4.92) (envelope-from ) id 1x8ya5-0007Am-E4; Tue, 22 Sep 2026 11:22:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428697.1651592; Tue, 22 Sep 2026 11:22:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ya5-0007Ad-B5; Tue, 22 Sep 2026 11:22:37 +0000 Received: by outflank-mailman (input) for mailman id 1428697; Tue, 22 Sep 2026 11:22:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8ya3-0007AQ-Br for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:22:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8ya2-002glK-Ov for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:22:34 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab264fa-8faa-0a2a0a5109dd-0a2a4509a09c-0 for ; Tue, 22 Sep 2026 13:22:34 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab264fa-be1a-0a2a45090019-4a7de18cacce-3 for ; Tue, 22 Sep 2026 13:22:34 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912df756so27768855e9.3 for ; Tue, 22 Sep 2026 04:22:34 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fdace76e8sm58810405e9.1.2026.09.22.04.22.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 04:22:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790076154; x=1790680954; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=FuQGbY5+Oh09G0KsH/4qhh0PfmkZHq19MkHek5qZnME=; b=ouggmz/9C5vaTG6MzwDd/nd096+ju1vioAJeOyalrz62Epw1w3Tavlkgk624il9DCg VclHa5+sBjZ/0kz+y87dkT+UiiE/Ia7FjN5Vpsr0t329meICtcipwartAvHpi8H0ZMqa IeIioLTYr3rMRmDakmqvhV7glbJF+rlYOByjMAdzk4bYwPIdhpGqq2vRTuv/aK7St3el 8QqPNtYzWs7uCmj+hTYzxYo1LI3zWBNyFCkET3ar3rEFioSortSkPkMQlbolWfPqWWk3 +sfjDfu7ea/o6SiPaN8pJvPZeag54b4MjKF0ic3pV+fLqgi/zqU/rW84UMV7F18Fxsi7 YDeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790076154; x=1790680954; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=FuQGbY5+Oh09G0KsH/4qhh0PfmkZHq19MkHek5qZnME=; b=0UxXyBveKMImutpSrWlaST08Yw7o61wn9Ra0eqD2OUrhxAcPOwDNAvDaIXNCH3GMS0 SNf2sa2S09+ylTmlfamDfOCEdbbvnol1NYrtCRhLojn6R+5UDXKOZp6nRj8oSqUDuGxk Nxukn76hsDmBuC8c8Vo1f5bjMMHMALGPIdt/I04snxyVljuQSJ0eF0Z5hXxGkTNbiXvE Vq7Kb5BXm4DdyK7EfJ3dnTOnUDlOGHueE1vzDfZPmynhk2mEtcFJR0WAtKAEgsdfnzvc rnZeUZ+LRl/A9EOw+u9py10sj/gGsclrrQ/0oTnqVkQvVBYwpfHlh/8ouzamqAMCKOL1 Z7iQ== X-Gm-Message-State: AFuF++le33ri04fBLkqONKNMkhSiqXSRDrcR0v83ezUHeMDv6oHB89LN F1BVVqXggGMGyRSbDuY6EGLhaEVaIrW6ogZlHtSvGgeBfyxEfdM8KnR7 X-Gm-Gg: AYBFou0/IbzmfAfW0yQHPuiVY5ZGxcpLTzCBr06NengECdeDyGzJBGpwjVdOVWcbkiO GZekKLoFuEyjuzgul09zqJG7UPpmL80ATuQ8B2TRAkG8P1M9sFxJgwST4lvCh0+oRzIow1hOsNl 1SmpfKk37Rov/CALaiiek2vj1dCqEp4bzjVqrs0qWTUPWSEQmyrGyVvzETVN6nhkIlN/iKs+j2e PMYjwn8bpISNOMGnSa+ApCXjt7llwBYpLYNwiU8aPJiFOnpDBD/WeHafyOG9Tl96v19tQm4/KHT MvLmcP+WUsGHQdIJIDBagXciKNzcrA7fF9qFOBrLUcB7TWDpKDd5cBYTGLxuGWGz6q1SC8aF8ZG NwMVo0XbWVj80Qqqr0AqK8TaJT9Lm2UmYAOmN6yc4uctlhNb63QRQhjlN6xCi4HNkMV4Sl3VfrZ 51dZMjP+Ycr8umvJxeM9Wh+ORSEvIiCnKdUYvWhg9p+yVEi6EA4kJ6jwVWm+dWeB0ymji66oooQ oML/ZaPwKRAuCj2U1DmAC7fzkDUYgA7nW55w3TKf+DE89SXaw== X-Received: by 2002:a05:600c:474e:b0:49e:7cff:f8ca with SMTP id 5b1f17b1804b1-49fc5743c69mr183916215e9.29.1790076154219; Tue, 22 Sep 2026 04:22:34 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 13:22:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 25/39] xen/riscv: add guest load emulation for trapped MMIO accesses To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <7cf3203f8f826eefa1b24bb2dedbd76c0b611dc1.1787838835.git.oleksii.kurochko@gmail.com> <1789723009.8631fc262581453bbf619ec5b2062170.1a0b3cde12700072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789723009.8631fc262581453bbf619ec5b2062170.1a0b3cde12700072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1790076154-3A2C4034-A6A77DFC/10/73395122804 X-purgate-type: spam X-purgate-size: 533 >> @@ -179,8 +178,7 @@ static void resolve_faulting_gpa(struct guest_fault *gf) >> * Relies on x0..x31 being laid out at the start of struct cpu_user_regs in >> * architectural register-number order; see the comment there. >> */ >> -static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs, >> - unsigned int reg) > Could we unified this function with regs_get_gpr()? > I think it could. I will try to do in the unified way. Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 11:38:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 11:38:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428709.1651600 (Exim 4.92) (envelope-from ) id 1x8ypc-0001VF-Mq; Tue, 22 Sep 2026 11:38:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428709.1651600; Tue, 22 Sep 2026 11:38:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8ypc-0001V8-KD; Tue, 22 Sep 2026 11:38:40 +0000 Received: by outflank-mailman (input) for mailman id 1428709; Tue, 22 Sep 2026 11:38:39 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x8ypb-0001Up-At for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 11:38:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8ypZ-00GI8O-Hh for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:38:37 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab268ba-8faa-0a2a0a5109dd-0a2a4504b3e6-10 for ; Tue, 22 Sep 2026 13:38:37 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab268bd-b57f-0a2a45040019-4a7de18cd8aa-3 for ; Tue, 22 Sep 2026 13:38:37 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d37b6so19565025e9.0 for ; Tue, 22 Sep 2026 04:38:37 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fdad29ee8sm44526315e9.4.2026.09.22.04.38.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 04:38:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790077117; x=1790681917; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=2+RHzN2uifN1QY4H3CQrwFyO+hBAxSeEL8727VN2mVU=; b=YWnIww6eCCpcYMDxZIJHh5Pd+U2+SKamBaBrVxU3IyL7G4xd4aRM82H2aLOoqNkiwP bLzMmv7GVNYJcm8g3SMziv16uyUovUneQK0Yn4ApZfcsy6kNkrXcH6/TZjUamfut7Iba m/q1QFtwruRaN014xAmIsn3DCROMlvmyfwouXGd7KWhLQcUGaSyV77L0GcTIcN1yvPbb x/WXNSu0T/zLNUn9vFuSZmHeBuy4Rzizj0zZcLlRzsY5ylkCi7qJDB16tzbcYunaDVvy M2kAABJRE891+Ki9F8VNlsNPP3wLLfx5A/f3viKdB6tkAmfhUJ1Fqm45Eg2QRBAN9KK/ AOdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790077117; x=1790681917; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=2+RHzN2uifN1QY4H3CQrwFyO+hBAxSeEL8727VN2mVU=; b=yqYQcskSzQgBxNMp65cm/8xREmGEWUHA9P2rJMjFbrMatRO6R6dN0dAljmvn1tWkI3 5sLLmGrZ0LeXUr5mGJS+1/gz6Qs5MU3WXWB1HV1bu3yjykJg5we6/c8CtzEZ+1zqG7Rm 8DkMgD8CEX50yLZTCxZHpNMp3jvEoPsiGrI2IsBW/0n4LLYezUVMAiIZzioOeZxG2uxn WkWNZqyTOpiKQzXP1+iycKROj5fo4RvwQY+2U1Qc5ULXxMBOCZSppR68YPv02sxAVyJo aZYq6Mu/9Piz4wPwxFn8bnkqxQgKooN/YO5s9pzgA8USojjwc1LvVy93+f8qIit3Qy4e FskA== X-Gm-Message-State: AFuF++lgdBfdS1e/1M6kHtkmsilhhURiyKkuxa3lvEoev9s3IVR30XNr wtMmgO6J6Lk9KPCjzUngOoV+7w3L9jgHX1VwS5cxqxcvsIl+oenyN+LN X-Gm-Gg: AYBFou1M03sj5dawpl1qVt3nTirsTQMFhZYMC2cnQLCYF4+igFnagiAHoRGLPQdkfgK 1u8zy4euZauB9GFx7G5UKw6rZ0l7YEd2rSyZgXPUfPE7mkF4hvHDnP4hZs44416qFcMw2vYV7ri kWULKh91efUm9Vh01XholSL23VfcP5iNPYLgdFahsJ6eqhxIYU6R9cpl055OEauDchtQQ3HkM7m JDvgXKFmbDOH+un4NmmgkaMC9B1i4Waxk9c6WOA4j2lyCXmWa6kEe3FWJwoMBh0fR1JSqvmztjG cB57cHMzGtWYvsyD04cwmuH2squ9Ozm3SLHhuXXVDeDd+4n3D1MvGdlZ7s2lDDx60ZzhwRB1T7O 2pbd0N4EOU5iWfg6fUg2Esu9ZWZAgcatEhIpdImhCiouTACB31nze0R53LCd7YpmfxsJtaowcdq QZEJfVXK8KpTo9ev6MkVtOj8h0zGwVMyReU8k2KnnlTZKI0ZabD/CbtXniRWVZhGH5qq0t7t9oH ADDEQlI1FQxmdW5wXBHddOHmRH669oQQUwkPgox8BLiX+dmjg== X-Received: by 2002:a05:600c:64c5:b0:49e:6c11:c4fc with SMTP id 5b1f17b1804b1-49fc56aa4e8mr197533085e9.7.1790077116737; Tue, 22 Sep 2026 04:38:36 -0700 (PDT) Message-ID: <1d647ef8-c6f7-4e27-83f5-4f9498bb9fd9@gmail.com> Date: Tue, 22 Sep 2026 13:38:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 26/39] xen/riscv: add guest store emulation for trapped MMIO accesses To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> <1789723009.8631fc262581453bbf619ec5b2062170.1a0b3cde27700072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789723009.8631fc262581453bbf619ec5b2062170.1a0b3cde27700072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1790077117-C26CAB50-6A073E2B/10/73395122804 X-purgate-type: spam X-purgate-size: 1498 On 9/18/26 11:16 AM, Baptiste Le Duc wrote: >> Extend the guest page fault handler with store emulation to support MMIO >> write accesses. >> >> The instruction decode mirrors emulate_load() and, like it, is adapted >> from Linux's KVM RISC-V implementation. As with the load path, the >> completion is synchronous through try_handle_mmio() rather than KVM's >> userspace exit/return split, since Xen's MMIO handlers run in the >> hypervisor. Faults taken while re-reading the trapped instruction are >> handled by decode_ldst_insn(), shared with the load path. >> >> When a guest store instruction faults, the trapped instruction is decoded >> using HTINST or, if unavailable, fetched via unprivileged access. At the > Nit: commit message restates the HTINST-or-unprivileged-fetch decode > mechanism, which is already described in the prep patch introducing > decode_ldst_insn()/insn_fetch_faulted(), and isn't repeated in > emulate_load()'s commit message. Suggest trimming for symmetry with the > load commit, e.g.: > > When a guest store instruction faults, the trapped instruction is > decoded via decode_ldst_insn(), shared with the load path. At the > moment only virtual interrupt controller (vINTC) traps are expected to > occur, since it is currently the only backend registered with the MMIO > handler dispatch, so in practice the store is emulated via the vINTC > backend. > I will update the commit message. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 12:28:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 12:28:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428759.1651699 (Exim 4.92) (envelope-from ) id 1x8zbI-0002Uu-6p; Tue, 22 Sep 2026 12:27:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428759.1651699; Tue, 22 Sep 2026 12:27:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8zbI-0002Un-2e; Tue, 22 Sep 2026 12:27:56 +0000 Received: by outflank-mailman (input) for mailman id 1428759; Tue, 22 Sep 2026 12:27:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8zbH-0002Ue-3O for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:27:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8zbG-00FrVj-Fl for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:27:54 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab27444-2eae-0a2a0a5409dd-0a2a45028e2e-10 for ; Tue, 22 Sep 2026 14:27:50 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab27446-6ca4-0a2a45020019-4a7de14cb0a1-3 for ; Tue, 22 Sep 2026 14:27:50 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4858bc96fabso3285328f8f.3 for ; Tue, 22 Sep 2026 05:27:50 -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 ffacd0b85a97d-48862793792sm5876059f8f.31.2026.09.22.05.27.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 05:27:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790080070; x=1790684870; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=wP/CxubhZJx44DypIsBQgS0gMJTEdf2jQTTrcKjNZ6w=; b=P1RzTurb3TFiRd8++fD2G0kBFpi3xRjkoCPP3u9UX/QO1S4N3eq+H7JoSSlsUom455 k8ImKGCY0RaQdJhOnRStQA4RnqEzXVX3TQ4ViUjHayuUw4p9wX4hDUzE5aBqPLETk8tm 6sFYsCugp4c71WogAcgD/Sc+vlouusb37HoZRCBMXvwfixWWsOLyzRok/gH5+wrSxrhh gCFIFwLFhU+bB7R5fvoxttTjWJvhNNigs/bMhxbDicXjEqeRBzh620b9xYM/3ahhseAi zLEXDXXQSeyG40C7Q+kIm6RWoL8pX9hNFPxN9pAOOtPRef1gne5zXHeCMl3aEK5kPWbl b8Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790080070; x=1790684870; h=content-transfer-encoding:content-type: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:content-type; bh=wP/CxubhZJx44DypIsBQgS0gMJTEdf2jQTTrcKjNZ6w=; b=0AHQJI6mi4t62VwoQ4kiDBfX0BhOjNk/0PEsSLs6lIeKrBw80PrIKDvGzrSLmNZGuW TpFJgsySLZhkN8lPaORSRa9kk6QiSfzwEIbkn8y36YZz1YX+dwBVDk785he7n9GjX+Dj enhv3Rg1evRD5NabBal7HQKoqRb0NWbg/mcBIoWT3mdOCmTmPJo+y6fm4HJN7tkwH5LM oAs3BGzd+81oodTMotv+kD8A0WwKMptk2DJw4WEKHUHjMhLFjO10DAAA61XkqgR6VgTs eX7kEmy4NLqtThMQcKSWzfFOsa3j8SDrcITmXUD5rq6JtJx8kKH8IHcF9c9B6PLMFUM+ ztrg== X-Gm-Message-State: AFuF++l3qHZAOz/s7PAkrJgD93/2JTHT9pB2mBVZcIHboh1xpNofJ+LM U8TNTF5WLs4d4fp8FmA1k2sDgmQq4FvJB8cBsuRslPMvpXdrBFt3gsE6PQEe6Z7MeA== X-Gm-Gg: AYBFou2kKhXGUKcdGs28kfnL1mElT7ALmt2zBqM22YvBO52vispMGhPySr5lIzg5NKC hkyunYtwiOhsAJjSebk+WPVKOVT6ettgzmL6Hun0SaLQgMTOOUpfyye+K8YFtR/hL/md3pqxge2 8uACzi7C+bl6i8wXPKCpr0TTLNys5DHwWgQeBmceWvV0Y8YFQomxkJaPKXbqstAMRF6yfFEA++0 i5VWbySGiP3qRhmYPSGGJw5VD8NZch5+w30k0Awfn8Z2zUT9BKQ6M22QoHb9ToNhKwpTm+C7cVL UmZ6pNCWmLrzh55uM6IeBmxYdzsfG0QsWN3kxrffdqGz35DK7WrcVjYAdxIzoHMwOGDMQ75uqEa ko8gKl+h8nvwZuYZ1GR2GGYJ2KI/42KlblngoTocjdSHxQIkm+jsUJZswpG4HCPmgcHCb5j/lf8 oXdYISukwzoXLNSixMfdcDWVn4f9MgPi7DdG3Xc7l47RII2ZXDXnQAP19tnnw0/A1vOdTzwgbrM 0ztq0cMKPLWao2pEMbwF0nU+IgSEmweUunQGNWkoTJweW8+S2V7PynMg+B2nK2dbizOeDjvdw== X-Received: by 2002:a05:6000:41f0:b0:487:7fd:730 with SMTP id ffacd0b85a97d-4871e254ef7mr19640865f8f.13.1790080070110; Tue, 22 Sep 2026 05:27:50 -0700 (PDT) Message-ID: <20c2003f-910b-4e9b-92f4-5298f11f58df@suse.com> Date: Tue, 22 Sep 2026 14:27:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/6] xen/riscv: make Zihintpause no longer a required extension To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3@vates.tech> 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: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1790080070-F0AA52AC-4313DE70/0/0 X-purgate-type: clean X-purgate-size: 1334 On 10.09.2026 11:34, Baptiste Le Duc wrote: > required_extensions[] panics at boot if Zihintpause is missing, but Xen > never actually depends on it: cpu_relax() only emits the "pause" hint when > the extension is implemented, otherwise it emits `0x0100000F`, a legally > valid FENCE instruction (`FENCE W, 0`) rather than a native NOP. Just that PAUSE's encoding is 0x0100000F. I.e. what is emitted is always the same, and hence discussing the encoding aspect here doesn't help justify the change. NOP or not also doesn't really matter here. The specific hint encoding looks to fall into what prior to Zihintpause would have been covered by "Designated for future standard use", and hence ... > FENCE is > guaranteed by the RISC-V base ISA, so it never raises an illegal > instruction fault. With an empty successor set, it enforces no > memory-ordering constraints and thus architecturally behaves as a NOP. ... there indeed should be no concern for any platform playing by the rules. > Drop it from required_extensions so hardware without Zihintpause > still boots. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v1: > - rewrite commit message. I fear another round of re-writing is going to be necessary, sorry. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 12:31:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 12:31:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428766.1651707 (Exim 4.92) (envelope-from ) id 1x8zec-00046X-KM; Tue, 22 Sep 2026 12:31:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428766.1651707; Tue, 22 Sep 2026 12:31:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8zec-00046Q-H9; Tue, 22 Sep 2026 12:31:22 +0000 Received: by outflank-mailman (input) for mailman id 1428766; Tue, 22 Sep 2026 12:31:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8zeb-00046H-Rx for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:31:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8zeb-002t10-5P for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:31:21 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab27518-8faa-0a2a0a5109dd-0a2a4507cfac-2 for ; Tue, 22 Sep 2026 14:31:21 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab27518-b4ea-0a2a45070019-4a7de18da0bf-3 for ; Tue, 22 Sep 2026 14:31:20 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e8185e037so23575255e9.3 for ; Tue, 22 Sep 2026 05:31:20 -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-49fdad53c7dsm44649225e9.12.2026.09.22.05.31.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 05:31:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790080280; x=1790685080; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=+92Dl39HqApT06XXPezMG+SG8nsAQtZw+yIjN81Wtug=; b=b5rEgd3HRXJXl8W976uw2Lx2N2hiYyLlZ9ryFpO5CZ27UKf+HdjOAdR2Hii1xvM4pD qQ+RfkZ+CcehLeKePc9Y2gCO0m41fzUcrzskY03JRWG1cyGSUz+gHZY4J1UtJoQGfiQB 0lm0hORVqDrWkzR6h0w23PgwWUnOFlJrCzRDBvN0mjTTFziuMdtEWHZdhbILpkQKLqkW hBAmaNuU4du0TCX46Xo6uO3zp5SFfUCCbh6eaxColxBCIH6WIZUg3FAY30upBKPvqAql eh9zkkgwgzMbZTRH+VXJMFKn7oLyrokgfre/0yjBiiGECVapxTn4MptemvwYBeMMQZLq VkTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790080280; x=1790685080; h=content-transfer-encoding:content-type: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:content-type; bh=+92Dl39HqApT06XXPezMG+SG8nsAQtZw+yIjN81Wtug=; b=tda9Ud9hQs17jxKpDyR7OahH8pul3bNEVj/VLOvA+qw2cabAVk9pCIGh45U8XCDdfa I7534LdENmtfjELDT77MA4SnxNbjv7wDsENNIiVf9Tko3U07bxeduaUHmbLBe86PXqjW yAHpXXPmUJy3kwPoS5upJafgN2D32/zOal6gXoeQ9VkfpDSVOwKctCfAkQ3U5WgV5osH +c/jJ6vG2PN6vzBkufgMvNEULuHEKu+tui3V+kse/0CR989LdPYkoLLDNL/DwYVmweHT FRYxlHaH6hAszB5gKH8v5+6Xa/uuPINrN6mcKeVxZCFxUWamhbe0c22Mkd6zD5KvOYGz Pqkw== X-Gm-Message-State: AFuF++kESR5JxjwHd53Vk8pZCB4CVr1xrX2uZ4kffJ0X/WzxLUMwzXB9 byuNV7PswZokbxM9iODQmi5z6zNJdCZyJjgBvOjAmfnkfan76/RxIjETI9bwPu89hw== X-Gm-Gg: AYBFou1iymHRnuCmm8yULAurGFN3urH4H1Tx+BccPnR9Er0PqBtDP/zQ+6XnKFxkDeq cpgTQhGlvRozdrmHIk3ZMJaB4oM1aljiDdkZS8+TexxiLqXhkxSOM0ZaULImCwcUYu45ks9Tza5 J6qti07bM45JRrRwl7Xc2UskaYPyRB+swD8mDNmzJKUSCpUIv3s1nyk02Npu6NWc8s4mzFjvHPX IaeFVW81HD9/85doWskY+pSvCs8fPKIq6zRne+PAbLum9r25mkv9h6wHwmGGPIySFeDrdSU2twp dQ2Z141ZSX/50pw020oHKI7y7Pgl1TbHilaE6eWg9XEveq49gq55VXJmU7sXnSnzxPBSevU/Jcw fwxAeLUWTVykowxmlEXoxKf45G7PKL6yrVOn3dKTGaUvX0ux28J8+CjlF3EAailSzUVvEHgRwiY aHdEMMdTTlkeRpkayynoryUYfclROvZvMNfQn7Hb6FqBkUT6fxNrBYVWtEKnUUkqJhNldwvmKl6 ye8WJ6O/89ryLXlyCTQkcDb4XJdr1Gzp6Jp8bQ9n0zG2sU= X-Received: by 2002:a05:600c:4505:b0:49a:a101:4157 with SMTP id 5b1f17b1804b1-49fc56db92fmr199087405e9.7.1790080279539; Tue, 22 Sep 2026 05:31:19 -0700 (PDT) Message-ID: <89defb83-6e1d-4961-b5f8-a425f093a25c@suse.com> Date: Tue, 22 Sep 2026 14:31:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/6] xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu() To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba238000c4f3@vates.tech> 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: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba238000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790080280-366DAAE4-E32E8335/0/0 X-purgate-type: clean X-purgate-size: 1329 On 10.09.2026 11:34, Baptiste Le Duc wrote: > The existing SFENCE.VMA before the satp write only orders the page table > stores from setup_initial_pagetables() against subsequent implicit reads. > It does not prevent the CPU from speculatively caching translations after > the fence retires. > > According to the RISC-V Privileged specification, implementations are > permitted to speculatively cache Bare-mode identity mappings. Furthermore, > selecting MODE=Bare (which happens during check_pgtbl_mode_support()) > requires zeroing the remaining fields of satp, causing ASID=0 to be > actively used in Bare mode. Consequently, the TLB can be polluted with Bare > identity mappings tagged with ASID=0. > > Once satp is written to enable Sv39 translation, these cached identity > mappings (tagged with ASID=0) can shadow the true Sv39 translations. This > would lead to translation failures since turn_on_mmu() jumps to a > non-identity-mapped linker address. > > Fix this by adding a post-satp-write SFENCE.VMA to invalidate any stale > translations (including Bare-mode identity mappings under ASID=0) before > jumping to the virtual address space. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Sep 22 12:43:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 12:43:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428777.1651715 (Exim 4.92) (envelope-from ) id 1x8zpx-0006Gr-KN; Tue, 22 Sep 2026 12:43:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428777.1651715; Tue, 22 Sep 2026 12:43:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8zpx-0006Gk-HX; Tue, 22 Sep 2026 12:43:05 +0000 Received: by outflank-mailman (input) for mailman id 1428777; Tue, 22 Sep 2026 12:43:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x8zpw-0006GZ-J9 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:43:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x8zpv-00AK7E-Ch for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:43:03 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab277cd-e002-0a2a0a5209dd-0a2a4503a432-48 for ; Tue, 22 Sep 2026 14:43:03 +0200 Received: from [74.125.225.103] (helo=mail-wr2-f39.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab277d7-fae8-0a2a45030019-4a7de167800b-3 for ; Tue, 22 Sep 2026 14:43:03 +0200 Received: by mail-wr2-f39.google.com with SMTP id ffacd0b85a97d-482f633ece3so3138701f8f.3 for ; Tue, 22 Sep 2026 05:43:03 -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 ffacd0b85a97d-488626d29dasm5250064f8f.0.2026.09.22.05.43.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 05:43:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790080983; x=1790685783; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=snXXMJlrgbggXfT1mZvFwn5OPCOQTYOMT8eZohQBErw=; b=PWsbYdITMhGN6dH0+YZnf/L7i5esLZ3RLSLRuHwkvHyS9rCQgxaI9oHWHBwEZE3eDH YBBoyQSQx2qQ25AlTZcHM3bL97aeEqE2/Zb5OmKWv68JDWUtxL6u+XV9W+fYavw+NeZC F5aEV/Fwzpn0ZH/nYETXzfpG9zgmdZX/wzUu82gVv9ILd6g0Am5/ON7lv0w5A/uciZDw L8UZZkYGb2UCU0IzSaLJNreFPr6QA2LqBrCoAttRULQNJ/RIsIEbLouFGHuvwCnv0xy7 4jSFuxcD9sNmFWrhLYcfIf8+WnN46W1wAx0YryHw1prh7pPVXT8YW1ss1wM9us4KyHMx 7iNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790080983; x=1790685783; h=content-transfer-encoding:content-type: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:content-type; bh=snXXMJlrgbggXfT1mZvFwn5OPCOQTYOMT8eZohQBErw=; b=DMM9QOJFUS+cOqf4oi6ckYTD9EDuOnk2xPw8qMpjJymwt5aMhhrCkNrlohaPPJWyu/ 7uSau1S0ahBD1rbMkpzJWE4H1hQAHcMn8RgI2g1W64bf+Wn0VvFZuAt5e+c/IYMu5PKP tHlkID12qrzQOSLLX6v4ylDP4QsGYyDG0vYxVmAVHkVxMk84vl4ePZ3il6ArYl35/3WA EFFYTd4GIauWjpluCC/V5zCrEFA02V9zR919JBbXsRUyUNd42SEKbmu+UgQbxxq141CU jUAbOhIdCDqdp4CKki3rQR4Ufr+MddRMJWj+DYTYL/zjpAZtoF2jG6dFFk5EW5xeOi6d UGMA== X-Gm-Message-State: AFuF++lPg+uIe2ydhanLIU7sbHa/VOwrAqDHj0G14eJFt1xnlRnHjijW 6QNTe5f2NCFfW9l4DPsCqO++NxtCsd+fyA7czK4WyqX0DHlQ60VyekY7EY2KGZB9xA== X-Gm-Gg: AYBFou0R4xBGkOR+mk3fdIWmSIDADB5jJ9t66oDe1JiPSEIKizpVXkalrdW6RF3jXU6 QO2f+nBRYFZ1r0R3fSDM81twxs2Pr3KDvY2raiAbMH+rlOBxaPiXJGRBnMw82imp7ceaPe3e/Kn VPz3D7M3tPJSmkzHHqj+aS1OtMsWJyQ9T6H0WLE2yOC39UJ9LYIkR0bhlPJr6BfPWaDCQCUMWQ5 9/SAtS89/vlhzYHErzedmNqGYTMptQddyJnR7Pq+oTDQGVrZkPGelEElxQXX0E/6hMrxox33Jji Rqb/oNyL9+62W+g6UNQOrbHvWzt4uPsW7h7pXmxkLjlSYa7fbLeBTEifJQPvmVqdqG9p4/lZSMf b0dEQrK3pItlbVUvJbF/S1fDomHW1JVaq03Jmh25sb+YII6n8YC8N5hKbOOu3YySziN4/m+VbzM WJXZl7BmnabtCmy32eR26sJhDvr/xe05v9nqctEA9Jw3yGOVb6cYm9/AX85AKimjCUG06Wzl/XU +ZZh2wZCyuO94TzL3dUsKgb4/+eoB+XK1HNtsR25QmZuPVyU+1lB6IpMhPgFlM= X-Received: by 2002:a05:6000:4685:b0:487:2385:e19c with SMTP id ffacd0b85a97d-4872385f827mr11459240f8f.0.1790080982623; Tue, 22 Sep 2026 05:43:02 -0700 (PDT) Message-ID: <0ebba54b-142b-4040-b4a8-938518e7672b@suse.com> Date: Tue, 22 Sep 2026 14:43:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 6/6] xen/riscv: fix level_map_mask truncation on load_start To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Zheng Zhang , Alistair Francis , Connor Davis , Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3@vates.tech> 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: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1790080983-6F8C54E9-EE386F89/0/0 X-purgate-type: clean X-purgate-size: 2588 On 10.09.2026 11:34, Baptiste Le Duc wrote: > check_pgtbl_mode_support() declares level_map_mask as bare `unsigned`, i.e. > a 32-bit type while it derives from a paddr_t which is in both RV32/RV64 a > 64-bit type. Storing that value into a 32-bit local silently drops any set > bits above bit 31. > > The mask is then used as: > > aligned_load_start = load_start & level_map_mask; > > load_start is `unsigned long` (64-bit on riscv64) and if it requires more > than 32 bits to represent, because load_start zero-extend to 64 bits, we > would drop some load_start's bits during the AND. > > Widen level_map_mask to `unsigned long`, matching the width of the physical > address. > > Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") > Reported-by: Zheng Zhang > Signed-off-by: Baptiste Le Duc The change is okay as is, so Reviewed-by: Jan Beulich But see below. > --- > Question: > I would think replacing unsigned long by paddr_t would be better in this > case but for consistency with other variables in the function I just kept > unsigned long. > > However, there are many variables in mm.c which are unsigned long while > they are, in reality, physical addresses and could technically be paddr_t. > Using paddr_t would also let us bypass the compiler's decision on what > unsigned long extends to (u32 or u64, depending on the target), and > therefore be more generic. I've seen similar code in Arm using this > convention, and found nothing on the mailing list explaining the original > choice of unsigned long over paddr_t. The mask here is applied to an incoming linear address, so imo unsigned long is the correct type. > --- a/xen/arch/riscv/mm.c > +++ b/xen/arch/riscv/mm.c > @@ -180,7 +180,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_desc *mmu_desc, > bool is_mode_supported = false; > unsigned int index; > unsigned int page_table_level = (mmu_desc->num_levels - 1); > - unsigned level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level); > + unsigned long level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level); > > unsigned long aligned_load_start = load_start & level_map_mask; level_map_mask is used exclusively here. Without that intermediate variable no problem would have existed in the first place. Hence perhaps worth considering unsigned long aligned_load_start = load_start & XEN_PT_LEVEL_MAP_MASK(page_table_level); as an alternative? Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 12:55:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 12:55:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428790.1651730 (Exim 4.92) (envelope-from ) id 1x901g-0008SC-OD; Tue, 22 Sep 2026 12:55:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428790.1651730; Tue, 22 Sep 2026 12:55:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x901g-0008S5-Ke; Tue, 22 Sep 2026 12:55:12 +0000 Received: by outflank-mailman (input) for mailman id 1428790; Tue, 22 Sep 2026 12:55:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x901f-0008Rs-Cr for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 12:55:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x901e-00HLst-PP for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:55:10 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab27aa2-bab6-0a2a0a5309dd-0a2a450ca090-20 for ; Tue, 22 Sep 2026 14:55:10 +0200 Received: from [52.101.43.59] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab27aac-f479-0a2a450c0019-34652b3bf27d-3 for ; Tue, 22 Sep 2026 14:55:10 +0200 Received: from CH7PR03MB7859.namprd03.prod.outlook.com (2603:10b6:610:24f::20) by SJ0PR03MB5421.namprd03.prod.outlook.com (2603:10b6:a03:289::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 12:55:06 +0000 Received: from CH7PR03MB7859.namprd03.prod.outlook.com ([fe80::967:59c2:d16:1fcf]) by CH7PR03MB7859.namprd03.prod.outlook.com ([fe80::967:59c2:d16:1fcf%6]) with mapi id 15.21.0451.014; Tue, 22 Sep 2026 12:55:06 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h+i2fPDUH683qhhcD7+UCmcWM+V2OUm+v9Pgae0lbL67d+OFuUkZFm5f46rbU6p91nmz7aASC2to2zMHvqr1BDnKPeL1Qo6R1SX25xaiODFN9DylVFdNR6AYmtvtJiiGLSd2n6w9pCZEVa7yQHftRr1/aMkdS4tyjZHLq4FrlvDIJcuMOvOlsJYD0watBd1uJ0qAPjd1AXNXQrCMV+bWjJrsLeAyWqoNQP7rxy0sn7IGpVy1wS3AjZY9Htl6RF3dBeKnhp3uUfRrekQNBLnsG2n1cwIbIum2iSRCO8mdEA+YBMdIGpG9Bfd79b/ML/e/NTNEvSnpWOto2umORTmZZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PMvDmdURcCKCX8S8qDj2J5NhrZcfw0jh8u43/yP7kPE=; b=GdTebdoaRwl3p/ZhHMVKCr71swKtxljW22YNPmkNlXsdER6mftd5Hu/99XRApE6a/BVDjMsMGfCGGvvhoV7HUdXIiA63Q8mGKm+skjyUQdlbUuO2r8BCorNjBISyPzeDPHor/LaQ+Plj/fC/gOEo+pusgN2ZEpQ0ZVBNrPDOPBSHyLql6wmeSWoNm3iYaUaogflqhtJM2+ay1CLU6y3eK14CT8T5gGm6A6abyo47P81VSqefzqWaP/FYQrXzpAenqz6dN7jHLhI1WpgQCTBDJHQbAFZzoK2MfXmJ2yh2WGhXFuNYZht58zxR1Of+iy4x9ZgMv31jLvGIVSu6xaf8Iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PMvDmdURcCKCX8S8qDj2J5NhrZcfw0jh8u43/yP7kPE=; b=V61M0xOjiX/wJCGcntXCZ/ApOnt7/Yaj5b9yKD1y231aQCSWTqVoeRZIqxXEqnvZ+3OVTLtFCr8x6UK8r0L1Chy2krjiUcRJud/6JNIRZH3VdizgVRlUw1Uu1PkXD9Puz55n9cA/ZZm0gQFGm7/3CXnLRKT/50YcQntd1b+eEDQ= From: Alex Brett To: "xen-devel@lists.xenproject.org" Subject: Xen Summit 2026 - "Nested Virt <-> WinPV drivers" design session notes Thread-Topic: Xen Summit 2026 - "Nested Virt <-> WinPV drivers" design session notes Thread-Index: AQHdSo9DZLcioeW9H02VyiyxNJb//w== Date: Tue, 22 Sep 2026 12:55:06 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH7PR03MB7859:EE_|SJ0PR03MB5421:EE_ x-ms-office365-filtering-correlation-id: 44e796d7-24c3-4456-cd54-08df18a8ba23 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|38070700021|3023799007|10067099003|56012099006|5023799004|11063799006|18002099003; x-microsoft-antispam-message-info: ml0Lj9Z3C57jteK2i+ID4Jhserpe0kJtXe53wLjPnS2H0L37uzJFKfMVmI6SQr7ccG363+ASAUx5I0dP454Y/+jKkfP1VuavR7CEGNSxKAKukvfTaN1WqTVJwNtnG7XvYGGhhAjRZ6Fjj0sYmGCNHSSrNE9hiYOCShlGVbfhb1aCWLt8forIs1Yn6S3UXrCEfCRGOYtZYjH1Gh7oZX8hP2YNdZRCMm8dVPc16mvqV3s+fY1wWWX7haIPTXWTQ4PsFeg0N4nlXA+WsT4ARaPwbcIbRB2BQzr6GuD8ru44JjICl42+e7IvA+IYKwTZg8jn4v57Gkk3c+1WptfNWMUPEt7U5sJB3HX3DM2g6pxTUEOyl3FI3YrsjAuGHm3C8PXnvm5JO+Un7PPftatpS9MF714vcBjcvrDNd7D/nDQLsctHMlo1W0zbciF3roGgT2EDGk8R8kB7XAsy7syJ/CXzbmYJhGkLJ+UN5B/tHlGwxWddL8fFPXVj/Cp1NxB6Q86F+8hxVLqUhJGGyBMuA6WPKUo1nKLdo3EEKN6xg4pJbbdlwTgpS3ugyiV9H7wPl0gSC8hSe0Ap0JfSDcNBMfKo4bSQbH/gVnBeqO4hq9nc7l4Fe65nnlCSddd9P7oVR6fiDXLl4G/E6QYzSWvozfkbxb7QLgfmDKLtVSBUdI4+jzo= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7859.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(38070700021)(3023799007)(10067099003)(56012099006)(5023799004)(11063799006)(18002099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?OxN7WKVMQGi8+0zjq7zpLXFtWbaey58otWKDGVDpLLzKyqdbL0uVK0gNjx?= =?iso-8859-1?Q?n+HvGcl/8YET3Lvyhz6aGqivFmhrlEnN+81soeKRxYTjPmpz2IyWlXoRHH?= =?iso-8859-1?Q?YAeGyzjJEhcQkG0GOYX4DvXXdIpPdewJ0MBe/6JlFQU3ywgZH6wccRw/Gi?= =?iso-8859-1?Q?7870OcrTj+IIgHjKQjFU2RkJ3Gh5N3Ny1luiCKcQc54Ms472FTEDykBfoW?= =?iso-8859-1?Q?SQNmZbS+5ecA7LAxBL+66xndr02SBMZ6i7LMfFhBbZ2Klyj58Iak19zMk1?= =?iso-8859-1?Q?3ffphbSQiTdLUbk+GD2VCdHzfKB2FFcnAGW+/65RLD16me8JxD/MQDkG22?= =?iso-8859-1?Q?teB5axyJfE2dvyWB8ZxI/oVhUw1fxjPwtUW+U5UUctp6V9dfcxMXUoUVEq?= =?iso-8859-1?Q?WZHCpt2TEP1ZZiYhgtAJvvzkWasCG9YzkVCmf7corVH4qzcZ6XqV2DSKRd?= =?iso-8859-1?Q?+xsWzdAhbUuihq0w4P8SXlKMoR/3dMNQFdhMRz9OtDRp6V/zK70wpMUXSS?= =?iso-8859-1?Q?Ix4RsiEfGtjKTE08zZvnLg5Wxs2YfBJka3bCquuQlhihiMCF1a/+lgcIqs?= =?iso-8859-1?Q?dxNpXxePQnzHMZMO0Mt1/VqLcIrbRvmgmgqgkQ3ugsb8Scg+Zno1WEYRq/?= =?iso-8859-1?Q?WieA4StFQpEEVoCmpbvwivRoZWiS/sz7B6Odv+Mjj3Ot78hcuq9+mTwsIP?= =?iso-8859-1?Q?uJ+UuwT9BZndxkY++FYedRyIyxbPDoRFmvJUJecgulFpCxj2X5gCKa+KbH?= =?iso-8859-1?Q?xKDlnMs/I7E1coSs9Ys/RHDg/TP8oZ0SfXNRk6r5gZOF0lwgfXHGNxrvTz?= =?iso-8859-1?Q?5ZlhnvN8XDRMMt7icGLPqgUsMTZjdjNa49SEapuTPuE2UUu+DIx4mX7EMj?= =?iso-8859-1?Q?ft+lqZmp8CG4nEKbgbm++eOOZcGS3ntYEVvrPhB3LY4H7kNl3mFQR3GHlW?= =?iso-8859-1?Q?D8IN3RzlsmUMvKg0zfpw1X6JxuSDjcE24/ZGEhLLGcgX+5cKdOL3gLyHzQ?= =?iso-8859-1?Q?3jqTI4nPZTvnThRb8JlSb0g7Qi4ssLIzDqLTYeFeL7GWGz1SMfEgo2zlaC?= =?iso-8859-1?Q?upWuQ0RgKvoVac9KvBpT89jLyjT2ya5zSD+1GyKvxYtPKhrGMskS6QQAbh?= =?iso-8859-1?Q?aJueAjkx91FFGUDAjCB/QT70DdEundmgoIEBeD/o1U/De2bgfWXY2X4zYI?= =?iso-8859-1?Q?WBkPplll/BzssCr1rtjm2DBloI2OwPWUAfx20RPG+a64Bbcmk3bYgT4IJQ?= =?iso-8859-1?Q?PsLTl3KmKo9NaSArViPlGcg/j5blrWlMUskYLKT+TmCMoJDJmrsSG0U4+N?= =?iso-8859-1?Q?EcDvwlW5Suk719DvTBMcMyBEkZ3AGQu+lTEm9uI2Oif0Q40N5kpA3FFxJk?= =?iso-8859-1?Q?xyIguUfafhHIQRPXrQAe1ZU9wX9v69wt7d049/yZii4KX++v11c2d9HeRg?= =?iso-8859-1?Q?0FKP4EHUYew9/7RUbRm40UOyKxgFQq3lb4ErjrVh97shCPojM1lVirGjTC?= =?iso-8859-1?Q?6M7oZeXZ1soMOWf2mnOU5TJTLmRH4kXY5K0stVCZs0PJY3evJBpr/btIkZ?= =?iso-8859-1?Q?bYvT2rnJnhOnQzwLJ7wIMeYSbmsT78wFdxxhdF4xsUhyEdXgg+LHpCeU00?= =?iso-8859-1?Q?BQb7uaXriIsri4JCbHIxuOmDzLYhdb1sCHIUYEOw/Ziv3G4aTUGMREViJd?= =?iso-8859-1?Q?gi8Afc3BKNi2LWEa7fuNM2fHfVOZcHx/ZUQSFZ/3CWA32gru285vD4LqVF?= =?iso-8859-1?Q?l/3OT4s0ELpxY7mibtd2s+oVr//YOk9CAE0+5Bxp2PI0vu?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7859.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44e796d7-24c3-4456-cd54-08df18a8ba23 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 12:55:06.5802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CAkwflQfo/FlVJig2xaVDn+9TBGnhJGrWJFASyqPKLPadIB58fU3JwmaBxdyiLQghVQZUSgjwyn8L9PGuhFVjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5421 X-purgate-ID: tlsNG-d25034/1790081710-51538A5B-90F97B5E/0/0 X-purgate-type: clean X-purgate-size: 3980 The following notes were taken during the design session on Thursday 17th= =A0September (https://design-sessions.xenproject.org/uid/discussion/disc_bp= kf1nkpeOyiAehjw4xN/view) titled "Nested Virt <-> WinPV drivers":=0A= =0A= This is an issue identified during XenServer's nested virt development.=0A= With HyperV, your nominal Windows machine becomes an L2 guest as the root p= artition under HyperV (~equivalent to Xen dom0). HyperV at L1 handles thing= s from the L2 (flowing via Xen at L0).=0A= Specifically this affects CPUID and VM(M)CALL operations - L1 handles these= and doesn't give the Xen parts that the PV drivers expect - consequence is= PV drivers are unable to communicate with Xen. 'Feature' of the design of = nesting.=0A= =0A= A Viridian enlightenment allows L1 to provide information to L0 as to which= L2 is the root partition. A workaround was implemented using this where Xe= n can modify the responses so the L2 still 'sees' Xen and can enable the dr= ivers. This relies on a _currently_ invalid input to HyperV, but this may f= ail in future so not a safe solution and not shippable.=0A= =0A= Tangent: Bromium. Different way of solving this problem, did all hypercalls= using the CPUID instruction (Intel doesn't permit you not to have an exit = on CPUID, AMD permits you not to intercept but everyone does). ABI for CPUI= D says nothing about high halves of the registers, so Bromium puts a magic = constant in high half that L0 can recognise, or if not present the nominal = L1 would still answer the normal CPUID.=0A= =0A= What are people's thoughts on such an approach?=0A= =A0 Would it be restricted to root partition? Yes.=0A= =A0=A0=0A= HyperV doesn't seem to have good provision for nested virt on hypervisors t= hat are not MS. Can we stick to just Viridian enlightenments in the nested = case and avoid the problem?=0A= =A0 Ideal world we'd do a full VMBus implementation and abandon the PV driv= ers but we can't (potential legal issues with doing so. Might change if MS = do an implementation in Linux which is rumoured, but no sign of this as thi= ngs stand - would be complete replacement of I/O model and not practical in= the timeframe of the nested virt project). Could be looked into in future,= but not a short term solution.=0A= =A0 HyperV knows about PCI and enables this for the root partition, but our= PV model uses hypercalls.=0A= =0A= Some questions to put to MS=0A= =A0 Never found a situation where the root partition doesn't have an identi= ty map=0A= =0A= Ballooning will break everything?=0A= =A0 Apparently MS has an API to add/remove memory that may be a solution he= re.=0A= =A0 Ballooning implementation in PV drivers uses API.=0A= =A0 Concern as to whether this API is designed for HyperV and not a nested = case like this?=0A= =A0 Tu would like to retain ballooning in the drivers. Andrew wants to make= it an admin choice (whereas currently it must be available even in dangero= us cases). Interaction with ABI enumeration questions...=0A= =0A= We have the Xen PCI platform device in HVM domains.=0A= =A0 Root partition will see this device, could we send hypercalls to it? In= principal maybe. Specific BAR for hypercalls where qemu tells the hypervis= or a specific range? Would mean every hypercall goes into x86 emulate! Mayb= e could have some sort of special flag?=0A= =A0 What would benefit be over CPUID mechanism? Don't need to check it's th= e root partition, can just do it by access to PCI device.=0A= =A0 Wouldn't work for PVH.=0A= =0A= Could we do something with an MMIO range? Can't have a Xen specific driver = use this as HyperV comes up before Xen drivers. Could declare in ACPI and t= hen Windows knows a driver can bind to it?=0A= =0A= We only want the root partition to be doing PV I/O to L0, not any L2 guest.= In a virtio model it'd be down to HyperV/root partition which guest it pas= ses the PCI device to.=0A= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:01:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:01:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428803.1651737 (Exim 4.92) (envelope-from ) id 1x907Q-0001zq-FB; Tue, 22 Sep 2026 13:01:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428803.1651737; Tue, 22 Sep 2026 13:01:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x907Q-0001zj-CQ; Tue, 22 Sep 2026 13:01:08 +0000 Received: by outflank-mailman (input) for mailman id 1428803; Tue, 22 Sep 2026 13:01:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x907P-0001zZ-H2 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:01:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x907O-005niM-Cq for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:01:06 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab27c12-8faa-0a2a0a5109dd-0a2a4508e44c-0 for ; Tue, 22 Sep 2026 15:01:06 +0200 Received: from [74.125.229.205] (helo=mail-lf2-f13.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab27c12-f659-0a2a45080019-4a7de5cdebb3-3 for ; Tue, 22 Sep 2026 15:01:06 +0200 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b8c9954ccbso2450394e87.1 for ; Tue, 22 Sep 2026 06:01:06 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b8d46ad0b5sm487273e87.5.2026.09.22.06.01.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 06:01:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790082066; x=1790686866; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tnQ0ideIs48MmX8Q0RhKG0Die5lKQw6VCxIcqz/H+aY=; b=DI5O1TphM6UaU9FsS5vtqW7pWvHqpgtByw4HqIWUI5H0te6xNGO6l6G+q9gmA3gG6m qTeqNETMZC7I3mWjC2+ascux1hvWRZw2Q0TQMmyZ1zAuiLNzcQk/1UFsrB5TQwuI3Wgo wb67Ssy8WvdgmkNc11wsESo/f2k76debHnxnG3LadLcLuzGct0lh565sBZpxEkBP3WJ/ oMATJEKZ37AUH9/QaXWaJMCdAncHNF34qlDsQQnwRkaDuQuzoXzw4DCyEu7lBfFpAwtp k/mCQYNUWF0OoMm15KL5pOMvxOEOatxs1Wqms+7dbhxrOLhET+qMuyhohwAy84TYmaq7 F7tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790082066; x=1790686866; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=tnQ0ideIs48MmX8Q0RhKG0Die5lKQw6VCxIcqz/H+aY=; b=p5KppfoSsYENHH3RI87kIeG88ud+UyX55g6qPhj07cSgqo9EKHliyZ7LRUEEiJpuKJ WElwxjYi95fsTH1Jafn3jS31klUwbL1XCUtRwdid5XQdOZhoX/jOktrDYMC0VapES2V6 OAw8ZIUrh91ZT+jRNMJ92AWyfm7Ca9m5Jn0NoC+KhzyDy2YGnLBFcmi9GaMa3hL3kpXT Ml//RKUESW0uZtHjGY08A3o+zWbQieBi2cMRhRx6ybv5NfnIs+H65ldXx1VxFhQUzL4e ry4EyRzooS4cyjmM/Uuxpq35COv0uI5ZJ2DmM28+EI7z7MHS67EQhuwYRBahN5J4vs/A 9sGw== X-Forwarded-Encrypted: i=1; AKwUvBwsSVjuqWVh5kuJkORSglEUqueK8+O+chniEI9kccs+IZLk/M8hLbEwG6O2JkZZ35CRCVPPPDH2t6c=@lists.xenproject.org X-Gm-Message-State: AFuF++mX2S54a3rku1FM+z1a3BXGbGME/U657Y+zWIyHKbFY7igqjnaR k5SICkjhVdTpU5Nts8qVZoDu81TaeRPb08kzss+KcdM0linuV3LVEAFy X-Gm-Gg: AYBFou1aKuRCOXvCRPjGruk/Y4lo7X7p52fcL9SAMozkz+fbEIqHQ2cBEjT+RULT+e8 ZCjr6BUr/PMdmTBPlN0NxSPnlKdvIQRSPOKgDXrbpxI+T3KoPz7mjXtpXjuozZBtZDrFNRqGIFp kzATU/3z83WQGuKyqOIpjfzBRTVM90Wic5n1wi7h6cRmjOYiMkkNvGhivaMxV5UipsiT1HoMMNC ICsik5gZPNn/z9hAkSA7AYaw6TQEZX0O7xW8AEfT124z1ig6UOx3zIpSAtkIUvKVA9EPYPdp0Su OKgqFAiCWnbKydQXfvUvWBwlZATOp6A2SIrrzqBIgilEzIMqMr76Q2s/JDfs8V1M1Qk99FbqwT7 VmBdLBripyn7Xpraj9H771Mx9DFnc8enxT4jHYmBV2LujAYjHCJD6NJffZhrESikEKFrllOA/Lm S4sglcHTFBwVUnYx4ONnGaZh+OjUCce6pf9U/mkb0DNiIn/yjHbUiqrXdHLG4ThMZKzA/s2xn1T c9+cNiWhffxtdcD76LhLeilgEP4AJMtUaUyNj+Vq6f5XiOG4w== X-Received: by 2002:a05:6512:3ca5:b0:5b7:674f:cab8 with SMTP id 2adb3069b0e04-5b8c1821977mr4869113e87.15.1790082065147; Tue, 22 Sep 2026 06:01:05 -0700 (PDT) Message-ID: <5b70c0d6-12ec-429c-be9c-a96d78d48e68@gmail.com> Date: Tue, 22 Sep 2026 15:01:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file To: Baptiste Le Duc , xen-devel@lists.xenproject.org Cc: Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> <1790007309.8631fc262581453bbf619ec5b2062170.1a0c4bff57900072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790007309.8631fc262581453bbf619ec5b2062170.1a0c4bff57900072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790082066-CDB4987B-8BABB209/10/73395122804 X-purgate-type: spam X-purgate-size: 9602 On 9/21/26 6:15 PM, Baptiste Le Duc wrote: > > > On 8/27/26 5:24 PM, Oleksii Kurochko wrote: >> Implement first steps of migration a vCPU to a different guest >> interrupt file >> procedure: >> - At the old interrupt file, save to memory the values of registers >>    eidelivery and eithreshold, and set eidelivery = 0. >> - At the new interrupt file, set eidelivery = 0, and zero all >>    implemented interrupt-pending bits (the eip array). >> >> The following steps will be introduced in follow-up patches. >> >> Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to >> guard >> against silent incorrect behaviour or unexpected panics in guest VMs >> until >> the function is fully implemented. >> >> vgein_assign() will be introduced later in a separate patch, for not >> it is >> only stub. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v2: >>   - New patch. >> --- >> --- >>   xen/arch/riscv/aia.c             |   9 ++ >>   xen/arch/riscv/imsic.c           | 159 +++++++++++++++++++++++++++++++ >>   xen/arch/riscv/include/asm/aia.h |   4 + >>   xen/include/xen/config.h         |   1 + >>   4 files changed, 173 insertions(+) >> >> diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c >> index e31c9c2d24b6..75c82bcfa1b3 100644 >> --- a/xen/arch/riscv/aia.c >> +++ b/xen/arch/riscv/aia.c >> @@ -1,8 +1,10 @@ >>   /* SPDX-License-Identifier: GPL-2.0-only */ >> +#include >>   #include >>   #include >>   #include >> +#include >>   #include >>   #include >> @@ -21,3 +23,10 @@ void __init aia_init(void) >>       _aia_usable = true; >>   } >> + >> +unsigned int vgein_assign(struct vcpu *v) >> +{ >> +    BUG_ON("unimplemented\n"); >> + >> +    return 0; >> +} >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c >> index ad7fbe708bfd..516f0105352a 100644 >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -26,6 +26,7 @@ >>   #include >>   #include >> +#include >>   #include >>   #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * >> IMSIC_MMIO_PAGE_SZ) >> @@ -77,6 +78,64 @@ do {                            \ >>       csr_clear(CSR_SIREG, v);    \ >>   } while (0) >> +#define imsic_vs_csr_write(c, v)    \ >> +do {                                \ >> +    csr_write(CSR_VSISELECT, (c));  \ >> +    csr_write(CSR_VSIREG, (v));     \ >> +} while ( 0 ) >> + >> +/* >> + * Generic switchcase expansion pyramid. >> + * F is the per-operation leaf macro, ireg is the base register index. >> + * Optional extra args (e.g. an operation and/or a value) are >> forwarded to F >> + * via __VA_ARGS__. >> + * >> + * imsic_switchcase_break(ireg, op, v) - emit "case ireg: op(ireg,v); >> break;" >> + * imsic_switchcase_ret(ireg, op, ...) - emit "case ireg: return >> op(ireg[,v]);" >> + *   The variadic tail is optional so the same leaf works for both >> read (no v) >> + *   and swap (with v). >> + */ >> +#define imsic_switchcase_break(ireg, op, v) \ >> +    case ireg:                              \ >> +        op(ireg, v);                        \ >> +        break; >> + >> +#define imsic_switchcase_ret(ireg, op, ...) \ >> +    case ireg:                              \ >> +        return op(ireg, ##__VA_ARGS__); >> + >> +#define imsic_switchcase_2(F, ireg, ...)    \ >> +    F(ireg + 0, ##__VA_ARGS__)              \ >> +    F(ireg + 1, ##__VA_ARGS__) >> +#define imsic_switchcase_4(F, ireg, ...)    \ >> +    imsic_switchcase_2(F, ireg + 0, ##__VA_ARGS__)  \ >> +    imsic_switchcase_2(F, ireg + 2, ##__VA_ARGS__) >> +#define imsic_switchcase_8(F, ireg, ...)    \ >> +    imsic_switchcase_4(F, ireg + 0, ##__VA_ARGS__)  \ >> +    imsic_switchcase_4(F, ireg + 4, ##__VA_ARGS__) >> +#define imsic_switchcase_16(F, ireg, ...)   \ >> +    imsic_switchcase_8(F, ireg + 0, ##__VA_ARGS__)  \ >> +    imsic_switchcase_8(F, ireg + 8, ##__VA_ARGS__) >> +#define imsic_switchcase_32(F, ireg, ...)   \ >> +    imsic_switchcase_16(F, ireg + 0, ##__VA_ARGS__) \ >> +    imsic_switchcase_16(F, ireg + 16, ##__VA_ARGS__) >> +#define imsic_switchcase_64(F, ireg, ...)   \ >> +    imsic_switchcase_32(F, ireg + 0, ##__VA_ARGS__) \ >> +    imsic_switchcase_32(F, ireg + 32, ##__VA_ARGS__) >> + >> +static void imsic_eix_write(unsigned int ireg, unsigned long val) >> +{ >> +    switch ( ireg ) >> +    { >> +    imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIP0, >> +                        imsic_vs_csr_write, val) >> +    imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIE0, >> +                        imsic_vs_csr_write, val) >> +    default: >> +        ASSERT_UNREACHABLE(); >> +    } >> +} >> + >>   unsigned int vcpu_guest_file_id(const struct vcpu *v) >>   { >>       return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); >> @@ -389,6 +448,76 @@ int cf_check vcpu_imsic_init(struct vcpu *v) >>       return 0; >>   } >> +/* >> + * Arguments of the imsic_vsfile_local_*() helpers, which are >> executed by the >> + * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). >> + */ >> +struct imsic_vsfile_data { >> +    unsigned int hgei; >> +    unsigned int nr_eix; >> +    struct imsic_mrif *mrif; >> +}; >> + >> +/* >> + * Execute func() on the pCPU which owns the IMSIC interrupt file >> func() is >> + * going to work with. >> + * >> + * An IMSIC VS-file is reachable only through hstatus.VGEIN of the >> hart the >> + * file belongs to, and a guest interrupt file index is meaningless >> on any >> + * other hart, so such work always has to be done by that very hart. >> + * >> + * The local case runs with IRQs disabled to provide func() with the >> same >> + * environment it is given when it is called from the function call IPI >> + * handler. >> + */ >> +static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), >> +                              void *data) >> +{ >> +    if ( cpu == smp_processor_id() ) >> +    { >> +        unsigned long flags; >> + >> +        local_irq_save(flags); >> +        func(data); >> +        local_irq_restore(flags); >> +    } >> +    else >> +        on_selected_cpus(cpumask_of(cpu), func, data, 1); >> +} >> + >> +static void cf_check imsic_vsfile_local_clear(void *data) > I think the remark from Jan to direclty pass the type instead of void > could be applied here. I think it can't because of how function pointer is passed to on_selected_cpus() through imsic_call_on_cpu(). >> +{ >> +    unsigned int i; >> +    const struct imsic_vsfile_data *idata = data; >> +    unsigned long new_hstatus, old_hstatus, old_vsiselect; >> + >> +    /* We can only zero-out if we have a IMSIC VS-file */ >> +    if ( !idata->hgei ) >> +        return; >> + >> +    old_vsiselect = csr_read(CSR_VSISELECT); >> +    old_hstatus = csr_read(CSR_HSTATUS); >> +    new_hstatus = old_hstatus & ~HSTATUS_VGEIN; >> +    new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); >> +    csr_write(CSR_HSTATUS, new_hstatus); >> + >> +    imsic_vs_csr_write(IMSIC_EIDELIVERY, 0); >> +    imsic_vs_csr_write(IMSIC_EITHRESHOLD, 0); >> + >> +    for ( i = 0; i < idata->nr_eix; i++ ) >> +    { >> +        imsic_eix_write(IMSIC_EIP0 + i * 2, 0); >> +        imsic_eix_write(IMSIC_EIE0 + i * 2, 0); >> +#ifdef CONFIG_RISCV_32 >> +        imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); >> +        imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); >> +#endif >> +    } >> + >> +    csr_write(CSR_HSTATUS, old_hstatus); >> +    csr_write(CSR_VSISELECT, old_vsiselect); >> +} >> + >>   void cf_check vcpu_imsic_deinit(struct vcpu *v) >>   { >>       XVFREE(v->arch.vimsic_state); >> @@ -689,6 +818,14 @@ int __init vimsic_make_domu_dt_node(struct >> kernel_info *kinfo, >>   void imsic_migrate_vcpu(struct vcpu *v) >>   { >> +    unsigned int new_vsfile_hgei; >> +    unsigned int new_vsfile_cpu; >> +    unsigned int nr_hw_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, >> +                                          BITS_PER_TYPE(uint64_t)); > This value appears to remain constant after initialization, since it > depends directly on the hw, > so it is not necessary to calculate it each time. I will add then: --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ struct imsic_config { /* Number off interrupt identities */ unsigned int nr_ids; + /* + * Number of 64-bit EIx groups needed to cover all the interrupt + * identities, which are 0 (never valid, but it still occupies a bit) up + * to and including nr_ids. + */ + unsigned int nr_eix; + and init it once in imsic_parse_node(). Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:06:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:06:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428812.1651746 (Exim 4.92) (envelope-from ) id 1x90Cn-0002oV-1D; Tue, 22 Sep 2026 13:06:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428812.1651746; Tue, 22 Sep 2026 13:06:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90Cm-0002oO-UO; Tue, 22 Sep 2026 13:06:40 +0000 Received: by outflank-mailman (input) for mailman id 1428812; Tue, 22 Sep 2026 13:06:39 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90Cl-0002oC-EL for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:06:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x90Ck-00A0xG-BO for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:06:38 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab27d58-8faa-0a2a0a5109dd-0a2a4507a6a6-36 for ; Tue, 22 Sep 2026 15:06:38 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab27d5e-b4ea-0a2a45070019-4a7de18dd5ea-3 for ; Tue, 22 Sep 2026 15:06:38 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912e2406so21496995e9.1 for ; Tue, 22 Sep 2026 06:06:38 -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-49fd8b97385sm81301225e9.2.2026.09.22.06.06.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 06:06:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790082398; x=1790687198; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=2n3wz7G08GTlWfh01lt1v39ZqHI/IUXS8V3S9RLV6/I=; b=XjRRy18zPmk8W0DUD9gtupx/iMzef9FUz/7uXEo9iCfZ023ERt21o2iw5UT7b1sU3c lWykhawnIWjCtvjgOhyFL9wyvM7nbGjhGguIBbYyJIRVuDRAbXf9iI+idLFuk5xi7AMF 5yl1y5ZpVk7aLflutQ/pV9jTgz5bFT+YIYCTmZ1NAOTocyZ+H35maszNm/X+nDGi7Nxq TU4HDM9THkxEt2RtDwFImJA1zWdfwtS7Sbvo9c1Xdx0EsT1G8gc9epNucoyfgYeBvzEa B4okDXF2qrYnSX08RUhOte1BEBmzpA8n9zfW4BnBE+Izm3FCgfLzrOyJX90fEuM26RAJ KmBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790082398; x=1790687198; h=content-transfer-encoding:content-type: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:content-type; bh=2n3wz7G08GTlWfh01lt1v39ZqHI/IUXS8V3S9RLV6/I=; b=Msv3Jc3zeFK49BIadw3qagr5wQap2L3+msz9HphDWewHpbe/aaE1g2Fa245o53NUxL ojvVqu7yXEaexp0SZZqQWF2w8ZQC2t5Z5Nz1mUdFkLt7S0LeRlsjZdiEvchQTt50tYjp /HmOmMxr1FplqaFXUC4hJjnrS0TDFKRCDet6rvBQzwnkPxuuCn5Qo6KLt5KUQCiwmGvH 1uivp13P9Hj/DMG2MXavVQGqeQxJaDCP9aZTkJ7AYMplJ25zZXlT4vC1kzYhdI6Sew6/ UKBCFOkFOSZ82QuykMytO6z6aobc6ckLHL7rh/V6n0QQhxU5/fHG30Fj2WsUL4wSAE3x 3BJA== X-Forwarded-Encrypted: i=1; AKwUvBwo8DT/e1+mBpXTH7IxlutGUkDDSO1dprAoTab4DgNPcl/ZZXCGA3oLXimaUTXS/OyKlC52DCzshkM=@lists.xenproject.org X-Gm-Message-State: AFuF++m8AhexsBUhZyv9iFi62pkxHvHgcpjdSPYngigEJb/44PjtiuS0 QTY9AZmmUIfd6/b2HqQJbvuw32H1UQAJk6jtg5SOtH3NM8kpXVKVa1r+N5jiqRsj4g== X-Gm-Gg: AYBFou2YLh7MP08+dWA670K2Cwmu7NMNqAnPYyksGsv029CwLqU1mbeAxrL3EOcX93C hB1n12h/b0ZmX4HW9qwUi7cjKCAPkb0Dbm4H3TctRuAATf0KiNbEJwi9blXQbCfEM2J+MezU3xe 0ftCjZrinOUTrE29pgcU9gY6EkeUu/sIU7BEmQOf4UYQUk0a56qsrq6vqGGYJNrmuKq4rpPCpU+ lS+b+PFra/wzYPjfp9TmlNAbRpCRuRh4dAsRqxfBtkNdnHr0n4V7otFX0AcwqXwU/cmFB+02062 lOHUN5U7eDNdJATWIp6v/g7qU4bVpeL/+J0x4j438CVous8wJd/IyGtBFbxIP6Pqb46CCXXOx7O GQeuz5wNOEicrAPgUG7RrV0GIwvqKlYdAq8VYL35YgPZaISZ8nr0QNoOWvbmQnUix0AWuPTW0I2 76shb7n4gmK78ObaIbh4Bacgme14s/HeRLuXfGNOUIJ4hpJ9pK3GBAoVqWzX+hhpJDVkokKwsuZ Vy50bJE0nse8cBh9zyH7HdnetlBDIPwNEQjlxa8WigXL8QHfuHOj/uHQnGci7Q= X-Received: by 2002:a05:600d:8642:10b0:49e:6865:904e with SMTP id 5b1f17b1804b1-49fd8a65f21mr30545025e9.12.1790082397037; Tue, 22 Sep 2026 06:06:37 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 15:06:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: Anthony PERARD , Andrew Cooper , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20250904114202.2722478-1-marmarek@invisiblethingslab.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: <20250904114202.2722478-1-marmarek@invisiblethingslab.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790082398-A54C3AE4-9B19C9BC/0/0 X-purgate-type: clean X-purgate-size: 1816 On 04.09.2025 13:41, Marek Marczykowski-Górecki wrote: > Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's > available in earlier toolchain versions. But use it together with > -fmacro-prefix-map (if available) for hypervisor build, otherwise it > still contains some paths in out-of-tree builds. > > The out of tree build requires -fdebug-prefix-map mapping for both source > dir and object dir - otherwise the latter is included (2 occurrences) in > xen-syms. Note the ./xen path for out of tree builds may not be strictly > correct choice, but it's consistent across the tree, and just require > starting debugger from the source, not object, directory. > > Ensure to have a realpath for XEN_ROOT else it fails to substitute > properly paths in strings sections. > > Signed-off-by: Marek Marczykowski-Górecki Coming back to this, as it was also mentioned at the summit. > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -1,4 +1,4 @@ > -XEN_ROOT = $(CURDIR)/.. > +XEN_ROOT = $(realpath $(CURDIR)/..) $(realpath ...) may not be available (with older make), it wants to be $(call realpath, ...), allowing use of the fallback in ./Config.mk. I'm further not really sure if $(realpath ...) is actually meant here; to me $(abspath ...) would seem more logical (as we don't want to resolve symlinks in the path, but rather keep it as specified / seen). And finally - isn't the above rendering redundant ... > --- a/tools/Rules.mk > +++ b/tools/Rules.mk > @@ -166,6 +166,8 @@ endif > CFLAGS-$(CONFIG_X86_32) += $(call cc-option,$(CC),-mno-tls-direct-seg-refs) > CFLAGS += $(CFLAGS-y) > > +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=$(realpath $(XEN_ROOT))=.) ... the use of $(realpath ...) here? Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:23:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:23:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428835.1651756 (Exim 4.92) (envelope-from ) id 1x90Sg-0006Wr-9g; Tue, 22 Sep 2026 13:23:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428835.1651756; Tue, 22 Sep 2026 13:23:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90Sg-0006Wk-6o; Tue, 22 Sep 2026 13:23:06 +0000 Received: by outflank-mailman (input) for mailman id 1428835; Tue, 22 Sep 2026 13:23:05 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90Se-0006WX-M7 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:23:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x90Sd-00G3uD-HR for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:23:03 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2812c-2eae-0a2a0a5409dd-0a2a4502c746-12 for ; Tue, 22 Sep 2026 15:23:03 +0200 Received: from [202.12.124.144] (helo=fout-b1-smtp.messagingengine.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28131-6ca4-0a2a45020019-ca0c7c90eb61-3 for ; Tue, 22 Sep 2026 15:22:57 +0200 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.stl.internal (Postfix) with ESMTP id 6DF961D0009D; Tue, 22 Sep 2026 09:22:56 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 22 Sep 2026 09:22:56 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Sep 2026 09:22:54 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1790083376; x=1790169776; bh=8yLYVHJ6jNzwsHMgG8xS1Ovb4UA04vsZw/QYJZxSTJI=; b= X2ypO5wa3iO9/WOfyPan5UDJcstQ/iIZO8ZhmMI7WI/ShG5xQwz2lBfxZm4CQHfM S+kF8r7kJNl188Vlhw6T0Ej8ocpDirFuhCQAbwIfMziP+YVjAJq/x7LFmearYekN 5AMtSzTmFWobxTnA2Fa6Fw7MvPGG3uvrZYOikSajG6rhYqwizFwsIQ29BJGWGTko RuU4Ye8h0bBgrLWQi+s5CccTRCcgR6noEYDJTAeyJllFlVk3Mbzx+ZxwdcTBnXss 9FHo0AJm9YjpVYqtnO15OcWdMu18PEOsNv7TMwYGj6KmwmwyAKFOlvjBPKtEfpPt TEMQWs6Ql4cyHTzlXUwzJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1790083376; x=1790169776; bh=8yLYVHJ6jNzwsHMgG8xS1Ovb4UA04vsZw/Q YJZxSTJI=; b=i0nALIbfl7oxb6z9DtuhZVBboe4ijUGOMuZeJpZPLr1bbTqXzka aEC6GsFZmPeG1bVv61bPK0G+QBcsiwHtmdBa3/sg589hXpRF41SL+gF0O1We5oWl Usimv9UfK5nAFHjZdJPCglGfJds/Lld4b3bZkQSB9HcNAPDisxQ+OJaOz3ouPkiB A6nW4W78kF9ZMUZSonHnpZQZl1e3W7gyHx0pg605P85aZpMBhl+1wLWbhGL5FEUG vvZxyHt12m2OeYp/+VnPWGZrIoxxnCNIg4hB3APAqGpTLsyIK7ZLxwhx+Ih3XeG9 /xFtvWs5tIdhjeydkPVZhsd9at+ZUKGhZng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGfELLFfugd19QwWNMUx/tN0RfiMI7ehPd4jmxTb0QXU0+VfZjqDjZOAKNphemAil rmqN74zJleUWWCqI8Trx5U9i1ROrF++RFTlMWaBw7cUhxMLH9xkcZj3HgwVZa3CJl4oqZ9 lN0pxKfKfXSt+WJIZt8blUxdlCJ1cfqZQXCyrtfOFP7+e7Rut5ssK16fr6BMz9Qla3SAlC NgL5Ul00WvBCgLWKloTgd40nKH3+iS5SuD9/2cJ2baFinZ+aa+USU3OH8TvjYOnGec3g/1 BUdDuHPQH8IY3TqIdqNpy0OMvH3c8Xt0QEiim/6SMx4Fae3jEKCXbFjFJHhQrIUV/1Xwjv vnk05nWlshLTR7N9Nxw8qqE0VH+UGV7CJsuJfwhxx9IOzEyIbcmK4eNuqNBvkUba6PupyQ nINvJLCGKguSugVtLxwRbYGP7EYoVReXPPmuetCsziet0J4JmJVViQbrDBcVNYz6ZLcWrU 5R+B15C4ABX3rmQeoIHfeL6IZpNG8j13N0J2/wHkIdumiexEL6AxHNXMb5hQlx3JbPg+ml vy8CjjoRoBhMSq2OwIqBhhsf/lnozxl6rnDu8+hzOV/0qu8yRit7lAZ6aMAOdm8r8ZmZpF pdzto7JsTUryzvI1RZhMqj7Sinf2szIfmWgPCWJrrNjuPoQk1WToOPXz4vmQ X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 22 Sep 2026 15:22:52 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Anthony PERARD , Andrew Cooper , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?TW9ubsOp?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor Message-ID: References: <20250904114202.2722478-1-marmarek@invisiblethingslab.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kSAC0yivbSsstiZu" Content-Disposition: inline In-Reply-To: X-purgate-ID: tlsNG-720697/1790083383-315CD2AC-62A64731/0/0 X-purgate-type: clean X-purgate-size: 3768 --kSAC0yivbSsstiZu Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2026 15:22:52 +0200 From: Marek =?utf-8?B?PT91dGYtOD9RP01hcmN6eWtvd3NraS1HPUMzPUIzcmVja2k/PQ==?= To: Jan Beulich Cc: Anthony PERARD , Andrew Cooper , Michal Orzel , Julien Grall , Roger Pau =?utf-8?B?PT91dGYtOD9CP1RXOXVic09wPz0=?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] Strip build path directories in tools and hypervisor On Tue, Sep 22, 2026 at 03:06:35PM +0200, Jan Beulich wrote: > On 04.09.2025 13:41, Marek Marczykowski-G=C3=B3recki wrote: > > Use -fdebug-prefix-map in preference to -ffile-prefix-map, as it's > > available in earlier toolchain versions. But use it together with > > -fmacro-prefix-map (if available) for hypervisor build, otherwise it > > still contains some paths in out-of-tree builds. > >=20 > > The out of tree build requires -fdebug-prefix-map mapping for both sour= ce > > dir and object dir - otherwise the latter is included (2 occurrences) in > > xen-syms. Note the ./xen path for out of tree builds may not be strictly > > correct choice, but it's consistent across the tree, and just require > > starting debugger from the source, not object, directory. > >=20 > > Ensure to have a realpath for XEN_ROOT else it fails to substitute > > properly paths in strings sections. > >=20 > > Signed-off-by: Marek Marczykowski-G=C3=B3recki >=20 > Coming back to this, as it was also mentioned at the summit. >=20 > > --- a/tools/Makefile > > +++ b/tools/Makefile > > @@ -1,4 +1,4 @@ > > -XEN_ROOT =3D $(CURDIR)/.. > > +XEN_ROOT =3D $(realpath $(CURDIR)/..) >=20 > $(realpath ...) may not be available (with older make), it wants to be > $(call realpath, ...), allowing use of the fallback in ./Config.mk. >=20 > I'm further not really sure if $(realpath ...) is actually meant here; > to me $(abspath ...) would seem more logical (as we don't want to > resolve symlinks in the path, but rather keep it as specified / seen). Honestly, I don't remember all the details a year later... But I think, based on the commit message, there was some case where XEN_ROOT needed to textually match the actual directory, possibly when some other part of the build system embedded a resolved path to the binary anyway. > And finally - isn't the above rendering redundant ... >=20 > > --- a/tools/Rules.mk > > +++ b/tools/Rules.mk > > @@ -166,6 +166,8 @@ endif > > CFLAGS-$(CONFIG_X86_32) +=3D $(call cc-option,$(CC),-mno-tls-direct-se= g-refs) > > CFLAGS +=3D $(CFLAGS-y) > > =20 > > +$(call cc-option-add,CFLAGS,CC,-fdebug-prefix-map=3D$(realpath $(XEN_R= OOT))=3D.) >=20 > ... the use of $(realpath ...) here? This seems to be correct observation. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --kSAC0yivbSsstiZu Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmqygSwACgkQ24/THMrX 1yx4jwf/RGmjRI1+CvVrXCsM219ug75nn/KNfZ/hfgZxSSCwc+/guiTyj0DYeBTy 6Y3/9+yMbUk/whSO/JGN7u6TCRasbuhozet3JuE6OO7VOij6zoqFFYDYfJuy/Xmo sN5gEtFZNoYgqfv7m/JR63wC6dCkT4aFAhkA+eaH3LQtleVInrAYu9zBn396ervu Qz/rY9e8jS8uiklBJVzt3gehf0bL9+pIPlRvHSpgvm1UccICyaq1So+suVRvZeWE FeZHYPWqdFOEtuOT5gvvZu8OmMMV3NlUT+PaaILsE01Dhof2P1wLc5UVFfyzieKF EiD26Fduz/YW2SWImIHCqiIl/GqTMQ== =9tOx -----END PGP SIGNATURE----- --kSAC0yivbSsstiZu-- From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:34:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:34:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428851.1651764 (Exim 4.92) (envelope-from ) id 1x90dZ-0001fd-9e; Tue, 22 Sep 2026 13:34:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428851.1651764; Tue, 22 Sep 2026 13:34:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90dZ-0001fW-6o; Tue, 22 Sep 2026 13:34:21 +0000 Received: by outflank-mailman (input) for mailman id 1428851; Tue, 22 Sep 2026 13:34:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90dX-0001fI-P0 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:34:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x90dW-00G6SM-EI for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:34:18 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab283d1-8faa-0a2a0a5109dd-0a2a450a86e4-24 for ; Tue, 22 Sep 2026 15:34:17 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab283d9-f2d2-0a2a450a0019-4a7de18dbe2d-3 for ; Tue, 22 Sep 2026 15:34:17 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49ccf3ca626so21686895e9.0 for ; Tue, 22 Sep 2026 06:34:17 -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 ffacd0b85a97d-4886277e84dsm5608092f8f.20.2026.09.22.06.34.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 06:34:16 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790084057; x=1790688857; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=e4Ryrx73BEQdCje8/y/wl1Qw7FCFzVnkirAvpC6A43E=; b=CoHYzCvRPYVBfrzzcH/nnl6vN7VpWymYIkAjiQvMvIAI0azqrJsqsc2I+gIfF88p2s CH3Lbfay5c7XBOYxOGJ0PZOTM8JD81gO3m+moR2ziWutxLxelSgNnDOaFJgup0ukrOZ3 kcDBa5e1Et5reNGYpCrLrtfgGchWLi079YmQqlw4IUJGx1pHI/nBjKvVzQ4gU0hTigML Ua/mfbXhNVCe8A7B532Utqm+HC0GyBsZaCil35HUbVBHndQ4OKkod+o/7nrc37JTE2F6 fKrjLeH2Yn+njMITRKX8UqGLmTS7Rraje+t/It4BIPybWqWv7Oed0aFMSQcFxEy9oPpL q3BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790084057; x=1790688857; h=content-transfer-encoding:content-type: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:content-type; bh=e4Ryrx73BEQdCje8/y/wl1Qw7FCFzVnkirAvpC6A43E=; b=zbXpO7oBUP7N7+fj31nT7JdNqSPFK8aYsT1Vnden8Iw6O9bvYfdYTeTahIyMmD467O ElYsJ8wxjjrLbBN4sZqYfOxns4rcOtlcBUqXso+MlVfOloQDq6UBWBzd9uFRzGqFzkd3 HpEWRSLXRgyKWOjk6FdIEppOrRzUleMCOcVIYkKTYDwUKC2t7DWoxsBTjNP7HuECrO1k ukTP1fqz9vphezivFTgBPc8lkDaw/d1IzdlSCDHOtj6ZuIjiu1f5OKi26hyAEgR5Bef1 xQrhYHZKfot3701ZiF2exunzesPcH7WGzXdDc7+Io2fmgTJ2eLP1Bp+sHa2AUMs3Gbdt 4k2Q== X-Forwarded-Encrypted: i=1; AKwUvBzcmdSTQjYRhkqH7frrbe+Xs35L3NFcX4K3LmZ29/M5UYVMCHavTEVcmKgKRrrLShCwxfvs2Z+mioE=@lists.xenproject.org X-Gm-Message-State: AFuF++mryqem4ErMcAthrfsbZorgLd+aB5y7ab4mF1vF0BtS5zofkUln DpN3Ht1ZZP1r5FmyLHP444T4TlEZOvHTsHMLYhNRBGS5S71RCAzHNVT1vN00T2OnTA== X-Gm-Gg: AYBFou0UL/6JMukYtd97izAtTSslOjEqNaRWE2tbvWDD9ZsgOAW6TKiXko7GiMl66/z rIs+nZFEScvaVcnjwmiC4pOpXeVudW0s12YjByoO09at7PbmjwqxtixA8+TDB6kLaoOf5k8itZo zEQTghKpNL6ZmgJz3Ykqxxqylk2L3sfErFWB3cmTov2xxs6vqQ0Cv2j9FZ4V0nA7sfLE7Y60Fb2 eaeV88tpuGYV5fxm/B+8vk0qUXqV6vakOw1x1c9H+g6jy34tQOXIHmuynQWmuwzipgorYNIrW/5 qAKJgK3yPNQ0xox686kC7J8iZDP3NrRCv0uRiYnu2TwxIwQTt0evGlPM5JIZJruxIn+kaBC0hIc 1HyhaYL2Gp3f84HfMEm6nmIAQ0FvrtTTBezjn95xXqnyi4uyCRKkC9bvE61mYhx0/E21WZ0rtlr VrpglBxvYKCn6ymuCPIyFyr7/SklS4dWYmABY2N3opGOqeVAdB0PcVY/vfOitGlfrwIFYcuFk8w wyg7f8H09cFE7Z6s67dfASBc60r0b/BDM28xaGNt+PNFRayNg7sRxjt9Pkheg== X-Received: by 2002:a05:600c:6308:b0:49c:fa20:cbfd with SMTP id 5b1f17b1804b1-49fc5728e35mr190371955e9.20.1790084057070; Tue, 22 Sep 2026 06:34:17 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 15:34:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86emul: Cache the amd_like() output on x86_emulate() entry To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260921092545.37148-1-alejandro.garciavallejo@amd.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: <20260921092545.37148-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1790084057-508CDCFC-8D6F4817/0/0 X-purgate-type: clean X-purgate-size: 1950 On 21.09.2026 11:25, Alejandro Vallejo wrote: > The current code instantiates amd_like() way too many times, leading to > codegen explosion. Unconditionally call it early on, and use that > variable everywhere. This shrinks the emulator by ~3KiB. > > No a functional change. > > Signed-off-by: Alejandro Vallejo > --- > pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2860748404 > (it's red because of an caching issue and personal branch name > conventions it's just arm. x86 passes in full) > > bloat-o-meter before-after patch. > > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-3366 (-3366) > Function old new delta > x86_emulate 209351 205985 -3366 > Total: Before=3617694, After=3614328, chg -0.09% That's surprisingly big a difference, considering how simple amd_like() is. I'm counting 24 instances, so the savings would be well over 100 bytes per instance. That said - there are more uses, and I wonder why you ... > @@ -1310,6 +1310,7 @@ x86_emulate( > /* Shadow copy of register state. Committed on successful emulation. */ > struct cpu_user_regs _regs = *ctxt->regs; > const struct cpu_policy *__maybe_unused cp = ctxt->cpu_policy; > + bool is_amd_like = amd_like(ctxt); > struct x86_emulate_state state; ... make a standalone local variable here when you could introduce a new field in struct x86_emulate_state, which would then filled early in x86emul_decode(), and which could then be used elsewhere as well. With that amd_like() could then likely also move from private.h to decode.c; better yet - perhaps the function then wouldn't be needed at all anymore. Another way to reduce the overhead at least some would be to make more use of _amd_like(), now that x86_emulate() has a "cp" local variable. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:37:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:37:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428857.1651773 (Exim 4.92) (envelope-from ) id 1x90go-0002Xu-Mq; Tue, 22 Sep 2026 13:37:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428857.1651773; Tue, 22 Sep 2026 13:37: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 1x90go-0002Xn-Jr; Tue, 22 Sep 2026 13:37:42 +0000 Received: by outflank-mailman (input) for mailman id 1428857; Tue, 22 Sep 2026 13:37:41 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90gn-0002Xd-7m for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:37:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x90gm-00B6Mr-1m; Tue, 22 Sep 2026 13:37:40 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x90gn-00FBgx-01; Tue, 22 Sep 2026 13:37:40 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=bBfMPPDgDvbZEKlPYABncFvyU5Uu7LoimSa/PokQfPo=; b=KtPJ0e+KF1ciHuB234M/KO484f TD1ZFtKqEtsPPaUislqqW04ZIwPW6NAo49aNDLvUECHT47gTMrUmZWjlzx947s+fozjr1HgTjYmuP cNIJWpVpj/X5FCIYDbFlkhadog7rn/3Q5kTCdryGoPjFL9nLeCRA4T+2JCpUlY7EWIhY=; Date: Tue, 22 Sep 2026 15:37:32 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 1/6] x86/pass-through: defer event unlock in pt_irq_create_bind() Message-ID: References: <7618c144-2f4a-483c-b078-0d9100b9f251@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7618c144-2f4a-483c-b078-0d9100b9f251@suse.com> On Tue, Sep 08, 2026 at 03:01:27PM +0200, Jan Beulich wrote: > The radix tree holding struct pirq * as obtained by pirq_get_info() is > protected by the domain's event lock. The result ("info") and the derived > "pirq_dpci" therefore may not be de-referenced past the dropping of that > lock. Moving the unlock down is safe, but perhaps not obviously so: > - vector_hashing_dest() does a memory allocation, but core event channel > code does so too while holding the lock; the call to > vlapic_match_dest() doesn't involve any further locking, > - hvm_migrate_pirq() operates on the corresponding IRQ descriptor, where > obtaining of its lock is of course fine (those locks always nest inside > the event lock), > - {hvm,vmx}_pi_update_irte() are very similar to hvm_migrate_pirq() > locking-wise, > - the locking around guest_mask_msi_irq() is the same as in the earlier > two bullet points. > > As long as the PCI-devs lock is held around both > pt_irq_{create,destroy}_bind(), this is only a latent issue. > > Fixes: 35a1caf8b6b5 ("pass-through: update IRTE according to guest interrupt config changes") > Fixes: 1066331913c9 ("passthrough: don't migrate pirq when it is delivered through VT-d PI") > Fixes: 782cf8ba4678 ("pass-through: adjust pIRQ migration") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > The last two unlocks could be done a little more efficiently, but then > also in a little less straightforward a way: > > if ( pt_irq_bind->u.msi.gflags & XEN_DOMCTL_VMSI_X86_UNMASKED ) > { > unsigned long flags; > struct irq_desc *desc = pirq_spin_lock_irq_desc(info, &flags); > > write_unlock(&d->event_lock); > > if ( !desc ) > { > pt_irq_destroy_bind(d, pt_irq_bind); > return -EINVAL; > } > > guest_mask_msi_irq(desc, false); > spin_unlock_irqrestore(&desc->lock, flags); > } > else > write_unlock(&d->event_lock); > > break; I think your proposed approach is easier to follow, I'm happy with it. > > Seeing that the IRQ descriptor lock is taken up to three times in a row, > I wonder whether we shouldn't consolidate this (by obtaining desc once and > then passing it into hvm_migrate_pirq() (or a suitable new sibling > thereof) and hvm_pi_update_irte()). Possibly? I haven't looked what would be the adjustment needed on other callers. Just passing the locked irq_desc? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:37:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:37:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428859.1651783 (Exim 4.92) (envelope-from ) id 1x90gx-0002rB-UK; Tue, 22 Sep 2026 13:37:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428859.1651783; Tue, 22 Sep 2026 13:37:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90gx-0002r4-Qe; Tue, 22 Sep 2026 13:37:51 +0000 Received: by outflank-mailman (input) for mailman id 1428859; Tue, 22 Sep 2026 13:37:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x90gv-0002nT-W1 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:37:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x90gu-00Gf6s-UR for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:37:48 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28493-8faa-0a2a0a5109dd-0a2a4505eb0e-38 for ; Tue, 22 Sep 2026 15:37:48 +0200 Received: from [74.125.229.204] (helo=mail-lf2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab284ac-4cb1-0a2a45050019-4a7de5ccbc23-3 for ; Tue, 22 Sep 2026 15:37:48 +0200 Received: by mail-lf2-f12.google.com with SMTP id 2adb3069b0e04-5b5e4f13d7aso5803714e87.1 for ; Tue, 22 Sep 2026 06:37:48 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b8d46ace42sm524032e87.3.2026.09.22.06.37.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 06:37:43 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790084268; x=1790689068; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wZeN+u7NqTmI72DLqEMk7TXQCdL8lLz6a5VXYHbQBBI=; b=i6LXn03870FPVTp4FfUaqLubTL7L0vr4mE7fnLaW0LyhqiEiVTuF23QWe4suCRD1hn vfXjtIw0iYLuDpCpC8ERNJ6D6E3IPV37Sk5G8/JDzDBiDLFuJU61YQGELJLHm239+Wvh hn8Xvl8esyhFOPPV/yi+wYHXcOCQfSAOQfOD4qGmvNmn8KkUAslhA/F5AOfRxn/VRp3y ICnGGhQYmLAeNzKfJ+RgVFPltmOzwWPpJ2KMVKLXgQUc/zxNcHlaTP5H+umw+RGOo3Dc HC6/9fKuZ7CQOFMojTP3GAQgLFRFKL+uWqFIn8z4IixOFqL0G/JYEMtiTTR8Eg3GlnGL JKlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790084268; x=1790689068; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=wZeN+u7NqTmI72DLqEMk7TXQCdL8lLz6a5VXYHbQBBI=; b=JLUfaOc+RnDPTiRVO3xFD9SR1mU7Cd0gLM59zOmdY/j8yD6MG1adhlwfIDQTmhK0gv rsTrZ+wxMY3KxUTGSGN8sDGpwhxkYGl6QiaSRT74fxeAoEKqdEr7SeWLie8Rolafms1L TcQtOv8KHgl/d2Z8KRY3Ar+eZH5ztYDKUVZ7WuLG/n3htOJOESlzN29O7T4kju3Z2Dwj hNDdIA1TOXage5yzh5nHK7/nWblDxprarQYE9M4tGHBn8vQnEQPJCF2aRZ/pOe2pd3M+ CaIo7dh25z8Tr60s8BSDagbKlzjWT+EVD2oRr7l96uvt7bFFBT2sljBKYEYy6dFaWwQu 50Ww== X-Forwarded-Encrypted: i=1; AKwUvByAJ8s5Fmi02zbN2wgOGmQ2KV/k4rYua7tq3uIBJ5IeY1y7AoBHyCKOKSMxFMvVxPYLQvqb/R62Qfc=@lists.xenproject.org X-Gm-Message-State: AFuF++lm27MRBlOFt7x5sbYPueRF6Tmej4PQExyF8Mk2p9qBzdh0Q6Gi OfeM8+udsfMblsirKu+DuiVOPSKtDqcnuE1QVsiXfvi+eZKN4TBzJh1L X-Gm-Gg: AYBFou0rnDcg4L7QZWE9RMYXsPHQeLLSO2rOcBaJjSiiKWRbkyFccKd/8fKHRBYva3S RXP2jFHOi9kbDy0Obt+vb74omUXfOqIVOP0q9ov+nqEqz/1f80gnSgLLtfuEfI89l0sOYcnOnxT JZR1gGgiGHwhbvLVcnPG4dJ/bzIzsOO4tdbtbc7plkSNEkqxBYomAXxQnWKvvyN1bG64Y8sHMrq TZCmGHstKHlrCJBdlWet+DFtNilQ0Da7ET6ZktOTfuQUW/uUHZtQp6GRP7jae0TPXUp7eXgN0cY KRwYN2ATp8P5+sOp9HsWGAeTBSXswDbngJsatZtGCIjVsAy5iVLDExmlOHGKFErQ57tYSRBgZbC 4GHDJD9R0ESr1+euinCADF/Z0HjQdfPpFT/Ch9k25Z30A3bx6PT4sOES4Qwwqcn6dzQn61cW1v2 1B0H1ZQj87bjN5CR8PM0y3Mq5b+gYqYXRDHgI5gx5brRtXN1dJQXtbC/og8g2iyDXipgvaIwu4q 1ll6eeVY0ydCZ6dcJdRbL4x5fLPp1o7EQB6QjLXguzs0fKeOw== X-Received: by 2002:a05:6512:1049:b0:5b5:e8d5:7fff with SMTP id 2adb3069b0e04-5b8c17f5dafmr4645582e87.8.1790084263478; Tue, 22 Sep 2026 06:37:43 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 15:37:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9260a8cb-66f0-4eba-b630-666039bf2e72@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790084268-253192A1-A390FC16/10/73395122804 X-purgate-type: spam X-purgate-size: 5684 On 9/21/26 5:08 PM, Jan Beulich wrote: > On 21.09.2026 16:01, Oleksii Kurochko wrote: >> On 9/18/26 2:52 PM, Jan Beulich wrote: >>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>> --- a/xen/arch/riscv/imsic.c >>>> +++ b/xen/arch/riscv/imsic.c >>>> @@ -510,12 +510,31 @@ void cf_check imsic_ctxt_switch_from(struct vcpu *v) >>>> >>>> write_lock_irqsave(&imsic_state->vsfile_lock, flags); >>>> imsic_state->vsfile_cpu = v->processor; >>>> + /* >>>> + * Start to observe the VS-file from HS-mode: while the vCPU isn't >>>> + * running an interrupt pending in its VS-file is reported through HGEIP >>>> + * instead of being delivered to VS-mode, which lets Xen wake the vCPU up. >>>> + */ >>>> + csr_set(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); >>>> write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >>>> } >>> >>> It is suspicious for the HGEIE write to be the last step. How's this free >>> of a window where an interrupt is lost. (Sorry, likely another blind spot >>> of mine wrt RISC-V.) >> >> There's no window: a guest interrupt file's hgeip bit is >> level-sensitive, i.e. it reflects whether the file currently has a >> pending-and-enabled interrupt (the MSI itself stays latched in the >> file's eip[] until the guest claims it), and hip.SGEIP is simply (hgeip >> & hgeie) != 0. So an MSI arriving after the vCPU stopped running but >> before hgeie is set raises an SGEI as soon as the bit is set, taken once >> interrupts are re-enabled. I'll extend the comment to say so: >> >> /* >> * Start to observe the VS-file from HS-mode: while the vCPU isn't >> * running an interrupt pending in its VS-file is reported through >> HGEIP >> * instead of being delivered to VS-mode, which lets Xen wake the >> vCPU up. >> * >> * HGEIP is level-sensitive, reflecting the VS-file's current state, so >> * an interrupt that became pending before this point raises an SGEI as >> * soon as the bit is set in HGEIE; nothing is lost in between. >> */ >> >> Does it make sense? > > I think I get what you're trying to explain, but the term "level-sensitive" > here doesn't really help. I'm unconvinced you actually mean that, as it > requires pins / physical signals, which don't exist with MSI. It feels like > you may mean "sticky" instead. Fair point regarding the terminology: 'level-sensitive' usually implies physical signal lines, whereas here MSIs are memory writes latched in the file's eip[] array. I meant that HGEIP dynamically reflects whether the VS-file currently has any pending-and-enabled interrupt latched. I'll update the comment to clarify this without using 'level-sensitive': /* * Start to observe the VS-file from HS-mode: while the vCPU isn't * running an interrupt pending in its VS-file is reported through HGEIP * instead of being delivered to VS-mode, which lets Xen wake the vCPU up. * * An MSI is recorded in the VS-file's eip[] array until the guest claims * it, and HGEIP isn't latched but reflects whether the file currently * has a pending-and-enabled interrupt. Hence an interrupt which arrived * before this point raises an SGEI as soon as the bit is set in HGEIE; * nothing is lost in between. */ > >>>> void cf_check imsic_ctxt_switch_to(struct vcpu *v) >>>> { >>>> - /* Nothing to do */ >>>> + struct vimsic_state *imsic_state = v->arch.vimsic_state; >>>> + unsigned long flags; >>>> + >>>> + /* A s/w VS-file is never observed through HGEIP. */ >>>> + if ( !vcpu_guest_file_id(v) ) >>>> + return; >>>> + >>>> + /* >>>> + * The vCPU is about to run, so hstatus.VGEIN delivers the VS-file's >>>> + * interrupts to it directly and there is nothing left for Xen to observe. >>>> + */ >>>> + read_lock_irqsave(&imsic_state->vsfile_lock, flags); >>>> + csr_clear(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); >>>> + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >>>> } >>> >>> How can this be a read-lock when you write a CSR? >> >> But here is a protection of ->guest_file_id not of write to a CSR and we >> want to not have a change of ->guest_file_id during an update of CSR_HGEIE. >> >>> Or else - why is locking >>> here necessary in the firt place? >> >> Strictly speaking no locking is needed with the current implementation: >> HGEIE is local to this pCPU, and guest_file_id can't change >> concurrently. It's updated either by this very pCPU ahead of switching >> the vCPU in (imsic_migrate_vcpu() called from schedule(), >> imsic_vsfile_attach() right after), or while the vCPU can't be >> scheduled: sched_unit_migrate_finish() defers to unit_context_saved() >> while the unit is running, and sched_move_domain() pauses the domain. >> >> (and the similar are true for imsic_ctxt_switch_from()) >> >> But IMO we should keep around ->vsfile_lock to not miss the case where >> some case will update ->guest_file_id in parallel with >> imsic_ctxt_switch_to(). >> >> Does it make to continue to have read_lock_irqsave(...->vsfile_lock, >> ...) here just for potential future cases? > > You get to judge. If the lock typically is uncontended, keeping things > as-is may indeed be fine. Introducing a bottleneck "just for potential > future cases" otoh wouldn't look overly nice to me. > For the moment, I prefer to have a lock here as it is expected to be cheap. If one day it won't be true anymore it will be easier to spot all the places and remove it where it will be necessary. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:41:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:41:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428877.1651791 (Exim 4.92) (envelope-from ) id 1x90kq-00050J-DO; Tue, 22 Sep 2026 13:41:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428877.1651791; Tue, 22 Sep 2026 13:41:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90kq-00050C-AI; Tue, 22 Sep 2026 13:41:52 +0000 Received: by outflank-mailman (input) for mailman id 1428877; Tue, 22 Sep 2026 13:41:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x90kp-000503-Aq for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:41:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x90ko-00Gfzd-Ng for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:41:50 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28589-e002-0a2a0a5209dd-0a2a4503e652-40 for ; Tue, 22 Sep 2026 15:41:50 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2859e-fae8-0a2a45030019-4a7de14ca851-3 for ; Tue, 22 Sep 2026 15:41:50 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843378fb37so2064752f8f.3 for ; Tue, 22 Sep 2026 06:41:50 -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 ffacd0b85a97d-4886277e841sm5874558f8f.19.2026.09.22.06.41.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 06:41:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:Autocrypt:Subject:From:Cc:To:Content-Language:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790084510; x=1790689310; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=fEJWe61S7N2olbvg8Gvy8LD38E1k64cZuqUmQQSpCiU=; b=HEftOQBteHTOgOeF1WILoKaWmLoMM61TaFzb9h/CSStCB+tAZ6jlU0+cqdv8eNYQ0L cd0umuLhHyarnOSFS7Rnb8b2rDjr3gbIZiqhHnC0JRAwMZlbE0ttc+FUyEofNv4TSxOx 3iBfGTtYQ4SuUl3/t+zhLHJPkpSP2ISxUQtQULZBwT7BI9xG8GXfQkPoKl5SzvawHYGy NzgyNMSTcOeFIhBiHSGM2FkMYn7WKgbIx/spSu2tLMzn/0bU+73CxATXddrnYkViRc5Y zfiGIqQnZ5ql7OD4W/L1bLia6/myHYPx2ZvgpIYrgaxuz1XE5e/W+SIzQa0u2y9Ijwtu YmCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790084510; x=1790689310; h=content-transfer-encoding:content-type:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=fEJWe61S7N2olbvg8Gvy8LD38E1k64cZuqUmQQSpCiU=; b=Rhm5/ETEzk9Xe4hByAVLun54DHkHFJH+iN20k5ApPx34MTNokhCcSbLN0vylS76Cdm q6SIvg75OGjXhcSRDwlQhPAZKxTLv9Yt6QdnQeIT0i4Uccsew853psCza3cgp0Fx+QJQ 1vrggE96gZJ3wZTXjqq9oRmqh8qh2RPmuh8db3ZKoq7ZxWtqKyUxNPoqvcb7zM5cmIsx QqQSwVjq3+HgL5a7B4uulgSaDjvZOAi2NkqaYpOx0bN4aFiRC/1VSAs1R++IEAU4QCna zr0F3+eRBeLYcstPNVKt27gxOH3VO4iJqNPuu7bBgGJj8PssUPh0XmIxB1+oaAQbFmcd 4eng== X-Gm-Message-State: AFuF++nrORfwWN85BmTLlXnH7An0PbV1cP5a4tCb9UY98F/cHVFJZ129 1julonmZq0a+BO7fp96TFAo7I4aM+/J780UOaym4bl7ZYrd0x0vmEchPHm35HNHbIbm4nHbyyS1 ZXhV7Gg== X-Gm-Gg: AYBFou07+hO2Jv801snV4PGGoAkJSTSkedUtYRXtszIA6qya9ku/YFu6ONede2qdG+J ZCG3L7HgsKcRuR3bqgTRTMWbrlh2FOux7BT05sPWGIk6GGvvgTCefSVUjy/yUAQ9uIBTXeB8Sr3 mMUu0b/Qayv9dccnnP1ZoZZgg9vex7lC/jwM6lj4h+xUUlWTnJl28NRe+XPobrcBt1sNAwD6dqr v3Op66aKHAVGeCmNcKlAEgQQ+/dOqO8GeC/qNj1N5umePyVQNk1RQugPGpHIEAhgMFsURt9+Noj DhoYu+uQb6xlQCY7GtOmj5xT7gjzwVXVLXSvGsxqegf4RobHB5ypVOqTOTRHVL7X+h4Sy9SsW7B HaJbLulGpIUh2hoESzIRJpnzB7itBkwNysG8yAwgnVY4jZ/A0ZeUXaxRn791JhwkN0WwIUJ6zpw LCrP4j+XHCYr8zkOBB11iPkqXQlqJmiCrLB5t2JwNhroioDsOXC1bLrB4CB4Td5IPOshW0M4FFZ A14PiwcTXy2IOmvR/pwA/5GBR8nAtkhS+y2SK+Gr9fk7qF5yNxYln7YzQas/6MoWzhr7b50+Q== X-Received: by 2002:a05:6000:3103:b0:486:f908:14c with SMTP id ffacd0b85a97d-4871e3778cbmr17997834f8f.47.1790084510049; Tue, 22 Sep 2026 06:41:50 -0700 (PDT) Message-ID: <7a9080a2-6411-40f0-be7e-f08909c19501@suse.com> Date: Tue, 22 Sep 2026 15:41:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Nicola Vetrini From: Jan Beulich Subject: [PATCH] automation/Eclair: tag directive 4.3 as well as rules 17.2 and 21.17 as clean 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1790084510-6EACC4E9-8D0B89F4/0/0 X-purgate-type: clean X-purgate-size: 1009 These have been clean for a while already, without being marked so. Signed-off-by: Jan Beulich --- https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2871068276 As per https://lists.xen.org/archives/html/xen-devel/2026-09/msg00486.html rule 18.1 is also clean already. It is being marked so there; that line could of course also be moved here if so desired (albeit personally I'd prefer the 18-series markings to stay together). --- a/automation/eclair_analysis/ECLAIR/tagging.ecl +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl @@ -23,6 +23,7 @@ "MC3A2.D1.1|| MC3A2.D2.1|| MC3A2.D4.1|| +MC3A2.D4.3|| MC3A2.D4.7|| MC3A2.D4.10|| MC3A2.D4.11|| @@ -77,6 +78,7 @@ MC3A2.R16.3|| MC3A2.R16.6|| MC3A2.R16.7|| MC3A2.R17.1|| +MC3A2.R17.2|| MC3A2.R17.3|| MC3A2.R17.4|| MC3A2.R17.5|| @@ -105,6 +107,7 @@ MC3A2.R21.10|| MC3A2.R21.11|| MC3A2.R21.12|| MC3A2.R21.13|| +MC3A2.R21.17|| MC3A2.R21.18|| MC3A2.R21.19|| MC3A2.R21.20|| From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:58:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:58:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428890.1651801 (Exim 4.92) (envelope-from ) id 1x910y-0000vz-Qp; Tue, 22 Sep 2026 13:58:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428890.1651801; Tue, 22 Sep 2026 13:58:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x910y-0000vs-Ny; Tue, 22 Sep 2026 13:58:32 +0000 Received: by outflank-mailman (input) for mailman id 1428890; Tue, 22 Sep 2026 13:58:32 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x910x-0000vi-Vr for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:58:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x910w-00AZCX-WE for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:58:31 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28979-bab6-0a2a0a5309dd-0a2a4508af1c-28 for ; Tue, 22 Sep 2026 15:58:30 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28986-f659-0a2a45080019-4a7de18cf71d-3 for ; Tue, 22 Sep 2026 15:58:30 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912df756so29140045e9.3 for ; Tue, 22 Sep 2026 06:58:30 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fd8b97385sm84318545e9.2.2026.09.22.06.58.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 06:58:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790085510; x=1790690310; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=PR9XOsE+XnvE6AH4I0DYy0W5jkKN9kElBVLGNxt+jAg=; b=O3FjBWR/poNNOoczkreQmfbqgqPVCVizqoY7mZb7Stg3J7p2J5Yd5KWuQuBH+D+kMs 3B+z24ZLPhjQeIsH2MSyKqAdxFrgXCeGtDb01pKpV6ANwBKlyHU2/JVIFoe8I+yvtEPA b509cAiICRU+L0MSxTouaasWp1polXz1M+I6ypgVsWyWVcoLU8yFymzcVSMpJtpIEm8H wDOddKFzHjouyYtqMU1bFaeyOY5ZQu5p5fyUqtxg3AQFWBEN9SXlHYcBZPCpxsAp7EsK iVHdoR1C3MhKCXxui+yqk3h7F7Anoz1wa2YozJNFDJ5bG3FZL9QN5JHlDujgxpvoBgwo KbiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790085510; x=1790690310; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=PR9XOsE+XnvE6AH4I0DYy0W5jkKN9kElBVLGNxt+jAg=; b=fBFXzAidDbJeg7EFtWfqGeirKEIJgcUZQLoTkmMPfexX1wOgnX2nSO5RpBsn/9w/5E w76sYwK1DcprQxEFmuH/DYMqriZ3MX7JZRz+7zDyusE1JldMbIf2LqQsCGkA/VKpO95Y Fm3GCzQczhQhN0kQBUNNlccvWLUKLiYBbx90X4nJthRmf/YjE9o+ryVcjnNjH5lrSOVS GBp3xafoR8AL1rK5uz278bsR/GT/wPdlhu7DAOLOY8fzeNFDsL62Tigmhu4W7Evut2kN aPVyZo40XJJJtbg2VElVF/LxdBPIAZjQaqSH4647Z/1IOnTT7SZ7neVlp7vXFSiwuuaN 5IsQ== X-Forwarded-Encrypted: i=1; AKwUvBylJysLO2d68ALgjGJV3D/r2Bup6/tnDqqiipSj3eD2UcvBrFecLP5L2VmpCk5XqWSt1oLVCMKrkpE=@lists.xenproject.org X-Gm-Message-State: AFuF++mmu5dWxN6YtU6aC1NeBAPhHX7LLJr/A2qkzmnEz8HSDnK69jhZ 3Kysi54K4UQco5J21KK4pEH+GqD7GOt+tKOlhfo2fJGUh6x2xKZvucRk X-Gm-Gg: AYBFou036iz4jrkofNaUQx9AzWDoSOt+iOcm7zOtNYxB2aM6OAKI2Lq/Mc+zuImnpJQ TPkoF9ninvaUsE5NwxvEaqdN7RA3Q4k8J5aeL9gLRqdQUyKY7+LO2dM1eOarOQmIg7mGVDU0YwX nVVvsoS9RFMPciei2J8WSByJ+pfb/CYwQyep0Ww39uoeysjgHeLADRmHT4/w84LUV1hwECvB95x bnNjkJRZsIupG88GtzSOUQqrhIC7r3ZOpGD60ELHXoRVeVTk0oF2A8JEPzXHpB+FfqyoVWzjXO/ b46BZPrhihc2tmY7fr+LlycXlgo+55sIcy0OHUcE/l1+c3wLgaaixyw4/sq4KsVCovwcibTgohz 5taVW1fyYJA97RA9OsMk2EE/dwWmqOF57pKu83MuSdvCFJYffCdaAzNZw7xmmkWC6g9+t4h0c0h DceiBOueTjvSwFojLinY2tjJqRze6bWz1xzBVVzrLM0EmM6RVaqkir3M/b3/swNsiLa+8Qkg0fV MNeugB7NNVO+GJRKsdg+cVTYVcloclRI7hdiDGdWpyJkt7S3g== X-Received: by 2002:a05:600c:1c1a:b0:49d:1de5:ce0a with SMTP id 5b1f17b1804b1-49fc56d4238mr246209275e9.13.1790085510219; Tue, 22 Sep 2026 06:58:30 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 15:58:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu() To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <8dbc4ba6-bf92-4e9f-b4b6-7286d5a96443@suse.com> <96f66feb-8889-4475-b39f-ed52b1f58a68@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1790085510-D5F4787B-C2AB749A/10/73395122804 X-purgate-type: spam X-purgate-size: 3934 On 9/22/26 12:20 PM, Jan Beulich wrote: > On 22.09.2026 10:23, Oleksii Kurochko wrote: >> On 9/21/26 2:12 PM, Jan Beulich wrote: >>> On 27.08.2026 17:21, Oleksii Kurochko wrote: >>>> continue_new_vcpu() is the arch hook invoked the first time a freshly >>>> created vCPU is scheduled. Implement both cases it has to cover: >>>> - for the idle vCPU, switch to its own stack and jump to idle_loop(); >>>> - for a guest vCPU, restore hstatus and enter the guest through the new >>>> return_to_new_vcpu() path in entry.S, which loads sepc, passes the >>>> hart id in a0 and the DTB address in a1 as expected by the RISC-V >>>> boot protocol, sets sstatus.SPP and executes sret. >>> >>> Is this a requirement for all CPUs, or just for the boot one? (I can't >>> quite see why secondary processors would need passing a DTB address.) >> >> It is requirement for boot one. For secondary processors it is HSM boot >> data which is passed to sbi_hsm_hart_start() and then intercpeted by Xen. >> >> At the moment of writing of this commit message we have only boot CPU >> and so only DTB could be passed. > > That you're talking about Xen. Despite Xen being UP only right now, guests > still can have more than one vCPU, can't they? They can. > >> I can update the commit message and the comment in return_to_new_vcpu() >> to tell that it could be DTB address for boot cpu and/or for secondary >> CPUs HSM boot data or it will be better to add info about HSM boot data >> during and an introduction of secondary CPUs support? > > As per above you want to deal with multi-vCPU guests right now. Then I will update the commit message and the comment in return_to_new_vcpu() to say that a1 holds the DTB address for the boot vCPU, and for secondary vCPUs the opaque value the guest passed to SBI HSM hart_start(). For commit message: - for a guest vCPU, restore hstatus and enter the guest through the new return_to_new_vcpu() path in entry.S, which loads sepc, passes the hart id in a0 and, in a1, either the DTB address (boot vCPU) or the opaque argument of SBI HSM hart_start() (secondary vCPUs), as required by the RISC-V boot protocol and the SBI specification, sets sstatus.SPP and executes sret. In the code: /* * .a1 holds the DTB address for the boot vCPU, or the opaque value * passed to SBI HSM hart_start() for secondary vCPUs */ >>>> + /* Set guest mode to supervisor */ >>>> + li t0, SSTATUS_SPP >>>> + csrs CSR_SSTATUS, t0 >>>> + >>>> + /* Enter guest */ >>>> + sret >>>> +END(return_to_new_vcpu) >>> >>> Aiui SRET does not switch stacks. Shouldn't you therefore clear sp here? >>> And perhaps also other GPRs, not the least ra? Exposing hypervisor >>> register values to guests is, well, a bit of a problem. >> >> Good point, sret leaves all GPRs as they are, so the guest would indeed >> see Xen's sp, ra and friends. Only a0 and a1 are architecturally >> meaningful for a booting hart, so I'll clear every other GPR right >> before sret. >> >> I will add the following before sret: >> >> /* >> * sret doesn't switch stacks and leaves the GPRs alone, so every >> * register which isn't meaningful to the vCPU being started >> has to be >> * cleared here: otherwise the guest would see Xen's values, sp >> (this >> * vCPU's Xen stack) and ra among them. >> */ >> .irp reg, ra, sp, gp, tp, t0, t1, t2, s0, s1, a2, a3, a4, a5, >> a6, a7, \ >> s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, t3, t4, t5, t6 >> mv \reg, zero >> .endr > > At which point discussing the clobbering of t0 in the comment ahead of > the function also isn't needed anymore. Indeed, I'll drop it. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 13:59:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 13:59:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428895.1651810 (Exim 4.92) (envelope-from ) id 1x9127-0001Z3-3K; Tue, 22 Sep 2026 13:59:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428895.1651810; Tue, 22 Sep 2026 13:59:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9127-0001Yw-0d; Tue, 22 Sep 2026 13:59:43 +0000 Received: by outflank-mailman (input) for mailman id 1428895; Tue, 22 Sep 2026 13:59:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9125-0001Yk-V9 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 13:59:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9125-00HYlr-80 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:59:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab289ca-bab6-0a2a0a5309dd-0a2a450b8fe6-22 for ; Tue, 22 Sep 2026 15:59:41 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab289cd-b7e8-0a2a450b0019-4a7de14ce2ae-3 for ; Tue, 22 Sep 2026 15:59:41 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6350f89so2507993f8f.3 for ; Tue, 22 Sep 2026 06:59:41 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48862774882sm5506267f8f.13.2026.09.22.06.59.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 06:59:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790085581; x=1790690381; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=CaOfa4yq+8f+PXaRAVsgS+seiDe9BQ6P4dSHmnDrlbQ=; b=lp9YUGuj6OGE4wZXnk1VwE+i1clhqkgd8LPjN5swSwNnStfIp/2Aaz2jENTAcIoOIz YdxnFKdoYeU1wvWmNq5QwJE5Xs7QOuzLpJ7tGiN6UGB2ZpE7uRLV1kv18U9U4mLsIZE5 6S5BGxZdYC1/giDAzNhSWTe0UnQbc8k1mhTschDndJMFIOJJ4cGY8mye08/DfHjEqKpk miDXnI34F+SEjleFEYjvtof9UTHxWX8PyKrh94kLefxhe/KQk9M58Hukysmwfa5yASkq Zz9r+tgS21L3o5QD5gZkKqokft5wwy+4XX0zN+gNwZBOoqg3of2R8yda1dWFTWeU2t0P 76JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790085581; x=1790690381; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=CaOfa4yq+8f+PXaRAVsgS+seiDe9BQ6P4dSHmnDrlbQ=; b=uOL/XAcWOMJKt+zZY9h4N4elu77QM3UfrkQNWmxof8bD11hFxguR2oOPd3Szt9VnTe 68Gp7wb97e5/KvO5wlmzhN9d173oybsnHT8ySRIvFPLmdInD0AJnKjsSyV37jp8D0y2H +9LVjYE/ByTkFdkL2Hd+F7aqBkJNiMGKl536ox0yPmDeOokQxkMgfTV8QPAleehpPUvq 5juOOZ+xKl+cY7NfXgufGTHoCpBKDuc4U1dMx3KDJ7FW2kATKEO/qrZf0eZ+7qsUliUX QLgFYP4K/DTqOmicc3G3yfw8a+topWlvyW3+DG2HSLGuDI1JRuKV6HTRaocXiRtC6Ybq m2lA== X-Forwarded-Encrypted: i=1; AKwUvBxx95rLgyciUqw+co60g4AxyFfEtM5+b9OWunBNAIFqN+Hiv2MVPfe0ssX0uB86GtiIr0Eg9CEX7Uc=@lists.xenproject.org X-Gm-Message-State: AFuF++msmfTj8qqVhQPiLg1NTTRbcAIultBJTtC48ZW2CpS7Fe3QpTqT 4wbO/jRguCjCDtRtMBGn1B7qFGrpxSsfgioD48bIPEWMlxLoY8zCgNnW X-Gm-Gg: AYBFou1Vq57OxNrVqIcxAUTOzmJOI19mFT6u22SfxkpWMc1qO4kBDP+SeNU9yJRtSWm djS1atB7bHtbQIX0s0cvnkD7ST6c/QvxJv8SUhQtm8qij8oD/H0LpLAvYtoCT+RBZiDVUm26H6x es9kFagn53vxuctppkUwuiWKtPkklbPcbPygbaWCq/c6ReKIK+mEjvKBhjnrHs9/4cM26i8wBZe KhSMeFddrx1/Moji2I3dbZylEOsgwht8dflXxe92shTtsXulll1+DpvhRrDh1O9E5GiqstTe93t H3yE6CIWsLTtz+QWtPky/mB0knaHQyZtMpAkvV65T7GITW1I7WdmxmJLmjMSi5Sd6oorpXEdnPp ZtN21xVpDT8wu9Y2VqonvmR7gmUslrZhHG7QEn7ATDA/zgWUg3uH6RIxk9Uu3rOTp0cP7GPSLmC fLAElPdru96JEVYfXRbTybDrABLxR1A/SUGNmFYnyWquNxLgRkZs8zhJ1bV5SV9xgbL91/Lbq4j /7W/23cvHLUqgBV7JKZhk5iPLJATZr1KDXY8W6IpTQeQVPcMJwor2t3gEbv X-Received: by 2002:a05:6000:2608:b0:487:91e:d8ed with SMTP id ffacd0b85a97d-4871e20b210mr20498734f8f.2.1790085580550; Tue, 22 Sep 2026 06:59:40 -0700 (PDT) Message-ID: <038aa8c1-915d-488e-89ac-004b1b8bec70@gmail.com> Date: Tue, 22 Sep 2026 15:59:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/4] CHANGELOG: add removal of grub-pv To: Juergen Gross , xen-devel@lists.xenproject.org Cc: Community Manager References: <20260922072711.385956-1-jgross@suse.com> <20260922072711.385956-5-jgross@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <20260922072711.385956-5-jgross@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-42698a/1790085581-AAAD89EA-B9621E1B/10/73395122804 X-purgate-type: spam X-purgate-size: 940 On 9/22/26 9:27 AM, Juergen Gross wrote: > Signed-off-by: Juergen Gross > --- > CHANGELOG.md | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index aa1a777dd4..a2dd01037b 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -23,6 +23,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > The only known user was the classic-xen fork of Linux. This does not > affect Xen kexec support in the kexec-tools package. > - The example stubdom "c-stubdom" has been removed. > + - The grub-pv stubdom has been removed. A grub-pv stubdom from an older > + Xen version (e.g. 4.22) will still work with Xen 4.23. > > ## [4.22.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=staging) - 2026-07-30 > Acked-by: Oleksii Kurochko Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:02:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:02:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428905.1651818 (Exim 4.92) (envelope-from ) id 1x914b-0003aE-HE; Tue, 22 Sep 2026 14:02:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428905.1651818; Tue, 22 Sep 2026 14:02:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x914b-0003a7-EX; Tue, 22 Sep 2026 14:02:17 +0000 Received: by outflank-mailman (input) for mailman id 1428905; Tue, 22 Sep 2026 14:02:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x914Z-0003Zx-Rr for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:02:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x914Z-00ABCH-8R for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:02:15 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28a64-8faa-0a2a0a5109dd-0a2a4507d846-8 for ; Tue, 22 Sep 2026 16:02:15 +0200 Received: from [40.107.162.133] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28a66-b4ea-0a2a45070019-286ba285bc03-3 for ; Tue, 22 Sep 2026 16:02:15 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by GV2PR03MB9355.eurprd03.prod.outlook.com (2603:10a6:150:d6::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 14:02:13 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:02:12 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=czPMoJtnuk4ko5uXMvwBG5ZvHEiab8N1cEOKaqGMiwDiAoUJNM8+F4i0Ea+yzE+jTfvcmarSQTRbV09pWIA3fLqp6kok65FJHx54JV9C/PmzGzL/0Q3cb3k/E2OS0AL+XRkulN8G8B6IA4eHqva9yIIGC29LVwYcTdeFfQsIjY1nr8H0ac+FFUfhO1c8nPkUw0MC6GFiXctRQWQCkr7mOcm4QGxkH5m6epVa0aKiXbyKS0l1a+S32Dtd+wd/hkt3ZzeDUP99w95gO79SiA2XajxLHByK9io8ZDFh22KCdPdSeOoEgJQ1wJe3XT8FPnAg4ANFCYIh6p82pDcx6sEFdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rbLdUjeDZ7fj3h/kdE7ekuRdj4H7UCSvClOU6Cd5lAg=; b=iWtlRdjTG2K5GBZACDVBElDmMVvaVUKhMVGdzqrr6Lg1Xf5/TtH93InE16xqIK5zi7WR4088OHYiiElxIgtpOkGTlGGXJ6EmSHlpY8V430F2lSshnuz5yefaDrvPa9y7bimCaSuvoY4CwwjAXvSh1nzSq088gZ/9nfakktxvdpetlSV9gMg0+Ip6UuyW+NrmAwgRK+tHug5k5ENGC6QSlBkyzrLmwx0qMuX2lWcOvjeGl+Ihr2mOgpmMSAGWacOWF/M5cpuyR368ecDKm22IkpoDOAVCDg7cormDmBEuvYPP014WMNO978w76ZwbG+kAqVAj4w3QzwgxS1JtefowKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rbLdUjeDZ7fj3h/kdE7ekuRdj4H7UCSvClOU6Cd5lAg=; b=jMy4tr9DYQj4oxaGRXNPY7PSzKrldm5tXdS77ZFZDOp3f2V6mvkGKNUE+NUtt63WSS78hYsXJtobdssNce5ITKerMqX5wSv9cYujdinMO9bUzZR0g3hylOkEjf9cwZvH/R+dlhAFcgqUdOaYzmGJx6Xn7QGxuNqR/6ZGHWqxBd4W/9d22BZGTg6RqqTJbLuWdFsgzIXg09Tcd8Cb9CDFLfLby7VHUpZXBJKvWB5X3uWZ6NU7SsiJmlHN7Uvowg5iySn1PvkYILumlojrL02BsKOKDIARaC4Ip7/qYxvz9oCvuKCsqzYoOsf7UjEO73wLv6pvW0fJU9CkeCCab125fw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Tue, 22 Sep 2026 17:02:08 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: Mykola Kvach , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Luca Fancellu , Volodymyr Babchuk Subject: Re: [PATCH v2 2/4] xen/arm: its: separate ITS and host LPI quirk scopes Message-ID: Mail-Followup-To: "Orzel, Michal" , Mykola Kvach , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Luca Fancellu , Volodymyr Babchuk References: <5edcb9ec3e643133d115f009d0d942869ffb6955.1779922874.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: WA0P291CA0015.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::20) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|GV2PR03MB9355:EE_ X-MS-Office365-Filtering-Correlation-Id: 631aeb68-88cb-48ea-bb77-08df18b219d2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|6133799003|22082099003|18002099003|3023799007|11063799006|10067099003|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: 9MV+tSEbtPSy4WuIzk7wi2RW24pKtq6UTSWUjAQevdOZjJdmwOiVS5SHCuUBZ35rfcnLMqHJaav6Q5aRGz2nCQARjFFd2GgXhYDsh05aLM2zoxB6agwEft8+ZZqkG3RS+zKtVts7UXsfYZhRO1bS50J6/HuqqJsmHaR+nfI92ky/8gelFCVt4IsazvcL0iMINpEdbOPBEogGwV15kex06OlgODla64PaGH0fUskYt0bvIZ+57M0c3c9/wwyfvkFlNrPseeJiBzc/+SBaTypNJFq5BW2AyGe3b5SXBDeWokm2rWY6BXFwDkw655IswCwwvcUuDWxc0+enQ1YuGDxTNPh//RfghBek+RwQxmjmOdN+CJSgfxblhSTEtojSF8US4lA/vC9FgFVVCk/KyS7iaBUliREj+mpKDvv2AZPkbMrD5ZPrpoBlXVG4kvVAQm20imQ9GJDVofa9Sw8+IGAHGrDA4PdC3aLiKnTsTIqqs2SiRv5/SDSMudrVxHqjn92Eff92jhYBg0NdLWedNxErrvUY3NZXaB6qxMNZaa17UMsEw8a1H4l1Nhx64+Y5LQd6NWOTl59DJ9Ag0lkIXeTxzvmqc7zyFtuW7oiuH5MMmlp/CHH6ubqGhyzGT9EDLBowGbSKgPQb4ApON/gtn7g0Kb9MS/Z2Sr2LNx0F3P7Hxlc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(6133799003)(22082099003)(18002099003)(3023799007)(11063799006)(10067099003)(4143699003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YmZiNjIwb3lhY1hJekNtOE9OTkZBMU1SWG1MV08zYXBWSDVRaXhNdGRyU3l1?= =?utf-8?B?cUVjeWd3emFBYjRpclB0WnhqeGo4NHpHbjRDOVprQjNLS3dzWG5xbWY5U2ds?= =?utf-8?B?OW5Cb3ZhVFB1S0dJbVpHZUFUa1N5eVZ1Y3poZmdqc2QxeXFSTXRscDN6UVlS?= =?utf-8?B?SXJneitJenRTNy9laTdSWlNGZTllaTdVeFI5TUxyUXlXSExvSndsRHNNZUtS?= =?utf-8?B?NGxzUTNKQnpVeVNMR3JPYjlDTlZDUjRJNzVEWWZCMFRxcUgyNVpQT1F2QU1E?= =?utf-8?B?V29DeGJzQjBEUW1hemJRdXdpT0VRS1YxejR2c0JtYVpqaUZDRjdKdDFucjVY?= =?utf-8?B?ZVlhRDJLbGljYWo4TEM3OVgxWURyeDYyOFFhbjY0bXpaQ0hLRVh1ZG9qMnFj?= =?utf-8?B?bHhPODR4dnZTaHBaTDZrUWs2a0VwcDJmK1JoYjdWSG5WaXRJdytrQVIyVkVw?= =?utf-8?B?TmkzdWVTMGV6VVdPQlNMekpueWUwRlBhbUw0UHVYY2ZOZFMrazBGQTRSRTVW?= =?utf-8?B?U0loZHRxeHNXMWcxblNScGxvMDNyUHZCYUxkZkxRSjIxRkJvaHBzSnc5S0Fo?= =?utf-8?B?aXlIbEpabEg0Nm02c3RZSG05QUxvS0lTd3UzcW5QWmRIb09rR3Q1WmdPQWov?= =?utf-8?B?dCtubXhpL2U0c2JjaFZvUVBOeERwUWRqcUVwS1o0ZUIxQ2hWSkV4a2xodEpS?= =?utf-8?B?L0FnQmd1cW01RDRIdml2V0tVMXBXaGhmWTczU1RTbVJDYlY3blhTTUxjMTNT?= =?utf-8?B?UjVQNUpTdkUyUGhYVnZzZE5vaERHbzlWM2dhL0hIbGswaUhSbWlVNWRDQTQ1?= =?utf-8?B?MXBydUNtMGoySHhDYkdaKzJUYzV1cFRUdlM4eExKam5mMkFveStyakttanN0?= =?utf-8?B?WGtzMjRHS3lKUVhFQkNBUGtpNEMwdWUvVHRwc0JDVVc5Y0Nad0p4b1Y4Z2cy?= =?utf-8?B?cmZ3MWU4QnFiVG1qbTFOckVOQXpvN1p3b3pZUzVtVjlPWVlVZzRWSDBmd3dZ?= =?utf-8?B?dFNCdk5uMVE2Z2dncnU3K0psUEduRnpPZzBURWRuZXJreHZ1S0ZITWh0MGJX?= =?utf-8?B?VnpVcVVQMi9PYXZ4SDJoZno5d1hNd0tleU02S0RtakdkazNrUDV4NjNTbmJm?= =?utf-8?B?RTN1dnNrdUpUb1REWW44K1NXa2RPSDlHN0xOZEswUDBrVENIMGtHL0VWOERM?= =?utf-8?B?Nm01Z2Z5VFdmeGJoTzhncUI2aDArK3JjendNYTFWb2c4cDJzS2VxYlMvRDgx?= =?utf-8?B?UmtWTllHL0xtcVRRREtUa1dEUDZCUXo2ZVFXSFM0MW1QNm9OSkx1MjRXMWQy?= =?utf-8?B?a1ovdmptcUp2c0NXZmdhelVGVDBBOUpIaVRBYkVOL1F6YWVzTjlEK1JrcUYx?= =?utf-8?B?RnhpT2ltckhyUmY3ZUg1eld2K09mNlpZV09lcGJvL0pUcHU3QmdDYUxrWS8v?= =?utf-8?B?ZFpSRFJ4c0VWVnZaM3BlbnRDNmhLelVudWIvYzVBZWlNWkV1U0lpMU85cHRI?= =?utf-8?B?NWFyemd5ckRXTFl1enRNUUdqNThTbnJDUS9JdHFuTkM4R0JuWWJ4a2lQdU50?= =?utf-8?B?TFBZL2tVR0JmeWtQK2RXbXhsdG8ydTNNb2l3Y2psc2N6c1FncUdHOFVHUjNy?= =?utf-8?B?TXZLbFJGY3FBWVNDQ3BPa2s0ZTBHekp3Y2wrbERNaXNPc1hlUCtwMEc4TFZ5?= =?utf-8?B?djRweTkrWFhIN3MzY0N2WnhsM2ZocjU4VHlVc3dJMnFGZ3pzcHdMRk5NN2lS?= =?utf-8?B?NHhuV1V2bFRDWGt4azFndUhjUTlBdFJ0S3dlaDZWMFZGVDEzdDRnMXdaQ28z?= =?utf-8?B?bWpTc1RDU1QyaTJYQjR5NTR6OHQ2STdKWi9Ibm5BdXZDTk52VzRWRlBTRHds?= =?utf-8?B?dWUyU21jZ0ZKaFdremJIM2JKNU0xcGhsQjk4eHdjQXZ2K3E2T3kwUnJPQTlL?= =?utf-8?B?RjNmSVB0aW01VTFvWDBGdEl6eGhUOEpUdUVzU2NNS0RHOUl3YXczbzRsY0xE?= =?utf-8?B?dkRNL3ZPM3FyNVJnK2s3QThLNmJkU2VFcVhmWFpYTnJiNW5EU1pGUjRFTG9S?= =?utf-8?B?cWZ1M2MvZTlDZTJYT1h1MnRuQ25KcDFYYW4vZGloYVArUlJGM1p5c0pwSlM4?= =?utf-8?B?MXZZS25LV0o4S1dWdTZrOWFLaVZIb1pxbmJIM2JCNVJTZWY3SzRZeXJsTXdL?= =?utf-8?B?T0wrS21zVHRiMVE0NXI0UzB0Ulp3QStjMDBTQlA0UTBTSVBubytPSDErMWxK?= =?utf-8?B?Q2J1TzMwbVFwMlN4blcrWnE5QzhON01mL2FJK1RLMTJjdFhMbElBaEJkWFZP?= =?utf-8?B?NUxnWG1kZUNka2puUEl6cVkvQTdScTVJZ3VsSjQvRlNZbk11a2RQQT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 631aeb68-88cb-48ea-bb77-08df18b219d2 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 14:02:12.8524 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /BVmgCIa1ZMFo3oRwaMpQdU7jTw55Y5tNMoW1QZy/SqQ9MMW6XNyloroDgqGjcQDjW977ZCvY6TPVuDxuIJofw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB9355 X-purgate-ID: tlsNG-ef75cf/1790085735-A5EC6AE4-D15BAFBB/0/0 X-purgate-type: clean X-purgate-size: 2876 Hi Michal, Thanks for the follow-up. On Fri, Jul 31, 2026 at 10:24:47AM +0200, Orzel, Michal wrote: > > > On 28-May-26 02:25, Mykola Kvach wrote: > > From: Mykola Kvach > > > > ITS quirks can impose restrictions on memory accessed by the ITS itself and > > on shared host LPI/Redistributor state. These scopes are not identical, so > > a single global ITS quirk state makes the host LPI policy depend implicitly > > on the quirks seen while initializing host ITSes. > > > > Add per-ITS quirk_flags to struct host_its and keep a separate > > host_lpi_flags state in the LPI code. The quirk table now records the > > ITS-private and host LPI scopes explicitly through its_flags and lpi_flags. > > The R-Car Gen4 quirk applies the same memory-related restrictions to both > > scopes, preserving the existing behavior without relying on an implicit > > aggregation step. > > > > This also removes the old assumption that all host ITSes must expose the > > same quirk state. Host LPI restrictions are accumulated only from quirk > > entries that explicitly set lpi_flags. > > > > Use per-ITS quirk_flags for GITS_CBASER, GITS_BASER and ITT allocations. > > Use host_lpi_flags directly in gic-v3-lpi.c for GICR_PROPBASER and > > GICR_PENDBASER setup. Memory-related quirk bits are named GICV3_QUIRK_MEM_* > > and are translated by shared gicv3_mem_get_*() helpers. > > > > Signed-off-by: Mykola Kvach > I already gave R-b for this patch but noticed two issues: > > [...] > > > > > -static void gicv3_its_enable_quirks(struct host_its *hw_its) > > +static void __init gicv3_its_collect_quirks(struct host_its *hw_its) > The only caller of gicv3_its_collect_quirks() is > gicv3_its_init_single_its(), which stays non-init until patch 4/4. > Please annotate the caller here as well. I plan to replace the first patch, whose release fix is now upstream, with the initialization-order follow-up discussed with Julien. It will prepare all ITSes and collect their quirks, initialize host LPI state, and then activate the ITSes. I'll put the __init annotations on the ITS preparation and activation functions, and gicv3_its_init(), in that replacement patch. This will make the quirk collector's caller init-only before the quirk-scope changes are introduced. > > [...] > > > @@ -157,6 +164,7 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base); > > /* Initialize the host structures for LPIs and the host ITSes. */ > > int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits); > > int gicv3_its_init(void); > > +void __init gicv3_lpi_update_host_flags(uint32_t flags); > Please, do not add __init here for a prototype. I'll also remove __init from the gicv3_lpi_update_host_flags() prototype and keep it on the definition. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:03:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:03:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428900.1651828 (Exim 4.92) (envelope-from ) id 1x915o-0004D4-RH; Tue, 22 Sep 2026 14:03:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428900.1651828; Tue, 22 Sep 2026 14:03:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x915o-0004Cx-Nc; Tue, 22 Sep 2026 14:03:32 +0000 Received: by outflank-mailman (input) for mailman id 1428900; Tue, 22 Sep 2026 14:00:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x912p-00039K-Lc for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:00:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x912p-00Gk3W-26 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:00:27 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab289f0-e002-0a2a0a5209dd-0a2a45018b22-20 for ; Tue, 22 Sep 2026 16:00:26 +0200 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab289f8-5984-0a2a45010019-cddcb483d2d0-3 for ; Tue, 22 Sep 2026 16:00:26 +0200 Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68MBPKrG620173 for ; Tue, 22 Sep 2026 14:00:24 GMT Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4guha5tqfw-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 22 Sep 2026 14:00:19 +0000 (GMT) Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2cc73f47bdcso68841645ad.3 for ; Tue, 22 Sep 2026 07:00:19 -0700 (PDT) Received: from [10.133.33.241] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2df5d0454bbsm10878375ad.49.2026.09.22.06.59.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 07:00:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= c0NMRdlbNh+6YYqfzxC0TJttAVqfbQgJC5qBWn4UzJY=; b=RKg5V6VdLKJJzT7t PAOWDCo7CsGKR7OpwqoLi+WRzFIOGrx4vDUV7YKN1sqK9h93Lw0BcGoaHafPx3Gd krNuxNPCp3J/nF+5B5ZFeU5XT9eWZ+0R20UyCpJ50cPLqIM68vb7HC+ebbN6VEPS 3AvZ5GCwB6zunk57xHu844aCwwAIBei2i/tzSxiMVeDUai8khhOYLu0t8vc+otwr zSRy7Wqhy984dKvxwb6+Wv1LXPnfWaeizeuLw6DR8idfSfdPegwpFI3dOjlwhviK zOa5Cm8wobhhIs1tAfseJbTccpfm92Pk8Jbz7j78EdUFhY68JRzGZoVK6LQ90Ss1 atjWIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1790085619; x=1790690419; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=c0NMRdlbNh+6YYqfzxC0TJttAVqfbQgJC5qBWn4UzJY=; b=G6eWS5G8ZIxyQ21tBtQNzyjAkATYQpBsDnMeXkO6oYGmONyxdlO0GpYxPnpRi1L6he 9v0WyRtZXoVYgb3qd51isq/X+dLRGCbxuwnipD3fGFg4tKuGl0wHiGQKm3KrMqSbYmsC pE7XpWrMMRxrIkMG6qHurgDoYMOCNJfsE3Z1swI3yJvsCPPSeQkQ2v161a9Mi4gRt27j oIlhpK4yR7pBqU8vcogQvt7j7rjyQ0y9qtJ8ybAHvD5rRI2RqQYBEzQO6eiTzdyreZf1 eI7Tdb0zkBcjh1zdmmTvlY2HYcL2oB37BPp21tEuZZg1fuyoTSkdA03qqC3TiuNumU0c Akcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790085619; x=1790690419; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=c0NMRdlbNh+6YYqfzxC0TJttAVqfbQgJC5qBWn4UzJY=; b=14NF7jcSnkNq1eOxay7DvD//EcHeypaAw4h7rxLUEWYa0QiM8rwVnQrDWRXK+HWWpp 1we15DWU+BIuRdMC1FNCe34PCCNQysCT+N0KXsaJOnQtK/msFe8PTHBcNRcsRboEFxAa hNTlUzcQQI1Siq+Wdk35wgzx6mXMNZcNo1dmgoBlARt2SysJeDHaDjcF28dCpowAQjg5 WKpkQeFMXozd8P0kfOKPdx1QEqY8pc7sEj50wZmxABLA2hprm5WLOHVKPC5rP1kw7oBv +8X7rivc43uw/+MyR49p4TnQ15gBt9kbC4LWw03LYOq/+FVSOz0adaTlLqRaU4obUXdH WMzQ== X-Forwarded-Encrypted: i=1; AKwUvBzIy+p8Nn6N2/n+CT1LeFzFapyU4Ouk1wELlZJEn0S+hL4M7+mTBlMRg6Mq/IHZy0SS8KbiQPvoVQc=@lists.xenproject.org X-Gm-Message-State: AFuF++lh9dMjfVreUzmGp5sI12v39p1hFZNBQIIaUxjSZhpYqeMFzwNW xgEAGWvdlsdrd34eqUY6cwr/mdj3OkbiNQnoPdGtMRhQL3h6QhTUF7IGAo3cFk0nh6cOh4KNEnM jYj6tkfo2tSv0LJMnMbmdaL6ZpUE3VPuy5iwAZJBFVhQiggveP4QGHfMu2bUgI4b+nozKvg== X-Gm-Gg: AYBFou3B27WAdhnVR1CYJdeccuRg1oJWKgczXdYCuwHmqirmgdwR+IyERuaFnvAntuy g3ZwXYOIISw6biN1yfFmZGIKYFw25CO0/hpB0B3jB8acQFHRYfmiPWVYRiDtmQ54M2EmB+rdmRD nYftHUGBXezWCwjS0oTYH3SqYnpM6mPiGao7snHcfDsgHhZNTBmDUlZWL2X49bnsKKQbfjNgyUZ mAMPFc2Oy5rGZYgsh8+KU6E/I46ggorAksG2pLU7OR1Sd5ZE/c+XKMKr1ApRiR83N7VPGIvrEv9 87gK7aVFoLDj/BO00P57gV5+N0tQu5iVpGTvNx6ZXdTCbtsfdBhBjTjUDtjgBEplH6PEVB9o0I9 LBPXmmBDuuKozcTBfVtmqlobmpQ2kn/tHrwQMz8tgtHrcamfqWWb8kNutpGaOoASLA+Lae8vC X-Received: by 2002:a17:903:1ace:b0:2dd:c0ff:e729 with SMTP id d9443c01a7336-2df60b692demr15638615ad.59.1790085612711; Tue, 22 Sep 2026 07:00:12 -0700 (PDT) X-Received: by 2002:a17:903:1ace:b0:2dd:c0ff:e729 with SMTP id d9443c01a7336-2df60b692demr15635505ad.59.1790085609925; Tue, 22 Sep 2026 07:00:09 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 21:59:43 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 12/13] treewide: convert rdmsrq() from a macro to an inline function To: Juergen Gross , linux-kernel@vger.kernel.org, x86@kernel.org, linux-perf-users@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, linux-edac@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, linux-coco@lists.linux.dev, linux-acpi@vger.kernel.org, linux-ide@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-crypto@vger.kernel.org, linux-gpio@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-mtd@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-fbdev@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Sean Christopherson , Paolo Bonzini , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Josh Poimboeuf , Pawan Gupta , Pu Wen , Tony Luck , Reinette Chatre , Dave Martin , James Morse , Babu Moger , Tony W Wang-oc , Vitaly Kuznetsov , Andy Lutomirski , Bjorn Helgaas , "Rafael J. Wysocki" , Pavel Machek , Kiryl Shutsemau , Rick Edgecombe , Boris Ostrovsky , Len Brown , Damien Le Moal , Niklas Cassel , David Airlie , Olivia Mackall , Herbert Xu , Viresh Kumar , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , Srinivas Pandruvada , Yazen Ghannam , Linus Walleij , Bartosz Golaszewski , Guenter Roeck , Artem Bityutskiy , Artem Bityutskiy , Arnd Bergmann , Greg Kroah-Hartman , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Ashok Raj , Hans de Goede , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Rajneesh Bhardwaj , Xi Pardee , Daniel Lezcano , Zhang Rui , Lukasz Luba , Helge Deller , xen-devel@lists.xenproject.org, linux-geode@lists.infradead.org, Michael Kelley , zhongqiu.han@oss.qualcomm.com References: <20260911074530.3140830-1-jgross@suse.com> <20260911074530.3140830-13-jgross@suse.com> Content-Language: en-US From: Zhongqiu Han In-Reply-To: <20260911074530.3140830-13-jgross@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: agGHtqiry33awEeZg4P7YaDVebyGL4_p X-Proofpoint-Spam-Info: AW1haW4tMjYwOTIyMDIwNCBTYWx0ZWRfX+uCNrj7bpqKn h0omy0HivMkZrFuxwMsYEC1XGLOo9nbqX2ly0YUxnTedyns6QvYrUXMsvDGxGvymZRo+SCga+KL Rs0N6kQ8kVN83dg8wsPCEyJ5M52IUIE= X-Authority-Analysis: v=2.4 cv=U+4Hnuru c=1 sm=1 tr=0 ts=6ab289f3 cx=c_pps a=MTSHoo12Qbhz2p7MsH1ifg==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=iox4zFpeAAAA:8 a=VwQbUJbxAAAA:8 a=UqCG9HQmAAAA:8 a=EUspDBNiAAAA:8 a=iJoDjuSkDfkr3SbJ1BgA:9 a=QEXdDO2ut3YA:10 a=GvdueXVYPmCkWapjIL-Q:22 a=WzC6qhA0u3u7Ye7llzcV:22 X-Proofpoint-ORIG-GUID: agGHtqiry33awEeZg4P7YaDVebyGL4_p X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTIyMDIwNCBTYWx0ZWRfX3shXLWOxVS36 exbMgEJRbNf1kYpmT5pOZQgRTVzEVroyb6ICjyiuY5A8kHI3DxU7NLLmpqlsx/GVZnYsCnJdJzb uxq7OIQuKPrJ3GpL4lYO5KCTchK7aWICfCwnisDkflXTj7HO9nWA0+dZWv4GtewMbRpL21F1jeV J41xFueFM5ri/F/j5ohxKPIlicx6EstLp8jQRigqSOi3sSC+vaFIYRjF+8yhshZ6TKMWrhDCd0j Q3Ioq6yOG2j7uUfTWEQIbLbfl5bBE2QKq+0p+vUB8gOwutS+RKQcyuKkp+XQTAXGJqdFn2LE1nk 8mYlV6Q5Lk2SvoJGq5G5PAgg6woVdiuBztZPOPZB08NoGkc6L5EliNVIt6ufqOEblxj/OYrbnFE HfpW2HlDRiH2VYhZx+hFmEYOAQwB4w== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-22_01,2026-09-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 spamscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609220204 X-purgate-ID: tlsNG-d62444/1790085626-C43594F7-74696594/0/0 X-purgate-type: clean X-purgate-size: 179419 On 9/11/2026 3:45 PM, Juergen Gross wrote: > Today rdmsrq() is a macro using its second parameter as the target for > storing the read MSR value. > > Convert rdmsrq() to an inline function returning the MSR value. > > The users have been converted using the following semantic patch: > > // Options: --include-headers > > virtual patch > virtual report > > @@ > expression msr, val; > @@ > ( > - rdmsrq(msr,val) > + val = rdmsrq(msr) > ) > > Signed-off-by: Juergen Gross > Acked-by: Damien Le Moal # ATA > Reviewed-by: Michael Kelley # Hyper-V My Reviewed-by tag for the cpufreq changes from v2 still applies. Reviewed-by: Zhongqiu Han # cpufreq > --- > arch/x86/coco/sev/core.c | 2 +- > arch/x86/events/amd/brs.c | 4 +-- > arch/x86/events/amd/core.c | 4 +-- > arch/x86/events/amd/ibs.c | 18 +++++----- > arch/x86/events/amd/lbr.c | 8 ++--- > arch/x86/events/amd/power.c | 8 ++--- > arch/x86/events/amd/uncore.c | 4 +-- > arch/x86/events/core.c | 20 +++++------ > arch/x86/events/intel/core.c | 11 +++--- > arch/x86/events/intel/cstate.c | 2 +- > arch/x86/events/intel/ds.c | 2 +- > arch/x86/events/intel/knc.c | 6 ++-- > arch/x86/events/intel/lbr.c | 14 ++++---- > arch/x86/events/intel/p4.c | 6 ++-- > arch/x86/events/intel/p6.c | 4 +-- > arch/x86/events/intel/pt.c | 12 +++---- > arch/x86/events/intel/uncore.c | 2 +- > arch/x86/events/intel/uncore_nhmex.c | 4 +-- > arch/x86/events/intel/uncore_snb.c | 2 +- > arch/x86/events/intel/uncore_snbep.c | 6 ++-- > arch/x86/events/msr.c | 2 +- > arch/x86/events/perf_event.h | 6 ++-- > arch/x86/events/rapl.c | 4 +-- > arch/x86/events/zhaoxin/core.c | 6 ++-- > arch/x86/hyperv/hv_apic.c | 6 ++-- > arch/x86/hyperv/hv_init.c | 26 +++++++------- > arch/x86/hyperv/hv_spinlock.c | 2 +- > arch/x86/include/asm/apic.h | 4 +-- > arch/x86/include/asm/debugreg.h | 2 +- > arch/x86/include/asm/fsgsbase.h | 2 +- > arch/x86/include/asm/kvm_host.h | 2 +- > arch/x86/include/asm/msr.h | 15 ++++---- > arch/x86/include/asm/paravirt.h | 8 ++--- > arch/x86/kernel/apic/apic.c | 14 ++++---- > arch/x86/kernel/apic/apic_numachip.c | 6 ++-- > arch/x86/kernel/cet.c | 2 +- > arch/x86/kernel/cpu/amd.c | 14 ++++---- > arch/x86/kernel/cpu/aperfmperf.c | 8 ++--- > arch/x86/kernel/cpu/bugs.c | 12 +++---- > arch/x86/kernel/cpu/bus_lock.c | 8 ++--- > arch/x86/kernel/cpu/centaur.c | 8 ++--- > arch/x86/kernel/cpu/common.c | 12 +++---- > arch/x86/kernel/cpu/feat_ctl.c | 4 +-- > arch/x86/kernel/cpu/hygon.c | 4 +-- > arch/x86/kernel/cpu/intel.c | 6 ++-- > arch/x86/kernel/cpu/intel_epb.c | 4 +-- > arch/x86/kernel/cpu/mce/amd.c | 4 +-- > arch/x86/kernel/cpu/mce/core.c | 8 ++--- > arch/x86/kernel/cpu/mce/inject.c | 2 +- > arch/x86/kernel/cpu/mce/intel.c | 18 +++++----- > arch/x86/kernel/cpu/mce/p5.c | 8 ++--- > arch/x86/kernel/cpu/mce/winchip.c | 2 +- > arch/x86/kernel/cpu/microcode/intel.c | 2 +- > arch/x86/kernel/cpu/mshyperv.c | 6 ++-- > arch/x86/kernel/cpu/mtrr/amd.c | 4 +-- > arch/x86/kernel/cpu/mtrr/cleanup.c | 4 +-- > arch/x86/kernel/cpu/mtrr/generic.c | 32 ++++++++--------- > arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +- > arch/x86/kernel/cpu/resctrl/core.c | 2 +- > arch/x86/kernel/cpu/resctrl/monitor.c | 4 +-- > arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 +-- > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +- > arch/x86/kernel/cpu/topology.c | 2 +- > arch/x86/kernel/cpu/topology_amd.c | 4 +-- > arch/x86/kernel/cpu/transmeta.c | 2 +- > arch/x86/kernel/cpu/tsx.c | 10 +++--- > arch/x86/kernel/cpu/umwait.c | 2 +- > arch/x86/kernel/cpu/zhaoxin.c | 4 +-- > arch/x86/kernel/fpu/core.c | 2 +- > arch/x86/kernel/hpet.c | 2 +- > arch/x86/kernel/kvm.c | 2 +- > arch/x86/kernel/mmconf-fam10h_64.c | 6 ++-- > arch/x86/kernel/process.c | 4 +-- > arch/x86/kernel/process_64.c | 14 ++++---- > arch/x86/kernel/shstk.c | 8 ++--- > arch/x86/kernel/traps.c | 4 +-- > arch/x86/kernel/tsc.c | 2 +- > arch/x86/kernel/tsc_msr.c | 6 ++-- > arch/x86/kernel/tsc_sync.c | 6 ++-- > arch/x86/kvm/msrs.c | 2 +- > arch/x86/kvm/svm/pmu.c | 4 +-- > arch/x86/kvm/svm/svm.c | 4 +-- > arch/x86/kvm/vmx/nested.c | 4 +-- > arch/x86/kvm/vmx/pmu_intel.c | 8 ++--- > arch/x86/kvm/vmx/sgx.c | 6 ++-- > arch/x86/kvm/vmx/vmx.c | 36 +++++++++---------- > arch/x86/kvm/x86.c | 6 ++-- > arch/x86/lib/insn-eval.c | 6 ++-- > arch/x86/lib/msr-smp.c | 2 +- > arch/x86/mm/pat/memtype.c | 2 +- > arch/x86/pci/amd_bus.c | 8 ++--- > arch/x86/platform/olpc/olpc-xo1-rtc.c | 6 ++-- > arch/x86/platform/olpc/olpc-xo1-sci.c | 2 +- > arch/x86/power/cpu.c | 10 +++--- > arch/x86/realmode/init.c | 2 +- > arch/x86/virt/hw.c | 8 ++--- > arch/x86/virt/svm/sev.c | 18 +++++----- > arch/x86/virt/vmx/tdx/tdx.c | 2 +- > arch/x86/xen/suspend.c | 2 +- > drivers/acpi/processor_perflib.c | 2 +- > drivers/ata/pata_cs5535.c | 4 +-- > drivers/ata/pata_cs5536.c | 2 +- > drivers/char/agp/nvidia-agp.c | 6 ++-- > drivers/char/hw_random/via-rng.c | 4 +-- > drivers/cpufreq/acpi-cpufreq.c | 8 ++--- > drivers/cpufreq/amd-pstate.c | 4 +-- > drivers/cpufreq/e_powersaver.c | 20 +++++------ > drivers/cpufreq/intel_pstate.c | 28 +++++++-------- > drivers/cpufreq/longhaul.c | 12 +++---- > drivers/cpufreq/longrun.c | 16 ++++----- > drivers/cpufreq/powernow-k7.c | 10 +++--- > drivers/cpufreq/powernow-k8.c | 8 ++--- > drivers/cpufreq/speedstep-centrino.c | 4 +-- > drivers/cpufreq/speedstep-lib.c | 14 ++++---- > drivers/edac/amd64_edac.c | 6 ++-- > drivers/gpio/gpio-cs5535.c | 2 +- > drivers/hv/mshv_vtl_main.c | 2 +- > drivers/hwmon/hwmon-vid.c | 4 +-- > drivers/idle/intel_idle.c | 26 +++++++------- > drivers/misc/cs5535-mfgpt.c | 6 ++-- > drivers/mtd/nand/raw/cs553x_nand.c | 6 ++-- > drivers/platform/x86/intel/ifs/load.c | 10 +++--- > drivers/platform/x86/intel/ifs/runtest.c | 8 ++--- > drivers/platform/x86/intel/pmc/cnp.c | 2 +- > .../intel/speed_select_if/isst_if_mbox_msr.c | 6 ++-- > .../intel/speed_select_if/isst_tpmi_core.c | 2 +- > drivers/platform/x86/intel_ips.c | 20 +++++------ > drivers/powercap/intel_rapl_msr.c | 2 +- > drivers/thermal/intel/intel_hfi.c | 8 ++--- > drivers/thermal/intel/therm_throt.c | 22 ++++++------ > drivers/thermal/intel/x86_pkg_temp_thermal.c | 6 ++-- > drivers/video/fbdev/geode/display_gx.c | 2 +- > drivers/video/fbdev/geode/gxfb_core.c | 2 +- > drivers/video/fbdev/geode/lxfb_ops.c | 18 +++++----- > drivers/video/fbdev/geode/suspend_gx.c | 8 ++--- > drivers/video/fbdev/geode/video_gx.c | 8 ++--- > include/linux/cs5535.h | 2 +- > 137 files changed, 483 insertions(+), 485 deletions(-) > > diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c > index cc292d7c6fd1..2a1875642cd4 100644 > --- a/arch/x86/coco/sev/core.c > +++ b/arch/x86/coco/sev/core.c > @@ -2026,7 +2026,7 @@ void __init snp_secure_tsc_init(void) > secrets = (__force struct snp_secrets_page *)mem; > > setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); > - rdmsrq(MSR_AMD64_GUEST_TSC_FREQ, tsc_freq_mhz); > + tsc_freq_mhz = rdmsrq(MSR_AMD64_GUEST_TSC_FREQ); > > /* Extract the GUEST TSC MHZ from BIT[17:0], rest is reserved space */ > tsc_freq_mhz &= GENMASK_ULL(17, 0); > diff --git a/arch/x86/events/amd/brs.c b/arch/x86/events/amd/brs.c > index dc564688f3d7..4df3a2a736e0 100644 > --- a/arch/x86/events/amd/brs.c > +++ b/arch/x86/events/amd/brs.c > @@ -325,7 +325,7 @@ void amd_brs_drain(void) > u32 brs_idx = tos - i; > u64 from, to; > > - rdmsrq(brs_to(brs_idx), to); > + to = rdmsrq(brs_to(brs_idx)); > > /* Entry does not belong to us (as marked by kernel) */ > if (to == BRS_POISON) > @@ -338,7 +338,7 @@ void amd_brs_drain(void) > */ > to = (u64)(((s64)to << shift) >> shift); > > - rdmsrq(brs_from(brs_idx), from); > + from = rdmsrq(brs_from(brs_idx)); > > if (!amd_brs_match_plm(event, from, to)) > continue; > diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c > index 49b6b8fce566..80ed49dba255 100644 > --- a/arch/x86/events/amd/core.c > +++ b/arch/x86/events/amd/core.c > @@ -663,7 +663,7 @@ static inline u64 amd_pmu_get_global_status(void) > u64 status; > > /* PerfCntrGlobalStatus is read-only */ > - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, status); > + status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); > > return status; > } > @@ -683,7 +683,7 @@ static bool amd_pmu_test_overflow_topbit(int idx) > { > u64 counter; > > - rdmsrq(x86_pmu_event_addr(idx), counter); > + counter = rdmsrq(x86_pmu_event_addr(idx)); > > return !(counter & BIT_ULL(x86_pmu.cntval_bits - 1)); > } > diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c > index 3531f9c23b8c..17eab32164df 100644 > --- a/arch/x86/events/amd/ibs.c > +++ b/arch/x86/events/amd/ibs.c > @@ -505,7 +505,7 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs, struct perf_event *event, > * prev count manually on overflow. > */ > while (!perf_event_try_update(event, count, 64)) { > - rdmsrq(event->hw.config_base, *config); > + *config = rdmsrq(event->hw.config_base); > count = perf_ibs->get_count(*config); > } > } > @@ -610,7 +610,7 @@ static void perf_ibs_stop(struct perf_event *event, int flags) > if (!stopping && (hwc->state & PERF_HES_UPTODATE)) > return; > > - rdmsrq(hwc->config_base, config); > + config = rdmsrq(hwc->config_base); > > if (stopping) { > /* > @@ -1437,7 +1437,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs) > hwc = &event->hw; > msr = hwc->config_base; > buf = ibs_data.regs; > - rdmsrq(msr, *buf); > + *buf = rdmsrq(msr); > if (!(*buf++ & perf_ibs->valid_mask)) > goto fail; > > @@ -1455,7 +1455,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs) > offset_max = perf_ibs_get_offset_max(perf_ibs, event, check_rip); > > do { > - rdmsrq(msr + offset, *buf++); > + *buf++ = rdmsrq(msr + offset); > size++; > offset = find_next_bit(perf_ibs->offset_mask, > perf_ibs->offset_max, > @@ -1497,17 +1497,17 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs) > if (event->attr.sample_type & PERF_SAMPLE_RAW) { > if (perf_ibs == &perf_ibs_op) { > if (ibs_caps & IBS_CAPS_BRNTRGT) { > - rdmsrq(MSR_AMD64_IBSBRTARGET, *buf++); > + *buf++ = rdmsrq(MSR_AMD64_IBSBRTARGET); > br_target_idx = size; > size++; > } > if (ibs_caps & IBS_CAPS_OPDATA4) { > - rdmsrq(MSR_AMD64_IBSOPDATA4, *buf++); > + *buf++ = rdmsrq(MSR_AMD64_IBSOPDATA4); > size++; > } > } > if (perf_ibs == &perf_ibs_fetch && (ibs_caps & IBS_CAPS_FETCHCTLEXTD)) { > - rdmsrq(MSR_AMD64_ICIBSEXTDCTL, *buf++); > + *buf++ = rdmsrq(MSR_AMD64_ICIBSEXTDCTL); > size++; > } > } > @@ -1768,7 +1768,7 @@ static inline int ibs_eilvt_valid(void) > > preempt_disable(); > > - rdmsrq(MSR_AMD64_IBSCTL, val); > + val = rdmsrq(MSR_AMD64_IBSCTL); > offset = val & IBSCTL_LVT_OFFSET_MASK; > > if (!(val & IBSCTL_LVT_OFFSET_VALID)) { > @@ -1883,7 +1883,7 @@ static inline int get_ibs_lvt_offset(void) > { > u64 val; > > - rdmsrq(MSR_AMD64_IBSCTL, val); > + val = rdmsrq(MSR_AMD64_IBSCTL); > if (!(val & IBSCTL_LVT_OFFSET_VALID)) > return -EINVAL; > > diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c > index 9d9c961989d5..29628af6a023 100644 > --- a/arch/x86/events/amd/lbr.c > +++ b/arch/x86/events/amd/lbr.c > @@ -76,7 +76,7 @@ static __always_inline u64 amd_pmu_lbr_get_from(unsigned int idx) > { > u64 val; > > - rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2, val); > + val = rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2); > > return val; > } > @@ -85,7 +85,7 @@ static __always_inline u64 amd_pmu_lbr_get_to(unsigned int idx) > { > u64 val; > > - rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2 + 1, val); > + val = rdmsrq(MSR_AMD_SAMP_BR_FROM + idx * 2 + 1); > > return val; > } > @@ -404,11 +404,11 @@ void amd_pmu_lbr_enable_all(void) > } > > if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) { > - rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl); > + dbg_ctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); > wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI); > } > > - rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg); > + dbg_extn_cfg = rdmsrq(MSR_AMD_DBG_EXTN_CFG); > wrmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg | DBG_EXTN_CFG_LBRV2EN); > } > > diff --git a/arch/x86/events/amd/power.c b/arch/x86/events/amd/power.c > index 66197214b010..5a5ebce0a526 100644 > --- a/arch/x86/events/amd/power.c > +++ b/arch/x86/events/amd/power.c > @@ -52,8 +52,8 @@ static void event_update(struct perf_event *event) > > prev_pwr_acc = hwc->pwr_acc; > prev_ptsc = hwc->ptsc; > - rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR, new_pwr_acc); > - rdmsrq(MSR_F15H_PTSC, new_ptsc); > + new_pwr_acc = rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR); > + new_ptsc = rdmsrq(MSR_F15H_PTSC); > > /* > * Calculate the CU power consumption over a time period, the unit of > @@ -79,8 +79,8 @@ static void __pmu_event_start(struct perf_event *event) > > event->hw.state = 0; > > - rdmsrq(MSR_F15H_PTSC, event->hw.ptsc); > - rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR, event->hw.pwr_acc); > + event->hw.ptsc = rdmsrq(MSR_F15H_PTSC); > + event->hw.pwr_acc = rdmsrq(MSR_F15H_CU_PWR_ACCUMULATOR); > } > > static void pmu_event_start(struct perf_event *event, int mode) > diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c > index 7181973b5b12..35f0c4831919 100644 > --- a/arch/x86/events/amd/uncore.c > +++ b/arch/x86/events/amd/uncore.c > @@ -151,7 +151,7 @@ static void amd_uncore_read(struct perf_event *event) > * read counts directly from the corresponding PERF_CTR. > */ > if (hwc->event_base_rdpmc < 0) > - rdmsrq(hwc->event_base, new); > + new = rdmsrq(hwc->event_base); > else > new = rdpmc(hwc->event_base_rdpmc); > > @@ -998,7 +998,7 @@ static void amd_uncore_umc_read(struct perf_event *event) > * UMC counters do not have RDPMC assignments. Read counts directly > * from the corresponding PERF_CTR. > */ > - rdmsrq(hwc->event_base, new); > + new = rdmsrq(hwc->event_base); > > /* > * Unlike the other uncore counters, UMC counters saturate and set the > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c > index 8b3ea0adb965..34bd80bb2c9e 100644 > --- a/arch/x86/events/core.c > +++ b/arch/x86/events/core.c > @@ -711,7 +711,7 @@ void x86_pmu_disable_all(void) > > if (!test_bit(idx, cpuc->active_mask)) > continue; > - rdmsrq(x86_pmu_config_addr(idx), val); > + val = rdmsrq(x86_pmu_config_addr(idx)); > if (!(val & ARCH_PERFMON_EVENTSEL_ENABLE)) > continue; > val &= ~ARCH_PERFMON_EVENTSEL_ENABLE; > @@ -1592,10 +1592,10 @@ void perf_event_print_debug(void) > return; > > if (x86_pmu.version >= 2) { > - rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL, ctrl); > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); > - rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, overflow); > - rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL, fixed); > + ctrl = rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL); > + status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > + overflow = rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL); > + fixed = rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL); > > pr_info("\n"); > pr_info("CPU#%d: ctrl: %016llx\n", cpu, ctrl); > @@ -1603,19 +1603,19 @@ void perf_event_print_debug(void) > pr_info("CPU#%d: overflow: %016llx\n", cpu, overflow); > pr_info("CPU#%d: fixed: %016llx\n", cpu, fixed); > if (pebs_constraints) { > - rdmsrq(MSR_IA32_PEBS_ENABLE, pebs); > + pebs = rdmsrq(MSR_IA32_PEBS_ENABLE); > pr_info("CPU#%d: pebs: %016llx\n", cpu, pebs); > } > if (x86_pmu.lbr_nr) { > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); > pr_info("CPU#%d: debugctl: %016llx\n", cpu, debugctl); > } > } > pr_info("CPU#%d: active: %016llx\n", cpu, *(u64 *)cpuc->active_mask); > > for_each_set_bit(idx, cntr_mask, X86_PMC_IDX_MAX) { > - rdmsrq(x86_pmu_config_addr(idx), pmc_ctrl); > - rdmsrq(x86_pmu_event_addr(idx), pmc_count); > + pmc_ctrl = rdmsrq(x86_pmu_config_addr(idx)); > + pmc_count = rdmsrq(x86_pmu_event_addr(idx)); > > prev_left = per_cpu(pmc_prev_left[idx], cpu); > > @@ -1627,7 +1627,7 @@ void perf_event_print_debug(void) > cpu, idx, prev_left); > } > for_each_set_bit(idx, fixed_cntr_mask, X86_PMC_IDX_MAX) { > - rdmsrq(x86_pmu_fixed_ctr_addr(idx), pmc_count); > + pmc_count = rdmsrq(x86_pmu_fixed_ctr_addr(idx)); > > pr_info("CPU#%d: fixed-PMC%d count: %016llx\n", > cpu, idx, pmc_count); > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c > index cc13164d948f..41ae90b6bbdc 100644 > --- a/arch/x86/events/intel/core.c > +++ b/arch/x86/events/intel/core.c > @@ -2965,7 +2965,7 @@ static inline u64 intel_pmu_get_status(void) > { > u64 status; > > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); > + status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > > return status; > } > @@ -3494,7 +3494,7 @@ static void intel_pmu_enable_event_ext(struct perf_event *event) > else > new.thresh = ARCH_PEBS_THRESH_SINGLE; > > - rdmsrq(MSR_IA32_PEBS_INDEX, old.whole); > + old.whole = rdmsrq(MSR_IA32_PEBS_INDEX); > if (new.thresh != old.thresh || !old.en) { > if (old.thresh == ARCH_PEBS_THRESH_MULTI && old.wr > 0) { > /* > @@ -6255,8 +6255,7 @@ static void intel_update_pmu_caps(struct pmu *pmu) > update_pmu_cap_from_perfmonext(pmu); > > if (is_hybrid() && this_cpu_has(X86_FEATURE_PDCM)) { > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, > - hybrid(pmu, intel_cap).capabilities); > + hybrid(pmu, intel_cap).capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES); > > /* > * Restore perf_metrics on platforms with broken > @@ -6412,7 +6411,7 @@ static void intel_pmu_cpu_starting(int cpu) > if (!is_hybrid() && x86_pmu.intel_cap.perf_metrics) { > union perf_capabilities perf_cap; > > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, perf_cap.capabilities); > + perf_cap.capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES); > if (!perf_cap.perf_metrics) { > x86_pmu.intel_cap.perf_metrics = 0; > x86_pmu.intel_ctrl &= ~GLOBAL_CTRL_EN_PERF_METRICS; > @@ -7959,7 +7958,7 @@ __init int intel_pmu_init(void) > if (boot_cpu_has(X86_FEATURE_PDCM)) { > u64 capabilities; > > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, capabilities); > + capabilities = rdmsrq(MSR_IA32_PERF_CAPABILITIES); > x86_pmu.intel_cap.capabilities = capabilities; > } > > diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c > index f3d5ee07f8f2..69eb6cf51d3b 100644 > --- a/arch/x86/events/intel/cstate.c > +++ b/arch/x86/events/intel/cstate.c > @@ -324,7 +324,7 @@ static inline u64 cstate_pmu_read_counter(struct perf_event *event) > { > u64 val; > > - rdmsrq(event->hw.event_base, val); > + val = rdmsrq(event->hw.event_base); > return val; > } > > diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c > index 8940f0292229..ffe4f84c411d 100644 > --- a/arch/x86/events/intel/ds.c > +++ b/arch/x86/events/intel/ds.c > @@ -3231,7 +3231,7 @@ static void intel_pmu_drain_arch_pebs(struct pt_regs *iregs, > void *base, *at, *top; > u64 mask; > > - rdmsrq(MSR_IA32_PEBS_INDEX, index.whole); > + index.whole = rdmsrq(MSR_IA32_PEBS_INDEX); > > if (unlikely(!index.wr)) { > intel_pmu_pebs_event_update_no_drain(cpuc, X86_PMC_IDX_MAX); > diff --git a/arch/x86/events/intel/knc.c b/arch/x86/events/intel/knc.c > index e887adc108ac..c4f81215f758 100644 > --- a/arch/x86/events/intel/knc.c > +++ b/arch/x86/events/intel/knc.c > @@ -160,7 +160,7 @@ static void knc_pmu_disable_all(void) > { > u64 val; > > - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); > + val = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL); > val &= ~(KNC_ENABLE_COUNTER0|KNC_ENABLE_COUNTER1); > wrmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); > } > @@ -169,7 +169,7 @@ static void knc_pmu_enable_all(int added) > { > u64 val; > > - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); > + val = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL); > val |= (KNC_ENABLE_COUNTER0|KNC_ENABLE_COUNTER1); > wrmsrq(MSR_KNC_IA32_PERF_GLOBAL_CTRL, val); > } > @@ -201,7 +201,7 @@ static inline u64 knc_pmu_get_status(void) > { > u64 status; > > - rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_STATUS, status); > + status = rdmsrq(MSR_KNC_IA32_PERF_GLOBAL_STATUS); > > return status; > } > diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c > index cbe5c762008d..fc05ec3b9a99 100644 > --- a/arch/x86/events/intel/lbr.c > +++ b/arch/x86/events/intel/lbr.c > @@ -141,7 +141,7 @@ static void __intel_pmu_lbr_enable(bool pmi) > if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR) && !pmi && cpuc->lbr_sel) > wrmsrq(MSR_LBR_SELECT, lbr_select); > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); > orig_debugctl = debugctl; > > if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR)) > @@ -211,7 +211,7 @@ static inline u64 intel_pmu_lbr_tos(void) > { > u64 tos; > > - rdmsrq(x86_pmu.lbr_tos, tos); > + tos = rdmsrq(x86_pmu.lbr_tos); > return tos; > } > > @@ -304,7 +304,7 @@ static __always_inline u64 rdlbr_from(unsigned int idx, struct lbr_entry *lbr) > if (lbr) > return lbr->from; > > - rdmsrq(x86_pmu.lbr_from + idx, val); > + val = rdmsrq(x86_pmu.lbr_from + idx); > > return lbr_from_signext_quirk_rd(val); > } > @@ -316,7 +316,7 @@ static __always_inline u64 rdlbr_to(unsigned int idx, struct lbr_entry *lbr) > if (lbr) > return lbr->to; > > - rdmsrq(x86_pmu.lbr_to + idx, val); > + val = rdmsrq(x86_pmu.lbr_to + idx); > > return val; > } > @@ -328,7 +328,7 @@ static __always_inline u64 rdlbr_info(unsigned int idx, struct lbr_entry *lbr) > if (lbr) > return lbr->info; > > - rdmsrq(x86_pmu.lbr_info + idx, val); > + val = rdmsrq(x86_pmu.lbr_info + idx); > > return val; > } > @@ -477,7 +477,7 @@ void intel_pmu_lbr_save(void *ctx) > task_ctx->tos = tos; > > if (cpuc->lbr_select) > - rdmsrq(MSR_LBR_SELECT, task_ctx->lbr_sel); > + task_ctx->lbr_sel = rdmsrq(MSR_LBR_SELECT); > } > > static void intel_pmu_arch_lbr_save(void *ctx) > @@ -754,7 +754,7 @@ void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc) > u64 lbr; > } msr_lastbranch; > > - rdmsrq(x86_pmu.lbr_from + lbr_idx, msr_lastbranch.lbr); > + msr_lastbranch.lbr = rdmsrq(x86_pmu.lbr_from + lbr_idx); > > perf_clear_branch_entry_bitfields(br); > > diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c > index 5368dc31787c..e675e85682f1 100644 > --- a/arch/x86/events/intel/p4.c > +++ b/arch/x86/events/intel/p4.c > @@ -860,7 +860,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_perf_event *hwc) > u64 v; > > /* an official way for overflow indication */ > - rdmsrq(hwc->config_base, v); > + v = rdmsrq(hwc->config_base); > if (v & P4_CCCR_OVF) { > wrmsrq(hwc->config_base, v & ~P4_CCCR_OVF); > return 1; > @@ -873,7 +873,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_perf_event *hwc) > * the counter has reached zero value and continued counting before > * real NMI signal was received: > */ > - rdmsrq(hwc->event_base, v); > + v = rdmsrq(hwc->event_base); > if (!(v & ARCH_P4_UNFLAGGED_BIT)) > return 1; > > @@ -1373,7 +1373,7 @@ __init int p4_pmu_init(void) > /* If we get stripped -- indexing fails */ > BUILD_BUG_ON(ARCH_P4_MAX_CCCR > INTEL_PMC_MAX_GENERIC); > > - rdmsrq(MSR_IA32_MISC_ENABLE, misc); > + misc = rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(misc & MSR_IA32_MISC_ENABLE_EMON)) { > pr_cont("unsupported Netburst CPU model %d ", > boot_cpu_data.x86_model); > diff --git a/arch/x86/events/intel/p6.c b/arch/x86/events/intel/p6.c > index fb991e0ac614..4268b576b5d8 100644 > --- a/arch/x86/events/intel/p6.c > +++ b/arch/x86/events/intel/p6.c > @@ -143,7 +143,7 @@ static void p6_pmu_disable_all(void) > u64 val; > > /* p6 only has one enable register */ > - rdmsrq(MSR_P6_EVNTSEL0, val); > + val = rdmsrq(MSR_P6_EVNTSEL0); > val &= ~ARCH_PERFMON_EVENTSEL_ENABLE; > wrmsrq(MSR_P6_EVNTSEL0, val); > } > @@ -153,7 +153,7 @@ static void p6_pmu_enable_all(int added) > unsigned long val; > > /* p6 only has one enable register */ > - rdmsrq(MSR_P6_EVNTSEL0, val); > + val = rdmsrq(MSR_P6_EVNTSEL0); > val |= ARCH_PERFMON_EVENTSEL_ENABLE; > wrmsrq(MSR_P6_EVNTSEL0, val); > } > diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c > index 5754cd405562..d595d69b49a1 100644 > --- a/arch/x86/events/intel/pt.c > +++ b/arch/x86/events/intel/pt.c > @@ -196,7 +196,7 @@ static int __init pt_pmu_hw_init(void) > int ret; > long i; > > - rdmsrq(MSR_PLATFORM_INFO, reg); > + reg = rdmsrq(MSR_PLATFORM_INFO); > pt_pmu.max_nonturbo_ratio = (reg & 0xff00) >> 8; > > /* > @@ -232,7 +232,7 @@ static int __init pt_pmu_hw_init(void) > * "IA32_VMX_MISC[bit 14]" being 1 means PT can trace > * post-VMXON. > */ > - rdmsrq(MSR_IA32_VMX_MISC, reg); > + reg = rdmsrq(MSR_IA32_VMX_MISC); > if (reg & BIT(14)) > pt_pmu.vmx = true; > } > @@ -935,7 +935,7 @@ static void pt_handle_status(struct pt *pt) > int advance = 0; > u64 status; > > - rdmsrq(MSR_IA32_RTIT_STATUS, status); > + status = rdmsrq(MSR_IA32_RTIT_STATUS); > > if (status & RTIT_STATUS_ERROR) { > pr_err_ratelimited("ToPA ERROR encountered, trying to recover\n"); > @@ -994,12 +994,12 @@ static void pt_read_offset(struct pt_buffer *buf) > struct topa_page *tp; > > if (!buf->single) { > - rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE, pt->output_base); > + pt->output_base = rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE); > tp = phys_to_virt(pt->output_base); > buf->cur = &tp->topa; > } > > - rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK, pt->output_mask); > + pt->output_mask = rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK); > /* offset within current output region */ > buf->output_off = pt->output_mask >> 32; > /* index of current output region within this table */ > @@ -1623,7 +1623,7 @@ static void pt_event_start(struct perf_event *event, int mode) > * PMI might have just cleared these, so resume_allowed > * must be checked again also. > */ > - rdmsrq(MSR_IA32_RTIT_STATUS, status); > + status = rdmsrq(MSR_IA32_RTIT_STATUS); > if (!(status & (RTIT_STATUS_TRIGGEREN | > RTIT_STATUS_ERROR | > RTIT_STATUS_STOPPED)) && > diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c > index b2109b37ea7f..ab2c5a962b31 100644 > --- a/arch/x86/events/intel/uncore.c > +++ b/arch/x86/events/intel/uncore.c > @@ -171,7 +171,7 @@ u64 uncore_msr_read_counter(struct intel_uncore_box *box, struct perf_event *eve > { > u64 count; > > - rdmsrq(event->hw.event_base, count); > + count = rdmsrq(event->hw.event_base); > > return count; > } > diff --git a/arch/x86/events/intel/uncore_nhmex.c b/arch/x86/events/intel/uncore_nhmex.c > index 7a6855281102..81e838e6f729 100644 > --- a/arch/x86/events/intel/uncore_nhmex.c > +++ b/arch/x86/events/intel/uncore_nhmex.c > @@ -216,7 +216,7 @@ static void nhmex_uncore_msr_disable_box(struct intel_uncore_box *box) > u64 config; > > if (msr) { > - rdmsrq(msr, config); > + config = rdmsrq(msr); > config &= ~((1ULL << uncore_num_counters(box)) - 1); > /* WBox has a fixed counter */ > if (uncore_msr_fixed_ctl(box)) > @@ -231,7 +231,7 @@ static void nhmex_uncore_msr_enable_box(struct intel_uncore_box *box) > u64 config; > > if (msr) { > - rdmsrq(msr, config); > + config = rdmsrq(msr); > config |= (1ULL << uncore_num_counters(box)) - 1; > /* WBox has a fixed counter */ > if (uncore_msr_fixed_ctl(box)) > diff --git a/arch/x86/events/intel/uncore_snb.c b/arch/x86/events/intel/uncore_snb.c > index 055131c508ff..da864724ff20 100644 > --- a/arch/x86/events/intel/uncore_snb.c > +++ b/arch/x86/events/intel/uncore_snb.c > @@ -533,7 +533,7 @@ static int icl_get_cbox_num(void) > { > u64 num_boxes; > > - rdmsrq(ICL_UNC_CBO_CONFIG, num_boxes); > + num_boxes = rdmsrq(ICL_UNC_CBO_CONFIG); > > return num_boxes & ICL_UNC_NUM_CBO_MASK; > } > diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c > index a97cd029db36..490725c8fee1 100644 > --- a/arch/x86/events/intel/uncore_snbep.c > +++ b/arch/x86/events/intel/uncore_snbep.c > @@ -642,7 +642,7 @@ static void snbep_uncore_msr_disable_box(struct intel_uncore_box *box) > > msr = uncore_msr_box_ctl(box); > if (msr) { > - rdmsrq(msr, config); > + config = rdmsrq(msr); > config |= SNBEP_PMON_BOX_CTL_FRZ; > wrmsrq(msr, config); > } > @@ -655,7 +655,7 @@ static void snbep_uncore_msr_enable_box(struct intel_uncore_box *box) > > msr = uncore_msr_box_ctl(box); > if (msr) { > - rdmsrq(msr, config); > + config = rdmsrq(msr); > config &= ~SNBEP_PMON_BOX_CTL_FRZ; > wrmsrq(msr, config); > } > @@ -6370,7 +6370,7 @@ void spr_uncore_cpu_init(void) > * of UNCORE_SPR_CHA) is incorrect on some SPR variants because of a > * firmware bug. Using the value from SPR_MSR_UNC_CBO_CONFIG to replace it. > */ > - rdmsrq(SPR_MSR_UNC_CBO_CONFIG, num_cbo); > + num_cbo = rdmsrq(SPR_MSR_UNC_CBO_CONFIG); > /* > * The MSR doesn't work on the EMR XCC, but the firmware bug doesn't impact > * the EMR XCC. Don't let the value from the MSR replace the existing value. > diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c > index 76d6418c5055..0e59781549ca 100644 > --- a/arch/x86/events/msr.c > +++ b/arch/x86/events/msr.c > @@ -158,7 +158,7 @@ static inline u64 msr_read_counter(struct perf_event *event) > u64 now; > > if (event->hw.event_base) > - rdmsrq(event->hw.event_base, now); > + now = rdmsrq(event->hw.event_base); > else > now = rdtsc_ordered(); > > diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h > index 71ed5b2acea2..4abdb9475e8f 100644 > --- a/arch/x86/events/perf_event.h > +++ b/arch/x86/events/perf_event.h > @@ -1475,11 +1475,11 @@ static __always_inline void __amd_pmu_lbr_disable(void) > { > u64 dbg_ctl, dbg_extn_cfg; > > - rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg); > + dbg_extn_cfg = rdmsrq(MSR_AMD_DBG_EXTN_CFG); > wrmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg & ~DBG_EXTN_CFG_LBRV2EN); > > if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) { > - rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl); > + dbg_ctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); > wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl & ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI); > } > } > @@ -1633,7 +1633,7 @@ static __always_inline void __intel_pmu_lbr_disable(void) > { > u64 debugctl; > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); > debugctl &= ~(DEBUGCTLMSR_LBR | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI); > wrmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > } > diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c > index 8ed03c32f560..180cc18282ca 100644 > --- a/arch/x86/events/rapl.c > +++ b/arch/x86/events/rapl.c > @@ -193,7 +193,7 @@ static inline unsigned int get_rapl_pmu_idx(int cpu, int scope) > static inline u64 rapl_read_counter(struct perf_event *event) > { > u64 raw; > - rdmsrq(event->hw.event_base, raw); > + raw = rdmsrq(event->hw.event_base); > return raw; > } > > @@ -222,7 +222,7 @@ static u64 rapl_event_update(struct perf_event *event) > > prev_raw_count = local64_read(&hwc->prev_count); > do { > - rdmsrq(event->hw.event_base, new_raw_count); > + new_raw_count = rdmsrq(event->hw.event_base); > } while (!local64_try_cmpxchg(&hwc->prev_count, > &prev_raw_count, new_raw_count)); > > diff --git a/arch/x86/events/zhaoxin/core.c b/arch/x86/events/zhaoxin/core.c > index e506f677db57..1980e5995e27 100644 > --- a/arch/x86/events/zhaoxin/core.c > +++ b/arch/x86/events/zhaoxin/core.c > @@ -268,7 +268,7 @@ static inline u64 zhaoxin_pmu_get_status(void) > { > u64 status; > > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); > + status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > > return status; > } > @@ -295,7 +295,7 @@ static void zhaoxin_pmu_disable_fixed(struct hw_perf_event *hwc) > > mask = 0xfULL << (idx * 4); > > - rdmsrq(hwc->config_base, ctrl_val); > + ctrl_val = rdmsrq(hwc->config_base); > ctrl_val &= ~mask; > wrmsrq(hwc->config_base, ctrl_val); > } > @@ -331,7 +331,7 @@ static void zhaoxin_pmu_enable_fixed(struct hw_perf_event *hwc) > bits <<= (idx * 4); > mask = 0xfULL << (idx * 4); > > - rdmsrq(hwc->config_base, ctrl_val); > + ctrl_val = rdmsrq(hwc->config_base); > ctrl_val &= ~mask; > ctrl_val |= bits; > wrmsrq(hwc->config_base, ctrl_val); > diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c > index 95f1782d1e17..4e30f9a11bc4 100644 > --- a/arch/x86/hyperv/hv_apic.c > +++ b/arch/x86/hyperv/hv_apic.c > @@ -38,7 +38,7 @@ static u64 hv_apic_icr_read(void) > { > u64 reg_val; > > - rdmsrq(HV_X64_MSR_ICR, reg_val); > + reg_val = rdmsrq(HV_X64_MSR_ICR); > return reg_val; > } > > @@ -64,10 +64,10 @@ static u32 hv_apic_read(u32 reg) > > switch (reg) { > case APIC_EOI: > - rdmsrq(HV_X64_MSR_EOI, reg_val.q); > + reg_val.q = rdmsrq(HV_X64_MSR_EOI); > return reg_val.l; > case APIC_TASKPRI: > - rdmsrq(HV_X64_MSR_TPR, reg_val.q); > + reg_val.q = rdmsrq(HV_X64_MSR_TPR); > return reg_val.l; > > default: > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c > index 0b4a1c0b0b16..672a9656446e 100644 > --- a/arch/x86/hyperv/hv_init.c > +++ b/arch/x86/hyperv/hv_init.c > @@ -101,7 +101,7 @@ static int hyperv_init_ghcb(void) > * returned by MSR_AMD64_SEV_ES_GHCB is above shared > * memory boundary and map it here. > */ > - rdmsrq(MSR_AMD64_SEV_ES_GHCB, ghcb_gpa); > + ghcb_gpa = rdmsrq(MSR_AMD64_SEV_ES_GHCB); > > /* Mask out vTOM bit and map as decrypted */ > ghcb_gpa &= ~ms_hyperv.shared_gpa_boundary; > @@ -134,7 +134,7 @@ static int hv_cpu_init(unsigned int cpu) > * For root partition we get the hypervisor provided VP assist > * page, instead of allocating a new page. > */ > - rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); > + msr.as_uint64 = rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE); > *hvp = memremap(msr.pfn << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT, > PAGE_SIZE, MEMREMAP_WB); > } else { > @@ -182,7 +182,7 @@ static void hv_reenlightenment_notify(struct work_struct *dummy) > { > struct hv_tsc_emulation_status emu_status; > > - rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); > + *(u64 *)&emu_status = rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS); > > /* Don't issue the callback if TSC accesses are not emulated */ > if (hv_reenlightenment_cb && emu_status.inprogress) > @@ -195,11 +195,11 @@ void hyperv_stop_tsc_emulation(void) > u64 freq; > struct hv_tsc_emulation_status emu_status; > > - rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); > + *(u64 *)&emu_status = rdmsrq(HV_X64_MSR_TSC_EMULATION_STATUS); > emu_status.inprogress = 0; > wrmsrq(HV_X64_MSR_TSC_EMULATION_STATUS, *(u64 *)&emu_status); > > - rdmsrq(HV_X64_MSR_TSC_FREQUENCY, freq); > + freq = rdmsrq(HV_X64_MSR_TSC_FREQUENCY); > tsc_khz = div64_u64(freq, 1000); > } > EXPORT_SYMBOL_GPL(hyperv_stop_tsc_emulation); > @@ -259,7 +259,7 @@ void clear_hv_tscchange_cb(void) > if (!hv_reenlightenment_available()) > return; > > - rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *(u64 *)&re_ctrl); > + *(u64 *)&re_ctrl = rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL); > re_ctrl.enabled = 0; > wrmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *(u64 *)&re_ctrl); > > @@ -295,7 +295,7 @@ static int hv_cpu_die(unsigned int cpu) > */ > memunmap(hv_vp_assist_page[cpu]); > hv_vp_assist_page[cpu] = NULL; > - rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); > + msr.as_uint64 = rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE); > msr.enable = 0; > } > wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); > @@ -304,7 +304,7 @@ static int hv_cpu_die(unsigned int cpu) > if (hv_reenlightenment_cb == NULL) > return 0; > > - rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl)); > + *((u64 *)&re_ctrl) = rdmsrq(HV_X64_MSR_REENLIGHTENMENT_CONTROL); > if (re_ctrl.target_vp == hv_vp_index[cpu]) { > /* > * Reassign reenlightenment notifications to some other online > @@ -375,7 +375,7 @@ static int hv_suspend(void *data) > hv_set_hypercall_pg(NULL); > > /* Disable the hypercall page in the hypervisor */ > - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL); > hypercall_msr.enable = 0; > wrmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > > @@ -392,7 +392,7 @@ static void hv_resume(void *data) > WARN_ON(ret); > > /* Re-enable the hypercall page */ > - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL); > hypercall_msr.enable = 1; > hypercall_msr.guest_physical_address = > vmalloc_to_pfn(hv_hypercall_pg_saved); > @@ -530,7 +530,7 @@ void __init hyperv_init(void) > if (hv_hypercall_pg == NULL) > goto clean_guest_os_id; > > - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL); > hypercall_msr.enable = 1; > > if (hv_root_partition()) { > @@ -672,7 +672,7 @@ void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die) > return; > panic_reported = true; > > - rdmsrq(HV_X64_MSR_GUEST_OS_ID, guest_id); > + guest_id = rdmsrq(HV_X64_MSR_GUEST_OS_ID); > > wrmsrq(HV_X64_MSR_CRASH_P0, err); > wrmsrq(HV_X64_MSR_CRASH_P1, guest_id); > @@ -706,7 +706,7 @@ bool hv_is_hyperv_initialized(void) > * that the hypercall page is setup > */ > hypercall_msr.as_uint64 = 0; > - rdmsrq(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); > + hypercall_msr.as_uint64 = rdmsrq(HV_X64_MSR_HYPERCALL); > > return hypercall_msr.enable; > } > diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c > index 6b4bdea18218..7ef2d794e2e8 100644 > --- a/arch/x86/hyperv/hv_spinlock.c > +++ b/arch/x86/hyperv/hv_spinlock.c > @@ -50,7 +50,7 @@ static void hv_qlock_wait(u8 *byte, u8 val) > if (READ_ONCE(*byte) == val) { > unsigned long msr_val; > > - rdmsrq(HV_X64_MSR_GUEST_IDLE, msr_val); > + msr_val = rdmsrq(HV_X64_MSR_GUEST_IDLE); > > (void)msr_val; > } > diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h > index 9cd493d467d4..e028140fac49 100644 > --- a/arch/x86/include/asm/apic.h > +++ b/arch/x86/include/asm/apic.h > @@ -220,7 +220,7 @@ static inline u32 native_apic_msr_read(u32 reg) > if (reg == APIC_DFR) > return -1; > > - rdmsrq(APIC_BASE_MSR + (reg >> 4), msr); > + msr = rdmsrq(APIC_BASE_MSR + (reg >> 4)); > return (u32)msr; > } > > @@ -233,7 +233,7 @@ static inline u64 native_x2apic_icr_read(void) > { > unsigned long val; > > - rdmsrq(APIC_BASE_MSR + (APIC_ICR >> 4), val); > + val = rdmsrq(APIC_BASE_MSR + (APIC_ICR >> 4)); > return val; > } > > diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debugreg.h > index 854d82b88ff4..60a3df32a4d3 100644 > --- a/arch/x86/include/asm/debugreg.h > +++ b/arch/x86/include/asm/debugreg.h > @@ -180,7 +180,7 @@ static inline unsigned long get_debugctlmsr(void) > if (boot_cpu_data.x86 < 6) > return 0; > #endif > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctlmsr); > + debugctlmsr = rdmsrq(MSR_IA32_DEBUGCTLMSR); > > return debugctlmsr; > } > diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h > index 70ff4ef457b1..9de49d732e9e 100644 > --- a/arch/x86/include/asm/fsgsbase.h > +++ b/arch/x86/include/asm/fsgsbase.h > @@ -60,7 +60,7 @@ static inline unsigned long x86_fsbase_read_cpu(void) > if (boot_cpu_has(X86_FEATURE_FSGSBASE)) > fsbase = rdfsbase(); > else > - rdmsrq(MSR_FS_BASE, fsbase); > + fsbase = rdmsrq(MSR_FS_BASE); > > return fsbase; > } > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > index 683bb8bf43a9..b7887dccb829 100644 > --- a/arch/x86/include/asm/kvm_host.h > +++ b/arch/x86/include/asm/kvm_host.h > @@ -1862,7 +1862,7 @@ static inline unsigned long read_msr(unsigned long msr) > { > u64 value; > > - rdmsrq(msr, value); > + value = rdmsrq(msr); > return value; > } > #endif > diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h > index 6d7bab33af71..95761803c2e6 100644 > --- a/arch/x86/include/asm/msr.h > +++ b/arch/x86/include/asm/msr.h > @@ -173,14 +173,13 @@ static inline u64 native_read_pmc(int counter) > #include > #else > #include > -/* > - * Access to machine-specific registers (available on 586 and better only) > - * Note: the rd* operations modify the parameters directly (without using > - * pointer indirection), this allows gcc to optimize better > - */ > > -#define rdmsrq(msr, val) \ > - ((val) = native_read_msr((msr))) > +/* Access to machine-specific registers (available on 586 and better only) */ > + > +static __always_inline u64 rdmsrq(u32 msr) > +{ > + return native_read_msr(msr); > +} > > static inline void wrmsrq(u32 msr, u64 val) > { > @@ -237,7 +236,7 @@ int wrmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8]); > #else /* CONFIG_SMP */ > static inline int rdmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 *q) > { > - rdmsrq(msr_no, *q); > + *q = rdmsrq(msr_no); > return 0; > } > static inline int wrmsrq_on_cpu(unsigned int cpu, u32 msr_no, u64 q) > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h > index 93754aa60d5e..19442bc3af37 100644 > --- a/arch/x86/include/asm/paravirt.h > +++ b/arch/x86/include/asm/paravirt.h > @@ -150,10 +150,10 @@ static inline int paravirt_write_msr_safe(u32 msr, u64 val) > return PVOP_CALL2(int, pv_ops, cpu.write_msr_safe, msr, val); > } > > -#define rdmsrq(msr, val) \ > -do { \ > - val = paravirt_read_msr(msr); \ > -} while (0) > +static __always_inline u64 rdmsrq(u32 msr) > +{ > + return paravirt_read_msr(msr); > +} > > static inline void wrmsrq(u32 msr, u64 val) > { > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c > index 90025451ace2..7a6c77e6a44e 100644 > --- a/arch/x86/kernel/apic/apic.c > +++ b/arch/x86/kernel/apic/apic.c > @@ -1193,7 +1193,7 @@ void disable_local_APIC(void) > if (enabled_via_apicbase) { > struct msr val; > > - rdmsrq(MSR_IA32_APICBASE, val.q); > + val.q = rdmsrq(MSR_IA32_APICBASE); > val.l &= ~MSR_IA32_APICBASE_ENABLE; > wrmsrq(MSR_IA32_APICBASE, val.q); > } > @@ -1710,7 +1710,7 @@ static bool x2apic_hw_locked(void) > > x86_arch_cap_msr = x86_read_arch_cap_msr(); > if (x86_arch_cap_msr & ARCH_CAP_XAPIC_DISABLE) { > - rdmsrq(MSR_IA32_XAPIC_DISABLE_STATUS, msr); > + msr = rdmsrq(MSR_IA32_XAPIC_DISABLE_STATUS); > return (msr & LEGACY_XAPIC_DISABLED); > } > return false; > @@ -1723,7 +1723,7 @@ static void __x2apic_disable(void) > if (!boot_cpu_has(X86_FEATURE_APIC)) > return; > > - rdmsrq(MSR_IA32_APICBASE, msr); > + msr = rdmsrq(MSR_IA32_APICBASE); > if (!(msr & X2APIC_ENABLE)) > return; > /* Disable xapic and x2apic first and then reenable xapic mode */ > @@ -1736,7 +1736,7 @@ static void __x2apic_enable(void) > { > u64 msr; > > - rdmsrq(MSR_IA32_APICBASE, msr); > + msr = rdmsrq(MSR_IA32_APICBASE); > if (msr & X2APIC_ENABLE) > return; > wrmsrq(MSR_IA32_APICBASE, msr | X2APIC_ENABLE); > @@ -1976,7 +1976,7 @@ static bool __init apic_verify(unsigned long addr) > > /* The BIOS may have set up the APIC at some other address */ > if (boot_cpu_data.x86 >= 6) { > - rdmsrq(MSR_IA32_APICBASE, val.q); > + val.q = rdmsrq(MSR_IA32_APICBASE); > if (val.l & MSR_IA32_APICBASE_ENABLE) > addr = val.l & MSR_IA32_APICBASE_BASE; > } > @@ -1999,7 +1999,7 @@ bool __init apic_force_enable(unsigned long addr) > * and AMD K7 (Model > 1) or later. > */ > if (boot_cpu_data.x86 >= 6) { > - rdmsrq(MSR_IA32_APICBASE, val.q); > + val.q = rdmsrq(MSR_IA32_APICBASE); > if (!(val.l & MSR_IA32_APICBASE_ENABLE)) { > pr_info("Local APIC disabled by BIOS -- reenabling.\n"); > val.l &= ~MSR_IA32_APICBASE_BASE; > @@ -2476,7 +2476,7 @@ static void lapic_resume(void *data) > * SMP! We'll need to do this as part of the CPU restore! > */ > if (boot_cpu_data.x86 >= 6) { > - rdmsrq(MSR_IA32_APICBASE, val.q); > + val.q = rdmsrq(MSR_IA32_APICBASE); > val.l &= ~MSR_IA32_APICBASE_BASE; > val.l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr; > wrmsrq(MSR_IA32_APICBASE, val.q); > diff --git a/arch/x86/kernel/apic/apic_numachip.c b/arch/x86/kernel/apic/apic_numachip.c > index a60c8960bbfd..3af93e3f2179 100644 > --- a/arch/x86/kernel/apic/apic_numachip.c > +++ b/arch/x86/kernel/apic/apic_numachip.c > @@ -32,7 +32,7 @@ static u32 numachip1_get_apic_id(u32 x) > unsigned int id = (x >> 24) & 0xff; > > if (cpu_feature_enabled(X86_FEATURE_NODEID_MSR)) { > - rdmsrq(MSR_FAM10H_NODE_ID, value); > + value = rdmsrq(MSR_FAM10H_NODE_ID); > id |= (value << 2) & 0xff00; > } > > @@ -43,7 +43,7 @@ static u32 numachip2_get_apic_id(u32 x) > { > u64 mcfg; > > - rdmsrq(MSR_FAM10H_MMIO_CONF_BASE, mcfg); > + mcfg = rdmsrq(MSR_FAM10H_MMIO_CONF_BASE); > return ((mcfg >> (28 - 8)) & 0xfff00) | (x >> 24); > } > > @@ -151,7 +151,7 @@ static void fixup_cpu_id(struct cpuinfo_x86 *c, int node) > > /* Account for nodes per socket in multi-core-module processors */ > if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) { > - rdmsrq(MSR_FAM10H_NODE_ID, val); > + val = rdmsrq(MSR_FAM10H_NODE_ID); > nodes = ((val >> 3) & 7) + 1; > } > > diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c > index 99444409c026..3efceee443b7 100644 > --- a/arch/x86/kernel/cet.c > +++ b/arch/x86/kernel/cet.c > @@ -56,7 +56,7 @@ static void do_user_cp_fault(struct pt_regs *regs, unsigned long error_code) > * will be whatever is live in userspace. So read the SSP before enabling > * interrupts so locking the fpregs to do it later is not required. > */ > - rdmsrq(MSR_IA32_PL3_SSP, ssp); > + ssp = rdmsrq(MSR_IA32_PL3_SSP); > > cond_local_irq_enable(regs); > > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > index 54e14ed276b5..4bd43e899c64 100644 > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -160,7 +160,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c) > if (mbytes > 508) > mbytes = 508; > > - rdmsrq(MSR_K6_WHCR, val.q); > + val.q = rdmsrq(MSR_K6_WHCR); > if ((val.l & 0x0000FFFF) == 0) { > unsigned long flags; > val.l = (1 << 0) | ((mbytes / 4) << 1); > @@ -181,7 +181,7 @@ static void init_amd_k6(struct cpuinfo_x86 *c) > if (mbytes > 4092) > mbytes = 4092; > > - rdmsrq(MSR_K6_WHCR, val.q); > + val.q = rdmsrq(MSR_K6_WHCR); > if ((val.l & 0xFFFF0000) == 0) { > unsigned long flags; > val.l = ((mbytes >> 2) << 22) | (1 << 16); > @@ -228,7 +228,7 @@ static void init_amd_k7(struct cpuinfo_x86 *c) > * As per AMD technical note 27212 0.2 > */ > if ((c->x86_model == 8 && c->x86_stepping >= 1) || (c->x86_model > 8)) { > - rdmsrq(MSR_K7_CLK_CTL, val.q); > + val.q = rdmsrq(MSR_K7_CLK_CTL); > if ((val.l & 0xfff00000) != 0x20000000) { > pr_info("CPU: CLK_CTL MSR was %x. Reprogramming to %x\n", > val.l, ((val.l & 0x000fffff) | 0x20000000)); > @@ -429,7 +429,7 @@ static void bsp_init_amd(struct cpuinfo_x86 *c) > (c->x86 == 0x10 && c->x86_model >= 0x2)) { > u64 val; > > - rdmsrq(MSR_K7_HWCR, val); > + val = rdmsrq(MSR_K7_HWCR); > if (!(val & BIT(24))) > pr_warn(FW_BUG "TSC doesn't count with P0 frequency!\n"); > } > @@ -583,7 +583,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) > */ > if (cpu_has(c, X86_FEATURE_SME) || cpu_has(c, X86_FEATURE_SEV)) { > /* Check if memory encryption is enabled */ > - rdmsrq(MSR_AMD64_SYSCFG, msr); > + msr = rdmsrq(MSR_AMD64_SYSCFG); > if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT)) > goto clear_all; > > @@ -600,7 +600,7 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c) > if (!sme_me_mask) > setup_clear_cpu_cap(X86_FEATURE_SME); > > - rdmsrq(MSR_K7_HWCR, msr); > + msr = rdmsrq(MSR_K7_HWCR); > if (!(msr & MSR_K7_HWCR_SMMLOCK)) > goto clear_sev; > > @@ -1111,7 +1111,7 @@ static void init_amd(struct cpuinfo_x86 *c) > init_amd_cacheinfo(c); > > if (cpu_has(c, X86_FEATURE_SVM)) { > - rdmsrq(MSR_VM_CR, vm_cr); > + vm_cr = rdmsrq(MSR_VM_CR); > if (vm_cr & SVM_VM_CR_SVM_DIS_MASK) { > pr_notice_once("SVM disabled (by BIOS) in MSR_VM_CR\n"); > clear_cpu_cap(c, X86_FEATURE_SVM); > diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c > index 7ffc78d5ebf2..492dc9a11d6b 100644 > --- a/arch/x86/kernel/cpu/aperfmperf.c > +++ b/arch/x86/kernel/cpu/aperfmperf.c > @@ -41,8 +41,8 @@ static void init_counter_refs(void *data) > { > u64 aperf, mperf; > > - rdmsrq(MSR_IA32_APERF, aperf); > - rdmsrq(MSR_IA32_MPERF, mperf); > + aperf = rdmsrq(MSR_IA32_APERF); > + mperf = rdmsrq(MSR_IA32_MPERF); > > this_cpu_write(cpu_samples.aperf, aperf); > this_cpu_write(cpu_samples.mperf, mperf); > @@ -479,8 +479,8 @@ void arch_scale_freq_tick(void) > if (!cpu_feature_enabled(X86_FEATURE_APERFMPERF)) > return; > > - rdmsrq(MSR_IA32_APERF, aperf); > - rdmsrq(MSR_IA32_MPERF, mperf); > + aperf = rdmsrq(MSR_IA32_APERF); > + mperf = rdmsrq(MSR_IA32_MPERF); > acnt = aperf - s->aperf; > mcnt = mperf - s->mperf; > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > index 56eac5611c31..aeb4770ba73c 100644 > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -761,7 +761,7 @@ void update_srbds_msr(void) > if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) > return; > > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); > + mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); > > switch (srbds_mitigation) { > case SRBDS_MITIGATION_OFF: > @@ -897,7 +897,7 @@ void update_gds_msr(void) > > switch (gds_mitigation) { > case GDS_MITIGATION_OFF: > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); > + mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); > mcu_ctrl |= GDS_MITG_DIS; > break; > case GDS_MITIGATION_FULL_LOCKED: > @@ -907,7 +907,7 @@ void update_gds_msr(void) > * CPUs. > */ > case GDS_MITIGATION_FULL: > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); > + mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); > mcu_ctrl &= ~GDS_MITG_DIS; > break; > case GDS_MITIGATION_FORCE: > @@ -924,7 +924,7 @@ void update_gds_msr(void) > * GDS_MITG_DIS will be ignored if this processor is locked but the boot > * processor was not. > */ > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl_after); > + mcu_ctrl_after = rdmsrq(MSR_IA32_MCU_OPT_CTRL); > WARN_ON_ONCE(mcu_ctrl != mcu_ctrl_after); > } > > @@ -959,7 +959,7 @@ static void __init gds_select_mitigation(void) > if (gds_mitigation == GDS_MITIGATION_FORCE) > gds_mitigation = GDS_MITIGATION_FULL; > > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl); > + mcu_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); > if (mcu_ctrl & GDS_MITG_LOCKED) { > if (gds_mitigation == GDS_MITIGATION_OFF) > pr_warn("Mitigation locked. Disable failed.\n"); > @@ -3274,7 +3274,7 @@ void __init cpu_select_mitigations(void) > * init code as it is not enumerated and depends on the family. > */ > if (cpu_feature_enabled(X86_FEATURE_MSR_SPEC_CTRL)) { > - rdmsrq(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base); > + x86_spec_ctrl_base = rdmsrq(MSR_IA32_SPEC_CTRL); > > /* > * Previously running kernel (kexec), may have some controls > diff --git a/arch/x86/kernel/cpu/bus_lock.c b/arch/x86/kernel/cpu/bus_lock.c > index 177f964d4d36..cf853af86ae4 100644 > --- a/arch/x86/kernel/cpu/bus_lock.c > +++ b/arch/x86/kernel/cpu/bus_lock.c > @@ -105,7 +105,7 @@ static bool split_lock_verify_msr(bool on) > ctrl &= ~MSR_TEST_CTRL_SPLIT_LOCK_DETECT; > if (wrmsrq_safe(MSR_TEST_CTRL, ctrl)) > return false; > - rdmsrq(MSR_TEST_CTRL, tmp); > + tmp = rdmsrq(MSR_TEST_CTRL); > return ctrl == tmp; > } > > @@ -145,7 +145,7 @@ static void __init __split_lock_setup(void) > return; > } > > - rdmsrq(MSR_TEST_CTRL, msr_test_ctrl_cache); > + msr_test_ctrl_cache = rdmsrq(MSR_TEST_CTRL); > > if (!split_lock_verify_msr(true)) { > pr_info("MSR access failed: Disabled\n"); > @@ -305,7 +305,7 @@ void bus_lock_init(void) > if (!boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT)) > return; > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, val); > + val = rdmsrq(MSR_IA32_DEBUGCTLMSR); > > if ((boot_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT) && > (sld_state == sld_warn || sld_state == sld_fatal)) || > @@ -383,7 +383,7 @@ static void __init split_lock_setup(struct cpuinfo_x86 *c) > * MSR_IA32_CORE_CAPS_SPLIT_LOCK_DETECT is. All CPUs that set > * it have split lock detection. > */ > - rdmsrq(MSR_IA32_CORE_CAPS, ia32_core_caps); > + ia32_core_caps = rdmsrq(MSR_IA32_CORE_CAPS); > if (ia32_core_caps & MSR_IA32_CORE_CAPS_SPLIT_LOCK_DETECT) > goto supported; > > diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c > index 513fa1f640f9..6cd89b5ac9de 100644 > --- a/arch/x86/kernel/cpu/centaur.c > +++ b/arch/x86/kernel/cpu/centaur.c > @@ -30,7 +30,7 @@ static void init_c3(struct cpuinfo_x86 *c) > > /* enable ACE unit, if present and disabled */ > if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) { > - rdmsrq(MSR_VIA_FCR, msr); > + msr = rdmsrq(MSR_VIA_FCR); > /* enable ACE unit */ > wrmsrq(MSR_VIA_FCR, msr | ACE_FCR); > pr_info("CPU: Enabled ACE h/w crypto\n"); > @@ -38,7 +38,7 @@ static void init_c3(struct cpuinfo_x86 *c) > > /* enable RNG unit, if present and disabled */ > if ((tmp & (RNG_PRESENT | RNG_ENABLED)) == RNG_PRESENT) { > - rdmsrq(MSR_VIA_RNG, msr); > + msr = rdmsrq(MSR_VIA_RNG); > /* enable RNG unit */ > wrmsrq(MSR_VIA_RNG, msr | RNG_ENABLE); > pr_info("CPU: Enabled h/w RNG\n"); > @@ -52,7 +52,7 @@ static void init_c3(struct cpuinfo_x86 *c) > #ifdef CONFIG_X86_32 > /* Cyrix III family needs CX8 & PGE explicitly enabled. */ > if (c->x86_model >= 6 && c->x86_model <= 13) { > - rdmsrq(MSR_VIA_FCR, msr); > + msr = rdmsrq(MSR_VIA_FCR); > wrmsrq(MSR_VIA_FCR, msr | (1 << 1 | 1 << 7)); > set_cpu_cap(c, X86_FEATURE_CX8); > } > @@ -169,7 +169,7 @@ static void init_centaur(struct cpuinfo_x86 *c) > name = "??"; > } > > - rdmsrq(MSR_IDT_FCR1, val.q); > + val.q = rdmsrq(MSR_IDT_FCR1); > newlo = (val.l | fcr_set) & (~fcr_clr); > > if (newlo != val.l) { > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index c7352827f491..b2d9f8b14909 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -346,7 +346,7 @@ static void squash_the_stupid_serial_number(struct cpuinfo_x86 *c) > > /* Disable processor serial number: */ > > - rdmsrq(MSR_IA32_BBL_CR_CTL, val.q); > + val.q = rdmsrq(MSR_IA32_BBL_CR_CTL); > val.l |= 0x200000; > wrmsrq(MSR_IA32_BBL_CR_CTL, val.q); > > @@ -610,7 +610,7 @@ __noendbr u64 ibt_save(bool disable) > u64 msr = 0; > > if (cpu_feature_enabled(X86_FEATURE_IBT)) { > - rdmsrq(MSR_IA32_S_CET, msr); > + msr = rdmsrq(MSR_IA32_S_CET); > if (disable) > wrmsrq(MSR_IA32_S_CET, msr & ~CET_ENDBR_EN); > } > @@ -623,7 +623,7 @@ __noendbr void ibt_restore(u64 save) > u64 msr; > > if (cpu_feature_enabled(X86_FEATURE_IBT)) { > - rdmsrq(MSR_IA32_S_CET, msr); > + msr = rdmsrq(MSR_IA32_S_CET); > msr &= ~CET_ENDBR_EN; > msr |= (save & CET_ENDBR_EN); > wrmsrq(MSR_IA32_S_CET, msr); > @@ -1357,7 +1357,7 @@ u64 x86_read_arch_cap_msr(void) > u64 x86_arch_cap_msr = 0; > > if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) > - rdmsrq(MSR_IA32_ARCH_CAPABILITIES, x86_arch_cap_msr); > + x86_arch_cap_msr = rdmsrq(MSR_IA32_ARCH_CAPABILITIES); > > return x86_arch_cap_msr; > } > @@ -1923,10 +1923,10 @@ static bool detect_null_seg_behavior(void) > */ > > unsigned long old_base, tmp; > - rdmsrq(MSR_FS_BASE, old_base); > + old_base = rdmsrq(MSR_FS_BASE); > wrmsrq(MSR_FS_BASE, 1); > loadsegment(fs, 0); > - rdmsrq(MSR_FS_BASE, tmp); > + tmp = rdmsrq(MSR_FS_BASE); > wrmsrq(MSR_FS_BASE, old_base); > return tmp == 0; > } > diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c > index 10a92927a515..7228fc2bb43e 100644 > --- a/arch/x86/kernel/cpu/feat_ctl.c > +++ b/arch/x86/kernel/cpu/feat_ctl.c > @@ -40,7 +40,7 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c) > * as they exist on any CPU that supports VMX, i.e. we want the WARN if > * the RDMSR faults. > */ > - rdmsrq(MSR_IA32_VMX_PROCBASED_CTLS, val.q); > + val.q = rdmsrq(MSR_IA32_VMX_PROCBASED_CTLS); > supported = val.h; > c->vmx_capability[PRIMARY_CTLS] = supported; > > @@ -53,7 +53,7 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c) > c->vmx_capability[TERTIARY_CTLS_LOW] = val.l; > c->vmx_capability[TERTIARY_CTLS_HIGH] = val.h; > > - rdmsrq(MSR_IA32_VMX_PINBASED_CTLS, val.q); > + val.q = rdmsrq(MSR_IA32_VMX_PINBASED_CTLS); > supported = val.h; > rdmsrq_safe(MSR_IA32_VMX_VMFUNC, &val.q); > funcs = val.h; > diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c > index ec51c2b9a257..44b462799cf6 100644 > --- a/arch/x86/kernel/cpu/hygon.c > +++ b/arch/x86/kernel/cpu/hygon.c > @@ -99,7 +99,7 @@ static void bsp_init_hygon(struct cpuinfo_x86 *c) > if (cpu_has(c, X86_FEATURE_CONSTANT_TSC)) { > u64 val; > > - rdmsrq(MSR_K7_HWCR, val); > + val = rdmsrq(MSR_K7_HWCR); > if (!(val & BIT(24))) > pr_warn(FW_BUG "TSC doesn't count with P0 frequency!\n"); > } > @@ -194,7 +194,7 @@ static void init_hygon(struct cpuinfo_x86 *c) > init_hygon_cacheinfo(c); > > if (cpu_has(c, X86_FEATURE_SVM)) { > - rdmsrq(MSR_VM_CR, vm_cr); > + vm_cr = rdmsrq(MSR_VM_CR); > if (vm_cr & SVM_VM_CR_SVM_DIS_MASK) { > pr_notice_once("SVM disabled (by BIOS) in MSR_VM_CR\n"); > clear_cpu_cap(c, X86_FEATURE_SVM); > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > index 4297ceb2cb24..2aabe9affa0c 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -159,7 +159,7 @@ static void detect_tme_early(struct cpuinfo_x86 *c) > u64 tme_activate; > int keyid_bits; > > - rdmsrq(MSR_IA32_TME_ACTIVATE, tme_activate); > + tme_activate = rdmsrq(MSR_IA32_TME_ACTIVATE); > > if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(tme_activate)) { > pr_info_once("x86/tme: not enabled by BIOS\n"); > @@ -335,7 +335,7 @@ static void early_init_intel(struct cpuinfo_x86 *c) > * string flag and enhanced fast string capabilities accordingly. > */ > if (c->x86_vfm >= INTEL_PENTIUM_M_DOTHAN) { > - rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable); > + misc_enable = rdmsrq(MSR_IA32_MISC_ENABLE); > if (misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING) { > /* X86_FEATURE_ERMS is set based on CPUID */ > set_cpu_cap(c, X86_FEATURE_REP_GOOD); > @@ -579,7 +579,7 @@ static void init_intel(struct cpuinfo_x86 *c) > if (boot_cpu_has(X86_FEATURE_DS)) { > u64 l; > > - rdmsrq(MSR_IA32_MISC_ENABLE, l); > + l = rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(l & MSR_IA32_MISC_ENABLE_BTS_UNAVAIL)) > set_cpu_cap(c, X86_FEATURE_BTS); > if (!(l & MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL)) > diff --git a/arch/x86/kernel/cpu/intel_epb.c b/arch/x86/kernel/cpu/intel_epb.c > index 2c56f8730f59..a02d562253d9 100644 > --- a/arch/x86/kernel/cpu/intel_epb.c > +++ b/arch/x86/kernel/cpu/intel_epb.c > @@ -79,7 +79,7 @@ static int intel_epb_save(void *data) > { > u64 epb; > > - rdmsrq(MSR_IA32_ENERGY_PERF_BIAS, epb); > + epb = rdmsrq(MSR_IA32_ENERGY_PERF_BIAS); > /* > * Ensure that saved_epb will always be nonzero after this write even if > * the EPB value read from the MSR is 0. > @@ -94,7 +94,7 @@ static void intel_epb_restore(void *data) > u64 val = this_cpu_read(saved_epb); > u64 epb; > > - rdmsrq(MSR_IA32_ENERGY_PERF_BIAS, epb); > + epb = rdmsrq(MSR_IA32_ENERGY_PERF_BIAS); > if (val) { > val &= EPB_MASK; > } else { > diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c > index 1cc20b855b7e..9695af953299 100644 > --- a/arch/x86/kernel/cpu/mce/amd.c > +++ b/arch/x86/kernel/cpu/mce/amd.c > @@ -438,7 +438,7 @@ static void threshold_restart_block(void *_tr) > if (!this_cpu_read(threshold_banks) && !tr->set_lvt_off) > return; > > - rdmsrq(tr->b->address, val.q); > + val.q = rdmsrq(tr->b->address); > > /* > * Reset error count and overflow bit. > @@ -658,7 +658,7 @@ static void disable_err_thresholding(struct cpuinfo_x86 *c, unsigned int bank) > return; > } > > - rdmsrq(MSR_K7_HWCR, hwcr); > + hwcr = rdmsrq(MSR_K7_HWCR); > > /* McStatusWrEn has to be set */ > need_toggle = !(hwcr & BIT(18)); > diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c > index ab469605fc89..df56ca06275b 100644 > --- a/arch/x86/kernel/cpu/mce/core.c > +++ b/arch/x86/kernel/cpu/mce/core.c > @@ -1845,7 +1845,7 @@ static void __mcheck_cpu_cap_init(void) > u64 cap; > u8 b; > > - rdmsrq(MSR_IA32_MCG_CAP, cap); > + cap = rdmsrq(MSR_IA32_MCG_CAP); > > b = cap & MCG_BANKCNT_MASK; > > @@ -1864,7 +1864,7 @@ static void __mcheck_cpu_init_generic(void) > { > u64 cap; > > - rdmsrq(MSR_IA32_MCG_CAP, cap); > + cap = rdmsrq(MSR_IA32_MCG_CAP); > if (cap & MCG_CTL_P) > wrmsrq(MSR_IA32_MCG_CTL, ~0ULL); > } > @@ -1896,7 +1896,7 @@ static void __mcheck_cpu_init_prepare_banks(void) > wrmsrq(mca_msr_reg(i, MCA_CTL), b->ctl); > wrmsrq(mca_msr_reg(i, MCA_STATUS), 0); > > - rdmsrq(mca_msr_reg(i, MCA_CTL), msrval); > + msrval = rdmsrq(mca_msr_reg(i, MCA_CTL)); > b->init = !!msrval; > } > } > @@ -2214,7 +2214,7 @@ void mca_bsp_init(struct cpuinfo_x86 *c) > if (mce_flags.smca) > smca_bsp_init(); > > - rdmsrq(MSR_IA32_MCG_CAP, cap); > + cap = rdmsrq(MSR_IA32_MCG_CAP); > > /* Use accurate RIP reporting if available. */ > if ((cap & MCG_EXT_P) && MCG_EXT_CNT(cap) >= 9) > diff --git a/arch/x86/kernel/cpu/mce/inject.c b/arch/x86/kernel/cpu/mce/inject.c > index 6f8a49d8baeb..aa933864f32e 100644 > --- a/arch/x86/kernel/cpu/mce/inject.c > +++ b/arch/x86/kernel/cpu/mce/inject.c > @@ -743,7 +743,7 @@ static void check_hw_inj_possible(void) > u64 status = MCI_STATUS_VAL, ipid; > > /* Check whether bank is populated */ > - rdmsrq(MSR_AMD64_SMCA_MCx_IPID(bank), ipid); > + ipid = rdmsrq(MSR_AMD64_SMCA_MCx_IPID(bank)); > if (!ipid) > continue; > > diff --git a/arch/x86/kernel/cpu/mce/intel.c b/arch/x86/kernel/cpu/mce/intel.c > index 4655223ba560..2edb05d5e2d7 100644 > --- a/arch/x86/kernel/cpu/mce/intel.c > +++ b/arch/x86/kernel/cpu/mce/intel.c > @@ -94,7 +94,7 @@ static bool cmci_supported(int *banks) > if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6) > return false; > > - rdmsrq(MSR_IA32_MCG_CAP, cap); > + cap = rdmsrq(MSR_IA32_MCG_CAP); > *banks = min_t(unsigned, MAX_NR_BANKS, cap & MCG_BANKCNT_MASK); > return !!(cap & MCG_CMCI_P); > } > @@ -106,7 +106,7 @@ static bool lmce_supported(void) > if (mca_cfg.lmce_disabled) > return false; > > - rdmsrq(MSR_IA32_MCG_CAP, tmp); > + tmp = rdmsrq(MSR_IA32_MCG_CAP); > > /* > * LMCE depends on recovery support in the processor. Hence both > @@ -123,7 +123,7 @@ static bool lmce_supported(void) > * WARN if the MSR isn't locked as init_ia32_feat_ctl() unconditionally > * locks the MSR in the event that it wasn't already locked by BIOS. > */ > - rdmsrq(MSR_IA32_FEAT_CTL, tmp); > + tmp = rdmsrq(MSR_IA32_FEAT_CTL); > if (WARN_ON_ONCE(!(tmp & FEAT_CTL_LOCKED))) > return false; > > @@ -141,7 +141,7 @@ static void cmci_set_threshold(int bank, int thresh) > u64 val; > > raw_spin_lock_irqsave(&cmci_discover_lock, flags); > - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); > + val = rdmsrq(MSR_IA32_MCx_CTL2(bank)); > val &= ~MCI_CTL2_CMCI_THRESHOLD_MASK; > wrmsrq(MSR_IA32_MCx_CTL2(bank), val | thresh); > raw_spin_unlock_irqrestore(&cmci_discover_lock, flags); > @@ -184,7 +184,7 @@ static bool cmci_skip_bank(int bank, u64 *val) > if (test_bit(bank, mce_banks_ce_disabled)) > return true; > > - rdmsrq(MSR_IA32_MCx_CTL2(bank), *val); > + *val = rdmsrq(MSR_IA32_MCx_CTL2(bank)); > > /* Already owned by someone else? */ > if (*val & MCI_CTL2_CMCI_EN) { > @@ -233,7 +233,7 @@ static void cmci_claim_bank(int bank, u64 val, int bios_zero_thresh, int *bios_w > > val |= MCI_CTL2_CMCI_EN; > wrmsrq(MSR_IA32_MCx_CTL2(bank), val); > - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); > + val = rdmsrq(MSR_IA32_MCx_CTL2(bank)); > > /* If the enable bit did not stick, this bank should be polled. */ > if (!(val & MCI_CTL2_CMCI_EN)) { > @@ -324,7 +324,7 @@ static void __cmci_disable_bank(int bank) > > if (!test_bit(bank, this_cpu_ptr(mce_banks_owned))) > return; > - rdmsrq(MSR_IA32_MCx_CTL2(bank), val); > + val = rdmsrq(MSR_IA32_MCx_CTL2(bank)); > val &= ~MCI_CTL2_CMCI_EN; > wrmsrq(MSR_IA32_MCx_CTL2(bank), val); > __clear_bit(bank, this_cpu_ptr(mce_banks_owned)); > @@ -430,7 +430,7 @@ void intel_init_lmce(void) > if (!lmce_supported()) > return; > > - rdmsrq(MSR_IA32_MCG_EXT_CTL, val); > + val = rdmsrq(MSR_IA32_MCG_EXT_CTL); > > if (!(val & MCG_EXT_CTL_LMCE_EN)) > wrmsrq(MSR_IA32_MCG_EXT_CTL, val | MCG_EXT_CTL_LMCE_EN); > @@ -443,7 +443,7 @@ void intel_clear_lmce(void) > if (!lmce_supported()) > return; > > - rdmsrq(MSR_IA32_MCG_EXT_CTL, val); > + val = rdmsrq(MSR_IA32_MCG_EXT_CTL); > val &= ~MCG_EXT_CTL_LMCE_EN; > wrmsrq(MSR_IA32_MCG_EXT_CTL, val); > } > diff --git a/arch/x86/kernel/cpu/mce/p5.c b/arch/x86/kernel/cpu/mce/p5.c > index 3c2b6cc918b1..b441c720f9b7 100644 > --- a/arch/x86/kernel/cpu/mce/p5.c > +++ b/arch/x86/kernel/cpu/mce/p5.c > @@ -26,8 +26,8 @@ noinstr void pentium_machine_check(struct pt_regs *regs) > u64 addr, type; > > instrumentation_begin(); > - rdmsrq(MSR_IA32_P5_MC_ADDR, addr); > - rdmsrq(MSR_IA32_P5_MC_TYPE, type); > + addr = rdmsrq(MSR_IA32_P5_MC_ADDR); > + type = rdmsrq(MSR_IA32_P5_MC_TYPE); > > pr_emerg("CPU#%d: Machine Check Exception: 0x%8X (type 0x%8X).\n", > smp_processor_id(), (u32)addr, (u32)type); > @@ -55,8 +55,8 @@ void intel_p5_mcheck_init(struct cpuinfo_x86 *c) > return; > > /* Read registers before enabling: */ > - rdmsrq(MSR_IA32_P5_MC_ADDR, q); > - rdmsrq(MSR_IA32_P5_MC_TYPE, q); > + q = rdmsrq(MSR_IA32_P5_MC_ADDR); > + q = rdmsrq(MSR_IA32_P5_MC_TYPE); > pr_info("Intel old style machine check architecture supported.\n"); > > /* Enable MCE: */ > diff --git a/arch/x86/kernel/cpu/mce/winchip.c b/arch/x86/kernel/cpu/mce/winchip.c > index 7040243533d9..7b967f2abd8f 100644 > --- a/arch/x86/kernel/cpu/mce/winchip.c > +++ b/arch/x86/kernel/cpu/mce/winchip.c > @@ -30,7 +30,7 @@ void winchip_mcheck_init(struct cpuinfo_x86 *c) > { > struct msr val; > > - rdmsrq(MSR_IDT_FCR1, val.q); > + val.q = rdmsrq(MSR_IDT_FCR1); > val.l |= (1<<2); /* Enable EIERRINT (int 18 MCE) */ > val.l &= ~(1<<4); /* Enable MCE */ > wrmsrq(MSR_IDT_FCR1, val.q); > diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c > index 1142183c950c..4d199abd8fd8 100644 > --- a/arch/x86/kernel/cpu/microcode/intel.c > +++ b/arch/x86/kernel/cpu/microcode/intel.c > @@ -991,7 +991,7 @@ static __init bool staging_available(void) > if (!(val & ARCH_CAP_MCU_ENUM)) > return false; > > - rdmsrq(MSR_IA32_MCU_ENUMERATION, val); > + val = rdmsrq(MSR_IA32_MCU_ENUMERATION); > return !!(val & MCU_STAGING); > } > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > index b4af7c0a70ac..e1388ed27384 100644 > --- a/arch/x86/kernel/cpu/mshyperv.c > +++ b/arch/x86/kernel/cpu/mshyperv.c > @@ -74,7 +74,7 @@ u64 hv_get_non_nested_msr(unsigned int reg) > if (hv_is_synic_msr(reg) && ms_hyperv.paravisor_present) > hv_ivm_msr_read(reg, &value); > else > - rdmsrq(reg, value); > + value = rdmsrq(reg); > return value; > } > EXPORT_SYMBOL_GPL(hv_get_non_nested_msr); > @@ -399,7 +399,7 @@ static unsigned long hv_get_tsc_khz(void) > { > unsigned long freq; > > - rdmsrq(HV_X64_MSR_TSC_FREQUENCY, freq); > + freq = rdmsrq(HV_X64_MSR_TSC_FREQUENCY); > > return freq / 1000; > } > @@ -660,7 +660,7 @@ static void __init ms_hyperv_init_platform(void) > */ > u64 hv_lapic_frequency; > > - rdmsrq(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency); > + hv_lapic_frequency = rdmsrq(HV_X64_MSR_APIC_FREQUENCY); > hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ); > lapic_timer_period = hv_lapic_frequency; > pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n", > diff --git a/arch/x86/kernel/cpu/mtrr/amd.c b/arch/x86/kernel/cpu/mtrr/amd.c > index a73715d6f05c..652e4d64ff4a 100644 > --- a/arch/x86/kernel/cpu/mtrr/amd.c > +++ b/arch/x86/kernel/cpu/mtrr/amd.c > @@ -13,7 +13,7 @@ amd_get_mtrr(unsigned int reg, unsigned long *base, > unsigned long val; > struct msr msr; > > - rdmsrq(MSR_K6_UWCCR, msr.q); > + msr.q = rdmsrq(MSR_K6_UWCCR); > /* Upper dword is region 1, lower is region 0 */ > if (reg == 1) > val = msr.h; > @@ -68,7 +68,7 @@ amd_set_mtrr(unsigned int reg, unsigned long base, unsigned long size, mtrr_type > /* > * Low is MTRR0, High MTRR 1 > */ > - rdmsrq(MSR_K6_UWCCR, msr.q); > + msr.q = rdmsrq(MSR_K6_UWCCR); > regs[0] = msr.l; > regs[1] = msr.h; > > diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c > index cd1a6dec4064..2b72c784db9e 100644 > --- a/arch/x86/kernel/cpu/mtrr/cleanup.c > +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c > @@ -670,7 +670,7 @@ int __init mtrr_cleanup(void) > if (!cpu_feature_enabled(X86_FEATURE_MTRR) || enable_mtrr_cleanup < 1) > return 0; > > - rdmsrq(MSR_MTRRdefType, def); > + def = rdmsrq(MSR_MTRRdefType); > def &= 0xff; > if (def != MTRR_TYPE_UNCACHABLE) > return 0; > @@ -870,7 +870,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn) > if (!cpu_feature_enabled(X86_FEATURE_MTRR) || disable_mtrr_trim) > return 0; > > - rdmsrq(MSR_MTRRdefType, def); > + def = rdmsrq(MSR_MTRRdefType); > def &= MTRR_DEF_TYPE_TYPE; > if (def != MTRR_TYPE_UNCACHABLE) > return 0; > diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c > index 67cf69f24b00..4d8034a7fdc8 100644 > --- a/arch/x86/kernel/cpu/mtrr/generic.c > +++ b/arch/x86/kernel/cpu/mtrr/generic.c > @@ -112,7 +112,7 @@ static inline void k8_check_syscfg_dram_mod_en(void) > if (cc_platform_has(CC_ATTR_HOST_SEV_SNP)) > return; > > - rdmsrq(MSR_AMD64_SYSCFG, val.q); > + val.q = rdmsrq(MSR_AMD64_SYSCFG); > if (val.l & K8_MTRRFIXRANGE_DRAM_MODIFY) { > pr_err(FW_WARN "MTRR: CPU %u: SYSCFG[MtrrFixDramModEn]" > " not cleared by BIOS, clearing this bit\n", > @@ -559,10 +559,10 @@ get_mtrr_var_range(unsigned int index, struct mtrr_var_range *vr) > { > struct msr val; > > - rdmsrq(MTRRphysBase_MSR(index), val.q); > + val.q = rdmsrq(MTRRphysBase_MSR(index)); > vr->base_lo = val.l; > vr->base_hi = val.h; > - rdmsrq(MTRRphysMask_MSR(index), val.q); > + val.q = rdmsrq(MTRRphysMask_MSR(index)); > vr->mask_lo = val.l; > vr->mask_hi = val.h; > } > @@ -588,12 +588,12 @@ static void get_fixed_ranges(mtrr_type *frs) > > k8_check_syscfg_dram_mod_en(); > > - rdmsrq(MSR_MTRRfix64K_00000, p[0]); > + p[0] = rdmsrq(MSR_MTRRfix64K_00000); > > for (i = 0; i < 2; i++) > - rdmsrq(MSR_MTRRfix16K_80000 + i, p[1 + i]); > + p[1 + i] = rdmsrq(MSR_MTRRfix16K_80000 + i); > for (i = 0; i < 8; i++) > - rdmsrq(MSR_MTRRfix4K_C0000 + i, p[3 + i]); > + p[3 + i] = rdmsrq(MSR_MTRRfix4K_C0000 + i); > } > > void mtrr_save_fixed_ranges(void *info) > @@ -700,7 +700,7 @@ bool __init get_mtrr_state(void) > > vrs = mtrr_state.var_ranges; > > - rdmsrq(MSR_MTRRcap, q); > + q = rdmsrq(MSR_MTRRcap); > mtrr_state.have_fixed = q & MTRR_CAP_FIX; > > for (i = 0; i < num_var_ranges; i++) > @@ -708,13 +708,13 @@ bool __init get_mtrr_state(void) > if (mtrr_state.have_fixed) > get_fixed_ranges(mtrr_state.fixed_ranges); > > - rdmsrq(MSR_MTRRdefType, q); > + q = rdmsrq(MSR_MTRRdefType); > mtrr_state.def_type = q & MTRR_DEF_TYPE_TYPE; > mtrr_state.enabled = (q & MTRR_DEF_TYPE_ENABLE) >> MTRR_STATE_SHIFT; > > if (amd_special_default_mtrr()) { > /* TOP_MEM2 */ > - rdmsrq(MSR_K8_TOP_MEM2, mtrr_tom2); > + mtrr_tom2 = rdmsrq(MSR_K8_TOP_MEM2); > mtrr_tom2 &= 0xffffff800000ULL; > } > > @@ -770,7 +770,7 @@ static void set_fixed_range(int msr, bool *changed, unsigned int *msrwords) > { > struct msr val; > > - rdmsrq(msr, val.q); > + val.q = rdmsrq(msr); > > if (val.l != msrwords[0] || val.h != msrwords[1]) { > mtrr_wrmsr(msr, msrwords[0], msrwords[1]); > @@ -818,7 +818,7 @@ static void generic_get_mtrr(unsigned int reg, unsigned long *base, > */ > get_cpu(); > > - rdmsrq(MTRRphysMask_MSR(reg), mask); > + mask = rdmsrq(MTRRphysMask_MSR(reg)); > > if (!(mask & MTRR_PHYSMASK_V)) { > /* Invalid (i.e. free) range */ > @@ -828,7 +828,7 @@ static void generic_get_mtrr(unsigned int reg, unsigned long *base, > goto out_put_cpu; > } > > - rdmsrq(MTRRphysBase_MSR(reg), base_msr); > + base_msr = rdmsrq(MTRRphysBase_MSR(reg)); > > /* Work out the shifted address mask: */ > tmp = mask & PAGE_MASK; > @@ -889,7 +889,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr) > bool changed = false; > struct msr val; > > - rdmsrq(MTRRphysBase_MSR(index), val.q); > + val.q = rdmsrq(MTRRphysBase_MSR(index)); > if ((vr->base_lo & ~MTRR_PHYSBASE_RSVD) != (val.l & ~MTRR_PHYSBASE_RSVD) > || (vr->base_hi & ~phys_hi_rsvd) != (val.h & ~phys_hi_rsvd)) { > > @@ -897,7 +897,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr) > changed = true; > } > > - rdmsrq(MTRRphysMask_MSR(index), val.q); > + val.q = rdmsrq(MTRRphysMask_MSR(index)); > > if ((vr->mask_lo & ~MTRR_PHYSMASK_RSVD) != (val.l & ~MTRR_PHYSMASK_RSVD) > || (vr->mask_hi & ~phys_hi_rsvd) != (val.h & ~phys_hi_rsvd)) { > @@ -952,7 +952,7 @@ void mtrr_disable(void) > struct msr val; > > /* Save MTRR state */ > - rdmsrq(MSR_MTRRdefType, val.q); > + val.q = rdmsrq(MSR_MTRRdefType); > deftype_lo = val.l; > deftype_hi = val.h; > > @@ -1065,7 +1065,7 @@ static int generic_have_wrcomb(void) > { > u64 config; > > - rdmsrq(MSR_MTRRcap, config); > + config = rdmsrq(MSR_MTRRcap); > return config & MTRR_CAP_WC; > } > > diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c > index 468c53b20acf..9b7abd58b677 100644 > --- a/arch/x86/kernel/cpu/mtrr/mtrr.c > +++ b/arch/x86/kernel/cpu/mtrr/mtrr.c > @@ -571,7 +571,7 @@ void __init mtrr_bp_init(void) > if (mtrr_enabled()) { > /* Get the number of variable MTRR ranges. */ > if (mtrr_if == &generic_mtrr_ops) > - rdmsrq(MSR_MTRRcap, config); > + config = rdmsrq(MSR_MTRRcap); > else > config = mtrr_if->var_regs; > num_var_ranges = config & MTRR_CAP_VCNT; > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c > index 55214d6fdc49..dd0e20179fce 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -165,7 +165,7 @@ static inline void cache_alloc_hsw_probe(void) > if (wrmsrq_safe(MSR_IA32_L3_CBM_BASE, max_cbm)) > return; > > - rdmsrq(MSR_IA32_L3_CBM_BASE, l3_cbm_0); > + l3_cbm_0 = rdmsrq(MSR_IA32_L3_CBM_BASE); > > /* If all the bits were set in MSR, return success */ > if (l3_cbm_0 != max_cbm) > diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c > index 3838e0a13d36..530c425d7ee4 100644 > --- a/arch/x86/kernel/cpu/resctrl/monitor.c > +++ b/arch/x86/kernel/cpu/resctrl/monitor.c > @@ -147,7 +147,7 @@ static int __rmid_read_phys(u32 prmid, enum resctrl_event_id eventid, u64 *val) > * are error bits. > */ > wrmsrq(MSR_IA32_QM_EVTSEL, msr_val.q); > - rdmsrq(MSR_IA32_QM_CTR, msr_val.q); > + msr_val.q = rdmsrq(MSR_IA32_QM_CTR); > > if (msr_val.q & RMID_VAL_ERROR) > return -EIO; > @@ -310,7 +310,7 @@ static int __cntr_id_read(u32 cntr_id, u64 *val) > * is set if the counter data is unavailable. > */ > wrmsrq(MSR_IA32_QM_EVTSEL, msr_val.q); > - rdmsrq(MSR_IA32_QM_CTR, msr_val.q); > + msr_val.q = rdmsrq(MSR_IA32_QM_CTR); > > if (msr_val.q & RMID_VAL_ERROR) > return -EIO; > diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c > index d7caab0409b6..0408ac7f66fd 100644 > --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c > +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c > @@ -250,7 +250,7 @@ int resctrl_arch_measure_cycles_lat_fn(void *_plr) > /* > * Disable hardware prefetchers. > */ > - rdmsrq(MSR_MISC_FEATURE_CONTROL, saved); > + saved = rdmsrq(MSR_MISC_FEATURE_CONTROL); > wrmsrq(MSR_MISC_FEATURE_CONTROL, prefetch_disable_bits); > mem_r = READ_ONCE(plr->kmem); > /* > @@ -346,7 +346,7 @@ static int measure_residency_fn(struct perf_event_attr *miss_attr, > /* > * Disable hardware prefetchers. > */ > - rdmsrq(MSR_MISC_FEATURE_CONTROL, saved); > + saved = rdmsrq(MSR_MISC_FEATURE_CONTROL); > wrmsrq(MSR_MISC_FEATURE_CONTROL, prefetch_disable_bits); > > /* Initialize rest of local variables */ > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > index 5ffa39fa86fa..37f0b1f7fe4f 100644 > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > @@ -96,7 +96,7 @@ void resctrl_arch_mon_event_config_read(void *_config_info) > pr_warn_once("Invalid event id %d\n", config_info->evtid); > return; > } > - rdmsrq(MSR_IA32_EVT_CFG_BASE + index, msrval); > + msrval = rdmsrq(MSR_IA32_EVT_CFG_BASE + index); > > /* Report only the valid event configuration bits */ > config_info->mon_config = msrval & MAX_EVT_CONFIG_BITS; > diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c > index 4913b64ec592..68337da5aa09 100644 > --- a/arch/x86/kernel/cpu/topology.c > +++ b/arch/x86/kernel/cpu/topology.c > @@ -151,7 +151,7 @@ static __init bool check_for_real_bsp(u32 apic_id) > * kernel must rely on the firmware enumeration order. > */ > if (has_apic_base) { > - rdmsrq(MSR_IA32_APICBASE, msr); > + msr = rdmsrq(MSR_IA32_APICBASE); > is_bsp = !!(msr & MSR_IA32_APICBASE_BSP); > } > > diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c > index c5a6944df86a..5192f13f3686 100644 > --- a/arch/x86/kernel/cpu/topology_amd.c > +++ b/arch/x86/kernel/cpu/topology_amd.c > @@ -140,7 +140,7 @@ static void parse_fam10h_node_id(struct topo_scan *tscan) > if (!boot_cpu_has(X86_FEATURE_NODEID_MSR)) > return; > > - rdmsrq(MSR_FAM10H_NODE_ID, nid.msr); > + nid.msr = rdmsrq(MSR_FAM10H_NODE_ID); > store_node(tscan, nid.nodes_per_pkg + 1, nid.node_id); > tscan->c->topo.llc_id = nid.node_id; > } > @@ -168,7 +168,7 @@ static void topoext_fixup(struct topo_scan *tscan) > MSR_AMD64_CPUID_EXT_FEAT_TOPOEXT_BIT) <= 0) > return; > > - rdmsrq(MSR_AMD64_CPUID_EXT_FEAT, msrval); > + msrval = rdmsrq(MSR_AMD64_CPUID_EXT_FEAT); > if (msrval & MSR_AMD64_CPUID_EXT_FEAT_TOPOEXT) { > set_cpu_cap(c, X86_FEATURE_TOPOEXT); > pr_info_once(FW_INFO "CPU: Re-enabling disabled Topology Extensions Support.\n"); > diff --git a/arch/x86/kernel/cpu/transmeta.c b/arch/x86/kernel/cpu/transmeta.c > index 35d498f24e34..f8632becda18 100644 > --- a/arch/x86/kernel/cpu/transmeta.c > +++ b/arch/x86/kernel/cpu/transmeta.c > @@ -87,7 +87,7 @@ static void init_transmeta(struct cpuinfo_x86 *c) > } > > /* Unhide possibly hidden capability flags */ > - rdmsrq(0x80860004, msr); > + msr = rdmsrq(0x80860004); > wrmsrq(0x80860004, msr | ~0U); > cpuid_refresh_leaf(c, 0x1); > c->x86_capability[CPUID_1_EDX] = cpuid_edx(0x00000001); > diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c > index 209b5a22d880..b500845d2049 100644 > --- a/arch/x86/kernel/cpu/tsx.c > +++ b/arch/x86/kernel/cpu/tsx.c > @@ -35,7 +35,7 @@ static void tsx_disable(void) > { > u64 tsx; > > - rdmsrq(MSR_IA32_TSX_CTRL, tsx); > + tsx = rdmsrq(MSR_IA32_TSX_CTRL); > > /* Force all transactions to immediately abort */ > tsx |= TSX_CTRL_RTM_DISABLE; > @@ -55,7 +55,7 @@ static void tsx_enable(void) > { > u64 tsx; > > - rdmsrq(MSR_IA32_TSX_CTRL, tsx); > + tsx = rdmsrq(MSR_IA32_TSX_CTRL); > > /* Enable the RTM feature in the cpu */ > tsx &= ~TSX_CTRL_RTM_DISABLE; > @@ -126,11 +126,11 @@ static void tsx_clear_cpuid(void) > */ > if (boot_cpu_has(X86_FEATURE_RTM_ALWAYS_ABORT) && > boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)) { > - rdmsrq(MSR_TSX_FORCE_ABORT, msr); > + msr = rdmsrq(MSR_TSX_FORCE_ABORT); > msr |= MSR_TFA_TSX_CPUID_CLEAR; > wrmsrq(MSR_TSX_FORCE_ABORT, msr); > } else if (cpu_feature_enabled(X86_FEATURE_MSR_TSX_CTRL)) { > - rdmsrq(MSR_IA32_TSX_CTRL, msr); > + msr = rdmsrq(MSR_IA32_TSX_CTRL); > msr |= TSX_CTRL_CPUID_CLEAR; > wrmsrq(MSR_IA32_TSX_CTRL, msr); > } > @@ -157,7 +157,7 @@ static void tsx_dev_mode_disable(void) > !cpu_feature_enabled(X86_FEATURE_SRBDS_CTRL)) > return; > > - rdmsrq(MSR_IA32_MCU_OPT_CTRL, mcu_opt_ctrl); > + mcu_opt_ctrl = rdmsrq(MSR_IA32_MCU_OPT_CTRL); > > if (mcu_opt_ctrl & RTM_ALLOW) { > mcu_opt_ctrl &= ~RTM_ALLOW; > diff --git a/arch/x86/kernel/cpu/umwait.c b/arch/x86/kernel/cpu/umwait.c > index e4a31c536642..8c3cf0f95e9a 100644 > --- a/arch/x86/kernel/cpu/umwait.c > +++ b/arch/x86/kernel/cpu/umwait.c > @@ -218,7 +218,7 @@ static int __init umwait_init(void) > * changed. This is the only place where orig_umwait_control_cached > * is modified. > */ > - rdmsrq(MSR_IA32_UMWAIT_CONTROL, orig_umwait_control_cached); > + orig_umwait_control_cached = rdmsrq(MSR_IA32_UMWAIT_CONTROL); > > ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "umwait:online", > umwait_cpu_online, umwait_cpu_offline); > diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c > index fe504fd43c77..f89aec38a349 100644 > --- a/arch/x86/kernel/cpu/zhaoxin.c > +++ b/arch/x86/kernel/cpu/zhaoxin.c > @@ -29,7 +29,7 @@ static void init_zhaoxin_cap(struct cpuinfo_x86 *c) > > /* Enable ACE unit, if present and disabled */ > if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) { > - rdmsrq(MSR_ZHAOXIN_FCR57, msr); > + msr = rdmsrq(MSR_ZHAOXIN_FCR57); > /* Enable ACE unit */ > wrmsrq(MSR_ZHAOXIN_FCR57, msr | ACE_FCR); > pr_info("CPU: Enabled ACE h/w crypto\n"); > @@ -37,7 +37,7 @@ static void init_zhaoxin_cap(struct cpuinfo_x86 *c) > > /* Enable RNG unit, if present and disabled */ > if ((tmp & (RNG_PRESENT | RNG_ENABLED)) == RNG_PRESENT) { > - rdmsrq(MSR_ZHAOXIN_FCR57, msr); > + msr = rdmsrq(MSR_ZHAOXIN_FCR57); > /* Enable RNG unit */ > wrmsrq(MSR_ZHAOXIN_FCR57, msr | RNG_ENABLE); > pr_info("CPU: Enabled h/w RNG\n"); > diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c > index d1aeecd57f5e..7d2cff9633cf 100644 > --- a/arch/x86/kernel/fpu/core.c > +++ b/arch/x86/kernel/fpu/core.c > @@ -364,7 +364,7 @@ void fpu_sync_guest_vmexit_xfd_state(void) > > lockdep_assert_irqs_disabled(); > if (fpu_state_size_dynamic()) { > - rdmsrq(MSR_IA32_XFD, fpstate->xfd); > + fpstate->xfd = rdmsrq(MSR_IA32_XFD); > __this_cpu_write(xfd_state, fpstate->xfd); > } > } > diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c > index 8dc7b710e125..8a27b9ae9fc7 100644 > --- a/arch/x86/kernel/hpet.c > +++ b/arch/x86/kernel/hpet.c > @@ -971,7 +971,7 @@ static bool __init hpet_is_pc10_damaged(void) > return false; > > /* Check whether PC10 is enabled in PKG C-state limit */ > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, pcfg); > + pcfg = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > if ((pcfg & 0xF) < 8) > return false; > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c > index 6b0a5861ccb8..8710e3fab693 100644 > --- a/arch/x86/kernel/kvm.c > +++ b/arch/x86/kernel/kvm.c > @@ -740,7 +740,7 @@ static int kvm_suspend(void *data) > > #ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL > if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL)) > - rdmsrq(MSR_KVM_POLL_CONTROL, val); > + val = rdmsrq(MSR_KVM_POLL_CONTROL); > has_guest_poll = !(val & 1); > #endif > return 0; > diff --git a/arch/x86/kernel/mmconf-fam10h_64.c b/arch/x86/kernel/mmconf-fam10h_64.c > index ef6104e7cc72..348ac8fce3ad 100644 > --- a/arch/x86/kernel/mmconf-fam10h_64.c > +++ b/arch/x86/kernel/mmconf-fam10h_64.c > @@ -97,7 +97,7 @@ static void get_fam10h_pci_mmconf_base(void) > > /* SYS_CFG */ > address = MSR_AMD64_SYSCFG; > - rdmsrq(address, val); > + val = rdmsrq(address); > > /* TOP_MEM2 is not enabled? */ > if (!(val & (1<<21))) { > @@ -105,7 +105,7 @@ static void get_fam10h_pci_mmconf_base(void) > } else { > /* TOP_MEM2 */ > address = MSR_K8_TOP_MEM2; > - rdmsrq(address, val); > + val = rdmsrq(address); > tom2 = max(val & 0xffffff800000ULL, 1ULL << 32); > } > > @@ -177,7 +177,7 @@ void fam10h_check_enable_mmcfg(void) > return; > > address = MSR_FAM10H_MMIO_CONF_BASE; > - rdmsrq(address, val); > + val = rdmsrq(address); > > /* try to make sure that AP's setting is identical to BSP setting */ > if (val & FAM10H_MMIO_CONF_ENABLE) { > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > index 346c438ac880..85e6b076ef17 100644 > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -730,7 +730,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p) > arch_has_block_step()) { > unsigned long debugctl, msk; > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); > debugctl &= ~DEBUGCTLMSR_BTF; > msk = tifn & _TIF_BLOCKSTEP; > debugctl |= (msk >> TIF_BLOCKSTEP) << DEBUGCTLMSR_BTF_SHIFT; > @@ -980,7 +980,7 @@ void __init arch_post_acpi_subsys_init(void) > * the machine is affected K8_INTP_C1E_ACTIVE_MASK bits are set in > * MSR_K8_INT_PENDING_MSG. > */ > - rdmsrq(MSR_K8_INT_PENDING_MSG, val); > + val = rdmsrq(MSR_K8_INT_PENDING_MSG); > if (!(val & K8_INTP_C1E_ACTIVE_MASK)) > return; > > diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c > index 2bce7b3f97ed..28dbe7e629fc 100644 > --- a/arch/x86/kernel/process_64.c > +++ b/arch/x86/kernel/process_64.c > @@ -97,8 +97,8 @@ void __show_regs(struct pt_regs *regs, enum show_regs_mode mode, > return; > > if (mode == SHOW_REGS_USER) { > - rdmsrq(MSR_FS_BASE, fs); > - rdmsrq(MSR_KERNEL_GS_BASE, shadowgs); > + fs = rdmsrq(MSR_FS_BASE); > + shadowgs = rdmsrq(MSR_KERNEL_GS_BASE); > printk("%sFS: %016lx GS: %016lx\n", > log_lvl, fs, shadowgs); > return; > @@ -109,9 +109,9 @@ void __show_regs(struct pt_regs *regs, enum show_regs_mode mode, > savesegment(fs, fsindex); > savesegment(gs, gsindex); > > - rdmsrq(MSR_FS_BASE, fs); > - rdmsrq(MSR_GS_BASE, gs); > - rdmsrq(MSR_KERNEL_GS_BASE, shadowgs); > + fs = rdmsrq(MSR_FS_BASE); > + gs = rdmsrq(MSR_GS_BASE); > + shadowgs = rdmsrq(MSR_KERNEL_GS_BASE); > > cr0 = read_cr0(); > cr2 = read_cr2(); > @@ -197,7 +197,7 @@ static noinstr unsigned long __rdgsbase_inactive(void) > native_swapgs(); > } else { > instrumentation_begin(); > - rdmsrq(MSR_KERNEL_GS_BASE, gsbase); > + gsbase = rdmsrq(MSR_KERNEL_GS_BASE); > instrumentation_end(); > } > > @@ -463,7 +463,7 @@ unsigned long x86_gsbase_read_cpu_inactive(void) > gsbase = __rdgsbase_inactive(); > local_irq_restore(flags); > } else { > - rdmsrq(MSR_KERNEL_GS_BASE, gsbase); > + gsbase = rdmsrq(MSR_KERNEL_GS_BASE); > } > > return gsbase; > diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c > index 0ca64900192f..f3d1f385c626 100644 > --- a/arch/x86/kernel/shstk.c > +++ b/arch/x86/kernel/shstk.c > @@ -231,7 +231,7 @@ static unsigned long get_user_shstk_addr(void) > > fpregs_lock_and_load(); > > - rdmsrq(MSR_IA32_PL3_SSP, ssp); > + ssp = rdmsrq(MSR_IA32_PL3_SSP); > > fpregs_unlock(); > > @@ -248,7 +248,7 @@ int shstk_pop(u64 *val) > > fpregs_lock_and_load(); > > - rdmsrq(MSR_IA32_PL3_SSP, ssp); > + ssp = rdmsrq(MSR_IA32_PL3_SSP); > if (val && get_user(*val, (__user u64 *)ssp)) > ret = -EFAULT; > else > @@ -268,7 +268,7 @@ int shstk_push(u64 val) > > fpregs_lock_and_load(); > > - rdmsrq(MSR_IA32_PL3_SSP, ssp); > + ssp = rdmsrq(MSR_IA32_PL3_SSP); > ssp -= SS_FRAME_SIZE; > ret = write_user_shstk_64((__user void *)ssp, val); > if (!ret) > @@ -497,7 +497,7 @@ static int wrss_control(bool enable) > return 0; > > fpregs_lock_and_load(); > - rdmsrq(MSR_IA32_U_CET, msrval); > + msrval = rdmsrq(MSR_IA32_U_CET); > > if (enable) { > features_set(ARCH_SHSTK_WRSS); > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > index 30aa8369957e..9cd11dc7bb17 100644 > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > @@ -1250,7 +1250,7 @@ static noinstr void exc_debug_kernel(struct pt_regs *regs, unsigned long dr6) > */ > unsigned long debugctl; > > - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > + debugctl = rdmsrq(MSR_IA32_DEBUGCTLMSR); > debugctl |= DEBUGCTLMSR_BTF; > wrmsrq(MSR_IA32_DEBUGCTLMSR, debugctl); > } > @@ -1509,7 +1509,7 @@ static bool handle_xfd_event(struct pt_regs *regs) > if (!IS_ENABLED(CONFIG_X86_64) || !cpu_feature_enabled(X86_FEATURE_XFD)) > return false; > > - rdmsrq(MSR_IA32_XFD_ERR, xfd_err); > + xfd_err = rdmsrq(MSR_IA32_XFD_ERR); > if (!xfd_err) > return false; > > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > index 723347e2cf7f..39baee2307c3 100644 > --- a/arch/x86/kernel/tsc.c > +++ b/arch/x86/kernel/tsc.c > @@ -1088,7 +1088,7 @@ static void __init detect_art(void) > if (art_base_clk.denominator < ART_MIN_DENOMINATOR) > return; > > - rdmsrq(MSR_IA32_TSC_ADJUST, art_base_clk.offset); > + art_base_clk.offset = rdmsrq(MSR_IA32_TSC_ADJUST); > > /* Make this sticky over multiple CPU init calls */ > setup_force_cpu_cap(X86_FEATURE_ART); > diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c > index d74743c8d2a4..6a1d22e8b846 100644 > --- a/arch/x86/kernel/tsc_msr.c > +++ b/arch/x86/kernel/tsc_msr.c > @@ -179,15 +179,15 @@ unsigned long cpu_khz_from_msr(void) > > freq_desc = (struct freq_desc *)id->driver_data; > if (freq_desc->use_msr_plat) { > - rdmsrq(MSR_PLATFORM_INFO, val.q); > + val.q = rdmsrq(MSR_PLATFORM_INFO); > ratio = (val.l >> 8) & 0xff; > } else { > - rdmsrq(MSR_IA32_PERF_STATUS, val.q); > + val.q = rdmsrq(MSR_IA32_PERF_STATUS); > ratio = (val.h >> 8) & 0x1f; > } > > /* Get FSB FREQ ID */ > - rdmsrq(MSR_FSB_FREQ, val.q); > + val.q = rdmsrq(MSR_FSB_FREQ); > index = val.l & freq_desc->mask; > md = &freq_desc->muldiv[index]; > > diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c > index ec3aa340d351..a21ea3c85f6f 100644 > --- a/arch/x86/kernel/tsc_sync.c > +++ b/arch/x86/kernel/tsc_sync.c > @@ -66,7 +66,7 @@ void tsc_verify_tsc_adjust(bool resume) > > adj->nextcheck = jiffies + HZ; > > - rdmsrq(MSR_IA32_TSC_ADJUST, curval); > + curval = rdmsrq(MSR_IA32_TSC_ADJUST); > if (adj->adjusted == curval) > return; > > @@ -166,7 +166,7 @@ bool __init tsc_store_and_check_tsc_adjust(bool bootcpu) > if (check_tsc_unstable()) > return false; > > - rdmsrq(MSR_IA32_TSC_ADJUST, bootval); > + bootval = rdmsrq(MSR_IA32_TSC_ADJUST); > cur->bootval = bootval; > cur->nextcheck = jiffies + HZ; > tsc_sanitize_first_cpu(cur, bootval, smp_processor_id(), bootcpu); > @@ -188,7 +188,7 @@ bool tsc_store_and_check_tsc_adjust(bool bootcpu) > if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST)) > return false; > > - rdmsrq(MSR_IA32_TSC_ADJUST, bootval); > + bootval = rdmsrq(MSR_IA32_TSC_ADJUST); > cur->bootval = bootval; > cur->nextcheck = jiffies + HZ; > cur->warned = false; > diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c > index dd3bb04878ca..59c19c534564 100644 > --- a/arch/x86/kvm/msrs.c > +++ b/arch/x86/kvm/msrs.c > @@ -1205,7 +1205,7 @@ static __always_inline void kvm_access_xstate_msr(struct kvm_vcpu *vcpu, > > kvm_fpu_get(); > if (access == MSR_TYPE_R) > - rdmsrq(msr_info->index, msr_info->data); > + msr_info->data = rdmsrq(msr_info->index); > else > wrmsrq(msr_info->index, msr_info->data); > kvm_fpu_put(); > diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c > index c18286545a7a..5ebee82dba84 100644 > --- a/arch/x86/kvm/svm/pmu.c > +++ b/arch/x86/kvm/svm/pmu.c > @@ -249,7 +249,7 @@ static void amd_mediated_pmu_load(struct kvm_vcpu *vcpu) > struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); > u64 global_status; > > - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, global_status); > + global_status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); > /* Clear host global_status MSR if non-zero. */ > if (global_status) > wrmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS_CLR, global_status); > @@ -263,7 +263,7 @@ static void amd_mediated_pmu_put(struct kvm_vcpu *vcpu) > struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); > > wrmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL, 0); > - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS, pmu->global_status); > + pmu->global_status = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_STATUS); > > /* Clear global status bits if non-zero */ > if (pmu->global_status) > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 7d59d301e1e5..91f5a5344529 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -4637,7 +4637,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags) > kvm_clear_available_registers(vcpu, SVM_REGS_LAZY_LOAD_SET); > > if (!msr_write_intercepted(svm, MSR_AMD64_PERF_CNTR_GLOBAL_CTL)) > - rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL, vcpu_to_pmu(vcpu)->global_ctrl); > + vcpu_to_pmu(vcpu)->global_ctrl = rdmsrq(MSR_AMD64_PERF_CNTR_GLOBAL_CTL); > > trace_kvm_exit(vcpu, KVM_ISA_SVM); > > @@ -5485,7 +5485,7 @@ static __init void svm_adjust_mmio_mask(void) > return; > > /* If memory encryption is not enabled, use existing mask */ > - rdmsrq(MSR_AMD64_SYSCFG, msr); > + msr = rdmsrq(MSR_AMD64_SYSCFG); > if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT)) > return; > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > index 151873407abd..3f06d6742f0e 100644 > --- a/arch/x86/kvm/vmx/nested.c > +++ b/arch/x86/kvm/vmx/nested.c > @@ -7358,8 +7358,8 @@ static void nested_vmx_setup_cr_fixed(struct nested_vmx_msrs *msrs) > msrs->cr4_fixed0 = VMXON_CR4_ALWAYSON; > > /* These MSRs specify bits which the guest must keep fixed off. */ > - rdmsrq(MSR_IA32_VMX_CR0_FIXED1, msrs->cr0_fixed1); > - rdmsrq(MSR_IA32_VMX_CR4_FIXED1, msrs->cr4_fixed1); > + msrs->cr0_fixed1 = rdmsrq(MSR_IA32_VMX_CR0_FIXED1); > + msrs->cr4_fixed1 = rdmsrq(MSR_IA32_VMX_CR4_FIXED1); > > if (vmx_umip_emulated()) > msrs->cr4_fixed1 |= X86_CR4_UMIP; > diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c > index bfa8612fb450..24cfbb8f5078 100644 > --- a/arch/x86/kvm/vmx/pmu_intel.c > +++ b/arch/x86/kvm/vmx/pmu_intel.c > @@ -320,7 +320,7 @@ static bool intel_pmu_handle_lbr_msrs_access(struct kvm_vcpu *vcpu, > int err = 0; > > if (read) > - rdmsrq(index, msr_info->data); > + msr_info->data = rdmsrq(index); > else > err = wrmsrq_safe(index, msr_info->data); > __set_bit(INTEL_PMC_IDX_FIXED_VLBR, vcpu_to_pmu(vcpu)->pmc_in_use); > @@ -772,7 +772,7 @@ static bool intel_pmu_is_mediated_pmu_supported(struct x86_pmu_capability *host_ > u64 host_perf_cap = 0; > > if (boot_cpu_has(X86_FEATURE_PDCM)) > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, host_perf_cap); > + host_perf_cap = rdmsrq(MSR_IA32_PERF_CAPABILITIES); > > /* > * Require v4+ for MSR_CORE_PERF_GLOBAL_STATUS_SET, and full-width > @@ -801,7 +801,7 @@ static void intel_mediated_pmu_load(struct kvm_vcpu *vcpu) > struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); > u64 global_status, toggle; > > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, global_status); > + global_status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > toggle = pmu->global_status ^ global_status; > if (global_status & toggle) > wrmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, global_status & toggle); > @@ -816,7 +816,7 @@ static void intel_mediated_pmu_put(struct kvm_vcpu *vcpu) > struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); > > /* MSR_CORE_PERF_GLOBAL_CTRL is already saved at VM-exit. */ > - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, pmu->global_status); > + pmu->global_status = rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS); > > /* Clear hardware MSR_CORE_PERF_GLOBAL_STATUS MSR, if non-zero. */ > if (pmu->global_status) > diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c > index 771c75a58343..765cac151023 100644 > --- a/arch/x86/kvm/vmx/sgx.c > +++ b/arch/x86/kvm/vmx/sgx.c > @@ -420,9 +420,9 @@ void setup_default_sgx_lepubkeyhash(void) > sgx_pubkey_hash[3] = 0xd4f8c05909f9bb3bULL; > } else { > /* MSR_IA32_SGXLEPUBKEYHASH0 is read above */ > - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH1, sgx_pubkey_hash[1]); > - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH2, sgx_pubkey_hash[2]); > - rdmsrq(MSR_IA32_SGXLEPUBKEYHASH3, sgx_pubkey_hash[3]); > + sgx_pubkey_hash[1] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH1); > + sgx_pubkey_hash[2] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH2); > + sgx_pubkey_hash[3] = rdmsrq(MSR_IA32_SGXLEPUBKEYHASH3); > } > } > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index 612ab07d4100..2c8487bbda6a 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -1261,13 +1261,13 @@ static inline void pt_save_msr(struct pt_ctx *ctx, u32 addr_range) > { > u32 i; > > - rdmsrq(MSR_IA32_RTIT_STATUS, ctx->status); > - rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE, ctx->output_base); > - rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK, ctx->output_mask); > - rdmsrq(MSR_IA32_RTIT_CR3_MATCH, ctx->cr3_match); > + ctx->status = rdmsrq(MSR_IA32_RTIT_STATUS); > + ctx->output_base = rdmsrq(MSR_IA32_RTIT_OUTPUT_BASE); > + ctx->output_mask = rdmsrq(MSR_IA32_RTIT_OUTPUT_MASK); > + ctx->cr3_match = rdmsrq(MSR_IA32_RTIT_CR3_MATCH); > for (i = 0; i < addr_range; i++) { > - rdmsrq(MSR_IA32_RTIT_ADDR0_A + i * 2, ctx->addr_a[i]); > - rdmsrq(MSR_IA32_RTIT_ADDR0_B + i * 2, ctx->addr_b[i]); > + ctx->addr_a[i] = rdmsrq(MSR_IA32_RTIT_ADDR0_A + i * 2); > + ctx->addr_b[i] = rdmsrq(MSR_IA32_RTIT_ADDR0_B + i * 2); > } > } > > @@ -1280,7 +1280,7 @@ static void pt_guest_enter(struct vcpu_vmx *vmx) > * GUEST_IA32_RTIT_CTL is already set in the VMCS. > * Save host state before VM entry. > */ > - rdmsrq(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl); > + vmx->pt_desc.host.ctl = rdmsrq(MSR_IA32_RTIT_CTL); > if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) { > wrmsrq(MSR_IA32_RTIT_CTL, 0); > pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.num_address_ranges); > @@ -1418,7 +1418,7 @@ static void vmx_prepare_switch_to_host(struct vcpu_vmx *vmx) > ++vmx->vcpu.stat.host_state_reload; > > #ifdef CONFIG_X86_64 > - rdmsrq(MSR_KERNEL_GS_BASE, vmx->msr_guest_kernel_gs_base); > + vmx->msr_guest_kernel_gs_base = rdmsrq(MSR_KERNEL_GS_BASE); > #endif > if (host_state->ldt_sel || (host_state->gs_sel & 7)) { > vmx_load_ldt(host_state->ldt_sel); > @@ -2694,7 +2694,7 @@ static int adjust_vmx_controls(u32 ctl_min, u32 ctl_opt, u32 msr, u32 *result) > struct msr vmx_msr; > u32 ctl = ctl_min | ctl_opt; > > - rdmsrq(msr, vmx_msr.q); > + vmx_msr.q = rdmsrq(msr); > > ctl &= vmx_msr.h; /* bit == 0 in high word ==> must be zero */ > ctl |= vmx_msr.l; /* bit == 1 in low word ==> must be one */ > @@ -2711,7 +2711,7 @@ static u64 adjust_vmx_controls64(u64 ctl_opt, u32 msr) > { > u64 allowed; > > - rdmsrq(msr, allowed); > + allowed = rdmsrq(msr); > > return ctl_opt & allowed; > } > @@ -2897,7 +2897,7 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf, > break; > } > > - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); > + basic_msr = rdmsrq(MSR_IA32_VMX_BASIC); > > /* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */ > if (vmx_basic_vmcs_size(basic_msr) > PAGE_SIZE) > @@ -2917,7 +2917,7 @@ static int setup_vmcs_config(struct vmcs_config *vmcs_conf, > if (vmx_basic_vmcs_mem_type(basic_msr) != X86_MEMTYPE_WB) > return -EIO; > > - rdmsrq(MSR_IA32_VMX_MISC, misc_msr); > + misc_msr = rdmsrq(MSR_IA32_VMX_MISC); > > vmcs_conf->basic = basic_msr; > vmcs_conf->pin_based_exec_ctrl = _pin_based_exec_control; > @@ -4494,7 +4494,7 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx) > > vmcs_writel(HOST_RIP, (unsigned long)vmx_vmexit); /* 22.2.5 */ > > - rdmsrq(MSR_IA32_SYSENTER_CS, val.q); > + val.q = rdmsrq(MSR_IA32_SYSENTER_CS); > vmcs_write32(HOST_IA32_SYSENTER_CS, val.l); > > /* > @@ -4506,11 +4506,11 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx) > if (!IS_ENABLED(CONFIG_IA32_EMULATION) && !IS_ENABLED(CONFIG_X86_32)) > vmcs_writel(HOST_IA32_SYSENTER_ESP, 0); > > - rdmsrq(MSR_IA32_SYSENTER_EIP, tmpl); > + tmpl = rdmsrq(MSR_IA32_SYSENTER_EIP); > vmcs_writel(HOST_IA32_SYSENTER_EIP, tmpl); /* 22.2.3 */ > > if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_PAT) { > - rdmsrq(MSR_IA32_CR_PAT, val.q); > + val.q = rdmsrq(MSR_IA32_CR_PAT); > vmcs_write64(HOST_IA32_PAT, val.q); > } > > @@ -7161,7 +7161,7 @@ static void handle_nm_fault_irqoff(struct kvm_vcpu *vcpu) > * the #NM exception. > */ > if (is_xfd_nm_fault(vcpu)) > - rdmsrq(MSR_IA32_XFD_ERR, vcpu->arch.guest_fpu.xfd_err); > + vcpu->arch.guest_fpu.xfd_err = rdmsrq(MSR_IA32_XFD_ERR); > } > > static void handle_exception_irqoff(struct kvm_vcpu *vcpu, u32 intr_info) > @@ -8031,7 +8031,7 @@ static __init u64 vmx_get_perf_capabilities(void) > return 0; > > if (boot_cpu_has(X86_FEATURE_PDCM)) > - rdmsrq(MSR_IA32_PERF_CAPABILITIES, host_perf_cap); > + host_perf_cap = rdmsrq(MSR_IA32_PERF_CAPABILITIES); > > if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR) && > !enable_mediated_pmu) { > @@ -8680,7 +8680,7 @@ __init int vmx_hardware_setup(void) > vmx_setup_user_return_msrs(); > > if (boot_cpu_has(X86_FEATURE_MPX)) { > - rdmsrq(MSR_IA32_BNDCFGS, host_bndcfgs); > + host_bndcfgs = rdmsrq(MSR_IA32_BNDCFGS); > WARN_ONCE(host_bndcfgs, "BNDCFGS in host will be lost"); > } > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 79468ddfe473..6bbeb9b6e4b9 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -7037,7 +7037,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) > } > > if (boot_cpu_has(X86_FEATURE_SHSTK) || boot_cpu_has(X86_FEATURE_IBT)) { > - rdmsrq(MSR_IA32_S_CET, kvm_host.s_cet); > + kvm_host.s_cet = rdmsrq(MSR_IA32_S_CET); > /* > * Linux doesn't yet support supervisor shadow stacks (SSS), so > * KVM doesn't save/restore the associated MSRs, i.e. KVM may > @@ -7069,7 +7069,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) > } > > if (boot_cpu_has(X86_FEATURE_XSAVES)) { > - rdmsrq(MSR_IA32_XSS, kvm_host.xss); > + kvm_host.xss = rdmsrq(MSR_IA32_XSS); > kvm_caps.supported_xss = kvm_host.xss & KVM_SUPPORTED_XSS; > } > > @@ -7081,7 +7081,7 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) > kvm_init_pmu_capability(ops->pmu_ops); > > if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) > - rdmsrq(MSR_IA32_ARCH_CAPABILITIES, kvm_host.arch_capabilities); > + kvm_host.arch_capabilities = rdmsrq(MSR_IA32_ARCH_CAPABILITIES); > > WARN_ON_ONCE(kvm_nr_uret_msrs); > > diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c > index e03eeec55cfe..b9db2012a75e 100644 > --- a/arch/x86/lib/insn-eval.c > +++ b/arch/x86/lib/insn-eval.c > @@ -709,16 +709,16 @@ unsigned long insn_get_seg_base(struct pt_regs *regs, int seg_reg_idx) > unsigned long base; > > if (seg_reg_idx == INAT_SEG_REG_FS) { > - rdmsrq(MSR_FS_BASE, base); > + base = rdmsrq(MSR_FS_BASE); > } else if (seg_reg_idx == INAT_SEG_REG_GS) { > /* > * swapgs was called at the kernel entry point. Thus, > * MSR_KERNEL_GS_BASE will have the user-space GS base. > */ > if (user_mode(regs)) > - rdmsrq(MSR_KERNEL_GS_BASE, base); > + base = rdmsrq(MSR_KERNEL_GS_BASE); > else > - rdmsrq(MSR_GS_BASE, base); > + base = rdmsrq(MSR_GS_BASE); > } else { > base = 0; > } > diff --git a/arch/x86/lib/msr-smp.c b/arch/x86/lib/msr-smp.c > index 7b6cfc2c0970..ddff68050322 100644 > --- a/arch/x86/lib/msr-smp.c > +++ b/arch/x86/lib/msr-smp.c > @@ -15,7 +15,7 @@ static void __rdmsr_on_cpu(void *info) > else > reg = &rv->reg; > > - rdmsrq(rv->msr_no, reg->q); > + reg->q = rdmsrq(rv->msr_no); > } > > static void __wrmsr_on_cpu(void *info) > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c > index cf94fb561310..114853c212ed 100644 > --- a/arch/x86/mm/pat/memtype.c > +++ b/arch/x86/mm/pat/memtype.c > @@ -257,7 +257,7 @@ void __init pat_bp_init(void) > if (!cpu_feature_enabled(X86_FEATURE_PAT)) > pat_disable("PAT not supported by the CPU."); > else > - rdmsrq(MSR_IA32_CR_PAT, pat_msr_val); > + pat_msr_val = rdmsrq(MSR_IA32_CR_PAT); > > if (!pat_msr_val) { > pat_disable("PAT support disabled by the firmware."); > diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c > index 99b1727136c1..342371081f60 100644 > --- a/arch/x86/pci/amd_bus.c > +++ b/arch/x86/pci/amd_bus.c > @@ -202,7 +202,7 @@ static int __init early_root_info_init(void) > > /* need to take out [0, TOM) for RAM*/ > address = MSR_K8_TOP_MEM1; > - rdmsrq(address, val); > + val = rdmsrq(address); > end = (val & 0xffffff800000ULL); > printk(KERN_INFO "TOM: %016llx aka %lldM\n", end, end>>20); > if (end < (1ULL<<32)) > @@ -293,12 +293,12 @@ static int __init early_root_info_init(void) > /* need to take out [4G, TOM2) for RAM*/ > /* SYS_CFG */ > address = MSR_AMD64_SYSCFG; > - rdmsrq(address, val); > + val = rdmsrq(address); > /* TOP_MEM2 is enabled? */ > if (val & (1<<21)) { > /* TOP_MEM2 */ > address = MSR_K8_TOP_MEM2; > - rdmsrq(address, val); > + val = rdmsrq(address); > end = (val & 0xffffff800000ULL); > printk(KERN_INFO "TOM2: %016llx aka %lldM\n", end, end>>20); > subtract_range(range, RANGE_NUM, 1ULL<<32, end); > @@ -341,7 +341,7 @@ static int amd_bus_cpu_online(unsigned int cpu) > { > u64 reg; > > - rdmsrq(MSR_AMD64_NB_CFG, reg); > + reg = rdmsrq(MSR_AMD64_NB_CFG); > if (!(reg & ENABLE_CF8_EXT_CFG)) { > reg |= ENABLE_CF8_EXT_CFG; > wrmsrq(MSR_AMD64_NB_CFG, reg); > diff --git a/arch/x86/platform/olpc/olpc-xo1-rtc.c b/arch/x86/platform/olpc/olpc-xo1-rtc.c > index ee77d57bcab7..95dfd90b1f05 100644 > --- a/arch/x86/platform/olpc/olpc-xo1-rtc.c > +++ b/arch/x86/platform/olpc/olpc-xo1-rtc.c > @@ -64,9 +64,9 @@ static int __init xo1_rtc_init(void) > of_node_put(node); > > pr_info("olpc-xo1-rtc: Initializing OLPC XO-1 RTC\n"); > - rdmsrq(MSR_RTC_DOMA_OFFSET, rtc_info.rtc_day_alarm); > - rdmsrq(MSR_RTC_MONA_OFFSET, rtc_info.rtc_mon_alarm); > - rdmsrq(MSR_RTC_CEN_OFFSET, rtc_info.rtc_century); > + rtc_info.rtc_day_alarm = rdmsrq(MSR_RTC_DOMA_OFFSET); > + rtc_info.rtc_mon_alarm = rdmsrq(MSR_RTC_MONA_OFFSET); > + rtc_info.rtc_century = rdmsrq(MSR_RTC_CEN_OFFSET); > > r = platform_device_register(&xo1_rtc_device); > if (r) > diff --git a/arch/x86/platform/olpc/olpc-xo1-sci.c b/arch/x86/platform/olpc/olpc-xo1-sci.c > index 8b5b3626b559..d2b63a7c0fe6 100644 > --- a/arch/x86/platform/olpc/olpc-xo1-sci.c > +++ b/arch/x86/platform/olpc/olpc-xo1-sci.c > @@ -316,7 +316,7 @@ static int setup_sci_interrupt(struct platform_device *pdev) > u32 sts; > int r; > > - rdmsrq(0x51400020, msr); > + msr = rdmsrq(0x51400020); > sci_irq = (msr >> 20) & 15; > > if (sci_irq) { > diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c > index 702f30eaf9c4..f44ebe2fe099 100644 > --- a/arch/x86/power/cpu.c > +++ b/arch/x86/power/cpu.c > @@ -45,7 +45,7 @@ static void msr_save_context(struct saved_context *ctxt) > > while (msr < end) { > if (msr->valid) > - rdmsrq(msr->info.msr_no, msr->info.reg.q); > + msr->info.reg.q = rdmsrq(msr->info.msr_no); > msr++; > } > } > @@ -111,12 +111,12 @@ static void __save_processor_state(struct saved_context *ctxt) > savesegment(ds, ctxt->ds); > savesegment(es, ctxt->es); > > - rdmsrq(MSR_FS_BASE, ctxt->fs_base); > - rdmsrq(MSR_GS_BASE, ctxt->kernelmode_gs_base); > - rdmsrq(MSR_KERNEL_GS_BASE, ctxt->usermode_gs_base); > + ctxt->fs_base = rdmsrq(MSR_FS_BASE); > + ctxt->kernelmode_gs_base = rdmsrq(MSR_GS_BASE); > + ctxt->usermode_gs_base = rdmsrq(MSR_KERNEL_GS_BASE); > mtrr_save_fixed_ranges(NULL); > > - rdmsrq(MSR_EFER, ctxt->efer); > + ctxt->efer = rdmsrq(MSR_EFER); > #endif > > /* > diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c > index 694d80a5c68e..469f2aa8e105 100644 > --- a/arch/x86/realmode/init.c > +++ b/arch/x86/realmode/init.c > @@ -147,7 +147,7 @@ static void __init setup_real_mode(void) > * Some AMD processors will #GP(0) if EFER.LMA is set in WRMSR > * so we need to mask it out. > */ > - rdmsrq(MSR_EFER, efer); > + efer = rdmsrq(MSR_EFER); > trampoline_header->efer = efer & ~EFER_LMA; > > trampoline_header->start = (u64) secondary_startup_64; > diff --git a/arch/x86/virt/hw.c b/arch/x86/virt/hw.c > index a236447ac7a2..a0f5ecb5b946 100644 > --- a/arch/x86/virt/hw.c > +++ b/arch/x86/virt/hw.c > @@ -178,7 +178,7 @@ static __init int __x86_vmx_init(void) > if (!cpu_feature_enabled(X86_FEATURE_VMX)) > return -EOPNOTSUPP; > > - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); > + basic_msr = rdmsrq(MSR_IA32_VMX_BASIC); > > /* IA-32 SDM Vol 3B: VMCS size is never greater than 4kB. */ > if (WARN_ON_ONCE(vmx_basic_vmcs_size(basic_msr) > PAGE_SIZE)) > @@ -230,7 +230,7 @@ static int x86_svm_enable_virtualization_cpu(void) > { > u64 efer; > > - rdmsrq(MSR_EFER, efer); > + efer = rdmsrq(MSR_EFER); > if (efer & EFER_SVME) > return -EBUSY; > > @@ -253,7 +253,7 @@ static int x86_svm_disable_virtualization_cpu(void) > r = 0; > > fault: > - rdmsrq(MSR_EFER, efer); > + efer = rdmsrq(MSR_EFER); > wrmsrq(MSR_EFER, efer & ~EFER_SVME); > return r; > } > @@ -264,7 +264,7 @@ static void x86_svm_emergency_disable_virtualization_cpu(void) > > virt_rebooting = true; > > - rdmsrq(MSR_EFER, efer); > + efer = rdmsrq(MSR_EFER); > if (!(efer & EFER_SVME)) > return; > > diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c > index cff285d8ad8e..4a1e75d66e6c 100644 > --- a/arch/x86/virt/svm/sev.c > +++ b/arch/x86/virt/svm/sev.c > @@ -150,7 +150,7 @@ static void snp_enable(void *arg) > if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP)) > return; > > - rdmsrq(MSR_AMD64_SYSCFG, val); > + val = rdmsrq(MSR_AMD64_SYSCFG); > > val |= MSR_AMD64_SYSCFG_SNP_EN; > val |= MSR_AMD64_SYSCFG_SNP_VMPL_EN; > @@ -254,7 +254,7 @@ static void clear_rmp(void) > return; > > /* Clearing the RMP while SNP is enabled will cause an exception */ > - rdmsrq(MSR_AMD64_SYSCFG, val); > + val = rdmsrq(MSR_AMD64_SYSCFG); > if (WARN_ON_ONCE(val & MSR_AMD64_SYSCFG_SNP_EN)) > return; > > @@ -520,7 +520,7 @@ int snp_prepare(void) > * Check if SEV-SNP is already enabled, this can happen in case of > * kexec boot. > */ > - rdmsrq(MSR_AMD64_SYSCFG, val); > + val = rdmsrq(MSR_AMD64_SYSCFG); > if (val & MSR_AMD64_SYSCFG_SNP_EN) > return 0; > > @@ -561,7 +561,7 @@ void snp_shutdown(void) > { > u64 syscfg; > > - rdmsrq(MSR_AMD64_SYSCFG, syscfg); > + syscfg = rdmsrq(MSR_AMD64_SYSCFG); > if (syscfg & MSR_AMD64_SYSCFG_SNP_EN) > return; > > @@ -608,8 +608,8 @@ static bool probe_contiguous_rmptable_info(void) > { > u64 rmp_sz, rmp_base, rmp_end; > > - rdmsrq(MSR_AMD64_RMP_BASE, rmp_base); > - rdmsrq(MSR_AMD64_RMP_END, rmp_end); > + rmp_base = rdmsrq(MSR_AMD64_RMP_BASE); > + rmp_end = rdmsrq(MSR_AMD64_RMP_END); > > if (!(rmp_base & RMP_ADDR_MASK) || !(rmp_end & RMP_ADDR_MASK)) { > pr_err("Memory for the RMP table has not been reserved by BIOS\n"); > @@ -642,13 +642,13 @@ static bool probe_segmented_rmptable_info(void) > unsigned int eax, ebx, segment_shift, segment_shift_min, segment_shift_max; > u64 rmp_base, rmp_end; > > - rdmsrq(MSR_AMD64_RMP_BASE, rmp_base); > + rmp_base = rdmsrq(MSR_AMD64_RMP_BASE); > if (!(rmp_base & RMP_ADDR_MASK)) { > pr_err("Memory for the RMP table has not been reserved by BIOS\n"); > return false; > } > > - rdmsrq(MSR_AMD64_RMP_END, rmp_end); > + rmp_end = rdmsrq(MSR_AMD64_RMP_END); > WARN_ONCE(rmp_end & RMP_ADDR_MASK, > "Segmented RMP enabled but RMP_END MSR is non-zero\n"); > > @@ -684,7 +684,7 @@ static bool probe_segmented_rmptable_info(void) > bool snp_probe_rmptable_info(void) > { > if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) > - rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg); > + rmp_cfg = rdmsrq(MSR_AMD64_RMP_CFG); > > if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) > return probe_segmented_rmptable_info(); > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c > index 1b9ff749dd8e..9839f5b8dcc3 100644 > --- a/arch/x86/virt/vmx/tdx/tdx.c > +++ b/arch/x86/virt/vmx/tdx/tdx.c > @@ -1523,7 +1523,7 @@ static void __init check_tdx_erratum(void) > * Some TDX-capable CPUs have an erratum where the current VMCS is > * cleared after calling into P-SEAMLDR. > */ > - rdmsrq(MSR_IA32_VMX_BASIC, basic_msr); > + basic_msr = rdmsrq(MSR_IA32_VMX_BASIC); > if (!(basic_msr & VMX_BASIC_NO_SEAMRET_INVD_VMCS)) > setup_force_cpu_bug(X86_BUG_SEAMRET_INVD_VMCS); > } > diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c > index ba2f17e64321..b0e1152aa80e 100644 > --- a/arch/x86/xen/suspend.c > +++ b/arch/x86/xen/suspend.c > @@ -56,7 +56,7 @@ static void xen_vcpu_notify_suspend(void *data) > tick_suspend_local(); > > if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { > - rdmsrq(MSR_IA32_SPEC_CTRL, tmp); > + tmp = rdmsrq(MSR_IA32_SPEC_CTRL); > this_cpu_write(spec_ctrl, tmp); > wrmsrq(MSR_IA32_SPEC_CTRL, 0); > } > diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c > index 9e25d6124efd..535a0f9dd2cf 100644 > --- a/drivers/acpi/processor_perflib.c > +++ b/drivers/acpi/processor_perflib.c > @@ -296,7 +296,7 @@ static void amd_fixup_frequency(struct acpi_processor_px *px, int i) > > if ((boot_cpu_data.x86 == 0x10 && boot_cpu_data.x86_model < 10) || > boot_cpu_data.x86 == 0x11) { > - rdmsrq(MSR_AMD_PSTATE_DEF_BASE + index, val.q); > + val.q = rdmsrq(MSR_AMD_PSTATE_DEF_BASE + index); > /* > * MSR C001_0064+: > * Bit 63: PstateEn. Read-write. If set, the P-state is valid. > diff --git a/drivers/ata/pata_cs5535.c b/drivers/ata/pata_cs5535.c > index 512f9728224f..5ca17faa8e6e 100644 > --- a/drivers/ata/pata_cs5535.c > +++ b/drivers/ata/pata_cs5535.c > @@ -110,7 +110,7 @@ static void cs5535_set_piomode(struct ata_port *ap, struct ata_device *adev) > pio_cmd_timings[cmdmode] | pio_timings[mode]); > > /* Set the PIO "format 1" bit in the DMA timing register */ > - rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg); > + reg = rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno); > wrmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg | 0x80000000UL); > } > > @@ -132,7 +132,7 @@ static void cs5535_set_dmamode(struct ata_port *ap, struct ata_device *adev) > u32 reg; > int mode = adev->dma_mode; > > - rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno, reg); > + reg = rdmsrq(ATAC_CH0D0_DMA + 2 * adev->devno); > reg &= 0x80000000UL; > if (mode >= XFER_UDMA_0) > reg |= udma_timings[mode - XFER_UDMA_0]; > diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c > index 61d232a82b5e..eca97dce1e85 100644 > --- a/drivers/ata/pata_cs5536.c > +++ b/drivers/ata/pata_cs5536.c > @@ -84,7 +84,7 @@ static int cs5536_read(struct pci_dev *pdev, int reg, u32 *val) > { > #ifdef MAYBE_USE_MSR > if (unlikely(use_msr)) { > - rdmsrq(MSR_IDE_CFG + reg, *val); > + *val = rdmsrq(MSR_IDE_CFG + reg); > return 0; > } > #endif > diff --git a/drivers/char/agp/nvidia-agp.c b/drivers/char/agp/nvidia-agp.c > index 3e760bc00afa..f646f1854981 100644 > --- a/drivers/char/agp/nvidia-agp.c > +++ b/drivers/char/agp/nvidia-agp.c > @@ -72,8 +72,8 @@ static int nvidia_init_iorr(u32 base, u32 size) > /* If not found, determine the uppermost available iorr */ > free_iorr_addr = AMD_K7_NUM_IORR; > for (iorr_addr = 0; iorr_addr < AMD_K7_NUM_IORR; iorr_addr++) { > - rdmsrq(IORR_BASE0 + 2 * iorr_addr, base_msr.q); > - rdmsrq(IORR_MASK0 + 2 * iorr_addr, mask_msr.q); > + base_msr.q = rdmsrq(IORR_BASE0 + 2 * iorr_addr); > + mask_msr.q = rdmsrq(IORR_MASK0 + 2 * iorr_addr); > > if ((base_msr.l & 0xfffff000) == (base & 0xfffff000)) > break; > @@ -94,7 +94,7 @@ static int nvidia_init_iorr(u32 base, u32 size) > wrmsrq(IORR_BASE0 + 2 * iorr_addr, base_msr.q); > wrmsrq(IORR_MASK0 + 2 * iorr_addr, mask_msr.q); > > - rdmsrq(SYSCFG, sys_msr.q); > + sys_msr.q = rdmsrq(SYSCFG); > sys_msr.l |= 0x00100000; > wrmsrq(SYSCFG, sys_msr.q); > > diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c > index b718e78d3c1c..a0a3488a6947 100644 > --- a/drivers/char/hw_random/via-rng.c > +++ b/drivers/char/hw_random/via-rng.c > @@ -151,7 +151,7 @@ static int via_rng_init(struct hwrng *rng) > * does not say to write them as zero, so I make a guess that > * we restore the values we find in the register. > */ > - rdmsrq(MSR_VIA_RNG, val.q); > + val.q = rdmsrq(MSR_VIA_RNG); > > old_lo = val.l; > val.l &= ~(0x7f << VIA_STRFILT_CNT_SHIFT); > @@ -175,7 +175,7 @@ static int via_rng_init(struct hwrng *rng) > > /* perhaps-unnecessary sanity check; remove after testing if > unneeded */ > - rdmsrq(MSR_VIA_RNG, val.q); > + val.q = rdmsrq(MSR_VIA_RNG); > if ((val.l & VIA_RNG_ENABLE) == 0) { > pr_err(PFX "cannot enable VIA C3 RNG, aborting\n"); > return -ENODEV; > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c > index 10ea6035f4ad..e1ee80ecd0bb 100644 > --- a/drivers/cpufreq/acpi-cpufreq.c > +++ b/drivers/cpufreq/acpi-cpufreq.c > @@ -110,7 +110,7 @@ static int boost_set_msr(bool enable) > return -EINVAL; > } > > - rdmsrq(msr_addr, val); > + val = rdmsrq(msr_addr); > > if (enable) > val &= ~msr_mask; > @@ -248,7 +248,7 @@ static u32 cpu_freq_read_intel(struct acpi_pct_register *not_used) > { > u64 val; > > - rdmsrq(MSR_IA32_PERF_CTL, val); > + val = rdmsrq(MSR_IA32_PERF_CTL); > return (u32)val; > } > > @@ -256,7 +256,7 @@ static void cpu_freq_write_intel(struct acpi_pct_register *not_used, u32 val) > { > u64 msrval; > > - rdmsrq(MSR_IA32_PERF_CTL, msrval); > + msrval = rdmsrq(MSR_IA32_PERF_CTL); > msrval = (msrval & ~(u64)INTEL_MSR_RANGE) | (val & INTEL_MSR_RANGE); > wrmsrq(MSR_IA32_PERF_CTL, msrval); > } > @@ -265,7 +265,7 @@ static u32 cpu_freq_read_amd(struct acpi_pct_register *not_used) > { > u64 val; > > - rdmsrq(MSR_AMD_PERF_CTL, val); > + val = rdmsrq(MSR_AMD_PERF_CTL); > return (u32)val; > } > > diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c > index 8bfd46d60843..53838c7470c7 100644 > --- a/drivers/cpufreq/amd-pstate.c > +++ b/drivers/cpufreq/amd-pstate.c > @@ -596,8 +596,8 @@ static inline bool amd_pstate_sample(struct amd_cpudata *cpudata) > unsigned long flags; > > local_irq_save(flags); > - rdmsrq(MSR_IA32_APERF, aperf); > - rdmsrq(MSR_IA32_MPERF, mperf); > + aperf = rdmsrq(MSR_IA32_APERF); > + mperf = rdmsrq(MSR_IA32_MPERF); > tsc = rdtsc(); > > if (cpudata->prev.mperf == mperf || cpudata->prev.tsc == tsc) { > diff --git a/drivers/cpufreq/e_powersaver.c b/drivers/cpufreq/e_powersaver.c > index 54689ebadeb2..cc05494ac316 100644 > --- a/drivers/cpufreq/e_powersaver.c > +++ b/drivers/cpufreq/e_powersaver.c > @@ -99,7 +99,7 @@ static unsigned int eps_get(unsigned int cpu) > return 0; > > /* Return current frequency */ > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val = rdmsrq(MSR_IA32_PERF_STATUS); > return centaur->fsb * ((val >> 8) & 0xff); > } > > @@ -111,11 +111,11 @@ static int eps_set_state(struct eps_cpu_data *centaur, > int i; > > /* Wait while CPU is busy */ > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val = rdmsrq(MSR_IA32_PERF_STATUS); > i = 0; > while (val & ((1 << 16) | (1 << 17))) { > udelay(16); > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val = rdmsrq(MSR_IA32_PERF_STATUS); > i++; > if (unlikely(i > 64)) { > return -ENODEV; > @@ -127,7 +127,7 @@ static int eps_set_state(struct eps_cpu_data *centaur, > i = 0; > do { > udelay(16); > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val = rdmsrq(MSR_IA32_PERF_STATUS); > i++; > if (unlikely(i > 64)) { > return -ENODEV; > @@ -139,7 +139,7 @@ static int eps_set_state(struct eps_cpu_data *centaur, > u8 current_multiplier, current_voltage; > > /* Print voltage and multiplier */ > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val = rdmsrq(MSR_IA32_PERF_STATUS); > current_voltage = val & 0xff; > pr_info("Current voltage = %dmV\n", current_voltage * 16 + 700); > current_multiplier = (val >> 8) & 0xff; > @@ -194,12 +194,12 @@ static int eps_cpu_init(struct cpufreq_policy *policy) > > switch (c->x86_model) { > case 10: > - rdmsrq(0x1153, val); > + val = rdmsrq(0x1153); > brand = (((val >> 2) ^ val) >> 18) & 3; > pr_cont("Model A "); > break; > case 13: > - rdmsrq(0x1154, val); > + val = rdmsrq(0x1154); > brand = (((val >> 4) ^ (val >> 2))) & 0x000000ff; > pr_cont("Model D "); > break; > @@ -223,12 +223,12 @@ static int eps_cpu_init(struct cpufreq_policy *policy) > return -ENODEV; > } > /* Enable Enhanced PowerSaver */ > - rdmsrq(MSR_IA32_MISC_ENABLE, val); > + val = rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(val & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { > val |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP; > wrmsrq(MSR_IA32_MISC_ENABLE, val); > /* Can be locked at 0 */ > - rdmsrq(MSR_IA32_MISC_ENABLE, val); > + val = rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(val & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { > pr_info("Can't enable Enhanced PowerSaver\n"); > return -ENODEV; > @@ -236,7 +236,7 @@ static int eps_cpu_init(struct cpufreq_policy *policy) > } > > /* Print voltage and multiplier */ > - rdmsrq(MSR_IA32_PERF_STATUS, val); > + val = rdmsrq(MSR_IA32_PERF_STATUS); > current_voltage = val & 0xff; > pr_info("Current voltage = %dmV\n", current_voltage * 16 + 700); > current_multiplier = (val >> 8) & 0xff; > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index ceb340f7a110..1a0eb8c359c0 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -560,7 +560,7 @@ static bool turbo_is_disabled(void) > { > u64 misc_en; > > - rdmsrq(MSR_IA32_MISC_ENABLE, misc_en); > + misc_en = rdmsrq(MSR_IA32_MISC_ENABLE); > > return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE); > } > @@ -1351,7 +1351,7 @@ static void set_power_ctl_ee_state(bool input) > > guard(mutex)(&intel_pstate_driver_lock); > > - rdmsrq(MSR_IA32_POWER_CTL, power_ctl); > + power_ctl = rdmsrq(MSR_IA32_POWER_CTL); > if (input) { > power_ctl &= ~BIT(MSR_IA32_POWER_CTL_BIT_EE); > power_ctl_ee_state = POWER_CTL_EE_ENABLE; > @@ -1728,7 +1728,7 @@ static ssize_t show_energy_efficiency(struct kobject *kobj, struct kobj_attribut > u64 power_ctl; > int enable; > > - rdmsrq(MSR_IA32_POWER_CTL, power_ctl); > + power_ctl = rdmsrq(MSR_IA32_POWER_CTL); > enable = !!(power_ctl & BIT(MSR_IA32_POWER_CTL_BIT_EE)); > return sprintf(buf, "%d\n", !enable); > } > @@ -2022,7 +2022,7 @@ static int atom_get_min_pstate(int not_used) > { > u64 value; > > - rdmsrq(MSR_ATOM_CORE_RATIOS, value); > + value = rdmsrq(MSR_ATOM_CORE_RATIOS); > return (value >> 8) & 0x7F; > } > > @@ -2030,7 +2030,7 @@ static int atom_get_max_pstate(int not_used) > { > u64 value; > > - rdmsrq(MSR_ATOM_CORE_RATIOS, value); > + value = rdmsrq(MSR_ATOM_CORE_RATIOS); > return (value >> 16) & 0x7F; > } > > @@ -2038,7 +2038,7 @@ static int atom_get_turbo_pstate(int not_used) > { > u64 value; > > - rdmsrq(MSR_ATOM_CORE_TURBO_RATIOS, value); > + value = rdmsrq(MSR_ATOM_CORE_TURBO_RATIOS); > return value & 0x7F; > } > > @@ -2069,7 +2069,7 @@ static int silvermont_get_scaling(void) > static int silvermont_freq_table[] = { > 83300, 100000, 133300, 116700, 80000}; > > - rdmsrq(MSR_FSB_FREQ, value); > + value = rdmsrq(MSR_FSB_FREQ); > i = value & 0x7; > WARN_ON(i > 4); > > @@ -2085,7 +2085,7 @@ static int airmont_get_scaling(void) > 83300, 100000, 133300, 116700, 80000, > 93300, 90000, 88900, 87500}; > > - rdmsrq(MSR_FSB_FREQ, value); > + value = rdmsrq(MSR_FSB_FREQ); > i = value & 0xF; > WARN_ON(i > 8); > > @@ -2096,7 +2096,7 @@ static void atom_get_vid(struct cpudata *cpudata) > { > u64 value; > > - rdmsrq(MSR_ATOM_CORE_VIDS, value); > + value = rdmsrq(MSR_ATOM_CORE_VIDS); > cpudata->vid.min = int_tofp((value >> 8) & 0x7f); > cpudata->vid.max = int_tofp((value >> 16) & 0x7f); > cpudata->vid.ratio = div_fp( > @@ -2104,7 +2104,7 @@ static void atom_get_vid(struct cpudata *cpudata) > int_tofp(cpudata->pstate.max_pstate - > cpudata->pstate.min_pstate)); > > - rdmsrq(MSR_ATOM_CORE_TURBO_VIDS, value); > + value = rdmsrq(MSR_ATOM_CORE_TURBO_VIDS); > cpudata->vid.turbo = value & 0x7f; > } > > @@ -2452,8 +2452,8 @@ static inline bool intel_pstate_sample(struct cpudata *cpu, u64 time) > u64 tsc; > > local_irq_save(flags); > - rdmsrq(MSR_IA32_APERF, aperf); > - rdmsrq(MSR_IA32_MPERF, mperf); > + aperf = rdmsrq(MSR_IA32_APERF); > + mperf = rdmsrq(MSR_IA32_MPERF); > tsc = rdtsc(); > if (cpu->prev_mperf == mperf || cpu->prev_tsc == tsc) { > local_irq_restore(flags); > @@ -3642,7 +3642,7 @@ static bool __init intel_pstate_platform_pwr_mgmt_exists(void) > > id = x86_match_cpu(intel_pstate_cpu_oob_ids); > if (id) { > - rdmsrq(MSR_MISC_PWR_MGMT, misc_pwr); > + misc_pwr = rdmsrq(MSR_MISC_PWR_MGMT); > if (misc_pwr & BITMASK_OOB) { > pr_debug("Bit 8 or 18 in the MISC_PWR_MGMT MSR set\n"); > pr_debug("P states are controlled in Out of Band mode by the firmware/hardware\n"); > @@ -3698,7 +3698,7 @@ static bool intel_pstate_hwp_is_enabled(void) > { > u64 value; > > - rdmsrq(MSR_PM_ENABLE, value); > + value = rdmsrq(MSR_PM_ENABLE); > return !!(value & 0x1); > } > > diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c > index 4c2599264333..9bc0acc0ea69 100644 > --- a/drivers/cpufreq/longhaul.c > +++ b/drivers/cpufreq/longhaul.c > @@ -121,7 +121,7 @@ static int longhaul_get_cpu_mult(void) > unsigned long invalue = 0; > u64 val; > > - rdmsrq(MSR_IA32_EBL_CR_POWERON, val); > + val = rdmsrq(MSR_IA32_EBL_CR_POWERON); > invalue = (val & (1<<22|1<<23|1<<24|1<<25))>>22; > if (longhaul_version == TYPE_LONGHAUL_V2 || > longhaul_version == TYPE_POWERSAVER) { > @@ -137,7 +137,7 @@ static void do_longhaul1(unsigned int mults_index) > { > union msr_bcr2 bcr2; > > - rdmsrq(MSR_VIA_BCR2, bcr2.val); > + bcr2.val = rdmsrq(MSR_VIA_BCR2); > /* Enable software clock multiplier */ > bcr2.bits.ESOFTBF = 1; > bcr2.bits.CLOCKMUL = mults_index & 0xff; > @@ -152,7 +152,7 @@ static void do_longhaul1(unsigned int mults_index) > > /* Disable software clock multiplier */ > local_irq_disable(); > - rdmsrq(MSR_VIA_BCR2, bcr2.val); > + bcr2.val = rdmsrq(MSR_VIA_BCR2); > bcr2.bits.ESOFTBF = 0; > wrmsrq(MSR_VIA_BCR2, bcr2.val); > } > @@ -165,7 +165,7 @@ static void do_powersaver(int cx_address, unsigned int mults_index, > union msr_longhaul longhaul; > u32 t; > > - rdmsrq(MSR_VIA_LONGHAUL, longhaul.val); > + longhaul.val = rdmsrq(MSR_VIA_LONGHAUL); > /* Setup new frequency */ > if (!revid_errata) > longhaul.bits.RevisionKey = longhaul.bits.RevisionID; > @@ -534,7 +534,7 @@ static void longhaul_setup_voltagescaling(void) > unsigned int j, speed, pos, kHz_step, numvscales; > int min_vid_speed; > > - rdmsrq(MSR_VIA_LONGHAUL, longhaul.val); > + longhaul.val = rdmsrq(MSR_VIA_LONGHAUL); > if (!(longhaul.bits.RevisionID & 1)) { > pr_info("Voltage scaling not supported by CPU\n"); > return; > @@ -836,7 +836,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) > } > /* Check Longhaul ver. 2 */ > if (longhaul_version == TYPE_LONGHAUL_V2) { > - rdmsrq(MSR_VIA_LONGHAUL, val); > + val = rdmsrq(MSR_VIA_LONGHAUL); > if (val == 0) > /* Looks like MSR isn't present */ > longhaul_version = TYPE_LONGHAUL_V1; > diff --git a/drivers/cpufreq/longrun.c b/drivers/cpufreq/longrun.c > index 82a7bb69c401..4b7e624ae1e5 100644 > --- a/drivers/cpufreq/longrun.c > +++ b/drivers/cpufreq/longrun.c > @@ -37,14 +37,14 @@ static void longrun_get_policy(struct cpufreq_policy *policy) > { > struct msr msr; > > - rdmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); > + msr.q = rdmsrq(MSR_TMTA_LONGRUN_FLAGS); > pr_debug("longrun flags are %x - %x\n", msr.l, msr.h); > if (msr.l & 0x01) > policy->policy = CPUFREQ_POLICY_PERFORMANCE; > else > policy->policy = CPUFREQ_POLICY_POWERSAVE; > > - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); > + msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL); > pr_debug("longrun ctrl is %x - %x\n", msr.l, msr.h); > msr.l &= 0x0000007F; > msr.h &= 0x0000007F; > @@ -93,7 +93,7 @@ static int longrun_set_policy(struct cpufreq_policy *policy) > pctg_lo = pctg_hi; > > /* performance or economy mode */ > - rdmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); > + msr.q = rdmsrq(MSR_TMTA_LONGRUN_FLAGS); > msr.l &= 0xFFFFFFFE; > switch (policy->policy) { > case CPUFREQ_POLICY_PERFORMANCE: > @@ -105,7 +105,7 @@ static int longrun_set_policy(struct cpufreq_policy *policy) > wrmsrq(MSR_TMTA_LONGRUN_FLAGS, msr.q); > > /* lower and upper boundary */ > - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); > + msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL); > msr.l &= 0xFFFFFF80; > msr.h &= 0xFFFFFF80; > msr.l |= pctg_lo; > @@ -177,16 +177,16 @@ static int longrun_determine_freqs(unsigned int *low_freq, > * For maximum frequency, read out level zero. > */ > /* minimum */ > - rdmsrq(MSR_TMTA_LRTI_READOUT, msr.q); > + msr.q = rdmsrq(MSR_TMTA_LRTI_READOUT); > msr.l = msr.h; > wrmsrq(MSR_TMTA_LRTI_READOUT, msr.q); > - rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ, msr.q); > + msr.q = rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ); > *low_freq = msr.l * 1000; /* to kHz */ > > /* maximum */ > msr.l = 0; > wrmsrq(MSR_TMTA_LRTI_READOUT, msr.q); > - rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ, msr.q); > + msr.q = rdmsrq(MSR_TMTA_LRTI_VOLT_MHZ); > *high_freq = msr.l * 1000; /* to kHz */ > > pr_debug("longrun table interface told %u - %u kHz\n", > @@ -203,7 +203,7 @@ static int longrun_determine_freqs(unsigned int *low_freq, > pr_debug("high frequency is %u kHz\n", *high_freq); > > /* get current borders */ > - rdmsrq(MSR_TMTA_LONGRUN_CTRL, msr.q); > + msr.q = rdmsrq(MSR_TMTA_LONGRUN_CTRL); > save.l = msr.l & 0x0000007F; > save.h = msr.h & 0x0000007F; > > diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.c > index 6a930d7e6a5c..1df2a8f365a3 100644 > --- a/drivers/cpufreq/powernow-k7.c > +++ b/drivers/cpufreq/powernow-k7.c > @@ -220,7 +220,7 @@ static void change_FID(int fid) > { > union msr_fidvidctl fidvidctl; > > - rdmsrq(MSR_K7_FID_VID_CTL, fidvidctl.val); > + fidvidctl.val = rdmsrq(MSR_K7_FID_VID_CTL); > if (fidvidctl.bits.FID != fid) { > fidvidctl.bits.SGTC = latency; > fidvidctl.bits.FID = fid; > @@ -235,7 +235,7 @@ static void change_VID(int vid) > { > union msr_fidvidctl fidvidctl; > > - rdmsrq(MSR_K7_FID_VID_CTL, fidvidctl.val); > + fidvidctl.val = rdmsrq(MSR_K7_FID_VID_CTL); > if (fidvidctl.bits.VID != vid) { > fidvidctl.bits.SGTC = latency; > fidvidctl.bits.VID = vid; > @@ -261,7 +261,7 @@ static int powernow_target(struct cpufreq_policy *policy, unsigned int index) > fid = powernow_table[index].driver_data & 0xFF; > vid = (powernow_table[index].driver_data & 0xFF00) >> 8; > > - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); > + fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS); > cfid = fidvidstatus.bits.CFID; > freqs.old = fsb * fid_codes[cfid] / 10; > > @@ -558,7 +558,7 @@ static unsigned int powernow_get(unsigned int cpu) > > if (cpu) > return 0; > - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); > + fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS); > cfid = fidvidstatus.bits.CFID; > > return fsb * fid_codes[cfid] / 10; > @@ -599,7 +599,7 @@ static int powernow_cpu_init(struct cpufreq_policy *policy) > if (policy->cpu != 0) > return -ENODEV; > > - rdmsrq(MSR_K7_FID_VID_STATUS, fidvidstatus.val); > + fidvidstatus.val = rdmsrq(MSR_K7_FID_VID_STATUS); > > recalibrate_cpu_khz(); > > diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c > index c9bcc6f0ab7b..6097dc3e5a89 100644 > --- a/drivers/cpufreq/powernow-k8.c > +++ b/drivers/cpufreq/powernow-k8.c > @@ -89,7 +89,7 @@ static int pending_bit_stuck(void) > { > u64 msr; > > - rdmsrq(MSR_FIDVID_STATUS, msr); > + msr = rdmsrq(MSR_FIDVID_STATUS); > return msr & MSR_S_LO_CHANGE_PENDING ? 1 : 0; > } > > @@ -107,7 +107,7 @@ static int query_current_values_with_pending_wait(struct powernow_k8_data *data) > pr_debug("detected change pending stuck\n"); > return 1; > } > - rdmsrq(MSR_FIDVID_STATUS, msr.q); > + msr.q = rdmsrq(MSR_FIDVID_STATUS); > } while (msr.l & MSR_S_LO_CHANGE_PENDING); > > data->currvid = msr.h & MSR_S_HI_CURRENT_VID; > @@ -134,7 +134,7 @@ static void fidvid_msr_init(void) > struct msr msr; > u8 fid, vid; > > - rdmsrq(MSR_FIDVID_STATUS, msr.q); > + msr.q = rdmsrq(MSR_FIDVID_STATUS); > vid = msr.h & MSR_S_HI_CURRENT_VID; > fid = msr.l & MSR_S_LO_CURRENT_FID; > msr.l = fid | (vid << MSR_C_LO_VID_SHIFT); > @@ -293,7 +293,7 @@ static int core_voltage_pre_transition(struct powernow_k8_data *data, > if ((savefid < LO_FID_TABLE_TOP) && (reqfid < LO_FID_TABLE_TOP)) > rvomult = 2; > rvosteps *= rvomult; > - rdmsrq(MSR_FIDVID_STATUS, msr.q); > + msr.q = rdmsrq(MSR_FIDVID_STATUS); > maxvid = 0x1f & (msr.h >> 16); > pr_debug("ph1 maxvid=0x%x\n", maxvid); > if (reqvid < maxvid) /* lower numbers are higher voltages */ > diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speedstep-centrino.c > index de50fb367c6b..2e90b658bfc2 100644 > --- a/drivers/cpufreq/speedstep-centrino.c > +++ b/drivers/cpufreq/speedstep-centrino.c > @@ -378,7 +378,7 @@ static int centrino_cpu_init(struct cpufreq_policy *policy) > > /* Check to see if Enhanced SpeedStep is enabled, and try to > enable it if not. */ > - rdmsrq(MSR_IA32_MISC_ENABLE, q); > + q = rdmsrq(MSR_IA32_MISC_ENABLE); > > if (!(q & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { > q |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP; > @@ -386,7 +386,7 @@ static int centrino_cpu_init(struct cpufreq_policy *policy) > wrmsrq(MSR_IA32_MISC_ENABLE, q); > > /* check to see if it stuck */ > - rdmsrq(MSR_IA32_MISC_ENABLE, q); > + q = rdmsrq(MSR_IA32_MISC_ENABLE); > if (!(q & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) { > pr_info("couldn't enable Enhanced SpeedStep\n"); > return -ENODEV; > diff --git a/drivers/cpufreq/speedstep-lib.c b/drivers/cpufreq/speedstep-lib.c > index 2afc3f177a29..188d459c7e2a 100644 > --- a/drivers/cpufreq/speedstep-lib.c > +++ b/drivers/cpufreq/speedstep-lib.c > @@ -74,7 +74,7 @@ static unsigned int pentium3_get_frequency(enum speedstep_processor processor) > int i = 0, j = 0; > > /* read MSR 0x2a - we only need the low 32 bits */ > - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); > + msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON); > pr_debug("P3 - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.h); > msr_tmp = msr_lo = msr.l; > > @@ -112,7 +112,7 @@ static unsigned int pentiumM_get_frequency(void) > struct msr msr; > u32 msr_tmp; > > - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); > + msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON); > pr_debug("PM - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", msr.l, msr.h); > > /* see table B-2 of 24547212.pdf */ > @@ -136,7 +136,7 @@ static unsigned int pentium_core_get_frequency(void) > u32 msr_tmp; > int ret; > > - rdmsrq(MSR_FSB_FREQ, msr.q); > + msr.q = rdmsrq(MSR_FSB_FREQ); > /* see table B-2 of 25366920.pdf */ > switch (msr.l & 0x07) { > case 5: > @@ -161,7 +161,7 @@ static unsigned int pentium_core_get_frequency(void) > pr_err("PCORE - MSR_FSB_FREQ undefined value\n"); > } > > - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); > + msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON); > pr_debug("PCORE - MSR_IA32_EBL_CR_POWERON: 0x%x 0x%x\n", > msr.l, msr.h); > > @@ -191,7 +191,7 @@ static unsigned int pentium4_get_frequency(void) > if (c->x86_model < 2) > return cpu_khz; > > - rdmsrq(0x2c, msr.q); > + msr.q = rdmsrq(0x2c); > > pr_debug("P4 - MSR_EBC_FREQUENCY_ID: 0x%x 0x%x\n", msr.l, msr.h); > > @@ -348,7 +348,7 @@ enum speedstep_processor speedstep_detect_processor(void) > > /* all mobile PIII Coppermines have FSB 100 MHz > * ==> sort out a few desktop PIIIs. */ > - rdmsrq(MSR_IA32_EBL_CR_POWERON, msr.q); > + msr.q = rdmsrq(MSR_IA32_EBL_CR_POWERON); > pr_debug("Coppermine: MSR_IA32_EBL_CR_POWERON is 0x%x, 0x%x\n", > msr.l, msr.h); > msr.l &= 0x00c0000; > @@ -361,7 +361,7 @@ enum speedstep_processor speedstep_detect_processor(void) > * it has SpeedStep technology if either > * bit 56 or 57 is set > */ > - rdmsrq(MSR_IA32_PLATFORM_ID, msr.q); > + msr.q = rdmsrq(MSR_IA32_PLATFORM_ID); > pr_debug("Coppermine: MSR_IA32_PLATFORM ID is 0x%x, 0x%x\n", > msr.l, msr.h); > if ((msr.h & (1<<18)) && > diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c > index 475235c402e8..40317ab69461 100644 > --- a/drivers/edac/amd64_edac.c > +++ b/drivers/edac/amd64_edac.c > @@ -2956,13 +2956,13 @@ static void dct_read_mc_regs(struct amd64_pvt *pvt) > * Retrieve TOP_MEM and TOP_MEM2; no masking off of reserved bits since > * those are Read-As-Zero. > */ > - rdmsrq(MSR_K8_TOP_MEM1, pvt->top_mem); > + pvt->top_mem = rdmsrq(MSR_K8_TOP_MEM1); > edac_dbg(0, " TOP_MEM: 0x%016llx\n", pvt->top_mem); > > /* Check first whether TOP_MEM2 is enabled: */ > - rdmsrq(MSR_AMD64_SYSCFG, msr_val); > + msr_val = rdmsrq(MSR_AMD64_SYSCFG); > if (msr_val & BIT(21)) { > - rdmsrq(MSR_K8_TOP_MEM2, pvt->top_mem2); > + pvt->top_mem2 = rdmsrq(MSR_K8_TOP_MEM2); > edac_dbg(0, " TOP_MEM2: 0x%016llx\n", pvt->top_mem2); > } else { > edac_dbg(0, " TOP_MEM2 disabled\n"); > diff --git a/drivers/gpio/gpio-cs5535.c b/drivers/gpio/gpio-cs5535.c > index a97ec7561889..e9cc577e94b7 100644 > --- a/drivers/gpio/gpio-cs5535.c > +++ b/drivers/gpio/gpio-cs5535.c > @@ -148,7 +148,7 @@ int cs5535_gpio_set_irq(unsigned group, unsigned irq) > if (group > 7 || irq > 15) > return -EINVAL; > > - rdmsrq(MSR_PIC_ZSEL_HIGH, val.q); > + val.q = rdmsrq(MSR_PIC_ZSEL_HIGH); > > val.l &= ~(0xF << (group * 4)); > val.l |= (irq & 0xF) << (group * 4); > diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c > index 6e3c11c68171..f678eda1641c 100644 > --- a/drivers/hv/mshv_vtl_main.c > +++ b/drivers/hv/mshv_vtl_main.c > @@ -599,7 +599,7 @@ static int mshv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set) > if (set) > wrmsrq(reg_table[i].msr_addr, *reg64); > else > - rdmsrq(reg_table[i].msr_addr, *reg64); > + *reg64 = rdmsrq(reg_table[i].msr_addr); > } > return 0; > } > diff --git a/drivers/hwmon/hwmon-vid.c b/drivers/hwmon/hwmon-vid.c > index dee42c163d92..cfb3a2975de4 100644 > --- a/drivers/hwmon/hwmon-vid.c > +++ b/drivers/hwmon/hwmon-vid.c > @@ -243,10 +243,10 @@ static u8 get_via_model_d_vrm(void) > "C7-M", "C7", "Eden", "C7-D" > }; > > - rdmsrq(0x198, msr); > + msr = rdmsrq(0x198); > vid = (msr >> 32) & 0xff; > > - rdmsrq(0x1154, msr); > + msr = rdmsrq(0x1154); > brand = ((msr >> 4) ^ (msr >> 2)) & 0x03; > > if (vid > 0x3f) { > diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c > index 651408df9c24..82faaf771b2d 100644 > --- a/drivers/idle/intel_idle.c > +++ b/drivers/idle/intel_idle.c > @@ -2125,35 +2125,35 @@ static void __init bxt_idle_state_table_update(void) > unsigned long long msr; > unsigned int usec; > > - rdmsrq(MSR_PKGC6_IRTL, msr); > + msr = rdmsrq(MSR_PKGC6_IRTL); > usec = irtl_2_usec(msr); > if (usec) { > bxt_cstates[2].exit_latency = usec; > bxt_cstates[2].target_residency = usec; > } > > - rdmsrq(MSR_PKGC7_IRTL, msr); > + msr = rdmsrq(MSR_PKGC7_IRTL); > usec = irtl_2_usec(msr); > if (usec) { > bxt_cstates[3].exit_latency = usec; > bxt_cstates[3].target_residency = usec; > } > > - rdmsrq(MSR_PKGC8_IRTL, msr); > + msr = rdmsrq(MSR_PKGC8_IRTL); > usec = irtl_2_usec(msr); > if (usec) { > bxt_cstates[4].exit_latency = usec; > bxt_cstates[4].target_residency = usec; > } > > - rdmsrq(MSR_PKGC9_IRTL, msr); > + msr = rdmsrq(MSR_PKGC9_IRTL); > usec = irtl_2_usec(msr); > if (usec) { > bxt_cstates[5].exit_latency = usec; > bxt_cstates[5].target_residency = usec; > } > > - rdmsrq(MSR_PKGC10_IRTL, msr); > + msr = rdmsrq(MSR_PKGC10_IRTL); > usec = irtl_2_usec(msr); > if (usec) { > bxt_cstates[6].exit_latency = usec; > @@ -2181,7 +2181,7 @@ static void __init sklh_idle_state_table_update(void) > if ((mwait_substates & (0xF << 28)) == 0) > return; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr); > + msr = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > > /* PC10 is not enabled in PKG C-state limit */ > if ((msr & 0xF) != 8) > @@ -2193,7 +2193,7 @@ static void __init sklh_idle_state_table_update(void) > /* if SGX is present */ > if (ebx & (1 << 2)) { > > - rdmsrq(MSR_IA32_FEAT_CTL, msr); > + msr = rdmsrq(MSR_IA32_FEAT_CTL); > > /* if SGX is enabled */ > if (msr & (1 << 18)) > @@ -2213,7 +2213,7 @@ static bool __init skx_is_pc6_disabled(void) > { > u64 msr; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr); > + msr = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > > /* > * 000b: C0/C1 (no package C-state support) > @@ -2467,7 +2467,7 @@ static void auto_demotion_disable(void) > { > unsigned long long msr_bits; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_bits); > + msr_bits = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > msr_bits &= ~auto_demotion_disable_flags; > wrmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_bits); > } > @@ -2476,7 +2476,7 @@ static void c1e_promotion_enable(void) > { > unsigned long long msr_bits; > > - rdmsrq(MSR_IA32_POWER_CTL, msr_bits); > + msr_bits = rdmsrq(MSR_IA32_POWER_CTL); > msr_bits |= 0x2; > wrmsrq(MSR_IA32_POWER_CTL, msr_bits); > } > @@ -2485,7 +2485,7 @@ static void c1e_promotion_disable(void) > { > unsigned long long msr_bits; > > - rdmsrq(MSR_IA32_POWER_CTL, msr_bits); > + msr_bits = rdmsrq(MSR_IA32_POWER_CTL); > msr_bits &= ~0x2; > wrmsrq(MSR_IA32_POWER_CTL, msr_bits); > } > @@ -2554,7 +2554,7 @@ static void intel_c1_demotion_toggle(void *enable) > { > unsigned long long msr_val; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_val); > + msr_val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > /* > * Enable/disable C1 undemotion along with C1 demotion, as this is the > * most sensible configuration in general. > @@ -2594,7 +2594,7 @@ static ssize_t intel_c1_demotion_show(struct device *dev, > * Read the MSR value for a CPU and assume it is the same for all CPUs. Any other > * configuration would be a BIOS bug. > */ > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, msr_val); > + msr_val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > return sysfs_emit(buf, "%d\n", !!(msr_val & NHM_C1_AUTO_DEMOTE)); > } > static DEVICE_ATTR_RW(intel_c1_demotion); > diff --git a/drivers/misc/cs5535-mfgpt.c b/drivers/misc/cs5535-mfgpt.c > index 9abfc44f70f4..9006b59858ff 100644 > --- a/drivers/misc/cs5535-mfgpt.c > +++ b/drivers/misc/cs5535-mfgpt.c > @@ -83,7 +83,7 @@ int cs5535_mfgpt_toggle_event(struct cs5535_mfgpt_timer *timer, int cmp, > return -EIO; > } > > - rdmsrq(msr, val.q); > + val.q = rdmsrq(msr); > > if (enable) > val.l |= mask; > @@ -114,7 +114,7 @@ int cs5535_mfgpt_set_irq(struct cs5535_mfgpt_timer *timer, int cmp, int *irq, > * IRQ of the 1st. This can only happen if forcing an IRQ, calling this > * with *irq==0 is safe. Currently there _are_ no 2 drivers. > */ > - rdmsrq(MSR_PIC_ZSEL_LOW, zsel.q); > + zsel.q = rdmsrq(MSR_PIC_ZSEL_LOW); > shift = ((cmp == MFGPT_CMP1 ? 0 : 4) + timer->nr % 4) * 4; > if (((zsel.l >> shift) & 0xF) == 2) > return -EIO; > @@ -128,7 +128,7 @@ int cs5535_mfgpt_set_irq(struct cs5535_mfgpt_timer *timer, int cmp, int *irq, > /* Can't use IRQ if it's 0 (=disabled), 2, or routed to LPC */ > if (*irq < 1 || *irq == 2 || *irq > 15) > return -EIO; > - rdmsrq(MSR_PIC_IRQM_LPC, lpc.q); > + lpc.q = rdmsrq(MSR_PIC_IRQM_LPC); > if (lpc.l & (1 << *irq)) > return -EIO; > > diff --git a/drivers/mtd/nand/raw/cs553x_nand.c b/drivers/mtd/nand/raw/cs553x_nand.c > index 0b872b1e3b04..2ed13666b48f 100644 > --- a/drivers/mtd/nand/raw/cs553x_nand.c > +++ b/drivers/mtd/nand/raw/cs553x_nand.c > @@ -351,20 +351,20 @@ static int __init cs553x_init(void) > return -ENXIO; > > /* If it doesn't have the CS553[56], abort */ > - rdmsrq(MSR_DIVIL_GLD_CAP, val); > + val = rdmsrq(MSR_DIVIL_GLD_CAP); > val &= ~0xFFULL; > if (val != CAP_CS5535 && val != CAP_CS5536) > return -ENXIO; > > /* If it doesn't have the NAND controller enabled, abort */ > - rdmsrq(MSR_DIVIL_BALL_OPTS, val); > + val = rdmsrq(MSR_DIVIL_BALL_OPTS); > if (val & PIN_OPT_IDE) { > pr_info("CS553x NAND controller: Flash I/O not enabled in MSR_DIVIL_BALL_OPTS.\n"); > return -ENXIO; > } > > for (i = 0; i < NR_CS553X_CONTROLLERS; i++) { > - rdmsrq(MSR_DIVIL_LBAR_FLSH0 + i, val); > + val = rdmsrq(MSR_DIVIL_LBAR_FLSH0 + i); > > if ((val & (FLSH_LBAR_EN|FLSH_NOR_NAND)) == (FLSH_LBAR_EN|FLSH_NOR_NAND)) > err = cs553x_init_one(i, !!(val & FLSH_MEM_IO), val & 0xFFFFFFFF); > diff --git a/drivers/platform/x86/intel/ifs/load.c b/drivers/platform/x86/intel/ifs/load.c > index 50f1fdf7dfed..6320a0e45d38 100644 > --- a/drivers/platform/x86/intel/ifs/load.c > +++ b/drivers/platform/x86/intel/ifs/load.c > @@ -129,7 +129,7 @@ static void copy_hashes_authenticate_chunks(struct work_struct *work) > msrs = ifs_get_test_msrs(dev); > /* run scan hash copy */ > wrmsrq(msrs->copy_hashes, ifs_hash_ptr); > - rdmsrq(msrs->copy_hashes_status, hashes_status.data); > + hashes_status.data = rdmsrq(msrs->copy_hashes_status); > > /* enumerate the scan image information */ > num_chunks = hashes_status.num_chunks; > @@ -151,7 +151,7 @@ static void copy_hashes_authenticate_chunks(struct work_struct *work) > linear_addr |= i; > > wrmsrq(msrs->copy_chunks, linear_addr); > - rdmsrq(msrs->copy_chunks_status, chunk_status.data); > + chunk_status.data = rdmsrq(msrs->copy_chunks_status); > > ifsd->valid_chunks = chunk_status.valid_chunks; > err_code = chunk_status.error_code; > @@ -197,7 +197,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev) > > if (need_copy_scan_hashes(ifsd)) { > wrmsrq(msrs->copy_hashes, ifs_hash_ptr); > - rdmsrq(msrs->copy_hashes_status, hashes_status.data); > + hashes_status.data = rdmsrq(msrs->copy_hashes_status); > > /* enumerate the scan image information */ > chunk_size = hashes_status.chunk_size * SZ_1K; > @@ -218,7 +218,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev) > > if (ifsd->generation >= IFS_GEN_STRIDE_AWARE) { > wrmsrq(msrs->test_ctrl, INVALIDATE_STRIDE); > - rdmsrq(msrs->copy_chunks_status, chunk_status.data); > + chunk_status.data = rdmsrq(msrs->copy_chunks_status); > if (chunk_status.valid_chunks != 0) { > dev_err(dev, "Couldn't invalidate installed stride - %d\n", > chunk_status.valid_chunks); > @@ -241,7 +241,7 @@ static int copy_hashes_authenticate_chunks_gen2(struct device *dev) > local_irq_disable(); > wrmsrq(msrs->copy_chunks, (u64)chunk_table); > local_irq_enable(); > - rdmsrq(msrs->copy_chunks_status, chunk_status.data); > + chunk_status.data = rdmsrq(msrs->copy_chunks_status); > err_code = chunk_status.error_code; > } while (err_code == AUTH_INTERRUPTED_ERROR && --retry_count); > > diff --git a/drivers/platform/x86/intel/ifs/runtest.c b/drivers/platform/x86/intel/ifs/runtest.c > index dfc119d7354d..46e1ea944ce7 100644 > --- a/drivers/platform/x86/intel/ifs/runtest.c > +++ b/drivers/platform/x86/intel/ifs/runtest.c > @@ -211,7 +211,7 @@ static int doscan(void *data) > * are processed in a single pass) before it retires. > */ > wrmsrq(MSR_ACTIVATE_SCAN, params->activate->data); > - rdmsrq(MSR_SCAN_STATUS, status.data); > + status.data = rdmsrq(MSR_SCAN_STATUS); > > trace_ifs_status(ifsd->cur_batch, start, stop, status.data); > > @@ -324,7 +324,7 @@ static int do_array_test(void *data) > if (cpu == first) { > wrmsrq(MSR_ARRAY_BIST, command->data); > /* Pass back the result of the test */ > - rdmsrq(MSR_ARRAY_BIST, command->data); > + command->data = rdmsrq(MSR_ARRAY_BIST); > } > > return 0; > @@ -376,7 +376,7 @@ static int do_array_test_gen1(void *status) > > if (cpu == first) { > wrmsrq(MSR_ARRAY_TRIGGER, ARRAY_GEN1_TEST_ALL_ARRAYS); > - rdmsrq(MSR_ARRAY_STATUS, *((u64 *)status)); > + *((u64 *)status) = rdmsrq(MSR_ARRAY_STATUS); > } > > return 0; > @@ -528,7 +528,7 @@ static int dosbaf(void *data) > * during the "execution" of the WRMSR. > */ > wrmsrq(MSR_ACTIVATE_SBAF, run_params->activate->data); > - rdmsrq(MSR_SBAF_STATUS, status.data); > + status.data = rdmsrq(MSR_SBAF_STATUS); > trace_ifs_sbaf(ifsd->cur_batch, *run_params->activate, status); > > /* Pass back the result of the test */ > diff --git a/drivers/platform/x86/intel/pmc/cnp.c b/drivers/platform/x86/intel/pmc/cnp.c > index efea4e1ba52b..44979e680361 100644 > --- a/drivers/platform/x86/intel/pmc/cnp.c > +++ b/drivers/platform/x86/intel/pmc/cnp.c > @@ -228,7 +228,7 @@ static void disable_c1_auto_demote(void *unused) > int cpunum = smp_processor_id(); > u64 val; > > - rdmsrq(MSR_PKG_CST_CONFIG_CONTROL, val); > + val = rdmsrq(MSR_PKG_CST_CONFIG_CONTROL); > per_cpu(pkg_cst_config, cpunum) = val; > val &= ~NHM_C1_AUTO_DEMOTE; > wrmsrq(MSR_PKG_CST_CONFIG_CONTROL, val); > diff --git a/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c b/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c > index 22745b217c6f..909c9e25112d 100644 > --- a/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c > +++ b/drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c > @@ -40,7 +40,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter, > /* Poll for rb bit == 0 */ > retries = OS_MAILBOX_RETRY_COUNT; > do { > - rdmsrq(MSR_OS_MAILBOX_INTERFACE, data); > + data = rdmsrq(MSR_OS_MAILBOX_INTERFACE); > if (data & BIT_ULL(MSR_OS_MAILBOX_BUSY_BIT)) { > ret = -EBUSY; > continue; > @@ -65,7 +65,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter, > /* Poll for rb bit == 0 */ > retries = OS_MAILBOX_RETRY_COUNT; > do { > - rdmsrq(MSR_OS_MAILBOX_INTERFACE, data); > + data = rdmsrq(MSR_OS_MAILBOX_INTERFACE); > if (data & BIT_ULL(MSR_OS_MAILBOX_BUSY_BIT)) { > ret = -EBUSY; > continue; > @@ -75,7 +75,7 @@ static int isst_if_send_mbox_cmd(u8 command, u8 sub_command, u32 parameter, > return -ENXIO; > > if (response_data) { > - rdmsrq(MSR_OS_MAILBOX_DATA, data); > + data = rdmsrq(MSR_OS_MAILBOX_DATA); > *response_data = data; > } > ret = 0; > diff --git a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c > index bb0d0b8fc54a..57262a6afe8c 100644 > --- a/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c > +++ b/drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c > @@ -568,7 +568,7 @@ static bool disable_dynamic_sst_features(void) > if (!cpu_feature_enabled(X86_FEATURE_HWP)) > return true; > > - rdmsrq(MSR_PM_ENABLE, value); > + value = rdmsrq(MSR_PM_ENABLE); > return !(value & 0x1); > } > > diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c > index b1b2d9caba7b..79c07f23ba0b 100644 > --- a/drivers/platform/x86/intel_ips.c > +++ b/drivers/platform/x86/intel_ips.c > @@ -370,7 +370,7 @@ static void ips_cpu_raise(struct ips_driver *ips) > if (!ips->cpu_turbo_enabled) > return; > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > + turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT); > > cur_tdp_limit = turbo_override & TURBO_TDP_MASK; > new_tdp_limit = cur_tdp_limit + 8; /* 1W increase */ > @@ -405,7 +405,7 @@ static void ips_cpu_lower(struct ips_driver *ips) > u64 turbo_override; > u16 cur_limit, new_limit; > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > + turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT); > > cur_limit = turbo_override & TURBO_TDP_MASK; > new_limit = cur_limit - 8; /* 1W decrease */ > @@ -437,7 +437,7 @@ static void do_enable_cpu_turbo(void *data) > { > u64 perf_ctl; > > - rdmsrq(IA32_PERF_CTL, perf_ctl); > + perf_ctl = rdmsrq(IA32_PERF_CTL); > if (perf_ctl & IA32_PERF_TURBO_DIS) { > perf_ctl &= ~IA32_PERF_TURBO_DIS; > wrmsrq(IA32_PERF_CTL, perf_ctl); > @@ -475,7 +475,7 @@ static void do_disable_cpu_turbo(void *data) > { > u64 perf_ctl; > > - rdmsrq(IA32_PERF_CTL, perf_ctl); > + perf_ctl = rdmsrq(IA32_PERF_CTL); > if (!(perf_ctl & IA32_PERF_TURBO_DIS)) { > perf_ctl |= IA32_PERF_TURBO_DIS; > wrmsrq(IA32_PERF_CTL, perf_ctl); > @@ -1215,7 +1215,7 @@ static int cpu_clamp_show(struct seq_file *m, void *data) > u64 turbo_override; > int tdp, tdc; > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > + turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT); > > tdp = (int)(turbo_override & TURBO_TDP_MASK); > tdc = (int)((turbo_override & TURBO_TDC_MASK) >> TURBO_TDC_SHIFT); > @@ -1290,7 +1290,7 @@ static struct ips_mcp_limits *ips_detect_cpu(struct ips_driver *ips) > return NULL; > } > > - rdmsrq(IA32_MISC_ENABLE, misc_en); > + misc_en = rdmsrq(IA32_MISC_ENABLE); > /* > * If the turbo enable bit isn't set, we shouldn't try to enable/disable > * turbo manually or we'll get an illegal MSR access, even though > @@ -1312,7 +1312,7 @@ static struct ips_mcp_limits *ips_detect_cpu(struct ips_driver *ips) > return NULL; > } > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_power); > + turbo_power = rdmsrq(TURBO_POWER_CURRENT_LIMIT); > tdp = turbo_power & TURBO_TDP_MASK; > > /* Sanity check TDP against CPU */ > @@ -1496,7 +1496,7 @@ static int ips_probe(struct pci_dev *dev, const struct pci_device_id *id) > * Check PLATFORM_INFO MSR to make sure this chip is > * turbo capable. > */ > - rdmsrq(PLATFORM_INFO, platform_info); > + platform_info = rdmsrq(PLATFORM_INFO); > if (!(platform_info & PLATFORM_TDP)) { > dev_err(&dev->dev, "platform indicates TDP override unavailable, aborting\n"); > return -ENODEV; > @@ -1529,7 +1529,7 @@ static int ips_probe(struct pci_dev *dev, const struct pci_device_id *id) > ips->mgta_val = thm_readw(THM_MGTA); > > /* Save turbo limits & ratios */ > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, ips->orig_turbo_limit); > + ips->orig_turbo_limit = rdmsrq(TURBO_POWER_CURRENT_LIMIT); > > ips_disable_cpu_turbo(ips); > ips->cpu_turbo_enabled = false; > @@ -1596,7 +1596,7 @@ static void ips_remove(struct pci_dev *dev) > if (ips->gpu_turbo_disable) > symbol_put(i915_gpu_turbo_disable); > > - rdmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > + turbo_override = rdmsrq(TURBO_POWER_CURRENT_LIMIT); > turbo_override &= ~(TURBO_TDC_OVR_EN | TURBO_TDP_OVR_EN); > wrmsrq(TURBO_POWER_CURRENT_LIMIT, turbo_override); > wrmsrq(TURBO_POWER_CURRENT_LIMIT, ips->orig_turbo_limit); > diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rapl_msr.c > index a34543e66446..5d840de67c2b 100644 > --- a/drivers/powercap/intel_rapl_msr.c > +++ b/drivers/powercap/intel_rapl_msr.c > @@ -176,7 +176,7 @@ static int rapl_msr_read_raw(int cpu, struct reg_action *ra, bool pmu_ctx) > * from any CPU in the package. > */ > if (pmu_ctx) { > - rdmsrq(ra->reg.msr, ra->value); > + ra->value = rdmsrq(ra->reg.msr); > goto out; > } > > diff --git a/drivers/thermal/intel/intel_hfi.c b/drivers/thermal/intel/intel_hfi.c > index 3273b8fe3d4d..6b2801aaa745 100644 > --- a/drivers/thermal/intel/intel_hfi.c > +++ b/drivers/thermal/intel/intel_hfi.c > @@ -285,7 +285,7 @@ void intel_hfi_process_event(__u64 pkg_therm_status_msr_val) > if (!raw_spin_trylock(&hfi_instance->event_lock)) > return; > > - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr); > + msr = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); > hfi = msr & PACKAGE_THERM_STATUS_HFI_UPDATED; > if (!hfi) { > raw_spin_unlock(&hfi_instance->event_lock); > @@ -357,7 +357,7 @@ static void hfi_enable(void) > { > u64 msr_val; > > - rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); > + msr_val = rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG); > msr_val |= HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT; > wrmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); > } > @@ -378,7 +378,7 @@ static void hfi_disable(void) > u64 msr_val; > int i; > > - rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); > + msr_val = rdmsrq(MSR_IA32_HW_FEEDBACK_CONFIG); > msr_val &= ~HW_FEEDBACK_CONFIG_HFI_ENABLE_BIT; > wrmsrq(MSR_IA32_HW_FEEDBACK_CONFIG, msr_val); > > @@ -389,7 +389,7 @@ static void hfi_disable(void) > * memory. > */ > for (i = 0; i < 2000; i++) { > - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); > + msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); > if (msr_val & PACKAGE_THERM_STATUS_HFI_UPDATED) > break; > > diff --git a/drivers/thermal/intel/therm_throt.c b/drivers/thermal/intel/therm_throt.c > index 4d4e81601d17..3ead57f45510 100644 > --- a/drivers/thermal/intel/therm_throt.c > +++ b/drivers/thermal/intel/therm_throt.c > @@ -297,7 +297,7 @@ static void get_therm_status(int level, bool *proc_hot, u8 *temp) > else > msr = MSR_IA32_PACKAGE_THERM_STATUS; > > - rdmsrq(msr, msr_val); > + msr_val = rdmsrq(msr); > if (msr_val & THERM_STATUS_PROCHOT_LOG) > *proc_hot = true; > else > @@ -543,7 +543,7 @@ static int check_directed_thermal_pkg_intr_ack(void) > * Wait 15ms to be safe. > */ > do { > - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); > + msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); > udelay(1); > } while (!(msr_val & PACKAGE_THERM_STATUS_DPTI_ACK) && --count); > > @@ -561,7 +561,7 @@ static void config_directed_thermal_pkg_intr(void *info) > bool enable = *((bool *)info); > u64 msr_val; > > - rdmsrq(MSR_IA32_THERM_INTERRUPT, msr_val); > + msr_val = rdmsrq(MSR_IA32_THERM_INTERRUPT); > > if (enable) > msr_val |= THERM_INT_DPTI_ENABLE; > @@ -931,7 +931,7 @@ void intel_thermal_interrupt(void) > if (cpu_feature_enabled(X86_FEATURE_HWP)) > notify_hwp_interrupt(); > > - rdmsrq(MSR_IA32_THERM_STATUS, msr_val); > + msr_val = rdmsrq(MSR_IA32_THERM_STATUS); > > /* Check for violation of core thermal thresholds*/ > notify_thresholds(msr_val); > @@ -946,7 +946,7 @@ void intel_thermal_interrupt(void) > CORE_LEVEL); > > if (this_cpu_has(X86_FEATURE_PTS)) { > - rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS, msr_val); > + msr_val = rdmsrq(MSR_IA32_PACKAGE_THERM_STATUS); > /* check violations of package thermal thresholds */ > notify_package_thresholds(msr_val); > therm_throt_process(msr_val & PACKAGE_THERM_STATUS_PROCHOT, > @@ -1004,7 +1004,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > * be some SMM goo which handles it, so we can't even put a handler > * since it might be delivered via SMI already: > */ > - rdmsrq(MSR_IA32_MISC_ENABLE, val.q); > + val.q = rdmsrq(MSR_IA32_MISC_ENABLE); > > val.h = lvtthmr_init; > /* > @@ -1030,7 +1030,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > /* early Pentium M models use different method for enabling TM2 */ > if (cpu_has(c, X86_FEATURE_TM2)) { > if (c->x86 == 6 && (c->x86_model == 9 || c->x86_model == 13)) { > - rdmsrq(MSR_THERM2_CTL, val.q); > + val.q = rdmsrq(MSR_THERM2_CTL); > if (val.l & MSR_THERM2_CTL_TM_SELECT) > tm2 = 1; > } else if (val.l & MSR_IA32_MISC_ENABLE_TM2) > @@ -1044,7 +1044,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > thermal_intr_init_core_clear_mask(); > thermal_intr_init_pkg_clear_mask(); > > - rdmsrq(MSR_IA32_THERM_INTERRUPT, val.q); > + val.q = rdmsrq(MSR_IA32_THERM_INTERRUPT); > if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable) { > val.l |= THERM_INT_LOW_ENABLE | THERM_INT_HIGH_ENABLE; > val.l &= ~THERM_INT_PLN_ENABLE; > @@ -1056,7 +1056,7 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > wrmsrq(MSR_IA32_THERM_INTERRUPT, val.q); > > if (cpu_has(c, X86_FEATURE_PTS)) { > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > + val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); > if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable) { > val.l |= PACKAGE_THERM_INT_LOW_ENABLE | > PACKAGE_THERM_INT_HIGH_ENABLE; > @@ -1071,13 +1071,13 @@ void intel_init_thermal(struct cpuinfo_x86 *c) > wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > > if (cpu_has(c, X86_FEATURE_HFI)) { > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > + val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); > wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, > val.q | PACKAGE_THERM_INT_HFI_ENABLE); > } > } > > - rdmsrq(MSR_IA32_MISC_ENABLE, val.q); > + val.q = rdmsrq(MSR_IA32_MISC_ENABLE); > wrmsrq(MSR_IA32_MISC_ENABLE, val.q | MSR_IA32_MISC_ENABLE_TM1); > > pr_info_once("CPU0: Thermal monitoring enabled (%s)\n", > diff --git a/drivers/thermal/intel/x86_pkg_temp_thermal.c b/drivers/thermal/intel/x86_pkg_temp_thermal.c > index 43fd5bdf1d8d..11ca647802dc 100644 > --- a/drivers/thermal/intel/x86_pkg_temp_thermal.c > +++ b/drivers/thermal/intel/x86_pkg_temp_thermal.c > @@ -187,7 +187,7 @@ static inline void enable_pkg_thres_interrupt(void) > u8 thres_0, thres_1; > struct msr val; > > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > + val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); > /* only enable/disable if it had valid threshold value */ > thres_0 = (val.l & THERM_MASK_THRESHOLD0) >> THERM_SHIFT_THRESHOLD0; > thres_1 = (val.l & THERM_MASK_THRESHOLD1) >> THERM_SHIFT_THRESHOLD1; > @@ -203,7 +203,7 @@ static inline void disable_pkg_thres_interrupt(void) > { > struct msr val; > > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > + val.q = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); > > val.l &= ~(THERM_INT_THRESHOLD0_ENABLE | THERM_INT_THRESHOLD1_ENABLE); > wrmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, val.q); > @@ -356,7 +356,7 @@ static int pkg_temp_thermal_device_add(unsigned int cpu) > goto out_unregister_tz; > > /* Store MSR value for package thermal interrupt, to restore at exit */ > - rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT, zonedev->msr_pkg_therm); > + zonedev->msr_pkg_therm = rdmsrq(MSR_IA32_PACKAGE_THERM_INTERRUPT); > > cpumask_set_cpu(cpu, &zonedev->cpumask); > raw_spin_lock_irq(&pkg_temp_lock); > diff --git a/drivers/video/fbdev/geode/display_gx.c b/drivers/video/fbdev/geode/display_gx.c > index b93aa21a1d2b..511cb7bf98e9 100644 > --- a/drivers/video/fbdev/geode/display_gx.c > +++ b/drivers/video/fbdev/geode/display_gx.c > @@ -26,7 +26,7 @@ unsigned int gx_frame_buffer_size(void) > struct msr msr; > > /* The number of pages is (PMAX - PMIN)+1 */ > - rdmsrq(MSR_GLIU_P2D_RO0, msr.q); > + msr.q = rdmsrq(MSR_GLIU_P2D_RO0); > > /* PMAX */ > val = ((msr.h & 0xff) << 12) | ((msr.l & 0xfff00000) >> 20); > diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/geode/gxfb_core.c > index 8d69be7c9d31..e0a3447f2b1b 100644 > --- a/drivers/video/fbdev/geode/gxfb_core.c > +++ b/drivers/video/fbdev/geode/gxfb_core.c > @@ -378,7 +378,7 @@ static int gxfb_probe(struct pci_dev *pdev, const struct pci_device_id *id) > > /* Figure out if this is a TFT or CRT part */ > > - rdmsrq(MSR_GX_GLD_MSR_CONFIG, val); > + val = rdmsrq(MSR_GX_GLD_MSR_CONFIG); > > if ((val & MSR_GX_GLD_MSR_CONFIG_FP) == MSR_GX_GLD_MSR_CONFIG_FP) > par->enable_crt = 0; > diff --git a/drivers/video/fbdev/geode/lxfb_ops.c b/drivers/video/fbdev/geode/lxfb_ops.c > index f5f1134cae9a..980a782214a2 100644 > --- a/drivers/video/fbdev/geode/lxfb_ops.c > +++ b/drivers/video/fbdev/geode/lxfb_ops.c > @@ -127,7 +127,7 @@ static void lx_set_dotpll(u32 pllval) > struct msr dotpll; > int i; > > - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); > + dotpll.q = rdmsrq(MSR_GLCP_DOTPLL); > > if ((dotpll.l & MSR_GLCP_DOTPLL_LOCK) && (dotpll.h == pllval)) > return; > @@ -145,7 +145,7 @@ static void lx_set_dotpll(u32 pllval) > /* Now, loop for the lock bit */ > > for (i = 0; i < 1000; i++) { > - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); > + dotpll.q = rdmsrq(MSR_GLCP_DOTPLL); > if (dotpll.l & MSR_GLCP_DOTPLL_LOCK) > break; > } > @@ -316,7 +316,7 @@ unsigned int lx_framebuffer_size(void) > struct msr msr; > > /* The number of pages is (PMAX - PMIN)+1 */ > - rdmsrq(MSR_GLIU_P2D_RO0, msr.q); > + msr.q = rdmsrq(MSR_GLIU_P2D_RO0); > > /* PMAX */ > val = ((msr.h & 0xff) << 12) | ((msr.l & 0xfff00000) >> 20); > @@ -359,7 +359,7 @@ void lx_set_mode(struct fb_info *info) > > /* Set output mode */ > > - rdmsrq(MSR_LX_GLD_MSR_CONFIG, msrval); > + msrval = rdmsrq(MSR_LX_GLD_MSR_CONFIG); > msrval &= ~MSR_LX_GLD_MSR_CONFIG_FMT; > > if (par->output & OUTPUT_PANEL) { > @@ -420,7 +420,7 @@ void lx_set_mode(struct fb_info *info) > > /* Set default watermark values */ > > - rdmsrq(MSR_LX_SPARE_MSR, msrval); > + msrval = rdmsrq(MSR_LX_SPARE_MSR); > > msrval &= ~(MSR_LX_SPARE_MSR_DIS_CFIFO_HGO > | MSR_LX_SPARE_MSR_VFIFO_ARB_SEL > @@ -592,10 +592,10 @@ static void lx_save_regs(struct lxfb_par *par) > } while ((i & GP_BLT_STATUS_PB) || !(i & GP_BLT_STATUS_CE)); > > /* save MSRs */ > - rdmsrq(MSR_LX_MSR_PADSEL, par->msr.padsel); > - rdmsrq(MSR_GLCP_DOTPLL, par->msr.dotpll); > - rdmsrq(MSR_LX_GLD_MSR_CONFIG, par->msr.dfglcfg); > - rdmsrq(MSR_LX_SPARE_MSR, par->msr.dcspare); > + par->msr.padsel = rdmsrq(MSR_LX_MSR_PADSEL); > + par->msr.dotpll = rdmsrq(MSR_GLCP_DOTPLL); > + par->msr.dfglcfg = rdmsrq(MSR_LX_GLD_MSR_CONFIG); > + par->msr.dcspare = rdmsrq(MSR_LX_SPARE_MSR); > > write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK); > > diff --git a/drivers/video/fbdev/geode/suspend_gx.c b/drivers/video/fbdev/geode/suspend_gx.c > index 6c0a526ee8a2..2fa20acba62e 100644 > --- a/drivers/video/fbdev/geode/suspend_gx.c > +++ b/drivers/video/fbdev/geode/suspend_gx.c > @@ -21,8 +21,8 @@ static void gx_save_regs(struct gxfb_par *par) > } while (i & (GP_BLT_STATUS_BLT_PENDING | GP_BLT_STATUS_BLT_BUSY)); > > /* save MSRs */ > - rdmsrq(MSR_GX_MSR_PADSEL, par->msr.padsel); > - rdmsrq(MSR_GLCP_DOTPLL, par->msr.dotpll); > + par->msr.padsel = rdmsrq(MSR_GX_MSR_PADSEL); > + par->msr.dotpll = rdmsrq(MSR_GLCP_DOTPLL); > > write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK); > > @@ -43,7 +43,7 @@ static void gx_set_dotpll(uint32_t dotpll_hi) > struct msr dotpll; > int i; > > - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); > + dotpll.q = rdmsrq(MSR_GLCP_DOTPLL); > dotpll.l |= MSR_GLCP_DOTPLL_DOTRESET; > dotpll.l &= ~MSR_GLCP_DOTPLL_BYPASS; > dotpll.h = dotpll_hi; > @@ -51,7 +51,7 @@ static void gx_set_dotpll(uint32_t dotpll_hi) > > /* wait for the PLL to lock */ > for (i = 0; i < 200; i++) { > - rdmsrq(MSR_GLCP_DOTPLL, dotpll.q); > + dotpll.q = rdmsrq(MSR_GLCP_DOTPLL); > if (dotpll.l & MSR_GLCP_DOTPLL_LOCK) > break; > udelay(1); > diff --git a/drivers/video/fbdev/geode/video_gx.c b/drivers/video/fbdev/geode/video_gx.c > index 5717c3356949..b2cfadaf3ff8 100644 > --- a/drivers/video/fbdev/geode/video_gx.c > +++ b/drivers/video/fbdev/geode/video_gx.c > @@ -142,8 +142,8 @@ void gx_set_dclk_frequency(struct fb_info *info) > } > } > > - rdmsrq(MSR_GLCP_SYS_RSTPLL, sys_rstpll); > - rdmsrq(MSR_GLCP_DOTPLL, dotpll); > + sys_rstpll = rdmsrq(MSR_GLCP_SYS_RSTPLL); > + dotpll = rdmsrq(MSR_GLCP_DOTPLL); > > /* Program new M, N and P. */ > dotpll &= 0x00000000ffffffffull; > @@ -167,7 +167,7 @@ void gx_set_dclk_frequency(struct fb_info *info) > > /* Wait for LOCK bit. */ > do { > - rdmsrq(MSR_GLCP_DOTPLL, dotpll); > + dotpll = rdmsrq(MSR_GLCP_DOTPLL); > } while (timeout-- && !(dotpll & MSR_GLCP_DOTPLL_LOCK)); > } > > @@ -180,7 +180,7 @@ gx_configure_tft(struct fb_info *info) > > /* Set up the DF pad select MSR */ > > - rdmsrq(MSR_GX_MSR_PADSEL, val); > + val = rdmsrq(MSR_GX_MSR_PADSEL); > val &= ~MSR_GX_MSR_PADSEL_MASK; > val |= MSR_GX_MSR_PADSEL_TFT; > wrmsrq(MSR_GX_MSR_PADSEL, val); > diff --git a/include/linux/cs5535.h b/include/linux/cs5535.h > index 5ec2aca537bb..fef236cab7d8 100644 > --- a/include/linux/cs5535.h > +++ b/include/linux/cs5535.h > @@ -51,7 +51,7 @@ static inline int cs5535_pic_unreqz_select_high(unsigned int group, > { > struct msr val; > > - rdmsrq(MSR_PIC_ZSEL_HIGH, val.q); > + val.q = rdmsrq(MSR_PIC_ZSEL_HIGH); > val.l &= ~(0xF << (group * 4)); > val.l |= (irq & 0xF) << (group * 4); > wrmsrq(MSR_PIC_ZSEL_HIGH, val.q); -- Thx and BRs, Zhongqiu Han From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:06:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:06:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428918.1651838 (Exim 4.92) (envelope-from ) id 1x918E-0005ES-Cz; Tue, 22 Sep 2026 14:06:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428918.1651838; Tue, 22 Sep 2026 14:06:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x918E-0005EL-9Z; Tue, 22 Sep 2026 14:06:02 +0000 Received: by outflank-mailman (input) for mailman id 1428918; Tue, 22 Sep 2026 14:06:01 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x918D-0005EC-Aw for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:06:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x918C-00GC66-FU for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:06:00 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28b37-2eae-0a2a0a5409dd-0a2a450ae716-48 for ; Tue, 22 Sep 2026 16:06:00 +0200 Received: from [40.107.162.128] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28b42-f2d2-0a2a450a0019-286ba2802b24-3 for ; Tue, 22 Sep 2026 16:05:55 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by AS1PR03MB8264.eurprd03.prod.outlook.com (2603:10a6:20b:474::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 14:05:52 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:05:52 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Twa+XyxvDhk2wKCB+4leGMjDQrFWELofrhxeJyx1+pkFFfQUvnsOHUDYEvKmV0xsL7Xz6im6sZYwGwM/hqk3ghjiQso5RVUiWPM3jfxO9b8n2mw/D0yLnbJnlemYBZwYCqYZUyRDAmqtECAkYsjkN7YrAG8nI1lnh/gybHJcOqxQrCNqV2NcVeXN3dy2Jw8qOZv0iGGXyjfVz7jVUruBrIqtmkBM1eOU1h8+SDQwDPSnDiWAv1tqhMHodHb6O4khZA7vpnz82p+wZrk0nCOZSbrzNuCkjT6NCgjaCEZn5vTFw/1BPIeuMCi5Mgo5Ov5r7D/rvoFqS+VpZb+3EJD61g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=b4BqyLrUmx+6dUteUQy3vicJ8GpvQFplSI25NlSF2sQ=; b=g5W846Q1lUGS3KuM6mBTqZuurzTyUPVzvibrWzQDtec0Ds7i0gRDo1054xJiLazadWq6f0EuwJyhlKSNJfGlOgeFCO1dhPCN2L+IUhyIuy9YUKCQoJudo+ytb9NkleGvAspTZTOVwL7iCPYApifD+KzpNS+X8rDrFrDqjzaMGKsT7Ndt5Oy66rCZWFdDpB3k4kiYjAY2yoGcyCykzK5clmhkV+nvlIJm8qcgB/AeVYCJ8UlueMvxylcGlILFF+ifhlJYXtZBtt1Aa/7y0IRkaYAJ2RfVbA5vw3yaWWTIhvdvgMrpeYChIwEPY1FpjJycCI8ZaiRtNtCbfb0j5mgNzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b4BqyLrUmx+6dUteUQy3vicJ8GpvQFplSI25NlSF2sQ=; b=Kuq+TIoJKBR8LIo/Ajhlc3FeHPI99mnMrxoFqmFWQo5nKM8dPG6X4nclDX0vzATWYLXd/IUYOnA2cmixxBaHzrSPtQilGyXNbg0DlIDDIaMoXkaXGDNEY7/MkP4EFg1bywaawON8Ib0olulwGOjrKfHoJRXOGaoItVUSOXMVPopVGEnzPb3TmijkghS5//g9E5qIIia8KPKv/6QfzClRYfEoXaw9jh/+SscqmeIl85vjr9gjhm47NCFrRNh7R7lmFofb2BVr5kmibz5M+VO7BirjTfRWhAWS+fd8zQJAXKqcZwkuM2EuVUdFkq8qo0i9dEUe4t1GeXLmtKQ9DP6mmg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Tue, 22 Sep 2026 17:05:47 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: Mykola Kvach , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Luca Fancellu , Volodymyr Babchuk Subject: Re: [PATCH v2 3/4] xen/arm: its: refactor ITS quirk matching Message-ID: Mail-Followup-To: "Orzel, Michal" , Mykola Kvach , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Luca Fancellu , Volodymyr Babchuk References: <22e10198-10d4-4343-9286-989d994b021f@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <22e10198-10d4-4343-9286-989d994b021f@amd.com> X-ClientProxiedBy: WA2P291CA0021.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1e::29) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AS1PR03MB8264:EE_ X-MS-Office365-Filtering-Correlation-Id: fe9dc5b5-9198-4803-be8f-08df18b29c80 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|376014|10067099003|56012099006|6133799003|18002099003|22082099003|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: sy1Fr2RhiiCeuazHkap8W2zt4Ci50cI4j7y7KHW9UvFgCAoN/ePAMwKkRa932I7P63de+aBjXX8tO8o0oF4atI2oKsZgUlCFmY0stefNYF4t1pyoDqHm/NyWRzrptJuWQkkDUt9GYUaX0ewk0jsLfMGfB1y1fCOX1ETL2O9cbjBaE+M2bYLN6AXPiGmuPuPJvbBhdFBRVd4zKrv04+7tcGsejt2TEKtSgDHZrq+KNqb1JT6QmYdC86QNW5UcWBP9b9s43LNYrODJHk4Ie3g0kkAbaTJi58QqWiCbko9wD1rnNi8k6Y7TvLWUkkT+YIGctKTuID25Qo5JCoineiCTLiCRJSCJVoy1hEmeZgvsxohwG5TrZ7bN0RCtMNbk+0tHdqG/+qtyChGqufsH71zhZ7sYpRFrzwxuNTeiW4EkBzReK504oOdfz+5z44M83sBEs5D3a7aFvMFIMPDTWtwjQ7EinRDnqRZKrSMMRfPTZ27p7kxkTQHj1aamSpz5wOOqFkZsERnw45JxRyPh+WWPWecUhknOzz9gOitLHzx77vwVZG3wMrV5Zwd5yrv+Q9sUzhobVzfPDMOHDx31ZzIFXcm1UCEET0NK7ycRmZI+urENgatyRnSy3ZsCh62Ln/IUCs+FB0d826bZQ16u6rxhRxMM1U/pZqHr9M62/r4Cz+o= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(376014)(10067099003)(56012099006)(6133799003)(18002099003)(22082099003)(11063799006)(4143699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eWJYY1Y0V3l3Q0xDY253Q0lTSCtUKy85b2FlaDF1K2RXKzhkUDVXWGxqWERw?= =?utf-8?B?dGFUU0drY3BvLzk5eEllZHZ2cHIyc1g3V3hJL0N3TXIxbW0rMmN2cFdWN2wv?= =?utf-8?B?M2p0YzhtWnlid1NEc0djdkRNczhKamJxU3VWcDRrZW4xMGpSVTIrcnVpZ2FG?= =?utf-8?B?NmFqMG5HNEN6SVhsVmovRm1VZDBzRWI0N3MySzQ2bmFnNUpSYnVzYTQvSFEy?= =?utf-8?B?Ty9oK0daK2dIUDg5TUdwVmFYYjR1ZXkvMXNZUXFVYlpYdTNMcU5DS3pZcG1n?= =?utf-8?B?UUJJdEoxNjBweVd1WEZkN0tUVFFNbjhlVjJuTUFmNkRxOEFBWTVGMVZWMDhk?= =?utf-8?B?SFVWTEk5QnpXNHp1NXY0U2JLNU1yUmM4Z1FUbkNTVTRDY3RKTUNQaXdxM0gy?= =?utf-8?B?MjZyMzZJcFdndmJSdkZUdjN3ZGdHVjdManBEdyswNEpiY3V3OWhPa1Y5Kzli?= =?utf-8?B?VXZIb0V0ZnRDcC9MWkxiTXRuYWE0YmU4Z0tLVDBJTkkzTjUvZVlpVVRWQjVw?= =?utf-8?B?RGxvbUF6UnhCUEdMZlN5dUVVNlFERGpLdlpFK3hOZXVnR2FxSHRDTlVFRldv?= =?utf-8?B?Y0NpSUMySXU1V1ViVXFyMDNlRlZXdHE1Mmo4cGdVc3VuaUNJbTZtaEVKb1NJ?= =?utf-8?B?YkFZUEo5NUtZZkh5L3RqZjlrbXZGelV1cnljcUdhN0Z4NWQyNXk1SDFvZFF5?= =?utf-8?B?a2ZIYk5MVWMxc0Z5YWJoWFUyM05WN0dsODBBRGJ1aFdVS2hLRHM0bW9UN3NV?= =?utf-8?B?ck8wdmk5NUtVMUh5VmFQczhUSDREbndHUzFEK0ZUeEIwQkV5MW9JMXVnVzcx?= =?utf-8?B?TEZCRVpFWWU1b3Y5Mk43Q1JLd2dFVTlEeWFwVVlRblRFdis5cFcycEFkWjRI?= =?utf-8?B?aXJBZHp5SzRJZmJ2enJrbklzcmRseFN2aHNmY1cvQXkyNkk4dFBjbEZrYzEr?= =?utf-8?B?djFrSlN2c0R6a3l4NXBVWERXVjBBWlByRmJLZnlyNHhsUE5rbDRRYjYxRnZG?= =?utf-8?B?TUQ5K1Y2M2RkdVZodUFMWlF4NDZGeXFwaUZmOTZlNVFLRWFFRC9pWDhCMFdV?= =?utf-8?B?Ukxtb0hjYzJtbVhBUktzK0JKdXBESnhoTFd3NktlUkordTYySWM5NEhsdWFn?= =?utf-8?B?dkg5bmpCMVJtM05leDh0Yy92eU1iMTk0Wjc3Tmd2UklIN2Y4czh3Q0Rva0t0?= =?utf-8?B?WXV1WHljQU1iakFOejBlaytuZmFZTzlMOStTUzhlMUxkTGcwOFVWd2t4WHRU?= =?utf-8?B?aTFSZ05XRlZsWVNRT1JRUmF1ckRRY1lZeTBDUWdBVS9weE9DRWZYTGxyaEJW?= =?utf-8?B?V2YxYWl4ajhEZ0dCUHhoWjVPVEhBK3o4ZmlVQURTNEhJckd5cmhJMHNEbGUz?= =?utf-8?B?Rmt3YXZubVRCQzFOdHJVUllJZDcyb1pSeW1JOGdMYWNacmFxYm1GMGdFZ3I5?= =?utf-8?B?eEVBNTZZYlJLL0FjanRuQ2RWTGxRU1RTZGR0VDhVZitucHY5bi9ZTFhpSFcy?= =?utf-8?B?c1RnRUozY1FLL2lDMFk3bld6UFF1cFR6RW9ZbndaRGkvY2M3Z0dGcGxDd1Fu?= =?utf-8?B?V05VZUpqWExkVmEwenN0dEJlUWRWZ2czeWNMTkR2NzRsclhTb2xBQXFYTkcv?= =?utf-8?B?eEZubmM4YXZJSzI2RHZyMytZZEZzbXNZYllQWEl6aFNTT2o3Q3VYNUZLR3Rp?= =?utf-8?B?a1Z3MzRTdFo5Sld3ZFNDOUt0R3VVUVRhOHZDUGF5OG82VE5Vem9wVUV0ZWR2?= =?utf-8?B?SU4rWWVVa0F3MHA2S0hDUldKVzllZ21jSzJydTJhWTN2VUQ0aDkzc21lMlRs?= =?utf-8?B?Sm5GZ04weUNpdHQ0TGp3L2xZa2ZIaUxLbDdOcHhiUG5vbWdTVFFNVHJZZmRQ?= =?utf-8?B?a0U4NWtSZkVCSXhGNHRtckpYaHlNMUNDaWxJUlFqUGViMkhTSnVxQk9mVVB4?= =?utf-8?B?eHZLeU9kREN5MVdQMkFTWGNMYUJKSTFwUC92K0V4eXVMR1VBN2p1ZWVNcUdK?= =?utf-8?B?S3VWMUFPNmJQc21udm1rVE9ndGVNV2didUE2dG15Vkd6WGkwYzZGT1diSjFX?= =?utf-8?B?ODFzV1IzRytOSWptVEdVMVd6dG55SUtabTNxUERGcndHTWF0eEhPaTVXNjV1?= =?utf-8?B?SHZ2Sm9BOWVLdDg1L2ZEbktpdU9rQnNFVE15eGFCUmVLamp0eU5Xb2M3V0JP?= =?utf-8?B?MXVZT1ZyOEYrMEgzN3diN2NiUHpvdWNyZTNQMEg5aG1Va2Nqeks2c2Q2V0dN?= =?utf-8?B?c3FOQTFBT3M2VUdJNWFwY2t5a1hvNCtsRHV1NjlWMDNUWUVhWm1iN29ONEdZ?= =?utf-8?B?UWVTYURWc2lMNkNaeFlIY2YwS1QwMEFsaEZlTmpSY0xUeFgyRTgvdz09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe9dc5b5-9198-4803-be8f-08df18b29c80 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 14:05:52.5225 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: F8xTivaV0LXlbTdJDkFfQ03zJmVr6T20hQyUJbvHeuysW9wIUc+lRN9G1wTHnO0Fl/iPseZKunoEd0F9P8rCgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR03MB8264 X-purgate-ID: tlsNG-4011c0/1790085955-530D9CFC-4B27C6F6/0/0 X-purgate-type: clean X-purgate-size: 4777 On Fri, Jul 31, 2026 at 10:34:11AM +0200, Orzel, Michal wrote: > > > On 28-May-26 02:25, Mykola Kvach wrote: > > From: Mykola Kvach > > > > ITS quirks are currently matched only by IIDR and mask fields stored in > > each table entry. That is too coarse for integrations where the same GIC > > IP block can appear in several platforms but the workaround is only valid > > for a subset of boards. > > > > Replace the fixed IIDR fields with a generic match(hw_its, data) callback > > and an opaque data pointer. Add an IIDR matcher as a reusable building > > block and use it from the R-Car Gen4 matcher after checking the Renesas > > machine compatibles. The R-Car Gen4 platform refinement is DT-only; > > ACPI-discovered ITSes do not match it. > > > > Keep first-match semantics explicit. Assert that non-sentinel entries > > provide a matcher and that IIDR matching receives match data, but keep > > runtime guards so a malformed table entry does not become a NULL function > > call or NULL data dereference in non-debug builds. The matched entry still > > supplies separate ITS and LPI flags; this patch only changes how the entry > > is selected. > > > > Signed-off-by: Mykola Kvach > > --- > > Changes in v2: > > - Replace v1's optional platform callback plus fixed IIDR/mask fields with > > a single generic match(hw_its, data) selector. > > - Add a reusable IIDR matcher and use it after the R-Car Gen4 > > machine-compatible checks. > > - Document that the R-Car Gen4 quirk remains DT-only. > > - Keep the split ITS and host LPI quirk scopes when applying the matched > > entry. > > - Document first-match ordering in the lookup path and guard against > > entries without a match callback or IIDR match data. > > --- > > xen/arch/arm/gic-v3-its.c | 67 +++++++++++++++++++++++++++++++-------- > > 1 file changed, 53 insertions(+), 14 deletions(-) > > > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > > index dc48a84789..e055914763 100644 > > --- a/xen/arch/arm/gic-v3-its.c > > +++ b/xen/arch/arm/gic-v3-its.c > > @@ -53,8 +53,8 @@ struct its_device { > > > > struct its_quirk { > > const char *desc; > > - uint32_t iidr; > > - uint32_t mask; > > + bool (*match)(const struct host_its *hw_its, const void *data); > > + const void *data; > > uint32_t its_flags; > > /* > > * lpi_flags are ORed into the global host LPI policy and must only > > @@ -64,11 +64,48 @@ struct its_quirk { > > uint32_t lpi_flags; > > }; > > > > +struct its_quirk_match_iidr { > > + uint32_t iidr; > > + uint32_t mask; > > +}; > > + > > +static bool __init gicv3_its_match_iidr(const struct host_its *hw_its, > > + const void *data) > > +{ > > + const struct its_quirk_match_iidr *match; > > + uint32_t iidr; > > + > > + ASSERT(data); > > + > > + match = data; > > + iidr = readl_relaxed(hw_its->its_base + GITS_IIDR); > > + > > + return (iidr & match->mask) == match->iidr; > The commit message says you keep a runtime guard so malformed table data > does not become a NULL data dereference in non-debug builds, but there is > no such guard - ASSERT() compiles out and match->mask is then read from > NULL. You're right: ASSERT() alone does not provide the guard described in the commit message. I'll add an explicit NULL check before the IIDR match data is dereferenced, so it also works in non-debug builds. > > > +} > > + > > +static bool __init gicv3_its_match_quirk_gen4(const struct host_its *hw_its, > > + const void *data) > > +{ > > + if ( !hw_its->dt_node ) > > + return false; > > + > > + if ( !dt_machine_is_compatible("renesas,r8a779f0") && > > + !dt_machine_is_compatible("renesas,r8a779g0") ) > Given that IIDR 0x0201743b is not Renesas-specific as you mention in the cover > letter, this is a behavior changed and should be mentioned in the commit msg > (cover letter is not in git). I'll document the change from IIDR-only matching to platform-restricted matching in the commit message, including its effect on ACPI and other platforms. > > > + return false; > > + > > + return gicv3_its_match_iidr(hw_its, data); > > +} > > + > > +static const struct its_quirk_match_iidr rcar_gen4_iidr = { > __initconst > > > + .iidr = 0x0201743b, > > + .mask = 0xffffffffU, > > +}; > > + > > static const struct its_quirk its_quirks[] = { > __initconstrel I'll also mark the IIDR match data __initconst and the pointer-containing quirk table __initconstrel. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:09:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:09:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428925.1651845 (Exim 4.92) (envelope-from ) id 1x91BD-0006aA-PS; Tue, 22 Sep 2026 14:09:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428925.1651845; Tue, 22 Sep 2026 14:09:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91BD-0006a3-Mf; Tue, 22 Sep 2026 14:09:07 +0000 Received: by outflank-mailman (input) for mailman id 1428925; Tue, 22 Sep 2026 14:09:07 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91BC-0006Zs-Ui for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:09:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91BB-00GDSZ-8O for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:09:05 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28bfd-8faa-0a2a0a5109dd-0a2a4505b952-18 for ; Tue, 22 Sep 2026 16:09:05 +0200 Received: from [52.101.66.116] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28c00-4cb1-0a2a45050019-34654274a410-3 for ; Tue, 22 Sep 2026 16:09:05 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by BESPR03MB911401.eurprd03.prod.outlook.com (2603:10a6:b10:105::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 14:09:02 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:09:02 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=t031A90k+vH8hNurADh6bEyuf/JmZhng3PB0+kEq0tdsYxQFOq3MKgZgKijhqbejT7gIGcghXLHX3mPp1pc6Rt9IAATPfFRaA+Ku7Dt7UaR45CWpY+phUc6F5y4XggWgSjykFwoOfLZhUvW3dcK+V0LIfpZD8/9TLN3O1rmtS6WoJU6R88g/aVRhaCX27eVb9iayL4Uhu1bt7/Db8ce43dxeHbPuvBuhCVHM1ysm0nH6YNI+yNXfTMPM/RuT3FwFXjeo5CS4gZib4lxO4T8dugyF7t2wPHMJIpdBcTFPfXmV0ENyRpBQUaQvuyKilKfzbTkkoHz2+uGA3k1qiUNMcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=I6L1/7un1Y1Bx4nCZhJxjl/opiga05Fw0y4Br9uixXM=; b=B0YTlF5V7x/3s3YPjhIDuLHRpJ81xnKLUhg9PDYQiO4qZkVVz+LUVwQWw4X3umvqlerkV7xO5nr2yJMw652ncGSrCBwVRHvHHRsmjDjth4x/c6IiZc2vTHwnKADz4jKnCYyGYq8FdN6ezytC/iehqbKB6MklRHZt9MZrYqgsyPMD3ChV1O/4pG0xGHalfHQKiMebQy20atatb6zMZpC3ek4BX97sptPlVIXwoeygh81R74DWx2pVHLeqNoLfgibd9XUixT+XQPJJ1kogItXd4LrAGs+pekt7/ny9tBVYGh/6m7gxZzFKHAtwX3B/QkzB9ph65atcnD2i3NZpwMvkHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I6L1/7un1Y1Bx4nCZhJxjl/opiga05Fw0y4Br9uixXM=; b=oAmNx2rHDqui6JvIAS6psmiOEHhNmhCdufcXY+ct2H8r91OeQ83bIGQRR/2u0pVeUVmsrojz0Uu8cjynD0jYGBauU+GWJy3cJu7djtR9rjHws+3yEDFXQnjYUSLn4pMP8OX+pe0tuNCHyhlEsDMz83z2XqvG8Th8huIPXCDfPRnmOliv5kj1TRymK+t2KIGAw5aIqQBGVmmtPm/YqNSL7uLW3xgi/viINpxqGvsCUq6D9C8CnuSILrsl0MyslNs6y9uSgPseaiINI+M7MkD8I1zt9UjlCzbsm6mnrT6i2Aacr5UtLlReBK2w8g81mabvvT9GT5OMCGo27k10JtDMjA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Tue, 22 Sep 2026 17:08:58 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: Mykola Kvach , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Luca Fancellu , Volodymyr Babchuk Subject: Re: [PATCH v2 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes Message-ID: Mail-Followup-To: "Orzel, Michal" , Mykola Kvach , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Luca Fancellu , Volodymyr Babchuk References: <43b0e8f6b25588ba1cfc22d367e5ed6b303a4978.1779922874.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: WA1PEPF00005B8A.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::63b) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|BESPR03MB911401:EE_ X-MS-Office365-Filtering-Correlation-Id: 5e2122b3-5c3b-4af6-4704-08df18b30de1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|23010399003|376014|10067099003|56012099006|18002099003|22082099003|5023799004|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: Tii/RZ2g8ODGiMHk1ZAa2JW3Rb5b5VvOTDaSs1jBgSN7vu7GwBBhZMWXVC5BqX5U9SyObJ3fiYLkybDPwd3R3uKjIvKkB9HwFb981lURMUAYgYOHMgFf6eAcELOvKtT/Fx95cEqOe3MUqfeDqSOc7VLsx5sBfPOt3PzZfoxiVZai0RuhMLT6J3zKncsEmi7zzfYgp0mmFmAr9oOVCrFh3tMAYndUlQq2f5MODCVV/hDEsk6VHBYiRVDtcc8KUFC9ZmJQzvoIRKJo/36N4vxbyXPP0HliWm7sCbckDg56VVPut7pJmayHZVIBrerFz1ZVfvgr645ZcVSQMlGuysGOSp3Yg+riI//zNXCgXpSD9CKY3eZ7qGEDeKbuysH5mnx/TNbxVXDO4uCQLarJVgedIYD3R89tliikDXuaKt+0dlo7PR6chYAFDFIbqZnVlu++i+6Zo4NM1i/trBFQFtRVb5zSrmAVFTTWEJK08f3K8bTjs7pfdXDJa63NrMK28GAghGzWpZDTIarJ4VUysiLR4bTt7KqmTHs4HcxqltNF6hEkezgt1bvZOTQT+keGzZ/IKJdqLuTLJ3s/BSK502F2eT1hDJvbYQxdUb0irfpv8v8dujbRrdjVvFElF6X/zmvD8Gf4zaboMKi0GyOI/7QWhGgPLwvH6rQyn/S4kpymYbM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(23010399003)(376014)(10067099003)(56012099006)(18002099003)(22082099003)(5023799004)(4143699003)(11063799006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cHJWWXBqZFMvYi9FNVN4QmZhM3ZnQW1KUnBjV2hwdTM0b0llNXdrZ0RXOVZ1?= =?utf-8?B?NkUrYkdXWXNvWFFnSitKKzNkU0tKTllTcDNLczhQQWZKaEtweDk1SS9ENDZN?= =?utf-8?B?ZDhkNEpDTmU5ZldjejZvN2FRdjVtR1RzTW5waG9NaGoxWkVhRTljUWJlbE9y?= =?utf-8?B?d2V1NlB1b3htRzdtSkxxRjNGWnMyNDJScGhQU25WeVNjanZocXVUWDhiTkVY?= =?utf-8?B?WHVEU3NXOU1ucUpNOS8zWm9IUVMwZE02NXhXNlI4VEVPNmprSlRMbW1sZXVT?= =?utf-8?B?aW9SZUlFOTEySTF6Qzg3eE5LYkRxU0FRT2loRTRUT2FrenUwWE9nMEJ6cVhS?= =?utf-8?B?YURTZUJKSmpRWWc1cW8xMWpmbjZGdHVnSmt2Sk1VN0sveHR6aU9jaG50Si9U?= =?utf-8?B?bnZEQXlqVmoyQ0QxUUU4YnZVUnpaQ3FrZlliUEE1TFBQVW5Pa3d2Z1F6Nmxp?= =?utf-8?B?TWl4NEI3dUkxdVZ5TjNWU1hPRis1Mk40YXhqNGVxeENtYStQOGpuUXliVUZY?= =?utf-8?B?SjZDeldvbDVqekRjRE16K3NVbGxZbWhSbzBONXR4dHJRVTk2ZVlWRHpwMzl5?= =?utf-8?B?Sk9lR2tUajY0RTBXSXIxOE5GVUc3a2lRUStmRUlXUUtFbVFORzdHbk9YWUVy?= =?utf-8?B?ZHZHM2V6NGQ4ZEMwZklnZEpDV29oSlpFdGhLSktIdUtJTW0zcm9PdWdubTRU?= =?utf-8?B?a21kaklDOEFaWk5ieDJuUzVpWVFDRUZRUDR2YTRuU2JLWlRNQit5aUFMaGtD?= =?utf-8?B?cS9lQm1pcW5aeDBMcmNCdHFuZS9FYnJJQlA4SlNleURoY2FTNmZoaEV3MGFG?= =?utf-8?B?bTlsQTlxdlMyRGZieWZFbnZUOUNHS1BRV2twSDVQRk5HOG51RU9hK1dvaVJ2?= =?utf-8?B?bkNza250eDBlalJ2TGFiUEhIRVo2QmVzdEUzTDJwYjFnaFUxSEQxY2ZQNE9h?= =?utf-8?B?ODBkV2Q0aEs4OE90VFZMR244ZElTYUZxWjlJNWowMVJsU0RPV1pXOTlWN3Nw?= =?utf-8?B?Q3JoZlJncURzZURpUDF0dksvUFpkMGNnWFh6aWxiZXhpczFmbU5pYXI4ck9T?= =?utf-8?B?U3JjbU9IRjNnUGxrOVlVQ2F1bDN5dTI3MEw1eS9SMEROZ3FHb0d6dUZRWUdB?= =?utf-8?B?ZExoL2NiKzN2S2twTkdiRjRRZzM1cG0rZ2s2SUF2ZnNxVDZid3BHRFhSSmlr?= =?utf-8?B?OEVTOTJhaG8yWi9QUFVBUWlFQ0ZGMzY3UW5EdUdCMHRqNUdhVEVXSmk3Q3lP?= =?utf-8?B?RmRXOFk0dkVwbkdrUnpGSEdlZWFzS2VmN2hnWkRsZ2U3dVcxS3ZTR1NLYmx1?= =?utf-8?B?U1B4ZWo1d2s0Zjh0MFZhb2l5ZUhtSE5pOU1sRHV0akdKeU1Kc0JYR1NDYzV5?= =?utf-8?B?Tlc2TEgxaE9HYWdiNzhzZ3Z6UmNmalNRa3U0am1OYVFwbnBPaEVnM09EQkNY?= =?utf-8?B?V1ZzbjBERm93UlRmaXU5WnBVdmcxdTY4MVNpdFZZVmY4d2l4OUJnSzd2NlZT?= =?utf-8?B?S3VOcWtXS3duOXp0d0hZR0pCVGdoVkF3Mk9PR3BISmtLb2xBN2VuUDFuK0I2?= =?utf-8?B?RGx1MzdMUUt0Q0wxenF2dTBFZ3l0OEdmbWV6NXJOckx0aVFhUDdtNlBYSW5J?= =?utf-8?B?R3FNN3dhSTU5ZUcwZDJLOGZYdEEyUldrODlsZW52b28xOVZWczJvNFI0WFpR?= =?utf-8?B?YThRazZjT2MrbkdPZWpMQVZ6T3JtNmJBdzB3RTdKSGZ4N1dpTDNtdUpnL0Zu?= =?utf-8?B?aEhPQ2d3OGpPTnh1MndOTHgzOFUwaURPL0tCZjlROUtQb3ZqTU1ZZXZ3R2wv?= =?utf-8?B?UG1KWkpTTmtLcE5ua0NiMFhhREpjYVZQMXFmUHYwaHZ1RHowdkU0UWNyTERM?= =?utf-8?B?WEVDMC9IZS9BT1FTaTY4MkQzdXYvbEtrR08wRkF0VDVUSUlER2U5NHhkUEQw?= =?utf-8?B?YlBvN2xCOEJETzRwa2NMREhWYW9rQzZ4TFpHN1dXbkJ4RVVmY0NXeHFmU2Rz?= =?utf-8?B?Q1ppYTRtRVJUQXpoZkVLN3h2bTlib2NrKytQU1NnbGZUdHJMa2RseFI0d04r?= =?utf-8?B?ZEJ1ZWNxVUdaR2lLSUFrdmROSTVlTmFpU1dMVldwaHlqeSttUUgzTmJENjh1?= =?utf-8?B?aW9rclQ2TDd5YjhpSXJFeHFOME5zMWo3QWZ4dEdpcGorOHBoTEpBa04yQWxy?= =?utf-8?B?dlVlN1VVbGt5dmVLdkFyVmZVamwrOTJsWDZ4NnY2MVgwL1NkeHJJTkFvSXZF?= =?utf-8?B?c0tiV09Tc0pJOEd6UjVGTUFNWXQ4QzVSZFRsY0MwaUNwZFpTUGgraDBMQ2kv?= =?utf-8?B?Z2JnTFdFdmh2WlNiUkZZcWRFblRCWVdxaGhZSWJKOHpNZ1hrUWVVZz09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e2122b3-5c3b-4af6-4704-08df18b30de1 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 14:09:02.3537 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5nEdXQTa5ohR/4xgnu9MFrPsoqI38y20pwGZ8BGd9m+WRo4rZIPHZtiGjrfyY2L2Hi6sXvkUi4cSfkIGB1dHog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BESPR03MB911401 X-purgate-ID: tlsNG-c201ff/1790086145-72AB72A1-E5801670/0/0 X-purgate-type: clean X-purgate-size: 6170 On Fri, Jul 31, 2026 at 10:39:54AM +0200, Orzel, Michal wrote: > > > On 28-May-26 02:25, Mykola Kvach wrote: > > From: Mykola Kvach > > > > The DT dma-noncoherent property describes the bus coherency of the device > > represented by the node. On an ITS subnode, that is memory accessed by that > > ITS, so add GICV3_QUIRK_MEM_NC_NS to the corresponding host_its before > > programming GITS tables and allocating ITTs. > > > > When the property is present on the top-level GIC node, it describes the > > Redistributor side of the LPI path. Collect it in > > gicv3_lpi_init_host_lpis() and apply it only to the host LPI policy used > > for GICR_PROPBASER and GICR_PENDBASER setup. > > > > Do not inherit the property between parent and child nodes: ITS-node > > non-coherency does not change the global host LPI policy, and GIC-node > > non-coherency does not change per-ITS quirk_flags. > > > > ACPI is left unchanged; this patch only consumes the DT dma-noncoherent > > property. > > > > Signed-off-by: Mykola Kvach > > --- > > Changes in v2: > > - Split v1's dma-noncoherent handling into explicit ITS-node and GIC-node > > scopes. > > - Apply an ITS subnode property only to the matching host_its quirk_flags. > > - Collect the top-level GIC property from gic-v3-lpi.c before host LPI > > allocations use host_lpi_flags. > > --- > > xen/arch/arm/gic-v3-its.c | 21 +++++++++++++++++++-- > > xen/arch/arm/gic-v3-lpi.c | 22 +++++++++++++++++++++- > > 2 files changed, 40 insertions(+), 3 deletions(-) > > > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > > index e055914763..606b127487 100644 > > --- a/xen/arch/arm/gic-v3-its.c > > +++ b/xen/arch/arm/gic-v3-its.c > > @@ -134,6 +134,21 @@ static const struct its_quirk *__init gicv3_its_find_quirk( > > return NULL; > > } > > > > +static void __init gicv3_its_collect_fw_attrs(struct host_its *hw_its) > > +{ > > + /* > > + * An ITS subnode property describes memory transactions made by that ITS. > > + * Do not inherit it into the global host LPI/Redistributor policy. > > + */ > > + if ( !hw_its->dt_node || > > + !dt_property_read_bool(hw_its->dt_node, "dma-noncoherent") ) > > + return; > > + > > + hw_its->quirk_flags |= GICV3_QUIRK_MEM_NC_NS; > > + printk("GICv3: ITS @%#"PRIpaddr" marked dma-noncoherent\n", > > + hw_its->addr); > > +} > > + > > static void __init gicv3_its_collect_quirks(struct host_its *hw_its) > > { > > const struct its_quirk *quirk = gicv3_its_find_quirk(hw_its); > > @@ -144,6 +159,8 @@ static void __init gicv3_its_collect_quirks(struct host_its *hw_its) > > gicv3_lpi_update_host_flags(quirk->lpi_flags); > > printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc); > > } > > + > > + gicv3_its_collect_fw_attrs(hw_its); > > } > > > > uint64_t gicv3_mem_get_cacheability(uint32_t flags) > > @@ -578,7 +595,7 @@ static int gicv3_disable_its(struct host_its *hw_its) > > return -ETIMEDOUT; > > } > > > > -static int gicv3_its_init_single_its(struct host_its *hw_its) > > +static int __init gicv3_its_init_single_its(struct host_its *hw_its) > These __init additions have nothing to do with dma-noncoherent and > are not mentioned in the commit message. They belong with patch 2/4, > which is where the callees became __init. I'll move the ITS __init annotations out of this patch and into the replacement first patch, so they precede the init-only quirk collectors > > > { > > uint64_t reg; > > int i, ret; > > @@ -1221,7 +1238,7 @@ static void gicv3_its_acpi_init(void) > > > > #endif > > > > -int gicv3_its_init(void) > > +int __init gicv3_its_init(void) > > { > > struct host_its *hw_its; > > int ret; > > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > > index 35f93e4756..c6f17b9b2d 100644 > > --- a/xen/arch/arm/gic-v3-lpi.c > > +++ b/xen/arch/arm/gic-v3-lpi.c > > @@ -7,7 +7,9 @@ > > * Copyright (C) 2016,2017 - ARM Ltd > > */ > > > > +#include > > #include > > +#include > > #include > > #include > > #include > > @@ -101,6 +103,20 @@ void __init gicv3_lpi_update_host_flags(uint32_t flags) > > host_lpi_flags |= flags; > > } > > > > +static void __init gicv3_lpi_collect_fw_attrs(void) > > +{ > > + /* > > + * A top-level GIC node property describes the Redistributor side of the > > + * LPI path. Do not inherit it into per-ITS policy. > > + */ > > + if ( !acpi_disabled || > > + !dt_property_read_bool(dt_interrupt_controller, "dma-noncoherent") ) > > + return; > > + > > + gicv3_lpi_update_host_flags(GICV3_QUIRK_MEM_NC_NS); > > + printk("GICv3: GIC node marked dma-noncoherent for host LPI tables\n"); > > +} > > + > > static union host_lpi *gic_get_host_lpi(uint32_t plpi) > > { > > union host_lpi *block; > > @@ -442,7 +458,7 @@ integer_param("max_lpi_bits", max_lpi_bits); > > * to the page with the actual "union host_lpi" entries. Our LPI limit > > * avoids excessive memory usage. > > */ > > -int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) > > +int __init gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) > > { > > unsigned int nr_lpi_ptrs; > > int rc; > > @@ -450,6 +466,10 @@ int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) > > /* We rely on the data structure being atomically accessible. */ > > BUILD_BUG_ON(sizeof(union host_lpi) > sizeof(unsigned long)); > > > > + gicv3_lpi_collect_fw_attrs(); > > + if ( host_lpi_flags ) > > + printk("GICv3: host LPI workaround flags: %#x\n", host_lpi_flags); > Every contributor to host_lpi_flags already prints its own line - > "enabling workaround for ITS: %s" from the quirk path. Please drop this one. I'll drop the aggregate host-LPI-flags message and keep the per-source diagnostics. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:17:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:17:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428935.1651854 (Exim 4.92) (envelope-from ) id 1x91Iz-00016q-Kl; Tue, 22 Sep 2026 14:17:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428935.1651854; Tue, 22 Sep 2026 14:17:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91Iz-00016j-IA; Tue, 22 Sep 2026 14:17:09 +0000 Received: by outflank-mailman (input) for mailman id 1428935; Tue, 22 Sep 2026 14:17:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91Iy-00016Y-7v for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:17:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91Ix-008E2J-5g for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:17:07 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28dd6-e002-0a2a0a5209dd-0a2a45019274-20 for ; Tue, 22 Sep 2026 16:17:06 +0200 Received: from [52.101.53.31] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28de1-5984-0a2a45010019-3465351fc8d1-3 for ; Tue, 22 Sep 2026 16:17:06 +0200 Received: from CH2PR16CA0018.namprd16.prod.outlook.com (2603:10b6:610:50::28) by IA0PPF12042BF6F.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bc8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 14:17:02 +0000 Received: from CH1PEPF0000AD7C.namprd04.prod.outlook.com (2603:10b6:610:50:cafe::88) by CH2PR16CA0018.outlook.office365.com (2603:10b6:610:50::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.13 via Frontend Transport; Tue, 22 Sep 2026 14:17:01 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CH1PEPF0000AD7C.mail.protection.outlook.com (10.167.244.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Tue, 22 Sep 2026 14:17:01 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 09:17:00 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 09:17:00 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 22 Sep 2026 09:16:59 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YNx0BNli/zoVpHkZph6wjpPURvRBwU4lKmmJUmwObJ8h7GCGcuymjyWCT6vDSBqJLLFGmNrKjfMPx5bvOt95QF+GL6XSeXKRTgUKLmJdf1PYAtG2ryTQiOtW3frzwQ18bpVC1llhuN2K4BEfWMIp6uxUHNbQosYlXXEuRZysbpT0cGeo7CQ3ruDQRroJ7/2MaqBbFUyjHxihrhAQQG+fGN8+9TKjU5BOVZwBDrHVQFk4di+Nbp+89Sto2iAMd+G2I7yt3tGH2zdBp1HRWNzuWCZhwUJ6N37dO0hx7qHujj3U8WXfcrG8iw051RkiII7TT54H0EKqCdjqLlkLiQIHjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GiyKKdJUOBT3vXd8bxwGTLEbTo7Dtuy1RwvOHLYnLek=; b=Anmro2vnonKxOjhARTn1FBWA+SH5t/EbrZLJuxK029BxjmNaltOAWBrjHqjFIWv9ooLZ+OfWQVwcuF5+dL6Dyb+23Dab5aMdI7i8xca+Cd9jRvz0VlIR2NBlQw6vhEDzXyBMoQHd3Uin1qYDOAEi/6hyOknScDZpf11nkpc0iZ+HpyfJJcfSHt0q/sC4SJBjqncb7TUmSPn6lWE+W4yyKYSt5aBuE7tIQwW580covjDQGx4Rew/lZ7+to/kL5xfSl10stYPpybcze+jffvjiht1y780Dd8CkmIwyWl7kvHmWcP4mI/yxvuCdCpwyD16BVsvoSKZlUa0isz15ziHn+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GiyKKdJUOBT3vXd8bxwGTLEbTo7Dtuy1RwvOHLYnLek=; b=XXhmblkdGkWAx3vzElZqRVshbu9s63Qd78NIP8MLj9/C5XiYQCuH6dxnCwoCKOAhIK6KYTd06g33vP+s/e8BkwMTEtQdwcRZlh5sJ9NOEhTSrt73zlqP+r8pFp2MkIK5a5ndbmAfW0w7OM8MUG4G9xAVP6PrhPeLtlC9+0vVx38= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: <40b411db-a4a7-4f3e-90ff-5e4936c37041@amd.com> Date: Tue, 22 Sep 2026 16:16:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/4] xen/arm: validate IRQs before descriptor lookup To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <6a94111e53249fc449b3df7700f37e026d522fc6.1790056623.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <6a94111e53249fc449b3df7700f37e026d522fc6.1790056623.git.mykola_kvach@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7C:EE_|IA0PPF12042BF6F:EE_ X-MS-Office365-Filtering-Correlation-Id: 0ce37825-7cca-459c-6145-08df18b42b69 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|1800799024|376014|23010399003|10067099003|11063799006|56012099006|18002099003|22082099003|4143699003; X-Microsoft-Antispam-Message-Info: AdniWrewZOdZz3BOao5C+hUOdRH0isDrz0vPkDqQbvEYBBlOZvepmqu4Suro83yim6ayIjb9CEw1QznUq8I7f0KCrc1WCnulL1JpvqFgRcoNoQiEzmQ4+77rFgppKT+vzuo652ACf28ffjANLyfr2D69KXM/4xRRLHrNfAZV3zMnOObpzN+hQIH8Hyr+CBwrjUdJQWp9cq55cqhbmeGfLBP8BB7Rrq9h6Z6NzBFK4r1pIoZz1KcN6bVV1DyADFJs2iE1NFwh2vrFMjhIZJCeJfnstHVxXd7bzWf1Kd85NP+Bn/A6HdXLyfBFsdt2NnfpjCbJ3EME6kzWdwO6LHtH55YTvQs/c2uSVKYdA2/OImS+lagS0GWNPmVH9mohyhEBV7nuosRT+L62Pirs7FQr3kMcB3eE/gHJ0BqGwDkMLP19nOt7nu3MB1On+CfG7zsTwvFwVto3Gm/dX8Hfp+oN8MMy83yArdXlgf6NWKfAidVhzavzmq7EPMT97kHFBLinuqU0hU5CarKokiPb2L+TTELgyV1nhHXuTCnSxoc/K9mKnla97/XMZ26mAWIigCTilOPcVHyOnV/g+75Vi35/31P12eAzTU+2P3S/8lzCKyyuFwZepZS5NBSliDyIulPDWyyyqI7tS0zyFtGz2Wk4Q4LHUsEtifnRQKeiEw9APCD2b5ZwXEZRKLzdAuZC/cKPQEzCfN4v7bp0BNGFQf9qxw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(1800799024)(376014)(23010399003)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: WIPug61okO9wkzH39COqxjpQQKQQvmr8CXEXW/jjeuNh3J/sPZlbqLcT8//JxFIYrydRTwXDpiW0GCtN2XnIqRp5sxwCYmj2mnstm9O0atAXUyMz6g+3nOlHobrCCB+5Et+YzR+ix+ONHW7RY3DnHdOXRcLFW7CYex+h84x03tXO+8dhsg8IJXfWc8thPFk7RE3k7N4mx6nC6pVAIw7BZk3ZCNfnHy8aDimrRRsV/4yy/ZoUpahabJnUbnxysX7a7Nv+oXCj7m/TuUHTY0dL71zCjT35XHH4a0W+Bh7gCp2mCHJG0dP8tCFxEow5BTv3Rmyup3GqX+tI8wm3ERIL/KVXMtRC1YZF5nq96i+hivYL7bWkmdTkFUoj/DjeCMwFVwm3vzSbbM2SUBZqJu9RBygQWCZYKkbXDR/zKPgb+sKwetrleb0J0FzAEnFV+Dal X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 14:17:01.0842 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0ce37825-7cca-459c-6145-08df18b42b69 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD7C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF12042BF6F X-purgate-ID: tlsNG-d62444/1790086626-1F262757-F2F889B8/0/0 X-purgate-type: clean X-purgate-size: 1174 On 22-Sep-26 08:39, Mykola Kvach wrote: > GICv3 eSPI support makes nr_irqs span the architectural INTID namespace > through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[] > and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs. > INTIDs 1024 through 4095 have no backing descriptors. > > Validation based only on nr_irqs accepts an INTID in this gap. > __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or > update unrelated Xen memory. > > Reject INTIDs that the GIC reports as unimplemented in setup_irq() before > looking up a descriptor. irq_set_spi_type() can run before the implemented > GIC line counts are available, so validate descriptor-backed ranges there > before looking up a descriptor. > > Use the same descriptor range check in irq_set_spi_type() and the > assertion in __irq_to_desc() to keep them in sync. Log the IRQ number > when setup_irq() rejects an invalid line. > > Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range") > Signed-off-by: Mykola Kvach Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:18:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:18:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428940.1651864 (Exim 4.92) (envelope-from ) id 1x91Kg-000265-VJ; Tue, 22 Sep 2026 14:18:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428940.1651864; Tue, 22 Sep 2026 14:18:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91Kg-00025y-Sc; Tue, 22 Sep 2026 14:18:54 +0000 Received: by outflank-mailman (input) for mailman id 1428940; Tue, 22 Sep 2026 14:18:52 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91Ke-00025l-P2 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:18:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91Kd-00Acw6-Uq for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:18:52 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28e43-bab6-0a2a0a5309dd-0a2a450bb830-32 for ; Tue, 22 Sep 2026 16:18:51 +0200 Received: from [52.101.61.14] (helo=DM1PR04CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28e4a-b7e8-0a2a450b0019-34653d0e3d52-3 for ; Tue, 22 Sep 2026 16:18:51 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB6980.namprd03.prod.outlook.com (2603:10b6:510:16a::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 14:18:28 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:18:28 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s6/JBzYmEBtoVG2KWaaulwGK0Plm1W79lGiJsYhp1jGZZaNJ7CgiZzq3fq000qjV5VAzJiTqm9k+Mhj8ioANRlVcxB1WUjBEdjw3vIzBdhG77yXO7lVdbykkA83lJaA5CgGHSMfqcYKXIT54RhMbijMErXu4n/hsLOex1svqHTbaw0eP6cnnXR2dKDqs5bLDmbw702gZZUyEruZePLYROMh4LnDPq1ceX1vvTXHX7Z3XwGJ3wuFQqV0UI4o7S/palhVvy2eyi9UduAeTycWu9P9fC7lKezbj+MjHP8kiTSdxuaKxdHjnG5m8bTVsJ1uO4axrTLj/3/hebSzUQ2nFQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uIZMBydZ5HeX0ITvM+0L2mT/tEScmM17uSdyZ1JYSko=; b=pppJuBujiH+o8iwTmok4NYHf5GLPcOURM1gyaj7e/ZZ4f6KjAfyUwromGWASPr1jXzJfTwSMSNk9rwXq+GJRNJkjEdW9HTGIB1l+nBEuxHOPOkPsGaRXDI7tEwx4OQPb1H9a9pjdL05Dk75V7PU9/frQwLW4e0ZaUJjEPP5IT9NScrL0EvPBkNcjvJzTMRBiz+KHJXMBbWMEgrGGNgy7zniiR0NKEy6fQav7ZiOo4NEETElnYc5MGhmfJH/7RCJAWIlbuSlxcXivZahSsc6qnqGD/yQ/aTRN6P7fPqDOd8D560MZn3rWQBXCdzYAWa6u1aQMAorsP9QdQXC0BSZa/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uIZMBydZ5HeX0ITvM+0L2mT/tEScmM17uSdyZ1JYSko=; b=O3OO9a8agP1Xp7B5lnox3NU8gbrw16D57uu1fcV3B908Z6shW2ZXf1mP6sPD//oqSyXv2YR/PRUzLjD9g5L7kmhn0NYUsvEhQ2A7Rusy3/IJy2S0xYeUkh3AcW6AkMKEvDqm6uN+lgpK7B2JdT9gn9TOluzrAqZoCsoBUXSBTE8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 22 Sep 2026 15:18:25 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Daniel Smith , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v2 03/14] x86/mm: get_page_from_l1e() is PV-or-shadow-only To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <4f7a34b6-b522-4d8f-a678-304ef4c0f916@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <4f7a34b6-b522-4d8f-a678-304ef4c0f916@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AS4P192CA0022.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:5e1::20) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB6980:EE_ X-MS-Office365-Filtering-Correlation-Id: 9f0e6319-47cb-4eb4-77fe-08df18b45f74 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|18002099003|22082099003|11063799006|10067099003|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: gGZvsufyTn16lO8KY0+P3UqN6jV6q4ZxuQopCOG5hcy24HTCcKQMf9sMcwT1wCbVnDhQwwputm7Lo9z/VROQPmB83u1Su7w1vSHYdOcv+g/RiuXs3Kcaf4FiehgVjW4Tox0DwcMd2vyhXp0BnZ8OyMdSAysfAUrZ9nt7OM2xFMTsja1uzqDNjyB/8JXnsnecAvr6hDfKntqTBxXsM03S0eQ7e0wn8VfKAhB2TUVKcxK4BbRf9KFmhVymUtw1A8AyZcR5LCY38ojAcbq17+kkAh7vFrwQ01OMPsDokjdduh/tAjRCoBqLPzhreZA+GLNLiGb0Vi0fG5SfrCqXFICO8CbUpC1tUhoSVLB+v9nD1Haj1vOMyq36T+6mrDD2se8FUK0YNKZlIM7XXnIdRHkldFNnpx00sXNqtdXmL8lyqqj5hP/NCTMYtH3Pv+gNPFi3y++NO1umx4i0JTTYK2XabrZH4CtqpHGAUmTZBAbUDHOccsWahxaIP0wS8EAW/BcZV+R1hbA/5AWL3twIPUq0Qv106T5mj9ivAlpoKxn/s8N0YIpAzWBFXrWi+/D/Jggavw1Inb/soqfz88dQMOUZ7hVF1Aq3KP/9ZBA45Aw1opi4BRn7GgAcb5D0WK3rleX6FPdLNwFGrGn/HeAC6URKYF/Z32zr63mBNAbS5SwpFzM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(18002099003)(22082099003)(11063799006)(10067099003)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WjJwZURVQmpNUkdlMVFSeDNZYTU5aDZ0cU1vcGR4OG4xZGVHYzJpbyt6SnVo?= =?utf-8?B?UHZNcEJJL3YwS213KzNtdWZmcUVKUmIxaG9JY0I5eGhpM200RjlwNkM2c3do?= =?utf-8?B?M3dkM0tmaEs5bms4OFVrSERlemdEZG9FL01EcGNiNlhJWXZLZTFUL2VKVmhn?= =?utf-8?B?a0tMeThvSHZUSVNZTnNseXZLSmNrQVhHcUtHbzdyMllZZDcvZytRenE2MjdN?= =?utf-8?B?VGNVaWpvSS9sVGN4blp0cVdKVmpGNS9hK2pGdTJGT3ZNZHN4Wk5iYVF1aENR?= =?utf-8?B?MlVrRGkzU05IZFFwbDI3WnhFMmRPdFAremRDaWVwRndBcUdvSjdPbkloZnJi?= =?utf-8?B?aE5tb3dqV0F1NkgrTnp1ZUhLVnV6akg3VVBQK25HYnNia2ErdVQrRkwzZmNl?= =?utf-8?B?RjVtN1Q2cjNVaHZSaWZkZTB3N2NReWJpblJaTGdPQVZJY24rVmIyU1hWN2Fx?= =?utf-8?B?M3BSckFVZkpoVkdjdmxybDk3SUlJT2JRVmhoSi90UnBkQVhaR0RnOW9GR1VB?= =?utf-8?B?c28xRjV2NzhKUkZLbVYrdGp2QjhMSnZuTmRoKytBUFhxeExNYmtDeG96L0tX?= =?utf-8?B?MzBJL1hWSUNNRk1sem4rbXFIYUpBYVdPNUtRNUwxZkh2VzRTT2FSUlI5eGJL?= =?utf-8?B?aUdHSG9EWUY1YXBVSDNwdUJYSmxjVkNDSnhjQ0NJY3pGM2NUcTViM253SHg1?= =?utf-8?B?ODY4aUdQWXlKSmkxSmQxWEdVb3ltWC82cjBVdk4xWGJZSFE5UFFJMThIUlJL?= =?utf-8?B?RVF4WTRnT3d0M21TZ3pPVk9HSmRJQkRZMkd0dm5FUUcrazE4ekRhaExEWjVG?= =?utf-8?B?Nk1VeEZBNTZ3RW9pTGZlNVd5TTY5Ym5VV0orUWttRTJZREpGdE9NM05KZ1NZ?= =?utf-8?B?OFc4M2ZSbHhsSS8ycjFRdGNjYU81cVJ4Y05zVy9JTzNuZFR5U3NxNE9uQlB1?= =?utf-8?B?ZGY3OE9YeGc2M2JsUjVEaDVMcFRodldwV3JMSjNlV2FmVEJsdnMxNmFUYWx0?= =?utf-8?B?MjNkckR6WVNlcGc4UDhZL1h2Y2JHaDF5T25HdEkyQ0F4dWtFZG5tL3ZyRGtS?= =?utf-8?B?bHhRUFlhMG10R2ZJK0RJbnZqWXFLZkVJTjI0MmlDOVN0WDVmM2JQZkQrWVBp?= =?utf-8?B?bVZoV0ZrQ0duNnoyd3NoZnRmOTlmZnVyOEwwZWErYmN2b3dqTDNZaWg2WnFq?= =?utf-8?B?WEpBT3FIbkxkOGZwejV3N3kzQVJTS3hWMWtXNkNsMjJUb2hTU1h4K3FlYXNv?= =?utf-8?B?WngyVjhqOEpZRU9LM0xRWmQrUGw3aVhPeDhhNEZ5VWhiVHo2dElTM2lCSVEz?= =?utf-8?B?Sk0zMHozbDg5VFFIQmNvbXdNM2VBbWpDNW43Z1Y0YTZ0d0oyN1d1VTBYT0JL?= =?utf-8?B?ekl4WGlSOEc4WkZRSHM2MDhRWEd6VVhNaEx5OGNhZXllTHg1SWJRaXRwYXY5?= =?utf-8?B?UWVEVWRWNTRXeEsyM0dqMUhtTWZzbzhnd3FpYVkzckxMVkJWVUNuTnNJeXlB?= =?utf-8?B?bUpIUVFtTTM5VUxhTnFGSHUzSzdpVmltTFpJOGg0dC9UekMwelRXWU4xL2Vo?= =?utf-8?B?S3QyR1dkUnFxOGJuSnAyWEd3STMySTlScUJ6R2QrZldkRFkvanMwVGUxY1FC?= =?utf-8?B?MWdQUHdXT2R3Wm15cjQrQmFuNWErNVh5Wk1ReXZpMi9ua1hTd3ZpV3h0TDBy?= =?utf-8?B?aHFEY1U3U1NqaXhDUU10NmV2YnJEYzgzZm50dWJ4d1JtUWVCMytwbU82RHZZ?= =?utf-8?B?UDZhZDIwdXBpTTdkaUtISEc3dEpmR3ozbTVNVzMzR0lUMXBIMlNKNXVLWlNw?= =?utf-8?B?SzBZSHN4bHV6bG5OVmNxOHFOMGNZN3IrM244QkM4RWQ0RWZzNkIxV1FpK0VQ?= =?utf-8?B?NUlWV3daZ0t1WXpiN1F3Q0FqT1pmU0VpZTJaTlNvTWtuSS9DWnBoNlRWczdu?= =?utf-8?B?MmMzbWJLb2s0eE90Vlc3QjBOM3JBT1VEMnVBTWo0ZStyMjYrNXVIWmxsREEr?= =?utf-8?B?MlpVWklYeXJSODJHSEUwWnFGVWloZXdFdzZLbUtrSGRXenNaY29lTENVbU9z?= =?utf-8?B?Y0h3Y1RJOFBjdmNTbDR5OCt3cVpJaFBJSHVYMENOVHhmQnRNSnZqVzd3UmVl?= =?utf-8?B?bjVpVmZnRm1HdU9CY0NRaVl6bTNQV2JsRE55SmpsNVl1czc5ck9TQ3dxOWxE?= =?utf-8?B?VFVNMkZ5Y3M3TktEdHR6dG5obDlMV05ycWZvUUQrZTQxQ252L3lFa2ZwV2R6?= =?utf-8?B?aWp3TTZ2Z202cE5TZTVwOUhKblVLdFc1RXpWMG1WcjlZbGtFRmZRbkg1VWsr?= =?utf-8?B?Q0RkTmpZUjVzWU5xK0hMeStvMThiL0duS0l6VTAyQllzZFZobTNKZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f0e6319-47cb-4eb4-77fe-08df18b45f74 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 14:18:28.5616 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ftIrMLFUQYxCceREw1XMTNxpSp0FzRIwdjQIW3SD9CeiXF0q0oO7XniKTwT27fNgO3wam03DUt8IEoT4KwuuVijeNd9Nmo/tcZVTVesoisg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6980 X-purgate-ID: tlsNG-42698a/1790086731-A8CCF9EA-32AD8F90/0/0 X-purgate-type: clean X-purgate-size: 401 On 17/08/2026 9:52 am, Jan Beulich wrote: > Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1. > With the function compiled out, its dedicated XSM hook also becomes > unreachable, so it is similarly guarded. > > Signed-off-by: Jan Beulich > Acked-by: Daniel P. Smith Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:21:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:21:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428948.1651872 (Exim 4.92) (envelope-from ) id 1x91Mu-00040Q-9i; Tue, 22 Sep 2026 14:21:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428948.1651872; Tue, 22 Sep 2026 14:21:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91Mu-00040J-71; Tue, 22 Sep 2026 14:21:12 +0000 Received: by outflank-mailman (input) for mailman id 1428948; Tue, 22 Sep 2026 14:21:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x91Ms-00040D-TS for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:21:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91Ms-0062Ue-A4 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:21:10 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28ecf-bab6-0a2a0a5309dd-0a2a4501d7e8-34 for ; Tue, 22 Sep 2026 16:21:10 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28ed5-5984-0a2a45010019-4a7de18ce5fd-3 for ; Tue, 22 Sep 2026 16:21:09 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d391aso28770955e9.2 for ; Tue, 22 Sep 2026 07:21:09 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fdaa544e5sm44041225e9.1.2026.09.22.07.21.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 07:21:08 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790086869; x=1790691669; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ctZXYyHP1vY5uEl8z6mPKdIX7/CrxbY9+jI8Oqm6ke4=; b=P2mRqQNMSY58CkfaqKwW3mX2ClfxRoLKaz7kiX/9NgVSN4LjYtOstlRVX0w9V0h6VI E0JMSNrfSqHejCZy6/u3zlRfIrZWKjHLZxsu9UIb2Bw94zc7NeekvSjTmQNdMYyeXuXr SbZYmnYoHEndMO8sgAMXmur01iTe8shXw3pCG0A/hLVp/3GilL0PuOtFFh/4773BK/QU LYsSv9BgTmE1D2lU3q0fyVwae+R82/1D5y9yDynVoRSYlJxZ2tZbf+TF3db+97sAwtyb tyBEdjmbXmWCSQVhMYt2RjEXXeRm/Kw6amqScmKJs8Pr02QewVJNTRBnbtg8IGm9q1Jm NxNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790086869; x=1790691669; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=ctZXYyHP1vY5uEl8z6mPKdIX7/CrxbY9+jI8Oqm6ke4=; b=FZWw+/fRo27LTOEKLWeyYNPyshi9CJhFS17MC50M7ezehzkZ3Z9vQ0BzAKKJynLys1 Vo4wSj0Zjrx7hJAJBMnPLTCAuoMvWY/hhOOQRaJbx4AYCQmQtvHT9poIbjIfnAhX/0VF tbQ+9uuRVGOMBV5Cl7SmacQtiooqjWWdpndhHNdIRpfx4haX/5r7mSk/UMKOg2MnV+h9 5me3NMkUUzyST0Cq+606r7RRrZqKQEGtF6aMNxNdsYCDVMd/ZVITJQOfad9MWVLaDMxD FAH0wjhMCL4h84IbkY+YsY9C9UMAjmE6pRXMxTucezDBp6oVjEFUDWk3JUbqR/7DKmud wxLg== X-Gm-Message-State: AFuF++ltgw9O+Rr6qi8wSHT086oX6+k0fu9MIiop7F3ImXgQAZ3R6+oi 4sOYHYZ4RQLZ5gaQd94bwklVt/VdbKVcCgGYw3ZBPP2J1hMLU9bM6yco X-Gm-Gg: AYBFou2PJ+LW0TlAe58TKn94ExgNaFhL6md6mlndqZRgDLNSh+53OdwWb51S/uS811B 2iFvsZJbG43EGAJKOHjz0lc202ihguOanf1D4uGJ2D59g7XoOQT/XalO40YfQwlrp/m5bdY3/kY /X6sVM0iaj/+Wly0X+M4EEG0sl6g2mUGI73DnU2/5o+Cn8v2OUzKnKwY83K9i/bdY8phPYPqaJ4 i+7AfEB1XHtjGOMOYBKqjuOaKotshoS3dWpbfcuiBnIrlUNb7US5t9u37UN8MdIypVjuO/UKTFM iZPUmFgLz9rCIQ3ah3dWbSD/2tIPYJ6hwNXUOl1JYpIJLtto1p8A18yJv0JlKDRtEBhW0pYTBts cDcJvU2W2erOd/TVCKhCBHOj06NoBzmJDTysMDvBXSHY56vrYjhi+gqJkxg7yucJSNpRx+4cWla Jh4K5jXYagp9g12G+5F6KJkGJ4lk4Qd9maGrCF6og6uCLPKlpi+QyFhTy3l1P5A4kh638DFu3CL 3mNJsFVwGHNCGvWLj6JUKnp+X+oXfhsOiotL/qvX1ZR8cbl32Ljazw9YSHa X-Received: by 2002:a05:600c:474a:b0:49c:edd8:ba35 with SMTP id 5b1f17b1804b1-49fc56713ebmr200706465e9.6.1790086869239; Tue, 22 Sep 2026 07:21:09 -0700 (PDT) Message-ID: <6bb95b82-3ef0-4931-aa21-6794360d26b5@gmail.com> Date: Tue, 22 Sep 2026 16:21:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 6/6] xen/riscv: fix level_map_mask truncation on load_start To: Baptiste Le Duc , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Zheng Zhang References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba3b8000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1790086870-1FC69757-F3CA23C1/10/73395122804 X-purgate-type: spam X-purgate-size: 2881 On 9/10/26 11:34 AM, Baptiste Le Duc wrote: > check_pgtbl_mode_support() declares level_map_mask as bare `unsigned`, i.e. > a 32-bit type while it derives from a paddr_t which is in both RV32/RV64 a > 64-bit type. Storing that value into a 32-bit local silently drops any set > bits above bit 31. > > The mask is then used as: > > aligned_load_start = load_start & level_map_mask; > > load_start is `unsigned long` (64-bit on riscv64) and if it requires more > than 32 bits to represent, because load_start zero-extend to 64 bits, we > would drop some load_start's bits during the AND. > > Widen level_map_mask to `unsigned long`, matching the width of the physical > address. > > Fixes: e66003e7be19 ("xen/riscv: introduce setup_initial_pages") > Reported-by: Zheng Zhang > Signed-off-by: Baptiste Le Duc > --- > Changes since v1: > - new patch > --- > Question: > I would think replacing unsigned long by paddr_t would be better in this > case but for consistency with other variables in the function I just kept > unsigned long. > > However, there are many variables in mm.c which are unsigned long while > they are, in reality, physical addresses and could technically be paddr_t. > Using paddr_t would also let us bypass the compiler's decision on what > unsigned long extends to (u32 or u64, depending on the target), and > therefore be more generic. I've seen similar code in Arm using this > convention, and found nothing on the mailing list explaining the original > choice of unsigned long over paddr_t. > > Replacing every such field would be a fairly large change, so I'm asking > for your opinion on whether it's worth doing. > --- I think if to do that it will better to do step by step where real use cases which lead to some problem will happen. Specifically here it looks like `unsigned long` should be enough ... > xen/arch/riscv/mm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c > index 53bebbcabf..e7f2491257 100644 > --- a/xen/arch/riscv/mm.c > +++ b/xen/arch/riscv/mm.c > @@ -180,7 +180,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_desc *mmu_desc, > bool is_mode_supported = false; > unsigned int index; > unsigned int page_table_level = (mmu_desc->num_levels - 1); > - unsigned level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level); > + unsigned long level_map_mask = XEN_PT_LEVEL_MAP_MASK(page_table_level); > > unsigned long aligned_load_start = load_start & level_map_mask; > unsigned long aligned_page_size = XEN_PT_LEVEL_SIZE(page_table_level); > ... what you actually did. LGTM: Reviewed-by: Oleksii Kurochko Thanks for the fix! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:21:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:21:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428962.1651882 (Exim 4.92) (envelope-from ) id 1x91Ne-0004bq-MG; Tue, 22 Sep 2026 14:21:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428962.1651882; Tue, 22 Sep 2026 14:21:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91Ne-0004bj-JO; Tue, 22 Sep 2026 14:21:58 +0000 Received: by outflank-mailman (input) for mailman id 1428962; Tue, 22 Sep 2026 14:21:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x91Nd-0004bX-Td for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:21:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91Nd-0001Cp-Ae for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:21:57 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28ef7-8faa-0a2a0a5109dd-0a2a4502b32a-26 for ; Tue, 22 Sep 2026 16:21:57 +0200 Received: from [74.125.230.99] (helo=mail-lr2-f35.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28f05-6ca4-0a2a45020019-4a7de66381f6-3 for ; Tue, 22 Sep 2026 16:21:57 +0200 Received: by mail-lr2-f35.google.com with SMTP id 38308e7fff4ca-3a47f740839so35120691fa.2 for ; Tue, 22 Sep 2026 07:21:57 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3a627d67d9asm6260641fa.23.2026.09.22.07.21.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 07:21:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790086916; x=1790691716; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6xiUNAhZbzRQt8xbOCQm25lVj86yCf+Eb13dZvBRGfM=; b=h62CQ7xHZgloTuPgkRHLZ4RjMhFY4IjLzLCYCSAo7/v58XF1byF7QdAnvf4Sv1Orfu /O1KYBwdSlLncnw5GKjiMkJNP7TYsNLor8mERlDwzhrU+nI358oBqJepYEMidOVmJtfA wToH9CHTQg0W1oEYYJzBBUPDsvOAUX0oVpX9xrX3mPOlrRM0CerdRWJ16calMaLnxbL2 I0RCwiSql8vEcap2qlfpgvcJ33h2wBNEyVhA/0EST9o1frSDAexgOnW1qHXni6Y5sUtS DvxT+C/nj/y12zUcucWSoeb/c1/6nyVQ3u/dhMkuafJSYAw6IHl19wMZwW4b0XohmD3c g/cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790086916; x=1790691716; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=6xiUNAhZbzRQt8xbOCQm25lVj86yCf+Eb13dZvBRGfM=; b=VW3PamDraBhMz2zrvOEUEmDkocSZQMTQxazpYr4KITbzdAlpZlEzsR8lQT3SgyXBj2 azWmY5XKPz88mq1/b91dOWQpkCdkgp+jbzfWdhA/vCQQLHJl4klZH+PuUlacz6evxqck rg7K64kD3F7n73PnYKKnGTNyVjzq4BeywWWRO7zIhDj+9HqW4iTxjWo4j33ludb/WvUJ 2N2XnHpSyJNUfHkmLog5xvWoB08Ati/+rDf+K0IeUDoRqv6vTsFGcKBt783qrvpK//Jj MuMLTgZvNdeKEkPmHImJY6mR+YjA3UOVG7pYvseluxpmOIOFQhSqtVF8RfFCpek4FIeQ 8mVw== X-Gm-Message-State: AFuF++ke4O30aeqU+uy+fzkcY5RHNQG9Xu3JxzsAu1coSKALJhymWudw rMUzekGO3xfpdV+ddZw0YmAk+uFOCa1PWIjOSoTxpMoZ9uMgnAheE6wK X-Gm-Gg: AYBFou0jJa1T2wAaaY1J9NgJ5ba8L220V3h1wzn040DaSy45/Gb3BGVWaiZWOls4TKi gLVR8y8wPss4ZhmepteSjTUPHAzCOt5/jO4FOzygRltqUj2seiiZ472UvX40xFgoOMwFRUNBNPc hoLD60JDM1bOUMx2r/GARafS2Zn0K+Kxaa4OoLjUN0CLfPavPeoGMMXz3hw4LOwvKjwyLHkarud yBEzCaZ1nu8Afjcr/xSbaTuroCQ7gkFohns+GGJTcLmsLG2QIAYrkqrjUjGaJHRk1MB4UMd6MQM czXrhVOGBDDeJAYczUpqpM4L3koH7ZAD0f8csuVzdcZv8DKdcbEec4Ye9CEwRbYEQKGBiYhhcK0 eqY5xnh5/3jGMa24kl/k0uehhNw+1VHoZi6+bwAvrrFzFJmrdApeM5TrOdNaVlDwPw9RxySOnFr Ulo4/44JXNkFNMoE1taFcnPLiaq8HgwwVzhRNiNTyX1aLhD/pHeARlrGrH54KPGjUlg0eqcUbTC DNP4D1h3ypoDRgZ2EFlc/I7oBJL3tvcPf4U8j8B72cVYDxfmC9mG5ATNTkP X-Received: by 2002:a2e:bc04:0:b0:3a6:95a:52a6 with SMTP id 38308e7fff4ca-3a6095a5397mr24620721fa.20.1790086916308; Tue, 22 Sep 2026 07:21:56 -0700 (PDT) Message-ID: <1a1d21cb-20c5-4b11-af1e-995d31fd2995@gmail.com> Date: Tue, 22 Sep 2026 16:21:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/6] xen/riscv: flush speculatively cached Bare-mode TLB entries in turn_on_mmu() To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Julien Grall , Alistair Francis , Anthony PERARD , Andrew Cooper , Jan Beulich , Michal Orzel , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Connor Davis References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba238000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789032899.8631fc262581453bbf619ec5b2062170.1a08aaba238000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1790086917-315CD2AC-31E02189/10/73395122804 X-purgate-type: spam X-purgate-size: 1923 On 9/10/26 11:34 AM, Baptiste Le Duc wrote: > The existing SFENCE.VMA before the satp write only orders the page table > stores from setup_initial_pagetables() against subsequent implicit reads. > It does not prevent the CPU from speculatively caching translations after > the fence retires. > > According to the RISC-V Privileged specification, implementations are > permitted to speculatively cache Bare-mode identity mappings. Furthermore, > selecting MODE=Bare (which happens during check_pgtbl_mode_support()) > requires zeroing the remaining fields of satp, causing ASID=0 to be > actively used in Bare mode. Consequently, the TLB can be polluted with Bare > identity mappings tagged with ASID=0. > > Once satp is written to enable Sv39 translation, these cached identity > mappings (tagged with ASID=0) can shadow the true Sv39 translations. This > would lead to translation failures since turn_on_mmu() jumps to a > non-identity-mapped linker address. > > Fix this by adding a post-satp-write SFENCE.VMA to invalidate any stale > translations (including Bare-mode identity mappings under ASID=0) before > jumping to the virtual address space. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v1: > - rewrite commit message > --- > xen/arch/riscv/riscv64/head.S | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/head.S > index 9c40512e61..7f6edc972f 100644 > --- a/xen/arch/riscv/riscv64/head.S > +++ b/xen/arch/riscv/riscv64/head.S > @@ -98,6 +98,7 @@ FUNC(turn_on_mmu) > srli t1, t1, PAGE_SHIFT > or t1, t1, t0 > csrw CSR_SATP, t1 > + sfence.vma > > jr a0 > END(turn_on_mmu) > Reviewed-by: Oleksii Kurochko ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:24:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:24:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428972.1651890 (Exim 4.92) (envelope-from ) id 1x91QG-0005WB-1k; Tue, 22 Sep 2026 14:24:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428972.1651890; Tue, 22 Sep 2026 14:24:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91QF-0005W4-VH; Tue, 22 Sep 2026 14:24:39 +0000 Received: by outflank-mailman (input) for mailman id 1428972; Tue, 22 Sep 2026 14:24:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91QE-0005Vt-Db for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:24:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91QD-004mzz-Qd for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:24:37 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28fa4-2eae-0a2a0a5409dd-0a2a4507b324-8 for ; Tue, 22 Sep 2026 16:24:37 +0200 Received: from [40.107.209.53] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28fa4-b4ea-0a2a45070019-286bd135b5b7-3 for ; Tue, 22 Sep 2026 16:24:37 +0200 Received: from BY5PR04CA0029.namprd04.prod.outlook.com (2603:10b6:a03:1d0::39) by BY5PR12MB4241.namprd12.prod.outlook.com (2603:10b6:a03:20c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 14:21:16 +0000 Received: from SJ1PEPF000023CB.namprd02.prod.outlook.com (2603:10b6:a03:1d0:cafe::af) by BY5PR04CA0029.outlook.office365.com (2603:10b6:a03:1d0::39) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.13 via Frontend Transport; Tue, 22 Sep 2026 14:21:16 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000023CB.mail.protection.outlook.com (10.167.244.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Tue, 22 Sep 2026 14:21:16 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 09:21:15 -0500 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 09:21:14 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 22 Sep 2026 09:21:13 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QM7IjKYQmg36TzDvXvKkLC45Y9vky9ixpDSotiVQRHrthWcWhfqu8Owk80Nni7198fWbfotkkF5mGW4GseWNnZDhoTyvHcAwCJO3dW7xsI2K99PqriZpZ4Vro2t4iuHj1w6lafbBFRlWSSti6BqIyLf62lk1B8GeZ7CmS4z2sgedbqxZgam8LIvtjSbwbdr5FVMamxobBsowd4I2D/fZEEVe22vgfpwNcIBiZzzpVihg9htAhWxJ8UtB07ouFAFF0qX89lwsBMkMLIRXqEwDUmY5EeoHnFVFisyuC7UtGOZyk5M3EDBrlHzpP79dsYQRGWT5LKTU0shKr1wryG0ViA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UOcZmDEQVFh+hFHW/y8ILASHFQwfF/paE8y4vWUmMtM=; b=Mt0bVn8Gq8AonSFpOrEFJGxvq5zm21i/Yv7HTdKGa0hn8rYctMfjiPv2bS66QaAhV3n5K74Ag59YcMRLV5caEePZ/FIErrdO3b/iDHZHcwNE5DjUAREFZVfRIu4kDUZM7ZiYd7qWjzhU+xuzCekhTMrTo5RA3HXyvOaOlo3B+XkQrevYT7exMh2uTMh4sDdWxNLEhYm7ZuR2B0S4m/v+Wlyl4UfYkb0bMyo1AbN4udjw3lrjc8rYrvVkPNEECttT+ZEHso0ND7MhsZD5X8jsUIIQnKrh4A9RUIDFc6tekKBPZ6+UolZaF9E70rAx+UK1CYOVP4DYvu+jZSaG+3jVCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UOcZmDEQVFh+hFHW/y8ILASHFQwfF/paE8y4vWUmMtM=; b=NApspWGFcVugzmVdINiEnGV+ZnoPF6rhpH5AUsSXOMgrmXZ+Jhhpr9IaNOdQxFXCjrEB+7l9QEDV3fod1l3LIQJ9QgaZ0Sib8JbWBQSzzS+Jgi0SZ1+3SK0ClzB1dgWkuIi9Y+9fU2JGUEO7FgxIizAV3kVFk8PzRkRMGnUqenI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Tue, 22 Sep 2026 16:21:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/4] xen/arm: vgic: free eSPIs using the bitmap index To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CB:EE_|BY5PR12MB4241:EE_ X-MS-Office365-Filtering-Correlation-Id: 068f67e8-5f4c-4f7c-f67f-08df18b4c3b6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|82310400026|36860700016|1800799024|10067099003|11063799006|4143699003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: otcUTWCkJczJGzMyAc1K+5olLoUXhcKjfG6+Grn6LaILynUhZHwf47niGoIIUWRcejDPTaaIcPiLqLTJ/WP7j88q5+2eY/2ds07FTRa0sQMbbS6462tvt8tokFgh/a7jBZI2fWthr8SHl/GPSh6Qg2BGYtTgBroS2VeklVxhdVKVpUrbk3Q0XbfjJJUUxbOpXMjiltZzcMYtl84jRrXq/+biqHza29/q1pxWel20AxFScJ9d8Sx0aF80OpZEPhpTXFXoL7iP2yAaypW/kd9kPMiU/HLK6ISb00RIO6cwjNM5KYFaQ/9H4WFNTCzvbUfcz/tWY/Cpq7HAPvx7PkuCx9I4J6BJgTb5MO9wVM/maP/oC8YITyXYn1AvqOIlWdjm3m+ZwqNVps7AnmDjz6n/i90T4SNNHbLbXwoSMgbk4z3nOUnhfdPU+jl1NwnubRWG2UcLKn8ryHnGlwoc4fq322LDWmq3EKy61K2yt9lk9wXzC6ul3rQCPr2sy+IdZOcsPbjT/sxfzSfNKTmGo+A1/ACy/0RSExht3iyC3zJU7N8xnf8BK2C9mV4B1oKBYaWWOz1fQFfDkfFVNjOxLUK7ZqPFdDGCBk4wS9pvoXyNk/etKPBBYXrU5INIKkmoBpOX6indV84BfijPG7oVI4lyr+OSQ40A49P41TK1XcvBprh3hu4qQ/3trU3N4YFp+3TIecdGSJGBg3zmFPvr8jPlQQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(376014)(82310400026)(36860700016)(1800799024)(10067099003)(11063799006)(4143699003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 915P4r3qnPyh8r8Q3/c21yEu3kUYKF6d+CKa5naiRM2IDILqJkqKEj587dBEK8jNOJXCPGl2ZyPY9pyhmG//1FtRK9+vo6PB4yeb4izhoYdg2RHKcA9eIaO9s3tp3fkb06Pho57PbqM0t2DUVj72clLuzuj09wRZHiOEiZadyXniDLP02YZPwHJvjabNooL7O0tPtoFWVT0LKoqgnCq5qnFZ14K8a05BXYVvVl/AlsR0YGlPplv6xFOeP5ZcId9Gjt3e4laoYnOUn5mD5YtWk3CjCn9AEmNl5Xa33tGHARoVwOc42jUg07tB4WfLpg3G/mFKBHN2iYj+4d7l1nPe0b1Tv5D/NxO5aiOOoUvg1ElCJRRdl3IDxNwJgOMh5lIhWwy2s2gAJbN0vT4h97vWeMAX4L8FjYOgvWTG50VI5Nt21THG+F3jyJjta4qFQ+dH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 14:21:16.5342 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 068f67e8-5f4c-4f7c-f67f-08df18b4c3b6 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023CB.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4241 X-purgate-ID: tlsNG-ef75cf/1790087077-350CDAE4-2C924FA1/0/0 X-purgate-type: clean X-purgate-size: 895 On 22-Sep-26 08:39, Mykola Kvach wrote: > The allocated_irqs bitmap in the existing vGIC implementation stores eSPI > allocation bits immediately after the regular vIRQ bits. > vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index, > but vgic_free_virq() used the raw INTID. > > Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit. > This writes beyond allocated_irqs and leaves the intended eSPI bit set. > Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind, > and during vPL011 teardown. > > Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving > and freeing vIRQs. Validate a vIRQ before clearing its allocation bit. Please also add this validation (just vgic_is_valid_line() guard) to a new VGIC vgic.c. It's eSPI agnostic and we should keep them in sync if possible. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:25:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:25:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428977.1651900 (Exim 4.92) (envelope-from ) id 1x91Qm-00061U-9Z; Tue, 22 Sep 2026 14:25:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428977.1651900; Tue, 22 Sep 2026 14:25:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91Qm-00061M-6P; Tue, 22 Sep 2026 14:25:12 +0000 Received: by outflank-mailman (input) for mailman id 1428977; Tue, 22 Sep 2026 14:25:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91Ql-00061B-5G for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:25:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91Qk-004nIV-I4 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:25:10 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab28fbb-2eae-0a2a0a5409dd-0a2a4507b596-34 for ; Tue, 22 Sep 2026 16:25:10 +0200 Received: from [52.101.43.0] (helo=SJ2PR03CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab28fc4-b4ea-0a2a45070019-34652b007964-3 for ; Tue, 22 Sep 2026 16:25:09 +0200 Received: from PH7PR17CA0061.namprd17.prod.outlook.com (2603:10b6:510:325::11) by CH2PR12MB4327.namprd12.prod.outlook.com (2603:10b6:610:7d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 14:25:02 +0000 Received: from SA2PEPF00003F61.namprd04.prod.outlook.com (2603:10b6:510:325:cafe::e) by PH7PR17CA0061.outlook.office365.com (2603:10b6:510:325::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.13 via Frontend Transport; Tue, 22 Sep 2026 14:25:02 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF00003F61.mail.protection.outlook.com (10.167.248.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Tue, 22 Sep 2026 14:25:01 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Tue, 22 Sep 2026 09:25:01 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Tue, 22 Sep 2026 09:24:59 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AyURv1WWmopIPslncxza23Ohs4vPmQin/hqOIPBB1vyTJc5yndjEtilxEXK8bLJWq4+TvPyvga4tScmJPI2Ql5WoMMBSkKUaHg/4T3rmNjCb0csMTIgwrCB5DzA6OPt/pIngeiiwVwfV5DQP8AEt1ZEdl52Ozo/M+GdApBu6FN/YZN8rMjT5xJJ94zri1NfoZFm1QojRtkb6p2jKGLrWlS1giHJPVP+1fNnqJ/QQcVns+UAMvD9iWsn1mhc+qVqMs0utN8RVSrMsu6HT3FdseVTY0F/Cp7eoMCie8RCoyBWkvVuBc8FzJ+NLLZgDPupYqdr5mfOSgWJ7diGfBwEnJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5qG0XuocjWs6WiHLtjd0Q4a+ZOxxKSdKCQzn586RzgM=; b=sXQbkE5obV5t6Tht1bZNj+l23HpJQ9xBkkOsO5CiTJ0AZltV7eGkT4VB5odUYJrL98IvhT2XekPOWXGNwSBH5B9XBy044C7wtp00DtszAUaDHmxmrKw8VzfN6pz8vucNoE8ZImHfWW5YMIuwvLX+aEgaxyVKXcpng7PgVnt6dIjLnWwvGEBF/cdVjwTgsktDZqcpSprLunn4ixxyGcEvOkku79z/lTDOOILYRfGCCCGLJHOV6GIk6WvJSp3uHp1q7tiRLwrw1eMBRwerwtVuBk0Zg3GVjkRjGrG/wWSfMeH9l53HSuBtdwUv+V44lUTH7unfKiCiI2zQryyxhbtf4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5qG0XuocjWs6WiHLtjd0Q4a+ZOxxKSdKCQzn586RzgM=; b=2sga5If4SVTIZOAp1g+7TakWPU8vI5dKeiTe53ZVX1FHXjdEzQngyq9HQvQPz2cnKLX0KR5dmpNHiVd1qyvQdixa2P8aY9sjLJ9GXeB55qIrrNjmzixmXzigJ/JPkSMkmnP6aKAGJQLTooPD0l3TyfRgEWEW+dHpsPDlWTRhhBA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Tue, 22 Sep 2026 16:24:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/4] xen/arm: handle irq_set_type() failures To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jens Wiklander References: <85c5f8f04b19eea8d32e875a8b7e94f4ebb88292.1790056623.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <85c5f8f04b19eea8d32e875a8b7e94f4ebb88292.1790056623.git.mykola_kvach@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003F61:EE_|CH2PR12MB4327:EE_ X-MS-Office365-Filtering-Correlation-Id: d7b6682d-1095-4820-86d3-08df18b549e7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700016|7416014|376014|23010399003|6133799003|18002099003|22082099003|11063799006|10067099003|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: Nbqo8cT6DzTO/S4jqLlw731wF1x8OLp26aWM6DQRgzluIryRuxvJpxSGjEZbPmrZExJuM5nJBNj47pgDD8GMXKIsU8CIXd0uH7nwh5U/vIVLl9CZDlXqHTsON5aAmEyhV15TuBsN0fK3gaYOkM0GsUz+8SCOGXJyWNltA6FlV7E3zFoj71vwGql4EepmrHrvAfA/YTMSzvxjW3TiDQt5gG5whyYfwasVOlAQnCvWu1+nQbIob/ZgrVXgh2eD0eIl/D4C7X5jXCe113EP6ZHWrRZH+kJ+KpkgaoPoA7ExHXr/G4R+64lX9yEzs6UzuFcLCDb+SrSKpbc5sWNxvDHil/IYLRtpohru4yp2NwW4WEH0qY8eYswUrqQ+m5KkU4B+bcM94Sjh5RB7LY4DBN6t0TdwzaAXUwSXAaKnG3ZGHt+frf4apnPHWENhACMVTcT0fUM8lnPliyrngRyqtZ6tt7JyV1Nq3Zkg5ywrtC+PEYbREYTIWILGehR/WNbVNBD0Jq677UgNCySrkL6X2VpX9nP4kfztMp7hiOFEWiYdxGg3WVMDRn4yXSjZ0yb4wggJdSCgaVZP9H0zl4Lm7hHnD7bbzcyzcyO9EOzu5fx3dDKrBTB1TfmSP8dTRbyrTS1ehPpYKVJY4p9sY/pYF0xMCZtxc6rjYNyj+tH7RpRKfP6xnHyIcBOXCW7uQaY6be8+jRJ3Nxn5yx5NkdJ7DfjMMw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(7416014)(376014)(23010399003)(6133799003)(18002099003)(22082099003)(11063799006)(10067099003)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: DPYyN6gcB+OGn+WzJQmFtUNFhtNyxu2b8/GIInFBzQ0zgUfBoICMDZuMMjvCFa5KiaotT6XJba3S4ohFwvgpeXwou6+H4O+A5/8PBP7CjtzhN7tidh3vz7Yo7K9989xBB3CHSDQKh7ZWBZgHywvd8XsyxDBDC2F2c38zLxq/U4/Uoz2Ac0y0SxBqU74XK+m2QzUVKH1A7LAN4BHkvEyMRhGVKQ/v3/u2JP9Qv3rlaBDJ5q/BqG+w/70e7mx5jzz/Zz56QgPUHKQWqpmVMtvUaUbIh+yYSYm+mNrN3HD4N+hACJ5eH8hQrN5AP6jui767DQ8py9kSd4++Nox0g36s5JeWDG3qNU4PIw6Ixmy4qUZHBGgBa02mORibjctZoOKH7ebqBVH1YtnRCSfUZ7wiMZOhixrk4mmENDOA7nelS1q8/jTd5T8G5FpGoWvBBI/s X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 14:25:01.7342 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d7b6682d-1095-4820-86d3-08df18b549e7 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF00003F61.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4327 X-purgate-ID: tlsNG-ef75cf/1790087110-A7ED6AE4-B8F95524/0/0 X-purgate-type: clean X-purgate-size: 1187 On 22-Sep-26 08:39, Mykola Kvach wrote: > Several Arm firmware initialization paths discard irq_set_type()'s return > value, violating MISRA C Rule 17.7. If trigger configuration fails, > initialization continues with an IRQ that was not configured as requested. > > GTDT and MADT retain rejected timer and maintenance INTIDs. > check_timer_irq_cfg() and release_irq() later perform unconditional > descriptor lookups on those values. Xen has no backing descriptors for > INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds > access. > > Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store timer > INTIDs only after successful trigger configuration, make GTDT parsing > failure fatal, and stop UART or notification setup when trigger > configuration fails. > > Signed-off-by: Mykola Kvach > Reviewed-by: Volodymyr Babchuk > Reviewed-by: Michal Orzel I asked you on v3 to reorder the patches, so that this one comes first (usually when sending the series, fixes, improvements should come first so that they can be immediately taken). ~Michal From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:26:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:26:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428984.1651909 (Exim 4.92) (envelope-from ) id 1x91SE-0006nR-Ja; Tue, 22 Sep 2026 14:26:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428984.1651909; Tue, 22 Sep 2026 14:26: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 1x91SE-0006nK-FA; Tue, 22 Sep 2026 14:26:42 +0000 Received: by outflank-mailman (input) for mailman id 1428984; Tue, 22 Sep 2026 14:26:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x91SD-0006n8-0h for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:26:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91SC-003Exz-Dp for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:26:40 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29012-bab6-0a2a0a5309dd-0a2a4505bf42-38 for ; Tue, 22 Sep 2026 16:26:40 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29020-4cb1-0a2a45050019-4a7de14ca6bb-3 for ; Tue, 22 Sep 2026 16:26:40 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f63546c3so3344282f8f.1 for ; Tue, 22 Sep 2026 07:26:40 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-488627314d2sm5572350f8f.2.2026.09.22.07.26.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 07:26:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790087200; x=1790692000; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=A7Sq8j8QIedgbYpG7RY4msDcbFCXXkohdyLjyVH/YZQ=; b=Mai0xYeOsNBuvd4xiygRb8442MdSj5nS6eJb6M7ile+pbXh+S8jbIAAfUVHUq8fcL5 dz26q71FDv6c4Az+/vDNtYBld0xXO3uD2UG8SUbwwlUloXyHX0ww+rPCWbGh7pEe8o3G 1NfHGk6QU6bWHG3CxIjynnYI/Ej8hxmMmE6mjfURnfEv/uHNb2twn+Sx41Eg620F+Uoh gUzBiFsUnginIVIKvVhxD+xc1UkQO/pN8pJr5RZg6AIdFuGVD7ULYpdEdGv0ujd3a/1o iCN9weTLBtsFHq4Ak0YPw7Otp+4NpuwhB5iGLVxBRYxjgXkjE+ZZZP8zY98REZRpFGPz xZlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790087200; x=1790692000; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=A7Sq8j8QIedgbYpG7RY4msDcbFCXXkohdyLjyVH/YZQ=; b=wY6gYpHe+tCRADMnYIoaWrg3HITcwMqvgzTjIvrHbc0RRqyMvRH7dthxUp1MsvI0AJ c+nkSz69vaxwaBMqr02ktYlNRE6W77ol9Vh1u4yyjNuhUhImxlI+TXrQMHO54+Xk5Wt6 J7eoVSC/PCJLEHkuTAvaJets2ePu2PPNdCmkgax0N1F/MJZD0WryCEVBGyGnSuOnnfvJ yNMU3FI+VxHjSact2iTNx11cYHRd/TLnjAndHbNRVgw5T79JZp9L3OkYrXowzaJ5M6E+ MJt/8djVZA1dfkuciEyEibQslncpmgDulCCc1mG1qzk2GTHlKEfwjTkKS/tJIU+4pdC2 UnEQ== X-Gm-Message-State: AFuF++mY1WVYq1rO1++HlX03LY80AiN5cU6b+RAVyGVOliEPhdeX298t WiFS3t0ZGzF1EWrGZt4F+VwYtJHDVf2VDC7gqSPST2LhgpIc8H0UnYRV X-Gm-Gg: AYBFou2xrShicVLO2kMp4NLcwmNFR5ttYqTRTFyPdNhrcKt3Sf3Lz0tSAI/VhzaL/2X hIJrWvcUFc2L+CMCJOY1guYYV9+7jG1wLfDDB7ckmLUMRU6zhm+oQZkCzEgvvTmnet3M2Fgy2RB bCJo5mtywoAPXRWrIzCfxjXEea+2MLR3J5SJ+dZD55X3pdQTcC/xJHsw+ZH32PLpI2iRhEPTAMV 1Y/UH2E0YBqbDVKapJhmVuggVJjWo+663QwxuAfbPcKIZCO+GJzIughwgiB/AOmRKLq/JCGwQiN hy9rqYsUQAb4SeBpN5TGymEMR43lO2fz1gMW9HgsmGQQrtQR6TTRRI5mhEZz5BryNw07ZWuLIJ8 zWlEO7cPhmLQ1enwGjpNrg4w0Rfg8LgIkq32gxQO3UEJhxaM8mVaLPPYahyg9PZ4stEonCApwv8 03QIljAZq5tCewe7HoqWf9H/spGlg/WrS1IdgAseVOGpRPHB5werM7KlNrP2hxB64Gw9vQMjZ5t vt2zvxzqdci4fZ2zBotD2cXEjFfkV8pf3C3Q4Rzt/e7kGnaaQ== X-Received: by 2002:adf:e18c:0:b0:487:b00:3853 with SMTP id ffacd0b85a97d-4871e269d9cmr18711365f8f.27.1790087199779; Tue, 22 Sep 2026 07:26:39 -0700 (PDT) Message-ID: <66104177-def7-419e-b6c6-55c3cbc04ddc@gmail.com> Date: Tue, 22 Sep 2026 16:26:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/6] xen/riscv: make Zihintpause no longer a required extension To: Jan Beulich , Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3@vates.tech> <20c2003f-910b-4e9b-92f4-5298f11f58df@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <20c2003f-910b-4e9b-92f4-5298f11f58df@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790087200-F5CA82A1-6D5B9AA2/10/73395122804 X-purgate-type: spam X-purgate-size: 2149 On 9/22/26 2:27 PM, Jan Beulich wrote: > On 10.09.2026 11:34, Baptiste Le Duc wrote: >> required_extensions[] panics at boot if Zihintpause is missing, but Xen >> never actually depends on it: cpu_relax() only emits the "pause" hint when >> the extension is implemented, otherwise it emits `0x0100000F`, a legally >> valid FENCE instruction (`FENCE W, 0`) rather than a native NOP. > > Just that PAUSE's encoding is 0x0100000F. I.e. what is emitted is always > the same, and hence discussing the encoding aspect here doesn't help > justify the change. NOP or not also doesn't really matter here. The > specific hint encoding looks to fall into what prior to Zihintpause would > have been covered by "Designated for future standard use", and hence ... > >> FENCE is >> guaranteed by the RISC-V base ISA, so it never raises an illegal >> instruction fault. With an empty successor set, it enforces no >> memory-ordering constraints and thus architecturally behaves as a NOP. > > ... there indeed should be no concern for any platform playing by the > rules. > >> Drop it from required_extensions so hardware without Zihintpause >> still boots. >> >> Assisted-by: Claude:claude-opus-5 >> Signed-off-by: Baptiste Le Duc >> --- >> Changes since v1: >> - rewrite commit message. > > I fear another round of re-writing is going to be necessary, sorry. Would it be better: required_extensions[] panics at boot if Zihintpause is missing, but Xen does not strictly require hardware support for it. The PAUSE hint (Zihintpause extension) is encoded as FENCE W, 0 (0x0100000F). In accordance with the RISC-V Unprivileged ISA, HINTs are encoded in the space of valid standard instructions. On platforms without Zihintpause support, executing 0x0100000F is treated as a standard FENCE with an empty successor set, which acts as a NOP and never generates an illegal instruction trap. Therefore, Zihintpause is purely an optimization hint. Drop it from required_extensions[] so systems without explicit Zihintpause support can boot Xen successfully. ? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:31:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:31:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428997.1651917 (Exim 4.92) (envelope-from ) id 1x91XH-00018w-7K; Tue, 22 Sep 2026 14:31:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428997.1651917; Tue, 22 Sep 2026 14:31:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91XH-00018p-4a; Tue, 22 Sep 2026 14:31:55 +0000 Received: by outflank-mailman (input) for mailman id 1428997; Tue, 22 Sep 2026 14:31:53 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91XF-00018e-85 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:31:53 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x91XD-00BBqm-1m; Tue, 22 Sep 2026 14:31:51 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x91XE-002cJP-04; Tue, 22 Sep 2026 14:31:51 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=rZVWmg66vbC05uITk/fmvmFmAIU5kmmNjz+n5/rMt+0=; b=O6I2TSzQQhmDP5MXWQ7nnBe1M8 +yzYCXTVEwUDIIr+L2TC/3KGNN23d8x21l2QAOWVNtN2/vhm792dKCBoswZcs0cl4iIrkYv6QARLN sFi01JHRZIyXvkFY3lhINopHFIDHSJ0gPPXew8tgMbHTaOOyy1cYset81Efo1nFe/0qU=; Date: Tue, 22 Sep 2026 16:31:49 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Nicola Vetrini Subject: Re: [PATCH] automation/Eclair: tag directive 4.3 as well as rules 17.2 and 21.17 as clean Message-ID: References: <7a9080a2-6411-40f0-be7e-f08909c19501@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7a9080a2-6411-40f0-be7e-f08909c19501@suse.com> On Tue, Sep 22, 2026 at 03:41:48PM +0200, Jan Beulich wrote: > These have been clean for a while already, without being marked so. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:32:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:32:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1428998.1651927 (Exim 4.92) (envelope-from ) id 1x91XP-0001RQ-EM; Tue, 22 Sep 2026 14:32:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1428998.1651927; Tue, 22 Sep 2026 14:32:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91XP-0001RI-BY; Tue, 22 Sep 2026 14:32:03 +0000 Received: by outflank-mailman (input) for mailman id 1428998; Tue, 22 Sep 2026 14:32:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91XO-0001Qb-74 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:32:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91XN-00AGBX-HU for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:32:01 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2914e-bab6-0a2a0a5309dd-0a2a4502c010-40 for ; Tue, 22 Sep 2026 16:32:01 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29160-6ca4-0a2a45020019-b9ff1c229031-3 for ; Tue, 22 Sep 2026 16:32:01 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c987ccc300072c4.005 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 14:31:55 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 45626823B0; Tue, 22 Sep 2026 16:31:54 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=HqtEdkqWsTQdfBxLXjD47jIsUqZfqdpt8rlAnYFzdBM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=rAj7EUHLQsyYTDF9y6TZVz5957zAVnODoWbR4h/HHe4wH/3GJPs0PhwsgkBvRaDHjOoL/W1TB Wxt/YgSKERO2oCgtqEFn+Trk5zM7bwpGx0ZcP+T/8BcGTxc5uYaZYVLUaGX27fBF0TDKXjizrse FRTOKZ4dNfHRnhu8r0LNQ9ZMFCjHnCMtdOY0o+gltec3qTJ3z7bPfonz0EYXU9xxZzPc/XgH/65 Sx5QcvJm12hgrrTB0y1GZwoe0HWcozWwe7TOhOYqii4BKuSsD18ER2wW8lh+XIbqtW/I0WeobY+ FzPN14gLNPanFXJuadq3hwwxgEOX+zC4zr+FcXxwAjsA== X-Zone-Loop: d4cdb94cf27f4badd58abfc1e5fc2bb063297568fba1 x-campaign-type: default x-transaction-id: 232f421c-f8c2-4bbe-b4ad-d28a53ad27e4 x-swg-uid: 01-5515bba7-72f8-45a5-9148-c6474579c167 X-Mailer: Sweego Message-ID: <1790087515.8631fc262581453bbf619ec5b2062170.1a0c987ccc300072c4@vates.tech> x-swg-bid: 1790087515.8631fc262581453bbf619ec5b2062170.1a0c987ccc300072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [RFC XEN PATCH 00/13] Running bare-metal tests with "pytest" From: Baptiste Le Duc To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, Andrew Cooper , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Anthony PERARD , Doug Goldstein , Stefano Stabellini In-Reply-To: <20260922100900.29129-1-anthony@xenproject.org> References: <20260922100900.29129-1-anthony@xenproject.org> Date: Tue, 22 Sep 2026 16:31:47 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790087509; l=1456; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=S8sPD3/M/rDXTNp+0YSXenuDu8JcbKmbZCkHux2Y+Uo=; b=qnkto6tG416RUOjFhFrfd/Tqdcn7BtpnBRQZfVJBzzacViKD9ApBprb3yQHkRKw3AkqX77Zkv 65q1/+hNTJGDBQjhRqaA/grP+GxhArJrVh0Lg65J3RlgPveRlRNfgKK X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790087514400 X-purgate-ID: tlsNG-720697/1790087521-307C22AC-A6FE1DE4/0/0 X-purgate-type: clean X-purgate-size: 1456 > From: Anthony PERARD > > Patch series available in this git branch: > https://xenbits.xenproject.org/git-http/people/aperard/xen-unstable.git br.ci.bare-metal-with-pytest-v1 > > Hi, > > I wanted to add some new machine to our GitLab CI, but I didn't want to > duplicate yet another time the existing shell script. They are good to get the > ball rolling but are getting harder to maintain as more test are been added, > and don't share common code between machines. Hi Anthony, Nice to hear! I reviewed it quickly and it seems to be a more maintainable solution to add machines in the CI. FWIW the patch series I sent [1] also uses a python-driven framework (QTB) which aims to replace the existing shell smoke test scripts. It's QEMU-only though as it drives QEMU over QMP/qtest to manually trigger some IRQs. So, it doesn't cover your usecase for the moment as-is and for the moment I don't see a possible common abstraction between them but worth flagging. Moreover, do you think we could replace the QEMU smoke-tests by using your framework? With a very quick review, it seems we could just add a pytest fixture machine_on_qemu(). If yes, then it would definitely be an overlap with the usage of QTB I described above. [1] https://lore.kernel.org/xen-devel/1787823334.8631fc262581453bbf619ec5b2062170.1a04293255c000c4f3@vates.tech/ -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:38:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:38:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429010.1651935 (Exim 4.92) (envelope-from ) id 1x91dU-0003Nu-1s; Tue, 22 Sep 2026 14:38:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429010.1651935; Tue, 22 Sep 2026 14:38:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91dT-0003Nn-VF; Tue, 22 Sep 2026 14:38:19 +0000 Received: by outflank-mailman (input) for mailman id 1429010; Tue, 22 Sep 2026 14:38:18 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x91dS-0003Ne-Sj for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:38:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91dS-0003vP-5Q for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:38:18 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab292c6-bab6-0a2a0a5309dd-0a2a4504b93e-40 for ; Tue, 22 Sep 2026 16:38:18 +0200 Received: from [74.125.228.170] (helo=mail-ej2-f42.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab292da-b57f-0a2a45040019-4a7de4aa805c-3 for ; Tue, 22 Sep 2026 16:38:18 +0200 Received: by mail-ej2-f42.google.com with SMTP id a640c23a62f3a-c254f6c7a56so509161066b.1 for ; Tue, 22 Sep 2026 07:38:18 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2a9c5b2d17sm100643766b.36.2026.09.22.07.38.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 07:38:17 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790087898; x=1790692698; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ijelvjpV/j5YwDiQgvuM4OExfRmt6Zi4hbEk3BZURWo=; b=m4RM7q90rkJTM/zJS/SApExlM2g6v+uYzcP7MgMx4z794xRn2RJCBzH9DlbMLqm6s9 X+E4g/upvOh0XiDzT47z21tPTCKMTPes+b9UULbtZDFy+HhrJN138qyDx0W6mfo3q4gP tSTH/oaFx2M3ts2xj6aol0G27oz8zJoPhwhtQEmRAZlv5PlCL2GM0fxtU4W0YZgx4OmQ W6G+IPlCb8KJYQ01aHyTd68A4rL/Hkaf+GCM139gFXcivGBmbSz9z06SxqFK4FrXlupt VIWk4LvVcfBTuB7M9RS6BvfY4H4Q9HzPTZmz8KVAwTIICiT+1kQ6WMtnMY8ejJe2SKuq pUSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790087898; x=1790692698; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=ijelvjpV/j5YwDiQgvuM4OExfRmt6Zi4hbEk3BZURWo=; b=xX+5fAflT7Ju4SofBQ2VDESpEUah+kqrHIVQU4E3JXt7XyUbhMoLKdQL8trz01QgmJ pFeG2qkKAV21xJxkFenPDTyLDn5EEPzxT9v1WJEvmNzKIp8Vw6T6UXi8zXT/iGjoUzu1 BcNPZn7dwxgfgJJFQNmDpJWZJcK4GYkjCgS30OyHauei5Ff6WZEwYNAYem++IFHu63Ay wxQ168pYCx+Nl5TmDgjZFkH7KS/uBIG0LNZwK9ffQmzobtA+WlvAfm39lPIQPS+w4L6u 97Nm3FUj4ywK/JMB/ezhe/J7MD+FLyBam1czYh6/1vjQpSTlM3brmtF1R+sDnF/+i0cZ QzBg== X-Gm-Message-State: AFuF++k8FwotCTkYbwaYy9xygAlPz4AOVyKLESn6DDvYbbZhoUXAnNKT +8Wq5Q2E7REi+Aw/uwXce7vpxRCTLd+ha6VyFNiqeup2gehkIqVGFP62 X-Gm-Gg: AYBFou0GiZTzkuHpZgGqzEyLpN+yC8WVIn/LGnlsolZNR1y+YCJNtt9OzksvezVTxZK +2I8BXwQ0/P3XUrwr2voXvwljScp9Z/Uulj/J7n2kgUfmB2lpLs5XSevEzmkRvSUi9uALDxpvdD 4kF7I3C1A08neEWqSf3i8vvsRvhyOBARnVjWAvtGtG4DFEbd6Qor9K6bsRcQHC7NjtDutzQbh0G iruvONZhj6WUrBSYlEG/O1zq5MMWH10fmqrSOP4CYYichcG9uHVU11/+cZTwB10UNIlPn4B2HQb VMLXkN6leuCeCnakRJ6x8IxvvcVfF5Zn9QLZzav9t8ZipWWeZQ3ZmsSmlxkgerkvxIzZSa1BH/1 m3yUXuinCYalQMeqB1Y9Diwy+c2NImH5bZYRlx0LEquZVn3WsIrgogwOzWG0W+KRJECiXqc1eej Fy9e8cGNYfI/ZnQtmbink/1YRL1zmfxZakv5/FMqQ0kg52hEQH4V7DdmfnXwd/wcm4FBGQHdJh2 cM12b2B2MpniEL8AATf1aeOJ/b7W6KZu+vA0VTEuB9lgXIoMg== X-Received: by 2002:a17:907:7284:b0:c29:52dd:317b with SMTP id a640c23a62f3a-c2a15aeb6b6mr1362332466b.29.1790087897619; Tue, 22 Sep 2026 07:38:17 -0700 (PDT) Message-ID: <04564edb-95e8-4f7e-a148-7e3533ee38e8@gmail.com> Date: Tue, 22 Sep 2026 16:38:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/6] xen/riscv: make Svpbmt no longer a required extension To: Jan Beulich , Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3@vates.tech> <9ea9edfc-be76-4507-8b71-a483daa9e7d5@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <9ea9edfc-be76-4507-8b71-a483daa9e7d5@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1790087898-C34C3B50-FD4A73DB/10/73395122804 X-purgate-type: spam X-purgate-size: 2278 On 9/21/26 5:57 PM, Jan Beulich wrote: > On 10.09.2026 11:34, Baptiste Le Duc wrote: >> Without the Svpbmt extension, memory attributes (such as cacheability and >> ordering) are strictly tied to physical address ranges and enforced by the >> hardware's Physical Memory Attributes (PMA) checker. >> >> In this configuration, supervisor software relies on the platform's memory >> map: >> - peripheral device registers (MMIO) are physically mapped into >> hardware-defined I/O regions (which are implicitly non-cacheable and >> strongly-ordered) >> - regular RAM is mapped as cacheable main memory. >> >> S-mode paging can safely map these physical ranges without specifying >> page-based memory types in the PTEs, as the hardware MMU and PMA pipeline >> will correctly bypass caches for MMIO accesses and use caches for RAM >> accesses, based on the target physical address. > Provided firmware got absolutely everything right. Yes. S-mode has no standard way to discover PMAs, so it has to trust the platform here. Note though that PMAs are in most implementations fixed in hardware rather than programmed by M-mode firmware, so this is mostly a matter of the platform's memory map being correct (and of the DT/ACPI describing it correctly), which we rely on anyway. > >> Furthermore, on platforms that either feature fully hardware-coherent DMA >> or don't expose non-coherent DMA agents to the OS, page-level programmatic >> cache control via Svpbmt is not required, making it safe to boot and run >> when Svpbmt is absent. > Yet a fully coherent platform should also be possible to somehow identify? To some degree, yes, via firmware tables: on RISC-V DT devices are treated as DMA-coherent unless marked with the "dma-noncoherent" property, and with ACPI coherency is expressed via _CCA. What matters for Svpbmt specifically is whether a non-coherent device could be used at all: without Svpbmt no NC mapping can be established through page tables, and without Zicbom there is no standard way to do cache maintenance. If neither is available and the DT describes a "dma-noncoherent" device, Xen will want to warn and refuse to assign such a device to a domain or something like that. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:40:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:40:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429016.1651949 (Exim 4.92) (envelope-from ) id 1x91fa-0005WD-LU; Tue, 22 Sep 2026 14:40:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429016.1651949; Tue, 22 Sep 2026 14:40:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fa-0005Vm-I1; Tue, 22 Sep 2026 14:40:30 +0000 Received: by outflank-mailman (input) for mailman id 1429016; Tue, 22 Sep 2026 14:40:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fZ-0005TO-3T for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:40:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91fY-00AHxl-GY for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:40:28 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2934d-bab6-0a2a0a5309dd-0a2a4506e4aa-24 for ; Tue, 22 Sep 2026 16:40:27 +0200 Received: from [40.107.159.85] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2935b-195a-0a2a45060019-286b9f557f3a-4 for ; Tue, 22 Sep 2026 16:40:27 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV2PR03MB11837.eurprd03.prod.outlook.com (2603:10a6:150:36e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 14:40:25 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:40:25 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zP1YUBqBDm1iekR4RVssmPjGqEPEmSYCPGeooqn5fs6or4Mtl/92S2XF+w7zF/yn6blfp3NNNWz4o6FgBrsXqwSo+VEsQoeeKvfiMhbE6CIcntUEq+tNSePPnglYLv++mMidGJTCw9PbiOKRbyNUXayD1UmE5s8y67Ej4/KcTXQi6WaeljovcUxw1i8KBf5foK+O02dfp8tM2osHbB8RJl/g5/mufS49Yll7i6Cb6fJsIVN+prYTzCxf4f571qgMKg3YBI2dajf7PqZRfztPYLW2Laclpbsc3T1oE2AwBOdj5+udjhUhSBOHDxrTxLcfzH3b/7Q17Pb0LH1skHSPXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NbO8+AUtmxzEwXw519OUt+YFsVuyNoCYBe8TB5s7/Y4=; b=gp+n8KI2y6n4Cxhj7lbHZGrs7MAT1Fu7o3t+UfHuOxAvAUfQBuxiMjp7E9o8pfO1DRIX18bIq9gWNvFJAMl6xO32n8X/1OxoauO0qhQFuiJvBnHV4yTuZSN/jYgUxu55PULN4KQB61gts2Rs7zB2xJxkdvzDdRL4CSNVCAmkMc3yLJyM5erB1HonZR57EEJCR1i+N9PE5xr+AhTL07b7HCBLNsr4B+0YENYIoaXR2k4RSp/rP2dosoaatE1VlgyaDXP7WjsfBSbZ6KvWljpVvCIumoRUeuIGYT4u//B42VALJLPRMCQfbeTLnC5lrB+NIr5lqVpyEWp5AqdZLRt/TQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NbO8+AUtmxzEwXw519OUt+YFsVuyNoCYBe8TB5s7/Y4=; b=lQih5UB6aIp3bo6bXO8zvSQJkl0GJX8IdWwyCl7IAf8fLPOZ8OMnjaxPBOg3ndPyfgDN2x7iJjPluc/CRjYRMGpOZ2qkGNZOgPogFNPwwUh/SvE1KjuX1/S2s4EG+pmsvpruG4Cm+4hTVfYJVboYjQdEENxkOg6L9LxGjfi7tayPQT5xAAP7VSXhp5auX0QaOhSleStkiSWr9iIYfnxT2EaOXRXXpG87TwbGtyoHhxDFmYdrs6QzkXqGcCTLnXYuLRz+hx1P4gfZh+sjDrkbY6vI1WD7qfK/3OYhOcjqTu7TVf0vJ1hn4BAckjpAXIT680mDIqgMSeCuG/LGdjoW5w== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v13 1/6] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Topic: [PATCH v13 1/6] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Index: AQHdSqBNTsRaFY22HUuVlBJ/nDlBag== Date: Tue, 22 Sep 2026 14:40:24 +0000 Message-ID: <2994db05229aa026a8a00de5287a93d90b31c660.1790087968.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV2PR03MB11837:EE_ x-ms-office365-filtering-correlation-id: a00e4934-c477-45c5-328a-08df18b77063 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|366016|1800799024|6133799003|18002099003|22082099003|11063799006|56012099006|10067099003|38070700021|3023799007; x-microsoft-antispam-message-info: RysltWSMcoXHPgVXUFX8T55G5cwBtlmDZ+wcbc9wMPvHqEJA2cUOKklQmiMjYpWeW/up5K7S97yFgIGHJC5B/NHlIZSmw+uOlNaJ/Miso/F5AoFTv/j61qcfXeqjgiTdv87h06xv8MSkhskiyUSMyNjYYIS6CYvLI2ysOQ026CmR8feJd1EqmjUAW/c7hNlYf768+4g6qqMLcBDiozqMidDt4Y2/VnzPAe9MftOxZYyn47akeOxZJTsZMc2Oxho0eqFYglkd43r7CjUJmd8C/gW7EwdAiKItGeYzdz9GDSFekxlubUQE1a6RRxkHk8vZZFy9lTYJaPjKDm6mQcDFBEwKZ0G4yPXu7xD5tjRhPwqNWIdhbq3rH3pQYHC9lWpYPqn2J6uHMQzI9Dqq+dr/e78tgnRil9o+NxYflRitt+aCQk6f8WUdsr4PCHewKwiFZQtOhbAniIRwNZ8Ym1hpRE4o89iZioq0pCfJHHsWifQnrGd4VoMI47+H0BDHj6VgYnGRWNXlWB4ZxTRG2Pm3D4dAP5aIhV4GriR5xigJnXmSu7lrUi8BFA2VDtVtwEcBg+lKkXOf+E+OpYr2zbiDKrrOobbSnQy02BDxzYL2Nythp+NockAAx7/AENcLZfS/eUSARA2M6xmZIuThqWzcAB5YbSuEY/xae8ojjURQLx52FYzH7dueyUW9V/XokHvQiU7HB8VYTW67jHZGf66GSH42Yeu0oETJApcBT4tkE9Q= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(376014)(366016)(1800799024)(6133799003)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(38070700021)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VzBiczR4NEdPelJ0R1lPajJXdlNzaTI1cmExM2pGVXVPYkkzbkZzS0hRdG4y?= =?utf-8?B?ZUovM3dMZ2ljcHY1RGdaaldQV1ZjL01SYnB4bzdQSndGNHp1SjhWbmxzQ2g4?= =?utf-8?B?bVVHZDZHQ0JTZG1ybFZQT0dLZFlKZUJTa2ZsbnlRa0Z2ai9iMS9Kak5Cd0VC?= =?utf-8?B?dG5abHhhV0l1RXlhaEZtNVN1M1VELyt5b24zZU5UQ282eXhKVHlLekQ3OEtV?= =?utf-8?B?TmExWThrRDlwdC8rRFcrZ1RLT2owRVRpMDZ6cDl1RTI2Nlo2N043bUtxV2xJ?= =?utf-8?B?YW8vaHppcUFMSkxaMXh4bFZLNTR1WGcrT3hpaUlqamRBekc4NWRSUkp5S2lR?= =?utf-8?B?YXpKNk9qamxjYUloQ25LQVF1cDhpb1QvdGJHRFRxNGJjakNtVW9FZGU5azc2?= =?utf-8?B?QjM1NzJuZjNvN1lOQlVzQlh0S0lqdEJScEpkeXFFc3QyaHRVcmRRQndaV2FE?= =?utf-8?B?Tll2cXpmSUVNdUtWVWV6Wityd2tnMTNMNnBqUVIrekx0dW8xNkhuOXQ0aEd5?= =?utf-8?B?eFJrUlIyS0ZuR1N2ZHBWTlRsMkplNnhPZFhJdmZwWEJxUjQyYkxpZGFyQlZL?= =?utf-8?B?S3Z1RWdhamJYTVJzWWpNYUNzOWgweVAzWERiVUtmY1dwVXdlQ2M2Tm5veEZ5?= =?utf-8?B?SDZINTBKMWhqZUtGKzlnemZsWGJWeFU3ZFIzNDIvMVQxZHdxanBlQTkrLzdl?= =?utf-8?B?aEJUVktxZW9vMGxPcm5aSjUvdGVKelhZb25CeXpMTWRUK2hrbW42YlREMnZq?= =?utf-8?B?R01SUCtZc2pwKyt3SWxnNzd2TE5YWHh1UlV4ZGJ1OHNOTFRGM3lkSm5jUUN6?= =?utf-8?B?Umw2elVlVlZDWlJaeWNjZjVHTFB2ZHdkeTk2YTFQWGs2bHVPN3BMQzM0TmJj?= =?utf-8?B?YlVaMlVaS2NkQ09SZWkvSzEzN3MvNWRxVVdDRE9qV0Q3akJsM016Tlo0MzdS?= =?utf-8?B?UlVEYnBvU0N6SzBaY3hYeElvaG5HWlhLdVM3VGhSVmlFaHFCNlpqQVNxb2ND?= =?utf-8?B?SmtCQ0RwRE1jd0tyb2Ntbk1rZVc2UlBZYmZuZm8vZVRORDBCcHJBYXlreFRp?= =?utf-8?B?Ujd2eWcxUWZ2NGhMbmVET2JSNTVqSDRlQlFGdklvVXh4WE9pc0d0VWgxN3Jr?= =?utf-8?B?VkpieXNqR04rcStvSVRtU3ZBdDFXZnAvMk5oaVprUXJDTTZKR1E5Rk8zdHM1?= =?utf-8?B?aS81c1JkbTAyaUNidzkyQ3RDblVMYzVWOUptZjRrak9hTFJBUFllcktrbmMw?= =?utf-8?B?c2xud1RXUWVoL0QrNm9uWGpRQ2RKajcyL2Yxd1ppakl5YjBrU29sWFE1Wkpj?= =?utf-8?B?akU2dUVyMVljWW0vMGxZUTJHdFBYOGptWk5PZDZvVHRRRG43QlBiSVd0RU5F?= =?utf-8?B?S0xQcW4xMmpGYWpEUGc0NTRDZDFOSXIyQjcwci9sYjV3NDFpancxbmN3Mjd2?= =?utf-8?B?b01vTDFJT2lHeU5NeTFLL1hOS1BDVDV2MHdwY3FNd0NPNGl3eVcyMU5lS1g1?= =?utf-8?B?MU9WZ2l0K0VBQmZwSFVLZzV2VHFSWmZSMTJJOUZmaC9oUjRQVk10VTJ5VjVl?= =?utf-8?B?TEF3Uk9NaDZ5QjBNUnVRQjM3ZndaY2ZIVWUrVkZWUGJCVjBUTHRYKzVaQzZ3?= =?utf-8?B?OGdWRXY2YmJ2dFBhMlhISVYrZjhhYjc0S0hNdVdPOXNTMjJEaFpudXUzbDZG?= =?utf-8?B?VDlLZWJGQVVqM0hvNXh6OU03WC9jMUx0anhsRjJxZzNLTUhLMzdjQ2FMY2xv?= =?utf-8?B?V1ZKWXB5WUVJSCtuZi85Ui8xSkdRWjBGaHczalhaLzZSbUFiT2RkRG4ybExF?= =?utf-8?B?V1dZb2x4ZkZwU21VWmpXRHNvNURmV20xVXoxNmVFWVdybDU2clh4V2ZPRlpr?= =?utf-8?B?VjY1Q2JtT2Z5bUJ3ekhtNE9IdGZiTm5xQUJrYmN2KzRWV25XemhuTVZRMzJx?= =?utf-8?B?b2d3aFpGYUgxeUV6WEE0RCs5bnVKWkFjRk9Xb05vZXRRUjRyVk9KQzNkTlA4?= =?utf-8?B?cUN2UUJvNkZKa1hhUHc3OXljaFlxd2xlVXNHZUtET2RkcXFGcS9MMXB6R3Ry?= =?utf-8?B?TjlMUVFwS0RXL0lVZmtmdUxyb2x2bXU5S0twbEk2UWZjV0lreDh4b1lZWFUz?= =?utf-8?B?cUpMVEViakp6TXFDNjlBYm43bkZRU2xlWXNuZllLQ3REQnRMVlNtTWpIdUdF?= =?utf-8?B?cTN5Q3RhdGU4aHQydmZlTzk3ZjBKWkltTCt1bUNHZEEvQWg1dS9NblI0YWRS?= =?utf-8?B?MGdCWmxkZ2Z6QXJoZEpHd2xsUWtXTmt1WHBMNjBKZ0hHM0xmTmhLTE8yb1B2?= =?utf-8?B?ejNyL3o3ZFM1ZGFzU3dkN01TaUlDT1UxRkRMWk1JMml1WmVTYklqUUxoRzlT?= =?utf-8?Q?YQU5jpfyt76KJWpM=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a00e4934-c477-45c5-328a-08df18b77063 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 14:40:24.4254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZWCFUvjEQcpFG9j0d462IKEpfBXb20oa2sN1gcxXa06I0oAIctMJjVWNMRTwYdx+ulaC6t6AC5Kp9MRjXi3y3qJFEmsKLSXwyvxPQV0kqBs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11837 X-purgate-ID: tlsNG-16d1c6/1790088027-FEC7777B-ADEFA538/0/0 X-purgate-type: clean X-purgate-size: 11270 RnJvbTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KDQpB ZGQgY2hhaW5lZCBoYW5kbGluZyBvZiBhc3NpZ25lZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQgYWNj ZXNzLWNvbnRyb2xsZXINCmZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3b3JrLCBzbyBh IERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUNCnBhc3NlZCB0byBmaXJtd2FyZSBmb3Ig cHJvY2Vzc2luZyBhbmQgZW5hYmxpbmcgVk0gYWNjZXNzIHRvIHRoZSByZXF1ZXN0ZWQNCmRldmlj ZSAoZm9yIGV4YW1wbGUsIGRldmljZSBwb3dlciBtYW5hZ2VtZW50IHRocm91Z2ggU0NNSSkuDQoN ClRoZSBTQ0kgYWNjZXNzLWNvbnRyb2xsZXIgRFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2FsbGVk IGJlZm9yZSB0aGUgSU9NTVUNCnBhdGguIEl0IHJ1bnMgZm9yIGFueSBEVC1kZXNjcmliZWQgZGV2 aWNlIChwcm90ZWN0ZWQgb3Igbm90LCBhbmQgZXZlbiB3aGVuDQp0aGUgSU9NTVUgaXMgZGlzYWJs ZWQpLiBUaGUgSU9NTVUgcGF0aCByZW1haW5zIHVuY2hhbmdlZCBmb3IgUENJIGRldmljZXM7DQpv bmx5IHRoZSBEVCBwYXRoIGlzIHJlbGF4ZWQgdG8gcGVybWl0IG5vbi1JT01NVSBkZXZpY2VzLg0K DQpUaGlzIGxldHMgeGwuY2ZnOiJkdGRldiIgbGlzdCBib3RoIElPTU1VLXByb3RlY3RlZCBhbmQg bm9uLXByb3RlY3RlZCBEVA0KZGV2aWNlczoNCg0KZHRkZXYgPSBbDQogICAgIi9zb2MvdmlkZW9A ZTZlZjAwMDAiLCA8LSBJT01NVSBwcm90ZWN0ZWQgZGV2aWNlDQogICAgIi9zb2MvaTJjQGU2NTA4 MDAwIiwgPC0gbm90IElPTU1VIHByb3RlY3RlZCBkZXZpY2UNCl0NCg0KVGhlIGNoYW5nZSBpcyBk b25lIGluIHR3byBwYXJ0czoNCjEpIGNhbGwgc2NpX2RvX2RvbWN0bCgpIGluIGRvX2RvbWN0bCgp IGJlZm9yZSBJT01NVSBwcm9jZXNzaW5nLiBJZg0Kc2NpX2RvX2RvbWN0bCgpIHJlcG9ydHMgYW4g ZXJyb3Igb3RoZXIgdGhhbiAtRU5YSU8sIHRyZWF0IGl0IGFzDQphdXRob3JpdGF0aXZlIGFuZCBz a2lwIHRoZSBJT01NVSBwYXRoLiBBIHJldHVybiBvZiAtRU5YSU8gaW5kaWNhdGVzDQp0aGF0IFND SSBkaWQgbm90IGhhbmRsZSB0aGUgcmVxdWVzdCBhbmQgaXMgaWdub3JlZCwgYWxsb3dpbmcgdGhl DQpleGlzdGluZyBJT01NVSBoYW5kbGluZyB0byBydW4gdW5jaGFuZ2VkOw0KMikgdXBkYXRlIGlv bW11X2RvX2R0X2RvbWN0bCgpIHRvIGNoZWNrIGZvciBkdF9kZXZpY2VfaXNfcHJvdGVjdGVkKCkg YW5kDQpub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVS4gaW9t bXVfZG9fcGNpX2RvbWN0bA0KZG9lc24ndCBuZWVkIHRvIGJlIHVwZGF0ZWQgYmVjYXVzZSBpb21t dV9kb19kb21jdGwgZmlyc3QgdHJpZXMNCmlvbW11X2RvX3BjaV9kb21jdGwgKHdoZW4gQ09ORklH X0hBU19QQ0kpIGFuZCBmYWxscyBiYWNrIHRvDQppb21tdV9kb19kdF9kb21jdGwgb25seSBpZiBQ Q0kgcmV0dXJucyAtRU5PREVWLg0KDQpUaGUgbmV3IGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKSBi eXBhc3MgaW4gaW9tbXVfZG9fZHRfZG9tY3RsIG9ubHkNCmFwcGxpZXMgdG8gRFQtZGVzY3JpYmVk IGRldmljZXM7IFNDSSBwYXJhbWV0ZXJzIGFyZSBjYXJyaWVkIHZpYSBEVA0Kbm9kZXMuIFBDSSBk ZXZpY2VzIGhhbmRsZWQgYnkgaW9tbXVfZG9fcGNpX2RvbWN0bCBkbyBub3QgY2FycnkgRFQvU0NJ DQptZXRhZGF0YSBpbiB0aGlzIHBhdGgsIHNvIHRoZXJlIGlzIG5vIG5vdGlvbiBvZiDigJxTQ0kg cGFyYW1ldGVycyBvbiBhDQpub24tSU9NTVUtcHJvdGVjdGVkIFBDSSBkZXZpY2XigJ0gZm9yIGl0 IHRvIGludGVycHJldCBvciB0byBza2lwLiBUaGUgUENJDQpwYXRoIHNob3VsZCBjb250aW51ZSB0 byByZXBvcnQgZXJyb3JzIGlmIGFzc2lnbm1lbnQgY2Fubm90IGJlIHBlcmZvcm1lZA0KYnkgdGhl IElPTU1VIGxheWVyLiBTbyB3ZSBzaG91bGQgbGVhdmUgaW9tbXVfZG9fcGNpX2RvbWN0bCB1bmNo YW5nZWQ7IHRoZQ0KU0NJL0RULXNwZWNpZmljIHJlbGF4YXRpb25zIGJlbG9uZyBvbmx5IGluIHRo ZSBEVCBwYXRoLiBBbHNvIFNDSSBoYW5kbGluZw0Kb25seSBleGlzdHMgd2hlbiBEVCBpcyBwcmVz ZW50Lg0KDQpTaWduZWQtb2ZmLWJ5OiBHcnlnb3JpaSBTdHJhc2hrbyA8Z3J5Z29yaWlfc3RyYXNo a29AZXBhbS5jb20+DQpTaWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldiA8b2xla3NpaV9t b2lzaWVpZXZAZXBhbS5jb20+DQpSZXZpZXdlZC1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzc3Rh YmVsbGluaUBrZXJuZWwub3JnPg0KQWNrZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4NCi0tLQ0KDQoobm8gY2hhbmdlcyBzaW5jZSB2MTIpDQoNCkNoYW5nZXMgaW4gdjEyOg0K LSByZWJhc2UgdG8gdGhlIGxhdGVzdCBzdGFnaW5nDQotIGFkZCBSLUJzIGZyb20gU3RlZmFubyBh bmQgQWNrIGZyb20gSmFuDQoNCkNoYW5nZXMgaW4gdjEwOg0KLSByZW1vdmUgdW51c2VkIHNjaV9k b19kb21jdGwgc3R1YiBmcm9tIHNjaS5oDQoNCkNoYW5nZXMgaW4gdjk6DQotIHRyZWF0IFNDSSBh cyBhIGdhdGUgZm9yIFhFTl9ET01DVExfKmFzc2lnbl9kZXZpY2U6IGFib3J0IGJlZm9yZQ0KSU9N TVUgaWYgc2NpX2RvX2RvbWN0bCgpIHJldHVybnMgYW4gZXJyb3Igb3RoZXIgdGhhbiAtRU5YSU8s IGluc3RlYWQNCm9mIHRyeWluZyB0byBwcm9wYWdhdGUgU0NJIGVycm9ycyBhZnRlciBhIHN1Y2Nl c3NmdWwgSU9NTVUNCm9wZXJhdGlvbi4gVGhpcyBhdm9pZHMgcGFydGlhbCBzdWNjZXNzIGFuZCB0 aGUgbmVlZCBmb3IgSU9NTVUgcm9sbGJhY2suDQotIHJlbW92ZSBlYXJseSByZXR1cm4gZnJvbSBk b19kb21jdGwoKSBpbiB0aGUgYXNzaWduX2RldmljZQ0KcGF0aCB0byBrZWVwIFJDVSBoYW5kbGlu ZyBpbnRhY3QuDQotIGNoYW5nZSBJU19FTkFCTEVEKCopIHRvICNpZmRlZiBpbiBzY2lfZG9fZG9t Y3RsIHF1YXJkDQoNCkNoYW5nZXMgaW4gdjg6DQotIGNoZWNrIGZvciBDT05GSUdfQVJNX1NDSSB0 byBiZSBlYmFibGVkIGluc3RlYWQgb2YgQ09NRklHX0FSTSBiZWZvcmUNCmNhbGxpbmcgc2NpX2Rv X2RvbWN0bA0KLSByZXdvcmsgc2NpX2RvX2RvbWN0bCBjYWxsIHRvIGF2b2lkIGV4dHJhIGNoZWNr cywgaW1wcm92ZWQgZXJyb3INCmhhbmRsaW5nLg0KLSBkbyBub3QgcHJvcGFnYXRlIHJldDEgaWYg c2NpX2RvX2RvbWN0bCByZXR1cm5lZCBwb3NpdGl2ZSByZXQNCi0gdXBkYXRlZCBjb21tZW50IGlu IGRvbWN0bC5jIGNvZGUNCg0KQ2hhbmdlcyBpbiB2NzoNCi0gdXBkYXRlIGRvbWN0bCB0byBidWls ZCBvbiBib3RoIEFybSBhbmQgeDg2IHBsYXRmb3Jtcw0KLSBtb3ZlIHJldDEgZGVjbGFyYXRpb24g dG8gdGhlIHRvcCBvZiB0aGUgZnVuY3Rpb24gYXMgcmVxdWlyZWQgYnkgY29kZQ0Kc3R5bGUNCg0K Q2hhbmdlcyBpbiB2NjoNCi0gY2hhbmdlIGlvbW11X2RvX2RvbWN0bCBhbmQgc2NpX2RvX2RvbWN0 bCBjb21tYW5kIG9yZGVyIGFuZA0KY2FsbCBzY2lfZG9fZG9tY3RsIGZpcnN0IHdoaWNoIHdpbGwg cHJvZHVjZSBjbGVhbmVyIGNvZGUgcGF0aC4NCkFsc28gZHJvcHBlZCBjaGFuZ2luZyByZXR1cm4g Y29kZSB3aGVuIGlvbW11IHdhcyBkaXNhYmxlZCBpbg0KaW9tbXVfZG9fZG9tY3RsLg0KDQpDaGFu Z2VzIGluIHY1Og0KLSByZXR1cm4gLUVJTlZBTCBpZiBtZWRpYXRvciB3aXRob3V0IGFzc2lnbl9k dF9kZXZpY2Ugd2FzIHByb3ZpZGVkDQotIGludmVydCByZXR1cm4gY29kZSBjaGVjayBmb3IgaW9t bXVfZG9fZG9tY3RsIGluDQpYRU5fRE9NQ1RMX2Fzc2lnbl9kZXZpY2UgZG9tY3RsIHByb2Nlc3Np bmcgdG8gbWFrZSBjbGVhbmVyIGNvZGUNCi0gY2hhbmdlIC1FTk9UU1VQUCBlcnJvciBjb2RlIHRv IC1FTlhJTyBpbiBzY2lfZG9fZG9tY3RsDQotIGhhbmRsZSAtRU5YSU8gcmV0dXJuIGNvbWRlIG9m IGlvbW11X2RvX2RvbWN0bA0KLSBsZWF2ZSAhZHRfZGV2aWNlX2lzX3Byb3RlY3RlZCBjaGVjayBp biBpb21tdV9kb19kdF9kb21jdGwgdG8gbWFrZQ0KY29kZSB3b3JrIHRoZSBzYW1lIHdheSBpdCdz IGRvbmUgaW4gImhhbmRsZV9kZXZpY2UiIGNhbGwgd2hpbGUNCmNyZWF0aW5nIGh3ZG9tKGRvbTAp IGFuZCAiaGFuZGxlX3Bhc3N0aHJvdWdoX3Byb3AiIGNhbGwgZm9yIGRvbTBsZXNzDQpjcmVhdGlv bg0KLSBkcm9wIHJldHVybiBjaGVjayBmcm9tIHNjaV9hc3NpZ25fZHRfZGV2aWNlIGNhbGwgYXMg bm90IG5lZWRlZA0KLSBkbyBub3QgcmV0dXJuIEVJTlZBTCB3aGVuIGFkZGlnbl9kdF9kZXZpY2Ug aXMgbm90IHNldC4gVGhhdCBpcw0KYmVjYXVzZSB0aGlzIGNhbGxiYWNrIGlzIG9wdGlvbmFsIGFu ZCBub3QgaW1wbGVtZW50ZWQgaW4gc2luZ2xlLWFnZW50IGRyaXZlcg0KDQogeGVuL2FyY2gvYXJt L2Zpcm13YXJlL3NjaS5jICAgICAgICAgICAgIHwgMzYgKysrKysrKysrKysrKysrKysrKysrKysr Kw0KIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaCB8ICA4ICsrKysrKw0K IHhlbi9jb21tb24vZG9tY3RsLmMgICAgICAgICAgICAgICAgICAgICB8IDE1ICsrKysrKysrKysr DQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYyAgIHwgIDYgKysrKysNCiA0 IGZpbGVzIGNoYW5nZWQsIDY1IGluc2VydGlvbnMoKykNCg0KZGlmZiAtLWdpdCBhL3hlbi9hcmNo L2FybS9maXJtd2FyZS9zY2kuYyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KaW5kZXgg YWE5M2NkYTdmMC4uYTZjNjQ3YTA5ZCAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2Fy ZS9zY2kuYw0KKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQpAQCAtMTI2LDYgKzEy Niw0MiBAQCBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0 IGR0X2RldmljZV9ub2RlICpkZXYpDQogICAgIHJldHVybiAwOw0KIH0NCiANCitpbnQgc2NpX2Rv X2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpkLA0KKyAg ICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2Rv bWN0bCkNCit7DQorICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2Ow0KKyAgICBpbnQgcmV0 ID0gMDsNCisNCisgICAgc3dpdGNoICggZG9tY3RsLT5jbWQgKQ0KKyAgICB7DQorICAgIGNhc2Ug WEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlOg0KKyAgICAgICAgcmV0ID0gLUVOWElPOw0KKyAgICAg ICAgaWYgKCBkb21jdGwtPnUuYXNzaWduX2RldmljZS5kZXYgIT0gWEVOX0RPTUNUTF9ERVZfRFQg KQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgaWYgKCAhY3VyX21lZGlhdG9yICkN CisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGlmICggIWN1cl9tZWRpYXRvci0+YXNz aWduX2R0X2RldmljZSApDQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICByZXQgPSBk dF9maW5kX25vZGVfYnlfZ3BhdGgoZG9tY3RsLT51LmFzc2lnbl9kZXZpY2UudS5kdC5wYXRoLA0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvbWN0bC0+dS5hc3NpZ25fZGV2 aWNlLnUuZHQuc2l6ZSwgJmRldik7DQorICAgICAgICBpZiAoIHJldCApDQorICAgICAgICAgICAg cmV0dXJuIHJldDsNCisNCisgICAgICAgIHJldCA9IHNjaV9hc3NpZ25fZHRfZGV2aWNlKGQsIGRl dik7DQorDQorICAgICAgICBicmVhazsNCisNCisgICAgZGVmYXVsdDoNCisgICAgICAgIC8qIGRv IG5vdCBmYWlsIGhlcmUgYXMgY2FsbCBpcyBjaGFpbmVkIHdpdGggaW9tbXUgaGFuZGxpbmcgKi8N CisgICAgICAgIGJyZWFrOw0KKyAgICB9DQorDQorICAgIHJldHVybiByZXQ7DQorfQ0KKw0KIHN0 YXRpYyBpbnQgX19pbml0IHNjaV9pbml0KHZvaWQpDQogew0KICAgICBzdHJ1Y3QgZHRfZGV2aWNl X25vZGUgKm5wOw0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2Fy ZS9zY2kuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KaW5kZXgg NDg1Y2UyMTFjOS4uM2I0YjNkZjc3MCAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9pbmNsdWRl L2FzbS9maXJtd2FyZS9zY2kuaA0KKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13 YXJlL3NjaS5oDQpAQCAtMTQ2LDYgKzE0NiwxNCBAQCBpbnQgc2NpX2R0X2ZpbmFsaXplKHN0cnVj dCBkb21haW4gKmQsIHZvaWQgKmZkdCk7DQogICogY29udHJvbCIgZnVuY3Rpb25hbGl0eS4NCiAg Ki8NCiBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0 X2RldmljZV9ub2RlICpkZXYpOw0KKw0KKy8qDQorICogU0NJIGRvbWN0bCBoYW5kbGVyDQorICoN CisgKiBPbmx5IFhFTl9ET01DVExfYXNzaWduX2RldmljZSBpcyBoYW5kbGVkIGZvciBub3cuDQor ICovDQoraW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0 IGRvbWFpbiAqZCwNCisgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhl bl9kb21jdGxfdCkgdV9kb21jdGwpOw0KICNlbHNlDQogDQogI2luY2x1ZGUgPHB1YmxpYy9hcmNo LWFybS5oPg0KZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZG9tY3RsLmMgYi94ZW4vY29tbW9uL2Rv bWN0bC5jDQppbmRleCBhNjIxMGRiNGZiLi40ZTQwZDQzYTcyIDEwMDY0NA0KLS0tIGEveGVuL2Nv bW1vbi9kb21jdGwuYw0KKysrIGIveGVuL2NvbW1vbi9kb21jdGwuYw0KQEAgLTI5LDYgKzI5LDkg QEANCiAjaW5jbHVkZSA8eGVuL3h2bWFsbG9jLmg+DQogDQogI2luY2x1ZGUgPGFzbS9jdXJyZW50 Lmg+DQorI2lmZGVmIENPTkZJR19BUk0NCisjaW5jbHVkZSA8YXNtL2Zpcm13YXJlL3NjaS5oPg0K KyNlbmRpZg0KICNpbmNsdWRlIDxhc20vaXJxLmg+DQogI2luY2x1ZGUgPGFzbS9wYWdlLmg+DQog I2luY2x1ZGUgPGFzbS9wMm0uaD4NCkBAIC05MjEsNiArOTI0LDE4IEBAIGxvbmcgZG9fZG9tY3Rs KFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCiAgICAgY2Fz ZSBYRU5fRE9NQ1RMX2Fzc2lnbl9kZXZpY2U6DQogICAgIGNhc2UgWEVOX0RPTUNUTF90ZXN0X2Fz c2lnbl9kZXZpY2U6DQogICAgIGNhc2UgWEVOX0RPTUNUTF9kZWFzc2lnbl9kZXZpY2U6DQorICAg ICAgICAvKg0KKyAgICAgICAgICogQ2hhaW4gU0NJIERUIGhhbmRsaW5nIGFoZWFkIG9mIHRoZSBJ T01NVSBwYXRoIHNvIGFuIFNDSSBtZWRpYXRvcg0KKyAgICAgICAgICogY2FuIGF1dGhvcmlzZSBh Y2Nlc3MtY29udHJvbGxlZCBEVCBkZXZpY2VzLiBVbmhhbmRsZWQgY2FzZXMgcmVwb3J0DQorICAg ICAgICAgKiAtRU5YSU8sIHdoaWNoIGlzIGlnbm9yZWQuIEFueSBvdGhlciBTQ0kgZXJyb3IgYWJv cnRzIGJlZm9yZSB0aGUNCisgICAgICAgICAqIElPTU1VIHBhdGggcnVucy4NCisgICAgICAgICAq Lw0KKyNpZmRlZiBDT05GSUdfQVJNX1NDSQ0KKyAgICAgICAgcmV0ID0gc2NpX2RvX2RvbWN0bChv cCwgZCwgdV9kb21jdGwpOw0KKyAgICAgICAgaWYgKCByZXQgPCAwICYmIHJldCAhPSAtRU5YSU8g KQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKyNlbmRpZg0KKw0KICAgICAgICAgcmV0ID0gaW9tbXVf ZG9fZG9tY3RsKG9wLCBkLCB1X2RvbWN0bCk7DQogICAgICAgICBicmVhazsNCiANCmRpZmYgLS1n aXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jIGIveGVuL2RyaXZlcnMv cGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0KaW5kZXggYWIxZTA3YWM5OS4uN2M0Y2YyN2QzMiAx MDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMNCisrKyBi L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMNCkBAIC0zNzksNiArMzc5LDEy IEBAIGludCBpb21tdV9kb19kdF9kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3Ry dWN0IGRvbWFpbiAqZCwNCiAgICAgICAgICAgICBicmVhazsNCiAgICAgICAgIH0NCiANCisgICAg ICAgIGlmICggIWR0X2RldmljZV9pc19wcm90ZWN0ZWQoZGV2KSApDQorICAgICAgICB7DQorICAg ICAgICAgICAgcmV0ID0gMDsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIH0NCisNCiAg ICAgICAgIHJldCA9IGlvbW11X2Fzc2lnbl9kdF9kZXZpY2UoZCwgZGV2KTsNCiANCiAgICAgICAg IGlmICggcmV0ICkNCi0tIA0KMi40My4wDQo= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:40:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:40:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429017.1651955 (Exim 4.92) (envelope-from ) id 1x91fa-0005ct-VR; Tue, 22 Sep 2026 14:40:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429017.1651955; Tue, 22 Sep 2026 14:40:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fa-0005bz-R7; Tue, 22 Sep 2026 14:40:30 +0000 Received: by outflank-mailman (input) for mailman id 1429017; Tue, 22 Sep 2026 14:40:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fZ-0005TQ-Bk for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:40:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91fY-00AHxl-OO for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:40:28 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2934d-bab6-0a2a0a5309dd-0a2a4506e4aa-28 for ; Tue, 22 Sep 2026 16:40:28 +0200 Received: from [40.107.159.85] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2935b-195a-0a2a45060019-286b9f557f3a-5 for ; Tue, 22 Sep 2026 16:40:28 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV2PR03MB11837.eurprd03.prod.outlook.com (2603:10a6:150:36e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 14:40:25 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:40:25 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VOT679ArTBr/HeYuDf8sgS5VQ1asvZts8bqtzOihtIXEM0FS8Zv8Cd/rTP40fJ+gI7iCAmOjZkp8QI9Ch4ehDrY6oJHXB9nxpvoTTNZs9wYuEOQNOlVX+nth3Ndkso2EK9ggcmstceSy3IsbWMknf0V1uaDa24aS3SyWbdHFFqnKEFg4U0EZpQ7PKOmIsCsbycFrEM88Zasw1sbVpwLgZnd8sIQl8Lf/hhYCZ2q90kpdFF8+NC0xhP59/juCH3sdeduMzaHwpB2RdeMuPSilMr4eZvh260T9Yy9a1wD2Quxgr0S5rENhXhcejwJaJPThMa/CZzeIY3dqcQwrbWcBpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HaPlyiQF1WAzVJ67Z+NxO+5WCG19GCRvpAl3HPh9kPA=; b=r8i6blBpijXjGWUQXMLzNRLrDA4Cf+nmuCqZNMTozCOQdTjUlNe0zZKCFeffWT8ytGTuRGL+oSh0qHpC/8Mu9RmzxqrRyY0wLhc1liXHIe6OZATXxL+eDqw61p3HWvAn2I/oy9BlfMMkk8LENyHy4tUxSc9hve+yyL1MyUPHcPo8IyuuWY6L66RxLOMuwxh95GcpUDYLz30WhbYQV1J2C24ZXe6lIRltrPCrndrcE7Q3CkKUQpb5fRUh795OJr3WUyYeLHzIrugKonnUpXQNHe0Mf9t+si0tOyKnycfPv9KAERYwaD7qzEs3dGqTtMDc6XfB5uxncsBwxK4fnbM21Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HaPlyiQF1WAzVJ67Z+NxO+5WCG19GCRvpAl3HPh9kPA=; b=BRQoM9JTpObxHDmWpXPAcgCFFTPsfbDbz8+tvQv1dOZION+kuhPa+9YNe5yP+YpejRE8wKbE3luGh7Ig/krF+2iE/ZuiFF82KjCTjNHKDBYNSX+ur6oVb7WcQILWC1k4u7L/l0BXzkhB0ygJ/0ooOPZZ+BnMjq7TK8xs7meMMPA37Vyx8gScmrHfTbClMulktVvDAuS/rDWYJZCidlzML3X/YssYhbpavwpK3zx2yWRfIwC3zNi3ejus2i/nneRHY/TztK1QQeJNc0LsMizxfq1cRnx5fQuU0atCgTn1RxAgP7GPz7prUv8eFIDXK7im70AgsisVGMDJs7sDwJSmJA== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v13 2/6] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Topic: [PATCH v13 2/6] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Index: AQHdSqBNho+F8L2W9kicIm5Tp8rY8w== Date: Tue, 22 Sep 2026 14:40:24 +0000 Message-ID: <07687288fe00a8a6a7bde67ab35a9039605c2734.1790087968.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV2PR03MB11837:EE_ x-ms-office365-filtering-correlation-id: f1f9a765-5170-4db5-fbc4-08df18b7709f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|366016|1800799024|18002099003|22082099003|11063799006|56012099006|10067099003|38070700021|3023799007; x-microsoft-antispam-message-info: tuG4h3xsu9t6//uPGNkYS8SyO0MSkZabCgoYzzNpztgs65SutANK/WvRsa92cnPVzePjB5caEyvarnLGZS45N3arku7GmmA0WrfRZ1vVLJ8t7lghUAI8iaDYe+FNhAq4ymBjhPdHccfvrlO2zhuj7RRJcPcuacAelnDei13ZflmELJsqh+fRAvFcOORWV3MZB7UmPfrhVrDp0FN7z/nXoh7ucAQpwiD9D9yZaPUlgiz/FnxvcvbVf9YTGy2WBkec+xHX8r1lubnB8To+UYXbaZasQgkBZYldFWVJjjfh3LNZVNlkz57+98oRi9rU9SmeM58O4I43VdSzOzyhfM64/7KRa2FSAJG3vUbF5s2RG3SdxMx3tXbjhAuggco/2md3AGQvgWlhDWaLlQHFZupTZi85Akw1+TMg5/dSyvwkPWX5rN9RKygi/TiUfHbspVi2xkpILxY2qCEOqFBwcr8QioXbwu6XftaAFfNmsv5j0Im5EA5lcqANVKkMlw4iHp7iVyKgoYliQcbdVn6ZFsxOuQkSr0OaZDer+wRFnAN4OoXlvAUPHwD5hgnGscqU0opq1nyc/C4eaLPmwEM2yp/zjMT9eHYZR9FVbo3HLe2RfRjZbKTYuuHziHsKSLQkPR4acN/0vp6pFfrAhy76XhdNJwOrc05vRcz0Hkwaywhm92DNPwPhVlvQeiWpuh92fqBgyH+Hy3+98Ioe9aU3+m710mPtbmo7RdyH0fGZ59PbK6k= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(376014)(366016)(1800799024)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(38070700021)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?BS0WccDecmGc4U07wGInHxgi15hEFQk6oCiShnuPcqNgR87AZF+7BgymD3?= =?iso-8859-1?Q?+GK7lzBn6mRMy2yIm14cB8TrQmWRlKn+OSWNZTsoOImeNH6dklHXIqN+60?= =?iso-8859-1?Q?qss/RtoXD1823YHHnjvIVtmAOZjhyVgjTGCrbK6XbqO8u6ZOCHPZKXQM70?= =?iso-8859-1?Q?cSJPZ08D1ESbx2RpHyMulqHS1eKdBOI/TEKdNklroYCrOuzoOWGip+ov92?= =?iso-8859-1?Q?0U+XV7N+TGxj1icZD+BmJx+puc2bXg0rol/4EPqtyDOyK/f+6WpI2g9qLr?= =?iso-8859-1?Q?ow8WId+B7VZ20TuC4IUK4D3zM/gt/zs3kWtgXrD7iUssnJFg1AAT9Yxj64?= =?iso-8859-1?Q?KbZLSm9yN9DNFl/IWsG/IQvy5hCFL5beXR7CE0YaSx9dY4t5OTpzM1nCRY?= =?iso-8859-1?Q?YH4oBlPEuv53BmzJIPRw4CcGFwcdUnaqSHEkOa9RPKBYJBdVNbM/Y5z9yW?= =?iso-8859-1?Q?7eGZjB4n0DCxdRVOo3PcgDJyfQMIhdBb9YMVDExFmJvfbZ53AN3DsWEO01?= =?iso-8859-1?Q?/lOSXNt/fApYzB4Sy4U8gkueZA0DNDDeZqsdukr9ekaqePrarGVvbC+4aG?= =?iso-8859-1?Q?yEMHDsEOzS54MqD0l/ilK1NQ+Vq0Bo7fq//uvW7JQxLpzTqaAxvO3EM+3R?= =?iso-8859-1?Q?oqppJRo6mqDWTA0t5rrwtzB5X/nSk5GylcjnqDvZdbgc9yb2WvhxhgnisF?= =?iso-8859-1?Q?zMKYWIwTNEk9Pg8qlBmSFzcNJ455l1+YnOo2RKcp2U+8PERkfRq5Xef1gx?= =?iso-8859-1?Q?RErWRTfgj4urkuuHS2Jr5VvyBblha5yiBcU1nKyCmLM2q4LGIG5K1fPHqf?= =?iso-8859-1?Q?uTu50fQWXUNS4J/bjq0m1FrmQMuWVPKnVG+ZJI5HjFj4EycV8DsyrFJuhH?= =?iso-8859-1?Q?TBTUqYBkkkIlIx2ztuFFX6l30bV7AWAomwN/7ucFUb/Cw9C7W+/hpJvBOY?= =?iso-8859-1?Q?Gc3P9AbbuC+WaeOZeXyvttv9+fnqj5uy1kMrrePj0jO3ZcPu/u1kJ/0XQk?= =?iso-8859-1?Q?DGEIcts8MMDtpAx2Kq5qjvv36DuuljgfPznbsIFC61VUNj6dPB+zb5C90N?= =?iso-8859-1?Q?AlZ+fieB5KGGZTUghHnXYBqPlJCEuc5zY0lX4Dwjtb2YJwH2WL/i6iw0lW?= =?iso-8859-1?Q?AXNOWGwlRJP6pyfuiWKvPgdNvIVBGtgjcgEia4lg4f14SvR9GuAmq6+MqD?= =?iso-8859-1?Q?qqITpnDL0umINPqfCxLQZPjgZY6sISRKkWRsdkcOn1Zx51/v4Ny/FriseQ?= =?iso-8859-1?Q?kM4uALT163MKb2x2e+E9Pn0/8J8rp3fYr+xlcAmlBh/uZR25egttZd7uwO?= =?iso-8859-1?Q?NMmZRXiD8Ic22YeexFv0TneV4sKqdk5eF04MU9bRJd6F+ho2dW0XB6q23i?= =?iso-8859-1?Q?CT1WHweQfYuz21m1Qsr7pNBMg1gI8+DQJFV7Mx9hp3twyfDlKg1M8sDKgv?= =?iso-8859-1?Q?bfpl+dy6Z1WENLrlX++JhVuJxb1BO9Bdyh7lJE9pTax3c9DU0H4h/j98OO?= =?iso-8859-1?Q?o5Wb2+1efBV/SO/Lxk+YSgxEPDGsRKMYwv6Z1x8b6o1EP4wIWeQkJwQvdL?= =?iso-8859-1?Q?HNnoOREAz1UNpCuIEwj87Jy4o4+mJFZtySq2l0UTLn5m1TMn7kEk2yuoZn?= =?iso-8859-1?Q?cLvqpaClmWxULtq9Pvn0Df/MR4n+UdbpjKbHDrxywpXPme59Q/BlG7BKxU?= =?iso-8859-1?Q?Kkzb6O/+Sd5u/KYqv93Oa/HsN5DVeshgKexcn78qfZqlbQsfx9KL1paRzl?= =?iso-8859-1?Q?eR+kjuT80Abl4LArs4fWBomXsQqeAL20htkgsLYSu0lfi8GK14uIyo4Dhr?= =?iso-8859-1?Q?Ewk0GeHlbFWsHAWSJjXUAcw8BJwi2z4=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1f9a765-5170-4db5-fbc4-08df18b7709f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 14:40:24.7229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AdYn8G/C+eLxNyuF4I1vlP1NvYLI4r0TlfBA67/SAtBpOaS8HRM26P03haJlInAiVOF3W87C8xF8S8YbMHdasxzbFSChNanZ6v/yclqlcL0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11837 X-purgate-ID: tlsNG-16d1c6/1790088028-F4C0777B-58AFF651/0/0 X-purgate-type: clean X-purgate-size: 1118 According to the "7.1 Return Codes" section of DEN0028 [1] INVALID_PARAMETER code (-3) is returned when one of the call parameters has a non-supported value. Adding this error code to the common smccc header file. [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 Signed-off-by: Oleksii Moisieiev Acked-by: Stefano Stabellini --- (no changes since v12) Changes in v12: - add missed Ack. xen/arch/arm/include/asm/smccc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/sm= ccc.h index c7763acd7f..91c9bc1186 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -381,6 +381,7 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs = *args, 0x3FFF) =20 /* SMCCC error codes */ +#define ARM_SMCCC_INVALID_PARAMETER (-3) #define ARM_SMCCC_NOT_REQUIRED (-2) #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1) #define ARM_SMCCC_NOT_SUPPORTED (-1) --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:40:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:40:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429015.1651946 (Exim 4.92) (envelope-from ) id 1x91fa-0005U0-FF; Tue, 22 Sep 2026 14:40:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429015.1651946; Tue, 22 Sep 2026 14:40:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fa-0005Tr-A5; Tue, 22 Sep 2026 14:40:30 +0000 Received: by outflank-mailman (input) for mailman id 1429015; Tue, 22 Sep 2026 14:40:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fY-0005TG-Ap for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:40:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91fX-00AHxl-NG for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:40:27 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2934d-bab6-0a2a0a5309dd-0a2a4506e4aa-22 for ; Tue, 22 Sep 2026 16:40:27 +0200 Received: from [40.107.159.85] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2935b-195a-0a2a45060019-286b9f557f3a-3 for ; Tue, 22 Sep 2026 16:40:27 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV2PR03MB11837.eurprd03.prod.outlook.com (2603:10a6:150:36e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 14:40:24 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:40:24 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mxWS1qMYA0AJpFsn1QzOsIkg9yJ9Pm2SYG4jKeBuiycAmfkDWq3f7uFqbnRauEQ0UbSMRVaz1jfsOhUojNmT9tt9CKXpnmSva4/+0FbayUa9NADeTQ1SwrNwKvS39RjVzq0pGcpZVeVZ5FtwqIAEiGmxu4gfMx/462o6x0u4VpIcFJqpTTkr5bcU8LPyZyZWaDOvcrZHCFbziN45qPFXSW8E2DZmidHkbKnN4W1AOqM5RapBU0e3st6meJA3pDzF7+ZW2xkzJm8jysNFaM7IJeqAKfjD9FMlBE2ggSKCeKVU4/CgQ5woeTJc6GUENw/ZDnM46zwtNrN3x7usqIi0SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8jcAYlMQ1shH37NUY3udP54lIh3e9sOCTA+qUXi/DWw=; b=v9PJrpijKLrJKgtwdYFNsBylU4R4es86XW7rOVWyIBVEwNTbOPjbk7psQPj8h9Xl2rjapPHk1gUqk2NmQLV6PeRp9+khW6gEx0oPvcEiwu9R/Q1RRgX7GR5pK70fug5eIAcdoBvGQS9Q0RNG0dFWIrSvg2yasb5vPNV9ugagCh5X+CgbSkh9zl2HhC+lXkD7qNuIMKUNx1GT7ehtQ74Gx+Hzc0xDP8ZFHvLGSX5PT5CdIzsQn7rEjBLnfz172xE9KcLXAG2ZU4NyKJU1KZoiesFxumsuC8ESImI7mewtxcAdEKDWREkmelNBXRyEEhGUqkzscxVlLU/xG4SNxzCf3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8jcAYlMQ1shH37NUY3udP54lIh3e9sOCTA+qUXi/DWw=; b=JsHFzYuVzllesKci096IRLazlCzYztk69U+Tsih+ejBw+ImCc2fo3xQ3/0uHrmHJ/d+aatUL4saa6bmY/FoffXiC9Cg2hHdK5qBhGr42w6V0EKnLDsnmk0nwBIs/tgMb+XnGVDFGfKhZuNGD28ZEaU90uKuG4o1nwmF5px49P955LPGDSdE8Gm5aF++Zp+PQJibxRyXo8MKkEiiWf5+9rjdCEi8bCCKDNxB2IyEAZ1l2yrqVGAHbyvz1N6u0mPigtDAFeoN7sXMp7Y+Wd8QseD87QkmCNzydyUU4crWK3mxPTSh55hWSTooyRDExq7JY+/JWQZGhjGWpkeAm7YDq6g== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v13 0/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Topic: [PATCH v13 0/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Index: AQHdSqBNQ5v+uY84RUKVk8m5glhVog== Date: Tue, 22 Sep 2026 14:40:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV2PR03MB11837:EE_ x-ms-office365-filtering-correlation-id: 56d07652-69fa-42e3-fadf-08df18b76f9c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|366016|1800799024|6133799003|18002099003|11063799006|56012099006|10067099003|38070700021; x-microsoft-antispam-message-info: sc45dA2hfiepMQsyFvTJgmM2Kr88zMoHyqaJmexyOkVezLk7ianbXrLOJ/rOjEg8QV1X9+8yTPlCKtMgSi7AnhMtihUfK7bPDLVmcLMaMFvPPEMpZ+MzeCq1L1qCsIe3/5/LcAXnbVX+Y+gvHFEmyZip+0027+L+3R0FqdjVkfGsTEWED7FANj4imDgDxnH8aPh5BXgtMlGvclcwoinbpJZY2xqSCaHGIu32FbhfdkYo4M/g6HZ+7CPLsSlutEu6roz8zze2GCENSv/vULXu1LJFsKDOwp1JrIE2SfT2znEX0ekF8APSM0o3No83NFXcVsXopBcRORQHd5mI/Enj/i3AhUGRVZuT3zY4nwFKFWJgwfUyWjLlnsbq3UltCxuLv6XiPr/ryfmrJJuZFziAQXfGY+bX53yjNrAB62ryZXfx9R/MPyvHwSzrzHmgZm1UmCOMYwwiILrTI/6zHiTlMfaIIknzT5MOc/nTypQZxTCMkOUS/5Q+bEHW8AvgFMpMjvsjbZWZWo/Acex6JkRo8xjFcDH2yQ8bfz0VMnH9CZ465fsOH+J6YxPASh4me2odihDIE5HFEoR9P2FGt6bUbftGr3Qvgm20szrHnwgvvupwp/sZCVTyPPNzfAx3gLHgaEfc89yVRde4owhGQ8Ss7JYhTyfX7zVXFvxb3fVHGRI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(376014)(366016)(1800799024)(6133799003)(18002099003)(11063799006)(56012099006)(10067099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WTErNWlDeUFhYXdwajREZXZTMHlDVEhPNnZGOXNVMUIvaU5vQVJDTVIxL2Jz?= =?utf-8?B?aDVzTmJmckFTMnQ0OVZXMVlHQ0d3T3AxWDdFQjZ6NDhhYWVzeVBqNFREUkNh?= =?utf-8?B?NHNWN0RBdytpZGN1cHI4WDNSRkh0cGp5K0hjeDZrU0xnMVpiNy82TTk0aEV3?= =?utf-8?B?WVdRLzNJUlpqYkhrYkJwcTVJNXRtUUdYekN1M1dydlJGaFgrd1hNbVFFbzln?= =?utf-8?B?VXVYTXoxUCtIRVIyc2p6ZmloMVBiUDhEN1NFdzJyNW1wdGxBR2xLQjJaMVY1?= =?utf-8?B?cVVDL1BOM29SYjJSckFvd25WWHJLcWpLQ29ZbzB1VTUwNDE0bUJQUy9ZVVAy?= =?utf-8?B?UTcwRitEYWozWlBUSmI2TjYyWGlFQStWTTA3dzBhUC9CZ3hXUjRta2I1QTR3?= =?utf-8?B?QzBjWmZjRU81TU93ck1odHFTQ2pHOWdvOUR2VnFrLzl2Wjk1R0R2VUlNaGV3?= =?utf-8?B?Y2dsYWlxKzFHWjdrZS8yRXIwNFNpR0crTEVZQmJORjRtaWRyWndtbGZib1BL?= =?utf-8?B?c3lqYW54ZytBakR5VE54c0tvTTNXdm92YWhOZ1NGbFdpS2tIUzYvUDNvYS8x?= =?utf-8?B?YXU2dUp6OWd5ZmNZQk9WbUhQK0hUUXJUblkySzhKaTVPbjFTM2ZyZVpYcDdn?= =?utf-8?B?amEveUZtcjU5TmRqaXcwbGxzMFRFWFVpSTYzdTNpVGtrSFBmT3RlQ0srTytl?= =?utf-8?B?V1dubE5wSytqVy9DUXcraW1lY21qMnZOS3FTWTcxd1A2S0dRTDMrclhsTkt1?= =?utf-8?B?MHhKSW5OcWo3VXJTc1A0ZUpITjB3R0kwcEtTMTgxV3kzamJDUXJUSUhSU1FN?= =?utf-8?B?V2ZyekMxT0RlOUVSMnp5eUM5dVgzYzZ0L0pkMkgzelV4aWJEc3ByZTN4TTVs?= =?utf-8?B?WkwvSmV6K29FamxvNy8vMHMvbUVWbUptbFVGY0dNMVhUOUZ6YjUrVTVqZVVR?= =?utf-8?B?dmxVVllJYjZpRkQ5M3JXYlA1Q0l3c1N4M2pUVlNwdmtQU3d3V2krVHU2bE5J?= =?utf-8?B?Tk5kamx5MTlRQ0RFZ1M5QTNKSWhFNEJoOStHSEVEcEloZ054M09HcTAzYVc1?= =?utf-8?B?TDVpdU1lbmhxT3BITWVYZE12c0tvSG1XeXUyY3BkZEtGd3BlcnE1eGJjd1Jk?= =?utf-8?B?NzhzUFRxOXBhZ1VScEM5Ylp1VUhuc0pETzVpaUdmM3FKNCtHUVE3YjNSTmRT?= =?utf-8?B?S0o1bm5rSnROZTdhRHNTczUyNEdVaEE4dFRpTGVoTEROQWZSMWs5YXpTcTVx?= =?utf-8?B?RFpOUUZGRjN1QWhrVUdRb1d3SmROc20wdkx6UWFnRStmWnFCZVhvWWxYb1U4?= =?utf-8?B?QzJJWjNkUS9UaWxZN1d5OG80U2QxQnNDeXdlSFZ3cG12Kzl1Nkp2aExuUHpl?= =?utf-8?B?L3Z4bk1xVXJzcWU2b1dBYmpCeVpjWWpFaHliSHRPamRXdGxlb2hhVTJYekNp?= =?utf-8?B?djBnVnVmNU1wVDZUUyt4bG9tbTR0RWpLKytmMjZRaEw3WXhkckdRVENSbm9n?= =?utf-8?B?K0xTUzcwOEtWbnVNbkgwTDg3bmpGQnRybTlJdXRQYit6N1Q0UVNhdWFMZzhQ?= =?utf-8?B?TFVCaStuVTBaakgybUpXTUJad1FBb1I2RjY3T1dERlZTQ3Z3NEYzbEprU2FC?= =?utf-8?B?MXhoV001T2R5K3lPOUYyUmU3YTBhQ2lhYkU3UTdYQzVUSGhIZnk3Rk1nSTg3?= =?utf-8?B?eXcxMG9mY3RUakE1K3UySzBxbzJFL254L1lBLzU5amVVcTNMN0kwR2ZYcTk4?= =?utf-8?B?TmpIKys1Rm9yb0gxeHA5ZTNIVENyWk8rdUpERVpxTUVIOElIN0k1ejRBOUZ4?= =?utf-8?B?UnNKY2tvN3Jmd2FZSGY0RVlLSjVHSW1lYkg3RU1iT091ZTZIcU9nZm1yNHhv?= =?utf-8?B?a1VGNU9Qb2VFVjJNUUY1eEFhZ2Fhc0FSZElvcWpTblRkajNGcGtRaG5rRkIw?= =?utf-8?B?SGVUNy96ZCswOGN6U0VQa1BkNjlYQkh5OEhnL25RbEVHYjNTamx2aTZONzE1?= =?utf-8?B?M29KTmN6Rlp4YW5saFJpMmtGNy9uaktiR3BmTEFhNllRRHhmSzdiR0dNbUhR?= =?utf-8?B?Lzkwb3E1SzVCaE1rNFJyWUJGWVhrckc1YmxUMGUxRkM1NjViUjdsZXNRa2xu?= =?utf-8?B?a2xULzVzVTMyZ2lRWXJjVEgySnRKakZrNXRBSkxnUXczL1hTdDF6aTNsOW9w?= =?utf-8?B?N1JiOGpjdDNkdUJJV0IxdW5VckhCVlRuWEZVVFpOdjBuSFVqZ3ZsektndVFF?= =?utf-8?B?UmpUay83OEx1d2VKNmhGSnI1WStyVTRtdzFsRlM2eU94VDVtcWVDcTIvY1RZ?= =?utf-8?B?L3pHZW16VTB2cG1YcWVCczRxN3FRQ2dsajhJN1VqM1oxOXJqNzQzV2JNN0Nk?= =?utf-8?Q?nZlT9vi12B1TDSvc=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56d07652-69fa-42e3-fadf-08df18b76f9c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 14:40:24.0297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: daUsaq3N6smzHX4yTs7vLb76reRRQP+G9GVxjJxSa3CFJC53dZWaG84NibXA9AUHZYF4BlnTFHK6KMbGUxpMEX5jhI0UkOO8Msdh60KzP14= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11837 X-purgate-ID: tlsNG-16d1c6/1790088027-F687577B-25036222/0/0 X-purgate-type: clean X-purgate-size: 24424 SW5yb2R1Y2luZyBwYXRjaCBzZXJpZXMgd2hpY2ggaW5jbHVkZXMgaW1wbGVtZW50YXRpb24gb2Yg dGhlIFNDSSBTQ01JDQpTTUMgbXVsdGktYWdlbnQgc3VwcG9ydC4NClRoaXMgcGF0Y2ggc2VyaWVz IGZvbGxvd3MgUkZDIHY1IFszXSBzZXJpZXMgd2hpY2ggd2FzIGludHJvZHVjaW5nIGJvdGgNClND TUkgc2luZ2xlLWFnZW50IGFuZCBtdWx0aS1hZ2VudCBzdXBwb3J0LiBBZnRlciB0aGUgZGlzY3Vz c2lvbiBpdCB3YXMNCmRlY2lkZWQgdG8gc3BsaXQgZmVhdHVyZXMgYW5kIHVwc3RyZWFtIHNpbmdl LWFnZW50IHN1cHBvcnQgZmlyc3QuIFRoaXMNCmZlYXR1cmUgaXMgbWVyZ2VkIGZvciBub3cgdG8g djQuMjEtcmMyLg0KSSdtIHN0YXJ0aW5nIHRoaXMgcGF0Y2ggc2VyaWVzIGZyb20gdjYgdG8gc2F2 ZSB0aGUgZGlzY3Vzc2lvbiBoaXN0b3J5DQphbmQgZG9uJ3QgYnJlYWsgY2hhbmdlcyBsb2cuDQoN ClBhdGNoIC0geGVuL2RvbWN0bDogZXh0ZW5kIFhFTl9ET01DVExfYXNzaWduX2RldmljZSB0byBo YW5kbGUgbm90DQpvbmx5IGlvbW11DQotIGFkZCBjaGFpbmdlZCBoYW5kbGluZyBvZiBhc3NpZ25l ZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQNCmFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkg dGhyb3VnaCBTQ0kgZnJhbWV3b3JrLg0KQ2hhbmdlIHdhcyBkb25lIGluIHR3byBwYXJ0czoNCiAt IGNhbGwgdG8gc2NpX2RvX2RvbWN0bCgpIHRvIGRvX2RvbWN0bCgpDQogLSB1cGRhdGUgaW9tbXVf ZG9fZHRfZG9tY3RsKCkgdG8gY2hlY2sgZm9yIGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKQ0KIGFu ZCBub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVQ0KDQpQYXRj aCAtIHhlbi9hcm06IHNjbWk6IGludHJvZHVjZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJp dmVyDQotIGFkZCBYZW4tc3BlY2lmaWMgU0NNSSBjb250YWluZXIgY29tcGF0aWJsZSBgeGVuLHNj aWANCiAgdW5kZXIgYC9jaG9zZW4veGVuYDsgWGVuIGJpbmRzIG9ubHkgdG8gdGhlIGBhcm0sc2Nt aS1zbWNgIGluc2lkZSBpdCBhbmQNCiAgaWdub3JlcyBvdGhlciBTQ01JIG5vZGVzIChlLmcuIHVu ZGVyIGAvZmlybXdhcmVgKS4NCi0gYWRkIGBzY21pLXNlY29uZGFyeS1hZ2VudHNgIGFuZCBgI3Nj bWktc2Vjb25kYXJ5LWFnZW50cy1jZWxsc2AgdG8gZGVzY3JpYmUNCiAgZnVuY19pZC9zaG1lbS8o b3B0aW9uYWwgYWdlbnRfaWQpIHR1cGxlcyBmb3Igc2Vjb25kYXJ5IGFnZW50cy4NCi0gZWFjaCBn dWVzdCB1c2luZyBTQ01JIHN1cHBsaWVzIGl0cyBhZ2VudF9pZCAoZG9tMCB2aWENCiAgYHhlbSxk b20wLXNjaS1hZ2VudC1pZD1gIHBhcmFtZXRlciBpbiB4ZW4sc2NpIGNvbXBhdGlibGUgbm9kZSwN CiAgdG9vbHN0YWNrIHZpYSBgYXJtX3NjaSA9ICJ0eXBlPXNjbWlfc21jX211bHRpYWdlbnQsYWdl bnRfaWQ9Li4uImAsIGRvbTBsZXNzDQogIHZpYSBgeGVuLHNjaV90eXBlYCArIGB4ZW4sc2NpLWFn ZW50LWlkYCBpbiBgeGVuLGRvbWFpbmApLg0KLSBmYWN0b3Igb3V0IFNDTUkgZ2VuZXJpYyBkZWZp bml0aW9ucyBhbmQgc2htZW0gY29kZS4NCi0gcGFzc3Rocm91Z2ggY29uZmlndXJhdGlvbiBmb3Ig U0NNSSBndWVzdHMgbWlycm9ycyBvdGhlciBIVyBwYXNzdGhyb3VnaC4NCg0KUGF0Y2ggLSBkb2Nz OiBhcm06IGFkZCBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGRvY3MNCi0gZG9jdW1l bnQgdGhlIFhlbiBTQ01JIGNvbnRhaW5lciB1bmRlciBgL2Nob3Nlbi94ZW4veGVuX3NjbWlfY29u ZmlnYCBhbmQgdGhlDQogIG1lZGlhdG9y4oCZcyBiaW5kaW5nIHJ1bGVzOyB1cGRhdGUgZXhhbXBs ZXMgYWNjb3JkaW5nbHkuDQoNCkFsbCBYZW4tc3BlY2lmaWMgU0NNSSBjb25maWd1cmF0aW9uIG5v dyBsaXZlcyB1bmRlciBgL2Nob3Nlbi9gDQp0byBrZWVwIGhvc3QgRFQgY2hhbmdlcyBpc29sYXRl ZCB3aGlsZSBsZWF2aW5nIHRoZSBob3N0IGAvZmlybXdhcmUvc2NtaWANCnVudG91Y2hlZCBmb3Ig RG9tMCBjb25zdW1wdGlvbi4NCg0KQ29kZSBjYW4gYmUgZm91bmQgYXQ6DQpodHRwczovL2dpdGh1 Yi5jb20vb2xla3NpaW1vaXNpZWlldi94ZW4vdHJlZS9zY21pX21hX3Vwc3RydjYNCg0KWzFdIFJG QyB2MjoNCmh0dHA6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wcm9qZWN0L3hlbi1kZXZlbC9jb3Zl ci9jb3Zlci4xNjQ0MzQxNjM1LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NClsyXSBS RkMgdjM6DQpodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QveGVuLWRldmVsL3Bh dGNoLzIwMjUwMzExMTExNjE4LjE4NTA5MjctMS1ncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbQ0K WzNdIFJGQyB2NToNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzUz MTg0NDg3LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NCls0XSBTQ01JIHNpbmdsZS1h Z2VudDoNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzU2OTk1NTk1 LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NClNDTUkgc3BlYzoNCmh0dHBzOi8vZGV2 ZWxvcGVyLmFybS5jb20vZG9jdW1lbnRhdGlvbi9kZW4wMDU2L2UvP2xhbmc9ZW4NCg0KU0NNSSBi aW5kaW5nczoNCmh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVs L2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmlu ZGluZ3MvZmlybXdhcmUvYXJtLHNjbWkueWFtbA0KaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcv cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50 YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9hY2Nlc3MtY29udHJvbGxlcnMvYWNjZXNzLWNvbnRy b2xsZXJzLnlhbWwNCg0KUmVmZXJlbmNlIEVMMyBGVzoNClJQSTU6IGh0dHBzOi8vZ2l0aHViLmNv bS94ZW4tdHJvb3BzL2FybS10cnVzdGVkLWZpcm13YXJlL2NvbW1pdHMvcnBpNV9kZXYvDQpSZW5l c2FzIHY0aDoNCmh0dHBzOi8vZ2l0aHViLmNvbS9HcnlnaXJpaVMvYXJtLXRydXN0ZWQtZmlybXdh cmUvY29tbWl0cy9yY2FyX2dlbjRfdjIuN192NHgtc2NtaV91cGQvDQoNCmJhc2UtY29tbWl0OiBk YmU2MGYyNDRjIChVcGRhdGUgWGVuIHRvIDQuMjEsIDIwMjUtMDItMjEpDQoNCkNoYW5nZXMgaW4g djEzOg0KLSBtZW1jcHlfe2Zyb20sdG99aW8oKTogYWxpZ24gb25seSB0aGUgSS9PIHBvaW50ZXIg YW5kIGFjY2VzcyB0aGUNCiAgcmVndWxhciBtZW1vcnkgc2lkZSB0aHJvdWdoIGdldF91bmFsaWdu ZWRfbGUzMigpL3B1dF91bmFsaWduZWRfbGUzMigpLg0KLSBkb2N1bWVudCB0aGUgY29udHJhY3Qg b2YgdGhlIGhlbHBlcnMgaW4geGVuL2lvLmgNCi0gcmV3b3JkIHRoZSBBcm0gaW1wbGVtZW50YXRp b24gbm90ZXMgdG8gc3RhdGUgdGhlIGNvbmNyZXRlIGFjY2Vzcw0KICBwYXR0ZXJuDQotIGRyb3Ag dGhlIGluY29ycmVjdCBjbGFpbSBhYm91dCBhdm9pZGluZyBlbmRpYW5uZXNzIGNvbnZlcnNpb24g ZnJvbSB0aGUNCiAgY29tbWl0IG1lc3NhZ2U7IG5vdGUgaW5zdGVhZCB0aGF0IHRoZSBfbGUzMiBo ZWxwZXJzIHBhaXIgd2l0aA0KICByZWFkbCgpL3dyaXRlbCgpIHNvIHRoZSBieXRlIHNlcXVlbmNl IGlzIHByZXNlcnZlZCBvbiBlaXRoZXIgZW5kaWFubmVzcw0KLSBmaXggdHlwbyBpbiBjb21taXQg ZGVzY3JpcHRpb24NCg0KQ2hhbmdlcyBpbiB2MTI6DQotIHJlYmFzZSB0byB0aGUgbGF0ZXN0IHN0 YWdpbmcNCi0gYWRkIFItQnMgZnJvbSBTdGVmYW5vIGFuZCBBY2sgZnJvbSBKYW4NCi0gYWRkIG1p c3NlZCBBY2suDQotIEFkZCBtaXNzZWQgUi1CDQotIGNvcnJlY3QgdGhlIEVtYWNzIGZvb3RlciBv ZiBib3RoIGZpbGVzLCB3aGljaCBhc2tlZCBmb3IgOCBjb2x1bW4NCnRhYiBpbmRlbnRhdGlvbiB3 aGlsZSB0aGUgY29kZSBpcyBpbiA0IGNvbHVtbiBYZW4gc3R5bGUNCi0gcmViYXNlIHRvIHRoZSBs YXRlc3Qgc3RhZ2luZw0KLSByZXR1cm4gRUlOVkFMIGlmIHhlbixzY2lfdHlwZT1zY21pX3NtY19t dWx0aWFnZW50IHdhcyBzZXQgYnV0DQpDT05GSUdfU0NNSV9TTUNfTUEgbm90IHNldA0KLSBwdXQg YXJtX3NjaV9hZ2VudF9pZCBhZnRlciB2OHJfZWwxX21zYSBhbmQgYmVmb3JlIHBhZCB0byBwcmVz ZXJ2ZQ0Kb3JkZXIuIFJlZHVjZWQgcGFkIGZyb20gdWludDE2X3QgdG8gdWludDhfdCB0byBmaWxs IHRoZSBnYXAgKHdhcyAyDQpieXRlcyBiZWZvcmUgYWRkaW5nIGFybV9zY2lfYWdlbnRfaWQgYW5k IGxlZnQgb25seSAxLCBzbyB1c2VkIHVpbnQ4X3QNCnRvIHByZXNlcnZlIHN0cnVjdHVyZSBzaXpl KQ0KLSBmaXggc2NtaV9oYW5kbGVfY2FsbCB0byB1c2UgYXJtX3NtY2NjX2d1ZXN0X3NtYyBoZWxw ZXIgZnVuY3Rpb24NCi0gdXBkYXRlIHNlbmRfc21jX21lc3NhZ2UgZnVuY3Rpb24gdG8gdXNlIG5l dyBmb3JtYXQgb2YNCmFybV9zbWNjY18xXzFfc21jDQotIGd1YXJkIHRoZSBEb20wIFNDTUkgYWdl bnQgaWQgc2V0dXAgaW4gY3JlYXRlX2RvbTAoKSBhbmQgTUEgcmVsYXRlZA0KZnVuY2l0b25zIHdp dGggQ09ORklHX1NDTUlfU01DX01BDQotIGZpeCB0aGUgeGVuX3NjbWlfY29uZmlnIGV4YW1wbGUg aW4gYm9vdGluZy50eHQsIHdoaWNoIHBsYWNlZCBwcm9wZXJ0aWVzDQphZnRlciBzdWJub2RlcyBh bmQgd2FzIHJlamVjdGVkIGJ5IGR0YyB3aXRoICJQcm9wZXJ0aWVzIG11c3QgcHJlY2VkZQ0Kc3Vi bm9kZXMiDQoNCkNoYW5nZXMgaW4gdjExOg0KLSBGaXggYWdlbnRfaWQgZG9jdW1lbnRhdGlvbjog Y2xhcmlmeSBpdCBhcHBsaWVzIHRvIFNDTUkgU01DDQptdWx0aS1hZ2VudCBzdXBwb3J0IG9ubHks IG5vdCBwbGFpbiBTQ01JIFNNQyAocmV2aWV3ZXIgZmVlZGJhY2spDQotIFJlbW92ZSAibm9uLXpl cm8iIGZyb20gYWdlbnRfaWQgZGVzY3JpcHRpb24gdG8gbWF0Y2ggYWNjZXB0ZWQNCnJhbmdlIFsw Li4yNTRdDQotIFJlbW92ZSAiVUlOVDhfTUFYICgyNTUpIGlzIHRyZWF0ZWQgYXMgaW52YWxpZCIg ZnJvbSB1c2VyDQpkb2N1bWVudGF0aW9uIGFzIHVubmVjZXNzYXJ5IGltcGxlbWVudGF0aW9uIGRl dGFpbA0KLSBBZGQgTElCWExfSEFWRV9TQ01JX1NNQ19NVUxUSUFHRU5UIGZlYXR1cmUgbWFjcm8g aW4gbGlieGwuaCB0bw0KYWR2ZXJ0aXNlIHRoZSBuZXcgc2NtaV9zbWNfbXVsdGlhZ2VudCB0eXBl IGFuZCBhZ2VudF9pZCBmaWVsZA0KLSBBZGQgYWdlbnRfaWQgdmFsaWRhdGlvbiBpbg0KbGlieGxf X2FyY2hfZG9tYWluX2J1aWxkX2luZm9fc2V0ZGVmYXVsdCgpIHRvIHJlamVjdCBpbnZhbGlkIHZh bHVlcyBhdA0KdGhlIGxpYnhsIGxldmVsLCBub3Qgb25seSBpbiB4bA0KDQpDaGFuZ2VzIGluIHYx MDoNCi0gcmVtb3ZlIHVudXNlZCBzY2lfZG9fZG9tY3RsIHN0dWIgZnJvbSBzY2kuaA0KLSByZW1v dmVkIGV4dHJhIGluY2x1ZGUgaW4gbWVtY3B5LXt0by9mcm9tfWlvLmMgZmlsZXMNCi0gRml4IHRh YnMgaW4gTUFJTlRBSU5FUlMgZmlsZQ0KLSByZW1vdmUgZHVwbGljYXRlIFNQRFggdGFnIGZyb20g c2NtaS1zaG1lbS5jDQotIGFkZCBjYXN0IHRvIEFSTV9TTUNDQ19JTlZBTElEX1BBUkFNRVRFUiB0 byBzZXR0bGUgdGhlIHNpZ24gc2luY2UNCkFSTV9TTUNDQ19JTlZBTElEX1BBUkFNRVRFUiBpcyAt MyB3aGljaCBpcyBwYXJ0IG9mIHRoZSBzcGVjIGFuZCByZXNwDQppcyB0aGUgZGVmYXVsdCBzbWNj YyBjYWxsIHN0cnVjdHVyZS4NCi0gdXBkYXRlIGZyZWVfY2hhbm5lbF9saXN0LiBBZGQgc3Bpbmxv Y2sgdG8gYXZvaWQgcmFjZSBjb25kaXRpb24gYW5kDQphIGNvbW1lbnQgd2l0aCBhIGRlc2NyaXB0 aW9uIG9mIHRoZSBmdW5jdGlvbiB3b3JrDQotIHByZXNlcnZlIGVycm9yIG9mIHNtY19jcmVhdGVf Y2hhbm5lbCBpbiBzY21pX3Byb2JlDQotIGNoZWNrIHNjbWkgc2htZW0gYWRkcmVzcyBhbGlnbm1l bnQgYXMgd2VsIGFzIGl0IGlzIGRvbmUgZm9yIHNpemUNCi0gY2hlY2sgZm9yIGQtPmFyY2guc2Np X2RhdGEgIT0gTlVMTCBpbiBzY21pX2hhbmRsZV9jYWxsDQotIHVzZSBTQ01JX1NITUVNX01BUFBF RCBzaXplIGZvciBpb21lbV9wZXJtaXRfYWNjZXNzDQotIGNoYW5nZSBsZW4gdHlwZSB0byB1bnNp Z25lZCBpbiBzaG1lbV97Z2V0fHB1dH1fbWVzc2FnZQ0KLSByZW5hbWUgc2htZW1fY2hhbm5lbF9p c19mcmVlIHRvIHNobWVtX2NoYW5uZWxfc3RhdHVzDQotIGFkZCBjb21tZW50IGFib3V0IHNraXBw aW5nIG1lc3NhZ2Ugc3RhdHVzIHdoZW4gZ2V0dGluZyBtZXNzYWdlIHJlc3BvbnNlDQotIFNldCBj b3JyZWN0IGFnZW50X2lkIHJhbmdlcyBmb3IgZG9tMGxlc3MgYW5kIGEgdG9vbHN0YWNrLiBBZ2Vu dF9pZCAwDQppcyBub3QgYmluZGVkIGZvciBkb20wIHNvIGNhbiBiZSByZXVzZWQuIEFsc28gbWVu dGlvbmVkIHRoYXQNClVJTlQ4X01BWCAoMjU1KSBpcyB0cmVhdGVkIGFzIGludmFsaWQgYWdlbnRf aWQuDQotIFNwbGl0IGh5cGVydmlzb3IgYW5kIHRvb2xzdGFjayBjaGFuZ2VzIGludG8gc2VwYXJh dGUgY29tbWl0cw0KLSBtb3ZlIGluaXQgbGlzdCBhbmQgc3BpbiBpbml0IGFmdGVyIGluaXRpYWwg Y2hlY2tzIGluIHByb2JlIGNhbGwNCi0gZml4IHR5cG8gaW4gY29tbWVudHMNCi0gY2xlYW4gcmVz b3VyY2VzIHdoZW4gc2NpX3JlZ2lzdGVyIHJldHVybnMgYW4gZXJyb3IuDQotIFNwbGl0IGh5cGVy dmlzb3IgYW5kIHRvb2xzdGFjayBjaGFuZ2VzIGludG8gc2VwYXJhdGUgY29tbWl0cw0KLSByZXBo cmFzZSBzZWN0aW9uIGFib3V0IC9maXJtd2FyZS9zY21pLiBNZW50aW9uZWQgdGhhdCB0aGlzIG5v ZGUgaXMNCnRha2VuIGZyb20gSG9zdCBEVCBhbmQgY29waWVkIHVubW9kaWZpZWQuDQotIGZpeCB4 ZW4scmVnIGFkZHJlc3MgZm9yIHNlY29uZGFyeSBkb21haW5zIGZvciBEb20wbGVzcyBjb25maWd1 cmF0aW9uDQoNCkNoYW5nZXMgaW4gdjk6DQotIHRyZWF0IFNDSSBhcyBhIGdhdGUgZm9yIFhFTl9E T01DVExfKmFzc2lnbl9kZXZpY2U6IGFib3J0IGJlZm9yZQ0KSU9NTVUgaWYgc2NpX2RvX2RvbWN0 bCgpIHJldHVybnMgYW4gZXJyb3Igb3RoZXIgdGhhbiAtRU5YSU8sIGluc3RlYWQNCm9mIHRyeWlu ZyB0byBwcm9wYWdhdGUgU0NJIGVycm9ycyBhZnRlciBhIHN1Y2Nlc3NmdWwgSU9NTVUNCm9wZXJh dGlvbi4gVGhpcyBhdm9pZHMgcGFydGlhbCBzdWNjZXNzIGFuZCB0aGUgbmVlZCBmb3IgSU9NTVUg cm9sbGJhY2suDQotIHJlbW92ZSBlYXJseSByZXR1cm4gZnJvbSBkb19kb21jdGwoKSBpbiB0aGUg YXNzaWduX2RldmljZQ0KcGF0aCB0byBrZWVwIFJDVSBoYW5kbGluZyBpbnRhY3QuDQotIGNoYW5n ZSBJU19FTkFCTEVEKCopIHRvICNpZmRlZiBpbiBzY2lfZG9fZG9tY3RsIHF1YXJkDQotIHJld29y ZCBjb21taXQgZGVzY3JpcHRpb24gdG8gcmVmZXIgdG8gbWVtY3B5X2Zyb21pbyBhbmQgbWVtY3B5 X3RvaW8NCi0gb3JkZXJpbmcgb2JqLXkgaW4gTWFrZWZpbGUNCi0gcmVuYW1lIEFMTF9MSUJTIHRv IEFSQ0hfTElCUw0KLSBkcm9wIGlvLmggYW5kIG1vdmUgZGVmaW5pdGlvbnMgdG8gdGhlIGNvbW1v biBoZWFkZXIsIGZpeCBjb21tZW50cyB0bw0KYmUgYXJjaCBuZXV0cmFsDQotIHVwZGF0ZSBjb21t ZW50cyBmb3IgbWVtY3B5X3tmcm9tL3RvfWlvIGltcGxlbWVudGF0aW9uDQotIHNvcnQgYW5kIHJl ZmFjdG9yIE1BSU5UQUlORVJTIGVudGllcw0KLSByZW1vdmUgU3B1cmlvdXMgY2hhbmdlcw0KLSBh ZGQgZXh0cmEgY2hlY2sgdG8gYXZvaWQgQVNTRVJUIHdoZW4gY2FsbGluZyB1bm1hcF9jaGFubmVs X21lbW9yeQ0KZnJvbSBhc3NpZ24gZGV2aWNlIG1ldGhvZA0KLSBzZXQgY29ycmVjdCB0eCBmbGFn IHRvIFNDTUlfQkFTRV9BR0VOVF9QRVJNSVNTSU9OU19SRVNFVCB3aGVuDQpmcmVlaW5nIHJlc291 cmNlcy4gRmxhZyBzaG91bGQgYmUgc2V0IHRvIDEgYWNjb3JkaW5nIHRvIHRoZQ0Kc2VjdGlvbiA0 LjIuMi4xMiBbMF0uDQotIGZpeCBkdCBub2RlIGNvcG1hcmluZw0KLSBtb3ZlZCBjaGFubmVsLT5z aG1lbSBjaGVjayBmcm9tIEFTU0VSVCBpbiB1bm1hcF9tZW1vcnlfY2hhbm5lbCB0bw0KImlmIiBz dGF0ZW1lbnQuIFRoaXMgd2lsbCBwcmV2ZW50IGZpcmluZyBBU1NFUlQgaWYNCnVubWFwX2NoYW5u ZWxfbWVtb3J5IHdhcyBjYWxsZWQgdHdpY2Ugb24gdGhlIHNhbWUgY2hhbm5lbC4NCg0KQ2hhbmdl cyBpbiB2ODoNCi0gY2hlY2sgZm9yIENPTkZJR19BUk1fU0NJIHRvIGJlIGViYWJsZWQgaW5zdGVh ZCBvZiBDT01GSUdfQVJNIGJlZm9yZQ0KY2FsbGluZyBzY2lfZG9fZG9tY3RsDQotIHJld29yayBz Y2lfZG9fZG9tY3RsIGNhbGwgdG8gYXZvaWQgZXh0cmEgY2hlY2tzLCBpbXByb3ZlZCBlcnJvcg0K aGFuZGxpbmcuDQotIGRvIG5vdCBwcm9wYWdhdGUgcmV0MSBpZiBzY2lfZG9fZG9tY3RsIHJldHVy bmVkIHBvc2l0aXZlIHJldA0KLSB1cGRhdGVkIGNvbW1lbnQgaW4gZG9tY3RsLmMgY29kZQ0KLSBz d2l0Y2hlZCB0byBvcmRlcmVkIGFjY2Vzc29ycyB0byBhZGRyZXNzIHRoZSBvcmRlcmluZyBhbmQg YmFycmllcg0KY29uY2VybnMuDQotIHVwZGF0ZWQgdGhlIGRvY3VtZW50YXRpb24gdG8gbWF0Y2gg dGhlIGltcGxlbWVudGF0aW9uIGFuZCBleHBsaWNpdGx5DQpzdGF0ZSB0aGUgc3VwcG9ydGVkIGFj Y2VzcyBzaXplcyBhbmQgZ3JhbnVsYXJpdHkuDQotIHJlbmFtZSBtZW1jcHlfKiBpbXBsZW1lbnRh dGlvbiBmaWxlcyB0byBtZW1jcHUtKiB0byBmb2xsb3cgbmFtaW5nDQpjb252ZW5zaW9uDQotIGZp eCBpbmRlbnRhdGlvbiB0byBtYXRjaCBYZW4gc3R5bGUNCi0gZml4IGludGVuZGF0aW9uIHRvIG1h dGNoIFhlbiBzdHlsZQ0KLSBtb3ZlIG1lbWNweS17ZnJvbS90b31pbyB0byBtb3JlIGNvbnZlbmll bnQgbGlicmFyeSBwbGFjZQ0KLSB1cGRhdGUgeGVuX3NjbWkgZnVuY19pZCBpbiBjb21taXQgZGVz Y3JpcHRpb24NCi0gdXBkYXRlZCBkb2N1bWVudGF0aW9uIHdpdGggdGhlIG5ldyBEVCBmb3JtYXQN Ci0gdXBkYXRlZCBvcHRfZG9tMF9zY21pX2FnZW50X2lkIHNldHRpbmcgdG8gYXZvaWQgaXQgdG8g YmUgZXF1YWwNClNDTUlfQUdFTlRfSURfSU5WQUxJRC4NCi0gY2hhbmdlZCBTQ01JX0FHRU5UX0lE X0lOVkFMSUQgZnJvbSAweGZmIHRvIFVJTlQ4X01BWCB3aGljaCBtYWtlcw0KY29kZSBtb3JlIGNs ZWFyIHNob3dpbmcgdGhhdCBVSU5UOF9NQVggaXMgdGhlYXRlZCBsaWtlIGludmFsaWQNCmFnZW50 X2lkIGFuZCBjb3VsZG4ndCBiZSB1c2VkLiBBbHNvIGV4Y2x1ZGVkIFNDTUlfQUdFTlRfSURfSU5W QUxJRA0KZnJvbSBhY2NlcHRhYmxlIHZhbHVlIHJhbmdlDQotIHJlbW92ZSBvdXRkYXRlZCB4ZW4s Y29uZmlnIHByb3BlcnR5IGlnbm9yZSwgYWRkZWQgeGVuLHNjaSBjb21wYXRpYmxlDQp0byBza2lw X21hdGNoZXMgaW4gaGFuZGxlX25vZGUNCi0gYWRkIGRvY3VtZW50YXRpb24gZm9yIHByZS1leGlz dGluZyBzY21pLXNtYy1wYXNzdGhyb3VnaCBjb21tYW5kIGxpbmUNCm9wdGlvbiBpbiBhbHBoYWJl dGljYWxseSBjb3JyZWN0IGxvY2F0aW9uIChpbiAncycgc2VjdGlvbikNCi0gYWRkIG5vdGUgdG8g Y29tbWl0IGRlc2NyaXB0aW9uIGFib3V0IGRvY3VtZW50YXRpb24gZm9yIHByZXZpb3VzbHkNCnVu ZG9jdW1lbnRlZCBzY21pLXNtYy1wYXNzdGhyb3VnaA0KLSBGaXggU01DIElEcyBpbiBEVCBleGFt cGxlcyAoWGVuIG1hbmFnZW1lbnQgdXNlcyAweDgyMDAwMDAzLCBEb20wIHVzZXMgMHg4MjAwMDAw MikNCi0gQWRkIGV4cGxpY2l0IG5vdGUgZXhwbGFpbmluZyB3aHkgRG9tMCBhbmQgWGVuIGNoYW5u ZWxzIGRvIG5vdCBjb25mbGljdA0KLSBEb2N1bWVudCBkb20wbGVzcyBtdWx0aS1hZ2VudCBjb25m aWd1cmF0aW9uIGV4YW1wbGUgKHhlbixzY2lfdHlwZSAvIHhlbixzY2ktYWdlbnQtaWQpDQotIEFk ZCBzY21pX3hlbiBub2RlIHRvIGFnZW50LWRpc2NvdmVyeSBleGFtcGxlIHdpdGggI3NjbWktc2Vj b25kYXJ5LWFnZW50cy1jZWxscyA9IDINCi0gRHJvcCBkb20wPXNjaS1hZ2VudC1pZCBjb21tYW5k IGxpbmUgaGFuZGxpbmc7IERvbTAgU0NNSSBpcyBub3cgZW5hYmxlZCB2aWENCiAgeGVuLGRvbTAt c2NpLWFnZW50LWlkIGluIHRoZSB4ZW4sc2NpIERUIGNvbnRhaW5lcg0KLSBSZWZyZXNoIGRvY3Mg YW5kIGV4YW1wbGVzIHRvIG1lbnRpb24gdGhlIERUIHByb3BlcnR5IGluc3RlYWQgb2YgdGhlIGNt ZGxpbmUgb3B0aW9uDQotIHVwZGF0ZSBkb2N1bWVudGF0aW9uIHRvIG1hdGNoIHRoZSBsYXN0IERU IGZvcm1hdA0KLSBmaXhlZCBSU1Q6ICIuLi4gY29kZS1ibG9jazo6IGR0cyIgLT4gIi4uIGNvZGUt YmxvY2s6OiBkdHMiDQotIHVwZGF0ZSBkb2N1bWVudGF0aW9uIHdpdGggZG9tMGxlc3MgY29uZmln dXJhdGlvbiBleGFtcGxlDQotIHVwZGF0ZSBkb2N1bWVudGF0aW9uIHdpdGggbmV3IHBhcmFtIHhl bixkb20wLXNjaS1hZ2VudC1pZA0KaW5zdGVhZCBvZiB0aGUgY29tbWFuZCBsaW5lIHBhcmFtZXRl cg0KDQpDaGFuZ2VzIGluIHY3Og0KLSB1cGRhdGUgZG9tY3RsIHRvIGJ1aWxkIG9uIGJvdGggQXJt IGFuZCB4ODYgcGxhdGZvcm1zDQotIG1vdmUgcmV0MSBkZWNsYXJhdGlvbiB0byB0aGUgdG9wIG9m IHRoZSBmdW5jdGlvbiBhcyByZXF1aXJlZCBieSBjb2RlDQpzdHlsZQ0KLSB4ODYgZ3VpZGFuY2U6 IHJlbW92ZWQgdGhlIHNwZWN1bGF0aXZlIG5vdGU7IGhlYWRlciBub3cganVzdCBzYXlzDQogIGVh Y2ggYXJjaCBzdXBwbGllcyBpdHMgb3duIGltcGxlbWVudGF0aW9uIG9yIG1hY3JvLg0KLSBuYW1l IHNwYWNpbmc6IGRyb3BwZWQgdGhlIGRvdWJsZS11bmRlcnNjb3JlOyB0aGUgaGVscGVycyBhcmUg bm93DQogIG1lbWNweV9mcm9taW8gLyBtZW1jcHlfdG9pby4gVGhlIGhlYWRlciBhbHNvIGV4cGxp Y2l0bHkgYWxsb3dzIGFuDQogIGFyY2ggdG8gZGVmaW5lIHRoZXNlIGFzIG1hY3JvcyBiZWZvcmUg aW5jbHVkaW5nIGl0Lg0KLSB1cGRhdGVkIGlvLmMgdG8ga2VlcCAzMi1iaXQgdHJhbnNmZXJzIHNh ZmUgb24gYXJtMzINCi0gbW92ZWQgdG8gX19yYXdfcmVhZCovX19yYXdfd3JpdGUqIGFjY2Vzc29y cyB0byBhdm9pZCBlbmRpYW5uZXNzIGNvbnZlcnNpb24uDQotIHNwbGl0IHRoZSBoZWxwZXJzIGlu dG8gc2VwYXJhdGUgY29tcGlsYXRpb24gdW5pdHMNCi0gcmV3b3JrIHNjbWkgbm9kZXMgZm9yIHhl biB0byBtYXRjaCBvbiBjb21wYXRpYmxlIHN0cmluZyBpbnN0ZWFkIG9mDQp0aGUgZGlyZWN0IHBh dGgNCi0gdXBkYXRlIGRvY3VtZW50YXRpb24gaW4gc2VjdGlvbiBvZiB0aGUgeGVuX3NjbWkgY29u ZmlndXJhdGlvbiB3aGljaA0KaXMgbWF0Y2hlZCBieSAieGVuLHNjaSIgY29tcGF0aWJsZSBpbnN0 ZWFkIG9mIHRoZSBkaXJlY3QgcGF0aC4NCg0KQ2hhbmdlcyBpbiB2NjoNCi0gY2hhbmdlIGlvbW11 X2RvX2RvbWN0bCBhbmQgc2NpX2RvX2RvbWN0bCBjb21tYW5kIG9yZGVyIGFuZA0KY2FsbCBzY2lf ZG9fZG9tY3RsIGZpcnN0IHdoaWNoIHdpbGwgcHJvZHVjZSBjbGVhbmVyIGNvZGUgcGF0aC4NCkFs c28gZHJvcHBlZCBjaGFuZ2luZyByZXR1cm4gY29kZSB3aGVuIGlvbW11IHdhcyBkaXNhYmxlZCBp bg0KaW9tbXVfZG9fZG9tY3RsLg0KLSBzb3J0ZWQgb2JqcyBpbiBNYWtlZmlsZSBhbGhhYmV0aWNh bGx5DQotIGFkZGVkIG5ld2xpbmUgYXQgdGhlIGVuZCBvZiBNYWtlZmlsZQ0KLSB1c2VkIHVpbnR7 Tn1fdCBpbnRlYWQgb2YgdXtOfQ0KLSBhZGQgY29tbWVudCBhYm91dCB3aHkgMzIgYml0IElPIG9w ZXJhdGlvbnMgd2VyZSB1c2VkDQotIHVwZGF0ZWQgY2FzdCBvcGVydGFpb25zIHRvIGF2b2lkIGRy b3BwaW5nIGNvbnN0bmVzcyB3aGljaCBpcyB3cm9uZw0KLSBtb3ZlIGZ1bmN0aW9uIGRlZmluaXRp b25zIHRvIGdlbmVyaWMgcGxhY2Ugc28gdGhlIGNvdWxkIGJlIHJldXNlZCBieQ0Kb3RoZXIgYXJj aA0KLSBhZGQgU1BEWCB0YWcgdG8gaW8uYw0KLSB1cGRhdGVkIHNjbWktc2htZW0gdG8gdXNlIGlv LmggZnJvbSBnZW5lcmljIGxvY2F0aW9uDQotIHVwZGF0ZSBzY21pX2FnZW50X2lkIHBhcmFtZXRl ciB0byBiZSBwcm92aWRlZCBpbnNpZGUgZG9tMD0gcGFyYW1ldGVyDQpsaXN0IGFuZCBoYXZlIHRo ZSBmb2xsb3dpbmcgZm9ybWF0ICJkb20wPXNjaS1hZ2VudC1pZD0wIg0KVGhpcyBjaGFuZ2Ugd2Fz IGRvbmUgYXMgYSByZXNwb25zZSBmb3IgU3RlZmFubyBjb21tZW50IGFuZA0KcmVxdWlyZXMgYSBs b3Qgb2YgY29kZSBjaGFuZ2VzLCBidXQgcHJvZHVjZXMgbXVjaCBjbGVhbmVyIHNvbHV0aW9uDQp0 aGF0J3Mgd2h5IEkndmUgYWRkZWQgaXQgdG8gdGhlIGNvZGUuDQotIGZpeCBmaWxlIGNvbW1lbnRz IGFuZCByZXR1cm4gY29kZXMNCi0gZml4IGxlbmdodCBjaGVja3MgaW4gc2htZW1fe2dldCxwdXR9 X21lc3NhZ2UgdG8gdXNlIG9mZnNldG9mDQotIHJlbW92ZSBsZW4gbWVtYmVyIGZyb20gc2NtaV9j aGFubmVsIHN0cnVjdHVyZSBhcyBpdCBpcyBub3QgdXNlZA0KLSBzZXQgc2NtaS1zZWNvbmRhcnkt YWdlbnRzIHByb3BlcnR5IHRvIGJlIG1hbmRhdG9yeSBzaW5jZSBpZiBubw0Kc2Vjb25kYXJ5IGFn ZW50cyB3ZXJlIHByb3ZpZGVkIHRoZW4gdGhlcmUgaXMgbm8gc2VuY2UgdG8gZW5hYmxlIHNjbWkN CndoZW4gbm8gc2Vjb25kYXJ5IGFnZW50cyBhcmUgcG9wdWxhdGVkIHRvIHRoZSBEb21haW5zDQot IHVwZGF0ZSBkb2N1bWVudGF0aW9uIGluIGJvb3RpbmcudHh0LCBhZGRlZCB4ZW5fc2NtaSBub2Rl IHRvIHRoZQ0KZXhhbXBsZQ0KLSBhZGp1c3QgZC0+YXJjaC5zY2lfZW5hYmxlZCB2YWx1ZSBpbiBz Y21pX2RvbWFpbl9kZXN0cm95DQotIGZpeCBsb2NrIG1hbmFnZW1lbnQgaW4gc21jX2NyZWF0ZV9j aGFubmVsIGNhbGwNCi0gYXZvaWQgZXh0cmEgbWFwX2NoYW5uZWxfbWVtb3J5IGNvbW1hbmQgZm9y IFhlbiBtYW5hZ2VtZW50IGNoYW5uZWwNCmJlY2F1c2UgY29sbGVjdF9hZ2VudF9pZCBjYWxsIHVu bWFwcyBtZW1vcnkgaWYgRE9NSURfWEVOIGlzIG5vdA0Kc2V0LiBTbyBmb3IgWGVuIG1hbmFnZW1l bnQgY2hhbm5lbCB3ZSBjYW4gaW5pdCBkb21haW5faWQgYWQgRE9NSURfWEVODQpiZWZvcmUgY2Fs bGluZyBjb2xsZWN0X2FnZW50X2lkIHNvIG1lbW9yeSBzaG91bGRuJ3QgYmUgdW5tYXBwZWQuDQot IHJlbW92ZSBhbGwgSFZDIG1lbnRpb25zIGZyb20gdGhlIG11bHRpLWFnZW50IGRvYw0KLSB1cGRh dGUgc2NpLWFnZW50LWlkIHBhcmFtZXRlciBkZXNjcmlwdGlvbiBpbiB0aGUgZG9jdW1lbnRhdGlv bg0KLSBhZGQgbWlzc2luZyBTaWduLW9mDQotIG1pbm9yIGZpeGVzIGFjcm9zcyB0aGUgZG9jdW1l bnQNCg0KQ2hhbmdlcyBpbiB2NToNCi0gcmV0dXJuIC1FSU5WQUwgaWYgbWVkaWF0b3Igd2l0aG91 dCBhc3NpZ25fZHRfZGV2aWNlIHdhcyBwcm92aWRlZA0KLSBpbnZlcnQgcmV0dXJuIGNvZGUgY2hl Y2sgZm9yIGlvbW11X2RvX2RvbWN0bCBpbg0KWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlIGRvbWN0 bCBwcm9jZXNzaW5nIHRvIG1ha2UgY2xlYW5lciBjb2RlDQotIGNoYW5nZSAtRU5PVFNVUFAgZXJy b3IgY29kZSB0byAtRU5YSU8gaW4gc2NpX2RvX2RvbWN0bA0KLSBoYW5kbGUgLUVOWElPIHJldHVy biBjb21kZSBvZiBpb21tdV9kb19kb21jdGwNCi0gbGVhdmUgIWR0X2RldmljZV9pc19wcm90ZWN0 ZWQgY2hlY2sgaW4gaW9tbXVfZG9fZHRfZG9tY3RsIHRvIG1ha2UNCmNvZGUgd29yayB0aGUgc2Ft ZSB3YXkgaXQncyBkb25lIGluICJoYW5kbGVfZGV2aWNlIiBjYWxsIHdoaWxlDQpjcmVhdGluZyBo d2RvbShkb20wKSBhbmQgImhhbmRsZV9wYXNzdGhyb3VnaF9wcm9wIiBjYWxsIGZvciBkb20wbGVz cw0KY3JlYXRpb24NCi0gZHJvcCByZXR1cm4gY2hlY2sgZnJvbSBzY2lfYXNzaWduX2R0X2Rldmlj ZSBjYWxsIGFzIG5vdCBuZWVkZWQNCi0gZG8gbm90IHJldHVybiBFSU5WQUwgd2hlbiBhZGRpZ25f ZHRfZGV2aWNlIGlzIG5vdCBzZXQuIFRoYXQgaXMNCmJlY2F1c2UgdGhpcyBjYWxsYmFjayBpcyBv cHRpb25hbCBhbmQgbm90IGltcGxlbWVudGVkIGluIHNpbmdsZS1hZ2VudCBkcml2ZXINCi0gbW92 ZSBtZW1jcHlfdG9pby9mcm9taW8gdG8gdGhlIGdlbmVyaWMgcGxhY2UNCi0gZml4IGRldmljZS10 cmVlIGV4YW1wbGUgZm9ybWF0IGluIGJvb3RpbmcudHh0LCBhZGRlZCAiOyIgYWZ0ZXIgIn0iLg0K LSB1cGRhdGUgZGVmaW5lIGluIHNjbWktcHJvdG8uaA0KLSB1cGRhdGUgZGVmaW5lIGluIHNjbWkt c2htZW0uaCBmaWxlDQotIHNjbWlfYXNzaWduX2RldmljZSAtIGRvIG5vdCBpZ25vcmUgLUVPUE5P VFNVUFAgcmV0dXJuDQpjb2RlIG9mIHRoZSBkb19zbWNfeGZlcg0KLSByZW1vdmUgb3ZlcndyaXRp bmcgYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQgYWZ0ZXINClNDTUlfQkFTRV9ESVNDT1ZFUl9BR0VO VCBjYWxsDQotIGFkZCBtdWx0aS1hZ2VudCBmaWxlcyB0byB0aGUgTUFJTlRBSU5FUlMNCi0gYWRk IFNDTUkgbXVsdGktYWdlbnQgZGVzY3JpcHRpb24gdG8gdGhlIFNVUFBPUlQubWQNCi0gaGFuZGxl IEFSTV9TTUNDQ19JTlZBTElEX1BBUkFNRVRFUiByZXR1cm4gY29kZSBhbmQgcmV0dXJuIC1FSU5W QUwNCmZvciBzbWMgY2FsbA0KLSB1cGRhdGVkIGNvbGxlY3RfYWdlbnRzIGZ1bmN0aW9uLiBTZXQg YWdlbnRfaWQgcGFyYW1ldGVyIGFzIG9wdGlvbmFsDQppbiBzY21pLXNlY29uZGFyeS1hZ2VudHMg ZGV2aWNlLXRyZWUgcHJvcGVydHkNCi0gaW50cm9kdWNlICIjc2NtaS1zZWNvbmRhcnktYWdlbnRz LWNlbGxzIiBwYXJhbWV0ZXIgdG8gc2V0IGlmDQphZ2VudF9pZCB3YXMgcHJvdmlkZWQNCi0gcmVh bm1lIHhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMgcHJvcGVydHkgdG8gc2NtaS1zZWNvbmRhcnkt YWdlbnRzDQotIG1vdmUgbWVtY3B1X3RvaW8vZnJvbWlvIGZvciB0aGUgZ2VuZXJpYyBwbGFjZQ0K LSB1cGRhdGUgWGVuIHRvIGdldCBtYW5hZ2VtZW50IGNoYW5uZWwgZnJvbSAvY2hvc2VuL3hlbixj b25maWcgbm9kZQ0KLSBnZXQgaHlwZXJ2aXNvciBjaGFubm5lbCBmcm9tIG5vZGUgaW5zdGVhZCBv ZiB1c2luZyBoYXJkY29kZWQNCi0gdXBkYXRlIGhhbmRsaW5nIHNjbWkgYW5kIHNobWVtIG5vZGVz IGZvciB0aGUgZG9tYWluDQotIFNldCBtdWx0aS1hZ2VudCBkcml2ZXIgdG8gc3VwcG9ydCBvbmx5 IEFybTY0DQotIHJld29yayBtdWx0aS1hZ2VudCBkcml2ZXIgdG8gbGVhdmUgSG9zdCBEZXZpY2Ut dHJlZSB1bm1vZGlmaWVkDQoNCkNoYW5nZXMgaW4gdjQ6DQotIHRvb2xzdGFjayBjb21tZW50cyBm cm9tIEFudGhvbnkgUEVSQVJEDQotIGFkZGVkIGRvbTBsZXNzIHN1cHBvcnQNCi0gYWRkZWQgZG9j IGZvciAieGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyINCg0KR3J5Z29yaWkgU3RyYXNoa28gKDIp Og0KICB4ZW4vZG9tY3RsOiBjaGFpbiBTQ0kgaGFuZGxpbmcgYmVmb3JlIElPTU1VIGluIGFzc2ln bl9kZXZpY2UgZG9tY3RsDQogIGRvY3M6IGFybTogYWRkIFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2Vu dCBkcml2ZXIgZG9jcw0KDQpPbGVrc2lpIE1vaXNpZWlldiAoNCk6DQogIHhlbjogYXJtOiBzbWNj YzogYWRkIElOVkFMSURfUEFSQU1FVEVSIGVycm9yIGNvZGUNCiAgbGliL2FybTogQWRkIEkvTyBt ZW1vcnkgY29weSBoZWxwZXJzDQogIHhlbi9hcm06IHNjbWk6IGludHJvZHVjZSBTQ0kgU0NNSSBT TUMgbXVsdGktYWdlbnQgZHJpdmVyDQogIHRvb2xzL3hsL2xpYnhsOiB3aXJlIHVwIFNDTUkgU01D IG11bHRpLWFnZW50IGNvbmZpZ3VyYXRpb24NCg0KIE1BSU5UQUlORVJTICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQogU1VQUE9SVC5tZCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgIDExICsNCiAuLi4vYXJtL2Zpcm13YXJlL2FybS1zY21pLnJz dCAgICAgICAgICAgICAgICAgfCA0MjIgKysrKysrKysrDQogZG9jcy9tYW4veGwuY2ZnLjUucG9k LmluICAgICAgICAgICAgICAgICAgICAgIHwgIDEzICsNCiBkb2NzL21pc2MvYXJtL2RldmljZS10 cmVlL2Jvb3RpbmcudHh0ICAgICAgICAgfCAxOTcgKysrKysNCiB0b29scy9pbmNsdWRlL2xpYnhs LmggICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDggKw0KIHRvb2xzL2xpYnMvbGlnaHQvbGli eGxfYXJtLmMgICAgICAgICAgICAgICAgICB8ICAxMyArDQogdG9vbHMvbGlicy9saWdodC9saWJ4 bF90eXBlcy5pZGwgICAgICAgICAgICAgIHwgICA0ICstDQogdG9vbHMveGwveGxfcGFyc2UuYyAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDI3ICsNCiB4ZW4vYXJjaC9hcm0vTWFrZWZpbGUg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEgKw0KIHhlbi9hcmNoL2FybS9hcmNoLm1rICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQogeGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1 aWxkLmMgICAgICAgICAgICAgICAgIHwgIDE3ICsNCiB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxk LmMgICAgICAgICAgICAgICAgICAgfCAgNDMgKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9LY29u ZmlnICAgICAgICAgICAgICAgICB8ICAxMiArDQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL01ha2Vm aWxlICAgICAgICAgICAgICAgIHwgICAxICsNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMg ICAgICAgICAgICAgICAgICAgfCAgMzYgKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXBy b3RvLmggICAgICAgICAgICB8IDE2NCArKysrDQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWkt c2htZW0uYyAgICAgICAgICAgIHwgMTE4ICsrKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21p LXNobWVtLmggICAgICAgICAgICB8ICA0NSArDQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWkt c21jLW11bHRpYWdlbnQuYyAgIHwgODE2ICsrKysrKysrKysrKysrKysrKw0KIHhlbi9hcmNoL2Fy bS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaCAgICAgICB8ICAgOCArDQogeGVuL2FyY2gvYXJt L2luY2x1ZGUvYXNtL3NtY2NjLmggICAgICAgICAgICAgIHwgICAxICsNCiB4ZW4vYXJjaC9hcm0v bGliL01ha2VmaWxlICAgICAgICAgICAgICAgICAgICAgfCAgIDIgKw0KIHhlbi9hcmNoL2FybS9s aWIvbWVtY3B5LWZyb21pby5jICAgICAgICAgICAgICB8ICA1NiArKw0KIHhlbi9hcmNoL2FybS9s aWIvbWVtY3B5LXRvaW8uYyAgICAgICAgICAgICAgICB8ICA1NiArKw0KIHhlbi9jb21tb24vZG9t Y3RsLmMgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxNSArDQogeGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvZGV2aWNlX3RyZWUuYyAgICAgICAgIHwgICA2ICsNCiB4ZW4vaW5jbHVkZS9wdWJs aWMvYXJjaC1hcm0uaCAgICAgICAgICAgICAgICAgfCAgIDUgKy0NCiB4ZW4vaW5jbHVkZS94ZW4v aW8uaCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgMjUgKw0KIDI5IGZpbGVzIGNoYW5nZWQs IDIxMjIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCiBjcmVhdGUgbW9kZSAxMDA2NDQg eGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaA0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4 ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5jDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhl bi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmgNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVu L2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYw0KIGNyZWF0ZSBtb2RlIDEw MDY0NCB4ZW4vYXJjaC9hcm0vbGliL01ha2VmaWxlDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9h cmNoL2FybS9saWIvbWVtY3B5LWZyb21pby5jDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNo L2FybS9saWIvbWVtY3B5LXRvaW8uYw0KDQotLSANCjIuNDMuMA0KDQpiYXNlLWNvbW1pdDogODIy YjBiZTY2MDZkNDljMTQ0Mzc0ODQ0NTMwZDUxNjg4OTc5MWZhOA0KYnJhbmNoOiBzY21pX21hX3Vw c3RydjEz From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:40:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:40:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429018.1651961 (Exim 4.92) (envelope-from ) id 1x91fb-0005iq-9d; Tue, 22 Sep 2026 14:40:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429018.1651961; Tue, 22 Sep 2026 14:40:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fb-0005gm-3k; Tue, 22 Sep 2026 14:40:31 +0000 Received: by outflank-mailman (input) for mailman id 1429018; Tue, 22 Sep 2026 14:40:29 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fZ-0005TY-KM for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:40:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91fZ-00AHxl-10 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:40:29 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2934d-bab6-0a2a0a5309dd-0a2a4506e4aa-30 for ; Tue, 22 Sep 2026 16:40:28 +0200 Received: from [40.107.159.85] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2935b-195a-0a2a45060019-286b9f557f3a-6 for ; Tue, 22 Sep 2026 16:40:28 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV2PR03MB11837.eurprd03.prod.outlook.com (2603:10a6:150:36e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 14:40:26 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:40:26 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Bb5HSoGBKYf41+2fpiu2AOe+eAgoee3Tkdu3NpF10DSloMVtg497v1M4vkijxGVrfTuZto7/+f5oQHzp3ajPdoLF7SVPiGm5x26/xZFW+WEqsep2EifMBU24HmnHpuA7P95k75QfhK2LK+ebWjlW4EmPo4UtG+dM5toQEur76VU2hd2WfE+neGW0gs985mcsR+Wgub1VxNlZuiyQqgNM2GTNQCzrdVidOe9Fg2fwzRr7Oo4tPPKodZapB6hAftiJlCLKzNa1oPwGKuxTnZEGHxZk5q1OHTLg4oeZYAOynAtI/krkHMksorqp6BvSghC73AMKf5ykxW86R1Sg1U7jag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XV5f3tUGW+mzcug+M+p3lP5Jfj6Y79rIFmhgwSn1QeI=; b=mv5GQPFp/AoFRT4KSbZcwUz3Pe4LxHPQvRHiYjzlkvScNEs9AX3japXGsxG0geIGYYauEFdGq+lhC6wpg8q8IBpGMrgetKoNeynku1UGieq674tCCKKE3Rmj8c/IGneW7C2JmmeHx1+HrUzXHnbcGEMn3Cg8nzGRYTGvS+ImuE44GkLaoboxYZxFEJN6+8wE48utI224QzuNq7QWGcuTgOX5mt9Y96+1XE3fB4wHy6uFPgs2RKcj0iFla6dnWTz3k6dwvmmeJ63IpP+4a/AzVEv1OXslKIWPJLj12xYkggcVHSykwLRNmtVcewVV3Pz2yeShuLSsXKX9hFQ5qY5vxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XV5f3tUGW+mzcug+M+p3lP5Jfj6Y79rIFmhgwSn1QeI=; b=I4uVZuLmx76+OQh8rILX5k5C/s2GXbecv3RPj0hONQ8Yx1gslFejvkrYulr04xNWmqk/GgVCKG612N5EFXb0Pg/Ga6xGgL7PFjIPuu5nN/EnRxN+7z+8y6hr0laIY0LyYTOdb3rtHXcKbSTTMgjtt0hAKFSe+3lrO52HnEm/7cPNqjwVfhZ+LFetoY6mgBii6f+EXSI4ibcXJ61w6jHPFEnEBeEWeCWJ/sTgFBFoRi9YMu3pZJ7XMlTq2QVKPhKIavkeByLzhIHGsPiKVhf8wjAqyQEmwLxE5wTld33PLHy47TMWymLK6zW1rEA5LO5nu2r7z6zHuJ011JQ5XyyC3w== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v13 3/6] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v13 3/6] lib/arm: Add I/O memory copy helpers Thread-Index: AQHdSqBNWHTiy8oSrE+yfsv9Eam6pw== Date: Tue, 22 Sep 2026 14:40:25 +0000 Message-ID: <89957e49342282942cfe923357287ff63d550cf3.1790087968.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV2PR03MB11837:EE_ x-ms-office365-filtering-correlation-id: a16d2b97-1553-48a0-8e15-08df18b770da x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|366016|1800799024|18002099003|22082099003|11063799006|56012099006|10067099003|38070700021|3023799007; x-microsoft-antispam-message-info: ZG59aq88gfqRBKGU+BiIDiWGzdF0CFuY3Um6obR6tWm5yaNkOG0TQtIv8GdWVJrj/31Jd9Ra2wNjFP7Vd5biC385Dh9qqyatlbrHYUGQHjlrYq5Epj3x/7kAcxfBJ+nAdS53FlD6bGEInhUBM2N9zQgT859AWZdKB83C/XlHin3TJnE1g1aOrB9I0whhNl/OaJxo54NDkv78UOIL/bwZZ1Y0yhi768Lcae8uSzuCWRYpMO+fFZu1AFHGbHcHVNzf8UlY5Z85bgc8YeD1z2TkmKAJcQep5ScgpL0pCSW0iSBGtOp8d6bIqUEDmic1vcb98/3h4PDfgNjWoUdqGiYI6+yaSTXxkeAL8ppOAHmEM6ibbAFAfOlYRdhy7Jh4wynAtW2tJZcRS2O1MHT4ZYhN4Tp9cCsepqDmbzldNrTqWpjBGuU5Wlgj6YEDdmg9zN20F24mhbcm61tcrBgvHWNkbYG8ce93fx0raccFWYMOwgwGFrg0VXsw0QGaNTHnZvhp3mNyVIrK9UzKmZRpuB9D7tFayJPa58s2kPFR+1bX4QETmIwnqdVWjEfd280iAn54iAVsjHZ3e7O0FP6hfeuzNQoz+vcF52g6iGLTBKbnrdlqaxMOHda5Zxz13LGrihCwYmCXdTMC1uAexL89jKn1YAfHrkzt6IB29Igv1514X2dwTcFsBkFzwCZTHJJKY9eOVAkNoTtDh4k1nhUBnZdu2l5b+8NnA58YjaFv9r44r3s= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(376014)(366016)(1800799024)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(38070700021)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?8LgwH6S6CAqJuA09iLrAmV6pZ6T/z0zr2Gxo0fvdX1KNWc0hW5D5EJwnIn?= =?iso-8859-1?Q?QiuFo83rXy/oNLQA8kkzAVmv2YF7FaEo5XvNnqNNRYssX1u+zMCuMu2wrg?= =?iso-8859-1?Q?0NKo7vszqzizAospCSybHAf/Rxn3QN6CjTlwqnKvE6dt8+cvzVb6OoceDl?= =?iso-8859-1?Q?DirbPunAIaTWu9Ig/cCwM6HNz3Xk7Q0i6mjsjn9/TSL5Jwm8+mmPXtxi+9?= =?iso-8859-1?Q?/VpZ2UzUWG2FUgoNNewvofANb3rWmOCf0CJbgQf2nnW7iX+aen23/mN/3V?= =?iso-8859-1?Q?JMBd7YcRDjpm/714tQXxWBIEDvIW3yj4fR3z4dVUgPDnaW985Vc2/Bi53e?= =?iso-8859-1?Q?XnlOE9LcbdyVKL11s4QS3Gqr2m2zFm0Mts3PTdWREMfes88kByeps5UQZK?= =?iso-8859-1?Q?ZLFMNGZdXS8NIgwsF7Q8N7HDqefvJdUGRrPLq7m63OvogjFrssa8LJX3kp?= =?iso-8859-1?Q?A0xt/mbHM1ABrSRXhUUn2dHUFhdWdIXPirMtf+U8YEn00otnSNfRpwDH+q?= =?iso-8859-1?Q?w+BruBptcqvmKIkVUI5mNBmzwwFkZHP9D6HFf9yKPKbyfa6fqNxnxKq+yS?= =?iso-8859-1?Q?Z/R64P1/bHbYJRBC9FTbhJj8aD01gq7RCwYQm3dY5N5madnI94HFK6Uipb?= =?iso-8859-1?Q?/EPL2zkTheHZu9nQuz/1386a+/dc6Nml4GqwKEge2oCpIYmTPhJhRyyoCo?= =?iso-8859-1?Q?wiOPcACZ+chaZsCj3FGnA7CwbA3r6wRG059al8WMywn9X3hV5Z2n1x1Zfo?= =?iso-8859-1?Q?eLTfj20aKH3GvO6QRsekOQbCorgDfh9C5cHs97olwP0iA57NfHaauO7pVd?= =?iso-8859-1?Q?1uWYY75/6+K8yITOm1xl9wl1BdbKLnyIjnz6g1PhRMHCrHz2KobtwcaHMy?= =?iso-8859-1?Q?c4X98R266ipJj6qC2R1WBlZmF+Y3hiAyocB4jXenw3M4ztQwec3QYgbhe2?= =?iso-8859-1?Q?yihIcW8v0sC3c7PlMDoY6PhHJM9B6f41pLjWzZyY8YvDzNQorhSpthvtHg?= =?iso-8859-1?Q?01rBV0VJC40hzmDNh1+BlKaoDEtSqN8JGwh6WddWvM/+6lqATS9fei0PBF?= =?iso-8859-1?Q?QAU/YG8Ka87KPXH+TVHkzlxSt5THnfkek+MuvxNXoCUYdhXMw9+DDN3tBd?= =?iso-8859-1?Q?hGSnKdTQcZNbmKacT+M1uwV7YPcecTFuTROY1n63+7d5CKjgn20ru0NgH8?= =?iso-8859-1?Q?zMzSdvFrZEBn3PUv+iKyEzs3OeTKQk238djhgI5TmzJlFjJUnUvoeU/6us?= =?iso-8859-1?Q?R6ftj9bpJLuqyISPDRbMFAxwoRzcsMv4ouM907hlTKPhEvtehZCuPkszOb?= =?iso-8859-1?Q?IVz5s6ZJRgAEjxVyvtDt4jrEtfZfq3BEPBce3gnDtzxWLC625w03JVH6Rj?= =?iso-8859-1?Q?CMZc+cY2WNj9vYH1Se54m4JMbYqZnjk/HPwjjhQ+9PeLUuCTL5GUYtgSul?= =?iso-8859-1?Q?Q+35FBcsMRCqR+zPGS0t1v/4CTFLh2L39mSp5reXJjIRVzqkpkjwBIxqTP?= =?iso-8859-1?Q?eog29FY+KX+6u+GkkHH8IZeLTtqc+SSAhepyP/1e7PH/kiBqNqIYgUaSN9?= =?iso-8859-1?Q?Up5Zhi+dktQYi6DbONfN6hW6AheLBohAjcGEiJvw3kGxp8NKjPX2ptlmPM?= =?iso-8859-1?Q?9+DT13QOBFhsEWpPx83wx3qbw9QTZ+gM3GI2V3D24lwrpeds78Ssknzd/J?= =?iso-8859-1?Q?h/M4RYxS6/fsMj4KYRurqExtnf3i5gbb3sqrH5tgAA0ScVBEf1yrhgkH6r?= =?iso-8859-1?Q?TafXkONsZxAdy30e9ybdXMKm4/D9/PJT9KeMgVxEbybc3mz60cF10Dt+gJ?= =?iso-8859-1?Q?WX6vK7+XkKANt4LiCVZIEHaSJCOkWCE=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a16d2b97-1553-48a0-8e15-08df18b770da X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 14:40:25.1077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lScBOep6x0XJOGqiMZP4Sw4x2LhCMFj2+KUecP/Pagmgn7TyC/OoWd1mtZtYdcQ8cTae7ylcfI35Nka2Gdgi4zGcL3najTzyxzoQOfeAQck= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11837 X-purgate-ID: tlsNG-16d1c6/1790088028-1F6C877B-2F8E688E/0/0 X-purgate-type: clean X-purgate-size: 10146 Introduce memcpy_fromio() and memcpy_toio() helpers to copy between regular memory and a memory-like I/O region on Arm. The generic prototypes live in io.h so other architectures can provide their own implementations. The helpers copy a byte sequence: byte accesses are used until the I/O pointer is 32-bit aligned and for the trailing count % 4 bytes, the aligned bulk uses 32-bit accesses. Only the I/O pointer is aligned, the regular memory side is accessed through get_unaligned_le32() / put_unaligned_le32(), so the access widths issued on the I/O side do not depend on the alignment of the memory buffer. These _le32 helpers pair with readl()/writel(), which are little endian accessors, hence the byte sequence is preserved on either CPU endianness. The constraints on the I/O region are documented next to the declarations in xen/io.h, the arch-specific access pattern next to the implementation. Signed-off-by: Oleksii Moisieiev Reviewed-by: Stefano Stabellini --- Changes in v13: - memcpy_{from,to}io(): align only the I/O pointer and access the regular memory side through get_unaligned_le32()/put_unaligned_le32(). - document the contract of the helpers in xen/io.h - reword the Arm implementation notes to state the concrete access pattern - drop the incorrect claim about avoiding endianness conversion from the commit message; note instead that the _le32 helpers pair with readl()/writel() so the byte sequence is preserved on either endianness Changes in v12: - Add missed R-B - correct the Emacs footer of both files, which asked for 8 column tab indentation while the code is in 4 column Xen style Changes in v10: - removed extra include in memcpy-{to/from}io.c files Changes in v9: - reword commit description to refer to memcpy_fromio and memcpy_toio - ordering obj-y in Makefile - rename ALL_LIBS to ARCH_LIBS - drop io.h and move definitions to the common header, fix comments to be arch neutral - update comments for memcpy_{from/to}io implementation Changes in v8: - switched to ordered accessors to address the ordering and barrier concerns. - updated the documentation to match the implementation and explicitly state the supported access sizes and granularity. - rename memcpy_* implementation files to memcpu-* to follow naming convension - fix indentation to match Xen style - fix intendation to match Xen style - move memcpy-{from/to}io to more convenient library place Changes in v7: - x86 guidance: removed the speculative note; header now just says each arch supplies its own implementation or macro. - name spacing: dropped the double-underscore; the helpers are now memcpy_fromio / memcpy_toio. The header also explicitly allows an arch to define these as macros before including it. - updated io.c to keep 32-bit transfers safe on arm32 - moved to __raw_read*/__raw_write* accessors to avoid endianness conversio= n. - split the helpers into separate compilation units Changes in v6: - sorted objs in Makefile alhabetically - added newline at the end of Makefile - used uint{N}_t intead of u{N} - add comment about why 32 bit IO operations were used - updated cast opertaions to avoid dropping constness which is wrong - move function definitions to generic place so the could be reused by other arch - add SPDX tag to io.c Changes in v5: - move memcpy_toio/fromio to the generic place xen/arch/arm/Makefile | 1 + xen/arch/arm/arch.mk | 1 + xen/arch/arm/lib/Makefile | 2 ++ xen/arch/arm/lib/memcpy-fromio.c | 56 ++++++++++++++++++++++++++++++++ xen/arch/arm/lib/memcpy-toio.c | 56 ++++++++++++++++++++++++++++++++ xen/include/xen/io.h | 25 ++++++++++++++ 6 files changed, 141 insertions(+) create mode 100644 xen/arch/arm/lib/Makefile create mode 100644 xen/arch/arm/lib/memcpy-fromio.c create mode 100644 xen/arch/arm/lib/memcpy-toio.c diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index b7afd3e58c..e448e69014 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -8,6 +8,7 @@ ifneq ($(CONFIG_NO_PLAT),y) obj-y +=3D platforms/ endif obj-y +=3D firmware/ +obj-y +=3D lib/ obj-$(CONFIG_TEE) +=3D tee/ obj-$(CONFIG_HAS_VPCI) +=3D vpci.o =20 diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk index dea8dbd18a..009bb22c45 100644 --- a/xen/arch/arm/arch.mk +++ b/xen/arch/arm/arch.mk @@ -2,6 +2,7 @@ # arm-specific definitions =20 ARCH_LIBS-y +=3D arch/arm/$(ARCH)/lib/lib.a +ARCH_LIBS-y +=3D arch/arm/lib/lib.a =20 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) $(call cc-option-add,CFLAGS,CC,-Wnested-externs) diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile new file mode 100644 index 0000000000..07a0d9186c --- /dev/null +++ b/xen/arch/arm/lib/Makefile @@ -0,0 +1,2 @@ +lib-y +=3D memcpy-fromio.o +lib-y +=3D memcpy-toio.o diff --git a/xen/arch/arm/lib/memcpy-fromio.c b/xen/arch/arm/lib/memcpy-fro= mio.c new file mode 100644 index 0000000000..98339a5cfa --- /dev/null +++ b/xen/arch/arm/lib/memcpy-fromio.c @@ -0,0 +1,56 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include + +/* + * Arm implementation notes: + * - Byte accesses are issued until the I/O pointer is 32-bit aligned and + * for the trailing count % 4 bytes; the aligned bulk uses 32-bit + * accesses. No wider accesses are issued. + * - The access widths on the I/O side depend only on the alignment of the + * I/O pointer and on count. The regular memory side is accessed through + * put_unaligned_le32(), so its alignment has no influence on them. + * - put_unaligned_le32() pairs with readl(), which is a little endian + * accessor, so the byte sequence is preserved on either CPU endianness. + * - The I/O region must be mapped with device attributes; ordering is + * provided by the accessors themselves, no extra barriers are added. + */ + +void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count) +{ + while ( count && !IS_ALIGNED((unsigned long)from, 4) ) + { + *(uint8_t *)to =3D readb(from); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + put_unaligned_le32(readl(from), to); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + *(uint8_t *)to =3D readb(from); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/lib/memcpy-toio.c b/xen/arch/arm/lib/memcpy-toio.= c new file mode 100644 index 0000000000..c0be79586d --- /dev/null +++ b/xen/arch/arm/lib/memcpy-toio.c @@ -0,0 +1,56 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include + +/* + * Arm implementation notes: + * - Byte accesses are issued until the I/O pointer is 32-bit aligned and + * for the trailing count % 4 bytes; the aligned bulk uses 32-bit + * accesses. No wider accesses are issued. + * - The access widths on the I/O side depend only on the alignment of the + * I/O pointer and on count. The regular memory side is accessed through + * get_unaligned_le32(), so its alignment has no influence on them. + * - get_unaligned_le32() pairs with writel(), which is a little endian + * accessor, so the byte sequence is preserved on either CPU endianness. + * - The I/O region must be mapped with device attributes; ordering is + * provided by the accessors themselves, no extra barriers are added. + */ + +void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count) +{ + while ( count && !IS_ALIGNED((unsigned long)to, 4) ) + { + writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + writel(get_unaligned_le32(from), to); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/xen/io.h b/xen/include/xen/io.h index 164a20c5d7..0b60be27c1 100644 --- a/xen/include/xen/io.h +++ b/xen/include/xen/io.h @@ -67,4 +67,29 @@ static inline bool write_mmio(volatile void __iomem *mem= , unsigned long data, return true; } =20 +/* + * Copy a sequence of bytes between regular memory and a memory-like I/O + * region, e.g. shared memory placed in RAM or SRAM mapped with device + * attributes. + * + * The I/O region must behave like byte-addressable storage: it has to + * accept 8-bit accesses at any byte address and naturally aligned 32-bit + * accesses, with plain byte-storage semantics in both cases (no side + * effects, no dependency on the access width). An implementation may use + * any of these widths, but never wider ones. The helpers are therefore + * not suitable for device registers with access-width requirements. + * + * Neither pointer needs to be aligned. The access widths issued on the + * I/O side depend only on the alignment of the I/O pointer and on count, + * never on the alignment of the regular memory pointer. + * + * Implementations are architecture-specific and may impose further + * constraints; see the respective arch//lib/memcpy-{from,to}io.c + * for the exact access pattern. + */ +void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count); +void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count); + #endif /* XEN_IO_H */ --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:40:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:40:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429019.1651973 (Exim 4.92) (envelope-from ) id 1x91fc-0005yW-2g; Tue, 22 Sep 2026 14:40:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429019.1651973; Tue, 22 Sep 2026 14:40:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fb-0005wg-S1; Tue, 22 Sep 2026 14:40:31 +0000 Received: by outflank-mailman (input) for mailman id 1429019; Tue, 22 Sep 2026 14:40:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fZ-0005Tf-Tu for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:40:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91fZ-00AHxl-A3 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:40:29 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2934d-bab6-0a2a0a5309dd-0a2a4506e4aa-32 for ; Tue, 22 Sep 2026 16:40:29 +0200 Received: from [40.107.159.85] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2935b-195a-0a2a45060019-286b9f557f3a-7 for ; Tue, 22 Sep 2026 16:40:29 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV2PR03MB11837.eurprd03.prod.outlook.com (2603:10a6:150:36e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 14:40:26 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:40:26 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EzlGfnmtrOySYxqR0CVQF3A8UPrRUqGqfnGixS8fqtoa+XPFH4xYd9lHbwCYg8nfATSIrkT9LKXLMbM4DhJ/ce2433RoS5xNzKMSHbFn/xTzjlwiR/uYq6l1fhZE98gRcmpWTXuEXH7mdQTKJqQzYuqRiZjLmxJXbCxLUIRX/aSrgnou2/H98iuQeZGtPLZtOSr4qT2T/rBk6yll6u3e1HpDE4OgBU65/4Rt/YWG2Dqt1Syt/dP41c0BgdR/AjG3kT5egXVxV2FU1ypcSDXDF4UdIL3R+OR5y8ckgZfPlfSaaQNUAyDAWqkn6vxVDmywaWgcqjlz4EIjUnHIC3zuhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SKdq67ybnX8uUukX1pkN+uLO/zxBaT9y96AQcmHIDKI=; b=AcxqyQULPFCuuj9SEGZk/603wBQz5wo0atwy9nqvgfWtVxQbmU8f83ydNo4Ih2syLgJUyObSm8TyZX/w4i7NcLLoEdjVjtUsUuEPu7gsnUqUy+TQ6Rq3z5CJnZhSIXpz0475HesUHEqKMDO/pmk8QXxQ5XW03oiqHQGVGf9aRYjc2ETcvzqOZ7KXtinzBrYs2i0yI5X8RlTuzfubwmPbsJ+sLbVf3ElOkOB8xr9toHZHmolabTNhcEI9YrOQayXuzPH2X4Hqb9G05Fe9jIeR/iUGQLTvBfiq+b9p2LqBpT1AJlWGya0qGY9IG3ISKCYUAFCP9sUkfimJo3pZ/8vkeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SKdq67ybnX8uUukX1pkN+uLO/zxBaT9y96AQcmHIDKI=; b=GvoP2pO2o+8CD9p1cRzfeCrnK3Q/IgO207riLwUb9DwUzeJzd346/cmEPqAH5LOW0zkrzhEgZ2D8ZhZqjRI7QqHVEZ4bs98l6Y6tagD+sCus0o1A8lhaB5FsKM2VKAx/CLvZXtJhENH9YgF9k1pymjKoXsCXuOKyehu5diEoNPH8GGA3wcqWimLXEYJz6ePsxU98rUX4M83qql5DJlGYNwS7h7grQXYwFUnrK3UOWBtlFe9B72Vf9DJutVFtdtOj7xLTR1oYgMuXKFGMHg3kGGMR6a6SGTE2HwXTAQf9l5I4KthRic0av00YMlfjF1dCJmCSt1oCGbdOXvTamHH/XQ== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdSqBOtjSUOlH6/km+/eJYUhrZfw== Date: Tue, 22 Sep 2026 14:40:25 +0000 Message-ID: <5c3ae163d21f619bf25c8757232a1a0867c3eb87.1790087968.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV2PR03MB11837:EE_ x-ms-office365-filtering-correlation-id: 9a179315-be2f-42b0-336e-08df18b77115 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|366016|1800799024|6133799003|18002099003|22082099003|11063799006|56012099006|10067099003|38070700021|3023799007; x-microsoft-antispam-message-info: 2Rh6NbS52YELNF/ZILOWlSb6aGL8c0PzIuuZshzAXuBqqL9vacNswIYJM4dnAx+xGosyWu58jkpGZ74aezKmLtT85gix8VnjeKZK2XuCr5NsE6BoSKiQbVm90FDW2mnZTBy8THT9iytalVvizr4y65sS2RLwuLMQJhmTNBV+nToQEDJHMQsSV9k2PQLFLY6RjeBsUJIsfnUaCTqmZl1TELuTkapOSRduu1/5uNs1/NYHfkxNfkcaYe+O97R7UJuxHSKSOaZOsOugkjp/JbygjuA7j+mUuWaKK5//T2zFHNKapD0fsoJwzS8TgXAzQCMzDYvY4YE3WsrWeQULjQ0NJC24iqeeffBbNqfLjYToo/mkiQNDiSQhKyxNXzvduOPtxDMprZhvoGHPrJlYPcVWI2u9GyVRgmFGG00FJHSwj1uJlLVUMrOGM2s0m+WdJN+pXqH3DSFh7DyfPbVFZcYjpCRnkI6NtmHH3GygAe2897S/QV9mVpLTHzlGnn/36ErJxQrn+xlyZJlWqfWD/sSY2/vnvUCvtWbLZDzxYiGih9yA4mTfPS2JUBelNz1ojpmNcTSF1dig6+2F23apqxmrnZxEn5K2QW9wOO+ogUQZTAEab7L1vZXTUndB6xFdj5P0aVdm8mxM3eEHLJET7GJmMwGdGeTTGYAM/yWTCxIXNm/ahZ8dOdWO1Tw+TYnK7sV2 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(376014)(366016)(1800799024)(6133799003)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(38070700021)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?/twz7Juw52gKPa+3Dm31czUkEHSXdMezJRsXwYhVfAU5Ez76s1PLuwh1kG?= =?iso-8859-1?Q?0mPvJ8ZSHBuIWwXlE7LvtnzX+v9y5VDWV5WV9AnDgPNXtxKLhbVNly6sVJ?= =?iso-8859-1?Q?kZWe+tutNO/72Trwa3hUEndrzW/3GyynXCWD8dDdvPxmStUSevRejl+6KH?= =?iso-8859-1?Q?haVxkdh6OUL7Nti6SWtULuyEho9C8k/tjost6RjCmYrXTeUXjLTo/4qtUZ?= =?iso-8859-1?Q?K1fQ41qoiNi2PPDnneo0METkvUnaACRqrD/8L5/uCAjqrLbxFIKd0Tl+Jh?= =?iso-8859-1?Q?ySq5zbmlmjCrVrQZ1X2i2FbYZJHjEE60l6kfOzCs0bX+3GOy2fTFe1waqk?= =?iso-8859-1?Q?tUnUAVmTj5P/pv4+Ei1ZA5NoykjqeEchnuQVcI4Sv7HljjQ4QGW3FPyZqv?= =?iso-8859-1?Q?THjO2rL/TsDZU/fJMwDv94wA8+jSUpesaskKYiLYehuioD16PnXWbWtfjD?= =?iso-8859-1?Q?fihrhwKImWEIPjnzmGS1qxq+YrpuVr+A0PmB6ca7b07LQ+4n+cDptXdv06?= =?iso-8859-1?Q?fs6ZCzfHKp7ZsH8yevxFUEfPNEFelcT/lknSbDKWcy01g365VdchUvTF+u?= =?iso-8859-1?Q?n1WtcStEo0Tr3w0aFatnFV0dFjkESWb8zA7K3wocrpMmoLH8vO12zlyrlQ?= =?iso-8859-1?Q?hakMsSD+DR6HyzNROzI2qnl9t9eMAJJWNYOOuMVBrsIE3d8wZtC7ugt9h/?= =?iso-8859-1?Q?MaL0z5TiYx/kLKllhX5Cbffek6mQIWgLMgPofeJZp86oN5J5WB0tGMZ/Kd?= =?iso-8859-1?Q?LDtu1ptaItoNWlvQ3MnQ32F+2qUlPr0hfTDbiU6Yn4bK07MjvHZxwLDg3M?= =?iso-8859-1?Q?JJ7vZBt/u4tjmJd+G+zldrtsuKuwqE3YyT0ovOlDFaNI63tLsxO6BVTpCn?= =?iso-8859-1?Q?qa8gxIi1Bi4tHR8V42fImfgm1Yak6j05lNRDVieijwQ+yQ4XCUXCTQdXDc?= =?iso-8859-1?Q?wW9sVIkJ/+3vap+jr/xPvbJrjHoiAH/yABhHk55F7UJsiVnCL+1nL/XfDY?= =?iso-8859-1?Q?MJDS2aRNBwDo6ymMiwP9jihnJG6fRp0EL3dYuDVJtRtIqkkqIhEOJRGUq2?= =?iso-8859-1?Q?ppQkW8lg3T738fJQngUxjTLOxCIFT8lrTIuS/CXU0NlC4hufaS6xaqsaee?= =?iso-8859-1?Q?X8jKd4OblyLUS6NP4zEPyOmp4NedEW6wu+t2SZdtknSJ4zyYjQJ/frTy28?= =?iso-8859-1?Q?IFpGZjQxB7vkVdYX35FDYaxBTj2s5GReqBRyUFRbLwuYrixQPug3NQr5da?= =?iso-8859-1?Q?Vs43BQrVMv++iSp4A1HnC/k3AlSynf9qSDCAJchpasoFqcai+aEjzWDhQU?= =?iso-8859-1?Q?hPN+K8aPCLqP5zjEwgdlLvos8/SmSBdTZy8n99T6BXm+LWsDacD6THQj8J?= =?iso-8859-1?Q?WoG6HDgPiuEYFK517JIAalsAh1R5FcY6mE4Wl8fp/GEAox08DF5tLiwdK6?= =?iso-8859-1?Q?Bzs/a5QfKWocsInGkA6n73u+RLFn44Iboti2L/0wu5XE9Z6WWisoA0D0Sx?= =?iso-8859-1?Q?ElsLX1eBy3lvXjXr0XFvyEAiCiDbVpLy0/2+jnKJiMSFDPuzMIwx+9Cs3S?= =?iso-8859-1?Q?N+/LODnf0xTFraJWlhvSLb6Ru0uT3EK9U88CEJUV0gT5yM2eMXguJlzWDm?= =?iso-8859-1?Q?0FHW6Wtmr70vIXOZWy6Tpjc8ubG9jVkk3ztjWqBAR18x/ckTlTJQSiTdH2?= =?iso-8859-1?Q?gr+hDhMff73vIwzeujVPb0OxJF+4gdvpox2C2TvkQMvosvOQMv3rpUieA8?= =?iso-8859-1?Q?jy4XQSv1LSI5KNaUfr0BKIyReZjneFDsxJboipL9Qf26iAsztbMtkkzeF7?= =?iso-8859-1?Q?YvVQHnTzst3QtM8NpRtB6t2gd26aX7k=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a179315-be2f-42b0-336e-08df18b77115 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 14:40:25.6195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vdXzhC8F//7U5LXIx+yjCxaklCzjAikf28LaDncvGHXzRGS06ac93CHQ9X0FelH6QC9OkXBHlNNPLZAll8sGodVs3oAKCf85jl6zo7fgX8w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11837 X-purgate-ID: tlsNG-16d1c6/1790088029-F4A044DB-78B794FC/0/0 X-purgate-type: clean X-purgate-size: 68942 This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A (TF-A) which provides SCMI interface with multi-agent support, as shown below. +-----------------------------------------+ | | | EL3 TF-A SCMI | +-------+--+-------+--+-------+--+-------++ |shmem1 | |shmem0 | |shmem2 | |shmemX | +-----+-+ +---+---+ +--+----+ +---+---+ smc-id1 | | | | agent1 | | | | +-----v--------+---------+-----------+----+ | | | | | | | | | | +--------------+---------+-----------+----+ smc-id0 | smc-id2| smc-idX| agent0 | agent2 | agentX | | | | +----v---+ +--v-----+ +--v-----+ | | | | | | | Dom0 | | Dom1 | | DomX | | | | | | | | | | | | | +--------+ +--------+ +--------+ The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared memory transport for every Agent in the system. The SCMI Agent transport channel defined by pair: - smc-id: SMC id used for Doorbell - shmem: shared memory for messages transfer, Xen page aligned. Shared memory is mapped with the following flags: MT_DEVICE_nGnRE. The follwoing SCMI Agents are expected to be defined by SCMI FW to enable S= CMI multi-agent functionality under Xen: - Xen management agent: trusted agents that accesses to the Base Protocol commands to configure agent specific permissions - OSPM VM agents: non-trusted agent, one for each Guest domain which is allowed direct HW access. At least one OSPM VM agent has to be provided by FW if HW is handled only by Dom0 or Driver Domain. The EL3 SCMI FW is expected to implement following Base protocol messages: - BASE_DISCOVER_AGENT (optional if agent_id was provided) - BASE_RESET_AGENT_CONFIGURATION (optional) - BASE_SET_DEVICE_PERMISSIONS (optional) The SCI SCMI SMC multi-agent driver implements following functionality: - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the ``arm,scmi-smc`` node that is a child of this container will bind to Xen; other SCMI nodes (for example under ``/firmware``) are ignored to avoid stealing the host OSPM instance. scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; #access-controller-cells =3D < 1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; - The driver obtains Xen specific SCMI Agent's configuration from the Host DT, probes Agents and builds SCMI Agents list. The Agents configuration is taken from "scmi-secondary-agents" property where first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and third is optional "agent_id": / { chosen { xen { ranges; xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; scmi-secondary-agents =3D < 0x82000002 &scmi_shm_0 0 0x82000004 &scmi_shm_2 2 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id #scmi-secondary-agents-cells =3D <3>; xen,dom0-sci-agent-id =3D <0>; scmi_shm_0: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; /* Xen SCMI management channel */ scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_shm_2: sram@47ff2000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff2000 0x0 0x1000>; }; scmi_shm_3: sram@47ff3000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff3000 0x0 0x1000>; }; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent func_id #address-cells =3D <1>; #size-cells =3D <0>; #access-controller-cells =3D <1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; }; }; }; }; / { /* * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI * enabled for it, ignored by Xen multi-agent mediator */ scmi_shm: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; firmware { scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem protocol@X{ }; }; }; }; This approach allows defining multiple SCMI Agents by adding Xen-specific properties under the ``/chosen`` node to the Host Device Tree, leaving the main part unchanged. The Host DT SCMI channel will be passed to Dom0. The Xen management agent is described as a ``scmi_xen`` node under the ``xen,sci`` comaptible node, which is used by Xen to control other SCMI Agents in the system. All secondary agents' configurations are provided in the ``scmi-secondary-agents`` property with an optional ``agent_id`` field. The ``agent_id`` from the ``scmi-secondary-agents`` property is used to identify the agent in the system and can be omitted by setting ``#scmi-secondary-agents-cells =3D <2>``, so the Secondary Agents configuration will look like this: / { chosen { xen { xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; /* Shared memory nodes as defined earlier */ scmi-secondary-agents =3D < 0x82000003 &scmi_shm_0 0x82000004 &scmi_shm_2 0x82000005 &scmi_shm_3 0x82000006 &scmi_shm_4>; #scmi-secondary-agents-cells =3D <2>; }; }; }; } In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to discover the ``agent_id`` for each secondary agent. Providing the ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping the discovery call, which is useful when the secondary agent's shared memory is not accessible by Xen or when boot time is important because it allows skipping the agent discovery procedure. Note that Xen is the only one entry in the system which need to know about SCMI multi-agent support. SMC ID Configuration and SCMI Connection Compatibility: The configuration allows the same device tree to work for both baremetal Linux and Linux Dom0. This is achieved because: - Baremetal Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 - Dom0 Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 - Xen management uses: func_id 0x82000003, scmi-shmem 0x47ff1000 This works because the privileged SCMI connection in EL3 firmware is not tied exclusively to func_id 0x82000002. The EL3 firmware supports multiple SCMI agents with different SMC IDs and shared memory regions. Each agent (Dom0 via 0x82000002, Xen via 0x82000003, other domains via additional func_ids) has an independent communication channel to the firmware. The key distinction is that Xen's management channel (0x82000003) is used for privileged operations like agent configuration and device permissions (BASE_SET_DEVICE_PERMISSIONS, BASE_RESET_AGENT_CONFIGURATION), while Dom0's channel (0x82000002) is used for standard SCMI protocol operations (power, clock, sensor management, etc.). The firmware enforces different permission levels for each agent based on their agent_id, not the SMC ID. Therefore, there is no conflict: Linux Dom0 retains its standard SCMI connection for hardware management, while Xen uses its separate privileged channel for mediating access between multiple domains. - It implements the SCI subsystem interface required for configuring and enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable SCMI functionality for domain it has to be configured with unique supported SCMI Agent_id and use corresponding SCMI SMC shared memory transport [smc-id, shmem] defined for this SCMI Agent_id. - Once Xen domain is configured it can communicate with EL3 SCMI FW: -- zero-copy, the guest domain puts SCMI message in shmem; -- the guest triggers SMC exception with smc-id (doorbell); -- the Xen driver catches exception, do checks and synchronously forwards it to EL3 FW. - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen management agent channel on domain destroy event. This allows to reset resources used by domain and so implement use-case like domain reboot. Dom0 Enable SCMI SMC: - set xen,dom0-sci-agent-id=3D under the xen,sci container in the Host DT. If the property is absent, SCMI is disabled for Dom0 and all SCMI nodes are removed from the Dom0 DT. The driver updates the Dom0 DT SCMI node "arm,smc-id" value and fixes up the shmem node according to the assigned agent_id. - pass dom0=3Dsci-agent-id=3D in Xen command line. if not provid= ed SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem node according to assigned agent_id. Guest domains enable SCMI SMC: - xl.cfg: add configuration option as below arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for the domain, for example: iomem =3D [ "47ff2,1@22001", ] - DT: add SCMI nodes to the Driver domain partial device tree as in the below example. The "arm,smc-id" should correspond assigned agent_id for the domain: passthrough { scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x22001000 0x0 0x1000>; }; firmware { compatible =3D "simple-bus"; scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000004>; shmem =3D <&scmi_shm_0>; ... } } } SCMI "4.2.1.1 Device specific access control" The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to. The DT SCMI node should "#access-controller-cells=3D<1>" property and DT devices should be bound to the Xen SCMI. &i2c1 { access-controllers =3D <&scmi 0>; }; The Dom0 and dom0less domains DT devices will be processed automatically through sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property shall be used: dtdev =3D [ "/soc/i2c@e6508000", ] xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU). Additionally, this patch adds documentation for the pre-existing scmi-smc-passthrough command line option, which was previously undocumented. [0] https://developer.arm.com/documentation/den0056 [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/access-controllers/access-controller= s.yaml Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- Changes in v13: - fix typo in commit description Changes in v12: - rebase to the latest staging - return EINVAL if xen,sci_type=3Dscmi_smc_multiagent was set but CONFIG_SCMI_SMC_MA not set - put arm_sci_agent_id after v8r_el1_msa and before pad to preserve order. Reduced pad from uint16_t to uint8_t to fill the gap (was 2 bytes before adding arm_sci_agent_id and left only 1, so used uint8_t to preserve structure size) - fix scmi_handle_call to use arm_smccc_guest_smc helper function - update send_smc_message function to use new format of arm_smccc_1_1_smc - guard the Dom0 SCMI agent id setup in create_dom0() and MA related funcitons with CONFIG_SCMI_SMC_MA - fix the xen_scmi_config example in booting.txt, which placed properties after subnodes and was rejected by dtc with "Properties must precede subnodes" Changes in v10: - Fix tabs in MAINTAINERS file - remove duplicate SPDX tag from scmi-shmem.c - add cast to ARM_SMCCC_INVALID_PARAMETER to settle the sign since ARM_SMCCC_INVALID_PARAMETER is -3 which is part of the spec and resp is the default smccc call structure. - update free_channel_list. Add spinlock to avoid race condition and a comment with a description of the function work - preserve error of smc_create_channel in scmi_probe - check scmi shmem address alignment as wel as it is done for size - check for d->arch.sci_data !=3D NULL in scmi_handle_call - use SCMI_SHMEM_MAPPED size for iomem_permit_access - change len type to unsigned in shmem_{get|put}_message - rename shmem_channel_is_free to shmem_channel_status - add comment about skipping message status when getting message response - Set correct agent_id ranges for dom0less and a toolstack. Agent_id 0 is not binded for dom0 so can be reused. Also mentioned that UINT8_MAX (255) is treated as invalid agent_id. - Split hypervisor and toolstack changes into separate commits - move init list and spin init after initial checks in probe call - fix typo in comments - clean resources when sci_register returns an error. Changes in v9: - sort and refactor MAINTAINERS enties - remove Spurious changes - add extra check to avoid ASSERT when calling unmap_channel_memory from assign device method - set correct tx flag to SCMI_BASE_AGENT_PERMISSIONS_RESET when freeing resources. Flag should be set to 1 according to the section 4.2.2.12 [0]. - fix dt node copmaring - moved channel->shmem check from ASSERT in unmap_memory_channel to "if" statement. This will prevent firing ASSERT if unmap_channel_memory was called twice on the same channel. Changes in v8: - update xen_scmi func_id in commit description - updated documentation with the new DT format - updated opt_dom0_scmi_agent_id setting to avoid it to be equal SCMI_AGENT_ID_INVALID. - changed SCMI_AGENT_ID_INVALID from 0xff to UINT8_MAX which makes code more clear showing that UINT8_MAX is theated like invalid agent_id and couldn't be used. Also excluded SCMI_AGENT_ID_INVALID from acceptable value range - remove outdated xen,config property ignore, added xen,sci compatible to skip_matches in handle_node - add documentation for pre-existing scmi-smc-passthrough command line option in alphabetically correct location (in 's' section) - add note to commit description about documentation for previously undocumented scmi-smc-passthrough - Fix SMC IDs in DT examples (Xen management uses 0x82000003, Dom0 uses 0x8= 2000002) - Add explicit note explaining why Dom0 and Xen channels do not conflict - Document dom0less multi-agent configuration example (xen,sci_type / xen,s= ci-agent-id) - Add scmi_xen node to agent-discovery example with #scmi-secondary-agents-= cells =3D 2 - Drop dom0=3Dsci-agent-id command line handling; Dom0 SCMI is now enabled = via xen,dom0-sci-agent-id in the xen,sci DT container - Refresh docs and examples to mention the DT property instead of the cmdli= ne option Changes in v7: - rework scmi nodes for xen to match on compatible string instead of the direct path Changes in v6: - updated scmi-shmem to use io.h from generic location - update scmi_agent_id parameter to be provided inside dom0=3D parameter list and have the following format "dom0=3Dsci-agent-id=3D0" This change was done as a response for Stefano comment and requires a lot of code changes, but produces much cleaner solution that's why I've added it to the code. - fix file comments and return codes - fix lenght checks in shmem_{get,put}_message to use offsetof - remove len member from scmi_channel structure as it is not used - set scmi-secondary-agents property to be mandatory since if no secondary agents were provided then there is no sence to enable scmi when no secondary agents are populated to the Domains - update documentation in booting.txt, added xen_scmi node to the example - adjust d->arch.sci_enabled value in scmi_domain_destroy - fix lock management in smc_create_channel call - avoid extra map_channel_memory command for Xen management channel because collect_agent_id call unmaps memory if DOMID_XEN is not set. So for Xen management channel we can init domain_id ad DOMID_XEN before calling collect_agent_id so memory shouldn't be unmapped. Changes in v5: - fix device-tree example format in booting.txt, added ";" after "}". - update define in scmi-proto.h - update define in scmi-shmem.h file - scmi_assign_device - do not ignore -EOPNOTSUPP return code of the do_smc_xfer - remove overwriting agent_channel->agent_id after SCMI_BASE_DISCOVER_AGENT call - add multi-agent files to the MAINTAINERS - add SCMI multi-agent description to the SUPPORT.md - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL for smc call - updated collect_agents function. Set agent_id parameter as optional in scmi-secondary-agents device-tree property - introduce "#scmi-secondary-agents-cells" parameter to set if agent_id was provided - reanme xen,scmi-secondary-agents property to scmi-secondary-agents - move memcpu_toio/fromio for the generic place - update Xen to get management channel from /chosen/xen,config node - get hypervisor channnel from node instead of using hardcoded - update handling scmi and shmem nodes for the domain - Set multi-agent driver to support only Arm64 Changes in v4: - toolstack comments from Anthony PERARD - added dom0less support - added doc for "xen,scmi-secondary-agents" MAINTAINERS | 1 + SUPPORT.md | 11 + docs/misc/arm/device-tree/booting.txt | 197 +++++ xen/arch/arm/dom0less-build.c | 17 + xen/arch/arm/domain_build.c | 43 ++ xen/arch/arm/firmware/Kconfig | 12 + xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/scmi-proto.h | 164 ++++ xen/arch/arm/firmware/scmi-shmem.c | 118 +++ xen/arch/arm/firmware/scmi-shmem.h | 45 ++ xen/arch/arm/firmware/scmi-smc-multiagent.c | 816 ++++++++++++++++++++ xen/include/public/arch-arm.h | 5 +- 12 files changed, 1429 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/firmware/scmi-proto.h create mode 100644 xen/arch/arm/firmware/scmi-shmem.c create mode 100644 xen/arch/arm/firmware/scmi-shmem.h create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c diff --git a/MAINTAINERS b/MAINTAINERS index c60afc93a5..cd6d1243bd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -534,6 +534,7 @@ SCI MEDIATORS R: Oleksii Moisieiev S: Supported F: xen/arch/arm/firmware/sci.c +F: xen/arch/arm/firmware/scmi-*.[ch] F: xen/arch/arm/include/asm/firmware/sci.h =20 SEABIOS UPSTREAM diff --git a/SUPPORT.md b/SUPPORT.md index eb07332462..dc41a6b2f3 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -972,6 +972,17 @@ by hwdom. Some platforms use SCMI for access to system= -level resources. =20 Status: Supported =20 +### Arm: SCMI SMC multi-agent support + +Enable support for the multi-agent configuration of the EL3 Firmware, whic= h +allows Xen to provide an SCMI interface to the Domains. +Xen manages access permissions to the HW resources and provides an SCMI in= terface +to the Domains. Each Domain is represented as a separate Agent, which can +communicate with EL3 Firmware using a dedicated shared memory region, and +notifications are passed through by Xen. + + Status, ARM64: Tech Preview + ### ARM: Guest PSCI support =20 Emulated PSCI interface exposed to guests. We support all mandatory diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t= ree/booting.txt index bcb06bc796..1d0382a865 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -331,6 +331,21 @@ with the following properties: Should be used together with scmi-smc-passthrough Xen command line option. =20 + - "scmi_smc_multiagent" + + Enables ARM SCMI SMC multi-agent support for the guest by enabling SCM= I over + SMC calls forwarding from domain to the EL3 firmware (like ARM + Trusted Firmware-A) with a multi SCMI OSPM agent support. + The SCMI agent_id should be specified for the guest with "xen,sci-agen= t-id" + property. + +- "xen,sci-agent-id" + + Specifies ARM SCMI agent id for the guest. This option is mandatory if= the + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The a= gent ids + of guest must be unique and in the range [0..254]. UINT8_MAX (255) is + treated as invalid. + - v8r_el1_msa =20 A string property specifying whether, on Armv8-R systems at EL1, a dom= ain @@ -847,3 +862,185 @@ The automatically allocated static shared memory will= get mapped at 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in Dom= U2 guest physical address space. DomU1 is explicitly defined as the owner dom= ain, and DomU2 is the borrower domain. + +SCMI SMC multi-agent support +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D + +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_= SMC_MA) +the Xen specific SCMI Agent's configuration shall be provided in the Host = DT +according to the SCMI compliant EL3 Firmware specification with ARM SMC/HV= C +transport. The SCMI configuration must live under the Xen SCMI container +"xen,sci" beneath "/chosen" (for example "/chosen/xen/xen_scmi_config/scmi= "). The +Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is a chil= d of +this "xen,sci" container; any other "arm,scmi-smc" nodes (for example unde= r +"/firmware") are ignored to avoid stealing the host's SCMI OSPM instance. + +- scmi-secondary-agents + + Defines a set of SCMI agents configuration supported by SCMI EL3 FW an= d + available for Xen. Each Agent defined as triple consisting of: + SMC/HVC function_id assigned for the agent transport ("arm,smc-id"), + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem"= ), + SCMI agent_id (optional) if not set - Xen will determine Agent ID for + each provided channel using BASE_DISCOVER_AGENT message. + +- xen,dom0-sci-agent-id + + Optional. Specifies the Dom0/hwdom SCMI agent_id inside the ``xen,sci`= ` + container. When provided, Dom0 will be configured for SCMI multi-agent + support; when omitted, SCMI remains disabled for Dom0. The value must + match the ``func_id`` and shmem pairing that EL3 firmware exposes for + Dom0 (for example via ``/firmware/scmi``). + +As an example: + +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + xen,dom0-sci-agent-id =3D <0>; <--- dom0 agent id + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_= id + #scmi-secondary-agents-cells =3D <3>; + + scmi_shm_0: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + /* Xen SCMI management channel */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; + }; + }; +}; + +Note: This example keeps the Host DT unchanged for Dom0 and baremetal Linu= x +by using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a +separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 +firmware enforces permissions per agent_id, so there is no conflict betwee= n +Dom0 and Xen channels. + +- #scmi-secondary-agents-cells + + Defines whether Agent_id is set in the "scmi-secondary-agents" propert= y. + Possible values are: 2, 3. + When set to 3 (the default), expect agent_id to be present in the seco= ndary + agents list. + When set to 2, agent_id will be discovered for each channel using + BASE_DISCOVER_AGENT message. + + +Example: + +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Shared memory nodes as in the previous example */ + + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; + }; + }; +}; + +Dom0less example (multi-agent) +------------------------------- + +Below is a minimal dom0less configuration showing how to enable SCMI SMC +multi-agent for a pre-defined guest domain using xen,sci_type and +xen,sci-agent-id, together with the Xen SCMI container: + +chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Xen management channel shared memory */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_domu: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000004 &scmi_shm_domu 2>; + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; + }; + }; + }; + + xen,domain@1 { + compatible =3D "xen,domain"; + xen,sci_type =3D "scmi_smc_multiagent"; + xen,sci-agent-id =3D <2>; + /* Additional domain properties (memory, cpus, kernels, etc.) */ + }; +}; diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 3f48f74226..50e2516b9e 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -292,6 +292,23 @@ static int __init domu_dt_sci_parse(struct dt_device_n= ode *node, =20 d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; } + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) + { + uint32_t agent_id =3D 0; + + if ( !IS_ENABLED(CONFIG_SCMI_SMC_MA) ) + { + printk(XENLOG_ERR "xen,sci_type=3Dscmi_smc_multiagent requeste= d, but CONFIG_SCMI_SMC_MA not set\n"); + return -EINVAL; + } + + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || + agent_id >=3D UINT8_MAX ) + return -EINVAL; + + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA= ; + d_cfg->arch.arm_sci_agent_id =3D agent_id; + } else { printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"= , diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 72d5316180..297c46d5a2 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -87,6 +87,39 @@ int __init parse_arch_dom0_param(const char *s, const ch= ar *e) return -EINVAL; } =20 +#ifdef CONFIG_SCMI_SMC_MA +/* SCMI agent ID for dom0 obtained from xen,sci container */ +#define SCMI_AGENT_ID_INVALID UINT8_MAX + +static uint8_t __init get_dom0_scmi_agent_id(void) +{ + const struct dt_device_node *config_node; + u32 val; + const struct dt_property *prop; + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + return SCMI_AGENT_ID_INVALID; + + prop =3D dt_find_property(config_node, "xen,dom0-sci-agent-id", NULL); + if ( !prop ) + return SCMI_AGENT_ID_INVALID; + + if ( !dt_property_read_u32(config_node, "xen,dom0-sci-agent-id", &val)= ) + return SCMI_AGENT_ID_INVALID; + + if ( val >=3D SCMI_AGENT_ID_INVALID ) + { + printk(XENLOG_WARNING + "Invalid xen,dom0-sci-agent-id=3D%u, SCMI disabled for Dom0\n= ", + val); + return SCMI_AGENT_ID_INVALID; + } + + return val; +} +#endif /* CONFIG_SCMI_SMC_MA */ + /* Override macros from asm/page.h to make them work with mfn_t */ #undef virt_to_mfn #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) @@ -1479,6 +1512,7 @@ static int __init handle_node(struct domain *d, struc= t kernel_info *kinfo, DT_MATCH_TYPE("memory"), /* The memory mapped timer is not supported by Xen. */ DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"), + DT_MATCH_COMPATIBLE("xen,sci"), { /* sentinel */ }, }; static const struct dt_device_match timer_matches[] __initconst =3D @@ -1965,6 +1999,15 @@ void __init create_dom0(void) dom0_cfg.arch.tee_type =3D tee_get_type(); dom0_cfg.max_vcpus =3D dom0_max_vcpus(); =20 +#ifdef CONFIG_SCMI_SMC_MA + /* Set up SCMI agent ID if provided in the xen,sci container */ + dom0_cfg.arch.arm_sci_agent_id =3D get_dom0_scmi_agent_id(); + dom0_cfg.arch.arm_sci_type =3D (dom0_cfg.arch.arm_sci_agent_id !=3D + SCMI_AGENT_ID_INVALID) ? + XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA : + XEN_DOMCTL_CONFIG_ARM_SCI_NONE; +#endif + if ( iommu_enabled ) dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu; =20 diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index 5c5f0880c4..972cd9b173 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -29,6 +29,18 @@ config SCMI_SMC driver domain. Use with EL3 firmware which supports only single SCMI OSPM agent. =20 +config SCMI_SMC_MA + bool "Enable ARM SCMI SMC multi-agent driver" + depends on ARM_64 + select ARM_SCI + help + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Doma= ins + to EL3 firmware (TF-A) which supports multi-agent feature. + This feature allows to enable SCMI per Domain using unique SCMI agent_i= d, + so Domain is identified by EL3 firmware as an SCMI Agent and can access + allowed platform resources through dedicated SMC/HVC Shared memory base= d + transport. + endchoice =20 endmenu diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil= e index 71bdefc24a..37927e690e 100644 --- a/xen/arch/arm/firmware/Makefile +++ b/xen/arch/arm/firmware/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_ARM_SCI) +=3D sci.o obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o +obj-$(CONFIG_SCMI_SMC_MA) +=3D scmi-shmem.o scmi-smc-multiagent.o diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scm= i-proto.h new file mode 100644 index 0000000000..49f63cfc0a --- /dev/null +++ b/xen/arch/arm/firmware/scmi-proto.h @@ -0,0 +1,164 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * + * Copyright (c) 2025 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_PROTO_H_ +#define ARM_FIRMWARE_SCMI_PROTO_H_ + +#include + +#define SCMI_SHORT_NAME_MAX_SIZE 16 + +/* SCMI status codes. See section 4.1.4 */ +#define SCMI_SUCCESS 0 +#define SCMI_NOT_SUPPORTED (-1) +#define SCMI_INVALID_PARAMETERS (-2) +#define SCMI_DENIED (-3) +#define SCMI_NOT_FOUND (-4) +#define SCMI_OUT_OF_RANGE (-5) +#define SCMI_BUSY (-6) +#define SCMI_COMMS_ERROR (-7) +#define SCMI_GENERIC_ERROR (-8) +#define SCMI_HARDWARE_ERROR (-9) +#define SCMI_PROTOCOL_ERROR (-10) + +/* Protocol IDs */ +#define SCMI_BASE_PROTOCOL 0x10 + +/* Base protocol message IDs */ +#define SCMI_BASE_PROTOCOL_VERSION 0x0 +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 +#define SCMI_BASE_DISCOVER_AGENT 0x7 +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB + +typedef struct scmi_msg_header { + uint8_t id; + uint8_t type; + uint8_t protocol; + uint32_t status; +} scmi_msg_header_t; + +/* Table 2 Message header format */ +#define SCMI_HDR_ID GENMASK(7, 0) +#define SCMI_HDR_TYPE GENMASK(9, 8) +#define SCMI_HDR_PROTO GENMASK(17, 10) + +#define SCMI_FIELD_GET(_mask, _reg) = \ + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) +#define SCMI_FIELD_PREP(_mask, _val) = \ + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) + +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) +{ + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); +} + +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t = *hdr) +{ + hdr->id =3D SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); + hdr->type =3D SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); + hdr->protocol =3D SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); +} + +static inline int scmi_to_xen_errno(int scmi_status) +{ + if ( scmi_status =3D=3D SCMI_SUCCESS ) + return 0; + + switch ( scmi_status ) + { + case SCMI_NOT_SUPPORTED: + return -EOPNOTSUPP; + case SCMI_INVALID_PARAMETERS: + return -EINVAL; + case SCMI_DENIED: + return -EACCES; + case SCMI_NOT_FOUND: + return -ENOENT; + case SCMI_OUT_OF_RANGE: + return -ERANGE; + case SCMI_BUSY: + return -EBUSY; + case SCMI_COMMS_ERROR: + return -ENOTCONN; + case SCMI_GENERIC_ERROR: + return -EIO; + case SCMI_HARDWARE_ERROR: + return -ENXIO; + case SCMI_PROTOCOL_ERROR: + return -EBADMSG; + default: + return -EINVAL; + } +} + +/* PROTOCOL_VERSION */ +#define SCMI_VERSION_MINOR GENMASK(15, 0) +#define SCMI_VERSION_MAJOR GENMASK(31, 16) + +struct scmi_msg_prot_version_p2a { + uint32_t version; +} __packed; + +/* BASE PROTOCOL_ATTRIBUTES */ +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) + +struct scmi_msg_base_attributes_p2a { + uint32_t attributes; +} __packed; + +/* + * BASE_DISCOVER_AGENT + */ +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF + +struct scmi_msg_base_discover_agent_a2p { + uint32_t agent_id; +} __packed; + +struct scmi_msg_base_discover_agent_p2a { + uint32_t agent_id; + char name[SCMI_SHORT_NAME_MAX_SIZE]; +} __packed; + +/* + * BASE_SET_DEVICE_PERMISSIONS + */ +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) + +struct scmi_msg_base_set_device_permissions_a2p { + uint32_t agent_id; + uint32_t device_id; + uint32_t flags; +} __packed; + +/* + * BASE_RESET_AGENT_CONFIGURATION + */ +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) + +struct scmi_msg_base_reset_agent_cfg_a2p { + uint32_t agent_id; + uint32_t flags; +} __packed; + +#endif /* ARM_FIRMWARE_SCMI_PROTO_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scm= i-shmem.c new file mode 100644 index 0000000000..e36745a85e --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.c @@ -0,0 +1,118 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SMC/HVC shmem transport implementation used by + * SCI SCMI multi-agent driver. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +static inline int +shmem_channel_status(const volatile struct scmi_shared_mem __iomem *shmem) +{ + return (readl(&shmem->channel_status) & + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; +} + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, unsigned int len= ) +{ + int ret; + + if ( (len + offsetof(struct scmi_shared_mem, msg_payload)) > + SCMI_SHMEM_MAPPED_SIZE ) + { + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invali= d\n"); + return -EINVAL; + } + + ret =3D shmem_channel_status(shmem); + if ( ret ) + return ret; + + writel_relaxed(0x0, &shmem->channel_status); + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set */ + writel_relaxed(0x0, &shmem->flags); + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); + writel(pack_scmi_header(hdr), &shmem->msg_header); + + if ( len > 0 && data ) + memcpy_toio(shmem->msg_payload, data, len); + + return 0; +} + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, unsigned int le= n) +{ + int recv_len; + int ret; + /* + * First word of msg_payload carries the returned status; exclude it f= rom + * recv_len so only the protocol payload is copied back to the caller. + */ + int pad =3D sizeof(hdr->status); + + if ( len >=3D SCMI_SHMEM_MAPPED_SIZE - + offsetof(struct scmi_shared_mem, msg_payload) ) + { + printk(XENLOG_ERR + "scmi: Wrong size of input smc message. Data may be invalid= \n"); + return -EINVAL; + } + + ret =3D shmem_channel_status(shmem); + if ( ret ) + return ret; + + recv_len =3D readl(&shmem->length) - sizeof(shmem->msg_header); + + if ( recv_len < 0 ) + { + printk(XENLOG_ERR + "scmi: Wrong size of smc message. Data may be invalid\n"); + return -EINVAL; + } + + unpack_scmi_header(readl(&shmem->msg_header), hdr); + + hdr->status =3D readl(&shmem->msg_payload); + recv_len =3D recv_len > pad ? recv_len - pad : 0; + + ret =3D scmi_to_xen_errno(hdr->status); + if ( ret ) + { + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); + return ret; + } + + if ( recv_len > len ) + { + printk(XENLOG_ERR + "scmi: Not enough buffer for message %d, expecting %d\n", + recv_len, len); + return -EINVAL; + } + + if ( recv_len > 0 ) + memcpy_fromio(data, shmem->msg_payload + pad, recv_len); + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.h b/xen/arch/arm/firmware/scm= i-shmem.h new file mode 100644 index 0000000000..722263aa77 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.h @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * Shared Memory based Transport + * + * Copyright (c) 2024 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_SHMEM_H_ +#define ARM_FIRMWARE_SCMI_SHMEM_H_ + +#include + +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) + +struct scmi_shared_mem { + uint32_t reserved; + uint32_t channel_status; + uint32_t reserved1[2]; + uint32_t flags; + uint32_t length; + uint32_t msg_header; + uint8_t msg_payload[]; +}; + +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, unsigned int len= ); + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, unsigned int le= n); +#endif /* ARM_FIRMWARE_SCMI_SHMEM_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/fir= mware/scmi-smc-multiagent.c new file mode 100644 index 0000000000..0c5653fbc0 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c @@ -0,0 +1,816 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +#define SCMI_SECONDARY_AGENTS "scmi-secondary-agents" + +struct scmi_channel { + uint32_t agent_id; + uint32_t func_id; + domid_t domain_id; + uint64_t paddr; + struct scmi_shared_mem __iomem *shmem; + spinlock_t lock; + struct list_head list; +}; + +struct scmi_data { + struct list_head channel_list; + spinlock_t channel_list_lock; + uint32_t func_id; + bool initialized; + uint32_t shmem_phandle; + uint32_t hyp_channel_agent_id; + struct dt_device_node *dt_dev; +}; + +static struct scmi_data scmi_data; + +static bool scmi_is_under_xen_sci(const struct dt_device_node *node) +{ + const struct dt_device_node *p; + + for ( p =3D node->parent; p; p =3D p->parent ) + if ( dt_device_is_compatible(p, "xen,sci") ) + return true; + + return false; +} + +static int send_smc_message(struct scmi_channel *chan_info, + scmi_msg_header_t *hdr, void *data, int len) +{ + struct arm_smccc_res resp; + int ret; + + ret =3D shmem_put_message(chan_info->shmem, hdr, data, len); + if ( ret ) + return ret; + + resp =3D arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0); + + if ( resp.a0 =3D=3D (unsigned long)ARM_SMCCC_INVALID_PARAMETER ) + return -EINVAL; + + if ( resp.a0 ) + return -EOPNOTSUPP; + + return 0; +} + +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t *= hdr, + void *tx_data, int tx_size, void *rx_data, int rx_s= ize) +{ + int ret =3D 0; + + ASSERT(chan_info && chan_info->shmem); + + if ( !hdr ) + return -EINVAL; + + spin_lock(&chan_info->lock); + + printk(XENLOG_DEBUG + "scmi: agent_id =3D %d msg_id =3D %x type =3D %d, proto =3D %x\= n", + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); + + ret =3D send_smc_message(chan_info, hdr, tx_data, tx_size); + if ( ret ) + goto clean; + + ret =3D shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size); + +clean: + printk(XENLOG_DEBUG + "scmi: get smc response agent_id =3D %d msg_id =3D %x proto =3D= %x res=3D%d\n", + chan_info->agent_id, hdr->id, hdr->protocol, ret); + + spin_unlock(&chan_info->lock); + + return ret; +} + +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) +{ + struct scmi_channel *curr; + bool found =3D false; + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + found =3D true; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + if ( found ) + return curr; + + return NULL; +} + +static struct scmi_channel *acquire_scmi_channel(struct domain *d, + uint32_t agent_id) +{ + struct scmi_channel *curr; + struct scmi_channel *ret =3D ERR_PTR(-ENOENT); + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + if ( curr->domain_id !=3D DOMID_INVALID ) + { + ret =3D ERR_PTR(-EEXIST); + break; + } + + curr->domain_id =3D d->domain_id; + ret =3D curr; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + + return ret; +} + +static void relinquish_scmi_channel(struct scmi_channel *channel) +{ + ASSERT(channel !=3D NULL); + + spin_lock(&scmi_data.channel_list_lock); + channel->domain_id =3D DOMID_INVALID; + spin_unlock(&scmi_data.channel_list_lock); +} + +static int map_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel && channel->paddr); + channel->shmem =3D ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_S= IZE); + if ( !channel->shmem ) + return -ENOMEM; + + channel->shmem->channel_status =3D SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE; + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->pa= ddr, + channel->shmem); + + return 0; +} + +static void unmap_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel); + + if ( !channel->shmem ) + return; + + iounmap(channel->shmem); + channel->shmem =3D NULL; +} + +static struct scmi_channel *smc_create_channel(uint32_t agent_id, + uint32_t func_id, uint64_t = addr) +{ + struct scmi_channel *channel, *curr; + + spin_lock(&scmi_data.channel_list_lock); + + /* Check if channel already exists while holding the lock */ + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-EEXIST); + } + } + + channel =3D xmalloc(struct scmi_channel); + if ( !channel ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-ENOMEM); + } + + spin_lock_init(&channel->lock); + channel->agent_id =3D agent_id; + channel->func_id =3D func_id; + channel->domain_id =3D DOMID_INVALID; + channel->shmem =3D NULL; + channel->paddr =3D addr; + list_add_tail(&channel->list, &scmi_data.channel_list); + + spin_unlock(&scmi_data.channel_list_lock); + return channel; +} + +static void free_channel_list(void) +{ + struct scmi_channel *curr, *_curr; + /* + * Called only on the __init error path, before any runtime users exis= t, + * so no other thread is iterating channel_list. Keep the lock for the + * whole drain for clarity and to avoid misleading readers about possi= ble + * concurrent access. + */ + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list) + { + list_del(&curr->list); + xfree(curr); + } + spin_unlock(&scmi_data.channel_list_lock); +} + +static int __init +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr, + u64 *size) +{ + struct dt_device_node *shmem_node; + const __be32 *prop; + + prop =3D dt_get_property(scmi_node, "shmem", NULL); + if ( !prop ) + return -EINVAL; + + shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop)); + if ( IS_ERR_OR_NULL(shmem_node) ) + { + printk(XENLOG_ERR + "scmi: Device tree error, can't parse reserved memory %ld\n= ", + PTR_ERR(shmem_node)); + return PTR_ERR(shmem_node); + } + + return dt_device_get_address(shmem_node, 0, addr, size); +} + +/* + * Handle Dom0 SCMI specific DT nodes + * + * Make a decision on copying SCMI specific nodes into Dom0 device tree. + * For SCMI multi-agent case: + * - shmem nodes will not be copied and generated instead if SCMI + * is enabled for Dom0 + * - scmi node will be copied if SCMI is enabled for Dom0 + */ +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *n= ode) +{ + static const struct dt_device_match shmem_matches[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-shmem"), + { /* sentinel */ }, + }; + static const struct dt_device_match scmi_matches[] __initconst =3D { + DT_MATCH_PATH("/firmware/scmi"), + { /* sentinel */ }, + }; + + if ( !scmi_data.initialized ) + return false; + + /* skip scmi shmem node for dom0 if scmi not enabled */ + if ( dt_match_node(shmem_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk(" Skip scmi shmem node\n"); + return true; + } + + /* drop scmi if not enabled */ + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk(" Skip scmi node\n"); + return true; + } + + return false; +} + +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, + uint32_t flags) +{ + struct scmi_msg_base_set_device_permissions_a2p tx; + struct scmi_channel *channel; + scmi_msg_header_t hdr; + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + return -EINVAL; + + hdr.id =3D SCMI_BASE_SET_DEVICE_PERMISSIONS; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.agent_id =3D agent_id; + tx.device_id =3D device_id; + tx.flags =3D flags; + + return do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); +} + +static int scmi_dt_assign_device(struct domain *d, + struct dt_phandle_args *ac_spec) +{ + struct scmi_channel *agent_channel; + uint32_t scmi_device_id =3D ac_spec->args[0]; + int ret; + + if ( !d->arch.sci_data ) + return 0; + + /* The access-controllers is specified for DT dev, but it's not a SCMI= */ + if ( !scmi_data.dt_dev || + !dt_node_path_is_equal(ac_spec->np, scmi_data.dt_dev->full_name) = ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + + ret =3D scmi_assign_device(agent_channel->agent_id, scmi_device_id, + SCMI_BASE_DEVICE_ACCESS_ALLOW); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)= ", + d, agent_channel->agent_id, scmi_device_id, ret); + } + + spin_unlock(&agent_channel->lock); + return ret; +} + +static int collect_agent_id(struct scmi_channel *agent_channel) +{ + int ret; + scmi_msg_header_t hdr; + struct scmi_msg_base_discover_agent_p2a da_rx; + struct scmi_msg_base_discover_agent_a2p da_tx; + + ret =3D map_channel_memory(agent_channel); + if ( ret ) + return ret; + + hdr.id =3D SCMI_BASE_DISCOVER_AGENT; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + da_tx.agent_id =3D agent_channel->agent_id; + + ret =3D do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx= , + sizeof(da_rx)); + if ( agent_channel->domain_id !=3D DOMID_XEN ) + unmap_channel_memory(agent_channel); + if ( ret ) + return ret; + + printk(XENLOG_DEBUG "id=3D0x%x name=3D%s\n", da_rx.agent_id, da_rx.nam= e); + agent_channel->agent_id =3D da_rx.agent_id; + return 0; +} + +static __init int collect_agents(struct dt_device_node *scmi_node) +{ + const struct dt_device_node *config_node; + const __be32 *prop; + uint32_t len; + const __be32 *end; + uint32_t cells_per_entry =3D 3; /* Default to 3 cells if property is a= bsent. */ + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + { + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to = collect.\n"); + return -ENOENT; + } + + /* Check for the optional '#scmi-secondary-agents-cells' property. */ + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", + &cells_per_entry) ) + { + if ( cells_per_entry !=3D 2 && cells_per_entry !=3D 3 ) + { + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells = value: %u\n", + cells_per_entry); + return -EINVAL; + } + } + + prop =3D dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); + if ( !prop ) + { + printk(XENLOG_ERR "scmi: No %s property found, no agents to collec= t.\n", + SCMI_SECONDARY_AGENTS); + return -EINVAL; + } + + /* Validate that the property length is a multiple of the cell size. *= / + if ( len =3D=3D 0 || len % (cells_per_entry * sizeof(uint32_t)) !=3D 0= ) + { + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u = cells per entry\n", + SCMI_SECONDARY_AGENTS, len, cells_per_entry); + return -EINVAL; + } + + end =3D (const __be32 *)((const u8 *)prop + len); + + for ( ; prop < end; ) + { + uint32_t agent_id; + uint32_t smc_id; + uint32_t shmem_phandle; + struct dt_device_node *node; + u64 addr, size; + int ret; + struct scmi_channel *agent_channel; + + smc_id =3D be32_to_cpu(*prop++); + shmem_phandle =3D be32_to_cpu(*prop++); + + if ( cells_per_entry =3D=3D 3 ) + agent_id =3D be32_to_cpu(*prop++); + else + agent_id =3D SCMI_BASE_AGENT_ID_OWN; + + node =3D dt_find_node_by_phandle(shmem_phandle); + if ( !node ) + { + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %= u\n", + agent_id); + return -EINVAL; + } + + ret =3D dt_device_get_address(node, 0, &addr, &size); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: Could not read shmem address for agent %u: %d\n"= , + agent_id, ret); + return ret; + } + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) || + !IS_ALIGNED(addr, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + agent_channel =3D smc_create_channel(agent_id, smc_id, addr); + if ( IS_ERR(agent_channel) ) + { + printk(XENLOG_ERR "scmi: Could not create channel for agent %u= : %ld\n", + agent_id, PTR_ERR(agent_channel)); + return PTR_ERR(agent_channel); + } + + if ( cells_per_entry =3D=3D 2 ) + { + ret =3D collect_agent_id(agent_channel); + if ( ret ) + return ret; + } + + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_chan= nel->agent_id, + smc_id, (unsigned long)addr); + } + + return 0; +} + +static int scmi_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) +{ + struct scmi_channel *channel; + int ret; + + if ( !scmi_data.initialized ) + return 0; + + /* + * SCMI support is configured via: + * - For dom0: xen,dom0-sci-agent-id property under the xen,sci contai= ner + * - For dom0less: xen,sci-agent-id in the domain node + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id + * are already set by domain_build.c or dom0less-build.c + */ + + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) + return 0; + + channel =3D acquire_scmi_channel(d, config->arch.arm_sci_agent_id); + if ( IS_ERR(channel) ) + { + printk(XENLOG_ERR + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\= n", + config->arch.arm_sci_agent_id, PTR_ERR(channel)); + return PTR_ERR(channel); + } + + printk(XENLOG_INFO + "scmi: Acquire channel id =3D 0x%x, domain_id =3D %d paddr =3D = 0x%lx\n", + channel->agent_id, channel->domain_id, channel->paddr); + + /* + * Dom0 (if present) needs to have an access to the guest memory range + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permi= ssion + * domctl. + */ + if ( hardware_domain && !is_hardware_domain(d) ) + { + ret =3D iomem_permit_access(hardware_domain, paddr_to_pfn(channel-= >paddr), + paddr_to_pfn(channel->paddr + + SCMI_SHMEM_MAPPED_SIZE - 1)); + if ( ret ) + goto error; + } + + d->arch.sci_data =3D channel; + d->arch.sci_enabled =3D true; + + return 0; + +error: + relinquish_scmi_channel(channel); + return ret; +} + +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE && + config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC= _MA ) + { + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); + return -EINVAL; + } + + return 0; +} + +static int scmi_relinquish_resources(struct domain *d) +{ + int ret; + struct scmi_channel *channel, *agent_channel; + scmi_msg_header_t hdr; + struct scmi_msg_base_reset_agent_cfg_a2p tx; + + if ( !d->arch.sci_data ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + tx.agent_id =3D agent_channel->agent_id; + spin_unlock(&agent_channel->lock); + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + { + printk(XENLOG_ERR + "scmi: Unable to get Hypervisor scmi channel for domain %d\= n", + d->domain_id); + return -EINVAL; + } + + hdr.id =3D SCMI_BASE_RESET_AGENT_CONFIGURATION; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.flags =3D SCMI_BASE_AGENT_PERMISSIONS_RESET; + + ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); + if ( ret =3D=3D -EOPNOTSUPP ) + return 0; + + return ret; +} + +static void scmi_domain_destroy(struct domain *d) +{ + struct scmi_channel *channel; + + if ( !d->arch.sci_data ) + return; + + channel =3D d->arch.sci_data; + spin_lock(&channel->lock); + + relinquish_scmi_channel(channel); + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); + + d->arch.sci_data =3D NULL; + d->arch.sci_enabled =3D false; + + spin_unlock(&channel->lock); +} + +static bool scmi_handle_call(struct cpu_user_regs *regs) +{ + uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); + struct scmi_channel *agent_channel; + struct domain *d =3D current->domain; + bool res =3D false; + + if ( (!sci_domain_is_enabled(d)) || (!d->arch.sci_data) ) + return false; + + agent_channel =3D d->arch.sci_data; + spin_lock(&agent_channel->lock); + + if ( agent_channel->func_id !=3D fid ) + { + res =3D false; + goto unlock; + } + + arm_smccc_guest_smc(regs); + res =3D true; +unlock: + spin_unlock(&agent_channel->lock); + + return res; +} + +static const struct sci_mediator_ops scmi_ops =3D { + .domain_init =3D scmi_domain_init, + .domain_destroy =3D scmi_domain_destroy, + .relinquish_resources =3D scmi_relinquish_resources, + .handle_call =3D scmi_handle_call, + .dom0_dt_handle_node =3D scmi_dt_handle_node, + .domain_sanitise_config =3D scmi_domain_sanitise_config, + .assign_dt_device =3D scmi_dt_assign_device, +}; + +static int __init scmi_check_smccc_ver(void) +{ + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) + { + printk(XENLOG_WARNING + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); + return -ENOSYS; + } + + return 0; +} + +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_nod= e, + struct scmi_data *scmi_data, + u64 *addr) +{ + int ret; + u64 size; + + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_i= d) ) + { + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); + return -ENOENT; + } + + ret =3D scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); + if ( IS_ERR_VALUE(ret) ) + return -ENOENT; + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + return 0; +} + +static __init int scmi_probe(struct dt_device_node *scmi_node, const void = *data) +{ + u64 addr; + int ret; + struct scmi_channel *channel; + unsigned int n_agents; + scmi_msg_header_t hdr; + struct scmi_msg_base_attributes_p2a rx; + + ASSERT(scmi_node !=3D NULL); + + /* + * Only bind to the SCMI node provided by Xen under the xen,sci contai= ner + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to fir= mware + * SCMI nodes that belong to the host OSPM and keeps the mediator scop= ed to + * Xen-provided configuration only. + */ + if ( !scmi_is_under_xen_sci(scmi_node) ) + return -ENODEV; + + if ( !acpi_disabled ) + { + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); + return -EINVAL; + } + + ret =3D scmi_check_smccc_ver(); + if ( ret ) + return ret; + + ret =3D scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); + if ( ret ) + return ret; + + INIT_LIST_HEAD(&scmi_data.channel_list); + spin_lock_init(&scmi_data.channel_list_lock); + + scmi_data.dt_dev =3D scmi_node; + + channel =3D smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_= id, addr); + if ( IS_ERR(channel) ) + { + ret =3D PTR_ERR(channel); + goto out; + } + + /* Mark as Xen management channel before collecting agent ID */ + channel->domain_id =3D DOMID_XEN; + + /* Request agent id for Xen management channel */ + ret =3D collect_agent_id(channel); + if ( ret ) + goto error; + + /* Save the agent id for Xen management channel */ + scmi_data.hyp_channel_agent_id =3D channel->agent_id; + + hdr.id =3D SCMI_BASE_PROTOCOL_ATTIBUTES; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + ret =3D do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); + if ( ret ) + goto error; + + n_agents =3D SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); + ret =3D collect_agents(scmi_node); + if ( ret ) + goto error; + + ret =3D sci_register(&scmi_ops); + if ( ret ) + { + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\= n", + ret); + goto error; + } + + scmi_data.initialized =3D true; + goto out; + +error: + unmap_channel_memory(channel); + free_channel_list(); +out: + return ret; +} + +static const struct dt_device_match scmi_smc_match[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-smc"), + { /* sentinel */ }, +}; + +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) + .dt_match =3D scmi_smc_match, + .init =3D scmi_probe, +DT_DEVICE_END + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index 1fc676fd96..a9a10a3b8d 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); =20 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 =20 #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_NONE 0 #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_PMSA 1 @@ -361,7 +362,9 @@ struct xen_arch_domainconfig { uint8_t arm_sci_type; /* IN */ uint8_t v8r_el1_msa; - uint16_t pad; + /* IN */ + uint8_t arm_sci_agent_id; + uint8_t pad; }; #endif /* __XEN__ || __XEN_TOOLS__ */ =20 --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:40:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:40:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429020.1651981 (Exim 4.92) (envelope-from ) id 1x91fc-0006Bg-J3; Tue, 22 Sep 2026 14:40:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429020.1651981; Tue, 22 Sep 2026 14:40:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fc-0006A7-En; Tue, 22 Sep 2026 14:40:32 +0000 Received: by outflank-mailman (input) for mailman id 1429020; Tue, 22 Sep 2026 14:40:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fa-0005Xk-T5 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:40:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91fa-00AHxl-9X for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:40:30 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2934d-bab6-0a2a0a5309dd-0a2a4506e4aa-36 for ; Tue, 22 Sep 2026 16:40:30 +0200 Received: from [40.107.159.85] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2935b-195a-0a2a45060019-286b9f557f3a-8 for ; Tue, 22 Sep 2026 16:40:29 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV2PR03MB11837.eurprd03.prod.outlook.com (2603:10a6:150:36e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 14:40:26 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:40:26 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HwO+e2UqOklDKYhOHy9UV61zRYHwQObPH2xxdSgi2kfJfNkimZCH9hG8AJFCboYiGFa+YgjgycPmC2+ldjDt/6khfOmDd9Wfrpvob95c+gDEB4Ntm26OujvDCRFsRIu5h+6jK3FLW7psl47/GgY6odB2+UwSyvTjLSWnKrb3AQ35jISVJ4mYA9GjU6iyP9D/m/yETn6hpEwKsWwN5LrJmZvrQxFq3O88iC4sQ2oK6yvD5+ZP0wElgr2N4H4ASm04Qkgj7YjKFVkjVbXey0UIvZ/EHo8gbUAy43T00m2n/+ACaVLguJvG/WYv7eM/7LyEHx2s/VKbObLiXFh9EZZmRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YEB1ygg7k6uOLA8RSrzyTOVwxUCmQNEb0WWQgAfiVjU=; b=hfgbueMYE+8xijYsrrEyYFjQ8asN/DVROhL41Ye1Bw+D/b90eVmCUnizJnbbqRnxO3pUUECycr7Z1WxOGHQVkjlrG3QoU3FFNl/XCUfcd7Q4JHnau6TPFlpZQQ/+3RFxDFlT+hd3fQRkwp0BlX7YXlIZkN8m9EqUnieYVcsDKhGV11LDLeui/E+AtttL/HaKjoMwS4rcADswpsAJU2uSPAP1XAfXO5/WV9KeOIN/GWvFYQ3vSWWJwGpRgto4ZGDO1a/UpqsQCo6iJMA2CYGMAI8uulUV07tg0nSkuB+Ot0gCjUnFdRWXtGKgJ2MyKPb7b+qawLMZGAcGLUyLalrFZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YEB1ygg7k6uOLA8RSrzyTOVwxUCmQNEb0WWQgAfiVjU=; b=ENk+GCvZhlxsJhSKOaxr+goAS9VeoOIvej4DvX2en7MRTsELfIRMoReCMK5sDyGZCfOL+rExHfmWkBn7Z7je98gLReV6E8cx4Fmk2Vz/LL0tce0lFgU6qMk6SGrcJRo/ZxCjTijdGftjIHYglyke8aMEGlbvf/1wiqSQGZSv12AXJaEd6UI60HMfOhIBiDJMFahXA7TkAZwU0Pa7lXbYag5RsFGGvNb17enKfrwmG9o3SiqcclH0Cgif2L28cpH2Xfg6oorI9fKQwuQWhp7Ve5tQ8oBVYoOY8e0ERuFGXNsZven12Zz1ibYrMW/Q1Dseb/MdWC0x7W6bSNFFwTRS4A== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v13 5/6] tools/xl/libxl: wire up SCMI SMC multi-agent configuration Thread-Topic: [PATCH v13 5/6] tools/xl/libxl: wire up SCMI SMC multi-agent configuration Thread-Index: AQHdSqBOqljHv9ZNakqZnuriu076kA== Date: Tue, 22 Sep 2026 14:40:25 +0000 Message-ID: <2e4d8d0624f831a8f4758cfe3ba681722d5dbd1b.1790087968.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV2PR03MB11837:EE_ x-ms-office365-filtering-correlation-id: 98da9db1-6bc8-436e-d312-08df18b77144 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|366016|1800799024|6133799003|18002099003|22082099003|11063799006|56012099006|10067099003|38070700021; x-microsoft-antispam-message-info: Co+xjBdtMX82VLjqauwIFp/DwBi2lY7kuJhmeT3x+MaqMuYpyFKd3grjxFJWxJiDgSQFVsvWhLL+RpnOwNqT9EFKFSZDniSpy3GHvcsRYKZkFyjL8oDR9dNJ0UzL73dWs6ExIBHsYNeT0FLANc64ZRUIgj40Cz6xs/8j1jXanIKTa7igJO0zlTKdIMD50IdN1M6OF6zIk2gNoOZSmpGD6pViYdS2aElyNkeSI28JgVrk7wnr6m0XqbJpa0r4quZ14uP6clAzHg87NijnEvkNb8ON7TNJPBllPzCrx8YCwjF11vyYiJ2BbEF+nTbnR135hjyKrO358pOllDxv/Q5FFRq4pmda9uxUwnS6LUMw2F8sxC1a+CxuRsOP3AhrORRgefuhmSqbE8CObfiFZmibf49c7TQ3Z8aJvJ+8zSJEh1VbDFYg9bjXgiH/gUzrXFp9CJO/GkM/Hn5qSPXMC5b8U3w1GFzP5y6ssrhvcJFar2r3jkeXi8HazgLZ+vaNCmZ+iTM7cg6piaaURjWU5d4999qXMUppcFC0SCZhDjvOOQ3ZPM56PPxASOmXrX5GSMjJiZYBfnwKHGxyw50D3SnkXYOSehubLhdH6r20r1kHbWaaVW+ytfB1C709jIajMV49AdFfOCOS2ngTWZ5/JSzi8ndmgMaq3s0UlmJx/WC5QeqZjcRImZoSZ7MQKIP8bcxkQ2a7ptDrJXqF7IHXfBenlAEUomiq+Ik1VrjE0E0w0dQ= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(376014)(366016)(1800799024)(6133799003)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?3GSpx8JRO/mr2j2qQMOv0+l35/iHU5wqspMTjBWdlSb5miSRrkanm9+kVy?= =?iso-8859-1?Q?ZenSrh+A77XEqFCdKR9iPYbO2O9I6N/RIY5dR8pWmbcaStD34ZvuX+UlrL?= =?iso-8859-1?Q?evMwV9cvZtXjrBYjotNA5JyPv4f0d5DCaMpi7a2EA/2RiF6q+qQJLjy8fI?= =?iso-8859-1?Q?3Cx5MoORRJlz0zUBOks04VLwPxKVLmBGGKMTjY8AEaWnLx25J90N6muVMV?= =?iso-8859-1?Q?DAQEmStIxEB9GReXEZxMThZlxutzf2914c2z85CcSnbsOjSNzck4AusaKw?= =?iso-8859-1?Q?QbF/FR9QSTptlziGXb4a63/qBlCuKfb7YMgQKFH8Ts4FKjknT22yPUS3tb?= =?iso-8859-1?Q?rM3T+fT0Y+3yvVhIRmK4ZVSeYDZewJvU4mgwDBR45yFILZbW6vNvrmB7Ln?= =?iso-8859-1?Q?U772dc+2kWay31HShfjZ/cusGK0mPBuFXnwgcQZbL17++gVMPwoThg2OrS?= =?iso-8859-1?Q?cRiAgO7XVyiB1nYh1aS8G6uRw+FdEXphaJrkr/oUf7sSBUERIfk7l8+hXq?= =?iso-8859-1?Q?A1O3U4dVgn93plReTg3SpW1uzWSxbg1dFUxN/7+nMcBuNtsg961xrUvJWN?= =?iso-8859-1?Q?/RSz3E0Xp7P1q1nONwY3jw4hKdIT3gnd1k5Ebj5Sj3E+1SCiPoKrlRlT8r?= =?iso-8859-1?Q?uzRBBP0HCqPIx9e6RznNa9XafkMQ30aLb5yzh7w4tDJi8uSQ0+8vXZB2wc?= =?iso-8859-1?Q?BdbDsou5JDMEjO03IevtE3CZuAUmbvqc3obexpoVE+qW/vZuSVpBhL9iQ7?= =?iso-8859-1?Q?UV3fDf7D/nHsbhiu9cWtsyPy4cEAP7ZYEtWznJPYJ/aacFg/nQdtids6b+?= =?iso-8859-1?Q?uxUwSlSnh96X6nLulYwJzw+gjWnQ+sV8JKHUYsWcOG7sKkU1oy2RBOkwGd?= =?iso-8859-1?Q?2IUcTQOQPoX6E5by878s01GFKJCE1gyh2NJM0/e5RhLgBc+WRP5K/0MEqs?= =?iso-8859-1?Q?7eUOw+FYOVzcDQk6J6Yfc++Y/fQHPuflt/wv5jqfqGhXjVC0oxfJwhjSji?= =?iso-8859-1?Q?zmxFBljT2gQP+fATXMl9AzyyfOg2KWEJi1Re6sCrqB5CG/lyKxLQWizkNC?= =?iso-8859-1?Q?nYDswzVSNkoQOdR20/t4faBSJJCvzw4vcaUR4LP4EjMow9MyHvefDWCIvB?= =?iso-8859-1?Q?qWMyojI5h94nUklXlkC1u0iZwiZ7UsM71wYGARPRW9aD7+4allkCCKieWV?= =?iso-8859-1?Q?6D3AQonaHDgh63bfOzlm7vF7qbz/kFuhFTAdyVbFO5Jqdnj4ZK46A/llw3?= =?iso-8859-1?Q?UZEh/Bxde1J+U8qKMq59wByWft5cGDrQJ/PLtltYr0jGsSS067Dj3gAYzh?= =?iso-8859-1?Q?sPLqeTYeCp4U5KqW4EfEh4my52rKjnLCI2ziul7Bo8M60L8UMVTmSZeszQ?= =?iso-8859-1?Q?ydeQDgIBKONSgUyRYt5euY3cR6R38hCd6I8PpqMnAzoszCVv3tP6LVLIq2?= =?iso-8859-1?Q?dKZsoouGRP3Og9AxDnMIbjYA6+PQcKkWETBwW4IQ1dkW0sUE7jIxamgAh8?= =?iso-8859-1?Q?/0CXGIHv8cJoncPt6TiNyqVuQzKqibi4f3XZA8/qQgagHd0+chMQS7fyg+?= =?iso-8859-1?Q?nBQt16bRBnO5x+v80zA50/6MgMd8R5bfyvvKgIiYynNQJAQUG4FRo4wv+t?= =?iso-8859-1?Q?GltOwO86m3fmCjBNfpfC3WfcO270+fAcgj7yv3Sdr05tbK1iL0WFDFi/Zr?= =?iso-8859-1?Q?whexckLuwLw1eFsTpd9AnbiEYFK+J+VICDhwuMvUiPWqASYI/PBhbG0Cwi?= =?iso-8859-1?Q?pGqUbDc7eaFYHGXOP5ZdtTNGSFA5KWKt66fLD1nZOCkkHiX/Pwo8Eox/eq?= =?iso-8859-1?Q?Sh+qgUKEIuIMGaq0og0dxftw+H7C+AA=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98da9db1-6bc8-436e-d312-08df18b77144 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 14:40:25.9546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FOQQxf6UxRInvtDlAsAq29PTlABCHMc60QRQQ7dZFZpwlcI7fMgf/ojVg3QlPRkuYk+k1MTUx6JI5GpQvt3xQpq0w9pJCJ9xyNuKV/yZ/U8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11837 X-purgate-ID: tlsNG-16d1c6/1790088029-F540B77B-1F10B7D7/0/0 X-purgate-type: clean X-purgate-size: 7327 Plumb the SCMI SMC multi-agent type through the toolstack: - Extend libxl_arm_sci_type enumeration with scmi_smc_multiagent (value 2) - Add agent_id field to libxl_arm_sci structure for per-domain agent assign= ment - Update libxl_arm.c to translate libxl config to XEN_DOMCTL_CONFIG_ARM_SCI= _SCMI_SMC_MA and pass agent_id to the hypervisor via xen_domctl_createdomain - Add xl.cfg parsing for arm_sci=3D"type=3Dscmi_smc_multiagent,agent_id=3DN= " - Document the new xl.cfg options in xl.cfg.5.pod.in This completes the userspace side of multi-agent SCMI, allowing xl create and dom0less configurations to assign unique agent_id values to domains. Series-changes 12: - reject agent_id in xl.cfg when the ARM_SCI type is not scmi_smc_multiagent, instead of parsing it and discarding it - perform the check after the option loop, as type and agent_id may be given in either order Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- (no changes since v11) Changes in v11: - Fix agent_id documentation: clarify it applies to SCMI SMC multi-agent support only, not plain SCMI SMC (reviewer feedback) - Remove "non-zero" from agent_id description to match accepted range [0..254] - Remove "UINT8_MAX (255) is treated as invalid" from user documentation as unnecessary implementation detail - Add LIBXL_HAVE_SCMI_SMC_MULTIAGENT feature macro in libxl.h to advertise the new scmi_smc_multiagent type and agent_id field - Add agent_id validation in libxl__arch_domain_build_info_setdefault() to reject invalid values at the libxl level, not only in xl Changes in v10: - Split hypervisor and toolstack changes into separate commits docs/man/xl.cfg.5.pod.in | 13 +++++++++++++ tools/include/libxl.h | 8 ++++++++ tools/libs/light/libxl_arm.c | 13 +++++++++++++ tools/libs/light/libxl_types.idl | 4 +++- tools/xl/xl_parse.c | 27 +++++++++++++++++++++++++++ 5 files changed, 64 insertions(+), 1 deletion(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index d34951edb9..1dec511f20 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3179,8 +3179,21 @@ single SCMI OSPM agent support. Should be used together with B Xen command line option. =20 +=3Ditem B + +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI ov= er +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmwar= e-A) +with a multi SCMI OSPM agent support. The SCMI B should be +specified for the guest. + =3Dback =20 +=3Ditem B + +Specifies an ARM SCI agent id for the guest. This option is mandatory +if the SCMI SMC multi-agent support is enabled for the guest. The agent id= s of +domains existing on a single host must be unique and in the range [0..254]= . + =3Dback =20 =3Dback diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 7c098edab6..9f46566739 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -318,6 +318,14 @@ */ #define LIBXL_HAVE_BUILDINFO_ARCH_ARM_SCI 1 =20 +/* + * LIBXL_HAVE_SCMI_SMC_MULTIAGENT indicates that the + * LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT value is available in the + * libxl_arm_sci_type enumeration and the agent_id field is available + * in the libxl_arm_sci structure. + */ +#define LIBXL_HAVE_SCMI_SMC_MULTIAGENT 1 + /* * LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing * 'soft reset' for domains and there is 'soft_reset' shutdown reason diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c index e4407d6e3f..3adb90c286 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, case LIBXL_ARM_SCI_TYPE_SCMI_SMC: config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; break; + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_M= A; + config->arch.arm_sci_agent_id =3D d_config->b_info.arch_arm.arm_sc= i.agent_id; + break; default: LOG(ERROR, "Unknown ARM_SCI type %d", d_config->b_info.arch_arm.arm_sci.type); @@ -1837,6 +1841,15 @@ int libxl__arch_domain_build_info_setdefault(libxl__= gc *gc, } } =20 + /* Sanitise ARM SCI agent_id parameter */ + if (b_info->arch_arm.arm_sci.type =3D=3D LIBXL_ARM_SCI_TYPE_SCMI_SMC_M= ULTIAGENT && + b_info->arch_arm.arm_sci.agent_id >=3D UINT8_MAX) { + LOG(ERROR, + "Invalid ARM SCI agent_id: %u. Valid range is [0..254]", + b_info->arch_arm.arm_sci.agent_id); + return ERROR_FAIL; + } + if (b_info->type !=3D LIBXL_DOMAIN_TYPE_PV) return 0; =20 diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type= s.idl index 3c35f873df..9830671ca4 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -554,11 +554,13 @@ libxl_sve_type =3D Enumeration("sve_type", [ =20 libxl_arm_sci_type =3D Enumeration("arm_sci_type", [ (0, "none"), - (1, "scmi_smc") + (1, "scmi_smc"), + (2, "scmi_smc_multiagent") ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE") =20 libxl_arm_sci =3D Struct("arm_sci", [ ("type", libxl_arm_sci_type), + ("agent_id", uint8) ]) =20 libxl_rdm_reserve =3D Struct("rdm_reserve", [ diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 01783731b5..6bb3325c98 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1290,6 +1290,7 @@ static int parse_arm_sci_config(XLU_Config *cfg, libx= l_arm_sci *arm_sci, const char *str) { int ret =3D 0; + int agent_id_set =3D 0; char *buf2, *ptr; char *oparg; =20 @@ -1308,9 +1309,35 @@ static int parse_arm_sci_config(XLU_Config *cfg, lib= xl_arm_sci *arm_sci, } } =20 + if (MATCH_OPTION("agent_id", ptr, oparg)) { + unsigned long val =3D parse_ulong(oparg); + + if ( val >=3D UINT8_MAX ) { + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%l= u). Valid range [0..254]\n", + val); + ret =3D ERROR_INVAL; + goto out; + } + arm_sci->agent_id =3D val; + agent_id_set =3D 1; + } + ptr =3D strtok(NULL, ","); } =20 + /* + * agent_id only means something to the multi-agent driver, and + * libxl__arch_domain_prepare_config() only reads it for that type. + * Reject it elsewhere instead of silently dropping it. The check is d= one + * after the loop because the options may be given in any order. + */ + if (agent_id_set && + arm_sci->type !=3D LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT) { + fprintf(stderr, + "ARM_SCI agent_id is only supported with type=3Dscmi_smc_m= ultiagent\n"); + ret =3D ERROR_INVAL; + } + out: free(buf2); return ret; --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:40:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:40:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429021.1651991 (Exim 4.92) (envelope-from ) id 1x91fd-0006Ms-6t; Tue, 22 Sep 2026 14:40:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429021.1651991; Tue, 22 Sep 2026 14:40:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fc-0006Js-T3; Tue, 22 Sep 2026 14:40:32 +0000 Received: by outflank-mailman (input) for mailman id 1429021; Tue, 22 Sep 2026 14:40:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91fb-0005db-56 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:40:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91fa-00AHxl-HW for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:40:30 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2934d-bab6-0a2a0a5309dd-0a2a4506e4aa-40 for ; Tue, 22 Sep 2026 16:40:30 +0200 Received: from [40.107.159.85] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2935b-195a-0a2a45060019-286b9f557f3a-9 for ; Tue, 22 Sep 2026 16:40:30 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV2PR03MB11837.eurprd03.prod.outlook.com (2603:10a6:150:36e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 14:40:27 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 14:40:27 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WfbKos80XznyDPftf5KiWMIFnD44jddZg6S9jzGUYUNN+Lvv5X3WxAi2r81oEURcFFlg/wZgJXLnWwa7AMgeMaEEikEFgNXg2GjRjQnjRDGsucFIkdTtiMfm/QF99ZPTALneJI8jG76m1y5ioQk1GXA/RFQZA2Xttl6OyZo0H+jhirmaQ6AfIhHkcrDSu63OWi4SYH1BAbFbzUEqQrylHODFc4B+hSHfK4XdJ1Y1eWI8sPUlBCKNnC0bifoxz5W4PtMLhjI5LqnS7MGtrE3y6TQe6Cc23FDvtvdndtexk3LBNEjqKVSRyGLDmGLs4ooOft2bCLSdgVqJxEQyP5JBQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f5VLDzjGdXZ3fBMESadikUu6melFUxWISeZNonumRnY=; b=oCxA9gPh4YM2vBjrHBYBKIpsvFOL4GQ1RU0yYqk0yZJ+QvNzExMLUUSEDfRO+qT44H1WamwYVmvwqx4qXR4l+WOHAFdXnBEI6R4nnIXrdA2qSTnFnDGUPNMv2kevxZdcxWlDQEg32mo/TNjElrO+hXdvEv6DRJI0/6S8qujD59HLdQA3ZD0nGEPSJggH1zbBny/PTwgyUx9fgX9EPfFnWr1YaLbLgOCeemXJfJ10D/5qUD7zKK3JqL2CYZPoiMdZRSotYfQUYxFZp00Kv9j6gcBGGu8x/snnNx9yTgq2PYaGKr/JHQwSdGI/VM8blN2+vmssWN+qdZQ2GCjmhSm1kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f5VLDzjGdXZ3fBMESadikUu6melFUxWISeZNonumRnY=; b=M9XH9tGxluEF7odKkTVRTPVsK3IMro5mWiR+0AzT9rCvFe9ArQmsByRk5Bbq6HtIvBxQP1eADT54yWWQRhAT2j+s8FPnD2i0ru3lIoNX7TOjU/3UlRKkyX/ReZt6si9NT4JuUMOUFmWW4I6K6glbEfFG3Mgc2OU5Y15I1OKCGkHLICw0mkADfsaHomMSNVFeqpagI9xasT02VxJmC1Nd3UNpwEOnjqOFH0lNwuDBMipfkxONF03mrw3sGEmScwlYC7AeNvb5r8RvG2CqDI1kCinFIJg4UrH1Bc8Q83TuDPkHwnJ7vmpYsY61QSdSgsMqYqDsyhzUgEZmHrKWKh3WtQ== From: Oleksii Moisieiev To: "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , Oleksii Moisieiev , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v13 6/6] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Topic: [PATCH v13 6/6] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Index: AQHdSqBOmL4tbK2mIUKon1saCe3zLg== Date: Tue, 22 Sep 2026 14:40:26 +0000 Message-ID: <08f10459d0877e9960fe00182a5b7c1ba0551f64.1790087968.git.oleksii_moisieiev@epam.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV2PR03MB11837:EE_ x-ms-office365-filtering-correlation-id: 7c2ef69b-ace9-40c8-1770-08df18b77175 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|23010399003|376014|366016|1800799024|6133799003|18002099003|22082099003|11063799006|56012099006|10067099003|38070700021|3023799007; x-microsoft-antispam-message-info: vC5s5T6uhZ8+wFtlbfGl7gHQWrzmNxDSrWxwOzHEZPGo+dI4ra2B/YBE+BYIrPyQ+x9vqFdPuRaZE7FjAnDzKQ8wGo2d8lJY6WDqJAwq6A5pJ0xsi6rAc2cJjQLw6QpAxkZus0pcxn7dNUFSz+ophGzzGhGuR05CSqNpipWJBp8Wo3BEBDStvsStYnZOPWyl3pqgdyU/Hfzeaku8n97wTcaGUmSeq84GjCxBzmfoctzOuoBIdfnP3JG7JqLgYMaZYkiXqLfD3SirXOkORYQXrgdGSE9Hnf5a/yUBn3DUKB9AWa6V0NeH2yYL+qav16HB70RjXL0uUxLv+9HCdakvORdw7MtFGKwQWrMLQzmKs1wgSJkDe/yiO5gtAFBkUj9KAU97j7+KvJjMvHNjbmYkhSzvYMrSTLVpM3JdARTg9YBZV1IIbd5YoyWH8TlKvvf6/GH7bAOHcnmmhJmiDBIdgkjDoJvCyAzvcQy8P2jo5MHg/Zm3Ot+s56ltDuO9kTD/Gb0IqQYpRQ6I6g4FsoqzJcAHKy2D5CjoJDFOxUysd4SpzL/8wMvM2rn6A5W9qw5QVXDh2cY3bElQgstx3gSgAdoaViwXWary3XD9GOLBTpRWVK22smKW1AQa8T+mI9kAIef4uH4PSP5SOUDoYfQj4avr+zapDxSXnHC4XT1LuiM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(23010399003)(376014)(366016)(1800799024)(6133799003)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(38070700021)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?NkRj1jRmd5D2m/aimZY45rlJ286LToamC2EYjMdDCwgUUKpXeBOXVCObKF?= =?iso-8859-1?Q?zjsfQ5Btm5bWxHn74JFr9D0ybH9UAR30u7JsZBIjOJKw0nexfTbCU7r/Ba?= =?iso-8859-1?Q?8oxFTqLiu0o9++5x83vkQ9aW67imEXQfcgBCm2aqH5bvC81/g2uNSYUszx?= =?iso-8859-1?Q?MI194+nygzk8rPADnWwShI5Gn5gwgTzo2jRF0D260o+CFtri63W93AMjpP?= =?iso-8859-1?Q?iKUShsIZiMd6AeRRpFa06Wb/n286wwEoD+BxaMAndoFXSt4fELVU9UI6PS?= =?iso-8859-1?Q?9eW9vM8yGMU9CWv1U7HcFT0lmRDBDDp5McaqEcugDUROSR9WyjK9pTiual?= =?iso-8859-1?Q?QZIGL0sZUM93754rQ3WwbnVAyP0YgOBdB7eBAT9miU0n9qp4OM4ayGUrGa?= =?iso-8859-1?Q?rOb3+edR8HaiPyplEUHXsZRFS00lO0rYkdj9N8bKQL7Dp+bLFfmnyGEdIg?= =?iso-8859-1?Q?LMjtdGYYSbsBs+erVtubBfS4VBUDHm+Sx0QkRoL5X8C7w4KvVJdZmJxqPo?= =?iso-8859-1?Q?OuR3ls53wjSMVnyr++mip5dlE8pH8wNEjoUPPpNbup63Hq/xIEkw2LGRIB?= =?iso-8859-1?Q?34M+W0CtDhJNSqfeBdOoprxghg8U0ZsJ55JYYW2/rdLqepXmoyvhySW3wq?= =?iso-8859-1?Q?emD4FNOtC5rPFUsfhKOoTUmtFSNJSoUdD2Mf/RLBXM1vw5IhkNVzKN0dMK?= =?iso-8859-1?Q?xNF83Lp9PX6FsZ43r/rYMARAmNLZNAfHrCMLP5RhvpErXuht2WSJ2HhKtM?= =?iso-8859-1?Q?mgBBDLCp0XLXcvTKU5DQi0EtFKoGWDdYkRWiKgav8OTLTUh29geltZGBxg?= =?iso-8859-1?Q?pgPdb5NV3D/LKtVh4k4f7AMkN4SnMfw6xSCSMCZk1ttiBS3Lr7ad5zDoYP?= =?iso-8859-1?Q?NTr30km3V9l5hzKsh3sxXjTOoS9Hy0oHHTjOuFRKsCCesUcvB4dfXNUzRG?= =?iso-8859-1?Q?TYl9CID2JLgzvAPmRlL9KXqM470F5s9fmTZOsLm1fwKRHFs0yXx/scYsUJ?= =?iso-8859-1?Q?cUqlCT3v8GVBVCSezTiHbnr285682pJAonzME0vOgQNcr+EiumKBtOXivQ?= =?iso-8859-1?Q?vi/uCEMFJv9G3ErpBr9+UK/2F2wcLAwodNLvjvT8Yq00u3oFqJFEJyrf+C?= =?iso-8859-1?Q?3n3rRbJAUx0ypPPPsorausXtSYw5lvOTcKbdpJ/FZx92/jevSTVdBVAn3Q?= =?iso-8859-1?Q?ee6PsjG8dLV1iK+3i88+nGH/EfNpdaSEZXkQP9QBf3ABykW0f4VgDwbPiz?= =?iso-8859-1?Q?wNa9Xm7e+z3xrKapw+8TATL0jqd5u7DR9bYrj1QEe/bJapaZBtWqt4FjNI?= =?iso-8859-1?Q?aPD7IdmJCh9yY/lByWKKUrn2dY0LTQ0x9AAeB1TcqQIrbkWs0dOt4uGC3K?= =?iso-8859-1?Q?svgtRp1LptRKEoVZT8ELS2Ys5Ql1rhl2nP0RZilVC1OveGMANT7Oi4IMl1?= =?iso-8859-1?Q?EzF2gtQBN8s1QHX8IK29+3T/5jT/U4plJqHWP+bETzTJTP1hZIw0htfxxg?= =?iso-8859-1?Q?qu6fAj6oLhzUF3mpDj7TlxBHcvwEkY7wnhO+QbBZihBIBnWgr6QMM28GsX?= =?iso-8859-1?Q?hFrRisBRDDU+58PvIdTyS16o/IOgD+WLuXmqBwfhkq9Jn8Z4bnWkt3LXmk?= =?iso-8859-1?Q?2JJER0xbDsXh9Ln0W61u6MG1rV4hgO4NcwiAjw323wbY/GzXqqYz369DIH?= =?iso-8859-1?Q?/Wn4kDKV/b91WgOhsC5ZzO4Nozwn1FMS1rjtJDCdCb70erFvSk/OMPAns0?= =?iso-8859-1?Q?ZWY42QR2eVeLgxbXHRqnXAYkpAsjh2bkMg4m867qqE1SyfoQ2sLM1b7oup?= =?iso-8859-1?Q?Zgna+/ZaF/QEQh321OpTxGTAvqSDyTg=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c2ef69b-ace9-40c8-1770-08df18b77175 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 14:40:26.3616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XwfTR8s44I5LGoLx4zHECICcFEf764lw0gG3ItyHxoQJQYd0Rm/hyvTCo8WuUXsaNU4pkZHAvvVY5rIKLjpTHU9CA/kfIVhU+bS7CdvhfEM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR03MB11837 X-purgate-ID: tlsNG-16d1c6/1790088030-F460277B-8AAD7747/0/0 X-purgate-type: clean X-purgate-size: 18936 From: Grygorii Strashko Add SCI SCMI SMC multi-agent driver documentation. It includes a detailed description of the SCMI multi-agent driver. This document explains the driver's functionality, configuration, and the compilation process. The Xen SCMI multi-agent driver is designed to provide SCMI access to system resources from different domains. Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- (no changes since v10) Changes in v10: - rephrase section about /firmware/scmi. Mentioned that this node is taken from Host DT and copied unmodified. - fix xen,reg address for secondary domains for Dom0less configuration Changes in v8: - update documentation to match the last DT format - fixed RST: "... code-block:: dts" -> ".. code-block:: dts" - update documentation with dom0less configuration example - update documentation with new param xen,dom0-sci-agent-id instead of the command line parameter Changes in v7: - update documentation in section of the xen_scmi configuration which is matched by "xen,sci" compatible instead of the direct path. Changes in v6: - remove all HVC mentions from the multi-agent doc - update sci-agent-id parameter description in the documentation - add missing Sign-of - minor fixes across the document Changes in v5: - rework multi-agent driver to leave Host Device-tree unmodified .../arm/firmware/arm-scmi.rst | 422 ++++++++++++++++++ 1 file changed, 422 insertions(+) diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi= sor-guide/arm/firmware/arm-scmi.rst index d9698f4e4b..8791bc665e 100644 --- a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst @@ -36,6 +36,8 @@ The below sections describe SCMI support options availabl= e for Xen. =20 | [1] `Arm SCMI `= _ | [2] `System Control and Management Interface (SCMI) bindings `_ +| [3] `Generic Domain Access Controllers bindings `_ + =20 Simple SCMI over SMC calls forwarding driver (EL3) ------------------------------------------------------ @@ -189,3 +191,423 @@ except explicitly enabling SCMI with "arm_sci" xl.cfg= option. -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; -> xen,force-assign-without-iommu; }; + +SCMI SMC multi-agent driver (EL3) +------------------------------------- + +The SCMI SMC multi-agent driver enables support for ARM EL3 Trusted Firmwa= re-A (TF-A) which +provides SCMI interface with multi-agent support, as shown below. + +:: + + +-----------------------------------------+ + | | + | EL3 TF-A SCMI | + +-------+--+-------+--+-------+--+-------++ + |shmem1 | |shmem0 | |shmem2 | |shmemX | + +-----+-+ +---+---+ +--+----+ +---+---+ + smc-id1 | | | | + agent1 | | | | + +-----v--------+---------+-----------+----+ + | | | | | + | | | | | + +--------------+---------+-----------+----+ + smc-id0 | smc-id2| smc-idX| + agent0 | agent2 | agentX | + | | | + +----v---+ +--v-----+ +--v-----+ + | | | | | | + | Dom0 | | Dom1 | | DomX | + | | | | | | + | | | | | | + +--------+ +--------+ +--------+ + +The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared-m= emory transport +for every Agent in the system. The SCMI Agent transport channel defined by= pair: + +- smc-id: SMC function id used for Doorbell +- shmem: shared memory for messages transfer, **Xen page aligned**. + Shared memory is mapped with the following flags: MT_DEVICE_nGnRE and _P= AGE_DEVICE, indicating that this + memory is mapped as device memory. + +The following SCMI Agents are expected to be defined by SCMI FW to enable = SCMI multi-agent functionality +under Xen: + +- Xen management agent: trusted agents that accesses to the Base Protocol = commands to configure + agent specific permissions +- OSPM VM agents: non-trusted agent, one for each Guest domain which is a= llowed direct HW access. + At least one OSPM VM agent has to be provided by FW if HW is handled onl= y by Dom0 or Driver Domain. + +The EL3 SCMI FW is expected to implement following Base protocol messages: + +- BASE_DISCOVER_AGENT (optional if agent_id was provided) +- BASE_RESET_AGENT_CONFIGURATION (optional) +- BASE_SET_DEVICE_PERMISSIONS (optional) + +The number of supported SCMI agents and their transport specifications are= SCMI FW implementation +specific. + +Compiling with multi-agent support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build with the SCMI SMC multi-agent driver support, enable Kconfig opti= on: + +:: + + CONFIG_SCMI_SMC_MA + + +Driver functionality +^^^^^^^^^^^^^^^^^^^^ + +The SCI SCMI SMC multi-agent driver implements following functionality: + +- The driver is initialized from the Xen SCMI container ``xen_scmi_config`= ` + under ``/chosen/xen`` (for example ``/chosen/xen/xen_scmi_config/scmi``)= . + Only one SCMI interface is supported. The SCMI configuration must live u= nder + the Xen SCMI container ``xen,sci`` beneath ``/chosen``. + The Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is = a child of + this "xen,sci" container; any other "arm,scmi-smc" nodes (for example un= der + "/firmware") are ignored to avoid stealing the host's SCMI OSPM instance= . + +.. code-block:: dts + + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + +.. note:: + This layout keeps the Host DT unchanged for Dom0 and baremetal Linux by + using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a + separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 + firmware enforces permissions per agent_id, so there is no conflict bet= ween + Dom0 and Xen channels. + +- The driver obtains Xen specific SCMI Agent's configuration from the Host= DT, probes Agents and + builds SCMI Agents list. The Agents configuration is taken from "scmi-se= condary-agents" + property where first item is "arm,smc-id", second - "arm,scmi-shmem" pha= ndle and third is + optional "agent_id": + +.. code-block:: dts + + chosen { + ranges; <--- set default ranges so address can be translated when pa= rsing scmi_shm node + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; <--- set default ranges so address can be translated whe= n parsing scmi_shm node + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3 + 0x82000006 &scmi_shm_4 4>; + #scmi-secondary-agents-cells =3D <3>; <--- optional, default 3 + xen,dom0-sci-agent-id =3D <0>; /* Dom0 agent ID */ + + scmi_shm_0 : sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + scmi_shm_4: sram@47ff4000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff4000 0x0 0x1000>; + }; + + // Xen SCMI management channel + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-i= d + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + }; + }; + }; + + /{ + // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI ena= bled for it + scmi_shm: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + firmware { + scmi: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem + + protocol@X{ + }; + }; + }; + }; + + This approach allows defining multiple SCMI Agents by adding Xen-specifi= c properties under + the ``/chosen`` node to the Host Device Tree, leaving the main part unch= anged. The Host DT + SCMI channel will be passed to Dom0. + + The Xen management agent is described as a ``scmi_xen`` node under the `= `xen,sci`` compatible node, + which is used by Xen to control other SCMI Agents in the system. + + All secondary agents' configurations are provided in the ``scmi-secondar= y-agents`` property with + an optional ``agent_id`` field. + + The ``agent_id`` from the ``scmi-secondary-agents`` property is used to = identify the agent in the + system and can be omitted by setting ``#scmi-secondary-agents-cells =3D = <2>``, so the Secondary + Agents configuration will look like this: + +.. code-block:: dts + + chosen { + xen { + xen_scmi_config { + compatible =3D "xen,sci"; + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + }; + }; + } + + In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to disc= over the ``agent_id`` + for each secondary agent. Providing the ``agent_id`` in the ``scmi-secon= dary-agents`` property + allows skipping the discovery call, which is useful when the secondary a= gent's shared memory is + not accessible by Xen or when boot time is important because it allows s= kipping the agent + discovery procedure. + +.. note:: + + Note that Xen is the only one entry in the system which need to know a= bout SCMI multi-agent support. + +- The driver implements the SCI subsystem interface required for configuri= ng and enabling SCMI + functionality for Dom0/hwdom and Guest domains. To enable SCMI functiona= lity for guest domain + it has to be configured with unique supported SCMI Agent_id and use corr= esponding SCMI SMC + shared-memory transport ``[smc-id, shmem]`` defined for this SCMI Agent_= id. + +- Once Xen domain is configured it can communicate with EL3 SCMI FW: + + - zero-copy, the guest domain puts/gets SCMI message in/from shmem; + - the guest triggers SMC exception with agent "smc-id" (doorbell); + - the Xen driver catches exception, do checks and synchronously forwards= it to EL3 FW. + +- the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen manag= ement agent channel on + domain destroy event. This allows to reset resources used by domain and = so implement use-case + like domain reboot. + + +Configure SCMI for Dom0 +^^^^^^^^^^^^^^^^^^^^^^^ +Set the Dom0 SCMI agent ID in the device tree using the Xen SCMI container= under ``/chosen``. +Add ``xen,dom0-sci-agent-id`` to the ``xen,sci`` node. If the property is = absent, SCMI stays +disabled for Dom0 and the SCMI nodes are removed from Dom0 DT. + +.. code-block:: dts + + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + xen,dom0-sci-agent-id =3D <0>; /* Dom0 agent ID */ + /* scmi-secondary-agents and scmi_xen as shown above */ + }; + }; + }; + +The Host DT ``/firmware/scmi`` node is copied to the Dom0 DT unmodified. H= owever, for Dom0 SCMI +configuration, Xen actually relies on ``scmi-secondary-agents`` and ``xen,= dom0-sci-agent-id`` +properties from the ``xen,sci`` container under ``/chosen``. If the ``/fir= mware/scmi`` node is +missing or disabled, or if ``xen,dom0-sci-agent-id`` is not provided, the = Dom0 SCMI agent will not +be configured. + +.. note:: + + The ``xen,dom0-sci-agent-id`` value must match the ``func_id`` and ``shm= em`` pairing provided by + the EL3 firmware for Dom0 (for example in the ``/firmware/scmi`` node). + +Configure SCMI for for guest domain with toolstack +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* In domain's xl.cfg file add **"arm_sci"** option as below + +:: + + arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" + +* In domain's xl.cfg file enable access to the "arm,scmi-shmem" which shou= ld correspond + assigned "agent_id" for the domain, for example: + +:: + + iomem =3D [ + "47ff2,1@22001", + ] + +.. note:: It's up to the user to select guest IPA for mapping SCMI shared-= memory. + +* Add SCMI nodes to the Driver domain partial device tree as in the below = example. + The "arm,smc-id" should correspond assigned agent_id for the domain: + +.. code:: + + passthrough { + scmi_shm_0: sram@22001000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x22001000 0x0 0x1000>; + }; + + firmware { + compatible =3D "simple-bus"; + scmi: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000004>; <--- smc-id for agent_id= =3D2 + shmem =3D <&scmi_shm_0>; + ... + } + } + } + +**Device specific access control** + +The XEN SCMI SMC multi-agent driver performs "access-controller" provider = function in case +EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and p= rovides the +BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agent= s have access to. +The Host DT SCMI node should have "#access-controller-cells=3D<1>" propert= y and DT devices should +be bound to the SCMI node using Access Controllers bindings [3]. + +For example: + +.. code-block:: dts + + &i2c1 { + access-controllers =3D <&scmi 0>; + }; + +Use domain's xl.cfg file **"dtdev"** property to assign SCMI devices from = toolstack to the guest: + +:: + + dtdev =3D [ + "/soc/i2c@e6508000", + ] + +.. note:: + + xl.cfg:"dtdev" need contain all nodes which are under SCMI management = (not only those which are + behind IOMMU) and passed-through to the guest domain. + +Configure SCMI for predefined domains (dom0less) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add "xen,sci_type" and "xen,sci-agent-id" properties for required DomU (= "xen,domain") node + +:: + + xen,sci_type=3D"scmi_smc_multiagent" + xen,sci-agent-id=3D2 + +* add scmi nodes to the Driver domain partial device tree the same way as = above (toolstack case) and + enable access to the "arm,scmi-shmem" according to the dom0less document= ation. For example: + +.. code-block:: dts + + scmi_shm_0: sram@22001000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x00 0x22001000 0x00 0x1000>; + -> xen,reg =3D <0x0 0x47ff2000 0x0 0x1000 0x0 0x22001000>; + -> xen,force-assign-without-iommu; + }; + +* For SCMI device access control configure pass-through devices in the gue= st partial DT according to + the dom0less documentation and ensure that devices SCMI management has "= xen,path" property set: + +Example (dom0less, multi-agent): + +.. code-block:: dts + + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Xen management channel shared memory */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_domu: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000004 &scmi_shm_domu 2>; + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; + }; + }; + }; + + xen,domain@1 { + compatible =3D "xen,domain"; + xen,sci_type =3D "scmi_smc_multiagent"; + xen,sci-agent-id =3D <2>; + /* other domain properties here */ + }; + }; + +.. code-block:: dts + + i2c@e6508000 { + ... + reg =3D <0x00 0xe6508000 0x00 0x1000>; + -> xen,path =3D "/soc/i2c@e6508000" + -> xen,reg =3D <0x0 0xe6508000 0x0 0x1000 0x0 0xe6508000>; + -> xen,force-assign-without-iommu; + }; --=20 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:48:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:48:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429072.1652009 (Exim 4.92) (envelope-from ) id 1x91nD-00026R-2B; Tue, 22 Sep 2026 14:48:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429072.1652009; Tue, 22 Sep 2026 14:48:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91nC-00026K-V3; Tue, 22 Sep 2026 14:48:22 +0000 Received: by outflank-mailman (input) for mailman id 1429072; Tue, 22 Sep 2026 14:48:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x91nB-000255-OH for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:48:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91nA-008JaI-Sv for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:48:20 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29528-8faa-0a2a0a5109dd-0a2a4504959e-38 for ; Tue, 22 Sep 2026 16:48:20 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29534-b57f-0a2a45040019-4a7de14ca655-3 for ; Tue, 22 Sep 2026 16:48:20 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f63546c3so10237f8f.1 for ; Tue, 22 Sep 2026 07:48:20 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48862774543sm6162055f8f.11.2026.09.22.07.48.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 07:48:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790088500; x=1790693300; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=XlMJKnRCM9WsVOoHs8R7g0KyORvdFCPXy8vPf7MCrd0=; b=ryws05a5IB+kD7LzUmJ8pU0Z1m4ULVHhFbGiJ5JM1wiip5FUOyI8+eaDEzl+kt9CUh NhB4xlk/5Tk43fimTQKzvVMboqUScwQBc0HfyGO1bYVrtihOmekn+DEtC/4FCJvj1VV7 NMzbwIG/8KHsxJPzP00a8HMgCvOCPWz+GmFU8N0cHlK26kLt1ZqH6AM8z7egK5ttU7Y8 Balu/vcmNp0NNPAP4+kzF1UqW3f2CYL+je/dNq9OzFVqZjA5GaWUSScjXadyAmlZTKkm bRRgOynakpfmaylbLzFpGy05nq02rVzs2dP+Svolv+Ilsr6Y69POP1aenH8z1KkI6m4t nazQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790088500; x=1790693300; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=XlMJKnRCM9WsVOoHs8R7g0KyORvdFCPXy8vPf7MCrd0=; b=TXFHMFd8Q+8XCy/u0Yjp8w+yLaZNwuf2WaaBOCgkmV3W1u1WIDSVSR3/Z3YNp/2kyq QWqZJ1H3OUzU002uifL+HvHo+fGFFoiSIy0kqOtTMVARZJJu0c9d0JgLclfbxNDISqHW SMeI4wdOMngsKqYoTmc904V8SEhfu8I7Var2mJiV/ZhTFcFjLXmQGa4HvABBnU+pceGN yXHMoGbGTCfvTtzXD6J8vDhvslNAfgqUg1teHVeVGo6tJrLyuGj1A1zimEXuINDmH8Kz g4NFDLoH/BSDqOUwL6v/uB7tVC+OJjrGw623erv8ELxpwe+XxQaldP+OHqLpfiW9nV08 xpXg== X-Gm-Message-State: AFuF++n8vsBqQOStXP6to01xFxKL/hH361ytD+Ytw8VwDOZVe2Fk0u7N J5QAgL1aKpV11+qU2lv08AUpSux762rGkUVhSsrj0KuHFlBQB1I3PQtA X-Gm-Gg: AYBFou2xwDpHtglvj7d5aqYKQKp6vNZE3t5zmpj/KEiPC28NnRAEHf+SxYMb7ck3KTT xySvFSWT25bwwmtYcopEJ4knmnhIFGxBT/d0BMtA6IX4Nyeph5fC7F7MK38aC3wR2nh1ymlG4Un B8SmFbZObpKp6ZteCGs9afOdGolWqqnJrN8h/KXlB9G3vgEHfzVO7r7QkA4MnvA9pKgU/ZWoISw th+4uYKg2ujGTDoAPFkG0JSBpjdjx3YYqmZyg9ewzOpVCI3k2zZUyW2nc2zg4rjjI4fcci0Y1TY DGpVT8PaEgwmp2dqEZwJJgCh78NiQInmlFTzXHFhEiTbSwctk+9KwbhC56sn8NBYrtkOsV4Q56O Ij6O4pDbYdN61/8XOC0Pu0znbZ7Ddj5lQPaskLt+Pwya/oKvzte6qOmJ+AqlwFhts/xm8ldK4GJ kNfuJpFHFjJrLezq+cQOa0etleEQS84KyhJ2TR2qIkd1FMfEJ8pQMWhhf+UzgQg55OGXeOrnp9E 9Ib5IaLb6k/23YTZFGPXDyqaGiyS58CDYTVTJd287082PPV7Q== X-Received: by 2002:a05:6000:2c0b:b0:487:342:d143 with SMTP id ffacd0b85a97d-4871e269474mr20053433f8f.33.1790088499911; Tue, 22 Sep 2026 07:48:19 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 16:48:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/6] xen/riscv: make Svpbmt no longer a required extension To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Alistair Francis , Jan Beulich , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Anthony PERARD , Andrew Cooper , Michal Orzel , Connor Davis References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9fe1000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ebf023/1790088500-C10DDB50-224D5D3A/10/73395122804 X-purgate-type: spam X-purgate-size: 6414 On 9/10/26 11:34 AM, Baptiste Le Duc wrote: > Without the Svpbmt extension, memory attributes (such as cacheability and > ordering) are strictly tied to physical address ranges and enforced by the > hardware's Physical Memory Attributes (PMA) checker. > > In this configuration, supervisor software relies on the platform's memory > map: > - peripheral device registers (MMIO) are physically mapped into > hardware-defined I/O regions (which are implicitly non-cacheable and > strongly-ordered) > - regular RAM is mapped as cacheable main memory. > > S-mode paging can safely map these physical ranges without specifying > page-based memory types in the PTEs, as the hardware MMU and PMA pipeline > will correctly bypass caches for MMIO accesses and use caches for RAM > accesses, based on the target physical address. > > Furthermore, on platforms that either feature fully hardware-coherent DMA > or don't expose non-coherent DMA agents to the OS, page-level programmatic > cache control via Svpbmt is not required, making it safe to boot and run > when Svpbmt is absent. > > Drop Svpbmt from required_extensions. Introduce svpbmt_enabled, a > __ro_after_init flag computed once in init_csr_masks() from ISA > availability and the henvcfg.PBMTE bit. Xen cannot read menvcfg.PBMTE > directly, since menvcfg is M-mode-only and unreadable from HS-mode, but the > spec guarantees henvcfg.PBMTE reads as zero whenever menvcfg.PBMTE is zero, > so checking henvcfg.PBMTE alone is sufficient. Use svpbmt_enabled in > pte_pbmt_nocache()/pte_pbmt_io(), two new inline helpers that mask the PBMT > encoding down to 0 when Svpbmt is unavailable. > > Also switch vcpu_csr_init() branch to determine if Svpbmt was enabled to > svpbmt_enabled as it does the same logic. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > > --- > Changes since v1: > - Replace the pte_pbmt() macro, which re-checked > riscv_isa_extension_available() on every call, with a svpbmt_enabled > flag cached once in init_csr_masks(). > - Add pte_pbmt_nocache()/pte_pbmt_io() inline helpers instead, used by > PAGE_HYPERVISOR_NOCACHE/WC and p2m_pte_from_mfn(). > - Switch vcpu_csr_init() to the same cached svpbmt_enabled flag instead > of re-deriving Svpbmt availability itself. > --- > xen/arch/riscv/cpufeature.c | 1 - > xen/arch/riscv/domain.c | 10 ++++++++-- > xen/arch/riscv/include/asm/page.h | 22 +++++++++++++++++++--- > xen/arch/riscv/p2m.c | 2 +- > 4 files changed, 28 insertions(+), 7 deletions(-) docs/misc/riscv/booting.txt isn't updated. > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > index 19454544a7..986a6dec78 100644 > --- a/xen/arch/riscv/cpufeature.c > +++ b/xen/arch/riscv/cpufeature.c > @@ -158,7 +158,6 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = { > RISCV_ISA_EXT_DATA(zifencei), > RISCV_ISA_EXT_DATA(zihintpause), > RISCV_ISA_EXT_DATA(zbb), > - RISCV_ISA_EXT_DATA(svpbmt), > }; > > static bool __init is_lowercase_extension_name(const char *str) > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index 2819ff4e7c..f6f20824e3 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -47,6 +47,8 @@ static struct csr_masks __ro_after_init csr_masks; > #define HENVCFG_VALID_MASK 0xe0000003000000ffUL > #define HSTATEEN0_VALID_MASK 0xde00000000000007UL > > +bool __ro_after_init svpbmt_enabled; svpbmt_enabled controls Xen's own stage-1 page tables, but it's defined in domain.c (guest CSR setup) and declared in page.h. That's defensible, because the value is computed in init_csr_masks() from csr_masks.henvcfg. It would still read better in cpufeature.c, with the declaration in cpufeature.h, or at least with a comment next to the definition saying why it's in domain.c. > + > void __init init_csr_masks(void) > { > /* > @@ -79,6 +81,10 @@ void __init init_csr_masks(void) > INIT_RO_ONE_MASK(HSTATEEN0, hstateen0); > } > > + svpbmt_enabled = (riscv_isa_extension_available(NULL, > + RISCV_ISA_EXT_svpbmt)) && (ENVCFG_PBMTE & > + csr_masks.henvcfg); > + svpbmt_enabled stays false until init_csr_masks() runs in start_xen(). Any ioremap(), ioremap_wc() or p2m MMIO mapping created before that silently gets PMA instead of IO. Nothing does this today; setup before that point only uses PAGE_HYPERVISOR_RW. Consider an ASSERT or a comment in pte_pbmt_*(), or setting the flag earlier, e.g. right after riscv_fill_hwcap() (if it is possible, considering that you are using csr_masks.henvcfg probably it can't) . > #undef INIT_CSR_MASK > #undef INIT_RO_ONE_MASK > } > @@ -97,8 +103,8 @@ static void vcpu_csr_init(struct vcpu *v) > */ > v->arch.hcounteren = HCOUNTEREN_TM; > > - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) > - v->arch.henvcfg = ENVCFG_PBMTE & csr_masks.henvcfg; > + if ( svpbmt_enabled ) > + v->arch.henvcfg = ENVCFG_PBMTE; > > if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > { > diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h > index 1977634efc..a7d087ff52 100644 > --- a/xen/arch/riscv/include/asm/page.h > +++ b/xen/arch/riscv/include/asm/page.h > @@ -11,6 +11,7 @@ > #include > > #include > +#include Do we really need this? The helpers only read extern bool svpbmt_enabled and don't call riscv_isa_extension_available(). Adding the include only widens the header dependencies. > #include > > #define VPN_MASK (PAGETABLE_ENTRIES - 1UL) > @@ -42,7 +43,21 @@ > * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > * 11 - Rsvd Reserved for future standard use > + * > + * These bits are only meaningful when Svpbmt is enabled. Otherwise they must > + * stay 0 (PMA). > */ > +extern bool svpbmt_enabled; Shouldn't be here an empty line? Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:50:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:50:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429078.1652018 (Exim 4.92) (envelope-from ) id 1x91p2-0004Ht-CW; Tue, 22 Sep 2026 14:50:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429078.1652018; Tue, 22 Sep 2026 14:50:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91p2-0004Hm-8y; Tue, 22 Sep 2026 14:50:16 +0000 Received: by outflank-mailman (input) for mailman id 1429078; Tue, 22 Sep 2026 14:50:15 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x91p1-0004He-9O for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:50:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91p0-00GLD4-MG for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:50:14 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2959b-8faa-0a2a0a5109dd-0a2a4505e8fe-28 for ; Tue, 22 Sep 2026 16:50:14 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab295a6-4cb1-0a2a45050019-4a7de14c96fe-3 for ; Tue, 22 Sep 2026 16:50:14 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f633cd78so7832f8f.1 for ; Tue, 22 Sep 2026 07:50:14 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48862775412sm5638432f8f.10.2026.09.22.07.50.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 07:50:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790088614; x=1790693414; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HlqJcAaLUHpOAKZ2E3y2oDjiN8GgNL8j6yICFQt86Vg=; b=JPKosG4FduEInV+o5oUTNRPYqCqcN5ZQ/SKZ3ffZ6Q++vCySHJeXY9Dkaz0SEwiFFZ T3h1rlBnadgWSsU+rGDCRY388XPNuAmSMyj3RvHUsgck5vcuE40uLc9+11SruxnofnYN q6Bl9luZa5XUuAM3Mq6GvVMhKb4rIm6OqGgLbGuwIQeEe+FUMFzxewYh6hbQT4Pk/xXZ ZHy7rinaSBr/3XuJBkcoDbGWZqWneJH8KFrBrpCAnIUFU0APml1/vo+4yz5eCRvaU3KY YjGkxYtRs45W9cycQfN5kcjba19zP4sjQllVjbVU1pqIcG17DtxtuslVhFvBvOjxYOn3 y4nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790088614; x=1790693414; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=HlqJcAaLUHpOAKZ2E3y2oDjiN8GgNL8j6yICFQt86Vg=; b=g0MnpHJKVxxA6TnjjUZgn7JpFNIW4AiUeYSn958C2iy1pOLOsP38ALtfwArKEck9je 2Ws6zmdWa/1RrVOeWeR6Cd2PMfULn0uJjo67JAPGxqaVanId8z3rwarS3tIrTzLswz5M XiTr1fwFe5QanyXlrgUSI7C5g6nThHBiN4CrI7KRcWXA/YTNbgBnlu8wTxMB/be6tYPO cPKVZdCMZBalVupUTNGV/zR7Yi4Oxpm87wYPTgjr16FIy6Pno8LiNC498TVXuPrbYqDW CLejyLDijhceuONVXCs/6zogGiYLmcVeUfVBhfs6MJVLaDRfKdGJ16+rrYFQ1PYhdE7o pX5w== X-Gm-Message-State: AFuF++mvcx0EwuLeP/+zmE8WbS5xelcZ9wn4SCMHldiJjyEZY/wlXidg z/II8XMqkO47UhX20q2o14IsJVgk9nCNWRC89MlQJxaxX4PkfeYMwqyv X-Gm-Gg: AYBFou0dOLfcV5hBenfo8QFVEd07A6azxW+sZ9wRzvEzRQf/ZQv7UR8nhnz1W7EmuJy a68c7UwOOUsB/LL29acCa4eDksf84JYnqkI+8YF1RAK8E6fCmfXIMNG/Je8lo/YLiEaAwaAz16a od2kncNTHKdhSt0QfRAoyPIH/ZQGW+Ki6kAvxpmorD6yhxOK8IKBYv9Kb3QEbw1aPyh1lJH7kuH FTHDHShdv2glP2aBnFvRZF0ltsuUrOc53k5dD1HxYH86OFBBCoisPKHHX2Mlk9qwaqTF70hh9Ar A1eH8JFAtbEs1Z1fMAXkUDIbs+gxf4WXVJp5IS2zpvKVAuVbqFnXYLoBE+VL/Ix/js7zuH0YL1D RpZy7usU9oY0er3Bbv1h9nHfzKLFLKpZBHF3qpo3NvNhA02KVzgWmUwH7l25o60iktCn/NfXwX/ a+9w2XgzoLiva0mXsBG3SzNREiZQxDopvO9fDkbaLPuTB8RCshxjV+ulFBwiHqVcTBy9gW59DrA vKDiYw02G5NNuDMpqgsRYAWRSvkRH7Z+A7GDHv0risKtXtwFg== X-Received: by 2002:a05:600c:46cc:b0:493:f5bf:4dc6 with SMTP id 5b1f17b1804b1-49fc566951dmr197506265e9.7.1790088614004; Tue, 22 Sep 2026 07:50:14 -0700 (PDT) Message-ID: <69cdf366-06bc-4989-b060-935c9e0c8a4e@gmail.com> Date: Tue, 22 Sep 2026 16:50:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/6] xen/riscv: make Zihintpause no longer a required extension To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Jan Beulich , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Anthony PERARD , Andrew Cooper , Connor Davis , Alistair Francis , Michal Orzel References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790088614-73EB92A1-82AD5A61/10/73395122804 X-purgate-type: spam X-purgate-size: 954 On 9/10/26 11:34 AM, Baptiste Le Duc wrote: > required_extensions[] panics at boot if Zihintpause is missing, but Xen > never actually depends on it: cpu_relax() only emits the "pause" hint when > the extension is implemented, otherwise it emits `0x0100000F`, a legally > valid FENCE instruction (`FENCE W, 0`) rather than a native NOP. FENCE is > guaranteed by the RISC-V base ISA, so it never raises an illegal > instruction fault. With an empty successor set, it enforces no > memory-ordering constraints and thus architecturally behaves as a NOP. > > Drop it from required_extensions so hardware without Zihintpause > still boots. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v1: > - rewrite commit message. > --- > xen/arch/riscv/cpufeature.c | 1 - > 1 file changed, 1 deletion(-) > Please update also booting.txt? Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:50:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:50:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429084.1652025 (Exim 4.92) (envelope-from ) id 1x91pg-0004uz-KL; Tue, 22 Sep 2026 14:50:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429084.1652025; Tue, 22 Sep 2026 14:50:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91pg-0004us-HC; Tue, 22 Sep 2026 14:50:56 +0000 Received: by outflank-mailman (input) for mailman id 1429084; Tue, 22 Sep 2026 14:50:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91pf-0004uQ-Ls for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:50:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91pf-004s76-2p for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:50:55 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab295be-bab6-0a2a0a5309dd-0a2a450c94b8-46 for ; Tue, 22 Sep 2026 16:50:54 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab295ce-f479-0a2a450c0019-b9ff1c229469-3 for ; Tue, 22 Sep 2026 16:50:54 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c99927a900072c4.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 14:50:52 +0000 Received: from bazzite.gpn.vates.fr (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id E526081F18; Tue, 22 Sep 2026 16:50:51 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=6eAo7c3MG+C8Ech4IV5+ANE4e8iZF0V92ih6APaMRjQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=VtxwEOWlZpXeHFNCFRKbPCEIoQP7ANYGz2BQ/QkxeyU3upwSv5sWgGVIT9192AIeUYzf9Hy/J UqjX0qoOpv9Tjkx47NjaP7gRtPG/2OwdEftFJmzuAVKLfihlFNmJCeIGcehwuRkR0ffBP2dkgqd Pbom58bjD6vji+kmeBkzs3jg14xGnczaGjBMkjjFTX5J43rleA/Mx/npUrrnCRzIAe1Vdsi5U5I 2VSdw6awok2rW66psKxZjm9Ew0sSC0YFW00/2e6u7xfWE1c3uJqBxyL67yJwyaXd9dB08iDDhHv XEclZlMD3W0vTK8YSrVNDHA6aQzgs/Ast2AGAaJ2PTlg== X-Zone-Loop: e0b49ee9af5f70e319e5ab6c82a81cf8e5f47b43d7fd x-campaign-type: default x-transaction-id: 6f8a17f6-adcb-4b38-a56f-61183e8e2d81 x-swg-uid: 01-f19ef4d7-e8b9-4d0b-83a9-3ece3b2af384 X-Mailer: Sweego Message-ID: <1790088652.8631fc262581453bbf619ec5b2062170.1a0c99927a900072c4@vates.tech> x-swg-bid: 1790088652.8631fc262581453bbf619ec5b2062170.1a0c99927a900072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Teddy Astie To: xen-devel@lists.xenproject.org Cc: Teddy Astie , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] vvmx: Handle INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL properly Date: Tue, 22 Sep 2026 16:50:17 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.33b.b627ffca3605a2ed.1a0c999255e.5e92ecd46a17f789=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790088652131 X-purgate-ID: tlsNG-d25034/1790088654-02CDBA5B-60BFB5A5/0/0 X-purgate-type: clean X-purgate-size: 1216 ---=Part.33b.b627ffca3605a2ed.1a0c999255e.5e92ecd46a17f789=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The feature is already advertised in NVPID_CAP_BITS, yet the handling in nvmx_handle_invvpid() was missing=2E Signed-off-by: Teddy Astie Fixes: 9ccf55307868 ("nVMX: virutalize VPID capability to nested VMM") --- xen/arch/x86/hvm/vmx/vvmx=2Ec | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/hvm/vmx/vvmx=2Ec b/xen/arch/x86/hvm/vmx/vvmx=2Ec index e2407f07c2=2E=2E9be8b0067f 100644 --- a/xen/arch/x86/hvm/vmx/vvmx=2Ec +++ b/xen/arch/x86/hvm/vmx/vvmx=2Ec @@ -2053,6 +2053,7 @@ static int nvmx_handle_invvpid(struct cpu_user_regs = *regs) case INVVPID_INDIVIDUAL_ADDR: case INVVPID_SINGLE_CONTEXT: case INVVPID_ALL_CONTEXT: + case INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL: hvm_asid_flush_vcpu_asid(&vcpu_nestedhvm(current)=2Env_n2asid); break; default: --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.33b.b627ffca3605a2ed.1a0c999255e.5e92ecd46a17f789=--- From xen-devel-bounces@lists.xenproject.org Tue Sep 22 14:59:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 14:59:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429095.1652034 (Exim 4.92) (envelope-from ) id 1x91y0-00078J-CG; Tue, 22 Sep 2026 14:59:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429095.1652034; Tue, 22 Sep 2026 14:59:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91y0-00078C-9S; Tue, 22 Sep 2026 14:59:32 +0000 Received: by outflank-mailman (input) for mailman id 1429095; Tue, 22 Sep 2026 14:59:30 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x91xy-00076v-PY for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 14:59:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x91xx-0069bK-CA for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:59:29 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab297b1-2eae-0a2a0a5409dd-0a2a450ae9b6-44 for ; Tue, 22 Sep 2026 16:59:29 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab297d0-f2d2-0a2a450a0019-4a7de18cd74a-3 for ; Tue, 22 Sep 2026 16:59:29 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ccf3ca626so22383505e9.0 for ; Tue, 22 Sep 2026 07:59:29 -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-49fddf841e7sm1726655e9.2.2026.09.22.07.59.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 07:59:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790089168; x=1790693968; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=YgIbgXcm41PbxwTucIV3LnFdNM08SG21o/OLExwN6oM=; b=LZySI/9UdfsL4pdj5EdwN+uGgBE0GKbdotjOq/373u42Ctd2varxsi2hhyJWWX1KUG eC2nAy7Ck5nC3icGsqdqX/oVpiNpL89ZoxQqyVYKfV59/bghF/MytOZK4FcLglWhTuRs QZP5m+wWRb2okjt9a40cM9tSDnlDj3w3aRXRAUmhWq+v/6rNzoWC5q410C9SBmHm4cNY aDBeF8r9BYyoyfEz4Qaqte6YwDwccQ2lxTwqY3HWObRQy4ShUwuClujDQIj8ZklxmYwH 914xDgrYDLlNTrangkUYeEoZ4CGEGkTctjXKqwiUyD8ux4U4DJGBo3/XjvklJihhNdfo uM8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790089168; x=1790693968; h=content-transfer-encoding:content-type: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:content-type; bh=YgIbgXcm41PbxwTucIV3LnFdNM08SG21o/OLExwN6oM=; b=NrMIVeUGBvrlAohXQV82OlXz0g4L7l+sHwn/UBTdDTXawUAENIjZFrQjfdg01yAdo5 q/V2ALhVOmfOMvQIdUp0KlHhydBOeguYiN7e6z8DWm9F1oDuaSWCKnaIE0ZpV1E0nJzi gp2cwKO/h9eGrh9N3Y63w+/FHIiJ8FkCg/0Ud+SRzlqt8Pvy4g9ZCrQyTmKzp/izrIHG mgO3ViP7p8dwly/17UKoae/nqRs9r5yexAyrFSkJyGTImkk6MeS6reGjq3HTSEzgi6zK 9sAnJqpOoVSbqYSBCZ2OXx8WUbHfpKCLjyoTjlPMHYHScFf4p1ZG5YBIaO3Bu5+VVFcU jS2g== X-Gm-Message-State: AFuF++nNxuaApt9b1stAhNWXN6aRnmDFqzWy7+y5rfh1/edYMucxR/Wb BOnmWV4Lk8Ct6EKvvnYqAlq0QBGwSowTIzGk3oIGZGJtqgkR2cKema6M42n+urTjpQ== X-Gm-Gg: AYBFou0gdQiF5fMLWgq8mobR+9hBkcub7UKzpPNrIbZkd835Q9ZNGviMEDjNYHgtatQ eA6SXJm2tDo1UIwAmbBirPyrNdWeyVu/Naa1lqnbobswZyWbqN0eyVOH0N16bpSxiAERAUZliQx IXJUJ3GDkue4Tr5JPt9iuAePAOgsNqC8IbC53y9HsSGHdWGSdwOv3sJUrMmeGzvm5MeKA53DnSF iY41yt1p1MQNjIFpBPYwOlVld7PeZ/QY+eC73mA/m8RjOeX4gDmwgfEsO8fWTY8xkXgAMHzQ+l/ Cera9l7R1anqD0qTjG98QjelPcYDLk0JHgmVkodEjZfERyh/ywqavI4ZSSoekIDqphCCPo6+8DX AfrWdqLm2nLVuAftivkjM6fz3doS1PLP1l2AZZ3v7xi9alcP6+/voZm5npcoOh4SMNJHuo36ajS aNv1GlzYPgxJK5ETvSM5YvHjeZL8O3BOxyPGJRWMnnV//qo8zuTZZ2ff/kA8+kiLiFCmScYh0oX mmmsxVctwIlPvFw/Z9VQbKYUHTMGr6UafT+Ldg6oSCezfGM5UgE66ENz/uo0AM= X-Received: by 2002:a05:600c:46cc:b0:493:f5bf:4dc6 with SMTP id 5b1f17b1804b1-49fc566951dmr197897205e9.7.1790089168501; Tue, 22 Sep 2026 07:59:28 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 16:59:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] x86/pass-through: defer event unlock in pt_irq_create_bind() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie References: <7618c144-2f4a-483c-b078-0d9100b9f251@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: 8bit X-purgate-ID: tlsNG-4011c0/1790089169-5A5DBCFC-986357FE/0/0 X-purgate-type: clean X-purgate-size: 2182 On 22.09.2026 15:37, Roger Pau Monné wrote: > On Tue, Sep 08, 2026 at 03:01:27PM +0200, Jan Beulich wrote: >> The radix tree holding struct pirq * as obtained by pirq_get_info() is >> protected by the domain's event lock. The result ("info") and the derived >> "pirq_dpci" therefore may not be de-referenced past the dropping of that >> lock. Moving the unlock down is safe, but perhaps not obviously so: >> - vector_hashing_dest() does a memory allocation, but core event channel >> code does so too while holding the lock; the call to >> vlapic_match_dest() doesn't involve any further locking, >> - hvm_migrate_pirq() operates on the corresponding IRQ descriptor, where >> obtaining of its lock is of course fine (those locks always nest inside >> the event lock), >> - {hvm,vmx}_pi_update_irte() are very similar to hvm_migrate_pirq() >> locking-wise, >> - the locking around guest_mask_msi_irq() is the same as in the earlier >> two bullet points. >> >> As long as the PCI-devs lock is held around both >> pt_irq_{create,destroy}_bind(), this is only a latent issue. >> >> Fixes: 35a1caf8b6b5 ("pass-through: update IRTE according to guest interrupt config changes") >> Fixes: 1066331913c9 ("passthrough: don't migrate pirq when it is delivered through VT-d PI") >> Fixes: 782cf8ba4678 ("pass-through: adjust pIRQ migration") >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. >> Seeing that the IRQ descriptor lock is taken up to three times in a row, >> I wonder whether we shouldn't consolidate this (by obtaining desc once and >> then passing it into hvm_migrate_pirq() (or a suitable new sibling >> thereof) and hvm_pi_update_irte()). > > Possibly? I haven't looked what would be the adjustment needed on > other callers. Just passing the locked irq_desc? Yes. Yet in carrying that out I realize that calling iommu_update_ire_from_msi() (out of vmx_pi_update_irte()) with the lock held is perhaps more risky than I'd like it to be. With limited effort I couldn't convince myself that there might not be a lock order inversion issue somewhere. Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:06:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:06:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429111.1652043 (Exim 4.92) (envelope-from ) id 1x924K-0001jw-2d; Tue, 22 Sep 2026 15:06:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429111.1652043; Tue, 22 Sep 2026 15:06:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x924K-0001jo-05; Tue, 22 Sep 2026 15:06:04 +0000 Received: by outflank-mailman (input) for mailman id 1429111; Tue, 22 Sep 2026 15:06:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x924I-0001jd-Hq for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:06:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x924H-00GvRU-Gr for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:06:01 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29953-2eae-0a2a0a5409dd-0a2a450aa820-16 for ; Tue, 22 Sep 2026 17:06:01 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29958-f2d2-0a2a450a0019-4a7de18cb209-3 for ; Tue, 22 Sep 2026 17:06:01 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49e620fa473so26431255e9.1 for ; Tue, 22 Sep 2026 08:06:01 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fdaa99b8bsm42639685e9.1.2026.09.22.08.05.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 08:06:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790089560; x=1790694360; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=SUTJHHO7QDYKSxYCbxvAq6JYc+Al10jTRuWWtUcd/u0=; b=G3iGGFmCccA5BNK7eSE87eg//+jHqkP+uqvBL8fx5I8toHPVtOFZuQwnt//O4OYRnr QMfBnr4Gdi1FLcpJHRFtY/LLsn7a4kuXVk/5OOq0I5Le5sIl1PKtHN+O7hRYvSgwhjaL 3nUR/cN/3mmj9ijZqNoi4ssoTbnIdgIVtrG+GjFotBzKfsd9MVJcbzZ9RF6/jGuXOLKW wFKjT0OL908JxrjCLjfVDYf/qe2oC0bhp54H57pyYgzclmjnqrQs7/edHnkNamayreZm lgZNUlvx+wA5cN9ZvzRULzQVcK6/SEKFjg/kjotqTu1TvgBmcN6OSE1H3GaRrKJWy7Q0 vBmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790089560; x=1790694360; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=SUTJHHO7QDYKSxYCbxvAq6JYc+Al10jTRuWWtUcd/u0=; b=GygN+274+vtBvMmukZDsw9mbwznj+7407aPack3KR7OXQk56MMlWUDiLWojtAgKl3t lKx2PYPcoj6J7K0ZVG8SiBZxDgo61gCYRWbTAE4gOcrf0I61HGltzkTkZ4l987oHEW5H YdkqplFOzoONjR0j2ssxcAB3D8V9leVOKWp/1HUmz6qK1rwNCvAcav8paI3XY1nI+J6f PemuPGLZI5S0nEVUDbJwWoY+8b12cO1rKtN0AP58ABqv1+xwsiI1gzxDTGcV4j1LPIG8 mgKVTQUSZwFngPDDUy6svNZCf+rwUf+ozvyofg64h3Uu0dMoNtztFO1UWCP9QKT+CjTj +cLQ== X-Gm-Message-State: AFuF++kzhwOfuOy9qYhGcGsX2ucP3zkVLVMvInsCRnM2VBL90wi7b1tc HmEZ6MBOPPI8GuFISCRtfNzo9nT8hCue4JAwYpQRFwqnUu9b3sD32yPm X-Gm-Gg: AYBFou1mjIFgo199178rdnzPVHN1HS9grpNtFyZgS8NLdwwj6gP9sgUVt3AMPb/OxPc JAfPh0lAaG2hgr5PzamqZTquFi9fIx3HMHO7+pUrf4xB4FC96Z1EEoB001xiVcUae/GPoFp376x yJyhQwmss6oiMsVAq582XTZohYZ4UwlPiG/stJ2IcABsdiGep/uRet4F23am0cFjgTOS7ZAS9Ay ucW20D0XKUEctPGU+k8HKTbz3IVZVL80rpfckU5UbJNlCqR1EHTxUZsKbso+tofnDQi0rtSjO64 UdmqWf+D2N/jqIHWldX0kg2UMHOVGA+R5H5YTDWyoAUM6xugXARlslZzTYEIpSGVChP7y0PPL/0 U0wRY2G1zSxSAor4EeczZ/5Ukr1LRSvf8cGYhnMipvzmFU+LIm+rh5LA789clRc4SsjPS9T1mWF yfI9Kswbz6DBGWvZqn11LgYSF9uRIiS7dAjlK2vrHDS2SAy5gVIKtzR8fYdmMltUUrqCr6ro3/d j/ROvN/Dyk1G3u7N/73t6TyJRlPHj9xLjmUsOYKGcG16NEGqA== X-Received: by 2002:a05:600c:3f0b:b0:49d:1df6:2592 with SMTP id 5b1f17b1804b1-49fc5750c61mr177979385e9.21.1790089560413; Tue, 22 Sep 2026 08:06:00 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 17:05:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] xen/riscv: set A/D bits in Xen's page-table mappings under Svade To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Julien Grall , Connor Davis , Alistair Francis , Anthony PERARD , Andrew Cooper , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Michal Orzel , Jan Beulich References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789032898.8631fc262581453bbf619ec5b2062170.1a08aab9ea7000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1790089561-5A1DDCFC-524FC852/10/73395122804 X-purgate-type: spam X-purgate-size: 6062 On 9/10/26 11:34 AM, Baptiste Le Duc wrote: > The previous patch set A/D bits in case of the Svade extension for G-stage > mappings. Xen's own S-stage mappings need the same fix as both > setup_initial_mapping() (the boot page tables) and arch_pmap_map() (the > fixmap) build leaf PTEs directly instead of going through > pt_update_entry(), which is what adds A/D bits. So with Svade, both would > fault on first access. Please don't refer to "the previous patch": once applied, the commit message should stand on its own. Just state the fact instead, e.g.: With Svade, hardware doesn't update the A/D bits; instead it raises a page fault when A is clear (or D is clear on a write). pt_update_entry() already sets them, but ... > > Add PTE_ACCESSED to all PAGE_HYPERVISOR_* and also PTE_DIRTY to > PAGE_HYPERVISOR_RW as it needs to be set during a write to avoid a fault. > This fixes arch_pmap_map() for free, since it already builds its PTE from > PAGE_HYPERVISOR_RW. Switch setup_initial_mapping() to use these macros for > its default, text and rodata permissions, and for the temporary root entry > built by check_pgtbl_mode_support(), instead of the equivalent raw bit > lists. The latter drops PTE_WRITABLE, going from RWX to RX, but this is > harmless, as that entry only has to make the current instruction stream > fetchable between the two CSR_SATP writes used to probe SATP mode support, > and nothing writes through it. > > Drop the now-redundant PTE_LEAF_DEFAULT, since converting the last > open-coded site above leaves it with no user outside page.h itself. > > A PTE is a table entry iff PTE_VALID is set and R/W/X are all clear, so > update pte_is_table() and pte_is_mapping() accordingly. This doesn't describe what the patch actually changes: the return expressions of pte_is_table()/pte_is_mapping() are untouched, only the ASSERT()s change. The real reason is that the ASSERT()s masked the PTE with PAGE_HYPERVISOR_RW, which now contains A|D, so for the reserved encoding V|W|A we would compare V|W|A != V|W and the ASSERT() would silently stop firing. Something like: The ASSERT()s in pte_is_table() and pte_is_mapping() mask the PTE with PAGE_HYPERVISOR_RW to detect the reserved W=1,R=0 encoding. Now that PAGE_HYPERVISOR_RW includes A/D, the check would no longer trigger for a PTE with A or D set, so use an explicit V|R|W mask. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v1: > - change commit title > - mention in patch message that arch_pmap_map() is fixed too, via the > PAGE_HYPERVISOR_RW change, not just setup_initial_mapping(). > - convert check_pgtbl_mode_support()'s temporary root entry to > PAGE_HYPERVISOR_RX, as it's harmless. > - drop PTE_LEAF_DEFAULT entirely instead of keeping it, now that no site > open-codes it anymore. > - drop the pte_is_table() comment line that referenced PAGE_HYPERVISOR_RW, > now stale. > --- > xen/arch/riscv/include/asm/page.h | 15 +++++++-------- > xen/arch/riscv/mm.c | 9 ++++----- > 2 files changed, 11 insertions(+), 13 deletions(-) > > diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h > index b465a90325..1977634efc 100644 > --- a/xen/arch/riscv/include/asm/page.h > +++ b/xen/arch/riscv/include/asm/page.h > @@ -46,12 +46,11 @@ > #define PTE_PBMT_NOCACHE BIT(61, UL) > #define PTE_PBMT_IO BIT(62, UL) > > -#define PTE_LEAF_DEFAULT (PTE_VALID | PTE_READABLE | PTE_WRITABLE) > #define PTE_TABLE (PTE_VALID) > > -#define PAGE_HYPERVISOR_RO (PTE_VALID | PTE_READABLE) > -#define PAGE_HYPERVISOR_RW (PTE_VALID | PTE_READABLE | PTE_WRITABLE) > -#define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE) > +#define PAGE_HYPERVISOR_RO (PTE_VALID | PTE_READABLE | PTE_ACCESSED) > +#define PAGE_HYPERVISOR_RW (PTE_VALID | PTE_READABLE | PTE_WRITABLE | PTE_ACCESSED | PTE_DIRTY) > +#define PAGE_HYPERVISOR_RX (PTE_VALID | PTE_READABLE | PTE_EXECUTABLE | PTE_ACCESSED) These two lines exceed 80 columns, please wrap them, e.g.: #define PAGE_HYPERVISOR_RW (PTE_VALID | PTE_READABLE | PTE_WRITABLE | \ PTE_ACCESSED | PTE_DIRTY) Also, pt_update_entry() sets D on every leaf, while here RO/RX get only A. Both are valid per the spec, but it means boot-time and runtime mappings of the same kind of page differ in D. Either set D on RO/RX too for consistency, or say in the commit message why it isn't done. > > #define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW > /* > @@ -174,10 +173,9 @@ static inline bool pte_is_table(pte_t p) > * According to the spec if V=1 and W=1 then R also needs to be 1 as > * R = 0 is reserved for future use ( look at the Table 4.5 ) so check > * in ASSERT that if (V==1 && W==1) then R isn't 0. > - * > - * PAGE_HYPERVISOR_RW contains PTE_VALID too. > */ > - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); > + ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) != > + (PTE_VALID | PTE_WRITABLE)); > > return ((p.pte & (PTE_VALID | PTE_ACCESS_MASK)) == PTE_VALID); > } > @@ -185,7 +183,8 @@ static inline bool pte_is_table(pte_t p) > static inline bool pte_is_mapping(pte_t p) > { > /* See pte_is_table() */ > - ASSERT(((p.pte & PAGE_HYPERVISOR_RW) != (PTE_VALID | PTE_WRITABLE))); > + ASSERT((p.pte & (PTE_VALID | PTE_READABLE | PTE_WRITABLE)) != > + (PTE_VALID | PTE_WRITABLE)); Nit: the indentation differs from the one in pte_is_table() (one extra space here). As the same expression is now open-coded twice, maybe it is worth introducing a small helper (e.g. pte_is_reserved_wr()) and using it in both ASSERT()s? Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:10:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:10:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429117.1652052 (Exim 4.92) (envelope-from ) id 1x9292-0004Vr-JT; Tue, 22 Sep 2026 15:10:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429117.1652052; Tue, 22 Sep 2026 15:10:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9292-0004Vj-GC; Tue, 22 Sep 2026 15:10:56 +0000 Received: by outflank-mailman (input) for mailman id 1429117; Tue, 22 Sep 2026 15:10:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9290-0004Ty-GJ for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:10:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x928y-0009nq-PH for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:10:52 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29a72-e002-0a2a0a5209dd-0a2a4507e460-30 for ; Tue, 22 Sep 2026 17:10:48 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29a78-b4ea-0a2a45070019-4a7de18dba37-3 for ; Tue, 22 Sep 2026 17:10:48 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912d8239so30652435e9.0 for ; Tue, 22 Sep 2026 08:10:48 -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-49fdaa4e47csm110344655e9.1.2026.09.22.08.10.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 08:10:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790089848; x=1790694648; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=8jfV5Zs9qAdGqOsefDfzrCrrfCsilXB5G5oCWhUPhqY=; b=Xf6fgc/lOQbV3Fv04mhSU9SwzPuN8TaXk5oFN+qGRPkg56NZeZHEDLDg1U1RMSPLQB wq4DkVfJ/6Fqs2Q7E4cPfsWFZWIqwe96iWl7MSPFpsrJpIgVieAxvVRjbBdIdrgqNceI z6OhMSWmGZB9wbF7r4rwxJXm7rnm16EAxbjQvi7fmDOIY3gV0BURX7eY2YcFAiMNzQWC f2M62uLiFJsvE9/+OywWzGF8O6ryku4PZwdCLUatl9zv9BSiwO/nlZkrwuKfcu5vvpB+ 5XWGRPHk/W2WpAVyW1gXeqLlHzzlthKXdniPj0nlaZVWy9F1l32NDEwUzp2MbfbjP7TJ AF4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790089848; x=1790694648; h=content-transfer-encoding:content-type: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:content-type; bh=8jfV5Zs9qAdGqOsefDfzrCrrfCsilXB5G5oCWhUPhqY=; b=R6/nr50NG9fz3IC5e50IkMSIpV6MpBeglqOrB/nQzW3nlsQx7jf5AlpHvXM8C9ZamN inS/sWXuiqRMng9mL0PMVkljBOfgkpJxj5arzNxSBXIcPAoMiOWVx6rpSpomgHA5+5TT MfzlpQmawfLsFfcgBJYQg0lWh3UbOLFoy8nGpNH8SHtv74JSZWIcelet/LhxfiS6byEc SYwmFlYwRCteLqx1bCnaYsHdLtIXknpgVfaawnPF77m8v7T8omvHLik7tzXEZFZHhceE iGpwSu44yyvUiuEE4uEx6JqHmL2hY08gmozi29jMAVNI4EKbjs2JbHewcRWb4VasOp+j cmWw== X-Gm-Message-State: AFuF++nIln+F7ExmKPigZUb/r5N/NAOh/U/Pq9E1KromMIp2bMGLmkxC icpY8THooLclFU4ErBoT+9Ijebn8b7dUeeWtAu+eHv+q0ZG3wF0RL0YXRpKLTDEf7A== X-Gm-Gg: AYBFou2UZbi3VNhGbd2gMOcr+GT8ay/dtz1VfNhB0q1ruPQddlCHSdZ5/1NVIqhmlW3 nW3y8WaeyGbKN4k7jYEWDcPsO/VVjNIcjX2uV4MHIyGbgZozBjivPe5mCtjT214AupmNfpkur94 IMC8aLUEJVas729U1lutm2Woi2u6MrKyg2pheYSYG7sbYsPUV0wyQcReAsfrb8zCQ+G9da4gU4R JlZvRqq4bePus35+Jdkdt620l57UhD8l37oxHb2ty9nCFClOS+WlKM+vprlho+9HbgQutDk+4HH A0BybWZYXEpp+Mpo+//NHd9zk6V1kgjJtgJcd1rEAx5GpLRFqsxHlbj5edhnrehDKQPQPl8iGQg a3UN4gio0T+z9GKGzxqKqr7ylQJTMEykUckfmgY3Wi4Uc2yKVj5VtCC+uGWKgGGFBok/vPEpMH/ LTNAtpzwsdQWvG+9W6LdjoNkc6z6JYzHkIz7vnhv88boUUnOctfquQkdYFj4b5HcFCkQq/KaHVk ZFpn3y6NVP7bf8MZyBW4XyKFy0txQ9oP0t8vHFge89IAykTplUxEeqgUH7EP2Y= X-Received: by 2002:a05:600c:4695:b0:49c:d019:70c5 with SMTP id 5b1f17b1804b1-49fc55ac96emr214042675e9.0.1790089848006; Tue, 22 Sep 2026 08:10:48 -0700 (PDT) Message-ID: <7d374a65-9786-415b-b869-9899cb05bbae@suse.com> Date: Tue, 22 Sep 2026 17:10:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/6] xen/riscv: make Zihintpause no longer a required extension To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Baptiste Le Duc References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032898.8631fc262581453bbf619ec5b2062170.1a08aaba10f000c4f3@vates.tech> <20c2003f-910b-4e9b-92f4-5298f11f58df@suse.com> <66104177-def7-419e-b6c6-55c3cbc04ddc@gmail.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: <66104177-def7-419e-b6c6-55c3cbc04ddc@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790089848-3C411AE4-E0ED3276/0/0 X-purgate-type: clean X-purgate-size: 2381 On 22.09.2026 16:26, Oleksii Kurochko wrote: > On 9/22/26 2:27 PM, Jan Beulich wrote: >> On 10.09.2026 11:34, Baptiste Le Duc wrote: >>> required_extensions[] panics at boot if Zihintpause is missing, but Xen >>> never actually depends on it: cpu_relax() only emits the "pause" hint when >>> the extension is implemented, otherwise it emits `0x0100000F`, a legally >>> valid FENCE instruction (`FENCE W, 0`) rather than a native NOP. >> >> Just that PAUSE's encoding is 0x0100000F. I.e. what is emitted is always >> the same, and hence discussing the encoding aspect here doesn't help >> justify the change. NOP or not also doesn't really matter here. The >> specific hint encoding looks to fall into what prior to Zihintpause would >> have been covered by "Designated for future standard use", and hence ... >> >>> FENCE is >>> guaranteed by the RISC-V base ISA, so it never raises an illegal >>> instruction fault. With an empty successor set, it enforces no >>> memory-ordering constraints and thus architecturally behaves as a NOP. >> >> ... there indeed should be no concern for any platform playing by the >> rules. >> >>> Drop it from required_extensions so hardware without Zihintpause >>> still boots. >>> >>> Assisted-by: Claude:claude-opus-5 >>> Signed-off-by: Baptiste Le Duc >>> --- >>> Changes since v1: >>> - rewrite commit message. >> >> I fear another round of re-writing is going to be necessary, sorry. > > Would it be better: Quite a bit, yes; just one thing ... > required_extensions[] panics at boot if Zihintpause is missing, but Xen > does not strictly require hardware support for it. ... here: required_extensions[] isn't a function and hence cannot "panic". Jan > The PAUSE hint (Zihintpause extension) is encoded as FENCE W, 0 > (0x0100000F). In accordance with the RISC-V Unprivileged ISA, HINTs are > encoded in the space of valid standard instructions. On platforms > without Zihintpause support, executing 0x0100000F is treated as a > standard FENCE with an empty successor set, which acts as a NOP and > never generates an illegal instruction trap. > > Therefore, Zihintpause is purely an optimization hint. Drop it from > required_extensions[] so systems without explicit Zihintpause support > can boot Xen successfully. > > ? > > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:14:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:14:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429124.1652061 (Exim 4.92) (envelope-from ) id 1x92CR-0005d8-1O; Tue, 22 Sep 2026 15:14:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429124.1652061; Tue, 22 Sep 2026 15:14:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92CQ-0005d1-Uk; Tue, 22 Sep 2026 15:14:26 +0000 Received: by outflank-mailman (input) for mailman id 1429124; Tue, 22 Sep 2026 15:14:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x92CP-0005cs-Vs for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:14:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92CP-008NK7-Ck for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:14:25 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29b35-2eae-0a2a0a5409dd-0a2a450ac320-48 for ; Tue, 22 Sep 2026 17:14:25 +0200 Received: from [74.125.225.92] (helo=mail-wr2-f28.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29b51-f2d2-0a2a450a0019-4a7de15c8075-3 for ; Tue, 22 Sep 2026 17:14:25 +0200 Received: by mail-wr2-f28.google.com with SMTP id ffacd0b85a97d-485b1d2874aso31448f8f.1 for ; Tue, 22 Sep 2026 08:14:25 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48862774882sm5936376f8f.13.2026.09.22.08.14.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 08:14:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790090065; x=1790694865; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wctz8bQ99T0MRcz2ZfNR4ChcDuX77qBnwjNz/nlSGVc=; b=WOH/j38DOEB3EPalEZGWYH0q/0gBVTI4giSr8d8PBWueUIOPPv9wx1ZGwTDe/PBH49 b27ui5OdugpeDizv9SPB58saBb9LKB4prjyi6/1n198kkPqE8VjVQLFBPb5DyshAMsH2 6ywR4bioSMfqyQOQ3B6GGVskapVD/gLST/nXpqqNR4zvE2qCnYV4pJsU/0pFAMCDNRnf aF5qCaA3GwlSuOI+AX+47YhTWYCLso4rV8cLhTeZwH6a6J+vHHx1jKGWGUflVoi3yrp+ FsPC9MfIunEvnHZyoh2DBQSz5gkqkp2Dnanr09ikCDtgdfAmPO9Z+LiLb2mYmsrjegHr RxIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790090065; x=1790694865; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=wctz8bQ99T0MRcz2ZfNR4ChcDuX77qBnwjNz/nlSGVc=; b=tF9f9LYjkpcq5VCo1zS9EmfV9Z8ZuxUy6buyJYvZrCENEPvs2cUVYcicl3iR+ZbHg6 EV9fOyHtQkTG18fzPPIEJfte9FPZedntUXoeHYEk1wx1f0HEpqBsLlEK42KWRfs2LndW OfGClqr5JQz0fVBxfq4aUQsQ3/YT9UjjZKlLoGIjwH+iGrnH7zWAZE6qwn4av+Cy8uDB tTfAqtAOelne1Bt6nXKj6er+SdYsUysVPoGRkDjaFLj9x6JOSe51DUU+itqu2+ZClUcd J6IW0/8t07I35toJPZBKEG/Bj0JKwc9MZouRSGBQbDMEtWmoyfPw2Qnu6EaNCYaSxHm5 +Gxw== X-Gm-Message-State: AFuF++k71J7K+CcLmq12U0eNoaXKylvFFbLTP0wbkiQFOF2AaHUM/HKu JYVJbnV1u/9+0M5jV+xqec4Rm8u4ZyY+xCu9mhqK8ahCIKMKFwF3zq3J X-Gm-Gg: AYBFou32pmruW6ttTK6QUOl5t/h6utfhyt7Q9Bt5x/o/1NIA9ZKzPMNCiXQmMHdoIvg CF9GsTj6vuKIM3V9RaJc3JP1zALAEpEPNR15ZBF8NRJPVVBkGo1oVnop1qBylTPkFf69auFRdhQ /Yanittx94U55lDp7enXzoJuZQWhwOOSHkNDm9UZENutFmTQS3LUyH9eBzd+apo2LjVXTr7C5m/ FHixM+fopPqZyUmtIEtmXn48d++fl2CeRncdC4hbU8jkbJtpgOC0CDxTXGVv0QBE27haZRA56CJ 7OI8EWu8X7SzKZd3eKGQiDplr64XymdFizZdmXfyj9sIinuxcmO2x6RQtvdD/9KH4+htkgdsRe4 K4zXCfPw2xjKDCjudEfq2O9uc+y+f29UMwmBNhVMNJ8mT/wq3Oy5P1nFUQiFRYEHCxbUYp6IG9/ Xt/YpnGElhasdLKxm8+nGpSarnXlPzevEf3CUVQe7cSokXPk+4ftONrPhWiVxubon+WMork1Gjz 14xW9pDGQU4SmVVCO1QkOjZmF76MLd/dZ7Jd4B09kOVStswew== X-Received: by 2002:a05:6000:4819:b0:487:27f9:833 with SMTP id ffacd0b85a97d-48727f90ad7mr15798665f8f.40.1790090064670; Tue, 22 Sep 2026 08:14:24 -0700 (PDT) Message-ID: <48253b42-1b0c-4463-ad0b-01ebed1d8282@gmail.com> Date: Tue, 22 Sep 2026 17:14:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling To: Baptiste Le Duc , Jan Beulich Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> <450d0c5e-2101-4b1c-98fd-2f438bd0ccf3@suse.com> <1790010225.8631fc262581453bbf619ec5b2062170.1a0c4ec74f000072c4@vates.tech> <1790068677.8631fc262581453bbf619ec5b2062170.1a0c868594900072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790068677.8631fc262581453bbf619ec5b2062170.1a0c868594900072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-4011c0/1790090065-583CCCFC-CFA75FBF/10/73395122804 X-purgate-type: spam X-purgate-size: 7202 On 9/22/26 11:17 AM, Baptiste Le Duc wrote: > On 2026-09-22 08:24 +0200, Jan Beulich wrote: >> On 21.09.2026 19:03, Baptiste Le Duc wrote: >>> On 2026-09-21 17:26:47+02:00, Jan Beulich wrote: >>>> On 10.09.2026 11:34, Baptiste Le Duc wrote: >>>>> @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) >>>>> return false; >>>>> } >>>>> >>>>> +/* >>>>> + * Svade and Svadu extensions represent two schemes for managing the PTE A/D >>>>> + * bits. When the PTE A/D bits need to be set, the Svade extension indicates >>>>> + * that a page fault will be raised. In contrast, the Svadu extension supports >>>>> + * hardware updating of the PTE A/D bits. >>>>> + * >>>>> + * There are 4 possible combinations of these extensions in the device tree. >>>>> + * The default hardware behavior for each is: >>>>> + * >>>>> + * 1) Neither Svade nor Svadu present in DT => It is technically unknown >>>>> + * whether the platform uses Svade or Svadu. Xen should be prepared to >>>>> + * handle either hardware updating of the PTE A/D bits or page faults when >>>>> + * they need updating. In that case, Xen assumes Svade because it's >>>>> + * harmless if the platform is actually Svadu, while assuming Svadu on real >>>>> + * Svade hardware risks an unhandled page fault. >>>>> + * >>>>> + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. >>>>> + * >>>>> + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. >>>>> + * >>>>> + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off >>>>> + * at boot time by setting A/D bits. To use Svadu, the supervisor must >>>>> + * explicitly enable it using the SBI FWFT extension. >>>>> + * >>>>> + * The Svade extension is mandatory and the Svadu extension is optional in the >>>>> + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose >>>>> + * option 3. Platforms aware of the profile can choose option 4, and Xen won't >>>>> + * get the benefit of Svadu until the SBI FWFT extension is available. >>>>> + * >>>>> + * In other words, hardware manages the A/D bits on its own only in case 3, in >>>>> + * all the other cases software has to preset them. Instead of open coding this >>>>> + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is >>>>> + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. >>>>> + */ >>>>> +static void __init riscv_resolve_ad_scheme(void) >>>>> +{ >>>>> + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); >>>>> + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); >>>>> + >>>>> + /* Case 3: leave the A/D bits management to hardware. */ >>>>> + if ( svadu && !svade ) >>>>> + return; >>>>> + >>>>> + /* Case 4 */ >>>>> + if ( svadu && svade ){ >>>>> + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ >>>> >>>> Nit (style): Brace placement. >>> Sorry for that. I will fix that in v3. >>>> Furthermore this is written in a way which Misra would call "dead code". I'd >>>> like to suggest (leaving out comments): >>>> >>>> if ( svadu ) >>>> { >>>> if ( !svade ) >>>> return; >>>> >>>> if ( !sbi_probe_extension(SBI_EXT_FWFT) ) >>>> printk(...); >>>> } >>> I assume you are referring to Misra C:2012 Rule 13.5 "The right operand >>> of a logical && or || operand shall not contain persistent side effect" >>> >>> If yes, IMO, I think it doesn't apply here as `svade` is evaluated >>> before the `if` so there is no side effect that wouldn't have been >>> executed in case of svadu=false. >> >> No, there's nothing side-effect-ish here. With "svadu && !svade" in the >> first if(), the rhs of "svadu && svade" in the second one is dead code: >> Things would function the same with it dropped. > Ok, now I understand, thanks. I'll fix it in next round. >> >>>>> + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" >>>>> + "RISC-V: Defaulting to software A/D updates (Svade).\n" >>>>> + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); >>>> >>>> Nit (style): Indentation (in multiple ways). Furthermore XENLOG_* needs >>>> repeating after every newline. >>>> >>>>> + } >>>>> + } >>>>> + >>>>> + /* Cases 1, 2: Xen assume Svade to be enabled */ >>>>> + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); >>>> >>>> Isn't this a lie (to ourselves) then? >>> If you are talking about case 1: >>> [1] Yes, it's technically a lie for boards shipped before >>> the svade/svadu extension was ratified (e.g., HiFive Premier P550). >>> These extensions merely formalized a mechanism that already existed in >>> hardware. >> >> Wait, how do you know this for _all_ boards anyone may ever have made? > We don't know but based on [1] and my commit message, if neither > Svade nor Svadu are present in DT then it is technically unknown whether > the platform uses Svade or Svade. Hypervisor may then assume Svade to be > present and enabled or it can discover based on mvendorid, marchid, and > mimpid. For this patch, I choose to have the Hypervisor assumed Svade. Can hypervisor really access this regs? ~ Oleksii > > Saying that, I agree that it doesn't make sense to manually have set > Svade extension in the isa bitfield as we could just preset A/D bits > regardless of Svade/Svadu during the p2m_set_permission(). It's what > kvm explains in kvm_riscv_gstage_map_page(): > > /* > * A RISC-V implementation can choose to either: > * 1) Update 'A' and 'D' PTE bits in hardware > * 2) Generate page fault when 'A' and/or 'D' bits are not set > * PTE so that software can update these bits. > * > * We support both options mentioned above. To achieve this, we > * always set 'A' and 'D' PTE bits at time of creating G-stage > * mapping. To support KVM dirty page logging with both options > * mentioned above, we will write-protect G-stage PTEs to track > * dirty pages. > */ > > > [1] https://lore.kernel.org/lkml/20240628093711.11716-1-yongxuan.wang@sifive.com/#t >> And for all qemu (and alike) versions which supported RISC-V? > > Concerning qemu, you're right, in case when (!svade && !svadu) they use > by default Svadu (hw updating) for backward compatibility. > >> >>> [2] For boards that do support svade, we could enforce DT >>> declaration by adding it to `required_extension` as they are >>> explicitly supporting it. However, doing so would cause boards >>> without svade/svadu support (as described above) to hit a panic >>> during boot. >>> >>> So in both case ([1], [2]), the svade extension exist either implicitely or >>> explicitly. Therefore, force it doesn't compromize anything. >> >> If, despite my comment above, this is indeed what is wanted, I think it >> requires a little more commentary. >> >> Jan >> >> >> > > From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:19:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:19:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429143.1652071 (Exim 4.92) (envelope-from ) id 1x92Gz-0007Et-LM; Tue, 22 Sep 2026 15:19:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429143.1652071; Tue, 22 Sep 2026 15:19:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92Gz-0007Em-I6; Tue, 22 Sep 2026 15:19:09 +0000 Received: by outflank-mailman (input) for mailman id 1429143; Tue, 22 Sep 2026 15:19:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92Gy-0007Eb-5p for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:19:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92Gx-00Gxo1-3U for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:19:07 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29c62-8faa-0a2a0a5109dd-0a2a4506e6fe-34 for ; Tue, 22 Sep 2026 17:19:07 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29c6a-195a-0a2a45060019-b9ff1c22b1ad-3 for ; Tue, 22 Sep 2026 17:19:06 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c9b2f93d00072c4.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 15:19:04 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id CF0DB81F18; Tue, 22 Sep 2026 17:19:03 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=6Er3KvlK9wQlEJbo46n4FQLJkQHGED7sapa04KUosR4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=e6Rwsh5Tt/OCPP7IAyKzEoqrg9A1DdpJ0tK+CNMdJVILRDMeb6r5Lb4t/DO/a30GuLonLjz3F KmRy808pZSHWD06MtuCfj0FaJFplvvru5vFHOziehIsQ4ktY4kbC2cYmKfAitCm1GXp6BkU4GAK aZQJ0FwpDmPw5cTPqCXPmYTU1j8FZ/3KpyfPum58GSSQVr6yVPepmhLOJaFy33i4JeiNr8inz6e X1QSTKMf8FufVrnOvjMaqPpxbE3WMNtH7so4KyHu1ncHWYfz89oJ/Bstct69iwQai5tGRPHDaVp fEgFj9u8QJ3Agnhavtzp+x8qjYg+A80mnJhQqPGiHfNQ== X-Zone-Loop: ebb2c348a0a70328eeb1a160d0f08838235f334ec288 x-campaign-type: default x-transaction-id: 92b5f6b6-e93f-4cb4-ad77-9e57143bb5a6 x-swg-uid: 01-19b2e30b-c23e-482a-aa4c-436d627a2048 X-Mailer: Sweego Message-ID: <1790090344.8631fc262581453bbf619ec5b2062170.1a0c9b2f93d00072c4@vates.tech> x-swg-bid: 1790090344.8631fc262581453bbf619ec5b2062170.1a0c9b2f93d00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , Jan Beulich , xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <48253b42-1b0c-4463-ad0b-01ebed1d8282@gmail.com> References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> <450d0c5e-2101-4b1c-98fd-2f438bd0ccf3@suse.com> <1790010225.8631fc262581453bbf619ec5b2062170.1a0c4ec74f000072c4@vates.tech> <1790068677.8631fc262581453bbf619ec5b2062170.1a0c868594900072c4@vates.tech> <48253b42-1b0c-4463-ad0b-01ebed1d8282@gmail.com> Date: Tue, 22 Sep 2026 17:18:58 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790090338; l=756; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=7JnbEHPG3MInXHIKWLsIpbgn1y1z2oTX/IsB1PppKOw=; b=kQJVl9GwyB37o+Wo0UytAl4WN7LN5fpEtZlYpT2dwael3v61XwYUnGQmKB0SoO/BvjIMbuwuE QgWXZ1HIjYtCZWlNzPsFPpeOJjiyf+392V+jxAIP/Ijetb9LoEoVlgd X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790090344034 X-purgate-ID: tlsNG-16d1c6/1790090347-FD00977B-2D6551B3/0/0 X-purgate-type: clean X-purgate-size: 760 On 2026-09-22 17:14:23+02:00, Oleksii Kurochko wrote: > On 9/22/26 11:17 AM, Baptiste Le Duc wrote: > > > On 2026-09-22 08:24 +0200, Jan Beulich wrote: > > Ok, now I understand, thanks. I'll fix it in next round. > > We don't know but based on [1] and my commit message, if neither > > Svade nor Svadu are present in DT then it is technically unknown whether > > the platform uses Svade or Svade. Hypervisor may then assume Svade to be > > present and enabled or it can discover based on mvendorid, marchid, and > > mimpid. For this patch, I choose to have the Hypervisor assumed Svade. > > Can hypervisor really access this regs? No it can't as they are M-mode only, it's why I choose to have the Hypervisor assumed Svade. > > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:21:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:21:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429148.1652080 (Exim 4.92) (envelope-from ) id 1x92JM-0000sY-0n; Tue, 22 Sep 2026 15:21:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429148.1652080; Tue, 22 Sep 2026 15:21:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92JL-0000sR-U4; Tue, 22 Sep 2026 15:21:35 +0000 Received: by outflank-mailman (input) for mailman id 1429148; Tue, 22 Sep 2026 15:21:35 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92JK-0000sH-Rd for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:21:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92JJ-00GyPL-SC for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:21:33 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29ced-e002-0a2a0a5209dd-0a2a450ce03e-34 for ; Tue, 22 Sep 2026 17:21:33 +0200 Received: from [40.107.209.18] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29cfb-f479-0a2a450c0019-286bd112b9ef-3 for ; Tue, 22 Sep 2026 17:21:33 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BL1PR03MB5992.namprd03.prod.outlook.com (2603:10b6:208:30a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 15:21:30 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 15:21:30 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iD+eqMeUeRMYVXOqvGEcrD9UimyvpCQ39HB17t72w0LUxy3j1uuiI72DD76v1DKYRe5zGInyROwQpHvViROUMFml8P7TKV36utmgf1QcAQQKKrEdtDIqsqqMbzYNq5N++jGhWbb+Wn3hp341sxY8+GI3OYASLNSs+HHzMe9ypWgzf21sf+P87KTYoWjAd3LjmsDtX33QffR6q0Pwtqgm4ChDyk0k7zWFVKoXwigPNFzQda1llstXJ0pHSM+vaj3K3lUWwYpjmDN/VU3wDxZRSOO47I/XHuEXaizJ4VCILNonyW1AC2/SBd0QiPjU/6HVCks5NKXuDLUdlE7eSCMOLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kEI/kIIOd6UTcjRAbecf/3Wfz1WNDPukW79dqipR1yQ=; b=zEl9RhiSh8B6jJU65h4/2f8Ot7SEGSbH/o0k7fhBGWacSPU+BA7H2cp/oZpnsJsvJK+QehoyXtlacDAAitEdjiTV7DdW5eHpHT1OGkhGMmt1/IGhtFJTO3oT81q+2DEbKpcLw8BoAmMMteYWrh7I89jhJsDkI3K+FYuQnjAtnB/fwkLqo0LBQED/mQkjfbC5WUV18DtGTZVF6S997t80Oo/J4Nq8wY7J0vAS/dZUkVJBLO9M5KXivAfOddRPiPguJigklTaEivcAPmsIeOdToKoNsfBB+j/ILUcCqJqvKy09fOsXbvLvgtONScCWLPlPASzs4gzvG0eAQFr1PPGEiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kEI/kIIOd6UTcjRAbecf/3Wfz1WNDPukW79dqipR1yQ=; b=Gx7ADZ3DJXZR6gAWNPkoDubm9ZbpiltYQ0Gqmikmdbwp3XYNJrhhcFRXwfYQ47RprCBObPgPzTrUkAqLkZg3NanGK2Swr81/0wxhMAr+jyMDJSKZxiFu4f1d6+8Qri6VNzrnv/LTHM5uiJaM2NQCArUoGP/cErH02QlpkunmVlU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <290d1ac5-a9b8-4576-9e9e-2b44d377a76a@citrix.com> Date: Tue, 22 Sep 2026 16:21:25 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Daniel Smith Subject: Re: [PATCH v2 04/14] x86: restrict PHYSDEVOP_* when PV=n To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <664d2a63-2745-4c33-9748-283aefce2433@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <664d2a63-2745-4c33-9748-283aefce2433@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VI1P189CA0032.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::45) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BL1PR03MB5992:EE_ X-MS-Office365-Filtering-Correlation-Id: 3b6a05a6-fd86-4164-f559-08df18bd2d60 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|4143699003|6133799003|10067099003|11063799006|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: gmx9byPQOysiQJWUO5wVZm3kLvgP/kfuw8UMBXRBoOulp+TTu/ulUQV670JNzgpM4T+j5eviJJkAZQhCMA5R6/hdCIhix5bzOp8PYHTTKtVcXGXxwrUARDkFQDVpenftEulxQZ8qRW5GCXga2yMVdGQSZoAbtU05WPu7xlDpVABv/9GDFzPxFcZXoOUJL/K2MYl7j2D1I2zckq/bLkJe2bryNxSdDafvB30aCo21YcQVqBQxY/8KoFJFYf+eNmIPnejZ9EJiIloGiaBamJthxe7LyBfA9IOedNdUk1OSkSOiZXeHKulkwnKQJT6weivB357y9zzbQpUDy9I2UH8wGy8ToPkJ2UJy/sDhwhks9DZD0q/YBs0+EuQAeHBIMERbn+HfRtZmRV3JVvpPe/5+Ny5mPMgLXL//9mrDcVNvk1JyHwEqVX4FDGGYyEpGts/4zFqbfiRU3XMe1nriSQVnaaOelGYnMbk7MffcWkpnbpz3yakzIYT1SQvqbl8rder+MNaGCXiYh541BQRT6sw72KEUjoCwA+DhC1dGyvz69YNkGjU/EAFy0UahFH3YfbXJwlpJazQRH8mfwta7iMIdR5fWTBPQcZUpU1eyRf6DYHRIzld1cvYVbiEERejbOE85WLTgMAiYHtnowLgSu79nyB1B6NUbwY/OClt1wrT4lJ8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(4143699003)(6133799003)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TUNrS0RGQkxFZVJyTjBEemViZ01KVFRpbC93YzdaRUVZa3EvNjM5cFBDcVJj?= =?utf-8?B?bktSMkFOU1lCdnZmZ3A2R2VILzlTc2pqSVdMdTdDRzZVekFjOVpEcFZoYTlS?= =?utf-8?B?M1Z5UzNRd0VIa1V6MG14WlluYlJGNWhUVW9aNERVWFk3cHJBeUhCUnpSYTZk?= =?utf-8?B?UlAzUUZFYjBYcCtHaGh6dGYwYnUxYTd5UTdlL1cyRTNCSHhQaEpvR3paSDZ4?= =?utf-8?B?bEFzRzIwV05iWFkzVU9IMTFqb2Flc2FlMUlSR2JWYnlZWlpVbU1BMEhFSnZs?= =?utf-8?B?N0x1L1FMbW9TTFZlSSt1QmtQb3lhdlVGZUVHRmJna0MwK0xjM2J4R0czZWtT?= =?utf-8?B?QUNWQlltSVg5ZFlVZFY1N3dZR1RLOXd3UXoxWmhPS0kyUXZpTUhRMVMwNHhM?= =?utf-8?B?ZFpSa1YzbUhwcGlJS3dDKytkN0hzdmZJSzkwNld5aFQrNXVXUktzc3I3NThn?= =?utf-8?B?aGpIM1YycWRDR2NKb3lpTnB3UTFidFJVVk15czRhUVNVM3NxZ3JaQ1NUUXRL?= =?utf-8?B?SnBLZ2tWTkFYS1BoaWdoQkZLZWhaekpVWjFFakNlRDdEN291Q3lqTWhzenpo?= =?utf-8?B?TEpKSEd3SGxZRzQrMmYyQzFvOWVhWXdIZFdNam8zT1RPY21UWEFQMTlURkdu?= =?utf-8?B?NUlBR29vU3dLTDdjaFJJY2ZhNnZ1WlRUdE5Xd0dOelNoSnVtckozY3BnamUx?= =?utf-8?B?UUkyWmU2RDlzTkZ1OVYvRFpFb0VIeC92Z00rdi9MR1JsUjdtdUQ0dUdjdEhm?= =?utf-8?B?Zkl5RG5JeDFZdlNKdHFnUU1xY0FQNjVPNDF4bUVPY3VkRkpTY2FxenhoblVu?= =?utf-8?B?TlRBcDJFa1lkMGFvUHdJWEFsNlM4TnN6V0Q0T2MwdVFtcXZiSm91eG8rSk14?= =?utf-8?B?VUtoaGVDcy9ZWmxadW9Pa0w3VG9POHIvWjN6cFBONHNVWGxTdTQ2ZzRBNlBE?= =?utf-8?B?ZXdtYmp3QmxqOWVRRDdNNGthZ0dma0JYSU12WUY5U1VERWdka3hOaFdTZGda?= =?utf-8?B?WlRtVlcrNGdnYXZwbDllMngxdG94em83dmtlQXM2OENJZG5yU3p3WDEvUjNP?= =?utf-8?B?VDl0S2poYThKQkwwNWlaUFBzOFAwQ2hGWVU5bzFSTStlK0Q0NTFCeVFmV1JE?= =?utf-8?B?N01wNElRQkgwOWQ1RHdLNGdBbjBiU2VTZVBiMjNHM3V0dHdCZ1NSbnZHWWc2?= =?utf-8?B?QSszMVVBdFhDQmZLOUNSem5malVZRVpmSVNBcC9QOVh1TVgvU2JKT3VkRnVr?= =?utf-8?B?elRKUU1kckVuRlRvMGs5dCtINVpVVXA5NjF3RHJZbnNKMFVBaWorcXIxelVP?= =?utf-8?B?STA5NEF0ejNlZ3J5UE5jekN1R0dQZ2ovTDZjVS9iMHQ4Nk14d0RBMWM1M0p5?= =?utf-8?B?MzlUWkVicUpiNzJwRUt2R3B1VW1GQTBpN2dRSU9vdFBYL1Fjc3ZIMW85T1k5?= =?utf-8?B?ZFNvU0hzRDBhR2R4R2h6NktCajVWZStWR20xWDJHa2JXS2Jac2VtR0NjcVpP?= =?utf-8?B?RDExL1JlL0plcW1jSzBTbkZIVDhONnZ3Q3JEM0YrZXp6RXpudHFGTmI2Ty94?= =?utf-8?B?VGxOcUY3dVJYS2h5N3lsaThJUkRFZ25pUEVIaHdLcTRpTklrNkovRld6cFFk?= =?utf-8?B?T0FwQXo5ZnBRejNiUzdxM01CV2tyMWY2ZHR5KzJjR1VWeW5ad3JMUXVibXBC?= =?utf-8?B?NUdnY0F2RlhyZVhtNHYvWnNES1dXM3NPSHBCOHRyejJvL3dlcmZNckNIUktw?= =?utf-8?B?cFpSRXhBSjNjR24zVEJ6cFJXOFZaTlZORW5wdFRyYUdhZFZpRElnUElYVHBN?= =?utf-8?B?NFByWjZmMG15SnVua1VQeGRlQ1NpcldxSFpoTEhsZzFsQklLcDd0Mk1Fc1Fu?= =?utf-8?B?M1VDN1RKTGE2OG1hTnNrakJZKzM0YXBtYkJkOUdXYzBlRUN0VHRxNU45Z1F2?= =?utf-8?B?SHBNMFEyc0dCUzVpL0RWWGIzZ3BmZmt2aUI4VnZZRk43TkpTcHRja1I1blhK?= =?utf-8?B?UHlzK2wxQkN5YXk0TEgvT1FTRFpYbWN4anBLbWpYMS9YcUtFM1ZsbE9wak5t?= =?utf-8?B?RTVQZ2lnVnNGOHU3cDJ0TnNOV2pYMkppSmdWbUw3enpSaHRwRmdGUDM2MGsx?= =?utf-8?B?WTRYTzZxdXFmdTZXZ0RZQWl2U3JHSkFOV1dwei9BSEYrcW84Zm5qQUhsYzJT?= =?utf-8?B?TFlaSG92cGxVSmdIL0c5VzRQekRGNjlMZXYrU1lLVTBNTHYrZjRWVFFnc2Yr?= =?utf-8?B?YUpnMWRjM2p1QnZNelNsaE9JYkQvTjh4cHZuZjMxQWwycVNSWFJEZ0xqc3J4?= =?utf-8?B?aVBoWGJSU1dzRnAwVkYzM0Q3QnFhcXV1NGpndXJrTSt4ZjNBQUR3dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b6a05a6-fd86-4164-f559-08df18bd2d60 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 15:21:30.0090 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: pQMB5musMl+7XyW738dHryLfyJQ8UijEbMTjMzXKuIl5CLy3Lte1IUgMMmUHhuvGVz2DAM2Jbxuk9dvE4KdhwZ2Ra+qLB846pLcGqf9yrSI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB5992 X-purgate-ID: tlsNG-d25034/1790090493-51B35A5B-4E28AF6B/0/0 X-purgate-type: clean X-purgate-size: 484 On 17/08/2026 9:52 am, Jan Beulich wrote: > --- a/xen/arch/x86/physdev.c > +++ b/xen/arch/x86/physdev.c > @@ -233,6 +233,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H > break; > } > > +#ifdef CONFIG_PV I think this needs to have /* See hvm_physdev_op(). */ Most of these ops are not inherently PV; they're only PV because we've not cared to expose them to HVM guests, and that's a different meaning to what CONFIG_PV normally means in code. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:29:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:29:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429158.1652089 (Exim 4.92) (envelope-from ) id 1x92R2-000327-PH; Tue, 22 Sep 2026 15:29:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429158.1652089; Tue, 22 Sep 2026 15:29:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92R2-000320-MV; Tue, 22 Sep 2026 15:29:32 +0000 Received: by outflank-mailman (input) for mailman id 1429158; Tue, 22 Sep 2026 15:29:31 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x92R0-00031n-SJ for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:29:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92Qz-00Aotb-KT for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:29:29 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29ecf-8faa-0a2a0a5109dd-0a2a4501e7c2-36 for ; Tue, 22 Sep 2026 17:29:29 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29ed9-5984-0a2a45010019-4a7de18ced81-3 for ; Tue, 22 Sep 2026 17:29:29 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e4ad9so25497845e9.2 for ; Tue, 22 Sep 2026 08:29:29 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fddfd158bsm2148465e9.6.2026.09.22.08.29.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 08:29:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790090969; x=1790695769; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=8PGtmnDxBnGxAZeoBuBu672Y7HTrakHFY0FKpHr3+Vc=; b=gv4RdlwFnxdqM9Zd5iM6XmWS8aKHl7xGNmCDaWGfYXrbY1pKva+uuLZy3mhJi+X1y7 NdnvvTlDD1q4zb8xIfkBbIYhLgSAhoySYxsSwgghJyp6h5zzTxrqRgheA7exJJooP+aa lXO/FvHb563JCOPjCZ80+QnAo/fkmqa02KzhC6eNF6V2Mb1Y5+WJKCW9mMh+tARLOmFE iJUxh5MtFE8FTJw4Gr0QDuk7MKQvkmXbKd9ndTDbodtMAZFKjH79+IpHHCfWakAJ4EOV rbk7Wv9JlsRffAtoiHou1q7YfEPZBg+ghcxZhykRkZ2t3EFxHmcAqrlh1q7H62ua+uDX W/NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790090969; x=1790695769; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=8PGtmnDxBnGxAZeoBuBu672Y7HTrakHFY0FKpHr3+Vc=; b=JxDQR8ZkU3kpaFCnIb8cTFdPdkUZsLyOmD5Z0x1/TSRssnm6XhISMUHN+Hr1T+mZrU Fv1gQvhjY65a5qrTY8iEUfoiMFLkZvYWQE1wKnpXjQle+JDDUHhK2gupLD9H0NM6taRj F77gJxy/SU2lTA9OfTm+rmcRFWo65fItZdrPMs3MlNS83581ISqp8/DtzZ0nbeCARcES oIVohWpyNflDKMMWoLmd4N4ibwoMFTzxwl0SaS6yE2HqD1EG43oNYHJf9ow+BFqCfuv2 TfW7DAoijOno3v0c2BPw5D6xk73CU5xjgy5DnxQi3Gyo0ChP2JaDRN96WCo2a2bV0x3X qa4Q== X-Gm-Message-State: AFuF++nYoIA32dYDkKBV2I9RY3ErR21qd7MMqcG0PCDwxpffIAASHYiX AC8YaPsLtebVDHHhkfvfo0eDLDFoR4s5Hf6CH1+ny+Wsd6QN4/7d3CPP X-Gm-Gg: AYBFou0FSvrB54F0UDh0gZ2vdim5hj5ZCTeQom0mhDMW+Aydp7uYXek9pn6AWFNc6q+ yUeCendZC1BI8KtuYJ94d8ZxgB5VdhH2XRNY2VGccPeH5V1B1rlrmGvrEch+MdLVDSRbcHlhCSK GvlRu/v/mU//eos/203UbeJ2oLfChfum9JMq3F/VtMVCq4Ede8mlOj/HK+CgJBpOdv+SYq4d1ju p5rDjCHvlB91YlpN6AXwTv5nh+iE3Cx8BL8UD0/O5N2FslO3ZNLulZOGEzv7RBs6FRnVo6agVyn /yvBfr0yhVMxAwmYh527hRSPLrIhsJJL0D8jqvI7H+sDG2U99y7wvmjNeFeixIWaICaTl2MFLAD NxpKm5LKacqaU0Lmo3oVsuqecr/2KcjsnqR7lVA4jw2jGR8TBmyfbl/E6Onp1/fUW01/ueVA3LX lStET9b8UZiRmuJSFYie2KwAhNV5KKo3H0YKILkWEg1MlNdsibQIzdemuCabUtEU9RPLGZdHM/H BYxsYZlz3BTe597tpr/bjlde+/Pjsh0C1o= X-Received: by 2002:a05:600d:6409:20b0:49f:cbad:eef7 with SMTP id 5b1f17b1804b1-49fcbadef22mr123063165e9.33.1790090967939; Tue, 22 Sep 2026 08:29:27 -0700 (PDT) Message-ID: Date: Tue, 22 Sep 2026 17:29:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling To: Baptiste Le Duc , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Cc: xen-devel@lists.xenproject.org References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790090969-1FE68757-A0BBB646/10/73395122804 X-purgate-type: spam X-purgate-size: 13512 On 9/10/26 11:34 AM, Baptiste Le Duc wrote: > p2m_set_permission() only presets the PTE A/D bits when the Svade extension > is present in the device tree. This causes an unhandled page fault when > neither Svade nor Svadu is present (the platform's actual behaviour is then > unknown), and when both are present in the device tree. When both are present, RISCV_ISA_EXT_svade is set, so the current code does preset the A/D bits and no fault happens. The only broken case is when neither extension is present, so shouldn't "both present" be dropped? > > Move the Svade/Svadu resolution out of p2m_set_permission() and into a new > riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). For each of > the four possible Svade/Svadu combinations (inspired by [1]), it decides > whether software has to preset the A/D bits and, if so, sets > RISCV_ISA_EXT_svade to record that decision: > - neither present: assume Svade, since assuming Svade is harmless on real > Svadu hardware, while assuming Svadu on real Svade hardware risks an > unhandled page fault > - only Svade present: assume Svade > - only Svadu present: leave A/D management to hardware > - both present: Svade wins until Xen supports the SBI FWFT call needed to > enable hardware updating of A/D bits, so assume Svade and warn that > dropping 'svade' from the DT is the only way to get Svadu. > > [1] https://lwn.net/Articles/980016/ > > Fixes: ff14053983b0 ("xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration") > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Baptiste Le Duc > --- > Changes since v1: > - change commit title > - expose RISCV_ISA_EXT_svadu so the two extensions can be told apart. > - move the Svade/Svadu resolution to a new riscv_resolve_ad_scheme(), > called once from riscv_fill_hwcap(). > - expose sbi_probe_extension() (was static) to probe for SBI FWFT. sbi_probe_extension() is already non-static in staging, only the prototype is missing. What base is this patch against? > - stop presetting A/D bits unconditionally in p2m_set_permission(), do it > only when Svade is present. What is the gain from not presetting them? Presetting A/D is correct with both Svade and Svadu: with Svadu it just saves the hardware an atomic PTE update on first access. Xen doesn't consume G-stage A/D bits (no dirty tracking, no demand paging), and pt.c already presets A/D unconditionally for Xen's own mappings. Always setting PTE_ACCESSED | PTE_DIRTY in p2m_set_permission() fixes the bug in one line, with no need for the resolver, the new ISA bit, FWFT probing or the ASSERT. Handling A/D differently only makes sense once Xen actually wants that information, and at that point FWFT support and a fault handler are needed anyway. > --- > xen/arch/riscv/cpufeature.c | 59 +++++++++++++++++++++++++++++++++ > xen/arch/riscv/include/asm/cpufeature.h | 1 + > xen/arch/riscv/include/asm/sbi.h | 8 +++++ > xen/arch/riscv/p2m.c | 47 ++++++++++---------------- > 4 files changed, 86 insertions(+), 29 deletions(-) > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > index 92235fdfd5..19454544a7 100644 > --- a/xen/arch/riscv/cpufeature.c > +++ b/xen/arch/riscv/cpufeature.c > @@ -18,6 +18,7 @@ > > #include > #include > +#include > > #ifdef CONFIG_ACPI > # error "cpufeature.c functions should be updated to support ACPI" > @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) > return false; > } > > +/* > + * Svade and Svadu extensions represent two schemes for managing the PTE A/D > + * bits. When the PTE A/D bits need to be set, the Svade extension indicates > + * that a page fault will be raised. In contrast, the Svadu extension supports > + * hardware updating of the PTE A/D bits. > + * > + * There are 4 possible combinations of these extensions in the device tree. > + * The default hardware behavior for each is: > + * > + * 1) Neither Svade nor Svadu present in DT => It is technically unknown > + * whether the platform uses Svade or Svadu. Xen should be prepared to > + * handle either hardware updating of the PTE A/D bits or page faults when > + * they need updating. In that case, Xen assumes Svade because it's > + * harmless if the platform is actually Svadu, while assuming Svadu on real > + * Svade hardware risks an unhandled page fault. > + * > + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. > + * > + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. > + * > + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off > + * at boot time by setting A/D bits. To use Svadu, the supervisor must > + * explicitly enable it using the SBI FWFT extension. > + * > + * The Svade extension is mandatory and the Svadu extension is optional in the > + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose > + * option 3. Platforms aware of the profile can choose option 4, and Xen won't > + * get the benefit of Svadu until the SBI FWFT extension is available. > + * > + * In other words, hardware manages the A/D bits on its own only in case 3, in > + * all the other cases software has to preset them. Instead of open coding this > + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is > + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. > + */ > +static void __init riscv_resolve_ad_scheme(void) > +{ > + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); svadu is always false here: the patch doesn't add RISCV_ISA_EXT_ENTRY(svadu, NONE) to riscv_isa_ext[], so match_isa_ext() never sets this bit. Cases 3 and 4 are dead code. Am I missing something? > + > + /* Case 3: leave the A/D bits management to hardware. */ > + if ( svadu && !svade ) > + return; > + > + /* Case 4 */ > + if ( svadu && svade ){ > + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ > + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" > + "RISC-V: Defaulting to software A/D updates (Svade).\n" > + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); > + } > + } sbi_probe_extension() returns a negative errno on SBI failure, so !sbi_probe_extension() is false in that case and an error is treated as "FWFT present". The existing callers check "> 0", so this should be "<= 0". > + > + /* Cases 1, 2: Xen assume Svade to be enabled */ s/assume/assumes. > + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); In case 4 RISCV_ISA_EXT_svadu stays set, so both bits are set and the ASSERT() in p2m_set_permission() fires (once svadu is actually parsed). This contradicts the "mutually exclusive" statement there. > +} > + > bool riscv_isa_extension_available(const unsigned long *isa_bitmap, > enum riscv_isa_ext_id id) > { > @@ -513,6 +570,8 @@ void __init riscv_fill_hwcap(void) > __set_bit(RISCV_ISA_EXT_sstc, riscv_isa); > } > > + riscv_resolve_ad_scheme(); > + > for ( i = 0; i < req_extns_amount; i++ ) > { > const struct riscv_isa_ext_data ext = required_extensions[i]; > diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h > index 0c48d57a03..74200ce7c9 100644 > --- a/xen/arch/riscv/include/asm/cpufeature.h > +++ b/xen/arch/riscv/include/asm/cpufeature.h > @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { > RISCV_ISA_EXT_sstc, > RISCV_ISA_EXT_svade, > RISCV_ISA_EXT_svpbmt, > + RISCV_ISA_EXT_svadu, Please keep the same order as riscv_isa_ext[], i.e. between svade and svpbmt, and add the matching riscv_isa_ext[] entry there as well. > RISCV_ISA_EXT_MAX > }; > > diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h > index 1952868e96..4f13e8c7a0 100644 > --- a/xen/arch/riscv/include/asm/sbi.h > +++ b/xen/arch/riscv/include/asm/sbi.h > @@ -30,6 +30,7 @@ > #define SBI_EXT_BASE 0x10 > #define SBI_EXT_RFENCE 0x52464E43 > #define SBI_EXT_TIME 0x54494D45 > +#define SBI_EXT_FWFT 0x46574654 > > /* SBI function IDs for BASE extension */ > #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 > @@ -138,6 +139,13 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, > int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, > size_t size, unsigned long vmid); > > +/** > + * Check if an SBI extension ID is supported or not. > + * @extid: The extension ID to be probed. > + * > + * @return: 1 or an extension specific nonzero value if yes, 0 otherwise. > + */ This is incorrect: on failure the function returns a negative errno, not 0. Also, the rest of the file uses /* */ and not kernel-doc /**. > +int sbi_probe_extension(long extid); A blank line is missing before the next comment block. > /* > * Initialize SBI library > * > diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c > index 1cea86512c..22ad4a2aee 100644 > --- a/xen/arch/riscv/p2m.c > +++ b/xen/arch/riscv/p2m.c > @@ -586,42 +586,31 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_cache) > > static void p2m_set_permission(pte_t *e, p2m_type_t t) > { > + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); This runs for every p2m PTE. The second test_bit() exists only for the ASSERT(). > + > e->pte &= ~PTE_ACCESS_MASK; > > e->pte |= PTE_USER; > > /* > - * Two schemes to manage the A and D bits are defined: > - * • The Svade extension: when a virtual page is accessed and the A bit > - * is clear, or is written and the D bit is clear, a page-fault > - * exception is raised. > - * • When the Svade extension is not implemented, the following scheme > - * applies. > - * When a virtual page is accessed and the A bit is clear, the PTE is > - * updated to set the A bit. When the virtual page is written and the > - * D bit is clear, the PTE is updated to set the D bit. When G-stage > - * address translation is in use and is not Bare, the G-stage virtual > - * pages may be accessed or written by implicit accesses to VS-level > - * memory management data structures, such as page tables. > - * Thereby to avoid a page-fault in case of Svade is available, it is > - * necessary to set A and D bits. > - * > - * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI > - * delegates page faults to a lower privilege mode and so OpenSBI > - * isn't expect to handle page-faults occured in lower modes. > - * By setting the A/D bits here, page faults that would otherwise > - * be generated due to unset A/D bits will not occur in Xen. > - * > - * Currently, Xen on RISC-V does not make use of the information > - * that could be obtained from handling such page faults, which > - * could otherwise be useful for several use cases such as demand > - * paging, cache-flushing optimizations, memory access tracking,etc. > + * riscv_fill_hwcap() sets either RISCV_ISA_EXT_svade or > + * RISCV_ISA_EXT_svadu (mutually exclusive) depending on the Svade/Svadu > + * device tree combination (see riscv_resolve_ad_scheme()): This isn't true, see the comment on riscv_resolve_ad_scheme(): in case 4 both bits end up set. > + * - RISCV_ISA_EXT_svade means that software is responsible for the A/D > + * bits. > + * - RISCV_ISA_EXT_svadu means the hardware is responsible for the A/D > + * bits. > * > - * To support the more general case and the optimizations mentioned > - * above, it would be better to stop setting the A/D bits here and > - * instead handle page faults that occur due to unset A/D bits. > + * Currently, when RISCV_ISA_EXT_svade is set, Xen doesn't track A/D > + * bits, so it does not make use of the information that could be > + * obtained from handling the resulting page faults, which could > + * otherwise be useful for several use cases such as demand paging, > + * cache-flushing optimizations, memory access tracking, etc. To avoid > + * such a page fault, Xen presets the A and D bits instead. > */ > - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > + ASSERT(svade != svadu); /* exactly one of svade/svadu must be set by riscv_fill_hwcap() */ The line is over 80 columns, and the trailing comment just repeats the block comment above. > + if ( svade ) > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > switch ( t ) > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:31:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:31:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429166.1652097 (Exim 4.92) (envelope-from ) id 1x92T1-0004wZ-7h; Tue, 22 Sep 2026 15:31:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429166.1652097; Tue, 22 Sep 2026 15:31:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92T1-0004wS-4q; Tue, 22 Sep 2026 15:31:35 +0000 Received: by outflank-mailman (input) for mailman id 1429166; Tue, 22 Sep 2026 15:31:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92T0-0004wG-6d for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:31:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92Sz-008QEg-6F for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:31:33 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab29f49-bab6-0a2a0a5309dd-0a2a4503abf8-20 for ; Tue, 22 Sep 2026 17:31:33 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab29f53-fae8-0a2a45030019-aceafc1faed8-3 for ; Tue, 22 Sep 2026 17:31:32 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 81B3D40DC1; Tue, 22 Sep 2026 15:31:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 971F71F00893; Tue, 22 Sep 2026 15:31:26 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790091090; bh=VFYj6sjedfWGEBuGl++9heS9zoD83sYWZIxoZFH52Mw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=oxgbajWAx+ewgz3EYGgJPYtZfNNrVy2jiDvlrL0XB6QieOmgNe9oJ8tWYTAmWkd4E 40O1bShYyuGwabzOZg2yryGvTCOWVoLErNmP15TezU6CcK1+IP50a2puK4iDmaw6R3 PCwUfPw/jYwdSq8HtaOBJAU/3KQvk7VOfDVSLU+W6MZTQuGVG14os2s8QuaTXuRpZy c1E7BQMp5Oh5V6N9yXEOXRU2Ns8Xz5BjaAREZfd68p1jzII0svn4YeEB6D4D+XgUXP mn6RKCk0xuOhAtFCkmd48wAcJ6k5w8jrTIJhK2olCjTjtXsHqi1z/Ac++TcJ8CKg7E LVSLUkJaZCs2w== Date: Tue, 22 Sep 2026 15:31:25 +0000 From: Jaegeuk Kim To: Nanzhe Zhao Cc: Zi Yan , Qi Zheng , Matthew Brost , Alistair Popple , ceph-devel@vger.kernel.org, Eric Biggers , xen-devel@lists.xenproject.org, Gregory Price , Arnaldo Carvalho de Melo , linux-fscrypt@vger.kernel.org, Shuah Khan , David Hildenbrand , Suren Baghdasaryan , linux-kernel@vger.kernel.org, Nico Pache , linux-perf-users@vger.kernel.org, Oleksandr Tyshchenko , Masami Hiramatsu , Jiri Olsa , linux-fsdevel@vger.kernel.org, Andrew Morton , Trond Myklebust , Mark Rutland , linux-doc@vger.kernel.org, Dave Hansen , Hongbo Li , Ying Huang , Stefano Stabellini , Vlastimil Babka , Sergey Senozhatsky , Byungchul Park , linux-trace-kernel@vger.kernel.org, Lorenzo Stoakes , Joshua Hahn , Barry Song , Kairui Song , "Theodore Y. Ts'o" , Muchun Song , linux-f2fs-devel@lists.sourceforge.net, Minchan Kim , Lance Yang , Thomas Gleixner , Anna Schumaker , Pratyush Yadav , Alex Markuze , Alexander Shishkin , linux-mtd@lists.infradead.org, Chunhai Guo , Jonathan Corbet , Dev Jain , "Matthew Wilcox (Oracle)" , Viacheslav Dubeyko , Gao Xiang , Wei Xu , Baoquan He , James Clark , Steven Rostedt , Borislav Petkov , Baolin Wang , Shakeel Butt , Tal Zussman , Ilya Dryomov , Oscar Salvador , linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-erofs@lists.ozlabs.org, Mike Rapoport , Ian Rogers , Michal Hocko , Jan Kara , Peter Zijlstra , Dave Young , Yuanchu Xie , "Liam R. Howlett" , "H. Peter Anvin" , Yue Hu , Rakie Kim , Richard Weinberger , x86@kernel.org, Ingo Molnar , Axel Rasmussen , Ryan Roberts , Pasha Tatashin , Usama Arif , Jeffle Xu , Namhyung Kim , Juergen Gross , kexec@lists.infradead.org, Adrian Hunter , Johannes Weiner , Mathieu Desnoyers Subject: Re: [f2fs-dev] [PATCH v5 00/17] Remove PG_private by using page/folio->private checks instead Message-ID: References: <20260920-remove-pg_private-v5-0-bb68b6a21869@nvidia.com> <20260922041600.1240429-1-zhaonanzhe@xiaomi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260922041600.1240429-1-zhaonanzhe@xiaomi.com> X-purgate-ID: tlsNG-33051d/1790091093-6ECCB4E9-45AFFC6D/0/0 X-purgate-type: clean X-purgate-size: 1132 On 09/22, Nanzhe Zhao wrote: > Hi Zi Yan, > > Thanks for the series. The cleanup is a nice help for the f2fs > large-folio work -- it removes the page-based private-flag plumbing that > my series would otherwise have to carry itself. > > My large-folio series v2 [1] can be rebased on top of this series. The > only overlap is the PAGE_PRIVATE_* flag helpers, which I can re-express > on top of the F2FS_FOLIO_PRIVATE_* names while keeping the > f2fs_folio_state indirection. > > Jaegeuk, do you have a preference on the ordering here? My personal > suggestion would be to review and merge this series first, and I'll > rebase on top of it. Let's keep working on the f2fs tree, since we should not merge this in my tree. Later, we'd need to prepare how to address the merge conflict. > > [1] https://lore.kernel.org/linux-f2fs-devel/20260915041909.2903887-1-zhaonanzhe@xiaomi.com/ > > Thanks, > Nanzhe > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:37:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:37:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429176.1652107 (Exim 4.92) (envelope-from ) id 1x92YA-0006Qc-Q5; Tue, 22 Sep 2026 15:36:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429176.1652107; Tue, 22 Sep 2026 15:36:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92YA-0006QV-Mk; Tue, 22 Sep 2026 15:36:54 +0000 Received: by outflank-mailman (input) for mailman id 1429176; Tue, 22 Sep 2026 15:36:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x92Y9-0006QM-LR for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:36:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92Y8-00Aqez-TL for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:36:52 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2a07b-8faa-0a2a0a5109dd-0a2a4507c23e-48 for ; Tue, 22 Sep 2026 17:36:52 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2a093-b4ea-0a2a45070019-b9ff1c2387af-3 for ; Tue, 22 Sep 2026 17:36:52 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0c9c32ad300072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 15:36:46 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 3E73282362; Tue, 22 Sep 2026 17:36:45 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=8Ey3zrjI8D0i6oxEP4lWwENQRpC1B+d6F7u4VPCDVbY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=tQqDmq19nwHSxG4uKJYcONpEpqJvjbbhmT/1Nt94mVo7mmZH+EONo8aI99J6k7GflULDZsw2R Qy6P3NfMjLy1ZWv30yfLO/PKqIXlIy8ITFnc0d6AhXkGKFVO21pNLiD0okaFK+U+GwAFOJ9IQn1 n7CeNTvjhFYduMMvONC9Ug2saUxR0w7ljtz6JTqFEO6Zp2YX4TZcr7/g+817083y3XKqetPKQGI bB/oNHBNbVn8O0SjQrrBdofV1DkIwZSfYu+w4bTJbacCOt6VGPP3fsN/SS0dZTs4JRvz64vr2JN LX1P/zWSZST4qirXdh7mC2703Wko4+C4E6Kz9xUR66rA== X-Zone-Loop: 7417802adc134c79dc3dc9abfa987440dc040b2f0ddd x-campaign-type: default x-transaction-id: 3297e265-725e-44f0-85ef-f576fc4e46ea x-swg-uid: 01-e66d5b4d-f032-49fd-a992-c3aadaa0c401 X-Mailer: Sweego Message-ID: <1790091406.8631fc262581453bbf619ec5b2062170.1a0c9c32ad300072c4@vates.tech> x-swg-bid: 1790091406.8631fc262581453bbf619ec5b2062170.1a0c9c32ad300072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <5b70c0d6-12ec-429c-be9c-a96d78d48e68@gmail.com> References: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> <1790007309.8631fc262581453bbf619ec5b2062170.1a0c4bff57900072c4@vates.tech> <5b70c0d6-12ec-429c-be9c-a96d78d48e68@gmail.com> Date: Tue, 22 Sep 2026 17:36:39 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790091399; l=10227; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=7eaUhQ0DVeRCoRnrDKsWiD50xCkTNrckjLHxLGNTNrs=; b=ZVhBnkmD3CK4Szwe1moI9uQcChVNn/R+z5Pehi4UBAzSoDsPYZboMHkomBLTMKqaMa7zC9ylb pgVYDl9c1AvDAR3eW9BxuOwMHxopq9jLRYEC4a6kuGjd+v1A6UTbRfF X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790091405462 X-purgate-ID: tlsNG-ef75cf/1790091412-A70DDAE4-E3D577A9/10/73395122804 X-purgate-type: spam X-purgate-size: 10231 On 2026-09-22 15:01:02+02:00, Oleksii Kurochko wrote: > On 9/21/26 6:15 PM, Baptiste Le Duc wrote: > > > > > > On 8/27/26 5:24 PM, Oleksii Kurochko wrote: > >> Implement first steps of migration a vCPU to a different guest > >> interrupt file > >> procedure: > >> - At the old interrupt file, save to memory the values of registers > >>    eidelivery and eithreshold, and set eidelivery = 0. > >> - At the new interrupt file, set eidelivery = 0, and zero all > >>    implemented interrupt-pending bits (the eip array). > >> > >> The following steps will be introduced in follow-up patches. > >> > >> Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to > >> guard > >> against silent incorrect behaviour or unexpected panics in guest VMs > >> until > >> the function is fully implemented. > >> > >> vgein_assign() will be introduced later in a separate patch, for not > >> it is > >> only stub. > >> > >> Signed-off-by: Oleksii Kurochko > >> --- > >> Changes in v2: > >>   - New patch. > >> --- > >> --- > >>   xen/arch/riscv/aia.c             |   9 ++ > >>   xen/arch/riscv/imsic.c           | 159 +++++++++++++++++++++++++++++++ > >>   xen/arch/riscv/include/asm/aia.h |   4 + > >>   xen/include/xen/config.h         |   1 + > >>   4 files changed, 173 insertions(+) > >> > >> diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c > >> index e31c9c2d24b6..75c82bcfa1b3 100644 > >> --- a/xen/arch/riscv/aia.c > >> +++ b/xen/arch/riscv/aia.c > >> @@ -1,8 +1,10 @@ > >>   /* SPDX-License-Identifier: GPL-2.0-only */ > >> +#include > >>   #include > >>   #include > >>   #include > >> +#include > >>   #include > >>   #include > >> @@ -21,3 +23,10 @@ void __init aia_init(void) > >>       _aia_usable = true; > >>   } > >> + > >> +unsigned int vgein_assign(struct vcpu *v) > >> +{ > >> +    BUG_ON("unimplemented\n"); > >> + > >> +    return 0; > >> +} > >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > >> index ad7fbe708bfd..516f0105352a 100644 > >> --- a/xen/arch/riscv/imsic.c > >> +++ b/xen/arch/riscv/imsic.c > >> @@ -26,6 +26,7 @@ > >>   #include > >>   #include > >> +#include > >>   #include > >>   #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * > >> IMSIC_MMIO_PAGE_SZ) > >> @@ -77,6 +78,64 @@ do {                            \ > >>       csr_clear(CSR_SIREG, v);    \ > >>   } while (0) > >> +#define imsic_vs_csr_write(c, v)    \ > >> +do {                                \ > >> +    csr_write(CSR_VSISELECT, (c));  \ > >> +    csr_write(CSR_VSIREG, (v));     \ > >> +} while ( 0 ) > >> + > >> +/* > >> + * Generic switchcase expansion pyramid. > >> + * F is the per-operation leaf macro, ireg is the base register index. > >> + * Optional extra args (e.g. an operation and/or a value) are > >> forwarded to F > >> + * via __VA_ARGS__. > >> + * > >> + * imsic_switchcase_break(ireg, op, v) - emit "case ireg: op(ireg,v); > >> break;" > >> + * imsic_switchcase_ret(ireg, op, ...) - emit "case ireg: return > >> op(ireg[,v]);" > >> + *   The variadic tail is optional so the same leaf works for both > >> read (no v) > >> + *   and swap (with v). > >> + */ > >> +#define imsic_switchcase_break(ireg, op, v) \ > >> +    case ireg:                              \ > >> +        op(ireg, v);                        \ > >> +        break; > >> + > >> +#define imsic_switchcase_ret(ireg, op, ...) \ > >> +    case ireg:                              \ > >> +        return op(ireg, ##__VA_ARGS__); > >> + > >> +#define imsic_switchcase_2(F, ireg, ...)    \ > >> +    F(ireg + 0, ##__VA_ARGS__)              \ > >> +    F(ireg + 1, ##__VA_ARGS__) > >> +#define imsic_switchcase_4(F, ireg, ...)    \ > >> +    imsic_switchcase_2(F, ireg + 0, ##__VA_ARGS__)  \ > >> +    imsic_switchcase_2(F, ireg + 2, ##__VA_ARGS__) > >> +#define imsic_switchcase_8(F, ireg, ...)    \ > >> +    imsic_switchcase_4(F, ireg + 0, ##__VA_ARGS__)  \ > >> +    imsic_switchcase_4(F, ireg + 4, ##__VA_ARGS__) > >> +#define imsic_switchcase_16(F, ireg, ...)   \ > >> +    imsic_switchcase_8(F, ireg + 0, ##__VA_ARGS__)  \ > >> +    imsic_switchcase_8(F, ireg + 8, ##__VA_ARGS__) > >> +#define imsic_switchcase_32(F, ireg, ...)   \ > >> +    imsic_switchcase_16(F, ireg + 0, ##__VA_ARGS__) \ > >> +    imsic_switchcase_16(F, ireg + 16, ##__VA_ARGS__) > >> +#define imsic_switchcase_64(F, ireg, ...)   \ > >> +    imsic_switchcase_32(F, ireg + 0, ##__VA_ARGS__) \ > >> +    imsic_switchcase_32(F, ireg + 32, ##__VA_ARGS__) > >> + > >> +static void imsic_eix_write(unsigned int ireg, unsigned long val) > >> +{ > >> +    switch ( ireg ) > >> +    { > >> +    imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIP0, > >> +                        imsic_vs_csr_write, val) > >> +    imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIE0, > >> +                        imsic_vs_csr_write, val) > >> +    default: > >> +        ASSERT_UNREACHABLE(); > >> +    } > >> +} > >> + > >>   unsigned int vcpu_guest_file_id(const struct vcpu *v) > >>   { > >>       return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); > >> @@ -389,6 +448,76 @@ int cf_check vcpu_imsic_init(struct vcpu *v) > >>       return 0; > >>   } > >> +/* > >> + * Arguments of the imsic_vsfile_local_*() helpers, which are > >> executed by the > >> + * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). > >> + */ > >> +struct imsic_vsfile_data { > >> +    unsigned int hgei; > >> +    unsigned int nr_eix; > >> +    struct imsic_mrif *mrif; > >> +}; > >> + > >> +/* > >> + * Execute func() on the pCPU which owns the IMSIC interrupt file > >> func() is > >> + * going to work with. > >> + * > >> + * An IMSIC VS-file is reachable only through hstatus.VGEIN of the > >> hart the > >> + * file belongs to, and a guest interrupt file index is meaningless > >> on any > >> + * other hart, so such work always has to be done by that very hart. > >> + * > >> + * The local case runs with IRQs disabled to provide func() with the > >> same > >> + * environment it is given when it is called from the function call IPI > >> + * handler. > >> + */ > >> +static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), > >> +                              void *data) > >> +{ > >> +    if ( cpu == smp_processor_id() ) > >> +    { > >> +        unsigned long flags; > >> + > >> +        local_irq_save(flags); > >> +        func(data); > >> +        local_irq_restore(flags); > >> +    } > >> +    else > >> +        on_selected_cpus(cpumask_of(cpu), func, data, 1); > >> +} > >> + > >> +static void cf_check imsic_vsfile_local_clear(void *data) > > I think the remark from Jan to direclty pass the type instead of void > > could be applied here. > > I think it can't because of how function pointer is passed to > on_selected_cpus() through imsic_call_on_cpu(). > > >> +{ > >> +    unsigned int i; > >> +    const struct imsic_vsfile_data *idata = data; > >> +    unsigned long new_hstatus, old_hstatus, old_vsiselect; > >> + > >> +    /* We can only zero-out if we have a IMSIC VS-file */ > >> +    if ( !idata->hgei ) > >> +        return; > >> + > >> +    old_vsiselect = csr_read(CSR_VSISELECT); > >> +    old_hstatus = csr_read(CSR_HSTATUS); > >> +    new_hstatus = old_hstatus & ~HSTATUS_VGEIN; > >> +    new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); > >> +    csr_write(CSR_HSTATUS, new_hstatus); > >> + > >> +    imsic_vs_csr_write(IMSIC_EIDELIVERY, 0); > >> +    imsic_vs_csr_write(IMSIC_EITHRESHOLD, 0); > >> + > >> +    for ( i = 0; i < idata->nr_eix; i++ ) > >> +    { > >> +        imsic_eix_write(IMSIC_EIP0 + i * 2, 0); > >> +        imsic_eix_write(IMSIC_EIE0 + i * 2, 0); > >> +#ifdef CONFIG_RISCV_32 > >> +        imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); > >> +        imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); > >> +#endif > >> +    } > >> + > >> +    csr_write(CSR_HSTATUS, old_hstatus); > >> +    csr_write(CSR_VSISELECT, old_vsiselect); > >> +} > >> + > >>   void cf_check vcpu_imsic_deinit(struct vcpu *v) > >>   { > >>       XVFREE(v->arch.vimsic_state); > >> @@ -689,6 +818,14 @@ int __init vimsic_make_domu_dt_node(struct > >> kernel_info *kinfo, > >>   void imsic_migrate_vcpu(struct vcpu *v) > >>   { > >> +    unsigned int new_vsfile_hgei; > >> +    unsigned int new_vsfile_cpu; > >> +    unsigned int nr_hw_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, > >> +                                          BITS_PER_TYPE(uint64_t)); > > This value appears to remain constant after initialization, since it > > depends directly on the hw, > > so it is not necessary to calculate it each time. > > I will add then: > > --- a/xen/arch/riscv/include/asm/imsic.h > +++ b/xen/arch/riscv/include/asm/imsic.h > @@ struct imsic_config { > /* Number off interrupt identities */ > unsigned int nr_ids; > > + /* > + * Number of 64-bit EIx groups needed to cover all the interrupt > + * identities, which are 0 (never valid, but it still occupies a > bit) up > + * to and including nr_ids. > + */ > + unsigned int nr_eix; > + Thanks! Maybe use `registers` instead of `groups` wording. > and init it once in imsic_parse_node(). > > Thanks. > > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:59:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:59:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429192.1652144 (Exim 4.92) (envelope-from ) id 1x92ti-0005kD-KS; Tue, 22 Sep 2026 15:59:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429192.1652144; Tue, 22 Sep 2026 15:59:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92ti-0005k1-Dy; Tue, 22 Sep 2026 15:59:10 +0000 Received: by outflank-mailman (input) for mailman id 1429192; Tue, 22 Sep 2026 15:59:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92th-0005d7-QX for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:59:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92th-00ATp7-7M for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:59:09 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2a5ca-2eae-0a2a0a5409dd-0a2a4505d854-4 for ; Tue, 22 Sep 2026 17:59:09 +0200 Received: from [52.101.66.99] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2a5cc-4cb1-0a2a45050019-3465426338ac-3 for ; Tue, 22 Sep 2026 17:59:09 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by AMBPR03MB11360.eurprd03.prod.outlook.com (2603:10a6:20b:767::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 15:59:05 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 15:59:05 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oLgtyVh4ZP5JqViUaVZV3+F7q04fMyUlbh3lMICdp3WpBeDjWsuXCUvW+mDtme4orTB2PKMg20Db82MX4GW8PrkSbvlrBqviRDIsVeGl5NzoZgX44mb3UK4TwTCpyW2i5Ibo/Wt0m++6/0vF3XzwxBYoyRA0Mzi/BOULjXXUBYA6++MHCaYs5MEBNLc1eV+/n1PUcYHiRaAMesNEdeTAkMzaANvoLY8cHJJ+X2FQ/NaL5p/ot98CiMk5qDEGMQazeGXSQI+xzMx3eUs99pf6yBFE/WS3LRlqGMgreCabQoM1d+/xAR3DJ2rLr9GgbsCOtkgVrrALm0VdJbg/uVW+Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=y0CNFQ6w0OoFMTVo9GGVwFDr1Sg2IGBlLPPygPrJC/Y=; b=uG1/Gi81Z5n0fRfO65ju8ZQlAaCsNm3rkzStvRIfFBYM28L1+wkuV636ZEJV8zKZ+Be4K2zzWUBg+RchRTCAJetzGQUbxDUYZXso66YK6sQhVbB58bQAGeO02ogOhqFgxHf1AT/dRgZobPZE5r/2T0e/NPh4SV15Qkaef7ziU9mC7xAj9gokmjl13tF0zKk2bFIw2UamRFFB5LEJ4X1HK1Auzo7j2lhdzQitjKe87mi88OuehZfGXK/kdw30BAVUMVEYxos51Tj/k2Qxb0Bfb2NgQmJHcGxX502l6vVL67P4q7jX5dvmeSn4ulQhq+1W7LJKSFiD0mY64REgRbvqzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y0CNFQ6w0OoFMTVo9GGVwFDr1Sg2IGBlLPPygPrJC/Y=; b=FvN2XmUJnqotIpgygOTFZEznxNrVky/ohLoZ4I9V03vDmmp+ghht0JWtRT4TcKSAm4Fdg8j4NuPpMq0R43AKZBIjo6usuGq2RHewG4SG+Eg5BQ5Oj9nKttHFuToji4cPTFg31JAbFW2RHdyKcrUac1DRFCpeNMCWgI/TuSb/olnwpQuaanf25Gq6oDdhyM28aSAgUO/E8YgZ0lJCRyT1ftPJa3lV4RkAIe+cSAnixM2BZhuGQqvn7NfglUgC32BknAJTck8Xlp2LuuoozZttTu6t7rZ4e/hXIiLRJWAzt9Nqort7MOEsOzjWm393pImeW4nw0CS2w0tmysESDpxObg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 3/4] xen/arm: its: refactor ITS quirk matching Date: Tue, 22 Sep 2026 18:58:41 +0300 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0020.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::17) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AMBPR03MB11360:EE_ X-MS-Office365-Filtering-Correlation-Id: 2b5a5be9-f1eb-4778-2666-08df18c26dfd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|18002099003|22082099003|11063799006|56012099006|10067099003; X-Microsoft-Antispam-Message-Info: nxKuU2JMZMreulMbq0ktOE2Z8ESLmB51S+vcv9n7FoXveEakbNFK76ZT42XZU2gbvcOezfwPHm2njKS6eUMohm0XKLgEKlBVyUCUztqDWYkk7U4+D26nKSES97RrRvklSdMhcvbTLopcGMmpUBb9bA6OechwZkQ4B1tOQ7KRFiLQU8qO0F32qU0vcy5OCNv6+JU7T/Iv4u96gL06bJCRD4pWmegU7gTQ4xMlasQmFhW64KCaio0LV7ZHPtq6V5UJswYsfazdSyIQh0kNc6MEf8LYyePCSH0UhxkXHmd3p3PbQtvBEp8BZri6IOX51jWLpNNp2EbHZ6tMtfZFAEIPaWwDkKAEcimRet21I1CyzZsUdDS+7OoWAa13mCUd3+PDR2QWE6PCSOUCyMAELGnau/LAb8PkuA1DpZulSpMDfOIEUtqVd++wvGHj3g9OepYDt7zuzDA5Z19HF/ao7gNm9gN7hkdfzCpSC1uWHVq36RjDJK+qBLMCrXJ78Ezz022/gj1jK3Zs49B9E46H6I8OC3KhqyI6p1kiGvnWMQnNeeFO45CNIBoBnStct5InyzQPn7qf9I4IzqE2vCOcgSND5vNNpTxyDPPlsIgB9HWuiB5yX4K0IDj+/urE61admJiCH9kIauwq+IUE2paLxlCP/ymbL/ks6uCtsdLuMW2lDGU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?On5pEzodTOQ9XD+mLSqc2VUuHTqi3njuR60lNFRPha8Gnd8nA73Diz3MMehO?= =?us-ascii?Q?O6dYVIHHCwhOMl1ufwgM/IrGuG4LNJoda+cA//6mir2WKsiglPWITkP1ZP4N?= =?us-ascii?Q?uRFNcxqkjRnDOiBaXwD9loDHggT74DX0ZiNrrUorPxW66SlOeUXqIcCwtzjO?= =?us-ascii?Q?FeYqxhW/sIw42SZP6LRyFWr17wtoy3pb94n7ApXxgjK3gD5m+gxUpv+HqLLL?= =?us-ascii?Q?OgrAQXFJ8NiFmT27fXKbDVwkuh2ExWBk168xEsuA9BbuKOC0LS6ZYGj26uqQ?= =?us-ascii?Q?6Gwb3erQmlbAHBZubTQL2UFVkwz6MTTssssi5o34fG4V27z98kz5MYMx45mH?= =?us-ascii?Q?8eTzSmQsUZmDOXPk6IM8H4tesg09MWWoZCTaRlN5Iu73xX65E5aUf6r33k6P?= =?us-ascii?Q?2oifM4fY3VHwaOD6Al74uFWwcKwet2VbKbn3c2ApkiG1IEX71OkcTAappWbe?= =?us-ascii?Q?Tmdoof8AjECEnSNUyMbnrhyWVhvjkm+lHpiPTv3061ObnO+zfAXV+RJ4Dl28?= =?us-ascii?Q?wgqsfyt6CYW6uT7GyoL/gx7geZ7mcPyGFcduFZIWC9BhZC3v2at6ozjGES4K?= =?us-ascii?Q?3UKfGcgYdJpZ9qKhZLAScudiIrG+f9lIK0fmAsqvqtgTBZu6Ef0EcHCJvC8H?= =?us-ascii?Q?3lurrtISKZrRFd3zE2hJU7ImF/398FWnPb3ZnLt35I0ay+9g00j/vj1h47tI?= =?us-ascii?Q?BMyeH6QTy6npVzkT+kFwCBwF+7b6mtUWhLGeDGsKfbm9Wugpqsd8C2KiZNPJ?= =?us-ascii?Q?91wWUegT7IuvqtbwKwvpfxWV3ioL0JTkqWsPwWqa+eDYlHbZLPzx631ACjZ7?= =?us-ascii?Q?S5sGVvTE2ew7cHPQ/MzgYK/HuN+y83q6saLPwpDYsxdNuGFIfjZKmtAa7Fda?= =?us-ascii?Q?mUeGdbvZ2svhVg55Gn6x2Hbd1wTYBbc0Xm4JQqcX1+GrO5J8+QzIUoP5QCUp?= =?us-ascii?Q?16PbR+EHQjUiGcEXHBdAOwygX5Nefssi/Jj2j/FSeuOdpQ3gQXDBGMSU/DR7?= =?us-ascii?Q?E93dqHXpW4IJPri611LlypuEYKCGHLB2pcceuIaBp0W0PdHBHy+WVtlnnZm/?= =?us-ascii?Q?eM1gINw1D/lDoQ80bVvUEtb2w9pvBWXWT6M2TPFWYnRQ+KqNUKUD9qUo1Fhu?= =?us-ascii?Q?q4e8j6XvaZmXZUMvBOvYOYE6ga1FAN57UvInbcMhSuftWqAAXMATechZU1AI?= =?us-ascii?Q?SyQK+y36/eRJiC89eJ8sP8z5Hy7iwNTg+KP3FAyv7bTsvILHTS+JjXVhMJ4N?= =?us-ascii?Q?js5XTgXt3PsoFtWtWpiRvVVh84aUPTwvQxzEAieX20KjxZdu9LlhE7efpxJI?= =?us-ascii?Q?0Lsxs+CfWKs8Q6kwU6ZjQ9stvZacGwpCwEcZD7LOpvSGWbd3fAVgjLmdgM1x?= =?us-ascii?Q?86wjnOP2Lj2aPBx9iInGdNIndzXHtfjeNtRSlYbVees5P0U0KCBtjMktF2ka?= =?us-ascii?Q?b7F4J9NTeaRQzqw4wStzab+wo+dfeKnUjNCorqbj38ln/AsBZ/GuK/hZjDBJ?= =?us-ascii?Q?E78gEF9YibcKkkr9lRjslL6o1IDA9wA3QUx+Twu7fo1jB6xEF8IecmLX3PF0?= =?us-ascii?Q?VdaYbnByeN39ZjqRAJz3/NMfCN3WV4UG6PZ3JyryjLGKIAr37qD77U+wO+0Q?= =?us-ascii?Q?+rf7cfM2JOiRwv0jbUh2p8M0pzE06BqBNl3Coa8+jf3nyZP4xhfGlCL9QmkA?= =?us-ascii?Q?iaWrGmPnFbhkdGNfkzMAjOpeRGABVNFcvyqYNMzpw2kXjgtPSaDdfAFb90j+?= =?us-ascii?Q?73TgE4QKrQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b5a5be9-f1eb-4778-2666-08df18c26dfd X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 15:59:05.9198 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: lH56Dn9s0pvSSlqXVk0WZ6bPEfWWMCdBeB+IgSsGO6dCreF4zFLrSxHlp1qcKYXT9etvOLw9wdTLlV1AV1/4qQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMBPR03MB11360 X-purgate-ID: tlsNG-c201ff/1790092749-F7CB82A1-959C4A81/0/0 X-purgate-type: clean X-purgate-size: 5575 ITS quirks are matched only by IIDR and mask fields stored in each table entry. That is too coarse when the same GIC IP block appears on several platforms but a workaround is valid only for some of them. Replace the fixed IIDR fields with a generic match(hw_its, data) callback and an opaque data pointer. Add an IIDR matcher as a reusable building block and use it from the R-Car Gen4 matcher after checking the Renesas machine compatibles. This intentionally narrows the R-Car Gen4 quirk. Previously every ITS with IIDR 0x0201743b matched. Now it matches only a DT-discovered ITS on an r8a779f0 or r8a779g0 machine. ACPI-discovered ITSes and the same IIDR on other platforms no longer match. Keep first-match semantics explicit. Assert that non-sentinel entries provide a matcher and that IIDR matching receives match data. Retain runtime guards so malformed entries cannot cause a NULL function call or data dereference in non-debug builds. Place the matcher data and table in init-only read-only sections. The matched entry still supplies separate ITS and LPI flags; this patch only changes how the entry is selected. Signed-off-by: Mykola Kvach --- Changes in v3: - Document the intentional narrowing of the R-Car Gen4 match. - Add the non-debug NULL-data guard. - Put the matcher data and table in init-only read-only sections. Changes in v2: - Replace v1's optional platform callback plus fixed IIDR/mask fields with a single generic match(hw_its, data) selector. - Add a reusable IIDR matcher and use it after the R-Car Gen4 machine-compatible checks. - Document that the R-Car Gen4 quirk remains DT-only. - Keep the split ITS and host LPI quirk scopes when applying the matched entry. - Document first-match ordering in the lookup path and guard against entries without a match callback or IIDR match data. --- xen/arch/arm/gic-v3-its.c | 73 +++++++++++++++++++++++++++++++-------- 1 file changed, 58 insertions(+), 15 deletions(-) diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c index 454fd0e0ef..f52232ca40 100644 --- a/xen/arch/arm/gic-v3-its.c +++ b/xen/arch/arm/gic-v3-its.c @@ -54,8 +54,8 @@ struct its_device { struct its_quirk { const char *desc; - uint32_t iidr; - uint32_t mask; + bool (*match)(const struct host_its *hw_its, const void *data); + const void *data; uint32_t its_flags; /* * lpi_flags are ORed into the global host LPI policy and must only @@ -65,11 +65,52 @@ struct its_quirk { uint32_t lpi_flags; }; -static const struct its_quirk its_quirks[] = { +struct its_quirk_match_iidr { + uint32_t iidr; + uint32_t mask; +}; + +static bool __init gicv3_its_match_iidr(const struct host_its *hw_its, + const void *data) +{ + const struct its_quirk_match_iidr *match; + uint32_t iidr; + + ASSERT(data); + + if ( !data ) + return false; + + match = data; + iidr = readl_relaxed(hw_its->its_base + GITS_IIDR); + + return (iidr & match->mask) == match->iidr; +} + +static bool __init gicv3_its_match_quirk_gen4(const struct host_its *hw_its, + const void *data) +{ + if ( !hw_its->dt_node ) + return false; + + if ( !dt_machine_is_compatible("renesas,r8a779f0") && + !dt_machine_is_compatible("renesas,r8a779g0") ) + return false; + + return gicv3_its_match_iidr(hw_its, data); +} + +static const struct its_quirk_match_iidr rcar_gen4_iidr __initconst = { + /* Implementer 0x43b identifies Arm Ltd. */ + .iidr = 0x0201743b, + .mask = 0xffffffffU, +}; + +static const struct its_quirk its_quirks[] __initconstrel = { { - .desc = "R-Car Gen4", - .iidr = 0x0201743b, - .mask = 0xffffffffU, + .desc = "R-Car Gen4", + .match = gicv3_its_match_quirk_gen4, + .data = &rcar_gen4_iidr, .its_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR, .lpi_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR, }, @@ -78,18 +119,21 @@ static const struct its_quirk its_quirks[] = { } }; -static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr) +static const struct its_quirk *__init gicv3_its_find_quirk( + const struct host_its *hw_its) { - const struct its_quirk *quirks = its_quirks; + const struct its_quirk *quirk; /* - * The first matching quirk wins. More specific quirks must be listed - * before broader IIDR-only entries. + * The first matching quirk wins. Entries that match a specific platform + * must be listed before broader IIDR-only entries. */ - for ( ; quirks->desc; quirks++ ) + for ( quirk = its_quirks; quirk->desc; quirk++ ) { - if ( quirks->iidr == (quirks->mask & iidr) ) - return quirks; + ASSERT(quirk->match); + + if ( quirk->match && quirk->match(hw_its, quirk->data) ) + return quirk; } return NULL; @@ -97,8 +141,7 @@ static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr) static void __init gicv3_its_collect_quirks(struct host_its *hw_its) { - uint32_t iidr = readl_relaxed(hw_its->its_base + GITS_IIDR); - const struct its_quirk *quirk = gicv3_its_find_quirk(iidr); + const struct its_quirk *quirk = gicv3_its_find_quirk(hw_its); if ( quirk ) { -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:59:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:59:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429190.1652122 (Exim 4.92) (envelope-from ) id 1x92tZ-00055W-PV; Tue, 22 Sep 2026 15:59:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429190.1652122; Tue, 22 Sep 2026 15:59:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92tZ-000558-Kl; Tue, 22 Sep 2026 15:59:01 +0000 Received: by outflank-mailman (input) for mailman id 1429190; Tue, 22 Sep 2026 15:59:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92tY-00052R-Nf for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:59:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92tY-0051uC-4E for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:59:00 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2a5b3-e002-0a2a0a5209dd-0a2a4503b2ce-34 for ; Tue, 22 Sep 2026 17:59:00 +0200 Received: from [52.101.69.87] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2a5c3-fae8-0a2a45030019-346545579f74-3 for ; Tue, 22 Sep 2026 17:59:00 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by AMBPR03MB11360.eurprd03.prod.outlook.com (2603:10a6:20b:767::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 15:58:58 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 15:58:58 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xX7nPF5AtWO9RH0I2a+z2LvO39mlYCSex1vmVtd1vuaG9ry18xmmkfiQwfCKLUy1e8QXngT375IUmJaoYrMxCDJD2V61hDPCLE6ItNzN/OilTON3mQilOWY6umWVw4NaOXW9ivEW8B9D/7XSVP0crSxMrY0jlAnGIkfeRaN5aM1+/iAPC/auWIbmw0ncSOmuzfGWNINjaYTe57IvG6sSgqcQZpAv2NU33+4AKaY3lyu+4fuTr4j7qLKCoKDgUdBQ4eEjE9nJ+q+AFTcEOvIi69f5Yca8k/noZ2A+1CaD1TJGkVhHO9BeAAakWmHawqgmag3mWlGzUfTVcEd4sOoI5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r+hTxJNTEDvZMRAcnSSFx66gX6XkBALCTM+wQLOjqmo=; b=UoSpN11ZSKxm4c9YENc5fFj7mjWr/lbrGRmILz+VqM2GDNcPK0+6knBEsKvaSBANe5MRPh1+Q0UVRWC2FvK4rxCFCLv3p7nEpWiAGb92AQ07KIrUEPZcCQrAgPtq6uYaLo0ytuYzzztxC+P3DXVkxdQvR7VsnmxSx/hZ6uEcYf/suDajcJi0CzJJJW0NvFmDsTkYBGC7fB2iz5U5BTAz0FOKSt5erBEkLdLoI78/7GRc5I5g87X4Pegba4CLuthIskbkYAcESTXz5k1J+1SFGg8Ectlpy/mkCyV/Mk+ZFY/YQGBhRTO19qN9TwBGOiCbClatLdtuDPN82l0qIDuilQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r+hTxJNTEDvZMRAcnSSFx66gX6XkBALCTM+wQLOjqmo=; b=fkhQtI8BkzVVln4JksFSaDwSw1pduxVZMm/0a8BenTfJXav5woS1SBEacHpzi+VYasD5OM5UtoqeYeZgaC5rSt7qv9O1M3JpUTNbAUpds6jTaO0olOzHMFAyywlHJR8ryBT9WtJYvlN5+sBjDKtl1BHWPFj6nX61uvjIJfyw8qdf5ZjJwoPNHkUiyW9NYIQeYOXAoTQPVcjIb8qpyC+6Ht6qaGtYf8up6U7c3NF3lZVob5FnebDiafnRDQweJR6i02q1S8XMQ/jNT7yNc3Lv8/tFruzXsMkowLVNuDz9l+DNJ38/ZfNAZDab/KS99zAKe7iwTeDpF1k4yjSAORf/ug== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 1/4] xen/arm: its: initialize host LPI state before activating ITSes Date: Tue, 22 Sep 2026 18:58:39 +0300 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0020.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::17) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AMBPR03MB11360:EE_ X-MS-Office365-Filtering-Correlation-Id: 8ba07f7f-a4cb-479e-6683-08df18c2698e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|6133799003|18002099003|22082099003|11063799006|56012099006|10067099003|3023799007; X-Microsoft-Antispam-Message-Info: dmSf6e4c+BUg+mBY3WaqWeM5dp5EZt5s2imhBL/6VIvTcXr5bQyN90eiy6CjjQ/C12pEUTkLjAjwWa3qdWIGSCNSNuyEvJhxW8F17GuNv+CiTNJ5J6CYdnzSRJmguMJvQG+Ob0zihkcL0AYVrRK2ZUUx0Vi05BllmP6GeRfwoajq5xbeFz3TdivUP634kThqDz8UyKfUTBNosd+IEWEoVm74+QG9F0VQMUwmnUJnhlFRFf4Oj04nR1VQ2DjIW2dox6n7y8XEQfGyUJ2oLBfT5IQOujMt/aGqDQDYV8bLN042yVo3ZTKiCiGd4ROuv3sMxmEGIi6s06bnA8V7ggiWb+qyiG11/LL56fESkbM35gMjkr+q8TXGIKiw5Ixs/wITDzxxxSy1rEpIjAL93zPbwBztB2ndUBrjwGvihR7xK5PXXreYn1Ctx46M/5CsUtbBYInzcM8YhMLT+dE4AVNt6Bzyee5Mohk+EU1B5tlNeXw6V9BaHgcRg2Bi791gKWNpTC4lgt0KrtLjDCQEmgxQfdQf8lsb3oEIyxCQ/nbZU4QKSE4f/o3Qm7FKimLs50JKmD3uWb0wonJhxG5u0r8+2iJkEQIl20/GcWcPdvuLHeVzZg9L+Np9Bxwnqwk3yjMU X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(6133799003)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?83OeXx1cg9ErD5uByvrXcHwcoaPaHu9wdDOycyQBd1u4UQAMQKbEI8Ghakw5?= =?us-ascii?Q?6IsPq+JC+oSIr0IBJfKQN/2Dl0K9f4FmviJZ6NjA9KUdssxHfL4vBMWduK4H?= =?us-ascii?Q?KHTvD+NmP7ADxbUO2NzrcC0LhmO8biQ+RBmcQ5inwZw8BEuKGaum8xjRlXVH?= =?us-ascii?Q?8aLbkaZlUu+S1jUzfoDNwewY8/3g63Rdrbv06b81E8eVxBRWgu0HDg7vQl1c?= =?us-ascii?Q?7KO6CI9TfiwGTzIVyzol5ymIMneD25LIN5CpSlFMrOXusNF/wQv2FzbQQMaY?= =?us-ascii?Q?1QQrqgwW+6aaDuMW2pAqWXQOMOFCTZ5a9v5HjdWvbmuFYUCGrXGsoJau/2kn?= =?us-ascii?Q?lx/0HUjBRZXb0K5uJ018/7sMhrh4YD6aOT8g2nGEDrOhzKPxggyDq3ZjeHEU?= =?us-ascii?Q?3Ml3DF5b7lH+7bL0AxHeMpeAb4Z47fp5IB/heBW8ssPz2wNF9ROdIOO4ocSC?= =?us-ascii?Q?9STVhLHKS03nve7xU2XWQ+V3vZYGU5C/0OKhfqVs8TCWKuYdnYepiMYZvkZN?= =?us-ascii?Q?nWdQ+9XsVxejmZ8M4LU2CkrQxrKdjbku+0jQA6sFX5X91/g76+xKGIrHG/9S?= =?us-ascii?Q?Vxqx9sXKdGrLndFsF6oJcYJIeduEO0TrmFxqDJ8GJQkCb0O89IIvEnCEuNJG?= =?us-ascii?Q?Ofv0GODynh66qcos/ApfM0ZrAnsXgZ2+9wALt6drVOkLCBdUt5omcMgCva3P?= =?us-ascii?Q?oiE/BTfPsK2Oz81KkxSQpa31ybDN8AP1JhTuiE742XJ87N2jWAG4wN3On8B7?= =?us-ascii?Q?6FKkxOrFjS64WrqLeyjX7RwoyG4AcAmhgz5F5SPGLbXVdO50+hYh03903xks?= =?us-ascii?Q?6PP0uVB53K9Wc9UCA7DxFyicVpW0Qwdms2pSyJEWdY0YAmEFEgGg1e80qq8u?= =?us-ascii?Q?yjLBEAtqzhmJuAoTgVMF4wfcoE6aBXQUKGxa4b77xZU1dW8lqYRavTGyLkC1?= =?us-ascii?Q?maoHlJjaH8ux/QN8QeY/Nr56NP+S3Hmo+kN4wLotrzJY8iZ2ndqrKIWeh7M/?= =?us-ascii?Q?MSPxXvqT8WvmZ7Wsk+uNwwAZ6LNPX5t0VD6xi4JBW1316Y3jMW6eFbbdT3Tl?= =?us-ascii?Q?fE6H2eIvbVtPacxnZOvY0ozG+zEDaTCS/5BbHv6GeWASnPiOedClK3Yvl7mX?= =?us-ascii?Q?fvMBCIl0pkFXy9HxKBYu6xtRPl36YAva2tydtKhYqsgKj0O2qlkbyr/e0+p1?= =?us-ascii?Q?oz2EevfWU33LLZ2Nj16hw3HJNlGy4/lztQKe7OLoeYu3ujlboCHwxLQ62fIS?= =?us-ascii?Q?2ibOYAznvMuWJ2l7GXApm2TiLoUIfsRlJzaWD2tipM+HJQ4jPa/OK2TecFKf?= =?us-ascii?Q?sLdm50EKaaC55xWEPTxACVAw5U8aKeK2x1p01mk2M+CuAndI9mfiisQlgVeE?= =?us-ascii?Q?gMk04FIvz1stXSCjZfLPrDJeaG1o4cCQ5VKVC+tDs1yslPWnW1xCKeCe3iN2?= =?us-ascii?Q?nV1cOy9LZ8d+2ClVeyBZydykNxXeupCMlzq+sGwL4Fv2piOwQOP1XUkVUIKD?= =?us-ascii?Q?M6DLnOnrM/MjglATarJ6nj6eTMSdlQGCRH6c9CYIuVq6o+Yb8YtucqccZSpF?= =?us-ascii?Q?uwGmF34TsjfogxDmvCEVHcr0gDn0YJKkQzBfYm3K1KYwhnG3RapD7Mi0Qnxs?= =?us-ascii?Q?lPQWBNx+uQ1qO1ARJa/KHic6h4aEBHnF3KXtW413Z7IPnvO38R9dJ7yXJs5H?= =?us-ascii?Q?j5log63xGsu11bdCcG+REOCtY2yTPJsV1VjbbrZCNbG5nKXYr7D+IVN/yGgE?= =?us-ascii?Q?ojk1WPiQAA=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ba07f7f-a4cb-479e-6683-08df18c2698e X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 15:58:58.4592 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QrjQ1c5j0ojhOtN9po1Gn7KUPkBffoqg4nPpqJQ0sxbsq/IAflCXwoZcOVC4ZTAcHhh0t87JX5iS5rf2VyTPAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMBPR03MB11360 X-purgate-ID: tlsNG-33051d/1790092740-75EFF4E9-6CF776A8/0/0 X-purgate-type: clean X-purgate-size: 5341 The boot CPU pending table must use the memory attributes selected by ITS quirks. gicv3_lpi_init_host_lpis() is therefore called after gicv3_its_init(). However, gicv3_its_init() also programs and enables each ITS before host LPI state is allocated. No ITS commands are submitted at that point, but this ordering relies on that implementation detail. Split per-ITS initialization into preparation and activation phases. First map and disable every ITS and collect its quirks. Then initialize host LPI state. Only after that, allocate and program the ITS tables and command queue, and enable each ITS. The subsequent gicv3_cpu_init() sequence remains unchanged: it programs the Redistributor LPI tables, enables LPIs, and then submits the first MAPC and SYNC commands. Suggested-by: Julien Grall Signed-off-by: Mykola Kvach --- Changes in v3: - New patch implementing the post-4.22 initialization order discussed during review of the ordering fix. Link: https://patchew.org/Xen/341edd8de63dcd84ccc6e7b6c03e9e8fc7105184.1781847061.git.mykola._5Fkvach@epam.com/ --- xen/arch/arm/gic-v3-its.c | 32 ++++++++++++++++++++++----- xen/arch/arm/gic-v3.c | 15 ++----------- xen/arch/arm/include/asm/gic_v3_its.h | 4 ++-- 3 files changed, 31 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c index 325835b0ad..972825bf06 100644 --- a/xen/arch/arm/gic-v3-its.c +++ b/xen/arch/arm/gic-v3-its.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -549,10 +550,9 @@ static int gicv3_disable_its(struct host_its *hw_its) return -ETIMEDOUT; } -static int gicv3_its_init_single_its(struct host_its *hw_its) +static int __init gicv3_its_prepare_single_its(struct host_its *hw_its) { - uint64_t reg; - int i, ret; + int ret; hw_its->its_base = ioremap_nocache(hw_its->addr, hw_its->size); if ( !hw_its->its_base ) @@ -564,6 +564,14 @@ static int gicv3_its_init_single_its(struct host_its *hw_its) gicv3_its_enable_quirks(hw_its); + return 0; +} + +static int __init gicv3_its_init_single_its(struct host_its *hw_its) +{ + uint64_t reg; + int i, ret; + reg = readq_relaxed(hw_its->its_base + GITS_TYPER); hw_its->devid_bits = GITS_TYPER_DEVICE_ID_BITS(reg); hw_its->evid_bits = GITS_TYPER_EVENT_ID_BITS(reg); @@ -1189,7 +1197,7 @@ static void gicv3_its_acpi_init(void) #endif -int gicv3_its_init(void) +int __init gicv3_its_init(unsigned int host_lpi_bits) { struct host_its *hw_its; int ret; @@ -1201,13 +1209,27 @@ int gicv3_its_init(void) list_for_each_entry(hw_its, &host_its_list, entry) { - ret = gicv3_its_init_single_its(hw_its); + ret = gicv3_its_prepare_single_its(hw_its); if ( ret ) return ret; } gicv3_its_validate_quirks(); + if ( list_empty(&host_its_list) ) + return 0; + + ret = gicv3_lpi_init_host_lpis(host_lpi_bits); + if ( ret ) + return ret; + + list_for_each_entry(hw_its, &host_its_list, entry) + { + ret = gicv3_its_init_single_its(hw_its); + if ( ret ) + return ret; + } + return 0; } diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index acdac22953..6bc3e313be 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -1984,20 +1984,9 @@ static int __init gicv3_init(void) if ( gic_dist_supports_lpis() ) { - res = gicv3_its_init(); + res = gicv3_its_init(intid_bits); if ( res ) - panic("GICv3: ITS: initialization failed: %d\n", res); - - /* - * Host LPI allocation uses ITS-derived memory attributes, so defer it - * until after gicv3_its_init() has discovered ITS workarounds. - */ - if ( gicv3_its_host_has_its() ) - { - res = gicv3_lpi_init_host_lpis(intid_bits); - if ( res ) - panic("GICv3: LPI initialization failed: %d\n", res); - } + panic("GICv3: ITS/LPI initialization failed: %d\n", res); } res = gicv3_cpu_init(); diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h index 02c083f210..e1322b94f8 100644 --- a/xen/arch/arm/include/asm/gic_v3_its.h +++ b/xen/arch/arm/include/asm/gic_v3_its.h @@ -156,7 +156,7 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base); /* Initialize the host structures for LPIs and the host ITSes. */ int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits); -int gicv3_its_init(void); +int gicv3_its_init(unsigned int host_lpi_bits); /* Store the physical address and ID for each redistributor as read from DT. */ void gicv3_set_redist_address(paddr_t address, unsigned int redist_id); @@ -245,7 +245,7 @@ static inline int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) return 0; } -static inline int gicv3_its_init(void) +static inline int gicv3_its_init(unsigned int host_lpi_bits) { return 0; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:59:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:59:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429189.1652115 (Exim 4.92) (envelope-from ) id 1x92tZ-00052l-FU; Tue, 22 Sep 2026 15:59:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429189.1652115; Tue, 22 Sep 2026 15:59:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92tZ-00052e-CJ; Tue, 22 Sep 2026 15:59:01 +0000 Received: by outflank-mailman (input) for mailman id 1429189; Tue, 22 Sep 2026 15:59:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92tY-00052O-Do for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:59:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92tX-0051tn-3A for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:58:59 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2a5b1-2eae-0a2a0a5409dd-0a2a4505e8b2-34 for ; Tue, 22 Sep 2026 17:58:58 +0200 Received: from [52.101.70.73] (helo=AS8PR04CU009.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2a5c2-4cb1-0a2a45050019-346546493c53-3 for ; Tue, 22 Sep 2026 17:58:58 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by PA4PR03MB7454.eurprd03.prod.outlook.com (2603:10a6:102:e7::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 15:58:56 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 15:58:56 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EjGhAmv94wQwmbQTPoWivMOmGv5se1OtwgRUoDFHUOZdHF88/6g58lXk0WB85B/SbaCFOy8VIRBtRQejKbh4v2Jv23Y0+rVvYIjCR75LuPLcTD8mYe8vZmSBXzha9qI+N7U5eTil9Z/pwODt9XXhy7YfO3u+tL3Gb4QL3ooxZzv7m4fGRj+5KRYoym/q4mz4nfKV/uov5/13+BMJVMVPHQEq6D5jLQWAE6fPmf6HHVIm+Mahcki0iSNnelVRY+QPArwCwBwUw5zZmZPOHZQEpDp+gETZz66CW5i0y99bEZWEMS77nQbA9PHHa1AFrOA1wBp9ggum7QQrc4pL30g+6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xa+6kpBTzi8jr+B+8LiuaqduRKG8Hj8+jv1H6RbdqYY=; b=xiS3yTCOQb6Z663FPFDoXlF4rHkf4sbhudZGUBlFHawmJS1bGf6ACBYXhs6eiLujsr71sPAATdUf2Rlb8LQWoNTWiF8IzmueiHCUGGMwNpLux4TEhNmrqe7XrzNo5FY1T5e2w7o6QtR22XsTacNbcmqavOyW0XZVI79g5qmLjue2ONvkdwsOUQKM7+IiTTT9fxjVbxCIQGO0b/bBW751BqL6ETvOEoH13nQNPgzBMeuGdPvM4GWXX8uKId01D5R9Q1RHTGnEvos48Ia8uNnWNwa0itaJ21SepIB6crAarBoH+9ydcpjb0OQs5eF39n65kA3Lq+IxaSSvXNQZEYQleQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xa+6kpBTzi8jr+B+8LiuaqduRKG8Hj8+jv1H6RbdqYY=; b=B/RVCT1FPTPRGZr+0HsWLQodn6y6wKIlQHijcP5wnGcquRdPDiSC42p9iiWoWE4ttFUZytbR0ePylOztnyutNuCBMXBWvCkjDP8ik4/PlMgOTo18tL4g+QIpAw9sotttoQdygMKyAiqR2HWpfCdildN2rROWYbOD3HIq+yK8amXIrUTOZXrA2MJggrCVDRKxYWoITU4KZXXQ1BMSpciWty50GXzUzI/WoooHbooJ6W7kPqk8slRQ0ZLJPFELldTqHILn2mNaejZJorwBr0LznKnq4whVkNaCo/tI6SS/QhDs01pe0YVz/7m0raJgNVMWRxiwXW+0PhVcvWM48Xqi1g== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 0/4] xen/arm: gicv3: defer host LPI init and split ITS/LPI quirk scopes Date: Tue, 22 Sep 2026 18:58:38 +0300 Message-ID: X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0020.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::17) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|PA4PR03MB7454:EE_ X-MS-Office365-Filtering-Correlation-Id: c7539e0b-313d-4ab2-4d8e-08df18c2684f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|3023799007|6133799003|11063799006|10067099003|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: iK3NI73cXfMP0vGDqdqsyBSEKd44ENGWRw6MiWeWmQCPbcbk2GmjdkiZ+100QgWvnWZihc2Yka7ZakHlvormB0TnR01zwSLpDYRkFEH7Bg1KBvKzJi3NoI4irbaHRfrxZgj24Vdj6qYAD4G0EK6m7GxnVlPxCDWlKdWp8xstkTcEWKysNxJsB61quldLV22meml7pSuE3aKOFEfAaEr1pzuiOTP1rw8ShKLYn1DpPXaYy2yu+I5rR/+4CsnyYcGucryKxe2muL7mh/ipSb8G5m/83Xdw3yH2rnq28POX1bvfP1e1Uz0LmX1QJqBkjYkwVhjwplsyVpi5SAbx2XrU5WGkO1jILRXayYejtAiQ95cCqNaorpivcP6vkU5oJ0TW80Z7gJQ5A45lVIe/IPM5j225v2f5cnffHEHIhrnckZPDpxqgIrtrb5ySDnPc9Bh6wS7Y31KnxsmzqNDUyqtERjj9Kut7oB9E7i3gqnq7hMMMdecqvHQ47WuuyXH17UnchjY/YguHo0q8uLxnk+FEedj4d22MXYfWYkyvsMB7KL2RVn8pzVLkKXz1C2dLh/ZzHJIXZI0PvM3cE5qTam5aQDxMISbciJKBh68+7byWV2ipcHCssoxl/R7csDWjrVXESkSCCBY8BdamXNpOfslvP7VhAZamVxgg4TZFDzvyuh0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(3023799007)(6133799003)(11063799006)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?luch2lsej+wY0/qWj45QsfqVD1pMsjbpy40Kdj55lYkxfENTx6FwNq0SDhiq?= =?us-ascii?Q?qdi6E6XaES+tzl5SygkdxNZfOGSP1KT11nbvGWwYE+ByXqVBMJE1I7LDS/Xx?= =?us-ascii?Q?tlgwHEE/OOQkPh/r5LO38GEH2V7lF5UYPGdlRp7EbKvLpqiq0l3skO/gOZa7?= =?us-ascii?Q?QdWVdVo2DlHXrcXBMoWFbOjHHaCAKySOEGYeQoP1FJfJuFq+gTKzvGKeycj8?= =?us-ascii?Q?d+lCFg9JEbDXJUH5CMrzuPwWcrk+Ah/I2tEMpo9osMqjBayJS6HBboNGQrTZ?= =?us-ascii?Q?rUjVner9aSr2RrlNSBaZwXJCXdjtPcuziPZwq3nua4GjzGqj6NimyNaczOP9?= =?us-ascii?Q?fCA9+p7LPLwV4Kmhs6fBUImSsfKUQdpgdudazHIQbS8jl6tMQ68NaE+GmWKW?= =?us-ascii?Q?2prSoP+HdSSB+nCzFzbJ/j4maUihTWvTK9LCM/XcO5HAzi9Ozx6et3D+jxZK?= =?us-ascii?Q?GMbou+jULDRUX4yW+Oc9mh4P/xiqC/CbGvFu3guv9um71l8nsBauWkLqdheo?= =?us-ascii?Q?4GLbKSulhDHdVvUSMseES5eLbgIOTe7O30xZLeWSvowx/uUztMJ3NSivFij3?= =?us-ascii?Q?55sUIEd5df6HxV0GJzM6IO9s65sWCsmyBAWuPr8S/3APJPIPpY1LKwnIRmtz?= =?us-ascii?Q?2nmN8xT28uZqhm5x9FaS3hZutoQlg6vDM1bfGzfF15/yTKxcjPXjW4moaiS4?= =?us-ascii?Q?siqX/RzyOnC505o4LKWSGdwRBP4sIAgNgNj6vWbffeQdJFZX3DqfKP8MWO/i?= =?us-ascii?Q?3hQUOR0J+FYQBKXkguxIK97JL4hFzSI+K7iQs5smT2jF3BpLv7vMQPtzWZB/?= =?us-ascii?Q?ppqtq6/xGtzfXdc1bL1lOXEjazMScMn5axIAmZIvKYPAZ+YI8+VVlsJIfqlN?= =?us-ascii?Q?YWVSqlKtQN2x4TgfTWJlrwl6EmYdw+zG+JBTxHTXnnK3SWtud5drOp6sqOnS?= =?us-ascii?Q?FgQX5hpMoLwyk2r/M7KwT027s29U0h1TBo7kq53ocMUzyEAhXMdZgWzgBi11?= =?us-ascii?Q?+b5KcHUGr6hqjsbufo0Kp3fkiHtYU6qWg+evkqc3DioFr+gr3DNV1ZpPST8F?= =?us-ascii?Q?EhcEsbSd3CeGEdMNYdt5TGfQWHUhohMmTrj2oURRZ0d7RasShuOLDIT5Xh2K?= =?us-ascii?Q?FIHutISr7hrR3Hd9e+JOQzGVIWeZ86DPN59tw5rRN74MBYZSanl9OhfRgeln?= =?us-ascii?Q?UCn2SHAzScfJvyUaioVJZ32oEse21t1lXWwIr7rBH5yeE6RO7UfOKZaZWVxe?= =?us-ascii?Q?ENJfv/o+vhj+TJkTLBfLbH4uoRmOzRTNQ2d22JjgJPjPKx/Ne2ESrfb8C+QW?= =?us-ascii?Q?vLk3QjtqtKIXr3PlfseqgmDm7m7kUhaVX/BAxe5sqEexFLRudQxdBUSP9KOM?= =?us-ascii?Q?b8p6Czm9nZABU2Gqro8uqdj0gyuROSjIfleK0X+SXHCvRM785xmUNhlxFR1H?= =?us-ascii?Q?wh4ygJurPCsikw/nYsf03vgh3wQqVSNPwJibhkbZs7ndFAsZlA5hEWGht87I?= =?us-ascii?Q?Z8STjqlHFTr2kECCS0sPvLu0sv53P+/7RwP2NrCBcqiFaPst/JuXzAThYX/o?= =?us-ascii?Q?D9jT4HfunkvUpZjvRYMyfydkv7GO2QkXE3wSVXGrZEV2GGVLRcQOJ8W7goW7?= =?us-ascii?Q?2zVpRtZcXRiQQRr3RdG2JuB+CEDzuqoHoU+kovMlvBXlAkx4hYovgFAYz1Bm?= =?us-ascii?Q?Y1J0N4yPH4EsQc8FzqwdJ7kLPtP7KV3VbBUZLLr+N2RjinWcEGUgzgkGag/e?= =?us-ascii?Q?GEmJkndM/g=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7539e0b-313d-4ab2-4d8e-08df18c2684f X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 15:58:56.4890 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ZIDbIIpwT3zvS8Eqe8I2Yszi/a1RqXxQMLt+UJ8llJBfVtVaO/6D3DnEsajSWAsrnyXBIyh2IaGk22uK/eWW2w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7454 X-purgate-ID: tlsNG-c201ff/1790092738-F46A52A1-83ABC2E8/0/0 X-purgate-type: clean X-purgate-size: 5318 Hi all, This series reworks ITS and host LPI initialization, separates ITS-private memory restrictions from host LPI/Redistributor restrictions, and adds support for the DT dma-noncoherent property. Patch 1 splits ITS initialization into preparation and activation phases. The preparation pass maps and disables each host ITS and collects its quirks. Once all host ITSes have been prepared, host LPI state is initialized, including the boot CPU pending table. Only then are ITS tables and command queues allocated and programmed, and the ITSes enabled. This sequence is coordinated within gicv3_its_init(). The subsequent gicv3_cpu_init() sequence remains unchanged: it programs the Redistributor LPI table registers, enables LPIs, and submits the first MAPC and SYNC commands. Patch 2 replaces the global ITS quirk state with per-ITS flags and a separate host LPI policy. Per-ITS flags govern ITS table, command queue, and ITT allocations, and the memory attributes programmed into GITS_CBASER and GITS_BASER. Host LPI flags govern property and pending table allocations and the attributes programmed into GICR_PROPBASER and GICR_PENDBASER. An ITS-discovered quirk contributes to host LPI policy only through its explicit lpi_flags. Per-ITS flags are not implicitly aggregated into that policy, and different ITSes no longer have to share the same quirk state. Patch 3 replaces the fixed IIDR/mask fields in the quirk table with a match(hw_its, data) callback and an opaque data pointer. A reusable IIDR matcher is combined with platform checks for the R-Car Gen4 entry. First-match semantics are preserved. The R-Car Gen4 entry matches only DT-discovered ITSes with IIDR 0x0201743b on machines compatible with renesas,r8a779f0 or renesas,r8a779g0. ACPI-discovered ITSes and other platforms with the same IIDR no longer match this entry. For matching systems, the non-cacheable/non-shareable attributes and 32-bit allocation restrictions are retained in both the ITS and host LPI scopes. Patch 4 handles dma-noncoherent independently of platform quirk matching. A property on an ITS subnode affects only that ITS. A property on the top-level GIC node affects only host LPI/Redistributor policy. The property is not inherited between the nodes. It selects non-cacheable/non-shareable memory attributes; it does not impose a 32-bit allocation restriction. --- Changes since v2 * Split ITS initialization into preparation and activation phases, with host LPI initialization between them inside gicv3_its_init(). * Collected quirk flags during ITS preparation. Kept the ITS init-only annotations in the initialization patch. * Documented the intentional narrowing of the R-Car Gen4 match, including the exclusion of ACPI-discovered ITSes and other platforms with the same IIDR. * Added the non-debug NULL-data guard to the IIDR matcher and placed the matcher data and quirk table in init-only read-only sections. * Dropped the redundant aggregate host-LPI-flags log message --- Changes since v1 * Reordered the series so that the minimal host LPI initialization ordering fix is first. Patch 1 is intended for 4.22. * Dropped the v1 ITS pre-initialization hook. * Moved the existing gicv3_lpi_init_host_lpis() call after gicv3_its_init() instead, so host LPI state is allocated after ITS workaround discovery. * Checked the return value from gicv3_lpi_init_host_lpis() and made failure fatal once the ITS/LPI path is enabled. * Replaced the old single global ITS quirk state with separate per-ITS and host LPI quirk scopes. * Removed the implicit aggregation of all per-ITS quirks into the host LPI policy. Host LPI effects are now expressed explicitly with lpi_flags. * Kept per-ITS flags for ITS-private allocations: - GITS_CBASER; - GITS_BASER; - ITT memory. * Kept host LPI flags for Redistributor/LPI state: - GICR_PROPBASER; - GICR_PENDBASER. * Refactored ITS quirk matching from fixed IIDR/mask fields to a generic match(hw_its, data) callback plus opaque data. * Kept first-match semantics explicit. More specific entries must be listed before broader IIDR-only entries. * Added a reusable IIDR matcher and used it after checking the Renesas machine compatibles for the R-Car Gen4 quirk. * Split dma-noncoherent handling by DT node scope: - ITS subnode dma-noncoherent affects only the matching ITS; - top-level GIC dma-noncoherent affects only the host LPI/Redistributor policy. * Dropped the Orange Pi 5 / RK3588-specific quirk patch from v1. The non-coherent GIC integration is now handled through DT dma-noncoherent properties instead of a Xen-side platform quirk. Mykola Kvach (4): xen/arm: its: initialize host LPI state before activating ITSes xen/arm: its: separate ITS and host LPI quirk scopes xen/arm: its: refactor ITS quirk matching xen/arm: its: handle dma-noncoherent on GIC and ITS nodes xen/arch/arm/gic-v3-its.c | 203 +++++++++++++++++--------- xen/arch/arm/gic-v3-lpi.c | 65 +++++++-- xen/arch/arm/gic-v3.c | 15 +- xen/arch/arm/include/asm/gic_v3_its.h | 22 ++- 4 files changed, 210 insertions(+), 95 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:59:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:59:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429191.1652133 (Exim 4.92) (envelope-from ) id 1x92th-0005WC-5B; Tue, 22 Sep 2026 15:59:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429191.1652133; Tue, 22 Sep 2026 15:59:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92th-0005Vv-21; Tue, 22 Sep 2026 15:59:09 +0000 Received: by outflank-mailman (input) for mailman id 1429191; Tue, 22 Sep 2026 15:59:07 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92tf-0005Td-IA for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:59:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92te-00ATp7-VF for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:59:06 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2a5ba-2eae-0a2a0a5409dd-0a2a450ac088-26 for ; Tue, 22 Sep 2026 17:59:06 +0200 Received: from [52.101.84.73] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2a5ca-f2d2-0a2a450a0019-346554496212-3 for ; Tue, 22 Sep 2026 17:59:06 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by PA4PR03MB7184.eurprd03.prod.outlook.com (2603:10a6:102:106::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 15:59:04 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 15:59:04 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YcestljPpgEzMGIdiNF/yvGFMHoi8ed5WmYfIkjO3W3PXBiIz56ao/q+C8IAYUTWdY49dbyD9Vb92azCc4KCML7HfLld/5XIP1Qr5/OISAuF8a23x37Lv6g9U17z8RhDfwt7wbIvFeVCK/UwTAFlKQhpp4ewguO0J9N1oF5QwEq97CdBh63C244t0ua6nfYZ5SzNQfzvjBOueWTGN1JHNIu+PMYZjFnTJtJ9vOWpBBFCGQprWHrps5vihL02rYxgAX9LDVZrbpGU2Vo0t7AkegnOPLJUb+mQ27qfEd9IBtmvdZ18AAQ4huIZQEkIKIgzVNJwKs4vK+HRCSupNywu2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+FVQkX0S+iPV6n7069bjHG6csiHA3mhUKGAwXPjaq78=; b=V29qp4t4n7+WGutb1lHpzHd9UfyFfe6W0gsDmc5nyMU/u0mEeljLxd/7nt5nRB6XKlMap0EEbvwTWzIsTZge+8S0wlvION5cXiu0g3kU0BlOBX+ERhOvwOws6yAU7NWpFkV5GczaeXTiNLYpDvXvIDHAlCOFE1m/tFSUXvJa+iIng+C7GH+TZJJSO7wZ88O3W2itpnrn1It7+OgCSqgI1jhcRbwCxyymueMZpYYrtcMilLiidhnDpMlH6+17FB9prGIFKMRzIXlH5MAb0M5p7KQadcJx/ZDc4/jQSvrpwhRtZXUrhTq6Jq3XcRg4Qh4C9iIaZvSFvD2Tt8ovBVOXWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+FVQkX0S+iPV6n7069bjHG6csiHA3mhUKGAwXPjaq78=; b=fmidiczxwYKaz8ocMKIF/mxaTI9kHbDbxP28LxO2C3GcbEzjLV3z6BG+d0Uu6py2FKNrzqZdQg/dCKosWrIZeDT1xV0UMHSB/XOt6a2HIdDO65P3nJG4cEEA++7ngvMD8imSCcArUI2sptpqkOi7g4qofH6Ghb89XvXUrj4GY4d+gDwzfbYO39rlpZU1c/PI3E6jy2ZjVFGVQLgWaU7TupswDalr+cUBlgK9znLlezl7jWwq/QD+uxBGkqbaHEpRdmbrs9bQyoylAMI6aR3t20vG8d0G4X+TLy/Iltem9gHJewgdxybUKG7Z6rm5MK3dFE5QUuzNkDly1oa/c4nYIQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 2/4] xen/arm: its: separate ITS and host LPI quirk scopes Date: Tue, 22 Sep 2026 18:58:40 +0300 Message-ID: <9de733816d356161c8bfa45171e0ddbba68021f2.1790089161.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0020.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::17) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|PA4PR03MB7184:EE_ X-MS-Office365-Filtering-Correlation-Id: 0d2744c9-88ae-471b-1ed8-08df18c26d2b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|6133799003|18002099003|22082099003|3023799007|11063799006|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: ZbykrZeKmt3v5c/I8zkajwY2zVt920jBsgj5gvKofAlsOunoqUrw3zzSvO6cFjMDe4AvLWirz/udIRFXOd4DImKIDReA5Zp+wNXl703/aXdMfgmLdqzQGh1m6W9ZIqQ6PpYXO9bp0zgkUZydZmEGt52euEgb3nINE0nOIrH17+kRODB8M2/kFQtgTRyDIjGQImlqJOhOUNxeeEcSo8SCpmziVyzomO1sppsT04VENfYDpkMXml5vfAwSHHnMqsHjMI6kNuc290IG3NMbCP65jZbeMgfFglgRfcUOJtt0x4/UIz5fglj/lUSc5ciWCCJSK/uP8TVBTdeHp7ob2iMOOEwdvGqCeyadWQWf+kI455q5IfDzQ90CkIoibJChc9neusIDX41W4O2ENydzYhlvhxZ0TQZTFZE87fjk1Xd9Lvt1LLDp/a1O++cj43DdfpCJu0tHna39WETlVVShEY7O7qDVommSsMusLDOS0ZY4APOzkKhdM9EWoMNILAK9jqrEoWLlxg3L57GTQBRHDkTyQmMRrIHZMOBlaFdxAPjQXoafA0jelTYWLzOTQBL1mOiuGHkyNFHVwUkdaZonxB+tKrnsp3thCrIViWqRAjiIuKvp6w8paT7V66IzfZFurahPkCjTVnMN9BPQBtAnsdJEmh5GKuF3Rwm/m0y/ViEx+uk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(6133799003)(18002099003)(22082099003)(3023799007)(11063799006)(10067099003)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?XYJUlYxlVFx6S7QxN8gkNct/MZ79LJpR3jaVySHJY78TlYRMOEUQO9jBLBQz?= =?us-ascii?Q?8sdM99rgu9otK/2gY/UbUO6Qt/sOMEKZeViDoCNmTXsZ4P6cEGkwCYrLKU7o?= =?us-ascii?Q?xYjGuoFCyRVZKeuaBddm4j6QktmmtwfoR0dTVIP0AoNIzSDoRCaD2qP4qwBq?= =?us-ascii?Q?knovUQU4+AVX0mYE8wGoFvOzQE0eRJgHIU447zai3KX/RFT6oQypfZEH4NAl?= =?us-ascii?Q?5u7Za+ZgS6AIpfNPJPPzXO7YtrPmMxCb9IZSClUydkZVMuNVbBBT9N7Cusc/?= =?us-ascii?Q?vRlsnN0vdX4qG/xzv6fYu+1WAjBdSE3Hf+mJAc5ccoZZY0oYe2aMiUkmxuHg?= =?us-ascii?Q?oji8zSGuIxvqjS+Vo2s5DxYCzF+N7VV3R+sjH9RsVSc+YIjjhiKpw8F2rc4C?= =?us-ascii?Q?4SeEdanyiPPclVqMqqKlUZZhE4NUaSpx8kSMrwnXStfvuCKKQF0aM/RyXC/+?= =?us-ascii?Q?XGqznlHJLC/fd87iN8ciz5rEUgJ8m9Atejso7neC21nGta99IvVVShBQOxRX?= =?us-ascii?Q?wAPN1YpdNPgilK2VIdMToLYUXV1bT8cmbbHHPhGdEfpRQGtKR+S2yCGLf5q2?= =?us-ascii?Q?+VxfNE7sBQi7EL/JZ1O7qtLyu6f+Z43huXoG5DDxxUZo/dUc3SBwvn9iN4CZ?= =?us-ascii?Q?VK+hdF027RvuFMmOW9oTD3w+b7sCvw3ViMfj1HKSZu9Ou1P/P4XKC7Z2oZ4M?= =?us-ascii?Q?JIV9gCGAQaQ2ZAHMFwiHJxOraG3BQPhu4MQ1yRaqSQG2Se2OQqWXehqSPo3X?= =?us-ascii?Q?PADSiP1XHoib93Hy26vbR5ar9bxRFVJpeRNr2zN69o8si8vNqyh2DyrvbNtq?= =?us-ascii?Q?iYOVeFd2hvUjH7Uq1ZlJK+3xTNyY8FN+1rT47olsBdie4Vdk6Ivf2jelH4FB?= =?us-ascii?Q?SMpIdwIJlsi4GPpL2Hhyie/cJaNrYCRpAAcW7HhiAs1GodxNIamY1jif6r21?= =?us-ascii?Q?AVqXzNEryXtXPl2bOfbb2466eYz3P7TL9+Qk28OpOMvs/UzRaRgMYigrOFrR?= =?us-ascii?Q?XAUEvLgFCWnuL/jsH2D5ndRM6M5e9zWUz7DYL7Vc/cfl3+EfYp0SY8qI0YIj?= =?us-ascii?Q?xLJzg08dI1uFvt9PlC/2kXMMG4o5/7lxLsuamPcypH3MWP4uurw+dkb5Cpzr?= =?us-ascii?Q?Sk3UIjy6JWiRWT2kVjy+/u4ynFznYStMzE1bVWPqr0UalWnugntzM/xThWLq?= =?us-ascii?Q?0R2SBTTafZwk50l33087CvCUZNRkGCRafPzRcmU6YsiFFWhrkUpL0kAK6gqB?= =?us-ascii?Q?iJ0wWVfdQcH1RYE53VMUaBnwudX4QLoswZVAQR4RDjvUGXhQW70+FPhZ5dDQ?= =?us-ascii?Q?P/JVsSZ0MT9iWxi08sujeqyjuD6L/UpN6zZKpHwkOpN7cltBv4Cj3+4Eq+2j?= =?us-ascii?Q?S4mHJD18YV30qgGCeWn0QJDWlTY21nt2sKiF6ur4k3IuwREOSGE1Zmn6Ksic?= =?us-ascii?Q?+qjpIrEEyWAPWSgvwd46zGk9rZDI20shWDtXDindXDHyZjlsZwoSaf/ZPOsz?= =?us-ascii?Q?te6/GIYSyF90f6g7onHOU9KmFVClDFeFfYkfn4fHI/gPusqZ6UwAh14olXhg?= =?us-ascii?Q?cfCVrPidKhuTl203RfwLd3mmvz4vjJW/GIfGLpDm1BhzOB+tj3CiruTLbRk/?= =?us-ascii?Q?Hyh0aPrNklpWE8RoroUOoW2Lv29UW6EU9gLnD7pNCmSJs6B52QYYlCzNzDNu?= =?us-ascii?Q?7KIGYadTL/eM16jwKFl5mzK6KiEU+0mheYRl6zoL/euTnh5w0NfikR1eZrGp?= =?us-ascii?Q?ea8+C4iTNQ=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d2744c9-88ae-471b-1ed8-08df18c26d2b X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 15:59:04.5485 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: pY7M8V8AgqUf55T9QhyJQRTKUmoIvdYYvdMHPi5R+g5x39m/AGPLI5fX5b0Es9Y8CxWHDTKNQCBF4cN9FlAl7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7184 X-purgate-ID: tlsNG-4011c0/1790092746-504CFCFC-E368911F/0/0 X-purgate-type: clean X-purgate-size: 18883 ITS quirks can impose restrictions on memory accessed by the ITS itself and on shared host LPI/Redistributor state. These scopes are not identical, so a single global ITS quirk state makes the host LPI policy depend implicitly on the quirks seen while initializing host ITSes. Add per-ITS quirk_flags to struct host_its and keep a separate host_lpi_flags state in the LPI code. The quirk table now records the ITS-private and host LPI scopes explicitly through its_flags and lpi_flags. The R-Car Gen4 quirk applies the same memory restrictions to both scopes, preserving the existing R-Car memory policy without relying on an implicit aggregation step. This also removes the assumption that all host ITSes must expose the same quirk state. ITS-derived host LPI restrictions are accumulated only from quirk entries that explicitly set lpi_flags. Use per-ITS quirk_flags for GITS_CBASER, GITS_BASER, and ITT allocations. Use host_lpi_flags when allocating the property and pending tables and when programming GICR_PROPBASER and GICR_PENDBASER. Memory-related quirk bits are named GICV3_QUIRK_MEM_* and are translated by shared gicv3_mem_get_*() helpers. Collect both scopes during the ITS preparation pass, before host LPI state is allocated. Keep init-only annotations and includes in the implementation files rather than the public header. Signed-off-by: Mykola Kvach --- Changes in v3: - Collect quirk flags during the ITS preparation pass added earlier. - Keep init-only annotations and includes in implementation files. Changes in v2: - Replace v1's single global ITS quirk flags and same-quirk validation with explicit per-ITS and host LPI quirk scopes. - Drop the v1 ITS pre-initialization approach from this patch. In v2, host LPI allocation was moved after ITS initialization by a separate patch. - Drop DT dma-noncoherent handling from this patch; firmware-provided non-coherency is handled separately with explicit ITS-node and GIC-node scopes. - Keep host_lpi_flags owned by gic-v3-lpi.c and update it only with quirk flags that explicitly apply to host LPI/Redistributor state. - Rename the current memory-related bits to GICV3_QUIRK_MEM_* and use shared gicv3_mem_get_*() helpers for register attributes and allocation flags. --- xen/arch/arm/gic-v3-its.c | 111 ++++++++++++-------------- xen/arch/arm/gic-v3-lpi.c | 45 +++++++++-- xen/arch/arm/include/asm/gic_v3_its.h | 18 +++-- 3 files changed, 100 insertions(+), 74 deletions(-) diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c index 972825bf06..454fd0e0ef 100644 --- a/xen/arch/arm/gic-v3-its.c +++ b/xen/arch/arm/gic-v3-its.c @@ -52,43 +52,40 @@ struct its_device { struct pending_irq *pend_irqs; /* One struct per event */ }; -/* - * It is unlikely that a platform implements ITSes with different quirks, - * so assume they all share the same. - */ struct its_quirk { const char *desc; - bool (*init)(struct host_its *hw_its); uint32_t iidr; uint32_t mask; + uint32_t its_flags; + /* + * lpi_flags are ORed into the global host LPI policy and must only + * contain additive restrictions. Non-additive LPI quirks need explicit + * handling. + */ + uint32_t lpi_flags; }; -static uint32_t __ro_after_init its_quirk_flags; - -static bool gicv3_its_enable_quirk_gen4(struct host_its *hw_its) -{ - its_quirk_flags |= HOST_ITS_WORKAROUND_NC_NS | - HOST_ITS_WORKAROUND_32BIT_ADDR; - - return true; -} - static const struct its_quirk its_quirks[] = { { .desc = "R-Car Gen4", .iidr = 0x0201743b, .mask = 0xffffffffU, - .init = gicv3_its_enable_quirk_gen4, + .its_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR, + .lpi_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR, }, { /* Sentinel. */ } }; -static const struct its_quirk *gicv3_its_find_quirk(uint32_t iidr) +static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr) { const struct its_quirk *quirks = its_quirks; + /* + * The first matching quirk wins. More specific quirks must be listed + * before broader IIDR-only entries. + */ for ( ; quirks->desc; quirks++ ) { if ( quirks->iidr == (quirks->mask & iidr) ) @@ -98,53 +95,38 @@ static const struct its_quirk *gicv3_its_find_quirk(uint32_t iidr) return NULL; } -static void gicv3_its_enable_quirks(struct host_its *hw_its) +static void __init gicv3_its_collect_quirks(struct host_its *hw_its) { uint32_t iidr = readl_relaxed(hw_its->its_base + GITS_IIDR); const struct its_quirk *quirk = gicv3_its_find_quirk(iidr); - if ( quirk && quirk->init(hw_its) ) - printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc); -} - -static void gicv3_its_validate_quirks(void) -{ - const struct its_quirk *quirk = NULL, *prev = NULL; - const struct host_its *hw_its; - - if ( list_empty(&host_its_list) ) - return; - - hw_its = list_first_entry(&host_its_list, struct host_its, entry); - prev = gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_IIDR)); - - list_for_each_entry(hw_its, &host_its_list, entry) + if ( quirk ) { - quirk = gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_IIDR)); - BUG_ON(quirk != prev); - prev = quirk; + hw_its->quirk_flags |= quirk->its_flags; + gicv3_lpi_update_host_flags(quirk->lpi_flags); + printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc); } } -uint64_t gicv3_its_get_cacheability(void) +uint64_t gicv3_mem_get_cacheability(uint32_t flags) { - if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS ) + if ( flags & GICV3_QUIRK_MEM_NC_NS ) return GIC_BASER_CACHE_nC; return GIC_BASER_CACHE_RaWaWb; } -uint64_t gicv3_its_get_shareability(void) +uint64_t gicv3_mem_get_shareability(uint32_t flags) { - if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS ) + if ( flags & GICV3_QUIRK_MEM_NC_NS ) return GIC_BASER_NonShareable; return GIC_BASER_InnerShareable; } -unsigned int gicv3_its_get_memflags(void) +unsigned int gicv3_mem_get_alloc_flags(uint32_t flags) { - if ( its_quirk_flags & HOST_ITS_WORKAROUND_32BIT_ADDR ) + if ( flags & GICV3_QUIRK_MEM_32BIT_ADDR ) return MEMF_bits(32); return 0; @@ -391,13 +373,17 @@ static void *its_map_cbaser(struct host_its *its) uint64_t reg; unsigned int order; void *buffer; + uint64_t cacheability = gicv3_mem_get_cacheability(its->quirk_flags); + uint64_t shareability = gicv3_mem_get_shareability(its->quirk_flags); + unsigned int memflags = gicv3_mem_get_alloc_flags(its->quirk_flags); - reg = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT; - reg |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT; - reg |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT; + reg = MASK_INSR(shareability, GITS_BASER_SHAREABILITY_MASK); + reg |= MASK_INSR(GIC_BASER_CACHE_SameAsInner, + GITS_BASER_OUTER_CACHEABILITY_MASK); + reg |= MASK_INSR(cacheability, GITS_BASER_INNER_CACHEABILITY_MASK); order = get_order_from_bytes(max(ITS_CMD_QUEUE_SZ, SZ_64K)); - buffer = alloc_xenheap_pages(order, gicv3_its_get_memflags()); + buffer = alloc_xenheap_pages(order, memflags); if ( !buffer ) return NULL; @@ -438,8 +424,8 @@ static void *its_map_cbaser(struct host_its *its) /* The ITS BASE registers work with page sizes of 4K, 16K or 64K. */ #define BASER_PAGE_BITS(sz) ((sz) * 2 + 12) -static int its_map_baser(void __iomem *basereg, uint64_t regc, - unsigned int nr_items) +static int its_map_baser(struct host_its *its, void __iomem *basereg, + uint64_t regc, unsigned int nr_items) { uint64_t attr, reg; unsigned int entry_size = GITS_BASER_ENTRY_SIZE(regc); @@ -447,10 +433,14 @@ static int its_map_baser(void __iomem *basereg, uint64_t regc, unsigned int table_size; unsigned int order; void *buffer; + uint64_t cacheability = gicv3_mem_get_cacheability(its->quirk_flags); + uint64_t shareability = gicv3_mem_get_shareability(its->quirk_flags); + unsigned int memflags = gicv3_mem_get_alloc_flags(its->quirk_flags); - attr = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT; - attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT; - attr |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT; + attr = MASK_INSR(shareability, GITS_BASER_SHAREABILITY_MASK); + attr |= MASK_INSR(GIC_BASER_CACHE_SameAsInner, + GITS_BASER_OUTER_CACHEABILITY_MASK); + attr |= MASK_INSR(cacheability, GITS_BASER_INNER_CACHEABILITY_MASK); /* * Setup the BASE register with the attributes that we like. Then read @@ -464,7 +454,7 @@ retry: table_size = min(table_size, 256U << BASER_PAGE_BITS(pagesz)); order = get_order_from_bytes(max(table_size, BIT(BASER_PAGE_BITS(pagesz), U))); - buffer = alloc_xenheap_pages(order, gicv3_its_get_memflags()); + buffer = alloc_xenheap_pages(order, memflags); if ( !buffer ) return -ENOMEM; @@ -562,7 +552,7 @@ static int __init gicv3_its_prepare_single_its(struct host_its *hw_its) if ( ret ) return ret; - gicv3_its_enable_quirks(hw_its); + gicv3_its_collect_quirks(hw_its); return 0; } @@ -592,18 +582,19 @@ static int __init gicv3_its_init_single_its(struct host_its *hw_its) case GITS_BASER_TYPE_NONE: continue; case GITS_BASER_TYPE_DEVICE: - ret = its_map_baser(basereg, reg, BIT(hw_its->devid_bits, UL)); + ret = its_map_baser(hw_its, basereg, reg, + BIT(hw_its->devid_bits, UL)); if ( ret ) return ret; break; case GITS_BASER_TYPE_COLLECTION: - ret = its_map_baser(basereg, reg, num_possible_cpus()); + ret = its_map_baser(hw_its, basereg, reg, num_possible_cpus()); if ( ret ) return ret; break; /* In case this is a GICv4, provide a (dummy) vPE table as well. */ case GITS_BASER_TYPE_VCPU: - ret = its_map_baser(basereg, reg, 1); + ret = its_map_baser(hw_its, basereg, reg, 1); if ( ret ) return ret; break; @@ -738,6 +729,7 @@ int gicv3_its_map_guest_device(struct domain *d, struct its_device *dev = NULL; struct rb_node **new = &d->arch.vgic.its_devices.rb_node, *parent = NULL; int i, ret = -ENOENT; /* "i" must be signed to check for >= 0 below. */ + unsigned int memflags; unsigned int order; hw_its = gicv3_its_find_by_doorbell(host_doorbell); @@ -801,8 +793,9 @@ int gicv3_its_map_guest_device(struct domain *d, ret = -ENOMEM; /* An Interrupt Translation Table needs to be 256-byte aligned. */ + memflags = gicv3_mem_get_alloc_flags(hw_its->quirk_flags); order = get_order_from_bytes(max(nr_events * hw_its->itte_size, 256UL)); - itt_addr = alloc_xenheap_pages(order, gicv3_its_get_memflags()); + itt_addr = alloc_xenheap_pages(order, memflags); if ( !itt_addr ) goto out_unlock; @@ -1214,8 +1207,6 @@ int __init gicv3_its_init(unsigned int host_lpi_bits) return ret; } - gicv3_its_validate_quirks(); - if ( list_empty(&host_its_list) ) return 0; diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c index 9ee338edc2..accfd48a74 100644 --- a/xen/arch/arm/gic-v3-lpi.c +++ b/xen/arch/arm/gic-v3-lpi.c @@ -8,6 +8,7 @@ */ #include +#include #include #include #include @@ -78,9 +79,29 @@ struct lpi_redist_data { static DEFINE_PER_CPU(struct lpi_redist_data, lpi_redist); +/* + * Host LPI flags are scoped to shared LPI/Redistributor state, not to an + * ITS instance. Arm IHI 0069H.b section 5.1.1 says "LPI configuration is + * global". Section 12.11.33 (GICR_PROPBASER) makes mismatched values + * UNPREDICTABLE for Redistributors that share an LPI Configuration table + * while GICR_CTLR.EnableLPIs == 1. Section 12.11.32 (GICR_PENDBASER) + * similarly makes mismatched OuterCache, Shareability or InnerCache values + * across Redistributors UNPREDICTABLE while GICR_CTLR.EnableLPIs == 1. + * + * Keep this policy in the LPI code and accumulate only explicit LPI/RD + * restrictions into it. Per-ITS restrictions stay in host_its::quirk_flags + * for GITS_CBASER, GITS_BASER and ITT memory. + */ +static uint32_t __ro_after_init host_lpi_flags; + #define MAX_NR_HOST_LPIS (lpi_data.max_host_lpi_ids - LPI_OFFSET) #define HOST_LPIS_PER_PAGE (PAGE_SIZE / sizeof(union host_lpi)) +void __init gicv3_lpi_update_host_flags(uint32_t flags) +{ + host_lpi_flags |= flags; +} + static union host_lpi *gic_get_host_lpi(uint32_t plpi) { union host_lpi *block; @@ -228,6 +249,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu) { void *pendtable; unsigned int order; + unsigned int memflags = gicv3_mem_get_alloc_flags(host_lpi_flags); if ( per_cpu(lpi_redist, cpu).pending_table ) return -EBUSY; @@ -239,7 +261,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu) * physically contiguous memory. */ order = get_order_from_bytes(max(lpi_data.max_host_lpi_ids / 8, (unsigned long)SZ_64K)); - pendtable = alloc_xenheap_pages(order, gicv3_its_get_memflags()); + pendtable = alloc_xenheap_pages(order, memflags); if ( !pendtable ) return -ENOMEM; @@ -262,6 +284,8 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base) { const void *pendtable = this_cpu(lpi_redist).pending_table; uint64_t val; + uint64_t cacheability = gicv3_mem_get_cacheability(host_lpi_flags); + uint64_t shareability = gicv3_mem_get_shareability(host_lpi_flags); /* * The memory should have been allocated while preparing the CPU (or @@ -275,9 +299,10 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base) ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16))); - val = gicv3_its_get_cacheability() << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT; - val |= GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT; - val |= gicv3_its_get_shareability() << GICR_PENDBASER_SHAREABILITY_SHIFT; + val = MASK_INSR(cacheability, GICR_PENDBASER_INNER_CACHEABILITY_MASK); + val |= MASK_INSR(GIC_BASER_CACHE_SameAsInner, + GICR_PENDBASER_OUTER_CACHEABILITY_MASK); + val |= MASK_INSR(shareability, GICR_PENDBASER_SHAREABILITY_MASK); val |= GICR_PENDBASER_PTZ; val |= virt_to_maddr(pendtable); @@ -304,10 +329,13 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base) { uint64_t reg; unsigned int order; + uint64_t cacheability = gicv3_mem_get_cacheability(host_lpi_flags); + uint64_t shareability = gicv3_mem_get_shareability(host_lpi_flags); - reg = gicv3_its_get_cacheability() << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT; - reg |= GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT; - reg |= gicv3_its_get_shareability() << GICR_PROPBASER_SHAREABILITY_SHIFT; + reg = MASK_INSR(cacheability, GICR_PROPBASER_INNER_CACHEABILITY_MASK); + reg |= MASK_INSR(GIC_BASER_CACHE_SameAsInner, + GICR_PROPBASER_OUTER_CACHEABILITY_MASK); + reg |= MASK_INSR(shareability, GICR_PROPBASER_SHAREABILITY_MASK); /* * The property table is shared across all redistributors, so allocate @@ -317,9 +345,10 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base) { /* The property table holds one byte per LPI. */ void *table; + unsigned int memflags = gicv3_mem_get_alloc_flags(host_lpi_flags); order = get_order_from_bytes(max(lpi_data.max_host_lpi_ids, (unsigned long)SZ_4K)); - table = alloc_xenheap_pages(order, gicv3_its_get_memflags()); + table = alloc_xenheap_pages(order, memflags); if ( !table ) return -ENOMEM; diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h index e1322b94f8..9230705181 100644 --- a/xen/arch/arm/include/asm/gic_v3_its.h +++ b/xen/arch/arm/include/asm/gic_v3_its.h @@ -110,8 +110,9 @@ #define HOST_ITS_FLUSH_CMD_QUEUE (1U << 0) #define HOST_ITS_USES_PTA (1U << 1) -#define HOST_ITS_WORKAROUND_NC_NS (1U << 0) -#define HOST_ITS_WORKAROUND_32BIT_ADDR (1U << 1) +/* GICv3 memory-related quirk flags. */ +#define GICV3_QUIRK_MEM_NC_NS (1U << 0) +#define GICV3_QUIRK_MEM_32BIT_ADDR (1U << 1) /* We allocate LPIs on the hosts in chunks of 32 to reduce handling overhead. */ #define LPI_BLOCK 32U @@ -128,6 +129,11 @@ struct host_its { unsigned int itte_size; spinlock_t cmd_lock; void *cmd_buf; + /* + * Workaround flags scoped to this ITS instance, including memory + * accessed through GITS_CBASER, GITS_BASER and ITT memory. + */ + uint32_t quirk_flags; unsigned int flags; }; @@ -157,6 +163,7 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base); /* Initialize the host structures for LPIs and the host ITSes. */ int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits); int gicv3_its_init(unsigned int host_lpi_bits); +void gicv3_lpi_update_host_flags(uint32_t flags); /* Store the physical address and ID for each redistributor as read from DT. */ void gicv3_set_redist_address(paddr_t address, unsigned int redist_id); @@ -199,10 +206,9 @@ struct pending_irq *gicv3_assign_guest_event(struct domain *d, void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id, uint32_t virt_lpi); -/* ITS quirks handling. */ -uint64_t gicv3_its_get_cacheability(void); -uint64_t gicv3_its_get_shareability(void); -unsigned int gicv3_its_get_memflags(void); +uint64_t gicv3_mem_get_cacheability(uint32_t flags); +uint64_t gicv3_mem_get_shareability(uint32_t flags); +unsigned int gicv3_mem_get_alloc_flags(uint32_t flags); #else -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 15:59:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 15:59:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429194.1652152 (Exim 4.92) (envelope-from ) id 1x92tk-00061Y-Q0; Tue, 22 Sep 2026 15:59:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429194.1652152; Tue, 22 Sep 2026 15:59:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92tk-00061N-MH; Tue, 22 Sep 2026 15:59:12 +0000 Received: by outflank-mailman (input) for mailman id 1429194; Tue, 22 Sep 2026 15:59:11 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92tj-0005sC-8K for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 15:59:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92ti-00ATp7-LM for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:59:10 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2a5ca-2eae-0a2a0a5409dd-0a2a4505d854-8 for ; Tue, 22 Sep 2026 17:59:10 +0200 Received: from [52.101.66.99] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2a5cc-4cb1-0a2a45050019-3465426338ac-4 for ; Tue, 22 Sep 2026 17:59:09 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by AMBPR03MB11360.eurprd03.prod.outlook.com (2603:10a6:20b:767::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 15:59:08 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 15:59:08 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QCO8eJmFBqrnuuFRNl4anOlhNMdX8qGzWIxTH3kGbz8RQ4vcdSZ3fupGJjIuT/X0O6yRa0P+j+iPHiRFox+MV66ogLIQomCccGvR56399gYRblSItTbtfZQgBCpRdmTLmGE59NsUKWQj8PpyWcmxZPUIdvTv8yoYnfRKGuOhbig1xZZ9CogSlVlbyaM3eSLp7URlhAWdMBreTh3q0Rk4j6X/JVcgGkGgzME0I2fvUy4l44Fh169T5YdobejkF3YtIyuKz/M6ieqPCpy28rEOIoDt7wxLYShhltHoc/ndKacejQVh+7/rY1xkk8w1yXv9tRlsY1xLbuHB+nLIINHwEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hoX9Udd1u8jB2Mb3putecPwyzMLTMMQOizPOOYuBRec=; b=qhWikTMtKGbSe/IrxZkaupQ44MXG4bY01vcMDHk3cz4lqpEGdBTu4VeHQPOjmmlWat5rHNQpt6pLpxw+KN5IiiXhvzNLUE17rh2vI4R+mRcOsQWpCkPQCrEwWOxNx2NaxQTUztgKh7Zun/LZll0q+9lq9aQhvLtE4HUCMrK2dDczvHAfYGwA2bFyM6x6WEGYaqL9Pz5I/XR2htvFyK4fbgk9CRmEMWKGfc5PD4vYSP68L8E43leHdGMI4bDXyYU8QW4zSAKSGSeyDpWNsdGDCqGcgco+BInvwpJo8X8MyhvsvBFj+UGFR+K+x0EH0uyAHeskWqK0dFD0zVBa1DjiIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hoX9Udd1u8jB2Mb3putecPwyzMLTMMQOizPOOYuBRec=; b=b5jTdGcDXxTnTApsJR8UHx5Fj2O1KK+4Yff9N4HAOE+jCEUURKtaZ21O1tuufvmyXDQBs5KSgK+iARboNrl9evloizYdbEfFT9/xtmSlpoxR27fhPN0XGKqNogCKPgNR5QPgljQ4onvjEWOlbl7HI5I6xNQRJOS8p4G8Nw69LFdz5Vi/A/ptjaO4LqlQROg+ol8LHgWocLD4x0iA20EG2N1szWoXKK2+zTGZh4gM5kc4U+2BBchlDS0rMruFhtUzcvXCH13IpvsyzUgcO6v2E2i7iMiFUIj78PVA/TWEitpNUTxQUrROlr5NLkB7QiSj7Oz+7p7qyiQv5u2agu/HmA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes Date: Tue, 22 Sep 2026 18:58:42 +0300 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0020.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::17) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AMBPR03MB11360:EE_ X-MS-Office365-Filtering-Correlation-Id: 34dd9ad9-5906-4d84-50f6-08df18c26ebc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|366016|1800799024|6133799003|18002099003|22082099003|11063799006|56012099006|10067099003; X-Microsoft-Antispam-Message-Info: mQqySFEa5RdKUH9+5jY4d+sZWDbw+XCG3B0a9lH/5W4GK+zHzytRMcneAEZIFOy1yqzi5utu69FpINVK8Ksqpn717WSTsVIG1goyTHgtEuBpUlugTSISsjRHiQrrvDpIbQWqBer7ZEWEIMmnyZdkIT//lVKQAd3V/zerEHpBFffffeL5XSpH3ClLx0hrOb9hvzdD2bWNySGTfKiQl7PNFX7ANmQ8+R2v90pw0D4C7Xbgz683n0J9yDMGJiwOv/jdlKtLfDzOZWkaJ3PBE0hxKMaajedCrhVNRsNg0aRwPc0IvuBWM/jW0lqhgD7YCSKrRV8to9kJuSAe+YKozWCqLCmvonXiswSoH9IlCq5xrIZO7JPan2qlBB6owTvseewfLrd2jWoQEe80tbJUQnSA4y+L9cv6+8thBgRRJ/LbhtOxgaMa+385F2uhd6h4e0ooll9fr501jemj8IIMCOk2Ea4jLYC6PjkF6kOfJ2m8JEHyCeUIroy+BjuYvAPYwD/YZ+Rzo2StGLiPDlHBjCbKdrQXvX4P3Lkg11PjHT6/E+qZzc5fgQJTaVoIvLzIRJnJXV+8VgJqo1eewG3AbJHnIhcZUkns2V6diIAAvBdJdyKR9iQyJ2EHikxQSVHBVbbY0wEHBqFN2S/5HBWnP2KO3CGSJh6jaWg2tsXNmwQUZ6s= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(366016)(1800799024)(6133799003)(18002099003)(22082099003)(11063799006)(56012099006)(10067099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uQLmTHSuz9MfkxBNaXP9NXODFAt4d0+1P0Een8P25LMf6akzwlTyOsmkS5AF?= =?us-ascii?Q?CXvVcroTVPuV/T0hqdd03MOooG1uD+eKoLxS/DCtxaVCZVWeYu/oHrmWjYtu?= =?us-ascii?Q?6r2v+59aa8H6ZXHFGZniiAn5CfVrmr0CdzD0JrqzNlU2T40VnqsN+hMuY1ZC?= =?us-ascii?Q?0ZHmMfC6DQvnc2aBDgVbSh7rcYhN0fd/jFK3jfxKxTZ6sVxDvpgJpQ+KXQ2k?= =?us-ascii?Q?T3CdQc5R6eZYMfu6ij9YAhsYfq7CnOuf+EuhfG/kwaG2GtcFjrMNdxLTi5dt?= =?us-ascii?Q?MUacCJ1ImEQ3LAszlyrY8W86mWoMQoUe9FahqDu1I8AK7hXDN8tZLaQ1RXnY?= =?us-ascii?Q?yMo8e4mNL8gOd9HaC2rWIhqnSO3vW6Ukmo/Go3UhcdycpzMn9G0R7zactrwF?= =?us-ascii?Q?jMvfIXfrxylQT0d5CS/DJYElIh8pCeuuN7TV9pbG2dpgba8dB2cPpPfjhFRK?= =?us-ascii?Q?cCerj+Vis2HPs5DAHFwZMYzHjGvu5qOsVo5UrGiRWOobI023XMByWPCQ4WAv?= =?us-ascii?Q?+sCvtinvy9e5j6cKtY/Hm1wGmX/NsBVP6SFouTTKhZ3MSFxqpAKxu96uzhT/?= =?us-ascii?Q?uOZf9nd7gr/Wk/j4V1yFtQvuN98u4xLO/3BYzHCjbHJQrkDzAYyv95526uwP?= =?us-ascii?Q?iL3bnwmDGLtkq7sUSQEkrkJNdXqDu+GnGJQm7r98vzywQ93Fo3q9zBFEjKZz?= =?us-ascii?Q?trRoztHC2+lZeoPeJ7XvON+0a8MFqOSbBkw61kO8AWxleg7htz5hSC15QGf0?= =?us-ascii?Q?qCfZbx6mHsCLX0IP1+iph9eYUPcUZZv21rEaLZlfzTFlC49JZwBYPOnnBx0d?= =?us-ascii?Q?J0Oi5nB8hVtE9l0ln8yU5J4jfiQBq0Ge/kZoQf66dSbI6apSyLurFbrsDbHS?= =?us-ascii?Q?r8guLukQIC1OsvJyMERC8+DOfFkACa0mmWqMOzCzd5eBY6/NYBtKQSnWJVcF?= =?us-ascii?Q?e1NpIJTk5r+GG4ohpPGdCCdfDMNIOuC4wbDNLAS3ZqbZIyHte1jH9YMwa7Mm?= =?us-ascii?Q?T/ne0xZMiuMQH2LnTLvodSF7nRm7HUox0JyNzOfXI6N01kHSkxfIn3GqSKo8?= =?us-ascii?Q?o/0yt2qWS3gh/3yLRZb56cs5TRlpxBefQ1kRBabe6bJu9mLjtb3DoHBdjh2H?= =?us-ascii?Q?0zM6TApcDAoN+jZxYq0HPG91IiFY4cqXruaUw0FGrRjP/VgPUdm2lV8+h8pG?= =?us-ascii?Q?d6ABiJBfnYyJ1x1fliSpCTIFAWa/ezoieig4CUQRqgHwAQjaBS4EySPTV6Kt?= =?us-ascii?Q?M7ObcKn8ayDkPyuo25RwoMS84xsyiBmEemCMOzNaUN9m0IPw9F5CcK3ytyVd?= =?us-ascii?Q?jqt3qmwNAj6rY9h5vNiKyIWwKjgzc/AMN6D0JNBFuxHGmqWUkxwkL31aK4K9?= =?us-ascii?Q?Pb4pen0w69z0tqtzY2xD1vFdnFFH7DRUWRKy640RNfDzLm0ki/M4wWpDdKSN?= =?us-ascii?Q?irNeV1Sp9FXA8sNMNtMRNHt5TzK+FMzubA8VJ+l5pzvCj1frhBKNHI1VCEU5?= =?us-ascii?Q?GCfiy7b6PxYCBequ5wznUQUxmc57/IiBbUd/dl/pDs+6kNyr2Zpk44nUhSQ8?= =?us-ascii?Q?Y2Srw4ia2cDClSjTocqPSF+QIAN10EAzfgFyB8LOLTC6aguwFw1StJh02CWJ?= =?us-ascii?Q?7IcsujBFNzva1A+2oOX2DOlkNvzD1YABc64fORZONhGuQcAURmjWtWN+UKZU?= =?us-ascii?Q?5h2lh/8+t+eptkX7jHMvWNe8wAoXZBqTXoGlUU5QVOEh3fmA/POEtlzHaazs?= =?us-ascii?Q?R5PS1o+6Ng=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34dd9ad9-5906-4d84-50f6-08df18c26ebc X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 15:59:07.1803 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: RL7AU8bXu9gBWWkR/da85bD5UJ1sg/bpQavsu9glaSy7eoGzmFCEUdHa4yyQe1fONTqJVdb9rzEaMUE3xaczXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMBPR03MB11360 X-purgate-ID: tlsNG-c201ff/1790092749-F44A42A1-4F56D02A/0/0 X-purgate-type: clean X-purgate-size: 4715 The DT dma-noncoherent property describes the bus coherency of the device represented by the node. On an ITS subnode, that is memory accessed by that ITS. Add GICV3_QUIRK_MEM_NC_NS to the corresponding host_its and use it when programming GITS_CBASER and GITS_BASER. On the top-level GIC node, the property describes the Redistributor side of the LPI path. Collect it in gicv3_lpi_init_host_lpis() and apply it only to the host LPI policy used when allocating the property and pending tables and when programming GICR_PROPBASER and GICR_PENDBASER. Mark the function init-only because firmware attributes are collected only during boot. Do not inherit the property between parent and child nodes: ITS-node non-coherency does not change the global host LPI policy, and GIC-node non-coherency does not change per-ITS quirk_flags. ACPI is unchanged; this patch only consumes the DT dma-noncoherent property. Signed-off-by: Mykola Kvach --- Changes in v3: - Keep the ITS init annotations with the earlier initialization patch. - Drop the redundant aggregate host-LPI-flags message. Changes in v2: - Split v1's dma-noncoherent handling into explicit ITS-node and GIC-node scopes. - Apply an ITS subnode property only to the matching host_its quirk_flags. - Collect the top-level GIC property from gic-v3-lpi.c before host LPI allocations use host_lpi_flags. --- xen/arch/arm/gic-v3-its.c | 17 +++++++++++++++++ xen/arch/arm/gic-v3-lpi.c | 20 +++++++++++++++++++- 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c index f52232ca40..6734f94e7c 100644 --- a/xen/arch/arm/gic-v3-its.c +++ b/xen/arch/arm/gic-v3-its.c @@ -139,6 +139,21 @@ static const struct its_quirk *__init gicv3_its_find_quirk( return NULL; } +static void __init gicv3_its_collect_fw_attrs(struct host_its *hw_its) +{ + /* + * An ITS subnode property describes memory transactions made by that ITS. + * Do not inherit it into the global host LPI/Redistributor policy. + */ + if ( !hw_its->dt_node || + !dt_property_read_bool(hw_its->dt_node, "dma-noncoherent") ) + return; + + hw_its->quirk_flags |= GICV3_QUIRK_MEM_NC_NS; + printk("GICv3: ITS @%#"PRIpaddr" marked dma-noncoherent\n", + hw_its->addr); +} + static void __init gicv3_its_collect_quirks(struct host_its *hw_its) { const struct its_quirk *quirk = gicv3_its_find_quirk(hw_its); @@ -149,6 +164,8 @@ static void __init gicv3_its_collect_quirks(struct host_its *hw_its) gicv3_lpi_update_host_flags(quirk->lpi_flags); printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc); } + + gicv3_its_collect_fw_attrs(hw_its); } uint64_t gicv3_mem_get_cacheability(uint32_t flags) diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c index accfd48a74..1cf49430ea 100644 --- a/xen/arch/arm/gic-v3-lpi.c +++ b/xen/arch/arm/gic-v3-lpi.c @@ -7,7 +7,9 @@ * Copyright (C) 2016,2017 - ARM Ltd */ +#include #include +#include #include #include #include @@ -102,6 +104,20 @@ void __init gicv3_lpi_update_host_flags(uint32_t flags) host_lpi_flags |= flags; } +static void __init gicv3_lpi_collect_fw_attrs(void) +{ + /* + * A top-level GIC node property describes the Redistributor side of the + * LPI path. Do not inherit it into per-ITS policy. + */ + if ( !acpi_disabled || + !dt_property_read_bool(dt_interrupt_controller, "dma-noncoherent") ) + return; + + gicv3_lpi_update_host_flags(GICV3_QUIRK_MEM_NC_NS); + printk("GICv3: Redistributors marked dma-noncoherent\n"); +} + static union host_lpi *gic_get_host_lpi(uint32_t plpi) { union host_lpi *block; @@ -443,7 +459,7 @@ integer_param("max_lpi_bits", max_lpi_bits); * to the page with the actual "union host_lpi" entries. Our LPI limit * avoids excessive memory usage. */ -int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) +int __init gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) { unsigned int nr_lpi_ptrs; int rc; @@ -451,6 +467,8 @@ int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) /* We rely on the data structure being atomically accessible. */ BUILD_BUG_ON(sizeof(union host_lpi) > sizeof(unsigned long)); + gicv3_lpi_collect_fw_attrs(); + /* * An implementation needs to support at least 14 bits of LPI IDs. * Tell the user about it, the actual number is reported below. -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 16:02:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 16:02:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429228.1652161 (Exim 4.92) (envelope-from ) id 1x92x7-0001GU-7I; Tue, 22 Sep 2026 16:02:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429228.1652161; Tue, 22 Sep 2026 16:02:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92x7-0001GN-3m; Tue, 22 Sep 2026 16:02:41 +0000 Received: by outflank-mailman (input) for mailman id 1429228; Tue, 22 Sep 2026 16:02:40 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x92x5-0001G7-VZ for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 16:02:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x92x5-00H4Tu-Ca for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 18:02:39 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2a69a-bab6-0a2a0a5309dd-0a2a4508d2ca-22 for ; Tue, 22 Sep 2026 18:02:39 +0200 Received: from [74.125.225.81] (helo=mail-wr2-f17.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2a69f-f659-0a2a45080019-4a7de15180e1-3 for ; Tue, 22 Sep 2026 18:02:39 +0200 Received: by mail-wr2-f17.google.com with SMTP id ffacd0b85a97d-484366874b0so65019f8f.2 for ; Tue, 22 Sep 2026 09:02: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 ffacd0b85a97d-4886277df46sm6161763f8f.17.2026.09.22.09.02.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 09:02: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790092959; x=1790697759; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=S5WBgZIOIhe27nk6Ohz6bOfdZS/bVYn3SfLmOOimSlo=; b=RreWde7uPLbreQGUi3/8A+sQttLVjxn1MOzyuwqSjJ+LZ27WlH3lia0buVTjQfa4px EwbCguxaC0B0jvbsiIoRe33qPYWaOncpLwzwFtDRk+YSds4eTZtMsfe952eZENUMq79K mrQG3EZh6sxokO014pYFfVeaZRzS1I2/n50jA5kznVeAvlQ4+dY0AZav1SelPh7yUUpj vbj+fMW0V7iLMVKnE55cTGr0651ASQMH3SATiYFXke+MKl/lS8GqjbHu3AFBqQO0Hpq+ QI6i3pTfcbuscfSZMRNbv9c2GKE9PQer2mQTrPxrs1MBacyH1qdwnzFVqtQ/2Rae5XXe FW8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790092959; x=1790697759; h=content-transfer-encoding:content-type: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:content-type; bh=S5WBgZIOIhe27nk6Ohz6bOfdZS/bVYn3SfLmOOimSlo=; b=ewgypBCD9Mtsy60lTX5ZPUQJ52Ihm8LF6BdXE5Te3hV7OHTXZofwARjJqjfQqWLVTZ muxZQXYoyEb13Ov+6+cimVW2rQMuElCHjQJjtlO9DUJE0RCZtd0oMny47aBAjZFvib+K 4/HEt0uOGN5xzAHrhA4QCAUCM+YwuhSgScyZTKQ2ioS0fiJ9l9TYHVOtUOzX3l8KLCp9 Xbxo4448eC7p/HxinuNXKNXLYG3AVZ+02nDNsqKrh33fSzpLdPvtI9gkDFySIrp6bdga Fz/K5gX9xtZNSbF/jBRKQ4Bjy1lMdeCtYckjJqzwj5Y18n5ie5f4CQvjK2SWEQCfu6Bp o+kA== X-Forwarded-Encrypted: i=1; AKwUvBzNK7vQVwGTiplZmM+TY9oGGkbUx3IC5/2vOdFhAuNV/t6jC/7tKb6vI6O6tB9biY/196oJ1s5vaRw=@lists.xenproject.org X-Gm-Message-State: AFuF++lloDMIE/mawOiCsf1YcT5lUdztdkKAIV7xJPZIlolxD6deRQOT d5XgVxD+fszjrlGg1G6stSasmEIyhSdtV0o0H/icFPwh+5vGEK145+U0DfC62EgwFA== X-Gm-Gg: AYBFou0nMcjRb9voE5K64kE/f7b+oS7C5ibeNoPTnJd65+zWusgGU4RlB+RyES5lC3U f+i6oS/zGRmmyiexqf2MICUvxg5OZlUud9LZEJpisxd0lG23BaJPYrJlDyZof3hfHKeNZ9s1509 LsTEZAdi2OU0tK2JIw7rxIRkeA6G8PCYKIhvKBCmacNt/6H5qJh4wjVjMs6KTuKthG1T9V4ubkt PZqdCufkQCL8NgrFXe1r46v3OnSG4z2Tl1Vacjj8PwhcAQDiV3lVUOHtcryrtJLpcYHZdXR+PNy 1sbFME2cAsiKmtqDPj1nigUsSDOsLfICiNnzJBdvb03v8nxxGAgXwoJdXX+o00RQiO5SAAEUI+K dq9/SdGYXGjf8tBQEyQ018YzQPo9Tg5ZO5reGUz5oSFu3Xz5f+O+k0jjp/SMEwGpmWAELiij04b blbPKl1PGtJa4M9jz2WogE5G8gaqswifwJOg8Tj+SKlhuT12LhZkcZCz4/aWXrk8LZpGq0aha42 3BM9xS6Y3Xgg6uGM0+j8K80/vQfcX7d1Vjv9vu8a3yJseW/YRArVQsHhe0QBQ== X-Received: by 2002:a05:6000:25f1:b0:487:27f6:a4e5 with SMTP id ffacd0b85a97d-4886709ea7dmr41521f8f.53.1790092958696; Tue, 22 Sep 2026 09:02:38 -0700 (PDT) Message-ID: <3f84e5f8-473d-4d4d-b4ae-b83dd0c0f997@suse.com> Date: Tue, 22 Sep 2026 18:02:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/14] x86: restrict PHYSDEVOP_* when PV=n To: Andrew Cooper Cc: Daniel Smith , "xen-devel@lists.xenproject.org" References: <664d2a63-2745-4c33-9748-283aefce2433@suse.com> <290d1ac5-a9b8-4576-9e9e-2b44d377a76a@citrix.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: <290d1ac5-a9b8-4576-9e9e-2b44d377a76a@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1790092959-D654487B-633593BA/0/0 X-purgate-type: clean X-purgate-size: 612 On 22.09.2026 17:21, Andrew Cooper wrote: > On 17/08/2026 9:52 am, Jan Beulich wrote: >> --- a/xen/arch/x86/physdev.c >> +++ b/xen/arch/x86/physdev.c >> @@ -233,6 +233,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H >> break; >> } >> >> +#ifdef CONFIG_PV > > I think this needs to have /* See hvm_physdev_op(). */ > > Most of these ops are not inherently PV; they're only PV because we've > not cared to expose them to HVM guests, and that's a different meaning > to what CONFIG_PV normally means in code. Hmm, yes, added locally. May I infer "A-b with this adjustment"? Jan From xen-devel-bounces@lists.xenproject.org Tue Sep 22 17:00:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 17:00:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429259.1652171 (Exim 4.92) (envelope-from ) id 1x93rI-0001wg-Cm; Tue, 22 Sep 2026 17:00:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429259.1652171; Tue, 22 Sep 2026 17:00:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x93rI-0001wY-7w; Tue, 22 Sep 2026 17:00:44 +0000 Received: by outflank-mailman (input) for mailman id 1429259; Tue, 22 Sep 2026 17:00:43 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x93rH-0001wN-17 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:00:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x93rF-005Abk-Rw for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:00:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b436-8faa-0a2a0a5109dd-0a2a450bd270-6 for ; Tue, 22 Sep 2026 19:00:41 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2b439-b7e8-0a2a450b0019-b9ff1c12aa23-3 for ; Tue, 22 Sep 2026 19:00:41 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0ca0fea6500072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 17:00:35 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 41B87829F2; Tue, 22 Sep 2026 19:00:33 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=IJPNXCUDrfDKlMgB/AMVKPZxO7W/NFwVwi45Sl/Gnp0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=m6J5RWEMm0XTH+JS8P8m92JX6px5HI/JLLeGLfpvmPOPz2v3TPhVhAUNllCUHXGQAanobZcs6 17Luf7u3dZ2z0FBUwz9z59i3NE9pUzjaEjmfT46V1jmQFmZ96bUpUOcadhJlq6RXCp9484V+yBy kwR6HcRwyFzN2V1gc7/xBlSk4Ib9mNIDTu0zPm5c19QExiWHSzNshTT1kX2z0vXMpyP8JNR/hDa CG5tZLOG57LoN4J/jm7vNhAjlRGd+AbawW/N/LGtSYWbEzxILptP+UtMjGBD+ug3o3YmElxcEzO Iw94RMqBlj4vUKxBemM/VokjjhjXzLKrcW8MDaPit0Sg== X-Zone-Loop: 3a345c1d85a50e16936e6a62e8c5239bd87b3fa8c707 x-campaign-type: default x-transaction-id: 7d2ea33e-c4a2-44bd-ad4e-d79f0b644c24 x-swg-uid: 01-7f2fd41b-88ed-417b-9668-d77d1932586a X-Mailer: Sweego Message-ID: <1790096435.8631fc262581453bbf619ec5b2062170.1a0ca0fea6500072c4@vates.tech> x-swg-bid: 1790096435.8631fc262581453bbf619ec5b2062170.1a0ca0fea6500072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> References: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> Date: Tue, 22 Sep 2026 19:00:25 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790096426; l=2569; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=ZFi8w6UqcqG8mh9D4ewNYr+ZjJ9zbC25lwsecYfIAJY=; b=6bVI7Om3f5WdZZ2iBb0dTpZzG6k1uZJ84HhvbHe3Tc2ggYfdXGXS50Eqse6pdOwFmQRM8PrvG lQhonuz2QNRBbjVlIXZQ+JDwrVR54l1Roc3b3bqoOxzm48uflZ/yavn X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790096433486 X-purgate-ID: tlsNG-42698a/1790096441-192CC9EA-F65EC26E/10/73395122804 X-purgate-type: spam X-purgate-size: 2569 > During migration of a virtual hart to a different guest interrupt file, > straggler MSIs from the APLIC could arrive at the old interrupt file > after the switch. > > genmsi is used despite not supporting guest interrupt files because the > AIA spec guarantees that all MSIs previously sent from the APLIC to the > same hart are visible at the hart's IMSIC before the extempore MSI from > genmsi becomes visible. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c > index 0af13f28e4..cb11d6aeaa 100644 > --- a/xen/arch/riscv/aplic.c > +++ b/xen/arch/riscv/aplic.c > @@ -27,7 +27,9 @@ > #include > #include > #include > +#include > #include > +#include > > static struct aplic_priv aplic = { > .lock = SPIN_LOCK_UNLOCKED, > @@ -205,6 +207,30 @@ void aplic_hw_write_reg(unsigned int offset, uint32_t value) > spin_unlock_irqrestore(&aplic.lock, flags); > } > > +/* > + * As needed, synchronize with all IOMMUs and APLICs to ensure that no > + * straggler MSIs will arrive at the old interrupt file after this step. > + */ > +void aplic_genmsi_barrier(void) > +{ > + const struct imsic_config *imsic = imsic_get_config(); > + unsigned int cpu = smp_processor_id(); > + unsigned long flags; > + uint32_t val; > + > + val = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | > + (imsic->sync_id & APLIC_TARGET_EIID); > + > + spin_lock_irqsave(&aplic.lock, flags); > + > + writel(val, &aplic.regs->genmsi); > + > + while ( readl(&aplic.regs->genmsi) & APLIC_GENMSI_BUSY ) > + cpu_relax(); > + > + spin_unlock_irqrestore(&aplic.lock, flags); > +} > + According to AIA spec §4.9.3 (Synchronizing interactions between a hart and the APLIC), the sequence needs 6 steps; this implements only steps 2-5: - Step 1: clear the pending bit for sync_id at the hart's IMSIC before writing genmsi. - Step 6: after releasing the lock, poll the pending bit for sync_id at the hart's IMSIC until it's set. Step 4 (Busy clear) only means the APLIC has accepted/sent the MSI, not that it has arrived at the hart (the spec notes an unspecified travel delay). Without step 6, aplic_genmsi_barrier() returns before the MSI (and thus prior MSIs) actually reach the hart, so it doesn't achieve the barrier it's meant to provide. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Sep 22 17:00:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 17:00:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429260.1652178 (Exim 4.92) (envelope-from ) id 1x93rN-0002Af-He; Tue, 22 Sep 2026 17:00:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429260.1652178; Tue, 22 Sep 2026 17:00:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x93rN-0002AY-Eo; Tue, 22 Sep 2026 17:00:49 +0000 Received: by outflank-mailman (input) for mailman id 1429260; Tue, 22 Sep 2026 17:00:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x93rM-0002AI-Rs for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:00:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x93rM-008cvY-8U for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:00:48 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b439-2eae-0a2a0a5409dd-0a2a4502c390-20 for ; Tue, 22 Sep 2026 19:00:48 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2b43f-6ca4-0a2a45020019-b9ff1c12b0f9-3 for ; Tue, 22 Sep 2026 19:00:48 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0ca0fea8600072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 17:00:35 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 154BD81C7E; Tue, 22 Sep 2026 19:00:32 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=1dlUnqEPqELr3/b37rHCQBFuq5HiJfx0Z/ILCX05KcM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=et/BuBt4hGGWcEmGKxyc9YhFqMLBJ5z+pDQ9rgHyA1dDlta7YJLZ0Mzt7iDPaoGud0efYb4HM pksHysMCDNKtVYvuoFABcLjp26qU35f2sOtWJQ8D3Vnde1AuHNx0E0vI0SCbMhiWVs5YJJDB9ZD kiJkJQvSfRRWoft87dO0EfjeZzf3OLZX0jCKcSP/HY+gqKfTWVsZ2kcIGC40b7AbGM+ot4ofInr 84aFSZn/VV9M/H2WZqVkuptbCPJhxIofgu9sMzbTM6wPl7A6ZpTwU3oEWqr7EiH0FNCDc6ZIPKJ eo/SmfZos/cnRp1P2js20awO35reSMs3YeFtlcL4yN/A== X-Zone-Loop: daff011fe32f1f132ca5de1354413e918ff439400371 x-campaign-type: default x-transaction-id: b4718b59-ecc9-4980-8db3-5c1260a4d8da x-swg-uid: 01-7fa33e84-c785-4feb-9883-e9902c5104ac X-Mailer: Sweego Message-ID: <1790096435.8631fc262581453bbf619ec5b2062170.1a0ca0fea8600072c4@vates.tech> x-swg-bid: 1790096435.8631fc262581453bbf619ec5b2062170.1a0ca0fea8600072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 27/39] xen/riscv: introduce arch_move_irqs() From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Tue, 22 Sep 2026 19:00:25 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790096426; l=708; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=erI0Y9hiRzVVveCjNXTGPiL04yC2AvNDjQOzR0wgwpQ=; b=kwwZZByE0FTbk0miBdVPts+XPnx1Iqfr6cu0QswsJWO+vyI7ytIpVWuDn2Aq9d7gguKzf+Ddj 5fAUb1waV3JC7QtIxTjV5qdwLx1tD+BagmuOec9QmX+R5anKBcQzUG5 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790096432317 X-purgate-ID: tlsNG-720697/1790096448-30DC12AC-0BF26DD2/10/73395122804 X-purgate-type: spam X-purgate-size: 708 On Thu, 27 Aug 2026 17:21:11 +0200, Oleksii Kurochko wrote: > When migrating a vCPU between pCPUs the hypervisor must also migrate > the associated virtual interrupt state. arch_move_irqs() is the > per-arch hook called by generic code to trigger that. > > Replace the static inline BUG_ON placeholder in asm/irq.h with a real > implementation in intc.c dispatching through a new move_irqs vintc_ops > callback. Wire it up in vAPLIC, which delegates to imsic_migrate_vcpu() > which itself still a stub to be implemented in follow-up patches. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Tue Sep 22 17:03:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 17:03:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429272.1652187 (Exim 4.92) (envelope-from ) id 1x93ts-00036E-Vd; Tue, 22 Sep 2026 17:03:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429272.1652187; Tue, 22 Sep 2026 17:03:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x93ts-000367-T7; Tue, 22 Sep 2026 17:03:24 +0000 Received: by outflank-mailman (input) for mailman id 1429272; Tue, 22 Sep 2026 17:03:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x93tr-00035y-RS for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:03:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x93tr-00AcQB-8H for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:03:23 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b4be-8faa-0a2a0a5109dd-0a2a450ceb4a-46 for ; Tue, 22 Sep 2026 19:03:23 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2b4da-f479-0a2a450c0019-b9ff1c128023-3 for ; Tue, 22 Sep 2026 19:03:22 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0ca1270b600072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 22 Sep 2026 17:03:21 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id C110081BC9; Tue, 22 Sep 2026 19:03:17 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=ONy15IQp8/c+sWVq7M1U+PHLMkvnpBm1Fx5erVNBUJw=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=pBFw+w6hXkIdbxii5REinbr8Qeq9pl0dCA7O13/n3XzmfnlXyMgwU3Pc+O92iw1sAA2Q6wGgl 2dxgHJfLsfuZQHwkZYZ9Tl+qJJO+xQ5Qsl881KSJwWc1y21Zzmb/3rhkFJI55fxOIP1qc8wz+H6 iDbFIvw06ELeejPYOv1LT1YXjHKaS+ndZCqZ2Fdi4d4VJkreIZOpjcFoYNcaMC/FQNhBtUauTuX YUpvaPgy3G2PwrnwpnRVLkKszsnTyVTQTTXJtjWE7okYqXTZinib8qX5BGzjSaitJXBDBfOSppk f8hFky4moUfvXXdnNWfNQKJou6MBOkuxKqmMMez3AB5g== X-Zone-Loop: 1da72f24e40c9350b51869622d599f8dca9459ab5fa9 x-campaign-type: default x-transaction-id: 2afd3361-c69d-4012-a82f-db9066d3ecfe x-swg-uid: 01-b93e5509-bec0-44e7-a8d3-9055e74a5c06 X-Mailer: Sweego Message-ID: <1790096601.8631fc262581453bbf619ec5b2062170.1a0ca1270b600072c4@vates.tech> x-swg-bid: 1790096601.8631fc262581453bbf619ec5b2062170.1a0ca1270b600072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration From: Baptiste Le Duc To: Oleksii Kurochko Cc: Jan Beulich , Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org In-Reply-To: <2e07e5e8-bd6c-4ec9-b656-6fa8c61bb456@gmail.com> References: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> <45f6e417-ea0e-470c-bfae-e163a65b48d0@suse.com> <2e07e5e8-bd6c-4ec9-b656-6fa8c61bb456@gmail.com> Date: Tue, 22 Sep 2026 19:03:12 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790096592; l=2172; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=YvSFGSEofh4TgOJCL12sD2xJouKXuEGsA7+UhywqWEM=; b=vIPVlrQ9e0EsxY515hCY/AH4pPndw0xpdRYKFmcaHnl2WHyxM0BGPixOC/5ejg6Js9CYleLgf DHtsoowu42WBtfWtlKRbIRhTNSgeT+XotBNPFsjo5gsyHyjV4TXJCh4 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790096597988 X-purgate-ID: tlsNG-d25034/1790096603-02CDBA5B-A35DF6A9/0/0 X-purgate-type: clean X-purgate-size: 2176 On 2026-09-18 13:53:12+02:00, Oleksii Kurochko wrote: > On 9/14/26 3:27 PM, Jan Beulich wrote: > > > On 27.08.2026 17:21, Oleksii Kurochko wrote: > > > > Hmm. As indicated, I'm learning RISC-V as I'm reviewing patches. This > > paragraph, if left as is, would make sure I simply can't ack the patch. > > I just don't understand what is being talked about. I can guess parts, > > but for example I don't know what "genmsi" is. > > I will reword then commit message in the following way: > > ``` > When a vCPU is moved to a different guest interrupt file, MSIs that the > APLIC has already sent towards the old file may still be in flight. They > must land before the old file's state is saved and the switch is done, > otherwise they would be lost. > > To wait for them, use the APLIC's genmsi register. Writing it makes the > APLIC itself send an MSI (an "extempore" MSI) with a given interrupt > identity to a given hart. genmsi can only target the hart's supervisor- Nit: supervisor = hypervisor in our pov > level interrupt file, not a guest one, but the AIA spec guarantees that > all MSIs previously sent by the same APLIC to the same hart become > visible at the hart's IMSIC before the extempore MSI does. So once the > extempore MSI has been delivered, no older MSI from this APLIC to the > hart can still be in flight, whichever interrupt file it targets. > > The last interrupt identity (nr_ids) is reserved for this purpose. > ``` > > > Along the lines of a question on an earlier patch: What if this ANDing > > actually chops off bits? > > I will do then the same as I did in aplic_set_irq_affinity() (i > mentioned that in the one of the replies connected to this function in > this patch series): > > /* > * sync_id is nr_ids, which imsic_parse_node() limits to IMSIC_MAX_ID, > * so it always fits into the EIID field. > */ > BUILD_BUG_ON(IMSIC_MAX_ID > MASK_EXTR(~0U, APLIC_TARGET_EIID)); > ASSERT(imsic->sync_id <= IMSIC_MAX_ID); > > val = MASK_INSR(aplic_hart_index(cpu), APLIC_TARGET_HART_IDX) | > imsic->sync_id; > > Thanks. > > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429300.1652228 (Exim 4.92) (envelope-from ) id 1x94mm-0004yp-AB; Tue, 22 Sep 2026 18:00:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429300.1652228; Tue, 22 Sep 2026 18:00:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94mm-0004xC-28; Tue, 22 Sep 2026 18:00:08 +0000 Received: by outflank-mailman (input) for mailman id 1429300; Tue, 22 Sep 2026 17:14:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x944H-0005Kg-LN for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:14:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x944H-00Gih6-1x for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:14:09 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b747-bab6-0a2a0a5309dd-0a2a4506eaf6-10 for ; Tue, 22 Sep 2026 19:14:09 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b760-195a-0a2a45060019-d98c6eac9766-1 for ; Tue, 22 Sep 2026 19:14:08 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0E2F91576; Tue, 22 Sep 2026 10:14:04 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CF53A3FA32; Tue, 22 Sep 2026 10:13:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097247; bh=ycUddICsfxEifMnQljPG5LJ+QAfshpGj42pAhJYJWAs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=SBP5DIfa3nHM7wg1pyznXr/QOoBKyjohtWTUL8njVjJ2HZJ7Dx+/2lyN5lNkmMRzt MkKJj6bY+fLt8c5gDKfHKPh91F5Et1R0ROJrwOWzqHfSea49QFldK5bBAeUeM9p2Ca sZJWLtBML/JGGl2eO59i8Nq/hvCyVDsIRYBYPmlc= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:33 +0100 Subject: [PATCH v3 5/9] mm: convert PTE table entry to pte MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-5-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-16d1c6/1790097249-F480577B-478CDECB/0/0 X-purgate-type: clean X-purgate-size: 897 The non-MMU stub receives hw_pte_t but returns a software PTE value. It has no attached PTE that requires ptep_get(), so convert only the stored entry through __pte_from_hw(). Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Explain why the NOMMU stub does not use ptep_get(). - Use software PTE value terminology. --- include/linux/hugetlb.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 0d2101facaa50..637fc863d3687 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -1278,7 +1278,8 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, #ifdef CONFIG_MMU return ptep_get(ptep); #else - return *ptep; + /* No attached PTE that requires ptep_get(). */ + return __pte_from_hw(*ptep); #endif } -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429306.1652250 (Exim 4.92) (envelope-from ) id 1x94mn-0005P0-Me; Tue, 22 Sep 2026 18:00:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429306.1652250; Tue, 22 Sep 2026 18:00:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94mn-0005KU-5n; Tue, 22 Sep 2026 18:00:09 +0000 Received: by outflank-mailman (input) for mailman id 1429306; Tue, 22 Sep 2026 17:14:51 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x944x-0005O3-G5 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:14:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x944w-003clj-T5 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:14:50 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b788-bab6-0a2a0a5309dd-0a2a4508d152-4 for ; Tue, 22 Sep 2026 19:14:50 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b789-f659-0a2a45080019-d98c6eac9526-1 for ; Tue, 22 Sep 2026 19:14:50 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 33B321576; Tue, 22 Sep 2026 10:14:45 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4E50C3F86C; Tue, 22 Sep 2026 10:14:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097288; bh=FzOwmvXA/ZsaFfwRIrSgTUueXbfZi9w1ND4q544oILg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Q1VpCxluEzmguxI26Ee7wNqjVLyFcXsyK9/dTWuDEaV5LI432tzfpNULGi1fic9rT Bmjsh3ZnFfh+9S7gpmlxZgPGzuuQpx+nqgYUgF5ZWR3Ua8oDKnB0+1kZHIWXY9gb9N 2rdmHfnaacSFRGJxxoea+piZgL6JIpAkwsMHQgwc= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:36 +0100 Subject: [PATCH v3 8/9] drm/i915: use hw_pte_t for PTE range callbacks MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-8-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-c1860d/1790097290-D6F5F87B-B16FE897/0/0 X-purgate-type: clean X-purgate-size: 2447 apply_to_page_range() now passes PTE table storage to its callback as hw_pte_t *. Update the i915 remap and selftest callbacks to match the new type. Continue to use ptep_get() for software PTE values and set_pte_at() for updates. The type remains an alias of pte_t on x86 until that architecture opts in. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Use software PTE value terminology. Changes since RFC v1: - Clarify the effect on architectures that have not opted in. --- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 4 ++-- drivers/gpu/drm/i915/i915_mm.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c index d01acfb7d93d0..056faf4a3618b 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c @@ -1690,7 +1690,7 @@ static int igt_mmap_gpu(void *arg) return 0; } -static int check_present_pte(pte_t *pte, unsigned long addr, void *data) +static int check_present_pte(hw_pte_t *pte, unsigned long addr, void *data) { pte_t ptent = ptep_get(pte); @@ -1703,7 +1703,7 @@ static int check_present_pte(pte_t *pte, unsigned long addr, void *data) return 0; } -static int check_absent_pte(pte_t *pte, unsigned long addr, void *data) +static int check_absent_pte(hw_pte_t *pte, unsigned long addr, void *data) { pte_t ptent = ptep_get(pte); diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c index fd89e7c7d8d6f..aab88e8edf946 100644 --- a/drivers/gpu/drm/i915/i915_mm.c +++ b/drivers/gpu/drm/i915/i915_mm.c @@ -48,7 +48,7 @@ static inline unsigned long sgt_pfn(const struct remap_pfn *r) return r->sgt.pfn + (r->sgt.curr >> PAGE_SHIFT); } -static int remap_sg(pte_t *pte, unsigned long addr, void *data) +static int remap_sg(hw_pte_t *pte, unsigned long addr, void *data) { struct remap_pfn *r = data; @@ -70,7 +70,7 @@ static int remap_sg(pte_t *pte, unsigned long addr, void *data) #define EXPECTED_FLAGS (VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP) #if IS_ENABLED(CONFIG_X86) -static int remap_pfn(pte_t *pte, unsigned long addr, void *data) +static int remap_pfn(hw_pte_t *pte, unsigned long addr, void *data) { struct remap_pfn *r = data; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429294.1652208 (Exim 4.92) (envelope-from ) id 1x94ml-0004bm-7Q; Tue, 22 Sep 2026 18:00:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429294.1652208; Tue, 22 Sep 2026 18:00:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94ml-0004Zp-2U; Tue, 22 Sep 2026 18:00:07 +0000 Received: by outflank-mailman (input) for mailman id 1429294; Tue, 22 Sep 2026 17:13:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x943t-0005Ht-Nk for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:13:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x943t-00B3e2-4Z for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:13:45 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b748-e002-0a2a0a5209dd-0a2a45019dac-2 for ; Tue, 22 Sep 2026 19:13:44 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b746-5984-0a2a45010019-d98c6eac9382-1 for ; Tue, 22 Sep 2026 19:13:43 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0295A1BF7; Tue, 22 Sep 2026 10:13:38 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 804793F86C; Tue, 22 Sep 2026 10:13:28 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097221; bh=hbwpI1dfxzJNivW5/jfGidrrhQka72LMuk6he+tRNFY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=rlnn6dN81q5UsLnf0ndk9eP+OGv+uyvqliAMX/KrwbrZBWlSh+5kBxFv4qrSN3CbE peraBVOlk2zYlQZssADeevlNFjj8cVmRfWLPOcsLCB1B32kuHpvd4k0G8nTXKVzyzy EONfL4uyPEHRLzBGtiBjkloydqkhhe5hD3CplMO0= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:31 +0100 Subject: [PATCH v3 3/9] mm: use hw_pte_t for generic PTE table storage MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-3-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-d62444/1790097224-BE8674F7-3731CF24/0/0 X-purgate-type: clean X-purgate-size: 124423 Generic page-table interfaces use pte_t * for both pointers to PTE table storage and pointers to software PTE values. Convert the generic declarations and their MM, fs, and kernel users together so parameters, return types, callbacks, and local pointers that designate table storage use hw_pte_t *. Include linux/pgtable_types.h from headers that expose the converted interfaces. It continues to provide pgprot_t to vmalloc.h through asm/page.h. Keep software PTE values as pte_t and retain pte_t * for value interfaces. No architecture selects ARCH_HAS_HW_PTE_T at this point, so hw_pte_t remains an alias of pte_t and this changes the interface vocabulary without changing representation or behavior. Most of this mechanical conversion was generated with the Coccinelle script included in the cover letter. The script deliberately ignores pte_t * pointers named ptentp because they designate software PTE values. The result was then audited, and sites the script could not convert were updated by hand. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Fold the header includes into their first user instead of keeping a stand-alone preparation patch. - Rebase onto mm-new and rerun the Coccinelle script. - Use software PTE value terminology. Changes since RFC v1: - Clarify that linux/pgtable_types.h provides both generic hw_pte_t definitions. - Clarify that the distinct generic definition is activated by an architecture opt-in. --- fs/hugetlbfs/inode.c | 3 ++- fs/proc/task_mmu.c | 33 ++++++++++++++-------------- include/asm-generic/hugetlb.h | 15 +++++++------ include/asm-generic/pgalloc.h | 6 ++--- include/asm-generic/tlb.h | 5 +++-- include/linux/hugetlb.h | 50 +++++++++++++++++++++++------------------- include/linux/mm.h | 26 +++++++++++----------- include/linux/page_table_check.h | 10 ++++++--- include/linux/pagewalk.h | 8 +++---- include/linux/pgtable.h | 79 +++++++++++++++++++++++++++++++++++------------------------------- include/linux/rmap.h | 2 +- include/linux/swapops.h | 6 +++-- include/linux/vmalloc.h | 4 ++-- include/trace/events/xen.h | 10 ++++----- kernel/bpf/arena.c | 9 ++++---- kernel/events/core.c | 3 ++- mm/damon/ops-common.c | 2 +- mm/damon/ops-common.h | 2 +- mm/damon/vaddr.c | 20 +++++++++-------- mm/debug_vm_pgtable.c | 2 +- mm/filemap.c | 4 ++-- mm/gup.c | 9 ++++---- mm/highmem.c | 15 +++++++------ mm/hmm.c | 6 ++--- mm/huge_memory.c | 4 ++-- mm/hugetlb.c | 60 ++++++++++++++++++++++++++------------------------ mm/hugetlb_vmemmap.c | 13 ++++++----- mm/internal.h | 16 +++++++------- mm/kasan/init.c | 12 +++++----- mm/kasan/shadow.c | 6 ++--- mm/khugepaged.c | 50 +++++++++++++++++++++++++----------------- mm/ksm.c | 7 +++--- mm/madvise.c | 14 +++++++----- mm/mapping_dirty_helpers.c | 4 ++-- mm/memory-failure.c | 6 ++--- mm/memory.c | 78 +++++++++++++++++++++++++++++++++-------------------------------- mm/mempolicy.c | 4 ++-- mm/migrate.c | 4 ++-- mm/migrate_device.c | 4 ++-- mm/mincore.c | 4 ++-- mm/mlock.c | 4 ++-- mm/mprotect.c | 19 ++++++++-------- mm/mremap.c | 4 ++-- mm/page_table_check.c | 4 ++-- mm/pagewalk.c | 9 ++++---- mm/percpu.c | 2 +- mm/pgtable-generic.c | 20 ++++++++--------- mm/ptdump.c | 2 +- mm/rmap.c | 6 ++--- mm/sparse-vmemmap.c | 22 +++++++++---------- mm/swap_state.c | 3 ++- mm/swapfile.c | 5 +++-- mm/userfaultfd.c | 32 +++++++++++++++------------ mm/util.c | 2 +- mm/vmalloc.c | 11 +++++----- mm/vmscan.c | 6 ++--- 56 files changed, 410 insertions(+), 356 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 7611a8470ea26..ddaab714c3e02 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -328,7 +328,8 @@ static void hugetlb_delete_from_page_cache(struct folio *folio) static bool hugetlb_vma_maps_pfn(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn) { - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; ptep = hugetlb_walk(vma, addr, huge_page_size(hstate_vma(vma))); if (!ptep) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index e671b4fd8dedd..4211c33b06491 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -982,7 +982,7 @@ static void smaps_pte_hole_lookup(unsigned long addr, struct mm_walk *walk) #endif } -static void smaps_pte_entry(pte_t *pte, unsigned long addr, +static void smaps_pte_entry(hw_pte_t *pte, unsigned long addr, struct mm_walk *walk) { struct mem_size_stats *mss = walk->private; @@ -1076,7 +1076,7 @@ static int smaps_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, struct mm_walk *walk) { struct vm_area_struct *vma = walk->vma; - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; ptl = pmd_trans_huge_lock(pmd, vma); @@ -1199,7 +1199,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) } #ifdef CONFIG_HUGETLB_PAGE -static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask, +static int smaps_hugetlb_range(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { @@ -1622,7 +1622,7 @@ static inline bool pte_is_pinned(struct vm_area_struct *vma, unsigned long addr, } static inline void clear_soft_dirty(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte) + unsigned long addr, hw_pte_t *pte) { if (!pgtable_supports_soft_dirty()) return; @@ -1690,7 +1690,8 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr, { struct clear_refs_private *cp = walk->private; struct vm_area_struct *vma = walk->vma; - pte_t *pte, ptent; + hw_pte_t *pte; + pte_t ptent; spinlock_t *ptl; struct folio *folio; @@ -2090,7 +2091,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long addr, unsigned long end, struct vm_area_struct *vma = walk->vma; struct pagemapread *pm = walk->private; spinlock_t *ptl; - pte_t *pte, *orig_pte; + hw_pte_t *pte, *orig_pte; int err = 0; #ifdef CONFIG_TRANSPARENT_HUGEPAGE @@ -2128,7 +2129,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long addr, unsigned long end, #ifdef CONFIG_HUGETLB_PAGE /* This function walks within one hugetlb entry in the single call */ -static int pagemap_hugetlb_range(pte_t *ptep, unsigned long hmask, +static int pagemap_hugetlb_range(hw_pte_t *ptep, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { @@ -2419,7 +2420,7 @@ static unsigned long pagemap_page_category(struct pagemap_scan_private *p, } static void make_uffd_wp_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte, pte_t ptent) + unsigned long addr, hw_pte_t *pte, pte_t ptent) { if (pte_present(ptent)) { pte_t old_pte; @@ -2552,7 +2553,7 @@ static unsigned long pagemap_hugetlb_category(struct vm_area_struct *vma, } static void make_uffd_wp_huge_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, + unsigned long addr, hw_pte_t *ptep, pte_t ptent) { const unsigned long psize = huge_page_size(hstate_vma(vma)); @@ -2786,7 +2787,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start, struct pagemap_scan_private *p = walk->private; struct vm_area_struct *vma = walk->vma; unsigned long addr, flush_end = 0; - pte_t *pte, *start_pte; + hw_pte_t *pte, *start_pte; spinlock_t *ptl; int ret; @@ -2880,7 +2881,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start, } #ifdef CONFIG_HUGETLB_PAGE -static int pagemap_scan_hugetlb_entry(pte_t *ptep, unsigned long hmask, +static int pagemap_scan_hugetlb_entry(hw_pte_t *ptep, unsigned long hmask, unsigned long start, unsigned long end, struct mm_walk *walk) { @@ -2961,7 +2962,7 @@ static int pagemap_scan_hugetlb_hole_wp(struct vm_area_struct *vma, unsigned long psize = huge_page_size(h); struct mm_struct *mm = vma->vm_mm; spinlock_t *ptl; - pte_t *ptep; + hw_pte_t *ptep; pte_t pte; for (addr = ALIGN_DOWN(addr, psize); addr < end; addr += psize) { @@ -3345,8 +3346,8 @@ static int gather_pte_stats(pmd_t *pmd, unsigned long addr, struct numa_maps *md = walk->private; struct vm_area_struct *vma = walk->vma; spinlock_t *ptl; - pte_t *orig_pte; - pte_t *pte; + hw_pte_t *orig_pte; + hw_pte_t *pte; #ifdef CONFIG_TRANSPARENT_HUGEPAGE ptl = pmd_trans_huge_lock(pmd, vma); @@ -3379,7 +3380,7 @@ static int gather_pte_stats(pmd_t *pmd, unsigned long addr, return 0; } #ifdef CONFIG_HUGETLB_PAGE -static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask, +static int gather_hugetlb_stats(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { pte_t huge_pte; @@ -3402,7 +3403,7 @@ static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask, } #else -static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask, +static int gather_hugetlb_stats(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { return 0; diff --git a/include/asm-generic/hugetlb.h b/include/asm-generic/hugetlb.h index 635c41cc34797..3bfad4a99b64d 100644 --- a/include/asm-generic/hugetlb.h +++ b/include/asm-generic/hugetlb.h @@ -60,7 +60,7 @@ static inline int huge_pte_uffd(pte_t pte) #ifndef __HAVE_ARCH_HUGE_PTE_CLEAR static inline void huge_pte_clear(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned long sz) + hw_pte_t *ptep, unsigned long sz) { pte_clear(mm, addr, ptep); } @@ -68,7 +68,7 @@ static inline void huge_pte_clear(struct mm_struct *mm, unsigned long addr, #ifndef __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned long sz) + hw_pte_t *ptep, pte_t pte, unsigned long sz) { set_pte_at(mm, addr, ptep, pte); } @@ -76,7 +76,7 @@ static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, #ifndef __HAVE_ARCH_HUGE_PTEP_GET_AND_CLEAR static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, unsigned long sz) + unsigned long addr, hw_pte_t *ptep, unsigned long sz) { return ptep_get_and_clear(mm, addr, ptep); } @@ -84,7 +84,7 @@ static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm, #ifndef __HAVE_ARCH_HUGE_PTEP_CLEAR_FLUSH static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { return ptep_clear_flush(vma, addr, ptep); } @@ -99,7 +99,7 @@ static inline int huge_pte_none(pte_t pte) #ifndef __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT static inline void huge_ptep_set_wrprotect(struct mm_struct *mm, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { ptep_set_wrprotect(mm, addr, ptep); } @@ -107,7 +107,7 @@ static inline void huge_ptep_set_wrprotect(struct mm_struct *mm, #ifndef __HAVE_ARCH_HUGE_PTEP_SET_ACCESS_FLAGS static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, + unsigned long addr, hw_pte_t *ptep, pte_t pte, int dirty) { return ptep_set_access_flags(vma, addr, ptep, pte, dirty); @@ -115,7 +115,8 @@ static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma, #endif #ifndef __HAVE_ARCH_HUGE_PTEP_GET -static inline pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep) +static inline pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, + hw_pte_t *ptep) { return ptep_get(ptep); } diff --git a/include/asm-generic/pgalloc.h b/include/asm-generic/pgalloc.h index 051aa1331051c..b35e5a2158ada 100644 --- a/include/asm-generic/pgalloc.h +++ b/include/asm-generic/pgalloc.h @@ -16,7 +16,7 @@ * * Return: pointer to the allocated memory or %NULL on error */ -static inline pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm) +static inline hw_pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm) { struct ptdesc *ptdesc = pagetable_alloc_noprof(GFP_PGTABLE_KERNEL, 0); @@ -40,7 +40,7 @@ static inline pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm) * * Return: pointer to the allocated memory or %NULL on error */ -static inline pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm) +static inline hw_pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm) { return __pte_alloc_one_kernel_noprof(mm); } @@ -52,7 +52,7 @@ static inline pte_t *pte_alloc_one_kernel_noprof(struct mm_struct *mm) * @mm: the mm_struct of the current context * @pte: pointer to the memory containing the page table */ -static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte) +static inline void pte_free_kernel(struct mm_struct *mm, hw_pte_t *pte) { pagetable_dtor_free(virt_to_ptdesc(pte)); } diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h index bdcc2778ac64f..2c3517800a9a8 100644 --- a/include/asm-generic/tlb.h +++ b/include/asm-generic/tlb.h @@ -644,7 +644,8 @@ static inline void tlb_flush_p4d_range(struct mmu_gather *tlb, } #ifndef __tlb_remove_tlb_entry -static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep, unsigned long address) +static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, + hw_pte_t *ptep, unsigned long address) { } #endif @@ -670,7 +671,7 @@ static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep, u * consecutive ptes instead of only a single one. */ static inline void tlb_remove_tlb_entries(struct mmu_gather *tlb, - pte_t *ptep, unsigned int nr, unsigned long address) + hw_pte_t *ptep, unsigned int nr, unsigned long address) { tlb_flush_pte_range(tlb, address, PAGE_SIZE * nr); for (;;) { diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 900c95e346b2e..0d2101facaa50 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -141,7 +141,7 @@ unsigned long hugetlb_total_pages(void); vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long address, unsigned int flags); #ifdef CONFIG_USERFAULTFD -int hugetlb_mfill_atomic_pte(pte_t *dst_pte, +int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte, struct vm_area_struct *dst_vma, unsigned long dst_addr, unsigned long src_addr, @@ -161,7 +161,7 @@ void hugetlb_fix_reserve_counts(struct inode *inode); extern struct mutex *hugetlb_fault_mutex_table; u32 hugetlb_fault_mutex_hash(struct address_space *mapping, pgoff_t idx); -pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, pud_t *pud); bool hugetlbfs_pagecache_present(struct hstate *h, struct vm_area_struct *vma, @@ -185,22 +185,22 @@ void hugetlb_bootmem_set_nodes(void); * which may go down to the lowest PTE level in their huge_pte_offset() and * huge_pte_alloc(): to avoid reliance on pte_offset_map() without pte_unmap(). */ -static inline pte_t *pte_offset_huge(pmd_t *pmd, unsigned long address) +static inline hw_pte_t *pte_offset_huge(pmd_t *pmd, unsigned long address) { return pte_offset_kernel(pmd, address); } -static inline pte_t *pte_alloc_huge(struct mm_struct *mm, pmd_t *pmd, +static inline hw_pte_t *pte_alloc_huge(struct mm_struct *mm, pmd_t *pmd, unsigned long address) { return pte_alloc(mm, pmd) ? NULL : pte_offset_huge(pmd, address); } #endif -pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, unsigned long sz); /* * huge_pte_offset(): Walk the hugetlb pgtable until the last level PTE. - * Returns the pte_t* if found, or NULL if the address is not mapped. + * Returns the hw_pte_t* if found, or NULL if the address is not mapped. * * IMPORTANT: we should normally not directly call this function, instead * this is only a common interface to implement arch-specific @@ -235,11 +235,11 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, * a concurrent pmd unshare, but it makes sure the pgtable page is safe to * access. */ -pte_t *huge_pte_offset(struct mm_struct *mm, +hw_pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz); unsigned long hugetlb_mask_last_page(struct hstate *h); int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep); + unsigned long addr, hw_pte_t *ptep); void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma); void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, unsigned long *start, unsigned long *end); @@ -301,7 +301,8 @@ static inline struct address_space *hugetlb_folio_mapping_lock_write( } static inline int huge_pmd_unshare(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep) + struct vm_area_struct *vma, unsigned long addr, + hw_pte_t *ptep) { return 0; } @@ -393,7 +394,7 @@ static inline int is_hugepage_only_range(struct mm_struct *mm, } #ifdef CONFIG_USERFAULTFD -static inline int hugetlb_mfill_atomic_pte(pte_t *dst_pte, +static inline int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte, struct vm_area_struct *dst_vma, unsigned long dst_addr, unsigned long src_addr, @@ -405,7 +406,7 @@ static inline int hugetlb_mfill_atomic_pte(pte_t *dst_pte, } #endif /* CONFIG_USERFAULTFD */ -static inline pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, +static inline hw_pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz) { return NULL; @@ -984,7 +985,8 @@ static inline bool htlb_allow_alloc_fallback(enum migrate_reason reason) } static inline spinlock_t *huge_pte_lockptr(struct hstate *h, - struct mm_struct *mm, pte_t *pte) + struct mm_struct *mm, + hw_pte_t *pte) { const unsigned long size = huge_page_size(h); @@ -1048,7 +1050,8 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm) #ifndef huge_ptep_modify_prot_start #define huge_ptep_modify_prot_start huge_ptep_modify_prot_start static inline pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, + hw_pte_t *ptep) { unsigned long psize = huge_page_size(hstate_vma(vma)); @@ -1059,7 +1062,8 @@ static inline pte_t huge_ptep_modify_prot_start(struct vm_area_struct *vma, #ifndef huge_ptep_modify_prot_commit #define huge_ptep_modify_prot_commit huge_ptep_modify_prot_commit static inline void huge_ptep_modify_prot_commit(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, + unsigned long addr, + hw_pte_t *ptep, pte_t old_pte, pte_t pte) { unsigned long psize = huge_page_size(hstate_vma(vma)); @@ -1247,7 +1251,8 @@ static inline bool htlb_allow_alloc_fallback(enum migrate_reason reason) } static inline spinlock_t *huge_pte_lockptr(struct hstate *h, - struct mm_struct *mm, pte_t *pte) + struct mm_struct *mm, + hw_pte_t *pte) { return &mm->page_table_lock; } @@ -1264,11 +1269,11 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm) { } -pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, pte_t *ptep); +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr, hw_pte_t *ptep); unsigned long huge_pte_dirty(pte_t pte); static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { #ifdef CONFIG_MMU return ptep_get(ptep); @@ -1278,7 +1283,8 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, } static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned long sz) + hw_pte_t *ptep, pte_t pte, + unsigned long sz) { } @@ -1306,7 +1312,7 @@ static inline void hugetlb_bootmem_struct_page_init(void) #endif /* CONFIG_HUGETLB_PAGE */ static inline spinlock_t *huge_pte_lock(struct hstate *h, - struct mm_struct *mm, pte_t *pte) + struct mm_struct *mm, hw_pte_t *pte) { spinlock_t *ptl; @@ -1324,12 +1330,12 @@ static inline __init void hugetlb_cma_reserve(void) #endif #ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING -static inline bool hugetlb_pmd_shared(pte_t *pte) +static inline bool hugetlb_pmd_shared(hw_pte_t *pte) { return ptdesc_pmd_is_shared(virt_to_ptdesc(pte)); } #else -static inline bool hugetlb_pmd_shared(pte_t *pte) +static inline bool hugetlb_pmd_shared(hw_pte_t *pte) { return false; } @@ -1356,7 +1362,7 @@ bool __vma_private_lock(struct vm_area_struct *vma); * Safe version of huge_pte_offset() to check the locks. See comments * above huge_pte_offset(). */ -static inline pte_t * +static inline hw_pte_t * hugetlb_walk(struct vm_area_struct *vma, unsigned long addr, unsigned long sz) { #if defined(CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING) && defined(CONFIG_LOCKDEP) diff --git a/include/linux/mm.h b/include/linux/mm.h index 1b28e6fc8d5dd..7d7344b9dbe19 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -779,7 +779,7 @@ struct vm_fault { * VM_FAULT_ERROR). */ /* These three entries are valid only while holding ptl lock */ - pte_t *pte; /* Pointer to pte entry matching + hw_pte_t *pte; /* Pointer to pte entry matching * the 'address'. NULL if the page * table hasn't been allocated. */ @@ -3246,7 +3246,7 @@ struct follow_pfnmap_args { * The caller shouldn't touch any of these. */ spinlock_t *lock; - pte_t *ptep; + hw_pte_t *ptep; /** * Outputs: * @@ -3583,7 +3583,7 @@ static inline pud_t pud_mkspecial(pud_t pud) } #endif /* CONFIG_ARCH_SUPPORTS_PUD_PFNMAP */ -extern pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr, +extern hw_pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr, spinlock_t **ptl); #ifdef __PAGETABLE_P4D_FOLDED @@ -3861,7 +3861,7 @@ static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pmd_t *pmd) return ptlock_ptr(page_ptdesc(pmd_page(*pmd))); } -static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte) +static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, hw_pte_t *pte) { BUILD_BUG_ON(IS_ENABLED(CONFIG_HIGHPTE)); BUILD_BUG_ON(MAX_PTRS_PER_PTE * sizeof(pte_t) > PAGE_SIZE); @@ -3892,7 +3892,7 @@ static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pmd_t *pmd) { return &mm->page_table_lock; } -static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte) +static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, hw_pte_t *pte) { return &mm->page_table_lock; } @@ -3933,19 +3933,19 @@ static inline bool pagetable_pte_ctor(struct mm_struct *mm, return true; } -pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp); +hw_pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp); -static inline pte_t *pte_offset_map(pmd_t *pmd, unsigned long addr) +static inline hw_pte_t *pte_offset_map(pmd_t *pmd, unsigned long addr) { return __pte_offset_map(pmd, addr, NULL); } -pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, spinlock_t **ptlp); -pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, spinlock_t **ptlp); -pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp, spinlock_t **ptlp); @@ -4895,7 +4895,7 @@ static inline bool gup_can_follow_protnone(const struct vm_area_struct *vma, return !vma_is_accessible(vma); } -typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr, void *data); +typedef int (*pte_fn_t)(hw_pte_t *pte, unsigned long addr, void *data); extern int apply_to_page_range(struct mm_struct *mm, unsigned long address, unsigned long size, pte_fn_t fn, void *data); extern int apply_to_existing_page_range(struct mm_struct *mm, @@ -5144,7 +5144,7 @@ void *vmemmap_alloc_block(unsigned long size, int node); struct vmem_altmap; void *vmemmap_alloc_block_buf(unsigned long size, int node, struct vmem_altmap *altmap); -void vmemmap_verify(pte_t *, int, unsigned long, unsigned long); +void vmemmap_verify(hw_pte_t *, int, unsigned long, unsigned long); void vmemmap_set_pmd(pmd_t *pmd, void *p, int node, unsigned long addr, unsigned long next); int vmemmap_check_pmd(pmd_t *pmd, int node, @@ -5509,7 +5509,7 @@ static inline bool snapshot_page_is_faithful(const struct page_snapshot *ps) void snapshot_page(struct page_snapshot *ps, const struct page *page); -void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte, +void map_anon_folio_pte_nopf(struct folio *folio, hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr, bool uffd_wp); diff --git a/include/linux/page_table_check.h b/include/linux/page_table_check.h index 12268a32e8be1..933c1028c2232 100644 --- a/include/linux/page_table_check.h +++ b/include/linux/page_table_check.h @@ -7,6 +7,8 @@ #ifndef __LINUX_PAGE_TABLE_CHECK_H #define __LINUX_PAGE_TABLE_CHECK_H +#include + #ifdef CONFIG_PAGE_TABLE_CHECK #include @@ -21,7 +23,7 @@ void __page_table_check_pmd_clear(struct mm_struct *mm, unsigned long addr, void __page_table_check_pud_clear(struct mm_struct *mm, unsigned long addr, pud_t pud); void __page_table_check_ptes_set(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned int nr); + hw_pte_t *ptep, pte_t pte, unsigned int nr); void __page_table_check_pmds_set(struct mm_struct *mm, unsigned long addr, pmd_t *pmdp, pmd_t pmd, unsigned int nr); void __page_table_check_puds_set(struct mm_struct *mm, unsigned long addr, @@ -74,7 +76,8 @@ static inline void page_table_check_pud_clear(struct mm_struct *mm, } static inline void page_table_check_ptes_set(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, + unsigned long addr, + hw_pte_t *ptep, pte_t pte, unsigned int nr) { if (static_branch_likely(&page_table_check_disabled)) @@ -137,7 +140,8 @@ static inline void page_table_check_pud_clear(struct mm_struct *mm, } static inline void page_table_check_ptes_set(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, + unsigned long addr, + hw_pte_t *ptep, pte_t pte, unsigned int nr) { } diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h index c34d826c5e4a2..7ab2eb39e02c0 100644 --- a/include/linux/pagewalk.h +++ b/include/linux/pagewalk.h @@ -38,7 +38,7 @@ enum page_walk_lock { * not trigger for any populated ranges. * @hugetlb_entry: if set, called for each hugetlb entry. This hook * function is called with the vma lock held, in order to - * protect against a concurrent freeing of the pte_t* or + * protect against a concurrent freeing of the hw_pte_t* or * the ptl. In some cases, the hook function needs to drop * and retake the vma lock in order to avoid deadlocks * while calling other functions. In such cases the hook @@ -76,11 +76,11 @@ struct mm_walk_ops { unsigned long next, struct mm_walk *walk); int (*pmd_entry)(pmd_t *pmd, unsigned long addr, unsigned long next, struct mm_walk *walk); - int (*pte_entry)(pte_t *pte, unsigned long addr, + int (*pte_entry)(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk); int (*pte_hole)(unsigned long addr, unsigned long next, int depth, struct mm_walk *walk); - int (*hugetlb_entry)(pte_t *pte, unsigned long hmask, + int (*hugetlb_entry)(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long next, struct mm_walk *walk); int (*test_walk)(unsigned long addr, unsigned long next, @@ -173,7 +173,7 @@ struct folio_walk { struct page *page; enum folio_walk_level level; union { - pte_t *ptep; + hw_pte_t *ptep; pud_t *pudp; pmd_t *pmdp; }; diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index e3c8ab96941c5..19098e302b75a 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -4,6 +4,7 @@ #include #include +#include #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT) #define PUD_ORDER (PUD_SHIFT - PAGE_SHIFT) @@ -93,26 +94,26 @@ static inline void pud_init(void *addr) #endif #ifndef pte_offset_kernel -static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address) +static inline hw_pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address) { - return (pte_t *)pmd_page_vaddr(*pmd) + pte_index(address); + return (hw_pte_t *)pmd_page_vaddr(*pmd) + pte_index(address); } #define pte_offset_kernel pte_offset_kernel #endif #ifdef CONFIG_HIGHPTE #define __pte_map(pmd, address) \ - ((pte_t *)kmap_local_page(pmd_page(*(pmd))) + pte_index((address))) + ((hw_pte_t *)kmap_local_page(pmd_page(*(pmd))) + pte_index((address))) #define pte_unmap(pte) do { \ kunmap_local((pte)); \ rcu_read_unlock(); \ } while (0) #else -static inline pte_t *__pte_map(pmd_t *pmd, unsigned long address) +static inline hw_pte_t *__pte_map(pmd_t *pmd, unsigned long address) { return pte_offset_kernel(pmd, address); } -static inline void pte_unmap(pte_t *pte) +static inline void pte_unmap(hw_pte_t *pte) { rcu_read_unlock(); } @@ -172,7 +173,7 @@ static inline pmd_t *pmd_off_k(unsigned long va) return pmd_offset(pud_offset(p4d_offset(pgd_offset_k(va), va), va), va); } -static inline pte_t *virt_to_kpte(unsigned long vaddr) +static inline hw_pte_t *virt_to_kpte(unsigned long vaddr) { pmd_t *pmd = pmd_off_k(vaddr); @@ -407,7 +408,7 @@ static inline void lazy_mmu_mode_resume(void) {} * * May be overridden by the architecture, else pte_batch_hint is always 1. */ -static inline unsigned int pte_batch_hint(pte_t *ptep, pte_t pte) +static inline unsigned int pte_batch_hint(hw_pte_t *ptep, pte_t pte) { return 1; } @@ -442,7 +443,7 @@ static inline pte_t pte_advance_pfn(pte_t pte, unsigned long nr) * to the same folio. The PTEs are all in the same PMD. */ static inline void set_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned int nr) + hw_pte_t *ptep, pte_t pte, unsigned int nr) { page_table_check_ptes_set(mm, addr, ptep, pte, nr); @@ -459,7 +460,7 @@ static inline void set_ptes(struct mm_struct *mm, unsigned long addr, #ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS extern int ptep_set_access_flags(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep, + unsigned long address, hw_pte_t *ptep, pte_t entry, int dirty); #endif @@ -490,7 +491,7 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma, #endif #ifndef ptep_get -static inline pte_t ptep_get(pte_t *ptep) +static inline pte_t ptep_get(hw_pte_t *ptep) { return READ_ONCE(*ptep); } @@ -526,7 +527,7 @@ static inline pgd_t pgdp_get(pgd_t *pgdp) #ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG static inline bool ptep_test_and_clear_young(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { pte_t pte = ptep_get(ptep); bool young = true; @@ -565,7 +566,7 @@ static inline bool pmdp_test_and_clear_young(struct vm_area_struct *vma, #ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH bool ptep_clear_flush_young(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep); + unsigned long address, hw_pte_t *ptep); #endif #ifndef __HAVE_ARCH_PMDP_CLEAR_YOUNG_FLUSH @@ -644,7 +645,7 @@ static inline void arch_check_zapped_pud(struct vm_area_struct *vma, pud_t pud) #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long address, - pte_t *ptep) + hw_pte_t *ptep) { pte_t pte = ptep_get(ptep); pte_clear(mm, address, ptep); @@ -673,7 +674,7 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline void clear_young_dirty_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, + unsigned long addr, hw_pte_t *ptep, unsigned int nr, cydp_t flags) { pte_t pte; @@ -698,7 +699,7 @@ static inline void clear_young_dirty_ptes(struct vm_area_struct *vma, #endif static inline void ptep_clear(struct mm_struct *mm, unsigned long addr, - pte_t *ptep) + hw_pte_t *ptep) { pte_t pte = ptep_get(ptep); @@ -739,7 +740,7 @@ static inline void ptep_clear(struct mm_struct *mm, unsigned long addr, * present bit set *unless* it is 'l'. Because get_user_pages_fast() only * operates on present ptes we're safe. */ -static inline pte_t ptep_get_lockless(pte_t *ptep) +static inline pte_t ptep_get_lockless(hw_pte_t *ptep) { pte_t pte; @@ -777,7 +778,7 @@ static inline pmd_t pmdp_get_lockless(pmd_t *pmdp) * We require that the PTE can be read atomically. */ #ifndef ptep_get_lockless -static inline pte_t ptep_get_lockless(pte_t *ptep) +static inline pte_t ptep_get_lockless(hw_pte_t *ptep) { return ptep_get(ptep); } @@ -844,7 +845,8 @@ static inline pud_t pudp_huge_get_and_clear_full(struct vm_area_struct *vma, #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, - unsigned long address, pte_t *ptep, + unsigned long address, + hw_pte_t *ptep, int full) { return ptep_get_and_clear(mm, address, ptep); @@ -872,7 +874,7 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, unsigned int nr, int full) + unsigned long addr, hw_pte_t *ptep, unsigned int nr, int full) { pte_t pte, tmp_pte; @@ -908,7 +910,7 @@ static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline pte_t get_and_clear_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned int nr) + hw_pte_t *ptep, unsigned int nr) { return get_and_clear_full_ptes(mm, addr, ptep, nr, 0); } @@ -933,7 +935,7 @@ static inline pte_t get_and_clear_ptes(struct mm_struct *mm, unsigned long addr, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline void clear_full_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned int nr, int full) + hw_pte_t *ptep, unsigned int nr, int full) { for (;;) { ptep_get_and_clear_full(mm, addr, ptep, full); @@ -962,7 +964,7 @@ static inline void clear_full_ptes(struct mm_struct *mm, unsigned long addr, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline void clear_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned int nr) + hw_pte_t *ptep, unsigned int nr) { clear_full_ptes(mm, addr, ptep, nr, 0); } @@ -977,13 +979,14 @@ static inline void clear_ptes(struct mm_struct *mm, unsigned long addr, */ #ifndef update_mmu_tlb_range static inline void update_mmu_tlb_range(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep, unsigned int nr) + unsigned long address, hw_pte_t *ptep, + unsigned int nr) { } #endif static inline void update_mmu_tlb(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { update_mmu_tlb_range(vma, address, ptep, 1); } @@ -1000,7 +1003,7 @@ static inline void update_mmu_tlb(struct vm_area_struct *vma, * The PTEs are all in the same PMD. */ static inline void clear_nonpresent_ptes(struct mm_struct *mm, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { (void)addr; @@ -1016,7 +1019,7 @@ static inline void clear_nonpresent_ptes(struct mm_struct *mm, #ifndef __HAVE_ARCH_PTEP_CLEAR_FLUSH extern pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address, - pte_t *ptep); + hw_pte_t *ptep); #endif #ifndef __HAVE_ARCH_PMDP_HUGE_CLEAR_FLUSH @@ -1044,7 +1047,8 @@ static inline pmd_t pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma) #ifndef __HAVE_ARCH_PTEP_SET_WRPROTECT struct mm_struct; -static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep) +static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, + hw_pte_t *ptep) { pte_t old_pte = ptep_get(ptep); set_pte_at(mm, address, ptep, pte_wrprotect(old_pte)); @@ -1070,7 +1074,7 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addres * ptep_try_set as an identity macro. The generic stub returns false, which is * correct for callers that fall through to oops on failure. */ -static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte) +static inline bool ptep_try_set(hw_pte_t *ptep, pte_t new_pte) { return false; } @@ -1113,7 +1117,7 @@ static inline void flush_tlb_before_set(unsigned long addr) * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, unsigned int nr) + hw_pte_t *ptep, unsigned int nr) { for (;;) { ptep_set_wrprotect(mm, addr, ptep); @@ -1144,7 +1148,7 @@ static inline void wrprotect_ptes(struct mm_struct *mm, unsigned long addr, * pages that belong to the same folio. The PTEs are all in the same PMD. */ static inline bool clear_flush_young_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { bool young = false; @@ -1181,7 +1185,7 @@ static inline bool clear_flush_young_ptes(struct vm_area_struct *vma, * Returns: whether any PTE was young. */ static inline bool test_and_clear_young_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { bool young = false; @@ -1585,7 +1589,7 @@ static inline int pmd_none_or_clear_bad(pmd_t *pmd) static inline pte_t __ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep) + hw_pte_t *ptep) { /* * Get the current pte state, but zero it out to make it @@ -1597,7 +1601,7 @@ static inline pte_t __ptep_modify_prot_start(struct vm_area_struct *vma, static inline void __ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pte_t pte) + hw_pte_t *ptep, pte_t pte) { /* * The pte is non-present, so there's no hardware state to @@ -1623,7 +1627,7 @@ static inline void __ptep_modify_prot_commit(struct vm_area_struct *vma, */ static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep) + hw_pte_t *ptep) { return __ptep_modify_prot_start(vma, addr, ptep); } @@ -1636,7 +1640,8 @@ static inline pte_t ptep_modify_prot_start(struct vm_area_struct *vma, */ static inline void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pte_t old_pte, pte_t pte) + hw_pte_t *ptep, pte_t old_pte, + pte_t pte) { __ptep_modify_prot_commit(vma, addr, ptep, pte); } @@ -1667,7 +1672,7 @@ static inline void ptep_modify_prot_commit(struct vm_area_struct *vma, */ #ifndef modify_prot_start_ptes static inline pte_t modify_prot_start_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { pte_t pte, tmp_pte; @@ -1707,7 +1712,7 @@ static inline pte_t modify_prot_start_ptes(struct vm_area_struct *vma, */ #ifndef modify_prot_commit_ptes static inline void modify_prot_commit_ptes(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pte_t old_pte, pte_t pte, unsigned int nr) + hw_pte_t *ptep, pte_t old_pte, pte_t pte, unsigned int nr) { int i; diff --git a/include/linux/rmap.h b/include/linux/rmap.h index 0b332770abeed..d28a7fb6f2c0e 100644 --- a/include/linux/rmap.h +++ b/include/linux/rmap.h @@ -868,7 +868,7 @@ struct page_vma_mapped_walk { struct vm_area_struct *vma; unsigned long address; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; unsigned int flags; bool pgoff_is_anon : 1; diff --git a/include/linux/swapops.h b/include/linux/swapops.h index e7d0d529f3e0f..40d2fd920558f 100644 --- a/include/linux/swapops.h +++ b/include/linux/swapops.h @@ -216,7 +216,8 @@ static inline swp_entry_t make_migration_entry_dirty(swp_entry_t entry) extern void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd, unsigned long address); -extern void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, pte_t *pte); +extern void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, + hw_pte_t *pte); #else /* CONFIG_MIGRATION */ static inline swp_entry_t make_readable_migration_entry(pgoff_t offset) { @@ -236,7 +237,8 @@ static inline swp_entry_t make_writable_migration_entry(pgoff_t offset) static inline void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd, unsigned long address) { } static inline void migration_entry_wait_huge(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte) { } + unsigned long addr, + hw_pte_t *pte) { } static inline swp_entry_t make_migration_entry_young(swp_entry_t entry) { diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index aed121d729b01..666ff2b3741da 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -8,7 +8,7 @@ #include #include #include -#include /* pgprot_t */ +#include /* pgprot_t, hw_pte_t */ #include #include @@ -120,7 +120,7 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr, uns #ifndef arch_vmap_pte_range_unmap_size static inline unsigned long arch_vmap_pte_range_unmap_size(unsigned long addr, - pte_t *ptep) + hw_pte_t *ptep) { return PAGE_SIZE; } diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h index ad384969e2cb2..1972d50b043a5 100644 --- a/include/trace/events/xen.h +++ b/include/trace/events/xen.h @@ -138,10 +138,10 @@ TRACE_EVENT(xen_mc_extend_args, TRACE_DEFINE_SIZEOF(pteval_t); TRACE_EVENT(xen_mmu_set_pte, - TP_PROTO(pte_t *ptep, pte_t pteval), + TP_PROTO(hw_pte_t *ptep, pte_t pteval), TP_ARGS(ptep, pteval), TP_STRUCT__entry( - __field(pte_t *, ptep) + __field(hw_pte_t *, ptep) __field(pteval_t, pteval) ), TP_fast_assign(__entry->ptep = ptep; @@ -207,12 +207,12 @@ TRACE_EVENT(xen_mmu_set_p4d, DECLARE_EVENT_CLASS(xen_mmu_ptep_modify_prot, TP_PROTO(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pteval), + hw_pte_t *ptep, pte_t pteval), TP_ARGS(mm, addr, ptep, pteval), TP_STRUCT__entry( __field(struct mm_struct *, mm) __field(unsigned long, addr) - __field(pte_t *, ptep) + __field(hw_pte_t *, ptep) __field(pteval_t, pteval) ), TP_fast_assign(__entry->mm = mm; @@ -227,7 +227,7 @@ DECLARE_EVENT_CLASS(xen_mmu_ptep_modify_prot, #define DEFINE_XEN_MMU_PTEP_MODIFY_PROT(name) \ DEFINE_EVENT(xen_mmu_ptep_modify_prot, name, \ TP_PROTO(struct mm_struct *mm, unsigned long addr, \ - pte_t *ptep, pte_t pteval), \ + hw_pte_t *ptep, pte_t pteval), \ TP_ARGS(mm, addr, ptep, pteval)) DEFINE_XEN_MMU_PTEP_MODIFY_PROT(xen_mmu_ptep_modify_prot_start); diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c index 7b6847200b431..62005229b2e94 100644 --- a/kernel/bpf/arena.c +++ b/kernel/bpf/arena.c @@ -155,7 +155,7 @@ struct clear_range_data { struct llist_head *free_pages; }; -static int apply_range_set_cb(pte_t *pte, unsigned long addr, void *data) +static int apply_range_set_cb(hw_pte_t *pte, unsigned long addr, void *data) { struct apply_range_data *d = data; struct page *page; @@ -207,7 +207,7 @@ static void flush_vmap_cache(unsigned long start, unsigned long size) flush_cache_vmap(start, start + size); } -static int apply_range_clear_cb(pte_t *pte, unsigned long addr, void *data) +static int apply_range_clear_cb(hw_pte_t *pte, unsigned long addr, void *data) { struct clear_range_data *d = data; pte_t old_pte; @@ -238,7 +238,8 @@ static int apply_range_clear_cb(pte_t *pte, unsigned long addr, void *data) return 0; } -static int apply_range_set_scratch_cb(pte_t *pte, unsigned long addr, void *data) +static int apply_range_set_scratch_cb(hw_pte_t *pte, unsigned long addr, + void *data) { struct page *scratch_page = data; @@ -340,7 +341,7 @@ static struct bpf_map *arena_map_alloc(union bpf_attr *attr) return ERR_PTR(err); } -static int existing_page_cb(pte_t *ptep, unsigned long addr, void *data) +static int existing_page_cb(hw_pte_t *ptep, unsigned long addr, void *data) { struct bpf_arena *arena = data; struct page *page; diff --git a/kernel/events/core.c b/kernel/events/core.c index a6c8e38a31104..0369f6c95ba7d 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -8517,7 +8517,8 @@ static u64 perf_get_pgtable_size(struct mm_struct *mm, unsigned long addr) p4d_t *p4dp, p4d; pud_t *pudp, pud; pmd_t *pmdp, pmd; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; pgdp = pgd_offset(mm, addr); pgd = pgdp_get(pgdp); diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c index 7a2e40bc7baed..f844a44752a81 100644 --- a/mm/damon/ops-common.c +++ b/mm/damon/ops-common.c @@ -39,7 +39,7 @@ struct folio *damon_get_folio(unsigned long pfn) return folio; } -void damon_ptep_mkold(pte_t *pte, struct vm_area_struct *vma, unsigned long addr) +void damon_ptep_mkold(hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr) { pte_t pteval = ptep_get(pte); struct folio *folio; diff --git a/mm/damon/ops-common.h b/mm/damon/ops-common.h index 38d295488fa18..34b7e5715fcf9 100644 --- a/mm/damon/ops-common.h +++ b/mm/damon/ops-common.h @@ -7,7 +7,7 @@ struct folio *damon_get_folio(unsigned long pfn); -void damon_ptep_mkold(pte_t *pte, struct vm_area_struct *vma, unsigned long addr); +void damon_ptep_mkold(hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr); void damon_pmdp_mkold(pmd_t *pmd, struct vm_area_struct *vma, unsigned long addr); void damon_folio_mkold(struct folio *folio); bool damon_folio_young(struct folio *folio); diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c index 0648400b2d65b..e32b914720d5c 100644 --- a/mm/damon/vaddr.c +++ b/mm/damon/vaddr.c @@ -268,7 +268,7 @@ static void damon_va_walk_page_range(struct mm_struct *mm, unsigned long start, static int damon_mkold_pmd_entry(pmd_t *pmd, unsigned long addr, unsigned long next, struct mm_walk *walk) { - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; ptl = pmd_trans_huge_lock(pmd, walk->vma); @@ -293,7 +293,7 @@ static int damon_mkold_pmd_entry(pmd_t *pmd, unsigned long addr, } #ifdef CONFIG_HUGETLB_PAGE -static void damon_hugetlb_mkold(pte_t *pte, struct mm_struct *mm, +static void damon_hugetlb_mkold(hw_pte_t *pte, struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr) { bool referenced = false; @@ -320,7 +320,7 @@ static void damon_hugetlb_mkold(pte_t *pte, struct mm_struct *mm, folio_put(folio); } -static int damon_mkold_hugetlb_entry(pte_t *pte, unsigned long hmask, +static int damon_mkold_hugetlb_entry(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { @@ -389,7 +389,7 @@ struct damon_young_walk_private { static int damon_young_pmd_entry(pmd_t *pmd, unsigned long addr, unsigned long next, struct mm_walk *walk) { - pte_t *pte; + hw_pte_t *pte; pte_t ptent; spinlock_t *ptl; struct folio *folio; @@ -433,7 +433,7 @@ static int damon_young_pmd_entry(pmd_t *pmd, unsigned long addr, } #ifdef CONFIG_HUGETLB_PAGE -static int damon_young_hugetlb_entry(pte_t *pte, unsigned long hmask, +static int damon_young_hugetlb_entry(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { @@ -522,7 +522,7 @@ static unsigned int damon_va_check_accesses(struct damon_ctx *ctx) static bool damos_va_filter_young_match(struct damos_filter *filter, struct folio *folio, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pmd_t *pmdp) + unsigned long addr, hw_pte_t *ptep, pmd_t *pmdp) { bool young = false; @@ -544,7 +544,7 @@ static bool damos_va_filter_young_match(struct damos_filter *filter, static bool damos_va_filter_out(struct damos *scheme, struct folio *folio, struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pmd_t *pmdp) + hw_pte_t *ptep, pmd_t *pmdp) { struct damos_filter *filter; bool matched; @@ -641,7 +641,8 @@ static int damos_va_migrate_pmd_entry(pmd_t *pmd, unsigned long addr, struct damos_migrate_dests *dests = &s->migrate_dests; struct folio *folio; spinlock_t *ptl; - pte_t *start_pte, *pte, ptent; + hw_pte_t *start_pte, *pte; + pte_t ptent; int nr; #ifdef CONFIG_TRANSPARENT_HUGEPAGE @@ -801,7 +802,8 @@ static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned long addr, struct vm_area_struct *vma = walk->vma; struct folio *folio; spinlock_t *ptl; - pte_t *start_pte, *pte, ptent; + hw_pte_t *start_pte, *pte; + pte_t ptent; int nr; #ifdef CONFIG_TRANSPARENT_HUGEPAGE diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c index 2875fd22d7bb0..54e194d2a5854 100644 --- a/mm/debug_vm_pgtable.c +++ b/mm/debug_vm_pgtable.c @@ -50,7 +50,7 @@ struct pgtable_debug_args { p4d_t *p4dp; pud_t *pudp; pmd_t *pmdp; - pte_t *ptep; + hw_pte_t *ptep; p4d_t *start_p4dp; pud_t *start_pudp; diff --git a/mm/filemap.c b/mm/filemap.c index 00fd89cf6f550..98f89dcc55603 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3490,7 +3490,7 @@ static vm_fault_t filemap_fault_recheck_pte_none(struct vm_fault *vmf) { struct vm_area_struct *vma = vmf->vma; vm_fault_t ret = 0; - pte_t *ptep; + hw_pte_t *ptep; /* * We might have COW'ed a pagecache folio and might now have an mlocked @@ -3796,7 +3796,7 @@ static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf, vm_fault_t ret = 0; struct page *page = folio_page(folio, start); unsigned int count = 0; - pte_t *old_ptep = vmf->pte; + hw_pte_t *old_ptep = vmf->pte; unsigned long addr0; /* diff --git a/mm/gup.c b/mm/gup.c index d1ba59da94e9a..549f462a23b2f 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -761,7 +761,7 @@ static struct page *follow_huge_pmd(struct vm_area_struct *vma, #endif /* CONFIG_PGTABLE_HAS_HUGE_LEAVES */ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address, - pte_t *pte, unsigned int flags) + hw_pte_t *pte, unsigned int flags) { if (flags & FOLL_TOUCH) { pte_t orig_entry = ptep_get(pte); @@ -806,7 +806,8 @@ static struct page *follow_page_pte(struct vm_area_struct *vma, struct folio *folio; struct page *page; spinlock_t *ptl; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; int ret; ptep = pte_offset_map_lock(mm, pmd, address, &ptl); @@ -1035,7 +1036,7 @@ static int get_gate_page(struct mm_struct *mm, unsigned long address, p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; pte_t entry; int ret = -EFAULT; @@ -2838,7 +2839,7 @@ static unsigned long gup_fast_pte_range(pmd_t pmd, pmd_t *pmdp, unsigned int flags, struct page **pages) { unsigned long nr_pages = 0; - pte_t *ptep, *ptem; + hw_pte_t *ptep, *ptem; ptem = ptep = pte_offset_map(&pmd, addr); if (!ptep) diff --git a/mm/highmem.c b/mm/highmem.c index a33e411839517..87f94cac6106b 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -141,7 +141,7 @@ EXPORT_SYMBOL(__totalhigh_pages); static int pkmap_count[LAST_PKMAP]; static __cacheline_aligned_in_smp DEFINE_SPINLOCK(kmap_lock); -pte_t *pkmap_page_table; +hw_pte_t *pkmap_page_table; /* * Most architectures have no use for kmap_high_get(), so let's abstract @@ -532,9 +532,9 @@ static inline bool kmap_high_unmap_local(unsigned long vaddr) return false; } -static pte_t *__kmap_pte; +static hw_pte_t *__kmap_pte; -static pte_t *kmap_get_pte(unsigned long vaddr, int idx) +static hw_pte_t *kmap_get_pte(unsigned long vaddr, int idx) { if (IS_ENABLED(CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY)) /* @@ -549,8 +549,9 @@ static pte_t *kmap_get_pte(unsigned long vaddr, int idx) void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) { - pte_t pteval, *kmap_pte; unsigned long vaddr; + hw_pte_t *kmap_pte; + pte_t pteval; int idx; /* @@ -597,7 +598,7 @@ EXPORT_SYMBOL(__kmap_local_page_prot); void kunmap_local_indexed(const void *vaddr) { unsigned long addr = (unsigned long) vaddr & PAGE_MASK; - pte_t *kmap_pte; + hw_pte_t *kmap_pte; int idx; if (addr < __fix_to_virt(FIX_KMAP_END) || @@ -646,7 +647,7 @@ EXPORT_SYMBOL(kunmap_local_indexed); void __kmap_local_sched_out(void) { struct task_struct *tsk = current; - pte_t *kmap_pte; + hw_pte_t *kmap_pte; int i; /* Clear kmaps */ @@ -683,7 +684,7 @@ void __kmap_local_sched_out(void) void __kmap_local_sched_in(void) { struct task_struct *tsk = current; - pte_t *kmap_pte; + hw_pte_t *kmap_pte; int i; /* Restore kmaps */ diff --git a/mm/hmm.c b/mm/hmm.c index 2f1e98c6b6440..0c959611eda01 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -240,7 +240,7 @@ static inline unsigned long pte_to_hmm_pfn_flags(struct hmm_range *range, } static int hmm_vma_handle_pte(struct mm_walk *walk, unsigned long addr, - unsigned long end, pmd_t *pmdp, pte_t *ptep, + unsigned long end, pmd_t *pmdp, hw_pte_t *ptep, unsigned long *hmm_pfn) { struct hmm_vma_walk *hmm_vma_walk = walk->private; @@ -411,7 +411,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp, &range->hmm_pfns[(start - range->start) >> PAGE_SHIFT]; unsigned long npages = (end - start) >> PAGE_SHIFT; unsigned long addr = start; - pte_t *ptep; + hw_pte_t *ptep; pmd_t pmd; again: @@ -547,7 +547,7 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long start, unsigned long end, #endif #ifdef CONFIG_HUGETLB_PAGE -static int hmm_vma_walk_hugetlb_entry(pte_t *pte, unsigned long hmask, +static int hmm_vma_walk_hugetlb_entry(hw_pte_t *pte, unsigned long hmask, unsigned long start, unsigned long end, struct mm_walk *walk) { diff --git a/mm/huge_memory.c b/mm/huge_memory.c index c5d11147b69ae..8466a52381991 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3146,7 +3146,7 @@ static void __split_huge_zero_page_pmd(struct vm_area_struct *vma, pgtable_t pgtable; pmd_t _pmd, old_pmd; unsigned long addr; - pte_t *pte; + hw_pte_t *pte; int i; /* @@ -3196,7 +3196,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, bool soft_dirty, uffd_wp = false, young = false, write = false; bool anon_exclusive = false, dirty = false; unsigned long addr; - pte_t *pte; + hw_pte_t *pte; int i; VM_BUG_ON(haddr & ~HPAGE_PMD_MASK); diff --git a/mm/hugetlb.c b/mm/hugetlb.c index bfc0184ed95c7..c30e7584f1a5c 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -129,7 +129,7 @@ static void hugetlb_vma_lock_free(struct vm_area_struct *vma); static void hugetlb_vma_lock_alloc(struct vm_area_struct *vma); static void __hugetlb_vma_unlock_write_free(struct vm_area_struct *vma); static int __huge_pmd_unshare(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, + struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep, bool check_locks); static void hugetlb_unshare_pmds(struct vm_area_struct *vma, unsigned long start, unsigned long end, bool take_locks); @@ -4878,7 +4878,7 @@ static pte_t make_huge_pte(struct vm_area_struct *vma, struct folio *folio, } static void set_huge_ptep_writable(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { pte_t entry; @@ -4888,14 +4888,14 @@ static void set_huge_ptep_writable(struct vm_area_struct *vma, } static void set_huge_ptep_maybe_writable(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { if (vma->vm_flags & VM_WRITE) set_huge_ptep_writable(vma, address, ptep); } static void -hugetlb_install_folio(struct vm_area_struct *vma, pte_t *ptep, unsigned long addr, +hugetlb_install_folio(struct vm_area_struct *vma, hw_pte_t *ptep, unsigned long addr, struct folio *new_folio, pte_t old, unsigned long sz) { pte_t newpte = make_huge_pte(vma, new_folio, true); @@ -4921,7 +4921,8 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma) { - pte_t *src_pte, *dst_pte, entry; + hw_pte_t *src_pte, *dst_pte; + pte_t entry; struct folio *pte_folio; unsigned long addr; bool cow = vma_is_cow_mapping(src_vma); @@ -5113,7 +5114,8 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, } static void move_huge_pte(struct vm_area_struct *vma, unsigned long old_addr, - unsigned long new_addr, pte_t *src_pte, pte_t *dst_pte, + unsigned long new_addr, hw_pte_t *src_pte, + hw_pte_t *dst_pte, unsigned long sz) { bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma); @@ -5175,7 +5177,7 @@ int move_hugetlb_page_tables(struct vm_area_struct *vma, struct mm_struct *mm = vma->vm_mm; unsigned long old_end = old_addr + len; unsigned long last_addr_mask; - pte_t *src_pte, *dst_pte; + hw_pte_t *src_pte, *dst_pte; struct mmu_notifier_range range; struct mmu_gather tlb; @@ -5236,7 +5238,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma, struct mm_struct *mm = vma->vm_mm; const bool folio_provided = !!folio; unsigned long address; - pte_t *ptep; + hw_pte_t *ptep; pte_t pte; spinlock_t *ptl; struct hstate *h = hstate_vma(vma); @@ -5770,7 +5772,7 @@ static inline vm_fault_t hugetlb_handle_userfault(struct vm_fault *vmf, * false if pte changed or is changing. */ static bool hugetlb_pte_stable(struct hstate *h, struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t old_pte) + hw_pte_t *ptep, pte_t old_pte) { spinlock_t *ptl; bool same; @@ -6295,7 +6297,7 @@ static struct folio *alloc_hugetlb_folio_vma(struct hstate *h, * Used by userfaultfd UFFDIO_* ioctls. Based on userfaultfd's mfill_atomic_pte * with modifications for hugetlb pages. */ -int hugetlb_mfill_atomic_pte(pte_t *dst_pte, +int hugetlb_mfill_atomic_pte(hw_pte_t *dst_pte, struct vm_area_struct *dst_vma, unsigned long dst_addr, unsigned long src_addr, @@ -6354,7 +6356,7 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte, folio = alloc_hugetlb_folio(dst_vma, dst_addr, false); if (IS_ERR(folio)) { - pte_t *actual_pte = hugetlb_walk(dst_vma, dst_addr, PMD_SIZE); + hw_pte_t *actual_pte = hugetlb_walk(dst_vma, dst_addr, PMD_SIZE); if (actual_pte) { ret = -EEXIST; goto out; @@ -6522,7 +6524,7 @@ long hugetlb_change_protection(struct vm_area_struct *vma, { struct mm_struct *mm = vma->vm_mm; unsigned long start = address; - pte_t *ptep; + hw_pte_t *ptep; pte_t pte; struct hstate *h = hstate_vma(vma); long pages = 0, psize = huge_page_size(h); @@ -7007,15 +7009,15 @@ void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, * racing tasks could either miss the sharing (see huge_pte_offset) or select a * bad pmd for sharing. */ -pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, pud_t *pud) { struct address_space *mapping = vma->vm_file->f_mapping; const pgoff_t idx = linear_page_index(vma, addr); struct vm_area_struct *svma; unsigned long saddr; - pte_t *spte = NULL; - pte_t *pte; + hw_pte_t *spte = NULL; + hw_pte_t *pte; i_mmap_lock_read(mapping); mapping_rmap_tree_foreach(svma, mapping, idx, idx) { @@ -7046,13 +7048,13 @@ pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, } spin_unlock(&mm->page_table_lock); out: - pte = (pte_t *)pmd_alloc(mm, pud, addr); + pte = (hw_pte_t *)pmd_alloc(mm, pud, addr); i_mmap_unlock_read(mapping); return pte; } static int __huge_pmd_unshare(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, + struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep, bool check_locks) { unsigned long sz = huge_page_size(hstate_vma(vma)); @@ -7093,7 +7095,7 @@ static int __huge_pmd_unshare(struct mmu_gather *tlb, * was not a shared PMD table. */ int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { return __huge_pmd_unshare(tlb, vma, addr, ptep, /*check_locks=*/true); } @@ -7123,21 +7125,21 @@ void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma) #else /* !CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING */ -pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, pud_t *pud) { return NULL; } static int __huge_pmd_unshare(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, + struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep, bool check_locks) { return 0; } int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) + unsigned long addr, hw_pte_t *ptep) { return 0; } @@ -7158,13 +7160,13 @@ bool want_pmd_share(struct vm_area_struct *vma, unsigned long addr) #endif /* CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING */ #ifdef CONFIG_ARCH_WANT_GENERAL_HUGETLB -pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, +hw_pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, unsigned long addr, unsigned long sz) { pgd_t *pgd; p4d_t *p4d; pud_t *pud; - pte_t *pte = NULL; + hw_pte_t *pte = NULL; pgd = pgd_offset(mm, addr); p4d = p4d_alloc(mm, pgd, addr); @@ -7173,13 +7175,13 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, pud = pud_alloc(mm, p4d, addr); if (pud) { if (sz == PUD_SIZE) { - pte = (pte_t *)pud; + pte = (hw_pte_t *)pud; } else { BUG_ON(sz != PMD_SIZE); if (want_pmd_share(vma, addr) && pud_none(*pud)) pte = huge_pmd_share(mm, vma, addr, pud); else - pte = (pte_t *)pmd_alloc(mm, pud, addr); + pte = (hw_pte_t *)pmd_alloc(mm, pud, addr); } } @@ -7201,7 +7203,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, * size @sz doesn't match the hugepage size at this level of the page * table. */ -pte_t *huge_pte_offset(struct mm_struct *mm, +hw_pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz) { pgd_t *pgd; @@ -7219,14 +7221,14 @@ pte_t *huge_pte_offset(struct mm_struct *mm, pud = pud_offset(p4d, addr); if (sz == PUD_SIZE) /* must be pud huge, non-present or none */ - return (pte_t *)pud; + return (hw_pte_t *)pud; if (!pud_present(*pud)) return NULL; /* must have a valid entry and size to go further */ pmd = pmd_offset(pud, addr); /* must be pmd huge, non-present or none */ - return (pte_t *)pmd; + return (hw_pte_t *)pmd; } /* @@ -7405,7 +7407,7 @@ static void hugetlb_unshare_pmds(struct vm_area_struct *vma, struct mmu_gather tlb; unsigned long address; spinlock_t *ptl; - pte_t *ptep; + hw_pte_t *ptep; if (!(vma->vm_flags & VM_MAYSHARE)) return; diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c index eb339c4a71f40..bf85d82c29b96 100644 --- a/mm/hugetlb_vmemmap.c +++ b/mm/hugetlb_vmemmap.c @@ -34,7 +34,7 @@ * operations. */ struct vmemmap_remap_walk { - void (*remap_pte)(pte_t *pte, unsigned long addr, + void (*remap_pte)(hw_pte_t *pte, unsigned long addr, struct vmemmap_remap_walk *walk); unsigned long nr_walked; @@ -56,7 +56,7 @@ static int vmemmap_split_pmd(pmd_t *pmd, struct page *head, unsigned long start, pmd_t __pmd; int i; unsigned long addr = start; - pte_t *pgtable; + hw_pte_t *pgtable; pgtable = pte_alloc_one_kernel(&init_mm); if (!pgtable) @@ -65,7 +65,8 @@ static int vmemmap_split_pmd(pmd_t *pmd, struct page *head, unsigned long start, pmd_populate_kernel(&init_mm, &__pmd, pgtable); for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) { - pte_t entry, *pte; + pte_t entry; + hw_pte_t *pte; pgprot_t pgprot = PAGE_KERNEL; entry = mk_pte(head + i, pgprot); @@ -137,7 +138,7 @@ static int vmemmap_pmd_entry(pmd_t *pmd, unsigned long addr, return vmemmap_split_pmd(pmd, head, addr & PMD_MASK, vmemmap_walk); } -static int vmemmap_pte_entry(pte_t *pte, unsigned long addr, +static int vmemmap_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { struct vmemmap_remap_walk *vmemmap_walk = walk->private; @@ -199,7 +200,7 @@ static void free_vmemmap_page_list(struct list_head *list) free_vmemmap_page(page); } -static void vmemmap_remap_pte(pte_t *pte, unsigned long addr, +static void vmemmap_remap_pte(hw_pte_t *pte, unsigned long addr, struct vmemmap_remap_walk *walk) { struct page *page = pte_page(ptep_get(pte)); @@ -233,7 +234,7 @@ static void vmemmap_remap_pte(pte_t *pte, unsigned long addr, set_pte_at(&init_mm, addr, pte, entry); } -static void vmemmap_restore_pte(pte_t *pte, unsigned long addr, +static void vmemmap_restore_pte(hw_pte_t *pte, unsigned long addr, struct vmemmap_remap_walk *walk) { struct page *src = pte_page(ptep_get(pte)), *dst; diff --git a/mm/internal.h b/mm/internal.h index e16f1250b25c8..54efddc4536f4 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -263,7 +263,7 @@ void unmap_vmas(struct mmu_gather *tlb, struct unmap_desc *unmap); #ifdef CONFIG_MMU bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pte_t pte, + unsigned long addr, hw_pte_t *ptep, pte_t pte, unsigned long nr_ptes); static inline void get_anon_vma(struct anon_vma *anon_vma) @@ -394,7 +394,7 @@ static inline pte_t __pte_batch_clear_ignored(pte_t pte, fpb_t flags) * Return: the number of table entries in the batch. */ static inline unsigned int folio_pte_batch_flags(struct folio *folio, - struct vm_area_struct *vma, pte_t *ptep, pte_t *ptentp, + struct vm_area_struct *vma, hw_pte_t *ptep, pte_t *ptentp, unsigned int max_nr, fpb_t flags) { bool any_writable = false, any_young = false, any_dirty = false; @@ -448,7 +448,7 @@ static inline unsigned int folio_pte_batch_flags(struct folio *folio, return min(nr, max_nr); } -unsigned int folio_pte_batch(struct folio *folio, pte_t *ptep, pte_t pte, +unsigned int folio_pte_batch(struct folio *folio, hw_pte_t *ptep, pte_t pte, unsigned int max_nr); /** @@ -505,11 +505,11 @@ static inline pte_t pte_next_swp_offset(pte_t pte) * * Return: the number of table entries in the batch. */ -static inline int swap_pte_batch(pte_t *start_ptep, int max_nr, pte_t pte) +static inline int swap_pte_batch(hw_pte_t *start_ptep, int max_nr, pte_t pte) { pte_t expected_pte = pte_next_swp_offset(pte); - const pte_t *end_ptep = start_ptep + max_nr; - pte_t *ptep = start_ptep + 1; + const hw_pte_t *end_ptep = start_ptep + max_nr; + hw_pte_t *ptep = start_ptep + 1; VM_WARN_ON(max_nr < 1); VM_WARN_ON(!softleaf_is_swap(softleaf_from_pte(pte))); @@ -1547,7 +1547,7 @@ static inline void maybe_rmap_unlock_action(struct vm_area_struct *vma, #ifdef CONFIG_MMU_NOTIFIER static inline bool clear_flush_young_ptes_notify(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { bool young; @@ -1568,7 +1568,7 @@ static inline bool pmdp_clear_flush_young_notify(struct vm_area_struct *vma, } static inline bool test_and_clear_young_ptes_notify(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, unsigned int nr) + unsigned long addr, hw_pte_t *ptep, unsigned int nr) { bool young; diff --git a/mm/kasan/init.c b/mm/kasan/init.c index 66a8838879876..30c5266eaf37e 100644 --- a/mm/kasan/init.c +++ b/mm/kasan/init.c @@ -92,7 +92,7 @@ static __init void *early_alloc(size_t size, int node) static void __ref zero_pte_populate(pmd_t *pmd, unsigned long addr, unsigned long end) { - pte_t *pte = pte_offset_kernel(pmd, addr); + hw_pte_t *pte = pte_offset_kernel(pmd, addr); pte_t zero_pte; zero_pte = pfn_pte(PFN_DOWN(__pa_symbol(kasan_early_shadow_page)), @@ -122,7 +122,7 @@ static int __ref zero_pmd_populate(pud_t *pud, unsigned long addr, } if (pmd_none(*pmd)) { - pte_t *p; + hw_pte_t *p; if (slab_is_available()) p = pte_alloc_one_kernel(&init_mm); @@ -281,9 +281,9 @@ int __ref kasan_populate_early_shadow(const void *shadow_start, return 0; } -static void kasan_free_pte(pte_t *pte_start, pmd_t *pmd) +static void kasan_free_pte(hw_pte_t *pte_start, pmd_t *pmd) { - pte_t *pte; + hw_pte_t *pte; int i; for (i = 0; i < PTRS_PER_PTE; i++) { @@ -341,7 +341,7 @@ static void kasan_free_p4d(p4d_t *p4d_start, pgd_t *pgd) pgd_clear(pgd); } -static void kasan_remove_pte_table(pte_t *pte, unsigned long addr, +static void kasan_remove_pte_table(hw_pte_t *pte, unsigned long addr, unsigned long end) { unsigned long next; @@ -369,7 +369,7 @@ static void kasan_remove_pmd_table(pmd_t *pmd, unsigned long addr, unsigned long next; for (; addr < end; addr = next, pmd++) { - pte_t *pte; + hw_pte_t *pte; next = pmd_addr_end(addr, end); diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c index d286e0a045437..86fc7ed45dcd0 100644 --- a/mm/kasan/shadow.c +++ b/mm/kasan/shadow.c @@ -189,7 +189,7 @@ static bool shadow_mapped(unsigned long addr) p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; if (pgd_none(*pgd)) return false; @@ -297,7 +297,7 @@ struct vmalloc_populate_data { struct page **pages; }; -static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr, +static int kasan_populate_vmalloc_pte(hw_pte_t *ptep, unsigned long addr, void *_data) { struct vmalloc_populate_data *data = _data; @@ -465,7 +465,7 @@ int __kasan_populate_vmalloc(unsigned long addr, unsigned long size, gfp_t gfp_m return 0; } -static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr, +static int kasan_depopulate_vmalloc_pte(hw_pte_t *ptep, unsigned long addr, void *unused) { pte_t pte; diff --git a/mm/khugepaged.c b/mm/khugepaged.c index f49a6710933b1..4a7074f58b55d 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -639,8 +639,8 @@ static void release_pte_folio(struct folio *folio) folio_putback_lru(folio); } -static void release_pte_pages(pte_t *pte, pte_t *_pte, - struct list_head *compound_pagelist) +static void release_pte_pages(hw_pte_t *pte, hw_pte_t *_pte, + struct list_head *compound_pagelist) { struct folio *folio, *tmp; @@ -685,7 +685,8 @@ static void count_collapse_event(unsigned int order, enum vm_event_item vm_event } static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma, - unsigned long start_addr, pte_t *pte, struct collapse_control *cc, + unsigned long start_addr, hw_pte_t *pte, + struct collapse_control *cc, unsigned int order, struct list_head *compound_pagelist) { const unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, order); @@ -694,7 +695,7 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma, struct page *page = NULL; struct folio *folio = NULL; unsigned long addr = start_addr; - pte_t *_pte; + hw_pte_t *_pte; int none_or_zero = 0, shared = 0, referenced = 0; enum scan_result result = SCAN_FAIL; @@ -840,16 +841,18 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma, return result; } -static void __collapse_huge_page_copy_succeeded(pte_t *pte, - struct vm_area_struct *vma, unsigned long address, - spinlock_t *ptl, unsigned int order, - struct list_head *compound_pagelist) +static void __collapse_huge_page_copy_succeeded(hw_pte_t *pte, + struct vm_area_struct *vma, + unsigned long address, + spinlock_t *ptl, + unsigned int order, + struct list_head *compound_pagelist) { const unsigned long nr_pages = 1UL << order; unsigned long end = address + (PAGE_SIZE * nr_pages); struct folio *src, *tmp; pte_t pteval; - pte_t *_pte; + hw_pte_t *_pte; unsigned int nr_ptes; for (_pte = pte; _pte < pte + nr_pages; _pte += nr_ptes, @@ -904,9 +907,11 @@ static void __collapse_huge_page_copy_succeeded(pte_t *pte, } } -static void __collapse_huge_page_copy_failed(pte_t *pte, - pmd_t *pmd, pmd_t orig_pmd, struct vm_area_struct *vma, - unsigned int order, struct list_head *compound_pagelist) +static void __collapse_huge_page_copy_failed(hw_pte_t *pte, + pmd_t *pmd, pmd_t orig_pmd, + struct vm_area_struct *vma, + unsigned int order, + struct list_head *compound_pagelist) { const unsigned long nr_pages = 1UL << order; spinlock_t *pmd_ptl; @@ -942,10 +947,14 @@ static void __collapse_huge_page_copy_failed(pte_t *pte, * @ptl: lock on raw pages' PTEs * @compound_pagelist: list that stores compound pages */ -static enum scan_result __collapse_huge_page_copy(pte_t *pte, struct folio *folio, - pmd_t *pmd, pmd_t orig_pmd, struct vm_area_struct *vma, - unsigned long address, spinlock_t *ptl, unsigned int order, - struct list_head *compound_pagelist) +static enum scan_result __collapse_huge_page_copy(hw_pte_t *pte, + struct folio *folio, + pmd_t *pmd, pmd_t orig_pmd, + struct vm_area_struct *vma, + unsigned long address, + spinlock_t *ptl, + unsigned int order, + struct list_head *compound_pagelist) { const unsigned long nr_pages = 1UL << order; unsigned int i; @@ -1164,7 +1173,7 @@ static enum scan_result __collapse_huge_page_swapin(struct mm_struct *mm, vm_fault_t ret = 0; unsigned long addr, end = start_addr + (PAGE_SIZE << order); enum scan_result result; - pte_t *pte = NULL; + hw_pte_t *pte = NULL; spinlock_t *ptl; for (addr = start_addr; addr < end; addr += PAGE_SIZE) { @@ -1292,7 +1301,7 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s const unsigned long end_addr = start_addr + (PAGE_SIZE << order); LIST_HEAD(compound_pagelist); pmd_t *pmd, _pmd; - pte_t *pte = NULL; + hw_pte_t *pte = NULL; pgtable_t pgtable; struct folio *folio; spinlock_t *pmd_ptl, *pte_ptl; @@ -1606,7 +1615,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm, unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER); enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE; pmd_t *pmd; - pte_t *pte, *_pte, pteval; + hw_pte_t *pte, *_pte; + pte_t pteval; int i; int none_or_zero = 0, shared = 0, referenced = 0; enum scan_result result = SCAN_FAIL; @@ -1871,7 +1881,7 @@ static enum scan_result try_collapse_pte_mapped_thp(struct mm_struct *mm, unsign unsigned long end = haddr + HPAGE_PMD_SIZE; struct vm_area_struct *vma = vma_lookup(mm, haddr); struct folio *folio; - pte_t *start_pte, *pte; + hw_pte_t *start_pte, *pte; pmd_t *pmd, pgt_pmd; spinlock_t *pml = NULL, *ptl; int i; diff --git a/mm/ksm.c b/mm/ksm.c index 2a4f19fe0f696..3882d8916efa4 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -618,7 +618,7 @@ static int break_ksm_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned long en { unsigned long *found_addr = (unsigned long *) walk->private; struct mm_struct *mm = walk->mm; - pte_t *start_ptep, *ptep; + hw_pte_t *start_ptep, *ptep; spinlock_t *ptl; int found = 0; @@ -1399,7 +1399,7 @@ static int replace_page(struct vm_area_struct *vma, struct page *page, struct folio *folio = page_folio(page); pmd_t *pmd; pmd_t pmde; - pte_t *ptep; + hw_pte_t *ptep; pte_t newpte; spinlock_t *ptl; unsigned long addr; @@ -2530,7 +2530,8 @@ static int ksm_next_page_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned lon { struct ksm_next_page_arg *private = walk->private; struct vm_area_struct *vma = walk->vma; - pte_t *start_ptep = NULL, *ptep, pte; + hw_pte_t *start_ptep = NULL, *ptep; + pte_t pte; struct mm_struct *mm = walk->mm; struct folio *folio; struct page *page; diff --git a/mm/madvise.c b/mm/madvise.c index dd75a673e108f..a08270c9f7610 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -198,7 +198,7 @@ static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start, { struct vm_area_struct *vma = walk->private; struct swap_io_ctx ctx = {}; - pte_t *ptep = NULL; + hw_pte_t *ptep = NULL; spinlock_t *ptl; unsigned long addr; @@ -350,7 +350,7 @@ static inline bool can_do_file_pageout(struct vm_area_struct *vma) } static inline int madvise_folio_pte_batch(unsigned long addr, unsigned long end, - struct folio *folio, pte_t *ptep, + struct folio *folio, hw_pte_t *ptep, pte_t *ptentp) { int max_nr = (end - addr) / PAGE_SIZE; @@ -368,7 +368,8 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, bool pageout = private->pageout; struct mm_struct *mm = tlb->mm; struct vm_area_struct *vma = walk->vma; - pte_t *start_pte, *pte, ptent; + hw_pte_t *start_pte, *pte; + pte_t ptent; spinlock_t *ptl; struct folio *folio = NULL; LIST_HEAD(folio_list); @@ -670,7 +671,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, struct mm_struct *mm = tlb->mm; struct vm_area_struct *vma = walk->vma; spinlock_t *ptl; - pte_t *start_pte, *pte, ptent; + hw_pte_t *start_pte, *pte; + pte_t ptent; struct folio *folio; int nr_swap = 0; unsigned long next; @@ -1095,7 +1097,7 @@ static int guard_install_pmd_entry(pmd_t *pmd, unsigned long addr, return pmd_trans_huge(pmdval); } -static int guard_install_pte_entry(pte_t *pte, unsigned long addr, +static int guard_install_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { pte_t pteval = ptep_get(pte); @@ -1238,7 +1240,7 @@ static int guard_remove_pmd_entry(pmd_t *pmd, unsigned long addr, return 0; } -static int guard_remove_pte_entry(pte_t *pte, unsigned long addr, +static int guard_remove_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { pte_t ptent = ptep_get(pte); diff --git a/mm/mapping_dirty_helpers.c b/mm/mapping_dirty_helpers.c index e0efa36e0a076..dcbd39912f819 100644 --- a/mm/mapping_dirty_helpers.c +++ b/mm/mapping_dirty_helpers.c @@ -31,7 +31,7 @@ struct wp_walk { * The function write-protects a pte and records the range in * virtual address space of touched ptes for efficient range TLB flushes. */ -static int wp_pte(pte_t *pte, unsigned long addr, unsigned long end, +static int wp_pte(hw_pte_t *pte, unsigned long addr, unsigned long end, struct mm_walk *walk) { struct wp_walk *wpwalk = walk->private; @@ -86,7 +86,7 @@ struct clean_walk { * in the address_space, as well as the first and last of the bits * touched. */ -static int clean_record_pte(pte_t *pte, unsigned long addr, +static int clean_record_pte(hw_pte_t *pte, unsigned long addr, unsigned long end, struct mm_walk *walk) { struct wp_walk *wpwalk = walk->private; diff --git a/mm/memory-failure.c b/mm/memory-failure.c index a8b03e2920ba8..a89f3fde47a5d 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -342,7 +342,7 @@ static unsigned long dev_pagemap_mapping_shift(struct vm_area_struct *vma, p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; pte_t ptent; VM_BUG_ON_VMA(address == -EFAULT, vma); @@ -742,7 +742,7 @@ static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr, { struct hwpoison_walk *hwp = walk->private; int ret = 0; - pte_t *ptep, *mapped_pte; + hw_pte_t *ptep, *mapped_pte; spinlock_t *ptl; ptl = pmd_trans_huge_lock(pmdp, walk->vma); @@ -770,7 +770,7 @@ static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr, } #ifdef CONFIG_HUGETLB_PAGE -static int hwpoison_hugetlb_range(pte_t *ptep, unsigned long hmask, +static int hwpoison_hugetlb_range(hw_pte_t *ptep, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { diff --git a/mm/memory.c b/mm/memory.c index ec63dd6212ac5..7fc8ce10503c3 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -462,7 +462,7 @@ int __pte_alloc(struct mm_struct *mm, pmd_t *pmd) int __pte_alloc_kernel(pmd_t *pmd) { - pte_t *new = pte_alloc_one_kernel(&init_mm); + hw_pte_t *new = pte_alloc_one_kernel(&init_mm); if (!new) return -ENOMEM; @@ -909,7 +909,7 @@ struct page *vm_normal_page_pud(struct vm_area_struct *vma, */ static void restore_exclusive_pte(struct vm_area_struct *vma, struct folio *folio, struct page *page, unsigned long address, - pte_t *ptep, pte_t orig_pte) + hw_pte_t *ptep, pte_t orig_pte) { pte_t pte; @@ -946,7 +946,7 @@ static void restore_exclusive_pte(struct vm_area_struct *vma, * sleeping. */ static int try_restore_exclusive_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pte_t orig_pte) + unsigned long addr, hw_pte_t *ptep, pte_t orig_pte) { const softleaf_t entry = softleaf_from_pte(orig_pte); struct page *page = softleaf_to_page(entry); @@ -969,7 +969,7 @@ static int try_restore_exclusive_pte(struct vm_area_struct *vma, static unsigned long copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, - pte_t *dst_pte, pte_t *src_pte, struct vm_area_struct *dst_vma, + hw_pte_t *dst_pte, hw_pte_t *src_pte, struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, unsigned long addr, int *rss) { pte_t orig_pte = ptep_get(src_pte); @@ -1083,7 +1083,7 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm, */ static inline int copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, - pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss, + hw_pte_t *dst_pte, hw_pte_t *src_pte, unsigned long addr, int *rss, struct folio **prealloc, struct page *page) { struct folio *new_folio; @@ -1122,7 +1122,7 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma } static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma, - struct vm_area_struct *src_vma, pte_t *dst_pte, pte_t *src_pte, + struct vm_area_struct *src_vma, hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t pte, unsigned long addr, int nr) { struct mm_struct *src_mm = src_vma->vm_mm; @@ -1172,7 +1172,7 @@ static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma, */ static inline int copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, - pte_t *dst_pte, pte_t *src_pte, pte_t pte, unsigned long addr, + hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t pte, unsigned long addr, int max_nr, int *rss, struct folio **prealloc) { fpb_t flags = FPB_MERGE_WRITE; @@ -1272,8 +1272,8 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, { struct mm_struct *dst_mm = dst_vma->vm_mm; struct mm_struct *src_mm = src_vma->vm_mm; - pte_t *orig_src_pte, *orig_dst_pte; - pte_t *src_pte, *dst_pte; + hw_pte_t *orig_src_pte, *orig_dst_pte; + hw_pte_t *src_pte, *dst_pte; pmd_t dummy_pmdval; pte_t ptent; spinlock_t *src_ptl, *dst_ptl; @@ -1666,7 +1666,7 @@ static inline bool zap_drop_markers(struct zap_details *details) * Returns true if uffd-wp PTEs were installed, false otherwise. */ bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pte_t pte, + unsigned long addr, hw_pte_t *ptep, pte_t pte, unsigned long nr_ptes) { bool arm_uffd_pte = false; @@ -1720,7 +1720,7 @@ bool cond_install_uffd_wp_ptes(struct vm_area_struct *vma, */ static inline bool zap_install_uffd_wp_if_needed(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte, int nr, + unsigned long addr, hw_pte_t *pte, int nr, struct zap_details *details, pte_t pteval) { if (zap_drop_markers(details)) @@ -1731,7 +1731,7 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma, static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb, struct vm_area_struct *vma, struct folio *folio, - struct page *page, pte_t *pte, pte_t ptent, unsigned int nr, + struct page *page, hw_pte_t *pte, pte_t ptent, unsigned int nr, unsigned long addr, struct zap_details *details, int *rss, bool *force_flush, bool *force_break, bool *any_skipped) { @@ -1781,7 +1781,7 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb, * Returns the number of processed (skipped or zapped) PTEs (at least 1). */ static inline int zap_present_ptes(struct mmu_gather *tlb, - struct vm_area_struct *vma, pte_t *pte, pte_t ptent, + struct vm_area_struct *vma, hw_pte_t *pte, pte_t ptent, unsigned int max_nr, unsigned long addr, struct zap_details *details, int *rss, bool *force_flush, bool *force_break, bool *any_skipped) @@ -1827,7 +1827,7 @@ static inline int zap_present_ptes(struct mmu_gather *tlb, } static inline int zap_nonpresent_ptes(struct mmu_gather *tlb, - struct vm_area_struct *vma, pte_t *pte, pte_t ptent, + struct vm_area_struct *vma, hw_pte_t *pte, pte_t ptent, unsigned int max_nr, unsigned long addr, struct zap_details *details, int *rss, bool *any_skipped) { @@ -1898,7 +1898,7 @@ static inline int zap_nonpresent_ptes(struct mmu_gather *tlb, } static inline int do_zap_pte_range(struct mmu_gather *tlb, - struct vm_area_struct *vma, pte_t *pte, + struct vm_area_struct *vma, hw_pte_t *pte, unsigned long addr, unsigned long end, struct zap_details *details, int *rss, bool *force_flush, bool *force_break, @@ -1961,7 +1961,7 @@ static bool zap_pte_table_if_empty(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, pmd_t *pmdval) { spinlock_t *pml, *ptl = NULL; - pte_t *start_pte, *pte; + hw_pte_t *start_pte, *pte; int i; pml = pmd_lock(mm, pmd); @@ -2001,8 +2001,8 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb, struct mm_struct *mm = tlb->mm; int rss[NR_MM_COUNTERS]; spinlock_t *ptl; - pte_t *start_pte; - pte_t *pte; + hw_pte_t *start_pte; + hw_pte_t *pte; pmd_t pmdval; unsigned long start = addr; bool direct_reclaim = true; @@ -2384,7 +2384,7 @@ static pmd_t *walk_to_pmd(struct mm_struct *mm, unsigned long addr) return pmd; } -pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr, +hw_pte_t *get_locked_pte(struct mm_struct *mm, unsigned long addr, spinlock_t **ptl) { pmd_t *pmd = walk_to_pmd(mm, addr); @@ -2442,7 +2442,7 @@ static int validate_page_before_insert(struct vm_area_struct *vma, return 0; } -static int insert_page_into_pte_locked(struct vm_area_struct *vma, pte_t *pte, +static int insert_page_into_pte_locked(struct vm_area_struct *vma, hw_pte_t *pte, unsigned long addr, struct page *page, pgprot_t prot, bool mkwrite) { @@ -2487,7 +2487,7 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr, struct page *page, pgprot_t prot, bool mkwrite) { int retval; - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; retval = validate_page_before_insert(vma, page); @@ -2504,7 +2504,7 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr, return retval; } -static int insert_page_in_batch_locked(struct vm_area_struct *vma, pte_t *pte, +static int insert_page_in_batch_locked(struct vm_area_struct *vma, hw_pte_t *pte, unsigned long addr, struct page *page, pgprot_t prot) { int err; @@ -2522,7 +2522,7 @@ static int insert_pages(struct vm_area_struct *vma, unsigned long addr, struct page **pages, unsigned long *num, pgprot_t prot) { pmd_t *pmd = NULL; - pte_t *start_pte, *pte; + hw_pte_t *start_pte, *pte; spinlock_t *pte_lock; struct mm_struct *const mm = vma->vm_mm; unsigned long curr_page_idx = 0; @@ -2765,7 +2765,8 @@ static vm_fault_t insert_pfn(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn, pgprot_t prot, bool mkwrite) { struct mm_struct *mm = vma->vm_mm; - pte_t *pte, entry; + hw_pte_t *pte; + pte_t entry; spinlock_t *ptl; pte = get_locked_pte(mm, addr, &ptl); @@ -3006,7 +3007,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, unsigned long end, unsigned long pfn, pgprot_t prot) { - pte_t *pte, *mapped_pte; + hw_pte_t *pte, *mapped_pte; spinlock_t *ptl; int err = 0; @@ -3407,7 +3408,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd, pte_fn_t fn, void *data, bool create, pgtbl_mod_mask *mask) { - pte_t *pte, *mapped_pte; + hw_pte_t *pte, *mapped_pte; int err = 0; spinlock_t *ptl; @@ -4710,7 +4711,7 @@ static vm_fault_t handle_pte_marker(struct vm_fault *vmf) /* * Check if the PTEs within a range are contiguous swap entries. */ -static bool can_swapin_thp(struct vm_fault *vmf, pte_t *ptep, int nr_pages) +static bool can_swapin_thp(struct vm_fault *vmf, hw_pte_t *ptep, int nr_pages) { unsigned long addr; int idx; @@ -4762,7 +4763,7 @@ static unsigned long thp_swapin_suitable_orders(struct vm_fault *vmf) unsigned long addr; softleaf_t entry; spinlock_t *ptl; - pte_t *pte; + hw_pte_t *pte; int order; /* @@ -4856,7 +4857,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) int nr_pages; unsigned long page_idx; unsigned long address; - pte_t *ptep; + hw_pte_t *ptep; if (!pte_unmap_same(vmf)) goto out; @@ -5025,7 +5026,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) unsigned long idx = folio_page_idx(folio, page); unsigned long folio_start = address - idx * PAGE_SIZE; unsigned long folio_end = folio_start + nr * PAGE_SIZE; - pte_t *folio_ptep; + hw_pte_t *folio_ptep; pte_t folio_pte; if (unlikely(folio_start < max(address & PMD_MASK, vma->vm_start))) @@ -5255,7 +5256,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) return ret; } -static bool pte_range_none(pte_t *pte, int nr_pages) +static bool pte_range_none(hw_pte_t *pte, int nr_pages) { int i; @@ -5274,7 +5275,7 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf) unsigned long orders; struct folio *folio; unsigned long addr; - pte_t *pte; + hw_pte_t *pte; gfp_t gfp; int order; @@ -5356,7 +5357,7 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf) return folio_prealloc(vma->vm_mm, vma, vmf->address, true); } -void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte, +void map_anon_folio_pte_nopf(struct folio *folio, hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr, bool uffd_wp) { @@ -5377,7 +5378,7 @@ void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte, update_mmu_cache_range(NULL, vma, addr, pte, nr_pages); } -static void map_anon_folio_pte_pf(struct folio *folio, pte_t *pte, +static void map_anon_folio_pte_pf(struct folio *folio, hw_pte_t *pte, struct vm_area_struct *vma, unsigned long addr, bool uffd_wp) { const unsigned int order = folio_order(folio); @@ -6162,7 +6163,7 @@ int numa_migrate_check(struct folio *folio, struct vm_fault *vmf, } static void numa_rebuild_single_mapping(struct vm_fault *vmf, struct vm_area_struct *vma, - unsigned long fault_addr, pte_t *fault_pte, + unsigned long fault_addr, hw_pte_t *fault_pte, bool writable) { pte_t pte, old_pte; @@ -6184,7 +6185,7 @@ static void numa_rebuild_large_mapping(struct vm_fault *vmf, struct vm_area_stru unsigned long start, end, addr = vmf->address; unsigned long addr_start = addr - (nr << PAGE_SHIFT); unsigned long pt_start = ALIGN_DOWN(addr, PMD_SIZE); - pte_t *start_ptep; + hw_pte_t *start_ptep; /* Stay within the VMA and within the page table. */ start = max3(addr_start, pt_start, vma->vm_start); @@ -6944,7 +6945,7 @@ int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address) #endif /* __PAGETABLE_PMD_FOLDED */ static inline void pfnmap_args_setup(struct follow_pfnmap_args *args, - spinlock_t *lock, pte_t *ptep, + spinlock_t *lock, hw_pte_t *ptep, pgprot_t pgprot, unsigned long pfn_base, unsigned long addr_mask, bool writable, bool special) @@ -7013,7 +7014,8 @@ int follow_pfnmap_start(struct follow_pfnmap_args *args) p4d_t *p4dp, p4d; pud_t *pudp, pud; pmd_t *pmdp, pmd; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; pfnmap_lockdep_assert(vma); diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 2ad0a5f18280a..51ab12fa4cb61 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -710,7 +710,7 @@ static int queue_folios_pte_range(pmd_t *pmd, unsigned long addr, struct folio *folio; struct queue_pages *qp = walk->private; unsigned long flags = qp->flags; - pte_t *pte, *mapped_pte; + hw_pte_t *pte, *mapped_pte; pte_t ptent; spinlock_t *ptl; int max_nr, nr; @@ -790,7 +790,7 @@ static int queue_folios_pte_range(pmd_t *pmd, unsigned long addr, return 0; } -static int queue_folios_hugetlb(pte_t *pte, unsigned long hmask, +static int queue_folios_hugetlb(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { diff --git a/mm/migrate.c b/mm/migrate.c index a369d0c95c386..75b4b637290c2 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -494,7 +494,7 @@ void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd, unsigned long address) { spinlock_t *ptl; - pte_t *ptep; + hw_pte_t *ptep; pte_t pte; softleaf_t entry; @@ -525,7 +525,7 @@ void migration_entry_wait(struct mm_struct *mm, pmd_t *pmd, * * This function will release the vma lock before returning. */ -void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep) +void migration_entry_wait_huge(struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep) { spinlock_t *ptl = huge_pte_lockptr(hstate_vma(vma), vma->vm_mm, ptep); softleaf_t entry; diff --git a/mm/migrate_device.c b/mm/migrate_device.c index 009bfa8b212d5..6138833fa902b 100644 --- a/mm/migrate_device.c +++ b/mm/migrate_device.c @@ -254,7 +254,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp, spinlock_t *ptl; struct folio *fault_folio = migrate->fault_page ? page_folio(migrate->fault_page) : NULL; - pte_t *ptep; + hw_pte_t *ptep; again: if (pmd_trans_huge(*pmdp) || !pmd_present(*pmdp)) { @@ -989,7 +989,7 @@ static void migrate_vma_insert_page(struct migrate_vma *migrate, p4d_t *p4dp; pud_t *pudp; pmd_t *pmdp; - pte_t *ptep; + hw_pte_t *ptep; pte_t orig_pte; /* Only allow populating anonymous memory */ diff --git a/mm/mincore.c b/mm/mincore.c index c086836bc4bcc..65cc43c85d03f 100644 --- a/mm/mincore.c +++ b/mm/mincore.c @@ -24,7 +24,7 @@ #include "swap.h" #include "internal.h" -static int mincore_hugetlb(pte_t *pte, unsigned long hmask, unsigned long addr, +static int mincore_hugetlb(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long end, struct mm_walk *walk) { #ifdef CONFIG_HUGETLB_PAGE @@ -164,7 +164,7 @@ static int mincore_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, { spinlock_t *ptl; struct vm_area_struct *vma = walk->vma; - pte_t *ptep; + hw_pte_t *ptep; unsigned char *vec = walk->private; int nr = (end - addr) >> PAGE_SHIFT; int step, i; diff --git a/mm/mlock.c b/mm/mlock.c index efa6716e4dfbd..36002b80382a9 100644 --- a/mm/mlock.c +++ b/mm/mlock.c @@ -305,7 +305,7 @@ void munlock_folio(struct folio *folio) } static inline unsigned int folio_mlock_step(struct folio *folio, - pte_t *pte, unsigned long addr, unsigned long end) + hw_pte_t *pte, unsigned long addr, unsigned long end) { unsigned int count = (end - addr) >> PAGE_SHIFT; pte_t ptent = ptep_get(pte); @@ -353,7 +353,7 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr, { struct vm_area_struct *vma = walk->vma; spinlock_t *ptl; - pte_t *start_pte, *pte; + hw_pte_t *start_pte, *pte; pte_t ptent; struct folio *folio; unsigned int step = 1; diff --git a/mm/mprotect.c b/mm/mprotect.c index 2888ee638d872..1d23475e0bb76 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -103,7 +103,7 @@ bool can_change_pte_writable(struct vm_area_struct *vma, unsigned long addr, return can_change_shared_pte_writable(vma, pte); } -static int mprotect_folio_pte_batch(struct folio *folio, pte_t *ptep, +static int mprotect_folio_pte_batch(struct folio *folio, hw_pte_t *ptep, pte_t pte, int max_nr_ptes, fpb_t flags) { /* No underlying folio, so cannot batch */ @@ -118,7 +118,7 @@ static int mprotect_folio_pte_batch(struct folio *folio, pte_t *ptep, /* Set nr_ptes number of ptes, starting from idx */ static __always_inline void prot_commit_flush_ptes(struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep, pte_t oldpte, pte_t ptent, + unsigned long addr, hw_pte_t *ptep, pte_t oldpte, pte_t ptent, int nr_ptes, int idx, bool set_write, struct mmu_gather *tlb) { /* @@ -170,7 +170,7 @@ static __always_inline int page_anon_exclusive_batch(int start_idx, int max_len, * retrieve sub-batches. */ static __always_inline void commit_anon_folio_batch(struct vm_area_struct *vma, - struct folio *folio, struct page *first_page, unsigned long addr, pte_t *ptep, + struct folio *folio, struct page *first_page, unsigned long addr, hw_pte_t *ptep, pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb) { bool expected_anon_exclusive; @@ -189,7 +189,7 @@ static __always_inline void commit_anon_folio_batch(struct vm_area_struct *vma, } static __always_inline void set_write_prot_commit_flush_ptes(struct vm_area_struct *vma, - struct folio *folio, struct page *page, unsigned long addr, pte_t *ptep, + struct folio *folio, struct page *page, unsigned long addr, hw_pte_t *ptep, pte_t oldpte, pte_t ptent, int nr_ptes, struct mmu_gather *tlb) { bool set_write; @@ -212,7 +212,7 @@ static __always_inline void set_write_prot_commit_flush_ptes(struct vm_area_stru } static long change_softleaf_pte(struct vm_area_struct *vma, - unsigned long addr, pte_t *pte, pte_t oldpte, unsigned long cp_flags) + unsigned long addr, hw_pte_t *pte, pte_t oldpte, unsigned long cp_flags) { const bool uffd_prot = cp_flags & (MM_CP_UFFD_WP | MM_CP_UFFD_RWP); const bool uffd_prot_resolve = cp_flags & @@ -279,7 +279,7 @@ static long change_softleaf_pte(struct vm_area_struct *vma, } static __always_inline void change_present_ptes(struct mmu_gather *tlb, - struct vm_area_struct *vma, unsigned long addr, pte_t *ptep, + struct vm_area_struct *vma, unsigned long addr, hw_pte_t *ptep, int nr_ptes, unsigned long end, pgprot_t newprot, struct folio *folio, struct page *page, unsigned long cp_flags) { @@ -332,7 +332,8 @@ static long change_pte_range(struct mmu_gather *tlb, struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr, unsigned long end, pgprot_t newprot, unsigned long cp_flags) { - pte_t *pte, oldpte; + hw_pte_t *pte; + pte_t oldpte; spinlock_t *ptl; long pages = 0; bool is_private_single_threaded; @@ -727,7 +728,7 @@ long change_protection(struct mmu_gather *tlb, return pages; } -static int prot_none_pte_entry(pte_t *pte, unsigned long addr, +static int prot_none_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { return pfn_modify_allowed(pte_pfn(ptep_get(pte)), @@ -736,7 +737,7 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr, } #ifdef CONFIG_HUGETLB_PAGE -static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask, +static int prot_none_hugetlb_entry(hw_pte_t *pte, unsigned long hmask, unsigned long addr, unsigned long next, struct mm_walk *walk) { diff --git a/mm/mremap.c b/mm/mremap.c index 7c368440fafe2..5272cea12f80e 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -176,7 +176,7 @@ static pte_t move_soft_dirty_pte(pte_t pte) } static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned long addr, - pte_t *ptep, pte_t pte, int max_nr) + hw_pte_t *ptep, pte_t pte, int max_nr) { struct folio *folio; @@ -200,7 +200,7 @@ static int move_ptes(struct pagetable_move_control *pmc, struct vm_area_struct *vma = pmc->old; bool need_clear_uffd_wp = vma_has_uffd_without_event_remap(vma); struct mm_struct *mm = vma->vm_mm; - pte_t *old_ptep, *new_ptep; + hw_pte_t *old_ptep, *new_ptep; pte_t old_pte, pte; pmd_t dummy_pmdval; spinlock_t *old_ptl, *new_ptl; diff --git a/mm/page_table_check.c b/mm/page_table_check.c index 143a918c0bde2..705794a817bad 100644 --- a/mm/page_table_check.c +++ b/mm/page_table_check.c @@ -208,7 +208,7 @@ static void page_table_check_pte_flags(pte_t pte) } void __page_table_check_ptes_set(struct mm_struct *mm, unsigned long addr, - pte_t *ptep, pte_t pte, unsigned int nr) + hw_pte_t *ptep, pte_t pte, unsigned int nr) { unsigned int i; @@ -279,7 +279,7 @@ void __page_table_check_pte_clear_range(struct mm_struct *mm, return; if (!pmd_none(pmd) && !pmd_bad(pmd) && !pmd_leaf(pmd)) { - pte_t *ptep = pte_offset_map(&pmd, addr); + hw_pte_t *ptep = pte_offset_map(&pmd, addr); unsigned long i; if (WARN_ON(!ptep)) diff --git a/mm/pagewalk.c b/mm/pagewalk.c index 7411702a37f58..b6a29a06a19bc 100644 --- a/mm/pagewalk.c +++ b/mm/pagewalk.c @@ -26,7 +26,7 @@ static int real_depth(int depth) return depth; } -static int walk_pte_range_inner(pte_t *pte, unsigned long addr, +static int walk_pte_range_inner(hw_pte_t *pte, unsigned long addr, unsigned long end, struct mm_walk *walk) { const struct mm_walk_ops *ops = walk->ops; @@ -61,7 +61,7 @@ static int walk_pte_range_inner(pte_t *pte, unsigned long addr, static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, struct mm_walk *walk) { - pte_t *pte; + hw_pte_t *pte; int err = 0; spinlock_t *ptl; @@ -341,7 +341,7 @@ static int walk_hugetlb_range(unsigned long addr, unsigned long end, unsigned long next; unsigned long hmask = huge_page_mask(h); unsigned long sz = huge_page_size(h); - pte_t *pte; + hw_pte_t *pte; const struct mm_walk_ops *ops = walk->ops; int err = 0; @@ -905,7 +905,8 @@ struct folio *folio_walk_start(struct folio_walk *fw, struct page *page; pud_t *pudp, pud; pmd_t *pmdp, pmd; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; spinlock_t *ptl; pgd_t *pgdp; p4d_t *p4dp; diff --git a/mm/percpu.c b/mm/percpu.c index 47a903fe3b512..197a786e1c5cf 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -3176,7 +3176,7 @@ void __init __weak pcpu_populate_pte(unsigned long addr) pmd = pmd_offset(pud, addr); if (!pmd_present(*pmd)) { - pte_t *new; + hw_pte_t *new; new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE); pmd_populate_kernel(&init_mm, pmd, new); diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c index 224c444cf45d9..df548ad3d9a54 100644 --- a/mm/pgtable-generic.c +++ b/mm/pgtable-generic.c @@ -80,7 +80,7 @@ void pmd_clear_bad(pmd_t *pmd) * force that call on sun4c so we changed this macro slightly */ int ptep_set_access_flags(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep, + unsigned long address, hw_pte_t *ptep, pte_t entry, int dirty) { int changed = !pte_same(ptep_get(ptep), entry); @@ -94,7 +94,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma, #ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH bool ptep_clear_flush_young(struct vm_area_struct *vma, - unsigned long address, pte_t *ptep) + unsigned long address, hw_pte_t *ptep) { bool young; @@ -107,7 +107,7 @@ bool ptep_clear_flush_young(struct vm_area_struct *vma, #ifndef __HAVE_ARCH_PTEP_CLEAR_FLUSH pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address, - pte_t *ptep) + hw_pte_t *ptep) { struct mm_struct *mm = (vma)->vm_mm; pte_t pte; @@ -294,7 +294,7 @@ static unsigned long pmdp_get_lockless_start(void) { return 0; } static void pmdp_get_lockless_end(unsigned long irqflags) { } #endif -pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) +hw_pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) { unsigned long irqflags; pmd_t pmdval; @@ -320,11 +320,11 @@ pte_t *__pte_offset_map(pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp) return NULL; } -pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, spinlock_t **ptlp) { pmd_t pmdval; - pte_t *pte; + hw_pte_t *pte; pte = __pte_offset_map(pmd, addr, &pmdval); if (likely(pte)) @@ -332,11 +332,11 @@ pte_t *pte_offset_map_ro_nolock(struct mm_struct *mm, pmd_t *pmd, return pte; } -pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, pmd_t *pmdvalp, spinlock_t **ptlp) { - pte_t *pte; + hw_pte_t *pte; VM_WARN_ON_ONCE(!pmdvalp); pte = __pte_offset_map(pmd, addr, pmdvalp); @@ -402,12 +402,12 @@ pte_t *pte_offset_map_rw_nolock(struct mm_struct *mm, pmd_t *pmd, * table, and may not use RCU at all: "outsiders" like khugepaged should avoid * pte_offset_map() and co once the vma is detached from mm or mm_users is zero. */ -pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd, +hw_pte_t *pte_offset_map_lock(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, spinlock_t **ptlp) { spinlock_t *ptl; pmd_t pmdval; - pte_t *pte; + hw_pte_t *pte; again: pte = __pte_offset_map(pmd, addr, &pmdval); if (unlikely(!pte)) diff --git a/mm/ptdump.c b/mm/ptdump.c index 5851096e6f656..376880071ca2a 100644 --- a/mm/ptdump.c +++ b/mm/ptdump.c @@ -117,7 +117,7 @@ static int ptdump_pmd_entry(pmd_t *pmd, unsigned long addr, return 0; } -static int ptdump_pte_entry(pte_t *pte, unsigned long addr, +static int ptdump_pte_entry(hw_pte_t *pte, unsigned long addr, unsigned long next, struct mm_walk *walk) { struct ptdump_state *st = walk->private; diff --git a/mm/rmap.c b/mm/rmap.c index b5cc9273fe5a4..0223c4ab0b361 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1122,7 +1122,7 @@ static int page_vma_mkclean_one(struct page_vma_mapped_walk *pvmw) address = pvmw->address; if (pvmw->pte) { - pte_t *pte = pvmw->pte; + hw_pte_t *pte = pvmw->pte; pte_t entry = ptep_get(pte); /* @@ -2139,7 +2139,7 @@ static pte_t swp_pte_prepare(swp_entry_t entry, pte_t old_pte, static bool ttu_anon_swapbacked_folio(struct vm_area_struct *vma, struct folio *folio, struct page *page, unsigned long address, - pte_t *ptep, pte_t pteval) + hw_pte_t *ptep, pte_t pteval) { const bool anon_exclusive = folio_test_anon(folio) && PageAnonExclusive(page); @@ -2174,7 +2174,7 @@ static bool ttu_anon_swapbacked_folio(struct vm_area_struct *vma, } static bool ttu_anon_folio(struct vm_area_struct *vma, struct folio *folio, - struct page *page, unsigned long address, pte_t *ptep, + struct page *page, unsigned long address, hw_pte_t *ptep, pte_t pteval, unsigned long nr_pages) { /* diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index e62e6aa07f126..77eb1749e123f 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -135,7 +135,7 @@ static void * __meminit altmap_alloc_block_buf(unsigned long size, return __va(__pfn_to_phys(pfn)); } -void __meminit vmemmap_verify(pte_t *pte, int node, +void __meminit vmemmap_verify(hw_pte_t *pte, int node, unsigned long start, unsigned long end) { unsigned long pfn = pte_pfn(ptep_get(pte)); @@ -236,11 +236,11 @@ static __meminit void *vmemmap_alloc_pte(unsigned long pfn, int node, return page_address(page); } -static pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node, +static hw_pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node, struct vmem_altmap *altmap, unsigned long ptpfn, unsigned long flags) { - pte_t *pte = pte_offset_kernel(pmd, addr); + hw_pte_t *pte = pte_offset_kernel(pmd, addr); unsigned long pfn = page_to_pfn((struct page *)addr); if (pte_none(ptep_get(pte))) { @@ -323,7 +323,7 @@ static pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node) return pgd; } -static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, +static hw_pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, struct vmem_altmap *altmap, unsigned long ptpfn, unsigned long flags) @@ -332,7 +332,7 @@ static pte_t * __meminit vmemmap_populate_address(unsigned long addr, int node, p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *pte; + hw_pte_t *pte; pgd = vmemmap_pgd_populate(addr, node); if (!pgd) @@ -361,7 +361,7 @@ static int __meminit vmemmap_populate_range(unsigned long start, unsigned long flags) { unsigned long addr = start; - pte_t *pte; + hw_pte_t *pte; for (; addr < end; addr += PAGE_SIZE) { pte = vmemmap_populate_address(addr, node, altmap, @@ -394,7 +394,7 @@ void vmemmap_wrprotect_hvo(unsigned long addr, unsigned long end, int node, unsigned long headsize) { unsigned long maddr; - pte_t *pte; + hw_pte_t *pte; for (maddr = addr + headsize; maddr < end; maddr += PAGE_SIZE) { pte = virt_to_kpte(maddr); @@ -413,7 +413,7 @@ int __weak __meminit vmemmap_check_pmd(pmd_t *pmd, int node, { if (!pmd_leaf(pmdp_get(pmd))) return 0; - vmemmap_verify((pte_t *)pmd, node, addr, next); + vmemmap_verify((hw_pte_t *)pmd, node, addr, next); return 1; } @@ -497,9 +497,9 @@ static bool __meminit reuse_compound_section(unsigned long start_pfn, return !IS_ALIGNED(offset, nr_pages) && nr_pages > PAGES_PER_SUBSECTION; } -static pte_t * __meminit compound_section_tail_page(unsigned long addr) +static hw_pte_t * __meminit compound_section_tail_page(unsigned long addr) { - pte_t *pte; + hw_pte_t *pte; addr -= PAGE_SIZE; @@ -520,7 +520,7 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn, struct dev_pagemap *pgmap) { unsigned long size, addr; - pte_t *pte; + hw_pte_t *pte; int rc; if (reuse_compound_section(start_pfn, pgmap)) { diff --git a/mm/swap_state.c b/mm/swap_state.c index 305877e1f4d7b..d654449f393e8 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -918,7 +918,8 @@ static struct folio *swap_vma_readahead(swp_entry_t targ_entry, gfp_t gfp_mask, struct swap_io_ctx ctx = {}; struct blk_plug plug; struct folio *folio; - pte_t *pte = NULL, pentry; + hw_pte_t *pte = NULL; + pte_t pentry; int win; unsigned long start, end, addr; pgoff_t ilx = targ_ilx; diff --git a/mm/swapfile.c b/mm/swapfile.c index 869a918b18e8e..2f6aa8dc2f5bb 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -2500,7 +2500,8 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, struct page *page; struct folio *swapcache; spinlock_t *ptl; - pte_t *pte, new_pte, old_pte; + hw_pte_t *pte; + pte_t new_pte, old_pte; bool hwpoisoned = false; int ret = 1; @@ -2611,7 +2612,7 @@ static int unuse_pte_range(struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr, unsigned long end, unsigned int type) { - pte_t *pte = NULL; + hw_pte_t *pte = NULL; do { struct folio *folio; diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 79cc7b546f130..8281796638c0a 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -334,13 +334,13 @@ static int mfill_atomic_install_pte(pmd_t *dst_pmd, { int ret; struct mm_struct *dst_mm = dst_vma->vm_mm; - pte_t _dst_pte, *dst_pte; + hw_pte_t *dst_pte; bool writable = dst_vma->vm_flags & VM_WRITE; bool vm_shared = dst_vma->vm_flags & VM_SHARED; spinlock_t *ptl; struct folio *folio = page_folio(page); bool page_in_cache = folio_mapping(folio); - pte_t dst_ptep; + pte_t _dst_pte, dst_ptep; _dst_pte = mk_pte(page, dst_vma->vm_page_prot); _dst_pte = pte_mkdirty(_dst_pte); @@ -629,7 +629,8 @@ static int mfill_atomic_pte_zeropage(struct mfill_state *state) struct vm_area_struct *dst_vma = state->vma; unsigned long dst_addr = state->dst_addr; pmd_t *dst_pmd = state->pmd; - pte_t _dst_pte, *dst_pte; + hw_pte_t *dst_pte; + pte_t _dst_pte; spinlock_t *ptl; int ret; @@ -710,7 +711,8 @@ static int mfill_atomic_pte_poison(struct mfill_state *state) struct mm_struct *dst_mm = dst_vma->vm_mm; unsigned long dst_addr = state->dst_addr; pmd_t *dst_pmd = state->pmd; - pte_t _dst_pte, *dst_pte; + hw_pte_t *dst_pte; + pte_t _dst_pte; spinlock_t *ptl; int ret; @@ -757,7 +759,7 @@ static __always_inline ssize_t mfill_atomic_hugetlb( { struct mm_struct *dst_mm = dst_vma->vm_mm; ssize_t err; - pte_t *dst_pte; + hw_pte_t *dst_pte; unsigned long src_addr, dst_addr; long copied; struct folio *folio; @@ -1234,7 +1236,7 @@ void double_pt_unlock(spinlock_t *ptl1, __release(ptl2); } -static inline bool is_pte_pages_stable(pte_t *dst_pte, pte_t *src_pte, +static inline bool is_pte_pages_stable(hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval) { @@ -1252,7 +1254,8 @@ static inline bool is_pte_pages_stable(pte_t *dst_pte, pte_t *src_pte, */ static struct folio *check_ptes_for_batched_move(struct vm_area_struct *src_vma, unsigned long src_addr, - pte_t *src_pte, pte_t *dst_pte) + hw_pte_t *src_pte, + hw_pte_t *dst_pte) { pte_t orig_dst_pte, orig_src_pte; struct folio *folio; @@ -1283,7 +1286,7 @@ static long move_present_ptes(struct mm_struct *mm, struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, unsigned long dst_addr, unsigned long src_addr, - pte_t *dst_pte, pte_t *src_pte, + hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl, @@ -1370,7 +1373,7 @@ static long move_present_ptes(struct mm_struct *mm, static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, unsigned long dst_addr, unsigned long src_addr, - pte_t *dst_pte, pte_t *src_pte, + hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl, @@ -1435,7 +1438,7 @@ static int move_zeropage_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma, unsigned long dst_addr, unsigned long src_addr, - pte_t *dst_pte, pte_t *src_pte, + hw_pte_t *dst_pte, hw_pte_t *src_pte, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl) @@ -1481,8 +1484,8 @@ static long move_pages_ptes(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd pte_t orig_src_pte, orig_dst_pte; pte_t src_folio_pte; spinlock_t *src_ptl, *dst_ptl; - pte_t *src_pte = NULL; - pte_t *dst_pte = NULL; + hw_pte_t *src_pte = NULL; + hw_pte_t *dst_pte = NULL; pmd_t dummy_pmdval; pmd_t dst_pmdval; struct folio *src_folio = NULL; @@ -2597,7 +2600,8 @@ static inline bool userfaultfd_huge_must_wait(struct userfaultfd_ctx *ctx, unsigned long reason) { struct vm_area_struct *vma = vmf->vma; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; assert_fault_locked(vmf); @@ -2670,7 +2674,7 @@ static inline bool userfaultfd_must_wait(struct userfaultfd_ctx *ctx, p4d_t *p4d; pud_t *pud; pmd_t *pmd, _pmd; - pte_t *pte; + hw_pte_t *pte; pte_t ptent; bool ret; diff --git a/mm/util.c b/mm/util.c index bf0513d1d3d08..cc253050f6892 100644 --- a/mm/util.c +++ b/mm/util.c @@ -1564,7 +1564,7 @@ EXPORT_SYMBOL(mmap_action_complete); * * Return: the number of table entries in the batch. */ -unsigned int folio_pte_batch(struct folio *folio, pte_t *ptep, pte_t pte, +unsigned int folio_pte_batch(struct folio *folio, hw_pte_t *ptep, pte_t pte, unsigned int max_nr) { return folio_pte_batch_flags(folio, NULL, ptep, &pte, max_nr, 0); diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 6ed6c160abed7..60ba46838bbeb 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -97,7 +97,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, phys_addr_t phys_addr, pgprot_t prot, unsigned int max_page_shift, pgtbl_mod_mask *mask) { - pte_t *pte; + hw_pte_t *pte; u64 pfn; struct page *page; unsigned long size = PAGE_SIZE; @@ -389,7 +389,7 @@ int ioremap_page_range(unsigned long addr, unsigned long end, static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end, pgtbl_mod_mask *mask) { - pte_t *pte; + hw_pte_t *pte; pte_t ptent; unsigned long size = PAGE_SIZE; @@ -550,7 +550,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr, pgtbl_mod_mask *mask) { int err = 0; - pte_t *pte; + hw_pte_t *pte; /* * nr is a running index into the array which helps higher level @@ -827,7 +827,8 @@ struct page *vmalloc_to_page(const void *vmalloc_addr) p4d_t *p4d; pud_t *pud; pmd_t *pmd; - pte_t *ptep, pte; + hw_pte_t *ptep; + pte_t pte; /* * XXX we might need to change this if we add VIRTUAL_BUG_ON for @@ -3615,7 +3616,7 @@ struct vmap_pfn_data { unsigned int idx; }; -static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) +static int vmap_pfn_apply(hw_pte_t *pte, unsigned long addr, void *private) { struct vmap_pfn_data *data = private; unsigned long pfn = data->pfns[data->idx]; diff --git a/mm/vmscan.c b/mm/vmscan.c index 07ba86634b840..5f0ac5f647425 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3553,7 +3553,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end, { int i; bool dirty; - pte_t *pte; + hw_pte_t *pte; spinlock_t *ptl; unsigned long addr; int total = 0; @@ -3584,7 +3584,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end, for (i = pte_index(start), addr = start; addr != end; i += nr, addr += nr * PAGE_SIZE) { unsigned long pfn; struct folio *folio; - pte_t *cur_pte = pte + i; + hw_pte_t *cur_pte = pte + i; pte_t ptent = ptep_get(cur_pte); nr = 1; @@ -4271,7 +4271,7 @@ bool lru_gen_look_around(struct page_vma_mapped_walk *pvmw, unsigned int nr) struct lru_gen_mm_walk *walk; struct folio *last = NULL; int young = nr; - pte_t *pte = pvmw->pte; + hw_pte_t *pte = pvmw->pte; unsigned long addr = pvmw->address; struct vm_area_struct *vma = pvmw->vma; struct folio *folio = pfn_folio(pvmw->pfn); -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429298.1652220 (Exim 4.92) (envelope-from ) id 1x94ml-0004pG-Ua; Tue, 22 Sep 2026 18:00:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429298.1652220; Tue, 22 Sep 2026 18:00:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94ml-0004nF-Li; Tue, 22 Sep 2026 18:00:07 +0000 Received: by outflank-mailman (input) for mailman id 1429298; Tue, 22 Sep 2026 17:14:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x944C-0005Jw-5W for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:14:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x944B-00Ae5e-Io for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:14:03 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b740-8faa-0a2a0a5109dd-0a2a450bd518-26 for ; Tue, 22 Sep 2026 19:14:03 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b71e-b7e8-0a2a450b0019-d98c6eac9244-1 for ; Tue, 22 Sep 2026 19:13:03 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7A82B1576; Tue, 22 Sep 2026 10:12:58 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 153903F86C; Tue, 22 Sep 2026 10:12:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Subject:Date:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097182; bh=6fGlC+l7ZOTUAPb0qf6/jbMAeDqXx74X21kDAUYsIyk=; h=From:Subject:Date:To:Cc:From; b=HIIxexScPs77FEWrL1zKfh489AcYGH+eosy1rJu4q8Qx0Y5qygcZGRibDPK9zayy2 bMswKnuZyeg7Xdl5EiA/OMueeXhZkIg42q52ZYMsGuSW+3VibDu/Td+mjExBEv2p1H 6o6egoaJbq6J6Irg6+9TyJTuwzBdadX5XN/qqY9E= From: Muhammad Usama Anjum Subject: [PATCH v3 0/9] mm: distinguish HW PTE pointers from SW PTE value pointers Date: Tue, 22 Sep 2026 18:12:28 +0100 Message-Id: <20260922-pte0-v3-0-5670b8cb9059@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAPy2smoC/y2NwQ6DIBAFf8XsuZgFqxVP/Y/GA8W1YoIaENPG+ O8F2+Mk8+bt4MkZ8tBkOzjajDfzFKG4ZKAHNb2ImS4yCBQVSn5ly0rIKl3XfVlK0d0kRHVx1Jv 3mXm0P/bhOZJe0zYZg/Hr7D7nzyaS909iwbFAFDmP+bqUjLPglVW5msZg78rZXM8W2uM4vgCpy qqtAAAA X-Change-ID: 20260914-pte0-6c88f5592d79 To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-42698a/1790097183-A9CC79EA-E1E000CA/13/0 X-purgate-type: bulk X-purgate-size: 18715 Hi, pte_t currently describes both a software PTE value and an element stored in a PTE table. Consequently, pte_t * can point either to a software PTE value, often a stack copy, or to a PTE-table slot. The compiler cannot distinguish these cases. A value pointer can therefore be passed to an interface that expects table storage, while table storage can be read by direct dereference instead of the architecture accessor. This series begins a staged conversion at the PTE level. It introduces hw_pte_t as the element type for PTE-table storage and converts generic MM to use hw_pte_t *. Software PTE values remain pte_t. Interfaces that intentionally return a value through pte_t *, such as install_pte, remain value interfaces; the relevant parameters are named ptentp to make that distinction explicit. The generic definition aliases hw_pte_t to pte_t unless an architecture selects ARCH_HAS_HW_PTE_T, which enables a distinct generic wrapper named __hw_pte_t. Some architectures define pgtable_t in headers parsed before the generic hw_pte_t typedef is visible. The structure tag allows those headers to define pgtable_t as struct __hw_pte_t * without creating an include-order dependency. This is required when converting s390, m68k, powerpc and sparc. No architecture selects ARCH_HAS_HW_PTE_T in this series, so the representation and behavior of every architecture are preserved. ptep_get() keeps its existing READ_ONCE() semantics and converts the stored element through __pte_from_hw(). An architecture can later select the option and convert its PTE interfaces to make the distinction compiler-enforced. Architecture PTE implementations and most architecture code are deliberately left for those later opt-in conversions. Here, hw_pte_t identifies PTE-table storage rather than table lifetime: complete PTE tables use hw_pte_t whether or not they are currently linked into a page-table hierarchy, while software PTE values use pte_t. The distinction between complete but unlinked tables and hardware-reachable tables was raised during discussion and remains an important point for review. PMD, PUD, P4D and PGD storage are deliberately out of scope. They can be converted in later series after the PTE boundary is agreed, avoiding the PMD-specific cases that made an all-level conversion difficult to review. Most mechanical pointer conversions were generated with the Coccinelle script included below, then audited and fixed by hand. This series does not add a second ptep_get_once() accessor and does not remove or replace STRICT_MM_TYPECHECKS. The design discussion is available at [1]; while the original idea came from [2]. I've the patches here [3] for arm64 conversion which I used to find usages in generic code which I missed during development. [1] https://lore.kernel.org/all/6110202c-057b-4701-8c04-1a76ee7bb9ab@arm.com/ [2] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com [3] https://lore.kernel.org/all/20260914-pte0_arm-v1-0-bb53b663e396@arm.com Testing: Testing was performed with and without the series on both x86_64 and arm64. KUnit and the MM kselftests produced matching before-and-after results problems or regressions. Fastpath performance testing was also completed on arm64. No regression was found. Thanks, Usama --- Changes in v3: - Retitle the series - Moved hw_pte_val() adding helper to generic series - Link to v2: https://patch.msgid.link/20260903103002.1091859-1-usama.anjum@arm.com Changes in v2: - Name the generic wrapper structure __hw_pte_t so architectures can forward-declare it before the generic typedef is visible. - Use software PTE value terminology consistently - Fold the prerequisite header includes into the generic storage conversion - Explain why the NOMMU stub converts the stored entry without ptep_get(). - Rebase onto mm-new and rerun the Coccinelle conversion. - Link to v1: https://lore.kernel.org/all/20260806083926.1807279-1-usama.anjum@arm.com Changes in v1: - Add ARCH_HAS_HW_PTE_T so architectures can opt in to a distinct PTE-table storage type. - Define the distinct hw_pte_t wrapper and its conversion helpers in generic code instead of requiring each architecture to define them. - Read hw_pte_t through READ_ONCE() before converting it to pte_t. - Drop the previous mremap patch in favour of [a]. Apply [a] first if it is not already present. - Drop the previous two dead-code conversion patches; the affected code was cleaned up separately in [b] and [c]. - Link to RFC: https://lore.kernel.org/all/20260727164715.2866609-1-usama.anjum@arm.com [a] https://lore.kernel.org/linux-mm/20260720141633.501799-1-agordeev@linux.ibm.com/ [b] https://lore.kernel.org/all/20260730111316.3672672-1-usama.anjum@arm.com [c] https://lore.kernel.org/all/20260730094501.3002718-1-usama.anjum@arm.com --- // SPDX-License-Identifier: GPL-2.0-only /// /// Rename raw PTE pointer types to hardware PTE pointer types. /// /// This is a mechanical type rename. It converts common declarations, /// function parameters, prototypes, return types and casts from "pte_t *" /// to "hw_pte_t *". Plain "pte_t" objects are intentionally left unchanged. /// Pointers named "ptentp" refer to temporary software PTE values and are /// intentionally ignored in all modes. /// Re-run in context mode afterwards to audit remaining raw pte_t pointers /// and cases that need hand conversion, such as trace macros and mixed /// declarations. /// /// Confidence: Moderate // Options: --no-includes --include-headers virtual patch virtual report virtual context @local_decl depends on patch@ identifier x != ptentp; @@ - pte_t *x; + hw_pte_t *x; @local_decl_init depends on patch@ identifier x != ptentp; expression e; @@ - pte_t *x = e; + hw_pte_t *x = e; @param_proto depends on patch@ identifier f; identifier x != ptentp; type R; @@ R f(..., - pte_t *x + hw_pte_t *x ,...); @param_proto_unnamed depends on patch@ identifier f; type R; @@ R f(..., - pte_t * + hw_pte_t * ,...); @param_def depends on patch@ identifier f; identifier x != ptentp; type R; @@ R f(..., - pte_t *x + hw_pte_t *x ,...) { ... } @ret_proto depends on patch@ identifier f; parameter list ps; @@ - pte_t * + hw_pte_t * f(ps); @ret_def depends on patch@ identifier f; parameter list ps; @@ - pte_t * + hw_pte_t * f(ps) { ... } @struct_member depends on patch@ identifier S; identifier x != ptentp; @@ struct S { ... - pte_t *x; + hw_pte_t *x; ... }; @union_member depends on patch@ identifier x != ptentp; @@ union { ... - pte_t *x; + hw_pte_t *x; ... }; @union_member_in_struct depends on patch@ identifier S; identifier x != ptentp; @@ struct S { ... union { ... - pte_t *x; + hw_pte_t *x; ... }; ... }; @fnptr_struct_member depends on patch@ identifier S,f; identifier x != ptentp; type R; @@ struct S { ... R (*f)(..., - pte_t *x + hw_pte_t *x ,...); ... }; @fnptr_typedef_pte_fn_t depends on patch@ identifier x != ptentp; @@ typedef int (*pte_fn_t)(..., - pte_t *x + hw_pte_t *x ,...); @cast depends on patch@ expression e; @@ - (pte_t *)e + (hw_pte_t *)e @remaining_decl depends on context || report@ identifier x != ptentp; position p; @@ * pte_t *x@p; @remaining_decl_init depends on context || report@ identifier x != ptentp; expression e; position p; @@ * pte_t *x@p = e; @remaining_param_proto depends on context || report@ identifier f; identifier x != ptentp; type R; position p; @@ R f(..., * pte_t *x@p ,...); @remaining_param_proto_unnamed depends on context || report@ identifier f; type R; position p; @@ R f(..., * pte_t *@p ,...); @remaining_param_def depends on context || report@ identifier f; identifier x != ptentp; type R; position p; @@ R f(..., * pte_t *x@p ,...) { ... } @remaining_ret_proto depends on context || report@ identifier f; parameter list ps; position p; @@ * pte_t *f@p(ps); @remaining_ret_def depends on context || report@ identifier f; parameter list ps; position p; @@ * pte_t *f@p(ps) { ... } @remaining_struct_member depends on context || report@ identifier S; identifier x != ptentp; position p; @@ struct S { ... * pte_t *x@p; ... }; @remaining_union_member depends on context || report@ identifier x != ptentp; position p; @@ union { ... * pte_t *x@p; ... }; @remaining_union_member_in_struct depends on context || report@ identifier S; identifier x != ptentp; position p; @@ struct S { ... union { ... * pte_t *x@p; ... }; ... }; @remaining_fnptr_struct_member depends on context || report@ identifier S,f; identifier x != ptentp; type R; position p; @@ struct S { ... R (*f)(..., * pte_t *x@p ,...); ... }; @remaining_fnptr_typedef_pte_fn_t depends on context || report@ identifier x != ptentp; position p; @@ typedef int (*pte_fn_t)(..., * pte_t *x@p ,...); --- To: Andrew Morton To: David Hildenbrand To: Lorenzo Stoakes To: "Liam R. Howlett" To: Vlastimil Babka To: Mike Rapoport To: Suren Baghdasaryan To: Michal Hocko To: Xu Xin To: Chengming Zhou To: Jann Horn To: Muchun Song To: Oscar Salvador To: Pedro Falcato To: Arnd Bergmann To: Will Deacon To: "Aneesh Kumar K.V" To: Nick Piggin To: Peter Zijlstra To: Pasha Tatashin To: Rik van Riel To: Harry Yoo To: Lance Yang To: Chris Li To: Kairui Song To: Kemeng Shi To: Nhat Pham To: Baoquan He To: Barry Song To: Youngjun Park To: Uladzislau Rezki To: Steven Rostedt To: Masami Hiramatsu To: Mathieu Desnoyers To: Alexei Starovoitov To: Daniel Borkmann To: Andrii Nakryiko To: Eduard Zingerman To: Kumar Kartikeya Dwivedi To: Martin KaFai Lau To: Song Liu To: Yonghong Song To: Jiri Olsa To: Emil Tsalapatis To: Ihor Solodrai To: Ingo Molnar To: Arnaldo Carvalho de Melo To: Namhyung Kim To: Mark Rutland To: Alexander Shishkin To: Ian Rogers To: Adrian Hunter To: James Clark To: SJ Park To: "Matthew Wilcox (Oracle)" To: Jan Kara To: Jason Gunthorpe To: John Hubbard To: Peter Xu To: Leon Romanovsky To: Zi Yan To: Baolin Wang To: Nico Pache To: Ryan Roberts To: Dev Jain To: Usama Arif To: Kiryl Shutsemau To: Andrey Ryabinin To: Alexander Potapenko To: Andrey Konovalov To: Dmitry Vyukov To: Vincenzo Frascino To: Miaohe Lin To: Naoya Horiguchi To: Matthew Brost To: Joshua Hahn To: Rakie Kim To: Byungchul Park To: Gregory Price To: Ying Huang To: Alistair Popple To: Dennis Zhou To: Tejun Heo To: Christoph Lameter To: Johannes Weiner To: Qi Zheng To: Shakeel Butt To: Axel Rasmussen To: Yuanchu Xie To: Wei Xu To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: David Airlie To: Simona Vetter To: Juergen Gross To: Stefano Stabellini To: Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-trace-kernel@vger.kernel.org Cc: bpf@vger.kernel.org Cc: linux-perf-users@vger.kernel.org Cc: damon@lists.linux.dev Cc: kasan-dev@googlegroups.com Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: xen-devel@lists.xenproject.org Signed-off-by: Muhammad Usama Anjum --- Muhammad Usama Anjum (9): mm: introduce hw_pte_t for PTE table storage mm: rename pointers to software PTE values as ptentp mm: use hw_pte_t for generic PTE table storage mm: convert PTE table entries in ptep_get() mm: convert PTE table entry to pte mm: add hw_pte_val for HW PTE storage mm/kasan: use hw_pte_t for the early shadow PTE table drm/i915: use hw_pte_t for PTE range callbacks xen: use hw_pte_t for PTE range callbacks MAINTAINERS | 1 + drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 4 +-- drivers/gpu/drm/i915/i915_mm.c | 4 +-- drivers/xen/gntdev.c | 2 +- drivers/xen/privcmd.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 2 +- drivers/xen/xlate_mmu.c | 4 +-- fs/hugetlbfs/inode.c | 3 +- fs/proc/task_mmu.c | 33 ++++++++++---------- include/asm-generic/hugetlb.h | 15 ++++----- include/asm-generic/pgalloc.h | 6 ++-- include/asm-generic/tlb.h | 5 +-- include/linux/hugetlb.h | 53 +++++++++++++++++-------------- include/linux/kasan.h | 2 +- include/linux/mm.h | 26 ++++++++-------- include/linux/page_table_check.h | 10 ++++-- include/linux/pagewalk.h | 10 +++--- include/linux/pgtable.h | 81 +++++++++++++++++++++++++----------------------- include/linux/pgtable_types.h | 23 ++++++++++++++ include/linux/rmap.h | 2 +- include/linux/swapops.h | 6 ++-- include/linux/vmalloc.h | 4 +-- include/trace/events/xen.h | 10 +++--- kernel/bpf/arena.c | 9 +++--- kernel/events/core.c | 3 +- mm/Kconfig | 3 ++ mm/damon/ops-common.c | 2 +- mm/damon/ops-common.h | 2 +- mm/damon/vaddr.c | 20 ++++++------ mm/debug_vm_pgtable.c | 2 +- mm/filemap.c | 4 +-- mm/gup.c | 9 +++--- mm/highmem.c | 15 ++++----- mm/hmm.c | 6 ++-- mm/huge_memory.c | 4 +-- mm/hugetlb.c | 60 ++++++++++++++++++----------------- mm/hugetlb_vmemmap.c | 13 ++++---- mm/internal.h | 16 +++++----- mm/kasan/init.c | 14 ++++----- mm/kasan/shadow.c | 6 ++-- mm/khugepaged.c | 50 ++++++++++++++++++------------ mm/ksm.c | 11 ++++--- mm/madvise.c | 18 ++++++----- mm/mapping_dirty_helpers.c | 4 +-- mm/memory-failure.c | 6 ++-- mm/memory.c | 78 +++++++++++++++++++++++----------------------- mm/mempolicy.c | 4 +-- mm/migrate.c | 4 +-- mm/migrate_device.c | 4 +-- mm/mincore.c | 4 +-- mm/mlock.c | 4 +-- mm/mprotect.c | 19 ++++++------ mm/mremap.c | 4 +-- mm/page_table_check.c | 4 +-- mm/pagewalk.c | 9 +++--- mm/percpu.c | 2 +- mm/pgtable-generic.c | 20 ++++++------ mm/ptdump.c | 4 +-- mm/rmap.c | 6 ++-- mm/sparse-vmemmap.c | 22 ++++++------- mm/swap_state.c | 3 +- mm/swapfile.c | 5 +-- mm/userfaultfd.c | 32 ++++++++++--------- mm/util.c | 2 +- mm/vmalloc.c | 11 ++++--- mm/vmscan.c | 6 ++-- 66 files changed, 457 insertions(+), 375 deletions(-) --- base-commit: ead700ca770c82167af32622cf8b68c9f87c3c7c change-id: 20260914-pte0-6c88f5592d79 Best regards, -- Usama From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429308.1652255 (Exim 4.92) (envelope-from ) id 1x94mo-0005Yu-0V; Tue, 22 Sep 2026 18:00:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429308.1652255; Tue, 22 Sep 2026 18:00:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94mn-0005WF-Md; Tue, 22 Sep 2026 18:00:09 +0000 Received: by outflank-mailman (input) for mailman id 1429308; Tue, 22 Sep 2026 17:15:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x945A-0005Qz-IB for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:15:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9459-00AeFB-VE for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:15:03 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b77c-8faa-0a2a0a5109dd-0a2a4502cc04-42 for ; Tue, 22 Sep 2026 19:15:03 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-720697.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b796-6ca4-0a2a45020019-d98c6eac8cc4-1 for ; Tue, 22 Sep 2026 19:15:03 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C71EE1595; Tue, 22 Sep 2026 10:14:58 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 056A83F86C; Tue, 22 Sep 2026 10:14:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097302; bh=S1+moWK8WUqQqBwq12CGGS95zxJn4CEiSQR2ZbgzAjA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=I3OhF8wvoUdplYbIAxprYhaliSqNizYMQQKPtaoeJ91myAacTy8wDEGp9P9Hk+JYc Cxti/txw6TGw66MJUNH7dnKqLXhJcsVRV8TfIQ9DU6Lzstr1QT53ZIGBG3xPD9QBrO 98HXGpHEpdXb5XLelYBAp6ylu9J64MVVJelAF18I= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:37 +0100 Subject: [PATCH v3 9/9] xen: use hw_pte_t for PTE range callbacks MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-9-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-720697/1790097303-668B42AC-7CBD72FD/0/0 X-purgate-type: clean X-purgate-size: 3396 Generic PTE range and remapping helpers now pass pointers to PTE table storage as hw_pte_t *. Update the Xen callbacks to match those interfaces. Keep software PTE values as pte_t and continue to access them through the existing PTE helpers. This is required when Xen is built for an architecture that selects the distinct hw_pte_t wrapper. Reviewed-by: Juergen Gross Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Use software PTE value terminology. Changes since RFC v1: - Clarify why the callback conversion is required after architecture opt-in. --- drivers/xen/gntdev.c | 2 +- drivers/xen/privcmd.c | 2 +- drivers/xen/xenbus/xenbus_client.c | 2 +- drivers/xen/xlate_mmu.c | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 1dcc4675580ed..b013bcad99b5b 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -301,7 +301,7 @@ void gntdev_put_map(struct gntdev_priv *priv, struct gntdev_grant_map *map) /* ------------------------------------------------------------------ */ -static int find_grant_ptes(pte_t *pte, unsigned long addr, void *data) +static int find_grant_ptes(hw_pte_t *pte, unsigned long addr, void *data) { struct gntdev_grant_map *map = data; unsigned int pgnr = (addr - map->pages_vm_start) >> PAGE_SHIFT; diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 7cfc28f1bb86f..e724cc053e264 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -1658,7 +1658,7 @@ static int privcmd_mmap(struct file *file, struct vm_area_struct *vma) * on a per pfn/pte basis. Mapping calls that fail with ENOENT * can be then retried until success. */ -static int is_mapped_fn(pte_t *pte, unsigned long addr, void *data) +static int is_mapped_fn(hw_pte_t *pte, unsigned long addr, void *data) { return pte_none(ptep_get(pte)) ? 0 : -EBUSY; } diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c index 27682cb5e58ab..387f97a555594 100644 --- a/drivers/xen/xenbus/xenbus_client.c +++ b/drivers/xen/xenbus/xenbus_client.c @@ -749,7 +749,7 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr) EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree); #ifdef CONFIG_XEN_PV -static int map_ring_apply(pte_t *pte, unsigned long addr, void *data) +static int map_ring_apply(hw_pte_t *pte, unsigned long addr, void *data) { struct map_ring_valloc *info = data; diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c index 8efd7b55223fb..d7244f9f9a545 100644 --- a/drivers/xen/xlate_mmu.c +++ b/drivers/xen/xlate_mmu.c @@ -93,7 +93,7 @@ static void setup_hparams(unsigned long gfn, void *data) info->fgfn++; } -static int remap_pte_fn(pte_t *ptep, unsigned long addr, void *data) +static int remap_pte_fn(hw_pte_t *ptep, unsigned long addr, void *data) { struct remap_data *info = data; struct page *page = info->pages[info->index++]; @@ -269,7 +269,7 @@ struct remap_pfn { unsigned long i; }; -static int remap_pfn_fn(pte_t *ptep, unsigned long addr, void *data) +static int remap_pfn_fn(hw_pte_t *ptep, unsigned long addr, void *data) { struct remap_pfn *r = data; struct page *page = r->pages[r->i]; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429291.1652203 (Exim 4.92) (envelope-from ) id 1x94mk-0004Tn-Sl; Tue, 22 Sep 2026 18:00:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429291.1652203; Tue, 22 Sep 2026 18:00:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94mk-0004TS-Nv; Tue, 22 Sep 2026 18:00:06 +0000 Received: by outflank-mailman (input) for mailman id 1429291; Tue, 22 Sep 2026 17:13:30 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x943e-0005GY-Nw for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:13:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x943e-005CEz-4h for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:13:30 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b70d-2eae-0a2a0a5409dd-0a2a450aec74-48 for ; Tue, 22 Sep 2026 19:13:29 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b738-f2d2-0a2a450a0019-d98c6eacc160-1 for ; Tue, 22 Sep 2026 19:13:29 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B1CBF1595; Tue, 22 Sep 2026 10:13:24 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 742013F86C; Tue, 22 Sep 2026 10:13:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097208; bh=A5NzDbD1noDwzYUVi8ldHdR4UZ15jpqj+KvUR0EDrHw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=igT401m5Ukd+3+6wB+UgkDK63LspXcTemyvQIbaw1+BgwuYsVHrX2DMhqhgHk3LXY kHy/IQiBkermaVeOcybtnCdoQu7KcLnO6cNeXQ+B00DQhjxLMdA8FG5xp3QHrnYKlq HpbAzdd9QkzACrgJ3YINIW0HcgeXtIyLmi4yHh8c= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:30 +0100 Subject: [PATCH v3 2/9] mm: rename pointers to software PTE values as ptentp MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-2-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-4011c0/1790097209-4ABD8CFC-A8EEAF4C/0/0 X-purgate-type: clean X-purgate-size: 2982 Some interfaces use pte_t * for a software PTE value rather than for an entry stored in a PTE table. These pointers must remain pte_t * when pointers to PTE table storage are converted to hw_pte_t *. Rename these parameters in the install_pte callback, write_protect_page(), and guard_install_set_pte() to ptentp. The later Coccinelle conversion skips pointers named ptentp, allowing it to convert the remaining PTE table pointers without changing these interfaces. Some functions already use ptentp for such pointers, including: - madvise_folio_pte_batch() - folio_pte_batch_flags() No need to rename them. This patch only renames parameters and makes no functional change. Acked-by: David Hildenbrand (Arm) Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Rewrite the subject and description to distinguish software PTE values from PTE table storage. Changes since RFC v1: - Update the description for the architecture opt-in conversion. --- include/linux/pagewalk.h | 2 +- mm/ksm.c | 4 ++-- mm/madvise.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h index b41d7265c01bc..c34d826c5e4a2 100644 --- a/include/linux/pagewalk.h +++ b/include/linux/pagewalk.h @@ -89,7 +89,7 @@ struct mm_walk_ops { struct mm_walk *walk); void (*post_vma)(struct mm_walk *walk); int (*install_pte)(unsigned long addr, unsigned long next, - pte_t *ptep, struct mm_walk *walk); + pte_t *ptentp, struct mm_walk *walk); enum page_walk_lock walk_lock; }; diff --git a/mm/ksm.c b/mm/ksm.c index 624f37975e129..2a4f19fe0f696 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -1292,7 +1292,7 @@ static u32 calc_checksum(struct page *page) } static int write_protect_page(struct vm_area_struct *vma, struct folio *folio, - pte_t *orig_pte) + pte_t *ptentp) { struct mm_struct *mm = vma->vm_mm; DEFINE_FOLIO_VMA_WALK(pvmw, folio, vma, 0, 0); @@ -1371,7 +1371,7 @@ static int write_protect_page(struct vm_area_struct *vma, struct folio *folio, set_pte_at(mm, pvmw.address, pvmw.pte, entry); } - *orig_pte = entry; + *ptentp = entry; err = 0; out_unlock: diff --git a/mm/madvise.c b/mm/madvise.c index 73c2901b9adbf..dd75a673e108f 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -1113,12 +1113,12 @@ static int guard_install_pte_entry(pte_t *pte, unsigned long addr, } static int guard_install_set_pte(unsigned long addr, unsigned long next, - pte_t *ptep, struct mm_walk *walk) + pte_t *ptentp, struct mm_walk *walk) { unsigned long *nr_pages = (unsigned long *)walk->private; /* Simply install a PTE marker, this causes segfault on access. */ - *ptep = make_pte_marker(PTE_MARKER_GUARD); + *ptentp = make_pte_marker(PTE_MARKER_GUARD); (*nr_pages)++; return 0; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429289.1652198 (Exim 4.92) (envelope-from ) id 1x94mk-0004RH-KP; Tue, 22 Sep 2026 18:00:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429289.1652198; Tue, 22 Sep 2026 18:00:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94mk-0004R6-Fa; Tue, 22 Sep 2026 18:00:06 +0000 Received: by outflank-mailman (input) for mailman id 1429289; Tue, 22 Sep 2026 17:13:19 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x943T-0005FS-CO for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:13:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x943R-006TAE-7q for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:13:17 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b72c-8faa-0a2a0a5109dd-0a2a4502c1b2-0 for ; Tue, 22 Sep 2026 19:13:16 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-720697.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b72b-6ca4-0a2a45020019-d98c6eace9ce-1 for ; Tue, 22 Sep 2026 19:13:16 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9E8A51595; Tue, 22 Sep 2026 10:13:11 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 479AD3F86C; Tue, 22 Sep 2026 10:13:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097195; bh=6PW1tkj08QGo8QdckrPX0ODHoxUb6pqu2veO+kTTZ/k=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=pCTPM03mJphkPxfc35zeUUsQF8Wf+c8WL4VK71wDLX28hB9HGW7S8BbVsmZ2JQk5T Yo0zY8RCJu6/8P4pPe9u2C/m6SJk9j0y0fparJfvZTMlzq4fTIbQBDrgjycGf2yHZq HemyfHlHgY+jLXxIgf46qiftTUNRZqsbU5Uy10Sg= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:29 +0100 Subject: [PATCH v3 1/9] mm: introduce hw_pte_t for PTE table storage MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-1-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-720697/1790097196-F22A92AC-391C8119/0/0 X-purgate-type: clean X-purgate-size: 3029 pte_t is used both for software PTE values and for entries stored in a PTE table, so pte_t * does not distinguish a pointer to a software PTE value from a pointer to table storage. Introduce hw_pte_t as the generic name for a PTE table element. Define it as a macro alias of pte_t by default. When an architecture selects ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead. This preserves the representation while allowing converted architectures to enforce the distinction at compile time. Name the generic wrapper structure __hw_pte_t so architectures can forward-declare it when pgtable_t must be defined before the generic hw_pte_t typedef is visible. This avoids header-order dependencies. Keep the C type definitions behind an __ASSEMBLY__ check because architecture assembly sources can include this header indirectly. Include asm/page.h so consumers such as linux/vmalloc.h retain the page definitions they previously obtained from that header. Acked-by: David Hildenbrand (Arm) Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Name the generic wrapper structure __hw_pte_t so architectures can forward-declare it, and explain why this is required. - Use software PTE value terminology. Changes since RFC v1: - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition. - Exclude the C type definitions from assembly sources. - Update the description for the new opt-in model. --- MAINTAINERS | 1 + include/linux/pgtable_types.h | 17 +++++++++++++++++ mm/Kconfig | 3 +++ 3 files changed, 21 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2133aec4a2004..da60a8bdcddb5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17140,6 +17140,7 @@ F: include/linux/mmu_notifier.h F: include/linux/pagewalk.h F: include/linux/pgalloc.h F: include/linux/pgtable.h +F: include/linux/pgtable_types.h F: include/linux/ptdump.h F: include/linux/vmpressure.h F: include/linux/vmstat.h diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h new file mode 100644 index 0000000000000..07da05d375c2c --- /dev/null +++ b/include/linux/pgtable_types.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_PGTABLE_TYPES_H +#define _LINUX_PGTABLE_TYPES_H + +#include + +#ifndef __ASSEMBLY__ + +#ifdef CONFIG_ARCH_HAS_HW_PTE_T +typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t; +#else +#define hw_pte_t pte_t +#endif + +#endif /* !__ASSEMBLY__ */ + +#endif /* _LINUX_PGTABLE_TYPES_H */ diff --git a/mm/Kconfig b/mm/Kconfig index c1ddf59c0d71a..5f462ec6fa5e5 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1312,6 +1312,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled" config GUP_GET_PXX_LOW_HIGH bool +config ARCH_HAS_HW_PTE_T + bool + config DMAPOOL_TEST tristate "Enable a module to run time tests on dma_pool" depends on HAS_DMA -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429302.1652234 (Exim 4.92) (envelope-from ) id 1x94mm-00057P-N5; Tue, 22 Sep 2026 18:00:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429302.1652234; Tue, 22 Sep 2026 18:00:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94mm-00055G-Cx; Tue, 22 Sep 2026 18:00:08 +0000 Received: by outflank-mailman (input) for mailman id 1429302; Tue, 22 Sep 2026 17:14:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x944V-0005Ln-2W for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:14:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x944U-00Gilg-Fl for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:14:22 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b767-bab6-0a2a0a5309dd-0a2a450c81d2-26 for ; Tue, 22 Sep 2026 19:14:22 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b76d-f479-0a2a450c0019-d98c6eacee0a-1 for ; Tue, 22 Sep 2026 19:14:21 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7B61A1576; Tue, 22 Sep 2026 10:14:17 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D30003F86C; Tue, 22 Sep 2026 10:14:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097261; bh=m1/Zj1kl1r4NT70p2V5vARYiyafZNwoUEY016kfXI6M=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=uyMUOZj6R5njDUnUE0WViDRG203+0ImQf8L3e4R3tvNeiQX8hthSWT3MmAozquZCC MtaevHRyysWE/QOR2DnQlqNWb2SZ0tKdXvT/wq71vEr+9CY6J3c/VDmp9lE+PtmgLq I6LApZTWohZd2n0AKddZqBwhz/kVnU82kKMdtcjU= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:34 +0100 Subject: [PATCH v3 6/9] mm: add hw_pte_val for HW PTE storage MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-6-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-d25034/1790097262-51737A5B-2E5D5452/0/0 X-purgate-type: clean X-purgate-size: 1321 Atomic PTE updates need an lvalue for the bits stored in an HW PTE. pte_val() only accepts a SW PTE value, so it cannot operate directly on a distinct hw_pte_t. Add hw_pte_val() to expose the underlying pte_val() lvalue. Access the wrapper's __pte member when hw_pte_t is distinct, and use pte_val() directly when it remains an alias of pte_t. Signed-off-by: Muhammad Usama Anjum --- Changes in v3: - Moved from the arm64 series to generic series as it makes more sense to add this in generic with all other changes. Usually we only add code where its get used. But this whole series wouldn't get used until an arch started using HW PTEs. --- include/linux/pgtable_types.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h index d6c5a7548550b..ee4eace5c3e1c 100644 --- a/include/linux/pgtable_types.h +++ b/include/linux/pgtable_types.h @@ -9,9 +9,13 @@ #ifdef CONFIG_ARCH_HAS_HW_PTE_T typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t; #define __pte_from_hw(pte) ((pte).__pte) + +#define hw_pte_val(x) pte_val((x).__pte) #else #define hw_pte_t pte_t #define __pte_from_hw(pte) (pte) + +#define hw_pte_val(x) pte_val(x) #endif #endif /* !__ASSEMBLY__ */ -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429296.1652212 (Exim 4.92) (envelope-from ) id 1x94ml-0004iT-IX; Tue, 22 Sep 2026 18:00:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429296.1652212; Tue, 22 Sep 2026 18:00:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94ml-0004g2-BT; Tue, 22 Sep 2026 18:00:07 +0000 Received: by outflank-mailman (input) for mailman id 1429296; Tue, 22 Sep 2026 17:13:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9444-0005Ir-BS for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:13:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9443-005CIV-OU for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:13:55 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b741-2eae-0a2a0a5409dd-0a2a45039aa4-34 for ; Tue, 22 Sep 2026 19:13:55 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b752-fae8-0a2a45030019-d98c6eacc21c-1 for ; Tue, 22 Sep 2026 19:13:55 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 094B31595; Tue, 22 Sep 2026 10:13:51 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C46153F86C; Tue, 22 Sep 2026 10:13:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097234; bh=VSAJHWUAe7NS76HVRAMjNd0GQzrtewrgnfoeWDUMlnY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=FVt56hjuBPaMyg/BnFKqE4fzU1cEu6NBRc7MPH68RUYG/CCz6y6YC9RG6hPWhN96x x9hwL9qrWyGY3gHSBta6j4l7PueQkx2vM6HZNIWXJTPqHrodyx2R2jU4yzc9rQNtJ/ 1suYvsUR4FuoJM/twYHmYXuJo99AkA0nApGsDh9M= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:32 +0100 Subject: [PATCH v3 4/9] mm: convert PTE table entries in ptep_get() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-4-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-33051d/1790097235-6D8D54E9-34DFBB81/0/0 X-purgate-type: clean X-purgate-size: 1531 ptep_get() now accepts a pointer to hw_pte_t storage but must continue to return a software PTE value. Add __pte_from_hw for both generic hw_pte_t definitions. Read the hw_pte_t table element atomically before converting it to pte_t. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Use software PTE value terminology. Changes since RFC v1: - Define __pte_from_hw for the opted-in generic wrapper. - Apply READ_ONCE() to hw_pte_t before converting it to pte_t. --- include/linux/pgtable.h | 2 +- include/linux/pgtable_types.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index 19098e302b75a..41337da0d65aa 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -493,7 +493,7 @@ static inline int pudp_set_access_flags(struct vm_area_struct *vma, #ifndef ptep_get static inline pte_t ptep_get(hw_pte_t *ptep) { - return READ_ONCE(*ptep); + return __pte_from_hw(READ_ONCE(*ptep)); } #endif diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h index 07da05d375c2c..d6c5a7548550b 100644 --- a/include/linux/pgtable_types.h +++ b/include/linux/pgtable_types.h @@ -8,8 +8,10 @@ #ifdef CONFIG_ARCH_HAS_HW_PTE_T typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t; +#define __pte_from_hw(pte) ((pte).__pte) #else #define hw_pte_t pte_t +#define __pte_from_hw(pte) (pte) #endif #endif /* !__ASSEMBLY__ */ -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:00:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:00:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429304.1652241 (Exim 4.92) (envelope-from ) id 1x94mn-0005IS-3g; Tue, 22 Sep 2026 18:00:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429304.1652241; Tue, 22 Sep 2026 18:00:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94mm-0005Gt-Ph; Tue, 22 Sep 2026 18:00:08 +0000 Received: by outflank-mailman (input) for mailman id 1429304; Tue, 22 Sep 2026 17:14:37 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x944i-0005Mv-UF for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 17:14:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x944i-00Ae9t-B5 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:14:36 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2b748-8faa-0a2a0a5109dd-0a2a4504e582-18 for ; Tue, 22 Sep 2026 19:14:36 +0200 Received: from [217.140.110.172] (helo=foss.arm.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTP (eXpurgate 4.57.1) (envelope-from ) id 6ab2b77b-b57f-0a2a45040019-d98c6eac94f8-1 for ; Tue, 22 Sep 2026 19:14:36 +0200 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 78D071595; Tue, 22 Sep 2026 10:14:31 -0700 (PDT) Received: from [127.0.1.1] (e142334-100.cambridge.arm.com [10.2.198.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 50FAF3FA32; Tue, 22 Sep 2026 10:14:21 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=foss header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:References:In-Reply-To:To:Cc" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790097275; bh=SNK4rrwFvjnxcdknL2hsc20bUzMvwr6CIipWYMszSzs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=iARAx8Qyk1413VBr4PC7dGwIhlrToaTnagZ6dPlvezmqEddDjaVkHLgBTgS5wWhxt NG3MjS+xmLq1vZyn83oVsYzSt8u9iMTTXB3k+0eeRFDj4F3gou8popZy7lpyXeDKr4 SHUdvtaZmDDnMdNPXUZnhs8extIVv21cyFM4/8oM= From: Muhammad Usama Anjum Date: Tue, 22 Sep 2026 18:12:35 +0100 Subject: [PATCH v3 7/9] mm/kasan: use hw_pte_t for the early shadow PTE table MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260922-pte0-v3-7-5670b8cb9059@arm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org, Muhammad Usama Anjum X-Mailer: b4 0.16.0 X-purgate-ID: tlsNG-ebf023/1790097276-528C9B50-8DA07A91/0/0 X-purgate-type: clean X-purgate-size: 2371 kasan_early_shadow_pte is a complete PTE table rather than a software PTE value. Declare and define its elements as hw_pte_t so the object uses the PTE table storage type. Read the first element through ptep_get(), which returns the software PTE value expected by note_page_pte(), instead of accessing hw_pte_t storage directly. This also uses the accessor selected by the architecture. No architecture selects ARCH_HAS_HW_PTE_T at this point, so the storage representation remains unchanged. Signed-off-by: Muhammad Usama Anjum --- Changes since v1: - Use software PTE value terminology. Changes since RFC v1: - Update the description for the architecture opt-in model. --- include/linux/kasan.h | 2 +- mm/kasan/init.c | 2 +- mm/ptdump.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index bf233bde68c7e..ff41949c0ac08 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -51,7 +51,7 @@ typedef unsigned int __bitwise kasan_vmalloc_flags_t; #endif extern unsigned char kasan_early_shadow_page[PAGE_SIZE]; -extern pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS]; +extern hw_pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS]; extern pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD]; extern pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD]; extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D]; diff --git a/mm/kasan/init.c b/mm/kasan/init.c index 30c5266eaf37e..9bbc2a41d23f0 100644 --- a/mm/kasan/init.c +++ b/mm/kasan/init.c @@ -64,7 +64,7 @@ static inline bool kasan_pmd_table(pud_t pud) return false; } #endif -pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS] +hw_pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS] __bss_pgtbl; static inline bool kasan_pte_table(pmd_t pmd) diff --git a/mm/ptdump.c b/mm/ptdump.c index 376880071ca2a..8f19f20be3c44 100644 --- a/mm/ptdump.c +++ b/mm/ptdump.c @@ -19,7 +19,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk, { struct ptdump_state *st = walk->private; - st->note_page_pte(st, addr, kasan_early_shadow_pte[0]); + st->note_page_pte(st, addr, ptep_get(kasan_early_shadow_pte)); walk->action = ACTION_CONTINUE; -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:04:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:04:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429391.1652286 (Exim 4.92) (envelope-from ) id 1x94rB-00012h-P5; Tue, 22 Sep 2026 18:04:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429391.1652286; Tue, 22 Sep 2026 18:04:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94rB-00012a-MG; Tue, 22 Sep 2026 18:04:41 +0000 Received: by outflank-mailman (input) for mailman id 1429391; Tue, 22 Sep 2026 18:04:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x94rA-00012U-3v for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 18:04:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x94r9-000XMc-6E for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 20:04:39 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2c32c-8faa-0a2a0a5109dd-0a2a450c8116-14 for ; Tue, 22 Sep 2026 20:04:38 +0200 Received: from [52.101.85.40] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2c334-f479-0a2a450c0019-346555284326-3 for ; Tue, 22 Sep 2026 20:04:38 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by MW3PR12MB4377.namprd12.prod.outlook.com (2603:10b6:303:55::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 18:04:34 +0000 Received: from BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740]) by BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740%3]) with mapi id 15.21.0451.012; Tue, 22 Sep 2026 18:04:34 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rIEghoqffS+B5m0AB8cm5VSOkz0gC4CoyLD+2wabmYutAxo5m8ItRo/pL0IbTwjUexjEGhkPIjhCEAq7ZbnK/jfMlHId6nLWLSiRoPYL8zXx6Cm/l86P1Hfy/75Ei3+A8M/wLmD8MqZYAZTXCuBRsm/9LIYpexDYf746w79wt8SNVN4itSLzuM1k4eHi0uJgSffW0USTOwmNAnuiFXa5DFBosMkEI85YcSZCUswk9clb3l7ky3D5Br0/WPjfRBw/yPWI5TS4IRwxYlg5CNQbciJHa1UsEFXSLioNj7pbvjGe7z2QS/NWqNKh4TiJ8H3NZMxUUPpQCIpgTMnfz1pxfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KsafzPgXm+m80JgfRlY5/jcuPa28hbwq3sNzFBPowF0=; b=Mnd+qcZ27W86R+m58HSAjJ1rsBO1Nj3OV8ckO6rSYiA/BDp7JvgKDIMhJc7juKPhTm8GRxhvuuCVr1+rqsNrDvGBg03aFEke7at8cx9mZkcA6yhE6Z0E5N1lxWNXaPlbiWyigMWgklOBGFqZfc2sNl9d2DJnQziE9PaIdwuyfYB7w17fnpim0hHNX31V0x4JwwkXbjwHHVUOnqNS5PKR29ldD/1Ytm8BzNGtolyXxD1qDyo7Mw0L3hUeIRQ5QItb0Rl/a74YH1ecYwB457k201/eOuqI9cbPLx84hKirWI5iMJbaDm5XWK2ZUVcnUj/DnU5VwLKk0+scJpqz59l9PQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KsafzPgXm+m80JgfRlY5/jcuPa28hbwq3sNzFBPowF0=; b=MITuxenF2p7kXtvMz57grW+axEDfLY4YFuvUoggC/bFEQTo2mZo/c7Hmh1LA/WtyIOWtlxiyZj5nclsxjwAotFOtfEm/QYdT0cIEdX3/74ztaZhu056uumBVjs2U6+vJcuehJluXp+S63RJns8nbDnqYPcWIEGSCldPaNaNiVdU= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 22 Sep 2026 20:04:31 +0200 Message-Id: Cc: "Andrew Cooper" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Teddy Astie" , Subject: Re: [PATCH] x86emul: Cache the amd_like() output on x86_emulate() entry From: "Alejandro Vallejo" To: "Jan Beulich" X-Mailer: aerc 0.17.0 References: <20260921092545.37148-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-ClientProxiedBy: MA2P292CA0024.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::6) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|MW3PR12MB4377:EE_ X-MS-Office365-Filtering-Correlation-Id: 19241c6e-237e-41c3-8a05-08df18d3f524 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|10067099003|5023799004|11063799006|22082099003|18002099003|56012099006|4143699003; X-Microsoft-Antispam-Message-Info: ZoyC4g93Jx5zzHCF9+k650WmvU3/71GCt7+LNqciBeeOxY67Rgv55A/VSvoG78xMkva6C5OADr67EgPxwDuzESdJwdy/TF/3kEHibuypjBnk04ngZsJRVXTkQDgf+9o8zvQbKmYWNFq+xnNlF3X1ag/aKKFY6u8as+zWKINHnqO/3ml+BR+LS44Zz7/Yqv8lhRSIefLERpvEUg1z41/ueVNNt0tF/LFnAlVYSCbdCO5X/fl9f4bKqL69iCR64GxtL63u7yayeI6KLkBeTfq0+ddfZT/cwUfof0qiSgxz78Mo5Oqy1lXQlNsV8GIt4yPqLzXelCHpTmF8PZygICDWtDpUogF0Xh1Xqhtb0YP3t8JBJ/ra3qT0iJM/+zdsaPLYpazSLM4bKXTAar+4SRJTGEwR0xD+aTKtXBbRTVhNIK+tX/MsqcWc9Q3gwDELf3W6V8LRHAMAX7bmd+OvTOTqn1asd2zSeAG1xeg2ih2fBS/oDqea1ylG3pV3fYfpWMMb+og2BYTZrUzi+j5ZtfhDuTTX9RwrqLb7Jcqf9/WmZq0IQPr9MYsVVImrLFV7XwyeAp0ypiz2AuHI6fUhkR8T1fZ+AwyEEvRs74/1ws1H7krAjG4PGbN4nDPHRIwA0q7giEmq7MGK7wPaHXQCQD80YaAUnc2LR9esaTFKq/cMIqI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB4999.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(10067099003)(5023799004)(11063799006)(22082099003)(18002099003)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V3RvRUtwUEUxcE9BcFMyZVNzUFJidUpmMkljWVB3TUQydkJjWWZhb0VTa3hp?= =?utf-8?B?OWN0YU9YQjFFUnNUVW5GQ1lFdUZmWUVpLy82THRyQjk2OHpRWlpDVyt6WXVJ?= =?utf-8?B?dUMyUkZoUUZIaVQ2eWRXbGhWVlN0R2ppcEF4aVQ0MW1xTTB0REhXRnBYaW5m?= =?utf-8?B?YjlTT0VJSm9PdHVJVjluQjRLVUw5K1NMTGRyQStIUzdyc1d6bHRMMHl2UGhq?= =?utf-8?B?RFRwTWE5MWRkQjJ6c3VzbXNkcjYzRlBLcG4xQ0VqVUpBc3RHZU1RY2Rkc1hX?= =?utf-8?B?WHcrNWt5M2xiMlM4YXNwSXZFbUJueEhUeGhNd0ZWUU0rUVU5b0lSWG5VQjJy?= =?utf-8?B?Wm9jNlNCbHowSlpxSSsrY1BFbkFtRUtqYlFlQUdCaldwZEN2ZW9kYVNTSGJW?= =?utf-8?B?S1FLaVRkanFYRHBBaTl6ekF1d0NFdSs2aVlyTGg2Ti9mZ1Nsa2NTamZtMi81?= =?utf-8?B?OFdGaTRBZGhMQUhVdnovSVdEUTNhTWJ3VDFWbUM2bjI1SFBYeDRkSk9jS2M4?= =?utf-8?B?c1RBYWhrK1hiRjdScEx1bENpS3NBRnVDSjZucnk1b0hBSUhBbndTeEEralFB?= =?utf-8?B?ejJkV3J2NW8ybnVVdVNMeDIwMitRRGN3V3drOVdleGxvZGJ0ZXBicjVaNS9v?= =?utf-8?B?Y05vVjVBZWVaL2x1QmVwNFU5UzlCUko1c0VwcVRZVmYzNG1JY2xXdUg1cGtM?= =?utf-8?B?cHQvd0N5eDd2SVpnRDgzMUIwNGw5MlpkbVc4aUxpbXRuUjJFTmRYT05ZMWtX?= =?utf-8?B?YzlsTjV3N3V4K3FDSTZsb2JJejVQajB2VVVQM3VrdUdSUVppMkJVbDM1NFJR?= =?utf-8?B?dGVVM1o1VnA5MFhyYUdsVlRwNEZOWkF3ZDdiN2paK0x5L21rOFFLcHQwQWpv?= =?utf-8?B?NVo4MFBXa2hFczkyb1JIMHBTNmJVUHVvNDFRRUpmSW9WMmFEeEpGQ1NsN2px?= =?utf-8?B?RlV2LzJnbEJ4Q2hEdFY4VU05RFowemJyUUwvL3QxNTBTZDgyYm95cFM4MExu?= =?utf-8?B?ZzVGSCtNeEExbFhQVFp1QUVNeWVPYTY4SkZlWlZ5VkNyMVNwUVVrSWlzamhj?= =?utf-8?B?WVdPaFArd2prbDRDc1E4QmQyUU1hNjZEUndibnBpeElKbmoxVjQ4UGxoeWpx?= =?utf-8?B?cGxtWEY1QVJKdjBETzc5NFdFTGxmREtMUUI5SHpVYmludzlrOFFUdXByVkx1?= =?utf-8?B?d25nWkJWUWdlaTRCUHJpY3BZMFZ2akNrMUZmNWJGN2tDRHc1M2tJOTBLSVdv?= =?utf-8?B?c09iL3hNai93czV6aFdYRGZYOTcyTXBxV3lRNWZsYmpqMzAwL0RCSW1xVnJ4?= =?utf-8?B?NlBoZ3RKZ3ZKeTRNZnBQdW02MzFhOW9yN3dtR3pJWGdxa0hQSnlma3FRblI4?= =?utf-8?B?R3VIT1JZVmF2NklhNXZXVE1iRDZYZVJsT3ZpaHh5a0RGYXF2T1c2V3hTSWxi?= =?utf-8?B?cUNWN2NsbGRUaE5pWDNnR2w0L2VKRllwbE1tWUFJR2Mxa3RwOXZrOE10YjNF?= =?utf-8?B?bjE3emR5ajM0bFJvSTV4bXJ0cWVrazR0QlY1OGJ6MG03WXRneDlKTWp5L29G?= =?utf-8?B?U25XZXBEaGJCNXV1VG95ZTNvcTVPcWJIZVVwWTF5MDA0ZkhwQjJNSjEySmpV?= =?utf-8?B?VVNBcDJwVXJJby9NY3ZQalBFN2g2c0tHbCtNRzJoMDFEN1FtdWtKVU1ZNWQ2?= =?utf-8?B?UmVUQ2tPQklxZXlUKytEMTNTY2dselJVdEs3OHJ5MGhtMlRkQ1c2Rzg0Ti9L?= =?utf-8?B?SXZuTytUcUFIa0VMOU11NkpwejVlcTFGMkhkZHNJT1k0L2JhZ3VqSCtUeGdC?= =?utf-8?B?amlaWEM0cFNtTzhpNXJ5MGZkSnE4eTVQUHBEOVRsTFhQWHBGU1BKTHJFK3Az?= =?utf-8?B?MkR0Ti9oWlg3Z0pxd0Nzb1YwcFlBWVk2OEVQeW9NbDFndzcxUTFKRkFlNnZC?= =?utf-8?B?NnRTcFg5OFhvVm1lY2FpaUtrZEtsYkxVbkxNOE5rc0luam5tNTMxeUlXdVV0?= =?utf-8?B?aWJUcDhVWEFqUzBoTVhOMGYvcmVGQys5OFFjQlZuNDMwS05uYmVaV1Y2bm02?= =?utf-8?B?WU1iUng1UE1KdjdiRUprU3d3OCtoUXF4MnJ6cUMrQ3dLSGNmZFZJT2lmem9z?= =?utf-8?B?MytMZzhUWmNwOHMvQVZqU1VGYU9nRkZtTmlBdDU5NGVxcDVjVUVmMWp6ZWw5?= =?utf-8?B?V2NrTDFpdWhmcFFPdFg4dTJuY0RlMk5TTkF6dk9QcWZxTU5ZbXVqY1pDME51?= =?utf-8?B?Y3Y0TTlGcXM4cXNzWW85OXNTN3pCY3hqZk1maTk2b3FLMVM5bnVabUlKeVNs?= =?utf-8?Q?SvMfgOTV4mUga2vkNQ?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19241c6e-237e-41c3-8a05-08df18d3f524 X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2026 18:04:34.1648 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7vjAryzad659JLFOJ/DfPtVNx8LJnlUqXRCokMo/t939zGW+XD4vB2i9CpaS5RJlJByuIsb2y4xguoieLbEQ1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4377 X-purgate-ID: tlsNG-d25034/1790100278-50F3BA5B-CFE38C0D/0/0 X-purgate-type: clean X-purgate-size: 1962 On Tue Sep 22, 2026 at 3:34 PM CEST, Jan Beulich wrote: > On 21.09.2026 11:25, Alejandro Vallejo wrote: > > The current code instantiates amd_like() way too many times, leading to > > codegen explosion. Unconditionally call it early on, and use that > > variable everywhere. This shrinks the emulator by ~3KiB. > >=20 > > No a functional change. > >=20 > > Signed-off-by: Alejandro Vallejo > > --- > > pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelin= es/2860748404 > > (it's red because of an caching issue and personal branch nam= e > > conventions it's just arm. x86 passes in full) > >=20 > > bloat-o-meter before-after patch. > >=20 > > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-3366 (-3366) > > Function old new delta > > x86_emulate 209351 205985 -3366 > > Total: Before=3D3617694, After=3D3614328, chg -0.09% > > That's surprisingly big a difference, considering how simple amd_like() i= s. > I'm counting 24 instances, so the savings would be well over 100 bytes pe= r > instance. I have some more interesting results. I can very much repro at that commit with GCC 13 with debug=3Dy, but ALSO the variable must be set at the tail of all other locals. I never noticed the gain was gone after moving where it is in this patch. Clearly I misattributed the origin of the shrinkage. In retrospect, it turns out to be an unrelated matter. I _THINK_ register pressure is somehow precluding the inlining of a helper. The problem is gone in debug=3Dn where CSE ensures all is good. If I find a way of shrinking debug builds in a way that's more resilient to compiler specifics I'll push that as a separate patch, but for now I'll just drop this. Clearly it doesn't matter here for a realistic build. Apologies for the noise. Codegen is hard :) Alejandro From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:43:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:43:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429417.1652297 (Exim 4.92) (envelope-from ) id 1x95Sq-0007yh-KG; Tue, 22 Sep 2026 18:43:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429417.1652297; Tue, 22 Sep 2026 18:43:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x95Sq-0007ya-Gd; Tue, 22 Sep 2026 18:43:36 +0000 Received: by outflank-mailman (input) for mailman id 1429417; Tue, 22 Sep 2026 18:43:35 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x95Sp-0007yP-GO for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 18:43:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x95So-006dB4-Be for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 20:43:34 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2cc47-e002-0a2a0a5209dd-0a2a4505c714-30 for ; Tue, 22 Sep 2026 20:43:34 +0200 Received: from [74.125.224.170] (helo=mail-yx2-f42.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2cc55-4cb1-0a2a45050019-4a7de0aa8d9b-3 for ; Tue, 22 Sep 2026 20:43:34 +0200 Received: by mail-yx2-f42.google.com with SMTP id 00721157ae682-89666ee9b3bso3799877b3.0 for ; Tue, 22 Sep 2026 11:43:33 -0700 (PDT) Received: from StolidWingnut.axolotl-tone.ts.net ([174.80.170.224]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8a4658c723asm1141807b3.15.2026.09.22.11.43.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Sep 2026 11:43:32 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=edera.io header.i="@edera.io" header.h="Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=edera.io; s=google; t=1790102613; x=1790707413; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=29xwDDSi2fCcXa+moxCVRPRT7c5WgBkgjLtY01+nTtM=; b=ffMv+K3EM6mv7X/lWUCvFSLXwKioRoyz2RDtQER0vz4LSDbJwpQV6/BhFQIFOqWwYG UIMYJVKihtk5JXljBQdHjRJlY3PCZvOV/rYZy0Lk2u7LcS5+Ou1QVQGx5HcMq5wyLrD2 mQeZ6iYRvhVVGI9Gtk4PgjovYB91afCT1X+BF0owL2udSjcKjxCXHS7GPrP3gsBifUHk wsc6H2Gy38iE7HTg9RFbHt7ohZsJ19vUe5IjG9zipMKhm67aL130aGHQPhXhkwSVgi76 Ir1lEtJ9Aeiq5+DHXtjhFB+hgeQ0/Y76pt9kt5SwWYPWvmt0JLVNyQMaowLWBQGDrFKy agGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790102613; x=1790707413; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=29xwDDSi2fCcXa+moxCVRPRT7c5WgBkgjLtY01+nTtM=; b=GOqMgzH/owIJArtofb/9xZA4vHsuj0OKUsFGrNBgiKMlnEjyHiyuaKfCDc8bwzC1jS YSm32P7QIyI1NVGF7qTk+8NBXES7xrgQO49gE+tlCbSF2p2fAleUeLmD6dOZZWHE3+8E 0UtMDTM1SBzJ0503MaRyxP0s47zlKpMfVzSNFQCEcf0l/j22wbx2KvHE9YnepgWCsKEl aedYN9JBlaiHC+Scmrr3fSNPc106illC4x+B4CDDNe9nyXrg9p/9T3Tjxy3RNub4+wCj gx4zpJXrvwp3RoL/JRhawj0ULgBWcZsnf0Khul1zx6+7D+FCsIuKJNPaNXqagQtL06ZE Tggw== X-Gm-Message-State: AFuF++m717//7kMEA+cvE6jeqTETBeFkY2lQVaDOJ1KpdIqyIbp7vDUt 6KTyHh7B5nWhQJaD66N87tBtOxZT/wNFbuLNf7aTrwDoS9OZ4DA3YfOBBs0WGSZDIsjx2fFRXTW aCpsqBpk= X-Gm-Gg: AYBFou12H++Z8UEC3Zz8WbFUrwMtL3cNY2jmzM6g0mQyEtfClmtxZfzPmzEm6ipXcsw Kzq+Midu83epN1qQ3zfVKzoJgflMsrrcR2wTcaU+lJW1Gg27P4VnEXel7muLwC4McjDoLq4eVLZ +NM3rBFp6hNOMv6WNe5banUrjfavKh5bz3M3CSfR88/lgIfRzKYBEytv/IJaBuihNeXmjIoihoy 3Jo40bvg/BDD7mzYmdv3NsgBHzAB3Y5S+K76IW1+0E7c560+DUJeFOUuqDOOiaVS1Dw5HLUbAsf Racxj7CtT+aHHx7vq4iyiRkIvKqygePTwh310AGIUIbMlP+yOdIvg7gVXHYJL494G0MJJB8Dx4v OsecD+WiuNziqVP64Arv+Q0n3HAQn48RCIbn4PC4tQ3YLj6pyzVozTbzm2MAssZNcbjijRR9pk0 5zdwT72v74IxsOs4ooq+PmG2jMep3+Q4cMglmuVH7sgwKIqKTZ6J6oj+TEk+kZd3WJZIST7iYqi Uv9D8c7ynzWso468DASySomMeHMOfVlhYrPIgjBqMhKE0BGzvSIbvEoQYZZkMyGHqTynFiejwwu Sq0TiQ== X-Received: by 2002:a05:690c:a6d4:b0:888:7a02:280d with SMTP id 00721157ae682-8a45afa799emr2654537b3.30.1790102612569; Tue, 22 Sep 2026 11:43:32 -0700 (PDT) From: Benjamin Leggett To: xen-devel@lists.xenproject.org Cc: Benjamin Leggett , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] ns16550: find the console UART on PCI when there is no legacy one Date: Tue, 22 Sep 2026 14:43:16 -0400 Message-ID: <20260922184316.324817-1-benjamin@edera.io> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790102614-6BEB92A1-8F0D6B88/0/0 X-purgate-type: clean X-purgate-size: 5800 Amazon EC2 bare metal instances have no UART at the legacy I/O port 0x3f8. Their only serial port is a 16550-compatible PCI device (vendor 0x1d0f, device 0x8250) with its registers in the MMIO space of BAR 0. Today Xen has no console on these systems unless the command line names that device, and "com1=...,pci" cannot find it, because uart_config[] doesn't have it. Add the device to uart_config[]. Additionally, when the port that com1 describes is not present, scan PCI for a known UART before giving up. This way the same command line works on systems with and without a legacy UART, and a machine-specific "pci" option is not needed. The fallback does not run when the command line gave an I/O base, or when it already asked for a scan with "pci" or "amt", so explicit config keeps its current meaning. It is for com1 only: for com2, pci_uart_config() skips the first port it finds, so it can never match a single-port device. When the scan finds nothing, pci_uart_config() puts back the original base, and check_existence() does not test MMIO addresses. On a system with a legacy UART, check_existence() passes and nothing changes. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Benjamin Leggett --- xen/drivers/char/ns16550.c | 47 +++++++++++++++++++++++++++++++++++++- xen/include/xen/pci_ids.h | 2 ++ 2 files changed, 48 insertions(+), 1 deletion(-) diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 120ac09d23..d5403598d2 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -64,8 +64,10 @@ static struct ns16550 { bool intr_works; bool force_polling; bool dw_usr_bsy; + bool io_base_set; /* if =1, io_base came from the command line */ #ifdef NS16550_PCI /* PCI card parameters. */ + bool pci_scanned; /* if =1, pci_uart_config() already ran */ bool pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ bool ps_bdf_enable; /* if =1, ps_bdf effective, port on pci card */ pci_sbdf_t pci_bridge; @@ -98,6 +100,7 @@ struct ns16550_config { param_intel_lpss, param_wch_ch382, param_asix, + param_amazon, } param; }; @@ -909,6 +912,13 @@ static const struct ns16550_config_param __initconst uart_param[] = { .bar0 = true, .max_ports = 1, }, + [param_amazon] = { + .reg_width = 1, + .lsr_mask = UART_LSR_THRE, + .bar0 = true, + .mmio = true, + .max_ports = 1, + }, }; static const struct ns16550_config __initconst uart_config[] = @@ -1255,6 +1265,12 @@ static const struct ns16550_config __initconst uart_config[] = .dev_id = 0x9910, .param = param_asix }, + /* Amazon EC2 bare metal UART, the only serial port on those systems */ + { + .vendor_id = PCI_VENDOR_ID_AMAZON, + .dev_id = 0x8250, + .param = param_amazon + }, }; static int __init @@ -1263,6 +1279,8 @@ pci_uart_config(struct ns16550 *uart, bool skip_amt, unsigned int idx) u64 orig_base = uart->io_base; unsigned int b, d, f, nextf, i; + uart->pci_scanned = true; + /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus 0. */ for ( b = skip_amt ? 1 : 0; b < 0x100; b++ ) { @@ -1618,6 +1636,7 @@ static bool __init parse_positional(struct ns16550 *uart, char **str) #endif { uart->io_base = simple_strtoull(conf, &conf, 0); + uart->io_base_set = true; } } @@ -1693,6 +1712,7 @@ static bool __init parse_namevalue_pairs(char *str, struct ns16550 *uart) break; } uart->io_base = simple_strtoull(param_value, NULL, 0); + uart->io_base_set = true; break; case irq: @@ -1805,7 +1825,32 @@ static void __init ns16550_parse_port_config( if ( uart->io_base == 0 ) PARSE_ERR("I/O base address must be specified."); if ( !check_existence(uart) ) - PARSE_ERR("16550-compatible serial UART not present"); + { + bool present = false; + +#ifdef NS16550_PCI + /* + * Some systems, EC2 bare metal among them, have no legacy UART and + * carry their only serial port on PCI. Look for one before giving up, + * unless the command line named a base or already asked for a scan. + * com1 only: for com2 the scan skips the first port it finds, so it + * can never match a single-port device. + */ + if ( uart == ns16550_com && !uart->io_base_set && !uart->pci_scanned ) + { + pci_uart_config(uart, 1 /* skip AMT */, uart - ns16550_com); + /* + * A scan that matched nothing puts back the base we just rejected, + * and check_existence() passes MMIO addresses through untested, so + * ps_bdf_enable is what says a device was found. + */ + present = uart->ps_bdf_enable && check_existence(uart); + } +#endif + + if ( !present ) + PARSE_ERR("16550-compatible serial UART not present"); + } /* Register with generic serial driver. */ serial_register_uart(uart - ns16550_com, &ns16550_driver, uart); diff --git a/xen/include/xen/pci_ids.h b/xen/include/xen/pci_ids.h index fd424ef55d..a17c88dcf7 100644 --- a/xen/include/xen/pci_ids.h +++ b/xen/include/xen/pci_ids.h @@ -17,6 +17,8 @@ #define PCI_VENDOR_ID_WCHIC 0x1c00 +#define PCI_VENDOR_ID_AMAZON 0x1d0f + #define PCI_VENDOR_ID_INTEL 0x8086 #endif /* XEN_PCI_IDS_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:48:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:48:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429432.1652304 (Exim 4.92) (envelope-from ) id 1x95Xo-0000Oa-8Y; Tue, 22 Sep 2026 18:48:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429432.1652304; Tue, 22 Sep 2026 18:48:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x95Xo-0000OT-60; Tue, 22 Sep 2026 18:48:44 +0000 Received: by outflank-mailman (input) for mailman id 1429432; Tue, 22 Sep 2026 18:48:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x95Xm-0000ON-Lb for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 18:48:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x95Xl-005MWG-VA for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 20:48:41 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2cd65-8faa-0a2a0a5109dd-0a2a4503e044-48 for ; Tue, 22 Sep 2026 20:48:41 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2cd89-fae8-0a2a45030019-4a7de18ce22f-3 for ; Tue, 22 Sep 2026 20:48:41 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd4ba9f68so1247425e9.1 for ; Tue, 22 Sep 2026 11:48:41 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fde1acb91sm10872635e9.15.2026.09.22.11.48.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 11:48:40 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790102921; x=1790707721; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=lIPMuq7W1Pa4X4TXu8rbTxYicHKqL6hnBXo/9p1I/dM=; b=dwx/kwnxIvR0NpYpc9ByzbERa7DGlJJFiIILWZpREbmoheZeQEcgknIXGWMF7peDP0 Ak2g3YFoarVrYm9rxCNuVsqYyAyaW4r6A7VzZdEQuofvGOZ48MzJuW8AStY6gl121DPa /z4ZZxRqUPP0LfBTj0NiSjXLwXZZnpdQszJ4ifkchuuCK5GkfnNeK1pJcGhI0xgC2GEV RIqWF5427Tp0aiNIi4GW9umSgReAdP0ipKEzpcOm54XdgXspctqDr8jaJGHRkaMSU8uU QNvXv6R4w2a57A5/UbgtdkgVYTMJYPQ3yZbSlSaVmrxD+zfkTZK8QpVUjE/j2qLM4Q4t 5kBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790102921; x=1790707721; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=lIPMuq7W1Pa4X4TXu8rbTxYicHKqL6hnBXo/9p1I/dM=; b=Lt+n+wmePOyloj9/Dpv1UICFLxsKThvO7vNLf0WaELOs5GTdltcf2HUR4rRurtiDQa EJwOWNsPPLbPkDatfqHWdWy1XuFtawnIlKCKQEPaFOEOwTDI6O+FSSUY1LVOFxw23BGZ 1oX9ZKaRquGENxJMQxQ+zXoB4/o+PgQgl/BrTg/bvXNNIXxY0c3Z3WRw/1BO0RtQW1EP B7lzSYy51QIIrC5UbOGZ4mOr2fcMAcPFJSS9GBPxKVMKdJ+cksn0D896jkehNQQbqmNK 2WUH7vNfpvZZrYv8zAz9HCWuIhrEfGgu7OVL2fo/LiQzmEYyZT+aav8wC9n8nZIvhjpx BJng== X-Gm-Message-State: AFuF++kVc15CIXULS5eWKLmRWyuqxzbmfwE+n48XE/XsT40rUXqIj7qP 4OU4qAyLX0k6njODvbwGdEyDUBXwYKlCzJLYui9DLMpXoDGi30DmvqHP X-Gm-Gg: AYBFou0vBm7TKbynaBYhUUFicQzq/I/zRs0tPbCkcl9izFQTIfnUoV7JYVccv02Pj6O 1TJZs2l/2UNIGol45L+EYTQjikIP7CCLc4D5IHgThakn5hbnogtjgA4Q49AWSwkqDAMZJTb8aX9 WecKwxd+ZhoIQTy1pY1lQs68iWpk84PqamusQXH2xNurcBFy6lE17CPAtO6mMGdrjbvu4hpQSKf J4a9JDVh7V9Nt1OtM5qp83Ry0kVsV7nx/HC0H1uYtS1LEurSFjmKWMYo3H6BjYizfn/n5uLE5Sj 86zTnuzjAEa7CMe9cHTFdTw8TXOm9YoMRqCRO6rE0gN/oJBfTheUktEudMxMBOMqSgiuAuqJKWK PY/5cZOhxbl6Bf/5kVPM8JXrYCldWZonV+sbca5Fz5SRryIkyZ4xVw9ItLEjFCxmosYy/Ec6dzN aTjFMNtAHEnezuLzifAxfocYXagKpzWH8E+KXLRIEKQCC/nK6U5A8ufwpX6sGFlGBPA/PLUN5Wn 1Zg35lUKTttOxaVV8+QgP0sCcasG+L+YDgfe8+MAe0MmPueWQk= X-Received: by 2002:a05:600c:138d:b0:49e:73d3:78ab with SMTP id 5b1f17b1804b1-49fdec980c6mr2165765e9.0.1790102921255; Tue, 22 Sep 2026 11:48:41 -0700 (PDT) Message-ID: <6da5569d-8ae8-4388-a407-00b5d2a4bc27@gmail.com> Date: Tue, 22 Sep 2026 20:48:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> <1790096435.8631fc262581453bbf619ec5b2062170.1a0ca0fea6500072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790096435.8631fc262581453bbf619ec5b2062170.1a0ca0fea6500072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1790102921-6DCD34E9-452875B4/10/73395122804 X-purgate-type: spam X-purgate-size: 2917 On 9/22/26 7:00 PM, Baptiste Le Duc wrote: >> During migration of a virtual hart to a different guest interrupt file, >> straggler MSIs from the APLIC could arrive at the old interrupt file >> after the switch. >> >> genmsi is used despite not supporting guest interrupt files because the >> AIA spec guarantees that all MSIs previously sent from the APLIC to the >> same hart are visible at the hart's IMSIC before the extempore MSI from >> genmsi becomes visible. > > >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c >> index 0af13f28e4..cb11d6aeaa 100644 >> --- a/xen/arch/riscv/aplic.c >> +++ b/xen/arch/riscv/aplic.c >> @@ -27,7 +27,9 @@ >> #include >> #include >> #include >> +#include >> #include >> +#include >> >> static struct aplic_priv aplic = { >> .lock = SPIN_LOCK_UNLOCKED, >> @@ -205,6 +207,30 @@ void aplic_hw_write_reg(unsigned int offset, uint32_t value) >> spin_unlock_irqrestore(&aplic.lock, flags); >> } >> >> +/* >> + * As needed, synchronize with all IOMMUs and APLICs to ensure that no >> + * straggler MSIs will arrive at the old interrupt file after this step. >> + */ >> +void aplic_genmsi_barrier(void) >> +{ >> + const struct imsic_config *imsic = imsic_get_config(); >> + unsigned int cpu = smp_processor_id(); >> + unsigned long flags; >> + uint32_t val; >> + >> + val = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >> + (imsic->sync_id & APLIC_TARGET_EIID); > > >> + >> + spin_lock_irqsave(&aplic.lock, flags); >> + >> + writel(val, &aplic.regs->genmsi); >> + >> + while ( readl(&aplic.regs->genmsi) & APLIC_GENMSI_BUSY ) >> + cpu_relax(); >> + >> + spin_unlock_irqrestore(&aplic.lock, flags); >> +} >> + > According to AIA spec §4.9.3 (Synchronizing interactions between a hart and the APLIC), the sequence needs 6 steps; this implements only steps 2-5: > > - Step 1: clear the pending bit for sync_id at the hart's IMSIC before writing genmsi. > - Step 6: after releasing the lock, poll the pending bit for sync_id at the hart's IMSIC until it's set. > > Step 4 (Busy clear) only means the APLIC has accepted/sent the MSI, not that it has arrived at the hart (the spec notes an unspecified travel delay). > Without step 6, aplic_genmsi_barrier() returns before the MSI (and thus prior MSIs) actually reach the hart, so it doesn't achieve the barrier it's meant to > provide. > It is really missed but it exists in riscv-next-upstream branch (https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/imsic.c#L723). I will re-check why it is missed here. Thanks for noticing that. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Sep 22 18:58:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 18:58:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429439.1652314 (Exim 4.92) (envelope-from ) id 1x95hd-0002o5-4G; Tue, 22 Sep 2026 18:58:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429439.1652314; Tue, 22 Sep 2026 18:58:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x95hd-0002ny-1e; Tue, 22 Sep 2026 18:58:53 +0000 Received: by outflank-mailman (input) for mailman id 1429439; Tue, 22 Sep 2026 18:58:52 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x95hb-0002ns-Ry for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 18:58:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x95ha-000dk7-H4 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 20:58:50 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2cfd1-8faa-0a2a0a5109dd-0a2a450bc242-38 for ; Tue, 22 Sep 2026 20:58:50 +0200 Received: from [52.101.72.121] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2cfea-b7e8-0a2a450b0019-3465487985b3-3 for ; Tue, 22 Sep 2026 20:58:50 +0200 Received: from DB5PR03MB10049.eurprd03.prod.outlook.com (2603:10a6:10:4a0::9) by VI0PR03MB10733.eurprd03.prod.outlook.com (2603:10a6:800:264::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Tue, 22 Sep 2026 18:58:45 +0000 Received: from DB5PR03MB10049.eurprd03.prod.outlook.com ([fe80::9240:92cd:d9da:bf9e]) by DB5PR03MB10049.eurprd03.prod.outlook.com ([fe80::9240:92cd:d9da:bf9e%5]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 18:58:45 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oc+ruYOKUoKN7DOXKoh5fm8A+TEg96+hqDUQqPI/7JGcngQ7cHrFCi9UyiK+uanY0OalWKNp60+4M3CjDYF9q4bje7qqHKsuVcVN9PKxGPI2/cr1I7zvcJ3pqzkC7fHHGViBdG1uITJbuhWK4zvytGYeJgOBCX8Fel4953HHB19F0V2nTvytW5BixXNd0KdpayAmDYoaRTO0GLQN4pxeURldvx3CxvfH5wFY/2LM590CeGI/KiL5v6JGA2sQVhbHQHlJiWy5Inw41u1Ca8aVlk3OCApVcOUxK1fditEk4Ro0vLqJgr9ohgwQ/Z5QSI5qRW/PTGTMvZy7iMhQsb9zeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EdID0DFE4HAU7xd8Jz5U0z8FNuSv078dhHif4ac5eZs=; b=xKjLhtMBgc1kiNMX6ZQoblWf8QIuCOmOurhZ2tzYkguYcSZAYhHm9pwMKn2hbdh7Uwmaz/L0rq/gVpF8d9INYIfzSPSpNtzZK3ypw6gttIznaMJuq90mPVTNAJBlj1S2h5nckAV0W88V/ElhEvnWogIf1XffxrXZdM5RyZ6iFXtBxIAzqWTeWd84pXKl3yUAq/q3zYrYPHgyKpA3Sx92HFcrmsSXceUICyDm3m9ElNiPaNwP2PpEk5RP/TxYhZPPpjM95EHwHdQIScvcgFg4K5yLpWW+ERI7zohyoTsTAJXX85sa92QoEOShuCK12hLOAPZIk3qDhQOIFeAsDLUW8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EdID0DFE4HAU7xd8Jz5U0z8FNuSv078dhHif4ac5eZs=; b=gXourLZoYtwzEcC2fsfdrh6Y22nyRxwR7H/Cva0KBKubIOyHdZLTUu+kroWfeAb26KtRrI07FUS+P2uwgGwaHS+pXR7o0wbYaeAgQwa/nEYHvF97892QmB0PSlf7+CN4lWssQBNXo5ERlE+UT7ftr+9UToFx+8xPYQyHg2WBATGMOfHR2V6npd/RnskP6fK1lGQ58N2rcYMfsTP+cAmtFciAs8U1fuqs6dRHnk+Z99ylXdy2OpDYnkqiymUznv9t5+5v3OmB90LREa9Kz0C1QELUflnhkuvvmSpKYoi2jnIod+3O9wBxTq9rfKE6EUK63pbdKZsehRxZh23A9/cprw== From: Leonid Komarianskyi To: "xen-devel@lists.xenproject.org" CC: Leonid Komarianskyi , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Julien Grall Subject: [PATCH v2] xen/arm: gicv3: initialize eSPI unconditionally Thread-Topic: [PATCH v2] xen/arm: gicv3: initialize eSPI unconditionally Thread-Index: AQHdSsRkuuRG4YXur0mlXN3LfWLvYg== Date: Tue, 22 Sep 2026 18:58:45 +0000 Message-ID: <13181424f9be3f5e31977fbd505209cd0508571b.1790102501.git.leonid_komarianskyi@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB5PR03MB10049:EE_|VI0PR03MB10733:EE_ x-ms-office365-filtering-correlation-id: 69e3f00e-ecf5-4ff9-509a-08df18db874e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|38070700021|5023799004|11063799006|6133799003|10067099003|56012099006|18002099003; x-microsoft-antispam-message-info: 9+w/QoSgF3KxjRt0YIgp/Ypdiyg62HN/ebrMvU1vNMlabMVbESzyOkIRrBvDiWUMj7HeNK3L99Q50lrNDrlXZWFH9HTl/H2HhF5BbRpHixoQsxDRSDk5ez0E/0cb5YyoPHS9okMdM9wcntQp8DbICOhngglqwp2aoUaGLag6Y/WbjWUf405j9Grk68Cm3Zbeha1hfsLzSrUakHxH7JMwnSIDDL4SMf729obpfHVCRNbumn2iYn78TDB5Usm13HyPq84xu7eVLm498IR2vYljv5mPoKVc2tFD308bz3mvhHqQa294brnKg4bwkaiTsAkwMNbqQe878iSAEUY/sNL3kqxPYUANSbF4Ou7f8OB3lxEcBzxkAGsHP68rorHo8/9isojNivmuv6xanJcdy5+AVokOxMUMwxZncyjLSDbcX6H1xpsV8isgV26IarEahZVufJ0GwLsHuk0Tyx9DL8mFc0XCbCp+Aiv6VBpy1uYtn/LoKnBNFMlTZh4NhweiULZSTarChuL3z1mYtmTxmvRgo61lguwP0orWbc+cOmeeTvHRbORhwUcOFEUMyl83Wy6/2/GomazO19B4gswjOK1AFTL+G2u0ELpiXGsIek06R6dr8wtuYG6LPxtp8+Yo0Xfk3MggoGReHT2ILzGqYppunL8Krm5KChOxhb7kYo1jMkKGCt/Zqf7PXLvnxx7Ss6C75G0jCRXjKwp7QTIKgy6nlGEPbhSZQIigbi5xTy/DYek= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB5PR03MB10049.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(38070700021)(5023799004)(11063799006)(6133799003)(10067099003)(56012099006)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Q1c1SXJEVFJBU2h2YmUzak5GR2JwT0hwNllhSmdHVmlZaGJPL0RxdjVBaDEx?= =?utf-8?B?YTJYc243RElEQlpMc2pYY2YrTzJ6Yks2ZkdOT2UvNTErd084akF5YlVPSERm?= =?utf-8?B?bE82THFwdTVUdHJJVmo0ZDRkQ05hS0lnMVlIRDhuV0hhZFRmNmZ5dmpweUtT?= =?utf-8?B?U05helJyQ3Npc3htNnh4c2p0Rit4NFkzVmVad3Q4OEVRUDNueDV0MmpjdjFu?= =?utf-8?B?WnBESUFPZ0VrQ3NKVElsQzQ2cVQ0M1NXSk14SkkrMzBWV3ovL1IyMTdHVTFo?= =?utf-8?B?Nkt5aUxvSVQ1dkNJYzV1NG1oZ0MxTFIxclR0ekFtMmtLMWo2R3JiWHFaNGxD?= =?utf-8?B?WWtzMUlwdFVQUUZYRDZEMUo4dDRWTHFPbGlkTjJvVWlOMm43ampDYkhzOU1K?= =?utf-8?B?dXdxRWJ1ZkhSUUt6TVdFaXVBREQvemtpY0k4MkNzMWFoaVJ4N1YyOUFDZW9a?= =?utf-8?B?U0UycDh4a3l4UUFFcUZiS2xMbTJCQzlDbnV6UEI3Vzh5MTE0ZVhBcXhoSGFr?= =?utf-8?B?TXRnL0JYVGVTODZQK0NtUjZNb284aUVtWXZrU0dVVGpFQTJvZDJydktMRHRm?= =?utf-8?B?ajJnZFJ4ZTFVaGFOeFJCcnlEaGgzdjFvUGgwWDN2dkpNdkwxa3lVaHd2K0x1?= =?utf-8?B?TUl6WmJvcnNhMnROdzEyZTI0ZElRcTl0d3VZVW5PR3didzdTbWFOWWYwQ3Vw?= =?utf-8?B?M016V0FEQXZEQWR3S2pmdzk4ZGN2dUZXWTMxWUVaNys2TkF2ZDZLYXJSOGFX?= =?utf-8?B?WWJTYVBHYkptSjBDVzMrSENCTmdCZEtHaUQycWFFU3JPdXcveDFEcVJLZmox?= =?utf-8?B?ZTFmLzJUWGcrcWorZUhpUG83VDRkUnNwaXNCV2JUMy9UV2kvVGtXWDVwWXQ5?= =?utf-8?B?SGU1UHdaWlkwM2kzVTRRbTF4NXVOZnliQ3d6STh0bkoxZ1lTc1ZZTUNWajA1?= =?utf-8?B?cVpKc0JIcmZDM09qU05FU2ttWU5nZy9BS2h5cGcxZ1lsQWdXdElUbVIxUXdG?= =?utf-8?B?ZWJIcmVja0FZOVJmMGhsaUpxekNtWnEyUzZyWFFGSit0cWxzcnV2WjlWMmR2?= =?utf-8?B?MU5QUFJyWjYyNG0xQkM5SUVkWCtrQ0V0VkdrM054aG56Z2ZnVE9VUjIvSS9Z?= =?utf-8?B?b3BPQmxYclNpVzZveWJ0Rmhwajl2amkrbGhGU3FPRmJDZk5HS1gvYTNVQnVK?= =?utf-8?B?NFJyaXQ2Tk5jVnhKQ09KOFVXZE9sQ29nTDVrbCtHaE05cGF5NmNKcU5sb2Zq?= =?utf-8?B?em1ESVNBVnFNZ2N1TDJXZzlXck9ySS9BZlQvd3VISzNpVExISFp4ejNFTGd6?= =?utf-8?B?bU15QXJEUms3SjliUERSWnVMTVgvVDVGa0JGTUpKQmJ2OFJZZXpieWg5TWhB?= =?utf-8?B?T3lQQ0pPZklnWEtLbG5QTGZvYUFnOTIzOEtFdHpodXFZRUtPcjdKVy9lK1Jn?= =?utf-8?B?eWFPclRlSlhDOUl0N3QxMVhoQkVDSnhRcnNvSmlEWTZUaVVIN0llamtlN1dw?= =?utf-8?B?dTRuTW1USE11dEtVRDhiakVZaEU5VVJSamFkOEtKY055dXg3cko2TG13TFNX?= =?utf-8?B?Z3cwUnlGRUdZT0Vwa2Vra3M3NkQ0bEdaRkZwQTE0QlRxM0VBbUJCc25EUkc5?= =?utf-8?B?UDllSDhvZHQxaGxETVFBTFhxRUtKN2RYMDYxU21SQjJvZ042SDcxbkN3Rk41?= =?utf-8?B?VjBWWFpMRjFwVzlCa1BON1BOTEZVZXF5OEtvNUhUcDN6UnpUVTh6eFNHZFN3?= =?utf-8?B?MmxDQnN4TnVIRERWQUtQVlRKYXlpYVYyVHQ4ejZvcURkVmpVS2pOSGpGOXFB?= =?utf-8?B?UUI5Y2ZBUzVZUmdIYVNLNWtIZXRpWEpOQXZEM3NSM3lIcnFDeFIvMldZekE5?= =?utf-8?B?U2ZQZyt0Vng4YUV1cUM5STRwcnB4dzNuaDhiZEwrb0d2OU5RTnhiQ3lTOXNV?= =?utf-8?B?Rm9WMjdveFFrdXpwNFR3NCtlZWlvQm1YOVBkQ0EzK01Sc2ZQekZIK0JNVjFo?= =?utf-8?B?L09jcS9xa0VwaFF6WUY3V2ZFdzU1V2Y5cVFnSHRvYzJTcmc4SUFMV1N2VHg4?= =?utf-8?B?M1pDbEhQUWtTSGZkc3B4clZhSjBISzBRTmN3WDNyTkxTcmJDb29JTjRRTkkw?= =?utf-8?B?anYvYmtYcHFYV0x5ZVhjclBWMVVkS3hVbmZoWTlGbzNIUWlIOW55Rnk1N1lU?= =?utf-8?B?YTd1dk8rZlEwV2s2SDRhQ09Tc05NeTdrSjRGZXh5Y3pDUVE1alRNY1VYbUxG?= =?utf-8?B?b3NNK2Z4VXlTNFIzZ0hINDI4c2NqYmF1dHhZRWo2ZnEzZ0NWUU1TQUNSc3h5?= =?utf-8?B?WWNsdzcxZ0M3Q1M1aWRLVWQ5MGw2cmZoTGpLQis0cHJCK2R6NElHQTN2R2xa?= =?utf-8?Q?xx56xycrgfwhCGd4=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB5PR03MB10049.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69e3f00e-ecf5-4ff9-509a-08df18db874e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 18:58:45.6296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WHeOxv4HEkWsIkbx/Dtm+Xg/NU3cmg4otoN2uHha6oGzMpXJRXY5Z6V6V5Z7xAtCc4mWqfc1Sj0zlfwpd6WzMzXy7auXtLVOGu7oyUmkkDc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10733 X-purgate-ID: tlsNG-42698a/1790103530-AA0C59EA-3A0C6932/0/0 X-purgate-type: clean X-purgate-size: 5842 U2luY2UgdGhlIGZpcm13YXJlIG1heSBpbml0aWFsaXplIGVTUElzIGJlZm9yZSBYZW4sIGFuZCB3 aXRob3V0DQpDT05GSUdfR0lDVjNfRVNQSSBlbmFibGVkLCBYZW4gd291bGQgbm90IHJlaW5pdGlh bGl6ZSB0aGVtIHByb3Blcmx5DQpkdXJpbmcgYm9vdC4gSW4gc3VjaCBjYXNlcywgb25jZSB0aGUg R0lDIGlzIHJlLWVuYWJsZWQgaW4gWGVuLA0KaW50ZXJydXB0cyBtYXkgYmUgcmVjZWl2ZWQgdGhh dCBjYW5ub3QgYmUgaGFuZGxlZC4NCg0KVG8gZW5zdXJlIHByb3BlciBvcGVyYXRpb24gb24gaGFy ZHdhcmUgd2l0aCBlU1BJIGZlYXR1cmUsIGV2ZW4gd2hlbiB0aGUgZVNQSQ0KY29uZmlnIGlzIGRp c2FibGVkLCBnaWN2M19kaXN0X2VzcGlfY29tbW9uX2luaXQoKSBzaG91bGQgYmUgaW52b2tlZA0K cmVnYXJkbGVzcyBvZiB3aGV0aGVyIENPTkZJR19HSUNWM19FU1BJIGlzIGVuYWJsZWQgb3Igbm90 LiBUaGlzIHdpbGwgbm90DQphZmZlY3QgaGFyZHdhcmUgd2l0aG91dCBlU1BJIHN1cHBvcnQsIGFz IHRoZSBmdW5jdGlvbiBjaGVja3MgaWYgdGhlDQpoYXJkd2FyZSBzdXBwb3J0cyBlU1BJcyBieSBy ZWFkaW5nIHRoZSBHSUNEX1RZUEVSLkVTUEkgZmllbGQgKHVzaW5nDQpHSUNEX1RZUEVSX0VTUElT X05VTSBtYWNybyksIHdoaWNoIGluZGljYXRlcyB3aGV0aGVyIHRoZSBleHRlbmRlZCBTUEkNCnJh bmdlIGlzIHN1cHBvcnRlZC4gSWYgdGhlIGhhcmR3YXJlIGRvZXMgbm90IHN1cHBvcnQgZVNQSSwg dGhlIGZ1bmN0aW9uDQp3aWxsIG5vdCBwZXJmb3JtIGFueSBhY3Rpb25zLg0KDQpUaGVyZSBhcmUg bm8gZnVuY3Rpb25hbCBjaGFuZ2VzIGZvciBzZXR1cHMgd2hlcmUgQ09ORklHX0dJQ1YzX0VTUEk9 eS4NCg0KU3VnZ2VzdGVkLWJ5OiBKdWxpZW4gR3JhbGwgPGpncmFsbEBhbWF6b24uY29tPg0KU2ln bmVkLW9mZi1ieTogTGVvbmlkIEtvbWFyaWFuc2t5aSA8bGVvbmlkX2tvbWFyaWFuc2t5aUBlcGFt LmNvbT4NCkFja2VkLWJ5OiBKdWxpZW4gR3JhbGwgPGpncmFsbEBhbWF6b24uY29tPg0KLS0tDQpD aGFuZ2VzIGluIHYyOg0KLSByZWJhc2VkIG9uIHRoZSBjdXJyZW50IHN0YWdpbmcNCi0gcGxhY2Vk IFN1Z2dlc3RlZC1ieSB0YWcgZmlyc3QgdG8ga2VlcCB0YWdzIGluIGNocm9ub2xvZ2ljYWwgb3Jk ZXINCi0gYWRkZWQgQWNrZWQtYnkgZnJvbSBKdWxpZW4gR3JhbGwNCg0KVGhpcyBpcyBhIGZvbGxv dy11cCBwYXRjaCByZWxhdGVkIHRvIHRoZSBkaXNjdXNzaW9uOg0KaHR0cHM6Ly9sb3JlLmtlcm5l bC5vcmcveGVuLWRldmVsLzgyMDcwNGQwLTQwNDctNGYwMi1hMDU4LTAxZGFiYTI3NjVmMUB4ZW4u b3JnLw0KDQpTZW5kaW5nIHYyIHdpdGggdGhlIHJlcXVlc3RlZCBjaGFuZ2VzLCBhcyBJIG9ubHkg bm93IG5vdGljZWQNCnRoYXQgdGhpcyBwYXRjaCBoYXMgbm90IGJlZW4gbWVyZ2VkIHlldC4NCi0t LQ0KIHhlbi9hcmNoL2FybS9naWMtdjMuYyAgICAgICAgICAgICAgICAgIHwgMzIgKysrKysrKysr KysrKystLS0tLS0tLS0tLS0NCiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljX3YzX2RlZnMu aCB8ICAyIC0tDQogMiBmaWxlcyBjaGFuZ2VkLCAxNyBpbnNlcnRpb25zKCspLCAxNyBkZWxldGlv bnMoLSkNCg0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9naWMtdjMuYyBiL3hlbi9hcmNoL2Fy bS9naWMtdjMuYw0KaW5kZXggYWNkYWMyMjk1My4uNDYzNzY5ZDc3YiAxMDA2NDQNCi0tLSBhL3hl bi9hcmNoL2FybS9naWMtdjMuYw0KKysrIGIveGVuL2FyY2gvYXJtL2dpYy12My5jDQpAQCAtNzAz LDE3ICs3MDMsMzIgQEAgdW5zaWduZWQgaW50IGdpY19udW1iZXJfZXNwaXModm9pZCkNCiAgICAg cmV0dXJuIGdpY19od19vcHMtPmluZm8tPm5yX2VzcGk7DQogfQ0KIA0KK3N0YXRpYyB2b2lkIF9f aW5pdCBnaWN2M19kaXN0X2VzcGlfaW5pdF9hZmYodWludDY0X3QgYWZmaW5pdHkpDQorew0KKyAg ICB1bnNpZ25lZCBpbnQgaTsNCisNCisgICAgZm9yICggaSA9IDA7IGkgPCBnaWN2M19pbmZvLm5y X2VzcGk7IGkrKyApDQorICAgICAgICB3cml0ZXFfcmVsYXhlZF9ub25fYXRvbWljKGFmZmluaXR5 LCBHSUNEICsgR0lDRF9JUk9VVEVSbkUgKyBpICogOCk7DQorfQ0KKyNlbHNlDQorDQorc3RhdGlj IHZvaWQgX19pbml0IGdpY3YzX2Rpc3RfZXNwaV9pbml0X2FmZih1aW50NjRfdCBhZmZpbml0eSkg eyB9DQorI2VuZGlmDQorDQogc3RhdGljIHZvaWQgX19pbml0IGdpY3YzX2Rpc3RfZXNwaV9jb21t b25faW5pdCh1aW50MzJfdCB0eXBlKQ0KIHsNCiAgICAgdW5zaWduZWQgaW50IGVzcGlfbnIsIGk7 DQogDQogICAgIGVzcGlfbnIgPSBtaW4oMTAyNFUsIEdJQ0RfVFlQRVJfRVNQSVNfTlVNKHR5cGUp KTsNCisjaWZkZWYgQ09ORklHX0dJQ1YzX0VTUEkNCiAgICAgZ2ljdjNfaW5mby5ucl9lc3BpID0g ZXNwaV9ucjsNCisjZW5kaWYNCiAgICAgLyogVGhlIEdJQyBIVyBkb2Vzbid0IHN1cHBvcnQgZVNQ SSwgc28gd2UgY2FuIGxlYXZlIGZyb20gaGVyZSAqLw0KLSAgICBpZiAoIGdpY3YzX2luZm8ubnJf ZXNwaSA9PSAwICkNCisgICAgaWYgKCBlc3BpX25yID09IDAgKQ0KICAgICAgICAgcmV0dXJuOw0K IA0KLSAgICBwcmludGsoIkdJQ3YzOiAldSBlU1BJIGxpbmVzXG4iLCBnaWN2M19pbmZvLm5yX2Vz cGkpOw0KKyAgICBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0dJQ1YzX0VTUEkpICkNCisgICAgICAg IHByaW50aygiR0lDdjM6ICV1IGVTUEkgbGluZXNcbiIsIGVzcGlfbnIpOw0KIA0KICAgICAvKiBU aGUgY29uZmlndXJhdGlvbiBmb3IgZVNQSXMgaXMgc2ltaWxhciB0byB0aGF0IGZvciByZWd1bGFy IFNQSXMgKi8NCiAgICAgZm9yICggaSA9IDA7IGkgPCBlc3BpX25yOyBpICs9IDE2ICkNCkBAIC03 MzMsMTkgKzc0OCw2IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBnaWN2M19kaXN0X2VzcGlfY29tbW9u X2luaXQodWludDMyX3QgdHlwZSkNCiAgICAgICAgIHdyaXRlbF9yZWxheGVkKEdFTk1BU0soMzEs IDApLCBHSUNEICsgR0lDRF9JR1JPVVBSbkUgKyAoaSAvIDMyKSAqIDQpOw0KIH0NCiANCi1zdGF0 aWMgdm9pZCBfX2luaXQgZ2ljdjNfZGlzdF9lc3BpX2luaXRfYWZmKHVpbnQ2NF90IGFmZmluaXR5 KQ0KLXsNCi0gICAgdW5zaWduZWQgaW50IGk7DQotDQotICAgIGZvciAoIGkgPSAwOyBpIDwgZ2lj djNfaW5mby5ucl9lc3BpOyBpKysgKQ0KLSAgICAgICAgd3JpdGVxX3JlbGF4ZWRfbm9uX2F0b21p YyhhZmZpbml0eSwgR0lDRCArIEdJQ0RfSVJPVVRFUm5FICsgaSAqIDgpOw0KLX0NCi0jZWxzZQ0K LXN0YXRpYyB2b2lkIF9faW5pdCBnaWN2M19kaXN0X2VzcGlfY29tbW9uX2luaXQodWludDMyX3Qg dHlwZSkgeyB9DQotDQotc3RhdGljIHZvaWQgX19pbml0IGdpY3YzX2Rpc3RfZXNwaV9pbml0X2Fm Zih1aW50NjRfdCBhZmZpbml0eSkgeyB9DQotI2VuZGlmDQotDQogc3RhdGljIHZvaWQgX19pbml0 IGdpY3YzX2Rpc3RfaW5pdCh2b2lkKQ0KIHsNCiAgICAgdWludDMyX3QgdHlwZTsNCmRpZmYgLS1n aXQgYS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZ2ljX3YzX2RlZnMuaCBiL3hlbi9hcmNoL2Fy bS9pbmNsdWRlL2FzbS9naWNfdjNfZGVmcy5oDQppbmRleCAzNzE0Y2ZlYjdkLi4yMDgxYjJmZThm IDEwMDY0NA0KLS0tIGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2dpY192M19kZWZzLmgNCisr KyBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9naWNfdjNfZGVmcy5oDQpAQCAtNjMsNyArNjMs NiBAQA0KICNkZWZpbmUgR0lDRF9JUk9VVEVSbkUgICAgICAgICAgICAgICAoMHg4MDAwKQ0KICNk ZWZpbmUgR0lDRF9JUk9VVEVSbkVOICAgICAgICAgICAgICAoMHg5RkZDKQ0KIA0KLSNpZmRlZiBD T05GSUdfR0lDVjNfRVNQSQ0KICNkZWZpbmUgR0lDRF9UWVBFUl9FU1BJX1NISUZUICAgICAgICA4 DQogI2RlZmluZSBHSUNEX1RZUEVSX0VTUElfUkFOR0VfU0hJRlQgIDI3DQogI2RlZmluZSBHSUNE X1RZUEVSX0VTUElfUkFOR0VfTUFTSyAgICgweDFGKQ0KQEAgLTczLDcgKzcyLDYgQEANCiAjZGVm aW5lIEdJQ0RfVFlQRVJfRVNQSVNfTlVNKHR5cGVyKSAgICBcDQogICAgICAgICAoKCh0eXBlcikg JiBHSUNEX1RZUEVSX0VTUEkpID8gXA0KICAgICAgICAgR0lDRF9UWVBFUl9FU1BJX1JBTkdFKCh0 eXBlcikgPj4gR0lDRF9UWVBFUl9FU1BJX1JBTkdFX1NISUZUKSA6IDApDQotI2VuZGlmDQogDQog LyogQ29tbW9uIGJldHdlZW4gR0lDRF9QSURSMiBhbmQgR0lDUl9QSURSMiAqLw0KICNkZWZpbmUg R0lDX1BJRFIyX0FSQ0hfTUFTSyAgICAgICAgICgweGYwKQ0KLS0gDQoyLjM0LjENCg== From xen-devel-bounces@lists.xenproject.org Tue Sep 22 20:24:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 20:24:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429471.1652323 (Exim 4.92) (envelope-from ) id 1x972V-0003sI-26; Tue, 22 Sep 2026 20:24:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429471.1652323; Tue, 22 Sep 2026 20:24:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x972U-0003sB-VR; Tue, 22 Sep 2026 20:24:30 +0000 Received: by outflank-mailman (input) for mailman id 1429471; Tue, 22 Sep 2026 20:24:29 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x972S-0003s5-W1 for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 20:24:29 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x972R-00BPgi-Mt for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 22:24:27 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2e3fb-2eae-0a2a0a5409dd-0a2a4508b96e-0 for ; Tue, 22 Sep 2026 22:24:27 +0200 Received: from [170.10.133.124] (helo=us-smtp-delivery-124.mimecast.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2e3f5-f659-0a2a45080019-aa0a857cda23-3 for ; Tue, 22 Sep 2026 22:24:22 +0200 Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-684-Ljz03s7FNHWwafDBITVPiw-1; Tue, 22 Sep 2026 16:24:17 -0400 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 28C9C19772E4; Tue, 22 Sep 2026 20:24:16 +0000 (UTC) Received: from localhost (headnet03.pony-001.prod.iad2.dc.redhat.com [10.2.32.114]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 5100141D; Tue, 22 Sep 2026 20:24:13 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=mimecast20190719 header.d=redhat.com header.i="@redhat.com" header.h="From:Subject:Date:Message-Id:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1790108661; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ArBsudPGq56rGaGjJckWrplo0/hGiKQk5vOivYLgX9k=; b=QIsZgVeuuzl2ZhjQwuC/Ev2xRT58M/N7eE3GyQ2PPEj97XWOBxLhTCzf5CsY9pKGxyykX4 z6FWOxTu+0pX+b/4zC8XGk+KDtJrgYL02t9+2A3kHbNlntRyT/WL+QNPBwAQ5YbkBSK5EM 4F2WcO4yumsE7YO4QyZ8GK1uAgTE4/4= X-MC-Unique: Ljz03s7FNHWwafDBITVPiw-1 X-Mimecast-MFC-AGG-ID: Ljz03s7FNHWwafDBITVPiw_1790108656 From: =?utf-8?q?Marc-Andr=C3=A9_Lureau?= Date: Wed, 23 Sep 2026 00:18:32 +0400 Subject: [PATCH 85/88] qdev: add x-query-qtree QMP command MIME-Version: 1.0 Message-Id: <20260923-nohmp-v1-85-ebc029d4bd80@redhat.com> References: <20260923-nohmp-v1-0-ebc029d4bd80@redhat.com> In-Reply-To: <20260923-nohmp-v1-0-ebc029d4bd80@redhat.com> To: qemu-devel@nongnu.org Cc: Kevin Wolf , =?utf-8?q?Marc-Andr=C3=A9_Lureau?= , "Michael S. Tsirkin" , Laurent Vivier , Amit Shah , Paolo Bonzini , =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= , Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Eric Blake , Markus Armbruster , xen-devel@lists.xenproject.org, qemu-rust@nongnu.org X-Developer-Signature: v=1; a=openpgp-sha256; l=22716; i=marcandre.lureau@redhat.com; h=from:subject:message-id; bh=kgwmlhrAVDXi4XANRljYDT/ER4YlpkwkFlzObaLlJCI=; b=owEBbQKS/ZANAwAKAdro4Ql1lpzlAcsmYgBqsuK0thVU45gjDBEnQecKc50CZGgIu1NnS+HpQ rZ5RvqAZ+eJAjMEAAEKAB0WIQSHqb2TP4fGBtJ29i3a6OEJdZac5QUCarLitAAKCRDa6OEJdZac 5b9tD/4kNJbyz4x+KPGlvhyk8IVrVHJKZHe5UYHPfmbGRKG3E/CkRpYoSW1VZREd5AXbD30foTk uH2iuDdZSIVyKgvaXZ7nI5VUgdRygOG4goAHwzLFHxxhq3Vclj4UBupzOvP0tPftLwnrGsOF4+p TYYtzzoFntv8G+lZZandIG3ufOMhbd+YxevKBYq3enEueT7AqZQZZ1ASg38GYKqxTaqtcj3gQ/p 13tMoUCCnxkpLfRr9R3+4ZYMWXoaE9ORpoiK8yxM22Esgy4mTBrQxYpib+lhhY4TtgsuBa0YIqV soeVaFz8aT2ePEv3xAjpVz6sIj6WqNFoQF2DN/9t7Z0AtT3InmQKtWd3YgA9zKYYwRcJYyR6x3m 8Fk/M4VVDAweUT4vsJc1/PgrRp+Ll66Rhe/Xc2Vcmi0sy8Fu5zhpXlE2gid+F5Cxo8sn5E1Sz9D 8XSclNJ44UE1JsizmaE27ACxJM73V4DHmoQap/RElPzw3KQ/HzT2/UShIHIUqzEwTWCaBgoNn7r hQbqa9uiSvX4TpmFSQ3JFg9RaqcKlNJaZKIi7sjB042G13pfc52ZVxT2zvSzculhKrJxk5Wza5U hnukq7c231Kr1MQI6F87bTKMT7GXKQrxiJah4/1xyrbK9ZfTjfo+yDV7uv0DZpTujvcd7Ht/igg DtXX3YvV6KvoVZg== X-Developer-Key: i=marcandre.lureau@redhat.com; a=openpgp; fpr=87A9BD933F87C606D276F62DDAE8E10975969CE5 X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 X-Mimecast-MFC-PROC-ID: rwj2S0dtMkQfFOHf-l19XsiugOfoLzfkG1or5F3ApqI_1790108656 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790108667-D457487B-72E35ECC/0/0 X-purgate-type: clean X-purgate-size: 22718 Add x-query-qtree QMP command returning HumanReadableText with the device tree. Supports an optional "brief" parameter to omit device properties, matching the -b flag of "info qtree". Refactor the BusClass print_dev callback and qbus_print/qdev_print functions to write to a GString buffer instead of requiring a Monitor, so the QMP command can collect the output directly without needing monitor internals. Rewire hmp_info_qtree to use the new QMP command. Eventually, qom-list and properties retrieval should be enhanced to do tree traversal and make this pretty-printing method obsolete and return structured data instead. Signed-off-by: Marc-André Lureau --- hw/char/virtio-serial-bus.c | 23 ++++++++-------------- hw/core/sysbus.c | 17 +++++------------ hw/misc/auxbus.c | 22 ++++++++------------- hw/pci/pci-hmp-cmds.c | 38 ------------------------------------- hw/pci/pci-internal.h | 2 +- hw/pci/pci.c | 40 +++++++++++++++++++++++++++++++++++++-- hw/usb/bus.c | 23 ++++++++-------------- hw/xen/xen-bus.c | 12 +++--------- include/hw/core/qdev.h | 4 +--- qapi/qdev.json | 31 ++++++++++++++++++++++++++++++ rust/bindings/hwcore-sys/lib.rs | 2 +- system/qdev-monitor.c | 42 +++++++++++++++++++++++++++-------------- 12 files changed, 132 insertions(+), 124 deletions(-) diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c index c36e18a4cfb5..af438316f1a4 100644 --- a/hw/char/virtio-serial-bus.c +++ b/hw/char/virtio-serial-bus.c @@ -24,8 +24,6 @@ #include "qemu/main-loop.h" #include "qemu/module.h" #include "migration/qemu-file-types.h" -#include "monitor/monitor.h" -#include "monitor/hmp.h" #include "qemu/error-report.h" #include "qemu/queue.h" #include "hw/core/qdev-properties.h" @@ -818,9 +816,7 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f, return 0; } -#ifdef CONFIG_HMP -static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent); -#endif +static void virtser_bus_dev_print(GString *buf, DeviceState *qdev, int indent); static const Property virtser_props[] = { DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID), @@ -829,10 +825,8 @@ static const Property virtser_props[] = { static void virtser_bus_class_init(ObjectClass *klass, const void *data) { -#ifdef CONFIG_HMP BusClass *k = BUS_CLASS(klass); k->print_dev = virtser_bus_dev_print; -#endif } static const TypeInfo virtser_bus_info = { @@ -842,18 +836,17 @@ static const TypeInfo virtser_bus_info = { .class_init = virtser_bus_class_init, }; -#ifdef CONFIG_HMP -static void virtser_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent) +static void virtser_bus_dev_print(GString *buf, DeviceState *qdev, int indent) { VirtIOSerialPort *port = VIRTIO_SERIAL_PORT(qdev); - monitor_hmp_printf(hmp, "%*sport %d, guest %s, host %s, throttle %s\n", - indent, "", port->id, - port->guest_connected ? "on" : "off", - port->host_connected ? "on" : "off", - port->throttled ? "on" : "off"); + g_string_append_printf(buf, + "%*sport %d, guest %s, host %s, throttle %s\n", + indent, "", port->id, + port->guest_connected ? "on" : "off", + port->host_connected ? "on" : "off", + port->throttled ? "on" : "off"); } -#endif /* This function is only used if a port id is not provided by the user */ static uint32_t find_free_port_id(VirtIOSerial *vser) diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c index fe8f867a8d9c..3a5fd52192d8 100644 --- a/hw/core/sysbus.c +++ b/hw/core/sysbus.c @@ -20,13 +20,9 @@ #include "qemu/osdep.h" #include "qapi/error.h" #include "hw/core/sysbus.h" -#include "monitor/monitor.h" -#include "monitor/hmp.h" #include "system/address-spaces.h" -#ifdef CONFIG_HMP -static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent); -#endif +static void sysbus_dev_print(GString *buf, DeviceState *dev, int indent); static char *sysbus_get_fw_dev_path(DeviceState *dev); typedef struct SysBusFind { @@ -78,9 +74,7 @@ static void system_bus_class_init(ObjectClass *klass, const void *data) { BusClass *k = BUS_CLASS(klass); -#ifdef CONFIG_HMP k->print_dev = sysbus_dev_print; -#endif k->get_fw_dev_path = sysbus_get_fw_dev_path; } @@ -253,8 +247,7 @@ bool sysbus_realize_and_unref(SysBusDevice *dev, Error **errp) return qdev_realize_and_unref(DEVICE(dev), sysbus_get_default(), errp); } -#ifdef CONFIG_HMP -static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent) +static void sysbus_dev_print(GString *buf, DeviceState *dev, int indent) { SysBusDevice *s = SYS_BUS_DEVICE(dev); hwaddr size; @@ -262,11 +255,11 @@ static void sysbus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent) for (i = 0; i < s->num_mmio; i++) { size = memory_region_size(s->mmio[i].memory); - monitor_hmp_printf(hmp, "%*smmio " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n", - indent, "", s->mmio[i].addr, size); + g_string_append_printf(buf, "%*smmio " + HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n", + indent, "", s->mmio[i].addr, size); } } -#endif static char *sysbus_get_fw_dev_path(DeviceState *dev) { diff --git a/hw/misc/auxbus.c b/hw/misc/auxbus.c index 3f17784d9b8a..17033433147a 100644 --- a/hw/misc/auxbus.c +++ b/hw/misc/auxbus.c @@ -32,8 +32,6 @@ #include "qemu/module.h" #include "hw/misc/auxbus.h" #include "hw/i2c/i2c.h" -#include "monitor/monitor.h" -#include "monitor/hmp.h" #include "qapi/error.h" #ifndef DEBUG_AUX @@ -47,22 +45,18 @@ } while (0) -#ifdef CONFIG_HMP -static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent); -#endif +static void aux_slave_dev_print(GString *buf, DeviceState *dev, int indent); static inline I2CBus *aux_bridge_get_i2c_bus(AUXTOI2CState *bridge); /* aux-bus implementation (internal not public) */ static void aux_bus_class_init(ObjectClass *klass, const void *data) { -#ifdef CONFIG_HMP BusClass *k = BUS_CLASS(klass); /* AUXSlave has an MMIO so we need to change the way we print information * in monitor. */ k->print_dev = aux_slave_dev_print; -#endif } AUXBus *aux_bus_init(DeviceState *parent, const char *name) @@ -287,13 +281,12 @@ static const TypeInfo aux_to_i2c_type_info = { }; /* aux-slave implementation */ -#ifdef CONFIG_HMP static bool aux_bus_is_bridge(AUXBus *bus, DeviceState *dev) { return (dev == DEVICE(bus->bridge)); } -static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent) +static void aux_slave_dev_print(GString *buf, DeviceState *dev, int indent) { AUXBus *bus = AUX_BUS(qdev_get_parent_bus(dev)); AUXSlave *s; @@ -305,12 +298,13 @@ static void aux_slave_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent) s = AUX_SLAVE(dev); - monitor_hmp_printf(hmp, "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n", - indent, "", - object_property_get_uint(OBJECT(s->mmio), "addr", NULL), - memory_region_size(s->mmio)); + g_string_append_printf(buf, + "%*smemory " HWADDR_FMT_plx "/" HWADDR_FMT_plx "\n", + indent, "", + object_property_get_uint(OBJECT(s->mmio), + "addr", NULL), + memory_region_size(s->mmio)); } -#endif void aux_init_mmio(AUXSlave *aux_slave, MemoryRegion *mmio) { diff --git a/hw/pci/pci-hmp-cmds.c b/hw/pci/pci-hmp-cmds.c index 879011da1384..776762f18fa5 100644 --- a/hw/pci/pci-hmp-cmds.c +++ b/hw/pci/pci-hmp-cmds.c @@ -135,44 +135,6 @@ void hmp_info_pci(MonitorHMP *hmp, const QDict *qdict) qapi_free_PciInfoList(info_list); } -#ifdef CONFIG_HMP -void pcibus_dev_print(MonitorHMP *hmp, DeviceState *dev, int indent) -{ - PCIDevice *d = (PCIDevice *)dev; - int class = pci_get_word(d->config + PCI_CLASS_DEVICE); - const pci_class_desc *desc = get_class_desc(class); - char ctxt[64]; - PCIIORegion *r; - int i; - - if (desc->desc) { - snprintf(ctxt, sizeof(ctxt), "%s", desc->desc); - } else { - snprintf(ctxt, sizeof(ctxt), "Class %04x", class); - } - - monitor_hmp_printf(hmp, "%*sclass %s, addr %02x:%02x.%x, " - "pci id %04x:%04x (sub %04x:%04x)\n", - indent, "", ctxt, pci_dev_bus_num(d), - PCI_SLOT(d->devfn), PCI_FUNC(d->devfn), - pci_get_word(d->config + PCI_VENDOR_ID), - pci_get_word(d->config + PCI_DEVICE_ID), - pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID), - pci_get_word(d->config + PCI_SUBSYSTEM_ID)); - for (i = 0; i < PCI_NUM_REGIONS; i++) { - r = &d->io_regions[i]; - if (!r->size) { - continue; - } - monitor_hmp_printf(hmp, "%*sbar %d: %s at 0x%"FMT_PCIBUS - " [0x%"FMT_PCIBUS"]\n", - indent, "", - i, r->type & PCI_BASE_ADDRESS_SPACE_IO ? "i/o" : "mem", - r->addr, r->addr + r->size - 1); - } -} -#endif - void hmp_pcie_aer_inject_error(MonitorHMP *hmp, const QDict *qdict) { Error *err = NULL; diff --git a/hw/pci/pci-internal.h b/hw/pci/pci-internal.h index b7231fab5dc9..68a169488d09 100644 --- a/hw/pci/pci-internal.h +++ b/hw/pci/pci-internal.h @@ -16,7 +16,7 @@ extern PCIHostStateList pci_host_bridges; const pci_class_desc *get_class_desc(int class); PCIBus *pci_find_bus_nr(PCIBus *bus, int bus_num); -void pcibus_dev_print(MonitorHMP *mon, DeviceState *dev, int indent); +void pcibus_dev_print(GString *buf, DeviceState *dev, int indent); int pcie_aer_parse_error_string(const char *error_name, uint32_t *status, bool *correctable); diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 0efb4eb4bb03..433568440853 100644 --- a/hw/pci/pci.c +++ b/hw/pci/pci.c @@ -293,9 +293,7 @@ static void pci_bus_class_init(ObjectClass *klass, const void *data) ResettableClass *rc = RESETTABLE_CLASS(klass); FWCfgDataGeneratorClass *fwgc = FW_CFG_DATA_GENERATOR_CLASS(klass); -#ifdef CONFIG_HMP k->print_dev = pcibus_dev_print; -#endif k->get_dev_path = pcibus_get_dev_path; k->get_fw_dev_path = pcibus_get_fw_dev_path; k->realize = pci_bus_realize; @@ -2094,6 +2092,44 @@ const pci_class_desc *get_class_desc(int class) return desc; } +void pcibus_dev_print(GString *buf, DeviceState *dev, int indent) +{ + PCIDevice *d = (PCIDevice *)dev; + int class = pci_get_word(d->config + PCI_CLASS_DEVICE); + const pci_class_desc *desc = get_class_desc(class); + char ctxt[64]; + PCIIORegion *r; + int i; + + if (desc->desc) { + snprintf(ctxt, sizeof(ctxt), "%s", desc->desc); + } else { + snprintf(ctxt, sizeof(ctxt), "Class %04x", class); + } + + g_string_append_printf(buf, "%*sclass %s, addr %02x:%02x.%x, " + "pci id %04x:%04x (sub %04x:%04x)\n", + indent, "", ctxt, pci_dev_bus_num(d), + PCI_SLOT(d->devfn), PCI_FUNC(d->devfn), + pci_get_word(d->config + PCI_VENDOR_ID), + pci_get_word(d->config + PCI_DEVICE_ID), + pci_get_word(d->config + PCI_SUBSYSTEM_VENDOR_ID), + pci_get_word(d->config + PCI_SUBSYSTEM_ID)); + for (i = 0; i < PCI_NUM_REGIONS; i++) { + r = &d->io_regions[i]; + if (!r->size) { + continue; + } + g_string_append_printf(buf, "%*sbar %d: %s at 0x%"FMT_PCIBUS + " [0x%"FMT_PCIBUS"]\n", + indent, "", + i, + r->type & PCI_BASE_ADDRESS_SPACE_IO + ? "i/o" : "mem", + r->addr, r->addr + r->size - 1); + } +} + void pci_init_nic_devices(PCIBus *bus, const char *default_model) { qemu_create_nic_bus_devices(&bus->qbus, TYPE_PCI_DEVICE, default_model, diff --git a/hw/usb/bus.c b/hw/usb/bus.c index 5cc5ffec33a1..c6d65274771f 100644 --- a/hw/usb/bus.c +++ b/hw/usb/bus.c @@ -8,14 +8,10 @@ #include "qemu/module.h" #include "system/system.h" #include "migration/vmstate.h" -#include "monitor/monitor.h" -#include "monitor/hmp.h" #include "trace.h" #include "qemu/cutils.h" -#ifdef CONFIG_HMP -static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent); -#endif +static void usb_bus_dev_print(GString *buf, DeviceState *qdev, int indent); static char *usb_get_dev_path(DeviceState *dev); static char *usb_get_fw_dev_path(DeviceState *qdev); @@ -34,9 +30,7 @@ static void usb_bus_class_init(ObjectClass *klass, const void *data) BusClass *k = BUS_CLASS(klass); HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass); -#ifdef CONFIG_HMP k->print_dev = usb_bus_dev_print; -#endif k->get_dev_path = usb_get_dev_path; k->get_fw_dev_path = usb_get_fw_dev_path; hc->unplug = qdev_simple_device_unplug_cb; @@ -548,19 +542,18 @@ static const char *usb_speed(unsigned int speed) return txt[speed]; } -#ifdef CONFIG_HMP -static void usb_bus_dev_print(MonitorHMP *hmp, DeviceState *qdev, int indent) +static void usb_bus_dev_print(GString *buf, DeviceState *qdev, int indent) { USBDevice *dev = USB_DEVICE(qdev); USBBus *bus = usb_bus_from_device(dev); - monitor_hmp_printf(hmp, "%*saddr %d.%d, port %s, speed %s, name %s%s\n", - indent, "", bus->busnr, dev->addr, - dev->port ? dev->port->path : "-", - usb_speed(dev->speed), dev->product_desc, - dev->attached ? ", attached" : ""); + g_string_append_printf(buf, + "%*saddr %d.%d, port %s, speed %s, name %s%s\n", + indent, "", bus->busnr, dev->addr, + dev->port ? dev->port->path : "-", + usb_speed(dev->speed), dev->product_desc, + dev->attached ? ", attached" : ""); } -#endif static char *usb_get_dev_path(DeviceState *qdev) { diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c index 8def3bb68bc6..cc98034230e8 100644 --- a/hw/xen/xen-bus.c +++ b/hw/xen/xen-bus.c @@ -16,8 +16,6 @@ #include "hw/xen/xen-legacy-backend.h" /* xen_be_init() */ #include "hw/xen/xen-bus.h" #include "hw/xen/xen-bus-helper.h" -#include "monitor/monitor.h" -#include "monitor/hmp.h" #include "qapi/error.h" #include "qobject/qdict.h" #include "system/system.h" @@ -101,15 +99,13 @@ abort: qemu_xen_xs_transaction_end(xenbus->xsh, tid, true); } -#ifdef CONFIG_HMP -static void xen_bus_print_dev(MonitorHMP *hmp, DeviceState *dev, int indent) +static void xen_bus_print_dev(GString *buf, DeviceState *dev, int indent) { XenDevice *xendev = XEN_DEVICE(dev); - monitor_hmp_printf(hmp, "%*sname = '%s' frontend_id = %u\n", - indent, "", xendev->name, xendev->frontend_id); + g_string_append_printf(buf, "%*sname = '%s' frontend_id = %u\n", + indent, "", xendev->name, xendev->frontend_id); } -#endif static char *xen_bus_get_dev_path(DeviceState *dev) { @@ -388,9 +384,7 @@ static void xen_bus_class_init(ObjectClass *class, const void *data) BusClass *bus_class = BUS_CLASS(class); HotplugHandlerClass *hotplug_class = HOTPLUG_HANDLER_CLASS(class); -#ifdef CONFIG_HMP bus_class->print_dev = xen_bus_print_dev; -#endif bus_class->get_dev_path = xen_bus_get_dev_path; bus_class->realize = xen_bus_realize; bus_class->unrealize = xen_bus_unrealize; diff --git a/include/hw/core/qdev.h b/include/hw/core/qdev.h index 1f6bf3fc1abf..e8399d8541fb 100644 --- a/include/hw/core/qdev.h +++ b/include/hw/core/qdev.h @@ -323,10 +323,8 @@ DECLARE_OBJ_CHECKERS(BusState, BusClass, struct BusClass { ObjectClass parent_class; -#ifdef CONFIG_HMP /* FIXME first arg should be BusState */ - void (*print_dev)(MonitorHMP *mon, DeviceState *dev, int indent); -#endif + void (*print_dev)(GString *buf, DeviceState *dev, int indent); /* * Return a newly allocated string containing the path of the * device on this bus. diff --git a/qapi/qdev.json b/qapi/qdev.json index 974cf9c5830e..4b5ccfb37687 100644 --- a/qapi/qdev.json +++ b/qapi/qdev.json @@ -165,6 +165,37 @@ { 'event': 'DEVICE_UNPLUG_GUEST_ERROR', 'data': { '*device': 'str', 'path': 'str' } } +## +# @x-query-qtree: +# +# Query device tree +# +# @brief: if true, omit device properties. (default: false) +# +# Features: +# +# @unstable: This command is meant for debugging. +# +# Returns: device tree +# +# Since: 11.2 +# +# .. qmp-example:: +# +# -> { "execute": "x-query-qtree" } +# <- { "return": { "human-readable-text": "..." } } +# +# .. qmp-example:: +# +# -> { "execute": "x-query-qtree", +# "arguments": { "brief": true } } +# <- { "return": { "human-readable-text": "..." } } +## +{ 'command': 'x-query-qtree', + 'data': { '*brief': 'bool' }, + 'returns': 'HumanReadableText', + 'features': [ 'unstable' ] } + ## # @device-sync-config: # diff --git a/rust/bindings/hwcore-sys/lib.rs b/rust/bindings/hwcore-sys/lib.rs index cecbf808dd09..a28f5ab90f69 100644 --- a/rust/bindings/hwcore-sys/lib.rs +++ b/rust/bindings/hwcore-sys/lib.rs @@ -21,7 +21,7 @@ use chardev_sys::Chardev; use common::Zeroable; -use glib_sys::GSList; +use glib_sys::{GSList, GString}; use migration_sys::VMStateDescription; use qom_sys::{ InterfaceClass, Object, ObjectClass, ObjectProperty, ObjectPropertyAccessor, diff --git a/system/qdev-monitor.c b/system/qdev-monitor.c index 8185822daa71..1a4af35f9db1 100644 --- a/system/qdev-monitor.c +++ b/system/qdev-monitor.c @@ -27,6 +27,7 @@ #include "system/runstate.h" #include "qapi/error.h" #include "qapi/qapi-commands-qdev.h" +#include "qapi/type-helpers.h" #include "qapi/qmp-registry.h" #include "qobject/qdict.h" #include "qapi/qmp/qerror.h" @@ -770,11 +771,10 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp) return ret; } -#ifdef CONFIG_HMP #define qdev_printf(fmt, ...) \ - monitor_hmp_printf(hmp, "%*s" fmt, indent, "", ## __VA_ARGS__) + g_string_append_printf(buf, "%*s" fmt, indent, "", ## __VA_ARGS__) -static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc, +static void qdev_print_props(GString *buf, DeviceState *dev, DeviceClass *dc, int indent) { for (int i = 0, n = dc->props_count_; i < n; ++i) { @@ -798,16 +798,17 @@ static void qdev_print_props(MonitorHMP *hmp, DeviceState *dev, DeviceClass *dc, } } -static void bus_print_dev(BusState *bus, MonitorHMP *hmp, DeviceState *dev, int indent) +static void bus_print_dev(BusState *bus, GString *buf, DeviceState *dev, + int indent) { BusClass *bc = BUS_GET_CLASS(bus); if (bc->print_dev) { - bc->print_dev(hmp, dev, indent); + bc->print_dev(buf, dev, indent); } } -static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent) +static void qdev_print(GString *buf, DeviceState *dev, int indent) { ObjectClass *class; NamedGPIOList *ngl; @@ -832,13 +833,13 @@ static void qdev_print(MonitorHMP *hmp, DeviceState *dev, int indent) } class = object_get_class(OBJECT(dev)); do { - qdev_print_props(hmp, dev, DEVICE_CLASS(class), indent); + qdev_print_props(buf, dev, DEVICE_CLASS(class), indent); class = object_class_get_parent(class); } while (class != object_class_by_name(TYPE_DEVICE)); - bus_print_dev(dev->parent_bus, hmp, dev, indent); + bus_print_dev(dev->parent_bus, buf, dev, indent); } -static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details) +static void qbus_print(GString *buf, BusState *bus, int indent, bool details) { BusChild *kid; @@ -851,22 +852,35 @@ static void qbus_print(MonitorHMP *hmp, BusState *bus, int indent, bool details) qdev_printf("dev: %s, id \"%s\"\n", object_get_typename(OBJECT(dev)), dev->id ? dev->id : ""); if (details) { - qdev_print(hmp, dev, indent + 2); + qdev_print(buf, dev, indent + 2); } QLIST_FOREACH(child_bus, &dev->child_bus, sibling) { - qbus_print(hmp, child_bus, indent + 2, details); + qbus_print(buf, child_bus, indent + 2, details); } } } #undef qdev_printf -void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict) +HumanReadableText *qmp_x_query_qtree(bool has_brief, bool brief, Error **errp) { - bool details = !qdict_get_try_bool(qdict, "brief", false); + g_autoptr(GString) buf = g_string_new(""); + bool details = !(has_brief && brief); if (sysbus_get_default()) { - qbus_print(hmp, sysbus_get_default(), 0, details); + qbus_print(buf, sysbus_get_default(), 0, details); } + + return human_readable_text_from_str(buf); +} + +#ifdef CONFIG_HMP +void hmp_info_qtree(MonitorHMP *hmp, const QDict *qdict) +{ + bool brief = qdict_get_try_bool(qdict, "brief", false); + g_autoptr(HumanReadableText) info = + qmp_x_query_qtree(true, brief, &error_abort); + + monitor_hmp_printf(hmp, "%s", info->human_readable_text); } void hmp_info_qdm(MonitorHMP *hmp, const QDict *qdict) -- 2.56.0.rc0.29.g47ce80527c56 From xen-devel-bounces@lists.xenproject.org Tue Sep 22 21:18:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 21:18:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429495.1652333 (Exim 4.92) (envelope-from ) id 1x97ss-00047P-0I; Tue, 22 Sep 2026 21:18:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429495.1652333; Tue, 22 Sep 2026 21:18:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x97sr-00047I-S8; Tue, 22 Sep 2026 21:18:37 +0000 Received: by outflank-mailman (input) for mailman id 1429495; Tue, 22 Sep 2026 21:18:36 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x97sq-00047B-7o for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 21:18:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x97sp-0002IN-Kx for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 23:18:35 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2f07f-2eae-0a2a0a5409dd-0a2a450cd066-18 for ; Tue, 22 Sep 2026 23:18:35 +0200 Received: from [52.101.65.133] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2f0ab-f479-0a2a450c0019-34654185268f-4 for ; Tue, 22 Sep 2026 23:18:35 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS4PR03MB8363.eurprd03.prod.outlook.com (2603:10a6:20b:512::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 21:18:32 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 21:18:32 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h/NGHD1RMZYhDVs3/TftudDlvnxmAG5Qz2vqOJ8wWJnDNTzogxcI3CXa3RdjZln6gN/CHC8UWkAXSRtr/5dGiiXyD7xcrf2iHE4DwJlH1v1tI/WRP2PGc79YJvWMTqUkTHn31QzOCr5Ahf9Z72V36ky7kFH51O1HP49CNA5td1mRuD+5g68p3TJuTDxFwrD5G8mNRYlNqWGgpuWjBwpSo6tBOlpfiD94PECr9X5A3PsvSId3T/pig1U5B9/6jtWCCgyvhRBOaUhfiQNbEp0czTAKmOJ6lFet4IzsyeYZimg6zYrSbl9PBrjGyTZlOMZJCj3gZ1gTq9iCb+n4K2s8kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A4KMALGWBREel2hCxC00aazS8xleixzBvLDh+8W/RgE=; b=K97b5qW54Cp+nHodS47Lmh/VcRvzkvfA6yIqbkd6a9s4VyGPIXtBi0Z3JdhE/NFQMk0qIN4/Z9EE6znLJIgg7Mk5Ma36Qwmfo9UzQpGyNxiOw9mZcpfhrP5f6R4cnd6B1xCLWLn5b+czBs6BCtvfv5+ue8Hee+Z2U6L2Hj6pR9LjQ8Ily6N5+xm7VE3LvbID2GzoDm3cAkn7L7tknSHU7OcvytlKl29dyBuWHDcOuf2lwsq1m3DhuWqbYGLNdgoW9PZzxsqWOWJtKixccjJakANlKIRxA9+IqTKF2TPgqpiiIualz9SJnk8No9Mdco67UTfrkH43P0eaysLZB3h/2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A4KMALGWBREel2hCxC00aazS8xleixzBvLDh+8W/RgE=; b=QJe3Y5iWNO2kqLERlApjLotM19n8yMXkua2ORz5k4iwdCUSVy/3rqiYjbTxSeQs7H/2qG+IY4sOcWGopmqyqqXn5huY4SiKjcs6KRRWTM1aQ/rviWbWjPQfxCvviuchNZX3mlW7FIMWlQVUwtoHcsad3qBaYLs+I7AB+Qv3EKxYCqixOhB4sHQMFC6Fv8TzBa1gqbkzWeNsatQsbh6CiIZwVRTWplk7btC9QdjTPNFdRdYn+FLQATNTDUpEiY0xb3BI1kTI0DAxiAwbAAiS2hoDk2jZXMMVWGPIzqVYRs2eHe73l64fpakxudQmuCSLo7IsbuYeCuN3qVYGl++Yh9Q== From: Volodymyr Babchuk To: Jan Beulich CC: "xen-devel@lists.xenproject.org" , Nicola Vetrini , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Bertrand Marquis Subject: Re: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code Thread-Topic: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code Thread-Index: AQHdOqUePUfY0zBPU0K0F/hx5odMHA== Date: Tue, 22 Sep 2026 21:18:31 +0000 Message-ID: <87h5jh56ji.fsf@epam.com> References: <0ff5676d-2ad3-49e3-a94b-90e7c3edb55f@suse.com> <87qzim6p5i.fsf@epam.com> <8fd025af-f429-488e-9977-aec3fea2e78b@suse.com> <87y0ct5zan.fsf@epam.com> In-Reply-To: (Jan Beulich's message of "Tue, 22 Sep 2026 13:16:22 +0200") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS4PR03MB8363:EE_ x-ms-office365-filtering-correlation-id: e5647331-931d-4bb0-6fb1-08df18ef0e03 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|23010399003|42112799006|1800799024|366016|38070700021|4143699003|10067099003|56012099006|11063799006|22082099003|18002099003; x-microsoft-antispam-message-info: y3kG04QrG4mVyuSjD4vIqxQJEpdSzseQyn+yzbG55s+7OYVTADQiyW1zVEKyMZiRX5522EGd8kZs1nh5OPe6d/1M1dDEZz/c9KDCaryH4drT+uHu5Wk0UPy9/U8uh/qPUCZzjxrspsCYaIelhlz4NQkl1HXApOKoAjUH2lxRB3iYPMCcAg8xFESxrK6qF11Zhl+LvxNLQn2UPb2ms/3XmI/FmOGyuAEN8PaF3AhsYNk+RmjN/tmRNXg9rkci+bZt6OMfQXJXjbQdK2qXUoy/u9vZlc0+QY8HrRaLy0gWViT09NV0pp+XO5XwKI2n+SNjZK5BT0jzGd4rmjlXUTTbFv5pYRPOwxtuEebps4oT8AX8Ryi69D2UqKkwzqEUxGcuN9d/CtFwaFcBJgrS5OHfhX8EtcmlOfdHgDApgRTrteA9wSAvXNSUSMj636CXDjkx/Ccql43UoLBC9u5h9+XnhBSmkStu/Qs8ZjBlbQP75HCERBXzA3xWPWv60aFIDiZWoXugPOPQhQ+dJ3r68Qn119v/uMSgPmHdWPc/KyfRGKJzlxBTxomJOzaW7QMgrxY5U+zj+UR2JAg8utjGL7A4NVjlvPap6HQdoae4IvYC6erO0chCBQ5tYW2wEXacmeqBJKL4ys5kSRljDjJ1cw4U5lKuoPlXGxUfBDZBlbzZEK1mnA63ZDUu8GOKaBBtKWQ0TkJMKbnLegMtbQjw+5MEpdr0mk1IoTw0cHuIVZUbLYg= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(23010399003)(42112799006)(1800799024)(366016)(38070700021)(4143699003)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?CMIuXJa08QSbpvAtT+F0DeXL5dMsYcaj1DuLJ7OB3Kl49UePX7zpnWtF8w?= =?iso-8859-1?Q?ii0KIdDsWkyXEKVXlTJs79IRNi+NsioNdENPAFQ0Yj1RzqEssfqW0dGPA3?= =?iso-8859-1?Q?zKEVb1S9klKpR3Vbbukj4PBYrTBTXFV5KA1+WQilYHf7ahJdEnsagud/HN?= =?iso-8859-1?Q?3tWagmQZh8xpKZoo/VOKR0I+hrpXFwHmeaoro5eH7nXRcm3PTGk8Fb3VwC?= =?iso-8859-1?Q?m1Cm1pWd/OqVNdEm7NP6vfjlmG1jjORyx1mfp9h/aUm0SMLwXTTtFFoXH/?= =?iso-8859-1?Q?hnNlhpSE08i3oK38MSvhZLjgEbugm/ww4V01WfGbITaX5RE5ZEnCjowifj?= =?iso-8859-1?Q?OKGAe3zNOD7bAbvSjB2KXPFXhJX5nVZi3XHeb7EXrOB6OmxEn+HMOalENh?= =?iso-8859-1?Q?2oe3wTKzACKHKFoZnYHwk4frv9j7+xhHoDyri1Q+do1DaKTY+iC4lv/lEQ?= =?iso-8859-1?Q?Dky3FB7jX+r9Y09aZHtoZ8xYu4gTUBRhlZbezEN5LDtUNeP8k2iXl3rOwA?= =?iso-8859-1?Q?axmJ7QE4pi5vUtBXXDQa++qvZl0Mjlj4alIBgq7fO1eGqccQm0TP7kOe+u?= =?iso-8859-1?Q?wWoqV8FXuFQgEWpOT5lhYjlNgl4xo5/nwZ+azNN+SCGW3nT7omM9aMRz2g?= =?iso-8859-1?Q?ow6Xp7sku0VzXHrny8mGx/A8DyPaJ/rprdfW1xy2zXuiT0beIDAYv5D8l4?= =?iso-8859-1?Q?cTiYVqMp+PiPwlA92FV1OYmedozqKVVsJLM/StWSvn3lXF6b9hDTSjgUms?= =?iso-8859-1?Q?px3oo4Kh703ZQesYZFfLJJB3RL1/TBSHQ/rYDRYnHb2gtEVfDcB762pVQT?= =?iso-8859-1?Q?U6YQzZDh5ljT2MOPoe14WMDk5oBEMuOyBSPQ4Qw3r6bW+mlsHDV8CErguf?= =?iso-8859-1?Q?GdTJbeZedfwCERKcknzoy2RRcobvta9jsVQDNbYN4P0yNjout9uBdDc0dG?= =?iso-8859-1?Q?G9M8jvICn58yoQ+6RKnqcVT77Rm6jY5mwEx8bkik7WvHeBAGb7eAtDN2KD?= =?iso-8859-1?Q?FgUBTpuF+082/2WdLKwNURE0SJ/F81routMc8nObg5FaVyUP9SW+eZCvhZ?= =?iso-8859-1?Q?ZhmramTLQCk9Ph0kGhbxQxg0SCCa+IVYgZ1zMWm7fEu/qug2xzWTrl+HTi?= =?iso-8859-1?Q?8JW6iAgeyNjEVYWGxvrL8HiAtV2bCcPelEEi1Bp/TbK/8Jxf91L1CU3lcO?= =?iso-8859-1?Q?2QW8eckzpyWhTM84r96gRNadJft8NkEXsjhO5CF9EEUhnxzcca+n4Ukrk6?= =?iso-8859-1?Q?zGKgLlrEVNgAZCEeDLvUq/KKSUb3ThBnq8Qq+fMI6y9S7cE8PZwQpDvVkG?= =?iso-8859-1?Q?reblrgP6PGCNH0IHhzyGS1dZA4nBB//uam8+D+JthHl+J5HElhWptaVExn?= =?iso-8859-1?Q?ZtOYrKo5IlZ3lMqNpk3FHX+zUP9SwV4gM1SjJqwY6i4YpOhAuNnrkU2Ghh?= =?iso-8859-1?Q?ihZXicjcRh/j951ieXvZh4TtJvXylpn+lQ1s2XAz1JxFlObbFH55aSJQtT?= =?iso-8859-1?Q?MizWobxK67+PJf2P7jJWUatXV6rtIPFsR4y58FQW2Sz4mqts3laeiWeR/z?= =?iso-8859-1?Q?1/BVhbxo5JzuVGQ1x9eOtcf72C2A17lvThV5XO6EP+qWI00PRqOYT9Sdx5?= =?iso-8859-1?Q?nc8T9UtleQAsD9foosrtFScCKhst3YiRTfMTAZikSNgknJQysafTtiUVlD?= =?iso-8859-1?Q?gSLTCqahmkqTqARZpBllCJmZMZdGtVP74/gnDs8pFKxypHIEOteTz2DhPm?= =?iso-8859-1?Q?32ogiLmJALrWqwK8mESqrR9+2YSaiyl6OI6+MtYxHCvl97veZYjjGkkZa3?= =?iso-8859-1?Q?DuNJlTqeM3x7WOwp14VM/CI3uS5nG2s=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5647331-931d-4bb0-6fb1-08df18ef0e03 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 21:18:32.0842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LkZ/69uhd0zePJQAuDmrNDbmRy9xLrmw7F50GfvUCBbFRIwvLma8YyByqZI8FgteDcPfxU7OUuFW+1J1KLNnnHT6RoqhM5aWdfQDpltmQnw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8363 X-purgate-ID: tlsNG-d25034/1790111915-01CC3A5B-D968EDDD/0/0 X-purgate-type: clean X-purgate-size: 2490 Hi Jan, Sorry for the late reply Jan Beulich writes: > On 22.09.2026 12:57, Volodymyr Babchuk wrote: >> Jan Beulich writes: >>> On 22.09.2026 03:38, Volodymyr Babchuk wrote: >>>> Jan Beulich writes: >>>>> Outside of drivers/acpi/tables/ (which is excluded from Eclair report= ing >>>>> for dubious reasons), arch/arm/acpi/domain_build.c is the only user o= f >>>>> ACPI_COMPARE_NAME(). Make the macro const correct, at the expense of >>>>> introducing a "const" variant of ACPI_CAST_PTR(), and at the expense = of >>>> >>>> I think you can avoid adding ACPI_CAST_PTR() by providing a const >>>> type. Like this: >>>> >>>> +#define ACPI_COMPARE_NAME(a, b) (*ACPI_CAST_PTR (const u32, a= ) =3D=3D \ >>>> + *ACPI_CAST_PTR (const u32, b= )) >>> >>> I don't think so. You did notice ... >>> >>>>> --- a/xen/include/acpi/acmacros.h >>>>> +++ b/xen/include/acpi/acmacros.h >>>>> @@ -103,6 +103,7 @@ >>>>> * Pointer manipulation >>>>> */ >>>>> #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p)) >>>>> +#define ACPI_CAST_CPTR(t, p) ((const t *) (const acpi_uin= tptr_t) (p)) >>> >>> ... this, I assume. On the surface it looks odd, because one would expe= ct >>> acpi_uintptr_t to be a scalar type, like uintptr_t is. But it isn't: >>> >>> #ifndef acpi_uintptr_t >>> #define acpi_uintptr_t void * >>> #endif >>=20 >> Well, that was unexpected. Talk about principle of least surprise... >>=20 >>> The only alternative I see (somewhat more risky overall) would be to >>> introduce >>> >>> #define acpi_uintptr_t uintptr_t >>=20 >> What are the risks? I'd really prefer to have fewer gotchas in the code. > > It hides casting away of const-ness. Right here we would like that, yet i= n > the general case I think we don't. Otoh Linux switched to the above in th= e > 5.18 dev cycle. ... but for different reason. clang complained about pointer subtraction with a null pointer. This does not fired in Xen because we are not using ACPI_PTR_DIFF() yet. But, if we are going to use it, we'll face the same problem. So, if we are already touching this parts, maybe it is better port that Linux patch ([1]) and use const types as I suggested? [1] https://lore.kernel.org/linux-acpi/20210927121338.938994-1-arnd@kernel.= org,=20 --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Tue Sep 22 22:14:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 22:14:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429513.1652342 (Exim 4.92) (envelope-from ) id 1x98kg-0006X7-Sb; Tue, 22 Sep 2026 22:14:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429513.1652342; Tue, 22 Sep 2026 22:14:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x98kg-0006X0-Od; Tue, 22 Sep 2026 22:14:14 +0000 Received: by outflank-mailman (input) for mailman id 1429513; Tue, 22 Sep 2026 22:14:13 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x98ke-0006Wu-DY for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 22:14:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x98ka-0048qu-Fl for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 00:14:08 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2fd88-2eae-0a2a0a5409dd-0a2a4504c0fc-28 for ; Wed, 23 Sep 2026 00:14:07 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2fdae-b57f-0a2a45040019-d561b338d092-3 for ; Wed, 23 Sep 2026 00:14:06 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x98k4-005qrI-QL; Wed, 23 Sep 2026 00:13:36 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x98k3-007Hg8-LC; Wed, 23 Sep 2026 00:13:36 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x98k3-00000003pWQ-2v5j; Wed, 23 Sep 2026 00:13:35 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=QrSu8YGOsu2E9jgIjM8USyvJdljVhVLowKN8872lW1E=; b=DtRscbnaZHf4PSBLM2a5VVIE+r ap7ZAz4U5sN/ScaRvrzsqpXlYbFfFlBfaJVzgGX9APtb3XHxiRuS6Ab4zpJ+ps1JO93pKQn3tsNS2 9YDX0uh5LIo//Vb9bSlwrPPMIrx6EoPSKPIWctZSLYHuASjT0RIBhzEVAYIuP4rsDEzLNkEmoLfku paInSpSfda95+QQUSHTnU+uRbIZxlF2J1kLW321YhpPNUeMHo+7zvPUV7twbPpq3ScB3mvMWIPGWm wU5WxR0JebnjBOM08fiyiacE43HGRqwq61uL2yiHHJSGHpBTWOiOBAiKqYBinXUIytlmMZOy6At+k uwEEPSjA==; MIME-Version: 1.0 Date: Tue, 22 Sep 2026 19:13:35 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v10 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN) In-Reply-To: <20260922035815.GFarH819yHRX8WWnG9@fat_crate.local> References: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> <20260922035815.GFarH819yHRX8WWnG9@fat_crate.local> Message-ID: <3ed7ea3908233ef72660ddfa1f92e914@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-ebf023/1790115247-C3CC7B50-A5CCF11B/0/0 X-purgate-type: clean X-purgate-size: 2198 On 2026-09-22 00:58, Borislav Petkov wrote: > On Mon, Sep 21, 2026 at 10:36:31PM -0300, Mauricio Faria de Oliveira wrote: >> The issue of unbootable VMs with CONFIG_PVH due to CONFIG_KASAN is back. >> >> Booting directly from vmlinux (instead of bzImage) now fails with gcc-14/15 >> (but works with gcc-12/13) if CONFIG_KASAN_GENERIC is set, on Ubuntu 25.10. >> >> The PVH code is required/supposed not to use the KASAN memory access check >> in the kernel entry point as KASAN has not yet been setup, or an exception >> is hit and the boot fails. >> >> This was previously described and addressed with __builtin_mem{cmp,set}(): >> - commit 661362e3dcab ("xen, pvh: fix unbootable VMs (PVH + KASAN - AMD_MEM_ENCRYPT)") >> - commit 416a33c9afce ("x86/cpu: fix unbootable VMs by inlining memcmp() in hypervisor_cpuid_base()") >> - commit fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()") >> >> However, even with __builtin the compiler may decide to use the out of line >> function instead of the inline implementation. So, that does not really fix >> the issue unconditionally; see details below. > > So, this whole deal doesn't sound to me like we need to backport it to stable > - it rather looks more like fixing some configs which want to enable KASAN on > PVH guests. > > In that case, I'll queue this for 7.4. > > If this needs to go to stable, then there better be a pretty good reason for > it. > > Right? I think that is fine, yes. Even though it's a boot failure, actually hitting it depends on all of: CONFIG_KASAN, CONFIG_PVH, booting from the PVH entry point, _plus_ a compiler version that triggers it. Nonetheless, this may be picked up for stable due to the Fixes: tags, but I can provide backports as needed. BTW, I just realized that the title of patch 4/4 is missing memset(). Would you mind adding it, please? Or I can send v11. -x86/cpuid: fix unbootable VMs by really inlining memcmp() in cpuid_base_hypervisor() and xen_prepare_pvh() +x86/cpuid: fix unbootable VMs by really inlining memcmp() and memset() in cpuid_base_hypervisor() and xen_prepare_pvh() Thanks, -- Mauricio From xen-devel-bounces@lists.xenproject.org Tue Sep 22 23:07:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 23:07:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429531.1652350 (Exim 4.92) (envelope-from ) id 1x99aT-000762-Gn; Tue, 22 Sep 2026 23:07:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429531.1652350; Tue, 22 Sep 2026 23:07:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x99aT-00075v-ED; Tue, 22 Sep 2026 23:07:45 +0000 Received: by outflank-mailman (input) for mailman id 1429531; Tue, 22 Sep 2026 23:07:44 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x99aS-00075p-By for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 23:07:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x99aR-00Bg09-Ck for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 01:07:43 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab30a19-2eae-0a2a0a5409dd-0a2a450c8e3c-18 for ; Wed, 23 Sep 2026 01:07:43 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab30a3e-f479-0a2a450c0019-ac6904feb166-3 for ; Wed, 23 Sep 2026 01:07:43 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 91941601F0; Tue, 22 Sep 2026 23:07:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 871731F000FF; Tue, 22 Sep 2026 23:07:40 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:cc:Subject:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790118461; bh=Kd2W6KkdCDYQn3TqVPRzfg+RT3RLgENl/pIefvqy8R0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GsEPAV4lwjJ1HF/xHZs4rbbgDMsASQ6jlU/Llzp8u3AX9iG8j6xaztp0DSdn6azTD dUXZ2DOyQJs2NPYne5tQzsK8VqeZNpxZUAPtAKp7VoAW2O2pjQ5eDmcjqTY9Pc32PT oI9KZTVLNQ3+DCtgHt0n756LFIut7pZfaUxPHZAaOgi4754aB1PuNeOTpMHvP6y+4k n3fslCm2rnZBqIZBaN05L6rx1p8YP+ObUi42TrOLAVr/W2Ijriz1zyAn/343bA8ow7 iinHf+oNjb6ooaRu5ESJi5vXjNUMDKdkjBnYjFz6ShuEmYghwtKQ1AEgeTxgfDyioI dK7v7QTEsFBRQ== Date: Tue, 22 Sep 2026 16:07:39 -0700 (PDT) From: Stefano Stabellini To: Ethan Nelson-Moore cc: Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, Juergen Gross , Stefano Stabellini Subject: Re: [PATCH] xen: remove unused hvm_vcpu.h header In-Reply-To: <20260919074650.453007-1-enelsonmoore@gmail.com> Message-ID: <7c7518ed-6eeb-618d-5fba-2461e51c3b82@kernel.org> References: <20260919074650.453007-1-enelsonmoore@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-purgate-ID: tlsNG-d25034/1790118463-51F33A5B-1CB805D8/0/0 X-purgate-type: clean X-purgate-size: 4125 On Sat, 19 Sep 2026, Ethan Nelson-Moore wrote: > The header appears to have been unused > ever since it was added to the kernel in commit cee2cfb7d18d ("xen/pvh: > Import PVH-related Xen public interfaces"). Remove it. > > Signed-off-by: Ethan Nelson-Moore Reviewed-by: Stefano Stabellini > --- > include/xen/interface/hvm/hvm_vcpu.h | 116 --------------------------- > 1 file changed, 116 deletions(-) > delete mode 100644 include/xen/interface/hvm/hvm_vcpu.h > > diff --git a/include/xen/interface/hvm/hvm_vcpu.h b/include/xen/interface/hvm/hvm_vcpu.h > deleted file mode 100644 > index cbf93493275c..000000000000 > --- a/include/xen/interface/hvm/hvm_vcpu.h > +++ /dev/null > @@ -1,116 +0,0 @@ > -/* SPDX-License-Identifier: MIT */ > -/* > - * Copyright (c) 2015, Roger Pau Monne > - */ > - > -#ifndef __XEN_PUBLIC_HVM_HVM_VCPU_H__ > -#define __XEN_PUBLIC_HVM_HVM_VCPU_H__ > - > -#include "../xen.h" > - > -struct vcpu_hvm_x86_32 { > - uint32_t eax; > - uint32_t ecx; > - uint32_t edx; > - uint32_t ebx; > - uint32_t esp; > - uint32_t ebp; > - uint32_t esi; > - uint32_t edi; > - uint32_t eip; > - uint32_t eflags; > - > - uint32_t cr0; > - uint32_t cr3; > - uint32_t cr4; > - > - uint32_t pad1; > - > - /* > - * EFER should only be used to set the NXE bit (if required) > - * when starting a vCPU in 32bit mode with paging enabled or > - * to set the LME/LMA bits in order to start the vCPU in > - * compatibility mode. > - */ > - uint64_t efer; > - > - uint32_t cs_base; > - uint32_t ds_base; > - uint32_t ss_base; > - uint32_t es_base; > - uint32_t tr_base; > - uint32_t cs_limit; > - uint32_t ds_limit; > - uint32_t ss_limit; > - uint32_t es_limit; > - uint32_t tr_limit; > - uint16_t cs_ar; > - uint16_t ds_ar; > - uint16_t ss_ar; > - uint16_t es_ar; > - uint16_t tr_ar; > - > - uint16_t pad2[3]; > -}; > - > -/* > - * The layout of the _ar fields of the segment registers is the > - * following: > - * > - * Bits [0,3]: type (bits 40-43). > - * Bit 4: s (descriptor type, bit 44). > - * Bit [5,6]: dpl (descriptor privilege level, bits 45-46). > - * Bit 7: p (segment-present, bit 47). > - * Bit 8: avl (available for system software, bit 52). > - * Bit 9: l (64-bit code segment, bit 53). > - * Bit 10: db (meaning depends on the segment, bit 54). > - * Bit 11: g (granularity, bit 55) > - * Bits [12,15]: unused, must be blank. > - * > - * A more complete description of the meaning of this fields can be > - * obtained from the Intel SDM, Volume 3, section 3.4.5. > - */ > - > -struct vcpu_hvm_x86_64 { > - uint64_t rax; > - uint64_t rcx; > - uint64_t rdx; > - uint64_t rbx; > - uint64_t rsp; > - uint64_t rbp; > - uint64_t rsi; > - uint64_t rdi; > - uint64_t rip; > - uint64_t rflags; > - > - uint64_t cr0; > - uint64_t cr3; > - uint64_t cr4; > - uint64_t efer; > - > - /* > - * Using VCPU_HVM_MODE_64B implies that the vCPU is launched > - * directly in long mode, so the cached parts of the segment > - * registers get set to match that environment. > - * > - * If the user wants to launch the vCPU in compatibility mode > - * the 32-bit structure should be used instead. > - */ > -}; > - > -struct vcpu_hvm_context { > -#define VCPU_HVM_MODE_32B 0 /* 32bit fields of the structure will be used. */ > -#define VCPU_HVM_MODE_64B 1 /* 64bit fields of the structure will be used. */ > - uint32_t mode; > - > - uint32_t pad; > - > - /* CPU registers. */ > - union { > - struct vcpu_hvm_x86_32 x86_32; > - struct vcpu_hvm_x86_64 x86_64; > - } cpu_regs; > -}; > -typedef struct vcpu_hvm_context vcpu_hvm_context_t; > - > -#endif /* __XEN_PUBLIC_HVM_HVM_VCPU_H__ */ > -- > 2.43.0 > From xen-devel-bounces@lists.xenproject.org Tue Sep 22 23:56:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 22 Sep 2026 23:56:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429554.1652359 (Exim 4.92) (envelope-from ) id 1x9ALc-0006Kz-UL; Tue, 22 Sep 2026 23:56:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429554.1652359; Tue, 22 Sep 2026 23:56:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9ALc-0006Ks-Rh; Tue, 22 Sep 2026 23:56:28 +0000 Received: by outflank-mailman (input) for mailman id 1429554; Tue, 22 Sep 2026 23:56:27 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9ALb-0006Km-Ke for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 23:56:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9ALa-005qKB-BK for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 01:56:26 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab31538-2eae-0a2a0a5409dd-0a2a450ac9a4-16 for ; Wed, 23 Sep 2026 01:56:26 +0200 Received: from [40.107.159.130] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab315a9-f2d2-0a2a450a0019-286b9f823685-3 for ; Wed, 23 Sep 2026 01:56:26 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by BESPR03MB11843.eurprd03.prod.outlook.com (2603:10a6:b10:fd::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Tue, 22 Sep 2026 23:56:23 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Tue, 22 Sep 2026 23:56:23 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uyZO44RDIa8+W8Prmn2wOsuMeRmDuK6P1Q/krv/qhyTGG9VBtCUs33WA1vwTxyDY6BAovuVh/39F+zMnfVKkcqfh8Pp7Ou6ZN2y5yRV3LcUOOomeQfQKL3cioV8yq2tB2N3Oi0X9oNFMHc9tphbO448/mKJl9CT8ryk9+sZcfb06lA3wFwPSgAQsMhqQgnrJ2R6bb8E3309dmFxOdfIyUi58x/WLo22cJ0gtklhq76ochbyFSrn/VdoJDVrvZmda/F1KmviPZVBYLze+IW1lN67jgusqs8F5y24jHuRo9wscdDMrIwo37Xv06KVAposBE4TUyK5/9wEySlabFbBlqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Adt5AFFvngQlvhyNHuOWpyMqXZ3eaYAQIevhb8B0XYg=; b=UMySzeOYXcwO4P+Y62DLWljqAxj5dtdHuRCAAdb837cnRLnWH7lnZCsPptSpUi53RCmuHZZFGf6qEXuLsyYaUoWO+MPoRHszKE3HRVRnDA0eQOjtN5/rF7gO8O4sOlvU2Ua42KI5EN2fkGWOKR5xLj4a8DmWCE7CfJucBGoLDL+ZjRxt2VAe/CIN/MSelmxB9D6rKGEveB2FpCaOnIRvxfPHWkrx0UjIb8zyUUmtfDIY9GcIJONKmMi9gQyEPE4wlqCCvzONM56AUiywC5a8HyQLN8+l4tI7bmQraEXqmpj5+kQzZZ7Bz2VOtqym4hxWoqUKeizDacwWyn8jQXBXeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Adt5AFFvngQlvhyNHuOWpyMqXZ3eaYAQIevhb8B0XYg=; b=H9b8Nfq82Umad38BJF21E2vagaCW2u/08SVcX9bCfaRssJAdDTiRIzhSkWMcuYf+mj5FmOzvV3TRJUEh3Sh5HdNENx/KY9Tmi9snV/rFxa4rlWujsxjLDsMLUus6pG9SH5q6ZDdQxUoNi4SQca1B2BhBQvCNpW47FqsqMd5qyHxsx80CQD+PZFxNf7U1QaFTsVpEtYHR/tPziWFsavuiGUNYf+YqeIFwTMFYW99Qt0FSFZ+VGjjM/TzZ6GVQot8piQl3jHgXnurm/PADyPYedYxMFIZdhcxckbANTkV/GFW+bdjPp3LWG/zuxJ56wDz2BRLlMsB/CsBDHMz7Nq+86g== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v3 1/4] xen/arm: its: initialize host LPI state before activating ITSes Thread-Topic: [PATCH v3 1/4] xen/arm: its: initialize host LPI state before activating ITSes Thread-Index: AQHdSqtHErIjikKEzUu28tenN1pYhA== Date: Tue, 22 Sep 2026 23:56:22 +0000 Message-ID: <8733v06dsq.fsf@epam.com> References: In-Reply-To: (Mykola Kvach's message of "Tue, 22 Sep 2026 18:58:39 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|BESPR03MB11843:EE_ x-ms-office365-filtering-correlation-id: 4e5b101d-c4e2-456f-c2b8-08df19051b0c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|42112799006|366016|1800799024|38070700021|4143699003|56012099006|11063799006|10067099003|22082099003|18002099003|6133799003|3023799007; x-microsoft-antispam-message-info: IAaXdv39pbSw4slbLyuyrrQCDg7DH1oO2q6Np87ia6Yxc7cXbglTOqxYpLQkhiEX/Y/vk+NAnqIAWti2iY1V5VmP+/7/rXUXOPzJqy18vB5mh4JXyH1VZoqpFByhwEFtmLfGl4C10ZlOQeWvYKur52nucn0J5sDuTBdRgkLVOJ2z/j/oWaQdSuZEuPTewjYA5Hjmo1SYtC5GV3sQ3xqnTGbIU0Ns5j1Z3GgVe3J/M67JTecMnjFwq0xs7Wq5/hrL2t7ysmXF+N7PLfohmpYoH/B/KEQdiqh9PxXvzPr4CuwOqEcC5wb/6boaAn5wbqN5QDK3b+nzJJlQ77DsxkIMQYgKMB5+BI9Z1eBqrWMc/8Dal+80HTzGL+E6hxumoEJ+8nj/l7AgkSdxPdz6fg7r2RPGMOH30uCFvpCwJgdldtk3zsStzqBJ+SALh0/IY5ADrzzDl+6hS1Egg78QzKnf2we7YFGDAaRMywmqUkGWEqyMxk9juzShHpFexExzi82W7OMfMoG0HBlbFEpBktCB8srckDCDLRwRm4zhMdNqpBjhjtIseobjCj7Z13yB6HaFtOnfXytiDfRZSqQHlH7wXEfBfNXlnptLXMq8TgfKgZLAtRwTem+xpU5gtWNgDHioBsjqpyFa6gXmn8I72LgJjRdukYXnFF+Zo/trGNoztV6C9XOYK+HxWrTfrhZ9fTUw x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(42112799006)(366016)(1800799024)(38070700021)(4143699003)(56012099006)(11063799006)(10067099003)(22082099003)(18002099003)(6133799003)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?zR8uU7eDJxoVp/r7f2u7vSFwe0PgFsK6qprJdgdcgEV2qnIlwPlJYT76mr?= =?iso-8859-1?Q?BHVTi1knEJM6tvwP+RRBndYb9d5rZCUczw+8nMqhubTDEhaDD3agi861Vo?= =?iso-8859-1?Q?wKeZY7sPJozWwtaF8ktECi5DS2S32oy0C4bbTJIbX8iqpvFL5f46jrsgCg?= =?iso-8859-1?Q?u0ztDQEsJm/c2uaNTjQDowrW7+KWEz5c4UNc+Tw9VOQZDXbnGT6yC9eA6Y?= =?iso-8859-1?Q?UMWVW3Onn0aOkcfXF3oqKN/bK81SSRxD2+BiPpPqrfcer8crlbfgdrm7tQ?= =?iso-8859-1?Q?qvd01P+3RcjxrVFIgvE9rVZxEBQwwkdc9EE03sg35Xr7iXsrCZZ4m/qO3w?= =?iso-8859-1?Q?nPSpSUtHiJnP7jEbqoIlOMFML2Yb6LSeEnvmBiOA33nUg+y/d4n0iMSpfa?= =?iso-8859-1?Q?PCf2iJU5WmGWZZesT/+hdXdOfPMxhfj578UxMBJNMSqO5txN3NhfYUCTuO?= =?iso-8859-1?Q?HIohwd0SGT1ehDnkTDLj1MipAIyfMNaE/0Va8hiVKQwKDlFdhw4p7N3Gma?= =?iso-8859-1?Q?dd5mdVabciteYEuFT0cyqlb0lmyK3qWjJnP/OzWy2ILmPh9ElFHwof/0Of?= =?iso-8859-1?Q?2CEXMHDxZZs04RpBVMoOpba1eSto1avsS+ELwO4fl5hBPLhrgaOo3Y1zwA?= =?iso-8859-1?Q?O/qjI/UQwg97P7yl3BvwxEliLcjFhTyzENVmjG0elzJMdeC+QI4MN4Nh6U?= =?iso-8859-1?Q?cAsd87UK6e+FSQ1y9kVQ4zqjtvqhWqko5TRFNAVP0MpMqTWzk9e0ZQgx1K?= =?iso-8859-1?Q?7TIKG6VLCxQjZirGv89a7pUErmtFlqHb9gmZupCNF16tGfRrmXgAD7viZz?= =?iso-8859-1?Q?DtNbvzbjrIhzZ9EZyNKMNnoQQ755OzQhkVyye5ifszMduyEOXYH/Jgp3LG?= =?iso-8859-1?Q?F5dwctA2eK4IKkrAiKigGzW+CWs/O0SPlFIbT5PKISNQ5NcGD7Xpd9wEzV?= =?iso-8859-1?Q?IH14ZX1lDIwUyuFkWbdZp3KXqdTg0oMPrjGPmz5DBUK0hv43H14zhCzzpz?= =?iso-8859-1?Q?JcXXkHba1QFHCWyOykvuKsBDsWIJfA7UvWXT2MvxZq21nud/EJ0Repn9nm?= =?iso-8859-1?Q?9J+tgafLlxvfZl8KNMx6nHUbNBCBSwX6ymWPgEIG5Sus4fjQlSu4SweVUs?= =?iso-8859-1?Q?6k9lb37695NBnF7j0cfbMYWMaEGCmlJghEi9kRFsjhgMIRR6g8+50RhRuv?= =?iso-8859-1?Q?F+3K+uhxt+XjHYSc20mUf+abykyfdIXx7nE5cBMNwbhbUrMqv1JKBcF0fm?= =?iso-8859-1?Q?ch0f3PW/tCzFBbwrQ8cikZffg51OyI+psCyX9UE4+GnIfT4TIbPV+OKWdG?= =?iso-8859-1?Q?eKiKUn3qeq9fxDx4QQissF/p6MVWUMZOLr5mn9X5HqbyfZP2dJ0EnJdhWg?= =?iso-8859-1?Q?CzVx2I/I9H8lDHzKsi7Z+TFQ/ansaqIdodBgS9WXgUKgdkJPHZf0j/ETAq?= =?iso-8859-1?Q?2odvx5BAKd1QZA+xrFnTPfRXZ1zadr11Z6kpWDXZF3YXSdBlX71q5rED1X?= =?iso-8859-1?Q?TBtcdzvAtNUiqjhOUr5dvkbefDnpMJoerc2v900oiqC55xz2HHoU1JsRjY?= =?iso-8859-1?Q?/be0Rl2QBspleETaFH5Y+f+VT8TD2thLvbLRChH+pZclrLRYGraDZEDfMX?= =?iso-8859-1?Q?X66TvQY8MnPr8DL+9cEO3iB5KAP7vUsQJ6FCJgSvZ9/O6SMuDq4Bs6JPgJ?= =?iso-8859-1?Q?F7cekagHF8Vk2DVdPY158LsezWSt90gC83tucRSlBYCOUuKog2Yi+EZKn/?= =?iso-8859-1?Q?K6dp59aWkzKXVDnPwBF+ncD1arVSevi3ytocugl5/ggbEgQkeFZL3g2k5+?= =?iso-8859-1?Q?M1oIdtUgjwh1S7orb4aHZZHuvf0/DUY=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e5b101d-c4e2-456f-c2b8-08df19051b0c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 23:56:22.9048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MRPBds/5d0BRuLI+s/FbKqd+3SwIu9436CR0LtkQ/XhpxFpQhX2IGfz86CfyAodXKSjeB47sErcX68jPvoYZcmN+KVlAIjycp4R5gZZ/f8s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BESPR03MB11843 X-purgate-ID: tlsNG-4011c0/1790121386-51CC3CFC-46DFCBA0/0/0 X-purgate-type: clean X-purgate-size: 3932 Hi Mykola, Mykola Kvach writes: > The boot CPU pending table must use the memory attributes selected by > ITS quirks. gicv3_lpi_init_host_lpis() is therefore called after > gicv3_its_init(). However, gicv3_its_init() also programs and enables > each ITS before host LPI state is allocated. No ITS commands are > submitted at that point, but this ordering relies on that implementation > detail. > > Split per-ITS initialization into preparation and activation phases. > First map and disable every ITS and collect its quirks. Then initialize > host LPI state. Only after that, allocate and program the ITS tables and > command queue, and enable each ITS. > > The subsequent gicv3_cpu_init() sequence remains unchanged: it programs > the Redistributor LPI tables, enables LPIs, and then submits the first > MAPC and SYNC commands. > > Suggested-by: Julien Grall > Signed-off-by: Mykola Kvach > --- > Changes in v3: > - New patch implementing the post-4.22 initialization order discussed > during review of the ordering fix. > > Link: https://patchew.org/Xen/341edd8de63dcd84ccc6e7b6c03e9e8fc7105184.17= 81847061.git.mykola._5Fkvach@epam.com/ > --- > xen/arch/arm/gic-v3-its.c | 32 ++++++++++++++++++++++----- > xen/arch/arm/gic-v3.c | 15 ++----------- > xen/arch/arm/include/asm/gic_v3_its.h | 4 ++-- > 3 files changed, 31 insertions(+), 20 deletions(-) > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > index 325835b0ad..972825bf06 100644 > --- a/xen/arch/arm/gic-v3-its.c > +++ b/xen/arch/arm/gic-v3-its.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -549,10 +550,9 @@ static int gicv3_disable_its(struct host_its *hw_its= ) > return -ETIMEDOUT; > } > =20 > -static int gicv3_its_init_single_its(struct host_its *hw_its) > +static int __init gicv3_its_prepare_single_its(struct host_its *hw_its) > { > - uint64_t reg; > - int i, ret; > + int ret; > =20 > hw_its->its_base =3D ioremap_nocache(hw_its->addr, hw_its->size); > if ( !hw_its->its_base ) > @@ -564,6 +564,14 @@ static int gicv3_its_init_single_its(struct host_its= *hw_its) > =20 > gicv3_its_enable_quirks(hw_its); > =20 > + return 0; > +} > + > +static int __init gicv3_its_init_single_its(struct host_its *hw_its) > +{ > + uint64_t reg; > + int i, ret; > + > reg =3D readq_relaxed(hw_its->its_base + GITS_TYPER); > hw_its->devid_bits =3D GITS_TYPER_DEVICE_ID_BITS(reg); > hw_its->evid_bits =3D GITS_TYPER_EVENT_ID_BITS(reg); > @@ -1189,7 +1197,7 @@ static void gicv3_its_acpi_init(void) > =20 > #endif > =20 > -int gicv3_its_init(void) > +int __init gicv3_its_init(unsigned int host_lpi_bits) > { > struct host_its *hw_its; > int ret; > @@ -1201,13 +1209,27 @@ int gicv3_its_init(void) > =20 > list_for_each_entry(hw_its, &host_its_list, entry) > { > - ret =3D gicv3_its_init_single_its(hw_its); > + ret =3D gicv3_its_prepare_single_its(hw_its); > if ( ret ) > return ret; > } > =20 > gicv3_its_validate_quirks(); > =20 > + if ( list_empty(&host_its_list) ) > + return 0; What is the purpose of this check here? I'd expect to see it before the first list_for_each_entry() loop. > + > + ret =3D gicv3_lpi_init_host_lpis(host_lpi_bits); > + if ( ret ) > + return ret; > + > + list_for_each_entry(hw_its, &host_its_list, entry) > + { > + ret =3D gicv3_its_init_single_its(hw_its); > + if ( ret ) > + return ret; > + } > + > return 0; > } [...] --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Wed Sep 23 00:14:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 00:14:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429562.1652368 (Exim 4.92) (envelope-from ) id 1x9AcX-0001K6-E0; Wed, 23 Sep 2026 00:13:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429562.1652368; Wed, 23 Sep 2026 00:13:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9AcX-0001Jz-Ax; Wed, 23 Sep 2026 00:13:57 +0000 Received: by outflank-mailman (input) for mailman id 1429562; Wed, 23 Sep 2026 00:13:56 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9AcV-0001Jt-Ry for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 00:13:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9AcU-00BM4m-MJ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 02:13:54 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab319a0-2eae-0a2a0a5409dd-0a2a450a83da-12 for ; Wed, 23 Sep 2026 02:13:54 +0200 Received: from [40.107.159.139] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab319c0-f2d2-0a2a450a0019-286b9f8b31aa-3 for ; Wed, 23 Sep 2026 02:13:54 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by DB4PR03MB8659.eurprd03.prod.outlook.com (2603:10a6:10:385::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Wed, 23 Sep 2026 00:13:50 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 00:13:50 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=o/HqS3cEugsMW18ijR3vcnd8C3K8FZmMqa0rhm2iyXQUEsf2330+lAQUqoWdXfdFkfWE1+WuvgKBEFrYgGnkKeikmlZEF3ZmcIh0XPWEFpv2z2gjOMouaDJdYJnz07rYHNm/1XplAba2qdkXNrRF+uHjxP2pCyRg6rCfBcZzuVaVg25sbhxHPSygurEzD6cIzeUM9SJ85qVTVPcHVAbyrwCLwTjksDwpfKWlJY1LQLwx1kwSGj8guSSe0wVKKw8Loy0ZABiDpfStIjE/aL56GiTDs2CS0AMIgXGKSZ5096Qks621fi56nt8l8LWlNKF9BoQ5tHtKEzfdOt3yXFIUQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RHje+FgnWMBnxY8dSHDD9k//cdxgZlIDyNO4Txzw55s=; b=wjrw+MUHw5EkzWYdXSydjIDCIYdRgn6QSzKzZGVIvkIpTyYkFyC8gtlmaBzwBgfXB5V7J68WDbVgkTF17E7yq0L8a7eCToGsOIB7C6OJi1xaqZOwUayLLpCyJIK0f2am8wNkXLw1f4DA2kN9IqJGK/Dvy5TGxjbjuJ+PMdW1fMOuvd0yB/WmsqMbA9C58vDX3KNiss4AScn9wzRnp1PWpJ0r/PPFgGWE9ajb7uS1HCQyEQcFcrH35AgAexhN2xE7yLtU2NOMVX2TWfV1QSH+a7ZVNFWqXMiFOKBXaP3i7ZMTJ6tTLAwhV4yOE4QqzlMo/KcZTfHu89z1LEijwb8N9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RHje+FgnWMBnxY8dSHDD9k//cdxgZlIDyNO4Txzw55s=; b=B4NvOJUqjlws2Usov+eFdxiraKpyPp6Mz7OTAl7QO18bvQGfMnPPrHSPJYa+4Jh4cSDsvGZBXl6iMR1C4oRXQl2bq7dYRnsFsyszooEGI2MtZo7j8mtnhCdnmvCViryFHwnJO6oAr7WWyb2XdSCu45k9wzlnFTsRhxZSz8HhTEj2B7IHa9p2yDQzJ472p5A2aYZr2ZP1x6Mc/+irSgqe2b5BeNrgJKWKom8X6Y6AlbGOx5aJ/bb1u4227j+JZj28ml1XBHY8tTIqUj2Lwgx1I2d8LCyhgrKIT4CF4V6IDs1veEd8ysn+kfXC6zLEjmLMX6pwSB0X+kyM9i6K/6MxBg== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v3 2/4] xen/arm: its: separate ITS and host LPI quirk scopes Thread-Topic: [PATCH v3 2/4] xen/arm: its: separate ITS and host LPI quirk scopes Thread-Index: AQHdSqtLrSlEtqKp7ka3WfHuuRD+Ew== Date: Wed, 23 Sep 2026 00:13:49 +0000 Message-ID: <87qzik4yf6.fsf@epam.com> References: <9de733816d356161c8bfa45171e0ddbba68021f2.1790089161.git.mykola_kvach@epam.com> In-Reply-To: <9de733816d356161c8bfa45171e0ddbba68021f2.1790089161.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Tue, 22 Sep 2026 18:58:40 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|DB4PR03MB8659:EE_ x-ms-office365-filtering-correlation-id: ea74afee-5897-4c00-fad1-08df19078b33 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|42112799006|23010399003|4143699003|22082099003|18002099003|38070700021|56012099006|11063799006|6133799003|10067099003|3023799007; x-microsoft-antispam-message-info: jlYsf9XmMunZs2DPN6wKRYadJT7Ot/OjE+8VGNvm7gvAU9bWdU5E7KIbw+AlFIHEy74PXhaAfBjwtLZfS72fEWk3pDWEww9MfdUiPJ11V0xNzTSYWgF2spkTZ+r8t/9S7sDUvyEcF2/XhJhI+v/s5mBJKEL8ba53TLZSRTJAO3MAQiP046NsQzmertDtIRh8IXPOTUl2fMLftSW+oqqjev3lSEMXIxNN4kMYuYJMgL33Z+FiVUmcQ/HUJWkzHTxxqwr3/fFQdUbAot+V5sfmLUV1D5B0uuQ3hmqbphaNUBGuG/EWaTGWRuY8Y2UVK36xQHltweNXarj9NPZJfRY2zcLU083vcJCOLUTGsNWaiiddMnMU63E/hEpmPU7/V1YCbPA7/8nL/Mud4ZllFQI9xD6ezUMudDQAa6Faq8zdDn+QaVlMOoajhPGGKOQv0LaQwMAZt+xdWoV69p7qzzQtoy3Fa1oZEnbM6D2ttJAvw1Sq4ZthsRciGWPg/TULrfHUrFi33EGqFl25mrNZaAo44bgQ+n1HSWElEUoz//JZe0cUE/62Z8e4KEe4LdtJqiWJ+xybVgcfvCppRQKPpm+bnhD/UsM1Ylh8Fxa1FodbwhOxOXuQUw5CgjgNKD34j0pzhcJioWRj30ISlDMN2rT/4xjbVIgwOc3zg47bJM+Nz8lk/FzJneVUdz2Efcn/xJ3eg2q5FMIjiMYvytpTeDq071z5elwGDuKfBxbYvyfBvVI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(42112799006)(23010399003)(4143699003)(22082099003)(18002099003)(38070700021)(56012099006)(11063799006)(6133799003)(10067099003)(3023799007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Q34IPsTqy5ddTymcJ2ijqgnnqdQ2Zb5BbiYRKBdQtT37WuwO7SOnQmIMJf?= =?iso-8859-1?Q?UYLyGxRr6M1+nFbCsqGpa1JZymqDEQbp4zFXZB+PmlyjkB1/1Zfr17lz9P?= =?iso-8859-1?Q?Ed3ovB8CLQzx2jLjhYLQjlBJLphVPzdvdPcIKmwq8fh2G6luObhVH/T47K?= =?iso-8859-1?Q?qv4tc8Dl9yxeN3HO2tvIVRa5472eBQ0IRUZXFRFOb8yEf9MxGLFU6y6mbS?= =?iso-8859-1?Q?asiINa6KJaSneVBHP16pCrL4tUleDwxCECNge81aPSCGNN56QHZony9rQ7?= =?iso-8859-1?Q?fidVELyqu1IR01XsjQ5GdkRS9g/D0U/UQEjzc5JAfsHf05Jfi8QbYxFHpq?= =?iso-8859-1?Q?sATNnbBnyHJxCeKCouQjj7omUxcvjRsuAM1m9NaW2YaGFgWiTdJIKUWawq?= =?iso-8859-1?Q?twomEozEwyA8ZPTc6HsstHovNddeExDiZaiEUEnP/wy/QCYKRQ/sbo/Vwn?= =?iso-8859-1?Q?LBXTSAIyBEKiQfpIzqHB0RupiBAzFZlhZeYhnwS3WMzOaCW9gQk9Uy6O4H?= =?iso-8859-1?Q?yrGm6Q4gJqmoURKj82YpOw/eUmBcOGE0S3LXNX4IrnOupdcKxfxVsd5vmN?= =?iso-8859-1?Q?n/fejOKOZkyWnzfSzoFhKYDvuT1maI1vv6S7XRZW2qu0lnpSHg9H3tXP4H?= =?iso-8859-1?Q?5VHJtc5P+uBKI31N/0fcVxwFgu32T3JivAzShQaQj+ty+BVfaq8pULXBwj?= =?iso-8859-1?Q?tqWBRAfOAnf7T5jOzRDu2sp0XH2LeCiuaHJKdrc4bquKRJP5m+yfkR9Eok?= =?iso-8859-1?Q?ZlYQO9LQDkQEtHklFEwa24vV93kaAczvgHoIMiNfPTp9HKhDDhalMtf1Nl?= =?iso-8859-1?Q?rlNjRjodcxAqfm0W0UDkWVyaKApEbHhV7lQOsSn4KB5hvpG6yKyJjR81JP?= =?iso-8859-1?Q?B7FVFZxyJfPLeyjoRiwmLun+CsXd5YH5A1eZlsV7R6NS04WFewQ1jDUwPm?= =?iso-8859-1?Q?2X752VScqWXbzFWkVF1V7f1voAnDinRTJPM4NwXJtE5mxtvJHq+TXsj+OY?= =?iso-8859-1?Q?mazQ64dY6YCoasj+0d4wHQXZOzsqcuIcK8m0CEoKIGMzv/76XOBa33qLkw?= =?iso-8859-1?Q?EUm/5fM8FfvwaxS38pkRDqWFsjuHphRU5KWmqOfUQhOzMrjsYzVD88vG1d?= =?iso-8859-1?Q?UB7AjlLTRNSXe1/6d1rqBFhG6iT6rsagAJqcq3dKrfozGJlyI0OByDPW1C?= =?iso-8859-1?Q?3M3b8UwMvJxYNJaRGzwoOQua6DmRzMmYZ4QPDztEkUSHYfaxgfuj9mmPk0?= =?iso-8859-1?Q?knRcZ/TB4YS6SJLZIJuiRkcaT9b1bA6KTWgAkcVW7lOR78PGNqK74aEqHo?= =?iso-8859-1?Q?5IUcnxAHPKAZTog4h/dPDdwGPPtY8V6EhkJGnLfAfz3BiM1/agNR3dPzFR?= =?iso-8859-1?Q?calljWi4oRCD/tgYcDF0dU+7VU9jWR1euxRsz78DSXEg/qaC6Kjd8LWdAR?= =?iso-8859-1?Q?z1cjkKKZ3lJNqjCmAi/uRukZVk6LX+qkWuEZO2M5BqVGiKXTG63rLqlqA8?= =?iso-8859-1?Q?b46FulnW4sodqEhHLVYSNLt1GMCdGdRKc6h4SEINPDWQa2FWFizinGkDus?= =?iso-8859-1?Q?A7V9ANag1JCQhXkhwrKdnEpWfK90tzF1pOA4sz75vCKenOv2xg0dxtvxKN?= =?iso-8859-1?Q?5cm5HYfuAwyOR+UI2m5KdLbm5s1HX26u5RVySVVDEjF/9jJVFq62ZN/Thk?= =?iso-8859-1?Q?h/BYKeSJUoynxoQKVqPJ17vfWdirmfA56ZMHzIIbjew1TH+KL5VLoAk6oQ?= =?iso-8859-1?Q?aMdb53HqA9xYntaSQGyb2GHPXp/Z9FYM2TzKPDc8RBeMgctVEZ/Da5Vn9o?= =?iso-8859-1?Q?J1VyOLi1cVbI6CJaeL1PQn5H8QQWMzc=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea74afee-5897-4c00-fad1-08df19078b33 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2026 00:13:50.0448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: a5c2J1huSJGZFgPDh/9qBK/bKsA3buU82qK9tliz0nVEYX4s0ftX9T9qzL56NoTySTSu2aCceT8ugXKWV5kEqz7m2jiMAEvJ1LJvvcCx6j8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB8659 X-purgate-ID: tlsNG-4011c0/1790122434-4B4D7CFC-96E05DB0/0/0 X-purgate-type: clean X-purgate-size: 20550 Hi Mykola, Mykola Kvach writes: > ITS quirks can impose restrictions on memory accessed by the ITS itself > and on shared host LPI/Redistributor state. These scopes are not > identical, so a single global ITS quirk state makes the host LPI policy > depend implicitly on the quirks seen while initializing host ITSes. > > Add per-ITS quirk_flags to struct host_its and keep a separate > host_lpi_flags state in the LPI code. The quirk table now records the > ITS-private and host LPI scopes explicitly through its_flags and > lpi_flags. The R-Car Gen4 quirk applies the same memory restrictions to > both scopes, preserving the existing R-Car memory policy without relying > on an implicit aggregation step. > > This also removes the assumption that all host ITSes must expose the > same quirk state. ITS-derived host LPI restrictions are accumulated only > from quirk entries that explicitly set lpi_flags. > > Use per-ITS quirk_flags for GITS_CBASER, GITS_BASER, and ITT > allocations. Use host_lpi_flags when allocating the property and pending > tables and when programming GICR_PROPBASER and GICR_PENDBASER. > Memory-related quirk bits are named GICV3_QUIRK_MEM_* and are translated > by shared gicv3_mem_get_*() helpers. > > Collect both scopes during the ITS preparation pass, before host LPI > state is allocated. Keep init-only annotations and includes in the > implementation files rather than the public header. > > Signed-off-by: Mykola Kvach > --- > Changes in v3: > - Collect quirk flags during the ITS preparation pass added earlier. > - Keep init-only annotations and includes in implementation files. > > Changes in v2: > - Replace v1's single global ITS quirk flags and same-quirk validation > with explicit per-ITS and host LPI quirk scopes. > - Drop the v1 ITS pre-initialization approach from this patch. In v2, > host LPI allocation was moved after ITS initialization by a separate > patch. > - Drop DT dma-noncoherent handling from this patch; firmware-provided > non-coherency is handled separately with explicit ITS-node and > GIC-node scopes. > - Keep host_lpi_flags owned by gic-v3-lpi.c and update it only with quirk > flags that explicitly apply to host LPI/Redistributor state. > - Rename the current memory-related bits to GICV3_QUIRK_MEM_* and use > shared gicv3_mem_get_*() helpers for register attributes and allocation > flags. > --- > xen/arch/arm/gic-v3-its.c | 111 ++++++++++++-------------- > xen/arch/arm/gic-v3-lpi.c | 45 +++++++++-- > xen/arch/arm/include/asm/gic_v3_its.h | 18 +++-- > 3 files changed, 100 insertions(+), 74 deletions(-) > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > index 972825bf06..454fd0e0ef 100644 > --- a/xen/arch/arm/gic-v3-its.c > +++ b/xen/arch/arm/gic-v3-its.c > @@ -52,43 +52,40 @@ struct its_device { > struct pending_irq *pend_irqs; /* One struct per event */ > }; > =20 > -/* > - * It is unlikely that a platform implements ITSes with different quirks= , > - * so assume they all share the same. > - */ > struct its_quirk { > const char *desc; > - bool (*init)(struct host_its *hw_its); > uint32_t iidr; > uint32_t mask; > + uint32_t its_flags; > + /* > + * lpi_flags are ORed into the global host LPI policy and must only > + * contain additive restrictions. Non-additive LPI quirks need expli= cit > + * handling. > + */ > + uint32_t lpi_flags; > }; > =20 > -static uint32_t __ro_after_init its_quirk_flags; > - > -static bool gicv3_its_enable_quirk_gen4(struct host_its *hw_its) > -{ > - its_quirk_flags |=3D HOST_ITS_WORKAROUND_NC_NS | > - HOST_ITS_WORKAROUND_32BIT_ADDR; > - > - return true; > -} > - > static const struct its_quirk its_quirks[] =3D { > { > .desc =3D "R-Car Gen4", > .iidr =3D 0x0201743b, > .mask =3D 0xffffffffU, > - .init =3D gicv3_its_enable_quirk_gen4, > + .its_flags =3D GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADD= R, > + .lpi_flags =3D GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADD= R, > }, > { > /* Sentinel. */ > } > }; > =20 > -static const struct its_quirk *gicv3_its_find_quirk(uint32_t iidr) > +static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr= ) > { > const struct its_quirk *quirks =3D its_quirks; > =20 > + /* > + * The first matching quirk wins. More specific quirks must be liste= d > + * before broader IIDR-only entries. > + */ > for ( ; quirks->desc; quirks++ ) > { > if ( quirks->iidr =3D=3D (quirks->mask & iidr) ) > @@ -98,53 +95,38 @@ static const struct its_quirk *gicv3_its_find_quirk(u= int32_t iidr) > return NULL; > } > =20 > -static void gicv3_its_enable_quirks(struct host_its *hw_its) > +static void __init gicv3_its_collect_quirks(struct host_its *hw_its) > { > uint32_t iidr =3D readl_relaxed(hw_its->its_base + GITS_IIDR); > const struct its_quirk *quirk =3D gicv3_its_find_quirk(iidr); > =20 > - if ( quirk && quirk->init(hw_its) ) > - printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc); > -} > - > -static void gicv3_its_validate_quirks(void) > -{ > - const struct its_quirk *quirk =3D NULL, *prev =3D NULL; > - const struct host_its *hw_its; > - > - if ( list_empty(&host_its_list) ) > - return; > - > - hw_its =3D list_first_entry(&host_its_list, struct host_its, entry); > - prev =3D gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_= IIDR)); > - > - list_for_each_entry(hw_its, &host_its_list, entry) > + if ( quirk ) > { > - quirk =3D gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + = GITS_IIDR)); > - BUG_ON(quirk !=3D prev); > - prev =3D quirk; > + hw_its->quirk_flags |=3D quirk->its_flags; > + gicv3_lpi_update_host_flags(quirk->lpi_flags); > + printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc); > } > } > =20 > -uint64_t gicv3_its_get_cacheability(void) > +uint64_t gicv3_mem_get_cacheability(uint32_t flags) > { > - if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS ) > + if ( flags & GICV3_QUIRK_MEM_NC_NS ) > return GIC_BASER_CACHE_nC; > =20 > return GIC_BASER_CACHE_RaWaWb; > } > =20 > -uint64_t gicv3_its_get_shareability(void) > +uint64_t gicv3_mem_get_shareability(uint32_t flags) > { > - if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS ) > + if ( flags & GICV3_QUIRK_MEM_NC_NS ) > return GIC_BASER_NonShareable; > =20 > return GIC_BASER_InnerShareable; > } > =20 > -unsigned int gicv3_its_get_memflags(void) > +unsigned int gicv3_mem_get_alloc_flags(uint32_t flags) > { > - if ( its_quirk_flags & HOST_ITS_WORKAROUND_32BIT_ADDR ) > + if ( flags & GICV3_QUIRK_MEM_32BIT_ADDR ) > return MEMF_bits(32); > =20 > return 0; > @@ -391,13 +373,17 @@ static void *its_map_cbaser(struct host_its *its) > uint64_t reg; > unsigned int order; > void *buffer; > + uint64_t cacheability =3D gicv3_mem_get_cacheability(its->quirk_flag= s); > + uint64_t shareability =3D gicv3_mem_get_shareability(its->quirk_flag= s); > + unsigned int memflags =3D gicv3_mem_get_alloc_flags(its->quirk_flags= ); > =20 > - reg =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHI= FT; > - reg |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILIT= Y_SHIFT; > - reg |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILI= TY_SHIFT; > + reg =3D MASK_INSR(shareability, GITS_BASER_SHAREABILITY_MASK); > + reg |=3D MASK_INSR(GIC_BASER_CACHE_SameAsInner, > + GITS_BASER_OUTER_CACHEABILITY_MASK); > + reg |=3D MASK_INSR(cacheability, GITS_BASER_INNER_CACHEABILITY_MASK)= ; > =20 > order =3D get_order_from_bytes(max(ITS_CMD_QUEUE_SZ, SZ_64K)); > - buffer =3D alloc_xenheap_pages(order, gicv3_its_get_memflags()); > + buffer =3D alloc_xenheap_pages(order, memflags); > if ( !buffer ) > return NULL; > =20 > @@ -438,8 +424,8 @@ static void *its_map_cbaser(struct host_its *its) > /* The ITS BASE registers work with page sizes of 4K, 16K or 64K. */ > #define BASER_PAGE_BITS(sz) ((sz) * 2 + 12) > =20 > -static int its_map_baser(void __iomem *basereg, uint64_t regc, > - unsigned int nr_items) > +static int its_map_baser(struct host_its *its, void __iomem *basereg, > + uint64_t regc, unsigned int nr_items) > { > uint64_t attr, reg; > unsigned int entry_size =3D GITS_BASER_ENTRY_SIZE(regc); > @@ -447,10 +433,14 @@ static int its_map_baser(void __iomem *basereg, uin= t64_t regc, > unsigned int table_size; > unsigned int order; > void *buffer; > + uint64_t cacheability =3D gicv3_mem_get_cacheability(its->quirk_flag= s); > + uint64_t shareability =3D gicv3_mem_get_shareability(its->quirk_flag= s); > + unsigned int memflags =3D gicv3_mem_get_alloc_flags(its->quirk_flags= ); > =20 > - attr =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SH= IFT; > - attr |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILI= TY_SHIFT; > - attr |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABIL= ITY_SHIFT; > + attr =3D MASK_INSR(shareability, GITS_BASER_SHAREABILITY_MASK); > + attr |=3D MASK_INSR(GIC_BASER_CACHE_SameAsInner, > + GITS_BASER_OUTER_CACHEABILITY_MASK); > + attr |=3D MASK_INSR(cacheability, GITS_BASER_INNER_CACHEABILITY_MASK= ); > =20 > /* > * Setup the BASE register with the attributes that we like. Then re= ad > @@ -464,7 +454,7 @@ retry: > table_size =3D min(table_size, 256U << BASER_PAGE_BITS(pagesz)); > =20 > order =3D get_order_from_bytes(max(table_size, BIT(BASER_PAGE_BITS(p= agesz), U))); > - buffer =3D alloc_xenheap_pages(order, gicv3_its_get_memflags()); > + buffer =3D alloc_xenheap_pages(order, memflags); > if ( !buffer ) > return -ENOMEM; > =20 > @@ -562,7 +552,7 @@ static int __init gicv3_its_prepare_single_its(struct= host_its *hw_its) > if ( ret ) > return ret; > =20 > - gicv3_its_enable_quirks(hw_its); > + gicv3_its_collect_quirks(hw_its); > =20 > return 0; > } > @@ -592,18 +582,19 @@ static int __init gicv3_its_init_single_its(struct = host_its *hw_its) > case GITS_BASER_TYPE_NONE: > continue; > case GITS_BASER_TYPE_DEVICE: > - ret =3D its_map_baser(basereg, reg, BIT(hw_its->devid_bits, = UL)); > + ret =3D its_map_baser(hw_its, basereg, reg, > + BIT(hw_its->devid_bits, UL)); You are passing hw_its now, so there is no need to pass the last argument, because its_map_baser() can calculate it by itself. > if ( ret ) > return ret; > break; > case GITS_BASER_TYPE_COLLECTION: > - ret =3D its_map_baser(basereg, reg, num_possible_cpus()); > + ret =3D its_map_baser(hw_its, basereg, reg, num_possible_cpu= s()); > if ( ret ) > return ret; > break; > /* In case this is a GICv4, provide a (dummy) vPE table as well.= */ > case GITS_BASER_TYPE_VCPU: > - ret =3D its_map_baser(basereg, reg, 1); > + ret =3D its_map_baser(hw_its, basereg, reg, 1); > if ( ret ) > return ret; > break; > @@ -738,6 +729,7 @@ int gicv3_its_map_guest_device(struct domain *d, > struct its_device *dev =3D NULL; > struct rb_node **new =3D &d->arch.vgic.its_devices.rb_node, *parent = =3D NULL; > int i, ret =3D -ENOENT; /* "i" must be signed to check for >=3D= 0 below. */ > + unsigned int memflags; > unsigned int order; > =20 > hw_its =3D gicv3_its_find_by_doorbell(host_doorbell); > @@ -801,8 +793,9 @@ int gicv3_its_map_guest_device(struct domain *d, > ret =3D -ENOMEM; > =20 > /* An Interrupt Translation Table needs to be 256-byte aligned. */ > + memflags =3D gicv3_mem_get_alloc_flags(hw_its->quirk_flags); > order =3D get_order_from_bytes(max(nr_events * hw_its->itte_size, 25= 6UL)); > - itt_addr =3D alloc_xenheap_pages(order, gicv3_its_get_memflags()); > + itt_addr =3D alloc_xenheap_pages(order, memflags); > if ( !itt_addr ) > goto out_unlock; > =20 > @@ -1214,8 +1207,6 @@ int __init gicv3_its_init(unsigned int host_lpi_bit= s) > return ret; > } > =20 > - gicv3_its_validate_quirks(); > - > if ( list_empty(&host_its_list) ) > return 0; > =20 > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > index 9ee338edc2..accfd48a74 100644 > --- a/xen/arch/arm/gic-v3-lpi.c > +++ b/xen/arch/arm/gic-v3-lpi.c > @@ -8,6 +8,7 @@ > */ > =20 > #include > +#include > #include > #include > #include > @@ -78,9 +79,29 @@ struct lpi_redist_data { > =20 > static DEFINE_PER_CPU(struct lpi_redist_data, lpi_redist); > =20 > +/* > + * Host LPI flags are scoped to shared LPI/Redistributor state, not to a= n > + * ITS instance. Arm IHI 0069H.b section 5.1.1 says "LPI configuration i= s > + * global". Section 12.11.33 (GICR_PROPBASER) makes mismatched values > + * UNPREDICTABLE for Redistributors that share an LPI Configuration tabl= e > + * while GICR_CTLR.EnableLPIs =3D=3D 1. Section 12.11.32 (GICR_PENDBASER= ) > + * similarly makes mismatched OuterCache, Shareability or InnerCache val= ues > + * across Redistributors UNPREDICTABLE while GICR_CTLR.EnableLPIs =3D=3D= 1. > + * > + * Keep this policy in the LPI code and accumulate only explicit LPI/RD > + * restrictions into it. Per-ITS restrictions stay in host_its::quirk_fl= ags > + * for GITS_CBASER, GITS_BASER and ITT memory. > + */ > +static uint32_t __ro_after_init host_lpi_flags; > + > #define MAX_NR_HOST_LPIS (lpi_data.max_host_lpi_ids - LPI_OFFSET) > #define HOST_LPIS_PER_PAGE (PAGE_SIZE / sizeof(union host_lpi)) > =20 > +void __init gicv3_lpi_update_host_flags(uint32_t flags) > +{ > + host_lpi_flags |=3D flags; > +} > + > static union host_lpi *gic_get_host_lpi(uint32_t plpi) > { > union host_lpi *block; > @@ -228,6 +249,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int = cpu) > { > void *pendtable; > unsigned int order; > + unsigned int memflags =3D gicv3_mem_get_alloc_flags(host_lpi_flags); > =20 > if ( per_cpu(lpi_redist, cpu).pending_table ) > return -EBUSY; > @@ -239,7 +261,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int = cpu) > * physically contiguous memory. > */ > order =3D get_order_from_bytes(max(lpi_data.max_host_lpi_ids / 8, (u= nsigned long)SZ_64K)); > - pendtable =3D alloc_xenheap_pages(order, gicv3_its_get_memflags()); > + pendtable =3D alloc_xenheap_pages(order, memflags); > if ( !pendtable ) > return -ENOMEM; > =20 > @@ -262,6 +284,8 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdis= t_base) > { > const void *pendtable =3D this_cpu(lpi_redist).pending_table; > uint64_t val; > + uint64_t cacheability =3D gicv3_mem_get_cacheability(host_lpi_flags)= ; > + uint64_t shareability =3D gicv3_mem_get_shareability(host_lpi_flags)= ; > =20 > /* > * The memory should have been allocated while preparing the CPU (or > @@ -275,9 +299,10 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdi= st_base) > =20 > ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16))); > =20 > - val =3D gicv3_its_get_cacheability() << GICR_PENDBASER_INNER_CACHEA= BILITY_SHIFT; > - val |=3D GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEAB= ILITY_SHIFT; > - val |=3D gicv3_its_get_shareability() << GICR_PENDBASER_SHAREABILITY= _SHIFT; > + val =3D MASK_INSR(cacheability, GICR_PENDBASER_INNER_CACHEABILITY_M= ASK); > + val |=3D MASK_INSR(GIC_BASER_CACHE_SameAsInner, > + GICR_PENDBASER_OUTER_CACHEABILITY_MASK); > + val |=3D MASK_INSR(shareability, GICR_PENDBASER_SHAREABILITY_MASK); > val |=3D GICR_PENDBASER_PTZ; > val |=3D virt_to_maddr(pendtable); > =20 > @@ -304,10 +329,13 @@ static int gicv3_lpi_set_proptable(void __iomem * r= dist_base) > { > uint64_t reg; > unsigned int order; > + uint64_t cacheability =3D gicv3_mem_get_cacheability(host_lpi_flags)= ; > + uint64_t shareability =3D gicv3_mem_get_shareability(host_lpi_flags)= ; > =20 > - reg =3D gicv3_its_get_cacheability() << GICR_PROPBASER_INNER_CACHEA= BILITY_SHIFT; > - reg |=3D GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEAB= ILITY_SHIFT; > - reg |=3D gicv3_its_get_shareability() << GICR_PROPBASER_SHAREABILITY= _SHIFT; > + reg =3D MASK_INSR(cacheability, GICR_PROPBASER_INNER_CACHEABILITY_M= ASK); > + reg |=3D MASK_INSR(GIC_BASER_CACHE_SameAsInner, > + GICR_PROPBASER_OUTER_CACHEABILITY_MASK); > + reg |=3D MASK_INSR(shareability, GICR_PROPBASER_SHAREABILITY_MASK); > =20 > /* > * The property table is shared across all redistributors, so alloca= te > @@ -317,9 +345,10 @@ static int gicv3_lpi_set_proptable(void __iomem * rd= ist_base) > { > /* The property table holds one byte per LPI. */ > void *table; > + unsigned int memflags =3D gicv3_mem_get_alloc_flags(host_lpi_fla= gs); > =20 > order =3D get_order_from_bytes(max(lpi_data.max_host_lpi_ids, (u= nsigned long)SZ_4K)); > - table =3D alloc_xenheap_pages(order, gicv3_its_get_memflags()); > + table =3D alloc_xenheap_pages(order, memflags); > =20 > if ( !table ) > return -ENOMEM; > diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include= /asm/gic_v3_its.h > index e1322b94f8..9230705181 100644 > --- a/xen/arch/arm/include/asm/gic_v3_its.h > +++ b/xen/arch/arm/include/asm/gic_v3_its.h > @@ -110,8 +110,9 @@ > #define HOST_ITS_FLUSH_CMD_QUEUE (1U << 0) > #define HOST_ITS_USES_PTA (1U << 1) > =20 > -#define HOST_ITS_WORKAROUND_NC_NS (1U << 0) > -#define HOST_ITS_WORKAROUND_32BIT_ADDR (1U << 1) > +/* GICv3 memory-related quirk flags. */ > +#define GICV3_QUIRK_MEM_NC_NS (1U << 0) > +#define GICV3_QUIRK_MEM_32BIT_ADDR (1U << 1) > =20 > /* We allocate LPIs on the hosts in chunks of 32 to reduce handling over= head. */ > #define LPI_BLOCK 32U > @@ -128,6 +129,11 @@ struct host_its { > unsigned int itte_size; > spinlock_t cmd_lock; > void *cmd_buf; > + /* > + * Workaround flags scoped to this ITS instance, including memory > + * accessed through GITS_CBASER, GITS_BASER and ITT memory. > + */ > + uint32_t quirk_flags; > unsigned int flags; > }; > =20 > @@ -157,6 +163,7 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base); > /* Initialize the host structures for LPIs and the host ITSes. */ > int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits); > int gicv3_its_init(unsigned int host_lpi_bits); > +void gicv3_lpi_update_host_flags(uint32_t flags); > =20 > /* Store the physical address and ID for each redistributor as read from= DT. */ > void gicv3_set_redist_address(paddr_t address, unsigned int redist_id); > @@ -199,10 +206,9 @@ struct pending_irq *gicv3_assign_guest_event(struct = domain *d, > void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id, > uint32_t virt_lpi); > =20 > -/* ITS quirks handling. */ Maybe leave the comment? Just change "ITS" to "ITS/LPI" ? > -uint64_t gicv3_its_get_cacheability(void); > -uint64_t gicv3_its_get_shareability(void); > -unsigned int gicv3_its_get_memflags(void); > +uint64_t gicv3_mem_get_cacheability(uint32_t flags); > +uint64_t gicv3_mem_get_shareability(uint32_t flags); > +unsigned int gicv3_mem_get_alloc_flags(uint32_t flags); > =20 > #else --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Wed Sep 23 00:21:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 00:21:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429569.1652377 (Exim 4.92) (envelope-from ) id 1x9Aji-00032Q-5I; Wed, 23 Sep 2026 00:21:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429569.1652377; Wed, 23 Sep 2026 00:21:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Aji-00032J-1v; Wed, 23 Sep 2026 00:21:22 +0000 Received: by outflank-mailman (input) for mailman id 1429569; Wed, 23 Sep 2026 00:21:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Ajg-000318-Ti for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 00:21:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Ajg-00BMpc-6n for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 02:21:20 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab31b41-2eae-0a2a0a5409dd-0a2a450b9d06-46 for ; Wed, 23 Sep 2026 02:21:20 +0200 Received: from [40.107.159.119] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab31b7f-b7e8-0a2a450b0019-286b9f77a1a4-4 for ; Wed, 23 Sep 2026 02:21:19 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by PAWPR03MB10167.eurprd03.prod.outlook.com (2603:10a6:102:363::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Wed, 23 Sep 2026 00:21:18 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 00:21:17 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l3HQcR7wZo76gZ2fEggulvLJ/DBUNz2WGczgGCfLpFAEN/xmJvaiYCDaNxR9ApaF4L0PF52oe10Xqo28KkrlDkFi5vMssF34DX0fr7Wy2drf4YZywDPAdfN6VsfQ7Xq5iuj5wNR5vszpPw0TvD/wvLZnwmYopTNXE1lpHu/eG+UqCsiYnDqaCwJBOw1O1zCUADsu4ZFyHPKebZdDfjAS2LuhBrfw3ZWzW85vTEEl8X6kYUOZevdJ8sr+9jJBlmcUs/8K6pCjOkV1qN0YmeoFSFKldZO+UvmsuM9XP9HgcrcYPxGUfpkUdBtyEDtIawCJd485H/E5TuI3hULXkn+sXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hfoGumbEuAkIDCu2v8ZkaLiloepCzdiLRBPfmJh5mC8=; b=MhnMjwLVX+r/0BT833Fj9Zo/l19X1DIVq4X6oQXFj7+G20Lg0jrrbxCHSgEckxLhF64YRfwqmYuUNMpn5+/rgrxFa2GCKpC3AW8hK7zUYix2iK7Q7Oxyc8CCTKBcNoGiqLcMwYvu2Zw70K37tMIoHxDPkyVFz1Z9SwQP4c2geEwmAvPTRboaWJoCUZA+XkS6IhHXAGJjkys7FTNZoYOu963IH9RHNFrlTF+r9mCfeRu9hy805HS/jiTDF0QqelqpTdoiwGmf5C+gyTjxiksyHX8g5iP9g0gifaicClK5jplQCZCPq/timU1ZCEVIwJfxJG9zWAXMYadC5mLbti/ajw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hfoGumbEuAkIDCu2v8ZkaLiloepCzdiLRBPfmJh5mC8=; b=d0njgTNkeaJOODWu30j6+CTPfkuk5tUEEe/8YzNyKXF1A29WU3lim2VOqhGvDcGUEmb+BFZwXjrfw+4VRHSqyhx8OzdJ3pkCWwzYROQ/buDQer7AcO3DnnubEU8Ef1rWjCBO281wdocXxW2uGWx2pfN+tOJqqHM56zLG98n8/DHzHWBlKMOKb8cgpwn68r5W0CNU6oEQ/+jCFEGsWpfhclCSJBTutFNQwJW1Ppd9//SXvcqRY6W/GUKLe46Zgpz1hV2sY8gWOkgtv7V6x2JrU8nj8A2MvNdcFHu37DGK77t3L9wXtjBYkcM4jjfHlw1fTFAGdhuwwBf3ObXMIGP87g== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v3 3/4] xen/arm: its: refactor ITS quirk matching Thread-Topic: [PATCH v3 3/4] xen/arm: its: refactor ITS quirk matching Thread-Index: AQHdSqtNwidRcqNdj0yo3wTLZbOD6Q== Date: Wed, 23 Sep 2026 00:21:17 +0000 Message-ID: <87cxu44y2q.fsf@epam.com> References: In-Reply-To: (Mykola Kvach's message of "Tue, 22 Sep 2026 18:58:41 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|PAWPR03MB10167:EE_ x-ms-office365-filtering-correlation-id: 0f60d11a-1ec8-452a-7fe7-08df19089602 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|42112799006|1800799024|38070700021|4143699003|10067099003|11063799006|56012099006|18002099003|22082099003; x-microsoft-antispam-message-info: bFg72p4Qg83RIFs358bq0LgF1TssGennVh5lGj9v7vwH4FWysXNn28HHiQxNZcg3kiAeQ39rzBR2/ZY/531A/tY8/A9lmWl13JO5s+C1GFgv1nKQSsIXFNVjcEvMftLv68N2zWiUVFQk7AolGfU5/mbLBesYqXAxFnL0jzoDPTJDEEVQjHJGi7vF3X2AmW4nMa8LNbnhNYLE1Q5V5RER39n8OE7o1wG1BE4Kc7H6NYXO+K0cdX0Kl1bFHoL52M1FsJ42DEoiuPBEl8Eu+5lz5QPjG2znye01FW3zvcRCu9nSbR/9YonaLEcBiFJRwIQvD+LgRJ7TaxRLan+3KtiULNxUGXZ2wzAAit2fnbCJtTHuC3meFWGYLUQr5zDfKMsiD8tlTjjwHJrkWVM5M9dsB4KbpNJIAe1+NTysGR6J21arqLxlaRCdPhzUbon4ixs6xyIPX4ihE938gPjJiB8qhGdyBdJ3Z8NT8bhKcH/RyyrPXwUrygR55IXPNXihi995aeI+j5f3ouapVRKMjZtp/TuPn69GO2PnOUxlPAAn+KJi6VW07yJ1zqGc/hL9+CsxpGrDq0IG2vUdU/hnU+cJaBZMguY9EkKaJ+uNal3fTNIbiI0PZn+z8we1On3sj9ypmCoOw2fAaHE4rMzT7qRYWk1DaImBqZaXvta0qzZLQS2iy2TyEeA1C/bxjQwzoOI+ADiXvcITdMD0juCEEQB9YppYbJzJ5ANv7MAkW+5WuqY= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(42112799006)(1800799024)(38070700021)(4143699003)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?uw605W2Cn5bBPv1S/nyTxS3A0JbnKPnI0xt3o1R147AuRKAucsPKDvpfgK?= =?iso-8859-1?Q?cJRuNSMpYXeVI5epTNMn8nkjFTm4bHf7sZXRTVcam8Ig2M45OOmtfSb5us?= =?iso-8859-1?Q?KI+CZvZRAlZAbvpMVuFN36rfemtPOpDXfV6753kCnUdlXpNvQRBx1rAz/Z?= =?iso-8859-1?Q?15RNmuJFC7Lq9RVWEU1Yuy9lE6uH/ncH2PfRUvvDPOf5NA92Aq+MbU+Syk?= =?iso-8859-1?Q?/QHx6fGdjyr1KG1EekHmJ4nWRmn5tLo3YJz31rcseGn0wCu4H1447VavZ1?= =?iso-8859-1?Q?ANeqi2r+rrBjJNL109NUYkfhDm1OBtdL1Ex/QHkROS0JM3xAgXSz9tq0gw?= =?iso-8859-1?Q?adYUzieFXBt/4cMcnSz5VAPP7LaqrdORlkHU835hfo7oUucs5eR03BA576?= =?iso-8859-1?Q?yAcu1//atsWyRj/nWwHXCYYHeFewLGNZVo16jj/nLfICzJ3UfAEBT+DVus?= =?iso-8859-1?Q?EUwz/IhbyfKv3tIs4DnPwVSSbZGxHGhUSpSW/6OUaeF9lNDOLv2aCkrtnR?= =?iso-8859-1?Q?v+fYo1sba0clrJnjdZ0yD34DaR7IwGgR6eMadzMOh1nCblDbwoK6IZjRfS?= =?iso-8859-1?Q?VQJYFQ14/lwMBnwx7w9gMmxj7+fgzLjetMeuBhvYOgq5VwDEwS9WK443fU?= =?iso-8859-1?Q?MbJ5Hd89ZqEi/iROUX8hN4xnyiosW8OJOB8CHl3cf99RPRir5KpVQvxXDi?= =?iso-8859-1?Q?wal4tnaXRgWypSzQtrn8z075zJTsv8abW/qptG/xM6H6G/osmUzWPr/ovZ?= =?iso-8859-1?Q?iUbfgVBikaS4fxn9lK5FOQlk6q0EkwPhwXwvBd0Mq8izFatAxkp4UeRgaA?= =?iso-8859-1?Q?y18pZrzo+qMMEwXBNHQILkt1k+/dr66eVnLcVDYLsJaHi65uEDNPJwZ5Xo?= =?iso-8859-1?Q?4qxNyW65e3WrTPgVA/vsSj7xGn1P+dHtjCqR+mlRGy0bsOnNLn9Fs572KC?= =?iso-8859-1?Q?wjWj8QIolWJoIthndMelkza9BZekcSoEcT7k1NiP26YmwCWsmfw+w7wdRl?= =?iso-8859-1?Q?5MRfqfYKesqk2+cuzWDV2oDOS09oGJYYoEsrDjDKH+7ou/+TJOMjuZkF9z?= =?iso-8859-1?Q?PNqykB/tdKH6/8P9WYv6VRzgfAZy2g8u2g45AhIyL9BUu45x7VLLcsRWmj?= =?iso-8859-1?Q?ToQfX6rXeqr58Tlg+jwG2Tqe6ShYPXhZtdRMNgITB1mmWbfQiTF0g8Zzza?= =?iso-8859-1?Q?G4gG68D9K9gDQ34bBH8YoRFq+Z1C41B+LUUReK0D2l57rSmwttF8wDVQNC?= =?iso-8859-1?Q?1e6Wg+5oBbGXS1UAqxMt9pGqHoifWY9yaFq1U4AyezH73RO1vU3X0SubyK?= =?iso-8859-1?Q?qG1hWPAW62HpCvj6ALavxVz9czdSBOpj7G23pO9BkBjrzqn8uOxA4mR2fn?= =?iso-8859-1?Q?1xvDaowTIxF95sZuUwEEi0w2bVJisHCA+XsApDYOvi61JJUGUYcPkPoAGt?= =?iso-8859-1?Q?NXwWHupp0psGnbEZUZtC9SNpp+4PfyGcMrIGNzqUXr3I3imfGOfd5Ze2zy?= =?iso-8859-1?Q?nk8Qj4U/T4hLdkJBiNT4PKwzpH/qatujOWRTsCRi4JJohtKpsTveJ/kzhj?= =?iso-8859-1?Q?xQOprkJH1RgswmtmbdweWjSvKtz1oWauQ7QwYV0D1bWngdZ6POTzQGWLES?= =?iso-8859-1?Q?RyiAm3b/SsbR0F21qI185WFlPlJeY7fwD/A0+33mRWErR485Rn4D+5c0jC?= =?iso-8859-1?Q?2OIhCoypVNN6usg15RF6H0DZwMSPed0f8dRt5vWEzMHu5q7dhTqhz9lZnu?= =?iso-8859-1?Q?EFI5huNQC+rJc20o/nacPjQIvPIcSjxjstPwgUNgawe/phMcJT/BVmI8n8?= =?iso-8859-1?Q?QjYwwfZgV4qWwAJsOoS6KxFADIRHVhg=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f60d11a-1ec8-452a-7fe7-08df19089602 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2026 00:21:17.6811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: d6cHct4bt31QbqGEs7TEalAlU6E7+FsyEOAARKVJ6S4bxWlMKcADISyO3AD2kgMPdVB/4R/4jP8TPXAR29eUfUx6D8z6yDQLia6q5bLa+V0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB10167 X-purgate-ID: tlsNG-42698a/1790122880-1A6DA9EA-EE277EBE/0/0 X-purgate-type: clean X-purgate-size: 6323 Hi, Mykola Kvach writes: > ITS quirks are matched only by IIDR and mask fields stored in each table > entry. That is too coarse when the same GIC IP block appears on several > platforms but a workaround is valid only for some of them. > > Replace the fixed IIDR fields with a generic match(hw_its, data) > callback and an opaque data pointer. Add an IIDR matcher as a reusable > building block and use it from the R-Car Gen4 matcher after checking the > Renesas machine compatibles. > > This intentionally narrows the R-Car Gen4 quirk. Previously every ITS > with IIDR 0x0201743b matched. Now it matches only a DT-discovered ITS on > an r8a779f0 or r8a779g0 machine. ACPI-discovered ITSes and the same IIDR > on other platforms no longer match. > > Keep first-match semantics explicit. Assert that non-sentinel entries > provide a matcher and that IIDR matching receives match data. Retain > runtime guards so malformed entries cannot cause a NULL function call > or data dereference in non-debug builds. Place the matcher data and > table in init-only read-only sections. > > The matched entry still supplies separate ITS and LPI flags; this patch > only changes how the entry is selected. > > Signed-off-by: Mykola Kvach > --- > Changes in v3: > - Document the intentional narrowing of the R-Car Gen4 match. > - Add the non-debug NULL-data guard. > - Put the matcher data and table in init-only read-only sections. > > Changes in v2: > - Replace v1's optional platform callback plus fixed IIDR/mask fields > with a single generic match(hw_its, data) selector. > - Add a reusable IIDR matcher and use it after the R-Car Gen4 > machine-compatible checks. > - Document that the R-Car Gen4 quirk remains DT-only. > - Keep the split ITS and host LPI quirk scopes when applying the matched > entry. > - Document first-match ordering in the lookup path and guard against > entries without a match callback or IIDR match data. > --- > xen/arch/arm/gic-v3-its.c | 73 +++++++++++++++++++++++++++++++-------- > 1 file changed, 58 insertions(+), 15 deletions(-) > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > index 454fd0e0ef..f52232ca40 100644 > --- a/xen/arch/arm/gic-v3-its.c > +++ b/xen/arch/arm/gic-v3-its.c > @@ -54,8 +54,8 @@ struct its_device { > =20 > struct its_quirk { > const char *desc; > - uint32_t iidr; > - uint32_t mask; > + bool (*match)(const struct host_its *hw_its, const void *data); > + const void *data; > uint32_t its_flags; > /* > * lpi_flags are ORed into the global host LPI policy and must only > @@ -65,11 +65,52 @@ struct its_quirk { > uint32_t lpi_flags; > }; > =20 > -static const struct its_quirk its_quirks[] =3D { > +struct its_quirk_match_iidr { > + uint32_t iidr; > + uint32_t mask; > +}; > + > +static bool __init gicv3_its_match_iidr(const struct host_its *hw_its, > + const void *data) > +{ > + const struct its_quirk_match_iidr *match; > + uint32_t iidr; > + > + ASSERT(data); > + > + if ( !data ) > + return false; It looks strange to have both ASSERT and then this check. Maybe it is worth to remove ASSERT and print a warning in a debug build ins= tead? > + > + match =3D data; > + iidr =3D readl_relaxed(hw_its->its_base + GITS_IIDR); > + > + return (iidr & match->mask) =3D=3D match->iidr; > +} > + > +static bool __init gicv3_its_match_quirk_gen4(const struct host_its *hw_= its, > + const void *data) > +{ > + if ( !hw_its->dt_node ) > + return false; > + > + if ( !dt_machine_is_compatible("renesas,r8a779f0") && > + !dt_machine_is_compatible("renesas,r8a779g0") ) > + return false; > + > + return gicv3_its_match_iidr(hw_its, data); Do you really need to match IIDR in this case? You already know that platform requires the quirk. > +} > + > +static const struct its_quirk_match_iidr rcar_gen4_iidr __initconst =3D = { > + /* Implementer 0x43b identifies Arm Ltd. */ > + .iidr =3D 0x0201743b, > + .mask =3D 0xffffffffU, > +}; > + > +static const struct its_quirk its_quirks[] __initconstrel =3D { > { > - .desc =3D "R-Car Gen4", > - .iidr =3D 0x0201743b, > - .mask =3D 0xffffffffU, > + .desc =3D "R-Car Gen4", > + .match =3D gicv3_its_match_quirk_gen4, > + .data =3D &rcar_gen4_iidr, > .its_flags =3D GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADD= R, > .lpi_flags =3D GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADD= R, > }, > @@ -78,18 +119,21 @@ static const struct its_quirk its_quirks[] =3D { > } > }; > =20 > -static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr= ) > +static const struct its_quirk *__init gicv3_its_find_quirk( > + const struct host_its *hw_its) > { > - const struct its_quirk *quirks =3D its_quirks; > + const struct its_quirk *quirk; Is this change really required? > =20 > /* > - * The first matching quirk wins. More specific quirks must be liste= d > - * before broader IIDR-only entries. > + * The first matching quirk wins. Entries that match a specific plat= form > + * must be listed before broader IIDR-only entries. > */ > - for ( ; quirks->desc; quirks++ ) > + for ( quirk =3D its_quirks; quirk->desc; quirk++ ) > { > - if ( quirks->iidr =3D=3D (quirks->mask & iidr) ) > - return quirks; > + ASSERT(quirk->match); > + > + if ( quirk->match && quirk->match(hw_its, quirk->data) ) > + return quirk; > } > =20 > return NULL; > @@ -97,8 +141,7 @@ static const struct its_quirk *__init gicv3_its_find_q= uirk(uint32_t iidr) > =20 > static void __init gicv3_its_collect_quirks(struct host_its *hw_its) > { > - uint32_t iidr =3D readl_relaxed(hw_its->its_base + GITS_IIDR); > - const struct its_quirk *quirk =3D gicv3_its_find_quirk(iidr); > + const struct its_quirk *quirk =3D gicv3_its_find_quirk(hw_its); > =20 > if ( quirk ) > { --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Wed Sep 23 00:29:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 00:29:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429577.1652387 (Exim 4.92) (envelope-from ) id 1x9Aru-0003uc-3t; Wed, 23 Sep 2026 00:29:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429577.1652387; Wed, 23 Sep 2026 00:29:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Aru-0003uV-0I; Wed, 23 Sep 2026 00:29:50 +0000 Received: by outflank-mailman (input) for mailman id 1429577; Wed, 23 Sep 2026 00:29:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Ars-0003uP-Cu for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 00:29:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Arr-005tZy-7s for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 02:29:47 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab31d54-8faa-0a2a0a5109dd-0a2a4508acba-16 for ; Wed, 23 Sep 2026 02:29:47 +0200 Received: from [40.107.159.104] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab31d7a-f659-0a2a45080019-286b9f682f76-3 for ; Wed, 23 Sep 2026 02:29:47 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS8PR03MB9722.eurprd03.prod.outlook.com (2603:10a6:20b:61e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 00:29:42 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 00:29:42 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jY1BuutTHrOXanck5yd38LBM/2QibLwOadC4sDRwjR0xMG43mlmGvJbSitfddi3P411XOb5xMiD68SAM2qfaKMr4dlKYAsXRzFKf1zKqHUea+bVwpBoJJrxp0bfuKZSigESUSAoxBe+w/UCF9C9hHD9qWltqInh0u5L1eVMMeXBWKGydJSxVbaEVoRy7D5K5Ii+MyKKOpAtWZpIrWJzcV9UrDsavee/atHYVu2HyOQvCO6OME8NWqNdL2eFnT5JBOGF8eYEAL+/XWzKkYn3K2ga4pT/gauVL2wmGWH0pTJGs4FOCdIOEBlplFr2tp/Wqm45RHNpCepYAcuuA7bJBjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IPMzW6Xow40ZOnlzOKr0ty5B8RH0cA/iIO6XNEixvhI=; b=q2RFzck0kZ5fpBowXhSZ76kC5XbS314u73SVPVZsaINorJr5K3KPTps98FatzwpY4Q5Mcunuh2GpmWyrIXYD6J565iswFXSFhvxiLGe/ibHrGOn1lPYevBlXpuXDuspOJXSgvWK4yFfnaZohpUqRmvtnfocA3M8yhskU+6Bkabnd9KDFjDV17+NEvpNWZR2krdUQU53gdPAkgc5JvhLULW7Epv+FnC28nhAL0k7hrwRM8lJEid2qnNBg8VM++rH36KQGlI/abnoLoD1NL42YJC2lx4/Ys/AY3kUPMPAa9KmY5v10TGbn9cZWiwrycjYaMaWqUn3EBNP0JgKSjMVOBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IPMzW6Xow40ZOnlzOKr0ty5B8RH0cA/iIO6XNEixvhI=; b=spGUjFhAlpwIOXz/+l84n62OiuK8lUiddF3m6S4iJ3khKigLPwEgr6+wdRJKhTPZwJDs/hweuP9245kSELh0SIu5cqw+9cuCyRh59ANDJpaaoul2RgLTb/5JSOlWl8OEy/cY47H2i517M1ZjQJwc/vRLOYMRgzuk51Dx8qBMcDGsb9hYL2KD52JodGYaKT9wVR9TM3pzMd8yHXCzRSG3QyEINgpoefMSSeaq8dYy12StwEPgTRHgohfjQJp1MYQi5Qc7Ze9s4m3WExzsG8TS4LizMKAmLiZKQ4Nxll62FTT+DXPVHcA19lkvxNvhkvmDLzo1ZkmZGnq1iE7WqZJdzA== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v3 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes Thread-Topic: [PATCH v3 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes Thread-Index: AQHdSqtNhuAYUgdtlEG2grNEEh5N0w== Date: Wed, 23 Sep 2026 00:29:41 +0000 Message-ID: <874ifg4xoq.fsf@epam.com> References: In-Reply-To: (Mykola Kvach's message of "Tue, 22 Sep 2026 18:58:42 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS8PR03MB9722:EE_ x-ms-office365-filtering-correlation-id: 23ef156c-b3f5-4574-79a5-08df1909c2b6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|1800799024|366016|23010399003|376014|11063799006|10067099003|6133799003|22082099003|18002099003|56012099006|4143699003|38070700021; x-microsoft-antispam-message-info: XZ7BcVbUn+oFq3p191wLIVBWUm1ztytiuj2TBa5VbqeF8VF3/hYPGLamP9XDhwEdF51bSzsnCwmntWjBuRCuALEe0xZ0/0yfV+Vl84KUPGLN/h69JGav6aiUrYRkJFhfMPAE/9ijyNG6xjhPKUD+JRfGATQuay2SsD59wXkYftfU93uL03hBBwYYoHJDqukIR06x3U4bYTvzFHx/tXvNirE27vFPs2WV6bUwANnXgAHKwZKRFjXH0Yl0U0d6S6cCV/ELVzxhwpADW4//Fvi2KUDgyNV8rPk9JSKRxnTR1zvPgWbzTxzxeA/P3qETfOVkX8c/9AqXZyr3hvB9Lo5cCFoLEk+fYKqwoYmhRaq5r2svguWwXJbwgw1dC9S0742OchAhIHmgev0dRsO4ANB16KdDXHZDdyOWQplck0ENQAyX5woTakEcuv3cBCClinzwHYD8nTjO5/NFQy02uOo3KIO6hRjLXuaylAV7z+7T6GxNH0kKphiwj9DaCaHD/Yn1RcB+cmND8MeGAmKEvDLyJVBRpLUM6gaw766M0xu11kLDj4RdP+wG95NO4l/jWRGuf46J5W9QY3iWm1qMuavMrLn33lBbZdfycqfzYTBl12PGQZ2zUXGUgC6Gi9rC5Yw/kt3MxX4WrptJveYUKUBbm2cQA+StLF6nMUI+3vMlgWefjOoGq6+7Ov/9sk5WTr+yKD2e8ijIpJEjEvENmo/OJXx51dAgxQB4toJVMg9RwVU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(1800799024)(366016)(23010399003)(376014)(11063799006)(10067099003)(6133799003)(22082099003)(18002099003)(56012099006)(4143699003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?29M2ZIu+TIHcW/pUvjMSIMHr4/zHEWTryFvhKy/Wp/9+FETedQa3S8EKyP?= =?iso-8859-1?Q?oCYxl+uXUyIT2xq+k3GPKT6ksgWevkBrRAIgJdfKWz/JUgRhEM8Xf1bf/y?= =?iso-8859-1?Q?aUCmGfbjw/LNhydi7k8EXTVwqIhpZMKJbU1Ir6gCA/2NRy9CYon/E3wKYs?= =?iso-8859-1?Q?jArJhw/cDjMohV6ygac8Ao4+DOP3lDhMOOZZXwxyRdBtaXWkdvmOr4gQD+?= =?iso-8859-1?Q?WA1ZuGJkDNWzBlSFuXcILYW3YWBEe5J2sGjdIrC2Z23Gsir/+DAFTSDn5N?= =?iso-8859-1?Q?4sorfigfCqaXZmFQFwdEO2A16cPUMyn8rvXooRNQArXoRckF3qBtEJIetD?= =?iso-8859-1?Q?gH7QInmOQ7SqQPaWeAprfgYEtFq9Xk24hMIrfjETEO6xUfTzBcXYgkfudi?= =?iso-8859-1?Q?pni+psoLTcLlYRkxlJ5BICWY//habtrHNWCltM5phGeR6OFIRHgnLLNWqE?= =?iso-8859-1?Q?zfvEDFWGBsdq9f9nvLffanCygTB8/u/wBQxuMZVQlIOppSAKmWQ2XFPWy7?= =?iso-8859-1?Q?jrRdp+lLdW7NTILh8oONDsyF/qhNGdh180H/iKsuXbtxkGP8HS3bEWRdJj?= =?iso-8859-1?Q?Ab5DJjrtmUEECoTb0Uvn7olNgMk8nC6qP7fpxCCdX2ZNbAOIW6YHCiyngh?= =?iso-8859-1?Q?kVC9cWRUhjL2q1OB/7TK9wBIPQ2eTveuuA1B8Fh4Zy+TmRA0ecdQbfixPp?= =?iso-8859-1?Q?XvipHqvOlN+rGOHRc9j8lfMaQQu3e0TNekOlzBk6XLh/L1S+BfgDnfwejh?= =?iso-8859-1?Q?ZFo6uQZ9GxB+A1tw3g0V5sPlOj6Z06tgPVtPPJeZvZN3vdUcV2YFxe8byp?= =?iso-8859-1?Q?WarIJM93a7Obu2hoKFBJNquWkkLJot1pxYZwZgMkHMrU29RjzqaIWmC6eW?= =?iso-8859-1?Q?2t+abdjAGhxVz8hMTxL9S34YhFchjf5Q3DL7Jrwq67lIPZCC0U7f8X0QZJ?= =?iso-8859-1?Q?u2OrzSkdrHjDGB4AZEE1s/byxsy0p6aIH9C178BoroBfnwmcRWEsSruiaW?= =?iso-8859-1?Q?PZFr9jO+fku6OBQu+aGVArBOTRaQI9B2vkUO6zSng7Sbj7VQgMvi51KGKD?= =?iso-8859-1?Q?dwDma9dh/0TJdLHvFRVj2BJS84BqPgyGnSbYswbhklOpL6L+cnJIGL5YHX?= =?iso-8859-1?Q?kodYS8CpafKoPZbk+Fc2a/coz0K+HOu2i7qwdqXh7m2KqLjRkH7u4vhrVN?= =?iso-8859-1?Q?ffy68YzWOz/Xn6GLWegTQgevfNES/mWjGluDJMZxZDZK6A82mKSnQUPXIA?= =?iso-8859-1?Q?GsLZpnVTvDN/UdYylusb1Oa/WD1OAo+UHBAgILYYg44S57pW+EluIP+97J?= =?iso-8859-1?Q?vBSZuKAKIzEIcwsTPaPY4jMQaZnb2sqxgnV1JDES5+zDKOZNZgltA6OSXS?= =?iso-8859-1?Q?NgfLijXf1FC97URBnib8ccFE+kmjDM8NpqR2KpBDHHMFaCdBUywxdjDsLI?= =?iso-8859-1?Q?8SSBvZJE4mqW8eb6qDl0F7/8WzdGhUrxS3jrX9iPnKA3djxlWqvXzWIg2s?= =?iso-8859-1?Q?kUuXIzGvUp4wLsZH0PedYkx0xF4jg3wt0qdDqmfHbWNlH3akq2XOMQB2EP?= =?iso-8859-1?Q?L7yrTEQ2NOXkKRL9atLGQ7VUk95hd2WgTdk7btOqiJ8sZ4wR4TOXshChoQ?= =?iso-8859-1?Q?uD+f2ROPE5/+fhCHA3W6saCSnW+zSbyq/iPYV6XXzDCd/+KHbHWPeKrSs2?= =?iso-8859-1?Q?qBZtf4B0IxeUTtN2d8QCRj9CgJ3wMOH8WCffsQw0/N1Yekys5GaFhxb1Oj?= =?iso-8859-1?Q?HyXGj+Ufpm9Va//s49bU+vzftRkU3B1t8TVMuCpduYH+v9qLOiJVrJThC8?= =?iso-8859-1?Q?rhkGDh+xJyMovKFx32ByrC6vvzIao1M=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23ef156c-b3f5-4574-79a5-08df1909c2b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2026 00:29:42.1468 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Dcm7wefXw8ySKTdYRFBIpBhqjpoLX4sIJqYJsSqhXbTxcfqbk0ZGEVD5AVU6EsIMlQUCQwDnCNoFf0Q4G5NM8ap1rmqWXCSS25NxDM6imw0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9722 X-purgate-ID: tlsNG-c1860d/1790123387-D6D4087B-A12D9E76/0/0 X-purgate-type: clean X-purgate-size: 5084 Hi, Mykola Kvach writes: > The DT dma-noncoherent property describes the bus coherency of the > device represented by the node. On an ITS subnode, that is memory > accessed by that ITS. Add GICV3_QUIRK_MEM_NC_NS to the corresponding > host_its and use it when programming GITS_CBASER and GITS_BASER. > > On the top-level GIC node, the property describes the Redistributor side > of the LPI path. Collect it in gicv3_lpi_init_host_lpis() and apply it > only to the host LPI policy used when allocating the property and > pending tables and when programming GICR_PROPBASER and GICR_PENDBASER. > Mark the function init-only because firmware attributes are collected > only during boot. > > Do not inherit the property between parent and child nodes: ITS-node > non-coherency does not change the global host LPI policy, and GIC-node > non-coherency does not change per-ITS quirk_flags. > > ACPI is unchanged; this patch only consumes the DT dma-noncoherent > property. > > Signed-off-by: Mykola Kvach > --- > Changes in v3: > - Keep the ITS init annotations with the earlier initialization patch. > - Drop the redundant aggregate host-LPI-flags message. > > Changes in v2: > - Split v1's dma-noncoherent handling into explicit ITS-node and GIC-node > scopes. > - Apply an ITS subnode property only to the matching host_its > quirk_flags. > - Collect the top-level GIC property from gic-v3-lpi.c before host LPI > allocations use host_lpi_flags. > --- > xen/arch/arm/gic-v3-its.c | 17 +++++++++++++++++ > xen/arch/arm/gic-v3-lpi.c | 20 +++++++++++++++++++- > 2 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > index f52232ca40..6734f94e7c 100644 > --- a/xen/arch/arm/gic-v3-its.c > +++ b/xen/arch/arm/gic-v3-its.c > @@ -139,6 +139,21 @@ static const struct its_quirk *__init gicv3_its_find= _quirk( > return NULL; > } > =20 > +static void __init gicv3_its_collect_fw_attrs(struct host_its *hw_its) > +{ > + /* > + * An ITS subnode property describes memory transactions made by tha= t ITS. > + * Do not inherit it into the global host LPI/Redistributor policy. > + */ > + if ( !hw_its->dt_node || > + !dt_property_read_bool(hw_its->dt_node, "dma-noncoherent") ) > + return; > + > + hw_its->quirk_flags |=3D GICV3_QUIRK_MEM_NC_NS; > + printk("GICv3: ITS @%#"PRIpaddr" marked dma-noncoherent\n", > + hw_its->addr); > +} > + > static void __init gicv3_its_collect_quirks(struct host_its *hw_its) > { > const struct its_quirk *quirk =3D gicv3_its_find_quirk(hw_its); > @@ -149,6 +164,8 @@ static void __init gicv3_its_collect_quirks(struct ho= st_its *hw_its) > gicv3_lpi_update_host_flags(quirk->lpi_flags); > printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc); > } > + > + gicv3_its_collect_fw_attrs(hw_its); > } > =20 > uint64_t gicv3_mem_get_cacheability(uint32_t flags) > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > index accfd48a74..1cf49430ea 100644 > --- a/xen/arch/arm/gic-v3-lpi.c > +++ b/xen/arch/arm/gic-v3-lpi.c > @@ -7,7 +7,9 @@ > * Copyright (C) 2016,2017 - ARM Ltd > */ > =20 > +#include > #include > +#include > #include > #include > #include > @@ -102,6 +104,20 @@ void __init gicv3_lpi_update_host_flags(uint32_t fla= gs) > host_lpi_flags |=3D flags; > } > =20 > +static void __init gicv3_lpi_collect_fw_attrs(void) > +{ > + /* > + * A top-level GIC node property describes the Redistributor side of= the > + * LPI path. Do not inherit it into per-ITS policy. > + */ > + if ( !acpi_disabled || > + !dt_property_read_bool(dt_interrupt_controller, "dma-noncoheren= t") ) > + return; > + > + gicv3_lpi_update_host_flags(GICV3_QUIRK_MEM_NC_NS); > + printk("GICv3: Redistributors marked dma-noncoherent\n"); > +} > + > static union host_lpi *gic_get_host_lpi(uint32_t plpi) > { > union host_lpi *block; > @@ -443,7 +459,7 @@ integer_param("max_lpi_bits", max_lpi_bits); > * to the page with the actual "union host_lpi" entries. Our LPI limit > * avoids excessive memory usage. > */ > -int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) > +int __init gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) Spurious change? > { > unsigned int nr_lpi_ptrs; > int rc; > @@ -451,6 +467,8 @@ int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bi= ts) > /* We rely on the data structure being atomically accessible. */ > BUILD_BUG_ON(sizeof(union host_lpi) > sizeof(unsigned long)); > =20 > + gicv3_lpi_collect_fw_attrs(); > + > /* > * An implementation needs to support at least 14 bits of LPI IDs. > * Tell the user about it, the actual number is reported below. --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Wed Sep 23 01:02:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 01:02:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429593.1652396 (Exim 4.92) (envelope-from ) id 1x9BNO-00082B-D0; Wed, 23 Sep 2026 01:02:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429593.1652396; Wed, 23 Sep 2026 01:02:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9BNO-000824-8l; Wed, 23 Sep 2026 01:02:22 +0000 Received: by outflank-mailman (input) for mailman id 1429593; Wed, 23 Sep 2026 01:02:21 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9BNM-00081y-Of for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 01:02:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9BNL-00HVLp-GF for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 03:02:19 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab324ea-2eae-0a2a0a5409dd-0a2a45038456-32 for ; Wed, 23 Sep 2026 03:02:19 +0200 Received: from [52.101.65.93] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3251a-fae8-0a2a45030019-3465415d7629-3 for ; Wed, 23 Sep 2026 03:02:19 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS8PR03MB7287.eurprd03.prod.outlook.com (2603:10a6:20b:2e9::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 01:02:15 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 01:02:15 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pkU53dj6oy9cCxoVl03qUscRvSLbFyHNqf2TGo1szWgrJaSpahh5qEDDAIaJdyDTj9pSUpmPQ1O1GyQfNPoRRVNBBA1knRS1GRgGUA7fToLba/9L+I68BVRxi1zK2a33+8lVQ1jmdCKjpVhr5uEklWovwE1JlQNQ7zRpQsF7yHEsfJkAAO/a9idzHL/iRI0PLQNOVz3HCWOSC7Or0sKPzUqSTKpQOVXpLw/s3HstCL96nYxvm2b7lp1/c13+8UuD4lA9XVbCDfpTCnTzKPWmwfoNtp78u5KNXBG/PvDWPAXVvSlMio2EBBTyAC12HJ6v4hNF9ooHdbsmgBXmW+l2aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=H9arWjSQGMWdOSlFAXj0u8ZR/Hu4tznMqBnk0eEaagc=; b=rfPt1lwl/yARDQ8GnL4soe0Sk+uYBgb1OCW4TVeQjG0L/JUOBC5d7bH/WJVbIZUpX1VCBMHQnDOaiAScIfLhQMaOGFM0VVEiyiC4iR6xRqk8KGwvBBhFhdhDMX2/Vwr7gPMr8BcKzE13kpbcm5gabMfw+N2SbhT8LO2lsW0Dm2KbnHAUD8WywF06TOxQEE1Q5szBJBOjPPdKwG06ElqG+uWXn9ohHjwK44E1VyzHoigw7AHbPK037uCdOhgG8tfwOxzS5Cto+tmUUbMMZEID6yPe9Adkq87LvbHndERXykeVi2LfF57B6p8ny6aDIDcPPbQ4bThlQUNtOTU8xq2iWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H9arWjSQGMWdOSlFAXj0u8ZR/Hu4tznMqBnk0eEaagc=; b=pgs5eR1aYzngRuqQyqn8vmCjG5EjmWckg4d3z4lYZfEmgPqJtc7N275/ZYlFq2TrVzIdflnxJWHG64FCUpzlOdSCJxXtVQWpcuHDTwt/lpyvQUeMMqzqabP23MopG8Nka6RGn3tSLNJCBe8PGFZ42XqYGjwtJt0SWcoolXjUl57RwdaRfQg16TVILSQU1DggDgjVCWH2K2G4QS1+hKTtOAYG6kexIuxrQykkfwdghWWJyblDxGe6YgaL2z2qNRZVPcGwQ/FUSxDYg8XaTnCrGfYDA0ubkZQjZnmM7gPKfhktLsBdeVEs5vAncNiqmWAWhFGcXP9tx2GJIeje7Imerw== From: Volodymyr Babchuk To: Oleksii Moisieiev CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Grygorii Strashko Subject: Re: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdSqBPF0kScKehyU2HqE/MZamZRQ== Date: Wed, 23 Sep 2026 01:02:14 +0000 Message-ID: <87pky43hm2.fsf@epam.com> References: <5c3ae163d21f619bf25c8757232a1a0867c3eb87.1790087968.git.oleksii_moisieiev@epam.com> In-Reply-To: <5c3ae163d21f619bf25c8757232a1a0867c3eb87.1790087968.git.oleksii_moisieiev@epam.com> (Oleksii Moisieiev's message of "Tue, 22 Sep 2026 14:40:25 +0000") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS8PR03MB7287:EE_ x-ms-office365-filtering-correlation-id: 3d04d75e-dc58-4fa5-20a8-08df190e4ef8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|1800799024|366016|7416014|23010399003|376014|11063799006|10067099003|6133799003|3023799007|4133799003|22082099003|18002099003|56012099006|4143699003|38070700021; x-microsoft-antispam-message-info: xSMwu7Gu0EKAEVJ7NVCMdZLOf3mOSF5SFRRpg2J0S1g51h8so3TFy7veKtZ6VP3kLuUgrwvQ0TyFxSxD6on9JqeZ828IYTkMMZ/q2LEwcocRJN8q4EwkHc6g7Nr6+yZ4aWv2xva9FoH1tBxuFq/RZbzwFZCSgEYYeK/TUxgoe//acYBBbegVk0uSgWbRsl3p1n+94wZYYLFh953ukm6oFyrQGyneFri+/Cyr/cjoPsANpOfqM/LKVZX6vCl2dlqwdMqcuheZqdKRhtn+V43oTLrYNU7FB+A8jKgDx9e87tvzPA5+eEeVBWrznoo13MuDqikei9y9M8PRekCBlkLBR7Vqlm8xgRdC2tAEhRIUeMvSO64hTJRfiCpZYxlzS4ob2RqB9P6u9uwdpNrw/7+ds0pEW8Ke/tCiEspEiOyBA1QMvU3PNF9HbgrGhSrDiyk5+55faiV4RKlqJjl3RYEarSUWTzqvzRF3pTz3e+G1ZPH2EBQO0g7aRdd6I5qQYz5xhV1El+cRQV3vggwODu9NMVlpiJ02zFZe8WdwMmZIJ7Vszp3a4g/y4nXZk1+0WLGireuI3GRpAO+euuvr37XEdRWAXY4yDpBUeGQvB/YEmr5kFhdkeQi6Dg84NMlDQZMUzFLzY8YguVk8OsSgHmKenrZ9uuYH3az6CST0O27t41Uhu4mhXnX2xppaUpVIn0gS x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(1800799024)(366016)(7416014)(23010399003)(376014)(11063799006)(10067099003)(6133799003)(3023799007)(4133799003)(22082099003)(18002099003)(56012099006)(4143699003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?1ca5qAnDu9WSuAcQ8FNBPc2QoNrRKSTIWSUGk1ez4dcLM+NLX0d3ODMXp2?= =?iso-8859-1?Q?fBoJPo6XcaFmW9uR9NYK0xNOo/mjW9hOxhuF/87LUAHoFjRGcnFpbGXOn4?= =?iso-8859-1?Q?jCBtao9RTeTDcLZMzROQMnsl/kCKAZYl3PqX6nhLVb+R8ktuhdOyV2T7jv?= =?iso-8859-1?Q?72dxpKtKeQWlasaQgy5kV0Z5EwYJLoa/EXXh+WjUCfNMMcccFEqCmXD9KB?= =?iso-8859-1?Q?Y8s1FNkH7dmFYdwNJqRAWm5QqvXM/mQJ5LjG1d0L7r7t4E/Gj21UdQQbbT?= =?iso-8859-1?Q?XuXA8S3wI0bGEn9RlEZANA8AwadTOmZaqrFGEUcLPkfXdZUjHyh+914fCQ?= =?iso-8859-1?Q?2rA+qC4DmYIBX9eSacrGn4GJHJyJNgsFzPoSXzGbEtn6dDTEnhfLpAAIbn?= =?iso-8859-1?Q?yXnjDlp553iMFJ0VUH2io9Ri+FMv176a7lR/7HUYwrnA9i4I6usgi0GV/1?= =?iso-8859-1?Q?zlQDsSjC5BubwA+9B54oNVqKijlZM31IkqDGPoQsx/Q4GFGZ43Cqa2Tj0/?= =?iso-8859-1?Q?W09Ao3c5u4ubLIlIfA2SZCqlhljpAkqQB5lFSIzgZH4jNlHagysRIeFIQQ?= =?iso-8859-1?Q?IQnh1a3LSOXB3jzcp6vxMgwqomETkDLckgwTVGr1JmkLCrTmzUii+u2MXS?= =?iso-8859-1?Q?KIOkC2e9UF4E2EynzGizgzfYE3EEP7Dzfq1xR3sp+c7sWFYn/oD3E8N1Ez?= =?iso-8859-1?Q?Luj9h6XESegk/MJLhNJqAsGek5bncfX+K9X3tYwhXZBidrvmaB09T7pT9T?= =?iso-8859-1?Q?5lcPLqMQVl8CRgOsKGtWdc95uLor9BdvMrNVzvhSGnqTjjStYY48gThXen?= =?iso-8859-1?Q?dUj0eziLYYs2MMntxURZMf2jbDl2kw3OlMfsmgysq0OE1KrvZoYsX9mNKe?= =?iso-8859-1?Q?wiwJs+f2vKVjgfTBWPEYY+C2X+1X8UCmlj1HKWcM6O1vhp+cXQefyAgtYe?= =?iso-8859-1?Q?bledyFZGIi919nJkDGrCX224gpFVWdRowOUJ/3aJHtK4Y1zwPbnA70A/Td?= =?iso-8859-1?Q?7h40IExjpeX5kppvDCVrCeszaeWYPtxS42KBf1QUm9yls/QjDHZAAkpmHo?= =?iso-8859-1?Q?3KkpMtpdmqZaceurnEJReMYEZA05PpvODiIxvRCJumA5HtjjnUNMp7yz6S?= =?iso-8859-1?Q?DaHuR608PBuI0/KTDe81KBC2aUz21ZblpYbiJxxtHe7yF0EZNUpozJiZmu?= =?iso-8859-1?Q?ELUMAv+4VEVfL9Ie64gA4xO4NofsL4haUcnoNAteFUa/ERHr2Ccvp9b7hc?= =?iso-8859-1?Q?ZPKmNafkLjZiSokFK192ddmFnm7TbJgqMi67m66ILucqETSDwJMMVEnK8s?= =?iso-8859-1?Q?HkZIHSX+j1S6CzTANzCSZSKiLgmdMn7A94Gog6EdVrGzgmC+rMTDi5bt9p?= =?iso-8859-1?Q?igfnQi7owYAtfMZ1Z6wv9gTaSajMIjq1iKp34k9l44BmojoYUomtYuISyw?= =?iso-8859-1?Q?C2ukrerPW59Kex4BU3WXsNnOGZm+cM4vk9BhVnI+dgjmd0euI/7Bqk8oWp?= =?iso-8859-1?Q?9IchBOsbMBQq8Mk9xfyAQVps0DqzjwP0UKC93YwiKrb4rjRvR7SCywxBRf?= =?iso-8859-1?Q?+tgoxQ4ntfMlQMub/T9n0Ey9i6r+abWA9kuAUFm+GY/G8PuP6Ku9cV2aZx?= =?iso-8859-1?Q?UA20oDVi/LBYF27bTFEmd9YszJkeSrdiBpQ87RKOs0G7EbkVFXAdX3favs?= =?iso-8859-1?Q?bYeZJyr3OpZXw9laqP6gcWn9S0hcrQX6a7jYgt9W/oHZGVXlqGGpGG1oGB?= =?iso-8859-1?Q?zDWJK0DtRS6xcBUk494zBfaYsaFyyFVaGh4f/iEEFHa/QvQ81dqLJVSs6X?= =?iso-8859-1?Q?sv9L5RD9ZTwuvdYXCbwhpAZDtNqrnRM=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d04d75e-dc58-4fa5-20a8-08df190e4ef8 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2026 01:02:15.4862 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FN4yYaeHmD5jzry+BO8ADYG50oSYFcq+Bv9bcVFMrZnhRXoy7KbQzbGGNeiGwie8FDOiwKzdAlp7aKubuTH5LHCw/Qj7x0JoXtpiELBkO3Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7287 X-purgate-ID: tlsNG-33051d/1790125339-6ECCB749-0786EC0B/0/0 X-purgate-type: clean X-purgate-size: 74331 Hi Oleksii, Oleksii Moisieiev writes: This is a great piece of documentation. It is larger than the text you added to the 'doc' directory. So I believe it is better to put into a design document, so it is will not be lost in the git commit messages. > This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-= A > (TF-A) which provides SCMI interface with multi-agent support, as shown > below. > > +-----------------------------------------+ > | | > | EL3 TF-A SCMI | > +-------+--+-------+--+-------+--+-------++ > |shmem1 | |shmem0 | |shmem2 | |shmemX | > +-----+-+ +---+---+ +--+----+ +---+---+ > smc-id1 | | | | > agent1 | | | | > +-----v--------+---------+-----------+----+ > | | | | | > | | | | | > +--------------+---------+-----------+----+ > smc-id0 | smc-id2| smc-idX| > agent0 | agent2 | agentX | > | | | > +----v---+ +--v-----+ +--v-----+ > | | | | | | > | Dom0 | | Dom1 | | DomX | > | | | | | | > | | | | | | > +--------+ +--------+ +--------+ > > The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared > memory transport for every Agent in the system. > > The SCMI Agent transport channel defined by pair: > - smc-id: SMC id used for Doorbell > - shmem: shared memory for messages transfer, Xen page > aligned. Shared memory is mapped with the following flags: > MT_DEVICE_nGnRE. > > The follwoing SCMI Agents are expected to be defined by SCMI FW to enable= SCMI > multi-agent functionality under Xen: > - Xen management agent: trusted agents that accesses to the Base Protocol > commands to configure agent specific permissions > - OSPM VM agents: non-trusted agent, one for each Guest domain which is > allowed direct HW access. At least one OSPM VM agent has to be provided > by FW if HW is handled only by Dom0 or Driver Domain. > > The EL3 SCMI FW is expected to implement following Base protocol messages= : > - BASE_DISCOVER_AGENT (optional if agent_id was provided) > - BASE_RESET_AGENT_CONFIGURATION (optional) > - BASE_SET_DEVICE_PERMISSIONS (optional) > > The SCI SCMI SMC multi-agent driver implements following > functionality: > - The driver is initialized from the Xen SCMI container ``xen_scmi_config= `` > (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the > ``arm,scmi-smc`` node that is a child of this container will bind to Xe= n; > other SCMI nodes (for example under ``/firmware``) are ignored to avoid > stealing the host OSPM instance. > > scmi_shm_1: sram@47ff1000 { > compatible =3D "arm,scmi-shmem"; > reg =3D <0x0 0x47ff1000 0x0 0x1000>; > }; > scmi_xen: scmi { > compatible =3D "arm,scmi-smc"; > arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id > #address-cells =3D < 1>; > #size-cells =3D < 0>; > #access-controller-cells =3D < 1>; > shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem > }; > > - The driver obtains Xen specific SCMI Agent's configuration from the > Host DT, probes Agents and builds SCMI Agents list. The Agents > configuration is taken from "scmi-secondary-agents" property where > first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and > third is optional "agent_id": > > / { > chosen { > xen { > ranges; > xen_scmi_config { > compatible =3D "xen,sci"; > #address-cells =3D <2>; > #size-cells =3D <2>; > ranges; > > scmi-secondary-agents =3D < > 0x82000002 &scmi_shm_0 0 > 0x82000004 &scmi_shm_2 2 > 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id > #scmi-secondary-agents-cells =3D <3>; I don't think that this is the correct way of using -cells property. These properties are used either to provide information for **child** nodes (like #address-cells or #size-cells) or to provide a number of cells to encode a specifier for a domain (like #interrupt-cells). Here you are doing neither of these. I think the proper way is to define secondary agents as children: agents { #address-cells =3D 1; #size-cells =3D 0; scmi_agent_2: scmi_agent@2 { compatible =3D "arm,scmi-agent"; // Actually, I am not sure if // we allowed to use 'arm' names= pace reg =3D <2>; // Agent id goes here shmmem =3D &scmi_shm_2; arm,smc-id =3D 0x82000004; }; } With this approach you don't need #scmi-secondary-agents-cells at all and the whole structure becomes more device-tree-ish. > xen,dom0-sci-agent-id =3D <0>; > > scmi_shm_0: sram@47ff0000 { > compatible =3D "arm,scmi-shmem"; > reg =3D <0x0 0x47ff0000 0x0 0x1000>; > }; > > /* Xen SCMI management channel */ > scmi_shm_1: sram@47ff1000 { > compatible =3D "arm,scmi-shmem"; > reg =3D <0x0 0x47ff1000 0x0 0x1000>; > }; > > scmi_shm_2: sram@47ff2000 { > compatible =3D "arm,scmi-shmem"; > reg =3D <0x0 0x47ff2000 0x0 0x1000>; > }; > > scmi_shm_3: sram@47ff3000 { > compatible =3D "arm,scmi-shmem"; > reg =3D <0x0 0x47ff3000 0x0 0x1000>; > }; > > scmi_xen: scmi { > compatible =3D "arm,scmi-smc"; > arm,smc-id =3D <0x82000003>; <--- Xen management agent func_id > #address-cells =3D <1>; > #size-cells =3D <0>; > #access-controller-cells =3D <1>; > shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem > }; > }; > }; > }; > }; > > / { > /* > * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI > * enabled for it, ignored by Xen multi-agent mediator > */ > scmi_shm: sram@47ff0000 { > compatible =3D "arm,scmi-shmem"; > reg =3D <0x0 0x47ff0000 0x0 0x1000>; > }; > > firmware { > scmi: scmi { > compatible =3D "arm,scmi-smc"; > arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id > #address-cells =3D < 1>; > #size-cells =3D < 0>; > shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem > > protocol@X{ > }; > }; > }; > }; > > This approach allows defining multiple SCMI Agents by adding > Xen-specific properties under the ``/chosen`` node to the Host Device > Tree, leaving the main part unchanged. The Host DT SCMI channel will > be passed to Dom0. > > The Xen management agent is described as a ``scmi_xen`` node under the > ``xen,sci`` comaptible node, which is used by Xen to control other > SCMI Agents in the system. > > All secondary agents' configurations are provided in the > ``scmi-secondary-agents`` property with an optional ``agent_id`` field. > > The ``agent_id`` from the ``scmi-secondary-agents`` property is used > to identify the agent in the system and can be omitted by setting > ``#scmi-secondary-agents-cells =3D <2>``, so the Secondary Agents > configuration will look like this: > > / { > chosen { > xen { > xen_scmi_config { > compatible =3D "xen,sci"; > #address-cells =3D <2>; > #size-cells =3D <2>; > ranges; > > /* Shared memory nodes as defined earlier */ > > scmi-secondary-agents =3D < > 0x82000003 &scmi_shm_0 > 0x82000004 &scmi_shm_2 > 0x82000005 &scmi_shm_3 > 0x82000006 &scmi_shm_4>; > #scmi-secondary-agents-cells =3D <2>; > }; > }; > }; > } > > In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to > discover the ``agent_id`` for each secondary agent. Providing the > ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping > the discovery call, which is useful when the secondary agent's shared > memory is not accessible by Xen or when boot time is important because > it allows skipping the agent discovery procedure. > > Note that Xen is the only one entry in the system which need to know > about SCMI multi-agent support. > > SMC ID Configuration and SCMI Connection Compatibility: > > The configuration allows the same device tree to work for both baremetal > Linux and Linux Dom0. This is achieved because: > > - Baremetal Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 > - Dom0 Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 > - Xen management uses: func_id 0x82000003, scmi-shmem 0x47ff1000 > > This works because the privileged SCMI connection in EL3 firmware is not > tied exclusively to func_id 0x82000002. The EL3 firmware supports multipl= e > SCMI agents with different SMC IDs and shared memory regions. Each agent > (Dom0 via 0x82000002, Xen via 0x82000003, other domains via additional > func_ids) has an independent communication channel to the firmware. > > The key distinction is that Xen's management channel (0x82000003) is used > for privileged operations like agent configuration and device permissions > (BASE_SET_DEVICE_PERMISSIONS, BASE_RESET_AGENT_CONFIGURATION), while Dom0= 's > channel (0x82000002) is used for standard SCMI protocol operations (power= , > clock, sensor management, etc.). The firmware enforces different permissi= on > levels for each agent based on their agent_id, not the SMC ID. > > Therefore, there is no conflict: Linux Dom0 retains its standard SCMI > connection for hardware management, while Xen uses its separate privilege= d > channel for mediating access between multiple domains. > > - It implements the SCI subsystem interface required for configuring and > enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable > SCMI functionality for domain it has to be configured with unique support= ed > SCMI Agent_id and use corresponding SCMI SMC shared memory transport > [smc-id, shmem] defined for this SCMI Agent_id. > - Once Xen domain is configured it can communicate with EL3 SCMI FW: > -- zero-copy, the guest domain puts SCMI message in shmem; > -- the guest triggers SMC exception with smc-id (doorbell); > -- the Xen driver catches exception, do checks and synchronously forwar= ds > it to EL3 FW. > - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen > management agent channel on domain destroy event. This allows to reset > resources used by domain and so implement use-case like domain reboot. > > Dom0 Enable SCMI SMC: > - set xen,dom0-sci-agent-id=3D under the xen,sci container in > the Host DT. If the property is absent, SCMI is disabled for Dom0 > and all SCMI nodes are removed from the Dom0 DT. The driver updates > the Dom0 DT SCMI node "arm,smc-id" value and fixes up the shmem > node according to the assigned agent_id. > > - pass dom0=3Dsci-agent-id=3D in Xen command line. if not prov= ided > SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT= . > The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shm= em > node according to assigned agent_id. > > Guest domains enable SCMI SMC: > - xl.cfg: add configuration option as below > > arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" > > - xl.cfg: enable access to the "arm,scmi-shmem" which should > correspond assigned agent_id for the domain, for example: > > iomem =3D [ > "47ff2,1@22001", > ] > > - DT: add SCMI nodes to the Driver domain partial device tree as in the > below example. The "arm,smc-id" should correspond assigned agent_id > for the domain: > > passthrough { > scmi_shm_0: sram@22001000 { > compatible =3D "arm,scmi-shmem"; > reg =3D <0x0 0x22001000 0x0 0x1000>; > }; > > firmware { > compatible =3D "simple-bus"; > scmi: scmi { > compatible =3D "arm,scmi-smc"; > arm,smc-id =3D <0x82000004>; > shmem =3D <&scmi_shm_0>; > ... > } > } > } > > SCMI "4.2.1.1 Device specific access control" > > The XEN SCI SCMI SMC multi-agent driver performs "access-controller" > provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device > specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS > command to configure the devices that an agents have access to. > The DT SCMI node should "#access-controller-cells=3D<1>" property and DT > devices should be bound to the Xen SCMI. > > &i2c1 { > access-controllers =3D <&scmi 0>; > }; > > The Dom0 and dom0less domains DT devices will be processed > automatically through sci_assign_dt_device() call, but to assign SCMI > devices from toolstack the xl.cfg:"dtdev" property > shall be used: > > dtdev =3D [ > "/soc/i2c@e6508000", > ] > > xl.cfg:dtdev will contain all nodes which are under SCMI > management (not only those which are behind IOMMU). > > Additionally, this patch adds documentation for the pre-existing > scmi-smc-passthrough command line option, which was previously > undocumented. > > [0] https://developer.arm.com/documentation/den0056 > [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi= t/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.gi= t/tree/Documentation/devicetree/bindings/access-controllers/access-controll= ers.yaml > > Signed-off-by: Grygorii Strashko > Signed-off-by: Oleksii Moisieiev > --- > > Changes in v13: > - fix typo in commit description > > Changes in v12: > - rebase to the latest staging > - return EINVAL if xen,sci_type=3Dscmi_smc_multiagent was set but > CONFIG_SCMI_SMC_MA not set > - put arm_sci_agent_id after v8r_el1_msa and before pad to preserve > order. Reduced pad from uint16_t to uint8_t to fill the gap (was 2 > bytes before adding arm_sci_agent_id and left only 1, so used uint8_t > to preserve structure size) > - fix scmi_handle_call to use arm_smccc_guest_smc helper function > - update send_smc_message function to use new format of > arm_smccc_1_1_smc > - guard the Dom0 SCMI agent id setup in create_dom0() and MA related > funcitons with CONFIG_SCMI_SMC_MA > - fix the xen_scmi_config example in booting.txt, which placed properties > after subnodes and was rejected by dtc with "Properties must precede > subnodes" > > Changes in v10: > - Fix tabs in MAINTAINERS file > - remove duplicate SPDX tag from scmi-shmem.c > - add cast to ARM_SMCCC_INVALID_PARAMETER to settle the sign since > ARM_SMCCC_INVALID_PARAMETER is -3 which is part of the spec and resp > is the default smccc call structure. > - update free_channel_list. Add spinlock to avoid race condition and > a comment with a description of the function work > - preserve error of smc_create_channel in scmi_probe > - check scmi shmem address alignment as wel as it is done for size > - check for d->arch.sci_data !=3D NULL in scmi_handle_call > - use SCMI_SHMEM_MAPPED size for iomem_permit_access > - change len type to unsigned in shmem_{get|put}_message > - rename shmem_channel_is_free to shmem_channel_status > - add comment about skipping message status when getting message response > - Set correct agent_id ranges for dom0less and a toolstack. Agent_id 0 > is not binded for dom0 so can be reused. Also mentioned that > UINT8_MAX (255) is treated as invalid agent_id. > - Split hypervisor and toolstack changes into separate commits > - move init list and spin init after initial checks in probe call > - fix typo in comments > - clean resources when sci_register returns an error. > > Changes in v9: > - sort and refactor MAINTAINERS enties > - remove Spurious changes > - add extra check to avoid ASSERT when calling unmap_channel_memory > from assign device method > - set correct tx flag to SCMI_BASE_AGENT_PERMISSIONS_RESET when > freeing resources. Flag should be set to 1 according to the > section 4.2.2.12 [0]. > - fix dt node copmaring > - moved channel->shmem check from ASSERT in unmap_memory_channel to > "if" statement. This will prevent firing ASSERT if > unmap_channel_memory was called twice on the same channel. > > Changes in v8: > - update xen_scmi func_id in commit description > - updated documentation with the new DT format > - updated opt_dom0_scmi_agent_id setting to avoid it to be equal > SCMI_AGENT_ID_INVALID. > - changed SCMI_AGENT_ID_INVALID from 0xff to UINT8_MAX which makes > code more clear showing that UINT8_MAX is theated like invalid > agent_id and couldn't be used. Also excluded SCMI_AGENT_ID_INVALID > from acceptable value range > - remove outdated xen,config property ignore, added xen,sci compatible > to skip_matches in handle_node > - add documentation for pre-existing scmi-smc-passthrough command line > option in alphabetically correct location (in 's' section) > - add note to commit description about documentation for previously > undocumented scmi-smc-passthrough > - Fix SMC IDs in DT examples (Xen management uses 0x82000003, Dom0 uses 0= x82000002) > - Add explicit note explaining why Dom0 and Xen channels do not conflict > - Document dom0less multi-agent configuration example (xen,sci_type / xen= ,sci-agent-id) > - Add scmi_xen node to agent-discovery example with #scmi-secondary-agent= s-cells =3D 2 > - Drop dom0=3Dsci-agent-id command line handling; Dom0 SCMI is now enable= d via > xen,dom0-sci-agent-id in the xen,sci DT container > - Refresh docs and examples to mention the DT property instead of the cmd= line option > > Changes in v7: > - rework scmi nodes for xen to match on compatible string instead of > the direct path > > Changes in v6: > - updated scmi-shmem to use io.h from generic location > - update scmi_agent_id parameter to be provided inside dom0=3D parameter > list and have the following format "dom0=3Dsci-agent-id=3D0" > This change was done as a response for Stefano comment and > requires a lot of code changes, but produces much cleaner solution > that's why I've added it to the code. > - fix file comments and return codes > - fix lenght checks in shmem_{get,put}_message to use offsetof > - remove len member from scmi_channel structure as it is not used > - set scmi-secondary-agents property to be mandatory since if no > secondary agents were provided then there is no sence to enable scmi > when no secondary agents are populated to the Domains > - update documentation in booting.txt, added xen_scmi node to the > example > - adjust d->arch.sci_enabled value in scmi_domain_destroy > - fix lock management in smc_create_channel call > - avoid extra map_channel_memory command for Xen management channel > because collect_agent_id call unmaps memory if DOMID_XEN is not > set. So for Xen management channel we can init domain_id ad DOMID_XEN > before calling collect_agent_id so memory shouldn't be unmapped. > > Changes in v5: > - fix device-tree example format in booting.txt, added ";" after "}". > - update define in scmi-proto.h > - update define in scmi-shmem.h file > - scmi_assign_device - do not ignore -EOPNOTSUPP return > code of the do_smc_xfer > - remove overwriting agent_channel->agent_id after > SCMI_BASE_DISCOVER_AGENT call > - add multi-agent files to the MAINTAINERS > - add SCMI multi-agent description to the SUPPORT.md > - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL > for smc call > - updated collect_agents function. Set agent_id parameter as optional > in scmi-secondary-agents device-tree property > - introduce "#scmi-secondary-agents-cells" parameter to set if > agent_id was provided > - reanme xen,scmi-secondary-agents property to scmi-secondary-agents > - move memcpu_toio/fromio for the generic place > - update Xen to get management channel from /chosen/xen,config node > - get hypervisor channnel from node instead of using hardcoded > - update handling scmi and shmem nodes for the domain > - Set multi-agent driver to support only Arm64 > > Changes in v4: > - toolstack comments from Anthony PERARD > - added dom0less support > - added doc for "xen,scmi-secondary-agents" > > MAINTAINERS | 1 + > SUPPORT.md | 11 + > docs/misc/arm/device-tree/booting.txt | 197 +++++ > xen/arch/arm/dom0less-build.c | 17 + > xen/arch/arm/domain_build.c | 43 ++ > xen/arch/arm/firmware/Kconfig | 12 + > xen/arch/arm/firmware/Makefile | 1 + > xen/arch/arm/firmware/scmi-proto.h | 164 ++++ > xen/arch/arm/firmware/scmi-shmem.c | 118 +++ > xen/arch/arm/firmware/scmi-shmem.h | 45 ++ > xen/arch/arm/firmware/scmi-smc-multiagent.c | 816 ++++++++++++++++++++ > xen/include/public/arch-arm.h | 5 +- > 12 files changed, 1429 insertions(+), 1 deletion(-) > create mode 100644 xen/arch/arm/firmware/scmi-proto.h > create mode 100644 xen/arch/arm/firmware/scmi-shmem.c > create mode 100644 xen/arch/arm/firmware/scmi-shmem.h > create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index c60afc93a5..cd6d1243bd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -534,6 +534,7 @@ SCI MEDIATORS > R: Oleksii Moisieiev > S: Supported > F: xen/arch/arm/firmware/sci.c > +F: xen/arch/arm/firmware/scmi-*.[ch] > F: xen/arch/arm/include/asm/firmware/sci.h > > SEABIOS UPSTREAM > diff --git a/SUPPORT.md b/SUPPORT.md > index eb07332462..dc41a6b2f3 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -972,6 +972,17 @@ by hwdom. Some platforms use SCMI for access to syst= em-level resources. > > Status: Supported > > +### Arm: SCMI SMC multi-agent support > + > +Enable support for the multi-agent configuration of the EL3 Firmware, wh= ich > +allows Xen to provide an SCMI interface to the Domains. > +Xen manages access permissions to the HW resources and provides an SCMI = interface > +to the Domains. Each Domain is represented as a separate Agent, which ca= n > +communicate with EL3 Firmware using a dedicated shared memory region, an= d > +notifications are passed through by Xen. > + > + Status, ARM64: Tech Preview > + > ### ARM: Guest PSCI support > > Emulated PSCI interface exposed to guests. We support all mandatory > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device= -tree/booting.txt > index bcb06bc796..1d0382a865 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -331,6 +331,21 @@ with the following properties: > Should be used together with scmi-smc-passthrough Xen command line > option. > > + - "scmi_smc_multiagent" > + > + Enables ARM SCMI SMC multi-agent support for the guest by enabling S= CMI over > + SMC calls forwarding from domain to the EL3 firmware (like ARM > + Trusted Firmware-A) with a multi SCMI OSPM agent support. > + The SCMI agent_id should be specified for the guest with "xen,sci-ag= ent-id" > + property. > + > +- "xen,sci-agent-id" > + > + Specifies ARM SCMI agent id for the guest. This option is mandatory = if the > + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The= agent ids > + of guest must be unique and in the range [0..254]. UINT8_MAX (255) i= s > + treated as invalid. > + > - v8r_el1_msa > > A string property specifying whether, on Armv8-R systems at EL1, a d= omain > @@ -847,3 +862,185 @@ The automatically allocated static shared memory wi= ll get mapped at > 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in D= omU2 > guest physical address space. DomU1 is explicitly defined as the owner d= omain, > and DomU2 is the borrower domain. > + > +SCMI SMC multi-agent support > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > + > +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCM= I_SMC_MA) > +the Xen specific SCMI Agent's configuration shall be provided in the Hos= t DT > +according to the SCMI compliant EL3 Firmware specification with ARM SMC/= HVC > +transport. The SCMI configuration must live under the Xen SCMI container > +"xen,sci" beneath "/chosen" (for example "/chosen/xen/xen_scmi_config/sc= mi"). The > +Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is a ch= ild of > +this "xen,sci" container; any other "arm,scmi-smc" nodes (for example un= der > +"/firmware") are ignored to avoid stealing the host's SCMI OSPM instance= . > + > +- scmi-secondary-agents > + > + Defines a set of SCMI agents configuration supported by SCMI EL3 FW = and > + available for Xen. Each Agent defined as triple consisting of: > + SMC/HVC function_id assigned for the agent transport ("arm,smc-id"), > + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shme= m"), > + SCMI agent_id (optional) if not set - Xen will determine Agent ID fo= r > + each provided channel using BASE_DISCOVER_AGENT message. > + > +- xen,dom0-sci-agent-id > + > + Optional. Specifies the Dom0/hwdom SCMI agent_id inside the ``xen,sc= i`` > + container. When provided, Dom0 will be configured for SCMI multi-age= nt > + support; when omitted, SCMI remains disabled for Dom0. The value mus= t > + match the ``func_id`` and shmem pairing that EL3 firmware exposes fo= r > + Dom0 (for example via ``/firmware/scmi``). > + > +As an example: > + > +/ { > + chosen { > + xen { > + ranges; > + xen_scmi_config { > + compatible =3D "xen,sci"; > + #address-cells =3D <2>; > + #size-cells =3D <2>; > + ranges; > + > + xen,dom0-sci-agent-id =3D <0>; <--- dom0 agent id > + scmi-secondary-agents =3D < > + 0x82000002 &scmi_shm_0 0 > + 0x82000004 &scmi_shm_2 2 > + 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agen= t_id > + #scmi-secondary-agents-cells =3D <3>; > + > + scmi_shm_0: sram@47ff0000 { > + compatible =3D "arm,scmi-shmem"; > + reg =3D <0x0 0x47ff0000 0x0 0x1000>; > + }; > + > + /* Xen SCMI management channel */ > + scmi_shm_1: sram@47ff1000 { > + compatible =3D "arm,scmi-shmem"; > + reg =3D <0x0 0x47ff1000 0x0 0x1000>; > + }; > + > + scmi_shm_2: sram@47ff2000 { > + compatible =3D "arm,scmi-shmem"; > + reg =3D <0x0 0x47ff2000 0x0 0x1000>; > + }; > + > + scmi_shm_3: sram@47ff3000 { > + compatible =3D "arm,scmi-shmem"; > + reg =3D <0x0 0x47ff3000 0x0 0x1000>; > + }; > + > + scmi_xen: scmi { > + compatible =3D "arm,scmi-smc"; > + arm,smc-id =3D <0x82000003>; <--- Xen management age= nt func_id > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + #access-controller-cells =3D <1>; > + shmem =3D <&scmi_shm_1>; <--- Xen management agent s= hmem > + }; > + }; > + }; > + }; > +}; > + > +Note: This example keeps the Host DT unchanged for Dom0 and baremetal Li= nux > +by using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses = a > +separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 > +firmware enforces permissions per agent_id, so there is no conflict betw= een > +Dom0 and Xen channels. > + > +- #scmi-secondary-agents-cells > + > + Defines whether Agent_id is set in the "scmi-secondary-agents" prope= rty. > + Possible values are: 2, 3. > + When set to 3 (the default), expect agent_id to be present in the se= condary > + agents list. > + When set to 2, agent_id will be discovered for each channel using > + BASE_DISCOVER_AGENT message. > + > + > +Example: > + > +/ { > + chosen { > + xen { > + ranges; > + xen_scmi_config { > + compatible =3D "xen,sci"; > + #address-cells =3D <2>; > + #size-cells =3D <2>; > + ranges; > + > + /* Shared memory nodes as in the previous example */ > + > + scmi-secondary-agents =3D < > + 0x82000002 &scmi_shm_0 > + 0x82000004 &scmi_shm_2 > + 0x82000005 &scmi_shm_3 > + 0x82000006 &scmi_shm_4>; > + #scmi-secondary-agents-cells =3D <2>; > + > + scmi_xen: scmi { > + compatible =3D "arm,scmi-smc"; > + arm,smc-id =3D <0x82000003>; <--- Xen management age= nt func_id > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + #access-controller-cells =3D <1>; > + shmem =3D <&scmi_shm_1>; <--- Xen management agent s= hmem > + }; > + }; > + }; > + }; > +}; > + > +Dom0less example (multi-agent) > +------------------------------- > + > +Below is a minimal dom0less configuration showing how to enable SCMI SMC > +multi-agent for a pre-defined guest domain using xen,sci_type and > +xen,sci-agent-id, together with the Xen SCMI container: > + > +chosen { > + xen { > + ranges; > + xen_scmi_config { > + compatible =3D "xen,sci"; > + #address-cells =3D <2>; > + #size-cells =3D <2>; > + ranges; > + > + /* Xen management channel shared memory */ > + scmi_shm_1: sram@47ff1000 { > + compatible =3D "arm,scmi-shmem"; > + reg =3D <0x0 0x47ff1000 0x0 0x1000>; > + }; > + > + scmi_shm_domu: sram@47ff2000 { > + compatible =3D "arm,scmi-shmem"; > + reg =3D <0x0 0x47ff2000 0x0 0x1000>; > + }; > + > + scmi-secondary-agents =3D < > + 0x82000004 &scmi_shm_domu 2>; > + #scmi-secondary-agents-cells =3D <3>; > + > + scmi_xen: scmi { > + compatible =3D "arm,scmi-smc"; > + arm,smc-id =3D <0x82000003>; > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + #access-controller-cells =3D <1>; > + shmem =3D <&scmi_shm_1>; > + }; > + }; > + }; > + > + xen,domain@1 { > + compatible =3D "xen,domain"; > + xen,sci_type =3D "scmi_smc_multiagent"; > + xen,sci-agent-id =3D <2>; > + /* Additional domain properties (memory, cpus, kernels, etc.) */ > + }; > +}; > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.= c > index 3f48f74226..50e2516b9e 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -292,6 +292,23 @@ static int __init domu_dt_sci_parse(struct dt_device= _node *node, > > d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > } > + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) > + { > + uint32_t agent_id =3D 0; > + > + if ( !IS_ENABLED(CONFIG_SCMI_SMC_MA) ) > + { > + printk(XENLOG_ERR "xen,sci_type=3Dscmi_smc_multiagent reques= ted, but CONFIG_SCMI_SMC_MA not set\n"); > + return -EINVAL; > + } > + > + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) = || > + agent_id >=3D UINT8_MAX ) > + return -EINVAL; > + > + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_= MA; > + d_cfg->arch.arm_sci_agent_id =3D agent_id; > + } > else > { > printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\= n", > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 72d5316180..297c46d5a2 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -87,6 +87,39 @@ int __init parse_arch_dom0_param(const char *s, const = char *e) > return -EINVAL; > } > > +#ifdef CONFIG_SCMI_SMC_MA > +/* SCMI agent ID for dom0 obtained from xen,sci container */ > +#define SCMI_AGENT_ID_INVALID UINT8_MAX > + > +static uint8_t __init get_dom0_scmi_agent_id(void) > +{ > + const struct dt_device_node *config_node; > + u32 val; > + const struct dt_property *prop; > + > + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); > + if ( !config_node ) > + return SCMI_AGENT_ID_INVALID; > + > + prop =3D dt_find_property(config_node, "xen,dom0-sci-agent-id", NULL= ); > + if ( !prop ) > + return SCMI_AGENT_ID_INVALID; > + > + if ( !dt_property_read_u32(config_node, "xen,dom0-sci-agent-id", &va= l) ) > + return SCMI_AGENT_ID_INVALID; > + > + if ( val >=3D SCMI_AGENT_ID_INVALID ) > + { > + printk(XENLOG_WARNING > + "Invalid xen,dom0-sci-agent-id=3D%u, SCMI disabled for Dom0= \n", > + val); > + return SCMI_AGENT_ID_INVALID; > + } > + > + return val; > +} > +#endif /* CONFIG_SCMI_SMC_MA */ > + > /* Override macros from asm/page.h to make them work with mfn_t */ > #undef virt_to_mfn > #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) > @@ -1479,6 +1512,7 @@ static int __init handle_node(struct domain *d, str= uct kernel_info *kinfo, > DT_MATCH_TYPE("memory"), > /* The memory mapped timer is not supported by Xen. */ > DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"), > + DT_MATCH_COMPATIBLE("xen,sci"), > { /* sentinel */ }, > }; > static const struct dt_device_match timer_matches[] __initconst =3D > @@ -1965,6 +1999,15 @@ void __init create_dom0(void) > dom0_cfg.arch.tee_type =3D tee_get_type(); > dom0_cfg.max_vcpus =3D dom0_max_vcpus(); > > +#ifdef CONFIG_SCMI_SMC_MA > + /* Set up SCMI agent ID if provided in the xen,sci container */ > + dom0_cfg.arch.arm_sci_agent_id =3D get_dom0_scmi_agent_id(); > + dom0_cfg.arch.arm_sci_type =3D (dom0_cfg.arch.arm_sci_agent_id !=3D > + SCMI_AGENT_ID_INVALID) ? > + XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA : > + XEN_DOMCTL_CONFIG_ARM_SCI_NONE; > +#endif > + > if ( iommu_enabled ) > dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu; > > diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfi= g > index 5c5f0880c4..972cd9b173 100644 > --- a/xen/arch/arm/firmware/Kconfig > +++ b/xen/arch/arm/firmware/Kconfig > @@ -29,6 +29,18 @@ config SCMI_SMC > driver domain. > Use with EL3 firmware which supports only single SCMI OSPM agent. > > +config SCMI_SMC_MA > + bool "Enable ARM SCMI SMC multi-agent driver" > + depends on ARM_64 > + select ARM_SCI > + help > + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests fro= m Domains > + to EL3 firmware (TF-A) which supports multi-agent feature. > + This feature allows to enable SCMI per Domain using unique SCMI a= gent_id, > + so Domain is identified by EL3 firmware as an SCMI Agent and can = access > + allowed platform resources through dedicated SMC/HVC Shared memor= y based > + transport. > + > endchoice > > endmenu > diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makef= ile > index 71bdefc24a..37927e690e 100644 > --- a/xen/arch/arm/firmware/Makefile > +++ b/xen/arch/arm/firmware/Makefile > @@ -1,2 +1,3 @@ > obj-$(CONFIG_ARM_SCI) +=3D sci.o > obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o > +obj-$(CONFIG_SCMI_SMC_MA) +=3D scmi-shmem.o scmi-smc-multiagent.o > diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/s= cmi-proto.h > new file mode 100644 > index 0000000000..49f63cfc0a > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-proto.h > @@ -0,0 +1,164 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Arm System Control and Management Interface definitions > + * Version 3.0 (DEN0056C) > + * > + * Copyright (c) 2025 EPAM Systems > + */ > + > +#ifndef ARM_FIRMWARE_SCMI_PROTO_H_ > +#define ARM_FIRMWARE_SCMI_PROTO_H_ > + > +#include > + > +#define SCMI_SHORT_NAME_MAX_SIZE 16 > + > +/* SCMI status codes. See section 4.1.4 */ > +#define SCMI_SUCCESS 0 > +#define SCMI_NOT_SUPPORTED (-1) > +#define SCMI_INVALID_PARAMETERS (-2) > +#define SCMI_DENIED (-3) > +#define SCMI_NOT_FOUND (-4) > +#define SCMI_OUT_OF_RANGE (-5) > +#define SCMI_BUSY (-6) > +#define SCMI_COMMS_ERROR (-7) > +#define SCMI_GENERIC_ERROR (-8) > +#define SCMI_HARDWARE_ERROR (-9) > +#define SCMI_PROTOCOL_ERROR (-10) > + > +/* Protocol IDs */ > +#define SCMI_BASE_PROTOCOL 0x10 > + > +/* Base protocol message IDs */ > +#define SCMI_BASE_PROTOCOL_VERSION 0x0 > +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 > +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 > +#define SCMI_BASE_DISCOVER_AGENT 0x7 > +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 > +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB > + > +typedef struct scmi_msg_header { > + uint8_t id; > + uint8_t type; > + uint8_t protocol; > + uint32_t status; > +} scmi_msg_header_t; > + > +/* Table 2 Message header format */ > +#define SCMI_HDR_ID GENMASK(7, 0) > +#define SCMI_HDR_TYPE GENMASK(9, 8) > +#define SCMI_HDR_PROTO GENMASK(17, 10) > + > +#define SCMI_FIELD_GET(_mask, _reg) = \ > + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) > +#define SCMI_FIELD_PREP(_mask, _val) = \ > + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) > + > +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) > +{ > + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | > + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | > + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); > +} > + > +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_= t *hdr) > +{ > + hdr->id =3D SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); > + hdr->type =3D SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); > + hdr->protocol =3D SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); > +} > + > +static inline int scmi_to_xen_errno(int scmi_status) > +{ > + if ( scmi_status =3D=3D SCMI_SUCCESS ) > + return 0; > + > + switch ( scmi_status ) > + { > + case SCMI_NOT_SUPPORTED: > + return -EOPNOTSUPP; > + case SCMI_INVALID_PARAMETERS: > + return -EINVAL; > + case SCMI_DENIED: > + return -EACCES; > + case SCMI_NOT_FOUND: > + return -ENOENT; > + case SCMI_OUT_OF_RANGE: > + return -ERANGE; > + case SCMI_BUSY: > + return -EBUSY; > + case SCMI_COMMS_ERROR: > + return -ENOTCONN; > + case SCMI_GENERIC_ERROR: > + return -EIO; > + case SCMI_HARDWARE_ERROR: > + return -ENXIO; > + case SCMI_PROTOCOL_ERROR: > + return -EBADMSG; > + default: > + return -EINVAL; > + } > +} > + > +/* PROTOCOL_VERSION */ > +#define SCMI_VERSION_MINOR GENMASK(15, 0) > +#define SCMI_VERSION_MAJOR GENMASK(31, 16) > + > +struct scmi_msg_prot_version_p2a { > + uint32_t version; > +} __packed; > + > +/* BASE PROTOCOL_ATTRIBUTES */ > +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) > +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) > + > +struct scmi_msg_base_attributes_p2a { > + uint32_t attributes; > +} __packed; > + > +/* > + * BASE_DISCOVER_AGENT > + */ > +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF > + > +struct scmi_msg_base_discover_agent_a2p { > + uint32_t agent_id; > +} __packed; > + > +struct scmi_msg_base_discover_agent_p2a { > + uint32_t agent_id; > + char name[SCMI_SHORT_NAME_MAX_SIZE]; > +} __packed; > + > +/* > + * BASE_SET_DEVICE_PERMISSIONS > + */ > +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) > + > +struct scmi_msg_base_set_device_permissions_a2p { > + uint32_t agent_id; > + uint32_t device_id; > + uint32_t flags; > +} __packed; > + > +/* > + * BASE_RESET_AGENT_CONFIGURATION > + */ > +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) > + > +struct scmi_msg_base_reset_agent_cfg_a2p { > + uint32_t agent_id; > + uint32_t flags; > +} __packed; > + > +#endif /* ARM_FIRMWARE_SCMI_PROTO_H_ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/s= cmi-shmem.c > new file mode 100644 > index 0000000000..e36745a85e > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-shmem.c > @@ -0,0 +1,118 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * SMC/HVC shmem transport implementation used by > + * SCI SCMI multi-agent driver. > + * > + * Oleksii Moisieiev > + * Copyright (c) 2025 EPAM Systems > + */ > + > +#include > +#include > +#include > + > +#include "scmi-proto.h" > +#include "scmi-shmem.h" > + > +static inline int > +shmem_channel_status(const volatile struct scmi_shared_mem __iomem *shme= m) > +{ > + return (readl(&shmem->channel_status) & > + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; > +} > + > +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, unsigned int l= en) > +{ > + int ret; > + > + if ( (len + offsetof(struct scmi_shared_mem, msg_payload)) > > + SCMI_SHMEM_MAPPED_SIZE ) > + { > + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is inva= lid\n"); > + return -EINVAL; > + } > + > + ret =3D shmem_channel_status(shmem); > + if ( ret ) > + return ret; > + > + writel_relaxed(0x0, &shmem->channel_status); > + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set *= / > + writel_relaxed(0x0, &shmem->flags); > + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); > + writel(pack_scmi_header(hdr), &shmem->msg_header); > + > + if ( len > 0 && data ) > + memcpy_toio(shmem->msg_payload, data, len); > + > + return 0; > +} > + > +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *sh= mem, > + scmi_msg_header_t *hdr, void *data, unsigned int = len) > +{ > + int recv_len; > + int ret; > + /* > + * First word of msg_payload carries the returned status; exclude it= from > + * recv_len so only the protocol payload is copied back to the calle= r. > + */ > + int pad =3D sizeof(hdr->status); > + > + if ( len >=3D SCMI_SHMEM_MAPPED_SIZE - > + offsetof(struct scmi_shared_mem, msg_payload) ) > + { > + printk(XENLOG_ERR > + "scmi: Wrong size of input smc message. Data may be inval= id\n"); > + return -EINVAL; > + } > + > + ret =3D shmem_channel_status(shmem); > + if ( ret ) > + return ret; > + > + recv_len =3D readl(&shmem->length) - sizeof(shmem->msg_header); > + > + if ( recv_len < 0 ) > + { > + printk(XENLOG_ERR > + "scmi: Wrong size of smc message. Data may be invalid\n")= ; > + return -EINVAL; > + } > + > + unpack_scmi_header(readl(&shmem->msg_header), hdr); > + > + hdr->status =3D readl(&shmem->msg_payload); > + recv_len =3D recv_len > pad ? recv_len - pad : 0; > + > + ret =3D scmi_to_xen_errno(hdr->status); > + if ( ret ) > + { > + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); > + return ret; > + } > + > + if ( recv_len > len ) > + { > + printk(XENLOG_ERR > + "scmi: Not enough buffer for message %d, expecting %d\n", > + recv_len, len); > + return -EINVAL; > + } > + > + if ( recv_len > 0 ) > + memcpy_fromio(data, shmem->msg_payload + pad, recv_len); > + > + return 0; > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-shmem.h b/xen/arch/arm/firmware/s= cmi-shmem.h > new file mode 100644 > index 0000000000..722263aa77 > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-shmem.h > @@ -0,0 +1,45 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Arm System Control and Management Interface definitions > + * Version 3.0 (DEN0056C) > + * Shared Memory based Transport > + * > + * Copyright (c) 2024 EPAM Systems > + */ > + > +#ifndef ARM_FIRMWARE_SCMI_SHMEM_H_ > +#define ARM_FIRMWARE_SCMI_SHMEM_H_ > + > +#include > + > +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) > +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) > + > +struct scmi_shared_mem { > + uint32_t reserved; > + uint32_t channel_status; > + uint32_t reserved1[2]; > + uint32_t flags; > + uint32_t length; > + uint32_t msg_header; > + uint8_t msg_payload[]; > +}; > + > +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE > + > +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, unsigned int l= en); > + > +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *sh= mem, > + scmi_msg_header_t *hdr, void *data, unsigned int = len); > +#endif /* ARM_FIRMWARE_SCMI_SHMEM_H_ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/f= irmware/scmi-smc-multiagent.c > new file mode 100644 > index 0000000000..0c5653fbc0 > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c > @@ -0,0 +1,816 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. > + * > + * Oleksii Moisieiev > + * Copyright (c) 2025 EPAM Systems > + */ > + > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#include "scmi-proto.h" > +#include "scmi-shmem.h" > + > +#define SCMI_SECONDARY_AGENTS "scmi-secondary-agents" > + > +struct scmi_channel { > + uint32_t agent_id; > + uint32_t func_id; > + domid_t domain_id; > + uint64_t paddr; > + struct scmi_shared_mem __iomem *shmem; > + spinlock_t lock; > + struct list_head list; > +}; > + > +struct scmi_data { > + struct list_head channel_list; > + spinlock_t channel_list_lock; > + uint32_t func_id; > + bool initialized; > + uint32_t shmem_phandle; > + uint32_t hyp_channel_agent_id; > + struct dt_device_node *dt_dev; > +}; > + > +static struct scmi_data scmi_data; > + > +static bool scmi_is_under_xen_sci(const struct dt_device_node *node) > +{ > + const struct dt_device_node *p; > + > + for ( p =3D node->parent; p; p =3D p->parent ) > + if ( dt_device_is_compatible(p, "xen,sci") ) > + return true; > + > + return false; > +} > + > +static int send_smc_message(struct scmi_channel *chan_info, > + scmi_msg_header_t *hdr, void *data, int len) > +{ > + struct arm_smccc_res resp; > + int ret; > + > + ret =3D shmem_put_message(chan_info->shmem, hdr, data, len); > + if ( ret ) > + return ret; > + > + resp =3D arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0); > + > + if ( resp.a0 =3D=3D (unsigned long)ARM_SMCCC_INVALID_PARAMETER ) > + return -EINVAL; > + > + if ( resp.a0 ) > + return -EOPNOTSUPP; > + > + return 0; > +} > + > +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t= *hdr, > + void *tx_data, int tx_size, void *rx_data, int rx= _size) > +{ > + int ret =3D 0; > + > + ASSERT(chan_info && chan_info->shmem); > + > + if ( !hdr ) > + return -EINVAL; > + > + spin_lock(&chan_info->lock); > + > + printk(XENLOG_DEBUG > + "scmi: agent_id =3D %d msg_id =3D %x type =3D %d, proto =3D %= x\n", > + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); > + > + ret =3D send_smc_message(chan_info, hdr, tx_data, tx_size); > + if ( ret ) > + goto clean; > + > + ret =3D shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size); > + > +clean: > + printk(XENLOG_DEBUG > + "scmi: get smc response agent_id =3D %d msg_id =3D %x proto = =3D %x res=3D%d\n", > + chan_info->agent_id, hdr->id, hdr->protocol, ret); > + > + spin_unlock(&chan_info->lock); > + > + return ret; > +} > + > +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) > +{ > + struct scmi_channel *curr; > + bool found =3D false; > + > + spin_lock(&scmi_data.channel_list_lock); > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id =3D=3D agent_id ) > + { > + found =3D true; > + break; > + } > + } > + > + spin_unlock(&scmi_data.channel_list_lock); > + if ( found ) > + return curr; > + > + return NULL; > +} > + > +static struct scmi_channel *acquire_scmi_channel(struct domain *d, > + uint32_t agent_id) > +{ > + struct scmi_channel *curr; > + struct scmi_channel *ret =3D ERR_PTR(-ENOENT); > + > + spin_lock(&scmi_data.channel_list_lock); > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id =3D=3D agent_id ) > + { > + if ( curr->domain_id !=3D DOMID_INVALID ) > + { > + ret =3D ERR_PTR(-EEXIST); > + break; > + } > + > + curr->domain_id =3D d->domain_id; > + ret =3D curr; > + break; > + } > + } > + > + spin_unlock(&scmi_data.channel_list_lock); > + > + return ret; > +} > + > +static void relinquish_scmi_channel(struct scmi_channel *channel) > +{ > + ASSERT(channel !=3D NULL); > + > + spin_lock(&scmi_data.channel_list_lock); > + channel->domain_id =3D DOMID_INVALID; > + spin_unlock(&scmi_data.channel_list_lock); > +} > + > +static int map_channel_memory(struct scmi_channel *channel) > +{ > + ASSERT(channel && channel->paddr); > + channel->shmem =3D ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED= _SIZE); > + if ( !channel->shmem ) > + return -ENOMEM; > + > + channel->shmem->channel_status =3D SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE= ; > + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->= paddr, > + channel->shmem); > + > + return 0; > +} > + > +static void unmap_channel_memory(struct scmi_channel *channel) > +{ > + ASSERT(channel); > + > + if ( !channel->shmem ) > + return; > + > + iounmap(channel->shmem); > + channel->shmem =3D NULL; > +} > + > +static struct scmi_channel *smc_create_channel(uint32_t agent_id, > + uint32_t func_id, uint64_= t addr) > +{ > + struct scmi_channel *channel, *curr; > + > + spin_lock(&scmi_data.channel_list_lock); > + > + /* Check if channel already exists while holding the lock */ > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id =3D=3D agent_id ) > + { > + spin_unlock(&scmi_data.channel_list_lock); > + return ERR_PTR(-EEXIST); > + } > + } > + > + channel =3D xmalloc(struct scmi_channel); > + if ( !channel ) > + { > + spin_unlock(&scmi_data.channel_list_lock); > + return ERR_PTR(-ENOMEM); > + } > + > + spin_lock_init(&channel->lock); > + channel->agent_id =3D agent_id; > + channel->func_id =3D func_id; > + channel->domain_id =3D DOMID_INVALID; > + channel->shmem =3D NULL; > + channel->paddr =3D addr; > + list_add_tail(&channel->list, &scmi_data.channel_list); > + > + spin_unlock(&scmi_data.channel_list_lock); > + return channel; > +} > + > +static void free_channel_list(void) > +{ > + struct scmi_channel *curr, *_curr; > + /* > + * Called only on the __init error path, before any runtime users ex= ist, > + * so no other thread is iterating channel_list. Keep the lock for t= he > + * whole drain for clarity and to avoid misleading readers about pos= sible > + * concurrent access. > + */ > + spin_lock(&scmi_data.channel_list_lock); > + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list) > + { > + list_del(&curr->list); > + xfree(curr); > + } > + spin_unlock(&scmi_data.channel_list_lock); > +} > + > +static int __init > +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *add= r, > + u64 *size) > +{ > + struct dt_device_node *shmem_node; > + const __be32 *prop; > + > + prop =3D dt_get_property(scmi_node, "shmem", NULL); > + if ( !prop ) > + return -EINVAL; > + > + shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop)); > + if ( IS_ERR_OR_NULL(shmem_node) ) > + { > + printk(XENLOG_ERR > + "scmi: Device tree error, can't parse reserved memory %ld= \n", > + PTR_ERR(shmem_node)); > + return PTR_ERR(shmem_node); > + } > + > + return dt_device_get_address(shmem_node, 0, addr, size); > +} > + > +/* > + * Handle Dom0 SCMI specific DT nodes > + * > + * Make a decision on copying SCMI specific nodes into Dom0 device tree. > + * For SCMI multi-agent case: > + * - shmem nodes will not be copied and generated instead if SCMI > + * is enabled for Dom0 > + * - scmi node will be copied if SCMI is enabled for Dom0 > + */ > +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node = *node) > +{ > + static const struct dt_device_match shmem_matches[] __initconst =3D = { > + DT_MATCH_COMPATIBLE("arm,scmi-shmem"), > + { /* sentinel */ }, > + }; > + static const struct dt_device_match scmi_matches[] __initconst =3D { > + DT_MATCH_PATH("/firmware/scmi"), > + { /* sentinel */ }, > + }; > + > + if ( !scmi_data.initialized ) > + return false; > + > + /* skip scmi shmem node for dom0 if scmi not enabled */ > + if ( dt_match_node(shmem_matches, node) && !sci_domain_is_enabled(d)= ) > + { > + dt_dprintk(" Skip scmi shmem node\n"); > + return true; > + } > + > + /* drop scmi if not enabled */ > + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) = ) > + { > + dt_dprintk(" Skip scmi node\n"); > + return true; > + } > + > + return false; > +} > + > +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, > + uint32_t flags) > +{ > + struct scmi_msg_base_set_device_permissions_a2p tx; > + struct scmi_channel *channel; > + scmi_msg_header_t hdr; > + > + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); > + if ( !channel ) > + return -EINVAL; > + > + hdr.id =3D SCMI_BASE_SET_DEVICE_PERMISSIONS; > + hdr.type =3D 0; > + hdr.protocol =3D SCMI_BASE_PROTOCOL; > + > + tx.agent_id =3D agent_id; > + tx.device_id =3D device_id; > + tx.flags =3D flags; > + > + return do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); > +} > + > +static int scmi_dt_assign_device(struct domain *d, > + struct dt_phandle_args *ac_spec) > +{ > + struct scmi_channel *agent_channel; > + uint32_t scmi_device_id =3D ac_spec->args[0]; > + int ret; > + > + if ( !d->arch.sci_data ) > + return 0; > + > + /* The access-controllers is specified for DT dev, but it's not a SC= MI */ > + if ( !scmi_data.dt_dev || > + !dt_node_path_is_equal(ac_spec->np, scmi_data.dt_dev->full_name= ) ) > + return 0; > + > + agent_channel =3D d->arch.sci_data; > + > + spin_lock(&agent_channel->lock); > + > + ret =3D scmi_assign_device(agent_channel->agent_id, scmi_device_id, > + SCMI_BASE_DEVICE_ACCESS_ALLOW); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%= d)", > + d, agent_channel->agent_id, scmi_device_id, ret); > + } > + > + spin_unlock(&agent_channel->lock); > + return ret; > +} > + > +static int collect_agent_id(struct scmi_channel *agent_channel) > +{ > + int ret; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_discover_agent_p2a da_rx; > + struct scmi_msg_base_discover_agent_a2p da_tx; > + > + ret =3D map_channel_memory(agent_channel); > + if ( ret ) > + return ret; > + > + hdr.id =3D SCMI_BASE_DISCOVER_AGENT; > + hdr.type =3D 0; > + hdr.protocol =3D SCMI_BASE_PROTOCOL; > + > + da_tx.agent_id =3D agent_channel->agent_id; > + > + ret =3D do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_= rx, > + sizeof(da_rx)); > + if ( agent_channel->domain_id !=3D DOMID_XEN ) > + unmap_channel_memory(agent_channel); > + if ( ret ) > + return ret; > + > + printk(XENLOG_DEBUG "id=3D0x%x name=3D%s\n", da_rx.agent_id, da_rx.n= ame); > + agent_channel->agent_id =3D da_rx.agent_id; > + return 0; > +} > + > +static __init int collect_agents(struct dt_device_node *scmi_node) > +{ > + const struct dt_device_node *config_node; > + const __be32 *prop; > + uint32_t len; > + const __be32 *end; > + uint32_t cells_per_entry =3D 3; /* Default to 3 cells if property is= absent. */ > + > + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); > + if ( !config_node ) > + { > + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents t= o collect.\n"); > + return -ENOENT; > + } > + > + /* Check for the optional '#scmi-secondary-agents-cells' property. *= / > + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells= ", > + &cells_per_entry) ) > + { > + if ( cells_per_entry !=3D 2 && cells_per_entry !=3D 3 ) > + { > + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cell= s value: %u\n", > + cells_per_entry); > + return -EINVAL; > + } > + } > + > + prop =3D dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); > + if ( !prop ) > + { > + printk(XENLOG_ERR "scmi: No %s property found, no agents to coll= ect.\n", > + SCMI_SECONDARY_AGENTS); > + return -EINVAL; > + } > + > + /* Validate that the property length is a multiple of the cell size.= */ > + if ( len =3D=3D 0 || len % (cells_per_entry * sizeof(uint32_t)) !=3D= 0 ) > + { > + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %= u cells per entry\n", > + SCMI_SECONDARY_AGENTS, len, cells_per_entry); > + return -EINVAL; > + } > + > + end =3D (const __be32 *)((const u8 *)prop + len); > + > + for ( ; prop < end; ) > + { > + uint32_t agent_id; > + uint32_t smc_id; > + uint32_t shmem_phandle; > + struct dt_device_node *node; > + u64 addr, size; > + int ret; > + struct scmi_channel *agent_channel; > + > + smc_id =3D be32_to_cpu(*prop++); > + shmem_phandle =3D be32_to_cpu(*prop++); > + > + if ( cells_per_entry =3D=3D 3 ) > + agent_id =3D be32_to_cpu(*prop++); > + else > + agent_id =3D SCMI_BASE_AGENT_ID_OWN; > + > + node =3D dt_find_node_by_phandle(shmem_phandle); > + if ( !node ) > + { > + printk(XENLOG_ERR "scmi: Could not find shmem node for agent= %u\n", > + agent_id); > + return -EINVAL; > + } > + > + ret =3D dt_device_get_address(node, 0, &addr, &size); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "scmi: Could not read shmem address for agent %u: %d\= n", > + agent_id, ret); > + return ret; > + } > + > + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) || > + !IS_ALIGNED(addr, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > + return -EINVAL; > + } > + > + agent_channel =3D smc_create_channel(agent_id, smc_id, addr); > + if ( IS_ERR(agent_channel) ) > + { > + printk(XENLOG_ERR "scmi: Could not create channel for agent = %u: %ld\n", > + agent_id, PTR_ERR(agent_channel)); > + return PTR_ERR(agent_channel); > + } > + > + if ( cells_per_entry =3D=3D 2 ) > + { > + ret =3D collect_agent_id(agent_channel); > + if ( ret ) > + return ret; > + } > + > + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_ch= annel->agent_id, > + smc_id, (unsigned long)addr); > + } > + > + return 0; > +} > + > +static int scmi_domain_init(struct domain *d, > + struct xen_domctl_createdomain *config) > +{ > + struct scmi_channel *channel; > + int ret; > + > + if ( !scmi_data.initialized ) > + return 0; > + > + /* > + * SCMI support is configured via: > + * - For dom0: xen,dom0-sci-agent-id property under the xen,sci cont= ainer > + * - For dom0less: xen,sci-agent-id in the domain node > + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id > + * are already set by domain_build.c or dom0less-build.c > + */ > + > + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE= ) > + return 0; > + > + channel =3D acquire_scmi_channel(d, config->arch.arm_sci_agent_id); > + if ( IS_ERR(channel) ) > + { > + printk(XENLOG_ERR > + "scmi: Failed to acquire SCMI channel for agent_id %u: %l= d\n", > + config->arch.arm_sci_agent_id, PTR_ERR(channel)); > + return PTR_ERR(channel); > + } > + > + printk(XENLOG_INFO > + "scmi: Acquire channel id =3D 0x%x, domain_id =3D %d paddr = =3D 0x%lx\n", > + channel->agent_id, channel->domain_id, channel->paddr); > + > + /* > + * Dom0 (if present) needs to have an access to the guest memory ran= ge > + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_per= mission > + * domctl. > + */ > + if ( hardware_domain && !is_hardware_domain(d) ) > + { > + ret =3D iomem_permit_access(hardware_domain, paddr_to_pfn(channe= l->paddr), > + paddr_to_pfn(channel->paddr + > + SCMI_SHMEM_MAPPED_SIZE - 1)); > + if ( ret ) > + goto error; > + } > + > + d->arch.sci_data =3D channel; > + d->arch.sci_enabled =3D true; > + > + return 0; > + > +error: > + relinquish_scmi_channel(channel); > + return ret; > +} > + > +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) > +{ > + if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE &= & > + config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_S= MC_MA ) > + { > + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int scmi_relinquish_resources(struct domain *d) > +{ > + int ret; > + struct scmi_channel *channel, *agent_channel; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_reset_agent_cfg_a2p tx; > + > + if ( !d->arch.sci_data ) > + return 0; > + > + agent_channel =3D d->arch.sci_data; > + > + spin_lock(&agent_channel->lock); > + tx.agent_id =3D agent_channel->agent_id; > + spin_unlock(&agent_channel->lock); > + > + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); > + if ( !channel ) > + { > + printk(XENLOG_ERR > + "scmi: Unable to get Hypervisor scmi channel for domain %= d\n", > + d->domain_id); > + return -EINVAL; > + } > + > + hdr.id =3D SCMI_BASE_RESET_AGENT_CONFIGURATION; > + hdr.type =3D 0; > + hdr.protocol =3D SCMI_BASE_PROTOCOL; > + > + tx.flags =3D SCMI_BASE_AGENT_PERMISSIONS_RESET; > + > + ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); > + if ( ret =3D=3D -EOPNOTSUPP ) > + return 0; > + > + return ret; > +} > + > +static void scmi_domain_destroy(struct domain *d) > +{ > + struct scmi_channel *channel; > + > + if ( !d->arch.sci_data ) > + return; > + > + channel =3D d->arch.sci_data; > + spin_lock(&channel->lock); > + > + relinquish_scmi_channel(channel); > + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); > + > + d->arch.sci_data =3D NULL; > + d->arch.sci_enabled =3D false; > + > + spin_unlock(&channel->lock); > +} > + > +static bool scmi_handle_call(struct cpu_user_regs *regs) > +{ > + uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); > + struct scmi_channel *agent_channel; > + struct domain *d =3D current->domain; > + bool res =3D false; > + > + if ( (!sci_domain_is_enabled(d)) || (!d->arch.sci_data) ) > + return false; > + > + agent_channel =3D d->arch.sci_data; > + spin_lock(&agent_channel->lock); > + > + if ( agent_channel->func_id !=3D fid ) > + { > + res =3D false; > + goto unlock; > + } > + > + arm_smccc_guest_smc(regs); > + res =3D true; > +unlock: > + spin_unlock(&agent_channel->lock); > + > + return res; > +} > + > +static const struct sci_mediator_ops scmi_ops =3D { > + .domain_init =3D scmi_domain_init, > + .domain_destroy =3D scmi_domain_destroy, > + .relinquish_resources =3D scmi_relinquish_resources, > + .handle_call =3D scmi_handle_call, > + .dom0_dt_handle_node =3D scmi_dt_handle_node, > + .domain_sanitise_config =3D scmi_domain_sanitise_config, > + .assign_dt_device =3D scmi_dt_assign_device, > +}; > + > +static int __init scmi_check_smccc_ver(void) > +{ > + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) > + { > + printk(XENLOG_WARNING > + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabl= ed\n"); > + return -ENOSYS; > + } > + > + return 0; > +} > + > +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_n= ode, > + struct scmi_data *scmi_data, > + u64 *addr) > +{ > + int ret; > + u64 size; > + > + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func= _id) ) > + { > + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); > + return -ENOENT; > + } > + > + ret =3D scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); > + if ( IS_ERR_VALUE(ret) ) > + return -ENOENT; > + > + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static __init int scmi_probe(struct dt_device_node *scmi_node, const voi= d *data) > +{ > + u64 addr; > + int ret; > + struct scmi_channel *channel; > + unsigned int n_agents; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_attributes_p2a rx; > + > + ASSERT(scmi_node !=3D NULL); > + > + /* > + * Only bind to the SCMI node provided by Xen under the xen,sci cont= ainer > + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to f= irmware > + * SCMI nodes that belong to the host OSPM and keeps the mediator sc= oped to > + * Xen-provided configuration only. > + */ > + if ( !scmi_is_under_xen_sci(scmi_node) ) > + return -ENODEV; > + > + if ( !acpi_disabled ) > + { > + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"= ); > + return -EINVAL; > + } > + > + ret =3D scmi_check_smccc_ver(); > + if ( ret ) > + return ret; > + > + ret =3D scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); > + if ( ret ) > + return ret; > + > + INIT_LIST_HEAD(&scmi_data.channel_list); > + spin_lock_init(&scmi_data.channel_list_lock); > + > + scmi_data.dt_dev =3D scmi_node; > + > + channel =3D smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.fun= c_id, addr); > + if ( IS_ERR(channel) ) > + { > + ret =3D PTR_ERR(channel); > + goto out; > + } > + > + /* Mark as Xen management channel before collecting agent ID */ > + channel->domain_id =3D DOMID_XEN; > + > + /* Request agent id for Xen management channel */ > + ret =3D collect_agent_id(channel); > + if ( ret ) > + goto error; > + > + /* Save the agent id for Xen management channel */ > + scmi_data.hyp_channel_agent_id =3D channel->agent_id; > + > + hdr.id =3D SCMI_BASE_PROTOCOL_ATTIBUTES; > + hdr.type =3D 0; > + hdr.protocol =3D SCMI_BASE_PROTOCOL; > + > + ret =3D do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); > + if ( ret ) > + goto error; > + > + n_agents =3D SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes)= ; > + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); > + ret =3D collect_agents(scmi_node); > + if ( ret ) > + goto error; > + > + ret =3D sci_register(&scmi_ops); > + if ( ret ) > + { > + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d= )\n", > + ret); > + goto error; > + } > + > + scmi_data.initialized =3D true; > + goto out; > + > +error: > + unmap_channel_memory(channel); > + free_channel_list(); > +out: > + return ret; > +} > + > +static const struct dt_device_match scmi_smc_match[] __initconst =3D { > + DT_MATCH_COMPATIBLE("arm,scmi-smc"), > + { /* sentinel */ }, > +}; > + > +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) > + .dt_match =3D scmi_smc_match, > + .init =3D scmi_probe, > +DT_DEVICE_END > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.= h > index 1fc676fd96..a9a10a3b8d 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); > > #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 > #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 > +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 > > #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_NONE 0 > #define XEN_DOMCTL_CONFIG_ARM_V8R_EL1_MSA_PMSA 1 > @@ -361,7 +362,9 @@ struct xen_arch_domainconfig { > uint8_t arm_sci_type; > /* IN */ > uint8_t v8r_el1_msa; > - uint16_t pad; > + /* IN */ > + uint8_t arm_sci_agent_id; > + uint8_t pad; > }; > #endif /* __XEN__ || __XEN_TOOLS__ */ -- WBR, Volodymyr From xen-devel-bounces@lists.xenproject.org Wed Sep 23 01:13:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 01:13:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429602.1652404 (Exim 4.92) (envelope-from ) id 1x9BXj-0001NS-D4; Wed, 23 Sep 2026 01:13:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429602.1652404; Wed, 23 Sep 2026 01:13:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9BXj-0001NL-AI; Wed, 23 Sep 2026 01:13:03 +0000 Received: by outflank-mailman (input) for mailman id 1429602; Wed, 23 Sep 2026 01:13:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9BXi-0001Mw-1R for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 01:13:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9BXg-007HCV-UH for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 03:13:00 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab32729-bab6-0a2a0a5309dd-0a2a4503e3b2-26 for ; Wed, 23 Sep 2026 03:13:00 +0200 Received: from [65.109.113.108] (helo=mail.alien8.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3279c-fae8-0a2a45030019-416d716ce3b0-3 for ; Wed, 23 Sep 2026 03:13:00 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id F3C8B40E016C; Wed, 23 Sep 2026 01:12:59 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6o-Fo31hAHa9; Wed, 23 Sep 2026 01:12:50 +0000 (UTC) Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 6BA7340E015D; Wed, 23 Sep 2026 01:12:35 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=alien8 header.d=alien8.de header.i="@alien8.de" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1790125970; bh=uWKwydJTNrxZzExrdKneBzP0b9+gsjTjN2mem4Zk7Bo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ByW6iTGxph5qdd6H36j8szI6mZnmiunldGYwh0edVemYmU5fJxDf3kjazB9Nkx387 C03N4L2UqELPzgreD3hZUn6FOn4mg1Z9iyZD8h6g4JwPQ67ZPbyLcAO9I3yvFn814g LUzP0gS6us1xtFDb5K7Vhp02MtfpmPCT/lSW1AYFzplbHtnNVTlcdAvXljVoK8vmUs j8zAyEuzFJfloggsP2KY8cXmNPgjKiFnrDD/Rm6wsAXyb/tg/9Hk3pgVPQHdkQZC50 ovcd514Ek64IUy9hT04pRhcqB3xNgkmoK9ijOhoiPy8mcwKqBn5TrXz2AKMT7V8Wy4 pChbdxTxfZFX5rw3XnGX2DBaV5YeWRrURqgDDkoxOSCAJd3+MtANuOPGC/uZx/1Qh7 5gp5DuuNB7ERfZi/qGQFqrtYp15uQi+r29W/sRrZGEzu8UF8Q4PXLZN6Et4PFqJTaO V3x0/Kn1ZxxB93ZRfE31x5t4EOJ6DGcqK0P67EjhfGbdU57Fsuod36Xm5u48iIR1S/ 6GaD68UIzAsQwoNZ+HbUaeJQ8cLZYjed6/o/EQmsp56SG/gcFl8Y+sAXUyZoPHF3RK 5ENNwIgmg/qMobHPIzEPyxbPeQRcftt04LNpGM6NiT+F2akLaoOSqcrnOmD2e12zat RZbfvZK1kBMH7nQIzd8FIh7w= Date: Tue, 22 Sep 2026 18:12:32 -0700 From: Borislav Petkov To: Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v10 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN) Message-ID: <20260923011232.GBarMngDiylzal41XI@fat_crate.local> References: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> <20260922035815.GFarH819yHRX8WWnG9@fat_crate.local> <3ed7ea3908233ef72660ddfa1f92e914@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3ed7ea3908233ef72660ddfa1f92e914@igalia.com> X-purgate-ID: tlsNG-33051d/1790125980-752854E9-DD59829C/0/0 X-purgate-type: clean X-purgate-size: 1096 On Tue, Sep 22, 2026 at 07:13:35PM -0300, Mauricio Faria de Oliveira wrote: > I think that is fine, yes. Even though it's a boot failure, actually > hitting it depends on all of: CONFIG_KASAN, CONFIG_PVH, booting from the > PVH entry point, _plus_ a compiler version that triggers it. > > Nonetheless, this may be picked up for stable due to the Fixes: tags, > but I can provide backports as needed. Right, just consider all the bandwidth of the folks involved downstream: stable team and all distros backporting stuff every day. This sounds like an exotic thing so let's be conservative here pls. > BTW, I just realized that the title of patch 4/4 is missing memset(). > Would you mind adding it, please? Or I can send v11. > -x86/cpuid: fix unbootable VMs by really inlining memcmp() in > cpuid_base_hypervisor() and xen_prepare_pvh() > +x86/cpuid: fix unbootable VMs by really inlining memcmp() and memset() > in cpuid_base_hypervisor() and xen_prepare_pvh() Sure, np. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Wed Sep 23 04:35:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 04:35:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429683.1652412 (Exim 4.92) (envelope-from ) id 1x9EhX-0001V1-FF; Wed, 23 Sep 2026 04:35:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429683.1652412; Wed, 23 Sep 2026 04:35:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9EhX-0001Uu-Ca; Wed, 23 Sep 2026 04:35:23 +0000 Received: by outflank-mailman (input) for mailman id 1429683; Wed, 23 Sep 2026 04:35:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9EhV-0001Un-MW for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 04:35:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9EhU-00Blm0-1T for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 06:35:20 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab356f4-e002-0a2a0a5209dd-0a2a4506ab54-22 for ; Wed, 23 Sep 2026 06:35:19 +0200 Received: from [52.101.201.13] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab35705-195a-0a2a45060019-3465c90d470b-3 for ; Wed, 23 Sep 2026 06:35:19 +0200 Received: from SA1PR12MB999228.namprd12.prod.outlook.com (2603:10b6:806:4db::10) by IA1PR12MB6650.namprd12.prod.outlook.com (2603:10b6:208:3a1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Wed, 23 Sep 2026 04:35:12 +0000 Received: from SA1PR12MB999228.namprd12.prod.outlook.com ([fe80::4dba:119e:8e7c:37b3]) by SA1PR12MB999228.namprd12.prod.outlook.com ([fe80::4dba:119e:8e7c:37b3%6]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 04:35:12 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=p6L730XBTm6fBb+8RyilodyYPqmdNmUUqWZ25+2FvG4VzBKWh6y0c0OIszK/mFNJYP8gWpnt4Ix/WXTzIwvGmAZfSzHYxbqv4H+EEn8fpHuVoM2VQrKIHRoN933T5gUgsW6lcVyiY9VTA6YTIT+M1akhzQK1eaODHY1hWrw0WneeqO4/XVkmwBI0k0e7OsRRDsMqcq4mqUOsjBDZ7czDoJIBZF6ST52g/PdEY3NcqlEWxqI8PwkSy5rAlSD5vgSDSMlhpkSD1ZzwyxS6nd9xffkiyqktdLZZtdiRzJ33X2PdtalTtYqEVaC/HRg6fpFk8NWHKh8rXmevh5mdc6wwZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=x2d3KccSK+qwgXdBkoUCmUtGaaT6R2qysxXQ1M1RQEg=; b=b37Xj3IBtQbLMw2hqRviggBRCePqg+DOqmn5yilJMyuz+/bq2F9gJdFZZsxGf8WeA4211TBJAQGXpfWXbEJXUatRv3Ll36PNwMf2oLTX1ZDehmYHxyubsajfhNWcu7LZO4bMOzpEQtphW009DEqVgB7+rdSbEhQtStU/vibpjt1+rR+ZraoVdLTvmylXPeX0xIZb+cqJB/qiY/s+qZJaCvSyoFawZtbPApR+8YeDQEs2+M5AyOBGhYuN/ZR5mk59vYQ8C/+IfyQ+kfMp2EnmqfqEWMg6/cPs8hlbjTP89uoQD15CeY7ebvCupr7vjaTkaao77URew/luTNTtG+p6tQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x2d3KccSK+qwgXdBkoUCmUtGaaT6R2qysxXQ1M1RQEg=; b=4BqnvGAMXrhcsSSujKtI25AOlwa7oPoLWhi+SQZ0KHUME9N6oV/I9gTGkoE1RzoO4LS2jQtGlRuRf4VfU/11luXYJYbhisHtOgXklFiDNdWk7CDSmBlwvN2zfCAUiExI1gEXV0NmghdcBZ2JF69TUghb6nGnIrqX56yKL2j7EuE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <8ff51404-d752-499c-af65-cd25e0731a2e@amd.com> Date: Wed, 23 Sep 2026 14:34:49 +1000 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH kernel 17/17] x86/sev: Flush IOMMU TLB for trusted devices To: Jianxiong Gao Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Catalin Marinas , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , Liam Merwick , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?Q?Carlos_L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , David Howells , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Christian Marangi , Dave Jiang , Michael Kelley , Ilias Stamatis , Sumanth Korikkar , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , Palmer Dabbelt , linux-coco@lists.linux.dev, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, linux-mm@kvack.org, aik@ozlabs.ru, Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba , Darwin Guo , Shruti , Saurabh Singh References: <20260916115159.1938195-1-aik@amd.com> <20260916115159.1938195-18-aik@amd.com> From: Alexey Kardashevskiy Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SY6PR01CA0107.ausprd01.prod.outlook.com (2603:10c6:10:111::22) To SA1PR12MB999228.namprd12.prod.outlook.com (2603:10b6:806:4db::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA1PR12MB999228:EE_|IA1PR12MB6650:EE_ X-MS-Office365-Filtering-Correlation-Id: 8981c364-a945-4747-3f40-08df192c0e65 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|7416014|366016|376014|11063799006|56012099006|3023799007|4143699003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: ZaDuQetgahZL0POAHplLHKM987LEJ/IKYS6CK/okFsjPboBL5sRvVMf8LQaMVfpusvykSSJRhs2QkXWUaubCCqxVe1yn/v9AUeYZhMT6fKcT2gaHASLNsmqHLUcxfUHz3nONwDrGrTbOLy/nWbN+t7T0NyjxR8sfdFx5dDAMeyHJrVSfNekpqqGlpi8L9nfCkrGdigRnUhnCkSnYIdBeHRDMSt7NC9/Jvwa/zr4l+Gz+bPOpqG1zd5oxynPg7qLs88uhjnMUiRuDl5If779W/jx+SDEVc++ZUOl+3aM2+/e+LvbV9t/OI2D0P3aS05ALNVG0nNIWiw8X+jOm60j7KO3wEbo29z3C85X7Hx1wt8KoKe1Ybxckjec3duxdjktfy1DGMDFJe0CaNQZHIVboaZN/6bxERmKKU7FSO9NVjcbZ9Y87wW8da7q6kuZmf5pdjnLT06CjSilPTz7NDZtU9Q7Rseh7hRvLN7Xix1lK8m+x59QyEnMFay8x5W3dSPtd5h3o+P0HahtYIhmCIjHhyBeSYYBaki9PyCYMYpyWYTFDNFvmzY9LVG/UgcwJr2DydhS4vqzExQe/Io1YkUN0EYLafefs3wFS0q+e1mAqYnLgumtOY9fzJnIAwALAZB0nZCgzrhV/Gzd+CWZj/WvLcyO4dkCKwpsCQu9ij+8Oka4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR12MB999228.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(7416014)(366016)(376014)(11063799006)(56012099006)(3023799007)(4143699003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c2dvSUtpRE8rSkNnc3h5d0gyK04vRC9QMmVSVWE4U3I2VCtrbVlwTEFjRlNn?= =?utf-8?B?NnZ1U2V4eUNPdGQ5eDFuMUJNNDZ2R09KMkN4ZzF5bTREdUoxTVAvT29nRTJQ?= =?utf-8?B?R0J3cEsxVVJDM3k0M1hRMUhLejBmR3hrRkg3a01FUjdkK0djY3UvdFM5NFFE?= =?utf-8?B?b3FoUmFCUklHSTJWM3pNODA1WFVGVnNaU2NjV0MzRU9FMlM5Nlp0SllOTmpo?= =?utf-8?B?R0JRRGJlL0xWbG5PT3V6bk0xWjQ0Z01hVWIxa3oxcFJvU0RvYlF3cjhteXBn?= =?utf-8?B?UXRtU25DSjdjRlRQWXVMcFRRK1RmZ2lmaUgrWmdQV2hJR1pLL2QxL1BmelMx?= =?utf-8?B?VXlVekpVWWJkbEVsQnFydm9PZmZEczJIVDRTMCtBV1BDMXlZcmlkbkx2R3hW?= =?utf-8?B?M2xoQ0hQNWlmUm5DTG01RTc3VFhIeEVXSVFXNjIxcThpeVF6VG5oZUNwdUs0?= =?utf-8?B?RTJkY3lOK1FyTnMzenJOT3dudUhqV25aK3RPWjlYdmtLcVZaWGJpcW9HMkE0?= =?utf-8?B?SDVLRWJMSTVFVXBWZXllNWtsL3hia25DNU5vVEUyMXF0Z2NuaG41Um8xYmRU?= =?utf-8?B?QmxsVjNRQXl1bERvaTJQQ3Fpd2RHejV0bVNxbU5XZ3dDR1BCSUMzS3o3R2Rm?= =?utf-8?B?M2hDUDdKcEhkaVg2d2Zya0I4VDVwOUY5R2E5YlZYRGFyNjgzd2lTYzJmRlhD?= =?utf-8?B?dFNsRkt0Y1dybExWT2pvZ3N0WGcyNnkwZngyVXRkMlFOSzlaU2tLb0JON3pT?= =?utf-8?B?UEtJdTc2elRjNGM3NFp5SHpvWmZERWUrS3puYmtOQkM2MFVsdmd1ZFpUWkJz?= =?utf-8?B?aHhDaHBWcmREZE1nb1BOMFhWM3ZCSlBaMGI4bWVzQ3RzUU95RHJKK2ZIcjd5?= =?utf-8?B?K2ZobjlKenE3K1lJb0F2RW9CMVBZZ1lOTzNIRUU0a0toQlRSY2RrSEZaa2J2?= =?utf-8?B?VFZrKzN0VTlraDZpcVNYYmhKVGsweUpBZVorWDJCbnU0Tkk2M2FtdTFaanA0?= =?utf-8?B?ZUx5bXVibWxNOFhmRnVCMHRrYWhJWnZxUyt5OGNRalFhdUZjcGYxZmwyRDl0?= =?utf-8?B?VWtEY2ZmbmFVWHYrVDJaQ0h0b3lHbmNzNHR3bEV5aUVEK0htZ1RQY0VzT0NV?= =?utf-8?B?dzFIa1BSQVdKSmZkaXJMMUhCZWhDNjVpRlZES0NmQ2ZOM2MyM2NCUGtTdUF1?= =?utf-8?B?V3RWT2FiV0NvRTVWUnhmYlJQcjRGT0dhS1lvL1V0S3VxTlBYMXZkNStIWlVl?= =?utf-8?B?ak1laVcyUUhrSnp1MmpIekFRYjRUcXdDcjRHa2ZWVFhGMlhteURpOVBJZmY2?= =?utf-8?B?ckErSXNvYWJMb1N1aXIzZ0w2QUw3bUo1N3hJN3dRVklsdnBxZU4yQ3JJdlhr?= =?utf-8?B?elMwWmxDUVdqNzhqVWdGbDluOW15L2UwM2VkVUp6YTBFOEUzalpVNitONy9B?= =?utf-8?B?NHRmMEsvcHRyZjVMaEtQRk5qWnFZWHNGYnlrTHVBVHJmUmZuTHRvTlhhYlJJ?= =?utf-8?B?RmpnUm84SkJjTlZ3VHpjZDJjcytmTmNGOFNDeGpxdCtKMzlFTkdsdFI2Y3dj?= =?utf-8?B?VWg4RWJXbW5qQzdiY1ZLZmZ4ZUdIWGR0cXE0SFdpWDVrbEFpaHc1RGh6OEJW?= =?utf-8?B?UnN4ZFlVVk8vVHBTb2tpbUFRdWE0c1djZHhjeDRkSTZ4Rjl0OXpsQmMvblhl?= =?utf-8?B?M0p0TjNiOXFpWDlobnFQMTZwdytNZitySUhXcitUMW9PSVNWMWVucXlrN21Z?= =?utf-8?B?a2dJZ0JiRmwwR0k3eUt5SGRiWkZVU2dBOThJTzExWWlkMC9lREZrcnRabnNV?= =?utf-8?B?M3dhZjZPdzczNlZ5ZExNQWVUbGMvN0huM3pITFczNHZTNTQ5T2RjOUxHclV5?= =?utf-8?B?TDM3OXBjSk5xQTVWVHFIYVptRW9RdTN0RzBQdjZvb3dXcGR3MFRoZGlkRjUy?= =?utf-8?B?bkxOVkpiVW11NEVWNk0xQ0JpSUdZQ0F5bW9xb2FpeFlYOVA3ZHFHSy9VK2lH?= =?utf-8?B?UFBOQ2EwTDFqT0NPaW8xZE5OQUt5ZDJJaCtpa1N3RitVRS9rU2JLRHQ1Ui8r?= =?utf-8?B?U2FPMXJxVXU5QUh5QWUxL0tRdGdVaEhwc1h6M3AzUFVIRmVuR2wyRitJRjg1?= =?utf-8?B?aHZudEFXU1U3bDBlUERPZjBLVUZhWFhBaWRrRVA3QmV6Y0RQMDVxRE03Mi9Z?= =?utf-8?B?L1M5WWtYdnlTK1dqdUsreWRwRzRtWXpNaHF4cTBNMlpSYWVIOHRHdS90Und3?= =?utf-8?B?alo5ZzU2LzZpQS9KREtseER2dXFZcnpDZDJlYk5GMFR3NWUwbVVFZHJqK3FK?= =?utf-8?B?L3pIWk83dEFsdC9wTEtEcVBmcS9lM0pRbXpKdHk5bG9OOW5OY3VtQT09?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8981c364-a945-4747-3f40-08df192c0e65 X-MS-Exchange-CrossTenant-AuthSource: SA1PR12MB999228.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 04:35:12.1580 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zZs7rr9HjiBZLbw/+tgcevxZC4wiBrtIsCkocA1rCwwo3zMPw8jTnfk0grI5DrECh7sD98PZlZVY1ra8DYA4bA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6650 X-purgate-ID: tlsNG-16d1c6/1790138119-FE67277B-D54425E5/0/0 X-purgate-type: clean X-purgate-size: 13959 On 23/9/26 05:22, Jianxiong Gao wrote: > On Wed, Sep 16, 2026 at 5:07 AM Alexey Kardashevskiy wrote: >> +static int alloc_iommu_tlb_flush_ghcb_pages(void) >> +{ >> + unsigned int cpu; >> + struct page *pg; >> + void *p; >> + >> + /* >> + * Allocate per CPU pages while encrypted DMA is not happening yet >> + * and smashing is cheap. >> + */ >> + for_each_possible_cpu(cpu) { >> + if (per_cpu(iommu_tlb_flush_ghcb_page, cpu)) >> + continue; >> + >> + pg = alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL, 0); >> + if (!pg) >> + return -ENOMEM; >> + >> + p = page_to_virt(pg); >> + /* Trigger psmash in the host os now to avoid psmash race later */ >> + snp_set_memory_shared((unsigned long)p, 1); >> + snp_set_memory_private((unsigned long)p, 1); >> + per_cpu(iommu_tlb_flush_ghcb_page, cpu) = p; >> + } >> + >> + return 0; >> +} >> >> int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) >> { >> @@ -111,6 +142,24 @@ int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) >> struct ghcb *ghcb; >> int ret; >> >> + if (!(sev_hv_features & GHCB_HV_FT_SNP_SEV_TIO)) >> + return -EPERM; >> + >> + if (op == SVM_VMGEXIT_SEV_TIO_OP_RUN || op == SVM_VMGEXIT_SEV_TIO_OP_STOP) { >> + if (!(sev_hv_features & GHCB_HV_FT_SNP_IOMMU_TLB_FLUSH)) >> + return -EPERM; >> + >> + if (op == SVM_VMGEXIT_SEV_TIO_OP_RUN) { >> + if (atomic_inc_return(&sev_tio_devices_num) == 1) { >> + ret = alloc_iommu_tlb_flush_ghcb_pages(); >> + if (ret) >> + return ret; >> + } >> + } else if (atomic_dec_return(&sev_tio_devices_num) == 0) { >> + /* Do cleanup or leave it like this? */ >> + } >> + } > > Hi Alexey, > > When testing this series and accepting a locked TDI in the guest > (echo 1 > /sys/bus/pci/devices/.../tsm/accept), the guest immediately > terminates with 0x1:0xd (SEV_TERM_SET_LINUX, GHCB_TERM_IOMMUTLB_FLUSH). Yup, you are right, I do have it fixed exactly like this in my current working tree, just screwed up my rebase (as a newer CPU will do this invalidate differently) and posted a broken version :-/ Sorry about that. Thanks, > > In sev_tio_op(), sev_tio_devices_num is incremented from 0 to 1 before > alloc_iommu_tlb_flush_ghcb_pages() allocates and initializes the per-CPU > iommu_tlb_flush_ghcb_page buffers: > > 1. atomic_inc_return(&sev_tio_devices_num) sets sev_tio_devices_num = 1 > while iommu_tlb_flush_ghcb_page is still NULL on all CPUs. > 2. alloc_iommu_tlb_flush_ghcb_pages() allocates p for cpu = 0 and calls > snp_set_memory_shared((unsigned long)p, 1) to pre-smash the 2M page > before per_cpu(iommu_tlb_flush_ghcb_page, cpu) is assigned (and before > other CPUs' pages are allocated, in case this task is running on cpu > 0). > 3. snp_set_memory_shared() -> __set_pages_state() sees > atomic_read(&sev_tio_devices_num) != 0 and calls ghcb_flush_iommu_tlb(). > 4. ghcb_flush_iommu_tlb() reads this_cpu_read(iommu_tlb_flush_ghcb_page), > gets NULL, and returns -ENOMEM. > 5. __set_pages_state() treats the non-zero return as fatal and calls > sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_IOMMUTLB_FLUSH). > > Calling alloc_iommu_tlb_flush_ghcb_pages() before incrementing > sev_tio_devices_num avoids triggering ghcb_flush_iommu_tlb() while the > per-CPU pages are still being pre-smashed and initialized: > > --- a/arch/x86/coco/sev/core.c > +++ b/arch/x86/coco/sev/core.c > @@ -150,13 +150,12 @@ int sev_tio_op(...) > return -EPERM; > > if (op == SVM_VMGEXIT_SEV_TIO_OP_RUN) { > - if (atomic_inc_return(&sev_tio_devices_num) == 1) { > - ret = alloc_iommu_tlb_flush_ghcb_pages(); > - if (ret) > - return ret; > - } > - } else if (atomic_dec_return(&sev_tio_devices_num) == 0) { > - /* Do cleanup or leave it like this? */ > + ret = alloc_iommu_tlb_flush_ghcb_pages(); > + if (ret) > + return ret; > + atomic_inc(&sev_tio_devices_num); > + } else { > + atomic_dec_if_positive(&sev_tio_devices_num); > } > } > > On Wed, Sep 16, 2026 at 5:07 AM Alexey Kardashevskiy wrote: >> >> IOMMU performs RMP checks when SNP is enabled, the results are >> cached along with the IOMMU translations. When a VM lowers permission >> of a mapped page (moves to a lower VMPL level or from read+write to >> read-only or private to shared), the cached RMP check results require >> invalidation. >> >> At the moment the only way to invalidate IOMMU cache is the RMPUPDATE >> instruction which flushes all IOMMU TLBs. It is a host privileged >> instruction so a VM needs a way to ensure the host has done it. >> Note that the guest's RMPADJUST/PVALIDATE do not flush IOMMU TLBs. >> >> The host implements a new "IOMMU TLB Flush" VMGEXIT code which is >> advertised via bit#11 in the GHCB Hypervisor capabilities. >> >> Use RMPUPDATE in the following way: >> - allocate a page per VCPU (to allow lockless flushing); >> - When invalidation is needed, copy two patterns (A and B) to the page; >> - invalidate the page so the host can make it shared; >> - use new GHCB call to request RMPUPDATE on the host; >> - the host makes the page shared; >> - the host clears pattern A; >> - the host makes the page private again; >> - the host returns to the guest; >> - check if pattern A has changed and pattern B has not; >> - if the above failed, panic(). >> >> The patterns are located far enough to not hit the same cache line to >> work with the cipher text hiding feature. >> >> The host can choose to not execute the request, WARN_ON if this >> is the case. Further patches will attempt to handle this in other way. >> >> Signed-off-by: Alexey Kardashevskiy >> --- >> arch/x86/include/asm/sev-common.h | 2 + >> arch/x86/include/uapi/asm/svm.h | 3 + >> arch/x86/coco/sev/core.c | 92 ++++++++++++++++++++ >> 3 files changed, 97 insertions(+) >> >> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h >> index ff763c3c5d63..51abf8d061fa 100644 >> --- a/arch/x86/include/asm/sev-common.h >> +++ b/arch/x86/include/asm/sev-common.h >> @@ -138,6 +138,7 @@ enum psc_op { >> #define GHCB_HV_FT_SNP_AP_CREATION BIT_ULL(1) >> #define GHCB_HV_FT_SNP_MULTI_VMPL BIT_ULL(5) >> #define GHCB_HV_FT_SNP_SEV_TIO BIT_ULL(7) >> +#define GHCB_HV_FT_SNP_IOMMU_TLB_FLUSH BIT_ULL(11) >> >> /* >> * SNP Page State Change NAE event >> @@ -210,6 +211,7 @@ struct snp_psc_desc { >> #define GHCB_TERM_SECURE_TSC 10 /* Secure TSC initialization failed */ >> #define GHCB_TERM_SVSM_CA_REMAP_FAIL 11 /* SVSM is present but CA could not be remapped */ >> #define GHCB_TERM_SAVIC_FAIL 12 /* Secure AVIC-specific failure */ >> +#define GHCB_TERM_IOMMUTLB_FLUSH 13 /* IOMMUTLB flush failed for SEV-TIO device */ >> >> #define GHCB_RESP_CODE(v) ((v) & GHCB_MSR_INFO_MASK) >> >> diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h >> index 93597ad492bf..269050942c8e 100644 >> --- a/arch/x86/include/uapi/asm/svm.h >> +++ b/arch/x86/include/uapi/asm/svm.h >> @@ -160,6 +160,8 @@ >> #define SVM_VMGEXIT_SEV_TIO_OP_UNBIND 1 >> #define SVM_VMGEXIT_SEV_TIO_OP_RUN 2 >> #define SVM_VMGEXIT_SEV_TIO_OP_STOP 3 >> +#define SVM_VMGEXIT_IOMMU_TLB_FLUSH 0x80000022ull >> +#define SVM_VMGEXIT_IOMMU_TLB_FLUSH_NO_ACTION 1 >> #define SVM_VMGEXIT_HV_FEATURES 0x8000fffdull >> #define SVM_VMGEXIT_TERM_REQUEST 0x8000fffeull >> #define SVM_VMGEXIT_TERM_REASON(reason_set, reason_code) \ >> @@ -285,6 +287,7 @@ >> { SVM_VMGEXIT_AP_CREATION, "vmgexit_ap_creation" }, \ >> { SVM_VMGEXIT_SEV_TIO_GR, "vmgexit_sev_tio_guest_request" }, \ >> { SVM_VMGEXIT_SEV_TIO_OP, "vmgexit_sev_tio_op" }, \ >> + { SVM_VMGEXIT_IOMMU_TLB_FLUSH, "vmgexit_sev_tio_iommu_tlb_flush" }, \ >> { SVM_VMGEXIT_HV_FEATURES, "vmgexit_hypervisor_feature" }, \ >> { SVM_EXIT_ERR, "invalid_guest_state" } >> >> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c >> index ed0e4546d5e5..aa5a3abb4796 100644 >> --- a/arch/x86/coco/sev/core.c >> +++ b/arch/x86/coco/sev/core.c >> @@ -44,6 +44,7 @@ >> #include >> #include >> #include >> +#include >> >> #include "internal.h" >> >> @@ -103,6 +104,36 @@ static unsigned long snp_tsc_freq_khz __ro_after_init; >> >> DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data); >> DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); >> +DEFINE_PER_CPU(u8 *, iommu_tlb_flush_ghcb_page); >> +static atomic_t sev_tio_devices_num; >> + >> +static int alloc_iommu_tlb_flush_ghcb_pages(void) >> +{ >> + unsigned int cpu; >> + struct page *pg; >> + void *p; >> + >> + /* >> + * Allocate per CPU pages while encrypted DMA is not happening yet >> + * and smashing is cheap. >> + */ >> + for_each_possible_cpu(cpu) { >> + if (per_cpu(iommu_tlb_flush_ghcb_page, cpu)) >> + continue; >> + >> + pg = alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL, 0); >> + if (!pg) >> + return -ENOMEM; >> + >> + p = page_to_virt(pg); >> + /* Trigger psmash in the host os now to avoid psmash race later */ >> + snp_set_memory_shared((unsigned long)p, 1); >> + snp_set_memory_private((unsigned long)p, 1); >> + per_cpu(iommu_tlb_flush_ghcb_page, cpu) = p; >> + } >> + >> + return 0; >> +} >> >> int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) >> { >> @@ -111,6 +142,24 @@ int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) >> struct ghcb *ghcb; >> int ret; >> >> + if (!(sev_hv_features & GHCB_HV_FT_SNP_SEV_TIO)) >> + return -EPERM; >> + >> + if (op == SVM_VMGEXIT_SEV_TIO_OP_RUN || op == SVM_VMGEXIT_SEV_TIO_OP_STOP) { >> + if (!(sev_hv_features & GHCB_HV_FT_SNP_IOMMU_TLB_FLUSH)) >> + return -EPERM; >> + >> + if (op == SVM_VMGEXIT_SEV_TIO_OP_RUN) { >> + if (atomic_inc_return(&sev_tio_devices_num) == 1) { >> + ret = alloc_iommu_tlb_flush_ghcb_pages(); >> + if (ret) >> + return ret; >> + } >> + } else if (atomic_dec_return(&sev_tio_devices_num) == 0) { >> + /* Do cleanup or leave it like this? */ >> + } >> + } >> + >> /* __sev_get_ghcb() needs IRQs disabled because it uses per-CPU GHCB. */ >> guard(irqsave)(); >> >> @@ -347,6 +396,42 @@ static int vmgexit_psc(struct ghcb *ghcb, struct snp_psc_desc *desc) >> return ret; >> } >> >> +static int ghcb_flush_iommu_tlb(struct ghcb *ghcb) >> +{ >> + /* AES encrypts with 16 byte blocks */ >> + unsigned long s1[BITS_TO_LONGS(128)], s2[BITS_TO_LONGS(128)]; >> + void *p = this_cpu_read(iommu_tlb_flush_ghcb_page), *p2; >> + struct es_em_ctxt ctxt; >> + int ret; >> + >> + if (!p) >> + return -ENOMEM; >> + >> + /* Keep patterns apart far enough to not share the same cache line */ >> + p2 = (u8 *) p + 2048; >> + >> + vc_ghcb_invalidate(ghcb); >> + >> + BUILD_BUG_ON(ARRAY_SIZE(s1) != 2); >> + if (!rdrand_long(s1) || !rdrand_long(s1 + 1) || >> + !rdrand_long(s2) || !rdrand_long(s2 + 1)) >> + return -EFAULT; >> + >> + memcpy(p, s1, sizeof(s1)); >> + memcpy(p2, s2, sizeof(s2)); >> + >> + pvalidate((unsigned long) p, RMP_PG_SIZE_4K, false); >> + ret = sev_es_ghcb_hv_call(ghcb, &ctxt, SVM_VMGEXIT_IOMMU_TLB_FLUSH, __pa(p), 0); >> + pvalidate((unsigned long) p, RMP_PG_SIZE_4K, true); >> + >> + /* Ensure that the host change is visible */ >> + smp_mb(); >> + >> + if (!memcmp(p, s1, sizeof(s1)) || memcmp(p2, s2, sizeof(s2))) >> + return -EFAULT; >> + >> + return 0; >> +} >> static unsigned long __set_pages_state(struct snp_psc_desc *data, unsigned long vaddr, >> unsigned long vaddr_end, int op) >> { >> @@ -404,6 +489,13 @@ static unsigned long __set_pages_state(struct snp_psc_desc *data, unsigned long >> if (!ghcb || vmgexit_psc(ghcb, data)) >> sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PSC); >> >> + if (atomic_read(&sev_tio_devices_num)) { >> + int ret = ghcb_flush_iommu_tlb(ghcb); >> + >> + if (ret) >> + sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_IOMMUTLB_FLUSH); >> + } >> + >> __sev_put_ghcb(&state); >> >> local_irq_restore(flags); >> -- >> 2.55.0 >> >> > > -- Alexey From xen-devel-bounces@lists.xenproject.org Wed Sep 23 06:11:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 06:11:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429720.1652421 (Exim 4.92) (envelope-from ) id 1x9GCU-0008CN-Ul; Wed, 23 Sep 2026 06:11:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429720.1652421; Wed, 23 Sep 2026 06:11:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9GCU-0008CG-S4; Wed, 23 Sep 2026 06:11:26 +0000 Received: by outflank-mailman (input) for mailman id 1429720; Wed, 23 Sep 2026 06:11:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9GCS-0008CA-TV for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 06:11:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9GCS-006WHq-AP for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 08:11:24 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab36d8b-8faa-0a2a0a5109dd-0a2a4507ce62-8 for ; Wed, 23 Sep 2026 08:11:24 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab36d8b-b4ea-0a2a45070019-4a7de14cf657-3 for ; Wed, 23 Sep 2026 08:11:24 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485b1d2874fso228735f8f.0 for ; Tue, 22 Sep 2026 23:11:24 -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-49fe0c77b8csm23049545e9.3.2026.09.22.23.11.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2026 23:11:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790143883; x=1790748683; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=oeRo1lrFVOAUXTlKOftlBsJcAgKh5BvSU2w80XPL1RM=; b=LALRGMLy1R/zVlLPOrE8uSPrED5GdyCfXpWFm2CfzpywLzcdaJjh1LvCu9837T66Ei qQRpT65yUbCyxGLpT2VhHKoWVamkSXtyqgGRQtHvejyo0A/fYCY9wweY44RkJP45AQv7 SVvEFREeh9rUAY7iLDkSGZtrS7mRjZ73B9kKYR8DoDF2SyzUCeX7wfHoL1/G1M7H6iIk UHzwzivPuoqYZBdW5/fNKcpIZs7uMn7XMZhOvgDVUbPL3Y3PjACY1l677/U2T6TqQYIR hOdz63ItZNcJfXi7CJB0f2W2PdjKFgLjxHZSwekm/Vh9++zbpxpSv5wm3/hk12LGXE3T BjrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790143883; x=1790748683; h=content-transfer-encoding:content-type: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:content-type; bh=oeRo1lrFVOAUXTlKOftlBsJcAgKh5BvSU2w80XPL1RM=; b=m1ZaklLurlVNWUTuZrnoXhKQZyTPVaw9InfE4rBmgjpE0hoN+l9SjMu6YFg/m34w4x edzTOMKrwCPOLRcaEmHRN9PJCuJSNrhbrCI6iC3rfoEGH5IAb5+mTh9+lBaWJoI+F4S6 Fb2YEvJaJzBMK8P9W8KaLVgQ4l6ySGtqQnqchGEyjGqGI9Ac1mazhr4J486GOddPFl+J f0k4MEtQdsgP7j1N1LOglSVLrBTevjuVRCT7vDJGG/ZBfwSp86pdwojXf8FG4O5xxg0Y Z/5gT4H3McWPXM0xDF7cfRTJvKfaLa2tSscDvVGTFHr+SjNVw5BhmpRTx+EtNIN8m2cg n7cQ== X-Forwarded-Encrypted: i=1; AKwUvByZeGLFl805xQ2S9gh0dy3TwbaoR9al5F6mqYqrSOsOo1e2+00YPAlq/rUEx7HzAFRcfFIXZ9C35Vg=@lists.xenproject.org X-Gm-Message-State: AFuF++lA5TNGeZ/gr3jtoPQh/+RDtUZROIM6G2/G2d8Uleanw59plKw5 K6GPnU75z/VAgBVXDNep8Ilb0l2hp5ptnUHof4ueB/y8SAiFA8yuLUtruHhTCVE1tQ== X-Gm-Gg: AYBFou1gEr/Cte+OW+pBhOOQJGhJ3dEvuso0DCLesssEKr7N6Og+PUzfFolrgix0Gyh N8sPXnniEfvOAYqzpsbDezgDLPrsI8duUHej7XEmln0TXToouynz8obQYLzQeHCzueD7wCEzHKX M9Gox6gJeSLZBtVo+izbiAwJ1pZp6d5//zeYuuP/MYm8VRtDeIeavR3mIeeM8N/SpT8s7f7aSpe 000yhEncTlRwmS+XWV2NJ3Fp6Hie7p0f8x6OM33oJgEkTeP0u1BwaiLpTlvsdGGXO/LzrxBVThk 40YZH6eXVEbieqGhEYM1mB1TqfE0FRtrUnyUu6K0vzAjP6t3EsOqSWRDgjcXJw57bTKCKOYwO+4 eZsgsDSHnhaFjkI3vwiUoe/tYOmEjQbZ7vN0YIN/JQWYHgqH14oXhXSJZwYVO3Zgb/E6Ptefre5 x0A0z5TKUBnKoOyjKFfgLZKOpnxcR+CSK8smtL23Ypw5hA3W8uuSAZ6UwNXgD1dMdpxj6cvs2zh tdUxlcQLBOTtLKQzMPFE2mtxF4cadG8W/wQDjwh3c1SoqAlIEwCWFy8lBf1LvU= X-Received: by 2002:a05:600c:c491:b0:49c:f13e:e4d with SMTP id 5b1f17b1804b1-49fde4972e0mr18342185e9.10.1790143883433; Tue, 22 Sep 2026 23:11:23 -0700 (PDT) Message-ID: <1f2eb0d2-5208-40e4-bcd1-55df6ebfc2e3@suse.com> Date: Wed, 23 Sep 2026 08:11:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ns16550: find the console UART on PCI when there is no legacy one To: Benjamin Leggett Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260922184316.324817-1-benjamin@edera.io> 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: <20260922184316.324817-1-benjamin@edera.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790143884-3C817AE4-E076B8FF/0/0 X-purgate-type: clean X-purgate-size: 3220 On 22.09.2026 20:43, Benjamin Leggett wrote: > Amazon EC2 bare metal instances have no UART at the legacy I/O port > 0x3f8. Their only serial port is a 16550-compatible PCI device (vendor > 0x1d0f, device 0x8250) with its registers in the MMIO space of BAR 0. > Today Xen has no console on these systems unless the command line > names that device, and "com1=...,pci" cannot find it, because > uart_config[] doesn't have it. > > Add the device to uart_config[]. Is there a spec that you could point to here? > Additionally, when the port that com1 describes is not present, scan PCI > for a known UART before giving up. This way the same command line works on > systems with and without a legacy UART, and a machine-specific "pci" > option is not needed. The fallback does not run when the command line > gave an I/O base, or when it already asked for a scan with "pci" or > "amt", so explicit config keeps its current meaning. It is > for com1 only: for com2, pci_uart_config() skips the first port it > finds, so it can never match a single-port device. This needs to be split to a separate patch, and not only because right now you're doing two entirely unrelated things in a single change. The addition of the Amazon device is likely uncontroversial, so presumably can go in quickly. Doing a scan when none was asked for, otoh, is potentially problematic: What if there's an issue during scanning? With not having any output set up yet, we couldn't even indicate the problem, and a possible crash would also go entirely silently. > When the scan finds nothing, pci_uart_config() puts back the original > base, and check_existence() does not test MMIO addresses. > > On a system with a legacy UART, check_existence() passes and nothing > changes. This isn't really true, is it? You check ... > @@ -1805,7 +1825,32 @@ static void __init ns16550_parse_port_config( > if ( uart->io_base == 0 ) > PARSE_ERR("I/O base address must be specified."); > if ( !check_existence(uart) ) > - PARSE_ERR("16550-compatible serial UART not present"); > + { > + bool present = false; > + > +#ifdef NS16550_PCI > + /* > + * Some systems, EC2 bare metal among them, have no legacy UART and > + * carry their only serial port on PCI. Look for one before giving up, > + * unless the command line named a base or already asked for a scan. > + * com1 only: for com2 the scan skips the first port it finds, so it > + * can never match a single-port device. > + */ > + if ( uart == ns16550_com && !uart->io_base_set && !uart->pci_scanned ) ... ->io_base_set here, which can only be true when a command line option provided the base address. A cmdline option like "com1=115200" doesn't, and instead the value set by (on x86) __start_xen() is used. If that isn't the correct address to use, check_existence() is (hopefully) going to fail. (For example, I have a system where firmware mixes up COM1 and COM2 settings, which you may only notice after having played with things for a while. In such a case it doesn't help if unexpected PCI bus scanning gets in the way.) Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 23 06:58:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 06:58:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429749.1652431 (Exim 4.92) (envelope-from ) id 1x9GwK-0005a4-7q; Wed, 23 Sep 2026 06:58:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429749.1652431; Wed, 23 Sep 2026 06:58:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9GwK-0005Zx-50; Wed, 23 Sep 2026 06:58:48 +0000 Received: by outflank-mailman (input) for mailman id 1429749; Wed, 23 Sep 2026 06:58:46 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9GwI-0005Zr-Gs for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 06:58:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9GwH-006eLw-Ky for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 08:58:45 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab378a3-8faa-0a2a0a5109dd-0a2a4508bd5c-14 for ; Wed, 23 Sep 2026 08:58:45 +0200 Received: from [40.107.130.90] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab378a5-f659-0a2a45080019-286b825ac444-3 for ; Wed, 23 Sep 2026 08:58:45 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by AMDPR03MB911541.eurprd03.prod.outlook.com (2603:10a6:20b:70c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 06:58:43 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 06:58:43 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bZefkbVlstGM91EMjpwTnga6lpAqcQL2/9iODUcYN+pUioO46La9fCU3QggmKWekLlHHRts6B4B+1knFUsZqZUPbYBCXUszn+aOdGwCEETjE648Jzw9L0Aww3HoX7Ll4XNyOLZ0gjwJY/8YjobLIF7bby7RpYY0QqME6CDdXGxBZRwaMXUGJOI7ouIfHEA5nqych/FzfGnbJ0avQrXkl78x3T1p0j882ighU+Fu9TavUe62bzuzMBdhXILpxH+pue/C+dUZpbXDTXR4r9sTY1Sqb6INtnJyLYsTH8rMglxJNyPzrqZOXG6GNhGWuXAMtszFXdcTHNRLmpz/nN1n2/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pKssA4GK1hBRRYvO/ImT7sgyAtEYimnCFouoTrbpv/U=; b=XGRbTd73Etu7oJr9q0B2NbBixczJ//WxAGeJ0bpfby4A2UhvZfWfLKku1Zg+MhQhaUtKUEetCSuK4WpCpqcYnzMvFELL0wJeojP/faTfdM+RBiQM6t7IHkdQDNjrrRmh9ut3dKDDetWjL63iMkwRKkNcyz4rQnzH5GT9YG1JfYgsy07LLKlneAxqhVFB1gN5QtIx2sPCNOrSGm/MfLHtdbiMZHvVpF6WhdKs5iz7Y2pKweWljMNhoeUOVcuZaKmdgyroDXWclNlzsXUSd97BFwXFykobgud2EcDVvvuZJOIkKQcGED1AUyMw1EPF4vUP2MyckK0/gRniza5plQ3k4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pKssA4GK1hBRRYvO/ImT7sgyAtEYimnCFouoTrbpv/U=; b=rOWDcYLnPglyoNK3W+IgUlkf1a1YxKbnnXec0mYmrUGq7lu1iR+XeCvzHv+EjEojakDecaaoJUgtMD8y0460kTw6pE6JDthSM5Yi4RxsITM/E6kXhjncNUdzbavjoOP44sIrkijcvSToELRoTxjTY/ID1nm4sBerOF9/WyQc1l6uoKNHxgx0A3v/4u2vdJSKZQNJy3KN/DV12EEAEycAw56BpQNsyF3R3z60RzGxYZSV3aXkmFOD+k/+ZpLN2GRm2ZyDCG0V3Feovf9y6A73KIZbFQxTyVjqWT7y+2WkkZKrC5YI3nLjAAtkQH6A9jti5omvmOZBLxYfzNNdmYE4Ww== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Wed, 23 Sep 2026 09:58:39 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH v4] xen/arm: derive GIC CPU interface ID fields from the vGIC Message-ID: Mail-Followup-To: "Orzel, Michal" , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <1101ee75414ec2e6bec05d34118c4fa7f8b60bcf.1790060180.git.mykola_kvach@epam.com> <600256d1-a038-4ceb-a1df-a8d86dfee130@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <600256d1-a038-4ceb-a1df-a8d86dfee130@amd.com> X-ClientProxiedBy: WA2P291CA0010.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1e::16) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AMDPR03MB911541:EE_ X-MS-Office365-Filtering-Correlation-Id: 51392a0b-28a2-4f61-9e5d-08df19401b28 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|4143699003|6133799003|10067099003|56012099006|11063799006|5023799004|18002099003|22082099003|4133799003; X-Microsoft-Antispam-Message-Info: zycc+yu+wTL5PXQ5iIkhI9hZHdM26oHEjrsCiJ7K1E1YsEm+o/HSvdwU+3jBvc5YvKU+/y2OaXrUSM8PSuxm7yETJ/YLDuKfwChi3byLJdBBMxuxmUDG8OiyTPzULydkdA5iRb3AMAI6bgYQX56Yt/jDFJQzRZ7R3UencOR5ftYahTuWLfiJWvCbQSx2PBrjri2eL62I0zlwLSR3UA3FRLXK1revHL8DWk/YVajuqQFfKie+Gh3iUY+VetzPS7P9urRaFu+epjH+v5JVpup/bvOUZKdzdUSU19q3ag82BAqdZl6SFxDuH5MCd71ZOh0a7IBqIxelivKJ2Ysia3sJzUb4VmKEwGp2kOgvOu8PREq01bLcQveuZNQ8j5bbpHkIJ22AQeepIa0dMx3uv89HIpIGrYpLB7f/MREbgAq1dqIfWnZKJVXJHEiyT8+MCr+A8RrRYMTbwJbCmaqJ33B05LlBKhXr895Sf0izMzdfGUV8VUqxBTPKghM1baQoBH/VxoFLA22fDsw7JrMEW58cyiSdPy4oi2kVLB9xStzec1pijyYJS18yjO3LqABC51tHTi2CJARHYYnmyT2EyXi5SYL11pQaWsvChM3VJ/AqWVkVNysDqfbu/iynRWoBLXOa X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(4143699003)(6133799003)(10067099003)(56012099006)(11063799006)(5023799004)(18002099003)(22082099003)(4133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?di82TytaTUFIckMrZ2ZxOUZ4blRNNFRhc21RTHJwMmhrUTQ3UnVtTk5oS1Fi?= =?utf-8?B?RDNucE9iMmxYeUEvQThmajNUeWFBS1ZGRENhSEowRmNXV1pGYURuNDNLUFNp?= =?utf-8?B?TmNzT0hTMDdJcE85Mm5HMGZmd0gxa01FYzNpQnprQ0tmVDdjNFM2QnMreENU?= =?utf-8?B?SzhjWDJQZGhjcUt6dXYxNWRGZUhpbEE3N1lMbUNYNjlZell5UHhDcnRFbEJi?= =?utf-8?B?WTVJY0Z3TE9aMU16MVl2UlhKQmZvcnlVbkdjRU1pK3pQbDdaekY4WlZTd25U?= =?utf-8?B?MmJEQVBkY2pIV3hZbUxKSml4Q1d0RlBRMkFFb09QWUxLL2dUYXFyQmNLa05r?= =?utf-8?B?aDQ1Qnowc0YyYkUvK3ZiQUEzVDVRTmNmOHh0Z0pKTVNTUmJVZlMxNm5rcS9B?= =?utf-8?B?eVIyeGRqNkhnbXpGOS9LVG1lbE5jNkxQaVBlR2F4RmM5Y0JCQk1XK0pNVVZH?= =?utf-8?B?V2EwaXphQlJFWjhsQU4wbDhnb2FxUlluZWNnK1NhcXFNemZKWk4wYlp5b0lC?= =?utf-8?B?L3JvYUxMcXQwcDdNUmtzMlp3SVo2NGhpTWNnQ3lGWDFhUDF3Z1orUnBVT21r?= =?utf-8?B?V3g1MHBBOHZFaTYyT1UrSjVvOHZjQW5lWlQxNWZRVVkwMTVFMDIrbFMrdzN5?= =?utf-8?B?M3RLTVRBaDVoSml6Z2ZrdEsvNC9rdEFVZ0dZaVdaQWJYQ1AwdkVvNE0zbTFv?= =?utf-8?B?S2RDNUdNWmNXNnd3a1crZDBaR2dWQldhV0dEVkFkejhZOStpQlVCZXVTZU9E?= =?utf-8?B?K25iaVBwT2IxMS9vWnkwdUtmcERiQ2djYUdDb1hJRmdwL0RBTDhLVnlxYy9s?= =?utf-8?B?SlVvajZISm02akVER0ROQWsrRjdYR3ZxSFZCK2p3MnM3VTVnTHc5ZHhTNjhp?= =?utf-8?B?aVRiTWxsaVRNU0psYys3Y3JZSDNtRXozT1dGaG5lSGpKdEdxTnBxMzJ4KzAr?= =?utf-8?B?cjZTL0RUdENSbFlIU1RJREs0ZCt2Z3M3OXZzQkJqWDRneWMyNkRIbDNRWmta?= =?utf-8?B?TXFqenZ4aFRGV0pCaTViMkcrR3BoUXltQXF5cDBQakFDRWZaTFBjbTFBcitu?= =?utf-8?B?Wmc5UDJzRnBEczVlZUMwVWFjRFJhZkhISEVwcWhVS0dva01WemNNSzNlZlRt?= =?utf-8?B?VFZheHpTWDVTdjIxNUszUkdlUmJKQUE3bVR3TC8zTDVzamoxelhwWVRGN04z?= =?utf-8?B?T2E2ampxRDVmVmlkUUpJOWIzTHMrVUc2NVVDRVdkUWo4bHlkNk11dzZwckVC?= =?utf-8?B?V0FCNFZtRWZiekJSZWtrWituZktRTFhTUThFR1BoSVVPbEdncUtRNWc1akJl?= =?utf-8?B?UWNqZUNXSXlPRVFmcnI0QlZUQlNyWTRsYmtmWHBVYTFxVlFBQmpBNG05NitP?= =?utf-8?B?Yi8xNlBXU0g0Q1RZWXFPZlMrRFVhWG5xWTRZeUN1QzhKWlQ4WXpNNDZpUG1B?= =?utf-8?B?d2wyR1I3UzYrenFsZUxFOW93LytvSnY0NGtydEZzWm8rYjhuZWFGeCthTjVC?= =?utf-8?B?bUZjeTJ5TnRHVGZUSndkL2RpVWQ3M0tGZzB6YWFXOGptREsyMS9uQ3Y0cHpX?= =?utf-8?B?T3JqNitQVTZjTkJpYTdnL3NoWGszdHo4RHRRckwwUWVYRm5hc3RHYVg5SlRu?= =?utf-8?B?THdpRDdFemdtNGpEUGRnd2pPdm03UTRBTTdrZFlhWDd4RW54RXJKTW5WK2gy?= =?utf-8?B?MzVuSmRmS3RMYVhCanFpcE1sMDhGMTh1a3lUZTRtVFhUNm1HQjFrcUk2RWUw?= =?utf-8?B?SzJWOWxmbUNPU2ZHbXZjd3VxcUN3TmR6VUlJMHZVNk9jWnQ5eERxM2dZbXNv?= =?utf-8?B?QjJ4WXFINThyaUoyYnBqbHRMWjYyV0tBUnpRYUIxT2phOUxqQXdQZCt4NkNn?= =?utf-8?B?L1RWbXR6RXhpNGkzS1RjODhDNjlpamxaTWNuMC9vU3d0VHB4b3dSdXVNT0Iz?= =?utf-8?B?ck5wV2JLY0ZZYlI2UWVleFBmcmZITHNTalJWT2FScDVzQnN3UUYxWC82U1lz?= =?utf-8?B?YlZQMDg4Z2NhTzNVWUNwREhKQjJtTUtPckxESHVPRUFIQnFvVjdTTVhGd0dt?= =?utf-8?B?ampjekE2UDd0R2ZPRGxpdmNTcWxEc0g1RCtQaHVZeXVtVWd4ZkMwcDVORkk2?= =?utf-8?B?aHlrVEdQcnllQmF1Zmpsc1RIYzVVTXFORWdYcGNUOXNaSERxZFlvZWJtaXdj?= =?utf-8?B?a1lsOEtnQjlXQnFQcUEwSTB0TmdWQXhnMlRvTGs0VmVDeHN0UnhMS3hrcndE?= =?utf-8?B?UlEvM2ZjWXcrVkxCS2dINjZ2Tkk2MHVJc01sSjRiQnRPUnBwNVB5a0oxMlpW?= =?utf-8?B?TS9FRWJJemhZcDB5QktRSVJNZ3BmcUdBSmZyS2pLcjBmMU5SbnJjdz09?= Content-Transfer-Encoding: 7bit X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51392a0b-28a2-4f61-9e5d-08df19401b28 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 06:58:43.5796 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +NKfLm2vGTLf0RJcAwBBQBL6VSW8uP06RWz5/4ne5QY7okfO4Dzn6DvN3ipPx+NPqEAW2ztA6FLO92xtoqljXw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMDPR03MB911541 X-purgate-ID: tlsNG-c1860d/1790146725-CCB7187B-6E3BA996/0/0 X-purgate-type: clean X-purgate-size: 8048 Hi Michal, Thanks again for reviewing the new version. On Tue, Sep 22, 2026 at 12:40:45PM +0200, Orzel, Michal wrote: > > > On 22-Sep-26 09:21, Mykola Kvach wrote: > > Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo, > > which is initialized from the sanitized host CPU feature state. This > > does not necessarily match the virtual interrupt controller configured > > for a domain. > > > > A vGICv2 domain can therefore observe a nonzero GIC field when the host > > supports the GIC system register interface, even though Xen disables that > > interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can > > observe encoding 0b0011, although Xen exposes only its vGICv3 model. > > > > Derive the fields from the domain's vGIC version instead. Expose 0b0000 > > for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the > > ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through > > CP15 in AArch32 state. Leave the alias unchanged when AArch32 is > > unavailable. > > > > Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64") > > Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers") > > Signed-off-by: Mykola Kvach > > --- > > Changes in v4: > > - Explain why ID_PFR1_EL1 is left unchanged without AArch32 EL0 support. > > - Move all ID_PFR1_*_SHIFT definitions to the common asm/sysregs.h and > > remove the unused cpregs.h includes from the ARM64 files. > > - Return explicit unsigned GIC field values to avoid MISRA C Rule 10.3. > > > > Changes in v3: > > - Add direct dependencies for the shared ID register helpers. > > - Move ID_PFR1_GIC_SHIFT to the common CP15 register header. > > - Apply cosmetic fixes from review. > > > > Changes in v2: > > - Share the GIC ID field helpers between the AArch64 and AArch32 paths. > > - Parenthesize the individual ASSERT conditions. > > - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable. > > - Target master instead of the 4.22 release. > > > > v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/ > > --- > > xen/arch/arm/arm64/vsysreg.c | 21 ++++++++++++++++++- > > xen/arch/arm/include/asm/arm64/sysregs.h | 9 -------- > > xen/arch/arm/include/asm/sysregs.h | 9 ++++++++ > > xen/arch/arm/include/asm/vreg.h | 26 ++++++++++++++++++++++++ > > xen/arch/arm/vcpreg.c | 12 ++++++++++- > > 5 files changed, 66 insertions(+), 11 deletions(-) > > > > diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c > > index 66f4f23bb3..2912445301 100644 > > --- a/xen/arch/arm/arm64/vsysreg.c > > +++ b/xen/arch/arm/arm64/vsysreg.c > > @@ -299,7 +299,22 @@ void do_sysreg(struct cpu_user_regs *regs, > > * to identify the processor features > > */ > > GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0) > > - GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1) > > + case HSR_SYSREG_ID_PFR1_EL1: > > + { > > + register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1]; > > + > > + /* > > + * Preserve the sanitized ID_PFR1_EL1 value when AArch32 EL0 > > + * is not supported, as for the other AArch32 ID registers. > > + */ > > + if ( cpu_feature64_has_el0_32(&domain_cpuinfo) ) > > + guest_reg_value = id_reg_set_gic_field(guest_reg_value, > > + ID_PFR1_GIC_SHIFT, > > + v->domain); > > + > > + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, > > + guest_reg_value); > > + } > > GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2) > > > > case HSR_SYSREG_ID_DFR0_EL1: > > @@ -362,6 +377,10 @@ void do_sysreg(struct cpu_user_regs *regs, > > guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask; > > } > > > > + guest_reg_value = id_reg_set_gic_field(guest_reg_value, > > + ID_AA64PFR0_GIC_SHIFT, > > + v->domain); > > + > > return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, > > guest_reg_value); > > } > > diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h > > index f3c11d871e..f6ece8f972 100644 > > --- a/xen/arch/arm/include/asm/arm64/sysregs.h > > +++ b/xen/arch/arm/include/asm/arm64/sysregs.h > > @@ -438,15 +438,6 @@ > > #define MVFR1_FPDNAN_SHIFT 4 > > #define MVFR1_FPFTZ_SHIFT 0 > > > > -#define ID_PFR1_GIC_SHIFT 28 > > -#define ID_PFR1_VIRT_FRAC_SHIFT 24 > > -#define ID_PFR1_SEC_FRAC_SHIFT 20 > > -#define ID_PFR1_GENTIMER_SHIFT 16 > > -#define ID_PFR1_VIRTUALIZATION_SHIFT 12 > > -#define ID_PFR1_MPROGMOD_SHIFT 8 > > -#define ID_PFR1_SECURITY_SHIFT 4 > > -#define ID_PFR1_PROGMOD_SHIFT 0 > > - > > #define MVFR2_FPMISC_SHIFT 4 > > #define MVFR2_SIMDMISC_SHIFT 0 > > > > diff --git a/xen/arch/arm/include/asm/sysregs.h b/xen/arch/arm/include/asm/sysregs.h > > index f6af987ef5..8dcf82a694 100644 > > --- a/xen/arch/arm/include/asm/sysregs.h > > +++ b/xen/arch/arm/include/asm/sysregs.h > > @@ -9,6 +9,15 @@ > > # error "unknown ARM variant" > > #endif > > > > +#define ID_PFR1_GIC_SHIFT 28 > > +#define ID_PFR1_VIRT_FRAC_SHIFT 24 > > +#define ID_PFR1_SEC_FRAC_SHIFT 20 > > +#define ID_PFR1_GENTIMER_SHIFT 16 > > +#define ID_PFR1_VIRTUALIZATION_SHIFT 12 > > +#define ID_PFR1_MPROGMOD_SHIFT 8 > > +#define ID_PFR1_SECURITY_SHIFT 4 > > +#define ID_PFR1_PROGMOD_SHIFT 0 > > + > > #ifndef __ASSEMBLER__ > > > > #include > > diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h > > index 387ce76e7e..96de1c4916 100644 > > --- a/xen/arch/arm/include/asm/vreg.h > > +++ b/xen/arch/arm/include/asm/vreg.h > > @@ -4,11 +4,37 @@ > > #ifndef __ASM_ARM_VREG__ > > #define __ASM_ARM_VREG__ > > > > +#include > > +#include > > +#include > > + > > +#include > > + > > typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r, > > bool read); > > typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r, > > bool read); > > > > +#define ID_REG_GIC_WIDTH 4 > > + > > +static inline unsigned int vgic_id_gic_field(const struct domain *d) > > +{ > > + ASSERT((d->arch.vgic.version == GIC_V2) || > > + (d->arch.vgic.version == GIC_V3)); > > + > > + return d->arch.vgic.version == GIC_V3 ? 1U : 0U; > > +} > > + > > +static inline register_t id_reg_set_gic_field(register_t val, > > + unsigned int shift, > > + const struct domain *d) > > +{ > > + register_t mask = GENMASK(shift + ID_REG_GIC_WIDTH - 1, shift); > > + > > + return (val & ~mask) | > > + ((register_t)vgic_id_gic_field(d) << shift); > No need for split. It would fit 80 chars. Ack. > > > +} > This is a header included by a few source files, so the less we expose the > better. Please combine vgic_id_gic_field() into id_reg_set_gic_field() given its > simplicity and the fact that it is only used in the latter. Also, your new > helpers use a vgic.h namespace (this header uses vreg_ prefix). I think it makes > sense to s/id_reg_set_gic_field/vreg_id_reg_set_gic_field/ and > s/ID_REG_GIC_WIDTH/VREG_ID_REG_GIC_WIDTH/. Thanks, will be addressed in v5. > > With that changed: > Reviewed-by: Michal Orzel Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 23 07:31:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 07:31:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429775.1652440 (Exim 4.92) (envelope-from ) id 1x9HS2-0002RZ-JY; Wed, 23 Sep 2026 07:31:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429775.1652440; Wed, 23 Sep 2026 07:31:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9HS2-0002RS-GS; Wed, 23 Sep 2026 07:31:34 +0000 Received: by outflank-mailman (input) for mailman id 1429775; Wed, 23 Sep 2026 07:31:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9HS1-0002RM-09 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 07:31:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9HRz-00AESD-Mk for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:31:31 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3804d-bab6-0a2a0a5309dd-0a2a450596b2-18 for ; Wed, 23 Sep 2026 09:31:31 +0200 Received: from [74.125.225.100] (helo=mail-wr2-f36.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab38053-4cb1-0a2a45050019-4a7de1648045-3 for ; Wed, 23 Sep 2026 09:31:31 +0200 Received: by mail-wr2-f36.google.com with SMTP id ffacd0b85a97d-4843c3ee4cfso374900f8f.2 for ; Wed, 23 Sep 2026 00:31:31 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4886848646dsm4321278f8f.10.2026.09.23.00.31.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 00:31:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790148691; x=1790753491; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Ez00zs/pIQ/TI/e+vxBc1G78CKXnF3ieCrItTOcLyvY=; b=g+goRExjdJUJtXfcfUSZ+6Ka8fTUHnSKhrVbRfg/CGKiy/HQBtz591Qc5gRNNOFLdr 3RGKXqprKYHWlC2G3DCfh+t909/yAzj+HDcym+d+UUaeDF0gS82qd6LvRiLgMPfrh49M iuwkpwDrBYXO88NPtsO0uWjsKZ0lRmcTFDLrcah7O18h4sEQiYNjKuHY3ybhN+tUEyhM tjMo4SWFHwCd77a4VWksl8LhkbqWY/P6KqbyJvyFxclH4AcixktYg0DWxF8NR3pkz92+ mZ/Iul8Bc8nEv5p9TUSItGoMh4Ta0m1VIpEuaaaXIwU0Lx3D0mHYYDgyVEKTada1koJK SeIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790148691; x=1790753491; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=Ez00zs/pIQ/TI/e+vxBc1G78CKXnF3ieCrItTOcLyvY=; b=hiG8M+XTGicEiE/WiUKXCncw517kkeQuqHonCmeLLzMXxFdCPRfbfAMhqsWyETYPqq sHqY+CUy7xvGz6MJ0Nrm521PKsKnJJjS9tDqYI5BeEzMeNm3jvLTJ5hTwq5/Y+WiEp+W +EARMRiK4KMCdKlGb61IRykS5ouAoXX9qn3y7BshjQ36HOJr0/XUPBS2RBThWSt9lLDR 0uC5+D6rlFiAMdS+Wn+IQMCzJeY9fGK5kS3HZfHdoiVlzzC1N7jU7Ll/6aAjMp4zRAiR iVfDwIGGN8u3isWyo8qOoxFVGhK8vdnJTGuDd3tyjbf2ygOcSgV2trVlTHT3c28BNWq5 YpUQ== X-Gm-Message-State: AFuF++kqJot82UXJFQ/QyhlKj9Hfz15VExyeaKiPAhlZH7YBV7g9IFkD CAruIsZ1BNPf9uLLyOVZitAYKHk5FQXt1U24yD0QCBhcbwa+bbtUfH8/ X-Gm-Gg: AYBFou0L83Y+/UrNO5CtDAkFSRsJ0A39frAjmCuYKUMd2vQerusVMC0gLeKHOlZuvqe QOOEIrspj0cNl70p02XcnoHB8YNyjdlAbVpckg9S2RgStJaB4FFUL1PMKRNZ0DE0sn/EbYuZ9UU qI7QVEDIaS8RzbjiZn8fjAzg+cC5oNYdtzygLeyRSKdARyPtBxACOM47RPRssGKbCvz/np7swE4 M+QKMOCeK9MMTPcgpjfc/QbIn4OWi3h7wnKK/DnlGCK1AcUDHCUyO8ssVQCeNnRyhwHAqb8tbY5 S3SFO4S7YRc/GMAhD4Km/c5+z4ZLCPzlZIP7uXngp9bi8+QAGzPXLAC3jBWcU1N2WRwQTpIoXcK Hm8CCGxmsDQirLAdJEzq5JmHplGY6cTkX26Hx97W08wOilJasicbI7iAhIOK8YOfg4+rSOhT4mu LrJxRrj80Hsoo68KSEtGXU7F5A0Xc13Hk8yKqLvgos4MWW0QLN7ORn+RbITJnYU9K+qDo6uONOT 6rVeRlfQyamYO1EoBX8Diy4JAbd/eoikZ9MUQV4lfE+TBnVzy8= X-Received: by 2002:a05:6000:260a:b0:485:c240:20ec with SMTP id ffacd0b85a97d-488670a3596mr2501691f8f.37.1790148690466; Wed, 23 Sep 2026 00:31:30 -0700 (PDT) Message-ID: <5b531087-2327-4f59-8a7c-c16941a5f324@gmail.com> Date: Wed, 23 Sep 2026 09:31:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling To: Baptiste Le Duc , Jan Beulich Cc: xen-devel@lists.xenproject.org, Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> <450d0c5e-2101-4b1c-98fd-2f438bd0ccf3@suse.com> <1790010225.8631fc262581453bbf619ec5b2062170.1a0c4ec74f000072c4@vates.tech> <1790068677.8631fc262581453bbf619ec5b2062170.1a0c868594900072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790068677.8631fc262581453bbf619ec5b2062170.1a0c868594900072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790148691-F78BE2A1-31DFB191/10/73395122804 X-purgate-type: spam X-purgate-size: 8338 On 9/22/26 11:17 AM, Baptiste Le Duc wrote: > On 2026-09-22 08:24 +0200, Jan Beulich wrote: >> On 21.09.2026 19:03, Baptiste Le Duc wrote: >>> On 2026-09-21 17:26:47+02:00, Jan Beulich wrote: >>>> On 10.09.2026 11:34, Baptiste Le Duc wrote: >>>>> @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) >>>>> return false; >>>>> } >>>>> >>>>> +/* >>>>> + * Svade and Svadu extensions represent two schemes for managing the PTE A/D >>>>> + * bits. When the PTE A/D bits need to be set, the Svade extension indicates >>>>> + * that a page fault will be raised. In contrast, the Svadu extension supports >>>>> + * hardware updating of the PTE A/D bits. >>>>> + * >>>>> + * There are 4 possible combinations of these extensions in the device tree. >>>>> + * The default hardware behavior for each is: >>>>> + * >>>>> + * 1) Neither Svade nor Svadu present in DT => It is technically unknown >>>>> + * whether the platform uses Svade or Svadu. Xen should be prepared to >>>>> + * handle either hardware updating of the PTE A/D bits or page faults when >>>>> + * they need updating. In that case, Xen assumes Svade because it's >>>>> + * harmless if the platform is actually Svadu, while assuming Svadu on real >>>>> + * Svade hardware risks an unhandled page fault. >>>>> + * >>>>> + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. >>>>> + * >>>>> + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. >>>>> + * >>>>> + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off >>>>> + * at boot time by setting A/D bits. To use Svadu, the supervisor must >>>>> + * explicitly enable it using the SBI FWFT extension. >>>>> + * >>>>> + * The Svade extension is mandatory and the Svadu extension is optional in the >>>>> + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose >>>>> + * option 3. Platforms aware of the profile can choose option 4, and Xen won't >>>>> + * get the benefit of Svadu until the SBI FWFT extension is available. >>>>> + * >>>>> + * In other words, hardware manages the A/D bits on its own only in case 3, in >>>>> + * all the other cases software has to preset them. Instead of open coding this >>>>> + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is >>>>> + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. >>>>> + */ >>>>> +static void __init riscv_resolve_ad_scheme(void) >>>>> +{ >>>>> + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); >>>>> + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); >>>>> + >>>>> + /* Case 3: leave the A/D bits management to hardware. */ >>>>> + if ( svadu && !svade ) >>>>> + return; >>>>> + >>>>> + /* Case 4 */ >>>>> + if ( svadu && svade ){ >>>>> + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ >>>> >>>> Nit (style): Brace placement. >>> Sorry for that. I will fix that in v3. >>>> Furthermore this is written in a way which Misra would call "dead code". I'd >>>> like to suggest (leaving out comments): >>>> >>>> if ( svadu ) >>>> { >>>> if ( !svade ) >>>> return; >>>> >>>> if ( !sbi_probe_extension(SBI_EXT_FWFT) ) >>>> printk(...); >>>> } >>> I assume you are referring to Misra C:2012 Rule 13.5 "The right operand >>> of a logical && or || operand shall not contain persistent side effect" >>> >>> If yes, IMO, I think it doesn't apply here as `svade` is evaluated >>> before the `if` so there is no side effect that wouldn't have been >>> executed in case of svadu=false. >> >> No, there's nothing side-effect-ish here. With "svadu && !svade" in the >> first if(), the rhs of "svadu && svade" in the second one is dead code: >> Things would function the same with it dropped. > Ok, now I understand, thanks. I'll fix it in next round. >> >>>>> + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" >>>>> + "RISC-V: Defaulting to software A/D updates (Svade).\n" >>>>> + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); >>>> >>>> Nit (style): Indentation (in multiple ways). Furthermore XENLOG_* needs >>>> repeating after every newline. >>>> >>>>> + } >>>>> + } >>>>> + >>>>> + /* Cases 1, 2: Xen assume Svade to be enabled */ >>>>> + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); >>>> >>>> Isn't this a lie (to ourselves) then? >>> If you are talking about case 1: >>> [1] Yes, it's technically a lie for boards shipped before >>> the svade/svadu extension was ratified (e.g., HiFive Premier P550). >>> These extensions merely formalized a mechanism that already existed in >>> hardware. >> >> Wait, how do you know this for _all_ boards anyone may ever have made? > We don't know but based on [1] and my commit message, if neither > Svade nor Svadu are present in DT then it is technically unknown whether > the platform uses Svade or Svade. It is unknown from DT point of view but it isn't true from h/w point of view. H/W knows what it supports Svade or Svadu. That is why I am not convinced that in p2m_set_permission() we should use DT binding explanation. The original comment is better as it describes all the possible from h/w point and not DT point of view. Also, generally nothing guarantee that DT is correct (someone miss to add Svade or Svadu in riscv,isa property) so make an explanation *only* based on it probably isn't the best one option and probably it will be better just have a comment as it was in original changes. I think that the easiest option for us is to ... > Hypervisor may then assume Svade to be > present and enabled or it can discover based on mvendorid, marchid, and > mimpid. For this patch, I choose to have the Hypervisor assumed Svade. > > Saying that, I agree that it doesn't make sense to manually have set > Svade extension in the isa bitfield as we could just preset A/D bits > regardless of Svade/Svadu during the p2m_set_permission(). It's what But then it means that in the case of Svadu we will have not precise statistics about A/D bits. I think that for p2m_set_permission() we still may want to have if () condition around as at the moment of p2m_set_permission is being called we could identify which A/D scheme is supported by h/w. Therefore I think we still want to set ISA bitmap based on what I described below ... > kvm explains in kvm_riscv_gstage_map_page(): > > /* > * A RISC-V implementation can choose to either: > * 1) Update 'A' and 'D' PTE bits in hardware > * 2) Generate page fault when 'A' and/or 'D' bits are not set > * PTE so that software can update these bits. > * > * We support both options mentioned above. To achieve this, we > * always set 'A' and 'D' PTE bits at time of creating G-stage > * mapping. To support KVM dirty page logging with both options > * mentioned above, we will write-protect G-stage PTEs to track > * dirty pages. > */ > > > [1] https://lore.kernel.org/lkml/20240628093711.11716-1-yongxuan.wang@sifive.com/#t >> And for all qemu (and alike) versions which supported RISC-V? > > Concerning qemu, you're right, in case when (!svade && !svadu) they use > by default Svadu (hw updating) for backward compatibility. > >> >>> [2] For boards that do support svade, we could enforce DT >>> declaration by adding it to `required_extension` as they are >>> explicitly supporting it. However, doing so would cause boards >>> without svade/svadu support (as described above) to hit a panic >>> during boot. ...to require the user to specify either Svade or Svadu in the DTS. If neither is mentioned in the DTS, the user should be prompted to choose one of the two options, since, from a hardware perspective, the hardware must support one of them. Also, I think we could detect in runtime if Svade is supported but it is IMO overcomplication of the things instead of force use to put implicity Svade or Svadu in DTS. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 23 07:49:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 07:49:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429793.1652449 (Exim 4.92) (envelope-from ) id 1x9HjL-0004FN-3A; Wed, 23 Sep 2026 07:49:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429793.1652449; Wed, 23 Sep 2026 07:49:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9HjL-0004FG-0M; Wed, 23 Sep 2026 07:49:27 +0000 Received: by outflank-mailman (input) for mailman id 1429793; Wed, 23 Sep 2026 07:49:25 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9HjJ-0004FA-Mw for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 07:49:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9HjJ-00CiDz-3g for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:49:25 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab38484-bab6-0a2a0a5309dd-0a2a450cb49c-2 for ; Wed, 23 Sep 2026 09:49:25 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab38484-f479-0a2a450c0019-4a7de18cb7e3-3 for ; Wed, 23 Sep 2026 09:49:25 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e4b11so3184225e9.3 for ; Wed, 23 Sep 2026 00:49:24 -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-49fde18af34sm53025975e9.6.2026.09.23.00.49.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 00:49:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790149764; x=1790754564; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=bNNRMwXYfNfMtNHDBcL5O+NwJVmpzrAMXA+Pmy4bEG4=; b=GAP6pqHcHUIYvs638d3f46nB3FJfAYDa/Olmr3hvcNdCJqAyCmqrSZ9HAtfeJZ8Sa1 /eTfXyMBByKYOmF6LWwvJxUZUAZSFE52Ns7miQ2sb2072kuPxD60Y3XxWpctNe5U2HZn lK+KpGynkkEOv+LUktFMFt/rNJXGi39ECFERhaMNP92ERcVlxqIW9F8u1Nbm1IdQQubQ 4wKpoNQPhvr4AmLMeM+dftheJqKuvxDeBoHFDnDZ1+A+soaCrOV//JsqgIoM16WzIVKa fXH7426lqSkIcSL5v2TkW/OeOevL9/xwjyTNHAzJUuoUNKGSFRfrjeIo6iFvMgZWGD/c f3+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790149764; x=1790754564; h=content-transfer-encoding:content-type: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:content-type; bh=bNNRMwXYfNfMtNHDBcL5O+NwJVmpzrAMXA+Pmy4bEG4=; b=WTRM2d9Btzm5HS4T67yUr9q5vl2CKSGFIWk68iUJoEz+0a79jw5Lm1SpFxQ3MQvoE0 9M62bCxvEgcfsJT4JhoJwkPwPQdSnrjZomD3VNjsvECbd1b5wjJy3auFL8QEcbXrq25n UJOdGhP+1cj0yKD8pbA8CKnpceqGzfGbN87w/f58iLV7EITjjTUgKkZ6E2mTQjKpqeoG wYeOx1xbU3R7zwzW29Kd4aYpl6s3/Pzy7/xKmHGZBcFfThk1NMK+Tlb/adEIaWYc200D QplOwLM277ITDXuTsT7/B5KoxhAh37j3zXqEORjAS84/HBhu7L2AhNsyTiznbE5vXsUs PgIQ== X-Forwarded-Encrypted: i=1; AKwUvBwKRS5FBOKEvZ2H5hcyzWInseyk+MVjnZBbaH4BkLN5X+0nos1hhoxZK6zfsyoqRRBq7JXxdAztV9Y=@lists.xenproject.org X-Gm-Message-State: AFuF++laW4DBXc0/4JDCRIK8C1LW4TEqWbPSV+sbID6RoMPCBSnq/qnt m0eoQgjjNs5dAieQrGsq2L42fra3LwaKtNBG9e83bdWDFSZNEB4pg+8lpJfqjmNMZg== X-Gm-Gg: AYBFou0rHcqXB1F01m3mcYpCBG/Ztpmom6Xgz6TccItcx7T3OXRD6rbfjWrZzzP/JQK DHGp0RFZk6InExplH2WdSIV59s1pULV/Caj0+mcByeeNYKhwKGszXbJi8+Mxt0LkpOrfT1Vp6kz I7SL0a3c79ehwRE5Bta5VL8l+QiMZ8pBtoOsBi1oByDVN1R6JE22xAA4a9NRTpiFynH7JQKcyA1 4D9v8qafbK0LJLB4BfCTCvNTlhldeVbD0mqOo0NahwSkbncUrFdzdPywoaZ/7Icyt2Vak+4kRK4 dM5o7YATN7DIcWv1nEK35LplqVFIK6pmVmwKnBWgEmPOQq6PBCM/sp7Y6FjU5kx3amNA16va4T/ FtPNnk4xvvCkRH48wq6lfo2Bd7i9/YYJkzq2GpePGvS6UudIhA5FzAspwqIs6BJHdpTb5hHJ697 /AzAzpXZ2XpfReuryimSGDo+cv2fKhnM1TShT7YMNt1M4+WpI3N5O2GuHMctl7zequ1cbGZRJmw xCYlR6rpsBoR0+vv0GbxT+JP5MLy9qhB3wDXhPtklGI8zovuUr9m/2ERJ6VoaMKhDX6P9KP X-Received: by 2002:a05:600c:46d1:b0:49d:15b9:2a2a with SMTP id 5b1f17b1804b1-49fdefffe1fmr21341335e9.10.1790149763103; Wed, 23 Sep 2026 00:49:23 -0700 (PDT) Message-ID: <96c36c5c-eb07-4724-ab73-a6153ced1e33@suse.com> Date: Wed, 23 Sep 2026 09:49:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/2] tools/hvmloader: implement Intel IGD extended VBT support To: Chuck Zmudzinski Cc: qemu-devel@nongnu.org, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260913032724.62438-1-brchuckz@aol.com> <20260913032724.62438-2-brchuckz@aol.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: <20260913032724.62438-2-brchuckz@aol.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790149765-008CDA5B-333037C4/0/0 X-purgate-type: clean X-purgate-size: 13527 On 13.09.2026 05:27, Chuck Zmudzinski wrote: > Modern Intel IGD devices do not work well with the current implementation of > support for the Intel IGD in hvmloader because it lacks support for an > extended video bios table (VBT). > > Code 43 errors in Windows guests and failure of the guest screen to light up > are some of the problems that occur with the current implementation. > > To address this problem, this patch implements support for Intel IGD devices > with an extended VBT and OpRegion version 2+ which is required for most modern > Intel IGD devices, as noted in the Linux kernel vfio commits referenced in the > Link tags below. This patch ports support for devices with an extended VBT and > OpRegion 2+ which was added in those commits for KVM/vfio, but adapted for Xen > HVM guests with PCI passthrough. > > This patch depends on compatible support in the device model. If hvmloader > detects the device model lacks such support, it will fall back to the > currently implemented protocol for configuring the OpRegion to provide > backward compatibiltiy for systems that lack a device model with support for > an extended VBT. > > The primary reason the OpRegion needs to be patched in some cases is that with > the addition of the RVDA and RVDS fields to the OpRegion, the OpRegion is not > position-independent and may need to be patched if it is moved to a different > address in the guest. This means the current protocol of having the device > model directly map the unmodified host OpRegion to the guest is not compatible > with the requiremnts of the newer devices that in some cases require that the > OpRegion be modified for it to be compatible with the guest address space. > > In this implementation, the device model has the responsibility to read the > host OpRegion and patch it as needed before exposing it to the guest. Since an > extended VBT means more pages are needed for the OpRegion, depending on the > size of the extended VBT, hvmloader has the responsibility to edit the E820 > map to accomodate the additional pages needed to contain the OpRegion + VBT. > > To implement this in hvmloader, use a variable, igd_opregion_e820_pages, > instead of the constant, IGD_OPREGION_PAGES, to represent the number of pages > to reserve in the E820 map for the OpRegion + VBT. Also, to remove the > confusion introduced by setting IGD_OPREGION_PAGES to 3 in an earlier patch > to account for the fact that the OpRegion is not guaranteed to be aligned on > a page boundary, reset IGD_OPREGION_PAGES to 2 so it matches the actual size > of the OpRegion. > > Instead of only writing to the PCI_INTEL_OPREGION register, first read from it > to provide a way for both hvmloader and the device model to discover if both > components have support for an extended VBT and more than 3 pages reserved for > the OpRegion + VBT. The device model detects the read of the register before > the write to learn that hvmloader has support, and hvmoader detects that the > device model returns the number of pages to reserve for the OpRegion + VBT > instead of 0 when it first reads the register to learn that that the device > model has support. When this new protocol is supported by both hvmloader and > the device model, the device model will not expose the host OpRegion directly > to the guest via a direct mapping as the old protocol does but instead exposes > an emulated copy of the OpRegion and VBT using its ioreq server. This has the > added benefit of preventing extraneous host memory in the regions before or > after a non-page-aligned OpRegion that should be confidential to the host from > being exposed to the guest. > > Testing reveals that when the device model exposes the OpRegion to the guest > by mapping it to the device model's ioreq server, the Windows Intel IGD > graphics dirvers are unable to access the OpRegion and report Code 43 errors > with the result being that the guest screen never lights up. So after the > device model exposes the OpRegion to the guest using its ioreq server, make a > copy of it and use a copy of the OpRegion and VBT which is backed by RAM > allocated to the guest instead of mapped via the ioreq server. This fixes the > Code 43 errors reported by the Windows IGD graphics drivers. > > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=bab2c1990b78 > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=49ba1a2976c8 > Signed-off-by: Chuck Zmudzinski Despite the non-negligible number of comments below, I think this is in a much better shape now. > --- a/tools/firmware/hvmloader/config.h > +++ b/tools/firmware/hvmloader/config.h > @@ -8,7 +8,8 @@ enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt }; > extern enum virtual_vga virtual_vga; > > extern unsigned long igd_opregion_pgbase; > -#define IGD_OPREGION_PAGES 3 > +extern unsigned int igd_opregion_e820_pages; > +#define IGD_OPREGION_PAGES 2 I wonder if this is a good way of expressing things. Specifying a page count here kind of implies page alignment. Imo specifying a size in bytes here would be better, as that then makes more natural that an extra page needs adding in the legacy case (to account for the area not starting at a page boundary). See also a comment further down, likely leading to elimination of most of the users of this constant. > --- a/tools/firmware/hvmloader/pci.c > +++ b/tools/firmware/hvmloader/pci.c > @@ -44,6 +44,7 @@ uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0; > > enum virtual_vga virtual_vga = VGA_none; > unsigned long igd_opregion_pgbase = 0; > +unsigned int igd_opregion_e820_pages = 0; > > /* Check if the specified range conflicts with any reserved device memory. */ > static bool check_overlap_all(uint64_t start, uint64_t size) > @@ -93,6 +94,9 @@ void pci_setup(void) > uint16_t class, vendor_id, device_id; > unsigned int bar, pin, link, isa_irq; > uint8_t pci_devfn_decode_type[256] = {}; > + uint32_t igd_opregion; > + void *opregion_vbt_scratch; > + bool opregion_is_direct_mapped; Please declare these in the narrowest possible scope, i.e. ... > @@ -192,12 +196,98 @@ void pci_setup(void) > { ... apparently here. > igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES); Why do you leave this untouched? By splitting the mem_hole_alloc() calls, you rely on implementation details of that function without there actually being a need. > /* > - * Write the the OpRegion offset to give the opregion > - * address to the device model. The device model will trap > - * and map the OpRegion at the give address. > + * To be compatible with this interface for programming the > + * the PCI_INTEL_OPREGION register, the device model must > + * check if the guest reads the register before it writes > + * to the register. To indicate to the device model that > + * we have support for an extended VBT, we read the > + * PCI_INTEL_OPREGION register before writing to it. If the > + * device model supports an extended VBT, it will return > + * the number of pages needed for the OpRegion + VBT. If > + * not, it will return 0 which indicates that it does not > + * implement this interface for supporting an extended VBT. > + */ This approach will need buyoff by qemu folks before it can be acked here. (Buyoff doesn't necessarily mean the change must have gone in there first, yet of course it would be best if things went in that order.) > + igd_opregion_e820_pages = pci_readl(vga_devfn, > + PCI_INTEL_OPREGION); > + if ( !igd_opregion_e820_pages ) > + { > + /* > + * This case provides backward compatibility with > + * device model versions that lack support for an > + * extended VBT. In this case the device model > + * expects us to allocate an extra page in case the > + * OpRegion is not aligned on a page boundary. Also, > + * in this case, the host OpRegion is direct mapped > + * into the guest. > + */ > + igd_opregion_pgbase = mem_hole_alloc(1); > + igd_opregion_e820_pages = IGD_OPREGION_PAGES + 1; > + opregion_is_direct_mapped = true; > + } > + else > + { > + /* Allocate extra pages for an extended VBT */ > + if ( igd_opregion_e820_pages > IGD_OPREGION_PAGES ) > + { > + igd_opregion_pgbase = > + mem_hole_alloc(igd_opregion_e820_pages - > + IGD_OPREGION_PAGES); > + } > + opregion_is_direct_mapped = false; > + } > + /* > + * This ensures the OpRegion + VBT does not take up more > + * than 1/32 of the reserved region. Also, we must reject > + * a value of 1 for igd_opregion_e820_pages. > + */ > + if ( igd_opregion_e820_pages > > + RESERVED_MEMORY_DYNAMIC_PAGES >> 5 || Parentheses please around the shift expression. The 1/32th also looks to be entirely arbitrary. If so, the comment also wants to state this fact. > + igd_opregion_e820_pages == 1 ) > + { > + printf("too many or too few pages (%u) for OpRegion\n", > + igd_opregion_e820_pages); > + BUG(); > + } Why does this entire if() not live in the "else" branch of the earlier if()? It's applicable only there afaict. > + /* > + * Write the the OpRegion offset to give the OpRegion Nit: As you move the comment, please also drop the stray extra "the". > + * address to the device model. The device model will trap > + * and make the OpRegion accessible at the given address. > + * The device model is also expected to verify that the > + * OpRegion is compatible with the guest address space and > + * patch it if necessary to make it compatible. > */ The last sentence of the comment is new, and I fear I don't understand what it is trying to describe. How can one "patch a region" to "make it compatible"? > pci_writel(vga_devfn, PCI_INTEL_OPREGION, > igd_opregion_pgbase << PAGE_SHIFT); > + > + /* Don't use our own copy if OpRegion is direct mapped */ > + if ( opregion_is_direct_mapped ) > + break; > + > + /* > + * Windows IGD drivers do not work properly when the > + * OpRegion is exposed by the device model's ioreq server, > + * so make a copy of the OpRegion and use that copy which > + * will be backed by RAM allocated to the guest. > + */ I'm struggling with this comment: What does "do not work properly" mean here? How the region is backed should be of no interest to the driver? > + opregion_vbt_scratch = > + scratch_alloc(igd_opregion_e820_pages << > + PAGE_SHIFT, 0); > + memcpy(opregion_vbt_scratch, > + (void *)(igd_opregion_pgbase << PAGE_SHIFT), > + igd_opregion_e820_pages << PAGE_SHIFT); > + > + igd_opregion = pci_readl(vga_devfn, PCI_INTEL_OPREGION); Aren't you reading back here what you wrote above? Why the read then? > + /* > + * The device model will unmap the OpRegion from the ioreq > + * server so we can use our own copy of the OpRegion. > + */ > + pci_writel(vga_devfn, PCI_INTEL_OPREGION, igd_opregion); Despite the comment this looks like black magic: You write back the value you read. That's hardly expected behavior, and hardly how real hardware would behave. I think the comment will need extending, and I think this is another behavioral aspect which needs buyoff by qemu folks. One further request: As you're already tidying things, would you mind also correcting the comment on PCI_INTEL_OPREGION's definition (which I think means "bytes" when it says "bits")? Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 23 08:04:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 08:04:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429814.1652457 (Exim 4.92) (envelope-from ) id 1x9Hxm-0007aU-Pa; Wed, 23 Sep 2026 08:04:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429814.1652457; Wed, 23 Sep 2026 08:04:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Hxm-0007aM-MW; Wed, 23 Sep 2026 08:04:22 +0000 Received: by outflank-mailman (input) for mailman id 1429814; Wed, 23 Sep 2026 08:04:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Hxk-0007aG-LI for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 08:04:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Hxj-0029f1-TA for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:04:19 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab38800-2eae-0a2a0a5409dd-0a2a4507c15a-28 for ; Wed, 23 Sep 2026 10:04:19 +0200 Received: from [74.125.230.99] (helo=mail-lr2-f35.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab38803-b4ea-0a2a45070019-4a7de663812a-3 for ; Wed, 23 Sep 2026 10:04:19 +0200 Received: by mail-lr2-f35.google.com with SMTP id 38308e7fff4ca-3a47f740839so5560281fa.2 for ; Wed, 23 Sep 2026 01:04:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790150659; cv=none; d=google.com; s=arc-20260327; b=VD5snWgQLThyOzsvFyIm0KJnX1dZogNkuziUIvv6Sj9cruMw4zKLxl9WBlmEYGQmyu jlhWbBc6EdwzqGWaD/uKbK5o0QWnZ9tKVtE+qVKv/tRuL5zaafRSKqd8lci4nXvPwT4+ 3M3qN78sw9ynyAa5BXi0DyGju0F3EezEIEZZFQNNzuMwvXR8FERsh4ihnfis7yWeuXmH mCVX5Yptlvh5VV2dbNpwoYAASPxFoeAjUswISEEfirceQ+v/1Dcmh0gAWHu4b+kGnm1d KiKkzgLxwQw2EqrxIqTBPqVwBZDk4l/Hif3H6xw2jqtuHII6MX9sYgwXEpoDKcH43bPk 947g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/sGE1cWKRddn9BumVRWlGmuOGXI1Suk6ksjIkhQj8eU=; fh=WIBsbU94tzJ4cDiE2U1nGSEGZUKQH+ugjEkhmxI8Bgo=; b=N6TLUse4cVGrk4NfeFU//BiAeKJZBS8WV0/RYexNEMEX/sY2pxDO4q0LSlbcBFPtYj louWgIYOzL+ZoIQw/jrhrmo4pAg3nsY6MUroCHZcNK3vFBOZHgQuaZdcgMLLA5kxNcew YUQxypKSHZ4XDcU3GJhrxO1wGR6UHK6FqPUvwCKgPeqB4zGGr9iZGCm2y4jAV5/4Cgcj qMR7nI3nMGAWi11uZWCr84weN2E51kOHqKo3GcPdRmuiYBowa4VsjqPRJ43ShqN3nq66 Pqq3PYQNuoJEInKDXo1vDnN2DpkdLgsNljIWzIe6D2oUf2bErCPFG8MRvy55oRXXFyXr s9yA==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790150659; x=1790755459; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=/sGE1cWKRddn9BumVRWlGmuOGXI1Suk6ksjIkhQj8eU=; b=aD4fcS99XIJJEeA1gEkVKc3v2mZqL3teuL139J/o/CtEdiHVeuLjddLtgYaoW/jrRl 33LisIdirbfVdf2FTilJLdP7g4PDHavUtFV8aZ+I9E91fMOmH/Z2QTrqPnPBs1uMHW83 Gs8tn2gmK7ziroUeCJnJPcSSr3oKg3ju2b0gpnfGBro/YX9WgRq/su9bZT1atbKylkw7 w9RyqKl2iU0pVBRkfpzqa4Es5rkUV6x9HYusZcc4puXGroi/NlnMUpZhdLczXfCaajB0 XStfpMjZCwJpkyNXFQHZT4QzlPX344dx0q6mFIwlZwCeRdHBDjy1bZUH6nnJZ3QwTpvg lTBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790150659; x=1790755459; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/sGE1cWKRddn9BumVRWlGmuOGXI1Suk6ksjIkhQj8eU=; b=Cia9XrrrID2mK5by/NDC1EALHUB//gpO8nbWuzOcJjhj/EGTwGnLWRiaoFyqbJtJBb 6N+MFEut12aB5Rr9wqOn6H7tHpzgw3eAwIVl9xvz97FSs2l/EpY8aIfv57RQJb8FSS2S MLWCInqnQEmUEA/QzNWRbDNDOE5cbWRK6U8DzEaYrVTwpI3i5nGStPf5AwbDi8KXXAwe kCqox17s+aFMcJd02f4Zozfyiddj+S8/j0kgKO4mNAzcCUJIF4Bq6hvZW2bxASqHcnp1 89vI8pF8MgIHJH1JU97iIUVahztdW56Ful5NQmVsJRDFGayyH3uTI3FqGHM+Or0HMN+k OvOg== X-Gm-Message-State: AFuF++nHQoqvz8GzVuKl/VbuOwvIAHNN4XBhqubKtdP3WpovqU6fMImm jMZBoBYsCMDB4uldEDf5TQEYBfaIO/i5NtjIaknq8KGyVTNVqQ1uKVRx30wtNDJRkwtcxwopK+5 R7b4AfIN6MD4rMeJgB2nj8oBRMaDql/c= X-Gm-Gg: AYBFou2sprlbZwPky6+jSaLXPUAPI1A3h6lbKOG9Wyjr1Fy2FW5ETXdQ3HeML36aZ70 9yAuPosYYt31omXxFXUI9BZR6WdEp1np19DWgotFkd/cdTHItIjrLJ2tQlBonV6sAwU3m7f8N85 LDr6q6ckyqk0Iojre6vyNSzgfkd3VJqlypTn6NJNERMupZdHFn9btxy8mnyjaIUz7XWMO87ozX9 gyiqBa6mYSKuCaiPLBpjXbrGSdtyVhPjgLk571op4cM/VUvSiZIU/C8rnbSRbbiQM9+nGTouilo TNpTTuQOiBfiQgPAah/FYiYnUxU+NZbttHjymPeck7jUaU2YJOxUNA== X-Received: by 2002:a2e:be90:0:b0:3a3:749e:319d with SMTP id 38308e7fff4ca-3a630649c2fmr3671191fa.17.1790150658338; Wed, 23 Sep 2026 01:04:18 -0700 (PDT) MIME-Version: 1.0 References: <13181424f9be3f5e31977fbd505209cd0508571b.1790102501.git.leonid_komarianskyi@epam.com> In-Reply-To: <13181424f9be3f5e31977fbd505209cd0508571b.1790102501.git.leonid_komarianskyi@epam.com> From: Mykola Kvach Date: Wed, 23 Sep 2026 11:04:07 +0300 X-Gm-Features: AcwNN1ULFoLO3WCAA7Hn7gboN_yxL5eiKc6W-Kgs4eI3OOrAoTmbVCHd-4ivzSo Message-ID: Subject: Re: [PATCH v2] xen/arm: gicv3: initialize eSPI unconditionally To: Leonid Komarianskyi Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Julien Grall Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1790150659-A70DDAE4-3485C89B/0/0 X-purgate-type: clean X-purgate-size: 3872 Hi Leonid, Thank you for the patch. On Tue, Sep 22, 2026 at 9:59=E2=80=AFPM Leonid Komarianskyi wrote: > > Since the firmware may initialize eSPIs before Xen, and without > CONFIG_GICV3_ESPI enabled, Xen would not reinitialize them properly > during boot. In such cases, once the GIC is re-enabled in Xen, > interrupts may be received that cannot be handled. > > To ensure proper operation on hardware with eSPI feature, even when the e= SPI > config is disabled, gicv3_dist_espi_common_init() should be invoked > regardless of whether CONFIG_GICV3_ESPI is enabled or not. This will not > affect hardware without eSPI support, as the function checks if the > hardware supports eSPIs by reading the GICD_TYPER.ESPI field (using > GICD_TYPER_ESPIS_NUM macro), which indicates whether the extended SPI > range is supported. If the hardware does not support eSPI, the function > will not perform any actions. > > There are no functional changes for setups where CONFIG_GICV3_ESPI=3Dy. > > Suggested-by: Julien Grall > Signed-off-by: Leonid Komarianskyi > Acked-by: Julien Grall > --- > Changes in v2: > - rebased on the current staging > - placed Suggested-by tag first to keep tags in chronological order > - added Acked-by from Julien Grall > > This is a follow-up patch related to the discussion: > https://lore.kernel.org/xen-devel/820704d0-4047-4f02-a058-01daba2765f1@xe= n.org/ > > Sending v2 with the requested changes, as I only now noticed > that this patch has not been merged yet. > --- > xen/arch/arm/gic-v3.c | 32 ++++++++++++++------------ > xen/arch/arm/include/asm/gic_v3_defs.h | 2 -- > 2 files changed, 17 insertions(+), 17 deletions(-) > > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > index acdac22953..463769d77b 100644 > --- a/xen/arch/arm/gic-v3.c > +++ b/xen/arch/arm/gic-v3.c > @@ -703,17 +703,32 @@ unsigned int gic_number_espis(void) > return gic_hw_ops->info->nr_espi; > } > > +static void __init gicv3_dist_espi_init_aff(uint64_t affinity) > +{ > + unsigned int i; > + > + for ( i =3D 0; i < gicv3_info.nr_espi; i++ ) > + writeq_relaxed_non_atomic(affinity, GICD + GICD_IROUTERnE + i * = 8); > +} > +#else > + > +static void __init gicv3_dist_espi_init_aff(uint64_t affinity) { } > +#endif > + > static void __init gicv3_dist_espi_common_init(uint32_t type) I think the ordering in gicv3_dist_espi_common_init() needs to be revisited now that this function is also called with CONFIG_GICV3_ESPI=3Dn. The motivation for this patch is that firmware may have left an eSPI enabled. However, we currently program GICD_ICFGRnE before clearing the corresponding enable bit in GICD_ICENABLERnE. The GIC architecture requires an interrupt to be individually disabled before changing Int_config; otherwise the behavior is UNPREDICTABLE. See Arm IHI 0069H.b, section 12.9.9 (GICD_ICFGR). We also rely on the same requirement in gic_set_irq_type(). So shouldn't we disable/deactivate all eSPIs before programming GICD_ICFGRnE? Linux also initializes the extended SPI range in this order: ICENABLERnE/ICACTIVERnE first, followed by IGROUPRnE, ICFGRnE and IPRIORITYRnE. This issue already seems to exist for the CONFIG_GICV3_ESPI=3Dy path, but this patch makes it relevant to the newly added CONFIG=3Dn path, where an eSPI left enabled by firmware is precisely the case we are trying to handle. Also, we could disable/deactivate eSPIs for all builds, while keeping the rest of the eSPI configuration under CONFIG_GICV3_ESPI. This would avoid accessing the other eSPI registers in builds without eSPI support, unless there is a particular reason to initialize them there. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 23 08:06:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 08:06:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429823.1652466 (Exim 4.92) (envelope-from ) id 1x9I00-0008At-8O; Wed, 23 Sep 2026 08:06:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429823.1652466; Wed, 23 Sep 2026 08:06:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9I00-0008Am-5S; Wed, 23 Sep 2026 08:06:40 +0000 Received: by outflank-mailman (input) for mailman id 1429823; Wed, 23 Sep 2026 08:06:39 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Hzy-0008Ag-Ux for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 08:06:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Hzy-00AODV-8M for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:06:38 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3888c-2eae-0a2a0a5409dd-0a2a4505d1aa-2 for ; Wed, 23 Sep 2026 10:06:38 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3888e-4cb1-0a2a45050019-4a7de18cc2d6-3 for ; Wed, 23 Sep 2026 10:06:38 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49d1fb0cf5eso4025125e9.3 for ; Wed, 23 Sep 2026 01:06:38 -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-49fde1d978fsm52219145e9.9.2026.09.23.01.06.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 01: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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790150797; x=1790755597; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=CrJEYYJqlVu0pUh1RC8wmI4eHQPgvuN+x450Z//bKIQ=; b=gCQEdHJbnYMM+M9KKUfh29wOfAIpasm5wrAcHPplkHMre4Vzh+1FLUALGsKl/TR2Ng Muz/perpZYW8YPs4yF+QoTRQv+6oMJ5/YY0Hu2LhyVxTJ/dfffZXcmjuIf7eyXlFyIDW +4WZFVdM4zBNvQd8auQgFafcoNpdbVNqFgjVyCMmphX0Hi2KvuSBzpVw79dPwIjx+Zwn hRVYxAQQA8cQsQZAd7j47Jylx+CsKFoF1pZEMziU7BDSAJaL4YpKpCESynO/wi7XIPQk /9S+REfeDUQRP0x1aeZRQFefqPYO34MeKyQZkK2AfMQVpoEzgynLNesQvPcJoqzMtD6/ cjaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790150797; x=1790755597; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=CrJEYYJqlVu0pUh1RC8wmI4eHQPgvuN+x450Z//bKIQ=; b=GyzhAfEuvNy4Ij5uOTEurALVt5cvO+N3jw6hNV7y9BifIJC8Wq+Z2KNYW9ffxG2f3p 8MKuH1Hn7f72If3gdTjszPn6VjBEx58OThydM/n0BiI+IHKk1RcjDweY7e/JFPKcna7N Nlqfg33bdmyPDensMaQ28zJaXgSf9XaWyYIbv8gKQNHv+NAkXGYFuajn3lRYG9p/FRxD 3asp4GWLHF6KfpjHYbMvS6TFVSrYxNth6kJI3PpN7q9/OGGWDMNVImStz9vwNDPfs03r k9Fa05lYKvhIQAPBzsiwG6L5yIZm31pAbfQyDOUe8Apiz+tixBj/f2Paah/4rcYnFCEL QAsQ== X-Gm-Message-State: AFuF++nSXKnJotBE8oONP3ZhO1jtN0TfkTG3NV0u9cS067pAHUR3/H2r WaiKiyASV4J+Yz4FQJ4xlIMAsCLTlPY7IMKv/cRbiyGSf4UxSvpQiZjrUSMOqks/eHD9BMvXzfI yTUiWEg== X-Gm-Gg: AYBFou3tOjREICXb2V+bs4ylFnq+ldDauMhcNyF4g9mk2KoMdKCQORA8XHEVBU/nCZS L2aXQlzfY4asB+XyQPd3Uy9dKVhgJiIAmgYDXA8ZEAkkCV4ymIMXTXJYeGhzhcVs3vxNa1Zm3wK +fQoVRCDNUdDxAE6ee9DV3mGvx5Bmr4lMkIZK6khNmXIiYV82eYr8glxHOF3zzUYdsAUFdoZMvI 6gHdV3yC3S4DB3ECtphxrfy5zrzdwc5lLZY9qnz7xiCMdrouT0dbLViC4pC7IV20M7lIzgPeBKT KyDnpcg6UfFU2xu/PTTnCUQyoJbOVAaMMVXMg+LYb/xQw7jZUEHPs62f3Uf4Is3uy8eqrn6raD7 PO00ZMqLNDIw4Q0D8xu4m5mqdqOXSBmzq6vVyrqtCqU+zp8xI9WWEFbLdkHYhmyB36G52FhjBtt tVr7lhNNr9OnrxfVYV8bA6O7v9uezIO8WNQT2d+W9Qe3za1PYJI2q39b+3fISMpq/JgjM9F0uXa 4/wM9tAiOJ6srjuRJmNOXz34uTzjsGz6K3Cb8HqVeC6FDeoYED88MX+EuDuOQ== X-Received: by 2002:a05:600c:4fc2:b0:49f:bd3c:bc23 with SMTP id 5b1f17b1804b1-49fdf25367dmr20775055e9.30.1790150797498; Wed, 23 Sep 2026 01:06:37 -0700 (PDT) Message-ID: <9a4c03fc-3312-4e0c-94ba-28c67f4f2e64@suse.com> Date: Wed, 23 Sep 2026 10:06:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/14] x86/mm: get_page_from_l1e() is PV-or-shadow-only From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Daniel Smith , Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4f7a34b6-b522-4d8f-a678-304ef4c0f916@suse.com> Content-Language: en-US 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: <4f7a34b6-b522-4d8f-a678-304ef4c0f916@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790150798-F74BC2A1-1637B535/0/0 X-purgate-type: clean X-purgate-size: 536 On 17.08.2026 10:52, Jan Beulich wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -836,6 +836,8 @@ static int cf_check print_mmio_emul_rang > } > #endif > > +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING) > + > /* > * get_page_from_l1e returns: > * 0 => success (page not present also counts as such) As (only) eclair-x86_64-amd points out, this #if needs to move up ahead of print_mmio_emul_range(). (Of course sooner or later a randconfig job would also have spotted this.) Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 23 08:26:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 08:26:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429853.1652477 (Exim 4.92) (envelope-from ) id 1x9IIi-0002zr-Pn; Wed, 23 Sep 2026 08:26:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429853.1652477; Wed, 23 Sep 2026 08:26:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9IIi-0002zk-LB; Wed, 23 Sep 2026 08:26:00 +0000 Received: by outflank-mailman (input) for mailman id 1429853; Wed, 23 Sep 2026 08:25:59 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9IIg-0002ze-NL for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 08:25:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9IIf-006wcE-Jc for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:25:57 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab38d11-8faa-0a2a0a5109dd-0a2a450ab516-6 for ; Wed, 23 Sep 2026 10:25:57 +0200 Received: from [40.107.162.123] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab38d13-f2d2-0a2a450a0019-286ba27b12f5-3 for ; Wed, 23 Sep 2026 10:25:55 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by PAWPR03MB10166.eurprd03.prod.outlook.com (2603:10a6:102:34e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 08:25:50 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 08:25:50 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rt1Pm4EmedmFf45vauMBkaTtjFRg1wN6YHJaE8eGMeD60MK65qwPcVYnD7djfeWq6vXcrN0OIg8DNvkQHsQ+rsPQCV8lZ3vZzGhGxUJnQilo+oUNHipS/nmTQPENe/xQRv5+eabj37VKREQcV4K8BmmPFtRjd1fjCgnwLtxPs13vibVIcRnnh9SSm9NzDcvOJyOxIpUvoJ6ywDp3Jvwk9E3Cnpa5eK/6j6T0vrvsEWafwwYEWZovSKiOncNl6NG5QVKpK7z6+MKMyB3BcrFQtDJNOV/FF8ERk3w7aRPnzdhVRoisU/oyC9PAIUzwuZk/5GAEQnW0OWl/JFr6MUH2hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kEqya5dJyB0IofAnrQLJ/QtnyM3vtJmweVjaxm1we7E=; b=mDUY9cQGR5p1uNjJxB0hNL8RY9xSpQBjxlUdUjuYrQnNAuXUOB43sSOTsg+AK7GbcJ69ko3UsIW+4RRCaDlzvpFyGqa/0y7jOWXEOKpp/Eb/F5XlRK6Mr8sNFZgSWFbWT3d+Dw02HF39L/4RkcZYAVYOBjpXKNx97BgcE25BPLB+xzInflsr/IRmV4mNe9V5n05jwBm/o+2hl5F0x3R2RU4o6v7yDMBuNQLb3VPxcTzKbFKR69tbsZtGlf4ZehWOGtO6KmySGJvujc34Kd8symllijjAh1C6tEBzoKSjhOJ6jEcbDtI+smZFVyzu3aYlfT/FNnOdbnXaYQfaoTmYMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kEqya5dJyB0IofAnrQLJ/QtnyM3vtJmweVjaxm1we7E=; b=jP5R5KmJw+jIcyrR8YoMyXWjtZEeJEe3+tNXkDYsGE6V5TibR8VSsyMpmjGNrK/m8dSWM7UhgU3kXN8ihJV0LWT7KjeTclgX7xlT7Pl3qP5+BWXOyx2p8+7MM0AOHU+xT2EmeF4gYK/OiPol1bk9aVA4DxE6mxHTIELBy8oBbjW5lj4/gVItPlw5I+UITtb1gIe6qSgUKpGZ0/OinG78R1Eo3kYKDZ/u7igTvCAYWz3jcVuCxtv+RsF66rWEszK0MRaG0BSqkLfO/neQ+/cYzX/4ht26WVz+LWAxWPf0j262isKSaxFAzgrI/gNfMvHrREQJT9EDYY7xN+01HUf/lA== From: Oleksii Moisieiev To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Grygorii Strashko Subject: Re: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdSqBOtjSUOlH6/km+/eJYUhrZf7bb1QQA Date: Wed, 23 Sep 2026 08:25:50 +0000 Message-ID: <63f4841c-fb36-40c4-b96e-4a1aed95fbda@epam.com> References: <5c3ae163d21f619bf25c8757232a1a0867c3eb87.1790087968.git.oleksii_moisieiev@epam.com> <87pky43hm2.fsf@epam.com> In-Reply-To: <87pky43hm2.fsf@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|PAWPR03MB10166:EE_ x-ms-office365-filtering-correlation-id: de444122-b8f6-432a-0580-08df194c467f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|7416014|38070700021|3023799007|4133799003|6133799003|10067099003|56012099006|22082099003|18002099003|4143699003|11063799006; x-microsoft-antispam-message-info: 3FghmNst43xInJCSuQySm6OYAwzRIwcrQk4G5IW6iccxWRamicK8VvW6y4BxowudC2TC3s73uFotPCu2lsdSOvyDsK1+jPatW+Ry+DLl9RzSelROZ0Q8SjM4k1/u9PLyTqdwA55DT/NnTI8MHcTDUdYqVY0V6+RTZ7/Ornu49RN+20SI+H+RmnWVY6LjSkDWQuKEsillxREwic68I6T+FFy4buLD3sDx3k1MKjvT+hyd7kItcCX+g8ZQhDX6VImsnc5IElJZBZ52eq0dt77FfLjPkQ0+iOTRfNsqt+kGhdNAyGTbrMvt/gMs/spislOEjUBrpXsskfXV5bL7SJjlvdMHTc3mDM9uoxfy+nYgWP0I5rC0d6zfeonKKjqwg+nHrk39al6V1y6sive7hrqyevU59bLcV4duawX2PhGQ18IabKB6wwf4Y8WLw1fN75t5FlMj2mg8V2c4wyA2JurGnOPpgBGwj7s2++YdGapec+6pmlgOhN6W1Yrpp6EKkdhwr9JtQi6nHsxrDC+i+5g5S5RDfSaM+kMNWSibEgudNRKtqsRATAh6mYNvKnOihiUtzSj8GY/MJPOa8KVGzLPG5XLh0pMHtafz2TVKNgVJn16UKXFJ7TkJbFZ70FIfOHWpwoZ47ctlphOaqRMW34c+Ag4Gzgr3+Y2UKgE8BtN1uX3VDoONYW/GNlDPuMbjo6yo x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(7416014)(38070700021)(3023799007)(4133799003)(6133799003)(10067099003)(56012099006)(22082099003)(18002099003)(4143699003)(11063799006);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?R3k3KzBqVlc1Z1ZOYm5tQjl2dW12WTZIczcyZTF4cUEzRVBZUGtIQWZ3Z1Zp?= =?utf-8?B?N00rd0l6cmZuM0g4d3ErcWFDRGVtQU1mTFl1TUJBM3NYU1FIOGRqNlRBVkJx?= =?utf-8?B?Qm41ekszZXI4OU52cHFMRTJqelFPSEdZM0FXZThpd0xpVWp5VSsxRjZycUpU?= =?utf-8?B?L054UElMVHBEaVFNU3FIOEtQd1pYZ3pPc3VBSHV0SlVOdlNxUzF0VHYvOWhl?= =?utf-8?B?VXpQZ1VLZkNnZHVEL3BxSWlpTUt1b0tRR1AvOVBsWURkNGlGcDgwQWlSejQw?= =?utf-8?B?Vjh4TkZoZzJKMmhuRFJ4dG1WRnBpWURTK3l1ekNDSDR3UjRmQ2NTR1N4WEdN?= =?utf-8?B?RlUxVHFjQUJRWkRmN1JQQnhNU3lUSjUzMVR2UzFYcTMreG4wZXRKVWR6ZGMv?= =?utf-8?B?SEhaMWI3Y2N5SlZURjRsemxZc2dmeGEvRERTcFNkdndQS2hGOE1rM3V4TzN5?= =?utf-8?B?WWR0aGVHNGpZN1JQS2c5ZzRyUXN1dnZCTkNKeld0VHdXWklUZkJDWGx4aksr?= =?utf-8?B?QTRTUDRPTysyL0VZUUFVVmpSZ3hiT1JLMGhrdzZ2SDV5aUJzbDVBVjlQVHVZ?= =?utf-8?B?T0lJa2R3OFlXdlRKcEc2UmZtaHpxMTBoOTA3TWVQOUc1aXJ3MUQwVjJ0QXJG?= =?utf-8?B?eW5wcXl5WVhBeVdkUlRCMDVsRW9hbkE4em9lZEg3UVVmYU1lSGRsVUIvTHlP?= =?utf-8?B?VW9UZHNld2FCZVhnOXpWV2k1c2hzcWJ4VVR2Zk9kL2NWL0I1Y2JwZXI3blRj?= =?utf-8?B?YkppNFRtRFJCUCtENUhmSXdtV2M5THFwd2NmbDhITVhRVFo2VW9nMUI5MTVR?= =?utf-8?B?OGprRERkaVNhRlBIVWxDdFVwM25WRnpLSDBPWUNURFViNU1vWFpSTFIraFFh?= =?utf-8?B?K0YyWk9rQXl1QThKeG5wM1YrUGxPaEJmUzBReEcxdE5kckV6Qm1KTmFzYmd4?= =?utf-8?B?dXJOWGFaT2o2K0RpTnRlUm1jd3M5cEtKUzB1dEo4dFFDNnBrVENDTUQ1Mkwv?= =?utf-8?B?aGlqM0x1U2JTSHZSZURxZG54eDd1aHVGbXpMa1FxVlI4YkNROVN4SHI3d2NG?= =?utf-8?B?MHI3Rmo2aFdJVHMvZG9lYkdZeHNZYnhRVW1kYmYycWs5THI4ZnJVNDlUMkda?= =?utf-8?B?dGVCRWRzNStGemVuL3BEUFcxbEhqRjVsamVTcnBlTk83Q1FQVG1FZGNJWkpB?= =?utf-8?B?THl3M3JaeE9lc3dYYUFvdXJFRlBSR08vbTI0RnNkNG1PZFR0cnVVbmJoc1l6?= =?utf-8?B?ZjRnZE40L3YvME10MmZ0RytrV0FpUFdrWEZFTnYwQU5tdVpPV2ZKK2NPOEdx?= =?utf-8?B?L2c3aXJMQi9jeWZ5VmJMMk1ybkpReG1YalVvTVJvOEJybEVlSzlmQmYwRU9I?= =?utf-8?B?ZUx5UnZid1o4VWV5MWxsSDc4VENsaUZaVVdEVVF0SGFRTkJyM0lOa0VYYmk1?= =?utf-8?B?dlBNTUxpTGUyYnRDVTNodnZMOVgyM05YaU1RK0M1SWE5bXVSNU1SYzlrSVNC?= =?utf-8?B?azg1TUR1elZhK2xJZHNWMUZ1L0VPbGptUDE0MWZxcmMwaDQ3UitrZVlzRXNB?= =?utf-8?B?STdzWU9selBTQTl4dm9KTzk1VkYxa0RVVG9jN0N4OWRXV09ESDVudk1ZNlR0?= =?utf-8?B?VWwyd0lyelc4RzZQMmU0WlpxNisrc3pDbFJPRkwvc0tNeTRSdFFRSDlTdnF1?= =?utf-8?B?VHllU3grdlJRUFhSZGwxVStWOG1JbEFuSzdOR3dHMTluVXRnc3lwK1UwaUp6?= =?utf-8?B?dWN4WUppSTQxck5FOUkwTFpNczYvc000aG1OVkRXYkhkNnZVSktBbkFLa1ZK?= =?utf-8?B?MVlzRGZkMzhRTnFHSXRIRnB5NnVldTVqUXFwdlRsMzEvak5HQ1hOU0taV21i?= =?utf-8?B?NDREZ0pidlZIcEJRQ0p4YU16TnVYZzRCNHYwbm81clVqczNTYTRuckJ2MVBK?= =?utf-8?B?SjNPeGtSWmZwWElSTmVmUVZLRFVpbjNoajlzOXRYV2g0bVhsaGU5ZXRzSE1i?= =?utf-8?B?RkZHQlQvUkgxakFTTVA4N1A2cy82ZFQ1aWZBUlZPS25VclBTS1c1SXhkcTR4?= =?utf-8?B?dFdDdDRFeWlxT3N2RWJaanpxUk1iMy9GcHArMU0rT0Vaam8ycUpqVElYTFBr?= =?utf-8?B?TjB0elozQTR2a1dreDdRRDE3R1dzcTFWaWZKd2ZkUGdXMHROcGJQaVNybEp2?= =?utf-8?B?UEp6NzVIQ3BqN20xVG9NSTlqVnFTRjh5RzFoS3VWejlYQ05oTDlwSC9WV05H?= =?utf-8?B?RGlxT0xieFpJTEFtWWFMQWtnQ2xRdWw4MEJRYlVVUk0vQVp3OVlzck52TTRz?= =?utf-8?B?WEllZEQ2dW5hdGFWVlBHMElFZ0tkcFRkYmJVbFUvNVowM1phZnlqREk1cFRU?= =?utf-8?Q?ml3xv6KXFdpNb/NE=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <6F0CD68C7CA7254A9E27FFD08392F228@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: de444122-b8f6-432a-0580-08df194c467f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2026 08:25:50.0465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MML/qYgdJnBDtkpcwfjS1YV4hDYgblor0q6IvixAF6zPPIOsL/wv+oEcrcm71bKfj873rBkhvoOgWZ2ePYFcA2c6VkicD/y63Ki+3BaivRU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB10166 X-purgate-ID: tlsNG-4011c0/1790151955-4BAD4F5C-2A8D656C/0/0 X-purgate-type: clean X-purgate-size: 111138 DQpPbiAyMy8wOS8yMDI2IDA0OjAyLCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4gSGkgT2xl a3NpaSwNCj4NCj4gT2xla3NpaSBNb2lzaWVpZXYgPE9sZWtzaWlfTW9pc2llaWV2QGVwYW0uY29t PiB3cml0ZXM6DQo+DQo+IFRoaXMgaXMgYSBncmVhdCBwaWVjZSBvZiBkb2N1bWVudGF0aW9uLiBJ dCBpcyBsYXJnZXIgdGhhbiB0aGUgdGV4dCB5b3UNCj4gYWRkZWQgdG8gdGhlICdkb2MnIGRpcmVj dG9yeS4gU28gSSBiZWxpZXZlIGl0IGlzIGJldHRlciB0byBwdXQgaW50byBhDQo+IGRlc2lnbiBk b2N1bWVudCwgc28gaXQgaXMgd2lsbCBub3QgYmUgbG9zdCBpbiB0aGUgZ2l0IGNvbW1pdCBtZXNz YWdlcy4NCg0KSGkgVm9sb2R5bXlyLA0KDQpUaGFuayB5b3UgZm9yIGEgcXVpY2sgcmVzcG9uc2Uu DQoNCkkndmUganVzdCByZWNoZWtlZCBkb2N1bWVudCBpbiBwYXRjaCA2Og0KZG9jcy9oeXBlcnZp c29yLWd1aWRlL2FybS9maXJtd2FyZS9hcm0tc2NtaS5yc3QgYW5kDQoNCmNvbXBhcmVkIGl0IHdp dGggdGhlIGluZm9ybWF0aW9uIHByb3ZpZGVkIGluIHRoZSBjb21taXQgZGVzY3JpcHRpb24uDQoN CkFzIEkgY2FuIHNlZSBhbGwgaW5mb3JtYXRpb24gcHJvdmlkZWQgaW4gdGhlIGRlc2NyaXB0aW9u IChhZGQgc2NoZW1lcw0KYW5kIGR0cyBleGFtcGxlcyBhdCBsZWFzdCkNCg0KYXJlIHByZXNlbnQg aW4gdGhlIGRvY3VtZW50YXRpb24uIEFsc28gZG9jIGl0c2VsZiBpcyBtb3JlIGRldGFpbGVkIHRo ZW4NCnRoZSBjb21taXQgZGVzY3JpcHRpb24uDQoNCk1heWJlIEkgbWlzc2VkIHNvbWV0aGluZz8N Cg0KPj4gVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIFNDSSBkcml2ZXIgdG8gc3VwcG9ydCBmb3IgQVJN IEVMMyBUcnVzdGVkIEZpcm13YXJlLUENCj4+IChURi1BKSB3aGljaCBwcm92aWRlcyBTQ01JIGlu dGVyZmFjZSB3aXRoIG11bHRpLWFnZW50IHN1cHBvcnQsIGFzIHNob3duDQo+PiBiZWxvdy4NCj4+ DQo+PiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICB8IEVM MyBURi1BIFNDTUkgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICArLS0tLS0tLSst LSstLS0tLS0tKy0tKy0tLS0tLS0rLS0rLS0tLS0tLSsrDQo+PiAgICB8c2htZW0xIHwgIHxzaG1l bTAgfCAgfHNobWVtMiB8ICB8c2htZW1YIHwNCj4+ICAgICstLS0tLSstKyAgKy0tLSstLS0rICAr LS0rLS0tLSsgICstLS0rLS0tKw0KPj4gc21jLWlkMSB8ICAgICAgICB8ICAgICAgICAgfCAgICAg ICAgICAgfA0KPj4gYWdlbnQxICB8ICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4g ICAgKy0tLS0tdi0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKw0KPj4gICAgfCAg ICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4gICAgfCAgICAgICAg ICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4gICAgKy0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKw0KPj4gICAgICAgICAgIHNtYy1pZDAgfCAgc21j LWlkMnwgICAgc21jLWlkWHwNCj4+ICAgICAgICAgICBhZ2VudDAgIHwgIGFnZW50MiB8ICAgIGFn ZW50WCB8DQo+PiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4g ICAgICAgICAgICAgICstLS0tdi0tLSsgICstLXYtLS0tLSsgICstLXYtLS0tLSsNCj4+ICAgICAg ICAgICAgICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+PiAgICAgICAgICAg ICAgfCBEb20wICAgfCAgfCBEb20xICAgfCAgfCBEb21YICAgfA0KPj4gICAgICAgICAgICAgIHwg ICAgICAgIHwgIHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+ICAgICAgICAgICAgICB8ICAgICAg ICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+PiAgICAgICAgICAgICAgKy0tLS0tLS0tKyAg Ky0tLS0tLS0tKyAgKy0tLS0tLS0tKw0KPj4NCj4+IFRoZSBFTDMgU0NNSSBtdWx0aS1hZ2VudCBm aXJtd2FyZSBpcyBleHBlY3RlZCB0byBwcm92aWRlIFNDTUkgU01DIHNoYXJlZA0KPj4gbWVtb3J5 IHRyYW5zcG9ydCBmb3IgZXZlcnkgQWdlbnQgaW4gdGhlIHN5c3RlbS4NCj4+DQo+PiBUaGUgU0NN SSBBZ2VudCB0cmFuc3BvcnQgY2hhbm5lbCBkZWZpbmVkIGJ5IHBhaXI6DQo+PiAgIC0gc21jLWlk OiBTTUMgaWQgdXNlZCBmb3IgRG9vcmJlbGwNCj4+ICAgLSBzaG1lbTogc2hhcmVkIG1lbW9yeSBm b3IgbWVzc2FnZXMgdHJhbnNmZXIsIFhlbiBwYWdlDQo+PiAgIGFsaWduZWQuIFNoYXJlZCBtZW1v cnkgaXMgbWFwcGVkIHdpdGggdGhlIGZvbGxvd2luZyBmbGFnczoNCj4+ICAgTVRfREVWSUNFX25H blJFLg0KPj4NCj4+IFRoZSBmb2xsd29pbmcgU0NNSSBBZ2VudHMgYXJlIGV4cGVjdGVkIHRvIGJl IGRlZmluZWQgYnkgU0NNSSBGVyB0byBlbmFibGUgU0NNSQ0KPj4gbXVsdGktYWdlbnQgZnVuY3Rp b25hbGl0eSB1bmRlciBYZW46DQo+PiAtIFhlbiBtYW5hZ2VtZW50IGFnZW50OiB0cnVzdGVkIGFn ZW50cyB0aGF0IGFjY2Vzc2VzIHRvIHRoZSBCYXNlIFByb3RvY29sDQo+PiBjb21tYW5kcyB0byBj b25maWd1cmUgYWdlbnQgc3BlY2lmaWMgcGVybWlzc2lvbnMNCj4+IC0gT1NQTSBWTSBhZ2VudHM6 IG5vbi10cnVzdGVkIGFnZW50LCBvbmUgZm9yIGVhY2ggR3Vlc3QgZG9tYWluIHdoaWNoIGlzDQo+ PiAgICBhbGxvd2VkIGRpcmVjdCBIVyBhY2Nlc3MuIEF0IGxlYXN0IG9uZSBPU1BNIFZNIGFnZW50 IGhhcyB0byBiZSBwcm92aWRlZA0KPj4gICAgYnkgRlcgaWYgSFcgaXMgaGFuZGxlZCBvbmx5IGJ5 IERvbTAgb3IgRHJpdmVyIERvbWFpbi4NCj4+DQo+PiBUaGUgRUwzIFNDTUkgRlcgaXMgZXhwZWN0 ZWQgdG8gaW1wbGVtZW50IGZvbGxvd2luZyBCYXNlIHByb3RvY29sIG1lc3NhZ2VzOg0KPj4gLSBC QVNFX0RJU0NPVkVSX0FHRU5UIChvcHRpb25hbCBpZiBhZ2VudF9pZCB3YXMgcHJvdmlkZWQpDQo+ PiAtIEJBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTiAob3B0aW9uYWwpDQo+PiAtIEJBU0Vf U0VUX0RFVklDRV9QRVJNSVNTSU9OUyAob3B0aW9uYWwpDQo+Pg0KPj4gVGhlIFNDSSBTQ01JIFNN QyBtdWx0aS1hZ2VudCBkcml2ZXIgaW1wbGVtZW50cyBmb2xsb3dpbmcNCj4+IGZ1bmN0aW9uYWxp dHk6DQo+PiAtIFRoZSBkcml2ZXIgaXMgaW5pdGlhbGl6ZWQgZnJvbSB0aGUgWGVuIFNDTUkgY29u dGFpbmVyIGBgeGVuX3NjbWlfY29uZmlnYGANCj4+ICAgIChjb21wYXRpYmxlIGBgeGVuLHNjaWBg KSBwbGFjZWQgdW5kZXIgYGAvY2hvc2VuL3hlbmBgLiBPbmx5IHRoZQ0KPj4gICAgYGBhcm0sc2Nt aS1zbWNgYCBub2RlIHRoYXQgaXMgYSBjaGlsZCBvZiB0aGlzIGNvbnRhaW5lciB3aWxsIGJpbmQg dG8gWGVuOw0KPj4gICAgb3RoZXIgU0NNSSBub2RlcyAoZm9yIGV4YW1wbGUgdW5kZXIgYGAvZmly bXdhcmVgYCkgYXJlIGlnbm9yZWQgdG8gYXZvaWQNCj4+ICAgIHN0ZWFsaW5nIHRoZSBob3N0IE9T UE0gaW5zdGFuY2UuDQo+Pg0KPj4gc2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+PiAgICAg ICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gICAgICAgICAgICByZWcg PSA8MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+PiB9Ow0KPj4gc2NtaV94ZW46IHNjbWkg ew0KPj4gICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4gICAgICAgICAg YXJtLHNtYy1pZCA9IDwweDgyMDAwMDAzPjsgPC0tLSBYZW4gbWFuYWdlbWVudCBhZ2VudCBzbWMt aWQNCj4+ICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPCAxPjsNCj4+ICAgICAgICAgICNzaXpl LWNlbGxzID0gPCAwPjsNCj4+ICAgICAgICAgICNhY2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwg MT47DQo+PiAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMT47IDwtLS0gWGVuIG1hbmFnZW1l bnQgYWdlbnQgc2htZW0NCj4+IH07DQo+Pg0KPj4gLSBUaGUgZHJpdmVyIG9idGFpbnMgWGVuIHNw ZWNpZmljIFNDTUkgQWdlbnQncyBjb25maWd1cmF0aW9uIGZyb20gdGhlDQo+PiAgICBIb3N0IERU LCBwcm9iZXMgQWdlbnRzIGFuZCBidWlsZHMgU0NNSSBBZ2VudHMgbGlzdC4gVGhlIEFnZW50cw0K Pj4gICAgY29uZmlndXJhdGlvbiBpcyB0YWtlbiBmcm9tICJzY21pLXNlY29uZGFyeS1hZ2VudHMi IHByb3BlcnR5IHdoZXJlDQo+PiAgICBmaXJzdCBpdGVtIGlzICJhcm0sc21jLWlkIiwgc2Vjb25k IC0gImFybSxzY21pLXNobWVtIiBwaGFuZGxlIGFuZA0KPj4gICAgdGhpcmQgaXMgb3B0aW9uYWwg ImFnZW50X2lkIjoNCj4+DQo+PiAvIHsNCj4+ICAgIGNob3NlbiB7DQo+PiAgICAgIHhlbiB7DQo+ PiAgICAgICAgcmFuZ2VzOw0KPj4gICAgICAgIHhlbl9zY21pX2NvbmZpZyB7DQo+PiAgICAgICAg ICBjb21wYXRpYmxlID0gInhlbixzY2kiOw0KPj4gICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8 Mj47DQo+PiAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwyPjsNCj4+ICAgICAgICAgIHJhbmdlczsN Cj4+DQo+PiAgICAgIHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCj4+ICAgICAgICAgICAgMHg4 MjAwMDAwMiAmc2NtaV9zaG1fMCAwDQo+PiAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2ht XzIgMg0KPj4gICAgICAgICAgICAweDgyMDAwMDA1ICZzY21pX3NobV8zIDM+OyA8LS0tIGZ1bmNf aWQsIHNobWVtLCBhZ2VudF9pZA0KPj4gICAgICAgICAgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1j ZWxscyA9IDwzPjsNCj4gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgdGhlIGNvcnJlY3Qgd2F5 IG9mIHVzaW5nIC1jZWxscyBwcm9wZXJ0eS4NCj4NCj4gVGhlc2UgcHJvcGVydGllcyBhcmUgdXNl ZCBlaXRoZXIgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBmb3IgKipjaGlsZCoqIG5vZGVzDQo+IChs aWtlICNhZGRyZXNzLWNlbGxzIG9yICNzaXplLWNlbGxzKSBvciB0byBwcm92aWRlIGEgbnVtYmVy IG9mIGNlbGxzIHRvDQo+IGVuY29kZSBhIHNwZWNpZmllciBmb3IgYSBkb21haW4gKGxpa2UgI2lu dGVycnVwdC1jZWxscykuDQo+DQo+IEhlcmUgeW91IGFyZSBkb2luZyBuZWl0aGVyIG9mIHRoZXNl LiBJIHRoaW5rIHRoZSBwcm9wZXIgd2F5IGlzIHRvIGRlZmluZQ0KPiBzZWNvbmRhcnkgYWdlbnRz IGFzIGNoaWxkcmVuOg0KPg0KPiBhZ2VudHMgew0KPiAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9 IDE7DQo+ICAgICAgICAgICNzaXplLWNlbGxzID0gMDsNCj4gICAgICAgICAgIHNjbWlfYWdlbnRf Mjogc2NtaV9hZ2VudEAyIHsNCj4gICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1h Z2VudCI7ICAvLyBBY3R1YWxseSwgSSBhbSBub3Qgc3VyZSBpZg0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIHdlIGFsbG93ZWQgdG8gdXNlICdhcm0nIG5h bWVzcGFjZQ0KPg0KPiAgICAgICAgICAgICByZWcgPSA8Mj47ICAgICAgICAgICAgICAgICAgICAg IC8vIEFnZW50IGlkIGdvZXMgaGVyZQ0KPiAgICAgICAgICAgICBzaG1tZW0gPSAmc2NtaV9zaG1f MjsNCj4gICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDB4ODIwMDAwMDQ7DQo+ICAgICAgICAgICB9 Ow0KPiB9DQo+DQo+IFdpdGggdGhpcyBhcHByb2FjaCB5b3UgZG9uJ3QgbmVlZCAjc2NtaS1zZWNv bmRhcnktYWdlbnRzLWNlbGxzIGF0IGFsbA0KPiBhbmQgdGhlIHdob2xlIHN0cnVjdHVyZSBiZWNv bWVzIG1vcmUgZGV2aWNlLXRyZWUtaXNoLg0KVGhhbmsgeW91IGZvciBsb29raW5nIGF0IHRoaXMu IEkgYWdyZWUgdGhhdCB0aGUgdHdvIGNhc2VzIHlvdSBsaXN0IGFyZQ0KdGhlIG1vc3QgY29tbW9u IG9uZXMsIGJ1dCB0aGV5IGFyZSBub3QgdGhlIG9ubHkgc2FuY3Rpb25lZCBvbmVzOiB0aGVyZSBp cyBhDQp0aGlyZCwgbG9uZy1zdGFuZGluZyBwYXR0ZXJuIHdoZXJlIGEgIiM8bmFtZT4tY2VsbHMi IHByb3BlcnR5IGluIGEgbm9kZQ0KZGVjbGFyZXMgdGhlIGNlbGwgc3RyaWRlIG9mIGEgKm5vbi1w aGFuZGxlIGxpc3QgcHJvcGVydHkgaW4gdGhhdCB2ZXJ5IHNhbWUNCm5vZGUqLiBUaGF0IGlzIGV4 YWN0bHkgd2hhdCAiI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyIgZG9lcyBmb3INCiJzY21p LXNlY29uZGFyeS1hZ2VudHMiLiBTb21lIGV2aWRlbmNlIGZyb20gdGhlIERldmljZXRyZWUgU3Bl Y2lmaWNhdGlvbiBhbmQNCmZyb20gTGludXg6DQoNCjEpICJyYW5nZXMiIGFuZCAiaW50ZXJydXB0 LW1hcCIgYXJlIHBhcnNlZCB3aXRoIHRoZSBjZWxsIGNvdW50cyBvZiB0aGUgbm9kZQ0KICAgIHRo YXQgY2FycmllcyB0aGVtLCBub3Qgb2YgYSBjaGlsZCBvciBvZiBhIHBoYW5kbGUgdGFyZ2V0Lg0K DQogICAgZHRjIGVuZm9yY2VzIHRoaXMgaXRzZWxmOg0KDQogICAgLSBzY3JpcHRzL2R0Yy9jaGVj a3MuYzo3ODUgY2hlY2tfcmFuZ2VzX2Zvcm1hdCgpIGNvbXB1dGVzIHRoZSBlbnRyeQ0KbGVuZ3Ro DQogICAgICBhcyAocGFyZW50ICNhZGRyZXNzLWNlbGxzICsgdGhpcyBub2RlJ3MgI2FkZHJlc3Mt Y2VsbHMgKyB0aGlzIG5vZGUncw0KICAgICAgI3NpemUtY2VsbHMpIGFuZCB2YWxpZGF0ZXMgdGhl IGxlbmd0aCBvZiAicmFuZ2VzIiBpbiB0aGlzIG5vZGUNCmFnYWluc3QgaXQuDQoNCiAgICAtIHNj cmlwdHMvZHRjL2NoZWNrcy5jOjE2MDEgY2hlY2tfaW50ZXJydXB0X21hcCgpOg0KDQogICAgICAg ICAgY2VsbHNpemUgPSBub2RlX2FkZHJfY2VsbHMobm9kZSk7DQogICAgICAgICAgY2VsbHNpemUg Kz0gcHJvcHZhbF9jZWxsKGdldF9wcm9wZXJ0eShub2RlLCAiI2ludGVycnVwdC1jZWxscyIpKTsN Cg0KICAgICAgaS5lLiB0aGUgc3RyaWRlIG9mIHRoZSAiaW50ZXJydXB0LW1hcCIgZW50cmllcyBp biBhIG5vZGUgaXMgdGFrZW4gZnJvbQ0KICAgICAgIiNhZGRyZXNzLWNlbGxzIiBhbmQgIiNpbnRl cnJ1cHQtY2VsbHMiICpvZiB0aGF0IHNhbWUgbm9kZSouIExpbnV4DQpkb2VzDQogICAgICB0aGUg c2FtZSBpbiBkcml2ZXJzL29mL2lycS5jLg0KDQogICAgU28gImEgIyotY2VsbHMgcHJvcGVydHkg aW4gbm9kZSBYIGRlc2NyaWJpbmcgdGhlIGxheW91dCBvZiBhIHByb3BlcnR5IGluDQogICAgbm9k ZSBYIiBpcyBub3QgYW4gYWJ1c2Ugb2YgdGhlIGNvbnZlbnRpb24sIGl0IGlzIGhvdyB0d28gb2Yg dGhlIGNvcmUNCiAgICBEZXZpY2V0cmVlIFNwZWNpZmljYXRpb24gcHJvcGVydGllcyBhcmUgZGVm aW5lZC4NCg0KMikgVGhlcmUgaXMgYSBwcmVjZWRlbnQgd2hvc2Ugc2hhcGUgaXMgaWRlbnRpY2Fs IHRvIG91cnMgLSBhIHZlbmRvciBwcm9wZXJ0eQ0KICAgIGhvbGRpbmcgYSBsaXN0LCBwbHVzIGNl bGxzIHByb3BlcnRpZXMgaW4gdGhlIHNhbWUgbm9kZSB0aGF0IGRlc2NyaWJlDQpob3cgdG8NCiAg ICBkZWNvZGUgaXQ6DQoNCiAgICBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdHBt L2libSx2dHBtLnlhbWw6MzYNCg0KICAgICAgICBpYm0sI2RtYS1hZGRyZXNzLWNlbGxzOg0KICAg ICAgICAgIGRlc2NyaXB0aW9uOg0KICAgICAgICAgICAgbnVtYmVyIG9mIGNlbGxzIHRoYXQgYXJl IHVzZWQgdG8gZW5jb2RlIHRoZSBwaHlzaWNhbCBhZGRyZXNzDQpmaWVsZA0KICAgICAgICAgICAg b2YgZG1hLXdpbmRvdyBwcm9wZXJ0aWVzDQogICAgICAgIGlibSwjZG1hLXNpemUtY2VsbHM6DQog ICAgICAgICAgZGVzY3JpcHRpb246DQogICAgICAgICAgICBudW1iZXIgb2YgY2VsbHMgdGhhdCBh cmUgdXNlZCB0byBlbmNvZGUgdGhlIHNpemUgZmllbGQgb2YNCiAgICAgICAgICAgIGRtYS13aW5k b3cgcHJvcGVydGllcw0KICAgICAgICBpYm0sbXktZG1hLXdpbmRvdzoNCiAgICAgICAgICBkZXNj cmlwdGlvbjogRE1BIHdpbmRvdyBhc3NvY2lhdGVkIHdpdGggdGhpcyB2aXJ0dWFsIEkvTyBBZGFw dGVyDQoNCiAgICBhbmQgdGhlIGV4YW1wbGUgKHNhbWUgZmlsZSwgbGluZXMgOTYtOTgpOg0KDQog ICAgICAgIGlibSwjZG1hLWFkZHJlc3MtY2VsbHMgPSA8MHgyPjsNCiAgICAgICAgaWJtLCNkbWEt c2l6ZS1jZWxscyA9IDwweDI+Ow0KICAgICAgICBpYm0sbXktZG1hLXdpbmRvdyA9IDwweDEwMDAw MDAzIDB4MCAweDAgMHgwIDB4MTAwMDAwMDA+Ow0KDQogICAgQm90aCBjZWxscyBwcm9wZXJ0aWVz IGFyZSAicmVxdWlyZWQiLiBUaGUgcGFyc2VyIGlzDQogICAgYXJjaC9wb3dlcnBjL2tlcm5lbC9w cm9tX3BhcnNlLmM6MTEgb2ZfcGFyc2VfZG1hX3dpbmRvdygpLCB3aGljaCByZWFkcw0KICAgICJp Ym0sI2RtYS1hZGRyZXNzLWNlbGxzIiBhbmQgImlibSwjZG1hLXNpemUtY2VsbHMiIGZyb20gdGhl IHNhbWUNCm5vZGUgImRuIg0KICAgIHRvIHdhbGsgImlibSxteS1kbWEtd2luZG93Ii4gVGhlcmUg aXMgbm8gcGhhbmRsZSBhbmQgbm8gY2hpbGQgbm9kZQ0KICAgIGludm9sdmVkOyB0aGlzIGlzIGV4 YWN0bHkgdGhlICJzZWxmLWRlc2NyaWJpbmcgbGlzdCBwcm9wZXJ0eSIgcGF0dGVybi4NCg0KMykg QSAiIyotY2VsbHMiIHByb3BlcnR5IGRvZXMgbm90IGhhdmUgdG8gZGVzY3JpYmUgYSBwaGFuZGxl IHNwZWNpZmllcg0KYXQgYWxsOg0KDQogICAgLSAiI3BpbmN0cmwtY2VsbHMiIChEb2N1bWVudGF0 aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcGluY3RybC8NCiAgICAgIHBpbmN0cmwtc2luZ2xlLnlh bWw6NTUpIGdpdmVzIHRoZSBudW1iZXIgb2YgY2VsbHMgcGVyIGVudHJ5IG9mIHRoZQ0KcGxhaW4N CiAgICAgICJwaW5jdHJsLXNpbmdsZSxwaW5zIiBwcm9wZXJ0eTsgZHJpdmVycy9waW5jdHJsL2Rl dmljZXRyZWUuYzoyOTcNCiAgICAgIHBpbmN0cmxfZmluZF9jZWxsc19zaXplKCkgbG9va3MgaXQg dXAgaW4gdGhlIHBhcmVudC9ncmFuZHBhcmVudCBub2RlLg0KICAgICAgTm8gcGhhbmRsZSBzcGVj aWZpZXIgaXMgaW52b2x2ZWQuDQoNCiAgICAtICIjaW5kZXgtY2VsbHMiDQooRG9jdW1lbnRhdGlv bi9kZXZpY2V0cmVlL2JpbmRpbmdzL3VzYi9mc2wsdXNibWlzYy55YW1sOjU2KQ0KICAgICAgaXMg bm90IGEgc3BlY2lmaWVyIGZvciBhbnkgZG9tYWluIGVpdGhlci4NCg0KU28gdGhlIGNvbnZlbnRp b24gaW4gcHJhY3RpY2UgaXMgImEgIzxmb28+LWNlbGxzIHByb3BlcnR5IHN0YXRlcyBob3cNCm1h bnkgY2VsbHMNCm9uZSA8Zm9vPiBlbnRyeSBvY2N1cGllcyIsIGFuZCB0aGUgZW50cmllcyBtYXkg bGl2ZSBpbiBhIGNoaWxkIG5vZGUncw0KcHJvcGVydHkNCigjYWRkcmVzcy1jZWxscyksIGluIGEg Y29uc3VtZXIncyBwaGFuZGxlIHNwZWNpZmllciAoI2ludGVycnVwdC1jZWxscywNCiNjbG9jay1j ZWxscyksIG9yIGluIGEgcHJvcGVydHkgb2YgdGhlIGRlY2xhcmluZyBub2RlIGl0c2VsZiAocmFu Z2VzLA0KaW50ZXJydXB0LW1hcCwgaWJtLG15LWRtYS13aW5kb3cpLiBPdXIgdXNhZ2UgZmFsbHMg aW50byB0aGUgdGhpcmQgZ3JvdXAuDQoNClRoaXMgYnJpbmcgdXMgdG8gdGhlIGZvbGxvd2luZyBj b25jbHVzaW9uIHRoYXQNCiNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMgdXNhZ2UNCmRvZXNu J3QgdGVjaG5pY2FsbHkgYnJlYWsgdGhlIGRldmljZS10cmVlIGNvbnZlbnRpb24gd2l0aCAyIGV4 Y2VwdGlvbnM6DQoNCmEpIFZlbmRvciBwcmVmaXguIERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9i aW5kaW5ncy93cml0aW5nLWJpbmRpbmdzLnJzdDo2OA0KICAgIHNheXMgIkRPIHVzZSBhIHZlbmRv ciBwcmVmaXggb24gZGV2aWNlLXNwZWNpZmljIHByb3BlcnR5IG5hbWVzIiwgYW5kIGFsbA0KICAg IHRoZSBzYW1lLW5vZGUgcHJlY2VkZW50cyBhYm92ZSBhcmUgdmVuZG9yLXByZWZpeGVkDQooImli bSwjZG1hLWFkZHJlc3MtY2VsbHMiKS4NCiAgICBCb3RoIG9mIG91ciBwcm9wZXJ0aWVzIGFyZSBY ZW4tc3BlY2lmaWMgYW5kIGxpdmUgdW5kZXIgL2Nob3Nlbi94ZW4sDQpzbyBpZiB3ZQ0KICAgIGtl ZXAgdGhlIGZsYXQgZm9ybSB0aGV5IHNob3VsZCBiZWNvbWUgInhlbixzY21pLXNlY29uZGFyeS1h Z2VudHMiIGFuZA0KICAgICJ4ZW4sI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyIuDQoNCmIp IEVudHJ5IGxheW91dC4gSW4gb3VyIGxpc3QgdGhlIHBoYW5kbGUgaXMgdGhlIHNlY29uZCBjZWxs DQogICAgKDxzbWMtaWQgJnNobWVtIGFnZW50LWlkPiksIHdoaWNoIHByZXZlbnRzIHRoZSB1c2Ug b2YgdGhlIHN0YW5kYXJkDQogICAgcGhhbmRsZS1hcnJheSBoZWxwZXJzIC0gdGhleSBhbGwgZXhw ZWN0IHRoZSBwaGFuZGxlIGZpcnN0LiBJZiB3ZQ0Ka2VlcCB0aGUNCiAgICBmbGF0IGZvcm0sIHJl b3JkZXJpbmcgdG8gPCZzaG1lbSBzbWMtaWQgYWdlbnQtaWQ+IHdvdWxkIGxldCB0aGUNCnByb3Bl cnR5IGJlDQogICAgcGFyc2VkIGFzIGFuIG9yZGluYXJ5IHBoYW5kbGUtYXJyYXkuDQoNCkFzIGZv ciB5b3VyIHByb3Bvc2FsOiB0aGUgY2hpbGQtbm9kZSBmb3JtIHlvdSBzdWdnZXN0IGlzIGNlcnRh aW5seQ0KbW9yZSBpZGlvbWF0aWMsIGl0IG1ha2VzIHRoZSBhZ2VudCBpZCBhbiBhZGRyZXNzYWJs ZSAicmVnIiBhbmQgaXQNCnJlbW92ZXMgdGhlDQpvcHRpb25hbCAyLXZzLTMtY2VsbHMgdmFyaWFu dCBhbHRvZ2V0aGVyLiBNeSBvbmx5IHJlc2VydmF0aW9ucyBhcmUgdGhhdA0KaXQgZ3Jvd3MNCnRo ZSBYZW4gRFQgcGFyc2VyIChub2RlIGl0ZXJhdGlvbiBpbnN0ZWFkIG9mIGEgc2luZ2xlIHByb3Bl cnR5IHdhbGspIGFuZA0KdGhhdCB0aGUNCmNvbXBhdGlibGUgc3RyaW5nIHdvdWxkIG5lZWQgYSBu YW1lc3BhY2Ugd2Ugb3duICgieGVuLHNjbWktYWdlbnQiIHJhdGhlcg0KdGhhbg0KImFybSxzY21p LWFnZW50IiwgYXMgeW91IGNvcnJlY3RseSBzdXNwZWN0ZWQpLg0KDQpTbyBJIGRvIG5vdCB0aGlu ayB0aGUgY3VycmVudCBmb3JtIGlzIGludmFsaWQsIGJ1dCBJIGhhdmUgbm8gb2JqZWN0aW9uIHRv DQptb3ZpbmcgdG8gY2hpbGQgbm9kZXMgaWYgeW91IHByZWZlciBpdC4gUGxlYXNlIGxldCBtZSBr bm93IHdoaWNoIHdheSB5b3UNCndvdWxkDQpsaWtlIG1lIHRvIGdvIGZvciB2MTQgYW5kIEkgd2ls bCByZXNwaW4gYWNjb3JkaW5nbHkuDQo+PiAgICAgICAgICB4ZW4sZG9tMC1zY2ktYWdlbnQtaWQg PSA8MD47DQo+Pg0KPj4gICAgICAgICAgc2NtaV9zaG1fMDogc3JhbUA0N2ZmMDAwMCB7DQo+PiAg ICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gICAgICAgICAgICBy ZWcgPSA8MHgwIDB4NDdmZjAwMDAgMHgwIDB4MTAwMD47DQo+PiAgICAgICAgICB9Ow0KPj4NCj4+ ICAgICAgICAgIC8qIFhlbiBTQ01JIG1hbmFnZW1lbnQgY2hhbm5lbCAqLw0KPj4gICAgICAgICAg c2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+PiAgICAgICAgICAgIGNvbXBhdGlibGUgPSAi YXJtLHNjbWktc2htZW0iOw0KPj4gICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjEwMDAgMHgw IDB4MTAwMD47DQo+PiAgICAgICAgICB9Ow0KPj4NCj4+ICAgICAgICAgIHNjbWlfc2htXzI6IHNy YW1ANDdmZjIwMDAgew0KPj4gICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVt IjsNCj4+ICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYyMDAwIDB4MCAweDEwMDA+Ow0KPj4g ICAgICAgICAgfTsNCj4+DQo+PiAgICAgICAgICBzY21pX3NobV8zOiBzcmFtQDQ3ZmYzMDAwIHsN Cj4+ICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAgICAgICAg ICAgIHJlZyA9IDwweDAgMHg0N2ZmMzAwMCAweDAgMHgxMDAwPjsNCj4+ICAgICAgICAgIH07DQo+ Pg0KPj4gICAgICAgICAgc2NtaV94ZW46IHNjbWkgew0KPj4gICAgICAgICAgICBjb21wYXRpYmxl ID0gImFybSxzY21pLXNtYyI7DQo+PiAgICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAw Mz47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgZnVuY19pZA0KPj4gICAgICAgICAgICAjYWRk cmVzcy1jZWxscyA9IDwxPjsNCj4+ICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8MD47DQo+PiAg ICAgICAgICAgICNhY2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwxPjsNCj4+ICAgICAgICAgICAg c2htZW0gPSA8JnNjbWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IHNobWVtDQo+ PiAgICAgICAgICB9Ow0KPj4gICAgICAgIH07DQo+PiAgICAgIH07DQo+PiAgICB9Ow0KPj4gfTsN Cj4+DQo+PiAvIHsNCj4+ICAgICAgLyoNCj4+ICAgICAgICogSG9zdCBTQ01JIE9TUE0gY2hhbm5l bCAtIHByb3ZpZGVkIHRvIHRoZSBEb20wIGFzIGlzIGlmIFNDTUkNCj4+ICAgICAgICogZW5hYmxl ZCBmb3IgaXQsIGlnbm9yZWQgYnkgWGVuIG11bHRpLWFnZW50IG1lZGlhdG9yDQo+PiAgICAgICAq Lw0KPj4gICAgICBzY21pX3NobTogc3JhbUA0N2ZmMDAwMCB7DQo+PiAgICAgICAgICAgICAgY29t cGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAgICAgICAgICAgICAgcmVnID0gPDB4MCAw eDQ3ZmYwMDAwIDB4MCAweDEwMDA+Ow0KPj4gICAgICB9Ow0KPj4NCj4+ICAgICAgZmlybXdhcmUg ew0KPj4gICAgICAgIHNjbWk6IHNjbWkgew0KPj4gICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0s c2NtaS1zbWMiOw0KPj4gICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAyPjsgPC0tLSBI b3N0IE9TUE0gYWdlbnQgc21jLWlkDQo+PiAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwgMT47 DQo+PiAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwgMD47DQo+PiAgICAgICAgICBzaG1lbSA9IDwm c2NtaV9zaG0+OyA8LS0tIEhvc3QgT1NQTSBhZ2VudCBzaG1lbQ0KPj4NCj4+ICAgICAgICAgIHBy b3RvY29sQFh7DQo+PiAgICAgICAgICB9Ow0KPj4gICAgICAgIH07DQo+PiAgICAgfTsNCj4+IH07 DQo+Pg0KPj4gVGhpcyBhcHByb2FjaCBhbGxvd3MgZGVmaW5pbmcgbXVsdGlwbGUgU0NNSSBBZ2Vu dHMgYnkgYWRkaW5nDQo+PiBYZW4tc3BlY2lmaWMgcHJvcGVydGllcyB1bmRlciB0aGUgYGAvY2hv c2VuYGAgbm9kZSB0byB0aGUgSG9zdCBEZXZpY2UNCj4+IFRyZWUsIGxlYXZpbmcgdGhlIG1haW4g cGFydCB1bmNoYW5nZWQuIFRoZSBIb3N0IERUIFNDTUkgY2hhbm5lbCB3aWxsDQo+PiBiZSBwYXNz ZWQgdG8gRG9tMC4NCj4+DQo+PiBUaGUgWGVuIG1hbmFnZW1lbnQgYWdlbnQgaXMgZGVzY3JpYmVk IGFzIGEgYGBzY21pX3hlbmBgIG5vZGUgdW5kZXIgdGhlDQo+PiBgYHhlbixzY2lgYCBjb21hcHRp YmxlIG5vZGUsIHdoaWNoIGlzIHVzZWQgYnkgWGVuIHRvIGNvbnRyb2wgb3RoZXINCj4+IFNDTUkg QWdlbnRzIGluIHRoZSBzeXN0ZW0uDQo+Pg0KPj4gQWxsIHNlY29uZGFyeSBhZ2VudHMnIGNvbmZp Z3VyYXRpb25zIGFyZSBwcm92aWRlZCBpbiB0aGUNCj4+IGBgc2NtaS1zZWNvbmRhcnktYWdlbnRz YGAgcHJvcGVydHkgd2l0aCBhbiBvcHRpb25hbCBgYGFnZW50X2lkYGAgZmllbGQuDQo+Pg0KPj4g VGhlIGBgYWdlbnRfaWRgYCBmcm9tIHRoZSBgYHNjbWktc2Vjb25kYXJ5LWFnZW50c2BgIHByb3Bl cnR5IGlzIHVzZWQNCj4+IHRvIGlkZW50aWZ5IHRoZSBhZ2VudCBpbiB0aGUgc3lzdGVtIGFuZCBj YW4gYmUgb21pdHRlZCBieSBzZXR0aW5nDQo+PiBgYCNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2Vs bHMgPSA8Mj5gYCwgc28gdGhlIFNlY29uZGFyeSBBZ2VudHMNCj4+IGNvbmZpZ3VyYXRpb24gd2ls bCBsb29rIGxpa2UgdGhpczoNCj4+DQo+PiAvIHsNCj4+ICAgIGNob3NlbiB7DQo+PiAgICAgIHhl biB7DQo+PiAgICAgICAgeGVuX3NjbWlfY29uZmlnIHsNCj4+ICAgICAgICAgIGNvbXBhdGlibGUg PSAieGVuLHNjaSI7DQo+PiAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwyPjsNCj4+ICAgICAg ICAgICNzaXplLWNlbGxzID0gPDI+Ow0KPj4gICAgICAgICAgcmFuZ2VzOw0KPj4NCj4+ICAgICAg ICAgIC8qIFNoYXJlZCBtZW1vcnkgbm9kZXMgYXMgZGVmaW5lZCBlYXJsaWVyICovDQo+Pg0KPj4g ICAgICAgICAgc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4gICAgICAgICAgICAweDgyMDAw MDAzICZzY21pX3NobV8wDQo+PiAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2htXzINCj4+ ICAgICAgICAgICAgMHg4MjAwMDAwNSAmc2NtaV9zaG1fMw0KPj4gICAgICAgICAgICAweDgyMDAw MDA2ICZzY21pX3NobV80PjsNCj4+ICAgICAgICAgICNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2Vs bHMgPSA8Mj47DQo+PiAgICAgICAgfTsNCj4+ICAgICAgfTsNCj4+ICAgIH07DQo+PiB9DQo+Pg0K Pj4gSW4gdGhpcyBjYXNlLCBYZW4gd2lsbCB1c2UgdGhlIGBgU0NNSV9CQVNFX0RJU0NPVkVSX0FH RU5UYGAgY2FsbCB0bw0KPj4gZGlzY292ZXIgdGhlIGBgYWdlbnRfaWRgYCBmb3IgZWFjaCBzZWNv bmRhcnkgYWdlbnQuIFByb3ZpZGluZyB0aGUNCj4+IGBgYWdlbnRfaWRgYCBpbiB0aGUgYGBzY21p LXNlY29uZGFyeS1hZ2VudHNgYCBwcm9wZXJ0eSBhbGxvd3Mgc2tpcHBpbmcNCj4+IHRoZSBkaXNj b3ZlcnkgY2FsbCwgd2hpY2ggaXMgdXNlZnVsIHdoZW4gdGhlIHNlY29uZGFyeSBhZ2VudCdzIHNo YXJlZA0KPj4gbWVtb3J5IGlzIG5vdCBhY2Nlc3NpYmxlIGJ5IFhlbiBvciB3aGVuIGJvb3QgdGlt ZSBpcyBpbXBvcnRhbnQgYmVjYXVzZQ0KPj4gaXQgYWxsb3dzIHNraXBwaW5nIHRoZSBhZ2VudCBk aXNjb3ZlcnkgcHJvY2VkdXJlLg0KPj4NCj4+ICAgIE5vdGUgdGhhdCBYZW4gaXMgdGhlIG9ubHkg b25lIGVudHJ5IGluIHRoZSBzeXN0ZW0gd2hpY2ggbmVlZCB0byBrbm93DQo+PiAgICBhYm91dCBT Q01JIG11bHRpLWFnZW50IHN1cHBvcnQuDQo+Pg0KPj4gU01DIElEIENvbmZpZ3VyYXRpb24gYW5k IFNDTUkgQ29ubmVjdGlvbiBDb21wYXRpYmlsaXR5Og0KPj4NCj4+IFRoZSBjb25maWd1cmF0aW9u IGFsbG93cyB0aGUgc2FtZSBkZXZpY2UgdHJlZSB0byB3b3JrIGZvciBib3RoIGJhcmVtZXRhbA0K Pj4gTGludXggYW5kIExpbnV4IERvbTAuIFRoaXMgaXMgYWNoaWV2ZWQgYmVjYXVzZToNCj4+DQo+ PiAtIEJhcmVtZXRhbCBMaW51eCB1c2VzOiBmdW5jX2lkIDB4ODIwMDAwMDIsIHNjbWktc2htZW0g MHg0N2ZmMDAwMA0KPj4gLSBEb20wIExpbnV4IHVzZXM6IGZ1bmNfaWQgMHg4MjAwMDAwMiwgc2Nt aS1zaG1lbSAweDQ3ZmYwMDAwDQo+PiAtIFhlbiBtYW5hZ2VtZW50IHVzZXM6IGZ1bmNfaWQgMHg4 MjAwMDAwMywgc2NtaS1zaG1lbSAweDQ3ZmYxMDAwDQo+Pg0KPj4gVGhpcyB3b3JrcyBiZWNhdXNl IHRoZSBwcml2aWxlZ2VkIFNDTUkgY29ubmVjdGlvbiBpbiBFTDMgZmlybXdhcmUgaXMgbm90DQo+ PiB0aWVkIGV4Y2x1c2l2ZWx5IHRvIGZ1bmNfaWQgMHg4MjAwMDAwMi4gVGhlIEVMMyBmaXJtd2Fy ZSBzdXBwb3J0cyBtdWx0aXBsZQ0KPj4gU0NNSSBhZ2VudHMgd2l0aCBkaWZmZXJlbnQgU01DIElE cyBhbmQgc2hhcmVkIG1lbW9yeSByZWdpb25zLiBFYWNoIGFnZW50DQo+PiAoRG9tMCB2aWEgMHg4 MjAwMDAwMiwgWGVuIHZpYSAweDgyMDAwMDAzLCBvdGhlciBkb21haW5zIHZpYSBhZGRpdGlvbmFs DQo+PiBmdW5jX2lkcykgaGFzIGFuIGluZGVwZW5kZW50IGNvbW11bmljYXRpb24gY2hhbm5lbCB0 byB0aGUgZmlybXdhcmUuDQo+Pg0KPj4gVGhlIGtleSBkaXN0aW5jdGlvbiBpcyB0aGF0IFhlbidz IG1hbmFnZW1lbnQgY2hhbm5lbCAoMHg4MjAwMDAwMykgaXMgdXNlZA0KPj4gZm9yIHByaXZpbGVn ZWQgb3BlcmF0aW9ucyBsaWtlIGFnZW50IGNvbmZpZ3VyYXRpb24gYW5kIGRldmljZSBwZXJtaXNz aW9ucw0KPj4gKEJBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUywgQkFTRV9SRVNFVF9BR0VOVF9D T05GSUdVUkFUSU9OKSwgd2hpbGUgRG9tMCdzDQo+PiBjaGFubmVsICgweDgyMDAwMDAyKSBpcyB1 c2VkIGZvciBzdGFuZGFyZCBTQ01JIHByb3RvY29sIG9wZXJhdGlvbnMgKHBvd2VyLA0KPj4gY2xv Y2ssIHNlbnNvciBtYW5hZ2VtZW50LCBldGMuKS4gVGhlIGZpcm13YXJlIGVuZm9yY2VzIGRpZmZl cmVudCBwZXJtaXNzaW9uDQo+PiBsZXZlbHMgZm9yIGVhY2ggYWdlbnQgYmFzZWQgb24gdGhlaXIg YWdlbnRfaWQsIG5vdCB0aGUgU01DIElELg0KPj4NCj4+IFRoZXJlZm9yZSwgdGhlcmUgaXMgbm8g Y29uZmxpY3Q6IExpbnV4IERvbTAgcmV0YWlucyBpdHMgc3RhbmRhcmQgU0NNSQ0KPj4gY29ubmVj dGlvbiBmb3IgaGFyZHdhcmUgbWFuYWdlbWVudCwgd2hpbGUgWGVuIHVzZXMgaXRzIHNlcGFyYXRl IHByaXZpbGVnZWQNCj4+IGNoYW5uZWwgZm9yIG1lZGlhdGluZyBhY2Nlc3MgYmV0d2VlbiBtdWx0 aXBsZSBkb21haW5zLg0KPj4NCj4+IC0gSXQgaW1wbGVtZW50cyB0aGUgU0NJIHN1YnN5c3RlbSBp bnRlcmZhY2UgcmVxdWlyZWQgZm9yIGNvbmZpZ3VyaW5nIGFuZA0KPj4gZW5hYmxpbmcgU0NNSSBm dW5jdGlvbmFsaXR5IGZvciBEb20wL2h3ZG9tIGFuZCBHdWVzdCBkb21haW5zLiBUbyBlbmFibGUN Cj4+IFNDTUkgZnVuY3Rpb25hbGl0eSBmb3IgZG9tYWluIGl0IGhhcyB0byBiZSBjb25maWd1cmVk IHdpdGggdW5pcXVlIHN1cHBvcnRlZA0KPj4gU0NNSSBBZ2VudF9pZCBhbmQgdXNlIGNvcnJlc3Bv bmRpbmcgU0NNSSBTTUMgc2hhcmVkIG1lbW9yeSB0cmFuc3BvcnQNCj4+IFtzbWMtaWQsIHNobWVt XSBkZWZpbmVkIGZvciB0aGlzIFNDTUkgQWdlbnRfaWQuDQo+PiAtIE9uY2UgWGVuIGRvbWFpbiBp cyBjb25maWd1cmVkIGl0IGNhbiBjb21tdW5pY2F0ZSB3aXRoIEVMMyBTQ01JIEZXOg0KPj4gICAg LS0gemVyby1jb3B5LCB0aGUgZ3Vlc3QgZG9tYWluIHB1dHMgU0NNSSBtZXNzYWdlIGluIHNobWVt Ow0KPj4gICAgLS0gdGhlIGd1ZXN0IHRyaWdnZXJzIFNNQyBleGNlcHRpb24gd2l0aCBzbWMtaWQg KGRvb3JiZWxsKTsNCj4+ICAgIC0tIHRoZSBYZW4gZHJpdmVyIGNhdGNoZXMgZXhjZXB0aW9uLCBk byBjaGVja3MgYW5kIHN5bmNocm9ub3VzbHkgZm9yd2FyZHMNCj4+ICAgIGl0IHRvIEVMMyBGVy4N Cj4+IC0gdGhlIFhlbiBkcml2ZXIgc2VuZHMgQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdVUkFUSU9O IG1lc3NhZ2UgdG8gWGVuDQo+PiAgICBtYW5hZ2VtZW50IGFnZW50IGNoYW5uZWwgb24gZG9tYWlu IGRlc3Ryb3kgZXZlbnQuIFRoaXMgYWxsb3dzIHRvIHJlc2V0DQo+PiAgICByZXNvdXJjZXMgdXNl ZCBieSBkb21haW4gYW5kIHNvIGltcGxlbWVudCB1c2UtY2FzZSBsaWtlIGRvbWFpbiByZWJvb3Qu DQo+Pg0KPj4gRG9tMCBFbmFibGUgU0NNSSBTTUM6DQo+PiAgIC0gc2V0IHhlbixkb20wLXNjaS1h Z2VudC1pZD08YWdlbnRfaWQ+IHVuZGVyIHRoZSB4ZW4sc2NpIGNvbnRhaW5lciBpbg0KPj4gICAg IHRoZSBIb3N0IERULiBJZiB0aGUgcHJvcGVydHkgaXMgYWJzZW50LCBTQ01JIGlzIGRpc2FibGVk IGZvciBEb20wDQo+PiAgICAgYW5kIGFsbCBTQ01JIG5vZGVzIGFyZSByZW1vdmVkIGZyb20gdGhl IERvbTAgRFQuIFRoZSBkcml2ZXIgdXBkYXRlcw0KPj4gICAgIHRoZSBEb20wIERUIFNDTUkgbm9k ZSAiYXJtLHNtYy1pZCIgdmFsdWUgYW5kIGZpeGVzIHVwIHRoZSBzaG1lbQ0KPj4gICAgIG5vZGUg YWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25lZCBhZ2VudF9pZC4NCj4+DQo+PiAgIC0gcGFzcyBkb20w PXNjaS1hZ2VudC1pZD08YWdlbnRfaWQ+IGluIFhlbiBjb21tYW5kIGxpbmUuIGlmIG5vdCBwcm92 aWRlZA0KPj4gICAgIFNDTUkgd2lsbCBiZSBkaXNhYmxlZCBmb3IgRG9tMCBhbmQgYWxsIFNDTUkg bm9kZXMgcmVtb3ZlZCBmcm9tIERvbTAgRFQuDQo+PiAgICAgVGhlIGRyaXZlciB1cGRhdGVzIERv bTAgRFQgU0NNSSBub2RlICJhcm0sc21jLWlkIiB2YWx1ZSBhbmQgZml4IHVwIHNobWVtDQo+PiAg ICAgbm9kZSBhY2NvcmRpbmcgdG8gYXNzaWduZWQgYWdlbnRfaWQuDQo+Pg0KPj4gR3Vlc3QgZG9t YWlucyBlbmFibGUgU0NNSSBTTUM6DQo+PiAgIC0geGwuY2ZnOiBhZGQgY29uZmlndXJhdGlvbiBv cHRpb24gYXMgYmVsb3cNCj4+DQo+PiAgICAgYXJtX3NjaSA9ICJ0eXBlPXNjbWlfc21jX211bHRp YWdlbnQsYWdlbnRfaWQ9MiINCj4+DQo+PiAgIC0geGwuY2ZnOiBlbmFibGUgYWNjZXNzIHRvIHRo ZSAiYXJtLHNjbWktc2htZW0iIHdoaWNoIHNob3VsZA0KPj4gICBjb3JyZXNwb25kIGFzc2lnbmVk IGFnZW50X2lkIGZvciB0aGUgZG9tYWluLCBmb3IgZXhhbXBsZToNCj4+DQo+PiBpb21lbSA9IFsN Cj4+ICAgICAgIjQ3ZmYyLDFAMjIwMDEiLA0KPj4gXQ0KPj4NCj4+ICAgLSBEVDogYWRkIFNDTUkg bm9kZXMgdG8gdGhlIERyaXZlciBkb21haW4gcGFydGlhbCBkZXZpY2UgdHJlZSBhcyBpbiB0aGUN Cj4+ICAgYmVsb3cgZXhhbXBsZS4gVGhlICJhcm0sc21jLWlkIiBzaG91bGQgY29ycmVzcG9uZCBh c3NpZ25lZCBhZ2VudF9pZA0KPj4gICBmb3IgdGhlIGRvbWFpbjoNCj4+DQo+PiBwYXNzdGhyb3Vn aCB7DQo+PiAgICAgc2NtaV9zaG1fMDogc3JhbUAyMjAwMTAwMCB7DQo+PiAgICAgICAgIGNvbXBh dGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gICAgICAgICByZWcgPSA8MHgwIDB4MjIwMDEw MDAgMHgwIDB4MTAwMD47DQo+PiAgICAgfTsNCj4+DQo+PiAgICAgZmlybXdhcmUgew0KPj4gICAg ICAgICAgY29tcGF0aWJsZSA9ICJzaW1wbGUtYnVzIjsNCj4+ICAgICAgICAgICAgICBzY21pOiBz Y21pIHsNCj4+ICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0K Pj4gICAgICAgICAgICAgICAgICBhcm0sc21jLWlkID0gPDB4ODIwMDAwMDQ+Ow0KPj4gICAgICAg ICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMD47DQo+PiAgICAgICAgICAgICAgICAgIC4u Lg0KPj4gICAgICAgICAgICAgIH0NCj4+ICAgICAgfQ0KPj4gfQ0KPj4NCj4+IFNDTUkgIjQuMi4x LjEgRGV2aWNlIHNwZWNpZmljIGFjY2VzcyBjb250cm9sIg0KPj4NCj4+IFRoZSBYRU4gU0NJIFND TUkgU01DIG11bHRpLWFnZW50IGRyaXZlciBwZXJmb3JtcyAiYWNjZXNzLWNvbnRyb2xsZXIiDQo+ PiBwcm92aWRlciBmdW5jdGlvbiBpbiBjYXNlIEVMMyBTQ01JIEZXIGltcGxlbWVudHMgU0NNSSAi NC4yLjEuMSBEZXZpY2UNCj4+IHNwZWNpZmljIGFjY2VzcyBjb250cm9sIiBhbmQgcHJvdmlkZXMg dGhlIEJBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUw0KPj4gY29tbWFuZCB0byBjb25maWd1cmUg dGhlIGRldmljZXMgdGhhdCBhbiBhZ2VudHMgaGF2ZSBhY2Nlc3MgdG8uDQo+PiBUaGUgRFQgU0NN SSBub2RlIHNob3VsZCAiI2FjY2Vzcy1jb250cm9sbGVyLWNlbGxzPTwxPiIgcHJvcGVydHkgYW5k IERUDQo+PiBkZXZpY2VzIHNob3VsZCBiZSBib3VuZCB0byB0aGUgWGVuIFNDTUkuDQo+Pg0KPj4g JmkyYzEgew0KPj4gICAgICAgICAgYWNjZXNzLWNvbnRyb2xsZXJzID0gPCZzY21pIDA+Ow0KPj4g fTsNCj4+DQo+PiBUaGUgRG9tMCBhbmQgZG9tMGxlc3MgZG9tYWlucyBEVCBkZXZpY2VzIHdpbGwg YmUgcHJvY2Vzc2VkDQo+PiBhdXRvbWF0aWNhbGx5IHRocm91Z2ggc2NpX2Fzc2lnbl9kdF9kZXZp Y2UoKSBjYWxsLCBidXQgdG8gYXNzaWduIFNDTUkNCj4+IGRldmljZXMgZnJvbSB0b29sc3RhY2sg dGhlIHhsLmNmZzoiZHRkZXYiIHByb3BlcnR5DQo+PiBzaGFsbCBiZSB1c2VkOg0KPj4NCj4+IGR0 ZGV2ID0gWw0KPj4gICAgICAiL3NvYy9pMmNAZTY1MDgwMDAiLA0KPj4gXQ0KPj4NCj4+IHhsLmNm ZzpkdGRldiB3aWxsIGNvbnRhaW4gYWxsIG5vZGVzIHdoaWNoIGFyZSB1bmRlciBTQ01JDQo+PiBt YW5hZ2VtZW50IChub3Qgb25seSB0aG9zZSB3aGljaCBhcmUgYmVoaW5kIElPTU1VKS4NCj4+DQo+ PiBBZGRpdGlvbmFsbHksIHRoaXMgcGF0Y2ggYWRkcyBkb2N1bWVudGF0aW9uIGZvciB0aGUgcHJl LWV4aXN0aW5nDQo+PiBzY21pLXNtYy1wYXNzdGhyb3VnaCBjb21tYW5kIGxpbmUgb3B0aW9uLCB3 aGljaCB3YXMgcHJldmlvdXNseQ0KPj4gdW5kb2N1bWVudGVkLg0KPj4NCj4+IFswXSBodHRwczov L2RldmVsb3Blci5hcm0uY29tL2RvY3VtZW50YXRpb24vZGVuMDA1Ng0KPj4gWzFdIGh0dHBzOi8v d2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51 eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvZmlybXdhcmUvYXJt LHNjbWkueWFtbA0KPj4gWzJdIGh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGlu dXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2Rldmlj ZXRyZWUvYmluZGluZ3MvYWNjZXNzLWNvbnRyb2xsZXJzL2FjY2Vzcy1jb250cm9sbGVycy55YW1s DQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFz aGtvQGVwYW0uY29tPg0KPj4gU2lnbmVkLW9mZi1ieTogT2xla3NpaSBNb2lzaWVpZXYgPG9sZWtz aWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4gLS0tDQo+Pg0KPj4gQ2hhbmdlcyBpbiB2MTM6DQo+ PiAtIGZpeCB0eXBvIGluIGNvbW1pdCBkZXNjcmlwdGlvbg0KPj4NCj4+IENoYW5nZXMgaW4gdjEy Og0KPj4gLSByZWJhc2UgdG8gdGhlIGxhdGVzdCBzdGFnaW5nDQo+PiAtIHJldHVybiBFSU5WQUwg aWYgeGVuLHNjaV90eXBlPXNjbWlfc21jX211bHRpYWdlbnQgd2FzIHNldCBidXQNCj4+IENPTkZJ R19TQ01JX1NNQ19NQSBub3Qgc2V0DQo+PiAtIHB1dCBhcm1fc2NpX2FnZW50X2lkIGFmdGVyIHY4 cl9lbDFfbXNhIGFuZCBiZWZvcmUgcGFkIHRvIHByZXNlcnZlDQo+PiBvcmRlci4gUmVkdWNlZCBw YWQgZnJvbSB1aW50MTZfdCB0byB1aW50OF90IHRvIGZpbGwgdGhlIGdhcCAod2FzIDINCj4+IGJ5 dGVzIGJlZm9yZSBhZGRpbmcgYXJtX3NjaV9hZ2VudF9pZCBhbmQgbGVmdCBvbmx5IDEsIHNvIHVz ZWQgdWludDhfdA0KPj4gdG8gcHJlc2VydmUgc3RydWN0dXJlIHNpemUpDQo+PiAtIGZpeCBzY21p X2hhbmRsZV9jYWxsIHRvIHVzZSBhcm1fc21jY2NfZ3Vlc3Rfc21jIGhlbHBlciBmdW5jdGlvbg0K Pj4gLSB1cGRhdGUgc2VuZF9zbWNfbWVzc2FnZSBmdW5jdGlvbiB0byB1c2UgbmV3IGZvcm1hdCBv Zg0KPj4gYXJtX3NtY2NjXzFfMV9zbWMNCj4+IC0gZ3VhcmQgdGhlIERvbTAgU0NNSSBhZ2VudCBp ZCBzZXR1cCBpbiBjcmVhdGVfZG9tMCgpIGFuZCBNQSByZWxhdGVkDQo+PiBmdW5jaXRvbnMgd2l0 aCBDT05GSUdfU0NNSV9TTUNfTUENCj4+IC0gZml4IHRoZSB4ZW5fc2NtaV9jb25maWcgZXhhbXBs ZSBpbiBib290aW5nLnR4dCwgd2hpY2ggcGxhY2VkIHByb3BlcnRpZXMNCj4+IGFmdGVyIHN1Ym5v ZGVzIGFuZCB3YXMgcmVqZWN0ZWQgYnkgZHRjIHdpdGggIlByb3BlcnRpZXMgbXVzdCBwcmVjZWRl DQo+PiBzdWJub2RlcyINCj4+DQo+PiBDaGFuZ2VzIGluIHYxMDoNCj4+IC0gRml4IHRhYnMgaW4g TUFJTlRBSU5FUlMgZmlsZQ0KPj4gLSByZW1vdmUgZHVwbGljYXRlIFNQRFggdGFnIGZyb20gc2Nt aS1zaG1lbS5jDQo+PiAtIGFkZCBjYXN0IHRvIEFSTV9TTUNDQ19JTlZBTElEX1BBUkFNRVRFUiB0 byBzZXR0bGUgdGhlIHNpZ24gc2luY2UNCj4+IEFSTV9TTUNDQ19JTlZBTElEX1BBUkFNRVRFUiBp cyAtMyB3aGljaCBpcyBwYXJ0IG9mIHRoZSBzcGVjIGFuZCByZXNwDQo+PiBpcyB0aGUgZGVmYXVs dCBzbWNjYyBjYWxsIHN0cnVjdHVyZS4NCj4+IC0gdXBkYXRlIGZyZWVfY2hhbm5lbF9saXN0LiBB ZGQgc3BpbmxvY2sgdG8gYXZvaWQgcmFjZSBjb25kaXRpb24gYW5kDQo+PiBhIGNvbW1lbnQgd2l0 aCBhIGRlc2NyaXB0aW9uIG9mIHRoZSBmdW5jdGlvbiB3b3JrDQo+PiAtIHByZXNlcnZlIGVycm9y IG9mIHNtY19jcmVhdGVfY2hhbm5lbCBpbiBzY21pX3Byb2JlDQo+PiAtIGNoZWNrIHNjbWkgc2ht ZW0gYWRkcmVzcyBhbGlnbm1lbnQgYXMgd2VsIGFzIGl0IGlzIGRvbmUgZm9yIHNpemUNCj4+IC0g Y2hlY2sgZm9yIGQtPmFyY2guc2NpX2RhdGEgIT0gTlVMTCBpbiBzY21pX2hhbmRsZV9jYWxsDQo+ PiAtIHVzZSBTQ01JX1NITUVNX01BUFBFRCBzaXplIGZvciBpb21lbV9wZXJtaXRfYWNjZXNzDQo+ PiAtIGNoYW5nZSBsZW4gdHlwZSB0byB1bnNpZ25lZCBpbiBzaG1lbV97Z2V0fHB1dH1fbWVzc2Fn ZQ0KPj4gLSByZW5hbWUgc2htZW1fY2hhbm5lbF9pc19mcmVlIHRvIHNobWVtX2NoYW5uZWxfc3Rh dHVzDQo+PiAtIGFkZCBjb21tZW50IGFib3V0IHNraXBwaW5nIG1lc3NhZ2Ugc3RhdHVzIHdoZW4g Z2V0dGluZyBtZXNzYWdlIHJlc3BvbnNlDQo+PiAtIFNldCBjb3JyZWN0IGFnZW50X2lkIHJhbmdl cyBmb3IgZG9tMGxlc3MgYW5kIGEgdG9vbHN0YWNrLiBBZ2VudF9pZCAwDQo+PiBpcyBub3QgYmlu ZGVkIGZvciBkb20wIHNvIGNhbiBiZSByZXVzZWQuIEFsc28gbWVudGlvbmVkIHRoYXQNCj4+IFVJ TlQ4X01BWCAoMjU1KSBpcyB0cmVhdGVkIGFzIGludmFsaWQgYWdlbnRfaWQuDQo+PiAtIFNwbGl0 IGh5cGVydmlzb3IgYW5kIHRvb2xzdGFjayBjaGFuZ2VzIGludG8gc2VwYXJhdGUgY29tbWl0cw0K Pj4gLSBtb3ZlIGluaXQgbGlzdCBhbmQgc3BpbiBpbml0IGFmdGVyIGluaXRpYWwgY2hlY2tzIGlu IHByb2JlIGNhbGwNCj4+IC0gZml4IHR5cG8gaW4gY29tbWVudHMNCj4+IC0gY2xlYW4gcmVzb3Vy Y2VzIHdoZW4gc2NpX3JlZ2lzdGVyIHJldHVybnMgYW4gZXJyb3IuDQo+Pg0KPj4gQ2hhbmdlcyBp biB2OToNCj4+IC0gc29ydCBhbmQgcmVmYWN0b3IgTUFJTlRBSU5FUlMgZW50aWVzDQo+PiAtIHJl bW92ZSBTcHVyaW91cyBjaGFuZ2VzDQo+PiAtIGFkZCBleHRyYSBjaGVjayB0byBhdm9pZCBBU1NF UlQgd2hlbiBjYWxsaW5nIHVubWFwX2NoYW5uZWxfbWVtb3J5DQo+PiBmcm9tIGFzc2lnbiBkZXZp Y2UgbWV0aG9kDQo+PiAtIHNldCBjb3JyZWN0IHR4IGZsYWcgdG8gU0NNSV9CQVNFX0FHRU5UX1BF Uk1JU1NJT05TX1JFU0VUIHdoZW4NCj4+IGZyZWVpbmcgcmVzb3VyY2VzLiBGbGFnIHNob3VsZCBi ZSBzZXQgdG8gMSBhY2NvcmRpbmcgdG8gdGhlDQo+PiBzZWN0aW9uIDQuMi4yLjEyIFswXS4NCj4+ IC0gZml4IGR0IG5vZGUgY29wbWFyaW5nDQo+PiAtIG1vdmVkIGNoYW5uZWwtPnNobWVtIGNoZWNr IGZyb20gQVNTRVJUIGluIHVubWFwX21lbW9yeV9jaGFubmVsIHRvDQo+PiAiaWYiIHN0YXRlbWVu dC4gVGhpcyB3aWxsIHByZXZlbnQgZmlyaW5nIEFTU0VSVCBpZg0KPj4gdW5tYXBfY2hhbm5lbF9t ZW1vcnkgd2FzIGNhbGxlZCB0d2ljZSBvbiB0aGUgc2FtZSBjaGFubmVsLg0KPj4NCj4+IENoYW5n ZXMgaW4gdjg6DQo+PiAtIHVwZGF0ZSB4ZW5fc2NtaSBmdW5jX2lkIGluIGNvbW1pdCBkZXNjcmlw dGlvbg0KPj4gLSB1cGRhdGVkIGRvY3VtZW50YXRpb24gd2l0aCB0aGUgbmV3IERUIGZvcm1hdA0K Pj4gLSB1cGRhdGVkIG9wdF9kb20wX3NjbWlfYWdlbnRfaWQgc2V0dGluZyB0byBhdm9pZCBpdCB0 byBiZSBlcXVhbA0KPj4gU0NNSV9BR0VOVF9JRF9JTlZBTElELg0KPj4gLSBjaGFuZ2VkIFNDTUlf QUdFTlRfSURfSU5WQUxJRCBmcm9tIDB4ZmYgdG8gVUlOVDhfTUFYIHdoaWNoIG1ha2VzDQo+PiBj b2RlIG1vcmUgY2xlYXIgc2hvd2luZyB0aGF0IFVJTlQ4X01BWCBpcyB0aGVhdGVkIGxpa2UgaW52 YWxpZA0KPj4gYWdlbnRfaWQgYW5kIGNvdWxkbid0IGJlIHVzZWQuIEFsc28gZXhjbHVkZWQgU0NN SV9BR0VOVF9JRF9JTlZBTElEDQo+PiBmcm9tIGFjY2VwdGFibGUgdmFsdWUgcmFuZ2UNCj4+IC0g cmVtb3ZlIG91dGRhdGVkIHhlbixjb25maWcgcHJvcGVydHkgaWdub3JlLCBhZGRlZCB4ZW4sc2Np IGNvbXBhdGlibGUNCj4+IHRvIHNraXBfbWF0Y2hlcyBpbiBoYW5kbGVfbm9kZQ0KPj4gLSBhZGQg ZG9jdW1lbnRhdGlvbiBmb3IgcHJlLWV4aXN0aW5nIHNjbWktc21jLXBhc3N0aHJvdWdoIGNvbW1h bmQgbGluZQ0KPj4gb3B0aW9uIGluIGFscGhhYmV0aWNhbGx5IGNvcnJlY3QgbG9jYXRpb24gKGlu ICdzJyBzZWN0aW9uKQ0KPj4gLSBhZGQgbm90ZSB0byBjb21taXQgZGVzY3JpcHRpb24gYWJvdXQg ZG9jdW1lbnRhdGlvbiBmb3IgcHJldmlvdXNseQ0KPj4gdW5kb2N1bWVudGVkIHNjbWktc21jLXBh c3N0aHJvdWdoDQo+PiAtIEZpeCBTTUMgSURzIGluIERUIGV4YW1wbGVzIChYZW4gbWFuYWdlbWVu dCB1c2VzIDB4ODIwMDAwMDMsIERvbTAgdXNlcyAweDgyMDAwMDAyKQ0KPj4gLSBBZGQgZXhwbGlj aXQgbm90ZSBleHBsYWluaW5nIHdoeSBEb20wIGFuZCBYZW4gY2hhbm5lbHMgZG8gbm90IGNvbmZs aWN0DQo+PiAtIERvY3VtZW50IGRvbTBsZXNzIG11bHRpLWFnZW50IGNvbmZpZ3VyYXRpb24gZXhh bXBsZSAoeGVuLHNjaV90eXBlIC8geGVuLHNjaS1hZ2VudC1pZCkNCj4+IC0gQWRkIHNjbWlfeGVu IG5vZGUgdG8gYWdlbnQtZGlzY292ZXJ5IGV4YW1wbGUgd2l0aCAjc2NtaS1zZWNvbmRhcnktYWdl bnRzLWNlbGxzID0gMg0KPj4gLSBEcm9wIGRvbTA9c2NpLWFnZW50LWlkIGNvbW1hbmQgbGluZSBo YW5kbGluZzsgRG9tMCBTQ01JIGlzIG5vdyBlbmFibGVkIHZpYQ0KPj4gICAgeGVuLGRvbTAtc2Np LWFnZW50LWlkIGluIHRoZSB4ZW4sc2NpIERUIGNvbnRhaW5lcg0KPj4gLSBSZWZyZXNoIGRvY3Mg YW5kIGV4YW1wbGVzIHRvIG1lbnRpb24gdGhlIERUIHByb3BlcnR5IGluc3RlYWQgb2YgdGhlIGNt ZGxpbmUgb3B0aW9uDQo+Pg0KPj4gQ2hhbmdlcyBpbiB2NzoNCj4+IC0gcmV3b3JrIHNjbWkgbm9k ZXMgZm9yIHhlbiB0byBtYXRjaCBvbiBjb21wYXRpYmxlIHN0cmluZyBpbnN0ZWFkIG9mDQo+PiB0 aGUgZGlyZWN0IHBhdGgNCj4+DQo+PiBDaGFuZ2VzIGluIHY2Og0KPj4gLSB1cGRhdGVkIHNjbWkt c2htZW0gdG8gdXNlIGlvLmggZnJvbSBnZW5lcmljIGxvY2F0aW9uDQo+PiAtIHVwZGF0ZSBzY21p X2FnZW50X2lkIHBhcmFtZXRlciB0byBiZSBwcm92aWRlZCBpbnNpZGUgZG9tMD0gcGFyYW1ldGVy DQo+PiBsaXN0IGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgZm9ybWF0ICJkb20wPXNjaS1hZ2VudC1p ZD0wIg0KPj4gVGhpcyBjaGFuZ2Ugd2FzIGRvbmUgYXMgYSByZXNwb25zZSBmb3IgU3RlZmFubyBj b21tZW50IGFuZA0KPj4gcmVxdWlyZXMgYSBsb3Qgb2YgY29kZSBjaGFuZ2VzLCBidXQgcHJvZHVj ZXMgbXVjaCBjbGVhbmVyIHNvbHV0aW9uDQo+PiB0aGF0J3Mgd2h5IEkndmUgYWRkZWQgaXQgdG8g dGhlIGNvZGUuDQo+PiAtIGZpeCBmaWxlIGNvbW1lbnRzIGFuZCByZXR1cm4gY29kZXMNCj4+IC0g Zml4IGxlbmdodCBjaGVja3MgaW4gc2htZW1fe2dldCxwdXR9X21lc3NhZ2UgdG8gdXNlIG9mZnNl dG9mDQo+PiAtIHJlbW92ZSBsZW4gbWVtYmVyIGZyb20gc2NtaV9jaGFubmVsIHN0cnVjdHVyZSBh cyBpdCBpcyBub3QgdXNlZA0KPj4gLSBzZXQgc2NtaS1zZWNvbmRhcnktYWdlbnRzIHByb3BlcnR5 IHRvIGJlIG1hbmRhdG9yeSBzaW5jZSBpZiBubw0KPj4gc2Vjb25kYXJ5IGFnZW50cyB3ZXJlIHBy b3ZpZGVkIHRoZW4gdGhlcmUgaXMgbm8gc2VuY2UgdG8gZW5hYmxlIHNjbWkNCj4+IHdoZW4gbm8g c2Vjb25kYXJ5IGFnZW50cyBhcmUgcG9wdWxhdGVkIHRvIHRoZSBEb21haW5zDQo+PiAtIHVwZGF0 ZSBkb2N1bWVudGF0aW9uIGluIGJvb3RpbmcudHh0LCBhZGRlZCB4ZW5fc2NtaSBub2RlIHRvIHRo ZQ0KPj4gZXhhbXBsZQ0KPj4gLSBhZGp1c3QgZC0+YXJjaC5zY2lfZW5hYmxlZCB2YWx1ZSBpbiBz Y21pX2RvbWFpbl9kZXN0cm95DQo+PiAtIGZpeCBsb2NrIG1hbmFnZW1lbnQgaW4gc21jX2NyZWF0 ZV9jaGFubmVsIGNhbGwNCj4+IC0gYXZvaWQgZXh0cmEgbWFwX2NoYW5uZWxfbWVtb3J5IGNvbW1h bmQgZm9yIFhlbiBtYW5hZ2VtZW50IGNoYW5uZWwNCj4+IGJlY2F1c2UgY29sbGVjdF9hZ2VudF9p ZCBjYWxsIHVubWFwcyBtZW1vcnkgaWYgRE9NSURfWEVOIGlzIG5vdA0KPj4gc2V0LiBTbyBmb3Ig WGVuIG1hbmFnZW1lbnQgY2hhbm5lbCB3ZSBjYW4gaW5pdCBkb21haW5faWQgYWQgRE9NSURfWEVO DQo+PiBiZWZvcmUgY2FsbGluZyBjb2xsZWN0X2FnZW50X2lkIHNvIG1lbW9yeSBzaG91bGRuJ3Qg YmUgdW5tYXBwZWQuDQo+Pg0KPj4gQ2hhbmdlcyBpbiB2NToNCj4+IC0gZml4IGRldmljZS10cmVl IGV4YW1wbGUgZm9ybWF0IGluIGJvb3RpbmcudHh0LCBhZGRlZCAiOyIgYWZ0ZXIgIn0iLg0KPj4g LSB1cGRhdGUgZGVmaW5lIGluIHNjbWktcHJvdG8uaA0KPj4gLSB1cGRhdGUgZGVmaW5lIGluIHNj bWktc2htZW0uaCBmaWxlDQo+PiAtIHNjbWlfYXNzaWduX2RldmljZSAtIGRvIG5vdCBpZ25vcmUg LUVPUE5PVFNVUFAgcmV0dXJuDQo+PiBjb2RlIG9mIHRoZSBkb19zbWNfeGZlcg0KPj4gLSByZW1v dmUgb3ZlcndyaXRpbmcgYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQgYWZ0ZXINCj4+IFNDTUlfQkFT RV9ESVNDT1ZFUl9BR0VOVCBjYWxsDQo+PiAtIGFkZCBtdWx0aS1hZ2VudCBmaWxlcyB0byB0aGUg TUFJTlRBSU5FUlMNCj4+IC0gYWRkIFNDTUkgbXVsdGktYWdlbnQgZGVzY3JpcHRpb24gdG8gdGhl IFNVUFBPUlQubWQNCj4+IC0gaGFuZGxlIEFSTV9TTUNDQ19JTlZBTElEX1BBUkFNRVRFUiByZXR1 cm4gY29kZSBhbmQgcmV0dXJuIC1FSU5WQUwNCj4+IGZvciBzbWMgY2FsbA0KPj4gLSB1cGRhdGVk IGNvbGxlY3RfYWdlbnRzIGZ1bmN0aW9uLiBTZXQgYWdlbnRfaWQgcGFyYW1ldGVyIGFzIG9wdGlv bmFsDQo+PiBpbiBzY21pLXNlY29uZGFyeS1hZ2VudHMgZGV2aWNlLXRyZWUgcHJvcGVydHkNCj4+ IC0gaW50cm9kdWNlICIjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzIiBwYXJhbWV0ZXIgdG8g c2V0IGlmDQo+PiBhZ2VudF9pZCB3YXMgcHJvdmlkZWQNCj4+IC0gcmVhbm1lIHhlbixzY21pLXNl Y29uZGFyeS1hZ2VudHMgcHJvcGVydHkgdG8gc2NtaS1zZWNvbmRhcnktYWdlbnRzDQo+PiAtIG1v dmUgbWVtY3B1X3RvaW8vZnJvbWlvIGZvciB0aGUgZ2VuZXJpYyBwbGFjZQ0KPj4gLSB1cGRhdGUg WGVuIHRvIGdldCBtYW5hZ2VtZW50IGNoYW5uZWwgZnJvbSAvY2hvc2VuL3hlbixjb25maWcgbm9k ZQ0KPj4gLSBnZXQgaHlwZXJ2aXNvciBjaGFubm5lbCBmcm9tIG5vZGUgaW5zdGVhZCBvZiB1c2lu ZyBoYXJkY29kZWQNCj4+IC0gdXBkYXRlIGhhbmRsaW5nIHNjbWkgYW5kIHNobWVtIG5vZGVzIGZv ciB0aGUgZG9tYWluDQo+PiAtIFNldCBtdWx0aS1hZ2VudCBkcml2ZXIgdG8gc3VwcG9ydCBvbmx5 IEFybTY0DQo+Pg0KPj4gQ2hhbmdlcyBpbiB2NDoNCj4+IC0gdG9vbHN0YWNrIGNvbW1lbnRzIGZy b20gQW50aG9ueSBQRVJBUkQNCj4+IC0gYWRkZWQgZG9tMGxlc3Mgc3VwcG9ydA0KPj4gLSBhZGRl ZCBkb2MgZm9yICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIg0KPj4NCj4+ICAgTUFJTlRBSU5F UlMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQo+PiAgIFNVUFBPUlQu bWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgMTEgKw0KPj4gICBkb2NzL21p c2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0ICAgICAgIHwgMTk3ICsrKysrDQo+PiAgIHhl bi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jICAgICAgICAgICAgICAgfCAgMTcgKw0KPj4gICB4 ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAgICAgICAgICAgIHwgIDQzICsrDQo+PiAg IHhlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnICAgICAgICAgICAgICAgfCAgMTIgKw0KPj4g ICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvTWFrZWZpbGUgICAgICAgICAgICAgIHwgICAxICsNCj4+ ICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaCAgICAgICAgICB8IDE2NCArKysr DQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMgICAgICAgICAgfCAxMTgg KysrDQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmggICAgICAgICAgfCAg NDUgKysNCj4+ICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYyB8 IDgxNiArKysrKysrKysrKysrKysrKysrKw0KPj4gICB4ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1h cm0uaCAgICAgICAgICAgICAgIHwgICA1ICstDQo+PiAgIDEyIGZpbGVzIGNoYW5nZWQsIDE0Mjkg aW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVu L2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaA0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQg eGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4gICBjcmVhdGUgbW9kZSAxMDA2 NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaA0KPj4gICBjcmVhdGUgbW9kZSAx MDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYw0KPj4NCj4+ IGRpZmYgLS1naXQgYS9NQUlOVEFJTkVSUyBiL01BSU5UQUlORVJTDQo+PiBpbmRleCBjNjBhZmM5 M2E1Li5jZDZkMTI0M2JkIDEwMDY0NA0KPj4gLS0tIGEvTUFJTlRBSU5FUlMNCj4+ICsrKyBiL01B SU5UQUlORVJTDQo+PiBAQCAtNTM0LDYgKzUzNCw3IEBAIFNDSSBNRURJQVRPUlMNCj4+ICAgUjog T2xla3NpaSBNb2lzaWVpZXYgPG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4gICBTOiBT dXBwb3J0ZWQNCj4+ICAgRjogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+PiArRjogIHhl bi9hcmNoL2FybS9maXJtd2FyZS9zY21pLSouW2NoXQ0KPj4gICBGOiB4ZW4vYXJjaC9hcm0vaW5j bHVkZS9hc20vZmlybXdhcmUvc2NpLmgNCj4+DQo+PiAgIFNFQUJJT1MgVVBTVFJFQU0NCj4+IGRp ZmYgLS1naXQgYS9TVVBQT1JULm1kIGIvU1VQUE9SVC5tZA0KPj4gaW5kZXggZWIwNzMzMjQ2Mi4u ZGM0MWE2YjJmMyAxMDA2NDQNCj4+IC0tLSBhL1NVUFBPUlQubWQNCj4+ICsrKyBiL1NVUFBPUlQu bWQNCj4+IEBAIC05NzIsNiArOTcyLDE3IEBAIGJ5IGh3ZG9tLiBTb21lIHBsYXRmb3JtcyB1c2Ug U0NNSSBmb3IgYWNjZXNzIHRvIHN5c3RlbS1sZXZlbCByZXNvdXJjZXMuDQo+Pg0KPj4gICAgICAg U3RhdHVzOiBTdXBwb3J0ZWQNCj4+DQo+PiArIyMjIEFybTogU0NNSSBTTUMgbXVsdGktYWdlbnQg c3VwcG9ydA0KPj4gKw0KPj4gK0VuYWJsZSBzdXBwb3J0IGZvciB0aGUgbXVsdGktYWdlbnQgY29u ZmlndXJhdGlvbiBvZiB0aGUgRUwzIEZpcm13YXJlLCB3aGljaA0KPj4gK2FsbG93cyBYZW4gdG8g cHJvdmlkZSBhbiBTQ01JIGludGVyZmFjZSB0byB0aGUgRG9tYWlucy4NCj4+ICtYZW4gbWFuYWdl cyBhY2Nlc3MgcGVybWlzc2lvbnMgdG8gdGhlIEhXIHJlc291cmNlcyBhbmQgcHJvdmlkZXMgYW4g U0NNSSBpbnRlcmZhY2UNCj4+ICt0byB0aGUgRG9tYWlucy4gRWFjaCBEb21haW4gaXMgcmVwcmVz ZW50ZWQgYXMgYSBzZXBhcmF0ZSBBZ2VudCwgd2hpY2ggY2FuDQo+PiArY29tbXVuaWNhdGUgd2l0 aCBFTDMgRmlybXdhcmUgdXNpbmcgYSBkZWRpY2F0ZWQgc2hhcmVkIG1lbW9yeSByZWdpb24sIGFu ZA0KPj4gK25vdGlmaWNhdGlvbnMgYXJlIHBhc3NlZCB0aHJvdWdoIGJ5IFhlbi4NCj4+ICsNCj4+ ICsgICAgU3RhdHVzLCBBUk02NDogVGVjaCBQcmV2aWV3DQo+PiArDQo+PiAgICMjIyBBUk06IEd1 ZXN0IFBTQ0kgc3VwcG9ydA0KPj4NCj4+ICAgRW11bGF0ZWQgUFNDSSBpbnRlcmZhY2UgZXhwb3Nl ZCB0byBndWVzdHMuIFdlIHN1cHBvcnQgYWxsIG1hbmRhdG9yeQ0KPj4gZGlmZiAtLWdpdCBhL2Rv Y3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQgYi9kb2NzL21pc2MvYXJtL2Rldmlj ZS10cmVlL2Jvb3RpbmcudHh0DQo+PiBpbmRleCBiY2IwNmJjNzk2Li4xZDAzODJhODY1IDEwMDY0 NA0KPj4gLS0tIGEvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KPj4gKysr IGIvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KPj4gQEAgLTMzMSw2ICsz MzEsMjEgQEAgd2l0aCB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6DQo+PiAgICAgICBTaG91bGQg YmUgdXNlZCB0b2dldGhlciB3aXRoIHNjbWktc21jLXBhc3N0aHJvdWdoIFhlbiBjb21tYW5kIGxp bmUNCj4+ICAgICAgIG9wdGlvbi4NCj4+DQo+PiArICAgIC0gInNjbWlfc21jX211bHRpYWdlbnQi DQo+PiArDQo+PiArICAgIEVuYWJsZXMgQVJNIFNDTUkgU01DIG11bHRpLWFnZW50IHN1cHBvcnQg Zm9yIHRoZSBndWVzdCBieSBlbmFibGluZyBTQ01JIG92ZXINCj4+ICsgICAgU01DIGNhbGxzIGZv cndhcmRpbmcgZnJvbSBkb21haW4gdG8gdGhlIEVMMyBmaXJtd2FyZSAobGlrZSBBUk0NCj4+ICsg ICAgVHJ1c3RlZCBGaXJtd2FyZS1BKSB3aXRoIGEgbXVsdGkgU0NNSSBPU1BNIGFnZW50IHN1cHBv cnQuDQo+PiArICAgIFRoZSBTQ01JIGFnZW50X2lkIHNob3VsZCBiZSBzcGVjaWZpZWQgZm9yIHRo ZSBndWVzdCB3aXRoICJ4ZW4sc2NpLWFnZW50LWlkIg0KPj4gKyAgICBwcm9wZXJ0eS4NCj4+ICsN Cj4+ICstICJ4ZW4sc2NpLWFnZW50LWlkIg0KPj4gKw0KPj4gKyAgICBTcGVjaWZpZXMgQVJNIFND TUkgYWdlbnQgaWQgZm9yIHRoZSBndWVzdC4gVGhpcyBvcHRpb24gaXMgbWFuZGF0b3J5IGlmIHRo ZQ0KPj4gKyAgICBTQ01JIFNNQyAic2NtaV9zbWNfbXVsdGlhZ2VudCIgc3VwcG9ydCBpcyBlbmFi bGVkIGZvciB0aGUgZ3Vlc3QuIFRoZSBhZ2VudCBpZHMNCj4+ICsgICAgb2YgZ3Vlc3QgbXVzdCBi ZSB1bmlxdWUgYW5kIGluIHRoZSByYW5nZSBbMC4uMjU0XS4gVUlOVDhfTUFYICgyNTUpIGlzDQo+ PiArICAgIHRyZWF0ZWQgYXMgaW52YWxpZC4NCj4+ICsNCj4+ICAgLSB2OHJfZWwxX21zYQ0KPj4N Cj4+ICAgICAgIEEgc3RyaW5nIHByb3BlcnR5IHNwZWNpZnlpbmcgd2hldGhlciwgb24gQXJtdjgt UiBzeXN0ZW1zIGF0IEVMMSwgYSBkb21haW4NCj4+IEBAIC04NDcsMyArODYyLDE4NSBAQCBUaGUg YXV0b21hdGljYWxseSBhbGxvY2F0ZWQgc3RhdGljIHNoYXJlZCBtZW1vcnkgd2lsbCBnZXQgbWFw cGVkIGF0DQo+PiAgIDB4ODAwMDAwMDAgaW4gRG9tVTEgZ3Vlc3QgcGh5c2ljYWwgYWRkcmVzcyBz cGFjZSwgYW5kIGF0IDB4OTAwMDAwMDAgaW4gRG9tVTINCj4+ICAgZ3Vlc3QgcGh5c2ljYWwgYWRk cmVzcyBzcGFjZS4gRG9tVTEgaXMgZXhwbGljaXRseSBkZWZpbmVkIGFzIHRoZSBvd25lciBkb21h aW4sDQo+PiAgIGFuZCBEb21VMiBpcyB0aGUgYm9ycm93ZXIgZG9tYWluLg0KPj4gKw0KPj4gK1ND TUkgU01DIG11bHRpLWFnZW50IHN1cHBvcnQNCj4+ICs9PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQo+PiArDQo+PiArRm9yIGVuYWJsaW5nIHRoZSBBUk0gU0NNSSBTTUMgbXVsdGktYWdlbnQg c3VwcG9ydCAoZW5hYmxlZCBieSBDT05GSUdfU0NNSV9TTUNfTUEpDQo+PiArdGhlIFhlbiBzcGVj aWZpYyBTQ01JIEFnZW50J3MgY29uZmlndXJhdGlvbiBzaGFsbCBiZSBwcm92aWRlZCBpbiB0aGUg SG9zdCBEVA0KPj4gK2FjY29yZGluZyB0byB0aGUgU0NNSSBjb21wbGlhbnQgRUwzIEZpcm13YXJl IHNwZWNpZmljYXRpb24gd2l0aCBBUk0gU01DL0hWQw0KPj4gK3RyYW5zcG9ydC4gVGhlIFNDTUkg Y29uZmlndXJhdGlvbiBtdXN0IGxpdmUgdW5kZXIgdGhlIFhlbiBTQ01JIGNvbnRhaW5lcg0KPj4g KyJ4ZW4sc2NpIiBiZW5lYXRoICIvY2hvc2VuIiAoZm9yIGV4YW1wbGUgIi9jaG9zZW4veGVuL3hl bl9zY21pX2NvbmZpZy9zY21pIikuIFRoZQ0KPj4gK1hlbiBTQ01JIG1lZGlhdG9yIHdpbGwgYmlu ZCBvbmx5IHRvIHRoZSAiYXJtLHNjbWktc21jIiBub2RlIHRoYXQgaXMgYSBjaGlsZCBvZg0KPj4g K3RoaXMgInhlbixzY2kiIGNvbnRhaW5lcjsgYW55IG90aGVyICJhcm0sc2NtaS1zbWMiIG5vZGVz IChmb3IgZXhhbXBsZSB1bmRlcg0KPj4gKyIvZmlybXdhcmUiKSBhcmUgaWdub3JlZCB0byBhdm9p ZCBzdGVhbGluZyB0aGUgaG9zdCdzIFNDTUkgT1NQTSBpbnN0YW5jZS4NCj4+ICsNCj4+ICstIHNj bWktc2Vjb25kYXJ5LWFnZW50cw0KPj4gKw0KPj4gKyAgICBEZWZpbmVzIGEgc2V0IG9mIFNDTUkg YWdlbnRzIGNvbmZpZ3VyYXRpb24gc3VwcG9ydGVkIGJ5IFNDTUkgRUwzIEZXIGFuZA0KPj4gKyAg ICBhdmFpbGFibGUgZm9yIFhlbi4gRWFjaCBBZ2VudCBkZWZpbmVkIGFzIHRyaXBsZSBjb25zaXN0 aW5nIG9mOg0KPj4gKyAgICBTTUMvSFZDIGZ1bmN0aW9uX2lkIGFzc2lnbmVkIGZvciB0aGUgYWdl bnQgdHJhbnNwb3J0ICgiYXJtLHNtYy1pZCIpLA0KPj4gKyAgICBwaGFuZGxlIHRvIFNDTUkgU0hN IGFzc2lnbmVkIGZvciB0aGUgYWdlbnQgdHJhbnNwb3J0ICgiYXJtLHNjbWktc2htZW0iKSwNCj4+ ICsgICAgU0NNSSBhZ2VudF9pZCAob3B0aW9uYWwpIGlmIG5vdCBzZXQgLSBYZW4gd2lsbCBkZXRl cm1pbmUgQWdlbnQgSUQgZm9yDQo+PiArICAgIGVhY2ggcHJvdmlkZWQgY2hhbm5lbCB1c2luZyBC QVNFX0RJU0NPVkVSX0FHRU5UIG1lc3NhZ2UuDQo+PiArDQo+PiArLSB4ZW4sZG9tMC1zY2ktYWdl bnQtaWQNCj4+ICsNCj4+ICsgICAgT3B0aW9uYWwuIFNwZWNpZmllcyB0aGUgRG9tMC9od2RvbSBT Q01JIGFnZW50X2lkIGluc2lkZSB0aGUgYGB4ZW4sc2NpYGANCj4+ICsgICAgY29udGFpbmVyLiBX aGVuIHByb3ZpZGVkLCBEb20wIHdpbGwgYmUgY29uZmlndXJlZCBmb3IgU0NNSSBtdWx0aS1hZ2Vu dA0KPj4gKyAgICBzdXBwb3J0OyB3aGVuIG9taXR0ZWQsIFNDTUkgcmVtYWlucyBkaXNhYmxlZCBm b3IgRG9tMC4gVGhlIHZhbHVlIG11c3QNCj4+ICsgICAgbWF0Y2ggdGhlIGBgZnVuY19pZGBgIGFu ZCBzaG1lbSBwYWlyaW5nIHRoYXQgRUwzIGZpcm13YXJlIGV4cG9zZXMgZm9yDQo+PiArICAgIERv bTAgKGZvciBleGFtcGxlIHZpYSBgYC9maXJtd2FyZS9zY21pYGApLg0KPj4gKw0KPj4gK0FzIGFu IGV4YW1wbGU6DQo+PiArDQo+PiArLyB7DQo+PiArICAgIGNob3NlbiB7DQo+PiArICAgICAgICB4 ZW4gew0KPj4gKyAgICAgICAgICAgIHJhbmdlczsNCj4+ICsgICAgICAgICAgICB4ZW5fc2NtaV9j b25maWcgew0KPj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gInhlbixzY2kiOw0KPj4g KyAgICAgICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwyPjsNCj4+ICsgICAgICAgICAgICAg ICAgI3NpemUtY2VsbHMgPSA8Mj47DQo+PiArICAgICAgICAgICAgICAgIHJhbmdlczsNCj4+ICsN Cj4+ICsgICAgICAgICAgICAgICAgeGVuLGRvbTAtc2NpLWFnZW50LWlkID0gPDA+OyA8LS0tIGRv bTAgYWdlbnQgaWQNCj4+ICsgICAgICAgICAgICAgICAgc2NtaS1zZWNvbmRhcnktYWdlbnRzID0g PA0KPj4gKyAgICAgICAgICAgICAgICAgICAgMHg4MjAwMDAwMiAmc2NtaV9zaG1fMCAwDQo+PiAr ICAgICAgICAgICAgICAgICAgICAweDgyMDAwMDA0ICZzY21pX3NobV8yIDINCj4+ICsgICAgICAg ICAgICAgICAgICAgIDB4ODIwMDAwMDUgJnNjbWlfc2htXzMgMz47IDwtLS0gZnVuY19pZCwgc2ht ZW0sIGFnZW50X2lkDQo+PiArICAgICAgICAgICAgICAgICNzY21pLXNlY29uZGFyeS1hZ2VudHMt Y2VsbHMgPSA8Mz47DQo+PiArDQo+PiArICAgICAgICAgICAgICAgIHNjbWlfc2htXzA6IHNyYW1A NDdmZjAwMDAgew0KPj4gKyAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2Nt aS1zaG1lbSI7DQo+PiArICAgICAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjAwMDAg MHgwIDB4MTAwMD47DQo+PiArICAgICAgICAgICAgICAgIH07DQo+PiArDQo+PiArICAgICAgICAg ICAgICAgIC8qIFhlbiBTQ01JIG1hbmFnZW1lbnQgY2hhbm5lbCAqLw0KPj4gKyAgICAgICAgICAg ICAgICBzY21pX3NobV8xOiBzcmFtQDQ3ZmYxMDAwIHsNCj4+ICsgICAgICAgICAgICAgICAgICAg IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICAgICAg cmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgICAgICAgICB9 Ow0KPj4gKw0KPj4gKyAgICAgICAgICAgICAgICBzY21pX3NobV8yOiBzcmFtQDQ3ZmYyMDAwIHsN Cj4+ICsgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0K Pj4gKyAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYyMDAwIDB4MCAweDEwMDA+ Ow0KPj4gKyAgICAgICAgICAgICAgICB9Ow0KPj4gKw0KPj4gKyAgICAgICAgICAgICAgICBzY21p X3NobV8zOiBzcmFtQDQ3ZmYzMDAwIHsNCj4+ICsgICAgICAgICAgICAgICAgICAgIGNvbXBhdGli bGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4 MCAweDQ3ZmYzMDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgICAgICAgICB9Ow0KPj4gKw0K Pj4gKyAgICAgICAgICAgICAgICBzY21pX3hlbjogc2NtaSB7DQo+PiArICAgICAgICAgICAgICAg ICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNtYyI7DQo+PiArICAgICAgICAgICAgICAgICAg ICBhcm0sc21jLWlkID0gPDB4ODIwMDAwMDM+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IGZ1 bmNfaWQNCj4+ICsgICAgICAgICAgICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPDE+Ow0KPj4g KyAgICAgICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8MD47DQo+PiArICAgICAgICAgICAg ICAgICAgICAjYWNjZXNzLWNvbnRyb2xsZXItY2VsbHMgPSA8MT47DQo+PiArICAgICAgICAgICAg ICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMT47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQg c2htZW0NCj4+ICsgICAgICAgICAgICAgICAgfTsNCj4+ICsgICAgICAgICAgICB9Ow0KPj4gKyAg ICAgICAgfTsNCj4+ICsgICAgfTsNCj4+ICt9Ow0KPj4gKw0KPj4gK05vdGU6IFRoaXMgZXhhbXBs ZSBrZWVwcyB0aGUgSG9zdCBEVCB1bmNoYW5nZWQgZm9yIERvbTAgYW5kIGJhcmVtZXRhbCBMaW51 eA0KPj4gK2J5IHVzaW5nIGZ1bmNfaWQgMHg4MjAwMDAwMiAvIHNobWVtIDB4NDdmZjAwMDAgZm9y IERvbTAsIHdoaWxlIFhlbiB1c2VzIGENCj4+ICtzZXBhcmF0ZSBwcml2aWxlZ2VkIGNoYW5uZWwg ZnVuY19pZCAweDgyMDAwMDAzIC8gc2htZW0gMHg0N2ZmMTAwMC4gRUwzDQo+PiArZmlybXdhcmUg ZW5mb3JjZXMgcGVybWlzc2lvbnMgcGVyIGFnZW50X2lkLCBzbyB0aGVyZSBpcyBubyBjb25mbGlj dCBiZXR3ZWVuDQo+PiArRG9tMCBhbmQgWGVuIGNoYW5uZWxzLg0KPj4gKw0KPj4gKy0gI3NjbWkt c2Vjb25kYXJ5LWFnZW50cy1jZWxscw0KPj4gKw0KPj4gKyAgICBEZWZpbmVzIHdoZXRoZXIgQWdl bnRfaWQgaXMgc2V0IGluIHRoZSAic2NtaS1zZWNvbmRhcnktYWdlbnRzIiBwcm9wZXJ0eS4NCj4+ ICsgICAgUG9zc2libGUgdmFsdWVzIGFyZTogMiwgMy4NCj4+ICsgICAgV2hlbiBzZXQgdG8gMyAo dGhlIGRlZmF1bHQpLCBleHBlY3QgYWdlbnRfaWQgdG8gYmUgcHJlc2VudCBpbiB0aGUgc2Vjb25k YXJ5DQo+PiArICAgIGFnZW50cyBsaXN0Lg0KPj4gKyAgICBXaGVuIHNldCB0byAyLCBhZ2VudF9p ZCB3aWxsIGJlIGRpc2NvdmVyZWQgZm9yIGVhY2ggY2hhbm5lbCB1c2luZw0KPj4gKyAgICBCQVNF X0RJU0NPVkVSX0FHRU5UIG1lc3NhZ2UuDQo+PiArDQo+PiArDQo+PiArRXhhbXBsZToNCj4+ICsN Cj4+ICsvIHsNCj4+ICsgICAgY2hvc2VuIHsNCj4+ICsgICAgICAgIHhlbiB7DQo+PiArICAgICAg ICAgICAgcmFuZ2VzOw0KPj4gKyAgICAgICAgICAgIHhlbl9zY21pX2NvbmZpZyB7DQo+PiArICAg ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAieGVuLHNjaSI7DQo+PiArICAgICAgICAgICAgICAg ICNhZGRyZXNzLWNlbGxzID0gPDI+Ow0KPj4gKyAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9 IDwyPjsNCj4+ICsgICAgICAgICAgICAgICAgcmFuZ2VzOw0KPj4gKw0KPj4gKyAgICAgICAgICAg ICAgICAvKiBTaGFyZWQgbWVtb3J5IG5vZGVzIGFzIGluIHRoZSBwcmV2aW91cyBleGFtcGxlICov DQo+PiArDQo+PiArICAgICAgICAgICAgICAgIHNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCj4+ ICsgICAgICAgICAgICAgICAgICAgIDB4ODIwMDAwMDIgJnNjbWlfc2htXzANCj4+ICsgICAgICAg ICAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2htXzINCj4+ICsgICAgICAgICAgICAgICAg ICAgIDB4ODIwMDAwMDUgJnNjbWlfc2htXzMNCj4+ICsgICAgICAgICAgICAgICAgICAgIDB4ODIw MDAwMDYgJnNjbWlfc2htXzQ+Ow0KPj4gKyAgICAgICAgICAgICAgICAjc2NtaS1zZWNvbmRhcnkt YWdlbnRzLWNlbGxzID0gPDI+Ow0KPj4gKw0KPj4gKyAgICAgICAgICAgICAgICBzY21pX3hlbjog c2NtaSB7DQo+PiArICAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNt YyI7DQo+PiArICAgICAgICAgICAgICAgICAgICBhcm0sc21jLWlkID0gPDB4ODIwMDAwMDM+OyA8 LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IGZ1bmNfaWQNCj4+ICsgICAgICAgICAgICAgICAgICAg ICNhZGRyZXNzLWNlbGxzID0gPDE+Ow0KPj4gKyAgICAgICAgICAgICAgICAgICAgI3NpemUtY2Vs bHMgPSA8MD47DQo+PiArICAgICAgICAgICAgICAgICAgICAjYWNjZXNzLWNvbnRyb2xsZXItY2Vs bHMgPSA8MT47DQo+PiArICAgICAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMT47 IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgc2htZW0NCj4+ICsgICAgICAgICAgICAgICAgfTsN Cj4+ICsgICAgICAgICAgICB9Ow0KPj4gKyAgICAgICAgfTsNCj4+ICsgICAgfTsNCj4+ICt9Ow0K Pj4gKw0KPj4gK0RvbTBsZXNzIGV4YW1wbGUgKG11bHRpLWFnZW50KQ0KPj4gKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ICsNCj4+ICtCZWxvdyBpcyBhIG1pbmltYWwgZG9tMGxl c3MgY29uZmlndXJhdGlvbiBzaG93aW5nIGhvdyB0byBlbmFibGUgU0NNSSBTTUMNCj4+ICttdWx0 aS1hZ2VudCBmb3IgYSBwcmUtZGVmaW5lZCBndWVzdCBkb21haW4gdXNpbmcgeGVuLHNjaV90eXBl IGFuZA0KPj4gK3hlbixzY2ktYWdlbnQtaWQsIHRvZ2V0aGVyIHdpdGggdGhlIFhlbiBTQ01JIGNv bnRhaW5lcjoNCj4+ICsNCj4+ICtjaG9zZW4gew0KPj4gKyAgICB4ZW4gew0KPj4gKyAgICAgICAg cmFuZ2VzOw0KPj4gKyAgICAgICAgeGVuX3NjbWlfY29uZmlnIHsNCj4+ICsgICAgICAgICAgICBj b21wYXRpYmxlID0gInhlbixzY2kiOw0KPj4gKyAgICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0g PDI+Ow0KPj4gKyAgICAgICAgICAgICNzaXplLWNlbGxzID0gPDI+Ow0KPj4gKyAgICAgICAgICAg IHJhbmdlczsNCj4+ICsNCj4+ICsgICAgICAgICAgICAvKiBYZW4gbWFuYWdlbWVudCBjaGFubmVs IHNoYXJlZCBtZW1vcnkgKi8NCj4+ICsgICAgICAgICAgICBzY21pX3NobV8xOiBzcmFtQDQ3ZmYx MDAwIHsNCj4+ICsgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7 DQo+PiArICAgICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMTAwMCAweDAgMHgxMDAwPjsN Cj4+ICsgICAgICAgICAgICB9Ow0KPj4gKw0KPj4gKyAgICAgICAgICAgIHNjbWlfc2htX2RvbXU6 IHNyYW1ANDdmZjIwMDAgew0KPj4gKyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz Y21pLXNobWVtIjsNCj4+ICsgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYyMDAwIDB4 MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgICAgIH07DQo+PiArDQo+PiArICAgICAgICAgICAgc2Nt aS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4gKyAgICAgICAgICAgICAgICAweDgyMDAwMDA0ICZz Y21pX3NobV9kb211IDI+Ow0KPj4gKyAgICAgICAgICAgICNzY21pLXNlY29uZGFyeS1hZ2VudHMt Y2VsbHMgPSA8Mz47DQo+PiArDQo+PiArICAgICAgICAgICAgc2NtaV94ZW46IHNjbWkgew0KPj4g KyAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNtYyI7DQo+PiArICAgICAg ICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMz47DQo+PiArICAgICAgICAgICAgICAg ICNhZGRyZXNzLWNlbGxzID0gPDE+Ow0KPj4gKyAgICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9 IDwwPjsNCj4+ICsgICAgICAgICAgICAgICAgI2FjY2Vzcy1jb250cm9sbGVyLWNlbGxzID0gPDE+ Ow0KPj4gKyAgICAgICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMT47DQo+PiArICAgICAg ICAgICAgfTsNCj4+ICsgICAgICAgIH07DQo+PiArICAgIH07DQo+PiArDQo+PiArICAgIHhlbixk b21haW5AMSB7DQo+PiArICAgICAgICBjb21wYXRpYmxlID0gInhlbixkb21haW4iOw0KPj4gKyAg ICAgICAgeGVuLHNjaV90eXBlID0gInNjbWlfc21jX211bHRpYWdlbnQiOw0KPj4gKyAgICAgICAg eGVuLHNjaS1hZ2VudC1pZCA9IDwyPjsNCj4+ICsgICAgICAgIC8qIEFkZGl0aW9uYWwgZG9tYWlu IHByb3BlcnRpZXMgKG1lbW9yeSwgY3B1cywga2VybmVscywgZXRjLikgKi8NCj4+ICsgICAgfTsN Cj4+ICt9Ow0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jIGIv eGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCj4+IGluZGV4IDNmNDhmNzQyMjYuLjUwZTI1 MTZiOWUgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KPj4g KysrIGIveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCj4+IEBAIC0yOTIsNiArMjkyLDIz IEBAIHN0YXRpYyBpbnQgX19pbml0IGRvbXVfZHRfc2NpX3BhcnNlKHN0cnVjdCBkdF9kZXZpY2Vf bm9kZSAqbm9kZSwNCj4+DQo+PiAgICAgICAgICAgZF9jZmctPmFyY2guYXJtX3NjaV90eXBlID0g WEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQzsNCj4+ICAgICAgIH0NCj4+ICsgICAg ZWxzZSBpZiAoICFzdHJjbXAoc2NpX3R5cGUsICJzY21pX3NtY19tdWx0aWFnZW50IikgKQ0KPj4g KyAgICB7DQo+PiArICAgICAgICB1aW50MzJfdCBhZ2VudF9pZCA9IDA7DQo+PiArDQo+PiArICAg ICAgICBpZiAoICFJU19FTkFCTEVEKENPTkZJR19TQ01JX1NNQ19NQSkgKQ0KPj4gKyAgICAgICAg ew0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4ZW4sc2NpX3R5cGU9c2NtaV9z bWNfbXVsdGlhZ2VudCByZXF1ZXN0ZWQsIGJ1dCBDT05GSUdfU0NNSV9TTUNfTUEgbm90IHNldFxu Iik7DQo+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgICAgICB9DQo+PiAr DQo+PiArICAgICAgICBpZiAoICFkdF9wcm9wZXJ0eV9yZWFkX3UzMihub2RlLCAieGVuLHNjaS1h Z2VudC1pZCIsICZhZ2VudF9pZCkgfHwNCj4+ICsgICAgICAgICAgICAgYWdlbnRfaWQgPj0gVUlO VDhfTUFYICkNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ICsgICAg ICAgIGRfY2ZnLT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lf U0NNSV9TTUNfTUE7DQo+PiArICAgICAgICBkX2NmZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkID0g YWdlbnRfaWQ7DQo+PiArICAgIH0NCj4+ICAgICAgIGVsc2UNCj4+ICAgICAgIHsNCj4+ICAgICAg ICAgICBwcmludGsoWEVOTE9HX0VSUiAieGVuLHNjaV90eXBlIGluIG5vdCB2YWxpZCAoJXMpIGZv ciBkb21haW4gJXNcbiIsDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2RvbWFpbl9idWls ZC5jIGIveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+PiBpbmRleCA3MmQ1MzE2MTgwLi4y OTdjNDZkNWEyIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+ PiArKysgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCj4+IEBAIC04Nyw2ICs4NywzOSBA QCBpbnQgX19pbml0IHBhcnNlX2FyY2hfZG9tMF9wYXJhbShjb25zdCBjaGFyICpzLCBjb25zdCBj aGFyICplKQ0KPj4gICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiAgIH0NCj4+DQo+PiArI2lmZGVm IENPTkZJR19TQ01JX1NNQ19NQQ0KPj4gKy8qIFNDTUkgYWdlbnQgSUQgZm9yIGRvbTAgb2J0YWlu ZWQgZnJvbSB4ZW4sc2NpIGNvbnRhaW5lciAqLw0KPj4gKyNkZWZpbmUgU0NNSV9BR0VOVF9JRF9J TlZBTElEIFVJTlQ4X01BWA0KPj4gKw0KPj4gK3N0YXRpYyB1aW50OF90IF9faW5pdCBnZXRfZG9t MF9zY21pX2FnZW50X2lkKHZvaWQpDQo+PiArew0KPj4gKyAgICBjb25zdCBzdHJ1Y3QgZHRfZGV2 aWNlX25vZGUgKmNvbmZpZ19ub2RlOw0KPj4gKyAgICB1MzIgdmFsOw0KPj4gKyAgICBjb25zdCBz dHJ1Y3QgZHRfcHJvcGVydHkgKnByb3A7DQo+PiArDQo+PiArICAgIGNvbmZpZ19ub2RlID0gZHRf ZmluZF9jb21wYXRpYmxlX25vZGUoTlVMTCwgTlVMTCwgInhlbixzY2kiKTsNCj4+ICsgICAgaWYg KCAhY29uZmlnX25vZGUgKQ0KPj4gKyAgICAgICAgcmV0dXJuIFNDTUlfQUdFTlRfSURfSU5WQUxJ RDsNCj4+ICsNCj4+ICsgICAgcHJvcCA9IGR0X2ZpbmRfcHJvcGVydHkoY29uZmlnX25vZGUsICJ4 ZW4sZG9tMC1zY2ktYWdlbnQtaWQiLCBOVUxMKTsNCj4+ICsgICAgaWYgKCAhcHJvcCApDQo+PiAr ICAgICAgICByZXR1cm4gU0NNSV9BR0VOVF9JRF9JTlZBTElEOw0KPj4gKw0KPj4gKyAgICBpZiAo ICFkdF9wcm9wZXJ0eV9yZWFkX3UzMihjb25maWdfbm9kZSwgInhlbixkb20wLXNjaS1hZ2VudC1p ZCIsICZ2YWwpICkNCj4+ICsgICAgICAgIHJldHVybiBTQ01JX0FHRU5UX0lEX0lOVkFMSUQ7DQo+ PiArDQo+PiArICAgIGlmICggdmFsID49IFNDTUlfQUdFTlRfSURfSU5WQUxJRCApDQo+PiArICAg IHsNCj4+ICsgICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcNCj4+ICsgICAgICAgICAgICAg IkludmFsaWQgeGVuLGRvbTAtc2NpLWFnZW50LWlkPSV1LCBTQ01JIGRpc2FibGVkIGZvciBEb20w XG4iLA0KPj4gKyAgICAgICAgICAgICB2YWwpOw0KPj4gKyAgICAgICAgcmV0dXJuIFNDTUlfQUdF TlRfSURfSU5WQUxJRDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXR1cm4gdmFsOw0KPj4g K30NCj4+ICsjZW5kaWYgLyogQ09ORklHX1NDTUlfU01DX01BICovDQo+PiArDQo+PiAgIC8qIE92 ZXJyaWRlIG1hY3JvcyBmcm9tIGFzbS9wYWdlLmggdG8gbWFrZSB0aGVtIHdvcmsgd2l0aCBtZm5f dCAqLw0KPj4gICAjdW5kZWYgdmlydF90b19tZm4NCj4+ICAgI2RlZmluZSB2aXJ0X3RvX21mbih2 YSkgX21mbihfX3ZpcnRfdG9fbWZuKHZhKSkNCj4+IEBAIC0xNDc5LDYgKzE1MTIsNyBAQCBzdGF0 aWMgaW50IF9faW5pdCBoYW5kbGVfbm9kZShzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qga2VybmVs X2luZm8gKmtpbmZvLA0KPj4gICAgICAgICAgIERUX01BVENIX1RZUEUoIm1lbW9yeSIpLA0KPj4g ICAgICAgICAgIC8qIFRoZSBtZW1vcnkgbWFwcGVkIHRpbWVyIGlzIG5vdCBzdXBwb3J0ZWQgYnkg WGVuLiAqLw0KPj4gICAgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoImFybSxhcm12Ny10aW1l ci1tZW0iKSwNCj4+ICsgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoInhlbixzY2kiKSwNCj4+ ICAgICAgICAgICB7IC8qIHNlbnRpbmVsICovIH0sDQo+PiAgICAgICB9Ow0KPj4gICAgICAgc3Rh dGljIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2VfbWF0Y2ggdGltZXJfbWF0Y2hlc1tdIF9faW5pdGNv bnN0ID0NCj4+IEBAIC0xOTY1LDYgKzE5OTksMTUgQEAgdm9pZCBfX2luaXQgY3JlYXRlX2RvbTAo dm9pZCkNCj4+ICAgICAgIGRvbTBfY2ZnLmFyY2gudGVlX3R5cGUgPSB0ZWVfZ2V0X3R5cGUoKTsN Cj4+ICAgICAgIGRvbTBfY2ZnLm1heF92Y3B1cyA9IGRvbTBfbWF4X3ZjcHVzKCk7DQo+Pg0KPj4g KyNpZmRlZiBDT05GSUdfU0NNSV9TTUNfTUENCj4+ICsgICAgLyogU2V0IHVwIFNDTUkgYWdlbnQg SUQgaWYgcHJvdmlkZWQgaW4gdGhlIHhlbixzY2kgY29udGFpbmVyICovDQo+PiArICAgIGRvbTBf Y2ZnLmFyY2guYXJtX3NjaV9hZ2VudF9pZCA9IGdldF9kb20wX3NjbWlfYWdlbnRfaWQoKTsNCj4+ ICsgICAgZG9tMF9jZmcuYXJjaC5hcm1fc2NpX3R5cGUgPSAoZG9tMF9jZmcuYXJjaC5hcm1fc2Np X2FnZW50X2lkICE9DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNDTUlf QUdFTlRfSURfSU5WQUxJRCkgPw0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUNfTUEgOg0KPj4gKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfTk9ORTsNCj4+ ICsjZW5kaWYNCj4+ICsNCj4+ICAgICAgIGlmICggaW9tbXVfZW5hYmxlZCApDQo+PiAgICAgICAg ICAgZG9tMF9jZmcuZmxhZ3MgfD0gWEVOX0RPTUNUTF9DREZfaW9tbXU7DQo+Pg0KPj4gZGlmZiAt LWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnIGIveGVuL2FyY2gvYXJtL2Zpcm13 YXJlL0tjb25maWcNCj4+IGluZGV4IDVjNWYwODgwYzQuLjk3MmNkOWIxNzMgMTAwNjQ0DQo+PiAt LS0gYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZw0KPj4gKysrIGIveGVuL2FyY2gvYXJt L2Zpcm13YXJlL0tjb25maWcNCj4+IEBAIC0yOSw2ICsyOSwxOCBAQCBjb25maWcgU0NNSV9TTUMN Cj4+ICAgICAgICBkcml2ZXIgZG9tYWluLg0KPj4gICAgICAgIFVzZSB3aXRoIEVMMyBmaXJtd2Fy ZSB3aGljaCBzdXBwb3J0cyBvbmx5IHNpbmdsZSBTQ01JIE9TUE0gYWdlbnQuDQo+Pg0KPj4gK2Nv bmZpZyBTQ01JX1NNQ19NQQ0KPj4gKyAgICBib29sICJFbmFibGUgQVJNIFNDTUkgU01DIG11bHRp LWFnZW50IGRyaXZlciINCj4+ICsgICAgZGVwZW5kcyBvbiBBUk1fNjQNCj4+ICsgICAgc2VsZWN0 IEFSTV9TQ0kNCj4+ICsgICAgaGVscA0KPj4gKyAgICAgIEVuYWJsZXMgU0NNSSBTTUMvSFZDIG11 bHRpLWFnZW50IGluIFhFTiB0byBwYXNzIFNDTUkgcmVxdWVzdHMgZnJvbSBEb21haW5zDQo+PiAr ICAgICAgdG8gRUwzIGZpcm13YXJlIChURi1BKSB3aGljaCBzdXBwb3J0cyBtdWx0aS1hZ2VudCBm ZWF0dXJlLg0KPj4gKyAgICAgIFRoaXMgZmVhdHVyZSBhbGxvd3MgdG8gZW5hYmxlIFNDTUkgcGVy IERvbWFpbiB1c2luZyB1bmlxdWUgU0NNSSBhZ2VudF9pZCwNCj4+ICsgICAgICBzbyBEb21haW4g aXMgaWRlbnRpZmllZCBieSBFTDMgZmlybXdhcmUgYXMgYW4gU0NNSSBBZ2VudCBhbmQgY2FuIGFj Y2Vzcw0KPj4gKyAgICAgIGFsbG93ZWQgcGxhdGZvcm0gcmVzb3VyY2VzIHRocm91Z2ggZGVkaWNh dGVkIFNNQy9IVkMgU2hhcmVkIG1lbW9yeSBiYXNlZA0KPj4gKyAgICAgIHRyYW5zcG9ydC4NCj4+ ICsNCj4+ICAgZW5kY2hvaWNlDQo+Pg0KPj4gICBlbmRtZW51DQo+PiBkaWZmIC0tZ2l0IGEveGVu L2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL01ha2Vm aWxlDQo+PiBpbmRleCA3MWJkZWZjMjRhLi4zNzkyN2U2OTBlIDEwMDY0NA0KPj4gLS0tIGEveGVu L2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZmlybXdh cmUvTWFrZWZpbGUNCj4+IEBAIC0xLDIgKzEsMyBAQA0KPj4gICBvYmotJChDT05GSUdfQVJNX1ND SSkgKz0gc2NpLm8NCj4+ICAgb2JqLSQoQ09ORklHX1NDTUlfU01DKSArPSBzY21pLXNtYy5vDQo+ PiArb2JqLSQoQ09ORklHX1NDTUlfU01DX01BKSArPSBzY21pLXNobWVtLm8gc2NtaS1zbWMtbXVs dGlhZ2VudC5vDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJv dG8uaCBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXByb3RvLmgNCj4+IG5ldyBmaWxlIG1v ZGUgMTAwNjQ0DQo+PiBpbmRleCAwMDAwMDAwMDAwLi40OWY2M2NmYzBhDQo+PiAtLS0gL2Rldi9u dWxsDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5oDQo+PiBAQCAt MCwwICsxLDE2NCBAQA0KPj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9u bHkgKi8NCj4+ICsvKg0KPj4gKyAqIEFybSBTeXN0ZW0gQ29udHJvbCBhbmQgTWFuYWdlbWVudCBJ bnRlcmZhY2UgZGVmaW5pdGlvbnMNCj4+ICsgKiBWZXJzaW9uIDMuMCAoREVOMDA1NkMpDQo+PiAr ICoNCj4+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMjUgRVBBTSBTeXN0ZW1zDQo+PiArICovDQo+PiAr DQo+PiArI2lmbmRlZiBBUk1fRklSTVdBUkVfU0NNSV9QUk9UT19IXw0KPj4gKyNkZWZpbmUgQVJN X0ZJUk1XQVJFX1NDTUlfUFJPVE9fSF8NCj4+ICsNCj4+ICsjaW5jbHVkZSA8eGVuL3N0ZGludC5o Pg0KPj4gKw0KPj4gKyNkZWZpbmUgU0NNSV9TSE9SVF9OQU1FX01BWF9TSVpFIDE2DQo+PiArDQo+ PiArLyogU0NNSSBzdGF0dXMgY29kZXMuIFNlZSBzZWN0aW9uIDQuMS40ICovDQo+PiArI2RlZmlu ZSBTQ01JX1NVQ0NFU1MgICAgICAgICAgICAgIDANCj4+ICsjZGVmaW5lIFNDTUlfTk9UX1NVUFBP UlRFRCAgICAgICgtMSkNCj4+ICsjZGVmaW5lIFNDTUlfSU5WQUxJRF9QQVJBTUVURVJTICgtMikN Cj4+ICsjZGVmaW5lIFNDTUlfREVOSUVEICAgICAgICAgICAgICgtMykNCj4+ICsjZGVmaW5lIFND TUlfTk9UX0ZPVU5EICAgICAgICAgICgtNCkNCj4+ICsjZGVmaW5lIFNDTUlfT1VUX09GX1JBTkdF ICAgICAgICgtNSkNCj4+ICsjZGVmaW5lIFNDTUlfQlVTWSAgICAgICAgICAgICAgICgtNikNCj4+ ICsjZGVmaW5lIFNDTUlfQ09NTVNfRVJST1IgICAgICAgICgtNykNCj4+ICsjZGVmaW5lIFNDTUlf R0VORVJJQ19FUlJPUiAgICAgICgtOCkNCj4+ICsjZGVmaW5lIFNDTUlfSEFSRFdBUkVfRVJST1Ig ICAgICgtOSkNCj4+ICsjZGVmaW5lIFNDTUlfUFJPVE9DT0xfRVJST1IgICAgICgtMTApDQo+PiAr DQo+PiArLyogUHJvdG9jb2wgSURzICovDQo+PiArI2RlZmluZSBTQ01JX0JBU0VfUFJPVE9DT0wg MHgxMA0KPj4gKw0KPj4gKy8qIEJhc2UgcHJvdG9jb2wgbWVzc2FnZSBJRHMgKi8NCj4+ICsjZGVm aW5lIFNDTUlfQkFTRV9QUk9UT0NPTF9WRVJTSU9OICAgICAgICAgICAgMHgwDQo+PiArI2RlZmlu ZSBTQ01JX0JBU0VfUFJPVE9DT0xfQVRUSUJVVEVTICAgICAgICAgIDB4MQ0KPj4gKyNkZWZpbmUg U0NNSV9CQVNFX1BST1RPQ09MX01FU1NBR0VfQVRUUklCVVRFUyAweDINCj4+ICsjZGVmaW5lIFND TUlfQkFTRV9ESVNDT1ZFUl9BR0VOVCAgICAgICAgICAgICAgMHg3DQo+PiArI2RlZmluZSBTQ01J X0JBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUyAgICAgIDB4OQ0KPj4gKyNkZWZpbmUgU0NNSV9C QVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT04gICAweEINCj4+ICsNCj4+ICt0eXBlZGVmIHN0 cnVjdCBzY21pX21zZ19oZWFkZXIgew0KPj4gKyAgICB1aW50OF90IGlkOw0KPj4gKyAgICB1aW50 OF90IHR5cGU7DQo+PiArICAgIHVpbnQ4X3QgcHJvdG9jb2w7DQo+PiArICAgIHVpbnQzMl90IHN0 YXR1czsNCj4+ICt9IHNjbWlfbXNnX2hlYWRlcl90Ow0KPj4gKw0KPj4gKy8qIFRhYmxlIDIgTWVz c2FnZSBoZWFkZXIgZm9ybWF0ICovDQo+PiArI2RlZmluZSBTQ01JX0hEUl9JRCAgICBHRU5NQVNL KDcsIDApDQo+PiArI2RlZmluZSBTQ01JX0hEUl9UWVBFICBHRU5NQVNLKDksIDgpDQo+PiArI2Rl ZmluZSBTQ01JX0hEUl9QUk9UTyBHRU5NQVNLKDE3LCAxMCkNCj4+ICsNCj4+ICsjZGVmaW5lIFND TUlfRklFTERfR0VUKF9tYXNrLCBfcmVnKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgXA0KPj4gKyAgICAoKHR5cGVvZihfbWFzaykpKCgoX3JlZykgJiAoX21hc2sp KSA+PiAoZmZzNjQoX21hc2spIC0gMSkpKQ0KPj4gKyNkZWZpbmUgU0NNSV9GSUVMRF9QUkVQKF9t YXNrLCBfdmFsKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQo+ PiArICAgICgoKHR5cGVvZihfbWFzaykpKF92YWwpIDw8IChmZnM2NChfbWFzaykgLSAxKSkgJiAo X21hc2spKQ0KPj4gKw0KPj4gK3N0YXRpYyBpbmxpbmUgdWludDMyX3QgcGFja19zY21pX2hlYWRl cihzY21pX21zZ19oZWFkZXJfdCAqaGRyKQ0KPj4gK3sNCj4+ICsgICAgcmV0dXJuIFNDTUlfRklF TERfUFJFUChTQ01JX0hEUl9JRCwgaGRyLT5pZCkgfA0KPj4gKyAgICAgICAgICAgU0NNSV9GSUVM RF9QUkVQKFNDTUlfSERSX1RZUEUsIGhkci0+dHlwZSkgfA0KPj4gKyAgICAgICAgICAgU0NNSV9G SUVMRF9QUkVQKFNDTUlfSERSX1BST1RPLCBoZHItPnByb3RvY29sKTsNCj4+ICt9DQo+PiArDQo+ PiArc3RhdGljIGlubGluZSB2b2lkIHVucGFja19zY21pX2hlYWRlcih1aW50MzJfdCBtc2dfaGRy LCBzY21pX21zZ19oZWFkZXJfdCAqaGRyKQ0KPj4gK3sNCj4+ICsgICAgaGRyLT5pZCA9IFNDTUlf RklFTERfR0VUKFNDTUlfSERSX0lELCBtc2dfaGRyKTsNCj4+ICsgICAgaGRyLT50eXBlID0gU0NN SV9GSUVMRF9HRVQoU0NNSV9IRFJfVFlQRSwgbXNnX2hkcik7DQo+PiArICAgIGhkci0+cHJvdG9j b2wgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0hEUl9QUk9UTywgbXNnX2hkcik7DQo+PiArfQ0KPj4g Kw0KPj4gK3N0YXRpYyBpbmxpbmUgaW50IHNjbWlfdG9feGVuX2Vycm5vKGludCBzY21pX3N0YXR1 cykNCj4+ICt7DQo+PiArICAgIGlmICggc2NtaV9zdGF0dXMgPT0gU0NNSV9TVUNDRVNTICkNCj4+ ICsgICAgICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICBzd2l0Y2ggKCBzY21pX3N0YXR1cyAp DQo+PiArICAgIHsNCj4+ICsgICAgY2FzZSBTQ01JX05PVF9TVVBQT1JURUQ6DQo+PiArICAgICAg ICByZXR1cm4gLUVPUE5PVFNVUFA7DQo+PiArICAgIGNhc2UgU0NNSV9JTlZBTElEX1BBUkFNRVRF UlM6DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgY2FzZSBTQ01JX0RFTklF RDoNCj4+ICsgICAgICAgIHJldHVybiAtRUFDQ0VTOw0KPj4gKyAgICBjYXNlIFNDTUlfTk9UX0ZP VU5EOg0KPj4gKyAgICAgICAgcmV0dXJuIC1FTk9FTlQ7DQo+PiArICAgIGNhc2UgU0NNSV9PVVRf T0ZfUkFOR0U6DQo+PiArICAgICAgICByZXR1cm4gLUVSQU5HRTsNCj4+ICsgICAgY2FzZSBTQ01J X0JVU1k6DQo+PiArICAgICAgICByZXR1cm4gLUVCVVNZOw0KPj4gKyAgICBjYXNlIFNDTUlfQ09N TVNfRVJST1I6DQo+PiArICAgICAgICByZXR1cm4gLUVOT1RDT05OOw0KPj4gKyAgICBjYXNlIFND TUlfR0VORVJJQ19FUlJPUjoNCj4+ICsgICAgICAgIHJldHVybiAtRUlPOw0KPj4gKyAgICBjYXNl IFNDTUlfSEFSRFdBUkVfRVJST1I6DQo+PiArICAgICAgICByZXR1cm4gLUVOWElPOw0KPj4gKyAg ICBjYXNlIFNDTUlfUFJPVE9DT0xfRVJST1I6DQo+PiArICAgICAgICByZXR1cm4gLUVCQURNU0c7 DQo+PiArICAgIGRlZmF1bHQ6DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAg fQ0KPj4gK30NCj4+ICsNCj4+ICsvKiBQUk9UT0NPTF9WRVJTSU9OICovDQo+PiArI2RlZmluZSBT Q01JX1ZFUlNJT05fTUlOT1IgR0VOTUFTSygxNSwgMCkNCj4+ICsjZGVmaW5lIFNDTUlfVkVSU0lP Tl9NQUpPUiBHRU5NQVNLKDMxLCAxNikNCj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9tc2dfcHJvdF92 ZXJzaW9uX3AyYSB7DQo+PiArICAgIHVpbnQzMl90IHZlcnNpb247DQo+PiArfSBfX3BhY2tlZDsN Cj4+ICsNCj4+ICsvKiBCQVNFIFBST1RPQ09MX0FUVFJJQlVURVMgKi8NCj4+ICsjZGVmaW5lIFND TUlfQkFTRV9BVFRSX05VTV9QUk9UTyBHRU5NQVNLKDcsIDApDQo+PiArI2RlZmluZSBTQ01JX0JB U0VfQVRUUl9OVU1fQUdFTlQgR0VOTUFTSygxNSwgOCkNCj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9t c2dfYmFzZV9hdHRyaWJ1dGVzX3AyYSB7DQo+PiArICAgIHVpbnQzMl90IGF0dHJpYnV0ZXM7DQo+ PiArfSBfX3BhY2tlZDsNCj4+ICsNCj4+ICsvKg0KPj4gKyAqIEJBU0VfRElTQ09WRVJfQUdFTlQN Cj4+ICsgKi8NCj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9BR0VOVF9JRF9PV04gMHhGRkZGRkZGRg0K Pj4gKw0KPj4gK3N0cnVjdCBzY21pX21zZ19iYXNlX2Rpc2NvdmVyX2FnZW50X2EycCB7DQo+PiAr ICAgIHVpbnQzMl90IGFnZW50X2lkOw0KPj4gK30gX19wYWNrZWQ7DQo+PiArDQo+PiArc3RydWN0 IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdlbnRfcDJhIHsNCj4+ICsgICAgdWludDMyX3QgYWdl bnRfaWQ7DQo+PiArICAgIGNoYXIgbmFtZVtTQ01JX1NIT1JUX05BTUVfTUFYX1NJWkVdOw0KPj4g K30gX19wYWNrZWQ7DQo+PiArDQo+PiArLyoNCj4+ICsgKiBCQVNFX1NFVF9ERVZJQ0VfUEVSTUlT U0lPTlMNCj4+ICsgKi8NCj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9ERVZJQ0VfQUNDRVNTX0FMTE9X ICAgICAgICAgICBCSVQoMCwgVUwpDQo+PiArDQo+PiArc3RydWN0IHNjbWlfbXNnX2Jhc2Vfc2V0 X2RldmljZV9wZXJtaXNzaW9uc19hMnAgew0KPj4gKyAgICB1aW50MzJfdCBhZ2VudF9pZDsNCj4+ ICsgICAgdWludDMyX3QgZGV2aWNlX2lkOw0KPj4gKyAgICB1aW50MzJfdCBmbGFnczsNCj4+ICt9 IF9fcGFja2VkOw0KPj4gKw0KPj4gKy8qDQo+PiArICogQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdV UkFUSU9ODQo+PiArICovDQo+PiArI2RlZmluZSBTQ01JX0JBU0VfQUdFTlRfUEVSTUlTU0lPTlNf UkVTRVQgICAgICAgQklUKDAsIFVMKQ0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX21zZ19iYXNlX3Jl c2V0X2FnZW50X2NmZ19hMnAgew0KPj4gKyAgICB1aW50MzJfdCBhZ2VudF9pZDsNCj4+ICsgICAg dWludDMyX3QgZmxhZ3M7DQo+PiArfSBfX3BhY2tlZDsNCj4+ICsNCj4+ICsjZW5kaWYgLyogQVJN X0ZJUk1XQVJFX1NDTUlfUFJPVE9fSF8gKi8NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIExvY2FsIHZh cmlhYmxlczoNCj4+ICsgKiBtb2RlOiBDDQo+PiArICogYy1maWxlLXN0eWxlOiAiQlNEIg0KPj4g KyAqIGMtYmFzaWMtb2Zmc2V0OiA0DQo+PiArICogdGFiLXdpZHRoOiA0DQo+PiArICogaW5kZW50 LXRhYnMtbW9kZTogbmlsDQo+PiArICogRW5kOg0KPj4gKyAqLw0KPj4gZGlmZiAtLWdpdCBhL3hl bi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUv c2NtaS1zaG1lbS5jDQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAw MC4uZTM2NzQ1YTg1ZQ0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zp cm13YXJlL3NjbWktc2htZW0uYw0KPj4gQEAgLTAsMCArMSwxMTggQEANCj4+ICsvKiBTUERYLUxp Y2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBTTUMvSFZD IHNobWVtIHRyYW5zcG9ydCBpbXBsZW1lbnRhdGlvbiB1c2VkIGJ5DQo+PiArICogU0NJIFNDTUkg bXVsdGktYWdlbnQgZHJpdmVyLg0KPj4gKyAqDQo+PiArICogT2xla3NpaSBNb2lzaWVpZXYgPG9s ZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4gKyAqIENvcHlyaWdodCAoYykgMjAyNSBFUEFN IFN5c3RlbXMNCj4+ICsgKi8NCj4+ICsNCj4+ICsjaW5jbHVkZSA8eGVuL2Vyci5oPg0KPj4gKyNp bmNsdWRlIDx4ZW4vaW8uaD4NCj4+ICsjaW5jbHVkZSA8YXNtL2lvLmg+DQo+PiArDQo+PiArI2lu Y2x1ZGUgInNjbWktcHJvdG8uaCINCj4+ICsjaW5jbHVkZSAic2NtaS1zaG1lbS5oIg0KPj4gKw0K Pj4gK3N0YXRpYyBpbmxpbmUgaW50DQo+PiArc2htZW1fY2hhbm5lbF9zdGF0dXMoY29uc3Qgdm9s YXRpbGUgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSkNCj4+ICt7DQo+PiAr ICAgIHJldHVybiAocmVhZGwoJnNobWVtLT5jaGFubmVsX3N0YXR1cykgJg0KPj4gKyAgICAgICAg ICAgIFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NIQU5ORUxfRlJFRSkgPyAwIDogLUVCVVNZOw0KPj4g K30NCj4+ICsNCj4+ICtpbnQgc2htZW1fcHV0X21lc3NhZ2Uodm9sYXRpbGUgc3RydWN0IHNjbWlf c2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgc2Nt aV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0YSwgdW5zaWduZWQgaW50IGxlbikNCj4+ICt7 DQo+PiArICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgIGlmICggKGxlbiArIG9mZnNldG9mKHN0 cnVjdCBzY21pX3NoYXJlZF9tZW0sIG1zZ19wYXlsb2FkKSkgPg0KPj4gKyAgICAgICAgIFNDTUlf U0hNRU1fTUFQUEVEX1NJWkUgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9H X0VSUiAic2NtaTogV3Jvbmcgc2l6ZSBvZiBzbWMgbWVzc2FnZS4gRGF0YSBpcyBpbnZhbGlkXG4i KTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAg IHJldCA9IHNobWVtX2NoYW5uZWxfc3RhdHVzKHNobWVtKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0K Pj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgd3JpdGVsX3JlbGF4ZWQoMHgw LCAmc2htZW0tPmNoYW5uZWxfc3RhdHVzKTsNCj4+ICsgICAgLyogV3JpdGluZyAweDAgcmlnaHQg bm93LCBidXQgInNobWVtIl9GTEFHX0lOVFJfRU5BQkxFRCBjYW4gYmUgc2V0ICovDQo+PiArICAg IHdyaXRlbF9yZWxheGVkKDB4MCwgJnNobWVtLT5mbGFncyk7DQo+PiArICAgIHdyaXRlbF9yZWxh eGVkKHNpemVvZihzaG1lbS0+bXNnX2hlYWRlcikgKyBsZW4sICZzaG1lbS0+bGVuZ3RoKTsNCj4+ ICsgICAgd3JpdGVsKHBhY2tfc2NtaV9oZWFkZXIoaGRyKSwgJnNobWVtLT5tc2dfaGVhZGVyKTsN Cj4+ICsNCj4+ICsgICAgaWYgKCBsZW4gPiAwICYmIGRhdGEgKQ0KPj4gKyAgICAgICAgbWVtY3B5 X3RvaW8oc2htZW0tPm1zZ19wYXlsb2FkLCBkYXRhLCBsZW4pOw0KPj4gKw0KPj4gKyAgICByZXR1 cm4gMDsNCj4+ICt9DQo+PiArDQo+PiAraW50IHNobWVtX2dldF9yZXNwb25zZShjb25zdCB2b2xh dGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtLA0KPj4gKyAgICAgICAg ICAgICAgICAgICAgICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAqZGF0YSwgdW5zaWdu ZWQgaW50IGxlbikNCj4+ICt7DQo+PiArICAgIGludCByZWN2X2xlbjsNCj4+ICsgICAgaW50IHJl dDsNCj4+ICsgICAgLyoNCj4+ICsgICAgICogRmlyc3Qgd29yZCBvZiBtc2dfcGF5bG9hZCBjYXJy aWVzIHRoZSByZXR1cm5lZCBzdGF0dXM7IGV4Y2x1ZGUgaXQgZnJvbQ0KPj4gKyAgICAgKiByZWN2 X2xlbiBzbyBvbmx5IHRoZSBwcm90b2NvbCBwYXlsb2FkIGlzIGNvcGllZCBiYWNrIHRvIHRoZSBj YWxsZXIuDQo+PiArICAgICAqLw0KPj4gKyAgICBpbnQgcGFkID0gc2l6ZW9mKGhkci0+c3RhdHVz KTsNCj4+ICsNCj4+ICsgICAgaWYgKCBsZW4gPj0gU0NNSV9TSE1FTV9NQVBQRURfU0laRSAtDQo+ PiArICAgICAgICAgb2Zmc2V0b2Yoc3RydWN0IHNjbWlfc2hhcmVkX21lbSwgbXNnX3BheWxvYWQp ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAg ICAgICAgICAic2NtaTogV3Jvbmcgc2l6ZSBvZiBpbnB1dCBzbWMgbWVzc2FnZS4gRGF0YSBtYXkg YmUgaW52YWxpZFxuIik7DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0K Pj4gKw0KPj4gKyAgICByZXQgPSBzaG1lbV9jaGFubmVsX3N0YXR1cyhzaG1lbSk7DQo+PiArICAg IGlmICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgIHJlY3Zf bGVuID0gcmVhZGwoJnNobWVtLT5sZW5ndGgpIC0gc2l6ZW9mKHNobWVtLT5tc2dfaGVhZGVyKTsN Cj4+ICsNCj4+ICsgICAgaWYgKCByZWN2X2xlbiA8IDAgKQ0KPj4gKyAgICB7DQo+PiArICAgICAg ICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBXcm9uZyBzaXpl IG9mIHNtYyBtZXNzYWdlLiBEYXRhIG1heSBiZSBpbnZhbGlkXG4iKTsNCj4+ICsgICAgICAgIHJl dHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHVucGFja19zY21pX2hlYWRl cihyZWFkbCgmc2htZW0tPm1zZ19oZWFkZXIpLCBoZHIpOw0KPj4gKw0KPj4gKyAgICBoZHItPnN0 YXR1cyA9IHJlYWRsKCZzaG1lbS0+bXNnX3BheWxvYWQpOw0KPj4gKyAgICByZWN2X2xlbiA9IHJl Y3ZfbGVuID4gcGFkID8gcmVjdl9sZW4gLSBwYWQgOiAwOw0KPj4gKw0KPj4gKyAgICByZXQgPSBz Y21pX3RvX3hlbl9lcnJubyhoZHItPnN0YXR1cyk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsg ICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogRXJyb3IgcmVjZWl2 ZWQ6ICVkXG4iLCByZXQpOw0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsgICAgfQ0KPj4g Kw0KPj4gKyAgICBpZiAoIHJlY3ZfbGVuID4gbGVuICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAg cHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAic2NtaTogTm90IGVub3VnaCBi dWZmZXIgZm9yIG1lc3NhZ2UgJWQsIGV4cGVjdGluZyAlZFxuIiwNCj4+ICsgICAgICAgICAgICAg ICByZWN2X2xlbiwgbGVuKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9 DQo+PiArDQo+PiArICAgIGlmICggcmVjdl9sZW4gPiAwICkNCj4+ICsgICAgICAgIG1lbWNweV9m cm9taW8oZGF0YSwgc2htZW0tPm1zZ19wYXlsb2FkICsgcGFkLCByZWN2X2xlbik7DQo+PiArDQo+ PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIExvY2FsIHZhcmlh YmxlczoNCj4+ICsgKiBtb2RlOiBDDQo+PiArICogYy1maWxlLXN0eWxlOiAiQlNEIg0KPj4gKyAq IGMtYmFzaWMtb2Zmc2V0OiA0DQo+PiArICogdGFiLXdpZHRoOiA0DQo+PiArICogaW5kZW50LXRh YnMtbW9kZTogbmlsDQo+PiArICogRW5kOg0KPj4gKyAqLw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9h cmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmggYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2Nt aS1zaG1lbS5oDQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAwMC4u NzIyMjYzYWE3Nw0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13 YXJlL3NjbWktc2htZW0uaA0KPj4gQEAgLTAsMCArMSw0NSBAQA0KPj4gKy8qIFNQRFgtTGljZW5z ZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+ICsvKg0KPj4gKyAqIEFybSBTeXN0ZW0g Q29udHJvbCBhbmQgTWFuYWdlbWVudCBJbnRlcmZhY2UgZGVmaW5pdGlvbnMNCj4+ICsgKiBWZXJz aW9uIDMuMCAoREVOMDA1NkMpDQo+PiArICogU2hhcmVkIE1lbW9yeSBiYXNlZCBUcmFuc3BvcnQN Cj4+ICsgKg0KPj4gKyAqIENvcHlyaWdodCAoYykgMjAyNCBFUEFNIFN5c3RlbXMNCj4+ICsgKi8N Cj4+ICsNCj4+ICsjaWZuZGVmIEFSTV9GSVJNV0FSRV9TQ01JX1NITUVNX0hfDQo+PiArI2RlZmlu ZSBBUk1fRklSTVdBUkVfU0NNSV9TSE1FTV9IXw0KPj4gKw0KPj4gKyNpbmNsdWRlIDx4ZW4vc3Rk aW50Lmg+DQo+PiArDQo+PiArI2RlZmluZSBTQ01JX1NITUVNX0NIQU5fU1RBVF9DSEFOTkVMX0ZS RUUgIEJJVCgwLCBVTCkNCj4+ICsjZGVmaW5lIFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NIQU5ORUxf RVJST1IgQklUKDEsIFVMKQ0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX3NoYXJlZF9tZW0gew0KPj4g KyAgICB1aW50MzJfdCByZXNlcnZlZDsNCj4+ICsgICAgdWludDMyX3QgY2hhbm5lbF9zdGF0dXM7 DQo+PiArICAgIHVpbnQzMl90IHJlc2VydmVkMVsyXTsNCj4+ICsgICAgdWludDMyX3QgZmxhZ3M7 DQo+PiArICAgIHVpbnQzMl90IGxlbmd0aDsNCj4+ICsgICAgdWludDMyX3QgbXNnX2hlYWRlcjsN Cj4+ICsgICAgdWludDhfdCBtc2dfcGF5bG9hZFtdOw0KPj4gK307DQo+PiArDQo+PiArI2RlZmlu ZSBTQ01JX1NITUVNX01BUFBFRF9TSVpFIFBBR0VfU0laRQ0KPj4gKw0KPj4gK2ludCBzaG1lbV9w dXRfbWVzc2FnZSh2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVt LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lk ICpkYXRhLCB1bnNpZ25lZCBpbnQgbGVuKTsNCj4+ICsNCj4+ICtpbnQgc2htZW1fZ2V0X3Jlc3Bv bnNlKGNvbnN0IHZvbGF0aWxlIHN0cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21lbSAqc2htZW0s DQo+PiArICAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lk ICpkYXRhLCB1bnNpZ25lZCBpbnQgbGVuKTsNCj4+ICsjZW5kaWYgLyogQVJNX0ZJUk1XQVJFX1ND TUlfU0hNRU1fSF8gKi8NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIExvY2FsIHZhcmlhYmxlczoNCj4+ ICsgKiBtb2RlOiBDDQo+PiArICogYy1maWxlLXN0eWxlOiAiQlNEIg0KPj4gKyAqIGMtYmFzaWMt b2Zmc2V0OiA0DQo+PiArICogdGFiLXdpZHRoOiA0DQo+PiArICogaW5kZW50LXRhYnMtbW9kZTog bmlsDQo+PiArICogRW5kOg0KPj4gKyAqLw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9m aXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2Nt aS1zbWMtbXVsdGlhZ2VudC5jDQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAw MDAwMDAwMC4uMGM1NjUzZmJjMA0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gv YXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYw0KPj4gQEAgLTAsMCArMSw4MTYgQEAN Cj4+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArLyoN Cj4+ICsgKiBTQ0kgU0NNSSBtdWx0aS1hZ2VudCBkcml2ZXIsIHVzaW5nIFNNQy9IVkMgc2htZW0g YXMgdHJhbnNwb3J0Lg0KPj4gKyAqDQo+PiArICogT2xla3NpaSBNb2lzaWVpZXYgPG9sZWtzaWlf bW9pc2llaWV2QGVwYW0uY29tPg0KPj4gKyAqIENvcHlyaWdodCAoYykgMjAyNSBFUEFNIFN5c3Rl bXMNCj4+ICsgKi8NCj4+ICsNCj4+ICsjaW5jbHVkZSA8eGVuL2FjcGkuaD4NCj4+ICsNCj4+ICsj aW5jbHVkZSA8eGVuL2RldmljZV90cmVlLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9pbml0Lmg+DQo+ PiArI2luY2x1ZGUgPHhlbi9pb2NhcC5oPg0KPj4gKyNpbmNsdWRlIDx4ZW4vZXJyLmg+DQo+PiAr I2luY2x1ZGUgPHhlbi9saWJmZHQvbGliZmR0Lmg+DQo+PiArI2luY2x1ZGUgPHhlbi9zdHJpbmcu aD4NCj4+ICsjaW5jbHVkZSA8eGVuL3BhcmFtLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9zY2hlZC5o Pg0KPj4gKyNpbmNsdWRlIDx4ZW4vdm1hcC5oPg0KPj4gKw0KPj4gKyNpbmNsdWRlIDxhc20vZmly bXdhcmUvc2NpLmg+DQo+PiArI2luY2x1ZGUgPGFzbS9zbWNjYy5oPg0KPj4gKw0KPj4gKyNpbmNs dWRlICJzY21pLXByb3RvLmgiDQo+PiArI2luY2x1ZGUgInNjbWktc2htZW0uaCINCj4+ICsNCj4+ ICsjZGVmaW5lIFNDTUlfU0VDT05EQVJZX0FHRU5UUyAic2NtaS1zZWNvbmRhcnktYWdlbnRzIg0K Pj4gKw0KPj4gK3N0cnVjdCBzY21pX2NoYW5uZWwgew0KPj4gKyAgICB1aW50MzJfdCBhZ2VudF9p ZDsNCj4+ICsgICAgdWludDMyX3QgZnVuY19pZDsNCj4+ICsgICAgZG9taWRfdCBkb21haW5faWQ7 DQo+PiArICAgIHVpbnQ2NF90IHBhZGRyOw0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVt IF9faW9tZW0gKnNobWVtOw0KPj4gKyAgICBzcGlubG9ja190IGxvY2s7DQo+PiArICAgIHN0cnVj dCBsaXN0X2hlYWQgbGlzdDsNCj4+ICt9Ow0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX2RhdGEgew0K Pj4gKyAgICBzdHJ1Y3QgbGlzdF9oZWFkIGNoYW5uZWxfbGlzdDsNCj4+ICsgICAgc3BpbmxvY2tf dCBjaGFubmVsX2xpc3RfbG9jazsNCj4+ICsgICAgdWludDMyX3QgZnVuY19pZDsNCj4+ICsgICAg Ym9vbCBpbml0aWFsaXplZDsNCj4+ICsgICAgdWludDMyX3Qgc2htZW1fcGhhbmRsZTsNCj4+ICsg ICAgdWludDMyX3QgaHlwX2NoYW5uZWxfYWdlbnRfaWQ7DQo+PiArICAgIHN0cnVjdCBkdF9kZXZp Y2Vfbm9kZSAqZHRfZGV2Ow0KPj4gK307DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCBzY21pX2Rh dGEgc2NtaV9kYXRhOw0KPj4gKw0KPj4gK3N0YXRpYyBib29sIHNjbWlfaXNfdW5kZXJfeGVuX3Nj aShjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGUpDQo+PiArew0KPj4gKyAgICBjb25z dCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnA7DQo+PiArDQo+PiArICAgIGZvciAoIHAgPSBub2Rl LT5wYXJlbnQ7IHA7IHAgPSBwLT5wYXJlbnQgKQ0KPj4gKyAgICAgICAgaWYgKCBkdF9kZXZpY2Vf aXNfY29tcGF0aWJsZShwLCAieGVuLHNjaSIpICkNCj4+ICsgICAgICAgICAgICByZXR1cm4gdHJ1 ZTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIGZhbHNlOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMg aW50IHNlbmRfc21jX21lc3NhZ2Uoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbl9pbmZvLA0KPj4g KyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lk ICpkYXRhLCBpbnQgbGVuKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IGFybV9zbWNjY19yZXMgcmVz cDsNCj4+ICsgICAgaW50IHJldDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gc2htZW1fcHV0X21lc3Nh Z2UoY2hhbl9pbmZvLT5zaG1lbSwgaGRyLCBkYXRhLCBsZW4pOw0KPj4gKyAgICBpZiAoIHJldCAp DQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0KPj4gKyAgICByZXNwID0gYXJtX3NtY2Nj XzFfMV9zbWMoY2hhbl9pbmZvLT5mdW5jX2lkLCAwLCAwLCAwLCAwLCAwLCAwLCAwKTsNCj4+ICsN Cj4+ICsgICAgaWYgKCByZXNwLmEwID09ICh1bnNpZ25lZCBsb25nKUFSTV9TTUNDQ19JTlZBTElE X1BBUkFNRVRFUiApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ICsgICAg aWYgKCByZXNwLmEwICkNCj4+ICsgICAgICAgIHJldHVybiAtRU9QTk9UU1VQUDsNCj4+ICsNCj4+ ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgZG9fc21jX3hmZXIo c3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbl9pbmZvLCBzY21pX21zZ19oZWFkZXJfdCAqaGRyLA0K Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqdHhfZGF0YSwgaW50IHR4X3NpemUsIHZv aWQgKnJ4X2RhdGEsIGludCByeF9zaXplKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJldCA9IDA7DQo+ PiArDQo+PiArICAgIEFTU0VSVChjaGFuX2luZm8gJiYgY2hhbl9pbmZvLT5zaG1lbSk7DQo+PiAr DQo+PiArICAgIGlmICggIWhkciApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsN Cj4+ICsgICAgc3Bpbl9sb2NrKCZjaGFuX2luZm8tPmxvY2spOw0KPj4gKw0KPj4gKyAgICBwcmlu dGsoWEVOTE9HX0RFQlVHDQo+PiArICAgICAgICAgICAic2NtaTogYWdlbnRfaWQgPSAlZCBtc2df aWQgPSAleCB0eXBlID0gJWQsIHByb3RvID0gJXhcbiIsDQo+PiArICAgICAgICAgICBjaGFuX2lu Zm8tPmFnZW50X2lkLCBoZHItPmlkLCBoZHItPnR5cGUsIGhkci0+cHJvdG9jb2wpOw0KPj4gKw0K Pj4gKyAgICByZXQgPSBzZW5kX3NtY19tZXNzYWdlKGNoYW5faW5mbywgaGRyLCB0eF9kYXRhLCB0 eF9zaXplKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBjbGVhbjsNCj4+ ICsNCj4+ICsgICAgcmV0ID0gc2htZW1fZ2V0X3Jlc3BvbnNlKGNoYW5faW5mby0+c2htZW0sIGhk ciwgcnhfZGF0YSwgcnhfc2l6ZSk7DQo+PiArDQo+PiArY2xlYW46DQo+PiArICAgIHByaW50ayhY RU5MT0dfREVCVUcNCj4+ICsgICAgICAgICAgICJzY21pOiBnZXQgc21jIHJlc3BvbnNlIGFnZW50 X2lkID0gJWQgbXNnX2lkID0gJXggcHJvdG8gPSAleCByZXM9JWRcbiIsDQo+PiArICAgICAgICAg ICBjaGFuX2luZm8tPmFnZW50X2lkLCBoZHItPmlkLCBoZHItPnByb3RvY29sLCByZXQpOw0KPj4g Kw0KPj4gKyAgICBzcGluX3VubG9jaygmY2hhbl9pbmZvLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAg cmV0dXJuIHJldDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCBzY21pX2NoYW5uZWwg KmdldF9jaGFubmVsX2J5X2lkKHVpbnQzMl90IGFnZW50X2lkKQ0KPj4gK3sNCj4+ICsgICAgc3Ry dWN0IHNjbWlfY2hhbm5lbCAqY3VycjsNCj4+ICsgICAgYm9vbCBmb3VuZCA9IGZhbHNlOw0KPj4g Kw0KPj4gKyAgICBzcGluX2xvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiAr ICAgIGxpc3RfZm9yX2VhY2hfZW50cnkoY3VyciwgJnNjbWlfZGF0YS5jaGFubmVsX2xpc3QsIGxp c3QpDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlmICggY3Vyci0+YWdlbnRfaWQgPT0gYWdlbnRf aWQgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIGZvdW5kID0gdHJ1ZTsNCj4+ICsg ICAgICAgICAgICBicmVhazsNCj4+ICsgICAgICAgIH0NCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAg ICBzcGluX3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgaWYg KCBmb3VuZCApDQo+PiArICAgICAgICByZXR1cm4gY3VycjsNCj4+ICsNCj4+ICsgICAgcmV0dXJu IE5VTEw7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBzdHJ1Y3Qgc2NtaV9jaGFubmVsICphY3F1 aXJlX3NjbWlfY2hhbm5lbChzdHJ1Y3QgZG9tYWluICpkLA0KPj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBhZ2VudF9pZCkNCj4+ICt7 DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmN1cnI7DQo+PiArICAgIHN0cnVjdCBzY21p X2NoYW5uZWwgKnJldCA9IEVSUl9QVFIoLUVOT0VOVCk7DQo+PiArDQo+PiArICAgIHNwaW5fbG9j aygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgbGlzdF9mb3JfZWFjaF9l bnRyeShjdXJyLCAmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdCwgbGlzdCkNCj4+ICsgICAgew0KPj4g KyAgICAgICAgaWYgKCBjdXJyLT5hZ2VudF9pZCA9PSBhZ2VudF9pZCApDQo+PiArICAgICAgICB7 DQo+PiArICAgICAgICAgICAgaWYgKCBjdXJyLT5kb21haW5faWQgIT0gRE9NSURfSU5WQUxJRCAp DQo+PiArICAgICAgICAgICAgew0KPj4gKyAgICAgICAgICAgICAgICByZXQgPSBFUlJfUFRSKC1F RVhJU1QpOw0KPj4gKyAgICAgICAgICAgICAgICBicmVhazsNCj4+ICsgICAgICAgICAgICB9DQo+ PiArDQo+PiArICAgICAgICAgICAgY3Vyci0+ZG9tYWluX2lkID0gZC0+ZG9tYWluX2lkOw0KPj4g KyAgICAgICAgICAgIHJldCA9IGN1cnI7DQo+PiArICAgICAgICAgICAgYnJlYWs7DQo+PiArICAg ICAgICB9DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJnNjbWlfZGF0YS5j aGFubmVsX2xpc3RfbG9jayk7DQo+PiArDQo+PiArICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4g Kw0KPj4gK3N0YXRpYyB2b2lkIHJlbGlucXVpc2hfc2NtaV9jaGFubmVsKHN0cnVjdCBzY21pX2No YW5uZWwgKmNoYW5uZWwpDQo+PiArew0KPj4gKyAgICBBU1NFUlQoY2hhbm5lbCAhPSBOVUxMKTsN Cj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0K Pj4gKyAgICBjaGFubmVsLT5kb21haW5faWQgPSBET01JRF9JTlZBTElEOw0KPj4gKyAgICBzcGlu X3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICt9DQo+PiArDQo+PiAr c3RhdGljIGludCBtYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5l bCkNCj4+ICt7DQo+PiArICAgIEFTU0VSVChjaGFubmVsICYmIGNoYW5uZWwtPnBhZGRyKTsNCj4+ ICsgICAgY2hhbm5lbC0+c2htZW0gPSBpb3JlbWFwX25vY2FjaGUoY2hhbm5lbC0+cGFkZHIsIFND TUlfU0hNRU1fTUFQUEVEX1NJWkUpOw0KPj4gKyAgICBpZiAoICFjaGFubmVsLT5zaG1lbSApDQo+ PiArICAgICAgICByZXR1cm4gLUVOT01FTTsNCj4+ICsNCj4+ICsgICAgY2hhbm5lbC0+c2htZW0t PmNoYW5uZWxfc3RhdHVzID0gU0NNSV9TSE1FTV9DSEFOX1NUQVRfQ0hBTk5FTF9GUkVFOw0KPj4g KyAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBHb3Qgc2htZW0gJWx4IGFmdGVyIHZtYXAg JXBcbiIsIGNoYW5uZWwtPnBhZGRyLA0KPj4gKyAgICAgICAgICAgY2hhbm5lbC0+c2htZW0pOw0K Pj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHZvaWQgdW5t YXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCkNCj4+ICt7DQo+ PiArICAgIEFTU0VSVChjaGFubmVsKTsNCj4+ICsNCj4+ICsgICAgaWYgKCAhY2hhbm5lbC0+c2ht ZW0gKQ0KPj4gKyAgICAgICAgcmV0dXJuOw0KPj4gKw0KPj4gKyAgICBpb3VubWFwKGNoYW5uZWwt PnNobWVtKTsNCj4+ICsgICAgY2hhbm5lbC0+c2htZW0gPSBOVUxMOw0KPj4gK30NCj4+ICsNCj4+ ICtzdGF0aWMgc3RydWN0IHNjbWlfY2hhbm5lbCAqc21jX2NyZWF0ZV9jaGFubmVsKHVpbnQzMl90 IGFnZW50X2lkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdWludDMyX3QgZnVuY19pZCwgdWludDY0X3QgYWRkcikNCj4+ICt7DQo+PiArICAgIHN0 cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWwsICpjdXJyOw0KPj4gKw0KPj4gKyAgICBzcGluX2xv Y2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArDQo+PiArICAgIC8qIENoZWNr IGlmIGNoYW5uZWwgYWxyZWFkeSBleGlzdHMgd2hpbGUgaG9sZGluZyB0aGUgbG9jayAqLw0KPj4g KyAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5KGN1cnIsICZzY21pX2RhdGEuY2hhbm5lbF9saXN0LCBs aXN0KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBpZiAoIGN1cnItPmFnZW50X2lkID09IGFnZW50 X2lkICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBzcGluX3VubG9jaygmc2NtaV9k YXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gRVJSX1BUUigt RUVYSVNUKTsNCj4+ICsgICAgICAgIH0NCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBjaGFubmVs ID0geG1hbGxvYyhzdHJ1Y3Qgc2NtaV9jaGFubmVsKTsNCj4+ICsgICAgaWYgKCAhY2hhbm5lbCAp DQo+PiArICAgIHsNCj4+ICsgICAgICAgIHNwaW5fdW5sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9s aXN0X2xvY2spOw0KPj4gKyAgICAgICAgcmV0dXJuIEVSUl9QVFIoLUVOT01FTSk7DQo+PiArICAg IH0NCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrX2luaXQoJmNoYW5uZWwtPmxvY2spOw0KPj4gKyAg ICBjaGFubmVsLT5hZ2VudF9pZCA9IGFnZW50X2lkOw0KPj4gKyAgICBjaGFubmVsLT5mdW5jX2lk ID0gZnVuY19pZDsNCj4+ICsgICAgY2hhbm5lbC0+ZG9tYWluX2lkID0gRE9NSURfSU5WQUxJRDsN Cj4+ICsgICAgY2hhbm5lbC0+c2htZW0gPSBOVUxMOw0KPj4gKyAgICBjaGFubmVsLT5wYWRkciA9 IGFkZHI7DQo+PiArICAgIGxpc3RfYWRkX3RhaWwoJmNoYW5uZWwtPmxpc3QsICZzY21pX2RhdGEu Y2hhbm5lbF9saXN0KTsNCj4+ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJnNjbWlfZGF0YS5jaGFu bmVsX2xpc3RfbG9jayk7DQo+PiArICAgIHJldHVybiBjaGFubmVsOw0KPj4gK30NCj4+ICsNCj4+ ICtzdGF0aWMgdm9pZCBmcmVlX2NoYW5uZWxfbGlzdCh2b2lkKQ0KPj4gK3sNCj4+ICsgICAgc3Ry dWN0IHNjbWlfY2hhbm5lbCAqY3VyciwgKl9jdXJyOw0KPj4gKyAgICAvKg0KPj4gKyAgICAgKiBD YWxsZWQgb25seSBvbiB0aGUgX19pbml0IGVycm9yIHBhdGgsIGJlZm9yZSBhbnkgcnVudGltZSB1 c2VycyBleGlzdCwNCj4+ICsgICAgICogc28gbm8gb3RoZXIgdGhyZWFkIGlzIGl0ZXJhdGluZyBj aGFubmVsX2xpc3QuIEtlZXAgdGhlIGxvY2sgZm9yIHRoZQ0KPj4gKyAgICAgKiB3aG9sZSBkcmFp biBmb3IgY2xhcml0eSBhbmQgdG8gYXZvaWQgbWlzbGVhZGluZyByZWFkZXJzIGFib3V0IHBvc3Np YmxlDQo+PiArICAgICAqIGNvbmN1cnJlbnQgYWNjZXNzLg0KPj4gKyAgICAgKi8NCj4+ICsgICAg c3Bpbl9sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0KPj4gKyAgICBsaXN0X2Zv cl9lYWNoX2VudHJ5X3NhZmUoY3VyciwgX2N1cnIsICZzY21pX2RhdGEuY2hhbm5lbF9saXN0LCBs aXN0KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBsaXN0X2RlbCgmY3Vyci0+bGlzdCk7DQo+PiAr ICAgICAgICB4ZnJlZShjdXJyKTsNCj4+ICsgICAgfQ0KPj4gKyAgICBzcGluX3VubG9jaygmc2Nt aV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBf X2luaXQNCj4+ICtzY21pX2R0X3JlYWRfaHlwX2NoYW5uZWxfYWRkcihzdHJ1Y3QgZHRfZGV2aWNl X25vZGUgKnNjbWlfbm9kZSwgdTY0ICphZGRyLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHU2NCAqc2l6ZSkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAq c2htZW1fbm9kZTsNCj4+ICsgICAgY29uc3QgX19iZTMyICpwcm9wOw0KPj4gKw0KPj4gKyAgICBw cm9wID0gZHRfZ2V0X3Byb3BlcnR5KHNjbWlfbm9kZSwgInNobWVtIiwgTlVMTCk7DQo+PiArICAg IGlmICggIXByb3AgKQ0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+PiArICAg IHNobWVtX25vZGUgPSBkdF9maW5kX25vZGVfYnlfcGhhbmRsZShiZTMyX3RvX2NwdSgqcHJvcCkp Ow0KPj4gKyAgICBpZiAoIElTX0VSUl9PUl9OVUxMKHNobWVtX25vZGUpICkNCj4+ICsgICAgew0K Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAic2NtaTog RGV2aWNlIHRyZWUgZXJyb3IsIGNhbid0IHBhcnNlIHJlc2VydmVkIG1lbW9yeSAlbGRcbiIsDQo+ PiArICAgICAgICAgICAgICAgUFRSX0VSUihzaG1lbV9ub2RlKSk7DQo+PiArICAgICAgICByZXR1 cm4gUFRSX0VSUihzaG1lbV9ub2RlKTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXR1cm4g ZHRfZGV2aWNlX2dldF9hZGRyZXNzKHNobWVtX25vZGUsIDAsIGFkZHIsIHNpemUpOw0KPj4gK30N Cj4+ICsNCj4+ICsvKg0KPj4gKyAqIEhhbmRsZSBEb20wIFNDTUkgc3BlY2lmaWMgRFQgbm9kZXMN Cj4+ICsgKg0KPj4gKyAqIE1ha2UgYSBkZWNpc2lvbiBvbiBjb3B5aW5nIFNDTUkgc3BlY2lmaWMg bm9kZXMgaW50byBEb20wIGRldmljZSB0cmVlLg0KPj4gKyAqIEZvciBTQ01JIG11bHRpLWFnZW50 IGNhc2U6DQo+PiArICogLSBzaG1lbSBub2RlcyB3aWxsIG5vdCBiZSBjb3BpZWQgYW5kIGdlbmVy YXRlZCBpbnN0ZWFkIGlmIFNDTUkNCj4+ICsgKiAgIGlzIGVuYWJsZWQgZm9yIERvbTANCj4+ICsg KiAtIHNjbWkgbm9kZSB3aWxsIGJlIGNvcGllZCBpZiBTQ01JIGlzIGVuYWJsZWQgZm9yIERvbTAN Cj4+ICsgKi8NCj4+ICtzdGF0aWMgYm9vbCBzY21pX2R0X2hhbmRsZV9ub2RlKHN0cnVjdCBkb21h aW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9kZSkNCj4+ICt7DQo+PiArICAgIHN0YXRp YyBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX21hdGNoIHNobWVtX21hdGNoZXNbXSBfX2luaXRjb25z dCA9IHsNCj4+ICsgICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoImFybSxzY21pLXNobWVtIiks DQo+PiArICAgICAgICB7IC8qIHNlbnRpbmVsICovIH0sDQo+PiArICAgIH07DQo+PiArICAgIHN0 YXRpYyBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX21hdGNoIHNjbWlfbWF0Y2hlc1tdIF9faW5pdGNv bnN0ID0gew0KPj4gKyAgICAgICAgRFRfTUFUQ0hfUEFUSCgiL2Zpcm13YXJlL3NjbWkiKSwNCj4+ ICsgICAgICAgIHsgLyogc2VudGluZWwgKi8gfSwNCj4+ICsgICAgfTsNCj4+ICsNCj4+ICsgICAg aWYgKCAhc2NtaV9kYXRhLmluaXRpYWxpemVkICkNCj4+ICsgICAgICAgIHJldHVybiBmYWxzZTsN Cj4+ICsNCj4+ICsgICAgLyogc2tpcCBzY21pIHNobWVtIG5vZGUgZm9yIGRvbTAgaWYgc2NtaSBu b3QgZW5hYmxlZCAqLw0KPj4gKyAgICBpZiAoIGR0X21hdGNoX25vZGUoc2htZW1fbWF0Y2hlcywg bm9kZSkgJiYgIXNjaV9kb21haW5faXNfZW5hYmxlZChkKSApDQo+PiArICAgIHsNCj4+ICsgICAg ICAgIGR0X2RwcmludGsoIiAgU2tpcCBzY21pIHNobWVtIG5vZGVcbiIpOw0KPj4gKyAgICAgICAg cmV0dXJuIHRydWU7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgLyogZHJvcCBzY21pIGlmIG5v dCBlbmFibGVkICovDQo+PiArICAgIGlmICggZHRfbWF0Y2hfbm9kZShzY21pX21hdGNoZXMsIG5v ZGUpICYmICFzY2lfZG9tYWluX2lzX2VuYWJsZWQoZCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAg ICBkdF9kcHJpbnRrKCIgIFNraXAgc2NtaSBub2RlXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiB0 cnVlOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiBmYWxzZTsNCj4+ICt9DQo+PiAr DQo+PiArc3RhdGljIGludCBzY21pX2Fzc2lnbl9kZXZpY2UodWludDMyX3QgYWdlbnRfaWQsIHVp bnQzMl90IGRldmljZV9pZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50 MzJfdCBmbGFncykNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX3NldF9kZXZp Y2VfcGVybWlzc2lvbnNfYTJwIHR4Ow0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFu bmVsOw0KPj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+PiArDQo+PiArICAgIGNoYW5u ZWwgPSBnZXRfY2hhbm5lbF9ieV9pZChzY21pX2RhdGEuaHlwX2NoYW5uZWxfYWdlbnRfaWQpOw0K Pj4gKyAgICBpZiAoICFjaGFubmVsICkNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4g Kw0KPj4gKyAgICBoZHIuaWQgPSBTQ01JX0JBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUzsNCj4+ ICsgICAgaGRyLnR5cGUgPSAwOw0KPj4gKyAgICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJP VE9DT0w7DQo+PiArDQo+PiArICAgIHR4LmFnZW50X2lkID0gYWdlbnRfaWQ7DQo+PiArICAgIHR4 LmRldmljZV9pZCA9IGRldmljZV9pZDsNCj4+ICsgICAgdHguZmxhZ3MgPSBmbGFnczsNCj4+ICsN Cj4+ICsgICAgcmV0dXJuIGRvX3NtY194ZmVyKGNoYW5uZWwsICZoZHIsICZ0eCwgc2l6ZW9mKHR4 KSwgTlVMTCwgMCk7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgc2NtaV9kdF9hc3NpZ25f ZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc3RydWN0IGR0X3BoYW5kbGVfYXJncyAqYWNfc3BlYykNCj4+ICt7DQo+PiArICAgIHN0 cnVjdCBzY21pX2NoYW5uZWwgKmFnZW50X2NoYW5uZWw7DQo+PiArICAgIHVpbnQzMl90IHNjbWlf ZGV2aWNlX2lkID0gYWNfc3BlYy0+YXJnc1swXTsNCj4+ICsgICAgaW50IHJldDsNCj4+ICsNCj4+ ICsgICAgaWYgKCAhZC0+YXJjaC5zY2lfZGF0YSApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ ICsNCj4+ICsgICAgLyogVGhlIGFjY2Vzcy1jb250cm9sbGVycyBpcyBzcGVjaWZpZWQgZm9yIERU IGRldiwgYnV0IGl0J3Mgbm90IGEgU0NNSSAqLw0KPj4gKyAgICBpZiAoICFzY21pX2RhdGEuZHRf ZGV2IHx8DQo+PiArICAgICAgICAgIWR0X25vZGVfcGF0aF9pc19lcXVhbChhY19zcGVjLT5ucCwg c2NtaV9kYXRhLmR0X2Rldi0+ZnVsbF9uYW1lKSApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ ICsNCj4+ICsgICAgYWdlbnRfY2hhbm5lbCA9IGQtPmFyY2guc2NpX2RhdGE7DQo+PiArDQo+PiAr ICAgIHNwaW5fbG9jaygmYWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+PiArDQo+PiArICAgIHJldCA9 IHNjbWlfYXNzaWduX2RldmljZShhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCwgc2NtaV9kZXZpY2Vf aWQsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTQ01JX0JBU0VfREVWSUNFX0FD Q0VTU19BTExPVyk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAg cHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAic2NtaTogY291bGQgbm90IGFz c2lnbiBkZXYgZm9yICVwZCBhZ2VudDolZCBkZXZfaWQ6JXUgKCVkKSIsDQo+PiArICAgICAgICAg ICAgICAgZCwgYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQsIHNjbWlfZGV2aWNlX2lkLCByZXQpOw0K Pj4gKyAgICB9DQo+PiArDQo+PiArICAgIHNwaW5fdW5sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2Nr KTsNCj4+ICsgICAgcmV0dXJuIHJldDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBjb2xs ZWN0X2FnZW50X2lkKHN0cnVjdCBzY21pX2NoYW5uZWwgKmFnZW50X2NoYW5uZWwpDQo+PiArew0K Pj4gKyAgICBpbnQgcmV0Ow0KPj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+PiArICAg IHN0cnVjdCBzY21pX21zZ19iYXNlX2Rpc2NvdmVyX2FnZW50X3AyYSBkYV9yeDsNCj4+ICsgICAg c3RydWN0IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdlbnRfYTJwIGRhX3R4Ow0KPj4gKw0KPj4g KyAgICByZXQgPSBtYXBfY2hhbm5lbF9tZW1vcnkoYWdlbnRfY2hhbm5lbCk7DQo+PiArICAgIGlm ICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgIGhkci5pZCA9 IFNDTUlfQkFTRV9ESVNDT1ZFUl9BR0VOVDsNCj4+ICsgICAgaGRyLnR5cGUgPSAwOw0KPj4gKyAg ICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+PiArDQo+PiArICAgIGRhX3R4 LmFnZW50X2lkID0gYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQ7DQo+PiArDQo+PiArICAgIHJldCA9 IGRvX3NtY194ZmVyKGFnZW50X2NoYW5uZWwsICZoZHIsICZkYV90eCwgc2l6ZW9mKGRhX3R4KSwg JmRhX3J4LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihkYV9yeCkpOw0KPj4g KyAgICBpZiAoIGFnZW50X2NoYW5uZWwtPmRvbWFpbl9pZCAhPSBET01JRF9YRU4gKQ0KPj4gKyAg ICAgICAgdW5tYXBfY2hhbm5lbF9tZW1vcnkoYWdlbnRfY2hhbm5lbCk7DQo+PiArICAgIGlmICgg cmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgIHByaW50ayhYRU5M T0dfREVCVUcgImlkPTB4JXggbmFtZT0lc1xuIiwgZGFfcnguYWdlbnRfaWQsIGRhX3J4Lm5hbWUp Ow0KPj4gKyAgICBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCA9IGRhX3J4LmFnZW50X2lkOw0KPj4g KyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIF9faW5pdCBpbnQgY29sbGVj dF9hZ2VudHMoc3RydWN0IGR0X2RldmljZV9ub2RlICpzY21pX25vZGUpDQo+PiArew0KPj4gKyAg ICBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmNvbmZpZ19ub2RlOw0KPj4gKyAgICBjb25z dCBfX2JlMzIgKnByb3A7DQo+PiArICAgIHVpbnQzMl90IGxlbjsNCj4+ICsgICAgY29uc3QgX19i ZTMyICplbmQ7DQo+PiArICAgIHVpbnQzMl90IGNlbGxzX3Blcl9lbnRyeSA9IDM7IC8qIERlZmF1 bHQgdG8gMyBjZWxscyBpZiBwcm9wZXJ0eSBpcyBhYnNlbnQuICovDQo+PiArDQo+PiArICAgIGNv bmZpZ19ub2RlID0gZHRfZmluZF9jb21wYXRpYmxlX25vZGUoTlVMTCwgTlVMTCwgInhlbixzY2ki KTsNCj4+ICsgICAgaWYgKCAhY29uZmlnX25vZGUgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBw cmludGsoWEVOTE9HX1dBUk5JTkcgInNjbWk6IHhlbixzY2kgbm9kZSBub3QgZm91bmQsIG5vIGFn ZW50cyB0byBjb2xsZWN0LlxuIik7DQo+PiArICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+ICsg ICAgfQ0KPj4gKw0KPj4gKyAgICAvKiBDaGVjayBmb3IgdGhlIG9wdGlvbmFsICcjc2NtaS1zZWNv bmRhcnktYWdlbnRzLWNlbGxzJyBwcm9wZXJ0eS4gKi8NCj4+ICsgICAgaWYgKCBkdF9wcm9wZXJ0 eV9yZWFkX3UzMihjb25maWdfbm9kZSwgIiNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMiLA0K Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZjZWxsc19wZXJfZW50cnkpICkNCj4+ ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCBjZWxsc19wZXJfZW50cnkgIT0gMiAmJiBjZWxsc19w ZXJfZW50cnkgIT0gMyApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgcHJpbnRrKFhF TkxPR19FUlIgInNjbWk6IEludmFsaWQgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyB2YWx1 ZTogJXVcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIGNlbGxzX3Blcl9lbnRyeSk7DQo+PiAr ICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ ICsNCj4+ICsgICAgcHJvcCA9IGR0X2dldF9wcm9wZXJ0eShjb25maWdfbm9kZSwgU0NNSV9TRUNP TkRBUllfQUdFTlRTLCAmbGVuKTsNCj4+ICsgICAgaWYgKCAhcHJvcCApDQo+PiArICAgIHsNCj4+ ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBObyAlcyBwcm9wZXJ0eSBmb3VuZCwg bm8gYWdlbnRzIHRvIGNvbGxlY3QuXG4iLA0KPj4gKyAgICAgICAgICAgICAgIFNDTUlfU0VDT05E QVJZX0FHRU5UUyk7DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4g Kw0KPj4gKyAgICAvKiBWYWxpZGF0ZSB0aGF0IHRoZSBwcm9wZXJ0eSBsZW5ndGggaXMgYSBtdWx0 aXBsZSBvZiB0aGUgY2VsbCBzaXplLiAqLw0KPj4gKyAgICBpZiAoIGxlbiA9PSAwIHx8IGxlbiAl IChjZWxsc19wZXJfZW50cnkgKiBzaXplb2YodWludDMyX3QpKSAhPSAwICkNCj4+ICsgICAgew0K Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IEludmFsaWQgbGVuZ3RoIG9mICVz IHByb3BlcnR5OiAldSBmb3IgJXUgY2VsbHMgcGVyIGVudHJ5XG4iLA0KPj4gKyAgICAgICAgICAg ICAgIFNDTUlfU0VDT05EQVJZX0FHRU5UUywgbGVuLCBjZWxsc19wZXJfZW50cnkpOw0KPj4gKyAg ICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgZW5kID0gKGNv bnN0IF9fYmUzMiAqKSgoY29uc3QgdTggKilwcm9wICsgbGVuKTsNCj4+ICsNCj4+ICsgICAgZm9y ICggOyBwcm9wIDwgZW5kOyApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHVpbnQzMl90IGFnZW50 X2lkOw0KPj4gKyAgICAgICAgdWludDMyX3Qgc21jX2lkOw0KPj4gKyAgICAgICAgdWludDMyX3Qg c2htZW1fcGhhbmRsZTsNCj4+ICsgICAgICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9kZTsN Cj4+ICsgICAgICAgIHU2NCBhZGRyLCBzaXplOw0KPj4gKyAgICAgICAgaW50IHJldDsNCj4+ICsg ICAgICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmFnZW50X2NoYW5uZWw7DQo+PiArDQo+PiArICAg ICAgICBzbWNfaWQgPSBiZTMyX3RvX2NwdSgqcHJvcCsrKTsNCj4+ICsgICAgICAgIHNobWVtX3Bo YW5kbGUgPSBiZTMyX3RvX2NwdSgqcHJvcCsrKTsNCj4+ICsNCj4+ICsgICAgICAgIGlmICggY2Vs bHNfcGVyX2VudHJ5ID09IDMgKQ0KPj4gKyAgICAgICAgICAgIGFnZW50X2lkID0gYmUzMl90b19j cHUoKnByb3ArKyk7DQo+PiArICAgICAgICBlbHNlDQo+PiArICAgICAgICAgICAgYWdlbnRfaWQg PSBTQ01JX0JBU0VfQUdFTlRfSURfT1dOOw0KPj4gKw0KPj4gKyAgICAgICAgbm9kZSA9IGR0X2Zp bmRfbm9kZV9ieV9waGFuZGxlKHNobWVtX3BoYW5kbGUpOw0KPj4gKyAgICAgICAgaWYgKCAhbm9k ZSApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNj bWk6IENvdWxkIG5vdCBmaW5kIHNobWVtIG5vZGUgZm9yIGFnZW50ICV1XG4iLA0KPj4gKyAgICAg ICAgICAgICAgICAgICBhZ2VudF9pZCk7DQo+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7 DQo+PiArICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICByZXQgPSBkdF9kZXZpY2VfZ2V0X2Fk ZHJlc3Mobm9kZSwgMCwgJmFkZHIsICZzaXplKTsNCj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+ ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAg ICAgICAgICAgICAgICAic2NtaTogQ291bGQgbm90IHJlYWQgc2htZW0gYWRkcmVzcyBmb3IgYWdl bnQgJXU6ICVkXG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICBhZ2VudF9pZCwgcmV0KTsNCj4+ ICsgICAgICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gKyAgICAg ICAgaWYgKCAhSVNfQUxJR05FRChzaXplLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKSB8fA0KPj4g KyAgICAgICAgICAgICAhSVNfQUxJR05FRChhZGRyLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKSAp DQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6 IHNobWVtIG1lbW9yeSBpcyBub3QgYWxpZ25lZFxuIik7DQo+PiArICAgICAgICAgICAgcmV0dXJu IC1FSU5WQUw7DQo+PiArICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICBhZ2VudF9jaGFubmVs ID0gc21jX2NyZWF0ZV9jaGFubmVsKGFnZW50X2lkLCBzbWNfaWQsIGFkZHIpOw0KPj4gKyAgICAg ICAgaWYgKCBJU19FUlIoYWdlbnRfY2hhbm5lbCkgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAg ICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBDb3VsZCBub3QgY3JlYXRlIGNoYW5uZWwg Zm9yIGFnZW50ICV1OiAlbGRcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIGFnZW50X2lkLCBQ VFJfRVJSKGFnZW50X2NoYW5uZWwpKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gUFRSX0VSUihh Z2VudF9jaGFubmVsKTsNCj4+ICsgICAgICAgIH0NCj4+ICsNCj4+ICsgICAgICAgIGlmICggY2Vs bHNfcGVyX2VudHJ5ID09IDIgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHJldCA9 IGNvbGxlY3RfYWdlbnRfaWQoYWdlbnRfY2hhbm5lbCk7DQo+PiArICAgICAgICAgICAgaWYgKCBy ZXQgKQ0KPj4gKyAgICAgICAgICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKyAgICAgICAgfQ0KPj4g Kw0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogQWdlbnQgJXUgU01DICVY IGFkZHIgJWx4XG4iLCBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCwNCj4+ICsgICAgICAgICAgICAg ICBzbWNfaWQsICh1bnNpZ25lZCBsb25nKWFkZHIpOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAg IHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IHNjbWlfZG9tYWluX2luaXQo c3RydWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0 IHhlbl9kb21jdGxfY3JlYXRlZG9tYWluICpjb25maWcpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3Qg c2NtaV9jaGFubmVsICpjaGFubmVsOw0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKw0KPj4gKyAgICBp ZiAoICFzY21pX2RhdGEuaW5pdGlhbGl6ZWQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiAr DQo+PiArICAgIC8qDQo+PiArICAgICAqIFNDTUkgc3VwcG9ydCBpcyBjb25maWd1cmVkIHZpYToN Cj4+ICsgICAgICogLSBGb3IgZG9tMDogeGVuLGRvbTAtc2NpLWFnZW50LWlkIHByb3BlcnR5IHVu ZGVyIHRoZSB4ZW4sc2NpIGNvbnRhaW5lcg0KPj4gKyAgICAgKiAtIEZvciBkb20wbGVzczogeGVu LHNjaS1hZ2VudC1pZCBpbiB0aGUgZG9tYWluIG5vZGUNCj4+ICsgICAgICogVGhlIGNvbmZpZy0+ YXJjaC5hcm1fc2NpX3R5cGUgYW5kIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkDQo+PiAr ICAgICAqIGFyZSBhbHJlYWR5IHNldCBieSBkb21haW5fYnVpbGQuYyBvciBkb20wbGVzcy1idWls ZC5jDQo+PiArICAgICAqLw0KPj4gKw0KPj4gKyAgICBpZiAoIGNvbmZpZy0+YXJjaC5hcm1fc2Np X3R5cGUgPT0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9OT05FICkNCj4+ICsgICAgICAgIHJl dHVybiAwOw0KPj4gKw0KPj4gKyAgICBjaGFubmVsID0gYWNxdWlyZV9zY21pX2NoYW5uZWwoZCwg Y29uZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQpOw0KPj4gKyAgICBpZiAoIElTX0VSUihjaGFu bmVsKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+PiArICAg ICAgICAgICAgICAgInNjbWk6IEZhaWxlZCB0byBhY3F1aXJlIFNDTUkgY2hhbm5lbCBmb3IgYWdl bnRfaWQgJXU6ICVsZFxuIiwNCj4+ICsgICAgICAgICAgICAgICBjb25maWctPmFyY2guYXJtX3Nj aV9hZ2VudF9pZCwgUFRSX0VSUihjaGFubmVsKSk7DQo+PiArICAgICAgICByZXR1cm4gUFRSX0VS UihjaGFubmVsKTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBwcmludGsoWEVOTE9HX0lORk8N Cj4+ICsgICAgICAgICAgICJzY21pOiBBY3F1aXJlIGNoYW5uZWwgaWQgPSAweCV4LCBkb21haW5f aWQgPSAlZCBwYWRkciA9IDB4JWx4XG4iLA0KPj4gKyAgICAgICAgICAgY2hhbm5lbC0+YWdlbnRf aWQsIGNoYW5uZWwtPmRvbWFpbl9pZCwgY2hhbm5lbC0+cGFkZHIpOw0KPj4gKw0KPj4gKyAgICAv Kg0KPj4gKyAgICAgKiBEb20wIChpZiBwcmVzZW50KSBuZWVkcyB0byBoYXZlIGFuIGFjY2VzcyB0 byB0aGUgZ3Vlc3QgbWVtb3J5IHJhbmdlDQo+PiArICAgICAqIHRvIHNhdGlzZnkgaW9tZW1fYWNj ZXNzX3Blcm1pdHRlZCgpIGNoZWNrIGluIFhFTl9ET01DVExfaW9tZW1fcGVybWlzc2lvbg0KPj4g KyAgICAgKiBkb21jdGwuDQo+PiArICAgICAqLw0KPj4gKyAgICBpZiAoIGhhcmR3YXJlX2RvbWFp biAmJiAhaXNfaGFyZHdhcmVfZG9tYWluKGQpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmV0 ID0gaW9tZW1fcGVybWl0X2FjY2VzcyhoYXJkd2FyZV9kb21haW4sIHBhZGRyX3RvX3BmbihjaGFu bmVsLT5wYWRkciksDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhZGRy X3RvX3BmbihjaGFubmVsLT5wYWRkciArDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUgLSAxKSk7DQo+PiArICAgICAgICBpZiAoIHJl dCApDQo+PiArICAgICAgICAgICAgZ290byBlcnJvcjsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAg ICBkLT5hcmNoLnNjaV9kYXRhID0gY2hhbm5lbDsNCj4+ICsgICAgZC0+YXJjaC5zY2lfZW5hYmxl ZCA9IHRydWU7DQo+PiArDQo+PiArICAgIHJldHVybiAwOw0KPj4gKw0KPj4gK2Vycm9yOg0KPj4g KyAgICByZWxpbnF1aXNoX3NjbWlfY2hhbm5lbChjaGFubmVsKTsNCj4+ICsgICAgcmV0dXJuIHJl dDsNCj4+ICt9DQo+PiArDQo+PiAraW50IHNjbWlfZG9tYWluX3Nhbml0aXNlX2NvbmZpZyhzdHJ1 Y3QgeGVuX2RvbWN0bF9jcmVhdGVkb21haW4gKmNvbmZpZykNCj4+ICt7DQo+PiArICAgIGlmICgg Y29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSAhPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05P TkUgJiYNCj4+ICsgICAgICAgICBjb25maWctPmFyY2guYXJtX3NjaV90eXBlICE9IFhFTl9ET01D VExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUNfTUEgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBk cHJpbnRrKFhFTkxPR19JTkZPLCAic2NtaTogVW5zdXBwb3J0ZWQgQVJNX1NDSSB0eXBlXG4iKTsN Cj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJl dHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IHNjbWlfcmVsaW5xdWlzaF9yZXNv dXJjZXMoc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+PiArICAgIGludCByZXQ7DQo+PiArICAg IHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWwsICphZ2VudF9jaGFubmVsOw0KPj4gKyAgICBz Y21pX21zZ19oZWFkZXJfdCBoZHI7DQo+PiArICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX3Jlc2V0 X2FnZW50X2NmZ19hMnAgdHg7DQo+PiArDQo+PiArICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEg KQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIGFnZW50X2NoYW5uZWwgPSBk LT5hcmNoLnNjaV9kYXRhOw0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2soJmFnZW50X2NoYW5uZWwt PmxvY2spOw0KPj4gKyAgICB0eC5hZ2VudF9pZCA9IGFnZW50X2NoYW5uZWwtPmFnZW50X2lkOw0K Pj4gKyAgICBzcGluX3VubG9jaygmYWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+PiArDQo+PiArICAg IGNoYW5uZWwgPSBnZXRfY2hhbm5lbF9ieV9pZChzY21pX2RhdGEuaHlwX2NoYW5uZWxfYWdlbnRf aWQpOw0KPj4gKyAgICBpZiAoICFjaGFubmVsICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJp bnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAic2NtaTogVW5hYmxlIHRvIGdldCBI eXBlcnZpc29yIHNjbWkgY2hhbm5lbCBmb3IgZG9tYWluICVkXG4iLA0KPj4gKyAgICAgICAgICAg ICAgIGQtPmRvbWFpbl9pZCk7DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAg fQ0KPj4gKw0KPj4gKyAgICBoZHIuaWQgPSBTQ01JX0JBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJB VElPTjsNCj4+ICsgICAgaGRyLnR5cGUgPSAwOw0KPj4gKyAgICBoZHIucHJvdG9jb2wgPSBTQ01J X0JBU0VfUFJPVE9DT0w7DQo+PiArDQo+PiArICAgIHR4LmZsYWdzID0gU0NNSV9CQVNFX0FHRU5U X1BFUk1JU1NJT05TX1JFU0VUOw0KPj4gKw0KPj4gKyAgICByZXQgPSBkb19zbWNfeGZlcihjaGFu bmVsLCAmaGRyLCAmdHgsIHNpemVvZih0eCksIE5VTEwsIDApOw0KPj4gKyAgICBpZiAoIHJldCA9 PSAtRU9QTk9UU1VQUCApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgcmV0 dXJuIHJldDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHZvaWQgc2NtaV9kb21haW5fZGVzdHJv eShzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAq Y2hhbm5lbDsNCj4+ICsNCj4+ICsgICAgaWYgKCAhZC0+YXJjaC5zY2lfZGF0YSApDQo+PiArICAg ICAgICByZXR1cm47DQo+PiArDQo+PiArICAgIGNoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0K Pj4gKyAgICBzcGluX2xvY2soJmNoYW5uZWwtPmxvY2spOw0KPj4gKw0KPj4gKyAgICByZWxpbnF1 aXNoX3NjbWlfY2hhbm5lbChjaGFubmVsKTsNCj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAi c2NtaTogRnJlZSBkb21haW4gJWRcbiIsIGQtPmRvbWFpbl9pZCk7DQo+PiArDQo+PiArICAgIGQt PmFyY2guc2NpX2RhdGEgPSBOVUxMOw0KPj4gKyAgICBkLT5hcmNoLnNjaV9lbmFibGVkID0gZmFs c2U7DQo+PiArDQo+PiArICAgIHNwaW5fdW5sb2NrKCZjaGFubmVsLT5sb2NrKTsNCj4+ICt9DQo+ PiArDQo+PiArc3RhdGljIGJvb2wgc2NtaV9oYW5kbGVfY2FsbChzdHJ1Y3QgY3B1X3VzZXJfcmVn cyAqcmVncykNCj4+ICt7DQo+PiArICAgIHVpbnQzMl90IGZpZCA9ICh1aW50MzJfdClnZXRfdXNl cl9yZWcocmVncywgMCk7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmFnZW50X2NoYW5u ZWw7DQo+PiArICAgIHN0cnVjdCBkb21haW4gKmQgPSBjdXJyZW50LT5kb21haW47DQo+PiArICAg IGJvb2wgcmVzID0gZmFsc2U7DQo+PiArDQo+PiArICAgIGlmICggKCFzY2lfZG9tYWluX2lzX2Vu YWJsZWQoZCkpIHx8ICghZC0+YXJjaC5zY2lfZGF0YSkgKQ0KPj4gKyAgICAgICAgcmV0dXJuIGZh bHNlOw0KPj4gKw0KPj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsNCj4+ ICsgICAgc3Bpbl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgaWYg KCBhZ2VudF9jaGFubmVsLT5mdW5jX2lkICE9IGZpZCApDQo+PiArICAgIHsNCj4+ICsgICAgICAg IHJlcyA9IGZhbHNlOw0KPj4gKyAgICAgICAgZ290byB1bmxvY2s7DQo+PiArICAgIH0NCj4+ICsN Cj4+ICsgICAgYXJtX3NtY2NjX2d1ZXN0X3NtYyhyZWdzKTsNCj4+ICsgICAgcmVzID0gdHJ1ZTsN Cj4+ICt1bmxvY2s6DQo+PiArICAgIHNwaW5fdW5sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsN Cj4+ICsNCj4+ICsgICAgcmV0dXJuIHJlczsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGNvbnN0 IHN0cnVjdCBzY2lfbWVkaWF0b3Jfb3BzIHNjbWlfb3BzID0gew0KPj4gKyAgICAuZG9tYWluX2lu aXQgPSBzY21pX2RvbWFpbl9pbml0LA0KPj4gKyAgICAuZG9tYWluX2Rlc3Ryb3kgPSBzY21pX2Rv bWFpbl9kZXN0cm95LA0KPj4gKyAgICAucmVsaW5xdWlzaF9yZXNvdXJjZXMgPSBzY21pX3JlbGlu cXVpc2hfcmVzb3VyY2VzLA0KPj4gKyAgICAuaGFuZGxlX2NhbGwgPSBzY21pX2hhbmRsZV9jYWxs LA0KPj4gKyAgICAuZG9tMF9kdF9oYW5kbGVfbm9kZSA9IHNjbWlfZHRfaGFuZGxlX25vZGUsDQo+ PiArICAgIC5kb21haW5fc2FuaXRpc2VfY29uZmlnID0gc2NtaV9kb21haW5fc2FuaXRpc2VfY29u ZmlnLA0KPj4gKyAgICAuYXNzaWduX2R0X2RldmljZSA9IHNjbWlfZHRfYXNzaWduX2RldmljZSwN Cj4+ICt9Ow0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgX19pbml0IHNjbWlfY2hlY2tfc21jY2NfdmVy KHZvaWQpDQo+PiArew0KPj4gKyAgICBpZiAoIHNtY2NjX3ZlciA8IEFSTV9TTUNDQ19WRVJTSU9O XzFfMSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORw0KPj4g KyAgICAgICAgICAgICAgICJzY21pOiBObyBTTUNDQyAxLjEgc3VwcG9ydCwgU0NNSSBjYWxscyBm b3J3YXJkaW5nIGRpc2FibGVkXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PU1lTOw0KPj4g KyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMg aW50IF9faW5pdCBzY21pX2R0X2h5cF9jaGFubmVsX3JlYWQoc3RydWN0IGR0X2RldmljZV9ub2Rl ICpzY21pX25vZGUsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHN0cnVjdCBzY21pX2RhdGEgKnNjbWlfZGF0YSwNCj4+ICsgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdTY0ICphZGRyKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJl dDsNCj4+ICsgICAgdTY0IHNpemU7DQo+PiArDQo+PiArICAgIGlmICggIWR0X3Byb3BlcnR5X3Jl YWRfdTMyKHNjbWlfbm9kZSwgImFybSxzbWMtaWQiLCAmc2NtaV9kYXRhLT5mdW5jX2lkKSApDQo+ PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiB1bmFibGUgdG8g cmVhZCBzbWMtaWQgZnJvbSBEVFxuIik7DQo+PiArICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+ ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXQgPSBzY21pX2R0X3JlYWRfaHlwX2NoYW5uZWxfYWRk cihzY21pX25vZGUsIGFkZHIsICZzaXplKTsNCj4+ICsgICAgaWYgKCBJU19FUlJfVkFMVUUocmV0 KSApDQo+PiArICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+ICsNCj4+ICsgICAgaWYgKCAhSVNf QUxJR05FRChzaXplLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKSApDQo+PiArICAgIHsNCj4+ICsg ICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBzaG1lbSBtZW1vcnkgaXMgbm90IGFsaWdu ZWRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsNCj4+ ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBfX2luaXQgaW50IHNjbWlf cHJvYmUoc3RydWN0IGR0X2RldmljZV9ub2RlICpzY21pX25vZGUsIGNvbnN0IHZvaWQgKmRhdGEp DQo+PiArew0KPj4gKyAgICB1NjQgYWRkcjsNCj4+ICsgICAgaW50IHJldDsNCj4+ICsgICAgc3Ry dWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+ICsgICAgdW5zaWduZWQgaW50IG5fYWdlbnRz Ow0KPj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+PiArICAgIHN0cnVjdCBzY21pX21z Z19iYXNlX2F0dHJpYnV0ZXNfcDJhIHJ4Ow0KPj4gKw0KPj4gKyAgICBBU1NFUlQoc2NtaV9ub2Rl ICE9IE5VTEwpOw0KPj4gKw0KPj4gKyAgICAvKg0KPj4gKyAgICAgKiBPbmx5IGJpbmQgdG8gdGhl IFNDTUkgbm9kZSBwcm92aWRlZCBieSBYZW4gdW5kZXIgdGhlIHhlbixzY2kgY29udGFpbmVyDQo+ PiArICAgICAqIChlLmcuIC9jaG9zZW4veGVuL3hlbl9zY21pX2NvbmZpZy9zY21pKS4gVGhpcyBh dm9pZHMgYmluZGluZyB0byBmaXJtd2FyZQ0KPj4gKyAgICAgKiBTQ01JIG5vZGVzIHRoYXQgYmVs b25nIHRvIHRoZSBob3N0IE9TUE0gYW5kIGtlZXBzIHRoZSBtZWRpYXRvciBzY29wZWQgdG8NCj4+ ICsgICAgICogWGVuLXByb3ZpZGVkIGNvbmZpZ3VyYXRpb24gb25seS4NCj4+ICsgICAgICovDQo+ PiArICAgIGlmICggIXNjbWlfaXNfdW5kZXJfeGVuX3NjaShzY21pX25vZGUpICkNCj4+ICsgICAg ICAgIHJldHVybiAtRU5PREVWOw0KPj4gKw0KPj4gKyAgICBpZiAoICFhY3BpX2Rpc2FibGVkICkN Cj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJzY21pOiBpcyBu b3Qgc3VwcG9ydGVkIHdoZW4gdXNpbmcgQUNQSVxuIik7DQo+PiArICAgICAgICByZXR1cm4gLUVJ TlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXQgPSBzY21pX2NoZWNrX3NtY2NjX3Zl cigpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0K Pj4gKyAgICByZXQgPSBzY21pX2R0X2h5cF9jaGFubmVsX3JlYWQoc2NtaV9ub2RlLCAmc2NtaV9k YXRhLCAmYWRkcik7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7 DQo+PiArDQo+PiArICAgIElOSVRfTElTVF9IRUFEKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0KTsN Cj4+ICsgICAgc3Bpbl9sb2NrX2luaXQoJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+ PiArDQo+PiArICAgIHNjbWlfZGF0YS5kdF9kZXYgPSBzY21pX25vZGU7DQo+PiArDQo+PiArICAg IGNoYW5uZWwgPSBzbWNfY3JlYXRlX2NoYW5uZWwoU0NNSV9CQVNFX0FHRU5UX0lEX09XTiwgc2Nt aV9kYXRhLmZ1bmNfaWQsIGFkZHIpOw0KPj4gKyAgICBpZiAoIElTX0VSUihjaGFubmVsKSApDQo+ PiArICAgIHsNCj4+ICsgICAgICAgIHJldCA9IFBUUl9FUlIoY2hhbm5lbCk7DQo+PiArICAgICAg ICBnb3RvIG91dDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICAvKiBNYXJrIGFzIFhlbiBtYW5h Z2VtZW50IGNoYW5uZWwgYmVmb3JlIGNvbGxlY3RpbmcgYWdlbnQgSUQgKi8NCj4+ICsgICAgY2hh bm5lbC0+ZG9tYWluX2lkID0gRE9NSURfWEVOOw0KPj4gKw0KPj4gKyAgICAvKiBSZXF1ZXN0IGFn ZW50IGlkIGZvciBYZW4gbWFuYWdlbWVudCBjaGFubmVsICovDQo+PiArICAgIHJldCA9IGNvbGxl Y3RfYWdlbnRfaWQoY2hhbm5lbCk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGdv dG8gZXJyb3I7DQo+PiArDQo+PiArICAgIC8qIFNhdmUgdGhlIGFnZW50IGlkIGZvciBYZW4gbWFu YWdlbWVudCBjaGFubmVsICovDQo+PiArICAgIHNjbWlfZGF0YS5oeXBfY2hhbm5lbF9hZ2VudF9p ZCA9IGNoYW5uZWwtPmFnZW50X2lkOw0KPj4gKw0KPj4gKyAgICBoZHIuaWQgPSBTQ01JX0JBU0Vf UFJPVE9DT0xfQVRUSUJVVEVTOw0KPj4gKyAgICBoZHIudHlwZSA9IDA7DQo+PiArICAgIGhkci5w cm90b2NvbCA9IFNDTUlfQkFTRV9QUk9UT0NPTDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gZG9fc21j X3hmZXIoY2hhbm5lbCwgJmhkciwgTlVMTCwgMCwgJnJ4LCBzaXplb2YocngpKTsNCj4+ICsgICAg aWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBlcnJvcjsNCj4+ICsNCj4+ICsgICAgbl9hZ2Vu dHMgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0JBU0VfQVRUUl9OVU1fQUdFTlQsIHJ4LmF0dHJpYnV0 ZXMpOw0KPj4gKyAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBHb3QgYWdlbnQgY291bnQg JWRcbiIsIG5fYWdlbnRzKTsNCj4+ICsgICAgcmV0ID0gY29sbGVjdF9hZ2VudHMoc2NtaV9ub2Rl KTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBlcnJvcjsNCj4+ICsNCj4+ ICsgICAgcmV0ID0gc2NpX3JlZ2lzdGVyKCZzY21pX29wcyk7DQo+PiArICAgIGlmICggcmV0ICkN Cj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgIlNDTUk6IG1lZGlhdG9y IGFscmVhZHkgcmVnaXN0ZXJlZCAocmV0ID0gJWQpXG4iLA0KPj4gKyAgICAgICAgICAgICAgIHJl dCk7DQo+PiArICAgICAgICBnb3RvIGVycm9yOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHNj bWlfZGF0YS5pbml0aWFsaXplZCA9IHRydWU7DQo+PiArICAgIGdvdG8gb3V0Ow0KPj4gKw0KPj4g K2Vycm9yOg0KPj4gKyAgICB1bm1hcF9jaGFubmVsX21lbW9yeShjaGFubmVsKTsNCj4+ICsgICAg ZnJlZV9jaGFubmVsX2xpc3QoKTsNCj4+ICtvdXQ6DQo+PiArICAgIHJldHVybiByZXQ7DQo+PiAr fQ0KPj4gKw0KPj4gK3N0YXRpYyBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX21hdGNoIHNjbWlfc21j X21hdGNoW10gX19pbml0Y29uc3QgPSB7DQo+PiArICAgIERUX01BVENIX0NPTVBBVElCTEUoImFy bSxzY21pLXNtYyIpLA0KPj4gKyAgICB7IC8qIHNlbnRpbmVsICovIH0sDQo+PiArfTsNCj4+ICsN Cj4+ICtEVF9ERVZJQ0VfU1RBUlQoc2NtaV9zbWNfbWEsICJTQ01JIFNNQyBNRURJQVRPUiIsIERF VklDRV9GSVJNV0FSRSkNCj4+ICsgICAgICAgIC5kdF9tYXRjaCA9IHNjbWlfc21jX21hdGNoLA0K Pj4gKyAgICAgICAgLmluaXQgPSBzY21pX3Byb2JlLA0KPj4gK0RUX0RFVklDRV9FTkQNCj4+ICsN Cj4+ICsvKg0KPj4gKyAqIExvY2FsIHZhcmlhYmxlczoNCj4+ICsgKiBtb2RlOiBDDQo+PiArICog Yy1maWxlLXN0eWxlOiAiQlNEIg0KPj4gKyAqIGMtYmFzaWMtb2Zmc2V0OiA0DQo+PiArICogdGFi LXdpZHRoOiA0DQo+PiArICogaW5kZW50LXRhYnMtbW9kZTogbmlsDQo+PiArICogRW5kOg0KPj4g KyAqLw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oIGIveGVu L2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgNCj4+IGluZGV4IDFmYzY3NmZkOTYuLmE5YTEwYTNi OGQgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaA0KPj4gKysr IGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgNCj4+IEBAIC0zMjksNiArMzI5LDcgQEAg REVGSU5FX1hFTl9HVUVTVF9IQU5ETEUodmNwdV9ndWVzdF9jb250ZXh0X3QpOw0KPj4NCj4+ICAg I2RlZmluZSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkUgICAgICAwDQo+PiAgICNkZWZp bmUgWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQyAgMQ0KPj4gKyNkZWZpbmUgWEVO X0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19NQSAgMg0KPj4NCj4+ICAgI2RlZmluZSBY RU5fRE9NQ1RMX0NPTkZJR19BUk1fVjhSX0VMMV9NU0FfTk9ORSAgICAwDQo+PiAgICNkZWZpbmUg WEVOX0RPTUNUTF9DT05GSUdfQVJNX1Y4Ul9FTDFfTVNBX1BNU0EgICAgMQ0KPj4gQEAgLTM2MSw3 ICszNjIsOSBAQCBzdHJ1Y3QgeGVuX2FyY2hfZG9tYWluY29uZmlnIHsNCj4+ICAgICAgIHVpbnQ4 X3QgYXJtX3NjaV90eXBlOw0KPj4gICAgICAgLyogSU4gKi8NCj4+ICAgICAgIHVpbnQ4X3Qgdjhy X2VsMV9tc2E7DQo+PiAtICAgIHVpbnQxNl90IHBhZDsNCj4+ICsgICAgLyogSU4gKi8NCj4+ICsg ICAgdWludDhfdCBhcm1fc2NpX2FnZW50X2lkOw0KPj4gKyAgICB1aW50OF90IHBhZDsNCj4+ICAg fTsNCj4+ICAgI2VuZGlmIC8qIF9fWEVOX18gfHwgX19YRU5fVE9PTFNfXyAqLw0K From xen-devel-bounces@lists.xenproject.org Wed Sep 23 08:43:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 08:43:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429874.1652492 (Exim 4.92) (envelope-from ) id 1x9IZp-0006Ch-9b; Wed, 23 Sep 2026 08:43:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429874.1652492; Wed, 23 Sep 2026 08:43:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9IZp-0006Ca-6m; Wed, 23 Sep 2026 08:43:41 +0000 Received: by outflank-mailman (input) for mailman id 1429874; Wed, 23 Sep 2026 08:43:40 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9IZn-0006CU-Tc for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 08:43:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9IZm-00CQl5-Pq for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:43:38 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39139-2eae-0a2a0a5409dd-0a2a4508abd6-12 for ; Wed, 23 Sep 2026 10:43:38 +0200 Received: from [40.107.159.91] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3913a-f659-0a2a45080019-286b9f5bd213-3 for ; Wed, 23 Sep 2026 10:43:38 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by AM7PR03MB6279.eurprd03.prod.outlook.com (2603:10a6:20b:133::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 08:43:35 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 08:43:35 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UHlOvASWQf/r+mYyjBc9XNX23NQzvBDsVBdd0GyVfVwhpQoSwuA7jdNWOMv+y4HRbsgs3G6sa39m3/Zn/HqHyO09FKDx/SC5vbnTHGkA9WPy7n+PZzgLx/y9503sk3GIKPObjRuYzTO4QIePYpeeFWcnpur+P7Aj5JOoZQG57ChtgTRW0sX+loGD7PH0/NDoEPZ6sAwmNBCAjOIr5cXz6mKgFFAXQSjqAUv3xw+vWHTjaizqiEX/PEemN6SA+hjPFja8oXJ41x1jIg8YHb4QVeSPHlbJ7Wtsz8UApykfvhBmvwyGxxzi0vJ3aDeZq3WFcZQJMjAowHVnXZZ9A9vPEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=n64lJMbCAgVr7AruNYNLVvzSp1ZgFlsjaz/G2tQ6xVk=; b=Hxk2otKgTElviO4vIyNToxxp/xGV4L7pn9gxDh3wXjFZFu2L/3UnB04Zf4wwNljrTCyc5dZfmU77NqnIrNSlZN1pPfufbONvUbHJcbwUh4nGKNdTBn8x4IooCaKK7cLHTTyJXDJ7pJQaMjO95Dc99K77kQzU4wdQ6N6OwsshLX+9o1FnkThmhHTBrwlrE3hH3En5lUolvXOvFKk2iHVYT1MqybUlg5l/m/o/CjZdPO4TA340DTxFFtEWExOSTMFmYbrOXazVXTS7GhJjVvGB4thvyALO7g5IjlmmTgBLS8OLLY43gguT+DOY7Jy5KMPdd8YW4/PG7l4yDkE2n3T4pQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n64lJMbCAgVr7AruNYNLVvzSp1ZgFlsjaz/G2tQ6xVk=; b=XFgPPQIIWPQq96Y+Y5UuTw5u+sn+8Pfd132G0e+XUPZEliq6iMWoBIYZTfM5Pdqa18LWvT8cbODHKmfvDEyQ7VlXPDGWQcbCsoeJfDzIZVrBN8xJ+IMShBRavXiWz3q3WP4kF51Q1a7f6fqDF6gNczxYvQ/AGYytkNeul6SsrPVFM2uwK7PWuPzKvFOx6Czk+rrGGl1rsKAMVn0u0euSq5zA54nSxX3XSQdT+494n96IJRjR0PLgwL3bgqnYf70COWtUAeH3sADYWyALkgRHEDJqFVdcjzdHD9eX+rak8H5fMOW6pvREtbvRmlrVYGvibPLRaa3r24scr6iVB2tQgA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Wed, 23 Sep 2026 11:43:31 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH v4 1/4] xen/arm: make is_espi() a pure range predicate Message-ID: Mail-Followup-To: "Orzel, Michal" , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <802ae2dd44556a292d98f1d52d3c88ce4fa5034b.1790056623.git.mykola_kvach@epam.com> <52255065-80db-4dae-8406-b1f75614ef9a@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52255065-80db-4dae-8406-b1f75614ef9a@amd.com> X-ClientProxiedBy: WA2PEPF000008BF.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::699) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|AM7PR03MB6279:EE_ X-MS-Office365-Filtering-Correlation-Id: 8c9da111-e4a2-4c49-c169-08df194ec165 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|10067099003|56012099006|11063799006|22082099003|18002099003|4143699003; X-Microsoft-Antispam-Message-Info: gzre40hNQPUASRVmoVOvgxBU05r+Yk2MYR6bu1MESkRwNpjsobpT0HYxDV1vdNUl2QNErJC0k+dMzxI0nXhJfmKvw3l40/zfFjQVzL7Q5N60jKzR1ZbAcSzKtL2NJLqVguTpm+wbMybbPH5aZGWwchNpE72AxhVIqlgc2gYjsdF6ZrcnoVii7AJyWw0w4+/tdOgWck4V0DyeSab1dRJ07KIXX0nYg9Cf/RygIfbuLJT0EIzYYkKzA7vtDBsP26OtiptWS/CUSnSiiWp1zif1UgEqe/YxB5GvBHsXPwSRF4WHbwEmc54tXQUDP6QlMqI3/X3yy2sfyFuP52Otg37hG7PmknuPhulVbwOKhC/GICk4kHz8xiLX1U1nByd03IGEA6veumtnosGDMlO9B49TGpnPIs3qHE4cGe6p8BwR0ePt0k9U8ddSb9CX6ofTfW8z/MEDcjeWAKQE+T+H7AvMDm4i+odq85kMyW0CSG2aRjCtzLaMccL254Zdi56RrmI6IhkHoeAqNq4o9EXTw6UUWXOzNhJqAL4vtRQ3MyghVhDvVmuBiI5nTe1ZMj4osRNuwT9qOyQEjAcu0wUOzhGw3lAgqCIp3q5ODiLdzupHLo43dYT+YWVeTSBGmSKi6n4V6ehXC6pnGdTOiPBNW22L+2F57bTslFjEd/kEHqzZU30= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003)(4143699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UFZhNHZoMEltRHpCZDVtWStXeXFxZjJDYTJ1RkxFSE9saUVnRldaWlhmWVdN?= =?utf-8?B?V0Y5eWkwM1l6eFFLTkhxMFYzanlJMFJlOURpR3g1R0w1ckIvQXFDcnJiOXRL?= =?utf-8?B?MnVvdjg2UFQwaE1HbVg5MHE2Mis1dUZJOW45Q09xcVR3dFFYMWpOYWZBQUFa?= =?utf-8?B?YzAvRWtueno0MDZDcDU1R0Z5S1Y3UUVjTkEvNnRWVkxicldWYmJXYmtXVHN4?= =?utf-8?B?NG9sQmdHcWtjTG5LaEluSDBsVmkveFZIdGxoUVhTS0FuOGFOMUtmblRSeXFm?= =?utf-8?B?cTROelVNUHJYTXM0SU9kdkNOSWlBYzU1ZkVrWm1DdlExS3FReDZkczN0YnNs?= =?utf-8?B?b09DelUyTnlqUnVxWC93bXJYNFNlaElCQ0RwVDBMQ0pmRDdnQ2dFOFdrb1Rm?= =?utf-8?B?Nm9mNHN6dUxsR0FsRXpEZ3laSENqcmJsSUo0NDNxSzREV1RraWQ2YklnYnhi?= =?utf-8?B?NHhuVEJWZXJyNVh1WTRzVytkKzVMZ0gvOFRQRDNNd1lLMXVXYXdYWjV4OTlk?= =?utf-8?B?MnlKaDRSZHVMOG9ta1pDWC9wK3l0bXIyM2lQRXMrcWZ3TGQ1dUpHMDZoS2RS?= =?utf-8?B?cGxPQXgzQnY3cWovalRPajNSWTdtcnBnVDVzNjlWbVJYeFA2MVdhUTJ0TEZB?= =?utf-8?B?S2FZTGRrbkYvVzNrelVKa2xCbVNWWWVhdFVBSC9wVWhFVGV4OXFYN2tIL3hk?= =?utf-8?B?TnFTeGd4YmhkRlNmaUFtajNnZXFHV3h4dzJNWlZoMk5ESW85eC81Y3N5QTM2?= =?utf-8?B?UmJobEdGNjE4ODgwQVRCNEFHRTcyMDVWTlI1ZkZJeTJhTXJyMHZRNFh5ekNa?= =?utf-8?B?Q2pocExKc0lHK2YzYUhjNXNrdFFjZTFqckwzeUl4TUhqOUhCWVc2aWdMN1oy?= =?utf-8?B?MlFxMHdSTEdPOVlMWFJlZVFTOXVXQUQ4V1FUbHRXUWFYc1diM1MrMm1KSlln?= =?utf-8?B?eng3SlBvU0RkSmo2SDZIVVp1bmIyb0hpTC94a1RCdWJHeGtOcEhoVDV6aXQ1?= =?utf-8?B?djZIek1pNjk2YWdSeGJoWGZPL1VFYnRFQVptVWNMQ2tPbE5TTmhKL1JUblNT?= =?utf-8?B?OUZzWWZQNUhIRUZ5QVV2VnYyTjdZTUEvTWVIU0lFR0tNZkJ6OUVuYTlmQ1B6?= =?utf-8?B?eThYMTZIM0NLMG5OUTgrelBjS3pYeFBBWVZDbGxaOFM0YW9vdTVCL2I5N0xU?= =?utf-8?B?cmY5RjZQM3QrcXk0R1k1NmQvRTl2dFJScmVvV3c5MHdzbUZaNDQ3bGhSRnAz?= =?utf-8?B?MkpGYTVGV0ppR0ZvRkRlQWdjanlEdGVDUFlRZmI2WUh5VWNjMkE3MXg0a3dx?= =?utf-8?B?ZW1sZjZ4NCtXYUNOODlFd2h3Skszc004NjA4Nk5LWDE0TndHUCtmUUZ4NDZL?= =?utf-8?B?ZWVDdE5Dd2E3SkxZc0tScnNRd3ZVSHNRZFJmcXl6MGQ5a1FrRXArYVdqS053?= =?utf-8?B?eG01eFprcDFQemxQMGpRK2ZLS2ZOaUgwb2dBMVpueDBiUi9BcTlhdzI3ZzJm?= =?utf-8?B?L2VMOXo5ZzE1c0FtM2owR2cvVjlYVUR2MXp5RHVlVlUwVnFabjZPalFDNEdC?= =?utf-8?B?V0FtRjFOR1ZLaDZhcm1uUUtPOExFWVJwZmZRS2VVbG11dldGNHJWandhZ0lU?= =?utf-8?B?OVpQZ251b1lnRzhER0E0eGM4Q240bTdkczZSMk1YYzVxellod0QwaWgvTmcr?= =?utf-8?B?enRmQ3lQZjJzTXk1NGdURG1FMUNiQzg0MDRTUjBHOXVSMVpyb0ltTEUwSVkw?= =?utf-8?B?SzNxMnVZeHVPZTcwNnpBWjlzWXZrU2o1K1hQN1BOaTlxdHAxMjBlOVF4NXhX?= =?utf-8?B?K1FzRkdvV3FyeHg1Y09ZY3U1M2JRSXZWcHFDNU5IVS9jbGs4YXA0TXBLT3hB?= =?utf-8?B?MkkzSnNyVmV1Z09HZEI5NE5PT2ZIMWZ6WmRpNk5IQzRZZGtwb01zckhYVSsy?= =?utf-8?B?Vm85VHFQUkpZbHg2WmM4c01BR1k2cVY1WHVyYjQvWmJRM0thMVEwejRwT0J0?= =?utf-8?B?VDZxaUNUWnJEVUppUm5LYjI3cFpUcCtkaWtkVC9hbWdUMW1IcmJyN2U0THRU?= =?utf-8?B?Z3lxWDM1RlRqcUZMbzVhdmdIQTZYSGpYZ1BjSEFqZXAzTGM0ekxTRDByNE1m?= =?utf-8?B?Z21qWmxVcFE5blI2MFEySFZUNGlDaDhEUC9iZ0xmQXNNY3AvdzIvNy9kbkFh?= =?utf-8?B?MVlWK1h1SytzaGM3Y3RuSzNpNlNaNWJabkRkY3VEMmpXcGdXL1IwekFicnlo?= =?utf-8?B?UGtqSERrQnQxaiszV2dKVXNjOU1HQkhpU1RydHkyOXNjNklqY0g3ZWwxZk51?= =?utf-8?B?VTErMzYyVmY0VkFIWUh3OVkzc3FJVEIveFNaVy9hNGFUNTFWZVJIQT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c9da111-e4a2-4c49-c169-08df194ec165 X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 08:43:35.4563 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: MzfDjK47x4kzsC+5OtihB/fYlL+oSt3Bkg7F+lxsHLiJN0+CgQ40NmFkBIamrGUrJ3KFrIFVKFiATvQ1tpjfwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6279 X-purgate-ID: tlsNG-c1860d/1790153018-CE94287B-CA610B2B/0/0 X-purgate-type: clean X-purgate-size: 5224 Hi Michal, Thank you for the review. On Tue, Sep 22, 2026 at 01:19:57PM +0200, Orzel, Michal wrote: > > > On 22-Sep-26 08:39, Mykola Kvach wrote: > > is_espi() currently changes its result according to CONFIG_GICV3_ESPI. > > Without eSPI support, it returns false, and its assertion fails if > > an eSPI INTID is passed. Callers therefore use it both to identify > > eSPIs and to exclude eSPI handling when support is disabled. > > > > Make is_espi() report only whether an INTID is in the architectural > > eSPI range. Check for eSPI support at the call sites. > > > > Use BUG_ON() if the GIC reports an eSPI without compiled-in support, > > matching the handling of unsupported LPIs. Return NULL from > > spi_to_pending() for an eSPI when support is disabled, using an > > espi_to_pending() stub. > > > > Signed-off-by: Mykola Kvach > > --- > > Changes in v4: > > - Clarify the existing is_espi() behavior in the commit message. > > - Drop the unrelated blank-line removal in vgic.c. > > - Use BUG_ON() if the GIC reports an eSPI without eSPI support. > > - Drop the redundant CONFIG_GICV3_ESPI check in IRQ dispatch. > > - Return NULL for virtual eSPI lookup when eSPI support is disabled. > > > > Changes in v3: > > - New preparatory cleanup requested during review. > > --- > > xen/arch/arm/gic.c | 2 ++ > > xen/arch/arm/include/asm/irq.h | 11 ----------- > > xen/arch/arm/vgic.c | 30 ++++++++++++++++-------------- > > 3 files changed, 18 insertions(+), 25 deletions(-) > > > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > > index 078049e741..3a7f972826 100644 > > --- a/xen/arch/arm/gic.c > > +++ b/xen/arch/arm/gic.c > > @@ -348,6 +348,8 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq) > > /* Reading IRQ will ACK it */ > > irq = gic_hw_ops->read_irq(); > > > > + BUG_ON(!IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); > Usually BUG() should come with a comment explaining why we cannot continue. Here > it's that without config enabled, there's no descriptor and no pending_irq > storage for it. Please add a comment. Ack. > > > + > > if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(irq) ) > > { > > isb(); > > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h > > index 09788dbfeb..c29f3d04a3 100644 > > --- a/xen/arch/arm/include/asm/irq.h > > +++ b/xen/arch/arm/include/asm/irq.h > > @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq) > > > > static inline bool is_espi(unsigned int irq) > > { > > -#ifdef CONFIG_GICV3_ESPI > > return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID; > > -#else > > - /* > > - * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is > > - * disabled. Returning false allows the compiler to optimize the code > > - * when the config is disabled, while the assert ensures that out-of-range > > - * array resources are not accessed. > > - */ > > - ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID)); > > - return false; > > -#endif > > } > > > > static inline unsigned int espi_intid_to_idx(unsigned int intid) > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > > index e5aca17dcb..e04678f134 100644 > > --- a/xen/arch/arm/vgic.c > > +++ b/xen/arch/arm/vgic.c > > @@ -62,6 +62,13 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, > > return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]; > > } > > > > +static struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) > Constify d, please. > Also, use static inline like the surrounding helpers. Ack. > > > +{ > > + unsigned int idx = espi_intid_to_idx(irq) + d->arch.vgic.nr_spis; > > + > > + return &d->arch.vgic.pending_irqs[idx]; > > +} > > + > > #else > > static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank) > > { > > @@ -78,6 +85,11 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, > > ASSERT_UNREACHABLE(); > > return NULL; > > } > > + > > +static struct pending_irq *espi_to_pending(struct domain *d, unsigned int irq) > > +{ > Add ASSERT_UNREACHABLE() here like for vgic_get_espi_rank(). Ack. > > > + return NULL; > > +} > > #endif > > > > static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, > > @@ -696,8 +708,8 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, > > /* > > * Returns the pointer to the struct pending_irq belonging to the given > > * interrupt. > > - * This can return NULL if called for an LPI which has been unmapped > > - * meanwhile. > > + * This can return NULL for an eSPI when support is disabled, or for an > > + * LPI which has been unmapped meanwhile. > This puts LPI and eSPIs on exactly the same level which is not correct. While > unmapped LPI can happen, eSPI with support disabled must not. Leave the LPI > comment as is and clarify eSPI in one sentence. Ack. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:10:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:10:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429905.1652500 (Exim 4.92) (envelope-from ) id 1x9IzL-0001OV-7X; Wed, 23 Sep 2026 09:10:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429905.1652500; Wed, 23 Sep 2026 09:10:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9IzL-0001Nr-4P; Wed, 23 Sep 2026 09:10:03 +0000 Received: by outflank-mailman (input) for mailman id 1429905; Wed, 23 Sep 2026 09:10:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9IzI-00013k-SU for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:10:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9IzI-001Ugk-9M for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:10:00 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39758-8faa-0a2a0a5109dd-0a2a450ca9c4-34 for ; Wed, 23 Sep 2026 11:10:00 +0200 Received: from [40.107.159.120] (helo=OSPPR02CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39767-f479-0a2a450c0019-286b9f78559a-3 for ; Wed, 23 Sep 2026 11:10:00 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by ZR6PR03MB911552.eurprd03.prod.outlook.com (2603:10a6:910:d0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 09:09:58 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 09:09:58 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bEaQo6vmckxOZdHGwtcifI7WXBp0BJYmI5pRDQSxaigtqRFl6Mim70uNCeeIP16scKBwAM4ysS6X5NG/tVZA4tVdw6WHTKZGszkg77IHsJ7Y0UbXZ+DD7/5inpoqG+5Pg8Jy67F8/Xj0JUDOj0q8oqixVLjYKH8w2vlK2+AlG64VEcT63XwuKqlkOJ/yyB9xhKaetCm/MV2jUnACbYhTMiNbgKeg6xgiawg9wLcZhcLQTgKyUuCc6zEhygc67B5uknEvSESW1M6fdXl/2MOAb3LQcuEASFjzpWtDSX68Wa2sA+JzEMF85vPzHZyq4hm48Rt93ZtcbwRHB+EOtW67nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5hDleXXQ7ZFYiRyz/TOQ5zOKUgB4ljJBW/GGekLzPjk=; b=p9P1b/PXJ4PQ4+3+BLigW6GMuHo5QkM3PgDEGHnHu5itNf54dxtTmwGb0QoXcdCWxyVvOZRTgjvszbwYFCvzXcETrjpDyQKUgGKpp85ypFUVYpbvv587Pb6PIGOiU8orVyPiF+nB6d4QEr7v3XQ5EtZe4QwgIbWNGhXKdtcmBZoZ34OAUxt04n8nXh+MOy+MKzcDEbHbF2R4HuLxwW1hP7WdyjFepRLVZNrcGQCt0H8QppxPfZjpOTGPQ/YxF8kDlzDgFGax6K30dOM7pwv/O4KImEQK1acSrSDXgq/WPjpia0gu4YLrk3V5wTlZG2oR1e/PtCFLsbbEzkTIdLmsLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5hDleXXQ7ZFYiRyz/TOQ5zOKUgB4ljJBW/GGekLzPjk=; b=Ra9mw345dgQLnSuCEMftWskKowr5MvnfJNkWxrk4aPZYu7m4sRRb+qIRodj94mOtZ9H+bG/OzOJmO1spFuhnAWK55TlDQy2VT+5FeS3lHqeY9TiK+k0Ammx4gH46MwQ9dvUIzZObPIokueMw5xHhkGI7KfYfDT2SCJpHFMrnDxUZf21Z1mE2YkX+5FWoB1xZzTkPWvqS6ytO2xeUPQaXqPN0INPyk+6eCxcByXgTH5b/Z5zciBDpE6VR9ejCsXFJWKAKpmWdEJVen0peLQ5939HkqKAUqdwYHuCxOsdPLRJd8pHFAlTWy9IZvNqj+0yC0mQSzTE9X47J4PPUQnCWjQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Wed, 23 Sep 2026 12:09:54 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH v4 3/4] xen/arm: vgic: free eSPIs using the bitmap index Message-ID: Mail-Followup-To: "Orzel, Michal" , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: WA2PEPF000008AF.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::657) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|ZR6PR03MB911552:EE_ X-MS-Office365-Filtering-Correlation-Id: 56b0adca-4748-425c-c331-08df1952708a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|11063799006|10067099003|56012099006|22082099003|18002099003|4143699003; X-Microsoft-Antispam-Message-Info: CqNwlwX5it8USBSm8WDktdr4DcAxaOiT+Gc9eo9yyvdIxc39jq+XQdJW62OuiOWyN8FcScLHTbefD6yMVVLGWFz2S5WTFE70kkRi++RgyH0y9I7hE02h1vMSa1u70Hr1ZiRxcl0yDGbzmsxc07UN0xYVVlVjSnZYviURMm2TF9In5cF6CqjcaMX+VctfSVbb4DUr2jaxlXoSuLT7kTKBiOIgbGob/xuvQhyNvFDfGpYJLzAwqqzJ2VPjBAeIlShTJcwstSki0K1CMcM02RCQP844Pc2yj30mnmmA4ZUVNtX+p1azWk+0nYkwDoILlMIaURJuZNpoPEXE3cAFPQGSIgjKOgULmnsxRtWp19PeZ5ZeE580BCIGPdMJDfzqiSgFTu77yLXqpO9IAVIt5YwBIFvqMGYTUUjLKZYKyxbNhfEx+8kbhtvtR6OWdQHCFmeNMFOTSrxdkgPCAiGYeMHhMO3b2HwJBMCosVTC2fqfBhuUcS5DpSk3LnRy/FiWHPkTTeq+JbwoI5iwJ2C9o6z28d/RgXI26uPmv/KBZKiw2H7okzmvIZO/HiSyh+1uI3hUehV8F9tN1wy0eVhT7A5OZ+Ht74bi5slVItoAPrstAv4UBFMa9vnYRl5picPxKW4BKfLMXu6eiFZ8r+IoJdqmTrKO195RfLhHDWJfICr9A9U= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(11063799006)(10067099003)(56012099006)(22082099003)(18002099003)(4143699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TkNZWEdsTWkwMTZ0ZlIxY0RSUGk4bVoxWmpBYmpaVUlDNURhcTZrNWd1RC9O?= =?utf-8?B?Vlp3R0M1U3NsNTNSYzUxOG1aZlpwZWxieUp2VGdIODhuTnQyL2VJeTRkWkVK?= =?utf-8?B?S1BPa0g3eWZ1YUd4bnZwa0c1OHg0R2VsWDBrd0x6WUdRVVRtN1FoQUdsSG1W?= =?utf-8?B?d1Nhd3JCSStYNDgrYndyNDhnYjNaSXNyOXRVQ0QwT2d6d215THYzd2NHZ3c1?= =?utf-8?B?dlJkTjNvN29EYnRyVDNEYzZ3bXUwMG85V1Y0VDBnMW9kVVdvNDRTamRGNW1G?= =?utf-8?B?RTNSb2xtWkhiN1gxdStqZDVJb1poV3lnR2dTb1crc2xGUzUxS1R0bmJ5SGc2?= =?utf-8?B?RFBFSTJqZHp4YW0zdm9uY0NJQUhWc0IzMGtJVzN2UjFxTFVDSkk4T25sZXZO?= =?utf-8?B?UFoxUi9QOXlMdWdnaHFHeEZiTjNmemhLb25NeitEN3NkZ1I4cTl1ei9tbmlw?= =?utf-8?B?OVFEaHJlNGliRnZSbEwxbHpRVWJnWWNzRitkWlh3TjJLSldRUDFTejZuTmo0?= =?utf-8?B?OWhlY1RaSlRrRWlkMjBkNW9pSG91TS94V1VDOEwxaVJkVTJkNk96Wk5IemRC?= =?utf-8?B?K0JJaDc3S3N5V0VZOHNkL3IrSXZveWs0MjVwbHhMQ0h5dVJTNXdJM2VrSXBY?= =?utf-8?B?cFJ6RVdYMVZialFOQmxMZUtTNzR1QzZoZGtuTFJnbXNIQ3lvTEtTMnZRL0JP?= =?utf-8?B?MnFoUlNqaVZCcitHbytFV2FuRE1BQ3ZUOE5oaEJDTWlUWHJSYVFXSDRtdERy?= =?utf-8?B?OUxhWnJpaURteGF0SVpKbUtXd0psRHhzWEgvQklwZ21oYUY0UFBTRXJmRGEz?= =?utf-8?B?Qk01U3BBVXFqTkdOM2JmT09kQW9vY1JVUEh1UDdKSERUbG9qNnlpUUg0d3JF?= =?utf-8?B?Uk8zTHZBeDRBK1BjWUw3bENSYzVSQXJNdkI2Z2djWHYxM3pKSzhyT3NxYWNQ?= =?utf-8?B?TnN0UVQ5clNsZWdBN1JCVTAzdXNRMXErOTlTSmdLWU55a3MyTG95RHRUOEh3?= =?utf-8?B?QmlQNmYrNFN1Rkp4T2FWNEFtRVo2d3ZUSVI2MG9qYTRNRHRTT09LbWZSbDBk?= =?utf-8?B?a3FtOCtUdjJBQzVhRDhtTHp3dTJiVmxKVEVsVEJQeVZDcFlvWXliVldTOGNt?= =?utf-8?B?QVdMUkJicHhGb2trL215Tk94dUNxb1V2TnAySHloWG9HdERaZGZZTzZHcko2?= =?utf-8?B?bFlrZ2VweHNBT0ZwWVNaZGpUVVl6T2FCelI3OHdETStrU0xISm9xY3VIVWlK?= =?utf-8?B?VVk5UW5SeHl6V2s0dlE1b2Vld0tGN0dqQmtpUDBDRWl2K2RWTEVHalNIUUgw?= =?utf-8?B?K3dmbVVmNnpWWU1NNEhiRS9lb21XUzZTdlFyNE5NanUxRHR6N09ObWZZTmdq?= =?utf-8?B?bnB6YUMrWmhMRHl1S3hEWjZtaVVWYm92T09Da3BCL1ZnN1kvS1pYc055b0h5?= =?utf-8?B?Tmp0ZnhPMDFPakI4VUhiajM5NXRhOUJiSGR0ZFVzanRHVW5udXlmaEdQMGNP?= =?utf-8?B?b0NLVDVDSktVOUR3Q3V4OVY1SGlMUWNVeWNSekN6L2U3QXpXWjJ0UmdZNGpv?= =?utf-8?B?VkpvaHp2Sm01UURCUGw4LzM4Z0QwOE9DaHJ0RTBmaTdPSWgvYWxrY1VGeHZX?= =?utf-8?B?ZGloTkZHajJSZTJ2RWNrUXpUSVBTamwrYXlEN0lVWk9JVDNiUnNLTm9kZ1hs?= =?utf-8?B?TWxlK2hJcUFHUkpNUTl0VnVYcmplUTFJS21zOGVuV1ZXVzNzb21zM2sramlu?= =?utf-8?B?NGZHWDFOWFluaGxwTmZCRERBWW5KWVQ1WWRWQXRKVkJjaTlacUhUSG1qTnRN?= =?utf-8?B?RjdJUWplZWs1Nk9JWVJjRzRURUd0alltZXBBTk5HcGh5NTMvRlZsclRNaTYr?= =?utf-8?B?RXAzLy8zVXQyTFNDeUZieEdidkRGaEpTM3NDbjRPdXhnQU9vVEVQamRhT3lJ?= =?utf-8?B?aDc3eU54b2cvNW54SzczSkhTOGtaVGJFZUViK3g5TFVGZllpOEtFVWUzMncv?= =?utf-8?B?cEQvV09IckRRWHlwMFdSdnJkSldzSUNCeFZ1eG1PU3hwMmlDeHEwVnprOHFZ?= =?utf-8?B?RDQwNmxoWE9xdXRvbTN6ZTNkc2c5eFdzSWdaQ01KR3QyOGt4UjNNUTFwZmow?= =?utf-8?B?dWw5QXBuNlo1Rm1TS0d2c3d1aDJ3Mlo3R2o3VXdFWXBnWXBTdU1TYzFweFU5?= =?utf-8?B?NDBZVFFEY0tNMHVmN25BaS9sdWxhdldjNjNpV1h5RkpONmFsMlpYMUt6MGsr?= =?utf-8?B?MXdJdTl4YjI4T1RlWUpWVjZHQ0I1dHFDVklZaERJTjA4bStQemg3enlkR0Nu?= =?utf-8?B?RitOR1lrdmIwT2JMRnNEQzJ3Q254N21zL3k5cXhKaWNjejE1WVJsQT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56b0adca-4748-425c-c331-08df1952708a X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:09:57.7252 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zUe0RJzUZecLjNS4mEgIBx8cfOIad6SP1G4aRI8Xy0uDwLkZE4YAeYJ/ar0QyOube8h+x0b6pxe0iTZ+5nuedg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR03MB911552 X-purgate-ID: tlsNG-d25034/1790154600-02EDAA5B-E509B05D/0/0 X-purgate-type: clean X-purgate-size: 1352 On Tue, Sep 22, 2026 at 04:21:13PM +0200, Orzel, Michal wrote: > > > On 22-Sep-26 08:39, Mykola Kvach wrote: > > The allocated_irqs bitmap in the existing vGIC implementation stores eSPI > > allocation bits immediately after the regular vIRQ bits. > > vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index, > > but vgic_free_virq() used the raw INTID. > > > > Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit. > > This writes beyond allocated_irqs and leaves the intended eSPI bit set. > > Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind, > > and during vPL011 teardown. > > > > Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving > > and freeing vIRQs. Validate a vIRQ before clearing its allocation bit. > Please also add this validation (just vgic_is_valid_line() guard) to a new VGIC > vgic.c. It's eSPI agnostic and we should keep them in sync if possible. Sure, I can add the validation there as well. Just to clarify, NEW_VGIC currently selects GICV2 and GICV3_ESPI depends on GICV3 && !NEW_VGIC, so the eSPI bitmap issue itself cannot affect the new VGIC. But I agree that the validity check is generic and it makes sense to keep vgic_free_virq() consistent between the two implementations. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:21:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:21:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429924.1652550 (Exim 4.92) (envelope-from ) id 1x9JA1-0003zz-Gq; Wed, 23 Sep 2026 09:21:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429924.1652550; Wed, 23 Sep 2026 09:21:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JA1-0003zs-Dv; Wed, 23 Sep 2026 09:21:05 +0000 Received: by outflank-mailman (input) for mailman id 1429924; Wed, 23 Sep 2026 09:21:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JA0-0003zl-Jc for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:21:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JA0-0017hC-00 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:21:04 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab399f4-bab6-0a2a0a5309dd-0a2a4501daa0-28 for ; Wed, 23 Sep 2026 11:21:03 +0200 Received: from [52.101.57.0] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab399fd-5984-0a2a45010019-346539001def-3 for ; Wed, 23 Sep 2026 11:21:02 +0200 Received: from LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) by BL4PR03MB8106.namprd03.prod.outlook.com (2603:10b6:208:591::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.16; Wed, 23 Sep 2026 09:20:59 +0000 Received: from LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c]) by LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 09:20:59 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fdo2xB9wTRYMrB9qYzO+wrhja9wfijxxRdOXFWHWfUXEUMN/8eQGG3KEDXvZMlc0bmCmKAVWTztHQvlBiIRCp6Bi0XPF97Wt4t1s+Fr6T5RbCgGEGfoTQdYvBP2Pof0T5+MvNn5k21AnDDb/Joc6mrR19/933/GSkNLpZoxDIvfH0ETjcfe9PkWifHImADYcT13zWAL330OxOmDckv7mZqFp8fE+Sw4VYzx6dS39GvIuXPbwSu5BVI94LYr5zSEUzg+OruZZcgWaI66aZ5J6Mcxs8uJIXZYTzV4hd2OoBYVYrTusoGrykg4XHk/ubXwHjgjbYzqdAhWiaudrkxC7wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/G3pWmU7e5VB5nwmAFh2EbKY1eIA5N6iRNC787XIaAE=; b=HYECa/kbt5M39f+XsZzZHx/XFvW5zh3THT0Zfo2Z3jE4u2fN7ZqYMywsfW/5CyxZ/F6Je47ggurBDG+TtnT6oNhx6uxKLt91FMv2GOX9++9n56+Jrxfz7nzbZii4zYwOU+TgxjKFkvDslgHhRddVTVfdj/IXSvzrLkPbaiYrF1uMGCr2JqMwGuD9vgcAZsKMm931ippIKJrQ1mC4NJ0oHSAqXV33yvTC1AvkDjv0J2KQfgXdxK9Xj7eNJqaz6UgAxX0irZprtmiA52pJaBAnvNUXZsW1slXzwiJZhKhL5autegMJl0YaY25eCDnl46+id6OKsRUXrm4rR036pe2JjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/G3pWmU7e5VB5nwmAFh2EbKY1eIA5N6iRNC787XIaAE=; b=Q8p3ARwhE9zDLORpimDlT/N57WBR9HbbEk/8Dig4dryqszjDzfMdisS2Y5nJ3VLI4/qXV87obpy1xsv14Yoo29caNW6bKdNbpROTTR2f7JNiHVr5eIcA8Fq6dAWTLFjyU7iqRbZEJWoOEFWBKu6/3zltUQpeEuyU1osoI6skgQA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, Chunjie Zhu Subject: =?UTF-8?q?=5BPATCH=C2=A0v1=200/5=5D=20x86/nestedsvm=3A=20rework=20nested=20VMRUN/VMEXIT=20handling?= Date: Wed, 23 Sep 2026 17:20:40 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TPYP295CA0010.TWNP295.PROD.OUTLOOK.COM (2603:1096:7d0:9::19) To LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7609:EE_|BL4PR03MB8106:EE_ X-MS-Office365-Filtering-Correlation-Id: a338997c-f1c9-406c-9dd2-08df1953fac6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|56012099006|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: flAFZt1oaA6bZPkui14bAQBnLeTmXEezxY4vPfxHU26YavmMzLKv8yBBJpWC/5zn/fyW8fbsgUt/rWLVnD8iZnlwSEgRCyvJVE072egXvfEO+pRBs3aa1nMKZ5CJLAzuHvlRs8gjTRwmDwLUji7zbcUyPDNO8nsqEXxbHBYBZQzo0aUXSet4oGPnbUqG/AAehjhuTeniYY3TC5k8NgNj1ApjPaNFGn4Tq6bDnDTsJvC0eCi1WQsuDlRZnfKc+JGrhv3MWubU6wRxNkc9iecQ/CMyQZHa0/46Tc0VFMg0FbyCalJfzobcd+39fHi5eWNMBev+XHVYpA5DZjqLcwNAcW/saYXDFWK00rcgm5yOD+TbtBC21C2euqaSU8O6HqRu4y9RIh31ToD0kX0Ooy+hviqr7qlj6gGL+sboEWnscAqYQfxqyiEggACSOpl7UlCxCjLo+ggWiiSNr/r+KL8xKBIhoYjXpz/wVnbl7p/+H3ZU+0y2WtZBepDKvO9kQVzvT7nUKD794fF+yI2ntC1H1fyfAhSEUz0KQmWM97mBQDY3rM6ZRJP/hugQ1VsWkgyV5Gm3PFOBAL64m2mC/3BOPh1cmfe1fQ48NOFFYKJpyamEBitH0bt8toZfmY2z+eBqAg4NKiMTpbL4UayZVv83LtfxADAzjO1EGYIY5+76Roc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7609.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OXFiVnJDRXpLSjEyKzM5SHQ2eFhUQzFmM1hORktnaDZZVmtPejRlNFlXdkZJ?= =?utf-8?B?QjA5YlB1eWZSWjlpMUVHRW1Pd2FWa1IxSDBtYXovS1hmbVpqNUhrcERLaDJK?= =?utf-8?B?MzRpQU9HaUdNMHdWZlRvKzRFV3dURTEzMnJOSmRIYlA5MUlSM0UzeGhPMzBN?= =?utf-8?B?TWpEM01rcy9WQzh6NlNVYU42SWJEc1EzcVlMbWlYMDBtVldpNXRWeTVoOVRl?= =?utf-8?B?MmN5WXd3ejZrZUN2ZjhDWDBEVXRrV3A5dlJ1ZUtLL3AxNm03T1BJd0NOMFNG?= =?utf-8?B?ZE5XUGU3aHN1UzNJaUsvWWVvK0xRNk1DbFkvTG5zSUJSczJDVUJPckN5UEF0?= =?utf-8?B?ejBuVjB5dlk0TG5uODRGai8zZkx5NExhOUF4ZWIxL1M4NXBVQzNCOHE1TnhW?= =?utf-8?B?NlVBTEs5K0k3YnFiRWtaekhYNmZ2emh6TWh2YVpydFpPU2krTE04c1dub1VC?= =?utf-8?B?N0xNTzAyZG1wNlpvc0VHMzJUTHpzdUxRRHZ0U1ozVGN6TDRXR01ndTdORkNH?= =?utf-8?B?Wk9VV1JHZzhXUEE3aExGZUhmd3RFYmdXRFp3V2V1WDE0UXoydU5wcXE3TFdP?= =?utf-8?B?Y3RBa2dEWmVkMGZwODhYaHRhclhZb2Ryd3BXOEVGaUdiNWJFbmpLMEVRSWE1?= =?utf-8?B?d3FaTzFacTdpcjhtNS9vWEZHSEpNRDJ5bTVuSzAxdlYyNlpxV01WQ0RGejZQ?= =?utf-8?B?SHN1cFdOdWJ0YjJtWnlSU0p3N0t0aU5NcHBLRm5Jb2x1cHRPa0RKcGFRSlRv?= =?utf-8?B?Z09rOXd3SHIwZytWbElCNGhyMTNmUkMwRjFTWHFsclZXcGF5aVZLYjN1ZmxF?= =?utf-8?B?S01WVjB2aDJiT0hSNE9GcEluN3FpODRUcU1DK2pwZzhYL3BwYkNpWDdoSnVM?= =?utf-8?B?VTVUNXZ0U05DcG1NS1hZWlFiU1FxUGVpK2FuVXFHU0RpVzFtWkdSQjdjd2gx?= =?utf-8?B?MDlXWUI3YzZmaklWNGhndGhaN0dkUzkyZXZxMGw5d21vS3RabjU3QjQwWTlX?= =?utf-8?B?U3dsWDEvRHphMHdnT3ROd2lOb1RUTjBFTjI5S0JEOHdaeXpyVHVSVnpNdm5E?= =?utf-8?B?WVhjelZwUmZmeDVsMkNudzZxWXZiemNiZnBnMlRIaGVmbmlJcVJ2QTdlUDZa?= =?utf-8?B?N2tZUlBBcWRvV0V2OS9laXBaRWNPL2M3NG9pamJoSkRZSFhESXN1L1o5VkE1?= =?utf-8?B?Nyt2UTViTEl1YXRyS21TWGM2ZVVpdkNrVUdSbEx5TEN1bjNKQ3VWYlhzcDk2?= =?utf-8?B?Vy91ODNXR0hrL29PcjlDdU1vaTRnSUhKWjg1VXlLdEVuOThYT2lpc2g0R0M0?= =?utf-8?B?dEdSeng0TUhKU2JqQ2o2cmMxRCt5ZmVSWS9mS1JIaEVFL2VIY0ZMYmorMHYx?= =?utf-8?B?UWhPMmc0c2xFUHhYV2FOYnI2KzlKR0RUVjRTRlo3eEx1d0xtWUM0VnB2d25o?= =?utf-8?B?WnFZZ3djYlY3dTcxNG1rb21Sd0Z1ZXNWMkFjb1ZqdGtIbjIrUmFROVJSTk9J?= =?utf-8?B?NDNpcmZTUDhoL2wxRTFBTE1NZVNvcXlQeGUrcHdSN0hodmJEVUg2bllKYnEv?= =?utf-8?B?MGF2Ymd2ZXR1Q2VpeHkzYXd0VUY3V3RsZjdMbGdGbFNWSXpGSlJoK05IUlhI?= =?utf-8?B?akxEZGdRbVM0NlNNbzA5TUpjR1RBNUMzbmNTUmluTGo0NDcrSHRuWVBINlJG?= =?utf-8?B?M3pualZUdlJCZGFiYkd1N1BVWDhlMmNPMDRnbVNmUWhHbjNMWUc4YVF5dStO?= =?utf-8?B?MnNTZjNabnE0LzlhZENRb2FqUmYvYTRtYmF5QWlxWFpnOFhRc2tld1RXZHZt?= =?utf-8?B?VHJCcnNxaTUwazB5blN1UFA2b1ZwejZpeDQ0TE5FNm1RZGxoY3dicUxTbDFp?= =?utf-8?B?ckUwRXZUV1p3RGVnNUszRUVwTzlCcjU5QmxpOTdWTjkwQjRnMnM4aStVVGdE?= =?utf-8?B?VU1aS0x5L2o5U2s2TE9DU2Z4RHp5SXB5MkNuc2gxRDZvU0NJa3VvZW9hWGdt?= =?utf-8?B?QlcvN204YUNZYmU0Qkk0REJCVDRkQW8zZzNyRFJ1VkwxWWw0ME9EdXRJd2li?= =?utf-8?B?ek5Ock96RmhiM0Y3cUN4RHI4SnV1L0lBNkpqZ1JsZ0p5clZIakdEQzhmQlor?= =?utf-8?B?VFVDaDdHcnlyaG5aakNmVWNDQkVvdW1zU05QSnE4Mm85NDdxS3ExK29TaWd3?= =?utf-8?B?SFpiWmpLWThQQzNVSEZWT01JQnFKbk42b0k5dmJMS0U5WS9raEtTUlNSOHBh?= =?utf-8?B?SzBmYjFhSlQ0elJmNXd1UVo4b1R5SkpyY05sN1ZGeUk5bUtqNUdYTHVRY2VW?= =?utf-8?B?alNFWG5zUFJhd2N1YkhlSlA3U1paTGdyazRxU1pkUEZSbW1YdEtYdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a338997c-f1c9-406c-9dd2-08df1953fac6 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7609.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:20:59.3019 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: seHHm0nt3Y/Y8kbfT6jK6vGaIhtz51/p7Qf4y0MTVYZBVB0fbfw4rDR2BJpsEkZVTVdMufhaSzvtbhwVM620fQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8106 X-purgate-ID: tlsNG-d62444/1790155262-1E07B757-0141B1E1/0/0 X-purgate-type: clean X-purgate-size: 1666 From: Chunjie Zhu This series simplifies nested SVM execution by removing pending and deferred state from the VMRUN and VMEXIT paths. Nested transitions are handled directly by rearranging the state transfer and control flow. The series also removes obsolete interrupt-window and vCPU-switch handling associated with `nv_vmentry_pending`, while updating the relevant assembly offsets and nested-SVM data structures. Patch 1 rearranges VMRUN handling without pending or deferred flags. Patch 2 removes code related to `nv_vmentry_pending`. Patch 3 rearranges VMEXIT handling without pending or deferred flags. Patch 4 update vmcb fields correctly. Patch 5 fix issues which cause transition failure. Chunjie Zhu (5): x86/nestedsvm: update vmrun without pending or deferred flag x86/nestedsvm: remove nv_vmentry_pending x86/nestedsvm: update vmexit without pending or deferred flag x86/nestedsvm: update vmcb correctly x86/nestedsvm: fix up xen/arch/x86/hvm/svm/entry.S | 48 +++- xen/arch/x86/hvm/svm/intr.c | 22 +- xen/arch/x86/hvm/svm/nestedhvm.h | 6 +- xen/arch/x86/hvm/svm/nestedsvm.c | 337 ++++++++++++----------- xen/arch/x86/hvm/svm/svm.c | 25 +- xen/arch/x86/hvm/svm/vmcb.c | 12 +- xen/arch/x86/hvm/svm/vmcb.h | 6 + xen/arch/x86/include/asm/hvm/svm-types.h | 9 +- xen/arch/x86/include/asm/msr-index.h | 1 + xen/arch/x86/mm/p2m.c | 5 + xen/arch/x86/x86_64/asm-offsets.c | 1 + 11 files changed, 260 insertions(+), 212 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:21:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:21:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429925.1652560 (Exim 4.92) (envelope-from ) id 1x9JAC-0004Fu-Qw; Wed, 23 Sep 2026 09:21:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429925.1652560; Wed, 23 Sep 2026 09:21:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAC-0004Fn-Ms; Wed, 23 Sep 2026 09:21:16 +0000 Received: by outflank-mailman (input) for mailman id 1429925; Wed, 23 Sep 2026 09:21:15 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAB-0004FI-Eo for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:21:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JAA-00CYaM-Rq for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:21:14 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39a02-8faa-0a2a0a5109dd-0a2a4506e7d4-22 for ; Wed, 23 Sep 2026 11:21:14 +0200 Received: from [40.93.195.61] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39a09-195a-0a2a45060019-285dc33dd2fe-3 for ; Wed, 23 Sep 2026 11:21:14 +0200 Received: from LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) by BL4PR03MB8106.namprd03.prod.outlook.com (2603:10b6:208:591::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.16; Wed, 23 Sep 2026 09:21:12 +0000 Received: from LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c]) by LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 09:21:12 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=S39SDGmxQNfwCfkqBzSUJakOgaha7dWJ+R9dFHD+aUJmI0HrMoKtVWs+yYUugIeCPrlZSJBtmIRfttVEhpOl3sFJLkNHBjohuAl3M25kJKhQU128Y08am4BDWcIofHU4XN3vOn96aqDs6QL43iS3PKLprUBs6bDdJ1R0VKbx+j7xd0FTSBq/oJ75zuesLlxWOIvBHDdWUqRXnQ+xt9ynq5ebGWD6J5uqnuxOB79N5uZn71gv3EfpNZZFzpxMXbRnV399YPWty0SA6gqmQKVQAjzy6BivLTbtJk2/vuJ2iOQaierA59W1Duve/SrPaaVeqE730JOj7XTL9gNy6Wn1cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NJv1vhwGLQHHcsMb5ZEwN2EqsKM7E/Z918v8aaivmyo=; b=jCo/KppaYkWkB41GNMMQwWJnNTKiwvT3MCxZY7AGTmlpMY0B7drI2qcDNtDSf1JdB8tz4xHE/Y4eRbA7ePClAzivnQT3qGfIheKi7JsW/YKvZ6xnInbj2nnhEq2wstcaynySxyk4JMcGNWMDto04xqt2idVlN63tWm8lGjZRFoMbmKquuCvthHnY0pi/zRcV1Xya1nSbKaGAmKsq9NCAzwlvYBnlB6tpanaUOOwT2gQQkk9JJ8hARPq+xk82yFUylSxAv8bO2E8lJJGj8FOX4M2RhsazaJbSrTKsfaYOePCZLIrG2lAUYjsGfjo52ukgVvmmMPhkkGjucE4M5wy/Pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NJv1vhwGLQHHcsMb5ZEwN2EqsKM7E/Z918v8aaivmyo=; b=Pr9Y1JZ6B0J1jC9vcPcuYtU0SomyldOqCveqHr/epUK0IJveE9jY8ILmvFPjrf4hxuE7MXCFkoyJXPkntSNXxUMHYYf7BPbKC/ZjO6zd5Z8X687N5Ii0nsrgi+zQHEEjLXdLNr/Gc9U/nJ7AlGeT5/QcLAtWooAq1Kleya8FSgI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, Chunjie Zhu Subject: =?UTF-8?q?=5BPATCH=C2=A0v1=201/5=5D=20x86/nestedsvm=3A=20update=20vmrun=20without=20pending=20or=20deferred=20flag?= Date: Wed, 23 Sep 2026 17:20:41 +0800 Message-Id: <6a89e46dcdeaed7a0cae11356eec54dcb81d8701.1790146987.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: KL1PR02CA0019.apcprd02.prod.outlook.com (2603:1096:820:d::6) To LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7609:EE_|BL4PR03MB8106:EE_ X-MS-Office365-Filtering-Correlation-Id: 124a2cbe-d91c-4672-ebce-08df19540257 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|22082099003|56012099006|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: 9H0jnOuhh3Dd82ucZ5UnfarBVRFOMklt9oE0FHiv4GgIJqZjJlacXuIgJyIFyGaZ2thDJkTIsVhRfO+G6o7zgRFH4M4OBqPK/0BUHhZyjPAz3mec00IuP53i4O91a39rAA4guDSM+G5BVhbbgkqq1wUdaTIdBGKhnLiHVKhlHmFKX/DvtsVJlbr3UgIzhTVR4hjtuDuQXnaJz1WrjRxcy2RSxYeOtw8JcQqTZ5B34u1F7NlV2XVW5vtYHtb+SmmNu2TLaX6TUpkNVbG+0zLLvPKbja4gG/SpNQ9c2aul4jKllIhvHwMC7AsbY4lnKj6HD//GoaT0aiy2C9yja6nzJ2mUinW5CTYJFhhX8aywtSeF5aAh3Jj+0nvgMJykDwjW/xIBp1ZSmwG19yTNTfqE3R5I6KyaGckj0LKOJgGQMJIGpGR7DZp5SJN01gzllIboI6Kj73d46v+TZ6m1TwwuJ9us9Obc0jkLTVJrLBNyK/1ue6hdDuzDiCeRKQyeUrCcVHWREAunNN+vYQ5V/GGxk3T2wLSyvImy2jpW5eKCmiObCOaNFKFKCdAXQGY1+ZgaIVR4pda3E8yT8qnYLbpITbrI3WuQs9YZlmy0rEMxKT19XUR7D82XCvPSgZjAfllb7cizVgWp6ugz6En+sb2o981O5YRfIiumLXEAAQLAyao= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7609.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(22082099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ckNSSElCbWUrWERNNDQ0VXd4ZXFlbmRQcjFjWmk1VFRxWWhyUlRGVkpGUHhE?= =?utf-8?B?TS9lUHBYcXJYZHR1TmRqVmRiYnFiZlp0ai91bThPTjV3Sm05RGJMTkhNMUkr?= =?utf-8?B?ckNPQVhBaXBxNzNsdnhTWEpxY0JucXNnS2pwRkZZanFFVDJMbm90bkR1THNm?= =?utf-8?B?ZE1tY3NzbDN6RGltS3dQWXpQSkNDaUNFOXNQcjBCd1A0V2NXQ3BDR2h1dDVK?= =?utf-8?B?a2htWWxxS29GUStadGZPUUo2U0cwMTFXRkl6ZFRkQ3dYNTBCTGsrMG1FY0px?= =?utf-8?B?Y096dXh3Q25QT2dLZkV4Z3NSbVFIUm94NnVKdzQ3WjJpbTJYZit5M1VZWVdF?= =?utf-8?B?VEIxRWpNejhwMzFXZFZLWWFqcXJ0T0xrdUVYZTZQV3QyVHhFUWxFQjFkbktn?= =?utf-8?B?MHJlc0FwWlFkZm1lVGdKYkxqMWxPUTFZNEExbDhKeVdaZEhqZjdsSzByeC8w?= =?utf-8?B?VlcybVZtdDMvZlBMN2NzZlVLQ2tsRHJGWVVmMHBCQzlhOWFJVkc1amtJdCtn?= =?utf-8?B?M1I0TmJ2NzlJWXA0WDNLOVUxNHlVbDZQZmFIc1o0NjdvdE9GYml1ZTdoK2FF?= =?utf-8?B?MzRoYURQZ3NqTmk5bVdlb05PSXE3NGE2dGVBYmJRYlA2aWViV2tYSGl2SEg3?= =?utf-8?B?akVRZjM2NnhVdEwxenNmVGREUjA0UndNT0JnMElLYTQzcFpwS0NnTFBZR2gr?= =?utf-8?B?Z2oxeEJkeDBuZVVGTCtpWGNLOFVwcVplS3U1RWlkbi81U3lUOXc2a2xqVldX?= =?utf-8?B?Uy83KzJEMkNMckpKOC9OSlRSZU9EQVVwV2FEalVkNHlMbnZucldRZmoxc0pO?= =?utf-8?B?S0dhZVFQaUxiV3VZUHFEdEVDM0UrNHF4OFg1MHByeXVPZlpML1dDK0dnOXhl?= =?utf-8?B?Y2s4UFM1bFFUSnBQeGlpOVFOd2N5anRXdC9ldHJaOVdFdm1rNzJURnpCRkxo?= =?utf-8?B?d1ptR0l2MWZQbkFzVkpxQzd0a2s1UmE2VU9qU0Nob3BXUktNd1ZJZ08xeFhQ?= =?utf-8?B?b1gyREhWTVJGTC9ydFBDSlBBc1huQjM1YjNFOUl3SzlveHRNSVdwd0xjNGRs?= =?utf-8?B?YjRvMG9CRFFuK1B6WFRLRGtROTNBWUJuV1FKYjRoYUZLUUdpcWNQYkpFTlFv?= =?utf-8?B?azRMcEdIN05SVVN1UzZXeVJMSkxFci9tZmpuZHdyd3lUd1lSNVRCRVZvRWt5?= =?utf-8?B?RVg2RjVlVGtyWSsxNk9ZMDluOXhmcTdnK1ZvYWZzdEprSEtiUFhIVTVjaHJW?= =?utf-8?B?QnBSZmlMMnQ0cFVEd05XSVBIUmtnLzdnVnJoNTAwRVE1dFBYczEzTkwyQnI1?= =?utf-8?B?OUNqUGYyZ1lBQ3VTMTkwMU9IcGVEejRaT25vOXNmZzNDRnRjZDZJbFh4ZU1E?= =?utf-8?B?WDk2aTJWZXBZc1pLVGltck1WeGkzN2FUR3Q4dXBVS3VkdG1jV1BVVEVnU21r?= =?utf-8?B?TzhaMXlFbmJ5Z1pJOHFxTXFIKzYxNktGaS9qMkcwU3RWa2E3enI2bnVHVndv?= =?utf-8?B?NTRMYXJmTUExb2o5bzBxZVFqSFNpUzF3T0JXbGNEZGhkNmhtMDFnM0QzMkN0?= =?utf-8?B?cXVoVmxvVjdmckRmWmZVMXhJeisySHg4eDBuRU1BcFRxVVk0d3ZHUVpWZ2tz?= =?utf-8?B?ckpqbUVoNlI4RDBwckxTMEtvVksxWkxpbW5PaDg1eUFmOFF1UGVMMnNEbVVv?= =?utf-8?B?UHp1cXBEeCs3aGQ3SzBDbDJ0ZDJLVlFkdHVFaitXaXFtSjRaMmFlcVlZTlJQ?= =?utf-8?B?OUoyemZZaGtMdVlUNVNZdHpzM0s2aGovNjUrMDg0WCtyckE2bzJncGpuWnpE?= =?utf-8?B?UEtNRS9Kd0hqTEcxWm1oVEhON1pNamdUZ3ZhMElaL25WdXFvV3NZVk9CQXNG?= =?utf-8?B?U2hIRUFnZ21TbHVkK1hQRm1jeXdoUmYzQXpkejNRbXNJZ0NDdnI0dFYwaWZy?= =?utf-8?B?TWtWSis3aytiWWlVWUtBY2h5cVFncmJjNkJwRVc2cmFVZkJUQmlwR2xQemxa?= =?utf-8?B?bWdsK0dBNDUrUmxqVWMrTWVSazRoSnh4eVhjUmFzMWVCZXRYWFdwMGZsZ0Y5?= =?utf-8?B?SmZLUGUyMzJXOEt2V3V5dW44Mm96VUE4K1VtR0VWU3ltZTlZTmNmcHd3VWlj?= =?utf-8?B?aGcrY0xaTWNONUoxamQzY1pXdU1zeFdCR0paVllJRUVpb3ZkditnQkwwbUEr?= =?utf-8?B?KzhabHNuV2l3S05KTkk1Z3p2MkEzZ2djVnc1am8rd1dtTWpXc0NyUnN1UEFZ?= =?utf-8?B?S1pOUzdxMzVJeVowU3ZSZlJ3SmlQbTF5anJFdVJaWDB5NEY3Y09jYW1SYTNw?= =?utf-8?B?UjFWa0lQYzZiaEs2ZGE4akJpcGJwZyswREI1bXdWM01jTlpmaStnUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 124a2cbe-d91c-4672-ebce-08df19540257 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7609.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:21:12.0164 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1uR958YQLkLg7W0wALNkrBhijhcIDRBj5fExlUs8hBtDbhGgb1FmDl++DDkdFELsS/C15bgnLctDb1+MKSf4TA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8106 X-purgate-ID: tlsNG-16d1c6/1790155274-FE67277B-A46F138D/0/0 X-purgate-type: clean X-purgate-size: 6729 From: Chunjie Zhu Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/svm/entry.S | 48 +++++++++++++++++++++++-------- xen/arch/x86/hvm/svm/nestedhvm.h | 1 + xen/arch/x86/hvm/svm/nestedsvm.c | 31 +++++++++++++++++++- xen/arch/x86/hvm/svm/svm.c | 11 +++++-- xen/arch/x86/x86_64/asm-offsets.c | 1 + 5 files changed, 77 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S index d9613a2a8fed..59d865635fd5 100644 --- a/xen/arch/x86/hvm/svm/entry.S +++ b/xen/arch/x86/hvm/svm/entry.S @@ -28,31 +28,51 @@ FUNC(svm_asm_do_resume) GET_CURRENT(bx) .Lsvm_do_resume: call svm_intr_assist - call nsvm_vcpu_switch - ASSERT_NOT_IN_ATOMIC - mov VCPU_processor(%rbx),%eax - lea irq_stat+IRQSTAT_softirq_pending(%rip),%rdx + /* + * The nested p2m repair below may need to take nestedp2m_lock and + * issue synchronous cross-CPU TLB flush IPIs, doing this with + * interrupts disabled can deadlock. + */ xor %ecx,%ecx - shl $IRQSTAT_shift,%eax - cli - cmp %ecx,(%rdx,%rax,1) - jne .Lsvm_process_softirqs - cmp %cl,VCPU_nsvm_hap_enabled(%rbx) UNLIKELY_START(ne, nsvm_hap) + cmpb $0,VCPU_nhvm_guestmode(%rbx) + UNLIKELY_DONE(z, nsvm_hap) + cmpb $0,VCPU_nhvm_stale_np2m(%rbx) + jne .Lsvm_update_nestedp2m cmp %rcx,VCPU_nhvm_p2m(%rbx) sete %al test VCPU_nhvm_guestmode(%rbx),%al UNLIKELY_DONE(z, nsvm_hap) +.Lsvm_update_nestedp2m: /* - * Someone shot down our nested p2m table; go round again - * and nsvm_vcpu_switch() will fix it for us. + * The nested p2m table is stale, fix it here. */ - sti + mov %rbx,%rdi + call nsvm_vcpu_update_nestedp2m jmp .Lsvm_do_resume __UNLIKELY_END(nsvm_hap) + ASSERT_NOT_IN_ATOMIC + + mov VCPU_processor(%rbx),%eax + lea irq_stat+IRQSTAT_softirq_pending(%rip),%rdx + xor %ecx,%ecx + shl $IRQSTAT_shift,%eax + cli + cmp %ecx,(%rdx,%rax,1) + jne .Lsvm_process_softirqs + + cmp %cl,VCPU_nsvm_hap_enabled(%rbx) + je .Lsvm_vmenter + cmpb $0,VCPU_nhvm_guestmode(%rbx) + je .Lsvm_vmenter + cmpb $0,VCPU_nhvm_stale_np2m(%rbx) + jne .Lsvm_retry_nestedp2m + +.Lsvm_vmenter: + call svm_vmenter_helper clgi @@ -148,4 +168,8 @@ __UNLIKELY_END(nsvm_hap) sti call do_softirq jmp .Lsvm_do_resume + +.Lsvm_retry_nestedp2m: + sti + jmp .Lsvm_do_resume END(svm_asm_do_resume) diff --git a/xen/arch/x86/hvm/svm/nestedhvm.h b/xen/arch/x86/hvm/svm/nestedhvm.h index 9bb04a043430..e22ef259c171 100644 --- a/xen/arch/x86/hvm/svm/nestedhvm.h +++ b/xen/arch/x86/hvm/svm/nestedhvm.h @@ -41,6 +41,7 @@ void cf_check nsvm_vcpu_destroy(struct vcpu *v); int cf_check nsvm_vcpu_initialise(struct vcpu *v); int cf_check nsvm_vcpu_reset(struct vcpu *v); int nsvm_vcpu_vmrun(struct vcpu *v, struct cpu_user_regs *regs); +void nsvm_vcpu_update_nestedp2m(struct vcpu *v); int cf_check nsvm_vcpu_vmexit_event(struct vcpu *v, const struct x86_event *event); uint64_t cf_check nsvm_vcpu_hostcr3(struct vcpu *v); diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index a8b15d6eae05..171b32be2416 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -361,6 +361,35 @@ static void nestedsvm_vmcb_set_nestedp2m(struct vcpu *v, n2vmcb->_h_cr3 = pagetable_get_paddr(p2m_get_pagetable(p2m)); } +void nsvm_vcpu_update_nestedp2m(struct vcpu *v) +{ + struct nestedvcpu *nv; + struct nestedsvm *svm; + struct p2m_domain *p2m; + + ASSERT(v != NULL); + + nv = &vcpu_nestedhvm(v); + svm = &vcpu_nestedsvm(v); + + if ( !nestedhvm_paging_mode_hap(v) ) + return; + + p2m = p2m_get_nestedp2m(v); + + /* + * This may happen if we've handled VMEXIT_NPF at the same time as a + * nested flush IPI from another CPU. We've got a different P2M so the + * host CR3 needs updating. + */ + if ( svm->ns_vmcb_hostcr3 != vmcb_get_h_cr3(nv->nv_vvmcx) || + vmcb_get_h_cr3(nv->nv_n2vmcx) != + pagetable_get_paddr(p2m_get_pagetable(p2m)) ) + nestedsvm_vmcb_set_nestedp2m(v, nv->nv_vvmcx, nv->nv_n2vmcx); + + nv->stale_np2m = false; +} + static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); @@ -516,7 +545,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) /* host nested paging + guest nested paging. */ vmcb_set_np(n2vmcb, true); - nestedsvm_vmcb_set_nestedp2m(v, ns_vmcb, n2vmcb); + nsvm_vcpu_update_nestedp2m(v); /* hvm_set_cr3() below sets v->arch.hvm.guest_cr[3] for us. */ rc = hvm_set_cr3(ns_vmcb->_cr3, false, true); diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index e6a0edcf71ab..fc447d24d67e 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2118,6 +2118,8 @@ static void svm_vmexit_do_vmrun(struct cpu_user_regs *regs, struct vcpu *v, uint64_t vmcbaddr) { + int rc; + if ( !nsvm_efer_svm_enabled(v) ) { hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); @@ -2131,8 +2133,13 @@ svm_vmexit_do_vmrun(struct cpu_user_regs *regs, return; } - vcpu_nestedhvm(v).nv_vmentry_pending = 1; - return; + rc = nsvm_vcpu_vmrun(v, regs); + if ( rc ) + { + if ( nestedsvm_vcpu_vmexit(v, regs, VMEXIT_INVALID, 0, 0) == + NESTEDHVM_VMEXIT_FATALERROR ) + domain_crash(v->domain); + } } static struct page_info * diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-offsets.c index baf266ab8013..772d1959e5a5 100644 --- a/xen/arch/x86/x86_64/asm-offsets.c +++ b/xen/arch/x86/x86_64/asm-offsets.c @@ -129,6 +129,7 @@ void __dummy__(void) OFFSET(VCPU_nhvm_guestmode, struct vcpu, arch.hvm.nvcpu.nv_guestmode); OFFSET(VCPU_nhvm_p2m, struct vcpu, arch.hvm.nvcpu.nv_p2m); + OFFSET(VCPU_nhvm_stale_np2m, struct vcpu, arch.hvm.nvcpu.stale_np2m); OFFSET(VCPU_nsvm_hap_enabled, struct vcpu, arch.hvm.nvcpu.u.nsvm.ns_hap_enabled); BLANK(); #endif -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:21:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:21:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429927.1652568 (Exim 4.92) (envelope-from ) id 1x9JAK-0004XM-1B; Wed, 23 Sep 2026 09:21:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429927.1652568; Wed, 23 Sep 2026 09:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAJ-0004XF-Ue; Wed, 23 Sep 2026 09:21:23 +0000 Received: by outflank-mailman (input) for mailman id 1429927; Wed, 23 Sep 2026 09:21:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAI-0004Vv-Aj for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:21:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JAH-001WWY-Nt for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:21:21 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39a06-e002-0a2a0a5209dd-0a2a4501e712-32 for ; Wed, 23 Sep 2026 11:21:21 +0200 Received: from [52.101.57.28] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39a10-5984-0a2a45010019-3465391cae0b-3 for ; Wed, 23 Sep 2026 11:21:21 +0200 Received: from LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) by BL4PR03MB8106.namprd03.prod.outlook.com (2603:10b6:208:591::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.16; Wed, 23 Sep 2026 09:21:19 +0000 Received: from LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c]) by LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 09:21:19 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=y7hxGjT1n4EHplx1pcSXpP8ynOLsMTtTW44XPM1nXzjP+s7UfPguNaG/hTvK63cubGNTLJWziDycReNVna3b8zMpq5Uz7uyweYyh9uOjpr63Qx17dgVVEq+OUGQ8qHk7rwK853kKlCQdaoclYUMf9NqTzemq5qpFi9cWAszWrJB9tz5tM1yFW8hQRW+Gfp0MlCyhBewbu9yI7D/l8zdZHxCUt4IKtZQGQPHSR5wL7n4ltMFnrs9AljCo9HcjsujrsukO5SemicEAd7CZvHW+SeTHovBPDfHc9x3uWEHUFcEV381W1OHGdiBvFcfusfFjhfkAokBh1IR1jTB5cIZWDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GntJNyGKX+o72A97gHkQ6+ZdCb8ar/MTVXAUW4MR3h4=; b=MXvwLgbKAsQEiCq6AyTGQHXkLc9jGjIsi06DD0+yVRBJho37cuGASW0JwJzPnMF2SS5FLfeKrKEDZ3noCbIB+VxjDwr+pi+iuEu1do4Ae9yZmOM5o/zO/dLeT35jOjHGMzwOvTZMqdQfw1Sp1Vurjju89C4Kl69kYRirKdeZKa9dcFiNNE06oWZ+O/VJuKC/z3KZKsIONOm5+T2Bk2EUv6v9E0EwTApji4CLxQ9fCUGDgbJG9C/PJoTAAT8VS43Yd/6M81Drf3UlHJ68ofNMbXbqmG6G5VI774rjlLPam2XQ00t1sfYNFgb0jo+5/CmY/cmuGR/claVYFEvkWsVphA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GntJNyGKX+o72A97gHkQ6+ZdCb8ar/MTVXAUW4MR3h4=; b=lvqGp0Mp0QuLYlkPQwcuvLgDpHosqRmW6yiR6zpqtrfN+pj7wa+vYpmyxbnzlf6EzloXMx0Amikovpdt7qQUm1cBfVYnvZyzajPqqHXWhu0wTF+vwQOpJJMCQgRaCL1G4lQIkbM9VjqcovEESP3zRzd1kbvBacjYqh7gnElKn1M= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, Chunjie Zhu Subject: =?UTF-8?q?=5BPATCH=C2=A0v1=202/5=5D=20x86/nestedsvm=3A=20remove=20nv=5Fvmentry=5Fpending?= Date: Wed, 23 Sep 2026 17:20:42 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: KUZPR04CA0021.apcprd04.prod.outlook.com (2603:1096:d10:25::9) To LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7609:EE_|BL4PR03MB8106:EE_ X-MS-Office365-Filtering-Correlation-Id: 610ea4d2-b8c8-4c63-c623-08df195406a1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|22082099003|56012099006|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: EP9FLdFdg26AJAAxGxhO1iJ7//umdIuL1g73pYOIUk5f56ArOvuhJTHdFZ7PC+XJ8Txclx5Tjfgwnw616zql2WNuAdKBFHblhobnSG6REKW6T68Vb2gPRs8PCtGxx6VJADpxetpuagMi+JvTTyraoF0DT5HfyyhTPv+RXYCuh7uA11U9p/d+hRxsvbYFqucaGWZX+SI3P8GZlmhh5ftogr0S6RN2rHnqo0DMTljB82cgJCoqV1G30F3DVqOT2dqeQmd223IWPtcm/RLMeSkG960TRg3fn+a1m4EyMHPwpe+N5ezvekxiSq1y1wu3JcVqEw/yF0nsxV4CGV11ngMazXRfJYj4LAu0k7oJD/mJ0utHhqV5T47EObdxdHMSoPG+ww7vc+bzB0VzYEMZCcpifdlDvp/461w/bDX+hmdonXyrATNbpwF6/SFeVRtAuGlDmt/FzWepoRdz+AQe/9VrazB+24qImLR1JvHZirl5+wPo7hwtMVPgqCjY3kYRGtQBC6ryvW9O3NmvFwtpKd2mtdAjwpivwtr7w0iiwJE1ODtZYSTvXFmASQDMZotwwDd9f3ByEee7yfGQPbfI5lCZySZEnYNNOB/hsGq1EC3ZPE1RzhSyuEcv0fqBSy9hvlERNzrqxNwytSMREBVEbrZt7/6tjDCGeD9OytHMElYosVg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7609.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(22082099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RVNlUFF4UEQ4U2E1T1dGSDhHT0pRYmxISE02UU1Od1FnYU5Ga0lJY1g0ZGVl?= =?utf-8?B?TUZ0Zk91OHU1alQ1bUpuUURPYUdrTk11MnRTSE8wVGQ2QmpVZVlDaEdZT1Vw?= =?utf-8?B?Mmdzd01VeHBudklNQlZXcldmWUZsN1h1cjU2dldHNTF1endLdnhLTDIxcTBm?= =?utf-8?B?em1Ga3Z3R2QxQ1BLdjFsWHlBanhmc21MVXJZTC9VVFJZWFRiVFZSd05xVEQz?= =?utf-8?B?dXNzMC9ndis0SHMxY2EyYlRma2ViRVNudTJtTWFWRUhXM1N6V3dUdUhXejFP?= =?utf-8?B?L2VNZG1HeFhzVGp0NGJBV0h4U3ZFNkFJblNLYkhqVFRwWDRJTmNYd1duaGo0?= =?utf-8?B?b3NkVlZqUGo0RWc4V3FTTU94RWFVMXQ3eEZXQ1Zod25wdTNrYzNhck85NDM2?= =?utf-8?B?RkpvcUUxbE16L0I3cEVMYzBTcEFlMjZjK2ZMM3lLcnVyQVZUMlNGcU91cVVn?= =?utf-8?B?U21rUVdCNnpYSWZMeEJ4L0JtQ25zeDB6L1puWXgrc1dzS2twVWljREVjbGcy?= =?utf-8?B?NjNJWExWTDF5MXo5dHRZeWhFbWJpc1RSaHRnS1VhR3grTzd4dVlZbm8vYktG?= =?utf-8?B?bWhTSC8zKzVIUFBPU2lyZC9Nb1k2TW1kd2Z5KzRTaExOcGR2eGJsamFiZjRO?= =?utf-8?B?dlU3UHBOU05Ya2YzOFFRSWpDNU43YkZIUHNjTUp4VkJHWE1EbWF0VkVnL29X?= =?utf-8?B?WWFNTUUxc0lFOEVSdHhNNjZEa3V1V3h4L28vQ2Q2eDNjMm1XNE5pMml5VFRM?= =?utf-8?B?WGZSZmYvYlAvU2JhNzlmQzRzbEpoMUVWa0MrT2hLOGVScE5GYVJ0U3FiL1V1?= =?utf-8?B?SFhBZnRScGpGRXBMdDBEK0VIZHl2Z0ZYRGtOZ2JuK3NQOGg5NE1xMTFoWWJ0?= =?utf-8?B?ZDZKakZVcWdrV0o4bHdvTmZGZGlQRUpaY0lGNlNQZWJUaGxyeVRqaG1Mb0Fw?= =?utf-8?B?a2dBbkVMU1p5dTRYQjVKbnRlR21BVllDa2hNNyttblIzQy9hbnoxcWx4Yndz?= =?utf-8?B?cWxLY1RKTi94UURSb204K0FNUEIvMkpXSGo1ZkJVb1hFcEZMTnNmSFcwMXZR?= =?utf-8?B?K0d4VVBBdVdvcmkwOEQ3dFkvblVQSFMvZytYdFAyZ1BSeitlRXF3RGc1Y2l0?= =?utf-8?B?dmlWcDBucFpYWEZMVWlqWnUrM1BKd3hNZGRkTWRYMmhDbjE1T2hxUU52aTY2?= =?utf-8?B?a211TW0raEJzKzZhOWt6OWpDRkVKYWI0U3NLU2ZPTllWdVJUQTl1Um5FZkIx?= =?utf-8?B?YXVINFlvNDZlWnE3eHJqdGpSSlcvdVB5M1VMMHpub01JbmgxVVV0SUVDNW5V?= =?utf-8?B?Z1VBV0ZnK2FMRGhDc3NrcEc0RVZzcE5nWHl6K0ptWDlKZUdFT0JXdmRQUG1X?= =?utf-8?B?aStPQXpKUnc3TVhSRGxCK2M5akx2NzZ3YkZhMlBwOXBvSnBRMWF2VFp4N09Y?= =?utf-8?B?eWZPL09ScGhydlRSZVZqTnBNL3JpQmlFOEx4NU5nZGNWUmwxMlE0d2ZKeDVi?= =?utf-8?B?emdBdTJ4bkVVblpDL3hRcGd4eEpDK3dhM1pBMjBFcVptYklLaythQ01EZWpa?= =?utf-8?B?UW5lRzFZcHlLZzdGS2FwMGtrRVZiRXZSWTl1TVdNeEFZMUpvd0llRWtHaldj?= =?utf-8?B?eVNBZ2JkWWhzY1B3eWlOb1BIbVh2NjMvakdKUWJ1ckpFSzFYVUV3UGpBY2tQ?= =?utf-8?B?bkVjbU5SV0xwL2ZBU09jWFVSOG9mN0JwNVZ5NXJlclZKVXJTajU4Z1RmZjF6?= =?utf-8?B?K01Jc3JWTm9DZ0ZBWVNUL3NLdlBTTUpaSjVkOVY2d1hHckpkb0lxVTZ6dC9I?= =?utf-8?B?SnVmZktaaHdJTmZHbWJkQnF3allkOVduMERwSms0WEx5MFlYU0U1NUFZZzQ1?= =?utf-8?B?b3ZXWXRJa1Vad0craURtMUl0UTNJMUpiVnRDalpvUnM3ZU5rcDZyZ2ZsVGdU?= =?utf-8?B?VUdZUVZpZGlLQi9ZVWlFL2g3aHZiS1ZTNjFpSWIyOWg3ZHdkclhBUmV5L3Zk?= =?utf-8?B?SDliaXhIaGIrTjgwM291WkxlOVk0ZjFsTTk4RldVeGFwbHIyZEtiZCtMOUx5?= =?utf-8?B?UVVYbFYwL0ZEWlorMVI1RnFGbVlqOU42ekVUdmhTRk1DUTlZTWV4bUJnVm05?= =?utf-8?B?TUxtU1NoQU5KQ0hidktQYVpzOEhLMlRsQjlDcWRNZDNJaE5qTEFWRUw3VU1K?= =?utf-8?B?Yjh3N1dHNkZ1SlY5Q01GckF6dFNqbGJtSXV0dW56L1JkTEgvRUZtZXFuRyt4?= =?utf-8?B?cEF1QmZjdjhvNVlsRFV3ZG45RlpCazlGaVMzN3Z0N1E1Z2lmUVd6WENDaURp?= =?utf-8?B?SzVQajQ3Q3lOK2VGZVJNTlI1ODM2N3RLbkNhclBtK1JobmJSMk5uQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 610ea4d2-b8c8-4c63-c623-08df195406a1 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7609.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:21:19.1961 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: yr5d/4M3ntgE6QKDeIlnaW4Y3tav0f2FbTVUWHeCt4qP5VQJ659Cf4KSahcgQN3T91gva/5YAjPJWbKAkkiEjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8106 X-purgate-ID: tlsNG-d62444/1790155281-1EA66757-57A7FBCC/0/0 X-purgate-type: clean X-purgate-size: 2512 From: Chunjie Zhu Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/svm/intr.c | 18 ------------------ xen/arch/x86/hvm/svm/nestedsvm.c | 23 ----------------------- 2 files changed, 41 deletions(-) diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c index 4b0debfa9a2e..7f6cafb6db78 100644 --- a/xen/arch/x86/hvm/svm/intr.c +++ b/xen/arch/x86/hvm/svm/intr.c @@ -77,24 +77,6 @@ static void svm_enable_intr_window(struct vcpu *v, struct hvm_intack intack) ASSERT(intack.source != hvm_intsrc_none); - if ( nestedhvm_enabled(v->domain) ) - { - struct nestedvcpu *nv = &vcpu_nestedhvm(v); - - if ( nv->nv_vmentry_pending ) - { - struct vmcb_struct *gvmcb = nv->nv_vvmcx; - - /* check if l1 guest injects interrupt into l2 guest via vintr. - * return here or l2 guest looses interrupts, otherwise. - */ - ASSERT(gvmcb != NULL); - intr = vmcb_get_vintr(gvmcb); - if ( intr.fields.irq ) - return; - } - } - TRACE(TRC_HVM_INTR_WINDOW, intack.vector, intack.source, vmcb->event_inj.v ? vmcb->event_inj.vector : -1); diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 171b32be2416..edb3f444756d 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1433,31 +1433,8 @@ void asmlinkage nsvm_vcpu_switch(void) vmexit: nestedsvm_vcpu_vmexit(v, regs, svm->ns_vmexit.exitcode); nv->nv_vmexit_pending = 0; - nv->nv_vmentry_pending = 0; return; } - - if ( nv->nv_vmentry_pending ) - { - int ret; - ASSERT(!nv->nv_vmexit_pending); - ret = nsvm_vcpu_vmrun(v, regs); - if ( ret ) - goto vmexit; - - ASSERT(nestedhvm_vcpu_in_guestmode(v)); - nv->nv_vmentry_pending = 0; - } - - if ( nestedhvm_vcpu_in_guestmode(v) && nestedhvm_paging_mode_hap(v) ) - { - /* In case left the l2 guest due to a physical interrupt (e.g. IPI) - * that is not for the l1 guest then we continue running the l2 guest - * but check if the nestedp2m is still valid. - */ - if ( nv->nv_p2m == NULL ) - nestedsvm_vmcb_set_nestedp2m(v, nv->nv_vvmcx, nv->nv_n2vmcx); - } } /* Interrupts, Virtual GIF */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:21:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:21:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429930.1652576 (Exim 4.92) (envelope-from ) id 1x9JAT-0004wN-91; Wed, 23 Sep 2026 09:21:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429930.1652576; Wed, 23 Sep 2026 09:21:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAT-0004wF-66; Wed, 23 Sep 2026 09:21:33 +0000 Received: by outflank-mailman (input) for mailman id 1429930; Wed, 23 Sep 2026 09:21:31 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAR-0004sq-MG for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:21:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JAR-0079J3-36 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:21:31 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39a15-2eae-0a2a0a5409dd-0a2a450c828e-32 for ; Wed, 23 Sep 2026 11:21:31 +0200 Received: from [40.93.195.57] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39a19-f479-0a2a450c0019-285dc3399e16-3 for ; Wed, 23 Sep 2026 11:21:30 +0200 Received: from LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) by BL4PR03MB8106.namprd03.prod.outlook.com (2603:10b6:208:591::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.16; Wed, 23 Sep 2026 09:21:28 +0000 Received: from LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c]) by LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 09:21:28 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Uv/kP8+5dKvRiUe0mtYsU6E5nv3BHkRBS14/SEmSl+O4KN9aR9oJg4moTlDa8SMUSUbTRLsH55u8mHm6gznYnXUhF5+A2+wZLKegFzH2/1BTvr5RQ8pVFERd+3lLV06HltrLBVQVPoSRSL6qndVlQ5ADCSuVXy/X+1zB57L1TDXNqmhjCfSDTiWvMpu53/KPFk1nTXORtFC1L8SeRCwq9So0ISDXMOPhntA95QcIanYWlEugWhIe9NBhaSH1cF3ojswq1Ab4+/9VkBdOsIgRaiUiCqdMZj9kzJQOQhNBeCJA5POfBhKrwScZXZRPMepoTWUNCp42ZXw5l/PeBprpsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8IU4BHlwvEUQATEKce1EuKskCgG/uibOwmDxKxzfdCE=; b=c1VydIVejzKK4rMGX9qxg0YJ5goLqJs5hZwDXwJn6Oo2O/NaOclQDsnSCJdnkeDXvd+2iFsO9zCPmNicLHJblUT0mCs1Z3WjATsskYCgVVXor/+Dnqlou5COJTEMLRMc9VjtTWmpVgJhsFSd03ESP55Ec72wkD7pPGMYT6DNoaAMU8j3bXpJOh7M+Jb3Q4yac2Eq7bMURHxr6LT1meiJhaoL3FUUo+3VqByBeKxwRiC+Y/0sh97uicTs3ClZJh5fPHops8xLvFaKvCnIFGUZO8W1EYPShJ+l+SltcHtVA0qO7zjmewAfg3B7wz1V4TBQht1JHjFlwLCH5Jc29pSndg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8IU4BHlwvEUQATEKce1EuKskCgG/uibOwmDxKxzfdCE=; b=xRsUJZHawXpRYw62TPZWHniM4nf5IVhoR4VU2ZjVHStXSJ6okWUL817mi4miyv3Oz7myQG52w/7oJu/+jXX4ThXFZCAn3XnemB7FCRPQGOcgY48ByPIjyPiV0Nwgwh6x4PaA3pWHidpkv912X9aej3jvkyiw53qTjdNm2WRGzYA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, Chunjie Zhu Subject: =?UTF-8?q?=5BPATCH=C2=A0v1=203/5=5D=20x86/nestedsvm=3A=20update=20vmexit=20without=20pending=20or=20deferred=20flag?= Date: Wed, 23 Sep 2026 17:20:43 +0800 Message-Id: <3fd01cae3399dd425731c0c2f62b5fdb68071e36.1790146987.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: KU0P306CA0027.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:16::7) To LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7609:EE_|BL4PR03MB8106:EE_ X-MS-Office365-Filtering-Correlation-Id: 29dd6e7d-73b1-49e4-2ad0-08df19540bfe X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|22082099003|56012099006|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: GHkDco+qx9cw4b5kl+ueiE/BgAoDI3RfvCkVyrQOmBO4dK9cQ6ASgKZNSdCH6UxN5Ah24z+voBlTprprpu+5riQ8Y9TFsYQBfB+BVAvfXQo5wfIPYAUb2Ly0ZBNWGyVuHsfbeNJ3oYhRVJhqhZ8eGuJQrs+ylJr+bdXeJLsi2GYCF0kQYLtxBQ8Y4nuwo/7M4fPBpRtHCimnohAlTOsNatYlxrZazihC9G338e86OrDKxOSZK+pVXNYmq5obYp04b7Q5NyhERUsGDXSwQqLzNbmbRZS9qKWhhNRLSBHSXUAylYTIB7gEQXzij5BCIj4SnPxC7DmLLJpm0abrHqm9P2SJe8lr9DcBb0mC91/kmLQMAkmHeGwI669oLoSeKIfrWOxCuGF/QdWPLjW/fzwC2m78KlohvuiIds56IudoS9lbIeesGdA5bS6vOlPdwvCe5jo0t66fYmAWBCxowew5NLV7mS4lDnb4iKCwtaqLyqUoChxq8j8KGRcoGWwHrYKE/+qY46mbI4mT5wT0/PHebY/Hye2cjzIYP0palkHJbjpeT8R2q++mVBBnm+99RbnjVC1ZO1qpmaAUtItpx4U/QLr25yuUorUkGHl+2duRNMsYzursb35omr7UPj94SHm+rPNZFLO+Q8ht8kByy3URpps1gIgqMqFnxltrlw4p83s= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7609.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(22082099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cldFUk0vQkEwYUdER0FsYlZSdHhvVE1JbXdScjkwUlQvWDliS0crVHlsVjlr?= =?utf-8?B?QldiT0VyRnQ0RHpkQUxGWW9oemswem9MT2xObGFRZUJsSEIzZzVERGQyZlli?= =?utf-8?B?NlZrYXV2QzVwV0RJQ3NUMWJnd1V0MW10K1NDMmg2SGh6QjFrQXdkSGpZTlNh?= =?utf-8?B?S2dYWi96ODZQTHdJWUJRSEE1YjdEdG9FWmx3emlOb0tjQmRYOHVNQitzc2ky?= =?utf-8?B?ZWpjM05zUDI4K0U1cHdUVHdHS3d4c2x4UVdTYXQvcVVBT05jWFAxdmtGUVNI?= =?utf-8?B?YzJrWDB4b203ZnFRNFdody8rTExONmNvL3MzNDRLaXpYclg5dFhtYzJpRC9H?= =?utf-8?B?WldDZ2hIQ3E3d3lhdFp1cW9SMkVnN1c5RUJIa1c1VktVbDE1QVhwSm8vQU9S?= =?utf-8?B?c1hvdzNucmtmYS82cWdlYTdOd2xNTGZIVmRDNHQ0MTBQYVUyK213SDVteGRZ?= =?utf-8?B?c3VEOTYxdVV1TnFnYk4rWXcvWjdLSzliVzcwZU1oUC82bExVVG03K1ZFNGhI?= =?utf-8?B?TzNvdDRtUldpNTBvS1N1VWZFMy92eHp1RDVFbXorMVgyUUNuK2YzWjZDdy9i?= =?utf-8?B?eWZyTDRWU3JVUldydENQWk1aTkJRVmYrdUNFVkd4Zm1SSHZVZzVPSktyWDJI?= =?utf-8?B?UkI3SFNhQ3duVG81WDhwSWlVUWdYaVpEZ0M4OEQ2eVczb2Vpd3lpMjRPZlNJ?= =?utf-8?B?TVFtUUtUdnlxNSt4cVc3NVBGNXAwd21mZXkrazVMQnVwbk5vSGhvZHZINnpK?= =?utf-8?B?eG1ZREFvVkR0aXN0VWtyc0pHUnJwSXhkSmhZRDBucHV4RmhHWnlKMVZFTk1J?= =?utf-8?B?TTdrazB6Lyt1VmlnMjAybzdPSkpaMnB5VTJzcDU4L095Z00zL3lKWExuNEsy?= =?utf-8?B?R0FENTlDOEhZei9hV2h1TVIxeEZFQTNJenFEZWw4ekUyUzlRSTBVK04zc2xV?= =?utf-8?B?M0NOblNPSmZWVFF0eUhCSG4rbC9CV2FPNDlWV1BPdUEyck9TdDZkUUtvRnJY?= =?utf-8?B?ZVpJYUVneHV3NEN2Z0J4alVYeVptc0NMM3doeHhGL2RkNEtMcGJJTHdZSTBy?= =?utf-8?B?cjFidTdFbjgvR3F5K0xETE1lTjRBSzlhVXdXYWd4VHBia3RKc3pBcVZoQU8w?= =?utf-8?B?ZFluSGM2UE9mVDNHaE5Va3VDSnd6VmRvTHdkY1dodXNpWE9jRDJ2ZjkvYjQr?= =?utf-8?B?M2RNdlJkR0VGLytyek8zVVpvUzRySTV3Qys2S1kvNEpHeGRoVXMyMEh3UTVQ?= =?utf-8?B?WC9mcC8zcy8wUW1Nbmt2NEo0ZWYrVDNPaDZNMy9DR1huSWxVVk95cEhMallt?= =?utf-8?B?UUFzUWFPdlBKK3lrVTZ3Q00rZlM4d1hvZG9NTW15dzhPdTRHRkF3Nk9VTUFz?= =?utf-8?B?TXFwaEIzVjd2N0gwd1cwb1NPNFowT3YzVGM1WkZaa1BDMDhzdkhoeThVTlNo?= =?utf-8?B?b2grQXovdi94NGV3NXRwcEU5NlpzZlVaaFRoU1oyZSsyWUp6bVc2R0dpZ0Vq?= =?utf-8?B?MjdnQ2gyVG1ETmFWKzFyYTlvQnI3V3JiUWQyTkUzcDBRd2VpUGNrUHdkeFRt?= =?utf-8?B?eWtJM1FLUHFUZmRtVmFsWVpXWXJPanR2NzRaTE9YVElLNGJnNlc2WlpIT0w5?= =?utf-8?B?eWsyTmNzWWxBT21SNGl4RjhYczdVZTY2Y0ducC9jOUk1R2lMdmd5T04yNzBH?= =?utf-8?B?TU9qVWUyaTF2MXlIMEZYQ2JQTXhFT3BFWkxnSU9SZXcrVGsvZzhFa3hQV1F1?= =?utf-8?B?N0tGS21IU3VWbVZTeFhjNGtpNjhlQWZSTC80M1djcHE0dVJ6NTl4a3NwZWN1?= =?utf-8?B?bjJYd2svRnIvOUZ2ekhCbitSMTIzRXp1RGQ3cmJ1RVZ1cG9ZeHB4bGRNNFZM?= =?utf-8?B?bjZFY3lLZGdXcGhZaU80ak1DK1FvVEZJWGZ0VFlyV1QyVTFEaFVaWm5QRzV1?= =?utf-8?B?dHVzcjViUTJDcXlpbUtTNzNVTmxVRXRoZ0FTU2tZWXRnQldIUkMzNUxLZDdU?= =?utf-8?B?aWdxMGtpTTFkejc1Si9IYzIrR3ZNdzk4NHNiMzB3a0hnS1hSY1BYQlE4Qi96?= =?utf-8?B?eGJLeWJ4RDB2MzhIVTdzNFhGNEZDZGxsWGpiKzhIb2hBSTRORUNxN1kxMVcw?= =?utf-8?B?eHRydG5memx6ZlhvdG1jUGtWdFoxOWRDSFd2TVcyY2prOVBYMmlXY0lORXhJ?= =?utf-8?B?U1IxLzNvVTRtZ1VKL0xONnJuaXF3VFE4TFQ1VXUxcDdkQVN5VWNZaWY5dGkv?= =?utf-8?B?YnliQS90VVlEcmhrdTRnNk8xSzNuSmNaSlpFT01PekxmRGxRekhtbFNEaFBE?= =?utf-8?B?a0Z5b2JScTIzRk9ueUtwRUh3cUJ2REJFZWdZUU5EYmhDbHNic2g2UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29dd6e7d-73b1-49e4-2ad0-08df19540bfe X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7609.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:21:28.0660 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: IuaFT9smi/msam5Eq3kj+bg540+XlIPPD1THl+sOkvnoFCjRPzEbKPALmUbPzDnxG+eqN0lveabevuBDxOMuBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8106 X-purgate-ID: tlsNG-d25034/1790155291-50D3CA5B-FAA83AA1/0/0 X-purgate-type: clean X-purgate-size: 14296 From: Chunjie Zhu Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/svm/intr.c | 4 +- xen/arch/x86/hvm/svm/nestedhvm.h | 5 +- xen/arch/x86/hvm/svm/nestedsvm.c | 168 ++++++++--------------- xen/arch/x86/hvm/svm/svm.c | 10 +- xen/arch/x86/include/asm/hvm/svm-types.h | 7 - 5 files changed, 72 insertions(+), 122 deletions(-) diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c index 7f6cafb6db78..f9b59a0d6a46 100644 --- a/xen/arch/x86/hvm/svm/intr.c +++ b/xen/arch/x86/hvm/svm/intr.c @@ -55,7 +55,7 @@ static void svm_inject_nmi(struct vcpu *v) vmcb, general1_intercepts | GENERAL1_INTERCEPT_IRET); } -static void svm_inject_intr(struct vcpu *v, int vector) +void svm_inject_intr(struct vcpu *v, int vector) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; intinfo_t event; @@ -69,7 +69,7 @@ static void svm_inject_intr(struct vcpu *v, int vector) vmcb->event_inj = event; } -static void svm_enable_intr_window(struct vcpu *v, struct hvm_intack intack) +void svm_enable_intr_window(struct vcpu *v, struct hvm_intack intack) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; uint32_t general1_intercepts = vmcb_get_general1_intercepts(vmcb); diff --git a/xen/arch/x86/hvm/svm/nestedhvm.h b/xen/arch/x86/hvm/svm/nestedhvm.h index e22ef259c171..5876a948f39a 100644 --- a/xen/arch/x86/hvm/svm/nestedhvm.h +++ b/xen/arch/x86/hvm/svm/nestedhvm.h @@ -27,7 +27,8 @@ (!!((v)->arch.hvm.guest_efer & EFER_SVME)) int nestedsvm_vmcb_map(struct vcpu *v, uint64_t vmcbaddr); -void nestedsvm_vmexit_defer(struct vcpu *v, +enum nestedhvm_vmexits +nestedsvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs, uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2); enum nestedhvm_vmexits nestedsvm_vmexit_n2n1(struct vcpu *v, struct cpu_user_regs *regs); @@ -65,6 +66,8 @@ int cf_check nsvm_hap_walk_L1_p2m( #define NSVM_INTR_MASKED 0 int nestedsvm_vcpu_interrupt(struct vcpu *v, const struct hvm_intack intack); +void svm_enable_intr_window(struct vcpu *v, struct hvm_intack intack); +void svm_inject_intr(struct vcpu *v, int vector); #endif /* __X86_HVM_SVM_NESTEDHVM_PRIV_H__ */ diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index edb3f444756d..9e5e804a5b00 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -152,8 +152,6 @@ int cf_check nsvm_vcpu_reset(struct vcpu *v) svm->ns_vmcb_hostcr3 = 0; svm->ns_asid = 0; svm->ns_hostflags.bytes = 0; - svm->ns_vmexit.exitinfo1 = 0; - svm->ns_vmexit.exitinfo2 = 0; svm->ns_iomap = NULL; @@ -712,14 +710,10 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct cpu_user_regs *regs) int ret; unsigned int inst_len; struct nestedvcpu *nv = &vcpu_nestedhvm(v); - struct nestedsvm *svm = &vcpu_nestedsvm(v); inst_len = svm_get_insn_len(v, INSTR_VMRUN); if ( inst_len == 0 ) - { - svm->ns_vmexit.exitcode = VMEXIT_SHUTDOWN; return -1; - } nv->nv_vmswitch_in_progress = 1; ASSERT(nv->nv_vvmcx != NULL); @@ -738,15 +732,10 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct cpu_user_regs *regs) break; case NSVM_ERROR_VVMCB: gdprintk(XENLOG_ERR, "inject VMEXIT(INVALID)\n"); - svm->ns_vmexit.exitcode = VMEXIT_INVALID; return -1; case NSVM_ERROR_VMENTRY: default: - gdprintk(XENLOG_ERR, - "nsvm_vcpu_vmentry failed, injecting #UD\n"); - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); - /* Must happen after hvm_inject_hw_exception or it doesn't work right. */ - nv->nv_vmswitch_in_progress = 0; + gdprintk(XENLOG_ERR, "nsvm_vcpu_vmentry failed\n"); return 1; } @@ -760,47 +749,55 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct cpu_user_regs *regs) static int nsvm_vcpu_vmexit_inject(struct vcpu *v, struct cpu_user_regs *regs, - uint64_t exitcode) + uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2) { struct nestedvcpu *nv = &vcpu_nestedhvm(v); - struct nestedsvm *svm = &vcpu_nestedsvm(v); struct vmcb_struct *ns_vmcb; struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - if ( vmcb->_vintr.fields.vgif_enable ) + ASSERT(vmcb->_vintr.fields.vgif_enable); vmcb->_vintr.fields.vgif = 0; - else - svm->ns_gif = 0; ns_vmcb = nv->nv_vvmcx; - if ( nv->nv_vmexit_pending ) + switch ( exitcode ) + { + case VMEXIT_INTR: { - switch ( exitcode ) + struct hvm_intack intack = { + .source = exitinfo1, + .vector = exitinfo2 + }; + + /* See the comment in svm_intr_assist() for why this is necessary */ + if ( unlikely(vmcb->event_inj.v) || + hvm_interrupt_blocked(v, intack) ) { - case VMEXIT_INTR: - if ( unlikely(ns_vmcb->event_inj.v) && nv->nv_vmentry_pending && - hvm_event_needs_reinjection(ns_vmcb->event_inj.type, - ns_vmcb->event_inj.vector) ) - ns_vmcb->exit_int_info = ns_vmcb->event_inj; - break; - case VMEXIT_EXCEPTION_PF: - ns_vmcb->_cr2 = ns_vmcb->ei.exc.cr2; - fallthrough; - case VMEXIT_NPF: - ns_vmcb->exitinfo2 = svm->ns_vmexit.exitinfo2; - fallthrough; - case VMEXIT_EXCEPTION_NP: - case VMEXIT_EXCEPTION_SS: - case VMEXIT_EXCEPTION_GP: - case VMEXIT_EXCEPTION_15: - case VMEXIT_EXCEPTION_MF: - case VMEXIT_EXCEPTION_AC: - ns_vmcb->exitinfo1 = svm->ns_vmexit.exitinfo1; - break; - default: + svm_enable_intr_window(v, intack); break; } + + svm_inject_intr(v, intack.vector); + pt_intr_post(v, intack); + break; + } + + case VMEXIT_EXCEPTION_PF: + ns_vmcb->_cr2 = exitinfo2; + fallthrough; + case VMEXIT_NPF: + ns_vmcb->exitinfo2 = exitinfo2; + fallthrough; + case VMEXIT_EXCEPTION_NP: + case VMEXIT_EXCEPTION_SS: + case VMEXIT_EXCEPTION_GP: + case VMEXIT_EXCEPTION_15: + case VMEXIT_EXCEPTION_MF: + case VMEXIT_EXCEPTION_AC: + ns_vmcb->exitinfo1 = exitinfo1; + break; + default: + break; } ns_vmcb->exitcode = exitcode; @@ -811,10 +808,16 @@ nsvm_vcpu_vmexit_inject(struct vcpu *v, struct cpu_user_regs *regs, int cf_check nsvm_vcpu_vmexit_event( struct vcpu *v, const struct x86_event *event) { + enum nestedhvm_vmexits ret; + ASSERT(vcpu_nestedhvm(v).nv_vvmcx != NULL); - nestedsvm_vmexit_defer(v, VMEXIT_EXCEPTION_DE + event->vector, - event->error_code, event->data); + ret = nestedsvm_vcpu_vmexit(v, guest_cpu_user_regs(), + VMEXIT_EXCEPTION_DE + event->vector, + event->error_code, event->data); + if ( ret == NESTEDHVM_VMEXIT_FATALERROR ) + domain_crash(v->domain); + return NESTEDHVM_VMEXIT_DONE; } @@ -1219,7 +1222,7 @@ enum hvm_intblk cf_check nsvm_intr_blocked(struct vcpu *v) if ( v->io.req.state != STATE_IOREQ_NONE ) return hvm_intblk_shadow; - if ( !nv->nv_vmexit_pending && n2vmcb->exit_int_info.v ) + if ( n2vmcb->exit_int_info.v ) { /* Give the l2 guest a chance to finish the delivery of * the last injected interrupt or exception before we @@ -1228,42 +1231,15 @@ enum hvm_intblk cf_check nsvm_intr_blocked(struct vcpu *v) return hvm_intblk_shadow; } } - - if ( nv->nv_vmexit_pending ) - /* hvm_inject_hw_exception() must have run before. - * exceptions have higher priority than interrupts. - */ - return hvm_intblk_rflags_ie; - return hvm_intblk_none; } -/* VMEXIT emulation */ -void -nestedsvm_vmexit_defer(struct vcpu *v, - uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2) -{ - struct nestedsvm *svm = &vcpu_nestedsvm(v); - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - - if ( vmcb->_vintr.fields.vgif_enable ) - vmcb->_vintr.fields.vgif = 0; - else - svm->ns_gif = 0; - - svm->ns_vmexit.exitcode = exitcode; - svm->ns_vmexit.exitinfo1 = exitinfo1; - svm->ns_vmexit.exitinfo2 = exitinfo2; - vcpu_nestedhvm(v).nv_vmexit_pending = 1; -} - enum nestedhvm_vmexits nestedsvm_check_intercepts(struct vcpu *v, struct cpu_user_regs *regs, uint64_t exitcode) { bool is_intercepted; - ASSERT(vcpu_nestedhvm(v).nv_vmexit_pending == 0); is_intercepted = nsvm_vmcb_guest_intercepts_exitcode(v, regs, exitcode); /* @@ -1352,11 +1328,12 @@ nestedsvm_vmexit_n2n1(struct vcpu *v, struct cpu_user_regs *regs) /* The exitcode is in native SVM/VMX format. The forced exitcode * is in generic format. */ -static enum nestedhvm_vmexits +enum nestedhvm_vmexits nestedsvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs, - uint64_t exitcode) + uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2) { int rc; + enum nestedhvm_vmexits ret = NESTEDHVM_VMEXIT_DONE; struct nestedvcpu *nv = &vcpu_nestedhvm(v); nv->nv_vmswitch_in_progress = 1; @@ -1368,14 +1345,12 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs, */ if ( nestedhvm_vcpu_in_guestmode(v) ) { - enum nestedhvm_vmexits ret; - ret = nestedsvm_vmexit_n2n1(v, regs); switch ( ret ) { case NESTEDHVM_VMEXIT_FATALERROR: gdprintk(XENLOG_ERR, "VMEXIT: fatal error\n"); - return ret; + goto out; case NESTEDHVM_VMEXIT_HOST: BUG(); @@ -1395,46 +1370,18 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs, /* Prepare for running the l1 guest. Make the actual * modifications to the virtual VMCB/VMCS. */ - rc = nsvm_vcpu_vmexit_inject(v, regs, exitcode); + rc = nsvm_vcpu_vmexit_inject(v, regs, exitcode, exitinfo1, exitinfo2); /* If l1 guest uses shadow paging, update the paging mode. */ if ( !nestedhvm_paging_mode_hap(v) ) paging_update_paging_modes(v); - nv->nv_vmswitch_in_progress = 0; - if ( rc ) - return NESTEDHVM_VMEXIT_FATALERROR; - - return NESTEDHVM_VMEXIT_DONE; -} - -/* VCPU switch */ -void asmlinkage nsvm_vcpu_switch(void) -{ - struct cpu_user_regs *regs = guest_cpu_user_regs(); - struct vcpu *v = current; - struct nestedvcpu *nv; - struct nestedsvm *svm; - - if ( !nestedhvm_enabled(v->domain) ) - return; - - nv = &vcpu_nestedhvm(v); - svm = &vcpu_nestedsvm(v); - ASSERT(v->arch.hvm.svm.vmcb != NULL); - ASSERT(nv->nv_n1vmcx != NULL); - ASSERT(nv->nv_n2vmcx != NULL); - ASSERT(nv->nv_n1vmcx_pa != INVALID_PADDR); - ASSERT(nv->nv_n2vmcx_pa != INVALID_PADDR); + ret = NESTEDHVM_VMEXIT_FATALERROR; - if ( nv->nv_vmexit_pending ) - { - vmexit: - nestedsvm_vcpu_vmexit(v, regs, svm->ns_vmexit.exitcode); - nv->nv_vmexit_pending = 0; - return; - } +out: + nv->nv_vmswitch_in_progress = 0; + return ret; } /* Interrupts, Virtual GIF */ @@ -1477,7 +1424,10 @@ nestedsvm_vcpu_interrupt(struct vcpu *v, const struct hvm_intack intack) guest_cpu_user_regs(), exitcode); if ( ret ) { - nestedsvm_vmexit_defer(v, exitcode, intack.source, exitinfo2); + ret = nestedsvm_vcpu_vmexit(v, guest_cpu_user_regs(), exitcode, + intack.source, exitinfo2); + if ( ret == NESTEDHVM_VMEXIT_FATALERROR ) + domain_crash(v->domain); return NSVM_INTR_FORCEVMEXIT; } diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index fc447d24d67e..a8d258aa3980 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1619,7 +1619,9 @@ static void svm_do_nested_pgfault(struct vcpu *v, case -1: ASSERT(nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v)); /* inject #VMEXIT(NPF) into guest. */ - nestedsvm_vmexit_defer(v, VMEXIT_NPF, pfec, gpa); + if ( nestedsvm_vcpu_vmexit(v, regs, VMEXIT_NPF, pfec, gpa) == + NESTEDHVM_VMEXIT_FATALERROR ) + domain_crash(v->domain); return; } @@ -2595,8 +2597,10 @@ void asmlinkage svm_vmexit_handler(void) switch ( nsret ) { case NESTEDHVM_VMEXIT_DONE: - /* defer VMEXIT injection */ - nestedsvm_vmexit_defer(v, exit_reason, exitinfo1, exitinfo2); + nsret = nestedsvm_vcpu_vmexit(v, regs, exit_reason, + exitinfo1, exitinfo2); + if ( nsret == NESTEDHVM_VMEXIT_FATALERROR ) + domain_crash(v->domain); goto out; case NESTEDHVM_VMEXIT_FATALERROR: gdprintk(XENLOG_ERR, "unexpected nestedsvm_vmexit() error\n"); diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h index beab9a3af203..256bf5b91402 100644 --- a/xen/arch/x86/include/asm/hvm/svm-types.h +++ b/xen/arch/x86/include/asm/hvm/svm-types.h @@ -69,13 +69,6 @@ struct nestedsvm { bool ns_gif; bool ns_hap_enabled; - /* Only meaningful when vmexit_pending flag is set */ - struct { - uint64_t exitcode; /* native exitcode to inject into l1 guest */ - uint64_t exitinfo1; /* additional information to the exitcode */ - uint64_t exitinfo2; /* additional information to the exitcode */ - } ns_vmexit; - union { uint32_t bytes; struct { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:21:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:21:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429936.1652586 (Exim 4.92) (envelope-from ) id 1x9JAZ-0005NW-Ma; Wed, 23 Sep 2026 09:21:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429936.1652586; Wed, 23 Sep 2026 09:21:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAZ-0005NA-Is; Wed, 23 Sep 2026 09:21:39 +0000 Received: by outflank-mailman (input) for mailman id 1429936; Wed, 23 Sep 2026 09:21:38 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAY-0005IS-Fr for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:21:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JAX-0017u4-SU for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:21:37 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39a1d-bab6-0a2a0a5309dd-0a2a450c829e-12 for ; Wed, 23 Sep 2026 11:21:37 +0200 Received: from [52.101.57.2] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39a20-f479-0a2a450c0019-346539026ed6-3 for ; Wed, 23 Sep 2026 11:21:37 +0200 Received: from LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) by BL4PR03MB8106.namprd03.prod.outlook.com (2603:10b6:208:591::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.16; Wed, 23 Sep 2026 09:21:35 +0000 Received: from LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c]) by LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 09:21:35 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oB8xzTn5m48EtYiUi9N+tYqbbTv8e7uzFakRrSIWtmiLG/K6IoDp7Z31zCGYdYSPN7rnWY7TWSdl1pjngaHyyzuGzvedVa3mgOrjZaDDCgIdnqCNL/iyRbaSh8gNlNZ0e66SRH2gxJyxUuQBLbwqeWcMLncMQsBdZlCr8Czns/FAHhfQpUbxf6H5CreY18aYw9/2rUVoQfUASUkDFuZyjCf7TFnMLCARnYWn3Y27dHy8ZSrXY5IFj2EWQzbKMI9j38bR2wItElJSqjG4tF81NWK9gOYeFL+MPa3Gc5k+49CI/C4P6xEwB7P7boagiPQg3LFLckMCcjOaGmjnVnDh6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c0G5DFHvfT3OxxH3EakjBBKP8uv26iIDoAqt94XNIBo=; b=roy0obYufjH+LX15/CI78RIdU4iOriNQmSe8Cf/lPDUoQO7rXgOizUFojNi1qJunxfuqfTz7VCeuVyuwW3iYVykGNghJAJazXH/X6VklwF7fO3E2wWoPgrCtTAta1eOe7Khqwry0ADvccBXMuxS3Mk6p1yJcQKNOs8lWVIT9E0YrnwzOzWoyayZXYGtohdxR3TCuEEN/X7md+LVQSoX09f2hAjjpBN33ZXRw1hme4mgSoWQV7Pk4953Wpcv6QivzjogufiG003e+CBn7TeXVEWm9l2PEnNFLMfZ5WaBA+am8VLLdi2LF1cAGgWyaPGfyxoNF7MhI5D73+rndmyURmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c0G5DFHvfT3OxxH3EakjBBKP8uv26iIDoAqt94XNIBo=; b=kA79D9UYM8qw+QE55lT6QwT9bRuap7ih9YM7H6nTwxUQo1eFrNJ3ajngMksWgIO4QjQJzx7lv9BMqMfOJnKFI7JFuYb35b+MeyhCAa0WvCtQ6JtPFOZr+VoYJoH/G4Q4k3dgVXe2jKYfVAk5/eeselutcpT1eDqc2dXfpqjmHnM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, Chunjie Zhu Subject: =?UTF-8?q?=5BPATCH=C2=A0v1=204/5=5D=20x86/nestedsvm=3A=20update=20vmcb=20correctly?= Date: Wed, 23 Sep 2026 17:20:44 +0800 Message-Id: <293d4fce5adc8b4a7f8e9e2700ecaee988ac803c.1790146987.git.chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: KL1PR0401CA0034.apcprd04.prod.outlook.com (2603:1096:820:e::21) To LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7609:EE_|BL4PR03MB8106:EE_ X-MS-Office365-Filtering-Correlation-Id: 9be20fbe-389d-40f2-f23f-08df19541065 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|22082099003|56012099006|11063799006|5023799004|10067099003; X-Microsoft-Antispam-Message-Info: 4lOAWRITY+UDSE69gr0ZFuK+spQTbEsoGnUanMt0Qb+qXG/NIFs3ftPr8CXEvKZVVro7notdN2wbQGwo+IR9MHkDkiY6sNRNUaytqMipDaP2dftEx9fDyEz5wylTKXFKRVQVrZwMbzE4NrhR0vGucaxIBRu9yHZGWxcaCTpeFg/fv1oijIu+VTah79BbGpVfaIrVijv86JrR1NV6kiViK9+GLl3ZNtN7ZVe5afIL/8yS6xKk68aqRoJMN3gvyPqRI2llGJiJ0L67Z20R+XsjbXFMDhgryiZUKH3TxKG9KA4zZqBCEWqtoJpisPh1Q8U9mLJam3gLQ2YtVWnc1TEN6faaZ12trJgW87xSvR0gLpLHTPrMGKl0k6MW4fxE7y3tXh8I/kqYYOHXzneTZ3IG8PEAcVBNTH1JJbX1zG1GL8daY60JMPa0jRYFXLtr/tR3ErknUyg/vFmMsL4tT2uRzEplD23Y1UIEy3tLocJeu24zvULv3TufwbUf+eFZGvxhvQFzfIe2pyykxdG7HGg8a8rW85tsNWYoqtwLbKNn++GjWX/40w0RZ8/bMCU3T9cAV8zydzHNcJfbu2jM2bVStSD2obi1kdEIlQr27OEmwpD7za09bxNFLm54EuPxd/8RFhMEw5EaXMBMEyQcuGyttMo32MHl6I7P1pS18JbuAtU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7609.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(22082099003)(56012099006)(11063799006)(5023799004)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aGhUTEFZZk11NVJuZWcyejMrdHQvWklHVXZaRmE4NjQza1BrSUxXaGVNdlVr?= =?utf-8?B?NmRwZkxraFpaWk1JZ0NpclhlbEFjaFYyWnBLVmFTWGhjd2lJdUdJTVBPaDlh?= =?utf-8?B?NlRLcWtrTCtPUkpUVkVhWnNnUjJvcHhWYVZvbkdmQkNodXBKVFdwcHh1azQ3?= =?utf-8?B?djhrNjBnN1dBWHhodGNEdk11Nmowd2dkdnh0UWJQNFBLMkpmOXdydDBBUUJ2?= =?utf-8?B?ZTVJVlVjVUgxOHB0M2h3UnNtVktpcEduNk1tOGNMNzc2TFFqbC9lMlVkQnR5?= =?utf-8?B?NFlHeCtkL1h0VE1XQTd4azExK1l5dEprblg4cEprWGExTzV1Z1A1OTF1UlZ1?= =?utf-8?B?V1JPWmpTczJTajZCQnREcWRKcXVNTlBaa3BYN2dta3UzeHZMQ1lvaWs2Z0ZF?= =?utf-8?B?Nkpydlhla2Z2MkdZbzB2RjdUZWh1S2JFa0QyUC9kaVcySjRWYUxPM1g0VlZl?= =?utf-8?B?VytoZG5pNW16Zm5EQW1kcndQVEU5US9pQkhGaWM0OGN2UHNNL1llMzNxYWZP?= =?utf-8?B?RFpoOWNtSWNETDBXNlQ1Mk5EOGRNbmJHVWptbzAyczFLU2NZZnVRQXRyMnlv?= =?utf-8?B?UVBQZWk0TDVuVHdONzV1V0JCWnc2SExieUQrSTRlTWlLM25iSmtPdDRpMkNH?= =?utf-8?B?QlA5YXBLODhudEN0eHVDRm1yK3Y1a1AxMkFLMFVNVmFBUHJLWjVGSHJZRDQ2?= =?utf-8?B?aUdqMTh3dHVwVlo3aG9ndkFYQmVSbFdwb2Yzbkt4N3VDeDZIUkpjQ2ZtRGJn?= =?utf-8?B?cVpqRUtpVVd1eWwxWFI0dEoweklRTTlVZ3drU2tqTUJrSWFua09tU3NGejA3?= =?utf-8?B?SWxWM0h4VDh6dlBMQlVqTlhNMGlNai9WSnpGWlluSWkwTFc2ZFV4azQ0bUp5?= =?utf-8?B?TlNCWFZlWGVQTzVubVhnMUpkOVE4VXFiNXRrZUVJZi9wSTB5OGxpSXByamtC?= =?utf-8?B?SHY0UFIyeWQxRzI0bERTK1dIaXlhREJSNHF0amlXdldhL2FSWkNxTjhkNFRj?= =?utf-8?B?RTdjcUlleWdqZUhRSHVVVlE0STRiMjdISkFtL251T2k2ZjN0SEhBS3V6YXVr?= =?utf-8?B?NWxFVjVKWU5aT3NCYVh6L1hpNG5STzArTWl1azVNRXZCV3Y5OERweTBjamdJ?= =?utf-8?B?NzZkNUl4TXFKRGlnM2xsMVZtUHl6YkJ2bXJqSVVOU1JsN2cxaDVTUkRCc0ZH?= =?utf-8?B?Ymg3b0tTNDRKdFRqREc3bTNsSjZGRzM5akEwZVF2ZndtT1BINW5mR1J6aFVW?= =?utf-8?B?UGhralZiRGMweUUzS0U1QUl2c1g0blBaU2FIZmdVUEI1R1ZQRXNrR0hORUVm?= =?utf-8?B?WFpUdzI4MWsvTUVQTk50czhpbjVMeFVoUG9ZSUxaSnp1QWVzR3Z3anQyK1V4?= =?utf-8?B?WjRJQ2xIREJWTGVnQ3p2Tlhkb05WK00vUE5ydFFYd0ZsVnRWTGd2NHNvcURD?= =?utf-8?B?aTFKSXJ2Zyt1Vi9QL1N1Y0FINENmQ0c0Y084VU9qRlVESjk5d3F4aDFYZ3E3?= =?utf-8?B?UUxjNjd5OWg0K3hSNUVQUFFVRkw2ajZJSWxLbjN5ZUZGWGNUMUZWWlQxSGs1?= =?utf-8?B?R2pzQ00yL1ZZa0ZSY0Fyd2Q1VldMZER1M1BKQ1VxKy83VUtLelh4YWEyNEpt?= =?utf-8?B?OE5DekkyYnI2cVpQdnpoMmtkbS9YZUZtL2lRczBnYUhUSkpTeGVPQWNuYlZV?= =?utf-8?B?eDZPNWp6ZlFZQm95L3lKcXVjZVhuWmppM053bkJZZkVwaFIwNSt0azgxV1lC?= =?utf-8?B?STNid3liTHFvVXFIZjFBZjJoS3VjL0dPQ1N0QU5rNGEyRENaVUlTZnFDZXpp?= =?utf-8?B?RVVpYmZzTkdvbkVQR2Jpb3NxL3ZPSlpnY25VUTJEMjJ5OEpKRkpVbmJCQTgw?= =?utf-8?B?TDdzQ3JTUUNMRlY2dnhMdCtNYWloWHhJVUszNlF3L09jSFVlNWdiT1JtSEEr?= =?utf-8?B?YWxwcjhNRWtyRWhNVmxEMHF3WS9YMGZNUEJlWk5HWjJxWXRReDMrTHYyN0RV?= =?utf-8?B?cHpmV2c5cm4vVkN1UG9RQmwvZWx2QVdacEtIOEc4MnAySm9CQXBxcVFaRWNS?= =?utf-8?B?WWloZHBEMElZZUtLM3h2TXplb1pUWFpmYXhvbXJqSWVOcG5EOHNuSWhvQkxk?= =?utf-8?B?RjZlMWJncy96S01aZzF4SkY1K3JQc2tFcEZvWFJveDIzRkVBNzFGRFNsd09l?= =?utf-8?B?YS83dHBBbTdKNVduZFZ1Z1dYdnZqTkppZUhlNzFETnhubmg4OWpNWDIvSHdn?= =?utf-8?B?VThEcXByNXZUdjlCT0k0aXh0MXdVcVhPdVpJT2RLcnc5ZXYra3dxbkt1ckpt?= =?utf-8?B?aitZZ1M5NVk5MjFuMUZyWG5GYWduWVZlSEtGcGZ3VmpxeEFZRVRMdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9be20fbe-389d-40f2-f23f-08df19541065 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7609.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:21:35.4537 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: v4r7GZj/MvflqtvuAfnDYplFsLbaXf6DjFZ1yNB0Z+qq1AsjFXKa+nPCUSc7igWfa5jnWbqAixqChq2VadhBKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8106 X-purgate-ID: tlsNG-d25034/1790155297-034D7A5B-861885D8/0/0 X-purgate-type: clean X-purgate-size: 13662 From: Chunjie Zhu Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/svm/nestedsvm.c | 100 ++++++++++++++++------- xen/arch/x86/hvm/svm/svm.c | 4 + xen/arch/x86/hvm/svm/vmcb.c | 3 + xen/arch/x86/hvm/svm/vmcb.h | 6 ++ xen/arch/x86/include/asm/hvm/svm-types.h | 2 +- xen/arch/x86/include/asm/msr-index.h | 1 + 6 files changed, 87 insertions(+), 29 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 9e5e804a5b00..82e01e513e69 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -146,16 +146,15 @@ int cf_check nsvm_vcpu_reset(struct vcpu *v) svm->ns_exception_intercepts = 0; svm->ns_general1_intercepts = 0; svm->ns_general2_intercepts = 0; + svm->ns_general3_intercepts = 0; svm->ns_hap_enabled = 0; svm->ns_vmcb_guestcr3 = 0; svm->ns_vmcb_hostcr3 = 0; svm->ns_asid = 0; svm->ns_hostflags.bytes = 0; - svm->ns_iomap = NULL; - svm->ns_gif = 1; return 0; } @@ -416,6 +415,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) svm->ns_exception_intercepts = ns_vmcb->_exception_intercepts; svm->ns_general1_intercepts = ns_vmcb->_general1_intercepts; svm->ns_general2_intercepts = ns_vmcb->_general2_intercepts; + svm->ns_general3_intercepts = ns_vmcb->_general3_intercepts; } /* We could track the cleanbits of the n1vmcb from @@ -444,6 +444,8 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) n1vmcb->_general1_intercepts | ns_vmcb->_general1_intercepts; n2vmcb->_general2_intercepts = n1vmcb->_general2_intercepts | ns_vmcb->_general2_intercepts; + n2vmcb->_general3_intercepts = + n1vmcb->_general3_intercepts | ns_vmcb->_general3_intercepts; /* Nested Pause Filter */ if ( ns_vmcb->_general1_intercepts & GENERAL1_INTERCEPT_PAUSE ) @@ -472,6 +474,17 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) n2vmcb->_vintr.fields.intr_masking = 1; } + /* + * If L1 granted its L2 vGIF, the copy above already carried the enable + * and the GIF through. Otherwise seed it set, as a VMRUN of a guest + * without vGIF starts with GIF set (APM vol.2 15.5). + */ + if ( !ns_vmcb->_vintr.fields.vgif_enable ) + { + n2vmcb->_vintr.fields.vgif_enable = 1; + n2vmcb->_vintr.fields.vgif = 1; + } + /* Interrupt state */ n2vmcb->int_stat = ns_vmcb->int_stat; @@ -487,7 +500,8 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) n2vmcb->virt_ext.bytes = n1vmcb->virt_ext.bytes | ns_vmcb->virt_ext.bytes; - /* NextRIP - only evaluated on #VMEXIT. */ + /* NextRIP is consumed by VMRUN as the return address for injected soft events. */ + n2vmcb->nextrip = ns_vmcb->nextrip; /* * VMCB Save State Area @@ -652,10 +666,12 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, int ret; struct nestedvcpu *nv = &vcpu_nestedhvm(v); struct nestedsvm *svm = &vcpu_nestedsvm(v); - struct vmcb_struct *ns_vmcb; + struct vmcb_struct *ns_vmcb, *n1vmcb; ns_vmcb = nv->nv_vvmcx; + n1vmcb = nv->nv_n1vmcx; ASSERT(ns_vmcb != NULL); + ASSERT(n1vmcb != NULL); ASSERT(nv->nv_n2vmcx != NULL); ASSERT(nv->nv_n2vmcx_pa != INVALID_PADDR); @@ -700,7 +716,8 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs *regs, return ret; } - svm->ns_gif = 1; + ASSERT(n1vmcb->_vintr.fields.vgif_enable); + n1vmcb->_vintr.fields.vgif = 1; return 0; } @@ -756,7 +773,7 @@ nsvm_vcpu_vmexit_inject(struct vcpu *v, struct cpu_user_regs *regs, struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; ASSERT(vmcb->_vintr.fields.vgif_enable); - vmcb->_vintr.fields.vgif = 0; + vmcb->_vintr.fields.vgif = 0; ns_vmcb = nv->nv_vvmcx; @@ -939,12 +956,18 @@ nsvm_vmcb_guest_intercepts_exitcode(struct vcpu *v, break; return 0; - case VMEXIT_VMRUN ... VMEXIT_XSETBV: + case VMEXIT_VMRUN ... VMEXIT_RDPRU: exit_bits = 1ULL << (exitcode - VMEXIT_VMRUN); if ( svm->ns_general2_intercepts & exit_bits ) break; return 0; + case VMEXIT_INVLPGB ... VMEXIT_IDLE_HLT: + exit_bits = 1ULL << (exitcode - VMEXIT_INVLPGB); + if ( svm->ns_general3_intercepts & exit_bits ) + break; + return 0; + case VMEXIT_NPF: if ( nestedhvm_paging_mode_hap(v) ) break; @@ -1026,10 +1049,15 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) /* TLB control */ ns_vmcb->tlb_control = 0; - /* Virtual Interrupts */ - ns_vmcb->_vintr = n2vmcb->_vintr; - if ( !svm->ns_hostflags.fields.vintrmask ) - ns_vmcb->_vintr.fields.intr_masking = 0; + /* + * Virtual Interrupts. #VMEXIT writes back V_TPR and V_IRQ (APM vol.2 + * 15.6); the remaining fields do not change. Copy vGIF back only if + * enabled in L1. + */ + ns_vmcb->_vintr.fields.tpr = n2vmcb->_vintr.fields.tpr; + ns_vmcb->_vintr.fields.irq = n2vmcb->_vintr.fields.irq; + if ( ns_vmcb->_vintr.fields.vgif_enable ) + ns_vmcb->_vintr.fields.vgif = n2vmcb->_vintr.fields.vgif; /* Interrupt state */ ns_vmcb->int_stat = n2vmcb->int_stat; @@ -1437,19 +1465,30 @@ nestedsvm_vcpu_interrupt(struct vcpu *v, const struct hvm_intack intack) bool nestedsvm_gif_isset(struct vcpu *v) { - struct nestedsvm *svm = &vcpu_nestedsvm(v); - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + struct nestedvcpu *nv = &vcpu_nestedhvm(v); + struct vmcb_struct *n1vmcb = nv->nv_n1vmcx; + struct vmcb_struct *n2vmcb = nv->nv_n2vmcx; + struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; - /* get the vmcb gif value if using vgif */ - if ( vmcb->_vintr.fields.vgif_enable ) - return vmcb->_vintr.fields.vgif; - else - return svm->ns_gif; + /* + * An L2 with no vGIF of its own shares L1's GIF. L0 keeps that shared + * GIF in the L2 shadow, to keep an L2 CLGI off the host's. + */ + if ( nestedhvm_vcpu_in_guestmode(v) && + !ns_vmcb->_vintr.fields.vgif_enable ) + return n2vmcb->_vintr.fields.vgif; + + /* + * The VMCB virtual GIF is authoritative. + */ + return n1vmcb->_vintr.fields.vgif; } void svm_vmexit_do_stgi(struct cpu_user_regs *regs, struct vcpu *v) { + struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; unsigned int inst_len; + vintr_t intr; /* * STGI doesn't require SVME to be set to be used. See AMD APM vol @@ -1464,7 +1503,9 @@ void svm_vmexit_do_stgi(struct cpu_user_regs *regs, struct vcpu *v) if ( (inst_len = svm_get_insn_len(v, INSTR_STGI)) == 0 ) return; - vcpu_nestedsvm(v).ns_gif = 1; + intr = vmcb_get_vintr(vmcb); + intr.fields.vgif = 1; + vmcb_set_vintr(vmcb, intr); __update_guest_eip(regs, inst_len); } @@ -1485,10 +1526,9 @@ void svm_vmexit_do_clgi(struct cpu_user_regs *regs, struct vcpu *v) if ( (inst_len = svm_get_insn_len(v, INSTR_CLGI)) == 0 ) return; - vcpu_nestedsvm(v).ns_gif = 0; - /* After a CLGI no interrupts should come */ intr = vmcb_get_vintr(vmcb); + intr.fields.vgif = 0; intr.fields.irq = 0; general1_intercepts &= ~GENERAL1_INTERCEPT_VINTR; vmcb_set_vintr(vmcb, intr); @@ -1504,10 +1544,17 @@ void svm_vmexit_do_clgi(struct cpu_user_regs *regs, struct vcpu *v) void svm_nested_features_on_efer_update(struct vcpu *v) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - struct nestedsvm *svm = &vcpu_nestedsvm(v); u32 general2_intercepts; vintr_t vintr; + /* + * These accelerate the L1 VMCB. A world switch loads an EFER rather + * than writing one, and an L2 EFER write says nothing about L1; the L2 + * shadow is configured in nsvm_vmcb_prepare4vmrun(). + */ + if ( nestedhvm_vmswitch_in_progress(v) || nestedhvm_vcpu_in_guestmode(v) ) + return; + /* * Need state for transfering the nested gif status so only write on * the hvm_vcpu EFER.SVME changing. @@ -1515,7 +1562,6 @@ void svm_nested_features_on_efer_update(struct vcpu *v) if ( nsvm_efer_svm_enabled(v) ) { if ( !vmcb->virt_ext.fields.vloadsave_enable && - paging_mode_hap(v->domain) && cpu_has_svm_vloadsave ) { vmcb->virt_ext.fields.vloadsave_enable = 1; @@ -1525,11 +1571,9 @@ void svm_nested_features_on_efer_update(struct vcpu *v) vmcb_set_general2_intercepts(vmcb, general2_intercepts); } - if ( !vmcb->_vintr.fields.vgif_enable && - cpu_has_svm_vgif ) + if ( !vmcb->_vintr.fields.vgif_enable ) { vintr = vmcb_get_vintr(vmcb); - vintr.fields.vgif = svm->ns_gif; vintr.fields.vgif_enable = 1; vmcb_set_vintr(vmcb, vintr); general2_intercepts = vmcb_get_general2_intercepts(vmcb); @@ -1552,7 +1596,6 @@ void svm_nested_features_on_efer_update(struct vcpu *v) if ( vmcb->_vintr.fields.vgif_enable ) { vintr = vmcb_get_vintr(vmcb); - svm->ns_gif = vintr.fields.vgif; vintr.fields.vgif_enable = 0; vmcb_set_vintr(vmcb, vintr); general2_intercepts = vmcb_get_general2_intercepts(vmcb); @@ -1574,5 +1617,6 @@ void __init start_nested_svm(struct hvm_function_table *hvm_function_table) cpu_has_svm_lbrv && cpu_has_svm_nrips && cpu_has_svm_flushbyasid && - cpu_has_svm_decode; + cpu_has_svm_decode && + cpu_has_svm_vgif; } diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index a8d258aa3980..074f09a0e0e9 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1660,6 +1660,8 @@ static void svm_dr_access(struct vcpu *v, struct cpu_user_regs *regs) TRACE(TRC_HVM_DR_WRITE); __restore_debug_registers(vmcb, v); + if ( nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v) ) + vmcb_set_dr_intercepts(v->arch.hvm.svm.vmcb, 0); } static int cf_check svm_msr_read_intercept( @@ -1990,6 +1992,8 @@ static int cf_check svm_msr_write_intercept( case MSR_K8_SYSCFG: case MSR_K8_VM_CR: case MSR_AMD64_EX_CFG: + case MSR_K8_HWCR: + case MSR_K8_VM_IGNNE: /* ignore write. handle all bits as read-only. */ break; diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index d069280a4da8..5354c4f1b85f 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -194,6 +194,9 @@ static int construct_vmcb(struct vcpu *v) vmcb->_vintr.fields.vnmi_enable = cpu_has_svm_vnmi; + /* GIF is set out of reset; with vGIF its value lives in the VMCB. */ + vmcb->_vintr.fields.vgif = 1; + return 0; } diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index 3760f71a8625..d098bf1d1355 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -288,7 +288,13 @@ enum VMEXIT_EXITCODE VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */ VMEXIT_XSETBV = 141, /* 0x8d */ VMEXIT_RDPRU = 142, /* 0x8e */ + VMEXIT_INVLPGB = 160, /* 0xa0 */ + VMEXIT_INVLPGB_ILLEGAL = 161, /* 0xa1 */ + VMEXIT_INVPCID = 162, /* 0xa2 */ + VMEXIT_MCOMMIT = 163, /* 0xa3 */ + VMEXIT_TLBSYNC = 164, /* 0xa4 */ VMEXIT_BUS_LOCK = 165, /* 0xa5 */ + VMEXIT_IDLE_HLT = 166, /* 0xa6 */ /* Remember to also update VMEXIT_NPF_PERFC! */ VMEXIT_NPF = 1024, /* 0x400, nested paging fault */ /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */ diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h index 256bf5b91402..24363a58ffcb 100644 --- a/xen/arch/x86/include/asm/hvm/svm-types.h +++ b/xen/arch/x86/include/asm/hvm/svm-types.h @@ -44,6 +44,7 @@ struct nestedsvm { uint32_t ns_exception_intercepts; uint32_t ns_general1_intercepts; uint32_t ns_general2_intercepts; + uint32_t ns_general3_intercepts; /* Cached real MSR permission bitmaps of the l2 guest */ unsigned long *ns_cached_msrpm; @@ -66,7 +67,6 @@ struct nestedsvm { uint64_t ns_vmcb_guestcr3, ns_vmcb_hostcr3; uint32_t ns_asid; - bool ns_gif; bool ns_hap_enabled; union { diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h index ad1c6c97f8f7..beb858bf99bb 100644 --- a/xen/arch/x86/include/asm/msr-index.h +++ b/xen/arch/x86/include/asm/msr-index.h @@ -250,6 +250,7 @@ #define MSR_K8_VM_CR _AC(0xc0010114, U) #define VM_CR_INIT_REDIRECTION (_AC(1, ULL) << 1) #define VM_CR_SVM_DISABLE (_AC(1, ULL) << 4) +#define MSR_K8_VM_IGNNE _AC(0xc0010115, U) #define MSR_VIRT_SPEC_CTRL _AC(0xc001011f, U) /* Layout matches MSR_SPEC_CTRL */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:21:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:21:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429943.1652595 (Exim 4.92) (envelope-from ) id 1x9JAi-0005qB-Sk; Wed, 23 Sep 2026 09:21:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429943.1652595; Wed, 23 Sep 2026 09:21:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAi-0005q4-Pu; Wed, 23 Sep 2026 09:21:48 +0000 Received: by outflank-mailman (input) for mailman id 1429943; Wed, 23 Sep 2026 09:21:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JAh-0005nb-DL for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:21:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JAg-0079P3-QP for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:21:46 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39a28-2eae-0a2a0a5409dd-0a2a450acb6e-10 for ; Wed, 23 Sep 2026 11:21:46 +0200 Received: from [52.101.57.31] (helo=BN8PR05CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39a28-f2d2-0a2a450a0019-3465391fa556-3 for ; Wed, 23 Sep 2026 11:21:45 +0200 Received: from LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) by BL4PR03MB8106.namprd03.prod.outlook.com (2603:10b6:208:591::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.16; Wed, 23 Sep 2026 09:21:43 +0000 Received: from LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c]) by LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 09:21:43 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HI5bySuzJHbhGWoESuQoIz6iLJP9PmdB0Y31zwgAtfInKoOY54Rs3kimHRW1Wb77kWHv4rabJGWZ7ZquhgK42Pnl9ouiJ8s/EqXhIXyyiNLt2zd3tPkpfP9JE1IsGAkdwGkzoKlGv7G+AfnjzTK+qFZymrOxsMUDU+Y0JlRfx/WwXS8UJsdyR0948/DPId0M1OcilS7huIQjmSMQthdRttUtTSWLvqIYx+kdHPswdWcnQlTj3HF8gIE/v/HOTmdhydOs1iBalQcpxmKcJgw23CAdh2sW1xdeEp16aM7rfZBxk/rl5BlEbXbKy57ftQ6MY1WyZevdN+yfG7DgxVFC7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qQtCMr71u/dFmTTBykUGImfeS0Mu9gUyzujoZ62TAUA=; b=G7th76gRGCPrDB8N7wul0NfMb9oB+7EHcZg/hOcqN5dTJ70IF7EG1uNGs4pVmW3aO8QQiET/pWTfeSj3QGYEZhDGJeTYi8JKDd1SqqsYAIJ52a3Q8uVXkRzI4bNXxXnjqtIRJhJI/B/K/w2Az7M8M5JNsaPGeVLdVl9OmAAjwjD1H8neOYL4cqcPMqcSQu+C9zFfgOoFI52RkHnIBK7LiALTKX5DL5VJ/aNQp7vc3ZN0JQ49oFA+8JYMOmCS/LL3g2DxpwEPVsc8IeouHLXNN8o6mjmcSTi7b2x24VQ1A38q3anv/9FhdvFkt97xEaPnQwkwAhO8XCt+/PJPu+s7OA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qQtCMr71u/dFmTTBykUGImfeS0Mu9gUyzujoZ62TAUA=; b=ZGO4lUn7sYe1EGIktAujkPhANWNfkFvfnpcXk7VFL6TX68+yheOJo4QsQ4m/kL4LgXCaXhBxlGHvFGQ6XEyFQAfV3+/ua5CUuR1fvbQaTLLYvEH7vJpKKmrxX2T0VVXPC4wdwI2d68KHXibUHxfL4pKtJ6qZuvJnoSIfEHVHdw8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, Chunjie Zhu Subject: =?UTF-8?q?=5BPATCH=C2=A0v1=205/5=5D=20x86/nestedsvm=3A=20fix=20up?= Date: Wed, 23 Sep 2026 17:20:45 +0800 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: KUZPR01CA0014.apcprd01.prod.exchangelabs.com (2603:1096:d10:34::15) To LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7609:EE_|BL4PR03MB8106:EE_ X-MS-Office365-Filtering-Correlation-Id: 95495295-45ea-47f4-9eab-08df19541548 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|22082099003|56012099006|11063799006|10067099003; X-Microsoft-Antispam-Message-Info: qjkZxIh0Uz7t5kUhHLiDUNqAS8Q5r054YK8KzKEG5rR0RYgj5ZStVjxg/NBEfKZA/6Wx1/4WtZHDRVklkkRpnaccz8Rdg48E13PZOgyQXPsvgFlM9b9RAbQkW5adTOxVpNY/8PdxvvkNNRnyhsD63Vt91tVgSNIqQ46yv8PemQdaJpmlXMpvVrjLHFXm89DqVWhanbfQqFc4xxoUjuZL0C82veRXA7F4LlD3RwHfXkhTGW0/DtQ9dvR7c8Bb65KNp0sQtX/TDfUU20DxaSEsHC8UzNK8nZpDoYF5Kkwy0E5scKCd+cdo7izkcoTjBIGgRWVpxTK0WNErja7Um8uiatNiELnxss7YRUN+ET9rvy+Si6HIccfmOG0WmRqvHcMoAExoxMI/7QEgcStwq7aasWRA8xkwYswTTLdnVV/OmmXmkMiosHRpq0QcqtMMMQ33Wm1iRhMNxhEXiScZ/Y+iC5Xap0NxKq0qw9PGmeQ/7dxwTzTGgOBJ9iIO/FcPa2ur90wJfCRL6HTHOTLMkkROMr4UGUkzf5HcSeYy+ml4K4u10bH8gllnEbVmGkIBbVo9QGLwN8j75VkhwO/Zeb//lcDaTf0jsCBlF/QWVaUKWXIhD6o42Ki00e9caW2smTsdaeP+a/yVA2NfGDG2QAru745RtVI9zQTPUxklKdhH07o= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7609.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(22082099003)(56012099006)(11063799006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VkVxUHBNOURxYjVaUkRwRXFEN0lOcm16cUtJcEpaMDhNT2pYMEtIR1REbXBW?= =?utf-8?B?M0lxZlV5dVQ1eDJQTVROTklpMTRvdS9obWE4ejFEZjBaOTU5dlZ1VElTTS9Z?= =?utf-8?B?cWVqN2c0KzlxSkVqdGp6WUNJdWNPTGFCYjA3L0ZKWXVINjk1Q0RIYmFnOUFw?= =?utf-8?B?SzcySDIrWTVRSjg0TW1Ha1hOQUVibHhXNEozbTEySUNlZzlmZXplQW5rWkVD?= =?utf-8?B?OWp5ZnJmN1FrRThzNTdGaTkyTktxUWtUYkV1QUhpMWpIeEc0TTcvcENWQm1r?= =?utf-8?B?L0RxeEZaMVNXUE0yS1N6QWJhOU9vQzM5eEJoTnZNK2czZjV2WmF2M1BCM3Iy?= =?utf-8?B?MkVOYkhseFM1Z0xWVWNIMkUyQzlBeTRSODF1Z2dVQzVZTDVZVUpxZkE3dWdM?= =?utf-8?B?aVZXYTdhZlJoc09wRE4xWmlNSmpJLzBHUDFEaHNYZW01ZTZIM0NqWXFmdjJx?= =?utf-8?B?RDFMTXJiNU9DRXJWSU5RcEM0S1FLRFNYUFVxbThHVFdiejE1b2ozMDIwbWhH?= =?utf-8?B?aGltcXZFQllGUVA1WlNSL01La2JhNDN6VTF1VkZIbW1zWGR0TU9NY1YwYlFh?= =?utf-8?B?dXlKdzdpa0lsaGJoNmZPYWNtVlpRWCs0cTRNem5nbzVBdWhWZzRkRHhWNW83?= =?utf-8?B?Yk5WaGdDakhOVGJoQzlUTEtPSi92VEg5dkpsNzVJVmw5YVhSVDhPL09xNlM3?= =?utf-8?B?alpmOGtPQ1VReVpEbGlkSEVuelZoZm9ESTk2N1hIVHFLTUszcm83U213V0w5?= =?utf-8?B?ZDA5aHpSUFN2ZThpY1JsZ2FCQk43ZktyVC9tV2xrbkt0MnMwSW5BYlh1MTZj?= =?utf-8?B?cEd2NDdFWUdURHhMMElUZTl6Q1pCam5uMzNaVUw3bllrMTQxQjk1YXJlZDNK?= =?utf-8?B?TlczRG9sZ0R0K1BIRVR3T2RKMDJoMFBlWDhTWjVRN2gyWTV6VjR5Q0ZqNTVR?= =?utf-8?B?cGg4VHQxMWNwMU82WU8vQ3ZnTjlEL3VINzZYYU1lcVFJOXVwNEd6V3lzZWh0?= =?utf-8?B?UFo5ZnltWlIvZERNTEJHM3FTMHI1Zm5QbXhDYTVtKy9TdUtyMHJCQ0hsRjhX?= =?utf-8?B?WVh3UmNnV3R2QkVpZ28vMVNyK1JSbmlOL1dsSkRpNkxkczhDbng0TmZNQWdR?= =?utf-8?B?KzM2bUI3eU4vYTYvdE0wQWs0MUVQYmc1S3REVVFxUHJnMGhmRmhQQUJaZmxJ?= =?utf-8?B?SUhlLzMzT1h4MGhNZ2hmOUdKWWV2SXdvVjRoK0c1VUw5dS9uZWp5emlYQ1gr?= =?utf-8?B?cWd3N21td2RocXVqRmwzQU5pUEZWOWlySjZmQ0lDbmpvS25ZWVRXbElZcWhB?= =?utf-8?B?MzExUXJZK3BCZTgvU29FVnphSTBmMmVLTDNiYW9YYWsxc1ZycGVKekp0bVR1?= =?utf-8?B?ZEhNMVRiamNKQUhtOUZSN3F5Q01ySlB4UStHeWR6aTBvL0ZNZ0s3UDNJMHB6?= =?utf-8?B?cmFOaVBpcmlEUG9JNUI4aUJpRDVuNHdENU9tdmpMbHhXK0RKZDh1cFNWaFRM?= =?utf-8?B?Uko0M0ttUjdCcUtoSVRXR1pWTGFpeEcvWWk0NWxtNlBqUmRHSGU2UjhNTEVZ?= =?utf-8?B?RGFyMW5SWFNrc1ZWbHkvRU1LOHRjMyt0WWZxUC84cUFPK1M3RmlwR1JPMm5B?= =?utf-8?B?TGw0YkxLV1BHZlQrRHdmWVhhRVk5enlMNTJZeFlQdlNQcllna1B4NFIwaERv?= =?utf-8?B?SWFqSEpKQXlyQjN3ZXRCSEhvR0pNS0IwSWpVK0ZMMkNKMzhXSm5LbzBQVXpL?= =?utf-8?B?dXcyRi9jeCs4NVNERHFQVFZyTFh4cTYvcDlVNnBlVEtLRVVHWDF3NEJ2TkxM?= =?utf-8?B?bWhISG9lb3Q2UHlnTTVYSGhmdmRCdlJWQTVIeURpU2ZMcndUN2lKQTc3ckpI?= =?utf-8?B?WmpKVUY5aE1rMVVtb3Jka09JcWdVT0hoQ1hHY1pkVHZjZEozYnp2VDdHREVh?= =?utf-8?B?eFZxYnp4MXo5WWpBZzdOdGtJYTdWT0xuWDcyTjFYRjIrMHBPTElhUVdpOU5M?= =?utf-8?B?YnA2aTMvSE81T2pRQTVzTXpaK3RsRHI0VTM3T01USTlSWjNBM2NtUC83eWox?= =?utf-8?B?ZkJ0NDN3a3h1KzRCOGpXZTg4L1lrb1VIaXRwekQ4MUN5ck9pb29GWkV3MExQ?= =?utf-8?B?eXhhVHJnaG5IU2RrSFpYL2N1SERrRXd3S0h6azhGaUxKWWU0d0dvN004VUp5?= =?utf-8?B?d3lHdlgxTE10dEx1VlVzV3JQalZQcHR3dDRBaDNjRUUxZ2gyLzNKWWdBTFJ6?= =?utf-8?B?MVQxbVh5SG9BTE5adlBaR1BvZHB5U25aUGNaVExFUGowaGpYNjAzUmVvUEUx?= =?utf-8?B?OVdTa3hmTVFhbk1zcXFmWElmck8vRmpodGF1ZXRCMllIMXRHMHlDdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95495295-45ea-47f4-9eab-08df19541548 X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7609.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:21:43.8150 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: k14H2l2yzMa+ibbypHdADQu8RrAMSADTQGfyRhiaTqkEd0w+Ef232JbXxUDpYfRtVCwfIdbXyH0K4fvHnc+vjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8106 X-purgate-ID: tlsNG-4011c0/1790155305-59DDFCFC-5C11B661/0/0 X-purgate-type: clean X-purgate-size: 3673 From: Chunjie Zhu Signed-off-by: Chunjie Zhu --- xen/arch/x86/hvm/svm/nestedsvm.c | 19 ++++++++++++++++--- xen/arch/x86/hvm/svm/vmcb.c | 9 +++++---- xen/arch/x86/mm/p2m.c | 5 +++++ 3 files changed, 26 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 82e01e513e69..91872af8aa7b 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -355,7 +355,7 @@ static void nestedsvm_vmcb_set_nestedp2m(struct vcpu *v, vcpu_nestedsvm(v).ns_vmcb_hostcr3 = vvmcb->_h_cr3; p2m = p2m_get_nestedp2m(v); - n2vmcb->_h_cr3 = pagetable_get_paddr(p2m_get_pagetable(p2m)); + vmcb_set_h_cr3(n2vmcb, pagetable_get_paddr(p2m_get_pagetable(p2m))); } void nsvm_vcpu_update_nestedp2m(struct vcpu *v) @@ -373,6 +373,7 @@ void nsvm_vcpu_update_nestedp2m(struct vcpu *v) return; p2m = p2m_get_nestedp2m(v); + nv->stale_np2m = false; /* * This may happen if we've handled VMEXIT_NPF at the same time as a @@ -383,8 +384,6 @@ void nsvm_vcpu_update_nestedp2m(struct vcpu *v) vmcb_get_h_cr3(nv->nv_n2vmcx) != pagetable_get_paddr(p2m_get_pagetable(p2m)) ) nestedsvm_vmcb_set_nestedp2m(v, nv->nv_vvmcx, nv->nv_n2vmcx); - - nv->stale_np2m = false; } static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) @@ -1024,6 +1023,20 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; struct vmcb_struct *n2vmcb = nv->nv_n2vmcx; + ASSERT(v == current); + + /* + * The physical VMCB fields covered by VMSAVE/VMLOAD may not be in sync + * with v's vmcb if a context switch happened since the last VMLOAD. + * VMSAVE below would otherwise capture stale/foreign register state + * into the L1 shadow VMCB. + */ + if ( v->arch.hvm.svm.vmcb_sync_state == vmcb_needs_vmload ) + { + svm_vmload_pa(v->arch.hvm.svm.vmcb_pa); + v->arch.hvm.svm.vmcb_sync_state = vmcb_in_sync; + } + svm_vmsave_pa(nv->nv_n1vmcx_pa); /* Cache guest physical address of virtual vmcb diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 5354c4f1b85f..2f7053ed7eec 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -357,10 +357,11 @@ bool svm_vmcb_isvalid( PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n", cr0); if ( (cr0 & X86_CR0_PG) && - ((cr3 & 7) || - ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && (cr3 & 0xfe0)) || - ((efer & EFER_LMA) && - (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr))) ) + ((!(cr4 & X86_CR4_PCIDE) && + ((cr3 & 7) || + ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && + (cr3 & 0xfe0)))) || + (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr)) ) PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3); valid = hvm_cr4_guest_valid_bits(v->domain); diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 027b9ae69be3..d1fafc479c78 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1517,7 +1517,12 @@ p2m_get_nestedp2m_locked(struct vcpu *v) np2m_base &= ~(0xfffULL); if ( nv->nv_flushp2m && nv->nv_p2m ) + { + p2m = nv->nv_p2m; + if ( p2m ) + p2m_flush_table(p2m); nv->nv_p2m = NULL; + } nestedp2m_lock(d); p2m = nv->nv_p2m; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:27:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:27:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429971.1652604 (Exim 4.92) (envelope-from ) id 1x9JFz-000734-Iw; Wed, 23 Sep 2026 09:27:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429971.1652604; Wed, 23 Sep 2026 09:27:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JFz-00072w-FM; Wed, 23 Sep 2026 09:27:15 +0000 Received: by outflank-mailman (input) for mailman id 1429971; Wed, 23 Sep 2026 09:27:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JFy-00072p-Au for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:27:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JFx-007AlQ-Nd for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:27:13 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39b5e-8faa-0a2a0a5109dd-0a2a4502d1ba-36 for ; Wed, 23 Sep 2026 11:27:13 +0200 Received: from [52.101.66.125] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39b71-6ca4-0a2a45020019-3465427dbcdd-4 for ; Wed, 23 Sep 2026 11:27:13 +0200 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) by DB9PR03MB7565.eurprd03.prod.outlook.com (2603:10a6:10:2c1::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 09:27:11 +0000 Received: from AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7]) by AS8PR03MB9746.eurprd03.prod.outlook.com ([fe80::cf11:309:1384:58f7%6]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 09:27:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QxFdpci3RoA9C7TP2s4ZZb6CPLB20PSrd9+T+F659rdOJQhe1Aww0Wkikeig9GocVTkfwiARhddv2AU3GABIlLTnO/Vo5bHmWz4tXlCU7m6lUPPaYzKBjEQa4pTnJzcQTKNvheFVs6nBQuCV5rloWllx4Kgka9NR17T6VxPJk5zrDszKhwfugpxcyl2s2011uI4Pomh66C3Hbux2fc4DsWhiWwfZBJczUvOw833gWRJCxC3h3D6odfQgoTRJBxS7qfn9NCs/XvX8+g1zrmtUBsLaMN8XgZMrX3Bga6Y+DOgmCp4ynTmrUkyvqUvoET4Rl4qVcd4uzxzjItjx4wfSpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mzz31HR74OJnBFNuOq07IWwxoGymFus80+Ak97b2Aok=; b=YM/j08g6+e25E7UEwLSdhkVyOD/QvBDmexGLo2HSNqJM0WdqlBFgDDgibDEISpUI8lbkJVPrXEVgrMxF//yNpMH01b7ZPbm5//piGFmtmLyjGirPnWpv1gSCu/K+ixN4C6q8vTapSqxMucolOB8jEKD+j7nUqvFVt/9FQmdJDgr7ThSMp9vujKQAQIKvOcELeUwCxhlgPAsh6rejMGvMZDNvIXhP4exfDod4Zt6wAeFwUiy7v98ALiQ3q2cOXSIwu4MsoMEquxHzvO9OQnuh1kJLbnOFqAjfOFquIS5eHfYmHBi0SS0R2CtP2C0b2OSGvoyQOickR2wC4KFHFdqcnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mzz31HR74OJnBFNuOq07IWwxoGymFus80+Ak97b2Aok=; b=WoUpaRiqrcYuQaTHxxyeODges74Kl2Mm3xdx3lZKO7Gvni0aVODihAAiWP2r26PjkphbNu30P+c55A2OdqKh2iFjjsg8LDQv34+CKii0wCwGALpn74d42D1/aTTOFAKHXfqWXrRw572rrUpDAE7cWrldlg2vkhNajNNZz+q6QbdOxIWAi4I5Q2K31sCMpSSBn8sA7PdGWPMJFYNoDNBXfDFn7/3FzoxXKxEMF1WiTFAhd08Wk5crGkkPAZdw6OS7JtBYLltBt++QIp5k2lvW7SO1PiM+sRZYtuflMjhROuEaF77hHPmOulYgJAobaNGGjO61xfjF5pf1HdpNAaySpA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; Date: Wed, 23 Sep 2026 12:27:06 +0300 From: Mykola Kvach To: "Orzel, Michal" Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Roger Pau =?utf-8?B?TW9ubsOp?= , Jens Wiklander Subject: Re: [PATCH v4 4/4] xen/arm: handle irq_set_type() failures Message-ID: Mail-Followup-To: "Orzel, Michal" , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Roger Pau =?utf-8?B?TW9ubsOp?= , Jens Wiklander References: <85c5f8f04b19eea8d32e875a8b7e94f4ebb88292.1790056623.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: WA2PEPF000008BF.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::699) To AS8PR03MB9746.eurprd03.prod.outlook.com (2603:10a6:20b:61d::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR03MB9746:EE_|DB9PR03MB7565:EE_ X-MS-Office365-Filtering-Correlation-Id: f17589a2-b82c-4433-9aa8-08df1954d84d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024|23010399003|6133799003|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: SoGXoAVEnMKLYZ6oNPlO/1GXQgb06XwOg7oehI8rv1l+QqVToWYu9QhCcQproAuDJq4O8DfRRZc9gvF17fp+Ekv18q48qmWlO6fvQ7TMKiMtGF8etq8gZPOpRbv5CeMuCn/9cHvClRDzq7/D1uNNKzK35YdV6v7CJP+Gw3lAb6AkELpSA4kVq2G8PVdlfthG3vn2A4g7QeDK0CYSz2U0g2L52zqjpKsDuartObQXl8bsf0zytWbaQ0nmWIsDD5rOFj3y9Do/9nzNPLatnXoW5uehcaiy2DAwcUBHxj0Ci0e15MTtPqJhbXry4KuAH5W6dKNCd26u19YeHE0G0AgtRE3zG5AyplpUobCce80K6J0Wc/iwiePU1mH1kNS0t/OP7wLJN3YU+kqqPhvflw+neD8aC2zNPcV/4SufSY7WH4o567ASz/E6NokvvJIHuLuXZ/MkfyvMDAFz5rKcucf0SrvBrewF41e2UKgXPfvz4AhHXVCEozncAcAkxXYKUyBbbbeWMFFTDfgWs3ApSGqWXFCi8Son7w9sEGrvDekurFE7DzFhCP7h4rjv20YRJDoznMy4kJsgrOS1YAaJBC8jcSfbcjfVCGYs5M7YyIvjW0PPEYIKPtZ6KBBgLH2qFrd6bKZOJ3kF1eTMd+fKnShxLL9T/vHbR7GqoRsCl9DI8JI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9746.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(23010399003)(6133799003)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZUcwdlB6ZzlQWm5mRWZmQlJHdnEreFVPNDhiL3lMT2FrQmUzb296aHdHeVA4?= =?utf-8?B?ZWx2M2wwQThCaGluQXdQREhGM2YxSGJINkFJTkxEMWpwNG4rZWN5QWxodHcv?= =?utf-8?B?UDNSbVNJZXZiK1RieDlDU1FaUTF6VUVSMS80U2t6aGpHbDE1QmFTamNWSVdj?= =?utf-8?B?Q0ZSSFk2RUVGb0JBVmRtR1hPbW1lOHJDU01EZWI2enQwV05oZTFIK3B5aE9V?= =?utf-8?B?STVqZWw5Zkw3d3V0cW5wSFNwZmlCZitUUVh4NjdYSTloWkYwZWo2cHNYTms3?= =?utf-8?B?RGZZYkU5ZEFMVDlnWU5DRktTdUhYMURMMXdIdnZ0Q0FQSk0vYm80UmNHZU9Q?= =?utf-8?B?RWhiWUZ3aEZNc2dJV3poaHd4a3JOSVIvRnhnZDNHWDRiNW5ncEliSmFsa205?= =?utf-8?B?S1pyVWFBVDFCeWdxM0ZFR3laL25GcW13bG1kNUZZN1VkZkdlTVB6NFpuSkhU?= =?utf-8?B?MmFPUDM5OTB4RHJKN2NYMVVqUVQ1UWVuT2lncStpeDhZMm5LK3FEblJuYThS?= =?utf-8?B?aXZsSHR4ZFV6aThmbnUyeW40QzRDT2xRVVRrM1J1QWxhV3BTTng5VUZ0UEtp?= =?utf-8?B?UnNuSHFnSUt4ejhsWFU5QSt0YjZjT3ZtZ0VNMEZpaXhlc2FYL1djaFgxREp6?= =?utf-8?B?MlRrVFRiZVZGYThLQnRvVXE1UjJWYWNzakN2WHppVTVuU29yZ2sxbnRKOEFD?= =?utf-8?B?SklkUTFYMEwrSitrTTY4aHpiU1F3ZllxTy93ZWNwMlV1bjdmV0ZXWDB2WkJz?= =?utf-8?B?WUZBK090UXR2c1djRDdEUEhuclBLN2tJY0pUM0p6RjhiUzNVWlQ4MWxTN2tp?= =?utf-8?B?a2VhQnZNbVFnOUJhZzBPbWxSZFFmWFozZFU3TTI0TzBialE1cThkTXo5VEdM?= =?utf-8?B?clZsN1lpbHNDMmI0ci8zWDNPQTFnMURTY0tzT1lPakV1UDR3WitJQ1ZvUHVt?= =?utf-8?B?cDdQODBXR1JMOWhBaGM2MG11L2hMaXAzSmJJQVRwOEZHMHV2Rk1aS2FsUEEr?= =?utf-8?B?bWYzcTBnM3BQc3lkZ3NzL29pb1NBMmNicEFyRUVDTlI0OXNmeklZdjc4dEg0?= =?utf-8?B?dWE0cmdCTlB4NEc2SGlOdGQ1b1RFTlFUaWR0N0lHbkgzbkU3aFVVTGI3TlJv?= =?utf-8?B?YTZTTnd3c2x5T2R6VFBxdlNDQmp6S1ZMVDh1RkxydWVtSHk1ZzhiL2JMWita?= =?utf-8?B?TWp4TGpxTVVpWmFTb0RRMkZuUkk3MGt5RGlFcVpYdDVDYVFRcEJ3LzR1bmNV?= =?utf-8?B?NUxBbzVCeGZPb1ArUFRDUDFaU1Q2UVFYU1pIQ3pQalM1cGdrMGJBcGJkUThM?= =?utf-8?B?SFFzejBtTW4wUUZCMnRTcFh3b05ZNUZJWGVoUkZXemV2MHR4YnZ3eVdzelZX?= =?utf-8?B?VnVvUk1xUTB3cjNKWS9wNU9KaFVOU0FKZVdjSXBBcEhYZDNlVEhaWTdiRndz?= =?utf-8?B?bUhsczNaNmdFV29wRG5DcTFKcytXeGRsbENzNnliVm1najgzYU5nK2t4aGZr?= =?utf-8?B?eUtXQkEra3A3VWlrNVI2WjlpU3dFT25heEJCb1B1R2JhQ3NEWkhqeWh0SWlE?= =?utf-8?B?YU55K1QyRkVpUVQ0OURqODc2c2k3ZElMUjJJOUttRkd0dlk4TkFveFFNcjFm?= =?utf-8?B?bXVmUWZzY2RqcGtDZWxWYUIzdkFSa2RaWFZNNmJLN3lEQUh5NGtKMnhhMkpK?= =?utf-8?B?L0Zlek9HNnlMcjZRRHNydXlycTM3REMzQ1lIQjRHUW43eTY2S2NXR0lVL3JI?= =?utf-8?B?TlllenVta29iTzVGNXZ5ZTdVTVJkL1NSRWFBdjlLdm8rWGh0WHN5UTZyOWh5?= =?utf-8?B?cmhhTXNzSDA0T1JTYU1heGxpRmlrMVpTSXplNUp0dTVDMXpKZUV4cnNLbGpK?= =?utf-8?B?bTFqVjlydjdpYXA1cWVvbnlFVzNzT2tFdVJVa0UyKzk5TzB4MGlHYWM1ZnVR?= =?utf-8?B?cGl4NnMxV0JKRG5HL2RrUVlHM3dJSk1helI0WFV0SE9ROGUvbTZXL0RHK00y?= =?utf-8?B?R0ExWWZsdC9LbUFmaEo4TXhMaUMzd3FsUVZVc3hQWGYvdWVWTWVqSEh2TVNm?= =?utf-8?B?bDNqVFlmbGRWUW5iNFJIVlIyZDEyTTZQV1RpbjA4MlF4ZWIzd3cvTUNINU8r?= =?utf-8?B?SStsdzlyMkUxcGw1SUlRYlFGUThqTjlKRHVpWFdXRktQZjlyckNYQ0Z3MjYr?= =?utf-8?B?UDVDLzI1SzMzMEthU29qWFVka1hOR0lIdXhRdnZxcTNWeHVjcmpwalZlL0Zz?= =?utf-8?B?Y0NPTHMvdmErcklPblQ0RTUyVzFhTHFzdjVLTUowcGY5ejUyUVlVOE5rZWUz?= =?utf-8?B?MGhwZVFiMUV5c1JGckwvemU2ckdyRVEwVVg2M1JoQlVmWUZveG1lUT09?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: f17589a2-b82c-4433-9aa8-08df1954d84d X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9746.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:27:10.8368 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: uujo6hvIDRnveZnjLlTuqAXxniCszfkqyIUOHYpfJGqLAts+lywSqE/D6emLUjfnuIyuEqFft9dGBIcEfEP0aw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7565 X-purgate-ID: tlsNG-720697/1790155633-F2AB52AC-C7D3E3E5/0/0 X-purgate-type: clean X-purgate-size: 1408 On Tue, Sep 22, 2026 at 04:24:59PM +0200, Orzel, Michal wrote: > > > On 22-Sep-26 08:39, Mykola Kvach wrote: > > Several Arm firmware initialization paths discard irq_set_type()'s return > > value, violating MISRA C Rule 17.7. If trigger configuration fails, > > initialization continues with an IRQ that was not configured as requested. > > > > GTDT and MADT retain rejected timer and maintenance INTIDs. > > check_timer_irq_cfg() and release_irq() later perform unconditional > > descriptor lookups on those values. Xen has no backing descriptors for > > INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds > > access. > > > > Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store timer > > INTIDs only after successful trigger configuration, make GTDT parsing > > failure fatal, and stop UART or notification setup when trigger > > configuration fails. > > > > Signed-off-by: Mykola Kvach > > Reviewed-by: Volodymyr Babchuk > > Reviewed-by: Michal Orzel > I asked you on v3 to reorder the patches, so that this one comes first (usually > when sending the series, fixes, improvements should come first so that they can > be immediately taken). Sure, I'll reorder the series in v5 so that this patch comes first. Thanks for the reminder. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:37:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:37:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429980.1652613 (Exim 4.92) (envelope-from ) id 1x9JPM-0000Ru-BU; Wed, 23 Sep 2026 09:36:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429980.1652613; Wed, 23 Sep 2026 09:36:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JPM-0000Rn-8a; Wed, 23 Sep 2026 09:36:56 +0000 Received: by outflank-mailman (input) for mailman id 1429980; Wed, 23 Sep 2026 09:36:54 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JPK-0000Rh-Pw for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:36:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JPJ-008UsM-DU for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:36:53 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39da9-e002-0a2a0a5209dd-0a2a4506cac4-36 for ; Wed, 23 Sep 2026 11:36:53 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39db5-195a-0a2a45060019-4a7de18dd912-3 for ; Wed, 23 Sep 2026 11:36:53 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912d391aso4635865e9.2 for ; Wed, 23 Sep 2026 02:36:53 -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-49fde1e045dsm67733715e9.11.2026.09.23.02.36.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 02:36:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790156213; x=1790761013; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=7ClC/J8zDPk6EbOykFfOvPn+lLyj+URpAEetR1UoEGk=; b=IgcMCycNUeSw1RT7loJhyLopoGtcBb/dZUS2k3EM/TKQ+4MdeuXbDL0QRvjpdA5UWg GBWEN8TpxrrUbNYQrajTfHqtSWFTygZ2bFty5Hs0ghQVKlx33X5+86YiMeGkp7ExIT3M wEv5z+eGTKSzE0D1Wpb5IdDgoIZQLoVvmL7yCZZmifGzbtt37kP4qfv0hCpxUSuEgaJe 7v4/aHPZs19FfoJAPL6yddSLy/Mxnkkh+lCRQneS2BUA+2qTgnDES/PsgtrWOTzMtj2t blMTd3MZB4BWPbxFRELrFeX9/Kjqle3WzYrkZ2aVK+QHoHkJ+GifvYDvyrwMgep/uMgU ErLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790156213; x=1790761013; h=content-transfer-encoding:content-type: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:content-type; bh=7ClC/J8zDPk6EbOykFfOvPn+lLyj+URpAEetR1UoEGk=; b=xf7wfOQVeS5/rK4mOB4He2JljTzr4sdvihnUrdpFQ2DY2i4tUBR/+y4A310kbltttb EwdCQiQfbtGMGALZUDrNd5JHkGWCYAqkNzrSmkbM9VZyNhygonEMlgK/ruDt4j2cYzZP 9SUKAw7EVyDflpH4sIjxsRuyP1WHtC0i12+eyFfp+WTKAd7epznyU3wg7qczS5GzS8fm im05APR/eaCR8OiK1+06LkSlcPl4rFdTIWYHibKT0oDFtRztIq8vZt+tvEHU1YDmkXms XSAxmGhpQuYisjB3PWdXtdZq9QstSfpGVSk/ND8En3wBfQTklhM75/43pI1s/nMTCY3W PWsA== X-Forwarded-Encrypted: i=1; AKwUvBxsGQi25DnpvKdPmxfVjySeJQzS4F0KT0VHfy3m4FAgTuv3TT1J9FHlTWe/+Atmg/wWySG+UOMAsjY=@lists.xenproject.org X-Gm-Message-State: AFuF++mc5oBgVncnHj+mOcx62ELLEmd/aW5YmVB64GJuii67T0eBLoMa aTOgvyFOVpLQMWHYU9iGphlOQ8ykT7Q51SbEo6Hg4PJCNyklge1KBCsHvQ5adK+5qA== X-Gm-Gg: AYBFou1LD8z9z1moRGWy/HmRvAkGFSrrBxW0CalvFm/FOTt+L6X2bgOlh4MTWJzddUi mWYPL5b/ympyoL1bRL0pntCkQ3W7cFSQsZMk0pO6Ut/0JEc3AuIvL5+uhZVDws7f8l2CNz+qqV/ vuuLXtNedIVXkP64hJPhfrc5aoYJT9i4pA40uxBJUY7+fk2Sc84z/F1nQUMMTK0YhE/UHBlcqb8 JGC35vTobtMu1mqA8edevRu2hMnswMvCYA01l36xbd3K5E7gVDumL66vSmpRwUoCXf6oXsnbfu+ 44hwAjslgbwKk5JkJrhm0EZbT9f7MFJU9OyIogMnlaqGIMJbzNKmaNb1E1kmKIUBY48sx1Q5G3z N7P+YGe5N4UF+DFjAjPKu3u0h5bJOlTFb5ivkK6UHUcOHOxkSO+767sPQPNE4sKqCDxRLufXKU0 LtUBUk+VDXX+3oD1Gur5PmdaXDHPdRAafOZakEnRb98AGD3kd0e9Ohm5YNngM46YOybo5rSD5xs iAuX0trxLdh5185tC4X+Ba9jmkS0eqOdJ/XrV4CY2/wwLP9fJyrA0cKTvf3Qkc= X-Received: by 2002:a05:600c:314f:b0:49e:81db:4926 with SMTP id 5b1f17b1804b1-49fdee0a0d0mr25809755e9.5.1790156212674; Wed, 23 Sep 2026 02:36:52 -0700 (PDT) Message-ID: Date: Wed, 23 Sep 2026 11:36:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 0/5] x86/nestedsvm: rework nested VMRUN/VMEXIT handling To: chunjie.zhu@citrix.com Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-16d1c6/1790156213-F76C877B-EB49604B/0/0 X-purgate-type: clean X-purgate-size: 1236 On 23.09.2026 11:20, chunjie.zhu@citrix.com wrote: > From: Chunjie Zhu > > This series simplifies nested SVM execution by removing pending and > deferred state from the VMRUN and VMEXIT paths. Nested transitions are > handled directly by rearranging the state transfer and control flow. > > The series also removes obsolete interrupt-window and vCPU-switch handling > associated with `nv_vmentry_pending`, while updating the relevant assembly > offsets and nested-SVM data structures. > > Patch 1 rearranges VMRUN handling without pending or deferred flags. > Patch 2 removes code related to `nv_vmentry_pending`. > Patch 3 rearranges VMEXIT handling without pending or deferred flags. > Patch 4 update vmcb fields correctly. > Patch 5 fix issues which cause transition failure. > > Chunjie Zhu (5): > x86/nestedsvm: update vmrun without pending or deferred flag > x86/nestedsvm: remove nv_vmentry_pending > x86/nestedsvm: update vmexit without pending or deferred flag > x86/nestedsvm: update vmcb correctly > x86/nestedsvm: fix up This last patch, unless it was meant as an RFC without being marked so, surely wants a better title and a non-empty description. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:42:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:42:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429995.1652623 (Exim 4.92) (envelope-from ) id 1x9JV4-0002Ma-V8; Wed, 23 Sep 2026 09:42:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429995.1652623; Wed, 23 Sep 2026 09:42:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JV4-0002MT-Rk; Wed, 23 Sep 2026 09:42:50 +0000 Received: by outflank-mailman (input) for mailman id 1429995; Wed, 23 Sep 2026 09:42:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JV2-0002MN-Ld for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:42:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JV1-001bLn-U0 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:42:47 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab39f0d-2eae-0a2a0a5409dd-0a2a4501b722-10 for ; Wed, 23 Sep 2026 11:42:47 +0200 Received: from [52.101.53.42] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab39f15-5984-0a2a45010019-3465352a10e6-4 for ; Wed, 23 Sep 2026 11:42:46 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SJ0PR03MB6927.namprd03.prod.outlook.com (2603:10b6:a03:43d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 09:42:42 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 09:42:42 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kNF9K4mfQkj9VY7IINHw7ErCkPI5yf6Rt879yaXBnOmwk9om7XXBbIKh18mx4iMoe6dzINC7JyxpOcvI7QfKyE7zHrlt0+zo4tjsu0PZVuzNI3lmTZRwvxLW7qYUuS2i+Gq2AefIQT3X33Wo06gDWoxdcGz+M8GoMxUHZNk1k4JJ5tyW87r/6cHYPw9enKaxz3xKOkXYatxy35lwr1F5PyIzIw/z4GfVZLaeKUSSbzMsf8DwnwkqlYt1yYTahj5TthAIHPy5w3eWYl11yEZ59fDBjnBaZUDEAJpgM35AlNbeKXsRBf/1RmyZaXYk8NiXiRYvwSkhXpyf1wPsinuATg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ucfh9PR/hUVZ5CYzSpg5fpcKc3g4PNqj1US1IT1dzZA=; b=Nd8os1vdyqgiAjFnMzq6F3aVdlo9pxRmp9BFdDX+UFWm1pSOOR/T935LBtj+l5wKm0MYtcerItMNIeE7hT0sadvrBh+PXom5fHA+WGY/fOMQWB0m6PvP/gnAjG4v+BqcHfv7hxnD8kYTPh0W7aJc8I2F31dwEkpAJWnA9BQCp15B3bnQbrYHhU8EAkoTtzOralgVces0/RiRy8iITRvfvLWG8uQk7TDEcYo1UxZqkht90D0DJV8tL4U1+wtA9LN90IZXEaTdqkqcqfClqcUJHpzQXBv9KoMZreTcEfp4ooA3ySRMELMzJGeaMAoeqo4O01Crgikl0TvcdGTfAfHxyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ucfh9PR/hUVZ5CYzSpg5fpcKc3g4PNqj1US1IT1dzZA=; b=zv83rE46KJfiZMyQsv9FiQebQNYHlIGjQxi4RiDI3rRlZ5ZvIIwNjMy/+57mEIbk9WMA11GGnET/DJQwwhYfZf5/rl7D7Loa6YHqgAJvcUY93VlGTOFSRfdFo/2oHx2AzeRkDpd3m+pGPayRocH48VT8oeXdNe7T2M/SXCXgk9U= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 23 Sep 2026 10:42:37 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 5/5] x86/nestedsvm: fix up To: chunjie.zhu@citrix.com, xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech References: Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P302CA0021.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c1::12) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SJ0PR03MB6927:EE_ X-MS-Office365-Filtering-Correlation-Id: 9f058b63-a0c4-4db4-7ea0-08df195703b9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|4143699003|10067099003|11063799006|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: RBhO/zh5pxGgKsx5tiNWXx+KH9VnBcCEiPSP1u2TBkGvVs0HXeNopOA+COwZNTg9iyk09LnZuVmBu0Kzd/cutnU2vLDAwNZFsAR7IC3N82zWciIw3Jnk2HvVLd0/EEEzInyGESiOk6OZMPSsArewCt7phs2T+C7jdO17d7EYrmAqzr/HL0PPNghfWd5sfiwx4XalQXmNV7YCOelh9PRvoSEpyphtL4wcZpaQFx0qclqraDbil7QcsJxKF7h1eaw/8lT8iFOg3+ghCRDCv1V/IIBHt6Rym5bqQDrA2Y880ble297VYpA1jb2NkaUwXXgNH8t71RbOIzBDstrc7M9wMZGwV4k8EYaPJyzaWiRd8m1J8PyYwototOqavLxvgCtE68H3lvmQwq3zsQkIWaAZZOzjuzI6atNQ9JmgdBu3h01wvMPmZS23DBRh8utSMpFhAN0go+8yMJo1IhdZon3NWg28EeMeIj48yOO+9yu2emT3/VJiF1p7aQqggRpvUFw0/QKmg5ZuYU94FYDuXZTURsDI3Lx2crQzFwuqt2y0MWe4KXiiMlqSLMeZnU+zn9qhqu9pZDdWHg6Lh8Lj5WHaK8tVNymp35bu8xx/Jqfr6szrSGYJq8lozGrtZ1aBewnFHjfrt1hpKAIsvNb/xU3wLbrQ+aZNiXRdkMO2EQjp43s= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(4143699003)(10067099003)(11063799006)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZUhUVEVIVXBlS25kV0pjbjlVZzZWYVF3UUpKQ3hQZFFURXA0emo2OTBuZXdz?= =?utf-8?B?MlBYUjVPVVpzT0FCeXZDSC9HS2hiMWVDYWFGZmcxV1VHajBXVUo3L2VGSjJn?= =?utf-8?B?Y08vL0dmU08xaVFORUJXSFBOaU9kYmdCOWVnRlpvSHpwdnZ4R2k1VzlIbCtp?= =?utf-8?B?WlREQUtVNFV2L2RPNHVKelZUb0grQUZrRFVJYjBaeXBzL1o3Umt2R05ndnpr?= =?utf-8?B?M0t1NUV3OGExK04vTzBuS2tWVGVJald4bFZkeENvc25uYUlKbzlVU0NxU1kx?= =?utf-8?B?L0pOYWt0YWZ4TTBsYUtiWTJkYTN4cFhzaDJrcXBhNHd6OVVqUmR0S3JVa0da?= =?utf-8?B?b0xZY1ExWGF2Unk3QnJRRzFCQUV5OWtnWVB5aENnSk9zallPcmRRL00zeXBK?= =?utf-8?B?K1FKUWdRU3V6Yi8yMDgrYUNscG9yb1B4OTFKWDhxRDhXRFg5RnJwT3V1QWYv?= =?utf-8?B?OWIwRmhDWkF5bzJ0WWRuNHYwZXlJWHFuQXhTRTg1a3gvcnBxU3NONktmbjZt?= =?utf-8?B?MFdoM1ZocnFPbnRJeFZhaTh2bmQrclVSM2Q3U0ZmSlhSY2NTb2pUemhsQzg3?= =?utf-8?B?bmZ1em1UM05ZR2FRbFhCbll5dTBxdExDQTRjY3BFZHM4dTJpRG51ano1ZmYx?= =?utf-8?B?M0J4RHc3TE1zQUNDRFZsZjQwOU1rWHBBcndIZGt6WERLTWxLTndSckZYdVBE?= =?utf-8?B?dEFsTkU3OWhCV2V5YzlGSHk5SEdyMytQd1VxWUNlYWhiZWI0SGdQZlJvNjh0?= =?utf-8?B?aDhIc0FiYWFwcE55MHJ2dUtSME04dFZNVE9uNE1QMEl3UEpUTWR2aFJWWE5n?= =?utf-8?B?cnBTR2gzN1FHZGhZWlFGV1RwcWwvTitEWHV5dDBQS1pLYWRvdkRQdTJ1WUpv?= =?utf-8?B?R2dNdXFjZERoVmJwRk9iOUFzSGtDWHk4ZlJJMjBHZVRtbWlGcTdDRzcybU1R?= =?utf-8?B?dGFKdE1maUJKOHpwQy8yTmFvZE4wYnNES1RmS09Mb0FPbTJiMGtPZ2Vwb3hm?= =?utf-8?B?WEtmUEVtQm5KOVpsb0phZGozbWZkMVFuRi9ZUFdPSllId1NhMWpYQjFnU09y?= =?utf-8?B?ZHpqWU91bEVVUG5kd2lnWjc1KzdUQy9mcUNIdC8rT0VET2ZqS29vb3E1L25x?= =?utf-8?B?VzlORXJnRFkydG1mbGY3N0JvS0lKQjB6R0ZoQXZWR043N1VxUmt1YmkrYXRy?= =?utf-8?B?L0p0S0daVUdoZW5MOHN1cW1wZ2oyNjIxWEFaVVNsMWZjSnlTRU5iSzRQbnIr?= =?utf-8?B?TUJZaTZFMmxDZUpQUzRPZEM3MThSNmx3NDVVUnFReDVxY2tQa1F4UitBY2pE?= =?utf-8?B?ZHJ2UWJuV3Fyam82RitEYmF1b2lJbzh2aThYc0htZmpweG1YMC9iUDdPTUhX?= =?utf-8?B?eGVQc2dtRkpWRXFmK2tzc0xkdlhDa05Ba0FYUURFL2w5Vk9kRnB2Vmk3UjVR?= =?utf-8?B?dm9YZGEzSHF1dDJIbmdKbEJ6dnMzbEY0a1N3WkdoMFRZUFF3cGRSUWpzNmNJ?= =?utf-8?B?OVZKTWs4a1VtaWw2M1REQllLWWVvVzJvWmFpcGNkWVU5RkVuN3hoTUN0ZWJJ?= =?utf-8?B?bU16cVBodmhCWDlGUGJiQTIwSkQ2eXZ1dEJGT0dJN2pNZ0tBbm5sL3dtc0t5?= =?utf-8?B?aVg5Umh2cUJ6c2FtMmFEb2M2YytMZFBzLzFyNjRqZDZrY1NOUTNodEN4Q0t4?= =?utf-8?B?dlc2WXI2amd5V3hMUlZBOXBVYytwaCtKL3dvb1pvLy9BbkM1clpMcW4xWEJO?= =?utf-8?B?VmlPNkgzOGhzVjFSNHNSNzcrd3dIdGx4Mms1cG00eHlQckEwVzVMZFhlOGZP?= =?utf-8?B?K2kwS29wWStIdktiN2NrWWZHTmFPMDAyWXk0Ky9KR0UxY1JZWTQ1WmZBM1NO?= =?utf-8?B?Y0xKYkpHckFIUDFYRnJUQnhPNGRKQU4vanpJdnRBazNzdVlSeUMramZuaFM3?= =?utf-8?B?Y1hGSWpmOHdLZnlVYkpnTFA2cERYWGJ0YVhTcDZWQWcxaUxERERrRjcvQXZL?= =?utf-8?B?YnB2WVZVNmR2Mmhob3FnRUxyenBySzdYQSs0Rml4UUF1MzQ0ZUtpM3JtdTNp?= =?utf-8?B?RHdCdlE2dlNvbkRMSHRwOFd5M1lTZWVRdFdmWG1LN3J5c0hKNzR3elFSR0tE?= =?utf-8?B?VUo5NkV2bU5GaHhwOTlzU01aWnJHYmpVY09GeHZqSFArVXh2aHFxcTdFVHFE?= =?utf-8?B?R2p2bnhMOWNmd1VXbVN0bFhYVFRTOUorbStJdk1Sb3VSOXk1alNmTDZ1ajUx?= =?utf-8?B?RC9rKzErVGVUMjhQeWR2dW5qZVpIcG9OSlRpb3pqMGJoSEdvVmdNQTkyT1Zj?= =?utf-8?B?OTY3V2tZVFlhZnZwWWxLazVlc1JCa25ieTJXVnJrU203c3d0ZkJnMHl6TGEx?= =?utf-8?Q?yx9nGSgLzR5g2D0A=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f058b63-a0c4-4db4-7ea0-08df195703b9 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:42:42.6904 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fjnRtKOx6krCj9T0XrZ7pPp4WPbKn6M+0Zp2auVUEz132/cELeEC++kK2zzprjAI0DkOr0ag9sHX5Nwzw1A9zD1KOaQnLO0VX55viZK/GB4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6927 X-purgate-ID: tlsNG-d62444/1790156567-1FC69757-282F0547/0/0 X-purgate-type: clean X-purgate-size: 4193 On 9/23/26 10:20 AM, chunjie.zhu@citrix.com wrote: > From: Chunjie Zhu > > Signed-off-by: Chunjie Zhu > --- > xen/arch/x86/hvm/svm/nestedsvm.c | 19 ++++++++++++++++--- > xen/arch/x86/hvm/svm/vmcb.c | 9 +++++---- > xen/arch/x86/mm/p2m.c | 5 +++++ > 3 files changed, 26 insertions(+), 7 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c > index 82e01e513e69..91872af8aa7b 100644 > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -355,7 +355,7 @@ static void nestedsvm_vmcb_set_nestedp2m(struct vcpu *v, > vcpu_nestedsvm(v).ns_vmcb_hostcr3 = vvmcb->_h_cr3; > > p2m = p2m_get_nestedp2m(v); > - n2vmcb->_h_cr3 = pagetable_get_paddr(p2m_get_pagetable(p2m)); > + vmcb_set_h_cr3(n2vmcb, pagetable_get_paddr(p2m_get_pagetable(p2m))); > } > > void nsvm_vcpu_update_nestedp2m(struct vcpu *v) > @@ -373,6 +373,7 @@ void nsvm_vcpu_update_nestedp2m(struct vcpu *v) > return; > > p2m = p2m_get_nestedp2m(v); > + nv->stale_np2m = false; > > /* > * This may happen if we've handled VMEXIT_NPF at the same time as a > @@ -383,8 +384,6 @@ void nsvm_vcpu_update_nestedp2m(struct vcpu *v) > vmcb_get_h_cr3(nv->nv_n2vmcx) != > pagetable_get_paddr(p2m_get_pagetable(p2m)) ) > nestedsvm_vmcb_set_nestedp2m(v, nv->nv_vvmcx, nv->nv_n2vmcx); > - > - nv->stale_np2m = false; > } > > static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) > @@ -1024,6 +1023,20 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; > struct vmcb_struct *n2vmcb = nv->nv_n2vmcx; > > + ASSERT(v == current); > + > + /* > + * The physical VMCB fields covered by VMSAVE/VMLOAD may not be in sync > + * with v's vmcb if a context switch happened since the last VMLOAD. > + * VMSAVE below would otherwise capture stale/foreign register state > + * into the L1 shadow VMCB. > + */ > + if ( v->arch.hvm.svm.vmcb_sync_state == vmcb_needs_vmload ) > + { > + svm_vmload_pa(v->arch.hvm.svm.vmcb_pa); > + v->arch.hvm.svm.vmcb_sync_state = vmcb_in_sync; > + } > + > svm_vmsave_pa(nv->nv_n1vmcx_pa); > > /* Cache guest physical address of virtual vmcb > diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c > index 5354c4f1b85f..2f7053ed7eec 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -357,10 +357,11 @@ bool svm_vmcb_isvalid( > PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n", cr0); > > if ( (cr0 & X86_CR0_PG) && > - ((cr3 & 7) || > - ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && (cr3 & 0xfe0)) || > - ((efer & EFER_LMA) && > - (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr))) ) > + ((!(cr4 & X86_CR4_PCIDE) && > + ((cr3 & 7) || > + ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && > + (cr3 & 0xfe0)))) || > + (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr)) ) > PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3); > > valid = hvm_cr4_guest_valid_bits(v->domain); > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c > index 027b9ae69be3..d1fafc479c78 100644 > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -1517,7 +1517,12 @@ p2m_get_nestedp2m_locked(struct vcpu *v) > np2m_base &= ~(0xfffULL); > > if ( nv->nv_flushp2m && nv->nv_p2m ) > + { > + p2m = nv->nv_p2m; > + if ( p2m ) > + p2m_flush_table(p2m); > nv->nv_p2m = NULL; > + } > > nestedp2m_lock(d); > p2m = nv->nv_p2m; This seems to have combined several bug fixes from our internal patchqueue (I know because I wrote some of them...), some of which have already been posted to the list. It's not clear why they were submitted as part of this series. Ross From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:51:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:51:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430009.1652631 (Exim 4.92) (envelope-from ) id 1x9JdP-0004Jn-Pc; Wed, 23 Sep 2026 09:51:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430009.1652631; Wed, 23 Sep 2026 09:51:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JdP-0004Jg-Mz; Wed, 23 Sep 2026 09:51:27 +0000 Received: by outflank-mailman (input) for mailman id 1430009; Wed, 23 Sep 2026 09:51:26 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9JdO-0004Ja-Oe for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:51:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9JdN-005kew-Q7 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:51:25 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a11d-e002-0a2a0a5209dd-0a2a4501d596-2 for ; Wed, 23 Sep 2026 11:51:25 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a116-5984-0a2a45010019-a0658308e986-3 for ; Wed, 23 Sep 2026 11:51:19 +0200 Received: from xenrt10716048 (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id B6AB845A9FF8; Wed, 23 Sep 2026 05:49:14 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Lin Liu To: xen-devel@lists.xenproject.org Cc: Lin Liu , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH] x86/nSVM: Save L2's CR4 on #VMEXIT, not Xen's Date: Wed, 23 Sep 2026 09:51:15 +0000 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790157079-C4B45757-6EC62B25/0/0 X-purgate-type: clean X-purgate-size: 1111 Xen leaks the host's CR4 bits to L1. nsvm_vmcb_prepare4vmrun() constructs the shadow VMCB's CR4 via hvm_set_cr4(), and svm_update_guest_cr() ORs in HVM_CR4_HOST_MASK. nsvm_vmcb_prepare4vmexit() then copies CR4 back out of the shadow VMCB instead of the value kept in v->arch.hvm.guest_cr[4], so L1 reads back Xen's bits - under HAP, CR4.MCE. Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") Assisted-by: Claude:claude-opus-5 Signed-off-by: Lin Liu --- xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index a8b15d6eae..8d99b0affc 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -1082,7 +1082,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) ns_vmcb->_efer = n2vmcb->_efer; /* CRn */ - ns_vmcb->_cr4 = n2vmcb->_cr4; + ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4]; ns_vmcb->_cr0 = n2vmcb->_cr0; /* DRn */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 09:55:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 09:55:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430042.1652644 (Exim 4.92) (envelope-from ) id 1x9Jhg-0004vL-Ai; Wed, 23 Sep 2026 09:55:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430042.1652644; Wed, 23 Sep 2026 09:55:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Jhg-0004vE-7z; Wed, 23 Sep 2026 09:55:52 +0000 Received: by outflank-mailman (input) for mailman id 1430042; Wed, 23 Sep 2026 09:55:51 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Jhf-0004v8-A7 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 09:55:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Jhe-008YhE-NE for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:55:50 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a226-bab6-0a2a0a5309dd-0a2a450ada92-2 for ; Wed, 23 Sep 2026 11:55:50 +0200 Received: from [52.101.46.49] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a224-f2d2-0a2a450a0019-34652e3145f9-3 for ; Wed, 23 Sep 2026 11:55:50 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CH2PR03MB5192.namprd03.prod.outlook.com (2603:10b6:610:90::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.16; Wed, 23 Sep 2026 09:55:47 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 09:55:47 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QW3P08R9FBshieWcfVJCGf8EHV3vze0Km9Q2y/daInrPc7pe0gUt7r4grCJlNiJ4k3pN1a/L3Vg+jkFejwVO07wxGiUgmakobVXKjbNYfBFZpsH1hXTLOow5p65jphH4ZKBxIY1EHlxc6O0ejLVUrmIxaccITLpqLtuw3g9RjTvcl5ZGp4WAqE/oFpwSs18EdOwMkaKLYpOmKFysWXCsPekVFIxKhQZalMwYG/mlsUIPo8Nfx8OYgfuBlTmNLig3tEXvZ0eCGSDAXI+yl69eZTeDFU6x0GlO6XdEngPFP1JL6ivucwA64sR3/fGiXApXt0d1f5AvF/meEngiB58mmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ql/HNTMaNe4Qijw/njauqk0Pyeg8MFu3OjIs10pvGjY=; b=Nn8Lv2dpz55YFmls1CH/PYAvYG5vQN0D2ZchdYXLaBb0FYdyXRAFmvHKXXyg4LdDjLvrETHAlhh+vM8KVhtYLFppEjOQqFQQE16h8uexqn/J3ZIyTEg2jncDI6jOvrKDxh+aYrznB2H7OdS6LkM7s3tUxi9LHM8TmZze4PO8Kw4M/bhsRG8h+w2GC7f/rJTgJyabkpSwH9kCeWCbchbl5rvmR1HR1GJLe5UN3QCpHHR2TH/MKCXhg0wWGx40hHt7mpvKCt5Yn3T4mlBKjttdW2LI3WtK876q5kn4tKD+2f17bY/xBQoCcmAjlAa9Odk3rpZX0gCfFdpyOiHYOQ5G0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ql/HNTMaNe4Qijw/njauqk0Pyeg8MFu3OjIs10pvGjY=; b=OMAuIP7pO9DuABZKReHkECYgqobNBHvYm6aX3An91d5Te/xmDDTTfEg03wgJm5Q9HWYHMU/IVCmTiwXBt0mWPv6ubCHg8B3ijB3OeOGblGmd0jIfz8i4LNrIy3ArDaY+8r3bMZnQGUhnXlWxgjcu4gZL8luok+AfHHRsJF1n/SM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Date: Wed, 23 Sep 2026 10:55:41 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 5/5] x86/nestedsvm: fix up From: Ross Lagerwall To: chunjie.zhu@citrix.com, xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0107.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:191::22) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|CH2PR03MB5192:EE_ X-MS-Office365-Filtering-Correlation-Id: ca166abb-5f8b-4299-d500-08df1958d752 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|23010399003|1800799024|4143699003|10067099003|11063799006|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 35fBlqY0rz0BxXhxpVajKgoR4kih6YYW1HYtfOgukS0Hms4n5QY5uS1YOhzmTU1U3RYjNwpRhb24ZpgXTprHjK/v2EWKFAc1QLAYNwVmbJPDv3YmUrDHRcBisbJh6XCyOIAbtbWvk60g+aQw7EzdIfizSxVA4XV18sKJL4KJAakdqaIrel9xvZhZb352DVH2Z8GErOxEDkBuOPWky3525WlKEMbfxs6wUBOvGd9XsVsA2nhjJxJkAvPHQmtJrGH3qcnpYqbE6fgA8Vr/mhyaBocYLTDcsdcMLEaFr0KbYZL1BvHzbguEuaE/iMgJaTmy6dPYoeALMAWuACtyyqFeNeHBArI3r6NxK3nfFGfz1XWRzaC8gAqqAKVFumsruGrNnT0i6dNPCzj/TdZvCBmZJQtN4KVg45Qa90hxIPdtwKXUYyqOSflPE0GqCjgaMmVeONw2bfSBT6X/+Q/zUu/x1/2/zqa1tgHh3Frwj9RxAGSwCs0BEYelpQ7iABuAvRSG4aXypYcE/31YQLNwcdHN7ZHYIzx7n5eexauZmGnEkoyLLSUlAe1Tvb11syBmr2Qn76SQP/fx7dPLVkU3fFbl+JSMoj197k8zkuODBU9NFutb2AtNqDXWDfmDFDJ4u5J/TC39hfoVWj2ILNGKOybt9PIZ/fBe7zBNwNEcithqGIA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(23010399003)(1800799024)(4143699003)(10067099003)(11063799006)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ajczSGRnSlo4eTUrcVZFSnh0Z3U1MHNmYU4zcWVHQzVHT21kMDJTVVg0V3BE?= =?utf-8?B?ZGpvRGtaN0FXS2lhSVY5TDl6dEI1N0tZUGxDVlQzM0d5QStTalpJeVNjdk9i?= =?utf-8?B?TEFVVXExbU5ETnA2WXhpYlBoMjdhQXZSSThBQUlZRS9BK2ZvOXFOQVNPejFL?= =?utf-8?B?Y2xFaHNWcTVvR2phMUpCM1YvTVZLVGRUNGp3M245ZjVnSEoyb2tKOW5ia2or?= =?utf-8?B?VXE4T2E1ZXp4ZVJYdWFXTFlOQzNTeWVuS1pOWG9JVEZlMTVua1d3aFIyKy9S?= =?utf-8?B?THNpa0V2bThVbzduNXUvUE5STE1Rb202Z2ZOSDNZaGI1aVpKSEtBYTRZVDJG?= =?utf-8?B?MUZaOHlkZXhpSDg2bDJjUGhCQWNGQWZtVDV1VzZsdFk3eTR3Vm82cWExd3Qz?= =?utf-8?B?OHZhcHV0TjBaUUw4VjNQVDBHa2RsaGxFRk9MK3lvMjR1MUFrVDlObjdLcVRw?= =?utf-8?B?NFFGUWZIYlRjcXM5TEczWVlnU0lVL0FsWUNYS0YwL1VZaW5QNzFZN0FpTnpj?= =?utf-8?B?Uy9mcmhpSlZVTEpKbmt2bWRTZzFIKzRjNnVRZ0g4SWd1TktscEsxTDR6dGR0?= =?utf-8?B?eHF1a0hmVEtETnJoUXM3dnBZMmVjbllILzZGYUZVYWx2bnI1a2tiTUJ5UzVv?= =?utf-8?B?WjdHUzYvOFRLVVd3WWlOMndnUFhSVjhNaUpTZFNVUk9VNG02by9nVTV3MjZs?= =?utf-8?B?WkVUUm16QXJXSm9yMXI1Q01Cc1JKVUZCTTBWMFRBeHhvdzEyTzhkWVYrUTFK?= =?utf-8?B?bnNpYzdoV3FLMnhReGd1a0hQcXQ0MGZiQTYydTdLRHJXQUlFdS91K1NrLzJS?= =?utf-8?B?VytGS0Mvb3RjWjRvR2hCWFpSMDRBSEVuNkV1M2dkcjBWSlAra2h6NGUrS2ow?= =?utf-8?B?ZjVUSnYxWVNydVNUTXZQYjlZNHNiUW53d1MyRFhKaGNaZUlUTHBscUdiOS9T?= =?utf-8?B?R0ZkV3hySlArSGFUbE5wQzRLRHlXVExOMW9IcXdTc0NlYkRXckh2NHJONG14?= =?utf-8?B?ZUR6UHplZStPSnFkOXNBZ1Fkc2QzTjNHN094NFF2U1NiTDIyZGZYY3FGdG44?= =?utf-8?B?Z3pOYmIyUlpNRjJXaEV2L3hHaGN5YnhxaVpBSFIvaXYwWDR4RmhXbHVPRDVJ?= =?utf-8?B?WTdhS1RpcDl1Y0E2K3FyYmcvc3lHNTg5blVCS0paSitURGRTVmN3d3ZhZWty?= =?utf-8?B?V0kwcFRnc0tESWhnVHN0QmxkZmI1MXlwbEpSQlcxaStGSVVDdzN4N0RtWmJC?= =?utf-8?B?WllJR01JZWdxZUdCVWZvMVpzdEJIS05lMVgyQ1lLU0FIY0NweUpVWlFPcUZX?= =?utf-8?B?bWJIK0lPUnM0NVpXSDRjRUJMb2psR2pxalBPZUVuckFpWXVtZTNuVGt1ZGZS?= =?utf-8?B?cXJKeXhsbGduVHZzamFOT2NSZTllU1FsaUdBVVBxY0VlVWsyalF0K3BTd2hF?= =?utf-8?B?N0ROMGhXUVFvVDBiRGRVUmlxOGI5b1czOEgybkRJS2ZFenc1Y2JEbkgyRzJP?= =?utf-8?B?RnBzbE9laVNYbU0wVEhKbGRDcDNKeWJ4OEZIUE5KK1FXL0grYVhGWG5hNG11?= =?utf-8?B?Ti9sd0c0ZjBjRU9BUUE5Rjc5UVo4V2RiWjc0amZoQkhIL3NnTG5XV3VycnVY?= =?utf-8?B?QXJ1K0FJZ096RVFMdjVYTm10QlRPR2FzN0lUaFgvT1dFZmM3akNjNjJTTTlF?= =?utf-8?B?aHA2WWZTZTUrZkp0WjhDck1UcXRUQWZ0ZDF5V3h3eE1HeGFGMjM5UUliblY5?= =?utf-8?B?TTM0L0ZqMmRlSGRSb1pBYzlHdHU2MlBLSFd4UHRjdkhGRGdXdUVSYWF0QWF6?= =?utf-8?B?dnVPQzJNaVR6RnVpYjJzK09JMS9ZTVk2ZXR3T1VjYlZQQy9wcEIzbGVEZzNy?= =?utf-8?B?Z2lTNHdZVDN3RkxyTS9tUzM2SlBpOVhFa1FGVXZCR042UXdSSUhaRWRMR2Fq?= =?utf-8?B?SlBNaHVjS3krOExWZWpJMHB6b3RnMStLQkpUcEpERXBBWFNXOXBISXRpUVF1?= =?utf-8?B?NzJYOXBNKzFYWWZKZmpLSlhjSG9WU1piNVBIZ1NDMzI0TlRGdndGZGxvdkd6?= =?utf-8?B?THB4RnJJMEE4S3RYS2h2cUNlVGoyWlFSY0lCaWhqSVA1QkViTW5QNXNyK0JO?= =?utf-8?B?WmdwcTN1MWZtL1ZmbHZWQjZ3UUg0K2cwQXNsWUtMcnZpMFBkbW5jeVVjalBh?= =?utf-8?B?OFpyUjNvOEJuS1E3RzVBeEppTjFJYXlkdG8yS3lJMGdFUzJ1a3h6ZDN1eUhh?= =?utf-8?B?YUxzMkxRN2RpYzVDT2JEdXdWSkhaaldxMXZ5NUZMeXFXd3o1TUNNaE5ZTW40?= =?utf-8?B?U0ZsRWxyTnhYc0JkenhUNjVtQ3BlaklSUlZRZnMwS21GcVpiWE1qT2FIYkNa?= =?utf-8?Q?J+JxnwXgLjZMwk4o=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca166abb-5f8b-4299-d500-08df1958d752 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 09:55:47.1867 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7IHiF6+ljH0+bDgrU5BG5Q2o8bN9pkkNrxB07gyxQpUCrp0MTqK20TWyucigRN/ijaQmyYC810U58qVQHcpiPbfOqZX5MPsXy8gcDOY+P1E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5192 X-purgate-ID: tlsNG-4011c0/1790157350-530D9CFC-547B07A0/0/0 X-purgate-type: clean X-purgate-size: 4656 On 9/23/26 10:42 AM, Ross Lagerwall wrote: > On 9/23/26 10:20 AM, chunjie.zhu@citrix.com wrote: >> From: Chunjie Zhu >> >> Signed-off-by: Chunjie Zhu >> --- >> xen/arch/x86/hvm/svm/nestedsvm.c | 19 ++++++++++++++++--- >> xen/arch/x86/hvm/svm/vmcb.c | 9 +++++---- >> xen/arch/x86/mm/p2m.c | 5 +++++ >> 3 files changed, 26 insertions(+), 7 deletions(-) >> >> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c >> index 82e01e513e69..91872af8aa7b 100644 >> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >> @@ -355,7 +355,7 @@ static void nestedsvm_vmcb_set_nestedp2m(struct vcpu *v, >> vcpu_nestedsvm(v).ns_vmcb_hostcr3 = vvmcb->_h_cr3; >> p2m = p2m_get_nestedp2m(v); >> - n2vmcb->_h_cr3 = pagetable_get_paddr(p2m_get_pagetable(p2m)); >> + vmcb_set_h_cr3(n2vmcb, pagetable_get_paddr(p2m_get_pagetable(p2m))); >> } >> void nsvm_vcpu_update_nestedp2m(struct vcpu *v) >> @@ -373,6 +373,7 @@ void nsvm_vcpu_update_nestedp2m(struct vcpu *v) >> return; >> p2m = p2m_get_nestedp2m(v); >> + nv->stale_np2m = false; >> /* >> * This may happen if we've handled VMEXIT_NPF at the same time as a >> @@ -383,8 +384,6 @@ void nsvm_vcpu_update_nestedp2m(struct vcpu *v) >> vmcb_get_h_cr3(nv->nv_n2vmcx) != >> pagetable_get_paddr(p2m_get_pagetable(p2m)) ) >> nestedsvm_vmcb_set_nestedp2m(v, nv->nv_vvmcx, nv->nv_n2vmcx); >> - >> - nv->stale_np2m = false; >> } >> static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) >> @@ -1024,6 +1023,20 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >> struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; >> struct vmcb_struct *n2vmcb = nv->nv_n2vmcx; >> + ASSERT(v == current); >> + >> + /* >> + * The physical VMCB fields covered by VMSAVE/VMLOAD may not be in sync >> + * with v's vmcb if a context switch happened since the last VMLOAD. >> + * VMSAVE below would otherwise capture stale/foreign register state >> + * into the L1 shadow VMCB. >> + */ >> + if ( v->arch.hvm.svm.vmcb_sync_state == vmcb_needs_vmload ) >> + { >> + svm_vmload_pa(v->arch.hvm.svm.vmcb_pa); >> + v->arch.hvm.svm.vmcb_sync_state = vmcb_in_sync; >> + } >> + >> svm_vmsave_pa(nv->nv_n1vmcx_pa); >> /* Cache guest physical address of virtual vmcb >> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c >> index 5354c4f1b85f..2f7053ed7eec 100644 >> --- a/xen/arch/x86/hvm/svm/vmcb.c >> +++ b/xen/arch/x86/hvm/svm/vmcb.c >> @@ -357,10 +357,11 @@ bool svm_vmcb_isvalid( >> PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n", cr0); >> if ( (cr0 & X86_CR0_PG) && >> - ((cr3 & 7) || >> - ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && (cr3 & 0xfe0)) || >> - ((efer & EFER_LMA) && >> - (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr))) ) >> + ((!(cr4 & X86_CR4_PCIDE) && >> + ((cr3 & 7) || >> + ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && >> + (cr3 & 0xfe0)))) || >> + (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr)) ) >> PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3); >> valid = hvm_cr4_guest_valid_bits(v->domain); >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c >> index 027b9ae69be3..d1fafc479c78 100644 >> --- a/xen/arch/x86/mm/p2m.c >> +++ b/xen/arch/x86/mm/p2m.c >> @@ -1517,7 +1517,12 @@ p2m_get_nestedp2m_locked(struct vcpu *v) >> np2m_base &= ~(0xfffULL); >> if ( nv->nv_flushp2m && nv->nv_p2m ) >> + { >> + p2m = nv->nv_p2m; >> + if ( p2m ) >> + p2m_flush_table(p2m); >> nv->nv_p2m = NULL; >> + } >> nestedp2m_lock(d); >> p2m = nv->nv_p2m; > > This seems to have combined several bug fixes from our internal patchqueue (I > know because I wrote some of them...), some of which have already been posted > to the list. > > It's not clear why they were submitted as part of this series. > Looking further, patches 1, 3, and 4 also contain seemingly unrelated patches from our internal patchqueue. Can you resubmit this series without these patches mixed in? Or if they really are required dependencies, (where they haven't already been posted to xen-devel previously) submit them as separate patches at the start of this series, maintaining authorship information. Ross From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:06:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:06:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430060.1652653 (Exim 4.92) (envelope-from ) id 1x9Jrw-0006r3-7J; Wed, 23 Sep 2026 10:06:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430060.1652653; Wed, 23 Sep 2026 10:06:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Jrw-0006qw-4G; Wed, 23 Sep 2026 10:06:28 +0000 Received: by outflank-mailman (input) for mailman id 1430060; Wed, 23 Sep 2026 10:06:26 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Jru-0006qq-GM for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:06:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Jrt-00Cjrz-TT for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:06:25 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a48f-bab6-0a2a0a5309dd-0a2a4509835e-44 for ; Wed, 23 Sep 2026 12:06:25 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a4a1-be1a-0a2a45090019-b9ff1c129b4f-3 for ; Wed, 23 Sep 2026 12:06:25 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0cdbb0c1a00072c4.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 10:06:22 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id D23DF81F02; Wed, 23 Sep 2026 12:06:21 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=r5NqY5tsuZfaGPJIedpq5IwF5L8Z+DtepEpxCtaInE4=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=RllTlgY3QkY7nVwEln6o6EYMCw5RAdtSxODpmMRRww44b/6gNCs4ssTTN1JBGtd8+9HnpsZ4O GrqVDQfqcjb0bjfo8jk/D/eUVf2ld1oVSvkVS8vUsJaHl7jGeG6AgeCL83mrSF3DktB4hxduTNq d+RUpL768TB871vrV9RY0M8KU3uce5tSJ+0ClQ3WaACrFvjsIkTy/oDr19Wz3tbpLn+uis/0x5u aseCuZivoqFEg725tZAw+KDqfIINefytAoYD5BJmvn5PqU+7I/V83fq6fPfcgJfKsOsu0ceres4 zJO1VPPK/BchL7+MecXrrssW7xm00yyvNuBRlPt4d9lg== X-Zone-Loop: a5155383f830a84273021001a2be5f010e20d6952db1 x-campaign-type: default x-transaction-id: 1b354796-2ab0-4433-8d28-f5ec0014c160 x-swg-uid: 01-3356e6df-90c0-4cbe-a0a3-bbe3bbe8f038 X-Mailer: Sweego Message-ID: <1790157982.8631fc262581453bbf619ec5b2062170.1a0cdbb0c1a00072c4@vates.tech> x-swg-bid: 1790157982.8631fc262581453bbf619ec5b2062170.1a0cdbb0c1a00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org In-Reply-To: References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> Date: Wed, 23 Sep 2026 12:06:16 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790157976; l=14422; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=2AMC610y6CbAB1J8ddN8wMcCnv+bO22uyf4SsFERXZM=; b=PPbU+V8AviL7wTmI4f/LUlxEvfjgDHoHHuC55iMfjdFWAcd4C2VpzmNNuahhW6k0urv9x6pP6 hjcHs/MveoQDV88Cz7ijMItiMFWd2l01ktFbFb9SdGtzvDGRt3Pn+2e X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790157982057 X-purgate-ID: tlsNG-bad1c0/1790157985-3BAD0034-722B2059/0/0 X-purgate-type: clean X-purgate-size: 14426 On 2026-09-22 17:29 +0200, Oleksii Kurochko wrote: > > > On 9/10/26 11:34 AM, Baptiste Le Duc wrote: > > p2m_set_permission() only presets the PTE A/D bits when the Svade extension > > is present in the device tree. This causes an unhandled page fault when > > neither Svade nor Svadu is present (the platform's actual behaviour is then > > unknown), and when both are present in the device tree. > > When both are present, RISCV_ISA_EXT_svade is set, so the current code > does preset the A/D bits and no fault happens. The only broken case is > when neither extension is present, so shouldn't "both present" be dropped? Yes i agree, I'll fix that in v3. > > > > > Move the Svade/Svadu resolution out of p2m_set_permission() and into a new > > riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). For each of > > the four possible Svade/Svadu combinations (inspired by [1]), it decides > > whether software has to preset the A/D bits and, if so, sets > > RISCV_ISA_EXT_svade to record that decision: > > - neither present: assume Svade, since assuming Svade is harmless on real > > Svadu hardware, while assuming Svadu on real Svade hardware risks an > > unhandled page fault > > - only Svade present: assume Svade > > - only Svadu present: leave A/D management to hardware > > - both present: Svade wins until Xen supports the SBI FWFT call needed to > > enable hardware updating of A/D bits, so assume Svade and warn that > > dropping 'svade' from the DT is the only way to get Svadu. > > > > [1] https://lwn.net/Articles/980016/ > > > > Fixes: ff14053983b0 ("xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration") > > Assisted-by: Claude:claude-opus-5 > > Signed-off-by: Baptiste Le Duc > > --- > > Changes since v1: > > - change commit title > > - expose RISCV_ISA_EXT_svadu so the two extensions can be told apart. > > - move the Svade/Svadu resolution to a new riscv_resolve_ad_scheme(), > > called once from riscv_fill_hwcap(). > > - expose sbi_probe_extension() (was static) to probe for SBI FWFT. > > sbi_probe_extension() is already non-static in staging, only the prototype > is missing. What base is this patch against? > > > - stop presetting A/D bits unconditionally in p2m_set_permission(), do it > > only when Svade is present. > > What is the gain from not presetting them? Presetting A/D is correct > with both Svade and Svadu: with Svadu it just saves the hardware an > atomic PTE update on first access. Xen doesn't consume G-stage A/D bits > (no dirty tracking, no demand paging), and pt.c already presets A/D > unconditionally for Xen's own mappings. Always setting PTE_ACCESSED | > PTE_DIRTY in p2m_set_permission() fixes the bug in one line, with no > need for the resolver, the new ISA bit, FWFT probing or the ASSERT. > Handling A/D differently only makes sense once Xen actually wants that > information, and at that point FWFT support and a fault handler are > needed anyway. I agree that presetting them is the right way, it is also the way linux is working. If Jan agree, I will to in that way in v3. Then, it seems there is no need to register Svade/Svadu at all in cpufeature.c, am I right? > > --- > > xen/arch/riscv/cpufeature.c | 59 +++++++++++++++++++++++++++++++++ > > xen/arch/riscv/include/asm/cpufeature.h | 1 + > > xen/arch/riscv/include/asm/sbi.h | 8 +++++ > > xen/arch/riscv/p2m.c | 47 ++++++++++---------------- > > 4 files changed, 86 insertions(+), 29 deletions(-) > > > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > > index 92235fdfd5..19454544a7 100644 > > --- a/xen/arch/riscv/cpufeature.c > > +++ b/xen/arch/riscv/cpufeature.c > > @@ -18,6 +18,7 @@ > > > > #include > > #include > > +#include > > > > #ifdef CONFIG_ACPI > > # error "cpufeature.c functions should be updated to support ACPI" > > @@ -468,6 +469,62 @@ static bool __init has_isa_extensions_property(void) > > return false; > > } > > > > +/* > > + * Svade and Svadu extensions represent two schemes for managing the PTE A/D > > + * bits. When the PTE A/D bits need to be set, the Svade extension indicates > > + * that a page fault will be raised. In contrast, the Svadu extension supports > > + * hardware updating of the PTE A/D bits. > > + * > > + * There are 4 possible combinations of these extensions in the device tree. > > + * The default hardware behavior for each is: > > + * > > + * 1) Neither Svade nor Svadu present in DT => It is technically unknown > > + * whether the platform uses Svade or Svadu. Xen should be prepared to > > + * handle either hardware updating of the PTE A/D bits or page faults when > > + * they need updating. In that case, Xen assumes Svade because it's > > + * harmless if the platform is actually Svadu, while assuming Svadu on real > > + * Svade hardware risks an unhandled page fault. > > + * > > + * 2) Only Svade present in DT => Xen must assume Svade to be always enabled. > > + * > > + * 3) Only Svadu present in DT => Xen must assume Svadu to be always enabled. > > + * > > + * 4) Both Svade and Svadu present in DT => Xen must assume Svadu is turned off > > + * at boot time by setting A/D bits. To use Svadu, the supervisor must > > + * explicitly enable it using the SBI FWFT extension. > > + * > > + * The Svade extension is mandatory and the Svadu extension is optional in the > > + * RVA23 profile. Platforms wanting to take advantage of Svadu can choose > > + * option 3. Platforms aware of the profile can choose option 4, and Xen won't > > + * get the benefit of Svadu until the SBI FWFT extension is available. > > + * > > + * In other words, hardware manages the A/D bits on its own only in case 3, in > > + * all the other cases software has to preset them. Instead of open coding this > > + * in every A/D bits user, RISCV_ISA_EXT_svade is used to mean "software is > > + * responsible for the A/D bits" and is set here for the cases 1, 2 and 4. > > + */ > > +static void __init riscv_resolve_ad_scheme(void) > > +{ > > + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > > + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); > > svadu is always false here: the patch doesn't add > RISCV_ISA_EXT_ENTRY(svadu, NONE) to riscv_isa_ext[], so match_isa_ext() > never sets this bit. Cases 3 and 4 are dead code. Am I missing something? > > > + > > + /* Case 3: leave the A/D bits management to hardware. */ > > + if ( svadu && !svade ) > > + return; > > + > > + /* Case 4 */ > > + if ( svadu && svade ){ > > + if ( !sbi_probe_extension(SBI_EXT_FWFT) ){ > > + printk(XENLOG_WARNING "RISC-V: Both Svade and Svadu detected, but SBI FWFT is missing.\n" > > + "RISC-V: Defaulting to software A/D updates (Svade).\n" > > + "RISC-V: To force hardware A/D updates (Svadu), remove 'svade' from DT.\n"); > > + } > > + } > > sbi_probe_extension() returns a negative errno on SBI failure, so > !sbi_probe_extension() is false in that case and an error is treated as > "FWFT present". The existing callers check "> 0", so this should be > "<= 0". > > > + > > + /* Cases 1, 2: Xen assume Svade to be enabled */ > > s/assume/assumes. > > > + __set_bit(RISCV_ISA_EXT_svade, riscv_isa); > > In case 4 RISCV_ISA_EXT_svadu stays set, so both bits are set and the > ASSERT() in p2m_set_permission() fires (once svadu is actually parsed). > This contradicts the "mutually exclusive" statement there. > > > +} > > + > > bool riscv_isa_extension_available(const unsigned long *isa_bitmap, > > enum riscv_isa_ext_id id) > > { > > @@ -513,6 +570,8 @@ void __init riscv_fill_hwcap(void) > > __set_bit(RISCV_ISA_EXT_sstc, riscv_isa); > > } > > > > + riscv_resolve_ad_scheme(); > > + > > for ( i = 0; i < req_extns_amount; i++ ) > > { > > const struct riscv_isa_ext_data ext = required_extensions[i]; > > diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h > > index 0c48d57a03..74200ce7c9 100644 > > --- a/xen/arch/riscv/include/asm/cpufeature.h > > +++ b/xen/arch/riscv/include/asm/cpufeature.h > > @@ -41,6 +41,7 @@ enum riscv_isa_ext_id { > > RISCV_ISA_EXT_sstc, > > RISCV_ISA_EXT_svade, > > RISCV_ISA_EXT_svpbmt, > > + RISCV_ISA_EXT_svadu, > > Please keep the same order as riscv_isa_ext[], i.e. between svade and > svpbmt, and add the matching riscv_isa_ext[] entry there as well. > > > RISCV_ISA_EXT_MAX > > }; > > > > diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h > > index 1952868e96..4f13e8c7a0 100644 > > --- a/xen/arch/riscv/include/asm/sbi.h > > +++ b/xen/arch/riscv/include/asm/sbi.h > > @@ -30,6 +30,7 @@ > > #define SBI_EXT_BASE 0x10 > > #define SBI_EXT_RFENCE 0x52464E43 > > #define SBI_EXT_TIME 0x54494D45 > > +#define SBI_EXT_FWFT 0x46574654 > > > > /* SBI function IDs for BASE extension */ > > #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 > > @@ -138,6 +139,13 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, > > int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, > > size_t size, unsigned long vmid); > > > > +/** > > + * Check if an SBI extension ID is supported or not. > > + * @extid: The extension ID to be probed. > > + * > > + * @return: 1 or an extension specific nonzero value if yes, 0 otherwise. > > + */ > > This is incorrect: on failure the function returns a negative errno, not > 0. Also, the rest of the file uses /* */ and not kernel-doc /**. > > > +int sbi_probe_extension(long extid); > > A blank line is missing before the next comment block. > > > /* > > * Initialize SBI library > > * > > diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c > > index 1cea86512c..22ad4a2aee 100644 > > --- a/xen/arch/riscv/p2m.c > > +++ b/xen/arch/riscv/p2m.c > > @@ -586,42 +586,31 @@ static inline void p2m_clean_pte(pte_t *p, bool clean_cache) > > > > static void p2m_set_permission(pte_t *e, p2m_type_t t) > > { > > + bool svade = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade); > > + bool svadu = riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svadu); > > This runs for every p2m PTE. The second test_bit() exists only for the > ASSERT(). > > > + > > e->pte &= ~PTE_ACCESS_MASK; > > > > e->pte |= PTE_USER; > > > > /* > > - * Two schemes to manage the A and D bits are defined: > > - * • The Svade extension: when a virtual page is accessed and the A bit > > - * is clear, or is written and the D bit is clear, a page-fault > > - * exception is raised. > > - * • When the Svade extension is not implemented, the following scheme > > - * applies. > > - * When a virtual page is accessed and the A bit is clear, the PTE is > > - * updated to set the A bit. When the virtual page is written and the > > - * D bit is clear, the PTE is updated to set the D bit. When G-stage > > - * address translation is in use and is not Bare, the G-stage virtual > > - * pages may be accessed or written by implicit accesses to VS-level > > - * memory management data structures, such as page tables. > > - * Thereby to avoid a page-fault in case of Svade is available, it is > > - * necessary to set A and D bits. > > - * > > - * TODO: For now, it’s fine to simply set the A/D bits, since OpenSBI > > - * delegates page faults to a lower privilege mode and so OpenSBI > > - * isn't expect to handle page-faults occured in lower modes. > > - * By setting the A/D bits here, page faults that would otherwise > > - * be generated due to unset A/D bits will not occur in Xen. > > - * > > - * Currently, Xen on RISC-V does not make use of the information > > - * that could be obtained from handling such page faults, which > > - * could otherwise be useful for several use cases such as demand > > - * paging, cache-flushing optimizations, memory access tracking,etc. > > + * riscv_fill_hwcap() sets either RISCV_ISA_EXT_svade or > > + * RISCV_ISA_EXT_svadu (mutually exclusive) depending on the Svade/Svadu > > + * device tree combination (see riscv_resolve_ad_scheme()): > > This isn't true, see the comment on riscv_resolve_ad_scheme(): in case 4 > both bits end up set. > > > + * - RISCV_ISA_EXT_svade means that software is responsible for the A/D > > + * bits. > > + * - RISCV_ISA_EXT_svadu means the hardware is responsible for the A/D > > + * bits. > > * > > - * To support the more general case and the optimizations mentioned > > - * above, it would be better to stop setting the A/D bits here and > > - * instead handle page faults that occur due to unset A/D bits. > > + * Currently, when RISCV_ISA_EXT_svade is set, Xen doesn't track A/D > > + * bits, so it does not make use of the information that could be > > + * obtained from handling the resulting page faults, which could > > + * otherwise be useful for several use cases such as demand paging, > > + * cache-flushing optimizations, memory access tracking, etc. To avoid > > + * such a page fault, Xen presets the A and D bits instead. > > */ > > - if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svade) ) > > + ASSERT(svade != svadu); /* exactly one of svade/svadu must be set by riscv_fill_hwcap() */ > > The line is over 80 columns, and the trailing comment just repeats the > block comment above. > > > + if ( svade ) > > e->pte |= PTE_ACCESSED | PTE_DIRTY; > > > > switch ( t ) > > > > ~ Oleksii > > > From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:27:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:27:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430103.1652697 (Exim 4.92) (envelope-from ) id 1x9KBu-0002ik-23; Wed, 23 Sep 2026 10:27:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430103.1652697; Wed, 23 Sep 2026 10:27:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KBt-0002iZ-Ul; Wed, 23 Sep 2026 10:27:05 +0000 Received: by outflank-mailman (input) for mailman id 1430103; Wed, 23 Sep 2026 10:27:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9KBr-0002Hw-V6 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:27:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9KBr-00Cn1P-Az for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:27:03 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a974-2eae-0a2a0a5409dd-0a2a4506a1fe-12 for ; Wed, 23 Sep 2026 12:27:03 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a977-195a-0a2a45060019-4a7de14cdc18-3 for ; Wed, 23 Sep 2026 12:27:03 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356256so271340f8f.1 for ; Wed, 23 Sep 2026 03:27:03 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fe0c50da7sm32786515e9.3.2026.09.23.03.27.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 03:27:02 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790159223; x=1790764023; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=5kx8u+4+gN/f3jyrEZQ5/Z1zPXMqe+olQFMfcDsueDo=; b=Bana6F6Unq8kmsd8fa29mucl0S7hcJ+oQWnNczEAlv05nTJotwZ2+PXY0FbNlXMn2Z ozoIMEAPxLgMltbvtmBbP50ZnBAfirbgamZ/E+dlFgVQy1pT9Pg9W08n1wLsW4dRTzrO lfZamerfMKX/LpSlg4VImzUlpZaEL3zk8JOgsmtwCmwNL/TiN5rnd7Nnxbi7M5Y48RIt 1ey0HzDRGDTSK2+VUiieLHeZQkT/I4JuvGzFALirQs4Ez9ZRZ18zTrUY9/P01GjXm32B wKWa7Ob3i0a4X3+/XsEhSq3I5OrcFMh44m3ofjbtGfq1zklOPvDPaP5YDe1vL6jmcnjU pMGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790159223; x=1790764023; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=5kx8u+4+gN/f3jyrEZQ5/Z1zPXMqe+olQFMfcDsueDo=; b=xoeSGuNfNwGBjowYiv8KydXuDLYwx/gzVMehVFTxXbl2Sl2uOuaN/TTwJe14i/eyAe NoU1gJb7Q18EhVoaMVnUcXry1hG3PjMPJTjzk/NLEhdMPXOeI7oeqzbzEBcTHBbJ1fQG Loq4S0bOmZ3lWCq5sfP36ngYRl+DXjLKwzDZ3q+4H2JbRFetuyVKXWQmfwOYYKBdrFQF +xL+IEu9rgYik4h2Yf97U2xKG0t+UWC7JkhTHGy+AaySbVl1TyWY6gX1OljcNfq2DLLv SN6O63+z7sTUwoImNJ5pnLTkKDPFcJN1NjASQclu/n7JmpYY/g3jOUABg3P0PHrzN4oP rcMA== X-Gm-Message-State: AFuF++lT0MYo3wUSioV70qIeCjRLWJTXQm4yfcM/fCfB61pb4tYtMsOA tsdNCx4IBpf4V9+xsiStysnsmQyRI5hHZiNoW+7EZ3tXOKzRUOlSWmSlpevzCg== X-Gm-Gg: AYBFou0/I6a0o6cXpsc0+2gnrAZegfs4QJChejjLsNlver3aTWhNgduLCXQSy6iUBI7 4reqvElN3tPE45hIy6uMTNxV+JJablC3CftYDQ0N5GzBPpfLt+yPhPJU7IbQmzOFpgCjGjadn+F Ea21m3WCSVDYvmds2ulg3DOom7HpJwRZ1bjWPJFTGRNnTNbEHekMdWHb8DfSZuKRzLt23BUKmwx T/TKdw8rSbPN3SZNIfQO6Arv1Fqf41kWzTyZhB/n2qwPI6lqzfeVlQipOgtup6Iuxau72tv8UYI waCxUHulC7NKI7pWHvQEoUPvZoBqo0ssemiZ5MlXhiTsA9Q9xksn1egTZvFjo1XLPkD3GOlJYka ZSCobKQLTvN1FxgNjtck7mdKEHjVRM1n2xJrzwO0CRbzXHLz0X1RzYBRnf9qIMBCQTT6+f+SnA6 nlXlEpMUdjQW9MpCyWhkwAFOG4eIu9LsusgWQprMuJnQbJIaCpLbYox5zhVMlTCaVPbVKi5t2cG Wl/YcanB91rG3JIjQGSl9QjPa4/ksHKJRdCgswJ X-Received: by 2002:a05:600c:c491:b0:49c:f13e:e4d with SMTP id 5b1f17b1804b1-49fde4972e0mr28673935e9.10.1790159222733; Wed, 23 Sep 2026 03:27:02 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v10 4/5] xen/riscv: provide init_vuart() Date: Wed, 23 Sep 2026 12:26:48 +0200 Message-ID: <38e68bf92ed375d644d89e474b23e6b767356ea3.1790158750.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790159223-FEC7777B-DE04DC65/10/73395122804 X-purgate-type: spam X-purgate-size: 1392 For debug purpose is enough to have only print messages from guest what is now implemented in vsbi_legacy_ecall_handler(). For full guesst console support it will better to have something similar to [1], thereby there is nothing specific should be done, at least, for now and init_vuart() is provided to make dom0less code buildable. [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2602041533440.3175371@ubuntu-linux-20-04-desktop/ Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v3-v10: - Nothing changed. Only rebase. --- Changes in v2: - Add Acked-by: Jan Beulich . --- --- xen/arch/riscv/dom0less-build.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index a1fa51b996a7..d1a51b92936a 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -8,6 +8,14 @@ #include +int __init init_vuart(struct domain *d, struct kernel_info *kinfo, + const struct dt_device_node *node) +{ + /* Nothing to do at the moment */ + + return 0; +} + int __init init_intc_phandle(struct kernel_info *kinfo, const char *name, const int node_next, const void *pfdt) { -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:27:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:27:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430101.1652676 (Exim 4.92) (envelope-from ) id 1x9KBr-00028k-FF; Wed, 23 Sep 2026 10:27:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430101.1652676; Wed, 23 Sep 2026 10:27:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KBr-00027s-9p; Wed, 23 Sep 2026 10:27:03 +0000 Received: by outflank-mailman (input) for mailman id 1430101; Wed, 23 Sep 2026 10:27:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9KBp-0001sj-Li for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:27:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9KBp-007M7V-2U for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:27:01 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a960-bab6-0a2a0a5309dd-0a2a450ac28c-44 for ; Wed, 23 Sep 2026 12:27:01 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a974-f2d2-0a2a450a0019-4a7de18cdc8b-3 for ; Wed, 23 Sep 2026 12:27:01 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49ce364488dso2283075e9.0 for ; Wed, 23 Sep 2026 03:27:00 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fe0c50da7sm32786515e9.3.2026.09.23.03.26.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 03:27:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790159220; x=1790764020; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=KpfnDxVNKFDlD58v4ZzoleMMovfePdIbFSWKYF746yM=; b=ScppvQDyDGmncMdd9XvG8KiDrviatoabM5d7iRY7h+Xpx3iNTQLrZr9D7zc3hGnann zg0Pd0A6dZwI4CWjK/8vNblfcH9cenVr3O3TXOwH4xG6/jk8RWaIZmHuhUm10d7vg/oX Sun0OLub4ZddlovpdNSweodw19oaNisOVN1PKMIwqeyW/nebLQ75m5NqymkW4QshZ1yA C7n38bd2/CZkoh/y7U6Qi2LvI0FZKkK3AKsvYq6eyNHlFlcFOvanq9wp/8IDIa2SfBpb VktxSqSOk75+uFFz/1M26GxB7cz26KDzCup54zAgQVIJvJKOKktdvuEm/Fef3J9o+Oe5 XrKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790159220; x=1790764020; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=KpfnDxVNKFDlD58v4ZzoleMMovfePdIbFSWKYF746yM=; b=cc23gIjQZFKY0pAnmOv6yu731PXjcBkMgm4Ig0c3W3mxRJgJKpeRu4Axyrbvsqp0lL QFcMCAB54zLDARQzZZO9Uo4mECu83Xv0pn2+rzqzMLJ9IcDjCP7sl3UJvJ0TZR8k0BPY thKzM0lji+tP1ibE8EE71dksL3uGTZsVaaGWqhh9L3OzB4XFNB7M7a53+liEXzC5dvaA UgXqfXf+agT55GJ7T+Um6YTovKOE2dH6vqKRbrneYeeWtQwF+iW4rNMZsiwKmv6I22BY CjwKBmozxf6e222IIE/Ud1iRtwXXfQWp0F7jCqqNAV2qOmCkJ86eHnDm8JCb+2sE4KeQ S01g== X-Gm-Message-State: AFuF++lCF5Y8xepYN5WLZiEyKBjMU1BVeWFlj+p+bQKLeK2pM+mYtAgR MgSld+CXgDqezda3Ztrw8H8H/f2cO3OOdXZafa6HFSrhGQe6+RBgdo1ZU2Da3w== X-Gm-Gg: AYBFou19eOfC+h8mj+BSVZDCy3QkRiOsqAJsRmCzfqy8+npco9xnwq16kdNox1gYI37 tbUd12OWVs4d6/fSjWMfvhPxnoi75z9zGaDk7IDENv6tSz58yJcbzzhQfIywog0OkGICakqaDjD YeqcQGopai97C9tY6P5Bq8QuAZHnthVz6bRHFMHalmsEyFinEyCiuvSCPV83ktvMU6qxWy/dmtV Q4AQ5T5E1SjA6qeXAZcaPDoxsXqxCYoXDXGLzRKVxdzj52RcfexKU5pqMoQahhryMT0oCR87hyz TCQljqaO3tLPXxHwfGV80kVFB5hnpNbnYCoLv5XRAmequATrZEqwcXzal4GO72oh+qWI5iOLgoS l2s39/8k4c8XMS4Tmn2b43gfsquLBEL5wHPIeHw+GBcweabb6MktfrxHrzxhiJJ/Iu4F9Ic3R/3 oMWv3Izu2RPfxl4Uz8itfPrl+nnGD9xcLjYdiDzWgJcM/gqH7SZrcGt7HX4lubzNO9zPn/34Ehq jTxgHAiFhjArqIhOMtsN/kNVNARjmI/8hJcHxSjgbHtgN+JcpE= X-Received: by 2002:a05:600d:8491:10b0:49f:ce79:7a8d with SMTP id 5b1f17b1804b1-49fde4acce8mr22118605e9.17.1790159220516; Wed, 23 Sep 2026 03:27:00 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v10 2/5] xen/riscv: implement init_intc_phandle() Date: Wed, 23 Sep 2026 12:26:46 +0200 Message-ID: <1867ae29fb0f1819c3e75cbea4132b2ebd04cc62.1790158750.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790159221-532D8CFC-936C456C/10/73395122804 X-purgate-type: spam X-purgate-size: 1379 Implement init_intc_phandle() to read phandle of interrupt controller node and save it in kernel->phandle_intc for the future usage during creation of guest interrupt controller node. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v4-10: - Nothing changed. Only rebase. --- --- xen/arch/riscv/dom0less-build.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index 4cc00012aa8d..a1fa51b996a7 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -4,9 +4,26 @@ #include #include #include +#include #include +int __init init_intc_phandle(struct kernel_info *kinfo, const char *name, + const int node_next, const void *pfdt) +{ + if ( dt_node_cmp(name, "intc") == 0 ) + { + uint32_t phandle_intc = fdt_get_phandle(pfdt, node_next); + + if ( phandle_intc != 0 ) + kinfo->phandle_intc = phandle_intc; + + return 0; + } + + return 1; +} + int __init make_arch_nodes(struct kernel_info *kinfo) { /* No RISC-V specific nodes need to be made, at the moment. */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:27:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:27:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430099.1652662 (Exim 4.92) (envelope-from ) id 1x9KBp-0001sw-Te; Wed, 23 Sep 2026 10:27:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430099.1652662; Wed, 23 Sep 2026 10:27:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KBp-0001so-QZ; Wed, 23 Sep 2026 10:27:01 +0000 Received: by outflank-mailman (input) for mailman id 1430099; Wed, 23 Sep 2026 10:27:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9KBo-0001sX-CE for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:27:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9KBm-005rd8-SJ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:26:58 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a96f-e002-0a2a0a5209dd-0a2a4501bed6-8 for ; Wed, 23 Sep 2026 12:26:58 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a972-5984-0a2a45010019-4a7de18cb79a-3 for ; Wed, 23 Sep 2026 12:26:58 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912e4b11so4254395e9.3 for ; Wed, 23 Sep 2026 03:26:58 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fe0c50da7sm32786515e9.3.2026.09.23.03.26.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 03:26:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790159218; x=1790764018; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=p0FbgLBdKZXhIzR4V4rrI9guUPzS0nIxbtBIqIXqrrM=; b=N8YPdsc/w8WC0E3un4QxSibcViGJ9u4QaPLw0bb4n8XckURFBL8hJtfGnutcc5T08n jViX1X+CJ/7JgPXvMGdnvIkzXHJWc5CMRRkBfPiiBbTQXl7iy9l12vNHiFZlasSF1+3w T+rwsyqAJ9ZDKQN9Y9cbbbHwbQTI4cYg5whyKgBKrdcLZvz58SEfOTmEx+QVEU0L1t8Q XuF7NJntN42zAjQJm/YkonhLRKit2fC5XK0IANANVjWnRChTpiVL81HtIuauUyKeif82 LII7LqxwgWtbHcLivzkjQjzWzMuaW1ZgkDgdWY74inBjKVmyZFeKQiNHCM6g2ajfgjxY 75SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790159218; x=1790764018; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=p0FbgLBdKZXhIzR4V4rrI9guUPzS0nIxbtBIqIXqrrM=; b=cC6ZnKRKSEY3DFfK7xRHSpFpe5Pv3IHOrIYP/lC69jET48f6+WeEQkd5OCkfJ0GqyS 4EcgESW9cd9XMHl4Pjs9Utpki9Rvd13s2QNKpnFkQf2HlfYDbcoWamGkrggzpYeqzKbj GtmmKSH5VsPENuGF7eyPgeEgs5Q6jr8X4DT0GsrIcf6a1vSEqmQhSgGIc0GP56m/xhk3 q5hf9J9sSNRlAjTJ54sNkzO4DhzbkWz57Rt1U9ymfwDVYeHbXAVmCaETd/bdDfkCnp0G CIC5k12W2287DbJ5Pd3aUAOgkQIiTr692zwW+t8c2mmb0OG3zjmNZByRL+Lekr1VbOTn LVxw== X-Gm-Message-State: AFuF++lLVcHKx+gX6ddPCUagteQ6pfLK3JlnidejaYhA12oleDztuvGj gvJx+g6MtEAKfjMztq76T5cvVNLcj2Wiab/gcgRN64yZgHBbuC93UmSj3TKj1g== X-Gm-Gg: AYBFou3Lg9h1dsr/uoiXtYeheEQdmTHbnrqUn8dBmxpaY1QF1PcSa8X4f3+ytD5Zlu0 XDzoH4yEU7uGZT7vCguCko8h108bUqk9wBJ+M50fac0NJy1wVDq54mA5NETiEgKfpNiNgWqlEjW y9eVhjg1hE1zyT2IMGKYGR3q4RmaCV1K0Ntz/xAzC0ae2HCcqk0Pw15uWaPllOWJN35+WReqG25 Y+4GkaylsCYkfUo5ULttb+x3BmMzOdjj6TL+Sf4eO5XChwVAL2krH08ol4OXdavyGMUoZxqd8+T xJyM6vOcvXo8ORsYsnn9sKbFX8CFWDLKK99n/0PdQmzdBArxS4bZBle4VBPQTj38uPgWJaCEd9b dPRBtofoeCkYi8eFlSMjoRfKRFejENPqwJpB+1bZ+Qa7RJ4JN8Ywyry11DrDanFNMz9kM5KaDCG fqTbWCGy58RjPApDpPEoNUjKx479RR8b2BCqIX003PAQK8ot2TwWR8bEpgsLePnQGsDKTNfPHxy Sk0zWBPrIUNCWbNAiMwKzO9UdHCa8w8+rX8pK61 X-Received: by 2002:a05:600c:354e:b0:49c:fc6e:a3d8 with SMTP id 5b1f17b1804b1-49fdf13d72cmr28320715e9.23.1790159218172; Wed, 23 Sep 2026 03:26:58 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" Subject: [PATCH v10 0/5] Introduce enablemenant of dom0less Date: Wed, 23 Sep 2026 12:26:44 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790159218-BE27A757-63234249/10/73395122804 X-purgate-type: spam X-purgate-size: 3805 This patch series reprensent a bunch of patches necessary to enable common part of Dom0less. The stuff necessary to start/launch domains will be introduced separately. CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2874531386 --- Changes in v10: - Address the comments. - First 15 patches from v9 were merged to staging. --- Changes in v9: - Address the comments. --- Changes in v8: - Address the comments. - Rename some variable in [PATCH v8 11/20] xen/riscv: introduce per-vCPU IMSIC state. - Drop vaplic_init() and vcpu_aplic_deinit() in [PATCH v8 12/20] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure. --- Changes in v7: - Merged to upstream/staging: - xen/riscv: Implement ARCH_PAGING_MEMPOOL - xen: arm: update p2m_set_allocation() prototype - xen/riscv: do a 4th linking pass if necessary - Address the comments from ML. --- Changes in v6: - Merged to upstream/staging: - xen: arm: move declaration of map_device_irqs_to_domain() to common header - xen/Kconfig: introduce HAS_STATIC_MEMORY - xen/riscv: rename enum intc_version to intc_variant - xen/riscv: implement prerequisites for domain_create() - Move UBSAN fix ("xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page") to this patch series as it is connected to "xen/Kconfig: introduce HAS_STATIC_MEMORY". - Address the comments from ML. --- Changes in v5: - Add new patch (xen/riscv: do a 4th linking pass if necessary) which fixes randconfig job issue. - Address comments from ML. --- Changes in v4: - Address comments from ML. --- Changes in v3: - Drop dependency from other patch series ([1] https://lore.kernel.org/xen-devel/cover.1778140240.git.oleksii.kurochko@gmail.com/T/#t) as it was merged. - Reorder patches: - move common patches to the start. - Move some patches to separate patch series (will be introduced later) - Address comments from ML. --- Changes in v2: - Move patch "[PATCH v1 04/27] xen/riscv: rework G-stage mode handling" to patch series [1] - Address the comments from ML. - The following patches were folded into one: # xen/riscv: implement init_intc_phandle() # xen/riscv: call do_initcalls() in start_xen() # xen/riscv: setup system domains - The following patch were folded into one: # xen/riscv: add vaplic access check # xen/riscv: emulate guest writes to virtual APLIC MMIO # xen/riscv: emulate guest reads from virtual APLIC MMIO - Add new bug fix, not really necessary to this patch series: xen/riscv: manage IRQ_DISABLED flag in APLIC irq enable/disable callbacks --- Oleksii Kurochko (5): xen/riscv: implement IRQ routing for device passthrough xen/riscv: implement init_intc_phandle() xen/riscv: initialize RCU, scheduler, and system domains in start_xen() xen/riscv: provide init_vuart() xen/riscv: add initial dom0less infrastructure support xen/arch/riscv/Kconfig | 2 + xen/arch/riscv/Makefile | 1 + xen/arch/riscv/aplic.c | 31 +++ xen/arch/riscv/device.c | 100 +++++++++ xen/arch/riscv/dom0less-build.c | 32 +++ xen/arch/riscv/domain-build.c | 28 +++ xen/arch/riscv/include/asm/guest-layout.h | 12 + xen/arch/riscv/include/asm/intc.h | 9 + xen/arch/riscv/include/asm/irq.h | 5 + xen/arch/riscv/intc.c | 60 +++++ xen/arch/riscv/irq.c | 260 ++++++++++++++++++++++ xen/arch/riscv/setup.c | 12 + xen/arch/riscv/vaplic.c | 10 + 13 files changed, 562 insertions(+) create mode 100644 xen/arch/riscv/device.c -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:27:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:27:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430100.1652671 (Exim 4.92) (envelope-from ) id 1x9KBr-00025S-4u; Wed, 23 Sep 2026 10:27:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430100.1652671; Wed, 23 Sep 2026 10:27:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KBr-00025L-1L; Wed, 23 Sep 2026 10:27:03 +0000 Received: by outflank-mailman (input) for mailman id 1430100; Wed, 23 Sep 2026 10:27:01 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9KBo-0001sd-Vf for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:27:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9KBo-00Cn1P-CU for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:27:00 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a974-2eae-0a2a0a5409dd-0a2a4506a1fe-4 for ; Wed, 23 Sep 2026 12:27:00 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a974-195a-0a2a45060019-4a7de14c9bca-3 for ; Wed, 23 Sep 2026 12:27:00 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f633ecdeso637768f8f.2 for ; Wed, 23 Sep 2026 03:27:00 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fe0c50da7sm32786515e9.3.2026.09.23.03.26.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 03:26:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790159220; x=1790764020; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VdRGXbL3r1ReXwiz3W+ag2f41ewb62moUHap2/8mMZo=; b=DI6grSujbFj1SE7Uvq5rjIsZD+F3dZoTOxkDlpVKKzX1WwOr+y0B8HG7TrwS9Mfzry h1Zd46glg+WA7BzH0FYw1SUlDFkItDXkZFFPMv1nwzCksGiHDWkOjSxpNMzIKAkMu8tU ys1+L1HPrcwPGxMHDGrX0JwUPwqufTowUoZ/LLs971O7PdEtBDifGxqmVDyO6+cf+vl+ GObac/P89lntm7w9081PiIC3DnKc7MEJ6wbZVtdI0ye2OG7Isze4gLaIrZhDg3cujHEo 9FdIq6ibh4bCKFa50LAAs9RuRfWhvkOxuexuH7AxOHBjVq47Fhu4JqprG6+eaxLO+PIa SuIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790159220; x=1790764020; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=VdRGXbL3r1ReXwiz3W+ag2f41ewb62moUHap2/8mMZo=; b=bzpjaYQq3EDUkS3ZWAifkuc99u7zimcvzsagT21Y1GYh9r162JECKgdbzsen0z81It S+Ye8pz1Qd4SNdMnjQDSuTfjSC8v111843wV6E1lI8lW5sP30L4dEwRdU9UTqXvJGhIS WCFCRJP5mjQ1Qpx7h0CuNXQhtsYAwpEeryji3CjUNlXcuKLctK+57OwxiNC+/I1zOl5T XzHmHQ7UpJJPoFQMfQkegpIs3/5/hmSRV2OzLzookHE4HlkS5kp8WrE0IQlBxm5n3RUQ Ecpp3gK9EYD2rmEXdtsw+ulXasNiZMdPi8qQazPLSewyFHdgc+7zoqCmTHhQh/B6mNty E61g== X-Gm-Message-State: AFuF++kaqfttpIWbSOZ1v8eTsFKG2ZIbQBz0Kq81KZGtCUkJgYQolMMD IDtxqxKCiOrAPHsOHTJ7UXpWdqRIQImhcTYvH5Iui3uMx8MA75uHLFi5Yg/W6w== X-Gm-Gg: AYBFou25k3qtPcuieHZL8Tt9LxB471KCiy5yYcsf/8iv9O3P48Sz1HW0J4qBSzSVDVh RrGiTm62gFd0rz2Rei57VljkmEwXwVHTs8Xi09hinhZiv3dmCIf5Iw/eeF9sMu5g5Su6YCsICDW iOtzxFMUXwNBUVTJQRog+ovCWwW2PR5dJv4cLN/QnVOgl0L64KYTIqa1bo+AldhBW744/UK4l8w RRrlHEyaMNcUWZWQ6b8+u+VlwCtMPaIbesnMeDolcd5oznzf4aWeEsz44RErPOm7Hgkv5AxgI2E AMA9UKHSLBqjC0Vd+GVFURJuaPA/jOfx6/BzEFG28DVPrEPNvxgm7lAkCVNdpANBnbLSsdr8r/i 7Ewob1RrLLdQ7xNwuK6qywuVGjAijTtTlxBHDUEK0cZ6eMmet/TnDUrhqetbOoB/4DkqMdXla3d eE7ew1CUoLjq621eMVt8vQPUZG0WKAmbjkK8Q+CSadJs/pPhZXrKTG21pMSWb8FpxOpsVgdWeaN xl/JXRaMgkmc4Ylx7g7U6rzUVOrKNIDT6OXKY/t X-Received: by 2002:a05:600c:3512:b0:49c:fc6c:be0d with SMTP id 5b1f17b1804b1-49fdf12b393mr30224995e9.19.1790159219441; Wed, 23 Sep 2026 03:26:59 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" Subject: [PATCH v10 1/5] xen/riscv: implement IRQ routing for device passthrough Date: Wed, 23 Sep 2026 12:26:45 +0200 Message-ID: <99d3f072b0c4b97e2ebac8b227bd57f90e780605.1790158750.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790159220-F440377B-F5CD01AC/10/73395122804 X-purgate-type: spam X-purgate-size: 31425 dom0less device passthrough requires granting guest domains access to device interrupts. Introduce map_device_irqs_to_domain() to enumerate a DT node's interrupt properties, skipping those not owned by the primary interrupt controller (as at the moment I haven't seen usages of it), and map_irq_to_domain() to grant domain access and configure Xen's interrupt descriptor accordingly. Sharing IRQ between domains is rejected. Both map_irq_to_domain() and map_device_irqs_to_domain() are marked __overlay_init, mirroring Arm: without CONFIG_OVERLAY_DTB this expands to __init, so the functions are init-only and need no XSM check; with CONFIG_OVERLAY_DTB they become runtime-callable, but the only runtime entry point is dt_overlay_domctl(), which performs the XSM checks at the domctl layer. RISC-V does not wire up DT overlay yet, so today these are strictly __init; if/when overlay support is added, the domctl-level XSM gating must be added together with it, as on Arm. route_irq_to_guest() and release_guest_irq() manage irq_desc ownership for guest-assigned interrupts. Each assignment carries a small irq_guest structure as irqaction::dev_id, recording the owning domain and virtual IRQ number which is 1:1 mapped to physical IRQ number. A per-domain vIRQ allocation bitmap (used_irqs in struct vintc), managed by vintc_reserve_virq(), prevents the same vIRQ being claimed twice. Host and guest interrupts may differ in some operations, EOI timing in particular: a host IRQ is completed once Xen's handler runs, whereas a passthrough IRQ must defer the physical completion until the guest issues its own EOI, otherwise a still-asserted level line would immediately retrigger and storm. Hence a separate guest hw_irq_controller instance, aplic_guest_irq_type, rather than an alias of the host one. Its callbacks are BUG_ON("unimplemented") for now. The only interrupt controller configuration supported so far is APLIC in MSI mode together with IMSIC, where guest interrupts are delivered by hardware straight to the guest's interrupt file, bypassing do_IRQ() and thereby Xen entirely. The _IRQ_GUEST branch in do_IRQ() is left as BUG() for the same reason. Real callbacks, .end() in particular, become necessary once a platform without direct IMSIC delivery has to be supported, where Xen traps the interrupt and injects it into the guest itself. Signed-off-by: Oleksii Kurochko --- Changes in v10: - Rename aplic_guest back to aplic_guest_irq_type, for consistency with aplic_xen_irq_type, and give it a distinct typename ("aplic-guest"). - Replace the remaining test_bit()/__set_bit() on desc->status with plain bit operations, as the v9 changelog claimed. The wait loop in irq_release_action() keeps test_bit(): the loop must re-read desc->status on every iteration because another CPU may clear IRQ_INPROGRESS. The volatile read performed by test_bit() prevents the compiler from hoisting the read out of the loop, which would otherwise leave the loop spinning forever on a stale value. cpu_relax() is not a compiler barrier, so it cannot provide this guarantee by itself. - Actually drop the init. of info->action.free_on_release, as the v9 changelog claimed. - Prefix the remaining "already used by ..." messages in route_irq_to_guest() with %pd, as the v9 changelog claimed. - release_guest_irq(): reword the comment above irq_detach_action() to say that a concurrent release "will see" IRQ_GUEST cleared, as with desc->lock held no racing check can occur. - Drop Arm change from this patch. - Update the description of the host/guest hw_irq_controller split: the two no longer share any callback. - Re-wrap an over-long comment in domain_vaplic_init(). --- Changes in v9: - s/aplic_guest_irq_type/aplic_guest + introduce stubs for callbacks instead of re-using callbacks used for Xen itself. - Correct the comment above action member of struct irq_guest. - Drop test_bit() from ASSERT() in irq_get_guest_info(). - Use bit operations instead of __clear_bit() in irq_detach_action(). - Fomrat do () while () in irq_release_action() according to code style. - Update the comment above irq_release_action() and inside (before smp_rmb()). - Make an argument of release_guest_irq() pointer to const. - Drop init. of info->action.free_on_release as it will be false because of how info is allocated. - Align comments in printk() inside route_irq_to_guest(). - Move smp_rmb() after the wait loop in irq_release_action() (inside it, it ordered nothing useful) and spin with cpu_relax(). --- Changes in v8: - vintc_reserve_virq(): return an error code instead of a bool: 0 on success, -EEXIST when the vIRQ has already been reserved (which legitimately happens for an IRQ shared between devices) and -ERANGE when the vIRQ is outside the range the vINTC provides. Document the function and its return values. - vintc_reserve_virq(): mark it __overlay_init, as its only caller map_irq_to_domain() is __overlay_init too. Add the and includes this needs. - map_irq_to_domain(): check the return value of vintc_reserve_virq() and propagate anything but -EEXIST. Otherwise the IRQ would end up routed to the domain without domain_vintc_deinit() ever releasing it again. Update the stale comment accordingly. - domain_vintc_deinit(): only walk used_irqs and free it if it has actually been allocated. domain_vintc_init() can fail after the vINTC itself has been allocated, leaving used_irqs NULL. - irq.c: split the body of release_irq() into two helpers: irq_detach_action(), which removes the action matching dev_id from desc->action with desc->lock held, and irq_release_action(), which waits for a handler still running on another CPU and frees the action with desc->lock dropped. Both document the locking rules they rely on. release_irq() is now just a wrapper around the two. - release_guest_irq(): use irq_detach_action()/irq_release_action() instead of open-coding __clear_bit(_IRQ_GUEST, ...) followed by release_irq(), which looked the action up by dev_id a second time. - release_guest_irq(): drop the -EBUSY restriction that only allowed unrouting from a dying domain. Detaching the action under desc->lock now closes the window this was working around. - route_irq_to_guest(): on the intc_route_irq_to_guest() failure path, detach the action while desc->lock is still held and only release it after the lock has been dropped, instead of dropping the lock first and calling release_irq(). - route_irq_to_guest(): initialise desc at its declaration. - irq_get_guest_info(): use ASSERT(desc->action) instead of ASSERT(desc->action != NULL). --- Changes in v7: - Build device.c as device.init.o: everything it provides is __overlay_init, which is plain __init as long as CONFIG_OVERLAY_DTB stays Arm-only. Unlike Arm, which picks device.o/device.init.o based on that config, RISC-V cannot enable it, so the choice is unconditional for now. - Don't have release_irq() free the guest IRQ info anymore: set free_on_release = false and free 'info' explicitly in release_guest_irq(), i.e. reinstate the xvfree() dropped in v5. The action stays embedded in struct irq_guest, so a single allocation still covers both, but it no longer has to be the structure's first member: the offsetof() BUILD_BUG_ON and the xvfree() of a pointer that merely happened to coincide with the allocation base are gone. The ->dev_id concern from v5 doesn't apply: release_irq() clears desc->action under desc->lock and waits for in-flight handling before returning, so nothing can observe ->dev_id once 'info' is freed. - Move 'action' to the end of struct irq_guest and reword its comment accordingly. - Use xvzalloc() instead of xvmalloc() for struct irq_guest, so that the embedded action is fully initialized (action.handler was left uninitialized before). - route_irq_to_guest(): free 'info' via the common free_info label when intc_route_irq_to_guest() fails, now that release_irq() no longer frees it. - Drop a stray blank line ahead of release_irq(). --- Changes in v6: - size nr_virqs as guest_aplic_num_sources + 1 to reserve APLIC's 1-indexed source 0, so the highest source/irq could be reserved. --- Changes in v5: - add early -EINVAL return in route_irq_to_guest() if domain is dying - use __clear_bit() instead of clear_bit() in release_guest_irq() since desc->lock is already held - remove irq_get_domain() wrapper; inline irq_get_guest_info(desc)->d at its single call site - reword IRQ_GUEST comment in do_IRQ() for clarity - move XVFREE(used_irqs) before the switch so it is freed prior to variant-specific vintc teardown - fix missing space in dt_dprintk() format string split across lines - Drop 'inline' for irq_get_guest_info() and leave it only static. - Drop xfree(info) from release_guest_irq() to avoid a potential dangling-pointer issue with the ->dev_id field. Now that 'struct irqaction action;' is embedded into 'struct irq_guest', 'info' will be freed as part of release_irq() at the end. --- Changes in v4: - Update the commit message. - Mark map_irq_to_domain() and map_device_irqs_to_domain() as __overlay_init (mirroring Arm) and include . - Fix grammar in the controller-skip comment ("IRQ" -> "IRQs"). - Drop the redundant 'base' local in guest_imsic_make_reg_property(); use GUEST_IMSIC_S_BASE directly. - Rename vintc::irq_nums -> nr_virqs and update all users. - Guard domain_vintc_deinit() against a NULL d->arch.vintc. - Use smp_rmb() instead of smp_mb() in release_irq()'s wait loop and document how it pairs with the spin_unlock() in do_IRQ(). - In release_guest_irq(), reject live unrouting from a non-dying domain (-EBUSY) and clear _IRQ_GUEST under desc->lock so a concurrent release for the same IRQ bails out instead of double-freeing 'info'. - Tidy spurious whitespace in release_irq()'s spin_lock/unlock calls. --- Changes in v3: - Drop extraneous "to" from "Unable to permit to %pd" message. - Move res/irq/rirq to loop scope; use nirq as declaration initializer. - Hoist irq_ranges check before the loop (it is loop-invariant). - Remove spurious forward declarations (struct dt_device_node, struct rangeset) from intc.h; remove all three from setup.h. - Use __set_bit() instead of set_bit() in intc_route_irq_to_guest() since desc->lock is always held on every write path for desc->status. - Use XVFREE() instead of xvfree() in domain_vintc_deinit(). - Rename allocated_irqs -> used_irqs in struct vintc. - Fix dangling desc->action in release_irq()'s !IRQ_HAS_MULTIPLE_ACTION path by nulling *action_ptr after saving the action pointer. - Use true (not 1) for free_on_release in route_irq_to_guest(). - Use %pd for domain printing in route_irq_to_guest() error paths. - Introduce release_guest_irq() to pair with route_irq_to_guest() and plug the irq_guest info leak; call it from domain_vintc_deinit() for each vIRQ recorded in used_irqs. --- Changes in v2: - Rework IRQ mapping in more common (similar approach to Arm). --- --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/aplic.c | 31 ++++ xen/arch/riscv/device.c | 100 ++++++++++++ xen/arch/riscv/include/asm/intc.h | 9 ++ xen/arch/riscv/include/asm/irq.h | 5 + xen/arch/riscv/intc.c | 60 +++++++ xen/arch/riscv/irq.c | 260 ++++++++++++++++++++++++++++++ xen/arch/riscv/vaplic.c | 10 ++ 8 files changed, 476 insertions(+) create mode 100644 xen/arch/riscv/device.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 511ced09ec7e..665ec2693335 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -1,6 +1,7 @@ obj-y += aia.o obj-y += aplic.o obj-y += cpufeature.o +obj-y += device.init.o obj-y += domain.o obj-y += domain-build.init.o obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index c2d7183e1852..17c96177a3b1 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -325,9 +325,40 @@ static const hw_irq_controller aplic_xen_irq_type = { .set_affinity = aplic_set_irq_affinity, }; +static unsigned int cf_check aplic_guest_irq_startup(struct irq_desc *desc) +{ + BUG_ON("unimplemented"); +} + +/* + * Shared by ->shutdown(), ->enable(), ->disable() and ->end(), which have + * no state. + */ +static void cf_check aplic_guest_irq_stub(struct irq_desc *desc) +{ + BUG_ON("unimplemented"); +} + +static void cf_check aplic_guest_set_irq_affinity(struct irq_desc *desc, + const cpumask_t *mask) +{ + BUG_ON("unimplemented"); +} + +static const hw_irq_controller aplic_guest_irq_type = { + .typename = "aplic-guest", + .startup = aplic_guest_irq_startup, + .shutdown = aplic_guest_irq_stub, + .enable = aplic_guest_irq_stub, + .disable = aplic_guest_irq_stub, + .end = aplic_guest_irq_stub, + .set_affinity = aplic_guest_set_irq_affinity, +}; + static const struct intc_hw_operations aplic_ops = { .info = &aplic_info, .host_irq_type = &aplic_xen_irq_type, + .guest_irq_type = &aplic_guest_irq_type, .handle_interrupt = aplic_handle_interrupt, .set_irq_type = aplic_set_irq_type, }; diff --git a/xen/arch/riscv/device.c b/xen/arch/riscv/device.c new file mode 100644 index 000000000000..fc41c075c772 --- /dev/null +++ b/xen/arch/riscv/device.c @@ -0,0 +1,100 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#include +#include +#include +#include +#include +#include + +#include + +int __overlay_init map_irq_to_domain(struct domain *d, unsigned int irq, + bool need_mapping, const char *devname) +{ + int res; + + res = irq_permit_access(d, irq); + if ( res ) + { + printk(XENLOG_ERR "Unable to permit %pd access to IRQ %u\n", d, irq); + return res; + } + + if ( need_mapping ) + { + /* + * -EEXIST merely means that the IRQ has already been reserved, which + * legitimately happens when the IRQ is shared between devices. Any + * other failure has to be fatal: the IRQ would otherwise be routed to + * the domain without domain_vintc_deinit() ever releasing it again. + */ + res = vintc_reserve_virq(d, irq); + if ( res && (res != -EEXIST) ) + { + printk(XENLOG_ERR "Unable to reserve vIRQ %u for %pd\n", irq, d); + return res; + } + + res = route_irq_to_guest(d, irq, irq, devname); + if ( res < 0 ) + { + printk(XENLOG_ERR "Unable to map IRQ%u to %pd\n", irq, d); + return res; + } + } + + dt_dprintk(" - IRQ: %u\n", irq); + + return 0; +} + +int __overlay_init map_device_irqs_to_domain(struct domain *d, + struct dt_device_node *dev, + bool need_mapping, + struct rangeset *irq_ranges) +{ + unsigned int i, nirq = dt_number_of_irq(dev); + + if ( irq_ranges ) + return -EOPNOTSUPP; + + /* Give permission and map IRQs */ + for ( i = 0; i < nirq; i++ ) + { + int res, irq; + struct dt_raw_irq rirq; + + res = dt_device_get_raw_irq(dev, i, &rirq); + if ( res ) + { + printk(XENLOG_ERR "Unable to retrieve irq %u for %s\n", + i, dt_node_full_name(dev)); + return res; + } + + /* + * Don't map IRQs that have no physical meaning + * ie: IRQs whose controller is not APLIC/IMSIC/PLIC. + */ + if ( rirq.controller != dt_interrupt_controller ) + { + dt_dprintk("irq %u not connected to primary controller. Connected to %s\n", + i, dt_node_full_name(rirq.controller)); + continue; + } + + irq = platform_get_irq(dev, i); + if ( irq < 0 ) + { + printk("Unable to get irq %u for %s\n", i, dt_node_full_name(dev)); + return irq; + } + + res = map_irq_to_domain(d, irq, need_mapping, dt_node_name(dev)); + if ( res ) + return res; + } + + return 0; +} diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index 6fc0e620e937..1bfba7c6155b 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -15,6 +15,7 @@ enum intc_variant { }; struct cpu_user_regs; +struct domain; struct irq_desc; struct kernel_info; struct vcpu; @@ -34,6 +35,9 @@ struct intc_hw_operations { /* hw_irq_controller to enable/disable/eoi host irq */ const struct hw_interrupt_type *host_irq_type; + /* hw_irq_controller to enable/disable/eoi guest irq */ + const struct hw_interrupt_type *guest_irq_type; + /* Set IRQ type */ void (*set_irq_type)(struct irq_desc *desc, unsigned int type); /* Set IRQ priority */ @@ -63,6 +67,8 @@ struct vintc_ops { }; struct vintc { + unsigned int nr_virqs; + unsigned long *used_irqs; /* Callbacks invoked during domain construction only. */ const struct vintc_init_ops *init_ops; /* Runtime callbacks used for the lifetime of the guest. */ @@ -76,10 +82,13 @@ void register_intc_ops(const struct intc_hw_init_ops *init_ops); void intc_init(void); void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority); +int intc_route_irq_to_guest(struct irq_desc *desc, unsigned int priority); void intc_handle_external_irqs(struct cpu_user_regs *regs); int domain_vintc_init(struct domain *d); void domain_vintc_deinit(struct domain *d); +int vintc_reserve_virq(const struct domain *d, unsigned int virq); + #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */ diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/irq.h index 62648bdc4252..57e814d90cf4 100644 --- a/xen/arch/riscv/include/asm/irq.h +++ b/xen/arch/riscv/include/asm/irq.h @@ -52,6 +52,11 @@ void init_IRQ(void); void do_IRQ(struct cpu_user_regs *regs, unsigned int irq); +int route_irq_to_guest(struct domain *d, unsigned int virq, + unsigned int irq, const char *devname); + +int release_guest_irq(const struct domain *d, unsigned int virq); + #endif /* ASM__RISCV__IRQ_H */ /* diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index f5c8af6ddea4..810d126e263d 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -3,11 +3,15 @@ #include #include #include +#include +#include #include #include #include #include +#include #include +#include #include #include @@ -78,6 +82,22 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority) intc_set_irq_priority(desc, priority); } +int intc_route_irq_to_guest(struct irq_desc *desc, + unsigned int priority) +{ + ASSERT(spin_is_locked(&desc->lock)); + + ASSERT(intc_hw_ops->guest_irq_type); + + desc->handler = intc_hw_ops->guest_irq_type; + desc->status |= IRQ_GUEST; + + intc_set_irq_type(desc, desc->arch.type); + intc_set_irq_priority(desc, priority); + + return 0; +} + int __init make_intc_domU_node(struct kernel_info *kinfo) { const struct vintc *vintc = kinfo->bd.d->arch.vintc; @@ -101,6 +121,15 @@ int domain_vintc_init(struct domain *d) break; } + if ( !ret ) + { + d->arch.vintc->used_irqs = + xvzalloc_array(unsigned long, + BITS_TO_LONGS(d->arch.vintc->nr_virqs)); + if ( !d->arch.vintc->used_irqs ) + ret = -ENOMEM; + } + return ret; } @@ -108,6 +137,20 @@ void domain_vintc_deinit(struct domain *d) { const enum intc_variant variant = intc_hw_ops->info->hw_variant; + if ( !d->arch.vintc ) + return; + + if ( d->arch.vintc->used_irqs ) + { + unsigned int virq; + + for ( virq = 0; virq < d->arch.vintc->nr_virqs; virq++ ) + if ( test_bit(virq, d->arch.vintc->used_irqs) ) + release_guest_irq(d, virq); + + XVFREE(d->arch.vintc->used_irqs); + } + switch ( variant ) { case INTC_APLIC: @@ -118,3 +161,20 @@ void domain_vintc_deinit(struct domain *d) break; } } + +/* + * Mark @virq as used by @d so that domain_vintc_deinit() knows that it has to + * be released. + * + * Returns 0 on success, -EEXIST if @virq has already been reserved, which + * legitimately happens when an IRQ is shared between devices, and -ERANGE if + * @virq is outside the range of the interrupt sources the vINTC provides. + */ +int __overlay_init vintc_reserve_virq(const struct domain *d, + unsigned int virq) +{ + if ( virq >= d->arch.vintc->nr_virqs ) + return -ERANGE; + + return test_and_set_bit(virq, d->arch.vintc->used_irqs) ? -EEXIST : 0; +} diff --git a/xen/arch/riscv/irq.c b/xen/arch/riscv/irq.c index b5066fc3e981..74a4e31f16be 100644 --- a/xen/arch/riscv/irq.c +++ b/xen/arch/riscv/irq.c @@ -12,11 +12,27 @@ #include #include #include +#include #include +#include #include #include +/* Describe an IRQ assigned to a guest */ +struct irq_guest +{ + struct domain *d; + unsigned int virq; + /* + * The action of a guest IRQ has the same lifetime as this structure, so + * embed it here to have both covered by a single allocation. Consequently + * it must not be freed on its own, which is why free_on_release is left + * false for it (see irq_release_action()). + */ + struct irqaction action; +}; + static irq_desc_t irq_desc[NR_IRQS]; struct irq_desc *irq_to_desc(unsigned int irq) @@ -198,6 +214,14 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq) if ( desc->handler->ack ) desc->handler->ack(desc); + if ( desc->status & IRQ_GUEST ) + /* + * With APLIC + IMSIC, guest interrupts bypass Xen and are delivered + * directly to the guest. Without IMSIC, interrupts would be trapped + * by Xen and would need injecting into the guest here. + */ + panic("unimplemented"); + if ( desc->status & IRQ_DISABLED ) goto out; @@ -227,3 +251,239 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq) spin_unlock(&desc->lock); irq_exit(); } + +static struct irq_guest *irq_get_guest_info(struct irq_desc *desc) +{ + ASSERT(spin_is_locked(&desc->lock)); + ASSERT(desc->status & IRQ_GUEST); + ASSERT(desc->action); + + return desc->action->dev_id; +} + +/* + * Detach the action registered with 'dev_id' from 'desc' and, if it was the + * last one, shut the interrupt down. + * + * To be called with desc->lock held, which is still held upon return. The + * detached action is returned (NULL if 'dev_id' had no action registered) and + * has to be handed to irq_release_action() once the lock has been dropped. + */ +static struct irqaction *irq_detach_action(struct irq_desc *desc, + const void *dev_id) +{ + struct irqaction *action, **action_ptr = &desc->action; + + ASSERT(spin_is_locked(&desc->lock)); + +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION + for ( ;; ) + { + action = *action_ptr; + if ( !action || (action->dev_id == dev_id) ) + break; + + action_ptr = &action->next; + } +#else + action = *action_ptr; +#endif + + if ( !action ) + { + printk(XENLOG_WARNING "Trying to free already-free IRQ %u\n", + desc->irq); + return NULL; + } + + /* Found it - remove it from the action list */ +#ifdef CONFIG_IRQ_HAS_MULTIPLE_ACTION + *action_ptr = action->next; +#else + *action_ptr = NULL; +#endif + + /* If this was the last action, shut down the IRQ */ + if ( !desc->action ) + { + desc->handler->shutdown(desc); + desc->status &= ~IRQ_GUEST; + } + + return action; +} + +/* + * Complete the release of an action detached by irq_detach_action(). + * + * To be called with desc->lock dropped: the lock cannot be held all the way + * through, as waiting for a handler still running on another CPU to complete + * requires do_IRQ() to be able to acquire the very same lock. + * + * Once this function has returned, the action (and hence any object embedding + * it) is no longer referenced by anyone and may be freed. + */ +static void irq_release_action(const struct irq_desc *desc, + struct irqaction *action) +{ + /* Wait to make sure it's not being used on another CPU. */ + while ( test_bit(_IRQ_INPROGRESS, &desc->status) ) + cpu_relax(); + + /* + * IRQ_INPROGRESS is cleared in do_IRQ() after re-acquiring desc->lock, + * and lock acquisition implies a full barrier, so the handler's accesses + * are ordered before the clearing becomes visible here. The barrier below + * adds the missing load-load ordering (the loop's exit branch already + * prevents the store in xvfree() from becoming visible early), so that + * having observed the bit cleared we also see whatever the handler did on + * that CPU. Only then is it safe to free the action. + */ + smp_rmb(); + + if ( action->free_on_release ) + xvfree(action); +} + +void release_irq(unsigned int irq, const void *dev_id) +{ + struct irq_desc *desc = irq_to_desc(irq); + struct irqaction *action; + unsigned long flags; + + spin_lock_irqsave(&desc->lock, flags); + action = irq_detach_action(desc, dev_id); + spin_unlock_irqrestore(&desc->lock, flags); + + if ( action ) + irq_release_action(desc, action); +} + +int release_guest_irq(const struct domain *d, unsigned int virq) +{ + struct irq_desc *desc = irq_to_desc(virq); + struct irqaction *action; + struct irq_guest *info; + unsigned long flags; + int ret = -EINVAL; + + spin_lock_irqsave(&desc->lock, flags); + + if ( !(desc->status & IRQ_GUEST) ) + goto unlock_err; + + info = irq_get_guest_info(desc); + if ( d != info->d ) + goto unlock_err; + + /* + * Detaching the action happens with desc->lock still held, so that a + * concurrent release_guest_irq() for the same IRQ will see IRQ_GUEST + * already cleared and bail out, rather than capturing the same 'info' and + * double-freeing it below. + */ + action = irq_detach_action(desc, info); + + spin_unlock_irqrestore(&desc->lock, flags); + + if ( action ) + irq_release_action(desc, action); + + xvfree(info); + + return 0; + + unlock_err: + spin_unlock_irqrestore(&desc->lock, flags); + return ret; +} + +/* Route an IRQ to a specific guest */ +int route_irq_to_guest(struct domain *d, unsigned int virq, + unsigned int irq, const char *devname) +{ + struct irq_guest *info; + struct irq_desc *desc = irq_to_desc(irq); + unsigned long flags; + int retval = 0; + + if ( d->is_dying ) + return -EINVAL; + + info = xvzalloc(struct irq_guest); + if ( !info ) + return -ENOMEM; + + info->d = d; + info->virq = virq; + + info->action.dev_id = info; + info->action.name = devname; + + spin_lock_irqsave(&desc->lock, flags); + + /* + * If the IRQ is already used by someone + * - If it's the same domain -> Xen doesn't need to update the IRQ desc. + * For safety check if we are not trying to assign the IRQ to a + * different vIRQ. + * - Otherwise -> For now, don't allow the IRQ to be shared between + * Xen and domains. + */ + if ( desc->action != NULL ) + { + if ( desc->status & IRQ_GUEST ) + { + struct domain *ad = irq_get_guest_info(desc)->d; + + if ( d != ad ) + { + printk(XENLOG_G_ERR "%pd: IRQ %u is already used by %pd\n", + d, irq, ad); + retval = -EBUSY; + } + else if ( irq_get_guest_info(desc)->virq != virq ) + { + printk(XENLOG_G_ERR + "%pd: IRQ %u is already assigned to vIRQ %u\n", + d, irq, irq_get_guest_info(desc)->virq); + retval = -EBUSY; + } + } + else + { + printk(XENLOG_G_ERR "%pd: IRQ %u is already used by Xen\n", + d, irq); + retval = -EBUSY; + } + goto out; + } + + retval = _setup_irq(desc, 0, &info->action); + if ( retval ) + goto out; + + retval = intc_route_irq_to_guest(desc, IRQ_NO_PRIORITY); + if ( retval ) + { + struct irqaction *action = irq_detach_action(desc, info); + + spin_unlock_irqrestore(&desc->lock, flags); + + if ( action ) + irq_release_action(desc, action); + + goto free_info; + } + + spin_unlock_irqrestore(&desc->lock, flags); + + return 0; + + out: + spin_unlock_irqrestore(&desc->lock, flags); + free_info: + xvfree(info); + + return retval; +} diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index a529a5b1dc49..6fbdc07805fd 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -113,6 +113,16 @@ int domain_vaplic_init(struct domain *d) vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO; + /* + * APLIC source 0 is reserved; sources are numbered + * 1..guest_aplic_num_sources and used directly as indices into used_irqs. + * Size the bitmap to guest_aplic_num_sources + 1 so the highest source has + * a valid slot (index 0 stays unused). Without the +1, + * vintc_reserve_virq() can't record the top source, so + * domain_vintc_deinit() never releases it. + */ + d->arch.vintc->nr_virqs = guest_aplic_num_sources + 1; + return 0; } -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:27:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:27:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430102.1652681 (Exim 4.92) (envelope-from ) id 1x9KBr-0002Hr-QZ; Wed, 23 Sep 2026 10:27:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430102.1652681; Wed, 23 Sep 2026 10:27:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KBr-0002G5-N1; Wed, 23 Sep 2026 10:27:03 +0000 Received: by outflank-mailman (input) for mailman id 1430102; Wed, 23 Sep 2026 10:27:02 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9KBq-00023I-Pp for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:27:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9KBq-007MAJ-6X for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:27:02 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a968-8faa-0a2a0a5109dd-0a2a45099624-14 for ; Wed, 23 Sep 2026 12:27:02 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a976-be1a-0a2a45090019-4a7de18c8dcb-3 for ; Wed, 23 Sep 2026 12:27:02 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49d097b4939so3821375e9.0 for ; Wed, 23 Sep 2026 03:27:02 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fe0c50da7sm32786515e9.3.2026.09.23.03.27.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 03:27:01 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790159222; x=1790764022; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=q4vFq/LEYOvho2Vznc9H6m0hLeL8wfPz9BeDI8XZDT0=; b=BBrJ+HWItGxxNhR01VY6fHbdWvWiQ18l/qw+U7cdUshN/W8VWhrRyBDe9gQwRE59HJ MNyi8swF6yQAs7wLLcLSX/uhICe+sMn1ZUB0mQFKGGNWRavAfxmboBeRjp8hWU1SRSrA OEhrNKZPuprfj84jvq9xQjhwzALe+CaJ+cZVEDWcsdxSErVH3avGuLOArMY6w+NmYPmc TzPFmF6cXi2Wn/d0ilmUM/wMv8CgV2wj1tsfY8ZzbyNTD9nUIggLsSB1tC9Cldxfl/Pd y4UHNRj1pga49o5bWm07r87dMsFo1/C4cWEkBn/kre3i06vh2Flm9Wjuc1rDjIHue2LF sPFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790159222; x=1790764022; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=q4vFq/LEYOvho2Vznc9H6m0hLeL8wfPz9BeDI8XZDT0=; b=0PD2CgMZJE7sKzuvkeAaWqJznaGghupV/jmkBQu+y/ueiA8UsClhZgNGSSwX5iIAc9 XtFCKXQlb+sZ7mPWYBQeGbe4OupyGBDOB0kYVuuuqn7J4qrkCIJ/7OqfvjMTVpD6Hnmf hXA2ak0NWrY0b6eCptEYK4BEO0YtUEwhTmpZEwffiELZ2zJoQ+qlDt0ah/v9ZpbKnk0e RHNObGHa1GmgMeop9M1XFgMKyOCJClejie03LXO1NT9rosA2aJoILpAbWARlnGYEV5KV 8GO0XFomDYsM9zh3wPOzMODeqc9KFnSBfDCPkdC6NrI7hUbtHaI7lYt4jQin2lezVVui 1x6w== X-Gm-Message-State: AFuF++nn8/yFVeeBegszRgL8432BDh/cN+dxgAm7HrA1SkF3KqE+SWSk p772fdKlOhbp9l3ybG+xbcCNRCryieXedkXT+xPqfzIBwqmPxmDjPQGvCcH2VQ== X-Gm-Gg: AYBFou3lf8t7uWZLdDY438pmvaz81u/S62iq9AUian7j6mKcaK+DUE+nmA4zVcG4fKP DF8Hs4le01n4R7Fxo1ybkMQGHzJuToMnzdDyVRo1xhfDTloKrBRcZyyPq59Czc/Jvuq19KolvgE oc4RpTUO8LmTsiBRhzYYLQFYXAzUbOJjRdi4pcZDpBXZrPcHNpHsrNXZdM1CDDS4ljBJvm5H07L yuNryWtcvciEz4QR9tqxBypPPqF74hAk0pnzTWbwpKzFYX4nb1jUqt+6udWBakVYw4jlJ+iEbu1 k6t/FM1WQb1xBpSfMF9JVWEaCitMmb1w2T2ET0iXmhJBO4WB3R3lq34Lm/U5yRlSD+tDRZv3yUC y8TucWuTDU2AG+5rBSV/wW3IAvJ8yS9G5X1e+xi60+JSMaveQ1RAoamSbvCfq4ELlUPV89hQXM5 U5hREWDvwAK/SbLiD4U/Rm+2vgNFYC9DvfmpzXmO8TYgh43eTwlnxBbE8k0EH6AlV+DE/YOp2+X IPperWReF5afcpPbfZJ3fwhjGZbzVPUOcjE2j4g X-Received: by 2002:a05:600c:8a0a:20b0:49e:719e:e215 with SMTP id 5b1f17b1804b1-49fdf13b2f2mr18342355e9.26.1790159221661; Wed, 23 Sep 2026 03:27:01 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v10 3/5] xen/riscv: initialize RCU, scheduler, and system domains in start_xen() Date: Wed, 23 Sep 2026 12:26:47 +0200 Message-ID: <715c9d8947e99d50cd09aace8aff8eaf3cd4a2f0.1790158750.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1790159222-BE6DA034-A0385B0D/10/73395122804 X-purgate-type: spam X-purgate-size: 1561 Wire up the missing early-boot initialization steps in start_xen(). The scheduler must be initialized prior to do_initcalls() because cpupool_create_pool() is called during initcalls; without it, BUG_ON(IS_ERR(pool)) is triggered inside cpupool_create_pool(). Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v4-10: - Nothing changed. Only rebase. --- Changes in v3: - Add Acked-by: Jan Beulich . --- Changes in v2: - New patch. Several patches were folded into one. --- --- xen/arch/riscv/setup.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index 07f46ac3ce27..05f93a74c9d3 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -6,9 +6,12 @@ #include #include #include +#include #include #include #include +#include +#include #include #include #include @@ -160,12 +163,21 @@ void __init noreturn start_xen(unsigned long bootcpu_id, timer_init(); + rcu_init(); + + setup_system_domains(); + local_irq_enable(); console_init_postirq(); guest_mm_init(); + scheduler_init(); + set_current(idle_vcpu[0]); + + do_initcalls(); + printk("All set up\n"); machine_halt(); -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:27:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:27:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430104.1652707 (Exim 4.92) (envelope-from ) id 1x9KBv-0002wj-A8; Wed, 23 Sep 2026 10:27:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430104.1652707; Wed, 23 Sep 2026 10:27:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KBv-0002w5-5e; Wed, 23 Sep 2026 10:27:07 +0000 Received: by outflank-mailman (input) for mailman id 1430104; Wed, 23 Sep 2026 10:27:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9KBt-0002gB-2U for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:27:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9KBs-007MCr-FZ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:27:04 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3a96e-bab6-0a2a0a5309dd-0a2a4507ddb8-38 for ; Wed, 23 Sep 2026 12:27:04 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3a978-b4ea-0a2a45070019-4a7de14cf61e-3 for ; Wed, 23 Sep 2026 12:27:04 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485b1d2874fso324962f8f.0 for ; Wed, 23 Sep 2026 03:27:04 -0700 (PDT) Received: from fedora (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fe0c50da7sm32786515e9.3.2026.09.23.03.27.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 03:27:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790159224; x=1790764024; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=8WcnksmCgRRRAB+VvLfDA0qN9GynfiODcVrvICZ2zO0=; b=MlvEgJFAqzeyKvAkNzYBMnC7k8qUwhzzv5WksCYekbS+S8QnQv3LjQTBhfvJWx/pPO agB+r+n+o9SuaOyLLBNFPUHO9LwZ69r5hou67MYszhRzGeioigbtC4ovmlaWcr8byvX/ BtqX8Bw5/iju2FmLTenYNB8jeLSZbbYJG3WxEToQSf780L9kvoSv2HrwEW9a++YQdsN9 lVxOk6NGUDjRSlha9YSeRnPANKjj6x6l4y9mUamRxFqA4HLc/62rEsqPPx1+CVy10NK7 aThtOct8JybQ5QEgjt1AyE/mNmaYz2S6EOhdbkb+z9+JSepFtqWL5TxSbCs61VeSnR1O r47A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790159224; x=1790764024; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=8WcnksmCgRRRAB+VvLfDA0qN9GynfiODcVrvICZ2zO0=; b=Qn7jkfQfC4rz3XoVXfqki3qwFuvZuzlWyL/GXwEMH0UeDB7EcFjfm06rAIF0Klb505 0aHGrO8pRnRyCGI4ICvgICenxBEwlg/26373DeTdRQaF8i06UEFj1ugXEqk01QDB6HUc po5OfLDj4tNsEtmCeeFtj8JKanJB8feUQTC1yQnB6/12PoCa9yRFv3Mbe4Z5bLk3ZEEG s7IW/YedryX4w+rFi+rjiUpSstqvsabsEywQVPdG8QKzAnLjIAjR1eqWH2MoJtZgyma4 CUF5uDniAEgbhjEufAnFKxaIXT5Gmfn6JyCl+z9OhZ7WQv7HSrjgQdm+7jE/PTM7N/d9 CBkw== X-Gm-Message-State: AFuF++kzm6j5Hj4BvNp3y8z+k15j438N8sGMYzt8DcEFcbQraDx/x3cE Hu9/G0smqWHZSlDUTYdYBKB/Fah1qtJKm2MP0EmKh7YTiQE7QgIqKZqOgRjs3A== X-Gm-Gg: AYBFou04cwQfBHyN50n8mPUiGLtI9qNu9EAL3G7MG9vjPXlarkwkbBJx8BM3yyUgGMw 6G9fDaQO3+zC+8jr2kosozLrYSn/N41Q9iFZHGwTy7V91lKttv38NyxeUswExH+8XEym5BEveHx JUZO9mu+Ho30wopFPyfXCE9soYN0+3Mnpuyc/MjF9fLf/IvZV9pd/2yn5lHEwPOZ/3/QGJF/9XQ 2BdwqfJk22XNfcU1fLsBci6zNoie+POYwIh5A1KVOXEqlfi3rdzoAoJF3qvT0oTJxm2Nb5wkTjx A1Iag2V/gmS7ltDwdF57xbuIBSnL8ej7SD1JD0VPSCkiJhgQxKz7eeM7p8o/uQrHeCZrODe+Vx3 5AVze8P+Vr9BxDAjbsF8DsHnqviOt3hO7HhJUfxGw3+fKQpHtGJtpdXVb7hPCahMOiIUl0k/lYV mZXcNF5kwwKsrqAwatW46oQk9sDpcXlLO7b0sHuWDm657Exu/vEZGpLt9RJzKoGjQzI+Q5c5xSh NHbSZNmfe04+j6cfNExq282SkJcbzWv33/82F/c X-Received: by 2002:a05:600c:1988:b0:49b:8f5e:51fb with SMTP id 5b1f17b1804b1-49fdf3571f9mr25058195e9.3.1790159223841; Wed, 23 Sep 2026 03:27:03 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v10 5/5] xen/riscv: add initial dom0less infrastructure support Date: Wed, 23 Sep 2026 12:26:49 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790159224-37AD0AE4-3655A5EC/10/73395122804 X-purgate-type: spam X-purgate-size: 7401 Enable dom0less support for RISC-V by selecting HAS_DOM0LESS and providing the minimal architecture hooks required by the common dom0less infrastructure. Add stub implementations for architecture-specific helpers used when building domains from the device tree. These allow the generic dom0less code to build and let a basic DomU be constructed on RISC-V. construct_hwdom() and make_hypervisor_node() are still stubs returning an error: Dom0/hwdom construction isn't supported yet, and the hypervisor node generation (needed by domains with DOM0LESS_ENHANCED_NO_XS set) is not implemented. Both are marked with a TODO and are not reached by the currently supported configurations. Provide missing helpers and definitions required by the domain construction code, including domain bitness helpers and the p2m_set_allocation() prototype. Additionally define the guest magic memory region (GUEST_MAGIC_BASE / GUEST_MAGIC_SIZE) in asm/guest-layout.h. The base is arbitrary; the only constraint is that the region must not overlap guest RAM or the emulated device regions. It is placed in the unused gap below GUEST_RAM0_BASE (0x80000000); the constraints are documented next to the #define-s. A separate region for grant tables will be introduced at the same time as the introduction of the grant table for RISC-V. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v8-v10: - Nothing changed. Only rebase. --- Changes in v6-7: - Acked-by: Jan Beulich . --- Changes in v5: - Reword the comment above defintion of GUEST_MAGIC_BASE. - Shrunk the size of GUEST_MAGIC_SIZE to 2Mb as looking on the Arm only 4 pages are used and there is no technical reason to have 16Mb for that region. (Maybe in case of Arm it is connected that Arm has these definitions in public header so more space is reserved to not "break" public API in future) - Update the commit message with a remark about grant table region in guest-layout.h. --- Changes in v4: - Reword the description: the stubs do not let dom0less fully "run" since construct_hwdom() and make_hypervisor_node() return an error; spell out these limitations instead. - Add a TODO comment to construct_hwdom() explaining that Dom0/hwdom construction isn't supported yet. - Add a TODO comment to make_hypervisor_node() explaining that returning an error breaks building of domains with DOM0LESS_ENHANCED_NO_XS set, and why that is harmless for now. - Document the constraints on GUEST_MAGIC_BASE/GUEST_MAGIC_SIZE next to the #define-s and drop the QEMU-based justification (QEMU is not involved); the base is simply an arbitrary non-overlapping address. Changes in v3: - Add /* Nothing specific to do for now */ comment to arch_handle_passthrough_prop(). - Use _ULL() instead of xen_mk_ullong() for GUEST_MAGIC_BASE and GUEST_MAGIC_SIZE (xen_mk_ullong() is intended for public headers only). - Fix GUEST_MAGIC_BASE from 0x39000000 to 0x79000000 to avoid the QEMU RISC-V virt machine PCIE_ECAM range. - Drop CONFIG_STATIC_MEMORY=n from the CI randconfig; now redundant since STATIC_MEMORY depends on HAS_STATIC_MEMORY which RISC-V does not select. Changes in v2: - Move declaration of p2m_set_allocation() to p2m-common.h. - Add __initdata for max_init_domid and drop initalizer for it. - Add CONFIG_STATIC_MEMORY=n to CI's randconfig to avoid compilation error because of guest_physmap_add_pages() isn't provided. --- xen/arch/riscv/Kconfig | 2 ++ xen/arch/riscv/dom0less-build.c | 7 ++++++ xen/arch/riscv/domain-build.c | 28 +++++++++++++++++++++++ xen/arch/riscv/include/asm/guest-layout.h | 12 ++++++++++ 4 files changed, 49 insertions(+) diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig index 48520588fe40..d8a348c0cf07 100644 --- a/xen/arch/riscv/Kconfig +++ b/xen/arch/riscv/Kconfig @@ -6,6 +6,8 @@ config RISCV select GENERIC_BUG_FRAME select GENERIC_UART_INIT select HAS_DEVICE_TREE_DISCOVERY + select HAS_DOM0LESS + select HAS_DOMAIN_TYPE select HAS_EX_TABLE select HAS_PMAP select HAS_UBSAN diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index d1a51b92936a..0801d7e25059 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -102,3 +102,10 @@ int __init arch_parse_dom0less_node(struct dt_device_node *node, return 0; } + +int __init arch_handle_passthrough_prop(struct kernel_info *kinfo, + struct dt_device_node *node) +{ + /* Nothing specific to do for now */ + return 0; +} diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c index d7613721db95..1e3abe259ccd 100644 --- a/xen/arch/riscv/domain-build.c +++ b/xen/arch/riscv/domain-build.c @@ -156,9 +156,37 @@ int __init make_cpus_node(const struct domain *d, struct kernel_info *kinfo) return fdt_end_node(fdt); } +int __init construct_hwdom(struct kernel_info *kinfo, + const struct dt_device_node *node) +{ + /* + * TODO: Dom0/hwdom construction isn't supported on RISC-V yet, so this + * is a stub returning an error. It must be implemented before a hardware + * domain can be built from the device tree. + */ + + return -EOPNOTSUPP; +} + int __init make_timer_node(const struct kernel_info *kinfo) { /* There is no need for timer node for RISC-V. */ return 0; } + +int __init make_hypervisor_node(struct domain *d, + const struct kernel_info *kinfo, + int addrcells, int sizecells) +{ + /* + * TODO: Generating the hypervisor node isn't implemented yet. Returning + * an error here breaks building of any domain (DomU included) whose + * dom0less_feature has DOM0LESS_ENHANCED_NO_XS set. This is harmless for + * now because Dom0/hwdom construction isn't supported on RISC-V yet + * either, and no RISC-V DomU sets that flag, so this path is never taken. + * It must be implemented before DOM0LESS_ENHANCED_NO_XS is used. + */ + + return -EOPNOTSUPP; +} diff --git a/xen/arch/riscv/include/asm/guest-layout.h b/xen/arch/riscv/include/asm/guest-layout.h index 90603f06bb91..ceed9125e7e2 100644 --- a/xen/arch/riscv/include/asm/guest-layout.h +++ b/xen/arch/riscv/include/asm/guest-layout.h @@ -32,4 +32,16 @@ #define GUEST_RAM_BANK_BASES { GUEST_RAM0_BASE, GUEST_RAM1_BASE } #define GUEST_RAM_BANK_SIZES { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE } +/* + * The guest magic region holds the Xen-reserved pages mapped into the + * guest's physical address space. The only real constraint on + * GUEST_MAGIC_BASE/SIZE is that the region must not overlap guest RAM + * (the GUEST_RAMx banks) or the emulated device regions defined above; + * the exact base is otherwise arbitrary. Here it is placed in the unused gap + * below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM bank would work + * equally well. + */ +#define GUEST_MAGIC_BASE _UL(0x79000000) +#define GUEST_MAGIC_SIZE _UL(0x00200000) + #endif /* ASM_RISCV_GUEST_LAYOUT_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:37:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:37:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430154.1652756 (Exim 4.92) (envelope-from ) id 1x9KM2-0006Pj-O6; Wed, 23 Sep 2026 10:37:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430154.1652756; Wed, 23 Sep 2026 10:37:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KM2-0006Pc-Kf; Wed, 23 Sep 2026 10:37:34 +0000 Received: by outflank-mailman (input) for mailman id 1430154; Wed, 23 Sep 2026 10:37:33 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KM1-0006PE-9C for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:37:33 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x9KM0-00DV8g-23; Wed, 23 Sep 2026 10:37:32 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x9KM1-007YNz-0R; Wed, 23 Sep 2026 10:37:32 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=pRiwT0funSy0byFkZn08jBZ6KbTXmhhCcw9QDik8O8Q=; b=vVVIvluZHWArWsp+wCYAGSogFQ DXxGgEKx3daxNQDFWB/b135z2/7j+7nA1TXJpQRH8wABR4tC3I4FeM0Onsp5h7JReshmpZh3x1PF0 zsu8AKdkgyPyhBujsRKlOJ6QCmdZXUfEG8fvIf0I5ef6BZ+0bYjYqV4TSScDpA1yaB64=; Date: Wed, 23 Sep 2026 12:37:31 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Julian Vetter Subject: Re: [PATCH 2/6] x86/pass-through: no locking around pt_irq_{create,destroy}_bind() Message-ID: References: <92b0a72a-44df-424f-acbe-58d7167f1c4d@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <92b0a72a-44df-424f-acbe-58d7167f1c4d@suse.com> On Tue, Sep 08, 2026 at 03:01:51PM +0200, Jan Beulich wrote: > The questionable use of pcidevs_lock() there was discussed more than once. > It really is pointless: The functions synchronize primarily via the per- > domain event lock. They also may already be called with the global PCI > devices lock not held: See hvm/vmsi.c:vpci_msi_update(), > hvm/vmsi.c:vpci_msi_arch_update(), and hvm/vmsi.c:vpci_msi_disable(). > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/domctl.c > +++ b/xen/arch/x86/domctl.c > @@ -636,10 +636,7 @@ long arch_do_domctl( > ret = -EPERM; > else if ( is_iommu_enabled(d) ) > { > - pcidevs_lock(); > ret = pt_irq_create_bind(d, bind); > - pcidevs_unlock(); pt_irq_create_bind() might call into msixtbl_pt_register() which requires either the pcidevs_lock() or the per-domain d->pci_lock lock to be taken, which I think is not the case in the context here? Adding such locking aroiund the calls would mimic the vPCI context, where d->pci_lock is also taken while executing the vPCI handlers. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:42:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:42:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430163.1652766 (Exim 4.92) (envelope-from ) id 1x9KQG-00085I-8u; Wed, 23 Sep 2026 10:41:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430163.1652766; Wed, 23 Sep 2026 10:41:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KQG-00085B-3x; Wed, 23 Sep 2026 10:41:56 +0000 Received: by outflank-mailman (input) for mailman id 1430163; Wed, 23 Sep 2026 10:41:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9KQE-000855-IR for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:41:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9KQD-00DLFB-Lj for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:41:53 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3acdb-2eae-0a2a0a5409dd-0a2a450c96f6-44 for ; Wed, 23 Sep 2026 12:41:53 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3acf1-f479-0a2a450c0019-4a7de18c88cf-3 for ; Wed, 23 Sep 2026 12:41:53 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd38e0e5dso9731745e9.2 for ; Wed, 23 Sep 2026 03:41:53 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-488682668dcsm6475478f8f.1.2026.09.23.03.41.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 03:41:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790160113; x=1790764913; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=c9ihzKE0mSlPqtEO5PDjohARwVTe+h90O5WXQ1vjLDo=; b=eocGGaNlAdOeWuWU7/EzgJmYKWmNNB6U6Gl6ZTubOO8fc3Yu+7yBv91HIEnP5H6PvI AmHVadJpMASii2YwRFLvYyW4f8i9G82TyqeJ5iA/7MTJPxJ2d+WM3NnBCnMEbWRLE6Go 3P3qxWuuHyCVxLbGzaaY+mIyFxgh6pR8DYP2MK7mc27EE4zvBCPiuU92je9xNQx7FW6W VFa6iHaqARr4C+4EI0hXsmVorPttZd3gqdhwC0iQ0nlCEhoCibk9VHaM21XpOkTGNq1n RemPXk9j5xSe9m/wuqBlUZKgpYEf83xHvpdfB1PmzwyrBD7NCYZQkn+C2q+N/sGYqGRD dTTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790160113; x=1790764913; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=c9ihzKE0mSlPqtEO5PDjohARwVTe+h90O5WXQ1vjLDo=; b=Qu/S/Ckg5G8FsCQUhxUzpOFiySdkBt25Ir1eeHOXOKTpPg4euW3D1TkDF5wLM1Yft6 Cy8ceBu2GB0Zgmkm75eXZcMnfvdW6nRHmC7XQ+6xyDavx/yfibtv5vVaZaDPjs3XFurR 05j6xmkFiAJclpu98GMy7JKQvv5adAFCFYgbN6kmjXVmV3zD3uVk96zKjMMT21X2PQLN Wu+bay/C2sic1nQooeKf/l9RjElDxeZqANtxKY6OEnMNOmdzwmyN1WdnHKt8vNmiRaOw YMy7vk8C86YMWmEcKwia/WjBwnCsP2J32YCWNv1zm81dz9U0pE+Ye4K5in74lL1QvGbF Hisw== X-Forwarded-Encrypted: i=1; AKwUvBxSTxVJu+1HsgYd4uej2ib98b9rGF5xyx1XC6ItJI9vDRCqG1YSdxX88V+RwDZWQl6zUD2KNcKXB5k=@lists.xenproject.org X-Gm-Message-State: AFuF++l5m2ZFiypJpsHjfb8iKebTkVrJqiNwixgXpF5XoYHt6whVnjz8 2czHY78ZmfBle6TODxCed7MiSnL2vmlI513YJ1VM54cnNgXG6BgfTiMH X-Gm-Gg: AYBFou2qP3lPLcuULp8yPKMZKvTopbIvRfdQl5/KQAt4fuDZzenegdcnab7Uk+qB6fK sKJLv/wbkq+ijaJroqHXYk/NhBe/qokK2o0Muf/QCrmk2gKQQMefadMtCZkfnmlwxMTDSwSUixP z6UUHKsaMWwkTVvy6C+orse4sxvOg48h32hqu75tghI7klU3wbqpTQsjvCmKWsW6azvcou6wAqE Bu+QSeV95rsTZ+0TgJcwtDm3xC1ZY5yNAAaPoBYEUOdlO2hT7q6rE6DU32GWCUeoLZYZP4xoYYX sKE67h9w3kAVNQrGl0b9gdxyh1gX84E6HplxmT5y4rVWXYCYHwifk0hyuHD1kKSyYRCx+ukYWH2 9sBGHSJVAZ/2TIk4YmVLEbg74S8cCfMIBwElktDStBqFGL5P97vKeWMpv1nnxXE6kqVKKwrdDSS B71L5IZJrogKDGn48ZNnLuob8gGDQDyyJscLeAUZ6NLqO5wgBr8qc02NYC2laNaYxUdrIFtF0eX fXB9CgSrh4bWMjNUHAflR4YHD0vFNrkBYN8dXLm9FuQUoU4ug== X-Received: by 2002:a05:600c:8b21:b0:49c:f512:2361 with SMTP id 5b1f17b1804b1-49fdf1087edmr28780185e9.14.1790160112776; Wed, 23 Sep 2026 03:41:52 -0700 (PDT) Message-ID: <1425dafc-9737-4776-aa65-5b0e5635e9f5@gmail.com> Date: Wed, 23 Sep 2026 12:41:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] xen/riscv: fix Svade/Svadu A/D bit handling To: Baptiste Le Duc Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <1789032657.8631fc262581453bbf619ec5b2062170.1a08aa7f23b000c4f3@vates.tech> <1789032897.8631fc262581453bbf619ec5b2062170.1a08aab9d76000c4f3@vates.tech> <1790157982.8631fc262581453bbf619ec5b2062170.1a0cdbb0c1a00072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790157982.8631fc262581453bbf619ec5b2062170.1a0cdbb0c1a00072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790160113-03CD3A5B-5D75B1F1/10/73395122804 X-purgate-type: spam X-purgate-size: 4120 On 9/23/26 12:06 PM, Baptiste Le Duc wrote: > On 2026-09-22 17:29 +0200, Oleksii Kurochko wrote: >> >> >> On 9/10/26 11:34 AM, Baptiste Le Duc wrote: >>> p2m_set_permission() only presets the PTE A/D bits when the Svade extension >>> is present in the device tree. This causes an unhandled page fault when >>> neither Svade nor Svadu is present (the platform's actual behaviour is then >>> unknown), and when both are present in the device tree. >> >> When both are present, RISCV_ISA_EXT_svade is set, so the current code >> does preset the A/D bits and no fault happens. The only broken case is >> when neither extension is present, so shouldn't "both present" be dropped? > Yes i agree, I'll fix that in v3. >> >>> >>> Move the Svade/Svadu resolution out of p2m_set_permission() and into a new >>> riscv_resolve_ad_scheme(), called once from riscv_fill_hwcap(). For each of >>> the four possible Svade/Svadu combinations (inspired by [1]), it decides >>> whether software has to preset the A/D bits and, if so, sets >>> RISCV_ISA_EXT_svade to record that decision: >>> - neither present: assume Svade, since assuming Svade is harmless on real >>> Svadu hardware, while assuming Svadu on real Svade hardware risks an >>> unhandled page fault >>> - only Svade present: assume Svade >>> - only Svadu present: leave A/D management to hardware >>> - both present: Svade wins until Xen supports the SBI FWFT call needed to >>> enable hardware updating of A/D bits, so assume Svade and warn that >>> dropping 'svade' from the DT is the only way to get Svadu. >>> >>> [1] https://lwn.net/Articles/980016/ >>> >>> Fixes: ff14053983b0 ("xen/riscv: Implement p2m_pte_from_mfn() and support PBMT configuration") >>> Assisted-by: Claude:claude-opus-5 >>> Signed-off-by: Baptiste Le Duc >>> --- >>> Changes since v1: >>> - change commit title >>> - expose RISCV_ISA_EXT_svadu so the two extensions can be told apart. >>> - move the Svade/Svadu resolution to a new riscv_resolve_ad_scheme(), >>> called once from riscv_fill_hwcap(). >>> - expose sbi_probe_extension() (was static) to probe for SBI FWFT. >> >> sbi_probe_extension() is already non-static in staging, only the prototype >> is missing. What base is this patch against? >> >>> - stop presetting A/D bits unconditionally in p2m_set_permission(), do it >>> only when Svade is present. >> >> What is the gain from not presetting them? Presetting A/D is correct >> with both Svade and Svadu: with Svadu it just saves the hardware an >> atomic PTE update on first access. Xen doesn't consume G-stage A/D bits >> (no dirty tracking, no demand paging), and pt.c already presets A/D >> unconditionally for Xen's own mappings. Always setting PTE_ACCESSED | >> PTE_DIRTY in p2m_set_permission() fixes the bug in one line, with no >> need for the resolver, the new ISA bit, FWFT probing or the ASSERT. >> Handling A/D differently only makes sense once Xen actually wants that >> information, and at that point FWFT support and a fault handler are >> needed anyway. > I agree that presetting them is the right way, it is also the way linux > is working. If Jan agree, I will to in that way in v3. > > Then, it seems there is no need to register Svade/Svadu at all in > cpufeature.c, am I right? If after the re-work we won't need any case of code where it is needed to call riscv_isa_extension_available(NULL, RISCV_ISA_EXT_{svadu,svade}) then it seems like we won't need it in cpufeature.c, at least, in terms of the current patch. (but also consider my another reply in a separate thread if final solution will end that we will force a user to explicitly tell that a user has to write Svade or Svadu in DTS then likely we will need to have correspondent arrays in cpufeature.c and emum updated). Probably, we will need to have them mentioned in correspondent arrays in cpufeature.c if we want to implicitly tell for example that guest is supporting Svadu or Svade. But I think it isn't the case for the current patch. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 23 10:57:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 10:57:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430180.1652773 (Exim 4.92) (envelope-from ) id 1x9KfD-0001VY-EL; Wed, 23 Sep 2026 10:57:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430180.1652773; Wed, 23 Sep 2026 10:57:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KfD-0001VR-BU; Wed, 23 Sep 2026 10:57:23 +0000 Received: by outflank-mailman (input) for mailman id 1430180; Wed, 23 Sep 2026 10:57:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9KfB-0001VL-FP for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:57:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9KfA-001omP-NK for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:57:20 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3b075-2eae-0a2a0a5409dd-0a2a4502d718-44 for ; Wed, 23 Sep 2026 12:57:20 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3b090-6ca4-0a2a45020019-4a7de14cc78a-3 for ; Wed, 23 Sep 2026 12:57:20 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485b1d2874aso655013f8f.1 for ; Wed, 23 Sep 2026 03:57:20 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-488682668e7sm7256281f8f.4.2026.09.23.03.57.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 03:57:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790161040; x=1790765840; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=8bx2uWKvoOnVG2P2VE9YzHLiiwahiHPtwCvtIv7FPns=; b=dXxLNE7qrvTCR7RonGpl0N/Y84Gpi15nkSBElsEA7CSY92qw+eJRhnyFGdSKUTmIiz 3wFEqnIfu3HJB5/opXendnFfl6nFJyQHH2xZK/nkHZZL/mE4pY4iSeoEli00G7dQ9fx4 NvtmzcNMCi4BfQI7rSb16eD6YUHf21B8n4mhAXW0rNPSon4MDD47t/kNwNIH1KsYwDi+ WrZ7gkQnVUWiL6Ry43rk2uQC+/kpfDv2ntNaQYOST/pWCGHJxTNU6YtheJmfRIEU26eB KsM/e9jx7DdIRxqBrAJ1uloZBGXkvdGvrT+LmWaEO73cgNwzSrfouQaJLNhF5Lo6Jz6e 6Fyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790161040; x=1790765840; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=8bx2uWKvoOnVG2P2VE9YzHLiiwahiHPtwCvtIv7FPns=; b=Z9rt8SJle59DAOE3NoWX1ZULXr/3kOsbIUkZBjqxj35yJW5US27lsSfKZj8c+YAtsI XjnMWoxRdibMoIBYVHFV1rqVHDy9GXOdy39Ae8DQyw6L/7V5KxFuE3zyYRWi9GuUO6U3 JkmoJcXQsj91nRaKHaM/xP8uJOAXjALoYFUyIxrPigyAVA7WsjYDEEIMHOvTlLjy/vBh 58y4RqUJ2pK7B+EP7rQrJ0M1jWhs3pfrhejByzKm9PEpwh1IzYs8lF6eQbIvZJbhKv72 /ErtL+rWxMcb7cuLDwM8YwiDnxXqxGKxwbYtY1wVJHBpW8PkSOcxjBNl36dq47juUAu2 CDYA== X-Gm-Message-State: AFuF++lVwWA2IxuSEhRA2CsLagageiPWvLDXZ+6T6mKZDVbfGlU8P5Hh 1qfqZ4TyX7143wzR1GBl1tnQ2+2gcC9oGH2jJTli0Q2gKw89+hscBewD X-Gm-Gg: AYBFou1zi4cfd3sMsoadrpuEFwUMXd8LPUBnOW8rK0RV3JTGXq6/ict0vmk+PLLqRvb Ce+dZsAYZiHLMEhyG0JIjuO8biZcdMqDno+gkG8ELsZ3BRR8+sIHJ/4NlsREIOhmaSBI+Ct1OFi ldbq9MBqzhQ8pl6YhSMf8KRHijZ5gLJrlHJzF1W88lZBeucnDnUY2Hy/UK6+BmFp/Cq8xCH6cXi 9K9j975jQsJvQXG4GDPudOyA0l3nfkx+NVSRCKrJJ6vmttx+iDMoBY1DCVtk5QoYkV/Lad9geW+ gb+lf0FDSjkvh/m6gSsOD1Ss1AkynxBIX3A4h/JWhZJXmwBRI2GCowR+uhTSp+bsbQV7X8B0H0o mL/amXjS8VR9paJDT0ZIXXNgG3r1Ra93UNBmlTtqPpoBm2bp6U2P83ayDb2sUcfGHnk+nYbWm9g 15ukwEIe/cjxmThpo/1LBB4ueyn0rAEmw//XbNU8EihL7eQ7Ag3c7SikOPFWPlSCXD28SCviHD7 cZBtufbm1D5DmGEqAd1zdKbgEPwcLQjeK/vW2ljQf/YElkg8nwsAEwJYIUG X-Received: by 2002:a05:6000:26c7:b0:484:3314:eff6 with SMTP id ffacd0b85a97d-488670906bcmr3492908f8f.28.1790161040079; Wed, 23 Sep 2026 03:57:20 -0700 (PDT) Message-ID: <1cf983c9-456b-4137-b302-e60a0f5ed057@gmail.com> Date: Wed, 23 Sep 2026 12:57:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration From: Oleksii Kurochko To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> <1790096435.8631fc262581453bbf619ec5b2062170.1a0ca0fea6500072c4@vates.tech> <6da5569d-8ae8-4388-a407-00b5d2a4bc27@gmail.com> Content-Language: en-US In-Reply-To: <6da5569d-8ae8-4388-a407-00b5d2a4bc27@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790161040-307C22AC-A447E1E8/10/73395122804 X-purgate-type: spam X-purgate-size: 4347 On 9/22/26 8:48 PM, Oleksii Kurochko wrote: > > > On 9/22/26 7:00 PM, Baptiste Le Duc wrote: >>> During migration of a virtual hart to a different guest interrupt file, >>> straggler MSIs from the APLIC could arrive at the old interrupt file >>> after the switch. >>> >>> genmsi is used despite not supporting guest interrupt files because the >>> AIA spec guarantees that all MSIs previously sent from the APLIC to the >>> same hart are visible at the hart's IMSIC before the extempore MSI from >>> genmsi becomes visible. >> >> >>> >>> Signed-off-by: Oleksii Kurochko >>> >>> diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c >>> index 0af13f28e4..cb11d6aeaa 100644 >>> --- a/xen/arch/riscv/aplic.c >>> +++ b/xen/arch/riscv/aplic.c >>> @@ -27,7 +27,9 @@ >>>   #include >>>   #include >>>   #include >>> +#include >>>   #include >>> +#include >>>   static struct aplic_priv aplic = { >>>       .lock = SPIN_LOCK_UNLOCKED, >>> @@ -205,6 +207,30 @@ void aplic_hw_write_reg(unsigned int offset, >>> uint32_t value) >>>       spin_unlock_irqrestore(&aplic.lock, flags); >>>   } >>> +/* >>> + * As needed, synchronize with all IOMMUs and APLICs to ensure that no >>> + * straggler MSIs will arrive at the old interrupt file after this >>> step. >>> + */ >>> +void aplic_genmsi_barrier(void) >>> +{ >>> +    const struct imsic_config *imsic = imsic_get_config(); >>> +    unsigned int cpu = smp_processor_id(); >>> +    unsigned long flags; >>> +    uint32_t val; >>> + >>> +    val = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | >>> +          (imsic->sync_id & APLIC_TARGET_EIID); >> >> >>> + >>> +    spin_lock_irqsave(&aplic.lock, flags); >>> + >>> +    writel(val, &aplic.regs->genmsi); >>> + >>> +    while ( readl(&aplic.regs->genmsi) & APLIC_GENMSI_BUSY ) >>> +        cpu_relax(); >>> + >>> +    spin_unlock_irqrestore(&aplic.lock, flags); >>> +} >>> + >> According to AIA spec §4.9.3 (Synchronizing interactions between a >> hart and the APLIC), the sequence needs 6 steps; this implements only >> steps 2-5: >> >> - Step 1: clear the pending bit for sync_id at the hart's IMSIC before >> writing genmsi. >> - Step 6: after releasing the lock, poll the pending bit for sync_id >> at the hart's IMSIC until it's set. >> >> Step 4 (Busy clear) only means the APLIC has accepted/sent the MSI, >> not that it has arrived at the hart (the spec notes an unspecified >> travel delay). >> Without step 6, aplic_genmsi_barrier() returns before the MSI (and >> thus prior MSIs) actually reach the hart, so it doesn't achieve the >> barrier it's meant to >> provide. >> > > It is really missed but it exists in riscv-next-upstream branch > (https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next- > upstreaming/xen/arch/riscv/imsic.c#L723). > > I will re-check why it is missed here. Step 1 and step 6 are not missing, they are just not part of aplic_genmsi_barrier() itself. They are done by its caller, which is added in "xen/riscv: remap interrupts to new IMSIC VS-file": static void cf_check imsic_aplic_sync(void *unused) { imsic_local_eix_update(imsic_cfg.sync_id, 1, true, false); aplic_genmsi_barrier(); while ( !imsic_local_is_pending(imsic_cfg.sync_id) ) cpu_relax(); } I did consider doing all six steps inside aplic_genmsi_barrier(), but that would make aplic.c reach into IMSIC internals (the local EIx CSR accessors, which are private to imsic.c), and I would rather not add that dependency. Keeping the APLIC half (write genmsi, wait for Busy to clear) in aplic.c and the IMSIC half (clear the pending bit of sync_id before, poll it until set afterwards) in imsic.c keeps the layering clean. You are right, though, that nothing in this patch says so, and that the helper on its own is not the full barrier its name suggests. I will spell the split out in the commit message and in the comment above the function. Probably it will be better to introduce function imsic_aplic_sync() as a part of this patch. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 23 11:16:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 11:16:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430213.1652783 (Exim 4.92) (envelope-from ) id 1x9Ky3-0004eW-Uv; Wed, 23 Sep 2026 11:16:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430213.1652783; Wed, 23 Sep 2026 11:16:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Ky3-0004eP-SI; Wed, 23 Sep 2026 11:16:51 +0000 Received: by outflank-mailman (input) for mailman id 1430213; Wed, 23 Sep 2026 11:16:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Ky3-0004eJ-6y for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:16:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Ky2-007XID-1t for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:16:50 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3b51b-2eae-0a2a0a5409dd-0a2a450bae00-6 for ; Wed, 23 Sep 2026 13:16:49 +0200 Received: from [52.101.48.8] (helo=MW6PR02CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3b520-b7e8-0a2a450b0019-346530082af8-3 for ; Wed, 23 Sep 2026 13:16:49 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CY3PR03MB8152.namprd03.prod.outlook.com (2603:10b6:930:100::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 11:16:46 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 11:16:46 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ko156pzfNLv/coan9zKcYFk7a+dOlodbFjsWaFwDjIgBthz615Brrb8GqgJU07a25u67m3nToYFm8LAkALVcg4XIxwVjRPs1rJcnHShKDXtAMs2Efr7IDRmICHaQyH5F8LJBMNUvhVHOXMongqcKYLLp4nQlgDFWj8QbURsBG9vb/qZNaK5r4FeDNEXud1Xk1ORUb6QdvoOSdUjbhspaWWIlLiLkUmyhph9ykk6hvqBQLohN7hSHdBofGYBUNIUzUeQY5WW63OopBaqLwyVl/qvtbX1SwzqyyoxSnca9axi6c0XUoikOBxuuFOPWq0+kW5O8o7PuSkXy5hy9iDZlNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QxfeYVCK/ABHBpdU2TQPFB2PkdQGMgpkvrmStIswxk8=; b=Yf4VzTFJkxZWF8Zj2V3RlrARUJy51Xh3MjmYxc/ew7+Lr0CjynI9cvnUqeEpFFSpZzbBIAzE3HK/4ref9Csq6H93f5MsmZfaPsmHw799MU0mlq/djuJ1gzzJnJtgbwITDt+NN6J3dYLib4jgPXHrAix0Zs5JzIYswsEXkcc9Yf+5Qp0Bak3UJaELvFdBSWPmrKmTiVtj23R0HK55/TN+CJMTpfn5GN6MtFt53JnWFNfQweatq9PildM0FhEz5DAkQajrGh6LEJFtrM+bwPef4WGdSo35yvSv+vWKyAXV7mvkmLzyWJ8GIxsBxXj9+AsvtQdP1MOL6AK61QbbcpMDZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QxfeYVCK/ABHBpdU2TQPFB2PkdQGMgpkvrmStIswxk8=; b=TVyANupYmlotxXcwXgf37oUDOg0McuGrcmnQzSNnbAeNIwcyXVdlDtHC+5WuUBDA0TCqZzX5MXreG1v+v20GYRCfMm3HtM3AfMEmmlJdjj0HjOCgWirgj3IrRvtvDCiCZKF8xCquhuYnCS711B/aGiFW42zC3dTu7hVwpOS3kt4= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <38c41bfb-48c6-4408-8da1-2b7d730a6c9e@citrix.com> Date: Wed, 23 Sep 2026 12:16:41 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Save L2's CR4 on #VMEXIT, not Xen's To: Lin Liu , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie References: Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0071.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2af::13) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|CY3PR03MB8152:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d7fca29-1c82-4df3-6a72-08df196427df X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|56012099006|11063799006|10067099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: N4OMWksP/6Ngg54e6v18okY2MN1iPAHEFJ+mPsQB/ESdfBHlepqFTt7V27tMO+MKIxBM99peC7C5ERFyPJHeBom8Gs9Y1mUbxHBm80wLim/+KyUDJyGoLUZ4n004Ng1IuAf7vo1mg1O35Ww3yg/Ul5wsTK5ftmqAL7LorW5Zd2rf9DHU2aJFmu9NFHZGHCZQ8OarG/XYPHRYjmJpsmSh6OB0mf0AprYXbTsR8dEA9Ot6BsSq5jbmqlqpwLPHX9Ph2LEaMGkHkKvgNsKKbkaYlULOhaUIrGqusKMPTsRrxARWyRK4D9xUytaOEO0CoMJgWMYJnN8ma32EHtDA4EsWXwe+aeZAbE2NOq+Q/LsF/mxmyBi1cROjwqEbnsqRCYnuiROBp22KldFplX0E/IHWmbwcymEnbQnt7Hq+LBGM4aZYI88uNLBK4icN5cXps5QiaDRB01t14c6F3Tx5sEjWMSk4hUK1yJCcx1Mywpl1vEKb/K2dDcV+d/zfLvwLEBLxYgBPk1ubhAuXbkbet0giTNaK9ONXeatsu//d0gz9QfkbCJ4ty2sdn65zudaITur4qZNobMZFY4fQbL9vYJvI73WLxUWTb9x6OXdzvrCzDsGGA5k8926s9BR/LTFUAvYhOcg902vasLGSmsLEk8biF89BCMOTxMkmsrEBd8tJDIQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(56012099006)(11063799006)(10067099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S0lyRVdSam85REFGaEJCaUJIWTJ1OUFWWW1sY2lLd3JlMGN0c1cyTUtnRTN0?= =?utf-8?B?QUdqZWZlakdDYnZBTWxSOWJTNTRGVVFUM2VvNUxUREVuVTZOa1ZGalNUdW9t?= =?utf-8?B?WGRsMDFmTEtLNFB5S2U2NXozM29UTkkrcW1Ham9nN0l0dTJhUHQzY05wQUNC?= =?utf-8?B?TUFpcE9XL2FNVkpzRVVLMlh4MnZ2ank5TUNRcWRHVXFJMHFvL0ROUXUrZjhG?= =?utf-8?B?UWRTa2hjR0psOGpZKzZSQmNId1V5RDd0SjZZc21mR1luSEJYZzVvWGpCd1Vt?= =?utf-8?B?Uzlsc2ZGZVJZcWRuT2F6cEhRYWdNTzE0MHdiaUkxYWVFd2owUllTYmtSRy9l?= =?utf-8?B?bXJHNU9oQlVuMHRhbUV4bTNKd3NhaWEzdEVjVFB3aWVXMmxONFl3YmVHYWY5?= =?utf-8?B?QkdOREVSeDVTMUlHQ0NVZy8yQTl0U01nYVA0NFpJdFdEZjYybGF2b05QK2Yz?= =?utf-8?B?dHVzZGd4RXArTTBaQ1JKeXdLTGtEN0gyV2E4UE1ZZmhlWVI4a2RldlZWYWsw?= =?utf-8?B?WTlUamJQQU1wbVRsT3U2eFV4MmVTQUZKYmJMS3BVLzkxMU5DT2pYQ2lIMGV5?= =?utf-8?B?bzdXYzR3Mi90ZnZFNjZvbHQ2VFIrOXZxNitsR0JOWEprbVZWY0hUUnFLZ0wr?= =?utf-8?B?c3FCY2pjbE42SnNOcHlNWWFPZE4xaHMrK1UyVkgzaUE3aElMeWIvUno3azlK?= =?utf-8?B?ZDlKSWdibjVrcFRrME8yMnJ1ejR3SDVvUms2ajlLdlM4bEhlMEZXMk5SUmls?= =?utf-8?B?NGx1L3c4UU45b1FzV0MwR2s0VkhJWWoyL2JRT2EwVHFXWUt4MkRYMjdreTVB?= =?utf-8?B?d05wcWZWdC9JNWpoM2kwdlRpeEZkbG5VVXdtWldkVGhKUHdvdUk1aHBBTER2?= =?utf-8?B?TDhVQ1VKQlVpRUJZN2FPckROSW9xbzgxdzlDL1ZrRDBqS0NiR01Zd1lnZ3NM?= =?utf-8?B?VE5WRkZxZS9vSXlsa3M2bEtWdDdIOEo0WkVMUWtjNTBxUG5YbTg1azlBdDJ2?= =?utf-8?B?SitVQ3cwdmxXSEpDZXRnV2owSmNrWkJUTG9mZFpYMTd2alJwV09GeTVHS3JX?= =?utf-8?B?OStlZzhWTis4aTJTVjJxWWlHazV3QlBRNkRKVmIwMnRxOXpnM1N5S2phbnlw?= =?utf-8?B?VGllYjlCRFI2anB1TWVPRnVsZyt5a3k5WkFIOVNiYkJrMFJNSlYvakh1UXF1?= =?utf-8?B?WUxabzdhcVVtWEpsYmE4QXVwdU1sSXN5bFViU0VrZkpuMGhNTncwaXA3MDNJ?= =?utf-8?B?QjAwRHpOT1VZQWljZHM1SzRxem5KWEoxNUdPRnNlWmNuQzhBa25sdHk0a0w0?= =?utf-8?B?UEdsODkxaDdwcTM0ZGQxZjl1cW1DWjNIK04zWnB1aWxTd1poZDBYeUJmeHNt?= =?utf-8?B?aVRCdUlpT2FWQlc4VzBuQmhCUmhpM1JpRG1SNHNyTnNtR2xwNmxwMFJEelpB?= =?utf-8?B?RGxwUDlUMEQ2OGh5ZXFLNWd5RUtVRzVMcDRUMXZZVkhKbThvNkQraVlUcjA1?= =?utf-8?B?dmhRSG93YkF1a3NPaW8zZjVyZlIxdlpUdTRKS2JVcEpxa1RYNXRvTFppd1lB?= =?utf-8?B?UEdub2dFcWFKVGhKS1N0Y2NaMW9kMlpTVWliczhERUp6TkcxRVhZSlBTbXBG?= =?utf-8?B?Y0ZJQVQ0TXZ4dUdvb3RlMHQ1QVFvQis3aVVnK2FpbGtnQ1RuRVVCQXd2eXlj?= =?utf-8?B?YWhDSlkzU3hxNWEyOUpDMW5Bd1RKbHNrMFA4S3BDNldGcXlhaGpMWnpqZFFC?= =?utf-8?B?VldTNmtWTWx1UllQT1hhUHh2WGZ0MmM5RzVWZ1pQdWhGVHJkNG12QU92bUc4?= =?utf-8?B?aktucGRhMk1EMFhka0ZLWjdLSTNKelg5dDh1TVRna1dNUzZIZUYyeFVFdWFF?= =?utf-8?B?VlFwOFRna0dFTXdoOG9pVHZ2VHRudGxhNmtwb243SVFIOEhEQ3RScVlVWHlH?= =?utf-8?B?U3ZxU0FkUHl6emhRWXBYSnBONkJ0bk85aFV5c2pJVkpoVDlDaU8rR0h5K0M5?= =?utf-8?B?ajBmUjJITyttbUZtcXFCRUd1ajJqZ0JramVYTVVZeVloejFvY2k0cmN3c2dq?= =?utf-8?B?Rmh5TmZQaDNPZ0VHdDRGTGRlSVFGQTNJUVdFTmVqNTJzSU1qZUhZbzM1aTVS?= =?utf-8?B?dVllV0hta3R2cjBtMTNvUnNvUHhaaEFxekl4dGM5emtMMkQ5V0xGNjJ3bU9l?= =?utf-8?B?S0cyRGkxL0NIUHo5UlBydzFXMHBxVURIeTlkRkNhRTNmU3hOQ3psRjExUDU5?= =?utf-8?B?Q3V5WFVhaXFnWDhyaWhNZE5FK3RZQmFRUTNQK2dlR0dOemRDeGlkcnBZSE40?= =?utf-8?B?akNrRGwwUXYvNWpoQkFKQ0t2dXBaUnQ2ZGtndU0yL003RW1NMERaMml3eXRM?= =?utf-8?Q?dA8kVG7cMo2lcR8o=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d7fca29-1c82-4df3-6a72-08df196427df X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 11:16:46.8112 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: q2FSVhW96QwrXn2KvYKD32ug2BwkmbHEjnxFP6Wf+BCwtxBPh0Bq6A19Iy3OkZj4y2z4Lcz/hgBkpLkSaidwatjMUs59J8jwqiurgddHkxg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR03MB8152 X-purgate-ID: tlsNG-42698a/1790162209-1B4D39EA-A6FACC28/0/0 X-purgate-type: clean X-purgate-size: 1653 On 9/23/26 10:51 AM, Lin Liu wrote: > Xen leaks the host's CR4 bits to L1. > > nsvm_vmcb_prepare4vmrun() constructs the shadow VMCB's CR4 via > hvm_set_cr4(), and svm_update_guest_cr() ORs in HVM_CR4_HOST_MASK. > nsvm_vmcb_prepare4vmexit() then copies CR4 back out of the shadow VMCB > instead of the value kept in v->arch.hvm.guest_cr[4], so L1 reads back > Xen's bits - under HAP, CR4.MCE. > > Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Lin Liu > --- > xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c > index a8b15d6eae..8d99b0affc 100644 > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -1082,7 +1082,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > ns_vmcb->_efer = n2vmcb->_efer; > > /* CRn */ > - ns_vmcb->_cr4 = n2vmcb->_cr4; > + ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4]; > ns_vmcb->_cr0 = n2vmcb->_cr0; > > /* DRn */ Reviewed-by: Ross Lagerwall Did you consider addressing similar issues with the other state copied from n2vmcb as well? i.e. I think something similar would apply to CR0, EFER, etc. As an aside, it is confusing that the same CR value also appears in v->arch.hvm.nvcpu.guest_cr[4]. The SVM code doesn't seem to use it and I haven't checked why the VMX code needs it. Perhaps something to clean up in future. Ross From xen-devel-bounces@lists.xenproject.org Wed Sep 23 11:54:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 11:54:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430243.1652792 (Exim 4.92) (envelope-from ) id 1x9LYH-0001h2-L4; Wed, 23 Sep 2026 11:54:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430243.1652792; Wed, 23 Sep 2026 11:54:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9LYH-0001gv-Hq; Wed, 23 Sep 2026 11:54:17 +0000 Received: by outflank-mailman (input) for mailman id 1430243; Wed, 23 Sep 2026 11:54:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9LYG-0001gk-6A for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 11:54:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9LYF-007f0b-J9 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:54:15 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3bde3-bab6-0a2a0a5309dd-0a2a4507ab8c-28 for ; Wed, 23 Sep 2026 13:54:15 +0200 Received: from [148.163.158.5] (helo=mx0b-001b2d01.pphosted.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3bde5-b4ea-0a2a45070019-94a39e059ce6-3 for ; Wed, 23 Sep 2026 13:54:14 +0200 Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68N8ZaCq2742039; Wed, 23 Sep 2026 11:52:49 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gske1jk3y-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 23 Sep 2026 11:52:49 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.18.1.11/8.18.1.11) with ESMTP id 68N8ILmd2892101; Wed, 23 Sep 2026 11:52:48 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4gu5bkgqma-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2026 11:52:48 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 68NBqkcL49086914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Sep 2026 11:52:46 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4C3D920043; Wed, 23 Sep 2026 11:52:46 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F30620040; Wed, 23 Sep 2026 11:52:45 +0000 (GMT) Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown [9.224.92.206]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS; Wed, 23 Sep 2026 11:52:45 +0000 (GMT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=DZPR253R3+bl6LyBiXW5gQAtjY6DOY 80tr7PJYJoSn0=; b=Ip/9PsmLLpYTUEIiqqN7PEUCjt/tbos3gbllDcLV+dKinE DxM4vzFM1FgDLuHauy7zkOFHkE+8QgTu4v3UOwe3wRUssGJANSTjHJOqGP138G+T Nhqd4UMt93hU/7hAzMP4DnDStV7v3lAJgOZvyhZ0P+hcH1+UYg4pIU0KHQpm5t+5 XYQiGLs519bydF3F3Ly2mUsQkpmeIheUS2Amsu7SuvxdJgo6dsqyP4V/N6M8uPwo Yuml8Vro5Oj2/R/nPk2G/xRZFMnqki/FTHYZUvTsblhV4A+Kj49Gi5gWyBTzSy/p hvCA8ghvjVyo99no8eYyGLGNv+3L5xoksFaAmS9Q== Date: Wed, 23 Sep 2026 13:52:44 +0200 From: Alexander Gordeev To: Muhammad Usama Anjum Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: Re: [PATCH v2 1/8] mm: introduce hw_pte_t for PTE table storage Message-ID: <4fb9f42e-73c3-46db-ac10-351a90901b7c-agordeev@linux.ibm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> <20260903103002.1091859-2-usama.anjum@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260903103002.1091859-2-usama.anjum@arm.com> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: zkg8Yjm8buhyt1eRNhnorvj4h8bfMg31 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTIzMDA0NiBTYWx0ZWRfX6bMVOEi2qN4e SEAEWElqPuFcMqb6XxMSAKgTBU7nj/dCzT7pboAwFXABTdsicPgdnhSpodFJ6O+u2hg509qHfDk z9HbX8YO6UJxXAtAPBr1SXV/yRHUshBZqtP38jfDABopi2Q8TlICK2s09kBGBV4exDZexYbukEp Oxg7zWWj4bwJEOGzokpvAGkgwx6mOV9Hci2samlSyJVgEXMEqtoph/gVCurHxiAAqf0TauaVInd IvHSuwss6TAgfLNFvMkfvgEfm/lWIxq4QqGWZb1wZGJTR0i8Aqwb5xGBOLcMv/lOTIYdxzI8o3R oPxWzTJkmoTyuCze3ranpvgoRtO0j9Fwo13juJtO4WWD8YTP1C0PjcAbhZUntKNvoYTNnIcU/mO iX0G+Pezy0wbnkBvSeLA9ii/P51EkQzABCycAD2yGmiU5zm9dKM8qjIMLGZaPS8vA+24yUC1vPk rGMSqvFG6FK+7tXalcw== X-Authority-Analysis: v=2.4 cv=O/KsLx9W c=1 sm=1 tr=0 ts=6ab3bd91 cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=kj9zAlcOel0A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=7CQSdrXTAAAA:8 a=WBsaCDucxrlOMaPtzzAA:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTIzMDA0NiBTYWx0ZWRfX/Y5nhDG4vyXY k03GeTaIqKwMRq4AUpoHFMiSiGlDWAE+orQ24P6M5Bz7btA5rwd/KAwZVyCP0QeAkoFRkdQm8Rw gOzyts+JEL8Z8Grz2VhIOfiIo2KdxD0= X-Proofpoint-GUID: zkg8Yjm8buhyt1eRNhnorvj4h8bfMg31 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-23_04,2026-09-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 malwarescore=0 phishscore=0 impostorscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609230046 X-purgate-ID: tlsNG-ef75cf/1790164455-34AC8AE4-AF1E4327/0/0 X-purgate-type: clean X-purgate-size: 3435 On Thu, Sep 03, 2026 at 11:29:53AM +0100, Muhammad Usama Anjum wrote: > pte_t is used both for software PTE values and for entries stored in a PTE > table, so pte_t * does not distinguish a pointer to a software PTE > value from a pointer to table storage. > > Introduce hw_pte_t as the generic name for a PTE table element. Define it > as a macro alias of pte_t by default. When an architecture selects > ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead. > This preserves the representation while allowing converted architectures > to enforce the distinction at compile time. > > Name the generic wrapper structure __hw_pte_t so architectures can > forward-declare it when pgtable_t must be defined before the generic > hw_pte_t typedef is visible. This avoids header-order dependencies. > > Keep the C type definitions behind an __ASSEMBLY__ check because > architecture assembly sources can include this header indirectly. Include > asm/page.h so consumers such as linux/vmalloc.h retain the page definitions > they previously obtained from that header. > > Signed-off-by: Muhammad Usama Anjum > --- > Changes since v1: > - Name the generic wrapper structure __hw_pte_t so architectures can > forward-declare it, and explain why this is required. > - Use software PTE value terminology. > > Changes since RFC v1: > - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition. > - Exclude the C type definitions from assembly sources. > - Update the description for the new opt-in model. > --- > MAINTAINERS | 1 + > include/linux/pgtable_types.h | 17 +++++++++++++++++ > mm/Kconfig | 3 +++ > 3 files changed, 21 insertions(+) > create mode 100644 include/linux/pgtable_types.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2133aec4a2004..da60a8bdcddb5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17140,6 +17140,7 @@ F: include/linux/mmu_notifier.h > F: include/linux/pagewalk.h > F: include/linux/pgalloc.h > F: include/linux/pgtable.h > +F: include/linux/pgtable_types.h > F: include/linux/ptdump.h > F: include/linux/vmpressure.h > F: include/linux/vmstat.h > diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h > new file mode 100644 > index 0000000000000..07da05d375c2c > --- /dev/null > +++ b/include/linux/pgtable_types.h > @@ -0,0 +1,17 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _LINUX_PGTABLE_TYPES_H > +#define _LINUX_PGTABLE_TYPES_H > + > +#include > + > +#ifndef __ASSEMBLY__ > + > +#ifdef CONFIG_ARCH_HAS_HW_PTE_T > +typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t; > +#else > +#define hw_pte_t pte_t > +#endif I would suggest to provide __hw_pte() in this series - it is needed by architectures along with __pte_from_hw() right away (as opposed to when lands in arm64). > +#endif /* !__ASSEMBLY__ */ > + > +#endif /* _LINUX_PGTABLE_TYPES_H */ > diff --git a/mm/Kconfig b/mm/Kconfig > index c1ddf59c0d71a..5f462ec6fa5e5 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1312,6 +1312,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled" > config GUP_GET_PXX_LOW_HIGH > bool > > +config ARCH_HAS_HW_PTE_T > + bool > + > config DMAPOOL_TEST > tristate "Enable a module to run time tests on dma_pool" > depends on HAS_DMA > -- > 2.47.3 > From xen-devel-bounces@lists.xenproject.org Wed Sep 23 12:15:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 12:15:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430278.1652802 (Exim 4.92) (envelope-from ) id 1x9Lsx-0004kr-EJ; Wed, 23 Sep 2026 12:15:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430278.1652802; Wed, 23 Sep 2026 12:15:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Lsx-0004kj-A9; Wed, 23 Sep 2026 12:15:39 +0000 Received: by outflank-mailman (input) for mailman id 1430278; Wed, 23 Sep 2026 12:15:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9Lsv-0004kb-JA for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:15:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Lsu-007jMO-WA for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 14:15:37 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3c2db-e002-0a2a0a5209dd-0a2a4502ab0e-44 for ; Wed, 23 Sep 2026 14:15:36 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3c2e8-6ca4-0a2a45020019-b9ff1c228bf7-3 for ; Wed, 23 Sep 2026 14:15:36 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0ce31488500072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 12:15:31 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 88662821D0; Wed, 23 Sep 2026 14:15:30 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=BXA/xZrK7qbUzj5CdTkyj0eFU/ACd0spVO4w9gv8LDI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=h6QTIxvdof37gUbwo8dn9ZeL5MEDHAE6DkG6dHHCRo4jOjtZ5/STYUOxyABBxJPMOCIPtzwQq SjL1T+mR1RjT14eyFM+/oifhqyI+vf5+Gg8xrtcEZbxj8rgjYkaEgM7WYCbsR5g0CYqX0A5Al5X Yru80pT1QSLdCO6vnjbLV37ZIrX8eIaDug8brh2/ZrCo6QMWAHzSCO+jqKAiIB0a0iIcxMaUh+/ AZwxQhtb3EtPrLp4q1iE5GDFvzsSR6eFY9IOoVFzM80zdPDEvlHnJjoQUP21CjENNX1QXbvcATY dWHO8V1kQs+28WAE7jw1dDOgzl3ZRIJDcSN5p5wg2wsg== X-Zone-Loop: df19d74efeea9eaa38707cb655f52ab688699ea3d9d3 x-campaign-type: default x-transaction-id: 69b697b0-4e47-4f90-ab55-8c08355dbc31 x-swg-uid: 01-1661bd48-ee02-4300-a83e-67d03e7f4fc7 X-Mailer: Sweego Message-ID: <1790165731.8631fc262581453bbf619ec5b2062170.1a0ce31488500072c4@vates.tech> x-swg-bid: 1790165731.8631fc262581453bbf619ec5b2062170.1a0ce31488500072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <1cf983c9-456b-4137-b302-e60a0f5ed057@gmail.com> References: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> <1790096435.8631fc262581453bbf619ec5b2062170.1a0ca0fea6500072c4@vates.tech> <6da5569d-8ae8-4388-a407-00b5d2a4bc27@gmail.com> <1cf983c9-456b-4137-b302-e60a0f5ed057@gmail.com> Date: Wed, 23 Sep 2026 14:15:25 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790165725; l=4819; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=cR4lKVyGqbLaLxXYF/cwm1EWPPEICePCmiVQuJuVqRQ=; b=Q0FtZKLXNb4vPQjNyhGEMJ0LGbQQ5qgNAtVZS7iRFNlmapsf88IsaS65Frs9/Dwvd+OlYxD9O bGP/WVd7HbuBDF3/SqsApxAeFADrAgmWZ7h86HhANESAExu2nKegCpA X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790165730760 X-purgate-ID: tlsNG-720697/1790165736-F34BE2AC-C9FCD9B4/10/73395122804 X-purgate-type: spam X-purgate-size: 4823 On 2026-09-23 12:57 +0200, Oleksii Kurochko wrote: > > > On 9/22/26 8:48 PM, Oleksii Kurochko wrote: > > > > > > On 9/22/26 7:00 PM, Baptiste Le Duc wrote: > >>> During migration of a virtual hart to a different guest interrupt file, > >>> straggler MSIs from the APLIC could arrive at the old interrupt file > >>> after the switch. > >>> > >>> genmsi is used despite not supporting guest interrupt files because the > >>> AIA spec guarantees that all MSIs previously sent from the APLIC to the > >>> same hart are visible at the hart's IMSIC before the extempore MSI from > >>> genmsi becomes visible. > >> > >> > >>> > >>> Signed-off-by: Oleksii Kurochko > >>> > >>> diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c > >>> index 0af13f28e4..cb11d6aeaa 100644 > >>> --- a/xen/arch/riscv/aplic.c > >>> +++ b/xen/arch/riscv/aplic.c > >>> @@ -27,7 +27,9 @@ > >>>   #include > >>>   #include > >>>   #include > >>> +#include > >>>   #include > >>> +#include > >>>   static struct aplic_priv aplic = { > >>>       .lock = SPIN_LOCK_UNLOCKED, > >>> @@ -205,6 +207,30 @@ void aplic_hw_write_reg(unsigned int offset, > >>> uint32_t value) > >>>       spin_unlock_irqrestore(&aplic.lock, flags); > >>>   } > >>> +/* > >>> + * As needed, synchronize with all IOMMUs and APLICs to ensure that no > >>> + * straggler MSIs will arrive at the old interrupt file after this > >>> step. > >>> + */ > >>> +void aplic_genmsi_barrier(void) > >>> +{ > >>> +    const struct imsic_config *imsic = imsic_get_config(); > >>> +    unsigned int cpu = smp_processor_id(); > >>> +    unsigned long flags; > >>> +    uint32_t val; > >>> + > >>> +    val = MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | > >>> +          (imsic->sync_id & APLIC_TARGET_EIID); > >> > >> > >>> + > >>> +    spin_lock_irqsave(&aplic.lock, flags); > >>> + > >>> +    writel(val, &aplic.regs->genmsi); > >>> + > >>> +    while ( readl(&aplic.regs->genmsi) & APLIC_GENMSI_BUSY ) > >>> +        cpu_relax(); > >>> + > >>> +    spin_unlock_irqrestore(&aplic.lock, flags); > >>> +} > >>> + > >> According to AIA spec §4.9.3 (Synchronizing interactions between a > >> hart and the APLIC), the sequence needs 6 steps; this implements only > >> steps 2-5: > >> > >> - Step 1: clear the pending bit for sync_id at the hart's IMSIC before > >> writing genmsi. > >> - Step 6: after releasing the lock, poll the pending bit for sync_id > >> at the hart's IMSIC until it's set. > >> > >> Step 4 (Busy clear) only means the APLIC has accepted/sent the MSI, > >> not that it has arrived at the hart (the spec notes an unspecified > >> travel delay). > >> Without step 6, aplic_genmsi_barrier() returns before the MSI (and > >> thus prior MSIs) actually reach the hart, so it doesn't achieve the > >> barrier it's meant to > >> provide. > >> > > > > It is really missed but it exists in riscv-next-upstream branch > > (https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next- > > upstreaming/xen/arch/riscv/imsic.c#L723). > > > > I will re-check why it is missed here. > > Step 1 and step 6 are not missing, they are just not part of > aplic_genmsi_barrier() itself. They are done by its caller, which is > added in "xen/riscv: remap interrupts to new IMSIC VS-file": > > static void cf_check imsic_aplic_sync(void *unused) > { > imsic_local_eix_update(imsic_cfg.sync_id, 1, true, false); > > aplic_genmsi_barrier(); > > while ( !imsic_local_is_pending(imsic_cfg.sync_id) ) > cpu_relax(); > } > > I did consider doing all six steps inside aplic_genmsi_barrier(), but > that would make aplic.c reach into IMSIC internals (the local EIx CSR > accessors, which are private to imsic.c), and I would rather not add > that dependency. Keeping the APLIC half (write genmsi, wait for Busy to > clear) in aplic.c and the IMSIC half (clear the pending bit of sync_id > before, poll it until set afterwards) in imsic.c keeps the layering clean. > > You are right, though, that nothing in this patch says so, and that the > helper on its own is not the full barrier its name suggests. I will > spell the split out in the commit message and in the comment above the > function. > > Probably it will be better to introduce function imsic_aplic_sync() as a > part of this patch. Yes it would make sense as function imsic_aplic_sync() is introduced in next patch so reviewer couldn't know the existence of it when reading this patch. Thanks for that! > > ~ Oleksii > > > From xen-devel-bounces@lists.xenproject.org Wed Sep 23 12:26:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 12:26:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430307.1652810 (Exim 4.92) (envelope-from ) id 1x9M3N-0006UG-9Z; Wed, 23 Sep 2026 12:26:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430307.1652810; Wed, 23 Sep 2026 12:26:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9M3N-0006U9-6V; Wed, 23 Sep 2026 12:26:25 +0000 Received: by outflank-mailman (input) for mailman id 1430307; Wed, 23 Sep 2026 12:26:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9M3L-0006U3-Cb for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:26:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9M3K-00DfsD-Lz for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 14:26:22 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3c569-8faa-0a2a0a5109dd-0a2a450aa1c8-24 for ; Wed, 23 Sep 2026 14:26:22 +0200 Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3c56c-f2d2-0a2a450a0019-94a39c01ef2c-3 for ; Wed, 23 Sep 2026 14:26:22 +0200 Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68N8ZPkk2906895; Wed, 23 Sep 2026 12:25:42 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gskgsb5ap-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 23 Sep 2026 12:25:42 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.11/8.18.1.11) with ESMTP id 68N95f8S005144; Wed, 23 Sep 2026 12:25:41 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4gvbu8rrf7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2026 12:25:41 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 68NCPd4t38732190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Sep 2026 12:25:39 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EC5CD20065; Wed, 23 Sep 2026 12:25:38 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3B95620043; Wed, 23 Sep 2026 12:25:38 +0000 (GMT) Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown [9.224.92.206]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS; Wed, 23 Sep 2026 12:25:38 +0000 (GMT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=v0X+Rs8szhHkgnuPcIWhAyZce3EkTz TtRBKQqHEj2SY=; b=DymJK7xH6KCGN1aWSDi8yE3JeZCCm0hQdInjvaYZRKitNb sl2yDuJWYD4cPHPK0u4r0N9hStfA3omtniXxpaEHynRZ9NUZdggQ7y4v9nOzT7U9 XpO+PxL7oe/Fbh6/+YhooIKtXBG55sR4NiT2ToMHAWFRENr3oHFXFkwslZyhFWbI 1B334HuWzXx4hpfNYekKa9xlmXk6cYQIBC2BCsfeLJ0OBkoaCBbxWf7H/z4Lv2mB P/Lqle8a9fS6YnXCc6Y1u7OGYFyusCvin01zNALgGbVb6TQ9tmxXkOZ3MjLGdEdC M/ha62xE0Fq3/RrtNVNmohrqAIQ4+aJYTAup8uSA== Date: Wed, 23 Sep 2026 14:25:37 +0200 From: Alexander Gordeev To: Muhammad Usama Anjum Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values Message-ID: <1401e907-04ff-4ee5-ad03-00d88531a091-agordeev@linux.ibm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260903103002.1091859-1-usama.anjum@arm.com> X-TM-AS-GCONF: 00 X-Authority-Analysis: v=2.4 cv=V/XoQuni c=1 sm=1 tr=0 ts=6ab3c546 cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=kj9zAlcOel0A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=VwQbUJbxAAAA:8 a=7CQSdrXTAAAA:8 a=vUGUDSKChvK0ha46Ui4A:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-ORIG-GUID: ev-_JLyQr-pwEqNhXTXIZA7T8jABJbLj X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTIzMDA0OCBTYWx0ZWRfX3jBRFLFxLXRH 41gkMIIRJm9VbqiK2YtOcXDOIZwYjrCdxtSZOW/HeORsfhOxpmJhhPEWSN2wE9YBL2VRhW6O7D2 Qr3To+xxPwlTw7GeQ2a8zIO36T51bHxKzdyp7yFXdKF3rEFGszcZBbYQEl+zv+QLSQa5BvzpNIK C5R4wcWrvwWHRZRXWHAwBTIUpPG8PzVJkpsQifRmwR8LgilnDa74f2xP/hyPClmLnKPerI1e3/s fJyE7zMlic6Rx/76z/RtAMNkCr6xtVVE5VeRNLbRnsmDb4KohBKbvJQ4ax0IiGSsSTYf9dF9DDW Go51ekYyr1d3O9vLChpz5abCQojIKm+DNY8HzWZzpMyAQ8VmaL5ufL6oddQ5mv/Q189e6iBxqs6 q8d6mtePYNjZn9b5/f57l92H+6h3S1U9nREt1LclL5Eqc+yXvnOU5Bwtr8lGfdC+FyC20VRDqr5 yvBcPkksv7DCdMzUVog== X-Proofpoint-Spam-Info: AW1haW4tMjYwOTIzMDA0OCBTYWx0ZWRfX46m1QpM8dmIH lg16GCvD6ONwEeOosozSD2m/9N5Zt+i3zavCwk/jFQmzNEO3Hlv1PgshihWpld67QkuM0YD1grS xDTdsyKVkLQulaYB1Dcv4/OHkUvJzFM= X-Proofpoint-GUID: ev-_JLyQr-pwEqNhXTXIZA7T8jABJbLj X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-23_04,2026-09-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 spamscore=0 malwarescore=0 clxscore=1015 phishscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609230048 X-purgate-ID: tlsNG-4011c0/1790166382-526DECFC-91688456/0/0 X-purgate-type: clean X-purgate-size: 767 On Thu, Sep 03, 2026 at 11:29:52AM +0100, Muhammad Usama Anjum wrote: Hi Muhammad, > I've the patches here [3] for arm64 conversion which I used to find > usages in generic code which I missed during development. These would be > sent separately. > > [1] https://lore.kernel.org/all/6110202c-057b-4701-8c04-1a76ee7bb9ab@arm.com/ > [2] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com > [3] https://gitlab.arm.com/linux-arm/linux-us/-/commits/pte0_arm I checked [3] with s390 and also against our lazy mmu implementation and it looks okay. However, is there a particular reason this series is against mm-new? Should it be against the master, it would be easier for me to try it in our CI. > Thanks, > Usama Thanks! From xen-devel-bounces@lists.xenproject.org Wed Sep 23 12:42:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 12:42:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430330.1652819 (Exim 4.92) (envelope-from ) id 1x9MIw-00013Z-IL; Wed, 23 Sep 2026 12:42:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430330.1652819; Wed, 23 Sep 2026 12:42:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MIw-00013Q-FK; Wed, 23 Sep 2026 12:42:30 +0000 Received: by outflank-mailman (input) for mailman id 1430330; Wed, 23 Sep 2026 12:42:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MIt-00013K-5u for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 12:42:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MIr-007njs-6I for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 14:42:25 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3c91e-e002-0a2a0a5209dd-0a2a4501b06a-46 for ; Wed, 23 Sep 2026 14:42:24 +0200 Received: from [213.97.179.56] (helo=fanzine2.igalia.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3c92e-5984-0a2a45010019-d561b3388ce2-3 for ; Wed, 23 Sep 2026 14:42:23 +0200 Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com) by fanzine2.igalia.com with esmtps (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim) id 1x9MIN-0068Yz-Pt; Wed, 23 Sep 2026 14:41:55 +0200 Received: from webmail.service.igalia.com ([192.168.21.45]) by mail.igalia.com with esmtp (Exim) id 1x9MIL-008BYe-T3; Wed, 23 Sep 2026 14:41:55 +0200 Received: from localhost ([127.0.0.1] helo=webmail.igalia.com) by webmail.service.igalia.com with esmtp (Exim 4.98.2) (envelope-from ) id 1x9MIL-00000003yOG-3zlc; Wed, 23 Sep 2026 14:41:53 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20170329 header.d=igalia.com header.i="@igalia.com" header.h="Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To:From:Date:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:Cc:To :From:Date:MIME-Version:From:Reply-To; bh=g9B2VaeeRiExoRvqu5OhmbVwC5+5bS3UNUKe+fIyEUo=; b=I1KHWuoqWH71gb7QuhhwJvbB7B stuwG2ZQ1gEXCknmr0LlbVOX2Sn92AHnY67LFjl4iy/+q/PAoC4XAOiuqCyiOhZFAVdqyi2xSjR3D CBVRECGZeJ/n6E0w4Uh9sUOTOLGqqr/3Ez5aJx0+1hhC2zl5EuhLOGqz/VM/4WrY83oubYIcfT/RP JkNVY53mWlRS1267DJd7Ii5wQAe32cwT1PxBairv9PkIl7HulU9j/PPaYBlCl2s8DKcxJntNvps04 hSZ3sky0F5+s2o1bX+CsF6E8ovGUdjIcnIWhNL4zm7eD+DZFOObgFdPZpq6dj/Kma7QAR4xks9QHc cDSvavpg==; MIME-Version: 1.0 Date: Wed, 23 Sep 2026 09:41:53 -0300 From: Mauricio Faria de Oliveira To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , Jan Beulich , Brian Gerst , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v10 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN) In-Reply-To: <20260923011232.GBarMngDiylzal41XI@fat_crate.local> References: <20260921-pvh-kasan-inline-v10-0-08da47943d8e@igalia.com> <20260922035815.GFarH819yHRX8WWnG9@fat_crate.local> <3ed7ea3908233ef72660ddfa1f92e914@igalia.com> <20260923011232.GBarMngDiylzal41XI@fat_crate.local> Message-ID: <4d7b03a55ea3d8633828229d3c3c988e@igalia.com> X-Sender: mfo@igalia.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Report: NO, Score=-2.1, Tests=ALL_TRUSTED=-3,BAYES_50=0.8,KAM_DMARC_NONE=0.125,KAM_DMARC_STATUS=0.005 X-Spam-Score: -20 X-Spam-Bar: -- X-purgate-ID: tlsNG-d62444/1790167344-1E07B757-858DF159/0/0 X-purgate-type: clean X-purgate-size: 1322 On 2026-09-22 22:12, Borislav Petkov wrote: > On Tue, Sep 22, 2026 at 07:13:35PM -0300, Mauricio Faria de Oliveira wrote: >> I think that is fine, yes. Even though it's a boot failure, actually >> hitting it depends on all of: CONFIG_KASAN, CONFIG_PVH, booting from the >> PVH entry point, _plus_ a compiler version that triggers it. >> >> Nonetheless, this may be picked up for stable due to the Fixes: tags, >> but I can provide backports as needed. > > Right, just consider all the bandwidth of the folks involved downstream: > stable team and all distros backporting stuff every day. This sounds like an > exotic thing so let's be conservative here pls. Absolutely. I worked for a long time with distro kernels and backporting. I just mentioned that it is possible for this to be picked up, and that if it is, then I can help with it if needed; not pushing. :) >> BTW, I just realized that the title of patch 4/4 is missing memset(). >> Would you mind adding it, please? Or I can send v11. >> -x86/cpuid: fix unbootable VMs by really inlining memcmp() in >> cpuid_base_hypervisor() and xen_prepare_pvh() >> +x86/cpuid: fix unbootable VMs by really inlining memcmp() and memset() >> in cpuid_base_hypervisor() and xen_prepare_pvh() > > Sure, np. Thanks! > > Thx. -- Mauricio From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430379.1652846 (Exim 4.92) (envelope-from ) id 1x9MrG-0005xV-E5; Wed, 23 Sep 2026 13:17:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430379.1652846; Wed, 23 Sep 2026 13:17:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrG-0005vI-6y; Wed, 23 Sep 2026 13:17:58 +0000 Received: by outflank-mailman (input) for mailman id 1430379; Wed, 23 Sep 2026 13:17:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mqa-0005g9-Dm for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:17:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MqZ-006Oq6-Qw for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:17:15 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d157-e002-0a2a0a5209dd-0a2a450ce800-6 for ; Wed, 23 Sep 2026 15:17:15 +0200 Received: from [74.125.229.143] (helo=mail-dl2-f15.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d158-f479-0a2a450c0019-4a7de58f8011-3 for ; Wed, 23 Sep 2026 15:17:14 +0200 Received: by mail-dl2-f15.google.com with SMTP id a92af1059eb24-144f9160b81so326093c88.0 for ; Wed, 23 Sep 2026 06:17:13 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.16.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:17:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169432; x=1790774232; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=yna4uP+Wuvk4Vi5PLJAGcI6TOXtcsNj/VZXgauqzoKs=; b=FmNJZ+Ajglj6XXmpkaqT1KrUL0qzde3LSgO033s5fTplKaxt5hFeNUlYJ59PU0bbFY bZyITYlwlwi16TZvrFxUkAHWNYXKpdQTPRW/2elF6xHenilUlznel8i1ccZU3UqoAsBJ O/XjMFLym7VTHrWdhkWRfA9nBEpLOR5dUDwh13giekCizc5NmQuTC8kbLp9Nw92rqYJN ZstkazRTMIF/xjRWxGwLHEH7kdYSQKZ3U00JYpaga+Fo+jvTduhvCZeJtvaYiNCbiNeq YT5Y3koNZzwlB1DxCdX0Cn6NqvQz93aimM8oe4Bswli3B+NpweSu2OBpV/CYHFebCZFY 8/cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169432; x=1790774232; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=yna4uP+Wuvk4Vi5PLJAGcI6TOXtcsNj/VZXgauqzoKs=; b=vcNYDDvGuycao02jV9Im4X8uH1kKHcz9LZsYR6n3lhomZKrmNlCiDS3GJCARMRfWI8 SEIPP+lIwg5LBo0700YVmwS8gAwi9Un7rHhghw1ZG5r9oDqA2DBjSZRV/GrzVW8Osr0r o+CaC2md7l0CqYp3ZMWyiQLWIAiA7c6N1gNmPmDxucH4QBEKUCoFXS8WyaXFqVECqhXX 808bvTmwe4mZT7aoOMoDAgaB1kiFph3/jQyw6b4fqOIIFJDVsiLoAjhsWsICtSQ8aCeV 82+8CmvRsHo53pO+9EYOmKWKq2U9EIfpQYXzustajud1ZklUrXRPMxZWmrIoGl4ctbjB mTFA== X-Forwarded-Encrypted: i=1; AKwUvBzAztFZY1J521w7c8Un35tSrjXnP6YuLIzai1p3nqfed8OtgWjmf+gF1l0Z4spLF12YXg24xx9A4Ag=@lists.xenproject.org X-Gm-Message-State: AFuF++nvZdkcnnVWkKIzxJJii5c6Nw4xxdtEgIV7JoT0DeVoDR2N0xhb C8PNOXbw72aMNBL7GCW0rR76T19dS/T0SuBXDOxy9Wh+M3gP4pCt9I9+ X-Gm-Gg: AYBFou2BpPYvpro3WGZOxzkqIiaHOLEl232nND8tOVOHA/3OMqDVdb5yAEZiMPrnzqp 7QRRHlK20efUKJlbmtkgU+dNPeqGXK1stK8iPSDJbHlo0ShDFx6pQIm6Mtku6c9QGf6ceQi7KAO sdRq0mMrKwD+yV85JJDbpzte1b4UJ+w7bXpj6OqGSo8G3tLbGHOClPmZb0HiBQ7cDvWddKvUC0u 1YXjbDPHuMl4XYa5e9Z/VXvcVjFMhQwKaKjbLjp6gRMG8x26IWp/UtoPrj91fqIx8I1VKu2n3RW Mzdau3AYD94kwv/AbqQayGlcS+6AV5onvP027PFldYCzkWrGRIHThLSJxSCPO8rAKpyjyvSge5t GW+27JczBhNbZY1gvvVAETGI8qA24IvNpc4Wib38uWxipuvN5i8PGyngyhPBxfHGiTwQBfwqKc1 njIA+7iTWKrLAgq3ZLjqXytAdMmEhfSyIa1bYEtLA7igcDmkChG9rJIl+YT8DMGjJKYSTr111Kp 5zMdILi2hem9zHDxoqWS03ynJ6QDw4= X-Received: by 2002:a05:7022:fa9:b0:143:2973:3240 with SMTP id a92af1059eb24-144f91551e9mr4233625c88.29.1790169427298; Wed, 23 Sep 2026 06:17:07 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 002/114] configs/targets: remove target info definitions Date: Wed, 23 Sep 2026 21:14:36 +0800 Message-ID: <20260923131635.1894-3-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1790169434-012C8A5B-28A12276/0/0 X-purgate-type: clean X-purgate-size: 5620 From: Pierrick Bouvier Now that we remove machine_typename, we don't need to keep duplicated file per target anymore. So we can just rely on target-info-stub.c. Signed-off-by: Pierrick Bouvier Signed-off-by: Yonggang Luo --- configs/targets/aarch64-softmmu.c | 25 ------------------------- configs/targets/arm-softmmu.c | 25 ------------------------- configs/targets/meson.build | 6 ------ configs/targets/riscv32-softmmu.c | 24 ------------------------ configs/targets/riscv64-softmmu.c | 24 ------------------------ meson.build | 7 +------ 6 files changed, 1 insertion(+), 110 deletions(-) delete mode 100644 configs/targets/aarch64-softmmu.c delete mode 100644 configs/targets/arm-softmmu.c delete mode 100644 configs/targets/meson.build delete mode 100644 configs/targets/riscv32-softmmu.c delete mode 100644 configs/targets/riscv64-softmmu.c diff --git a/configs/targets/aarch64-softmmu.c b/configs/targets/aarch64-softmmu.c deleted file mode 100644 index fdebdcc3582..00000000000 --- a/configs/targets/aarch64-softmmu.c +++ /dev/null @@ -1,25 +0,0 @@ -/* - * QEMU binary/target API (qemu-system-aarch64) - * - * Copyright (c) Linaro - * - * SPDX-License-Identifier: GPL-2.0-or-later - */ - -#include "qemu/osdep.h" -#include "qemu/target-info-impl.h" -#include "qemu/target-info-init.h" -#include "target/arm/cpu-qom.h" -#include "target/arm/cpu-param.h" - -static const TargetInfo target_info_aarch64_system = { - .target_name = "aarch64", - .target_arch = SYS_EMU_TARGET_AARCH64, - .long_bits = 64, - .cpu_type = TYPE_ARM_CPU, - .endianness = ENDIAN_MODE_LITTLE, - .page_bits_vary = true, - .page_bits_init = TARGET_PAGE_BITS_LEGACY, -}; - -target_info_init(target_info_aarch64_system) diff --git a/configs/targets/arm-softmmu.c b/configs/targets/arm-softmmu.c deleted file mode 100644 index 2b98f65a0f8..00000000000 --- a/configs/targets/arm-softmmu.c +++ /dev/null @@ -1,25 +0,0 @@ -/* - * QEMU binary/target API (qemu-system-arm) - * - * Copyright (c) Linaro - * - * SPDX-License-Identifier: GPL-2.0-or-later - */ - -#include "qemu/osdep.h" -#include "qemu/target-info-impl.h" -#include "qemu/target-info-init.h" -#include "target/arm/cpu-qom.h" -#include "target/arm/cpu-param.h" - -static const TargetInfo target_info_arm_system = { - .target_name = "arm", - .target_arch = SYS_EMU_TARGET_ARM, - .long_bits = 32, - .cpu_type = TYPE_ARM_CPU, - .endianness = ENDIAN_MODE_LITTLE, - .page_bits_vary = true, - .page_bits_init = TARGET_PAGE_BITS_LEGACY, -}; - -target_info_init(target_info_arm_system) diff --git a/configs/targets/meson.build b/configs/targets/meson.build deleted file mode 100644 index 2ab4d27eaf5..00000000000 --- a/configs/targets/meson.build +++ /dev/null @@ -1,6 +0,0 @@ -foreach target : [ - 'arm-softmmu', 'aarch64-softmmu', - 'riscv32-softmmu', 'riscv64-softmmu' - ] - config_target_info += {target : files(target + '.c')} -endforeach diff --git a/configs/targets/riscv32-softmmu.c b/configs/targets/riscv32-softmmu.c deleted file mode 100644 index 0829ab84de5..00000000000 --- a/configs/targets/riscv32-softmmu.c +++ /dev/null @@ -1,24 +0,0 @@ -/* - * QEMU binary/target API (qemu-system-riscv32) - * - * Copyright (c) rev.ng Labs Srl. - * - * SPDX-License-Identifier: GPL-2.0-or-later - */ - -#include "qemu/osdep.h" -#include "qemu/target-info-impl.h" -#include "qemu/target-info-init.h" -#include "target/riscv/cpu-qom.h" -#include "target/riscv/cpu-param.h" - -static const TargetInfo target_info_riscv32_system = { - .target_name = "riscv32", - .target_arch = SYS_EMU_TARGET_RISCV32, - .long_bits = 32, - .cpu_type = TYPE_RISCV_CPU, - .endianness = ENDIAN_MODE_LITTLE, - .page_bits_init = TARGET_PAGE_BITS, -}; - -target_info_init(target_info_riscv32_system) diff --git a/configs/targets/riscv64-softmmu.c b/configs/targets/riscv64-softmmu.c deleted file mode 100644 index 553bd1f75fe..00000000000 --- a/configs/targets/riscv64-softmmu.c +++ /dev/null @@ -1,24 +0,0 @@ -/* - * QEMU binary/target API (qemu-system-riscv64) - * - * Copyright (c) rev.ng Labs Srl. - * - * SPDX-License-Identifier: GPL-2.0-or-later - */ - -#include "qemu/osdep.h" -#include "qemu/target-info-impl.h" -#include "qemu/target-info-init.h" -#include "target/riscv/cpu-qom.h" -#include "target/riscv/cpu-param.h" - -static const TargetInfo target_info_riscv64_system = { - .target_name = "riscv64", - .target_arch = SYS_EMU_TARGET_RISCV64, - .long_bits = 64, - .cpu_type = TYPE_RISCV_CPU, - .endianness = ENDIAN_MODE_LITTLE, - .page_bits_init = TARGET_PAGE_BITS, -}; - -target_info_init(target_info_riscv64_system) diff --git a/meson.build b/meson.build index f17665c667d..f412d917d94 100644 --- a/meson.build +++ b/meson.build @@ -3754,7 +3754,6 @@ subdir('dump') subdir('accel') subdir('backends') -subdir('configs/targets') subdir('disas') subdir('migration') subdir('monitor') @@ -4331,11 +4330,7 @@ foreach target : target_dirs endif endif - if target in config_target_info - arch_srcs += config_target_info[target] - else - arch_srcs += files('target-info-stub.c') - endif + arch_srcs += files('target-info-stub.c') if target_base_arch in target_arch t = target_arch[target_base_arch].apply(config_target, strict: false) -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430385.1652865 (Exim 4.92) (envelope-from ) id 1x9MrH-0006HJ-DF; Wed, 23 Sep 2026 13:17:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430385.1652865; Wed, 23 Sep 2026 13:17:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrH-0006EK-3v; Wed, 23 Sep 2026 13:17:59 +0000 Received: by outflank-mailman (input) for mailman id 1430385; Wed, 23 Sep 2026 13:17:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mqw-0005hx-Jy for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:17:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mqw-002EU2-0h for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:17:38 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d16a-8faa-0a2a0a5109dd-0a2a4503847a-16 for ; Wed, 23 Sep 2026 15:17:37 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d170-fae8-0a2a45030019-4a7de50c81a9-3 for ; Wed, 23 Sep 2026 15:17:37 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-33b9e805130so667924eec.1 for ; Wed, 23 Sep 2026 06:17:37 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.17.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:17:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169456; x=1790774256; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ElUpYvhknnIwSPfbcSK8wY490g/9t35RPhM2WyomKNg=; b=scT/3AqeDmupbfNVZmMacnnAzsFwc48mA//AWCLiQVAZAO3fjzbqMp/PiKVKNETptS z+KUaV3stKO4QfklcofmlbyRXTXsaux43/XNcIesXvlCPGHME1v2mShGUIaMC5C67cnx 5mXLZjdM8846GnXPFofDZ+cS8dm9DNWbejj5glanG713u4VIkaI78byl8uy5IG5jOjbV VCOaWIPM0CfvqjiZWWLhBwpqERf0GlC0bjPtctCRcGch1FYvF3HX0Zk9yXrU2UcoYlaz NFb0sJ+mDeiXx9jJ+dmKi5HpvS5/9Jf+TwtKhwqoYDYnoD93OKOX4GqVaH6RkObGCdbI KK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169456; x=1790774256; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ElUpYvhknnIwSPfbcSK8wY490g/9t35RPhM2WyomKNg=; b=tQ8TdMBrMTlPGGBMp67OnUIIkvljPe+YfF7Zmi0xBA1Imd3nDAX0t2H2mpNmMsWDJU HrJkDvOeqFRlVoczMz3Y2S7Yp4mqXyms4gEbG/k+cOvf0QwXWiZpF2fiMgKn8aHxqFWO Bi0fwyed/Ugjg40zL0FvLX6FjE17P0cRows/UoL7SzFQ95VVmiVwf2FkVeq9sxJqgU87 00W5UQvKfbQNXwH8kyYE7HI9i8CQMN5neIAScjH8N7NtFvTU+PrMYK00pewxPjn1B6+P 7NshGBJLON26ByL0Vwyd5caTs0NqoPNzMvPY1dj/7HRdc+FuLR9YcNJ2WdyHna42sNq5 GnHw== X-Forwarded-Encrypted: i=1; AKwUvBzKH43doDUIySwjUP0b3TkQ6Mm5BwLJh+juWyFGmfHmHMuIb+BpP3FpSfYIazPZZSAKuEAXV8YK0FI=@lists.xenproject.org X-Gm-Message-State: AFuF++n7F0+dEnoAuFjWMm/vZq0P0iFqAc2iGThN/Ts77WO/adAt88Pa JaGv7o2urzvdcG/2XrwVdkCWZ+XgjVEAyjB68y/FmcK8RAev7I+OcqNu X-Gm-Gg: AYBFou30o957YrQJU+NhYhffG0IWCAj74xeOlD4kW5U+HSYxox4iMPENmf42aluvXc3 ROKVV3pbrceW8ozV9Ben5JUg7PdEAIQAwnlR38Xdxmv5ZKxmtsgOL9KTawUd27CEFrC3fAXAERO /DWmrtVxp45Phs73sfkWDj5ylqnRHbLbLCsyhCbRGpk1ScRQsgEZfYvg2JNbTZHIlXfGtSuXfVF siJkYVmWhhEv+pCQCErBSBliKmD7nutxTBQj39CrLZV6ajFqLfNcsD2uI9eWqcEoKmIJMfbNvKB 7vxSFSLkfxJO9GvurlLMtXyleeFQ9B3jeOD3tiE1QP/UB4bxeBca6H7xVCW8vlEMFhU0uMohkBp oYapAtH/dmWYWQY+h+wf3umos/bv6wY0SS8p4LFJr1QIO8EfuxpOzC9LmbB6GdUzmMrkegP3KJJ 6lQpG3P5x7atqbYaXgKzPciiGHkAm9OawpYryNAnswEM2DlIEYiaAimTMdozQiFv17lddNExRDM czAvQwxdfMBs1UmhH8/muLhKAy1UaiEKwVx7ldOEQ== X-Received: by 2002:a05:7300:b286:b0:30e:f0a5:8762 with SMTP id 5a478bee46e88-33e8d9ca3c8mr2607807eec.19.1790169455486; Wed, 23 Sep 2026 06:17:35 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 005/114] target-info: set cpu_type from TARGET_BASE_ARCH Date: Wed, 23 Sep 2026 21:14:39 +0800 Message-ID: <20260923131635.1894-6-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-33051d/1790169457-6ECCB4E9-00AA5DB7/0/0 X-purgate-type: clean X-purgate-size: 5027 target-info-def.c no longer includes cpu.h, so CPU_RESOLVING_TYPE is unavailable. Emit TARGET_BASE_ARCH as an uppercase identifier in config-target.h and set cpu_type to TYPE_${TARGET_BASE_ARCH}_CPU. Alias the base-arch tokens whose QOM name differs: TYPE_I386_CPU, TYPE_OR1K_CPU, TYPE_PPC_CPU, TYPE_S390X_CPU, and TYPE_SH4_CPU. Drop the ArchCPU parent_obj and env offsetof checks with the cpu.h include. Page-size checks stay, via cpu-param.h. Signed-off-by: Yonggang Luo --- include/qemu/target-info-def.h | 2 +- meson.build | 1 + target-info-def.c | 11 +++-------- target/i386/cpu-qom.h | 1 + target/or1k/cpu-qom.h | 1 + target/ppc/cpu-qom.h | 1 + target/s390x/cpu-qom.h | 1 + target/sh4/cpu-qom.h | 1 + 8 files changed, 10 insertions(+), 9 deletions(-) diff --git a/include/qemu/target-info-def.h b/include/qemu/target-info-def.h index 8019d2c7196..ebd88463aea 100644 --- a/include/qemu/target-info-def.h +++ b/include/qemu/target-info-def.h @@ -19,7 +19,7 @@ typedef struct TargetInfo { SysEmuTarget target_arch; /* runtime equivalent of TARGET_LONG_BITS definition */ unsigned long_bits; - /* runtime equivalent of CPU_RESOLVING_TYPE definition */ + /* runtime equivalent of TYPE_${TARGET_BASE_ARCH}_CPU definition */ const char *cpu_type; /* related to TARGET_BIG_ENDIAN definition */ EndianMode endianness; diff --git a/meson.build b/meson.build index 8bd2d725ca0..20345860c9f 100644 --- a/meson.build +++ b/meson.build @@ -3378,6 +3378,7 @@ foreach target : target_dirs # Note that TARGET_BASE_ARCH ends up in config-target.h but it is # not used to select files from sourcesets. config_target_data.set('TARGET_' + v.to_upper(), 1) + config_target_data.set(k, v.to_upper()) elif k == 'TARGET_NAME' or k == 'CONFIG_QEMU_INTERP_PREFIX' config_target_data.set_quoted(k, v) elif v == 'y' diff --git a/target-info-def.c b/target-info-def.c index fa19cabc55f..f167f5f2ac1 100644 --- a/target-info-def.c +++ b/target-info-def.c @@ -10,15 +10,10 @@ #include "qemu/target-info.h" #include "qemu/target-info-def.h" #include "qemu/target-info-init.h" -#include "hw/core/boards.h" -#include "cpu.h" -#include "exec/cpu-defs.h" +#include "cpu-qom.h" +#include "cpu-param.h" #include "exec/page-vary.h" -/* Validate correct placement of CPUArchState. */ -QEMU_BUILD_BUG_ON(offsetof(ArchCPU, parent_obj) != 0); -QEMU_BUILD_BUG_ON(offsetof(ArchCPU, env) != sizeof(CPUState)); - /* Validate target page size, if invariant. */ #ifndef TARGET_PAGE_BITS_VARY QEMU_BUILD_BUG_ON(TARGET_PAGE_BITS < TARGET_PAGE_BITS_MIN); @@ -28,7 +23,7 @@ static const TargetInfo target_info_stub = { .target_name = TARGET_NAME, .target_arch = glue(SYS_EMU_TARGET_, TARGET_ARCH), .long_bits = TARGET_LONG_BITS, - .cpu_type = CPU_RESOLVING_TYPE, + .cpu_type = glue(TYPE_, glue(TARGET_BASE_ARCH, _CPU)), .endianness = TARGET_BIG_ENDIAN ? ENDIAN_MODE_BIG : ENDIAN_MODE_LITTLE, #ifdef TARGET_PAGE_BITS_VARY .page_bits_vary = true, diff --git a/target/i386/cpu-qom.h b/target/i386/cpu-qom.h index d4e216d000c..7619c4a4826 100644 --- a/target/i386/cpu-qom.h +++ b/target/i386/cpu-qom.h @@ -27,6 +27,7 @@ #else #define TYPE_X86_CPU "i386-cpu" #endif +#define TYPE_I386_CPU TYPE_X86_CPU OBJECT_DECLARE_CPU_TYPE(X86CPU, X86CPUClass, X86_CPU) diff --git a/target/or1k/cpu-qom.h b/target/or1k/cpu-qom.h index 14bac33312e..c0d5e9e81ba 100644 --- a/target/or1k/cpu-qom.h +++ b/target/or1k/cpu-qom.h @@ -12,6 +12,7 @@ #include "hw/core/cpu.h" #define TYPE_OPENRISC_CPU "or1k-cpu" +#define TYPE_OR1K_CPU TYPE_OPENRISC_CPU OBJECT_DECLARE_CPU_TYPE(OpenRISCCPU, OpenRISCCPUClass, OPENRISC_CPU) diff --git a/target/ppc/cpu-qom.h b/target/ppc/cpu-qom.h index 8247fa23367..428cdc85488 100644 --- a/target/ppc/cpu-qom.h +++ b/target/ppc/cpu-qom.h @@ -28,6 +28,7 @@ #else #define TYPE_POWERPC_CPU "powerpc-cpu" #endif +#define TYPE_PPC_CPU TYPE_POWERPC_CPU OBJECT_DECLARE_CPU_TYPE(PowerPCCPU, PowerPCCPUClass, POWERPC_CPU) diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h index c59bb1eab15..07a8c881fe5 100644 --- a/target/s390x/cpu-qom.h +++ b/target/s390x/cpu-qom.h @@ -23,6 +23,7 @@ #include "hw/core/cpu.h" #define TYPE_S390_CPU "s390x-cpu" +#define TYPE_S390X_CPU TYPE_S390_CPU OBJECT_DECLARE_CPU_TYPE(S390CPU, S390CPUClass, S390_CPU) diff --git a/target/sh4/cpu-qom.h b/target/sh4/cpu-qom.h index 6cf5fbb0745..08fa92106e9 100644 --- a/target/sh4/cpu-qom.h +++ b/target/sh4/cpu-qom.h @@ -23,6 +23,7 @@ #include "hw/core/cpu.h" #define TYPE_SUPERH_CPU "superh-cpu" +#define TYPE_SH4_CPU TYPE_SUPERH_CPU #define TYPE_SH7750R_CPU SUPERH_CPU_TYPE_NAME("sh7750r") #define TYPE_SH7751R_CPU SUPERH_CPU_TYPE_NAME("sh7751r") -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430377.1652840 (Exim 4.92) (envelope-from ) id 1x9MrG-0005rl-60; Wed, 23 Sep 2026 13:17:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430377.1652840; Wed, 23 Sep 2026 13:17:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrF-0005qo-Ve; Wed, 23 Sep 2026 13:17:57 +0000 Received: by outflank-mailman (input) for mailman id 1430377; Wed, 23 Sep 2026 13:17:01 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MqL-0005fG-Dz for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:17:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MqK-006Omx-Bl for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:17:00 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d149-2eae-0a2a0a5409dd-0a2a45029f8c-10 for ; Wed, 23 Sep 2026 15:17:00 +0200 Received: from [74.125.229.19] (helo=mail-dy2-f19.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d14a-6ca4-0a2a45020019-4a7de51380cc-3 for ; Wed, 23 Sep 2026 15:17:00 +0200 Received: by mail-dy2-f19.google.com with SMTP id 5a478bee46e88-3286624d194so642813eec.3 for ; Wed, 23 Sep 2026 06:16:59 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.16.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:16:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169418; x=1790774218; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2gngFNJ3Klpuiy2qgGGYHVsKQcajQAru1FZZV3MRnyY=; b=L2T1KumsISHbPxz6NPCdQ9wxshXO15Va2/fLFq4HAqOPxgHk000l4fHFyqjsPsbR8O 1Cjz1wYlVZ2fLsO6RRbws0/nhCGjjvXbDluRVAiA2VPkpT8J+1OwjGnQrH5gezGSd0uW 0mlpdnct5McvdUglofasmBhx2IJPnBs0kcwCqe5H5E9mPZMz+CETut8vX0rhXGNimbds R+DQgAJmSIT8UU504A98woT2zX6i8kXAqo3ZE6p9Dkpq9hmedKJS0/MbMRNI5Ijr8VE1 yXP5LpOQW+CULlzWBvCcbtd0br+JtS4xx3nl7epoQJBVdeiyBlkzLpie0pV/VMhICgsZ bjhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169418; x=1790774218; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=2gngFNJ3Klpuiy2qgGGYHVsKQcajQAru1FZZV3MRnyY=; b=D452zPH+khNa/3ZJoTfrI1cv5972f887XM4F1feGM/afa1yY8erR8wrSYIyKCl0mAl /C6CLHR3pCMFeyS1J8kuH4Yc+XPkJeWHi5ncjaC9QFnpeCMx2pe1A9eEVucqgA9yVngc 4llNTOQKupOtqen6dIBtOZDnD03as0LX841L9S22q1aCKiKLL+PX0aeL6yKAdoDxDmcH J1gS3JxnXmv0tPbwwgeskp59uG9l6V1ZdrEUSOwxjADkFsWamsejze/w4OBwfeSarwY/ uVQYXL4VILKeD2ER9LOPAWiyrAnSbKLam0KZdQPSdHNeGxgbM70Ej2gxRcdyJXNxCFOD D67A== X-Forwarded-Encrypted: i=1; AKwUvBwT5lyVNtf5yyMbTlxCYI6N3GJSOwWLtMzuX5mVxR5zuR24HfkD1eVRs3pPnsF0nzjNfhYtu3OMrk4=@lists.xenproject.org X-Gm-Message-State: AFuF++lRJdT5xhYWY3Omd4q/UvONddwJ8hP71CJzY2r2Qj3jfDT/jTKi TIktG8Wpwi4pYwbc6cl2Ie0nQjwS/tryq1RfsuDGG3Ay1fkvCZ2s8gEb X-Gm-Gg: AYBFou1WFwiGaq0iYK3jZ+1X0aZCfYg0E6oc6xdtIC5MjBQAJ+d2aRyemFYdKpJ4DSe GhPRVlj9Q96CNdKd5frls9kjb2GYTAqkqnC0Mf9GJkAgf0BR+1lA4CW4SXchhkiEDmwu8N48j0r CwUHpKk78QBGa47YypvOgV6v1GIFgEsSNN6+bZDMDnxRcS6+Pxq9uN/ygEDHjvlsR/um8hklcUH Z5/qL12mx0e/wgMGMK9qJhqHFHKpohJiw4Lrv3myOs4NnPywqpMvfSdLga8rZtxqPO8kFniiQaO 3DtccN+rHkhs4uHyrsHfjVjgsqZZdnlFiLHYtP3+cMEvx/GWMsuD1ck4dkcFV9nok5J/qzd9Y71 xbg428BJ/NtxU/DTkFu1+oIe/6eOlVi/mdBTOMQ5FLKSzPgG6otfwm68EkOliWwc7hx6/ZaYvAo IW8nSMJg+KhY/cSzpjxPUxcTZ4GtgxGUEMWgyrD8BNgFfYWkQ1sTF+SHBBrDOhmi7Tf6Y8REeAv pNWZ1dRAy43IxDeQv+X4jHpJUE9qdMtwNSnnEsH/A== X-Received: by 2002:a05:693c:8808:10b0:33e:6b65:5eab with SMTP id 5a478bee46e88-33e8ddbef60mr2484078eec.26.1790169417968; Wed, 23 Sep 2026 06:16:57 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 001/114] meson: stale qemu-version.h only when .git exists Date: Wed, 23 Sep 2026 21:14:35 +0800 Message-ID: <20260923131635.1894-2-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790169420-F22A92AC-CEE58226/0/0 X-purgate-type: clean X-purgate-size: 865 build_always_stale for qemu-version.h is fs.exists on the source .git. Matches qemu-version.sh, so a tree without git does not regenerate the header on every ninja. Signed-off-by: Yonggang Luo --- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meson.build b/meson.build index cfac634cf13..f17665c667d 100644 --- a/meson.build +++ b/meson.build @@ -3546,7 +3546,7 @@ qemu_version = custom_target('qemu-version.h', command: qemu_version_cmd, capture: true, build_by_default: true, - build_always_stale: true) + build_always_stale: fs.exists(meson.current_source_dir() / '.git')) genh += qemu_version hxdep = [] -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1429458.1652827 (Exim 4.92) (envelope-from ) id 1x9MrF-0005jE-IO; Wed, 23 Sep 2026 13:17:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1429458.1652827; Wed, 23 Sep 2026 13:17:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrF-0005j7-Ff; Wed, 23 Sep 2026 13:17:57 +0000 Received: by outflank-mailman (input) for mailman id 1429458; Tue, 22 Sep 2026 19:23:17 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x965F-0008Dm-7S for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 19:23:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x965E-00BJ8k-0X for xen-devel@lists.xenproject.org; Tue, 22 Sep 2026 21:23:16 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab2d574-e002-0a2a0a5209dd-0a2a4506af6a-46 for ; Tue, 22 Sep 2026 21:23:15 +0200 Received: from [209.85.167.42] (helo=mail-lf1-f42.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab2d5a3-195a-0a2a45060019-d155a72a8d3d-3 for ; Tue, 22 Sep 2026 21:23:15 +0200 Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-5b778bdb5b8so1468e87.1 for ; Tue, 22 Sep 2026 12:23:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790104995; cv=none; d=google.com; s=arc-20260327; b=RmsE4dXmwTZMIPuu37Dc5HUZZ+93N0rkeRAQS3rh2vW3bjTn8D6bXImQkAseIaw57w ZKz794xUCPAB0T/z6NFCNQMaMIyih5aMed7VKWWTHouLF0y6YI0h4blcmcnbO+1w0dQb lQcChmwdjRKOoDIPkQ5Y1G9lV1Gce19FCuaFHBhYDaHZiKAC29K/IFUZgOFKCjWtnJUb 9Vzh7Xpj9dCXu/PRUAj33V3iskHR18DqKdjFiTKnepSaG6mPyfUPRzAGVRwBMuRX2FUI xvJhFrAbH5UJVHLRuloRF6+3GzjEgu0Yp1USepyKgl9XL/Iz0eTpmy4N+iPYV3r5Hk7B z8Ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=bWXycRkvEhooYynfgtJMUHspQSrP76XAP+DtRk1GwMY=; fh=fArzXL4qjM1+Yv+HbKRwNCrID3Jf4eyIGmfeu0lRqsw=; b=e/cVoYJAj/21FPH92o0gzrliAv1RYLi4sdRgTMGXL+ru716Hcr67yAnv1FDbefqCsW FTRf1GNrBOW43SR5iu0sTJvap9NuxQTWR5SjRbGPaEGBLhzeKPRYam877ulEzKKPsVLh 3vd8XkMDbuhQzE8HY7gsEd2DT/2KL8iVwhMnLSlJrte0YeIB/e7o5VbbuRTVyqF3HBZS 2W6pvFq4ztiko+ptkRHDZ0vFgjsrcnJ1A5EI3yg1Yx2wXGqaPqiP3f6x8GnXIaSdprEX XXeRmE6MnbfErGhGKyBxcYiz2SpG55MITiZ9sMp+sOxwBNPsB2klNnXbmA6ERGAk34aL wEUQ==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790104995; x=1790709795; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=bWXycRkvEhooYynfgtJMUHspQSrP76XAP+DtRk1GwMY=; b=q0tV4/sPqAUD2VJNJJGEjfaAGb/ssRfjz2QyuSpZw3vE9UOj2y/syPuCfXnyqrvxo2 0zSjgUKI/mcIvofxVuuizs2cY4mlRlGERqOtgHUl7+bcBK3cub60G4Ry3HPIcFvU9yI2 OzA6vH/3zStowi/z6D9M1UBN6QgV0eDNUjKIh5zJ2SvggR9QRfOQ2rKdSz0vK5hld948 JwNKfjRWdYX+wHiBknAoFG0tgcYwH7WvSt5mN8FWGGJJnpqj3jRB+8iIv7ggum4X1rQU l/wEvLowCOnS9v+MAKLpMp04Y8fLL52LcWVVdbJ5Tervq3m06nanqfFluTB4h+eOO31f 8/Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790104995; x=1790709795; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=bWXycRkvEhooYynfgtJMUHspQSrP76XAP+DtRk1GwMY=; b=l4u1PSgh+Q01R1uBL7wljEAzAgu3Yl24Q7+UUSoV9x10Uo5cpVkCRO9GMSFw0Z2Jbv +12aG5Oxgvgbv9pD9cx+qjfCBhuC5V0yw8ex0/UitCUcQboACU7tETradBaU3RxAQVZN FY6XCB2Z1X9Tfyu774GLwO1vdBV8sDG4YTwgdn6nLH7Z51/cRF09Xwzhb0CnXH3nuO79 vHNScQpZzk5tEo5gotEi5av4rwzo8rKszDgZ3k9DpKkKOpXL+8klSiKFFMf+eGLbB5vE EreJPLwPxbvxNL+serV4QCbBpFk1ptcomEgbSI9WMqAYc+QibmFaoxjURg5HBIFUOik5 G5WQ== X-Forwarded-Encrypted: i=1; AKwUvBzSEJhPTJLmj+sL7/7DYptkIhDx2gYTQT9LJBU0oFPUpyzKCCXFizn7Ljkw3+WiuxefR11VLDHZC4s=@lists.xenproject.org X-Gm-Message-State: AFuF++kUtfCJzhf2RBxoMjSllejYJH/LfRJgF+wzhbY1bOlUmdQHMzK9 iqDoVSIUc23fIcl+WkStzra6avmSOD0+hc4jX319r5VAsN35W3fHE5khl5boXcWQtgrslw4UzpP 1qAA3bakS6E0y8gLM+DURteGRZN4KKKJrYAVy4Qik X-Gm-Gg: AYBFou00FGmvo62JCZ+5GvXAuqTBcnyfJ5qO8Ph1M1dd4aFcyiQdH+h/xkkqn5K4su2 KwYih5ozOuMRxvqnEgszJoQMt67h8Q+Kb3S8bwC1SihtkghH/NkGvCtwIiCsid3UBjee0AOWsVA jJhPAYPZsx5POV7xf8vdb/bevN6o8FsHp0WtGJFUKomxPxWFzeSf/Y+PMOV1CZWYLXgksyHXQCW mGuQ7EXOb5cNIeWi5x2efoL52quZ316w/jDQTgWk6oQXKTZvk9bwHTUF9X2mYovXMOaEfaEwl4f i/MRgSy0ZFZ1LaOOROMYaaHXFs8wQ8lB1PNf0VWj3+nIdZdZcMbrAn2nFVqEr9YGm/rDQDr8Rd4 +o81WeUDxOsE/RYVJ7yCT1jl/VL99LgMw5MCnxR/C X-Received: by 2002:a05:6512:1301:b0:5ae:b726:5f1f with SMTP id 2adb3069b0e04-5b8d8848194mr29002e87.8.1790104994064; Tue, 22 Sep 2026 12:23:14 -0700 (PDT) MIME-Version: 1.0 References: <20260916115159.1938195-1-aik@amd.com> <20260916115159.1938195-18-aik@amd.com> In-Reply-To: <20260916115159.1938195-18-aik@amd.com> From: Jianxiong Gao Date: Tue, 22 Sep 2026 12:22:45 -0700 X-Gm-Features: AcwNN1UxkcAsiONLLRx4-Onp4JXfCAvcJEHnQ3RWuM6d-nkITizrfWrwxkArT4o Message-ID: Subject: Re: [RFC PATCH kernel 17/17] x86/sev: Flush IOMMU TLB for trusted devices To: Alexey Kardashevskiy Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Catalin Marinas , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , Liam Merwick , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , =?UTF-8?Q?Carlos_L=C3=B3pez?= , Jonathan Cameron , Jori Koolstra , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , David Howells , Haavard Skinnemoen , Kenji Kaneshige , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Christian Marangi , Dave Jiang , Michael Kelley , Ilias Stamatis , Sumanth Korikkar , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , Palmer Dabbelt , linux-coco@lists.linux.dev, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, linux-mm@kvack.org, aik@ozlabs.ru, Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba , Darwin Guo , Shruti , Saurabh Singh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-16d1c6/1790104995-1FACA77B-F67446D3/0/0 X-purgate-type: clean X-purgate-size: 13449 On Wed, Sep 16, 2026 at 5:07 AM Alexey Kardashevskiy wrote: > +static int alloc_iommu_tlb_flush_ghcb_pages(void) > +{ > + unsigned int cpu; > + struct page *pg; > + void *p; > + > + /* > + * Allocate per CPU pages while encrypted DMA is not happening ye= t > + * and smashing is cheap. > + */ > + for_each_possible_cpu(cpu) { > + if (per_cpu(iommu_tlb_flush_ghcb_page, cpu)) > + continue; > + > + pg =3D alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL, 0); > + if (!pg) > + return -ENOMEM; > + > + p =3D page_to_virt(pg); > + /* Trigger psmash in the host os now to avoid psmash race= later */ > + snp_set_memory_shared((unsigned long)p, 1); > + snp_set_memory_private((unsigned long)p, 1); > + per_cpu(iommu_tlb_flush_ghcb_page, cpu) =3D p; > + } > + > + return 0; > +} > > int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) > { > @@ -111,6 +142,24 @@ int sev_tio_op(u32 guest_rid, unsigned int op, u64 *= fw_err, u64 *tdi_id) > struct ghcb *ghcb; > int ret; > > + if (!(sev_hv_features & GHCB_HV_FT_SNP_SEV_TIO)) > + return -EPERM; > + > + if (op =3D=3D SVM_VMGEXIT_SEV_TIO_OP_RUN || op =3D=3D SVM_VMGEXIT= _SEV_TIO_OP_STOP) { > + if (!(sev_hv_features & GHCB_HV_FT_SNP_IOMMU_TLB_FLUSH)) > + return -EPERM; > + > + if (op =3D=3D SVM_VMGEXIT_SEV_TIO_OP_RUN) { > + if (atomic_inc_return(&sev_tio_devices_num) =3D= =3D 1) { > + ret =3D alloc_iommu_tlb_flush_ghcb_pages(= ); > + if (ret) > + return ret; > + } > + } else if (atomic_dec_return(&sev_tio_devices_num) =3D=3D= 0) { > + /* Do cleanup or leave it like this? */ > + } > + } Hi Alexey, When testing this series and accepting a locked TDI in the guest (echo 1 > /sys/bus/pci/devices/.../tsm/accept), the guest immediately terminates with 0x1:0xd (SEV_TERM_SET_LINUX, GHCB_TERM_IOMMUTLB_FLUSH). In sev_tio_op(), sev_tio_devices_num is incremented from 0 to 1 before alloc_iommu_tlb_flush_ghcb_pages() allocates and initializes the per-CPU iommu_tlb_flush_ghcb_page buffers: 1. atomic_inc_return(&sev_tio_devices_num) sets sev_tio_devices_num =3D 1 while iommu_tlb_flush_ghcb_page is still NULL on all CPUs. 2. alloc_iommu_tlb_flush_ghcb_pages() allocates p for cpu =3D 0 and calls snp_set_memory_shared((unsigned long)p, 1) to pre-smash the 2M page before per_cpu(iommu_tlb_flush_ghcb_page, cpu) is assigned (and before other CPUs' pages are allocated, in case this task is running on cpu > 0= ). 3. snp_set_memory_shared() -> __set_pages_state() sees atomic_read(&sev_tio_devices_num) !=3D 0 and calls ghcb_flush_iommu_tlb(= ). 4. ghcb_flush_iommu_tlb() reads this_cpu_read(iommu_tlb_flush_ghcb_page), gets NULL, and returns -ENOMEM. 5. __set_pages_state() treats the non-zero return as fatal and calls sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_IOMMUTLB_FLUSH). Calling alloc_iommu_tlb_flush_ghcb_pages() before incrementing sev_tio_devices_num avoids triggering ghcb_flush_iommu_tlb() while the per-CPU pages are still being pre-smashed and initialized: --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -150,13 +150,12 @@ int sev_tio_op(...) return -EPERM; if (op =3D=3D SVM_VMGEXIT_SEV_TIO_OP_RUN) { - if (atomic_inc_return(&sev_tio_devices_num) =3D=3D 1) { - ret =3D alloc_iommu_tlb_flush_ghcb_pages(); - if (ret) - return ret; - } - } else if (atomic_dec_return(&sev_tio_devices_num) =3D=3D 0) { - /* Do cleanup or leave it like this? */ + ret =3D alloc_iommu_tlb_flush_ghcb_pages(); + if (ret) + return ret; + atomic_inc(&sev_tio_devices_num); + } else { + atomic_dec_if_positive(&sev_tio_devices_num); } } On Wed, Sep 16, 2026 at 5:07=E2=80=AFAM Alexey Kardashevskiy = wrote: > > IOMMU performs RMP checks when SNP is enabled, the results are > cached along with the IOMMU translations. When a VM lowers permission > of a mapped page (moves to a lower VMPL level or from read+write to > read-only or private to shared), the cached RMP check results require > invalidation. > > At the moment the only way to invalidate IOMMU cache is the RMPUPDATE > instruction which flushes all IOMMU TLBs. It is a host privileged > instruction so a VM needs a way to ensure the host has done it. > Note that the guest's RMPADJUST/PVALIDATE do not flush IOMMU TLBs. > > The host implements a new "IOMMU TLB Flush" VMGEXIT code which is > advertised via bit#11 in the GHCB Hypervisor capabilities. > > Use RMPUPDATE in the following way: > - allocate a page per VCPU (to allow lockless flushing); > - When invalidation is needed, copy two patterns (A and B) to the page; > - invalidate the page so the host can make it shared; > - use new GHCB call to request RMPUPDATE on the host; > - the host makes the page shared; > - the host clears pattern A; > - the host makes the page private again; > - the host returns to the guest; > - check if pattern A has changed and pattern B has not; > - if the above failed, panic(). > > The patterns are located far enough to not hit the same cache line to > work with the cipher text hiding feature. > > The host can choose to not execute the request, WARN_ON if this > is the case. Further patches will attempt to handle this in other way. > > Signed-off-by: Alexey Kardashevskiy > --- > arch/x86/include/asm/sev-common.h | 2 + > arch/x86/include/uapi/asm/svm.h | 3 + > arch/x86/coco/sev/core.c | 92 ++++++++++++++++++++ > 3 files changed, 97 insertions(+) > > diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev= -common.h > index ff763c3c5d63..51abf8d061fa 100644 > --- a/arch/x86/include/asm/sev-common.h > +++ b/arch/x86/include/asm/sev-common.h > @@ -138,6 +138,7 @@ enum psc_op { > #define GHCB_HV_FT_SNP_AP_CREATION BIT_ULL(1) > #define GHCB_HV_FT_SNP_MULTI_VMPL BIT_ULL(5) > #define GHCB_HV_FT_SNP_SEV_TIO BIT_ULL(7) > +#define GHCB_HV_FT_SNP_IOMMU_TLB_FLUSH BIT_ULL(11) > > /* > * SNP Page State Change NAE event > @@ -210,6 +211,7 @@ struct snp_psc_desc { > #define GHCB_TERM_SECURE_TSC 10 /* Secure TSC initializat= ion failed */ > #define GHCB_TERM_SVSM_CA_REMAP_FAIL 11 /* SVSM is present but CA= could not be remapped */ > #define GHCB_TERM_SAVIC_FAIL 12 /* Secure AVIC-specific f= ailure */ > +#define GHCB_TERM_IOMMUTLB_FLUSH 13 /* IOMMUTLB flush failed = for SEV-TIO device */ > > #define GHCB_RESP_CODE(v) ((v) & GHCB_MSR_INFO_MASK) > > diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/= svm.h > index 93597ad492bf..269050942c8e 100644 > --- a/arch/x86/include/uapi/asm/svm.h > +++ b/arch/x86/include/uapi/asm/svm.h > @@ -160,6 +160,8 @@ > #define SVM_VMGEXIT_SEV_TIO_OP_UNBIND 1 > #define SVM_VMGEXIT_SEV_TIO_OP_RUN 2 > #define SVM_VMGEXIT_SEV_TIO_OP_STOP 3 > +#define SVM_VMGEXIT_IOMMU_TLB_FLUSH 0x80000022ull > +#define SVM_VMGEXIT_IOMMU_TLB_FLUSH_NO_ACTION 1 > #define SVM_VMGEXIT_HV_FEATURES 0x8000fffdull > #define SVM_VMGEXIT_TERM_REQUEST 0x8000fffeull > #define SVM_VMGEXIT_TERM_REASON(reason_set, reason_code) \ > @@ -285,6 +287,7 @@ > { SVM_VMGEXIT_AP_CREATION, "vmgexit_ap_creation" }, \ > { SVM_VMGEXIT_SEV_TIO_GR, "vmgexit_sev_tio_guest_request" }= , \ > { SVM_VMGEXIT_SEV_TIO_OP, "vmgexit_sev_tio_op" }, \ > + { SVM_VMGEXIT_IOMMU_TLB_FLUSH, "vmgexit_sev_tio_iommu_tlb_flush" = }, \ > { SVM_VMGEXIT_HV_FEATURES, "vmgexit_hypervisor_feature" }, \ > { SVM_EXIT_ERR, "invalid_guest_state" } > > diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c > index ed0e4546d5e5..aa5a3abb4796 100644 > --- a/arch/x86/coco/sev/core.c > +++ b/arch/x86/coco/sev/core.c > @@ -44,6 +44,7 @@ > #include > #include > #include > +#include > > #include "internal.h" > > @@ -103,6 +104,36 @@ static unsigned long snp_tsc_freq_khz __ro_after_ini= t; > > DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data); > DEFINE_PER_CPU(struct sev_es_save_area *, sev_vmsa); > +DEFINE_PER_CPU(u8 *, iommu_tlb_flush_ghcb_page); > +static atomic_t sev_tio_devices_num; > + > +static int alloc_iommu_tlb_flush_ghcb_pages(void) > +{ > + unsigned int cpu; > + struct page *pg; > + void *p; > + > + /* > + * Allocate per CPU pages while encrypted DMA is not happening ye= t > + * and smashing is cheap. > + */ > + for_each_possible_cpu(cpu) { > + if (per_cpu(iommu_tlb_flush_ghcb_page, cpu)) > + continue; > + > + pg =3D alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL, 0); > + if (!pg) > + return -ENOMEM; > + > + p =3D page_to_virt(pg); > + /* Trigger psmash in the host os now to avoid psmash race= later */ > + snp_set_memory_shared((unsigned long)p, 1); > + snp_set_memory_private((unsigned long)p, 1); > + per_cpu(iommu_tlb_flush_ghcb_page, cpu) =3D p; > + } > + > + return 0; > +} > > int sev_tio_op(u32 guest_rid, unsigned int op, u64 *fw_err, u64 *tdi_id) > { > @@ -111,6 +142,24 @@ int sev_tio_op(u32 guest_rid, unsigned int op, u64 *= fw_err, u64 *tdi_id) > struct ghcb *ghcb; > int ret; > > + if (!(sev_hv_features & GHCB_HV_FT_SNP_SEV_TIO)) > + return -EPERM; > + > + if (op =3D=3D SVM_VMGEXIT_SEV_TIO_OP_RUN || op =3D=3D SVM_VMGEXIT= _SEV_TIO_OP_STOP) { > + if (!(sev_hv_features & GHCB_HV_FT_SNP_IOMMU_TLB_FLUSH)) > + return -EPERM; > + > + if (op =3D=3D SVM_VMGEXIT_SEV_TIO_OP_RUN) { > + if (atomic_inc_return(&sev_tio_devices_num) =3D= =3D 1) { > + ret =3D alloc_iommu_tlb_flush_ghcb_pages(= ); > + if (ret) > + return ret; > + } > + } else if (atomic_dec_return(&sev_tio_devices_num) =3D=3D= 0) { > + /* Do cleanup or leave it like this? */ > + } > + } > + > /* __sev_get_ghcb() needs IRQs disabled because it uses per-CPU G= HCB. */ > guard(irqsave)(); > > @@ -347,6 +396,42 @@ static int vmgexit_psc(struct ghcb *ghcb, struct snp= _psc_desc *desc) > return ret; > } > > +static int ghcb_flush_iommu_tlb(struct ghcb *ghcb) > +{ > + /* AES encrypts with 16 byte blocks */ > + unsigned long s1[BITS_TO_LONGS(128)], s2[BITS_TO_LONGS(128)]; > + void *p =3D this_cpu_read(iommu_tlb_flush_ghcb_page), *p2; > + struct es_em_ctxt ctxt; > + int ret; > + > + if (!p) > + return -ENOMEM; > + > + /* Keep patterns apart far enough to not share the same cache lin= e */ > + p2 =3D (u8 *) p + 2048; > + > + vc_ghcb_invalidate(ghcb); > + > + BUILD_BUG_ON(ARRAY_SIZE(s1) !=3D 2); > + if (!rdrand_long(s1) || !rdrand_long(s1 + 1) || > + !rdrand_long(s2) || !rdrand_long(s2 + 1)) > + return -EFAULT; > + > + memcpy(p, s1, sizeof(s1)); > + memcpy(p2, s2, sizeof(s2)); > + > + pvalidate((unsigned long) p, RMP_PG_SIZE_4K, false); > + ret =3D sev_es_ghcb_hv_call(ghcb, &ctxt, SVM_VMGEXIT_IOMMU_TLB_FL= USH, __pa(p), 0); > + pvalidate((unsigned long) p, RMP_PG_SIZE_4K, true); > + > + /* Ensure that the host change is visible */ > + smp_mb(); > + > + if (!memcmp(p, s1, sizeof(s1)) || memcmp(p2, s2, sizeof(s2))) > + return -EFAULT; > + > + return 0; > +} > static unsigned long __set_pages_state(struct snp_psc_desc *data, unsign= ed long vaddr, > unsigned long vaddr_end, int op) > { > @@ -404,6 +489,13 @@ static unsigned long __set_pages_state(struct snp_ps= c_desc *data, unsigned long > if (!ghcb || vmgexit_psc(ghcb, data)) > sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_PSC); > > + if (atomic_read(&sev_tio_devices_num)) { > + int ret =3D ghcb_flush_iommu_tlb(ghcb); > + > + if (ret) > + sev_es_terminate(SEV_TERM_SET_LINUX, GHCB_TERM_IO= MMUTLB_FLUSH); > + } > + > __sev_put_ghcb(&state); > > local_irq_restore(flags); > -- > 2.55.0 > > --=20 Jianxiong Gao From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430387.1652900 (Exim 4.92) (envelope-from ) id 1x9MrM-0007Ub-Mm; Wed, 23 Sep 2026 13:18:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430387.1652900; Wed, 23 Sep 2026 13:18:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrM-0007UM-Hk; Wed, 23 Sep 2026 13:18:04 +0000 Received: by outflank-mailman (input) for mailman id 1430387; Wed, 23 Sep 2026 13:17:52 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrA-0005ia-0G for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:17:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mr9-00BPJW-Df for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:17:51 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d172-2eae-0a2a0a5409dd-0a2a450b858a-40 for ; Wed, 23 Sep 2026 15:17:51 +0200 Received: from [74.125.229.170] (helo=mail-dl2-f42.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d179-b7e8-0a2a450b0019-4a7de5aa8d58-3 for ; Wed, 23 Sep 2026 15:17:47 +0200 Received: by mail-dl2-f42.google.com with SMTP id a92af1059eb24-142dce6e237so674288c88.3 for ; Wed, 23 Sep 2026 06:17:46 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.17.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:17:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169465; x=1790774265; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VyGOeMM6N9WmW/Btrmx0VVv+jU00kmaZZ+J9OFmIWlc=; b=oNBcuh/cCUt2NDLTVubwG+pYTe4x8stKpq4jAZTvb7GmNRVbzByJ9TLh1rjoTVpw1u ZmS0i2igmbwoFDfXqxRGeGWqqgO7zViirEfIibQSuriOK6/oorb8wZ32Ie2E8unksClP tvNhZuztLIkSGCzoUYzjB1YAPIZznsk36c/EakO6Jk/Y8K+MIbNcr4ltui7ut8d2CiCC 9QA+DVI4AheCbOVAeyrJ0D2MxES582ZMxYEBuoEzMy5HUBcnl85UUsd60cu1grKlRtB6 fViSoqRXq181BkXKW+mSvDAl4T7jtJv29bOqwXew23JnA1bbwSXQu1Dlq+ujcAfKscYB GYGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169465; x=1790774265; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=VyGOeMM6N9WmW/Btrmx0VVv+jU00kmaZZ+J9OFmIWlc=; b=dn2K3Xkcm83tANwp8iVvUMVcjgn7aMv8g3zp0v2J55TMXaBBY33QwRpx1/3p8o4+40 HF9PiECOH5e8UdHIIE3LBWiEkSVjo5qOgIzxaLC8WSXfhrt1S24W8CdcMC4RPrhnSNcq Dywkv2UbsXO6DvmJfWu2M24HAsYyxDSR8YjCAXI2RYvv5lVz2pwTtHgyR1HUwR+35SyP /xv+R0PqzXDoqDj22kL5rDswei2GuUuT5ltw4MimSjoDiq9OkUO+9BbDzrgRiZuXaGhf e9oWpmHrTq54bboHx65ON0B4pDdiGlbtWwQgQ6KSoO+OButqM3NBirfSOT21C8fQQ2iv cVtw== X-Forwarded-Encrypted: i=1; AKwUvBzWK1C7jJK0ZWXGqWfLRct8ZW5okHPPk8Sgk6puWOKedQ9Kyh9dm4E5R6hoXzoUQoB1imrVb3Jtl7M=@lists.xenproject.org X-Gm-Message-State: AFuF++lfi6p4IBV8bLyI6TDt8OhTQ3xKmTHOtZU87UbWCVkYgIXltPuP eIL2Pb5G/ek1MChYx2KWfnrkQYoMGfUJbn6drdk2uap2UP3KJz+kt/tw X-Gm-Gg: AYBFou2nek+V8LCxq+ELTFL+7SjnvlXHjka3iwk6yr5imtUu2lCOW0yQqeI8d1BeQ29 X2udl4E5o7SOy2ehiS2DQbEfnqTfzmV7OdETajtykBHIoNvzYVywiA03iCq1HrG2gAeLI80wZGt sNFu3iPbYo1QHK8XGKQQBZBw8H22R5brMkkF8GWL5mABrGr2qxiYsk5mzRYTqDQWOi9D4FzF1z9 fVp/m1pG5zUGcoISb2yfGLLyICtsAhy2y++swQyrU/0e2W60lziP7ty8fID63d9LtUz6JS++Y+U GeOFzBMap0IAhaw09DsLPP3DeyvhDpSoR7hj6SmMO2Ozo/l19FezsDIIUof8dJbx0W/QqZGOMNG zlCqDH4AbvYhz2zZ/lyOZKvKXXjyg/REJ26wCgRj+LdA715vF2n8KQPlMWVZH//vLm94qLbZv+V 0H1eKYfBNDPHEyOSWkBRLJJDogG8dk5liB1D7N6LNyUadp/L2NAEuuq6WBsxYsj6vKXRwgYtNmz m7rolZGCmiI8HlA0Yh8H57v6R6MWUY= X-Received: by 2002:a05:693c:6394:20b0:339:8343:a1a with SMTP id 5a478bee46e88-33e8e1b7329mr2469431eec.41.1790169464712; Wed, 23 Sep 2026 06:17:44 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 006/114] target: remove CPU_RESOLVING_TYPE Date: Wed, 23 Sep 2026 21:14:40 +0800 Message-ID: <20260923131635.1894-7-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790169467-AA8D99EA-E8B936FA/0/0 X-purgate-type: clean X-purgate-size: 9176 cpu_type is TYPE_${TARGET_BASE_ARCH}_CPU, so the per-target CPU_RESOLVING_TYPE macros are unused. Drop them from every target cpu.h. Signed-off-by: Yonggang Luo --- target/alpha/cpu.h | 2 -- target/arm/cpu.h | 2 -- target/avr/cpu.h | 2 -- target/hexagon/cpu.h | 1 - target/hppa/cpu.h | 2 -- target/i386/cpu.h | 2 -- target/loongarch/cpu.h | 2 -- target/m68k/cpu.h | 2 -- target/microblaze/cpu.h | 2 -- target/mips/cpu.h | 2 -- target/or1k/cpu.h | 2 -- target/ppc/cpu.h | 2 -- target/riscv/cpu.h | 2 -- target/rx/cpu.h | 2 -- target/s390x/cpu.h | 3 --- target/sh4/cpu.h | 2 -- target/sparc/cpu.h | 2 -- target/tricore/cpu.h | 2 -- target/xtensa/cpu.h | 2 -- 19 files changed, 38 deletions(-) diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h index 378bd96d941..a6ffe7eec29 100644 --- a/target/alpha/cpu.h +++ b/target/alpha/cpu.h @@ -433,8 +433,6 @@ void alpha_translate_init(void); void alpha_translate_code(CPUState *cs, TranslationBlock *tb, int *max_insns, vaddr pc, void *host_pc); -#define CPU_RESOLVING_TYPE TYPE_ALPHA_CPU - G_NORETURN void dynamic_excp(CPUAlphaState *, uintptr_t, int, int); G_NORETURN void arith_excp(CPUAlphaState *, uintptr_t, int, uint64_t); diff --git a/target/arm/cpu.h b/target/arm/cpu.h index e3f931dba26..359d86e2c37 100644 --- a/target/arm/cpu.h +++ b/target/arm/cpu.h @@ -2395,8 +2395,6 @@ bool write_cpustate_to_list(ARMCPU *cpu, bool kvm_sync); #define ARM_CPUID_TI915T 0x54029152 #define ARM_CPUID_TI925T 0x54029252 -#define CPU_RESOLVING_TYPE TYPE_ARM_CPU - #define TYPE_ARM_HOST_CPU "host-" TYPE_ARM_CPU /* Indexes used when registering address spaces with cpu_address_space_init */ diff --git a/target/avr/cpu.h b/target/avr/cpu.h index 1e4e839bd83..747655543d4 100644 --- a/target/avr/cpu.h +++ b/target/avr/cpu.h @@ -30,8 +30,6 @@ #error "AVR 8-bit does not support user mode" #endif -#define CPU_RESOLVING_TYPE TYPE_AVR_CPU - /* * AVR has two memory spaces, data & code. * e.g. both have 0 address diff --git a/target/hexagon/cpu.h b/target/hexagon/cpu.h index e79d8000304..54b0d69a827 100644 --- a/target/hexagon/cpu.h +++ b/target/hexagon/cpu.h @@ -52,7 +52,6 @@ typedef struct HexagonGlobalRegState HexagonGlobalRegState; #define MAX_TLB_ENTRIES 1024 #define THREADS_MAX 16 -#define CPU_RESOLVING_TYPE TYPE_HEXAGON_CPU #ifndef CONFIG_USER_ONLY #define CPU_INTERRUPT_SWI CPU_INTERRUPT_TGT_INT_0 #define CPU_INTERRUPT_K0_UNLOCK CPU_INTERRUPT_TGT_INT_1 diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h index f453444d7f9..35b6b8af82a 100644 --- a/target/hppa/cpu.h +++ b/target/hppa/cpu.h @@ -339,8 +339,6 @@ void hppa_translate_init(void); void hppa_translate_code(CPUState *cs, TranslationBlock *tb, int *max_insns, vaddr pc, void *host_pc); -#define CPU_RESOLVING_TYPE TYPE_HPPA_CPU - static inline vaddr hppa_form_gva_mask(uint64_t gva_offset_mask, uint64_t spc, target_ulong off) { diff --git a/target/i386/cpu.h b/target/i386/cpu.h index 786957fadd0..eba184035d4 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -2813,8 +2813,6 @@ void cpu_x86_update_dr7(CPUX86State *env, uint32_t new_dr7); /* hw/pc.c */ uint64_t cpu_get_tsc(CPUX86State *env); -#define CPU_RESOLVING_TYPE TYPE_X86_CPU - #ifdef TARGET_X86_64 #define TARGET_DEFAULT_CPU_TYPE X86_CPU_TYPE_NAME("qemu64") #else diff --git a/target/loongarch/cpu.h b/target/loongarch/cpu.h index c592f698853..5d79ea836bf 100644 --- a/target/loongarch/cpu.h +++ b/target/loongarch/cpu.h @@ -553,6 +553,4 @@ static inline void set_pc(CPULoongArchState *env, uint64_t value) #define HW_FLAGS_VA32 0x20 #define HW_FLAGS_EUEN_ASXE 0x40 -#define CPU_RESOLVING_TYPE TYPE_LOONGARCH_CPU - #endif /* LOONGARCH_CPU_H */ diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h index 7cf3791108c..b3962910ad1 100644 --- a/target/m68k/cpu.h +++ b/target/m68k/cpu.h @@ -579,8 +579,6 @@ enum { ACCESS_DATA = 0x20, /* Data load/store access */ }; -#define CPU_RESOLVING_TYPE TYPE_M68K_CPU - /* MMU modes definitions */ #define MMU_KERNEL_IDX 0 #define MMU_USER_IDX 1 diff --git a/target/microblaze/cpu.h b/target/microblaze/cpu.h index b9602f72b94..00ceaf1acf7 100644 --- a/target/microblaze/cpu.h +++ b/target/microblaze/cpu.h @@ -401,8 +401,6 @@ void mb_tcg_init(void); void mb_translate_code(CPUState *cs, TranslationBlock *tb, int *max_insns, vaddr pc, void *host_pc); -#define CPU_RESOLVING_TYPE TYPE_MICROBLAZE_CPU - /* MMU modes definitions */ #define MMU_NOMMU_IDX 0 #define MMU_KERNEL_IDX 1 diff --git a/target/mips/cpu.h b/target/mips/cpu.h index 32549791a18..0d2846eaf58 100644 --- a/target/mips/cpu.h +++ b/target/mips/cpu.h @@ -1359,8 +1359,6 @@ enum { */ #define CPU_INTERRUPT_WAKE CPU_INTERRUPT_TGT_INT_0 -#define CPU_RESOLVING_TYPE TYPE_MIPS_CPU - bool cpu_type_supports_cps_smp(const char *cpu_type); bool cpu_supports_isa(const CPUMIPSState *env, uint64_t isa_mask); bool cpu_type_supports_isa(const char *cpu_type, uint64_t isa); diff --git a/target/or1k/cpu.h b/target/or1k/cpu.h index fc4387ce7ae..34586755baf 100644 --- a/target/or1k/cpu.h +++ b/target/or1k/cpu.h @@ -320,8 +320,6 @@ void cpu_openrisc_count_start(OpenRISCCPU *cpu); void cpu_openrisc_count_stop(OpenRISCCPU *cpu); #endif -#define CPU_RESOLVING_TYPE TYPE_OPENRISC_CPU - #define TB_FLAGS_SM SR_SM #define TB_FLAGS_DME SR_DME #define TB_FLAGS_IME SR_IME diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h index 217b4f334e5..c11d64677df 100644 --- a/target/ppc/cpu.h +++ b/target/ppc/cpu.h @@ -29,8 +29,6 @@ #include "qom/object.h" #include "hw/core/registerfields.h" -#define CPU_RESOLVING_TYPE TYPE_POWERPC_CPU - #define TARGET_PAGE_BITS_64K 16 #define TARGET_PAGE_BITS_16M 24 diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h index a97f30793b9..034d7e96c49 100644 --- a/target/riscv/cpu.h +++ b/target/riscv/cpu.h @@ -36,8 +36,6 @@ typedef struct CPUArchState CPURISCVState; -#define CPU_RESOLVING_TYPE TYPE_RISCV_CPU - /* * b0: Whether a instruction always raise a store AMO or not. */ diff --git a/target/rx/cpu.h b/target/rx/cpu.h index 233615c32dc..49188c36c57 100644 --- a/target/rx/cpu.h +++ b/target/rx/cpu.h @@ -144,8 +144,6 @@ struct RXCPUClass { ResettablePhases parent_phases; }; -#define CPU_RESOLVING_TYPE TYPE_RX_CPU - const char *rx_crname(uint8_t cr); void rx_cpu_do_interrupt(CPUState *cpu); bool rx_cpu_exec_interrupt(CPUState *cpu, int int_req); diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h index 998bbb0d7ff..c77b297a26a 100644 --- a/target/s390x/cpu.h +++ b/target/s390x/cpu.h @@ -860,9 +860,6 @@ static inline uint8_t s390_cpu_get_state(const S390CPU *cpu) } -/* helper.c */ -#define CPU_RESOLVING_TYPE TYPE_S390_CPU - /* interrupt.c */ #define RA_IGNORED 0 void s390_program_interrupt(CPUS390XState *env, uint32_t code, uintptr_t ra); diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h index d440aa6dbe7..eaf67fe8e6a 100644 --- a/target/sh4/cpu.h +++ b/target/sh4/cpu.h @@ -304,8 +304,6 @@ int cpu_sh4_is_cached(CPUSH4State *env, uint32_t addr); void cpu_load_tlb(CPUSH4State * env); -#define CPU_RESOLVING_TYPE TYPE_SUPERH_CPU - /* MMU modes definitions */ #define MMU_USER_IDX 1 diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h index 31a16c2af03..fd409e74948 100644 --- a/target/sparc/cpu.h +++ b/target/sparc/cpu.h @@ -663,8 +663,6 @@ hwaddr cpu_get_phys_page_nofault(CPUSPARCState *env, target_ulong addr, #endif #endif -#define CPU_RESOLVING_TYPE TYPE_SPARC_CPU - /* MMU modes definitions */ #if defined (TARGET_SPARC64) #define MMU_USER_IDX 0 diff --git a/target/tricore/cpu.h b/target/tricore/cpu.h index 12e497d2a7a..346b0e1f3f3 100644 --- a/target/tricore/cpu.h +++ b/target/tricore/cpu.h @@ -257,8 +257,6 @@ void tricore_tcg_init(void); void tricore_translate_code(CPUState *cs, TranslationBlock *tb, int *max_insns, vaddr pc, void *host_pc); -#define CPU_RESOLVING_TYPE TYPE_TRICORE_CPU - /* helpers.c */ bool tricore_cpu_tlb_fill(CPUState *cs, vaddr address, int size, MMUAccessType access_type, int mmu_idx, diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h index 0b2cb5a250d..ee8d9c10b16 100644 --- a/target/xtensa/cpu.h +++ b/target/xtensa/cpu.h @@ -603,8 +603,6 @@ G_NORETURN void xtensa_cpu_do_unaligned_access(CPUState *cpu, vaddr addr, uintptr_t retaddr); G_NORETURN void xtensa_exception(CPUXtensaState *env, uint32_t excp); -#define CPU_RESOLVING_TYPE TYPE_XTENSA_CPU - #if TARGET_BIG_ENDIAN #define XTENSA_DEFAULT_CPU_MODEL "fsf" #define XTENSA_DEFAULT_CPU_NOMMU_MODEL "fsf" -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430375.1652832 (Exim 4.92) (envelope-from ) id 1x9MrF-0005lp-Rt; Wed, 23 Sep 2026 13:17:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430375.1652832; Wed, 23 Sep 2026 13:17:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrF-0005lQ-ND; Wed, 23 Sep 2026 13:17:57 +0000 Received: by outflank-mailman (input) for mailman id 1430375; Wed, 23 Sep 2026 13:16:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MqC-0005ek-Pc for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:16:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MqB-009CJY-EW for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:16:51 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d136-8faa-0a2a0a5109dd-0a2a4507972a-20 for ; Wed, 23 Sep 2026 15:16:51 +0200 Received: from [74.125.82.176] (helo=mail-dy1-f176.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d141-b4ea-0a2a45070019-4a7d52b0a5fa-3 for ; Wed, 23 Sep 2026 15:16:51 +0200 Received: by mail-dy1-f176.google.com with SMTP id 5a478bee46e88-3115c4451c8so635301eec.1 for ; Wed, 23 Sep 2026 06:16:50 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.16.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:16:46 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169409; x=1790774209; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=p8tyiRwxKQdp0RZD4SXOyBX8lB+B9XyIJi0FcZ12QW8=; b=s4CYuHgMczLCbZekTZALGu3dDpcgYDXflTmPitQGZY7Gd5flAgttEZxHoYOR5wFXZu +87iICjXDg+/OLYBWbSaof/xp0J1dovLBcRt3MLvvtrNrYLEQn2Kh2maI6cfiIDrsiah NraanQxAttq1ePRZXopcvrrq5fhcxg7GCvFpKI6tVhk8nqehhjlHiJDW6c+TZIs+2Sja eH21E9e1b1Am4l5+31ZqiuKt/QyyiJd4lXqZJq+T13ke+ZAi7+od8CDnQO9wGSflEyxr YqVnJpUPgJrFOOH3hByy7tkORRXgNPUs/CvVfXiCv/YVMK1ikHFAm8YL9YUFBmb/aX5/ o42A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169409; x=1790774209; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=p8tyiRwxKQdp0RZD4SXOyBX8lB+B9XyIJi0FcZ12QW8=; b=mC42cD69B5hf9kleeumsStdDTAaGi+8Vnf5vViKI2mnlcmB9g7QvvG8MgLBfALqxEn Eu5WcjUkmDjx1WrnuJubR5c52m08t/v6v6IlLP0NDH8BdPl6K0rnUEloFdLjtrgpG6iK 4l2RZDSWWmMegB8vk9rw7TQXkNIB2jGydhBTbiuQA5ZJsmtpqCVQoZrf57i0Ln1QsGqn YBP1buh5Uey3pREdP2Vylv+Wn03XZ4fwinXE45hvzmRhjluhaYWnoqD3DGEUkA5GB0Lr kgcc0686ziWActl2kIDvbguP5+R7KHvrGD2H/eDKm+HRQ4KYTiAqKNLMqqmkHvINDI9r Vr2w== X-Forwarded-Encrypted: i=1; AKwUvBwVqpLRGnhFh18CsKzUrPuwYZ7iXnaK8842oWCFfWxRYd5biLznbva/qW09QvShW6S7vDyr8MJqD0M=@lists.xenproject.org X-Gm-Message-State: AFuF++l684kubYIPYqIWAeKbQO9DE0WMdMc8YE3kzlM5iZ2/l4S3gYH3 VmUResR+w8AKalPRooC1NLzJZMQDuG/sR16oPh/2R8T9o+b0CqG1s5UL X-Gm-Gg: AYBFou2YDfRhRnZoZhRCmuGjRPFBZ7ZQvOr+5YasQg3OKt+8FJiAxbKI2wO+ydabieV 6AN9bv5TLI9F0IeHUsSGb07cKX5w6gV4MZ0u0OfwUFSw9w8WQ6W97HSAG1Tvl20PkvHJ9cWBttc /VGjObsw0TMhPdlaxKHUx2MI+B6RgdZIo6DP1Xx4hCjXF8S5O4L3Qx2PAQcyZkgLPp+8AAaA0Sf dB0uBGUVKCCGQ/rCqnqZlteaLmW0YMU2QPJIylqXzKnCDrzzqgKInEKt5C+PHlQ6HQbMf5pa1eN hvD5OQavlQOTdV/raF2Vuh/rBP2dVCz2I8tBb2w0BbSWQQobb0iTFcUML4AGOZ1MZf8/QSv5KQX 7jFng1LoHD+EJFq4/8yciFysciwNtAMPEGbulLK4NKcJFoWH0w1+4w6tjHuTKrF2lisuCvaVdEo EwV7YMLWWcup76Yox2N7TPuHK+b8lQzPjMUGQ/o1ofOdurQtvlYeYgxi0/O79BtkNe7U1V3Gq/D XBT5tgcFB0qmgGF0dXO42GNKHMt9KI= X-Received: by 2002:a05:7301:d586:b0:33e:5f5a:4b55 with SMTP id 5a478bee46e88-33e5f5a53f6mr2889546eec.19.1790169407963; Wed, 23 Sep 2026 06:16:47 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 000/114] single-binary: link multi-targets into qemu-system Date: Wed, 23 Sep 2026 21:14:34 +0800 Message-ID: <20260923131635.1894-1-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790169411-3C212AE4-B97C7303/0/0 X-purgate-type: clean X-purgate-size: 32837 This series produces one qemu-system binary that can run ARM (32 and 64), RISC-V (32 and 64), and MicroBlaze. Upstream filters machines with TypeInfo.is_available. This series passes a TargetInfo into that callback, uniquifies QOM names that collide in one process, and compiles those targets once so they can share qemu-system. A combined link cannot keep C symbols or QOM type names that were unique only because each qemu-system-$arch was a separate binary. These patches remove those collisions: - TYPE_ACCEL_CPU is the fixed abstract type accel-cpu, registered once next to TYPE_ACCEL. Leaf names still encode the CPU type so accel_init_cpu_interfaces() can look up "-" plus target_cpu_type() (tcg-accel-arm-cpu). - virt QOM names are prefixed: arm-virt, riscv-virt, and the same for or1k, hexagon, loongarch, m68k, and xtensa. Boards keep -machine virt via machine_class_set_name(). query-machines returns the QOM type in MachineInfo typename. - virt ACPI helpers and RISC-V TCG crc32/crc32c/wfi helpers get an arch prefix so the combined link does not need meson -D name mangling. LoongArch virt_acpi_setup is renamed in the same pass. Target selection has to work with more than one TargetInfo: - The combined binary takes arch:name on -M/-machine and in a [machine] type (aarch64:virt). arch: binds the target. microblaze: runs that target's default machine. arm, aarch64, riscv32, and riscv64 have no default. No -M leaves target none and the empty none machine. qemu-system-$arch keeps the historic -M name. -M help lists every target; arch:help lists one. query-targets lists each linked target, including none. - TargetInfo is a constructor list. target_info_select() picks the entry, including SYS_EMU_TARGET_NONE. is_available takes const TargetInfo *. While the target is still none, QOM skips the unavailable filter so grouped -M help can list every machine. - query-cpu-definitions, dump notes, and Angel semihosting sit on TargetCpuOps indexed by target_arch(). Registration uses a QEMU_ARCH_* bitmask so one object can fill ARM and AARCH64. The table is target-ops.h / target-ops.c. qemu-system-$TARGET is still built, including the Windows *w twin. qemu-system is extra. It links each target whose arch sources are only target-info-def.c: arm, aarch64, riscv32, riscv64, and microblaze. Do not add qemu-systemw for that binary. A GUI twin would keep QEMU exporting data from the .exe into DLLs, and those data exports cannot be delay-loaded (qdev_prop_array and other qdev_prop_*). That would block enabling modules globally on Windows. Examples: qemu-system -M aarch64:virt ... qemu-system -M microblaze:petalogix-s3adsp1800 ... qemu-system-riscv64 -M virt ... A bare machine name on qemu-system needs an arch: prefix. An unknown target fails with "target '...' is not available". Prerequisites: [PATCH v2 0/9] machine: uniquify virt QOM names https://patchew.org/QEMU/20260922215533.641-1-luoyonggang@gmail.com/ [PATCH 00/21] accel/tcg: share raise_excp across TCG targets https://patchew.org/QEMU/20260918004225.827-1-luoyonggang@gmail.com/ [PATCH v5 00/11] single-binary: Compile hw/riscv once https://patchew.org/QEMU/20260918-hw-riscv-cpu-int-v5-0-f98c5a244636@rev.ng/ v1: https://patchew.org/QEMU/20260823150731.896-1-luoyonggang@gmail.com/ v2: https://patchew.org/QEMU/20260826184229.1145-1-luoyonggang@gmail.com/ branch: https://gitlab.com/lygstate-qemu/qemu/-/tree/single-binary-arm-riscv?ref_type=heads x86_64 and i386: https://gitlab.com/lygstate-qemu/qemu/-/tree/combined-binary-multi-targets?ref_type=heads Changes v2 -> v3: - Drop -target. v2 parsed a target_name token and required it on bare qemu-system, with -target ? to list names. v3 selects the target with arch:name on -M. No -M leaves target none. -M help and arch:help list machines. - Rebased onto current master. Upstream is_available(void) replaces TYPE_TARGET_SPECIFIC. v3 passes const TargetInfo * into is_available. The v2 patches that registered TYPE_TARGET_SPECIFIC on ARM and RISC-V virt are dropped. - TargetInfo is a constructor list, not chosen from argv[0]. target_info_select() sets the current entry. Add SysEmuTarget none. A single-target binary does not switch TargetInfo; arch: must match that binary or the machine is rejected. - Drop -Dsingle_binary. qemu-system is built from single_binary_supported_targets once arch_srcs are only target-info-def.c. microblaze joins ARM and RISC-V. Per-target binaries stay. Still no qemu-systemw for the combined binary. - Unique virt QOM names extend past ARM and RISC-V to or1k, hexagon, loongarch, m68k, and xtensa. query-machines returns MachineInfo typename. - TargetCpuOps is an array indexed by target_arch(), registered with a QEMU_ARCH_* bitmask. The header moves from target-info-qom.h to target-ops.h. - Those targets are compiled once: ARM, RISC-V, and MicroBlaze fold into common source sets, TARGET_* ifdefs become runtime checks, and KVM moves to system_ss. Pierrick Bouvier (2): configs/targets: remove target info definitions target-info: rename target-info-stub.c in target-info-def.c Yonggang Luo (112): meson: stale qemu-version.h only when .git exists target-info: rename target-info-impl.h to target-info-def.h target-info: set cpu_type from TARGET_BASE_ARCH target: remove CPU_RESOLVING_TYPE vl: parse early options before target-info init target-info: replace QOM registration with a constructor list tests/unit: add test-target-info tests/qtest: prepare machine-list-test for combined qemu-system kconfig: rename REGISTER to HW_REGISTER target-info: add TargetKconfig target-info: add target_is_* helpers for each architecture target-info: add i386 and x86_64 helpers qom: pass TargetInfo to is_available module: use static ModuleEntry and per-type DSO lists module: add before/after hooks and module_call_init_fn qom: register late types through module_call_init_fn qom: inherit is_available and filter after MODULE_INIT_QOM tests/unit: add module-init and qom is-available tests hw/arm/virt: prefix ACPI helpers with arm_virt_ hw/riscv/virt: prefix ACPI helpers with riscv_virt_ hw/loongarch/virt: prefix ACPI helper with loongarch_virt_ target/riscv: uniquify TCG crc32, crc32c, and wfi helper names hw/riscv: gate boards with target_is_base_riscv hw/intc: use target_long_bits in IMSIC geilen hw/misc/riscv_cmgcr: replace target_ulong with uint64_t hw/intc: use kvm_enabled() in APLIC AIA helpers hw/intc: send IMSIC MSI via kvm_irqchip_send_msi() target/riscv: add kvm stubs source set tcg: fix off-by-one in helper extend-free assert gdbstub: drop per-target cpu-param.h from helpers.h hw/riscv: expand boston-aia and microblaze-v-generic to TypeInfo target/riscv: Include migration/vmstate.h instead of migration/cpu.h in machine.c target/riscv: gate CPU types with TargetInfo target/riscv: select ELF dump class from target_riscv64 target/riscv: replace TARGET_* macros in CSR helpers target/riscv: use target_long_bits in pmpaddr granule checks target/riscv: preserve signed XLEN semantics without target_long target/riscv: replace leftover TARGET_LONG_BITS target/riscv: select monitor width at runtime target/riscv: replace target-width format macros target/riscv: replace TARGET_LONG_BITS in translate target-info: add tl_is_64() and target_is_tl32/64 helpers target-info: dispatch CPU QMP, dump, and Angel semihosting tcg: give TCGv its own type and runtime tl ops exec: allow target_long.h, abi_ptr.h and cpu-ldst.h from common code migration: add TargetInfo-gated vmstate fields target/i386: always compile XMM, YMMH, and Hi16 VMSD target/i386: replace VMSTATE_UINTTL with 32/64 TI fields target/ppc: replace VMSTATE_UINTTL with 32/64 TI fields target/sparc: replace VMSTATE_UINTTL with 32/64 TI fields target/mips: replace VMSTATE_UINTTL with 32/64 TI fields hw/hexagon: drop unused migration/cpu.h include migration: remove unused cpu.h target/riscv: gate KVM CPU VMSDs with target_has_kconfig_kvm target/riscv: use tcg_imm_tl in translate target/riscv: select FP and amocas width at runtime target/riscv: drop TARGET_RISCV XL shortcuts in translate target/riscv: select KVM host CPU width at runtime accel: use a shared TYPE_ACCEL_CPU parent kvm: always compile guest debug hw/i386: move APIC_DEFAULT_ADDRESS to apic.h kvm: stop including cpu.h from kvm.h kvm: default kvm_arch_reset_parked_vcpu in stubs kvm: drop COMPILING_PER_TARGET wrap around kvm_arch APIs kvm: add split irqchip and send_msi stubs kvm: replace TARGET_S390X and TARGET_PPC hints kvm: move kvm_ss to system_ss system: add qemu_host_arch() and reject unavailable -accel kvm: add AccelClass is_available for host/guest pairing hvf: add AccelClass is_available for host/guest pairing xen: add AccelClass is_available for host/guest pairing nitro: add AccelClass is_available for host/guest pairing mshv: add AccelClass is_available for host/guest pairing whpx: add AccelClass is_available for host/guest pairing target/i386/nvmm: add AccelClass is_available for host/guest pairing accel: replace ACCEL_CPU_NAME with accel_cpu_register_type whpx: move whpx_ss to system_ss hw/riscv: move boards and irqchip onto hw_common_arch target/riscv: include target_long.h in TCG helpers target/riscv: compile CPU and TCG once target/arm: replace target_long in A64 translate target/arm: use 64-bit TCG addresses in A64 translate target/arm: move kvm_arm_set_cpreg_mig_tolerances to kvm.c target/arm: allow -cpu host with Nitro target/arm: gate -cpu host with TypeIsAvailable target/arm: fix family-common KVM compile tests/qtest: raise aspeed_smc-test timeout to 12 minutes hw/intc: move ARM GIC kvm/hvf/whpx onto arm_common_ss target/arm: fold arm_ss into common source sets meson: link shared objects into qemu-system target/microblaze: fold system sources into common source sets meson: add microblaze-softmmu to the combined qemu-system list boards: remove unused DEFINE_MACHINE_WITH_INTERFACES hw/arm: set virt TypeInfo.is_available hw/arm: set remaining 32-bit machine TypeInfo.is_available hw/arm: set aarch64-only machine TypeInfo.is_available hw/microblaze: set petalogix-s3adsp1800 TypeInfo.is_available hw/arm: expand leftover 32-bit DEFINE_MACHINE to TypeInfo hw/arm: expand imx8mm-evk DEFINE_MACHINE to TypeInfo hw/microblaze: expand petalogix-ml605 and xlnx-zynqmp-pmu to TypeInfo hw/i386: set TYPE_X86_MACHINE TypeInfo.is_available hw/block/dataplane: move xen-block onto system_ss hw/remote: move multiprocess memory onto remote_ss hw/remote: set x-remote TypeInfo.is_available target-info: add SysEmuTarget none accel/tcg: tolerate NULL target_cpu_type for -M none qom: skip unavailable filter when target_none() module: load every arch-tagged module when target is none target-info: select combined qemu-system target by name vl: parse arch: machine types on combined qemu-system qapi: add query-targets tests/qtest: cover combined qemu-system machines and accel-cpu MAINTAINERS | 1 - accel/accel-common.c | 62 +- accel/hvf/hvf-all.c | 15 + accel/kvm/kvm-accel-ops.c | 4 - accel/kvm/kvm-all.c | 45 +- accel/kvm/meson.build | 2 +- accel/mshv/mshv-all.c | 8 + accel/nitro/nitro-accel.c | 8 + accel/stubs/kvm-stub.c | 11 + accel/tcg/tcg-all.c | 9 +- accel/whpx/meson.build | 2 +- accel/whpx/whpx-common.c | 32 +- accel/xen/xen-all.c | 18 + configs/targets/aarch64-softmmu.c | 25 - configs/targets/aarch64-softmmu.mak | 1 - configs/targets/arm-softmmu.c | 25 - configs/targets/i386-softmmu.mak | 2 - configs/targets/loongarch64-softmmu.mak | 1 - configs/targets/meson.build | 6 - configs/targets/ppc-softmmu.mak | 1 - configs/targets/ppc64-softmmu.mak | 1 - configs/targets/riscv32-softmmu.c | 24 - configs/targets/riscv64-softmmu.c | 24 - configs/targets/riscv64-softmmu.mak | 1 - configs/targets/s390x-softmmu.mak | 1 - configs/targets/x86_64-softmmu.mak | 2 - hw/Kconfig | 2 +- hw/arm/aspeed_ast1040_evb.c | 1 + hw/arm/aspeed_ast10x0_evb.c | 2 + hw/arm/aspeed_ast2400_palmetto.c | 1 + hw/arm/aspeed_ast2400_quanta-q71l.c | 1 + hw/arm/aspeed_ast2400_supermicrox11.c | 1 + hw/arm/aspeed_ast2500_evb.c | 1 + hw/arm/aspeed_ast2500_g220a.c | 1 + hw/arm/aspeed_ast2500_romulus.c | 1 + hw/arm/aspeed_ast2500_supermicro-x11spi.c | 1 + hw/arm/aspeed_ast2500_tiogapass.c | 1 + hw/arm/aspeed_ast2500_witherspoon.c | 1 + hw/arm/aspeed_ast2500_yosemitev2.c | 1 + hw/arm/aspeed_ast2600_anacapa.c | 1 + hw/arm/aspeed_ast2600_bletchley.c | 1 + hw/arm/aspeed_ast2600_catalina.c | 1 + hw/arm/aspeed_ast2600_evb.c | 1 + hw/arm/aspeed_ast2600_fby35.c | 1 + hw/arm/aspeed_ast2600_fuji.c | 1 + hw/arm/aspeed_ast2600_gb200nvl.c | 1 + hw/arm/aspeed_ast2600_rainier.c | 1 + hw/arm/aspeed_ast2600_sanmiguel.c | 1 + hw/arm/aspeed_ast27x0-fc.c | 2 +- hw/arm/aspeed_ast27x0_evb.c | 4 +- hw/arm/ax3000-evk.c | 1 + hw/arm/b-l475e-iot01a.c | 1 + hw/arm/bananapi_m2u.c | 22 +- hw/arm/collie.c | 1 + hw/arm/cubieboard.c | 23 +- hw/arm/digic_boards.c | 19 +- hw/arm/exynos4_boards.c | 2 + hw/arm/imx25_pdk.c | 19 +- hw/arm/imx8mm-evk.c | 23 +- hw/arm/imx8mp-evk.c | 1 + hw/arm/integratorcp.c | 23 +- hw/arm/kzm.c | 19 +- hw/arm/max78000fthr.c | 19 +- hw/arm/mcimx6ul-evk.c | 19 +- hw/arm/mcimx7d-sabre.c | 23 +- hw/arm/microbit.c | 1 + hw/arm/mps2-tz.c | 5 + hw/arm/mps2.c | 4 + hw/arm/mps3r.c | 1 + hw/arm/msf2-som.c | 19 +- hw/arm/musca.c | 2 + hw/arm/netduino2.c | 19 +- hw/arm/netduinoplus2.c | 19 +- hw/arm/npcm7xx_boards.c | 5 + hw/arm/npcm8xx_boards.c | 1 + hw/arm/olimex-stm32-h405.c | 19 +- hw/arm/omap_sx1.c | 2 + hw/arm/orangepi.c | 23 +- hw/arm/raspi.c | 7 +- hw/arm/raspi4b.c | 2 +- hw/arm/realview.c | 4 + hw/arm/sabrelite.c | 1 + hw/arm/sbsa-ref.c | 1 + hw/arm/stellaris.c | 2 + hw/arm/stm32vldiscovery.c | 19 +- hw/arm/versatilepb.c | 2 + hw/arm/vexpress.c | 2 + hw/arm/virt-acpi-build.c | 4 +- hw/arm/virt.c | 13 +- hw/arm/xen-pvh.c | 1 + hw/arm/xilinx_zynq.c | 1 + hw/arm/xlnx-versal-virt.c | 2 + hw/arm/xlnx-zcu102.c | 1 + hw/block/dataplane/meson.build | 2 +- hw/core/Kconfig | 2 +- hw/core/cpu-system.c | 23 + hw/core/machine-qmp-cmds.c | 57 + hw/core/meson.build | 2 +- hw/dma/Kconfig | 4 +- hw/hexagon/hexagon_dsp.c | 1 - hw/i2c/Kconfig | 2 +- hw/i386/acpi-common.c | 1 + hw/i386/sgx.c | 1 + hw/i386/vmport.c | 1 + hw/i386/x86.c | 2 + hw/intc/arm_gic_kvm.c | 1 + hw/intc/arm_gicv3_its_kvm.c | 1 + hw/intc/arm_gicv3_kvm.c | 1 + hw/intc/meson.build | 16 +- hw/intc/riscv_aplic.c | 14 +- hw/intc/riscv_imsic.c | 18 +- hw/intc/s390_flic.c | 1 + hw/intc/s390_flic_kvm.c | 1 + hw/loongarch/virt-acpi-build.c | 6 +- hw/loongarch/virt.c | 2 +- hw/microblaze/petalogix_ml605_mmu.c | 19 +- hw/microblaze/petalogix_s3adsp1800_mmu.c | 1 + hw/microblaze/xlnx-zynqmp-pmu.c | 19 +- hw/misc/meson.build | 4 +- hw/misc/riscv_cmgcr.c | 2 +- hw/remote/machine.c | 3 + hw/remote/meson.build | 4 +- hw/riscv/boston-aia.c | 4 +- hw/riscv/k230.c | 5 +- hw/riscv/microblaze-v-generic.c | 19 +- hw/riscv/microchip_pfsoc.c | 5 +- hw/riscv/opentitan.c | 5 +- hw/riscv/shakti_c.c | 5 +- hw/riscv/sifive_e.c | 1 + hw/riscv/sifive_u.c | 1 + hw/riscv/spike.c | 1 + hw/riscv/tt_atlantis.c | 5 +- hw/riscv/virt-acpi-build.c | 2 +- hw/riscv/virt.c | 7 +- hw/riscv/xiangshan_kmh.c | 5 +- hw/s390x/css.c | 1 + hw/s390x/s390-pci-bus.c | 1 + hw/s390x/s390-pci-inst.c | 1 + hw/s390x/virtio-ccw.c | 1 + hw/timer/meson.build | 2 +- hw/usb/Kconfig | 2 +- include/accel/accel-cpu-target.h | 31 - include/accel/accel-cpu.h | 13 + include/accel/tcg/cpu-ldst.h | 4 +- include/exec/abi_ptr.h | 7 +- include/exec/helper-head.h.inc | 21 +- include/exec/poison.h | 2 + include/exec/target_long.h | 13 + include/gdbstub/helpers.h | 3 - include/hw/arm/virt.h | 4 +- include/hw/core/boards.h | 10 +- include/hw/i386/apic.h | 3 + include/hw/loongarch/virt.h | 2 +- include/hw/riscv/virt.h | 4 +- include/migration/cpu.h | 30 - include/migration/vmstate.h | 125 ++ include/qemu/base-arch-defs.h | 9 + include/qemu/config-file.h | 2 + include/qemu/module.h | 41 +- include/qemu/queue.h | 10 + include/qemu/target-info-def.h | 90 ++ include/qemu/target-info-impl.h | 42 - include/qemu/target-info-init.h | 53 - include/qemu/target-info-qom.h | 30 - include/qemu/target-info-select.h | 24 + include/qemu/target-info.h | 214 +++- include/qemu/target-kconfig-has.h | 7 + include/qemu/target-kconfig.h | 34 + include/qemu/target-ops.h | 58 + include/qom/object.h | 27 +- include/semihosting/common-semi.h | 63 +- include/system/kvm.h | 23 +- include/system/kvm_int.h | 2 - include/tcg/tcg-op-common.h | 2 + include/tcg/tcg-op-gvec-common.h | 12 + include/tcg/tcg-op-gvec.h | 12 - include/tcg/tcg-op-mem.h | 96 +- include/tcg/tcg-op-tl.h | 1133 +++++++++++++++++ include/tcg/tcg-op.h | 293 +---- include/tcg/tcg.h | 42 +- meson.build | 221 +++- migration/savevm.c | 4 + migration/trace-events | 1 + migration/vmstate-types.c | 86 ++ migration/vmstate.c | 135 +- page-vary-common.c | 2 +- page-vary-system.c | 2 +- qapi/machine.json | 48 +- qemu-options.hx | 11 +- qom/object.c | 145 ++- rust/util/src/module.rs | 16 +- scripts/gen-target-kconfig.py | 162 +++ stubs/dump.c | 27 - stubs/kvm.c | 4 + stubs/meson.build | 3 +- stubs/qmp-cpu.c | 21 - stubs/target-info-select.c | 14 + system/arch_init.c | 19 + system/target-info-select.c | 26 + system/vl.c | 319 ++++- target-info-stub.c => target-info-def.c | 20 +- target-info-qom.c | 55 - target-info.c | 213 +++- target-kconfig.c | 20 + target-ops.c | 50 + target/alpha/cpu.h | 2 - target/arm/arch_dump.c | 8 +- target/arm/arm-qmp-cmds.c | 15 +- target/arm/common-semi-target.c | 26 +- target/arm/cpu.c | 6 +- target/arm/cpu.h | 3 +- target/arm/cpu64.c | 80 +- target/arm/hvf/hvf-stub.c | 14 + target/arm/hvf/meson.build | 1 + target/arm/kvm-stub.c | 5 + target/arm/kvm.c | 40 +- target/arm/kvm_arm.h | 9 + target/arm/meson.build | 11 +- target/arm/tcg/translate-a64.c | 6 +- target/arm/tcg/translate-a64.h | 3 + target/arm/tcg/translate-sme.c | 5 +- target/arm/tcg/translate-sve.c | 18 +- target/arm/whpx/whpx-all.c | 1 - target/arm/whpx/whpx-stub.c | 5 + target/avr/cpu.h | 2 - target/hexagon/common-semi-target.c | 26 +- target/hexagon/cpu.h | 1 - target/hppa/cpu.h | 2 - target/i386/arch_dump.c | 8 +- target/i386/cpu-qom.h | 1 + target/i386/cpu-system.c | 12 +- target/i386/cpu.c | 6 +- target/i386/cpu.h | 12 +- target/i386/hvf/hvf-cpu.c | 13 +- target/i386/kvm/kvm-cpu.c | 12 +- target/i386/kvm/kvm_i386.h | 2 + target/i386/kvm/xen-emu.c | 1 + target/i386/machine.c | 94 +- target/i386/mshv/mshv-cpu.c | 12 +- target/i386/nvmm/nvmm-all.c | 28 +- target/i386/tcg/tcg-cpu.c | 12 +- target/i386/whpx/whpx-all.c | 1 - target/loongarch/arch_dump.c | 8 +- target/loongarch/cpu.h | 2 - target/loongarch/kvm/kvm.c | 1 + target/loongarch/kvm/kvm_loongarch.h | 2 + target/loongarch/loongarch-qmp-cmds.c | 15 +- target/m68k/cpu.h | 2 - target/microblaze/cpu.h | 2 - target/microblaze/meson.build | 2 +- target/mips/cpu.h | 2 - target/mips/system/machine.c | 124 +- target/mips/system/mips-qmp-cmds.c | 15 +- target/none/cpu-param.h | 6 + target/none/cpu-qom.h | 6 + target/or1k/cpu-qom.h | 1 + target/or1k/cpu.h | 2 - target/ppc/arch_dump.c | 8 +- target/ppc/cpu-qom.h | 1 + target/ppc/cpu.h | 2 - target/ppc/cpu_init.c | 1 + target/ppc/kvm.c | 24 +- target/ppc/machine.c | 78 +- target/ppc/ppc-qmp-cmds.c | 15 +- target/riscv/arch_dump.c | 18 +- target/riscv/common-semi-target.c | 28 +- target/riscv/cpu.c | 133 +- target/riscv/cpu.h | 9 +- target/riscv/helper.h | 6 +- target/riscv/internals.h | 12 +- target/riscv/kvm/kvm-cpu.c | 115 +- target/riscv/kvm/kvm-stub.c | 33 +- target/riscv/kvm/meson.build | 2 +- target/riscv/machine.c | 16 +- target/riscv/meson.build | 18 +- target/riscv/monitor.c | 41 +- target/riscv/riscv-qmp-cmds.c | 15 +- target/riscv/tcg/bitmanip_helper.c | 14 +- target/riscv/tcg/cpu_helper.c | 53 +- target/riscv/tcg/crypto_helper.c | 1 + target/riscv/tcg/csr.c | 20 +- .../tcg/insn_trans/trans_privileged.c.inc | 2 +- target/riscv/tcg/insn_trans/trans_rvb.c.inc | 18 +- target/riscv/tcg/insn_trans/trans_rvd.c.inc | 18 +- target/riscv/tcg/insn_trans/trans_rvf.c.inc | 11 +- target/riscv/tcg/insn_trans/trans_rvi.c.inc | 12 +- target/riscv/tcg/insn_trans/trans_rvm.c.inc | 6 +- .../riscv/tcg/insn_trans/trans_rvzacas.c.inc | 32 +- target/riscv/tcg/insn_trans/trans_rvzfh.c.inc | 8 +- target/riscv/tcg/insn_trans/trans_xlrbr.c.inc | 4 +- .../riscv/tcg/insn_trans/trans_xthead.c.inc | 2 +- target/riscv/tcg/m128_helper.c | 3 +- target/riscv/tcg/meson.build | 8 +- target/riscv/tcg/op_helper.c | 2 +- target/riscv/tcg/pmp.c | 5 +- target/riscv/tcg/tcg-cpu.c | 13 +- target/riscv/tcg/translate.c | 123 +- target/riscv/tcg/vector_helper.c | 21 +- target/riscv/tcg/vector_internals.c | 2 +- target/riscv/tcg/vector_internals.h | 9 +- target/rx/cpu.h | 2 - target/s390x/arch_dump.c | 8 +- target/s390x/cpu-qom.h | 1 + target/s390x/cpu.h | 3 - target/s390x/cpu_models_system.c | 15 +- target/sh4/cpu-qom.h | 1 + target/sh4/cpu.h | 2 - target/sparc/cpu.h | 2 - target/sparc/machine.c | 24 +- target/tricore/cpu.h | 2 - target/xtensa/cpu.h | 2 - tcg/tcg.c | 42 +- tests/qtest/accel-cpu-qom-test.c | 82 ++ tests/qtest/fuzz/fuzz.c | 3 - tests/qtest/machine-list-combined-test.c | 111 ++ tests/qtest/machine-list-test.c | 94 ++ tests/qtest/machine-list-test.inc.h | 876 +++++++++++++ tests/qtest/machine-option-test.c | 714 +++++++++++ tests/qtest/meson.build | 31 +- tests/unit/check-qom-interface.c | 12 +- tests/unit/check-qom-proplist.c | 13 +- tests/unit/meson.build | 13 + tests/unit/test-io-channel-websock.c | 7 +- tests/unit/test-io-task.c | 7 +- tests/unit/test-module-init.c | 186 +++ tests/unit/test-qdev-global-props.c | 14 +- tests/unit/test-qdev.c | 8 +- tests/unit/test-qom-is-available.c | 250 ++++ tests/unit/test-ram-discard-manager.c | 7 +- tests/unit/test-target-info.c | 38 + tests/unit/test-target-kconfig-has.c | 22 + tests/unit/test-vmstate.c | 377 +++++- ui/console-vc.c | 13 +- ui/dbus.c | 8 +- ui/gtk.c | 10 +- ui/spice-app.c | 7 +- util/module.c | 171 ++- util/qemu-config.c | 10 +- 338 files changed, 8224 insertions(+), 1876 deletions(-) delete mode 100644 configs/targets/aarch64-softmmu.c delete mode 100644 configs/targets/arm-softmmu.c delete mode 100644 configs/targets/meson.build delete mode 100644 configs/targets/riscv32-softmmu.c delete mode 100644 configs/targets/riscv64-softmmu.c delete mode 100644 include/accel/accel-cpu-target.h delete mode 100644 include/migration/cpu.h create mode 100644 include/qemu/target-info-def.h delete mode 100644 include/qemu/target-info-impl.h delete mode 100644 include/qemu/target-info-init.h delete mode 100644 include/qemu/target-info-qom.h create mode 100644 include/qemu/target-info-select.h create mode 100644 include/qemu/target-kconfig-has.h create mode 100644 include/qemu/target-kconfig.h create mode 100644 include/qemu/target-ops.h create mode 100644 include/tcg/tcg-op-tl.h create mode 100644 scripts/gen-target-kconfig.py delete mode 100644 stubs/dump.c delete mode 100644 stubs/qmp-cpu.c create mode 100644 stubs/target-info-select.c create mode 100644 system/target-info-select.c rename target-info-stub.c => target-info-def.c (71%) delete mode 100644 target-info-qom.c create mode 100644 target-kconfig.c create mode 100644 target-ops.c create mode 100644 target/arm/hvf/hvf-stub.c create mode 100644 target/none/cpu-param.h create mode 100644 target/none/cpu-qom.h create mode 100644 tests/qtest/accel-cpu-qom-test.c create mode 100644 tests/qtest/machine-list-combined-test.c create mode 100644 tests/qtest/machine-list-test.c create mode 100644 tests/qtest/machine-list-test.inc.h create mode 100644 tests/qtest/machine-option-test.c create mode 100644 tests/unit/test-module-init.c create mode 100644 tests/unit/test-qom-is-available.c create mode 100644 tests/unit/test-target-info.c create mode 100644 tests/unit/test-target-kconfig-has.c -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430381.1652851 (Exim 4.92) (envelope-from ) id 1x9MrG-00062o-NP; Wed, 23 Sep 2026 13:17:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430381.1652851; Wed, 23 Sep 2026 13:17:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrG-00060x-Ev; Wed, 23 Sep 2026 13:17:58 +0000 Received: by outflank-mailman (input) for mailman id 1430381; Wed, 23 Sep 2026 13:17:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mqd-0005gL-Ua for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:17:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mqc-002EMY-Gf for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:17:18 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d155-bab6-0a2a0a5309dd-0a2a450aa10e-22 for ; Wed, 23 Sep 2026 15:17:18 +0200 Received: from [74.125.229.170] (helo=mail-dl2-f42.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d15c-f2d2-0a2a450a0019-4a7de5aa985e-3 for ; Wed, 23 Sep 2026 15:17:18 +0200 Received: by mail-dl2-f42.google.com with SMTP id a92af1059eb24-144f089b1e3so805630c88.2 for ; Wed, 23 Sep 2026 06:17:17 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.17.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:17:14 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169436; x=1790774236; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=t43puSbRZc523NBj9nQXSYWDHrWaj0cvHGn4qE6n+xk=; b=Jlmi46C+QX33iA7Q4P9o/yrrb4JJ2DxukUmCrRMj2zRJ45vsuSMrWiL3uaBOd+xpS9 PvJRE27tK3vzOs6IBkk3xpm5S/APSE4iGTkZ0HZ0CZpaDNU7DiF5Hl6/Gq0BjaS7cJf0 /U7WE/U7JDSD5NFv/bL3agfgz3DnX5iPTmblgTAiCoqwxUoXgMY7+QrDyuZOXruCeD2r kBLysrBUf1y3WO3EsA2RMSTdqz2Vo/p5wnlnCPjs15/eN+LXw1+0HtB3fOpu4hl8oofj uZdfSZ7MTBf/vozsAh3PoDkacfHGxlJ3yPpuq1jgtXkIxjfjYn4PxDDNVgBJe2lsvWcF x0DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169436; x=1790774236; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=t43puSbRZc523NBj9nQXSYWDHrWaj0cvHGn4qE6n+xk=; b=S9KCguvTccCyd5/eDbpFKSXWmfz/jYOpjQsLYmNrnZyg58uc2Ozo8Gi3wXZsQCTEl1 Up1ULSiFt5BboTJyBWUtVgasjjbokFsu52KbjNVpNAS3x7bMJUxPnfegTKMMwdG3VDZ1 E+htPi98/00ITSYEJH9pksYJEJVtJahYDLJWqZ+wtgrH+q1Ogj6OXh9O5u+F8beUGmaq oFcvPKlz+oCtSBHOLjsxXdaFhxei3td91XGlbv98Zz3SJY4+Vyy3U2m9PpFqJsAuZj3C +Vbi2FN3lyf/fWqVVd6k+Djnbf7V+PZWWzfFlLRjXhUtzDMp6wnaUnn0N1Gpmj9OzyAs nYIw== X-Forwarded-Encrypted: i=1; AKwUvBwIvQynt5ukeme1KcfcFDVAIGrvGCqpexxWALjyxkuNehrggHFeERZRPGMr8LoIFRj8WYtZ9WO/kbI=@lists.xenproject.org X-Gm-Message-State: AFuF++lElIB3coWsOGop4mXR3OuFNfY1vRtTqHXjEjPAJ2HTG6p9Gpo6 IxVqa3td2Gc7fYqW/AD5C5Fo50V5BCFGptLViDDZzlrk/zvpDpcefFRh X-Gm-Gg: AYBFou2IESWlTlrSmyOR3NBreRA4TFun0jkQLu2gZjRdfCF9nrbzx7RdSeFo3eFd4if yhNvHEJ7GnKCsPd5njafJz9wdUNrLoNYImj4VfRbmFy8eP8uiYqRp9VFglfVn1OqcX7qD3q2mcq hR+B3wejRBgh6ICJ4h8KmIXtV97J4hdMBV7a0i3yESUeWmEEJygKcsiI4YE65CjW9WYsX3w2Da6 D2CipUfRkaJ/Jn/0r7GCjsgaCAasCL1xDrH9EzAb+1NqDjwHfihTz1OSid98MSiV1WmnYGHKf0g FfwrnPFiIJzyjj5U+OqyP0r34gBngcRrh6emWIt3Ks3NGS5aFNkYTU2sU7UcaMrH4+N9Qe7L/Bf LeEgJzjajisABQQqnddc87QyXjHubpkpjBMENHdlAEl/QfJ4GPLrvmBLJEAM4o/8IBNp2lnv5aQ BJcCDr24Q7qqEBp1/A3LBRFtX/3xy/QdJC5/abqzl4xOFNFwzVibgLcLN6lHu0L7Esn12VKT3YD 27SVto7Z2phKnuJVyD5D8dwxifgK20= X-Received: by 2002:a05:7300:8818:b0:338:2485:ad03 with SMTP id 5a478bee46e88-33e8c53c0d4mr2821124eec.16.1790169436068; Wed, 23 Sep 2026 06:17:16 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 003/114] target-info: rename target-info-stub.c in target-info-def.c Date: Wed, 23 Sep 2026 21:14:37 +0800 Message-ID: <20260923131635.1894-4-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790169438-585CBCFC-A8BD492B/0/0 X-purgate-type: clean X-purgate-size: 1055 From: Pierrick Bouvier Now it's the only file left to define target info, we call it def to make the intent more clear. Signed-off-by: Pierrick Bouvier Signed-off-by: Yonggang Luo --- meson.build | 2 +- target-info-stub.c => target-info-def.c | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename target-info-stub.c => target-info-def.c (100%) diff --git a/meson.build b/meson.build index f412d917d94..8bd2d725ca0 100644 --- a/meson.build +++ b/meson.build @@ -4330,7 +4330,7 @@ foreach target : target_dirs endif endif - arch_srcs += files('target-info-stub.c') + arch_srcs += files('target-info-def.c') if target_base_arch in target_arch t = target_arch[target_base_arch].apply(config_target, strict: false) diff --git a/target-info-stub.c b/target-info-def.c similarity index 100% rename from target-info-stub.c rename to target-info-def.c -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430383.1652858 (Exim 4.92) (envelope-from ) id 1x9MrH-0006Ag-12; Wed, 23 Sep 2026 13:17:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430383.1652858; Wed, 23 Sep 2026 13:17:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrG-00068l-Pd; Wed, 23 Sep 2026 13:17:58 +0000 Received: by outflank-mailman (input) for mailman id 1430383; Wed, 23 Sep 2026 13:17:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mqn-0005hB-WE for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:17:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mqn-002EQZ-Cy for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:17:29 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d166-bab6-0a2a0a5309dd-0a2a4502a438-14 for ; Wed, 23 Sep 2026 15:17:29 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d167-6ca4-0a2a45020019-4a7de50cdafe-3 for ; Wed, 23 Sep 2026 15:17:28 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-3286624d194so643177eec.3 for ; Wed, 23 Sep 2026 06:17:28 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.17.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:17:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169447; x=1790774247; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=qkiRWh0yDSkP2OT8vLUxuaEaTt8B1WJVNLebJyYrgq0=; b=DXjGuOR3I7w+9pHSCd/ln/8Z6fbAAHJ0PmhX/r4DZvXn3gLidtjCpEHcQ6WNRKMlY5 Si0092R0P+kPCHf+aKzeTVJ+iXxl1NDLxB2SsHddFXOd1wmDndfvswrbib/f/R7tpekD 15yjP6O/9qqoPrY6Ydupjs/AtXPzZNoHSUf+tlBqWEUNUcCCYXHySxwAAu4P2gHOtlP4 Qci8gREYhpwqbaUibWEWy80NBHCE5IDgmC0fWh+WsScoNs2F2XrjVOmKex8HdTy5DEnc QyFnqnWGuoMTZUSFXpbA+3zWwiJBjsdqDhlfSKlM1+DdylEs8aoVSxzZcErZhcya6LYx 0X9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169447; x=1790774247; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=qkiRWh0yDSkP2OT8vLUxuaEaTt8B1WJVNLebJyYrgq0=; b=yIdste/PlkyU03Vho62xHe1Pn2iiUa5RmrnKJ3dUFU9+6Kqi+kXLrbHJPuiBviMzfC C465oIDoxkacAdhWL/fchPgcSiubxYh/UTtS8vdBaxcowEWByh8lfFZr/8Ht92REGMTq sA4eEbTT3xx5Inw4EtaAvt9mJ9FXN0mS6FfAxs7axnLV+3IpsypElArWQ1Xyd6eXxX41 Xj7qmaOf5/diVBiiWPEiB8OlQgNRNnjlDroC7CCx16/1UEfjiONiFR0bc3K4TDNJ0s0W 0hc0yVhqCO7TeJfP2PPqrdC0GukpOj9uffM+WKVsg01cdYvGSyOoRFwaJKEaIP8jbCDf rSwQ== X-Forwarded-Encrypted: i=1; AKwUvByuC2iL1AkLzfEBIw5ZsTrZcFgAVF6A+NzLo6ftI6qJvrde2y7odrwIgzLUuD1vxllM7IR9KzDYI0U=@lists.xenproject.org X-Gm-Message-State: AFuF++mPpAgoFa0r3yKPzTiLzNB9umvaWxzGJmBmg6oYWVFEEMyQai6A +/+oDmXwb7tVUvrvELo7ABiAP8sOJPfhQiWpLpmAv/tIBfvcL11hXiyr X-Gm-Gg: AYBFou1/Lpdx+dAJOe5bXOxF08gZzcPLDq3GZ0dxJT3qL2rFAvDQ+TPGKCDx3PU7avO HsIZShTuSJfjEYYgWK6zfikQAFSJC5nX1R+YcqH9uulbq1a08dmlGAznfhxOfXcH21aiHffZlqf M+1Uf4KxZm4vGS6zdG1NlTWcA0MvDyViKJ0w//sxUY6jHxp+GEykES8bM0ZYOyj+EfcvmTUZVp+ L4y3q/8qsTaZgh9KHLa2Wl4P8vZBYe513iYoSEXyi11E7fLmXV4icqSm4Ty2bIiU5Eyj0YMKymN DJCR7bnvO+MgthXkDb0spE8gYE2MLVKryJE1xL3gp76Oy+fcKklXbRWp5nYi7yhRfzDiWi2dUg0 78hRR1iTJaa1svULtO+XdwxH/WJgKZ307x1uCBQxpYh0I3c48fpV3EHmsyI4ui4YrZUGM7V2LU1 zB57MUH6Jp7EmtFBi+Ic5nMd0qJzWUITEcjdYfwP+AUS9CrtUcCrPnpev3aqjVN6FgmarALf8q0 B88o4x6tMOiS39aOYI6TjVFoitG3kk= X-Received: by 2002:a05:693c:228f:b0:33c:3134:1055 with SMTP id 5a478bee46e88-33e8c53b899mr2375553eec.12.1790169445480; Wed, 23 Sep 2026 06:17:25 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 004/114] target-info: rename target-info-impl.h to target-info-def.h Date: Wed, 23 Sep 2026 21:14:38 +0800 Message-ID: <20260923131635.1894-5-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790169448-F36BF2AC-7521B523/0/0 X-purgate-type: clean X-purgate-size: 3656 Rename the TargetInfo structure header and its include guard. Signed-off-by: Yonggang Luo --- include/qemu/{target-info-impl.h => target-info-def.h} | 4 ++-- include/qemu/target-info-qom.h | 2 +- page-vary-common.c | 2 +- page-vary-system.c | 2 +- target-info-def.c | 2 +- target-info-qom.c | 2 +- target-info.c | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) rename include/qemu/{target-info-impl.h => target-info-def.h} (94%) diff --git a/include/qemu/target-info-impl.h b/include/qemu/target-info-def.h similarity index 94% rename from include/qemu/target-info-impl.h rename to include/qemu/target-info-def.h index cf42aabbc8b..8019d2c7196 100644 --- a/include/qemu/target-info-impl.h +++ b/include/qemu/target-info-def.h @@ -6,8 +6,8 @@ * SPDX-License-Identifier: GPL-2.0-or-later */ -#ifndef QEMU_TARGET_INFO_IMPL_H -#define QEMU_TARGET_INFO_IMPL_H +#ifndef QEMU_TARGET_INFO_DEF_H +#define QEMU_TARGET_INFO_DEF_H #include "qapi/qapi-types-common.h" #include "qapi/qapi-types-machine.h" diff --git a/include/qemu/target-info-qom.h b/include/qemu/target-info-qom.h index 91be415ed33..0f6772e65c3 100644 --- a/include/qemu/target-info-qom.h +++ b/include/qemu/target-info-qom.h @@ -9,7 +9,7 @@ #ifndef QEMU_TARGET_INFO_QOM_H #define QEMU_TARGET_INFO_QOM_H -#include "qemu/target-info-impl.h" +#include "qemu/target-info-def.h" #include "qom/object.h" #define TYPE_TARGET_INFO "target-info" diff --git a/page-vary-common.c b/page-vary-common.c index ddd08633788..5a4654725a8 100644 --- a/page-vary-common.c +++ b/page-vary-common.c @@ -20,7 +20,7 @@ #define IN_PAGE_VARY 1 #include "qemu/osdep.h" -#include "qemu/target-info-impl.h" +#include "qemu/target-info-def.h" #include "exec/page-vary.h" /* WARNING: This file must *not* be complied with -flto. */ diff --git a/page-vary-system.c b/page-vary-system.c index 6c49c10e23b..9773685dc16 100644 --- a/page-vary-system.c +++ b/page-vary-system.c @@ -20,7 +20,7 @@ #include "qemu/osdep.h" #include "exec/page-vary.h" #include "exec/tlb-flags.h" -#include "qemu/target-info-impl.h" +#include "qemu/target-info-def.h" QEMU_BUILD_BUG_ON(TLB_FLAGS_MASK & ((1u < TARGET_PAGE_BITS_MIN) - 1)); diff --git a/target-info-def.c b/target-info-def.c index d121b8c0170..fa19cabc55f 100644 --- a/target-info-def.c +++ b/target-info-def.c @@ -8,7 +8,7 @@ #include "qemu/osdep.h" #include "qemu/target-info.h" -#include "qemu/target-info-impl.h" +#include "qemu/target-info-def.h" #include "qemu/target-info-init.h" #include "hw/core/boards.h" #include "cpu.h" diff --git a/target-info-qom.c b/target-info-qom.c index 6965e4d1169..2b38673a3f8 100644 --- a/target-info-qom.c +++ b/target-info-qom.c @@ -9,7 +9,7 @@ #include "qemu/osdep.h" #include "qapi/error.h" #include "qom/object.h" -#include "qemu/target-info-impl.h" +#include "qemu/target-info-def.h" #include "qemu/target-info-init.h" #include "qemu/target-info-qom.h" diff --git a/target-info.c b/target-info.c index bba4503151a..9abe72b1f55 100644 --- a/target-info.c +++ b/target-info.c @@ -9,7 +9,7 @@ #include "qemu/osdep.h" #include "qemu/target-info.h" #include "qemu/target-info-qapi.h" -#include "qemu/target-info-impl.h" +#include "qemu/target-info-def.h" #include "qapi/error.h" const char *target_name(void) -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430394.1652909 (Exim 4.92) (envelope-from ) id 1x9MrT-0007yQ-5b; Wed, 23 Sep 2026 13:18:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430394.1652909; Wed, 23 Sep 2026 13:18:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrT-0007yG-1c; Wed, 23 Sep 2026 13:18:11 +0000 Received: by outflank-mailman (input) for mailman id 1430394; Wed, 23 Sep 2026 13:18:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrR-0007sl-O6 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:18:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MrR-002Egu-4g for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:18:09 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d182-bab6-0a2a0a5309dd-0a2a45058594-46 for ; Wed, 23 Sep 2026 15:18:09 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d18d-4cb1-0a2a45050019-4a7de50cc6e5-3 for ; Wed, 23 Sep 2026 15:18:07 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664b752eso566980eec.1 for ; Wed, 23 Sep 2026 06:18:06 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.17.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:18:03 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169485; x=1790774285; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7lw/MEkkV81N3qqf95gz4M3o+mzY0GwXwXNmVRKHabY=; b=KuXQJ6H2763OpRuAu4JVU+9rEV3CJJ8pKwlTvzJ5PXjIGho3psfQMGE8cCXCmogXmM 44tuge8I15g0M2a+LR0Q93kPbjnnWHmBoRMy1pobS6SIWRVc3Bdv4lDBCoEtpca/ZDQv 8PeOjt3eu/fc6o+USDNaQdbV9zFEHSICcg9ha57kDYOfGOuT0Kno7kBG6gh22G6Ie8xP sdUxWhnlAOn8grX/WRvmZ3rRQ+dG/M8dFx11YbRV0faiOULwCpJCrVoOAWKpvDZkua+p 7gm7WRauUcESSSpW0ZpFvGYFeD8lxGGf0R2aDi1ORpcHtDxCc8eF+aPwCvGJjYL1LAbC 3PVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169485; x=1790774285; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=7lw/MEkkV81N3qqf95gz4M3o+mzY0GwXwXNmVRKHabY=; b=SYORyirCbh2fLHO7zrUx9gLKZyttL+H6Hg0vhpYY1SEHZ4Et2KqgMF1c4EtHEfHYoi XMxwDktUBPzkM/m4MHa0mbzXfqYJYa5D3H5XNShH7cKeyOHvFmOrkImNpcN532bDwqKU NslEg40x//1fG2Ve75fveT6QXW4abiXI2RCAuoSMRc1ZqJh6AeQpOhYtuRzd3SRiFaKy TeCub8/hqT2NbgFNRVN2G+mARP+wEPuelT0VWWdN2EyJid0ftit01HtFY59iBjIvMnm4 Dk5WELkwFz15VV6RymqELmuyKw4N8q9hx9RNmNESRRe2Jj1mlJLRdSYyYqhNoqHkeNxw nXzQ== X-Forwarded-Encrypted: i=1; AKwUvBwu3H7iKhcf+yHDPOEE0aL1aggou4PWIgFPnY331SPPXLyrXksBBDWzOrcB/LNWU3OwnF5ONFls+qo=@lists.xenproject.org X-Gm-Message-State: AFuF++l2J7YVIQABGAEe0HeBvPPVzwJ5TMzusYflqw5f/M6wmaQAq8G+ rCWTRHhqzP09tfCCMWqnEWL4x82feaYLermfn8lImJOJK5oYwzF8zCan X-Gm-Gg: AYBFou28jMqHlA9YdQnv5UC0bz4nwa3fr/JgOUoBWuxwahELgMSNXBNjtpBgsSwDLro uK29qH7LPByS3ZmrQy3vU0WwOCCMacvFHLYtLdM0r5ZBXIikuXjOPOBVeqP7HYQfXnndOddxTXQ OYGxvbl7c5oocq2OwRTww9S3uwMjdo2yd7MAFA73hMbX7+uK71tAmyny4GxSrGNoXdzm640OXMP vrgqiY/qWLDm/g0N4tok7zspX3BOuVvpItcOzO8tU0ShbsB292koo70sNrq0FwASRC9tJW0voaJ WBEpkqw26/ttID256rwX1qR2IJTybzDarpO8mrX0tm3oyZMXN4W77OME2ACULsVNkAfn/7av1j0 Akuly3hncQchEGqLNPD31k/xtx0wXE9+XaY69CdVqw8s/J0CMNj+MxV2Wvit77fDo+uFeA+NcK5 jeMkzLCxScY3UHJD0mZnxvirmDHzUarX4dJ+XI8BFhk/gHLuMVLWEdtIOkOSM0euPzskoJ3R4ou 3N+2KPn+0+FRFV547gyM6FEkD2X3PPa X-Received: by 2002:a05:693c:83c3:10b0:33b:e842:c0ff with SMTP id 5a478bee46e88-33e88b2f9cemr2522418eec.0.1790169484806; Wed, 23 Sep 2026 06:18:04 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 008/114] target-info: replace QOM registration with a constructor list Date: Wed, 23 Sep 2026 21:14:42 +0800 Message-ID: <20260923131635.1894-9-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790169487-F72B32A1-1075F3A1/0/0 X-purgate-type: clean X-purgate-size: 14113 Replace MODULE_INIT_TARGET_INFO and target_info_qom_set_target with a constructor list. target_info_init builds a TargetInfoNode; target_info_list_add inserts it, sorted by target_arch, before main(). target_info() starts as an "unknown" TargetInfo and target_info_select sets the current entry. target-info.c moves into libqom. Signed-off-by: Yonggang Luo --- include/qemu/module.h | 1 - include/qemu/target-info-def.h | 56 ++++++++++++++++++++++++++++++--- include/qemu/target-info-init.h | 53 ------------------------------- include/qemu/target-info-qom.h | 30 ------------------ include/qemu/target-info.h | 11 +++++++ meson.build | 6 ++-- system/vl.c | 4 --- target-info-def.c | 1 - target-info-qom.c | 55 -------------------------------- target-info.c | 56 ++++++++++++++++++++++++++++++++- tests/qtest/fuzz/fuzz.c | 3 -- 11 files changed, 120 insertions(+), 156 deletions(-) delete mode 100644 include/qemu/target-info-init.h delete mode 100644 include/qemu/target-info-qom.h delete mode 100644 target-info-qom.c diff --git a/include/qemu/module.h b/include/qemu/module.h index fccf017bf9e..9885ac9afb3 100644 --- a/include/qemu/module.h +++ b/include/qemu/module.h @@ -43,7 +43,6 @@ typedef enum { MODULE_INIT_MIGRATION, MODULE_INIT_BLOCK, MODULE_INIT_OPTS, - MODULE_INIT_TARGET_INFO, MODULE_INIT_QOM, MODULE_INIT_TRACE, MODULE_INIT_XEN_BACKEND, diff --git a/include/qemu/target-info-def.h b/include/qemu/target-info-def.h index ebd88463aea..25dc7c508d3 100644 --- a/include/qemu/target-info-def.h +++ b/include/qemu/target-info-def.h @@ -11,8 +11,10 @@ #include "qapi/qapi-types-common.h" #include "qapi/qapi-types-machine.h" +#include "qemu/queue.h" +#include "qemu/target-info.h" -typedef struct TargetInfo { +struct TargetInfo { /* runtime equivalent of TARGET_NAME definition */ const char *target_name; /* related to TARGET_ARCH definition */ @@ -30,13 +32,57 @@ typedef struct TargetInfo { unsigned page_bits_init; /* runtime equivalent of TARGET_PAGE_BITS_VARY definition */ bool page_bits_vary; -} TargetInfo; +}; + +typedef struct TargetInfoNode TargetInfoNode; +typedef QLIST_HEAD(, TargetInfoNode) TargetInfoList; + +struct TargetInfoNode { + const TargetInfo *info; + QLIST_ENTRY(TargetInfoNode) next; +}; + +/** + * target_info_list: + * + * TargetInfo is a static list, not a QOM type. Constructors insert + * entries before main(), so type_init can use it. + * + * Returns: registered TargetInfoNode list head, sorted by + * info->target_arch. The list is owned by target-info + * and must not be modified. Iterate with + * QLIST_FOREACH(..., next) and use node->info. + */ +const TargetInfoList *target_info_list(void); /** - * target_info: + * target_info_select: + * @ti: TargetInfo to make current * - * Returns: The TargetInfo structure definition for this target binary. + * Sets target_info() to @ti. + */ +void target_info_select(const TargetInfo *ti); + +/** + * target_info_list_add: + * @node: static TargetInfoNode whose info points at a const TargetInfo + * + * Inserts @node into target_info_list(), sorted by info->target_arch. + * Sets target_info() to the first list entry. + */ +void target_info_list_add(TargetInfoNode *node); + +/* + * Register @ti before main(). Linked into the executable, not a DSO. + * @ti is a unique identifier in this translation unit. */ -const TargetInfo *target_info(void); +#define target_info_init(ti) \ + static TargetInfoNode ti##_node = { \ + .info = &(ti), \ + }; \ + static void __attribute__((constructor)) do_qemu_init_##ti(void) \ + { \ + target_info_list_add(&ti##_node); \ + } #endif diff --git a/include/qemu/target-info-init.h b/include/qemu/target-info-init.h deleted file mode 100644 index b7024c9faef..00000000000 --- a/include/qemu/target-info-init.h +++ /dev/null @@ -1,53 +0,0 @@ -/* - * QEMU target info initialization - * - * Copyright (c) Qualcomm - * - * SPDX-License-Identifier: GPL-2.0-or-later - * - * This file is included by each file defining a TargetInfo structure and is - * responsible for registering it. - */ - -#ifndef QEMU_TARGET_INFO_INIT_H -#define QEMU_TARGET_INFO_INIT_H - -#define DEFINE_TARGET_INFO_TYPE(info) \ -static void do_qemu_init_target_info(void) \ -{ \ - type_register_static(&info); \ -} \ -module_init(do_qemu_init_target_info, MODULE_INIT_TARGET_INFO) - -#ifdef COMPILING_PER_TARGET -#ifdef CONFIG_USER_ONLY - -/* - * User mode does not support multiple targets in the same binary, so just - * define target_info(). - */ -#define target_info_init(ti_var) \ -const TargetInfo *target_info(void) \ -{ \ - return &ti_var; \ -} - -#else /* CONFIG_USER_ONLY */ - -#include "qemu/target-info-qom.h" -#include "qom/object.h" - -#define target_info_init(ti_var) \ -static const TypeInfo target_info_qom_target_type_info = { \ - .name = TYPE_TARGET_INFO"-"TARGET_NAME, \ - .parent = TYPE_TARGET_INFO, \ - .instance_size = sizeof(TargetInfoQom), \ - .class_size = sizeof(TargetInfoQomClass), \ - .class_data = &ti_var, \ -}; \ -DEFINE_TARGET_INFO_TYPE(target_info_qom_target_type_info) - -#endif /* CONFIG_USER_ONLY */ -#endif /* COMPILING_PER_TARGET */ - -#endif /* QEMU_TARGET_INFO_INIT_H */ diff --git a/include/qemu/target-info-qom.h b/include/qemu/target-info-qom.h deleted file mode 100644 index 0f6772e65c3..00000000000 --- a/include/qemu/target-info-qom.h +++ /dev/null @@ -1,30 +0,0 @@ -/* - * QEMU target info QOM types - * - * Copyright (c) Qualcomm - * - * SPDX-License-Identifier: GPL-2.0-or-later - */ - -#ifndef QEMU_TARGET_INFO_QOM_H -#define QEMU_TARGET_INFO_QOM_H - -#include "qemu/target-info-def.h" -#include "qom/object.h" - -#define TYPE_TARGET_INFO "target-info" - -typedef struct TargetInfoQom { - Object parent_obj; -} TargetInfoQom; - -typedef struct TargetInfoQomClass { - ObjectClass parent_class; - const TargetInfo *target_info; -} TargetInfoQomClass; - -OBJECT_DECLARE_TYPE(TargetInfoQom, TargetInfoQomClass, TARGET_INFO) - -void target_info_qom_set_target(void); - -#endif /* QEMU_TARGET_INFO_QOM_H */ diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h index c09e5d2a3ec..c48973f20be 100644 --- a/include/qemu/target-info.h +++ b/include/qemu/target-info.h @@ -9,6 +9,17 @@ #ifndef QEMU_TARGET_INFO_H #define QEMU_TARGET_INFO_H +#include + +typedef struct TargetInfo TargetInfo; + +/** + * target_info: + * + * Returns: The TargetInfo structure definition for the selected target. + */ +const TargetInfo *target_info(void); + /** * target_name: * diff --git a/meson.build b/meson.build index 20345860c9f..9a6a80fd0c8 100644 --- a/meson.build +++ b/meson.build @@ -3777,6 +3777,9 @@ if enable_modules modulecommon = declare_dependency(objects: libmodulecommon.extract_all_objects(recursive: false), compile_args: '-DBUILD_DSO') endif +qom_ss.add(files( + 'target-info.c', +)) qom_ss = qom_ss.apply({}) libqom = static_library('qom', qom_ss.sources() + genh, dependencies: [qom_ss.dependencies()], @@ -3871,9 +3874,6 @@ endif common_ss.add(pagevary) system_ss.add(files('page-vary-system.c')) -common_ss.add(files('target-info.c')) -system_ss.add(files('target-info-qom.c')) - if 'CONFIG_TCG' in config_all_accel subdir('contrib/plugins') endif diff --git a/system/vl.c b/system/vl.c index dc883de8274..37cb4838188 100644 --- a/system/vl.c +++ b/system/vl.c @@ -28,7 +28,6 @@ #include "qemu/units.h" #include "qemu/module.h" #include "qemu/target-info.h" -#include "qemu/target-info-qom.h" #include "exec/cpu-common.h" #include "exec/page-vary.h" #include "hw/core/qdev-properties.h" @@ -2930,9 +2929,6 @@ void qemu_init(int argc, char **argv) os_setup_limits(); - module_call_init(MODULE_INIT_TARGET_INFO); - target_info_qom_set_target(); - module_init_info(qemu_modinfo); module_allow_arch(target_name()); diff --git a/target-info-def.c b/target-info-def.c index f167f5f2ac1..954298b56d0 100644 --- a/target-info-def.c +++ b/target-info-def.c @@ -9,7 +9,6 @@ #include "qemu/osdep.h" #include "qemu/target-info.h" #include "qemu/target-info-def.h" -#include "qemu/target-info-init.h" #include "cpu-qom.h" #include "cpu-param.h" #include "exec/page-vary.h" diff --git a/target-info-qom.c b/target-info-qom.c deleted file mode 100644 index 2b38673a3f8..00000000000 --- a/target-info-qom.c +++ /dev/null @@ -1,55 +0,0 @@ -/* - * QEMU binary/target API (QOM types) - * - * Copyright (c) Linaro - * - * SPDX-License-Identifier: GPL-2.0-or-later - */ - -#include "qemu/osdep.h" -#include "qapi/error.h" -#include "qom/object.h" -#include "qemu/target-info-def.h" -#include "qemu/target-info-init.h" -#include "qemu/target-info-qom.h" - -static void target_info_qom_class_init(ObjectClass *oc, const void * data) -{ - TargetInfoQomClass *klass = TARGET_INFO_CLASS(oc); - klass->target_info = data; -} - -static const TypeInfo target_info_parent_type = { - .name = TYPE_TARGET_INFO, - .parent = TYPE_OBJECT, - .instance_size = sizeof(TargetInfoQom), - .class_size = sizeof(TargetInfoQomClass), - /* use class_base_init so children classes can set class_data accordingly */ - .class_base_init = target_info_qom_class_init, - /* children classes will be concrete, which allows to easily query them - * without listing this parent class also */ - .abstract = true, -}; - -DEFINE_TARGET_INFO_TYPE(target_info_parent_type) - -static const TargetInfo *target_info_ptr; - -const TargetInfo *target_info(void) -{ - return target_info_ptr; -} - -void target_info_qom_set_target(void) -{ - g_autoptr(GSList) targets = object_class_get_list(TYPE_TARGET_INFO, false); - - size_t num_found = g_slist_length(targets); - if (num_found != 1) { - error_setg(&error_fatal, num_found == 0 ? - "no target-info is available" : - "more than one target-info is available"); - } - - target_info_ptr = TARGET_INFO_CLASS(targets->data)->target_info; -} diff --git a/target-info.c b/target-info.c index 9abe72b1f55..6e66f48e1ff 100644 --- a/target-info.c +++ b/target-info.c @@ -10,7 +10,61 @@ #include "qemu/target-info.h" #include "qemu/target-info-qapi.h" #include "qemu/target-info-def.h" -#include "qapi/error.h" +#include "exec/page-vary.h" + +static const TargetInfo target_info_default = { + .target_arch = SYS_EMU_TARGET__MAX, + .target_name = "unknown", + .long_bits = 64, + .endianness = ENDIAN_MODE_LITTLE, + .page_bits_init = TARGET_PAGE_BITS_MIN, +}; + +static const TargetInfo *target_info_ptr = &target_info_default; +static TargetInfoList target_infos = QLIST_HEAD_INITIALIZER(target_infos); + +const TargetInfo *target_info(void) +{ + g_assert(target_info_ptr != NULL); + return target_info_ptr; +} + +const TargetInfoList *target_info_list(void) +{ + return &target_infos; +} + +void target_info_select(const TargetInfo *ti) +{ + g_assert(ti != NULL); + target_info_ptr = ti; +} + +void target_info_list_add(TargetInfoNode *node) +{ + const TargetInfo *info; + TargetInfoNode *cur, *prev = NULL; + + g_assert(node && node->info); + info = node->info; + QLIST_FOREACH(cur, &target_infos, next) { + if (info->target_arch < cur->info->target_arch) { + QLIST_INSERT_BEFORE(cur, node, next); + break; + } + prev = cur; + } + if (!cur) { + if (prev) { + QLIST_INSERT_AFTER(prev, node, next); + } else { + QLIST_INSERT_HEAD(&target_infos, node, next); + } + } + + /* Single-target default: the first list entry. */ + target_info_select(QLIST_FIRST(&target_infos)->info); +} const char *target_name(void) { diff --git a/tests/qtest/fuzz/fuzz.c b/tests/qtest/fuzz/fuzz.c index a3a131c80f8..d2355989616 100644 --- a/tests/qtest/fuzz/fuzz.c +++ b/tests/qtest/fuzz/fuzz.c @@ -22,7 +22,6 @@ #include "system/runstate.h" #include "qemu/main-loop.h" #include "qemu/rcu.h" -#include "qemu/target-info-qom.h" #include "tests/qtest/libqtest.h" #include "tests/qtest/libqos/qgraph.h" #include "fuzz.h" @@ -173,8 +172,6 @@ int LLVMFuzzerInitialize(int *argc, char ***argv, char ***envp) /* Initialize qgraph and modules */ qos_graph_init(); - module_call_init(MODULE_INIT_TARGET_INFO); - target_info_qom_set_target(); module_call_init(MODULE_INIT_FUZZ_TARGET); module_call_init(MODULE_INIT_QOM); module_call_init(MODULE_INIT_LIBQOS); -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430389.1652879 (Exim 4.92) (envelope-from ) id 1x9MrI-0006jT-F7; Wed, 23 Sep 2026 13:18:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430389.1652879; Wed, 23 Sep 2026 13:18:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrI-0006hs-8P; Wed, 23 Sep 2026 13:18:00 +0000 Received: by outflank-mailman (input) for mailman id 1430389; Wed, 23 Sep 2026 13:17:59 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MrH-0006BM-5r for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:17:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MrG-002Egu-HM for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:17:58 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d182-bab6-0a2a0a5309dd-0a2a45058594-18 for ; Wed, 23 Sep 2026 15:17:58 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d184-4cb1-0a2a45050019-4a7de52b9ad1-3 for ; Wed, 23 Sep 2026 15:17:58 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-33c3735125bso408413eec.3 for ; Wed, 23 Sep 2026 06:17:57 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.17.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:17:52 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169476; x=1790774276; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sKNecRa3tzG6HeYVTRQDuQ00e5AIYSJOroCNurGi9rk=; b=H0JlBJJYkvkW+KZtx2h0u5kby9hMxg82p4aDXBOEt9UuiUSia5z6TvjgFTHK19dRfV JBzR71J8YdoYjh/XlPumInXMjXJiYGEGu+MHWWR3Uhc55ejyLvQEAm6SG/BFw27WaFSW rUT2bkqhlWOKqe51o7aUSgPuF7818dc7m8SfEmjudJHEpZNjhVLia+/gGbrlSvqE9AYU Ux2b5ahblOsbZtjElWi8DDWDNMWUwkFmz1RdBT2pvQgnyAzc3e9z5sDYJvEw4GC2vD8C Hy+YJBeNZl5Wvvvn4reXEzAaTKDAjHP3waX9BF+QzwCgrWcuunN4f9HEXPV+3zuQIvXG oNEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169476; x=1790774276; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=sKNecRa3tzG6HeYVTRQDuQ00e5AIYSJOroCNurGi9rk=; b=LDwuPgW4qmXihMUHmBdCuZ6MUWXoeLln9jm8EijdJOTIuxOJdSuIfZrLngS23ZHt/e jxRKUoK54y+iRLQo3TbKJZjhYcfg5cPM7b7GVnZbzYZirAj3UjIg1Jt2oZ9Ch6tZ4aTk T4cxVF/ShVp7sDIIDDbnnv8BMvEl8rdA5rkWba2JN5lS8tJUVXrmzse/UF4h2+GUcVtW NA7e55dCeKPMiaxw3c5P/B5EOfGVg+zukweh4vXVF16dY7hevkWRl8KkPMVFrg2sAj4U EelQNwCQMgrdgpjrs1ZOkOsJOfOEyktcZGrpinLSuwj1Zxdgu95vXzbV0XPzTqeMDy9I H5nw== X-Forwarded-Encrypted: i=1; AKwUvBy6mzXZ35n6ELaxvT/qSu74RMkBzB6cheCfuhqBZ2ZOIckPWXs69czdfOGo1tVLFz/GnKDM9A5i8SU=@lists.xenproject.org X-Gm-Message-State: AFuF++lRIBM4kr+PBoz1ADlslowtza9gLuU9Rk5O1vLQYOC9EZ0xFDE0 s3h4n3M3Nvm+iGo56m2pIqddk2ofBGCe1cGle/zwLukGRq7eCw8RgPtd X-Gm-Gg: AYBFou2GysTxb8Hw+qGS7mzciviAQXF7VjHKRDX1wYdMGzpPUCQtLd6zxbEYQ7NdQAS AmAZoq/KdBI912zAELXdzHD0zgZI9+JHbC0n29xdjJ0hno6DzA6btOzHhD4mMs6tFs0AJj5yZpr t45kcs10G2OZUr2Bs7aXTkKLp2H/dQmJ/taWIMRqA04aSkvtqxtJoh7Uo0fxvG+baUnUJ/uCQnb Oe363eRhJolmBCL/JChO6uo+PuiHBZLMDExWSvFfL9LzJLhTiWBcKQk1NjAUp1PsnNp6ZYXgHvo YiVvLCnNAxf+nUCPmPA4akxgB3zCNspYW2054K9AgJE2OF5G/8yWLpzRI77zMTJ8JPcpM3UoDzG i7ypf6Kq8W6EMTE/Mi+kJ1ycXG4kv4100gt3XFjod0efCxCdoXhE5UrzRsA5LIguA00iQHKMnOP oDmXD143xXkwgs4IWpIaM3AxEh0QG252k/hlGLdu71qrCrabqEHGV6yEaw8ZVBw0163eJPLfJuW iPPsCYe2AfhRoMb9DpTEmIKrCeZjok= X-Received: by 2002:a05:7301:db0c:b0:33b:96b8:3818 with SMTP id 5a478bee46e88-33e8ddbe14cmr1954620eec.32.1790169475447; Wed, 23 Sep 2026 06:17:55 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 007/114] vl: parse early options before target-info init Date: Wed, 23 Sep 2026 21:14:41 +0800 Message-ID: <20260923131635.1894-8-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790169478-F74BC2A1-949A6469/0/0 X-purgate-type: clean X-purgate-size: 1312 Move the first argv pass ahead of MODULE_INIT_TARGET_INFO so later target-info selection can use command-line options before QOM init. Signed-off-by: Yonggang Luo --- system/vl.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/system/vl.c b/system/vl.c index 0d52c5d0a46..dc883de8274 100644 --- a/system/vl.c +++ b/system/vl.c @@ -2910,16 +2910,6 @@ void qemu_init(int argc, char **argv) error_init(argv[0]); qemu_init_exec_dir(argv[0]); - os_setup_limits(); - - module_call_init(MODULE_INIT_TARGET_INFO); - target_info_qom_set_target(); - - module_init_info(qemu_modinfo); - module_allow_arch(target_name()); - - qemu_init_subsystems(); - /* first pass of option parsing */ optind = 1; while (optind < argc) { @@ -2938,6 +2928,16 @@ void qemu_init(int argc, char **argv) } } + os_setup_limits(); + + module_call_init(MODULE_INIT_TARGET_INFO); + target_info_qom_set_target(); + + module_init_info(qemu_modinfo); + module_allow_arch(target_name()); + + qemu_init_subsystems(); + machine_opts_dict = qdict_new(); if (userconfig) { qemu_read_default_config_file(&error_fatal); -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430415.1652917 (Exim 4.92) (envelope-from ) id 1x9Mrl-0000ww-Eg; Wed, 23 Sep 2026 13:18:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430415.1652917; Wed, 23 Sep 2026 13:18:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mrl-0000wO-BX; Wed, 23 Sep 2026 13:18:29 +0000 Received: by outflank-mailman (input) for mailman id 1430415; Wed, 23 Sep 2026 13:18:28 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mrk-0000qi-JD for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:18:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mrj-00BPR0-WF for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:18:28 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d196-e002-0a2a0a5209dd-0a2a4509cd0a-40 for ; Wed, 23 Sep 2026 15:18:27 +0200 Received: from [74.125.229.170] (helo=mail-dl2-f42.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d19e-be1a-0a2a45090019-4a7de5aab093-3 for ; Wed, 23 Sep 2026 15:18:24 +0200 Received: by mail-dl2-f42.google.com with SMTP id a92af1059eb24-144df39b6cfso669980c88.1 for ; Wed, 23 Sep 2026 06:18:23 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.18.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:18:12 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169502; x=1790774302; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=yqkLIHs8nht5THiWcj2P453LN93rHp/TnF9wI3rp1V4=; b=IZTi+iUqgq2UzgTCIfTNo53ZA8cS+pSLDrThfPnF1Jp0aeoUgqbudlXceH+so0mATG ApfwhCo9jXzJhii0csXAYjNh68Y8FAqRAO38q+R/W075y6SBpfnnkmRlsaCALghqv+0m LuKPTAHe1rAkyjs2HQn3dkABWlrOt6e5XCI5EIQN05NmnMh70S0n8sQSoCTHbiXJnkKK LfidcI5+EvxJHW6QhVNChcjsr4VSqVMu0Il/jI7q/ewYoW2hyLdxC3ELfKUxXssFxymL xmJXUfjPjBhp2gJoJJJ5XWGLlay37BBk5Av3wdBsTRhFe9c2qPAOL7MA8NGE1DaTQ4o/ 9Uww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169502; x=1790774302; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=yqkLIHs8nht5THiWcj2P453LN93rHp/TnF9wI3rp1V4=; b=erLIeOawmRgXCjaKyXSgpnnOqge5oagAt1H0KmwVxs/CqmToiXgtjwl039kFNY6vN0 fLRUXYKvgceb3+FDEa7r7j8XbdnMywy6VAvL3n0pDvokO7WVDdFl5RwGkupsondAphZ+ Bf0bqYRDN6kFg9K5jIqXV4xIUlIiGFQGdn3uhZvKB7JC/mNM8TPbzKplJ+Wjtt7ShvC2 rhA2p3BvcirW7t/pEJ+vX/AmsdtqIHNcrx7MkNitCamVWy3BFaJaCYfNNDQBNxEIruGs aCh1/p0StgQvvIEtD1JdvoTAsXaxL299rGxb2qLN1FwMTRPjGZ5I5j9bdxfcg3x5syg1 MSuQ== X-Forwarded-Encrypted: i=1; AKwUvBwppuoJNJJGS3YeQY+kfjPc7w27qrKCe3sZP3J1CCzKpGYJT4DnAL4Bo/UTkwR1yXXtMQPB7IDNVV0=@lists.xenproject.org X-Gm-Message-State: AFuF++nuWjmgb9RCM07FCr3B8GxeZiVGvpHPx8jMKuO5iaHJPqkviV/I qef5JHAtS3am1l6wmqABQx2+BwSpihZjpLLcHICi3vvoDo8FMmb9cyUy X-Gm-Gg: AYBFou3QUIUf0g4GR7Qo36EdCaId8kwGmPpNtArfpCYc1FwBFmFQ8L7myuykNSnzupm 1XdbznjKjrC7+a3wVcle896QvxVUWB2Y0G7Eu4cmIz3GOlxvDQrhQYBcbQHcPYXOx3ciRQZ4LX1 gnfKkeJNKfMg9dy47gwWNlMfOSeHANDz/3QmuTf2BnFs2OaM19m4OskUDs9AHCLgKUlyiGE0M11 dqPkDatp+P5NFA3L5n+OvldVYunLT2vLsFP2KSfLFHj43dsrHSiMJWrEMyqC0ouEBdWeldYVSYM iYA4aUR4PRSfExLDsyVvGNrm7fOKWjon/cyhcLKKDWOFaZdwSBWLIR/twsn4biwr6g8vV3q3eYg nq21J1KGvQsr16fA+oMF74HtLzCt2fv90fNXBYV9OjTrCQBt1mcA2u76wC/RBKZmZOWsAkbE0xd B+RkFO5c8pk/4oUwKS0JeRs2AsW2ekl/THz7NHQEQC04yG+VK2Sf588ll7dYacD0V50m4vKqxOS NRseajLahHCP86OGhGGCntF3dpnvPOpR6YUpo1i/w== X-Received: by 2002:a05:7022:fa9:b0:143:2719:a501 with SMTP id a92af1059eb24-144f9173969mr4195539c88.40.1790169493859; Wed, 23 Sep 2026 06:18:13 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 009/114] tests/unit: add test-target-info Date: Wed, 23 Sep 2026 21:14:43 +0800 Message-ID: <20260923131635.1894-10-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1790169504-3B0DD034-5014A523/0/0 X-purgate-type: clean X-purgate-size: 3224 Collect each target-info-def.c object in target_info_def_objects, keyed by target dir. Link every value so constructors fill the list. Assert target_info() is not NULL and target_info_list() has one entry per linked object. Signed-off-by: Yonggang Luo --- meson.build | 6 +++++- tests/unit/meson.build | 4 ++++ tests/unit/test-target-info.c | 38 +++++++++++++++++++++++++++++++++++ 3 files changed, 47 insertions(+), 1 deletion(-) create mode 100644 tests/unit/test-target-info.c diff --git a/meson.build b/meson.build index 9a6a80fd0c8..776d38c5afd 100644 --- a/meson.build +++ b/meson.build @@ -4260,6 +4260,8 @@ endif traceable = [] emulators = {} +target_info_def = files('target-info-def.c') +target_info_def_objects = {} foreach target : target_dirs config_target = config_target_mak[target] target_name = config_target['TARGET_NAME'] @@ -4331,7 +4333,7 @@ foreach target : target_dirs endif endif - arch_srcs += files('target-info-def.c') + arch_srcs += target_info_def if target_base_arch in target_arch t = target_arch[target_base_arch].apply(config_target, strict: false) @@ -4409,6 +4411,8 @@ foreach target : target_dirs c_args: c_args, build_by_default: false) + target_info_def_objects += {target: lib.extract_objects(target_info_def)} + if target.endswith('-softmmu') execs = [{ 'name': 'qemu-system-' + target_name, diff --git a/tests/unit/meson.build b/tests/unit/meson.build index e47bc7225ab..dc980a35955 100644 --- a/tests/unit/meson.build +++ b/tests/unit/meson.build @@ -43,6 +43,10 @@ tests = { 'test-qgraph': ['../qtest/libqos/qgraph.c'], 'check-qom-interface': [qom], 'check-qom-proplist': [qom], + 'test-target-info': [qom, declare_dependency( + objects: target_info_def_objects.values(), + compile_args: ['-DTARGET_INFO_DEF_COUNT=@0@'.format( + target_info_def_objects.values().length())])], 'test-qemu-opts': [], 'test-keyval': [testqapi], 'test-logging': [], diff --git a/tests/unit/test-target-info.c b/tests/unit/test-target-info.c new file mode 100644 index 00000000000..e6de9b259e8 --- /dev/null +++ b/tests/unit/test-target-info.c @@ -0,0 +1,38 @@ +/* + * TargetInfo unit tests + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qemu/target-info.h" +#include "qemu/target-info-def.h" + +static int target_info_list_count(void) +{ + TargetInfoNode *node; + int n = 0; + + QLIST_FOREACH(node, target_info_list(), next) { + n++; + } + return n; +} + +static void test_target_info_not_null(void) +{ + g_assert_nonnull(target_info()); +} + +static void test_target_info_list_count(void) +{ + g_assert_cmpint(target_info_list_count(), ==, TARGET_INFO_DEF_COUNT); +} + +int main(int argc, char **argv) +{ + g_test_init(&argc, &argv, NULL); + g_test_add_func("/target-info/not-null", test_target_info_not_null); + g_test_add_func("/target-info/list-count", test_target_info_list_count); + return g_test_run(); +} -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430428.1652927 (Exim 4.92) (envelope-from ) id 1x9Mrr-0001a9-Nr; Wed, 23 Sep 2026 13:18:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430428.1652927; Wed, 23 Sep 2026 13:18:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mrr-0001ZY-Kq; Wed, 23 Sep 2026 13:18:35 +0000 Received: by outflank-mailman (input) for mailman id 1430428; Wed, 23 Sep 2026 13:18:34 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mrq-0001WH-Ky for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:18:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mrq-002Evh-1g for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:18:34 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d19b-2eae-0a2a0a5409dd-0a2a4506c894-46 for ; Wed, 23 Sep 2026 15:18:34 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1a8-195a-0a2a45060019-4a7de52bb2a5-3 for ; Wed, 23 Sep 2026 15:18:33 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-33e652b7178so488149eec.1 for ; Wed, 23 Sep 2026 06:18:33 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.18.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:18:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169512; x=1790774312; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2ign1E0+b6xltdUS4MWB1vKIjsNRvcSjRc2WeM4/+WU=; b=SruQTHDpOnWzbi3FY7pYCwoi2wFCa4RRdGAug25WA1G8xU1VEZe5Y29m6p71/ku2ze zdcP2R9obYRPL961HXp8yqW3ZFPvQHH8vTQ+moWrEIm2c+aPf8ZjilWTqMyqAX/KbiQ0 pev4YpdtUgFW7Y2lJ16NQn7kjk6wwUwS6Cow5ceDhb9sQz2VLsJsA81cGeMjpBzOZf7r jD+tuLfdsjmsqHBGzeJTDUiP20tNDJOHlj8l9NipIV+mhGveyhkHPveZW3+6hVZD0rZL Z5qH5c2yXC4pN7krZ4FtXR+p+gq2QXUAVUcZaznYU/EXnNy+ItXaF8RjSDdpI2YHrCGB 9sTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169512; x=1790774312; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=2ign1E0+b6xltdUS4MWB1vKIjsNRvcSjRc2WeM4/+WU=; b=JZpeMm5YoxQNCKnzG8U57F0m8uo5NKUG+W7QKnNTWRJLu0+5+xIJJFrDY8rH0btZae m5MEa5fh6GQszQDewFSU5OSbBm3H7SLYYNq6pv3YjzmAdqrca6ZpXt9RlOyW19SpS8w6 hMqUS5voOpNhL3povm/riVk82LsdicWTRp92GU4AjqVwcbUZJ8H3X2UqgwBJBZuG/2/y ehvbxcope2LzoIrcqWu3uc+0Nfqg+PXMN2MrRGITvhOXrJoN3vXHAToaGrPmZHbPX2hy 5+ELByoUBIPQB0tgk8tLrlH3ifNhuH3Lxgb8NBBI6Dj8hDlnFTKMegNmlRW5OuBWH/yR A1fA== X-Forwarded-Encrypted: i=1; AKwUvByFWeru3SXq8TuOMjOFBaWfPw0MUdF1NWe3QPHazCk99+exKhivcDA/GrYt8sL11i6nE9js/QhZmxM=@lists.xenproject.org X-Gm-Message-State: AFuF++lNryaHVXuh6kmpWkxhUU/WerdhsWa+rY5K49DDpeE40MKpxUcu 2zXbZj54KPvsy30TAH3yS0xYI9PHVxIjHkmcXJP5JiPJVw9tuZiGiZm8 X-Gm-Gg: AYBFou16+N/Xwg8e/LwGRFJVmd5/mzgdGMfZAEVskG4AUWGW7Aa6eDIpJB4Uu0a3VZH nGbzjdVqRc3sdf45QtXmDUkYGVXYYQl8iyUWkCpFVs5VanfnffziuT4xgluWsCnw/HhJCmvHfmL 04EDe3sJNLW+tK8KnQ3Db16jg07ZcuP2r42KXRMeVf7w5dZDXtkGHJTSl3GMOYFydqV51YGFYaf NIJCa4hjw76E+KRPgEluTp7vrp9G1kIvsBdCgec9VcqLNWPA//0lFzXHwFxoEwHfsHhYFyDLycp 9ZBsEAbTIXzB5AiI2+GPt9Q5bxkRGStrJIkbtA0ydgUPU60+dDJEoxGhq6U4d9CTYTyk1mngN1b OX/11Q6BquN05ma1hbotRu5pRK14FuwcgKj55WcRtA1HJZNCkK3kJBeAemEXCFzF2LF2LOV90AM 7D2KM8K6kE4bdiDINl2AGAYplJH0G4dnUHWE+1sE4HwuSw9T4+asKCkMr7Yev1Psr1TAZ8f3mtr HfueFz4LFdd0jdlTCfzP8905RncnSM= X-Received: by 2002:a05:7300:6b19:b0:322:8541:48cc with SMTP id 5a478bee46e88-33e8c53c7afmr2557843eec.15.1790169511320; Wed, 23 Sep 2026 06:18:31 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 010/114] tests/qtest: prepare machine-list-test for combined qemu-system Date: Wed, 23 Sep 2026 21:14:44 +0800 Message-ID: <20260923131635.1894-11-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790169514-FDC0F77B-C5808A6A/0/0 X-purgate-type: clean X-purgate-size: 25975 Each built qemu-system target checks its query-target arch and query-machines names, including the none machine and omitting the abstract pegasos parent. xen, vmapple, nitro, and x-remote appear only when that host build has them. The lists in machine-list-test.inc.h are shared for a later combined qemu-system test. Signed-off-by: Yonggang Luo --- tests/qtest/machine-list-test.c | 94 +++ tests/qtest/machine-list-test.inc.h | 876 ++++++++++++++++++++++++++++ tests/qtest/meson.build | 1 + 3 files changed, 971 insertions(+) create mode 100644 tests/qtest/machine-list-test.c create mode 100644 tests/qtest/machine-list-test.inc.h diff --git a/tests/qtest/machine-list-test.c b/tests/qtest/machine-list-test.c new file mode 100644 index 00000000000..35fb365197d --- /dev/null +++ b/tests/qtest/machine-list-test.c @@ -0,0 +1,94 @@ +/* + * Per-target machine list tests. + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" + +#include "libqtest.h" +#include "qobject/qdict.h" +#include "qobject/qlist.h" +#include "qobject/qstring.h" + +/* query-target "arch" is SysEmuTarget, not always TARGET_NAME. */ +static const char *query_arch_for_target(const char *target_info) +{ + static const struct { + const char *target_name; + const char *arch; + } map[] = { + { "armeb", "arm" }, + { "microblazeel", "microblaze" }, + { "mips64el", "mips64" }, + { "mipsel", "mips" }, + { "ppc64le", "ppc64" }, + { "sh4eb", "sh4" }, + { "xtensaeb", "xtensa" }, + }; + size_t i; + + for (i = 0; i < G_N_ELEMENTS(map); i++) { + if (!strcmp(target_info, map[i].target_name)) { + return map[i].arch; + } + } + return target_info; +} + +#include "machine-list-test.inc.h" + +static QList *query_machine_names(QTestState *qts) +{ + QDict *resp; + QList *machines; + QList *names; + const QListEntry *e; + + resp = qtest_qmp(qts, "{'execute': 'query-machines'}"); + g_assert(qdict_haskey(resp, "return")); + machines = qdict_get_qlist(resp, "return"); + g_assert_nonnull(machines); + names = qlist_new(); + for (e = qlist_first(machines); e; e = qlist_next(e)) { + QDict *m = qobject_to(QDict, qlist_entry_obj(e)); + const char *name; + + g_assert_nonnull(m); + name = qdict_get_str(m, "name"); + qlist_append_str(names, name); + } + qobject_unref(resp); + return names; +} + +static void test_historic_machine_list(void) +{ + const char *target = qtest_get_arch(); + const struct ShippedTarget *t = lookup_shipped_target(target); + QTestState *qts; + QDict *resp; + QDict *ret; + g_autoptr(QList) names = NULL; + + qts = qtest_init("-nodefaults -M none"); + read_accel_flags(qts); + resp = qtest_qmp(qts, "{'execute': 'query-target'}"); + g_assert(qdict_haskey(resp, "return")); + ret = qdict_get_qdict(resp, "return"); + g_assert_cmpstr(qdict_get_str(ret, "arch"), ==, + query_arch_for_target(target)); + qobject_unref(resp); + names = query_machine_names(qts); + if (t) { + assert_name_list(names, t->name, t->machines, t->n_machines); + } + qtest_quit(qts); +} + +int main(int argc, char **argv) +{ + g_test_init(&argc, &argv, NULL); + qtest_add_func("machine-list", test_historic_machine_list); + return g_test_run(); +} diff --git a/tests/qtest/machine-list-test.inc.h b/tests/qtest/machine-list-test.inc.h new file mode 100644 index 00000000000..e6e6f3ea7cd --- /dev/null +++ b/tests/qtest/machine-list-test.inc.h @@ -0,0 +1,876 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +/* Normal machine lists for every softmmu target. */ +/* Xen, vmapple, nitro, and x-remote stay in special_machine_map. */ + +static const char * const aarch64_machines[] = { + "amd-versal-virt", + "amd-versal2-virt", + "anacapa-bmc", + "ast1030-evb", + "ast1040-evb", + "ast1060-evb", + "ast2500-evb", + "ast2600-evb", + "ast2700a1-evb", + "ast2700a2-evb", + "ast2700fc", + "axiado-scm3003", + "b-l475e-iot01a", + "bletchley-bmc", + "bpim2u", + "canon-a1100", + "catalina-bmc", + "collie", + "cubieboard", + "emcraft-sf2", + "fby35-bmc", + "fuji-bmc", + "g220a-bmc", + "gb200nvl-bmc", + "imx25-pdk", + "imx8mm-evk", + "imx8mp-evk", + "integratorcp", + "kudo-bmc", + "kzm", + "lm3s6965evb", + "lm3s811evb", + "max78000fthr", + "mcimx6ul-evk", + "mcimx7d-sabre", + "microbit", + "mori-bmc", + "mps2-an385", + "mps2-an386", + "mps2-an500", + "mps2-an505", + "mps2-an511", + "mps2-an521", + "mps3-an524", + "mps3-an536", + "mps3-an547", + "mps3-an555", + "musca-a", + "musca-b1", + "netduino2", + "netduinoplus2", + "none", + "npcm750-evb", + "npcm845-evb", + "nuri", + "olimex-stm32-h405", + "orangepi-pc", + "palmetto-bmc", + "quanta-gbs-bmc", + "quanta-gsj", + "quanta-q71l-bmc", + "rainier-bmc", + "raspi0", + "raspi1ap", + "raspi2b", + "raspi3ap", + "raspi3b", + "raspi4b", + "realview-eb", + "realview-eb-mpcore", + "realview-pb-a8", + "realview-pbx-a9", + "romulus-bmc", + "sabrelite", + "sanmiguel-bmc", + "sbsa-ref", + "smdkc210", + "stm32vldiscovery", + "supermicro-x11spi-bmc", + "supermicrox11-bmc", + "sx1", + "sx1-v1", + "tiogapass-bmc", + "versatileab", + "versatilepb", + "vexpress-a15", + "vexpress-a9", + "virt-10.0", + "virt-10.1", + "virt-10.2", + "virt-11.0", + "virt-11.1", + "virt-11.2", + "virt-6.0", + "virt-6.1", + "virt-6.2", + "virt-7.0", + "virt-7.1", + "virt-7.2", + "virt-8.0", + "virt-8.1", + "virt-8.2", + "virt-9.0", + "virt-9.1", + "virt-9.2", + "witherspoon-bmc", + "xilinx-zynq-a9", + "xlnx-zcu102", + "yosemitev2-bmc", +}; + +static const char * const alpha_machines[] = { + "clipper", + "none", +}; + +static const char * const arm_machines[] = { + "anacapa-bmc", + "ast1030-evb", + "ast1040-evb", + "ast1060-evb", + "ast2500-evb", + "ast2600-evb", + "b-l475e-iot01a", + "bletchley-bmc", + "bpim2u", + "canon-a1100", + "catalina-bmc", + "collie", + "cubieboard", + "emcraft-sf2", + "fby35-bmc", + "fuji-bmc", + "g220a-bmc", + "gb200nvl-bmc", + "imx25-pdk", + "integratorcp", + "kudo-bmc", + "kzm", + "lm3s6965evb", + "lm3s811evb", + "max78000fthr", + "mcimx6ul-evk", + "mcimx7d-sabre", + "microbit", + "mori-bmc", + "mps2-an385", + "mps2-an386", + "mps2-an500", + "mps2-an505", + "mps2-an511", + "mps2-an521", + "mps3-an524", + "mps3-an536", + "mps3-an547", + "mps3-an555", + "musca-a", + "musca-b1", + "netduino2", + "netduinoplus2", + "none", + "npcm750-evb", + "nuri", + "olimex-stm32-h405", + "orangepi-pc", + "palmetto-bmc", + "quanta-gbs-bmc", + "quanta-gsj", + "quanta-q71l-bmc", + "rainier-bmc", + "raspi0", + "raspi1ap", + "raspi2b", + "realview-eb", + "realview-eb-mpcore", + "realview-pb-a8", + "realview-pbx-a9", + "romulus-bmc", + "sabrelite", + "sanmiguel-bmc", + "smdkc210", + "stm32vldiscovery", + "supermicro-x11spi-bmc", + "supermicrox11-bmc", + "sx1", + "sx1-v1", + "tiogapass-bmc", + "versatileab", + "versatilepb", + "vexpress-a15", + "vexpress-a9", + "virt-10.0", + "virt-10.1", + "virt-10.2", + "virt-11.0", + "virt-11.1", + "virt-11.2", + "virt-6.0", + "virt-6.1", + "virt-6.2", + "virt-7.0", + "virt-7.1", + "virt-7.2", + "virt-8.0", + "virt-8.1", + "virt-8.2", + "virt-9.0", + "virt-9.1", + "virt-9.2", + "witherspoon-bmc", + "xilinx-zynq-a9", + "yosemitev2-bmc", +}; + +static const char * const avr_machines[] = { + "arduino-duemilanove", + "arduino-mega", + "arduino-mega-2560-v3", + "arduino-uno", + "none", +}; + +static const char * const hexagon_machines[] = { + "V66G_1024", + "V68N_1024", + "V81DGB_1", + "V81QA_1", + "none", + "virt", +}; + +static const char * const hppa_machines[] = { + "715", + "A400", + "B160L", + "C3700", + "none", +}; + +static const char * const i386_machines[] = { + "isapc", + "microvm", + "none", + "pc-i440fx-10.0", + "pc-i440fx-10.1", + "pc-i440fx-10.2", + "pc-i440fx-11.0", + "pc-i440fx-11.1", + "pc-i440fx-11.2", + "pc-i440fx-6.0", + "pc-i440fx-6.1", + "pc-i440fx-6.2", + "pc-i440fx-7.0", + "pc-i440fx-7.1", + "pc-i440fx-7.2", + "pc-i440fx-8.0", + "pc-i440fx-8.1", + "pc-i440fx-8.2", + "pc-i440fx-9.0", + "pc-i440fx-9.1", + "pc-i440fx-9.2", + "pc-q35-10.0", + "pc-q35-10.1", + "pc-q35-10.2", + "pc-q35-11.0", + "pc-q35-11.1", + "pc-q35-11.2", + "pc-q35-6.0", + "pc-q35-6.1", + "pc-q35-6.2", + "pc-q35-7.0", + "pc-q35-7.1", + "pc-q35-7.2", + "pc-q35-8.0", + "pc-q35-8.1", + "pc-q35-8.2", + "pc-q35-9.0", + "pc-q35-9.1", + "pc-q35-9.2", +}; + +static const char * const loongarch64_machines[] = { + "none", + "virt-11.1", + "virt-11.2", +}; + +static const char * const m68k_machines[] = { + "an5206", + "mcf5208evb", + "next-cube", + "none", + "q800", + "virt-10.0", + "virt-10.1", + "virt-10.2", + "virt-11.0", + "virt-11.1", + "virt-11.2", + "virt-6.0", + "virt-6.1", + "virt-6.2", + "virt-7.0", + "virt-7.1", + "virt-7.2", + "virt-8.0", + "virt-8.1", + "virt-8.2", + "virt-9.0", + "virt-9.1", + "virt-9.2", +}; + +static const char * const microblaze_machines[] = { + "none", + "petalogix-ml605", + "petalogix-s3adsp1800", + "xlnx-zynqmp-pmu", +}; + +static const char * const mips_machines[] = { + "malta", + "none", +}; + +static const char * const mips64_machines[] = { + "magnum", + "malta", + "none", + "pica61", +}; + +static const char * const mips64el_machines[] = { + "boston", + "fuloong2e", + "loongson3-virt", + "magnum", + "malta", + "none", + "pica61", +}; + +static const char * const mipsel_machines[] = { + "malta", + "none", +}; + +static const char * const or1k_machines[] = { + "none", + "or1k-sim", + "virt", +}; + +static const char * const ppc_machines[] = { + "40p", + "amigaone", + "bamboo", + "g3beige", + "mac99", + "mpc8544ds", + "none", + "pegasos1", + "pegasos2", + "ppce500", + "ppe42_machine", + "sam460ex", + "virtex-ml507", +}; + +static const char * const ppc64_machines[] = { + "40p", + "amigaone", + "bamboo", + "g3beige", + "mac99", + "mpc8544ds", + "none", + "pegasos1", + "pegasos2", + "powernv10", + "powernv10-rainier", + "powernv11", + "powernv8", + "powernv9", + "ppce500", + "ppe42_machine", + "pseries-10.0", + "pseries-10.1", + "pseries-10.2", + "pseries-11.0", + "pseries-11.1", + "pseries-11.2", + "pseries-6.0", + "pseries-6.1", + "pseries-6.2", + "pseries-7.0", + "pseries-7.1", + "pseries-7.2", + "pseries-8.0", + "pseries-8.1", + "pseries-8.2", + "pseries-9.0", + "pseries-9.1", + "pseries-9.2", + "sam460ex", + "virtex-ml507", +}; + +static const char * const riscv32_machines[] = { + "amd-microblaze-v-generic", + "none", + "opentitan", + "sifive_e", + "sifive_u", + "spike", + "virt", +}; + +static const char * const riscv64_machines[] = { + "amd-microblaze-v-generic", + "boston-aia", + "k230", + "microchip-icicle-kit", + "none", + "shakti_c", + "sifive_e", + "sifive_u", + "spike", + "tt-atlantis", + "virt", + "xiangshan-kunminghu", +}; + +static const char * const rx_machines[] = { + "gdbsim-r5f562n7", + "gdbsim-r5f562n8", + "none", +}; + +static const char * const s390x_machines[] = { + "none", + "s390-ccw-virtio-10.0", + "s390-ccw-virtio-10.1", + "s390-ccw-virtio-10.2", + "s390-ccw-virtio-11.0", + "s390-ccw-virtio-11.1", + "s390-ccw-virtio-11.2", + "s390-ccw-virtio-6.0", + "s390-ccw-virtio-6.1", + "s390-ccw-virtio-6.2", + "s390-ccw-virtio-7.0", + "s390-ccw-virtio-7.1", + "s390-ccw-virtio-7.2", + "s390-ccw-virtio-8.0", + "s390-ccw-virtio-8.1", + "s390-ccw-virtio-8.2", + "s390-ccw-virtio-9.0", + "s390-ccw-virtio-9.1", + "s390-ccw-virtio-9.2", +}; + +static const char * const sh4_machines[] = { + "none", + "r2d", +}; + +static const char * const sh4eb_machines[] = { + "none", + "r2d", +}; + +static const char * const sparc_machines[] = { + "LX", + "SPARCClassic", + "SPARCbook", + "SS-10", + "SS-20", + "SS-4", + "SS-5", + "SS-600MP", + "Voyager", + "leon3_generic", + "none", +}; + +static const char * const sparc64_machines[] = { + "niagara", + "none", + "sun4u", + "sun4v", +}; + +static const char * const tricore_machines[] = { + "KIT_AURIX_TC277_TRB", + "none", + "tricore_testboard", +}; + +static const char * const x86_64_machines[] = { + "isapc", + "microvm", + "none", + "pc-i440fx-10.0", + "pc-i440fx-10.1", + "pc-i440fx-10.2", + "pc-i440fx-11.0", + "pc-i440fx-11.1", + "pc-i440fx-11.2", + "pc-i440fx-6.0", + "pc-i440fx-6.1", + "pc-i440fx-6.2", + "pc-i440fx-7.0", + "pc-i440fx-7.1", + "pc-i440fx-7.2", + "pc-i440fx-8.0", + "pc-i440fx-8.1", + "pc-i440fx-8.2", + "pc-i440fx-9.0", + "pc-i440fx-9.1", + "pc-i440fx-9.2", + "pc-q35-10.0", + "pc-q35-10.1", + "pc-q35-10.2", + "pc-q35-11.0", + "pc-q35-11.1", + "pc-q35-11.2", + "pc-q35-6.0", + "pc-q35-6.1", + "pc-q35-6.2", + "pc-q35-7.0", + "pc-q35-7.1", + "pc-q35-7.2", + "pc-q35-8.0", + "pc-q35-8.1", + "pc-q35-8.2", + "pc-q35-9.0", + "pc-q35-9.1", + "pc-q35-9.2", +}; + +static const char * const xtensa_machines[] = { + "kc705", + "kc705-nommu", + "lx200", + "lx200-nommu", + "lx60", + "lx60-nommu", + "ml605", + "ml605-nommu", + "none", + "sim", + "virt", +}; + +static const char * const xtensaeb_machines[] = { + "kc705", + "kc705-nommu", + "lx200", + "lx200-nommu", + "lx60", + "lx60-nommu", + "ml605", + "ml605-nommu", + "none", + "sim", + "virt", +}; + +static const struct ShippedTarget { + const char *name; + const char *arch; + const char *endianness; + const char * const *machines; + size_t n_machines; +} shipped_targets[] = { + { "aarch64", "aarch64", "little", + aarch64_machines, G_N_ELEMENTS(aarch64_machines) }, + { "alpha", "alpha", "little", + alpha_machines, G_N_ELEMENTS(alpha_machines) }, + { "arm", "arm", "little", + arm_machines, G_N_ELEMENTS(arm_machines) }, + { "avr", "avr", "little", + avr_machines, G_N_ELEMENTS(avr_machines) }, + { "hexagon", "hexagon", "little", + hexagon_machines, G_N_ELEMENTS(hexagon_machines) }, + { "hppa", "hppa", "big", + hppa_machines, G_N_ELEMENTS(hppa_machines) }, + { "i386", "i386", "little", + i386_machines, G_N_ELEMENTS(i386_machines) }, + { "loongarch64", "loongarch64", "little", + loongarch64_machines, G_N_ELEMENTS(loongarch64_machines) }, + { "m68k", "m68k", "big", + m68k_machines, G_N_ELEMENTS(m68k_machines) }, + { "microblaze", "microblaze", "big", + microblaze_machines, G_N_ELEMENTS(microblaze_machines) }, + { "mips", "mips", "big", + mips_machines, G_N_ELEMENTS(mips_machines) }, + { "mips64", "mips64", "big", + mips64_machines, G_N_ELEMENTS(mips64_machines) }, + { "mips64el", "mips64", "little", + mips64el_machines, G_N_ELEMENTS(mips64el_machines) }, + { "mipsel", "mips", "little", + mipsel_machines, G_N_ELEMENTS(mipsel_machines) }, + { "or1k", "or1k", "big", + or1k_machines, G_N_ELEMENTS(or1k_machines) }, + { "ppc", "ppc", "big", + ppc_machines, G_N_ELEMENTS(ppc_machines) }, + { "ppc64", "ppc64", "big", + ppc64_machines, G_N_ELEMENTS(ppc64_machines) }, + { "riscv32", "riscv32", "little", + riscv32_machines, G_N_ELEMENTS(riscv32_machines) }, + { "riscv64", "riscv64", "little", + riscv64_machines, G_N_ELEMENTS(riscv64_machines) }, + { "rx", "rx", "little", + rx_machines, G_N_ELEMENTS(rx_machines) }, + { "s390x", "s390x", "big", + s390x_machines, G_N_ELEMENTS(s390x_machines) }, + { "sh4", "sh4", "little", + sh4_machines, G_N_ELEMENTS(sh4_machines) }, + { "sh4eb", "sh4", "big", + sh4eb_machines, G_N_ELEMENTS(sh4eb_machines) }, + { "sparc", "sparc", "big", + sparc_machines, G_N_ELEMENTS(sparc_machines) }, + { "sparc64", "sparc64", "big", + sparc64_machines, G_N_ELEMENTS(sparc64_machines) }, + { "tricore", "tricore", "little", + tricore_machines, G_N_ELEMENTS(tricore_machines) }, + { "x86_64", "x86_64", "little", + x86_64_machines, G_N_ELEMENTS(x86_64_machines) }, + { "xtensa", "xtensa", "little", + xtensa_machines, G_N_ELEMENTS(xtensa_machines) }, + { "xtensaeb", "xtensa", "big", + xtensaeb_machines, G_N_ELEMENTS(xtensaeb_machines) }, +}; + +/* + * Machines omitted from the normal lists. Merged in when @accel is + * present (NULL means no accel check) and the host matches (NULL + * host_os or host_cpu means any). xenfv is an alias of xenfv-4.2. + * aarch64 HVF (vmapple) is built only on an aarch64 Darwin host. + * nitro is Linux-only, on x86_64-softmmu for an x86_64 host and + * aarch64-softmmu for an aarch64 host. x-remote follows KVM on Linux + * when host_cpu is the host that builds KVM for that target. + */ +static const char * const xen_pc_machines[] = { + "xenpv", + "xenpvh", + "xenfv-4.2", +}; + +static const char * const xen_aarch64_machines[] = { + "xenpvh", +}; + +static const char * const hvf_aarch64_machines[] = { + "vmapple", +}; + +static const char * const nitro_machines[] = { + "nitro", +}; + +static const char * const x_remote_machines[] = { + "x-remote", +}; + +static const struct SpecialMachineMap { + const char *target; + const char *accel; + const char *host_os; + const char *host_cpu; + const char * const *machines; + size_t n_machines; +} special_machine_map[] = { + { "i386", "xen", NULL, "x86_64", + xen_pc_machines, G_N_ELEMENTS(xen_pc_machines) }, + { "i386", "xen", NULL, "aarch64", + xen_pc_machines, G_N_ELEMENTS(xen_pc_machines) }, + { "x86_64", "xen", NULL, "x86_64", + xen_pc_machines, G_N_ELEMENTS(xen_pc_machines) }, + { "x86_64", "xen", NULL, "aarch64", + xen_pc_machines, G_N_ELEMENTS(xen_pc_machines) }, + { "aarch64", "xen", NULL, "aarch64", + xen_aarch64_machines, G_N_ELEMENTS(xen_aarch64_machines) }, + { "aarch64", "hvf", "darwin", "aarch64", + hvf_aarch64_machines, G_N_ELEMENTS(hvf_aarch64_machines) }, + { "x86_64", NULL, "linux", "x86_64", + nitro_machines, G_N_ELEMENTS(nitro_machines) }, + { "aarch64", NULL, "linux", "aarch64", + nitro_machines, G_N_ELEMENTS(nitro_machines) }, + { "i386", "kvm", "linux", "x86_64", + x_remote_machines, G_N_ELEMENTS(x_remote_machines) }, + { "x86_64", "kvm", "linux", "x86_64", + x_remote_machines, G_N_ELEMENTS(x_remote_machines) }, + { "aarch64", "kvm", "linux", "aarch64", + x_remote_machines, G_N_ELEMENTS(x_remote_machines) }, + { "ppc", "kvm", "linux", "ppc64", + x_remote_machines, G_N_ELEMENTS(x_remote_machines) }, + { "ppc64", "kvm", "linux", "ppc64", + x_remote_machines, G_N_ELEMENTS(x_remote_machines) }, + { "s390x", "kvm", "linux", "s390x", + x_remote_machines, G_N_ELEMENTS(x_remote_machines) }, + { "riscv64", "kvm", "linux", "riscv64", + x_remote_machines, G_N_ELEMENTS(x_remote_machines) }, + { "loongarch64", "kvm", "linux", "loongarch64", + x_remote_machines, G_N_ELEMENTS(x_remote_machines) }, +}; + +static const struct ShippedTarget *lookup_shipped_target(const char *name) +{ + size_t i; + + for (i = 0; i < G_N_ELEMENTS(shipped_targets); i++) { + if (!strcmp(shipped_targets[i].name, name)) { + return &shipped_targets[i]; + } + } + return NULL; +} + +static bool have_xen; +static bool have_hvf; +static bool have_kvm; + +static const char *host_cpu(void) +{ +#if defined(__aarch64__) || defined(_M_ARM64) + return "aarch64"; +#elif defined(__x86_64__) || defined(_M_X64) + return "x86_64"; +#elif defined(__powerpc64__) + return "ppc64"; +#elif defined(__s390x__) + return "s390x"; +#elif defined(__riscv) && __riscv_xlen == 64 + return "riscv64"; +#elif defined(__loongarch64) + return "loongarch64"; +#else + return "other"; +#endif +} + +static bool host_os_matches(const char *host_os) +{ + if (!host_os) { + return true; + } +#if defined(CONFIG_LINUX) + return !strcmp(host_os, "linux"); +#elif defined(CONFIG_DARWIN) + return !strcmp(host_os, "darwin"); +#else + return false; +#endif +} + +static bool accel_present(const char *accel) +{ + if (!accel) { + return true; + } + if (!strcmp(accel, "xen")) { + return have_xen; + } + if (!strcmp(accel, "hvf")) { + return have_hvf; + } + if (!strcmp(accel, "kvm")) { + return have_kvm; + } + return false; +} + +static bool host_cpu_matches(const char *want) +{ + if (!want) { + return true; + } + return !strcmp(want, host_cpu()); +} + +static bool special_applies(const struct SpecialMachineMap *s, + const char *target) +{ + return !strcmp(s->target, target) && + accel_present(s->accel) && + host_os_matches(s->host_os) && + host_cpu_matches(s->host_cpu); +} + +static void assert_name_list(QList *names, const char *target, + const char * const *expect, size_t n_expect) +{ + GHashTable *got = g_hash_table_new(g_str_hash, g_str_equal); + GHashTable *want = g_hash_table_new(g_str_hash, g_str_equal); + const QListEntry *e; + GHashTableIter iter; + gpointer key; + size_t i; + + g_assert_nonnull(names); + for (e = qlist_first(names); e; e = qlist_next(e)) { + QString *qs = qobject_to(QString, qlist_entry_obj(e)); + + g_assert_nonnull(qs); + g_hash_table_add(got, (gpointer)qstring_get_str(qs)); + } + for (i = 0; i < n_expect; i++) { + g_hash_table_add(want, (gpointer)expect[i]); + } + for (i = 0; i < G_N_ELEMENTS(special_machine_map); i++) { + const struct SpecialMachineMap *s = &special_machine_map[i]; + size_t j; + + if (!special_applies(s, target)) { + continue; + } + for (j = 0; j < s->n_machines; j++) { + g_hash_table_add(want, (gpointer)s->machines[j]); + } + } + g_hash_table_iter_init(&iter, got); + while (g_hash_table_iter_next(&iter, &key, NULL)) { + if (!g_hash_table_contains(want, key)) { + g_printerr("unexpected machine: %s\n", (const char *)key); + } + } + g_hash_table_iter_init(&iter, want); + while (g_hash_table_iter_next(&iter, &key, NULL)) { + if (!g_hash_table_contains(got, key)) { + g_printerr("missing machine: %s\n", (const char *)key); + } + } + g_assert_cmpuint(g_hash_table_size(got), ==, g_hash_table_size(want)); + g_hash_table_unref(got); + g_hash_table_unref(want); +} + +static void read_accel_flags(QTestState *qts) +{ + QDict *resp; + QDict *ret; + QList *present; + const QListEntry *e; + + have_xen = false; + have_hvf = false; + have_kvm = false; + resp = qtest_qmp(qts, "{'execute': 'query-accelerators'}"); + g_assert(qdict_haskey(resp, "return")); + ret = qdict_get_qdict(resp, "return"); + present = qdict_get_qlist(ret, "present"); + g_assert_nonnull(present); + for (e = qlist_first(present); e; e = qlist_next(e)) { + QString *qs = qobject_to(QString, qlist_entry_obj(e)); + const char *name; + + g_assert_nonnull(qs); + name = qstring_get_str(qs); + if (!strcmp(name, "xen")) { + have_xen = true; + } else if (!strcmp(name, "hvf")) { + have_hvf = true; + } else if (!strcmp(name, "kvm")) { + have_kvm = true; + } + } + qobject_unref(resp); +} diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build index 33f58b0e95c..8c53bb2e30e 100644 --- a/tests/qtest/meson.build +++ b/tests/qtest/meson.build @@ -23,6 +23,7 @@ qtests_generic = [ 'cdrom-test', 'device-introspect-test', 'machine-none-test', + 'machine-list-test', 'qmp-test', 'qmp-cmd-test', 'qom-test', -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430439.1652936 (Exim 4.92) (envelope-from ) id 1x9Ms3-0002BO-4v; Wed, 23 Sep 2026 13:18:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430439.1652936; Wed, 23 Sep 2026 13:18:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Ms3-0002BF-1z; Wed, 23 Sep 2026 13:18:47 +0000 Received: by outflank-mailman (input) for mailman id 1430439; Wed, 23 Sep 2026 13:18:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Ms1-000284-En for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:18:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Ms0-00DJHR-Rh for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:18:44 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d1ab-bab6-0a2a0a5309dd-0a2a450b8de8-32 for ; Wed, 23 Sep 2026 15:18:44 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1b3-b7e8-0a2a450b0019-4a7de52b8eb7-3 for ; Wed, 23 Sep 2026 15:18:44 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-33e6b4e33e4so780595eec.0 for ; Wed, 23 Sep 2026 06:18:44 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.18.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:18:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169523; x=1790774323; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=gvdLUze2sQ9rH6tf9YWuWP18ipAcGMhXKG5e40lFeJk=; b=MieeQ+7P9R72xi1QfbRg66IiTR4e17qcc4ha+q+fsv+5lzRcxlDIbHMn51sk3UvhG9 EZITvSlFpynXUzpkqnvJU0jnCJ0gy64S5wLTqaYaL01hiYcgu9MSEzizGyZIGYAqMZ6n ygXGllm/3U5n/NMQaJElDaebZlCaJJYjLU58oZkbvfG7rMswBJnbNRpI7cVlip7PesBn kWM84GDWHq7q/oGhZwrEbd1dX4jSaYizrMhKPG5ELmaNIS1uAZnmV3u3cFDlRLTzU1gd 9fawtCNy57UsVFDog0tPRFv419B9m3nkJqYg6cXi1Qx/ePUwKst+01NYkW6EAJwCeh2Q mzhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169523; x=1790774323; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=gvdLUze2sQ9rH6tf9YWuWP18ipAcGMhXKG5e40lFeJk=; b=a/VUzhJfjSN7t7SRcjJPL1YzB5gIQNyY97FDtqfjWt4Hki0qK8BreiR5yPVc0pT69B cS5x9zAFd/9RjmqpE+K/DR0ROneKm1xLVWHq3YbnPvBQQWFOhtmjY9LLgArNA3jCdcvI LvFbTo3RxeRQy9AwVeGd5+P8WCaVGOu7WGx9pikTR3p2o25jyMLKMLUYhmyWnmPqSTVR bkOCzYkc51oSOL990G4/mY/+Lmn4LHVa2KYUgONdLeCwqJ+llL/rWy1V9f5GXeHAPBjI Vu91tAXaP1otpEgvbBvfKBv1RgMxZBYhhLNq67DNK2NBg8kSnMSSX2iVVzQXrcgnE/PE 8xuA== X-Forwarded-Encrypted: i=1; AKwUvBzSquGK8sjBB0BfS9wuVs+PNVq5iL+ceHdyJOhXltnuPaFPZQLmQDl9vh6z1MbqKdrai7yEuWYXPkk=@lists.xenproject.org X-Gm-Message-State: AFuF++mycvgH/UJNAIONqigkEg6kI87HVahzls+2ohlkRcOzqTn4VDrw /VFYyfLlzIloBz9CsZ04QKUD5jqSl6D0CbOsTiInr9HvoeGPWWkWd8sI X-Gm-Gg: AYBFou1eBcDa5FW8cKVzAROib8iVCIfx0UluH1UUrNDRVqOQ8qZ+PpuUCYXdTwm8PpH a2UxkDyd9kPKF2zXSaZwU2962HX9c0EPjR6oEQonmpqEmqP7+RSyzrOtliB6wwrl0Xtqf39px4X Bhd3ALxjvtXTFQyHL/L10BTV2X5cQP5/xdN0BKxnNQwl9C+xszf5zZWF8GnVBTwKd7CLOi8cjOc oLyuuq2HgltP4nBggdVfpiJxtQR6tThxK7XFBEwV3cmWFN4pLp1UcucP87bG+HlpNuvDcpWhXML dGkuInC1xkDi83uDYHCfmRlCgkiFpThtGk++Trgxoq95mv85h4/dW3R65Twg+rLp0TAeh6mxD/1 sDCV7vVhfF3Se4tND8LhifHb3kl0uaLH8whK3lOkucUDF6woVmb7cPE641Te6d3OoWAFA539jcX zATNmx+1nri12Z6KtylFDYKtjEjwOB8JojUAWa+ZbVyhvWj32z6LWyAo4vAfI2y3lCivKlWJq1M Zl6XhGDSWbecG22OEBUW4WSJMepNuM= X-Received: by 2002:a05:7301:3a99:b0:30f:1e28:fb5d with SMTP id 5a478bee46e88-33e8d6d03a4mr2458825eec.20.1790169522434; Wed, 23 Sep 2026 06:18:42 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 011/114] kconfig: rename REGISTER to HW_REGISTER Date: Wed, 23 Sep 2026 21:14:45 +0800 Message-ID: <20260923131635.1894-12-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790169524-ABED69EA-DA379DDE/0/0 X-purgate-type: clean X-purgate-size: 2919 Rename config REGISTER to HW_REGISTER. register is a C keyword, and a later TargetKconfig commit will use it as a struct member. Signed-off-by: Yonggang Luo --- hw/Kconfig | 2 +- hw/core/Kconfig | 2 +- hw/core/meson.build | 2 +- hw/dma/Kconfig | 4 ++-- hw/i2c/Kconfig | 2 +- hw/usb/Kconfig | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/hw/Kconfig b/hw/Kconfig index c92ca2b13a3..94f963f2944 100644 --- a/hw/Kconfig +++ b/hw/Kconfig @@ -85,7 +85,7 @@ config XILINX_AXI config XLNX_ZYNQMP bool - select REGISTER + select HW_REGISTER select CAN_BUS select PTIMER select XLNX_BBRAM diff --git a/hw/core/Kconfig b/hw/core/Kconfig index d1bdf765ee8..839e249b9d0 100644 --- a/hw/core/Kconfig +++ b/hw/core/Kconfig @@ -29,7 +29,7 @@ config PLATFORM_BUS bool depends on DEVICE_TREE -config REGISTER +config HW_REGISTER bool config SPLIT_IRQ diff --git a/hw/core/meson.build b/hw/core/meson.build index 8fe776d2c86..1c645d7041d 100644 --- a/hw/core/meson.build +++ b/hw/core/meson.build @@ -21,7 +21,7 @@ system_ss.add(when: 'CONFIG_GUEST_LOADER', if_true: files('guest-loader.c')) system_ss.add(when: 'CONFIG_OR_IRQ', if_true: files('or-irq.c')) system_ss.add(when: 'CONFIG_PLATFORM_BUS', if_true: files('platform-bus.c')) system_ss.add(when: 'CONFIG_PTIMER', if_true: files('ptimer.c')) -system_ss.add(when: 'CONFIG_REGISTER', if_true: files('register.c')) +system_ss.add(when: 'CONFIG_HW_REGISTER', if_true: files('register.c')) system_ss.add(when: 'CONFIG_SPLIT_IRQ', if_true: files('split-irq.c')) system_ss.add(when: 'CONFIG_XILINX_AXI', if_true: files('stream.c')) system_ss.add(when: 'CONFIG_PLATFORM_BUS', if_true: files('sysbus-fdt.c')) diff --git a/hw/dma/Kconfig b/hw/dma/Kconfig index 0a23e7d7b87..8f221b20634 100644 --- a/hw/dma/Kconfig +++ b/hw/dma/Kconfig @@ -16,7 +16,7 @@ config I8257 config ZYNQ_DEVCFG bool - select REGISTER + select HW_REGISTER config XLNX_ZDMA bool @@ -29,7 +29,7 @@ config SIFIVE_PDMA config XLNX_CSU_DMA bool - select REGISTER + select HW_REGISTER config K230_GSDMA bool \ No newline at end of file diff --git a/hw/i2c/Kconfig b/hw/i2c/Kconfig index 0766130b596..3482f475cf9 100644 --- a/hw/i2c/Kconfig +++ b/hw/i2c/Kconfig @@ -20,7 +20,7 @@ config ARM_SBCON_I2C config DESIGNWARE_I2C bool - select REGISTER + select HW_REGISTER select I2C config ACPI_SMBUS diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig index e8c00f813a6..43771291a06 100644 --- a/hw/usb/Kconfig +++ b/hw/usb/Kconfig @@ -137,7 +137,7 @@ config IMX_USBPHY config USB_DWC3 bool select USB_XHCI_SYSBUS - select REGISTER + select HW_REGISTER config XLNX_USB_SUBSYS bool -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:18:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:18:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430446.1652945 (Exim 4.92) (envelope-from ) id 1x9MsC-0002eh-Be; Wed, 23 Sep 2026 13:18:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430446.1652945; Wed, 23 Sep 2026 13:18:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MsC-0002eY-89; Wed, 23 Sep 2026 13:18:56 +0000 Received: by outflank-mailman (input) for mailman id 1430446; Wed, 23 Sep 2026 13:18:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MsA-0002bc-Jl for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:18:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MsA-00DqRR-0H for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:18:54 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d1bc-e002-0a2a0a5209dd-0a2a4504b038-8 for ; Wed, 23 Sep 2026 15:18:53 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1bc-b57f-0a2a45040019-4a7de52b846a-3 for ; Wed, 23 Sep 2026 15:18:53 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-328664ef78fso553275eec.2 for ; Wed, 23 Sep 2026 06:18:53 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.18.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:18:49 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169531; x=1790774331; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LmGgEVLgs7KsvhNFrBIpJWDBtYOselCCUrcKIvn6Xxs=; b=N5kD2MpFstjZQR5P4F/zhxpkQkoRPRsV9raByYIP9UTp0fpp159ddB7OUukZI1YzZp Ua4Yzkp8x8aKIMGXD/04hRrh2cQnpjQX2y3hlNqKH3FPKHv4DtoWVIV8j9ztX7lGPAnV YmnoOAMLKaeHLxDYQz41zk9NJnXwVIfv45j+bkghS33oXmBAolnbUIJPmAt38XQNzwYc sSwBmg8lQHN3W4XohzYOcXnnweNBtOGi6u1A3rb+dz5fZAr82cP718SdbKL5tyx3ecxA wpd4wqLM5FZNc3eo0xkuBH7Tkhqs2Dl2PwhZTWZMaLpjqSk9CP3P5E7Be/9VeN9h+6SE tgeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169531; x=1790774331; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=LmGgEVLgs7KsvhNFrBIpJWDBtYOselCCUrcKIvn6Xxs=; b=ZiputBaWmE2yZ1hceLNRAktumKt05+6LmTYznjLdZXiRz91zhzSmILLJ35r/GRghuk v96Qr6ydeU9a7RJ2Enq0wy2o8zh/yyz2yuc6rWJS65OotdzGra2P+ly+iLiAk1OYpLdD 9yGY16ze49sYYYPQomjfZFR/p5d2qgOdGWfT/AAx+u9HzHhXInXl5P+maZq3/yN/QyVp gLW07rmLnWz8cqdDcYrLQIxuMQ9IATiA+y3KQXaTPh0aFLgq5rt5nZdlCsMBn+HhzhLg afeSTU/vGE0p4Dy4+Z0mRu9i8Gfu6UZDZ2iOqB1DFHdOjI/tmZhRl/4sLK7UWwyzVM6i 4HSg== X-Forwarded-Encrypted: i=1; AKwUvBxVmWCDHCcE5yE796LwoHSpccptOaswenM8XS/zMgN2qAACau4jQIuZv0WjE+jP2ZdAn/zoTRAmzVk=@lists.xenproject.org X-Gm-Message-State: AFuF++l2STLRvzrMKDbOg/ru2hSbzvkr7VzectSLUgymZccozFmnFvsZ tLpp/NpmknVRDuEP9yT99Gof8EnN/a1BiBnHkk/dpKvw8Ps9bNDwPQOX X-Gm-Gg: AYBFou3PKZKaJx0fZZ91xikyDO+JZ9GdXGgiUW0OnekWuTqqe5YfAUTnimEoHijShRK BB0X+w8/iuR0TCNAWkeL5qu7MdPJtC7NcjwyfUY8cyVlvtpZyoHYrCiIudR2MOKAudSN8dNWKJL G7KQJMc/R4PXF7pZQ0wv4XRjEAxGRaXDo6uBwwncdtwZVnosyZN5Gq8tC/w4Y02AiDVrjY6R9Ou tLpKJNRS3VzOIf+U9bQlql69NV9gNTGGwujmPgZRwfSYasxYdZ0T7IoNNJJoo821LHLnH4nhh0a gDURO++bzPIDLuDRN8eRNyn0ZkUva9hvzYoE100WZwzsAx9n2Ar/pFbwoVgj7bHJyBg5RHh32bL 6Axsm6CUy9xZ77hDbAT2A6QP/P+Y8e1ulcxxBTDESGFLIG8g2Z9VC2h8U+ZCYto5a5v6cRztSNz JVUFybHXkOLRym7YnSY/JgjyLtxOBv4fPWILHVskJbWG6dyYqMQdnZchdZ9FQnyqRhmCvk71KRi s/BjMqrXP0hCCsik4ZtUgC5EwKYV+w= X-Received: by 2002:a05:7300:dd05:b0:33b:eea2:cbfe with SMTP id 5a478bee46e88-33e8dec5b02mr2369589eec.32.1790169531303; Wed, 23 Sep 2026 06:18:51 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 012/114] target-info: add TargetKconfig Date: Wed, 23 Sep 2026 21:14:46 +0800 Message-ID: <20260923131635.1894-13-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790169533-504DBB50-98395C87/0/0 X-purgate-type: clean X-purgate-size: 12921 Add a packed TargetKconfig of device and accel CONFIG_* bits, generated from the Kconfig tree, and attach it to TargetInfo. target_kconfig() returns the current bits, and target_has_kconfig_() tests them. Initialize target_info_stub.kconfig from CONFIG_DEVICES. Signed-off-by: Yonggang Luo --- include/qemu/target-info-def.h | 2 + include/qemu/target-kconfig-has.h | 7 ++ include/qemu/target-kconfig.h | 34 ++++++ meson.build | 14 +++ scripts/gen-target-kconfig.py | 162 +++++++++++++++++++++++++++ target-info-def.c | 6 + target-kconfig.c | 20 ++++ tests/unit/meson.build | 1 + tests/unit/test-target-kconfig-has.c | 22 ++++ 9 files changed, 268 insertions(+) create mode 100644 include/qemu/target-kconfig-has.h create mode 100644 include/qemu/target-kconfig.h create mode 100644 scripts/gen-target-kconfig.py create mode 100644 target-kconfig.c create mode 100644 tests/unit/test-target-kconfig-has.c diff --git a/include/qemu/target-info-def.h b/include/qemu/target-info-def.h index 25dc7c508d3..615596ed468 100644 --- a/include/qemu/target-info-def.h +++ b/include/qemu/target-info-def.h @@ -13,6 +13,7 @@ #include "qapi/qapi-types-machine.h" #include "qemu/queue.h" #include "qemu/target-info.h" +#include "qemu/target-kconfig.h" struct TargetInfo { /* runtime equivalent of TARGET_NAME definition */ @@ -32,6 +33,7 @@ struct TargetInfo { unsigned page_bits_init; /* runtime equivalent of TARGET_PAGE_BITS_VARY definition */ bool page_bits_vary; + TargetKconfig kconfig; }; typedef struct TargetInfoNode TargetInfoNode; diff --git a/include/qemu/target-kconfig-has.h b/include/qemu/target-kconfig-has.h new file mode 100644 index 00000000000..6616f75845a --- /dev/null +++ b/include/qemu/target-kconfig-has.h @@ -0,0 +1,7 @@ +/* + * QEMU target_has_kconfig_* helpers + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "target-kconfig-has-gen.h" diff --git a/include/qemu/target-kconfig.h b/include/qemu/target-kconfig.h new file mode 100644 index 00000000000..21b2ba576ec --- /dev/null +++ b/include/qemu/target-kconfig.h @@ -0,0 +1,34 @@ +/* + * QEMU target kconfig API + * + * Copyright (c) Yonggang Luo + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#ifndef QEMU_TARGET_KCONFIG_H +#define QEMU_TARGET_KCONFIG_H + +#include "qemu/compiler.h" + +/** + * struct TargetKconfig: + * + * Compile-time device and accel CONFIG_* bits. Not Kconfig.host + * or target/Kconfig. Target identity is TargetInfo, not these + * bits. Not kvm_enabled() etc. Fields and + * target_has_kconfig_() are generated by + * scripts/gen-target-kconfig.py. + */ +typedef struct TargetKconfig { +#include "target-kconfig-fields.h" +} QEMU_PACKED TargetKconfig; + +/** + * target_kconfig: + * + * Returns: The current TargetKconfig (target_info()->kconfig). + */ +const TargetKconfig *target_kconfig(void); + +#endif diff --git a/meson.build b/meson.build index 776d38c5afd..8a017faaa74 100644 --- a/meson.build +++ b/meson.build @@ -3445,6 +3445,19 @@ genh += custom_target('config-poison.h', capture: true, command: [find_program('scripts/make-config-poison.sh'), target_configs_h]) +genh += custom_target('target-kconfig', + output: ['target-kconfig-fields.h', + 'target-kconfig-init.h', + 'target-kconfig-has-gen.h', + 'target-kconfig-has.c.inc'], + depfile: 'target-kconfig.d', + command: [python, files('scripts/gen-target-kconfig.py'), + '--kconfig', meson.current_source_dir() / 'Kconfig', + '--depfile', '@DEPFILE@', + '--fields', '@OUTPUT0@', + '--init', '@OUTPUT1@', + '--has', '@OUTPUT2@', + '--has-c', '@OUTPUT3@']) if fdt_required.length() > 0 error('fdt disabled but required by targets ' + ', '.join(fdt_required)) @@ -3779,6 +3792,7 @@ endif qom_ss.add(files( 'target-info.c', + 'target-kconfig.c', )) qom_ss = qom_ss.apply({}) libqom = static_library('qom', qom_ss.sources() + genh, diff --git a/scripts/gen-target-kconfig.py b/scripts/gen-target-kconfig.py new file mode 100644 index 00000000000..afeffc75ca0 --- /dev/null +++ b/scripts/gen-target-kconfig.py @@ -0,0 +1,162 @@ +#!/usr/bin/env python3 +# SPDX-License-Identifier: GPL-2.0-or-later +"""Generate TargetKconfig CONFIG_* field, initializer, and has headers. + +The field list is every `config FOO` from the QEMU Kconfig tree, +parsed with scripts/minikconf.py (including accel/Kconfig: KVM, +XEN, HVF, TCG, ...). Host proxies in Kconfig.host and the +target/Kconfig tree (arch tokens and TARGET_BIG_ENDIAN) are +omitted. Target identity is TargetInfo, not TargetKconfig. + +Each field also gets target_has_kconfig_(const TargetInfo *). +""" + +import argparse +import os +import sys + +sys.path.insert(0, os.path.dirname(os.path.abspath(__file__))) +from minikconf import KconfigData, KconfigParser + + +def field_name(config: str) -> str: + return config[len("CONFIG_"):].lower() + + +def collect_from_kconfig(root: str) -> tuple[set[str], list[str]]: + data = KconfigData() + with open(root, "rt", encoding="utf-8") as fp: + KconfigParser.parse(fp, data) + names = {"CONFIG_" + name for name in data.defined_vars} + return names, list(data.previously_included) + + +def collect_kconfig_names(path: str) -> set[str]: + data = KconfigData() + with open(path, "rt", encoding="utf-8") as fp: + KconfigParser.parse(fp, data) + return {"CONFIG_" + name for name in data.defined_vars} + + +def collect_host_kconfig_names(kconfig_root: str) -> set[str]: + host = os.path.join(os.path.dirname(os.path.abspath(kconfig_root)), + "Kconfig.host") + return collect_kconfig_names(host) + + +def collect_target_kconfig_names(kconfig_root: str) -> set[str]: + target = os.path.join(os.path.dirname(os.path.abspath(kconfig_root)), + "target", "Kconfig") + return collect_kconfig_names(target) + + +def write_fields(path: str, configs: list[str]) -> None: + lines = [ + "/* Generated by scripts/gen-target-kconfig.py. Do not edit. */", + "", + ] + for name in configs: + lines.append(f" uint32_t {field_name(name)} : 1;") + lines.append("") + with open(path, "w", encoding="utf-8", newline="\n") as fh: + fh.write("\n".join(lines)) + + +def write_init(path: str, configs: list[str]) -> None: + lines = [ + "/* Generated by scripts/gen-target-kconfig.py. Do not edit. */", + "", + ] + for name in configs: + field = field_name(name) + lines.append(f"#if defined({name})") + lines.append(f" .{field} = true,") + lines.append("#endif") + lines.append("") + with open(path, "w", encoding="utf-8", newline="\n") as fh: + fh.write("\n".join(lines)) + + +def has_fn(config: str) -> str: + return "target_has_kconfig_" + field_name(config) + + +def write_has_h(path: str, configs: list[str]) -> None: + lines = [ + "/* Generated by scripts/gen-target-kconfig.py. Do not edit. */", + "", + "#ifndef TARGET_KCONFIG_HAS_GEN_H", + "#define TARGET_KCONFIG_HAS_GEN_H", + "", + "#include ", + "", + "typedef struct TargetInfo TargetInfo;", + "", + ] + for name in configs: + lines.append(f"bool {has_fn(name)}(const TargetInfo *ti);") + lines.append("") + lines.append("#endif") + lines.append("") + with open(path, "w", encoding="utf-8", newline="\n") as fh: + fh.write("\n".join(lines)) + + +def write_has_c(path: str, configs: list[str]) -> None: + lines = [ + "/* Generated by scripts/gen-target-kconfig.py. Do not edit. */", + "", + ] + for name in configs: + fn = has_fn(name) + field = field_name(name) + lines.append(f"bool {fn}(const TargetInfo *ti)") + lines.append("{") + lines.append(f" return ti->kconfig.{field};") + lines.append("}") + lines.append("") + with open(path, "w", encoding="utf-8", newline="\n") as fh: + fh.write("\n".join(lines)) + + +def write_depfile(path: str, outputs: list[str], deps: list[str]) -> None: + lines = [" ".join(outputs) + ":" ] + for dep in deps: + lines.append(f" {dep} \\") + if len(lines) > 1: + lines[-1] = lines[-1][:-2] + lines.append("") + with open(path, "w", encoding="utf-8", newline="\n") as fh: + fh.write("\n".join(lines)) + + +def main(argv: list[str]) -> int: + parser = argparse.ArgumentParser( + description="Generate TargetKconfig CONFIG_* include headers" + ) + parser.add_argument("--fields", required=True, help="output fields header") + parser.add_argument("--init", required=True, help="output initializer header") + parser.add_argument("--has", required=True, help="output has-function header") + parser.add_argument("--has-c", required=True, help="output has-function bodies") + parser.add_argument("--kconfig", required=True, help="root Kconfig") + parser.add_argument("--depfile", help="ninja depfile of walked Kconfig files") + args = parser.parse_args(argv) + + names, kconfig_files = collect_from_kconfig(args.kconfig) + names -= collect_host_kconfig_names(args.kconfig) + names -= collect_target_kconfig_names(args.kconfig) + configs = sorted(names) + + write_fields(args.fields, configs) + write_init(args.init, configs) + write_has_h(args.has, configs) + write_has_c(args.has_c, configs) + if args.depfile: + write_depfile(args.depfile, + [args.fields, args.init, args.has, args.has_c], + kconfig_files) + return 0 + + +if __name__ == "__main__": + sys.exit(main(sys.argv[1:])) diff --git a/target-info-def.c b/target-info-def.c index 954298b56d0..44d153cefbc 100644 --- a/target-info-def.c +++ b/target-info-def.c @@ -7,6 +7,9 @@ */ #include "qemu/osdep.h" +#ifdef CONFIG_DEVICES +#include CONFIG_DEVICES +#endif #include "qemu/target-info.h" #include "qemu/target-info-def.h" #include "cpu-qom.h" @@ -33,6 +36,9 @@ static const TargetInfo target_info_stub = { .page_bits_vary = false, .page_bits_init = TARGET_PAGE_BITS, #endif + .kconfig = { +#include "target-kconfig-init.h" + }, }; target_info_init(target_info_stub) diff --git a/target-kconfig.c b/target-kconfig.c new file mode 100644 index 00000000000..078c0d8e7f3 --- /dev/null +++ b/target-kconfig.c @@ -0,0 +1,20 @@ +/* + * QEMU target kconfig helpers + * + * Copyright (c) Yonggang Luo + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qemu/target-info.h" +#include "qemu/target-info-def.h" +#include "qemu/target-kconfig.h" +#include "qemu/target-kconfig-has.h" + +const TargetKconfig *target_kconfig(void) +{ + return &target_info()->kconfig; +} + +#include "target-kconfig-has.c.inc" diff --git a/tests/unit/meson.build b/tests/unit/meson.build index dc980a35955..c806dbc4ffa 100644 --- a/tests/unit/meson.build +++ b/tests/unit/meson.build @@ -47,6 +47,7 @@ tests = { objects: target_info_def_objects.values(), compile_args: ['-DTARGET_INFO_DEF_COUNT=@0@'.format( target_info_def_objects.values().length())])], + 'test-target-kconfig-has': [qom], 'test-qemu-opts': [], 'test-keyval': [testqapi], 'test-logging': [], diff --git a/tests/unit/test-target-kconfig-has.c b/tests/unit/test-target-kconfig-has.c new file mode 100644 index 00000000000..289ed89b854 --- /dev/null +++ b/tests/unit/test-target-kconfig-has.c @@ -0,0 +1,22 @@ +/* + * target-kconfig-has.h include path test + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qemu/target-kconfig-has.h" + +static void test_include(void) +{ + bool (*fn)(const TargetInfo *ti) = target_has_kconfig_tcg; + + g_assert_nonnull(fn); +} + +int main(int argc, char **argv) +{ + g_test_init(&argc, &argv, NULL); + g_test_add_func("/target-kconfig-has/include", test_include); + return g_test_run(); +} -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:19:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:19:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430452.1652954 (Exim 4.92) (envelope-from ) id 1x9MsK-00038p-Jk; Wed, 23 Sep 2026 13:19:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430452.1652954; Wed, 23 Sep 2026 13:19:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MsK-00038i-FN; Wed, 23 Sep 2026 13:19:04 +0000 Received: by outflank-mailman (input) for mailman id 1430452; Wed, 23 Sep 2026 13:19:03 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MsJ-000358-20 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:19:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MsI-009Ch3-FD for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:19:02 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d1c3-8faa-0a2a0a5109dd-0a2a4508ada8-16 for ; Wed, 23 Sep 2026 15:19:02 +0200 Received: from [74.125.229.140] (helo=mail-dl2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1c4-f659-0a2a45080019-4a7de58cb4c1-3 for ; Wed, 23 Sep 2026 15:19:02 +0200 Received: by mail-dl2-f12.google.com with SMTP id a92af1059eb24-142dd046b87so729350c88.2 for ; Wed, 23 Sep 2026 06:19:01 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.18.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:18:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169540; x=1790774340; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/Pnb4009fcr63720pQihUF6v8EokAjQS6rcfppqNlzc=; b=qwIx68aboq2H5bHUdmGRIxAsE+CUG8BNHN9/7dCEuuFlNs1ZEdfVi5WsqZTeBMM5nl 4qYjpq4UWO9xn8M5/qiqQLRppb6Gb077DYfoZocW5jeA6Y2uVzAP3t9cfwmLLn9S485v SY+KAfmw/Liw1s+CCyC6l9lyiEBqm0vhTcm3olPb6nWqhoviSvbKxzjTP0qNvuCd1LNZ T8NgfPQTtsTrcrwAiNYoRi1pIjcl6KfnILSsFsZWNcTRsd5PVwNpSEhvsH9W0H6MIPfQ lJfF4u1MOhec+PX8RGiPzpdcYGekpU/l+biqcDKs5764bRM++nbpIHMiBKDHLGC83CMG vmuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169540; x=1790774340; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=/Pnb4009fcr63720pQihUF6v8EokAjQS6rcfppqNlzc=; b=vYV1DUgeoxqmagCVguSeZl1HkfFWkZb2Sh5LKQUwYo+xBgi6DPRrdcyq53quCiWWzs Liun6G3Hcs3QjSLvnd5h4S7Y1aTSL4heztxy7I47wnCDE5gcxKOqolaMb8+rJG8uuojH pxZ1VnznlNFSWsH2tjbJPcYg579xVFz2Zqj+hBt76NFYcWhLkK1M83Rls6fQJw0259fc VprAstmHBPkTALAzrrC/Tk/4+j70XKGLF1TB/Mtj9cyDc9A9a2d4zZsl9VYh0dLVJtbb dJhZTlkygKqLEQS1cwrLmTgyys2Bd+pknvHx9b9tc8b2IBDYCJR26ALIP+wvdVfF5SLx zdKw== X-Forwarded-Encrypted: i=1; AKwUvBzzvd8N+jpiRQ58Jq+P2jR/CMao2UreGeh8msTqVJSCmOPpHQFR3nWVxotlICRIaUITUd1pf7441VY=@lists.xenproject.org X-Gm-Message-State: AFuF++k/vJS6EOJuqF75JvH89RKStKrn+SGgTCuFExSc3+ROExqpM8wS KpTqoqbsLC952gQD2YQs2B8PGzebEX+3mJLJOdq08xsNpyVoTzi8cFpE X-Gm-Gg: AYBFou2m8rOZJTe6nSYP6onhwjER9QlERTxHRSIbdmW4aHHxaCw31ktsaIUrigja0HH 5UuAlpSGe0TmGW401GAZuwNpIUMKEaOqbqH8+qu/HGT9McIF9r7ELRw/kXxI4uLi9pbnHSDwHrp Jsqq6//tAriANFpwHV3R5AfTwtSN0o/OgF/3Zcron4fu7DygqgzIIo1LTIskp+m0BpJEQPuMMqA 21Tj6spxNR2j86I6TV9yHE8Xh6ooKxLD//d1q0gtYCxHyqZO7/jRFeLqGILxtMdYDYBctxUWjOh hxu8csWGDnzMglUP7K0630r0NvF3PSd/LxfeNPnIZKBQ2wFCmSixyk1GjtiIwb5Z92ljMkSDFuw Em5zuPcKzZIABvwI2S5qiQlXgP359EwQ4QH6n0eNoBulOasloViV13IIwd1uB3CD22e+hEci1tT 0MkA0Nj8JFbL8VJQJICEHV6t4xLkeETDu5rWAsBOBjKg3ZsGTgObPOWEmIGsH3+ah/vAWfNEpA2 XvKoZS7ZDoB+K9lM3xIn5bpMmZ2z/k= X-Received: by 2002:a05:7022:fa9:b0:143:2973:3240 with SMTP id a92af1059eb24-144f91551e9mr4241198c88.29.1790169539996; Wed, 23 Sep 2026 06:18:59 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 013/114] target-info: add target_is_* helpers for each architecture Date: Wed, 23 Sep 2026 21:14:47 +0800 Message-ID: <20260923131635.1894-14-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790169542-CF55C87B-C0E75CE1/0/0 X-purgate-type: clean X-purgate-size: 6657 This is added for latter use with is_available. Signed-off-by: Yonggang Luo --- include/qemu/target-info.h | 91 +++++++++++++++++++++++++++++++++++++- target-info.c | 83 +++++++++++++++++++++++++++++----- 2 files changed, 161 insertions(+), 13 deletions(-) diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h index c48973f20be..89656da1ca4 100644 --- a/include/qemu/target-info.h +++ b/include/qemu/target-info.h @@ -53,6 +53,14 @@ const char *target_cpu_type(void); */ bool target_big_endian(void); +/** + * target_is_base_arm: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is ARM or Aarch64. + */ +bool target_is_base_arm(const TargetInfo *ti); + /** * target_base_arm: * @@ -60,6 +68,14 @@ bool target_big_endian(void); */ bool target_base_arm(void); +/** + * target_is_arm: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is ARM (32-bit, not Aarch64). + */ +bool target_is_arm(const TargetInfo *ti); + /** * target_arm: * @@ -67,6 +83,14 @@ bool target_base_arm(void); */ bool target_arm(void); +/** + * target_is_aarch64: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is Aarch64. + */ +bool target_is_aarch64(const TargetInfo *ti); + /** * target_aarch64: * @@ -74,6 +98,14 @@ bool target_arm(void); */ bool target_aarch64(void); +/** + * target_is_base_ppc: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is PowerPC 32-bit or 64-bit. + */ +bool target_is_base_ppc(const TargetInfo *ti); + /** * target_base_ppc: * @@ -81,6 +113,14 @@ bool target_aarch64(void); */ bool target_base_ppc(void); +/** + * target_is_ppc: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is PowerPC 32-bit. + */ +bool target_is_ppc(const TargetInfo *ti); + /** * target_ppc: * @@ -88,6 +128,14 @@ bool target_base_ppc(void); */ bool target_ppc(void); +/** + * target_is_ppc64: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is PowerPC 64-bit. + */ +bool target_is_ppc64(const TargetInfo *ti); + /** * target_ppc64: * @@ -95,6 +143,14 @@ bool target_ppc(void); */ bool target_ppc64(void); +/** + * target_is_s390x: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is S390x. + */ +bool target_is_s390x(const TargetInfo *ti); + /** * target_s390x: * @@ -102,17 +158,48 @@ bool target_ppc64(void); */ bool target_s390x(void); +/** + * target_is_base_riscv: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is RISC-V 32-bit or 64-bit. + */ +bool target_is_base_riscv(const TargetInfo *ti); + +/** + * target_base_riscv: + * + * Returns whether the target architecture is RISC-V 32-bit or 64-bit. + */ +bool target_base_riscv(void); + +/** + * target_is_riscv32: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is RISC-V 32-bit. + */ +bool target_is_riscv32(const TargetInfo *ti); + /** * target_riscv32: * - * Returns whether the target architecture is riscv32 + * Returns whether the target architecture is RISC-V 32-bit. */ bool target_riscv32(void); +/** + * target_is_riscv64: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is RISC-V 64-bit. + */ +bool target_is_riscv64(const TargetInfo *ti); + /** * target_riscv64: * - * Returns whether the target architecture is riscv64 + * Returns whether the target architecture is RISC-V 64-bit. */ bool target_riscv64(void); diff --git a/target-info.c b/target-info.c index 6e66f48e1ff..6d57cad5d33 100644 --- a/target-info.c +++ b/target-info.c @@ -96,9 +96,9 @@ bool target_big_endian(void) return target_endian_mode() == ENDIAN_MODE_BIG; } -bool target_base_arm(void) +bool target_is_base_arm(const TargetInfo *ti) { - switch (target_arch()) { + switch (ti->target_arch) { case SYS_EMU_TARGET_ARM: case SYS_EMU_TARGET_AARCH64: return true; @@ -107,19 +107,34 @@ bool target_base_arm(void) } } +bool target_base_arm(void) +{ + return target_is_base_arm(target_info()); +} + +bool target_is_arm(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_ARM; +} + bool target_arm(void) { - return target_arch() == SYS_EMU_TARGET_ARM; + return target_is_arm(target_info()); +} + +bool target_is_aarch64(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_AARCH64; } bool target_aarch64(void) { - return target_arch() == SYS_EMU_TARGET_AARCH64; + return target_is_aarch64(target_info()); } -bool target_base_ppc(void) +bool target_is_base_ppc(const TargetInfo *ti) { - switch (target_arch()) { + switch (ti->target_arch) { case SYS_EMU_TARGET_PPC: case SYS_EMU_TARGET_PPC64: return true; @@ -128,27 +143,73 @@ bool target_base_ppc(void) } } +bool target_base_ppc(void) +{ + return target_is_base_ppc(target_info()); +} + +bool target_is_ppc(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_PPC; +} + bool target_ppc(void) { - return target_arch() == SYS_EMU_TARGET_PPC; + return target_is_ppc(target_info()); +} + +bool target_is_ppc64(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_PPC64; } bool target_ppc64(void) { - return target_arch() == SYS_EMU_TARGET_PPC64; + return target_is_ppc64(target_info()); +} + +bool target_is_s390x(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_S390X; } bool target_s390x(void) { - return target_arch() == SYS_EMU_TARGET_S390X; + return target_is_s390x(target_info()); +} + +bool target_is_base_riscv(const TargetInfo *ti) +{ + switch (ti->target_arch) { + case SYS_EMU_TARGET_RISCV32: + case SYS_EMU_TARGET_RISCV64: + return true; + default: + return false; + } +} + +bool target_base_riscv(void) +{ + return target_is_base_riscv(target_info()); +} + +bool target_is_riscv32(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_RISCV32; } bool target_riscv32(void) { - return target_arch() == SYS_EMU_TARGET_RISCV32; + return target_is_riscv32(target_info()); +} + +bool target_is_riscv64(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_RISCV64; } bool target_riscv64(void) { - return target_arch() == SYS_EMU_TARGET_RISCV64; + return target_is_riscv64(target_info()); } -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:19:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:19:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430460.1652963 (Exim 4.92) (envelope-from ) id 1x9Msc-0003w8-15; Wed, 23 Sep 2026 13:19:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430460.1652963; Wed, 23 Sep 2026 13:19:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Msb-0003vx-U2; Wed, 23 Sep 2026 13:19:21 +0000 Received: by outflank-mailman (input) for mailman id 1430460; Wed, 23 Sep 2026 13:19:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Msa-0003qZ-4E for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:19:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MsZ-001trX-HC for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:19:19 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d1d2-e002-0a2a0a5209dd-0a2a45088f0e-20 for ; Wed, 23 Sep 2026 15:19:19 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1d5-f659-0a2a45080019-4a7de50cb91f-3 for ; Wed, 23 Sep 2026 15:19:19 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664ef783so542420eec.0 for ; Wed, 23 Sep 2026 06:19:18 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.19.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:19:07 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169557; x=1790774357; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZoknbnXiPKVvZXfcQ8PLlr7Gz40KHcVsCzqNeg5MeQU=; b=Pmlgkad40Nj6bAPahIrsidj6q9oS1RfMbbtINWjj3+hY5XI7iY/f+OjwPJlGJa6QOQ mGWq/OhQBB96I62sjSz+6AqCe8NKa79nLzxPQsdpo2IXk3O4ycntzR7KE0zy2NmGkX8a /wtq4oKunwoPzB/5uoQddaeQy1+SYZM3OYcmJIl0Lu88fvqvnbCzeEi/WjXtHDZ1MvAL KZhJ0G/FAP5/op+RCebeFoYnEBTQVaLZRFgtksbhHKaEAS6GbjKCNV0kyJJpYUo/r+6I QIS7bmrOC3LwN2DnhtQloRq/aSYgc/T2cMRa7Lt/MYxBel5dzecquK0U51qRO2vlChcJ sQzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169557; x=1790774357; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ZoknbnXiPKVvZXfcQ8PLlr7Gz40KHcVsCzqNeg5MeQU=; b=bSt+Vi65MeX6DFI2rUaPHXuA4oT220Zg+PKdOMwPAF6jD/zn0XDebzdOEjB93Jcm2L wsjS4CPnrVpCM5D8NfbbAaL4JNvtY82vXKzazmYly62LHw2aj3QVIwwHypKdcT23Q0Gx ajRLkh+LuAGbE0rbuUO0BR4A5RFh7961hWxl4gvisqTHe545Q0ShpVXdNrapU7Tm1wb0 y9VMbg4hioWYkMO0+x7bYxbK0gLVmEbD6CKuw0463Kf0/R5qr4wnSGxgVJD8sBXZHuoa 7DMoC0KdN7FZfiDkKk4IcKYO8MBH0oPveEbyQSIZTHnFWtWVW10GBbIvLNbgAP1kW5E6 U14g== X-Forwarded-Encrypted: i=1; AKwUvBw0IJE1piMIDn7mC6cEykr7hIMgi5op21DZr+eyp3XSKb0hvNdZlHv5QFI6jE5AzP6uPB2/2tyQJfo=@lists.xenproject.org X-Gm-Message-State: AFuF++m7DAy4rpdr9+kGt65fs27ZzCGax/QpXcLMF2nXeezBSxUnstBR YAt17NMP86pI4UWV0USs6K1qipuVdI6EFL6okBp30H5quegvmR+IUx73 X-Gm-Gg: AYBFou3NVTuaYRFdE6APzDLrsvoS9e9RcQzhCRltVeyo+zvShvFLgEkSlb2Nmn2MuML 2xktF7e0aFYTRMS057FhhU32cW1B17BkqdH/1xMbAihK/irYzUqwZPOG0lmnhe3kABC+hQGlbMk 4G1ksB43oT+9lgdl/WsN84ZYnN3S1lKOR9ATQB0RdTQdPqkO+xyGE2krc/vzvQgJC6t5SMRtVJr V4OsN0VaDM495m1RYEovRmAc+z6ZP9E15LidfbVr8JQIBaCWIlHLIzIYpGsQAtMDvpInnGcsbrc 50BF6DRyz3Q92jF1tE6FHAcbXG+8ssYnhvAKU3Jm/v4FqYKVIqSGc3fvyxK95C7sf39TQs2rbLg PULRdaZYKiZs9YgSHfQ5S/toUvldM+YHAiGpVpCvec1F8F5vTAKxaNeI+ey+MBNYDlV8F82L8Th bREDIfHM57o9xdKEbDKS5EcRnVTwretrnyoWhdkRw7WyqAxrUcc5vTyI5jRvksJDTcH8Qxj5RxT aFyT/k33B86ZcPZqe0fnZqMG6d6QHVX4JZ9oeERBg== X-Received: by 2002:a05:7300:dd05:b0:33b:eea2:cbfe with SMTP id 5a478bee46e88-33e8dec5b02mr2370454eec.32.1790169556543; Wed, 23 Sep 2026 06:19:16 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 014/114] target-info: add i386 and x86_64 helpers Date: Wed, 23 Sep 2026 21:14:48 +0800 Message-ID: <20260923131635.1894-15-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790169559-D497287B-E0D0FD19/0/0 X-purgate-type: clean X-purgate-size: 2573 This is added for latter use with is_available. Signed-off-by: Yonggang Luo --- include/qemu/target-info.h | 45 ++++++++++++++++++++++++++++++++++++++ target-info.c | 36 ++++++++++++++++++++++++++++++ 2 files changed, 81 insertions(+) diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h index 89656da1ca4..440da63e6cf 100644 --- a/include/qemu/target-info.h +++ b/include/qemu/target-info.h @@ -98,6 +98,51 @@ bool target_is_aarch64(const TargetInfo *ti); */ bool target_aarch64(void); +/** + * target_is_base_i386: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is i386 or x86_64. + */ +bool target_is_base_i386(const TargetInfo *ti); + +/** + * target_base_i386: + * + * Returns whether the target architecture is i386 or x86_64. + */ +bool target_base_i386(void); + +/** + * target_is_i386: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is i386 (32-bit, not x86_64). + */ +bool target_is_i386(const TargetInfo *ti); + +/** + * target_i386: + * + * Returns whether the target architecture is i386 (32-bit, not x86_64). + */ +bool target_i386(void); + +/** + * target_is_x86_64: + * @ti: TargetInfo to inspect + * + * Returns whether @ti is x86_64. + */ +bool target_is_x86_64(const TargetInfo *ti); + +/** + * target_x86_64: + * + * Returns whether the target architecture is x86_64. + */ +bool target_x86_64(void); + /** * target_is_base_ppc: * @ti: TargetInfo to inspect diff --git a/target-info.c b/target-info.c index 6d57cad5d33..36f75ece36f 100644 --- a/target-info.c +++ b/target-info.c @@ -132,6 +132,42 @@ bool target_aarch64(void) return target_is_aarch64(target_info()); } +bool target_is_base_i386(const TargetInfo *ti) +{ + switch (ti->target_arch) { + case SYS_EMU_TARGET_I386: + case SYS_EMU_TARGET_X86_64: + return true; + default: + return false; + } +} + +bool target_base_i386(void) +{ + return target_is_base_i386(target_info()); +} + +bool target_is_i386(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_I386; +} + +bool target_i386(void) +{ + return target_is_i386(target_info()); +} + +bool target_is_x86_64(const TargetInfo *ti) +{ + return ti->target_arch == SYS_EMU_TARGET_X86_64; +} + +bool target_x86_64(void) +{ + return target_is_x86_64(target_info()); +} + bool target_is_base_ppc(const TargetInfo *ti) { switch (ti->target_arch) { -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:19:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:19:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430464.1652973 (Exim 4.92) (envelope-from ) id 1x9Msk-0004LM-Bf; Wed, 23 Sep 2026 13:19:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430464.1652973; Wed, 23 Sep 2026 13:19:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Msk-0004LE-6b; Wed, 23 Sep 2026 13:19:30 +0000 Received: by outflank-mailman (input) for mailman id 1430464; Wed, 23 Sep 2026 13:19:28 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Msi-0004Jd-Pf for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:19:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Msi-00Dqip-61 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:19:28 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d1d6-bab6-0a2a0a5309dd-0a2a4505bf10-12 for ; Wed, 23 Sep 2026 15:19:28 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1de-4cb1-0a2a45050019-4a7de50cd27f-3 for ; Wed, 23 Sep 2026 15:19:27 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664c2da6so544677eec.1 for ; Wed, 23 Sep 2026 06:19:27 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.19.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:19:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169566; x=1790774366; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=wwD9DuwZG4f9q5/deLy+Fa9fAvUmV5QMi6qQxOTBcxg=; b=mGNSdVNjy4qSMPtWxo/di0gCMLmK+6vc2Ux+Rdy+e/3PTaUcdvH5CxeN8VjprwhYSv aySMVCdoQsdbSuiO5dt+IfHVo1wSpQr8/sXRjGViIIq7y7VYl3CbwNz2TFxCwLnd0TLa GeBJaWcmEnmePKM2TuiGyu4T1i6sfrJK6ZzMaxqvsuQ+5Fhz0gH0FGPhOKcUYzyM7fXx MRyfKgFADxdRZve5XHiqYd8QQxjZyrFBNzcf8JQD3pqGPibatUXS6wrJ6B9dA6em7ybG 0gTiHHE4ObOdEQ+CfT04e7RrmJMO+g2nn2nTjCqBRp+cr8NufJJyVd47EY2oro20uCG9 eH3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169566; x=1790774366; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=wwD9DuwZG4f9q5/deLy+Fa9fAvUmV5QMi6qQxOTBcxg=; b=Jg3mSB0y57J+Pq5RwTqv4SxeFSYTHnU+LZ8oloIQ/fRuLPQbJJYoJ8HMKJZ79UZSEO jvSRqcFP2fLpvdfeDeuT++Td4Ew0kk/Vu/xTDe2SWEDp+xJ0hNK/5/bvXsMG83R+0KR6 ZgArP/LdyDwQig+8xKrYlQWusz9pLfTsrxNmwqR/Byroehn0Gp2PcitOPDwpaAayYzXk 1VGaOthMrwSMvD6dQNXMwqQl9I0XIu38oSd7kmAr3O2e8Vs0opDFxser4Rw27ot2OKbz yEeFffwZwNcgnN+uX2/IMdn3P7mSPTfXPnj77HEOayuyXJbl/Eg1FIqCF0aMyOKlYVos 3j7Q== X-Forwarded-Encrypted: i=1; AKwUvBxUO/8BlomB4p+Fs2ZUKJV+f7D8UflQN8FZ7tn9qGZjvHkdSzWQssipTcJhOtlaSZoVIBSJoaA+4v8=@lists.xenproject.org X-Gm-Message-State: AFuF++kOTC4DaSyMQ1M9o7xwZiDwCBsb4lZNxaUpb5Pik+IEk9Yoa75A xFuQKzGiJaDB9ftfHw7GAhyXoDQ7lO0kNxXQwyw+4pRsV8fs4V1luXZj X-Gm-Gg: AYBFou3/k255MiI3snzD+bk5/+djqR6TdiW60h9j4xcIlHVGJJuDnxuKsG10A0il6xa pKpkBN7ipEBKgw4JUZ1z1l7IPThFKl39yDzjxPtanI8i3Z3yqHbcFx/7d8C2vImri+0vhdE9YlG D+TPtul+8Z/GAIcLAfT6W6iZO3mLgvZ5qNcKUSljcPveCSz3JoSO2kxZ0JbAPKoS8QC0mDgp5vK GQ97eJdKI9iOg2jrdPXDLwYoOUM9sXwzdLfH5IRG2jS2m3lafjc0SCs4Z32Ugy8iv3FH1gbFjNM A7dv3v/xzzipNIxsqG4j0eYOXCdI0icRgODioYI03UQiphHxarOi6hh61j8a2hm5od0/fxwJorq AYqhwGFrpQ5e2gjFjWiIHyjpkvpk/xak2cx+kt5o1j/OfcF+D1eOZhNy2iyx9kURHJ2fBuzJ27P e53t3jeurXl7nIfYrQ2oE2e7mocHNhICITcsJ3BJ9wXU1WHv4U96Wi8qMa4mrIVp/CPWrFXG50c MR0M35EcZM93gfda3YzZpZiFSybjco= X-Received: by 2002:a05:693c:638c:10b0:33e:6a54:b3ef with SMTP id 5a478bee46e88-33e8c05f69amr2514746eec.18.1790169565697; Wed, 23 Sep 2026 06:19:25 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 015/114] qom: pass TargetInfo to is_available Date: Wed, 23 Sep 2026 21:14:49 +0800 Message-ID: <20260923131635.1894-16-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790169568-F44A42A1-D7525A03/0/0 X-purgate-type: clean X-purgate-size: 13264 Change TypeInfo.is_available to TypeIsAvailable taking const TargetInfo *. Store the callback on TypeImpl and add object_class_get_is_available. ARM and RISC-V machines use target_is_aarch64(), target_is_riscv32(), and target_is_riscv64(). object.h includes target-info.h. Signed-off-by: Yonggang Luo --- hw/arm/aspeed_ast27x0-fc.c | 2 +- hw/arm/aspeed_ast27x0_evb.c | 4 ++-- hw/arm/raspi.c | 4 ++-- hw/arm/raspi4b.c | 2 +- hw/riscv/boston-aia.c | 4 ++-- hw/riscv/k230.c | 4 ++-- hw/riscv/microchip_pfsoc.c | 4 ++-- hw/riscv/opentitan.c | 4 ++-- hw/riscv/shakti_c.c | 4 ++-- hw/riscv/tt_atlantis.c | 4 ++-- hw/riscv/xiangshan_kmh.c | 4 ++-- include/qom/object.h | 27 ++++++++++++++++++++++++--- qom/object.c | 11 ++++++++++- 13 files changed, 54 insertions(+), 24 deletions(-) diff --git a/hw/arm/aspeed_ast27x0-fc.c b/hw/arm/aspeed_ast27x0-fc.c index 73362b60d2a..8a7c6a116ac 100644 --- a/hw/arm/aspeed_ast27x0-fc.c +++ b/hw/arm/aspeed_ast27x0-fc.c @@ -234,7 +234,7 @@ static const TypeInfo ast2700fc_types[] = { .parent = TYPE_MACHINE, .class_init = ast2700fc_class_init, .instance_size = sizeof(Ast2700FCState), - .is_available = target_aarch64, + .is_available = target_is_aarch64, }, }; diff --git a/hw/arm/aspeed_ast27x0_evb.c b/hw/arm/aspeed_ast27x0_evb.c index 460c9ff0d2e..02a8cff1d9d 100644 --- a/hw/arm/aspeed_ast27x0_evb.c +++ b/hw/arm/aspeed_ast27x0_evb.c @@ -75,13 +75,13 @@ static const TypeInfo aspeed_ast27x0_evb_types[] = { .name = MACHINE_TYPE_NAME("ast2700a1-evb"), .parent = TYPE_ASPEED_MACHINE, .class_init = aspeed_machine_ast2700a1_evb_class_init, - .is_available = target_aarch64, + .is_available = target_is_aarch64, }, { .name = MACHINE_TYPE_NAME("ast2700a2-evb"), .parent = TYPE_ASPEED_MACHINE, .class_init = aspeed_machine_ast2700a2_evb_class_init, - .is_available = target_aarch64, + .is_available = target_is_aarch64, } }; diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c index fadbacb2534..22b06c6ca22 100644 --- a/hw/arm/raspi.c +++ b/hw/arm/raspi.c @@ -403,12 +403,12 @@ static const TypeInfo raspi_machine_types[] = { .name = MACHINE_TYPE_NAME("raspi3ap"), .parent = TYPE_RASPI_MACHINE, .class_init = raspi3ap_machine_class_init, - .is_available = target_aarch64, + .is_available = target_is_aarch64, }, { .name = MACHINE_TYPE_NAME("raspi3b"), .parent = TYPE_RASPI_MACHINE, .class_init = raspi3b_machine_class_init, - .is_available = target_aarch64, + .is_available = target_is_aarch64, }, { .name = TYPE_RASPI_MACHINE, .parent = TYPE_RASPI_BASE_MACHINE, diff --git a/hw/arm/raspi4b.c b/hw/arm/raspi4b.c index 566d64572db..a1dc477f25e 100644 --- a/hw/arm/raspi4b.c +++ b/hw/arm/raspi4b.c @@ -121,7 +121,7 @@ static const TypeInfo raspi4b_machine_type = { .parent = TYPE_RASPI_BASE_MACHINE, .instance_size = sizeof(Raspi4bMachineState), .class_init = raspi4b_machine_class_init, - .is_available = target_aarch64, + .is_available = target_is_aarch64, }; static void raspi4b_machine_register_type(void) diff --git a/hw/riscv/boston-aia.c b/hw/riscv/boston-aia.c index ba16b7dbc69..2618b424efe 100644 --- a/hw/riscv/boston-aia.c +++ b/hw/riscv/boston-aia.c @@ -468,14 +468,14 @@ static const TypeInfo boston_types[] = { .name = TYPE_MIPS_BOSTON_AIA, .parent = TYPE_SYS_BUS_DEVICE, .instance_size = sizeof(BostonState), - .is_available = target_riscv64, + .is_available = target_is_riscv64, }, { .name = MACHINE_TYPE_NAME("boston-aia"), .parent = TYPE_MACHINE, .class_init = boston_mach_class_init, .instance_size = sizeof(MachineState), - .is_available = target_riscv64, + .is_available = target_is_riscv64, }, }; diff --git a/hw/riscv/k230.c b/hw/riscv/k230.c index 43b6ae6d2f2..79715265da6 100644 --- a/hw/riscv/k230.c +++ b/hw/riscv/k230.c @@ -421,7 +421,7 @@ static const TypeInfo k230_soc_type_info = { .instance_size = sizeof(K230SoCState), .instance_init = k230_soc_init, .class_init = k230_soc_class_init, - .is_available = target_riscv64, + .is_available = target_is_riscv64, }; static void k230_soc_register_types(void) @@ -560,7 +560,7 @@ static const TypeInfo k230_machine_typeinfo = { .class_init = k230_machine_class_init, .instance_init = k230_machine_instance_init, .instance_size = sizeof(K230MachineState), - .is_available = target_riscv64, + .is_available = target_is_riscv64, }; static void k230_machine_init_register_types(void) diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c index b2991e5a710..cc4b6bc3529 100644 --- a/hw/riscv/microchip_pfsoc.c +++ b/hw/riscv/microchip_pfsoc.c @@ -505,7 +505,7 @@ static const TypeInfo microchip_pfsoc_soc_type_info = { .instance_size = sizeof(MicrochipPFSoCState), .instance_init = microchip_pfsoc_soc_instance_init, .class_init = microchip_pfsoc_soc_class_init, - .is_available = target_riscv64, + .is_available = target_is_riscv64, }; static void microchip_pfsoc_soc_register_types(void) @@ -759,7 +759,7 @@ static const TypeInfo microchip_icicle_kit_machine_typeinfo = { .class_init = microchip_icicle_kit_machine_class_init, .instance_init = microchip_icicle_kit_machine_instance_init, .instance_size = sizeof(MicrochipIcicleKitState), - .is_available = target_riscv64, + .is_available = target_is_riscv64, }; static void microchip_icicle_kit_machine_init_register_types(void) diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c index c3a563db926..9e3db34eed9 100644 --- a/hw/riscv/opentitan.c +++ b/hw/riscv/opentitan.c @@ -333,13 +333,13 @@ static const TypeInfo open_titan_types[] = { .instance_size = sizeof(LowRISCIbexSoCState), .instance_init = lowrisc_ibex_soc_init, .class_init = lowrisc_ibex_soc_class_init, - .is_available = target_riscv32, + .is_available = target_is_riscv32, }, { .name = TYPE_OPENTITAN_MACHINE, .parent = TYPE_MACHINE, .instance_size = sizeof(OpenTitanState), .class_init = opentitan_machine_class_init, - .is_available = target_riscv32, + .is_available = target_is_riscv32, } }; diff --git a/hw/riscv/shakti_c.c b/hw/riscv/shakti_c.c index 76cfe30918a..0f96258b764 100644 --- a/hw/riscv/shakti_c.c +++ b/hw/riscv/shakti_c.c @@ -98,7 +98,7 @@ static const TypeInfo shakti_c_machine_type_info = { .class_init = shakti_c_machine_class_init, .instance_init = shakti_c_machine_instance_init, .instance_size = sizeof(ShaktiCMachineState), - .is_available = target_riscv64, + .is_available = target_is_riscv64, }; static void shakti_c_machine_type_info_register(void) @@ -188,7 +188,7 @@ static const TypeInfo shakti_c_type_info = { .class_init = shakti_c_soc_class_init, .instance_init = shakti_c_soc_instance_init, .instance_size = sizeof(ShaktiCSoCState), - .is_available = target_riscv64, + .is_available = target_is_riscv64, }; static void shakti_c_type_info_register(void) diff --git a/hw/riscv/tt_atlantis.c b/hw/riscv/tt_atlantis.c index f54eb942f37..086e95bd2d1 100644 --- a/hw/riscv/tt_atlantis.c +++ b/hw/riscv/tt_atlantis.c @@ -695,13 +695,13 @@ static const TypeInfo tt_atlantis_types[] = { .instance_size = sizeof(TTAtlantisSoCState), .instance_init = tt_atlantis_soc_init, .class_init = tt_atlantis_soc_class_init, - .is_available = target_riscv64, + .is_available = target_is_riscv64, }, { .name = MACHINE_TYPE_NAME("tt-atlantis"), .parent = TYPE_MACHINE, .class_init = tt_atlantis_machine_class_init, .instance_size = sizeof(TTAtlantisState), - .is_available = target_riscv64, + .is_available = target_is_riscv64, }, }; diff --git a/hw/riscv/xiangshan_kmh.c b/hw/riscv/xiangshan_kmh.c index f2383c53993..6bc669421fe 100644 --- a/hw/riscv/xiangshan_kmh.c +++ b/hw/riscv/xiangshan_kmh.c @@ -158,7 +158,7 @@ static const TypeInfo xiangshan_kmh_soc_info = { .instance_size = sizeof(XiangshanKmhSoCState), .instance_init = xiangshan_kmh_soc_instance_init, .class_init = xiangshan_kmh_soc_class_init, - .is_available = target_riscv64, + .is_available = target_is_riscv64, }; static void xiangshan_kmh_soc_register_types(void) @@ -222,7 +222,7 @@ static const TypeInfo xiangshan_kmh_machine_info = { .parent = TYPE_MACHINE, .instance_size = sizeof(XiangshanKmhState), .class_init = xiangshan_kmh_machine_class_init, - .is_available = target_riscv64, + .is_available = target_is_riscv64, }; static void xiangshan_kmh_machine_register_types(void) diff --git a/include/qom/object.h b/include/qom/object.h index 4c0645817a5..f2dc22f0eb0 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -16,6 +16,7 @@ #include "qapi/qapi-builtin-types.h" #include "qemu/module.h" +#include "qemu/target-info.h" struct TypeImpl; typedef struct TypeImpl *Type; @@ -117,6 +118,15 @@ typedef void (ObjectUnparent)(Object *obj); */ typedef void (ObjectFree)(void *obj); +/** + * typedef TypeIsAvailable: + * @ti: TargetInfo to test. + * + * Returns whether a type is available for @ti. Typical implementations + * are target_is_*(). + */ +typedef bool (TypeIsAvailable)(const TargetInfo *ti); + #define OBJECT_CLASS_CAST_CACHE 4 /** @@ -473,8 +483,10 @@ struct Object * @class_data: Data to pass to the @class_init, * @class_base_init. This can be useful when building dynamic * classes. - * @is_available: callback invoked at registration time, to dynamically check if - * this type should be available or not. + * @is_available: Optional callback. Unset inherits the parent type's + * callback in the MODULE_INIT_QOM after pass (parents are not all + * registered at type_register time). After inherit the callback is + * never NULL. Callers may also invoke it with a chosen TargetInfo. * @interfaces: The list of interfaces associated with this type. This * should point to a static array that's terminated with a zero filled * element. @@ -498,7 +510,7 @@ struct TypeInfo void (*class_base_init)(ObjectClass *klass, const void *data); const void *class_data; - bool (*is_available)(void); + TypeIsAvailable *is_available; const InterfaceInfo *interfaces; }; @@ -1087,6 +1099,15 @@ bool object_class_is_abstract(ObjectClass *klass); */ bool object_class_is_secure(ObjectClass *klass); +/** + * object_class_get_is_available: + * @klass: The class to obtain TypeInfo.is_available for. + * + * Returns: The availability callback (own or inherited from a parent). + * Never %NULL after MODULE_INIT_QOM inherit. + */ +TypeIsAvailable *object_class_get_is_available(ObjectClass *klass); + /** * object_class_by_name: * @typename: The QOM typename to obtain the class for. diff --git a/qom/object.c b/qom/object.c index 96498f3d001..a3e75927e82 100644 --- a/qom/object.c +++ b/qom/object.c @@ -15,6 +15,7 @@ #include "qom/compat-properties.h" #include "qom/object.h" #include "qom/object_interfaces.h" +#include "qemu/target-info-qapi.h" #include "qemu/cutils.h" #include "qemu/memalign.h" #include "qapi/visitor.h" @@ -71,6 +72,8 @@ struct TypeImpl bool abstract; bool secure; + TypeIsAvailable *is_available; + const char *parent; TypeImpl *parent_type; @@ -126,6 +129,7 @@ static TypeImpl *type_new(const TypeInfo *info) ti->abstract = info->abstract; ti->secure = info->secure; + ti->is_available = info->is_available; for (i = 0; info->interfaces && info->interfaces[i].type; i++) { ti->interfaces[i].typename = g_strdup(info->interfaces[i].type); @@ -167,7 +171,7 @@ static TypeImpl *type_register_internal(const TypeInfo *info) abort(); } - if (info->is_available && !info->is_available()) { + if (info->is_available && !info->is_available(target_info())) { return NULL; } @@ -1153,6 +1157,11 @@ bool object_class_is_secure(ObjectClass *klass) return klass->type->secure; } +TypeIsAvailable *object_class_get_is_available(ObjectClass *klass) +{ + return klass->type->is_available; +} + const char *object_class_get_name(ObjectClass *klass) { return klass->type->name; -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:19:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:19:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430468.1652981 (Exim 4.92) (envelope-from ) id 1x9Msw-0004so-I5; Wed, 23 Sep 2026 13:19:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430468.1652981; Wed, 23 Sep 2026 13:19: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 1x9Msw-0004sf-E7; Wed, 23 Sep 2026 13:19:42 +0000 Received: by outflank-mailman (input) for mailman id 1430468; Wed, 23 Sep 2026 13:19:40 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Msu-0004om-H7 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:19:40 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mst-00Dqlx-UE for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:19:39 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d1e9-bab6-0a2a0a5309dd-0a2a4502c13e-16 for ; Wed, 23 Sep 2026 15:19:39 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1ea-6ca4-0a2a45020019-4a7de52bab7f-3 for ; Wed, 23 Sep 2026 15:19:39 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-33e630052ebso1066083eec.0 for ; Wed, 23 Sep 2026 06:19:39 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.19.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:19:33 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169578; x=1790774378; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=XCBFYSF9Q0sqUJeK2F1X4ZcpeRW05ELn0GxDHlBCHlc=; b=aXnDru3Lk4n58iKDb4Hf/09NLduiEY86ZCqq0FCh6074qHJgOG9X+yj55HQLE01Tla ReHNINZPRZRJXi3i7UKGFFViqWZ/+YgCfUVSXoSqb0aFbOCABCFap1Yz20BrqwZD3CuC T/5kgXDu0kgLNspsXZ6frMYWyzqB/i1bIYEUK4vOE9EzGUK8kzqmrHyVOp4OGLjjPgc1 CnTTSpEHDcg25STy2BfVBsq8RQLHwOiHG/es3eHS92Cx/X/dAlPssrlTw41gf29lpuQH EVuVmNy6BmOODd6t6RXlVjjsQZeE5IOOsSM+JQrW6254PdXXdHg8UTxyQRJof1YzEd5v XTMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169578; x=1790774378; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=XCBFYSF9Q0sqUJeK2F1X4ZcpeRW05ELn0GxDHlBCHlc=; b=m9/plFnpegxpA9p8xr38R8rL233IF8UjEXYRkv2WIwT9HiV6k6MQ6iAfh62IspXwMM JkX7oT5aD8P8UmeCTp+Q/C2MMMQksf6HbcnfjuFTiHP4xZetX8uIIkqQ4YwB4caW0MYt 7qp2upXpGxw0I+dtug+61XlfzH4SESuglEgrpnemuG7+dl/W/q6koUewQ+pFw0QqlBRV ORxuyOvg9tHJ/yrpNNmBUhhzX83hZZAy3EQESWYUFbhcO9dNl9x9FsYmEzw6r+3S47D9 gfJugcl6sz5t+69HBGVggqiRaOeEbLtAVsZTYF/uIvvbWj6z9Wm2EJe5PzkFKhYJb4gZ cg0g== X-Forwarded-Encrypted: i=1; AKwUvByzymUqSgmT4jFiJlBUQjBIjl5gwNBaWexDDuJzu+Zel+Mp8j1saoPlzMas/d2Q1fdIvd1AtlPREdM=@lists.xenproject.org X-Gm-Message-State: AFuF++lw715iUOOVeTE9XHBQXnJL4KqshPIajWRkEmjP7bL91QsGK1hw 4M638ubuf63WpGnFa9A37fKkjgcXsvX2Jcjo+LHIDNEAqNWemiachscv X-Gm-Gg: AYBFou3wMahfWXjU/4bsSO3wOep2FjLBVq386s60WyUuXd/zsNFAki3uvVcQW+c6lbT 7sNYS14OQbCdgwdUh+lsCXfWPU7r3k7N7xk8zAkliDkh/2SCvSCGuP98ucuHyrvWThsq61Kxqxw UtIQirwoPERK4uBbgUVrtV9U9cC7gb6SHqgtBmRuEc4sC6FIZfrdN6SDYY9Nga7Cvv1dEHsUSA1 mIASFbS8uIFeStPnebPJKnB1pPmMQOv/UqyVQtZ3GIXCkmODv6+WkuQZEd0FBPSZLPBRLQ5JuIK L8lGpThThhmd1YTqaxkB/Hnlkyyphbr8MRXNpe+b6xX++0Ge7wKwjLqjJblvtJIoY5ZoY9MSP07 VZP2HtNV4/9qV+7yyS+gY8CRT13RTDyV/qu2pwPRp63QawUCE99UnCql38xU8HjYqBej3usFSsX s8AXcfzYQf3M2heYCTqo49XoI+OcFCSGzL7B0NfvXZoVu5o+6F8kmmK4229D31KiD+HTFijhbSA ALxMVKrV92cR7pzauiKBWaM9aS+9sCFZrFl+o63Dw== X-Received: by 2002:a05:693c:41c1:10b0:33e:84c3:a05b with SMTP id 5a478bee46e88-33e8ddc79bcmr2415216eec.30.1790169577497; Wed, 23 Sep 2026 06:19:37 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 016/114] module: use static ModuleEntry and per-type DSO lists Date: Wed, 23 Sep 2026 21:14:50 +0800 Message-ID: <20260923131635.1894-17-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790169579-30FCE2AC-BE38EDF4/0/0 X-purgate-type: clean X-purgate-size: 10566 register_module_init malloc'd a ModuleEntry and a late DSO ran from one shared list. Store each module_init in a static ModuleEntry and keep a dso_list per init type. Concatenate a late DSO onto the builtin list when that type is not done yet, otherwise run it immediately. Signed-off-by: Yonggang Luo --- include/qemu/module.h | 22 ++++++-- include/qemu/queue.h | 10 ++++ rust/util/src/module.rs | 16 ++++-- util/module.c | 109 ++++++++++++++++++++++------------------ 4 files changed, 98 insertions(+), 59 deletions(-) diff --git a/include/qemu/module.h b/include/qemu/module.h index 9885ac9afb3..34e05c75348 100644 --- a/include/qemu/module.h +++ b/include/qemu/module.h @@ -14,6 +14,7 @@ #ifndef QEMU_MODULE_H #define QEMU_MODULE_H +#include "qemu/queue.h" #define DSO_STAMP_FUN glue(qemu_stamp, CONFIG_STAMP) #define DSO_STAMP_FUN_STR stringify(DSO_STAMP_FUN) @@ -26,16 +27,22 @@ void DSO_STAMP_FUN(void); void qemu_module_dummy(void); #define module_init(function, type) \ +static ModuleEntry glue(qemu_module_entry_, function) = { \ + .init = function, \ +}; \ static void __attribute__((constructor)) do_qemu_init_ ## function(void) \ { \ - register_dso_module_init(function, type); \ + register_dso_module_init(&glue(qemu_module_entry_, function), type); \ } #else /* This should not be used directly. Use block_init etc. instead. */ #define module_init(function, type) \ +static ModuleEntry glue(qemu_module_entry_, function) = { \ + .init = function, \ +}; \ static void __attribute__((constructor)) do_qemu_init_ ## function(void) \ { \ - register_module_init(function, type); \ + register_module_init(&glue(qemu_module_entry_, function), type); \ } #endif @@ -51,6 +58,13 @@ typedef enum { MODULE_INIT_MAX } module_init_type; +typedef void (ModuleInitFn)(void); + +typedef struct ModuleEntry { + ModuleInitFn *init; + QTAILQ_ENTRY(ModuleEntry) node; +} ModuleEntry; + #define block_init(function) module_init(function, MODULE_INIT_BLOCK) #define opts_init(function) module_init(function, MODULE_INIT_OPTS) #define type_init(function) module_init(function, MODULE_INIT_QOM) @@ -64,8 +78,8 @@ typedef enum { #define block_module_load(lib, errp) module_load("block-", lib, errp) #define ui_module_load(lib, errp) module_load("ui-", lib, errp) -void register_module_init(void (*fn)(void), module_init_type type); -void register_dso_module_init(void (*fn)(void), module_init_type type); +void register_module_init(ModuleEntry *e, module_init_type type); +void register_dso_module_init(ModuleEntry *e, module_init_type type); void module_call_init(module_init_type type); diff --git a/include/qemu/queue.h b/include/qemu/queue.h index e029e7bf669..06ebe8b1dfc 100644 --- a/include/qemu/queue.h +++ b/include/qemu/queue.h @@ -470,6 +470,16 @@ union { \ (left)->field.tqe_circ.tql_prev->tql_next = (right)->field.tqe_next; \ } while (/*CONSTCOND*/0) +#define QTAILQ_CONCAT(head1, head2, field) do { \ + if (!QTAILQ_EMPTY(head2)) { \ + (head1)->tqh_circ.tql_prev->tql_next = (head2)->tqh_first; \ + (head2)->tqh_first->field.tqe_circ.tql_prev = \ + (head1)->tqh_circ.tql_prev; \ + (head1)->tqh_circ.tql_prev = (head2)->tqh_circ.tql_prev; \ + QTAILQ_INIT(head2); \ + } \ +} while (/*CONSTCOND*/0) + #define QTAILQ_FOREACH(var, head, field) \ for ((var) = ((head)->tqh_first); \ (var); \ diff --git a/rust/util/src/module.rs b/rust/util/src/module.rs index 06c45fc142b..45d8b67d6dc 100644 --- a/rust/util/src/module.rs +++ b/rust/util/src/module.rs @@ -8,6 +8,16 @@ macro_rules! module_init { ($type:ident => $body:block) => { const _: () = { + extern "C" fn init_fn() { + $body + } + + static mut ENTRY: $crate::bindings::ModuleEntry = + $crate::bindings::ModuleEntry { + init: Some(init_fn), + ..unsafe { ::core::mem::zeroed() } + }; + #[used] #[cfg_attr( not(any(target_vendor = "apple", target_os = "windows")), @@ -16,14 +26,10 @@ macro_rules! module_init { #[cfg_attr(target_vendor = "apple", link_section = "__DATA,__mod_init_func")] #[cfg_attr(target_os = "windows", link_section = ".CRT$XCU")] pub static LOAD_MODULE: extern "C" fn() = { - extern "C" fn init_fn() { - $body - } - extern "C" fn ctor_fn() { unsafe { $crate::bindings::register_module_init( - Some(init_fn), + ::core::ptr::addr_of_mut!(ENTRY), $crate::bindings::module_init_type::$type, ); } diff --git a/util/module.c b/util/module.c index 8f8e6994f11..6c5980542f6 100644 --- a/util/module.c +++ b/util/module.c @@ -27,19 +27,26 @@ #endif #include "trace.h" -typedef struct ModuleEntry +typedef QTAILQ_HEAD(, ModuleEntry) ModuleEntryList; + +typedef struct ModuleInit { - void (*init)(void); - QTAILQ_ENTRY(ModuleEntry) node; module_init_type type; -} ModuleEntry; + ModuleEntryList list; + ModuleEntryList dso_list; + bool done; +} ModuleInit; -typedef QTAILQ_HEAD(, ModuleEntry) ModuleTypeList; +static ModuleInit module_inits[MODULE_INIT_MAX]; -static ModuleTypeList init_type_list[MODULE_INIT_MAX]; -static bool modules_init_done[MODULE_INIT_MAX]; +static void empty_dso_lists(void) +{ + int i; -static ModuleTypeList dso_init_list; + for (i = 0; i < MODULE_INIT_MAX; i++) { + QTAILQ_INIT(&module_inits[i].dso_list); + } +} static void init_lists(void) { @@ -51,65 +58,56 @@ static void init_lists(void) } for (i = 0; i < MODULE_INIT_MAX; i++) { - QTAILQ_INIT(&init_type_list[i]); + module_inits[i].type = i; + QTAILQ_INIT(&module_inits[i].list); } - - QTAILQ_INIT(&dso_init_list); + empty_dso_lists(); inited = 1; } - -static ModuleTypeList *find_type(module_init_type type) +static ModuleInit *find_type(module_init_type type) { init_lists(); - return &init_type_list[type]; + return &module_inits[type]; } -void register_module_init(void (*fn)(void), module_init_type type) +static void module_init_add(ModuleEntryList *list, ModuleEntry *e) { - ModuleEntry *e; - ModuleTypeList *l; - - e = g_malloc0(sizeof(*e)); - e->init = fn; - e->type = type; + QTAILQ_INSERT_TAIL(list, e, node); +} - l = find_type(type); +void register_module_init(ModuleEntry *e, module_init_type type) +{ + module_init_add(&find_type(type)->list, e); +} - QTAILQ_INSERT_TAIL(l, e, node); +void register_dso_module_init(ModuleEntry *e, module_init_type type) +{ + module_init_add(&find_type(type)->dso_list, e); } -void register_dso_module_init(void (*fn)(void), module_init_type type) +static void module_init_run(ModuleInit *m, ModuleEntryList *list) { ModuleEntry *e; - init_lists(); - - e = g_malloc0(sizeof(*e)); - e->init = fn; - e->type = type; - - QTAILQ_INSERT_TAIL(&dso_init_list, e, node); + (void)m; + QTAILQ_FOREACH(e, list, node) { + e->init(); + } } void module_call_init(module_init_type type) { - ModuleTypeList *l; - ModuleEntry *e; + ModuleInit *m = find_type(type); - if (modules_init_done[type]) { + if (m->done) { return; } - l = find_type(type); - - QTAILQ_FOREACH(e, l, node) { - e->init(); - } - - modules_init_done[type] = true; + module_init_run(m, &m->list); + m->done = true; } #ifdef CONFIG_MODULES @@ -159,10 +157,13 @@ static bool module_load_dso(const char *fname, bool export_symbols, { GModule *g_module; void (*sym)(void); - ModuleEntry *e, *next; + int i; int flags; - assert(QTAILQ_EMPTY(&dso_init_list)); + init_lists(); + for (i = 0; i < MODULE_INIT_MAX; i++) { + assert(QTAILQ_EMPTY(&module_inits[i].dso_list)); + } flags = 0; if (!export_symbols) { @@ -183,19 +184,27 @@ static bool module_load_dso(const char *fname, bool export_symbols, error_append_hint(errp, "Only modules from the same build can be loaded.\n"); } + empty_dso_lists(); g_module_close(g_module); return false; } - QTAILQ_FOREACH(e, &dso_init_list, node) { - e->init(); - register_module_init(e->init, e->type); + for (i = 0; i < MODULE_INIT_MAX; i++) { + ModuleInit *m = &module_inits[i]; + + if (QTAILQ_EMPTY(&m->dso_list)) { + continue; + } + + if (!m->done) { + QTAILQ_CONCAT(&m->list, &m->dso_list, node); + continue; + } + + module_init_run(m, &m->dso_list); } trace_module_load_module(fname); - QTAILQ_FOREACH_SAFE(e, &dso_init_list, node, next) { - QTAILQ_REMOVE(&dso_init_list, e, node); - g_free(e); - } + empty_dso_lists(); return true; } -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:19:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:19:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430477.1652990 (Exim 4.92) (envelope-from ) id 1x9Mt7-0005RF-SZ; Wed, 23 Sep 2026 13:19:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430477.1652990; Wed, 23 Sep 2026 13:19:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mt7-0005R8-P2; Wed, 23 Sep 2026 13:19:53 +0000 Received: by outflank-mailman (input) for mailman id 1430477; Wed, 23 Sep 2026 13:19:53 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mt7-0005QF-7k for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:19:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mt6-00Dqoq-Ko for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:19:52 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d1f4-bab6-0a2a0a5309dd-0a2a4506c18e-16 for ; Wed, 23 Sep 2026 15:19:52 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1f7-195a-0a2a45060019-4a7de50c91e6-3 for ; Wed, 23 Sep 2026 15:19:52 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-32dbbe82e13so792389eec.0 for ; Wed, 23 Sep 2026 06:19:51 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.19.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:19:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169590; x=1790774390; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=kG8T0B41yOsfKs7+mPQWY4VwYoc5DWh5xeT8YOfa6ig=; b=OZKuO9doxlu4czHwgw4/o9yxizw54tDVfoSTRmNCGzO1qrpTRqGDERPoTwCwUv1QSW dabFP8NRH70EWJTrjhAkub2nkVpG6HDiVkcEVv6zh38wmJCJmywv3ihIyASfkX4a2yZa X9DIK2mEGHi25o4VCcilsGcSpEaMV9Cj8uLa6Aqr39+ppDSpFHkhNhQrDfji+y+yWqGm j5gaw7C0XNRW9UHdLI+ikiztboR1FtFCOwQD/VyFbqiLTbRwbMK8qxu46ZpYBnNPQH/s 3Vo11vBiI0iyevLKrj4u2wUVtskZ897bR/dN9StqilY2VGjW9LIDVp1IYGO8o6INa0kB 2+tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169590; x=1790774390; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=kG8T0B41yOsfKs7+mPQWY4VwYoc5DWh5xeT8YOfa6ig=; b=OT0ijt4RF7gCCAkbMLqypyiQA/pOxkNqQVrETsow/M6VQgmcRLTKPuE4s2OiLMxg6D XAGd19yNHHwUus/xGKRQ3ku5EO1fGG02ARG/YjSYwR2rPKj+gV1lQU82v6yVM/igUcjj Ro7uqsu2q2JIMiybn08IbBvuW/FvIAPnGR9qbCxy7JeFmhjc1jRz883EkKCn4ocqrp8y ZPVmWo24nFQL5U9ejtjnI27qkEqzYdG29hdQWRi4WRQTGUDYcWsKAJq29ZR0l+rauvtP LysKBWDtFCE4Em9tV4qBsREURuz82XHouyGyHM2rj9CU7MROAn+mdeq13/sDCrYNe8HS oV0Q== X-Forwarded-Encrypted: i=1; AKwUvByw7iAjXtIa355Im0zpjMJ6fAOfelaaUFOZ/WwUuak/iZ2+OQGjqKDvUHnE+NEUrp4qFkYC5IQ1TqM=@lists.xenproject.org X-Gm-Message-State: AFuF++kxyRXfNwtNjyPLwuop4gfa4xKG066n8cfzP0OvzsxCRsxb4s/d trm4NEqgKEDqIEM6RdA477al52vATJXJFOIXy2V5P66dMxGKbVabOYjp X-Gm-Gg: AYBFou1ImXor6wrPbh6ClIFO4E2gASDBzFyV5TRXHQQl+US+HybxubgGIi5oIRtBPBk BkSYvbUZ1iXrGoHgijn5RD6Z8oWY7OEjrqQsI/Lh10HanIeMwW/yXmtTS0vFnfsmMzeF7n3EJg0 7LHdsv+IGBo/zwTfcrkxAVQ6JB4CzkwE7QPKizEGB6vCpmL+ZqtrkXc54kuhHyPgX6K2nlvGx0u ytC4qxkwfWeZ2rIhR/UR2zke0/t9sOnzexQ8MeC158ENcWEnmiRDa+HREF5Awr5OFlX25J4YFOT 39pMPrzj6iLwYPg3VQ+zj49+0wkxrA+TE3C168gHW/zsNePj6aZkHJVa/Eh/Zo1RYAL02E36ElM QIYAfq7LEvyOqZXqYFYXJDBuPIDkGQNhZMRqhWew46Aot1eX+PfH6rdHRmwjc1znOt9st6SGUZJ mG7qEewDTsRAFyMYkx2T18zegwyeCj3KK4UdB/0KzURwUIJWF+gpLz88dzEWd0DwOnC6TVheMC0 pERiF2hDZZ5F7IZrAHcX5Pnt0U39AE= X-Received: by 2002:a05:693c:87ce:20b0:33e:5cb6:249e with SMTP id 5a478bee46e88-33e8ddc761cmr2337090eec.39.1790169589850; Wed, 23 Sep 2026 06:19:49 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 017/114] module: add before/after hooks and module_call_init_fn Date: Wed, 23 Sep 2026 21:14:51 +0800 Message-ID: <20260923131635.1894-18-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790169592-F6A7477B-EC12C471/0/0 X-purgate-type: clean X-purgate-size: 5164 module_call_init just walks the list. Add register_module_hooks so one init type can wrap that walk with before and after ModuleInitHook callbacks, and add module_call_init_fn so a single function takes the same path. module_call_init passes MODULE_INIT_PHASE_ON. A DSO or module_call_init_fn passes DSO_BEFORE until module_call_init finishes, then DSO_AFTER. Signed-off-by: Yonggang Luo --- include/qemu/module.h | 18 +++++++++++ util/module.c | 70 ++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 84 insertions(+), 4 deletions(-) diff --git a/include/qemu/module.h b/include/qemu/module.h index 34e05c75348..c10e32731fa 100644 --- a/include/qemu/module.h +++ b/include/qemu/module.h @@ -60,6 +60,20 @@ typedef enum { typedef void (ModuleInitFn)(void); +/* + * Where one module_init_run sits relative to module_call_init(). + * DSO_BEFORE: a DSO or module_call_init_fn before module_call_init(). + * ON: module_call_init() itself. + * DSO_AFTER: a DSO or module_call_init_fn after module_call_init(). + */ +typedef enum ModuleInitPhase { + MODULE_INIT_PHASE_DSO_BEFORE, + MODULE_INIT_PHASE_ON, + MODULE_INIT_PHASE_DSO_AFTER, +} ModuleInitPhase; + +typedef bool (ModuleInitHook)(ModuleInitPhase phase, Error **errp); + typedef struct ModuleEntry { ModuleInitFn *init; QTAILQ_ENTRY(ModuleEntry) node; @@ -82,6 +96,10 @@ void register_module_init(ModuleEntry *e, module_init_type type); void register_dso_module_init(ModuleEntry *e, module_init_type type); void module_call_init(module_init_type type); +void module_call_init_fn(module_init_type type, ModuleInitFn *init, Error **errp); + +void register_module_hooks(module_init_type type, + ModuleInitHook *before, ModuleInitHook *after); /* * module_load: attempt to load a module from a set of directories diff --git a/util/module.c b/util/module.c index 6c5980542f6..a007ecb53a6 100644 --- a/util/module.c +++ b/util/module.c @@ -32,6 +32,8 @@ typedef QTAILQ_HEAD(, ModuleEntry) ModuleEntryList; typedef struct ModuleInit { module_init_type type; + ModuleInitHook *before; + ModuleInitHook *after; ModuleEntryList list; ModuleEntryList dso_list; bool done; @@ -88,14 +90,54 @@ void register_dso_module_init(ModuleEntry *e, module_init_type type) module_init_add(&find_type(type)->dso_list, e); } -static void module_init_run(ModuleInit *m, ModuleEntryList *list) +/** + * register_module_hooks: + * @type: init list + * @before: runs before every registered init for @type + * @after: runs after every registered init for @type + * + * One ModuleInit holds both callbacks so before and after stay 1:1. + * module_call_init(@type) passes MODULE_INIT_PHASE_ON. A DSO or + * module_call_init_fn passes DSO_BEFORE if module_call_init() has not + * finished, otherwise DSO_AFTER. + */ +void register_module_hooks(module_init_type type, + ModuleInitHook *before, ModuleInitHook *after) +{ + ModuleInit *m = find_type(type); + + g_assert(before); + g_assert(after); + g_assert(!m->before && !m->after); + + m->before = before; + m->after = after; +} + +static bool module_init_run(ModuleInit *m, ModuleEntryList *list, bool is_dso, + Error **errp) { ModuleEntry *e; + ModuleInitPhase phase; + + if (!is_dso) { + phase = MODULE_INIT_PHASE_ON; + } else if (m->done) { + phase = MODULE_INIT_PHASE_DSO_AFTER; + } else { + phase = MODULE_INIT_PHASE_DSO_BEFORE; + } - (void)m; + if (m->before && !m->before(phase, errp)) { + return false; + } QTAILQ_FOREACH(e, list, node) { e->init(); } + if (m->after && !m->after(phase, errp)) { + return false; + } + return true; } void module_call_init(module_init_type type) @@ -106,10 +148,27 @@ void module_call_init(module_init_type type) return; } - module_init_run(m, &m->list); + module_init_run(m, &m->list, false, &error_abort); m->done = true; } +/* + * Run a single init through @type's before/after hooks with is_dso=true. + * May run before or after module_call_init. + */ +void module_call_init_fn(module_init_type type, ModuleInitFn *init, Error **errp) +{ + ModuleInit *m = find_type(type); + ModuleEntry e = { + .init = init, + }; + ModuleEntryList list; + + QTAILQ_INIT(&list); + QTAILQ_INSERT_TAIL(&list, &e, node); + module_init_run(m, &list, true, errp); +} + #ifdef CONFIG_MODULES static const QemuModinfo module_info_stub[] = { { @@ -201,7 +260,10 @@ static bool module_load_dso(const char *fname, bool export_symbols, continue; } - module_init_run(m, &m->dso_list); + if (!module_init_run(m, &m->dso_list, true, errp)) { + empty_dso_lists(); + return false; + } } trace_module_load_module(fname); empty_dso_lists(); -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:20:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:20:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430480.1653000 (Exim 4.92) (envelope-from ) id 1x9MtH-0006E2-6A; Wed, 23 Sep 2026 13:20:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430480.1653000; Wed, 23 Sep 2026 13:20:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MtH-0006DS-15; Wed, 23 Sep 2026 13:20:03 +0000 Received: by outflank-mailman (input) for mailman id 1430480; Wed, 23 Sep 2026 13:20:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MtG-0005yN-46 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:20:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MtF-00BPjT-HF for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:20:01 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d1fe-2eae-0a2a0a5409dd-0a2a4509b172-10 for ; Wed, 23 Sep 2026 15:20:01 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d1ff-be1a-0a2a45090019-4a7de50cb433-3 for ; Wed, 23 Sep 2026 15:20:01 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664e050bso1172774eec.0 for ; Wed, 23 Sep 2026 06:20:00 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.19.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:19:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169599; x=1790774399; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=bgYFeWF3ExMdjkoIhx1M6bQ8cLDb8ZfAeE7NuNbtMe0=; b=i7r1gV8xkOXsJFNKVot327qZ8aLmVW0V7SYcc4nVK1MeXudaVz7vP+V+SX2cewHlTH PG0BzxagyY1QtN9v3/wDPh+4RJ7QQAVov3/2pp3F8Yvhk++9ceSShuesZvA3uIfDp1VO sVZk6yH/KQ8K1xpuCZUmeMnL3Zct/Dhay/WOAyNC4juVwfBY+VTw2ic3pHoHloB79kRc uAnB7KLQ1t9bdfEQwTM8xALyznVdP1zkCmFCkPdTDZuP9ezhd3b8MhGXwkCkXV7dxz5z +rCwdsNXzR/J7Clo4kKlAe2wVRBP8YzUnWfjZruOh6CPnmsvpq4mbdxZ5JBQr4Ci+7rP 9fkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169599; x=1790774399; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=bgYFeWF3ExMdjkoIhx1M6bQ8cLDb8ZfAeE7NuNbtMe0=; b=Gz6+87InjqDD0nUyr7SfnNsV3EvbyyPkvVoMwbBnm4lT1PweHDmsmJiZJ1ZQ7O0nNZ g66WlPP7wnfifVO/g3xfD12Hjh4faI+fjuY70e3QoTvmrGrc+ySV5jmdwB7G8ZAXAm09 LKrQAsuGL4DQjWAUFrGopuaVtzkTd7f1Tha1/4FtAjLIDs7ObrMJZZ3kxs9Jfp/C9ROI lsj7If3QZ27jO8DNg/i3JtSFNMHdgmAH+q1EDiF07d3OJUOgeQouCI5r1H9zIQvaRs4q qzyI5g7wEfgpKBaqgAVvk98FZHVgNU4zqIe426To6ToGb/vaNIvGkj5gOKcCUj0ZkbrH /lyQ== X-Forwarded-Encrypted: i=1; AKwUvBytxCYRfK+yoMYwfpJ826pLAke+4pRaX2MSBfFfTC/MrbaABZDJ6s/xrBoAvGYzdX4tYigVqUBGbPo=@lists.xenproject.org X-Gm-Message-State: AFuF++myL4hhv4EGILVZDpuekO9OtJdZkWTgi6OEFLD1dxp5OwLXB03T uia9Qemgt9M+/sxTe3dj9UV08ImjB7mBiioULQp+puUJpz/vBZYFfK/x X-Gm-Gg: AYBFou3uUixikpQO7YKx37KjKqYDnqc+riwqIKdVbgKuM180Asd69j5a2VXFW8sV+z7 WBl8FBtxjcuDZLRIan7j+qHST7CG+WsIRK5sh1Gy/w4SSgoRqH9m31EDuKS7F/A//dGqfVOC65R ML5WEMNCT4zIojoOkyQ3jKTeCxbdamTUHt0+DLPkStl2TBH8AiVnVQk/gKRJmzZtOrXVCrFv8vI 7f3b+phdHPZK4WAXS4Icb0BRXXkDdeUC6Q7ghj6jql1QtGg3ch3VGzwonx1cj7IcndzpZEEqEPl MO9z9iAOHCzLb+xvNIdq5J+zeb2KZF0VOsZSbFdHRIL+gHD92zdFC3HMrUdsUylJiJ/2piSIy7T 8vwwkWyHc3Ro4GiCMiN/WCSLz3ZEl5BmJ4GJ+HWmwflGy2acCHLkADV9k9H4COgpgJWzBapm56i 5AMyoZHQ5NrC/2Bwff3QmIZXl9Skv5FJ8qcL3SS1JicagB12uwVGrbVG1rsdbUVM/iQzDfaoG4J jDshm6YbKnIbQfoumAggL6XfRtPPT4= X-Received: by 2002:a05:7300:220d:b0:33b:f206:845 with SMTP id 5a478bee46e88-33e8e0b4537mr4054962eec.32.1790169598799; Wed, 23 Sep 2026 06:19:58 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 018/114] qom: register late types through module_call_init_fn Date: Wed, 23 Sep 2026 21:14:52 +0800 Message-ID: <20260923131635.1894-19-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1790169601-FDA6E034-F4365F3D/0/0 X-purgate-type: clean X-purgate-size: 12313 Display early_init, the console-vc fallback, the PPC KVM host CPU, and unit-test types register after MODULE_INIT_QOM. Route them through module_call_init_fn so they take the same before/init/after path as a late DSO. Signed-off-by: Yonggang Luo --- target/ppc/kvm.c | 12 +++++++++++- tests/unit/check-qom-interface.c | 12 +++++++++--- tests/unit/check-qom-proplist.c | 13 +++++++++---- tests/unit/test-io-channel-websock.c | 7 ++++++- tests/unit/test-io-task.c | 7 ++++++- tests/unit/test-qdev-global-props.c | 14 ++++++++++---- tests/unit/test-qdev.c | 8 +++++++- tests/unit/test-ram-discard-manager.c | 7 ++++++- ui/console-vc.c | 13 ++++++++++--- ui/dbus.c | 8 +++++++- ui/gtk.c | 10 +++++++++- ui/spice-app.c | 7 ++++++- 12 files changed, 96 insertions(+), 22 deletions(-) diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c index 8e89a6c665c..a3c16850a18 100644 --- a/target/ppc/kvm.c +++ b/target/ppc/kvm.c @@ -22,6 +22,7 @@ #include #include "qapi/error.h" +#include "qemu/module.h" #include "qemu/error-report.h" #include "cpu.h" #include "cpu-models.h" @@ -2706,6 +2707,13 @@ static void pseries_machine_class_fixup(ObjectClass *oc, void *opaque) mc->default_cpu_type = TYPE_HOST_POWERPC_CPU; } +static TypeInfo host_cpu_type_info; + +static void kvm_ppc_register_host_cpu_type_qom(void) +{ + type_register_static(&host_cpu_type_info); +} + static int kvm_ppc_register_host_cpu_type(void) { TypeInfo type_info = { @@ -2722,7 +2730,9 @@ static int kvm_ppc_register_host_cpu_type(void) return -1; } type_info.parent = object_class_get_name(OBJECT_CLASS(pvr_pcc)); - type_register_static(&type_info); + host_cpu_type_info = type_info; + module_call_init_fn(MODULE_INIT_QOM, kvm_ppc_register_host_cpu_type_qom, + &error_abort); /* override TCG default cpu type with 'host' cpu model */ object_class_foreach(pseries_machine_class_fixup, TYPE_SPAPR_MACHINE, false, NULL); diff --git a/tests/unit/check-qom-interface.c b/tests/unit/check-qom-interface.c index 86ae5f6c3b1..1da051ed98b 100644 --- a/tests/unit/check-qom-interface.c +++ b/tests/unit/check-qom-interface.c @@ -12,6 +12,7 @@ #include "qemu/osdep.h" #include "qom/object.h" +#include "qapi/error.h" #include "qemu/module.h" @@ -86,14 +87,19 @@ static void interface_intermediate_test(void) test_interface_impl(TYPE_INTERMEDIATE_IMPL); } +static void register_types(void) +{ + type_register_static(&test_if_info); + type_register_static(&direct_impl_info); + type_register_static(&intermediate_impl_info); +} + int main(int argc, char **argv) { g_test_init(&argc, &argv, NULL); module_call_init(MODULE_INIT_QOM); - type_register_static(&test_if_info); - type_register_static(&direct_impl_info); - type_register_static(&intermediate_impl_info); + module_call_init_fn(MODULE_INIT_QOM, register_types, &error_abort); g_test_add_func("/qom/interface/direct_impl", interface_direct_test); g_test_add_func("/qom/interface/intermediate_impl", diff --git a/tests/unit/check-qom-proplist.c b/tests/unit/check-qom-proplist.c index 89de92b7d91..074a69a7fd3 100644 --- a/tests/unit/check-qom-proplist.c +++ b/tests/unit/check-qom-proplist.c @@ -703,15 +703,20 @@ static void test_qom_partial_path(void) object_unparent(cont1); } -int main(int argc, char **argv) +static void register_types(void) { - g_test_init(&argc, &argv, NULL); - - module_call_init(MODULE_INIT_QOM); type_register_static(&dummy_info); type_register_static(&dummy_dev_info); type_register_static(&dummy_bus_info); type_register_static(&dummy_backend_info); +} + +int main(int argc, char **argv) +{ + g_test_init(&argc, &argv, NULL); + + module_call_init(MODULE_INIT_QOM); + module_call_init_fn(MODULE_INIT_QOM, register_types, &error_abort); g_test_add_func("/qom/proplist/createlist/tree", test_dummy_createlist_tree); diff --git a/tests/unit/test-io-channel-websock.c b/tests/unit/test-io-channel-websock.c index 88da24f993d..d4a92572866 100644 --- a/tests/unit/test-io-channel-websock.c +++ b/tests/unit/test-io-channel-websock.c @@ -219,10 +219,15 @@ static void test_websock_stalled_write(const void *opaque) g_assert_true(g_str_has_prefix(reply, "HTTP/1.1 400 Bad Request\r\n")); } +static void register_types(void) +{ + type_register_static(&qio_channel_stall_info); +} + int main(int argc, char **argv) { module_call_init(MODULE_INIT_QOM); - type_register_static(&qio_channel_stall_info); + module_call_init_fn(MODULE_INIT_QOM, register_types, &error_abort); g_test_init(&argc, &argv, NULL); #define TEST_BAD_REQUEST(name, request) \ diff --git a/tests/unit/test-io-task.c b/tests/unit/test-io-task.c index b1c8ecb7abb..55c4a64f041 100644 --- a/tests/unit/test-io-task.c +++ b/tests/unit/test-io-task.c @@ -279,11 +279,16 @@ static void test_task_thread_failure(void) } +static void register_types(void) +{ + type_register_static(&dummy_info); +} + int main(int argc, char **argv) { g_test_init(&argc, &argv, NULL); module_call_init(MODULE_INIT_QOM); - type_register_static(&dummy_info); + module_call_init_fn(MODULE_INIT_QOM, register_types, &error_abort); g_test_add_func("/crypto/task/complete", test_task_complete); g_test_add_func("/crypto/task/cancel", test_task_cancel); g_test_add_func("/crypto/task/datafree", test_task_data_free); diff --git a/tests/unit/test-qdev-global-props.c b/tests/unit/test-qdev-global-props.c index 8ea362cbb90..e0aaee05d8b 100644 --- a/tests/unit/test-qdev-global-props.c +++ b/tests/unit/test-qdev-global-props.c @@ -27,6 +27,7 @@ #include "hw/core/qdev-properties.h" #include "qom/object.h" #include "qapi/error.h" +#include "qemu/module.h" #include "qapi/visitor.h" @@ -302,17 +303,22 @@ static void test_subclass_global_props(void) g_assert_cmpuint(mt->prop2, ==, 104); } -int main(int argc, char **argv) +static void register_types(void) { - g_test_init(&argc, &argv, NULL); - - module_call_init(MODULE_INIT_QOM); type_register_static(&static_prop_type); type_register_static(&subclass_type); type_register_static(&dynamic_prop_type); type_register_static(&hotplug_type); type_register_static(&nohotplug_type); type_register_static(&nondevice_type); +} + +int main(int argc, char **argv) +{ + g_test_init(&argc, &argv, NULL); + + module_call_init(MODULE_INIT_QOM); + module_call_init_fn(MODULE_INIT_QOM, register_types, &error_abort); test_init_machine(); diff --git a/tests/unit/test-qdev.c b/tests/unit/test-qdev.c index 77c3eee7171..5755fa57b58 100644 --- a/tests/unit/test-qdev.c +++ b/tests/unit/test-qdev.c @@ -2,6 +2,7 @@ #include "hw/core/qdev-properties.h" #include "qom/object.h" #include "qapi/error.h" +#include "qemu/module.h" #include "qapi/visitor.h" @@ -89,12 +90,17 @@ static void test_qdev_double_realization(void) } +static void register_types(void) +{ + type_register_static(&my_dev_type_info); +} + int main(int argc, char **argv) { g_test_init(&argc, &argv, NULL); module_call_init(MODULE_INIT_QOM); - type_register_static(&my_dev_type_info); + module_call_init_fn(MODULE_INIT_QOM, register_types, &error_abort); test_init_machine(); g_test_add_func("/qdev/free-properties", diff --git a/tests/unit/test-ram-discard-manager.c b/tests/unit/test-ram-discard-manager.c index 3d39a1e94ba..5bdcf9b074c 100644 --- a/tests/unit/test-ram-discard-manager.c +++ b/tests/unit/test-ram-discard-manager.c @@ -1187,12 +1187,17 @@ static void test_replay_discarded(void) test_teardown(); } +static void register_types(void) +{ + type_register_static(&test_rds_info); +} + int main(int argc, char **argv) { g_test_init(&argc, &argv, NULL); module_call_init(MODULE_INIT_QOM); - type_register_static(&test_rds_info); + module_call_init_fn(MODULE_INIT_QOM, register_types, &error_abort); g_test_add_func("/ram-discard-manager/single-source/basic", test_single_source_basic); diff --git a/ui/console-vc.c b/ui/console-vc.c index 53d9e9d39b3..c998a0dd807 100644 --- a/ui/console-vc.c +++ b/ui/console-vc.c @@ -6,6 +6,7 @@ #include "chardev/char.h" #include "qapi/error.h" +#include "qemu/module.h" #include "qemu/option.h" #include "qemu/queue.h" #include "qom/compat-properties.h" @@ -349,10 +350,16 @@ static const TypeInfo char_vc_type_info = { .class_init = char_vc_class_init, }; +static void register_default_char_vc(void) +{ + type_register_static(&char_vc_type_info); +} + void qemu_console_early_init(void) { - /* set the default vc driver */ - if (!object_class_by_name(TYPE_CHARDEV_VC)) { - type_register_static(&char_vc_type_info); + /* set the default vc driver if a display backend did not */ + if (object_class_by_name(TYPE_CHARDEV_VC)) { + return; } + module_call_init_fn(MODULE_INIT_QOM, register_default_char_vc, &error_abort); } diff --git a/ui/dbus.c b/ui/dbus.c index 7be0f8e2611..34b33bb9ca1 100644 --- a/ui/dbus.c +++ b/ui/dbus.c @@ -38,6 +38,7 @@ #include "qemu/audio.h" #include "audio/audio_int.h" /* FIXME: use QOM dynamic cast instead of drv->name */ #include "qapi/error.h" +#include "qemu/module.h" #include "trace.h" #include "dbus.h" @@ -623,6 +624,11 @@ static const TypeInfo dbus_vc_type_info = { .class_init = dbus_vc_class_init, }; +static void register_dbus_char_vc(void) +{ + type_register_static(&dbus_vc_type_info); +} + static void early_dbus_init(DisplayOptions *opts) { @@ -638,7 +644,7 @@ early_dbus_init(DisplayOptions *opts) using_dbus_display = 1; - type_register_static(&dbus_vc_type_info); + module_call_init_fn(MODULE_INIT_QOM, register_dbus_char_vc, &error_abort); } static void diff --git a/ui/gtk.c b/ui/gtk.c index ed7ffc06b15..2ddc1f8a901 100644 --- a/ui/gtk.c +++ b/ui/gtk.c @@ -38,6 +38,7 @@ #include "qemu/cutils.h" #include "qemu/error-report.h" #include "qemu/main-loop.h" +#include "qemu/module.h" #include "qemu-main.h" #include "ui/console.h" @@ -2893,6 +2894,13 @@ static void gtk_display_init(DisplayState *ds, DisplayOptions *opts) qemu_main = NULL; } +#if defined(CONFIG_VTE) +static void register_gtk_char_vc(void) +{ + type_register_static(&char_gd_vc_type_info); +} +#endif + static void early_gtk_display_init(DisplayOptions *opts) { /* The QEMU code relies on the assumption that it's always run in @@ -2946,7 +2954,7 @@ static void early_gtk_display_init(DisplayOptions *opts) keycode_map = gd_get_keymap(&keycode_maplen, &keycode_xorgevdev); #if defined(CONFIG_VTE) - type_register_static(&char_gd_vc_type_info); + module_call_init_fn(MODULE_INIT_QOM, register_gtk_char_vc, &error_abort); #endif } diff --git a/ui/spice-app.c b/ui/spice-app.c index fe3df62bfa5..dae3415ec8d 100644 --- a/ui/spice-app.c +++ b/ui/spice-app.c @@ -132,6 +132,11 @@ static void spice_app_cleanup(void) g_clear_pointer(&app_dir, g_free); } +static void register_spice_char_vc(void) +{ + type_register_static(&char_vc_type_info); +} + static void spice_app_display_early_init(DisplayOptions *opts) { QemuOpts *qopts; @@ -170,7 +175,7 @@ static void spice_app_display_early_init(DisplayOptions *opts) exit(1); } - type_register_static(&char_vc_type_info); + module_call_init_fn(MODULE_INIT_QOM, register_spice_char_vc, &error_abort); sock_path = g_strjoin("", app_dir, "/", "spice.sock", NULL); qopts = qemu_opts_create(list, NULL, 0, &error_abort); -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:20:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:20:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430484.1653008 (Exim 4.92) (envelope-from ) id 1x9MtT-0007Uq-I0; Wed, 23 Sep 2026 13:20:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430484.1653008; Wed, 23 Sep 2026 13:20:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MtT-0007Uj-Dz; Wed, 23 Sep 2026 13:20:15 +0000 Received: by outflank-mailman (input) for mailman id 1430484; Wed, 23 Sep 2026 13:20:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MtR-0007Pa-Cb for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:20:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MtQ-001uDL-Pe for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:20:12 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d20b-8faa-0a2a0a5109dd-0a2a4507d5d4-0 for ; Wed, 23 Sep 2026 15:20:11 +0200 Received: from [74.125.229.35] (helo=mail-dy2-f35.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d209-b4ea-0a2a45070019-4a7de5238009-3 for ; Wed, 23 Sep 2026 15:20:11 +0200 Received: by mail-dy2-f35.google.com with SMTP id 5a478bee46e88-3381a6a05c9so355075eec.1 for ; Wed, 23 Sep 2026 06:20:10 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.19.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:20:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169609; x=1790774409; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=R0NEODEUKGZurnafAxCJE2mvY+onJpkfc8axTrsuyg4=; b=OZ+glA4UZL9A3SuKPyD4xyrFgwmorAsWFm910l++x6CN+IlzQNHZpl7GzHlRCQ2o2y xWwDCxmpdWlX5+Ob5xIS/cgpv2T2eKx9qOK8X5XZf2u3s/L6m3dLEnuT0PuyxoQZXZYO 3T3bN3DmF6UaK5e59AZz1A467gMEH+/K/oe9jZpe43nS+jVxbOuf6vLPfPfj6qdNgPZ0 cti1FwQhGb/2zamAB4n+GKUoB6kNcLZ43GFhASvjPqW7nbnZyJzP5suVqOa8CcsNdni8 woYrQGfUOBEUqhUHd8xPxYFOR4pldUKKS7SMOS2UGLE8+9oeBdgd3L1osrZRmrL2a+6w 7ryA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169609; x=1790774409; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=R0NEODEUKGZurnafAxCJE2mvY+onJpkfc8axTrsuyg4=; b=CxuruikgxqOd0zO3ALxb4yzjYQFB8FynSuxC7jqJ7cnKsE0bn6IEqsTLZkpXIBGEx0 hjcvoVbXuGkbAZmQBicAI+eMHS6rArGvVNXvlBz5LocKskoXwkglAMWVSE09k42jQv7F 6RsX8XxIypqpDYk26CQM9QVpj5Mem0suTyo7bQXUbDz1eNyT/FurqmtgT9dnS8iwn+cC brM1KqkWx1VmFcV0oUI029FrImu0DsNZRP8Ulsce4SZaIkNW9h32CXc5nh4d16iuUv82 7EiT62C8kXyPwpsz3DpcE7V7IV5MLGws1Xq2S0QBVwcgK4KypQkw1GIfm4KQTew80Hgn BMzg== X-Forwarded-Encrypted: i=1; AKwUvBwWQ7Tk1cCAug05wFzua8vmbcWEXdAbZS/B4bWU03zlwtk8fIBgKhc1BlHSinm0GNIR8/j/eaL11HY=@lists.xenproject.org X-Gm-Message-State: AFuF++lIRA3NnZEwqHrfXtDAVlmz/JS9eoWt01qU2QwnejDbuccJRj3A ZXMor6SgmbMM84AblpNo4sjV4F7DdyG7qiI/pYLymKGoFXHy1keSte31 X-Gm-Gg: AYBFou2UoU/e/nlHJdMbQOV7Ty7yUUS4K3i6YY+XZv6ocOjhwUODoUreRC70uIwpkOm 5lGbsoD4o0UZredmlRbhcB4mw/Wf1+yRn/vTfCkCsbUx+UiVNAqF13SrVk/KNdAHPtax/QKiq0R ZjOqW+sJlTR8XIs8QV6ifA3u/C7ezAwl5zlQj4rxbaytwtC7n1YMB3GB+DqWJr6ZlbK0MxUZoqX eKF3UswyhZoftaHg7Vj6wVbj00z08eTUUq5VPUAYcE5gT0VvyTBjq+58ZoYfJ2p/FcL7C/wlmYP wW3CzsniCcBuf0wyGta/iyJBKQ/Q1SKlxCGdveC4YmhAFVJaBh6lCFnybvARojORoS3E2R0RCyI +tb+S906W9iVA7EH+ms6jXr7tBZqsPrz6xHR47jhsbapUHBm1Xrd91f0ZXOaJsmcNKMO550Kh+n IZpunNag7/uQGxnc2Wy1k+ElRNEoA4AqvZrVvDIiS5Y2jKKPwHoqyFRAv/WJBFSfLPVtJ7rSaqQ ft+38Kn3jLripjupGrPjHSlI8w4L6M= X-Received: by 2002:a05:693c:60cd:b0:33b:e306:2e27 with SMTP id 5a478bee46e88-33ea3eb055bmr2839410eec.5.1790169609054; Wed, 23 Sep 2026 06:20:09 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 019/114] qom: inherit is_available and filter after MODULE_INIT_QOM Date: Wed, 23 Sep 2026 21:14:53 +0800 Message-ID: <20260923131635.1894-20-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790169611-A7AD0AE4-8A0BEF44/0/0 X-purgate-type: clean X-purgate-size: 8383 Parents are not all registered at type_register time, so a type cannot inherit is_available then. After MODULE_INIT_QOM, and after a late DSO, inherit the callback from the parent, drop types that fail target_info(), and report a missing parent. Skip that filter for MODULE_INIT_PHASE_DSO_BEFORE. The inherit walk colors each type once, so it is O(N) in the number of types. TYPE_INTERFACE and TYPE_OBJECT use target_is_any(). type_register_static aborts if it runs outside the QOM before/after hooks. Signed-off-by: Yonggang Luo --- include/qemu/target-info.h | 9 +++ qom/object.c | 134 +++++++++++++++++++++++++++++++++++-- target-info.c | 6 ++ 3 files changed, 145 insertions(+), 4 deletions(-) diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h index 440da63e6cf..790fc74e9d3 100644 --- a/include/qemu/target-info.h +++ b/include/qemu/target-info.h @@ -53,6 +53,15 @@ const char *target_cpu_type(void); */ bool target_big_endian(void); +/** + * target_is_any: + * @ti: TargetInfo to inspect + * + * Returns true for every TargetInfo. Usable as TypeInfo.is_available + * for types that are not target-scoped (TYPE_OBJECT). + */ +bool target_is_any(const TargetInfo *ti); + /** * target_is_base_arm: * @ti: TargetInfo to inspect diff --git a/qom/object.c b/qom/object.c index a3e75927e82..d0f9242ac99 100644 --- a/qom/object.c +++ b/qom/object.c @@ -14,6 +14,7 @@ #include "qapi/error.h" #include "qom/compat-properties.h" #include "qom/object.h" +#include "qemu/module.h" #include "qom/object_interfaces.h" #include "qemu/target-info-qapi.h" #include "qemu/cutils.h" @@ -40,6 +41,7 @@ #include "qobject/qnum.h" #include "qobject/qstring.h" #include "qemu/error-report.h" +#include "qemu/queue.h" #define MAX_INTERFACES 32 @@ -81,11 +83,16 @@ struct TypeImpl int num_interfaces; InterfaceImpl interfaces[MAX_INTERFACES]; + + QTAILQ_ENTRY(TypeImpl) register_node; }; static Type type_interface; static GHashTable *type_table; +static QTAILQ_HEAD(, TypeImpl) type_register_list = + QTAILQ_HEAD_INITIALIZER(type_register_list); +static bool type_qom_registering; static bool enumerating_types; @@ -95,6 +102,21 @@ static void type_table_add(TypeImpl *ti) g_hash_table_insert(type_table, (void *)ti->name, ti); } +static void type_table_remove(TypeImpl *ti) +{ + int i; + + assert(!enumerating_types); + g_hash_table_remove(type_table, (void *)ti->name); + QTAILQ_REMOVE(&type_register_list, ti, register_node); + g_free((char *)ti->name); + g_free((char *)ti->parent); + for (i = 0; i < ti->num_interfaces; i++) { + g_free((char *)ti->interfaces[i].typename); + } + g_free(ti); +} + static TypeImpl *type_table_lookup(const char *name) { return g_hash_table_lookup(type_table, name); @@ -171,18 +193,20 @@ static TypeImpl *type_register_internal(const TypeInfo *info) abort(); } - if (info->is_available && !info->is_available(target_info())) { - return NULL; - } - ti = type_new(info); type_table_add(ti); + QTAILQ_INSERT_TAIL(&type_register_list, ti, register_node); return ti; } TypeImpl *type_register_static(const TypeInfo *info) { + if (!type_qom_registering) { + fprintf(stderr, "Registering '%s' outside QOM before/after\n", + info->name); + abort(); + } assert(info->parent); return type_register_internal(info); } @@ -316,6 +340,8 @@ static void type_initialize_interface(TypeImpl *ti, TypeImpl *interface_type, iface_impl = type_new(&info); iface_impl->parent_type = parent_type; + g_assert(interface_type->is_available); + iface_impl->is_available = interface_type->is_available; type_initialize(iface_impl); g_free((char *)info.name); @@ -1159,6 +1185,7 @@ bool object_class_is_secure(ObjectClass *klass) TypeIsAvailable *object_class_get_is_available(ObjectClass *klass) { + g_assert(klass->type->is_available); return klass->type->is_available; } @@ -3297,12 +3324,109 @@ static void object_class_init(ObjectClass *klass, const void *data) NULL); } +static bool type_qom_before(ModuleInitPhase phase, Error **errp) +{ + (void)errp; + (void)phase; + + type_qom_registering = true; + return true; +} + +enum TypeVisitColor { + TYPE_VISIT_GRAY = 1, + TYPE_VISIT_BLACK, +}; + +static bool type_update_is_available(TypeImpl *type, GHashTable *visit, + Error **errp) +{ + TypeImpl *parent; + gpointer color; + + color = g_hash_table_lookup(visit, type); + if (color == GINT_TO_POINTER(TYPE_VISIT_BLACK)) { + return true; + } + if (color == GINT_TO_POINTER(TYPE_VISIT_GRAY)) { + error_setg(errp, "Type '%s' has a cyclic parent chain", + type->name); + return false; + } + + g_hash_table_insert(visit, type, GINT_TO_POINTER(TYPE_VISIT_GRAY)); + + parent = type_get_parent(type); + if (!parent) { + if (strcmp(type->name, TYPE_OBJECT) != 0 && + strcmp(type->name, TYPE_INTERFACE) != 0) { + error_setg(errp, + "Type '%s' does not inherit from %s or %s", + type->name, TYPE_OBJECT, TYPE_INTERFACE); + return false; + } + } else { + if (!type_update_is_available(parent, visit, errp)) { + return false; + } + if (!type->is_available) { + type->is_available = parent->is_available; + } + } + + g_hash_table_insert(visit, type, GINT_TO_POINTER(TYPE_VISIT_BLACK)); + return true; +} + +static bool type_qom_after(ModuleInitPhase phase, Error **errp) +{ + TypeImpl *type, *next; + GHashTable *visit; + Error *local_err = NULL; + + type_qom_registering = false; + if (phase == MODULE_INIT_PHASE_DSO_BEFORE) { + return true; + } + + visit = g_hash_table_new(NULL, NULL); + QTAILQ_FOREACH(type, &type_register_list, register_node) { + if (!type_update_is_available(type, visit, &local_err)) { + break; + } + } + g_hash_table_destroy(visit); + + if (local_err) { + error_propagate(errp, local_err); + return false; + } + + QTAILQ_FOREACH_SAFE(type, &type_register_list, register_node, next) { + g_assert(type->is_available); + if (!type->is_available(target_info())) { + type_table_remove(type); + } + } + + QTAILQ_FOREACH(type, &type_register_list, register_node) { + if (type->parent && !type_table_lookup(type->parent)) { + error_setg(errp, "Type '%s' is missing its parent '%s'", + type->name, type->parent); + return false; + } + } + + return true; +} + static void __attribute__((constructor)) register_types(void) { static const TypeInfo interface_info = { .name = TYPE_INTERFACE, .class_size = sizeof(InterfaceClass), .abstract = true, + .is_available = target_is_any, }; static const TypeInfo object_info = { @@ -3310,9 +3434,11 @@ static void __attribute__((constructor)) register_types(void) .instance_size = sizeof(Object), .class_init = object_class_init, .abstract = true, + .is_available = target_is_any, }; type_table = g_hash_table_new(g_str_hash, g_str_equal); type_interface = type_register_internal(&interface_info); type_register_internal(&object_info); + register_module_hooks(MODULE_INIT_QOM, type_qom_before, type_qom_after); } diff --git a/target-info.c b/target-info.c index 36f75ece36f..a9ab4b465d3 100644 --- a/target-info.c +++ b/target-info.c @@ -96,6 +96,12 @@ bool target_big_endian(void) return target_endian_mode() == ENDIAN_MODE_BIG; } +bool target_is_any(const TargetInfo *ti) +{ + (void)ti; + return true; +} + bool target_is_base_arm(const TargetInfo *ti) { switch (ti->target_arch) { -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:20:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:20:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430498.1653018 (Exim 4.92) (envelope-from ) id 1x9Mtl-0008E5-Q7; Wed, 23 Sep 2026 13:20:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430498.1653018; Wed, 23 Sep 2026 13:20:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mtl-0008Dy-Lw; Wed, 23 Sep 2026 13:20:33 +0000 Received: by outflank-mailman (input) for mailman id 1430498; Wed, 23 Sep 2026 13:20:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mtj-0008BM-N0 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:20:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mtj-009D7k-3q for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:20:31 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d218-e002-0a2a0a5209dd-0a2a450c85f6-16 for ; Wed, 23 Sep 2026 15:20:31 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d218-f479-0a2a450c0019-4a7de52ba258-3 for ; Wed, 23 Sep 2026 15:20:26 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-33e46a15703so621911eec.0 for ; Wed, 23 Sep 2026 06:20:25 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.20.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:20:16 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169624; x=1790774424; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=MggXP4Uti4XPPjQvDWGWmS5irh6Dnb5s6/0zImLVthk=; b=qS+bHTJvgsTuss41vsE6F0tkLwwcLSWROBewl3TcZ98zPnX12s9J0DBJAyFh5Z/WoZ kQIKf2Ur6sr289pfOFZu8N25tf9BOlT5vADbnTNio158kronSafQbgvmnsoBcZZ8gjan yNmetWCo6IEbZqjxx3OFIM5gDY0jNLiBmWv078iasmiiB6B1Sfm33VAKjahQnMyEzcO6 4G0bjoHUXuuFuUInsFgh8EHv6NC66v3Sf+OPPniQOu6tJ5QtzHWOoPY2l8KdOAsGQ+Wd BBBtwKan5lv5B7ZxWMAW5bC1Bv2k2P3UkYY+lg8YUCo0mMxjSEH6Gq53vpoN2pK6INkT DUiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169624; x=1790774424; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=MggXP4Uti4XPPjQvDWGWmS5irh6Dnb5s6/0zImLVthk=; b=IBZdLRGCC1OAbJ+nAfGXYGvJTnbV7omUURmToeUyBbmxpkRgspqWwaaT6/4VSlo8kn CJPTJFhDLd+gTXchgLA7zXsVvhXrcX3EuaOHvQ2yA2+v/UmAfRkr3Rs/VXBXcW8hd8z7 5yJhO7jnAuQ9m8m6Cbnu1VjvlubUKD8gY8dTszrwvK+Fkv8CzVUwmXApdCtcg2AVspz1 ZFXyrdSaq8yks++vwMWLDdNSChjspVTOhFFgl/9Jbvq6FeaNdpbMvCFm13gKBQctQoJp 5cjbub1tbetxKWKu9QqGb/5oe3zWMKBoeaG08bwsLQFHheP34xB5GvpGrJvxBQyUxiCv Cs8A== X-Forwarded-Encrypted: i=1; AKwUvBy+9JSC/DbTdnAVbDCH6XO9boWluel+0mBVVZFSSJLkY5i3u4JtcRAUGZZcaNqhFKNkgz3Et/6hCiY=@lists.xenproject.org X-Gm-Message-State: AFuF++m6dq/2TpbtUs1+mn8URDIi0YW6ilOdbzNQS7ot/+driDZjPHdz pEw254Ol5+YS6aXFeXFLCHpOLsGZJFJlA0UmXvi23jmJVCk+xP5//rvD X-Gm-Gg: AYBFou1mVHw5pLXlGTPue3+nGw5Zn/14fdvng00wfOWR1M3ibSc1Zzm3Pc8f0ChiqrF frbreIwDz7MIdJHo9bNml/Kk6jwOl8/jjCymqStUbefI/FB0HDcXyT7Vcxx8Au5YqkvX+7PxSa5 9rf2bnnejGjDQ2EfvWrWjOYTY+BtH1/5NbUr0oWProLk7NH+q7l/I+Pd/UCnhlWHeih9nwseVdf ntnYNvHLEn3Q3l+TLE9UcrOeEBc7qKGZ8jJb4qrRKTpWqtKFQhkMEA5HrchC2+24sRaldQggPpv MZq8O8n3JvtuGVMMTE2FBjseWSzA/MifcR7lHRnU22SJsIZeuzwXnLMDSAPaoMYJeiHHelhDNRr VIl7+9szdjFPeaqhDJKX095/zqlMxN42nwq8Ain6iz4qtaQPcdZCLEjwF880INuMBHdcDCS7aHL 9w+cr/jGofEU6SLJedRQqCMhah1c7oPF4Gb90M5BtDRpm2Abyq1MnGH1OiKXKuH27bGQzfNUttU RHc9LUJlRi85qRmNeE+ZTkLoAZzcBHfV6q0hX37pw== X-Received: by 2002:a05:7301:7bc4:b0:333:f481:2252 with SMTP id 5a478bee46e88-33e8ddc490amr4023550eec.34.1790169623518; Wed, 23 Sep 2026 06:20:23 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 020/114] tests/unit: add module-init and qom is-available tests Date: Wed, 23 Sep 2026 21:14:54 +0800 Message-ID: <20260923131635.1894-21-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1790169626-77ED2A5B-1FDCD35E/0/0 X-purgate-type: clean X-purgate-size: 14095 The hook phases and QOM inherit/filter path have no unit coverage. Add test-module-init for before/after hooks and module_call_init_fn, and test-qom-is-available for inherit, filter, and late register when x86_64-softmmu is present. Signed-off-by: Yonggang Luo --- tests/unit/meson.build | 8 + tests/unit/test-module-init.c | 186 +++++++++++++++++++++ tests/unit/test-qom-is-available.c | 250 +++++++++++++++++++++++++++++ 3 files changed, 444 insertions(+) create mode 100644 tests/unit/test-module-init.c create mode 100644 tests/unit/test-qom-is-available.c diff --git a/tests/unit/meson.build b/tests/unit/meson.build index c806dbc4ffa..9387d2c34e6 100644 --- a/tests/unit/meson.build +++ b/tests/unit/meson.build @@ -2,6 +2,7 @@ testblock = declare_dependency(dependencies: [block], sources: 'iothread.c') tests = { + 'test-module-init': [], 'check-block-qdict': [], 'check-qdict': [], 'check-qnum': [], @@ -57,6 +58,13 @@ tests = { 'test-envlist': [], } +if 'x86_64-softmmu' in target_info_def_objects + tests += { + 'test-qom-is-available': [qom, declare_dependency( + objects: target_info_def_objects['x86_64-softmmu'])], + } +endif + if have_system or have_tools tests += { 'test-qmp-event': [testqapi], diff --git a/tests/unit/test-module-init.c b/tests/unit/test-module-init.c new file mode 100644 index 00000000000..85fa3ba3d54 --- /dev/null +++ b/tests/unit/test-module-init.c @@ -0,0 +1,186 @@ +/* + * Module before/after hooks, static ModuleEntry, and module_call_init_fn + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qapi/error.h" +#include "qemu/module.h" + +#define SEQ_BEFORE 1 +#define SEQ_INIT_A 2 +#define SEQ_INIT_B 3 +#define SEQ_AFTER 4 +#define SEQ_FN 5 + +static int seq[16]; +static int seq_n; +static int first_seq[16]; +static int first_seq_n; +static ModuleInitPhase last_phase; +static ModuleInitPhase first_phase; +static bool fail_before; +static bool fail_after; +static int fn_ran; +static int dso_ran; + +static void seq_add(int id) +{ + g_assert_cmpint(seq_n, <, (int)ARRAY_SIZE(seq)); + seq[seq_n++] = id; +} + +static bool test_before(ModuleInitPhase phase, Error **errp) +{ + last_phase = phase; + seq_add(SEQ_BEFORE); + if (fail_before) { + error_setg(errp, "before failed"); + return false; + } + return true; +} + +static bool test_after(ModuleInitPhase phase, Error **errp) +{ + last_phase = phase; + seq_add(SEQ_AFTER); + if (fail_after) { + error_setg(errp, "after failed"); + return false; + } + return true; +} + +static void init_a(void) +{ + seq_add(SEQ_INIT_A); +} + +static void init_b(void) +{ + seq_add(SEQ_INIT_B); +} + +static void init_fn(void) +{ + fn_ran++; + seq_add(SEQ_FN); +} + +static void init_dso(void) +{ + dso_ran++; +} + +static ModuleEntry entry_a = { + .init = init_a, +}; + +static ModuleEntry entry_b = { + .init = init_b, +}; + +static ModuleEntry entry_dso = { + .init = init_dso, +}; + +static void reset_seq(void) +{ + seq_n = 0; + memset(seq, 0, sizeof(seq)); +} + +static void test_builtin_order(void) +{ + g_assert_cmpint(first_phase, ==, MODULE_INIT_PHASE_ON); + g_assert_cmpint(first_seq_n, ==, 4); + g_assert_cmpint(first_seq[0], ==, SEQ_BEFORE); + g_assert_cmpint(first_seq[1], ==, SEQ_INIT_A); + g_assert_cmpint(first_seq[2], ==, SEQ_INIT_B); + g_assert_cmpint(first_seq[3], ==, SEQ_AFTER); + g_assert_cmpint(dso_ran, ==, 0); +} + +static void test_call_init_idempotent(void) +{ + reset_seq(); + module_call_init(MODULE_INIT_FUZZ_TARGET); + g_assert_cmpint(seq_n, ==, 0); +} + +static void test_call_init_fn(void) +{ + int old_fn = fn_ran; + + reset_seq(); + module_call_init_fn(MODULE_INIT_FUZZ_TARGET, init_fn, &error_abort); + g_assert_cmpint(last_phase, ==, MODULE_INIT_PHASE_DSO_AFTER); + g_assert_cmpint(fn_ran, ==, old_fn + 1); + g_assert_cmpint(seq_n, ==, 3); + g_assert_cmpint(seq[0], ==, SEQ_BEFORE); + g_assert_cmpint(seq[1], ==, SEQ_FN); + g_assert_cmpint(seq[2], ==, SEQ_AFTER); +} + +static void test_before_fail(void) +{ + Error *err = NULL; + int old_fn = fn_ran; + + reset_seq(); + fail_before = true; + module_call_init_fn(MODULE_INIT_FUZZ_TARGET, init_fn, &err); + fail_before = false; + g_assert_nonnull(err); + g_assert_cmpstr(error_get_pretty(err), ==, "before failed"); + g_assert_cmpint(fn_ran, ==, old_fn); + g_assert_cmpint(seq_n, ==, 1); + g_assert_cmpint(seq[0], ==, SEQ_BEFORE); + error_free(err); +} + +static void test_after_fail(void) +{ + Error *err = NULL; + int old_fn = fn_ran; + + reset_seq(); + fail_after = true; + module_call_init_fn(MODULE_INIT_FUZZ_TARGET, init_fn, &err); + fail_after = false; + g_assert_nonnull(err); + g_assert_cmpstr(error_get_pretty(err), ==, "after failed"); + g_assert_cmpint(fn_ran, ==, old_fn + 1); + g_assert_cmpint(seq_n, ==, 3); + g_assert_cmpint(seq[0], ==, SEQ_BEFORE); + g_assert_cmpint(seq[1], ==, SEQ_FN); + g_assert_cmpint(seq[2], ==, SEQ_AFTER); + error_free(err); +} + +int main(int argc, char **argv) +{ + g_test_init(&argc, &argv, NULL); + + register_module_hooks(MODULE_INIT_FUZZ_TARGET, test_before, test_after); + register_module_init(&entry_a, MODULE_INIT_FUZZ_TARGET); + register_module_init(&entry_b, MODULE_INIT_FUZZ_TARGET); + register_dso_module_init(&entry_dso, MODULE_INIT_FUZZ_TARGET); + + reset_seq(); + module_call_init(MODULE_INIT_FUZZ_TARGET); + first_seq_n = seq_n; + memcpy(first_seq, seq, sizeof(seq)); + first_phase = last_phase; + + g_test_add_func("/module/init/builtin-order", test_builtin_order); + g_test_add_func("/module/init/call-init-idempotent", + test_call_init_idempotent); + g_test_add_func("/module/init/call-init-fn", test_call_init_fn); + g_test_add_func("/module/init/before-fail", test_before_fail); + g_test_add_func("/module/init/after-fail", test_after_fail); + + return g_test_run(); +} diff --git a/tests/unit/test-qom-is-available.c b/tests/unit/test-qom-is-available.c new file mode 100644 index 00000000000..641f0cf1bb4 --- /dev/null +++ b/tests/unit/test-qom-is-available.c @@ -0,0 +1,250 @@ +/* + * QOM is_available inherit and filter after MODULE_INIT_QOM + * + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qapi/error.h" +#include "qemu/module.h" +#include "qemu/target-info-def.h" +#include "qom/object.h" + +#define TYPE_I386_PARENT "test-avail-i386-parent" +#define TYPE_I386_CHILD "test-avail-i386-child" +#define TYPE_NEVER "test-avail-never" +#define TYPE_NEVER_CHILD "test-avail-never-child" +#define TYPE_DROP_CHILD "test-avail-drop-child" +#define TYPE_TEST_IF "test-avail-if" +#define TYPE_LATE_KEEP "test-avail-late-keep" +#define TYPE_LATE_DROP "test-avail-late-drop" +#define TYPE_ORPHAN_PARENT "test-avail-orphan-parent" +#define TYPE_ORPHAN "test-avail-orphan" +#define TYPE_CYCLE_A "test-avail-cycle-a" +#define TYPE_CYCLE_B "test-avail-cycle-b" + +static bool test_never(const TargetInfo *ti) +{ + (void)ti; + return false; +} + +static const TypeInfo i386_parent_info = { + .name = TYPE_I386_PARENT, + .parent = TYPE_OBJECT, + .is_available = target_is_base_i386, +}; + +static const TypeInfo i386_child_info = { + .name = TYPE_I386_CHILD, + .parent = TYPE_I386_PARENT, +}; + +static const TypeInfo never_info = { + .name = TYPE_NEVER, + .parent = TYPE_OBJECT, + .is_available = test_never, +}; + +static const TypeInfo never_child_info = { + .name = TYPE_NEVER_CHILD, + .parent = TYPE_NEVER, +}; + +static const TypeInfo drop_child_info = { + .name = TYPE_DROP_CHILD, + .parent = TYPE_OBJECT, + .is_available = test_never, +}; + +static const TypeInfo test_if_info = { + .name = TYPE_TEST_IF, + .parent = TYPE_INTERFACE, +}; + +static void register_kept_types(void) +{ + /* Child before parent: inherit is a list walk, not register order. */ + type_register_static(&i386_child_info); + type_register_static(&i386_parent_info); + type_register_static(&never_child_info); + type_register_static(&never_info); + type_register_static(&drop_child_info); + type_register_static(&test_if_info); +} + +static void test_roots(void) +{ + ObjectClass *obj = object_class_by_name(TYPE_OBJECT); + ObjectClass *iface = object_class_by_name(TYPE_INTERFACE); + + g_assert_nonnull(obj); + g_assert_nonnull(iface); + g_assert(object_class_get_is_available(obj) == target_is_any); + g_assert(object_class_get_is_available(iface) == target_is_any); + g_assert_true(object_class_get_is_available(obj)(target_info())); +} + +static void test_inherit_family(void) +{ + ObjectClass *parent = object_class_by_name(TYPE_I386_PARENT); + ObjectClass *child = object_class_by_name(TYPE_I386_CHILD); + + if (target_is_base_i386(target_info())) { + g_assert_nonnull(parent); + g_assert_nonnull(child); + g_assert(object_class_get_is_available(parent) == target_is_base_i386); + g_assert(object_class_get_is_available(child) == target_is_base_i386); + } else { + g_assert_null(parent); + g_assert_null(child); + } +} + +static void test_filter_never(void) +{ + g_assert_null(object_class_by_name(TYPE_NEVER)); + g_assert_null(object_class_by_name(TYPE_NEVER_CHILD)); + g_assert_null(object_class_by_name(TYPE_DROP_CHILD)); +} + +static void test_interface_inherit(void) +{ + ObjectClass *klass = object_class_by_name(TYPE_TEST_IF); + + g_assert_nonnull(klass); + g_assert(object_class_get_is_available(klass) == target_is_any); +} + +static void register_late_keep(void) +{ + static const TypeInfo late_keep_info = { + .name = TYPE_LATE_KEEP, + .parent = TYPE_OBJECT, + }; + + type_register_static(&late_keep_info); +} + +static void register_late_drop(void) +{ + static const TypeInfo late_drop_info = { + .name = TYPE_LATE_DROP, + .parent = TYPE_OBJECT, + .is_available = test_never, + }; + + type_register_static(&late_drop_info); +} + +static void test_late_keep(void) +{ + ObjectClass *klass; + + module_call_init_fn(MODULE_INIT_QOM, register_late_keep, &error_abort); + klass = object_class_by_name(TYPE_LATE_KEEP); + g_assert_nonnull(klass); + g_assert(object_class_get_is_available(klass) == target_is_any); +} + +static void test_late_drop(void) +{ + module_call_init_fn(MODULE_INIT_QOM, register_late_drop, &error_abort); + g_assert_null(object_class_by_name(TYPE_LATE_DROP)); +} + +static void register_orphan(void) +{ + static const TypeInfo parent_info = { + .name = TYPE_ORPHAN_PARENT, + .parent = TYPE_OBJECT, + .is_available = test_never, + }; + static const TypeInfo child_info = { + .name = TYPE_ORPHAN, + .parent = TYPE_ORPHAN_PARENT, + .is_available = target_is_any, + }; + + type_register_static(&parent_info); + type_register_static(&child_info); +} + +static void test_orphan_parent(void) +{ + Error *err = NULL; + + module_call_init_fn(MODULE_INIT_QOM, register_orphan, &err); + g_assert_nonnull(err); + g_assert_cmpstr(error_get_pretty(err), ==, + "Type '" TYPE_ORPHAN "' is missing its parent '" + TYPE_ORPHAN_PARENT "'"); + error_free(err); +} + +static void register_cycle(void) +{ + static const TypeInfo a_info = { + .name = TYPE_CYCLE_A, + .parent = TYPE_CYCLE_B, + }; + static const TypeInfo b_info = { + .name = TYPE_CYCLE_B, + .parent = TYPE_CYCLE_A, + }; + + type_register_static(&a_info); + type_register_static(&b_info); +} + +static void test_cycle(void) +{ + Error *err = NULL; + + module_call_init_fn(MODULE_INIT_QOM, register_cycle, &err); + g_assert_nonnull(err); + g_assert_true(strstr(error_get_pretty(err), "cyclic parent chain") != NULL); + error_free(err); +} + +static void test_init_fn_before_call_init(void) +{ + if (g_test_subprocess()) { + test_roots(); + test_inherit_family(); + test_filter_never(); + test_interface_inherit(); + return; + } + g_test_trap_subprocess(NULL, 0, 0); + g_test_trap_assert_passed(); +} + +int main(int argc, char **argv) +{ + g_test_init(&argc, &argv, NULL); + + g_assert_nonnull(target_info()); + + if (g_test_subprocess()) { + module_call_init_fn(MODULE_INIT_QOM, register_kept_types, &error_abort); + module_call_init(MODULE_INIT_QOM); + } else { + module_call_init(MODULE_INIT_QOM); + module_call_init_fn(MODULE_INIT_QOM, register_kept_types, &error_abort); + } + + g_test_add_func("/qom/is-available/roots", test_roots); + g_test_add_func("/qom/is-available/inherit-family", test_inherit_family); + g_test_add_func("/qom/is-available/filter-never", test_filter_never); + g_test_add_func("/qom/is-available/interface-inherit", + test_interface_inherit); + g_test_add_func("/qom/is-available/late-keep", test_late_keep); + g_test_add_func("/qom/is-available/late-drop", test_late_drop); + g_test_add_func("/qom/is-available/orphan-parent", test_orphan_parent); + g_test_add_func("/qom/is-available/cycle", test_cycle); + g_test_add_func("/qom/is-available/init-fn-before-call-init", + test_init_fn_before_call_init); + + return g_test_run(); +} -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:20:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:20:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430501.1653025 (Exim 4.92) (envelope-from ) id 1x9Mtp-00006W-6G; Wed, 23 Sep 2026 13:20:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430501.1653025; Wed, 23 Sep 2026 13:20:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mtp-00006P-38; Wed, 23 Sep 2026 13:20:37 +0000 Received: by outflank-mailman (input) for mailman id 1430501; Wed, 23 Sep 2026 13:20:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mtn-0008TQ-Os for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:20:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mtn-007wnY-5D for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:20:35 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d21b-2eae-0a2a0a5409dd-0a2a450bc160-24 for ; Wed, 23 Sep 2026 15:20:35 +0200 Received: from [74.125.229.145] (helo=mail-dl2-f17.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d221-b7e8-0a2a450b0019-4a7de591804f-3 for ; Wed, 23 Sep 2026 15:20:34 +0200 Received: by mail-dl2-f17.google.com with SMTP id a92af1059eb24-143859f5737so1241018c88.2 for ; Wed, 23 Sep 2026 06:20:34 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.20.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:20:31 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169633; x=1790774433; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=yfDI7d67qBZp7NF6DoFzOD4nojzBBuGOhVVy0hvKz60=; b=s++WbVN4pYoTdDQlYIu945KAjllnruHg/N9sP3ecBuD0yzBqe3NX2jbn7ecC1MIRcF I02xPlLAKwm/vQtmn0g2+uxZm3eOfEftbLKrBgdgTPcTQNuw+39BZh+XEeKnwWbspBGj j5hZwCbYK4FzLVshEsP0jQFZWGoZyXiY0E/EYxSZtK1gr0SHPOk9EYe3ixLMJTWtLZ8t qN2YjYUng6NJiZuhMuxB79OxVjU5h4XlaDdsVtU4PKQhZE3mpBD4dCLfX8dXN8rP8GVh xX6iaMnYKMlGgjt3sCUJ0R7zz8rhg4U1JwDeEKABRnvtMBi55aPlvx+ZEK7gTqLzcFwj eeMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169633; x=1790774433; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=yfDI7d67qBZp7NF6DoFzOD4nojzBBuGOhVVy0hvKz60=; b=JuCk3B3vgf5SoRFL7Ogql8TC4OtMHBDYIRe1rbI5Etdypn4AFGdxh1K1/ks9xK4Gmm ZQTT31fyx2U3rGIon6n73KONa6CtAiA5QVpWCzlIYYxhoNYo+PZDYUYzvLtypc+cj4h/ bhDe9Q29v5PauH+T3KF4i7e2mEPykFTCVer3PzaXbHuWCgbBhb3gXqN6Mm2TE5wKltb7 aPlXIgsQiDKC72RKAGzT9njxh6luovYU7KyheyZrZcovQoUI5Ghlh/sevqF5eostOTaF ToKBOZ+y4Qxed/kHvGTJBs4rnDlL2iJ6m1jSD0WneO0FxatoMPT+UbdSg5TZsclfcDhi ncJA== X-Forwarded-Encrypted: i=1; AKwUvBzML1gzlGt82soGcS4jwSGX1xK4jYb4cSEoV5fsMXssWwsd++kKkiCnfDoOreUQ8kCLFb+/B+Q2YLk=@lists.xenproject.org X-Gm-Message-State: AFuF++kqzokCG57MGE/e7a99VQinTR5/sOM0H3Ihzdn4/KUXEEyyLQS1 BoGna71yKKIFNwzrLx9N9ZQk/1qJ68NFnuVXhXpfYdDBN8/buGTOD2Bi X-Gm-Gg: AYBFou1MU1ycVFvmBOEbIN1Zna2QWXgAzieWO2kesHQjlHULl/lFlhIlYyRh587dpAE yQzM/ltmeDdOHjG9GYB3M4cM2BuxttHUphK4e58KHwTUd1mddVbdOjA+k2BDVQFaTRQeswMJSdS Pcx64NQAoY3yIkDVaL1phQf9iOzYsFRDVJGSZA2nczVQCHxFX5oVs5wCXrJcDVugDWkWK/z36kt yEEEJqZXXzogOUsPhUgKKHkPhC8gpwh5ptJuYFlGcXnGaTC8XMTd5kMA15QUVBJSvqv9bQpBigf EF/1KQ2y5DeV9vt7SQn2cRJbld3lIOsWy3i1bI+rJE3BPLDrAc3a2/MqpN7U/YKQUA38dhdhbta GxtCPYJ1RzIzq4xsfSEIr7XWvN438kbocdjP5zXL88sB/ZZ9UdrqDTUfXOi0KhuNCsS2vEBoqnE 7F/OxXN/DIy8umGIy0KSu+MzbG4OBZaIWXLDcf0XiwO+jt84vKoxmkNQPhMjHqEeYGhlyRB3Oam kaUBxBaMIEDOcLl7Bx7EwRu7h+qE2HZQCEIK1E4og== X-Received: by 2002:a05:7022:3f81:b0:144:c113:77bb with SMTP id a92af1059eb24-144f9179520mr3177544c88.26.1790169632575; Wed, 23 Sep 2026 06:20:32 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 021/114] hw/arm/virt: prefix ACPI helpers with arm_virt_ Date: Wed, 23 Sep 2026 21:14:55 +0800 Message-ID: <20260923131635.1894-22-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790169635-2C59A9EA-1044DC69/0/0 X-purgate-type: clean X-purgate-size: 4805 - virt_acpi_setup and virt_is_acpi_enabled are generic names also used by RISC-V and LoongArch virt. A combined binary cannot export two functions with the same C symbol. - Rename the ARM helpers to arm_virt_acpi_setup and arm_virt_is_acpi_enabled. Leave the trace event virt_acpi_setup unchanged; it is a separate identifier. Signed-off-by: Yonggang Luo Reviewed-by: Philippe Mathieu-Daudé --- hw/arm/virt-acpi-build.c | 4 ++-- hw/arm/virt.c | 12 ++++++------ include/hw/arm/virt.h | 4 ++-- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c index d368913e766..5737c3a8fa4 100644 --- a/hw/arm/virt-acpi-build.c +++ b/hw/arm/virt-acpi-build.c @@ -1559,7 +1559,7 @@ static const VMStateDescription vmstate_virt_acpi_build = { }, }; -void virt_acpi_setup(VirtMachineState *vms) +void arm_virt_acpi_setup(VirtMachineState *vms) { AcpiBuildTables tables; AcpiBuildState *build_state; @@ -1570,7 +1570,7 @@ void virt_acpi_setup(VirtMachineState *vms) return; } - if (!virt_is_acpi_enabled(vms)) { + if (!arm_virt_is_acpi_enabled(vms)) { trace_virt_acpi_setup(); return; } diff --git a/hw/arm/virt.c b/hw/arm/virt.c index c8ffa1ceaf4..331fae883c7 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -769,7 +769,7 @@ static void fdt_add_cpu_nodes(VirtMachineState *vms) &bottom_node, CPU_TOPOLOGY_LEVEL_SOCKET); if (cache_at_topo_level) { - if (bottom_node == 1 && !virt_is_acpi_enabled(vms)) + if (bottom_node == 1 && !arm_virt_is_acpi_enabled(vms)) error_setg( &error_fatal, "Cannot share L1 at socket_id %d." @@ -809,7 +809,7 @@ static void fdt_add_cpu_nodes(VirtMachineState *vms) top_cluster, bottom_cluster, cpu, &cluster_offset); - if (bottom_cluster == 1 && !virt_is_acpi_enabled(vms)) { + if (bottom_cluster == 1 && !arm_virt_is_acpi_enabled(vms)) { error_setg(&error_fatal, "Cannot share L1 at socket_id %d, cluster_id %d. " "DT limitation on sharing at cache level = 1.", @@ -2036,7 +2036,7 @@ static void create_smmuv3_dev_dtb(VirtMachineState *vms, DeviceState *dev, hwaddr base = platform_bus_get_mmio_addr(pbus, sbdev, 0); MachineState *ms = MACHINE(vms); - if (!(vms->bootinfo.firmware_loaded && virt_is_acpi_enabled(vms))) { + if (!(vms->bootinfo.firmware_loaded && arm_virt_is_acpi_enabled(vms))) { if (object_property_get_bool(OBJECT(dev), "accel", &error_abort)) { error_setg(errp, "SMMUv3 with accel=on not supported for DT"); return; @@ -2446,7 +2446,7 @@ void virt_machine_done(Notifier *notifier, void *data) pci_bus_add_fw_cfg_extra_pci_roots(vms->fw_cfg, vms->bus, &error_abort); - virt_acpi_setup(vms); + arm_virt_acpi_setup(vms); virt_build_smbios(vms); } @@ -3210,7 +3210,7 @@ static void machvirt_init(MachineState *machine) create_pcie(vms); create_cxl_host_reg_region(vms); - if (aarch64 && firmware_loaded && virt_is_acpi_enabled(vms)) { + if (aarch64 && firmware_loaded && arm_virt_is_acpi_enabled(vms)) { vms->acpi_dev = create_acpi_ged(vms); vms->generic_error_notifier.notify = virt_generic_error_req; notifier_list_add(&acpi_generic_error_notifiers, @@ -3560,7 +3560,7 @@ static void virt_set_oem_table_id(Object *obj, const char *value, } -bool virt_is_acpi_enabled(const VirtMachineState *vms) +bool arm_virt_is_acpi_enabled(const VirtMachineState *vms) { if (vms->acpi == ON_OFF_AUTO_OFF) { return false; diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index 383ee320948..2ee61cc5a06 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -218,8 +218,8 @@ struct VirtMachineState { #define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("arm-virt") OBJECT_DECLARE_TYPE(VirtMachineState, VirtMachineClass, VIRT_MACHINE) -void virt_acpi_setup(VirtMachineState *vms); -bool virt_is_acpi_enabled(const VirtMachineState *vms); +void arm_virt_acpi_setup(VirtMachineState *vms); +bool arm_virt_is_acpi_enabled(const VirtMachineState *vms); #define CLIDR_CTYPE_NO_CACHE 0x00 #define CLIDR_CTYPE_I_CACHE 0x01 -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:20:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:20:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430505.1653035 (Exim 4.92) (envelope-from ) id 1x9Mty-0000Zy-EH; Wed, 23 Sep 2026 13:20:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430505.1653035; Wed, 23 Sep 2026 13:20:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mty-0000Zq-As; Wed, 23 Sep 2026 13:20:46 +0000 Received: by outflank-mailman (input) for mailman id 1430505; Wed, 23 Sep 2026 13:20:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mtx-0000X9-BV for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:20:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mtw-009DAy-OY for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:20:44 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d22b-e002-0a2a0a5209dd-0a2a4509bc6a-8 for ; Wed, 23 Sep 2026 15:20:44 +0200 Received: from [74.125.229.34] (helo=mail-dy2-f34.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d22b-be1a-0a2a45090019-4a7de5228003-3 for ; Wed, 23 Sep 2026 15:20:44 +0200 Received: by mail-dy2-f34.google.com with SMTP id 5a478bee46e88-33be7dfcfc1so1002987eec.1 for ; Wed, 23 Sep 2026 06:20:44 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.20.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:20:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169642; x=1790774442; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=F3AfQfrqvQe4UOX8IvAjiJQ3WGlTiTKTbcrqm5A18SE=; b=ERv2Bmhtd/OGw4iswNS8VuVbudwdeDEy+dteW5g8OH07+r8VdTO+DrZy5IMGpfGH5g wPi2/FWr7NEFKYGI30l69F+C8iM+7vGzb0fpu7iPJKRms/vQInuk0lZSuDK32nNgEeCv FUS6YhuDniQ3BoGJiI3u/aXzKN8RIwuH3oqbGE7gyEsDJ45NRXUvwgZa2ip/eggQlzxf JQuczYoNnzFqyTQ0HlejshSs0qInKA4j3+WT/skq8PfLF/qKMmKhArOiz9vKnrgpiZ8T AcHc58Q1JuwkboAOQBVhNeaEJ12y+BwUGymlFk9zyoz97NPvOd9DbOP1CQ6/W+8oOu8M XtGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169642; x=1790774442; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=F3AfQfrqvQe4UOX8IvAjiJQ3WGlTiTKTbcrqm5A18SE=; b=09MbbECtiG/VoKnQ0RRQkitWoWHUlRjOTcTfvX3tsJFTzi69P13wWES0HXJzVJYfjW O8NLosZ6KAOCBzINqzLedaMR9QVrW5umIjWxqnwMF5maVsjDBtxMqN/yxqkFFMcODg3D gyL/WbnrPW0brtZ9tHrxyIcFT+vlNHugxTQ4WQLoOu/9dG0onWjRMFse8Sag1WbQM2gN x94wwpGNln82C8D9qr2OdR/CY1sH3/T8J5mHcCLgWVIhcyBGNwJndF/3eHec/CwpwTat wJE+WoxmukUCRjOGkMIwUrudj1QeBXvPaobIFIeHzBKkwJmNIbecDS9AJFPR5OMpW+kb PrfA== X-Forwarded-Encrypted: i=1; AKwUvBw2CcMTZhq13LMyBcGfg1Cdx9yBHdlTZusBNzmWNrqcxVRrg7PPACY/4jcXTTnc01gvuofIx9DerVs=@lists.xenproject.org X-Gm-Message-State: AFuF++lWRIeEDBgmhrUP0tOL5oGeWlwTwa+NV8O4fElHibHzTNIU2ZDD WEixAyh2Jfdqq0wFFxhosn+ymzM0wqigh0FtSA2CSX+wB6Zscu4iPZMV X-Gm-Gg: AYBFou2AYGfx8yzdrwj3oJf3Qhm1kSWpS7iaLoV200OIe63SgJNpmgaA87mU4Z6li91 XQBpFoim/div6N1qm9WXRikwQXabbVW9kN8IxGqHhB+fICyMAca71Tsj87m++ozRhlBwNyoVz22 V+arzPv680ySXPuP/tXPsHCFhqR1QoezdGl5RBu4HaiKxK38tWQ01ycK0Zc/HxnbaMURaSOCBGS 708AcYFY3XQzCxarlB4cQKnKt+zuLFWZxkgHKcOULMQhUmZeQIZRsCOW1sFWBSo4skLueSjMvon bmFBe3nfRdfkjqiANRgUtMoQGp+VPVU/LqPbmD4gWeduuVjum0gMGLyrmrssUZfj2JgKol3Rtii 56OwsxQVpuT0IK7rVE3aBpFYY2MzC0FcVHrM1/Q5wGr2G2GJ0mTn/zcwnH3cWcXJq9nfwCnz9r/ Kjz5XufgAWIaH0bYpfmy9jvW8cbPytVKGP76p3YVrFL9BgLNXz58h18DYfu3lq3r3iZCcTpzGpm WYcx7EoDSGj7oyrQPlbNqVmQhDlXhR2lkMMqTItlg== X-Received: by 2002:a05:693c:638c:20b0:339:7da3:a4f8 with SMTP id 5a478bee46e88-33e8d6d1242mr2659932eec.19.1790169641572; Wed, 23 Sep 2026 06:20:41 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 022/114] hw/riscv/virt: prefix ACPI helpers with riscv_virt_ Date: Wed, 23 Sep 2026 21:14:56 +0800 Message-ID: <20260923131635.1894-23-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1790169644-BD4C3034-F82B072F/0/0 X-purgate-type: clean X-purgate-size: 2396 - virt_acpi_setup and virt_is_acpi_enabled collide with ARM virt when both architectures are linked into one qemu-system binary. - Rename the RISC-V helpers to riscv_virt_acpi_setup and riscv_virt_is_acpi_enabled. Leave file-local virt_acpi_build* names unchanged. Signed-off-by: Yonggang Luo Reviewed-by: Philippe Mathieu-Daudé --- hw/riscv/virt-acpi-build.c | 2 +- hw/riscv/virt.c | 6 +++--- include/hw/riscv/virt.h | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/hw/riscv/virt-acpi-build.c b/hw/riscv/virt-acpi-build.c index 8e516ec1148..de47631852f 100644 --- a/hw/riscv/virt-acpi-build.c +++ b/hw/riscv/virt-acpi-build.c @@ -1021,7 +1021,7 @@ static const VMStateDescription vmstate_virt_acpi_build = { }, }; -void virt_acpi_setup(RISCVVirtState *s) +void riscv_virt_acpi_setup(RISCVVirtState *s) { AcpiBuildTables tables; AcpiBuildState *build_state; diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index 686222fa0da..0edf75fefc3 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -706,8 +706,8 @@ static void virt_machine_done(Notifier *notifier, void *data) virt_build_smbios(s); - if (virt_is_acpi_enabled(s)) { - virt_acpi_setup(s); + if (riscv_virt_is_acpi_enabled(s)) { + riscv_virt_acpi_setup(s); } } @@ -1067,7 +1067,7 @@ static void virt_set_iommu_sys(Object *obj, Visitor *v, const char *name, visit_type_OnOffAuto(v, name, &s->iommu_sys, errp); } -bool virt_is_acpi_enabled(RISCVVirtState *s) +bool riscv_virt_is_acpi_enabled(RISCVVirtState *s) { return s->acpi != ON_OFF_AUTO_OFF; } diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h index 969aa5866ee..1cdc5840b7a 100644 --- a/include/hw/riscv/virt.h +++ b/include/hw/riscv/virt.h @@ -121,9 +121,9 @@ enum { #define VIRT_PLIC_SIZE(__num_context) \ (VIRT_PLIC_CONTEXT_BASE + (__num_context) * VIRT_PLIC_CONTEXT_STRIDE) -bool virt_is_acpi_enabled(RISCVVirtState *s); +bool riscv_virt_is_acpi_enabled(RISCVVirtState *s); bool virt_is_iommu_sys_enabled(RISCVVirtState *s); -void virt_acpi_setup(RISCVVirtState *vms); +void riscv_virt_acpi_setup(RISCVVirtState *vms); /* * The virt machine physical address space used by some of the devices -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:20:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:20:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430511.1653045 (Exim 4.92) (envelope-from ) id 1x9Mu8-00010L-MH; Wed, 23 Sep 2026 13:20:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430511.1653045; Wed, 23 Sep 2026 13:20:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mu8-00010E-II; Wed, 23 Sep 2026 13:20:56 +0000 Received: by outflank-mailman (input) for mailman id 1430511; Wed, 23 Sep 2026 13:20:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mu7-0000ya-CR for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:20:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mu6-007wu5-Pd for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:20:54 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d22d-2eae-0a2a0a5409dd-0a2a4504b8b6-38 for ; Wed, 23 Sep 2026 15:20:54 +0200 Received: from [74.125.229.170] (helo=mail-dl2-f42.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d235-b57f-0a2a45040019-4a7de5aa9499-3 for ; Wed, 23 Sep 2026 15:20:54 +0200 Received: by mail-dl2-f42.google.com with SMTP id a92af1059eb24-144efd1ea76so758608c88.1 for ; Wed, 23 Sep 2026 06:20:54 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.20.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:20:50 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169652; x=1790774452; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=eK1WJJTOKN3JQC4zjqi0U64pp0hPplv7AhkYIkHOF98=; b=c07hm7wJbVpWjLf5dQk7gSN7xwuxu4qq83ilX6/p5ooCHWbGLre9Glre9ei6zBHYTc 0MaY0TF25Hd3qSvRXGLeU02K4QfCkoMcA+hUQ/6Y7YZK+1Qwp5V5SrEGhXHAZbSZvXLB Gkgb5RWTrrpc6EZ83U/zDHpOqyfwa3pXheOkUxbUKia/phyzz1pr/CMskQe0D2JuiwSp Wm8hE6vzRG3agQ/TrZeVep6aETGcQqkjVJOt6fOMiB9AsAEp26Djt8HRF3F6e3fTK2x3 HbpIvmsg5nrM3v+qI80JiOmCL8m9YYeFNB6m/UAmAxenJcIqeW6YeA4H9LWejMrtG6Kj msGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169652; x=1790774452; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=eK1WJJTOKN3JQC4zjqi0U64pp0hPplv7AhkYIkHOF98=; b=aQ8FDl9p15OwRjLQemC4bmXK4cPndD3LwnmoPbrweOD1OVix+skVLML1N56YDdTr6h K69OVUxaCFmOniqOPOYUk69ppPsbgxwzL2mRQ4cIeUkaNikzcfbXL6cT5YoJeJT2NNsA 0733vKEg4nkEYevNyrL5pjqrIdtpZ3koNuF0KMctI0Eh1xOIx36HGyk87bbGEP375PNZ 8OydsR1J8aWXOzJCjszGYx730Xwfdx6IrKIWCzi5kWPIxOEO/1ed7kp/s+Q7ZRIEu/bj v8j+X9dxp3PCpSnSNpYJN6PhnpLVOB7Gge5GNXPOz7VwuFH5hjw3C5u8CwmYBQ+4JSM3 nwbw== X-Forwarded-Encrypted: i=1; AKwUvBwfvdvY6hZmVsuFOOVTxGYmzgAZi8N1RgGfoUfNqatRh+1Ch8NMn6jxnLUjOpN6X5YFQ9fxK08aZCE=@lists.xenproject.org X-Gm-Message-State: AFuF++ll2pcQhUSSh1HmO4gp/JgJw7tQk2y8yOv+g7GU6u8TC3SECr2U Wzr/ogvHqEC2HBsqugMrdXN08y/oegfnmumiP4stgwlD99xuMlS4295P X-Gm-Gg: AYBFou22zW/QebKCvDP1G/yIfjRAqxUFrMc659m/ukWgEXDecx42kl2wTwphAJz0Xu7 R35x9ARl/CbaPOwZgF0DsJqsxhJfBrnnQtAeA7LE0X3BjmDwBB70m+p6545c0eO2GIsIVLmYK6x hJd64doSj/NVq/O1P+DBi0HpvdWCE8VQhYCrvTuNJ5yS0ogAWYWab6pLA+CHnRkCMC8dhI+eCl/ oNlEudynnMcz5EMEgmgziy0RUVbCd9krY/EV9mDoB0A4WB2lBHlxUNmxKLCzb09KteTTLK6ikv4 J9YxDVqytRK+pbTPlnDLRLBnMXC+qlm6+hN5c/UCcKYThkql2ZMqW/I59sMWuTh0n8Pq++6Ewjb 1HxEW5R0OoKJ8sqo24AVyij2E0wbVPxp+e8ESHTxVXw0dznWw8GjxWN7Cjw+5lgldQoFYPstnA2 Rv3sPfep7GW6Wtqs0f0CoU/QgEjRlVCMnEQ+wG0tElDuO58PaLUw1fn/BoxiLhdcvgj3cKlzGNO L8hnrPtaoGJVU/Cw9Tsz65r17fWMP8DWAhI5H7vXQ== X-Received: by 2002:a05:701b:42d3:10b0:143:5c2a:e488 with SMTP id a92af1059eb24-144f8fc7b95mr2889651c88.0.1790169652322; Wed, 23 Sep 2026 06:20:52 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 023/114] hw/loongarch/virt: prefix ACPI helper with loongarch_virt_ Date: Wed, 23 Sep 2026 21:14:57 +0800 Message-ID: <20260923131635.1894-24-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790169654-528C9B50-128891B9/0/0 X-purgate-type: clean X-purgate-size: 2868 - virt_acpi_setup is the same C symbol used by ARM and RISC-V virt. Rename it now so a later combined binary does not need meson -D prefixes for LoongArch. - Rename the file-local virt_is_acpi_enabled to loongarch_virt_is_acpi_enabled to match. Signed-off-by: Yonggang Luo Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Song Gao --- hw/loongarch/virt-acpi-build.c | 6 +++--- hw/loongarch/virt.c | 2 +- include/hw/loongarch/virt.h | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/hw/loongarch/virt-acpi-build.c b/hw/loongarch/virt-acpi-build.c index 600ef60fc58..b9df9b3a127 100644 --- a/hw/loongarch/virt-acpi-build.c +++ b/hw/loongarch/virt-acpi-build.c @@ -674,7 +674,7 @@ static const VMStateDescription vmstate_acpi_build = { }, }; -static bool virt_is_acpi_enabled(LoongArchVirtMachineState *lvms) +static bool loongarch_virt_is_acpi_enabled(LoongArchVirtMachineState *lvms) { if (lvms->acpi == ON_OFF_AUTO_OFF) { return false; @@ -682,7 +682,7 @@ static bool virt_is_acpi_enabled(LoongArchVirtMachineState *lvms) return true; } -void virt_acpi_setup(LoongArchVirtMachineState *lvms) +void loongarch_virt_acpi_setup(LoongArchVirtMachineState *lvms) { AcpiBuildTables tables; AcpiBuildState *build_state; @@ -692,7 +692,7 @@ void virt_acpi_setup(LoongArchVirtMachineState *lvms) return; } - if (!virt_is_acpi_enabled(lvms)) { + if (!loongarch_virt_is_acpi_enabled(lvms)) { ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); return; } diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c index 2b003443eb0..18923500fc2 100644 --- a/hw/loongarch/virt.c +++ b/hw/loongarch/virt.c @@ -242,7 +242,7 @@ static void virt_done(Notifier *notifier, void *data) LoongArchVirtMachineState *lvms = container_of(notifier, LoongArchVirtMachineState, machine_done); virt_build_smbios(lvms); - virt_acpi_setup(lvms); + loongarch_virt_acpi_setup(lvms); virt_fdt_setup(lvms); } diff --git a/include/hw/loongarch/virt.h b/include/hw/loongarch/virt.h index 09529de48bd..4316a414f44 100644 --- a/include/hw/loongarch/virt.h +++ b/include/hw/loongarch/virt.h @@ -132,7 +132,7 @@ struct LoongArchVirtMachineState { #define TYPE_LOONGARCH_VIRT_MACHINE MACHINE_TYPE_NAME("loongarch-virt") OBJECT_DECLARE_SIMPLE_TYPE(LoongArchVirtMachineState, LOONGARCH_VIRT_MACHINE) -void virt_acpi_setup(LoongArchVirtMachineState *lvms); +void loongarch_virt_acpi_setup(LoongArchVirtMachineState *lvms); void virt_fdt_setup(LoongArchVirtMachineState *lvms); static inline bool virt_has_dmsi(LoongArchVirtMachineState *lvms) -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:21:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:21:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430527.1653053 (Exim 4.92) (envelope-from ) id 1x9MuJ-0001bG-20; Wed, 23 Sep 2026 13:21:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430527.1653053; Wed, 23 Sep 2026 13:21:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MuI-0001b4-UQ; Wed, 23 Sep 2026 13:21:06 +0000 Received: by outflank-mailman (input) for mailman id 1430527; Wed, 23 Sep 2026 13:21:05 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MuH-0001UR-Bu for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:21:05 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MuG-007wu5-Os for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:21:04 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d234-2eae-0a2a0a5409dd-0a2a4505b64c-30 for ; Wed, 23 Sep 2026 15:21:04 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d23f-4cb1-0a2a45050019-4a7de50ca0b7-3 for ; Wed, 23 Sep 2026 15:21:04 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-33bb1a50f6fso374830eec.2 for ; Wed, 23 Sep 2026 06:21:04 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.20.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:20:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169662; x=1790774462; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=qin3vLUrrbcXuVdau3Ouu4JIt8wWynB3TLlDqfsVk5s=; b=ULn8iY4QT/hiFBbaAUdsAjADi5QXDDYONdteKlAqfgscOaTFQGCk4Wd64heJ+k1GEJ 91uYRIHGKJVqJs+QNrMJm+KMhynYB+7Bxi/HoNJsfcq0scWTv5x6E6FIukRMgHmqQ5fp DTyVgyYyXxmtz3YPSp8oi5uvvCXYNLLLTBp/rGe+cbRnPIr/gvmB8RSZ573dUSkjWgvh 8rrtf0VxGmlZANGGxBaS5g4R0dc4JtC5HR+7axfLcMsjL+nV6oFJ1TZyNOBhgcLFDfR4 2TlKmzu9de0Ev+dWjuVRIF1PvhqpzIIqucF0+4OErtYOmn3dLEyB5DnETZxZYz9Mvac3 L4fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169662; x=1790774462; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=qin3vLUrrbcXuVdau3Ouu4JIt8wWynB3TLlDqfsVk5s=; b=Qkh74r8FIWTK2lej4RIwZbKi6bLgjJYxxsv1qjRys+T+/6pwmSJRbc628SXrxFukAy jQl99/8HmJufsb8xfgdIwRdJWohXfyvk5qsODOE1rw5egpFxqKvWCXHQbBmByX33aq1Y z9QVznabTacA9xD+pIMKrPxnfMBgAkd254LjKuAIEcUzVOiSdxFIMfT1tLspNm+KLj28 hvosvAdB+5siE+S+qwq41oZmzBMVZfLrKuHUXkrJFGQ/cj0m8F3zF//vQNu9Jg+HOefE n+snEUNyOBlZsxvVdRVQHxIXa0GXvHqYGBQZcsn2astaE3J8h53HFmDxfnTyHEUN+Bhh bzVA== X-Forwarded-Encrypted: i=1; AKwUvBzd0Oj4K9R9xH6K4T7RDFRK0LQh52iImJCI6YM+EO8PD8FvAdq9N2sRKecY34R5IgD90gKWO9rxsac=@lists.xenproject.org X-Gm-Message-State: AFuF++kRDMlJwCoaV/qJk1k3RX5ezl7dNGdFNJOpEcn+Gnx9ubJIpkPk Z8YKaB8Tm9Yy9R+fhYZ6rNfQfe0HFNtRrckicgU8yN/nHXFgCbl2ZTUD X-Gm-Gg: AYBFou0Pgqhxlm5Md4PxONzYRf/djdf+ODF93U9EVjCIzrgDsqkZ6DXCRLIsQKZMjL3 QkdrSY1QWnWp/lQY7hYEdbkJYoaYY+MHu7zxFlPtQ/29heyBDwNaaWTO4ruBj6COUoFLxoH8tlW 52RhzWp2qDxfl/eYRnQI+POpxtwSFGAqIF7/SDNkImBf4et1MNt7LkOzMSfqqtQnbLYyiVRud4U GfRlMlZGZJZ0IoeeeG/pxTqnxCbZS4JEBB9vFzvPG5Cf0T4vDiDC6n61zzTUE8atZop7+7SfkdK tvGjIaAb3qrNX6RoAA/fl59v5MHX2poFA6khlHuSSIUokEAUE9QfAxYuweUVT3Cf4W9IWjDMJSZ UmIFGS3+POQPeOsxfsSVdKOQh0FdwKIa2IsxrlfJPmZD43ErW1HrjaYorHhwHqofzo9keHA9dm2 bLgfGteoUgHTK1NctTbAylK2tvmpPpZGqEhUle3K20/d47clji1ocs+j6EN4nFWOB9MO9/C7ko4 CUN9S8g/KHY06ZOKj2ouycVGkcQuvh8eT34fxXEpw== X-Received: by 2002:a05:7300:a224:b0:33c:141b:73a5 with SMTP id 5a478bee46e88-33e8e1afe12mr2620027eec.41.1790169661766; Wed, 23 Sep 2026 06:21:01 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 024/114] target/riscv: uniquify TCG crc32, crc32c, and wfi helper names Date: Wed, 23 Sep 2026 21:14:58 +0800 Message-ID: <20260923131635.1894-25-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790169664-716AD2A1-0CE5E16F/0/0 X-purgate-type: clean X-purgate-size: 4810 - ARM already exports helper_crc32, helper_crc32c, helper_wfi, and the matching helper_info_* objects. RISC-V used the same DEF_HELPER names, which collide in a combined qemu-system link. - Rename the RISC-V helpers to riscv_crc32, riscv_crc32c, and riscv_wfi so the generated C symbols are unique without meson -D prefixes. Signed-off-by: Yonggang Luo --- target/riscv/helper.h | 6 +++--- target/riscv/tcg/bitmanip_helper.c | 4 ++-- target/riscv/tcg/insn_trans/trans_privileged.c.inc | 2 +- target/riscv/tcg/insn_trans/trans_xlrbr.c.inc | 4 ++-- target/riscv/tcg/op_helper.c | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/target/riscv/helper.h b/target/riscv/helper.h index 9458a5152be..ef629b3c650 100644 --- a/target/riscv/helper.h +++ b/target/riscv/helper.h @@ -83,8 +83,8 @@ DEF_HELPER_FLAGS_1(unzip, TCG_CALL_NO_RWG_SE, tl, tl) DEF_HELPER_FLAGS_1(zip, TCG_CALL_NO_RWG_SE, tl, tl) DEF_HELPER_FLAGS_2(xperm4, TCG_CALL_NO_RWG_SE, tl, tl, tl) DEF_HELPER_FLAGS_2(xperm8, TCG_CALL_NO_RWG_SE, tl, tl, tl) -DEF_HELPER_FLAGS_2(crc32, TCG_CALL_NO_RWG_SE, tl, tl, tl) -DEF_HELPER_FLAGS_2(crc32c, TCG_CALL_NO_RWG_SE, tl, tl, tl) +DEF_HELPER_FLAGS_2(riscv_crc32, TCG_CALL_NO_RWG_SE, tl, tl, tl) +DEF_HELPER_FLAGS_2(riscv_crc32c, TCG_CALL_NO_RWG_SE, tl, tl, tl) /* Floating Point - Half Precision */ DEF_HELPER_FLAGS_3(fadd_h, TCG_CALL_NO_RWG, i64, env, i64, i64) @@ -134,7 +134,7 @@ DEF_HELPER_1(sret, tl, env) DEF_HELPER_1(mret, tl, env) DEF_HELPER_1(mnret, tl, env) DEF_HELPER_1(ctr_clear, void, env) -DEF_HELPER_1(wfi, void, env) +DEF_HELPER_1(riscv_wfi, void, env) DEF_HELPER_1(wrs_nto, void, env) DEF_HELPER_1(tlb_flush, void, env) DEF_HELPER_1(tlb_flush_all, void, env) diff --git a/target/riscv/tcg/bitmanip_helper.c b/target/riscv/tcg/bitmanip_helper.c index d8d94bca7ba..5af3efe194d 100644 --- a/target/riscv/tcg/bitmanip_helper.c +++ b/target/riscv/tcg/bitmanip_helper.c @@ -117,7 +117,7 @@ target_ulong HELPER(xperm8)(target_ulong rs1, target_ulong rs2) return do_xperm(rs1, rs2, 3); } -target_ulong HELPER(crc32)(target_ulong rs1, target_ulong sz) +target_ulong HELPER(riscv_crc32)(target_ulong rs1, target_ulong sz) { for (target_ulong i = 0; i < sz; i++) { rs1 = crc32_table[rs1 & 0xFF] ^ (rs1 >> 8); @@ -126,7 +126,7 @@ target_ulong HELPER(crc32)(target_ulong rs1, target_ulong sz) return rs1; } -target_ulong HELPER(crc32c)(target_ulong rs1, target_ulong sz) +target_ulong HELPER(riscv_crc32c)(target_ulong rs1, target_ulong sz) { for (target_ulong i = 0; i < sz; i++) { rs1 = crc32c_table[rs1 & 0xFF] ^ (rs1 >> 8); diff --git a/target/riscv/tcg/insn_trans/trans_privileged.c.inc b/target/riscv/tcg/insn_trans/trans_privileged.c.inc index a8eaccef67e..0df78e89745 100644 --- a/target/riscv/tcg/insn_trans/trans_privileged.c.inc +++ b/target/riscv/tcg/insn_trans/trans_privileged.c.inc @@ -144,7 +144,7 @@ static bool trans_wfi(DisasContext *ctx, arg_wfi *a) #ifndef CONFIG_USER_ONLY decode_save_opc(ctx, 0); gen_update_pc(ctx, ctx->cur_insn_len); - gen_helper_wfi(tcg_env); + gen_helper_riscv_wfi(tcg_env); return true; #else return false; diff --git a/target/riscv/tcg/insn_trans/trans_xlrbr.c.inc b/target/riscv/tcg/insn_trans/trans_xlrbr.c.inc index 01da2b6ce1d..795231f0839 100644 --- a/target/riscv/tcg/insn_trans/trans_xlrbr.c.inc +++ b/target/riscv/tcg/insn_trans/trans_xlrbr.c.inc @@ -29,11 +29,11 @@ static bool gen_crc(DisasContext *ctx, arg_r2 *a, #define TRANS_CRC32(NAME, SIZE) \ static bool trans_crc32_##NAME(DisasContext *ctx, arg_r2 *a) \ { if (SIZE == 8) { REQUIRE_64BIT(ctx); }; \ - return gen_crc(ctx, a, gen_helper_crc32, tcg_constant_tl(SIZE)); } + return gen_crc(ctx, a, gen_helper_riscv_crc32, tcg_constant_tl(SIZE)); } #define TRANS_CRC32C(NAME, SIZE) \ static bool trans_crc32c_##NAME(DisasContext *ctx, arg_r2 *a) \ { if (SIZE == 8) { REQUIRE_64BIT(ctx); }; \ - return gen_crc(ctx, a, gen_helper_crc32c, tcg_constant_tl(SIZE)); } + return gen_crc(ctx, a, gen_helper_riscv_crc32c, tcg_constant_tl(SIZE)); } TRANS_CRC32(b, 1); TRANS_CRC32(h, 2); diff --git a/target/riscv/tcg/op_helper.c b/target/riscv/tcg/op_helper.c index a00370a7973..4f4932614f1 100644 --- a/target/riscv/tcg/op_helper.c +++ b/target/riscv/tcg/op_helper.c @@ -591,7 +591,7 @@ void helper_ctr_clear(CPURISCVState *env) riscv_ctr_clear(env); } -void helper_wfi(CPURISCVState *env) +void HELPER(riscv_wfi)(CPURISCVState *env) { CPUState *cs = env_cpu(env); bool rvs = riscv_has_ext(env, RVS); -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:21:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:21:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430541.1653061 (Exim 4.92) (envelope-from ) id 1x9MuS-00028d-90; Wed, 23 Sep 2026 13:21:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430541.1653061; Wed, 23 Sep 2026 13:21:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MuS-00028U-5k; Wed, 23 Sep 2026 13:21:16 +0000 Received: by outflank-mailman (input) for mailman id 1430541; Wed, 23 Sep 2026 13:21:15 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MuR-00026E-IH for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:21:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MuQ-006PU6-VW for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:21:14 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d241-bab6-0a2a0a5309dd-0a2a4506e044-44 for ; Wed, 23 Sep 2026 15:21:14 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d249-195a-0a2a45060019-4a7de50cd6a8-3 for ; Wed, 23 Sep 2026 15:21:14 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-32dbbe82e13so794109eec.0 for ; Wed, 23 Sep 2026 06:21:14 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.21.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:21:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169673; x=1790774473; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=aW7Q/4+ozQSDE0PZQ7E9tHZoVUU6eb45JG6HfJcLS94=; b=XQ5zYR1YF4Mch1mAi3R+9eR4DVKvZs9BsBo3ic79SdjEUi15Zb9pxtffber1XrPIyo xfJtY9DowFJYrh/hagxcOwdnLYIOdwvq7YL4/PTrfuQFd2I1xnw/G8GwDM5B+H4yFBMh QuZFq5GoAHf2Ic6/fqrW2BeKvOjrM5Yor4L6lIfRr5l5UQOZC2EWLqu8sDkw8rMv67zJ cRtilbTs0MEks5LruC1pruDzgyVoXkIKRyRhhr60cyD4KNA9g4COtcKUx6ExA18EFKUg oHPIiWNMa7zqjDgfOE7Wt5diovM0pUFe33B6U7fbzuBII85SV68jOi9ruNqcyLKdMD9P J4CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169673; x=1790774473; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=aW7Q/4+ozQSDE0PZQ7E9tHZoVUU6eb45JG6HfJcLS94=; b=aVkPdUN2DNlO7uhHT5vA38k/Ls7Cp/Ga01dchXCddgtX5FWJyJSatJvoolTO5qtPl4 FvK0vHM59k27vhfXy+TmkEnKKo5tXXIy9WtOM3AKw/DyMGm+W5mk6u7sD8oT866bixOu 8xTlHT6ghusKB5nTCbc17aJ84E2ny2iWJecdzGk5c9yLmTXcHmAcRbqDRVldqI9iGxqH ErgD/Phl93sIHD2cJKSIs9kmUJIlWjvAoKS5MHlyr/7X1ZselXOy/kJeYxqNMw2nMHp5 9qfq1u1eaNDZGtGyp8tMLCo+IiFn++YQduJRTYalBcug/LGqogr/gR89FKEj9qbiA1Hr flPA== X-Forwarded-Encrypted: i=1; AKwUvBxmRP/SNvWn/aLboIXyQ0C3Blb5LMpBg3c8M4vuUYCGtcYhDw2RMxR7CjK9CwyYR42JgGHCejNCwCk=@lists.xenproject.org X-Gm-Message-State: AFuF++kbDGgJXlW1xjDD9IjulTBONutAk3XSOVrfemKmyDsRh1J+hoJo B2gTPhlIjKFAanWGrRg8eHh9tcTjxlSNN1iZmH0L/CRm1z1A9A6EmqyQ X-Gm-Gg: AYBFou3bCCOGJaNDbtu5QjrSE3+TFZtiHa9QlktARLCSSR/P4EOu/mvhzaOcqdvRol9 GFG/5ClxSjJuZqqSKhIpxC+0vYqS61HyPdMDKey+C6MeyPOlv2K50LFQHXMOy3J2XQOKy1V7JLp bS824m5SwzF0jPEOKKFzfkj92MSnc16YeqaYhOaZQY3qqyJBQAlxNiwis16GrQZT3kWHavrThYv 1JzbosUhUwpWp9VhkZGnUneNppbhDuLe0BDVaQKX7f8HZyJrNCOgpbwI3DiS872eVycZ+JHYA+p b+uSLEOeLLogvjhZm0MgxDhgIiQviNvXeLopgC8/AFY3tZxib9pwC5mRFsPM6+V0jy9CyIFxMVg qIYBxV78jDkEDPABjDyJAbchzzazaYX+NoemKAawHvEdG6VDo95z20XBnUeJFMwOL9NKUr2sfEH pczqMZnORRr6i6UmBNSbkxIJWomZgo1sJ/tqm83S5+YC6yt74PLfD6Btk4+8Ladv1D7Uffxx01K 6kxa2cAm8eraYklolue9oloKHMYDwEwD2f9EWFcUJAKIRFDKFZJJA== X-Received: by 2002:a05:7300:cca4:b0:33b:fc68:9790 with SMTP id 5a478bee46e88-33e8d2ebd99mr2512374eec.21.1790169672443; Wed, 23 Sep 2026 06:21:12 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 025/114] hw/riscv: gate boards with target_is_base_riscv Date: Wed, 23 Sep 2026 21:14:59 +0800 Message-ID: <20260923131635.1894-26-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790169674-F7ECC77B-C89AFAC8/0/0 X-purgate-type: clean X-purgate-size: 6241 - Set TypeInfo.is_available to target_is_base_riscv on RISC-V machines so a combined qemu-system lists them only for riscv32/riscv64. --- hw/riscv/k230.c | 1 + hw/riscv/microchip_pfsoc.c | 1 + hw/riscv/opentitan.c | 1 + hw/riscv/shakti_c.c | 1 + hw/riscv/sifive_e.c | 1 + hw/riscv/sifive_u.c | 1 + hw/riscv/spike.c | 1 + hw/riscv/tt_atlantis.c | 1 + hw/riscv/virt.c | 1 + hw/riscv/xiangshan_kmh.c | 1 + 10 files changed, 10 insertions(+) diff --git a/hw/riscv/k230.c b/hw/riscv/k230.c index 79715265da6..3890cb6357d 100644 --- a/hw/riscv/k230.c +++ b/hw/riscv/k230.c @@ -557,6 +557,7 @@ static void k230_machine_class_init(ObjectClass *oc, const void *data) static const TypeInfo k230_machine_typeinfo = { .name = TYPE_RISCV_K230_MACHINE, .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .class_init = k230_machine_class_init, .instance_init = k230_machine_instance_init, .instance_size = sizeof(K230MachineState), diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c index cc4b6bc3529..103c0d7f7ca 100644 --- a/hw/riscv/microchip_pfsoc.c +++ b/hw/riscv/microchip_pfsoc.c @@ -756,6 +756,7 @@ static void microchip_icicle_kit_machine_class_init(ObjectClass *oc, static const TypeInfo microchip_icicle_kit_machine_typeinfo = { .name = MACHINE_TYPE_NAME("microchip-icicle-kit"), .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .class_init = microchip_icicle_kit_machine_class_init, .instance_init = microchip_icicle_kit_machine_instance_init, .instance_size = sizeof(MicrochipIcicleKitState), diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c index 9e3db34eed9..db1fb3e3347 100644 --- a/hw/riscv/opentitan.c +++ b/hw/riscv/opentitan.c @@ -337,6 +337,7 @@ static const TypeInfo open_titan_types[] = { }, { .name = TYPE_OPENTITAN_MACHINE, .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .instance_size = sizeof(OpenTitanState), .class_init = opentitan_machine_class_init, .is_available = target_is_riscv32, diff --git a/hw/riscv/shakti_c.c b/hw/riscv/shakti_c.c index 0f96258b764..e8ae770f7ca 100644 --- a/hw/riscv/shakti_c.c +++ b/hw/riscv/shakti_c.c @@ -95,6 +95,7 @@ static void shakti_c_machine_class_init(ObjectClass *klass, const void *data) static const TypeInfo shakti_c_machine_type_info = { .name = TYPE_RISCV_SHAKTI_MACHINE, .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .class_init = shakti_c_machine_class_init, .instance_init = shakti_c_machine_instance_init, .instance_size = sizeof(ShaktiCMachineState), diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c index 1b6f9ab4fee..087d0c48e1e 100644 --- a/hw/riscv/sifive_e.c +++ b/hw/riscv/sifive_e.c @@ -165,6 +165,7 @@ static void sifive_e_machine_class_init(ObjectClass *oc, const void *data) static const TypeInfo sifive_e_machine_typeinfo = { .name = MACHINE_TYPE_NAME("sifive_e"), .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .class_init = sifive_e_machine_class_init, .instance_init = sifive_e_machine_instance_init, .instance_size = sizeof(SiFiveEState), diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c index 344f3d915d7..d5cc9255da6 100644 --- a/hw/riscv/sifive_u.c +++ b/hw/riscv/sifive_u.c @@ -679,6 +679,7 @@ static void sifive_u_machine_class_init(ObjectClass *oc, const void *data) static const TypeInfo sifive_u_machine_typeinfo = { .name = MACHINE_TYPE_NAME("sifive_u"), .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .class_init = sifive_u_machine_class_init, .instance_init = sifive_u_machine_instance_init, .instance_size = sizeof(SiFiveUState), diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c index 63cf77e1de3..4bb58ec6203 100644 --- a/hw/riscv/spike.c +++ b/hw/riscv/spike.c @@ -292,6 +292,7 @@ static void spike_machine_class_init(ObjectClass *oc, const void *data) static const TypeInfo spike_machine_typeinfo = { .name = MACHINE_TYPE_NAME("spike"), .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .class_init = spike_machine_class_init, .instance_init = spike_machine_instance_init, .instance_size = sizeof(SpikeState), diff --git a/hw/riscv/tt_atlantis.c b/hw/riscv/tt_atlantis.c index 086e95bd2d1..6e7272d705c 100644 --- a/hw/riscv/tt_atlantis.c +++ b/hw/riscv/tt_atlantis.c @@ -699,6 +699,7 @@ static const TypeInfo tt_atlantis_types[] = { }, { .name = MACHINE_TYPE_NAME("tt-atlantis"), .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .class_init = tt_atlantis_machine_class_init, .instance_size = sizeof(TTAtlantisState), .is_available = target_is_riscv64, diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index 0edf75fefc3..2240a516d85 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -1202,6 +1202,7 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) static const TypeInfo virt_machine_typeinfo = { .name = TYPE_RISCV_VIRT_MACHINE, .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .class_init = virt_machine_class_init, .instance_init = virt_machine_instance_init, .instance_finalize = virt_machine_instance_finalize, diff --git a/hw/riscv/xiangshan_kmh.c b/hw/riscv/xiangshan_kmh.c index 6bc669421fe..9578a11aee6 100644 --- a/hw/riscv/xiangshan_kmh.c +++ b/hw/riscv/xiangshan_kmh.c @@ -220,6 +220,7 @@ static void xiangshan_kmh_machine_class_init(ObjectClass *klass, const void *dat static const TypeInfo xiangshan_kmh_machine_info = { .name = TYPE_XIANGSHAN_KMH_MACHINE, .parent = TYPE_MACHINE, + .is_available = target_is_base_riscv, .instance_size = sizeof(XiangshanKmhState), .class_init = xiangshan_kmh_machine_class_init, .is_available = target_is_riscv64, -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:21:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:21:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430544.1653071 (Exim 4.92) (envelope-from ) id 1x9Mub-0002X7-HC; Wed, 23 Sep 2026 13:21:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430544.1653071; Wed, 23 Sep 2026 13:21:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mub-0002Wz-E3; Wed, 23 Sep 2026 13:21:25 +0000 Received: by outflank-mailman (input) for mailman id 1430544; Wed, 23 Sep 2026 13:21:24 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mua-0002V1-KZ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:21:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mua-007x0m-1S for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:21:24 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d248-2eae-0a2a0a5409dd-0a2a45019c7c-20 for ; Wed, 23 Sep 2026 15:21:24 +0200 Received: from [74.125.229.22] (helo=mail-dy2-f22.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d252-5984-0a2a45010019-4a7de516806c-3 for ; Wed, 23 Sep 2026 15:21:23 +0200 Received: by mail-dy2-f22.google.com with SMTP id 5a478bee46e88-33bf5a1c4d9so901848eec.3 for ; Wed, 23 Sep 2026 06:21:23 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.21.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:21:19 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169682; x=1790774482; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Xe2eD+AiZP/2qt9dfiB6B/fVlOtPvZaEy5H5CusisPI=; b=JngE89EcHuzonfcInxuRbWhL35cJiiz/3a27eYOepiozbOGtfrZ1ydEYqeLAJJ/EsB 2SrLWanBG8Xm8lnyqc+aUvaTImWATPLGb+UoItNNe0slvSDjR+hPOQjq36jhjRhqAb63 hqMg4bMp7/IYCKNNNXxo6cLEuGOFWUrc0qimnv49sJ0HTXQfQDo4NU9mV3LnoqCbrYb1 eVveMiDgvA//gr7rCq7CaCsjXcJrcMeTw260YRsJVythQRlCT3VCezpKqTdGtPpIqSfU 9qrMPpU7IODfY3FmxIN7DKhRes/r2GWd44yGjQK4RyGUIYiFHhzU2uitZPlhJz8epbI9 x6OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169682; x=1790774482; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Xe2eD+AiZP/2qt9dfiB6B/fVlOtPvZaEy5H5CusisPI=; b=086TGH+pwtGuVvaa9WQUL+hzBt7Uut6fLambEZbaKDz4dCdLB9RGjbKqEpSN873bm0 G/tTBdwhQi1dffhZcKG3SUB26SO6j6IVDx2aOyKLSQerh888nnBwIm5Vt1vCVa3eTf4X yXWkKcRvxD9kvIJWr0KsZNm3jwhomjNr7oQDIyYB9BOyEppQnIdGwZU3Y6wH8h64F/g9 xoB3BLkXp2piJAKNYiE7vbkYwDe/dpiFp/U0UKSpb/ZV+fE0Lx0hNozEpo1s5PgVSqF4 Lvfe+8rS/pFXRjOXWKIo80O2cFLCWEtilWEKlziJbWGQGsWecJoZVHig1G7ksJznff7R ho9w== X-Forwarded-Encrypted: i=1; AKwUvBzsJbqi8YqVAdlsmukOiJ72KxwL8C0AyDTGOSXro8si33BzMwwcIstu9GdZJVvPZTcRe0oYwGhxG1U=@lists.xenproject.org X-Gm-Message-State: AFuF++m82K6KYz6PZpbnZhsNPWH733VyUjAi5a+pWV6kx4uf/F2w3VkY LMq52kGNgUYoPSqtQqAqBKzZETwRBzxmYs/1W+koq6/kvmHGpt3enJBD X-Gm-Gg: AYBFou1rKPgcaLWiGP+CrHA+GBE3u7q+iZuble5HjIl0ACZldmlyXn3v+v5xF0unwAF jcC4Q3mE9H5gDLiSH1yAsWpZXdMIxoMLLU2jhn6J1jqXbw3s31iL9q68OzOrXhbvnyi/O1v9/Gz wMzW655ERn403XUgJO0jt5xe/WJDs/GQz2gu7XS38fXbrneKfLmAae57ZBg898fQ/rM1LoQu+uW 472gsQc526Bl4/AMhedo0PexUu7ZkozG1mid1NxMCYAEywhbdh/7YQoEuxMmRT6y7dJ2SCQIEmv wObKUssNlMuBt9GUDD9nvDdH3uzGn4Hr0jkG2bfIxNw1dqL4TtWXnRaxCKuxjLqiT5yS5gzpbvQ x1ostjml5FdaubwApqjwLDc7ETMmXNO6lQ0H7BwrAgzJP8PMyt8FZ2TqauVoDn8CtLnjPY9Hbuu WjiIK8c4xTexLSUa6/fZdfvkWDHTaQntNo/Y5ihTzwh2cjBfHcnnoMkLddLNIKTZmPFDy9JFfdg 6D2QY0oZvozmtls5WzRGPQaDv80r7ECLxAk6yLDgg== X-Received: by 2002:a05:7300:8242:b0:339:7909:9782 with SMTP id 5a478bee46e88-33e8d9ce7f9mr2561360eec.21.1790169681656; Wed, 23 Sep 2026 06:21:21 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 026/114] hw/intc: use target_long_bits in IMSIC geilen Date: Wed, 23 Sep 2026 21:15:00 +0800 Message-ID: <20260923131635.1894-27-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790169684-BD341757-46695DE3/0/0 X-purgate-type: clean X-purgate-size: 623 - Compare geilen to target_long_bits() instead of TARGET_LONG_BITS so the check works when TARGET_* is poisoned. --- hw/intc/riscv_imsic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/intc/riscv_imsic.c b/hw/intc/riscv_imsic.c index bf0434e96fd..30fb60cc312 100644 --- a/hw/intc/riscv_imsic.c +++ b/hw/intc/riscv_imsic.c @@ -52,7 +52,7 @@ static void riscv_cpu_set_geilen(CPURISCVState *env, uint8_t geilen) return; } - if (geilen > (TARGET_LONG_BITS - 1)) { + if (geilen > (target_long_bits() - 1)) { return; } -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:21:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:21:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430554.1653081 (Exim 4.92) (envelope-from ) id 1x9Mum-00033T-Vw; Wed, 23 Sep 2026 13:21:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430554.1653081; Wed, 23 Sep 2026 13:21:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mum-00033H-Qs; Wed, 23 Sep 2026 13:21:36 +0000 Received: by outflank-mailman (input) for mailman id 1430554; Wed, 23 Sep 2026 13:21:35 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mul-00031h-0h for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:21:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Muk-007x4B-Du for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:21:34 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d25e-2eae-0a2a0a5409dd-0a2a4504abd2-2 for ; Wed, 23 Sep 2026 15:21:34 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d25c-b57f-0a2a45040019-4a7de52b930e-3 for ; Wed, 23 Sep 2026 15:21:34 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-33c3735125bso410509eec.3 for ; Wed, 23 Sep 2026 06:21:33 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.21.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:21:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169692; x=1790774492; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=huS4A6FsKFDWrrXfwa21/vS+oZaWC4wTWSJg3SCD6Do=; b=UOcW8haf4Xc6fjHt9QaOV5SDqcL4KM3mMxx8d9jU6s1gh/RlYhUxVmbKS6ESuSekW/ cYRY08d1gLdDpEkCZZmJCYpbwVPTVbz9YIwlIm8InxSbzBehIr1TrwE0cCrOl2lrV4Za GzAQU7G6PbEelN6whRs8jAs1WQg1dEAjQSHNuZNrcj7QRddzK481K2cdRldhaxIzqNz2 LROtoV1ZgOkPZF65KwgrAzwRRfYwyH8m4Spo1dlgd12TIKVd7Mv4l0GqN1KUZyVIeOuW bM73aBrF+SK1lTXeolhlicvs3OmBUzgLWcH2/SHaSErnl1nt9mvU88BYn249RlqW1dID Zong== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169692; x=1790774492; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=huS4A6FsKFDWrrXfwa21/vS+oZaWC4wTWSJg3SCD6Do=; b=n9NROeuIf8Nc+GB4mZrkSnW1hS3GRC8OpU9dcwE2JUSdLfRaytwLI9FhQ0HJMI9lc9 hUzNVVZwPBpfGgmpIAQYh97SwQZv/U5EDpKaEQnFEfLd3V9RP692j3Z+MZ6G1QQnz1Cx 3bdG3TWERu4a9B7vBUP5Ane8OHCJjv1h3umfk4rmVHwsAMl+tIdm4gVUj3CmC4d9/u1C Eb+iuHLC2OfCp6ok8gxH9VRqr6YVoa9tpDPH9Xb3RoGf3PehPAol5RjFjRtBA4US8PAu xXElK2VdfAFyUHH20Bx5CLOqj1ZjTlSmzh6sSf4T1P4E6cWYt6s3b5jBu+AikyM6AP0h q0+A== X-Forwarded-Encrypted: i=1; AKwUvBz232/HUUkwNEFGtCgnnxVeMp8E2Sdj7LW38w/05s0h1xZy3jjI+U72PiFUa6S+PaKmF3F/ypyetXA=@lists.xenproject.org X-Gm-Message-State: AFuF++ldifEdoJiTX6N1I4x4YYwXXlRVX3KEU+Gi70H1CBGC1SxEGego Xvb5xneGzXFNu3kCW0VBtTMkixdrQysxsSY1cuKt3qNQXHW6j0Lb5HfP X-Gm-Gg: AYBFou0fjUS01L8t9lGaMMVAgmo67xgm9nE0ajWRqAmKJa0qKMqEHyuBVhhAugq+i9k vKPQoWf3V7N8gGGh3tR/wD+brvvT29Meowl9Gdyho3jur9oLKdWKQClMDYI9g8tT7tGUnHu/aRY XxIXQAqu3oOk0aPtNy3bMvviUfMYExjsdJHaOmqUac1Z1LGr7wD82iVoJdSv/FprCVzDjivqfBH 9UB5yV/7dnnfPdUCdRctunfJU3lrmo5WsCjToXkpNElA5gIYy95jRdEcTcnXCBlu6rhh3PBdDNr V2VcUNJpZegWrZ1dee2NiZDKyLExnXsqFMio8eodTGut0cm27IGlzCmdXciuOFS1XuQ1wxUukkS /xo7GscNLMKHaADixVglC9rRjc42Wx/iSh7Q7kRgB+Z0TmHsS7ECPKiOc+0ZtqHmrAb3KPyCosq LA76847oAF2/hSCAFy0VJhIzsU1x+U8yLHFvirPfbwZJD06OYcu7cLjG5vHjp0Ua4VXUCEN+XCb o33s6gmTbAl59fzchyJnUmt3KWYuzaltptlJz2uAw== X-Received: by 2002:a05:693c:42d9:b0:33b:e75b:cc42 with SMTP id 5a478bee46e88-33e8d7d8b7bmr2063395eec.19.1790169691801; Wed, 23 Sep 2026 06:21:31 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 027/114] hw/misc/riscv_cmgcr: replace target_ulong with uint64_t Date: Wed, 23 Sep 2026 21:15:01 +0800 Message-ID: <20260923131635.1894-28-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790169694-53AC0B50-120FC315/0/0 X-purgate-type: clean X-purgate-size: 785 - Change get_exception_base() to return uint64_t so the GCR model compiles in libsystem_riscv with -DCPU_DEFS_H. - Match reset_base and cpu_set_exception_base(), which already use uint64_t. --- hw/misc/riscv_cmgcr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/misc/riscv_cmgcr.c b/hw/misc/riscv_cmgcr.c index 0390996f78b..2086a33f08e 100644 --- a/hw/misc/riscv_cmgcr.c +++ b/hw/misc/riscv_cmgcr.c @@ -110,7 +110,7 @@ static uint64_t gcr_read(void *opaque, hwaddr addr, unsigned size) return 0; } -static inline target_ulong get_exception_base(RISCVGCRVPState *vps) +static inline uint64_t get_exception_base(RISCVGCRVPState *vps) { return vps->reset_base & GCR_CL_RESET_BASE_RESETBASE_MSK; } -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:21:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:21:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430562.1653089 (Exim 4.92) (envelope-from ) id 1x9Muy-0003Yd-4R; Wed, 23 Sep 2026 13:21:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430562.1653089; Wed, 23 Sep 2026 13:21:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Muy-0003YV-1L; Wed, 23 Sep 2026 13:21:48 +0000 Received: by outflank-mailman (input) for mailman id 1430562; Wed, 23 Sep 2026 13:21:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Muw-0003Vh-1W for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:21:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Muv-006Pa4-EL for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:21:45 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d262-bab6-0a2a0a5309dd-0a2a450b9ba0-20 for ; Wed, 23 Sep 2026 15:21:45 +0200 Received: from [74.125.229.140] (helo=mail-dl2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d267-b7e8-0a2a450b0019-4a7de58c9069-3 for ; Wed, 23 Sep 2026 15:21:45 +0200 Received: by mail-dl2-f12.google.com with SMTP id a92af1059eb24-142dd04edb4so764526c88.0 for ; Wed, 23 Sep 2026 06:21:44 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.21.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:21:39 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169703; x=1790774503; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=BQcT2TCunpJ4XJOGDsLRORw+wafc2yMdlkK9/vuTXoQ=; b=DtntKWzu3Sqd+TbjcsxRCSsda6fmFmUA14btT+RvQZaUWUSkoUYCyFq7jEXFHQrnwt H8GLtrRZTy5+F7YkTSPzePE2z4T9QfKF2nRbvPfOsasesfyerjcqvx6msaD/jxRzHI40 CpqyTz/f8bOl3Wv8v/t2c3IORiRTzIMTOXRyFH0MmpQvoQxH1k/wwpKnvRDchCmlpIX8 MLj2L+DbtMoEliZlIL9Wdh02nPwl6A8ZI9fBcMdErz7cpR/LuB0SdEF4J7FcYiK+CFet prAy5r1Cx4fXbUa7APP4748n79c6EeMn4r4CiDGhUBxYPhCmv528Ha5TxGXeLEBsN/Le MXWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169703; x=1790774503; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=BQcT2TCunpJ4XJOGDsLRORw+wafc2yMdlkK9/vuTXoQ=; b=qWZn6Xcxdddot2tC0EZvSiw0MK0Rss2lFY4dwn5b6Qtb3B3UnsiJaWb2MC9M8GjyQv cqbjS8pzs2l6rpC1Tyd8AKuB+Hwdnkj1JV9C7zvJR4Qo4GfT2T2ErogNL2/WOFhNth4Q IrA+L7OxOaMQ2NlF0k07tl355Up4wPWgoEwKj+hJEew5U6KzSNP5POM0f8eJXDbgwikO fWrB37x294Y4ZdQ6zgPONZgWwpCIg12sObJip1prBcILwnSaAoJjX7ipg2LbVm0Yuao7 HpduLgNI1awE7yrQw7p91yfPEKUp3ppvNd/wkF0qC761wAWR2+cpGHYqhmbreSY0FG+r sTgw== X-Forwarded-Encrypted: i=1; AKwUvBxOwxZflLCBxB23wVyrKGePkOar3JZdjXzcrhLrAopnJDd3pUj7tZQjC08fCIWAdGzD1g9oDJ3NFfE=@lists.xenproject.org X-Gm-Message-State: AFuF++lLJKtGHHMY0sJls4k3fKUhqh8JsLOYGEsF5idv5wILiDMB/IWu DShHFa5otLktJmeGU+oBugUcH/4VtJl1t9tolcAJMRnBaW5szi3ujcj+ X-Gm-Gg: AYBFou3VG8bteLUsiGbJovzDN9roiPp9qDfymvMmpwPm58ZmdARR+Ye0A/M/JEvv+kr q9AkbpJxr4RpWwHC9DccJEJa12ICZ/Br+rfduTHXi/OKxqBClB0aomjVCE/Fnsyidm8NXy5aUg6 gNKyUeJ6zlzLx64tE2Yyd3oVLKV5m2kUvraf3ligc1MBUuaeguu79nait+ulPnjqpojnF7SjEgc AzRJ/gVeKH1KHJM7cidagEfYDYrigzWboaN0KNeLyCrHI1yPG/d6hB5n61iG5yEDNu1jYO8hvBd YqhTDD62yB+aHkgzKb1y5b63iqu83Ou+wdcUuf1NFxF9ZsfZBZpGiLwp75BS1nqLl7FPjqRkCvL sZSAE+FV7FKx4YIWn8CFHpaxOF6sHcFXKAoDytr0bWx2B+QJfUmIqNpPaHY+1KnbnkiCw5BXtei WGvwcD9E7ttJm45/lo46954Nmp1uOqCWIufeNbg0t++ymgUNVdylDQFkNFzkhfWoTcnu+t3Nh9j +JCV8FoWuaEHxXKoeJwlkGBSuIQmhuR82ZlcRKvnGI= X-Received: by 2002:a05:701b:4551:10b0:144:fd7c:84f4 with SMTP id a92af1059eb24-144fd7c8641mr1564469c88.5.1790169700288; Wed, 23 Sep 2026 06:21:40 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 028/114] hw/intc: use kvm_enabled() in APLIC AIA helpers Date: Wed, 23 Sep 2026 21:15:02 +0800 Message-ID: <20260923131635.1894-29-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790169705-1A2C49EA-A12480D9/0/0 X-purgate-type: clean X-purgate-size: 1295 - Replace CONFIG_KVM ifdefs in riscv_use_emulated_aplic and riscv_aplic_set_kvm_msicfgaddr with kvm_enabled(). --- hw/intc/riscv_aplic.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/hw/intc/riscv_aplic.c b/hw/intc/riscv_aplic.c index d8e25bfda14..03a0852b8b8 100644 --- a/hw/intc/riscv_aplic.c +++ b/hw/intc/riscv_aplic.c @@ -167,7 +167,10 @@ bool riscv_is_kvm_aia_aplic_imsic(bool msimode) bool riscv_use_emulated_aplic(bool msimode) { -#ifdef CONFIG_KVM + if (!kvm_enabled()) { + return true; + } + if (tcg_enabled()) { return true; } @@ -177,21 +180,20 @@ bool riscv_use_emulated_aplic(bool msimode) } return kvm_kernel_irqchip_split(); -#else - return true; -#endif } void riscv_aplic_set_kvm_msicfgaddr(RISCVAPLICState *aplic, hwaddr addr) { -#ifdef CONFIG_KVM + if (!kvm_enabled()) { + return; + } + if (riscv_use_emulated_aplic(aplic->msimode)) { addr >>= APLIC_xMSICFGADDR_PPN_SHIFT; aplic->kvm_msicfgaddr = extract64(addr, 0, 32); aplic->kvm_msicfgaddrH = extract64(addr, 32, 32) & APLIC_MMSICFGADDRH_VALID_MASK; } -#endif } /* -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:21:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:21:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430569.1653098 (Exim 4.92) (envelope-from ) id 1x9Mv8-00040q-Dp; Wed, 23 Sep 2026 13:21:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430569.1653098; Wed, 23 Sep 2026 13:21:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mv8-00040h-AT; Wed, 23 Sep 2026 13:21:58 +0000 Received: by outflank-mailman (input) for mailman id 1430569; Wed, 23 Sep 2026 13:21:56 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mv6-0003wa-GA for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:21:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mv5-006Pd0-T8 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:21:55 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d26e-bab6-0a2a0a5309dd-0a2a4501e51a-10 for ; Wed, 23 Sep 2026 15:21:51 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d26e-5984-0a2a45010019-4a7de50cc127-3 for ; Wed, 23 Sep 2026 15:21:51 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664d340aso547201eec.0 for ; Wed, 23 Sep 2026 06:21:51 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.21.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:21:48 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169710; x=1790774510; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=RGdh00utr6Q+OpO6+8fa0s0hS8SKHylDK/Tx/Y6cmu0=; b=Rdd9FaFGcQNRMMJuwVGacozwC7wKe2KNfY0+UGqfGrRsqUNNFDRbp86U8V0URvZp/E WEmkNl6GfkeLJxtEK/enRc3sxxLYfNJh6BZGLobAA2xz5B2KyopNu2l+NlBXEwdeTOYI DogcXHIV4n8hSau1wiStnob+oS/baz4K1TBVAPAftsOxrNk4+kufS0TxuWd1Z5WOcQrD 2gaDI3RApZ7ISH0JRPinVp1rfTRw0QiXJdTbAfJbeHmLKzi2N0VNWCwWCZZ8xBoK22Ll JPbbzcvPosMf4qZvW1qX6i39sRtAlsx6hA6766OcTKxfNQ1hzCkjK/Iv9QqKIiPZKQj2 z39g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169710; x=1790774510; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=RGdh00utr6Q+OpO6+8fa0s0hS8SKHylDK/Tx/Y6cmu0=; b=FxKcYzJZc00bVZfA8QklX5aYKWRJVT7ItcuQg3huFqr/iyh1iSdxVtI7jHsRoGpVeA 7Ng9mdxBkX9t/Eskv6pS2XHfLmTu/htmlQFgldozq8dLHG8SDfvd5tNW54jy2h0+d06K SYNzDp/OpA8kNNsLAyUyWmrsaQAJshfGT0QhmL8ueoET1j95zFwtkFIPR+y044oAUeJ0 Pu0mVf+dKUAe4deNzi7eMH9+GPb1SiMYt1RcLUV7zXpVDv9b/4w2rfa2SAhNGx7IgvLQ 5DumkQdkOTH8EW1HdNiaQPgl4lqd3le3uqesKeYn+fh1thHz3gcyIXgUwdN6wePe/AE/ qEow== X-Forwarded-Encrypted: i=1; AKwUvBwG0uOX2LCltDORU+keMbRTzfvODtRGxnQ86GhF/RE04SN31HyH9Wxw9zRzRNiflLP6DqqAWjSbFZs=@lists.xenproject.org X-Gm-Message-State: AFuF++kwjddPKJBh3RJfDlM+8sRQfuiNYIktBJoP9HGk9vsefbP7quzP Eur8zbKLt7v9jUjTu8bpP9NJc126ZKWOcT77Wqcr4N0jGFGPudZw820T X-Gm-Gg: AYBFou2U9nDbmwfUgb3IG5wpdh2VVZJX0a8r+99VFelKAQDmqGdGtPPyhzmJXcFRyAL zYmMGnyeHPz9FPGfdPQdGWlZI2e1kg0vKAlIbHcI+WVkDaq4w1c9rNp2LHMp9e7aI3S5Bye4Ka8 0N3NfRbkX8LxbF7BLyjxZsrzUnqAcrKRkTbIYiYaSg44fx5Deyu92Vcl41DZyb6E9DKeGgpXn+N pFx2mYLdOJgsYaEhlwSmF1TOi6j+U/O+HtOtFpLDqThrDg2N3Fr0ApsitjALqAZJU2mRmZbTCtC WiQpM4kvzGxPl95J6c+CHMhlqyIYgVTF86B62e4sFhZo8FEOp2KDjIZBoKzeoqU6vUNK9n9S8Fz 4El+63IdYE50qAw0k6Aqzs7B2zafV9vDqNUQU6kHZgklMWwu37X65I1E24Cw/ZJ7wUMxEEjRY3s ULtsaIAnq/GnUi9+KAEXOztF5S6lGKqVaaV2KQWIxZ0fW6reDBtXY3+1jdv96kmDYxt/GKr4wU3 b/dKNvf5HZWqiHc0e4FAUQurYDtKxY= X-Received: by 2002:a05:693c:88d4:10b0:33b:dcbc:6046 with SMTP id 5a478bee46e88-33e8bc70ee6mr2596067eec.7.1790169709341; Wed, 23 Sep 2026 06:21:49 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 029/114] hw/intc: send IMSIC MSI via kvm_irqchip_send_msi() Date: Wed, 23 Sep 2026 21:15:03 +0800 Message-ID: <20260923131635.1894-30-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d62444/1790169711-BD67C757-64952C21/0/0 X-purgate-type: clean X-purgate-size: 1251 - Drop the CONFIG_KVM ioctl path and call kvm_irqchip_send_msi() when KVM and an in-kernel irqchip are enabled. --- hw/intc/riscv_imsic.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/hw/intc/riscv_imsic.c b/hw/intc/riscv_imsic.c index 30fb60cc312..033b7813060 100644 --- a/hw/intc/riscv_imsic.c +++ b/hw/intc/riscv_imsic.c @@ -311,19 +311,15 @@ static void riscv_imsic_write(void *opaque, hwaddr addr, uint64_t value, goto err; } -#if defined(CONFIG_KVM) - if (kvm_irqchip_in_kernel()) { - struct kvm_msi msi; - - msi.address_lo = extract64(imsic->mmio.addr + addr, 0, 32); - msi.address_hi = extract64(imsic->mmio.addr + addr, 32, 32); - msi.data = le32_to_cpu(value); - - kvm_vm_ioctl(kvm_state, KVM_SIGNAL_MSI, &msi); + if (kvm_enabled() && kvm_irqchip_in_kernel()) { + MSIMessage msg = { + .address = imsic->mmio.addr + addr, + .data = (uint32_t)value, + }; + kvm_irqchip_send_msi(kvm_state, msg); return; } -#endif /* Writes only supported for MSI little-endian registers */ page = addr >> IMSIC_MMIO_PAGE_SHIFT; -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:22:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:22:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430572.1653107 (Exim 4.92) (envelope-from ) id 1x9MvB-0004J3-Kj; Wed, 23 Sep 2026 13:22:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430572.1653107; Wed, 23 Sep 2026 13:22:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MvB-0004Iw-HG; Wed, 23 Sep 2026 13:22:01 +0000 Received: by outflank-mailman (input) for mailman id 1430572; Wed, 23 Sep 2026 13:22:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MvA-0004Ge-Ia for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:22:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mv9-009DZj-VY for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:21:59 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d26f-e002-0a2a0a5209dd-0a2a45028604-32 for ; Wed, 23 Sep 2026 15:21:59 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d276-6ca4-0a2a45020019-4a7de50cc507-3 for ; Wed, 23 Sep 2026 15:21:59 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-3346e75082eso423380eec.1 for ; Wed, 23 Sep 2026 06:21:59 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.21.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:21:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169718; x=1790774518; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=20fmaOno77HQJxryAkVKJDwkjIsA6lPsyx3HFEs6GYM=; b=fg08DtR8zIgBo/fdkUSHRPVTs3tVdIZa1YkebjDzZk7+njQ1UMG3nw/NgAc0B1J9uY LSsKOw5E4n+XRc7NBoh4B4OEsTWw0saMWBsDLCGeyZFz50QCFXCLjJTzPEpx91VlshFy e9P8S6rusdl5bvK9KV5qaawP1FiMtUR9xKXWioUERaehEpVyxMog/1IXfkRLJSjygbms 9DpobUahlPyFxAT9Cv/hV1Gh7Ot/EgJlnwworbLO7hatGZCvZyRbQBfVOFzxZLG8OVMM jIExSp0/haLta0Bz2+UuWhxLW8l7ocAKHGsYzM8p5j+MYvNiLpEQBCMRNkaH6NG7P9Z+ XYIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169718; x=1790774518; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=20fmaOno77HQJxryAkVKJDwkjIsA6lPsyx3HFEs6GYM=; b=pwPuW2WQpKNoXkgsZdMbGKCcqY7Y051NA4KwY+5Y7dqoCGBqv+WiN8KlU2Hoeqfjwx 9RS0wMpZFFU/O173p7/2ZvbkX6kh9MOptjJx8v2sIviO7ORRDVoXN+oGW5IS+R8bWSgH h7aQv3wW/2MUENreAmXzYasYCdHccZcG0nqaw9hznDoEHThs6nFR8Xx9v1Lu6ojTXVks NM0rho/9+Os5g/cSZOyTIkZX/ivbSQJclgoaSGuFSWg0ikdRyVFwy/Rlf/IXPzygn7lb EngOobY3kZNJcIHbQhO2jDVdy1LTOCxt1rAsEPyvPEUUlycPsvBHIyLugNaHPoBGeTT+ LKbQ== X-Forwarded-Encrypted: i=1; AKwUvBwpygtUSB0YgC0kJBqJXA6jlPXFKmXGXKo3UyeLKdaSdg88X8gGH6s5yjUw46gaHRJeeksIKXRxXDc=@lists.xenproject.org X-Gm-Message-State: AFuF++n20euqJ05eoJ7B9RPxLr5Tsa2JP924ni3Dz6vzXDaw2U8iAgZh pH2YGqUHF3rKSJhG2XoCGE1RQIMo/PEZ/0GDjUaaXg4c2Yq4oH4RUv4q X-Gm-Gg: AYBFou0IeKp0xdQN4I0bPzz/bJBK6kBog+0jVWhZybyNy/2Ow8DwzMAdXiTi284oQ9E cxbZfuJKvZUgmsEGmio2ybyAnB+doaKwoZCZQMYIqEJRuTD8MLn12secCFQJhRJysUV7mbiXHzQ +vEb1FJGxgfer57ZEqqwAI76+qGUD4vvaiQjtMNsMpmXRTYS9F2m/nzovb9rPz/aezHupzswJz9 g1BB/TC8v7aBTMjauL5u6tX/CheWuf3PHhNIndYCPm3syLBcHoPD/RP1s+wrLArwg2bRySYqVab Jz/wicCkWYywWZ5VIC2j4abbsFTSiBYyfpU22i7itEQLoDUj2cSK8GkVDW3ReL84s2FBQ80PIOn h9bPPJi+t3qjL1okl03bzjvpms1Ubm0VjruX6nlVyM4AiElXSE1y+PXAhcl/rhvpd/+T/9VJLgg ZtYGqzJfM4AjC6buRDHh744GSjtarwGOr4agI8A8MG3/8eMWqfiTKaLzUwKbZdY0AfUbzum8bBi 31th7KzhBDw8Mw4nV492k6SFz3KAsrQNLjgQ0rr1A== X-Received: by 2002:a05:7301:db0c:b0:33b:96b8:3818 with SMTP id 5a478bee46e88-33e8ddbe14cmr1962518eec.32.1790169717553; Wed, 23 Sep 2026 06:21:57 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 030/114] target/riscv: add kvm stubs source set Date: Wed, 23 Sep 2026 21:15:04 +0800 Message-ID: <20260923131635.1894-31-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790169719-F30B02AC-81CC386F/0/0 X-purgate-type: clean X-purgate-size: 1929 - Add riscv_stubs_ss and kvm-stub.c, matching the ARM target_stubs_arch pattern (has_mp_state returns false; other entry points are g_assert_not_reached). - Register target_stubs_arch += {'riscv': riscv_stubs_ss}. - Leave target_arch / target_system_arch in place; next change can move RISC-V onto target_common_system_arch. Signed-off-by: Yonggang Luo --- target/riscv/kvm/kvm-stub.c | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/target/riscv/kvm/kvm-stub.c b/target/riscv/kvm/kvm-stub.c index 64e39c96d89..1c8c324cd44 100644 --- a/target/riscv/kvm/kvm-stub.c +++ b/target/riscv/kvm/kvm-stub.c @@ -9,6 +9,37 @@ #include "qemu/osdep.h" #include "target/riscv/kvm/kvm_riscv.h" +/* + * Safe to call without KVM. Return "not supported". + */ +bool kvm_riscv_has_mp_state(void) +{ + return false; +} + +/* + * These functions should never actually be called without KVM support. + */ +void kvm_riscv_reset_vcpu(RISCVCPU *cpu) +{ + g_assert_not_reached(); +} + +void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level) +{ + g_assert_not_reached(); +} + +void riscv_kvm_cpu_finalize_features(RISCVCPU *cpu, Error **errp) +{ + g_assert_not_reached(); +} + +uint64_t kvm_riscv_get_timebase_frequency(RISCVCPU *cpu) +{ + g_assert_not_reached(); +} + void kvm_riscv_aia_create(MachineState *machine, uint64_t group_shift, uint64_t aia_irq_num, uint64_t aia_msi_num, uint64_t aplic_base, uint64_t imsic_base, @@ -17,7 +48,7 @@ void kvm_riscv_aia_create(MachineState *machine, uint64_t group_shift, g_assert_not_reached(); } -uint64_t kvm_riscv_get_timebase_frequency(RISCVCPU *cpu) +void riscv_kvm_aplic_request(void *opaque, int irq, int level) { g_assert_not_reached(); } -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:22:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:22:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430583.1653117 (Exim 4.92) (envelope-from ) id 1x9MvL-0004t7-41; Wed, 23 Sep 2026 13:22:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430583.1653117; Wed, 23 Sep 2026 13:22:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MvK-0004sv-W6; Wed, 23 Sep 2026 13:22:10 +0000 Received: by outflank-mailman (input) for mailman id 1430583; Wed, 23 Sep 2026 13:22:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MvJ-0004pO-AJ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:22:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MvI-00BQAt-NI for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:22:08 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d27c-8faa-0a2a0a5109dd-0a2a450bb9a2-12 for ; Wed, 23 Sep 2026 15:22:08 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d27f-b7e8-0a2a450b0019-4a7de50cd980-3 for ; Wed, 23 Sep 2026 15:22:08 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664b7528so678738eec.2 for ; Wed, 23 Sep 2026 06:22:08 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.21.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:22:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169726; x=1790774526; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4msTpp+vR3Q9A3d1BOVyjzK5nl0nVEODWOwLdHYYFFk=; b=ZwQ/Lt7f3AoWtgi4NNjO7nFFxgEbiuYzS6ub+UVQQcIPByryjTAK2MXxv+akjeEBa4 hfLjwl/XJ6OAds2Vg7/Mk8EmNbLsbjc843rqwjb7skC8XSt5R9aN8whioEGbKVscWjnf l247w1PnzEwW+zp9drNq5W6/WlfYtUyHiZsvo8Ohs5rYjUMtVBJB5BOvXj0eDs2wBklr sKV+IZNjCPNk91MnppG1P2ca1xojV7s5QQNpOTk7NYRW90Ri8+hwBeIFXC6f26TujgCR rv/6f3mBtkOWAnpIjO3QxDUftlqupwiRlluiczTYgkVD6/4RaM5Zk/nSu1gMlecbC7XJ dWKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169726; x=1790774526; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=4msTpp+vR3Q9A3d1BOVyjzK5nl0nVEODWOwLdHYYFFk=; b=15wPr4xKCT6AhrZ9Cjp2rWwtjo+mBbyvluddX1HGtSK1/ReGitKnFdidXzDXPrnCpF MQ1r+x4PlRRJdRMFZkoHV3PVwyCeD0GN5pnk7xwtRg14+1LrhE6y0o6GIGlkGfwHp/HG lCZDf1TKRNMDk9HL3BPYlOqQOg+W5/1TKxa47XvPLbsQZrqpKXJc20YIuNxHAXQeYrK3 uMadeh1+sJNrBG1Y7a3VZ5MbJx3HqfPKnyGBAUmQcKWg/ZZ4jaB2Rl8hpilE8esVpO0w UlTf5Au4Ul/JFJ1g9WfkjhDi39ka+WW3N36En2hp92akXH9MCKKJtcOSVtyJYQxwbDKj M0QQ== X-Forwarded-Encrypted: i=1; AKwUvBxpHN4/UwJ/L4CdQtcQAhHfmLob18F0qBTNR/nnM7VUrGcZtm62ztvhfMUCKWEWxQo2I6da176YU9I=@lists.xenproject.org X-Gm-Message-State: AFuF++lmkokxOSUFInXde6Ye8btmYAe8YhQ3ggNKiWQUYUZt0QpbXbIV mI8Y+1ndiNDW55gqaIwuxeqPAwdGSO1JhRK8hdf57f1mAacpcnAOwG6L X-Gm-Gg: AYBFou0XCbvPF3y8pF5Dt1udnt7pET2YQ7Maw/5NDrhdlBw+MCjQVZlnIwOjejYBMTp BuB0EmkluG7arl+1vZjQsFo3BIrPP/xr2BMf8AYGiGKjylj9DHp8y6eXIuKTFcScAMaXuM7N+Ic Xl0v7zlXofhRukWNNJ5B5pj/Ba6G/aBFSaP54SZdNeLui4nmwZMW2/HzV71+cQc3YYaKzMJqWB9 ozmdy+GpdW0Z9q0BgDo8wAxeFexJyli4Mmd6d0WCfPZcmrfTp/oF6Aw8JYaZHXnztJHTqKlRjmP D7+gKsc/P7fMyzDtjAohOX0VnO2GuG390HT3gicg5BmvltlD3xpHycZehk5AIztg2WorVJNE3w6 jT9rPotUSx9w+xC+Z+NjAY82f9wcQwg7LE1Xhob74kiHTHdQtKp2nWMlWW4cxaKsaHbmk/e8IS6 k3doTNwIxKgCVKR9GYp0Q16VPS8dtNbSsRtbHaSnj1V2q61tnSw0SpQ8aGxxFwyT0RmLEeEs8Iw EI0NmqH7XatnS5ZOUUDJMTffLebo58= X-Received: by 2002:a05:7301:d595:b0:33b:e55f:68c8 with SMTP id 5a478bee46e88-33e8d8d21e3mr2659104eec.26.1790169725708; Wed, 23 Sep 2026 06:22:05 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 031/114] tcg: fix off-by-one in helper extend-free assert Date: Wed, 23 Sep 2026 21:15:05 +0800 Message-ID: <20260923131635.1894-32-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790169728-1A4DB9EA-B7EBDC82/0/0 X-purgate-type: clean X-purgate-size: 746 - Allow n_extend == MAX_CALL_IARGS after filling extend_free. - The old < check fired on a valid seven-argument extend. Signed-off-by: Yonggang Luo --- tcg/tcg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tcg/tcg.c b/tcg/tcg.c index 489df0e7386..6d55cc284df 100644 --- a/tcg/tcg.c +++ b/tcg/tcg.c @@ -2599,7 +2599,7 @@ static void tcg_gen_callN(void *func, TCGHelperInfo *info, QTAILQ_INSERT_TAIL(&tcg_ctx->ops, op, link); } - tcg_debug_assert(n_extend < ARRAY_SIZE(extend_free)); + tcg_debug_assert(n_extend <= ARRAY_SIZE(extend_free)); for (i = 0; i < n_extend; ++i) { tcg_temp_free_i64(extend_free[i]); } -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:22:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:22:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430588.1653126 (Exim 4.92) (envelope-from ) id 1x9MvT-0005Jy-CZ; Wed, 23 Sep 2026 13:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430588.1653126; Wed, 23 Sep 2026 13:22:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MvT-0005Jr-7H; Wed, 23 Sep 2026 13:22:19 +0000 Received: by outflank-mailman (input) for mailman id 1430588; Wed, 23 Sep 2026 13:22:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MvR-0005IZ-Lu for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:22:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MvR-00BQAt-2k for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:22:17 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d27c-8faa-0a2a0a5109dd-0a2a450bb9a2-28 for ; Wed, 23 Sep 2026 15:22:16 +0200 Received: from [74.125.229.170] (helo=mail-dl2-f42.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d287-b7e8-0a2a450b0019-4a7de5aac134-3 for ; Wed, 23 Sep 2026 15:22:16 +0200 Received: by mail-dl2-f42.google.com with SMTP id a92af1059eb24-144f47a9b57so964243c88.2 for ; Wed, 23 Sep 2026 06:22:16 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.22.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:22:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169735; x=1790774535; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dE9e1D/hNDaJ+34nzjVxm6PaKrug7kV63zAG9/GlOBQ=; b=U5Ab4cFRUnNhOcO1reKr8zZjobJoNBqEjSaQS84glgOJq/3izbZYN8jybIQpqT7AIX cLPuU/o26UdAc+ZVCAeZnE8yQqHzem2WP2HFV94bZOwc90txY+hJ47q/iUmMR9BVSybu M46W3LZQjFrCHWDN78rFyuW+gWXVFsNc5BS+uBrSa1lhHFfXgNaS4iJpx8U/A6v+Dct2 GXGd/+hA8K5ICshpcFMwU/EY63gfSBZIY6ZC7BFFzdKixFLJpFoVxRdz/wjWzCuU2AnI 2BH9KYoAgvUOh2hV0WRC/T3BnHoW9D0pvyGPMB2UUjNi2IGG7/qvY7LeVf2B/Ukpn6Fw jhqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169735; x=1790774535; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=dE9e1D/hNDaJ+34nzjVxm6PaKrug7kV63zAG9/GlOBQ=; b=ulWZp69V3nyPZpvYseHmKw/eRagrg9mBw6XD4MVnY1HV7ScYPWIK85XHoWzV/Fhtsr HzL2qC4e8ajgXB0RLOzUdU/WA5ay6nvvjpF5fjEVPI1DqicXrC7JNd/Ndd7Q/iizUTu4 uC9h1eWFH8FivyaeutllSV7Ot+wBvBLBb2oOIAMAolrk81N9W2yp0SoVBLQyBOfNgSnL /uOZioVz8v+f/MLvMGAJ1mMnDR4yZ7SDoAG6KVAjMIv2MkjKnhgJBehC784HIa7FfFZa stI0Wlzklrf5RCu/3RCMVmJIPw/srhh8W/MeRniOrj6w3WiBwOZVoFOL0McAr738M36f ogQw== X-Forwarded-Encrypted: i=1; AKwUvByNCUtFUGDMGoh6MZgEGxsIjGhV8Mf1PrLBjR4Gn8XJ7J6eS6uvjB72yZ67BQKwAD7dYJA9BUTDocw=@lists.xenproject.org X-Gm-Message-State: AFuF++lxC93F3NOrKipYQtg3zZiXAKWUCE5Aac5E4MO7eGN9eF5uQWvF iD1Jo9gNH5c7L+0U6CYclV5Kq8VSlD4Qo7/nLJqgUL5dMm+QI0/TPVbk X-Gm-Gg: AYBFou3HFpkJaznXOwKMVjoSUU87to1dslEwlFg5ABRLAnAVj8PKEeDsKtTOxwZeKbh Nni+edcCp7tswIoFhJoOk7rsVvDDvnujBX5/s6F7rTR7czBC+pJUPX0bVSyF7m3EFr7E4K1f+PV CHPNrM91zyNAQZshQ+435K5HfprRPIKltkxSMs0+mrgcoGk6P4RaPqh5OvFr0+aPONbWdO3DoZK UsKi6QhzU+m7/tSf6pUvCqQ4kErlBjyw8ZaCP02DZNrcth74AbR362T0W3xzbQ4TJg8Xn3VFBrk nh0JHOXNTsc/yB5AcYDbdl88iRs5mkweY0hZdIdCi2TO7dizewNJBsQL/iIuwSX7SPRk6sZ2JlY JHaPHDObm6SfuPjSZSnm63jnRjidEUjtzGg1VmPWgb0g3gfl264ncyskHnMLP9D2pPvFr6N/G77 8zs94jYv1YLCK0LmErAZOQcgAVSj/P6kOd4v4xW78xhGw2QiQiZWhikdWwP/AAkFV94vvP92H+x 0hY3PETnWK+B2AwXkNYiPO8FxmYORI= X-Received: by 2002:a05:7022:6b87:b0:143:57c1:6242 with SMTP id a92af1059eb24-144f917e7a9mr3802797c88.26.1790169734421; Wed, 23 Sep 2026 06:22:14 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 032/114] gdbstub: drop per-target cpu-param.h from helpers.h Date: Wed, 23 Sep 2026 21:15:06 +0800 Message-ID: <20260923131635.1894-33-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790169736-19AC09EA-0F5152AA/0/0 X-purgate-type: clean X-purgate-size: 678 - Stop including cpu-param.h from gdbstub/helpers.h so once-compiled gdbstub can use the helpers without TARGET_* macros. Signed-off-by: Yonggang Luo --- include/gdbstub/helpers.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/gdbstub/helpers.h b/include/gdbstub/helpers.h index b2f41d6d280..7250e457c2c 100644 --- a/include/gdbstub/helpers.h +++ b/include/gdbstub/helpers.h @@ -15,9 +15,6 @@ #include "qemu/bswap.h" #include "qemu/target-info.h" -#ifdef COMPILING_PER_TARGET -#include "cpu-param.h" -#endif /* * The GDB remote protocol transfers values in target byte order. As -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:22:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:22:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430593.1653133 (Exim 4.92) (envelope-from ) id 1x9Mvc-0005nM-HV; Wed, 23 Sep 2026 13:22:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430593.1653133; Wed, 23 Sep 2026 13:22:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mvc-0005n8-Ea; Wed, 23 Sep 2026 13:22:28 +0000 Received: by outflank-mailman (input) for mailman id 1430593; Wed, 23 Sep 2026 13:22:26 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mva-0005iw-9S for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:22:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MvZ-007xGa-MP for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:22:25 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d281-2eae-0a2a0a5409dd-0a2a450785e4-34 for ; Wed, 23 Sep 2026 15:22:25 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d290-b4ea-0a2a45070019-4a7de50cb5d6-3 for ; Wed, 23 Sep 2026 15:22:25 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664b7582so520147eec.3 for ; Wed, 23 Sep 2026 06:22:25 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.22.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:22:21 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169743; x=1790774543; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=gZLlHjgFKGd97ZAl0jDOPJ4J/L8M7/uJxBZfNAi1MwY=; b=UiUFYu47rAMR77AAN/2reISqmaCnNrAV0ysTYQsQMyvxcL+RwwHpI3tYEYrO6aKMQq 7e6pJMpxdUWqeegRkbakRubPFypi+iWRnQG7WvNUy3+N5nx4qpwpcGiM6SkE0698YsGY EEOB7CZs3IXEuYX5C75z3XIZ9xzjc3vE9v5dcB+AdNMDxVhTSurFjyQtRrpeYXtA4E3d X4WuGFH5zij5hTfhrgLCecvkUBoAcT217q+wgUwPSy6ia5XrrItOckGGWzoVq1qVXokC CB49un/oDr/9WNzmi4i0s3iDg+d64j08cZGuiHAfdaLuhMHIuoaEwiJakvT2Wymv3n6v z1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169743; x=1790774543; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=gZLlHjgFKGd97ZAl0jDOPJ4J/L8M7/uJxBZfNAi1MwY=; b=jr0YvlsFiySjnUHWyCwBqGRXaPkqRQoTFK0oJSONMybHT303p06y1AGv7cUoQYvBjo wXmRXgZBNI0TRadRpuhRX94/4iu4MVU1yXDwaQ2WtFc6gPH5Ye2Fykhoup+rJ+Avzab+ qUNZ6BlhH+emjjKBjZbx3iB08BysRxtFXvI0PlH8ua93uSAWt28sW8cU7Efl76oYQ/dY sZ0tOLJ1JUeSesiWxy3JMBvXElbNRjd5rFJoOT+I/o5k2RmWNbKsCo+yMTAGqB1iEEvN y68JVL7PrrUE32TYGe8vpUfoKRYXMRujKG8JjABSYLIjCppzTet1tTaSrL30qRtvBOfl BWPQ== X-Forwarded-Encrypted: i=1; AKwUvBxcIwE1TmYUftWzJsZUj7TPDxzOIQ6eVjVtEBqzHeWOjlhWDhigYX0tJrya/FBJpWUdR3/AfH5gvNU=@lists.xenproject.org X-Gm-Message-State: AFuF++mNBiLj8HzTuaxpCuZMHvgPvzBXLyzFd4OzD56izbzykaxvA2mI 8Xbz6pUtm4nuJJoUZmJDPafxFWuyTgXc1feQ5h8sZwuA69ldPjJeJ3n3 X-Gm-Gg: AYBFou1rmWLbNaAxSw2CKOh4exO5syf/yPab8tj1cH+Ve6WS/eA6upE1uMUm19cJC2P ggwR8fyNnUh1eFidYfcjFGOFkgVumWllBjl4OHn40FlQ/a7A0b2ZxQXKcvYwtgpeazOfjLobAG9 VLazudjjphKtoGFc0fFtVYNVy+9cB4btGVLUr2eqQK6YYpVAoqWpqpudgeaigQ0Fs4EF8bXB4la 7MGx9BuynXiYtKPlKsW0A+iajGpn8lietzqL8apzZgWHKdP9f4+uxaXGLyNz2pdIbYCj56tVbmU hxyt4AWDOgkIdvqFZeXlmwO1lgUZpPxDHSYer5a4YzHETasUjw/XIFNejkIq/b2OQ6C/k3sRZpu pRY3XsqFBuFkVNZFE/enb21mSoyyz2dDaoCxHXZtBqlgYePXTuapS4bvMaOuvYx/3jdQYPGDB8u vaRVjktlzANSc/C11qjZueV/lPR/EOP5GmtBczWxMpG4HYfl2C6YTPWMKPNGLUghsJmOg2qYFKs +xES4YIW4PSZbp2XE8GqLPGSDzi//LrU5lNoKg22g== X-Received: by 2002:a05:7301:c016:b0:33b:d4c9:561f with SMTP id 5a478bee46e88-33e8bb7c1ffmr2536095eec.5.1790169742689; Wed, 23 Sep 2026 06:22:22 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 033/114] hw/riscv: expand boston-aia and microblaze-v-generic to TypeInfo Date: Wed, 23 Sep 2026 21:15:07 +0800 Message-ID: <20260923131635.1894-34-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790169745-A74D3AE4-2B8872A1/0/0 X-purgate-type: clean X-purgate-size: 1801 Replace DEFINE_MACHINE with TypeInfo on boston-aia and amd-microblaze-v-generic. Set is_available to target_is_base_riscv. Signed-off-by: Yonggang Luo --- hw/riscv/microblaze-v-generic.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/hw/riscv/microblaze-v-generic.c b/hw/riscv/microblaze-v-generic.c index 3f07ab21328..9b60a955152 100644 --- a/hw/riscv/microblaze-v-generic.c +++ b/hw/riscv/microblaze-v-generic.c @@ -14,6 +14,7 @@ */ #include "qemu/osdep.h" +#include "qemu/target-info.h" #include "qemu/units.h" #include "qemu/target-info.h" #include "qapi/error.h" @@ -177,8 +178,10 @@ static void mb_v_generic_init(MachineState *machine) create_unimplemented_device("qspi", QSPI_BASEADDR, 0x10000); } -static void mb_v_generic_machine_init(MachineClass *mc) +static void mb_v_generic_machine_class_init(ObjectClass *oc, const void *data) { + MachineClass *mc = MACHINE_CLASS(oc); + mc->desc = "AMD Microblaze-V generic platform"; mc->init = mb_v_generic_init; mc->min_cpus = 1; @@ -188,4 +191,16 @@ static void mb_v_generic_machine_init(MachineClass *mc) mc->default_cpus = 1; } -DEFINE_MACHINE("amd-microblaze-v-generic", mb_v_generic_machine_init) +static const TypeInfo mb_v_generic_machine_class_init_typeinfo = { + .name = MACHINE_TYPE_NAME("amd-microblaze-v-generic"), + .parent = TYPE_MACHINE, + .class_init = mb_v_generic_machine_class_init, + .is_available = target_is_base_riscv, +}; + +static void mb_v_generic_machine_class_init_register_types(void) +{ + type_register_static(&mb_v_generic_machine_class_init_typeinfo); +} + +type_init(mb_v_generic_machine_class_init_register_types) -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:22:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:22:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430603.1653142 (Exim 4.92) (envelope-from ) id 1x9Mvj-0006G3-Qt; Wed, 23 Sep 2026 13:22:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430603.1653142; Wed, 23 Sep 2026 13:22:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mvj-0006Fn-Nb; Wed, 23 Sep 2026 13:22:35 +0000 Received: by outflank-mailman (input) for mailman id 1430603; Wed, 23 Sep 2026 13:22:34 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mvi-0006EJ-LO for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:22:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mvi-00DrH3-2I for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:22:34 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d28f-e002-0a2a0a5209dd-0a2a4505a2ee-30 for ; Wed, 23 Sep 2026 15:22:34 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d298-4cb1-0a2a45050019-4a7de50caa0f-3 for ; Wed, 23 Sep 2026 15:22:33 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664dbe2dso384614eec.0 for ; Wed, 23 Sep 2026 06:22:33 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.22.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:22:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169752; x=1790774552; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=WqXX4SX3rjdHTToJvg98g4i7PWcyKUf7129uvkL7/uk=; b=OG1jBjD9sVku7qnF5bJxhgSNT4n6gMfDDZFARO90jfQ4fg151swdO1hhQ/Rkyh2v31 rafSx4CVP8JeHSPYFEY8YXr4L+LcQmTcdjZI3JpBUGG4H8FPlFouIHa9fx15rYEL9CtK smuFKj6/hEO9DnFy8m2l1V2LC8vW6pDye14poz/ak5PvpPkLSisI+szRGnnzFt1S8aMb g4nRyjmvw8UyHDLcFM1YQyF6/MPNQsCKn3sSj7k3JvkETmpc6UItO6X57Vik8NCAkz/7 s8NecRkZsqGlVIU7bg8KMIqEx8Uto3faF8J3INOcwgaAn34NCwxs3UCyFawPxw4hDvCZ xO3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169752; x=1790774552; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=WqXX4SX3rjdHTToJvg98g4i7PWcyKUf7129uvkL7/uk=; b=SfhFoHBiIelEYINvQR3LEWJzw3EGhD8Nh7VW9GXIogqvz/DOMxxVeYScDrt7nDuupw CPrIpSHebNpCEEiiIL80vibwBZlpUzerL9HoEiFgtXUIyHbjf1p8JUcHsgUdqJ41fcGo X7RE081yPvWcyvIIjjhGkX5YPfVTsqlsivXhio/GeUXbLhQIkFn4L29sSJS2JMEDmkPP CivYEdY4ItJ7DdJqYyhR9IgQFsPZ+xqy2p7g2oxLG7go1TyO7NEVldSOLTFmhRguRxeO /cI+XFPEI9wZd1g2y8EPNzLHOHdF59K4zWTm29g24WoSQkn0yiKoLfp8sz1YzW3x8/AW VnxA== X-Forwarded-Encrypted: i=1; AKwUvBzqgkPD1RWxZ8gmISB+ThdYSNsXN/6+1oGd204QvofgkrjikAMbdKmeBenPGPUwgdpx2yhFEOpOBuk=@lists.xenproject.org X-Gm-Message-State: AFuF++kB4rQ8ExTfoGAhAGe0wCxuq/TQAiePI28eoGdRcSQyogEk3IHV Kwx8+oWh5vUURS3LnKcV3G48Bkb4FPf3d0unqbUk5Sw6WBZUqE2meQIL X-Gm-Gg: AYBFou3Zq1njU0QgQX1LazgZ+fW8jqS56mZZ5sFV3e8iKQ4xVsYIuJZ//h1oEoblGz1 Nu70qWi7CMdoFc5fqiuXHUZv29Md2qffZn4e0YQqtQB58iBtGCX8FnRXjufSPJVnvMQtQNzo/aZ cPH+Be3aS5TNL6e3Ib8Z1SgdZdYlSicewCqibyBafOAbPwDwU9MBEGMCNhw+C6kqRWMjNtdrmeT CQYlq0J5DfhqFQPFTx1ObeS/kYMVhRrqwFjYhk0VW5DGSN7wlaLW0UAeu0QzftlXIK4k4fDmMpN a6ZhcexYT+l5brA/Z0PfVInhL/1wV8SrpULjwx11s9cr7atl3jByjF6o3RN08znMSGKMhJd6ocz R4gIgCYNDgEAieUP98KqxcEKeR74L3avl4aP+UaTPTPC7ggneGwtwu4cMvQa+CzUa7peSMzlsBP kGSHA9xX9uHuYv8bLr5jyiN1EGKzyyD08/EjYFpEGSTkD7Qs4th08Tsw/BWAYxMBvpTUy4yNYxT uY90+7necp6JIm5 X-Received: by 2002:a05:693c:8814:20b0:33e:5e42:e0f9 with SMTP id 5a478bee46e88-33e7a4d6cd5mr2603893eec.6.1790169751387; Wed, 23 Sep 2026 06:22:31 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 034/114] target/riscv: Include migration/vmstate.h instead of migration/cpu.h in machine.c Date: Wed, 23 Sep 2026 21:15:08 +0800 Message-ID: <20260923131635.1894-35-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790169754-F76BD2A1-97CE2D88/0/0 X-purgate-type: clean X-purgate-size: 673 already uses fixed-width VMSTATE_* macros and does not need TARGET_LONG_BITS UINTTL helpers. Signed-off-by: Yonggang Luo --- target/riscv/machine.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/riscv/machine.c b/target/riscv/machine.c index bf203bffcef..00805745fbf 100644 --- a/target/riscv/machine.c +++ b/target/riscv/machine.c @@ -21,7 +21,7 @@ #include "qemu/error-report.h" #include "system/kvm.h" #include "system/tcg.h" -#include "migration/cpu.h" +#include "migration/vmstate.h" #include "exec/icount.h" #include "target/riscv/tcg/debug.h" #ifdef CONFIG_KVM -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:22:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:22:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430614.1653151 (Exim 4.92) (envelope-from ) id 1x9Mvs-0006qn-7Z; Wed, 23 Sep 2026 13:22:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430614.1653151; Wed, 23 Sep 2026 13:22:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mvs-0006qe-4Q; Wed, 23 Sep 2026 13:22:44 +0000 Received: by outflank-mailman (input) for mailman id 1430614; Wed, 23 Sep 2026 13:22:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mvq-0006mf-P8 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:22:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mvq-00BQNW-6A for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:22:42 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d2a0-bab6-0a2a0a5309dd-0a2a4505baa4-4 for ; Wed, 23 Sep 2026 15:22:42 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d2a0-4cb1-0a2a45050019-4a7de52b89b6-3 for ; Wed, 23 Sep 2026 15:22:41 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-328664ef791so589003eec.3 for ; Wed, 23 Sep 2026 06:22:41 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.22.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:22:38 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169760; x=1790774560; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=sbxGSR1jQ3mjsiUMVexNy6mEJBAK/pzPmYIAHajWfls=; b=qocp88/wkP0t8BjAd7rbxnEA+U6ZzprwmqcPj3rLSA/PXGs/bJ5wUmHZA9PYYM3VDl o3JVALAbeH4ZgfcKmG7ZTlCPQEI3LYcygCXRce7h/JsJaAtRdXt5BP5KatIQk+c/Twrv S+4ULR4VXNNhh7z6DezMnREGG4extzhbKYe1K5hZpkz9q0BIsdlnSJ8Uqh7XefENfvnj OtpjVkQvYeTNFV2R15LS2RcODx6PgfL8oAa2SgB69FT4zOtassPvxTv/gW4arjeiMdjx DSGQWxDFbxJta7UJKQCNPWMI0mZXews93Bf90cFx8c3HUQUA3Lla3qCBfeZ86DXQt8yu e9FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169760; x=1790774560; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=sbxGSR1jQ3mjsiUMVexNy6mEJBAK/pzPmYIAHajWfls=; b=niSxSY06qFmM/n9rXbn4OqR457MZ14ACCA3RFf5bRK9hMQd1EoQEjnrj4hfh9qZ9SN 95OBFWCGOlBdNd0TBr5OpQ6cHofClXlG63olrxar9M/T16UuLk7CfxgZHz3WnycTlaiG f6VY2wNh0TAjQAqRhtbtE8NWKT3eSiQ5tFKSGysWxQOlJ7QHddvrS6eUH91Vkd1XbVeW VAxmJ+H9ASzhMRl0yONfM4jcTjwH+disZPmSnHGY7zb2g4KSfu7ySFaEF+fpxRCSWzIx DIhuyTM4trJeIYPi1WcJd5KLmV93BilNMsQ49zPj9+xcUfZSyYnP9z9iVl6piD19rvMc KHkA== X-Forwarded-Encrypted: i=1; AKwUvBwdM17/IGebw044Cod+xwG9nG6gTFOZSxzHmml2ImvBsTyTzDJs+bcP20oPLIUMw1AIsna5G33PzK8=@lists.xenproject.org X-Gm-Message-State: AFuF++kkOxz3HRb3LLJh/k+ITEPuCAlQB7uHfdZjAlOigE31u+u4dSea dPrhK4Pe/Zc5UnhpM7FU7QWuUkdhFTtw/eRTirTW2bWush95zvVCW9GR X-Gm-Gg: AYBFou0K9zUGMW25pX133COFT1Vmn6dwld2wyuwY8ix+D4gihgtry1GjaNBqDh4KE02 RjNaCEHd5YdyXHaUx6cSs37ntQS+jgmq80ct16IsFU9qXj14NZ/2mYPpcD0tA+GfUCHhHRQTfx9 tGktkzjhm9r0RB3AYei14hQqu488gzQjPsqEkW6M8SDOMLEN8pzUwBvGpADot+7otsPlS/nr8qQ auX7H5ecbZDpUGpa/KSW19c73A3IJ36RaQCAWU9LoqnU3wVjR9O6y2UlDqkdMKFWtYx5d2ZXkaz g34PSBYHtVWCA9roGaa1a5aMAtzlfyQrZ2W7u8Z+VrhllSbCON7MTUKOVhly1+N5SzeemDhtmu0 xJVEWyeFl42w+79QiQkNLjjeIOucBM+01NKilfjQPAzL0I/UkhNAcDq/7BE6zboJV9pyMH85YGk ZP+EoO6tw1P/U3+UM4PobehMPmXPai9T1OSTXWN+uHHy8dHyjvMaEWc0DMf81lcnt5wG7WRyidl kMoJTl4f5uGaK0+hz379aCCWuqMiwI= X-Received: by 2002:a05:7300:fb0a:b0:339:66ff:51b3 with SMTP id 5a478bee46e88-33e8e2b67b8mr2443005eec.37.1790169759593; Wed, 23 Sep 2026 06:22:39 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 035/114] target/riscv: gate CPU types with TargetInfo Date: Wed, 23 Sep 2026 21:15:09 +0800 Message-ID: <20260923131635.1894-36-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790169762-F7ABF2A1-CDA8A535/0/0 X-purgate-type: clean X-purgate-size: 14802 - Gate CPU types with TypeInfo.is_available instead of TARGET_RISCV32/64: DEFINE_RISCV_CPU_AVAIL, DEFINE_RISCV64_CPU, and DEFINE_RISCV_CPU_32_64SYS. - Add RISCVCPUDef.target_init. max and bare keep RV64/SV57 in the TypeInfo; on riscv32 the callbacks set RV32/SV32 after merge. Do not inherit the parent pointer. - Validate RV64/128 misa_mxl_max only when not target_riscv32(). Signed-off-by: Yonggang Luo --- target/riscv/cpu.c | 128 ++++++++++++++++++++++++++++++--------------- target/riscv/cpu.h | 7 +++ 2 files changed, 93 insertions(+), 42 deletions(-) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index c6f17390755..4343f431d62 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -1586,18 +1586,37 @@ static const MISAExtInfo misa_ext_info_arr[] = { MISA_EXT_INFO(RVB, "b", "Bit manipulation (Zba_Zbb_Zbs)") }; +static void riscv_max_target_init(RISCVCPUClass *mcc) +{ + if (!target_riscv32()) { + return; + } + mcc->def->misa_mxl_max = MXL_RV32; + mcc->def->cfg.max_satp_mode = VM_1_10_SV32; +} + +static void riscv_bare_target_init(RISCVCPUClass *mcc) +{ + if (!target_riscv32()) { + return; + } + /* BARE has no misa_mxl_max, so the class_base_init satp clamp skips it. */ + mcc->def->cfg.max_satp_mode = VM_1_10_SV32; +} + static void riscv_cpu_validate_misa_mxl(RISCVCPUClass *mcc) { CPUClass *cc = CPU_CLASS(mcc); /* Validate that MISA_MXL is set properly. */ switch (mcc->def->misa_mxl_max) { -#ifdef TARGET_RISCV64 case MXL_RV64: case MXL_RV128: + if (target_riscv32()) { + g_assert_not_reached(); + } cc->gdb_core_xml_file = "riscv-64bit-cpu.xml"; break; -#endif case MXL_RV32: cc->gdb_core_xml_file = "riscv-32bit-cpu.xml"; break; @@ -3092,6 +3111,8 @@ static void riscv_cpu_class_base_init(ObjectClass *c, const void *data) if (pcc->def) { mcc->def = g_memdup2(pcc->def, sizeof(*pcc->def)); + /* TypeInfo supplies target_init; do not inherit the parent pointer. */ + mcc->def->target_init = NULL; } else { mcc->def = g_new0(RISCVCPUDef, 1); } @@ -3152,6 +3173,9 @@ static void riscv_cpu_class_base_init(ObjectClass *c, const void *data) mcc->def->custom_csrs = def->custom_csrs; } #endif + if (def->target_init) { + def->target_init(mcc); + } } if (!object_class_is_abstract(c)) { @@ -3262,6 +3286,7 @@ void riscv_isa_write_fdt(RISCVCPU *cpu, void *fdt, char *nodename) .name = (type_name), \ .parent = (parent_type_name), \ .abstract = true, \ + .is_available = target_is_base_riscv, \ .class_data = &(const RISCVCPUDef) { \ .priv_spec = RISCV_PROFILE_ATTR_UNUSED, \ .vext_spec = RISCV_PROFILE_ATTR_UNUSED, \ @@ -3270,10 +3295,11 @@ void riscv_isa_write_fdt(RISCVCPU *cpu, void *fdt, char *nodename) }, \ } -#define DEFINE_RISCV_CPU(type_name, parent_type_name, ...) \ +#define DEFINE_RISCV_CPU_AVAIL(type_name, parent_type_name, avail, ...) \ { \ .name = (type_name), \ .parent = (parent_type_name), \ + .is_available = (avail), \ .class_data = &(const RISCVCPUDef) { \ .priv_spec = RISCV_PROFILE_ATTR_UNUSED, \ .vext_spec = RISCV_PROFILE_ATTR_UNUSED, \ @@ -3282,8 +3308,37 @@ void riscv_isa_write_fdt(RISCVCPU *cpu, void *fdt, char *nodename) }, \ } +#define DEFINE_RISCV_CPU(type_name, parent_type_name, ...) \ + DEFINE_RISCV_CPU_AVAIL(type_name, parent_type_name, \ + target_is_base_riscv, __VA_ARGS__) + +#define DEFINE_RISCV64_CPU(type_name, parent_type_name, ...) \ + DEFINE_RISCV_CPU_AVAIL(type_name, parent_type_name, \ + target_is_riscv64, __VA_ARGS__) + +/* + * Original: + * #if defined(TARGET_RISCV32) || \ + * (defined(TARGET_RISCV64) && !defined(CONFIG_USER_ONLY)) + * + * RV32 models on every riscv32 binary, and on system riscv64 + * (-cpu rv32 / e31 / ibex). Not linux-user riscv64. + */ +static bool riscv32_64sys_available(const TargetInfo *ti) +{ +#ifdef CONFIG_USER_ONLY + return target_is_riscv32(ti); +#else + return target_is_base_riscv(ti); +#endif +} + +#define DEFINE_RISCV_CPU_32_64SYS(type_name, parent_type_name, ...) \ + DEFINE_RISCV_CPU_AVAIL(type_name, parent_type_name, \ + riscv32_64sys_available, __VA_ARGS__) + #define DEFINE_PROFILE_CPU(type_name, parent_type_name, profile_) \ - DEFINE_RISCV_CPU(type_name, parent_type_name, \ + DEFINE_RISCV64_CPU(type_name, parent_type_name, \ .profile = &(profile_)) static void riscv_cpu_instance_finalize(Object *obj) @@ -3311,6 +3366,7 @@ static const TypeInfo riscv_cpu_type_infos[] = { .class_size = sizeof(RISCVCPUClass), .class_init = riscv_cpu_common_class_init, .class_base_init = riscv_cpu_class_base_init, + .is_available = target_is_base_riscv, }, DEFINE_ABSTRACT_RISCV_CPU(TYPE_RISCV_DYNAMIC_CPU, TYPE_RISCV_CPU, @@ -3339,21 +3395,14 @@ static const TypeInfo riscv_cpu_type_infos[] = { * only MBARE will be available if the user doesn't enable * a mode manually (see riscv_cpu_satp_mode_finalize()). */ -#ifdef TARGET_RISCV32 - .cfg.max_satp_mode = VM_1_10_SV32, -#else .cfg.max_satp_mode = VM_1_10_SV57, -#endif + .target_init = riscv_bare_target_init, ), DEFINE_RISCV_CPU(TYPE_RISCV_CPU_MAX, TYPE_RISCV_DYNAMIC_CPU, -#if defined(TARGET_RISCV32) - .misa_mxl_max = MXL_RV32, - .cfg.max_satp_mode = VM_1_10_SV32, -#elif defined(TARGET_RISCV64) .misa_mxl_max = MXL_RV64, .cfg.max_satp_mode = VM_1_10_SV57, -#endif + .target_init = riscv_max_target_init, ), DEFINE_ABSTRACT_RISCV_CPU(TYPE_RISCV_CPU_SIFIVE_E, TYPE_RISCV_VENDOR_CPU, @@ -3378,9 +3427,7 @@ static const TypeInfo riscv_cpu_type_infos[] = { .cfg.pmp_regions = 8 ), -#if defined(TARGET_RISCV32) || \ - (defined(TARGET_RISCV64) && !defined(CONFIG_USER_ONLY)) - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_BASE32, TYPE_RISCV_DYNAMIC_CPU, + DEFINE_RISCV_CPU_32_64SYS(TYPE_RISCV_CPU_BASE32, TYPE_RISCV_DYNAMIC_CPU, .cfg.max_satp_mode = VM_1_10_SV32, .misa_mxl_max = MXL_RV32, @@ -3406,7 +3453,7 @@ static const TypeInfo riscv_cpu_type_infos[] = { .cfg.ext_svvptc = true, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_IBEX, TYPE_RISCV_VENDOR_CPU, + DEFINE_RISCV_CPU_32_64SYS(TYPE_RISCV_CPU_IBEX, TYPE_RISCV_VENDOR_CPU, .misa_mxl_max = MXL_RV32, .misa_ext = RVI | RVM | RVC | RVU, .priv_spec = PRIV_VERSION_1_12_0, @@ -3423,37 +3470,35 @@ static const TypeInfo riscv_cpu_type_infos[] = { .cfg.ext_xlrbr = true ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_SIFIVE_E31, TYPE_RISCV_CPU_SIFIVE_E, + DEFINE_RISCV_CPU_32_64SYS(TYPE_RISCV_CPU_SIFIVE_E31, TYPE_RISCV_CPU_SIFIVE_E, .misa_mxl_max = MXL_RV32 ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_SIFIVE_E34, TYPE_RISCV_CPU_SIFIVE_E, + DEFINE_RISCV_CPU_32_64SYS(TYPE_RISCV_CPU_SIFIVE_E34, TYPE_RISCV_CPU_SIFIVE_E, .misa_mxl_max = MXL_RV32, .misa_ext = RVF, /* IMAFCU */ ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_SIFIVE_U34, TYPE_RISCV_CPU_SIFIVE_U, + DEFINE_RISCV_CPU_32_64SYS(TYPE_RISCV_CPU_SIFIVE_U34, TYPE_RISCV_CPU_SIFIVE_U, .misa_mxl_max = MXL_RV32, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_RV32I, TYPE_RISCV_BARE_CPU, + DEFINE_RISCV_CPU_32_64SYS(TYPE_RISCV_CPU_RV32I, TYPE_RISCV_BARE_CPU, .misa_mxl_max = MXL_RV32, .misa_ext = RVI ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_RV32E, TYPE_RISCV_BARE_CPU, + DEFINE_RISCV_CPU_32_64SYS(TYPE_RISCV_CPU_RV32E, TYPE_RISCV_BARE_CPU, .misa_mxl_max = MXL_RV32, .misa_ext = RVE ), -#endif -#if (defined(TARGET_RISCV64) && !defined(CONFIG_USER_ONLY)) - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_MAX32, TYPE_RISCV_DYNAMIC_CPU, +#ifndef CONFIG_USER_ONLY + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_MAX32, TYPE_RISCV_DYNAMIC_CPU, .cfg.max_satp_mode = VM_1_10_SV32, .misa_mxl_max = MXL_RV32, ), #endif -#if defined(TARGET_RISCV64) - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_BASE64, TYPE_RISCV_DYNAMIC_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_BASE64, TYPE_RISCV_DYNAMIC_CPU, .cfg.max_satp_mode = VM_1_10_SV57, .misa_mxl_max = MXL_RV64, @@ -3479,19 +3524,19 @@ static const TypeInfo riscv_cpu_type_infos[] = { .cfg.ext_svvptc = true, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_SIFIVE_E51, TYPE_RISCV_CPU_SIFIVE_E, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_SIFIVE_E51, TYPE_RISCV_CPU_SIFIVE_E, .misa_mxl_max = MXL_RV64 ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_SIFIVE_U54, TYPE_RISCV_CPU_SIFIVE_U, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_SIFIVE_U54, TYPE_RISCV_CPU_SIFIVE_U, .misa_mxl_max = MXL_RV64, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_SHAKTI_C, TYPE_RISCV_CPU_SIFIVE_U, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_SHAKTI_C, TYPE_RISCV_CPU_SIFIVE_U, .misa_mxl_max = MXL_RV64, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_THEAD_C906, TYPE_RISCV_VENDOR_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_THEAD_C906, TYPE_RISCV_VENDOR_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVG | RVC | RVS | RVU, .priv_spec = PRIV_VERSION_1_11_0, @@ -3519,7 +3564,7 @@ static const TypeInfo riscv_cpu_type_infos[] = { #endif ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_THEAD_C908, TYPE_RISCV_VENDOR_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_THEAD_C908, TYPE_RISCV_VENDOR_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU, .priv_spec = PRIV_VERSION_1_12_0, @@ -3566,12 +3611,12 @@ static const TypeInfo riscv_cpu_type_infos[] = { #endif ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_THEAD_C908V, TYPE_RISCV_CPU_THEAD_C908, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_THEAD_C908V, TYPE_RISCV_CPU_THEAD_C908, .misa_ext = RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU | RVV, .vext_spec = VEXT_VERSION_1_00_0, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_TT_ASCALON, TYPE_RISCV_VENDOR_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_TT_ASCALON, TYPE_RISCV_VENDOR_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVG | RVC | RVS | RVU | RVH | RVV, .priv_spec = PRIV_VERSION_1_13_0, @@ -3635,7 +3680,7 @@ static const TypeInfo riscv_cpu_type_infos[] = { .cfg.max_satp_mode = VM_1_10_SV57, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_VEYRON_V1, TYPE_RISCV_VENDOR_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_VEYRON_V1, TYPE_RISCV_VENDOR_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVG | RVC | RVS | RVU | RVH, .priv_spec = PRIV_VERSION_1_12_0, @@ -3671,7 +3716,7 @@ static const TypeInfo riscv_cpu_type_infos[] = { .cfg.max_satp_mode = VM_1_10_SV48, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_XIANGSHAN_NANHU, TYPE_RISCV_VENDOR_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_XIANGSHAN_NANHU, TYPE_RISCV_VENDOR_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVG | RVC | RVB | RVS | RVU, .priv_spec = PRIV_VERSION_1_12_0, @@ -3694,7 +3739,7 @@ static const TypeInfo riscv_cpu_type_infos[] = { .cfg.max_satp_mode = VM_1_10_SV39, ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_XIANGSHAN_KMH, TYPE_RISCV_VENDOR_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_XIANGSHAN_KMH, TYPE_RISCV_VENDOR_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVG | RVC | RVB | RVS | RVU | RVH | RVV, .priv_spec = PRIV_VERSION_1_13_0, @@ -3754,7 +3799,7 @@ static const TypeInfo riscv_cpu_type_infos[] = { ), /* https://mips.com/products/hardware/p8700/ */ - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_MIPS_P8700, TYPE_RISCV_VENDOR_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_MIPS_P8700, TYPE_RISCV_VENDOR_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU, .priv_spec = PRIV_VERSION_1_12_0, @@ -3777,16 +3822,16 @@ static const TypeInfo riscv_cpu_type_infos[] = { ), #if defined(CONFIG_TCG) && !defined(CONFIG_USER_ONLY) - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_BASE128, TYPE_RISCV_DYNAMIC_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_BASE128, TYPE_RISCV_DYNAMIC_CPU, .cfg.max_satp_mode = VM_1_10_SV57, .misa_mxl_max = MXL_RV128, ), #endif /* CONFIG_TCG */ - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_RV64I, TYPE_RISCV_BARE_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_RV64I, TYPE_RISCV_BARE_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVI ), - DEFINE_RISCV_CPU(TYPE_RISCV_CPU_RV64E, TYPE_RISCV_BARE_CPU, + DEFINE_RISCV64_CPU(TYPE_RISCV_CPU_RV64E, TYPE_RISCV_BARE_CPU, .misa_mxl_max = MXL_RV64, .misa_ext = RVE ), @@ -3795,7 +3840,6 @@ static const TypeInfo riscv_cpu_type_infos[] = { DEFINE_PROFILE_CPU(TYPE_RISCV_CPU_RVA22S64, TYPE_RISCV_CPU_RV64I, RVA22S64), DEFINE_PROFILE_CPU(TYPE_RISCV_CPU_RVA23U64, TYPE_RISCV_CPU_RV64I, RVA23U64), DEFINE_PROFILE_CPU(TYPE_RISCV_CPU_RVA23S64, TYPE_RISCV_CPU_RV64I, RVA23S64), -#endif /* TARGET_RISCV64 */ }; DEFINE_TYPES(riscv_cpu_type_infos) diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h index 034d7e96c49..265c6322067 100644 --- a/target/riscv/cpu.h +++ b/target/riscv/cpu.h @@ -597,6 +597,13 @@ typedef struct RISCVCPUDef { #endif /* This is just a setter for env->num_triggers. */ uint32_t num_triggers; + + /* + * Optional per-CPU callback run from riscv_cpu_class_base_init + * after the static def is merged. Use it to adjust fields that + * depend on the build target (e.g. clamp misa_mxl_max for RV32). + */ + void (*target_init)(struct RISCVCPUClass *mcc); } RISCVCPUDef; /** -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:22:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:22:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430620.1653161 (Exim 4.92) (envelope-from ) id 1x9Mw1-0007I3-H0; Wed, 23 Sep 2026 13:22:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430620.1653161; Wed, 23 Sep 2026 13:22:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mw1-0007Ht-DH; Wed, 23 Sep 2026 13:22:53 +0000 Received: by outflank-mailman (input) for mailman id 1430620; Wed, 23 Sep 2026 13:22:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mvz-0007Eh-KZ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:22:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mvz-007xKs-17 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:22:51 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d2a0-bab6-0a2a0a5309dd-0a2a4505baa4-36 for ; Wed, 23 Sep 2026 15:22:51 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d2a9-4cb1-0a2a45050019-4a7de50cb49c-3 for ; Wed, 23 Sep 2026 15:22:50 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-328664e050bso1176303eec.0 for ; Wed, 23 Sep 2026 06:22:50 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.22.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:22:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169769; x=1790774569; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=qFqvsxy7L8PH7M6DU9x+2jtR9XBAWYnvWHhVICE/SQI=; b=S8Ael6cPBLVfggLp0obVwsiHL19HFc5WAQsy9qj32jWbdJuefowzZIU+Syx9ycrEBD sVRZhwAGfAi9TH08TYLvdA/DaibKp0AJJYkcyih2j+mSNiu96WjuGgcRxdyIDn19veGU moxRl5IJjcrPH++01Mgq24a56JgLpSWaRhFcJbuUs8400+VlXJ++eVJr8QfQnGV24vFL riGcntDGpzvmZGObbuLSVoMDNnusTp1ueWFneNFqewLp1qjXnKdM/Hb9crov79T9TWu5 1qDG99odaOJP/GDfPjEK0/9ZSII8y5W3fkgoaM1FtyYSzD3xxI9LOupqDmM/fH9q0WIE 7dnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169769; x=1790774569; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=qFqvsxy7L8PH7M6DU9x+2jtR9XBAWYnvWHhVICE/SQI=; b=GjCbV0khZ23uf7T50hK82Ml4CvX27sQwSSJoZvLa1oUoHqlpMqggTki9zl+BwM9Tzl z8mcoK3WXNVzCqPd6uXqaqLdl1pRl5UcgD+q5IC8gJu3tpuLr7FaHVAdadThtuLWde2s 2M66Ng/Z/agvJEBJVS1g9PeVlj/n2toFJBid3aYFZdie3lJylK89dhWDt0OMHFBqVucR G1BRJCXcnxelHwpiljAv2NGwcNwpv+fXJ3wvOhLlgLRPF6hdYTRQTX3NPC4AOzdh9s6/ sAL7WlZ9WuKa212LUDoBw1YhDPvckRDHq1eAKp2JXauD4y+Oqg6vWBbseazHjtun6Ixy QoAA== X-Forwarded-Encrypted: i=1; AKwUvByJmSnL16ShUE0jfx4lmDk+5QdrRhDaDJQGpvpQqnfRjI3mArmn4WRibTRKNZufiutifcuXqF3BBT0=@lists.xenproject.org X-Gm-Message-State: AFuF++kD3qUBE8YPosfm3IniWE2gjgCdWydA5eAIiLEFNfTO+Fm59TMi IPMF9u3lPx6xGEOsan+7Pb2LkA6BeteJwA3auGIZAVZI98PtcUUDS6R8 X-Gm-Gg: AYBFou1V8BHtlrJBuW6fC7uCPD2tZcfxIBfrD0Lz4SY7DTRjNqXIwzIf5mQcCAqnsgw zTHnb45El8rIzFfwvistpd4ArHlQ+uAX/QtNBf/n8qhfGxW7wYD7F4PKp2ddW6Sv7F84srxEOiN dlwSgUI6xLtCb0+QdRV5UBKCzoThDXqlEepKmFtb6R+V2co82frMXD//BvOUzlOsviG1KiMOzfo YL+S5aYaoXrH4kaKey++Pp5gJYXZQ30GcpchKPrZTGFvr+KOhIaW+JP/IgkpofzBKCx1G7QhkcO fUjG0sUN5dR4AhlmqpLuk5lTGnhgqPbGWB8H0xL5+0HT56vxw5WXTY5TZGcT7bXXw8/+7+IBHLL D3SC8iFrWc8GrZJ5SzFc3xLrF7w6ciclQCx6fx1oJtCNtCaNQYoDUqhRMhTVt18R65sQJEl1FaR F54Umd2p3HGJuslxKj6IOARzDWIvQPe/+J6uIUVcNpM8/VSWBs/h5oAE0xMUbm+JoGL/9ZD9cDM cuvlRY0wAOc19cPTy3A+TsBiRvWF34= X-Received: by 2002:a05:7300:59a1:b0:33b:e842:d272 with SMTP id 5a478bee46e88-33e8be6c06bmr2642017eec.5.1790169767812; Wed, 23 Sep 2026 06:22:47 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 036/114] target/riscv: select ELF dump class from target_riscv64 Date: Wed, 23 Sep 2026 21:15:10 +0800 Message-ID: <20260923131635.1894-37-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c201ff/1790169771-F5EA92A1-8F223EC7/0/0 X-purgate-type: clean X-purgate-size: 921 - Replace TARGET_RISCV64 with target_riscv64() so dump class still follows the QEMU target, not guest MXL. Signed-off-by: Yonggang Luo --- target/riscv/arch_dump.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/target/riscv/arch_dump.c b/target/riscv/arch_dump.c index 12b68799070..2704bd8d94e 100644 --- a/target/riscv/arch_dump.c +++ b/target/riscv/arch_dump.c @@ -175,11 +175,11 @@ int cpu_get_dump_info(ArchDumpInfo *info, info->d_machine = EM_RISCV; -#if defined(TARGET_RISCV64) - info->d_class = ELFCLASS64; -#else - info->d_class = ELFCLASS32; -#endif + if (target_riscv64()) { + info->d_class = ELFCLASS64; + } else { + info->d_class = ELFCLASS32; + } info->d_endian = (env->mstatus & MSTATUS_UBE) != 0 ? ELFDATA2MSB : ELFDATA2LSB; -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:23:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:23:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430625.1653169 (Exim 4.92) (envelope-from ) id 1x9Mw9-0007mF-NR; Wed, 23 Sep 2026 13:23:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430625.1653169; Wed, 23 Sep 2026 13:23:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mw9-0007m8-Kk; Wed, 23 Sep 2026 13:23:01 +0000 Received: by outflank-mailman (input) for mailman id 1430625; Wed, 23 Sep 2026 13:23:00 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mw8-0007hn-8O for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:23:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Mw7-00DJz9-L6 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:22:59 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d2b1-8faa-0a2a0a5109dd-0a2a450b86fc-4 for ; Wed, 23 Sep 2026 15:22:59 +0200 Received: from [74.125.229.12] (helo=mail-dy2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d2b2-b7e8-0a2a450b0019-4a7de50ce98a-3 for ; Wed, 23 Sep 2026 15:22:59 +0200 Received: by mail-dy2-f12.google.com with SMTP id 5a478bee46e88-3396cec93b6so976984eec.3 for ; Wed, 23 Sep 2026 06:22:59 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.22.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:22:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169777; x=1790774577; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=P+y3C9rGVvFAkdWFKio2TWsWiPkrJ96pOnUImryyekQ=; b=ocwNad0xCGJxMSosr7YSjU+lTYgQBFGZFtG1cnGhij7sQscqnVRDxraY1I9mSgR2VU 28DaIpoETDuM8IuWrAbaW0rkIA1VzFy1wv4jQjYqO/FBMezCImjxWqat24f+ijG0uvr1 4wOODAwPtRcW4/aDjnoWB+La8mlD8J49k+yX0odSiz2nZIWouiLcxXnO+bmJR81K/RSE rUoe41E1Qvd39Z7df5CHmm2pdqmFPuTdA0h4Mp02fpsVojDjweDc4Rtvoq4kXpGLz+TG 23kMt6PrPIIHgfkK0xeYnRdSb/wC01TY/Yaaw4B92kgjv1auQdefDNVNN5fT12W0gAqi RtaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169777; x=1790774577; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=P+y3C9rGVvFAkdWFKio2TWsWiPkrJ96pOnUImryyekQ=; b=DRg53v72zlAtwEpKP6KrpEUseEiuyMlHkLQDEcGIDpppe8Td23dh0xdErKNeSjH+QO cmr0t1WY2vsFCINgxlggNyfv8a4uc1iL/D79tAd0+jos4KN9ytEExJra0VNyB+cKjPCu f67MGLfLAgGilJE9rjhTqJ4Y2tbKw+zyZ0Hl0p1i689pgweBjGprGqcT+DG66QZUA3Gg Nkz2EmgVeOE4DhVqQg43x2k+Mx5HzD8EXvQI/AI2WnMID4/nkeg6Wrqc293oR/1sQxJv K3+feRy6+hhKZnCl1JnaL7HM5blTx5e/jJaac2Mudidsk8YSEwCGvsnG+LbznAY+/P8i PELQ== X-Forwarded-Encrypted: i=1; AKwUvBxHehEnqkLPO9bsiOy5oavXpUYdAoJGFu+SOwdWxSNJjKmgZLm3f6/WU5K4MTjfOQ49yp8CMTVuFK4=@lists.xenproject.org X-Gm-Message-State: AFuF++ltKj/4Nt0AUqRQwFBCKXNH4r2USJDGttcx7hP9Oj5TJ6i4xLRY mox9yuiF3/gXpsuNVxwVzzrM3OcwvPK4cdvkdZlqUn3wqlVK+qqnOGJyNEmtgoO1MqA= X-Gm-Gg: AYBFou2hFaMSYkN0fyqfndpAJkRfc7oWQF6g+bHBvroBkyApDwW6HyanXmQ0UPt84nB inqHVxN95jxmZ1LicoRvmbaLboRA/HSxUIdX6+OXeWBQIdtXcGkxFKwyifePNbgZUfr2udIV3sT pptDoxOqyeIirufrTTYuxfXps/07l9oz0txNP/WRlMYxpYQiTW+WmqLgwxDaWYQypzsdyJTvwFG VeUD/TOc06FA0AcKUCDau63JRyvfH5lAZGFnPvJ378gRUlCNSuYJSmJcz1+7WocVDdiV0Yo/jCm YIk2l1ReA1jEKNwTCBfgqFrQJT48mq7n1++1ZWIuci9RXEgBGwgWDjlGqH8YcYsd5Ird4cG7td1 eiM34pZv9iVz5LNBX03bWwow4h8mqkBkkKP+Xvz5sYYR6LEeUbKCwiwWy0e9jTBGlAFByjJl0mW 0r1CLfCcG/ES+rfyR2Cf5/XjZNywqxIYVM00y6m/r9x1i/2shgpZE97QfmouEh+VkCNm88L316l G0NWUaLFoBfaKi2VhN+MOCWvD6Mn/o= X-Received: by 2002:a05:7300:311a:b0:339:7357:b225 with SMTP id 5a478bee46e88-33e905f47cbmr2532490eec.16.1790169776667; Wed, 23 Sep 2026 06:22:56 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 037/114] target/riscv: replace TARGET_* macros in CSR helpers Date: Wed, 23 Sep 2026 21:15:11 +0800 Message-ID: <20260923131635.1894-38-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790169779-A98C19EA-38E6D484/0/0 X-purgate-type: clean X-purgate-size: 2434 - Use target_long_bits() instead of TARGET_LONG_BITS for the CSR write mask. - Use target_riscv64() instead of TARGET_RISCV64 for MISA RV64 and the PMP address mask. Signed-off-by: Yonggang Luo --- target/riscv/tcg/csr.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/target/riscv/tcg/csr.c b/target/riscv/tcg/csr.c index 061bc9db77b..0b96fff6b96 100644 --- a/target/riscv/tcg/csr.c +++ b/target/riscv/tcg/csr.c @@ -18,6 +18,7 @@ */ #include "qemu/osdep.h" +#include "qemu/target-info.h" #include "qemu/log.h" #include "qemu/timer.h" #include "cpu.h" @@ -2143,17 +2144,18 @@ static RISCVException read_misa_i128(CPURISCVState *env, int csrno, static RISCVException read_misa(CPURISCVState *env, int csrno, target_ulong *val) { - target_ulong misa; + uint64_t misa; switch (env->misa_mxl) { case MXL_RV32: - misa = (target_ulong)MXL_RV32 << 30; + misa = (uint64_t)MXL_RV32 << 30; break; -#ifdef TARGET_RISCV64 case MXL_RV64: - misa = (target_ulong)MXL_RV64 << 62; + if (!target_riscv64()) { + g_assert_not_reached(); + } + misa = (uint64_t)MXL_RV64 << 62; break; -#endif default: g_assert_not_reached(); } @@ -5430,13 +5432,11 @@ static RISCVException read_pmpaddr(CPURISCVState *env, int csrno, * here to avoid complaints about masking bits 0-53 * of a potential 32 bit target_ulong '*var'. */ -#ifdef TARGET_RISCV64 - if (env->misa_mxl == MXL_RV64 + if (target_riscv64() && env->misa_mxl == MXL_RV64 && csrno >= CSR_PMPADDR0 && csrno <= CSR_PMPADDR63) { - target_ulong read_mask = MAKE_64BIT_MASK(0, 54); + uint64_t read_mask = MAKE_64BIT_MASK(0, 54); *val &= read_mask; } -#endif return RISCV_EXCP_NONE; } @@ -5755,7 +5755,7 @@ RISCVException riscv_csrrw(CPURISCVState *env, int csrno, RISCVException riscv_csr_write_i64(CPURISCVState *env, int csrno, uint64_t val) { return riscv_csrrw(env, csrno, NULL, val, - MAKE_64BIT_MASK(0, TARGET_LONG_BITS), 0); + MAKE_64BIT_MASK(0, target_long_bits()), 0); } RISCVException riscv_csr_read_i64(CPURISCVState *env, int csrno, uint64_t *res) -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:23:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:23:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430636.1653179 (Exim 4.92) (envelope-from ) id 1x9MwI-0008IE-4K; Wed, 23 Sep 2026 13:23:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430636.1653179; Wed, 23 Sep 2026 13:23:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MwI-0008I7-0Z; Wed, 23 Sep 2026 13:23:10 +0000 Received: by outflank-mailman (input) for mailman id 1430636; Wed, 23 Sep 2026 13:23:09 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MwH-0008H9-F7 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:23:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MwG-00DrQ8-S3 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:23:08 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d2ba-bab6-0a2a0a5309dd-0a2a450a888e-6 for ; Wed, 23 Sep 2026 15:23:08 +0200 Received: from [74.125.229.167] (helo=mail-dl2-f39.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d2bb-f2d2-0a2a450a0019-4a7de5a78032-3 for ; Wed, 23 Sep 2026 15:23:08 +0200 Received: by mail-dl2-f39.google.com with SMTP id a92af1059eb24-1438cb9b3a3so944124c88.2 for ; Wed, 23 Sep 2026 06:23:08 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.22.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:23:04 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169786; x=1790774586; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=B9wmWDAGxCIEbiXb+JeTWZOg+WBaBPZDk+tkeJy0Fzg=; b=tD5Rchr/mzov+PXj/5Zm6oEa0yFtnPqS41tcwOWO8W1bZOIbic4DgfivDKOE5csVeN e54jEvRplXbhEK4/NndcwDEeoOBh3NIIGTHVbszfn8nJ4RbacbT0Ph+TjZEdYdMndOJU 1Bck3pHQBAPllThBhXX7S1jnqyhxXEPh9Gu7TIjJDwHi/CCfxhrwtqyIlqwBcbN6mdVq 6i9+2zOK+6sFNUc1ZRr7yzHyDsSnFqw3ScqSgNjIKGBoY51KpIX9IX5Y7m3kuC0+vSaA hbdTPrNziEpKQK6I9Mjb6f+sOUQkgbtmbbUDARN2bdmgLHzXJ33jrCt4aHYkkzMtEQeY zaOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169787; x=1790774587; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=B9wmWDAGxCIEbiXb+JeTWZOg+WBaBPZDk+tkeJy0Fzg=; b=YAS/m+L/PlFfLdCNLx1xIdQzAwDd+qgujIB00ho44QJF124dIPyL0gUzXwwqvg9jYc onYVu9XgKdb4RRRkfR8n8lG2pjIc43rFmGJSr4I0lPm+iyDqRFL2RqsAxKyUu+30SmDa egrYsyhWUw/oDvPcS3cUYGmZHrHxdMtnkF0oQ7S+rJAIiSLa2hXsy7NIpuPHd3dyRkE7 3WRcLCjsiA61aNf1W3ZgdHev8aDCK2lCrsvrU/vqGVAXeOpu19HOsHO/p3zlR8hHkKQZ 9thVS/b/x79g/HvcvVIOK13QVSJ70bZJZ4KZUB4xm1moUrh+nm5+agQ6F4Q9yN/hKGNy oJeg== X-Forwarded-Encrypted: i=1; AKwUvByj8F3+E1bw7mfE4HfhQ4WJ6mYHurQijjBQil+nWNDenLK3r6+Iofehn9CPjQXp1rRz+xfy2xsdGx4=@lists.xenproject.org X-Gm-Message-State: AFuF++kLSdOp1TEN+Pma/sg2caQtCqIKNiwEabn0T3zOnViGgyNUEPjf s1SBLgsiSz14CxJ5cIAey0Z730lMyjiYWmaGsY5dZY72suOmMzy+XuJq X-Gm-Gg: AYBFou2dvF29uYQ8zMJ5/2IbgPdodZVbzGJdr7dmJPM7tro6IL3Afm3cOQfSn3XgLDb BLSedxi13RzGhTAJUbLkyZXXBOR4R5cXtORHjbYX63YDkJbLZr4RYjJzV4rQV69LprEeMYIK7ax TMQsvHNvBFqJZASTfQPIv0wykAIYbsf2kSV0Ucdgtewa3ruNje4OIdV2AkgFGMqwrcvYtCgB1d8 99uk4ot+3rIXQxPwCbEiFdiPovetDzsK7w42UlRqkV8oaFBtM+3xI1BDevM+amzMjXp6U5nLfRe njsoNDrxafZQ/xAse285TSB1AoFrWt/xPALY3qBbQf0vJ+2zWZox5e87bevFbWvNNzBFJpA/C/j Qv3sRUBXneuFW/Mv8rhVFfqnsIKO1nDHRmiBsalP7GdA2eH0N2jhIXmPoTI+6Eaen4RfvIHD0bJ 5W+Dd85aZNIG1blGpqBA+NZa4wMA1G9EBGUBpGqF72JYTH9VKHxEI0z/yPHXL1grl6bcmCCKnq9 WvVcdC8AcT9JSqlCJb649Qe2ACWfiCGeOH1wFz+hw== X-Received: by 2002:a05:693c:88c6:10b0:33c:e93:764b with SMTP id 5a478bee46e88-33e8e3add75mr2436826eec.37.1790169785754; Wed, 23 Sep 2026 06:23:05 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 038/114] target/riscv: use target_long_bits in pmpaddr granule checks Date: Wed, 23 Sep 2026 21:15:12 +0800 Message-ID: <20260923131635.1894-39-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-4011c0/1790169788-502F0CFC-DADF620E/0/0 X-purgate-type: clean X-purgate-size: 1349 - Replace TARGET_LONG_BITS with target_long_bits() for TOR/NAPOT PMP address masking. Signed-off-by: Yonggang Luo --- target/riscv/tcg/pmp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/target/riscv/tcg/pmp.c b/target/riscv/tcg/pmp.c index 41b55519a8e..03ee7c74300 100644 --- a/target/riscv/tcg/pmp.c +++ b/target/riscv/tcg/pmp.c @@ -23,6 +23,7 @@ #include "qemu/log.h" #include "qapi/error.h" #include "cpu.h" +#include "qemu/target-info.h" #include "target/riscv/tcg/csr.h" #include "trace.h" #include "exec/cputlb.h" @@ -643,14 +644,14 @@ target_ulong pmpaddr_csr_read(CPURISCVState *env, uint32_t addr_index) /* fallthrough */ case PMP_AMATCH_TOR: /* Bit [g-1:0] read all zero */ - if (g >= 1 && g < TARGET_LONG_BITS) { + if (g >= 1 && g < target_long_bits()) { uint64_t granule = 1ULL << g; val = ROUND_DOWN(val, granule); } break; case PMP_AMATCH_NAPOT: /* Bit [g-2:0] read all one */ - if (g >= 2 && g < TARGET_LONG_BITS) { + if (g >= 2 && g < target_long_bits()) { val = deposit64(val, 0, g - 1, -1ULL); } break; -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:23:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:23:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430642.1653188 (Exim 4.92) (envelope-from ) id 1x9MwR-0000MJ-E4; Wed, 23 Sep 2026 13:23:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430642.1653188; Wed, 23 Sep 2026 13:23:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MwR-0000MC-AC; Wed, 23 Sep 2026 13:23:19 +0000 Received: by outflank-mailman (input) for mailman id 1430642; Wed, 23 Sep 2026 13:23:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MwQ-0000Hf-3g for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:23:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MwP-002FUs-Gn for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:23:17 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d2c0-8faa-0a2a0a5109dd-0a2a4508ae7e-20 for ; Wed, 23 Sep 2026 15:23:17 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d2c3-f659-0a2a45080019-4a7de52b95ae-3 for ; Wed, 23 Sep 2026 15:23:17 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-33c11ef641aso1115411eec.1 for ; Wed, 23 Sep 2026 06:23:16 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.23.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:23:13 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169795; x=1790774595; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=a+vM4VKx04YtiIcob+lp3bwuPAlEC1anahMCoo6i89k=; b=sTckSw/dZQ1lXiVr2dSEMxA996F9bLp4qfxV7vH1CzSshwgb6gOxUa0lvmGtOvNy2L /+OL3w4DCrl8PtG95l7deEsHVBMa1r8v1Qx/3K+8RSwERsHfThLkAN9XCQvz/WeHwTWA 6eLVLxfNuGm8TfB/O9Bc1qkHuXJ6tOu//MX/HFIBkFVE8mC78j4aKwqOmT8OZ2RGziX9 h5zsnciQVHn68G12CSvXES+mifr7LlFoRnYdXFpOC13+gCysexSRo0jONIeDe6skSQBT CmTsSGBdpKdyT/7ze5JRZILRaD6T6uX/Cc2G6sd97ZmMoCIHUyV7xqbBWgvOP38Ll1bm +mrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169795; x=1790774595; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=a+vM4VKx04YtiIcob+lp3bwuPAlEC1anahMCoo6i89k=; b=ai2/sFoPGUgE7gVh3/iv0zAjHKqJnPdCsYkfdQ4LscRbgehjPb1EfbWeQ/Mhi53VvH 95iw5Lyl1x1c9zN9eAvNKGps8nW9gPAjcwt09NgHGMtGgdi3lF8qPCOG/zEENTHvDXe6 HsgY3inenV6Xdw5F2eW6OaBVgxuKHX9n1MfHZ+0sHudC5gr8vij5UPQzAB0jqXq0F3cs +XqqZ4oHZH7AKIBBxZD6iTdpn+rI92GxHbxrsziBIYJjBKRCkGag2J2yrnSx59thBOy4 yscgPiU3RO7DalGuF1uyvDw7hxKYz7EP2/ivvKaccHb9ZnaLgQsNrUCrk/n1+f94tBBB jVfA== X-Forwarded-Encrypted: i=1; AKwUvByC5VHdoewb4mFpnq1VvPl5Zc8g7ODlNKfhKt0vyCvS80YDFzGreEo08kCdvJI6FivEml3TXsC6UxA=@lists.xenproject.org X-Gm-Message-State: AFuF++lom7JTx9l/rbERn+CP4Eev6vQmRVAC6BhHxbRGD512No5QyM0B Cp2QSTweclvYxewtyYTXCCvTYOB8wVuOSPUFQ8JAl09dFBDIQrRUQG4j X-Gm-Gg: AYBFou3myRy84VwgQwAp6WZPg5o/aIyhnAiTVKxRuEklCnqoq+MKPfdQm3LF5HqGStk kCuCrzLwicsI1MpsnEUTIQby3o8stoLD34RClFhTR/cEJSv6y4qRoEo87VWZ2XHGsLMQiVgpmfs sGX30EAWkoxO4VoIbqk0VHcpG1CSp+MChL0UYq9NXG44woGvzaZKhI2CIcn3/VHUfksX2D8Okbs obM9+MsjBR3E1rWUUXxOFBN1POrCiEUGPlPmgLnW7EYs6TL3/UI9sfW5sAl+nyMk8zVYeyfhKWW ekdWPICMvQhFIc4G7FHqN3Rna2etTwDkVPN9AGF0KICBTgjTMTrEJ/Rf0mRpwNyBWRIOylNH5x1 pgtaNzUUiXIHd2wy5Y4sx88hsp9XCaduQJ0HInusPA0d72wkel/qm4lgzjlzzoZshvXS9WNX5mI kBHCaALQMFgL97V4WRVW3B41Vs1896h+FW64f9zuWScuSAiCbZU1gghLsNPUwn5zUwqDnVULPcp bm8VVdBoUCeP5FoTIBkP62z5iRkfU/NIotKrM9FjQ== X-Received: by 2002:a05:7300:3e91:b0:327:affc:b506 with SMTP id 5a478bee46e88-33e8c72c478mr2326450eec.15.1790169794702; Wed, 23 Sep 2026 06:23:14 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 039/114] target/riscv: preserve signed XLEN semantics without target_long Date: Wed, 23 Sep 2026 21:15:13 +0800 Message-ID: <20260923131635.1894-40-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790169797-CF75B87B-BA62A746/0/0 X-purgate-type: clean X-purgate-size: 9659 - Mask pointer-masked addresses with extract64/sextract64 at runtime XLEN instead of a target_long arithmetic shift. - Pass vector vx scalars as int64_t after sextract64 from the helper tl slot so RV32 keeps bit 31 as the sign bit. - Leave every target_ulong helper argument unchanged. Signed-off-by: Yonggang Luo --- target/riscv/internals.h | 12 ++++++++---- target/riscv/tcg/vector_helper.c | 21 +++++++++++---------- target/riscv/tcg/vector_internals.c | 2 +- target/riscv/tcg/vector_internals.h | 9 +++++---- 4 files changed, 25 insertions(+), 19 deletions(-) diff --git a/target/riscv/internals.h b/target/riscv/internals.h index 1ee7e99e988..0844867246d 100644 --- a/target/riscv/internals.h +++ b/target/riscv/internals.h @@ -214,6 +214,7 @@ static inline target_ulong adjust_addr_body(CPURISCVState *env, { RISCVPmPmm pmm = PMM_FIELD_DISABLED; uint32_t pmlen = 0; + unsigned kept; bool signext = false; /* do nothing for rv32 mode */ @@ -235,13 +236,16 @@ static inline target_ulong adjust_addr_body(CPURISCVState *env, signext = riscv_cpu_virt_mem_enabled(env, is_virt_addr); pmlen = riscv_pm_get_pmlen(pmm); - addr = addr << pmlen; - /* sign/zero extend masked address by N-1 bit */ + /* + * Drop the top pmlen bits of XLEN. Do not rely on target_ulong + * shift wrap; common-system target_ulong is always 64 bits. + */ + kept = target_long_bits() - pmlen; if (signext) { - addr = (target_long)addr >> pmlen; + addr = sextract64(addr, 0, kept); } else { - addr = addr >> pmlen; + addr = extract64(addr, 0, kept); } return addr; diff --git a/target/riscv/tcg/vector_helper.c b/target/riscv/tcg/vector_helper.c index 0d1e4e09646..0b78a733ce4 100644 --- a/target/riscv/tcg/vector_helper.c +++ b/target/riscv/tcg/vector_helper.c @@ -1248,7 +1248,7 @@ void HELPER(NAME)(void *vd, void *v0, target_ulong s1, void *vs2, \ ETYPE s2 = *((ETYPE *)vs2 + H(i)); \ ETYPE carry = vext_elem_mask(v0, i); \ \ - *((ETYPE *)vd + H(i)) = DO_OP(s2, (ETYPE)(target_long)s1, carry);\ + *((ETYPE *)vd + H(i)) = DO_OP(s2, (ETYPE)sextract64(s1, 0, target_long_bits()), carry);\ } \ env->vstart = 0; \ /* set tail elements to 1s */ \ @@ -1325,7 +1325,7 @@ void HELPER(NAME)(void *vd, void *v0, target_ulong s1, \ ETYPE s2 = *((ETYPE *)vs2 + H(i)); \ ETYPE carry = !vm && vext_elem_mask(v0, i); \ vext_set_elem_mask(vd, i, \ - DO_OP(s2, (ETYPE)(target_long)s1, carry)); \ + DO_OP(s2, (ETYPE)sextract64(s1, 0, target_long_bits()), carry)); \ } \ env->vstart = 0; \ /* @@ -1609,7 +1609,7 @@ void HELPER(NAME)(void *vd, void *v0, target_ulong s1, void *vs2, \ continue; \ } \ vext_set_elem_mask(vd, i, \ - DO_OP(s2, (ETYPE)(target_long)s1)); \ + DO_OP(s2, (ETYPE)sextract64(s1, 0, target_long_bits()))); \ } \ env->vstart = 0; \ /* @@ -2050,7 +2050,7 @@ GEN_VEXT_VV(vnmsub_vv_w, 4) GEN_VEXT_VV(vnmsub_vv_d, 8) #define OPIVX3(NAME, TD, T1, T2, TX1, TX2, HD, HS2, OP) \ -static void do_##NAME(void *vd, target_long s1, void *vs2, int i) \ +static void do_##NAME(void *vd, int64_t s1, void *vs2, int i) \ { \ TX2 s2 = *((T2 *)vs2 + HS2(i)); \ TD d = *((TD *)vd + HD(i)); \ @@ -2246,7 +2246,7 @@ void HELPER(NAME)(void *vd, void *v0, target_ulong s1, \ for (i = env->vstart; i < vl; i++) { \ ETYPE s2 = *((ETYPE *)vs2 + H(i)); \ ETYPE d = (!vext_elem_mask(v0, i) ? s2 : \ - (ETYPE)(target_long)s1); \ + (ETYPE)sextract64(s1, 0, target_long_bits())); \ *((ETYPE *)vd + H(i)) = d; \ } \ env->vstart = 0; \ @@ -2397,12 +2397,12 @@ GEN_VEXT_VV_RM(vsaddu_vv_h, 2) GEN_VEXT_VV_RM(vsaddu_vv_w, 4) GEN_VEXT_VV_RM(vsaddu_vv_d, 8) -typedef void opivx2_rm_fn(void *vd, target_long s1, void *vs2, int i, +typedef void opivx2_rm_fn(void *vd, int64_t s1, void *vs2, int i, CPURISCVState *env, uint8_t vxrm); #define OPIVX2_RM(NAME, TD, T1, T2, TX1, TX2, HD, HS2, OP) \ static inline void \ -do_##NAME(void *vd, target_long s1, void *vs2, int i, \ +do_##NAME(void *vd, int64_t s1, void *vs2, int i, \ CPURISCVState *env, uint8_t vxrm) \ { \ TX2 s2 = *((T2 *)vs2 + HS2(i)); \ @@ -2410,7 +2410,7 @@ do_##NAME(void *vd, target_long s1, void *vs2, int i, \ } static inline void -vext_vx_rm_1(void *vd, void *v0, target_long s1, void *vs2, +vext_vx_rm_1(void *vd, void *v0, int64_t s1, void *vs2, CPURISCVState *env, uint32_t vl, uint32_t vm, uint8_t vxrm, opivx2_rm_fn *fn, uint32_t vma, uint32_t esz) @@ -2427,7 +2427,7 @@ vext_vx_rm_1(void *vd, void *v0, target_long s1, void *vs2, } static inline void -vext_vx_rm_2(void *vd, void *v0, target_long s1, void *vs2, +vext_vx_rm_2(void *vd, void *v0, int64_t s1, void *vs2, CPURISCVState *env, uint32_t desc, opivx2_rm_fn *fn, uint32_t esz) @@ -2468,7 +2468,8 @@ void HELPER(NAME)(void *vd, void *v0, target_ulong s1, \ void *vs2, CPURISCVState *env, \ uint32_t desc) \ { \ - vext_vx_rm_2(vd, v0, s1, vs2, env, desc, \ + vext_vx_rm_2(vd, v0, sextract64(s1, 0, target_long_bits()), \ + vs2, env, desc, \ do_##NAME, ESZ); \ } diff --git a/target/riscv/tcg/vector_internals.c b/target/riscv/tcg/vector_internals.c index b490b1d3989..95327052666 100644 --- a/target/riscv/tcg/vector_internals.c +++ b/target/riscv/tcg/vector_internals.c @@ -81,7 +81,7 @@ void do_vext_vv(void *vd, void *v0, void *vs1, void *vs2, vext_set_elems_1s(vd, vta, vl * esz, total_elems * esz); } -void do_vext_vx(void *vd, void *v0, target_long s1, void *vs2, +void do_vext_vx(void *vd, void *v0, int64_t s1, void *vs2, CPURISCVState *env, uint32_t desc, opivx2_fn fn, uint32_t esz) { diff --git a/target/riscv/tcg/vector_internals.h b/target/riscv/tcg/vector_internals.h index 5681b818153..da093d561eb 100644 --- a/target/riscv/tcg/vector_internals.h +++ b/target/riscv/tcg/vector_internals.h @@ -201,20 +201,20 @@ void HELPER(NAME)(void *vd, void *v0, void *vs1, \ do_##NAME, ESZ); \ } -typedef void opivx2_fn(void *vd, target_long s1, void *vs2, int i); +typedef void opivx2_fn(void *vd, int64_t s1, void *vs2, int i); /* * (T1)s1 gives the real operator type. * (TX1)(T1)s1 expands the operator type of widen or narrow operations. */ #define OPIVX2(NAME, TD, T1, T2, TX1, TX2, HD, HS2, OP) \ -static void do_##NAME(void *vd, target_long s1, void *vs2, int i) \ +static void do_##NAME(void *vd, int64_t s1, void *vs2, int i) \ { \ TX2 s2 = *((T2 *)vs2 + HS2(i)); \ *((TD *)vd + HD(i)) = OP(s2, (TX1)(T1)s1); \ } -void do_vext_vx(void *vd, void *v0, target_long s1, void *vs2, +void do_vext_vx(void *vd, void *v0, int64_t s1, void *vs2, CPURISCVState *env, uint32_t desc, opivx2_fn fn, uint32_t esz); @@ -224,7 +224,8 @@ void HELPER(NAME)(void *vd, void *v0, target_ulong s1, \ void *vs2, CPURISCVState *env, \ uint32_t desc) \ { \ - do_vext_vx(vd, v0, s1, vs2, env, desc, \ + do_vext_vx(vd, v0, sextract64(s1, 0, target_long_bits()), \ + vs2, env, desc, \ do_##NAME, ESZ); \ } -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:23:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:23:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430648.1653197 (Exim 4.92) (envelope-from ) id 1x9Mwa-0000t0-Lo; Wed, 23 Sep 2026 13:23:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430648.1653197; Wed, 23 Sep 2026 13:23:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Mwa-0000sr-Ha; Wed, 23 Sep 2026 13:23:28 +0000 Received: by outflank-mailman (input) for mailman id 1430648; Wed, 23 Sep 2026 13:23:26 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9MwY-0000om-ON for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:23:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9MwY-002Fb3-4t for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:23:26 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d2c6-e002-0a2a0a5209dd-0a2a450bbdf6-34 for ; Wed, 23 Sep 2026 15:23:26 +0200 Received: from [74.125.229.43] (helo=mail-dy2-f43.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d2cc-b7e8-0a2a450b0019-4a7de52b9479-3 for ; Wed, 23 Sep 2026 15:23:25 +0200 Received: by mail-dy2-f43.google.com with SMTP id 5a478bee46e88-33c11ef641aso1115608eec.1 for ; Wed, 23 Sep 2026 06:23:25 -0700 (PDT) Received: from WIN-BH9M8FJACR9 ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-33e97236754sm5553695eec.29.2026.09.23.06.23.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 06:23:22 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790169804; x=1790774604; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=F+o5KblLu0GyQgfzLlM1cTvsfq0uChm3NLiJCLhEk08=; b=bV6yRlFYGAyFON7bL5KKKaz/QAIV0q3u8odLsbtmX/RzlPGcpOT8lSEii1dIoEI/h3 wXbygWn97h/61Q89HrhSpmiGQzWWK39OiApx5ooA59D5eg+GWsy6yu+ElJUKVUzByqtQ kdbm0EJ2uJ1VpX6HxgRog/ds8J8s+zy5iQvtQzW8bN+19VvW+AsRkBrRIhoglE4ThZs/ hsI8Ni4UJMkdTW/uvGGKohldvz4Clzr9re3qOkUcLCbpAK7ZBJqDWa8ri6qGjhqTJ2dh fvBQaI0Vu6tuAb2NzZvPVwS6Hqd2XHkhHIJWkqEPN2CIXmqm3rlXF2Q7WoZkE5f30hoU uboQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790169804; x=1790774604; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=F+o5KblLu0GyQgfzLlM1cTvsfq0uChm3NLiJCLhEk08=; b=qPp9QzcW+S6vLtTCkxPuRiBTrs+JkJp2lvGc9OxlSxSOqw1LRgLS3VcyfcKBMJAPrp CrD5Spsnc9wwiL8g39b7ct07yqd55rSDSMgvR4PJb4J5j4XtnZlQnINtCugi6nNq+agf /zM+idQlPII+NUHVx5jLj0VveAWE5JWyGcr8JvhOsUGt6bwHw5kySp4xwxFx7F5pDyyW KX9H1xTPbmOlTTXMC5qh2Y/MJxGd0z8UPetaPUkH85ESkBiiPkHpD2eA/5a3cJEyUkzb tnzK4knuqMij8MlQ+9bD0fy3l3pgr8+GMcbMeDpzGCmUW7lFISAcxrvoYSQiLCRq3duQ txrA== X-Forwarded-Encrypted: i=1; AKwUvBwmY5iNXW/65+Fej08mMYSr5KkQy0yI+NvDjLtMqRhPdlLCbtgITbfP52gzX7V2EsZ7dS8GF/fHwLY=@lists.xenproject.org X-Gm-Message-State: AFuF++nFFjL5LsM02Ug9HYfaYbGyjv8V24YWVybJOikQBlBPjw6y8COM o+sAFLlrZ9KB4pwUCChILGPOx71VXveG/dpV9eF/TjXkfDImQdBgPHcM X-Gm-Gg: AYBFou3o0VgMe1AdYrB9mlQ5kMuSvWjWObZvVJa6Fpc1crBky58cpDccHrCkuFSwg45 zEDa/b+xVXBgd0RiBz9pBbvFdazKhWao0wzRmnx/QVHouPPbYOsoxP3BzDSthRIHnvXgLN9QbmZ WJygNBqc2Tg3sA71sjcgjGL9lniy+ERzXxdcyYTuOvZH8bAXLcdOUuz+kJgj4qBudKyFgQfdzyB CcEHSkiafNV46S6u/lG8A7XIGSGkp6qbSJGlaIUoi/sNbPXenJBAruzCBfPfemauIGBY66+C1ae w+FgmADkAt7TFgGP9jtaEImZ3Avcd+Vjd6kCkDv1A254iG9PLsAc+IQWyK94jz9eNkw85DhGRzV eIkF4v1K70334V0akHfXLwofRbe9lADmDfsKxbXr92xVhxEQ4QoCZwYdhvRF1HXqhSdtYtjOKkq xHr+ag5LfSu8hocvGfgocTMmgkOhNu0P0h+BFDIlFEhBGz6VYKXJNgDleqw56UKOrCRI5KS0Ccm XL7VXEkJCe2/3F7xizR+uToqsO2QW9XQuSX7NJPxg== X-Received: by 2002:a05:7300:7b27:b0:33b:eec0:eefc with SMTP id 5a478bee46e88-33e8e88ea29mr2331973eec.40.1790169802984; Wed, 23 Sep 2026 06:23:22 -0700 (PDT) From: Yonggang Luo To: qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Liu Zhiwei , Pierrick Bouvier , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?q?Alex=20Benn=C3=A9e?= , Stafford Horne , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain Subject: [PATCH v3 040/114] target/riscv: replace leftover TARGET_LONG_BITS Date: Wed, 23 Sep 2026 21:15:14 +0800 Message-ID: <20260923131635.1894-41-luoyonggang@gmail.com> X-Mailer: git-send-email 2.52.0.windows.1 In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> References: <20260923131635.1894-1-luoyonggang@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-42698a/1790169805-AAEDE9EA-2567EEF8/0/0 X-purgate-type: clean X-purgate-size: 2564 - Use target_long_bits() in bitmanip clmul/clmulr/xperm loops and in the m128 signed-div overflow check. - Compare xperm element positions to target_long_bits() instead of sizeof(target_ulong), which is always 8 in common-system. - Leave translate.c and insn_trans TARGET_LONG_BITS for riscv-tcg-tl. Signed-off-by: Yonggang Luo --- target/riscv/tcg/bitmanip_helper.c | 10 +++++----- target/riscv/tcg/m128_helper.c | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/target/riscv/tcg/bitmanip_helper.c b/target/riscv/tcg/bitmanip_helper.c index 5af3efe194d..db226146054 100644 --- a/target/riscv/tcg/bitmanip_helper.c +++ b/target/riscv/tcg/bitmanip_helper.c @@ -30,7 +30,7 @@ target_ulong HELPER(clmul)(target_ulong rs1, target_ulong rs2) { target_ulong result = 0; - for (int i = 0; i < TARGET_LONG_BITS; i++) { + for (int i = 0; i < target_long_bits(); i++) { if ((rs2 >> i) & 1) { result ^= (rs1 << i); } @@ -43,9 +43,9 @@ target_ulong HELPER(clmulr)(target_ulong rs1, target_ulong rs2) { target_ulong result = 0; - for (int i = 0; i < TARGET_LONG_BITS; i++) { + for (int i = 0; i < target_long_bits(); i++) { if ((rs2 >> i) & 1) { - result ^= (rs1 >> (TARGET_LONG_BITS - i - 1)); + result ^= (rs1 >> (target_long_bits() - i - 1)); } } @@ -98,9 +98,9 @@ static inline target_ulong do_xperm(target_ulong rs1, target_ulong rs2, target_ulong mask = (1LL << sz) - 1; target_ulong pos; - for (int i = 0; i < TARGET_LONG_BITS; i += sz) { + for (int i = 0; i < target_long_bits(); i += sz) { pos = ((rs2 >> i) & mask) << sz_log2; - if (pos < sizeof(target_ulong) * 8) { + if (pos < target_long_bits()) { r |= ((rs1 >> pos) & mask) << i; } } diff --git a/target/riscv/tcg/m128_helper.c b/target/riscv/tcg/m128_helper.c index 7d9b83b1b2c..e59a1ffd7a7 100644 --- a/target/riscv/tcg/m128_helper.c +++ b/target/riscv/tcg/m128_helper.c @@ -71,7 +71,7 @@ target_ulong HELPER(divs_i128)(CPURISCVState *env, if (vl == 0 && vh == 0) { /* Div by zero check */ ql = ~0x0; qh = ~0x0; - } else if (uh == (1ULL << (TARGET_LONG_BITS - 1)) && ul == 0 && + } else if (uh == (1ULL << (target_long_bits() - 1)) && ul == 0 && vh == ~0x0 && vl == ~0x0) { /* Signed div overflow check (-2**127 / -1) */ ql = ul; -- 2.52.0.windows.1 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:35:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:35:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430695.1653205 (Exim 4.92) (envelope-from ) id 1x9N7l-0004ra-Oj; Wed, 23 Sep 2026 13:35:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430695.1653205; Wed, 23 Sep 2026 13:35:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9N7l-0004rT-Lc; Wed, 23 Sep 2026 13:35:01 +0000 Received: by outflank-mailman (input) for mailman id 1430695; Wed, 23 Sep 2026 13:35:00 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9N7j-0004qD-Hh for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:35:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9N7i-00BSnW-Uc for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:34:58 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d577-2eae-0a2a0a5409dd-0a2a4502a50a-28 for ; Wed, 23 Sep 2026 15:34:58 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d582-6ca4-0a2a45020019-b9ff1c22b367-3 for ; Wed, 23 Sep 2026 15:34:58 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0ce79f65d00072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 13:34:54 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id B1A0D823C0; Wed, 23 Sep 2026 15:34:53 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=dFuIudNtE6oM2PjWLgsmu2jET1ZsEAt+xVFY2/KsvMo=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=nskKXtmthWxVoMqcsvDkyQgxBB+ba6takTdVLMTg1ydVLru28T0kB3r15gq3VQ8dBSr/6dUW7 CmnLK3nUQjlDCfjvN7BbFxDSdERC7YGNup8LQHq3WU80CE0Hgu6bDMy0hza50ra1wFXx/vC6hnS g0zUQuFdqkA42Oa18OAF9y/1EE/RGMxZeILrnIsXM/RdkOkW4prJStc2UvmgdfeTDQMjQA9eBQ2 N/KYkSK1jLNF5fIbedqUVluXx9CFw+ShfkikVstV16cuLglIwUvckgGi5xNyDy+rDIyHs7Q8iK7 MphJTmuFza9IgYVBuA4vDl0qLEB3MQpi36flftMRPv5w== X-Zone-Loop: 6b28e4af744cc266a227bc57f616b11ab14635dfacd3 x-campaign-type: default x-transaction-id: 2a8ee993-7704-4261-a27b-b280e175ec48 x-swg-uid: 01-781ff06c-eb71-4ce0-84b1-3cae80fa1eee X-Mailer: Sweego Message-ID: <1790170494.8631fc262581453bbf619ec5b2062170.1a0ce79f65d00072c4@vates.tech> x-swg-bid: 1790170494.8631fc262581453bbf619ec5b2062170.1a0ce79f65d00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> Date: Wed, 23 Sep 2026 15:34:46 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790170487; l=7073; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Q0Q8nCD/NGSNdOI64l/GAgsGkm9DoUQ1ABw46i0/2hw=; b=MtUjOeZDcknlc+Bdg2XDgTOQuq+RAnvKTu0nObVSBzo0JYFbTFwgySmv8cgYYUA8LWhHTWbdk /nk7foteJAiDrG3zhMPzaZewpFp2CFtJnF1KL6xUSGz8MQ4TzjU3DWD X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790170493927 X-purgate-ID: tlsNG-720697/1790170498-F06A72AC-B7DE096D/10/73395122804 X-purgate-type: spam X-purgate-size: 7073 > After new IMSIC VS-file is zeroed-out it is necessary to do G-stage remaping > fo new IMSIC VS-file. Also, if any interrupts at an APLIC are forwarded by > MSIs to the old interrupt file, reconfigure the APLIC to send them to the > new interrupt file. > > Generally it is needed also to modify the relevant translation tables at > all IOMMUs so that MSIs for this virtual interrupt file are now sent to > the new physical interrupt file but it is skipped for now there is no IOMMU > support for RISC-V. > > Synchronize with APLIC to ensure that no straggler MSIs will arrive at > the old interrupt file by using of aplic_genmsi_barrier(). > > Technically there is no need for read_lock_irqsave() and > read_unlock_irqrestore() around reading of ->guest_file_id, as a write > cannot happen in parallel: any update to ->guest_file_id for a vCPU > will happen either in imsic_migrate_vcpu() itself or before the vCPU > first gains control (in continue_new_vcpu()), so there is no concurrent > access to it in imsic_migrate_vcpu(). The lock is added here for > potential future cases. > > Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > against silent incorrect behaviour or unexpected panics in guest VMs until > the function is fully implemented. > > imsic_map_guest_file() and imsic_update_state() are stubs for now and will > be introduced later in a separate patch. "will be introduced later" would be stale in the future. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index 5de4594961..5e9f6995e4 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -27,6 +27,7 @@ > #include > > #include > +#include > #include > > #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ) > @@ -60,6 +61,12 @@ static unsigned int __ro_after_init guest_num_msis; > #define IMSIC_DISABLE_EITHRESHOLD 1 > #define IMSIC_ENABLE_EITHRESHOLD 0 > > +#define imsic_csr_read(c) \ > +({ \ > + csr_write(CSR_SISELECT, (c)); \ > + csr_read(CSR_SIREG); \ > +}) > + > #define imsic_csr_write(c, v) \ > do { \ > csr_write(CSR_SISELECT, c); \ > @@ -141,6 +148,11 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v) > return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); > } > > +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id) > +{ > + BUG_ON("unimplemented\n"); > +} > + > void __init imsic_ids_local_delivery(bool enable) > { > if ( enable ) > @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) > spin_unlock(&imsic_cfg.lock); > } > > +static bool imsic_local_is_pending(unsigned int id) > +{ > + unsigned long isel = > + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0; > + unsigned long bit = BIT(id % BITS_PER_LONG, UL); > + > + return !!(imsic_csr_read(isel) & bit); > +} > + > /* Callers aren't intended to changed imsic_cfg so return const. */ > const struct imsic_config *imsic_get_config(void) > { > @@ -436,6 +457,11 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v) > /* Nothing to do */ > } > > +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) > +{ > + return -EOPNOTSUPP; > +} > + > int cf_check vcpu_imsic_init(struct vcpu *v) > { > struct vimsic_state *imsic_state; > @@ -497,6 +523,27 @@ static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), > on_selected_cpus(cpumask_of(cpu), func, data, 1); > } > > +/* > + * Ensure that all the MSIs the APLIC has already generated for the hart this > + * runs on have really reached the hart's IMSIC. > + * > + * The barrier is the one described by the AIA specification in > + * "Synchronizing interactions between a hart and the APLIC": ask the APLIC to > + * send an MSI to the hart itself and wait until it shows up as pending in the > + * hart's own interrupt file. As it says nothing about MSIs on their way to > + * any other hart, it has to be executed by the pCPU owning the interrupt file > + * the MSIs were being sent to. > + */ > +static void cf_check imsic_aplic_sync(void *data) It seems data arg is not used here > +{ > + imsic_local_eix_update(imsic_cfg.sync_id, 1, true, false); > + > + aplic_genmsi_barrier(); > + > + while ( !imsic_local_is_pending(imsic_cfg.sync_id) ) > + cpu_relax(); > +} > + > static void cf_check imsic_vsfile_local_clear(void *data) > { > unsigned int i; > @@ -837,6 +884,10 @@ void imsic_migrate_vcpu(struct vcpu *v) > struct imsic_vsfile_data vsfile_data = { > .nr_eix = nr_hw_eix, > }; > + struct vimsic_state *imsic_state = v->arch.vimsic_state; > + unsigned long flags; > + unsigned int old_vsfile_id; > + unsigned int old_vsfile_cpu; > > /* > * The scheduler can mark a freshly created vCPU's unit as migrated and > @@ -848,8 +899,22 @@ void imsic_migrate_vcpu(struct vcpu *v) > if ( v->arch.last_cpu == NR_CPUS ) > return; > > + read_lock_irqsave(&imsic_state->vsfile_lock, flags); > + old_vsfile_id = imsic_state->guest_file_id; > + old_vsfile_cpu = imsic_state->vsfile_cpu; > + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > + > + /* > + * We don't support SW interrupt files at the moment. Bail out before > + * anything is touched, as the old file has no owning pCPU in that case > + * and there is nothing to retarget the producers away from. > + */ > + if ( old_vsfile_cpu == NR_CPUS ) > + panic("IMSIC SW-file isn't supported\n"); > + > /* > * At this point, all interrupt producers are still using the old IMSIC > + * VS-file so we first move all interrupt producers to the new IMSIC > * VS-file. > */ > > @@ -870,5 +935,43 @@ void imsic_migrate_vcpu(struct vcpu *v) > /* Zero-out new IMSIC VS-file */ > imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); > + /* Update G-stage mapping for the new IMSIC VS-file */ > + if ( imsic_map_guest_file(v, new_vsfile_hgei) ) > + { > + domain_crash(v->domain, "Migration to hw interrupt file failed\n"); > + > + return; > + } > + > + imsic_update_state(v, new_vsfile_hgei); > + This gets rewritten later in the series by "xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu", which moves the clear/map/update sequence into imsic_vsfile_acquire() (and adds vgein_release() on the error path). Could imsic_vsfile_acquire() be introduced here (or in a prep patch) instead, so that the later patch only adds imsic_vsfile_attach()? That would avoid the churn. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:37:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:37:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430701.1653214 (Exim 4.92) (envelope-from ) id 1x9NAD-0005eh-4B; Wed, 23 Sep 2026 13:37:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430701.1653214; Wed, 23 Sep 2026 13:37:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NAD-0005ea-1W; Wed, 23 Sep 2026 13:37:33 +0000 Received: by outflank-mailman (input) for mailman id 1430701; Wed, 23 Sep 2026 13:37:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NAB-0005dD-UM for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:37:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9NA8-00DMG7-RW for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:37:28 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d60b-2eae-0a2a0a5409dd-0a2a45028a16-14 for ; Wed, 23 Sep 2026 15:37:28 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d618-6ca4-0a2a45020019-4a7de18dd69d-3 for ; Wed, 23 Sep 2026 15:37:28 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912df756so6692195e9.3 for ; Wed, 23 Sep 2026 06:37:28 -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-49fde198f85sm82730105e9.8.2026.09.23.06.37.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 06:37:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790170648; x=1790775448; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=fcrUh4n9/+wLrzrrVFpgROhaQUP011P1zLKET1PjOsk=; b=b1HhqJj8fvmTBDuocl7/F9OZIvHXy5z813Wy0VJ95cVZx90nalPdyjGlO+qd6dKrrY 8xUQF4d1BLiHVTJR51n/6MPwJPkCIIfL4SCPU9jhXbezlzO3/dV+QlY2lLTxypPS0bpH qhdvNC5H6r8an6JpjA18cAHv7ch928kq6GlP6bGUqkIEcxlkHf1nyEsb6EFYMMWDW7Ll f78wm1gYf4dn8v0+ORE1QkeRzN+lP0YkGTfFy3YwpxMjpIpsrWswerzMQnVBwjMAC2QV 8GhCUwQ234Eo5pDAvLGlDeokGSAcYjJ50mP7Tleb7rlnNKcwU+tVNBHohTxBq5JeJGJE Sx1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790170648; x=1790775448; h=content-transfer-encoding:content-type: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:content-type; bh=fcrUh4n9/+wLrzrrVFpgROhaQUP011P1zLKET1PjOsk=; b=Ds1MYdILC+TFYw3C87ebNrNfuaOIJODu1qrNT0YDjR86WMyOi/XCvOdO2a68D9QijP CFPrLAbVXsDJEVSXmqlLGSXLaWgXTK3UN6ZKPbL7VE6osvoUFDPrIHIan6dD27wg5kW2 gbQd1nSgTcXD6mvBKj/m/33agpSpoNWKyigc0CEYzYYMKDgKqdHsp9FZLotFsSIbOJ6n jjMfdARlzorQRljgBA176QHWjidNqnDYCtautA3pVF+vKiUSHPt7AEeziWxQW/fPvgFg 9gjkkcwu6sMOm+lzNYF7dqniDj2GwhZCH+2v8BaN58A+7wrXcHZ9A0fsIFzFKnuzyylt Gx1g== X-Gm-Message-State: AFuF++nPp2AugGLpMjUKlHWkI81/kWo3mc1bycPxpLY/BlYhbpPTNH9R L/j7cQstWgJoynX6yA8ONfhtB9qJKkW+ytADUvoiqM9srXYI5x6zyg8oYbELDxRYH8nPtKkPFoY qx4h/sw== X-Gm-Gg: AYBFou1ZiWHCEAE0vuMvQYiOFUdxlGahW3qRys+IxgpVQEPEeQQtKaGml6gQlATVAq9 M9KEsEmIFlKwz9txiNYgLejHr96xHdQxIJI6TKxn95lIR3+C8f16Xq0RkeXVa1zXoRHwa/jPnDd bKMLMb+VtB77DkW0mGLYULlUMKqHlDvmgXz/EN0gTu+bwz6Cm8/KZcgZpOByoKZGATbBty9pWly ro+g/OtBNT946Abeya7aXs4bIms8JgmXNkIDfPL0pAJDTEE3IcURVFyRFbFquKHLF2RKTD52mNx O3IaYRSWo8Vp/F5k+IFgBq7Fkbua/Sfd5PYGgOZw7+b0NCWbuaxbbeHjV8uYbGfTGEL6BJQXlEN Los1JjkC122yXSfLXOcpJCrig3YYmZC9zTc2CcVL7mwlDxyfPUZvXCD9byuUZFSEu8F0TW2TUg4 gL4spMARN3wH9Hca+iyP9OJHfGCd3OmBBkZ5dWSBoik+eT+GCHoZPKJeUxZjhbBB4ft8JeWrYZy ie34MVCJ4K/qgXY8vEWFcOvMsG9FMkVbtUuQi/LAiTEj3F/7dlw6RE8VtoEcndraXWskY2qBA== X-Received: by 2002:a05:600c:8b88:b0:49c:fc6e:8cbd with SMTP id 5b1f17b1804b1-49fdf152e3fmr34515245e9.33.1790170647957; Wed, 23 Sep 2026 06:37:27 -0700 (PDT) Message-ID: Date: Wed, 23 Sep 2026 15:37:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 000/114] single-binary: link multi-targets into qemu-system To: Yonggang Luo Cc: xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, kvm@vger.kernel.org, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, qemu-devel@nongnu.org References: <20260923131635.1894-1-luoyonggang@gmail.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: <20260923131635.1894-1-luoyonggang@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-720697/1790170648-F08A42AC-BB1F4B12/0/0 X-purgate-type: clean X-purgate-size: 12368 (reducing Cc list to mailing lists) On 23.09.2026 15:14, Yonggang Luo wrote: > This series produces one qemu-system binary that can run ARM (32 and > 64), RISC-V (32 and 64), and MicroBlaze. > Upstream filters machines with TypeInfo.is_available. This series > passes a TargetInfo into that callback, uniquifies QOM names that > collide in one process, and compiles those targets once so they can > share qemu-system. > > A combined link cannot keep C symbols or QOM type names that were > unique only because each qemu-system-$arch was a separate binary. > These patches remove those collisions: > > - TYPE_ACCEL_CPU is the fixed abstract type accel-cpu, registered > once next to TYPE_ACCEL. Leaf names still encode the CPU type so > accel_init_cpu_interfaces() can look up "-" plus > target_cpu_type() (tcg-accel-arm-cpu). > - virt QOM names are prefixed: arm-virt, riscv-virt, and the same > for or1k, hexagon, loongarch, m68k, and xtensa. Boards keep > -machine virt via machine_class_set_name(). query-machines returns > the QOM type in MachineInfo typename. > - virt ACPI helpers and RISC-V TCG crc32/crc32c/wfi helpers get an > arch prefix so the combined link does not need meson -D name > mangling. LoongArch virt_acpi_setup is renamed in the same pass. > > Target selection has to work with more than one TargetInfo: > > - The combined binary takes arch:name on -M/-machine and in a > [machine] type (aarch64:virt). arch: binds the target. microblaze: > runs that target's default machine. arm, aarch64, riscv32, and > riscv64 have no default. No -M leaves target none and the empty > none machine. qemu-system-$arch keeps the historic -M name. > -M help lists every target; arch:help lists one. query-targets > lists each linked target, including none. > - TargetInfo is a constructor list. target_info_select() picks the > entry, including SYS_EMU_TARGET_NONE. is_available takes const > TargetInfo *. While the target is still none, QOM skips the > unavailable filter so grouped -M help can list every machine. > - query-cpu-definitions, dump notes, and Angel semihosting sit on > TargetCpuOps indexed by target_arch(). Registration uses a > QEMU_ARCH_* bitmask so one object can fill ARM and AARCH64. The > table is target-ops.h / target-ops.c. > > qemu-system-$TARGET is still built, including the Windows *w twin. > qemu-system is extra. It links each target whose arch sources are > only target-info-def.c: arm, aarch64, riscv32, riscv64, and > microblaze. Do not add qemu-systemw for that binary. A GUI > twin would keep QEMU exporting data from the .exe into DLLs, and > those data exports cannot be delay-loaded (qdev_prop_array and > other qdev_prop_*). That would block enabling modules globally on > Windows. > > Examples: > > qemu-system -M aarch64:virt ... > qemu-system -M microblaze:petalogix-s3adsp1800 ... > qemu-system-riscv64 -M virt ... > > A bare machine name on qemu-system needs an arch: prefix. An unknown > target fails with "target '...' is not available". > > Prerequisites: > [PATCH v2 0/9] machine: uniquify virt QOM names > https://patchew.org/QEMU/20260922215533.641-1-luoyonggang@gmail.com/ > [PATCH 00/21] accel/tcg: share raise_excp across TCG targets > https://patchew.org/QEMU/20260918004225.827-1-luoyonggang@gmail.com/ > [PATCH v5 00/11] single-binary: Compile hw/riscv once > https://patchew.org/QEMU/20260918-hw-riscv-cpu-int-v5-0-f98c5a244636@rev.ng/ > > v1: https://patchew.org/QEMU/20260823150731.896-1-luoyonggang@gmail.com/ > v2: https://patchew.org/QEMU/20260826184229.1145-1-luoyonggang@gmail.com/ > branch: https://gitlab.com/lygstate-qemu/qemu/-/tree/single-binary-arm-riscv?ref_type=heads > x86_64 and i386: https://gitlab.com/lygstate-qemu/qemu/-/tree/combined-binary-multi-targets?ref_type=heads > > Changes v2 -> v3: > - Drop -target. v2 parsed a target_name token and required it on > bare qemu-system, with -target ? to list names. v3 selects the > target with arch:name on -M. No -M leaves target none. -M help > and arch:help list machines. > - Rebased onto current master. Upstream is_available(void) replaces > TYPE_TARGET_SPECIFIC. v3 passes const TargetInfo * into > is_available. The v2 patches that registered TYPE_TARGET_SPECIFIC > on ARM and RISC-V virt are dropped. > - TargetInfo is a constructor list, not chosen from argv[0]. > target_info_select() sets the current entry. Add SysEmuTarget > none. A single-target binary does not switch TargetInfo; arch: > must match that binary or the machine is rejected. > - Drop -Dsingle_binary. qemu-system is built from > single_binary_supported_targets once arch_srcs are only > target-info-def.c. microblaze joins ARM and RISC-V. Per-target > binaries stay. Still no qemu-systemw for the combined binary. > - Unique virt QOM names extend past ARM and RISC-V to or1k, > hexagon, loongarch, m68k, and xtensa. query-machines returns > MachineInfo typename. > - TargetCpuOps is an array indexed by target_arch(), registered > with a QEMU_ARCH_* bitmask. The header moves from > target-info-qom.h to target-ops.h. > - Those targets are compiled once: ARM, RISC-V, and MicroBlaze fold > into common source sets, TARGET_* ifdefs become runtime checks, and > KVM moves to system_ss. > > Pierrick Bouvier (2): > configs/targets: remove target info definitions > target-info: rename target-info-stub.c in target-info-def.c > > Yonggang Luo (112): > meson: stale qemu-version.h only when .git exists > target-info: rename target-info-impl.h to target-info-def.h > target-info: set cpu_type from TARGET_BASE_ARCH > target: remove CPU_RESOLVING_TYPE > vl: parse early options before target-info init > target-info: replace QOM registration with a constructor list > tests/unit: add test-target-info > tests/qtest: prepare machine-list-test for combined qemu-system > kconfig: rename REGISTER to HW_REGISTER > target-info: add TargetKconfig > target-info: add target_is_* helpers for each architecture > target-info: add i386 and x86_64 helpers > qom: pass TargetInfo to is_available > module: use static ModuleEntry and per-type DSO lists > module: add before/after hooks and module_call_init_fn > qom: register late types through module_call_init_fn > qom: inherit is_available and filter after MODULE_INIT_QOM > tests/unit: add module-init and qom is-available tests > hw/arm/virt: prefix ACPI helpers with arm_virt_ > hw/riscv/virt: prefix ACPI helpers with riscv_virt_ > hw/loongarch/virt: prefix ACPI helper with loongarch_virt_ > target/riscv: uniquify TCG crc32, crc32c, and wfi helper names > hw/riscv: gate boards with target_is_base_riscv > hw/intc: use target_long_bits in IMSIC geilen > hw/misc/riscv_cmgcr: replace target_ulong with uint64_t > hw/intc: use kvm_enabled() in APLIC AIA helpers > hw/intc: send IMSIC MSI via kvm_irqchip_send_msi() > target/riscv: add kvm stubs source set > tcg: fix off-by-one in helper extend-free assert > gdbstub: drop per-target cpu-param.h from helpers.h > hw/riscv: expand boston-aia and microblaze-v-generic to TypeInfo > target/riscv: Include migration/vmstate.h instead of migration/cpu.h > in machine.c > target/riscv: gate CPU types with TargetInfo > target/riscv: select ELF dump class from target_riscv64 > target/riscv: replace TARGET_* macros in CSR helpers > target/riscv: use target_long_bits in pmpaddr granule checks > target/riscv: preserve signed XLEN semantics without target_long > target/riscv: replace leftover TARGET_LONG_BITS > target/riscv: select monitor width at runtime > target/riscv: replace target-width format macros > target/riscv: replace TARGET_LONG_BITS in translate > target-info: add tl_is_64() and target_is_tl32/64 helpers > target-info: dispatch CPU QMP, dump, and Angel semihosting > tcg: give TCGv its own type and runtime tl ops > exec: allow target_long.h, abi_ptr.h and cpu-ldst.h from common code > migration: add TargetInfo-gated vmstate fields > target/i386: always compile XMM, YMMH, and Hi16 VMSD > target/i386: replace VMSTATE_UINTTL with 32/64 TI fields > target/ppc: replace VMSTATE_UINTTL with 32/64 TI fields > target/sparc: replace VMSTATE_UINTTL with 32/64 TI fields > target/mips: replace VMSTATE_UINTTL with 32/64 TI fields > hw/hexagon: drop unused migration/cpu.h include > migration: remove unused cpu.h > target/riscv: gate KVM CPU VMSDs with target_has_kconfig_kvm > target/riscv: use tcg_imm_tl in translate > target/riscv: select FP and amocas width at runtime > target/riscv: drop TARGET_RISCV XL shortcuts in translate > target/riscv: select KVM host CPU width at runtime > accel: use a shared TYPE_ACCEL_CPU parent > kvm: always compile guest debug > hw/i386: move APIC_DEFAULT_ADDRESS to apic.h > kvm: stop including cpu.h from kvm.h > kvm: default kvm_arch_reset_parked_vcpu in stubs > kvm: drop COMPILING_PER_TARGET wrap around kvm_arch APIs > kvm: add split irqchip and send_msi stubs > kvm: replace TARGET_S390X and TARGET_PPC hints > kvm: move kvm_ss to system_ss > system: add qemu_host_arch() and reject unavailable -accel > kvm: add AccelClass is_available for host/guest pairing > hvf: add AccelClass is_available for host/guest pairing > xen: add AccelClass is_available for host/guest pairing > nitro: add AccelClass is_available for host/guest pairing > mshv: add AccelClass is_available for host/guest pairing > whpx: add AccelClass is_available for host/guest pairing > target/i386/nvmm: add AccelClass is_available for host/guest pairing > accel: replace ACCEL_CPU_NAME with accel_cpu_register_type > whpx: move whpx_ss to system_ss > hw/riscv: move boards and irqchip onto hw_common_arch > target/riscv: include target_long.h in TCG helpers > target/riscv: compile CPU and TCG once > target/arm: replace target_long in A64 translate > target/arm: use 64-bit TCG addresses in A64 translate > target/arm: move kvm_arm_set_cpreg_mig_tolerances to kvm.c > target/arm: allow -cpu host with Nitro > target/arm: gate -cpu host with TypeIsAvailable > target/arm: fix family-common KVM compile > tests/qtest: raise aspeed_smc-test timeout to 12 minutes > hw/intc: move ARM GIC kvm/hvf/whpx onto arm_common_ss > target/arm: fold arm_ss into common source sets > meson: link shared objects into qemu-system > target/microblaze: fold system sources into common source sets > meson: add microblaze-softmmu to the combined qemu-system list > boards: remove unused DEFINE_MACHINE_WITH_INTERFACES > hw/arm: set virt TypeInfo.is_available > hw/arm: set remaining 32-bit machine TypeInfo.is_available > hw/arm: set aarch64-only machine TypeInfo.is_available > hw/microblaze: set petalogix-s3adsp1800 TypeInfo.is_available > hw/arm: expand leftover 32-bit DEFINE_MACHINE to TypeInfo > hw/arm: expand imx8mm-evk DEFINE_MACHINE to TypeInfo > hw/microblaze: expand petalogix-ml605 and xlnx-zynqmp-pmu to TypeInfo > hw/i386: set TYPE_X86_MACHINE TypeInfo.is_available > hw/block/dataplane: move xen-block onto system_ss > hw/remote: move multiprocess memory onto remote_ss > hw/remote: set x-remote TypeInfo.is_available > target-info: add SysEmuTarget none > accel/tcg: tolerate NULL target_cpu_type for -M none > qom: skip unavailable filter when target_none() > module: load every arch-tagged module when target is none > target-info: select combined qemu-system target by name > vl: parse arch: machine types on combined qemu-system > qapi: add query-targets > tests/qtest: cover combined qemu-system machines and accel-cpu Now this is really excessive: You mail out a huge series (a fair part of which apparently still needs to make it through), cross posting to lists covering components which are touched only in very few places of the series. I consider such rude already for much smaller series; here you definitely should have made per-patch Cc lists. I wouldn't be surprised if xen-devel@ isn't the only list which is being spammed for no good reason. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:43:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:43:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430722.1653223 (Exim 4.92) (envelope-from ) id 1x9NGJ-0008MU-RM; Wed, 23 Sep 2026 13:43:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430722.1653223; Wed, 23 Sep 2026 13:43:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NGJ-0008MN-OO; Wed, 23 Sep 2026 13:43:51 +0000 Received: by outflank-mailman (input) for mailman id 1430722; Wed, 23 Sep 2026 13:43:50 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NGI-0008LC-IP for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:43:50 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9NGH-00BToJ-AZ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:43:49 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d791-e002-0a2a0a5209dd-0a2a450cb844-22 for ; Wed, 23 Sep 2026 15:43:49 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d795-f479-0a2a450c0019-4a7de18dbf3b-3 for ; Wed, 23 Sep 2026 15:43:49 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49d097b4939so5082575e9.0 for ; Wed, 23 Sep 2026 06:43:49 -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 ffacd0b85a97d-488684863fbsm6346831f8f.11.2026.09.23.06.43.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 06:43:47 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:Content-Language:References:Cc:To:From:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790171029; x=1790775829; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=DZsTMyt4BK3N1ESu+j3jzdx1XPzDqWmsokBRCaUxVHU=; b=TlbuKE82sHTsRAGrLLuHuWak2HQmIXOD5YclB5LcjIjH/4ErVPmd/DvZt8wHsJtFkp a6A+enPr5i8VNSftH36JkDEGXB/4w3CA+uA6/7hmydSifTVefVr4ClluBEQQjTAVgiSS DtA5aeDI/xwtTJ93ZQT9WtrgcfKaFgHLDHYoafGvMQfCS/YjP8Q3G+/sZu4D2bHLpKOe V0FiviLLZEuWCbhMUhSjmnc19sKUuxSF1aukiaS7GlfJy3v+AwZdEXPA1hh0yC7DDM4S h8UK5bQR/1ItcDZvWdOJDAeSeMEbexnWDH2Cm03RolJRIK29TQ0V5Ui9z9aJe2/Coh9C rUoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790171029; x=1790775829; h=content-transfer-encoding:content-type:in-reply-to:autocrypt :content-language:references:cc:to:from:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=DZsTMyt4BK3N1ESu+j3jzdx1XPzDqWmsokBRCaUxVHU=; b=rkqnOogwHGboWV2J0o/3qDspICdeScNQ0AAuyNt5edWA+6CRPEwGs6/r+7bZ3NgcQc 1cjFB6pFsBlu5yCl8YSwyDxx1VKI/5jXbYDVb37+wWmk7mePcyKRKigsWkG+GBQBSQXL pDmjhlNL8g6phlsmdb5DCEs1LHhg5kWBeNOTlb49/q3848zL2KD46SbUeXpZ3YB3IJr+ fPoPFg4eS4EysdKi0FjheXp1ZhNzts2LUWLjHS2cV+WPPiS6Rdgu8s9WU53qjOGulaQ9 Itn/m+xhY7Wi7h0+WBBc/aPvPeHpY43G96qGrkG4szM09RNPcA6PQ4iPeRZCp53K/i9U baPw== X-Gm-Message-State: AFuF++mkyfal+yWb3DbJ6Vz1meOcBsDs0NNHR3eF5H+rVyPOnuqa5497 4RGSasnXiPs4+5sbysbg9pxReo1v6g9lw1Cu+9/2NFDlHBd4PcAyOVH6tGlzhJGjjJo8KO+Xqsm dBmphBw== X-Gm-Gg: AYBFou2klNFQuxNi1jGKH+Dt38kK2+AM9P9VHhZYxP7qfc8egaxC5+h3dVOydWA05as vMAz1+i1X9qcT23XTzJKvtOMjERtUtj1VZBMIxcV33bkx2VVkEBUpP1ScydRq056D0aXxecQWlw 9NJ0ekwvhcRBc3l+uXM1fDEG75+cUgXRo17XGCSL6dhOtHB7ihAD/58zDFHZu/Zq52u4UuUqJv9 G5RNK0a27W0V/pzlsIcL8UHYbNmPp82iKqlf2Pq8IV/eXyNk47grcUNFWNSepuZFIMnsjGL4vYl /MoLWP9KmFAeZ2ixcvETFiAefKd3vGi4Gk3WWOPf7D4PV+dni9IR7MlLdI5R/MyWZdn2bDpib1P jgatSly+d5bImgAW9wN04+tN+SPb0DMs8kM/djOWqFoAu0lPeglIHiDl6y3PpgLXqkv5awjElWt 1CXINLwC/diHfBoaMNIfZWUVsRADuOpWHUK335hnk3NWc4E5moVrUAzvspWopL0m3AXHTc5ZJnp hEA+KsIi3azXtDLPpn/dNiaTJYGTYI9iGmMOv0rcb+7NgrS+VOP3Oz2yopcIGDM7WCA4cN9 X-Received: by 2002:a05:600c:190e:b0:49c:fa21:e746 with SMTP id 5b1f17b1804b1-49fdf13b858mr36956505e9.28.1790171028731; Wed, 23 Sep 2026 06:43:48 -0700 (PDT) Message-ID: <05180ea9-4fba-4b2f-b20e-7ea231c66cd9@suse.com> Date: Wed, 23 Sep 2026 15:43:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 7/7] gnttab: unreachable code when GNTTAB_MAX_VERSION < 2 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Nicola Vetrini References: <38850629-8bfa-4737-99ff-0fd3f489e56e@suse.com> <436c0688-8b9a-4e56-9d4c-c81dcfbea56e@suse.com> Content-Language: en-US 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: <436c0688-8b9a-4e56-9d4c-c81dcfbea56e@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790171029-018C5A5B-2B91056E/0/0 X-purgate-type: clean X-purgate-size: 340 On 28.07.2026 15:53, Jan Beulich wrote: > I'm surprised Eclair doesn't spot the large chunks of unreachable code on > Arm, i.e. violations of Misra C:2012 rule 2.1. This was a thinko of mine. By using "gnttab=max-ver:2" v2 can actually be engaged on Arm as well, so related code isn't unreachable. I'm withdrawing the patch. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:45:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:45:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430728.1653232 (Exim 4.92) (envelope-from ) id 1x9NI3-0000kM-4R; Wed, 23 Sep 2026 13:45:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430728.1653232; Wed, 23 Sep 2026 13:45:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NI3-0000kF-1C; Wed, 23 Sep 2026 13:45:39 +0000 Received: by outflank-mailman (input) for mailman id 1430728; Wed, 23 Sep 2026 13:45:38 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NI1-0000k9-T6 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:45:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9NI0-0082MR-VR for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:45:37 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d7f8-8faa-0a2a0a5109dd-0a2a450ac0b6-22 for ; Wed, 23 Sep 2026 15:45:35 +0200 Received: from [52.101.65.8] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d7fe-f2d2-0a2a450a0019-34654108af13-3 for ; Wed, 23 Sep 2026 15:45:34 +0200 Received: from WA2PEPF000008A3.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::654) by DBBPR08MB10531.eurprd08.prod.outlook.com (2603:10a6:10:53d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.4; Wed, 23 Sep 2026 13:45:24 +0000 Received: from WA1PEPF00009B3A.eurprd05.prod.outlook.com (2603:10a6:1d8::118) by WA2PEPF000008A3.outlook.office365.com (2603:10a6:1d8::654) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.382.12 via Frontend Transport; Wed, 23 Sep 2026 13:45:24 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by WA1PEPF00009B3A.mail.protection.outlook.com (10.167.242.40) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Wed, 23 Sep 2026 13:45:24 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) by DBBPR08MB5993.eurprd08.prod.outlook.com (2603:10a6:10:1f4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Wed, 23 Sep 2026 13:44:47 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0451.012; Wed, 23 Sep 2026 13:44:45 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=kzgdyTvKhhlePou3DYFmQlpI5GOSzMn/Xu8SPWCfg9vBVRFGQxid03K7ciG8NmY8+tUz+MYLtzcfk5D18Id9hqehjMiEPKwRi4yLASAy966ElR1Zy2BQTOv+P4ZfMLm7a4UNEEtyLxYIrvnY9JnInoJT3zNAQF/0ZX0/FENlReHD7C8IHtljH4UnDa/2wMFm4DtvRNOu1Huanv7AjveJ7HD6wiyyCSbgNXj8vMwIvhCbdg9WZax2rBTaYZ2W9P0HG3ng8IkuPfEWDOhgMf5PvD7LJLigPrtdTViHZ72d2ePWYWvN/I7DQ1EUaMes1fCFrQNJqJohqP70YjAhJrNXnQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DNv2PlrEALCBnLQsldXodP/zMuSTmALFTUFz//S+1bg=; b=xk35mhgC24gyWrvj5H9IV/yYQucGtvPOamJCQUxofy/lghRCucN0uyKWjgXhxzCvxeAiUfAwgZrxla+lXyF6mhN+QPNOvV9R6IMBTvqw0cq7bTdEtUYQv67/843h+eTNrvFASsfK2viClttBuM4exPxf80ou0h7U0s50rbYn1gUKO9HcNY01KvJilmQbsKXEMyVr+T1x279vfYHXlX9aMpGCGTNr6dTFuvbaPwpqFTZuFKXYs6WBy+bRxZAAJfIyZCJt/Cw6QIAucFlvJ1lqorhM6x7DMbi80kgyGT9ZA9qYEwhk8DRm/p+0e0bX28b4K056BkMg3Kj9IGiL7UGmpw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linux.ibm.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DNv2PlrEALCBnLQsldXodP/zMuSTmALFTUFz//S+1bg=; b=NImLnI7mPzOCS5h75myRD6dJrhYj/Y8pb61WWlfOk08FUtxHCscx3oDJn5egO5woT658xGiB2tOEbTMVbcbi6ph3mDDYiA2qjvSuNRYRzRqdfIE9qlC+/cqGsnimcLLVDcNeCm5QDg8C8Ok0X4+2H9Cqc6asgus/twsBLTaTJfY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CFc6tbN+DqR9bAcOpUhd5U6M7Q7RUV9BGGK3m1uDUl3G88awk3wbZkIUMEtEVoD5b+mpJyuYo4ThkzM/O18vTTB2yH05diNCUoxnCR6PzAd6zAe6sjujqVwqzbLfZSpBRmlaX7XN01mX1sFF/PCDrFtVgNxTVhkksyzKFJAoKXVc2dLQz68cI5czXADet2kHxLdB0RwAG8A4JIKNQ22vh7cJvtgaTzMm9J2BDX0LuHqFJpDmHmOlRw4vxjbTQQ8HW+FeNjRs/2kTIFFnnNEkCK8JjpAY43grjKB/1vVBkqsJP82tRXL+D3n54rr3SLW5UcaLzAtBE6p5ZI1m7B8buw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DNv2PlrEALCBnLQsldXodP/zMuSTmALFTUFz//S+1bg=; b=jNWSZAnXa1NBr9IVjgjsys9yhz7wZLeNTqADBkYdUvhNe6TsU0eG2px/iArkOYQ21o00f5SprqHsrUhgh/eG476Y9d73VAjX9Arqk7Sn1xVij1xQIbJ9Gc/isTRqDMBmtJxYT/h52ecJqhaIJw5lUqsBdyVWKgz0zfTPa7ceo+tOcwIduGe+GNYblhw83oko/QCqSMDHxhyH78pUhd4+GtCloSsUbMkr1b030fIdCDunGTloje1Oy+t7fof+sPsDg8ytEukVESEYbEFtLBJlJuy3TZ0ZNZ6xZmtA0RvwzY4tiXzWwf7DQElW80W7heL7Qh7OVrmv7FY8lQQa5CFUjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DNv2PlrEALCBnLQsldXodP/zMuSTmALFTUFz//S+1bg=; b=NImLnI7mPzOCS5h75myRD6dJrhYj/Y8pb61WWlfOk08FUtxHCscx3oDJn5egO5woT658xGiB2tOEbTMVbcbi6ph3mDDYiA2qjvSuNRYRzRqdfIE9qlC+/cqGsnimcLLVDcNeCm5QDg8C8Ok0X4+2H9Cqc6asgus/twsBLTaTJfY= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Message-ID: Date: Wed, 23 Sep 2026 14:44:40 +0100 User-Agent: Mozilla Thunderbird Cc: usama.anjum@arm.com, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: Re: [PATCH v2 1/8] mm: introduce hw_pte_t for PTE table storage To: Alexander Gordeev References: <20260903103002.1091859-1-usama.anjum@arm.com> <20260903103002.1091859-2-usama.anjum@arm.com> <4fb9f42e-73c3-46db-ac10-351a90901b7c-agordeev@linux.ibm.com> From: Muhammad Usama Anjum Content-Language: en-US In-Reply-To: <4fb9f42e-73c3-46db-ac10-351a90901b7c-agordeev@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0270.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:194::23) To VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3421:EE_|DBBPR08MB5993:EE_|WA1PEPF00009B3A:EE_|DBBPR08MB10531:EE_ X-MS-Office365-Filtering-Correlation-Id: 93df322b-b665-4342-eb1a-08df1978eb26 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|7416014|1800799024|376014|366016|10067099003|11063799006|6133799003|10063799003|18002099003|22082099003|56012099006|4143699003; X-Microsoft-Antispam-Message-Info-Original: 4g1AO8kRUEFNWgcQXjh2wHWdD79yQHdGiF1pC7allufgdnec5hNaE7+LNiSCIW8Cf/LtPMWAWu+HPPgzv/h/86VenR7OgyMEAnQxSLhc6S1YXd3KbGcVG8FY+/uRwl2ul7KHXmCO3LuzTQ0SFj2AvY+ekUeNm5xr/L4a17cqmOqLpE0hAIi44FxnIq9dA3Nm+SVA/TEFMUynwqzMMF1o0R5llCURQxKQkTE1GpeGyi36kiNV9ODPLh1EN0sfuFhInnhFcKJqY+xYUmLPvsySIeInXeNZ1Z93zJhvtB2mq6Y8l5seuDc2vh5RF/SHYMEdPWXSnE5OZxSiaYpuFsg+dDvBTPyMsN0r+h+n2YCPn1GFt6ITTvfq46WkRfqb3MSjQnVdYP/zv/x0HEy6K4khd2PMP8H+vDJwOYKRmIG3Mi519jEvwQz40tAckyFi0mO4vK+baOniNWbTxmwhe8ESybU9GLHKpvs/R6GFtfYcJZB3Kt6GXZUOf1Qb2V5lvYAJGrzFdVA2+GGsUXSScGpCDpUR+Y30VQ+1KOjQc8IDrXUQVwlCBTIaYDWiZ95e9D8+FO8tuwdnNTTTyOYXynEdIkSbx1nbyf2tebLLP7inAORYQY8UD1Uaw/iqwaxO1xbT X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(7416014)(1800799024)(376014)(366016)(10067099003)(11063799006)(6133799003)(10063799003)(18002099003)(22082099003)(56012099006)(4143699003);DIR:OUT;SFP:1101; X-Exchange-RoutingPolicyChecked: TXHaA0zYu16+wIC41/vqvbEGWbtUM6A/QEi4hfjhAZPwB7e/jDm13rcDMw/aO8Z2W08mfc3hKtaOOacLo68A26n5EL4dlA6LeleYhiC9nkQ6kXhDTJjvxh6CcSAyRIuUgCt1DIK2sXz505JdtvnA2ICEk4rkuGPM4P8kWlgrKMZpUO0UV9+9Uo3fIActyOJ5+5cyFkF9VXAiNALcv8XPHc2fVWH9PI099oOHbtbpKWEwWIu1KS07lEVj6r5JRJFjGKZlCzAiG9RixrQvT6D0eOwJ1RBKOXbzd2ZDFxeC0Qw/pt63RPvGVNaks9ZgZxO5NDYB/k+xBxN6WVE1V46ZaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5993 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: WA1PEPF00009B3A.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 40b0c1cc-e4c7-4cb9-e70f-08df1978d2e2 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|14060799003|36860700016|82310400026|35042699022|7416014|376014|23010399003|11063799006|56012099006|10067099003|6133799003|10063799003|22082099003|18002099003|4143699003|13003099007; X-Microsoft-Antispam-Message-Info: xOdlt9gWQb5AmSldLIWwF39tLodl3UEFxjRIlrJ59NOw1kDi74+MXR9xlaG6aaiwXOY4cd5Jr3/wVt3bn36vacHTUeK/0KkfDzfrq2g5Yg2Iq99iBlX+SLENnYyMQSMqVsEr5bmOG7rtrTXyX6GSBc/bDOo1IUtMeKgG3vo/wz5NiZSEi8voynSqFqdUS6viavUwo+Jx+JPKABcrwcVtgmVefWaxTfeyvVpXR6O8KwclhNDzbHfqq32FrEXU0oRTy7L7iSGI0XmH1BSjsT19TjgwGIfyWko4QvIXLRZ7R7aDkpnyOK1icXyArFqJ7sd1bhVUct+dsjWy2kDp4uqvcldeRBBLL858DI2MxESGcLlE7x0xIed6CPotyGxiZLixIEAQVj3xqWHFrekI8GCaF9oIgFJHptna+7v0Ltr9p6UUGpFAa/tqPIxoqsjPoSsY74WZ92uGJZQb/psZOb9k/BWPCpKRlG8ZogiOzuXyGNPyg8rTK4JwxRX2ipiwBXMPMvMfyYc+JG1BqLhRkmKvkwhywKX+Y7UXAVJzMtiV2XcTyIBK+JU0kCtEQwjNebJv6yulaHQFyARfAftW3HoMDE5ANHaQuYWy1WSkZwCxFxTNGuCfIV+dTdbLy5dwvccbsVoESTRJOsivk1l65Y0+HbGp9ST/sv8PNzZMjjVcmVU= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(14060799003)(36860700016)(82310400026)(35042699022)(7416014)(376014)(23010399003)(11063799006)(56012099006)(10067099003)(6133799003)(10063799003)(22082099003)(18002099003)(4143699003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: x678kAqGeH74dlpP5SlpeeqVF/B8Jqjj7yszzQQL7Qxoeef1ZC7qYaLfodPtRt1nBDXEY1KPq1agkS4ZsvRzqw24ACv31K8NxW9wr/5QZWeG+tOpRjBinx10ZZDpZXODjAJGdgImBc2OeaCXeldNt2c0helMZ1fadIpCpL8Qj24u1s64LdFc+u3JU6c+h2SM+Ywr5biNXalC/1kXFJPUWnkX4Q0D/03BN4zFe3OZUBkyYeW43OCfJ3yir3ileqzDhBvPe1LwPl4XAEoAx2nUPBaK4IVYMJVlvdT0YSyYQU5JyZAKOx4mb47W6+TRkp4Z2nBY7tIxsfapRMxxHIlkcCh4SUi40x5LoZc74sT0G1qox30Vs2XcCQluY5Fc5+cDtApJeOw8RizKDiyv4S3QI+goVGza5E7sXuQN5CIegAOHN6TogHTWIcUMWNyFiDMg X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 13:45:24.0046 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 93df322b-b665-4342-eb1a-08df1978eb26 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: WA1PEPF00009B3A.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB10531 X-purgate-ID: tlsNG-4011c0/1790171135-520C1CFC-1AF5F72C/0/0 X-purgate-type: clean X-purgate-size: 4226 On 23/09/2026 12:52 pm, Alexander Gordeev wrote: > On Thu, Sep 03, 2026 at 11:29:53AM +0100, Muhammad Usama Anjum wrote: >> pte_t is used both for software PTE values and for entries stored in a PTE >> table, so pte_t * does not distinguish a pointer to a software PTE >> value from a pointer to table storage. >> >> Introduce hw_pte_t as the generic name for a PTE table element. Define it >> as a macro alias of pte_t by default. When an architecture selects >> ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead. >> This preserves the representation while allowing converted architectures >> to enforce the distinction at compile time. >> >> Name the generic wrapper structure __hw_pte_t so architectures can >> forward-declare it when pgtable_t must be defined before the generic >> hw_pte_t typedef is visible. This avoids header-order dependencies. >> >> Keep the C type definitions behind an __ASSEMBLY__ check because >> architecture assembly sources can include this header indirectly. Include >> asm/page.h so consumers such as linux/vmalloc.h retain the page definitions >> they previously obtained from that header. >> >> Signed-off-by: Muhammad Usama Anjum >> --- >> Changes since v1: >> - Name the generic wrapper structure __hw_pte_t so architectures can >> forward-declare it, and explain why this is required. >> - Use software PTE value terminology. >> >> Changes since RFC v1: >> - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition. >> - Exclude the C type definitions from assembly sources. >> - Update the description for the new opt-in model. >> --- >> MAINTAINERS | 1 + >> include/linux/pgtable_types.h | 17 +++++++++++++++++ >> mm/Kconfig | 3 +++ >> 3 files changed, 21 insertions(+) >> create mode 100644 include/linux/pgtable_types.h >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 2133aec4a2004..da60a8bdcddb5 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -17140,6 +17140,7 @@ F: include/linux/mmu_notifier.h >> F: include/linux/pagewalk.h >> F: include/linux/pgalloc.h >> F: include/linux/pgtable.h >> +F: include/linux/pgtable_types.h >> F: include/linux/ptdump.h >> F: include/linux/vmpressure.h >> F: include/linux/vmstat.h >> diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h >> new file mode 100644 >> index 0000000000000..07da05d375c2c >> --- /dev/null >> +++ b/include/linux/pgtable_types.h >> @@ -0,0 +1,17 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +#ifndef _LINUX_PGTABLE_TYPES_H >> +#define _LINUX_PGTABLE_TYPES_H >> + >> +#include >> + >> +#ifndef __ASSEMBLY__ >> + >> +#ifdef CONFIG_ARCH_HAS_HW_PTE_T >> +typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t; >> +#else >> +#define hw_pte_t pte_t >> +#endif > > I would suggest to provide __hw_pte() in this series - it is needed > by architectures along with __pte_from_hw() right away (as opposed > to when lands in arm64). * __pte_from_hw() is added by 4th patch in this series. * __hw_pte() was added in arm64 specific series. But it has been dropped because of [1] in v2 of arm64 series [2]. There is no user of it in my both series. Please feel free to add it if s390 needs it. * hw_pte_val() was in arm64 specific series. It has since been moved to generic series in v3 [3]. [1] https://lore.kernel.org/all/86d4aea6-4272-427e-9229-295489e068d7@arm.com [2] arm64 v2: https://lore.kernel.org/all/20260922-pte0_arm-v2-0-a3f1ddff0a8a@arm.com [3] genric v3: https://lore.kernel.org/all/20260922-pte0-v3-0-5670b8cb9059@arm.com > >> +#endif /* !__ASSEMBLY__ */ >> + >> +#endif /* _LINUX_PGTABLE_TYPES_H */ >> diff --git a/mm/Kconfig b/mm/Kconfig >> index c1ddf59c0d71a..5f462ec6fa5e5 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -1312,6 +1312,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled" >> config GUP_GET_PXX_LOW_HIGH >> bool >> >> +config ARCH_HAS_HW_PTE_T >> + bool >> + >> config DMAPOOL_TEST >> tristate "Enable a module to run time tests on dma_pool" >> depends on HAS_DMA >> -- >> 2.47.3 >> -- Thanks, Usama From xen-devel-bounces@lists.xenproject.org Wed Sep 23 13:48:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 13:48:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430734.1653242 (Exim 4.92) (envelope-from ) id 1x9NKJ-0001iC-Gw; Wed, 23 Sep 2026 13:47:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430734.1653242; Wed, 23 Sep 2026 13:47:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NKJ-0001i5-DP; Wed, 23 Sep 2026 13:47:59 +0000 Received: by outflank-mailman (input) for mailman id 1430734; Wed, 23 Sep 2026 13:47:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NKH-0001hv-Tc for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 13:47:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9NKH-009IkH-6o for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:47:57 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3d882-8faa-0a2a0a5109dd-0a2a4503a284-24 for ; Wed, 23 Sep 2026 15:47:56 +0200 Received: from [52.101.66.1] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3d88c-fae8-0a2a45030019-3465420129eb-3 for ; Wed, 23 Sep 2026 15:47:56 +0200 Received: from AS4P190CA0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:5de::10) by PAWPR08MB8792.eurprd08.prod.outlook.com (2603:10a6:102:335::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.4; Wed, 23 Sep 2026 13:47:48 +0000 Received: from AM2PEPF00070CF5.eurprd02.prod.outlook.com (2603:10a6:20b:5de:cafe::aa) by AS4P190CA0004.outlook.office365.com (2603:10a6:20b:5de::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.13 via Frontend Transport; Wed, 23 Sep 2026 13:47:48 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AM2PEPF00070CF5.mail.protection.outlook.com (10.167.242.7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Wed, 23 Sep 2026 13:47:48 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) by AM8PR08MB5729.eurprd08.prod.outlook.com (2603:10a6:20b:1de::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 13:47:13 +0000 Received: from VI1PR08MB3421.eurprd08.prod.outlook.com ([fe80::e079:6bd:fbe0:89b4]) by VI1PR08MB3421.eurprd08.prod.outlook.com ([fe80::e079:6bd:fbe0:89b4%3]) with mapi id 15.21.0451.012; Wed, 23 Sep 2026 13:47:13 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=xVAmPSLiYLnLev2DhHQ9TtJw8jKZw9m7w5nahE/Itl7itPrHLfwlp9A3ddv0ZJhEdrS0Rg/xj9aZtLxnW0mRHfbh6QmkMQNivga4WaI/DzbMHnVXRQVmNxoAKEiKy9QTm6mteEtKK7h3XERqOpPfh++Xr9yiQ1UWs4scmKmTpp12ZP2q9UUZyPRtmjQ3um8EWO838GVv4ms15+PB18emdWhveyO1F1uunSKIC+Iq/2WjFTx0RScewtF/SGhZc0NYhT+F72RNqL7arIExReA+0wF7maShJHSacgwgSmVu0oEWo8p74GM31HSvT1VGBRDzm+nkRX0CZPOP5ST+ux2cxQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UhJoI7Wuj8ebK8ZsC9lfG+NOdXn1WH2SV3Bha+yEvZU=; b=PAmCtE2cShg8Gq0RF73Ksat5UuXYRnvD+u+aC3UeQM2BCAJxOa6S+/Bjttf5JUtbNrOm+XR/A+pLHlG9Et26mPQOq+nmqXVnW5s6dhQYFvlujPVimwWcDvDxYPlGL5Hk0NuQOKcCBMYRGfpJb3Gh5GGZ5/D2XxJlWxda/MTkcjjtPYBv7kND0krjVzT5dVX4pw6Duwpa9CVveue6aUoatxafZ4dBbypn5h+bMhT1E64wevsJ3a+BPHNFHm500jkVppyfvkOBY1s0+DqC0ENe9RJWJ036JvsEK2sgdXeiYzCoEodFlveByoGyapmRUWpv51bBCo5aQaxZQ3QxVM4qYw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linux.ibm.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UhJoI7Wuj8ebK8ZsC9lfG+NOdXn1WH2SV3Bha+yEvZU=; b=CEAnJKHdb8pQYooTKptKnU5SRdLbDsAEXe4zpgonArlQ6IOgiZ/8YIcavCracvPOjQpwUG6IDxmkMRotOFU70VAs2tvEkbWl2CDlFoaYztnWgG1xGsH4yIaMIWIcku6xHq/1Jugkyrr5fMSl5MLqGbPsNAIWqIzXCdK5hRAzHtM= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ickhjXQUhKmKADyKvpX2SLen/DlJScYm9DJfnqtrT0vB5PCb170fHF3jxmOwNXlRzLUSbUuP1wAziagOgnSFGBjCttrrcFfENX65D8i9dP+ln8RQFfeUzG89n8fu/T/UzZma7+gknAH7MSvM8CLP3W63eC5OYD2IYMiWpiFMa3GM4gK2IX7P+ViaJ76swrL1VFmYumr4i47G28whFE38tD9IZ53B8tYhTEhi/T7VIrp7Esksf+puHqaCYgApPb54POHoYBpshiTFtg8tmqc20JN+oFZbq29vtym7n0NrIl2UoeLrwRJC6oVTX7oFwtYfOFa+a20xFRBPl2pL+xlMiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UhJoI7Wuj8ebK8ZsC9lfG+NOdXn1WH2SV3Bha+yEvZU=; b=vu4VSN3RqZb/Vcgwz/Wf9VmAAobBhpMEKFhHyr95Pjgw5OIiRPvvaQmdoJHZVLoLB52Nl7Jid26+nwpGAnFX3Zu5E6Fv23fp2XSMp4vtChySpfU3S9aMBep1Vb7KV8GRW5VuzCZDi4l/32O8rKO58Z1TH7/oEc1sON60J5QjSGVGbcqfCrvSy6efxkpmT55txFhjgEHEcigFViy3srFQ0r51h5ybwODA0eJ9pF1vAXgV4EQTrIL3zjWfh36yEsgPxGy7P9Ht61jsn37Mmx8JHPQVqoqLpDTx9xQc9sFoH5nzkmZyH3mjkF1kQHQPclrH7u3xww14apmPa9K0oBtPOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UhJoI7Wuj8ebK8ZsC9lfG+NOdXn1WH2SV3Bha+yEvZU=; b=CEAnJKHdb8pQYooTKptKnU5SRdLbDsAEXe4zpgonArlQ6IOgiZ/8YIcavCracvPOjQpwUG6IDxmkMRotOFU70VAs2tvEkbWl2CDlFoaYztnWgG1xGsH4yIaMIWIcku6xHq/1Jugkyrr5fMSl5MLqGbPsNAIWqIzXCdK5hRAzHtM= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Message-ID: Date: Wed, 23 Sep 2026 14:47:08 +0100 User-Agent: Mozilla Thunderbird Cc: usama.anjum@arm.com, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values To: Alexander Gordeev References: <20260903103002.1091859-1-usama.anjum@arm.com> <1401e907-04ff-4ee5-ad03-00d88531a091-agordeev@linux.ibm.com> From: Muhammad Usama Anjum Content-Language: en-US In-Reply-To: <1401e907-04ff-4ee5-ad03-00d88531a091-agordeev@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PA7P264CA0091.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:348::10) To VI1PR08MB3421.eurprd08.prod.outlook.com (2603:10a6:803:80::16) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3421:EE_|AM8PR08MB5729:EE_|AM2PEPF00070CF5:EE_|PAWPR08MB8792:EE_ X-MS-Office365-Filtering-Correlation-Id: 45d622ff-62f2-4780-4429-08df1979413c x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|7416014|1800799024|366016|23010399003|10067099003|56012099006|11063799006|18002099003|4143699003|22082099003; X-Microsoft-Antispam-Message-Info-Original: er1QZE7t/U3keliySsRiVAPvYcTdlk2LDXtXoxCQiX/p/iuft5DFC6Hg211hZb0NWQwvMx9IUr76nD9aJUEw77Mote6K6GncWOChMqvI1mvAdPiuFtY7C8ycOlKNYQ1tlEBYn1u1K/U0k6WYfHH8R9ubi1rj7q/KBa+aCM7tPa+BrOAUYCQuzhK4rHTtfI5dsJmYjVdU5NX+nPgICeyXE/qyix3tFyt8G5IoWrTWWFjVB7+b5rbKPsLN+kuBxibKgO9CMVu62dGdE+/EO40XuvQGsUBKik71rer8bglW18v0Hu2rF7C1JxLla1p73iaseziW1mjUv1m3YExgnIIMl+YIhaUOC64dFjPaeqkNJuKmYJeIDoG3g4wXQrYkck6UDnuAXxx3/JoD2gQR+ruheEguivjEq7VUX5QFYAwVdM6H/5ZHufLQqlO57DMlRyvVDUlvzJogbPkIWPJkJPrUDipq4nDYlgZ80fmDOpQ3NC1GqHaBk4DBDE2YgXlP6ZPPIBZwWetKZuNaLVhqTNtBrf0o+Xt6yHnVRPgEIBuo8lpAhYP1Geok+PounKdZ6Dt/kcTPVM6opmbIjL5lpa7vxzvMWlR9fG1NNwyvvz79w14YiI735TKIMcv5NJf7vgmk X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3421.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(23010399003)(10067099003)(56012099006)(11063799006)(18002099003)(4143699003)(22082099003);DIR:OUT;SFP:1101; X-Exchange-RoutingPolicyChecked: iITv+pbcilPPsUiFk1ljo6e+oEJjA5GQCrka1p5aoy5sK5/YpMHzwUzjve+/D+zQXB6T1hlApHgCWb4Fl6E07hSm463PAuBWWM8E8SJ95bMwPp9IZwnx5wy0gk6CrZWd6dSZPpZc/zVzXW7s4wtmsuH2SKf/pikvXU4rLMkejhus34n3qKxApBaHZ0aMPXv9HR1pDnmOc1Mi0f5FM1pN32GHc6thNsrNjHfOBDs4lij2vZbPDUDh94hF1ZWJZHdjQUMerPNjoAX1yhxuh6zhB1ZPQW9M7/qXajnBALmMcnt2uH9RaIili6VIXZCziCKY8yjahJb/qe3bqcLthGwBpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5729 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM2PEPF00070CF5.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 43bfbc74-461e-4eb7-b61a-08df19792b6b X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|14060799003|36860700016|82310400026|35042699022|7416014|376014|23010399003|11063799006|56012099006|10067099003|22082099003|18002099003|4143699003|13003099007; X-Microsoft-Antispam-Message-Info: 0nVzaqRCcwMQ8CdRhEaC0+RTEHiFGDLJPjsvwKood6BdkpPo+vQrjbWt6LFO5G1N9Duy1aqGPzuuGHjwoeFovHL2F9FsQ7N2BqkVTz4DwNGeuHQlhV5XSUOMn/jh4Xt+dLSAuldkFi8OM3Xut0TUhAZiX/JhbWftVGf0yiEX4uuDQiuBbww8SVTsM3yxFXnHDlmBEf4ayMKB7K3COkpuOgPMB8REO2SB9ncGXZFcpsL/n8IZLNmxpCp0ynFatETxLlF/YO7FwwBO44ywqakOPvjpsssVsCxrrNd9VHcZ3ca4sdEbg5x7/UFveJJpzlcE+3OYplxTSkrt22qP2bG8OZ6EifmOHSQ/oPl0I8eqtngsGBlSScI1MMavOlaRxkDTBnlrXY1lRhUw5xwd5nx3a2eD9NIofTwBay4SjJbLkbhTXSeAu3OKwFO76U76bnkqCdKflAt2VYBm6UMQ1gKPKyFWzGz5bC6rS8gLML3oIv0F7WLk1/y82UOSIoL3V4w1dD/XnnEF56nV3MvTvw+oBB0xAWQPwQgXqv0pp2k6BcY4QW5Qvn1Tmwi8WGVrkItE9vm02nUsWh+fAq4pOZGPOlIMUSiKS24f+shaIYLJAmyHT5O3QIZ/6QiY3GAvlyGgG3htLsu3BP8pM61oXRgHw7njFUF1eyXenO6LOP5UyXQ= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(14060799003)(36860700016)(82310400026)(35042699022)(7416014)(376014)(23010399003)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003)(4143699003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: XBUBjUrkRjw5NPzuCqTd1jGPyzhLOg4jg+KNMXJYHzBsXChrizCFSp/4hIZDhirOxsFzr/P9HKMMQnSScOiuIvrgEzw96cF4mKLr7XM7SBYkyr33RJ/DyKYc4dss8BWk+ly3x1C/OhurLXcHuFzM7fZWYyaJr/NDcwer8uzzdODab/rz5DhR0suxHwufBS3WGhxctV3O2nuo9yL+4AyrJxg+yXxaeSXaZEJTYHvx3BK3SBcxEF6uRHvmfXLfWpHDW1rKK0TmYx5eZNMZLnZeHxlssGsBKIxubSOpSBZ1j/Hh4tY28UAtGu5xAF7pHWE0fDz+otk5g9gdmzV2ufHDKa0y81qq2FJg+3OjPUThXMIO5kplRg7dashW6IXHz1oy2J5V+e6ZugK2SwoCDx96fHxlapQxQlgxg51bX0PrVYCQKcp9gd6PhMNVwIevCkU2 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 13:47:48.5548 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 45d622ff-62f2-4780-4429-08df1979413c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: AM2PEPF00070CF5.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB8792 X-purgate-ID: tlsNG-33051d/1790171276-6C2E04E9-B7D9C0B1/0/0 X-purgate-type: clean X-purgate-size: 970 On 23/09/2026 1:25 pm, Alexander Gordeev wrote: > On Thu, Sep 03, 2026 at 11:29:52AM +0100, Muhammad Usama Anjum wrote: > > Hi Muhammad, > >> I've the patches here [3] for arm64 conversion which I used to find >> usages in generic code which I missed during development. These would be >> sent separately. >> >> [1] https://lore.kernel.org/all/6110202c-057b-4701-8c04-1a76ee7bb9ab@arm.com/ >> [2] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com >> [3] https://gitlab.arm.com/linux-arm/linux-us/-/commits/pte0_arm > > I checked [3] with s390 and also against our lazy mmu implementation and it > looks okay. > > However, is there a particular reason this series is against mm-new? > Should it be against the master, it would be easier for me to try it in our CI. I think, mm-new is the branch in which this series would be picked up. This is why its based on that. Are you referring to mm/master? -- Thanks, Usama From xen-devel-bounces@lists.xenproject.org Wed Sep 23 14:20:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 14:20:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430766.1653251 (Exim 4.92) (envelope-from ) id 1x9NpD-0007d1-2S; Wed, 23 Sep 2026 14:19:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430766.1653251; Wed, 23 Sep 2026 14:19:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NpC-0007cu-VO; Wed, 23 Sep 2026 14:19:54 +0000 Received: by outflank-mailman (input) for mailman id 1430766; Wed, 23 Sep 2026 14:19:53 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9NpB-0007aC-Nx for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 14:19:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9NpA-009PQt-ON for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:19:52 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3e008-e002-0a2a0a5209dd-0a2a4501b32c-2 for ; Wed, 23 Sep 2026 16:19:52 +0200 Received: from [148.163.156.1] (helo=mx0a-001b2d01.pphosted.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3e006-5984-0a2a45010019-94a39c019666-3 for ; Wed, 23 Sep 2026 16:19:52 +0200 Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68N8Zw1U1031879; Wed, 23 Sep 2026 14:19:11 GMT Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gske1useb-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 23 Sep 2026 14:19:11 +0000 (GMT) Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.18.1.11/8.18.1.11) with ESMTP id 68NCp1Qt007936; Wed, 23 Sep 2026 14:19:10 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4gvbt2s7yt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2026 14:19:10 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 68NEJ8X148628044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Sep 2026 14:19:08 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1776520040; Wed, 23 Sep 2026 14:19:08 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5C68F20043; Wed, 23 Sep 2026 14:19:07 +0000 (GMT) Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown [9.224.92.206]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTPS; Wed, 23 Sep 2026 14:19:07 +0000 (GMT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=pp1 header.d=ibm.com header.i="@ibm.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=2QrGt4Pc68eDNguGqvx9OXhAmFpd9e Q/n73e2TGYr7Y=; b=Ayo5EVpsou0Bg5ugqBjm1S51XWE2MeL2ndK2c3GelXo1lK 5hqPlah33xvQY5TiqA2OfPyJI1ZfTumV1sglYPdZ7J+lNyzWArp/be+tEWybqdm3 7Ve5yTDM8a3+Wg9738uiD6xhWxhhylckW5ZqezRi8Cc9Q5AEunEWV7aQhM7NO27B Okbrx6sv1HOopcrolJiHRaZ338lgyLIYvzb9FxdGj5pvFeSaKMzAE4F41qbtjSQq AV2hzyIV7EIC4N8FA7xw5n0/wfnzR+ZzBswzL4IaeXJmPTTJzIuRCesqj3zRD8qt +Z1j6e4HHxla/ubKARuqvWe/47TX0HQ0l8xHnmJQ== Date: Wed, 23 Sep 2026 16:19:06 +0200 From: Alexander Gordeev To: Muhammad Usama Anjum Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , "James E.J. Bottomley" , Helge Deller , Juergen Gross , Stefano Stabellini , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Andrey Ryabinin , David Hildenbrand , Pasha Tatashin , Chris Li , Kairui Song , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , Leon Romanovsky , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Mike Rapoport , Johannes Weiner , ziy@nvidia.com, pfalcato@suse.de, ryan.roberts@arm.com, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-parisc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev Subject: Re: [PATCH v2 0/8] mm: distinguish PTE table storage from PTE values Message-ID: <5a0c73a1-6875-49fc-8f85-28808cd6be19-agordeev@linux.ibm.com> References: <20260903103002.1091859-1-usama.anjum@arm.com> <1401e907-04ff-4ee5-ad03-00d88531a091-agordeev@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: jvicsneNpoTmGgGlWjYDZudGR7T2so9J X-Authority-Analysis: v=2.4 cv=EOCTQFZC c=1 sm=1 tr=0 ts=6ab3dfdf cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=kj9zAlcOel0A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=m85HiHUexkU1pPaUjCgA:9 a=CjuIK1q_8ugA:10 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTIzMDA1NiBTYWx0ZWRfX9B/05+SWggVO 7agvUqd8dhoypg0FPuJExRBm8O+PxCJzpiY8LotmGeU/DhT6/xu2/Uj3hl/SR7hiQoNSed7OI9+ TYVYgcC+u3rRF7SNRXDHxINKwsUMnTo= X-Proofpoint-GUID: jvicsneNpoTmGgGlWjYDZudGR7T2so9J X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTIzMDA1NiBTYWx0ZWRfX4HZcFdO5tIXY snGn2A3Db+S3OG1OjdgVbfGZEGUTHcIaKBobABDkMlLHsfwV9fFr8s4ZCTnpAdQPz9gYCpcRvNL meevVhPsIY2xb+UjLfiuVZTJR5I9Zgb+lOAD2ZqjDqXobpTi1VgByCxa+Ljb1FmoZoT62x64nIQ fdbmdyOp5uOBulJ9CpL0SOdFeWBnq23WXXdkmA4qDJBSelEfQbx6eUpb5+qNjYHhR6WCsLgthO5 OBtuzT2aI8D749f3QJiK8fKsdS96je+rKxtHth8BGDr1UF7hBJcUQiLfUmB5WMY7DowN0JvY/Jx 4rIY70z4mFoa/Tic/6RAu9AhrTMaPpFzTTPwaqBT8FJxQwKV98aap20VP54g4vtUBeIGWlNiLHY vnukgu+KUPBn3PwkU+WliZg6ZldU5ChvdsqyiDG96cfqv7YaCvZMLzqxSd3YW2i1WLbfmVoGiqY oe0K7aX7lcrg4NwlsCQ== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-23_04,2026-09-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 priorityscore=1501 clxscore=1015 spamscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609230056 X-purgate-ID: tlsNG-d62444/1790173192-1E07B757-7558B9D8/0/0 X-purgate-type: clean X-purgate-size: 488 On Wed, Sep 23, 2026 at 02:47:08PM +0100, Muhammad Usama Anjum wrote: > > However, is there a particular reason this series is against mm-new? > > Should it be against the master, it would be easier for me to try it in our CI. > > I think, mm-new is the branch in which this series would be picked up. This is > why its based on that. Are you referring to mm/master? No, to the Linus master. I will try to backport it and give it a try. > -- > Thanks, > Usama Thanks! From xen-devel-bounces@lists.xenproject.org Wed Sep 23 14:37:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 14:37:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430809.1653260 (Exim 4.92) (envelope-from ) id 1x9O6N-0006Mb-HN; Wed, 23 Sep 2026 14:37:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430809.1653260; Wed, 23 Sep 2026 14:37:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9O6N-0006MU-EY; Wed, 23 Sep 2026 14:37:39 +0000 Received: by outflank-mailman (input) for mailman id 1430809; Wed, 23 Sep 2026 14:37:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9O6L-0006MO-Vq for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 14:37:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9O6L-00BeHO-3J for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:37:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3e42d-bab6-0a2a0a5309dd-0a2a4501db9c-6 for ; Wed, 23 Sep 2026 16:37:36 +0200 Received: from [40.107.200.62] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3e42f-5984-0a2a45010019-286bc83eb03d-3 for ; Wed, 23 Sep 2026 16:37:36 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CO1PR03MB5826.namprd03.prod.outlook.com (2603:10b6:303:9f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.17; Wed, 23 Sep 2026 14:37:27 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 14:37:27 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Mk6EmlHme4d7QuiKzZFEgXXgyr+Jtzp802UUrskyYAhuRKUKZwxxhDxseSl3b7RNf2yWAR9Ls0loFNDUeuw8FV3Dn4ryECbTx2mZqN4K1Z13b1OhIyVy6wbk/Yui6SVQiZizJ+uddi/4a9TR7UYrTCvpudtLXvZULzqxVYU3Jwf8n2VP2I8n1nJDIClIJ7kA30uLYEEe6kwkQhXjmkgF0yiLB5bpdUmG1eE529RE8t+/U00HxIUK/XHVS2VyUPsjyMcEB2aBo+fF+hYvh2bGfzRZds1ua1pwOr97MBL219wQ3wqLv229BV+ve90lk1ohy1w1kSquQvPtYquxGySpSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wTO4s41TL6DXseZuSSKT4rCXXUTREqY6kYM3Ro3m/9M=; b=adLsNpiMJKPniLuu0G3cxx0hY8BNoUKU7Oy8VMU3YCupkUQyAsTTEuTTMck7Dsn68suETLymoKxYaPEe69ooF+rULTyq0FJi2hQRnpMOn2Aw5QNkfpI9mqAGtoKseON7+oJL1lXzsKLHMCTkOW1PiKfyyi6iIqQwplzGzyhmMA7qFnYPHMc3F6nEELlmieqWvTqf7ppIrY4Ry+6scj5LC66Qe2kIs1lPRmi0e1N5mCZjaOegId6VlDKIdTOPsJyFaBmdvqhfSJ+3FeAofy1UTxDJJf/VaSqpuTUEPOmGd7hI4L+RoCvTHBhc34ld0N0JBC5UI9W3RpHogfCE2kMz1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wTO4s41TL6DXseZuSSKT4rCXXUTREqY6kYM3Ro3m/9M=; b=GeY4MoMBx0CK+y7V1Gdjb/lbJGRr9ysHmOJVIKkfoj1CYHiP43fLpE+iikwWXLA87wxE4BwPEhautrrT78YmJlXE81XVEXgTVkac0+HjzmoKMAQtwznUtQaGluDdrMTHMNbaFpg3Tp+q07eu257Wzhj390RAInfp26hB10eEIl0= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <66aba455-6005-45f7-b01b-ad0e58ff7579@citrix.com> Date: Wed, 23 Sep 2026 15:37:23 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/svm: Fix VMLOAD/VMSAVE state handling when using nested virt To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260911151250.1232332-1-ross.lagerwall@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0501.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::20) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|CO1PR03MB5826:EE_ X-MS-Office365-Filtering-Correlation-Id: 30eb4a67-d182-4d63-9a43-08df198030ac X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|18002099003|22082099003|56012099006|11063799006|10067099003|4143699003; X-Microsoft-Antispam-Message-Info: Y96eu6+sap9m4C1zhR+mYBQCrUUXAW6//x3BMbfRVAiiJMuxbriaegeFdMeBxrQJLOkqIgJESy5AbYTWXtOY30laS8wVrkUwsa7ViekH7vuO5yQ/P+hIyFFdO9jdQgYtKPoOTKSgr2SQ3Ny5ZM9LSAwl/gkTI5nsZR/Q84uQbPpIX8z0jgXJgpuQ5esug46PzOlr+Fl5iJM954DxNzR/39+fRVDD6A4N7XblAvke9i+smFXyPzXfk/Ztyhl0cYDYFJjN2+CGJUScaApJSL2vBVG4qzQmLupt9B+NS+erQMVQYsflsSnT8l36R/e9wX2Ru3VrRRHobbOmG4wvvDhBr0gDUjxxZSN5tN1Y0zOqrlYpwnGslJC8VIZpocn84GrpQ9QjLK6BYVPjAcw8joVBXkma41bjV53LZHM95ewKALAvGfWtmRZ/pugy3nIBJXODswQLTZjknUNCVWwY7+h6QTFzLHdLDP1gke8F6wygKKjO27otweQHXJTGTo0HVeAEYEpzKV3NZDGUODKn4NELEzQpsQkTCvCf6DhztH0urKpoXfZ/s56ZE9Cmez6RmME2r1RtzOnifHah9yViYv+D/k+sMwyNW1qqU5N1uHG0W0WXjt86YMHzOqTgYd8m5+nTRat3a1SHwIU17WOa1bABjF+MapvpEU5OYnBKAPjFxKQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(22082099003)(56012099006)(11063799006)(10067099003)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VFl5ZVdYaU5SenJrK29zZCtCQWFjQ1l2Y3RXVnVwUTUvS3VidlM1OFZtK3c0?= =?utf-8?B?aXNaY2krNEpJZ2M0UE5KYkVuVlFQdmtsdUpSa1hXK3FlQkZ5Q0ZyRWY3dnNu?= =?utf-8?B?QWc3Q0R5SjkxbDN0OE1ZNjA4VlNYbjJVeFJ2UGVramU5VS9taExIK2hLTmxp?= =?utf-8?B?N3psa3F0V2k5M0Y0N2tydGRCNCszeWUwWWZMVW9GY1cyRXdnYkMxZ3NMMVFz?= =?utf-8?B?Q3Q5djhaQjZCdjV5YVlzYzJrS0ZkeUNqdmFTZDVkTktibjhuRThCdlk0Wm1L?= =?utf-8?B?Z0w3MlRNTTlwQkdKU3Zvb1c5UWtsQ3Jsb0pVWFNST3pVWVBENlBhVENiS2ls?= =?utf-8?B?RDUrdFc5UUZTbC9JODRSVlhaY2MyL0hvMGMydDV6dXMrZkU2WnpURlB3UUpF?= =?utf-8?B?RFhwS3poY0d1d1prMHlETStqa2RPUmxTYWFtTlA4Tk4zS2F5RGU1VDlHN1Zx?= =?utf-8?B?S2dueTR6c25vQ1VGMjhXWnlISXRyOHA5NmIxVnRUbENtWWRnZWw4a2R2STJO?= =?utf-8?B?Y1hBeWxLTjNoK3dIUXFuYzB3L1hsSlI5VkphT0FZTDVNZzRJZUMzVnJrUktV?= =?utf-8?B?WVJoQ0kzRkJ4RWkzV1BEUzR6MSt3Mit6SmcrK0RtdkFOSGlaK3UvTmZOUHdj?= =?utf-8?B?eVUxOWhVcS80L0poUWhPekpRQTBzdUdERE0zZTdtZkc4OE9YUHU1RTRtQ2ta?= =?utf-8?B?cEVUaE9FMGRNWEh6S1l3a3g3SGlpUTJNVUJ0cytuV1BnT1hKb0J5a2ZlVU5y?= =?utf-8?B?T3RUa3J4MmRFOVg2a1hxd1JWbjNabE81QWsvOWFGN3ROY2ZtN0g4c0d6M0tS?= =?utf-8?B?SG1UQ0F5SzIvV0RIQ0p3MHZUM2pKUndyOUFLQnhsaDNDY3dNMHdSTEFQODZm?= =?utf-8?B?ejJOVGFHcVJTVU8wbzlHVTdEV2c5YWRWUFVyZDdabjl0S2kwT1JUQWJGMlp5?= =?utf-8?B?QWlUMmloZC9lbzBlVmxhS1M0bUVHaHZaaVBHSHpRY1B4Vk0zZVk5TUJ5RnA4?= =?utf-8?B?dTVrUzBzZExkSExTL3h6RkNOdEcyYUJqcTBYcTRnRThQaVFLTjFPVVg2dFhi?= =?utf-8?B?ck5Fc25ZTGVYVWg4a0NKMHVGeUhxQjZaSzU4ajZjaERWSzdYdVZwYndIeEpZ?= =?utf-8?B?VFJNNHZGMHdHWElwQVI1cWNVcUxmWjY0ZEtHdkhOMjB5Rnc3VTJLTlM4RzBo?= =?utf-8?B?TmZoYUR2aE05VWsvQWlFekRDYmdSTWJhMGpMenBta3k3WUZGYzJYY1dEYzEw?= =?utf-8?B?SFh0dzkxNHJ6M2lEKy9xNHFqdXRlZFpteTV1MjlhWjhIbHkyem41YVNIVW92?= =?utf-8?B?Z2ViRldrK2wwRW5XNDZOczBha2t5NGxBZ2pnNGlYN0hiRCtMZGxHMzNNS1c1?= =?utf-8?B?Sk9UWnZtakdJZG9tYzZjYS85czlaR3R1NTZBR2ZYQ1pTM0k4N2EwSEM5dHp3?= =?utf-8?B?QzJGcHpmWXkwSzJON3pzMWdKMENIWjdhOWVPcTdTKzVvSjRUNGZ4aVhsVkQ4?= =?utf-8?B?cXhnSzl1Yys3MkN1YnRwRDVSMThwUjFyYWNOY1Evc0JtV1VTVjhFUGVCTGlX?= =?utf-8?B?N2NNTGJYY29qeEJWQ3FvWWZYaUhFRVpJOHByMnJGRkhRbEVDbXFyc1J5d2JX?= =?utf-8?B?WkFwTitVazQ5TFIzd0kzRG9hTjY1UXdkWW9SbVlBZ0dxL0h0bm91NENGKzdw?= =?utf-8?B?cTZPYzZrRXhXNnlhblhzbmdMTk5qRkhZcVBIeXZENEJmaCtiOS9VVDIvWEtj?= =?utf-8?B?U09ZSTU0NUVBdC96SEtvU0xaVXF3SDB1cVdqck1uK29sSG9iNm1DVkRCQnYx?= =?utf-8?B?L0RGMUdCQWhZMFlrSklaYm43L3NLNXlCY21nVU05bTBvcEp2SVBtRndDK3pV?= =?utf-8?B?SUNEYmFsTUtiYTF4N1kxZUU5UE1iSW1RNS9kWWJtWVFha2V0WmxUclNrNlRI?= =?utf-8?B?UzMzaUtGZDAxbmRjWERoK2lqamI4all4aHBmMEt4b2ZKeXUrd2ZRVWJCV00v?= =?utf-8?B?bG1EL2lJZnJmYkFuT0xHYkpITENEcGpuRHQ0Y1pYdzZwZEc0Vm12dzBYYU1M?= =?utf-8?B?RTEwRHFhUEMzN2kyV2tHSnF4Z1YycVVPMFM4bS9LVDdNck5aMjdSeWdFYVRo?= =?utf-8?B?UDIxYjVBejNZb3pvWkdLTnRHdVY1aTNiRElDKytmKzFCWG5ESC8zYzJ5WTRr?= =?utf-8?B?dFVrSG12Sjc1WHMxRGFRYlN0WDBXUDhlMmo4Vkh1Y2tmUlRqYUMzcmNObWc0?= =?utf-8?B?S2IrVGlwOXhXbmhPS290Y1dVSlBVcHV0UXhOVHpmZ3QwNHI5OHQ0WnhnVHMz?= =?utf-8?B?OEZCR2JUSDFUanBOV3F6TEFBMDJuUVB0RFFua29sRFZhZkRySU84U0wydTZs?= =?utf-8?Q?9xRB0gKPTW+5G+pc=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30eb4a67-d182-4d63-9a43-08df198030ac X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 14:37:27.4835 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 6YaJDMEGrbplKotJhaFiHg+kK1wRRrgDsm5EymEo0p0bdHycIljUbmsX6G+SMhPu8FkFsSj54iMk3U0Q66ZJmmMmGliPTieWHLSZJvgv3z0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5826 X-purgate-ID: tlsNG-d62444/1790174256-C5341757-FC0CD747/0/0 X-purgate-type: clean X-purgate-size: 1317 On 9/21/26 12:21 PM, Jan Beulich wrote: > On 11.09.2026 17:12, Ross Lagerwall wrote: >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -444,30 +444,30 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) >> >> static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) >> { >> - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; >> + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; > > Here and elsewhere you assume that vcpu_nestedhvm() is legitimate to use > even in the non-nested case. I think that's heading in the wrong direction; > I think that a hypothetical mode with CONFIG_NESTED=n and the entire > struct nestedvcpu wrapped in #ifdef CONFIG_NESTED should still be possible > to put in place, without meaningful rearrangements or renaming besides the > adding of the respective #if{,n}def. This assumption already exists, e.g. see svm_create_vmcb(), svm_destroy_vmcb(), svm_dr_access(). If you would prefer not to introduce any new cases like this, I could introduce a new macro, e.g. #define vcpu_n1vmcx(v) (vcpu_nestedhvm((v)).nv_n1vmcb) and then for the hypothetical CONFIG_NESTED=n, it would resolve to: #define vcpu_n1vmcx(v) ((v)->arch.hvm.svm.vmcb) Does that work for you? Ross From xen-devel-bounces@lists.xenproject.org Wed Sep 23 14:42:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 14:42:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430822.1653268 (Exim 4.92) (envelope-from ) id 1x9OBR-00010W-3M; Wed, 23 Sep 2026 14:42:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430822.1653268; Wed, 23 Sep 2026 14:42:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9OBR-00010P-0m; Wed, 23 Sep 2026 14:42:53 +0000 Received: by outflank-mailman (input) for mailman id 1430822; Wed, 23 Sep 2026 14:42:51 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9OBP-0000z7-68 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 14:42:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9OBN-008CEH-Gp for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:42:49 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3e559-bab6-0a2a0a5309dd-0a2a4503cfd8-28 for ; Wed, 23 Sep 2026 16:42:49 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3e569-fae8-0a2a45030019-4a7de14cc6f1-3 for ; Wed, 23 Sep 2026 16:42:49 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485933b24c3so721368f8f.0 for ; Wed, 23 Sep 2026 07:42:49 -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 ffacd0b85a97d-488682668e7sm8645448f8f.4.2026.09.23.07.42.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 07:42:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790174569; x=1790779369; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=Xf/8F/jpH1WySL88611CaOE19J/J3pLNy+jbpjItYu8=; b=NXBxIAzaxwRUSgWML3uS2KygM9Bd/YY35PoGfpuV0hc2gfIacxBVAVyu3RCSwTEz7r EoAfnR5df5+VosbgERnqtIq/XEFK7psCWzmwe21ZKm7FHQ9l+gGtGC71k338RL9QZann zCWwt7OqLktarV0NUjGJMNnq/gcG4XsPAgqNKpFP2XZEC4Jy7WWQsmvGqtpJo7rFHi7s xJzOqAeDKRFjSLxFzzYsl/0P2wkvz+2FGIPBBku/a4CXbIF1inpIcc/6jSBB865VTNyd VnFpdInbYrB0wOqCsVYaRVJDo3FKsKz+AkqOA2h8wtVeGBiTfWG1BMrblc8K2hGVeTDL AJCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790174569; x=1790779369; h=content-transfer-encoding:content-type: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:content-type; bh=Xf/8F/jpH1WySL88611CaOE19J/J3pLNy+jbpjItYu8=; b=oFAyIYzihGfrrpw3pC6Trw43kSZOVbG85YMEoMHixZ9L/R46xx47p6MZ77YGckAF1C JJmz0yL7i3mHTjgKePf6afsrPhosoOId9MvlDSV7gpHjNMOht6HvvJtsHxfKFE/w0slM Sf+J0fvLhFgRkqBAV0IrxifPETGcg3eN9u9coqurylIDHJwBmMejxNlmwF9/W321iIXx 48v3pvBV2ClTaBkeqacLkBJJhWR6mUtXWVTuXlBQhlyMpQ1E1JnuQV1oit6ukg4Y6Lt+ +6QQv2MiNEx3lQzdCpWn2vc8FsNY/SbV91rckVOHvnqgPxmeL/JAdKhmou8BA0AH4h6U VQZA== X-Forwarded-Encrypted: i=1; AKwUvBzGXfZZqBiXUEv6G7GR20FORtVGwViu77LbQsD/h697+PsI6EHlhBkfM7bn7aEv0oK4SFvME9cv3fk=@lists.xenproject.org X-Gm-Message-State: AFuF++k8IcYGdpkhSK0aKYBk5hp6wVd9PBnJZEAzIdcJW/gxzfXvuK3W mwwGwQe+QEN+UI+AP0vr4/fAKA/yqxJkz94WR+57feMBHr6e/wxzUPquNElUkC0eIg== X-Gm-Gg: AYBFou23AYseghCdBntfwhzQ+qq5HrKesuBOraHDQFeN8htvys9z95hMLRuZOym77fX dEhsIJNqzlL/5jozi4mUl/RvZ3SMq0HUoLuuBCE4tqTekeJg88WkT//eTUiLXNS/PQ0jRDdWoAB tN+zY5lD6pPUlcYYrFbKYyZFjd3SuAlH9FAZxcXyVPOOcdTmZWcqLOjcADGRi26tt7wFNQt2np1 Ppf4BEjunBNjjDjbdWakw8a2Gk8WtzDozCfH0IiDq6qck/4nsjC0VTcA4gXu+2jtGaIJ4S9DsfB pgyYy7xgOSW9SIOWoMGVp+/26dkuJUcBB6we5mda8bVyTsrzMX7lVC3EfwLA3YPnXe3+L4E1fgv ob9s4WpmbKbdWXzBpyQCChyOt0eQghVn86DV7SYHWwtzHTCS95mbEJFdqbpd7XbP85BH2j8u8Tq QviZtmwzGNbfVJNxcGW8JoMdqiDqTzAJqyOXYuk80s6337Ue9pfDTsyUws4V3POQkaIQX65TvKw 4b+EDQ45+XzOGjIsBeQkHX6ywuO6suGvSumSrZHWG9vSpcIHL3YXqPuUQTh0IA= X-Received: by 2002:a05:6000:3105:b0:485:8c16:a357 with SMTP id ffacd0b85a97d-488670b46d8mr5521116f8f.47.1790174568744; Wed, 23 Sep 2026 07:42:48 -0700 (PDT) Message-ID: Date: Wed, 23 Sep 2026 16:42:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] x86/svm: Fix VMLOAD/VMSAVE state handling when using nested virt To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260911151250.1232332-1-ross.lagerwall@citrix.com> <66aba455-6005-45f7-b01b-ad0e58ff7579@citrix.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: <66aba455-6005-45f7-b01b-ad0e58ff7579@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1790174569-77EC24E9-5EA15E96/0/0 X-purgate-type: clean X-purgate-size: 1565 On 23.09.2026 16:37, Ross Lagerwall wrote: > On 9/21/26 12:21 PM, Jan Beulich wrote: >> On 11.09.2026 17:12, Ross Lagerwall wrote: >>> --- a/xen/arch/x86/hvm/svm/svm.c >>> +++ b/xen/arch/x86/hvm/svm/svm.c >>> @@ -444,30 +444,30 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) >>> >>> static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) >>> { >>> - struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; >>> + struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx; >> >> Here and elsewhere you assume that vcpu_nestedhvm() is legitimate to use >> even in the non-nested case. I think that's heading in the wrong direction; >> I think that a hypothetical mode with CONFIG_NESTED=n and the entire >> struct nestedvcpu wrapped in #ifdef CONFIG_NESTED should still be possible >> to put in place, without meaningful rearrangements or renaming besides the >> adding of the respective #if{,n}def. > > This assumption already exists, e.g. see svm_create_vmcb(), svm_destroy_vmcb(), > svm_dr_access(). Hmm, I see. That's not very nice, but then of course you're okay to follow this model. > If you would prefer not to introduce any new cases like this, I could introduce > a new macro, e.g. > > #define vcpu_n1vmcx(v) (vcpu_nestedhvm((v)).nv_n1vmcb) > > and then for the hypothetical CONFIG_NESTED=n, it would resolve to: > > #define vcpu_n1vmcx(v) ((v)->arch.hvm.svm.vmcb) May be worthwhile independently, but as per above I wouldn't insist on you doing this right here. Jan From xen-devel-bounces@lists.xenproject.org Wed Sep 23 14:45:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 14:45:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430829.1653278 (Exim 4.92) (envelope-from ) id 1x9ODy-0001qk-H1; Wed, 23 Sep 2026 14:45:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430829.1653278; Wed, 23 Sep 2026 14:45:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9ODy-0001qd-ER; Wed, 23 Sep 2026 14:45:30 +0000 Received: by outflank-mailman (input) for mailman id 1430829; Wed, 23 Sep 2026 14:45:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9ODX-0001mR-1v for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 14:45:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9ODW-00Bfa8-Ep for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:45:02 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3e5e4-e002-0a2a0a5209dd-0a2a4506ce5a-20 for ; Wed, 23 Sep 2026 16:45:02 +0200 Received: from [205.220.180.131] (helo=mx0b-0031df01.pphosted.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3e5ec-195a-0a2a45060019-cddcb483cbc8-3 for ; Wed, 23 Sep 2026 16:45:01 +0200 Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68NBbe8Z3414040 for ; Wed, 23 Sep 2026 14:45:00 GMT Received: from mail-dy1-f197.google.com (mail-dy1-f197.google.com [74.125.82.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4gv78n2hjt-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 23 Sep 2026 14:44:59 +0000 (GMT) Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-33c35f5ca6cso1574614eec.1 for ; Wed, 23 Sep 2026 07:44:59 -0700 (PDT) Received: from [192.168.1.199] (216-71-219-44.dyn.novuscom.net. [216.71.219.44]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-33e95c7d003sm6415514eec.9.2026.09.23.07.44.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 07:44:57 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=qcppdkim1 header.d=qualcomm.com header.i="@qualcomm.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=google header.d=oss.qualcomm.com header.i="@oss.qualcomm.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Content-Language:From:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= xgcOxoTBwTC0LF6Ccg2RoIG8nDW44o8mbEkBphCt1MQ=; b=lOcvg0LsZNHlJQcO 83LWdgPgFbriVuwgIkvY1vjmlk3l0vvKq5h3c+UrBHs4eH8sUgVxSQO6/x7k7sWA XP9VHPwASEyTQBgKxgTVA9Qzh/Vpa4KV1F4MZcTE87LSY2YKrDyZxAD8y5rRIfqa 0kZU1HHHHdP/tG9icKbXa+XeoO4Jnpmc1tO0ArX+MMrLhxHJ3rUnkD1MyDAzuBv5 9e5urHMujrRvNlDJiuAx6R8rvM2q5XTIGwwp1wVaN23cB7UDJHJsv1g71ZijmXKP XizyejcqWjeG+hvuHg6+K8yMo852eB23u3BBgBaJ7+oAj83v3/xibK+Ja8JUaYxN NXqUZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1790174699; x=1790779499; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=xgcOxoTBwTC0LF6Ccg2RoIG8nDW44o8mbEkBphCt1MQ=; b=Yy9FGKap78gcdGmSZmZFoAbo8FWMsMVRUVrasSpCG0u7nfcvsNCw0uMMnn6t/1typ6 4XTS9lY+a2cASzTYF+5gFJ7B3kgE+0cZ0DDJnXK46S9FKFeY76muor4S9psJ1CoOWbC6 4jr7WUDfi5pdZ1n+w8FRCRIAB9lyCjX1ubmuBMDy5Ar8pO5hpFkE6RSy8RrQsho9BPPu nzOY9hY5ApEWIuR54oZ99opm1+iXQRb2qEecHSqV1nFFwc0jrCoZycIXZnClVZ8Zz7kc U3uWywVsDoznHNJPKcv5KTRB2a4gJKxJnHcxJ4hV19MGf9rLs6aB/3bCFfvUe4kuplwY Regg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790174699; x=1790779499; h=content-transfer-encoding:content-type:in-reply-to:content-language :from: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:content-type; bh=xgcOxoTBwTC0LF6Ccg2RoIG8nDW44o8mbEkBphCt1MQ=; b=zWW8wBaVnep6+FlfXk6BJX2GsT+UsHOhFkgKn0uWkA51u3dCYGEN1rl15/KQQf8iBV PTxNsHvUozoV5GS7kjSWZ4QP5ymGQK+WRECU6roOsKy9yM/EzENz0UVe4Yw0vicG97CG XQuoNxY8Eh0C8is6bFa7NKQN7v3LIFo0IufxgM4G/pN+rg/We0cAl2q1wmwE43+NbmIa 3FJet9I3NyoJRieCi+4fDNVuoqjHbzP1z72X+QTHW5KHqAC1AKJSCyU9DYzZbjal9+Aw 7XXHMAOmI+BgYYghuy5VFvp49QT6W9sOuhpaaOPGu9PpLtXGOV5xFfZWaDK27oaeYgPL GdOw== X-Forwarded-Encrypted: i=1; AKwUvBz6rTwy7SisUUoS9y9j4F9iEh6gmsuPBZzDvpxsCgeUulMpj+9eglEwQwq4VWeOAR9Jq6JC8cZdwMk=@lists.xenproject.org X-Gm-Message-State: AFuF++kzxih2nZrltgm/RAl9cuw2XKRgnpo3QOhjsTNnVBQlUKpX6ohm 7FXYH11Y9A1uvFOoBpoaC5WpudgVASrGlP+eNrWC/lPyzzDAoyRB4GyEHvGqo2x2s3ljHhR2gkh x/+k2hMJkHgTl5nxlQpnubevCnjl1n4lJafW1dWeLigl9F5K1HM2lV/CjaT4tjK+onvN7Gg== X-Gm-Gg: AYBFou0G07OJKTIgc0HyLuppcDIxoDMWn6aymkM+7xcwiiL5JjVcxVauSpORAEDSMJe DE/Nn9g4QpaSohfBFADzChEZIkGkExM/MNT+UuKLjn/hgiMGTJUDKeXbzTxtt+adagcjevcWp5g 7M5gsoPCaza21Ym1Ku88YMfYfEpNaHC4W9L7p0uHX5e52TfXbNSfcYF6oiljTLRAp/sXL8Viexa kQEAD14gR+zQ7W5JIoaekxEQbeQxxOaPJPRxVG9+6CvBfV2zBoGs1f3AxJvzrsV86gbVk9mP2H4 InoSF6riHJj9QFbzZPyd8Ow4TWaFsSDCNxZ2qQNmuW4btvlGvHrdpyS5ViUmieoie9+3+Os6qmw h4q6DvTTwLBxQHBLwOOUxNQZdOS4dVsEu27fjhHngHjcJ16ZFEE8Iswpuc2vFJ+7m0TIxU3DAso 5beg== X-Received: by 2002:a05:693c:42d9:b0:33b:e75b:cc42 with SMTP id 5a478bee46e88-33e8d7d8b7bmr2233687eec.19.1790174698776; Wed, 23 Sep 2026 07:44:58 -0700 (PDT) X-Received: by 2002:a05:693c:42d9:b0:33b:e75b:cc42 with SMTP id 5a478bee46e88-33e8d7d8b7bmr2233634eec.19.1790174698038; Wed, 23 Sep 2026 07:44:58 -0700 (PDT) Message-ID: Date: Wed, 23 Sep 2026 07:44:54 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 000/114] single-binary: link multi-targets into qemu-system To: Yonggang Luo , qemu-devel@nongnu.org Cc: Cornelia Huck , xen-devel@lists.xenproject.org, Chao Liu , Igor Mammedov , Alistair Francis , Daniel Henrique Barboza , Peter Xu , Eric Blake , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , Liu Zhiwei , Peter Maydell , Sunil V L , Stefan Hajnoczi , Palmer Dabbelt , Fabiano Rosas , Xianglai Li , Jiaxun Yang , Max Filippov , qemu-ppc@nongnu.org, Zhao Liu , Paolo Bonzini , Bibo Mao , "Michael S. Tsirkin" , Laurent Vivier , David Hildenbrand , Richard Henderson , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Nicholas Piggin , qemu-riscv@nongnu.org, kvm@vger.kernel.org, "Edgar E. Iglesias" , =?UTF-8?Q?Alex_Benn=C3=A9e?= , Stafford Horne , =?UTF-8?Q?Marc-Andr=C3=A9_Lureau?= , Markus Armbruster , Weiwei Li , Song Gao <17746591750@163.com>, qemu-arm@nongnu.org, qemu-s390x@nongnu.org, Brian Cain References: <20260923131635.1894-1-luoyonggang@gmail.com> From: Pierrick Bouvier Content-Language: en-US In-Reply-To: <20260923131635.1894-1-luoyonggang@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Info: AW1haW4tMjYwOTIzMDA1OCBTYWx0ZWRfX7qciuBdI2AZe CyQdDPF6tWBOvVcsURzYw6uaBqLi422VAE+kfitP915rFHXXqMUqWdEOnS9uxi4dAlOENzj/s/G pmbCydFZty0kzrnBUGkRrIymuuzlSCs= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTIzMDA1OCBTYWx0ZWRfXzP1tBP0J6BmX cp805b3Nnss6X0aFkLA7OzibBKMzAh/pPEbvMJrvUcV8pwFsITZIi+eV8d1DSiEAzos0t/riHzY KA4VfbwmfPzpw4dsF+tyoOgz9P5RXf2Vr8vGim2izF7A1ibfQESTXeqKj6JRFHueoAaYkVSMJTt mNsTLdfavipFP09uSleJFPitjUEOQSriog9s5wLN3ECkNiLYefampacej/W3wpEBsMSAq1jQIQO fsDOLNeU6aVNBpdD6P87DGwJWN8yp5fLhqGpynOvMXV/q2RPFTTf51QjwkCRiTjbZMgLjgmLqt+ rKLg5MYc971MUZVJwqBfV79oy4aejBBrEb1xrSumBtbMrmzpcOfaSgbbENuVKVkAzGcseK3Nke7 o5XFOBuS+cydAXYjni34nLKcIm8dysqMiUcomhrthTwy/iWIThPUxHHeF6vVXeeDEKbmFdKlEr3 Gb8IsrMXfwbWyzl6IfA== X-Proofpoint-ORIG-GUID: ktz--GUWAF66OazTJM_CVqPl5K17F19f X-Authority-Analysis: v=2.4 cv=aNFlOr9m c=1 sm=1 tr=0 ts=6ab3e5ec cx=c_pps a=Uww141gWH0fZj/3QKPojxA==:117 a=iLqgmErQAxjCjdq5jj1Aqg==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=GaQpPoNlAAAA:8 a=pGLkceISAAAA:8 a=p0WdMEafAAAA:8 a=GSDOiBCUhkFbxXud944A:9 a=QEXdDO2ut3YA:10 a=PxkB5W3o20Ba91AHUih5:22 a=xF5q_uoM5gZT5J3czcBi:22 X-Proofpoint-GUID: ktz--GUWAF66OazTJM_CVqPl5K17F19f X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-23_04,2026-09-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 spamscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 adultscore=0 phishscore=0 impostorscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609230058 X-purgate-ID: tlsNG-16d1c6/1790174702-FD20877B-F4A72336/0/0 X-purgate-type: clean X-purgate-size: 4830 Hi Yonggang, On 9/23/2026 6:14 AM, Yonggang Luo wrote: > This series produces one qemu-system binary that can run ARM (32 and > 64), RISC-V (32 and 64), and MicroBlaze. > Upstream filters machines with TypeInfo.is_available. This series > passes a TargetInfo into that callback, uniquifies QOM names that > collide in one process, and compiles those targets once so they can > share qemu-system. > > A combined link cannot keep C symbols or QOM type names that were > unique only because each qemu-system-$arch was a separate binary. > These patches remove those collisions: > > - TYPE_ACCEL_CPU is the fixed abstract type accel-cpu, registered > once next to TYPE_ACCEL. Leaf names still encode the CPU type so > accel_init_cpu_interfaces() can look up "-" plus > target_cpu_type() (tcg-accel-arm-cpu). > - virt QOM names are prefixed: arm-virt, riscv-virt, and the same > for or1k, hexagon, loongarch, m68k, and xtensa. Boards keep > -machine virt via machine_class_set_name(). query-machines returns > the QOM type in MachineInfo typename. > - virt ACPI helpers and RISC-V TCG crc32/crc32c/wfi helpers get an > arch prefix so the combined link does not need meson -D name > mangling. LoongArch virt_acpi_setup is renamed in the same pass. > > Target selection has to work with more than one TargetInfo: > > - The combined binary takes arch:name on -M/-machine and in a > [machine] type (aarch64:virt). arch: binds the target. microblaze: > runs that target's default machine. arm, aarch64, riscv32, and > riscv64 have no default. No -M leaves target none and the empty > none machine. qemu-system-$arch keeps the historic -M name. > -M help lists every target; arch:help lists one. query-targets > lists each linked target, including none. > - TargetInfo is a constructor list. target_info_select() picks the > entry, including SYS_EMU_TARGET_NONE. is_available takes const > TargetInfo *. While the target is still none, QOM skips the > unavailable filter so grouped -M help can list every machine. > - query-cpu-definitions, dump notes, and Angel semihosting sit on > TargetCpuOps indexed by target_arch(). Registration uses a > QEMU_ARCH_* bitmask so one object can fill ARM and AARCH64. The > table is target-ops.h / target-ops.c. > > qemu-system-$TARGET is still built, including the Windows *w twin. > qemu-system is extra. It links each target whose arch sources are > only target-info-def.c: arm, aarch64, riscv32, riscv64, and > microblaze. Do not add qemu-systemw for that binary. A GUI > twin would keep QEMU exporting data from the .exe into DLLs, and > those data exports cannot be delay-loaded (qdev_prop_array and > other qdev_prop_*). That would block enabling modules globally on > Windows. > > Examples: > > qemu-system -M aarch64:virt ... > qemu-system -M microblaze:petalogix-s3adsp1800 ... > qemu-system-riscv64 -M virt ... > > A bare machine name on qemu-system needs an arch: prefix. An unknown > target fails with "target '...' is not available". > > Prerequisites: > [PATCH v2 0/9] machine: uniquify virt QOM names > https://patchew.org/QEMU/20260922215533.641-1-luoyonggang@gmail.com/ > [PATCH 00/21] accel/tcg: share raise_excp across TCG targets > https://patchew.org/QEMU/20260918004225.827-1-luoyonggang@gmail.com/ > [PATCH v5 00/11] single-binary: Compile hw/riscv once > https://patchew.org/QEMU/20260918-hw-riscv-cpu-int-v5-0-f98c5a244636@rev.ng/ > > v1: https://patchew.org/QEMU/20260823150731.896-1-luoyonggang@gmail.com/ > v2: https://patchew.org/QEMU/20260826184229.1145-1-luoyonggang@gmail.com/ > branch: https://gitlab.com/lygstate-qemu/qemu/-/tree/single-binary-arm-riscv?ref_type=heads > x86_64 and i386: https://gitlab.com/lygstate-qemu/qemu/-/tree/combined-binary-multi-targets?ref_type=heads > thanks to pursue this effort. It seems like your mail provider blocked the send after 40 patches. It can either be: - usually I have to reenter my password (after a timeout around 3 to 4 min) to keep on sending patches. A better way is to setup your password in git config. - Your reached your daily quota because there are two many cc on each patch. Reduce cc list. Also, I would recommend you start easy, with only two base arch as targets (like aarch64 + riscv64). This makes the series much nicer to review and iterate. Then you can do one series per extra target. It takes time, but that's the only sane way to move forward. Also, I would invite you to get the command line details reviewed first, as it was the biggest point of discussion last time I tried this. Once you reach a consensus, it will be trivial to add new targets in. I'll follow any choice the community will make for this. Regards, Pierrick From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:16:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:16:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430871.1653286 (Exim 4.92) (envelope-from ) id 1x9Ohb-0002pz-Ms; Wed, 23 Sep 2026 15:16:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430871.1653286; Wed, 23 Sep 2026 15:16:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Ohb-0002ps-KC; Wed, 23 Sep 2026 15:16:07 +0000 Received: by outflank-mailman (input) for mailman id 1430871; Wed, 23 Sep 2026 15:16:06 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9Oha-0002pm-15 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:16:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9OhY-008IWv-L1 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:16:04 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3ed2d-2eae-0a2a0a5409dd-0a2a45049bf4-28 for ; Wed, 23 Sep 2026 17:16:04 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3ed34-b57f-0a2a45040019-b9ff1c228045-3 for ; Wed, 23 Sep 2026 17:16:04 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0ced6896200072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 15:16:01 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id AE5E1822C9; Wed, 23 Sep 2026 17:16:00 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=eCkgDkD2MRwoqy8APPUc78laAAk/4X63XbFZDO3ee3U=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Bdl7wmV8Tz88WiZU6UNu5Xhwc4jj5MgypD0Avc65gPtBNIMQh71KfG6W7cZ+a4yevJEsqHTFf rY8GBi6YI5Jq/HMyQQtozhAgmYcJ+jgygArcs656B7rYDF8bRSRH0+1LVv8DYHXunc4SJRWLXwp i8fUTgiLq9Jlmydoas2dU5gJvoUYKtBsCelIuIopFx+ixNE11wkE8fE7IhJ+TdMSbCjQIlLati4 lsTFHhESEDrBB0X//bs9L257AJQcPJr42dYb6cuGArIZYuDmoSt8RuoMekKkt6GMDDPCVlf5UCT yZy7N//MBmUFEkj0VFYjuxL0BdgmPc81BXsAd0Eyrm+Q== X-Zone-Loop: 116d5c6887484a98e33ceeba1b0ed0d47cf885805f2f x-campaign-type: default x-transaction-id: 95def31e-6925-42cd-83a0-4bb8419b5e9a x-swg-uid: 01-384ea436-d9b4-4e8b-a9f4-7333da706035 X-Mailer: Sweego Message-ID: <1790176561.8631fc262581453bbf619ec5b2062170.1a0ced6896200072c4@vates.tech> x-swg-bid: 1790176561.8631fc262581453bbf619ec5b2062170.1a0ced6896200072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Wed, 23 Sep 2026 17:15:53 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790176555; l=2913; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=fYzeUEWEhfCv4+Ymv9h8sEWhE7EOk0UljiQUNUMogws=; b=tj4pnjGtDo6GgIjIhkkGcDgWmB85wNR0cM9VVUz5sdtLKdZbwDytvYZirYrSU0qk+D7jDxi9d ZFtfEepGvifCBzqWMp+SPQlG5M0AFnbI1dqpsO2AKd48rCsMIfEMzxV X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790176560921 X-purgate-ID: tlsNG-ebf023/1790176564-52CCFB50-6D6F8907/10/73395122804 X-purgate-type: spam X-purgate-size: 2913 > At the old interrupt file, dump to memory all the eip and eie arrays). Typo `)` > After this step is done, the old interrupt file is no longer in use so > old intrrupt file VGEIN could be released. > > Restoring of old interrupt file state will be done in follow-up > patch. > > There are cases where it is needed to specify on which cpu it is > necessary to VGEIN should be released so update vgein_release() to The sentence miss a verb, here is a proposal: ``` There are cases where the cpu on which the VGEIN is released needs to be specified, so update vgein_release() to deal with that. ``` Moreover, could you explain me the cases you are talking about? It's not clear by reading the commit message in the first place. > deal with that. > > Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > against silent incorrect behaviour or unexpected panics in guest VMs until > the function is fully implemented. > > vgein_release() is stub for now and will be introduced later. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c > index 75c82bcfa1..be3901ec0c 100644 > --- a/xen/arch/riscv/aia.c > +++ b/xen/arch/riscv/aia.c > @@ -30,3 +30,8 @@ unsigned int vgein_assign(struct vcpu *v) > > return 0; > } > + > +void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) > +{ > + BUG_ON("unimplemented\n"); > +} > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index 5e9f6995e4..3cba58e0c1 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -56,6 +56,24 @@ static unsigned int __ro_after_init guest_num_msis; > */ > #define GUEST_IMSIC_MAX_MSIS 255U > > +/* > + * The interrupt identities an IMSIC interrupt file provides are 0 (which is > + * never valid, but still occupies a bit) up to IMSIC_MAX_ID inclusive, so > + * IMSIC_MAX_ID + 1 bits have to be covered. > + */ > +#define IMSIC_MAX_EIX DIV_ROUND_UP(IMSIC_MAX_ID + 1, BITS_PER_TYPE(uint64_t)) > + > +struct imsic_mrif_eix { > + unsigned long eip[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; > + unsigned long eie[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; > +}; > + > +struct imsic_mrif { > + struct imsic_mrif_eix eix[IMSIC_MAX_EIX]; > + unsigned long eithreshold; > + unsigned long eidelivery; > +}; > + Maybe I didn't get something but I couldn't find anything in the commit message explaining why do we use mrif here. Moreover, mrif, as described in aia spec (8.3 Memory-resident interrupt files), seems to be only usable with IOMMU that Xen doesn't support. If you want to have something in memory that could store some interrupt file info, we should take another name to not be confusing. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:25:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:25:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430884.1653296 (Exim 4.92) (envelope-from ) id 1x9OqS-00069q-FO; Wed, 23 Sep 2026 15:25:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430884.1653296; Wed, 23 Sep 2026 15:25:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9OqS-00069j-Ch; Wed, 23 Sep 2026 15:25:16 +0000 Received: by outflank-mailman (input) for mailman id 1430884; Wed, 23 Sep 2026 15:25:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9OqQ-00069c-Ho for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:25:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9OqP-009ZwT-Uu for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:25:13 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3ef3c-2eae-0a2a0a5409dd-0a2a4503ac08-26 for ; Wed, 23 Sep 2026 17:25:13 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3ef59-fae8-0a2a45030019-b9ff1c22a9d3-3 for ; Wed, 23 Sep 2026 17:25:13 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0cedeee2900072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 15:25:11 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id C3517823F1; Wed, 23 Sep 2026 17:25:10 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=A0O4widBrgTO8ppcYRp27L3uLQE6Gf1qHqFDj9Xx2Oc=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=gvepFN4dWymtlorbhHWDWkSHTC9pup/Sz00qeWhOWQSH+Aqg+c4yFNIuh/8EDBQDilpxImlPy J83mR6Lag3AzVLJlBVOiQFRputIW2LC3+f9F8TnftodwIj8xrkRM9X/F9VjeFNSU+yj77DbKqDz Fq2ip9oLRSJ3+5X/DJPtv5pE/0nB84M0mwn9tNrHKKZLfOrDqBhB2SauA+AthLOqBlC9G2s+P3S RK2FND39skfF+iml7pd4gIoKMnf+m+UfU8gfD6MQIibqnR9OJmWPeidZFX+QPg8cew65+lhq7i7 BmqBETMY7qldVJUMzi2Rhn8LR00HZTisNOBEI0uJJ4dg== X-Zone-Loop: 73962a39929b42fb26a835d2ca0ce7cbd2db22c8681d x-campaign-type: default x-transaction-id: 534a30be-c4fa-4c9b-80b8-41a2ff631381 x-swg-uid: 01-2cf5f2e2-09d6-4702-93f8-bedf152545c3 X-Mailer: Sweego Message-ID: <1790177111.8631fc262581453bbf619ec5b2062170.1a0cedeee2900072c4@vates.tech> x-swg-bid: 1790177111.8631fc262581453bbf619ec5b2062170.1a0cedeee2900072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] Date: Wed, 23 Sep 2026 17:25:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file To: Oleksii Kurochko , xen-devel@lists.xenproject.org Cc: Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> From: Baptiste Le Duc Content-Language: en-US Autocrypt: addr=baptiste.le-duc@vates.tech; keydata= xsBNBGoPSX8BCADSuTikqW3FD4mscQugY1thRaKlIhcJ2G9YCWYXAlp+xosvTlzfIftOZZim 750MLvyKtLPkQzB6TZtFZBiexSraaF/MdDKRTT5DcVa3r7ZnHgqMclWlPa4ioysS4yFcJanL cyNOT7HUFvIdirMMqiViedfYtS0GORPBBPVISD6ClMz3ecHIxqllfq9CHYQn4amKEfHmh6tm Rufo4Gjl6x8cUFZZlRQf+aCmUzdSPA0P5u3sueYH1uEz4w/jbD53MlKqzCvxUeOsfS2swTQA 6mS9jIgOjNadpUTOzKfDHMgFirtG+HFpm45Nwp6KQizxgDVOfTnOfVHm5Gwqm3ETl9y5ABEB AAHNPEJhcHRpc3RlIExlIER1YyAoVmF0ZXMgWXViaWtleSkgPGJhcHRpc3RlLmxlLWR1Y0B2 YXRlcy50ZWNoPsLAjgQTAQoAOBYhBGiSJ6HgW88MgT/gfu2Cu2XL9M6QBQJqD0l/AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEO2Cu2XL9M6QuMcH/ihiy/Nrxp919AmY0ENnc0NK r/2LDvW/hrX4FfbpxAmrGmQ7MU1aQTk0JDbfcsG8OYH6wO5sqnXb1gz50YrEdpfVSbHz5YTZ EhDIxE4g7NrvJZh3Qc0m0CAyjYTNHen7J6olVaCMjrOH7uRHUYZ7Pl3am9mZosfLmez/aWJO a6ihQxBXHI75brlk1teIURkep2kP7P0Flmfl4cA//saREoTF7GXCtjOSQk/xg8PP0Sswqp5G TdJptn3FQn6lAzfz0eFSYqkaoX2c2k1MDa7o+UX9cfGPL8ybMKnYkasLxck6eOWGJWf+YTrm ga/r0kBaftmqNDgt5nI2jNTDwZcT9g3OwE0Eag9JfwEIAM6IWbuBSvz+erv27oGDDpo8M6Fp dGUvft7v+WceHUfxiXpYFx9qgIU6XGy6y+3lJMAvNcltS8DuhioqMlfKRSYGKZlpliY65dNP 557IuM4ctVJ+I9CVclvv9eahARQKgF5auLJAAlvGSmU+ufNvlwTUmLIRcrPviTmB6X5jJYc+ fiNeyI0HcsgcN21C0r62tUCypuZ+vgEJXw2bx1V8mVGZKxdGJPh58QF6kRK+xmd4kEComLGV BeM6BcVOtEjDcGNC0tLhXb0p9g1Ys55iA8sd6s4WacyolW2J6rwmcOkjiWexWw1caYgIWAV1 004M3gwUaOz0dGq2i7HQ0AiVfVkAEQEAAcLAdgQYAQoAIBYhBGiSJ6HgW88MgT/gfu2Cu2XL 9M6QBQJqD0l/AhsMAAoJEO2Cu2XL9M6QovYH/RjstyL5o/V5K74ylBtz0j5t3pLX5JKbwApi 656rGgDdqElImyvvZppNMl/mgHNzvxmfFAhJXnSX9f1fqVEQKOGEhLUastnl/ssBiE5x7btM V0GAffxXbXJZbVv4b/DI+gVrOPc2YXlVwruapvTZNtD3hqPrkjrmq5WTtGR2loIVSe62hmh0 BGD2Fy79b/hYWyBqhayPBEjwGW75u4/yn+Yqy1PgG3hIcvg7GSuT3akhHZSB2Mbguzcoyf9Q DJl6t33JxPRkkNrEdkPPmRlQCTSiUkVjKqMDF3jlINWsJ5t4jKFsNF91ksdw7aQgiX+tQIpE ugMC1NuNi5dDGip66bw= In-Reply-To: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790177110997 X-purgate-ID: tlsNG-33051d/1790177113-6D6D64E9-C4837BBE/10/73395122804 X-purgate-type: spam X-purgate-size: 9071 > xen/riscv: remap interrupts to new IMSIC VS-file Nit: The next patch uses "restore" in its title, we might want to use "save" terminology here for symmetry? e.g.: "xen/riscv: save old interrupt file state to memory" On 8/27/26 5:22 PM, Oleksii Kurochko wrote: > After new IMSIC VS-file is zeroed-out it is necessary to do G-stage remaping > fo new IMSIC VS-file. Also, if any interrupts at an APLIC are forwarded by > MSIs to the old interrupt file, reconfigure the APLIC to send them to the > new interrupt file. > > Generally it is needed also to modify the relevant translation tables at > all IOMMUs so that MSIs for this virtual interrupt file are now sent to > the new physical interrupt file but it is skipped for now there is no IOMMU > support for RISC-V. > > Synchronize with APLIC to ensure that no straggler MSIs will arrive at > the old interrupt file by using of aplic_genmsi_barrier(). > > Technically there is no need for read_lock_irqsave() and > read_unlock_irqrestore() around reading of ->guest_file_id, as a write > cannot happen in parallel: any update to ->guest_file_id for a vCPU > will happen either in imsic_migrate_vcpu() itself or before the vCPU > first gains control (in continue_new_vcpu()), so there is no concurrent > access to it in imsic_migrate_vcpu(). The lock is added here for > potential future cases. > > Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > against silent incorrect behaviour or unexpected panics in guest VMs until > the function is fully implemented. > > imsic_map_guest_file() and imsic_update_state() are stubs for now and will > be introduced later in a separate patch. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v2: > - New patch. > --- > --- > xen/arch/riscv/imsic.c | 103 +++++++++++++++++++++++++++++ > xen/arch/riscv/include/asm/imsic.h | 3 + > 2 files changed, 106 insertions(+) > > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index 5de45949610d..5e9f6995e443 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -27,6 +27,7 @@ > #include > > #include > +#include > #include > > #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ) > @@ -60,6 +61,12 @@ static unsigned int __ro_after_init guest_num_msis; > #define IMSIC_DISABLE_EITHRESHOLD 1 > #define IMSIC_ENABLE_EITHRESHOLD 0 > > +#define imsic_csr_read(c) \ > +({ \ > + csr_write(CSR_SISELECT, (c)); \ > + csr_read(CSR_SIREG); \ > +}) > + > #define imsic_csr_write(c, v) \ > do { \ > csr_write(CSR_SISELECT, c); \ > @@ -141,6 +148,11 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v) > return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); > } > > +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id) > +{ > + BUG_ON("unimplemented\n"); > +} > + > void __init imsic_ids_local_delivery(bool enable) > { > if ( enable ) > @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) > spin_unlock(&imsic_cfg.lock); > } > > +static bool imsic_local_is_pending(unsigned int id) > +{ > + unsigned long isel = > + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0; > + unsigned long bit = BIT(id % BITS_PER_LONG, UL); > + > + return !!(imsic_csr_read(isel) & bit); > +} > + > /* Callers aren't intended to changed imsic_cfg so return const. */ > const struct imsic_config *imsic_get_config(void) > { > @@ -436,6 +457,11 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v) > /* Nothing to do */ > } > > +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) > +{ > + return -EOPNOTSUPP; > +} > + > int cf_check vcpu_imsic_init(struct vcpu *v) > { > struct vimsic_state *imsic_state; > @@ -497,6 +523,27 @@ static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), > on_selected_cpus(cpumask_of(cpu), func, data, 1); > } > > +/* > + * Ensure that all the MSIs the APLIC has already generated for the hart this > + * runs on have really reached the hart's IMSIC. > + * > + * The barrier is the one described by the AIA specification in > + * "Synchronizing interactions between a hart and the APLIC": ask the APLIC to > + * send an MSI to the hart itself and wait until it shows up as pending in the > + * hart's own interrupt file. As it says nothing about MSIs on their way to > + * any other hart, it has to be executed by the pCPU owning the interrupt file > + * the MSIs were being sent to. > + */ > +static void cf_check imsic_aplic_sync(void *data) > +{ > + imsic_local_eix_update(imsic_cfg.sync_id, 1, true, false); > + > + aplic_genmsi_barrier(); > + > + while ( !imsic_local_is_pending(imsic_cfg.sync_id) ) > + cpu_relax(); > +} > + > static void cf_check imsic_vsfile_local_clear(void *data) > { > unsigned int i; > @@ -837,6 +884,10 @@ void imsic_migrate_vcpu(struct vcpu *v) > struct imsic_vsfile_data vsfile_data = { > .nr_eix = nr_hw_eix, > }; > + struct vimsic_state *imsic_state = v->arch.vimsic_state; > + unsigned long flags; > + unsigned int old_vsfile_id; > + unsigned int old_vsfile_cpu; > > /* > * The scheduler can mark a freshly created vCPU's unit as migrated and > @@ -848,8 +899,22 @@ void imsic_migrate_vcpu(struct vcpu *v) > if ( v->arch.last_cpu == NR_CPUS ) > return; > > + read_lock_irqsave(&imsic_state->vsfile_lock, flags); > + old_vsfile_id = imsic_state->guest_file_id; > + old_vsfile_cpu = imsic_state->vsfile_cpu; > + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > + > + /* > + * We don't support SW interrupt files at the moment. Bail out before > + * anything is touched, as the old file has no owning pCPU in that case > + * and there is nothing to retarget the producers away from. > + */ > + if ( old_vsfile_cpu == NR_CPUS ) > + panic("IMSIC SW-file isn't supported\n"); > + > /* > * At this point, all interrupt producers are still using the old IMSIC > + * VS-file so we first move all interrupt producers to the new IMSIC > * VS-file. > */ > > @@ -870,5 +935,43 @@ void imsic_migrate_vcpu(struct vcpu *v) > /* Zero-out new IMSIC VS-file */ > imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); > > + /* Update G-stage mapping for the new IMSIC VS-file */ > + if ( imsic_map_guest_file(v, new_vsfile_hgei) ) > + { > + domain_crash(v->domain, "Migration to hw interrupt file failed\n"); > + > + return; > + } > + > + imsic_update_state(v, new_vsfile_hgei); > + > + /* > + * TODO: Modify the relevant translation tables at all IOMMUs so that MSIs > + * for this virtual interrupt file are now sent to the new physical > + * interrupt file. > + */ > + if ( iommu_enabled ) > + printk_once("IMSIC: IOMMU MSI retargeting is not implemented\n"); > + > + /* > + * If any interrupts at an APLIC are forwarded by MSIs to the old interrupt > + * file, reconfigure the APLIC to send them to the new interrupt file. > + */ > + aplic_reconfigure_target(v, old_vsfile_id, old_vsfile_cpu); > + > + /* > + * Synchronizing interactions between a hart and the APLIC. > + * > + * The MSIs to be flushed are the ones still on their way to the old > + * interrupt file, so the barrier has to be done by the pCPU which owns > + * that file. > + */ > + imsic_call_on_cpu(old_vsfile_cpu, imsic_aplic_sync, NULL); > + > + /* > + * At this point, all interrupt producers have been moved > + * to the new IMSIC VS-file. > + */ > + > BUG_ON("unimplemented"); > } > diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h > index 6ea2e4b8ca12..6395b539c52d 100644 > --- a/xen/arch/riscv/include/asm/imsic.h > +++ b/xen/arch/riscv/include/asm/imsic.h > @@ -114,12 +114,15 @@ void imsic_ids_local_delivery(bool enable); > int vcpu_imsic_init(struct vcpu *v); > void vcpu_imsic_deinit(struct vcpu *v); > unsigned int vcpu_guest_file_id(const struct vcpu *v); > +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id); > > int vimsic_make_domu_dt_node(struct kernel_info *kinfo, unsigned int *phandle); > > void imsic_ctxt_switch_from(struct vcpu *v); > void imsic_ctxt_switch_to(struct vcpu *v); > > +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id); > + > void imsic_migrate_vcpu(struct vcpu *v); > > #endif /* ASM_RISCV_IMSIC_H */ From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:28:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:28:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430893.1653305 (Exim 4.92) (envelope-from ) id 1x9OtI-0006fc-TU; Wed, 23 Sep 2026 15:28:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430893.1653305; Wed, 23 Sep 2026 15:28:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9OtI-0006fV-QG; Wed, 23 Sep 2026 15:28:12 +0000 Received: by outflank-mailman (input) for mailman id 1430893; Wed, 23 Sep 2026 15:28:11 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9OtH-0006f9-Ew for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:28:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9OtG-002ZOH-Rq for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:28:10 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f004-8faa-0a2a0a5109dd-0a2a4505cae2-14 for ; Wed, 23 Sep 2026 17:28:09 +0200 Received: from [40.107.162.67] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f009-4cb1-0a2a45050019-286ba243cc57-3 for ; Wed, 23 Sep 2026 17:28:09 +0200 Received: from DUZPR01CA0287.eurprd01.prod.exchangelabs.com (2603:10a6:10:4b7::29) by DB9PR08MB6603.eurprd08.prod.outlook.com (2603:10a6:10:25a::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.17; Wed, 23 Sep 2026 15:28:03 +0000 Received: from DU2PEPF00028D0A.eurprd03.prod.outlook.com (2603:10a6:10:4b7:cafe::6d) by DUZPR01CA0287.outlook.office365.com (2603:10a6:10:4b7::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.16 via Frontend Transport; Wed, 23 Sep 2026 15:28:03 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU2PEPF00028D0A.mail.protection.outlook.com (10.167.242.170) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Wed, 23 Sep 2026 15:28:03 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com (2603:10a6:10:1aa::17) by GV1PR08MB7348.eurprd08.prod.outlook.com (2603:10a6:150:23::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 15:27:26 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b]) by DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b%5]) with mapi id 15.21.0472.004; Wed, 23 Sep 2026 15:27:25 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=kmFto8GYScB4qlt4+Nn5noaewkw9K5aJpLweigDZJlfOhT9sqtm6Zp2BReMoLsfcAWkVUfyHjpmf25CBlllCmA9fDv7tkBDIyEtGJuZPX3L35NZmuO+Wsa7Mo6YEU2YIE/zyedE6ZEHww4GRfQoQpyzcG9C2Q4wxMEDvwzkwB+R6Y60viNnsEmPcDHqflRxeTbwNdKWRdAk31aQhls4sC0Nb2t3/ixmC3h5iSx1acCXUqcEU7OF+SeDggIPtdmcWfOarlcPsciAmKJt4OeiX9U6Iz70I8vshaKeQZSYR3ltXgJXlRQgpECyDat0rVvjR5iaozvnr8e1F5PmZ24dMxQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dPnnU/bovfMLMFk7Fz37gjc4NKrWmTRVmNUudIt/WoA=; b=GNcFOHz/+KIUxIAXMG8eTbbYEa9RCpIHHxRXcjAtBTBtZIgY1/whpiE3k9asWzaSsJ3RqYbx2SdoI784LpG8FKz+khea8C/tF61kcw+kth+mHRtnIthsf+a4dKMg6Wtr0kc8WUi1l+TRQAu7IZd0NhqebtzVwpCA+DkG9mviWQGm+XiWEDJe5WM25awlxueaO6LI+XFY+yBXeg+c75Fsp1qP+Y3KZLJbbqJkGU831OTFswLIKGEUTzaa5GwyUOxKXLlGElcpk3hiZy87WuDrDBg5wVU2w1f78yodIuuYpYSMLLcRqK1Vbr1wb8s67bCxazj1jswgrL49UWVCUD4GHg== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=epam.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dPnnU/bovfMLMFk7Fz37gjc4NKrWmTRVmNUudIt/WoA=; b=gEeLU5NJESNm6jRKV/96cFsWKWOdI0wID3zHh6yl06W0t3zJkanADPBlOmXgnyHSZ+n/s6Uw/zY003GYBjr0bFKoQpCM6+JJyFOVZ0HIsdfT3NhjTd2leDefly9Zx+GMpDKRQjvjTWlgJSV3PY2ICZpICdEoTEokjO2vdt+A5Co= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mmK6I3X/+Q4duqDQ/4XiE2rOkie0xM1AQWk+1ERk30/0cPMyiiR+ZG+0M7KoAJ3kRgF2t3pOIA+1MI3xvQUAcL1ZAk++DA1C5Sbvllzvp6Uz0guNrRLI2dUjv8QrkPDVzmxI3g5p9fVoZnAoPwcJdycvgwjtSpPiArCl/OCIZUT8uj9W0w4nc1/aoqHDxMeT2cSARj4GpT9ojr3ktaa8FmcpKSTORPbWLTQSZ2jGeDYrmX7e8PwoofgAEJVU8JRbx+owlcLQh4udjIZQEy7R6fKmGhQEaNNk8tQfXcnbRRsOLbbqDX9QLDjRv0wgchOpHY+24VxbPetUNO3hkbUWKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dPnnU/bovfMLMFk7Fz37gjc4NKrWmTRVmNUudIt/WoA=; b=iibPoN+F4tTtAOcBhIRxdARRmPrNvPDQY77U5HHFH5izY7mJcMuwCb30rteud6JZLIkq5nqMyN35e/xMDG3fS0VVE/JKybyWGtFq2QUWkBpO5CJSDs1x8XhV97ZEcwMACdH/9rcYV4LrC0ZOSnZxAxHV/dcvaylKQMTloXiO0EvQQvS5IMXdGqEC5685hBOgTo7A/36fUmNMhoM04Sh3ZL7KwGd47kuyqbHhfKjG8gQIFAFPgUwR4Aj5Ph4JoRs2YAUpeOBPKXwRsgVWHpPT37c2t8x4u/g7mFJS1YYd1t7hroxKADFjod+qWwgUXZgqXJpJELlEycc7Ryncu0pNlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dPnnU/bovfMLMFk7Fz37gjc4NKrWmTRVmNUudIt/WoA=; b=gEeLU5NJESNm6jRKV/96cFsWKWOdI0wID3zHh6yl06W0t3zJkanADPBlOmXgnyHSZ+n/s6Uw/zY003GYBjr0bFKoQpCM6+JJyFOVZ0HIsdfT3NhjTd2leDefly9Zx+GMpDKRQjvjTWlgJSV3PY2ICZpICdEoTEokjO2vdt+A5Co= From: Bertrand Marquis To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Luca Fancellu Subject: Re: [PATCH v12 02/13] xen/arm: gic-v2: Implement GIC suspend/resume functions Thread-Topic: [PATCH v12 02/13] xen/arm: gic-v2: Implement GIC suspend/resume functions Thread-Index: AQHdNjDkV92bkh6okkqfhA392pMLzbbcc6SA Date: Wed, 23 Sep 2026 15:27:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5590:EE_|GV1PR08MB7348:EE_|DU2PEPF00028D0A:EE_|DB9PR08MB6603:EE_ X-MS-Office365-Filtering-Correlation-Id: 589f9c86-765a-45c8-2b84-08df1987422d x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|376014|1800799024|366016|10067099003|4143699003|6133799003|56012099006|22082099003|18002099003|20046099003|11063799006|38070700021; X-Microsoft-Antispam-Message-Info-Original: rTzAftJg4uhfGextcAJIwRRojvra6mryEVuipo06qWgXJ7oHgO7+8lJ8RvxGHcWwnJ2JEo8nHhh6EdgnegiObv9+jkL5zSxeOwp1VEykG9C6HOwN21JOrqC9GlfzTHT2QViJR+wY4k92bUmsolYv9vt0Av8l2LO+WaG4y1YYuiX+fEHwle4C6BiLzXisyadXYeqj7uZyx4vCMr0E/J2qQtay5kiwoZ1brOsHjg6fA3HE16cj+sGIUL3Is6VmKnZtVYooVbd6Q/YDn/sxdcQdSpRSLZkwqkBvpoJsINzcixHcjVqm3NHqKWiRfiZAbPY/bOdP4y93YVQeypGyuViyM3BA6n59gMeEshVlRp+LCSKJP1bn8WyRy1HXLbXvK+ZIM508frAkK2kQJ5S8NkSbHf5n9dBHoLvQLUMGX35TKo/Bs4ONLdxjyrSj/cdnrPqeG/ufXC4Wj81vWlHwphQRD+NGL+6+wtLWN764cZw9bQUdSx04LvgOnrRzXhY4ciqlmV0yWHd5Rw5cJawzrsYWWfByUyDCgAAecNe1T5o7WJJQb76P3sN50FntdaRJL6VgNWOPP2inZYjEv2Q0ZTh6XS1afYlgDONXH471yGjtB0H4chl6hjHJorrfqbb3zoPuY6q1nfF4ARzWemXmao/jiiIk3MM/+v7+H6uhUyOZgTmq+sM0+vv/PXDFMqHuEfmBKqYi5jVEwazcMwj9jvLMoNaxzSUrGWReEw1jTPPRTc0= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5590.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(376014)(1800799024)(366016)(10067099003)(4143699003)(6133799003)(56012099006)(22082099003)(18002099003)(20046099003)(11063799006)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <63FF8F03AD858D4AB1775DC97014E8DB@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: W2F3/revURwvDmq7JWWOvGwwvEmfVYsOsqFB+NPR82K2jVSPQWS9apz3ot68lggS/nuKk5wJqavRpzsAgMycFicN4AtO15bZ/zVawH89zK/CrN6U9Pyt4J4fMbLJg757VcmBPo4/RcdZzwyo3U188vV9YU0/5h/NEOH8jphOH0bxIAuWntuOBZ1UDcppI1g94LFXatzW7ln3iMtJn8uSwI/JrzXwVwHwK2uz6V/TVja+5dLXNewRSvRF6rrk7cxGDjcRI0r2TfLISfWFHSboP2b3p0vAET2LoX3qNNZseTFIpTvqdaKF3Ns8dfKfJJeFi5tRKp3rJbFXOsslazL3kw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB7348 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF00028D0A.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 20691a91-c1ee-43fa-82aa-08df19872bf4 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|376014|36860700016|35042699022|14060799003|82310400026|6133799003|10067099003|11063799006|56012099006|4143699003|18002099003|20046099003|22082099003; X-Microsoft-Antispam-Message-Info: BiRyb4jNQwewQD60SJ6FssKHQGtHE3B+YjBcNBm/AfngYFyX6WWYJbCkfXpMp+kR8zmRJi/8WIQjJkPhTAM4BZbCSgBAsz4fU4pVpl4iqjtvFjrghI3RM/8kaWmiznkFwm4xpdAhFdeaFd2NbbfD0aYNpDtZv/ivGSjr/AULAjsS7hvqP27BaPKeKohBaHF4lVaFQl3zY+NXXvwbA0D3Ye5ziDCpW7zLDyWi9G4xJZNV7NqyBdhWA68SyFWyH9drlK+JasaqRAFZZNhb3057IsOfFWRds/zIhju2pzuAt1nBZPkeVVATPm5nWgUF35fd08ARIMj560621gIRNji0WUpqyQv0awb/8zQNRgutnPhldEM2epCysH/uD2bYHI3wMR7xu4GPQgQxFmG4U3LdeflihRT7SDZBqIBNxrFNVjtoigGeMwYtYB3B936dXIwOZg48JwNiegWjm34uKgCWq/PeZn18Q4Qsm4FAHIJMVZ0KTPehEsbwKyqkVFXhdnEeZ9D7KF4x1RTM3sxE4xLGCf0hgqy3o2KzuwzeN3fGtkZk92lu1WqQXvz3n6TRStysOF0RrgwO/+tKLxkJ+083TVhIgDwNxDB9vF9KQCoy7TgqUUmdG9eCwhj4FrSsWTVPTJKG0QIJKjH0775RRGiW40FlCbGlHdZB9D0lIUSHO6HU5Zjqz3DyI5k2W+futDRtp1JYoeIC5Qnbw3is/NYMkQ== X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(376014)(36860700016)(35042699022)(14060799003)(82310400026)(6133799003)(10067099003)(11063799006)(56012099006)(4143699003)(18002099003)(20046099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: TM7TQKvyQTZbe9s1Q1eCm/QOnFQmdygG+BrqiL6069AWJ8KPPXb+aqd9W9fW2kX4BTUZDK7eddqnFsHOIIBtj+FniJnuW429JPPhmoyL03LP6oikgtrNKthihFFmxrTT0OR+J8l2SeiFfJQsCKrSO6PdBfMzPEhYyLIyJnlDrzxxczR5p0QZ4tqk4rAXccuGUwMjs4+KRkK/xwlpW/ne3zJ5EzP7Pn7bqTBn4axvDV70QS6ypTNCTNVJZwBbaRZH22L4NvDY88ZX0YYNPlAK9eqiv5V4zgh9GqctTPmnkCFkqCDSZKOMU0SnvqM0VMq2I3d3hi/VYUcgjnwpTJ2ZWdN/dObPqqYnCnZfcaF0Io2oWasVjvMaMS+R3VTFnfOrlAG6TEzlaD/Ewy2+nMaL/+u27p1o0J8c4UhV6zvZgS6bUjBtQ/Y5lYLtdHLSR8Gb X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 15:28:03.0358 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 589f9c86-765a-45c8-2b84-08df1987422d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF00028D0A.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6603 X-purgate-ID: tlsNG-c201ff/1790177289-F4EA12A1-AD888603/0/0 X-purgate-type: clean X-purgate-size: 14912 Hi Mykola, Sorry for the delay to review this serie. > On 27 Aug 2026, at 16:31, Mykola Kvach wrote: >=20 > From: Mirela Simonovic >=20 > System suspend may lead to a state where GIC would be powered down. > Therefore, Xen should save/restore the context of GIC on suspend/resume. >=20 > Note that the context consists of states of registers which are > controlled by the hypervisor. Other GIC registers which are accessible > by guests are saved/restored on context switch. >=20 > Transient physical SGI pending state (GICD_CPENDSGIRn/GICD_SPENDSGIRn) > is intentionally excluded. CPU-interface active-priority state is also > not restored across suspend/resume. Xen reaches the final suspend path > at a quiescent point, so there is no active-priority execution context > to replay after resume. Enforce this with a runtime check after > disabling the CPU interface: if any implemented GICC_APRn word is still > non-zero, restore GICC_CTLR and abort suspend with -EBUSY. You mention SGI pending state but you do not say what would happen for PPI/= SPI pending state, and the patch does not look at or save/restore GICD_ISPENDR. Can you clarify what is expected for those? Cheers Bertrand >=20 > This does not apply to distributor active state. With GICv2 EOImode=3D=3D= 1, > EOIR only drops the interrupt priority; final deactivation is a separate > step. For guest-routed interrupts, Xen can have already EOIed the physica= l > IRQ while deactivation is still pending on the vGIC/GICV path. Therefore > GICD_ISACTIVER is preserved as architectural in-flight interrupt state. >=20 > Signed-off-by: Mirela Simonovic > Signed-off-by: Saeed Nowshadi > Signed-off-by: Mykyta Poturai > Signed-off-by: Mykola Kvach > Reviewed-by: Luca Fancellu > --- > Changes in V10: > - Limit GICC_APR active-priority checks to APR bits visible from > the Xen CPU-interface view. > - Avoid touching reserved GICD_IPRIORITYR/GICD_ITARGETSR words when the > last implemented interrupt block is partial. > - Restore distributor configuration before restoring interrupt enable > state, so GICD_ICFGR is written while the corresponding interrupts are > disabled. >=20 > Changes in V9: > - Skip saving/restoring GICD_ITARGETSR0..7 because SGI/PPI target > registers hold no state (read-only on MP, RAZ/WI on UP). > - Add a runtime GICC_APRn quiescence check after disabling the CPU > interface, and restore GICC_CTLR before returning -EBUSY. >=20 > Changes in V8: > - disable cpu interface + distributor before suspend > - change 0xffffffff to GENMASK; > - cosmetic changes; >=20 > Changes in V7: > - Allocate one contiguous memory block for the GICv2 dist suspend context= . > - gicv2_resume() no longer unconditionally re-enables the distributor/CPU > interface; it now writes back the saved CTLR values as-is. > - gicv2_alloc_context() now returns 0 on success and panics on failure, > since suspend context allocation is not recoverable. > --- > xen/arch/arm/gic-v2.c | 226 +++++++++++++++++++++++++++++++++ > xen/arch/arm/gic.c | 29 +++++ > xen/arch/arm/include/asm/gic.h | 12 ++ > 3 files changed, 267 insertions(+) >=20 > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c > index 43a379fdda..a0ef6ffc7f 100644 > --- a/xen/arch/arm/gic-v2.c > +++ b/xen/arch/arm/gic-v2.c > @@ -1108,6 +1108,223 @@ static int gicv2_iomem_deny_access(struct domain = *d) > return iomem_deny_access(d, mfn, mfn + nr - 1); > } >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + > +/* This struct represents block of 32 IRQs */ > +struct irq_block { > + uint32_t icfgr[2]; /* 2 registers of 16 IRQs each */ > + uint32_t ipriorityr[8]; > + uint32_t isenabler; > + uint32_t isactiver; > + uint32_t itargetsr[8]; > +}; > + > +/* GICv2 registers to be saved/restored on system suspend/resume */ > +struct gicv2_context { > + /* GICC context */ > + struct cpu_ctx { > + uint32_t ctlr; > + uint32_t pmr; > + uint32_t bpr; > + } cpu; > + > + /* GICD context */ > + struct dist_ctx { > + uint32_t ctlr; > + /* Includes banked SGI/PPI state for the boot CPU. */ > + struct irq_block *irqs; > + } dist; > +}; > + > +static struct gicv2_context gic_ctx; > + > +#define GICV2_NR_APRS 4 > +#define GICV2_APR_BITS_PER_REG 32U > + > +static int gicv2_check_active_priorities(uint32_t bpr) > +{ > + unsigned int i, apr_bits, nr_aprs; > + > + /* > + * Xen writes GICC_BPR to 0 during CPU init and does not change it. = Per > + * IHI0048B.b, a write below the implementation minimum reads back a= s the > + * minimum supported BPR value. Table 4-47 maps that Xen-visible BPR= value > + * to the visible GICC_APR bits. Avoid reading APR registers outs= ide > + * that visible range. > + * > + * This covers both GICv2 with and without Security Extensions. > + */ > + apr_bits =3D 1U << (7 - (bpr & 0x7)); > + nr_aprs =3D DIV_ROUND_UP(apr_bits, GICV2_APR_BITS_PER_REG); > + > + ASSERT(nr_aprs <=3D GICV2_NR_APRS); > + > + for ( i =3D 0; i < nr_aprs; i++ ) > + { > + unsigned int bits =3D min(GICV2_APR_BITS_PER_REG, > + apr_bits - i * GICV2_APR_BITS_PER_REG); > + uint32_t mask =3D GENMASK(bits - 1, 0); > + uint32_t apr =3D readl_gicc(GICC_APR + i * 4) & mask; > + > + if ( !apr ) > + continue; > + > + printk(XENLOG_ERR "GICv2: suspend aborted: GICC_APR%u=3D%#08x\n"= , > + i, apr); > + return -EBUSY; > + } > + > + return 0; > +} > + > +static int gicv2_suspend(void) > +{ > + unsigned int i, blocks =3D DIV_ROUND_UP(gicv2_info.nr_lines, 32); > + int ret; > + > + /* Save GICC_CTLR configuration. */ > + gic_ctx.cpu.ctlr =3D readl_gicc(GICC_CTLR); > + > + /* Quiesce the GIC CPU interface before suspend. */ > + gicv2_cpu_disable(); > + > + gic_ctx.cpu.bpr =3D readl_gicc(GICC_BPR); > + > + /* > + * Check the active-priority state for the group Xen drives through = the > + * CPU interface. GICC_CTL_ENABLE enables Group 0 without SecurityEx= tn and > + * Group 1 in Xen's Non-secure view with SecurityExtn, and in both c= ases > + * the relevant state is visible through GICC_APRn. The APR layout i= s > + * implementation-defined, so only test the bits visible from Xen's = CPU > + * interface view instead of reading every possible APR register. > + */ > + ret =3D gicv2_check_active_priorities(gic_ctx.cpu.bpr); > + if ( ret ) > + { > + writel_gicc(gic_ctx.cpu.ctlr, GICC_CTLR); > + return ret; > + } > + > + gic_ctx.cpu.pmr =3D readl_gicc(GICC_PMR); > + > + /* Save GICD configuration */ > + gic_ctx.dist.ctlr =3D readl_gicd(GICD_CTLR); > + writel_gicd(0, GICD_CTLR); > + > + for ( i =3D 0; i < blocks; i++ ) > + { > + struct irq_block *irqs =3D gic_ctx.dist.irqs + i; > + size_t j, off =3D i * sizeof(irqs->isenabler); > + size_t nr_regs =3D ARRAY_SIZE(irqs->ipriorityr); > + > + if ( i =3D=3D blocks - 1 ) > + nr_regs =3D DIV_ROUND_UP(gicv2_info.nr_lines - i * 32, 4); > + > + irqs->isenabler =3D readl_gicd(GICD_ISENABLER + off); > + > + /* > + * Save distributor active state as part of the hypervisor-owned > + * physical interrupt state. In GICv2 EOImode=3D=3D1, EOIR only = drops the > + * priority; final deactivation is separate. For guest-routed > + * interrupts, Xen may have EOIed the physical IRQ while the gue= st/vGIC > + * side still owns the deactivate step. Therefore GICD_ISACTIVER= can > + * legitimately remain set even though transient SGI pending sta= te and > + * CPU-interface active-priority state are expected to be quiesc= ed here. > + */ > + irqs->isactiver =3D readl_gicd(GICD_ISACTIVER + off); > + > + off =3D i * sizeof(irqs->ipriorityr); > + for ( j =3D 0; j < nr_regs; j++ ) > + irqs->ipriorityr[j] =3D readl_gicd(GICD_IPRIORITYR + off + j= * 4); > + > + /* > + * GICD_ITARGETSR0..7 cover SGIs/PPIs and hold no state to save: > + * they are read-only on multiprocessor implementations and RAZ/= WI > + * on uniprocessor implementations. > + */ > + if ( i ) > + { > + off =3D i * sizeof(irqs->itargetsr); > + for ( j =3D 0; j < nr_regs; j++ ) > + irqs->itargetsr[j] =3D readl_gicd(GICD_ITARGETSR + off += j * 4); > + } > + > + off =3D i * sizeof(irqs->icfgr); > + for ( j =3D 0; j < ARRAY_SIZE(irqs->icfgr); j++ ) > + irqs->icfgr[j] =3D readl_gicd(GICD_ICFGR + off + j * 4); > + } > + > + return 0; > +} > + > +static void gicv2_resume(void) > +{ > + unsigned int i, blocks =3D DIV_ROUND_UP(gicv2_info.nr_lines, 32); > + > + gicv2_cpu_disable(); > + /* Disable distributor */ > + writel_gicd(0, GICD_CTLR); > + > + for ( i =3D 0; i < blocks; i++ ) > + { > + struct irq_block *irqs =3D gic_ctx.dist.irqs + i; > + size_t j, off =3D i * sizeof(irqs->isenabler); > + size_t nr_regs =3D ARRAY_SIZE(irqs->ipriorityr); > + > + if ( i =3D=3D blocks - 1 ) > + nr_regs =3D DIV_ROUND_UP(gicv2_info.nr_lines - i * 32, 4); > + > + writel_gicd(GENMASK(31, 0), GICD_ICENABLER + off); > + > + off =3D i * sizeof(irqs->icfgr); > + for ( j =3D 0; j < ARRAY_SIZE(irqs->icfgr); j++ ) > + writel_gicd(irqs->icfgr[j], GICD_ICFGR + off + j * 4); > + > + off =3D i * sizeof(irqs->ipriorityr); > + for ( j =3D 0; j < nr_regs; j++ ) > + writel_gicd(irqs->ipriorityr[j], GICD_IPRIORITYR + off + j *= 4); > + > + /* > + * GICD_ITARGETSR0..7 cover SGIs/PPIs and hold no state to save: > + * they are read-only on multiprocessor implementations and RAZ/= WI > + * on uniprocessor implementations. > + */ > + if ( i ) > + { > + off =3D i * sizeof(irqs->itargetsr); > + for ( j =3D 0; j < nr_regs; j++ ) > + writel_gicd(irqs->itargetsr[j], GICD_ITARGETSR + off + j= * 4); > + } > + > + off =3D i * sizeof(irqs->isenabler); > + writel_gicd(irqs->isenabler, GICD_ISENABLER + off); > + > + writel_gicd(GENMASK(31, 0), GICD_ICACTIVER + off); > + writel_gicd(irqs->isactiver, GICD_ISACTIVER + off); > + } > + > + /* Restore distributor control state. */ > + writel_gicd(gic_ctx.dist.ctlr, GICD_CTLR); > + > + /* Restore GIC CPU interface configuration */ > + writel_gicc(gic_ctx.cpu.pmr, GICC_PMR); > + writel_gicc(gic_ctx.cpu.bpr, GICC_BPR); > + > + /* Enable GIC CPU interface */ > + writel_gicc(gic_ctx.cpu.ctlr, GICC_CTLR); > +} > + > +static void __init gicv2_alloc_context(void) > +{ > + uint32_t blocks =3D DIV_ROUND_UP(gicv2_info.nr_lines, 32); > + > + gic_ctx.dist.irqs =3D xzalloc_array(struct irq_block, blocks); > + if ( !gic_ctx.dist.irqs ) > + panic("Failed to allocate memory for GICv2 suspend context\n"); > +} > + > +#endif /* CONFIG_SYSTEM_SUSPEND */ > + > #ifdef CONFIG_ACPI > static unsigned long gicv2_get_hwdom_extra_madt_size(const struct domain = *d) > { > @@ -1312,6 +1529,11 @@ static int __init gicv2_init(void) >=20 > spin_unlock(&gicv2.lock); >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + /* Allocate memory to be used for saving GIC context during the susp= end */ > + gicv2_alloc_context(); > +#endif /* CONFIG_SYSTEM_SUSPEND */ > + > return 0; > } >=20 > @@ -1355,6 +1577,10 @@ static const struct gic_hw_operations gicv2_ops = =3D { > .map_hwdom_extra_mappings =3D gicv2_map_hwdom_extra_mappings, > .iomem_deny_access =3D gicv2_iomem_deny_access, > .do_LPI =3D gicv2_do_LPI, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend =3D gicv2_suspend, > + .resume =3D gicv2_resume, > +#endif /* CONFIG_SYSTEM_SUSPEND */ > }; >=20 > /* Set up the GIC */ > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index 078049e741..ffc11f36a1 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -438,6 +438,35 @@ int gic_iomem_deny_access(struct domain *d) > return gic_hw_ops->iomem_deny_access(d); > } >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + > +int gic_suspend(void) > +{ > + /* Must be called by boot CPU#0 with interrupts disabled */ > + ASSERT(!local_irq_is_enabled()); > + ASSERT(!smp_processor_id()); > + > + if ( !gic_hw_ops->suspend || !gic_hw_ops->resume ) > + return -ENOSYS; > + > + return gic_hw_ops->suspend(); > +} > + > +void gic_resume(void) > +{ > + /* > + * Must be called by boot CPU#0 with interrupts disabled after gic_s= uspend > + * has returned successfully. > + */ > + ASSERT(!local_irq_is_enabled()); > + ASSERT(!smp_processor_id()); > + ASSERT(gic_hw_ops->resume); > + > + gic_hw_ops->resume(); > +} > + > +#endif /* CONFIG_SYSTEM_SUSPEND */ > + > static int cpu_gic_callback(struct notifier_block *nfb, > unsigned long action, > void *hcpu) > diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gi= c.h > index ee2c26adb4..29bb9a89a4 100644 > --- a/xen/arch/arm/include/asm/gic.h > +++ b/xen/arch/arm/include/asm/gic.h > @@ -301,6 +301,12 @@ extern int gicv_setup(struct domain *d); > extern void gic_save_state(struct vcpu *v); > extern void gic_restore_state(struct vcpu *v); >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > +/* Suspend/resume */ > +extern int gic_suspend(void); > +extern void gic_resume(void); > +#endif /* CONFIG_SYSTEM_SUSPEND */ > + > /* SGI (AKA IPIs) */ > enum gic_sgi { > GIC_SGI_EVENT_CHECK, > @@ -444,6 +450,12 @@ struct gic_hw_operations { > int (*iomem_deny_access)(struct domain *d); > /* Handle LPIs, which require special handling */ > void (*do_LPI)(unsigned int lpi); > +#ifdef CONFIG_SYSTEM_SUSPEND > + /* Save GIC configuration due to the system suspend */ > + int (*suspend)(void); > + /* Restore GIC configuration due to the system resume */ > + void (*resume)(void); > +#endif /* CONFIG_SYSTEM_SUSPEND */ > }; >=20 > extern const struct gic_hw_operations *gic_hw_ops; > --=20 > 2.43.0 >=20 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:35:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:35:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430908.1653314 (Exim 4.92) (envelope-from ) id 1x9P0Z-0000k1-NN; Wed, 23 Sep 2026 15:35:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430908.1653314; Wed, 23 Sep 2026 15:35:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P0Z-0000ju-K5; Wed, 23 Sep 2026 15:35:43 +0000 Received: by outflank-mailman (input) for mailman id 1430908; Wed, 23 Sep 2026 15:35:42 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P0X-0000jo-Sm for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:35:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9P0S-009bbB-9M for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:35:41 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f1a6-8faa-0a2a0a5109dd-0a2a450bc980-44 for ; Wed, 23 Sep 2026 17:35:36 +0200 Received: from [52.101.72.71] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f1c7-b7e8-0a2a450b0019-34654847adba-3 for ; Wed, 23 Sep 2026 17:35:36 +0200 Received: from AS4P191CA0003.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:5d5::18) by AM9PR08MB6052.eurprd08.prod.outlook.com (2603:10a6:20b:2d5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.4; Wed, 23 Sep 2026 15:35:27 +0000 Received: from AM2PEPF00070CF9.eurprd02.prod.outlook.com (2603:10a6:20b:5d5:cafe::3c) by AS4P191CA0003.outlook.office365.com (2603:10a6:20b:5d5::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.16 via Frontend Transport; Wed, 23 Sep 2026 15:35:27 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AM2PEPF00070CF9.mail.protection.outlook.com (10.167.242.11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Wed, 23 Sep 2026 15:35:27 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DB4PR08MB8199.eurprd08.prod.outlook.com (2603:10a6:10:381::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.17; Wed, 23 Sep 2026 15:34:53 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 15:34:52 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=SNBFrmEeTbVn2m/sxaI0E6dPMvbNPIioFw+2PXzSwvVIbRoqh6i0Cim8C9GxXDXzbipi/zvtarhQtyRPBeQGfUtRA+m2uohlawyP53e9wpaYqSDSwWS8doQbKoPKUT1sxvkU0vDmEsKwu5rolK3SQxKLO8UwSVlchnli34k02zIcBu6XtCAibGL+E7r7h9M8e0dDKopb62p6jWyi4PQWa9JKEueenRHyYPZ4vLIl9vvVTioPP1j6rwd15T6vQExxTqEkQjw2miuBM+m5RbE2fXZlriBGGN1klXLTmD0EnYTV0LecgVpHmEaRmT67y2OeD/c3nEkTkiHXYT7qqG8hxA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gyaXTMpxlPJmtJCjn80suRr8TvenbaZ8yXgtRm2S5k8=; b=ZnbOJxNle0JMhnk0u0pivVMxzRKf74ukk9GhX+EuuUJcjLNM+JBqiY1yiDbRrCBh0c+L4yFwPnqgNfXsBq9DjHJjANUHVNRmv18VCcKbha0PCP1NoCTBqTZ3qsEfnrNgd8ObGF23XblkQ96N7avRIslCex7ZTJhBoDGGkmv/7BRvPgo37TPR6e8zmd4k8mFUGWRNYpLdOuOJ59xaXyygiXNglcvKqOMo9jWut9jwYmw1yjueOPnFnlv0q1f6UvPT2cRjpu2094gw8YuqJDG0lfyS7wbYG9QP9lWaVhRyFqQWPEjSqgNDHyf8E3CpG9DhORBrhHXsbyLI0fpVgJn7Og== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=epam.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gyaXTMpxlPJmtJCjn80suRr8TvenbaZ8yXgtRm2S5k8=; b=RhFhqAzekafF+jmhlfoSDmqrNbur/ZuBWvMkANt7MQy5OsBWWhkEQnQpMd/n77yVwyhq8wsg5jRbyi2aGT0Ro94g610e6Nc9PSIGP6rDs0hFNzSM9RUY25DWlHtDCtTPz9iOicD+LmY5dBA2fzVQOJYM7mZmrmlsSgaRxQ69feM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=v+SK44WlzRAwLf+H22Hd23+lDqa2S7ygRC/fJYN/tIltxCln8ps4LLA8xgcgsKU54d77uIIsb48kplp1o28y/D0A4VoKjon1wJ5B+Kd6PTSxcnF4xn2RQzXMO03QqZOnKKbMFPkEMdG9/Qleeo7OquldXEF0OBPc6UBjAioiXMh5lKtjpHhe0wRGSroqEFg54/mOtpyBD/Mo8TILtM7s+2hu/mcrT3SQUy+R8XdVHmMJwuh24VMUAEIzY8ATJBRCxDNlhUPDcND0r2YXdHAV9VNd4zN5yTIymbYIsWM7EJBXyJWi4mflv3mfEaUwmNJwFGbmfEzV6ynYsFPnW5TO0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gyaXTMpxlPJmtJCjn80suRr8TvenbaZ8yXgtRm2S5k8=; b=wepTQW3qACki8wxIGeYryLJoB5VeX7MlhOiPtOf7MtqYUFfeQBGqMG6Qfnz2Qlo6ipN5nfsZzI1bYZKSNPf0/JPOiRdktgxXGpmYmtN7PaGjIlRsM+M8dLx2zlJskm7tvhswA8KhYBn3/GYbBuPNz+UVgX87sTP2ga0plBlfKGF/E46bnwB8RB3S2cG8ivTs56G+lEVulRfts3o1M4TedOkMAjH8t3NoFbEXzRVMqAS5r2Xq3vblckyL7zb3P65vHiiSTUhmHLCaIHgLDVl13XbgMQCpEss/RWPS/psy9Qk4m5kcb9KhpF91/l0NAz12UfscHXZem1jP9SUN8Bjm5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gyaXTMpxlPJmtJCjn80suRr8TvenbaZ8yXgtRm2S5k8=; b=RhFhqAzekafF+jmhlfoSDmqrNbur/ZuBWvMkANt7MQy5OsBWWhkEQnQpMd/n77yVwyhq8wsg5jRbyi2aGT0Ro94g610e6Nc9PSIGP6rDs0hFNzSM9RUY25DWlHtDCtTPz9iOicD+LmY5dBA2fzVQOJYM7mZmrmlsSgaRxQ69feM= From: Bertrand Marquis To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Luca Fancellu Subject: Re: [PATCH v12 03/13] xen/arm: gic-v3: tolerate retained redistributor LPI state across CPU_OFF Thread-Topic: [PATCH v12 03/13] xen/arm: gic-v3: tolerate retained redistributor LPI state across CPU_OFF Thread-Index: AQHdNjDlOJD2OeV6HEaZdpj45JQE7rbcdbQA Date: Wed, 23 Sep 2026 15:34:52 +0000 Message-ID: <427F337F-4D3C-4DEE-9978-5B1AD3AB23D5@arm.com> References: <54a655ad51d994b46dff43e67c969a31772cec4b.1787838455.git.mykola_kvach@epam.com> In-Reply-To: <54a655ad51d994b46dff43e67c969a31772cec4b.1787838455.git.mykola_kvach@epam.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DB4PR08MB8199:EE_|AM2PEPF00070CF9:EE_|AM9PR08MB6052:EE_ X-MS-Office365-Filtering-Correlation-Id: fae6f32a-cd10-4aa1-6428-08df19884afc x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|38070700021|4143699003|56012099006|11063799006|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info-Original: pUmXKmnDUvRK35o66EAgG14yVQQf2FNSYrq4MdlIdZzffU/oZCAANdQOf507+qUDYDT3Hbe8w15NNQIz1ZO7gF5ehgAaCYU9QXF3bGdKMZuf8NaaAPvEuDHq2Gt1iB3TwiijIIdr8lWNqSUucpzAPWCKqZ/EHb387FuQWAQbYvKK5K94fafHir960rcZS8Z1PqR6BqQZiMTP9ng4xJJhqBiY7J9LiqYG8zzGa+P/KH2nQASf0vEqZGXrp44SLUfRqMW1sYgQMhR2IP9kFJpkbM50Ov8d/M/UECZ7ncTMdfPXDil5uLaQbrWLZzy7p4SNSKtLwgKQDBVmUjwCeHXp5n8c21ssy6M/8PQ/ap7FNT0O4rVoce7ckMhHsYf08FukBz58ds+3UktBDcowrpYXlNUC8kbK4YKL6VSj3TC0PVxUjo7hlO6IXMmzw93b2Y6bCGkX3ombOwEyl2tCG7hgjeZcLoZlt7Baxu+eetW3t1RIj1IEFjwmxu/tuKMK+ruwE7E1M8bo8nGHLoghOLcGNRmTb6cFDHcq1TaDtnkUtw7oJgZODj5rK2g3A2bi5EjWB2i38HzwPvnSSjDmnbvyeU4xxBpaqji7hvAQuYYXvsSWQFS3yxS7mBA2T+6OY3yIAmts0PBc2fcJlcALsHKRpFf1ykZYXztvRt5HBdQ9MZcKafFiwD8sWj6I+Ajq/IkOwm+EQYQquJ33FG935JOUUJRqrUH9sHzOSJjBz6siNWM= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(38070700021)(4143699003)(56012099006)(11063799006)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <93EB5DD7D5002745A6D637CD328AA19F@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: zJU1PI+pz7/4TmEnMhGnCXPzX0wA//u12nUVSGHlzrfhCbqW6JhjpLE6zNhNVqcra20mqtorxusdKJzImbrXaNM3iDfm+VbuFpVA2AuBhOompv2oif9XBCAXbdBxVAUFKmF6KskEQQF82FCs6tjo1UtygD5DuGQqaJ1U8nfMg1DM22PlolEj0V3uPvmHbVT5jVqE1xSpP5HjdpqFHhiBrGrWESd9MlCQdnF4eAYeITx4hZRlVM+i1chjDn6STFfiiWYY3JydXQ5BuwrR7RcFT5OnbSNU+Roex0sHIazphYUeL9q7d7wv4LqQJVDugvBKXYMDxW8PHNIKUmTYr1kmuw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB8199 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM2PEPF00070CF9.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 7c954f10-4c2f-4b9f-f0e4-08df19883652 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|14060799003|82310400026|36860700016|35042699022|23010399003|10067099003|6133799003|22082099003|4143699003|11063799006|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: f93ZFnDorHMrjGRSyPfLHd0hsbmXjUZMkC/mVEgx6Vw9tI4cFb5PKVOyfV/TzEgs61bl+iVv6u15J1MSid3SpdCoYASGO18OGln6Z4N1EXIaqoA5Y4Ft/vfJT2sT8pHUYbtlxG65TbptJk/m6NhLSk5+8zI7M6KSNOkaWcHolEJOHzZa/aPMNyMWzlV8V2wjt4JEaYPEwutvZNLqxhN9lR4ai4YziYSU8RpD2+/5DKOAMZe+bnqQcIc7rQiLKLSY5tyY2ajzC+sFGE2Z8N9wzwo/VP+5ZXauooslJu9XJ0/7int3EI4gSkOgF3PcXdbatryfWusQBGGN/GqmU3ofuf7T4b1jdHFggnMG0JESP1hrbhQ96J9mlFWaxqxCN9Fwe27q8+QnLg0zV/8R0ZKGT7KOE5MqBI783zBbhanm/9jzGW2c/9k7WbIuQuXRbx07L8eRrVT15UcTzjjDPN1o0d5LypEn7k50MnO4MKsb7pvxqXOU2hm+/ZUDHR+6vLvvGjKqurtPP5W1Bx69as2nGgazp5aanUlEWNPEylh5Ob5QHpcVLKVbH8S0brdl587kfJh2qpfe3PRbD8S5KclTEFhPDllcl3fPCiiLmWfaDw13yjXYeqReEKVMR+p9+dQCHNkGWeB8LtdF5HuUHBIgU7uOrc8ACWYWR5VWzIbUr0BiFoGWvXMXq0BO+p7kaxm1YMgdEjs3Z3EjLfXEXRnfnA== X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(14060799003)(82310400026)(36860700016)(35042699022)(23010399003)(10067099003)(6133799003)(22082099003)(4143699003)(11063799006)(56012099006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: h4xQVibo54IQf/9hzvWlrA1iHBad2gatx2uHfhgtkF7S9ud9Hexc5EnciwgiLI75PO6XLBrIWOYzFS/7p+xZYQkZGaBCO+Z3ykw939T7UZKaxdlPrDPdy/K491b5+2eECRPoTzvq0GcCZc9sUJupUY0keaR3Uc3S/Oy5kvD4xMMlbkV2+h7pdPV2jtyDRh8ghR+VkShGJIRMNI0isDa45ffn+1gs4BQldw6ts73OMCubu+V+GFEwW3JaWNBP4xpUdz4asyzEm4ZPnepgefMsWLsjjx76WZQzIySaKmRBGbsZA4f04QN5ldVQbx6I04894A6T9IOU8Pzj/Csi9jLjAO6GXXOLZwOzo+WQ42Y2ytlY9kXbVaHCbv1g1ufYu6H/W55hUHU6MP/BMgEPO+ouTo0AUm4oH3P+shng08We7C7/VeiVszUPH6WKCh5f3Xl8 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 15:35:27.3173 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fae6f32a-cd10-4aa1-6428-08df19884afc X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: AM2PEPF00070CF9.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6052 X-purgate-ID: tlsNG-42698a/1790177736-AAAD89EA-1943ABA5/0/0 X-purgate-type: clean X-purgate-size: 10855 Hi Mykola, > On 27 Aug 2026, at 16:31, Mykola Kvach wrote: >=20 > PSCI does not guarantee that a GICv3 redistributor is powered down across > CPU_OFF -> CPU_ON. >=20 > DEN0022F.b says CPU_OFF powers down the calling core (5.5) and CPU_ON > brings the core back with a defined initial CPU state (5.6, 6.4). > However, PSCI leaves interrupt migration and GIC re-initialization to the > supervisory software/firmware stack: the caller must migrate interrupts > away before CPU_OFF (5.5.2), and the execution context that is lost in a > powerdown state must be saved and restored by software (6.8). PSCI also > calls out GIC management explicitly in 6.8, including retargeting SPIs, > preventing PPIs/SGIs from targeting a powered down CPU, and reinitializin= g > the CPU interface after CPU_ON. >=20 > This matches the GIC architecture. IHI0069H.b Chapter 11.1 requires the P= E > and CPU interface to share a power domain, but explicitly allows the > associated redistributor, distributor, and ITS to remain powered while th= e > PE and CPU interface are off. All other GIC power-management behavior is > IMPLEMENTATION DEFINED. DEN0050D Chapter 4.2, "Generic Interrupt > Controller (GIC)", says the GICv3 redistributor may live either in the AP > core power domain or in a relatively always-on parent domain. So after > CPU_OFF -> CPU_ON a secondary CPU can legitimately come back to a live > redistributor with GICR_CTLR.EnableLPIs still set. >=20 > Handle that case in the LPI setup path instead of assuming a fully reset > redistributor. >=20 > The LPI path needs special care because the GIC spec makes redistributor > LPI state sticky and partially implementation defined. IHI0069H.b 5.1.1 > and 5.1.2 say that changing GICR_PROPBASER or GICR_PENDBASER while > GICR_CTLR.EnableLPIs =3D=3D 1 is UNPREDICTABLE. After clearing EnableLPIs= , > software must wait for GICR_CTLR.RWP =3D=3D 0 before touching the pending > table. The architecture also permits implementations where, once > EnableLPIs has been set, clearing it again is not guaranteed to work. > Where an ITS is present, the spec strongly recommends moving LPIs to > another redistributor before clearing EnableLPIs. >=20 > Because of that, treat a retained EnableLPIs state as valid when the > redistributor still points at Xen's expected PROPBASER/PENDBASER tables. > Only try to clear EnableLPIs when the retained configuration does not > match Xen's state, and wait for RWP before reprogramming the tables. >=20 > This is also consistent with platform firmware reality: PSCI and the GIC > architecture allow platform-specific redistributor power handling, and no= t > all platform firmware implementations force a full redistributor power-of= f > through implementation-defined controls during CPU_OFF. Xen therefore nee= ds > to tolerate retained redistributor state on secondary CPU bring-up. >=20 > Keep gicv3_populate_rdist() resident as well, because gicv3_cpu_init() > reuses it on secondary CPU bring-up after init. >=20 > Tested using Xen's non-boot CPU disable/enable path on Arm > FVP_Base_RevC-2xAEMvA, both with and without: > -C gic_distributor.allow-LPIEN-clear=3D1 > -C gic_distributor.GICR-clear-enable-supported=3D1 > and on Orange Pi 5. >=20 > Signed-off-by: Mykola Kvach > Reviewed-by: Luca Fancellu > --- > Changes in v10: > - Drop unrelated gicv3_populate_rdist() printk() format cleanups to keep > the patch focused on retained redistributor LPI state. >=20 > Changes in v9: > - move gicv3_do_wait_for_rwp prototype from its related header to gic.h > - drop __init from gicv3_populate_rdist(), which is reused on secondary > CPU bring-up after boot > - changed print format for smp_processor_id in gicv3_populate_rdist func > - cosmetic changes > --- > xen/arch/arm/gic-v3-lpi.c | 77 +++++++++++++++++++++++++++++++++- > xen/arch/arm/gic-v3.c | 15 ++++--- > xen/arch/arm/include/asm/gic.h | 4 ++ > 3 files changed, 90 insertions(+), 6 deletions(-) >=20 > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > index 9ee338edc2..847da26ff7 100644 > --- a/xen/arch/arm/gic-v3-lpi.c > +++ b/xen/arch/arm/gic-v3-lpi.c > @@ -81,6 +81,13 @@ static DEFINE_PER_CPU(struct lpi_redist_data, lpi_redi= st); > #define MAX_NR_HOST_LPIS (lpi_data.max_host_lpi_ids - LPI_OFFSET) > #define HOST_LPIS_PER_PAGE (PAGE_SIZE / sizeof(union host_lpi)) >=20 > +#define GICR_PROPBASER_XEN_MASK GENMASK_ULL(51, 12) > +/* > + * For retained redistributor state, match the pending table by address = only. > + * Attribute bits such as PTZ may not read back with the programmed valu= e. > + */ > +#define GICR_PENDBASER_XEN_MASK GENMASK_ULL(51, 16) > + > static union host_lpi *gic_get_host_lpi(uint32_t plpi) > { > union host_lpi *block; > @@ -296,6 +303,60 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdi= st_base) > return 0; > } >=20 > +static uint64_t gicv3_lpi_expected_proptable(void) > +{ > + return virt_to_maddr(lpi_data.lpi_property); > +} > + > +static uint64_t gicv3_lpi_expected_pendtable(void) > +{ > + return virt_to_maddr(this_cpu(lpi_redist).pending_table); > +} > + > +static bool gicv3_lpi_tables_match(void __iomem *rdist_base) > +{ > + uint64_t propbase, pendbase; > + > + if ( !lpi_data.lpi_property || !this_cpu(lpi_redist).pending_table ) > + return false; > + > + propbase =3D readq_relaxed(rdist_base + GICR_PROPBASER); > + pendbase =3D readq_relaxed(rdist_base + GICR_PENDBASER); > + > + return ((propbase & GICR_PROPBASER_XEN_MASK) =3D=3D > + (gicv3_lpi_expected_proptable() & GICR_PROPBASER_XEN_MASK)) = && > + ((pendbase & GICR_PENDBASER_XEN_MASK) =3D=3D > + (gicv3_lpi_expected_pendtable() & GICR_PENDBASER_XEN_MASK)); > +} > + > +static int gicv3_lpi_disable_lpis(void __iomem *rdist_base) > +{ > + uint32_t reg =3D readl_relaxed(rdist_base + GICR_CTLR); > + int ret; > + > + if ( !(reg & GICR_CTLR_ENABLE_LPIS) ) > + return 0; > + > + writel_relaxed(reg & ~GICR_CTLR_ENABLE_LPIS, rdist_base + GICR_CTLR)= ; > + > + /* > + * The spec only guarantees programmability when we have observed th= e bit > + * cleared. Where clearing is supported, RWP must reach 0 before tou= ching > + * PROPBASER/PENDBASER again. > + */ > + wmb(); > + > + ret =3D gicv3_do_wait_for_rwp(rdist_base, GICR_CTLR_RWP); > + if ( ret ) > + return ret; > + > + reg =3D readl_relaxed(rdist_base + GICR_CTLR); > + if ( reg & GICR_CTLR_ENABLE_LPIS ) > + return -EBUSY; > + > + return 0; > +} > + > /* > * Tell a redistributor about the (shared) property table, allocating one > * if not already done. > @@ -374,7 +435,21 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base) > /* Make sure LPIs are disabled before setting up the tables. */ > reg =3D readl_relaxed(rdist_base + GICR_CTLR); > if ( reg & GICR_CTLR_ENABLE_LPIS ) > - return -EBUSY; > + { > + if ( gicv3_lpi_tables_match(rdist_base) ) > + return -EBUSY; I am wondering if there is a corner case when a CPU is unplugged and then plugged back in. free_percpu_area() eventually frees the per-CPU area containing lpi_redist.pending_table, but not the table itself. On the next cpu_up(), gicv3_lpi_allocate_pendtable() allocates a new table, and I canno= t find where the old one is freed. If the redistributor kept EnableLPIs=3D1 and GICR_PENDBASER pointing to the old table, wouldn't gicv3_lpi_tables_match() fail?=20 What will happen if EnableLPIs cannot be cleared ? (i think this is somethi= ng possible in the hardware).=20 Cheers Bertrand > + > + ret =3D gicv3_lpi_disable_lpis(rdist_base); > + if ( ret =3D=3D -EBUSY ) > + { > + printk(XENLOG_ERR > + "GICv3: CPU%u: LPIs still enabled with unexpected red= istributor tables\n", > + smp_processor_id()); > + return -EINVAL; > + } > + if ( ret ) > + return ret; > + } >=20 > ret =3D gicv3_lpi_set_pendtable(rdist_base); > if ( ret ) > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > index acdac22953..b16888ad84 100644 > --- a/xen/arch/arm/gic-v3.c > +++ b/xen/arch/arm/gic-v3.c > @@ -275,7 +275,7 @@ static void gicv3_enable_sre(void) > } >=20 > /* Wait for completion of a distributor/redistributor change */ > -static void gicv3_do_wait_for_rwp(void __iomem *base, uint32_t rwp_bit) > +int gicv3_do_wait_for_rwp(void __iomem *base, uint32_t rwp_bit) > { > uint32_t val; > bool timeout =3D false; > @@ -299,17 +299,22 @@ static void gicv3_do_wait_for_rwp(void __iomem *bas= e, uint32_t rwp_bit) > } while ( 1 ); >=20 > if ( timeout ) > + { > dprintk(XENLOG_ERR, "RWP timeout\n"); > + return -ETIMEDOUT; > + } > + > + return 0; > } >=20 > static void gicv3_dist_wait_for_rwp(void) > { > - gicv3_do_wait_for_rwp(GICD, GICD_CTLR_RWP); > + (void)gicv3_do_wait_for_rwp(GICD, GICD_CTLR_RWP); > } >=20 > static void gicv3_redist_wait_for_rwp(void) > { > - gicv3_do_wait_for_rwp(GICD_RDIST_BASE, GICR_CTLR_RWP); > + (void)gicv3_do_wait_for_rwp(GICD_RDIST_BASE, GICR_CTLR_RWP); > } >=20 > static void gicv3_wait_for_rwp(int irq) > @@ -863,7 +868,7 @@ static bool gicv3_enable_lpis(void) > return true; > } >=20 > -static int __init gicv3_populate_rdist(void) > +static int gicv3_populate_rdist(void) > { > int i; > uint32_t aff; > @@ -931,7 +936,7 @@ static int __init gicv3_populate_rdist(void) > gicv3_set_redist_address(rdist_addr, procnum); >=20 > ret =3D gicv3_lpi_init_rdist(ptr); > - if ( ret && ret !=3D -ENODEV ) > + if ( ret && ret !=3D -ENODEV && ret !=3D -EBUSY ) > { > printk("GICv3: CPU%d: Cannot initialize LPIs: %u\= n", > smp_processor_id(), ret); > diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gi= c.h > index 29bb9a89a4..68003ab116 100644 > --- a/xen/arch/arm/include/asm/gic.h > +++ b/xen/arch/arm/include/asm/gic.h > @@ -301,6 +301,10 @@ extern int gicv_setup(struct domain *d); > extern void gic_save_state(struct vcpu *v); > extern void gic_restore_state(struct vcpu *v); >=20 > +#ifdef CONFIG_GICV3 > +int gicv3_do_wait_for_rwp(void __iomem *base, uint32_t rwp_bit); > +#endif > + > #ifdef CONFIG_SYSTEM_SUSPEND > /* Suspend/resume */ > extern int gic_suspend(void); > --=20 > 2.43.0 >=20 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:36:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:36:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430917.1653323 (Exim 4.92) (envelope-from ) id 1x9P1L-0001P7-Vh; Wed, 23 Sep 2026 15:36:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430917.1653323; Wed, 23 Sep 2026 15:36:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P1L-0001Oy-SU; Wed, 23 Sep 2026 15:36:31 +0000 Received: by outflank-mailman (input) for mailman id 1430917; Wed, 23 Sep 2026 15:36:31 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P1K-0001Oq-L2 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:36:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9P1K-009bkY-1Y for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:36:30 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f1d7-bab6-0a2a0a5309dd-0a2a4504c198-32 for ; Wed, 23 Sep 2026 17:36:29 +0200 Received: from [52.101.66.50] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f1fc-b57f-0a2a45040019-346542320ead-3 for ; Wed, 23 Sep 2026 17:36:29 +0200 Received: from DU7P195CA0029.EURP195.PROD.OUTLOOK.COM (2603:10a6:10:54d::12) by DU0PR08MB7461.eurprd08.prod.outlook.com (2603:10a6:10:354::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.472.4; Wed, 23 Sep 2026 15:36:21 +0000 Received: from MAD0EPF000008AB.eurprd04.prod.outlook.com (2603:10a6:10:54d:cafe::a9) by DU7P195CA0029.outlook.office365.com (2603:10a6:10:54d::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.16 via Frontend Transport; Wed, 23 Sep 2026 15:36:20 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by MAD0EPF000008AB.mail.protection.outlook.com (10.167.241.183) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Wed, 23 Sep 2026 15:36:20 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DB4PR08MB8199.eurprd08.prod.outlook.com (2603:10a6:10:381::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.17; Wed, 23 Sep 2026 15:35:48 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 15:35:47 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=gJaVQoq1iE/YxRGDYLCcXPaKlsfFzgo1wpOnwueDzGDRFs20dMLw8q4JZOZ9wsrVF0e/pOFBuhwFHrVfMfuvYiKtM7DoZSM+mxHvs4Il/WaRr5P8sAWwgAcvtxVfRI/T6TFRQMYHJdUDuTlOAM99GAZEsBmC5eDB2ZG2+sPzEoHA7dKgvhBBS5yiTzcOKIM2LOI0OdhR0deOkmQhnEh3rkLt8/82cQiRxQuab7kWSDrHLfN7e77IMG0xL2FTfPruzvYMkxMTobJVuG21jspN12QlwGCQBsfd1i6U2OZL+yXBqGpmbpb3LjrTwcbeMXuHMcBCFa70OFuVI9iiYenP2w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HA6H5Lbqp1/jEz1rrSO74xcs2U73mWUnuGOQt/8Wfzo=; b=W+eEr/MgEuZKUIbZ7518il6wX8v9Xn3ISzDVIKuQF2d3yEQtxAWpWDFBnHwV2Q3N31WBHaQA06TBydiNW6/e9OtiG+Aw26ci6E5tAA3L5cBPTz5j3hda81vliIUTRYZGlbQUudJgekegvbeg03NvctwmIJorjJ+N1ge0zKKSooT5/WIkgW5K+gzOqhSou/3b9B9bH9NtamSAwVvGrj+NuCgRI/uYIt/s2ObRSEIBwMJ6IpPqpoiQyMdvZPHjAlIrQqKY8ICpmdyieuXOXFv5AzQB7vd4p+7z0P2qhGepWSPgw9K6HBwrtEquGXLXvCprWwfy+KfvR6v5dYSN1He5Zg== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=epam.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HA6H5Lbqp1/jEz1rrSO74xcs2U73mWUnuGOQt/8Wfzo=; b=bnnqv1E+chaJGw3cN6wXrPBKTOA48ODkOcUXxkp6nyvwK1wLSY+dus8tN8OOpWUw78ngrmeofGxlThqTqk9rwrTfhrPbf/Bnc8IHffXyyMJAr6c/4+hOxj/wgdlf0B6OnFz87VR9Q+5mOFMe4iqZb8/MVP4490zxpGrdKik6j5Y= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ob4F24hXvaesML8or7HBAsoZeyjgZFwE6NOxyWygRFJN/ywn200SFIfXRMIT8Nlnvtd7eVAdd/iWk5e/9zgweI9Bmr5TPVouRVLR7uXRyZrozKdjSY3LJb8R3uxvBs1JLmDERai7OJoFNvlwdg9srBQIshtf9Zro4vX3WSmY/VvLklvlhHz/6Me5HHQjHMo1Hh8ECQ9U4W7SIeE9m689r8z3xcv7P7QE8f0yRyVa7Pyfa18+d9b8cPmgrnp8jEa9l9FxdeAoKtjdI33uo9Mi8ITzNzF0j9oC93Mdxff4UPFY3YTaNmYFxvdd2kQ04NmjkkG7eLAqjjXudIC8rDBTUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HA6H5Lbqp1/jEz1rrSO74xcs2U73mWUnuGOQt/8Wfzo=; b=TGajbvVGh+/diEBZe+vVXVr/VzW7NNbu0TNohquzX+f3BLmbD50eCr6WQefwy+qV4DiPS7cH05+CP0iBVQ9oCirUEuP68uCoUAeotEkWqn5/ExlbjE5Gzs1UBDSnHDGlRSaK+sCREcmHGu/X3ZAPNh/xYSWT0l/ieGRH14/DzGcF66EjXwPRcgRUZhfIR855qoUgm00QjOJkYsRzfWArlbn1eMTqZD6wk2QXYc1nzzkQ7o8pT9gHr9p7igsvp+GdDUVybKu8N/w8YxLQkN1KbM3+MVD5NYZo/ys67eJu8mAwyrszjZKBF0hDYIe9pDuVxc5QdxPXv5CLAr0SrTbE3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HA6H5Lbqp1/jEz1rrSO74xcs2U73mWUnuGOQt/8Wfzo=; b=bnnqv1E+chaJGw3cN6wXrPBKTOA48ODkOcUXxkp6nyvwK1wLSY+dus8tN8OOpWUw78ngrmeofGxlThqTqk9rwrTfhrPbf/Bnc8IHffXyyMJAr6c/4+hOxj/wgdlf0B6OnFz87VR9Q+5mOFMe4iqZb8/MVP4490zxpGrdKik6j5Y= From: Bertrand Marquis To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Luca Fancellu Subject: Re: [PATCH v12 04/13] xen/arm: gic-v3: Implement GICv3 suspend/resume functions Thread-Topic: [PATCH v12 04/13] xen/arm: gic-v3: Implement GICv3 suspend/resume functions Thread-Index: AQHdNjDlfHyU+mM4Q02Y6q8l8URxnLbcdfqA Date: Wed, 23 Sep 2026 15:35:47 +0000 Message-ID: References: <1f311886ad3162f59749210c7dce26f9d089d010.1787838455.git.mykola_kvach@epam.com> In-Reply-To: <1f311886ad3162f59749210c7dce26f9d089d010.1787838455.git.mykola_kvach@epam.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DB4PR08MB8199:EE_|MAD0EPF000008AB:EE_|DU0PR08MB7461:EE_ X-MS-Office365-Filtering-Correlation-Id: 795d81b5-da79-4efc-ca97-08df19886a92 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|366016|376014|1800799024|38070700021|4143699003|56012099006|11063799006|5023799004|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info-Original: 71BqpSx8lw/shhRP/feg1dbEiCYO173ox7BmW680LwegfFE1/4qDS6+x82Un1ccfJ5DMiBZHlQZLFOwMBG4cNeGryFWQuqPKfL5vnggw/WUTYV/KczCnUSJKe2cKMvR588wzxQSuWFsOxqqb2N6U+pP/Jb7nrHsxwjtGPTPhiqX8znafzOWVz/65T27yS6qI/0elrwcuykH+85mzY5OhPBkoFgicUovshbaCUJCA1Pr5gtyA7HThF2DHfbgDRmOvkE/w4Ue/mjUvbrwG0Wu6TSg6AY8TZ34pYMFUx2CWLzrqjJUBuaCGV6cSJ8Q5MT2c9AThpMyTpsSkc2UkZRRtR+x9GZHF50o5RBO2KgILmuWkuKN1pcFYLwonKsrcnK18UR4FY1Wk9TO/kJsiNkrdF6A6SLe2UXVlcNjdY7lhk5U57tpV0P6nPNhkcuYhoIPP0AGdVedMXB4Bj1miHP9lriyeZsv8ib05bbf9gvJ5Opqe1ckM7GnS5/KgwEn1S2Rw+h+nZjH44KS28hL7aGh21orikSWplTpV5K8iRP6s3FyTmcA/7tMp8sS0okskiEHqaNL8Q7LNhF3e5j7pYe6mNzS6AYAiE9faSccTEKsJ080QXw90ebl/TIgdeRIAu0UzrJsJ1G8pjhvb7IHUBP+t8mEm+vx8yw2rFuOliFzpsPsW21rtOUTaKEGiGUi8iNnoXHb+u4fn+1tI4yUbY6m74HhjvHBDi6Wm+Z5Zf+WWxtg= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(1800799024)(38070700021)(4143699003)(56012099006)(11063799006)(5023799004)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <5A0C7CB6FEDD084181EC2D91B18A8A2A@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: hLNx7sBSNxTVjb+p9q1zzyMkSuH4Qu4uI2QECUGJmgBmW2/W32XFZIw2xMvP1cTbZv88LqeObkQyeaLK4YtAdiIB22s2Dt46CgLrZgIL3fKyaT9LwEzLDJ5N1mKNkNuyf6rHAplRJ546LGr2ThPaRXgmxx+TYBwNfNq0o6POL0fX3l1+ENS0zufE6gjDSbeh0m2x5fD29YRaJdPCZwHQiu0ElzzBQFgJRPt8Ip5G/iqDXJZdBSlVr9WRZHgw4XmE+V2/D4ntHJOwA3QI/S1exW/TRofUnX4dmsnCsjEbWTDFz6cX9mPkfcFrgClurxUYStHqpTYbztBTyv5B9o53ig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB8199 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: MAD0EPF000008AB.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 707f074d-5ed7-40fa-7fab-08df1988572e X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|14060799003|36860700016|1800799024|35042699022|376014|23010399003|10067099003|56012099006|6133799003|18002099003|22082099003|11063799006|5023799004|4143699003; X-Microsoft-Antispam-Message-Info: AqAwo1Nns62OSIHxQpbaYCOfz+eHiKTV/vVisDU2uN2U287LMoqMUWg9hcn+UxDSzFmk3Vv6PniQhYntrEhORnmghVn7tVPPwZGHGr6g6pwAL8EyOa47QMxFlZk6pcybmKWogLNhPVqFozvk/69mFPvbym44zgM864jnmiUqNGqvQwlnuCNWKIBFYxXzKlkQufvxDQK3yj2MY98BjegH2PA1d3JzNis18920j7J28pNnCSGswJ3oR8vPKS+nEyGwIclQIqr45VVHLc8vsXE4McSiAyH8T2D6+ps69FNhuimWOsNm5mNv88Ci6siX8xpLOcCs7JlvTY4xGcFQAzASGL+Z+qVNfWhpbqtW2JRClgC+tOdA0YVnaOviT1PxGjNfiojPdxf956LCNu81NMErumTANbjakkNou8jaEJ9cWPdD//3VUTw67WP3NpBEofXIOPVUfPThqL+K/e1FTOB7TytLHLqXUWhg1IKDz+o3XPcVj5MoymxocXnNjati7NBgceBj60SOXzretywHIky+LO9z7kuz0UQKhZoxjyG+ShzTwv4zjhKAzBAnVzK3GNKhJSb+OAGxJE1L7OuAfxS+c6jNHQX/YXx0CcSDTP8Inti2BqCDBGO75nTzhCblkkKvS1WGESVSyhNGu3cUhVgmexKlSfxeppKKlZnMwmlt+I/yMtXoEC1E1WgCqJWPG+AXdl9E2+DC190/tzWhGrVsHw== X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(14060799003)(36860700016)(1800799024)(35042699022)(376014)(23010399003)(10067099003)(56012099006)(6133799003)(18002099003)(22082099003)(11063799006)(5023799004)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: O7jVVsEcbn7QuMOAdRfhbUAuDKql6c5sLaaE4Fr2GMZwKaHCT8L2oic+sc5GqwLr7mDidV/f5NJtv0nVxWulRAL97f3sB69F1dKRE73aag1/tbflGPwMtiejONwbaGTGPGdozGo280Tb0jVkMXq5eD+uPJm34OyLtNbNXINvkFrYfpv6w9TeS6xnpQYbPGhHnI9Xh1KCpQe/X1IqFtKmCaygiiSYKblJxY3PlmAESHpMypiH/JksPhRAF63V5FmBC71hj82FXxKMn1YhAecoZv/wle3W0C7cHA8d9hMMglVLKBvrPvV8Pa91VsmCxAm9040vSYoHLblymYYbH8ach6fgd7hkZTXv0EI3PPWFaip/LQIPePGwgoyoDze6T6Yr7jGYsE9ksMGH7KfBABp+aBRtv5cP8cvA4R4X6XkSVQ2sT9oxXgumaWGcbDStNNZW X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 15:36:20.2299 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 795d81b5-da79-4efc-ca97-08df19886a92 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: MAD0EPF000008AB.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7461 X-purgate-ID: tlsNG-ebf023/1790177789-C34C3B50-F015FFF9/0/0 X-purgate-type: clean X-purgate-size: 23235 Hi Mykola, > On 27 Aug 2026, at 16:31, Mykola Kvach wrote: >=20 > System suspend may lead to a state where GIC would be powered down. > Therefore, Xen should save/restore the context of GIC on suspend/resume. >=20 > Note that the context consists of states of registers which are > controlled by the hypervisor. Other GIC registers which are accessible > by guests are saved/restored on context switch. >=20 > Before continuing suspend, also verify that the physical CPU interface > has no Group 1 active-priority state left. Use ICC_CTLR_EL1.PRIbits to > decide which ICC_AP1R_EL1 registers are implemented, so Xen does not > read an unimplemented AP1R register. >=20 > Signed-off-by: Mykola Kvach > Reviewed-by: Luca Fancellu > --- > Changes in V10: > - abort suspend when the physical Group 1 active-priority state is still > present, deriving accessible ICC_AP1R_EL1 registers from > ICC_CTLR_EL1.PRIbits; > - re-enable the redistributor before restoring CPU and virtual interface > state on the suspend abort path; > - panic if the redistributor cannot be re-enabled on the suspend abort pa= th; > - avoid saving/restoring reserved GICD_IPRIORITYR and GICD_IROUTER entrie= s > for a partially populated last SPI block; > - disable Distributor group forwarding while preserving affinity routing > state before restoring Distributor configuration; > - disable SPI/eSPI forwarding and wait for RWP before restoring > GICD_ICFGR.Int_config. >=20 > Changes in V9: > - fix the suspend-context comment typo and split dist_ctx declarations; > - restore ICC_IGRPEN1_EL1 on the suspend error path; > - re-initialize GICD_IGROUPRnE during resume; > - restore GICD_IROUTER only after re-enabling ARE_NS during resume. >=20 > Changes in V8: > - use right rdist base for prop/pend baser and ctrl >=20 > Changes in V7: > - restore LPI regs on resume > - add timeout during redist disabling > - squash with suspend/resume handling for GICv3 eSPI registers > - drop ITS guard paths so suspend/resume always runs; switch missing ctx > allocation to panic > - trim TODO comments; narrow redistributor storage to PPI icfgr > - keep distributor context allocation even without ITS; adjust resume > to use GENMASK(31, 0) for clearing enables > - drop storage of the SGI configuration register, as SGIs are always > edge-triggered > --- > xen/arch/arm/gic-v3-lpi.c | 3 + > xen/arch/arm/gic-v3.c | 458 ++++++++++++++++++++++- > xen/arch/arm/include/asm/arm64/sysregs.h | 5 + > xen/arch/arm/include/asm/gic_v3_defs.h | 3 + > 4 files changed, 466 insertions(+), 3 deletions(-) >=20 > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > index 847da26ff7..a63c8c4979 100644 > --- a/xen/arch/arm/gic-v3-lpi.c > +++ b/xen/arch/arm/gic-v3-lpi.c > @@ -467,6 +467,9 @@ static int cpu_callback(struct notifier_block *nfb, u= nsigned long action, > switch ( action ) > { > case CPU_UP_PREPARE: > + if ( system_state =3D=3D SYS_STATE_resume ) > + break; > + > rc =3D gicv3_lpi_allocate_pendtable(cpu); > if ( rc ) > printk(XENLOG_ERR "Unable to allocate the pendtable for CPU%l= u\n", > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > index b16888ad84..038bf41142 100644 > --- a/xen/arch/arm/gic-v3.c > +++ b/xen/arch/arm/gic-v3.c > @@ -1078,12 +1078,12 @@ out: > return res; > } >=20 > -static void gicv3_hyp_disable(void) > +static void gicv3_hyp_enable(bool enable) > { > register_t hcr; >=20 > hcr =3D READ_SYSREG(ICH_HCR_EL2); > - hcr &=3D ~GICH_HCR_EN; > + hcr =3D enable ? (hcr | GICH_HCR_EN) : (hcr & ~GICH_HCR_EN); > WRITE_SYSREG(hcr, ICH_HCR_EL2); > isb(); > } > @@ -1190,7 +1190,7 @@ static void gicv3_disable_interface(void) > spin_lock(&gicv3.lock); >=20 > gicv3_cpu_disable(); > - gicv3_hyp_disable(); > + gicv3_hyp_enable(false); >=20 > spin_unlock(&gicv3.lock); > } > @@ -1926,6 +1926,450 @@ static bool gic_dist_supports_lpis(void) > return (readl_relaxed(GICD + GICD_TYPER) & GICD_TYPE_LPIS); > } >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + > +/* This struct represents a block of 32 IRQs */ > +struct dist_irq_block { > + uint32_t icfgr[2]; > + uint32_t ipriorityr[8]; > + uint64_t irouter[32]; > + uint32_t isactiver; > + uint32_t isenabler; > +}; > + > +struct redist_ctx { > + uint32_t ctlr; > + uint32_t icfgr; /* only PPIs stored */ Can you capitalize first comment letter ? s/only/Only/ > + uint32_t igroupr; > + uint32_t ipriorityr[8]; > + uint32_t isactiver; > + uint32_t isenabler; > + > + uint64_t pendbase; > + uint64_t propbase; > +}; > + > +/* GICv3 registers to be saved/restored on system suspend/resume */ > +struct gicv3_ctx { > + struct dist_ctx { > + uint32_t ctlr; > + struct dist_irq_block *irqs; > + struct dist_irq_block *espi_irqs; > + } dist; > + > + /* have only one rdist structure for last running CPU during suspend= */ Same here s/have/Have/ > + struct redist_ctx rdist; > + > + struct cpu_ctx { > + uint32_t ctlr; > + uint32_t pmr; > + uint32_t bpr; > + uint32_t sre_el2; > + uint32_t grpen; > + } cpu; > +}; > + > +static struct gicv3_ctx gicv3_ctx; > + > +static void __init gicv3_alloc_context(void) > +{ > + uint32_t blocks =3D DIV_ROUND_UP(gicv3_info.nr_lines, 32); > + > + /* The spec allows for systems without any SPIs */ > + if ( blocks > 1 ) > + { > + gicv3_ctx.dist.irqs =3D xzalloc_array(struct dist_irq_block, blo= cks - 1); > + if ( !gicv3_ctx.dist.irqs ) > + panic("Failed to allocate memory for GICv3 suspend context\n= "); > + } > + > +#ifdef CONFIG_GICV3_ESPI > + if ( !gic_number_espis() ) > + return; > + > + blocks =3D gic_number_espis() / 32; > + gicv3_ctx.dist.espi_irqs =3D xzalloc_array(struct dist_irq_block, bl= ocks); > + if ( !gicv3_ctx.dist.espi_irqs ) > + panic("Failed to allocate memory for GICv3 eSPI suspend context\= n"); > +#endif > +} > + > +static int gicv3_disable_redist(void) > +{ > + void __iomem *waker =3D GICD_RDIST_BASE + GICR_WAKER; > + s_time_t deadline; > + > + /* > + * Avoid infinite loop if Non-secure does not have access to GICR_WA= KER. > + * See Arm IHI 0069H.b, 12.11.42 GICR_WAKER: > + * When GICD_CTLR.DS =3D=3D 0 and an access is Non-secure access= es to this > + * register are RAZ/WI. > + */ > + if ( !(readl_relaxed(GICD + GICD_CTLR) & GICD_CTLR_DS) ) > + return 0; > + > + deadline =3D NOW() + MILLISECS(1000); > + > + writel_relaxed(readl_relaxed(waker) | GICR_WAKER_ProcessorSleep, wak= er); > + while ( (readl_relaxed(waker) & GICR_WAKER_ChildrenAsleep) =3D=3D 0 = ) > + { > + if ( NOW() > deadline ) > + { > + printk("GICv3: Timeout waiting for redistributor to sleep\n"= ); > + return -ETIMEDOUT; > + } > + cpu_relax(); > + udelay(10); > + } > + > + return 0; > +} > + > +#define GET_SPI_REG_OFFSET(name, is_espi) \ > + ((is_espi) ? GICD_##name##nE : GICD_##name) > + > +static void gicv3_store_spi_irq_block(struct dist_irq_block *irqs, > + unsigned int i, unsigned int nr_ir= qs, > + bool is_espi) > +{ > + void __iomem *base; > + unsigned int irq, nr_priority_regs; > + > + ASSERT(nr_irqs && nr_irqs <=3D 32); > + nr_priority_regs =3D DIV_ROUND_UP(nr_irqs, 4); > + > + base =3D GICD + GET_SPI_REG_OFFSET(ICFGR, is_espi) + i * sizeof(irqs= ->icfgr); > + irqs->icfgr[0] =3D readl_relaxed(base); > + irqs->icfgr[1] =3D readl_relaxed(base + 4); > + > + base =3D GICD + GET_SPI_REG_OFFSET(IPRIORITYR, is_espi); > + base +=3D i * sizeof(irqs->ipriorityr); > + for ( irq =3D 0; irq < nr_priority_regs; irq++ ) > + irqs->ipriorityr[irq] =3D readl_relaxed(base + 4 * irq); > + > + base =3D GICD + GET_SPI_REG_OFFSET(IROUTER, is_espi); > + base +=3D i * sizeof(irqs->irouter); > + for ( irq =3D 0; irq < nr_irqs; irq++ ) > + irqs->irouter[irq] =3D readq_relaxed_non_atomic(base + 8 * irq); > + > + base =3D GICD + GET_SPI_REG_OFFSET(ISACTIVER, is_espi); > + base +=3D i * sizeof(irqs->isactiver); > + irqs->isactiver =3D readl_relaxed(base); > + > + base =3D GICD + GET_SPI_REG_OFFSET(ISENABLER, is_espi); > + base +=3D i * sizeof(irqs->isenabler); > + irqs->isenabler =3D readl_relaxed(base); > +} > + > +static void gicv3_restore_spi_irq_config(struct dist_irq_block *irqs, > + unsigned int i, unsigned int nr= _irqs, > + bool is_espi) > +{ > + void __iomem *base; > + unsigned int irq, nr_priority_regs; > + > + ASSERT(nr_irqs && nr_irqs <=3D 32); > + nr_priority_regs =3D DIV_ROUND_UP(nr_irqs, 4); > + > + base =3D GICD + GET_SPI_REG_OFFSET(ICFGR, is_espi) + i * sizeof(irqs= ->icfgr); > + writel_relaxed(irqs->icfgr[0], base); > + writel_relaxed(irqs->icfgr[1], base + 4); > + > + base =3D GICD + GET_SPI_REG_OFFSET(IPRIORITYR, is_espi); > + base +=3D i * sizeof(irqs->ipriorityr); > + for ( irq =3D 0; irq < nr_priority_regs; irq++ ) > + writel_relaxed(irqs->ipriorityr[irq], base + 4 * irq); > +} > + > +static void gicv3_restore_spi_irq_routing(struct dist_irq_block *irqs, > + unsigned int i, unsigned int n= r_irqs, > + bool is_espi) > +{ > + void __iomem *base; > + unsigned int irq; > + > + ASSERT(nr_irqs && nr_irqs <=3D 32); > + > + base =3D GICD + GET_SPI_REG_OFFSET(IROUTER, is_espi); > + base +=3D i * sizeof(irqs->irouter); > + for ( irq =3D 0; irq < nr_irqs; irq++ ) > + writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * irq); > +} > + > +static void gicv3_disable_spi_irq_block(unsigned int i, bool is_espi) > +{ > + void __iomem *base; > + > + base =3D GICD + GET_SPI_REG_OFFSET(ICENABLER, is_espi) + i * 4; > + writel_relaxed(GENMASK(31, 0), base); > +} > + > +static void gicv3_restore_spi_irq_state(struct dist_irq_block *irqs, > + unsigned int i, bool is_espi) > +{ > + void __iomem *base; > + > + base =3D GICD + GET_SPI_REG_OFFSET(ISENABLER, is_espi); > + base +=3D i * sizeof(irqs->isenabler); > + writel_relaxed(irqs->isenabler, base); > + > + base =3D GICD + GET_SPI_REG_OFFSET(ICACTIVER, is_espi) + i * 4; > + writel_relaxed(GENMASK(31, 0), base); > + > + base =3D GICD + GET_SPI_REG_OFFSET(ISACTIVER, is_espi); > + base +=3D i * sizeof(irqs->isactiver); > + writel_relaxed(irqs->isactiver, base); > +} > + > +static int gicv3_check_ap1r(unsigned int n, register_t apr) > +{ > + if ( !apr ) > + return 0; > + > + printk(XENLOG_ERR "GICv3: suspend aborted: ICC_AP1R%u_EL1=3D%#" > + PRIregister"\n", n, apr); > + > + return -EBUSY; > +} > + > +static int gicv3_check_active_priorities(register_t ctlr) > +{ > + unsigned int pribits =3D MASK_EXTR(ctlr, ICC_CTLR_EL1_PRIBITS_MASK) = + 1; > + int ret; > + > + /* > + * Xen enables physical Group 1 interrupts through ICC_IGRPEN1_EL1, > + * so only the physical Group 1 active-priority registers are releva= nt > + * here. Use ICC_CTLR_EL1.PRIbits for the physical CPU interface, no= t > + * ICH_VTR_EL2, which describes the virtual interface. ICC_AP1R1_EL1= is > + * only implemented with at least 6 physical priority bits, and > + * ICC_AP1R2_EL1/ICC_AP1R3_EL1 with at least 7. > + */ > + switch ( pribits ) > + { > + case 8: > + case 7: > + ret =3D gicv3_check_ap1r(3, READ_SYSREG(ICC_AP1R3_EL1)); > + if ( ret ) > + return ret; > + ret =3D gicv3_check_ap1r(2, READ_SYSREG(ICC_AP1R2_EL1)); > + if ( ret ) > + return ret; > + /* Fall through */ > + case 6: > + ret =3D gicv3_check_ap1r(1, READ_SYSREG(ICC_AP1R1_EL1)); > + if ( ret ) > + return ret; > + /* Fall through */ > + default: > + return gicv3_check_ap1r(0, READ_SYSREG(ICC_AP1R0_EL1)); > + } > +} > + > +static int gicv3_suspend(void) > +{ > + unsigned int i, nr_irqs; > + void __iomem *base; > + int ret; > + struct redist_ctx *rdist =3D &gicv3_ctx.rdist; > + > + /* Save GICC configuration */ > + gicv3_ctx.cpu.ctlr =3D READ_SYSREG(ICC_CTLR_EL1); > + gicv3_ctx.cpu.pmr =3D READ_SYSREG(ICC_PMR_EL1); > + gicv3_ctx.cpu.bpr =3D READ_SYSREG(ICC_BPR1_EL1); > + gicv3_ctx.cpu.sre_el2 =3D READ_SYSREG(ICC_SRE_EL2); > + gicv3_ctx.cpu.grpen =3D READ_SYSREG(ICC_IGRPEN1_EL1); > + > + gicv3_disable_interface(); > + > + ret =3D gicv3_check_active_priorities(gicv3_ctx.cpu.ctlr); > + if ( ret ) > + goto out_enable_iface; > + > + ret =3D gicv3_disable_redist(); > + if ( ret ) > + goto out_enable_iface; I am wondering about the timeout case here.=20 gicv3_disable_redist() has set ProcessorSleep to 1, but returns while ChildrenAsleep is still 0. This new error path then calls gicv3_enable_redist(), which clears ProcessorSleep.=20 Could that happen before ChildrenAsleep reaches 1?=20 The GIC specification says that transition is UNPREDICTABLE.=20 How should we handle the timeout? > + > + /* Save GICR configuration */ > + gicv3_redist_wait_for_rwp(); > + > + base =3D GICD_RDIST_BASE; > + > + rdist->ctlr =3D readl_relaxed(base + GICR_CTLR); > + > + rdist->propbase =3D readq_relaxed(base + GICR_PROPBASER); > + rdist->pendbase =3D readq_relaxed(base + GICR_PENDBASER); > + > + base =3D GICD_RDIST_SGI_BASE; > + > + /* Save priority on PPI and SGI interrupts */ > + for ( i =3D 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) > + rdist->ipriorityr[i] =3D readl_relaxed(base + GICR_IPRIORITYR0 += 4 * i); > + > + rdist->isactiver =3D readl_relaxed(base + GICR_ISACTIVER0); > + rdist->isenabler =3D readl_relaxed(base + GICR_ISENABLER0); > + rdist->igroupr =3D readl_relaxed(base + GICR_IGROUPR0); > + rdist->icfgr =3D readl_relaxed(base + GICR_ICFGR1); > + > + /* Save GICD configuration */ > + gicv3_dist_wait_for_rwp(); > + gicv3_ctx.dist.ctlr =3D readl_relaxed(GICD + GICD_CTLR); > + > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > + { > + nr_irqs =3D min(32U, gicv3_info.nr_lines - i * 32); > + gicv3_store_spi_irq_block(gicv3_ctx.dist.irqs + i - 1, i, nr_irq= s, > + false); > + } > + > +#ifdef CONFIG_GICV3_ESPI > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > + gicv3_store_spi_irq_block(gicv3_ctx.dist.espi_irqs + i, i, 32, t= rue); > +#endif > + > + return 0; > + > + out_enable_iface: > + if ( gicv3_enable_redist() ) > + panic("GICv3: Failed to re-enable redistributor after suspend ab= ort\n"); > + > + gicv3_hyp_enable(true); > + WRITE_SYSREG(gicv3_ctx.cpu.grpen, ICC_IGRPEN1_EL1); > + isb(); > + > + return ret; > +} > + > +static void gicv3_resume(void) > +{ > + int ret; > + unsigned int i, nr_irqs; > + uint32_t dist_ctlr; > + void __iomem *base; > + struct redist_ctx *rdist =3D &gicv3_ctx.rdist; > + > + dist_ctlr =3D gicv3_ctx.dist.ctlr & GICD_CTLR_ARE_NS; > + > + /* Disable group forwarding while preserving affinity routing state.= */ > + writel_relaxed(dist_ctlr, GICD + GICD_CTLR); > + gicv3_dist_wait_for_rwp(); > + > + /* > + * IHI0069H.b 12.9.9 says changing GICD_ICFGR.Int_config > + * while the interrupt is individually enabled is UNPREDICTABLE. > + * Disable SPIs first; 4.7.1 defines GICD_ICENABLER, n > 0, > + * as the per-SPI disable mechanism. > + */ > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > + gicv3_disable_spi_irq_block(i, false); > + > +#ifdef CONFIG_GICV3_ESPI > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > + gicv3_disable_spi_irq_block(i, true); > +#endif > + > + gicv3_dist_wait_for_rwp(); > + > + for ( i =3D NR_GIC_LOCAL_IRQS; i < gicv3_info.nr_lines; i +=3D 32 ) > + writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) * = 4); > + > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > + { > + nr_irqs =3D min(32U, gicv3_info.nr_lines - i * 32); > + gicv3_restore_spi_irq_config(gicv3_ctx.dist.irqs + i - 1, i, nr_= irqs, > + false); > + } > + > +#ifdef CONFIG_GICV3_ESPI > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > + { > + writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPRnE + i * 4); > + gicv3_restore_spi_irq_config(gicv3_ctx.dist.espi_irqs + i, i, 32= , > + true); > + } > +#endif > + > + if ( dist_ctlr ) > + { > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > + { > + nr_irqs =3D min(32U, gicv3_info.nr_lines - i * 32); > + gicv3_restore_spi_irq_routing(gicv3_ctx.dist.irqs + i - 1, i= , > + nr_irqs, false); > + } > + > +#ifdef CONFIG_GICV3_ESPI > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > + gicv3_restore_spi_irq_routing(gicv3_ctx.dist.espi_irqs + i, = i, > + 32, true); > +#endif > + } > + > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > + gicv3_restore_spi_irq_state(gicv3_ctx.dist.irqs + i - 1, i, fals= e); > + > +#ifdef CONFIG_GICV3_ESPI > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > + gicv3_restore_spi_irq_state(gicv3_ctx.dist.espi_irqs + i, i, tru= e); > +#endif > + > + writel_relaxed(gicv3_ctx.dist.ctlr, GICD + GICD_CTLR); > + gicv3_dist_wait_for_rwp(); > + > + ret =3D gicv3_lpi_init_rdist(GICD_RDIST_BASE); > + /* > + * If LPIs are already enabled, assume firmware or the still-powered > + * redistributor has valid PROPBASER/PENDBASER and skip reprogrammin= g. > + * Return -EBUSY so callers can ignore this case. > + */ > + if ( ret && ret !=3D -ENODEV && ret !=3D -EBUSY ) > + panic("GICv3: Failed to re-initialize LPIs during resume\n"); > + else if ( ret =3D=3D -EBUSY ) /* extra checks, just to be sure */ Comment first letter capitalize: s/extra/Extra/ Cheers Bertrand > + { > + base =3D GICD_RDIST_BASE; > + if ( readq_relaxed(base + GICR_PROPBASER) !=3D rdist->propbase |= | > + readq_relaxed(base + GICR_PENDBASER) !=3D rdist->pendbase ) > + panic("GICv3: LPIs already enabled with unexpected PROPBASER= /PENDBASER during resume\n"); > + } > + > + /* Restore GICR (Redistributor) configuration */ > + if ( gicv3_enable_redist() ) > + panic("GICv3: Failed to re-enable redistributor during resume\n"= ); > + > + base =3D GICD_RDIST_SGI_BASE; > + > + writel_relaxed(GENMASK(31, 0), base + GICR_ICENABLER0); > + gicv3_redist_wait_for_rwp(); > + > + for ( i =3D 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) > + writel_relaxed(rdist->ipriorityr[i], base + GICR_IPRIORITYR0 + i= * 4); > + > + writel_relaxed(rdist->isactiver, base + GICR_ISACTIVER0); > + writel_relaxed(rdist->igroupr, base + GICR_IGROUPR0); > + writel_relaxed(rdist->icfgr, base + GICR_ICFGR1); > + > + gicv3_redist_wait_for_rwp(); > + > + writel_relaxed(rdist->isenabler, base + GICR_ISENABLER0); > + writel_relaxed(rdist->ctlr, GICD_RDIST_BASE + GICR_CTLR); > + > + gicv3_redist_wait_for_rwp(); > + > + WRITE_SYSREG(gicv3_ctx.cpu.sre_el2, ICC_SRE_EL2); > + isb(); > + > + /* Restore CPU interface (System registers) */ > + WRITE_SYSREG(gicv3_ctx.cpu.pmr, ICC_PMR_EL1); > + WRITE_SYSREG(gicv3_ctx.cpu.bpr, ICC_BPR1_EL1); > + WRITE_SYSREG(gicv3_ctx.cpu.ctlr, ICC_CTLR_EL1); > + WRITE_SYSREG(gicv3_ctx.cpu.grpen, ICC_IGRPEN1_EL1); > + isb(); > + > + gicv3_hyp_init(); > +} > + > +#endif /* CONFIG_SYSTEM_SUSPEND */ > + > /* Set up the GIC */ > static int __init gicv3_init(void) > { > @@ -2011,6 +2455,10 @@ static int __init gicv3_init(void) >=20 > gicv3_hyp_init(); >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > + gicv3_alloc_context(); > +#endif > + > out: > spin_unlock(&gicv3.lock); >=20 > @@ -2050,6 +2498,10 @@ static const struct gic_hw_operations gicv3_ops = =3D { > #endif > .iomem_deny_access =3D gicv3_iomem_deny_access, > .do_LPI =3D gicv3_do_LPI, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend =3D gicv3_suspend, > + .resume =3D gicv3_resume, > +#endif > }; >=20 > static int __init gicv3_dt_preinit(struct dt_device_node *node, const voi= d *data) > diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/incl= ude/asm/arm64/sysregs.h > index f3c11d871e..2261620316 100644 > --- a/xen/arch/arm/include/asm/arm64/sysregs.h > +++ b/xen/arch/arm/include/asm/arm64/sysregs.h > @@ -16,6 +16,11 @@ > #define ICC_SRE_EL1 S3_0_C12_C12_5 > #define ICC_IGRPEN1_EL1 S3_0_C12_C12_7 >=20 > +#define ICC_AP1R0_EL1 S3_0_C12_C9_0 > +#define ICC_AP1R1_EL1 S3_0_C12_C9_1 > +#define ICC_AP1R2_EL1 S3_0_C12_C9_2 > +#define ICC_AP1R3_EL1 S3_0_C12_C9_3 > + > #define ICH_VSEIR_EL2 S3_4_C12_C9_4 > #define ICC_SRE_EL2 S3_4_C12_C9_5 > #define ICH_HCR_EL2 S3_4_C12_C11_0 > diff --git a/xen/arch/arm/include/asm/gic_v3_defs.h b/xen/arch/arm/includ= e/asm/gic_v3_defs.h > index 3714cfeb7d..f741587322 100644 > --- a/xen/arch/arm/include/asm/gic_v3_defs.h > +++ b/xen/arch/arm/include/asm/gic_v3_defs.h > @@ -94,12 +94,15 @@ > #define GICD_TYPE_LPIS (1U << 17) >=20 > #define GICD_CTLR_RWP (1UL << 31) > +#define GICD_CTLR_DS (1U << 6) > #define GICD_CTLR_ARE_NS (1U << 4) > #define GICD_CTLR_ENABLE_G1A (1U << 1) > #define GICD_CTLR_ENABLE_G1 (1U << 0) > #define GICD_IROUTER_SPI_MODE_ANY (1UL << 31) >=20 > #define GICC_CTLR_EL1_EOImode_drop (1U << 1) > +#define ICC_CTLR_EL1_PRIBITS_SHIFT 8 > +#define ICC_CTLR_EL1_PRIBITS_MASK (0x7U << ICC_CTLR_EL1_PRIBITS_SHIFT= ) >=20 > #define GICR_WAKER_ProcessorSleep (1U << 1) > #define GICR_WAKER_ChildrenAsleep (1U << 2) > --=20 > 2.43.0 >=20 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:37:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:37:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430922.1653332 (Exim 4.92) (envelope-from ) id 1x9P2H-00022c-Ad; Wed, 23 Sep 2026 15:37:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430922.1653332; Wed, 23 Sep 2026 15:37:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P2H-00022V-7J; Wed, 23 Sep 2026 15:37:29 +0000 Received: by outflank-mailman (input) for mailman id 1430922; Wed, 23 Sep 2026 15:37:27 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P2F-000228-Mf for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:37:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9P2F-00EF6n-3T for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:37:27 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f221-2eae-0a2a0a5409dd-0a2a450ca184-22 for ; Wed, 23 Sep 2026 17:37:26 +0200 Received: from [52.101.65.40] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f236-f479-0a2a450c0019-34654128caa2-3 for ; Wed, 23 Sep 2026 17:37:26 +0200 Received: from DU2P251CA0002.EURP251.PROD.OUTLOOK.COM (2603:10a6:10:230::11) by PAVPR08MB9306.eurprd08.prod.outlook.com (2603:10a6:102:305::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.13; Wed, 23 Sep 2026 15:37:20 +0000 Received: from DU2PEPF00028CFD.eurprd03.prod.outlook.com (2603:10a6:10:230:cafe::2e) by DU2P251CA0002.outlook.office365.com (2603:10a6:10:230::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.14 via Frontend Transport; Wed, 23 Sep 2026 15:37:20 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU2PEPF00028CFD.mail.protection.outlook.com (10.167.242.181) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Wed, 23 Sep 2026 15:37:19 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DB4PR08MB8199.eurprd08.prod.outlook.com (2603:10a6:10:381::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.17; Wed, 23 Sep 2026 15:36:46 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%5]) with mapi id 15.21.0451.014; Wed, 23 Sep 2026 15:36:46 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=m7nOU+Eajx/N613lFTuQsF9dqkGffbJX3xXsJL8TXnuOGFLfyszUGYupyB+yDYHgM0mCAe8V9Zl2YGu+226pa75yglWevEFVaYy1vANy+JtAPmaTB2dexditx+mzYzLBlxSCCVxrIMf+LUE6EVXOG7iXCIOXZeR2K2JNHyOpg7DNq+CTmyQmz4CRNcb4E2cHQZGiJJt9cppIWfFbR/btQd174toLS8j5wzan2Id/SHdqcG7tJn/ljxXU4VUP+oPT9cgtwL6zzf50+LFc4saCC/OAE7SNTkGcfAN9BFRNvTFBeuFzMyEWtiB2n2e66iPxezlnPNRiWREe9ZeB51NT6w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s3I8iLPNGam68QpKjw2EjiBqDypinDji47utgYayYxY=; b=TmrxEHuw7d8PjW/NSmwJd1zGdCXiWwh8/iR/vvWnUP1Aq2yt+ilK11ExZmMeWoT2IXkXRnK1uHoien2eNRvI6d5GwFwK1Cz9OIfXXZZQeASmjrGlLuZVrbbqcSqhcMXXskMn11VBKZVP4JYM1A9mjY8QYVZskBQwUOnllJacCMAqwIa5QnzJW1UeC7MwnA4MboSvNer32mxJmTfMo4xTxM96/D+pRexE2NkEAuZJL3PhbWo0JRVRg1tSruMR0NnhGG0F6jv5yrnwuC4Auj6cT7oRYm5vTMnpewYHL11yq7PI/lmpt7lqVFXnOD16BBYYnpyQiagS9B5XPY685yUoEQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=epam.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s3I8iLPNGam68QpKjw2EjiBqDypinDji47utgYayYxY=; b=jOBZXJCts/YpENhxutDDIEmu7xjf/WoJ9m7Ur4qp1gJTM1mo7vVOkD3jSMzsbYSgFEVWZHrvmsjgHwnH9E0n21jTdKxlBJ2Tf+Yjl5/sLrXSY39GeUjenVHejIWUbM4Di6+30g1id+Ij1S66MxPJMPvmOmbtiMIYO+EYTgx5yts= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cyZK83AmX5MIjjD9nany9ZR1jGSfirAubH8aVLKWOE/Z2f6lrLD/S7JCceZm2tcN2972QryziEePquq/jOrSk8XSv3fa2vUs27qDg1dQRNs62kIr+x/t6WGA1/4LdMdtMx09dZwipOqwicSDgIwoz2OU6TjJAdJt54t/wI78ZceGt89Z4ElJLXz3XP7dBhxPNjDhA0QSs8Bb2yEMCwWrD1xbr5ClbJFlLr6mKl2uP2ldzQoh6De0XZ4yxQX/XOHxXxqAqk2m2/4V9zj5BRGijlkXMKI11OZloG7Fs5DrgCDsj2kcvPQYncSpg7sdCnsgB/JkxYqVZ0Cdgcf+KSEn9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s3I8iLPNGam68QpKjw2EjiBqDypinDji47utgYayYxY=; b=YfIeVFTDlBshY3XZnusOrV6eTDdwRZBLxj+rrvO6O7dXfGHvw246+jG1NDgjHZoxdFYUyFJIRbAYJqEya5LY+Ps35HGVdDzadqWZU2Lmg1o1KxbBToMd46AvMNfwmLhFuBOKgPly5TpZJHDwztmZsLuP7/LNenfKqNjgn2vD+5JCMEmsBo58tG8vHWMGb/SCSuol4dXJDZ8F8n2U1q9gCBGSYHArM/uVkWv7q9VvHjQaFvKfPIZS1ZPmPtvl9TelIezWeVPaMK0a0mB+bcZGSyqqgcuVYe7RWCUCYrZ8ZaSR+Xuq0BGci05DRKyanwOYQujN7zbOTQBiKtT5HGscNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s3I8iLPNGam68QpKjw2EjiBqDypinDji47utgYayYxY=; b=jOBZXJCts/YpENhxutDDIEmu7xjf/WoJ9m7Ur4qp1gJTM1mo7vVOkD3jSMzsbYSgFEVWZHrvmsjgHwnH9E0n21jTdKxlBJ2Tf+Yjl5/sLrXSY39GeUjenVHejIWUbM4Di6+30g1id+Ij1S66MxPJMPvmOmbtiMIYO+EYTgx5yts= From: Bertrand Marquis To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Luca Fancellu Subject: Re: [PATCH v12 05/13] xen/arm: gic-v3: add ITS suspend/resume support Thread-Topic: [PATCH v12 05/13] xen/arm: gic-v3: add ITS suspend/resume support Thread-Index: AQHdNjDkDpJZkaz2I0GcmjAkqnRhTLbcdj+A Date: Wed, 23 Sep 2026 15:36:46 +0000 Message-ID: References: <1d14b9ad58e88f19450999a6c2ce476ed31531e3.1787838455.git.mykola_kvach@epam.com> In-Reply-To: <1d14b9ad58e88f19450999a6c2ce476ed31531e3.1787838455.git.mykola_kvach@epam.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.700.51.1.1) Authentication-Results-Original: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DB4PR08MB8199:EE_|DU2PEPF00028CFD:EE_|PAVPR08MB9306:EE_ X-MS-Office365-Filtering-Correlation-Id: 29b82958-c586-4317-c693-08df19888dfb x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|23010399003|366016|376014|7416014|1800799024|38070700021|4143699003|56012099006|11063799006|10067099003|22082099003|18002099003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info-Original: Giwn8wgCbRYDlAexaTdRutU9phsIFTa05ZBHMNSNGDoEffNBqvu/6UX0yUDSjd6fyulYehFMCqK7/DeYXX9JBOvCQw/smlITiQOCvLwrffJNRcsPqTTxlpPPeLEDoVqZZG+04vZQRYM3FJAdzs7RyPiPl7H20I+KzVoj1NQ4sUT5wrYeh6hAxZpbKPm0C81aignYzm0ocflY3YfUzUZ7+5sGuEsUg7VxPDdahLZ7cpx9Fsxl1yoSvMxKeopDo/OZAH3qY1a41h+4fAaWp8rWmW4wO/zTi35dYHofzu/cErWt9Ny6xQQAP9iYmA1zBTA4Fpb5o0r0JRpZ1c75X9F1BpuEjRLgYdlMRfqXREQsp3tY4sigbGnE+M/AitKazNkm4uGJhKT6SjiXohWscaNJJR4CS1HE17HBN3YdwbAi+qBiFq3PBMmcIf1o4t7uWSjST7FnKokqvZ3buQZ0IQUMbLkYsRn4eBwphjZloNG3gA2Rn2MXV30q4FAsZyAT7ThkznDPFeVvUIM6kIaASApnaBRI84J8c1HVgnVm1bMtOJr3OejQ8WfdOIvB6qV/u1AxYE3AXrDECNvypI89mRu9uYOPjI2j0zGkGCPF2ekj3URqL5kQyXiI0q9GNseRoamVLTkPY3n/pP2L5C2KwnFlckCfvBlrgRLQarUtNquFt6mQ049wqeVsAmR7oacRF3l4Y9nP3IPHWbsFpY750RM2vcY4nuLLjAo6Y7yaKB65RU4= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(7416014)(1800799024)(38070700021)(4143699003)(56012099006)(11063799006)(10067099003)(22082099003)(18002099003)(6133799003)(3023799007);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: YrJOZBxWYTlevD7kqIthSK7ceXNiC8ERRx3+rnjIrGn8yAkOnyxEzZIOw4DjXAr5fzAQtGsADCZLI96vs15GUlxKtBo81z7kLmnre6F+7BUEcM+D8zeaDmXGzBAoisUPYXAKbUjzWZdDKotL2/9iZRfj0yJHFyCHDtzFz9dNuPyJ/kkb5ud0L3p3UXzL/+ewD67DGqIUuGUKQbs+I41f+K+ggktyhq3/vMJJzKJgPRHQeFL6Evmgct91pBwBDBDunuUd+i2BD2XICWeI/nWSrLw+A2WmbnqLBhI2x//6uGAlZJgAc05HrWBaohdnA7MG5N7ef2ltL/t85HDnYxcpXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB8199 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF00028CFD.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: a289f469-42fc-46a5-1d30-08df198879e4 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|14060799003|82310400026|7416014|376014|1800799024|35042699022|36860700016|10067099003|56012099006|4143699003|6133799003|3023799007|18002099003|22082099003|11063799006; X-Microsoft-Antispam-Message-Info: 8xxzP/Xt8uz9QTdf0AILoGYUbHEJ9uyiEg/O/KO+Z3ARi94290qxLsxQoIX2XNM+MZyKxdkfs+AdlbogxVtx3NnMxrm0qJuQWb2kA//DAT01dMsR1e/zXebRoDMfOy2C0dWwWczZOIGLAsUYUaK+PH1gLkUktqHuY8BfRRds8YcEjD+us//XMOMXXLyXGy2ejhWlQA2+Zv25DCxXFHMXVl/8s8geG9nbbSnQ02PpjTaJCfrnQXWKAuIbmTAzwgUk3i+dFHDkL76s0U7WqfUmnnd9H/cZ38Jsix18mv6tiryTZkLpLgC8gQO8gB/7PFdgGkC4y8JxlwNsYHqZAwBGdKMBkIhLODpBKevFoRv3OYx7pL1NlQ6lexjnxlJkNDbNERVHw6y+m3KyaH0pN4dmVucjVqEYazog5gWBK8UjvOaU96wPPP9NZ/0a/0XI2QHiHV7WrXhyGCUPgYHHo+GoS4cu/cPLwWjzaPem3QYkZuwA4bGHPGYbM9tPZzIZrtdDFtRu7zZZhJQfJIRuc3xgndTTMpJnKm85oVVSkjlEiO+D05CFutXWR306c583lp+k5cGJpAd/LEXU2EMxH1nuyVqDLbzgPj0GRBUsE/4KnSPQFnWR64INwASS4v4loqO/u790n7BYhAwViMpcvb8FFkMMXEXDN/NH1qwGKItJLaeNhR8MnPRc7SUBb+m/GitedQHrWU0lUi8UtG6RN+63cA== X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(14060799003)(82310400026)(7416014)(376014)(1800799024)(35042699022)(36860700016)(10067099003)(56012099006)(4143699003)(6133799003)(3023799007)(18002099003)(22082099003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: v1S/Nk4CxUjVgm97aBQV3J6oEk8H+IFAbDpuyzTYQqjTGrElouI9SScB9ZD7Kdwl3vHrfEhMN2B1YVxT/h/+uk7BmLR+epkp3fKa7zebSmx1JtVE/TtNFHc/Vs4VzPP/cgnBAolFAN7xGBNo2m2uUMujMyfDSqqPf/WqcRzmgzYLs0dM4tupqfrW41KfAmSkcQ5CHpclgB5EHLshAtfa8MrqnhfnKUrbtq70kYYTL0kCX4Btrxg1uRcFZngNqGwzXUSL61yf/EuDj3o0Pt7PVzuBPUo1ej48MzoT7cpJ0lXickj7F3gpLpw93cF5p8/pSQQJHfk73JBBv36JRLjYoy4u5nrWRRc7EAQNYWhgtwB86jIPA/imbGJvkNdBV0+PfJi0LApyfKHXNUZIbLr2vnzbD/LkFfiVSpF8kzT70yq21XDxhrJK0+CkQMj+vlbf X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 15:37:19.7174 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 29b82958-c586-4317-c693-08df19888dfb X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF00028CFD.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9306 X-purgate-ID: tlsNG-d25034/1790177846-024DFA5B-3E77BB8C/0/0 X-purgate-type: clean X-purgate-size: 12191 Hi Mykola, > On 27 Aug 2026, at 16:31, Mykola Kvach wrote: >=20 > Handle system suspend/resume for GICv3 with an ITS present so LPIs keep > working after firmware powers the GIC down. >=20 > Save and restore the ITS CTLR, CBASER and BASER registers. On resume, > re-establish the collection mapping only when the collection is held in > the ITS itself. Memory-backed collections are restored through the > restored GITS_BASER tables and must not be remapped unconditionally. >=20 > Add list_for_each_entry_continue_reverse() in list.h for the ITS suspend > error path that needs to roll back partially saved state. >=20 > Based on Linux commit dba0bc7b76dc: > "irqchip/gic-v3-its: Add ability to save/restore ITS state". > Signed-off-by: Mykola Kvach > Reviewed-by: Luca Fancellu Reviewed-by: Bertrand Marquis # Arm code Changes to list.h will need a review from the Others group but they look good to me. Cheers Bertrand > --- > Changes in V10: > - Replay MAPC on resume only for collections held in the ITS itself, as > indicated by GITS_TYPER.HCC. Memory-backed collections are restored > through GITS_BASER and are no longer remapped unconditionally. > - Make the current Xen col_id =3D=3D cpu assumption explicit in the ITS > resume path. > - Use "unpredictable" instead of "undefined" in the CBASER/BASER restore > comment. >=20 > Changes in V9: > - fix the ITS suspend/resume coding-style nits; > - preserve the saved GITS_CTLR state while masking the read-only > QUIESCENT bit. >=20 > Changes in V8: > - Reword the CBASER/CWRITER comment to match Xen and drop the stale Linux > cmd_write reference. > - Clarify the list_for_each_entry_continue_reverse() comment. > - Factor out per-ITS helpers for collection setup and resume. > - Restore each ITS and re-establish its collection mapping in the same > loop, so a failed ITS resume is not followed by MAPC/SYNC on that > un-restored instance. > - panic in case when resume of an ITS failed > - cleanup baser cache during suspend > --- > xen/arch/arm/gic-v3-its.c | 146 ++++++++++++++++++++++++-- > xen/arch/arm/gic-v3.c | 11 +- > xen/arch/arm/include/asm/gic_v3_its.h | 28 +++++ > xen/include/xen/list.h | 14 +++ > 4 files changed, 189 insertions(+), 10 deletions(-) >=20 > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > index 7560d46c6d..dd53209865 100644 > --- a/xen/arch/arm/gic-v3-its.c > +++ b/xen/arch/arm/gic-v3-its.c > @@ -335,6 +335,22 @@ static int its_send_cmd_inv(struct host_its *its, > return its_send_command(its, cmd); > } >=20 > +static int gicv3_its_setup_collection_single(struct host_its *its, > + unsigned int cpu) > +{ > + int ret; > + > + ret =3D its_send_cmd_mapc(its, cpu, cpu); > + if ( ret ) > + return ret; > + > + ret =3D its_send_cmd_sync(its, cpu); > + if ( ret ) > + return ret; > + > + return gicv3_its_wait_commands(its); > +} > + > /* Set up the (1:1) collection mapping for the given host CPU. */ > int gicv3_its_setup_collection(unsigned int cpu) > { > @@ -343,15 +359,7 @@ int gicv3_its_setup_collection(unsigned int cpu) >=20 > list_for_each_entry(its, &host_its_list, entry) > { > - ret =3D its_send_cmd_mapc(its, cpu, cpu); > - if ( ret ) > - return ret; > - > - ret =3D its_send_cmd_sync(its, cpu); > - if ( ret ) > - return ret; > - > - ret =3D gicv3_its_wait_commands(its); > + ret =3D gicv3_its_setup_collection_single(its, cpu); > if ( ret ) > return ret; > } > @@ -1211,6 +1219,126 @@ int gicv3_its_init(void) > return 0; > } >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > +int gicv3_its_suspend(void) > +{ > + struct host_its *its; > + int ret; > + > + list_for_each_entry( its, &host_its_list, entry ) > + { > + unsigned int i; > + void __iomem *base =3D its->its_base; > + > + /* > + * By the time Xen reaches gic_suspend(), every domain is alread= y in > + * SHUTDOWN_suspend, so ITS-targeting interrupt sources are expe= cted > + * to have been quiesced by the owning OS before SYSTEM_SUSPEND. > + */ > + /* Preserve saved GITS_CTLR state, excluding read-only QUIESCENT= . */ > + its->suspend_ctx.ctlr =3D readl_relaxed(base + GITS_CTLR) & > + ~GITS_CTLR_QUIESCENT; > + ret =3D gicv3_disable_its(its); > + if ( ret ) > + { > + writel_relaxed(its->suspend_ctx.ctlr, base + GITS_CTLR); > + goto err; > + } > + > + its->suspend_ctx.cbaser =3D readq_relaxed(base + GITS_CBASER); > + > + for ( i =3D 0; i < GITS_BASER_NR_REGS; i++ ) > + { > + uint64_t baser =3D readq_relaxed(base + GITS_BASER0 + i * 8)= ; > + > + its->suspend_ctx.baser[i] =3D 0; > + > + if ( !(baser & GITS_VALID_BIT) ) > + continue; > + > + its->suspend_ctx.baser[i] =3D baser; > + } > + } > + > + return 0; > + > + err: > + list_for_each_entry_continue_reverse( its, &host_its_list, entry ) > + writel_relaxed(its->suspend_ctx.ctlr, its->its_base + GITS_CTLR)= ; > + > + return ret; > +} > + > +static int gicv3_its_resume_single(struct host_its *its, unsigned int cp= u) > +{ > + void __iomem *base =3D its->its_base; > + unsigned int i; > + int ret; > + uint64_t typer; > + unsigned int col_id =3D cpu; /* Xen currently uses col_id =3D=3D cpu= . */ > + > + /* > + * Make sure that the ITS is disabled. If it fails to quiesce, > + * don't restore it since writing to CBASER or BASER > + * registers is unpredictable according to the GIC v3 ITS > + * Specification. > + */ > + WARN_ON(readl_relaxed(base + GITS_CTLR) & GITS_CTLR_ENABLE); > + ret =3D gicv3_disable_its(its); > + if ( ret ) > + return ret; > + > + writeq_relaxed(its->suspend_ctx.cbaser, base + GITS_CBASER); > + > + /* > + * Writing CBASER resets CREADR to 0, so reset CWRITER to > + * keep the command queue pointers aligned. > + */ > + writeq_relaxed(0, base + GITS_CWRITER); > + > + /* Restore GITS_BASER from the value cache. */ > + for ( i =3D 0; i < GITS_BASER_NR_REGS; i++ ) > + { > + uint64_t baser =3D its->suspend_ctx.baser[i]; > + > + if ( !(baser & GITS_VALID_BIT) ) > + continue; > + > + writeq_relaxed(baser, base + GITS_BASER0 + i * 8); > + } > + > + writel_relaxed(its->suspend_ctx.ctlr, base + GITS_CTLR); > + > + typer =3D readq_relaxed(base + GITS_TYPER); > + > + /* > + * Only collections with IDs below HCC are held in the ITS itself > + * and lose their state across an ITS reset/power loss. Memory-backe= d > + * collections are restored by restoring GITS_BASER and must not be > + * remapped here. > + */ > + if ( col_id < GITS_TYPER_HCC(typer) ) > + return gicv3_its_setup_collection_single(its, cpu); > + > + return 0; > +} > + > +void gicv3_its_resume(void) > +{ > + struct host_its *its; > + unsigned int cpu =3D smp_processor_id(); > + int ret; > + > + list_for_each_entry( its, &host_its_list, entry ) > + { > + ret =3D gicv3_its_resume_single(its, cpu); > + if ( ret ) > + panic("GICv3: ITS@%"PRIpaddr": failed to restore during resu= me: %d\n", > + its->addr, ret); > + } > +} > + > +#endif /* CONFIG_SYSTEM_SUSPEND */ >=20 > /* > * Local variables: > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > index 038bf41142..6b025c023d 100644 > --- a/xen/arch/arm/gic-v3.c > +++ b/xen/arch/arm/gic-v3.c > @@ -2186,10 +2186,14 @@ static int gicv3_suspend(void) > if ( ret ) > goto out_enable_iface; >=20 > - ret =3D gicv3_disable_redist(); > + ret =3D gicv3_its_suspend(); > if ( ret ) > goto out_enable_iface; >=20 > + ret =3D gicv3_disable_redist(); > + if ( ret ) > + goto out_its_resume; > + > /* Save GICR configuration */ > gicv3_redist_wait_for_rwp(); >=20 > @@ -2229,6 +2233,9 @@ static int gicv3_suspend(void) >=20 > return 0; >=20 > + out_its_resume: > + gicv3_its_resume(); > + > out_enable_iface: > if ( gicv3_enable_redist() ) > panic("GICv3: Failed to re-enable redistributor after suspend abo= rt\n"); > @@ -2355,6 +2362,8 @@ static void gicv3_resume(void) >=20 > gicv3_redist_wait_for_rwp(); >=20 > + gicv3_its_resume(); > + > WRITE_SYSREG(gicv3_ctx.cpu.sre_el2, ICC_SRE_EL2); > isb(); >=20 > diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include= /asm/gic_v3_its.h > index fc5a84892c..0f8cb16e41 100644 > --- a/xen/arch/arm/include/asm/gic_v3_its.h > +++ b/xen/arch/arm/include/asm/gic_v3_its.h > @@ -43,6 +43,11 @@ > #define GITS_CTLR_QUIESCENT BIT(31, UL) > #define GITS_CTLR_ENABLE BIT(0, UL) >=20 > +#define GITS_TYPER_HCC_SHIFT 24 > +#define GITS_TYPER_HCC_MASK 0xffUL > +#define GITS_TYPER_HCC(r) (((r) >> GITS_TYPER_HCC_SHIFT) &= \ > + GITS_TYPER_HCC_MASK) > + > #define GITS_TYPER_PTA BIT(19, UL) > #define GITS_TYPER_DEVIDS_SHIFT 13 > #define GITS_TYPER_DEVIDS_MASK (0x1fUL << GITS_TYPER_DEVIDS_SHIF= T) > @@ -129,6 +134,13 @@ struct host_its { > spinlock_t cmd_lock; > void *cmd_buf; > unsigned int flags; > +#ifdef CONFIG_SYSTEM_SUSPEND > + struct suspend_ctx { > + uint32_t ctlr; > + uint64_t cbaser; > + uint64_t baser[GITS_BASER_NR_REGS]; > + } suspend_ctx; > +#endif > }; >=20 > /* Map a collection for this host CPU to each host ITS. */ > @@ -204,6 +216,11 @@ uint64_t gicv3_its_get_cacheability(void); > uint64_t gicv3_its_get_shareability(void); > unsigned int gicv3_its_get_memflags(void); >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > +int gicv3_its_suspend(void); > +void gicv3_its_resume(void); > +#endif > + > #else >=20 > #ifdef CONFIG_ACPI > @@ -271,6 +288,17 @@ static inline int gicv3_its_make_hwdom_dt_nodes(cons= t struct domain *d, > return 0; > } >=20 > +#ifdef CONFIG_SYSTEM_SUSPEND > +static inline int gicv3_its_suspend(void) > +{ > + return 0; > +} > + > +static inline void gicv3_its_resume(void) > +{ > +} > +#endif > + > #endif /* CONFIG_HAS_ITS */ >=20 > #endif > diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h > index 98d8482dab..2aab274157 100644 > --- a/xen/include/xen/list.h > +++ b/xen/include/xen/list.h > @@ -535,6 +535,20 @@ static inline void list_splice_init(struct list_head= *list, > &(pos)->member !=3D (head); = \ > (pos) =3D list_entry((pos)->member.next, typeof(*(pos)), member)= ) >=20 > +/** > + * list_for_each_entry_continue_reverse - iterate backwards from the giv= en point > + * @pos: the type * to use as a loop cursor. > + * @head: the head for your list. > + * @member: the name of the list_head within the struct. > + * > + * Iterate over list of given type backwards, starting from the element = previous > + * to the current one in list order. > + */ > +#define list_for_each_entry_continue_reverse(pos, head, member) = \ > + for ((pos) =3D list_entry((pos)->member.prev, typeof(*(pos)), member= ); \ > + &(pos)->member !=3D (head); = \ > + (pos) =3D list_entry((pos)->member.prev, typeof(*(pos)), member= )) > + > /** > * list_for_each_entry_from - iterate over list of given type from the > * current point > --=20 > 2.43.0 >=20 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:39:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:39:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430930.1653341 (Exim 4.92) (envelope-from ) id 1x9P3l-0002xR-KH; Wed, 23 Sep 2026 15:39:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430930.1653341; Wed, 23 Sep 2026 15:39:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P3l-0002xK-HX; Wed, 23 Sep 2026 15:39:01 +0000 Received: by outflank-mailman (input) for mailman id 1430930; Wed, 23 Sep 2026 15:39:00 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P3k-0002xE-23 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:39:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9P3i-002Jys-K5 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:38:58 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f28d-bab6-0a2a0a5309dd-0a2a450add32-14 for ; Wed, 23 Sep 2026 17:38:58 +0200 Received: from [74.125.224.141] (helo=mail-yx2-f13.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f291-f2d2-0a2a450a0019-4a7de08d93b9-3 for ; Wed, 23 Sep 2026 17:38:58 +0200 Received: by mail-yx2-f13.google.com with SMTP id 00721157ae682-85d45ae011cso15005597b3.2 for ; Wed, 23 Sep 2026 08:38:57 -0700 (PDT) Received: from StolidWingnut ([174.80.170.224]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8a4658c6fb5sm11286887b3.9.2026.09.23.08.38.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 08:38:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=edera.io header.i="@edera.io" header.h="Content-Transfer-Encoding:Content-Disposition:Content-Type:MIME-Version:Message-ID:Date:User-Agent:References:In-Reply-To:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=edera.io; s=google; t=1790177936; x=1790782736; darn=lists.xenproject.org; h=content-transfer-encoding:content-disposition:content-type :mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ZOLyK+qFZl9rWYm51bMfdAhWNgi1+EugiYkehWERzhU=; b=Vx5ZGzJui80+XzcKVWgl89mH6Th6Dw69LxrlKA507nzi/d23MhsDsWNCTULwqv0cBG 9OlIhNRDc/idauPAITuIMmeMgY9bDdkiwUc64JcXWU1AYW8toIk3gaVuxZLwOs7LEc7d XJFNxMLLZAd9Rk9tB5Ov/3g2wsarRrjAYUMkAzL5K8mih2kunrmmVL7QYicgEdhO0HLh jyoW3XYc/tSe/gAg2aZVCOYyB5zOmJJLZb/VzxoyH31s6iT/qloMtlTfoLd+XbXJv4ZA /vkQBKEIKDSbs/0h24IBWHe2gAy0yevbjx4DooQqlWAlZZAT54MntVni9FnI3yEfxH6i N67w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790177936; x=1790782736; h=content-transfer-encoding:content-disposition:content-type :mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=ZOLyK+qFZl9rWYm51bMfdAhWNgi1+EugiYkehWERzhU=; b=Fv/38WhmQjywDvHgXvty2FVLUc4OaLy3P6hhifbZgrEzLH2Nvj1ZW+1ZjpzEZIFl5X uCFHOzy8RfH+GFFFCO9BQA7yCKUpYUWJpyas60ZGTs/uh2smWvn0wrWpOXD5DQ9lfP06 lUSEQGfkd+i/mHuz3HRQyWwWz9kdEw6wMgcShdIaotwRk3DgrFJb4rhBSceB+sLadbbz INvl2rT9Xj/njnNZAyRQAEANpsuP7hPXe4p6OiTywnymk5+D9JsXMwsJq/LZn0MQ3TYE PSE8eDuQubgoIto7TMjruWZwb6v71dTwQ5YOQ6OQ0WaOPidUBuvSxMuKB789S3HZS0UH 2JAw== X-Forwarded-Encrypted: i=1; AKwUvBzaTiLHm0V/UIGZqPtFWgAFHw3iDGzlkIDPaTEQZ2/+uDWsWgHdu0A3b0K6kwtVSkyoGAihEO8a+oo=@lists.xenproject.org X-Gm-Message-State: AFuF++nMkaYyJvxABo1xFtbLAD6qwI3ZziFt8WPV3zxOYG8uD4j0XBBy akOHQCV8sdypL1brwG2GXvZrocKPXA8fAH1uEXW1ojbrso4evNs+/2mJavnQ9boH+8K0ROsCs4/ aa54Hg0c= X-Gm-Gg: AYBFou0UQw4SMxazxyDePN7vK7E1xhMBtX8+LiqQaujPpxuloN9WMuEHk1oy90jPrfu TxbYHg5zslyjS+G7lXOzzQnwD0pKnpbCktraycbssFIgXJe2rOvVINxI6mLI/tgZ61OqtDmqMsN UdxTqpmVsTswaDNIlaTEW4LnroRJ/Hn/UlE8uWOqfMPkQgiGb4R1Zf6pq8BnFLuUrAfz/a/rv1l idcApB+UxZO6MdS5+/dTOb71+1lHswronIFTIyxb43YBMg731fkBkXcFimz2sMpVmW1NGBGoKgy FPuH+uDZE/drQuRucsWc3k9AyCOyUyf9cZNMFLWDkVA+ujIVklI/RsGjxEaSI9aaVxNb1fc5CFH wyH36FObXXYMivBpm579Pib9klfIGFCgwJqiPW88lvnEeZhRxt4h9LH9RtACIGdKEUEi7HeWJbJ 2LtzuJ6lA/5I/huXPr8uEKoArsmbihH4Ii71cpuQJDTrMziH4ElFHjMqDJLsBv3Po4uD5TbWRhD d5gvryFC1w5HppoCtoahc8DMwYswG1npQcxtSkn+ZG1rns+CCOO2xc= X-Received: by 2002:a05:690c:e205:10b0:873:3f2:c16d with SMTP id 00721157ae682-8a458c26438mr11471797b3.21.1790177936474; Wed, 23 Sep 2026 08:38:56 -0700 (PDT) From: Benjamin Leggett To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau =?utf-8?Q?Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH] ns16550: find the console UART on PCI when there is no legacy one In-Reply-To: <1f2eb0d2-5208-40e4-bcd1-55df6ebfc2e3@suse.com> References: <20260922184316.324817-1-benjamin@edera.io> <1f2eb0d2-5208-40e4-bcd1-55df6ebfc2e3@suse.com> User-Agent: mu4e 1.12.12; emacs 32.0.50 Date: Wed, 23 Sep 2026 11:38:54 -0400 Message-ID: <87zex8j7u9.fsf@edera.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1790177938-512C8CFC-D6C95F3D/0/0 X-purgate-type: clean X-purgate-size: 1144 Jan Beulich writes: > Is there a spec that you could point to here? Unfortunately not really, just an upstream Linux commit from 2017 ( ), and the fact that I=E2=80=99ve tested it on EC2 bare metal boxes. The ba= re metal boxes are being phased out, but people still use them. > This needs to be split to a separate patch, and not only because right > now you=E2=80=99re doing two entirely unrelated things in a single change= . The > addition of the Amazon device is likely uncontroversial, so presumably > can go in quickly. Yes, agreed. I will split and separately submit them. > Doing a scan when none was asked for, otoh, is > potentially problematic: What if there=E2=80=99s an issue during scanning= ? With > not having any output set up yet, we couldn=E2=80=99t even indicate the p= roblem, > and a possible crash would also go entirely silently. Yep, thanks. I will see if I can address these with a different version of the autoscan patch as a followup. From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:40:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:40:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430938.1653349 (Exim 4.92) (envelope-from ) id 1x9P57-0004tI-2d; Wed, 23 Sep 2026 15:40:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430938.1653349; Wed, 23 Sep 2026 15:40:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P56-0004tB-Vr; Wed, 23 Sep 2026 15:40:24 +0000 Received: by outflank-mailman (input) for mailman id 1430938; Wed, 23 Sep 2026 15:40:23 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P55-0004t1-Qp for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:40:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9P55-006pms-4I for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:40:23 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f2e2-8faa-0a2a0a5109dd-0a2a450ced3e-14 for ; Wed, 23 Sep 2026 17:40:23 +0200 Received: from [74.125.224.140] (helo=mail-yx2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f2e5-f479-0a2a450c0019-4a7de08ccb6f-3 for ; Wed, 23 Sep 2026 17:40:22 +0200 Received: by mail-yx2-f12.google.com with SMTP id 00721157ae682-85d440939f0so12350497b3.2 for ; Wed, 23 Sep 2026 08:40:22 -0700 (PDT) Received: from StolidWingnut.axolotl-tone.ts.net ([174.80.170.224]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8a465ec41acsm11211697b3.26.2026.09.23.08.40.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 08:40:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=edera.io header.i="@edera.io" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=edera.io; s=google; t=1790178021; x=1790782821; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=zRSBigR+fNtVFjx5bu3waR1j8HxydhkAAJV7I+0HM74=; b=ryozL9GSP7GQnj9DSEnHbw5lP8HgUd3bayjhyrtRp1VTvREKe4Q/ko/i0QkcU7jYkb 31pJ7eSFNCMrEuEqqqDr3CdhHsIFO6o0bLIgvW2C7fWhnBk6LVtvCEzMtQUF71vEI81l CajmXv+WdeC6JmCAIhb5N3M7Hu6yoJiNdqF26coeVR86+VMXK3EsnlNnmABxc1/JkpAh a13ye66ckGi4tBjdMekQ2jMiQ+rMm4FKBCbxALMi+/8nDDG7inL+Ueo0ubEpuftnuLth 9ecdtxx/54lcv96uR6PzPlsNWFyKtQGlH6TAxrm3LILuwWRGE3BTphbNHFttXOsgcQQr Jx9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790178021; x=1790782821; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=zRSBigR+fNtVFjx5bu3waR1j8HxydhkAAJV7I+0HM74=; b=iT5EejCvIGF0TT3keMnV3eqRtY0UVUoux8/4V8glQrgHZVN9xo782oeDUdJgWJXrsR WPkVIMMC+l3ieLnXl4Xi0bQ8AckLbQxnZmjYta6wP7G6Vv5nmupJCJdfEfx+103+qZJC Vvr/ya6aX+aZ3tUNT4c91M0DvVwlfsOmznv0zijg981/Ta/nfsdYSdId0fMFwURzWnMn NxavEqV44ELEbE/owbxrNM8zS/uuGb4Qi3VIX45Xg5cBY4tbflp5APXwHoLcOI63jMYM CDIgxLPsgkYtSDttsJbXv0iuqT9g6zkrdZKVPsayHNaeW3q68XE34hk3Hj5S/zCSYNGf Ys0w== X-Gm-Message-State: AFuF++mrEVzE5ZczdRSsz5Ggt/zxyhNU48kvCHS3BQOtCTUGDLBtcV+t CpWMUoVc5pCexDJkeSQnEvy7SI36paSoncmRu/W88/LGGq/34XvX/rJqqTscr7HLpQ8tYI2YBF6 Po9uFDzg= X-Gm-Gg: AYBFou0NsJo8qPFSVoIY1F0d5PhlsSHYr0J0jjSIPKhWpo/bt6phkWOADxggTzctWnl uyQ05Lg/aL28IXqYI7JSzrE8RdwG57U2PAXvBl3otVJNWBwWD9CsaPizHNI2Yr/fQgqRxkLBtkO 72yG3Kxzy7R87ZFJd+o91SZdCnxBrJbVs7PpEieyAQAuUFf2QmbA+CulzHjTKbFn5FS4vttIQrS JR1hyZqr6+BVza8lGj+R7hY6ffMmtxhQdsOk7iYkVBAoiAbeR+kFsaxBsp6FDjBVEtpGIdv7zdf qGChtgO0DXYUoe65fZ0Sql9iaWXbthO1WkMDmQXmchmJ7HqBdscmgCN9UXWvIHFB8wziubP6k6b yweiNHNj8jMbvRDhG7GRX0glKeQgg+r6dbH2WYdu3YuGU1lsx0RvY6JhS1DjjBUE84A46NBwck9 cUagoW/7zy6/7A01q4yAn06YKZafk5XjfhyE9Xb7ry4fY597itYSH0KT4cyYHga8/9C1/ftM875 Dq9fHFJl86PdFnReQm44NpLhiGFZuFZGiYuh++DGdlR/xqu6FXqTWMwom1vzEV8IdGvKll0z963 Ve479WemF4RCvcrXKg== X-Received: by 2002:a05:690c:c59c:b0:873:5bb2:6bff with SMTP id 00721157ae682-8a45b09e620mr17371697b3.41.1790178021171; Wed, 23 Sep 2026 08:40:21 -0700 (PDT) From: Benjamin Leggett To: xen-devel@lists.xenproject.org Cc: Benjamin Leggett , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] ns16550: add the Amazon EC2 PCI serial device Date: Wed, 23 Sep 2026 11:39:33 -0400 Message-ID: <20260923153933.2024896-1-benjamin@edera.io> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260922184316.324817-1-benjamin@edera.io> References: <20260922184316.324817-1-benjamin@edera.io> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1790178023-022C0A5B-E2C9AA9A/0/0 X-purgate-type: clean X-purgate-size: 2288 Amazon EC2 bare metal instances have no UART at the legacy I/O port 0x3f8. Their only serial port is a 16550-compatible PCI device (vendor 0x1d0f, device 0x8250) with its registers in the MMIO space of BAR 0. pci_uart_config() uses the default parameters for a device that is not in uart_config[], and those only accept an I/O BAR, so "com1=...,pci" cannot find this device. Add it, with the same layout that Linux uses (commit 3bfd1300abfe ("serial: 8250_pci: Add Amazon PCI serial device ID")): one port at the start of BAR 0, 1-byte registers, and the default 1.8432MHz clock. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Benjamin Leggett --- xen/drivers/char/ns16550.c | 14 ++++++++++++++ xen/include/xen/pci_ids.h | 2 ++ 2 files changed, 16 insertions(+) diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 120ac09d23..593d208483 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -98,6 +98,7 @@ struct ns16550_config { param_intel_lpss, param_wch_ch382, param_asix, + param_amazon, } param; }; @@ -909,6 +910,13 @@ static const struct ns16550_config_param __initconst uart_param[] = { .bar0 = true, .max_ports = 1, }, + [param_amazon] = { + .reg_width = 1, + .lsr_mask = UART_LSR_THRE, + .bar0 = true, + .mmio = true, + .max_ports = 1, + }, }; static const struct ns16550_config __initconst uart_config[] = @@ -1255,6 +1263,12 @@ static const struct ns16550_config __initconst uart_config[] = .dev_id = 0x9910, .param = param_asix }, + /* Amazon EC2 bare metal UART */ + { + .vendor_id = PCI_VENDOR_ID_AMAZON, + .dev_id = 0x8250, + .param = param_amazon + }, }; static int __init diff --git a/xen/include/xen/pci_ids.h b/xen/include/xen/pci_ids.h index fd424ef55d..a17c88dcf7 100644 --- a/xen/include/xen/pci_ids.h +++ b/xen/include/xen/pci_ids.h @@ -17,6 +17,8 @@ #define PCI_VENDOR_ID_WCHIC 0x1c00 +#define PCI_VENDOR_ID_AMAZON 0x1d0f + #define PCI_VENDOR_ID_INTEL 0x8086 #endif /* XEN_PCI_IDS_H */ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:43:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:43:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430947.1653360 (Exim 4.92) (envelope-from ) id 1x9P7n-0005PZ-Gk; Wed, 23 Sep 2026 15:43:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430947.1653360; Wed, 23 Sep 2026 15:43:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9P7n-0005PS-D3; Wed, 23 Sep 2026 15:43:11 +0000 Received: by outflank-mailman (input) for mailman id 1430947; Wed, 23 Sep 2026 15:43:10 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9P7m-0005PM-Cs for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:43:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9P7l-002KbI-Px for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:43:09 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f38a-bab6-0a2a0a5309dd-0a2a4503ac02-16 for ; Wed, 23 Sep 2026 17:43:09 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f38d-fae8-0a2a45030019-b9ff1c23b3c3-3 for ; Wed, 23 Sep 2026 17:43:09 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0ceef50f800072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 15:43:05 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 96D3F80B5E; Wed, 23 Sep 2026 17:43:04 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=NJ1Ayj43GSeaYDEZryv5OI9GcmzJI4BFh1MJ+3u6/tI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=nkvXLNnQ9JhKQYNKecS48hb/Y7egWLGE1l8rgEU7NsS+AUBDKcICIx0u3yxYP2+5/bTAkpVIw 1HvTV2H3pld5A+hFIXJo46FJctlWIHKnrQMOYe72pz/QnLDkbxiG/hZvINYB2h+6GkgaO7pBsFq AzgFTYuRmuM/FLenZWVG6/fz/36vYSxd/3FQk11VPimapY+BLltHXqMBiMpor9ScKWrUEzhAF22 CwK2+FxGpOF3959g00gara5XZFs7srmblD5Ycbb5Gm4NcIp1m969gceuSuRfI7W/WFXnQ+8syXt 11Nxgd7/aI8dxKL/oSqR2OJ0PN3FUZD8JyCyhcENAv9Q== X-Zone-Loop: 778e586d7f063c241a30b0af42b1bd94fe2ea116dee4 x-campaign-type: default x-transaction-id: b02bd0b7-68a8-47da-ad3c-759b09dfb7fc x-swg-uid: 01-71e76db3-6b38-42c9-9fe7-72d52ba7331a X-Mailer: Sweego Message-ID: <1790178185.8631fc262581453bbf619ec5b2062170.1a0ceef50f800072c4@vates.tech> x-swg-bid: 1790178185.8631fc262581453bbf619ec5b2062170.1a0ceef50f800072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 34/39] xen/riscv: restore register state in the new IMSIC VS-file From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Wed, 23 Sep 2026 17:42:57 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790178179; l=3736; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=BzEfIFlrYQztHMGGHfEsDcs/jwvhxnFVfJJ5vToB52o=; b=m8+Mb1EfT83cdswF9PF2zoCMAGLeo+La8Nz9dDNRv9xu5eI7dabgWLBHLgPHMvr4+P0jCNzoF MaMvQ7F1RexAPthK4mM4mh7cWa++oZXZFNGQ2AnKU8rtfk/tq12s5ZS X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790178184823 X-purgate-ID: tlsNG-33051d/1790178189-74A894E9-24E0A020/10/73395122804 X-purgate-type: spam X-purgate-size: 3736 > At this point, all interrupt producers have been moved to the new > IMSIC VS-file so we move register state from the old IMSIC VS/SW-file > to the new IMSIC VS-file. > > As new IMSIC VS-file is ready to be used update vCPU's hstatus with > new VGEIN. > > As the whole migration procedure is finished add some extra explanatory > comments. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index 3cba58e0c1..d7b137a1f5 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -112,6 +112,12 @@ do { \ > r_; \ > }) > > +#define imsic_vs_csr_set(c, v) \ > +do { \ > + csr_write(CSR_VSISELECT, (c)); \ > + csr_set(CSR_VSIREG, (v)); \ > +} while ( 0 ) > + > #define imsic_vs_csr_write(c, v) \ > do { \ > csr_write(CSR_VSISELECT, (c)); \ > @@ -185,6 +191,19 @@ static void imsic_eix_write(unsigned int ireg, unsigned long val) > } > } > > +static void imsic_eix_set(unsigned int ireg, unsigned long val) > +{ > + switch ( ireg ) > + { > + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIP0, > + imsic_vs_csr_set, val) > + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIE0, > + imsic_vs_csr_set, val) > + default: > + ASSERT_UNREACHABLE(); > + } > +} > + > unsigned int vcpu_guest_file_id(const struct vcpu *v) > { > return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); > @@ -630,13 +649,13 @@ static void cf_check imsic_vsfile_local_read_clear(void *data) > old_vsiselect = csr_read(CSR_VSISELECT); > old_hstatus = csr_read(CSR_HSTATUS); > new_hstatus = old_hstatus & ~HSTATUS_VGEIN; > - new_hstatus |= ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT; > + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); > csr_write(CSR_HSTATUS, new_hstatus); > > /* > - * There is no need to use atomic functions version to store > - * values in MRIF because imsic_vsfile_read_clear() is always called > - * with pointer to temporary MRIF on stack. > + * No atomic accessors are needed to store the values into the MRIF here, > + * as imsic_vsfile_read_clear() is always called with a pointer to a > + * temporary MRIF on the stack. > */ > > mrif->eidelivery = imsic_vs_csr_swap(IMSIC_EIDELIVERY, 0); > @@ -972,6 +991,49 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, > return fdt_end_node(fdt); > } > > +static void cf_check imsic_vsfile_local_update(void *data) > +{ > + unsigned int i; > + struct imsic_mrif_eix *eix; > + const struct imsic_vsfile_data *idata = data; > + struct imsic_mrif *mrif = idata->mrif; > + unsigned long new_hstatus, old_hstatus, old_vsiselect; > + > + /* We can only update if we have a HW IMSIC context */ > + if ( !idata->hgei ) > + return; > + > + /* > + * No atomic accessors are needed to read the values out of the MRIF here, > + * as this is always called with a pointer to a temporary MRIF on the > + * stack. > + */ idata->mrif may point anywhere, so what the comment really states is a requirement on callers. It also only makes full sense next to KVM, where a shared SW-file MRIF is accessed atomically; Xen has neither of those (yet). Either explicitely explain that callers must declare mrif on their stack or move the comment directly in call sites. -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:45:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:45:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430967.1653368 (Exim 4.92) (envelope-from ) id 1x9PA5-0005wk-Rj; Wed, 23 Sep 2026 15:45:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430967.1653368; Wed, 23 Sep 2026 15:45:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PA5-0005wd-Or; Wed, 23 Sep 2026 15:45:33 +0000 Received: by outflank-mailman (input) for mailman id 1430967; Wed, 23 Sep 2026 15:45:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9PA4-0005wX-3q for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:45:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PA3-00DhQe-Gs for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:45:31 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f41b-2eae-0a2a0a5409dd-0a2a4507a486-0 for ; Wed, 23 Sep 2026 17:45:31 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f41b-b4ea-0a2a45070019-4a7de18de6c9-3 for ; Wed, 23 Sep 2026 17:45:31 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49cd38e0e5dso14020135e9.2 for ; Wed, 23 Sep 2026 08:45:31 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fde1da00bsm80910615e9.10.2026.09.23.08.45.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 08:45:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790178331; x=1790783131; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0Df1rqWp3t8plN4b+c9Y1sHrb3OEKE0S8PfzeS6gM4c=; b=SI6AteYVoA0SSu/g6nVHE7GuGKyee2U2UnqVNQ1Z5FJQ6mpEoq+c4bm8yIcVG8XmoK 5Qp36dpcP9brrB14tA2rua7W1Ep4dctshzKMwC0qmTFtk9hKTQKHg+Jt5qwUXCc8aor/ 9NwHUhINe7DgpHUL2VFog3ibk2GgiWESgNmSa1GYxSCAtbB7l3G3VWsesCy1ngP3qLjz 8Frz/259VBphdeM6ra8hlXSjU3SQj0686xWEB0ZHsQU9McWT1lzTgJZ2Y4fM51xHka8Z o2ZUcPdKYIrjo+qDgwGU5RSBxhSB4M2kta7VM7HlBytdxYZgqJLV1jrhv4K09jaE3rv4 55Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790178331; x=1790783131; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=0Df1rqWp3t8plN4b+c9Y1sHrb3OEKE0S8PfzeS6gM4c=; b=2NHdqJC6nroX/5y+rrkOS3DNwDXytfNAjZZmnuRJytx3DeWZnfOmbi9AHnVnOE5ArC ZikSycrvYqBdEUv7A2o/O0BVHvEUznuo8Yj2RTKnTXmkWsi7vilBNdK1r4B7SSeDTi0/ 5VKTjTUZqnBp4BeMvWiiu6qi3eLqJD8amSLMKCZzpmsYALBx/ytWMsEHhNulDzmgxtUf 7cQA4mLVmN7+Ct/Skqjv22s2l7z2d7cF8SWYFwCdB3ghVnkxADPxxjX5yeMUSfRlD2gu xs9I/QVpdnUaYOlzOFg/lqKogwFcPC0OAZo7XJcFdVF84+J66BNcAzIzAKQUa7LJwiUr ycGQ== X-Gm-Message-State: AFuF++nM5aaHmVrwoNPBFVvJ7N/1oUItUhj4Nd9Z6o4DhL4kEHHMHD2L G6a5Z0wNaGwgZ8xsw2voRpXzKRwC3uAAGTtXS6Quf+YLW1Iq0T9UbDUx X-Gm-Gg: AYBFou2MoQG5xaD9z1asc5YA0jRlOqGWj3EprHbht9bWoscnGOBsOn5iybYcf/xtwFZ IzV6B/rm/S/aLx4mnxFUR2UvaocvXHJJQO/FlqFVdITMpzP4E/bERUR5ZnYHfVh9SFWpDXv2QRn 7j/VjD+dCQaUvJ2jkWUEv4kqi5czWYv79nFROQuQ1wm9QGU7qgu/Qb0wfiqVWn/sbFyPt1AMEq5 nnT8e6Pd2+3+FZDngZTCULFXLMCoTD68gAStqyUroh1/r2c2d2B6Q7q7VvET4rmBNOSjemcRvP7 mdqKUxu0HvLEDg9HgUvy7sNqcIA5Qe5t36i0dnmUqim7aBLionrS7ooyFlVt6HX2I7yJlm5UO8X yZQhPsRrXDNisEhAW/uDw7XygoZmyGgimShdF1HFFZ1lFSYns7puTOrkri+zA5DvjILNcdJoYrd ltpUuj0MnFM/6geoH6gGn06w/Hl3NbX8/7coBjooi5hzy9Z3TOlAnCtpD5sEFy1pEE+GM7lFfqq lQg5JF6DxORIJWeke+tK4fueaebi0mcJdomzDrHtfA/I/JTOw== X-Received: by 2002:a05:600c:19d2:b0:49c:cee0:e7c1 with SMTP id 5b1f17b1804b1-49fdf1370bcmr45308265e9.16.1790178330682; Wed, 23 Sep 2026 08:45:30 -0700 (PDT) Message-ID: <8d29264c-d364-4a77-9ee9-977a1017f76b@gmail.com> Date: Wed, 23 Sep 2026 17:45:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> <1790170494.8631fc262581453bbf619ec5b2062170.1a0ce79f65d00072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790170494.8631fc262581453bbf619ec5b2062170.1a0ce79f65d00072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790178331-368D9AE4-3E6586E7/10/73395122804 X-purgate-type: spam X-purgate-size: 7746 On 9/23/26 3:34 PM, Baptiste Le Duc wrote: >> After new IMSIC VS-file is zeroed-out it is necessary to do G-stage remaping >> fo new IMSIC VS-file. Also, if any interrupts at an APLIC are forwarded by >> MSIs to the old interrupt file, reconfigure the APLIC to send them to the >> new interrupt file. >> >> Generally it is needed also to modify the relevant translation tables at >> all IOMMUs so that MSIs for this virtual interrupt file are now sent to >> the new physical interrupt file but it is skipped for now there is no IOMMU >> support for RISC-V. >> >> Synchronize with APLIC to ensure that no straggler MSIs will arrive at >> the old interrupt file by using of aplic_genmsi_barrier(). >> > > >> Technically there is no need for read_lock_irqsave() and >> read_unlock_irqrestore() around reading of ->guest_file_id, as a write >> cannot happen in parallel: any update to ->guest_file_id for a vCPU >> will happen either in imsic_migrate_vcpu() itself or before the vCPU > > >> first gains control (in continue_new_vcpu()), so there is no concurrent >> access to it in imsic_migrate_vcpu(). The lock is added here for >> potential future cases. >> >> Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard >> against silent incorrect behaviour or unexpected panics in guest VMs until >> the function is fully implemented. >> >> imsic_map_guest_file() and imsic_update_state() are stubs for now and will >> be introduced later in a separate patch. > "will be introduced later" would be stale in the future. I will drop that part from the commit message. >> >> Signed-off-by: Oleksii Kurochko > > >> >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c >> index 5de4594961..5e9f6995e4 100644 >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -27,6 +27,7 @@ >> #include >> >> #include >> +#include >> #include >> >> #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ) >> @@ -60,6 +61,12 @@ static unsigned int __ro_after_init guest_num_msis; >> #define IMSIC_DISABLE_EITHRESHOLD 1 >> #define IMSIC_ENABLE_EITHRESHOLD 0 >> >> +#define imsic_csr_read(c) \ >> +({ \ >> + csr_write(CSR_SISELECT, (c)); \ >> + csr_read(CSR_SIREG); \ >> +}) >> + >> #define imsic_csr_write(c, v) \ >> do { \ >> csr_write(CSR_SISELECT, c); \ >> @@ -141,6 +148,11 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v) >> return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); >> } >> >> +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id) >> +{ >> + BUG_ON("unimplemented\n"); >> +} >> + >> void __init imsic_ids_local_delivery(bool enable) >> { >> if ( enable ) >> @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) >> spin_unlock(&imsic_cfg.lock); >> } >> >> +static bool imsic_local_is_pending(unsigned int id) >> +{ >> + unsigned long isel = >> + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0; >> + unsigned long bit = BIT(id % BITS_PER_LONG, UL); >> + >> + return !!(imsic_csr_read(isel) & bit); >> +} >> + >> /* Callers aren't intended to changed imsic_cfg so return const. */ >> const struct imsic_config *imsic_get_config(void) >> { >> @@ -436,6 +457,11 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v) >> /* Nothing to do */ >> } >> >> +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) >> +{ >> + return -EOPNOTSUPP; >> +} >> + >> int cf_check vcpu_imsic_init(struct vcpu *v) >> { >> struct vimsic_state *imsic_state; >> @@ -497,6 +523,27 @@ static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), >> on_selected_cpus(cpumask_of(cpu), func, data, 1); >> } >> >> +/* >> + * Ensure that all the MSIs the APLIC has already generated for the hart this >> + * runs on have really reached the hart's IMSIC. >> + * >> + * The barrier is the one described by the AIA specification in >> + * "Synchronizing interactions between a hart and the APLIC": ask the APLIC to >> + * send an MSI to the hart itself and wait until it shows up as pending in the >> + * hart's own interrupt file. As it says nothing about MSIs on their way to >> + * any other hart, it has to be executed by the pCPU owning the interrupt file >> + * the MSIs were being sent to. >> + */ >> +static void cf_check imsic_aplic_sync(void *data) > It seems data arg is not used here It will be renamed to `unused` in the v3 but we still need to have it becuase how this function is called through imsic_call_on_cpu(). >> +{ >> + imsic_local_eix_update(imsic_cfg.sync_id, 1, true, false); >> + >> + aplic_genmsi_barrier(); >> + >> + while ( !imsic_local_is_pending(imsic_cfg.sync_id) ) >> + cpu_relax(); >> +} >> + >> static void cf_check imsic_vsfile_local_clear(void *data) >> { >> unsigned int i; >> @@ -837,6 +884,10 @@ void imsic_migrate_vcpu(struct vcpu *v) >> struct imsic_vsfile_data vsfile_data = { >> .nr_eix = nr_hw_eix, >> }; >> + struct vimsic_state *imsic_state = v->arch.vimsic_state; >> + unsigned long flags; >> + unsigned int old_vsfile_id; >> + unsigned int old_vsfile_cpu; >> >> /* >> * The scheduler can mark a freshly created vCPU's unit as migrated and >> @@ -848,8 +899,22 @@ void imsic_migrate_vcpu(struct vcpu *v) >> if ( v->arch.last_cpu == NR_CPUS ) >> return; >> >> + read_lock_irqsave(&imsic_state->vsfile_lock, flags); >> + old_vsfile_id = imsic_state->guest_file_id; >> + old_vsfile_cpu = imsic_state->vsfile_cpu; >> + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); >> + >> + /* >> + * We don't support SW interrupt files at the moment. Bail out before >> + * anything is touched, as the old file has no owning pCPU in that case >> + * and there is nothing to retarget the producers away from. >> + */ >> + if ( old_vsfile_cpu == NR_CPUS ) >> + panic("IMSIC SW-file isn't supported\n"); >> + >> /* >> * At this point, all interrupt producers are still using the old IMSIC >> + * VS-file so we first move all interrupt producers to the new IMSIC >> * VS-file. >> */ >> >> @@ -870,5 +935,43 @@ void imsic_migrate_vcpu(struct vcpu *v) >> /* Zero-out new IMSIC VS-file */ >> imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); >> + /* Update G-stage mapping for the new IMSIC VS-file */ >> + if ( imsic_map_guest_file(v, new_vsfile_hgei) ) >> + { >> + domain_crash(v->domain, "Migration to hw interrupt file failed\n"); >> + >> + return; >> + } >> + >> + imsic_update_state(v, new_vsfile_hgei); >> + > This gets rewritten later in the series by "xen/riscv: introduce IMSIC h/w > interrupt file attaching to vcpu", which moves the clear/map/update sequence > into imsic_vsfile_acquire() (and adds vgein_release() on the error path). > > Could imsic_vsfile_acquire() be introduced here (or in a prep patch) instead, > so that the later patch only adds imsic_vsfile_attach()? That would avoid the > churn. > It could, I just thought that it will be easier to justify necessity of it by introduction in "xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu". But I am okay to move it to this patch. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 23 15:48:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 15:48:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430975.1653376 (Exim 4.92) (envelope-from ) id 1x9PCw-0006eX-8u; Wed, 23 Sep 2026 15:48:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430975.1653376; Wed, 23 Sep 2026 15:48:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PCw-0006eQ-5y; Wed, 23 Sep 2026 15:48:30 +0000 Received: by outflank-mailman (input) for mailman id 1430975; Wed, 23 Sep 2026 15:48:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9PCu-0006eF-RC for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 15:48:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PCu-002LPW-85 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:48:28 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f4bb-bab6-0a2a0a5309dd-0a2a4508980e-24 for ; Wed, 23 Sep 2026 17:48:28 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f4cc-f659-0a2a45080019-4a7de14c9dcd-3 for ; Wed, 23 Sep 2026 17:48:28 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-485933b2522so911451f8f.0 for ; Wed, 23 Sep 2026 08:48:28 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-488684864c8sm7791217f8f.13.2026.09.23.08.48.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 08:48:27 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790178508; x=1790783308; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BrcQUm3sMIVns8lk9CG91x+QVKrVrHeCfmAuzpHBQG8=; b=sBmBimrpQiE/x1NqPv+jWZ53/NE6ahDM8cjk2D0VV9MG/pyh3EiI3ik5gOhErVuAnf ynclKikPTnCb9/wVT3mDr/p8uTwrJBf02RSJJtYe4jDhTgKSnTwJ+6vBQaLCZlinAnR7 y6oprYjMWUBcNm66yCknVu7Lq/jOkFnGXXTo3Qg5sjfhL0Gc+aBX6viCROMeovqk1hjC WXP5Yp3Dqi9p4KUTLK0Ig0yPk7e85Dz7hKTWDai5VP8D5OZDjPN1enO9PODCxpkw8PLA 9D2od+55tZ89EiaFdUCl91/kN2lj/frXMQKrcVs7wFjfagXmOdx6UnQwoDzMnzzu8zHK QjOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790178508; x=1790783308; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=BrcQUm3sMIVns8lk9CG91x+QVKrVrHeCfmAuzpHBQG8=; b=sL7lxlrc3eaLrS5lA0a6DInqNMMLFFGAl/WvXYt2OD5s0COfHn/hgdioZb9op3TppF pih0Hb9CrZw5qvgRv0dVPLl2i4+p6E5CA6Rpeft1/76P3IxI1A529/eTI3rYPKKnYqxo SbW9sKq2qSgyZjiFoMrAHOq6h3BhC7AOJwiXEGu2ZAxjgGEeI7eWBLoC0CeNtLT7IrTs X3GPDsvERPEqfgh5F8yITst+FDvKycurG4U/LIDbfddO5H4Z5K/TVZZLylwWCtFC0I58 NdMjvV2Vf3aVWcarmbdDOVvsE76G5kebT1VLp2QXZjUKeG/VutiqFGCjNMWfZnDmxpRq xbfw== X-Forwarded-Encrypted: i=1; AKwUvBwSOKqfThYlTVVSUGJj+rhm2hU042kVlcj16KtWVhvJL8RA1hAldXF1GrEXPD6rJcXKqTa8ePQ6cVQ=@lists.xenproject.org X-Gm-Message-State: AFuF++kGfYFAVc5sMy/oRF5VPiR+OarG1slmiZM7vjCxeRZC0LYh75v5 Z7TMjOYRIYgNc0AjTR6pP3sjOvsqXFWB7RzlSMU6+dMOdXe7X9aYl4Sl X-Gm-Gg: AYBFou2lKS/9k+ss9CoNACQT0/GJO8KAGRXsu27drBnq1k5VhhK+A+sKW74qORhWDSL vNM6kkq6oqWZSSAwDygklxaVxt5Qu8OpRg2cSQOW1qN8PE3U6C+xoNoEfIgFGb4nxi7hLzeorwz asW2Bcz0svTpbrE5KtV8JKYfUDSgLZfrQwA8mxu/CHfbhSghkNEeb/FKxNv5XMLpsTHrCZte6wE Rw2NToC5knKoUw/kVPA022owuR8yG5+W3WfbAZ2W9StvG/IilWpilPUGa4IZ24JNtwaQkpnwXlM 6OdudwA4/fxbV5/aJoJRy9vn9ZbCRuZ6Uc7QkITm5LcUxYMULQDAQ8BQAZOv+gkNgaTdcMKV+Ke PuvpYRpssnHpLiNtOBr0JCEp2+1PFq37dV2l9/A5l2nGm/HQ6XvgfuVwi8/g+hXpP5h04Qqjfps 0fXpOUGToVb1pZhVv61j9Fhl9mmqqcb7Nu/Rv8+8gxGH6VCwPuAkU8SFFYTi/wyC3qwE/ZmzDOW 9Qr7hoYwT2R7+XzxEifO3Tgl3b+cfYGIo1Qnea221Q/cCbPwQ== X-Received: by 2002:a05:6000:2dc9:b0:487:27f9:831 with SMTP id ffacd0b85a97d-488670956f2mr5417466f8f.38.1790178507529; Wed, 23 Sep 2026 08:48:27 -0700 (PDT) Message-ID: Date: Wed, 23 Sep 2026 17:48:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file To: Baptiste Le Duc , xen-devel@lists.xenproject.org Cc: Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> <1790177111.8631fc262581453bbf619ec5b2062170.1a0cedeee2900072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790177111.8631fc262581453bbf619ec5b2062170.1a0cedeee2900072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-c1860d/1790178508-D5D4887B-9E71D383/10/73395122804 X-purgate-type: spam X-purgate-size: 572 On 9/23/26 5:25 PM, Baptiste Le Duc wrote: > > xen/riscv: remap interrupts to new IMSIC VS-file > > Nit: The next patch uses "restore" in its title, we might want to use > "save" terminology here for symmetry? e.g.: >     "xen/riscv: save old interrupt file state to memory" Not only saving old interrupt file state happens here but also moving of all interrupts to new IMSIC VS-file. That why remap sounds okay here to me. If it is Nit: and no one else are against that I prefer to still have the commit subject as it is written now. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 23 16:02:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 16:02:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1430991.1653385 (Exim 4.92) (envelope-from ) id 1x9PQc-0002pf-DP; Wed, 23 Sep 2026 16:02:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430991.1653385; Wed, 23 Sep 2026 16:02:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PQc-0002pY-An; Wed, 23 Sep 2026 16:02:38 +0000 Received: by outflank-mailman (input) for mailman id 1430991; Wed, 23 Sep 2026 16:02:36 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9PQa-0002pS-Jw for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:02:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PQZ-00Djp6-T2 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:02:35 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f815-2eae-0a2a0a5409dd-0a2a4509dc8c-32 for ; Wed, 23 Sep 2026 18:02:35 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f81b-be1a-0a2a45090019-4a7de14cd365-3 for ; Wed, 23 Sep 2026 18:02:35 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356f6bso918444f8f.2 for ; Wed, 23 Sep 2026 09:02:35 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4886877a2d5sm7806149f8f.27.2026.09.23.09.02.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 09:02:34 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790179355; x=1790784155; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/q0mDgZ/wxMWTngw+7Jgt3OPCsYIoEMksfky8Q1Ehag=; b=mjUuytv9MlijgY7GZ1mwWsPeJ5oK7MqzgFF5dPxewS5uLEjFxLpFvQ0r9NkHgzFadt YfUDFG5qNS5sFYBW8cEWhzaC9ZKHWiNOqmQ/f/da+hVWcRmvodoBTf0l/VoqV4tlswsE GZPKqhju8qb4VXuGKXqKQiIwxuJG0PFtSL7l4Isug0SQhhWyYZKQSRtdYCyiS4gG6Bt/ 9Zns82ARlKZB9k9Hsciav1K7cIkh0glRlVS8vatbYL9IMmhHHBEeUhwroxKOxhChhKxC BVxkQEXDXppHmL8Pos0u8ZaMiwHDQBgdR1O+l3+djo2pXRMJK7C0QYjn5R/CqpeGZbOv QEcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790179355; x=1790784155; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=/q0mDgZ/wxMWTngw+7Jgt3OPCsYIoEMksfky8Q1Ehag=; b=qir2L80Gf0kUFZmM39LtHGGPmBIfsbnlhPr8JgSh2qNvhwtHnj+Nt87fzw0JGGIMMe PcM6+Vf82ZIeGfn4Vkeu1DsJDkvs4sU6UpUDqu2gf0GBWnV3zjQbGuZ0fhKGPvlSUu1G aee/CE17J9LhgvkkG0E88zGOwglPJkRFVibqlwr2ivPSJsd6HCo29n3wklvC3AGnxhSr /B9BZYQ8jib2im1F/JQrjeDgO+/F0ca5tb3s4Dvw0WJ6hsullAemmgiAJfDv8U5+IFqH +7CeG7leqyVXLMn4yuqSmQrxXjIoIklg9NjEN0+v+4achc/VMbRDDEe3cXDNOtK20/ZG jFrA== X-Gm-Message-State: AFuF++nBdjGGkuIiz/JhBoEDxOwzsaZVHE9SA8jXhkl7vVIP+/1wNSKG wbOr8pQk3Lk6Q7cJc4IR3A6XiSSgti5LCRCqxdnCfmsm7uaOGTYnANVe X-Gm-Gg: AYBFou1fum0ZR3KE2qcOVpR2kgUKjaa5HQMvv4g6DDtUo2IR66IslXdSiUJ0+MnUyhc ffLeXuBnkZXCdIYRP4mloD0JCR/j0bXeKeKFWCxi11MDsR78MyXuiSmnwqx3Wn0FoikG5DOBa6u 3aEm8kP3d15qSy+QXXYbIBAC0h+hQiDTurrm1Nf4G7YfTpsmh/fRnHdDrGLsVc7TjSrEtT7/PPa i4MV7816ASTpvfYx1SuwR7Ag+LQGiPMcOfMxhXwDMNuOILdZBwoIrDZnyNSbtqWW+/HK/1oH4D7 NVNueum4ibiy2/+qvZxF5dFWHBqRaEHcjL/q93lPd5S7ytPSXlgoDwqFZ9aTnpxQO4ai0CLyKBG W9MgLUwLmYHgh/4/DpraZmV/3djU/taMms610NY6QPIVjr7K5NaV0tOXKMrwDZytXnnMWKCAm+2 BBNkvQINUkUuhrC0h4+aSyddoz4LKlvOJd38YOVXNRALRqgQyyfWLDGuoL3JzuhVq/tP0GmfdUI 3YjkpAJYQLPfEiUqaZ5PoLdlDFeeyud3wohMu7PAzm0MbY3G5GDpqIekEuB X-Received: by 2002:a05:6000:4917:b0:487:27f9:835 with SMTP id ffacd0b85a97d-48867097636mr5412516f8f.42.1790179355216; Wed, 23 Sep 2026 09:02:35 -0700 (PDT) Message-ID: Date: Wed, 23 Sep 2026 18:02:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1790176561.8631fc262581453bbf619ec5b2062170.1a0ced6896200072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790176561.8631fc262581453bbf619ec5b2062170.1a0ced6896200072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-bad1c0/1790179355-BDEC6034-6015D010/10/73395122804 X-purgate-type: spam X-purgate-size: 4597 On 9/23/26 5:15 PM, Baptiste Le Duc wrote: >> At the old interrupt file, dump to memory all the eip and eie arrays). > Typo `)` Will drop `)`. >> After this step is done, the old interrupt file is no longer in use so >> old intrrupt file VGEIN could be released. >> >> Restoring of old interrupt file state will be done in follow-up >> patch. >> > > >> There are cases where it is needed to specify on which cpu it is >> necessary to VGEIN should be released so update vgein_release() to > > The sentence miss a verb, here is a proposal: > ``` > There are cases where the cpu on which the VGEIN is released needs to > be specified, so update vgein_release() to deal with that. > ``` I think it could be dropped at all as vgein_release() stub is just introduced here and not updated. > Moreover, could you explain me the cases you are talking about? It's not > clear by reading the commit message in the first place. For example, during migration of vCPU, vCPU->processor points to new CPU where it will be run but we still have to free VGEIN on the prev. ->processor. > > >> deal with that. > > > > >> > > >> Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > > >> against silent incorrect behaviour or unexpected panics in guest VMs until >> the function is fully implemented. >> > > >> vgein_release() is stub for now and will be introduced later. > > >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c >> index 75c82bcfa1..be3901ec0c 100644 >> --- a/xen/arch/riscv/aia.c >> +++ b/xen/arch/riscv/aia.c >> @@ -30,3 +30,8 @@ unsigned int vgein_assign(struct vcpu *v) >> >> return 0; >> } >> + >> +void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) >> +{ >> + BUG_ON("unimplemented\n"); >> +} >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c >> index 5e9f6995e4..3cba58e0c1 100644 >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -56,6 +56,24 @@ static unsigned int __ro_after_init guest_num_msis; >> */ >> #define GUEST_IMSIC_MAX_MSIS 255U >> >> +/* >> + * The interrupt identities an IMSIC interrupt file provides are 0 (which is >> + * never valid, but still occupies a bit) up to IMSIC_MAX_ID inclusive, so >> + * IMSIC_MAX_ID + 1 bits have to be covered. >> + */ >> +#define IMSIC_MAX_EIX DIV_ROUND_UP(IMSIC_MAX_ID + 1, BITS_PER_TYPE(uint64_t)) > > >> + >> +struct imsic_mrif_eix { >> + unsigned long eip[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; >> + unsigned long eie[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; > > >> +}; >> + >> +struct imsic_mrif { >> + struct imsic_mrif_eix eix[IMSIC_MAX_EIX]; >> + unsigned long eithreshold; >> + unsigned long eidelivery; >> +}; >> + > Maybe I didn't get something but I couldn't find anything in the commit > message explaining why do we use mrif here. It is just convenient way to temporary store h/w interrupt file. Also it could be used not only for ... > > Moreover, mrif, as described in aia spec (8.3 Memory-resident interrupt > files), seems to be only usable with IOMMU that Xen doesn't support. ... IOMMU but also to support more guest interrupts file implemented by IMSIC (basically what I am calling as software interrupt file). Without memory-resident interrupt files, the number of virtual RISC-V harts that can directly receive MSIs from devices is limited by the total number of guest interrupt files implemented by all IMSICs in the system, because all MSIs to RISC-V harts must go through IMSICs. For a single RISC-V hart, the number of guest interrupt files is the GEILEN parameter defined by the Privileged Architecture, which can be at most 31 for RV32 and 63 for RV64. > > If you want to have something in memory that could store some interrupt > file info, we should take another name to not be confusing. It seems like it is okay to use memory residential interrupt file (mrif) here based on KVM's code who are using mrif for the same purpose I described above. In short, MRIF is a joint virtualization technology shared between the IOMMU and the hypervisor. The IOMMU uses the MRIF as a memory target to land incoming hardware MSIs, while the hypervisor manages these MRIFs in RAM as software data structures to support an effectively unlimited number of vCPUs that don't currently hold a physical IMSIC guest file slot. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 23 16:06:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 16:06:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431000.1653395 (Exim 4.92) (envelope-from ) id 1x9PUX-0003Q3-Uy; Wed, 23 Sep 2026 16:06:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431000.1653395; Wed, 23 Sep 2026 16:06:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PUX-0003Pw-Rn; Wed, 23 Sep 2026 16:06:41 +0000 Received: by outflank-mailman (input) for mailman id 1431000; Wed, 23 Sep 2026 16:06:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9PUX-0003Pq-62 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:06:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PUW-006syD-JE for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:06:40 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f90b-bab6-0a2a0a5309dd-0a2a4505baf4-10 for ; Wed, 23 Sep 2026 18:06:40 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f909-4cb1-0a2a45050019-b9ff1c23ab2b-3 for ; Wed, 23 Sep 2026 18:06:33 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0cf04c50000072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 16:06:31 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id ACA7E821D0; Wed, 23 Sep 2026 18:06:30 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=5u/eTcreG0QuSFd8jlByPhWAmd+FFBURn7FziJ9iuu0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=i11TWXyTj0jn3qxDhBlH7xxNRDkI2HLqyjkjlRebnCn6k5cZbePmCA9B7mZeVeDB95dppfAWh dVTapgGyQCGcKGzMzVsFlqgB1HV08kV2rlZK/0SipeuZXYUw6LhyKIYPorB8V7L6w1+x3fftL9/ z+d+21IlQ7+jEkq+srlUgdqCG7FjroVGi52KIDsG+TMeibbAlsHZ1OW0mDf6FvXH6oQ8e0KnUwy x3KFhLZ7AaBhR+xnXk2O699s4CM8CAN+x8SEKhvj2HURoQbfYB1qN+p9CohuzIr4Jip1MQXmb1I VLRu0v1kUTYsfkn2wQ7wMyJqgHxjHMm1I/8i2kL8WsVA== X-Zone-Loop: e935b0beecb51268a1416fa808eacdf764709d38514e x-campaign-type: default x-transaction-id: 13b6e8c1-b990-478a-b1ee-b0d445f207f6 x-swg-uid: 01-2a7a0b0f-3dc0-4fe1-803b-40d12bb98007 X-Mailer: Sweego Message-ID: <1790179591.8631fc262581453bbf619ec5b2062170.1a0cf04c50000072c4@vates.tech> x-swg-bid: 1790179591.8631fc262581453bbf619ec5b2062170.1a0cf04c50000072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 35/39] xen/riscv: add basic VGEIN management for AIA guests From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Wed, 23 Sep 2026 18:06:24 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790179585; l=740; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=uXGs7KNYpvWbIOpxJBme/LyIpHdLhTjkO3HtjDwp5qM=; b=H6Mfte2NnQxdD5KuI5HYIT/UOwlFIE0Vq7vOSBV66qaCPhgG1lPaDGhEV2ydmp+JdlrjYPNmN ipPRoDUQvgaBrV9kRvSh1DLqQdS5KWUANlfsWXA8gmbN81Agw4raqEq X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790179590920 X-purgate-ID: tlsNG-c201ff/1790179593-F76BD2A1-DC12BC13/10/73395122804 X-purgate-type: spam X-purgate-size: 740 On Thu, 27 Aug 2026 17:21:19 +0200, Oleksii Kurochko wrote: > It was decided to add support for IMSIC from the start instead of having APLIC > operate in direct delivery mode, as it requires a trap-and-emulation approach, > which is not optimal from a performance standpoint. > > AIA provides a hardware-accelerated mechanism for delivering external > interrupts to domains via "guest interrupt files" located in IMSIC. > A single physical hart can implement multiple such files (up to GEILEN), > allowing several virtual harts to receive interrupts directly from hardware. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Wed Sep 23 16:09:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 16:09:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431005.1653404 (Exim 4.92) (envelope-from ) id 1x9PWi-0004B5-9K; Wed, 23 Sep 2026 16:08:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431005.1653404; Wed, 23 Sep 2026 16:08:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PWi-0004Ay-6X; Wed, 23 Sep 2026 16:08:56 +0000 Received: by outflank-mailman (input) for mailman id 1431005; Wed, 23 Sep 2026 16:08:55 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9PWh-0004Ap-AH for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:08:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PWg-003bvo-NQ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:08:54 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f97b-8faa-0a2a0a5109dd-0a2a450c8026-28 for ; Wed, 23 Sep 2026 18:08:54 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3f996-f479-0a2a450c0019-4a7de18cfc9d-3 for ; Wed, 23 Sep 2026 18:08:54 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d37b5so6781305e9.2 for ; Wed, 23 Sep 2026 09:08:54 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49fe1432362sm39142135e9.1.2026.09.23.09.08.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 09:08:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790179734; x=1790784534; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ZQiZ1ZDIfeSLUCok3ByEnxinfDfMblBOQQ17P/nhpH8=; b=N2M80tAEYT8KZpKJUV1EZQcq6ZPBGg804H+4Lb1MHzW2+n/28TeYCvPLkFERP+VOKv q9AqZn5huz0nY6UujWj2p/RXYGjhfbHbgUlBE46zuTR38Lri7hWYkoUxAtAsTFqgwcsZ wBKMop7dheZHeoPgK25zcGDxyMIgV/ejsm52sTqY0F7NHR0ZeKlLkEhet6rFc/we4Ju7 sshug0wU4NA+tfFt0yISMQYJfWXXcztqLb4h5/jk9ELiFUNyqrmXwxvC7g36ZfH+yE9a 43Ty+DDYNpK7eDZu5ecl+AYZ9AxmWBN+uLGhLjVfJUP4+qnPevvlkhqHvk+slzRgNZT6 gX2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790179734; x=1790784534; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=ZQiZ1ZDIfeSLUCok3ByEnxinfDfMblBOQQ17P/nhpH8=; b=qaisQSEkr2WSoVSD52YDkG02CktZE/9rbAlrd7KohVBbJ1B222gAp4fs/B6rHdRMdo XIVlvQr7zhrhVsatS6lGNPnVbjWugLmUYqI9SWk3+gc2a/bqVYdhY+J81FUWTqq0wAE5 nnYU65ccTx01PyDYHw/G5hTMxqPchZ59eP43N1c0kap9/dsuaJyCbPXsl1b1pLWFXUPt 4wsI4gZBDZChpT5dyp12JD67o8P/pKUU7QGNHyAwyVdEiuaLdQGxvy+jdzN4RuoEl+GC Z1tMvA8q195gxHi8uxGw6qJGVzxlRKmjj1lljDMjYZE9i3+7uUZJ2CWgTCYXR5ZsaJl4 79Tg== X-Gm-Message-State: AFuF++ml9Bvidpq8lkCy/B/Duc2MnwkDN0QS9vD7lKegsLfhGvyGLfpW nooXHxtmBJEQD0eJLIdIBbACoQrhWepkGKubkfhHOrEbK2cVNJlZxS6Y X-Gm-Gg: AYBFou3EZUdXVmDTlijzDaUGerKPYtezBjv+yNDc3i/fFexa+ITBoEPGZWvrzOQtDa1 ATdIE5ZNsjClwJVeX8hOpuzbw0F000XbW43ws6Y/dwj3CPvpWW/zwu73wnPxqoYzqYJqBUFRlLt 5yLGRVkeeI8qylP2g1m59QWiEcDrsx8TFgg5IxYtavcIY4xr+ER8+bHaO8GWWLiSWm5A3qScZCS t/d6OqIyzKCgfD2NP5hE2urFqIaC51glVNxcVoR5ZecyisYH/xxZPGomRL5lNblvfHKtqsqIF8s JO4cFxoiDxFESP0yYdITjGc93WQ8Gg6XocGNNZv7s+8Wcyo9srZu8ERfm9lClTmjZi164YLa4CR Xoflr6TF/OF1MuS3mNfkY4ZB8ZSNWISlDkehqOjnClrzTRcb+3VUyKcnn78ng2Yq6qlCl7pUWMX QCUvVtAGa4uI9uUbQ+J8iYRanGd+k/Acm3N/uPEJ+yqomKa8MmN3FjoWtRmBOrY1Q0qn3F/IKkf iQ01y7UZm+F90R0Rn/TwT6q8ye//HOPczDVGzHXCX79QWQI0tG8RY6rigNH X-Received: by 2002:a05:600c:3b84:b0:49c:ff8d:b548 with SMTP id 5b1f17b1804b1-49fdecd5957mr54289585e9.11.1790179734061; Wed, 23 Sep 2026 09:08:54 -0700 (PDT) Message-ID: <5798db51-1f8a-4ac2-b2e1-57ca07361479@gmail.com> Date: Wed, 23 Sep 2026 18:08:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 34/39] xen/riscv: restore register state in the new IMSIC VS-file To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1790178185.8631fc262581453bbf619ec5b2062170.1a0ceef50f800072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790178185.8631fc262581453bbf619ec5b2062170.1a0ceef50f800072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790179734-76ADCA5B-7E192520/10/73395122804 X-purgate-type: spam X-purgate-size: 4341 On 9/23/26 5:42 PM, Baptiste Le Duc wrote: >> At this point, all interrupt producers have been moved to the new >> IMSIC VS-file so we move register state from the old IMSIC VS/SW-file >> to the new IMSIC VS-file. >> >> As new IMSIC VS-file is ready to be used update vCPU's hstatus with >> new VGEIN. >> >> As the whole migration procedure is finished add some extra explanatory >> comments. >> >> Signed-off-by: Oleksii Kurochko >> >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c >> index 3cba58e0c1..d7b137a1f5 100644 >> --- a/xen/arch/riscv/imsic.c >> +++ b/xen/arch/riscv/imsic.c >> @@ -112,6 +112,12 @@ do { \ >> r_; \ >> }) >> >> +#define imsic_vs_csr_set(c, v) \ >> +do { \ >> + csr_write(CSR_VSISELECT, (c)); \ >> + csr_set(CSR_VSIREG, (v)); \ >> +} while ( 0 ) >> + >> #define imsic_vs_csr_write(c, v) \ >> do { \ >> csr_write(CSR_VSISELECT, (c)); \ >> @@ -185,6 +191,19 @@ static void imsic_eix_write(unsigned int ireg, unsigned long val) >> } >> } >> >> +static void imsic_eix_set(unsigned int ireg, unsigned long val) >> +{ >> + switch ( ireg ) >> + { >> + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIP0, >> + imsic_vs_csr_set, val) >> + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIE0, >> + imsic_vs_csr_set, val) >> + default: >> + ASSERT_UNREACHABLE(); >> + } >> +} >> + >> unsigned int vcpu_guest_file_id(const struct vcpu *v) >> { >> return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); >> @@ -630,13 +649,13 @@ static void cf_check imsic_vsfile_local_read_clear(void *data) >> old_vsiselect = csr_read(CSR_VSISELECT); >> old_hstatus = csr_read(CSR_HSTATUS); >> new_hstatus = old_hstatus & ~HSTATUS_VGEIN; >> - new_hstatus |= ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT; >> + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); > > >> csr_write(CSR_HSTATUS, new_hstatus); >> >> /* >> - * There is no need to use atomic functions version to store >> - * values in MRIF because imsic_vsfile_read_clear() is always called >> - * with pointer to temporary MRIF on stack. >> + * No atomic accessors are needed to store the values into the MRIF here, >> + * as imsic_vsfile_read_clear() is always called with a pointer to a >> + * temporary MRIF on the stack. >> */ > > >> >> mrif->eidelivery = imsic_vs_csr_swap(IMSIC_EIDELIVERY, 0); >> @@ -972,6 +991,49 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, >> return fdt_end_node(fdt); >> } >> >> +static void cf_check imsic_vsfile_local_update(void *data) >> +{ >> + unsigned int i; >> + struct imsic_mrif_eix *eix; >> + const struct imsic_vsfile_data *idata = data; >> + struct imsic_mrif *mrif = idata->mrif; >> + unsigned long new_hstatus, old_hstatus, old_vsiselect; >> + >> + /* We can only update if we have a HW IMSIC context */ >> + if ( !idata->hgei ) >> + return; >> + >> + /* >> + * No atomic accessors are needed to read the values out of the MRIF here, >> + * as this is always called with a pointer to a temporary MRIF on the >> + * stack. >> + */ > idata->mrif may point anywhere, so what the comment really states is a > requirement on callers. It also only makes full sense next to KVM, where > a shared SW-file MRIF is accessed atomically; Xen has neither of those > (yet). Either explicitely explain that callers must declare mrif on > their stack or move the comment directly in call sites. It is mentioned in the comment "is always called with a pointer to a temporary MRIF on the stack.". With SW-file MRIF I expect that atomic operations should be used so this functions shouldn't just use for them and I assume KVM has something different function to work with SW-file MRIF. Anyway just mentioning KVM code isn't always useful as it forces me to go and investigate what is going on there what I am not fully convinced that it is okay... ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 23 16:10:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 16:10:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431014.1653413 (Exim 4.92) (envelope-from ) id 1x9PYU-0005zk-Kr; Wed, 23 Sep 2026 16:10:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431014.1653413; Wed, 23 Sep 2026 16:10:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PYU-0005zd-Hs; Wed, 23 Sep 2026 16:10:46 +0000 Received: by outflank-mailman (input) for mailman id 1431014; Wed, 23 Sep 2026 16:10:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9PYS-0005xv-PN for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:10:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PYS-002fPv-6J for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:10:44 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3f9e3-bab6-0a2a0a5309dd-0a2a45098d38-48 for ; Wed, 23 Sep 2026 18:10:44 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3fa03-be1a-0a2a45090019-b9ff1c22a9e7-3 for ; Wed, 23 Sep 2026 18:10:44 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0cf088fee00072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 16:10:39 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 28D5781ECA; Wed, 23 Sep 2026 18:10:39 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=qx7QpStwAj2cE4Bmzohc09PgJcPxfa088N+FxTCVtZQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=cGF8LWwn7MrPYYnw+69OR89/VxDBn10BWcLOatdHJBOAscCz8X4OUPGVrdJwM3CBntSaIxr5J 6vZwRMUcMX5k2Sjr+MjroDRmdKu7lvC10TpCVP6fBSeZdfVaQ3tzv7hkK2eyn2Xtli7erfG8FS6 RVfKvVxzldH1f4wcTGHlawqLuzEFMq0wKi3mn0wT0N2K5HfkgAxmGymP4PGPdAyPTnPHCN6pbyJ w4ayduG5tDkjZ1xfU/yPVQakTPi1U/EPmolv4IgcK2i2W+zofIU24Za/cIVbS5fZdn5/s/4hzz0 PjJNk1vJl/g7U8RsrNaOTAlbJWEwtQb9CEvPtuhtpLSw== X-Zone-Loop: 9557bc61d4a503d48f71b6fce58a1212c63dd5ed7165 x-campaign-type: default x-transaction-id: 26c5978a-c6df-4445-bbc9-287818c133f5 x-swg-uid: 01-52226159-ac85-49b0-9ee2-949ac5830d1f X-Mailer: Sweego Message-ID: <1790179840.8631fc262581453bbf619ec5b2062170.1a0cf088fee00072c4@vates.tech> x-swg-bid: 1790179840.8631fc262581453bbf619ec5b2062170.1a0cf088fee00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <8d29264c-d364-4a77-9ee9-977a1017f76b@gmail.com> References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> <1790170494.8631fc262581453bbf619ec5b2062170.1a0ce79f65d00072c4@vates.tech> <8d29264c-d364-4a77-9ee9-977a1017f76b@gmail.com> Date: Wed, 23 Sep 2026 18:10:33 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790179833; l=8373; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=LWDkhZK1XqirHOS30CJhnD9DTRwv/nX7EX/5TDmau/0=; b=/Z85VKs9aFIH4Y7lTNu1ygLjppOq1eYOWKtp0lLYLwQndInrWv+clMj3gX5CRgou6gCWBgy+t eFQOMwweFWaAGOdSfFjZ9GGVCfZImUta7sQ1tCCcydycYjXMl/rqi1j X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790179839377 X-purgate-ID: tlsNG-bad1c0/1790179844-3A4DB034-25E1E57C/10/73395122804 X-purgate-type: spam X-purgate-size: 8377 On 2026-09-23 17:45 +0200, Oleksii Kurochko wrote: > > > On 9/23/26 3:34 PM, Baptiste Le Duc wrote: > >> After new IMSIC VS-file is zeroed-out it is necessary to do G-stage remaping > >> fo new IMSIC VS-file. Also, if any interrupts at an APLIC are forwarded by > >> MSIs to the old interrupt file, reconfigure the APLIC to send them to the > >> new interrupt file. > >> > >> Generally it is needed also to modify the relevant translation tables at > >> all IOMMUs so that MSIs for this virtual interrupt file are now sent to > >> the new physical interrupt file but it is skipped for now there is no IOMMU > >> support for RISC-V. > >> > >> Synchronize with APLIC to ensure that no straggler MSIs will arrive at > >> the old interrupt file by using of aplic_genmsi_barrier(). > >> > > > > > >> Technically there is no need for read_lock_irqsave() and > >> read_unlock_irqrestore() around reading of ->guest_file_id, as a write > >> cannot happen in parallel: any update to ->guest_file_id for a vCPU > >> will happen either in imsic_migrate_vcpu() itself or before the vCPU > > > > > >> first gains control (in continue_new_vcpu()), so there is no concurrent > >> access to it in imsic_migrate_vcpu(). The lock is added here for > >> potential future cases. > >> > >> Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > >> against silent incorrect behaviour or unexpected panics in guest VMs until > >> the function is fully implemented. > >> > >> imsic_map_guest_file() and imsic_update_state() are stubs for now and will > >> be introduced later in a separate patch. > > "will be introduced later" would be stale in the future. > > I will drop that part from the commit message. > > >> > >> Signed-off-by: Oleksii Kurochko > > > > > >> > >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > >> index 5de4594961..5e9f6995e4 100644 > >> --- a/xen/arch/riscv/imsic.c > >> +++ b/xen/arch/riscv/imsic.c > >> @@ -27,6 +27,7 @@ > >> #include > >> > >> #include > >> +#include > >> #include > >> > >> #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_SZ) > >> @@ -60,6 +61,12 @@ static unsigned int __ro_after_init guest_num_msis; > >> #define IMSIC_DISABLE_EITHRESHOLD 1 > >> #define IMSIC_ENABLE_EITHRESHOLD 0 > >> > >> +#define imsic_csr_read(c) \ > >> +({ \ > >> + csr_write(CSR_SISELECT, (c)); \ > >> + csr_read(CSR_SIREG); \ > >> +}) > >> + > >> #define imsic_csr_write(c, v) \ > >> do { \ > >> csr_write(CSR_SISELECT, c); \ > >> @@ -141,6 +148,11 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v) > >> return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); > >> } > >> > >> +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id) > >> +{ > >> + BUG_ON("unimplemented\n"); > >> +} > >> + > >> void __init imsic_ids_local_delivery(bool enable) > >> { > >> if ( enable ) > >> @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) > >> spin_unlock(&imsic_cfg.lock); > >> } > >> > >> +static bool imsic_local_is_pending(unsigned int id) > >> +{ > >> + unsigned long isel = > >> + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_EIP0; > >> + unsigned long bit = BIT(id % BITS_PER_LONG, UL); > >> + > >> + return !!(imsic_csr_read(isel) & bit); > >> +} > >> + > >> /* Callers aren't intended to changed imsic_cfg so return const. */ > >> const struct imsic_config *imsic_get_config(void) > >> { > >> @@ -436,6 +457,11 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v) > >> /* Nothing to do */ > >> } > >> > >> +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) > >> +{ > >> + return -EOPNOTSUPP; > >> +} > >> + > >> int cf_check vcpu_imsic_init(struct vcpu *v) > >> { > >> struct vimsic_state *imsic_state; > >> @@ -497,6 +523,27 @@ static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), > >> on_selected_cpus(cpumask_of(cpu), func, data, 1); > >> } > >> > >> +/* > >> + * Ensure that all the MSIs the APLIC has already generated for the hart this > >> + * runs on have really reached the hart's IMSIC. > >> + * > >> + * The barrier is the one described by the AIA specification in > >> + * "Synchronizing interactions between a hart and the APLIC": ask the APLIC to > >> + * send an MSI to the hart itself and wait until it shows up as pending in the > >> + * hart's own interrupt file. As it says nothing about MSIs on their way to > >> + * any other hart, it has to be executed by the pCPU owning the interrupt file > >> + * the MSIs were being sent to. > >> + */ > >> +static void cf_check imsic_aplic_sync(void *data) > > It seems data arg is not used here > > It will be renamed to `unused` in the v3 but we still need to have it > becuase how this function is called through imsic_call_on_cpu(). > > >> +{ > >> + imsic_local_eix_update(imsic_cfg.sync_id, 1, true, false); > >> + > >> + aplic_genmsi_barrier(); > >> + > >> + while ( !imsic_local_is_pending(imsic_cfg.sync_id) ) > >> + cpu_relax(); > >> +} > >> + > >> static void cf_check imsic_vsfile_local_clear(void *data) > >> { > >> unsigned int i; > >> @@ -837,6 +884,10 @@ void imsic_migrate_vcpu(struct vcpu *v) > >> struct imsic_vsfile_data vsfile_data = { > >> .nr_eix = nr_hw_eix, > >> }; > >> + struct vimsic_state *imsic_state = v->arch.vimsic_state; > >> + unsigned long flags; > >> + unsigned int old_vsfile_id; > >> + unsigned int old_vsfile_cpu; > >> > >> /* > >> * The scheduler can mark a freshly created vCPU's unit as migrated and > >> @@ -848,8 +899,22 @@ void imsic_migrate_vcpu(struct vcpu *v) > >> if ( v->arch.last_cpu == NR_CPUS ) > >> return; > >> > >> + read_lock_irqsave(&imsic_state->vsfile_lock, flags); > >> + old_vsfile_id = imsic_state->guest_file_id; > >> + old_vsfile_cpu = imsic_state->vsfile_cpu; > >> + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > >> + > >> + /* > >> + * We don't support SW interrupt files at the moment. Bail out before > >> + * anything is touched, as the old file has no owning pCPU in that case > >> + * and there is nothing to retarget the producers away from. > >> + */ > >> + if ( old_vsfile_cpu == NR_CPUS ) > >> + panic("IMSIC SW-file isn't supported\n"); > >> + > >> /* > >> * At this point, all interrupt producers are still using the old IMSIC > >> + * VS-file so we first move all interrupt producers to the new IMSIC > >> * VS-file. > >> */ > >> > >> @@ -870,5 +935,43 @@ void imsic_migrate_vcpu(struct vcpu *v) > >> /* Zero-out new IMSIC VS-file */ > >> imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); > >> + /* Update G-stage mapping for the new IMSIC VS-file */ > >> + if ( imsic_map_guest_file(v, new_vsfile_hgei) ) > >> + { > >> + domain_crash(v->domain, "Migration to hw interrupt file failed\n"); > >> + > >> + return; > >> + } > >> + > >> + imsic_update_state(v, new_vsfile_hgei); > >> + > > This gets rewritten later in the series by "xen/riscv: introduce IMSIC h/w > > interrupt file attaching to vcpu", which moves the clear/map/update sequence > > into imsic_vsfile_acquire() (and adds vgein_release() on the error path). > > > > Could imsic_vsfile_acquire() be introduced here (or in a prep patch) instead, > > so that the later patch only adds imsic_vsfile_attach()? That would avoid the > > churn. > > > > It could, I just thought that it will be easier to justify necessity of > it by introduction in "xen/riscv: introduce IMSIC h/w interrupt file > attaching to vcpu". But I am okay to move it to this patch. Hum, finally I don't know if it's the good solution. First time I'm saw this, so I was suprised, but if it's common practice, let's keep it here for clarity. > Thanks. > > ~ Oleksii > > > From xen-devel-bounces@lists.xenproject.org Wed Sep 23 16:11:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 16:11:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431022.1653423 (Exim 4.92) (envelope-from ) id 1x9PZS-0006VQ-1f; Wed, 23 Sep 2026 16:11:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431022.1653423; Wed, 23 Sep 2026 16:11:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PZR-0006VI-U0; Wed, 23 Sep 2026 16:11:45 +0000 Received: by outflank-mailman (input) for mailman id 1431022; Wed, 23 Sep 2026 16:11:44 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PZQ-0006V6-G9 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:11:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PZP-00Dl2o-Jg for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:11:43 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3fa2d-2eae-0a2a0a5409dd-0a2a45078d06-16 for ; Wed, 23 Sep 2026 18:11:43 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3fa3f-b4ea-0a2a45070019-b9ff1c228d5f-3 for ; Wed, 23 Sep 2026 18:11:43 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0cf09703a00072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 16:11:37 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 8AE2A80631; Wed, 23 Sep 2026 18:11:36 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=2HIAdadP+KD4GDYkD9yrelDKi0UtXXzIp5jVVwwrDIk=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=qJdU/vZjv9WXQkGqEy+t80g5Z46q7DSmDegsKlPDJHqSetU/qsX/ZEMGvxTB0sUkKCXMyPTpn jt5InRUYDUhCwPJXm/AjV3RSirKeLntZMezcoZH3hIKABgiCtQV3oYsslqExb1qIOuKzrW2496i 4knkNi6lTxtStAwFJQYShVzp64vdVAGbwMuPNXZ8xDUYDqVIOkU9+1svBhx2gOZuTmpA0ahAeCh L9YRWYHj6PARcAJtuPeCayRNZI/f+lJg4SPHzEbOm+mI+HOhliVHHe91WS/yH/eh1WedTAcjNeS P14jPlzHDqeN8IbVCm/Ne/JIYIt5ng5fLOat1EpOdtpg== X-Zone-Loop: 4072e9ffd25b814610e0999d089d040a9e756aa6b2e8 x-campaign-type: default x-transaction-id: 360b78a8-c284-4f5c-8aec-fe9c80a480e4 x-swg-uid: 01-af3cd627-f8c3-4d07-b1bc-f9df78c75baa X-Mailer: Sweego Message-ID: <1790179897.8631fc262581453bbf619ec5b2062170.1a0cf09703a00072c4@vates.tech> x-swg-bid: 1790179897.8631fc262581453bbf619ec5b2062170.1a0cf09703a00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> <1790177111.8631fc262581453bbf619ec5b2062170.1a0cedeee2900072c4@vates.tech> Date: Wed, 23 Sep 2026 18:11:30 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790179891; l=690; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=KF919M5+CLGKZ43Zn/fPjANBWs6qZB/cLfYGpXEQjwQ=; b=LyFnDB2n3kFGcES3p1KF1o0uTEiEdoGAkzwG7YzhdjW7JUEpuwpWdaB2W5ABL1UCQUQ0/XHFS OkFNwdqA9nIDnfykxvL8ALxWeCiVbePESgYwbGmzuMTG+2ovl3sK8tY X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790179896771 X-purgate-ID: tlsNG-ef75cf/1790179903-348C9AE4-C31D9299/0/0 X-purgate-type: clean X-purgate-size: 694 On 2026-09-23 17:48 +0200, Oleksii Kurochko wrote: > > > On 9/23/26 5:25 PM, Baptiste Le Duc wrote: > > > xen/riscv: remap interrupts to new IMSIC VS-file > > > > Nit: The next patch uses "restore" in its title, we might want to use > > "save" terminology here for symmetry? e.g.: > >     "xen/riscv: save old interrupt file state to memory" > > Not only saving old interrupt file state happens here but also moving of > all interrupts to new IMSIC VS-file. That why remap sounds okay here to > me. If it is Nit: and no one else are against that I prefer to still > have the commit subject as it is written now. Ok lets keep the original. > > ~ Oleksii > > From xen-devel-bounces@lists.xenproject.org Wed Sep 23 16:16:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 16:16:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431034.1653430 (Exim 4.92) (envelope-from ) id 1x9Pdn-00076d-Ex; Wed, 23 Sep 2026 16:16:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431034.1653430; Wed, 23 Sep 2026 16:16:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Pdn-00076W-CM; Wed, 23 Sep 2026 16:16:15 +0000 Received: by outflank-mailman (input) for mailman id 1431034; Wed, 23 Sep 2026 16:16:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9Pdl-00076Q-RF for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:16:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Pdl-009hFR-83 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:16:13 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3fb4c-8faa-0a2a0a5109dd-0a2a4501e296-2 for ; Wed, 23 Sep 2026 18:16:13 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3fb4c-5984-0a2a45010019-b9ff1c23993f-3 for ; Wed, 23 Sep 2026 18:16:13 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0cf0d8f3d00072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 16:16:07 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id AC42D823C8; Wed, 23 Sep 2026 18:16:06 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=oQLDKepFC1/6fjRcI/L2o87sUQfeFA1nZIRfVNoZT78=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=Fclsr/LBOObgvt8b8WHi/RKMgTyarqOZ1VSuLow+4WIqR/fQ7qu/u0PBi3qqUC1iuoqgc/WBu YB+ipP7qIjdV7IHUyUXuOM9P9UewiWBv3H/7Hn62VUF9xINVjivYzNcx4cTe7v1Fmv7YyNEZfks 2j9NuYPwo2+0c9qus0wLFMgqQMWCYN2DdsfPhDnllvcd1Irb2QlM7jif6vVfaeSUNVsHnIvwZqR oewpcug1TWFP5xSjqVl67UF+Rr4uGF2rgz2zKktTuNGdgP1cdYUqB+4YyYVAeEpgBbxN5e9xoPG eXTwCC/G3aAAWbHEizG7HatOR9J9tvFTIsF1lErwpRyA== X-Zone-Loop: bb80efb9a9318bf4bdf9d1e1622e77e992dd89d3a31e x-campaign-type: default x-transaction-id: 6c308739-af24-4265-bc3e-e33eebd8e8a2 x-swg-uid: 01-0329b717-3c87-490f-a76b-f7f39bc26e42 X-Mailer: Sweego Message-ID: <1790180167.8631fc262581453bbf619ec5b2062170.1a0cf0d8f3d00072c4@vates.tech> x-swg-bid: 1790180167.8631fc262581453bbf619ec5b2062170.1a0cf0d8f3d00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: <1790176561.8631fc262581453bbf619ec5b2062170.1a0ced6896200072c4@vates.tech> Date: Wed, 23 Sep 2026 18:16:01 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790180161; l=5132; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Iybz0s5DPivkmLYMGXVMKTbxH9pgRvXaJVT7/W66QwI=; b=ttMi1pbP5KAjMSSAe6zAlSTxylLn9EaiiDLR1TTmAsor1SBqbO3RQf3YD1M2A3TUeRmMXHHsh 7H1KP3uWackBR1eYsa8nm3sgRdx6XmkN66HtJTZsneE6CFPvUKdqy71 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790180166910 X-purgate-ID: tlsNG-d62444/1790180173-BE664757-A97AF55A/10/73395122804 X-purgate-type: spam X-purgate-size: 5136 On 2026-09-23 18:02 +0200, Oleksii Kurochko wrote: > > > On 9/23/26 5:15 PM, Baptiste Le Duc wrote: > >> At the old interrupt file, dump to memory all the eip and eie arrays). > > Typo `)` > > Will drop `)`. > > >> After this step is done, the old interrupt file is no longer in use so > >> old intrrupt file VGEIN could be released. > >> > >> Restoring of old interrupt file state will be done in follow-up > >> patch. > >> > > > > > >> There are cases where it is needed to specify on which cpu it is > >> necessary to VGEIN should be released so update vgein_release() to > > > > The sentence miss a verb, here is a proposal: > > ``` > > There are cases where the cpu on which the VGEIN is released needs to > > be specified, so update vgein_release() to deal with that. > > ``` > > I think it could be dropped at all as vgein_release() stub is just > introduced here and not updated. > > > Moreover, could you explain me the cases you are talking about? It's not > > clear by reading the commit message in the first place. > > For example, during migration of vCPU, vCPU->processor points to new CPU > where it will be run but we still have to free VGEIN on the prev. > ->processor. > > > > > > >> deal with that. > > > > > > > > > >> > > > > > >> Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard > > > > > >> against silent incorrect behaviour or unexpected panics in guest VMs until > >> the function is fully implemented. > >> > > > > > >> vgein_release() is stub for now and will be introduced later. > > > > > >> > >> Signed-off-by: Oleksii Kurochko > >> > >> diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c > >> index 75c82bcfa1..be3901ec0c 100644 > >> --- a/xen/arch/riscv/aia.c > >> +++ b/xen/arch/riscv/aia.c > >> @@ -30,3 +30,8 @@ unsigned int vgein_assign(struct vcpu *v) > >> > >> return 0; > >> } > >> + > >> +void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) > >> +{ > >> + BUG_ON("unimplemented\n"); > >> +} > >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > >> index 5e9f6995e4..3cba58e0c1 100644 > >> --- a/xen/arch/riscv/imsic.c > >> +++ b/xen/arch/riscv/imsic.c > >> @@ -56,6 +56,24 @@ static unsigned int __ro_after_init guest_num_msis; > >> */ > >> #define GUEST_IMSIC_MAX_MSIS 255U > >> > >> +/* > >> + * The interrupt identities an IMSIC interrupt file provides are 0 (which is > >> + * never valid, but still occupies a bit) up to IMSIC_MAX_ID inclusive, so > >> + * IMSIC_MAX_ID + 1 bits have to be covered. > >> + */ > >> +#define IMSIC_MAX_EIX DIV_ROUND_UP(IMSIC_MAX_ID + 1, BITS_PER_TYPE(uint64_t)) > > > > > >> + > >> +struct imsic_mrif_eix { > >> + unsigned long eip[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; > >> + unsigned long eie[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; > > > > > >> +}; > >> + > >> +struct imsic_mrif { > >> + struct imsic_mrif_eix eix[IMSIC_MAX_EIX]; > >> + unsigned long eithreshold; > >> + unsigned long eidelivery; > >> +}; > >> + > > Maybe I didn't get something but I couldn't find anything in the commit > > message explaining why do we use mrif here. > > It is just convenient way to temporary store h/w interrupt file. Also it > could be used not only for ... > > > > > Moreover, mrif, as described in aia spec (8.3 Memory-resident interrupt > > files), seems to be only usable with IOMMU that Xen doesn't support. > > ... IOMMU but also to support more guest interrupts file implemented by > IMSIC (basically what I am calling as software interrupt file). Without > memory-resident interrupt files, the number of virtual RISC-V harts that > can directly receive MSIs from devices is limited by the total number of > guest interrupt files implemented by all IMSICs in the system, because > all MSIs to RISC-V harts must go through IMSICs. For a single RISC-V > hart, the number of guest interrupt files is the GEILEN parameter > defined by the Privileged Architecture, which can be at most 31 for RV32 > and 63 for RV64. > > > > > If you want to have something in memory that could store some interrupt > > file info, we should take another name to not be confusing. > > It seems like it is okay to use memory residential interrupt file (mrif) > here based on KVM's code who are using mrif for the same purpose I > described above. > > In short, MRIF is a joint virtualization technology shared between the > IOMMU and the hypervisor. The IOMMU uses the MRIF as a memory target to > land incoming hardware MSIs, while the hypervisor manages these MRIFs in > RAM as software data structures to support an effectively unlimited > number of vCPUs that don't currently hold a physical IMSIC guest file slot. > Yes, I read the spec to understand but here, mrif doesn't catch the MSIs right? so it's not exactly the behaviour mentioned or you have in mind to add full support when IOMMU will be supported? > ~ Oleksii > > > From xen-devel-bounces@lists.xenproject.org Wed Sep 23 16:20:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 16:20:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431047.1653440 (Exim 4.92) (envelope-from ) id 1x9PhW-0000hW-Uq; Wed, 23 Sep 2026 16:20:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431047.1653440; Wed, 23 Sep 2026 16:20:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PhW-0000hO-Q5; Wed, 23 Sep 2026 16:20:06 +0000 Received: by outflank-mailman (input) for mailman id 1431047; Wed, 23 Sep 2026 16:20:04 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PhQ-0008Ey-MV for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:20:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PhP-00EKA5-SZ for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:19:59 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3fc2b-e002-0a2a0a5209dd-0a2a45078a3e-14 for ; Wed, 23 Sep 2026 18:19:59 +0200 Received: from [40.93.196.43] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3fc2d-b4ea-0a2a45070019-285dc42b452b-3 for ; Wed, 23 Sep 2026 18:19:58 +0200 Received: from MW4PR03CA0081.namprd03.prod.outlook.com (2603:10b6:303:b6::26) by IA0PPF64A94D5DF.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bd0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Wed, 23 Sep 2026 16:19:52 +0000 Received: from CO1PEPF00012E7D.namprd03.prod.outlook.com (2603:10b6:303:b6:cafe::2c) by MW4PR03CA0081.outlook.office365.com (2603:10b6:303:b6::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.16 via Frontend Transport; Wed, 23 Sep 2026 16:19:49 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF00012E7D.mail.protection.outlook.com (10.167.249.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Wed, 23 Sep 2026 16:19:49 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 23 Sep 2026 11:19:48 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Wed, 23 Sep 2026 11:19:48 -0500 Received: from fedora (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Wed, 23 Sep 2026 11:19:47 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Z+ogYtxpuJyktxxUPNzUYEgRMYKTOPncp8iH6OjAhNhPA3DQAwSmHuo0gT38zea09P//M/aBEeWM8I3k6pcRlCk2AYj4YNl3wDTC35YQM2SfS6dalxWgVpPNry/l6XtogUY2GvBBHHmEbTKmWTzR736JgIBfA+8GtndN4zDmUS6L3ueqwQCMI6D4cZNaev7Up93ZNYzqqfwVZ4JMhWYl9D9X2mSl0kC8FKsyyvOIX45PN0LEgnQq5arY+6EPCC1Je/D39lAExNQOKZZF4Tm6qsc54V7h8h8LkH4M8dqy6fCTpZfg3ruJw4Q+miArRXq/7qfREMxcJZGMpXqiGNzsgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GyKqwygtGsE4qSrFPliY7ncBXi+c2UzL9Gwyvrui5b0=; b=N5sReWPRVLkC38xdLJc0SRnqD4YS3Xe5xTy1yV6aqlVa93vXfQzNdbt+xsIB1PY3hqgGZAelWMxaBrCXdxi2s+H7ApSNeliGxc3P5loUebT7K+mm4RlIaZdooZAEz97EE6dOVCUIxLuRE8b6pktvH07UcH5aMbCuMs2bF8yxFz83oeAi51Be764kfl99omGWUbqk46yXKDub70qmGQUlYpfDPNbAQ4xwykdQcE23w5y5cpRr9iO3ShqUkVP1FE0C0U0oJf/8BGQuOm3XVgAciAD7/mFksvBZU6jpIdjGMj0PGJqzY6i118oDsBD7wveodYOdYqRA3Y5FqXH+fCFSmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GyKqwygtGsE4qSrFPliY7ncBXi+c2UzL9Gwyvrui5b0=; b=zZ9T1mrCzgq/i4WU2yaUN0RdF6KY0t885hjVeQQI1m/BrK7qWeQCmfSYIGSwSeICiVl5pCSFVeKM9SAqq4zcnBgsPRJ6t1vCgIa2vdPECWk/BgvM7RIIGOmyS3UxrtTJDybg2A+kOOhprICND3FCls6pHMJRim3x86X2wEbPi0s= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Jason Andryuk To: CC: Jason Andryuk , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , Teddy Astie , Grygorii Strashko , Alejandro Vallejo Subject: [PATCH] xen: Consolidate linker script setup data Date: Wed, 23 Sep 2026 12:19:35 -0400 Message-ID: <20260923161935.24429-1-jason.andryuk@amd.com> X-Mailer: git-send-email 2.55.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF00012E7D:EE_|IA0PPF64A94D5DF:EE_ X-MS-Office365-Filtering-Correlation-Id: 0f33177b-efb0-4fe3-ceee-08df198e7d9e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|7416014|1800799024|36860700016|82310400026|3023799007|10067099003|11063799006|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: nWZBVkfm6ZFBjzxzdEebu7bFtw6xTPeKtYeYynzB+OwZbRnsgBhg0YCRPwAN/85+fNznsEQruAfuXAl18pnUKnArAhZ+DcXzKqxETzPwBz50Wd7JOFIWYtIhXZ+5792YDTHM/gyWpYfcFcImG/etRuFpCAyMSQP6qvYAy4h9IdYvSRW06l+6+in32FkLuCarFwBTjIwzHe7/YwvgbgvsK034KDtja1S0yLr1UAMrroG0iw9bV94N/v+6uOJjuiPATpLdQIDU9/P6z3u4t9Raoq/WsTPsmI2v0p2rY/3XnHS7LVkwfOCvafUmNx9MjbvluOZ8W5MfKuDcmGo6nng4coLy0i0q+7FjMMRNr7ci8gjLjuqxjI4aVnE75k/9BcRCNGiIBdm7ZOGio6mfHzjNrGV1R8rbZKHOT7eEcNNOZFFVNwK5lJ261dzzpRB6SRC5eIuPx9RNn7PA46V+oLhcqxhRsmxfrgmOtQQs4cmJBguGqDuhir+d1F1EMD/EkNr7A7tpLowb7GDViOQ0sHY/clz9ryhNUSKr/W75ExnN8Mo2FlCLs42ieQ8KoFm3mAr6inLu2k6fa3zVJcUNBG5VDCE/B/WYabthMUxtO0YNYmPxRVMiP89D85INsBFKO0Cl6vEZag5eZFI7ShcKAuONDJZdx6ZGKNsD6pu3Y1wQatIqaENHy3k1FoJIkuEqmuhwOeH9vlaGlw3Wt1zBgFLWOQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(376014)(7416014)(1800799024)(36860700016)(82310400026)(3023799007)(10067099003)(11063799006)(56012099006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: YNaz/ZGMCRlmlbjHEXIwm8nDoizqTwBkFA2iHCNzEwhgTouG4qr5E4GAO/gq57OMdnSiSc3e4x9YWjS9yK18t+SWxCLrTi9f4Hv0fioyRJULX/usTE5ODdXqa7dBLB4B477hp6XYUBypX+TimZQB4a+qEdLfhR8LCb8KKRAOL75YzqtnO0RnzgfYHabsU3IYBZWmy83FqAshakb8WBpoGA4N40UtM1cLf3jt8mzX6/6L4EhD4T9WbNTzPbtd3DTNDFlvb0iWtmH0NZ2GDOQcw3eCqYBNgHsx1jmpSlNXp9wqeB9KZDTIdXdLhyb3o19bOKGnd2o5pq6Xzd0bRC1q+aoHOjI2/41NZNGvZELwtMvTvi69tj2ptKyHJU9Qb0ShAQ3l1hVT/jPsXDDpxVPZSSGqx6KeDugS//Ahgf0K1WQOERJkmVZ0lJlLE3qML2R+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2026 16:19:49.2118 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f33177b-efb0-4fe3-ceee-08df198e7d9e X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF00012E7D.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF64A94D5DF X-purgate-ID: tlsNG-ef75cf/1790180399-376D2AE4-EBF3D39B/0/0 X-purgate-type: clean X-purgate-size: 3960 .init.setup, .initcallpresmp.init, and .initcall1.init are duplicated across architectures. Replace them with a common define, SETUP_DATA. Suggested-by: Grygorii Strashko Signed-off-by: Jason Andryuk Reviewed-by: Alejandro Vallejo Reviewed-by: Jan Beulich --- Alejandro reviewed internally. Jan reviewed off list. --- xen/arch/arm/xen.lds.S | 11 +---------- xen/arch/ppc/xen.lds.S | 12 +----------- xen/arch/riscv/xen.lds.S | 12 +----------- xen/arch/x86/xen.lds.S | 11 +---------- xen/include/xen/xen.lds.h | 12 ++++++++++++ 5 files changed, 16 insertions(+), 42 deletions(-) diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S index d4d9594033..32afbfe131 100644 --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -135,16 +135,7 @@ SECTIONS *(.init.rodata) *(.init.rodata.*) - . = ALIGN(POINTER_ALIGN); - __setup_start = .; - *(.init.setup) - __setup_end = .; - - __initcall_start = .; - *(.initcallpresmp.init) - __presmp_initcall_end = .; - *(.initcall1.init) - __initcall_end = .; + SETUP_DATA . = ALIGN(4); __alt_instructions = .; diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S index d0f2ed43f1..37256c8865 100644 --- a/xen/arch/ppc/xen.lds.S +++ b/xen/arch/ppc/xen.lds.S @@ -107,17 +107,7 @@ SECTIONS *(.init.rodata) *(.init.rodata.*) - . = ALIGN(POINTER_ALIGN); - __setup_start = .; - *(.init.setup) - __setup_end = .; - - __initcall_start = .; - *(.initcallpresmp.init) - __presmp_initcall_end = .; - *(.initcall1.init) - __initcall_end = .; - + SETUP_DATA LOCK_PROFILE_DATA *(.init.data) diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S index 70db658fef..d9375a9616 100644 --- a/xen/arch/riscv/xen.lds.S +++ b/xen/arch/riscv/xen.lds.S @@ -114,17 +114,7 @@ SECTIONS *(.init.rodata) *(.init.rodata.*) - . = ALIGN(POINTER_ALIGN); - __setup_start = .; - *(.init.setup) - __setup_end = .; - - __initcall_start = .; - *(.initcallpresmp.init) - __presmp_initcall_end = .; - *(.initcall1.init) - __initcall_end = .; - + SETUP_DATA LOCK_PROFILE_DATA *(.init.data) diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index b9e888e596..8f943e11ea 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -223,16 +223,7 @@ SECTIONS *(.init.rodata) *(.init.rodata.*) - . = ALIGN(POINTER_ALIGN); - __setup_start = .; - *(.init.setup) - __setup_end = .; - - __initcall_start = .; - *(.initcallpresmp.init) - __presmp_initcall_end = .; - *(.initcall1.init) - __initcall_end = .; + SETUP_DATA *(.init.data) *(.init.data.rel) diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h index ea11e3fb62..958f8256b0 100644 --- a/xen/include/xen/xen.lds.h +++ b/xen/include/xen/xen.lds.h @@ -179,6 +179,18 @@ *(.data.schedulers) \ __end_schedulers_array = .; +#define SETUP_DATA \ + . = ALIGN(POINTER_ALIGN); \ + __setup_start = .; \ + *(.init.setup) \ + __setup_end = .; \ + \ + __initcall_start = .; \ + *(.initcallpresmp.init) \ + __presmp_initcall_end = .; \ + *(.initcall1.init) \ + __initcall_end = .; + #ifdef CONFIG_HYPFS #define HYPFS_PARAM \ . = ALIGN(POINTER_ALIGN); \ -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Wed Sep 23 16:22:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 16:22:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431053.1653448 (Exim 4.92) (envelope-from ) id 1x9PjP-0001IR-7M; Wed, 23 Sep 2026 16:22:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431053.1653448; Wed, 23 Sep 2026 16:22:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9PjP-0001IK-4J; Wed, 23 Sep 2026 16:22:03 +0000 Received: by outflank-mailman (input) for mailman id 1431053; Wed, 23 Sep 2026 16:22:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9PjO-0001I9-0l for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 16:22:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9PjN-00BtLb-EC for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:22:01 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab3fc93-2eae-0a2a0a5409dd-0a2a4509af46-48 for ; Wed, 23 Sep 2026 18:22:01 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab3fca9-be1a-0a2a45090019-b9ff1c239c43-3 for ; Wed, 23 Sep 2026 18:22:01 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0cf12e28600072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 23 Sep 2026 16:21:56 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id B258481ECA; Wed, 23 Sep 2026 18:21:55 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=To9O2iM9Heyz3znzNq+AlKoXHZA9T84qK9B47cWcyB0=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=B4LQ5hy5dec1ztd/C1OC9Gba63pja6Qbjc6OsJ9/btdpp/oXzrNWwxdhj06QcPwhahB7SsASm Y0irPSynlHwAP+zvxTqVfLLMJ1LTNh9IGVp0bj9deNBgfzreiAYYGMpP0zFJUrX9YxNeml9RLB8 fX8E9x/tqJdPfme8WYlgtDqt1iwLMQx/gOZoNxkRCbQM6fvC/IGzGMrkMoOoNiahDgh3BR+AFZG t72w042PF9Q8EG/CFpuePy3BxntzgkT/5a/l+zh+EVGU2YrMWNZczZvI8J6gN7Xxz8n7QDhirvH Ooxg4w+Fh/TZcCHG81/TRJ0x7iXueOAIOdup1JvVq2WA== X-Zone-Loop: c607fbfa0904ca11e59337c2d45a70e40e9d735df6db x-campaign-type: default x-transaction-id: baf4214c-90e9-44c6-8311-a0819fe608ad x-swg-uid: 01-e43c8c51-ebda-43db-a7cd-dce7a70d036f X-Mailer: Sweego Message-ID: <1790180516.8631fc262581453bbf619ec5b2062170.1a0cf12e28600072c4@vates.tech> x-swg-bid: 1790180516.8631fc262581453bbf619ec5b2062170.1a0cf12e28600072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 34/39] xen/riscv: restore register state in the new IMSIC VS-file From: Baptiste Le Duc To: Oleksii Kurochko Cc: Baptiste Le Duc , xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <5798db51-1f8a-4ac2-b2e1-57ca07361479@gmail.com> References: <1790178185.8631fc262581453bbf619ec5b2062170.1a0ceef50f800072c4@vates.tech> <5798db51-1f8a-4ac2-b2e1-57ca07361479@gmail.com> Date: Wed, 23 Sep 2026 18:21:50 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790180510; l=4848; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=yIfxY7xHeNtTNnQ4ZsaWL01gfKbXrRlTdV61o8T4cjA=; b=h48AyKDf/4KLGognhM/LZItkfwtt0zIscwpAwU08Uc+p4bAacoS3JqmzVRoEuEP+LcSljDC3Q lJjK3p328eUCRl+rbot61iyKrHOuktC+lOMWT5UAeYOySozZZa5Oo37 X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790180515945 X-purgate-ID: tlsNG-bad1c0/1790180521-3B8D1034-34A32947/10/73395122804 X-purgate-type: spam X-purgate-size: 4852 On 2026-09-23 18:08 +0200, Oleksii Kurochko wrote: > > > On 9/23/26 5:42 PM, Baptiste Le Duc wrote: > >> At this point, all interrupt producers have been moved to the new > >> IMSIC VS-file so we move register state from the old IMSIC VS/SW-file > >> to the new IMSIC VS-file. > >> > >> As new IMSIC VS-file is ready to be used update vCPU's hstatus with > >> new VGEIN. > >> > >> As the whole migration procedure is finished add some extra explanatory > >> comments. > >> > >> Signed-off-by: Oleksii Kurochko > >> > >> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > >> index 3cba58e0c1..d7b137a1f5 100644 > >> --- a/xen/arch/riscv/imsic.c > >> +++ b/xen/arch/riscv/imsic.c > >> @@ -112,6 +112,12 @@ do { \ > >> r_; \ > >> }) > >> > >> +#define imsic_vs_csr_set(c, v) \ > >> +do { \ > >> + csr_write(CSR_VSISELECT, (c)); \ > >> + csr_set(CSR_VSIREG, (v)); \ > >> +} while ( 0 ) > >> + > >> #define imsic_vs_csr_write(c, v) \ > >> do { \ > >> csr_write(CSR_VSISELECT, (c)); \ > >> @@ -185,6 +191,19 @@ static void imsic_eix_write(unsigned int ireg, unsigned long val) > >> } > >> } > >> > >> +static void imsic_eix_set(unsigned int ireg, unsigned long val) > >> +{ > >> + switch ( ireg ) > >> + { > >> + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIP0, > >> + imsic_vs_csr_set, val) > >> + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIE0, > >> + imsic_vs_csr_set, val) > >> + default: > >> + ASSERT_UNREACHABLE(); > >> + } > >> +} > >> + > >> unsigned int vcpu_guest_file_id(const struct vcpu *v) > >> { > >> return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); > >> @@ -630,13 +649,13 @@ static void cf_check imsic_vsfile_local_read_clear(void *data) > >> old_vsiselect = csr_read(CSR_VSISELECT); > >> old_hstatus = csr_read(CSR_HSTATUS); > >> new_hstatus = old_hstatus & ~HSTATUS_VGEIN; > >> - new_hstatus |= ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT; > >> + new_hstatus |= MASK_INSR(idata->hgei, HSTATUS_VGEIN); > > > > > >> csr_write(CSR_HSTATUS, new_hstatus); > >> > >> /* > >> - * There is no need to use atomic functions version to store > >> - * values in MRIF because imsic_vsfile_read_clear() is always called > >> - * with pointer to temporary MRIF on stack. > >> + * No atomic accessors are needed to store the values into the MRIF here, > >> + * as imsic_vsfile_read_clear() is always called with a pointer to a > >> + * temporary MRIF on the stack. > >> */ > > > > > >> > >> mrif->eidelivery = imsic_vs_csr_swap(IMSIC_EIDELIVERY, 0); > >> @@ -972,6 +991,49 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, > >> return fdt_end_node(fdt); > >> } > >> > >> +static void cf_check imsic_vsfile_local_update(void *data) > >> +{ > >> + unsigned int i; > >> + struct imsic_mrif_eix *eix; > >> + const struct imsic_vsfile_data *idata = data; > >> + struct imsic_mrif *mrif = idata->mrif; > >> + unsigned long new_hstatus, old_hstatus, old_vsiselect; > >> + > >> + /* We can only update if we have a HW IMSIC context */ > >> + if ( !idata->hgei ) > >> + return; > >> + > >> + /* > >> + * No atomic accessors are needed to read the values out of the MRIF here, > >> + * as this is always called with a pointer to a temporary MRIF on the > >> + * stack. > >> + */ > > idata->mrif may point anywhere, so what the comment really states is a > > requirement on callers. It also only makes full sense next to KVM, where > > a shared SW-file MRIF is accessed atomically; Xen has neither of those > > (yet). Either explicitely explain that callers must declare mrif on > > their stack or move the comment directly in call sites. > > It is mentioned in the comment "is always called with a pointer to a > temporary MRIF on the stack.". Oh okay, I think I misunderstood the comment at the first place then. I thought you wanted to say the pointer itself is on the stack, not MRIF. Now it's more clear. > > With SW-file MRIF I expect that atomic operations should be used so this > functions shouldn't just use for them and I assume KVM has something > different function to work with SW-file MRIF. Anyway just mentioning KVM > code isn't always useful as it forces me to go and investigate what is > going on there what I am not fully convinced that it is okay... Yes sorry, no needs for more investigations here. > > ~ Oleksii > > > > From xen-devel-bounces@lists.xenproject.org Wed Sep 23 17:56:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 17:56:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431172.1653458 (Exim 4.92) (envelope-from ) id 1x9RCE-0006dt-NJ; Wed, 23 Sep 2026 17:55:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431172.1653458; Wed, 23 Sep 2026 17:55:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9RCE-0006dm-Kf; Wed, 23 Sep 2026 17:55:54 +0000 Received: by outflank-mailman (input) for mailman id 1431172; Wed, 23 Sep 2026 17:55:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9RCC-0006dg-V8 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 17:55:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9RCC-002r9J-7k for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 19:55:52 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab41282-bab6-0a2a0a5309dd-0a2a4504eaac-18 for ; Wed, 23 Sep 2026 19:55:52 +0200 Received: from [52.101.65.98] (helo=DU2PR03CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab412a2-b57f-0a2a45040019-346541626d1a-3 for ; Wed, 23 Sep 2026 19:55:47 +0200 Received: from DB5PR03MB10049.eurprd03.prod.outlook.com (2603:10a6:10:4a0::9) by VI0PR03MB10736.eurprd03.prod.outlook.com (2603:10a6:800:263::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Wed, 23 Sep 2026 17:55:41 +0000 Received: from DB5PR03MB10049.eurprd03.prod.outlook.com ([fe80::9240:92cd:d9da:bf9e]) by DB5PR03MB10049.eurprd03.prod.outlook.com ([fe80::9240:92cd:d9da:bf9e%5]) with mapi id 15.21.0428.015; Wed, 23 Sep 2026 17:55:41 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r4gzn8tmFUJpEmbiBTggocQNjGwngnxnUFg9iKHkuI5vADL5JWwPxQLKOZQ9BiqTHf1tiDnwN8qqS43Oq22xaekVS06fSjGtiMqPLw9/rS6o/PAc8g8LSkvQfWEdpvEME8DkuePDkhA1TeEwq5dzk98bLGZybMtEmGnBNEhUfdA7Qas1aaVoKWxNjBN8bTxTgJrRx1S9fkiO8F4Uh+qGyxA4P6c9aKdHkeYAQe+ZF19pNCNf/UDzpTSJeOTtOVo54fX5YvxATCo9JXVxn0bLzAvjVfHPatJi7lhKIk4BwKoNxQLdfuH/PG1DulcbyfXP/a3MTaS9NfVJ1YXoV1W9Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A4eO5jtFys8ChYYe95arSsDNkuvTyJBoxL0bZ27ksLQ=; b=NTLhesK+UnxMUpx/N+iOhOw2G0DzCMAWJ3W5xXdrQFBXogoUk+0sru5IhfjCGW/AywnqJvOdavrXwhl6CSxOKQHEu1rr33FgHJeMtHIkMwb7JvvV20QhS8Nnq8I+3apNWmFg/CuF7CJ28ANUqBqFO3sVWA1p+tQ1DNu0mYaEsvaPLKaEaqlEHKYlZCj7ka+KXWSv/UHbWqcn1CIAjuNXH3Z5z6eweCiHNCakMia1ryXmuEOUa5ITKpg+hu+NLK44jshsBcybcKnRBcW9b+E7t2xS9kNUzQtFuxQXCVJhIEdJQMJgznASIK7DzFPDeVdZtDVGT4OkURjdVtSch7FZpw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A4eO5jtFys8ChYYe95arSsDNkuvTyJBoxL0bZ27ksLQ=; b=sa3sdOjMCdozgMlDICH/T7vP9+eJQTBGAM/Pr6EuobjwMeUvTz67791XIZo3YcJijxTFmAk8hr/F6a3vmXD1artTu12jmX5GCwcoRcvA6m70SkrP7cUmkyJWMLJGyAnyYHz06RAxG91HyvpYnCbb4pbs2EEkILi/wODziJc8jorWZV1+JEIWHdA29j6xSXe2z6eI/uC/kRP7+QsRn/i6CBEiQYCHV3Z4/CK8fxd5ZE77XovJfS3kRxF8HIMGROTKt4LLkkUyhWpIoHmu4Zv9eZMLrRTlXQGLqJl157Kwgmrn8CUja7bXlEPIkccFyCfSzTh0Qr7QBW/FcgJGPjlW3w== From: Leonid Komarianskyi To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Julien Grall Subject: Re: [PATCH v2] xen/arm: gicv3: initialize eSPI unconditionally Thread-Topic: [PATCH v2] xen/arm: gicv3: initialize eSPI unconditionally Thread-Index: AQHdSsRkuuRG4YXur0mlXN3LfWLvYrbbzq2AgAClRwA= Date: Wed, 23 Sep 2026 17:55:41 +0000 Message-ID: References: <13181424f9be3f5e31977fbd505209cd0508571b.1790102501.git.leonid_komarianskyi@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DB5PR03MB10049:EE_|VI0PR03MB10736:EE_ x-ms-office365-filtering-correlation-id: 023634e7-3df9-42c9-197d-08df199be239 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|38070700021|5023799004|4133799003|11063799006|6133799003|10067099003|56012099006|4143699003|22082099003|18002099003; x-microsoft-antispam-message-info: DQ2jZU/2PPy8K8EkYcInVRN/y6iKtTlipMuyF/kds8n2U75ZsdcrwBQfHLgHaMARK/aD4I/NU7T5hcSlpFhVHp+4q1yX1ONsuvmkAL6lmT12SGkVamtAIwtnMYUNPoBpi+Y2GPa3j4CeOzfNRpSXd3SXRnBtZnp+Ma+Czdw1LOSHTGQq/5pT+NaMYBPEWjaXVRXL1mjlWcAxLXG1mYOQC66wruCAkA+ek1H/YRW2kKKGeix0ptH7G45F43KOhmoM9PGzSrdYisbpgjhOe+IhIFUUvOi7PjECzHkzmRj7fg2UGkNrhSg2AcsqAsLR3qeUj+XZN7st2njDU6f7bWelEPUekQ35F1zeuV48hRwvKckYgvmwNUAdqyzuicKZTKuZi1VlD8iDFF3bPSP3kGHjf2Tz0/DsyOoFeMFK2u67NZoaBAKF/kehFqnM1a5+YoXZ2eG256lXoUf4Tq5N+gyRiF9M8dNatS6zkiB9eRF2Ic/BsjvrHkdsd7JXrpy/AzJbHr0WP6mKiU0TS0arqDRC5158lJibW+1PId5vvmrwBHGhY6DwZdkQOqFW/YN3m4OM3F0hjipYXxOw61E6AKO2ni1mPMI2eJlpB9qCBihiQYFFOqLSc+rj50nQZxaLg76wEy7qXKRVshF3WK6HKBlomYn9eT7+5f3ZtY6C7PoaVvJmYx8Kw3pdj/GVSEDEcBSa x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB5PR03MB10049.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(38070700021)(5023799004)(4133799003)(11063799006)(6133799003)(10067099003)(56012099006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cVRaa3RyWDZycTJIM3gvdVlrM3FaQkNZUG12QW1sbzJwSlFHM3JrRVBtanJT?= =?utf-8?B?azhBcVlkcmliTzNvS243eG92dkhuUkViT2cxUjBYY1pvN0hOVUlrczdPSjBu?= =?utf-8?B?bG03Z2w2V0JaU0VKYnROcHFybUVNd1VySkU3MEdsOWtMRHlDS1BNMldWbjl5?= =?utf-8?B?N0h5OHpwOURLT1hiNWYzQnQvYUptS3VSQnRGeVFYRTlYOWZSbjIrakNkYWtU?= =?utf-8?B?ZGZWYWs4azltRTZ0K3o2dWx2RVFFTC9xY0dOMjV6QXNwYXFlOFFDdVlwOEU1?= =?utf-8?B?ZW1sT2I5YVlwNjJJVGVJM1pFOCtpY3BLaXJHSjl4bFlha1l4V3J4c2FGUDRI?= =?utf-8?B?S29UNE5VMUcwRVdDZzIvQWs3Q2FIUktvbnVNT2p3djhRdGJxbG92czJyeWE3?= =?utf-8?B?TjJtKy9xMDF3T045OFUwcUxVM3p2bnYrRTNLSGUrUXM2dHhNMis4RDc0UFVW?= =?utf-8?B?ekFLb09pREJXaUxKNEtCSlVFMlErblFYQmg2TDh4YklPcnVnM2Z1MlpHUTBu?= =?utf-8?B?dVR0SG5ZVG1Nb3EwYmdnZ1hMNHpaamczbEVLWEtOdFN3ZzNlMGR3OVVzdzlG?= =?utf-8?B?TE5pdnlxMTltTG5NSkc0MWxlZlZiNUdDSlFrSlkrS242UHJRNnVzNWVFRmlF?= =?utf-8?B?YlFUZ2F5SUZXalh6Tytwc2wwTG1HQ1ovejVBeWhkcUJiZ3p1bUp1TkZrSnFP?= =?utf-8?B?aVZtZ3hPUTV4NldWZ2d0STdBQS9uMFhyNVBCamgybjdVRHJGcnBVR3M2L29a?= =?utf-8?B?WGE3N1lneWpVVi9NSGV1S2F1SER6QXhCcVFVdG1SVDYyNzdxMDMzd05EZHZB?= =?utf-8?B?cm9WVzV4MDdTOVpxYXVYa2dPTXUzMm9pS0I0MEFBdjZXOTVxSi85Wi9QWWYy?= =?utf-8?B?cThhamt1T2dJenFPYkJkWmxXV3o0dEs3YlRnd3FhajhnYUNEUmQrV1hXdHVS?= =?utf-8?B?VTJtQTBRT1M4b1d2Q29STUJaSERXeDNSUjZXcEpKOHFVcVZMc085QmMxSEI0?= =?utf-8?B?VDhEcVNkNFpJUzkwS2VJWHNZTnhOaVdCQWpaajhzbEdwMEY3V3RIaU4rYXFr?= =?utf-8?B?UEFOUExNV0s5ai9xRUhJbVg4WW4xRzFKOGxFNXdlNElBSmZYM3RJcFlMc1BX?= =?utf-8?B?NUNTYi9DZnZUSGR1cGxXSEhkTEJhdmd3SkNDUlYxblNXNytsSHNwYWoybDAx?= =?utf-8?B?ZndtT3dHcGtzcC93ZzJnOVE4dGhIOC9BOVpZb0xFTTBCanl0ei91cVQwOW8y?= =?utf-8?B?MktCUFc3MmJUaHJrY0FEUGFTM3U5bnpHM2J0TWtTUVJDQmUvN284dytuZkRS?= =?utf-8?B?TTVyL3RRd0IzaWdWSFdRTjhFdVF4d2t3bDdvUjg5ZDE5aUlvdlg1ZWVGNDls?= =?utf-8?B?U0RrOVUvQTMzZDhBWEE1azF6NXdOZW5qSlRBdkliTldWdXZxK09BR0tmc0pO?= =?utf-8?B?MldNYzk1SkxYQXQrZ0FmVy9ZeFpKQ295dUxzeE5HM1VBWjFyeURsakpHdGI0?= =?utf-8?B?aXF6alhuTmNXZXFWajlqZTNpVEF0T2tocXpTUzRUSE1IMDkxUzhwVzQ2TStz?= =?utf-8?B?THNVWSsrR1U1UkFIaDJzcHBxYUZwMWdHRzFPWG92eHlqdHhFV2psSG9YdHR6?= =?utf-8?B?UTd5cGhlUUFQVE1IdGNFTThLZEV3by9FTGs4SGJEcGZucFM0NFloTmh6NkJ6?= =?utf-8?B?N1ZBdndLSEwyVXRHQlpZNHlGRDJlNmRkQXZ5ZFgxd0MwZlBra1dacG5FUjA4?= =?utf-8?B?WTFnaVRqSERrRlllYU1MeTYzQXJkSWFuaFo4WmZEK0NNbCtabGJnY1dSNWlP?= =?utf-8?B?SlZhaGtCQUVXZ20rVUhqb01tN25uSitNR2tkUzZSY3pXU1FyZVRZQW5kTVJU?= =?utf-8?B?YmxkNStxZjRiWldDa1BVbkVLYlMwNFFXMkwrWmI1NWJUZDYrcUZmNzdEUzFk?= =?utf-8?B?dVJVdElGRkVudTFUdExrT2RLWDZ4Z2VZNDdwSytuK2hSS2dHeXExWDRYWUdx?= =?utf-8?B?cFJrWDloK0ZheUZ6UHJBRXJSbHNDRFRpSVpZa2FsMmlrZTBHbCs3bmNDU3Bu?= =?utf-8?B?ZGhSMmhJQ05kSnpnbE1QUTl0cjhidEpzbjE2Z056blREZkQwU1lhQjJMWTJ2?= =?utf-8?B?djZFTndPcHJSRk94UUpyMWhKckhEdmIyTCtHYTBTL0lJRittQ050L3dNRTA2?= =?utf-8?B?allkeHpkb3lON0dlYnNrUDRWbS9DMnBBZ2Q0Q01tY3J2cWRpcUZidk42OTNN?= =?utf-8?B?Q250MEdQQ2I3YlNVRmQrWXpzVkg5eERJNUpsbHZhMzQ4Ym1mZE1JWXdreFNa?= =?utf-8?B?NVJNZUNqZEJvUUlMQStHNTNzYWdVMjljb1p2Y0JBRXU3VzdyWUNHNHJtZE93?= =?utf-8?Q?w+pyz7Oqz9JfP3tg=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <8915C3B5D1BE604A90DC0A9AC79C6834@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB5PR03MB10049.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 023634e7-3df9-42c9-197d-08df199be239 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2026 17:55:41.4864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5h+5B58/80ut2PVWMrjAddrZvPu6K2wRwGIFk3ihEXJc6YVStPss894iCZZXhyoyw1GT06tLPQX141MQLiSiwEyu3k8gjRDgcEeywiw/tsg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB10736 X-purgate-ID: tlsNG-ebf023/1790186152-C10DDB50-B3A15848/0/0 X-purgate-type: clean X-purgate-size: 7554 SGVsbG8gTXlrb2xhLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQpPbiA5LzIzLzI2 IDExOjA0LCBNeWtvbGEgS3ZhY2ggd3JvdGU6DQo+IEhpIExlb25pZCwNCj4NCj4gVGhhbmsgeW91 IGZvciB0aGUgcGF0Y2guDQo+DQo+IE9uIFR1ZSwgU2VwIDIyLCAyMDI2IGF0IDk6NTnigK9QTSBM ZW9uaWQgS29tYXJpYW5za3lpDQo+IDxMZW9uaWRfS29tYXJpYW5za3lpQGVwYW0uY29tPiB3cm90 ZToNCj4+DQo+PiBTaW5jZSB0aGUgZmlybXdhcmUgbWF5IGluaXRpYWxpemUgZVNQSXMgYmVmb3Jl IFhlbiwgYW5kIHdpdGhvdXQNCj4+IENPTkZJR19HSUNWM19FU1BJIGVuYWJsZWQsIFhlbiB3b3Vs ZCBub3QgcmVpbml0aWFsaXplIHRoZW0gcHJvcGVybHkNCj4+IGR1cmluZyBib290LiBJbiBzdWNo IGNhc2VzLCBvbmNlIHRoZSBHSUMgaXMgcmUtZW5hYmxlZCBpbiBYZW4sDQo+PiBpbnRlcnJ1cHRz IG1heSBiZSByZWNlaXZlZCB0aGF0IGNhbm5vdCBiZSBoYW5kbGVkLg0KPj4NCj4+IFRvIGVuc3Vy ZSBwcm9wZXIgb3BlcmF0aW9uIG9uIGhhcmR3YXJlIHdpdGggZVNQSSBmZWF0dXJlLCBldmVuIHdo ZW4gdGhlIGVTUEkNCj4+IGNvbmZpZyBpcyBkaXNhYmxlZCwgZ2ljdjNfZGlzdF9lc3BpX2NvbW1v bl9pbml0KCkgc2hvdWxkIGJlIGludm9rZWQNCj4+IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBDT05G SUdfR0lDVjNfRVNQSSBpcyBlbmFibGVkIG9yIG5vdC4gVGhpcyB3aWxsIG5vdA0KPj4gYWZmZWN0 IGhhcmR3YXJlIHdpdGhvdXQgZVNQSSBzdXBwb3J0LCBhcyB0aGUgZnVuY3Rpb24gY2hlY2tzIGlm IHRoZQ0KPj4gaGFyZHdhcmUgc3VwcG9ydHMgZVNQSXMgYnkgcmVhZGluZyB0aGUgR0lDRF9UWVBF Ui5FU1BJIGZpZWxkICh1c2luZw0KPj4gR0lDRF9UWVBFUl9FU1BJU19OVU0gbWFjcm8pLCB3aGlj aCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgZXh0ZW5kZWQgU1BJDQo+PiByYW5nZSBpcyBzdXBwb3J0 ZWQuIElmIHRoZSBoYXJkd2FyZSBkb2VzIG5vdCBzdXBwb3J0IGVTUEksIHRoZSBmdW5jdGlvbg0K Pj4gd2lsbCBub3QgcGVyZm9ybSBhbnkgYWN0aW9ucy4NCj4+DQo+PiBUaGVyZSBhcmUgbm8gZnVu Y3Rpb25hbCBjaGFuZ2VzIGZvciBzZXR1cHMgd2hlcmUgQ09ORklHX0dJQ1YzX0VTUEk9eS4NCj4+ DQo+PiBTdWdnZXN0ZWQtYnk6IEp1bGllbiBHcmFsbCA8amdyYWxsQGFtYXpvbi5jb20+DQo+PiBT aWduZWQtb2ZmLWJ5OiBMZW9uaWQgS29tYXJpYW5za3lpIDxsZW9uaWRfa29tYXJpYW5za3lpQGVw YW0uY29tPg0KPj4gQWNrZWQtYnk6IEp1bGllbiBHcmFsbCA8amdyYWxsQGFtYXpvbi5jb20+DQo+ PiAtLS0NCj4+IENoYW5nZXMgaW4gdjI6DQo+PiAtIHJlYmFzZWQgb24gdGhlIGN1cnJlbnQgc3Rh Z2luZw0KPj4gLSBwbGFjZWQgU3VnZ2VzdGVkLWJ5IHRhZyBmaXJzdCB0byBrZWVwIHRhZ3MgaW4g Y2hyb25vbG9naWNhbCBvcmRlcg0KPj4gLSBhZGRlZCBBY2tlZC1ieSBmcm9tIEp1bGllbiBHcmFs bA0KPj4NCj4+IFRoaXMgaXMgYSBmb2xsb3ctdXAgcGF0Y2ggcmVsYXRlZCB0byB0aGUgZGlzY3Vz c2lvbjoNCj4+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC84MjA3MDRkMC00MDQ3 LTRmMDItYTA1OC0wMWRhYmEyNzY1ZjFAeGVuLm9yZy8NCj4+DQo+PiBTZW5kaW5nIHYyIHdpdGgg dGhlIHJlcXVlc3RlZCBjaGFuZ2VzLCBhcyBJIG9ubHkgbm93IG5vdGljZWQNCj4+IHRoYXQgdGhp cyBwYXRjaCBoYXMgbm90IGJlZW4gbWVyZ2VkIHlldC4NCj4+IC0tLQ0KPj4gICB4ZW4vYXJjaC9h cm0vZ2ljLXYzLmMgICAgICAgICAgICAgICAgICB8IDMyICsrKysrKysrKysrKysrLS0tLS0tLS0t LS0tDQo+PiAgIHhlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9naWNfdjNfZGVmcy5oIHwgIDIgLS0N Cj4+ICAgMiBmaWxlcyBjaGFuZ2VkLCAxNyBpbnNlcnRpb25zKCspLCAxNyBkZWxldGlvbnMoLSkN Cj4+DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2dpYy12My5jIGIveGVuL2FyY2gvYXJt L2dpYy12My5jDQo+PiBpbmRleCBhY2RhYzIyOTUzLi40NjM3NjlkNzdiIDEwMDY0NA0KPj4gLS0t IGEveGVuL2FyY2gvYXJtL2dpYy12My5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZ2ljLXYzLmMN Cj4+IEBAIC03MDMsMTcgKzcwMywzMiBAQCB1bnNpZ25lZCBpbnQgZ2ljX251bWJlcl9lc3Bpcyh2 b2lkKQ0KPj4gICAgICAgcmV0dXJuIGdpY19od19vcHMtPmluZm8tPm5yX2VzcGk7DQo+PiAgIH0N Cj4+DQo+PiArc3RhdGljIHZvaWQgX19pbml0IGdpY3YzX2Rpc3RfZXNwaV9pbml0X2FmZih1aW50 NjRfdCBhZmZpbml0eSkNCj4+ICt7DQo+PiArICAgIHVuc2lnbmVkIGludCBpOw0KPj4gKw0KPj4g KyAgICBmb3IgKCBpID0gMDsgaSA8IGdpY3YzX2luZm8ubnJfZXNwaTsgaSsrICkNCj4+ICsgICAg ICAgIHdyaXRlcV9yZWxheGVkX25vbl9hdG9taWMoYWZmaW5pdHksIEdJQ0QgKyBHSUNEX0lST1VU RVJuRSArIGkgKiA4KTsNCj4+ICt9DQo+PiArI2Vsc2UNCj4+ICsNCj4+ICtzdGF0aWMgdm9pZCBf X2luaXQgZ2ljdjNfZGlzdF9lc3BpX2luaXRfYWZmKHVpbnQ2NF90IGFmZmluaXR5KSB7IH0NCj4+ ICsjZW5kaWYNCj4+ICsNCj4+ICAgc3RhdGljIHZvaWQgX19pbml0IGdpY3YzX2Rpc3RfZXNwaV9j b21tb25faW5pdCh1aW50MzJfdCB0eXBlKQ0KPg0KPiBJIHRoaW5rIHRoZSBvcmRlcmluZyBpbiBn aWN2M19kaXN0X2VzcGlfY29tbW9uX2luaXQoKSBuZWVkcyB0byBiZQ0KPiByZXZpc2l0ZWQgbm93 IHRoYXQgdGhpcyBmdW5jdGlvbiBpcyBhbHNvIGNhbGxlZCB3aXRoDQo+IENPTkZJR19HSUNWM19F U1BJPW4uDQo+DQo+IFRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHBhdGNoIGlzIHRoYXQgZmlybXdh cmUgbWF5IGhhdmUgbGVmdCBhbiBlU1BJDQo+IGVuYWJsZWQuIEhvd2V2ZXIsIHdlIGN1cnJlbnRs eSBwcm9ncmFtIEdJQ0RfSUNGR1JuRSBiZWZvcmUgY2xlYXJpbmcNCj4gdGhlIGNvcnJlc3BvbmRp bmcgZW5hYmxlIGJpdCBpbiBHSUNEX0lDRU5BQkxFUm5FLg0KPg0KPiBUaGUgR0lDIGFyY2hpdGVj dHVyZSByZXF1aXJlcyBhbiBpbnRlcnJ1cHQgdG8gYmUgaW5kaXZpZHVhbGx5IGRpc2FibGVkDQo+ IGJlZm9yZSBjaGFuZ2luZyBJbnRfY29uZmlnOyBvdGhlcndpc2UgdGhlIGJlaGF2aW9yIGlzIFVO UFJFRElDVEFCTEUuDQo+IFNlZSBBcm0gSUhJIDAwNjlILmIsIHNlY3Rpb24gMTIuOS45IChHSUNE X0lDRkdSPG4+KS4NCj4NCg0KU2VjdGlvbiAxMi45LjkgZGVzY3JpYmVzIEdJQ0RfSUNGR1I8bj4s IGkuZS4gdGhlIHJlZ3VsYXIgU1BJIHJhbmdlLCBhbmQNCml0IGluZGVlZCBjb250YWlucyB0aGlz IHJlcXVpcmVtZW50LiBIb3dldmVyLCB0aGUgY29kZSBpbg0KZ2ljdjNfZGlzdF9lc3BpX2NvbW1v bl9pbml0KCkgcHJvZ3JhbXMgR0lDRF9JQ0ZHUjxuPkUsIHdoaWNoIGlzDQpkZXNjcmliZWQgaW4g MTIuOS4xMCwgYW5kIEkgY291bGQgbm90IGZpbmQgYW4gZXF1aXZhbGVudCByZXF1aXJlbWVudCB0 aGVyZS4NCg0KVGhlIG9ubHkgcmVsYXRlZCBydWxlIEkgZm91bmQgdGhhdCBhbHNvIGNvdmVycyB0 aGUgZXh0ZW5kZWQgU1BJIHJhbmdlIGlzDQppbiBBcm0gSUhJIDAwNjlILmIgc2VjdGlvbiA0LjU6 DQoNCiJDaGFuZ2luZyB0aGUgY29uZmlndXJhdGlvbiBvZiBhbiBpbnRlcnJ1cHQgZnJvbSBsZXZl bC1zZW5zaXRpdmUgdG8NCmVkZ2UtdHJpZ2dlcmVkLCBvciBmcm9tIGVkZ2UtdHJpZ2dlcmVkIHRv IGxldmVsLXNlbnNpdGl2ZSwgd2hlbiB0aGVyZSBpcw0KYSBwZW5kaW5nIGludGVycnVwdCwgbGVh dmVzIHRoZSBpbnRlcnJ1cHQgaW4gYW4gVU5LTk9XTiBzdGF0ZS4iDQoNClRoYXQgcnVsZSBpcyBh Ym91dCB0aGUgcGVuZGluZyBzdGF0ZSByYXRoZXIgdGhhbiB0aGUgZW5hYmxlIHN0YXRlLCB0aG91 Z2guDQoNCkFsc28sIHRoZSBjdXJyZW50IGVTUEkgaW5pdGlhbGl6YXRpb24gc2VxdWVuY2UgbWly cm9ycyB0aGUgb25lIHVzZWQgZm9yDQpyZWd1bGFyIFNQSXMgaW4gZ2ljdjNfZGlzdF9pbml0KCks IHdoZXJlIHRoZSByZXF1aXJlbWVudCBmcm9tIDEyLjkuOQ0KZG9lcyBhcHBseS4gU28gaWYgd2Ug ZGVjaWRlIHRvIHJlb3JkZXIgdGhlIGluaXRpYWxpemF0aW9uLCBJIHRoaW5rIGl0DQpzaG91bGQg YmUgZG9uZSBmb3IgcmVndWxhciBTUElzIGFzIHdlbGwsIGlkZWFsbHkgaW4gYSBzZXBhcmF0ZQ0K cHJlcGFyYXRvcnkgcGF0Y2guDQoNCj4gV2UgYWxzbyByZWx5IG9uIHRoZSBzYW1lIHJlcXVpcmVt ZW50IGluIGdpY19zZXRfaXJxX3R5cGUoKS4NCj4NCj4gU28gc2hvdWxkbid0IHdlIGRpc2FibGUv ZGVhY3RpdmF0ZSBhbGwgZVNQSXMgYmVmb3JlIHByb2dyYW1taW5nDQo+IEdJQ0RfSUNGR1JuRT8g TGludXggYWxzbyBpbml0aWFsaXplcyB0aGUgZXh0ZW5kZWQgU1BJIHJhbmdlIGluIHRoaXMNCj4g b3JkZXI6IElDRU5BQkxFUm5FL0lDQUNUSVZFUm5FIGZpcnN0LCBmb2xsb3dlZCBieSBJR1JPVVBS bkUsDQo+IElDRkdSbkUgYW5kIElQUklPUklUWVJuRS4NCj4NCj4gVGhpcyBpc3N1ZSBhbHJlYWR5 IHNlZW1zIHRvIGV4aXN0IGZvciB0aGUgQ09ORklHX0dJQ1YzX0VTUEk9eSBwYXRoLA0KPiBidXQg dGhpcyBwYXRjaCBtYWtlcyBpdCByZWxldmFudCB0byB0aGUgbmV3bHkgYWRkZWQgQ09ORklHPW4g cGF0aCwNCj4gd2hlcmUgYW4gZVNQSSBsZWZ0IGVuYWJsZWQgYnkgZmlybXdhcmUgaXMgcHJlY2lz ZWx5IHRoZSBjYXNlIHdlIGFyZQ0KPiB0cnlpbmcgdG8gaGFuZGxlLg0KPg0KPiBBbHNvLCB3ZSBj b3VsZCBkaXNhYmxlL2RlYWN0aXZhdGUgZVNQSXMgZm9yIGFsbCBidWlsZHMsIHdoaWxlIGtlZXBp bmcNCj4gdGhlIHJlc3Qgb2YgdGhlIGVTUEkgY29uZmlndXJhdGlvbiB1bmRlciBDT05GSUdfR0lD VjNfRVNQSS4gVGhpcyB3b3VsZA0KPiBhdm9pZCBhY2Nlc3NpbmcgdGhlIG90aGVyIGVTUEkgcmVn aXN0ZXJzIGluIGJ1aWxkcyB3aXRob3V0IGVTUEkNCj4gc3VwcG9ydCwgdW5sZXNzIHRoZXJlIGlz IGEgcGFydGljdWxhciByZWFzb24gdG8gaW5pdGlhbGl6ZSB0aGVtIHRoZXJlLg0KPg0KDQpUaGlz IGlzIGEgZmFpciBwb2ludCwgYnV0IEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGNsYXJpZnkgd2l0 aCB0aGUgQXJtDQptYWludGFpbmVycyBmaXJzdCB3aGV0aGVyIHRoZSBTUEkvZVNQSSBpbml0aWFs aXphdGlvbiBvcmRlciBzaG91bGQgYmUNCmNoYW5nZWQgaW4gYSBzZXBhcmF0ZSBwcmVwYXJhdG9y eSBwYXRjaCwgYXMgdGhlIGNvZGUgZm9yIHRoaXMgcGF0Y2gNCmRlcGVuZHMgb24gdGhlIGFuc3dl ci4gQXMgbWVudGlvbmVkIGFib3ZlLCBJIGNvdWxkIG5vdCBmaW5kIHN1Y2ggYQ0KcmVzdHJpY3Rp b24gZm9yIGVTUElzOyBpdCBhcHBsaWVzIG9ubHkgdG8gcmVndWxhciBTUElzLiBJZiB0aGUNCm1h aW50YWluZXJzIGFncmVlIHRvIGNoYW5nZSB0aGUgc2VxdWVuY2UgZm9yIGJvdGggU1BJcyBhbmQg ZVNQSXMsIEkgY2FuDQpwcmVwYXJlIGEgc2VwYXJhdGUgcGF0Y2ggYW5kIHVwZGF0ZSB0aGlzIHBh dGNoIGFjY29yZGluZ2x5Lg0KDQoNCkJlc3QgcmVnYXJkcywNCkxlb25pZC4NCg== From xen-devel-bounces@lists.xenproject.org Wed Sep 23 18:30:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 18:30:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431218.1653468 (Exim 4.92) (envelope-from ) id 1x9Rk1-0004Je-6r; Wed, 23 Sep 2026 18:30:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431218.1653468; Wed, 23 Sep 2026 18:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Rk1-0004JX-2g; Wed, 23 Sep 2026 18:30:49 +0000 Received: by outflank-mailman (input) for mailman id 1431218; Wed, 23 Sep 2026 18:30:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9Rk0-0004JQ-1e for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 18:30:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Rjz-00E21G-En for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 20:30:47 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab41ac9-2eae-0a2a0a5409dd-0a2a4505b454-32 for ; Wed, 23 Sep 2026 20:30:47 +0200 Received: from [74.125.225.106] (helo=mail-wr2-f42.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab41ad2-4cb1-0a2a45050019-4a7de16a8064-3 for ; Wed, 23 Sep 2026 20:30:42 +0200 Received: by mail-wr2-f42.google.com with SMTP id ffacd0b85a97d-482f6351832so803965f8f.3 for ; Wed, 23 Sep 2026 11:30:42 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4886877a2d5sm8602379f8f.27.2026.09.23.11.30.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Sep 2026 11:30:41 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790188242; x=1790793042; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=q8IjnyHBIb8twytu5XIRV8far1iW2HRZH+bNJVqG0qU=; b=sGEReVDASxvEMhtcEhw7kdlXCv1g3PH6IlX68Q0F4jKqVtXQN++XIhBROiwhnI0XVp WyyZoPFnY7V+sbJmemovaioRaczjc5ojXnSOJg1X7+BEIerkbf0RDK2AtuPGUwqhyeMp elWH+9nh98BNFTgOtChEWjEqnz2xNyFtKfeVwE4Bk9plFTBv92ZDHQtOM8VCxWInXHv1 HVXw3PAIerkRwmr/E/G1ny+Zu+fGi0sR5vObHkRNDBncP1NW2AxmOgr15iMKwNt+mRfd LfABJxM7Scn/H9jJLmps2lONnfFQfUUzqTJFXbRiRUuLETIZ5ebubXIC9nGPLav/Q1/V ttdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790188242; x=1790793042; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=q8IjnyHBIb8twytu5XIRV8far1iW2HRZH+bNJVqG0qU=; b=ewXmfs3q0VEdcD78w+6GO/hzV4TMS+0Hc11Q46ntLgde9XJ9yAuCpBxcgJ//C3r81x gX9L6AhVGLVl0t9fT5zSTWqNMwuU/CSBbQ7sQXyqwWe0zEI35xDpQ2rXlCiB6tlVG1tv ey+Z7P4/Tlr0m4DSgzwPvi7lkJGy4JksQhMrOrWhGposx3i66kC5jjr8W+Va4vhsyLB9 3X3VcxHfrfTefSozCEO61/QHM652cTZxE0lnek/j6zIvRviRBfoe4T/3TLQ/EKjvaeX5 3ifTN3Tj0TkOKrp+jTWc6l8M9ZY6li3p5W0RtM2yNHx5c/V8n5WTHXrOjS76O/NKGLTJ 8Z6w== X-Gm-Message-State: AFuF++lJYTr3N4KO7HnHO1KXT6o7/dspik+DG9Q3GkOfHVxfhoYQbQpQ brv+hR9/E9BbPJtx5LVe/h8qzYOdUPJZjjsJ8R3ZK1mujIxZTvfa9Fe1 X-Gm-Gg: AYBFou0r7ArxDyk/ahn7SZ5/yHJoGswboqYg6Qo3zHakEyd48O1UyrCehqcL4Ro68la RJvJCWeI6wJBPYK+pCJe39CbEYzmjGNPvwkl6G2B3MAyTS4Jlj9X78p74bQsB5jsS7+NIR0T4gl iqW8mZlHpwb6BtquQ8Y4Yqc7KAxiS3w0QGCGxJUTlFdF0GRnIxAa2yoQBDPsZGzkO7OINlQ3LNm wgXBaoGaNRQtVil2ignEsFv+NoCdZe4muLlQ4S6KqhyA8w6n00/zgn6WnllAAQakIew8Wbk18HT iIDVwhGmxvrTaOd/6aQK69VETQnyIasfFj+lRCU/yeZrH4coaTg7E3T81krAGO3ViUbtrrzECyu 09dtu/Jk2qtcA7ZR/n+IcIXMnG97RwXJZSdJInW+xcTDALcZXJBvTdH5VV5tF5MvqDq/lCdHhvh +bthkgPk+Y7m8JFdLxUsSNxk1Ru2+gmQdPDulZL5o6PyUMcgcZktMel/ICz+8mi1TuwaOfQxBFB EHRv89+wgn0vL15lO5kyhMIqeFSiglbB6tJZpOD47nIeDuRf1ds7QQjUu9l X-Received: by 2002:adf:e189:0:b0:486:e5c6:cab with SMTP id ffacd0b85a97d-48867093bc0mr6972710f8f.32.1790188241675; Wed, 23 Sep 2026 11:30:41 -0700 (PDT) Message-ID: Date: Wed, 23 Sep 2026 20:30:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1790176561.8631fc262581453bbf619ec5b2062170.1a0ced6896200072c4@vates.tech> <1790180167.8631fc262581453bbf619ec5b2062170.1a0cf0d8f3d00072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790180167.8631fc262581453bbf619ec5b2062170.1a0cf0d8f3d00072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c201ff/1790188242-247132A1-6F8F43FA/10/73395122804 X-purgate-type: spam X-purgate-size: 5817 On 9/23/26 6:16 PM, Baptiste Le Duc wrote: > On 2026-09-23 18:02 +0200, Oleksii Kurochko wrote: >> >> >> On 9/23/26 5:15 PM, Baptiste Le Duc wrote: >>>> At the old interrupt file, dump to memory all the eip and eie arrays). >>> Typo `)` >> >> Will drop `)`. >> >>>> After this step is done, the old interrupt file is no longer in use so >>>> old intrrupt file VGEIN could be released. >>>> >>>> Restoring of old interrupt file state will be done in follow-up >>>> patch. >>>> >>> >>> >>>> There are cases where it is needed to specify on which cpu it is >>>> necessary to VGEIN should be released so update vgein_release() to >>> >>> The sentence miss a verb, here is a proposal: >>> ``` >>> There are cases where the cpu on which the VGEIN is released needs to >>> be specified, so update vgein_release() to deal with that. >>> ``` >> >> I think it could be dropped at all as vgein_release() stub is just >> introduced here and not updated. >> >>> Moreover, could you explain me the cases you are talking about? It's not >>> clear by reading the commit message in the first place. >> >> For example, during migration of vCPU, vCPU->processor points to new CPU >> where it will be run but we still have to free VGEIN on the prev. >> ->processor. >> >>> >>> >>>> deal with that. >>> >>> >>> >>> >>>> >>> >>> >>>> Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard >>> >>> >>>> against silent incorrect behaviour or unexpected panics in guest VMs until >>>> the function is fully implemented. >>>> >>> >>> >>>> vgein_release() is stub for now and will be introduced later. >>> >>> >>>> >>>> Signed-off-by: Oleksii Kurochko >>>> >>>> diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c >>>> index 75c82bcfa1..be3901ec0c 100644 >>>> --- a/xen/arch/riscv/aia.c >>>> +++ b/xen/arch/riscv/aia.c >>>> @@ -30,3 +30,8 @@ unsigned int vgein_assign(struct vcpu *v) >>>> >>>> return 0; >>>> } >>>> + >>>> +void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) >>>> +{ >>>> + BUG_ON("unimplemented\n"); >>>> +} >>>> diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c >>>> index 5e9f6995e4..3cba58e0c1 100644 >>>> --- a/xen/arch/riscv/imsic.c >>>> +++ b/xen/arch/riscv/imsic.c >>>> @@ -56,6 +56,24 @@ static unsigned int __ro_after_init guest_num_msis; >>>> */ >>>> #define GUEST_IMSIC_MAX_MSIS 255U >>>> >>>> +/* >>>> + * The interrupt identities an IMSIC interrupt file provides are 0 (which is >>>> + * never valid, but still occupies a bit) up to IMSIC_MAX_ID inclusive, so >>>> + * IMSIC_MAX_ID + 1 bits have to be covered. >>>> + */ >>>> +#define IMSIC_MAX_EIX DIV_ROUND_UP(IMSIC_MAX_ID + 1, BITS_PER_TYPE(uint64_t)) >>> >>> >>>> + >>>> +struct imsic_mrif_eix { >>>> + unsigned long eip[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; >>>> + unsigned long eie[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; >>> >>> >>>> +}; >>>> + >>>> +struct imsic_mrif { >>>> + struct imsic_mrif_eix eix[IMSIC_MAX_EIX]; >>>> + unsigned long eithreshold; >>>> + unsigned long eidelivery; >>>> +}; >>>> + >>> Maybe I didn't get something but I couldn't find anything in the commit >>> message explaining why do we use mrif here. >> >> It is just convenient way to temporary store h/w interrupt file. Also it >> could be used not only for ... >> >>> >>> Moreover, mrif, as described in aia spec (8.3 Memory-resident interrupt >>> files), seems to be only usable with IOMMU that Xen doesn't support. >> >> ... IOMMU but also to support more guest interrupts file implemented by >> IMSIC (basically what I am calling as software interrupt file). Without >> memory-resident interrupt files, the number of virtual RISC-V harts that >> can directly receive MSIs from devices is limited by the total number of >> guest interrupt files implemented by all IMSICs in the system, because >> all MSIs to RISC-V harts must go through IMSICs. For a single RISC-V >> hart, the number of guest interrupt files is the GEILEN parameter >> defined by the Privileged Architecture, which can be at most 31 for RV32 >> and 63 for RV64. >> >>> >>> If you want to have something in memory that could store some interrupt >>> file info, we should take another name to not be confusing. >> >> It seems like it is okay to use memory residential interrupt file (mrif) >> here based on KVM's code who are using mrif for the same purpose I >> described above. >> >> In short, MRIF is a joint virtualization technology shared between the >> IOMMU and the hypervisor. The IOMMU uses the MRIF as a memory target to >> land incoming hardware MSIs, while the hypervisor manages these MRIFs in >> RAM as software data structures to support an effectively unlimited >> number of vCPUs that don't currently hold a physical IMSIC guest file slot. >> > Yes, I read the spec to understand but here, mrif doesn't catch the MSIs > right? Yes, because right now only h/w if(s) are supported. For now it is just a storage where we are saving temporary h/w interrupt file (which has the same structure as MRIF). When s/w if(s) will be supported we will need to store somewhere an interrupt file in RAM and considering that the structure of h/w if == s/w if and basically == mrif thereby mrif is a good candidate. Even more, ... > so it's not exactly the behaviour mentioned or you have in mind > to add full support when IOMMU will be supported? ... IOMMU points to the the same structure so again h/w if == s/w if == mrif from organization point of you. And answering your question we have in mind to support IOMMU for IMSIC purposes and then we still will need mrif structure. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Sep 23 20:15:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 20:15:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431309.1653477 (Exim 4.92) (envelope-from ) id 1x9TMr-0001bu-5L; Wed, 23 Sep 2026 20:15:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431309.1653477; Wed, 23 Sep 2026 20:15:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9TMr-0001bn-1J; Wed, 23 Sep 2026 20:15:01 +0000 Received: by outflank-mailman (input) for mailman id 1431309; Wed, 23 Sep 2026 20:14:59 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9TMp-0001bg-Rt for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 20:14:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9TMp-00A9tI-92 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 22:14:59 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab43327-8faa-0a2a0a5109dd-0a2a450a91b6-40 for ; Wed, 23 Sep 2026 22:14:59 +0200 Received: from [74.125.229.205] (helo=mail-lf2-f13.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab43342-f2d2-0a2a450a0019-4a7de5cdb678-3 for ; Wed, 23 Sep 2026 22:14:59 +0200 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b8d6489419so1132026e87.3 for ; Wed, 23 Sep 2026 13:14:59 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790194498; cv=none; d=google.com; s=arc-20260327; b=UR9hEXeUm5vLqFHPKxBYmOjex8zylPzn6d8GDa69uMkzL660DhkpIR+vnbn43XVkiK sKGNI4Tet1ksY3DJOQrb77Q/zNn0cbUg/9/csC+mhrT8/thNicYQLXcE9HBMLipdlUFl Ud8GLaFl+rmDtczJX8R5pEtNvPk0VjI4xQ7Lv3cxWTf1DVPr8YRnkntG2lsINOkDWyw6 dhx00lzYXXTQjbzSZIZLFeIq6JygNf9bnF+8samX8a8dNy07FSx0VzHiCSJeRQL3OVa7 W7+lI+SgqU39ySpaVoIBSRjgdd02seodZ3A3xupBvswYYmtr8gzbQTJTja1HUT2MxVDf voDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=310ddxPyQ67CdOkKBpra+N+cJtSwigrefj3YJxWCnWk=; fh=iHb7RP+hgXFgvYb7euIDLHwm1Ntj6lTjth0e/S9Xdj8=; b=Xa6Xw4MTKC9uKOLVW2L3J6kZwyrDoHRq9mZ1XbkY16iwMiy4EDabuMJABe5Zoay4YH 989fUGweSnda/U4pYx51LMUmPxbEZ7hbCUBm4Qc1BXLTLoJrIepgpJWscss5Z4OobNVB feMwo783oft+Jhw4HiIwLIAhr04JVuzGcaUsIFroBCwhJJVYTViaE3Tq1QzXy2mK09HM K/aLSGy7NNeIdubK7+QBn/E2OQmNKIUhEyYCm3i+eiH3jvXnspgG2fXGcpaLjO7guqzs B/nDO+VZuvb0mICPhETubBHURWivELeELuKoBo9779/AXSQgs2dgYBwK5kXVLsNNkm0c nUxw==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790194498; x=1790799298; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=310ddxPyQ67CdOkKBpra+N+cJtSwigrefj3YJxWCnWk=; b=JtSg1AWxw0p9hSY4DRyR6Z8M2g5cCoy4X8Ya7+Df+J8hkhMpcOAOO98/pU3LJ8Szdl jOcB6wMqcMyJ573947uiwL7gh4E0SyyRD9uyzEcwirRD+i8eitjAv0ZY/qJc25uo8v5i gNgQ1oJYCpH1JnJRL67UiQejlxU0hoaNUs33Nt+26jetYW+HKjQVlekB3zsk1Fmu3Ubz LFqfMmwgWzOgDVlq8+5gBDVWR9L4yQ2n9dBAzCLqYJnRWXJndSZX5MwJ/PaBUEz4hQR0 MBX9p5ZEmkXhvW/ODqG5M4sQtl8XOD+SpSBPReVs0WzgQgCphst35GPXf9TQcZsANu7I ujCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790194498; x=1790799298; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=310ddxPyQ67CdOkKBpra+N+cJtSwigrefj3YJxWCnWk=; b=uwoNaq+uGOiTLoGesqMM4jDAHbF9Nx+0kesKI0Wn2j6rjORZV4aPcM8pIZehyHjFpk J0iRlwFFWznbgBmANKvDjsQJZyw2dUYjbXW7KM55W27bkhD9su/DoJIEEw9U//+QGVw7 YlMcJ+6KLmt8WSK35+el75M0rrsLv72eQ7glZV+XY+41KxMAIvoFma95O14n69GaCrOJ H53DBumzTujlo7Gq4H/8ZhD7tc16FeMk0VfgiNJkeJNJ6r0n6c7oSy3EXpZnR8l83EeU mMdBgr3jpdpUEozb25hr+qFzEGEmHmKNyKfbupacRsA8jLRdFFiNLb+kqTU9JNmt3GbF venw== X-Forwarded-Encrypted: i=1; AKwUvBzCNP1iaz++1RgCjLK48w4ZcdEhNFwHuq6cZ7g3J4kPDOWu23v/zUIMweFggLSjl4hx587Ce8ZGPO0=@lists.xenproject.org X-Gm-Message-State: AFuF++ksyYtJtEjYzplnpIPTh7dlO08HvSVgodkqgo9IonJ5Dc6bBQjU zJGOhJmbcl1DhcErzcjKhsbwzAdcLmQy6YLbtYWDHrYt58sXAo9hNG5PgL4k0ezQrH2/AjWOH2/ 5ZhxhaNLxoES8+Jw7uSGROYJtuV2Qj6E= X-Gm-Gg: AYBFou1xDZ8vduRECPYEe8PuSzJshu7EP0BFFAKzbDgkeaWQIMwdrb9uO6CYyGki4+X 1Y1GmDWzsJTdrlfhoT35V4b0MGwKD6ZDY26Ln9orHXzJQD7KZSHG0QpVBX6Nvtv6DU6KgjEsDf+ Qqhb6ehsLv4Tubh4rgcpEb5Gu8rCJ2RwYqPikdkLJmaSD3P0KDXP03xAZQEbY5xSpi0IDTG6ZT1 nfVDgmN9VZ8NSv0CPfdNa2RgmR1H77png+37jngeKksWLD5g7qAOlSAXTmP3d3eoyLMxB59MrTq X/oJoIuzVwBtpfuRSklHaRKs5a+cIfo1VcIHXJ0ER9DlTLx/GnxQtw== X-Received: by 2002:a05:6512:2383:b0:5b8:cfd0:90b3 with SMTP id 2adb3069b0e04-5b8df0590fbmr101470e87.19.1790194498352; Wed, 23 Sep 2026 13:14:58 -0700 (PDT) MIME-Version: 1.0 References: <1c846d023255a7a7a9ce533cde0a8db3c26eb855.1765811852.git.dmytro_prokopchuk1@epam.com> In-Reply-To: From: Mykola Kvach Date: Wed, 23 Sep 2026 23:14:46 +0300 X-Gm-Features: AclHuK9FD8zCBvGXohgM66Y66Arw7eVwR6HMki0gP4Xzkl0-i2cM81LRv6qxmPg Message-ID: Subject: Re: [PATCH v2] gic: Replace BUG() with ASSERT_UNREACHABLE() in LPI paths To: "Orzel, Michal" Cc: Dmytro Prokopchuk1 , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1790194499-53ED2CFC-426BC88B/0/0 X-purgate-type: clean X-purgate-size: 674 On Tue, Dec 16, 2025 at 10:57=E2=80=AFAM Orzel, Michal wrote: > > > > On 16/12/2025 09:22, Dmytro Prokopchuk1 wrote: > > MISRA C Rule 2.1 states: "A project shall not contain unreachable code.= " > > The GIC LPI driver callbacks violate this due to the use of the BUG() > > macro, which causes the function to never return. > > > > Swap BUG() for ASSERT_UNREACHABLE() to satisfy the rule without needing > > an additional deviation. > > > > Signed-off-by: Dmytro Prokopchuk > Reviewed-by: Michal Orzel Reviewed-by: Mykola Kvach Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Wed Sep 23 20:15:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 20:15:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431312.1653484 (Exim 4.92) (envelope-from ) id 1x9TNJ-0001wg-GB; Wed, 23 Sep 2026 20:15:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431312.1653484; Wed, 23 Sep 2026 20:15:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9TNJ-0001wZ-DB; Wed, 23 Sep 2026 20:15:29 +0000 Received: by outflank-mailman (input) for mailman id 1431312; Wed, 23 Sep 2026 20:15:28 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9TNI-0001w8-3K for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 20:15:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9TNG-008rfR-Mk for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 22:15:26 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4334d-bab6-0a2a0a5309dd-0a2a45029a76-20 for ; Wed, 23 Sep 2026 22:15:26 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4335e-6ca4-0a2a45020019-4a7de14cb25f-3 for ; Wed, 23 Sep 2026 22:15:26 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6356f6bso1098779f8f.2 for ; Wed, 23 Sep 2026 13:15:26 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790194526; cv=none; d=google.com; s=arc-20260327; b=BtA/q3fVJ1GUMzoRN6kZpoYxbEcIsZnYYOuSrFwIhJ9vsNH8sa6qila3TblC15PMxo OyS4UTG8sc3tI+S0R1rZe30WZBZfbgKD1GxwCDvh0rCdq8L6WqtE1xpPcCdgrhXlN10d VzSSOUBJpoJAI28zslLBphPyah1leIZXKUkRXKWQ7pZjnE+NKbdZFmEV5vkoOp6x5S8V sooVXWdBYXDcmO6N2t7unk4DvQgl7muTZWvB7P26LT+/eHsLlVYOJg3KZAHM1y/X/I/6 BCyPhstEQDEINxY5kzvu/L3PHSZbcufJDTTE5hZYUHJWDeOpu6S3E+uOOFC/ERV+ChdL LIZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kOoYO2x0ceYQoltgnReOSIDMz30qflbKcG3KVK6oiAM=; fh=3f41E6Nh1jEvWGJnylBzjuzP2JQmUlbohgqY5xbD5yU=; b=YylpakmsNVSdGnSW2alJ4e8fuN22R66GHHwK1BWjW0Mux+i9rgF3mYLQSuKpbpZnEp pGteyjs6/xW/xOk6itymA+lVvYHm55hJxUoZU1Ry01NuWBlYDmINCZFQy83CoY5ghN1A nhEnOTxCvkzzlFkBOfsepDfhd2Q/dpMPpeMluQsbmEPp71Yu1Y6o+fF01mwqbHFZ2U1t inRa8yKlUoHmOAuDnT0fvPAQ2BHhV2sPpr1itlxuz1zsOztBr8g1MVQmZ08IWgdaJoDX HdIiPIMZT8mzTd4X/utPRjoZUTua5VfgXQerWoT+JPzi0zhHCHZJ8ndwdrRvxgAPkwfF Qolw==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1790194526; x=1790799326; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=kOoYO2x0ceYQoltgnReOSIDMz30qflbKcG3KVK6oiAM=; b=RvbnNNZSSi3krdGNpYmfL/Bqeejk4MzkmjnlX4TsGRUnRkPfSBR88TEMNKRUvA2gn5 8Lq+xuyjggg1NWXhfG5I6XsqhN48n9GIyuFRB5uYSOsET/Fydi+g3VyUCxNjV+LvIxhn XTvnp7sYgZLHashvY3FMet1WqvcbFRCVl2obJ2luZnqRvv8jg+ZZUSzLv37gi1qTfGgq vH2FK4badx0sKfZCNBg8yucixT8Y3OHSJGDRQVfzJtralqxJQfCOsSUj4dFgisLytcGz 3qeaZVylMCg+vndDBmL66YSYo/NutxZ4hJ3k0+CHCzsy761bbU4ronYAeUVpRsJ5SfdF WnfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790194526; x=1790799326; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=kOoYO2x0ceYQoltgnReOSIDMz30qflbKcG3KVK6oiAM=; b=XRzOjdV3VvT+1M6GQ7flp16LxvS8JdFnGGHpDLScUm7RIBfAoJTHgJiPw9oAXbz4jo YZgcn5OzTskuSDEM2PpUjCOoJ/89Xnz5CV+QR2PthGyqKoIaTnLkGf0d2xl4MWcc8vcG JvKmW27UVZDXSdhZMMse4C4bs6sYd7iaK5LFq6iBkDSLNZhfooYPD6uv2458IhWl1HUC rQyxpi0ZGI7iSBUBZAq2E6ruXp6BTuuMFuXCnNrwTkucv4wbWpwqy16ole7W33kujRtJ exQEmw6xODZYZR0GwyRzLGI+PllNQAWm3yHkAZXyp7Z4JmAdI1SNkD9qNXHkrEehS5V0 jCnQ== X-Forwarded-Encrypted: i=1; AKwUvBxTt/mmP6e9juYAxZBb1ulXgIqZLbSnIsed564FeINAqNNRjc1sy3a819j9i+EknRFrnHwk0lg5JaA=@lists.xenproject.org X-Gm-Message-State: AFuF++mRhQjRw1wBeJPeYhQr0TAgQY7RbhjYsTyQkKvhW3aVfX4qXNoH is1MoTi8duHhFpkFMX4Diot/ytW6mh24Sc5CuouMey+CzY46QcKurIz3uVSA1sY+9VRM3vsazYK 3VPadsVeNZr2gktdtnYMyPl4afGdfhpb+SwILmVOr X-Gm-Gg: AYBFou1vtxKWrGYjCWmsfQk3AeAqzMCiUYD8w5dMrQd3d5AaH0vdQevgjbrCdYABK2C LHZhfZ/P+5nkm7NQHC4VgR1e5MqikoIDamUtxDoA6ivWua5P/Y3E0rljwaD8SgAr3ER9uYffPxa xthfH0QqrX3LroFbFALe31I8/qtEHN4Ns7cndaRKPJVrY8AzPeg3JmYvuooDFym5GpKXbcIK5tH fxhw/nSz425QaopObC28w93LY6/BkbquPC127iw//UKxHtZq4ezN3MJugX9IRAK+Nf4N2OD7lEb TNeG32XflhKoK7QFuw+wLibEqtSZ/86DteZKb+Okk9guc8ys14I1kjGTkpPzy1rK/bScvhTLymz MR5pC08IJT5ZXefP3OJ7qG7F1UzXz9834d/g8/ScfnxJsZhv61SxxClfE1oNXXuU5Lr7l0vgSmh b9Hw== X-Received: by 2002:a05:6000:2383:b0:485:ad55:208d with SMTP id ffacd0b85a97d-488716c8d48mr511088f8f.18.1790194525443; Wed, 23 Sep 2026 13:15:25 -0700 (PDT) MIME-Version: 1.0 References: <20260911084211.3149957-1-jgross@suse.com> <20260923193619.1408940-1-shreshth.srivastava@intel.com> In-Reply-To: <20260923193619.1408940-1-shreshth.srivastava@intel.com> From: Nick Desaulniers Date: Wed, 23 Sep 2026 13:15:14 -0700 X-Gm-Features: AclHuK-BmScte-vitIZ7FKAidjIiegIYr2tRDSSJKsz3-ZO8Fal-vgtzUYiiixY Message-ID: Subject: Re: [PATCH v5 00/17] x86/msr: Inline rdmsr/wrmsr instructions To: Shreshth Srivastava , Juergen Gross Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, llvm@lists.linux.dev, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, xin@zytor.com, nathan@kernel.org, jpoimboe@kernel.org, peterz@infradead.org, boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1790194526-F3EBB2AC-F2175C20/0/0 X-purgate-type: clean X-purgate-size: 3672 On Wed, Sep 23, 2026 at 12:36=E2=80=AFPM Shreshth Srivastava wrote: > > On 11.09.26 10:41, Juergen Gross wrote: > > When building a kernel with CONFIG_PARAVIRT_XXL the paravirt > > infrastructure will always use functions for reading or writing MSRs, > > even when running on bare metal. > > Hi Juergen, > > This doesn't build with CONFIG_PARAVIRT_XXL=3Dy. 16/17 and 17/17 are wher= e > it breaks, but the cause is the .byte fallbacks: ASM_WRMSRNS_IMM from > 08/17 and ASM_RDMSR_IMM from 10/17 don't end in a separator, unlike the > .insn variants above them. > > #define ASM_RDMSR_IMM \ > " .byte 0xc4,0xe7,0x7b,0xf6,0xc0; .long %c[msr]" > > That worked while they were only ever the last argument of an > ALTERNATIVE(), which appends its own newline. 16/17 concatenates them > with ASM_CLRERR: > > ASM_RDMSR_IMM ASM_CLRERR, X86_FEATURE_MSR_IMM, \ > > so the .long operand runs into the xor. From > make arch/x86/kernel/cpu/common.s: > > .byte 0xc4,0xe7,0x7b,0xf6,0xc0; .long 266xor %rdx,%rdx > > paravirt-msr.h:165: Error: junk at end of line, first unrecognized char= acter is `x' > > clang reports "error: unexpected token" in the same place. 71 objects > fail, the same 71 either way, no vmlinux. > > msr.h chooses between the .insn form and the .byte fallback with: > > #if defined(CONFIG_AS_IS_GNU) && CONFIG_AS_VERSION >=3D 24100 > > Two kinds of toolchain end up on the .byte side of that test: > > - GNU as older than 2.41. RHEL 9 and CentOS Stream 9 ship 2.35, and > Documentation/process/changes.rst sets the minimum at 2.30, so this > is a supported configuration rather than an old outlier. > - clang, any version. CONFIG_AS_IS_GNU is never set for clang, so the > && short-circuits and the version comparison is never reached. Your > 08/17 comment already notes that clang has no .insn support. Indeed, looks like we're missing support for .insn for x86. Filed https://github.com/llvm/llvm-project/issues/225916. (Please do file bugs against the toolchain when you encounter issues like this, and cc someone from kernel development). > > gcc with binutils 2.41 or newer takes the .insn path, where both macros > do end in a separator, and is unaffected. > > Reproduced on v7.3-rc2 with your v3 00/13, v2 0/5 and v5 00/17 applied in > that order, x86_64 defconfig plus HYPERVISOR_GUEST, PARAVIRT, XEN and > XEN_PV. gcc 11.5.0 with GNU as 2.35.2, and clang 21.1.7. > > Terminating both fallbacks fixes it, and both toolchains then build > vmlinux with no errors or warnings: > > diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h > index eba325ecfe4c..529c13553c63 100644 > --- a/arch/x86/include/asm/msr.h > +++ b/arch/x86/include/asm/msr.h > @@ -78,9 +78,9 @@ static inline void do_trace_rdpmc(u32 msr, u64 val, int= failed) {} > * form MSR access instructions reference %rax as the register operand. > */ > #define ASM_RDMSR_IMM \ > - " .byte 0xc4,0xe7,0x7b,0xf6,0xc0; .long %c[msr]" > + " .byte 0xc4,0xe7,0x7b,0xf6,0xc0; .long %c[msr]\n\t" > #define ASM_WRMSRNS_IMM \ > - " .byte 0xc4,0xe7,0x7a,0xf6,0xc0; .long %c[msr]" > + " .byte 0xc4,0xe7,0x7a,0xf6,0xc0; .long %c[msr]\n\t" > #endif > > #define RDMSR_AND_SAVE_RESULT \ > > ASM_WRMSRNS needs no change, _ASM_BYTES() already emits a semicolon. > > The WRMSRNS line belongs in 08/17 and the RDMSR line in 10/17. > > Thanks, > Shreshth --=20 Thanks, ~Nick Desaulniers From xen-devel-bounces@lists.xenproject.org Wed Sep 23 20:59:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 23 Sep 2026 20:59:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431355.1653493 (Exim 4.92) (envelope-from ) id 1x9U3y-00085a-Eb; Wed, 23 Sep 2026 20:59:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431355.1653493; Wed, 23 Sep 2026 20:59:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9U3y-00085T-C4; Wed, 23 Sep 2026 20:59:34 +0000 Received: by outflank-mailman (input) for mailman id 1431355; Wed, 23 Sep 2026 20:59:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9U3w-00085N-Nz for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 20:59:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9U3w-00EJE7-4p for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 22:59:32 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab43d90-8faa-0a2a0a5109dd-0a2a4508b200-32 for ; Wed, 23 Sep 2026 22:59:32 +0200 Received: from [172.234.252.31] (helo=sea.source.kernel.org) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab43db2-f659-0a2a45080019-aceafc1fd8cc-3 for ; Wed, 23 Sep 2026 22:59:31 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id B676041602; Wed, 23 Sep 2026 20:59:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 602181F000FF; Wed, 23 Sep 2026 20:59:29 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:From:To:Cc:Subject:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790197169; bh=IEdNn3aUwe4HImBS9dDjkJ7weHk8oU+emztUHcnANtw=; h=Date:From:To:Cc:Subject:In-Reply-To; b=QqomW+ylpw/PDwHN9aiavnvl81CPHF9/3wUqB+c4utej/ylTCBDXi9PwjpqywO48f qpoH7O7V2ClBBAc6veRhtMn+YFtMQU57vfRRpftyeQqjMJfAsiI9koqG0HNVwhCxgx R2GvCdoiPC4W9beZtTMPNobd5zj6RbzdrEwxEVKM1eZUatzQEvrfrNBVdeiQPs/LpV DwdHrQgMIQpCmpB/94BNzCIP6mSvzojtmhqdzFOsMOPHldJz4VxIcOTMjPZNGq7I+K PLTTmlIUxjLF+suBD4fBrd4SJ3YFZXArduF8R+tUZnRjDKVw2i5gzgIa3K7+IjzRot egDJ2t3wrj7MQ== Date: Wed, 23 Sep 2026 15:59:28 -0500 From: Bjorn Helgaas To: Alexey Kardashevskiy Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Ashish Kalra , Tom Lendacky , Herbert Xu , "David S. Miller" , Bjorn Helgaas , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Marek Szyprowski , Robin Murphy , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Catalin Marinas , Jini Susan George , Kees Cook , Michael Ellerman , Nikunj A Dadhania , Ard Biesheuvel , Eric Biggers , Kim Phillips , Joerg Roedel , Ethan Nelson-Moore , "Tycho Andersen (AMD)" , Liam Merwick , Michael Kerrisk , Suresh Siddha , Xiaotian Feng , Venkatesh Pallipadi , Andi Kleen , Kiryl Shutsemau , Tony Luck , Jason Gunthorpe , Lu Baolu , Xu Yilun , Carlos =?utf-8?B?TMOzcGV6?= , Jonathan Cameron , Jori Koolstra , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , "Aneesh Kumar K.V (Arm)" , Ian Campbell , Jeremy Fitzhardinge , Petr Tesarik , David Howells , Haavard Skinnemoen , Kenji Kaneshige , Ilpo =?utf-8?B?SsOkcnZpbmVu?= , Christian Marangi , Dave Jiang , Michael Kelley , Ilias Stamatis , Sumanth Korikkar , Simona Vetter , Toshi Kani , Greg Kroah-Hartman , Vinod Koul , Jiang Liu , Arnd Bergmann , Anshuman Khandual , Kefeng Wang , Palmer Dabbelt , linux-coco@lists.linux.dev, xen-devel@lists.xenproject.org, iommu@lists.linux.dev, linux-mm@kvack.org, aik@ozlabs.ru, Santosh Shukla , "Pratik R . Sampat" , Scott Soule Cheloha , Ackerley Tng , Fuad Tabba Subject: Re: [RFC PATCH kernel 02/17] pci/tsm: Fix stale comment about TDI report range start Message-ID: <20260923205928.GA1942391@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260916115159.1938195-3-aik@amd.com> X-purgate-ID: tlsNG-c1860d/1790197172-D634587B-99764D07/0/0 X-purgate-type: clean X-purgate-size: 1241 On Wed, Sep 16, 2026 at 09:51:42PM +1000, Alexey Kardashevskiy wrote: > The PCIe spec r6 and later defines the MMIO range start in 4K units which > was not the intention. The upcoming change makes it a byte address. > The structure is already fixed to match the new definition but the comment > is stale, fix it. Please include specific reference to current spec, e.g., "PCIe r7.0, sec x". I'm not sure who's intention is referred to here. Please make the subject line match others in drivers/pci in style, including capitalization. Use "git log --oneline drivers/pci" to see. > Signed-off-by: Alexey Kardashevskiy > --- > drivers/pci/tsm/core.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/pci/tsm/core.c b/drivers/pci/tsm/core.c > index 9ac216ad896d..2a18be5be56e 100644 > --- a/drivers/pci/tsm/core.c > +++ b/drivers/pci/tsm/core.c > @@ -623,7 +623,6 @@ EXPORT_SYMBOL_GPL(pci_tsm_mmio_teardown); > #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_IS_UPDATABLE BIT(3) > #define PCI_TSM_DEVIF_REPORT_MMIO_ATTR_RANGE_ID GENMASK(31, 16) > > -/* An interface report 'pfn' is 4K in size */ > struct pci_tsm_devif_mmio { > __le64 phys; > __le32 nr_pfns; > -- > 2.55.0 > From xen-devel-bounces@lists.xenproject.org Thu Sep 24 01:15:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 01:15:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431503.1653503 (Exim 4.92) (envelope-from ) id 1x9Y3Q-00055k-Kt; Thu, 24 Sep 2026 01:15:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431503.1653503; Thu, 24 Sep 2026 01:15:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Y3Q-00055c-GB; Thu, 24 Sep 2026 01:15:16 +0000 Received: by outflank-mailman (input) for mailman id 1431503; Thu, 24 Sep 2026 01:15:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Y3O-00055W-C1 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 01:15:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Y3M-00EgEw-A9 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 03:15:12 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab47983-e002-0a2a0a5209dd-0a2a4509ad5a-18 for ; Thu, 24 Sep 2026 03:15:12 +0200 Received: from [40.107.162.89] (helo=PA4PR04CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4799f-be1a-0a2a45090019-286ba2595b5c-3 for ; Thu, 24 Sep 2026 03:15:12 +0200 Received: from AM6PR03MB6070.eurprd03.prod.outlook.com (2603:10a6:20b:d4::24) by AMCPR03MB911274.eurprd03.prod.outlook.com (2603:10a6:20b:783::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.17; Thu, 24 Sep 2026 01:15:10 +0000 Received: from AM6PR03MB6070.eurprd03.prod.outlook.com ([fe80::6498:3539:2e93:7416]) by AM6PR03MB6070.eurprd03.prod.outlook.com ([fe80::6498:3539:2e93:7416%4]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 01:15:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ionwaPoPQkr9Xk+O2EyutHb1HO/VuAftGbGfMKvu2h6Z5FNUPxXyo+AlNqkOhfZnF5xCi0p6voTCY83PXa3cs8MoTBTgKu1t6WttGnGo36NnID9UDhA6eYvixLfsDWOq1cE+aoJEy0eUd1cc0YlgoSWKgSQLwlpaqOr6SBfnsYJSwwOUNhErHg0wZ2ZmHtmb+5wVD5K998G6VHYFuFv4sD4XMZbd1px1XrRXOmY6FW6biKNw+mppFj/GNGF63i7IVVq9KYXJvGR3p6LY7fkVcXxf3yrTRxnPyv/zvjYhwCBh8V+slTh4OUWU/1urHgM7CFxvABaxABe9elsSL4o90w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+pM9bP9lyZTCj4wWRlmA7O5+mgxvlg+StVGarZgWy5o=; b=OkC9gjCYMQeHadgeJS3SzXdf9R2HoX9xuYDq2+gVXn56scvKyGYpIXw2APnTPShVpDUeqZagMbykvEUeZqHiIq6nXwlBFG35VUvr6e3oBjITNweY3+LiJA4Uave8CyJ/KRhzrc96W1WiASi9Pc8rblxreYvrea+ojfv0nK+0x+tSJEsKINbYRbcoXE5nfBks7z3O0dM0aT8D2AGd5n0M4Bdvow3R0G9jRBw4U3lTDr9BKLvRPGXpefcK12WshP+h6QanDAfN2bLO+XtlwXjPUNaADK/4XoPAg/uOURrH0vJeshmW5WXB7qf15+h0hUBmyoBxNhCdlrxfrj9l+orLtw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+pM9bP9lyZTCj4wWRlmA7O5+mgxvlg+StVGarZgWy5o=; b=ooGmNtG9mDQ3r8eHesb/9/b9CAc/OYLIL/ZPpdPRK2k9Kbvh3XKPxt0iTBBk2Ji/wB1MDVmS8ivzAdKnEkX7QlflTvnYk+oz0rnUrmdANqw/o2eHLrQlc/Bxhu2JXM7HFAHkJuhHzV0vXj/4G42AC6vSJJrW1rKIdkqEhEb/o5c/5cCFcQCZsWXECqyHn7JNg4IAq2JZKx78fZ+XO1QOP7xVgyFlq0KR6Dmgci+qdIpLRAM8VsJPmbINsS+HJNow9BrLbnMQPDrwcd7zBFC+qqM13Zv6UQaGBY4cR2pLuoG1LCE9rZONrG6bLNGgy6tVWSJrYt8eF6HIryy5xS5IkA== From: Volodymyr Babchuk To: Oleksii Moisieiev CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Grygorii Strashko Subject: Re: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdSqBPF0kScKehyU2HqE/MZamZRQ== Date: Thu, 24 Sep 2026 01:15:10 +0000 Message-ID: <878q4r30wy.fsf@epam.com> References: <5c3ae163d21f619bf25c8757232a1a0867c3eb87.1790087968.git.oleksii_moisieiev@epam.com> <87pky43hm2.fsf@epam.com> <63f4841c-fb36-40c4-b96e-4a1aed95fbda@epam.com> In-Reply-To: <63f4841c-fb36-40c4-b96e-4a1aed95fbda@epam.com> (Oleksii Moisieiev's message of "Wed, 23 Sep 2026 08:25:50 +0000") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AM6PR03MB6070:EE_|AMCPR03MB911274:EE_ x-ms-office365-filtering-correlation-id: 2193ab15-41f1-4c43-c94d-08df19d94723 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|42112799006|366016|23010399003|38070700021|3023799007|6133799003|11063799006|10067099003|56012099006|4143699003|22082099003|18002099003; x-microsoft-antispam-message-info: OP7pbxqiqvcjHOy8rf+aBjVFZHfHMCO0Q9IEwJQ8sYEUgJ/T8QgIqNiDHXJ2/bmiJoO60bncT4Z0hdKqWK5bConUFebBzI5pBu5u8jQ8lR0k4BHRO0ghOOhtbOKw/oxYRyuTjmxTinpCR3wWFrD0LydD3YRluirXnlOHgVSnvEj4V+HuuXN/ju1JrI5oihHyARwq65g2xLprw/FThJT30Tfi2cv2NP5WyEqrXL9zlxSlmdyi6cR4SSy7+zFqrx/95LaHmV0nA9IqQJu2/k1199e4TdYszLKcvtCVdiJ2Vw1ZgKbBDo6W+IKfjYGSg73VWMmz16XhJietS6d3KNIfrJIpWMYl8NQmkNZpkySr4sQL9Y/m+L8jwUWNvrxcFeS+oPR8AC7kZiq1r+CPVb39hSft14H7EwtPvkNF8hKO3VS5Dcrm7iYB5VrTdE5jA3UicYOtYOHjIdlEVgl0VfXpIgzWN4Ru7kQHwXmnhNONJy241cP3Pm+J6nR1exezya+r2h/y/ui63SbE5KF1t9du0wSOk5J3S/+nreViHs+NpGgNSUeXjwYeEISRGtL/c+3P4RNIH/5mUQWK4IvISEvfKDO5Dgeb2PP50HpeF6Wjo+W6S1Btl1X5SP/JqFQ1h9pWBoZpl4cUnlJIrB4f/VZzpepgjtHLsZnUOxQf2nYpF5AlFMrgry2t7RGPsWanRHVgTbTME+aqCUuTUoll7segeGxmuc+7s3Lj0ODW1rHlCE4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR03MB6070.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(42112799006)(366016)(23010399003)(38070700021)(3023799007)(6133799003)(11063799006)(10067099003)(56012099006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Q1RUbk1nRGpKYXl1Mkl5M093Q3YyQkJLMTdicW5kWlEvMXVqaTZmTFhnVkFu?= =?utf-8?B?WXo5a0NZaVVoVUo4RE41cDNaYUNJZGFPTi9BTmtYcmk3dm1BdCtBUklTK2dj?= =?utf-8?B?K3grbjdjd3Z5M2JLOEpUb0txb1RXMjBZT1pEM3EzU3FrYmlqa29UcVZCM0Ur?= =?utf-8?B?MXYwSzBVQlNEUlpwRUI3enpFZlBUbW02V1ZRSGdFNGRrMmNPLy8wVWhHNUlY?= =?utf-8?B?ZndQcXE3Z1hCdXJOSWhuNXduRUR6T2hNVzd1aXdSRTA1ZlR3TU5tbkRFVENE?= =?utf-8?B?b0dVRE1nbldaSWUvTW10RlRvYXF6RU1RTzBYaDlJTFpqdkVUdHY1aVNQcFVL?= =?utf-8?B?bnlYUTd2WGZzejAzRjBqZFV1b2dqeElSOERVR2xnWlVFbis1eTNYL2x6SmFD?= =?utf-8?B?dXRhMlVINGdmZ2xRVENhV2RxaER1bVhnWjE1c3YzWEU5OHZ2WXdHSGdZMUFU?= =?utf-8?B?ZzVpdENsNnZmdHlVWTdCTDRISFNNZFNnR0w0TmVsbHJzZ3RXYU1vOWRLQmJR?= =?utf-8?B?ZzFmbkdCSThsUnNkblhtNHBiYmJhc3V5WmhzQ1hGQUJsay91R1E0cVNEUklO?= =?utf-8?B?Q2JiL2hNRzhxZjV6bHVnc3FxeHM5bDlKd2NUbFZVcjVhWGl5T0NVa3MvT0Vp?= =?utf-8?B?MEc5Q3lSeS9ESThiMnFrVDdUZC8ybm91TDY1VGFCSytVU3N0eU40Q2xCcDJZ?= =?utf-8?B?d1dkLzBhMWpQbnNaRVRKS2xvSGsvOG8ySDNHQ3lSNHB4RHFUT3ljaW1RWTNw?= =?utf-8?B?YVIwRW1mZTVOai9kNzNvaVNFSkx5alNyK1BSU2F4VnNBeGtYRE1ZYkc2OEtn?= =?utf-8?B?V2dZQWwvWXZPWk9lUHpoRjduc2NjanpZVVk0OWtTcG9vblJpQ1FJbS83TjE4?= =?utf-8?B?UkxRamI0NkRmNXptTDdKbGpOc1ZVSWp6WGVyMHEwL2NSQlAvYldmRjV4dmU4?= =?utf-8?B?TzhYQTM3bDRRd0ZuNVEwdnNVZmdtcmYzcFErWGdncm5KNi9mMVRhTEZtSUpj?= =?utf-8?B?bW14eVpCRmZEc3lFL0FWRnRSTzEwa3NwZTlWYlowOGRMUkZSRGNWcnJtYjFW?= =?utf-8?B?ODNXYVZNKzdzN1JHTFZGWHVOekFsWDlGajNJaTk3UUVQS2xWWVV5RjJDd1BG?= =?utf-8?B?OEdJUi9tNzJuWVFsYlNqZ0dRc3oyQ3hWcDFEaGF5Z1R6OVkrUWUzOVVRZXRw?= =?utf-8?B?UVQvK1BkZit3S1pTNTNXS2RkL0doVTFCWGJBbnFLb25GWWlOaDJpS3pERHJP?= =?utf-8?B?M2t6NmJGUCtYcyttK3V1MTNxcll5RVhjSHlSdjhNazBLR09MbkUvclhQUU9O?= =?utf-8?B?VDNocWZiNFFzTitReXVYK1U5YlJ4ckZUc1NhUHJDdjRya0Z1ZEdPSGtsL3dk?= =?utf-8?B?STZ3Z1I3blVsMVNiMVd6bHNVN3NqaEs2U3RaaTdGenBiY0djYzFrdG1Jb2hW?= =?utf-8?B?RVRjWnBqdXNEQ1JYT01GNzdDZmlQL2k5L2dDS1dUVkNUZkRiRWo2THovQUFa?= =?utf-8?B?NnRkTzZlSDM0OXZuT0tkRXVMa3pMbXk5UUltNmNkVnhrK3czQTdzY1JWREN3?= =?utf-8?B?aXFhekJiTFdCUzZjODlRZ01GOWw4dUZqZ1NCU0lxSVloUFNmZHBObGZVcTYx?= =?utf-8?B?bEhQK3grQUMvYlFYZnNQMDRHWmt4dEIzT0lMcUQvcFVPSUlLak9RL21uTnJN?= =?utf-8?B?aDcxVzcvZXJwZzI3SldoZHA1QzdIQ0hYV2hvWGwvRzN0TUZZR3pCU2tUUzhy?= =?utf-8?B?bUY1TUhQVDVrQkpTV0F2N0pUT05sYkZibU9GWVFRUGlTR1BZM1VZclRqMldX?= =?utf-8?B?N3p0b0l0ZC9RbE1Fa08xSndVNkNvVlE2UjlwbEROeW9jZjRIQW1SNUFJZzNF?= =?utf-8?B?Y3h2cGVzWXdLOUtlM2VneTVJalB2ODYyc2hzVDY5ZStnektwMnV0M096aU5M?= =?utf-8?B?RkthUVFETVdabkt5NXNkbmExOHBENzlBNjZTbEU4TVJHblpPcWw2cEw2L0wv?= =?utf-8?B?VWY3ZUJudDhydHM5WkRqaVNPWUYrMTRtbW52dmU0aG1rOW1ZZWJSRHFCSG5j?= =?utf-8?B?M3JqMGZsQ09oMmVNUEphdlkxWEhENkt4ZDlKSjI1Vk1odGt1Rm5jMXkyYlZk?= =?utf-8?B?OGNDWitVVXJqRXlCQlhvL3RyL0x4dXJ6Ny95RjJkSTZHc1hmdFl6Ukc0NTVF?= =?utf-8?B?YWhjc1RPdEZXQzdOaXU5YXFDQUxTOFp1dktMM3o4MjlUb1ZjWVFFUlpTVnVX?= =?utf-8?B?RXlIbzhxOGJuYlgzZ05QOGlOak5Mc1grUWx3VkZKSm9iR2h1SUZMaFVoMHpD?= =?utf-8?B?TW9HUnRoNXAxWTE2em1Vb0Y5VGpjNHVTM2JucUxMalkzTjF5Q011bEp2dWgr?= =?utf-8?Q?ioVrD38B8M/ODSRQ=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <0BE5C8C724C9C141A26F465DA2810EB2@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR03MB6070.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2193ab15-41f1-4c43-c94d-08df19d94723 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2026 01:15:10.1832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LFvS+FKyD/Ib2Ng/oUtzKV93lwYoAjiXn/LMnzVeYg4QgLmnr8o6kfcexrtuuAWboo1+TZbLazYYWSWS0gOylVKDS0eoWgoC0XXjMoClYaI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMCPR03MB911274 X-purgate-ID: tlsNG-bad1c0/1790212512-BC4CB034-7141B675/0/0 X-purgate-type: clean X-purgate-size: 16788 SGkgT2xla3NpaSwNCg0KT2xla3NpaSBNb2lzaWVpZXYgPE9sZWtzaWlfTW9pc2llaWV2QGVwYW0u Y29tPiB3cml0ZXM6DQoNCj4gT24gMjMvMDkvMjAyNiAwNDowMiwgVm9sb2R5bXlyIEJhYmNodWsg d3JvdGU6DQo+PiBIaSBPbGVrc2lpLA0KPj4NCj4+IE9sZWtzaWkgTW9pc2llaWV2IDxPbGVrc2lp X01vaXNpZWlldkBlcGFtLmNvbT4gd3JpdGVzOg0KPj4NCj4+IFRoaXMgaXMgYSBncmVhdCBwaWVj ZSBvZiBkb2N1bWVudGF0aW9uLiBJdCBpcyBsYXJnZXIgdGhhbiB0aGUgdGV4dCB5b3UNCj4+IGFk ZGVkIHRvIHRoZSAnZG9jJyBkaXJlY3RvcnkuIFNvIEkgYmVsaWV2ZSBpdCBpcyBiZXR0ZXIgdG8g cHV0IGludG8gYQ0KPj4gZGVzaWduIGRvY3VtZW50LCBzbyBpdCBpcyB3aWxsIG5vdCBiZSBsb3N0 IGluIHRoZSBnaXQgY29tbWl0IG1lc3NhZ2VzLg0KPg0KPiBIaSBWb2xvZHlteXIsDQo+DQo+IFRo YW5rIHlvdSBmb3IgYSBxdWljayByZXNwb25zZS4NCj4NCj4gSSd2ZSBqdXN0IHJlY2hla2VkIGRv Y3VtZW50IGluIHBhdGNoIDY6IA0KPiBkb2NzL2h5cGVydmlzb3ItZ3VpZGUvYXJtL2Zpcm13YXJl L2FybS1zY21pLnJzdCBhbmQNCj4NCj4gY29tcGFyZWQgaXQgd2l0aCB0aGUgaW5mb3JtYXRpb24g cHJvdmlkZWQgaW4gdGhlIGNvbW1pdCBkZXNjcmlwdGlvbi4NCj4NCj4gQXMgSSBjYW4gc2VlIGFs bCBpbmZvcm1hdGlvbiBwcm92aWRlZCBpbiB0aGUgZGVzY3JpcHRpb24gKGFkZCBzY2hlbWVzIA0K PiBhbmQgZHRzIGV4YW1wbGVzIGF0IGxlYXN0KQ0KPg0KPiBhcmUgcHJlc2VudCBpbiB0aGUgZG9j dW1lbnRhdGlvbi4gQWxzbyBkb2MgaXRzZWxmIGlzIG1vcmUgZGV0YWlsZWQgdGhlbiANCj4gdGhl IGNvbW1pdCBkZXNjcmlwdGlvbi4NCj4NCj4gTWF5YmUgSSBtaXNzZWQgc29tZXRoaW5nPw0KDQpB aCwgc28geW91IHB1dCB0aGlzIGluZm9ybWF0aW9uIGluIHRoZSBsYXN0IHBhdGNoIGluIHRoZSBz ZXJpZXMuIE9rYXksDQpzbyBJIG1pc3NlZCBpdC4NCg0KPj4+IFRoaXMgcGF0Y2ggaW50cm9kdWNl cyBTQ0kgZHJpdmVyIHRvIHN1cHBvcnQgZm9yIEFSTSBFTDMgVHJ1c3RlZCBGaXJtd2FyZS1BDQo+ Pj4gKFRGLUEpIHdoaWNoIHByb3ZpZGVzIFNDTUkgaW50ZXJmYWNlIHdpdGggbXVsdGktYWdlbnQg c3VwcG9ydCwgYXMgc2hvd24NCj4+PiBiZWxvdy4NCj4+Pg0KPj4+ICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+PiAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4gICAgfCBFTDMgVEYtQSBTQ01JICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KPj4+ICAgICstLS0tLS0tKy0tKy0tLS0tLS0rLS0rLS0tLS0t LSstLSstLS0tLS0tKysNCj4+PiAgICB8c2htZW0xIHwgIHxzaG1lbTAgfCAgfHNobWVtMiB8ICB8 c2htZW1YIHwNCj4+PiAgICArLS0tLS0rLSsgICstLS0rLS0tKyAgKy0tKy0tLS0rICArLS0tKy0t LSsNCj4+PiBzbWMtaWQxIHwgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4gYWdl bnQxICB8ICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4+ICAgICstLS0tLXYtLS0t LS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLSsNCj4+PiAgICB8ICAgICAgICAgICAgICB8 ICAgICAgICAgfCAgICAgICAgICAgfCAgICB8DQo+Pj4gICAgfCAgICAgICAgICAgICAgfCAgICAg ICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4+ICAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0r LS0tLS0tLS0tLS0rLS0tLSsNCj4+PiAgICAgICAgICAgc21jLWlkMCB8ICBzbWMtaWQyfCAgICBz bWMtaWRYfA0KPj4+ICAgICAgICAgICBhZ2VudDAgIHwgIGFnZW50MiB8ICAgIGFnZW50WCB8DQo+ Pj4gICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwNCj4+PiAgICAgICAg ICAgICAgKy0tLS12LS0tKyAgKy0tdi0tLS0tKyAgKy0tdi0tLS0tKw0KPj4+ICAgICAgICAgICAg ICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+Pj4gICAgICAgICAgICAgIHwg RG9tMCAgIHwgIHwgRG9tMSAgIHwgIHwgRG9tWCAgIHwNCj4+PiAgICAgICAgICAgICAgfCAgICAg ICAgfCAgfCAgICAgICAgfCAgfCAgICAgICAgfA0KPj4+ICAgICAgICAgICAgICB8ICAgICAgICB8 ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+Pj4gICAgICAgICAgICAgICstLS0tLS0tLSsgICst LS0tLS0tLSsgICstLS0tLS0tLSsNCj4+Pg0KPj4+IFRoZSBFTDMgU0NNSSBtdWx0aS1hZ2VudCBm aXJtd2FyZSBpcyBleHBlY3RlZCB0byBwcm92aWRlIFNDTUkgU01DIHNoYXJlZA0KPj4+IG1lbW9y eSB0cmFuc3BvcnQgZm9yIGV2ZXJ5IEFnZW50IGluIHRoZSBzeXN0ZW0uDQo+Pj4NCj4+PiBUaGUg U0NNSSBBZ2VudCB0cmFuc3BvcnQgY2hhbm5lbCBkZWZpbmVkIGJ5IHBhaXI6DQo+Pj4gICAtIHNt Yy1pZDogU01DIGlkIHVzZWQgZm9yIERvb3JiZWxsDQo+Pj4gICAtIHNobWVtOiBzaGFyZWQgbWVt b3J5IGZvciBtZXNzYWdlcyB0cmFuc2ZlciwgWGVuIHBhZ2UNCj4+PiAgIGFsaWduZWQuIFNoYXJl ZCBtZW1vcnkgaXMgbWFwcGVkIHdpdGggdGhlIGZvbGxvd2luZyBmbGFnczoNCj4+PiAgIE1UX0RF VklDRV9uR25SRS4NCj4+Pg0KPj4+IFRoZSBmb2xsd29pbmcgU0NNSSBBZ2VudHMgYXJlIGV4cGVj dGVkIHRvIGJlIGRlZmluZWQgYnkgU0NNSSBGVyB0byBlbmFibGUgU0NNSQ0KPj4+IG11bHRpLWFn ZW50IGZ1bmN0aW9uYWxpdHkgdW5kZXIgWGVuOg0KPj4+IC0gWGVuIG1hbmFnZW1lbnQgYWdlbnQ6 IHRydXN0ZWQgYWdlbnRzIHRoYXQgYWNjZXNzZXMgdG8gdGhlIEJhc2UgUHJvdG9jb2wNCj4+PiBj b21tYW5kcyB0byBjb25maWd1cmUgYWdlbnQgc3BlY2lmaWMgcGVybWlzc2lvbnMNCj4+PiAtIE9T UE0gVk0gYWdlbnRzOiBub24tdHJ1c3RlZCBhZ2VudCwgb25lIGZvciBlYWNoIEd1ZXN0IGRvbWFp biB3aGljaCBpcw0KPj4+ICAgIGFsbG93ZWQgZGlyZWN0IEhXIGFjY2Vzcy4gQXQgbGVhc3Qgb25l IE9TUE0gVk0gYWdlbnQgaGFzIHRvIGJlIHByb3ZpZGVkDQo+Pj4gICAgYnkgRlcgaWYgSFcgaXMg aGFuZGxlZCBvbmx5IGJ5IERvbTAgb3IgRHJpdmVyIERvbWFpbi4NCj4+Pg0KPj4+IFRoZSBFTDMg U0NNSSBGVyBpcyBleHBlY3RlZCB0byBpbXBsZW1lbnQgZm9sbG93aW5nIEJhc2UgcHJvdG9jb2wg bWVzc2FnZXM6DQo+Pj4gLSBCQVNFX0RJU0NPVkVSX0FHRU5UIChvcHRpb25hbCBpZiBhZ2VudF9p ZCB3YXMgcHJvdmlkZWQpDQo+Pj4gLSBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT04gKG9w dGlvbmFsKQ0KPj4+IC0gQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TIChvcHRpb25hbCkNCj4+ Pg0KPj4+IFRoZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGltcGxlbWVudHMgZm9s bG93aW5nDQo+Pj4gZnVuY3Rpb25hbGl0eToNCj4+PiAtIFRoZSBkcml2ZXIgaXMgaW5pdGlhbGl6 ZWQgZnJvbSB0aGUgWGVuIFNDTUkgY29udGFpbmVyIGBgeGVuX3NjbWlfY29uZmlnYGANCj4+PiAg ICAoY29tcGF0aWJsZSBgYHhlbixzY2lgYCkgcGxhY2VkIHVuZGVyIGBgL2Nob3Nlbi94ZW5gYC4g T25seSB0aGUNCj4+PiAgICBgYGFybSxzY21pLXNtY2BgIG5vZGUgdGhhdCBpcyBhIGNoaWxkIG9m IHRoaXMgY29udGFpbmVyIHdpbGwgYmluZCB0byBYZW47DQo+Pj4gICAgb3RoZXIgU0NNSSBub2Rl cyAoZm9yIGV4YW1wbGUgdW5kZXIgYGAvZmlybXdhcmVgYCkgYXJlIGlnbm9yZWQgdG8gYXZvaWQN Cj4+PiAgICBzdGVhbGluZyB0aGUgaG9zdCBPU1BNIGluc3RhbmNlLg0KPj4+DQo+Pj4gc2NtaV9z aG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+Pj4gICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz Y21pLXNobWVtIjsNCj4+PiAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMTAwMCAweDAgMHgx MDAwPjsNCj4+PiB9Ow0KPj4+IHNjbWlfeGVuOiBzY21pIHsNCj4+PiAgICAgICAgICBjb21wYXRp YmxlID0gImFybSxzY21pLXNtYyI7DQo+Pj4gICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAw MDAzPjsgPC0tLSBYZW4gbWFuYWdlbWVudCBhZ2VudCBzbWMtaWQNCj4+PiAgICAgICAgICAjYWRk cmVzcy1jZWxscyA9IDwgMT47DQo+Pj4gICAgICAgICAgI3NpemUtY2VsbHMgPSA8IDA+Ow0KPj4+ ICAgICAgICAgICNhY2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwgMT47DQo+Pj4gICAgICAgICAg c2htZW0gPSA8JnNjbWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IHNobWVtDQo+ Pj4gfTsNCj4+Pg0KPj4+IC0gVGhlIGRyaXZlciBvYnRhaW5zIFhlbiBzcGVjaWZpYyBTQ01JIEFn ZW50J3MgY29uZmlndXJhdGlvbiBmcm9tIHRoZQ0KPj4+ICAgIEhvc3QgRFQsIHByb2JlcyBBZ2Vu dHMgYW5kIGJ1aWxkcyBTQ01JIEFnZW50cyBsaXN0LiBUaGUgQWdlbnRzDQo+Pj4gICAgY29uZmln dXJhdGlvbiBpcyB0YWtlbiBmcm9tICJzY21pLXNlY29uZGFyeS1hZ2VudHMiIHByb3BlcnR5IHdo ZXJlDQo+Pj4gICAgZmlyc3QgaXRlbSBpcyAiYXJtLHNtYy1pZCIsIHNlY29uZCAtICJhcm0sc2Nt aS1zaG1lbSIgcGhhbmRsZSBhbmQNCj4+PiAgICB0aGlyZCBpcyBvcHRpb25hbCAiYWdlbnRfaWQi Og0KPj4+DQo+Pj4gLyB7DQo+Pj4gICAgY2hvc2VuIHsNCj4+PiAgICAgIHhlbiB7DQo+Pj4gICAg ICAgIHJhbmdlczsNCj4+PiAgICAgICAgeGVuX3NjbWlfY29uZmlnIHsNCj4+PiAgICAgICAgICBj b21wYXRpYmxlID0gInhlbixzY2kiOw0KPj4+ICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPDI+ Ow0KPj4+ICAgICAgICAgICNzaXplLWNlbGxzID0gPDI+Ow0KPj4+ICAgICAgICAgIHJhbmdlczsN Cj4+Pg0KPj4+IAlzY21pLXNlY29uZGFyeS1hZ2VudHMgPSA8DQo+Pj4gICAgICAgICAgICAweDgy MDAwMDAyICZzY21pX3NobV8wIDANCj4+PiAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2ht XzIgMg0KPj4+ICAgICAgICAgICAgMHg4MjAwMDAwNSAmc2NtaV9zaG1fMyAzPjsgPC0tLSBmdW5j X2lkLCBzaG1lbSwgYWdlbnRfaWQNCj4+PiAgICAgICAgICAjc2NtaS1zZWNvbmRhcnktYWdlbnRz LWNlbGxzID0gPDM+Ow0KPj4gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgdGhlIGNvcnJlY3Qg d2F5IG9mIHVzaW5nIC1jZWxscyBwcm9wZXJ0eS4NCj4+DQo+PiBUaGVzZSBwcm9wZXJ0aWVzIGFy ZSB1c2VkIGVpdGhlciB0byBwcm92aWRlIGluZm9ybWF0aW9uIGZvciAqKmNoaWxkKiogbm9kZXMN Cj4+IChsaWtlICNhZGRyZXNzLWNlbGxzIG9yICNzaXplLWNlbGxzKSBvciB0byBwcm92aWRlIGEg bnVtYmVyIG9mIGNlbGxzIHRvDQo+PiBlbmNvZGUgYSBzcGVjaWZpZXIgZm9yIGEgZG9tYWluIChs aWtlICNpbnRlcnJ1cHQtY2VsbHMpLg0KPj4NCj4+IEhlcmUgeW91IGFyZSBkb2luZyBuZWl0aGVy IG9mIHRoZXNlLiBJIHRoaW5rIHRoZSBwcm9wZXIgd2F5IGlzIHRvIGRlZmluZQ0KPj4gc2Vjb25k YXJ5IGFnZW50cyBhcyBjaGlsZHJlbjoNCj4+DQo+PiBhZ2VudHMgew0KPj4gICAgICAgICAgI2Fk ZHJlc3MtY2VsbHMgPSAxOw0KPj4gICAgICAgICAgI3NpemUtY2VsbHMgPSAwOw0KPj4gICAgICAg ICAgIHNjbWlfYWdlbnRfMjogc2NtaV9hZ2VudEAyIHsNCj4+ICAgICAgICAgICAgIGNvbXBhdGli bGUgPSAiYXJtLHNjbWktYWdlbnQiOyAgLy8gQWN0dWFsbHksIEkgYW0gbm90IHN1cmUgaWYNCj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gd2UgYWxsb3dl ZCB0byB1c2UgJ2FybScgbmFtZXNwYWNlDQo+Pg0KPj4gICAgICAgICAgICAgcmVnID0gPDI+OyAg ICAgICAgICAgICAgICAgICAgICAvLyBBZ2VudCBpZCBnb2VzIGhlcmUNCj4+ICAgICAgICAgICAg IHNobW1lbSA9ICZzY21pX3NobV8yOw0KPj4gICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDB4ODIw MDAwMDQ7DQo+PiAgICAgICAgICAgfTsNCj4+IH0NCj4+DQo+PiBXaXRoIHRoaXMgYXBwcm9hY2gg eW91IGRvbid0IG5lZWQgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyBhdCBhbGwNCj4+IGFu ZCB0aGUgd2hvbGUgc3RydWN0dXJlIGJlY29tZXMgbW9yZSBkZXZpY2UtdHJlZS1pc2guDQo+IFRo YW5rIHlvdSBmb3IgbG9va2luZyBhdCB0aGlzLiBJIGFncmVlIHRoYXQgdGhlIHR3byBjYXNlcyB5 b3UgbGlzdCBhcmUNCj4gdGhlIG1vc3QgY29tbW9uIG9uZXMsIGJ1dCB0aGV5IGFyZSBub3QgdGhl IG9ubHkgc2FuY3Rpb25lZCBvbmVzOiB0aGVyZSBpcyBhDQo+IHRoaXJkLCBsb25nLXN0YW5kaW5n IHBhdHRlcm4gd2hlcmUgYSAiIzxuYW1lPi1jZWxscyIgcHJvcGVydHkgaW4gYSBub2RlDQo+IGRl Y2xhcmVzIHRoZSBjZWxsIHN0cmlkZSBvZiBhICpub24tcGhhbmRsZSBsaXN0IHByb3BlcnR5IGlu IHRoYXQgdmVyeSBzYW1lDQo+IG5vZGUqLiBUaGF0IGlzIGV4YWN0bHkgd2hhdCAiI3NjbWktc2Vj b25kYXJ5LWFnZW50cy1jZWxscyIgZG9lcyBmb3INCj4gInNjbWktc2Vjb25kYXJ5LWFnZW50cyIu IFNvbWUgZXZpZGVuY2UgZnJvbSB0aGUgRGV2aWNldHJlZSBTcGVjaWZpY2F0aW9uIGFuZA0KPiBm cm9tIExpbnV4Og0KPg0KPiAxKSAicmFuZ2VzIiBhbmQgImludGVycnVwdC1tYXAiIGFyZSBwYXJz ZWQgd2l0aCB0aGUgY2VsbCBjb3VudHMgb2YgdGhlIG5vZGUNCj4gIMKgIMKgdGhhdCBjYXJyaWVz IHRoZW0sIG5vdCBvZiBhIGNoaWxkIG9yIG9mIGEgcGhhbmRsZSB0YXJnZXQuDQo+DQo+ICDCoCDC oGR0YyBlbmZvcmNlcyB0aGlzIGl0c2VsZjoNCj4NCj4gIMKgIMKgLSBzY3JpcHRzL2R0Yy9jaGVj a3MuYzo3ODUgY2hlY2tfcmFuZ2VzX2Zvcm1hdCgpIGNvbXB1dGVzIHRoZSBlbnRyeSANCj4gbGVu Z3RoDQo+ICDCoCDCoCDCoGFzIChwYXJlbnQgI2FkZHJlc3MtY2VsbHMgKyB0aGlzIG5vZGUncyAj YWRkcmVzcy1jZWxscyArIHRoaXMgbm9kZSdzDQo+ICDCoCDCoCDCoCNzaXplLWNlbGxzKSBhbmQg dmFsaWRhdGVzIHRoZSBsZW5ndGggb2YgInJhbmdlcyIgaW4gdGhpcyBub2RlIA0KPiBhZ2FpbnN0 IGl0Lg0KPg0KPiAgwqAgwqAtIHNjcmlwdHMvZHRjL2NoZWNrcy5jOjE2MDEgY2hlY2tfaW50ZXJy dXB0X21hcCgpOg0KPg0KPiAgwqAgwqAgwqAgwqAgwqBjZWxsc2l6ZSA9IG5vZGVfYWRkcl9jZWxs cyhub2RlKTsNCj4gIMKgIMKgIMKgIMKgIMKgY2VsbHNpemUgKz0gcHJvcHZhbF9jZWxsKGdldF9w cm9wZXJ0eShub2RlLCAiI2ludGVycnVwdC1jZWxscyIpKTsNCj4NCj4gIMKgIMKgIMKgaS5lLiB0 aGUgc3RyaWRlIG9mIHRoZSAiaW50ZXJydXB0LW1hcCIgZW50cmllcyBpbiBhIG5vZGUgaXMgdGFr ZW4gZnJvbQ0KPiAgwqAgwqAgwqAiI2FkZHJlc3MtY2VsbHMiIGFuZCAiI2ludGVycnVwdC1jZWxs cyIgKm9mIHRoYXQgc2FtZSBub2RlKi4gTGludXggDQo+IGRvZXMNCj4gIMKgIMKgIMKgdGhlIHNh bWUgaW4gZHJpdmVycy9vZi9pcnEuYy4NCj4NCj4gIMKgIMKgU28gImEgIyotY2VsbHMgcHJvcGVy dHkgaW4gbm9kZSBYIGRlc2NyaWJpbmcgdGhlIGxheW91dCBvZiBhIHByb3BlcnR5IGluDQo+ICDC oCDCoG5vZGUgWCIgaXMgbm90IGFuIGFidXNlIG9mIHRoZSBjb252ZW50aW9uLCBpdCBpcyBob3cg dHdvIG9mIHRoZSBjb3JlDQo+ICDCoCDCoERldmljZXRyZWUgU3BlY2lmaWNhdGlvbiBwcm9wZXJ0 aWVzIGFyZSBkZWZpbmVkLg0KPg0KPiAyKSBUaGVyZSBpcyBhIHByZWNlZGVudCB3aG9zZSBzaGFw ZSBpcyBpZGVudGljYWwgdG8gb3VycyAtIGEgdmVuZG9yIHByb3BlcnR5DQo+ICDCoCDCoGhvbGRp bmcgYSBsaXN0LCBwbHVzIGNlbGxzIHByb3BlcnRpZXMgaW4gdGhlIHNhbWUgbm9kZSB0aGF0IGRl c2NyaWJlIA0KPiBob3cgdG8NCj4gIMKgIMKgZGVjb2RlIGl0Og0KPg0KPiAgwqAgwqBEb2N1bWVu dGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdHBtL2libSx2dHBtLnlhbWw6MzYNCj4NCj4gIMKg IMKgIMKgIMKgaWJtLCNkbWEtYWRkcmVzcy1jZWxsczoNCj4gIMKgIMKgIMKgIMKgIMKgZGVzY3Jp cHRpb246DQo+ICDCoCDCoCDCoCDCoCDCoCDCoG51bWJlciBvZiBjZWxscyB0aGF0IGFyZSB1c2Vk IHRvIGVuY29kZSB0aGUgcGh5c2ljYWwgYWRkcmVzcyANCj4gZmllbGQNCj4gIMKgIMKgIMKgIMKg IMKgIMKgb2YgZG1hLXdpbmRvdyBwcm9wZXJ0aWVzDQo+ICDCoCDCoCDCoCDCoGlibSwjZG1hLXNp emUtY2VsbHM6DQo+ICDCoCDCoCDCoCDCoCDCoGRlc2NyaXB0aW9uOg0KPiAgwqAgwqAgwqAgwqAg wqAgwqBudW1iZXIgb2YgY2VsbHMgdGhhdCBhcmUgdXNlZCB0byBlbmNvZGUgdGhlIHNpemUgZmll bGQgb2YNCj4gIMKgIMKgIMKgIMKgIMKgIMKgZG1hLXdpbmRvdyBwcm9wZXJ0aWVzDQo+ICDCoCDC oCDCoCDCoGlibSxteS1kbWEtd2luZG93Og0KPiAgwqAgwqAgwqAgwqAgwqBkZXNjcmlwdGlvbjog RE1BIHdpbmRvdyBhc3NvY2lhdGVkIHdpdGggdGhpcyB2aXJ0dWFsIEkvTyBBZGFwdGVyDQo+DQo+ ICDCoCDCoGFuZCB0aGUgZXhhbXBsZSAoc2FtZSBmaWxlLCBsaW5lcyA5Ni05OCk6DQo+DQo+ICDC oCDCoCDCoCDCoGlibSwjZG1hLWFkZHJlc3MtY2VsbHMgPSA8MHgyPjsNCj4gIMKgIMKgIMKgIMKg aWJtLCNkbWEtc2l6ZS1jZWxscyA9IDwweDI+Ow0KPiAgwqAgwqAgwqAgwqBpYm0sbXktZG1hLXdp bmRvdyA9IDwweDEwMDAwMDAzIDB4MCAweDAgMHgwIDB4MTAwMDAwMDA+Ow0KPg0KPiAgwqAgwqBC b3RoIGNlbGxzIHByb3BlcnRpZXMgYXJlICJyZXF1aXJlZCIuIFRoZSBwYXJzZXIgaXMNCj4gIMKg IMKgYXJjaC9wb3dlcnBjL2tlcm5lbC9wcm9tX3BhcnNlLmM6MTEgb2ZfcGFyc2VfZG1hX3dpbmRv dygpLCB3aGljaCByZWFkcw0KPiAgwqAgwqAiaWJtLCNkbWEtYWRkcmVzcy1jZWxscyIgYW5kICJp Ym0sI2RtYS1zaXplLWNlbGxzIiBmcm9tIHRoZSBzYW1lIA0KPiBub2RlICJkbiINCj4gIMKgIMKg dG8gd2FsayAiaWJtLG15LWRtYS13aW5kb3ciLiBUaGVyZSBpcyBubyBwaGFuZGxlIGFuZCBubyBj aGlsZCBub2RlDQo+ICDCoCDCoGludm9sdmVkOyB0aGlzIGlzIGV4YWN0bHkgdGhlICJzZWxmLWRl c2NyaWJpbmcgbGlzdCBwcm9wZXJ0eSIgcGF0dGVybi4NCj4NCj4gMykgQSAiIyotY2VsbHMiIHBy b3BlcnR5IGRvZXMgbm90IGhhdmUgdG8gZGVzY3JpYmUgYSBwaGFuZGxlIHNwZWNpZmllciANCj4g YXQgYWxsOg0KPg0KPiAgwqAgwqAtICIjcGluY3RybC1jZWxscyIgKERvY3VtZW50YXRpb24vZGV2 aWNldHJlZS9iaW5kaW5ncy9waW5jdHJsLw0KPiAgwqAgwqAgwqBwaW5jdHJsLXNpbmdsZS55YW1s OjU1KSBnaXZlcyB0aGUgbnVtYmVyIG9mIGNlbGxzIHBlciBlbnRyeSBvZiB0aGUgDQo+IHBsYWlu DQo+ICDCoCDCoCDCoCJwaW5jdHJsLXNpbmdsZSxwaW5zIiBwcm9wZXJ0eTsgZHJpdmVycy9waW5j dHJsL2RldmljZXRyZWUuYzoyOTcNCj4gIMKgIMKgIMKgcGluY3RybF9maW5kX2NlbGxzX3NpemUo KSBsb29rcyBpdCB1cCBpbiB0aGUgcGFyZW50L2dyYW5kcGFyZW50IG5vZGUuDQo+ICDCoCDCoCDC oE5vIHBoYW5kbGUgc3BlY2lmaWVyIGlzIGludm9sdmVkLg0KPg0KPiAgwqAgwqAtICIjaW5kZXgt Y2VsbHMiIA0KPiAoRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3VzYi9mc2wsdXNi bWlzYy55YW1sOjU2KQ0KPiAgwqAgwqAgwqBpcyBub3QgYSBzcGVjaWZpZXIgZm9yIGFueSBkb21h aW4gZWl0aGVyLg0KPg0KPiBTbyB0aGUgY29udmVudGlvbiBpbiBwcmFjdGljZSBpcyAiYSAjPGZv bz4tY2VsbHMgcHJvcGVydHkgc3RhdGVzIGhvdyANCj4gbWFueSBjZWxscw0KPiBvbmUgPGZvbz4g ZW50cnkgb2NjdXBpZXMiLCBhbmQgdGhlIGVudHJpZXMgbWF5IGxpdmUgaW4gYSBjaGlsZCBub2Rl J3MgDQo+IHByb3BlcnR5DQo+ICgjYWRkcmVzcy1jZWxscyksIGluIGEgY29uc3VtZXIncyBwaGFu ZGxlIHNwZWNpZmllciAoI2ludGVycnVwdC1jZWxscywNCj4gI2Nsb2NrLWNlbGxzKSwgb3IgaW4g YSBwcm9wZXJ0eSBvZiB0aGUgZGVjbGFyaW5nIG5vZGUgaXRzZWxmIChyYW5nZXMsDQo+IGludGVy cnVwdC1tYXAsIGlibSxteS1kbWEtd2luZG93KS4gT3VyIHVzYWdlIGZhbGxzIGludG8gdGhlIHRo aXJkIGdyb3VwLg0KPg0KPiBUaGlzIGJyaW5nIHVzIHRvIHRoZSBmb2xsb3dpbmcgY29uY2x1c2lv biB0aGF0IA0KPiAjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzIHVzYWdlDQo+IGRvZXNuJ3Qg dGVjaG5pY2FsbHkgYnJlYWsgdGhlIGRldmljZS10cmVlIGNvbnZlbnRpb24gd2l0aCAyIGV4Y2Vw dGlvbnM6DQo+DQo+IGEpIFZlbmRvciBwcmVmaXguIERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9i aW5kaW5ncy93cml0aW5nLWJpbmRpbmdzLnJzdDo2OA0KPiAgwqAgwqBzYXlzICJETyB1c2UgYSB2 ZW5kb3IgcHJlZml4IG9uIGRldmljZS1zcGVjaWZpYyBwcm9wZXJ0eSBuYW1lcyIsIGFuZCBhbGwN Cj4gIMKgIMKgdGhlIHNhbWUtbm9kZSBwcmVjZWRlbnRzIGFib3ZlIGFyZSB2ZW5kb3ItcHJlZml4 ZWQgDQo+ICgiaWJtLCNkbWEtYWRkcmVzcy1jZWxscyIpLg0KPiAgwqAgwqBCb3RoIG9mIG91ciBw cm9wZXJ0aWVzIGFyZSBYZW4tc3BlY2lmaWMgYW5kIGxpdmUgdW5kZXIgL2Nob3Nlbi94ZW4sIA0K PiBzbyBpZiB3ZQ0KPiAgwqAgwqBrZWVwIHRoZSBmbGF0IGZvcm0gdGhleSBzaG91bGQgYmVjb21l ICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIiBhbmQNCj4gIMKgIMKgInhlbiwjc2NtaS1zZWNv bmRhcnktYWdlbnRzLWNlbGxzIi4NCj4NCj4gYikgRW50cnkgbGF5b3V0LiBJbiBvdXIgbGlzdCB0 aGUgcGhhbmRsZSBpcyB0aGUgc2Vjb25kIGNlbGwNCj4gIMKgIMKgKDxzbWMtaWQgJnNobWVtIGFn ZW50LWlkPiksIHdoaWNoIHByZXZlbnRzIHRoZSB1c2Ugb2YgdGhlIHN0YW5kYXJkDQo+ICDCoCDC oHBoYW5kbGUtYXJyYXkgaGVscGVycyAtIHRoZXkgYWxsIGV4cGVjdCB0aGUgcGhhbmRsZSBmaXJz dC4gSWYgd2UgDQo+IGtlZXAgdGhlDQo+ICDCoCDCoGZsYXQgZm9ybSwgcmVvcmRlcmluZyB0byA8 JnNobWVtIHNtYy1pZCBhZ2VudC1pZD4gd291bGQgbGV0IHRoZSANCj4gcHJvcGVydHkgYmUNCj4g IMKgIMKgcGFyc2VkIGFzIGFuIG9yZGluYXJ5IHBoYW5kbGUtYXJyYXkuDQo+DQo+IEFzIGZvciB5 b3VyIHByb3Bvc2FsOiB0aGUgY2hpbGQtbm9kZSBmb3JtIHlvdSBzdWdnZXN0IGlzIGNlcnRhaW5s eQ0KPiBtb3JlIGlkaW9tYXRpYywgaXQgbWFrZXMgdGhlIGFnZW50IGlkIGFuIGFkZHJlc3NhYmxl ICJyZWciIGFuZCBpdCANCj4gcmVtb3ZlcyB0aGUNCj4gb3B0aW9uYWwgMi12cy0zLWNlbGxzIHZh cmlhbnQgYWx0b2dldGhlci4gTXkgb25seSByZXNlcnZhdGlvbnMgYXJlIHRoYXQgDQo+IGl0IGdy b3dzDQo+IHRoZSBYZW4gRFQgcGFyc2VyIChub2RlIGl0ZXJhdGlvbiBpbnN0ZWFkIG9mIGEgc2lu Z2xlIHByb3BlcnR5IHdhbGspIGFuZCANCj4gdGhhdCB0aGUNCj4gY29tcGF0aWJsZSBzdHJpbmcg d291bGQgbmVlZCBhIG5hbWVzcGFjZSB3ZSBvd24gKCJ4ZW4sc2NtaS1hZ2VudCIgcmF0aGVyIA0K PiB0aGFuDQo+ICJhcm0sc2NtaS1hZ2VudCIsIGFzIHlvdSBjb3JyZWN0bHkgc3VzcGVjdGVkKS4N Cj4NCj4gU28gSSBkbyBub3QgdGhpbmsgdGhlIGN1cnJlbnQgZm9ybSBpcyBpbnZhbGlkLCBidXQg SSBoYXZlIG5vIG9iamVjdGlvbiB0bw0KPiBtb3ZpbmcgdG8gY2hpbGQgbm9kZXMgaWYgeW91IHBy ZWZlciBpdC4gUGxlYXNlIGxldCBtZSBrbm93IHdoaWNoIHdheSB5b3UgDQo+IHdvdWxkDQo+IGxp a2UgbWUgdG8gZ28gZm9yIHYxNCBhbmQgSSB3aWxsIHJlc3BpbiBhY2NvcmRpbmdseS4NCg0KWWVz LCBJIHRoaW5rIG1vcmUgaWRpb21hdGljIGZvcm1hdCBpcyBiZXR0ZXIuIEFsc28sIHlvdSBuZWVk IHRvIHdyaXRlIGENCnBhcnNlciBvbmNlLCBidXQgdXNlcnMgd2lsbCB3cml0ZSBkZXZpY2UgdHJl ZSBtb3JlIG9mdGVuLg0KDQpUaGUgc2Vjb25kIHRoaW5nIHRoYXQgYm90aGVycyBtZSBpcyB0aGUg c2hhcmVkIG1lbW9yeSBub2RlcyBpbnNpZGUgdGhlDQp4ZW5fc2NtaV9jb25maWcgbm9kZS4gSSBi ZWxpZXZlIHRoZXkgc2hvdWxkIGJlbG9uZyB0byByZXNlcnZlZF9tZW1vcnksIG5vPw0KDQoNCj4+ PiAgICAgICAgICB4ZW4sZG9tMC1zY2ktYWdlbnQtaWQgPSA8MD47DQo+Pj4NCj4+PiAgICAgICAg ICBzY21pX3NobV8wOiBzcmFtQDQ3ZmYwMDAwIHsNCj4+PiAgICAgICAgICAgIGNvbXBhdGlibGUg PSAiYXJtLHNjbWktc2htZW0iOw0KPj4+ICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYwMDAw IDB4MCAweDEwMDA+Ow0KPj4+ICAgICAgICAgIH07DQo+Pj4NCg0KWy4uLl0NCg0KLS0gDQpXQlIs IFZvbG9keW15cg== From xen-devel-bounces@lists.xenproject.org Thu Sep 24 02:30:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 02:30:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431574.1653511 (Exim 4.92) (envelope-from ) id 1x9ZDd-0007od-W5; Thu, 24 Sep 2026 02:29:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431574.1653511; Thu, 24 Sep 2026 02:29:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9ZDd-0007oV-T8; Thu, 24 Sep 2026 02:29:53 +0000 Received: by outflank-mailman (input) for mailman id 1431574; Thu, 24 Sep 2026 02:29:52 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9ZDc-0007oM-Jb for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 02:29:52 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9ZDb-009Qo5-6F for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 04:29:51 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab48a78-e002-0a2a0a5209dd-0a2a4504c8ba-42 for ; Thu, 24 Sep 2026 04:29:51 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab48b1e-b57f-0a2a45040019-a0658308987a-3 for ; Thu, 24 Sep 2026 04:29:50 +0200 Received: from xenrt10716048 (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 596FD4644A00; Wed, 23 Sep 2026 22:27:46 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Lin Liu To: ross.lagerwall@citrix.com Cc: andrew.cooper3@citrix.com, jason.andryuk@amd.com, jbeulich@suse.com, lin.liu01@citrix.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/nSVM: Save L2's CR4 on #VMEXIT, not Xen's Date: Thu, 24 Sep 2026 02:29:48 +0000 Message-ID: <20260924022948.1399293-1-lin.liu01@citrix.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <38c41bfb-48c6-4408-8da1-2b7d730a6c9e@citrix.com> References: <38c41bfb-48c6-4408-8da1-2b7d730a6c9e@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ebf023/1790216991-C0EDEB50-3D44657F/0/0 X-purgate-type: clean X-purgate-size: 226 Yeah, I think this is a good idea. I do think of other similar fields as well, but prefer the one-liner patch so it can be merged easly. I will follow up the proposal soon in new patches. Thanks for the nice help. Lin From xen-devel-bounces@lists.xenproject.org Thu Sep 24 05:02:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 05:02:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431700.1653521 (Exim 4.92) (envelope-from ) id 1x9bam-00052w-6i; Thu, 24 Sep 2026 05:01:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431700.1653521; Thu, 24 Sep 2026 05:01:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9bam-00052o-30; Thu, 24 Sep 2026 05:01:56 +0000 Received: by outflank-mailman (input) for mailman id 1431700; Thu, 24 Sep 2026 05:01:54 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9bak-00052i-Jz for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 05:01:54 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9baj-00FauK-IZ for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 07:01:53 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4aebc-bab6-0a2a0a5309dd-0a2a4507cf68-4 for ; Thu, 24 Sep 2026 07:01:53 +0200 Received: from [74.125.229.204] (helo=mail-lf2-f12.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4aec1-b4ea-0a2a45070019-4a7de5ccfa3e-3 for ; Thu, 24 Sep 2026 07:01:53 +0200 Received: by mail-lf2-f12.google.com with SMTP id 2adb3069b0e04-5b5e4f1744fso2159215e87.2 for ; Wed, 23 Sep 2026 22:01:53 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790226113; cv=none; d=google.com; s=arc-20260327; b=PP1TL0RDA6fvEaLRrMdaRnZgzyFjH+i3IFq7cXEu80lf6xNMXv18ekgEaH2/PS6crx ZAyKB9FGRusd9TMMsoBGjq4/yS6Dxenp3LW/Kjm91YwtkWOMYYzRO51ndV1YkQHmGzFS UArvELn08dr9jNV5cNUsjw3Xfa/fkIX3uGI/UTno+DSo4Xffcb3eipaqbjlcnu5mF4bu xmBBFviXWhwAkdAb14hGU4jmmugfnf8dGzrwFTMglp9Lt0fkO0IuoqMR4J2jvw/9E2OU LHHLLXj7jMeGNnQvBKLgQy5UbaNsY+PEQoa/x8sRE7rxQcJqwc+9uMuf2MVigqJf2362 0oOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=KCx1fqSXipixEFU1U5QO4FLgnVrlefZvTm2nl0uf+AI=; fh=N3vCEIYsxwmzEC2200hMfxl7H8AuZBr1H/EWDlY1frk=; b=IUhwmNFLguXnjbGsuXrFDLBTVV3oVx6hRp5fpSF5ebUvMXbonkovMicF8If8Hz9jqc uT69yTLyOzqHWcvqZZvOh8IoJ7o3qE22Qv6vLhM9Z1uHPnyVa1N8nWWq/NrwN3G9jET7 ubwt6jyFzx/KALqj7SC2cahmhFHAjNBcE3dJi/vSGxBbmUPxRfRapCHsoTOE+CDGZxVI gSGwr4jLd0s8a+T61imJXbSLmAkkjZEShu7yQSMJGZUUwt4I/dgChfLhf5gXlMF28Y4/ 672HeHVuFR0WtIIroBnjdxn4rblPmyTqni4P58MReqsRwjPtkpzpgRg1infTXRbSnOji en5A==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790226113; x=1790830913; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=KCx1fqSXipixEFU1U5QO4FLgnVrlefZvTm2nl0uf+AI=; b=g0xFIzgin8V0d1oskGmYRKIBtUjsJ6JFal1dZgndGFX8jN8asOGSVKopXcv56ppcLB gBAlkjeMmz5s+jhskGFs2GUdxYksctDuzj6hw/GdS5RAzx0YaK04JwZPJ57ldc8LsWGe FGosKyCkPrq68La6lHuLSS8VG15MqOx54IlDBXFqHlyjjF0UuP7zLy/J6AjPNm+rNi6f tPy7ROWpCR99UW1R1NCGMnSX7jab5zqbmMoVDZNhGFbLZdXGSERDmmbqfT+wqxkyfzdc 9LqcBYsnQoF3s2cY6bdMtU7822l1sRwdPEQC4n/J5rj10AtM7U/zk3DQlU5Fl5yN3PNV jC/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790226113; x=1790830913; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=KCx1fqSXipixEFU1U5QO4FLgnVrlefZvTm2nl0uf+AI=; b=gz/aMMbY5WkX+stBwZcaQoBTdFge8B4OAiLLmbzBGMtofmmcaFQ2KolECr3/cMMtL/ D8lZb9KX9GmVUELQqtdltMTBoEYEODaV3jRYBIJxorP4lAZX1RGUxngHSA1tpD3NJz9A nBOCwRkKOQ/IThOK9ZQqepcj6NytFUJfkev8irgLIHiSGYghtHY0bnpSY+glQzYXFHM5 wmte9RUz6TsvrD9MSU4R/L2CWRbewD/ZfRQjVkeOdkQX82xUWLoC3Yq0lzEJ9SxAUWxP c92fWqu8Vqj0HDIKed0ANWoNLSoJ9SByO5DRz4syunvP9ho0HRoLq1soVg1xOJXbDoSL bELg== X-Forwarded-Encrypted: i=1; AKwUvByEW421AME8MwGdMCiH506rqPFsmfAUveQ3UhPFPz4rXSVrgCTY6f+5W+RjjIbGCJn5PSz9ZPUkDtE=@lists.xenproject.org X-Gm-Message-State: AFuF++l+heZucxz/qo4K9hruuB6LZzUDZew2wqQdLQHG5BnU1TZz0/rk khFjR+x2mqb6oJ8VdP0tH0JwsmdqxSdPPOdBXRFo8cbiOmkTVGp4cjirZV5oUUroq2/O7YaYlj1 f7bZgJ+30Yfk+8EyKMD7W8CL2ryUy8HM= X-Gm-Gg: AYBFou3I9DVqrlhmavOgxcnRoL/LMX/SffwPzLZgD994CSHw7odSIWs/XeUwtqHQhx8 v1sXg3hT0fv4YC6D3cDAMWHSbhjxXlEix9ItyTElo83k3G6STcMdF9U+0ob0bKGFTQEhYQJra1F ZMwNh9kamHhBfT+NHI9d0Hk8K5kfHtHS0LcPfO4TWxZy6ZyxeYpPt9Y2bfcsox097Ijew9XEwS0 QnCQSxe9OiYMhv8bc4wgj8eQ8XQ4DsRGy1Tr6FBx/pGs9cv2qql+PBvyHZIqWM5+sdNmf5UlJqa i6XLM1c8Fk7tKuNQuUCQRvmyiME1Vrb1Vf2sIYEtw/9+T/DAkBHuJQ== X-Received: by 2002:a05:6512:b22:b0:5b6:183c:5c89 with SMTP id 2adb3069b0e04-5b8e0a06d51mr196017e87.39.1790226112495; Wed, 23 Sep 2026 22:01:52 -0700 (PDT) MIME-Version: 1.0 References: <87cxu44y2q.fsf@epam.com> In-Reply-To: <87cxu44y2q.fsf@epam.com> From: Mykola Kvach Date: Thu, 24 Sep 2026 08:00:00 +0300 X-Gm-Features: AclHuK9rbuCbYJOomSdKvxePLduh-uuqttcIkg34Wv5OTrkhfpxaCCczGcPilZ4 Message-ID: Subject: Re: [PATCH v3 3/4] xen/arm: its: refactor ITS quirk matching To: Volodymyr Babchuk Cc: Mykola Kvach , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1790226113-374D3AE4-1447A16D/0/0 X-purgate-type: clean X-purgate-size: 6741 On Wed, Sep 23, 2026 at 3:21=E2=80=AFAM Volodymyr Babchuk wrote: > > Hi, > > Mykola Kvach writes: > > > ITS quirks are matched only by IIDR and mask fields stored in each tabl= e > > entry. That is too coarse when the same GIC IP block appears on several > > platforms but a workaround is valid only for some of them. > > > > Replace the fixed IIDR fields with a generic match(hw_its, data) > > callback and an opaque data pointer. Add an IIDR matcher as a reusable > > building block and use it from the R-Car Gen4 matcher after checking th= e > > Renesas machine compatibles. > > > > This intentionally narrows the R-Car Gen4 quirk. Previously every ITS > > with IIDR 0x0201743b matched. Now it matches only a DT-discovered ITS o= n > > an r8a779f0 or r8a779g0 machine. ACPI-discovered ITSes and the same IID= R > > on other platforms no longer match. > > > > Keep first-match semantics explicit. Assert that non-sentinel entries > > provide a matcher and that IIDR matching receives match data. Retain > > runtime guards so malformed entries cannot cause a NULL function call > > or data dereference in non-debug builds. Place the matcher data and > > table in init-only read-only sections. > > > > The matched entry still supplies separate ITS and LPI flags; this patch > > only changes how the entry is selected. > > > > Signed-off-by: Mykola Kvach > > --- > > Changes in v3: > > - Document the intentional narrowing of the R-Car Gen4 match. > > - Add the non-debug NULL-data guard. > > - Put the matcher data and table in init-only read-only sections. > > > > Changes in v2: > > - Replace v1's optional platform callback plus fixed IIDR/mask fields > > with a single generic match(hw_its, data) selector. > > - Add a reusable IIDR matcher and use it after the R-Car Gen4 > > machine-compatible checks. > > - Document that the R-Car Gen4 quirk remains DT-only. > > - Keep the split ITS and host LPI quirk scopes when applying the matche= d > > entry. > > - Document first-match ordering in the lookup path and guard against > > entries without a match callback or IIDR match data. > > --- > > xen/arch/arm/gic-v3-its.c | 73 +++++++++++++++++++++++++++++++-------- > > 1 file changed, 58 insertions(+), 15 deletions(-) > > > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > > index 454fd0e0ef..f52232ca40 100644 > > --- a/xen/arch/arm/gic-v3-its.c > > +++ b/xen/arch/arm/gic-v3-its.c > > @@ -54,8 +54,8 @@ struct its_device { > > > > struct its_quirk { > > const char *desc; > > - uint32_t iidr; > > - uint32_t mask; > > + bool (*match)(const struct host_its *hw_its, const void *data); > > + const void *data; > > uint32_t its_flags; > > /* > > * lpi_flags are ORed into the global host LPI policy and must onl= y > > @@ -65,11 +65,52 @@ struct its_quirk { > > uint32_t lpi_flags; > > }; > > > > -static const struct its_quirk its_quirks[] =3D { > > +struct its_quirk_match_iidr { > > + uint32_t iidr; > > + uint32_t mask; > > +}; > > + > > +static bool __init gicv3_its_match_iidr(const struct host_its *hw_its, > > + const void *data) > > +{ > > + const struct its_quirk_match_iidr *match; > > + uint32_t iidr; > > + > > + ASSERT(data); > > + > > + if ( !data ) > > + return false; > > It looks strange to have both ASSERT and then this check. > > Maybe it is worth to remove ASSERT and print a warning in a debug build i= nstead? The ASSERT catches a programming error in the static quirk table in debug builds, while the explicit NULL check prevents a dereference when assertions are disabled. However, returning false skips a potentially required workaround, which could cause a less obvious failure later. This also raises the question of whether continuing is appropriate in non-debug builds. Would you prefer the debug warning you suggested, keeping ASSERT with an additional warning in non-debug builds, or using BUG_ON(!data) to stop immediately in all builds? > > > + > > + match =3D data; > > + iidr =3D readl_relaxed(hw_its->its_base + GITS_IIDR); > > + > > + return (iidr & match->mask) =3D=3D match->iidr; > > +} > > + > > +static bool __init gicv3_its_match_quirk_gen4(const struct host_its *h= w_its, > > + const void *data) > > +{ > > + if ( !hw_its->dt_node ) > > + return false; > > + > > + if ( !dt_machine_is_compatible("renesas,r8a779f0") && > > + !dt_machine_is_compatible("renesas,r8a779g0") ) > > + return false; > > + > > + return gicv3_its_match_iidr(hw_its, data); > > Do you really need to match IIDR in this case? You already know that > platform requires the quirk. I would prefer to retain the IIDR check. The machine compatible does not identify the exact ITS variant and revision. Keeping both checks preserves the existing IIDR restriction while narrowing the match to the affected platforms. Linux also uses both checks for the R-Car Gen4 DMA32 workaround: the quirk entry matches IIDR 0x0201743b with mask 0xffffffff, and its_enable_dma32() additionally checks the machine compatible. > > > +} > > + > > +static const struct its_quirk_match_iidr rcar_gen4_iidr __initconst = =3D { > > + /* Implementer 0x43b identifies Arm Ltd. */ > > + .iidr =3D 0x0201743b, > > + .mask =3D 0xffffffffU, > > +}; > > + > > +static const struct its_quirk its_quirks[] __initconstrel =3D { > > { > > - .desc =3D "R-Car Gen4", > > - .iidr =3D 0x0201743b, > > - .mask =3D 0xffffffffU, > > + .desc =3D "R-Car Gen4", > > + .match =3D gicv3_its_match_quirk_gen4, > > + .data =3D &rcar_gen4_iidr, > > .its_flags =3D GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_A= DDR, > > .lpi_flags =3D GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_A= DDR, > > }, > > @@ -78,18 +119,21 @@ static const struct its_quirk its_quirks[] =3D { > > } > > }; > > > > -static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t ii= dr) > > +static const struct its_quirk *__init gicv3_its_find_quirk( > > + const struct host_its *hw_its) > > { > > - const struct its_quirk *quirks =3D its_quirks; > > + const struct its_quirk *quirk; > > Is this change really required? Agreed, the rename is unnecessary. A single entry can carry several quirk flags, so the existing name also makes sense. I'll keep quirks. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Thu Sep 24 05:02:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 05:02:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431701.1653530 (Exim 4.92) (envelope-from ) id 1x9baq-0005FW-C6; Thu, 24 Sep 2026 05:02:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431701.1653530; Thu, 24 Sep 2026 05:02:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9baq-0005FP-9Q; Thu, 24 Sep 2026 05:02:00 +0000 Received: by outflank-mailman (input) for mailman id 1431701; Thu, 24 Sep 2026 05:01:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9bao-0005FA-Pd for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 05:01:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9bao-004xEB-6V for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 07:01:58 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4aebc-e002-0a2a0a5209dd-0a2a450ab518-34 for ; Thu, 24 Sep 2026 07:01:58 +0200 Received: from [74.125.229.205] (helo=mail-lf2-f13.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4aec5-f2d2-0a2a450a0019-4a7de5cdc741-3 for ; Thu, 24 Sep 2026 07:01:58 +0200 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b8d879752fso1288247e87.2 for ; Wed, 23 Sep 2026 22:01:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790226117; cv=none; d=google.com; s=arc-20260327; b=PbTKba2pxmo+y2nISFVrKCgadXftlO7bssArNA96/wLP1s4LbL2Gd20fQDwsy11Wv3 2FFAOtX0lrQWKino/f27/0xU1vlYAb/xBIk909dql/ClERPLoCP2iX7Qtc1zLG3X+N1H sFRW33FAhEmRXAD0SJxKIZQE982MgyZhK6M0NXnpDC/DdspdlK6dEfLfxleExmkK1fje Oi8KwNoIF3+4060p/X+G9Yu2hMsE1nlVpjtmWeQCYGBQha0zF3g8GR3qYZjLJsGFRQFA xTMYCXjyhQY76oP39FPgu+HqpRbuP3d79Ef3WmKxsG1pI2GE8ZeOkkJmG2xqrVIgncBA VFbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=2mnbVlKRorQRSy5N3Z5eLtpxA0WRkYE15BxZ7PKgfkk=; fh=0G2tH5PBgxhvCknJO5iqQp8yODac/UClzeeXE6wufUo=; b=GR/swS2Z65CZFqvFHlh+a1OKCjbf/zWnvebqt//PeUO6OxFQON2q1c98h3Jx+3V8Xl oAdfQe7oL0CIfmYN9xzZgghiRFDvQKSYr6gRlheu0YWUO44cysNkjN0FYC9KIXBqTUOa whJA6Kp1jUwT/+hhkSF10v+CjtJNlAVoP8JLj9werELeCigvA+5Uf0aJal11uMSgpmSm 5qNccORfzbf4R/z1HzM/FbvkcQ75qGFGG4fDnYrjTrCWfE7FUZQaB6s93PgVa+87Fpe6 Y2TQqB1VhhXISV/67Ei4UqukIrJb/K/mHvqUE1nslJ0mjgtKGlly/LUj1QA/rATCTcCx Oxkw==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790226117; x=1790830917; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=2mnbVlKRorQRSy5N3Z5eLtpxA0WRkYE15BxZ7PKgfkk=; b=ln5gvhPWa8ChzsaPOJ1Wznn0UBM0wsgXQMYnMVMrolTWI7sR5uZkv4QCKtmRETV9rL v660OJAeK8gPYJJJ0Rmw8kVfqvOrA8xqyKtLQiO6k+9vt8f37OCkoKTTzxxLPp1WtAya s2VWu+BM27G7+io2FOh4kvK9Eh4urBjKnYE5pntO+Ka6Q+6TbAwzQTX/NdofU/ntBaKQ fa4r2FocVNRsOqNjD9+B8CDDoO+LS3F0XHHszjT3MxXPZJaS9cEu1faHHU52KWSMi9WQ t2+MtCmUT+TakwlKtU06vqiwUdBNVRU8VG648kNVx4/mmN3o4AkTrOfm+jUhM41URfMS M+/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790226117; x=1790830917; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=2mnbVlKRorQRSy5N3Z5eLtpxA0WRkYE15BxZ7PKgfkk=; b=huc1tni7PBiqQ0jgulyUO+8L7t1IyaLoglfwgBoQRuUrVFQBYiadmhweR2TUZliBhZ Tv6cFOzsGz8CUhMfXfeeBUe7kYLQI0HRS+FoOHztI6xvPyfhwyCskuSVhxTtLT4uyJiD CdUY1BMAkF1FjG3lMkS1XQdwOAqX5gtkkCSrCPRkUhhdOLCRAUQ5DL5O3WcmsBvB0Mwj lS5xlRV/MkS9TE5jImzYcofZ5KTKNNwTix4JnM89tIPImc8pJPxNhPJLuoyQgfh1uyzs U1tAaOADBf7R/cMo9eT/fxTZIvK7e1vfsrZteJ73x4+Zpyk+Dl6XPA5lerL8d3qVlx/c 7Rcw== X-Forwarded-Encrypted: i=1; AKwUvBx1YnXO/GPsy9Lad7PYPb6NwBWEfMhNtmW8ZmE/fo8YHhlIFJFxF8Z5kV/wkoLc++Sq/Mt3iSuV9/M=@lists.xenproject.org X-Gm-Message-State: AFuF++nLxWP2lEDzU7MHZcrV9H2UVdyA1lSkVoPV0UdYxWErInPxD8Wb zr3jT0tbqmS8tBA2xQd2tPQXLDTRpxP8egEo+nia6RBzMKPf/alUf4HR8ZulyF8fD45mc2Ttekb Ih1YlWILtLHiyPIt3PhMd6NIeHeLvtNg= X-Gm-Gg: AYBFou0Hj4E4GIFl1vjS8et3T1S1sE0N6ljBs+NAutlf4k9w/g5pvIkqhNm3j0ud8up XP9rpJjD/HFYHlkSMa5eYtmFV6oBB0I+xSoapEcUSrX+UrgbOZSoYN89KXNTkpNwpXOEkjYhehc X46AaMD6rIGmJ4qb37lsPiIIpJWR/ntD1nVq7cfLmAtFCwxCdtXy7j8rW6CS4wPlBNe8fT8WHsD pCPwDTz8MuqeZ063KkCWhNlIg1SntmBvyIJo7khlrhBSUfWFL6zEpakaFUgT2mtwdksskjtxuY5 M49Q8SHtZ53kQV5iTX1FolzqT2blPKPz6+HdEh3g6FSBY9rmRmrbpA== X-Received: by 2002:a05:6512:3f06:b0:5b6:1a7c:27 with SMTP id 2adb3069b0e04-5b8df06f8e1mr398950e87.42.1790226117211; Wed, 23 Sep 2026 22:01:57 -0700 (PDT) MIME-Version: 1.0 References: <8733v06dsq.fsf@epam.com> In-Reply-To: <8733v06dsq.fsf@epam.com> From: Mykola Kvach Date: Thu, 24 Sep 2026 08:00:00 +0300 X-Gm-Features: AclHuK9rXx9yFmvPE8x1dn9SXmywgcknbuSLdHGbgZMoTKwO5yVFP6WYCPjIx6k Message-ID: Subject: Re: [PATCH v3 1/4] xen/arm: its: initialize host LPI state before activating ITSes To: Volodymyr Babchuk Cc: Mykola Kvach , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1790226118-524DFCFC-EA00DBC3/0/0 X-purgate-type: clean X-purgate-size: 4312 Hi Volodymyr, Thank you for the review. On Wed, Sep 23, 2026 at 2:56=E2=80=AFAM Volodymyr Babchuk wrote: > > Hi Mykola, > > Mykola Kvach writes: > > > The boot CPU pending table must use the memory attributes selected by > > ITS quirks. gicv3_lpi_init_host_lpis() is therefore called after > > gicv3_its_init(). However, gicv3_its_init() also programs and enables > > each ITS before host LPI state is allocated. No ITS commands are > > submitted at that point, but this ordering relies on that implementatio= n > > detail. > > > > Split per-ITS initialization into preparation and activation phases. > > First map and disable every ITS and collect its quirks. Then initialize > > host LPI state. Only after that, allocate and program the ITS tables an= d > > command queue, and enable each ITS. > > > > The subsequent gicv3_cpu_init() sequence remains unchanged: it programs > > the Redistributor LPI tables, enables LPIs, and then submits the first > > MAPC and SYNC commands. > > > > Suggested-by: Julien Grall > > Signed-off-by: Mykola Kvach > > --- > > Changes in v3: > > - New patch implementing the post-4.22 initialization order discussed > > during review of the ordering fix. > > > > Link: https://patchew.org/Xen/341edd8de63dcd84ccc6e7b6c03e9e8fc7105184.= 1781847061.git.mykola._5Fkvach@epam.com/ > > --- > > xen/arch/arm/gic-v3-its.c | 32 ++++++++++++++++++++++----- > > xen/arch/arm/gic-v3.c | 15 ++----------- > > xen/arch/arm/include/asm/gic_v3_its.h | 4 ++-- > > 3 files changed, 31 insertions(+), 20 deletions(-) > > > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > > index 325835b0ad..972825bf06 100644 > > --- a/xen/arch/arm/gic-v3-its.c > > +++ b/xen/arch/arm/gic-v3-its.c > > @@ -11,6 +11,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -549,10 +550,9 @@ static int gicv3_disable_its(struct host_its *hw_i= ts) > > return -ETIMEDOUT; > > } > > > > -static int gicv3_its_init_single_its(struct host_its *hw_its) > > +static int __init gicv3_its_prepare_single_its(struct host_its *hw_its= ) > > { > > - uint64_t reg; > > - int i, ret; > > + int ret; > > > > hw_its->its_base =3D ioremap_nocache(hw_its->addr, hw_its->size); > > if ( !hw_its->its_base ) > > @@ -564,6 +564,14 @@ static int gicv3_its_init_single_its(struct host_i= ts *hw_its) > > > > gicv3_its_enable_quirks(hw_its); > > > > + return 0; > > +} > > + > > +static int __init gicv3_its_init_single_its(struct host_its *hw_its) > > +{ > > + uint64_t reg; > > + int i, ret; > > + > > reg =3D readq_relaxed(hw_its->its_base + GITS_TYPER); > > hw_its->devid_bits =3D GITS_TYPER_DEVICE_ID_BITS(reg); > > hw_its->evid_bits =3D GITS_TYPER_EVENT_ID_BITS(reg); > > @@ -1189,7 +1197,7 @@ static void gicv3_its_acpi_init(void) > > > > #endif > > > > -int gicv3_its_init(void) > > +int __init gicv3_its_init(unsigned int host_lpi_bits) > > { > > struct host_its *hw_its; > > int ret; > > @@ -1201,13 +1209,27 @@ int gicv3_its_init(void) > > > > list_for_each_entry(hw_its, &host_its_list, entry) > > { > > - ret =3D gicv3_its_init_single_its(hw_its); > > + ret =3D gicv3_its_prepare_single_its(hw_its); > > if ( ret ) > > return ret; > > } > > > > gicv3_its_validate_quirks(); > > > > + if ( list_empty(&host_its_list) ) > > + return 0; > > What is the purpose of this check here? I'd expect to see it before the > first list_for_each_entry() loop. The check skips host LPI initialization when no host ITS is present, preserving the existing behavior. Xen currently does not support LPIs without an ITS. gicv3_its_validate_quirks() already checks for an empty list, so the current placement does not cause a functional issue. The following patch also removes that function and its call. Would you be OK with keeping the current placement? Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Thu Sep 24 05:26:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 05:26:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431283.1653539 (Exim 4.92) (envelope-from ) id 1x9byj-0000Cu-7e; Thu, 24 Sep 2026 05:26:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431283.1653539; Thu, 24 Sep 2026 05:26:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9byj-0000Cn-4b; Thu, 24 Sep 2026 05:26:41 +0000 Received: by outflank-mailman (input) for mailman id 1431283; Wed, 23 Sep 2026 19:36:32 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9Slb-0004fR-V7 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 19:36:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9Sla-00EA01-9u for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 21:36:30 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab429de-2eae-0a2a0a5409dd-0a2a4507bf78-46 for ; Wed, 23 Sep 2026 21:36:28 +0200 Received: from [192.198.163.12] (helo=mgamail.intel.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab42a39-b4ea-0a2a45070019-c0c6a30cb7dc-3 for ; Wed, 23 Sep 2026 21:36:27 +0200 Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2026 12:36:25 -0700 Received: from smtp.ostc.intel.com ([10.54.69.131]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2026 12:36:24 -0700 Received: from cwf-2s5.sh.intel.com (cwf-2s5.sh.intel.com [10.239.48.132]) by smtp.ostc.intel.com (Postfix) with ESMTP id 813186393; Wed, 23 Sep 2026 12:36:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=Intel header.d=intel.com header.i="@intel.com" header.h="From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1790192187; x=1821728187; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=qbyegVfPVisMftvM9w19I2vmSLxDxgBL+oYOVHk7UT8=; b=GY1YK3YZYi2/5TJqhAUTrbd1Bf8XOMpbuPPU0qDYrLGRFtMLUhweXo13 FvipGI6X2freitqdiSfAUYTjLnmPeKOvx254soGOVsuIogSwszq6Y87xE PG/2LqYvwR8YHOEh+6z2CujWfEumxuwGxzwxEv1esuy8npBQ0jKewr2oe /Yx4C3KHwnQB48UM5KWFPxL3V8VyKbWgXkMDoxuh+F2QpQUrvRtiM/4F3 Y+QKgKBv+ArW8wqW2ed/hJzJ+PfweI4AbmO59SWCRzmIix2bjpusiOeDy emBW5Yrudsh5ufoTWsDogtZs+R2LKSTH2/Odfu4nxWlej4RkLpBu3pPrQ Q==; X-CSE-ConnectionGUID: OebOIXcRQ+yn219iRNNcPA== X-CSE-MsgGUID: IG0letZISoGw4wNpYE1UzQ== X-IronPort-AV: E=McAfee;i="6800,10657,11914"; a="94745873" X-IronPort-AV: E=Sophos;i="6.27,119,1787036400"; d="scan'208";a="94745873" X-CSE-ConnectionGUID: V7WQAby/SG+8UCxdRYJ8CA== X-CSE-MsgGUID: rL2ba/rySBKoESyRt8MCQQ== X-ExtLoop1: 1 From: Shreshth Srivastava To: Juergen Gross , linux-kernel@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, llvm@lists.linux.dev Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, xin@zytor.com, nathan@kernel.org, ndesaulniers@google.com, jpoimboe@kernel.org, peterz@infradead.org, boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v5 00/17] x86/msr: Inline rdmsr/wrmsr instructions Date: Wed, 23 Sep 2026 15:36:17 -0400 Message-ID: <20260923193619.1408940-1-shreshth.srivastava@intel.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260911084211.3149957-1-jgross@suse.com> References: <20260911084211.3149957-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790192188-A66DAAE4-502E9D87/0/0 X-purgate-type: clean X-purgate-size: 2994 On 11.09.26 10:41, Juergen Gross wrote: > When building a kernel with CONFIG_PARAVIRT_XXL the paravirt > infrastructure will always use functions for reading or writing MSRs, > even when running on bare metal. Hi Juergen, This doesn't build with CONFIG_PARAVIRT_XXL=y. 16/17 and 17/17 are where it breaks, but the cause is the .byte fallbacks: ASM_WRMSRNS_IMM from 08/17 and ASM_RDMSR_IMM from 10/17 don't end in a separator, unlike the .insn variants above them. #define ASM_RDMSR_IMM \ " .byte 0xc4,0xe7,0x7b,0xf6,0xc0; .long %c[msr]" That worked while they were only ever the last argument of an ALTERNATIVE(), which appends its own newline. 16/17 concatenates them with ASM_CLRERR: ASM_RDMSR_IMM ASM_CLRERR, X86_FEATURE_MSR_IMM, \ so the .long operand runs into the xor. From make arch/x86/kernel/cpu/common.s: .byte 0xc4,0xe7,0x7b,0xf6,0xc0; .long 266xor %rdx,%rdx paravirt-msr.h:165: Error: junk at end of line, first unrecognized character is `x' clang reports "error: unexpected token" in the same place. 71 objects fail, the same 71 either way, no vmlinux. msr.h chooses between the .insn form and the .byte fallback with: #if defined(CONFIG_AS_IS_GNU) && CONFIG_AS_VERSION >= 24100 Two kinds of toolchain end up on the .byte side of that test: - GNU as older than 2.41. RHEL 9 and CentOS Stream 9 ship 2.35, and Documentation/process/changes.rst sets the minimum at 2.30, so this is a supported configuration rather than an old outlier. - clang, any version. CONFIG_AS_IS_GNU is never set for clang, so the && short-circuits and the version comparison is never reached. Your 08/17 comment already notes that clang has no .insn support. gcc with binutils 2.41 or newer takes the .insn path, where both macros do end in a separator, and is unaffected. Reproduced on v7.3-rc2 with your v3 00/13, v2 0/5 and v5 00/17 applied in that order, x86_64 defconfig plus HYPERVISOR_GUEST, PARAVIRT, XEN and XEN_PV. gcc 11.5.0 with GNU as 2.35.2, and clang 21.1.7. Terminating both fallbacks fixes it, and both toolchains then build vmlinux with no errors or warnings: diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index eba325ecfe4c..529c13553c63 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -78,9 +78,9 @@ static inline void do_trace_rdpmc(u32 msr, u64 val, int failed) {} * form MSR access instructions reference %rax as the register operand. */ #define ASM_RDMSR_IMM \ - " .byte 0xc4,0xe7,0x7b,0xf6,0xc0; .long %c[msr]" + " .byte 0xc4,0xe7,0x7b,0xf6,0xc0; .long %c[msr]\n\t" #define ASM_WRMSRNS_IMM \ - " .byte 0xc4,0xe7,0x7a,0xf6,0xc0; .long %c[msr]" + " .byte 0xc4,0xe7,0x7a,0xf6,0xc0; .long %c[msr]\n\t" #endif #define RDMSR_AND_SAVE_RESULT \ ASM_WRMSRNS needs no change, _ASM_BYTES() already emits a semicolon. The WRMSRNS line belongs in 08/17 and the RDMSR line in 10/17. Thanks, Shreshth From xen-devel-bounces@lists.xenproject.org Thu Sep 24 06:49:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 06:49:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431795.1653547 (Exim 4.92) (envelope-from ) id 1x9dGM-0003n9-0l; Thu, 24 Sep 2026 06:48:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431795.1653547; Thu, 24 Sep 2026 06:48:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9dGL-0003n2-UP; Thu, 24 Sep 2026 06:48:57 +0000 Received: by outflank-mailman (input) for mailman id 1431795; Thu, 24 Sep 2026 06:48:56 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9dGK-0003mw-Gj for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 06:48:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9dGJ-004FBg-Jq for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 08:48:55 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4c7b7-2eae-0a2a0a5409dd-0a2a450beb4a-46 for ; Thu, 24 Sep 2026 08:48:55 +0200 Received: from [74.125.229.204] (helo=mail-lf2-f12.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4c7d7-b7e8-0a2a450b0019-4a7de5ccbeaf-3 for ; Thu, 24 Sep 2026 08:48:55 +0200 Received: by mail-lf2-f12.google.com with SMTP id 2adb3069b0e04-5b79784a6edso1623657e87.1 for ; Wed, 23 Sep 2026 23:48:55 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790232535; cv=none; d=google.com; s=arc-20260327; b=aLv/zUY+BCYawXuQlZNwi/tV6BmziHZNIW7NXtf5O5kFyk1I9Cw+5EVjtGWmIbIeiJ i+dDYw8jAiCXsD2JdY9KuvY3w0ksSYz8NjFZPIVO+RugNIxJI1qT04irxTw1BcUdyW2C V2revzrJEnZmNpORp2NWqwrFNNLaY0I/KIphPvIVDyE6a2htr7tjwHo7iUfPNSinGL/8 IlrCTkTaHRYLFEFE9W+U+xnZR21iALVE3lvE/N5osWBMlHlLMPkB/c4EWQYXBU0WmSxP h36w4+h9DJ9RCwjknj64xxOfmGnozBb0h7s9ULER8UcTobq5JSRc4PKi+gRY8L9kC1gQ HyZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=nV0Gg6TO0aRbcsCOon3fJLQf0ueAKJ9vn9vU0D/FZFE=; fh=S0lixzhbrrbRqCv1owUgzGFfDmLcTjVJXgrnOWYFryQ=; b=gkXZLT7VkQbq7SsX8mjNanGMz4NRgWcRpR0tUHVaDk/AZabs7Nc687N/JES+C73VVs QFMAXsR9RPCDUe50jQgRSPQQTpDUEWu9Gup8sHHmwdybaHDk3Wmpy8/5qEEygVyGt7an 03MJKdoi8dxr6qzFSmOxmrYfYQPpJfGNDtZ419YAq6L+Jes6fXO6JE12mzH2oRxKm18l DbJtPH3W70Au0xC+VdahreTL/bNDiyfKn0jjHwQv17CTQRNgYPAX5yA1aG7g/ZgnzPf7 XXW/N9jlkeopPD4niYClJv/3TZg5rpDgn2CaiSkKitWKm9NeGOuj0fyhAXb7X/UqQCIy e9UA==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790232535; x=1790837335; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=nV0Gg6TO0aRbcsCOon3fJLQf0ueAKJ9vn9vU0D/FZFE=; b=UyhDY0b+1mKFktYV05UPfGvqlxlDdYl38JqSw1CsFnswGxz5cHWu+3izqIlFXFISLD Y/S8H1q7YfowXQ4+s7Nra6vhCEusxEqHGJuQQIvNRMgy/nSWJrTb53pEeM8oGPLdB1PI BAySFWQdHS7YEdL8pcjX91mvwue17r4znp58cbBB55n2Cp35jZTo+KEkbXai1nMU/Bkf GVmNRXKKPdfkok1IE0Ef0n4y4pGyfHiN4fp+GwYLDPOjnSkFR4D2T2l0jFAFy6nKCyFV nT8OWRWeOAk0SNjBFzM8Lkd5GQ1HteLrGf9uzYeUZzBko/rqYFcav1YcZzpTDm0PlUs2 IV1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790232535; x=1790837335; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=nV0Gg6TO0aRbcsCOon3fJLQf0ueAKJ9vn9vU0D/FZFE=; b=pPdfX0a0GmNaKj2/d9W/DwAuLy/Hx3GHk0kzvGvrQH/+cpJoR6923HaQYm0rd+7wcb u3e8xCf4/F2SSYjIt0C4dakFLJ8nv28uaFcc1f8XQLMQNhCk4HZgoXJsAUaMf5delZ+v t5gkP/uZKGK10SAGsraQ9mkaye4kw3o83sA4fUD5PKDhx2Q6CQmsAnHiBV8UU2qTrFB9 KLIDd8qDzhDWMhzKGI9y7njiA54wJG8ylPVzk/aMTX3jH91UEAt0Ce2zSDOqi8K5V44b SyWEW/UhusRbZqnyLjUzv0LG7OOQix7HFJaTXNIz4J7D6wyUoqTm2jUSm/GS+u1U9XGc TWLQ== X-Forwarded-Encrypted: i=1; AKwUvBwgN48N9WdoN6C05HiAqRgKEzVVJIGv/pSvc+10tQLjHedP5ZGlu4p4OdLzPi9vTgxkU5XRQ5jFoJ8=@lists.xenproject.org X-Gm-Message-State: AFuF++njr0YCqP+HxRPn8QW2u9iwoHSuu881C4+r3mqKfXBgJ9/PRv9u FZv8d49Ag5dkh3GE0Tp/y1iaG5UZkfy0hbOAdarrsd2S0gVCm8ied17WTRcw5pW0L7pHaAjLBgu jqokTnbshgBbz7fYquVP4F5aAt4ge7tNU4c9Krh8= X-Gm-Gg: AYBFou2bm0mV0f6M1oqdPpP0COs01hOtw3TJD0JxvSnOoCDQh6cCx7ufnX3T7BtAi6L 60153Al5SZ71AHciLJqHZAplF/h4qGlYTzqn8GBScbMPAs5Vu32YcwW0kq+Jxa2h6E3ZToBjCSt Cqru8ghKolcuyywNlox0QgKUDlwEvILYQj5a8vSXa8/IY2RlRj2eDleXsqb8fbXPt7MnJeozBfG XQswQdqwE64RYDlm3vorrbT/ZfjVcVAWbQFDsj6DkseENK9TWvtAmFU61aM4lO2K0FSdA68uZZO yzOW9o2ulhJJ7/4uwmvLSug7WgMS/loLMXuv0KaJT6vhxNgdqIldZg== X-Received: by 2002:a05:6512:2248:b0:5b4:5f6b:d43e with SMTP id 2adb3069b0e04-5b8df06a3afmr527530e87.14.1790232534537; Wed, 23 Sep 2026 23:48:54 -0700 (PDT) MIME-Version: 1.0 References: <874ifg4xoq.fsf@epam.com> In-Reply-To: <874ifg4xoq.fsf@epam.com> From: Mykola Kvach Date: Thu, 24 Sep 2026 09:48:42 +0300 X-Gm-Features: AclHuK-E17t3rxcpD-vFN4icp4iF4fj1FBG2Fi5P9Pf76fG-rmrqf4yjrOPMWSc Message-ID: Subject: Re: [PATCH v3 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes To: Volodymyr Babchuk Cc: Mykola Kvach , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1790232535-AB8D19EA-3041BBDC/0/0 X-purgate-type: clean X-purgate-size: 5131 On Wed, Sep 23, 2026 at 3:30=E2=80=AFAM Volodymyr Babchuk wrote: > > Hi, > > Mykola Kvach writes: > > > The DT dma-noncoherent property describes the bus coherency of the > > device represented by the node. On an ITS subnode, that is memory > > accessed by that ITS. Add GICV3_QUIRK_MEM_NC_NS to the corresponding > > host_its and use it when programming GITS_CBASER and GITS_BASER. > > > > On the top-level GIC node, the property describes the Redistributor sid= e > > of the LPI path. Collect it in gicv3_lpi_init_host_lpis() and apply it > > only to the host LPI policy used when allocating the property and > > pending tables and when programming GICR_PROPBASER and GICR_PENDBASER. > > Mark the function init-only because firmware attributes are collected > > only during boot. > > > > Do not inherit the property between parent and child nodes: ITS-node > > non-coherency does not change the global host LPI policy, and GIC-node > > non-coherency does not change per-ITS quirk_flags. > > > > ACPI is unchanged; this patch only consumes the DT dma-noncoherent > > property. > > > > Signed-off-by: Mykola Kvach > > --- > > Changes in v3: > > - Keep the ITS init annotations with the earlier initialization patch. > > - Drop the redundant aggregate host-LPI-flags message. > > > > Changes in v2: > > - Split v1's dma-noncoherent handling into explicit ITS-node and GIC-no= de > > scopes. > > - Apply an ITS subnode property only to the matching host_its > > quirk_flags. > > - Collect the top-level GIC property from gic-v3-lpi.c before host LPI > > allocations use host_lpi_flags. > > --- > > xen/arch/arm/gic-v3-its.c | 17 +++++++++++++++++ > > xen/arch/arm/gic-v3-lpi.c | 20 +++++++++++++++++++- > > 2 files changed, 36 insertions(+), 1 deletion(-) > > > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > > index f52232ca40..6734f94e7c 100644 > > --- a/xen/arch/arm/gic-v3-its.c > > +++ b/xen/arch/arm/gic-v3-its.c > > @@ -139,6 +139,21 @@ static const struct its_quirk *__init gicv3_its_fi= nd_quirk( > > return NULL; > > } > > > > +static void __init gicv3_its_collect_fw_attrs(struct host_its *hw_its) > > +{ > > + /* > > + * An ITS subnode property describes memory transactions made by t= hat ITS. > > + * Do not inherit it into the global host LPI/Redistributor policy= . > > + */ > > + if ( !hw_its->dt_node || > > + !dt_property_read_bool(hw_its->dt_node, "dma-noncoherent") ) > > + return; > > + > > + hw_its->quirk_flags |=3D GICV3_QUIRK_MEM_NC_NS; > > + printk("GICv3: ITS @%#"PRIpaddr" marked dma-noncoherent\n", > > + hw_its->addr); > > +} > > + > > static void __init gicv3_its_collect_quirks(struct host_its *hw_its) > > { > > const struct its_quirk *quirk =3D gicv3_its_find_quirk(hw_its); > > @@ -149,6 +164,8 @@ static void __init gicv3_its_collect_quirks(struct = host_its *hw_its) > > gicv3_lpi_update_host_flags(quirk->lpi_flags); > > printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc= ); > > } > > + > > + gicv3_its_collect_fw_attrs(hw_its); > > } > > > > uint64_t gicv3_mem_get_cacheability(uint32_t flags) > > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > > index accfd48a74..1cf49430ea 100644 > > --- a/xen/arch/arm/gic-v3-lpi.c > > +++ b/xen/arch/arm/gic-v3-lpi.c > > @@ -7,7 +7,9 @@ > > * Copyright (C) 2016,2017 - ARM Ltd > > */ > > > > +#include > > #include > > +#include > > #include > > #include > > #include > > @@ -102,6 +104,20 @@ void __init gicv3_lpi_update_host_flags(uint32_t f= lags) > > host_lpi_flags |=3D flags; > > } > > > > +static void __init gicv3_lpi_collect_fw_attrs(void) > > +{ > > + /* > > + * A top-level GIC node property describes the Redistributor side = of the > > + * LPI path. Do not inherit it into per-ITS policy. > > + */ > > + if ( !acpi_disabled || > > + !dt_property_read_bool(dt_interrupt_controller, "dma-noncoher= ent") ) > > + return; > > + > > + gicv3_lpi_update_host_flags(GICV3_QUIRK_MEM_NC_NS); > > + printk("GICv3: Redistributors marked dma-noncoherent\n"); > > +} > > + > > static union host_lpi *gic_get_host_lpi(uint32_t plpi) > > { > > union host_lpi *block; > > @@ -443,7 +459,7 @@ integer_param("max_lpi_bits", max_lpi_bits); > > * to the page with the actual "union host_lpi" entries. Our LPI limit > > * avoids excessive memory usage. > > */ > > -int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) > > +int __init gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits) > > Spurious change? This is intentional. This patch adds a call to the __init helper gicv3_lpi_collect_fw_attrs(). gicv3_lpi_init_host_lpis() is only called during boot, from gicv3_its_init(), so I marked it __init as well. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Thu Sep 24 07:54:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 07:54:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431828.1653557 (Exim 4.92) (envelope-from ) id 1x9eHg-0005BK-HA; Thu, 24 Sep 2026 07:54:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431828.1653557; Thu, 24 Sep 2026 07:54:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9eHg-0005BD-Dc; Thu, 24 Sep 2026 07:54:24 +0000 Received: by outflank-mailman (input) for mailman id 1431828; Thu, 24 Sep 2026 07:54:23 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9eHe-0005Ar-Ud for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 07:54:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9eHd-00FW57-N2 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 09:54:21 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4d71d-8faa-0a2a0a5109dd-0a2a4501e920-40 for ; Thu, 24 Sep 2026 09:54:21 +0200 Received: from [52.101.84.95] (helo=DB3PR0202CU003.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4d72d-5984-0a2a45010019-3465545f09a1-3 for ; Thu, 24 Sep 2026 09:54:21 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by AS8PR03MB8003.eurprd03.prod.outlook.com (2603:10a6:20b:42a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 07:54:17 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 07:54:17 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PA8z55Yfn74HEXNG23Bti/YccpYofOfLjoWASk3MC4bUYCRq0qNxDZw74Iax8nsyHlffs4dyryw23yjGaJgxh+JSA16i5p/bB2IwNMyn3Dd2psNQaBTnJIt+XVnrFZJsUqdLcH4OQfmqs9Dq6J1pNhpURm05sVyEj43wTKgwRwGJRdORdUW49AZ56Yk1QR8fgYsMKNYKaTt3qvjPqoLe7LR3jcLxTbSKySNQaaX0mL6xarxWVd4qUeLw8wwSnIgik8v/O2xAsnFCNv2+cnDKMyf341kgVdOqHACjf3zrcJHL9xVGthjWIH49u5/HJj7xYIdmewoLZCzk2x3HU3xClw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9FhQPIO1GRiS1wKCVWVqmGcJmf9QwCdF6Y+N4xOUS20=; b=S1S9nXJ3gmCw2i+dZtX/wSj0omID1StRrj3s1CoVy390kEaRJxwkyDNQgBQDDJC7y3gKcRGX00rurMbf7s5Q1J11hxlqCuOVN39k64U2my0dEFeMnSgsZ2nREe8UUHbwu1clYl3aKpzf7veVISnugmz0EQsId/pX5coUTcY9DnyqDBaaVVOwNE5zEGhhsfF4QiJSiQ5f29Y0dgxsFovBJ3SWQNSLz0T0VTtdbQR4cc4sJ8oGOrmqbC+F5+k/mbS7Ux2M8Zh2KERBdqS4btodUXo3vPH7bCJReQ8zCbePOuMgRYx1JWTtk7r6jTbKXBZg29WCrrhnCbe+6lqB4N4L5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9FhQPIO1GRiS1wKCVWVqmGcJmf9QwCdF6Y+N4xOUS20=; b=qtr+Zx83ONOSGqna/tZlSC0t+ApdmBgt3497O2gXU9Vfq3UZ5vetMzZa1G71Dd2pJw40z3pCSN0M8zGx99xmXSsdOVBG+aWprPOKOXHj59MqVMevVv8yjYhqTO5Zeu82ha02tE8JISu1/aEIUDUHTpFhsarUcQ2ybwXwDzNgsw1Jc/t5cP9xcGZmzFqE6OJ2OD3TJrPcbrYboj6SJpBY40AkYbl//xr6vdKqjNu+dlLbpvsukuPfnHWo2j45D+3Hjpg/wHxVR3un3g4KlXUI/68NbChQqsYHTmzGIK/U7mtyb4+v5D01XyZ+VeVg6gH0XnVOCPW2Kga2/yS09kc+lQ== From: Oleksii Moisieiev To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Grygorii Strashko Subject: Re: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdSqBOtjSUOlH6/km+/eJYUhrZf7bdXooA Date: Thu, 24 Sep 2026 07:54:17 +0000 Message-ID: References: <5c3ae163d21f619bf25c8757232a1a0867c3eb87.1790087968.git.oleksii_moisieiev@epam.com> <87pky43hm2.fsf@epam.com> <63f4841c-fb36-40c4-b96e-4a1aed95fbda@epam.com> <878q4r30wy.fsf@epam.com> In-Reply-To: <878q4r30wy.fsf@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|AS8PR03MB8003:EE_ x-ms-office365-filtering-correlation-id: becfc9c3-0c48-40d5-4fea-08df1a1108e7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|7416014|376014|38070700021|56012099006|3023799007|6133799003|10067099003|11063799006|4143699003|22082099003|18002099003; x-microsoft-antispam-message-info: wHKDSXftNrsrzoXp3YWgTKjfkegpTYkL1p30L+S5PjvnaU1f2NkPoulnd+vILqiGKdxeJB2cMNSQiI61qubpYQXPu+9vyMTHXH9juvzPWliummGWhKgjLTS/ObIA+pZkFNOb3uPCD9kvmNj0O1zJq7RU8R/vVMieQX748RzJixdDnhGzkN8vxL7RM5NsDPtPsr444mNv+fFyONj0/seVVPl6jd4h3bilVy6hWyj5tnRfSOdtxBk4Q8T4zRgpBEHQf5xUS4ZwteVShZATF7NP5cA1Gk9FOdnDi6e4SdEZLVwoHvJuZCgRHyeuek8HxNPmuK7s6YtLeIqmQhV8tb2Ibvfnp1d4EDgAWKKALDTp2sxLoNQfFefCDffPKG8095aS67PcdtVD0VzcrH8TXwRfhQmdy9E0r9SQjI9pI3tCVT5g2XgWuaBqm0IC8AqLXwZ/GRVQq4bcWb2lsbDTxXFaSGHGBSEt/3MSQqj2IicIKnFLgAk+1ALBb8aogoHU9UmekfHpyiweXdF5pzpVIYjF+OnujT6TrsUc7DtklIgcGExaNCjlhpS8mzKsaL6WLRGWJEW/92y2Ae+crRK+nl13+mA9xJq9w7/LIR0J+xmIcmfioVWSBnAbvQKRTqc6OcQfhaHt/otpoaAjo3nbkLATgd/g8oguQtJKmCEu8lUozUo9fm3L80l72QwHHw26NvsVCRoyicsxV371ApfvT2Thllw18kblEgYTLjRKgSiU+sM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(7416014)(376014)(38070700021)(56012099006)(3023799007)(6133799003)(10067099003)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WVlsbWpPWmxNL2xSazVSdGV1U3NpZ3dWbFRXTkx1SVBuT3Jhd29wMGhCSW40?= =?utf-8?B?MDl0ekxIWWpVbjU1T1ZJOWZRNVVtSTc0RjlheTdOZkhkMTM4V1VyaTRNd1hH?= =?utf-8?B?U0Z6ZjNWeFA1NmlueFNXQjJBcG8rVXptRG5hWXRLSHpJUk5QdElTQTl5RG8z?= =?utf-8?B?VWhuYXluWWxWRUVuYVdJTi8wZlY1UFZLS280MTJrd01nZkdUSnBDN3RzakVI?= =?utf-8?B?bmFyVU1UazlDYklTR1pMY0N0RDVUMmxoR2pJMTlLVzFNbjVGK1BiVHppQk80?= =?utf-8?B?ZnpOT2puUytBODdMbGFHa1o1VG1hZXNaMXhWVGZJbzJMcy8xRldhN3JNdllL?= =?utf-8?B?QTBZSjJuYVFHRDdqd2cvK1lCZ1F3VGUxdndjVWJEdXJ4b2cwZVJIUW0vUDhX?= =?utf-8?B?L3A0WFIvZ1p2SGFvUkVJdGN1U1B0Qi8xUkM2NGFjUFhyQTRoRzRQa0pCWE82?= =?utf-8?B?YldHaWRkWlRUSnhzeEtrSVNZSjE0Skk1WElpVGJXSHREMjVSUWp1Y3ZoRVV1?= =?utf-8?B?OGFjd0tBaUltMEJ4N3ZkWVM1ZFN3a0hkQUJRc1FXZzd0VzJXeFlmejJwR0RQ?= =?utf-8?B?ZnI0NmtudmIvanFoY0QvUkgrV0czNUtGc3Fhb0c0TldnNmR2c2pDTDBXVWly?= =?utf-8?B?UDZJMHZUalFWbFZZRVRSV3V3YitsMExFU3c0c2s4UDgxY1NlVTdDTEYxUi9Y?= =?utf-8?B?S25SQy95U2xvY3F4Kzh3N28xbzRFZExEU25GTXQxQWVzZHIxMmlicnovTzd0?= =?utf-8?B?TVhBUWh0M29kZHJEWTRzZ1FnaDlmSUVWNGFQLzl6YjlVMTUrWEpISDdjbWlj?= =?utf-8?B?cHpyQ1VZREMyMTBSd0oxdEZ5SmNvUnk1bG4yUlZVWi9vTTRod09ON3dxRU9H?= =?utf-8?B?OGdtWFIxdXVGUWI2akRRaGF5ZmF0Sy9DS055TUJGbDRsbzRtbWtKMmdYeWRI?= =?utf-8?B?QSt6WWtmRUsrZC85NEFLeWhaU0kzRk9TWnlLNWRYbDdtTncwMDR1NGZ1Z0g1?= =?utf-8?B?U3BRcmFCUmE4RUpPNHNnRzBxZ0V6bUNzYUtsQlJWMlVzWGc4RHM3bWxFWUwy?= =?utf-8?B?VXhyYUVDalhMT00vRk40eXRqRUY0UUxmaDVKOHBVRlI4VGl3SGlGL0cvSzJx?= =?utf-8?B?QW80UDN6NWlUWDFOT3pZS2ZKUzUxWi9hTEFjWVlOZ2wwZGtEWVk5YlZUQjJh?= =?utf-8?B?WmhPZ3ZOYnJJWCtOWkxlWE4vaGJtNlFOU1VQYmt2V2ZPMlZEN0tsbVF5ZTJk?= =?utf-8?B?L2xrRWcwcExwZTlXa05WbEhTbkhOay9nN3I4K2lYNDJheGh0SmdrblNOeTZp?= =?utf-8?B?TzNEZnFHMFE5dVB6ZjV1eVVKSUZIWUdNREw4L3gxcFE0cWw3MGU3bXZWUity?= =?utf-8?B?U2ZYdWZNSmsvN3pVdDM4OFZXbW51REpHYng4SnVPWU8vcFc4NTYzdmVGUXRU?= =?utf-8?B?RTJlZ3BHVXZIWDZmb2JVbVpkMU5VWDJUN2lMY25BSS9rbkRMUFU3VmcwZmgy?= =?utf-8?B?TXRQRmx5UXY0c0M5U1BldnEzN2I0S0FnTCt3SVRqSXMvN25zOXZ4NGhPNStN?= =?utf-8?B?OFE5dElBZnJkTjg4dmtEWmx2MGhsWWRaZ0ZKUHNrdE9NNVZZbTRKU1hWd1lN?= =?utf-8?B?K3V5M2NpVjZjSWt6UW9qYURQS0tkN25OMHNRYmUzSllUMzhGK1l4Zkt2NXZj?= =?utf-8?B?TEZLcE9McXlMV0JYZ0FMWmNBMHgxZGpaR3B2Q01zU2dxQ1FoT1dVa3JlVzdt?= =?utf-8?B?dHY5anhiY3VKN1JCVGNQWmp3MGZiaDFzaTIrZDZORXVqYmVpS3FwZk5nNG8z?= =?utf-8?B?STlWeS9FODJKQWUvYXhMdkxhL25uSThqTXFhbXA2VXVMRXhscGVWbGNBN1RD?= =?utf-8?B?ZmpaZUw4ZDl1TEduZ3MreEZ1UjVjdmFUcUJHdzdMdXJ2azUvQ1JodGVnTXZz?= =?utf-8?B?V2F1NlJzaVBlSDFwVm5hRkgwbmoycFUyeWplWnFNNDBnRWxuVWtEaHZjaC90?= =?utf-8?B?d1hxYnE1OXBrZTlvNXV5L1JkcFU5c2RGeDBkUkxvQkVNd3ZKV2d0MExGd1M4?= =?utf-8?B?L0ZHbFhkL2Zia1JUN3B1dkl2SFYvVThOVlBBS24xblFVcjNmWnJyTmMzWG4r?= =?utf-8?B?cTZobzhKSkhocVhjdld0ZlNZSFFjdFZwalBuaEV3VHB6ZnBPN3JGbTdXT1N6?= =?utf-8?B?dGRHOEtYcFhtcE5JU2RyWjArdzkwSXVJTGtiSTU3RDg5TXFSQUlzTHdkWkRp?= =?utf-8?B?aTZtV0kwK3ZnTkQzaGFvYVUvMlo3WUc4c1ZVT1d5Wm43aTZoZXVSWmRuMzJo?= =?utf-8?B?M2JxK1RaYzdlaHdQakhubFhGcTdRUGVIU0gydjBIczZnZHh6UzhBMlRLZVg3?= =?utf-8?Q?YIvpEpEJSPJmvpl4=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <77201724E15D1149B9DE6CE3B19268E3@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: becfc9c3-0c48-40d5-4fea-08df1a1108e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2026 07:54:17.5848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OrKqKuJXYl8gBOAJKDf2MkxS2cB9kbHmjWjNb1ZX/EFFHnQHu0/FVIzgiI5mbBoY2J+I7zsGCtEgrovdfMRbzCKv9xomeB3ep7lvAfU4pSE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8003 X-purgate-ID: tlsNG-d62444/1790236461-BDE78757-B328ADE1/0/0 X-purgate-type: clean X-purgate-size: 18926 DQpPbiAyNC8wOS8yMDI2IDA0OjE1LCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4gSGkgT2xl a3NpaSwNCj4NCj4gT2xla3NpaSBNb2lzaWVpZXYgPE9sZWtzaWlfTW9pc2llaWV2QGVwYW0uY29t PiB3cml0ZXM6DQo+DQo+PiBPbiAyMy8wOS8yMDI2IDA0OjAyLCBWb2xvZHlteXIgQmFiY2h1ayB3 cm90ZToNCj4+PiBIaSBPbGVrc2lpLA0KPj4+DQo+Pj4gT2xla3NpaSBNb2lzaWVpZXYgPE9sZWtz aWlfTW9pc2llaWV2QGVwYW0uY29tPiB3cml0ZXM6DQo+Pj4NCj4+PiBUaGlzIGlzIGEgZ3JlYXQg cGllY2Ugb2YgZG9jdW1lbnRhdGlvbi4gSXQgaXMgbGFyZ2VyIHRoYW4gdGhlIHRleHQgeW91DQo+ Pj4gYWRkZWQgdG8gdGhlICdkb2MnIGRpcmVjdG9yeS4gU28gSSBiZWxpZXZlIGl0IGlzIGJldHRl ciB0byBwdXQgaW50byBhDQo+Pj4gZGVzaWduIGRvY3VtZW50LCBzbyBpdCBpcyB3aWxsIG5vdCBi ZSBsb3N0IGluIHRoZSBnaXQgY29tbWl0IG1lc3NhZ2VzLg0KPj4gSGkgVm9sb2R5bXlyLA0KPj4N Cj4+IFRoYW5rIHlvdSBmb3IgYSBxdWljayByZXNwb25zZS4NCj4+DQo+PiBJJ3ZlIGp1c3QgcmVj aGVrZWQgZG9jdW1lbnQgaW4gcGF0Y2ggNjoNCj4+IGRvY3MvaHlwZXJ2aXNvci1ndWlkZS9hcm0v ZmlybXdhcmUvYXJtLXNjbWkucnN0IGFuZA0KPj4NCj4+IGNvbXBhcmVkIGl0IHdpdGggdGhlIGlu Zm9ybWF0aW9uIHByb3ZpZGVkIGluIHRoZSBjb21taXQgZGVzY3JpcHRpb24uDQo+Pg0KPj4gQXMg SSBjYW4gc2VlIGFsbCBpbmZvcm1hdGlvbiBwcm92aWRlZCBpbiB0aGUgZGVzY3JpcHRpb24gKGFk ZCBzY2hlbWVzDQo+PiBhbmQgZHRzIGV4YW1wbGVzIGF0IGxlYXN0KQ0KPj4NCj4+IGFyZSBwcmVz ZW50IGluIHRoZSBkb2N1bWVudGF0aW9uLiBBbHNvIGRvYyBpdHNlbGYgaXMgbW9yZSBkZXRhaWxl ZCB0aGVuDQo+PiB0aGUgY29tbWl0IGRlc2NyaXB0aW9uLg0KPj4NCj4+IE1heWJlIEkgbWlzc2Vk IHNvbWV0aGluZz8NCj4gQWgsIHNvIHlvdSBwdXQgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUgbGFz dCBwYXRjaCBpbiB0aGUgc2VyaWVzLiBPa2F5LA0KPiBzbyBJIG1pc3NlZCBpdC4NCj4NCj4+Pj4g VGhpcyBwYXRjaCBpbnRyb2R1Y2VzIFNDSSBkcml2ZXIgdG8gc3VwcG9ydCBmb3IgQVJNIEVMMyBU cnVzdGVkIEZpcm13YXJlLUENCj4+Pj4gKFRGLUEpIHdoaWNoIHByb3ZpZGVzIFNDTUkgaW50ZXJm YWNlIHdpdGggbXVsdGktYWdlbnQgc3VwcG9ydCwgYXMgc2hvd24NCj4+Pj4gYmVsb3cuDQo+Pj4+ DQo+Pj4+ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ Pj4+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+ ICAgICB8IEVMMyBURi1BIFNDTUkgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+ICAg ICArLS0tLS0tLSstLSstLS0tLS0tKy0tKy0tLS0tLS0rLS0rLS0tLS0tLSsrDQo+Pj4+ICAgICB8 c2htZW0xIHwgIHxzaG1lbTAgfCAgfHNobWVtMiB8ICB8c2htZW1YIHwNCj4+Pj4gICAgICstLS0t LSstKyAgKy0tLSstLS0rICArLS0rLS0tLSsgICstLS0rLS0tKw0KPj4+PiBzbWMtaWQxIHwgICAg ICAgIHwgICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4+IGFnZW50MSAgfCAgICAgICAgfCAgICAg ICAgIHwgICAgICAgICAgIHwNCj4+Pj4gICAgICstLS0tLXYtLS0tLS0tLSstLS0tLS0tLS0rLS0t LS0tLS0tLS0rLS0tLSsNCj4+Pj4gICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICB8ICAgIHwNCj4+Pj4gICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAg ICB8ICAgIHwNCj4+Pj4gICAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0r LS0tLSsNCj4+Pj4gICAgICAgICAgICBzbWMtaWQwIHwgIHNtYy1pZDJ8ICAgIHNtYy1pZFh8DQo+ Pj4+ICAgICAgICAgICAgYWdlbnQwICB8ICBhZ2VudDIgfCAgICBhZ2VudFggfA0KPj4+PiAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwNCj4+Pj4gICAgICAgICAgICAg ICArLS0tLXYtLS0rICArLS12LS0tLS0rICArLS12LS0tLS0rDQo+Pj4+ICAgICAgICAgICAgICAg fCAgICAgICAgfCAgfCAgICAgICAgfCAgfCAgICAgICAgfA0KPj4+PiAgICAgICAgICAgICAgIHwg RG9tMCAgIHwgIHwgRG9tMSAgIHwgIHwgRG9tWCAgIHwNCj4+Pj4gICAgICAgICAgICAgICB8ICAg ICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+Pj4+ICAgICAgICAgICAgICAgfCAgICAg ICAgfCAgfCAgICAgICAgfCAgfCAgICAgICAgfA0KPj4+PiAgICAgICAgICAgICAgICstLS0tLS0t LSsgICstLS0tLS0tLSsgICstLS0tLS0tLSsNCj4+Pj4NCj4+Pj4gVGhlIEVMMyBTQ01JIG11bHRp LWFnZW50IGZpcm13YXJlIGlzIGV4cGVjdGVkIHRvIHByb3ZpZGUgU0NNSSBTTUMgc2hhcmVkDQo+ Pj4+IG1lbW9yeSB0cmFuc3BvcnQgZm9yIGV2ZXJ5IEFnZW50IGluIHRoZSBzeXN0ZW0uDQo+Pj4+ DQo+Pj4+IFRoZSBTQ01JIEFnZW50IHRyYW5zcG9ydCBjaGFubmVsIGRlZmluZWQgYnkgcGFpcjoN Cj4+Pj4gICAgLSBzbWMtaWQ6IFNNQyBpZCB1c2VkIGZvciBEb29yYmVsbA0KPj4+PiAgICAtIHNo bWVtOiBzaGFyZWQgbWVtb3J5IGZvciBtZXNzYWdlcyB0cmFuc2ZlciwgWGVuIHBhZ2UNCj4+Pj4g ICAgYWxpZ25lZC4gU2hhcmVkIG1lbW9yeSBpcyBtYXBwZWQgd2l0aCB0aGUgZm9sbG93aW5nIGZs YWdzOg0KPj4+PiAgICBNVF9ERVZJQ0VfbkduUkUuDQo+Pj4+DQo+Pj4+IFRoZSBmb2xsd29pbmcg U0NNSSBBZ2VudHMgYXJlIGV4cGVjdGVkIHRvIGJlIGRlZmluZWQgYnkgU0NNSSBGVyB0byBlbmFi bGUgU0NNSQ0KPj4+PiBtdWx0aS1hZ2VudCBmdW5jdGlvbmFsaXR5IHVuZGVyIFhlbjoNCj4+Pj4g LSBYZW4gbWFuYWdlbWVudCBhZ2VudDogdHJ1c3RlZCBhZ2VudHMgdGhhdCBhY2Nlc3NlcyB0byB0 aGUgQmFzZSBQcm90b2NvbA0KPj4+PiBjb21tYW5kcyB0byBjb25maWd1cmUgYWdlbnQgc3BlY2lm aWMgcGVybWlzc2lvbnMNCj4+Pj4gLSBPU1BNIFZNIGFnZW50czogbm9uLXRydXN0ZWQgYWdlbnQs IG9uZSBmb3IgZWFjaCBHdWVzdCBkb21haW4gd2hpY2ggaXMNCj4+Pj4gICAgIGFsbG93ZWQgZGly ZWN0IEhXIGFjY2Vzcy4gQXQgbGVhc3Qgb25lIE9TUE0gVk0gYWdlbnQgaGFzIHRvIGJlIHByb3Zp ZGVkDQo+Pj4+ICAgICBieSBGVyBpZiBIVyBpcyBoYW5kbGVkIG9ubHkgYnkgRG9tMCBvciBEcml2 ZXIgRG9tYWluLg0KPj4+Pg0KPj4+PiBUaGUgRUwzIFNDTUkgRlcgaXMgZXhwZWN0ZWQgdG8gaW1w bGVtZW50IGZvbGxvd2luZyBCYXNlIHByb3RvY29sIG1lc3NhZ2VzOg0KPj4+PiAtIEJBU0VfRElT Q09WRVJfQUdFTlQgKG9wdGlvbmFsIGlmIGFnZW50X2lkIHdhcyBwcm92aWRlZCkNCj4+Pj4gLSBC QVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT04gKG9wdGlvbmFsKQ0KPj4+PiAtIEJBU0VfU0VU X0RFVklDRV9QRVJNSVNTSU9OUyAob3B0aW9uYWwpDQo+Pj4+DQo+Pj4+IFRoZSBTQ0kgU0NNSSBT TUMgbXVsdGktYWdlbnQgZHJpdmVyIGltcGxlbWVudHMgZm9sbG93aW5nDQo+Pj4+IGZ1bmN0aW9u YWxpdHk6DQo+Pj4+IC0gVGhlIGRyaXZlciBpcyBpbml0aWFsaXplZCBmcm9tIHRoZSBYZW4gU0NN SSBjb250YWluZXIgYGB4ZW5fc2NtaV9jb25maWdgYA0KPj4+PiAgICAgKGNvbXBhdGlibGUgYGB4 ZW4sc2NpYGApIHBsYWNlZCB1bmRlciBgYC9jaG9zZW4veGVuYGAuIE9ubHkgdGhlDQo+Pj4+ICAg ICBgYGFybSxzY21pLXNtY2BgIG5vZGUgdGhhdCBpcyBhIGNoaWxkIG9mIHRoaXMgY29udGFpbmVy IHdpbGwgYmluZCB0byBYZW47DQo+Pj4+ICAgICBvdGhlciBTQ01JIG5vZGVzIChmb3IgZXhhbXBs ZSB1bmRlciBgYC9maXJtd2FyZWBgKSBhcmUgaWdub3JlZCB0byBhdm9pZA0KPj4+PiAgICAgc3Rl YWxpbmcgdGhlIGhvc3QgT1NQTSBpbnN0YW5jZS4NCj4+Pj4NCj4+Pj4gc2NtaV9zaG1fMTogc3Jh bUA0N2ZmMTAwMCB7DQo+Pj4+ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2ht ZW0iOw0KPj4+PiAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47 DQo+Pj4+IH07DQo+Pj4+IHNjbWlfeGVuOiBzY21pIHsNCj4+Pj4gICAgICAgICAgIGNvbXBhdGli bGUgPSAiYXJtLHNjbWktc21jIjsNCj4+Pj4gICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAw MDAwMz47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgc21jLWlkDQo+Pj4+ICAgICAgICAgICAj YWRkcmVzcy1jZWxscyA9IDwgMT47DQo+Pj4+ICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwgMD47 DQo+Pj4+ICAgICAgICAgICAjYWNjZXNzLWNvbnRyb2xsZXItY2VsbHMgPSA8IDE+Ow0KPj4+PiAg ICAgICAgICAgc2htZW0gPSA8JnNjbWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50 IHNobWVtDQo+Pj4+IH07DQo+Pj4+DQo+Pj4+IC0gVGhlIGRyaXZlciBvYnRhaW5zIFhlbiBzcGVj aWZpYyBTQ01JIEFnZW50J3MgY29uZmlndXJhdGlvbiBmcm9tIHRoZQ0KPj4+PiAgICAgSG9zdCBE VCwgcHJvYmVzIEFnZW50cyBhbmQgYnVpbGRzIFNDTUkgQWdlbnRzIGxpc3QuIFRoZSBBZ2VudHMN Cj4+Pj4gICAgIGNvbmZpZ3VyYXRpb24gaXMgdGFrZW4gZnJvbSAic2NtaS1zZWNvbmRhcnktYWdl bnRzIiBwcm9wZXJ0eSB3aGVyZQ0KPj4+PiAgICAgZmlyc3QgaXRlbSBpcyAiYXJtLHNtYy1pZCIs IHNlY29uZCAtICJhcm0sc2NtaS1zaG1lbSIgcGhhbmRsZSBhbmQNCj4+Pj4gICAgIHRoaXJkIGlz IG9wdGlvbmFsICJhZ2VudF9pZCI6DQo+Pj4+DQo+Pj4+IC8gew0KPj4+PiAgICAgY2hvc2VuIHsN Cj4+Pj4gICAgICAgeGVuIHsNCj4+Pj4gICAgICAgICByYW5nZXM7DQo+Pj4+ICAgICAgICAgeGVu X3NjbWlfY29uZmlnIHsNCj4+Pj4gICAgICAgICAgIGNvbXBhdGlibGUgPSAieGVuLHNjaSI7DQo+ Pj4+ICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwyPjsNCj4+Pj4gICAgICAgICAgICNzaXpl LWNlbGxzID0gPDI+Ow0KPj4+PiAgICAgICAgICAgcmFuZ2VzOw0KPj4+Pg0KPj4+PiAJc2NtaS1z ZWNvbmRhcnktYWdlbnRzID0gPA0KPj4+PiAgICAgICAgICAgICAweDgyMDAwMDAyICZzY21pX3No bV8wIDANCj4+Pj4gICAgICAgICAgICAgMHg4MjAwMDAwNCAmc2NtaV9zaG1fMiAyDQo+Pj4+ICAg ICAgICAgICAgIDB4ODIwMDAwMDUgJnNjbWlfc2htXzMgMz47IDwtLS0gZnVuY19pZCwgc2htZW0s IGFnZW50X2lkDQo+Pj4+ICAgICAgICAgICAjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzID0g PDM+Ow0KPj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIHRoZSBjb3JyZWN0IHdheSBvZiB1 c2luZyAtY2VsbHMgcHJvcGVydHkuDQo+Pj4NCj4+PiBUaGVzZSBwcm9wZXJ0aWVzIGFyZSB1c2Vk IGVpdGhlciB0byBwcm92aWRlIGluZm9ybWF0aW9uIGZvciAqKmNoaWxkKiogbm9kZXMNCj4+PiAo bGlrZSAjYWRkcmVzcy1jZWxscyBvciAjc2l6ZS1jZWxscykgb3IgdG8gcHJvdmlkZSBhIG51bWJl ciBvZiBjZWxscyB0bw0KPj4+IGVuY29kZSBhIHNwZWNpZmllciBmb3IgYSBkb21haW4gKGxpa2Ug I2ludGVycnVwdC1jZWxscykuDQo+Pj4NCj4+PiBIZXJlIHlvdSBhcmUgZG9pbmcgbmVpdGhlciBv ZiB0aGVzZS4gSSB0aGluayB0aGUgcHJvcGVyIHdheSBpcyB0byBkZWZpbmUNCj4+PiBzZWNvbmRh cnkgYWdlbnRzIGFzIGNoaWxkcmVuOg0KPj4+DQo+Pj4gYWdlbnRzIHsNCj4+PiAgICAgICAgICAg I2FkZHJlc3MtY2VsbHMgPSAxOw0KPj4+ICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDA7DQo+Pj4g ICAgICAgICAgICBzY21pX2FnZW50XzI6IHNjbWlfYWdlbnRAMiB7DQo+Pj4gICAgICAgICAgICAg IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktYWdlbnQiOyAgLy8gQWN0dWFsbHksIEkgYW0gbm90IHN1 cmUgaWYNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAv LyB3ZSBhbGxvd2VkIHRvIHVzZSAnYXJtJyBuYW1lc3BhY2UNCj4+Pg0KPj4+ICAgICAgICAgICAg ICByZWcgPSA8Mj47ICAgICAgICAgICAgICAgICAgICAgIC8vIEFnZW50IGlkIGdvZXMgaGVyZQ0K Pj4+ICAgICAgICAgICAgICBzaG1tZW0gPSAmc2NtaV9zaG1fMjsNCj4+PiAgICAgICAgICAgICAg YXJtLHNtYy1pZCA9IDB4ODIwMDAwMDQ7DQo+Pj4gICAgICAgICAgICB9Ow0KPj4+IH0NCj4+Pg0K Pj4+IFdpdGggdGhpcyBhcHByb2FjaCB5b3UgZG9uJ3QgbmVlZCAjc2NtaS1zZWNvbmRhcnktYWdl bnRzLWNlbGxzIGF0IGFsbA0KPj4+IGFuZCB0aGUgd2hvbGUgc3RydWN0dXJlIGJlY29tZXMgbW9y ZSBkZXZpY2UtdHJlZS1pc2guDQo+PiBUaGFuayB5b3UgZm9yIGxvb2tpbmcgYXQgdGhpcy4gSSBh Z3JlZSB0aGF0IHRoZSB0d28gY2FzZXMgeW91IGxpc3QgYXJlDQo+PiB0aGUgbW9zdCBjb21tb24g b25lcywgYnV0IHRoZXkgYXJlIG5vdCB0aGUgb25seSBzYW5jdGlvbmVkIG9uZXM6IHRoZXJlIGlz IGENCj4+IHRoaXJkLCBsb25nLXN0YW5kaW5nIHBhdHRlcm4gd2hlcmUgYSAiIzxuYW1lPi1jZWxs cyIgcHJvcGVydHkgaW4gYSBub2RlDQo+PiBkZWNsYXJlcyB0aGUgY2VsbCBzdHJpZGUgb2YgYSAq bm9uLXBoYW5kbGUgbGlzdCBwcm9wZXJ0eSBpbiB0aGF0IHZlcnkgc2FtZQ0KPj4gbm9kZSouIFRo YXQgaXMgZXhhY3RseSB3aGF0ICIjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzIiBkb2VzIGZv cg0KPj4gInNjbWktc2Vjb25kYXJ5LWFnZW50cyIuIFNvbWUgZXZpZGVuY2UgZnJvbSB0aGUgRGV2 aWNldHJlZSBTcGVjaWZpY2F0aW9uIGFuZA0KPj4gZnJvbSBMaW51eDoNCj4+DQo+PiAxKSAicmFu Z2VzIiBhbmQgImludGVycnVwdC1tYXAiIGFyZSBwYXJzZWQgd2l0aCB0aGUgY2VsbCBjb3VudHMg b2YgdGhlIG5vZGUNCj4+ICAgwqAgwqB0aGF0IGNhcnJpZXMgdGhlbSwgbm90IG9mIGEgY2hpbGQg b3Igb2YgYSBwaGFuZGxlIHRhcmdldC4NCj4+DQo+PiAgIMKgIMKgZHRjIGVuZm9yY2VzIHRoaXMg aXRzZWxmOg0KPj4NCj4+ICAgwqAgwqAtIHNjcmlwdHMvZHRjL2NoZWNrcy5jOjc4NSBjaGVja19y YW5nZXNfZm9ybWF0KCkgY29tcHV0ZXMgdGhlIGVudHJ5DQo+PiBsZW5ndGgNCj4+ICAgwqAgwqAg wqBhcyAocGFyZW50ICNhZGRyZXNzLWNlbGxzICsgdGhpcyBub2RlJ3MgI2FkZHJlc3MtY2VsbHMg KyB0aGlzIG5vZGUncw0KPj4gICDCoCDCoCDCoCNzaXplLWNlbGxzKSBhbmQgdmFsaWRhdGVzIHRo ZSBsZW5ndGggb2YgInJhbmdlcyIgaW4gdGhpcyBub2RlDQo+PiBhZ2FpbnN0IGl0Lg0KPj4NCj4+ ICAgwqAgwqAtIHNjcmlwdHMvZHRjL2NoZWNrcy5jOjE2MDEgY2hlY2tfaW50ZXJydXB0X21hcCgp Og0KPj4NCj4+ICAgwqAgwqAgwqAgwqAgwqBjZWxsc2l6ZSA9IG5vZGVfYWRkcl9jZWxscyhub2Rl KTsNCj4+ICAgwqAgwqAgwqAgwqAgwqBjZWxsc2l6ZSArPSBwcm9wdmFsX2NlbGwoZ2V0X3Byb3Bl cnR5KG5vZGUsICIjaW50ZXJydXB0LWNlbGxzIikpOw0KPj4NCj4+ICAgwqAgwqAgwqBpLmUuIHRo ZSBzdHJpZGUgb2YgdGhlICJpbnRlcnJ1cHQtbWFwIiBlbnRyaWVzIGluIGEgbm9kZSBpcyB0YWtl biBmcm9tDQo+PiAgIMKgIMKgIMKgIiNhZGRyZXNzLWNlbGxzIiBhbmQgIiNpbnRlcnJ1cHQtY2Vs bHMiICpvZiB0aGF0IHNhbWUgbm9kZSouIExpbnV4DQo+PiBkb2VzDQo+PiAgIMKgIMKgIMKgdGhl IHNhbWUgaW4gZHJpdmVycy9vZi9pcnEuYy4NCj4+DQo+PiAgIMKgIMKgU28gImEgIyotY2VsbHMg cHJvcGVydHkgaW4gbm9kZSBYIGRlc2NyaWJpbmcgdGhlIGxheW91dCBvZiBhIHByb3BlcnR5IGlu DQo+PiAgIMKgIMKgbm9kZSBYIiBpcyBub3QgYW4gYWJ1c2Ugb2YgdGhlIGNvbnZlbnRpb24sIGl0 IGlzIGhvdyB0d28gb2YgdGhlIGNvcmUNCj4+ICAgwqAgwqBEZXZpY2V0cmVlIFNwZWNpZmljYXRp b24gcHJvcGVydGllcyBhcmUgZGVmaW5lZC4NCj4+DQo+PiAyKSBUaGVyZSBpcyBhIHByZWNlZGVu dCB3aG9zZSBzaGFwZSBpcyBpZGVudGljYWwgdG8gb3VycyAtIGEgdmVuZG9yIHByb3BlcnR5DQo+ PiAgIMKgIMKgaG9sZGluZyBhIGxpc3QsIHBsdXMgY2VsbHMgcHJvcGVydGllcyBpbiB0aGUgc2Ft ZSBub2RlIHRoYXQgZGVzY3JpYmUNCj4+IGhvdyB0bw0KPj4gICDCoCDCoGRlY29kZSBpdDoNCj4+ DQo+PiAgIMKgIMKgRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3RwbS9pYm0sdnRw bS55YW1sOjM2DQo+Pg0KPj4gICDCoCDCoCDCoCDCoGlibSwjZG1hLWFkZHJlc3MtY2VsbHM6DQo+ PiAgIMKgIMKgIMKgIMKgIMKgZGVzY3JpcHRpb246DQo+PiAgIMKgIMKgIMKgIMKgIMKgIMKgbnVt YmVyIG9mIGNlbGxzIHRoYXQgYXJlIHVzZWQgdG8gZW5jb2RlIHRoZSBwaHlzaWNhbCBhZGRyZXNz DQo+PiBmaWVsZA0KPj4gICDCoCDCoCDCoCDCoCDCoCDCoG9mIGRtYS13aW5kb3cgcHJvcGVydGll cw0KPj4gICDCoCDCoCDCoCDCoGlibSwjZG1hLXNpemUtY2VsbHM6DQo+PiAgIMKgIMKgIMKgIMKg IMKgZGVzY3JpcHRpb246DQo+PiAgIMKgIMKgIMKgIMKgIMKgIMKgbnVtYmVyIG9mIGNlbGxzIHRo YXQgYXJlIHVzZWQgdG8gZW5jb2RlIHRoZSBzaXplIGZpZWxkIG9mDQo+PiAgIMKgIMKgIMKgIMKg IMKgIMKgZG1hLXdpbmRvdyBwcm9wZXJ0aWVzDQo+PiAgIMKgIMKgIMKgIMKgaWJtLG15LWRtYS13 aW5kb3c6DQo+PiAgIMKgIMKgIMKgIMKgIMKgZGVzY3JpcHRpb246IERNQSB3aW5kb3cgYXNzb2Np YXRlZCB3aXRoIHRoaXMgdmlydHVhbCBJL08gQWRhcHRlcg0KPj4NCj4+ICAgwqAgwqBhbmQgdGhl IGV4YW1wbGUgKHNhbWUgZmlsZSwgbGluZXMgOTYtOTgpOg0KPj4NCj4+ICAgwqAgwqAgwqAgwqBp Ym0sI2RtYS1hZGRyZXNzLWNlbGxzID0gPDB4Mj47DQo+PiAgIMKgIMKgIMKgIMKgaWJtLCNkbWEt c2l6ZS1jZWxscyA9IDwweDI+Ow0KPj4gICDCoCDCoCDCoCDCoGlibSxteS1kbWEtd2luZG93ID0g PDB4MTAwMDAwMDMgMHgwIDB4MCAweDAgMHgxMDAwMDAwMD47DQo+Pg0KPj4gICDCoCDCoEJvdGgg Y2VsbHMgcHJvcGVydGllcyBhcmUgInJlcXVpcmVkIi4gVGhlIHBhcnNlciBpcw0KPj4gICDCoCDC oGFyY2gvcG93ZXJwYy9rZXJuZWwvcHJvbV9wYXJzZS5jOjExIG9mX3BhcnNlX2RtYV93aW5kb3co KSwgd2hpY2ggcmVhZHMNCj4+ICAgwqAgwqAiaWJtLCNkbWEtYWRkcmVzcy1jZWxscyIgYW5kICJp Ym0sI2RtYS1zaXplLWNlbGxzIiBmcm9tIHRoZSBzYW1lDQo+PiBub2RlICJkbiINCj4+ICAgwqAg wqB0byB3YWxrICJpYm0sbXktZG1hLXdpbmRvdyIuIFRoZXJlIGlzIG5vIHBoYW5kbGUgYW5kIG5v IGNoaWxkIG5vZGUNCj4+ICAgwqAgwqBpbnZvbHZlZDsgdGhpcyBpcyBleGFjdGx5IHRoZSAic2Vs Zi1kZXNjcmliaW5nIGxpc3QgcHJvcGVydHkiIHBhdHRlcm4uDQo+Pg0KPj4gMykgQSAiIyotY2Vs bHMiIHByb3BlcnR5IGRvZXMgbm90IGhhdmUgdG8gZGVzY3JpYmUgYSBwaGFuZGxlIHNwZWNpZmll cg0KPj4gYXQgYWxsOg0KPj4NCj4+ICAgwqAgwqAtICIjcGluY3RybC1jZWxscyIgKERvY3VtZW50 YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9waW5jdHJsLw0KPj4gICDCoCDCoCDCoHBpbmN0cmwt c2luZ2xlLnlhbWw6NTUpIGdpdmVzIHRoZSBudW1iZXIgb2YgY2VsbHMgcGVyIGVudHJ5IG9mIHRo ZQ0KPj4gcGxhaW4NCj4+ICAgwqAgwqAgwqAicGluY3RybC1zaW5nbGUscGlucyIgcHJvcGVydHk7 IGRyaXZlcnMvcGluY3RybC9kZXZpY2V0cmVlLmM6Mjk3DQo+PiAgIMKgIMKgIMKgcGluY3RybF9m aW5kX2NlbGxzX3NpemUoKSBsb29rcyBpdCB1cCBpbiB0aGUgcGFyZW50L2dyYW5kcGFyZW50IG5v ZGUuDQo+PiAgIMKgIMKgIMKgTm8gcGhhbmRsZSBzcGVjaWZpZXIgaXMgaW52b2x2ZWQuDQo+Pg0K Pj4gICDCoCDCoC0gIiNpbmRleC1jZWxscyINCj4+IChEb2N1bWVudGF0aW9uL2RldmljZXRyZWUv YmluZGluZ3MvdXNiL2ZzbCx1c2JtaXNjLnlhbWw6NTYpDQo+PiAgIMKgIMKgIMKgaXMgbm90IGEg c3BlY2lmaWVyIGZvciBhbnkgZG9tYWluIGVpdGhlci4NCj4+DQo+PiBTbyB0aGUgY29udmVudGlv biBpbiBwcmFjdGljZSBpcyAiYSAjPGZvbz4tY2VsbHMgcHJvcGVydHkgc3RhdGVzIGhvdw0KPj4g bWFueSBjZWxscw0KPj4gb25lIDxmb28+IGVudHJ5IG9jY3VwaWVzIiwgYW5kIHRoZSBlbnRyaWVz IG1heSBsaXZlIGluIGEgY2hpbGQgbm9kZSdzDQo+PiBwcm9wZXJ0eQ0KPj4gKCNhZGRyZXNzLWNl bGxzKSwgaW4gYSBjb25zdW1lcidzIHBoYW5kbGUgc3BlY2lmaWVyICgjaW50ZXJydXB0LWNlbGxz LA0KPj4gI2Nsb2NrLWNlbGxzKSwgb3IgaW4gYSBwcm9wZXJ0eSBvZiB0aGUgZGVjbGFyaW5nIG5v ZGUgaXRzZWxmIChyYW5nZXMsDQo+PiBpbnRlcnJ1cHQtbWFwLCBpYm0sbXktZG1hLXdpbmRvdyku IE91ciB1c2FnZSBmYWxscyBpbnRvIHRoZSB0aGlyZCBncm91cC4NCj4+DQo+PiBUaGlzIGJyaW5n IHVzIHRvIHRoZSBmb2xsb3dpbmcgY29uY2x1c2lvbiB0aGF0DQo+PiAjc2NtaS1zZWNvbmRhcnkt YWdlbnRzLWNlbGxzIHVzYWdlDQo+PiBkb2Vzbid0IHRlY2huaWNhbGx5IGJyZWFrIHRoZSBkZXZp Y2UtdHJlZSBjb252ZW50aW9uIHdpdGggMiBleGNlcHRpb25zOg0KPj4NCj4+IGEpIFZlbmRvciBw cmVmaXguIERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy93cml0aW5nLWJpbmRpbmdz LnJzdDo2OA0KPj4gICDCoCDCoHNheXMgIkRPIHVzZSBhIHZlbmRvciBwcmVmaXggb24gZGV2aWNl LXNwZWNpZmljIHByb3BlcnR5IG5hbWVzIiwgYW5kIGFsbA0KPj4gICDCoCDCoHRoZSBzYW1lLW5v ZGUgcHJlY2VkZW50cyBhYm92ZSBhcmUgdmVuZG9yLXByZWZpeGVkDQo+PiAoImlibSwjZG1hLWFk ZHJlc3MtY2VsbHMiKS4NCj4+ICAgwqAgwqBCb3RoIG9mIG91ciBwcm9wZXJ0aWVzIGFyZSBYZW4t c3BlY2lmaWMgYW5kIGxpdmUgdW5kZXIgL2Nob3Nlbi94ZW4sDQo+PiBzbyBpZiB3ZQ0KPj4gICDC oCDCoGtlZXAgdGhlIGZsYXQgZm9ybSB0aGV5IHNob3VsZCBiZWNvbWUgInhlbixzY21pLXNlY29u ZGFyeS1hZ2VudHMiIGFuZA0KPj4gICDCoCDCoCJ4ZW4sI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1j ZWxscyIuDQo+Pg0KPj4gYikgRW50cnkgbGF5b3V0LiBJbiBvdXIgbGlzdCB0aGUgcGhhbmRsZSBp cyB0aGUgc2Vjb25kIGNlbGwNCj4+ICAgwqAgwqAoPHNtYy1pZCAmc2htZW0gYWdlbnQtaWQ+KSwg d2hpY2ggcHJldmVudHMgdGhlIHVzZSBvZiB0aGUgc3RhbmRhcmQNCj4+ICAgwqAgwqBwaGFuZGxl LWFycmF5IGhlbHBlcnMgLSB0aGV5IGFsbCBleHBlY3QgdGhlIHBoYW5kbGUgZmlyc3QuIElmIHdl DQo+PiBrZWVwIHRoZQ0KPj4gICDCoCDCoGZsYXQgZm9ybSwgcmVvcmRlcmluZyB0byA8JnNobWVt IHNtYy1pZCBhZ2VudC1pZD4gd291bGQgbGV0IHRoZQ0KPj4gcHJvcGVydHkgYmUNCj4+ICAgwqAg wqBwYXJzZWQgYXMgYW4gb3JkaW5hcnkgcGhhbmRsZS1hcnJheS4NCj4+DQo+PiBBcyBmb3IgeW91 ciBwcm9wb3NhbDogdGhlIGNoaWxkLW5vZGUgZm9ybSB5b3Ugc3VnZ2VzdCBpcyBjZXJ0YWlubHkN Cj4+IG1vcmUgaWRpb21hdGljLCBpdCBtYWtlcyB0aGUgYWdlbnQgaWQgYW4gYWRkcmVzc2FibGUg InJlZyIgYW5kIGl0DQo+PiByZW1vdmVzIHRoZQ0KPj4gb3B0aW9uYWwgMi12cy0zLWNlbGxzIHZh cmlhbnQgYWx0b2dldGhlci4gTXkgb25seSByZXNlcnZhdGlvbnMgYXJlIHRoYXQNCj4+IGl0IGdy b3dzDQo+PiB0aGUgWGVuIERUIHBhcnNlciAobm9kZSBpdGVyYXRpb24gaW5zdGVhZCBvZiBhIHNp bmdsZSBwcm9wZXJ0eSB3YWxrKSBhbmQNCj4+IHRoYXQgdGhlDQo+PiBjb21wYXRpYmxlIHN0cmlu ZyB3b3VsZCBuZWVkIGEgbmFtZXNwYWNlIHdlIG93biAoInhlbixzY21pLWFnZW50IiByYXRoZXIN Cj4+IHRoYW4NCj4+ICJhcm0sc2NtaS1hZ2VudCIsIGFzIHlvdSBjb3JyZWN0bHkgc3VzcGVjdGVk KS4NCj4+DQo+PiBTbyBJIGRvIG5vdCB0aGluayB0aGUgY3VycmVudCBmb3JtIGlzIGludmFsaWQs IGJ1dCBJIGhhdmUgbm8gb2JqZWN0aW9uIHRvDQo+PiBtb3ZpbmcgdG8gY2hpbGQgbm9kZXMgaWYg eW91IHByZWZlciBpdC4gUGxlYXNlIGxldCBtZSBrbm93IHdoaWNoIHdheSB5b3UNCj4+IHdvdWxk DQo+PiBsaWtlIG1lIHRvIGdvIGZvciB2MTQgYW5kIEkgd2lsbCByZXNwaW4gYWNjb3JkaW5nbHku DQo+IFllcywgSSB0aGluayBtb3JlIGlkaW9tYXRpYyBmb3JtYXQgaXMgYmV0dGVyLiBBbHNvLCB5 b3UgbmVlZCB0byB3cml0ZSBhDQo+IHBhcnNlciBvbmNlLCBidXQgdXNlcnMgd2lsbCB3cml0ZSBk ZXZpY2UgdHJlZSBtb3JlIG9mdGVuLg0KPg0KPiBUaGUgc2Vjb25kIHRoaW5nIHRoYXQgYm90aGVy cyBtZSBpcyB0aGUgc2hhcmVkIG1lbW9yeSBub2RlcyBpbnNpZGUgdGhlDQo+IHhlbl9zY21pX2Nv bmZpZyBub2RlLiBJIGJlbGlldmUgdGhleSBzaG91bGQgYmVsb25nIHRvIHJlc2VydmVkX21lbW9y eSwgbm8/DQpEdXJpbmcgZGlzY3Vzc2lvbnMgb24gdGhlIHByZXZpb3VzIHZlcnNpb25zLCBpdCB3 YXMgZGVjaWRlZCB0aGF0IHRoZSANCm1haW4gZ29hbCBpcyB0byBsZWF2ZSB0aGUgb3JpZ2luYWwg ZGV2aWNlLXRyZWUgdW50b3VjaGVkIGFuZCBwdXQgYWxsIA0KWGVuLXJlbGF0ZWQgY29udGVudCBp bnRvIHRoZSB4ZW4gbm9kZS4gVGhhdCdzIHdoeSB3ZSBwcmVzZXJ2ZSB0aGUgDQpvcmlnaW5hbCBE VFMgc3RydWN0dXJlLCBzdWNoIGFzIHRoZSBzY21pX3NobV8wIGFuZCAvZmlybXdhcmUvc2NtaSBu b2Rlcy4NCg0KQWxzbywgaWYgeW91IHRha2UgYSBsb29rIGF0IHRoZSBhcm0sc2NtaS55YW1sIGZp bGUgaW4gdGhlIExpbnV4IGtlcm5lbCwgDQp0aGVyZSBpcyBubyBleHBsaWNpdCByZXF1aXJlbWVu dCByZWdhcmRpbmcgdGhlIGV4YWN0IHBsYWNlbWVudCBvZiB0aGUgDQpzY21pLXNobWVtIG5vZGUu IEFzIGNhbiBiZSBzZWVuLCBhcm0sc2NtaS1zaG1lbSBpcyBwcmVzZW50IGluIHRoZSANCnBhdHRl cm5Qcm9wZXJ0aWVzIG9mIHNyYW0ueWFtbCwgYnV0IHNvbWUgRFRTIGZpbGVzIHBsYWNlIGl0IGlu dG8gDQpyZXNlcnZlZC1tZW1vcnkgaW5zdGVhZC4NCg0KTXkgbWFpbiBwb2ludCBpcyB0aGF0IHdl IGRvbid0IHRvdWNoIHRoZSBvcmlnaW5hbCBkZXZpY2UtdHJlZSDigJQgd2UgDQpzaW1wbHkgYWRk IHRoZSB4ZW4gbm9kZSBhbmQgcHV0IGFsbCB0aGUgcmVxdWlyZWQgcHJvcGVydGllcyBpbnNpZGUg aXQuIA0KSWYgd2Ugd2VyZSB0byBwbGFjZSBzaG1lbSBpbnRvIHNyYW0gb3IgcmVzZXJ2ZWQtbWVt b3J5LCBpdCB3b3VsZCBnaXZlIHVzIA0KdGhlIGZvbGxvd2luZyBzdHJ1Y3R1cmU6DQoNCi8gew0K DQogwqAgwqAgwqB4ZW4gew0KDQogwqAgwqAgwqAgwqAgwqA8c3JhbXxyZXNlcnZlZC1tZW1vcnk+ OiB7DQoNCiDCoCDCoCDCoCDCoCDCoCDCoCDCoHNjbWlfc2htMCAuLi4NCg0KIMKgIMKgIMKgIMKg IMKgIMKgIC4uLi4NCg0KIMKgIMKgIMKgIMKgIMKgIMKgIHNjbWlfc2htWCAuLi4NCg0KIMKgIMKg IMKgIMKgIMKgfQ0KDQogwqAgwqAgwqB9DQoNCn0NCg0KVGhpcyB3b3VsZG4ndCBwcm92aWRlIGFu eSBiZW5lZml0IGJ1dCB3b3VsZCBvdmVyY29tcGxpY2F0ZSB0aGUgDQpkZXZpY2UtdHJlZSBzdHJ1 Y3R1cmUuIFdoYXQgZG8geW91IHRoaW5rPw0KPg0KPj4+PiAgICAgICAgICAgeGVuLGRvbTAtc2Np LWFnZW50LWlkID0gPDA+Ow0KPj4+Pg0KPj4+PiAgICAgICAgICAgc2NtaV9zaG1fMDogc3JhbUA0 N2ZmMDAwMCB7DQo+Pj4+ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0i Ow0KPj4+PiAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjAwMDAgMHgwIDB4MTAwMD47DQo+ Pj4+ICAgICAgICAgICB9Ow0KPj4+Pg0KPiBbLi4uXQ0KPg== From xen-devel-bounces@lists.xenproject.org Thu Sep 24 08:26:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 08:26:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431865.1653567 (Exim 4.92) (envelope-from ) id 1x9en3-0001ml-DJ; Thu, 24 Sep 2026 08:26:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431865.1653567; Thu, 24 Sep 2026 08:26:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9en3-0001me-8s; Thu, 24 Sep 2026 08:26:49 +0000 Received: by outflank-mailman (input) for mailman id 1431865; Thu, 24 Sep 2026 08:26:48 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9en1-0001mY-SG for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 08:26:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9en0-00FdWJ-Ob for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 10:26:46 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4deb9-bab6-0a2a0a5309dd-0a2a4506d0a8-22 for ; Thu, 24 Sep 2026 10:26:46 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4dec6-195a-0a2a45060019-4a7de14cc02a-3 for ; Thu, 24 Sep 2026 10:26:46 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843cedd129so1153236f8f.0 for ; Thu, 24 Sep 2026 01:26:46 -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 ffacd0b85a97d-4886877c379sm12644543f8f.29.2026.09.24.01.26.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2026 01:26:45 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790238406; x=1790843206; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=TkkP6WsYRo8sH98YUMRhSG2hYzszU9VFi3Hez4+CZiE=; b=TmPYnMa2MYs6fJsBKlbmevEn8TkZ6/haH8tN7PsySjDBEz0sjqLaHqD+sXZ4b3BCBA 1/JSg6HWJJENhSGnX4H5Adq2PM2PXmk/xpxNvFBzoALcTr0C6B9jsziRxwGTaOkW3Z60 yUs8UWy2ivcdIyK0Wl8tw3Jt7W79IqVkWpqbkF0ySosDs9PQaH2gQXh/U8sawJE9A5Wf 1yo0KwzGtgtJ9PUn5s7UqzEB4RCwk6P/WHky/AjQtmK8l6zkcQ49q+6Qz3Y9nBmsejLU hLEl5mzjyURwtviHl2UVevdGGth3izO78mv1C05ycaHZd9sRZJDhRnW56LZ+Np/MWNGQ mpEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790238406; x=1790843206; h=content-transfer-encoding:content-type: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:content-type; bh=TkkP6WsYRo8sH98YUMRhSG2hYzszU9VFi3Hez4+CZiE=; b=MapMuY3v2OCAgqyB2E7SMknC3U0T70GQ5SXyf1FgbiBBC0av3w7NkgjhWhW4LH/3+H b7ZtCj6Pd2vncC/z7AXI7LDr0FAE9bUPYZh5Jpvhkjgx/7HTLoPlgW8RXJA9QMymTcmk FlhNtFDUQpWiGRNnAPS91JYvpdvG3Hx5foKdGbPe5AYKrz+nmUXjfapBoX/Go/4AHOrg FgcIQY0Ckq2HifJsRNTCARhJoEd7p18rSR4SgKJaDGxB9XlOxBMTUpjFum18HFGkpEPb bRUIGRYMwGV/PQhoOCjXJicSnSp0BeZW9SF/7aU6E8d2hJ768QwtB4Qvgr2IAJWBMCHW w8gA== X-Forwarded-Encrypted: i=1; AKwUvBy+J70f9AxNwoxgfNJWYuH4NAX3TtgwHoXUW7gTDZvBC5ECL4v/bJ3XEpVKMSsdBldTM7ivON+xr9o=@lists.xenproject.org X-Gm-Message-State: AFuF++lZkHNGLotFeEELWazx2DJh6BM+h40y57xu3lL9kb7A7KLacI40 t5OLTkMwZCp3oMKkNNyqUpgmxOFCIMup/flbsYKV9mNY1cCqp5TN2/ZFXGKE/aBj/w== X-Gm-Gg: AYBFou0ACquMs/CFPH/WXQHFbU137v5UFOG7P4RN9mfwWYQoJ8cHQP6BG06Aburs0Tq PRnMAhr8P9x5kBvqTvGLPOi0L+Mo9wYazyWVtbHfGQQwNBp/NyVwpa2dRJHGhvPU9T47LSqbgW1 Q0THGrwUzsVR3Z6i3Em9OMtf6X6f5Xu3VPaIZE25foY9fPXM9vuXfZvxyiAV7QrFWmyexSMiLnB 1awkR2Uek54FrFj6LaECuFuo10IvtjvibnuX2Yvv57U/E/A8rrDYvrTKfsJda15QN1gIfyDjb4X 3WluKh329iZU8DsPbwpggvEhL2UCY+5oa1OgJolNgrj7p4AfWG4UEKUbD25c/ttG/UbLu/Kxz/Y YZPjX4K09zzVi8wez38em6wFRm8/KODm1sC6hDZYfXtz89cxaIHdtNEZcBja3iln1oI/7gT0V6c byt90xHqEZ3hBLV6TsfOytWIJsxNc4WyJ4G//kCcwNN7/h6VG8JA4hF2++j1g4WT1cvDK72rbkI 4IP6YrYsL6HK/Hw4Q5tnMfTUU0QBsHVFGqo5VGc59eY1z3tYkYNU0ywzD39jA== X-Received: by 2002:a05:6000:4711:b0:487:a0f:82ff with SMTP id ffacd0b85a97d-4887167c983mr2487806f8f.17.1790238406082; Thu, 24 Sep 2026 01:26:46 -0700 (PDT) Message-ID: Date: Thu, 24 Sep 2026 10:26:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ns16550: add the Amazon EC2 PCI serial device To: Benjamin Leggett Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260922184316.324817-1-benjamin@edera.io> <20260923153933.2024896-1-benjamin@edera.io> 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: <20260923153933.2024896-1-benjamin@edera.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1790238406-F7CCD77B-4254D2C6/0/0 X-purgate-type: clean X-purgate-size: 802 On 23.09.2026 17:39, Benjamin Leggett wrote: > Amazon EC2 bare metal instances have no UART at the legacy I/O port > 0x3f8. Their only serial port is a 16550-compatible PCI device (vendor > 0x1d0f, device 0x8250) with its registers in the MMIO space of BAR 0. > > pci_uart_config() uses the default parameters for a device that is not > in uart_config[], and those only accept an I/O BAR, so "com1=...,pci" > cannot find this device. Add it, with the same layout that Linux uses > (commit 3bfd1300abfe ("serial: 8250_pci: Add Amazon PCI serial device > ID")): one port at the start of BAR 0, 1-byte registers, and the > default 1.8432MHz clock. > > Assisted-by: Claude:claude-opus-5-5 > Signed-off-by: Benjamin Leggett Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Sep 24 09:02:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 09:02:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431910.1653575 (Exim 4.92) (envelope-from ) id 1x9fLT-0007gc-Vy; Thu, 24 Sep 2026 09:02:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431910.1653575; Thu, 24 Sep 2026 09:02:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9fLT-0007gV-Sr; Thu, 24 Sep 2026 09:02:23 +0000 Received: by outflank-mailman (input) for mailman id 1431910; Thu, 24 Sep 2026 09:02:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9fLS-0007gP-Rd for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 09:02:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x9fLS-00FE9l-0K; Thu, 24 Sep 2026 09:02:22 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x9fLS-006l9O-1t; Thu, 24 Sep 2026 09:02:22 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=nz7hWmOQzkI5zOz4nbp6z0d6UAAtWrS9kfIiP9sTrKw=; b=5TIHr4qaCJ7mu98+B9TCSLXo5T O466VYM+pF5zhCisMOx1zL0oaAd/j1ES0jfIH5TKYdX2BZ80O5EcoF71AeH67YE1ppoefBVJze6S4 jwplGYqBq5h8MuHmS8x7oufwyRvR+e6JZVDQiGFYZbq/zK2wAeiMCHjmsjdhLyhqYxZk=; Date: Thu, 24 Sep 2026 11:02:19 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie Subject: Re: [PATCH 3/6] x86/vPCI: tighten locking assertions Message-ID: References: <1b8c4276-0031-4a19-9663-b63799f5cf81@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1b8c4276-0031-4a19-9663-b63799f5cf81@suse.com> On Tue, Sep 08, 2026 at 03:02:19PM +0200, Jan Beulich wrote: > Already when they were introduced, they seemed overly lax. In particular > anything invoked solely from vpci_{read,write}() can check that the per- > domain PCI r/w lock is held. There's no need to permit the alternative of > holding the global PCI devices lock. I think this was (mostly?) done so that the macro could beused generically without having to think whether the context is locked by the pcidev_lock or the domain lock (or possibly both). > vpci_msi_arch_update()'s sole call site is update_msi(), which in turn is > solely called from write handling hooks. > > vpci_msi_update(), besides being called from vpci_msi_arch_update() (see > above), has two further call sites: > - vpci_msi_arch_enable(), called upon control register writes, > - vpci_msix_arch_enable_entry(), called solely from update_entry(), which > in turn is again called upon control register writes, plus from > msix_write(), which read-locks the domain's PCI lock. > Both arch_enable functions therefore can also have their assertions > adjusted. > > vpci_msi_disable() is called from > - vpci_msi_arch_disable(), called upon control register writes, > - vpci_msix_arch_enable_entry(), covered above, > - vpci_msix_arch_disable_entry(), called update_entry() (see above) and > upon control register writes. I was under the impression that the long term plan was to drop the pcidevs_lock side of ASSERT_PDEV_LIST_IS_READ_LOCKED(), and convert that assert to check exclusively for the per-domain pci_lock. However doing it would require assessing (and possibly adjusting) of all users, which is unlikely to happen. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > With this perhaps the comment near the top of vpci_msix_arch_print() might > better go away. Thoughts? I would remove it now - previously it was the outlier and hence deserved a comment, that's not the case after your change. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 24 09:16:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 09:16:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431921.1653583 (Exim 4.92) (envelope-from ) id 1x9fYy-0001HZ-31; Thu, 24 Sep 2026 09:16:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431921.1653583; Thu, 24 Sep 2026 09:16:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9fYy-0001HS-0B; Thu, 24 Sep 2026 09:16:20 +0000 Received: by outflank-mailman (input) for mailman id 1431921; Thu, 24 Sep 2026 09:16:19 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9fYw-0001GG-R5 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 09:16:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9fYv-00Fo0i-RL for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:16:17 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4ea5e-8faa-0a2a0a5109dd-0a2a4506e462-8 for ; Thu, 24 Sep 2026 11:16:17 +0200 Received: from [52.101.52.67] (helo=BL2PR02CU003.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4ea60-195a-0a2a45060019-346534433711-3 for ; Thu, 24 Sep 2026 11:16:17 +0200 Received: from LV3PR03MB7609.namprd03.prod.outlook.com (2603:10b6:408:283::12) by IA1PR03MB8061.namprd03.prod.outlook.com (2603:10b6:208:593::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 09:16:15 +0000 Received: from LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c]) by LV3PR03MB7609.namprd03.prod.outlook.com ([fe80::146d:1d33:b619:386c%5]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 09:16:14 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HTp6C8vpyy3xamkNduu2cvw8imDSuG5RrwViEnTxumxtU+rjldh4JkMMAQRlGRA6zd0hQeeOPFTqDz0DHtiBTGPw1yyNWLlUES5Sh1gNz9k+XFPFdiolMtj5ppLxEguVUe/fGr4OdqfKyg6UwZ0zkpUY+6elRQlwrzvASgo7YVFiM2ufPPS0+O/hzCiKQCPORZXHJ5cjXfkgRtrVQa5cvh8FxAi7IWt64Yw6cDJDTLUm8hhJ6sYqXWQ2+z1cS3Hp5NCN9DALeVX7K2Ru13KR+r2OvP+lqZaOjAvwLfiQR3iILuCpcvneEwvwVg8utfT8cHZgR56C3uLmolNFaR8C5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GgZejzKnQXAFzK1QYGTgdyV99LB0FyifVC9VdCZo/m8=; b=Fh24FRyT/XqgOdtIem7mlRXc0ZP94EsghJPyk9vlHPmM8n63KbdRZY/RgUeLHfr2n5Djhts63IkcWOFdWvkgJ97b+2BICC2WTsuBHPlGiUwT2Xm0H1Rn+mBD9wtzniRvWqmFSJBxSaYXemTn22heeIHb/rbfQ0z82ZKBuIoAJOMFF6GWaNSHuCadkCP3SAhOiRw8IL2pKdFuGkmpyzSnQzNqE5eM0lbYC1k/X5nEXWDMKCkZtSlLMYDsDNIe4WVg75n3o/gozj85iE9o5j6NRE136MPaxHt2+7zNiCqC2omy0g1exMqg5J9nD9QxV2QQAJ+rVgFqLmC9B0d6UbcDuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GgZejzKnQXAFzK1QYGTgdyV99LB0FyifVC9VdCZo/m8=; b=U3fnM6RAbzSHyzvDAhk+xz1/ezhgrpOk4AX/wNUrULJWvYhgMDKr1l3pVgK3NosCHiGhcYEgAjJwMyiXfQkJzfRIAjWRrvJDLlFyySy1Rc8aVHBEIBh/tVC7zzvGKR/zh41lTdlO80uUBhuEMHIBS4qEvye0GLhhpsXnFc09m2k= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: chunjie.zhu@citrix.com To: ross.lagerwall@citrix.com Cc: andrew.cooper3@citrix.com, chunjie.zhu@citrix.com, jason.andryuk@amd.com, jbeulich@suse.com, roger@xenproject.org, teddy.astie@vates.tech, xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 5/5] x86/nestedsvm: fix up Date: Thu, 24 Sep 2026 17:16:05 +0800 Message-Id: <20260924091605.344577-1-chunjie.zhu@citrix.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> References: <21b02d5c-4e21-43fb-b371-201a125bfdbb@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: KU2P306CA0037.MYSP306.PROD.OUTLOOK.COM (2603:1096:d10:3c::19) To IA3PR03MB7596.namprd03.prod.outlook.com (2603:10b6:208:508::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LV3PR03MB7609:EE_|IA1PR03MB8061:EE_ X-MS-Office365-Filtering-Correlation-Id: 31ed2cb2-a365-4e57-0897-08df1a1c7b65 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|10067099003|56012099006|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: fagarlHb6eCpjIbTdDUdAbdvW+8M8Kg9xtQdGZWCveJOlhxGyABYprx870gBnJKuT8IxP+E2+iIzrw7ptol2dilNvLfEMbH2CmXZvbQ8vwX1j6sLQRogmLiXMmSHCjvc8y3xOQXvKYwUybe3g74IBDEgi0eqYX8lF7egGuLbvRF59rRWYS5CzblMFMXTWUnCiGYHRPyKBI7NMzKBMQ1bhbx5H2uW+ejvjSqd7FhytiOewpByLZNdZhCExiM3kH+Ur1DwveT5i6ZzcP0Y6cGGiQeQ5Lwuuuh8Zx+o9wgYOPiBgJbPiwHRUVJjsSZBCkTbkmLFhNxLUXN6YWUV0X56+5JIR9glaRGEvsi+pFpxAERvYDchHGaiN7+BOZxbpze+I36kD3zw+7rI9feH+DkHKgyDvkHhc0af6GdH8Nn8yFXDbq6KHQqHLVHkJwzeR20fY41Yb5G6E07xOoFcCXMAt2nX2uo3v8UDxONALvlzpG5Pa7rEXIb3Db37+H+vY4KIyFgrbOmMi7xEhucZE4dsOcX6Ga34U7y4UgMOsq8+G7li7ODruB4aDFzsT9Hr2kSzEubuMfP5kdCORyhzirpYmpxtx3+ifKSUd1NC050v5fYGQejsV6pMhwcQ3uIxOC6/FkjrMVx+JU7AYLGk5dyaW5tIPgQTIZMhE+GS+XiKu8I= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7609.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uwvxQO2ZBVbb1U/KvZi6CGZr7p0ZSZAEdQ9h1exf4KTLSqLFIXYGTUaj6B7s?= =?us-ascii?Q?sRdlaYME7p1RteHWRsJh/YtQbp6FpC/7v1OBPOobatHsrDtzbVZG3mnWEJpS?= =?us-ascii?Q?t79xO8viEye1eAUUwROnvm3pHC3yEOk8iouuPvZ8OfZV1Gl5AMr8iPow1QiA?= =?us-ascii?Q?GFTQ7EMqc5AGxMx7X6BODydcok0gAV4FPKTZ9pi2+ipIWNfGlz9RtpgGSPhA?= =?us-ascii?Q?5xuLgxIW9LbuYFtXp09J58hGyLDmE+2BYezjha3/Ju24zQsKKzERo0b1m/mY?= =?us-ascii?Q?HuflsUUaJvYggPtOwE4Z3cxXL1Q3IALqW2cQSvFyGsCLWwyGOCb6vTTwVSiO?= =?us-ascii?Q?5FedP9DBHJG1O07sdsbIsJRQ6EDeAR3Y7XDQKW6pgyaWcjhNOdtPYWgv4anV?= =?us-ascii?Q?UWIERi7OV+iveubfHJCSXifZGhg5lqShMCnUUSIgyCeOdp3CEEfn5Pmb8qhl?= =?us-ascii?Q?EAupdYMCq3mMcsKiwCs4/ptnWiBtEu8yYwfquF5AoseeAUKNY368jU9/UDY0?= =?us-ascii?Q?8J3EdKL21BTN9kZIoStpF3c8ggIznJLNnT2GCMHbEqGcEQECANVo9lswXbdj?= =?us-ascii?Q?6LJk2eSj9x4GaUwGhNRsdYhT6Y8UNsA/iZN1v8YQACc8z8xgsz0z9mmf88fy?= =?us-ascii?Q?q4/SacsrPv4gim5IuqHvJtbr7focIEthzfQjHfB+KzivUsu9I8ZYKMXpAzB5?= =?us-ascii?Q?wjYQViF21JTX7vTbt5b03Tvnx/aOa8iRosVnbDHiFtNJPp0M5R6FGhsCUwqF?= =?us-ascii?Q?vKpwOCTVM61aOxUUnuhALUwgcHwjmq2UeN5gz50qdqpFxBn3+vS48ufgqYmE?= =?us-ascii?Q?zxdltT9FI59NcysXAzYUiARpAJLdorJLlGPtLjHkeiWBphYZE3At2Awmc0zs?= =?us-ascii?Q?yeVHTyTLQsWn5fiyBPVaiAOwSaH0CiwNO307nZzS6ERx1MgwerxpFQ1XcQPD?= =?us-ascii?Q?p3nynS+qCYB/CYYhqtQcbgCnE2WGtrUZAaQkh09rY7msG04SerLS3BU+a4tL?= =?us-ascii?Q?ZCfb5NCbrORb8RSRhJG4trk4QG4PCHUqsPviJz+es2yHB+s1SrBdVIAwU3Wb?= =?us-ascii?Q?iwKIlWifRc+axiD9GhOrTTat8Q5ZV0ENsLzPQr4u8JVWWjU3veQ6ELtzthFW?= =?us-ascii?Q?cFALUo2wUHun/2V9WSrOr9TPmDRVBKraNi6L1XlC7opq8c4UzNo2w6thxUGx?= =?us-ascii?Q?E88a//wUdvRO3OLiFTCSGulLs7kddSIjoF90K9Ej7GGF3jYSRWCJxde6AEoe?= =?us-ascii?Q?NLCa3QkmohJ/Jf5xxZh9Bxj9ynbe7yFpRAmxh8I3SSjLto2dzS5chpxGSN75?= =?us-ascii?Q?cbRSFAM1pu54rmgrXOOKs2DcYLKCMuY3FPmgNWqTVHxjhyPf2WnUqlAKfkLH?= =?us-ascii?Q?nfAX/beMp1lfA12R7xGxc/ydQIVAXl25xDebMpvtlOt6QzpyGmL1upcCu6ap?= =?us-ascii?Q?AUOjR6iOzJ9oZEO9loi5WBGVpuG1vZ3srQ9uB8F1gMJHj71DuWcMJNsnw6lq?= =?us-ascii?Q?uQw9j1hsAjQV2ulP4VOj9oWKkbP89uaT3M3if2A1PPBQGtd7tpwXGCMkq8/P?= =?us-ascii?Q?K8soinLh5wguZZwTxnSp4IFz+gn0Q4eX0dc0GMX5qiq5eotYonUlHtc/PS4s?= =?us-ascii?Q?wt1G7VBoWaujANr7ABtKawoBBoQZkibMw9gxB+iLYVi3yktkbevASNH7eVg8?= =?us-ascii?Q?6Pk11UcWhqYb2djn4TSfZjrrPh/4CTKZ+7zEpMvV7mJ8KWa0MG9X5wt2FFL6?= =?us-ascii?Q?OBLrAr+xHQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 31ed2cb2-a365-4e57-0897-08df1a1c7b65 X-MS-Exchange-CrossTenant-AuthSource: IA3PR03MB7596.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 09:16:14.8192 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: saAX+Dpgo4VpyUf6SCJhoembzdMFzwJaLqEGKWYv0YpJxm2vFKLFPy4qjAkVyHmHYnvX8mLz65lMpEciIVZRjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR03MB8061 X-purgate-ID: tlsNG-16d1c6/1790241377-1F6C877B-ADD45FF9/0/0 X-purgate-type: clean X-purgate-size: 4994 On Wed, Sep 23, 2026 at 10:55:41 AM, Ross Lagerwall wrote: > On 9/23/26 10:42 AM, Ross Lagerwall wrote: > > On 9/23/26 10:20 AM, chunjie.zhu@citrix.com wrote: > >> From: Chunjie Zhu > >> > >> Signed-off-by: Chunjie Zhu > >> --- > >> xen/arch/x86/hvm/svm/nestedsvm.c | 19 ++++++++++++++++--- > >> xen/arch/x86/hvm/svm/vmcb.c | 9 +++++---- > >> xen/arch/x86/mm/p2m.c | 5 +++++ > >> 3 files changed, 26 insertions(+), 7 deletions(-) > >> > >> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c > >> index 82e01e513e69..91872af8aa7b 100644 > >> --- a/xen/arch/x86/hvm/svm/nestedsvm.c > >> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > >> @@ -355,7 +355,7 @@ static void nestedsvm_vmcb_set_nestedp2m(struct vcpu *v, > >> vcpu_nestedsvm(v).ns_vmcb_hostcr3 = vvmcb->_h_cr3; > >> p2m = p2m_get_nestedp2m(v); > >> - n2vmcb->_h_cr3 = pagetable_get_paddr(p2m_get_pagetable(p2m)); > >> + vmcb_set_h_cr3(n2vmcb, pagetable_get_paddr(p2m_get_pagetable(p2m))); > >> } > >> void nsvm_vcpu_update_nestedp2m(struct vcpu *v) > >> @@ -373,6 +373,7 @@ void nsvm_vcpu_update_nestedp2m(struct vcpu *v) > >> return; > >> p2m = p2m_get_nestedp2m(v); > >> + nv->stale_np2m = false; > >> /* > >> * This may happen if we've handled VMEXIT_NPF at the same time as a > >> @@ -383,8 +384,6 @@ void nsvm_vcpu_update_nestedp2m(struct vcpu *v) > >> vmcb_get_h_cr3(nv->nv_n2vmcx) != > >> pagetable_get_paddr(p2m_get_pagetable(p2m)) ) > >> nestedsvm_vmcb_set_nestedp2m(v, nv->nv_vvmcx, nv->nv_n2vmcx); > >> - > >> - nv->stale_np2m = false; > >> } > >> static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) > >> @@ -1024,6 +1023,20 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > >> struct vmcb_struct *ns_vmcb = nv->nv_vvmcx; > >> struct vmcb_struct *n2vmcb = nv->nv_n2vmcx; > >> + ASSERT(v == current); > >> + > >> + /* > >> + * The physical VMCB fields covered by VMSAVE/VMLOAD may not be in sync > >> + * with v's vmcb if a context switch happened since the last VMLOAD. > >> + * VMSAVE below would otherwise capture stale/foreign register state > >> + * into the L1 shadow VMCB. > >> + */ > >> + if ( v->arch.hvm.svm.vmcb_sync_state == vmcb_needs_vmload ) > >> + { > >> + svm_vmload_pa(v->arch.hvm.svm.vmcb_pa); > >> + v->arch.hvm.svm.vmcb_sync_state = vmcb_in_sync; > >> + } > >> + > >> svm_vmsave_pa(nv->nv_n1vmcx_pa); > >> /* Cache guest physical address of virtual vmcb > >> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c > >> index 5354c4f1b85f..2f7053ed7eec 100644 > >> --- a/xen/arch/x86/hvm/svm/vmcb.c > >> +++ b/xen/arch/x86/hvm/svm/vmcb.c > >> @@ -357,10 +357,11 @@ bool svm_vmcb_isvalid( > >> PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n", cr0); > >> if ( (cr0 & X86_CR0_PG) && > >> - ((cr3 & 7) || > >> - ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && (cr3 & 0xfe0)) || > >> - ((efer & EFER_LMA) && > >> - (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr))) ) > >> + ((!(cr4 & X86_CR4_PCIDE) && > >> + ((cr3 & 7) || > >> + ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && > >> + (cr3 & 0xfe0)))) || > >> + (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr)) ) > >> PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3); > >> valid = hvm_cr4_guest_valid_bits(v->domain); > >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c > >> index 027b9ae69be3..d1fafc479c78 100644 > >> --- a/xen/arch/x86/mm/p2m.c > >> +++ b/xen/arch/x86/mm/p2m.c > >> @@ -1517,7 +1517,12 @@ p2m_get_nestedp2m_locked(struct vcpu *v) > >> np2m_base &= ~(0xfffULL); > >> if ( nv->nv_flushp2m && nv->nv_p2m ) > >> + { > >> + p2m = nv->nv_p2m; > >> + if ( p2m ) > >> + p2m_flush_table(p2m); > >> nv->nv_p2m = NULL; > >> + } > >> nestedp2m_lock(d); > >> p2m = nv->nv_p2m; > > > > This seems to have combined several bug fixes from our internal patchqueue (I > > know because I wrote some of them...), some of which have already been posted > > to the list. > > > > It's not clear why they were submitted as part of this series. > > > > Looking further, patches 1, 3, and 4 also contain seemingly unrelated patches > from our internal patchqueue. Can you resubmit this series without these > patches mixed in? Or if they really are required dependencies, (where they > haven't already been posted to xen-devel previously) submit them as separate > patches at the start of this series, maintaining authorship information. > > Ross Sure. Will send the v2 series. > > From xen-devel-bounces@lists.xenproject.org Thu Sep 24 09:28:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 09:28:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431948.1653592 (Exim 4.92) (envelope-from ) id 1x9fkT-0003Bq-2W; Thu, 24 Sep 2026 09:28:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431948.1653592; Thu, 24 Sep 2026 09:28:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9fkS-0003Bj-W6; Thu, 24 Sep 2026 09:28:12 +0000 Received: by outflank-mailman (input) for mailman id 1431948; Thu, 24 Sep 2026 09:28:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9fkR-0003Bd-8y for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 09:28:11 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x9fkQ-00FFf4-1u; Thu, 24 Sep 2026 09:28:10 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x9fkR-008cch-0E; Thu, 24 Sep 2026 09:28:10 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=2qQjfmwYwMgSFjYQudrNjPJiuxq453V22V7l2VkBGn0=; b=1C0QUS+HA9v6rqqvE+gSLd/uAB 3O6k4e9CpwshzSnDEK8ruOlI+z3cE0MgRscKXU0GdC7BKCXhzXKRpteKJKenMb+IPhz4hgUyvVaSf AbFOi88unrbwL8hI5/4HS+PQgb0iSsV9PDLgJrN8wZEaNcIVexAqbEr848QvkNt5mPKo=; Date: Thu, 24 Sep 2026 11:28:08 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH 4/6] vPCI: drop bogus locking assertion Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Sep 08, 2026 at 03:03:17PM +0200, Jan Beulich wrote: > msix_find() is a local helper, with all callers explicitly acquiring the > per-domain PCI r/w lock. The checking, which should never have included > the alternative of holding the global PCI devices lock, therefore is > pretty much pointless. Hm, maybe. I guess we need to put some limits on how much we assert for correct locking if the callers are all in the same translation unit. > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné I wouldn't have removed it myself, but I'm also not going to oppose. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Sep 24 09:57:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 09:57:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431971.1653602 (Exim 4.92) (envelope-from ) id 1x9gCm-0007rM-5J; Thu, 24 Sep 2026 09:57:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431971.1653602; Thu, 24 Sep 2026 09:57:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9gCm-0007rF-1Y; Thu, 24 Sep 2026 09:57:28 +0000 Received: by outflank-mailman (input) for mailman id 1431971; Thu, 24 Sep 2026 09:57:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9gCk-0007r9-KG for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 09:57:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9gCj-005rSd-57 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:57:25 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4f404-e002-0a2a0a5209dd-0a2a4509d38e-2 for ; Thu, 24 Sep 2026 11:57:25 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4f401-be1a-0a2a45090019-4a7de18cfedf-3 for ; Thu, 24 Sep 2026 11:57:21 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49e66390995so11736375e9.2 for ; Thu, 24 Sep 2026 02:57:21 -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 ffacd0b85a97d-4886848646dsm12255454f8f.10.2026.09.24.02.57.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2026 02:57:20 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790243841; x=1790848641; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=awkUv4uskLqcruZcmAXZuPDqqAn7vtVBRl8R4zKRSvs=; b=cRWI8YgV505oyl/MqQjKV4qWw7f0uau5aONq1MJuJVfn2xSsRuiJ5bjGLBcGlvReQS Wgwf8dBijMm8TEEyGs89fJEkGW4BfzmhwWL+WUc4cS7Fy/NCeJa+bHLwsZBGAfS1XyY5 uMW9ZUUTMVsyheiSLy8x9dIYo0FbN6csuBZ5IHqFuJZyRnxyw55sFF/mCJBMqEp7Pyz3 rjmaR4rwQpBGmOIXzBINR/tShOi3jv/ca+iIaSY3a+tIeczV7El9A4QS+BtizTQ6Bj0l UHjhUuMiObFlAbYhxTBqep+k1rgJ7U65cwFDuqhUAbVCQxE2yZEuvyhSwhoeUFWl7b1a D34A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790243841; x=1790848641; h=content-transfer-encoding:content-type: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:content-type; bh=awkUv4uskLqcruZcmAXZuPDqqAn7vtVBRl8R4zKRSvs=; b=R8ZZpuXUmBQlaI82Mj37blij5aOmu8Sae1/hoaHpaXn3mS5F9vGqGPA/T+1IKZqM+J mukUUTRgc+gEnx23ce8+lN7j7/xdseZw+YwHekcBaKkjQBkauNHrw8bqsQ1sAE9Ixl+h paa06+/lZ30c72Th5xrApWyJ8XOY1Ho2dkZ4aKyQbbCZGtPoXxvinaAl6HfvlZNk/cON nQdx0zZJyKMpQYmnsanyw4r4YdFssCvVUsKj5AVRiT81Ogd6S3UOZu7ezi6DZFpaSfyH z5AUKRIpbnOg1kBhoVQev7d6gRVOL2LrqVDNsSNfpy2JY3gleqRU1ij6BFSzOmNYh4Bt 0hlg== X-Gm-Message-State: AFuF++koW5DefHdZsZpPfQHCyHrqE+0RkJVGh30qSdCCqoTlrXW2BklL Btmw5p5qO76SDqPVUYQYkzP+FoHO7/038G1igndC49Q1ViXwrKDf8fWDzsIEAti/b3c+K5pqmIc OODmqcA== X-Gm-Gg: AYBFou08RbF6Ly9f5xzCONGxW69POJ8tVYnzas0x4jH2nOUVAPVbQTq5GQrlEdhF3ky mxLhWeORiU4s6FF2pdV0RFKuoclsXPnuRhWdASyasl+6ZaovvrTI3m8AhDZCzVHoBv8iqDz/bTy fbTH6u4UrnnPmTrmgPdxMBcoAenoTdowFvjWrTeEIQ9Yqy6FeTv6xasyizGOIwNnrqpNBQB2Mww LSMZZ08lWFjZ4N0rGSnYxU0bsPqP+r1PpmNw5xbDRV/nrBdtClrXDjoAsnoBygPAVJaxNDwc9vM Z7GAlKtePMfvVD6bEFN+uJegd0HmhqZfxU+FyLX+Zy8so7r8ztm/hFIaFdyEH0jMraFM0T2cnyk qD5Hp1vR0xB4A9FjC/o80GQZulz5qB2OcWF1R63EG4v/vSbWEHaGkKvMpoBSALOa4eKmTziHJJb HZ0RgiVg4b5G+aJ1+uq9vXLJ23/ylgmi0+ihtb4t7Sn4NNhDsARDjSPSdf4I3ITfKvzFqulfNPY 0phZQXZ3gNkowjmvmr6AMVfuon9IcRnDYsaazVg6kfgLVy6tgFFqF19RTETzuE= X-Received: by 2002:a05:600c:34c7:b0:49c:dca2:ac47 with SMTP id 5b1f17b1804b1-49fe66c8e71mr30055675e9.2.1790243841046; Thu, 24 Sep 2026 02:57:21 -0700 (PDT) Message-ID: Date: Thu, 24 Sep 2026 11:57:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] x86/pass-through: no locking around pt_irq_{create,destroy}_bind() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Julian Vetter References: <92b0a72a-44df-424f-acbe-58d7167f1c4d@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: 8bit X-purgate-ID: tlsNG-bad1c0/1790243841-FC610034-45317CB7/0/0 X-purgate-type: clean X-purgate-size: 1469 On 23.09.2026 12:37, Roger Pau Monné wrote: > On Tue, Sep 08, 2026 at 03:01:51PM +0200, Jan Beulich wrote: >> The questionable use of pcidevs_lock() there was discussed more than once. >> It really is pointless: The functions synchronize primarily via the per- >> domain event lock. They also may already be called with the global PCI >> devices lock not held: See hvm/vmsi.c:vpci_msi_update(), >> hvm/vmsi.c:vpci_msi_arch_update(), and hvm/vmsi.c:vpci_msi_disable(). >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/domctl.c >> +++ b/xen/arch/x86/domctl.c >> @@ -636,10 +636,7 @@ long arch_do_domctl( >> ret = -EPERM; >> else if ( is_iommu_enabled(d) ) >> { >> - pcidevs_lock(); >> ret = pt_irq_create_bind(d, bind); >> - pcidevs_unlock(); > > pt_irq_create_bind() might call into msixtbl_pt_register() which > requires either the pcidevs_lock() or the per-domain d->pci_lock lock > to be taken, which I think is not the case in the context here? Hmm, indeed. Not having seen the assertion there trigger kind of worries me a little. Do you agree that the change to vioapic_hwdom_map_gsi() can, otoh, be left as is? In turn I will then extend patch 3 to also tighten the assertions in msixtbl_pt_{,un}register(), as each of them has only this one call site. Would you mind indicating whether in doing so I may retain you A-b there? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 24 09:59:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 09:59:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431980.1653611 (Exim 4.92) (envelope-from ) id 1x9gFB-00006K-Jy; Thu, 24 Sep 2026 09:59:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431980.1653611; Thu, 24 Sep 2026 09:59:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9gFB-00006D-GZ; Thu, 24 Sep 2026 09:59:57 +0000 Received: by outflank-mailman (input) for mailman id 1431980; Thu, 24 Sep 2026 09:59:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9gFA-000067-2t for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 09:59:56 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9gF9-004jZt-Cf for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:59:55 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4f495-e002-0a2a0a5209dd-0a2a4502dcfa-36 for ; Thu, 24 Sep 2026 11:59:55 +0200 Received: from [40.107.208.22] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4f499-6ca4-0a2a45020019-286bd01662e0-3 for ; Thu, 24 Sep 2026 11:59:54 +0200 Received: from CH7PR03MB7859.namprd03.prod.outlook.com (2603:10b6:610:24f::20) by LV8PR03MB7447.namprd03.prod.outlook.com (2603:10b6:408:187::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Thu, 24 Sep 2026 09:59:39 +0000 Received: from CH7PR03MB7859.namprd03.prod.outlook.com ([fe80::967:59c2:d16:1fcf]) by CH7PR03MB7859.namprd03.prod.outlook.com ([fe80::967:59c2:d16:1fcf%6]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 09:59:38 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gN0onTk0sFH9Ev1ZLYuy3wNISazA+oxMqmouaOSgvVjJP/w0U+LDEGbfgd4a8Ke3tTIEXEkc8m/pizKKvtsml4hETB3UaDC1GtnnbBzqPJoML2IjRqUNbKtpakTFMyDkJQr2sTKxeYCVFfZolnItqmudyPMtCF3G+I6mvpq00fPnqTkYmV6nLrbUG0AHH3aOeGNyEJTOIdRuyMT9hdQaGcEr7Eb/pTVIZRwbfUgEmR7VA792fsyPJiVlDh02fn4JR7P50L/vT8U7suyagtp4m8ubDWcZZpssxOS0YHG+deiX2Up2XPbBLhx6ptdrlLhAEC0z31ex/8R8j6DSxuuloA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=roiavHcKqhBCze3i54BYoCG/anwhCeZEQ4CiwzLncz8=; b=FnDBvCskzr8KXCKwMNE3x+FKnIGW1/QKlqxPIkVVlGPaI5lZi/2qZFMSofn4q1L8yXWTtO0WQoXvcYszAu4VedTxxtLi4ew9Gbgz2RWGJ69EsJXOJa0dDy1rApAkfcqqj16LvEsf1RuHTZBueI86rB2RX/ghficDDgEQXb4fiR5ZeFBZBJOKVbXQ4NBpo2n8/XFhxpjVQue8OoYGy/ftreKukkZCssVpLB7cbVrWbY0YvUvi1o2E210rba++VE1ab7hSsY/nv/wVN2SyV5XXwsRJ+KhoiNrPcrwCf0i3dYPP7kvA6xqg9keuT58VvJ3lE0GkYaQ/wGXmzGIy+J/Zhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=roiavHcKqhBCze3i54BYoCG/anwhCeZEQ4CiwzLncz8=; b=J3WoEIfxKzsvyY1hYadP3Xl+hsAMweFh7dDEdI27DYjDdmIxNpnuliJX56ew5NrrZFpbhiPcaDK8TGDYqJM3/5vgKmDTEgcl+q7tfHxGwGQP4e4zvJPWbd+kGMCkVCaqXx4UCJ9jYfAlNGU0MnmOm8Ak/LwAoHF1RkJ0ON6CcV8= From: Alex Brett To: "xen-devel@lists.xenproject.org" Subject: Updates to Security Policy Thread-Topic: Updates to Security Policy Thread-Index: AQHdTAT75JUOq4hc+kK5Rpl1wLOZ7g== Date: Thu, 24 Sep 2026 09:59:38 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH7PR03MB7859:EE_|LV8PR03MB7447:EE_ x-ms-office365-filtering-correlation-id: 15565d4c-221a-4211-d889-08df1a228be6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|38070700021|10067099003|11063799006|56012099006|18002099003; x-microsoft-antispam-message-info: Ev9nsEytTi2uiFEwj+7fg+M9keyrG9ywMwidj30/y0Tqogagfx89evsZDldoa0FNpIA+bmgGQJ8f/wSsg3HVzGf2XIGVy7+CfBTAem0A7OV+OJfXPViFES/7AuFn2bO1se5Q3rYG/MeyFG1Nk1D7HCGRVFuikfmiuU9UBhK0Cuc2Y4KAok7rmlue7wfJXFKgEH6slhtOpN1xYP0Pfyd8cokTzxcN9i76lXeCcRGOyfPpnEk4xz3CRwfYGUUTvDwGdOgSrzTDiP3mUXozsLDlm9T3Oh9I1BR280POyTMOinubclIuwmSzN+8ivHKtMt68S8lxfEniX4Kzv7gKv09AoTQuqWbLPaET6/q2hPYKzimoYz3ikVoUBWLme6618Y4VZUe7RxeQu5SDbmHlivVpw3q8sKVvYreVKVrvgi2qkcpfMdOySFjGHf7RtCk7TA5vEwvMXviJnv4KzO3IfzspL6jpXKV9Hu48sMgf/XUPGVcLQrkgqHfgxaOwvOppgpQlVCFU4dCR3CeW3WcjzthnfonHffhrjbxIW6Q8IbLwPBslF9oVSJH0Y9jOjKw0px5XtciwRd26FosUt74X41nMy6KvjYbjSigTJHZ15VNa91rh1rx9Rwpq94CnzfOHOpnYCZXIUA9z9R6pUPpLmm7VAoTw4X0rpGh72Dg8pD1JAq4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7859.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(38070700021)(10067099003)(11063799006)(56012099006)(18002099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ZdxK9+diVU9BjTSA4v6T7LL/dbWYXE3YPcak/n/3XYJxZUZFkUjnkdt7tY?= =?iso-8859-1?Q?3LINGH/b2X5fJqqc8B7dBA6UrjgQe2GaxMxK+e3grMZPi2VI3Pa+IP3Y+5?= =?iso-8859-1?Q?AQW9XruIas8ki+fxG1oSz8Fgtos1LiL1oWIYlmhzIKdBGnwPOIgd/Jpmdl?= =?iso-8859-1?Q?RcuJ46EmsTiuvhlfYuLtfiYUziT6mVQkXm46sFjcTzlHilN6n4SMxikVuh?= =?iso-8859-1?Q?YGDXdyzcuH+Tw9eLypn64i3RQkWhe4KsVOEYeyDCx+lTmbt5jQNelLI5SI?= =?iso-8859-1?Q?FB3vC36Jm7iMLAhrXnVbuNg1oZaJa6XD049RpdFHZJmCM0CSJTXS9ZFzqt?= =?iso-8859-1?Q?c1mc7Q54dZNbLm2Aj42fZ9wOfIdwST9bj8N9xIocQsc6mdgXnWl83FOaGh?= =?iso-8859-1?Q?jsIYWXES/mwS0bBq4j3n2o+LLqR/KEFB0AcuBx6NncUCwFhbijYELPyRpu?= =?iso-8859-1?Q?2tgM152Ba8KrQNKx5B3Lh0PjgBOscLaIaNq+/pRTmDpjBNvfj9I8TdNqgC?= =?iso-8859-1?Q?PWfzSHZLTWwzOmNR8TGPypBF+jWa9V74MuXAyUdIzTxte/GjIFGNB/OpAs?= =?iso-8859-1?Q?H0Osp4WXptH6mLJuvgWmn9N6Y7j63oZS0O75D3B2G2X+rgJBP9Jqx/lPF1?= =?iso-8859-1?Q?DHoWE61rntl/4Mdtw8JkRGpEqwy8Bb8mLkKLwFiPGU1AwDP/qwxgC593db?= =?iso-8859-1?Q?kOKx2U84Irgdl6x3uuH3OukSQeJC0rojg4u7FRx5nvqqH0HbaDprlvSjAI?= =?iso-8859-1?Q?HmHCsiPOMDtLGgbC/SbhsdXIQiC3ajswVsKivxpyMEhjF2seyN7wia+vVN?= =?iso-8859-1?Q?ntiQ/SiDMCWSy66hJzrQ34mFRolO+Ow1cCwtAZmxH4BVpSz/4M0wTitgu2?= =?iso-8859-1?Q?pFNd+YpNeSXdiJAVq2tcBac4TEYSYrjHnoW8Lh7vdDOus2O90F5XloCWim?= =?iso-8859-1?Q?dM1yTS/rBGPAOqcIzLwAVKF5txziYlr7Ie1GfebQaSU1lSFSjFVuzCPj3b?= =?iso-8859-1?Q?5WGg2vXmhLMYwGVISxLdNyfNJ2FNRhTzw26xVPLrLKdAHNGo1hPr89Gkh1?= =?iso-8859-1?Q?a7XauytnR+hRDpvuNkAqkiQr0pzCxjzK4LhGUKPaGxX4w8xWnjUJwr+f/F?= =?iso-8859-1?Q?6oy8d252HvaZ2Ry7crJrCJyqFxs6+AOq8SZLzvWKXD1jKSYPqcC2GLDq/c?= =?iso-8859-1?Q?rgd1R8OurGB/GYL74xJJZQmk4RY/FL2yGOdU1Y/1aFQwz4RdHbIRsZIJ5A?= =?iso-8859-1?Q?w8wFFvKHOJSbGrJgnRh4cmrl0M005UspRDTX+manO2XHlpIjSX57YreyzK?= =?iso-8859-1?Q?LAUK+03rDTASFurhBVOxHJ2hebafvXcokkKYcaQZpX4K5Pz2zqj5V8BrX7?= =?iso-8859-1?Q?t5YmrCOqQxs0iIf/b9xa5GHHNJ7Khza4/f2pSNSDKigCIOG6sLOYvBuZKU?= =?iso-8859-1?Q?VDB2M3iMSF/j+/UjlGpGRDwl6qzSsxfSBnz/7bgbhYVraCH03JPqJCgu7u?= =?iso-8859-1?Q?y6DpT+R79n1+XU9HjMnGLHe6UAmLdgoj6siasPfOPbgPThLCY65B5sFFqo?= =?iso-8859-1?Q?Q1DCL12Jmu3frDM6UYuuUhjzVAiyP8lYwLTTap0NnX4CIlS4Y1RFSn/nsV?= =?iso-8859-1?Q?t4ccONT5vrwaowVUlRdpput7BTMfvYW2/OXrJC/1Jh0BzwXm9v3sPI5o96?= =?iso-8859-1?Q?O0x8b+QegaT1yIKXToDfVF2+W1eftneL5zZfS/DIp+h3bTD1oSIMBMBu2F?= =?iso-8859-1?Q?xOCsJTl3YUkpM+q5J7KezQ4tvkK9jI4rwmbfDu6HNDJVoHdhKii82c7PTW?= =?iso-8859-1?Q?JILw6qzCWw=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7859.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15565d4c-221a-4211-d889-08df1a228be6 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2026 09:59:38.8009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XiCEdrpC6ZoOLj+gW2GJgIhrybuhaaD8EQap3+L0/cIxpUZdZ0/ugw1QPhNEP2NgQ21VEjOiIPVm5FYrY9nnPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7447 X-purgate-ID: tlsNG-720697/1790243995-660A82AC-CD799038/0/0 X-purgate-type: clean X-purgate-size: 475 https://gitlab.com/xen-project/websites/www-xenproject-org/-/merge_requests= /107=0A= =0A= As discussed during a design session at Xen Summit in Munich on September 1= 7, 2026, I have raised a merge request to www-xenproject-org with a draft o= f the discussed minor updates to the security policy.=0A= =0A= (Not reproducing the patch here to avoid mixing email and merge request wor= kflows)=0A= =0A= Kind Regards,=0A= Alex Brett=0A= Chief Engineer, XenServer= From xen-devel-bounces@lists.xenproject.org Thu Sep 24 10:01:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 10:01:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1431986.1653620 (Exim 4.92) (envelope-from ) id 1x9gGQ-0001g5-Sl; Thu, 24 Sep 2026 10:01:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1431986.1653620; Thu, 24 Sep 2026 10:01:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9gGQ-0001fy-PX; Thu, 24 Sep 2026 10:01:14 +0000 Received: by outflank-mailman (input) for mailman id 1431986; Thu, 24 Sep 2026 10:01:13 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9gGO-0001fq-SU for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 10:01:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9gGO-005sGi-8b for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 12:01:12 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab4f4e2-e002-0a2a0a5209dd-0a2a4508c618-40 for ; Thu, 24 Sep 2026 12:01:11 +0200 Received: from [52.101.229.100] (helo=TY3P286CU002.outbound.protection.outlook.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab4f4e4-f659-0a2a45080019-3465e564a829-3 for ; Thu, 24 Sep 2026 12:01:10 +0200 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:458::18) by TY3P286MB3565.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:3b0::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 10:01:03 +0000 Received: from OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6]) by OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM ([fe80::c8c9:25cd:8d13:96d6%6]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 10:01:03 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=valinux.co.jp header.i="@valinux.co.jp" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CcqzvtxGpGvHvPYNdJRQsEuq/g3ZNz55rGatywqb3o5nRQaNAid3HfwcATpwDVZCAYgIFA6+4fTrr567adSQm35qdgu6sfk2Sh1LBa0thsA20xYXoeBLjW9N41bRdhSAvRw+perSooQPfVOrtxP6G8aYrR9YNJwcMd2DDXfTcHQ4j0n/W5FfXeLYQMCcWvX4hqLaR+Wnf0149rdPDjEPk6VG4ZqbXtaDZxsaVGRJEXgFYcSsAjP/6SGTaNqu9gMRJegGXD17LMXSf7UAbWEa9CP/NojtIZhTANcR7GXxmrYi+peWjg9Hq9ShOuQ02WKn2NpU50U1cZ+xFJoa/MSbyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eosPRYA+qWV6MHzZOwDJvXKOUfqtl/u29cCdl+QhDMI=; b=vSZVTP35YhxpqPDD/RtdCLYL70ZZhAHNISwc7MCuwJI568UFmz4IukvzVP/gpMs9/7aET1IHXTeNvatDLPyni3eL3Kf0DwlIpgOVMfsGws4jqTzJGhvfbGYBqt7HSrjtAXQLrGmNxwN+GAsIT3TyyG9phFtOIZyD8uOeGO3gEBJmNDELfzBvO2Qbf4OZkBokflVmdVmI+x9CFBOdY0zC/z2NQ4S/JbRqRmQJAMQuRGx7DNXwk2FdKmRkZIU9qLzXr39V0pz6y33Ox0M8I/LtRslIcmrtlBZNBxYmCB2HMBVIQUtmu3P3D/NVKGrtRSX/a0Q79ghTM5pnmkz9YqruCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=valinux.co.jp; dmarc=pass action=none header.from=valinux.co.jp; dkim=pass header.d=valinux.co.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valinux.co.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eosPRYA+qWV6MHzZOwDJvXKOUfqtl/u29cCdl+QhDMI=; b=mBQi/gcZyF9ombzoMyOPz6ljblhSBEb7VB5zWxNZZ7T45l6qSPmpHrTQWRi7K5ZJfng2t/GDvG2rMLY5noBY4BBwSmOdKIkH2TyqvyyRpwW03smww4b6jgMcZbE23SIvpOFbbOS9A1szsGzTq+fY4FG3ehV28O9UugrteNt1ZUg= From: Hirokazu Takahashi To: "Orzel, Michal" , "xen-devel@lists.xenproject.org" CC: "Mykyta_Poturai@epam.com" , Jan Beulich , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH v10 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Thread-Topic: [PATCH v10 1/4] xen/device-tree: Parse 'cpu-map' node for CPU topology exploration Thread-Index: AQHdQdJsRfCfHjXnRkCNM9ynFexwX7bSuOsAgArOa5A= Date: Thu, 24 Sep 2026 10:01:03 +0000 Message-ID: References: <20260911094213.79936-1-taka@valinux.co.jp> <20260911094213.79936-2-taka@valinux.co.jp> <78d6b1a6-5a59-409a-9d44-64314a4db106@amd.com> In-Reply-To: <78d6b1a6-5a59-409a-9d44-64314a4db106@amd.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=valinux.co.jp; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: OS9P286MB7222:EE_|TY3P286MB3565:EE_ x-ms-office365-filtering-correlation-id: 3ae85d25-5339-450e-b4f1-08df1a22be46 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016|23010399003|6133799003|38070700021|22082099003|18002099003|4143699003|56012099006|10067099003; x-microsoft-antispam-message-info: tQIDYK+gqocMUGgeVqobPbhAswPyqnwx8bmfb7Zx1DtIaIr6ZLywFi3/ODW3Mx5xlUi67dzCWmX6N6692OKjy0a+82nCuhgvOkV3SoYYmIN8yrN5l4fB9y37blRyMyPzxUHGeJP/Q3ihwobf/+ScwoJoDDFG2NHOXF3i2CPlEKbIk6MC0ytej6Syz67NDrAuRNNnVygCWCOQXvlH/deIjEklENKIHtSu4H38yAB1DmfPNN2Bn+KhMBdWWK3QOhQuSuBveEh/wfgdsNRbyp0ZV6AA/kYad9gk4w47JATg+TzRV4nDVXDg7b/2DvF+tr/7/BinftxjrrrjeHTEgpVgNu24uaukz+gH2jvYlWedynfKOQXjMyd1wQmXzWUS858LAUQRwQ9c0G5WsszFKu4qhFQNAfu3x8cEC7tMlyiH8QPLPSlZYeH8iu3Kw/+uGBqnL4SmzoL5NUxTzIMcPFjD5xIhXK8P6P8326jr3OHnFsGbn18xdx/NF+EZHrDY4QTftGdg5I1Hoh7TpNWQ5S06zIQekuAKvSROMrwHUfW/jwgjGpzgqvS6Q+ogVxdjcxtISNUNV8PNX+1PMiSIdoWXGUVkrGehoMcvavPQQyukxDV9VqJ63+dFjnTidDLMFYceZ/S+FcIpGmdzWfZoJ6wXA5xrcgxEt2+F+Ltz5QLOOvi4NgdVxTTDz9PrvbN6MhBRAUBRmFh9AWRbfrMDk6U2GRZDMagVwfNnW8GKjy6bkME= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(23010399003)(6133799003)(38070700021)(22082099003)(18002099003)(4143699003)(56012099006)(10067099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RWgzQjN0enB2VU90dUlUd1FzQ21qT21YT05FLzVBc3JuYmhLQmdzWEhKenVN?= =?utf-8?B?c24wMzNwYzhGNnpOUTU5VjZSMGpiTmhiL3JVcTVrd2g2MVYxWHN4SU9ZYTR1?= =?utf-8?B?dlFvMzQ3MXN0ZXhVYk13M1ZHNjVZbDArTmpGZEZxVG1YNzljWi9ZSURlTTNp?= =?utf-8?B?VTA3RGZhMVErNllMVndtN1JiUjhORHg4Uys0WGdPUno5bXd5SzZUYzQ3c2FV?= =?utf-8?B?ZUdZOWJsS0ZaSU5MZHA4NDJKWmdlNlBySXFDY2lPZkJLdFlWbTVleU1yOFg1?= =?utf-8?B?MlVhZXlhSFo4SnFNQWw5UktsaFV3bG92TFNTbnFyNENtSkJWbnVHOGlSWXN2?= =?utf-8?B?MFFacEdaZEdHWk8yUUJGcE5BdER0d0EvRWprbzFsd3htekxRd0J1NHJSWjMw?= =?utf-8?B?elZ6SWtjNUo4SS9xVDY0WlZ3TDBrb3l4SERBSnBRN0ZpNU1OY05Cc3RIU0pr?= =?utf-8?B?SGgyNVYxaDYwdUZXS1Z5K1pZTWx2OGIyZS9NRllVR1BzTys5WThwYTJvZm5l?= =?utf-8?B?OXQ5ODBJcmkvL29IWkcrZnVIdHdnYVFKOElhT1JuTGYxNWVqWW44NURUbEJ6?= =?utf-8?B?MVJGZUJ1TnZFMXovK0k4Q1diV1RkTTVCeUNhVjFmZlgxbHA1R0t4TGtaUmNn?= =?utf-8?B?VWM3NGVVNlFGU3hCa24rMGg1UEU0a0wrOHFFTGRrKzEyRzI2cGpzK1Z6eE4w?= =?utf-8?B?SHA2cGR6Q3p1dUxiTWR6YnZZTGpacEozMWYrS2ZFb3hrMjhMWmdWM00zVVdt?= =?utf-8?B?ZUNEZWNRM2VhVldQZnNuSEhhQ3JCSXJEemtweGE0NnlDR0lqQ2FVR2hib2tN?= =?utf-8?B?Q28va1lMUS9EbEY3K1BpUWxBMUNWZ01HcE5aTUV1aHNxTU5iKzBWRmFuWnRu?= =?utf-8?B?TklJTkVVeXpUYmQ4N0c3RUNHSnk3akdielNIYWdMMVk5K3VYSmdNMWVyMGp4?= =?utf-8?B?bitTOUpuSDQyZnc1ZVRseEVwbWtoaFMraDYvKzB3OHR2Z2hxb0F2dlozbUFC?= =?utf-8?B?dk91RE9LWXpLd3dUMjhOem42SlRKQmRaakwvaVB5OFpTcDdhTlNoRnBuSTVX?= =?utf-8?B?bElpRkhYMVdqaWFPcG5xMzQ2RmJVY2lONVZwYlU5RjVTMFVHdmRSbDA0ajhB?= =?utf-8?B?bVlzdDM4d0pCNjJuMWk4WFl3eUV5RUFOQ1NsMEp3d0lmVWMzZnVSZnllQytL?= =?utf-8?B?VW9QZFZVeHNHbjRiMEp3VG1OTzNXaU8xSFdhZjhoODNSblprZ25iS0kwajJ2?= =?utf-8?B?dGZ3SG9VZW9yL0RVOGI5YnBGYS9ndmdaZkpnL1Vjd2R3NUV5cHBtVTZ1ZnM3?= =?utf-8?B?R0dxeUhrYjRnZzZ4QnN1U3VkODhCbHFvVHAya1F3M0NOdjh4RnlITHN6eW9h?= =?utf-8?B?MmRKb25oZUlLOVZQY3NYclZJenJNZ2xla1FnQVI0Q0RRNTlyOFExMDNGaGRj?= =?utf-8?B?UnlEbUlFa2I2YnJDM013Ny8vVXpGZEQxc3hHTUg1Mk92dUJmMzlCRXJ4eHFs?= =?utf-8?B?OU1qbzRBY25CaDViYXdBMWE4RnhyWmhqZHBlaWtpWUpiRmV0NjgzL01OYlJi?= =?utf-8?B?N2prd3lRNWhwaDU0cG41Z0FJdEl2dE9rSWppamhFMnFBOGc1c1FZSi9nK3h5?= =?utf-8?B?S3Z4RFJZK2VubUdTcy9aK3p2OEFxZ05EWS9KeVVBOGdkN3FXQUI4elZyZ25F?= =?utf-8?B?dWx6TDBwL3VyeERGK1ZEaWp5TVRmVWxMK05iUE00VmFwNFhMd1N3Y1k4emw2?= =?utf-8?B?VFJLdldJK0NsT1JxdktPNjR0UHd0VnlXa0ZobmZlL3lqRHdZNHMrUW5qWi91?= =?utf-8?B?K0FyY001eHdCUGZKL2krZ1VYYUpiODkraEcvWUlWdGd4WEhxRllCMXhtQm5v?= =?utf-8?B?WUdFU29jNmM0VVhJdEc2R1l2b1pHaUFualpZZ0wwUDA2VEZQWWF5UDJ2ampE?= =?utf-8?B?NnZ6bERQQkRkYm92UVhXTmhELzdzMDJyZ2ZHRTlIcDVxdFlPcUlRNTRVcDVF?= =?utf-8?B?ZWMxSnJOcTlxbmg0K1lOTWNPN0ZXajI5V2NpTk8rNkJHOC9kZzhoYWNpeFAv?= =?utf-8?B?QWEvMjBCaU9BVkladENnWWJkT3o5OTVOa2RqR2E2QlR0SFB6NEhjVTNpZ2h3?= =?utf-8?B?ZlNWd1UvYWtRQ3dIYTl1NHpVdFNma1RCNEg5UFRmNC9sOXV5UU9ScVdJRzZ5?= =?utf-8?B?QnR2U3lUZ1psS0c2NnE4K3R3YUlGaTNYbXRucHJsNUNDUEw5dzh6bWRLMkFM?= =?utf-8?B?Y3luYlpDVlRVYlNFQjBSNUN3M3F0UnQwRjY4SmRPcE82N1JQeTNFNjEyL0FO?= =?utf-8?Q?weMsjD5PXaWnRTwSZi?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: valinux.co.jp X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: OS9P286MB7222.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3ae85d25-5339-450e-b4f1-08df1a22be46 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2026 10:01:03.2295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7a57bee8-f73d-4c5f-a4f7-d72c91c8c111 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tjrIkcL7PCAk7GXC6VZamvQgSKtig49YXon4cJVKXNaOqFgw/3Q6Vcu6qzUCCsidmfTRAOKh4tvg551ACcs5zA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY3P286MB3565 X-purgate-ID: tlsNG-c1860d/1790244071-D6B4187B-731D99EA/0/0 X-purgate-type: clean X-purgate-size: 12402 SGkgTWljaGFsLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNCj4gPiBkaWZmIC0tZ2l0 IGEveGVuL2FyY2gvYXJtL3NtcGJvb3QuYyBiL3hlbi9hcmNoL2FybS9zbXBib290LmMNCj4gPiBp bmRleCAxODA2YzQ3YTA4Li45MDQxMzBlZmRmIDEwMDY0NA0KPiA+IC0tLSBhL3hlbi9hcmNoL2Fy bS9zbXBib290LmMNCj4gPiArKysgYi94ZW4vYXJjaC9hcm0vc21wYm9vdC5jDQo+ID4gQEAgLTks MTAgKzksMTIgQEANCj4gPg0KPiA+ICAjaW5jbHVkZSA8eGVuL2FjcGkuaD4NCj4gPiAgI2luY2x1 ZGUgPHhlbi9jcHUuaD4NCj4gPiArI2luY2x1ZGUgPHhlbi9jcHUtdG9wb2xvZ3kuaD4NCj4gPiAg I2luY2x1ZGUgPHhlbi9jcHVtYXNrLmg+DQo+ID4gICNpbmNsdWRlIDx4ZW4vZGVsYXkuaD4NCj4g PiAgI2luY2x1ZGUgPHhlbi9kZXZpY2VfdHJlZS5oPg0KPiA+ICAjaW5jbHVkZSA8eGVuL2RvbWFp bl9wYWdlLmg+DQo+ID4gKyNpbmNsdWRlIDx4ZW4vZHQtY3B1LXRvcG9sb2d5Lmg+DQo+ID4gICNp bmNsdWRlIDx4ZW4vZXJybm8uaD4NCj4gPiAgI2luY2x1ZGUgPHhlbi9pbml0Lmg+DQo+ID4gICNp bmNsdWRlIDx4ZW4vbW0uaD4NCj4gPiBAQCAtMjQ0LDYgKzI0Niw5IEBAIHN0YXRpYyB2b2lkIF9f aW5pdCBkdF9zbXBfaW5pdF9jcHVzKHZvaWQpDQo+ID4gICAgICAgICAgfQ0KPiA+ICAgICAgICAg IGVsc2UNCj4gPiAgICAgICAgICAgICAgdG1wX21hcFtpXSA9IGh3aWQ7DQo+ID4gKw0KPiA+ICsg ICAgICAgIC8qIFBhc3MgdGhlIGluZm8gdG8gZHRfaW5pdF9jcHVfdG9wb2xvZ3koKSAqLw0KPiA+ ICsgICAgICAgIG1hcF9jcHVfdG9fZHRfbm9kZShpLCBjcHUpOw0KPiBUaGlzIHNob3VsZCBiZSBt b3ZlZCB0byB0aGUgYWJvdmUgZWxzZSBicmFuY2ggd2hpY2ggaXMgdGFrZW4gb24gYSBzdWNjZXNz IG9ubHkuDQoNCk9rYXkuDQoNCj4gPiArY29uZmlnIEdFTkVSSUNfQ1BVX1RPUE9MT0dZDQo+ID4g Kwlib29sDQo+ID4gKw0KPiA+ICtjb25maWcgRFRfQ1BVX1RPUE9MT0dZDQo+ID4gKwlib29sICJE ZXZpY2UgdHJlZSBiYXNlZCBDUFUgdG9wb2xvZ3kgc3VwcG9ydCAoVU5TVVBQT1JURUQpIg0KPiBD YW4geW91IHBsZWFzZSBleHBsYWluIHdoeSB1bnN1cHBvcnRlZD8NCg0KSSBtYXJrZWQgaXQgYXMg VU5TVVBQT1JURUQgc2ltcGx5IGJlY2F1c2UgaXQgaXMgYSBuZXcgZmVhdHVyZS4gSG93ZXZlciwg aWYgcG9zc2libGUsDQpJIHdvdWxkIHByZWZlciB0byBkcm9wIFVOU1VQUE9SVEVEIHNvIHRoYXQg ZXZlcnlvbmUgY2FuIG1ha2UgdXNlIG9mIGl0Lg0KDQo+ID4gKwlkZXBlbmRzIG9uIEhBU19HRU5F UklDX0NQVV9UT1BPTE9HWSAmJiBERVZJQ0VfVFJFRV9QQVJTRSAmJiBVTlNVUFBPUlRFRA0KPiA+ ICsJc2VsZWN0IEdFTkVSSUNfQ1BVX1RPUE9MT0dZDQo+ID4gKwloZWxwDQo+ID4gKwkgIFJldHJp ZXZlIENQVSB0b3BvbG9neSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBkZXZpY2UgdHJlZSB0byBvcHRp bWl6ZQ0KPiA+ICsJICB2Q1BVIHNjaGVkdWxpbmcuDQo+ID4gKw0KPiA+ICtjb25maWcgQUNQSV9D UFVfVE9QT0xPR1kNCj4gPiArCWJvb2wgIkFDUEkgYmFzZWQgQ1BVIHRvcG9sb2d5IHN1cHBvcnQg KFVOU1VQUE9SVEVEKSINCj4gPiArCWRlcGVuZHMgb24gSEFTX0dFTkVSSUNfQ1BVX1RPUE9MT0dZ ICYmIEFDUEkgJiYgVU5TVVBQT1JURUQNCj4gPiArCXNlbGVjdCBHRU5FUklDX0NQVV9UT1BPTE9H WQ0KPiA+ICsJaGVscA0KPiA+ICsJICBSZXRyaWV2ZSBDUFUgdG9wb2xvZ3kgaW5mb3JtYXRpb24g ZnJvbSB0aGUgQUNQSSBQUFRUIHRvIG9wdGltaXplDQo+ID4gKwkgIHZDUFUgc2NoZWR1bGluZy4N Cj4gPiArDQoNCj4gPiArdm9pZCBfX2luaXQgaW5pdF9jcHVfdG9wb2xvZ3kodm9pZCkNCj4gPiAr ew0KPiA+ICsgICAgdW5zaWduZWQgaW50IGNwdTsNCj4gPiArICAgIGludCByZXQ7DQo+ID4gKw0K PiA+ICsgICAgY3B1X3RvcG9sb2d5ID0geHZ6YWxsb2NfYXJyYXkoc3RydWN0IGNwdV90b3BvbG9n eSwgbnJfY3B1X2lkcyk7DQo+ID4gKyAgICBpZiAoICFjcHVfdG9wb2xvZ3kgKQ0KPiA+ICsgICAg ICAgIHJldHVybjsNCj4gSSBkb24ndCB0aGluayB0aGlzIGlzIG9rIGZvciB0aGlzIGZ1bmN0aW9u IG5vdCB0byBsZXQgdGhlIGNhbGxlciBhYm91dCB0aGUNCj4gZXJyb3IuIFRoYXQncyBlc3BlY2lh bGx5IGltcG9ydGFudCBmb3IgZmFpbHVyZXMgZnJvbSBhY3R1YWwgRFQvQUNQSSB0b3BvbG9neQ0K PiBpbml0aWFsaXphdGlvbi4gWW91IGRvbid0IGV2ZW4gcHJpbnQgYW55dGhpbmcuDQoNCkkgd2ls bCBhZGQgYW4gZXJyb3IgbWVzc2FnZSB3aGVuIG1lbW9yeSBhbGxvY2F0aW9uIGZhaWxzLg0KDQo+ ID4gK3N0YXRpYyB2b2lkIF9faW5pdCBzZXR1cF9zaWJsaW5nc19tYXNrcyh1bnNpZ25lZCBpbnQg dGFyZ2V0X2NwdSkNCj4gPiArew0KPiA+ICsgICAgY29uc3Qgc3RydWN0IGNwdV90b3BvbG9neSAq dGFyZ2V0X3RvcG8gPSAmY3B1X3RvcG9sb2d5W3RhcmdldF9jcHVdOw0KPiA+ICsgICAgY29uc3Qg c3RydWN0IGNwdV9tYXAgKnRhcmdldF9tYXAgPSAmY3B1X21hcFt0YXJnZXRfY3B1XTsNCj4gPiAr ICAgIHVuc2lnbmVkIGludCBjcHU7DQo+ID4gKw0KPiA+ICsgICAgLyogVXBkYXRlIGNsdXN0ZXIs IGNvcmUgYW5kIHRocmVhZCBzaWJsaW5nIG1hc2tzICovDQo+ID4gKyAgICBmb3JfZWFjaF9wb3Nz aWJsZV9jcHUoY3B1KQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGNvbnN0IHN0cnVjdCBjcHVf dG9wb2xvZ3kgKmNwdV90b3BvID0gJmNwdV90b3BvbG9neVtjcHVdOw0KPiA+ICsgICAgICAgIGNv bnN0IHN0cnVjdCBjcHVfbWFwICptYXAgPSAmY3B1X21hcFtjcHVdOw0KPiA+ICsNCj4gPiArICAg ICAgICBpZiAoIHRhcmdldF9jcHUgPiBjcHUgKQ0KPiA+ICsgICAgICAgICAgICBjb250aW51ZTsN Cj4gPiArDQo+ID4gKyAgICAgICAgaWYgKCB0YXJnZXRfbWFwLT5zb2NrZXRfaWQgIT0gbWFwLT5z b2NrZXRfaWQgKQ0KPiA+ICsgICAgICAgICAgICBjb250aW51ZTsNCj4gPiArDQo+ID4gKyAgICAg ICAgY3B1bWFza19zZXRfY3B1KHRhcmdldF9jcHUsIGNwdV90b3BvLT5jb3JlX3NpYmxpbmcpOw0K PiA+ICsgICAgICAgIGNwdW1hc2tfc2V0X2NwdShjcHUsIHRhcmdldF90b3BvLT5jb3JlX3NpYmxp bmcpOw0KPiBUaGlzIGRvZXMgbm90IGNvbXBpbGUuDQoNCkkgd2lsbCBmaXggdGhpcy4gSW4gbXkg bG9jYWwgZW52aXJvbm1lbnQsIE5SX0NQVVMgd2FzIHNldCB0byBhIGxhcmdlIHZhbHVlIHdoZXJl IHRoZSBiaXRtYXAgYXJlYQ0KYmVjb21lcyBhbiBpbmRpcmVjdCBwb2ludGVyLCBzbyBJIGRpZG4n dCBjYXRjaCB0aGlzIGNvbXBpbGF0aW9uIGlzc3VlLg0KDQo+ID4gKw0KPiA+ICsgICAgICAgIGlm ICggdGFyZ2V0X21hcC0+Y2x1c3Rlcl9pZCAhPSBtYXAtPmNsdXN0ZXJfaWQgKQ0KPiA+ICsgICAg ICAgICAgICBjb250aW51ZTsNCj4gPiArDQo+ID4gKyAgICAgICAgY3B1bWFza19zZXRfY3B1KHRh cmdldF9jcHUsIGNwdV90b3BvLT5jbHVzdGVyX3NpYmxpbmcpOw0KPiA+ICsgICAgICAgIGNwdW1h c2tfc2V0X2NwdShjcHUsIHRhcmdldF90b3BvLT5jbHVzdGVyX3NpYmxpbmcpOw0KPiA+ICsNCj4g PiArICAgICAgICBpZiAoIHRhcmdldF9tYXAtPmNvcmVfaWQgIT0gbWFwLT5jb3JlX2lkICkNCj4g PiArICAgICAgICAgICAgY29udGludWU7DQo+ID4gKw0KPiA+ICsgICAgICAgIGNwdW1hc2tfc2V0 X2NwdSh0YXJnZXRfY3B1LCBjcHVfdG9wby0+dGhyZWFkX3NpYmxpbmcpOw0KPiA+ICsgICAgICAg IGNwdW1hc2tfc2V0X2NwdShjcHUsIHRhcmdldF90b3BvLT50aHJlYWRfc2libGluZyk7DQo+ID4g KyAgICB9DQo+ID4gK30NCj4gPiArDQo+ID4gK3N0YXRpYyBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNl X25vZGUgKl9faW5pdCBkdF9maW5kX2NoaWxkX25vZGVfYnlfbmFtZSgNCj4gPiArICAgIGNvbnN0 IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZHQsDQo+ID4gKyAgICBjb25zdCBjaGFyICpuYW1lKQ0K PiA+ICt7DQo+ID4gKyAgICBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5wOw0KPiA+ICsN Cj4gPiArICAgIGR0X2Zvcl9lYWNoX2NoaWxkX25vZGUoZHQsIG5wKQ0KPiA+ICsgICAgICAgIGlm ICggbnAtPm5hbWUgJiYgKGR0X25vZGVfY21wKG5wLT5uYW1lLCBuYW1lKSA9PSAwKSApDQo+ID4g KyAgICAgICAgICAgIHJldHVybiBucDsNCj4gUGxlYXNlIHVzZSBkdF9ub2RlX25hbWVfaXNfZXF1 YWwoKSBoZXJlLg0KDQpPa2F5Lg0KDQoNCj4gPiArDQo+ID4gK3N0YXRpYyBib29sIF9faW5pdCBp c19jcHVfbWFwX2VtcHR5KCB1bnNpZ25lZCBpbnQgY3B1ICkNCj4gU3RyYXkgc3BhY2UgYXQgdGhl IGVuZCAiY3B1ICkiDQoNCk9rYXkuDQoNCj4gPiArew0KPiA+ICsgICAgcmV0dXJuIChjcHVfbWFw W2NwdV0uc29ja2V0X2lkID09IElOVkFMSURfVE9QT19JRCkgJiYNCj4gPiArICAgICAgICAgICAo Y3B1X21hcFtjcHVdLmNsdXN0ZXJfaWQgPT0gSU5WQUxJRF9UT1BPX0lEKSAmJg0KPiA+ICsgICAg ICAgICAgIChjcHVfbWFwW2NwdV0uY29yZV9pZCA9PSBJTlZBTElEX1RPUE9fSUQpICYmDQo+ID4g KyAgICAgICAgICAgKGNwdV9tYXBbY3B1XS50aHJlYWRfaWQgPT0gSU5WQUxJRF9UT1BPX0lEKTsN Cj4gPiArfQ0KPiA+ICsNCj4gPiArc3RhdGljIGludCBfX2luaXQgcGFyc2VfY29yZShjb25zdCBz dHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmNvcmUsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdW5zaWduZWQgaW50IHNvY2tldF9pZCwNCj4gPiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB1bnNpZ25lZCBpbnQgY2x1c3Rlcl9pZCwNCj4gPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB1bnNpZ25lZCBpbnQgY29yZV9pZCkNCj4gPiArew0KPiA+ICsgICAgYm9vbCBs ZWFmID0gdHJ1ZTsNCj4gPiArICAgIHVuc2lnbmVkIGludCB0aHJlYWRfaWQ7DQo+ID4gKyAgICB1 bnNpZ25lZCBpbnQgY3B1Ow0KPiA+ICsNCj4gPiArICAgIGZvciAoIHRocmVhZF9pZCA9IDA7IDsg dGhyZWFkX2lkKysgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGNvbnN0IHN0cnVjdCBkdF9k ZXZpY2Vfbm9kZSAqdGhyZWFkOw0KPiA+ICsgICAgICAgIGNoYXIgbmFtZVsyMF07DQo+ID4gKw0K PiA+ICsgICAgICAgIHNucHJpbnRmKG5hbWUsIHNpemVvZihuYW1lKSwgInRocmVhZCV1IiwgdGhy ZWFkX2lkKTsNCj4gPiArICAgICAgICB0aHJlYWQgPSBkdF9maW5kX2NoaWxkX25vZGVfYnlfbmFt ZShjb3JlLCBuYW1lKTsNCj4gPiArDQo+ID4gKyAgICAgICAgaWYgKCAhdGhyZWFkICkNCj4gPiAr ICAgICAgICAgICAgYnJlYWs7DQo+ID4gKw0KPiA+ICsgICAgICAgIGxlYWYgPSBmYWxzZTsNCj4g PiArICAgICAgICBjcHUgPSBnZXRfY3B1X2Zvcl9ub2RlKHRocmVhZCk7DQo+ID4gKw0KPiA+ICsg ICAgICAgIGlmICggY3B1ID09IElOVkFMSURfVE9QT19JRCApDQo+ID4gKyAgICAgICAgew0KPiA+ ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPiA+ICsgICAgICAgICAgICAgICAgICAg IkVSUk9SOiAlczogQ2FuJ3QgZ2V0IENQVSBmb3IgdGhyZWFkXG4iLCBkdF9ub2RlX25hbWUodGhy ZWFkKSk7DQo+IE5vIG5lZWQgZm9yIHRoZSBFUlJPUi9XQVJOSU5HIHByZWZpeGVzLiBZb3UgYWxy ZWFkeSB1c2UgY29ycmVjdCB4ZW5sb2cgbGV2ZWxzLg0KDQpPa2F5Lg0KDQoNCj4gPiArc3RhdGlj IGludCBfX2luaXQgcGFyc2VfY2x1c3Rlcihjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmNs dXN0ZXIsDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50 IHNvY2tldF9pZCwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25l ZCBpbnQgY2x1c3Rlcl9pZCkNCj4gPiArew0KPiA+ICsgICAgYm9vbCBoYXNfY29yZXMgPSBmYWxz ZTsNCj4gPiArICAgIGludCByZXQgPSAwOw0KPiA+ICsNCj4gPiArICAgIGlmICggZHRfZmluZF9j aGlsZF9ub2RlX2J5X25hbWUoY2x1c3RlciwgImNsdXN0ZXIwIikgKQ0KPiA+ICsgICAgew0KPiA+ ICsgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORw0KPiBYRU5MT0dfRVJST1I/DQoNCk9rYXku DQoNCj4gPiArICAgICAgICAgICAgICAgIldBUk5JTkc6IFRvcG9sb2d5IGZvciBjbHVzdGVycyBv ZiBjbHVzdGVycyBub3QgeWV0IHN1cHBvcnRlZFxuIik7DQo+ID4gKyAgICAgICAgcmV0dXJuIC1F SU5WQUw7DQo+ID4gKyAgICB9DQo+ID4gKw0KDQo+ID4gK3N0YXRpYyBpbnQgX19pbml0IHBhcnNl X2R0X3RvcG9sb2d5KHZvaWQpDQo+ID4gK3sNCj4gPiArICAgIGNvbnN0IHN0cnVjdCBkdF9kZXZp Y2Vfbm9kZSAqY3B1czsNCj4gPiArICAgIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbWFw Ow0KPiA+ICsNCj4gPiArICAgIGNwdXMgPSBkdF9maW5kX25vZGVfYnlfcGF0aCgiL2NwdXMiKTsN Cj4gPiArICAgIGlmICggIWNwdXMgKQ0KPiA+ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPiA+ ICsNCj4gPiArICAgIG1hcCA9IGR0X2ZpbmRfY2hpbGRfbm9kZV9ieV9uYW1lKGNwdXMsICJjcHUt bWFwIik7DQo+ID4gKyAgICBpZiAoICFtYXAgKQ0KPiA+ICsgICAgICAgIHJldHVybiAtRU5PRU5U Ow0KPiA+ICsNCj4gPiArICAgIHJldHVybiBwYXJzZV9wYWNrYWdlKG1hcCk7DQo+IExpbnV4IGVu ZHMgdGhpcyBmdW5jdGlvbiB3aXRoIGZvcl9lYWNoX3Bvc3NpYmxlX2NwdSgpLiBXaGF0J3MgdGhl IHJlYXNvbiBmb3INCj4gZHJvcHBpbmcgaXQgZm9yIG91ciBjYXNlPw0KDQpJbiB0aGUgTGludXgg a2VybmVsLCBwYXJzZV9kdF90b3BvbG9neSgpIGNoZWNrcyBhdCB0aGUgZW5kIHRoYXQgbm8gQ1BV J3MgcGFja2FnZV9pZCByZW1haW5zIHVuaW5pdGlhbGl6ZWQuDQpJbiB0aGUgY3VycmVudCBYZW4g Q1BVIHRvcG9sb2d5IHBhdGNoLCBJIG1vZGlmaWVkIHRoaXMgbG9naWMgYXMgZm9sbG93czoNCiAt IFJlbmFtZWQgTGludXgncyBwYWNrYWdlX2lkIHRvIHNvY2tldF9pZC4NCiAtIElmIHRoZXJlIGlz IG5vIHNvY2tldCBub2RlIGRlZmluaXRpb24gaW4gdGhlIERldmljZSBUcmVlIGNwdS1tYXAgbm9k ZSwgYWxsIENQVXMgYXJlIGFzc3VtZWQgdG8gcmVzaWRlIG9uDQogIHNvY2tldCAwIChzb2NrZXRf aWQgPSAwKS4gQXMgYSByZXN1bHQsIHNvY2tldF9pZCB3aWxsIG5vIGxvbmdlciByZW1haW4gLTEg KElOVkFMSURfVE9QT19JRCkuDQoNCklmIHlvdSB0aGluayBhbiBleHBsaWNpdCBlcnJvciBjaGVj ayBpcyBzdGlsbCBuZWVkZWQgaGVyZSwgd291bGQgYWRkaW5nIGFuIEFTU0VSVCgpIG9yIEJVR19P TigpIHRvIHZlcmlmeQ0KdGhhdCBubyBDUFUgaGFzIHNvY2tldF9pZCA9PSBJTlZBTElEX1RPUE9f SUQgYmUgdGhlIHByZWZlcnJlZCBhcHByb2FjaD8NCg0KKw0KPiA+IGRpZmYgLS1naXQgYS94ZW4v ZHJpdmVycy9hY3BpL3RvcG9sb2d5LmMgYi94ZW4vZHJpdmVycy9hY3BpL3RvcG9sb2d5LmMNCj4g PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPiA+IGluZGV4IDAwMDAwMDAwMDAuLjA5MGM3OTNmMzMN Cj4gPiAtLS0gL2Rldi9udWxsDQo+ID4gKysrIGIveGVuL2RyaXZlcnMvYWNwaS90b3BvbG9neS5j DQo+ID4gQEAgLTAsMCArMSw0MSBAQA0KPiA+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjog R1BMLTIuMC1vbmx5ICovDQo+ID4gKw0KPiA+ICsjaW5jbHVkZSA8eGVuL2FjcGkuaD4NCj4gPiAr I2luY2x1ZGUgPHhlbi9jcHUtdG9wb2xvZ3kuaD4NCj4gPiArI2luY2x1ZGUgPHhlbi9jcHVtYXNr Lmg+DQo+ID4gKyNpbmNsdWRlIDx4ZW4vaW5pdC5oPg0KPiA+ICsNCj4gPiArLyoNCj4gPiArICog VE9ETzogUG9wdWxhdGUgdGhlIHRvcG9sb2d5IGluZm9ybWF0aW9uIGJ5IHNjYW5uaW5nIHRoZSBB Q1BJDQo+ID4gKyAqICAgICAgIFBQVFQgKFByb2Nlc3NvciBQcm9wZXJ0aWVzIFRvcG9sb2d5IFRh YmxlKS4NCj4gPiArICovDQo+ID4gK2ludCBfX2luaXQgYWNwaV9pbml0X2NwdV90b3BvbG9neSh2 b2lkKQ0KPiA+ICt7DQo+ID4gKyAgICB1bnNpZ25lZCBpbnQgY3B1Ow0KPiBUaGUgY29ycmVzcG9u ZG9uZyBEVCBmdW5jdGlvbiBoYXMgdHdvIEFTU0VSVHMuIFdoeSB0aGUgZGl2ZXJnZW5jZSBoZXJl PyBBdCBsZWFzdA0KPiB0aGUgb25lIGZvciBjcHVfdG9wb2xvZ3kgZXhpc3RpbmcgaXMgYSBnb29k IG9uZSAoSSBkb24ndCBjb25zaWRlciB0aGUgZmlyc3QNCj4gQVNTRVJUIHZlcnkgdXNlZnVsKS4N Cg0KT2theS4NCg0KPiA+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4vY3B1LXRvcG9sb2d5 LmgNCj4gYi94ZW4vaW5jbHVkZS94ZW4vY3B1LXRvcG9sb2d5LmgNCj4gPiBuZXcgZmlsZSBtb2Rl IDEwMDY0NA0KPiA+IGluZGV4IDAwMDAwMDAwMDAuLjdjZmUzNzUyY2QNCj4gPiAtLS0gL2Rldi9u dWxsDQo+ID4gKysrIGIveGVuL2luY2x1ZGUveGVuL2NwdS10b3BvbG9neS5oDQo+ID4gQEAgLTAs MCArMSwzNCBAQA0KPiA+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5 ICovDQo+ID4gKw0KPiA+ICsjaWZuZGVmIFhFTl9DUFVfVE9QT0xPR1lfSA0KPiA+ICsjZGVmaW5l IFhFTl9DUFVfVE9QT0xPR1lfSA0KPiA+ICsNCj4gPiArI2luY2x1ZGUgPHhlbi9jcHVtYXNrLmg+ DQo+IFlvdSBjYW4gbW92ZSBpdCB1bmRlciAjaWZkZWYgd2hlcmUgeW91IGFjdHVhbGx5IHVzZSB0 aGVzZSB0eXBlcy4NCg0Kb2theS4NCg0KPiA+IC0tLSAvZGV2L251bGwNCj4gPiArKysgYi94ZW4v aW5jbHVkZS94ZW4vZHQtY3B1LXRvcG9sb2d5LmgNCj4gPiBAQCAtMCwwICsxLDM1IEBADQo+ID4g Ky8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4gPiArDQo+ID4g KyNpZm5kZWYgWEVOX0RUX0NQVV9UT1BPTE9HWV9IDQo+ID4gKyNkZWZpbmUgWEVOX0RUX0NQVV9U T1BPTE9HWV9IDQo+ID4gKw0KPiA+ICsjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQo+IFlvdSBjYW4g bW92ZSBpdCB1bmRlciAjZWxzZSB3aGljaCBpcyB3aGVyZSB5b3UgYWN0dWFsbHkgdXNlIHRoZSBl cnJubyBjb2RlLg0KDQpPa2F5Lg0KDQpUaGFuayB5b3UsDQpIaXJva2F6dSBUYWthaGFzaGkuDQo= From xen-devel-bounces@lists.xenproject.org Thu Sep 24 11:04:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 11:04:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432075.1653629 (Exim 4.92) (envelope-from ) id 1x9hFi-0002qr-Am; Thu, 24 Sep 2026 11:04:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432075.1653629; Thu, 24 Sep 2026 11:04:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9hFi-0002qj-7x; Thu, 24 Sep 2026 11:04:34 +0000 Received: by outflank-mailman (input) for mailman id 1432075; Thu, 24 Sep 2026 11:04:32 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9hFg-0002qd-OD for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:04:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9hFg-0066Q8-58 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:04:32 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab503bb-2eae-0a2a0a5409dd-0a2a4509a6ee-8 for ; Thu, 24 Sep 2026 13:04:31 +0200 Received: from [52.101.201.64] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab503bb-be1a-0a2a45090019-3465c940ba58-3 for ; Thu, 24 Sep 2026 13:04:31 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by SA6PR03MB7662.namprd03.prod.outlook.com (2603:10b6:806:440::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 11:04:25 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Thu, 24 Sep 2026 11:04:25 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UOmgZoXdcNCLlJwCzRrjcPkWLATw5zT2hs1nEv9/KbNpeD3mbvrUG8QQffEAQRTQ9/ItMxzGNont7vSyf+9137H+s9IpWo+kBhw5Dgi+BXXIJ4iIahLxMFRPexU3zkg2f68ay0TuOk/azI/bH8Ezj5UWJhBYOydU0Y7UIsZqVc+ftGCTvBzo1kv+t5vaI/zxb6eDvNMeyYH9ocA41ywzg8bpO6INkxCqFFtqEFeb9VxYrv3Ap1FOEi5Qp3rdKz0MAaXl+xTraF6thceTdNWh7GXlkjX+qLHm0dEdd7an0cTypgY3v0nnPcyLraY6evJKN5rFZDanhDyuOS/q037uIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YjnJp/V8OCyTrgEon0AYzsgSNPl/j1SefIzFcC4Nmpo=; b=WoRcCOc4tzp/PTVrEQ1u5P5kpbtJLHlISLF3ULHDQC8PJnodFRHp+xiDenxZe6ZLHhVoPCjPhZrPRWJO3J13JrJ88JtKgnpOPwLey1P93pEo9HFwnSrTuFMS40lZiV0yf4FM7OL7RNIgNLKm0tT53faf6AVvvLMEW5Nk+Cq6mCxhreScys1TWjkl0jcNU3FWdYQNRw6Mu5FXURrVxkC1ivInslglieonEaWsW+7WQdrPXn2jlsS8GYgwNTkX6EfYSGTq6lJMPQEAaC3eYmAqxRIH7QNulu7qRJZZ/yszc5n+Tz6SiOn04Q9C8Vrb3f6vjS1Q2qL9iW91WLOZmKsMYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YjnJp/V8OCyTrgEon0AYzsgSNPl/j1SefIzFcC4Nmpo=; b=ktHPEYLBg5acH6EmlDo0C4eDti+v/3Dc0wP6+G0tZExrMxFd3t6GtY/GSXQMwb9cHQY4OLWAs+n9nOAtJDltfpQvo/jL9VEhzGlxm0AsgdX/O/hmrPmaCZMIngAYyrar9PRGbmjm3Rd0GHsHzmuXLIaHMtObaMib13FFxrNZ0S0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Ross Lagerwall To: xen-devel@lists.xenproject.org Cc: Ross Lagerwall , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/hvm: Clamp Viridian features to known set Date: Thu, 24 Sep 2026 12:03:42 +0100 Message-ID: <20260924110342.1045230-1-ross.lagerwall@citrix.com> X-Mailer: git-send-email 2.55.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: DUZPR01CA0330.eurprd01.prod.exchangelabs.com (2603:10a6:10:4ba::26) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|SA6PR03MB7662:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f98f0bd-e29a-417b-699e-08df1a2b9887 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|6133799003|18002099003|10067099003|56012099006|11063799006|5023799004; X-Microsoft-Antispam-Message-Info: Gi9P1GNK2XTgS2ROdcVvdH/NKfHnNeZmeClYajDGs13bxFN/HmIicn03S/Hvqj+khSionZnqwkMvbO5Zpn95CpwgyzCnWHNa4hxJCLbFVv/H5lQbS1eFM87WNNfQVN3LQ7Irzxq7maXWLvS7JJLgiRiQRcD0hfD7Pu/IzhTFNp9qavQA7X2CxKBeJj1H477MDNDz4Z1o0ZRwZUVZqtcDhflwMXBiz5Lv2tfmuweTi3Rpz/oQxhxSIh2D5pEOYnjxPIaN17KrIXSLfvpXBW0Ak1LVaJzaOcRgo27NzoDTm91vNe9cUDHSr4kiuRp19comb3ZxVeDuouy2UA4pJgCkDNcIV14shQOO7ip83Lq1kmclj0zy89cgFeTOLsjjvirjYRyv6l8kEEPCgxXNlZlnTUrfhOuzZ9RaCU4rWB8OEymLRCgt9E+/zfHFJgHNgGT0yZGPJ6lMfwqNfUB4sxY9WQI5ue3oj4qiDsfIVuCHdtzp/hSdG4szpsGjkAv63oNiXKs2IHh6PmSjU4Hvu1Dmaewlp9a4LyHAxgGTp0AvpvEUNqijqLSIwkYZUf4zom8mjUufs7WWMJxFZzuDxlr7Eo6bVuAF2qkOjTI36UCza6OsNJAmkYjUSaarhgBOxgy/dkgimcIWUYyXOF7yDmg1GUGSv3RJorL9UB46oVHtonc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(6133799003)(18002099003)(10067099003)(56012099006)(11063799006)(5023799004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uhRK/qIfqNHfdWt98CfW7toc1iVLdD2gUF04hdB4DVNZ/9v3weqMm4J9aZFY?= =?us-ascii?Q?LXeMYZ8LkjNKXl1xtDVQ57Hh3GXb1n/MjCRhLLGHJ8gzHgrcWnVngjTbB6+w?= =?us-ascii?Q?/o6RMVSKwzoAcuCX1MfHnMWlzLyXdQQ3sNn38Ze+jMfOn2EDKSafSwHsw/Ce?= =?us-ascii?Q?pP28US2agWK6C/OXfCIHUn4zQc/bxSu8cpk2QguF1qAC4rrbtbxUH7HF2bgb?= =?us-ascii?Q?znv/sFWJg7xfpJGMJaCfMX++vnoTJlOv8wKY6xa2Rg5TxP4ZYKRs1aTuZgSx?= =?us-ascii?Q?nBgPuaTwx7L98B94HTdVfrE/CBxVjnSfB8F8bVJEkjXD4obzdnp5yTqCMByd?= =?us-ascii?Q?9viSng0YzoZWna9J5th4eI3NIwYjhMgq34UQ0lI+Ix1Kb/vIL51IFsnvyn2L?= =?us-ascii?Q?cehluRSHzOYkz9Tv0yLpO2d19hNL0wdxZQdRPS8EMo9CUSxv87c1yFtNcpJN?= =?us-ascii?Q?jjDk0p4XwjJ+i1s75nFPagqiiU4aSdBmZqWHmjvRR6eA/3MaoabIYaOkPadR?= =?us-ascii?Q?0S8OpEnZFvPCKNcVAeNmStX+ZwdOrREW7U80XktDqp+fTvNbuBI+WaHvxY+/?= =?us-ascii?Q?uUITnGn9HtMTDCxcXG9aWRDUZ8A5Yeda2N7GfUIZVJCjxkXoh8sAhFo6e+a+?= =?us-ascii?Q?VC139Y8f8FXhIlQjpf1jbqWPK4y1tf+MhrsYNSWIDn2/556mUMMfYiCSwOJu?= =?us-ascii?Q?JrzqNQoKm1w0Ba4pBQ1QToPnCL9rEPjsQuLA9q7cyfxdegvzMkyvIqW2zej0?= =?us-ascii?Q?zgIQs11CT9GXpPuok0CdLRIVaaSESEfDtRNABg0o91mgSb4jqm69Y9ZORtZP?= =?us-ascii?Q?723yvh8daSOJjYs976ptS+NS5Ax1mrz7OdP14j3ex/m6/8WJ1gBn8pExGJFO?= =?us-ascii?Q?iOgd9onxCwAToGUUubw2CKiwBBjks1Zdz5tm4E5CxWwjwFndgA/55XijcCQp?= =?us-ascii?Q?H1VKT6/Itb3sSgwHMYudtlUmYEmqtlYmh69ZRXt0FF2UhrBtILV/ZeSWvETw?= =?us-ascii?Q?9F5pV221jSx3VZJTSbb/8/AmHBtIP5y9pxEkMMJM9NipAaGzsb/7IxZZpM4s?= =?us-ascii?Q?Xu2Ie8dREhUDjDn5kYWOMdLrity0SYqdj9XzhbommNVIiTVkOd86+3xLHxB0?= =?us-ascii?Q?YDwkmLkbLkvByPIsXWa7C+gjxJEzQSwKCbeynf5CzbnBByfsvaWZPtUbGQKR?= =?us-ascii?Q?cCBemrF7ylBeYie2jly94+AZBtBp2PoPnsjoGcgfleO+pFAeWRXUOBnY4ONY?= =?us-ascii?Q?frvDQw6zbDFyxuC7PyUk70Tp4ti/OKqjvNHIT+HLPCH+QzrS1/RDwSzOomly?= =?us-ascii?Q?TotN42VNLA6RBoXwk6AxKmEojqZyH8JTBm8izCjrxEqZAXuL7aETZu4e5KYG?= =?us-ascii?Q?z9y1Vzd1BY9jVFB0F0KVKaS9VavER9R0tgIOHZ0NQONbjlOJ+P/5gGAyUIam?= =?us-ascii?Q?6HBIwbmNuEiGAZSg/L6chIOhhO3J3R6S43GcwwJbixnjRrLsnvPZ3xO27yIo?= =?us-ascii?Q?/XhX6tUixE6aBnd/49BtnHG+8svOteQZscmGTqYI1BYym6XWRBGVbYiDaV02?= =?us-ascii?Q?VdST1WS/rX2MxLUlb1FzFJwmFm0CODz/Ag7Gr4Zxx88x3xhYp12SefWUkjlL?= =?us-ascii?Q?0QKdParKVAbcU9j58t2L0Xpt2LplBtWa1A4A/7bZNOkNEFoBPQAoZRd4nERj?= =?us-ascii?Q?TWWHPY5pGBqrBUjfZvQjaJe/In6tB4zagz4uYHZCUvb6UVCniJk7V15lWML1?= =?us-ascii?Q?ns1xU36CS/dwDXiPU7PY33dWPQQfxq0=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f98f0bd-e29a-417b-699e-08df1a2b9887 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 11:04:25.5487 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8r0TpUTZj3fn9xx9Vwun3f2q74UijAp/zE7mvI8OqKNgG75zVhprS7itJoltOcle63jOBBufoUfxixx12VxnlmiYgKwmpE79i9JSnl9Iajs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7662 X-purgate-ID: tlsNG-bad1c0/1790247871-BFCD7034-FDCBC06C/0/0 X-purgate-type: clean X-purgate-size: 1115 Instead of returning EINVAL on an unknown feature bit, clamp to the known feature set. This simplifies upgrades since when the hypervisor and toolstack are updated without an immediate reboot, the toolstack may set unknown feature bits and the existing behaviour leaves the VM without any Virdian features enabled. Signed-off-by: Ross Lagerwall --- xen/arch/x86/hvm/hvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 192309c2fccc..67afa00a0f13 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4234,8 +4234,10 @@ static int hvm_set_param(struct domain *d, uint32_t index, uint64_t value) case HVM_PARAM_VIRIDIAN: if ( !IS_ENABLED(CONFIG_VIRIDIAN) ) rc = -ENODEV; - else if ( (value & ~HVMPV_feature_mask) || !(value & HVMPV_base_freq) ) + else if ( !(value & HVMPV_base_freq) ) rc = -EINVAL; + + value &= HVMPV_feature_mask; break; case HVM_PARAM_IDENT_PT: /* -- 2.55.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 24 11:20:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 11:20:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432093.1653639 (Exim 4.92) (envelope-from ) id 1x9hVG-0005ki-Kv; Thu, 24 Sep 2026 11:20:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432093.1653639; Thu, 24 Sep 2026 11:20:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9hVG-0005kb-Gv; Thu, 24 Sep 2026 11:20:38 +0000 Received: by outflank-mailman (input) for mailman id 1432093; Thu, 24 Sep 2026 11:20:36 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9hVE-0005kV-M4 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:20:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9hVE-0059a1-2S for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:20:36 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab50779-2eae-0a2a0a5409dd-0a2a4502d790-28 for ; Thu, 24 Sep 2026 13:20:35 +0200 Received: from [52.101.46.69] (helo=CO1PR03CU002.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab50780-6ca4-0a2a45020019-34652e45d27a-3 for ; Thu, 24 Sep 2026 13:20:35 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB989329.namprd03.prod.outlook.com (2603:10b6:510:3bc::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.13; Thu, 24 Sep 2026 11:20:30 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0428.015; Thu, 24 Sep 2026 11:20:30 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=a8EhlMAxNe+M3ryWBeCR27g29Fs8ZPKWXbCD7txTsJm0ovdXgukG4ngx9RTKt6P4sZVcfwRkq1sY5K/xFalbTMVKNKX0ApvygSeWCljkbAUF+3QvBOkFferR4IAwHxLKU0zeY+ztROY8vAu2DDHyTvYltkd0kdH9NJMXTgQO2KI3/8Mwp7tgttxU1IJ3icbka4TtqOFJQss8NmEZlXxWU02Qs1lPLLmByeblpAiPkopb9PNEL7HM0lZ/Eltv8t2Rf9mVTvRqWi8q65IxPGYqPVz5VXU6qVUDKnANg2AM8bGGlT2GtZq9WJMiRgBQyf0A2q3dckGKuy2dhsF9lrTGSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bkMPe0iTwG6ARSFHo6bi3VNGOcjGzc4CiGEWspknZsw=; b=bzxO2HO1sR5QqRc46xPEA726+YsASIjfCisFaR2BG2ArS9JhYPSnTAf8co7KpT6ET6vHban5A1PFoDeKkZTFF2KsexREa6bRn099uv5Qvv+uu0qwTbIRojbozmsNvR9QPey4bAUccAYxZXxJBBl3sLhFoGbSz/pso43MI2RgTTbJ3NXZOQIFPDc5WsIjjFMoXQtSjKuJsG/kOMZNPXaHSHeSN3fb6Yt3qNClze8iFGjtoTjtt7SatBtgR7xolw3u3frJFDAwHk99Tq88+PvykA24JCMeNDw7DUwBwO5pxKeNJoYBbuluOQlU2tN+J1OTlnB8+UwVfSlCRMrVUHAb8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bkMPe0iTwG6ARSFHo6bi3VNGOcjGzc4CiGEWspknZsw=; b=oOEW2UMyO43n9dJ0BW9XKQaj/GIRRiSJZOLAAq5QAjIDIds2ULlPTYVFI/k5rhlMuuFb2CxNJIIFQGnSeoTrQ9JRYCFp22vmcLm52CY0wBiZ0aJs8QDyLQt8RNS3ls/AdRvM1V7W/5gyiDFf5ElQz0ixvbKhDqkqh1x5ymV3QQo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 24 Sep 2026 12:20:27 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH] x86/hvm: Clamp Viridian features to known set To: Ross Lagerwall , xen-devel@lists.xenproject.org References: <20260924110342.1045230-1-ross.lagerwall@citrix.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20260924110342.1045230-1-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0036.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::23) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB989329:EE_ X-MS-Office365-Filtering-Correlation-Id: 309931d2-30df-452b-5b8f-08df1a2dd7bb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|23010399003|6133799003|10067099003|11063799006|5023799004|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: hMqXiQktY/uNn33aws754epiiMXp7zafqSM3BgNQ2jD9aWduaXlRekOZAUrtS1Ss9wkcyPQESMmJdLZHb93Zm69FEU3Ss4uDV2nu1EU+KJ1BnSAG82+0DL9uOCswdI4yb9pTWJYSvBIoCKSqiCqJRZ3jtnhBe6LRcERg4wZjvjAiPlNXfJkAPJkSqCl4vT04XxtzAQvmdM3lWqTIy9IabGnAq6AyqfWMh0Fl0+TbdRIRmcanCFSJpv3T6dczt50MyZviGRIC5Q91h2Wa5o3TGlrYCwaFXUy1CEwO6sou04iP0QKjBKJOIp0HpZ2CpO04GhXghAmLnXKMS+eOtLbVmmzm8k22N9/LU4gaFt/P/yHAgzK2ZB7zDDcuq1Xmb+R3vuSgAE8Bbj0dn8js+mix2odoJOwQwjnrr8bFQsbAiggu93QDLt75K+UNBzle71TJHIfqN6ZsbIfMPAgstvCDdj4GOTJFBVmkXwRp4UobxEa846sNfPbzr1vBTdjcZ3g8CKHmOaIaTXOc+xJIUrMZ1SERlizAiU+7Ox8np4SEQP/muPudTxOMCupf5nYMdqPs5QDhYhBFQJitxKS3CENrKmfE5CMxGnwwy6kFcuDPpnLBK6uS89OhBEaZjeA9jY8PRDs3Rg8eaaRKoidT37FtbNibBlbfWSjE9YI33ATxxoA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(23010399003)(6133799003)(10067099003)(11063799006)(5023799004)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?akJQQStOZTVDRWxNSDdJbUN2UnZ0M2RaZlowTllodE83SnhhaDJRS0hQRGhL?= =?utf-8?B?RXpLMVhZdWdHZjdqWjdwdWdCbEdJVytiZmRoOTVyMHhlbU9FdDBoK1ZWYnNL?= =?utf-8?B?WitzczljWTJWWitpVzVvQXRPckQwUlN0VWNGdnR3ZnpCR2djNXRtNkpaVGVJ?= =?utf-8?B?WkF2cnRYcGZQanJaTHdtYWFkWTRRTXNZemdiMjhldzdFSEpDTGUyWEd1b2Nh?= =?utf-8?B?MC84QUNIT0JmZXpKVGlzK2MrV3U2NDIvSFIzSjRnMHp0eUxXeXlQMFAzc3Q5?= =?utf-8?B?d2l3aEJtYlVXbGw1bEM2ZmFwZ21ZQkNBcFN0TlZMZWNBbzVLQTdhaXVKeGxW?= =?utf-8?B?bGpRL3Ivc3B6Um8yTHd3RWduREVuZjVITFNrVk1Vd3RBRGhkSGN6dXZ6SHJH?= =?utf-8?B?Z0NWMXRteU9tb0c3K2tOQlRTK2dNQ243cFJndHBLOU56cE5oNmNxVE1ZSlhm?= =?utf-8?B?OHFCdDJ0VlFic0ZudlJtbkYwN1pIR01PekZFYWJFV1lsNEF4d1Rnb2VNRmJX?= =?utf-8?B?VTFiNUtaMllYUVNPTURpZWJnUVlqTkMzRi9VNlhOakYzSFRoRC9xMS9WcEVq?= =?utf-8?B?Y245bEc5WUxsM21qa21HL0pKYmJLdHptU3lnd1oybEZqNEkxUUNJdmhNK3JC?= =?utf-8?B?QzlINlUyWk5JQm5SczJyUTNuZlhycVRpa0k1OFNMbnlpY0ZWUStLV2lCUEhF?= =?utf-8?B?REs4MjAvTHVqY3pqYk9Hc0dXbGtYU1gxMk1NZzdWa2RWa24rb0VFWVdYK1I4?= =?utf-8?B?WFI3aTRlSFBrVS9LWkxMZ0FVQ0Zad1grQ2VlY0taak11S2V1ZmRiVkFVM24v?= =?utf-8?B?ZFh0dHVacVE2bTViZlFiYVRSc0U2OGhsSHhJWlljWkxvSE1IZ2lIWGI0UDRW?= =?utf-8?B?Vy82N1UzeEg4ditveVo3UEk2WnlkS0NJOVljL3lhZ25UanZLa2FtemhURk16?= =?utf-8?B?eDhGaW1SeGFqcXE5U0E1WWJISmJReFhCYTh5NXVCOEwzMDNtWWo0Rm42V0Rl?= =?utf-8?B?aHF4d3gwZmgyMU5DRlgrVWdYUGg1MS95YzdXdk51aW1vZVdUSGZVL1pmTnhJ?= =?utf-8?B?TVJaN0hicDgyVzBXYWZIOEUvZThuOUovWTkzRFVmeGdpL0FLRDNqVEVuV05O?= =?utf-8?B?TVZUT2JlR2cvUjcxdGNESDJvU2xETzRKcnBYT244R3RXdmR2bXBpZFRqeUhC?= =?utf-8?B?MmFDRHFuOFFnU1hxcCs4bDdvVDdkMjBhTE9kWEJqWVAvSmZYWFlraEdxTHN5?= =?utf-8?B?YitGOHpQQjRRUWVkR3ExRHE3QzNVSWt0dXhYcVlzV2hoQXZSWDFjUTBOS25j?= =?utf-8?B?NnlOSlViN0hSVnlVeE9RRWZBYTR0UVFtaWVwVFh2dWJzSW4xdGl6TS9rQ1BO?= =?utf-8?B?b0FFOTB1YndKelptQ3RVZk91UXd6dlhKdHZUVmloNjBvZXBUM0w0M21XeWNo?= =?utf-8?B?Q2FvOExOVDNMdjAyZC9DUG5ZOHNsbGd3NjlFS08yTmpPSlJEU1pVaWV6a3pJ?= =?utf-8?B?Q01PaFVySWFVM2lmSHVpYytOcWwrOXNvVXJEcU01WjQ3RDJ2S2RCVEV3WUJz?= =?utf-8?B?bUxsbUVSVjZiQmFhRmgyR2VtSXB3NVlISy81TzNCN0ZzcVNtWVpqZmo2S3JP?= =?utf-8?B?bGhJYllna0ZzdHVDWlU2SHZqTm13UjQ2V21JQTk5L2JMbkk0OUIrbTB2MTlH?= =?utf-8?B?ZEo5S05YQjFBYTBEVG1RT0NJUjFGWDZ6RVdzcmdOODdGbHNFOGRpb3dZQm1I?= =?utf-8?B?NXhxSXYzWEVFWTdjT0puS2Y3d0R2S1NSSWZJMTRLOWpCaEFmVlhsQUwxaGpw?= =?utf-8?B?YmdmbnVYdWlYNDg0a2J6TVQ0QXVvaE1laEVFaDROS0YydWNDT2NDM00rNElN?= =?utf-8?B?OU9FWStMZGlXRUlQelJkWmQ2Rm1WZG1kTjlaQ3psSkJIYmxUMVNkYWtRZGdZ?= =?utf-8?B?MlVpMXlNNjVYekxMTkJkU0ZEek9Cb1dUMHRJS3A2Nm10endxZWgwVzBmYVBJ?= =?utf-8?B?QjFld1hneU9yZkJIN1BuaTY0L1c3TU9INE1waDVQbHhTVFZTaUI2bkp0cUR2?= =?utf-8?B?Yjkxbkt1MHdqNTJ3enlTOVZQTUhCUktkanhBRGx5TnhYVWU0ajJmQ3IzNVdE?= =?utf-8?B?OVhWQXd0cHJVZzBtUXFnMjBJTmc0alZCQ0hORnNsT2hJS1J0aW1ZWlhxYit1?= =?utf-8?B?V1dtQUsvL1Q3WFZGOGdnc3JGeUNLVFhNaGRaVUdLb0VJTERMS0YvTlJNU1ZQ?= =?utf-8?B?YjhPWm8vc2txTHNaTWtEbWdkUVN5MUVlV2psemdndCszSU1vTytHTVk4ZXZZ?= =?utf-8?B?SUhJd2U4Qy9RQTlDSFlXN2ZJTXpIWVhSNVVqMzNCZklpSEdNTGdRQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 309931d2-30df-452b-5b8f-08df1a2dd7bb X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 11:20:30.6935 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y5aRsCNLLsGfrfa4YmvDmKhLN8uiXNtjxv0CyZkYxCItKW+AAS+wFXIO/ASpZbZWxTHCT6XAP7UrPQmDM1zvBxZ0f2UbIv2nCq4U1bzHQuI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB989329 X-purgate-ID: tlsNG-720697/1790248835-F14AE2AC-416D8F7D/0/0 X-purgate-type: clean X-purgate-size: 630 On 24/09/2026 12:03 pm, Ross Lagerwall wrote: > Instead of returning EINVAL on an unknown feature bit, clamp to the > known feature set. Sorry, but no. This is equivalent to saying "I've got a VM using AVX512" and Xen saying "ok, I'll ignore that safety check and let you run on non-AVX512 capable hardware". Requesting a feature that Xen doesn't know about is a hard error.  Truncating features out like this will cause a guest using those features to malfunction. It is a bug that this was expressed as an HVM Param in the first place.  It should be part of CPU Policy, and it's on a TODO list. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Sep 24 11:54:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 11:54:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432142.1653646 (Exim 4.92) (envelope-from ) id 1x9i2L-000205-3l; Thu, 24 Sep 2026 11:54:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432142.1653646; Thu, 24 Sep 2026 11:54:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i2L-0001zy-0y; Thu, 24 Sep 2026 11:54:49 +0000 Received: by outflank-mailman (input) for mailman id 1432142; Thu, 24 Sep 2026 11:54:47 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i2J-0001zs-GT for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:54:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9i2I-006Fbl-Ds for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:54:46 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab50f7f-2eae-0a2a0a5409dd-0a2a450baef2-16 for ; Thu, 24 Sep 2026 13:54:46 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab50f85-b7e8-0a2a450b0019-b9ff1c228301-3 for ; Thu, 24 Sep 2026 13:54:46 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d344933500072c4.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 24 Sep 2026 11:54:41 +0000 Received: from localhost.localdomain (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 076E581BC9; Thu, 24 Sep 2026 13:54:41 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=9nmytw3SyN0uJE1H9g0dfnojus9AJSvcW73229Lph84=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=oo/96swOqlQtzUZVDwPZjyz3jiVjjnlxPB7JYyLuTd11LnnOWCt9Q4UhQkCS/3DHCVHxYvC4K cSe7acdTvnlxGA9viskcnLYSIY6YmdSvCFPYxeMrnHmsnbu6x94k4nJyH5M7klEnWVEYbICIIcl 2hyuektzYA722Hhx4BCEAWOyA3NKXUnLtbrBEJyEwgkcKRnkA6qA9EeJiVEAX0x2KC1/W8dtq8v t/Mv8nG1mX7DKxsNaYBdWfSdn+UPfXcFtD7UO/ORyY8QKH9RSCjp3Pp1kcWqKSP3JA4CmcQ45Pl 5scKkUpzjeGxpIgDioPrQOy8r+48NdloUDg3QMLbjUVQ== X-Zone-Loop: 76d2d19d955bf664bd60fc2d2153dde482147a90a0a4 x-campaign-type: default x-transaction-id: 9bdde316-c837-4c1c-9c14-959dfee3c746 x-swg-uid: 01-f81ed60b-c853-4883-a67e-62e78375b746 X-Mailer: Sweego Message-ID: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> x-swg-bid: 1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Teddy Astie To: xen-devel@lists.xenproject.org Cc: Teddy Astie , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH 0/3] vm_event: Fixes around MSR intercepts Date: Thu, 24 Sep 2026 13:54:12 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3d4.e46ba96b59340f1b.1a0d34490a4.aa7cd6f9f9a4b691=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790250881188 X-purgate-ID: tlsNG-42698a/1790250886-A90CD9EA-17A2DA11/0/0 X-purgate-type: clean X-purgate-size: 1341 ---=Part.3d4.e46ba96b59340f1b.1a0d34490a4.aa7cd6f9f9a4b691=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fix Xen panics when trying to configure MSR intercepts in hypervisor range (as hardware has no dedicated bitmap, since it's unconditionally intercept= ed)=2E (SVM all builds, and VMX debug builds) Fix bogus monitored_msr() check in svm logic, which was checking for a truncated MSR instead of the correct one=2E Regarding intercepts in hypervisor range, I'm not sure if it would be pref= erable to move the check higher (i=2Ee in hvm_enable_msr_interception() to check = if the MSR is a hypervisor one, and if it is, to skip the architecture specific l= ogic, as it's not required at least on VMX/SVM)=2E Teddy Astie (3): vm_event: svm: Don't BUG() when enabling intercept on hypervisor MSR vm_event: svm: Fix incorrect monitored_msr() check vm_event: vmx: Allow intercepting hypervisor MSRs in debug builds xen/arch/x86/hvm/svm/svm=2Ec | 13 +++++++------ xen/arch/x86/hvm/vmx/vmcs=2Ec | 2 +- 2 files changed, 8 insertions(+), 7 deletions(-) --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.3d4.e46ba96b59340f1b.1a0d34490a4.aa7cd6f9f9a4b691=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 24 11:56:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 11:56:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432147.1653657 (Exim 4.92) (envelope-from ) id 1x9i42-0002WF-FB; Thu, 24 Sep 2026 11:56:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432147.1653657; Thu, 24 Sep 2026 11:56:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i42-0002W8-BM; Thu, 24 Sep 2026 11:56:34 +0000 Received: by outflank-mailman (input) for mailman id 1432147; Thu, 24 Sep 2026 11:56:33 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i41-0002W0-RZ for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:56:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9i40-00ESgq-Lf for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:56:32 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab50fe7-bab6-0a2a0a5309dd-0a2a4501a264-18 for ; Thu, 24 Sep 2026 13:56:32 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab50ff0-5984-0a2a45010019-b9ff1c128407-3 for ; Thu, 24 Sep 2026 13:56:32 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d3463da200072c4.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 24 Sep 2026 11:56:31 +0000 Received: from localhost.localdomain (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 33B0181C7E; Thu, 24 Sep 2026 13:56:30 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=eTWX2WdGLYZXeD1eAt/KWVZ7FoLWWCD3HQ4uh8l7BPI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=oSTt+Gv1Jd6mQo4POXduteqWgiYTVw6R3vIIf1aNCGPlrGn0prdCfi3zr/dPJrmgXqnDgZFH+ qJWvevvTVy9T7PYDA/tXRSRcu1Ap+5FZjFhU2xYwdKcn4zJvKufhMIFYbArbbiMJTRIWzvfnSK0 2k5ePji6vT8u3PubePAMlTJNd26RKLStkMFo9V0mozzbNor9Skj6UO863rG5PBtkBMWE2ZI72hv XaLvnIzGFp+g2XswtghY/DPabeq/uMco3dO+As7nXv0OkdoeOMjiyW+YW8vRQGa4mmj6nl4K+Fo gA5/mnrpiXEATVfEhI+urH/59pg2keQ2k+4g8BDCNZTQ== X-Zone-Loop: 84793b4c4493e596a76e7d3e1c882968d7b48f441399 x-campaign-type: default x-transaction-id: 7dfe51b2-bf94-4bf8-92b5-f687f16a9af1 x-swg-uid: 01-6621afb4-7c13-42f1-964d-3681abcbc246 X-Mailer: Sweego Message-ID: <1790250991.8631fc262581453bbf619ec5b2062170.1a0d3463da200072c4@vates.tech> x-swg-bid: 1790250991.8631fc262581453bbf619ec5b2062170.1a0d3463da200072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Teddy Astie To: xen-devel@lists.xenproject.org Cc: Teddy Astie , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH 1/3] vm_event: svm: Don't BUG() when enabling intercept on hypervisor MSR Date: Thu, 24 Sep 2026 13:56:02 +0200 In-Reply-To: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> References: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3d5.7b6538e51e68e334.1a0d3463b1b.4a3c00cbe7847fd8=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790250990364 X-purgate-ID: tlsNG-d62444/1790250992-BE27A757-864A250C/0/0 X-purgate-type: clean X-purgate-size: 1686 ---=Part.3d5.7b6538e51e68e334.1a0d3463b1b.4a3c00cbe7847fd8=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable svm_msrbits() only cover MSRs in the ranges specified in APM and returns NULL for all the other ones (i=2Ee hypervisor range), which triggers the BUG_ON() that follows=2E APM specifies that MSR outside the architectural and AMD specific ranges are unconditionally intercepted, hence don't require any specific handling by SVM logic, fix this by ignoring cases when msr_bit is NULL=2E This is only reachable with CONFIG_VM_EVENT using XEN_DOMCTL_MONITOR_EVENT= _MOV_TO_MSR to configure a MSR intercept in the hypervisor range (0x40000000=E2=80=930= x40001fff)=2E Fixes: 6e9fc4d628b6 ("hvm/svm: Enable MSR events") Signed-off-by: Teddy Astie --- xen/arch/x86/hvm/svm/svm=2Ec | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/svm=2Ec b/xen/arch/x86/hvm/svm/svm=2Ec index b5fc459e62=2E=2E7a16289f85 100644 --- a/xen/arch/x86/hvm/svm/svm=2Ec +++ b/xen/arch/x86/hvm/svm/svm=2Ec @@ -237,7 +237,9 @@ void svm_intercept_msr(struct vcpu *v, uint32_t msr, i= nt flags) const struct domain *d =3D v->domain; =20 msr_bit =3D svm_msrbit(v->arch=2Ehvm=2Esvm=2Emsrpm, msr); - BUG_ON(msr_bit =3D=3D NULL); + if ( msr_bit =3D=3D NULL ) + return; + msr &=3D 0x1fff; =20 if ( flags & MSR_INTERCEPT_READ ) --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.3d5.7b6538e51e68e334.1a0d3463b1b.4a3c00cbe7847fd8=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 24 11:57:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 11:57:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432153.1653664 (Exim 4.92) (envelope-from ) id 1x9i4c-00030U-Od; Thu, 24 Sep 2026 11:57:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432153.1653664; Thu, 24 Sep 2026 11:57:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i4c-00030N-LW; Thu, 24 Sep 2026 11:57:10 +0000 Received: by outflank-mailman (input) for mailman id 1432153; Thu, 24 Sep 2026 11:57:09 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i4b-00030A-I3 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:57:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9i4a-00GHwW-Uv for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:57:08 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab51009-bab6-0a2a0a5309dd-0a2a45099cb8-38 for ; Thu, 24 Sep 2026 13:57:08 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab51014-be1a-0a2a45090019-b9ff1c239d61-3 for ; Thu, 24 Sep 2026 13:57:08 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d346bb7600072c4.003 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 24 Sep 2026 11:57:03 +0000 Received: from localhost.localdomain (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id A0AD081BC9; Thu, 24 Sep 2026 13:57:02 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=vfl7bGD+ze0wdzwbimwGjn278qJxmVdn7i/sXvYd5YU=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=D9JGfLSbCVAuwEO1Oj3DK8JcoYiGThpPRrn5J+3bbraEw8XI3ijj+YVANc8GJ/Ts+UcKrZPQb 1k7nNs75+GB6ptYLBWb9qjPdJRi71yj1GIfHJbqUGvAR1igZthNKtFaAd5jyxqM4fXICn5Pef4b acHsKuuFfmbGJjs7mg/RZW0M92iXvL/CdKeDC/S3Jjs4UAvqSU0SXiFfV4WWkqzOilwdeqnmzaK BQHIEM9EH6jveL15OgcBoV1LmzwKG0XX7KSszD0XxGubNSDGKNBk8lJnlKQPcVpwBwI1lC0BYrL Snu3aib8l/X1EgEc8gXuwr2yPBmLOfeBAISIQ3OOI55Q== X-Zone-Loop: 13123eb627616702cda6ae9aeb66064768f2e2126120 x-campaign-type: default x-transaction-id: eb13b39e-63ea-4c42-9183-302a6576ce27 x-swg-uid: 01-158bd62e-43bf-41b1-84c9-e1ad41e7e18b X-Mailer: Sweego Message-ID: <1790251023.8631fc262581453bbf619ec5b2062170.1a0d346bb7600072c4@vates.tech> x-swg-bid: 1790251023.8631fc262581453bbf619ec5b2062170.1a0d346bb7600072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Teddy Astie To: xen-devel@lists.xenproject.org Cc: Teddy Astie , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH 2/3] vm_event: svm: Fix incorrect monitored_msr() check Date: Thu, 24 Sep 2026 13:56:35 +0200 In-Reply-To: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> References: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3d6.9b770b8b9dcd803a.1a0d346b9d6.9cd4415412d644c6=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790251022806 X-purgate-ID: tlsNG-bad1c0/1790251028-BF6D2034-0AA31886/0/0 X-purgate-type: clean X-purgate-size: 2120 ---=Part.3d6.9b770b8b9dcd803a.1a0d346b9d6.9cd4415412d644c6=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable monitored_msr() is called with truncated MSR values (&=3D 0x1fff) which doesn't match the original one, making the check incorrect=2E Fix that by keeping the msr value intact and computing the bitmap offset separately (in msr_offset)=2E Fixes: 2746088d9cb4 ("svm: don't clear interception for MSRs required for = introspection") Signed-off-by: Teddy Astie --- Should we multiply by 2 msr_offset instead of doing that in {set,clear}_bi= t() ? xen/arch/x86/hvm/svm/svm=2Ec | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm=2Ec b/xen/arch/x86/hvm/svm/svm=2Ec index 7a16289f85=2E=2Ed986f3aa8f 100644 --- a/xen/arch/x86/hvm/svm/svm=2Ec +++ b/xen/arch/x86/hvm/svm/svm=2Ec @@ -234,23 +234,22 @@ svm_msrbit(unsigned long *msr_bitmap, uint32_t msr) void svm_intercept_msr(struct vcpu *v, uint32_t msr, int flags) { unsigned long *msr_bit; + unsigned int msr_offset =3D msr & 0x1fff; const struct domain *d =3D v->domain; =20 msr_bit =3D svm_msrbit(v->arch=2Ehvm=2Esvm=2Emsrpm, msr); if ( msr_bit =3D=3D NULL ) return; =20 - msr &=3D 0x1fff; - if ( flags & MSR_INTERCEPT_READ ) - __set_bit(msr * 2, msr_bit); + __set_bit(msr_offset * 2, msr_bit); else if ( !monitored_msr(d, msr) ) - __clear_bit(msr * 2, msr_bit); + __clear_bit(msr_offset * 2, msr_bit); =20 if ( flags & MSR_INTERCEPT_WRITE ) - __set_bit(msr * 2 + 1, msr_bit); + __set_bit(msr_offset * 2 + 1, msr_bit); else if ( !monitored_msr(d, msr) ) - __clear_bit(msr * 2 + 1, msr_bit); + __clear_bit(msr_offset * 2 + 1, msr_bit); } =20 #ifdef CONFIG_VM_EVENT --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.3d6.9b770b8b9dcd803a.1a0d346b9d6.9cd4415412d644c6=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 24 11:57:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 11:57:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432158.1653673 (Exim 4.92) (envelope-from ) id 1x9i52-0003gB-W8; Thu, 24 Sep 2026 11:57:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432158.1653673; Thu, 24 Sep 2026 11:57:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i52-0003g4-TT; Thu, 24 Sep 2026 11:57:36 +0000 Received: by outflank-mailman (input) for mailman id 1432158; Thu, 24 Sep 2026 11:57:35 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i51-0003Zl-AA for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 11:57:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9i50-009XC0-NK for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:57:34 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5102d-2eae-0a2a0a5409dd-0a2a4504e240-4 for ; Thu, 24 Sep 2026 13:57:34 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5102e-b57f-0a2a45040019-b9ff1c238647-3 for ; Thu, 24 Sep 2026 13:57:34 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d347225a00072c4.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 24 Sep 2026 11:57:29 +0000 Received: from localhost.localdomain (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id CD01C81C7E; Thu, 24 Sep 2026 13:57:28 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=YSK+oBEhJCxxZzsM9y3NERCslvzp5sV47ASUQ0IT6sQ=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=opwvSSeaIJAYQFGwOrE+4Z9hfuOxsUVQHroj+0c3lInNotR48+FoVZIQFZGqTJOkp38IfXV95 QOGnA7JoasjQlz2yDv9RzH612+AU7vYeDdnc9W3pEQdJjf8zyq9Lv+DzgukDP74ipB4MN7zw7mt q42pyDg+NpCmtbeH2Q08OTejFqo2kGFw/khaqapw6CzD7MW1Fpn+3ZoGs3Q3+jW82YGvYKxyAoF vpHJ1opFe/2BKNwRp8RprOY325qOb8ijsRfz6UtTkRezxNBkPmXzY11uhNtkzsdEsRNnAzBi2vQ RrRkF5Ar5osO6jDMlZ0OgB4Ds778YatiEGkKuPzSzjsw== X-Zone-Loop: 20541bc9a38802228b6bffc229bb790710352b308f84 x-campaign-type: default x-transaction-id: 6c62f9b7-f9f4-40a4-b512-ea2630e8d76d x-swg-uid: 01-16fd0064-d4a8-427c-b52a-feec3ef13f2b X-Mailer: Sweego Message-ID: <1790251049.8631fc262581453bbf619ec5b2062170.1a0d347225a00072c4@vates.tech> x-swg-bid: 1790251049.8631fc262581453bbf619ec5b2062170.1a0d347225a00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Teddy Astie To: xen-devel@lists.xenproject.org Cc: Teddy Astie , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 3/3] vm_event: vmx: Allow intercepting hypervisor MSRs in debug builds Date: Thu, 24 Sep 2026 13:57:07 +0200 In-Reply-To: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> References: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3d7.f43ed18a8ff1f602.1a0d3472009.a677eb19d0ec6198=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790251048970 X-purgate-ID: tlsNG-ebf023/1790251054-C28C9B50-A43345E1/0/0 X-purgate-type: clean X-purgate-size: 1594 ---=Part.3d7.f43ed18a8ff1f602.1a0d3472009.a677eb19d0ec6198=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MSRs that are not covered by MSR bitmap (e=2Eg hypervisor range) are unconditionally intercepted by hardware and don't need any specific handli= ng=2E However, vmx_set_msr_intercept() wrongly ASSERT() if the MSR is a part of = the hypervisor range=2E Fix it by skipping the ASSERT() in this case=2E This is only reachable with CONFIG_VM_EVENT using XEN_DOMCTL_MONITOR_EVENT= _MOV_TO_MSR to configure a MSR intercept in the hypervisor range (0x40000000=E2=80=930= x40001fff)=2E Fixes: 62999081ca27 ("x86/vmx: Introduce and use struct vmx_msr_bitmap") Signed-off-by: Teddy Astie --- xen/arch/x86/hvm/vmx/vmcs=2Ec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs=2Ec b/xen/arch/x86/hvm/vmx/vmcs=2Ec index 8e52ef4d49=2E=2E050168bbce 100644 --- a/xen/arch/x86/hvm/vmx/vmcs=2Ec +++ b/xen/arch/x86/hvm/vmx/vmcs=2Ec @@ -986,7 +986,7 @@ void vmx_set_msr_intercept(struct vcpu *v, unsigned in= t msr, if ( type & VMX_MSR_W ) set_bit(msr, msr_bitmap->write_high); } - else + else if ( !((msr >=3D 0x40000000U) && (msr <=3D 0x40001fffU)) ) ASSERT(!"MSR out of range for interception\n"); } =20 --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.3d7.f43ed18a8ff1f602.1a0d3472009.a677eb19d0ec6198=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 24 12:01:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 12:01:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432169.1653683 (Exim 4.92) (envelope-from ) id 1x9i8N-0005K8-GJ; Thu, 24 Sep 2026 12:01:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432169.1653683; Thu, 24 Sep 2026 12:01:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i8N-0005K1-Dd; Thu, 24 Sep 2026 12:01:03 +0000 Received: by outflank-mailman (input) for mailman id 1432169; Thu, 24 Sep 2026 12:01:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9i8M-0005Jv-2S for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 12:01:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9i8L-00EUBi-Bn for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 14:01:01 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab510f5-bab6-0a2a0a5309dd-0a2a450be2e0-44 for ; Thu, 24 Sep 2026 14:01:01 +0200 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab510fc-b7e8-0a2a450b0019-b9ff1c2295e3-3 for ; Thu, 24 Sep 2026 14:01:00 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d34a4a2d00072c4.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 24 Sep 2026 12:00:56 +0000 Received: from localhost.localdomain (88-188-240-210.subs.proxad.net [88.188.240.210]) (Authenticated sender: teddy.astie@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 7AB718115F; Thu, 24 Sep 2026 14:00:55 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=DL1Sjx54yS3tmAgAz4HCxGgr8ta9fM3OGuAi6B3UhaY=; h=from:subject:date:message-id:to:cc:mime-version:content-type:feedback-id; b=qJh/l/BVFLrgg3Tv+cv1hoLv6EKz6edTQMa4DNRu/u7Wa1YqZVi41eurNw2sqFFp8EVBldgVd Z/YLOtQfOvoekCpPJel/oo56MagUCB+wseJI+G3J9aTJy2fFyWl3dNeV1KXyd4E8nd6PT6OUhTo nH/kc0dchQr9j+4XGs2CKcflVqETDxpkTwpKxUvtfRUBRyrT4wy68al64OFElg/Up8iLMO+3pkb 1Lo0ONtWSEQ1i5YR7HmmMZY860DIsmup9Aeb4SWH7ovHGLYDD11fFClSAVbOezxNDQGL3b+ulLT VsiXAW3OWoRPo0+Vs0NpAs1dXgqMHcrMkeAZqVwOVWbQ== X-Zone-Loop: 952d021e65471d952c33df172676b51a1bb9850fb628 x-campaign-type: default x-transaction-id: cd77b029-4c9b-4f61-880b-49d68627346f x-swg-uid: 01-0544961e-4e18-4843-8ed0-1b3044505f4e X-Mailer: Sweego Message-ID: <1790251256.8631fc262581453bbf619ec5b2062170.1a0d34a4a2d00072c4@vates.tech> x-swg-bid: 1790251256.8631fc262581453bbf619ec5b2062170.1a0d34a4a2d00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Teddy Astie To: xen-devel@lists.xenproject.org Cc: Teddy Astie , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86emul: Fix AAM emulation AH output Date: Thu, 24 Sep 2026 13:59:49 +0200 MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.3d8.66a918d7fbd1f921.1a0d34a4764.a014632262073314=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790251255653 X-purgate-ID: tlsNG-42698a/1790251260-196C29EA-C3195670/0/0 X-purgate-type: clean X-purgate-size: 1595 ---=Part.3d8.66a918d7fbd1f921.1a0d34a4764.a014632262073314=- Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable AAM is defined in APM as AH =3D (AL/10d) AL =3D (AL mod 10d) However, due to the order of operations, we're incorrectly computing it as AL =3D (AL mod 10d) AH =3D (AL/10d) =3D ((originalAL mod 10d)/10d) =3D 0 Fix it by reordering the operations to match what's defined in APM and avoid the unexpected dependency between the 2 operations=2E Fixes: 8993572b9c16 ("x86emul: fold/eliminate some local variables") Signed-off-by: Teddy Astie --- xen/arch/x86/x86_emulate/x86_emulate=2Ec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/x86_emulate/x86_emulate=2Ec b/xen/arch/x86/x86_e= mulate/x86_emulate=2Ec index 89c37fea2c=2E=2Ef168f3ebcf 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate=2Ec +++ b/xen/arch/x86/x86_emulate/x86_emulate=2Ec @@ -2511,8 +2511,8 @@ x86_emulate( else { generate_exception_if(!n, X86_EXC_DE); - _regs=2Eal =3D _regs=2Eal % n; _regs=2Eah =3D _regs=2Eal / n; + _regs=2Eal =3D _regs=2Eal % n; } _regs=2Eeflags &=3D ~(X86_EFLAGS_SF | X86_EFLAGS_ZF | X86_EFLAGS_= PF); _regs=2Eeflags |=3D !_regs=2Eal ? X86_EFLAGS_ZF : 0; --=20 2=2E55=2E0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates s= olutions web: https://vates=2Etech ---=Part.3d8.66a918d7fbd1f921.1a0d34a4764.a014632262073314=--- From xen-devel-bounces@lists.xenproject.org Thu Sep 24 12:24:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 12:24:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432187.1653691 (Exim 4.92) (envelope-from ) id 1x9iUm-0000uA-86; Thu, 24 Sep 2026 12:24:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432187.1653691; Thu, 24 Sep 2026 12:24:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9iUm-0000u3-5V; Thu, 24 Sep 2026 12:24:12 +0000 Received: by outflank-mailman (input) for mailman id 1432187; Thu, 24 Sep 2026 12:24:11 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9iUl-0000tx-1T for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 12:24:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9iUk-00CQqP-ED for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 14:24:10 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab51666-8faa-0a2a0a5109dd-0a2a4502ed92-14 for ; Thu, 24 Sep 2026 14:24:10 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5166a-6ca4-0a2a45020019-4a7de18ca80a-3 for ; Thu, 24 Sep 2026 14:24:10 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b912d8239so14945175e9.0 for ; Thu, 24 Sep 2026 05:24:10 -0700 (PDT) Received: from andrew-B650M-DS3H.. ([102.213.49.86]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-488684864c8sm14470407f8f.13.2026.09.24.05.24.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 05:24:09 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790252650; x=1790857450; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=AdoDR5Hj3NTMNdxF4g8rScZTo2XPuPXeKc9btLdTOZc=; b=DeAriSlRexWrCgp7GJC6YyeokPeqNrfZVZXat22sYkfqWIPwUnYG8XIEExdFcn+NHr oUhdmXMe857IC4tZGJzXdYOJCemcbpWFFJeFQRevfsy34u/5XJe0JyoM95Ffhniljt+j htLMe0ik+kMIRXQBvky6IAO6ZQzy7973zxgL8snCX4tlB86z9na/DLKi2LPNVw3R3BIK uKPBbKEvCByWcjo8Dhrv5TZ/mwoE8JI7JF1XMqU2cixCWA1ZzEoJ/LUdPGnhNurT3AzX dcgY3f+2ZiHx+yEVnRgLrS429nTEYzL36tmU24vXyDzYdxHyNPU0PQHeOBPfwTKhW6fJ 7mgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790252650; x=1790857450; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=AdoDR5Hj3NTMNdxF4g8rScZTo2XPuPXeKc9btLdTOZc=; b=rGnhati4pXhXyRgadRW1fr1AbXg6h9y19Qp1dyaUgtsobyqBA3laUTyEHArjt+lAud sA6voZdZgfQfbBObpo0/ICoKXJPx1GTKYkPTmcoAOixKGf/A+RRAwSZ+W9WmlKvZ9Fo7 Y1VFcOm35XgXNM0lE300GgUO7jdfaa7nKavQREEWcYMgjRy0rab5xpNKlhd7m/G7Rg3D PeEzaJjuYrnl0Yz44VAT9djKlMqV+oVJZ9GeupU6QeDEB4W/AK8jIhifkUGCCBWITnQd YKuSa6fboWnvOzQbyHRYXDe8QBRHUt1ou1/WZxKbOh/wOzHn+U83QSCgapLiNtbSrbrK DMsw== X-Gm-Message-State: AFuF++npw6PN7hsxVYRNtooBMnzK84sPIiccfBq3OGtZmx8vwszynVJj Ij/V5IcD3/tG1qpa2asMsy8/+1TER8wdCY1xk4X2ZEuxqkcE6SWB2vhuQmOP5Yai32A= X-Gm-Gg: AYBFou30kfTSPGmF+y0V0v/Ov6NXeWlIimcF8y/7G3EB8uNZHQV2pNivKZml5Z03vzv +v3R6GWGGYOCQg9VLXSZAl12B6TvOZdcsoZJDgbLwxgbAwuWpVR6o77toEkRf0lzEfGRDwZ6UOA f4fW/CrnwG8T59nbCQ924eoBFvkr64dtN39vr4brpzs6PovFdaAImxJzHVMLwHam99ISWzUHyzi 59Y+ThPmL4Is6P6kNdcJ7yua+7SSMLp59QcBbiw2Jmv28EgXojgFuyDlBgXcfijNZ/+E/WsoJE4 Q4PrY8AE2i5jkvrFrsHvCoM9mdbWKHiRAo67GlWIhsqJlfs9/dCtlDHNAHX55tKgi/gYHe3Fwc7 PvfYd/sHuUFd/iXkJWE+KSuEAdS+2zz/qVBomjU6l1qnTBWLCybExni2Wj3eyrAGELvUCI5eMA1 +FLrl3e2TAFGE9Levkd7y98wsmXlq1rii/3uv5i1hEloab76Hx3hNdpxaiG22XMTKaP6sj8NzRc 16/xNzHnEWG1DtbsQ== X-Received: by 2002:a05:600c:6287:b0:49d:827:e5b6 with SMTP id 5b1f17b1804b1-49fe7babaadmr31595605e9.20.1790252649792; Thu, 24 Sep 2026 05:24:09 -0700 (PDT) From: Andrew Mbugua To: xen-devel@lists.xenproject.org Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, jbeulich@suse.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, Andrew Mbugua Subject: [PATCH] xen/common: fix MISRA R7.2 violations in crc32/unlzma/bunzip2 Date: Thu, 24 Sep 2026 15:24:03 +0300 Message-ID: <20260924122403.214738-1-andrewprecious388@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-720697/1790252650-31FD62AC-2CC344FA/0/0 X-purgate-type: clean X-purgate-size: 1582 Adding the U suffix. No functional change. MISRA C Rule 7.2 demands a "u" or "U" suffix on all integer constants with unsigned type. On 32-bit int targets constants >= 0x80000000 (e.g. 0xEDB88320, 0xFFFFFFFF, 0x80000000, 0x04C11DB7) must be written explicitly unsigned. Signed-off-by: Andrew Mbugua --- diff --git a/xen/common/bunzip2.c b/xen/common/bunzip2.c index 79f17162b1..6345a064cd 100644 --- a/xen/common/bunzip2.c +++ b/xen/common/bunzip2.c @@ -650,7 +650,7 @@ static int __init start_bunzip(struct bunzip_data **bdp, void *inbuf, int len, for (i = 0; i < 256; i++) { c = i << 24; for (j = 8; j; j--) - c = c&0x80000000 ? (c << 1)^0x04c11db7 : (c << 1); + c = c&0x80000000U ? (c << 1)^0x04c11db7U : (c << 1); bd->crc32Table[i] = c; } diff --git a/xen/common/unlzma.c b/xen/common/unlzma.c index 56359420aa..bd42984f15 100644 --- a/xen/common/unlzma.c +++ b/xen/common/unlzma.c @@ -106,7 +106,7 @@ static inline void __init rc_init(struct rc *rc, rc->ptr = rc->buffer; rc->code = 0; - rc->range = 0xFFFFFFFF; + rc->range = 0xFFFFFFFFU; } static inline void __init rc_init_code(struct rc *rc) diff --git a/xen/common/xz/crc32.c b/xen/common/xz/crc32.c index 092a74fbab..0368d8793f 100644 --- a/xen/common/xz/crc32.c +++ b/xen/common/xz/crc32.c @@ -19,7 +19,7 @@ XZ_EXTERN uint32_t __initdata xz_crc32_table[256]; XZ_EXTERN void __init xz_crc32_init(void) { - const uint32_t poly = 0xEDB88320; + const uint32_t poly = 0xEDB88320U; uint32_t i; uint32_t j; From xen-devel-bounces@lists.xenproject.org Thu Sep 24 12:56:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 12:56:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432253.1653702 (Exim 4.92) (envelope-from ) id 1x9izk-0005uO-KN; Thu, 24 Sep 2026 12:56:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432253.1653702; Thu, 24 Sep 2026 12:56:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9izk-0005uH-Gb; Thu, 24 Sep 2026 12:56:12 +0000 Received: by outflank-mailman (input) for mailman id 1432253; Thu, 24 Sep 2026 12:56:11 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9izj-0005uB-H1 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 12:56:11 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9izi-00HBr7-Ad for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 14:56:10 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab51de0-2eae-0a2a0a5409dd-0a2a450c9686-24 for ; Thu, 24 Sep 2026 14:56:10 +0200 Received: from [40.93.198.52] (helo=CY7PR03CU001.outbound.protection.outlook.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab51de8-f479-0a2a450c0019-285dc6348419-3 for ; Thu, 24 Sep 2026 14:56:10 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by DM4PR03MB7013.namprd03.prod.outlook.com (2603:10b6:8:40::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 12:56:05 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Thu, 24 Sep 2026 12:56:05 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QzFHmTSXrhlLb2x5jaoCLOKDqG09UfBu39Dm6JpMXa0PxIzsTOKa2n79rzLUECPTwFBDecwNZTwzbF5eSkKigiN2rJKbBcL0/tNxiOVFrvxhqK7IkRCcsgQNMl14vVRbfNmqstgLWe/VTVjtapnlTpuTbWNaXgoUy4n+1ZUsvlfwxhmKZC2RZAK86BdWsgLFynovN2Ap3VjCeumDJzaTMEZfoE4N3I6zR5olu3GLSQAMrPnQmO+kc3HNg4mKSotJT9UHe3iWXI/AA/9yLVZhh924SBqHAdxCxKtwzWXHIswfsSV1wny2wPk2+lzCRwdlhz7lsvckZWCqkxTeEuuumQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3qnXD8olE1RhVt4hyXvZJ14EiAuMC0A2U0g57NmoSrE=; b=Z946lt3g1PJyUmRgfDFGMERwHGBWGHchLpqo3L7Uwxpd0n3yGiQGvPNUw4zFVF1ZToOXvFiWd8fgm71cOd96wcYCIklTi+gHr6SmBZPto8q9Oho0RmKYlDqMLIhhnUOTTDgF6i7BXJT1Vyrp9jmXq7SPSnxRsDEI0Co8Vh55DcybJ+NWwye8S5+2jVobxH40M9AmkgIj6pdsARnNRNNmfTo4yfQd69+mhGp4pWaEn2CKCAXZsBp+Rf5Y8XcYhn68qeYYuiKh5evJf8ECTtiWtYS1EmKVMddC/eNDyXmdlDJXwNSxGLrwaHAQ4K5A7riu0hWhz/LlsRs8gBUul6KGJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3qnXD8olE1RhVt4hyXvZJ14EiAuMC0A2U0g57NmoSrE=; b=NpiS+ZYtotrzCC2OoxAi/iAsPTQsL5H+pCGhgiuv4T3a8JAYtpwur52XVeEwoFwp7hU2n4PF06NibZSiECgTk9FTwkUkLSwALR2oh5xua3QiXugqmy/YdvnvQFbBnECqVsF7tIy9U69eTHBRjhl6PS7zPWGwYg+OFriQ0EqiJqE= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 24 Sep 2026 13:56:02 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/hvm: Clamp Viridian features to known set To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <20260924110342.1045230-1-ross.lagerwall@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0298.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:196::15) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|DM4PR03MB7013:EE_ X-MS-Office365-Filtering-Correlation-Id: 38f5a246-6673-4f47-a325-08df1a3b3205 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|6133799003|10067099003|22082099003|18002099003|11063799006|56012099006|5023799004|4143699003; X-Microsoft-Antispam-Message-Info: oXbKAWQljDv381DZwuCOjVck6Xob7lmIljB7+jclrS8pFWRmI1scxQdrzrCsH8B509q9YmygPzgg/jNmu2gealkQz0njpYYy5+xNLF3TXLz3+YW85aU4898X8xxsFo1vucbVppRENlvNxrpmNtprIC3wpQ+Ibc41WmCrbmbCaFSPlGbvASaXFHcNPtXOEePjrfJDiaPLIIjI6jyiDtDxlDnch8Cl9JXD3Tc+GyKYN2yD1nFG8V655c+wGmLxH/HyAyANswB6/nlA7s1vam91jQAGzSPynJ0tjr6pWw1NS9KumQ9wiVZQ9jWgaChJdLvFPa2j1WETeqU9RVB2pTJivw/GovIeUhZVNAH9JnEUm5OtU177LKGA7R6SULQt+RZ2s+0V+oW21wyBuiztYjMcWv4c/OLVc+oplMSaaT7BHQzlLatiS4lpMEIdE5hDHvbizKtxnwmwLTVcLu4bqMX6pJqT4EBarsl9sQETqPxJKSRJa7Wgh+ZYNS6VUWP+2YfOzBddoR+IU5FwbnainpgthtTKl//zepNRTqVKwkaxqch9AYEMbn7GhCuLxLIAupU7ObkBf36vXGjoS8GeryqUK5DfZC096+8Ma45T5eEXQdfNbcmLNos14oseJgm8mqINF9u/t6gBGcjBnSKJSYdAJLeCPKTUFBt/dmqKUik8/s8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(6133799003)(10067099003)(22082099003)(18002099003)(11063799006)(56012099006)(5023799004)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bVdIY1plaFhlUXBoSzErY3g4MDFqOGRoMU9LMlozS0VkOEVGQitQQ2FHU0hD?= =?utf-8?B?Z2F4UkxneFpNbTV2VjhTRk45L3hBNnBuSkxkNThqUGtjcEZvdEEwSDZRT1li?= =?utf-8?B?V3llVlRqOFBLdkdOclRCdzRZSnZKa2w0dVdYVXBUazJkS0NiT2NIbjJUMUVM?= =?utf-8?B?SjEwK3hoR1RlelBZZElnVzFWSkR3dXhGSEdldE96YTF0S3pPSDNES2RGck4z?= =?utf-8?B?M0dBY3RLSlZQbno3aFNQSFBTS0ZzeXNpME9iQmdXbzlPK2dpUERDV2tONmxB?= =?utf-8?B?WExSUnh5azNJNFc1WHpTWjlSTmFyZkUwV2g1dXI5Zk9nOURuZWNFcCtWd084?= =?utf-8?B?czN0RGFLOWdQemVqbVVFYVd3ek83cmVoYXV2UjYzeDhCYlJ2RlJFS2w2bU9Q?= =?utf-8?B?cS9HM3kyTHZNeW55OEN1UHVpSXVsamVIaWNEM25IUjVnRUpLVm84bWZ5VGY2?= =?utf-8?B?MW1BM2pDNGZKbURzMUFMM3BxM21OL2NkWnNkaW9tR1RaUEJQUlBBR01SUlVH?= =?utf-8?B?ekhlalZxV2FaOUQyZ1AyV09oMGV1NWoyOWhXU1FuMmYybFE1Q2xYc0hocUZO?= =?utf-8?B?bmdJZlo4TjFEek5WdVdybmptTzZNMXEreW9ndWhXeDJCVUYrVDdhdHJqY21k?= =?utf-8?B?ZGhlMUU4QU9QZVJwbWt4OHNTY1pWTjB3L09VMmxpV3lJZm5CdHdRVG9YWXY4?= =?utf-8?B?cFBqQVhYNTRibnFtc2c5M2VhRVBRamN5VzdlamRINTZxakZUS0EwNGxER2pa?= =?utf-8?B?aFVrYklTbXhTMU5ydDRyOTRCN080Zlh1d2lCQzkrbUNpenVSZWEwVnRici9a?= =?utf-8?B?NkorVXJsbk51TjJ6TzZ4UTY1Wm1YR1B1dHZ5TThxcXl6dHZFSlg0Ykl3c0Ux?= =?utf-8?B?REdDSnhrZDMxb1c0VFNjR0J4RUhTT1A1d2djL0NFQnQ2WkFqZEcyZVdodlVX?= =?utf-8?B?NkxNRUpiODEvNUlkaHRXZWZ3NkNYN0JvT0tUekt3RnVQV2dISXpYY0NmZDdZ?= =?utf-8?B?WFhLSjY4b3JxYUluMHJSWHVSaWxHQVBCTGZiM3ZqVnZ4T0hTQWhLTFRmQ201?= =?utf-8?B?VzVPQ2pWN0RSYXBtTUcrS1ZscUw3Z25WSXFoeU95cm4wa2FpeDhraDJlaWJO?= =?utf-8?B?NzErZ1F2V1ZnUExOREhQN0lOOHVDQkZUcDZyZzFRWXdpYzdGWmRWZlpDODBo?= =?utf-8?B?Q1N5TkJVVWFFOUowOEZnTm91dDZiZWF6N1BrQ3l6dnFicDIvWVhSa2FkbjJI?= =?utf-8?B?TURXRVpsVS9jMk1ENmlZczFXU0N2czJEZGNsRWIvQ1dCUVFXZHkySWJ1aEpL?= =?utf-8?B?OTJpdEdCeXZtWUNYYi9yUjhFSDJRS1Z4MStWbkFMSTVSOEp1cjNrUW1HN3di?= =?utf-8?B?ZnlpcytwZko5RXg0eTZYOW9QMUcrYTFqN0s5U0NxTm82d21FMTk1M2M1V3Nt?= =?utf-8?B?bW12NkdLcTM3SmRaa1haOW5zUnVmbjNqMyt3dzdPT2lrKzZGSFY4Vm9rcDl4?= =?utf-8?B?dVNRdldFbGVScGo3R0N2Y2hiNkZQZndzdkNzMEptMVdxcWdYbEVDYXAyTURh?= =?utf-8?B?MHZzWWhEeVRMZ0JvdFBwNXQ1NXl0SDVJLytNWnQzcEJCeC9IdTlaZTh0REs0?= =?utf-8?B?ZDFwSXdvSkErNUtYZ0llUUFaRTV2eHlXVkVNUWNXbFpGdWRsbGswNm1mVVVv?= =?utf-8?B?WmFGeWZsdmkvRlJiQmZOaFFuNUw1cUI1eXVVK1hQeFR0cnJQeW01cWwySlBR?= =?utf-8?B?a2VWTjUzMmtERmJERE1HR29yKzdKeWFqMk1ZRXlueWVhVDVTckNwN2VDYzAw?= =?utf-8?B?S2xOdGZsSUU0dDYrTWpRVDY2eVpZSUZYMjNzYWkyM1Nnb3dNSDk1bGJPdW5L?= =?utf-8?B?WThmb2x2b3RieWs5WGs5NXV3WFUvQnM2RmdGZ0xqTDNrR0VWK0w2K2pPdGFB?= =?utf-8?B?RWc4TVpsdnpjd2JoVGEwdkdIVlJOV2djSi9VV3lVSS9mQThqWGNmYnl3eHNG?= =?utf-8?B?emdMNUREcVU2T0x3Z1pMT2xaeWxwdzZiMzl6cGRVMTNVNkpLV3RFR2dHYjg1?= =?utf-8?B?MmpPTGdvK0ZZbkhrdXNHc1RJL0RMOEZxd1h4VTdWN2cvVmVlc2JkdFhReEpB?= =?utf-8?B?MjJoaWtmcnMveURaNEJOVWxWb3p6Tkp1V1F3RndTaHlTWkoraWdxZDgxYXZ4?= =?utf-8?B?MytuR3Qza01DV1gxc2h0ZkVVd1BmNFJoblJHWVhHRWNaTnZCV1hVQ0ZUbW9F?= =?utf-8?B?cCtWWFIxZ1I0dDlGMFU5MFc5MnpYOU8wMkxvZWEwQWd0dlFCN001VG9tWXc2?= =?utf-8?B?SGlWMlFEbUUvTTFtdVZrUnFRYlExbVA2UzVUZmg2ZVFvYk84TWplelovQmhj?= =?utf-8?Q?Vy3vaZla28bCfUx0=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 38f5a246-6673-4f47-a325-08df1a3b3205 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 12:56:05.6198 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5pZ9JMitDclYhSK2RxQGMCALh32dqAkOqwPlmV0YVlJxq5Zqi7k3sU/W2Ive6WTCGRpJCWEoWHlsUJp9H3zZyb2QLA7ujKqX+OVpMx5fI/E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB7013 X-purgate-ID: tlsNG-d25034/1790254570-50520A5B-8B560B05/0/0 X-purgate-type: clean X-purgate-size: 854 On 9/24/26 12:20 PM, Andrew Cooper wrote: > On 24/09/2026 12:03 pm, Ross Lagerwall wrote: >> Instead of returning EINVAL on an unknown feature bit, clamp to the >> known feature set. > > Sorry, but no. > > This is equivalent to saying "I've got a VM using AVX512" and Xen saying > "ok, I'll ignore that safety check and let you run on non-AVX512 capable > hardware". > > Requesting a feature that Xen doesn't know about is a hard error. > Truncating features out like this will cause a guest using those > features to malfunction. > > It is a bug that this was expressed as an HVM Param in the first place. > It should be part of CPU Policy, and it's on a TODO list. But isn't this the same thing the CPU Policy code does? In recalculate_cpuid_policy(), it silently clamps the toolstack's choices to the max featureset. Ross From xen-devel-bounces@lists.xenproject.org Thu Sep 24 13:00:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 13:00:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432262.1653709 (Exim 4.92) (envelope-from ) id 1x9j4L-0007ay-3K; Thu, 24 Sep 2026 13:00:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432262.1653709; Thu, 24 Sep 2026 13:00:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9j4L-0007ar-0e; Thu, 24 Sep 2026 13:00:57 +0000 Received: by outflank-mailman (input) for mailman id 1432262; Thu, 24 Sep 2026 13:00:55 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9j4J-0007al-AX for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:00:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9j4I-00BHUU-N5 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:00:54 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab51f06-bab6-0a2a0a5309dd-0a2a4509b718-2 for ; Thu, 24 Sep 2026 15:00:54 +0200 Received: from [40.93.195.5] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab51f04-be1a-0a2a45090019-285dc305d175-3 for ; Thu, 24 Sep 2026 15:00:54 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV4PPFAC5861524.namprd03.prod.outlook.com (2603:10b6:40f:fc02::217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 13:00:50 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0428.015; Thu, 24 Sep 2026 13:00:50 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uGTdIfUPH5PiMXK0MocK9ekn7hBQBHIjSq1Hhoagn1G8nDag2r7EnM4vHHSIEGHRRQicKKOdNwhnx2jNAq/6lb9SPzsL1bDOG6EV70O/GFHLacJzWHdQLzw+qrMpY3FOjwRX6OHWZBsIiOXf+SSMjOC1gJ/ZD8XP+KNu/BW3pzBpIKIEU41iF9LJAHPznJlbCH631BN7K1YZqad5XqaRvR7wNwG/x7CDWOk6zuyInCYS32ZLHdhPVdZLNL9heerRSiBwyh71vL6Cg5CPC7+qqZzzBqUFcK7NIDEQ0fQ4QGZzSVrAyaVQfgx+3qobmuaw8dK8imzhvP5QrYmFsvoOgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VxCUXVQEYZxfbSOSIpLJalt/tkx250/1PfFRuiWtJeI=; b=iwE2qSvVWOeMYXInv9gSGWmFE8cPoZKfUFyJV5g9E9zv9hlk9+rp2OlvcX3RSoor9ttor2ce0NFn3f3jytN+90x9omN0GbuWovlrLh5de+7owMa5Dgs8n5qq4rxYyRcKC+dbfxZ/AF4AWWEdHSCt1K/6myaQzQNb/SR0c82s1axHG80+nvgHzAPeIzvG81fChTj8GjJ6HZZG//z+SSZCZGwp/of3DJzApf3ZwLjnVxifjn6BJkERyhsPtJu11Dr7NuR3ozU/ebHebQjOAF5AWMFL51J2Bos3awT90qIICbDIjytzVWdZP3Pxamr78av4CAi39en2Km8WBM9Hp7JIMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VxCUXVQEYZxfbSOSIpLJalt/tkx250/1PfFRuiWtJeI=; b=PyifM64bxATlhvSbuR6mbCe8oMs/bXi6QqnxLZGhNoJU5mnzEijkPji9a8vYdxbszt6xDAYk8MJj+W/v6YeDfeIWDJOiIzggYeMgvNZ/dDVRKUamkGEfq9O9EFfmRIJBl53otS4Wq08lod5lMi2oqQ8CjqVJhoanLakAX9ceV6g= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 24 Sep 2026 14:00:46 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86emul: Fix AAM emulation AH output To: Teddy Astie , xen-devel@lists.xenproject.org References: <1790251256.8631fc262581453bbf619ec5b2062170.1a0d34a4a2d00072c4@vates.tech> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <1790251256.8631fc262581453bbf619ec5b2062170.1a0d34a4a2d00072c4@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P123CA0003.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:338::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV4PPFAC5861524:EE_ X-MS-Office365-Filtering-Correlation-Id: f4c70ecf-567e-499c-be47-08df1a3bdbc6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|1800799024|366016|10067099003|56012099006|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: IFA8l9ubdv64eRHkltSpJ/j62+JpIOPCXnk9Ru1TClOEW1gHBVNDlPauw7EyvY0oq+z/glev43A+YG6GSrh7t5ZHNms6eOXRdOoBn0FoAZMSxQYKROhR5ufyR56PW24PLRdx8SnvpV/BbVFuQSc22vjj+gt71YLFqFye/JYhFp9Sb3oRQRii4DpIPMh/Zy4Xl3AWoey6p0115HV2Rwcu70a0kuN+x45LJK3gi7eI2lR1+BBeoIZ0H39ssbxRaE9TviwuDXC2/DAKnZZVytb/X4gNizskkMYZV/soryw9YATLkj/bDma11gX+EI1XsoMdlza2MwXYsvjCHPymtwQo5TpscUuCVLfK+UoIqz9NulN305dYBsS6nqEjFLZIAqJaV+VTET15gBzx/faMK+WM7YzZ+haCA9U/UJ+SeebX8A48V4gRuAQs5W8kdhagHYkCTBiltK/Jept5RfE6t7lsXpj1p/P5QfVTZZ72Iq777C2OvBtwYxrL+tBxB3q/d5eXflr6+mi5uIarCE9LBjuA2IUHokaFwWAuRPDgsgb5n/MVjFnx4bE0TyrCXPoS7YLIohaKe4Kl8Tp9wT0lERggouq8G3HXLIfkA1lTWwwr0ZR+VzhvvQq99K1ZwILHnN3JYXGc4+rW4mgNO3cBLiQKDSPaXZUECBItiH2WdV7BJ6o= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(1800799024)(366016)(10067099003)(56012099006)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M2pPZEJqbEdaV1BUbkthbmNSbUJZTVNjSDZ1QkNXYUdQeERSZ2cwNk1BK0RZ?= =?utf-8?B?d1B1Skc0SE9PWUZ3S2hiNjl4OHRONXlaRXJteXp3YTVWY1dsanJDRDRwQXBV?= =?utf-8?B?N2hzK3pOZ1dEYk9RK1ZxaEthTG95VlVCQzFQTnJKVnhQb0dDZDdOamhyUTEv?= =?utf-8?B?b0hkSlNiVXk3WlMxYk05aE9pakhCU3BBcHdLWmk0OE1GV09oQXhhNk9uSnYr?= =?utf-8?B?UXIvMkRGdk5zUVN4OVI1b1BUNGp6SStKeWtyMmwzd1A2NXREd1E5Y0xyZHVG?= =?utf-8?B?dUpQa1Q1d3ROYzNrWUwyNUdkN3N4VldySmttcndRZmEzK0RSczdrdnhWNEk3?= =?utf-8?B?S09KTVZTN0N5L1N6T1dWbVZuT1hieVJKQnQ0NkVpN3FZbkZRQVR2M1doOURX?= =?utf-8?B?SUdNWS9VbkxjQzUxZTliZXJPSzRxU3I1NUIxZE52dG9NTUhrVCtsdkxFdW1i?= =?utf-8?B?SExKNktRRkY5bVdUSUZhK0hVQXpINlFvbjJ3RVN0Y280QW1Vc09TakRIM3VE?= =?utf-8?B?SnFQYXF6akVKbnNva2lNOEJzbmltU0lLRDFGdExQUkExMDlaY1F6SDN2UU1k?= =?utf-8?B?bUhvS1FKR3QzRVArSkZ2SUNEdHFBY3FyYTVjS0RVZWdqRnNNdXc1UTBoeGhk?= =?utf-8?B?SGZqZnhrbWNiSEg4Mk1ncVFCbjBzY3dEQlBMaXE2SjE3Y0kybFp3enJlUEtz?= =?utf-8?B?ZXpKVUJWdnJJK2VjbzcvcHh3eHVUZXlUdnVrUkdKRFFCa3FIZk5XK3l5SHpL?= =?utf-8?B?eGIxZCtSUjV3bWxrMmN1dzlUK2h4ei9Ham1wa0luRm5sTm5ra0VnTnc5MlR1?= =?utf-8?B?R0dxckFIeXBBT2hEY2FmS3NwYlNhUlgyeGFEd05WaHN2R2g4WElzRFNKODl3?= =?utf-8?B?TWpxWTdJMzVqUjdzSFhOSFBkSXh4K3FZTmxJVjhMcXo0cWhFYUZIUkJXRFU0?= =?utf-8?B?Mm9PUlpQU3ZpM1cveHVnZlhrdnpDc0VXWUpIbFcxZ3VmUWVsbGdibVFXTytz?= =?utf-8?B?Z2ZWenczd0FNdlJ1Y1ZVdnNVR3hwQlpRU296dStuMUMzTmxJYlZ0TmVXU0sx?= =?utf-8?B?c2VKSGhmWTF5QTRkcS92THk5UXpSSytidnIybG9sTUJMcjYxTXdEQUVKdVhK?= =?utf-8?B?bE1uRm1haUw5YU1FRkRMSDYzUGlKQURtU0J0d05hLzZQNUJreCs2SFNGeEtJ?= =?utf-8?B?SGNaVmFLblIvSkU4NHpHTVppYWNYVkV3dE9hKzdXSU1rUEhRdlJVYVhRMkdj?= =?utf-8?B?NXp4VW1tY2RWdHRWTEFIMG1Vd3pQNSsvYU9rN1FXSDNqblgrdmV2eG1YRFlk?= =?utf-8?B?Z3FML3U3eVlxNUhMQmpZYktjaVVmaE5sWTdsK0JWakR6bUpoaDZFK1dPYURi?= =?utf-8?B?dkZ2Sm05SDY4dUEzcy9jR1ZGRGFmZ2JkdmhjOW5wMk1QL3NMajhrUVVtNVFm?= =?utf-8?B?eXdQd0JNckkvOEhTRTJrWkwyOUhXOUZhaXNUQXl3Nk93Slc2VFcxM2FvTGJD?= =?utf-8?B?b0JMZGRudlhpUmpPNDRVc1UwZWkwdVJRclUrN2xCT3FROWN0Qkg3TytlbTNN?= =?utf-8?B?Vm9UeUNvcEtOQjNCK3V1TTRsU2ZWWXV6UmtBNisxZGhubUtVc0xtZmVwd0Vk?= =?utf-8?B?RmZUSEVLQjd5c1QrT2E3OUI0cVVsNnFvOEJaQ3ljN3pyNGlOclcwQU9FbE1i?= =?utf-8?B?cEJGVlcyV2t3dzRoVFZhNDhhdVpHS0ZMSThLeUw4RmNKNnloUm5rdnhUSGQ0?= =?utf-8?B?L1lkQWlLOEdpMVBueUxqeEIxZmI0aWVTcmpZZzNwWUNtR3dycGFSWnlnMk9a?= =?utf-8?B?bG5sZEN6bnN5dURjUXNpOWVLYXJYck5FbnhRMmZWWVo0TUxLYS9QaFoxUGFw?= =?utf-8?B?cGlrZVVWcWdkNVJuYlYydkoyaDdnVzhaanhONG1SOGFqcTFxMnMrdFl4dThC?= =?utf-8?B?ekluamJmRG1xeGg2cUNwSVQ5TWwrSDZEN0xaUW9qblpmS3k4N0hIVU9pWG1E?= =?utf-8?B?TkRxV1FQcWtsQ1E4RjdINUVGSnRReERETzh6YUI0WHFRQWZlQjVUUENNbm4v?= =?utf-8?B?cGZiNkdEb1BTWFhoUG1sOCtZNy9uaEVSRjB0dWVpeUZwLzd1dTNPN3V1aGRL?= =?utf-8?B?dTFhUldOc21JNXNMSU9XQ2Y4cnphZTlqNm5lckNjbFFTVWVQWUp3Z0FjQVJs?= =?utf-8?B?OTIvdmt0Mm5SNXNmcndTSW1EYWlHd0FmTWZzTHpIeVZCSWJpQVhNU1ZSaHdX?= =?utf-8?B?dS9KcEh1RXIvMnZMb0FQcElrNGtyOFZFMkxaSnVMajdmRHgyalJ0NlZtdG5V?= =?utf-8?B?aEdEdjdrclZrMUFWMlI1MlNpNFY1dW8zTVRZR05GdzVzQkZQTHFMZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4c70ecf-567e-499c-be47-08df1a3bdbc6 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 13:00:50.3438 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: e+gvF8J+cCnhOeoSOsl7WgKEfEz761UGgV9ITt6MlwK3nzmvlO/lm5TCxZqwXjOQFfKyAl1gwzHAIyylr/Oi+IgTgM/eONMeJbfKa9S8Qz0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV4PPFAC5861524 X-purgate-ID: tlsNG-bad1c0/1790254854-FD26A034-CFEE8149/0/0 X-purgate-type: clean X-purgate-size: 1032 On 24/09/2026 12:59 pm, Teddy Astie wrote: > AAM is defined in APM as > > AH = (AL/10d) > AL = (AL mod 10d) > > However, due to the order of operations, we're incorrectly computing it as > > AL = (AL mod 10d) > AH = (AL/10d) = ((originalAL mod 10d)/10d) = 0 > > Fix it by reordering the operations to match what's defined in APM > and avoid the unexpected dependency between the 2 operations. > > Fixes: 8993572b9c16 ("x86emul: fold/eliminate some local variables") > Signed-off-by: Teddy Astie Oops.  Yes, looking at the code, it was previously:     movzbl -0x88(%rbp),%eax     xor    %edx,%edx     div    %ecx     mov    %dl,-0x88(%rbp)     mov    %edx,%eax     xor    %edx,%edx     div    %ecx     mov    %al,-0x87(%rbp) and with this fix:     movzbl -0x88(%rbp),%eax     xor    %edx,%edx     div    %ecx     mov    %al,-0x87(%rbp)     mov    %dl,-0x88(%rbp) Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Thu Sep 24 13:08:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 13:08:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432272.1653720 (Exim 4.92) (envelope-from ) id 1x9jBS-0008KS-T4; Thu, 24 Sep 2026 13:08:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432272.1653720; Thu, 24 Sep 2026 13:08:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9jBS-0008KL-PK; Thu, 24 Sep 2026 13:08:18 +0000 Received: by outflank-mailman (input) for mailman id 1432272; Thu, 24 Sep 2026 13:08:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9jBR-0008KF-JG for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:08:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9jBR-005MMr-09 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:08:17 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab520bc-e002-0a2a0a5209dd-0a2a4504cc46-20 for ; Thu, 24 Sep 2026 15:08:16 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab520c0-b57f-0a2a45040019-4a7de14ca0fb-3 for ; Thu, 24 Sep 2026 15:08:16 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f6350f91so1302621f8f.1 for ; Thu, 24 Sep 2026 06:08:16 -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 ffacd0b85a97d-488682668e7sm16723156f8f.4.2026.09.24.06.08.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2026 06:08:15 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790255296; x=1790860096; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=BTXDkeYMET/0xfBcH2qzBnboqdiJ8NYQEGyZ74erf5o=; b=Q/a84SO5s4aaa3WuK78jxvBtWBNkUtsK/1fUf1H8PFrsItcXIR72TpXmufYroNULxR yk6MSP7lfijv+e6ogpZq+eVTDFSPm3dzfS0I6gkBezymiinlgabA23Y+CjfECXMkcaZS AMD5Lm06nGoui4RYm0wrYyKw9WbeK6uGbegLsyMiz/Dr1QU0WoC8LYAGb0duh8QGNX2S kD8iw/Pr77VPZj+K0SvK1tlnfE509jfsWDC3D9lpGV5fBwb2Ub1cdi4G0gcK3Q0/WTRS fCin9Kuh6SRLFj9TgP0V6xjuHgd3lMyJMakwHzUcic4IKgBY289ImqyLtCaqgxhtU6m6 nC+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790255296; x=1790860096; h=content-transfer-encoding:content-type: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:content-type; bh=BTXDkeYMET/0xfBcH2qzBnboqdiJ8NYQEGyZ74erf5o=; b=CJWT0pVWbc9ZS2u3qBvt0vgEbok4ozbLYazmrF0BT7pXbIn0hygf5j/PKmMxUo8MUL NBu0rvxe37UBNoL9rXm+AhHPkVdn2PVjI5mB+E1iesPXeKa6jJZZFhfY/uoxaltJL2p4 is1fnMsCdELTox9V0Tvpur67Wl5dmwu70Ym090Q97jS9l2P+O7jZDpRwyw7HxM0q8D3a C+WBWErFMRw+Ljf9fq886Eb84XxR0W8viN/H+AZfS1EjRMvnJLUOsrrFZPrD8hMTqDzD jz/KZMqsc6vhsI0fLjiSjdq4jP2PYNFk6YibHJPf24gUrUWbI89YkDd/Xp/8LsHT8Dre G8IA== X-Forwarded-Encrypted: i=1; AKwUvBxfTso2dVKc0h7pAc8GyCvn7S5PFHYJ4YJxQ3fOmrAqt0bVtTSFeR4CPFMKP4cFnIxu32cYFW77WII=@lists.xenproject.org X-Gm-Message-State: AFuF++l8VwmHwubTXpVpDNk9vUh/8nENmnaZP5RpY2abEjsuRWRIn2r9 iVjpIbkpmappH4x6hwLqXQpHcYNrRNlOg7TtcvpKPzO2oWA1w3eUusOeC6NWzl2uzg== X-Gm-Gg: AYBFou0ISDXjbWScuLWCaSY8bao4WEP33FImP93qBs49yZFto15vsol/wT+w1O4H3QX /Zr6jD12mjWvoBHDs3O0pe7DLEY7uZFunueEgOdwlmJemSuM7RAstdsErGmUpUItzr75W9T6kQ1 LXZO0oV0dxNCnDPfAsoB+RtboVqVh7vYeK5Q3oGV7Z/nxo1A1e3vLTHMhDQjHUwQaGvgL4uqRJw soI0+TJ+XMMBE9SI33cy6ceu23Q36by1SBDbRv0Y76SUF4laj+9CguL8n1mLFlLLOpe+hMIR+Nu 2BJoTmjHrhUW8Kn9200pViYqi2aF+PRWqzdlTQRb/vxX3e5c7DrWjcrjy/ygkcMQnCZd3GTZkS+ 9ILCCG7z+RHiGN0BEuvH505iHxS4RM8IcyYEfznZ/XzjaYisNcNI1p+iMj0vZrAhDqFn/Wbgdb/ x/zGvi/M1NMjF9055TcnNZCNtM427eDlkXhHjBPWUEeIxGo5mAOB3fwWljxa+IIZOTD9n8tsbTs fvk472Gi99h7yrWL8fcPwlCPNQGdzn+46O5vMvOvCMbwXOwmed6YnuUGDX1Cg== X-Received: by 2002:a5d:64e6:0:b0:487:452:dbd3 with SMTP id ffacd0b85a97d-488718773e3mr4759528f8f.47.1790255296132; Thu, 24 Sep 2026 06:08:16 -0700 (PDT) Message-ID: <2f929826-3a32-405e-9bd9-0d47006e14f6@suse.com> Date: Thu, 24 Sep 2026 15:08:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/hvm: Clamp Viridian features to known set To: Ross Lagerwall Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Andrew Cooper , xen-devel@lists.xenproject.org References: <20260924110342.1045230-1-ross.lagerwall@citrix.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 X-purgate-ID: tlsNG-ebf023/1790255296-504DBB50-86B8DA5C/0/0 X-purgate-type: clean X-purgate-size: 1051 On 24.09.2026 14:56, Ross Lagerwall wrote: > On 9/24/26 12:20 PM, Andrew Cooper wrote: >> On 24/09/2026 12:03 pm, Ross Lagerwall wrote: >>> Instead of returning EINVAL on an unknown feature bit, clamp to the >>> known feature set. >> >> Sorry, but no. >> >> This is equivalent to saying "I've got a VM using AVX512" and Xen saying >> "ok, I'll ignore that safety check and let you run on non-AVX512 capable >> hardware". >> >> Requesting a feature that Xen doesn't know about is a hard error. >> Truncating features out like this will cause a guest using those >> features to malfunction. >> >> It is a bug that this was expressed as an HVM Param in the first place. >> It should be part of CPU Policy, and it's on a TODO list. > > But isn't this the same thing the CPU Policy code does? In > recalculate_cpuid_policy(), it silently clamps the toolstack's choices to the > max featureset. Which is behavior that, if I'm not mistaken, is supposed to go away. Such requests are intended to instead fail, down the road. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 24 13:32:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 13:32:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432331.1653728 (Exim 4.92) (envelope-from ) id 1x9jYX-0004ER-Fv; Thu, 24 Sep 2026 13:32:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432331.1653728; Thu, 24 Sep 2026 13:32:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9jYX-0004EK-DJ; Thu, 24 Sep 2026 13:32:09 +0000 Received: by outflank-mailman (input) for mailman id 1432331; Thu, 24 Sep 2026 13:32:07 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9jYV-0004EE-Eh for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 13:32:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9jYU-005bQO-Rg for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:32:06 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab52648-bab6-0a2a0a5309dd-0a2a450cd940-46 for ; Thu, 24 Sep 2026 15:32:06 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab52656-f479-0a2a450c0019-4a7de14cf244-3 for ; Thu, 24 Sep 2026 15:32:06 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-4843c3ea1f6so1230861f8f.0 for ; Thu, 24 Sep 2026 06:32:06 -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 ffacd0b85a97d-4886877a2a5sm15711533f8f.26.2026.09.24.06.32.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2026 06:32:05 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790256726; x=1790861526; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=A60fnXQj1SmvzB1OAk6yyuqIDiHJxqcVriICMz51sH4=; b=eArkGuwZs56aPJnnNb2/AXMD9zodQZcNjyX6ltNJo0nIOy3EbFGzp8YNskFB+xCAuv WfkZNEd4s0eUlXAUtzcgPlskOxsuLSl2w7HNPDdAQ8UeKQ3qeh4mE8dg0edjeo8gdX/E vStWRFHS+Q25Wn3e8h5cho6KI8Ki27UWNf4zHdSCIDWe9JaDNmKbJqtoh7YOb5oH/ayO YxKh5lHp6ZCdqonH1cVGhNQsIicmTCS10b+wb790po+AbpnW/sjJ7aAAYhUUARA+qWcn yE1kzTWQL7vHwnU0RriCEMVS1tmuqu10auhok3VivrH/m3urEwkVu9DzYOLQPV79l8XE shvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790256726; x=1790861526; h=content-transfer-encoding:content-type: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:content-type; bh=A60fnXQj1SmvzB1OAk6yyuqIDiHJxqcVriICMz51sH4=; b=RLt+TWhBF6sRYdxuGNo76olYBBnvHy+vXFfcO243uK+VXTWu9VaQmkL7XAauLK0uBD M8N2rCOy8mh12U2lhTHEHE/E6ABjaxU7DgpXbwXmrwGTDID0mHBTkUwwZFIJCVbBstte qqaarYlPWduKj7juXDF+rK79S8OwiUEtUiwO35/2WezwaIFhEZux9SBFkdWJsChqIYYF xdylu15yaFOS39s5aGyDsRX57ry5y9jiC99GtkQasTwNsK1Q7Xus17QH5FrQm5WvXcZv wy/L+W36DHumXUQRl3KpTU2KUlYO/6U4pI3KR+fmU18vwE61VWPbHL6L6i3I94LLxUK0 9PGA== X-Forwarded-Encrypted: i=1; AKwUvBzbeUFHFCSFWD4Z9VRZiKLtvAZPoLotzWZACpdKX3VKoenFtPf40jgF2vQJ9tj/zSRjEMLFajOidms=@lists.xenproject.org X-Gm-Message-State: AFuF++kwTHzpUqM743diJDaSeUx7JjqaRXltheDYlR7kBcwlXsBbW3L6 BV3/MLMBJ5x4WcqcdBdU2+9jdYz1Y+uNyfPNrCVakq4D4UQFBMtm1OG+zF7U35KvAA== X-Gm-Gg: AYBFou3LFsCaA23JujjP5yqxq3kFc4PLgHe/FCactZT159ZUcFVVekxGpGTc5PlhR4n cRxRdJfVJ9pxVI+Bpes3h3yAQGm57ll+U64iqsiodCX3tCZEIaBVRmQn2vnZJ6x8ziJ1hWoV/LL PG1eMKAxO6UQqOytIuR7zWCfET9pBxtaUsG1co6DNOqZBAChDuXhopZOJE7rMWBIUdfhmTcrpzR ev1xD/tWOg0wK9CUPy4CCDavM4fBpCxWfiEw5Wua/868PYTnrO8U4zTzqFJQkyc9HKbLlbmJwzY tmKiVcoc2q2QEVjDPChaONOtSUbiXARB+UKvWkBnHhGAQKPnL6XqMspMjrJgA1s+h2LFBJ2dD7T smUj03i9uOPtq3SftaFjC9ixkMe4FJ4evb7tB3dkOLzYXmM2nheQU6aQKcYCjhLh+DRLxxtSU6N fhQpz3pwBpaxLZSrMGRgd0j0j8Z8aKonGUyqM26a+XCF4ZzB4H/17hRmRDz8Sz4/GmSelPoeMw2 d0xB30Wf0D6DstYs/ssY/GVfTruBNgR+J+BKbx5mhseKKnh194IlGdOWpiL17I= X-Received: by 2002:a05:6000:4107:b0:488:781b:847b with SMTP id ffacd0b85a97d-488781b87b5mr544329f8f.16.1790256726030; Thu, 24 Sep 2026 06:32:06 -0700 (PDT) Message-ID: <8cbdcbf9-4ac4-4bb3-8b1a-c61550a92bb4@suse.com> Date: Thu, 24 Sep 2026 15:32:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/common: fix MISRA R7.2 violations in crc32/unlzma/bunzip2 To: Andrew Mbugua Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger@xenproject.org, sstabellini@kernel.org, xen-devel@lists.xenproject.org References: <20260924122403.214738-1-andrewprecious388@gmail.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: <20260924122403.214738-1-andrewprecious388@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790256726-01CC3A5B-FD965B2A/0/0 X-purgate-type: clean X-purgate-size: 1412 On 24.09.2026 14:24, Andrew Mbugua wrote: > Adding the U suffix. No functional change. > > MISRA C Rule 7.2 demands a "u" or "U" suffix on all > integer constants with unsigned type. On 32-bit int targets > constants >= 0x80000000 (e.g. 0xEDB88320, 0xFFFFFFFF, > 0x80000000, 0x04C11DB7) must be written explicitly unsigned. 0x04C11DB7 is small enough to be okay without suffix. Adding one nevertheless is fine, but the description wants to be correct. Furthermore, rule 7.2 is clean as per tagging.ecl. As per exclude-list.json common/bunzip2.c, common/un*.c, and common/xz/* are excluded from scanning. The fact that the change is benign to our present scanning status imo also wants expressing in the description. And then there is the question whether we want to fiddle with these files in the first place, when really we'd prefer them to stay as closely in sync with their originals as possible. > --- a/xen/common/bunzip2.c > +++ b/xen/common/bunzip2.c > @@ -650,7 +650,7 @@ static int __init start_bunzip(struct bunzip_data **bdp, void *inbuf, int len, > for (i = 0; i < 256; i++) { > c = i << 24; > for (j = 8; j; j--) > - c = c&0x80000000 ? (c << 1)^0x04c11db7 : (c << 1); > + c = c&0x80000000U ? (c << 1)^0x04c11db7U : (c << 1); Please (if we go with fiddling with these files) can you also add the missing blanks around & and ^ at this occasion? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 24 14:26:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 14:26:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432409.1653737 (Exim 4.92) (envelope-from ) id 1x9kOZ-0003bL-1A; Thu, 24 Sep 2026 14:25:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432409.1653737; Thu, 24 Sep 2026 14:25:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9kOY-0003bD-Tv; Thu, 24 Sep 2026 14:25:54 +0000 Received: by outflank-mailman (input) for mailman id 1432409; Thu, 24 Sep 2026 14:25:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1x9kOX-0003b6-BP for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 14:25:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9kOW-00EwCk-OJ for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 16:25:52 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab532e8-bab6-0a2a0a5309dd-0a2a450380a8-18 for ; Thu, 24 Sep 2026 16:25:52 +0200 Received: from [185.255.28.18] (helo=prod-mta-13.swg-srv.net) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab532f0-fae8-0a2a45030019-b9ff1c12a8df-3 for ; Thu, 24 Sep 2026 16:25:52 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d3cee79600072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 24 Sep 2026 14:25:47 +0000 Received: from [192.168.1.46] (areims-651-1-80-194.w90-18.abo.wanadoo.fr [90.18.187.194]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 783CE81EA6; Thu, 24 Sep 2026 16:25:46 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=pgD99OPWhS2+dozYhllIuqvIxVyi9V2mn9n5kxDxa2U=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=YdibUOkf0q4M15+dxqFs4v+R9xo/iua2mPJrM1L8V03vPGIE5D2aSF5/4Vm9QK8P5T8dr0OEY 2KtqA46nG0pNGAEAM6wepO11XXXoMikbR53QtLj26p1F6RH/Qd75eggFhFM1IMuw6Ao4exI6S05 iSuypVZxMWGqnOU2PzyN9N7USuzYXOjE8TNJI0IVWTeszHMS4ovGqZ6jQlw2CR0r0kNOUpZEg7s Ov3a2EaTTMU28Qjy7dNBKaogfA+Lg+S6AzsLAJDohHW3lsg6G58usASer4QNQ/jyiqvQkaYDga/ 70bYDSjYO7cs3z2w1TqPM3r87Z7O9K/tRZQisTMy22Pw== X-Zone-Loop: 34665cbd472bd0dba862fab8c3f08dcb1d37e41df772 x-campaign-type: default x-transaction-id: 6b8d1706-cc5d-4a80-b176-856d61502683 x-swg-uid: 01-5c35a8cd-4bb4-406f-88a2-46012120e8e2 X-Mailer: Sweego Message-ID: <1790259947.8631fc262581453bbf619ec5b2062170.1a0d3cee79600072c4@vates.tech> x-swg-bid: 1790259947.8631fc262581453bbf619ec5b2062170.1a0d3cee79600072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Thu, 24 Sep 2026 16:25:39 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790259941; l=8777; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=9y056bptfxndkZj69JAMSiYN5GgS+GQvU6OJpjFDa4k=; b=MVDU3jEjo7H6uaRHWQPVl3x9ACcfAv+k+cgWFC5DzJOrTrGUFdJlApy95rNDvXz354Qt2blCf C/RxqmhRfMAAbk4sHIUNa4fYo6uDiHTAPpkBbsVuKzQnRAJtnJloUcn X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790259946713 X-purgate-ID: tlsNG-33051d/1790259952-6CADC4E9-1643989F/10/73395122804 X-purgate-type: spam X-purgate-size: 8777 > While a vCPU is running, MSIs written to its h/w IMSIC guest interrupt > file are delivered straight to VS-mode. Once the vCPU is descheduled > nobody observes that file anymore, so a guest blocked on such an > interrupt would stay blocked until some unrelated event happens to > schedule it again. > > Let Xen observe the file in that window: on deschedule set the vCPU's > bit in HGEIE, which turns an interrupt pending in its VS-file into an > HS-level SGEI, and clear the bit again on schedule-in. HGEIP only > reports a file number, so to get from it back to a vCPU keep an > owners[] map per pCPU, filled by vgein_{assign,release} alongside the > VGEIN bitmap, and kick the vCPU it points at. Nit: I would reword the last sentence to make it more clear: HGEIP only reports an interrupt file number, so to find the vCPU to kick, keep a per-pCPU owners[] array indexed by file number and updated in vgein_assign()/vgein_release() together with the VGEIN bitmap. > > v->arch.hie is only initialized here and is written to the CSR later, > on the context switch to the vCPU. > > vgein_release() still has no caller: a vCPU going away has to both free > its VGEIN slot and drop the owners[] entry, but there is no vCPU > teardown path to hook it into yet. vgein_deinit() only covers a pCPU > going offline. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c > index 1aca07c2f7..9642a9796e 100644 > --- a/xen/arch/riscv/aia.c > +++ b/xen/arch/riscv/aia.c > @@ -18,6 +18,13 @@ struct vgein_ctrl { > /* The least-significant bits are implemented first, apart from bit 0 */ > unsigned long bmp; > spinlock_t lock; > + /* > + * Guest interrupt file IDs run from 1 to geilen inclusive (0 means that > + * no guest external interrupt source is selected), and geilen can never > + * exceed BITS_PER_LONG - 1, so indexing this array by the ID directly > + * always fits. > + */ > + struct vcpu *owners[BITS_PER_LONG]; > unsigned int geilen; > }; > > @@ -62,23 +69,25 @@ static int cf_check cpu_callback(struct notifier_block *nfb, > unsigned long action, void *hcpu) > { > unsigned int cpu = (unsigned long)hcpu; > - int rc = 0; > > switch ( action ) > { > case CPU_STARTING: > - rc = vgein_init(); > + { > + int rc = vgein_init(); > + > if ( rc ) > printk(XENLOG_ERR "AIA: failed to init vgein for CPU%u: %d\n", > cpu, rc); > break; > + } > > case CPU_DYING: > vgein_deinit(); > break; > } > > - return notifier_from_errno(rc); > + return NOTIFY_DONE; > } > > static struct notifier_block cpu_nfb = { > @@ -138,7 +147,10 @@ unsigned int vgein_assign(struct vcpu *v) > if ( vgein_id > vgein->geilen ) > vgein_id = 0; > else > + { > __set_bit(vgein_id, bmp); > + vgein->owners[vgein_id] = v; > + } > > spin_unlock_irqrestore(&vgein->lock, flags); > > @@ -161,6 +173,7 @@ void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) > spin_lock_irqsave(&vgein->lock, flags); > if ( !__test_and_clear_bit(vgein_id, &vgein->bmp) ) > ASSERT_UNREACHABLE(); > + vgein->owners[vgein_id] = NULL; > spin_unlock_irqrestore(&vgein->lock, flags); > > #ifdef VGEIN_DEBUG > @@ -168,3 +181,36 @@ void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) > __func__, v, vgein_id, cpu, vgein->bmp); > #endif > } > + > +void hgei_interrupt(void) > +{ > + unsigned long hgei_mask, flags; > + struct vgein_ctrl *vgein = &this_cpu(vgein); > + > + hgei_mask = csr_read(CSR_HGEIP) & csr_read(CSR_HGEIE); > + csr_clear(CSR_HGEIE, hgei_mask); > + > + spin_lock_irqsave(&vgein->lock, flags); > + > + for_each_set_bit ( guest_file_id, hgei_mask ) > + { > + /* > + * guest_file_id shouldn't be zero, as it will indicate that no > + * guest external interrupt source is selected for VS-level external > + * interrupts. > + */ > + ASSERT(guest_file_id); > + > + if ( vgein->owners[guest_file_id] ) > + { > +#ifdef VGEIN_DEBUG > + gprintk(XENLOG_DEBUG, "%s: kick ->%pv, hgei_mask(%#lx)\n", > + __func__, vgein->owners[guest_file_id], hgei_mask); > +#endif > + > + vcpu_kick(vgein->owners[guest_file_id]); > + } > + } > + > + spin_unlock_irqrestore(&vgein->lock, flags); > +} > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index 2dfe4c2e72..2918196822 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -136,6 +136,8 @@ static void vcpu_csr_init(struct vcpu *v) > v->arch.hstateen0 = (hstateen0 & csr_masks.hstateen0) | > csr_masks.ro_one.hstateen0; > } > + > + v->arch.hie = MIP_SGEIP; > } > > static void continue_new_vcpu(struct vcpu *prev) > @@ -398,6 +400,7 @@ static void restore_csr_regs(struct vcpu *vcpu) > csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); > csr_write(CSR_HIDELEG, vcpu->arch.hideleg); > csr_write(CSR_HVIP, vcpu->arch.hvip); > + csr_write(CSR_HIE, vcpu->arch.hie); > csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); > csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); > csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index d7b137a1f5..0715206611 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -510,12 +510,31 @@ void cf_check imsic_ctxt_switch_from(struct vcpu *v) > > write_lock_irqsave(&imsic_state->vsfile_lock, flags); > imsic_state->vsfile_cpu = v->processor; > + /* > + * Start to observe the VS-file from HS-mode: while the vCPU isn't > + * running an interrupt pending in its VS-file is reported through HGEIP > + * instead of being delivered to VS-mode, which lets Xen wake the vCPU up. > + */ > + csr_set(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); > write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > } > > void cf_check imsic_ctxt_switch_to(struct vcpu *v) > { > - /* Nothing to do */ > + struct vimsic_state *imsic_state = v->arch.vimsic_state; > + unsigned long flags; > + > + /* A s/w VS-file is never observed through HGEIP. */ > + if ( !vcpu_guest_file_id(v) ) > + return; > + > + /* > + * The vCPU is about to run, so hstatus.VGEIN delivers the VS-file's > + * interrupts to it directly and there is nothing left for Xen to observe. > + */ > + read_lock_irqsave(&imsic_state->vsfile_lock, flags); > + csr_clear(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); > + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); > } > > int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) > @@ -646,6 +665,12 @@ static void cf_check imsic_vsfile_local_read_clear(void *data) > struct imsic_mrif *mrif = idata->mrif; > unsigned long new_hstatus, old_hstatus, old_vsiselect; > > + /* > + * The HGEIE bit imsic_ctxt_switch_from() armed belongs to the old owner > + * only. > + */ > + csr_clear(CSR_HGEIE, BIT(idata->hgei, UL)); > + > old_vsiselect = csr_read(CSR_VSISELECT); > old_hstatus = csr_read(CSR_HSTATUS); > new_hstatus = old_hstatus & ~HSTATUS_VGEIN; > @@ -991,6 +1016,21 @@ int __init vimsic_make_domu_dt_node(struct kernel_info *kinfo, > return fdt_end_node(fdt); > } > > +/* > + * Start to observe the interrupt file from HS-mode, the same way > + * imsic_ctxt_switch_from() does it for a vCPU which is switched out. > + * > + * The counterpart, clearing the bit of the interrupt file which is left > + * behind, is done by imsic_vsfile_local_read_clear(), which already runs on > + * the pCPU owning that file. > + */ > +static void cf_check imsic_local_hgeie_set(void *data) > +{ > + const struct imsic_vsfile_data *idata = data; > + > + csr_set(CSR_HGEIE, BIT(idata->hgei, UL)); > +} > + Sorry I'm a bit lost here, are you doing that for vCPUs migration? Because in your commit message you only mentioned scheduled-out case which needs to have Xen observing the descheduled vCPU to re-scheduled it, but no other case that would need to have interrupt file observed is explained -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Thu Sep 24 15:01:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 15:01:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432503.1653746 (Exim 4.92) (envelope-from ) id 1x9kwy-000139-MV; Thu, 24 Sep 2026 15:01:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432503.1653746; Thu, 24 Sep 2026 15:01:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9kwy-000132-Jo; Thu, 24 Sep 2026 15:01:28 +0000 Received: by outflank-mailman (input) for mailman id 1432503; Thu, 24 Sep 2026 15:01:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9kwx-00012d-Mk for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:01:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9kwx-005rPT-3I for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 17:01:27 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab53b40-bab6-0a2a0a5309dd-0a2a450cc5d4-28 for ; Thu, 24 Sep 2026 17:01:27 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab53b46-f479-0a2a450c0019-4a7de18d8a9f-3 for ; Thu, 24 Sep 2026 17:01:26 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e6b885ef8so12625575e9.1 for ; Thu, 24 Sep 2026 08:01:26 -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-49fdf9691e2sm148828515e9.1.2026.09.24.08.01.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2026 08:01:24 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790262085; x=1790866885; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=2fo/K6E6my/zZjyksIY1zyo7gKRSPCXkbVyYhlm4zKE=; b=OzrnFD0Wvya+zk/ZSy2sotzkyIymHaJ3UZn39Q/R/8U+ngFAeRhUg8UH6QwssROta8 InzA01oCoPpsTrA5JO6hqqLmpfZ/MGaCSLNrqEmNj6tYObu6mXgdGwAON373lRBZgqOf j44aoK2lr/2qyd0ScLa6m5ivKnF3lZsOZjWkbc+HP8Q7L9qcBT5gGRWgjfW7nlG5Zp6y TUJGMzUqAakatsi+fXPkxug2KVUkxY+hEM3EBFKGQ7YXyB1oAuZmt06yHkO1DtM/irU4 7RV6yCkTaTCGyevNzqSN9glnmJz4puqAsXRrw5HcFXre6FKrO1tvLPG5Cc22fvVcddZS N2pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790262085; x=1790866885; h=content-transfer-encoding:content-type: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:content-type; bh=2fo/K6E6my/zZjyksIY1zyo7gKRSPCXkbVyYhlm4zKE=; b=VMXLkV0H37HQb5NwIHTtNB19tXyzK4lblmjRftpeiDbGNoHLKT4LbPaRykgaPRkqso EpPo/9nA5sZLaaoqvY9GRpZ7IdV/QO7Bwj48r3L+ro46++pEviQIn5cwLae8qdCYUCFC MMhB+9BzAA8bQfVY00FW0Hq3nRiugE7o1HrW1uLiWRFWW5UecTOyfud306I1J8Rc8fVw AsuELdV4Ys7JRVQqmBkFqs/EZ3xaGBqEvDlx+rHP3lXFZNjOhYpPNjj2Qh0uSGGWlmyt WLHJQR9pLJz/9l6KYDbQexTM0SRS29rNtAeekE3zSNVprWovW1+fdc+fm06V73mNWlTH LIJQ== X-Forwarded-Encrypted: i=1; AKwUvBwLRkB0n4ElRZFuZ7EU6nFCSDS8vYGTLAigyh5hughxtG9BiiOquaOYuZ9h8PlQeiO7fYOdtGYujww=@lists.xenproject.org X-Gm-Message-State: AFuF++nryDQ4YqBOvBlEDq1sqLZDqwIUlkcZMe8UXHw/vZanNGrU2QFI oTg9hblsw3+/JBGE7yfTDb9vpbdI1OPikr+hjgUYEMkJX+DgEQeyzeGyTzZ5vf+/dQ== X-Gm-Gg: AYBFou3z/6CedAEMzOXCn6ohMBdRKl4fuCK5sG7XqLJXxl2u/crmqj0MFhH7nBbfQsp bUAEHnNYpHNfKbTjEya0zhSPu9aym6MAoAE8bYvEWkgtfFM/T1Jmd2bSrGzXYLtSmVtDlNYmXwA Wkwdkh48Aw5t0NyBZYpNNgWV65sVLHJHa03rcl+NaNjCfgRCMBzvNFbAnT67gq3gFXi5JK8x/1k TLjxiKu49CBXT/LrIi/P6f4YAjNt+AXt5DmlKIQ2J8vEcnzEIPUI6Xlg5VwLpncw2zB8yfl2DOl ONJaffeKXsxCsW38zjfwD5SGn/Oc1DeyLd2iMsHjUb8flFiNof0rET2mNE3SAZWN/K8XqTaKIOE D2qglYd78PCRUM+2Q/N+xe3nIfH040vGUBQCNku1Y6RFFhF7vk5Ybb0rydGr+oV2mWvP6F+nTrp 07DrT5i8wf7532YVTv7kl0isMWepjceIKFIGOibYI9XTxx4HBvKJ1572JSJ/iqyKB1K0mgG43hg AZDm7zrgqZOD1lqUKk1wcJHRxkXQKFBCgwtvgGvLMjzj98mYhGK+gU86zqN1w== X-Received: by 2002:a05:600c:314a:b0:49e:6778:c2bd with SMTP id 5b1f17b1804b1-49fe66c86bcmr51828755e9.6.1790262085556; Thu, 24 Sep 2026 08:01:25 -0700 (PDT) Message-ID: <711e6af5-beca-4b71-a2cb-75cb1ed93689@suse.com> Date: Thu, 24 Sep 2026 17:01:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Save L2's CR4 on #VMEXIT, not Xen's To: Ross Lagerwall , Lin Liu Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <38c41bfb-48c6-4408-8da1-2b7d730a6c9e@citrix.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: <38c41bfb-48c6-4408-8da1-2b7d730a6c9e@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790262086-002F0A5B-05CE255F/0/0 X-purgate-type: clean X-purgate-size: 1666 On 23.09.2026 13:16, Ross Lagerwall wrote: > On 9/23/26 10:51 AM, Lin Liu wrote: >> Xen leaks the host's CR4 bits to L1. >> >> nsvm_vmcb_prepare4vmrun() constructs the shadow VMCB's CR4 via >> hvm_set_cr4(), and svm_update_guest_cr() ORs in HVM_CR4_HOST_MASK. >> nsvm_vmcb_prepare4vmexit() then copies CR4 back out of the shadow VMCB >> instead of the value kept in v->arch.hvm.guest_cr[4], so L1 reads back >> Xen's bits - under HAP, CR4.MCE. >> >> Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") >> Assisted-by: Claude:claude-opus-5 >> Signed-off-by: Lin Liu >> --- >> xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c >> index a8b15d6eae..8d99b0affc 100644 >> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >> @@ -1082,7 +1082,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >> ns_vmcb->_efer = n2vmcb->_efer; >> >> /* CRn */ >> - ns_vmcb->_cr4 = n2vmcb->_cr4; >> + ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4]; >> ns_vmcb->_cr0 = n2vmcb->_cr0; >> >> /* DRn */ > > Reviewed-by: Ross Lagerwall > > Did you consider addressing similar issues with the other state copied from > n2vmcb as well? i.e. I think something similar would apply to CR0, EFER, etc. But (assuming the above code change is indeed correct) wouldn't we better deal with CR0 then right away, rather that leaving things even visually inconsistent? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 24 15:22:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 15:22:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432532.1653754 (Exim 4.92) (envelope-from ) id 1x9lGp-0004Ln-7b; Thu, 24 Sep 2026 15:21:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432532.1653754; Thu, 24 Sep 2026 15:21:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lGp-0004Lg-4r; Thu, 24 Sep 2026 15:21:59 +0000 Received: by outflank-mailman (input) for mailman id 1432532; Thu, 24 Sep 2026 15:21:58 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lGo-0004La-3J for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:21:58 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9lGn-006wTd-CM for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 17:21:57 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab54011-bab6-0a2a0a5309dd-0a2a450cb5e6-8 for ; Thu, 24 Sep 2026 17:21:57 +0200 Received: from [74.125.225.140] (helo=mail-wm2-f12.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab54015-f479-0a2a450c0019-4a7de18cfa3a-3 for ; Thu, 24 Sep 2026 17:21:57 +0200 Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49cd38e0e5dso27897225e9.2 for ; Thu, 24 Sep 2026 08:21:57 -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-49fe0c3731fsm141138565e9.2.2026.09.24.08.21.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2026 08:21:56 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790263317; x=1790868117; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=mQ6Z5Fp/6POQiZdohnTBjItV7NbW9wvywJBkS1/asbw=; b=b2Jk8rmfkR+DIX7xsUKSyA1xc9Airrg8vuQhqKloj4Etjw84bWNVaWKA11AE/S4cuv PMAONIBzdsxbrW7n0O61OHRY9at6W2zgLnGgB137b9wPmP073vCfocKMdl/z7BkmBrGl G/sZt6lo7E5TcfBGV6oM1V+ZSYOB2rLng3TzJh9IL+RWE7RL7Pbdi+n5mL5V6UF1YKOq r2GdoBYgN2xWXWi9GPJNKlLMoC82dCaVxipzeRaIY12NjoHUIXrENspH9lMEtZZkfJQN 6fmqoF06/y3rD83801Vg9fNvDAhq0JI+Qzefeg50UEWVQcIvHbURribEye6CMDKZDMY4 AN0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790263317; x=1790868117; h=content-transfer-encoding:content-type: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:content-type; bh=mQ6Z5Fp/6POQiZdohnTBjItV7NbW9wvywJBkS1/asbw=; b=b30oFjgXL7wKXcfw7DC6rkmr36dDiKUfmCaB39rQ4VpBI1oVL6A/2FnciWup0JIg2J NHscyivLyowm6qmj2UnpAkIAiGnhe81yClJJMonVazJExRyeWAYHHZZx30hPt0rC6qdU qAWHsahYdymIpNtFGGSIRx6kbhqVwNQEeN9i9JQKyrBBDdBN2gVTTYKtC5RSjqPpy2Hs ueIW/116/sWyOIxqynwqGH1yccclU+fmPca8wvkteK4VYGDhdeLy+q33+sXhaNRJuXih NSJnSOG+ttw2bmN3xvnVTK/sG3HQCyHGKzYquyuS99hbYnvxGSnADXiX5rjNgMP3MTEb ZJaw== X-Forwarded-Encrypted: i=1; AKwUvBw3gb1b1BqYBJF8jao+uSDVGFPe2ZEprNlk9CvKvujSEhdsdstyVBtwqPvS3b+ZrW77kyqOZho7du8=@lists.xenproject.org X-Gm-Message-State: AFuF++mxcy38LOV+TDY+CW3eQ84vJGzUOcnoF510FbDYvpSUugsFJum6 kkbJ7Bg+hPYERoayWlZQtMy4no4bXgU+BNnAPZMi+kim+dY2Xw9URr6u6DJGG/wcxQ== X-Gm-Gg: AYBFou1PcMiG48e0tDxk85jULMw5WsMOzfWYIMKusSAXUQPjj9cn4wk79S01XCtHCmT uGQCQw07l8foh1XFjBS9R66qUYQ8a5FVPKSd6J2vAKmLrafZD2JuDVMbFlu6itjB5y8f6oqvzjn o7LF0JYMEH6pcen6IUuGYXrsuHIJjz6V+7+5yoCWmjCiMYuEocsMm9OlxV//qwSbE5V8+I13+YB Rm3PxdNvfRwYl1VObXIR9FMwdy3usoCcEHvIM1AsGSADf+DDPOdwtPwTAWecRuK+X6PgHC3M0Z1 72A4g761Cqx6E58gJU6JJZvy37Z4ozlIj+60kPGNJh8Nw7WuX3h5gMGKJvW9e9h6G5xg2nM+RsW 86ovqMPxyWsQZrCOn7r4EB9QuEMwQQxC04lZQt3ZMDALjtags6jlXVYbXsLgaBnWjuvjnWu1DhJ BGoke1DZHmvJuVebvSQlazgMYDoHwhojYBl39+mcaZ3A1gCcOMgJsnU9KCgAZCOobzzBSlhWFsG S0/qD4qL5amCqPrlv8FXyWGXFTojNMAMMnhU58PGr/nILTqWiOltd0yabw5+g== X-Received: by 2002:a05:600d:8482:20b0:49f:c451:b4ab with SMTP id 5b1f17b1804b1-49fe67bc264mr36213175e9.29.1790263316630; Thu, 24 Sep 2026 08:21:56 -0700 (PDT) Message-ID: <8bc996ec-09c0-4241-bc3a-64dbf44c5e5f@suse.com> Date: Thu, 24 Sep 2026 17:21:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Save L2's CR4 on #VMEXIT, not Xen's To: Lin Liu Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: 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 X-purgate-ID: tlsNG-d25034/1790263317-51F33A5B-27E84408/0/0 X-purgate-type: clean X-purgate-size: 607 On 23.09.2026 11:51, Lin Liu wrote: > --- a/xen/arch/x86/hvm/svm/nestedsvm.c > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c > @@ -1082,7 +1082,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) > ns_vmcb->_efer = n2vmcb->_efer; > > /* CRn */ > - ns_vmcb->_cr4 = n2vmcb->_cr4; > + ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4]; > ns_vmcb->_cr0 = n2vmcb->_cr0; In addition to mirroring the change to CR0 and EFER, doesn't CR2 also need handling the same way? Effectively the inverse direction of anything respective that nsvm_vmcb_prepare4vmrun() does? Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 24 15:30:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 15:30:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432553.1653763 (Exim 4.92) (envelope-from ) id 1x9lPM-0006BP-19; Thu, 24 Sep 2026 15:30:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432553.1653763; Thu, 24 Sep 2026 15:30:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lPL-0006BI-Uk; Thu, 24 Sep 2026 15:30:47 +0000 Received: by outflank-mailman (input) for mailman id 1432553; Thu, 24 Sep 2026 15:30:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lPK-0006BC-6q for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:30:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9lPJ-00D0Vb-JM for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 17:30:45 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5421a-e002-0a2a0a5209dd-0a2a4507915a-22 for ; Thu, 24 Sep 2026 17:30:45 +0200 Received: from [40.93.194.41] (helo=SN4PR0501CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab54224-b4ea-0a2a45070019-285dc229b021-3 for ; Thu, 24 Sep 2026 17:30:45 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CHAPR03MB989225.namprd03.prod.outlook.com (2603:10b6:610:302::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 15:30:41 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Thu, 24 Sep 2026 15:30:41 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Mr4xwyBeq0Op3KetQWdOqIMBUFqh0K7MQW8EcBZ8QNvIKsnyAM3SAUr9qP4a43pAyNikf1dzQE7uM6IpCX3cci8YJOT7sdSwltsFAQj+PpaNmTmPxJo0dOfHglauS5dG/fTRhxEglGQac4ucmBshTpuZz0mIuITfRNTeM5WSaDdqwN+9cryXBBIrhNOqRSwp37o4uTELglKRHzjctJRpZOFGlXRmMBvW2sz278+Rbtk+YdywHhXz95G2AYwB5BtzOr5XRP7EJBhayZASLOacHsSwLg7FlVtzB3yMuM1586yOxzkOa0PxpURmHqwB3Jj/ayu2HAuR6Yz2Dq3PYL8GXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nnHiWMHoKc3fpqnzFPc2Jv5W3thflSOCUs3uyXfRWSU=; b=nqTBXswS5CDjx3UXm1MdWuMZhTe/BmkCf8qPdGo6pdw8opdKttUD0d3xi7O8IriAlv4Yh3q4HAOXwBRB/Y6EFMvQNOcxksEJ6y7KvdgHkaWBlJvEjSWRgzNg1C24L0MT1x80OMW740lZXIryBonWGlFlxuepj9O59aAdeMe1GdM0cNRqHa87eimrbr1Xgg0G7xgHSZcR4FWDFbJsEPBs8tLC63tuBQx901X1bB+AkpfnB6WvLm8KLZIhuSefT3Fq9fp+wYRSoeomuPu3ow982/Bhj4p0yX1ePKiW23kBUwl2qmjt4C52kCSnPNWLU/SmyQJbmtL6YQQmNoFZQwyErw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nnHiWMHoKc3fpqnzFPc2Jv5W3thflSOCUs3uyXfRWSU=; b=gaAeiRK1cV479cRKq5gZyhqOU4vPkrKqurAi29Ab9xfiu4tuEsrbx5KkNvsK6IhHxPu0uDMsvhPYSRFKg2mFVf6TJEamR2ELmYMQ7dcB5S9Hh7kgc4TdOieRE6Jc+Ga8c0c4P+KFp8AuvJFlKgsthDMegrg2g0CxVjcGEhJ1/HY= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4916487d-2492-4377-bdb3-415837b6a401@citrix.com> Date: Thu, 24 Sep 2026 16:30:37 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/hvm: Clamp Viridian features to known set To: Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Andrew Cooper , xen-devel@lists.xenproject.org References: <20260924110342.1045230-1-ross.lagerwall@citrix.com> <2f929826-3a32-405e-9bd9-0d47006e14f6@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <2f929826-3a32-405e-9bd9-0d47006e14f6@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0070.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2af::10) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|CHAPR03MB989225:EE_ X-MS-Office365-Filtering-Correlation-Id: 8eed7a0e-9b12-4555-9dc2-08df1a50caba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|4143699003|11063799006|56012099006|5023799004|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: yoB9i41lLZ3i1zUVC/8buoqc3jDuZzV0JMIPC2XHl8B7VBJ7SLu0InjprUaIZFYPtbR340Y7Ui7PPRxPGtbBW1nXcM2f1optd1yF9C8wqxjjbPOiGIgR91E9CToHeG0KdxoG+B2COdBvk3KxGkiUEwS04eAa9KcYVv6sknHQDfqDRYRarUCkldpCGpPQuz6zrQPtnB2FKUROCfD3aUeLHIlxQS4ec785CiBGSSpLhEbI0eiaNYZVSrHpz2X66LkGzW8HF6uhRDr9emfyCrV+UBpcP3+H8X8/z+CeloN0SjnXAN1hcanYW3+rJ5y05kpev2qDxQUSn/eGPaItu+pfgdVmMoKn/RzDlEQ3xk1p1Zp+k+G0L1ZU2NVy5b3BruNgqXCKvqvaHx0wHw+J/8zxfBNeenncJs9orf4g9RahfEhY3MccBGIKGbel0/XAVo8fsXvqQPdUBismHVPd8V3epMIaL5PFBVSifSq+PoniJ7Ty/xbpmrC2miLwfQM3sJ2b7nClmX6wzBYQJdim/rdJDlTF5U6j1j9pIcPvhfz6LhDRx754dV80ebqO+FCjrGmcre1oEOdSItidvsWf56TlmpspesMwmYSBT+CFRK8fAfK0kRvH9rk7Cs3LCwWJAZS2HWZHnr+5h5cBU4hKM87cEyoutL+b62CNr3PxB74KkEE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(4143699003)(11063799006)(56012099006)(5023799004)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M0tHZkVjR29wa05GdHpXa29zMGRLUXZFaStJOTVidTY1Ym5ZMVJPRGJrZEI4?= =?utf-8?B?aHZwSFdpWnNINlNDMkMvWHNNTlM2VXN2alh0MjloZjY2a2VMMThUZGtuSVJo?= =?utf-8?B?YTgyVE9LdTJ6V1pUZW5GUWRQWnNjZHlvbzEvTE1mVU9Tb3A0NHEvUkEwamVw?= =?utf-8?B?Kzk2SktIN2twT3JNVE9OWCs5bklmVk56Tk5FeUpVaXo5MU1mQ0FQamgrcWxN?= =?utf-8?B?YTBvZStVczVnTU53cnJMVHhaRjRDUlQ0TnZnYm8zWVNoMWVQT1JRTSt2OUxn?= =?utf-8?B?c0VHdVoyUEgzZ21jeU04M3dINjhVN205ZUx1amtHdjV2ZFFuc3BKUy9DTHA1?= =?utf-8?B?WFRtUi8veTRLcEpVclkzck9ScHlJNTc3V0JRYndJVWN2N3VOZi9adlV2cGRL?= =?utf-8?B?SG1KL2JDemlMcTI2STAwSE40WU1zVWFKOHYzTDJiVUtmVzh1MmhjWHZTejhJ?= =?utf-8?B?d2dnMnA5aTNuS25rbDNVSklGdDlaRWtjaWdidExKRHpsOGZUSk1PaUtiQlJB?= =?utf-8?B?cWxna04yN2twMjA4V3BqK0NFbUw1cE12TXhPVlBHQU03QTJTczU4VDd5NXRu?= =?utf-8?B?cmdoY21XRTZGMm02MDErZjhhN1F0K1doSkNOTWxMSnlmOU1yeDIzcWtDSnJw?= =?utf-8?B?WS9IaDVZL2FBTEY5MEtRdk5MVzh0eVB3czdoODBWbmpRTnBhR3FCZDlxTG9O?= =?utf-8?B?MUFlK0kwcGxhSzk1amVmcmRkeTBEOUxpOERCUTdmZFk3bEhyQXpSRWZSbGwy?= =?utf-8?B?ZGVFTnNEN1QwcEJYaW5tVndXV0tRRGxnUUFZbUtMbExkaG5yeEI5emlsQzJF?= =?utf-8?B?cDNVVjZxVjFDSGdIVjd0c0dWL3p4U2VleW5SenNXUFE3cnpMbHhaQVRsOU53?= =?utf-8?B?V2JvNVY0Y0puK3g4eG1YaUgyWGtzU0JUQjVlNFd1K1hNcTZtZEtwdlNaeG5r?= =?utf-8?B?ZXY0NGMzUGs1U0FCd1YyMG03SjlobVR6bG40SmwycVBQSi9ka1VZaTZxV2h5?= =?utf-8?B?VXUyd0RkZ3FBdWFUcVF3UEsyZ2VDTFBSUkNabURlT0F0RWR4d3l2aWNVV3NS?= =?utf-8?B?YkVlblJpVHRRTkVkMEhGYzBpQ2srWDl2UGJ1d0lvZk9QTjdTZG04THhMMlNt?= =?utf-8?B?cmIwdEUrOEFMMlBuMG5OWi9ZUjR5VHdTMWQ0amRPWFFNK2hvTGQwQXlLMUNt?= =?utf-8?B?WnpqVXhKN1psVTlHOWR1TmNPWEt1bnE3L1VueHJKeFB2RG42RXVjRXc2RFl5?= =?utf-8?B?ekRSYUpvQ0VHeVB1ZThwWUMyZ1FpbWkvVjc3MlBiSUozMVRVVndFTzlvR2JX?= =?utf-8?B?QnJMazFFaXIrOVRqUFI5ZTlTb2x3OXA0MWNHbUpjN1R0YVRPaWFDcjBqWFVx?= =?utf-8?B?UHBla2ZFNTVZaWNpN0g3dDNyU0l2anBHbVJrNTNqTHY5em9mZk9QQ1MwQXhx?= =?utf-8?B?L0FtVG4ybFgzbEk4Q1pOV1E0K1ZyTE1hQ2JYcHpreXFJMTRkMUt1VTU1ZVhQ?= =?utf-8?B?TUEyVGxubi9odFdONFl0OFYvQVBzN0FOa25abkRyWHRrM3J5eVM4UmFIc3Ju?= =?utf-8?B?aENyOENsbW5GTHFGSTQ3UkQ5NHhhYmFGVUhYQU9OV1Nuc0xjTVV2YmFyNVlt?= =?utf-8?B?Z00wSzJKRFpYbXh2S1BMN1NRYTRSZmE5dW5GZmR3enAveFVqNktaSVJkVkR1?= =?utf-8?B?U05DeWRiUVNhc2NKWmhmb29uTkwwcDNsdVpyNWxlMkxVTnBGQzZ2cm0yekxO?= =?utf-8?B?VDdvQnU4WFdBTXdNQVYwR1VuVlVlQzVpZm55NGZFNEFWejQ5cWtPcUh4TjhG?= =?utf-8?B?NFdhV2tXdGZOcUp1MTZqR094Y1pwS2pzbGRRV3pYODI0THY5K1N5Z3Y2RDAy?= =?utf-8?B?MVlZSE9WMTczQ1R5WnNzSDUzZmd4NUpma0VIOW5JUjhNMm1ZeWg3L0o0bmpu?= =?utf-8?B?bmJSeEN3T08vSHMxdFFFN3hmVHQ3TXpwUEw1cVVMOCs5OHprS0pzNGl5Y25j?= =?utf-8?B?V0ZFeVJwZVpmcXpWZWZJaVVlcUR0VlI1cHkxMW9uNlRobnptbnVaMFdmY1BN?= =?utf-8?B?aDNtRkx0a0tNMEdUT1UzeE9ZNGl0cDNDWGNyVWZaZmdkVjAyWXhPbW51bnY4?= =?utf-8?B?WUFacGxRNUljR3U3ZlJlb3dvODl1bVhGNjlsKys1eVRqbE0rZTY3ZGtGT1pN?= =?utf-8?B?RElVMVZMaDlmd1F5VXBZTkhVUGI2UHFZeHBkQUVFQUlxQkt1MlVuZEpYUUZ1?= =?utf-8?B?MW9RbDQ4Q1FGSzJPc3pHa2REbnR1RnpEOWVUdUMwbU14bUZtUGN1NThLZXd2?= =?utf-8?B?RFM0N3Q1U0phT0xROEpRNTRhK3RLVzRKems3TjcvMUZaTFJmeEhMUkdHSmFs?= =?utf-8?Q?Egrrfd2HD+vwapes=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8eed7a0e-9b12-4555-9dc2-08df1a50caba X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 15:30:41.3094 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: usrcF7yv514qYsP+TTqGiGuKdHj7DLnmAi47IgTYgD962v/uF2vl9jaY4c1ni7R/4g3AC32rY3WWu+YhC/QQ0oBrL/6pJyWDlD9OR2zR654= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CHAPR03MB989225 X-purgate-ID: tlsNG-ef75cf/1790263845-3C411AE4-6F765D15/0/0 X-purgate-type: clean X-purgate-size: 1216 On 9/24/26 2:08 PM, Jan Beulich wrote: > On 24.09.2026 14:56, Ross Lagerwall wrote: >> On 9/24/26 12:20 PM, Andrew Cooper wrote: >>> On 24/09/2026 12:03 pm, Ross Lagerwall wrote: >>>> Instead of returning EINVAL on an unknown feature bit, clamp to the >>>> known feature set. >>> >>> Sorry, but no. >>> >>> This is equivalent to saying "I've got a VM using AVX512" and Xen saying >>> "ok, I'll ignore that safety check and let you run on non-AVX512 capable >>> hardware". >>> >>> Requesting a feature that Xen doesn't know about is a hard error. >>> Truncating features out like this will cause a guest using those >>> features to malfunction. >>> >>> It is a bug that this was expressed as an HVM Param in the first place. >>> It should be part of CPU Policy, and it's on a TODO list. >> >> But isn't this the same thing the CPU Policy code does? In >> recalculate_cpuid_policy(), it silently clamps the toolstack's choices to the >> max featureset. > > Which is behavior that, if I'm not mistaken, is supposed to go away. Such > requests are intended to instead fail, down the road. OK, if that is undesirable behaviour and going to change in future I'll retract this patch. Ross From xen-devel-bounces@lists.xenproject.org Thu Sep 24 15:37:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 15:37:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432561.1653773 (Exim 4.92) (envelope-from ) id 1x9lW8-0006z3-Ly; Thu, 24 Sep 2026 15:37:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432561.1653773; Thu, 24 Sep 2026 15:37:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lW8-0006yw-JB; Thu, 24 Sep 2026 15:37:48 +0000 Received: by outflank-mailman (input) for mailman id 1432561; Thu, 24 Sep 2026 15:37:47 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lW7-0006yp-2y for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:37:47 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9lW6-00Gw6m-G5 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 17:37:46 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab543c2-e002-0a2a0a5209dd-0a2a45079e7c-38 for ; Thu, 24 Sep 2026 17:37:46 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab543ca-b4ea-0a2a45070019-4a7de18dc9b3-3 for ; Thu, 24 Sep 2026 17:37:46 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e620fa473so13744585e9.1 for ; Thu, 24 Sep 2026 08:37:46 -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-49fe5e07bdcsm69481525e9.15.2026.09.24.08.37.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2026 08:37:44 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790264266; x=1790869066; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=21Sx5Z8bEuao/hLpUOAyuGmrfY+uSBEqP2/z7y7vJxU=; b=WfBOFxnvSbeyEk5iR2eRdLuLlGoewLrSjF12rOmzsEdpj8iiF9/x7iWo6Z3ZBfjrov yIYOmFau67YT3ApfUHX7RWYU9sHt9nrPLM9XLR1jjawwvzqk9iecFTOfoqiQrDTIWVjq dovvvrqywQ7VAQdGzEFYZHGkXOQsqOte1Lr2vLqRgCXaDtCFk/yeufiAxAhq+LulolxP wnwmDATswAAs7ctqg+qv7tLcVmDrxiES+lbxI0MG7sWC9cMOHen334+6wbm0DoRw9Cpj gMv+u2VvFiqJ1ogYZl59WWq4BDe6yiCDjnueV4YSYqoYEWvSc4fHvbr3uX28siY5dQYA X8+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790264266; x=1790869066; h=content-transfer-encoding:content-type: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:content-type; bh=21Sx5Z8bEuao/hLpUOAyuGmrfY+uSBEqP2/z7y7vJxU=; b=i8FxAiG8fkcGR1HQhwUCSBTavlUpewshM3mLTvbXrdO6MGC2I2l4JfJEZkmyUn/TIs 19YgeAFaZfoOvcLbKfgJ3MVoxPqMvrH5RaMpkAoav2iAtS5AzOR38ttrRAhteiZjw3Og QUjHeZQyp7X0silkP5aUq+j1u/NBz8xbbdIAN9p8AwM+z5j+Tn3rilJ9z/cUNP9ogvXa M8E5vbctDFS1S9vuBA0CbnAZzaewlQ4QTMeypJcu1RX9FAZTw/kd64g2FeeDm8pLVi8P Cxfn4FPqgJbLs/ReHfxgASwchs4TfG21etWuqpjICQDDvo//Cqw/dK+x1O93eyQfnkzX 7LEw== X-Forwarded-Encrypted: i=1; AKwUvBw04kxF9lyw1ax3hPTQxm0oPysHCS14IA6zSGY/CoW8pgvaYSZkg4o5+Q42edO113uJcBQdrZJwhM8=@lists.xenproject.org X-Gm-Message-State: AFuF++keqp6Vm/M32PRf5eEw3TmPSmdPsfEt56Fu/7slUaTZwROhT4Ht n7IiPkj4jxudppW/YUwu/yrd/+iONhtuulCUzf9goo/L2ioXy9b8znj5vUok75G8GQ== X-Gm-Gg: AYBFou28Z3aYhwItn5TiWmSCACjo25Af7EUYlvXfRjL57Xyd3VXW8bYcrkACml39ZdQ JDMJVisScUK0u4qeZwlEEP01dvRi7arfr+NyR4h0r9HpihxIVaj7jHCYtSUm9yUcL38PlFmi5df VuzBrxPmppdermHugOrsjAo6DkC8Tilp/5DxIvMcZb2TuBlV66aHUTqWS5XK16pvaU+xSK8TRDM 1uw8ilR19F8HhHsaf7PplfDlNa5eBVNX5e52gpXUgjmnHIYLDtZNR5JIUUbFZlm7tdqhSEKmYZL 07z4KpweMqmCL91FWgoifPn85gAVlcLp3aWQnTy9tqOATd7eqYVsxYLqJGs31GL8kz7jHz++OIa kxipSKHgdnPefavb1Jo0ANQ1ADLzG7XyrJ2iPV0j07X0D6zQZC0lM9MN8NFlo3mVWf4XwMS8EPe gFL7rU/CRMUwuM7t3xGkUZ56lWXTl1HfTr1/inyXx3GdnIY8R5rkxb/mMBc4iWJcyESD4zkvuT+ yeJ1+zjW+5Uhym6ivng148DtB4Hw7WRiQ7rNzjXX9Q247a9UuuvZP9gdMUts3s= X-Received: by 2002:a05:600c:4fcc:b0:49f:df99:ff1a with SMTP id 5b1f17b1804b1-49fe66f344dmr53716345e9.17.1790264265707; Thu, 24 Sep 2026 08:37:45 -0700 (PDT) Message-ID: Date: Thu, 24 Sep 2026 17:37:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] vvmx: Handle INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL properly To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1790088652.8631fc262581453bbf619ec5b2062170.1a0c99927a900072c4@vates.tech> 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: <1790088652.8631fc262581453bbf619ec5b2062170.1a0c99927a900072c4@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-ef75cf/1790264266-37AD0AE4-377F9044/0/0 X-purgate-type: clean X-purgate-size: 513 On 22.09.2026 16:50, Teddy Astie wrote: > The feature is already advertised in NVPID_CAP_BITS, yet the handling > in nvmx_handle_invvpid() was missing. > > Signed-off-by: Teddy Astie Reviewed-by: Jan Beulich > Fixes: 9ccf55307868 ("nVMX: virutalize VPID capability to nested VMM") I think it's its immediate successor, aa1b9dfdff9c ("nEPT: Expose EPT & VPID capablities to L1 VMM"). Without NVPID_CAP_BITS defined / used, there's no bug there. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 24 15:50:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 15:50:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432579.1653782 (Exim 4.92) (envelope-from ) id 1x9lic-0001TZ-QZ; Thu, 24 Sep 2026 15:50:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432579.1653782; Thu, 24 Sep 2026 15:50: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 1x9lic-0001TS-Ni; Thu, 24 Sep 2026 15:50:42 +0000 Received: by outflank-mailman (input) for mailman id 1432579; Thu, 24 Sep 2026 15:50:41 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lib-0001TM-35 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:50:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9lia-005oqL-G8 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 17:50:40 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab546cc-8faa-0a2a0a5109dd-0a2a4506e544-4 for ; Thu, 24 Sep 2026 17:50:40 +0200 Received: from [40.93.195.61] (helo=SN4PR2101CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab546ce-195a-0a2a45060019-285dc33deb71-3 for ; Thu, 24 Sep 2026 17:50:40 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by BN5PR03MB8054.namprd03.prod.outlook.com (2603:10b6:408:2ac::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 15:50:37 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0428.015; Thu, 24 Sep 2026 15:50:37 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yFVC4DQMltpsRL4PzN6oDDwsXU4OIeWyg8kYPPKA+ETbJyunoNpZjnPmkPC2pkVwa+8cuEcL6OgvM29axdkA7FBGV7YGyNU3rW13WX278of/LtLNiF/ETjXXUeYoR6B6mB0pTRE/uMlk1kG1Fh8YZ8Yff/8zoXDi550lbCT6XdIKjiYOrr0M5OfArHmZ2LTtkeTjtWfuGO2gwktYAt5ItURZ4rGYT5gB3tGEJAlPqjg0yLZsrdc077pcmMzOeCXngZ+Fr2gBG4hKsla6q3GhUziBKEUF+qIlAx/jo3H/KdsdEZBiS+Z0f0O9HM9Zh0RmERY2E7HrkgJrRRc/OP78aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bnzNbHNp3VyIXb7hkxTft/FfzXATib4lEj8daziz1rw=; b=hjVHE9Qkpui9bI3cajPD6oTQ7jDpC/bb+kxDh2XOhpR52YfKx6vzkLNVBxZ0Fy69PXQ8L+u3nnB6T7BRtwseKdDzxcEbsSZ3xzHUhWzzZeKLQ+jiFI+SmzCtOXY1ho4abmyZ1mrV2thWyH1Peu60l0SDgfMb3jS9mU20EJySn0HCUgfs4fUUOacP2ppg3jgu8rbwny8JzMfglXv020Qzrall5dNIsP775WEeQK39yTw7Q/6gNqEGXq60xOvTWhWNF1Ot9S7Jjd183aEzIbcAJ8+tEZsrNihref8uVUN+pzcdPVRv132GD5mCylpzXlMrbOrLD8Z/ylo2JNiVEmu+IA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bnzNbHNp3VyIXb7hkxTft/FfzXATib4lEj8daziz1rw=; b=W6EQyjOP65lFi7+rUhDBV7mbVep+Orf6NOK8v5FDyxBY1Aw8wiffp0S1mZ77arGC5C2rJtrpK2+YAmwbwkDkpiUKY5b5MATnLqCRhIkvdD3t5sdJruhxYfHrSQMSm9nJO9EeOSgmqCzbUA4KDAFU8xK7KLl0/ArE4fymIEre1LM= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <70bd67f8-fbe2-44e2-a050-b6065ba2de7f@citrix.com> Date: Thu, 24 Sep 2026 16:50:33 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Save L2's CR4 on #VMEXIT, not Xen's To: Jan Beulich , Lin Liu Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <38c41bfb-48c6-4408-8da1-2b7d730a6c9e@citrix.com> <711e6af5-beca-4b71-a2cb-75cb1ed93689@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <711e6af5-beca-4b71-a2cb-75cb1ed93689@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0098.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:191::13) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|BN5PR03MB8054:EE_ X-MS-Office365-Filtering-Correlation-Id: 6b9f0825-0bfe-46e2-5193-08df1a539397 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|11063799006|56012099006|4143699003|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 4dKF3NWiKJNO+t4lOIr0MgtXMHzWNTFNXIw2fkzSdK3LTsoo2vJllzFTs2z0XAJXVqSH1+FM8h1qNS26HaTxXBy/FpWpDlDw6x2LG1oxUlUQ6qUdJ4lPrBipGrmBBOt07W/2qgoZ2nR9B0B45o+keAiyjjZImXfKAIFXvuGZyEofRLjRiy+E3eNe02boqnc3A8Z33B4s+c9RHwgTOEwAsIO1wznq4YkqX/MYHU/4a8Refra+dGX47n3tGytKR2KWlExBXwG4xejYraw6urUxOr7G+dpfvVT3XWd0UItSIMnS+wb+FT1ZkyMyRJsuMPoJgY6xrVKMlZdqAR/NHe1L6xSccs8vKUhbUofAivB84MwBHj3Q86GkxcFn1vEH5bDy2RDZCR/4tzIfNh44iKP5rt7bmU4TwkfF7Eknb6dyfNUVsxXmg1b1HT1SYlJsle62WbgAbOhvDV4T8M/ui8gkaIpyF470m5x+wH0QKT5tVfp6bJpL0nkveGii+a1xU0Wpt3cpL81U7qTUi37XkLuyl0aY+izM6KpJ18/MY4BtJdM4ZGNlrgUD5yc9yhopsBL3mkwzmEPnz1ECiAoCsFXA2wJX4Ih4YoOO37l97i3OxdgxNfvuAgDmjf0DoAmEqrMEoA3CgdT8O0m9Mdf29GkgC5JSZosJl1h3/RMHMdWh1SI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(11063799006)(56012099006)(4143699003)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aVptQ1ZSNE8xZklQNCtKMFZTNGJiV3d3OW95VGNILzk3UnVmYllxcU9RNkpQ?= =?utf-8?B?azlNZ0pRVlVyWXgzV3FJb1piQURmVUxsQ0d3RDljWjRkM1R6QU1vVTk5RUln?= =?utf-8?B?WGY5c0NCVTc3UWVTUU5tUzBCRHNYZjkvY2lvdHhvTGlpM2ErMDFTekZKT2RU?= =?utf-8?B?SFVESHYxOHNWOG1zdG9XZXVjZE5zbXJVMFFSUUpsZFdVajZ5cEQ5S3JGTzNP?= =?utf-8?B?K0hPMC9pVzJPZnRKTnlMUVNrZ3czbnhzSG5rRzVIUHowbEo1USt6ZDRPei9k?= =?utf-8?B?TWNOM1kwampUdXBsWStyZHRZQlQvWnA5TEZQeVhVcGhUbC9ZTjJka0ZBR2ZC?= =?utf-8?B?bTByMHdEelRCcEtiVlVmMHlOa1grdDUyc1VwS1kwVm1ZaFZwdGVCcCtCKzFu?= =?utf-8?B?eDN4b3crU1hPV3k0cEFkZDZ3Qkx1WENTa245KzFUcFUzak1WOTlpaXZwb2RD?= =?utf-8?B?M2IrSjJyVXJZWDl6YVh5eFpVbDBIOFk0bWxCNWRmZlJneGNaR09IcE5pK3h1?= =?utf-8?B?NlpNWkhIYVBFbTVHSFcyVVRIeXBFUnBQK0MvM3U0YmNpTVRKcDhvdlduLzVT?= =?utf-8?B?NWs2dWxaQW9SZ0s1VGI4RXh4cWZKVUFDdWgxZW5vTHZWVVdacHBJdC9CWXBy?= =?utf-8?B?aitRVFpPQlVYRjYzTDZpa0k2MUZ0K0JHMWFDMFZrZmpVYk5JWjhRc1c2L0N1?= =?utf-8?B?aSt6akczSUJ4bTMzTUVvRkp4RTY1Wml5bS82OFJ2MEtaK2FGS0lFQ1FodDZ1?= =?utf-8?B?RWhBRnJPMWtvQW5oSDRlaEVsdEtGM0VmRHdJZDAyZzk2V21GVVI3cnFUN2xs?= =?utf-8?B?L0lJRmNoNlBPaHBzY2VGS2d5Y05oVk9oNEM0VXF6T3J2NXVXa0FzMTlpNU80?= =?utf-8?B?eHh3WWZmaGRiTE9Xa0ZWQ21uc2lrTDkzSEtzUWNML3p2OFBJVkY0Y1plUmp3?= =?utf-8?B?NE96UlNnT25SR3dJMEpCTFpncjU3bmFCdTVCWjI0K1FDbWJYYjQ1NHhXYWdO?= =?utf-8?B?T1FIR2pjWWVSYU5ERUdUS21KVit6MGY2TlBSQVpQSVBPOURIWDI2K0kzSDJZ?= =?utf-8?B?UzdXNEZseWdaT2Vha1cyNzNXRTBCeFMwZHVYL3A2WG1ZeUxCUkl4Ymw5VlM4?= =?utf-8?B?eFhnbU4ydk95aTlyc3EzQVNWUldBR1hVSW5yT1NlSXZCWFR2UTcvU2pMK2Iv?= =?utf-8?B?clQwcDJtbXJiTEQwYkJ2L3ZNWFR0VjRSOTJ6d28vQ2JJYWVBT0Nqb3ZqSmlC?= =?utf-8?B?d3UzSmdZcnN0aWNVS1p0Y0VrcHlHb0tGb3lRQVVvK0hCZzdUek42ZFJUOGpR?= =?utf-8?B?MFRtNGRVaEFCQURibFNVcjdUT21NZGlOdTlENzBPV2VDU3VlWVUzc0xNdG8w?= =?utf-8?B?ei92VElIcElZczltLy9YVXlxcFVTcTZDRk8wV2hTYU81V3Fnc3VLMWlsdFVk?= =?utf-8?B?WldXaGx1bUkzT3J6S3A5U0JWY05XeFR1S1JxcGZIb1hiSzhzWURUWmt0MzYz?= =?utf-8?B?Q29vZy96RnVQdGlYTzJVZHM2eDE3Szg0a3FwcWRGZi9aMDUyY0VSb0hmZkti?= =?utf-8?B?R1JaY1VpcFYzV3lIT3NEWnlHOW1EazZtN1kxV0pjN3lUOGRQRjk1YkxxbTN4?= =?utf-8?B?OTZCZDZkeVo3ZHJiOUtHS2JlNlk3Sk1DZmVjMVI2dzk5WXdnR3Z0ZDNBYVlC?= =?utf-8?B?bVc0a1BmTXM1WTIyWGFyY2xhTUdVSldOZ2JjSGpuL0NuaTUxeFlqZTU1alpy?= =?utf-8?B?K2V3bmZiUVlmR2FrdUVReEpKdHdqZVVZQmhTOGhmZnV4MUZKeHczcTA2MlZm?= =?utf-8?B?cDJKOVJQWjNrMG5yenRpQWUvaUdXQVplYlFBQjNDMDQyaUtuVTllem1uTmpS?= =?utf-8?B?V1JPLzFzUEhLa1pXNmoxc3RGajJOUXowcWErMHhmVUhpVWd2N2lnaEx1NHdx?= =?utf-8?B?VHo0MytOR2hRUVFMVXRTREFNMHBwckw0SjVGVWVwaE9jSzhKR1FWSmFxSlhY?= =?utf-8?B?Q0t6Q0ExZnE2U2ZDcnBpL3NuZWh0ajhhUy8yaWNHRC9PcU5obzBRVWZtMERy?= =?utf-8?B?dUJvdmNHMG5UVHYwTnVWWnlKb3lkaEpUYkl2YU0wTmdaY2xMS2RmNjFCZWJp?= =?utf-8?B?MGFGVlVsYitPaUNGb292YUpadzNGTkFGZ1J4Tm1uazRTektOUHdvUmc5bkl4?= =?utf-8?B?K1dZN05mS296MWZiNXZCMnJPby9jWGRQL3BDdkxmeW9LbjF6dnd3OTZIYTdo?= =?utf-8?B?QStRZkdSemRkaDU3SjhkUXd1MFNZUGxnTFV3OHJTWitjVEFWdTY1dkpBcG9T?= =?utf-8?B?d0FiWndDazRld3U5Sjgwbjlvb1YzSlEzeDV0SzZWUWZNWnN2ZHdtSHlmQUw2?= =?utf-8?Q?NR6u0PUgL7uofOiw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b9f0825-0bfe-46e2-5193-08df1a539397 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 15:50:37.2188 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HcYngFRgkooV9o6iiT21Uu0pR4fov4L4gnVysAvZUpeo4LHm59vjJgCinLRJ7qiy8ooP04awEva1oZlDV4MbY4IB7EcaevR+V6WrBrKV9JI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR03MB8054 X-purgate-ID: tlsNG-16d1c6/1790265040-FD00977B-EB648B20/0/0 X-purgate-type: clean X-purgate-size: 1992 On 9/24/26 4:01 PM, Jan Beulich wrote: > On 23.09.2026 13:16, Ross Lagerwall wrote: >> On 9/23/26 10:51 AM, Lin Liu wrote: >>> Xen leaks the host's CR4 bits to L1. >>> >>> nsvm_vmcb_prepare4vmrun() constructs the shadow VMCB's CR4 via >>> hvm_set_cr4(), and svm_update_guest_cr() ORs in HVM_CR4_HOST_MASK. >>> nsvm_vmcb_prepare4vmexit() then copies CR4 back out of the shadow VMCB >>> instead of the value kept in v->arch.hvm.guest_cr[4], so L1 reads back >>> Xen's bits - under HAP, CR4.MCE. >>> >>> Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") >>> Assisted-by: Claude:claude-opus-5 >>> Signed-off-by: Lin Liu >>> --- >>> xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c >>> index a8b15d6eae..8d99b0affc 100644 >>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >>> @@ -1082,7 +1082,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>> ns_vmcb->_efer = n2vmcb->_efer; >>> >>> /* CRn */ >>> - ns_vmcb->_cr4 = n2vmcb->_cr4; >>> + ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4]; >>> ns_vmcb->_cr0 = n2vmcb->_cr0; >>> >>> /* DRn */ >> >> Reviewed-by: Ross Lagerwall >> >> Did you consider addressing similar issues with the other state copied from >> n2vmcb as well? i.e. I think something similar would apply to CR0, EFER, etc. > > But (assuming the above code change is indeed correct) wouldn't we better deal > with CR0 then right away, rather that leaving things even visually inconsistent? That's up to the maintainers to decide, though given the state of the Nested SVM code at the moment IMO it is fine to take valid improvements and make some forward progress even if they don't address all the related issues at once. Ross From xen-devel-bounces@lists.xenproject.org Thu Sep 24 15:59:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 15:59:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432620.1653791 (Exim 4.92) (envelope-from ) id 1x9lqp-0002RR-J9; Thu, 24 Sep 2026 15:59:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432620.1653791; Thu, 24 Sep 2026 15:59:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lqp-0002RK-GZ; Thu, 24 Sep 2026 15:59:11 +0000 Received: by outflank-mailman (input) for mailman id 1432620; Thu, 24 Sep 2026 15:59:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lqo-0002RE-11 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 15:59:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9lqn-0060Ya-EA for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 17:59:09 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab548c3-8faa-0a2a0a5109dd-0a2a4507eae0-18 for ; Thu, 24 Sep 2026 17:59:09 +0200 Received: from [52.101.85.10] (helo=BYAPR05CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab548cb-b4ea-0a2a45070019-3465550ab369-3 for ; Thu, 24 Sep 2026 17:59:08 +0200 Received: from BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) by CH1PR12MB9718.namprd12.prod.outlook.com (2603:10b6:610:2b2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 15:59:00 +0000 Received: from BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740]) by BY5PR12MB4999.namprd12.prod.outlook.com ([fe80::a890:d230:e0a8:6740%3]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 15:59:00 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-Id:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XK/2eedU0ipgPn0Ce+GMnCUZQZYpFH6HXDVuv9GRmNEte3k0EfR5A1dITeveOGsjQkie/MpoGKv6pe3wOQlUf1ooGZd9ZUqPqcdKgwhuxgX24ssKmw5f0ROP10EACVT2PVty9XYVmc/aVH76V/XICLRdxaqUwEJ3HGxqWh5BR+L8yj7yu31r78/7OxJqe/sPVkyGyaX30oY6JUKyv5MQWoWD5O3wmYYq+W+B5Y2DL6970Es8EAZaHYkwEAANVnemVlA8P+a13hueHWY2FLDykgGvDcVWlCkOTA4QK2TljiY3r676f0keeGktCXU6vtGFtFWnC0y6vTP0wZKEJb485w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z6hdd+WxYwINwdvB8aBG2UPN/VWbPUZ4KqepmVC0zWE=; b=wqkGUi9QixA0rG06tJaMWMX3syGzZlPh/GuD1mdXOAwvCLgYGteie35wEvJIw2efiA1gFhSZzrv0hN4PALKNpfqQhXFIeVfuZLcxCe1KM+nT/YLTf13g3C/RBSqWQYjip12QWxdRHetzN+4fKzIEGHgomJ6v8EeNRAZZBnQ7tB2m3jbuata69wCZhOtSSjoHrgpfxAVinBdnLZkyGuoRMDocfXVLvEXib+7gMl5Woyl7aTGMt7Oiz1cBpIoFQq1AEXcY8AcTeqAQPU9pr6k4NE87mYpDezZbOShV5Dk4M1ikB8QevKsmbfiLgFI+hJkua+d8cbCpZWbBVSE/tdhAwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z6hdd+WxYwINwdvB8aBG2UPN/VWbPUZ4KqepmVC0zWE=; b=z+teFcFkSGUN+lX39SKoYcoK2M6H1uT/yY5mn0rXO9hGNu3SsRjWDXh7PsmMQrAo+Oeg771OfqykFISBm6ZZV6gf757J12Z70veYXF65u5iPl6DflnbpxTf3D+L1ai3zrMuM5+nE8smwEJQ2JsdHmaS9+HgSAqDtzt2TaJfbeYs= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 24 Sep 2026 17:58:55 +0200 Message-Id: Cc: "Stefano Stabellini" , "Julien Grall" , "Bertrand Marquis" , "Michal Orzel" , "Volodymyr Babchuk" , "Andrew Cooper" , "Anthony PERARD" , "Jan Beulich" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Timothy Pearson" , "Alistair Francis" , "Connor Davis" , "Oleksii Kurochko" , "Teddy Astie" , "Grygorii Strashko" Subject: Re: [PATCH] xen: Consolidate linker script setup data From: "Alejandro Vallejo" To: "Jason Andryuk" , X-Mailer: aerc 0.17.0 References: <20260923161935.24429-1-jason.andryuk@amd.com> In-Reply-To: <20260923161935.24429-1-jason.andryuk@amd.com> X-ClientProxiedBy: MA4P292CA0012.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::9) To BY5PR12MB4999.namprd12.prod.outlook.com (2603:10b6:a03:1da::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY5PR12MB4999:EE_|CH1PR12MB9718:EE_ X-MS-Office365-Filtering-Correlation-Id: f19e7abc-3805-4d5c-3e62-08df1a54bf8b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|7416014|376014|10067099003|11063799006|56012099006|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: 4u4vukta/WWQOwaDCD9i3tTKN4HRTyOjgCkQmrcmnW813b8dGoZ+Bmj1s+6NBLJ08RgYXOZiQOolWWxLHePhBzFBEttTjT9RCnxHT+hMwfVMu6qf7WUH2ai9IcPWbRVDqoMMYWCfsmvJmFA/WyREMyIGQfqS9+en2Nf4WMRbbeZRMHAY52I1FvFv8pnYzS3HGdPmH3dU8HoRGNW+r31HbePyQTUBTII3pxDX6CHYRVxAJ3xgcAu8OqPyFxGwfqFrN9FBqDI3rSYKDulVqSvl+R7ctPBZ9zBO8UwgNNj1F2kC+GioaKGQ4DEyO7VCcQwFtAAB8Af31dzSABKvEecHKJKaAgwfCLStunXDodbtMaVMk3YbpAc6k9pIN5weBhY/XU07jnBnEPS8Op9UC9wEzKeZgA2+jD6zneBJXma7doxVbS5BgLfIxVr3sA3UJgQNJC7lt/OgHtP1VHq42841Sd6jTlllhTGmzHE5vLnZhGhs6bIC0+4tEUtT03FvcJlAeG6n89dVPxiJVKEihfPYW7/woA8CrUf98kkY1C2qgZjtjpDe3XATbTDxWckaTlBE3qMRTlwXeF6evC6GRd1g/yeio+UmtdjF9stFCVJDHd9o8EmyRLDID+QRnhkbe6sd0ZtyvEbnAJCm1ZNnHB/LXCfPbr3ure2Q6qWzyPOtnhk= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB4999.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(7416014)(376014)(10067099003)(11063799006)(56012099006)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S3ZScmNsNnh0WXdBdmMzTWh4MFhwcmt5aCs0VTNBQWxGTXNncmcyR3BGMkU5?= =?utf-8?B?cDlhVWw4SlY0TGxjaXhSQ2Y4ZTZnd3ZJNHphNm0zNUl5THdIaUZZYXkydVFU?= =?utf-8?B?TEdkd0NBRzVmSm5hZ2NsL2tCZWVFRi9FU2ZYZXhyUmtGS1dNaXJrb3dmWmdQ?= =?utf-8?B?amsweTB4TzgyUWxlalEzaWtDditIVExRZXZwa20zYW85T21IVFkzNkxwbGxK?= =?utf-8?B?clBZKzlNNk9LQ0RDbFdFNXAxdDFML0xXc2I2bUtxdENWT05idldJS2JleHky?= =?utf-8?B?R0dMdlpDa2JhUEoySWZ4QUs0WldobmxOQ0c0SlZ0ak43cVJJNUMyR3I3UEcw?= =?utf-8?B?NjJhVTArazVKdG9kbkpxNEIwM1ZyMnJHak91UkhvMEdMVmRpaGlyakdiTXlE?= =?utf-8?B?dG5PMGdSVWxlU3pEcXlva1RtZ0tETXJtRVA4NGU0eFptcmdyU3lYaHMxUDJ5?= =?utf-8?B?SEJIRGtEanVJRnMxeGs5YUNzcTVQR25BamxYUTVRVTlSVHRxdnp1ck5aS0RK?= =?utf-8?B?MnBJSWRseHloWUk2NG1lM1EvSWZaTEpRTVZFRGZXQlh4V0lZcEFUNUJRTHBT?= =?utf-8?B?YVJqLzY5NXNtL3QxallkS3BmL09uZUJocXJWaStsR1dhd0tiUkRxZDVoMjV2?= =?utf-8?B?UitxNE5kS3BUcHkwenU2RE1LVjZaQUV3WWRac0loNnRyaEE5MWREdjBxcGg3?= =?utf-8?B?N0M0dHRTcEpVam1TVEtIbHI3ajhyTU1ZeWNqWkd1Z0YwbEpLWEo2VExFUW5m?= =?utf-8?B?dnpIc0NtaU95dXlHdlk4ZEFlZzMxVHZoMEJRODJIaWltN0p4QzdZV0dZaFZo?= =?utf-8?B?SzY5alVhVU5ocE1RazE4MWY2cHdYa0I3NnRxY3Z4Z1F1MEZyQmRienBoWGRU?= =?utf-8?B?WmVHZ1ZIblY2WmhWcmZ0VHVwMVdOODlKUGRjMDR6VVRUZDBDY0JPMVVlWWtl?= =?utf-8?B?dmVxSVdsUUwxUXVTdUJ1Q05IYVZxWjZwL2VLU29FdExPZkxrQytKWEM0OGRF?= =?utf-8?B?YVZpQUEvQXJCb1FRcDNFRFVqbTVTU2EyOEc0ZmZFUE5rSllIWFoxSlFWNExE?= =?utf-8?B?NWFROElBVTRka1ZRK3lLZktUM2M3OUtYaE1PTTU4Zlh6cjhzWVRSbG5uZFQ4?= =?utf-8?B?RStzdjh3WUhjalZ0eENIdXIwM1IwZklkbE5CeFo1cytNOHNLYng2NnU4TEov?= =?utf-8?B?eWJ1OVpwVnR3NUd3TmZLNTMxNk5OT2tvVE1qcTZCTmpYK0xJTjhiNUFpZ3Ew?= =?utf-8?B?bjNvVkpOV1dCclFuSjJSTkxyQXNiOHZSZmdTOE55Vm5vak51NVZFdThPUFVJ?= =?utf-8?B?QTBtWERRL0dBeXNrK0M5K0V1WFloZ1FZQmlFMHowNGxlYm5MSFROeDhxWEI4?= =?utf-8?B?SWc0Q2IwT0NQeUxOSTZkUXhaajV5ZGRIaGFNd2w3NWZWZEdqRStTQks1SFpG?= =?utf-8?B?aTJLWVlIcVpVdWt4MVRSTHRQd0tPR3laWUxiWlVhSUlyS0w2SDhpQ014cXF4?= =?utf-8?B?akNaWVQzSkZlamtVTktMR2p6cnVXNy95dVNxem5PUW15SjRGK3QwWXM3K2d0?= =?utf-8?B?SWpLTkEwTkk3N2FSNzVGRHYzcnorS3d2V29peW9vSXI5UDIxWExxWlQ5OTdo?= =?utf-8?B?cHVUYWYvbmZCNFE2NEQ3dlExT0RnMHd0TStBU01hdllFR0tqcDdtWmkrUFhO?= =?utf-8?B?KzFmdkl2b1JkRUwwRVBkRURwQTJ3NjFGd2xON2Zyb0RQVkdwVXlHUmVxMnBK?= =?utf-8?B?NUoyS2ViYVVoYW53TzNNK2FXeEFHS0NZZnQybTlicXZEa3VQV1E0bVhSK0hs?= =?utf-8?B?R1RVRlFFeHF0TWhELzNaQlVjbXp6bnRUMEpTcm5sbncwQ04zNi8yUnM4S1lx?= =?utf-8?B?ZmYzbTJROTM3NVJPb2VtOWI5bi81VVlKZ3NnYVI1V1ljSXFYTUZWMzFLTmw3?= =?utf-8?B?RUVaSWtPMlNKemlpbTJlbmt2QmRvelBob3ptRWFHWWpXVXNwSlJqRE9ldXdh?= =?utf-8?B?UU43cjdYcFhMU0JwWU1NT1lUOWZPUklGekpTMWVxMWNhcTM2L2IzTW02bEQ4?= =?utf-8?B?R2RoYzlXcFZzUXEwbkwwZ05MeXJWYWI0TDZHdlFQTDJNNmpwTUdOYlR2VDVE?= =?utf-8?B?U1E2MzVUQ2ViOUkwczlNMzdadzQwNGtLTnZVMzhkK29WUHY2OExwQlpTNmVx?= =?utf-8?B?TnBZaXppUXBlTnZyOU9mVER6NmNrQWxPaFpsUTNuMm53MUd5V2dyRU96aHlT?= =?utf-8?B?OWU3RkJ1NldIYWgwNUxPNjNPRlVGNVdyNUpiUy9weHl5ZVRNbFFQSkV5WDBy?= =?utf-8?Q?LUsujZRWEyofahXLhx?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: f19e7abc-3805-4d5c-3e62-08df1a54bf8b X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4999.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 15:59:00.4547 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PaKvxczgAv/CN2gXxsm9UjdKBGOmRSfx12jVaMOmuoFlcZ2FOWHiej90XtIetvDJa4qJpNtthxjPgMYILB2cDQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9718 X-purgate-ID: tlsNG-ef75cf/1790265549-A5EC6AE4-408026C9/0/0 X-purgate-type: clean X-purgate-size: 4410 On Wed Sep 23, 2026 at 6:19 PM CEST, Jason Andryuk wrote: > .init.setup, .initcallpresmp.init, and .initcall1.init are duplicated > across architectures. Replace them with a common define, SETUP_DATA. > > Suggested-by: Grygorii Strashko > Signed-off-by: Jason Andryuk > Reviewed-by: Alejandro Vallejo > Reviewed-by: Jan Beulich > --- > Alejandro reviewed internally. In case it matters, I confirm. Cheers, Alejandro > Jan reviewed off list. > --- > xen/arch/arm/xen.lds.S | 11 +---------- > xen/arch/ppc/xen.lds.S | 12 +----------- > xen/arch/riscv/xen.lds.S | 12 +----------- > xen/arch/x86/xen.lds.S | 11 +---------- > xen/include/xen/xen.lds.h | 12 ++++++++++++ > 5 files changed, 16 insertions(+), 42 deletions(-) > > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S > index d4d9594033..32afbfe131 100644 > --- a/xen/arch/arm/xen.lds.S > +++ b/xen/arch/arm/xen.lds.S > @@ -135,16 +135,7 @@ SECTIONS > *(.init.rodata) > *(.init.rodata.*) > =20 > - . =3D ALIGN(POINTER_ALIGN); > - __setup_start =3D .; > - *(.init.setup) > - __setup_end =3D .; > - > - __initcall_start =3D .; > - *(.initcallpresmp.init) > - __presmp_initcall_end =3D .; > - *(.initcall1.init) > - __initcall_end =3D .; > + SETUP_DATA > =20 > . =3D ALIGN(4); > __alt_instructions =3D .; > diff --git a/xen/arch/ppc/xen.lds.S b/xen/arch/ppc/xen.lds.S > index d0f2ed43f1..37256c8865 100644 > --- a/xen/arch/ppc/xen.lds.S > +++ b/xen/arch/ppc/xen.lds.S > @@ -107,17 +107,7 @@ SECTIONS > *(.init.rodata) > *(.init.rodata.*) > =20 > - . =3D ALIGN(POINTER_ALIGN); > - __setup_start =3D .; > - *(.init.setup) > - __setup_end =3D .; > - > - __initcall_start =3D .; > - *(.initcallpresmp.init) > - __presmp_initcall_end =3D .; > - *(.initcall1.init) > - __initcall_end =3D .; > - > + SETUP_DATA > LOCK_PROFILE_DATA > =20 > *(.init.data) > diff --git a/xen/arch/riscv/xen.lds.S b/xen/arch/riscv/xen.lds.S > index 70db658fef..d9375a9616 100644 > --- a/xen/arch/riscv/xen.lds.S > +++ b/xen/arch/riscv/xen.lds.S > @@ -114,17 +114,7 @@ SECTIONS > *(.init.rodata) > *(.init.rodata.*) > =20 > - . =3D ALIGN(POINTER_ALIGN); > - __setup_start =3D .; > - *(.init.setup) > - __setup_end =3D .; > - > - __initcall_start =3D .; > - *(.initcallpresmp.init) > - __presmp_initcall_end =3D .; > - *(.initcall1.init) > - __initcall_end =3D .; > - > + SETUP_DATA > LOCK_PROFILE_DATA > =20 > *(.init.data) > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S > index b9e888e596..8f943e11ea 100644 > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -223,16 +223,7 @@ SECTIONS > *(.init.rodata) > *(.init.rodata.*) > =20 > - . =3D ALIGN(POINTER_ALIGN); > - __setup_start =3D .; > - *(.init.setup) > - __setup_end =3D .; > - > - __initcall_start =3D .; > - *(.initcallpresmp.init) > - __presmp_initcall_end =3D .; > - *(.initcall1.init) > - __initcall_end =3D .; > + SETUP_DATA > =20 > *(.init.data) > *(.init.data.rel) > diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h > index ea11e3fb62..958f8256b0 100644 > --- a/xen/include/xen/xen.lds.h > +++ b/xen/include/xen/xen.lds.h > @@ -179,6 +179,18 @@ > *(.data.schedulers) \ > __end_schedulers_array =3D .; > =20 > +#define SETUP_DATA \ > + . =3D ALIGN(POINTER_ALIGN); \ > + __setup_start =3D .; \ > + *(.init.setup) \ > + __setup_end =3D .; \ > + \ > + __initcall_start =3D .; \ > + *(.initcallpresmp.init) \ > + __presmp_initcall_end =3D .; \ > + *(.initcall1.init) \ > + __initcall_end =3D .; > + > #ifdef CONFIG_HYPFS > #define HYPFS_PARAM \ > . =3D ALIGN(POINTER_ALIGN); \ From xen-devel-bounces@lists.xenproject.org Thu Sep 24 16:03:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 16:03:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432628.1653801 (Exim 4.92) (envelope-from ) id 1x9luf-0004Y5-46; Thu, 24 Sep 2026 16:03:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432628.1653801; Thu, 24 Sep 2026 16:03:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lue-0004Xy-Vr; Thu, 24 Sep 2026 16:03:08 +0000 Received: by outflank-mailman (input) for mailman id 1432628; Thu, 24 Sep 2026 16:03:08 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9lue-0004Xs-Ba for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 16:03:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9lud-0061dj-Oe for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 18:03:07 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab549bb-8faa-0a2a0a5109dd-0a2a450cecd2-2 for ; Thu, 24 Sep 2026 18:03:07 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab549bb-f479-0a2a450c0019-4a7de18d9b0d-3 for ; Thu, 24 Sep 2026 18:03:07 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49d1ca5b0d6so155705e9.0 for ; Thu, 24 Sep 2026 09:03:07 -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 ffacd0b85a97d-4887a30b1dfsm87108f8f.4.2026.09.24.09.03.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Sep 2026 09:03:06 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790265787; x=1790870587; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=eWz2yHL4cCdzhK6NSrqSIDHb7ADPce6lpaQOPtlheVQ=; b=KRzjf7mgwZn7d5KIF8RhNfEnc/cShy2yMWzE2IU0r+rYVwNcyF9/xDSQIgTsvqv0lF ANNxe6601hjkru8MtdnJAGqGl88iGfHcFE6jWpHcuawhFGjLlBN0LHvv1UDOkVM/dpFD BzuWitRiaFqGhVhjOzUFAchoPTi5E0vzy7/U+qHQ/1fYaS07UBem5Pqqhw6KOQwtN+F3 rQ+yYoydGw3WK/DD2ktwj8cXxJRCYG1yqWLYmnGysqJT/ZhjI/FkbvpJvicyGrDOUMCK 3bb0u/CJSMgT0fuFUl1WiZAf9IBya5P5svU19JeBZ19XjJNE3znb99IKRPihjtGSXW1j 1ZXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790265787; x=1790870587; h=content-transfer-encoding:content-type: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:content-type; bh=eWz2yHL4cCdzhK6NSrqSIDHb7ADPce6lpaQOPtlheVQ=; b=UauOj5n+3g90ImDIjSBVNsk+WhyzEr6rUt1ATWwckAIZtRl36q+Dr1tcmafK/pDj0j 8HY5TUfsNx3y6Nvpx3O9MhTL7kTcf3dbURHW5+ELAGKCnobZSX8Z4V55Al6jmexAFsvG ex8lJoUkmdAq/UVGrxWFyOgW7LhH4QMp9npddCiuj7sSS3mhDqVZe3etjWHGop9afm5Z Ka+qYwZSj+cyXZ49046OI0s+M1ExAkAHPaR+Z1bjA3sm6AlyjqVd6GLsJNab0rtCCKUF SCsLKBjZWXrutMMiZM24Q756maWv4XEoL2AzC+OT1lxUe80UO2ntl2V5NuQuNMrjgjAy f1qA== X-Forwarded-Encrypted: i=1; AKwUvBxbZqcscmIqouhxEMOwd60b2MW/i69Ui8YS0TN9jt7Jsk4eW1EJ560TYjYyzmGoAH6MFKXfI54dZ/c=@lists.xenproject.org X-Gm-Message-State: AFuF++k4szpAXKtLWOM5xn+xcRCvO9Id+xdmqhbMv1mRA6oUfKsfapIP 2uu4hrMMDJuSic+9gW02EtttdHU/IvceqB40jSEo2U3TQfqev6ntO2fFoK/NYsn4uA== X-Gm-Gg: AYBFou2Zq6crWTDRfd/OtnnZIQ+IQWZYo4Nrlu2llQA+OHFx2XO94Ul722tycY2Iqgp B7XRqIIfRroOumIX+hGVx4ja3XOzud8svRymUugSpgg+L/IMFGDhSvT3O8hieENFYyEcNetg/y8 qA6FeLUdhcggW8Jv8dElaXpBhS1Y6DP9DfBS5l9Wy7o8iXECG0vYlxv36KfSn6EIdjUyoav9oOk zsAcHoZnK15hVEivx5gIB6BgJOtM4tFRm3Gzr1FyvzwpN6JdgWcQCX+0GtqoVjJtK5/I8m2ld3h N5h9Lcu3NRnVOAh7us/Og974P1Mr8dFXOcg+FjWDG6Gi+KCumG2UPr7Aao/LAQyNER+iW4ZicWO F/6fhrKw4VkRvWY2kczDe9thLt0e9bfOK1w5i6/SBQsdl3Q9C802g4t0hS/EZOHSAjUbgoGxaM3 eTAiC5sVu7xqGoiQRGhfWVQIyYYRB+xVx6OzYm48oPl6I+AILg2BgKYJzY8CkpEopV105yhKBfF Zst2ln45Pc9i5GF2bbkJiuxWxZ20V76UHF024qPu/OcOSKGUe2cyl4h8d5czg== X-Received: by 2002:a05:600c:a010:b0:49e:79c5:ee93 with SMTP id 5b1f17b1804b1-49fe66b422emr52312045e9.8.1790265787005; Thu, 24 Sep 2026 09:03:07 -0700 (PDT) Message-ID: Date: Thu, 24 Sep 2026 18:03:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/nSVM: Save L2's CR4 on #VMEXIT, not Xen's To: Ross Lagerwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org, Lin Liu References: <38c41bfb-48c6-4408-8da1-2b7d730a6c9e@citrix.com> <711e6af5-beca-4b71-a2cb-75cb1ed93689@suse.com> <70bd67f8-fbe2-44e2-a050-b6065ba2de7f@citrix.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: <70bd67f8-fbe2-44e2-a050-b6065ba2de7f@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790265787-778D5A5B-28DAEA79/0/0 X-purgate-type: clean X-purgate-size: 2199 On 24.09.2026 17:50, Ross Lagerwall wrote: > On 9/24/26 4:01 PM, Jan Beulich wrote: >> On 23.09.2026 13:16, Ross Lagerwall wrote: >>> On 9/23/26 10:51 AM, Lin Liu wrote: >>>> Xen leaks the host's CR4 bits to L1. >>>> >>>> nsvm_vmcb_prepare4vmrun() constructs the shadow VMCB's CR4 via >>>> hvm_set_cr4(), and svm_update_guest_cr() ORs in HVM_CR4_HOST_MASK. >>>> nsvm_vmcb_prepare4vmexit() then copies CR4 back out of the shadow VMCB >>>> instead of the value kept in v->arch.hvm.guest_cr[4], so L1 reads back >>>> Xen's bits - under HAP, CR4.MCE. >>>> >>>> Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization") >>>> Assisted-by: Claude:claude-opus-5 >>>> Signed-off-by: Lin Liu >>>> --- >>>> xen/arch/x86/hvm/svm/nestedsvm.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c >>>> index a8b15d6eae..8d99b0affc 100644 >>>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c >>>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c >>>> @@ -1082,7 +1082,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct cpu_user_regs *regs) >>>> ns_vmcb->_efer = n2vmcb->_efer; >>>> >>>> /* CRn */ >>>> - ns_vmcb->_cr4 = n2vmcb->_cr4; >>>> + ns_vmcb->_cr4 = v->arch.hvm.guest_cr[4]; >>>> ns_vmcb->_cr0 = n2vmcb->_cr0; >>>> >>>> /* DRn */ >>> >>> Reviewed-by: Ross Lagerwall >>> >>> Did you consider addressing similar issues with the other state copied from >>> n2vmcb as well? i.e. I think something similar would apply to CR0, EFER, etc. >> >> But (assuming the above code change is indeed correct) wouldn't we better deal >> with CR0 then right away, rather that leaving things even visually inconsistent? > > That's up to the maintainers to decide, though given the state of the Nested > SVM code at the moment IMO it is fine to take valid improvements and make some > forward progress even if they don't address all the related issues at once. Yet moving code into more inconsistent shape isn't a very good step, when things are meant to be truly improved. Jan From xen-devel-bounces@lists.xenproject.org Thu Sep 24 18:39:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 18:39:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432856.1653813 (Exim 4.92) (envelope-from ) id 1x9oLu-0000Zy-QY; Thu, 24 Sep 2026 18:39:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432856.1653813; Thu, 24 Sep 2026 18:39:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9oLu-0000Zr-MD; Thu, 24 Sep 2026 18:39:26 +0000 Received: by outflank-mailman (input) for mailman id 1432856; Thu, 24 Sep 2026 18:39:24 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9oLs-0000Zj-Gz for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 18:39:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9oLr-00C7q7-UN for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:39:23 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab56e50-8faa-0a2a0a5109dd-0a2a4509bdd0-12 for ; Thu, 24 Sep 2026 20:39:23 +0200 Received: from [74.125.229.205] (helo=mail-lf2-f13.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab56e5b-be1a-0a2a45090019-4a7de5cdea89-3 for ; Thu, 24 Sep 2026 20:39:23 +0200 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b8c9954ccbso127786e87.1 for ; Thu, 24 Sep 2026 11:39:23 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790275163; cv=none; d=google.com; s=arc-20260327; b=g+YGtkU7eUDG2f86KEJHwTha/mzZVmQZeqVvOl+Eu4LNMwwqsORFWyRrHxZDRBp3Xm XU3ytyo90USNsDuqFffaHXpsUhBROgAwFDHQbLhI0hFdhTvJGkQ1CF5K99S1Pdgs1F0K gcpcX9s06I/Bq9xhi9yZkzkCp9Bai+7U+sXysxvbfwky1YjMB66MX5/SfWcmBeEjYoHk YONkyW/ZAb3/hJ+K19qArf+gTl/dsHlTitaCDDhsi4B87uD8wm2CWvjM6Lu81uJ+nI93 174dcBIFXxrJI3XOHaEuxAYYIlzFOEwgdouLXVQcfguGsydgOFgqkQdvtCYpxTGlZJT3 qraA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=I3tgwS5wyBwBpBV19eTdSTSNQN0siP1GJboYFHResf4=; fh=RwOOD8FwKHtBBkobGpKkroeNqvZU5mMoUlw2sGgs4aY=; b=oQaRFRrDFQt1KrnM9XefVM5DZ/YFBM1FBOvSY0KpHwbBWXFR46B09uVcwJdTlIaYJY PmXuzumBS9TKRDfwB1jOsFUaJgp99CuarhVmZO5IP6+Y7TNNk3eydTIqO2mo/CeYy1lW 6LOEWAMo5Yxgl4orBLXxgctBCW/kFb+inCzz6S77RfEwCMdLWD8OwLJSBxQTSBlPtvD1 2kni9ayJF7y1AWIupLQv0/vyG678JRI6wSRUe8qMSeqPiR4d6H1ZrmROy687haN/msLQ MgTXhM/6g3Rm/uC4pnRrnJooJpLd9hUvHNPhat8XYos/WlTFHpypOeTEjKESPpHkaLRF Qnvw==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790275163; x=1790879963; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=I3tgwS5wyBwBpBV19eTdSTSNQN0siP1GJboYFHResf4=; b=QqEColEjy/n2Eysh9z9SNGVHPAOaVdXtHSu+oD7utvjf4gwRfO8fEKsckNl2GoEwCS t4/wH3ugJx3WYxjtqBHHNS6DBaxhKpqJnCk7icHSHlu8vq5a8P67z0LVB3SKkyUqNkWg bn4wQh0iiCeudG+AD36/QXtpy9FtYe6lW4o54DzO64YBWKSNgMyssTp8c7UT5VB2wtaD Hlz2Vh19QnM86PoHecAwtJFg5ngrkQGy5JQ9Uut/VowRXUDLp6GKDI14wGmgz6Kw9dFA c7fh++5GvDbLKvJEf16wXamYO1yS6wlGSP1CfUyLSRM30KGmlcK8JmuscUfYdSJ+KJyL DOXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790275163; x=1790879963; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=I3tgwS5wyBwBpBV19eTdSTSNQN0siP1GJboYFHResf4=; b=wo7wdGXEykIkSTu/oi9yW1aQCi9zx2tjFl5uBKIgkkm/A5z3ILICxJULzL11n3oxEU puvle4SQhKfpU8CVD0uQbmfz6MhW2JZNv7J4uKMC0cxOc5Uzs/PzhiAaNpJTL9BdWhq4 j1OEu4Qmi5wvdw0Y/DRHgFjwO9ZnQ4hJyKbVos7aegryJOIe2irN7co2ntFEQ7XtsUBY 4d0QKoLXjG2qWujzEaWL5GVi91XZyIJy/acgO93gV8ki9ogfTZo+qiUPZ52xl7VybO+T cjlM9RfDF3JdJHMizKAwRnjX4aePRjSnuOg6aELuz/q//6qaCgD1OQTDKUDLb5lnd5i1 fV6A== X-Gm-Message-State: AFuF++mAZVbR0jr3jh60YBoZ/O/8Bt1H5CwAJP0xjeQGh1Mnz7qaHUVr 8aC/VCj02BEpLgYVWkFKcpbfom9NruNKUvnKlg7NNCsBDpSiuIyXYDo3U34EpU6E+fM8e4JDxXv Pbkw+6HtLURC3y28P78CFTF9B5ZmFVIw= X-Gm-Gg: AYBFou2sHJkmBKiWN32EOjTzvl/UuMLjbVNvDda7rmJCkUqcST/pZQtWDwcNV4VVVxF HhR22QshGQqWuiBI4eZSTUJa9Vd4fYMhHjzNfzVv5lsdA+LpwkRLlkdyg2LheU+n7MHmJpNt0vq 8IRCWYLcA0/KOzrRuy48Hz5VSVLC3i8zFmz/xPqGmIh1ozUWcerzFvBMv93rcxxw2cLBY1O6aLt I0xPnzGBf/imG/lxYC+2rwmydH3fZIzIAdcGsWEhw9+qj1CZOCiwI3TPD8zXIjShKbj2p0X6GoG FIDRmhHKVeUa8I/h/vVBP2xtI1rPGv9wT8QQpFEOspJlCHPSFQWjag== X-Received: by 2002:a05:6512:79:b0:5b8:98fb:e181 with SMTP id 2adb3069b0e04-5b8df0a5097mr897230e87.20.1790275162793; Thu, 24 Sep 2026 11:39:22 -0700 (PDT) MIME-Version: 1.0 References: <38850629-8bfa-4737-99ff-0fd3f489e56e@suse.com> <436c0688-8b9a-4e56-9d4c-c81dcfbea56e@suse.com> In-Reply-To: <436c0688-8b9a-4e56-9d4c-c81dcfbea56e@suse.com> From: Mykola Kvach Date: Thu, 24 Sep 2026 21:39:11 +0300 X-Gm-Features: AclHuK8NLeN81eO9h380fwq7TKT58gsAnrdNcuzQeq_w2xSzXXNCkuD1aHuuwQQ Message-ID: Subject: Re: [PATCH 7/7] gnttab: unreachable code when GNTTAB_MAX_VERSION < 2 To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Nicola Vetrini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1790275163-BD0CD034-462F8F19/0/0 X-purgate-type: clean X-purgate-size: 19593 Hi, On Tue, Jul 28, 2026 at 4:53=E2=80=AFPM Jan Beulich wro= te: > > I'm surprised Eclair doesn't spot the large chunks of unreachable code on > Arm, i.e. violations of Misra C:2012 rule 2.1. > > Signed-off-by: Jan Beulich > --- > This pretty certainly isn't dealing with everything. For example, with > another helper the gt_version field could likely also become conditional. > With some more effort the nr_status_frames field similarly could become > conditional. Could we also skip the gt->status allocation and cleanup on Arm? grant_table_init() still allocates this pointer array, although status pages are only used by v2. This could be done in a follow-up patch, together with the fields you mentioned. > > --- a/xen/common/grant_table.c > +++ b/xen/common/grant_table.c > @@ -72,8 +72,10 @@ struct grant_table { > /* Number of grant status frames shared with guest (for version 2) *= / > unsigned int nr_status_frames; > > +#if GNTTAB_MAX_VERSION >=3D 2 > /* Number of version 2 operations in progress. */ > atomic_t nr_v2_ops; > +#endif /* GNTTAB_MAX_VERSION >=3D 2 */ > > /* > * Number of available maptrack entries. For cleanup purposes it is > @@ -182,12 +184,10 @@ static int cf_check parse_gnttab_max_map > opt_max_maptrack_frames_val); > } > > -#ifndef GNTTAB_MAX_VERSION > -#define GNTTAB_MAX_VERSION 2 > -#endif > - > +#if GNTTAB_MAX_VERSION >=3D 2 > unsigned int __read_mostly opt_gnttab_max_version =3D GNTTAB_MAX_VERSION= ; > static bool __read_mostly opt_transitive_grants =3D true; > +#endif > #ifdef CONFIG_PV > static bool __ro_after_init opt_grant_transfer =3D true; > #else > @@ -196,17 +196,24 @@ static bool __ro_after_init opt_grant_tr > > static int __init cf_check parse_gnttab(const char *s) > { > - const char *ss, *e; > - int val, rc =3D 0; > + const char *ss; > + int rc =3D 0; > > do { > + int val; > + > ss =3D strchr(s, ','); > if ( !ss ) > ss =3D strchr(s, '\0'); > > - if ( !strncmp(s, "max-ver:", 8) || > - !strncmp(s, "max_ver:", 8) ) /* Alias for original XSA-226 = patch */ > + if ( false ) > + (void)val; /* Nothing. */ > +#ifndef opt_gnttab_max_version > + else if ( !strncmp(s, "max-ver:", 8) || > + /* Alias for original XSA-226 patch */ > + !strncmp(s, "max_ver:", 8) ) > { > + const char *e; > long ver =3D simple_strtol(s + 8, &e, 10); > > if ( e =3D=3D ss && ver >=3D 1 && ver <=3D 2 ) > @@ -216,6 +223,7 @@ static int __init cf_check parse_gnttab( > } > else if ( (val =3D parse_boolean("transitive", s, ss)) >=3D 0 ) > opt_transitive_grants =3D val; > +#endif > #ifndef opt_grant_transfer > else if ( (val =3D parse_boolean("transfer", s, ss)) >=3D 0 ) > opt_grant_transfer =3D val; > @@ -330,10 +338,12 @@ shared_entry_header(struct grant_table * > block_speculation(); > return (grant_entry_header_t*)&shared_entry_v1(t, ref); > > +#if GNTTAB_MAX_VERSION >=3D 2 > case 2: > /* Returned values should be independent of speculative executio= n */ > block_speculation(); > return &shared_entry_v2(t, ref).hdr; > +#endif > } > > ASSERT_UNREACHABLE(); > @@ -378,6 +388,9 @@ struct active_grant_entry { > }) > > domid_t domid; /* Domain being granted access. */ > + > +#if GNTTAB_MAX_VERSION >=3D 2 > + > domid_t src_domid; /* Original domain granting access. */ > unsigned int start:15; /* For sub-page grants, the start offset > in the page. */ > @@ -385,6 +398,9 @@ struct active_grant_entry { > unsigned int length:16; /* For sub-page grants, the length of the > grant. */ > grant_ref_t trans_gref; > + > +#endif /* GNTTAB_MAX_VERSION < 2 */ > + > mfn_t mfn; /* Machine frame being granted. */ > #ifndef NDEBUG > gfn_t gfn; /* Guest's idea of the frame being granted. */ > @@ -405,6 +421,15 @@ static inline void act_set_gfn(struct ac > #endif > } > > +static bool act_is_sub_page(const struct active_grant_entry *act) > +{ > +#if GNTTAB_MAX_VERSION >=3D 2 > + return act->is_sub_page; > +#else > + return false; > +#endif > +} > + > static DEFINE_PERCPU_RWLOCK_GLOBAL(grant_rwlock); > > static always_inline void grant_read_lock(struct grant_table *gt) > @@ -724,6 +749,7 @@ static unsigned int nr_grant_entries(str > block_speculation(); > return f2e(nr_grant_frames(gt), 1); > > +#if GNTTAB_MAX_VERSION >=3D 2 > case 2: > BUILD_BUG_ON(f2e(INITIAL_NR_GRANT_FRAMES, 2) < > GNTTAB_NR_RESERVED_ENTRIES); > @@ -731,6 +757,7 @@ static unsigned int nr_grant_entries(str > /* Make sure we return a value independently of speculative exec= ution */ > block_speculation(); > return f2e(nr_grant_frames(gt), 2); > +#endif /* GNTTAB_MAX_VERSION >=3D 2 */ > #undef f2e > } > > @@ -919,7 +946,7 @@ static int _set_status(const grant_entry > domid_t ldomid) > { > > - if ( evaluate_nospec(rgt_version =3D=3D 1) ) > + if ( GNTTAB_MAX_VERSION < 2 || evaluate_nospec(rgt_version =3D=3D 1)= ) > return _set_status_v1(shah, rd, act, readonly, mapflag, ldomid); > else > return _set_status_v2(shah, status, rd, act, readonly, mapflag, = ldomid); > @@ -1089,17 +1116,18 @@ map_grant_ref( > if ( act->pin && > ((act->domid !=3D ld->domain_id) || > (act->pin & GNTPIN_incr2oflow_mask(pin_incr)) || > - (act->is_sub_page)) ) > + act_is_sub_page(act)) ) > { > gdprintk(XENLOG_WARNING, > "Bad domain (%d !=3D %d), or risk of counter overflow %= 08x, or subpage %d\n", > - act->domid, ld->domain_id, act->pin, act->is_sub_page); > + act->domid, ld->domain_id, act->pin, act_is_sub_page(ac= t)); > rc =3D GNTST_general_error; > goto act_release_out; > } > > /* Make sure we do not access memory speculatively */ > - status =3D evaluate_nospec(rgt->gt_version =3D=3D 1) ? &shah->flags > + status =3D GNTTAB_MAX_VERSION < 2 || > + evaluate_nospec(rgt->gt_version =3D=3D 1) ? &shah->flags > : &status_entry(rgt, = ref); > > if ( !act->pin || > @@ -1113,9 +1141,10 @@ map_grant_ref( > > if ( !act->pin ) > { > - unsigned long gfn =3D evaluate_nospec(rgt->gt_version =3D=3D= 1) ? > - shared_entry_v1(rgt, ref).frame : > - shared_entry_v2(rgt, ref).full_page.fram= e; > + unsigned long gfn =3D GNTTAB_MAX_VERSION < 2 || > + evaluate_nospec(rgt->gt_version =3D=3D 1= ) > + ? shared_entry_v1(rgt, ref).frame > + : shared_entry_v2(rgt, ref).full_page.fr= ame; > > rc =3D get_paged_frame(gfn, &mfn, &pg, > op->flags & GNTMAP_readonly, rd); > @@ -1124,11 +1153,13 @@ map_grant_ref( > act_set_gfn(act, _gfn(gfn)); > act->domid =3D ld->domain_id; > act->mfn =3D mfn; > +#if GNTTAB_MAX_VERSION >=3D 2 > act->start =3D 0; > act->length =3D PAGE_SIZE; > act->is_sub_page =3D false; > act->src_domid =3D rd->domain_id; > act->trans_gref =3D ref; > +#endif /* GNTTAB_MAX_VERSION >=3D 2 */ > } > } > > @@ -1350,7 +1381,8 @@ map_grant_ref( > > grant_read_lock(rgt); > > - if ( unlikely(evaluate_nospec((rgt->gt_version =3D=3D 1) !=3D > + if ( GNTTAB_MAX_VERSION >=3D 2 && > + unlikely(evaluate_nospec((rgt->gt_version =3D=3D 1) !=3D > (status =3D=3D &shah->flags))) ) > { > /* > @@ -1625,7 +1657,7 @@ unmap_common_complete(struct gnttab_unma > > act =3D active_entry_acquire(rgt, op->ref); > > - if ( evaluate_nospec(rgt->gt_version =3D=3D 1) ) > + if ( GNTTAB_MAX_VERSION < 2 || evaluate_nospec(rgt->gt_version =3D= =3D 1) ) > status =3D &shared_entry_v1(rgt, op->ref).flags; > else if ( evaluate_nospec(op->ref < nr_grant_entries(rgt)) ) > status =3D &status_entry(rgt, op->ref); > @@ -1947,7 +1979,7 @@ gnttab_grow_table(struct domain *d, unsi > } > > /* Status pages - version 2 */ > - if ( evaluate_nospec(gt->gt_version > 1) ) > + if ( GNTTAB_MAX_VERSION >=3D 2 && evaluate_nospec(gt->gt_version > 1= ) ) > { > if ( gnttab_populate_status_frames(d, gt, req_nr_frames) ) > goto shared_alloc_failed; > @@ -2122,7 +2154,7 @@ gnttab_setup_table( > } > > if ( (op.nr_frames > nr_grant_frames(gt) || > - ((gt->gt_version > 1) && > + ((GNTTAB_MAX_VERSION >=3D 2) && (gt->gt_version > 1) && > (grant_to_status_frames(op.nr_frames) > nr_status_frames(gt))= )) && > gnttab_grow_table(d, op.nr_frames) ) > { > @@ -2472,7 +2504,8 @@ gnttab_transfer( > grant_read_lock(e->grant_table); > act =3D active_entry_acquire(e->grant_table, gop.ref); > > - if ( unlikely(evaluate_nospec(e->grant_table->gt_version !=3D ve= r)) ) > + if ( GNTTAB_MAX_VERSION >=3D 2 && > + unlikely(evaluate_nospec(e->grant_table->gt_version !=3D ve= r)) ) > { > rc =3D -EILSEQ; > goto release; > @@ -2538,12 +2571,13 @@ release_grant_for_copy( > act =3D active_entry_acquire(rgt, gref); > mfn =3D act->mfn; > > - if ( evaluate_nospec(rgt->gt_version =3D=3D 1) ) > + if ( GNTTAB_MAX_VERSION < 2 || evaluate_nospec(rgt->gt_version =3D= =3D 1) ) > { > status =3D &shared_entry_v1(rgt, gref).flags; > td =3D rd; > trans_gref =3D gref; > } > +#if GNTTAB_MAX_VERSION >=3D 2 > else > { > if ( evaluate_nospec(gref < nr_grant_entries(rgt)) ) > @@ -2552,6 +2586,7 @@ release_grant_for_copy( > ? rd : knownalive_domain_from_domid(act->src_domid); > trans_gref =3D act->trans_gref; > } > +#endif /* GNTTAB_MAX_VERSION >=3D 2 */ > > if ( readonly ) > { > @@ -2566,13 +2601,15 @@ release_grant_for_copy( > > reduce_status_for_pin(rd, act, status, readonly); > > +#if GNTTAB_MAX_VERSION >=3D 2 > if ( !act->pin && act->is_sub_page ) > atomic_dec(&rgt->nr_v2_ops); > +#endif > > active_entry_release(act); > grant_read_unlock(rgt); > > - if ( td !=3D rd ) > + if ( GNTTAB_MAX_VERSION >=3D 2 && td !=3D rd ) > { > /* > * Recursive call, but it is bounded (acquire permits only a sin= gle > @@ -2593,8 +2630,11 @@ release_grant_for_copy( > static int > acquire_grant_for_copy( > struct domain *rd, grant_ref_t gref, domid_t ldom, bool readonly, > - mfn_t *mfn, struct page_info **page, uint16_t *page_off, > - uint16_t *length, bool allow_transitive) > + mfn_t *mfn, struct page_info **page > +#if GNTTAB_MAX_VERSION >=3D 2 > + , uint16_t *page_off, uint16_t *length, bool allow_transitive > +#endif > + ) > { > struct grant_table *rgt =3D rd->grant_table; > grant_entry_v2_t *sha2; > @@ -2637,7 +2677,7 @@ acquire_grant_for_copy( > goto unlock_out; > } > > - if ( evaluate_nospec(rgt->gt_version =3D=3D 1) ) > + if ( GNTTAB_MAX_VERSION < 2 || evaluate_nospec(rgt->gt_version =3D= =3D 1) ) > { > sha2 =3D NULL; > status =3D &shah->flags; > @@ -2652,6 +2692,7 @@ acquire_grant_for_copy( > barrier(); > > old_pin =3D act->pin; > +#if GNTTAB_MAX_VERSION >=3D 2 > if ( sha2 && (shflags & GTF_type_mask) =3D=3D GTF_transitive ) > { > domid_t trans_domid; > @@ -2786,8 +2827,10 @@ acquire_grant_for_copy( > else > atomic_dec(&rgt->nr_v2_ops); > } > - else if ( !old_pin || > - (!readonly && !(old_pin & (GNTPIN_devw_mask|GNTPIN_hstw_ma= sk))) ) > + else > +#endif /* GNTTAB_MAX_VERSION >=3D 2 */ > + if ( !old_pin || > + (!readonly && !(old_pin & (GNTPIN_devw_mask|GNTPIN_hstw_mask)))= ) > { > unsigned long gfn; > > @@ -2828,23 +2871,29 @@ acquire_grant_for_copy( > if ( !act->pin ) > { > act->domid =3D ldom; > + act->mfn =3D grant_mfn; > + > +#if GNTTAB_MAX_VERSION >=3D 2 > act->is_sub_page =3D is_sub_page; > act->start =3D trans_page_off; > act->length =3D trans_length; > act->src_domid =3D rd->domain_id; > act->trans_gref =3D gref; > - act->mfn =3D grant_mfn; > > if ( is_sub_page ) > atomic_inc(&rgt->nr_v2_ops); > +#endif /* GNTTAB_MAX_VERSION >=3D 2 */ > } > else if ( !mfn_eq(act->mfn, grant_mfn) || > +#if GNTTAB_MAX_VERSION >=3D 2 > act->src_domid !=3D rd->domain_id || > act->trans_gref !=3D gref || > (act->is_sub_page && > (!is_sub_page || > act->start !=3D trans_page_off || > - act->length !=3D trans_length)) ) > + act->length !=3D trans_length)) || > +#endif /* GNTTAB_MAX_VERSION >=3D 2 */ > + false ) > { > put_page(*page); > *page =3D NULL; > @@ -2881,8 +2930,10 @@ acquire_grant_for_copy( > > act->pin +=3D pin_incr; > > +#if GNTTAB_MAX_VERSION >=3D 2 > *page_off =3D act->start; > *length =3D act->length; > +#endif > *mfn =3D act->mfn; > > active_entry_release(act); > @@ -3014,13 +3065,20 @@ static int gnttab_copy_claim_buf(const s > rc =3D acquire_grant_for_copy(buf->domain, ptr->u.ref, > current->domain->domain_id, > buf->read_only, > - &buf->mfn, &buf->page, > - &buf->ptr.offset, &buf->len, > - opt_transitive_grants); > + &buf->mfn, &buf->page > +#if GNTTAB_MAX_VERSION >=3D 2 > + , &buf->ptr.offset, &buf->len, > + opt_transitive_grants > +#endif > + ); > if ( rc !=3D GNTST_okay ) > goto out; > buf->ptr.u.ref =3D ptr->u.ref; > buf->have_grant =3D 1; > +#if GNTTAB_MAX_VERSION < 2 > + buf->ptr.offset =3D 0; > + buf->len =3D PAGE_SIZE; > +#endif > } > else > { > @@ -3241,6 +3299,12 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA > if ( gt->gt_version =3D=3D op.version ) > goto out_unlock; > > + if ( GNTTAB_MAX_VERSION < 2 ) > + { > + res =3D -EOPNOTSUPP; > + goto out_unlock; > + } > + > /* > * Make sure that the grant table isn't currently in use when we > * change the version number, except for the first 8 entries which > @@ -3270,6 +3334,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA > break; > > case 2: > +#if GNTTAB_MAX_VERSION >=3D 2 > if ( atomic_read(>->nr_v2_ops) ) > { > gdprintk(XENLOG_WARNING, > @@ -3278,6 +3343,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA > res =3D -EAGAIN; > goto out_unlock; > } > +#endif /* GNTTAB_MAX_VERSION >=3D 2 */ > > for ( i =3D 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ ) > { > @@ -3527,7 +3593,7 @@ swap_grant_ref(grant_ref_t ref_a, grant_ > goto out; > } > > - if ( evaluate_nospec(gt->gt_version =3D=3D 1) ) > + if ( GNTTAB_MAX_VERSION < 2 || evaluate_nospec(gt->gt_version =3D=3D= 1) ) > { > grant_entry_v1_t shared; > > @@ -3945,7 +4011,7 @@ int gnttab_release_mappings(struct domai > > act =3D active_entry_acquire(rgt, ref); > sha =3D shared_entry_header(rgt, ref); > - if ( rgt->gt_version =3D=3D 1 ) > + if ( GNTTAB_MAX_VERSION < 2 || rgt->gt_version =3D=3D 1 ) > status =3D &sha->flags; > else > status =3D &status_entry(rgt, ref); > @@ -4120,7 +4186,7 @@ int mem_sharing_gref_to_gfn(struct grant > rc =3D -EINVAL; > else if ( ref >=3D nr_grant_entries(gt) ) > rc =3D -ENOENT; > - else if ( evaluate_nospec(gt->gt_version =3D=3D 1) ) > + else if ( GNTTAB_MAX_VERSION < 2 || evaluate_nospec(gt->gt_version = =3D=3D 1) ) > { > const grant_entry_v1_t *sha1 =3D &shared_entry_v1(gt, ref); > > @@ -4144,7 +4210,7 @@ int mem_sharing_gref_to_gfn(struct grant > rc =3D -ENXIO; > else if ( !rc && status ) > { > - if ( evaluate_nospec(gt->gt_version =3D=3D 1) ) > + if ( GNTTAB_MAX_VERSION < 2 || evaluate_nospec(gt->gt_version = =3D=3D 1) ) > *status =3D flags; > else > *status =3D status_entry(gt, ref); > @@ -4275,7 +4341,7 @@ int gnttab_acquire_resource( > break; > > case XENMEM_resource_grant_table_id_status: > - if ( gt->gt_version !=3D 2 ) > + if ( GNTTAB_MAX_VERSION < 2 || gt->gt_version !=3D 2 ) > break; > > /* Check that void ** is a suitable representation for gt->statu= s. */ > @@ -4327,7 +4393,8 @@ int gnttab_map_frame_begin( > > grant_write_lock(gt); > > - if ( evaluate_nospec(gt->gt_version =3D=3D 2) && (idx & XENMAPIDX_gr= ant_table_status) ) > + if ( GNTTAB_MAX_VERSION >=3D 2 && evaluate_nospec(gt->gt_version =3D= =3D 2) && > + (idx & XENMAPIDX_grant_table_status) ) > { > idx &=3D ~XENMAPIDX_grant_table_status; > rc =3D gnttab_get_status_frame_mfn(d, idx, mfn); > @@ -4395,7 +4462,7 @@ static void gnttab_usage_print(struct do > > sha =3D shared_entry_header(gt, ref); > > - if ( gt->gt_version =3D=3D 1 ) > + if ( GNTTAB_MAX_VERSION < 2 || gt->gt_version =3D=3D 1 ) > { > status =3D sha->flags; > frame =3D shared_entry_v1(gt, ref).frame; > --- a/xen/include/xen/grant_table.h > +++ b/xen/include/xen/grant_table.h > @@ -39,7 +39,16 @@ void gnttab_seed_entry(const struct doma > > #ifdef CONFIG_GRANT_TABLE > > +#ifndef GNTTAB_MAX_VERSION > +#define GNTTAB_MAX_VERSION 2 > +#endif > + > +#if GNTTAB_MAX_VERSION >=3D 2 > extern unsigned int opt_gnttab_max_version; > +#else > +# define opt_gnttab_max_version GNTTAB_MAX_VERSION > +#endif > + > extern unsigned int opt_max_grant_frames; > > /* Create/destroy per-domain grant table context. */ > > Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Thu Sep 24 18:42:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 18:42:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432862.1653821 (Exim 4.92) (envelope-from ) id 1x9oOe-00024t-43; Thu, 24 Sep 2026 18:42:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432862.1653821; Thu, 24 Sep 2026 18:42:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9oOe-00024m-1A; Thu, 24 Sep 2026 18:42:16 +0000 Received: by outflank-mailman (input) for mailman id 1432862; Thu, 24 Sep 2026 18:42:14 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9oOc-00024d-63 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 18:42:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9oOb-00HIqf-FS for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:42:13 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab56eea-bab6-0a2a0a5309dd-0a2a450aab22-16 for ; Thu, 24 Sep 2026 20:42:13 +0200 Received: from [40.107.130.108] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab56f04-f2d2-0a2a450a0019-286b826c4bd9-3 for ; Thu, 24 Sep 2026 20:42:13 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AMCPR03MB911417.eurprd03.prod.outlook.com (2603:10a6:20b:781::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 18:42:11 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 18:42:10 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=M5B929zb0kL2FmQJcn6Y0yOWfQfjMspu1sMz4+YI9TxCksgAFGBaSPSLo9iH7ibBJPJbyjoQoaXx291V70+Ewa5mTGpMgvojmwiRWuIOJpqtVUOEqzc9ziOWnDgZtsF8xSIGqchTGeX4U9+bx+7K2xbgEFc3Y/MMFXlOmXZj24Xhc11w+d411xgXhF8+DPJAmKhKW4QJNxJRsdLaR1NMkFCDrT/Qpsi6ADnkRojOvq7Tz3N1F5eP4niD//Mdn3dZBcsnizbL30kZtBDm+PMiglI0o2cbUQyhIqB2PaC+l7GmQX3QK5fsEnKD9IN+4hRYPI5vBRktY9plQaEpUEcP7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YA9Wn4joB96MWjXRDgzj9xYdvqWzXYoF+5mpJT+zURw=; b=AX9wf0/nF1AAo84LW7W9+BWVLZRJ5nif36TPbfhqxAmc3JNnGlP897+utnACMGqxF7eOzn1dQ/bQGvgXRV39O7ViaGaxoD5NsJt9sEjiLUCwJ7pby8zfAuMI0jkbixNuGoSFQiyhZcf1h/y6GXWcODxULqsBMbU48PAkD1GiLtiHvSWM3vATprX+0DPsURgfPGjOie1VHO0nAnYGtrrpDFvHzlLPZJWdnGXZgG+gK8ssDaRxQ68CYV+kWOx5ab3cY7/26RaJOhYjLYUSM6ri7gi8tWf0QmGVElFNvqZ/VvPnjj4HxsTMG1OqNagX/izQg4Egrsvdr/LpJ9scmxEVzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YA9Wn4joB96MWjXRDgzj9xYdvqWzXYoF+5mpJT+zURw=; b=t3F94x4GDywW9oI1NVqv7hsVbprbuD2fDWQ+cwroeCZuwrJg1WkumP1mht1d8rpxunKjwDyvNrjDjv5FY2EAL+EfCWeCMe6OpASkkhlPyVVi5o7O8n18rZU3dUG/LpUGJXaz9eMFNcIGgEimZh1842DiCxq4BpTmHBzIgsTJGGHqvYbdSoX3yhSCPrGvgMvK7xB1eyDVwAkqeNVObdWrlwEJM/GqpIC/BsXma4bhBqY4oKb1HmvJBaH9ndpPAhyTjF3gQCWNHjTyA3zW5SFjDN5fplCnVbsRpSIN04iyLPgW89LoIn/bA9doAgb+GNW5XURlryMfQz/yd9a9KQk0/w== From: Volodymyr Babchuk To: Oleksii Moisieiev CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Grygorii Strashko Subject: Re: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdSqBPF0kScKehyU2HqE/MZamZRQ== Date: Thu, 24 Sep 2026 18:42:10 +0000 Message-ID: <87zex61ofy.fsf@epam.com> References: <5c3ae163d21f619bf25c8757232a1a0867c3eb87.1790087968.git.oleksii_moisieiev@epam.com> <87pky43hm2.fsf@epam.com> <63f4841c-fb36-40c4-b96e-4a1aed95fbda@epam.com> <878q4r30wy.fsf@epam.com> In-Reply-To: (Oleksii Moisieiev's message of "Thu, 24 Sep 2026 07:54:17 +0000") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AMCPR03MB911417:EE_ x-ms-office365-filtering-correlation-id: d2752a90-8961-4c4a-acdb-08df1a6b8afb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|23010399003|376014|7416014|366016|1800799024|38070700021|3023799007|6133799003|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003; x-microsoft-antispam-message-info: Y//aZ92AN8TZx+kOobAe+xmnMExb6KhEejRYH8RUDD+TswDcsWB78eSMHOshZaPiBdiBxDHe7JhePm9FjRYP7p1JqyL9i4HjykDBBvg+UVwQwF4YRuQ33XX7MJVUuxJ5aM8dtTJ6hy/5H7vxcPQ/mJn6499KjZBnUgJdyoWLhwMPM/wrUoWzb1x+IAsJ83FB+Nu2VfD4uCn7CxK2kcRSqyeZseFWaiWTwFLrRmku7GnzMrF/GWi3k9nTI/XVKUF88VJ16i/KqOCQF4l3DybUZklQl5WmIfKkd+hawdHmkUNNso9S7UIVq6qkvOD/tpA6mYtf/2lIhGqMiXtqdMqbMQDDwgEOmsqEhfeHxQU1ZM3pdHv9HOZIfd8Emc9xasJqKYE+4WrbPLrY1EpJOGTjRNDxyA9TN2K0RSRKGxlGpC26BSbFLPT7yuBdjWMOrdGfa4Dx1gWhd+5V08MIEVXaohXdQ6qtrXzJBWAQaR/v4JUTSxCcQ0ptV+F+nhCItr7XE5aljm+ykwApH8B/2Mk1tr0cpVLYPqGa++rJogqDxc+dCPRUKBjt1Np+jfIYKeOkBHf2ImxyaGAFoNMhfuCqNDrzwT9mPHDGQSiPjhIzRVNN7nfj3u5QDZVBHvs4aPRBATCqp8Ttl165mX6Kr81r55GNwa0Zb3QxL5ICNP/ON2WU8bE3P2IYIenn3rwTKWNmVONN6DfZN6cfuGrX3XEvd+O50PQdXsOH30U3xdMtl80= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(23010399003)(376014)(7416014)(366016)(1800799024)(38070700021)(3023799007)(6133799003)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bE9XK1dNVisxM1pMb21ndmwxamx4UjFnYUNCbmwxQzV0dlo1aHBUdlpEazVs?= =?utf-8?B?cDMwRk1DSUtzYllTWWVMRk5FOGVXTE5HZmhKT0dpdFhvaURaTGFoR1FFOW5y?= =?utf-8?B?TEZOVmh5RkFxeERXVEtqbXIvQ1p2UnNIczNXbDlEU1JxQWZoSjR4cEFWaUUy?= =?utf-8?B?TGNMUVVoU3l4anFyamJmRXdsSHZUVXNnM2xEdEVRa0N2Zmtxbm5OSVBNd1V2?= =?utf-8?B?SHFMWDZLTURnR2ZGRUFvenFkV1hkQnF4NGcrQzFoSXBlekJ4L0pPcGtneFNO?= =?utf-8?B?WUZ3NFgxeEtrYTZRWGZTTzlkcEhBRjFBSktlZE1JK01qd085cmc2c0VhV2Rh?= =?utf-8?B?WmEyTUxqcTdzYy9tOTBLTlc4TVN4cjEya0hnQzFRRlY3M3ExYUprQXBzUDVG?= =?utf-8?B?VkVoTStSbUVrMFJMY1FlZDZUbmdoemp4aC9LV0o3TURNMEQxV0ZZSVZPNXRn?= =?utf-8?B?Umsyd3NMamxyWHZYZ1Z6bng2Q3dMRVV1Uzg0Wks5ZHBDbmVKdWljRy8zbkpv?= =?utf-8?B?TkcrdVl3LzlxT09uK2xFUjduK29YbjNTK0dha1NaSlQyUWZETmlQWHR2ZmE4?= =?utf-8?B?a2xjdjk2ZUpReVpWUHEwbFVSb3dPU3ZGSTFJRUtidUxkZlFnMmxyYW1CZENB?= =?utf-8?B?OXhaRm1JTWpDbnFveE9MVVBzenErVzJUYVJaaFZTaWR3RVVMbzg5aENGQmVU?= =?utf-8?B?aWdDYXJYZmRsQkxxaGZkajlZU01RMGRrRlRMaVo5OXB1Si9wT01NYTRGeFVP?= =?utf-8?B?ZTBpbzV2Z0EzTktEeHJzc0xBQWNRQmlGWkpEQVN1TGlpM0xsdW9hUUsyYjdu?= =?utf-8?B?MkRxbWZRZEdWdEJESWgzaUNIZVVTcSsyVGZvdlVMaGloNFhtbmVuazM5Z2sy?= =?utf-8?B?Q3V4OENhT2xGem1hYUwrOXJ0TzJxcWVGYWhiakFqcDFKSG5pcVZ2Qnh0MTBm?= =?utf-8?B?VUxmY2FtdXAraHd0S2FKakMxN2RZT1Z6c21qRW9qTjIyaHd5b3NVeVZTa2tN?= =?utf-8?B?QmdMdnFqNTg5OFNPM2xYeEw0Q3pvMGM4MzBlcjI3T0hqemk1RU5hclJGTStD?= =?utf-8?B?SXhaTVJYWnpIcEoxNGk3ZEU4b0NjYW4rR0NKODdjeHlBeVRzWnR4Wm9venVP?= =?utf-8?B?ZWRtZDZTaEM5V2Eyc010SC9uRy80SEV4L09KdkVuMEV6UXVucVNTVU9VVkNm?= =?utf-8?B?bFJ6eGFPbHJ0SnZhU0JmaWZoVG5oc3U2Y0ZkWGh1Z2wyTmJYcHBiTHk5Rkt5?= =?utf-8?B?U1ZPU0hnMFhjdTVDKzl4U1lvY0JmSXJhaFRDQit3N0lUY1lOaGhuUkpwWDBx?= =?utf-8?B?bG5vN2JsSGJiL0FoeDEyNDJFUzhmdXVaZVdpUEdKSVEyUk1SMWJiVWpra3pI?= =?utf-8?B?bTAwTWhrRWd4cXFHRHBrUWUvK3VnclNSMUxQbGRSQnpYVzdYbytEVGhLcU5Z?= =?utf-8?B?VEhuZU1TbjZOckwwRnJMK3JxaUdlVlpJTlJpbFZ2ZlJGM2JEemo4cXJMV0Z4?= =?utf-8?B?bS9GVkV1UTg5TjNpMFJvSnJLaTcreXcrSnhFczAvSnMwdnBOem1sdU9HczU4?= =?utf-8?B?MXYrOHhJNmdLeEswb3FOZWF3QlFkbEJBRmpndGxPRTFtY3NoNURjblpzd1hh?= =?utf-8?B?eSt4L0tsNjd3Nm9zYjBIVHFjWWgzNVNaK0pqOStMSkNjRjFVaUZTVzVJZll1?= =?utf-8?B?d3ZaTWsvVXhsWEVqVFFqM3hyTGpOeEZMNEc3WXRXd1lWbTNjLzN1QWpCMUZT?= =?utf-8?B?MzNXejB3eHVBYkFTZWVoK29XblVHYW5EZTVWcGFTWTRMTmNaRW8rTnZHTzJz?= =?utf-8?B?MWZVOGFKbzk4Q29nVVU2cVJYWDRzdFpOVlZIRWs5WmFjRHdGQWpnUFBYS3Ry?= =?utf-8?B?b3FZWE8zeWVFNUZLYkZJcytlZWVsTlF1R08rVlJLMjFoZzNJN0dvZlkrN1VI?= =?utf-8?B?M1ZhOHNneDltVnR4a0w2TjdEb1RpRmxKeVlGc3lSeXMyS2Q4ME9sNktzbDJW?= =?utf-8?B?T3lMYVNCV2F4aDdaZzhVM3RnbUpyZEI5bFZHdmlxWnhwcjd0SDZ5cm1Ma2gy?= =?utf-8?B?QjVkMHk3Vi9OSWJUTFVUem16NFM3djQySzZpY2E1OTNSWU94UDNBcHpkbGsw?= =?utf-8?B?VXFkVkJVS3BHS3BMeHJ5N3lWRU1wOUx0ZEpsanRXMm9xOHJtWFhiYVdyRld1?= =?utf-8?B?U29zeFRZZEtOay9NSUV4bmNuUHgzWFVkaVY3bkg4RFZaMVM2dHJ1UDY2Nk84?= =?utf-8?B?WGRZLys0cTV3ZTdXZ2tqZ2E5L2Nyc3o2aU43Z2tEMm9La3lLd2hzQUlhdk5Y?= =?utf-8?B?V0FpcWJOU3FtL0xOMkJBWWNQWG1OY21HYkpGOWZmZFNZWDRGc2xqeW1CWW9C?= =?utf-8?Q?ury7fS8YYa/JXnWY=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2752a90-8961-4c4a-acdb-08df1a6b8afb X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2026 18:42:10.5078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LKkYLVUbZy04vaOGVD2t16LCNIZI+zc54fs7CfbaAmuTSAef0JvHj0dhMqPoI4ZHE9WKmXenYhlNXJin5eRy+HtqD2oRrY7XyrlwS6Y3iwE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMCPR03MB911417 X-purgate-ID: tlsNG-4011c0/1790275333-530D9CFC-D79206A5/0/0 X-purgate-type: clean X-purgate-size: 20264 SGkgT2xla3NpaSwNCg0KT2xla3NpaSBNb2lzaWVpZXYgPE9sZWtzaWlfTW9pc2llaWV2QGVwYW0u Y29tPiB3cml0ZXM6DQoNCj4gT24gMjQvMDkvMjAyNiAwNDoxNSwgVm9sb2R5bXlyIEJhYmNodWsg d3JvdGU6DQo+PiBIaSBPbGVrc2lpLA0KPj4NCj4+IE9sZWtzaWkgTW9pc2llaWV2IDxPbGVrc2lp X01vaXNpZWlldkBlcGFtLmNvbT4gd3JpdGVzOg0KPj4NCj4+PiBPbiAyMy8wOS8yMDI2IDA0OjAy LCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4+Pj4gSGkgT2xla3NpaSwNCj4+Pj4NCj4+Pj4g T2xla3NpaSBNb2lzaWVpZXYgPE9sZWtzaWlfTW9pc2llaWV2QGVwYW0uY29tPiB3cml0ZXM6DQo+ Pj4+DQo+Pj4+IFRoaXMgaXMgYSBncmVhdCBwaWVjZSBvZiBkb2N1bWVudGF0aW9uLiBJdCBpcyBs YXJnZXIgdGhhbiB0aGUgdGV4dCB5b3UNCj4+Pj4gYWRkZWQgdG8gdGhlICdkb2MnIGRpcmVjdG9y eS4gU28gSSBiZWxpZXZlIGl0IGlzIGJldHRlciB0byBwdXQgaW50byBhDQo+Pj4+IGRlc2lnbiBk b2N1bWVudCwgc28gaXQgaXMgd2lsbCBub3QgYmUgbG9zdCBpbiB0aGUgZ2l0IGNvbW1pdCBtZXNz YWdlcy4NCj4+PiBIaSBWb2xvZHlteXIsDQo+Pj4NCj4+PiBUaGFuayB5b3UgZm9yIGEgcXVpY2sg cmVzcG9uc2UuDQo+Pj4NCj4+PiBJJ3ZlIGp1c3QgcmVjaGVrZWQgZG9jdW1lbnQgaW4gcGF0Y2gg NjoNCj4+PiBkb2NzL2h5cGVydmlzb3ItZ3VpZGUvYXJtL2Zpcm13YXJlL2FybS1zY21pLnJzdCBh bmQNCj4+Pg0KPj4+IGNvbXBhcmVkIGl0IHdpdGggdGhlIGluZm9ybWF0aW9uIHByb3ZpZGVkIGlu IHRoZSBjb21taXQgZGVzY3JpcHRpb24uDQo+Pj4NCj4+PiBBcyBJIGNhbiBzZWUgYWxsIGluZm9y bWF0aW9uIHByb3ZpZGVkIGluIHRoZSBkZXNjcmlwdGlvbiAoYWRkIHNjaGVtZXMNCj4+PiBhbmQg ZHRzIGV4YW1wbGVzIGF0IGxlYXN0KQ0KPj4+DQo+Pj4gYXJlIHByZXNlbnQgaW4gdGhlIGRvY3Vt ZW50YXRpb24uIEFsc28gZG9jIGl0c2VsZiBpcyBtb3JlIGRldGFpbGVkIHRoZW4NCj4+PiB0aGUg Y29tbWl0IGRlc2NyaXB0aW9uLg0KPj4+DQo+Pj4gTWF5YmUgSSBtaXNzZWQgc29tZXRoaW5nPw0K Pj4gQWgsIHNvIHlvdSBwdXQgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUgbGFzdCBwYXRjaCBpbiB0 aGUgc2VyaWVzLiBPa2F5LA0KPj4gc28gSSBtaXNzZWQgaXQuDQo+Pg0KPj4+Pj4gVGhpcyBwYXRj aCBpbnRyb2R1Y2VzIFNDSSBkcml2ZXIgdG8gc3VwcG9ydCBmb3IgQVJNIEVMMyBUcnVzdGVkIEZp cm13YXJlLUENCj4+Pj4+IChURi1BKSB3aGljaCBwcm92aWRlcyBTQ01JIGludGVyZmFjZSB3aXRo IG11bHRpLWFnZW50IHN1cHBvcnQsIGFzIHNob3duDQo+Pj4+PiBiZWxvdy4NCj4+Pj4+DQo+Pj4+ PiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4g ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+ICAg ICB8IEVMMyBURi1BIFNDTUkgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+PiAgICAg Ky0tLS0tLS0rLS0rLS0tLS0tLSstLSstLS0tLS0tKy0tKy0tLS0tLS0rKw0KPj4+Pj4gICAgIHxz aG1lbTEgfCAgfHNobWVtMCB8ICB8c2htZW0yIHwgIHxzaG1lbVggfA0KPj4+Pj4gICAgICstLS0t LSstKyAgKy0tLSstLS0rICArLS0rLS0tLSsgICstLS0rLS0tKw0KPj4+Pj4gc21jLWlkMSB8ICAg ICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4+Pj4gYWdlbnQxICB8ICAgICAgICB8ICAg ICAgICAgfCAgICAgICAgICAgfA0KPj4+Pj4gICAgICstLS0tLXYtLS0tLS0tLSstLS0tLS0tLS0r LS0tLS0tLS0tLS0rLS0tLSsNCj4+Pj4+ICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgfCAg ICAgICAgICAgfCAgICB8DQo+Pj4+PiAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAg ICAgICAgIHwgICAgfA0KPj4+Pj4gICAgICstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0t LS0tLS0rLS0tLSsNCj4+Pj4+ICAgICAgICAgICAgc21jLWlkMCB8ICBzbWMtaWQyfCAgICBzbWMt aWRYfA0KPj4+Pj4gICAgICAgICAgICBhZ2VudDAgIHwgIGFnZW50MiB8ICAgIGFnZW50WCB8DQo+ Pj4+PiAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwNCj4+Pj4+ICAg ICAgICAgICAgICAgKy0tLS12LS0tKyAgKy0tdi0tLS0tKyAgKy0tdi0tLS0tKw0KPj4+Pj4gICAg ICAgICAgICAgICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+Pj4+PiAgICAg ICAgICAgICAgIHwgRG9tMCAgIHwgIHwgRG9tMSAgIHwgIHwgRG9tWCAgIHwNCj4+Pj4+ICAgICAg ICAgICAgICAgfCAgICAgICAgfCAgfCAgICAgICAgfCAgfCAgICAgICAgfA0KPj4+Pj4gICAgICAg ICAgICAgICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+Pj4+PiAgICAgICAg ICAgICAgICstLS0tLS0tLSsgICstLS0tLS0tLSsgICstLS0tLS0tLSsNCj4+Pj4+DQo+Pj4+PiBU aGUgRUwzIFNDTUkgbXVsdGktYWdlbnQgZmlybXdhcmUgaXMgZXhwZWN0ZWQgdG8gcHJvdmlkZSBT Q01JIFNNQyBzaGFyZWQNCj4+Pj4+IG1lbW9yeSB0cmFuc3BvcnQgZm9yIGV2ZXJ5IEFnZW50IGlu IHRoZSBzeXN0ZW0uDQo+Pj4+Pg0KPj4+Pj4gVGhlIFNDTUkgQWdlbnQgdHJhbnNwb3J0IGNoYW5u ZWwgZGVmaW5lZCBieSBwYWlyOg0KPj4+Pj4gICAgLSBzbWMtaWQ6IFNNQyBpZCB1c2VkIGZvciBE b29yYmVsbA0KPj4+Pj4gICAgLSBzaG1lbTogc2hhcmVkIG1lbW9yeSBmb3IgbWVzc2FnZXMgdHJh bnNmZXIsIFhlbiBwYWdlDQo+Pj4+PiAgICBhbGlnbmVkLiBTaGFyZWQgbWVtb3J5IGlzIG1hcHBl ZCB3aXRoIHRoZSBmb2xsb3dpbmcgZmxhZ3M6DQo+Pj4+PiAgICBNVF9ERVZJQ0VfbkduUkUuDQo+ Pj4+Pg0KPj4+Pj4gVGhlIGZvbGx3b2luZyBTQ01JIEFnZW50cyBhcmUgZXhwZWN0ZWQgdG8gYmUg ZGVmaW5lZCBieSBTQ01JIEZXIHRvIGVuYWJsZSBTQ01JDQo+Pj4+PiBtdWx0aS1hZ2VudCBmdW5j dGlvbmFsaXR5IHVuZGVyIFhlbjoNCj4+Pj4+IC0gWGVuIG1hbmFnZW1lbnQgYWdlbnQ6IHRydXN0 ZWQgYWdlbnRzIHRoYXQgYWNjZXNzZXMgdG8gdGhlIEJhc2UgUHJvdG9jb2wNCj4+Pj4+IGNvbW1h bmRzIHRvIGNvbmZpZ3VyZSBhZ2VudCBzcGVjaWZpYyBwZXJtaXNzaW9ucw0KPj4+Pj4gLSBPU1BN IFZNIGFnZW50czogbm9uLXRydXN0ZWQgYWdlbnQsIG9uZSBmb3IgZWFjaCBHdWVzdCBkb21haW4g d2hpY2ggaXMNCj4+Pj4+ICAgICBhbGxvd2VkIGRpcmVjdCBIVyBhY2Nlc3MuIEF0IGxlYXN0IG9u ZSBPU1BNIFZNIGFnZW50IGhhcyB0byBiZSBwcm92aWRlZA0KPj4+Pj4gICAgIGJ5IEZXIGlmIEhX IGlzIGhhbmRsZWQgb25seSBieSBEb20wIG9yIERyaXZlciBEb21haW4uDQo+Pj4+Pg0KPj4+Pj4g VGhlIEVMMyBTQ01JIEZXIGlzIGV4cGVjdGVkIHRvIGltcGxlbWVudCBmb2xsb3dpbmcgQmFzZSBw cm90b2NvbCBtZXNzYWdlczoNCj4+Pj4+IC0gQkFTRV9ESVNDT1ZFUl9BR0VOVCAob3B0aW9uYWwg aWYgYWdlbnRfaWQgd2FzIHByb3ZpZGVkKQ0KPj4+Pj4gLSBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJ R1VSQVRJT04gKG9wdGlvbmFsKQ0KPj4+Pj4gLSBCQVNFX1NFVF9ERVZJQ0VfUEVSTUlTU0lPTlMg KG9wdGlvbmFsKQ0KPj4+Pj4NCj4+Pj4+IFRoZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJp dmVyIGltcGxlbWVudHMgZm9sbG93aW5nDQo+Pj4+PiBmdW5jdGlvbmFsaXR5Og0KPj4+Pj4gLSBU aGUgZHJpdmVyIGlzIGluaXRpYWxpemVkIGZyb20gdGhlIFhlbiBTQ01JIGNvbnRhaW5lciBgYHhl bl9zY21pX2NvbmZpZ2BgDQo+Pj4+PiAgICAgKGNvbXBhdGlibGUgYGB4ZW4sc2NpYGApIHBsYWNl ZCB1bmRlciBgYC9jaG9zZW4veGVuYGAuIE9ubHkgdGhlDQo+Pj4+PiAgICAgYGBhcm0sc2NtaS1z bWNgYCBub2RlIHRoYXQgaXMgYSBjaGlsZCBvZiB0aGlzIGNvbnRhaW5lciB3aWxsIGJpbmQgdG8g WGVuOw0KPj4+Pj4gICAgIG90aGVyIFNDTUkgbm9kZXMgKGZvciBleGFtcGxlIHVuZGVyIGBgL2Zp cm13YXJlYGApIGFyZSBpZ25vcmVkIHRvIGF2b2lkDQo+Pj4+PiAgICAgc3RlYWxpbmcgdGhlIGhv c3QgT1NQTSBpbnN0YW5jZS4NCj4+Pj4+DQo+Pj4+PiBzY21pX3NobV8xOiBzcmFtQDQ3ZmYxMDAw IHsNCj4+Pj4+ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+ Pj4gICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEwMDA+Ow0KPj4+Pj4g fTsNCj4+Pj4+IHNjbWlfeGVuOiBzY21pIHsNCj4+Pj4+ICAgICAgICAgICBjb21wYXRpYmxlID0g ImFybSxzY21pLXNtYyI7DQo+Pj4+PiAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAz PjsgPC0tLSBYZW4gbWFuYWdlbWVudCBhZ2VudCBzbWMtaWQNCj4+Pj4+ICAgICAgICAgICAjYWRk cmVzcy1jZWxscyA9IDwgMT47DQo+Pj4+PiAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8IDA+Ow0K Pj4+Pj4gICAgICAgICAgICNhY2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwgMT47DQo+Pj4+PiAg ICAgICAgICAgc2htZW0gPSA8JnNjbWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50 IHNobWVtDQo+Pj4+PiB9Ow0KPj4+Pj4NCj4+Pj4+IC0gVGhlIGRyaXZlciBvYnRhaW5zIFhlbiBz cGVjaWZpYyBTQ01JIEFnZW50J3MgY29uZmlndXJhdGlvbiBmcm9tIHRoZQ0KPj4+Pj4gICAgIEhv c3QgRFQsIHByb2JlcyBBZ2VudHMgYW5kIGJ1aWxkcyBTQ01JIEFnZW50cyBsaXN0LiBUaGUgQWdl bnRzDQo+Pj4+PiAgICAgY29uZmlndXJhdGlvbiBpcyB0YWtlbiBmcm9tICJzY21pLXNlY29uZGFy eS1hZ2VudHMiIHByb3BlcnR5IHdoZXJlDQo+Pj4+PiAgICAgZmlyc3QgaXRlbSBpcyAiYXJtLHNt Yy1pZCIsIHNlY29uZCAtICJhcm0sc2NtaS1zaG1lbSIgcGhhbmRsZSBhbmQNCj4+Pj4+ICAgICB0 aGlyZCBpcyBvcHRpb25hbCAiYWdlbnRfaWQiOg0KPj4+Pj4NCj4+Pj4+IC8gew0KPj4+Pj4gICAg IGNob3NlbiB7DQo+Pj4+PiAgICAgICB4ZW4gew0KPj4+Pj4gICAgICAgICByYW5nZXM7DQo+Pj4+ PiAgICAgICAgIHhlbl9zY21pX2NvbmZpZyB7DQo+Pj4+PiAgICAgICAgICAgY29tcGF0aWJsZSA9 ICJ4ZW4sc2NpIjsNCj4+Pj4+ICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwyPjsNCj4+Pj4+ ICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwyPjsNCj4+Pj4+ICAgICAgICAgICByYW5nZXM7DQo+ Pj4+Pg0KPj4+Pj4gCXNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCj4+Pj4+ICAgICAgICAgICAg IDB4ODIwMDAwMDIgJnNjbWlfc2htXzAgMA0KPj4+Pj4gICAgICAgICAgICAgMHg4MjAwMDAwNCAm c2NtaV9zaG1fMiAyDQo+Pj4+PiAgICAgICAgICAgICAweDgyMDAwMDA1ICZzY21pX3NobV8zIDM+ OyA8LS0tIGZ1bmNfaWQsIHNobWVtLCBhZ2VudF9pZA0KPj4+Pj4gICAgICAgICAgICNzY21pLXNl Y29uZGFyeS1hZ2VudHMtY2VsbHMgPSA8Mz47DQo+Pj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlz IGlzIHRoZSBjb3JyZWN0IHdheSBvZiB1c2luZyAtY2VsbHMgcHJvcGVydHkuDQo+Pj4+DQo+Pj4+ IFRoZXNlIHByb3BlcnRpZXMgYXJlIHVzZWQgZWl0aGVyIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24g Zm9yICoqY2hpbGQqKiBub2Rlcw0KPj4+PiAobGlrZSAjYWRkcmVzcy1jZWxscyBvciAjc2l6ZS1j ZWxscykgb3IgdG8gcHJvdmlkZSBhIG51bWJlciBvZiBjZWxscyB0bw0KPj4+PiBlbmNvZGUgYSBz cGVjaWZpZXIgZm9yIGEgZG9tYWluIChsaWtlICNpbnRlcnJ1cHQtY2VsbHMpLg0KPj4+Pg0KPj4+ PiBIZXJlIHlvdSBhcmUgZG9pbmcgbmVpdGhlciBvZiB0aGVzZS4gSSB0aGluayB0aGUgcHJvcGVy IHdheSBpcyB0byBkZWZpbmUNCj4+Pj4gc2Vjb25kYXJ5IGFnZW50cyBhcyBjaGlsZHJlbjoNCj4+ Pj4NCj4+Pj4gYWdlbnRzIHsNCj4+Pj4gICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gMTsNCj4+ Pj4gICAgICAgICAgICNzaXplLWNlbGxzID0gMDsNCj4+Pj4gICAgICAgICAgICBzY21pX2FnZW50 XzI6IHNjbWlfYWdlbnRAMiB7DQo+Pj4+ICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz Y21pLWFnZW50IjsgIC8vIEFjdHVhbGx5LCBJIGFtIG5vdCBzdXJlIGlmDQo+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIHdlIGFsbG93ZWQgdG8gdXNl ICdhcm0nIG5hbWVzcGFjZQ0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgcmVnID0gPDI+OyAgICAg ICAgICAgICAgICAgICAgICAvLyBBZ2VudCBpZCBnb2VzIGhlcmUNCj4+Pj4gICAgICAgICAgICAg IHNobW1lbSA9ICZzY21pX3NobV8yOw0KPj4+PiAgICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDB4 ODIwMDAwMDQ7DQo+Pj4+ICAgICAgICAgICAgfTsNCj4+Pj4gfQ0KPj4+Pg0KPj4+PiBXaXRoIHRo aXMgYXBwcm9hY2ggeW91IGRvbid0IG5lZWQgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyBh dCBhbGwNCj4+Pj4gYW5kIHRoZSB3aG9sZSBzdHJ1Y3R1cmUgYmVjb21lcyBtb3JlIGRldmljZS10 cmVlLWlzaC4NCj4+PiBUaGFuayB5b3UgZm9yIGxvb2tpbmcgYXQgdGhpcy4gSSBhZ3JlZSB0aGF0 IHRoZSB0d28gY2FzZXMgeW91IGxpc3QgYXJlDQo+Pj4gdGhlIG1vc3QgY29tbW9uIG9uZXMsIGJ1 dCB0aGV5IGFyZSBub3QgdGhlIG9ubHkgc2FuY3Rpb25lZCBvbmVzOiB0aGVyZSBpcyBhDQo+Pj4g dGhpcmQsIGxvbmctc3RhbmRpbmcgcGF0dGVybiB3aGVyZSBhICIjPG5hbWU+LWNlbGxzIiBwcm9w ZXJ0eSBpbiBhIG5vZGUNCj4+PiBkZWNsYXJlcyB0aGUgY2VsbCBzdHJpZGUgb2YgYSAqbm9uLXBo YW5kbGUgbGlzdCBwcm9wZXJ0eSBpbiB0aGF0IHZlcnkgc2FtZQ0KPj4+IG5vZGUqLiBUaGF0IGlz IGV4YWN0bHkgd2hhdCAiI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyIgZG9lcyBmb3INCj4+ PiAic2NtaS1zZWNvbmRhcnktYWdlbnRzIi4gU29tZSBldmlkZW5jZSBmcm9tIHRoZSBEZXZpY2V0 cmVlIFNwZWNpZmljYXRpb24gYW5kDQo+Pj4gZnJvbSBMaW51eDoNCj4+Pg0KPj4+IDEpICJyYW5n ZXMiIGFuZCAiaW50ZXJydXB0LW1hcCIgYXJlIHBhcnNlZCB3aXRoIHRoZSBjZWxsIGNvdW50cyBv ZiB0aGUgbm9kZQ0KPj4+ICAgwqAgwqB0aGF0IGNhcnJpZXMgdGhlbSwgbm90IG9mIGEgY2hpbGQg b3Igb2YgYSBwaGFuZGxlIHRhcmdldC4NCj4+Pg0KPj4+ICAgwqAgwqBkdGMgZW5mb3JjZXMgdGhp cyBpdHNlbGY6DQo+Pj4NCj4+PiAgIMKgIMKgLSBzY3JpcHRzL2R0Yy9jaGVja3MuYzo3ODUgY2hl Y2tfcmFuZ2VzX2Zvcm1hdCgpIGNvbXB1dGVzIHRoZSBlbnRyeQ0KPj4+IGxlbmd0aA0KPj4+ICAg wqAgwqAgwqBhcyAocGFyZW50ICNhZGRyZXNzLWNlbGxzICsgdGhpcyBub2RlJ3MgI2FkZHJlc3Mt Y2VsbHMgKyB0aGlzIG5vZGUncw0KPj4+ICAgwqAgwqAgwqAjc2l6ZS1jZWxscykgYW5kIHZhbGlk YXRlcyB0aGUgbGVuZ3RoIG9mICJyYW5nZXMiIGluIHRoaXMgbm9kZQ0KPj4+IGFnYWluc3QgaXQu DQo+Pj4NCj4+PiAgIMKgIMKgLSBzY3JpcHRzL2R0Yy9jaGVja3MuYzoxNjAxIGNoZWNrX2ludGVy cnVwdF9tYXAoKToNCj4+Pg0KPj4+ICAgwqAgwqAgwqAgwqAgwqBjZWxsc2l6ZSA9IG5vZGVfYWRk cl9jZWxscyhub2RlKTsNCj4+PiAgIMKgIMKgIMKgIMKgIMKgY2VsbHNpemUgKz0gcHJvcHZhbF9j ZWxsKGdldF9wcm9wZXJ0eShub2RlLCAiI2ludGVycnVwdC1jZWxscyIpKTsNCj4+Pg0KPj4+ICAg wqAgwqAgwqBpLmUuIHRoZSBzdHJpZGUgb2YgdGhlICJpbnRlcnJ1cHQtbWFwIiBlbnRyaWVzIGlu IGEgbm9kZSBpcyB0YWtlbiBmcm9tDQo+Pj4gICDCoCDCoCDCoCIjYWRkcmVzcy1jZWxscyIgYW5k ICIjaW50ZXJydXB0LWNlbGxzIiAqb2YgdGhhdCBzYW1lIG5vZGUqLiBMaW51eA0KPj4+IGRvZXMN Cj4+PiAgIMKgIMKgIMKgdGhlIHNhbWUgaW4gZHJpdmVycy9vZi9pcnEuYy4NCj4+Pg0KPj4+ICAg wqAgwqBTbyAiYSAjKi1jZWxscyBwcm9wZXJ0eSBpbiBub2RlIFggZGVzY3JpYmluZyB0aGUgbGF5 b3V0IG9mIGEgcHJvcGVydHkgaW4NCj4+PiAgIMKgIMKgbm9kZSBYIiBpcyBub3QgYW4gYWJ1c2Ug b2YgdGhlIGNvbnZlbnRpb24sIGl0IGlzIGhvdyB0d28gb2YgdGhlIGNvcmUNCj4+PiAgIMKgIMKg RGV2aWNldHJlZSBTcGVjaWZpY2F0aW9uIHByb3BlcnRpZXMgYXJlIGRlZmluZWQuDQo+Pj4NCj4+ PiAyKSBUaGVyZSBpcyBhIHByZWNlZGVudCB3aG9zZSBzaGFwZSBpcyBpZGVudGljYWwgdG8gb3Vy cyAtIGEgdmVuZG9yIHByb3BlcnR5DQo+Pj4gICDCoCDCoGhvbGRpbmcgYSBsaXN0LCBwbHVzIGNl bGxzIHByb3BlcnRpZXMgaW4gdGhlIHNhbWUgbm9kZSB0aGF0IGRlc2NyaWJlDQo+Pj4gaG93IHRv DQo+Pj4gICDCoCDCoGRlY29kZSBpdDoNCj4+Pg0KPj4+ICAgwqAgwqBEb2N1bWVudGF0aW9uL2Rl dmljZXRyZWUvYmluZGluZ3MvdHBtL2libSx2dHBtLnlhbWw6MzYNCj4+Pg0KPj4+ICAgwqAgwqAg wqAgwqBpYm0sI2RtYS1hZGRyZXNzLWNlbGxzOg0KPj4+ICAgwqAgwqAgwqAgwqAgwqBkZXNjcmlw dGlvbjoNCj4+PiAgIMKgIMKgIMKgIMKgIMKgIMKgbnVtYmVyIG9mIGNlbGxzIHRoYXQgYXJlIHVz ZWQgdG8gZW5jb2RlIHRoZSBwaHlzaWNhbCBhZGRyZXNzDQo+Pj4gZmllbGQNCj4+PiAgIMKgIMKg IMKgIMKgIMKgIMKgb2YgZG1hLXdpbmRvdyBwcm9wZXJ0aWVzDQo+Pj4gICDCoCDCoCDCoCDCoGli bSwjZG1hLXNpemUtY2VsbHM6DQo+Pj4gICDCoCDCoCDCoCDCoCDCoGRlc2NyaXB0aW9uOg0KPj4+ ICAgwqAgwqAgwqAgwqAgwqAgwqBudW1iZXIgb2YgY2VsbHMgdGhhdCBhcmUgdXNlZCB0byBlbmNv ZGUgdGhlIHNpemUgZmllbGQgb2YNCj4+PiAgIMKgIMKgIMKgIMKgIMKgIMKgZG1hLXdpbmRvdyBw cm9wZXJ0aWVzDQo+Pj4gICDCoCDCoCDCoCDCoGlibSxteS1kbWEtd2luZG93Og0KPj4+ICAgwqAg wqAgwqAgwqAgwqBkZXNjcmlwdGlvbjogRE1BIHdpbmRvdyBhc3NvY2lhdGVkIHdpdGggdGhpcyB2 aXJ0dWFsIEkvTyBBZGFwdGVyDQo+Pj4NCj4+PiAgIMKgIMKgYW5kIHRoZSBleGFtcGxlIChzYW1l IGZpbGUsIGxpbmVzIDk2LTk4KToNCj4+Pg0KPj4+ICAgwqAgwqAgwqAgwqBpYm0sI2RtYS1hZGRy ZXNzLWNlbGxzID0gPDB4Mj47DQo+Pj4gICDCoCDCoCDCoCDCoGlibSwjZG1hLXNpemUtY2VsbHMg PSA8MHgyPjsNCj4+PiAgIMKgIMKgIMKgIMKgaWJtLG15LWRtYS13aW5kb3cgPSA8MHgxMDAwMDAw MyAweDAgMHgwIDB4MCAweDEwMDAwMDAwPjsNCj4+Pg0KPj4+ICAgwqAgwqBCb3RoIGNlbGxzIHBy b3BlcnRpZXMgYXJlICJyZXF1aXJlZCIuIFRoZSBwYXJzZXIgaXMNCj4+PiAgIMKgIMKgYXJjaC9w b3dlcnBjL2tlcm5lbC9wcm9tX3BhcnNlLmM6MTEgb2ZfcGFyc2VfZG1hX3dpbmRvdygpLCB3aGlj aCByZWFkcw0KPj4+ICAgwqAgwqAiaWJtLCNkbWEtYWRkcmVzcy1jZWxscyIgYW5kICJpYm0sI2Rt YS1zaXplLWNlbGxzIiBmcm9tIHRoZSBzYW1lDQo+Pj4gbm9kZSAiZG4iDQo+Pj4gICDCoCDCoHRv IHdhbGsgImlibSxteS1kbWEtd2luZG93Ii4gVGhlcmUgaXMgbm8gcGhhbmRsZSBhbmQgbm8gY2hp bGQgbm9kZQ0KPj4+ICAgwqAgwqBpbnZvbHZlZDsgdGhpcyBpcyBleGFjdGx5IHRoZSAic2VsZi1k ZXNjcmliaW5nIGxpc3QgcHJvcGVydHkiIHBhdHRlcm4uDQo+Pj4NCj4+PiAzKSBBICIjKi1jZWxs cyIgcHJvcGVydHkgZG9lcyBub3QgaGF2ZSB0byBkZXNjcmliZSBhIHBoYW5kbGUgc3BlY2lmaWVy DQo+Pj4gYXQgYWxsOg0KPj4+DQo+Pj4gICDCoCDCoC0gIiNwaW5jdHJsLWNlbGxzIiAoRG9jdW1l bnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3BpbmN0cmwvDQo+Pj4gICDCoCDCoCDCoHBpbmN0 cmwtc2luZ2xlLnlhbWw6NTUpIGdpdmVzIHRoZSBudW1iZXIgb2YgY2VsbHMgcGVyIGVudHJ5IG9m IHRoZQ0KPj4+IHBsYWluDQo+Pj4gICDCoCDCoCDCoCJwaW5jdHJsLXNpbmdsZSxwaW5zIiBwcm9w ZXJ0eTsgZHJpdmVycy9waW5jdHJsL2RldmljZXRyZWUuYzoyOTcNCj4+PiAgIMKgIMKgIMKgcGlu Y3RybF9maW5kX2NlbGxzX3NpemUoKSBsb29rcyBpdCB1cCBpbiB0aGUgcGFyZW50L2dyYW5kcGFy ZW50IG5vZGUuDQo+Pj4gICDCoCDCoCDCoE5vIHBoYW5kbGUgc3BlY2lmaWVyIGlzIGludm9sdmVk Lg0KPj4+DQo+Pj4gICDCoCDCoC0gIiNpbmRleC1jZWxscyINCj4+PiAoRG9jdW1lbnRhdGlvbi9k ZXZpY2V0cmVlL2JpbmRpbmdzL3VzYi9mc2wsdXNibWlzYy55YW1sOjU2KQ0KPj4+ICAgwqAgwqAg wqBpcyBub3QgYSBzcGVjaWZpZXIgZm9yIGFueSBkb21haW4gZWl0aGVyLg0KPj4+DQo+Pj4gU28g dGhlIGNvbnZlbnRpb24gaW4gcHJhY3RpY2UgaXMgImEgIzxmb28+LWNlbGxzIHByb3BlcnR5IHN0 YXRlcyBob3cNCj4+PiBtYW55IGNlbGxzDQo+Pj4gb25lIDxmb28+IGVudHJ5IG9jY3VwaWVzIiwg YW5kIHRoZSBlbnRyaWVzIG1heSBsaXZlIGluIGEgY2hpbGQgbm9kZSdzDQo+Pj4gcHJvcGVydHkN Cj4+PiAoI2FkZHJlc3MtY2VsbHMpLCBpbiBhIGNvbnN1bWVyJ3MgcGhhbmRsZSBzcGVjaWZpZXIg KCNpbnRlcnJ1cHQtY2VsbHMsDQo+Pj4gI2Nsb2NrLWNlbGxzKSwgb3IgaW4gYSBwcm9wZXJ0eSBv ZiB0aGUgZGVjbGFyaW5nIG5vZGUgaXRzZWxmIChyYW5nZXMsDQo+Pj4gaW50ZXJydXB0LW1hcCwg aWJtLG15LWRtYS13aW5kb3cpLiBPdXIgdXNhZ2UgZmFsbHMgaW50byB0aGUgdGhpcmQgZ3JvdXAu DQo+Pj4NCj4+PiBUaGlzIGJyaW5nIHVzIHRvIHRoZSBmb2xsb3dpbmcgY29uY2x1c2lvbiB0aGF0 DQo+Pj4gI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyB1c2FnZQ0KPj4+IGRvZXNuJ3QgdGVj aG5pY2FsbHkgYnJlYWsgdGhlIGRldmljZS10cmVlIGNvbnZlbnRpb24gd2l0aCAyIGV4Y2VwdGlv bnM6DQo+Pj4NCj4+PiBhKSBWZW5kb3IgcHJlZml4LiBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUv YmluZGluZ3Mvd3JpdGluZy1iaW5kaW5ncy5yc3Q6NjgNCj4+PiAgIMKgIMKgc2F5cyAiRE8gdXNl IGEgdmVuZG9yIHByZWZpeCBvbiBkZXZpY2Utc3BlY2lmaWMgcHJvcGVydHkgbmFtZXMiLCBhbmQg YWxsDQo+Pj4gICDCoCDCoHRoZSBzYW1lLW5vZGUgcHJlY2VkZW50cyBhYm92ZSBhcmUgdmVuZG9y LXByZWZpeGVkDQo+Pj4gKCJpYm0sI2RtYS1hZGRyZXNzLWNlbGxzIikuDQo+Pj4gICDCoCDCoEJv dGggb2Ygb3VyIHByb3BlcnRpZXMgYXJlIFhlbi1zcGVjaWZpYyBhbmQgbGl2ZSB1bmRlciAvY2hv c2VuL3hlbiwNCj4+PiBzbyBpZiB3ZQ0KPj4+ICAgwqAgwqBrZWVwIHRoZSBmbGF0IGZvcm0gdGhl eSBzaG91bGQgYmVjb21lICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIiBhbmQNCj4+PiAgIMKg IMKgInhlbiwjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzIi4NCj4+Pg0KPj4+IGIpIEVudHJ5 IGxheW91dC4gSW4gb3VyIGxpc3QgdGhlIHBoYW5kbGUgaXMgdGhlIHNlY29uZCBjZWxsDQo+Pj4g ICDCoCDCoCg8c21jLWlkICZzaG1lbSBhZ2VudC1pZD4pLCB3aGljaCBwcmV2ZW50cyB0aGUgdXNl IG9mIHRoZSBzdGFuZGFyZA0KPj4+ICAgwqAgwqBwaGFuZGxlLWFycmF5IGhlbHBlcnMgLSB0aGV5 IGFsbCBleHBlY3QgdGhlIHBoYW5kbGUgZmlyc3QuIElmIHdlDQo+Pj4ga2VlcCB0aGUNCj4+PiAg IMKgIMKgZmxhdCBmb3JtLCByZW9yZGVyaW5nIHRvIDwmc2htZW0gc21jLWlkIGFnZW50LWlkPiB3 b3VsZCBsZXQgdGhlDQo+Pj4gcHJvcGVydHkgYmUNCj4+PiAgIMKgIMKgcGFyc2VkIGFzIGFuIG9y ZGluYXJ5IHBoYW5kbGUtYXJyYXkuDQo+Pj4NCj4+PiBBcyBmb3IgeW91ciBwcm9wb3NhbDogdGhl IGNoaWxkLW5vZGUgZm9ybSB5b3Ugc3VnZ2VzdCBpcyBjZXJ0YWlubHkNCj4+PiBtb3JlIGlkaW9t YXRpYywgaXQgbWFrZXMgdGhlIGFnZW50IGlkIGFuIGFkZHJlc3NhYmxlICJyZWciIGFuZCBpdA0K Pj4+IHJlbW92ZXMgdGhlDQo+Pj4gb3B0aW9uYWwgMi12cy0zLWNlbGxzIHZhcmlhbnQgYWx0b2dl dGhlci4gTXkgb25seSByZXNlcnZhdGlvbnMgYXJlIHRoYXQNCj4+PiBpdCBncm93cw0KPj4+IHRo ZSBYZW4gRFQgcGFyc2VyIChub2RlIGl0ZXJhdGlvbiBpbnN0ZWFkIG9mIGEgc2luZ2xlIHByb3Bl cnR5IHdhbGspIGFuZA0KPj4+IHRoYXQgdGhlDQo+Pj4gY29tcGF0aWJsZSBzdHJpbmcgd291bGQg bmVlZCBhIG5hbWVzcGFjZSB3ZSBvd24gKCJ4ZW4sc2NtaS1hZ2VudCIgcmF0aGVyDQo+Pj4gdGhh bg0KPj4+ICJhcm0sc2NtaS1hZ2VudCIsIGFzIHlvdSBjb3JyZWN0bHkgc3VzcGVjdGVkKS4NCj4+ Pg0KPj4+IFNvIEkgZG8gbm90IHRoaW5rIHRoZSBjdXJyZW50IGZvcm0gaXMgaW52YWxpZCwgYnV0 IEkgaGF2ZSBubyBvYmplY3Rpb24gdG8NCj4+PiBtb3ZpbmcgdG8gY2hpbGQgbm9kZXMgaWYgeW91 IHByZWZlciBpdC4gUGxlYXNlIGxldCBtZSBrbm93IHdoaWNoIHdheSB5b3UNCj4+PiB3b3VsZA0K Pj4+IGxpa2UgbWUgdG8gZ28gZm9yIHYxNCBhbmQgSSB3aWxsIHJlc3BpbiBhY2NvcmRpbmdseS4N Cj4+IFllcywgSSB0aGluayBtb3JlIGlkaW9tYXRpYyBmb3JtYXQgaXMgYmV0dGVyLiBBbHNvLCB5 b3UgbmVlZCB0byB3cml0ZSBhDQo+PiBwYXJzZXIgb25jZSwgYnV0IHVzZXJzIHdpbGwgd3JpdGUg ZGV2aWNlIHRyZWUgbW9yZSBvZnRlbi4NCj4+DQo+PiBUaGUgc2Vjb25kIHRoaW5nIHRoYXQgYm90 aGVycyBtZSBpcyB0aGUgc2hhcmVkIG1lbW9yeSBub2RlcyBpbnNpZGUgdGhlDQo+PiB4ZW5fc2Nt aV9jb25maWcgbm9kZS4gSSBiZWxpZXZlIHRoZXkgc2hvdWxkIGJlbG9uZyB0byByZXNlcnZlZF9t ZW1vcnksIG5vPw0KPiBEdXJpbmcgZGlzY3Vzc2lvbnMgb24gdGhlIHByZXZpb3VzIHZlcnNpb25z LCBpdCB3YXMgZGVjaWRlZCB0aGF0IHRoZSANCj4gbWFpbiBnb2FsIGlzIHRvIGxlYXZlIHRoZSBv cmlnaW5hbCBkZXZpY2UtdHJlZSB1bnRvdWNoZWQgYW5kIHB1dCBhbGwgDQo+IFhlbi1yZWxhdGVk IGNvbnRlbnQgaW50byB0aGUgeGVuIG5vZGUuIFRoYXQncyB3aHkgd2UgcHJlc2VydmUgdGhlIA0K PiBvcmlnaW5hbCBEVFMgc3RydWN0dXJlLCBzdWNoIGFzIHRoZSBzY21pX3NobV8wIGFuZCAvZmly bXdhcmUvc2NtaSBub2Rlcy4NCj4NCj4gQWxzbywgaWYgeW91IHRha2UgYSBsb29rIGF0IHRoZSBh cm0sc2NtaS55YW1sIGZpbGUgaW4gdGhlIExpbnV4IGtlcm5lbCwgDQo+IHRoZXJlIGlzIG5vIGV4 cGxpY2l0IHJlcXVpcmVtZW50IHJlZ2FyZGluZyB0aGUgZXhhY3QgcGxhY2VtZW50IG9mIHRoZSAN Cj4gc2NtaS1zaG1lbSBub2RlLiBBcyBjYW4gYmUgc2VlbiwgYXJtLHNjbWktc2htZW0gaXMgcHJl c2VudCBpbiB0aGUgDQo+IHBhdHRlcm5Qcm9wZXJ0aWVzIG9mIHNyYW0ueWFtbCwgYnV0IHNvbWUg RFRTIGZpbGVzIHBsYWNlIGl0IGludG8gDQo+IHJlc2VydmVkLW1lbW9yeSBpbnN0ZWFkLg0KPg0K PiBNeSBtYWluIHBvaW50IGlzIHRoYXQgd2UgZG9uJ3QgdG91Y2ggdGhlIG9yaWdpbmFsIGRldmlj ZS10cmVlIOKAlCB3ZSANCj4gc2ltcGx5IGFkZCB0aGUgeGVuIG5vZGUgYW5kIHB1dCBhbGwgdGhl IHJlcXVpcmVkIHByb3BlcnRpZXMgaW5zaWRlIGl0Lg0KDQpPa2F5LCBidXQgWGVuIHNob3VsZCBr bm93IGFib3V0IHJlc2VydmVkIG1lbW9yeSwgcmlnaHQ/IFNvLCBpdCBpcyBvbmx5DQpmYWlyIHRv IGhhdmUgc2hhcmVkIG1lbW9yeSBub2RlcyBpbiAvcmVzZXJ2ZWQtbWVtb3J5LyBhcyBkZXZpY2Ug dHJlZQ0Kc3BlYyBzdWdnZXN0cy4NCg0KPiBJZiB3ZSB3ZXJlIHRvIHBsYWNlIHNobWVtIGludG8g c3JhbSBvciByZXNlcnZlZC1tZW1vcnksIGl0IHdvdWxkIGdpdmUgdXMgDQo+IHRoZSBmb2xsb3dp bmcgc3RydWN0dXJlOg0KPg0KPiAvIHsNCj4NCj4gIMKgIMKgIMKgeGVuIHsNCj4NCj4gIMKgIMKg IMKgIMKgIMKgPHNyYW18cmVzZXJ2ZWQtbWVtb3J5Pjogew0KPg0KPiAgwqAgwqAgwqAgwqAgwqAg wqAgwqBzY21pX3NobTAgLi4uDQo+DQo+ICDCoCDCoCDCoCDCoCDCoCDCoCAuLi4uDQo+DQo+ICDC oCDCoCDCoCDCoCDCoCDCoCBzY21pX3NobVggLi4uDQo+DQo+ICDCoCDCoCDCoCDCoCDCoH0NCj4N Cj4gIMKgIMKgIMKgfQ0KPg0KPiB9DQo+DQo+IFRoaXMgd291bGRuJ3QgcHJvdmlkZSBhbnkgYmVu ZWZpdCBidXQgd291bGQgb3ZlcmNvbXBsaWNhdGUgdGhlIA0KPiBkZXZpY2UtdHJlZSBzdHJ1Y3R1 cmUuIFdoYXQgZG8geW91IHRoaW5rPw0KDQpXZWxsLCB0aGVyZSBpcyBhbm90aGVyIGFyZ3VtZW50 IHdoeSBJIHdhbnQgdG8gbW92ZSBzaGFyZWQgbWVtb3J5IG5vZGVzDQpvdXQgb2YgeGVuX3NjbWlf Y29uZmlnLiBJbiB0aGF0IGNhc2Ugd2UgY2FuIGhhdmUgbW9yZSBmbGF0DQpzdHJ1Y3R1cmUuIFNv LCBpbnN0ZWFkIG9mDQoNCnhlbl9zY21pX2NvbmZpZyB7DQogICAgICAgICNhZGRyZXNzLWNlbGxz ID0gMjsNCiAgICAgICAgI3NpemUtY2VsbHMgPSAyOw0KDQogICAgICAgIHNobTEge307DQogICAg ICAgIHNobTIge307DQogICAgICAgIHNobU4ge307DQoNCiAgICAgICAgYWdlbnRzIHsNCiAgICAg ICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDE7DQogICAgICAgICAgICAgICAgI3NpemUtY2Vs bHMgPSAwOw0KICAgICAgICAgICAgICAgIGFnZW50MSB7fTsNCiAgICAgICAgICAgICAgICBhZ2Vu dDIge307DQogICAgICAgIH0NCn0NCg0KDQp3ZSBjb3VsZCBoYXZlDQoNCnhlbl9zY21pX2NvbmZp ZyB7DQogICAgICAgICNhZGRyZXNzLWNlbGxzID0gMTsNCiAgICAgICAgI3NpemUtY2VsbHMgPSAw Ow0KDQogICAgICAgIGFnZW50MSB7fTsNCiAgICAgICAgYWdlbnQyIHt9Ow0KfQ0KDQp3aGljaCBp cyBtb3JlIGlkaW9tYXRpYywgSU1PLg0KDQotLSANCldCUiwgVm9sb2R5bXly From xen-devel-bounces@lists.xenproject.org Thu Sep 24 18:55:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 18:55:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1432900.1653830 (Exim 4.92) (envelope-from ) id 1x9oay-00043B-Ab; Thu, 24 Sep 2026 18:55:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1432900.1653830; Thu, 24 Sep 2026 18:55:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9oay-000433-6m; Thu, 24 Sep 2026 18:55:00 +0000 Received: by outflank-mailman (input) for mailman id 1432900; Thu, 24 Sep 2026 18:54:59 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9oax-00042A-1w for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 18:54:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9oaw-00FW1d-Ev for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:54:58 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab571f8-2eae-0a2a0a5409dd-0a2a4508a342-18 for ; Thu, 24 Sep 2026 20:54:58 +0200 Received: from [74.125.229.205] (helo=mail-lf2-f13.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab57202-f659-0a2a45080019-4a7de5cdc70c-3 for ; Thu, 24 Sep 2026 20:54:58 +0200 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b8d879752fso125545e87.2 for ; Thu, 24 Sep 2026 11:54:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790276098; cv=none; d=google.com; s=arc-20260327; b=dzfAcTWRA9iad2obB4Q3R2xOkb24XEr7vITkHLi3cV4XfutX+Jp0IelOIng3NdK0iu JSlZuGuc/THdSNSuEAdgOWiuhj/IagBX4hOGIj+iyFKRGRwKThrqLrV62iOJtg5pztAb 8NZobjvzTahoTkg6sRKJzBsBU2n8giAt3e4yuTEQgi4GUI/N3x6B+/ihpL2IZ6RBbXU7 9vesfCwUy3TSBo9me+uTSvn14UT1C3bNx9uhwHXzWDbwK3D2rlxjVBYJ5otbhiJCcZCK D3KWws3sYek2K21VCXdCJ+cUUlzZkODqmMsaF1kafwAx9PeVptwp5LXIFX0POGzcDFzy up0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=PWAUwpPka71Oo5qcp6BYgkJIhV/r3ITppA9B+gt/k5U=; fh=RwOOD8FwKHtBBkobGpKkroeNqvZU5mMoUlw2sGgs4aY=; b=sAsN00f5z0cWW5MmPL2DxBZYG5oVznYX4jo12SQKtXrNKp+AHsgaqnrbUrxZJ/JrC3 om5QJiFpn9Nigdcc1pz2grOxXJYrQr+8v3T2k9KttD0R65PG9gYQmSMWmaec2o5lCYWH XvYrdhK4LhpAe2XfDEtUSlbh8YUvHmDX3BEJlBPw6I0+Zci6rIa6WX1JQ1fFmNt5884G IJyDvFPUIwL47RbuyrxsZMoeIEnUlPqdxZTkXhdy4U2j8eWP/MIvMgs3VH5rkBRZ6QTI fpm9uFqILEADNqlK8DnorTeps91sKsdW8z3x9o8geJjNc8HqjmmjFgM7HuBIMj4xl3ae nA4g==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790276098; x=1790880898; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=PWAUwpPka71Oo5qcp6BYgkJIhV/r3ITppA9B+gt/k5U=; b=lz6hE2fGKjAvIkvGOcCFM9s2bHfKRdUXUQE6kk15Z+4ey8oUv2FdC3vaPVdOumaYol WAG48gDc5m/FZ+aRbyRWNZW6klUnoz/6SEyIletcWaxvsOHu1ABxix997YRGmkWBiUb0 6dmvYJJutzeBIeZUA6uCNBZU44tXKjx3G0UhuvgvuPwnw5VzfbMewbNNNJf31bTeO89f xVEcPrhu+bA7p0AnJS/csRiVvyWxPS4XtUWlq2dMgrleJZLjPo3l2P8D9fyrWNCIa5VX dAWV9TCha/G9DXwJyG3RiIvee+vL/I7GSu4QBRX8M/6izVpGUGIOHPP8O1ByGIK4PBMM SEqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790276098; x=1790880898; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=PWAUwpPka71Oo5qcp6BYgkJIhV/r3ITppA9B+gt/k5U=; b=S/ztY5XvaH+Ga9HQhZpGvDCidNMRXA9rHwFuyCauKAKkJR4GMRIUssUQJs7slKBXM3 PKLcnQ/FiquTRqziLBmVZBXZrYR2P/F2avtrMMzCSlDXegLwtOyqljjTDhk2rDJvBUpP TIIa2Qqnv83H4IZIU+4QsX1SU3kzMKA8a9lR5COHL+ZbGzDOvyx91ZRawOa6reE3kIBV jq4sYL/5C3wYpK6t5AZ9mxdLrLjKrZYEGFAakvvq5XphgaDyxX/WEIxVMIJCUY0VidRd h8V2m6eJcvdjJOeSlvCUwpX+QmWHXcbEoYdprGgmM0E8TkEuhckUlDLmAq8uZ2buWh/z NqSg== X-Gm-Message-State: AFuF++kMKov9asS1vbk+6vAqGMtEMs20XhI+2J6d5zTX0Lws1gR7Js10 JKbI1dzk4cbnN18C8YUcz24WkTtPCWs321+fTePIOGgiQnpR+akzPC1oCGq5K1Q5TRp0loPTJuw SgsyF1fRNA7JOpYWCtv4s6KAE96Xe91I= X-Gm-Gg: AYBFou3dwMUpaiXS1SHeA54xdTCKqiJK9eKdbWucG0nf32g6uboxOV+2pqHt3iHfbBA Ge4pjBhK6s6Uzn2UY07kbSI/RAX/zw9q/zko3rC18JPBRGekxcSB9W5vQBM3htbW86Dtqq1nFSy xhTA6hD4zNJKRfHoQbZe9ltFQsZQp640xI1aKDspLrUEmDRdSVXTBQZxC2nQktCtiWejAEGtrHp QfNwkLZFTCyQ+OjgO98AB92V+TG465eEAgsgKGm2xJrRfKk7spkLjsfcyRchLINzSTUY5SB7zvs DpWSb91K7DVVoa2uOqzPobFkgDayI08cF/v5Xo27SBYMTfnMzIMPWQ== X-Received: by 2002:a05:6512:b96:b0:5b7:6686:45a9 with SMTP id 2adb3069b0e04-5b8df06f6e9mr1638079e87.37.1790276097458; Thu, 24 Sep 2026 11:54:57 -0700 (PDT) MIME-Version: 1.0 References: <38850629-8bfa-4737-99ff-0fd3f489e56e@suse.com> <436c0688-8b9a-4e56-9d4c-c81dcfbea56e@suse.com> In-Reply-To: From: Mykola Kvach Date: Thu, 24 Sep 2026 21:54:45 +0300 X-Gm-Features: AclHuK_E4UtponCqS-Mc9o-HmEjG25hhkgdPTzu-tyXwM-cQvMjMhPGQcabaarQ Message-ID: Subject: Re: [PATCH 7/7] gnttab: unreachable code when GNTTAB_MAX_VERSION < 2 To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Nicola Vetrini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c1860d/1790276098-D514E87B-8592DA3D/0/0 X-purgate-type: clean X-purgate-size: 1088 On Thu, Sep 24, 2026 at 9:39=E2=80=AFPM Mykola Kvach wrote: > > Hi, > > On Tue, Jul 28, 2026 at 4:53=E2=80=AFPM Jan Beulich w= rote: > > > > I'm surprised Eclair doesn't spot the large chunks of unreachable code = on > > Arm, i.e. violations of Misra C:2012 rule 2.1. > > > > Signed-off-by: Jan Beulich > > --- > > This pretty certainly isn't dealing with everything. For example, with > > another helper the gt_version field could likely also become conditiona= l. > > With some more effort the nr_status_frames field similarly could become > > conditional. > > Could we also skip the gt->status allocation and cleanup on Arm? > grant_table_init() still allocates this pointer array, although status > pages are only used by v2. This could be done in a follow-up patch, > together with the fields you mentioned. Sorry, I missed that gnttab=3Dmax-ver:2 can still enable v2 on Arm. My suggestion to skip the status allocation would only apply if v2 were completely disabled on Arm. ~Mykola From xen-devel-bounces@lists.xenproject.org Thu Sep 24 20:51:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 20:51:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433014.1653838 (Exim 4.92) (envelope-from ) id 1x9qPn-00041a-7z; Thu, 24 Sep 2026 20:51:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433014.1653838; Thu, 24 Sep 2026 20:51:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qPn-00041T-4n; Thu, 24 Sep 2026 20:51:35 +0000 Received: by outflank-mailman (input) for mailman id 1433014; Thu, 24 Sep 2026 20:51:34 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qPl-00041N-W4 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:51:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9qPl-00CM19-Ct for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:51:33 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab58d2b-bab6-0a2a0a5309dd-0a2a45099eaa-16 for ; Thu, 24 Sep 2026 22:51:32 +0200 Received: from [52.101.201.55] (helo=PH7PR06CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab58d52-be1a-0a2a45090019-3465c9377d18-3 for ; Thu, 24 Sep 2026 22:51:32 +0200 Received: from BY3PR10CA0028.namprd10.prod.outlook.com (2603:10b6:a03:255::33) by DS4PR12MB9564.namprd12.prod.outlook.com (2603:10b6:8:27e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 20:51:26 +0000 Received: from CO1PEPF000066E9.namprd05.prod.outlook.com (2603:10b6:a03:255:cafe::d) by BY3PR10CA0028.outlook.office365.com (2603:10b6:a03:255::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.16 via Frontend Transport; Thu, 24 Sep 2026 20:51:25 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF000066E9.mail.protection.outlook.com (10.167.249.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Thu, 24 Sep 2026 20:51:25 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Thu, 24 Sep 2026 15:51:24 -0500 Received: from [192.168.19.2] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Thu, 24 Sep 2026 15:51:24 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NXWlg9Ga+C/vZdSkIbuf3xKsmQaUj/FPutWo9UNbbRvJZs+thX5yKEandiIna6uBGYgpVUO0HY8M+WmeFKtbmt02Re3xb25ubvdyGX/Yi89mblN2+zpPPtO3yokiiYNPEE8+SiXoV89uv+AShAa3VxMhsKAVjEvNF021sQdaLbJg9T6R4Ihb1pXhjASxgF3TIXW04K14f055HkfyqhdXEdfPa6TXTg5mpb8W2X+ImWFw6Mvj/g0AMTYRA973ncqbooPSiYumLTmMrxE4m8PSwijH0crxzmor4RvqGYU/6UHtyvl3m2j1EseoORIx8kNF67fqYJGLyirzs+bl7PcGUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2E/f0fpmXT0ZjsFoGXlxc/pgA8IpqgUbdIw6ulGug+Y=; b=AnayFr1PziNbSCtwF55RLXQjYQaS2ZatyMzDC+HCUfMkXXCX6DqufjggLtw45ie+HDs9seiS8ipSO4hqFQS3A9Hn9NQVzL7ezLXLc+QifDFpkEMkD6S/1PilFM2V7W8zR2e4YnBky2kuFHD7tBTronELcSZDtIM0JlRaywB/WaN2X7mghwx7po/CB3VlCEvQsmbLggvuLgdgo6CsS/qokgTt+GQ47adwEChCdNkQm4j/bypiKdSGYsTjY5d40il1VnuFkdmB6PgxZ5oO3UWTmj/UUpkWJKJAmsX6tjABPRPHuUCFyeWnzwZwRvwwM7zJWdtQCoqMHux911Y6o2F1Dw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2E/f0fpmXT0ZjsFoGXlxc/pgA8IpqgUbdIw6ulGug+Y=; b=bXyAE+lSts67hPDRfO7oEkdxbhaaSOQlkVqH+xOlATeG9bJgZQ2PnGpL1x0Sje8LA2FdEMU/spiIMsF9eRTgNmyZtvUA+FOdz+1fBkcPWuOrr6X81oGpTzj8YpXyH7jzsJzPM9EqvRhwbG2YORDcXhyCeJFcToD/chiDNz5ByAY= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <3aa3d405-88f8-4f4b-8fca-1671e3d59794@amd.com> Date: Thu, 24 Sep 2026 16:51:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] vm_event: svm: Fix incorrect monitored_msr() check To: Teddy Astie , CC: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> <1790251023.8631fc262581453bbf619ec5b2062170.1a0d346bb7600072c4@vates.tech> Content-Language: en-US From: Jason Andryuk In-Reply-To: <1790251023.8631fc262581453bbf619ec5b2062170.1a0d346bb7600072c4@vates.tech> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000066E9:EE_|DS4PR12MB9564:EE_ X-MS-Office365-Filtering-Correlation-Id: 760d8560-0a4f-44d2-2eac-08df1a7d9959 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700016|376014|23010399003|10067099003|18002099003|56012099006|22082099003|4143699003|11063799006; X-Microsoft-Antispam-Message-Info: ekAIeKbmHDqxPH4Hm4X5LZ/JD4rn8fTTUHKERaexa7Qw5a9r6njSTxuGA7hljPHy+ZLrYpPoXYT/SBhxVLqXkoX09PqbZ8F42aIJsF+31FaccCeJ/jAE4KWbrpjfGqe+Q3inlvGwfzmLiY/o3C2CZC8INHI/plY96+UK8IL59XVxj1gyGqbkxiV64Ya7IvbMmCz9Zmd6RnJEe8kNNy47+P8HBL3ai4UryN/C8XHsIgkuhR66RynVjqTIAnXiI0jqL2qbrMojYG3TyqGyO1zV7yzAQDC2WztFNCg71BFtfqfm4iDfWv0H9X1N1L0/PJ1E6by7KLef4tjuZfIdfndL4lybUAPuhtOO0rH3di4aZSBPZWTAPo3bMDCJMF56kWyB88TADiy/zEiXW8OuYHSUMDIiQjDYaGT0hWaeee+Lv/6KUiLWSNbWiB/homiBO08+lul88eXZ1Ad1qjYpbjClyMQn3MeTE10Gas+ySOx8UIRDc8A/gEnGaiymacKqtR03vqWQixyi9YDnJRohDyd2lvuZzRE0wd/mNh+jr5YWxbIZHPBfVmBXEnUvoJgSe02C14P/qp3uH7MK4W2akwmpTf+lkG7eHWMUdwjfOXRyBxlt/NHaJXs/dlAqW5KdU9gCXwE2uGn4ht0hd74NMmNvQOJSRsNZb5AATsqm7FBhVDZXWDF1soW1TyplcKhAH4ZjAUN8OpBvQnnT8zuAVSrl0g== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700016)(376014)(23010399003)(10067099003)(18002099003)(56012099006)(22082099003)(4143699003)(11063799006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 3TqjHq+q+0MXmqE6XickvlLWIkKe5+9NM4fN/1KDfIdOIHdDVHbE/QjhTmt277g9JgyWg8AAg4rI/6NCVyoGb0KLKeuTM/FuSIIv7nK4+dlj3jLUYhxTf1EZVNVL+csMe4OGGs1JRe+SFzoPFHkd/819mhi0igUnUpORSWSYKzDSV7Ysz9VdnXyiTeeWMo07zgbOHFAV9AviKtrYYMfZLZjFlPDhdEhXfPsRFdLFXfqeQSXGuf+HcKb70Qx2o6bdAS9AfG9x3Dgw2OLFJuxo3FhUOOgN4Zxe7GfS5Exb9CJbmbyEytYjf/48YaMv0OBVGpQ+LuTK5unwEoeWFbrgEAg6KMsyXNSGKeKuA/CUTGSKw3NqGaHuuyO8LqrJCmwfr4p5Ca8YeNtsS7jherydk7bsZol/9IpCLyTR9W0uBAYITJA7klSuhdvxJWZdHxyU X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 20:51:25.4558 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 760d8560-0a4f-44d2-2eac-08df1a7d9959 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000066E9.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9564 X-purgate-ID: tlsNG-bad1c0/1790283092-FC610034-4BB73B45/0/0 X-purgate-type: clean X-purgate-size: 714 On 2026-09-24 07:56, Teddy Astie wrote: > monitored_msr() is called with truncated MSR values (&= 0x1fff) > which doesn't match the original one, making the check incorrect. > > Fix that by keeping the msr value intact and computing the bitmap > offset separately (in msr_offset). > > Fixes: 2746088d9cb4 ("svm: don't clear interception for MSRs required for introspection") > Signed-off-by: Teddy Astie Reviewed-by: Jason Andryuk Nice find. > --- > Should we multiply by 2 msr_offset instead of doing that in {set,clear}_bit() ? If you do that, I suggest you use msrpm_offset as the name since it is no longer the msr. Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu Sep 24 20:55:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 20:55:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433029.1653865 (Exim 4.92) (envelope-from ) id 1x9qTn-0004kE-S3; Thu, 24 Sep 2026 20:55:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433029.1653865; Thu, 24 Sep 2026 20:55:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qTn-0004k6-O1; Thu, 24 Sep 2026 20:55:43 +0000 Received: by outflank-mailman (input) for mailman id 1433029; Thu, 24 Sep 2026 20:55:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qTm-0004k0-Kw for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:55:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9qTl-00CMNj-UT for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:55:41 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab58e10-2eae-0a2a0a5409dd-0a2a4501ec40-44 for ; Thu, 24 Sep 2026 22:55:41 +0200 Received: from [40.107.200.11] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab58e4c-5984-0a2a45010019-286bc80bba38-3 for ; Thu, 24 Sep 2026 22:55:41 +0200 Received: from DS1PR05CA0002.namprd05.prod.outlook.com (2603:10b6:8:457::10) by CH2PR12MB4264.namprd12.prod.outlook.com (2603:10b6:610:a4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 20:50:31 +0000 Received: from DS3PEPF0000C381.namprd04.prod.outlook.com (2603:10b6:8:457:cafe::ad) by DS1PR05CA0002.outlook.office365.com (2603:10b6:8:457::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.13 via Frontend Transport; Thu, 24 Sep 2026 20:50:30 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by DS3PEPF0000C381.mail.protection.outlook.com (10.167.23.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Thu, 24 Sep 2026 20:50:29 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Thu, 24 Sep 2026 15:50:29 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Thu, 24 Sep 2026 15:50:28 -0500 Received: from [192.168.19.2] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Thu, 24 Sep 2026 15:50:28 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=g0TnSY8VneubHBgeyhD1m8uEhNIg8U5WXBnSBj7obBu3+LyFZ91YkcpGa+Ok5i84mYBB2LvTvnn91Qbob/MVtLBQQEFQcfN0k4oEUX0xGIZbhLmeFfj6EuCxLJ2CCllT9OCvCiF6oJDq+baKfIZbWgvxBenIC1Io5Iy6E7FDvI9c7D9p0OBRewuImeVBx5cd2vxFizGtDHlqZlFsbyTWCaL52YBOsnjnU8Hkw6KQWFCzwNy/4ia6jofKcxRPNQ6NJnLa2ZdbyTxrvpiYqBn8JDYpRQxCdq5jPAhpoDg8Ci3JX+/guGyg08PB0jWUD8EUH3C3cN865YySBEGnvNqNhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XrwXOGVPoCuvkbvKL3weAoNwHrYqs0UvPWiSsQhyNMA=; b=VvYuX1BmrRwNwHXwcBwKj9/s3boaaWy6W9RKP04oKGNUdlrIJJZ8xqjVzLX9Azk/6vWbC9Kwwt8yiQ9v9ATCJ4M395TOQvkPjotR+EbEzt1VXylULZV9KHUVINFG2OEpv6EJxcboo7U+2xIc27yTcypQCf1btgM6E6bnLDJX2yDrbsgiHAHAUzvjJXIKyXRE9a2CZaSYy9xAkyOMzWzrPbRJdYHFJL7CI2ApD+j+CB3lBCgQh7uUh21taBXeyQFM5ZYalpLiHLBprmJC3BW6oE7zRlg/4anr5sbrk4Q5SDiVHLrkUiF8FmLHIRrMv9pCTISGxadNZCsxkGrKlmqHSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XrwXOGVPoCuvkbvKL3weAoNwHrYqs0UvPWiSsQhyNMA=; b=WXhW8v1CKNCX3u2brQrCemNfsog3kUl4Ssk/TaB7PTxvsJi8YyQcWo4+FULYvPhb3Pl9dDCT7v1qeT7m+QAVu8CvVfrWu2zzppgpGkcdMOEsJJoCcRIftj0TFjWgfVJkoCddv/tLN8BP4rVlni18YPsca/NvBE3Z0xZ1cbN8BcA= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: Date: Thu, 24 Sep 2026 16:50:27 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] vm_event: svm: Don't BUG() when enabling intercept on hypervisor MSR To: Teddy Astie , CC: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <1790250881.8631fc262581453bbf619ec5b2062170.1a0d344933500072c4@vates.tech> <1790250991.8631fc262581453bbf619ec5b2062170.1a0d3463da200072c4@vates.tech> Content-Language: en-US From: Jason Andryuk In-Reply-To: <1790250991.8631fc262581453bbf619ec5b2062170.1a0d3463da200072c4@vates.tech> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF0000C381:EE_|CH2PR12MB4264:EE_ X-MS-Office365-Filtering-Correlation-Id: 08af3900-ea8c-42d3-2e4d-08df1a7d77eb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|23010399003|6133799003|11063799006|56012099006|18002099003|10067099003|4143699003|22082099003; X-Microsoft-Antispam-Message-Info: X2suyCMx/ZTjclQ82Y2KFcEBkyVmanpJFNAvRdICyBvdhe6HC1jZ9D3KXlodJwsQ3WWruzB/A7CmDDrs7dJ2h8OnIkMcORbI0hRxR/t6kpBl8NJ5IxwKjCj7Pj1xFA/WZ1ZeU0/YqnhANR/dvCu3fsQ/w3Hu5D7HhlZzBVoB42mYtm8Eu0PZwVd+VXY3d+uLfqPiH7hPQGo/thpRxhbJ1h45QxPsPMoJ8Ao1VfnqAib1RqYnVeKG60a6G5I7H1XhaX9/Lo6MMPSbZhxD2aRvUqCaRwr/jrBguMivfIXhPkLnofGmnjlUks+KzJcp20DmSCJ9HTwvYarE1/OimZc45MBuX5Ud2qX/WFso3wSJMm3MAxDYSuzxMe5F342DBM54iO6Sy4RHu2XKeGmslSL/DoXXCbxUunsqluJWoB8rXGCjagREDLu0bQ6EdFV57JQDXKSmSCFhsIzYZGgpkJpMUjOIVQHDDq9Ohay4LA0p9fqn1w2Uw4Mw7WzwISw2SUtrzut8VlhOSNEp0Kt04ohlv0D9hyOQi5cuRBst/6Se9PW5wu3uZBBCjExxXacvsyVugkSTTUHSmFVIueFPr/nomAeVk4nwBFyhakFKj4PLfuto0JXYfx810nwZMshma7J8fh2+YOxETCsaZ/qmBATAHScWfhlCFHVPzZTwV9Z6MveG2re4fGajVj5usbMrmqTp X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700016)(23010399003)(6133799003)(11063799006)(56012099006)(18002099003)(10067099003)(4143699003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: tBONMGLDF9P5eTwqzLgp/rLtSk5XzzTUNrig8QNUMRiVGIfIE44WgVksF2xXit8b0Iai0LBR0PmNEVzQPWhosUbef8oVZZg3bmbwTOfP13zHWXqY3/w8yLGe+i7wo2IgyLOzP81G/IPYELAuAQcsMR/c8sgd9NKkzrYOfGTZGW/gel1lbARlV2XK708iNADw65y7moAyWxDVPbkN9eejOqHTbzBG6NIhKy2CLGh6wi6HuFQ3r+VzRiKuFHxmQQmrM+4J78K05n4/KR/+bRmwsJJnnR1utzpa/0ekjzwC713SiHFeJSf935vrzi3G8m8Z/8FlrKlh8nQhvdF6AU6FexSETKuCiaTQKtzSHOt0FN+jqd6tXN7vnn2XKZP04d1IPp4S1zYZ2ZGFNSWE+xA9IHyAUUeVsWG3qHagv1JigrK/R2K2UFBw8McJcNDJqLHM X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 20:50:29.4241 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 08af3900-ea8c-42d3-2e4d-08df1a7d77eb X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF0000C381.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4264 X-purgate-ID: tlsNG-d62444/1790283341-BDE78757-7FF90730/0/0 X-purgate-type: clean X-purgate-size: 800 On 2026-09-24 07:56, Teddy Astie wrote: > svm_msrbits() only cover MSRs in the ranges specified in APM and returns > NULL for all the other ones (i.e hypervisor range), which triggers the > BUG_ON() that follows. > > APM specifies that MSR outside the architectural and AMD specific ranges > are unconditionally intercepted, hence don't require any specific handling > by SVM logic, fix this by ignoring cases when msr_bit is NULL. > > This is only reachable with CONFIG_VM_EVENT using XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR > to configure a MSR intercept in the hypervisor range (0x40000000–0x40001fff). > > Fixes: 6e9fc4d628b6 ("hvm/svm: Enable MSR events") > Signed-off-by: Teddy Astie Reviewed-by: Jason Andryuk Thanks, Jason From xen-devel-bounces@lists.xenproject.org Thu Sep 24 20:58:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 20:58:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433039.1653873 (Exim 4.92) (envelope-from ) id 1x9qWI-0005S3-71; Thu, 24 Sep 2026 20:58:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433039.1653873; Thu, 24 Sep 2026 20:58:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWI-0005Rw-4E; Thu, 24 Sep 2026 20:58:18 +0000 Received: by outflank-mailman (input) for mailman id 1433039; Thu, 24 Sep 2026 20:58:16 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWG-0005Rj-Ds for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:58:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9qWF-00CMcQ-Qu for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:58:15 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab58ebf-8faa-0a2a0a5109dd-0a2a4509c090-26 for ; Thu, 24 Sep 2026 22:58:15 +0200 Received: from [40.107.130.140] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab58ee7-be1a-0a2a45090019-286b828ce1c5-3 for ; Thu, 24 Sep 2026 22:58:15 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by GV1PR03MB10503.eurprd03.prod.outlook.com (2603:10a6:150:16f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 20:58:10 +0000 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28]) by DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28%5]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 20:58:09 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=atvXbPtNEYEJ7yUjCeF4ae0byOyKys/Zf1iIjhnK81x0b6o5JZJ5M5Cdp9cwJOu/7JZCjLGMKRwl4UNfaNaFRVmdFPcHYUU6fk5x7J3zGuhrOSYGRVt8AuJrY75a3NXdHC1fyQdEaAAQwjIHDVRRMayvTDqyrxDXavJrm0rWGDEgpXEGMV4AmVQSMvouyVsTJLca/8VjkbFDMHaux/XjdXu2i6dAQ7oJZgosaPihy9oMe6VsDK39dQ3+mHejZIgQYxjvUj/OODeBshPsOdR7YMz2ubCnuU4b+JeqnkAqnvG2yzoLL4pVogWFcQlACTUv/g5J6sVqzuCiqByxxmXLCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9FEWI+Mu3FCaR/ob7J4Ho5auTDYHoiCQQ5iGwusxYkY=; b=AIIE7uvBQcXvNqia0QG/vtlp0gJTgGCmCDNpbHrjwn0oB7i9Xft2s7OYyTGRsrxQHz/91BgQZQPeMMtb5SNM0Nwm0mJzXhCGw5ouHtjb9VdetKpFtUQTTUgR4bxp8kj39WcpQAheC+12CQOjnifjYdzhFDZFhx9Y11l4Pv7v4QLYZ7hCOo0U0xV1RbxQkQtMlsy/Pd8iSyQPh+Tmv/MwZDtsvia7qaRKEijX8dV8f/r8nqhjKFSXEsv2oTxhAulXxcHaYDQrmSeLSkbBddZSKkRCD02ykfcpe0099KsVfJHN6LFdn5oJLv1pGVnJgsWXgrqcUJZB3pKGQXDCBeRehA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9FEWI+Mu3FCaR/ob7J4Ho5auTDYHoiCQQ5iGwusxYkY=; b=kXnalXmN9eztwE5KlJap/Hc2gKhOWucGm4oDIoXTDJiBMAd00WBh080lU/ZCvf7qSra/nS56VGD8gQgF0IFtFbxGAfb5B8B2g9ffUc7DBbOPComNH4aCqUIT42J2npJ+nO0aOT281FxPQxF9KrdwXwgXjWdj8aKDmzzy0qz5JtG6T/7Kl5taC3zN2/aP4x1YgDEAA7VVDyKn7Au7uYABvx5NRIgKfZcoO1ckoAcCMnrQ+wirIiOS++Yj6FoJmwluKHCPOCLgKUWOjCUsXWoiK+RxCJhdqPwWj4FaMP0xgBCCduI68SS2z0+zV7Z5+PFGnZKaIx6BLEhPC1csemb1IA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jens Wiklander Subject: [PATCH v5 0/4] xen/arm: Fix eSPI IRQ handling Date: Thu, 24 Sep 2026 23:57:52 +0300 Message-ID: X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0022.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::22) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|GV1PR03MB10503:EE_ X-MS-Office365-Filtering-Correlation-Id: 3ce9cfcf-ff79-42ec-27a9-08df1a7e8a37 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|7416014|376014|1800799024|11063799006|56012099006|10067099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: yx6ZVKPKYcsT8wYFACGpqNzvb41uFqAeN8Irl6zQsT1inwLGukEAIXDOX5c4/jWei8TC5e0LpeVSQIf1eOIdqxcuDAx+7YEmKUezkYxxNQXWPbjglxWcqNMim1zuaW/5FTkwyAbDFoacsmMwP39xnrwKN9oU3ekAK7GMd4ROx5EXH2bY/kKAmw6TAOwsPfapXv11u5hF4IOfNYQBOxghY9ZAlJSF3ly92R7UBkmjH0Ui+mDoGbmefzH9/8BXlLMkisL9bzA9CDH5oHtddxIPm+xeyS5fReGX/hWx5AqyGXkeH0e6ULkKRr1wjKEaD+AadXDgvnl2wiBpDPCbM+Z+AR698aHCZr/R92bKlA4SRmNmo44e8kmliznnW4dOPqQlEvexx2fsyTzPR1smUjxaYPJ28UWdhjawtn1uQEkVXuWXOxuj43rMdz5ke7oGe/6upTRuMbqzCdqNYAs6Cadki5UcO2WWu9M3PmcAg2WXJnLUIuMqdc1z1wHkMUS2ZKcKE6Agmuj5Pdg68+MCL36pZt10eox0urFOGyGrVQU0MtDTVyFx/jngtv+todtHypdqGc/gFuhFeO8FlAkcUHR/Frk2Ck1gNK4991/u6a6Ln4Q1084btNauvA3RIW4hpA4/2eUFwpRLWNvLscCcIWTHPj/LYY8HpYh8bqMpECJYSCo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB3PR0302MB9208.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(7416014)(376014)(1800799024)(11063799006)(56012099006)(10067099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?pAHWxusjT+tKjiIt+0hMMVC2ztXEpOG4ByxVSVA4F6jgnbaNnD5N9TJ0xm5I?= =?us-ascii?Q?GKiE0fZarQMyaoKHCbvOr7vIordpqhAtCLcE7b2au1k2yhJ8zH8n4MSdRraH?= =?us-ascii?Q?Fqo3ZRIh0j2QoMYF6fUsoD6DnvztMKnKrMbJUeqftAvCqQNOMkAGkdkGhz4/?= =?us-ascii?Q?frtpFyr0cYQWGmEuvw4E98Nh3i4G261pfcjybgq6CdpmPsrShXN02eveRMpM?= =?us-ascii?Q?wQKYRmwQYwYsj6uKrde8tZGBQga4B/qvh9oNZtEz7dWib0BBGE9xM7ACMV1y?= =?us-ascii?Q?SjCvWJmXOUxe6SXRPL0HkLlSuj0KEWEKjLYQFNZJsH3njbywEBBC9p/Kr2iS?= =?us-ascii?Q?TY2b3VhcMFa2r0XDDwvYRoxmRIRe8kHW4cKX+viklkjUuJWlWkHP5eXMzlBE?= =?us-ascii?Q?SjFJyinlnsH/F8d7U+zbHFd/g76h26exKEEPX9qr2YlNgD8gY4uo/DnTlNo3?= =?us-ascii?Q?BeZaePyy6W1qbDrG8lMG/sfXNZQjW7Tg0Dp5WFwHtwe3Q94M4krWBgFgccAW?= =?us-ascii?Q?lO9H+gB3jAY09xFpFttW6maSSaGqkPsR0H/iYdRc1WZRZOSGZOfqOZU4r1KU?= =?us-ascii?Q?Nh2+eaah1IuvjfF010D/GLSdBrMx9zn/0nANgO6RoH28NmHrbvaASKVIB0jD?= =?us-ascii?Q?jcwF3qCOO/ePWN4GQFd9gJVx4eGkALXlbOWnFeuhVojNjTGycDgZsfPayumE?= =?us-ascii?Q?nfAQ47X2F/3v5nYKPilk4zbTU+5JTVFRFjipC25ZyBBBSWwhoNS0mWPJcKVG?= =?us-ascii?Q?6pXFI3wY4o0K7B8mGfvpOMDqh6Tqtl+1vRfdNb1jB/Jp82aYNEDIW+1tZNVc?= =?us-ascii?Q?AFFpI39+Cno+Pp5Sgwze4e5xdxgWh2R5TRP7d71ZGPbi9pDlsqDxG/uLT6ry?= =?us-ascii?Q?mckB/DUn7XgmNq8ZIb/Fg134VvuRqnRQxNksXRUM82T2Mjgc1r3GX4UWYyLq?= =?us-ascii?Q?RroNCtmprHiz5jKKeG+O3ZFehwwqcGqDh2iKgsaplKJRbfs+lEk1qc48ppuZ?= =?us-ascii?Q?z77vAqZHwNYtEt/cmFulLrMEuN47YPRcCJX/9GOytisrL+fWkbMi6G4g6rOW?= =?us-ascii?Q?DkmkrfdZQvnHcYAMEkNtJUQpWJLrtfUlzS02/uodjjEEuoN40Nm924l0l1L0?= =?us-ascii?Q?wClehkX7c5KcNGugH1yKBW3hw2m8SYC9SDtUV3pD3LKNPvv9hNGztHTvY+xo?= =?us-ascii?Q?uyLwHKmbowW4Lp07fajiITAjgQ3IPh5dfnCSfXQVX13znmCxzu3RJZ45KIsm?= =?us-ascii?Q?UnX9sRlVAmhaqLbrAXeGn3J1zCfG4RQOvE6GsCsUtdXmjKf5wg7OAOcHMZ2E?= =?us-ascii?Q?ToFFJUhwjgKt+0I3S47dNuS1u8o6oTpQgk3Q+lulCMyBEp8c7D8YTDnufTLE?= =?us-ascii?Q?14u+d6HvUGIhDyA+l2BCVn4OqLedGV7MxWr2OvLbFQda0aeV4XZJ1MN6w/ms?= =?us-ascii?Q?EBpvMaTq/On/NJtjZ8bpWxyjXN6V6HiV51ZNjISRyV+4ND9Bg2RqK9wwAxck?= =?us-ascii?Q?kKhTZJVhj2YWmGw7Y2Wu+aar3tAoADwYiYpQ7wf6H8AWS6n6WC8rfgMWcLo0?= =?us-ascii?Q?UbPyxBCG8M/SsS1LmbBh27jOpipNx9pYKJGlrEIv/fMceYrGm0hnOKwAiyV0?= =?us-ascii?Q?lhsixivR2lA1PHVFab8IX4Up34vBc+pUNo056O0NNOOTSTVDlgJzMGGUK61r?= =?us-ascii?Q?90Dh1/C9Vga1v0jVSV2AZPfI9JvWF9knfAPx7Tw/4OPTqtwANq6OvgOCMUlx?= =?us-ascii?Q?6js9w6+HMw=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3ce9cfcf-ff79-42ec-27a9-08df1a7e8a37 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 20:58:09.8672 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vC9H98kbc3bRk/kgDNnJhyDZoWd0uvd1C68vq/qyUcf5Zc0Hj9owXU3q62l08EoKGP7zsc/VpitcavzmO823Vw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10503 X-purgate-ID: tlsNG-bad1c0/1790283495-BFCD7034-44A4E690/0/0 X-purgate-type: clean X-purgate-size: 5223 This series fixes sparse eSPI INTID handling and checks errors returned by irq_set_type(). Patch 1 checks irq_set_type() failures in the GTDT, MADT, SPCR, and FF-A paths. GTDT and MADT could retain rejected timer or maintenance INTIDs and later use them in direct descriptor lookups. This patch also fixes MISRA C Rule 17.7 violations. It is now first in the series, as requested during review, so callers handle errors before stricter IRQ validation is introduced. Patch 2 makes is_espi() check the architectural INTID range regardless of CONFIG_GICV3_ESPI. If the GIC reports an eSPI without compiled-in support, Xen stops with BUG_ON(), as there is no descriptor or pending_irq storage for it. Virtual eSPI pending lookups without support are treated as unreachable: the stub asserts in debug builds and retains a NULL return. Xen has IRQ descriptors for INTIDs below NR_IRQS and, with eSPI support, for eSPIs starting at 4096. It has no descriptors for INTIDs 1024 through 4095. Patch 3 checks INTIDs in setup_irq() and irq_set_spi_type() before descriptor lookup. irq_set_spi_type() checks descriptor-backed ranges because it can run before the GIC line counts are known. setup_irq() checks implemented lines using those counts. Patch 4 fixes the vGIC allocation bitmap. Reserving an eSPI used a compact bitmap index, but freeing it used the raw virtual INTID. This could write past the bitmap and leave the eSPI reserved. Both vGIC implementations now use vgic_is_valid_line() when reserving and freeing vIRQs. Testing of the v5 review changes, before the latest rebase and reordering: - Arm64 build with CONFIG_NEW_VGIC=y, CONFIG_GICV2=y, and CONFIG_DEBUG=y. - QEMU GICv2 guest tests: 10 checks passed, covering SPI delivery, enable/disable behavior, affinity changes, SGIs, and the virtual timer. Testing from earlier revisions, before the final v5 edits: - QEMU and FVP tests with CONFIG_GICV3_ESPI, CONFIG_HAS_ITS, and CONFIG_DEBUG enabled and disabled. - Physical and virtual eSPI delivery on FVP, including delivery to both vCPUs and retriggering an active eSPI. - Injected an unsupported physical eSPI and confirmed BUG_ON() in both debug and release builds. - Arm64 builds with CONFIG_GICV3_ESPI and CONFIG_DEBUG enabled and disabled. - Arm64 debug builds with CONFIG_ACPI=y and CONFIG_FFA=y, both with and without CONFIG_GICV3_ESPI. - FVP Device Tree boot with 64 eSPIs; Linux dom0 started. - QEMU virt UEFI/ACPI boot to a dom0 initramfs shell, covering the GTDT, GICv3 MADT, and PL011 SPCR paths. Changes in v5: - Move the irq_set_type() error-handling patch to the beginning. - Explain why an eSPI cannot be handled without compiled-in support. - Make both espi_to_pending() helpers static inline and constify d. - Add ASSERT_UNREACHABLE() to the disabled-eSPI stub. - Preserve the unmapped LPI comment and clarify that eSPI lookup without support must not occur. - Add the vgic_is_valid_line() guard to vgic_free_virq() in the new vGIC implementation and use the same helper in vgic_reserve_virq(). Changes in v4: - Use BUG_ON() when the GIC reports an eSPI without compiled-in support. - Return NULL for virtual eSPI pending lookups when support is disabled. - Remove the redundant CONFIG_GICV3_ESPI check in IRQ dispatch. - Share irq_has_desc() with the assertion in __irq_to_desc(). - Log invalid IRQs rejected by setup_irq(). - Document the compressed vIRQ allocation bitmap above the conversion helpers, with an ASCII diagram and a reference to struct vgic_dist. - Clarify the is_espi() commit message and drop unrelated blank-line removals. - Add Reviewed-by tags. Changes in v3: - Add a preparatory patch making is_espi() a pure range predicate and move configuration policy and debug checks to callers. - Add the requested assertion before regular descriptor lookup. - Avoid partial MADT and UART state updates after irq_set_type() failures. - Apply cosmetic cleanups from review. Changes in v2: - Check descriptor ranges in irq_set_spi_type() and implemented GIC lines in setup_irq(). - Keep the is_espi() debug check when CONFIG_GICV3_ESPI is disabled. - Remove a redundant CONFIG_GICV3_ESPI guard from the vGIC code. - Add a patch checking irq_set_type() errors in the GTDT, MADT, SPCR, and FF-A paths. - Target master instead of the 4.22 release. Mykola Kvach (4): xen/arm: handle irq_set_type() failures xen/arm: make is_espi() a pure range predicate xen/arm: validate IRQs before descriptor lookup xen/arm: vgic: free eSPIs using the bitmap index xen/arch/arm/gic-v2.c | 15 ++++--- xen/arch/arm/gic-v3.c | 15 ++++--- xen/arch/arm/gic.c | 6 +++ xen/arch/arm/include/asm/irq.h | 11 ------ xen/arch/arm/irq.c | 28 +++++++++++-- xen/arch/arm/tee/ffa_notif.c | 11 +++++- xen/arch/arm/time.c | 18 +++++++-- xen/arch/arm/vgic.c | 72 +++++++++++++++++++++++----------- xen/arch/arm/vgic/vgic.c | 5 ++- xen/drivers/char/ns16550.c | 8 +++- xen/drivers/char/pl011.c | 4 +- 11 files changed, 135 insertions(+), 58 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 24 20:58:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 20:58:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433042.1653881 (Exim 4.92) (envelope-from ) id 1x9qWK-0005f9-Gt; Thu, 24 Sep 2026 20:58:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433042.1653881; Thu, 24 Sep 2026 20:58:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWK-0005f2-E7; Thu, 24 Sep 2026 20:58:20 +0000 Received: by outflank-mailman (input) for mailman id 1433042; Thu, 24 Sep 2026 20:58:19 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWJ-0005eb-K5 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:58:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9qWJ-006bdo-0u for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:58:19 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab58eca-bab6-0a2a0a5309dd-0a2a4507bfe2-20 for ; Thu, 24 Sep 2026 22:58:19 +0200 Received: from [52.101.72.96] (helo=AM0PR02CU008.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab58eea-b4ea-0a2a45070019-346548602343-3 for ; Thu, 24 Sep 2026 22:58:18 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by GV1PR03MB10503.eurprd03.prod.outlook.com (2603:10a6:150:16f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 20:58:16 +0000 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28]) by DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28%5]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 20:58:16 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZMRtPN43aJim3Ip0+0Q0UQxof+rJp+A4Ec8ws1UvIvPhEWFK3Jf4akODFHz2BTqIMP7uSzgwXgBasCBkLnLNopwtt3PjoiQNLtgMaxuJ//8IlpB8bnBJVgvi9YPYhrIo5OCVQO1HeM6WISA/2WKqFCkOzI/elEP/imtCgjBoTw3+4pQCNFAfZzAKiypTNcxCkjaD35qbw+ow52RKjXnGsICv+NxFOZ1rVXN9tMlXw+eKls3VCQrwrB1VC9oeYeVGB/aTnZDZpBjSqhunP+zPpC6Az0zOtyA2LY45ARfO5qFpb0cu7cfoBkdMnbGcCiXtZh6srN6Olvr34BSlXTiDiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2cKreGMUElULo1QhsKeoGyzZB+m+nWVmEkjFZ6Y0E/o=; b=Tn+YWP29nsFVC+g2Z2JaJ4TL+UGgm0yM3O915rFZkK3IsU74s5Z3cXp+nk56F1K6mffYGHlgIIaWImCyEoABF/e4A2AqD+zecmDXM07XJVrxE/4c6QHSV4gP769SYfKLeYWtkvm6RePnYu+PBmrO4PoQowFUmAsoltbvi0ioEhw4nj7b16ZlpZ8jqfZvJKH+5xtlvWzu/ZhiZlKziFx7NROMeKS23HVVEH/+LK3IwHo19Hxhgh712qTrvWYr26PuAvr+3/lXqdy/KOzM7pWFF62lDGkanJOM0lKTAWkaEOnVsH4LjFtJvA0LrbokIyYDlXx5fzovcCQx6zhb6vJ5Ag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2cKreGMUElULo1QhsKeoGyzZB+m+nWVmEkjFZ6Y0E/o=; b=hPlv2lfsDxTDaCwTcIxVXiKoHZKpCj6FplNFesJkwFccG63xU1YARr60ocOeUZ6PmlncMdT+QUCcpQaJ0UXzdAAxEGxeQEYzXR0ELeu/Li/npefyOgsDttIbPPYUQ8xWtz1dZTvxWiATgLvLC60QtNscgwHI4RrP0A3kVpg+7znHnwBIM1/3nfq0OdSDH5CtCmasWc5KJ9NvfOhhSrNb3nreZVI/KgVMOxS79RySOs4yEEzphma2Ve/Xo9Gxljz5THj9goJsMvNhQ3LmZgyRNdT8gTPHwlM/yxC9JVpEVNw4D8ZzHkCooWpSV1Rqy1+ojMwFjadH4O4ldbuiJlhh3A== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jens Wiklander , Volodymyr Babchuk Subject: [PATCH v5 1/4] xen/arm: handle irq_set_type() failures Date: Thu, 24 Sep 2026 23:57:53 +0300 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0022.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::22) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|GV1PR03MB10503:EE_ X-MS-Office365-Filtering-Correlation-Id: eaeb7763-ca84-45bb-1ccd-08df1a7e8e64 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|7416014|376014|1800799024|11063799006|56012099006|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: ICH174TeE8r+OFrdJ2Q0P3mLL7/E5HVNEZVh5QOKpn5GcmRK1DNZtjUlga3hb1H/hwblQf39oKvItpcEx3MSWiOcEACg9rt6IFc0JyWURGNpP3x2kBW5PKppNmlXiLBSkmIOOTZMsVMI7C63g9lJQvBD3TEu30OXvRVLZ+RZ8JX69TIWjfMaaPm/K7iOBnn1a+fEgNYnqF6uD7EfhC4uTozyIg9CQN3KM8ixGBYuwCk7tVzlDcqqB+MGhLuWA4IsqOzHwCiJ67idxIA56WCYlSXR0FJeJH3vgiaQyAkpV+kjvXcfEXYasHbAO1z5+O08CHH0U84rj+N5xMiw/ItyfDAd9J3Wq6SwXN88qhk8DHldgcVFoXtm72DAZ5mrm4mAtrJvwOx4BeiexdFqb1on8FqU+UwN8On1pwuCT23DkMit977y4s6x2SPoXnd4ZcuSHwf4xHYBwH3z2JdaJNBgH8dvRlV2qOoj1tbL10d+sTcOUmYwHzmcbDZrO6RAvrTpE+kVFYPvrsw5KB27SDHYzJ7zYJDy4AFLMBxyL+hswRShcQkaJiezc+uU4DVELPTAkKgX1tlY/aAO/vjXd+sT/JwOaGIQ72jaIxL3aWrjmwWo7rIpWfGIyDGIzJQXN5LV5xn2QkH+S4nghGF3tO2wcOBB0AMzARVgCiqQC/ONkLI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB3PR0302MB9208.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(7416014)(376014)(1800799024)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HI4go001o3bIuJJ8JD5j6WUOjT7vYlRZoJMK/vJeFocV927H8SjFSW06qr1g?= =?us-ascii?Q?5MGSq5rG9YZ+c6ukunkvICE3gpc/F7N592AeNH2nDzde+CdNDXbu0MRA52ju?= =?us-ascii?Q?gyC+KNNVRsm5IWG4aZe+s+Oqkz+jjR9SVf5FjQJiZkdG0lZLqpN0H968fy9d?= =?us-ascii?Q?O+kTi+eIUZJOmWjpUxQDIVEQwbv27XaKcGhVybCxFqVM+4EhBtOD95rSdhw6?= =?us-ascii?Q?9J/OuM4KHNx1QZed5XfI4omLlV7GVhMLvh2smMjCrdieg+MG5X3Vldvfk8Ir?= =?us-ascii?Q?GxQ/yW3quNVn/4gKjvyHrlki1LfGjG7qLaLLndPAPkg4vlHn/6IEymUl3rwd?= =?us-ascii?Q?Fr+vEtIcr+XhU4w3h8QKlWTVvXODc34be5ZlSfa+uZ4akYbxugGqjrBn1FmD?= =?us-ascii?Q?RKPcqi8ymQ9dny+6nbDBQydbyXbddm49Xds74c575MRUpWyB4Y/dvPLHnxdN?= =?us-ascii?Q?QR5WOlalUCTvm9hKvof6umjJayIGVa56qwjPJlDNG3wwXfjd2Aw0LGI0i8hd?= =?us-ascii?Q?EBEeoJEO6GmhJAmHD8CfpWC05O+q8XPDjSI2uWaZW4z747iK9JD2jKQs7mcA?= =?us-ascii?Q?10yXeexb8VTCxsgN9smoL1ryuSekcK/CxJlwM2We0/zbrdCjQYsL6TcpLY70?= =?us-ascii?Q?+nlaWmcvGEKGrqbKUNtToIpS/CGF1quZbqpa14B7TLKC2BviNimOD2LBEY+x?= =?us-ascii?Q?Y6xk4zNj6PsByIJTrpmTbMN45gzdqRZu3hm7VICRU5eX0SXV6TPc+Fe+tzG+?= =?us-ascii?Q?fRNeq9sI7FWWUYApgZs6OMFFqLr2wyC/cYLODDlMIzGn+NlDPZItBXDP9/8P?= =?us-ascii?Q?x8HI7iHRGq2vS5BuFSUYPqkoz5I4REyweeAQLfZf5rzBK+FAd25ea+Hkh8H2?= =?us-ascii?Q?7Phs2o9w8d7Y+jIwlbqysKivl8zZ9TJPWOP/D7djEoORqRwTzQqUdsSzRMO8?= =?us-ascii?Q?B9EHS8HfaVCrdgASXI2uHCSDnf0YGh2C2M4dMekaQU167AlGu1hAOAfO2lsi?= =?us-ascii?Q?o6Usd4ubMMzA9MpmN8vGPm/fDC4FSQdrTQatQ/tc6mivQle/x/kRxIXf+4Bv?= =?us-ascii?Q?Gx9bDmeN3uFiTrTY6ZzkMLBt6lp7/jYFaqjXaCrVNMAA0VdpX0sOGyFInQJb?= =?us-ascii?Q?PJqoO0bKxltsTeCTH3IYYsIFiRV8SAt0fopd8dCLOOGUcmY6G2M+ekpp0TIK?= =?us-ascii?Q?3zsCe8VVSfsgBuqCjfAT57DQ2i6ydRRlKeSjoFyqZIKAQjxn7QN25E+Lvrkv?= =?us-ascii?Q?0pXO5TruXxwKu+MpYlGpk59anO08U6ZZW4SK9pP93eElk3gOIFj+WuYZl53C?= =?us-ascii?Q?/nloD+JVrLTKHUyp42Ql8WkJe9kzT/U1GSsL0vX0Uvb0qOzsRz+x2R78XSFE?= =?us-ascii?Q?Uw5sT2ui90YUhOXbA7QB/q5x7g71me+nl+QIWgqtr7JoElgB1EjMBH7keNRF?= =?us-ascii?Q?xaP2mWeozcK0Cpsn/7D7XorCiNCqkmUm9zCK4je8bnmT66+BIcf7A9HdTEce?= =?us-ascii?Q?7+KeDUXS28k4WmRXTluVJ+D4lEPtRErQNIRebFKXsxQl4bWM9MXTA0tWm9vD?= =?us-ascii?Q?I18fa/JCWv0NPrLKA0A9DyGcyGDJgBYqKY4Fa+LUrRR3JyXApfDPYd7oSbgv?= =?us-ascii?Q?uZcptWHbfWpV1LLMXBwO+pbi5OVOqLFoMLugp3EFQcYYizR6uhiSnUg8nlMo?= =?us-ascii?Q?txU+jRmZkH1KIS5dDmo3rJoIDfKdfLea8TWO/A4FJDBuYx66cGa31q9rTo+x?= =?us-ascii?Q?MUWhHjnCag=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: eaeb7763-ca84-45bb-1ccd-08df1a7e8e64 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 20:58:16.8019 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zF3QyVmAavuCDFfeJTg52Z0a8cWhq9Ojj+hjUfLC9xP2huwTaaG1DCCj5nf0+NbZDL/Sr4+AZyp1yRsrpRNUQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10503 X-purgate-ID: tlsNG-ef75cf/1790283498-A58C1AE4-2EE4BAF3/0/0 X-purgate-type: clean X-purgate-size: 8128 Several Arm firmware initialization paths discard irq_set_type()'s return value, violating MISRA C Rule 17.7. If trigger configuration fails, initialization continues with an IRQ that was not configured as requested. GTDT and MADT retain rejected timer and maintenance INTIDs. check_timer_irq_cfg() and release_irq() later perform unconditional descriptor lookups on those values. Xen has no backing descriptors for INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds access. Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store timer INTIDs only after successful trigger configuration, make GTDT parsing failure fatal, and stop UART or notification setup when trigger configuration fails. Signed-off-by: Mykola Kvach Reviewed-by: Volodymyr Babchuk Reviewed-by: Michal Orzel --- Changes in v3: - Avoid partial state updates and simplify maintenance IRQ setup. Changes in v2: - New patch. --- xen/arch/arm/gic-v2.c | 15 +++++++++------ xen/arch/arm/gic-v3.c | 15 +++++++++------ xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++- xen/arch/arm/time.c | 18 ++++++++++++++---- xen/drivers/char/ns16550.c | 8 ++++++-- xen/drivers/char/pl011.c | 4 +++- 6 files changed, 51 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index d05c574d88..87eda9d322 100644 --- a/xen/arch/arm/gic-v2.c +++ b/xen/arch/arm/gic-v2.c @@ -1166,17 +1166,20 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header, /* Read from APIC table and fill up the GIC variables */ if ( cpu_base_assigned == 0 ) { + int rc; + + rc = irq_set_type(processor->vgic_interrupt, + processor->flags & ACPI_MADT_VGIC_IRQ_MODE ? + IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK); + + if ( rc ) + return rc; + cbase = processor->base_address; csize = SZ_8K; hbase = processor->gich_base_address; vbase = processor->gicv_base_address; gicv2_info.maintenance_irq = processor->vgic_interrupt; - - if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE ) - irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH); - else - irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK); - cpu_base_assigned = 1; } else diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index acdac22953..b32a9b5009 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -1743,15 +1743,18 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header, /* Read from APIC table and fill up the GIC variables */ if ( !cpu_base_assigned ) { + int rc; + + rc = irq_set_type(processor->vgic_interrupt, + processor->flags & ACPI_MADT_VGIC_IRQ_MODE ? + IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK); + + if ( rc ) + return rc; + cbase = processor->base_address; vbase = processor->gicv_base_address; gicv3_info.maintenance_irq = processor->vgic_interrupt; - - if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE ) - irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH); - else - irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK); - cpu_base_assigned = 1; } else diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c index 186e726412..d08d0a3366 100644 --- a/xen/arch/arm/tee/ffa_notif.c +++ b/xen/arch/arm/tee/ffa_notif.c @@ -407,7 +407,16 @@ void ffa_notif_init(void) irq = resp.a2; notif_sri_irq = irq; if ( irq >= NR_GIC_SGI ) - irq_set_type(irq, IRQ_TYPE_EDGE_RISING); + { + ret = irq_set_type(irq, IRQ_TYPE_EDGE_RISING); + if ( ret ) + { + printk(XENLOG_ERR + "ffa: irq_set_type irq %u failed: error %d\n", + irq, ret); + return; + } + } ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL); if ( ret ) { diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index be54b87438..ccfb76e20f 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -60,20 +60,27 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header) { u32 irq_type; struct acpi_table_gtdt *gtdt; + int rc; gtdt = container_of(header, struct acpi_table_gtdt, header); /* Initialize all the generic timer IRQ variable from GTDT table */ irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el1_flags); - irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); + rc = irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); + if ( rc ) + return rc; timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt; irq_type = acpi_get_timer_irq_type(gtdt->virtual_timer_flags); - irq_set_type(gtdt->virtual_timer_interrupt, irq_type); + rc = irq_set_type(gtdt->virtual_timer_interrupt, irq_type); + if ( rc ) + return rc; timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt; irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el2_flags); - irq_set_type(gtdt->non_secure_el2_interrupt, irq_type); + rc = irq_set_type(gtdt->non_secure_el2_interrupt, irq_type); + if ( rc ) + return rc; timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt; return 0; @@ -81,7 +88,10 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header) static void __init preinit_acpi_xen_time(void) { - acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init); + int rc = acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init); + + if ( rc ) + panic("Timer: Failed to configure interrupts from GTDT: %d\n", rc); } #else static void __init preinit_acpi_xen_time(void) { } diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 120ac09d23..eb608ab8b4 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -1928,6 +1928,7 @@ static int __init ns16550_acpi_uart_init(const void *data) struct acpi_table_header *table; struct acpi_table_spcr *spcr; acpi_status status; + int rc; /* * Same as the DT part. * Only support one UART on ARM which happen to be ns16550_com[0]. @@ -1959,6 +1960,11 @@ static int __init ns16550_acpi_uart_init(const void *data) return -EINVAL; } + /* The trigger/polarity information is not available in spcr. */ + rc = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); + if ( rc ) + return rc; + ns16550_init_common(uart); /* @@ -1975,8 +1981,6 @@ static int __init ns16550_acpi_uart_init(const void *data) uart->reg_shift = spcr->serial_port.bit_offset; uart->reg_width = spcr->serial_port.access_width; - /* The trigger/polarity information is not available in spcr. */ - irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); uart->irq = spcr->interrupt; uart->vuart.base_addr = uart->io_base; diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c index a336241033..97c53c11e0 100644 --- a/xen/drivers/char/pl011.c +++ b/xen/drivers/char/pl011.c @@ -363,7 +363,9 @@ static int __init pl011_acpi_uart_init(const void *data) spcr->interface_type == ACPI_DBG2_SBSA_32); /* trigger/polarity information is not available in spcr */ - irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); + res = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); + if ( res ) + return res; /* TODO - mmio32 proper handling (for now set to true) */ res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address, -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 24 20:58:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 20:58:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433043.1653891 (Exim 4.92) (envelope-from ) id 1x9qWM-0005tE-Pm; Thu, 24 Sep 2026 20:58:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433043.1653891; Thu, 24 Sep 2026 20:58:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWM-0005t7-Lq; Thu, 24 Sep 2026 20:58:22 +0000 Received: by outflank-mailman (input) for mailman id 1433043; Thu, 24 Sep 2026 20:58:21 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWL-0005oP-Ar for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:58:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9qWK-00HWJ6-Ny for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:58:20 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab58ebe-e002-0a2a0a5209dd-0a2a4501e560-46 for ; Thu, 24 Sep 2026 22:58:20 +0200 Received: from [52.101.66.86] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab58eec-5984-0a2a45010019-346542567440-3 for ; Thu, 24 Sep 2026 22:58:20 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by GV1PR03MB10503.eurprd03.prod.outlook.com (2603:10a6:150:16f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 20:58:18 +0000 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28]) by DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28%5]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 20:58:18 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kcrtg0u8XideqywdwzVLW1qFyOrF+fQW9OfUJ5MFRaZij363b61NNhvkcDd/Nw+dHR8wCohcZ9ZZJFgrWalKOBNI8nGnqwOPyqkeklXWTjxZo3RkjSdWOzViYDmPGLgkAc6UBk4pLbWWlhWN6Ug6G+YG+R3qWN16sZwyxUpn685wkML1PHAIZSgLOsllwC1wX4jE3EN0wi3QtK1nUYD1Invziljb5dJo4Clq/2/mGPZsgmDM/Mu06p4gHGsWNfIwB/SqGcfY3RxMFfNXlv2XhDryhktdCVUDgG8YwrHx+3HbflwnLCFl1Bji3AnMeYJCZeaMnRNq/sVrTyfZ+wG84w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XZJm9VptMgDBtMucbsn2Dy/QZZTYVwTGm6Ztac11StQ=; b=OSDWt047dQq7kHiJu5n8vHwg6UGozeRTXEGogxoiiHugPntlvEtXi9BlZ4N6BKLZWTSZDnBUaM6OPltDIaAO0KiXAtlI4tTlNvx06luI8EdIvTuLLNUUjpWU99do0AgjFwUBkw0whJ8XimcjcE7ektwRJ0b3pHdeRo3OV0sqk0g5xnmFcP2JYeuCWbk/LRH3pP0axPDWcK0maS9Ally88JLoAnbhjnvC4SnZbY7b59vcJqN5TqUD3roB+XiB7znfS8h7pbglDWbAuS1nGSwdocBUewGkcFUIwlcF7dtZAn6pglFWPTEy//9ZPOSuI2bo9Hq1rzAbJg0/zenc3sRnhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XZJm9VptMgDBtMucbsn2Dy/QZZTYVwTGm6Ztac11StQ=; b=VKFbK7WPkyKGdvQ7JVVIUeVus5R45nQZhPOc30v1RsueK3Cerk+TQ+NBOcC4e1RdRmWWwadOo6heo7pifhMzBcqt0aZHI6DXOGXy9WX4mVTYIuDQjlTnDKGSHnEWIuEauikV7blMdf9z6LkQmLj1+OYLXzYjKCN148mfbDsj+kAnaBC8bGrf+H8WrJ8I9npib6/pHItoArW9AKxeBs73TuhMBEA4UgFOZYiBuE5qrLQJj7bLGTmTWH55gpqzu64OSYG5QmK3KaxgdKw5kBORaZC6dTq/6foeoRbZWpf4jNGJzALnIEcEsS8ixqJ3rIK7emYC6hhPU5nI/a+lJgGeRw== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v5 2/4] xen/arm: make is_espi() a pure range predicate Date: Thu, 24 Sep 2026 23:57:54 +0300 Message-ID: <8aa55bb41ec944bd249a77959e7702e001a8329d.1790160605.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0022.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::22) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|GV1PR03MB10503:EE_ X-MS-Office365-Filtering-Correlation-Id: f7ddf65c-3137-411c-56c6-08df1a7e8f77 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|11063799006|56012099006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: lBq4e3nCmNinhfdFSAPSZ0dosj47bmxTp8Jy93aHdy8DsZqKOK5ir/1l9Eq3eFILQs/zoUsNmH5zcWD5IX45+QYCJsxrHVxmBBZB2fE8d4TUgExCT74fijKDcGJ0Mg8pJ4dL6L1BvwVvoU3FeVljAMkXqbJ7QljXbWh2K81G/OIHNJ9bjZFHiJwSYTFvp1UVxdcxy+C86hnJ/mRkXmUbOSp6hbFiECVF2PdyUka6R1OXtOWd4jzdk8lvH7dzZznCttn5yehij9GiEFItCapq2JvHoor9HlxzLq1Fkzejmfm+eteDKIJf0uZEgezz2AT8aLyIHonXFM9ESJjSllAtPoDhTYAmK5xH3JGadNeMSCF/wqD0vQoHh+YRq3wyC1L1jZsrhba8i/EPUnNVCAsGHjCr2xksW9/p6BPr97uD5fdFG1ORwj6JIFlOlSUHJMIvg3RECJ7qaHmUwTl5kJmtN0GIEaL9zCwqm//vrjsfrLwoFM1eKC7yjFqr0W2YlMO87pYFrYF+b8cTqiwTs2BquF+/6J4Ll/pxRR2quZbw8QYBJtmV9pg7XPXRbuE4WMvDmORjEPhyNoHy2wr0habfjsp+Mw2EmWEC2zMCgD09z05t+UDhSy/l55zOS1yl1utZmDuNWBj4B/799dH5WAWa18RRWDXAzirxGC6f+UpyGd4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB3PR0302MB9208.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?0X3+vHs5s4xIS43txTFDDsc5XdtOEJJqrkbefXlDPinkKuxPB26oi8iLGDcp?= =?us-ascii?Q?bnmiGNDFUro4Xm/M/AFrv/HDjanj5JAymmvaDM7e/GdAsjFqXctxzOMHmtMj?= =?us-ascii?Q?wPPy1/L4qnpQQwa/GytaVOt49ZQbZco+IlYklC5EIhWmF94TaDvNqKWVcPiT?= =?us-ascii?Q?Oc9cYG0qkj20Ph4ukZ3selUjgQaNaWeT/XZXbHPckxXwqoB1JkSosUwMjbbI?= =?us-ascii?Q?5Z1hGPBk4og3mAdWACuD3IV+D9B9Ni0+ong0Kz/AnRthM3GYGdVZHaComLJG?= =?us-ascii?Q?eKH/q7ohIeS72aCA7nAv4lbjFbRImiyYTz+kj9ntCGXEAWaOKQgVTkXOoICO?= =?us-ascii?Q?FsbArCRNZJeKhzp3+X2fTomnXiLv+bCrqZ1t8ucujcMiNa3Sd/nRr01puDy+?= =?us-ascii?Q?MrI4hFz5FIZVtRt9UXTNzMiOO3k1pi5ni1Put5nWJ5uR5pD0lWGE6ngRdaSC?= =?us-ascii?Q?u8rBoUHyiY0IKknT5hG8zmo3immjbJ0iXQb6nkFCdUQyKVlNCL0vzWpsb3fS?= =?us-ascii?Q?/Bnf3FWms8wvLJqYFCZdvoSxq+/OjVbGMUZJGr4uu0swZb7uHI5y+BkmUBz5?= =?us-ascii?Q?mHUZHbJ71vjutOYdYfDqjTPRHiTXMWfiBJ0Qlf9TmWaJwl6QAVVu/YziERVl?= =?us-ascii?Q?i+Yol8Va4YS/mIn8zDQPHP69K/OuJX2LN+z52a+JdtgmNKMFA+B5zwm83FGj?= =?us-ascii?Q?MzWg5ZFKdSc7T0z47HOjzqV0W5SGtSlSZPjKy66l8AXTzqW61OAX1CY1JyFZ?= =?us-ascii?Q?8xxytPGeb3TdlNgVBaJH12fjfTqtj7N3/6Il6h3YI3Wwohga3mE92gnKEwLW?= =?us-ascii?Q?gQWwqsqAdlk0dcs2gDeknGYE76ziSwkYSAwoQuq2kDYB4JUOOW/lG/JZuyKZ?= =?us-ascii?Q?dDtuyHLcaeJKVOPGAavkZyW0je9aCY5s+nUba7r1q2xO7JvVNqRlHSSA3BCY?= =?us-ascii?Q?2nyP+I8VfAfNhiH/ZzulKLH6eBj2BwSGkOHNLwQaXJT0/meqlThxNRJhts7o?= =?us-ascii?Q?OzhVjBCZolq6N3PojNSGIgsGBFRbztowa1gI2bpYV81YSqSJ4ULadCZgihz3?= =?us-ascii?Q?utbyI8lIiD4tQbXgTswTjqhl+IblXRk0+7wuLxl7pkOk07siKSNt9GRnEiTY?= =?us-ascii?Q?cqXHwSTAuskOvCjdM4pJYRfbX/F4bsJQIalzWdSDEv3nzobbz35drqRm8tcn?= =?us-ascii?Q?vGR8Eybi7rM6htjXIkZTXPQEoNUuDglsF49wRxtrjIwwQZqY9slxGEUWareB?= =?us-ascii?Q?vfdH6vXLOxz4+xNV55aJtojWJsebCk4UvLAjTx+zm5wpiVpZRVK31o6JxlA6?= =?us-ascii?Q?mKIO5aqmJYIPdnpus3arMMXixjwb2EWxxQ0wJEiQbPxmhDoXbhQh+udT5ZF3?= =?us-ascii?Q?BzSd84Fqkvnga3O+/dDtbYJ5cbOJL5OkIb7XEB5aB8L4jOxdNYgkRxxgHrUX?= =?us-ascii?Q?XOZBlQ0kCYZYlxW/57v0r525nSnIYqle5C2+cuvP+fk4rpz/6lt9atcmJoOS?= =?us-ascii?Q?6qeAnJD7aFRFhbW8N7ePPUGiMTgBK66wX6MQe1JilhBNENVoF+RMxXUIhLnG?= =?us-ascii?Q?wzdnfoVO+j3M9dlWvrY6xgdVjKZlSJyWSCKc5lNg+sKc3hLUlMubpvl7Wy8J?= =?us-ascii?Q?x71l4/tsTLKiBzkIEp+jcDUxYqnBZGnw1nLhGSXsrPrtx6VKBemOySGR+gBd?= =?us-ascii?Q?MyoOqbpCtaBayW+nTOBZzWQjEyaFt4dFQSr0Z+W8ckrn/CBgVWNrIyxZU6Qp?= =?us-ascii?Q?hp4LL3frrA=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7ddf65c-3137-411c-56c6-08df1a7e8f77 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 20:58:18.6155 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: O+y03ZeGpq3XaKtwHHOC5sd7RRjDOKI28F+HxW5M3wfYmd/eFY/Z2/FHEivYjncf2jXW/tBrzo4OVIIg4C60Nw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10503 X-purgate-ID: tlsNG-d62444/1790283500-1E27A757-4B8DA43C/0/0 X-purgate-type: clean X-purgate-size: 5307 is_espi() currently changes its result according to CONFIG_GICV3_ESPI. Without eSPI support, it returns false, and its assertion fails if an eSPI INTID is passed. Callers therefore use it both to identify eSPIs and to exclude eSPI handling when support is disabled. Make is_espi() report only whether an INTID is in the architectural eSPI range. Check for eSPI support at the call sites. Use BUG_ON() if the GIC reports an eSPI without compiled-in support, matching the handling of unsupported LPIs. Treat virtual eSPI lookup without support as unreachable, with a NULL return from the espi_to_pending() stub. Signed-off-by: Mykola Kvach --- Changes in v5: - Explain why an eSPI cannot be handled without compiled-in support. - Make both espi_to_pending() helpers static inline and constify d. - Add ASSERT_UNREACHABLE() to the espi_to_pending() stub. - Preserve the unmapped LPI comment and clarify that an eSPI lookup without support must not occur. Changes in v4: - Clarify the existing is_espi() behavior in the commit message. - Drop the unrelated blank-line removal in vgic.c. - Use BUG_ON() if the GIC reports an eSPI without eSPI support. - Drop the redundant CONFIG_GICV3_ESPI check in IRQ dispatch. - Return NULL for virtual eSPI lookup when eSPI support is disabled. Changes in v3: - New preparatory cleanup requested during review. --- xen/arch/arm/gic.c | 6 ++++++ xen/arch/arm/include/asm/irq.h | 11 ----------- xen/arch/arm/vgic.c | 30 ++++++++++++++++++------------ 3 files changed, 24 insertions(+), 23 deletions(-) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 078049e741..cdae6afb07 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -348,6 +348,12 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq) /* Reading IRQ will ACK it */ irq = gic_hw_ops->read_irq(); + /* + * Without CONFIG_GICV3_ESPI, there is no IRQ descriptor or + * pending_irq storage for eSPIs, so we cannot handle them. + */ + BUG_ON(!IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); + if ( likely(irq >= GIC_SGI_STATIC_MAX && irq < 1020) || is_espi(irq) ) { isb(); diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h index 09788dbfeb..c29f3d04a3 100644 --- a/xen/arch/arm/include/asm/irq.h +++ b/xen/arch/arm/include/asm/irq.h @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq) static inline bool is_espi(unsigned int irq) { -#ifdef CONFIG_GICV3_ESPI return irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID; -#else - /* - * The function should not be called for eSPIs when CONFIG_GICV3_ESPI is - * disabled. Returning false allows the compiler to optimize the code - * when the config is disabled, while the assert ensures that out-of-range - * array resources are not accessed. - */ - ASSERT(!(irq >= ESPI_BASE_INTID && irq <= ESPI_MAX_INTID)); - return false; -#endif } static inline unsigned int espi_intid_to_idx(unsigned int intid) diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index e5aca17dcb..0ba13e18da 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -62,6 +62,14 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]; } +static inline struct pending_irq *espi_to_pending(const struct domain *d, + unsigned int irq) +{ + unsigned int idx = espi_intid_to_idx(irq) + d->arch.vgic.nr_spis; + + return &d->arch.vgic.pending_irqs[idx]; +} + #else static inline bool is_valid_espi_rank(struct domain *d, unsigned int rank) { @@ -78,6 +86,13 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank(struct vcpu *v, ASSERT_UNREACHABLE(); return NULL; } + +static inline struct pending_irq *espi_to_pending(const struct domain *d, + unsigned int irq) +{ + ASSERT_UNREACHABLE(); + return NULL; +} #endif static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, @@ -698,6 +713,7 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, * interrupt. * This can return NULL if called for an LPI which has been unmapped * meanwhile. + * This must not be called for an eSPI when CONFIG_GICV3_ESPI is disabled. */ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq) { @@ -715,22 +731,12 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq) struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq) { - unsigned int idx; - ASSERT(irq >= NR_LOCAL_IRQS); if ( is_espi(irq) ) - { - unsigned int nr_spis = d->arch.vgic.nr_spis; + return espi_to_pending(d, irq); - idx = espi_intid_to_idx(irq) + nr_spis; - } - else - { - idx = irq - NR_LOCAL_IRQS; - } - - return &d->arch.vgic.pending_irqs[idx]; + return &d->arch.vgic.pending_irqs[irq - NR_LOCAL_IRQS]; } void vgic_clear_pending_irqs(struct vcpu *v) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 24 20:58:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 20:58:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433044.1653900 (Exim 4.92) (envelope-from ) id 1x9qWO-00068y-5Z; Thu, 24 Sep 2026 20:58:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433044.1653900; Thu, 24 Sep 2026 20:58:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWO-00068i-0y; Thu, 24 Sep 2026 20:58:24 +0000 Received: by outflank-mailman (input) for mailman id 1433044; Thu, 24 Sep 2026 20:58:22 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWM-0005t6-M1 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:58:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9qWM-00HWLS-2v for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:58:22 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab58ea4-8faa-0a2a0a5109dd-0a2a450bd730-44 for ; Thu, 24 Sep 2026 22:58:22 +0200 Received: from [40.107.130.143] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab58eed-b7e8-0a2a450b0019-286b828f2f50-3 for ; Thu, 24 Sep 2026 22:58:21 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by GV1PR03MB10503.eurprd03.prod.outlook.com (2603:10a6:150:16f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 20:58:20 +0000 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28]) by DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28%5]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 20:58:20 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=meGH4WxeuPVP4MAZTO7adCw6H91j2xa4eIsAQzrF2xGl/tMw7Qjx/HJcjphAZfqDdnkek+3cRtyr2AdyYAJhUR/tT4+n87F0kOMi/unpRimLCNTJnxNTygMwWbYKUg93RXzOdyRuPBGUK2EktcLI10TmkO60/HLWwk8qZA9RT2XPlESgQP7W7rPDXd05XtL2vuNOLbE8wF7P0k1ruRy7nez9vI61WPp0+Fdks8kBggziZAEy9GgtZBvo7KyqtVC3CENjHuZq65rahnBuuOI0aYQZaaPIsHRB6vAQyP1BVzXYaLcVd8enwUjoNYedFkhFOv0gqzT+Sr+AM6G7I5UW5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S1X45a1bjO90dQ/nHOuk0lZMguN6rIuX4USnlTBTDpU=; b=zQVmSuapbvtoL4ahaByiL+fpeya/INXk/QIsQvGO8Y9ub/N9yYhAP2wSpZKRQq2DDngxqnQ5Tvcsi9CF02+ayJQaklaN0Ml2ampIir6PN8PFPzC5/CJVdAHNJphUrj/BAU2l6ErDD4T9Kg6S2+/9dJnFgoJ2mW0wSriPVIai3FpoVyL5xS/E1VlggjY9a48nDRDTTHQrwcxKuY5iyeXW7H/QZga4nhTY2zoVd6QiDFO5LMcoy8+TFQ/qvZxZhi0+Ez1oyErI73JH4776fGQNMv9gFchASy9q7CYhjKwTmLIOL1S9or4yzLa1qedsmGOM5QchMUjaNMH5eeahIqR0lQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S1X45a1bjO90dQ/nHOuk0lZMguN6rIuX4USnlTBTDpU=; b=uTMRvf0+yl9WAyAMOe9zEI6GuhObGerZiU3ZSlLN96KWuuCJ9McFOk8JJ6mmobPaC/QTkf0Hl1a4doF6P07ZH5HH25Te8jwMb10xWgFTAhQABFe0Ue6Cg/S7OpYJZNrPf1F97xOJS/XttsrfrdDH6GiZzzccbWOBjVWE3CpdZWE+S/01/r63SOq6QY9P9BcbzyKJE8GZMtAkrR+tZLnaBFhMGlBv3IQSPq45aVDoegM/s+I2J92jSgqhKCq84ifkiCgOKimQ9V6S/4XQYVgIcnnrrCwDqGLRagzNkicUp0wimSjLb+1kmzz6pckIkH/J15aXhilqkgCJCR/w01OHFg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v5 3/4] xen/arm: validate IRQs before descriptor lookup Date: Thu, 24 Sep 2026 23:57:55 +0300 Message-ID: <1cbd9431b0cacc1406cc1716636a305ebe2b7ed2.1790160605.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0022.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::22) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|GV1PR03MB10503:EE_ X-MS-Office365-Filtering-Correlation-Id: c63ba9f8-9213-4955-58bf-08df1a7e904a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|11063799006|56012099006|10067099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: /6T3SB/1OzZqAI2uTvkFUYH+52QjUY38IZtHUuliEZVPzic6gB+BzfFpIu+0OJQwcdZhofBwchkPySkQBkKTJyh0mquI2Srf8JxNgJ/BBCxWBFD6+BTUMfOfSiKvZV10ixl0Nu01Lw73MxNlE0bSxzfejFJVkem/2mVoM8OltL0se4LN4S1v6mjMS2UVlp0vD1FMA3WOhwbru5+Ye9H4wfQtIJGBhgAcCdQ9embEHDx2WQ5slI0R6/JvZ3M6/rt3fcvNPZmIjwdl3nTb5IXFca0vYIpl7ro7YXgwrI5zFsa16e4ouos4Mi0p5Zjzf70Ty96GPGwBnLYt+3cWkeMyKa/lETSMGd1w2PWfFMUYvEwgHlF0s5xetNcf6Qx0Mhydy0tgShxf5hFz75cBdrVIXOmGcakJR9447fdaemPZYDfvTySwI/Bsj+hzOO16N/okHfJpS0GgEaZSxKElgBGQtL36kzTJngU0Lb/VpHoAz91XVi7UgkaKZBWHf3ZfA1SHrMbKJFDUPeX5AtNs6ExxV7kLi2qrnnSVPMFcJKb/mn2BGdekWWsh++hKih0ATmunlE6nN5Xwca/k3o7uiCz84IWW5LMp91TFUPNuoLYPUb/FY52doXDilF8wDoko6UGSnbpkldY1DwjZZBhJnBC+gUtIuxOhThaNAhCaw8nBd4Y= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB3PR0302MB9208.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?vJJHrM18Iq3R/uRcifIEnrLvgXfWSJ+/SqjfeArE4sOnxvA4EDvo1wevRArF?= =?us-ascii?Q?cbqf3PmZgB1fRQsloIj818Ro2v1VW6MvagLJt0HxT+cG792QpFDQiByJlEeC?= =?us-ascii?Q?g3rfx3aVBk/xT1RowW4KDIrvLN3PRnMvrrX+K1VbHqIQYkkoUlX5bUaIWb1i?= =?us-ascii?Q?IfWGVVhdH4haClMUpT/lTeEDKOiefiFL7jI8ydCD+z8wS205s4N1QG8ZlQAR?= =?us-ascii?Q?2qTI5PLUzy1gMwjleguAUcuU8mHglpM2brVzEQWfH1bj9t10TNzGyjPjtrnB?= =?us-ascii?Q?OwIJ5zVcDNvc8RHx9MNtgPMhxRITASFsMw3Xt9f7Jr+8MZwKFnXBLAgCP0HT?= =?us-ascii?Q?iG6XvwTsmgCHPTLaZHp+HFnIkBhhcub0VzUPdHiu029xxrCiR7//UDC/eG7/?= =?us-ascii?Q?vlUBwynJr4KrQZSW/Uyz2/XvkxYG0OtMDl8IbefllNTV5L1shDpPwqSVsg71?= =?us-ascii?Q?jSVhHgR7RCZxe1aXHVS+39cIyH3wwhusopBvNHrWIHxTN7l7mAnsvK1ZvNpV?= =?us-ascii?Q?FJfc1DQOm5DzRp8UtyExligoFSiXlDgI+HJJf1vP680W1wrwdicQo6ujpdJj?= =?us-ascii?Q?tMQPtJjlDwtUQa0daw/EIB/k7VvI4f6zv8qZIb2lCm8VvnIVnn7p475PRC2g?= =?us-ascii?Q?YJBQgbzoQXWdkPHxCrknvXoQ66dZ3UlHLnnwto9dvqn55lR+iVUkD4V3UKbF?= =?us-ascii?Q?kdSUV9xAmeqUkHyX+h7QRVbPFNslYk4UAzf7JZj6V4Fp1aUJiUjMaipznByK?= =?us-ascii?Q?6U3Y/ZlIWcMPisu2DUCuC7DGLw5pf6n7+o37U5xI7qJ8/ZgnsPd8XVetNtCq?= =?us-ascii?Q?+pqEHpVJTfVpMaVr3yRjfLfHw9ddkM5pCzE7uxFNrbQoLIh34QXjpjFqFeam?= =?us-ascii?Q?wluUoW2BFNH9Ze/H5eGGYnJKAX45cSfFDZbITgn7Nb0HlF/1mgC1o1QL5knA?= =?us-ascii?Q?a/YbjEZVfJI2QeXmqQrbADFHqvPIC3NrzxSj77IQ0tdy+ufisTjuR7376pOC?= =?us-ascii?Q?2koSW3MYskLPj3saC1WD6IZS68WUhoGhyL/qG8sMu1+IGqP1fci8mdBvVHop?= =?us-ascii?Q?eOCkjfQLqiJGsnxYGD868CyibTWor/9GRXljJB2+v8jwtXB+bm1Ve/3cyZnn?= =?us-ascii?Q?J7kog44gXiNRc8FVKXNmhaxnVtzD6N5HYF2Vd6DpvXpycxRAQlREit7/LbON?= =?us-ascii?Q?a4AaIP3LiQ2rLlqPyp4DqekWkmLICsgK1Y41J1qwmHkW4GMABf0tauw3Sl7T?= =?us-ascii?Q?N5xiFzNllNTXf24WveuARzGmWJtzVnamjMrWij6oBP4K3oEQSWa7bXgMIhei?= =?us-ascii?Q?3+jQ85RTLnuCzHv6h7T8Zx646S8dTvOHDTe/atlIOx1PKJSa1BrNlg4yb3Xt?= =?us-ascii?Q?Qb+l3U7QCTmWCGCkU6HtAM1Syu5XOhWD8mNhiBagP/Qd39xhZ3rfrBf924FD?= =?us-ascii?Q?uVYFewnwE7oMXzXfv7RFu7gcrthwpTqEocmf0bMqUlWrRn+03GZK34gFaD+X?= =?us-ascii?Q?3XlM3rY0YYF33gYZzMfg3Ova/3aeuSrnrxyrS25IWEBC1D+KKU/5A7NM39pO?= =?us-ascii?Q?4cy76CIaTr6259s7rYcf6K23REotPkITbZb5P3xR8X1yagQ4/pgLEAqDMwy6?= =?us-ascii?Q?Y0KEGdeG1Ppsc3sqF1OXPc+gvgOyuXoSUH07kUCwuBRY23aMs2gjc+ZdR7Tm?= =?us-ascii?Q?PVMSF5AmkhyDxw0H0gztebxcjj7WzdWMYCA7ogzp1df8pjRQOP37ZaN3x95p?= =?us-ascii?Q?RzzJDLGcWA=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: c63ba9f8-9213-4955-58bf-08df1a7e904a X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 20:58:19.9926 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qpnoNm2mODLXOh8cXzFqM7EN3bqOT8tWJCR/Hv0B8Lg6ii0USaoShez3waoppJv1FvGkaB38060itjhM24RMow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10503 X-purgate-ID: tlsNG-42698a/1790283502-18AC89EA-79862BB6/0/0 X-purgate-type: clean X-purgate-size: 3693 GICv3 eSPI support makes nr_irqs span the architectural INTID namespace through ESPI_MAX_INTID, but descriptor storage is sparse. local_irq_desc[] and irq_desc[] cover INTIDs below NR_IRQS, while espi_desc[] covers eSPIs. INTIDs 1024 through 4095 have no backing descriptors. Validation based only on nr_irqs accepts an INTID in this gap. __irq_to_desc() then indexes beyond irq_desc[], and callers may lock or update unrelated Xen memory. Reject INTIDs that the GIC reports as unimplemented in setup_irq() before looking up a descriptor. irq_set_spi_type() can run before the implemented GIC line counts are available, so validate descriptor-backed ranges there before looking up a descriptor. Use the same descriptor range check in irq_set_spi_type() and the assertion in __irq_to_desc() to keep them in sync. Log the IRQ number when setup_irq() rejects an invalid line. Fixes: 98f7060b9ed5 ("xen/arm/irq: add handling for IRQs in the eSPI range") Signed-off-by: Mykola Kvach Reviewed-by: Michal Orzel --- Changes in v4: - Share irq_has_desc() with the assertion in __irq_to_desc(). - Log invalid IRQs rejected by setup_irq(). - Drop the unrelated blank line removal. Changes in v3: - Add the requested bound assertion and retain the SPI-only comment. Changes in v2: - Validate descriptor-backed ranges in irq_set_spi_type(). - Validate implemented GIC lines in setup_irq(). - Preserve is_espi() validation with CONFIG_GICV3_ESPI disabled. --- xen/arch/arm/irq.c | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 73e58a5108..8d3517e761 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -85,6 +85,12 @@ static int __init init_espi_data(void) static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc); +static bool irq_has_desc(unsigned int irq) +{ + return irq < NR_IRQS || + (IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); +} + struct irq_desc *__irq_to_desc(unsigned int irq) { if ( irq < NR_LOCAL_IRQS ) @@ -95,6 +101,8 @@ struct irq_desc *__irq_to_desc(unsigned int irq) return espi_to_desc(irq); #endif + ASSERT(irq_has_desc(irq)); + return &irq_desc[irq-NR_LOCAL_IRQS]; } @@ -416,6 +424,12 @@ int setup_irq(unsigned int irq, unsigned int irqflags, struct irqaction *new) struct irq_desc *desc; bool disabled; + if ( !gic_is_valid_line(irq) ) + { + printk(XENLOG_ERR "Cannot set up IRQ %u: invalid GIC interrupt\n", irq); + return -EINVAL; + } + desc = irq_to_desc(irq); spin_lock_irqsave(&desc->lock, flags); @@ -647,13 +661,21 @@ static bool irq_validate_new_type(unsigned int curr, unsigned int new) int irq_set_spi_type(unsigned int spi, unsigned int type) { unsigned long flags; - struct irq_desc *desc = irq_to_desc(spi); + struct irq_desc *desc; int ret = -EBUSY; - /* This function should not be used for other than SPIs */ - if ( spi < NR_LOCAL_IRQS ) + /* + * This function should not be used for other than SPIs. + * + * The implemented GIC line counts are not available when early + * callers configure IRQ types. Check descriptor storage here; setup_irq() + * validates the implemented line before the interrupt is used. + */ + if ( spi < NR_LOCAL_IRQS || !irq_has_desc(spi) ) return -EINVAL; + desc = irq_to_desc(spi); + spin_lock_irqsave(&desc->lock, flags); if ( !irq_validate_new_type(desc->arch.type, type) ) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 24 20:58:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 20:58:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433045.1653909 (Exim 4.92) (envelope-from ) id 1x9qWP-0006N5-Bl; Thu, 24 Sep 2026 20:58:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433045.1653909; Thu, 24 Sep 2026 20:58:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWP-0006Mw-8K; Thu, 24 Sep 2026 20:58:25 +0000 Received: by outflank-mailman (input) for mailman id 1433045; Thu, 24 Sep 2026 20:58:24 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qWN-00066Y-TF for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 20:58:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9qWN-00HWJ6-A4 for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:58:23 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab58e9f-e002-0a2a0a5209dd-0a2a4502901e-28 for ; Thu, 24 Sep 2026 22:58:23 +0200 Received: from [52.101.66.119] (helo=DUZPR83CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab58eee-6ca4-0a2a45020019-346542773085-3 for ; Thu, 24 Sep 2026 22:58:23 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by GV1PR03MB10503.eurprd03.prod.outlook.com (2603:10a6:150:16f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 20:58:21 +0000 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28]) by DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28%5]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 20:58:21 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FZF4JepcOw763500uSu/hpe9KrjlsR5DxLumocDnDjJPfTx/zdqNEljc2nYDaSUwi7PGsouMbUqo3Ptjf3PWP8dG+e3WnWcm+0E3hgSpdTjJ9tGc9wW2pGahHywN7ioLTQa8BmOJ2VBI7XWxOBBqfjSDdHzhA23NyRCRPhuWeq+k2IjbswnwKRxbTKKhPrQz9vAAnAWrt3rQ++WnLlVHCcOGnSWgH2G6RQpP09mVtdhmWnMoTBhZAs2A/+LP7SpaXBeBMGgtT6A3om4yICUBlLGSRqWu6pGp9csxR/0Ho9tbqVm85ksfHE0dz1g2Gi4xWCFFj3cVHB9kmDgMlkBeCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S2lkmYG7n/ygHugPAF7XixSg3rxPx+xoxz3SzwwUq4A=; b=gu/a+pFbwdPLDgtgaitaS+DGxuX6BtWOUeiSoNZgM0+Po9uBdHhCus19exaPkOCENhiTTQ11tYX+hu5U6Vjhdi7y2SKoKGc8y02L0yYGgjegaaZuCMK1itD4WSSOMY5PZ+EsOmHnqGme4mBsE4ZxoGWCFQnTEtYCMFvLe1mdzsDbrONhyp0xe8Sy6uEOuVsGWG/LQeDJqAgSvdZ24uYUnH1V5i0dJWTcgBp6Y9L1wlKm4XIvpC1pMKOcd9O7fAZBcKjrSgkXn5xIKST3QcxH0XMnIxpvPVUvQGATYiq5htJCgwnS9GbtNk0dLrLGEpBqgQcnhZZclWc0h/ycB4UKpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S2lkmYG7n/ygHugPAF7XixSg3rxPx+xoxz3SzwwUq4A=; b=LmUZzgx6IfigCIvLDEu6u/REWpqjw6IARYvIwLf/e7LHwzMWm022+oSbKenj3dVd/P2sPDIiZqA4MpMvGN88VGlvicX5X5tU5n9pfvpSqNmgRAhsZiys5A26SC7Es7g0eB9vUfXeLv3zId/27V91pWx9CFm3cf2VAVk/U9fn7TtU/nRJ21VIjcRp+EcR80OWMkzkFonLuJ7zjLaa3FtWO2HD9hnztEr65G+xidTEbTZ1/2DRR71ydWNdR5qTgp4ByEp7mH9UM2iyw8C9D6Te9gwijBPkmFpeedsHADAr8Fgjr9dd76EQ6UisnkglPRSUFmFOHHJXRMYZJg5F8Cjdyg== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v5 4/4] xen/arm: vgic: free eSPIs using the bitmap index Date: Thu, 24 Sep 2026 23:57:56 +0300 Message-ID: <8c61cf31b69377737d1f688bded43d123ac55d00.1790160605.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA0P291CA0022.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::22) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|GV1PR03MB10503:EE_ X-MS-Office365-Filtering-Correlation-Id: e722cc51-7bf7-435a-5f8a-08df1a7e9118 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|376014|1800799024|11063799006|56012099006|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: 21UexnDn8z+7il3TUWVxXY4u2DdhvoBu9QfkJFiRXSuwDhsBXj64QvheeIqoLpUdevetUyS0cBxbPtSL55OsSKdor5pGA1HrpbdxLP/9klLARWxDuV5sDv6Cqp3reHd4Qh4NqzB4yW96v666U/Q1DjBro1bvwZBf4+maiojanq+QK5CCkwQYKtzrfb/+6jrrIIWCxV9+/5aqKnU17ko/z3lM5Di96fHWz/ynM+rI79o0jVIDmRyP1CAZRgNIJYj40Vm55JksdvKd6cEKvpQu6tQ5P/hpUcoufRsywuc27W2PaE01xc4S4xcUmdXYDgrUySdjHtqLx1Apqruh9NO2sJ+4Y/Oauqt8Qky0V0yigI0HzvU+VPIa/3jTLQYW5FPeMIJbdObu0tk5/fcTIthU/bcUwnFktnEPI/gs9x/ajCY5PNlCrFcJkRGs35MqGS89UAAoKo0sBjxOYT5GWBZAyLzjVpqyNwZb0iyPZhzVMf9PXkQ96GCmX5xNLSSAxZ2MSj2eJNZyWxQ+DDDFXFjvfEoTaJv5JjC3A2vkt6/yd/Vor74zBUJn1kLq973W79mWYz51CsGhdZnFlBmG9iX0BGkeiFQx0fM1n6FGRcASMOlKFu4OGE2AGdxgmghBFETG6qdYeJ89w7vVmEKTMNLhJGDO0ArGOoIpeRiKofjAyBc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB3PR0302MB9208.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(11063799006)(56012099006)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Fo6khaXhSFPvxngmiZTTRkWTqeTS1eZtt1lDCLOYdb6VXxny46WodMZKqzhF?= =?us-ascii?Q?MZYpGkppPbGmQSNp+A+KXEbwPgNccd1sO+06nj1o65eh4zF4hVMNedPhxpsh?= =?us-ascii?Q?6vLci+QPbgqSRmI4P0rSq0jd2bwH3hf9N52dLY8jDRQ0cNjDLJM7vL4mUk+N?= =?us-ascii?Q?5rL/DBpc0pPGXvIsfAG9Wo4NDBAS6IYLIyshcTKrV8qhgE6WkWd1K7suL1OB?= =?us-ascii?Q?9kEYzWcBJ496bbjje/KHI/IlukesGLU9s9/FWKUhvhaWFMxrl9IeK9vFdb7q?= =?us-ascii?Q?dIs2M0qNfBDUzb4C0qdOQJko+nFcHtQNHdAC9zmtl06QEGdqldCIxw0knU4J?= =?us-ascii?Q?53I2YNNjniXYu2d9YGBhRnIXsFRxICHeWcIxOP6ORWqib1hJDBwmb7u3ht3p?= =?us-ascii?Q?Q1l41yF1oezLIEwTOlD+8NMiOLUew00rjuHDJ4nkniOVehI6vmi2QTi96Efp?= =?us-ascii?Q?DDryVLN8dx182D25+oqVkj6Wr0P6qefjerdVKesS86icY+d9LenTxwKqEdwo?= =?us-ascii?Q?0lNuIP3WSj+sUDEx6Kt5ZsjwDd85lySA+ILcZoZZGq0to7hlpzb8IJw4m3S6?= =?us-ascii?Q?yHbI/iHqjzRbbgf43I/IM6CEyyUg25Qt6E2WAtkB9NXmDxpq6nDT5DuNvrI5?= =?us-ascii?Q?XU0/ilMZhVl1E+XGACc3aTQt76Mj8Mvjw2VE3aaZbMtr5fIYI1iFYXdwpwfi?= =?us-ascii?Q?2saHlEnuKUcgVSBRNJQWERrdSiPxT16zo4/OaQspHAu5rvG9aHqoZ8x2F357?= =?us-ascii?Q?Tcc39wehUGWdk0YKza7qjZpvCVSMVuOKLnGfSnaK0tIcMfYafFr2KFDXDUfA?= =?us-ascii?Q?o/7c2X+8NU6siS+7iSYi7zKvuVrTFJpgHdZmpo9h0hTfzayvibpePui4RSbB?= =?us-ascii?Q?oeNuXqnSBfNQE2Lrs5/F5/36ewBVs9PrAT/Nzq+K8esIIXx6lr6/423RiCvE?= =?us-ascii?Q?uA+TbqwvfA6Nob/T6woZRfllAmQ0OajW3Inr6T1ZcdLOCENxISxWz56zjWUf?= =?us-ascii?Q?nI80kf+6ElNHkEy4/meYhZZp0z2zZiUErv8fks9Tx7vEMIAL4vdG6eRSE2i3?= =?us-ascii?Q?dIp7iaIG+7AdpubK9Fx0pkPDZFupFZbo8rv0UrdHGCGJ/XVDYqZcAWuTfukS?= =?us-ascii?Q?gNHvTpcLxe+B0knqHgZGwrmtUHxPsKUcQEkEaWTRqbIXTWgzDlRXaGDFuxT1?= =?us-ascii?Q?RSQc7HMfqKcq3xB5dOX/BTRBGxbK6HSzGkQyNx4lEH7ZLMmRNLyzEXLKeOxO?= =?us-ascii?Q?Z+iy9WJ/r2/M2/8wO1Brljmxf23DTH/jvH5IWA66R5J7L4vdUVYyB3FVpzai?= =?us-ascii?Q?Aw80RubBTPqnaRuj7ncPJLSxSO5tnfda494QuMw3hQSbCGuZrkf8m/TQds2R?= =?us-ascii?Q?tBEaj5iAaGxK2OhqnT9cuUeaGCY2djfIj/hFeiaWmVIFh3QjpZCQWKtGvKIM?= =?us-ascii?Q?nj5DPnhCtbn7Anbv9bsspHaMfiLHHnE2UVEgdeYbo+vHT2OoRXdUKz9Kwdw2?= =?us-ascii?Q?iBq5XTim9O6aTqNyBafDoj5RUD39dCi8HyB9Fj1EOqy/ThpodMtFRrDejKAr?= =?us-ascii?Q?Ox+EjAgQMI94WQAlooY2WXIfjmXfEHqCgcHDlLf2KfHRoNzUNZvH7Mhlurjr?= =?us-ascii?Q?pl8eKtlpGn2BO6ioKHc/7kJQ9czCXeKykDiklyBUymhKiKz0YkGjNE3wU03O?= =?us-ascii?Q?/pW5xM8u8AsvXxUMBaXVdo4IMl372o4rp23lRDtMFAyMkfzM+aE3sRfDESjd?= =?us-ascii?Q?KTGxpb1t1w=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: e722cc51-7bf7-435a-5f8a-08df1a7e9118 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 20:58:21.3556 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +zGqKfQwZA+8/tDR6B3Ix3kE+UCinS9VsQt7aRvP0f7Z6G/pxFmjrRL9pVmWGXScPQucaiJvUauHTLdpmsGviA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10503 X-purgate-ID: tlsNG-720697/1790283503-F10A02AC-A3A39AA6/0/0 X-purgate-type: clean X-purgate-size: 4869 The allocated_irqs bitmap in the existing vGIC implementation stores eSPI allocation bits immediately after the regular vIRQ bits. vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index, but vgic_free_virq() used the raw INTID. Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit. This writes beyond allocated_irqs and leaves the intended eSPI bit set. Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind, and during vPL011 teardown. Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving and freeing vIRQs. Use vgic_is_valid_line() for the validity checks when reserving and freeing vIRQs in both vGIC implementations. Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended SPIs") Signed-off-by: Mykola Kvach Reviewed-by: Michal Orzel --- Changes in v5: - Add the vgic_is_valid_line() guard to vgic_free_virq() in the new vGIC implementation and use the same helper in vgic_reserve_virq(). Changes in v4: - Document the compressed bitmap layout with an ASCII diagram above the conversion helpers and refer to struct vgic_dist for the full layout. Changes in v3: - Adapt virq_to_idx() to the configuration-neutral is_espi() helper. Changes in v2: - Call is_espi() without a configuration guard. --- xen/arch/arm/vgic.c | 42 +++++++++++++++++++++++++++++----------- xen/arch/arm/vgic/vgic.c | 5 ++++- 2 files changed, 35 insertions(+), 12 deletions(-) diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index 0ba13e18da..acded6a40f 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -25,6 +25,21 @@ #include +/* + * The allocated_irqs bitmap is compressed: eSPI bits immediately follow + * regular IRQ bits, skipping the gap in the INTID space. + * + * +-----------+-----------+-------------------+-------------------+ + * | SGIs | PPIs | SPIs | eSPIs | + * +-----------+-----------+-------------------+-------------------+ + * 0 16 32 vgic_num_irqs(d) + * + * INTID ESPI_BASE_INTID maps to bitmap index vgic_num_irqs(d). + * The following idx_to_virq() and virq_to_idx() convert between INTIDs + * and bitmap indexes. + * + * See also the allocated_irqs comment in struct vgic_dist. + */ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx) { if ( idx >= vgic_num_irqs(d) ) @@ -33,6 +48,16 @@ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx) return idx; } +static inline unsigned int virq_to_idx(struct domain *d, unsigned int virq) +{ + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(virq)); + + if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(virq) ) + return espi_intid_to_idx(virq) + vgic_num_irqs(d); + + return virq; +} + bool vgic_is_valid_line(struct domain *d, unsigned int virq) { #ifdef CONFIG_GICV3_ESPI @@ -854,19 +879,11 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr) bool vgic_reserve_virq(struct domain *d, unsigned int virq) { - unsigned int idx = virq; - if ( !vgic_is_valid_line(d, virq) ) return false; - if ( is_espi(virq) ) - { - unsigned int num_regular_irqs = vgic_num_irqs(d); - - idx = espi_intid_to_idx(virq) + num_regular_irqs; - } - - return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs); + return !test_and_set_bit(virq_to_idx(d, virq), + d->arch.vgic.allocated_irqs); } int vgic_allocate_virq(struct domain *d, bool spi) @@ -903,7 +920,10 @@ int vgic_allocate_virq(struct domain *d, bool spi) void vgic_free_virq(struct domain *d, unsigned int virq) { - clear_bit(virq, d->arch.vgic.allocated_irqs); + if ( !vgic_is_valid_line(d, virq) ) + return; + + clear_bit(virq_to_idx(d, virq), d->arch.vgic.allocated_irqs); } unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version) diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c index ba029b8a3b..84212bbefe 100644 --- a/xen/arch/arm/vgic/vgic.c +++ b/xen/arch/arm/vgic/vgic.c @@ -712,7 +712,7 @@ bool vgic_evtchn_irq_pending(struct vcpu *v) bool vgic_reserve_virq(struct domain *d, unsigned int virq) { - if ( virq >= vgic_num_irqs(d) ) + if ( !vgic_is_valid_line(d, virq) ) return false; return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs); @@ -756,6 +756,9 @@ int vgic_allocate_virq(struct domain *d, bool spi) void vgic_free_virq(struct domain *d, unsigned int virq) { + if ( !vgic_is_valid_line(d, virq) ) + return; + clear_bit(virq, d->arch.vgic.allocated_irqs); } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 24 21:01:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 21:01:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433077.1653918 (Exim 4.92) (envelope-from ) id 1x9qZc-0000Xx-P4; Thu, 24 Sep 2026 21:01:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433077.1653918; Thu, 24 Sep 2026 21:01:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qZc-0000Xq-MC; Thu, 24 Sep 2026 21:01:44 +0000 Received: by outflank-mailman (input) for mailman id 1433077; Thu, 24 Sep 2026 21:01:42 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9qZa-0000Xj-BG for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 21:01:42 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9qZZ-000iG7-BZ for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 23:01:41 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab58fa7-8faa-0a2a0a5109dd-0a2a4509b6b4-26 for ; Thu, 24 Sep 2026 23:01:41 +0200 Received: from [52.101.83.77] (helo=GVXPR05CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab58fb4-be1a-0a2a45090019-3465534d28ba-3 for ; Thu, 24 Sep 2026 23:01:41 +0200 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) by AMCPR03MB11903.eurprd03.prod.outlook.com (2603:10a6:20b:76f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Thu, 24 Sep 2026 21:01:38 +0000 Received: from DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28]) by DB3PR0302MB9208.eurprd03.prod.outlook.com ([fe80::f257:38e:c0af:df28%5]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 21:01:38 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=K6jgf7HiY8hh2FLU4Y2+G8WSynCroKfT0T2npJB5vTjCzs0dA6f53dezVRG11EyEJQ7/GtYGtcxhxNEwKEPFvMyYCMO/4bkpvLB74iaYXTQ8olYT5LJyBb+CilQXcYJVA5/FHCS++gH22/juSjaIORbSJ2Nx9x0FxTrE69M7JbC3FFdwafA7BrrcfFGFcsciA+5sebrYPAuXOmAtcyBpDNz58YRehce4FiatUb48qP3dI89MVcns2kZ5Q8V8lIsBDC7ywX/KL4tA0yK435+v5jgzLtTE4CYNbkFyVQv0QoVelGKr3b+hghUzU7MhzNABEruMty97tO438jsWAlM5MA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DynQrCIYzpoukoQqiq/sboDfmzo/Zj/QuvlwnQu+MVQ=; b=cNNQK2Bn6Y9+245vz2hJ1cZtrQXVmbZtry0xWbCcDMsXZTpYUD/c2kbrULvSvZUepwUh+6AxvQfgyoXuT9K3eIV3VeBa3y9usTFS9liJ/C8TihP+J8aZKDxlVMH24WVxVymYLvIZARkZPq7PYIG0Yz0cOg/naaykSxwGNawr2+JRnbUpoWv7iUj1Uvd7JjxTNqioKZER/quoC8/STensoYkt8nIQNpr5jdaVXu9X9yoqwz21jqjPzKzZLWjxizXlqK7PGach3LOjxUIcfoWvgklfMxA9FkPfRj558qYQk8aNFqvwRG8TTW3cMeUuJHl75levfoBJbn+Y9eoc7BbLpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DynQrCIYzpoukoQqiq/sboDfmzo/Zj/QuvlwnQu+MVQ=; b=fQ0RqZw1rMixvzJgU6xw1ynAaHcTV7HxjE9MwQdNZTn++5723k2LhtO+CaV62GuUYd4D9Wwa2bzm/IB4cHhIMFxSGbrR1AMmoghQLgSNrMRaYJWr/vxToMlz+GOmgvUmhlvIjrt0cA+naJN5d0x47bztnLOCys6XiLluAQ3V8ipQDP0VKtvRDaKqnDm/cg90PlrVV/BUyQi8UGWnqLExFAL3FxfiCUtzq6U4NtphypzwMb7aDP6RQMqrjNVOuymLmiswk2tCj8j6H79YluilCDEJGLWBUMBJQB9qDeTpaNdOV+C8Esqu7CEx9RmfADYA5ws+pcLsTwgXaygZhdgaQA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; From: Mykola Kvach To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v5] xen/arm: derive GIC CPU interface ID fields from the vGIC Date: Fri, 25 Sep 2026 00:01:29 +0300 Message-ID: <4f24dd8cd9fc76e8c3f93bca44bb58056cbcc51a.1790147101.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.53.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: WA1PEPF00005B8B.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d8::63c) To DB3PR0302MB9208.eurprd03.prod.outlook.com (2603:10a6:10:430::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB3PR0302MB9208:EE_|AMCPR03MB11903:EE_ X-MS-Office365-Filtering-Correlation-Id: 247959e7-2ec7-480d-48c5-08df1a7f0670 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|23010399003|10067099003|5023799004|11063799006|56012099006|6133799003|18002099003; X-Microsoft-Antispam-Message-Info: SkA0tAFaixTP+fUqlT4V3hOfuIFFCwoDhUYVLddk53mDlPD/6bsyoZsVijoYsEPDPQYtqaKRPmBEj6oWPF4509CecUK+aa7FrQ7JVVR6ZMoWK5M5exZ4iWu/jetq1Lbi8x5GXQrFJVsqxr8JFE0MFMiHRo6lC8Hgv5+LN2S7FL83pdmwysOHKIRJT9+5FLAlWstMVszniKhFHvqSILuKBxfRy7/MVp2U0kKUr4E4RppUHBgQlK4J5XSs0Y+ZwgEyRg7W5Yu6B1qfeL1NitA+cwRk+eCq20C3ewCFqU3cl/81ypd0WpiKX5qBMlIclfkL0A56J16q4WAXs60nkEUY0q+/bflG4/LSyFKmCyXg7x7YukQnCXPbTiRLghYOEdAt7Aa2Ce7L0sm+MmCQZnofXUged36pVqsIdz9LSmwY2CEEOe0vm/LP/YTWsOEKhOoP4605KOXjc2i4TIMtZ3YWssrUIv7U2pD9Ucfdo2/8+0oEcmayv+KlT5w0nDPxc5LJQOs69gAAodDz3cPREHQOJV0O1ceS1jxMjO1LMq1Vmpz3wP+stFh9YB2GUrwOPzahcCzYzv4WI1hAK2GyKE+ggNzABapA6XFEpN6Q48Ki+No2VGecrRl7yfu8W2/wjRy+ X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB3PR0302MB9208.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(10067099003)(5023799004)(11063799006)(56012099006)(6133799003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?aJvmpt8k80aMBZtP5X2q29v+qxbTWEoflW8TVUYdc1QUb9yIlmrftZX2cTyc?= =?us-ascii?Q?BMHnKNyDn4qU72a2ffkzUgbJ5SBq350jfWl3vz0ustilIYZB9+CvkP9fhVh3?= =?us-ascii?Q?0tK4IHxcJsq+TyeNJpyxUES0adtJvZiL0iWL/sfylkcn4U5DCQcTZ50zq54x?= =?us-ascii?Q?kLgH8caIrzlEeCrqVVRZmQk8uJlYQGfKc6qSumZV3eunmC5yFcNbsJgwKHyr?= =?us-ascii?Q?N5NiDl5NmCyweDjrCQuXaoj1b9S3SE4TCX5wN6r2KCVXIr6S+CP355G4+oFQ?= =?us-ascii?Q?PJYNLn5Il+9df4xQY4wuqhExIc6DIg7gcvTtFiIFgZo8h+XOfbJeMxJ24NBb?= =?us-ascii?Q?BXj0YUh8hdQlTvzNyvrrywRk+hzNhwrnKSOAfrJ4Nb8NoU0seHqcYQFfRGTr?= =?us-ascii?Q?sw4L1Q1zCamL0TwHZxpStiSyO/dj4u9UjaRl8fJ1ZXKJuFJxQNDWf/6Fx0k/?= =?us-ascii?Q?nW4STrgVq3uvMujaJ1zLBZ8JtrZAxw4FWSl8T2r4PXFy/FP8/Xu5fNZSFmx+?= =?us-ascii?Q?DfCtTLCkdmp6QJSn5P2mtogxNKMUUBnp0z0Z+RvUMIF9pdXbCjHjglQn+MUG?= =?us-ascii?Q?cKAQmKQelX1MYfVR6fuzosVX0aged0cNIQ+3MV+C0uMC78eOZHX9b9plgTxr?= =?us-ascii?Q?M6c0TaigzSk/vO7YhA1z+nUbQb0zw0THaKXtugdMm1CG6BGzjM+OsRTAQZi4?= =?us-ascii?Q?ae06hMQKiBLdiceMMQW8BBmUXSWA42qUpSTbrTcUATkrSUZ4J3+bsRC+I/Xg?= =?us-ascii?Q?g97QCEIfIwDYT8NwbXAGBdYdvzu3hEB6o4EvJmX0qwCw2/UEH3n8u8R4nf7C?= =?us-ascii?Q?JBD1fLVbpDX1nLErFmSU2bcJMW6KgeIr1VbFRYhY4E0ZFqzEk1AP0xIpzMYg?= =?us-ascii?Q?0yf6omMgJKky+agnbZTrXm6z/mFGMEnAZpf1acJOwBEvAP5cRDcgL6PYMrzP?= =?us-ascii?Q?chw64zaegbAyR8Nh/+eiCZx2vGW29vr9fGkfXn9lGJJJrn6zftAswWALl9cQ?= =?us-ascii?Q?arCLQzxOBxglDSRNzPtdp+8AruBfw224eTu/Zf+dK7rOsF+rizhSkZdmFyJn?= =?us-ascii?Q?oK0UkjijLPLUNnaXw61nLXPH4WZcOK0m7RdKpOcuFqvp5rMeHho4Mk3UmkKm?= =?us-ascii?Q?hqxJfOECtFQZBCMk8u0hl/h9CAgxWzBtzAFcs6I7PfXo33wNvoMi2GVots+E?= =?us-ascii?Q?6VOuoJjnVW1Z3oiKX2L4CrSPpuTbYjaZvHXpUAHPUYK6iIuLLp/QG1/Zkshc?= =?us-ascii?Q?IoLyxG/72di/0afJlHH0g8Llt4CmMMfj/GGPVh07LRbUcsS+QPBUBoSnQQB6?= =?us-ascii?Q?2KjAFPzNujSYrDNhChWst87jkSA7e5gdonYb+CX009x0A8YX7K/B3YSduFmF?= =?us-ascii?Q?Fi11ol0OIAX/lj0ziKTUMVoL+wz1cJlqBkL49wLPvrCvM8Bebccj9JmgsH12?= =?us-ascii?Q?7iKagtk2BSoX48rOBkLykEGSa1pfOXSforqb4L2cDbgdii8oscfjLtwSZboP?= =?us-ascii?Q?j9lwlI+PFmj0R8/+AafHRnce5VjdmmenJ45h7px3F0I9GIdt6vXsv3o3DNIl?= =?us-ascii?Q?LNSdv+s/WpPmjs8drAbEncr7i2WnaeKn4DYJjNXTAfdL2EZJ6DhVwFCElj2v?= =?us-ascii?Q?wO8RyBfS+69ZNRKS2WWn0Oq5htMh/msskbxW2TNzp1TpXb40lFQVnFa19h08?= =?us-ascii?Q?zpctR0CeIW1yY2GgtkdHLkcYk/Y/sWOATemtchkqfzsHKRXtq+xNoeVHoYkn?= =?us-ascii?Q?bZqVUWXzQA=3D=3D?= X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 247959e7-2ec7-480d-48c5-08df1a7f0670 X-MS-Exchange-CrossTenant-AuthSource: DB3PR0302MB9208.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Sep 2026 21:01:38.2569 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: U+fZsWg/c3pA7I7TlTNQV8BXRLWPcFxyyKavoUySHR3bYc80QttJgcWm+c/ceCEW+E5VP8eDlAIebtQEbdVo3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMCPR03MB11903 X-purgate-ID: tlsNG-bad1c0/1790283701-BECDF034-3AAEF001/0/0 X-purgate-type: clean X-purgate-size: 7826 Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo, which is initialized from the sanitized host CPU feature state. This does not necessarily match the virtual interrupt controller configured for a domain. A vGICv2 domain can therefore observe a nonzero GIC field when the host supports the GIC system register interface, even though Xen disables that interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can observe encoding 0b0011, although Xen exposes only its vGICv3 model. Derive the fields from the domain's vGIC version instead. Expose 0b0000 for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through CP15 in AArch32 state. Leave the alias unchanged when AArch32 is unavailable. Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64") Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers") Signed-off-by: Mykola Kvach Reviewed-by: Michal Orzel --- Changes in v5: - Fold the vGIC version mapping into the shared ID register helper. - Use the vreg_ and VREG_ prefixes for the helper and field width. - Cosmetic changes after review Changes in v4: - Explain why ID_PFR1_EL1 is left unchanged without AArch32 EL0 support. - Move all ID_PFR1_*_SHIFT definitions to the common asm/sysregs.h and remove the unused cpregs.h includes from the ARM64 files. - Return explicit unsigned GIC field values to avoid MISRA C Rule 10.3. Changes in v3: - Add direct dependencies for the shared ID register helpers. - Move ID_PFR1_GIC_SHIFT to the common CP15 register header. - Apply cosmetic fixes from review. Changes in v2: - Share the GIC ID field helpers between the AArch64 and AArch32 paths. - Parenthesize the individual ASSERT conditions. - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable. - Target master instead of the 4.22 release. v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/ --- xen/arch/arm/arm64/vsysreg.c | 21 ++++++++++++++++++++- xen/arch/arm/include/asm/arm64/sysregs.h | 9 --------- xen/arch/arm/include/asm/sysregs.h | 9 +++++++++ xen/arch/arm/include/asm/vreg.h | 20 ++++++++++++++++++++ xen/arch/arm/vcpreg.c | 12 +++++++++++- 5 files changed, 60 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c index 66f4f23bb3..d8f380ccb7 100644 --- a/xen/arch/arm/arm64/vsysreg.c +++ b/xen/arch/arm/arm64/vsysreg.c @@ -299,7 +299,22 @@ void do_sysreg(struct cpu_user_regs *regs, * to identify the processor features */ GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0) - GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1) + case HSR_SYSREG_ID_PFR1_EL1: + { + register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1]; + + /* + * Preserve the sanitized ID_PFR1_EL1 value when AArch32 EL0 + * is not supported, as for the other AArch32 ID registers. + */ + if ( cpu_feature64_has_el0_32(&domain_cpuinfo) ) + guest_reg_value = vreg_id_reg_set_gic_field(guest_reg_value, + ID_PFR1_GIC_SHIFT, + v->domain); + + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, + guest_reg_value); + } GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2) case HSR_SYSREG_ID_DFR0_EL1: @@ -362,6 +377,10 @@ void do_sysreg(struct cpu_user_regs *regs, guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask; } + guest_reg_value = vreg_id_reg_set_gic_field(guest_reg_value, + ID_AA64PFR0_GIC_SHIFT, + v->domain); + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, guest_reg_value); } diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h index f3c11d871e..f6ece8f972 100644 --- a/xen/arch/arm/include/asm/arm64/sysregs.h +++ b/xen/arch/arm/include/asm/arm64/sysregs.h @@ -438,15 +438,6 @@ #define MVFR1_FPDNAN_SHIFT 4 #define MVFR1_FPFTZ_SHIFT 0 -#define ID_PFR1_GIC_SHIFT 28 -#define ID_PFR1_VIRT_FRAC_SHIFT 24 -#define ID_PFR1_SEC_FRAC_SHIFT 20 -#define ID_PFR1_GENTIMER_SHIFT 16 -#define ID_PFR1_VIRTUALIZATION_SHIFT 12 -#define ID_PFR1_MPROGMOD_SHIFT 8 -#define ID_PFR1_SECURITY_SHIFT 4 -#define ID_PFR1_PROGMOD_SHIFT 0 - #define MVFR2_FPMISC_SHIFT 4 #define MVFR2_SIMDMISC_SHIFT 0 diff --git a/xen/arch/arm/include/asm/sysregs.h b/xen/arch/arm/include/asm/sysregs.h index f6af987ef5..8dcf82a694 100644 --- a/xen/arch/arm/include/asm/sysregs.h +++ b/xen/arch/arm/include/asm/sysregs.h @@ -9,6 +9,15 @@ # error "unknown ARM variant" #endif +#define ID_PFR1_GIC_SHIFT 28 +#define ID_PFR1_VIRT_FRAC_SHIFT 24 +#define ID_PFR1_SEC_FRAC_SHIFT 20 +#define ID_PFR1_GENTIMER_SHIFT 16 +#define ID_PFR1_VIRTUALIZATION_SHIFT 12 +#define ID_PFR1_MPROGMOD_SHIFT 8 +#define ID_PFR1_SECURITY_SHIFT 4 +#define ID_PFR1_PROGMOD_SHIFT 0 + #ifndef __ASSEMBLER__ #include diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h index 387ce76e7e..a85fefcc3e 100644 --- a/xen/arch/arm/include/asm/vreg.h +++ b/xen/arch/arm/include/asm/vreg.h @@ -4,11 +4,31 @@ #ifndef __ASM_ARM_VREG__ #define __ASM_ARM_VREG__ +#include +#include +#include + +#include + typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r, bool read); typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r, bool read); +#define VREG_ID_REG_GIC_WIDTH 4 + +static inline register_t vreg_id_reg_set_gic_field(register_t val, + unsigned int shift, + const struct domain *d) +{ + register_t mask = GENMASK(shift + VREG_ID_REG_GIC_WIDTH - 1, shift); + enum gic_version vgic_ver = d->arch.vgic.version; + + ASSERT((vgic_ver == GIC_V2) || (vgic_ver == GIC_V3)); + + return (val & ~mask) | ((vgic_ver == GIC_V3 ? 1U : 0U) << shift); +} + static inline bool vreg_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr, vreg_reg_fn_t fn) { diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c index 3c315be9fd..15ccde71da 100644 --- a/xen/arch/arm/vcpreg.c +++ b/xen/arch/arm/vcpreg.c @@ -316,7 +316,17 @@ void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr) * to identify the processor features */ GENERATE_TID3_INFO(ID_PFR0, pfr32, 0) - GENERATE_TID3_INFO(ID_PFR1, pfr32, 1) + case HSR_CPREG32(ID_PFR1): + { + register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1]; + + guest_reg_value = vreg_id_reg_set_gic_field(guest_reg_value, + ID_PFR1_GIC_SHIFT, + v->domain); + + return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1, + guest_reg_value); + } GENERATE_TID3_INFO(ID_PFR2, pfr32, 2) case HSR_CPREG32(ID_DFR0): -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Sep 24 22:23:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 22:23:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433123.1653944 (Exim 4.92) (envelope-from ) id 1x9rqd-00043K-R3; Thu, 24 Sep 2026 22:23:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433123.1653944; Thu, 24 Sep 2026 22:23:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9rqd-00043D-ND; Thu, 24 Sep 2026 22:23:23 +0000 Received: by outflank-mailman (input) for mailman id 1433123; Thu, 24 Sep 2026 22:23:22 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9rqc-000437-1n for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:23:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9rqb-00B091-Ev for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 00:23:21 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5a2bd-bab6-0a2a0a5309dd-0a2a450893b4-20 for ; Fri, 25 Sep 2026 00:23:21 +0200 Received: from [74.125.229.204] (helo=mail-lf2-f12.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5a2d9-f659-0a2a45080019-4a7de5cc978b-3 for ; Fri, 25 Sep 2026 00:23:21 +0200 Received: by mail-lf2-f12.google.com with SMTP id 2adb3069b0e04-5b8e7106948so69878e87.2 for ; Thu, 24 Sep 2026 15:23:21 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790288601; cv=none; d=google.com; s=arc-20260327; b=a7KmUM0pMS7RaLkI+oimGQ4IovHbsySCf1F07nonEKoVD5/ZLjhWVYha0zGWvmH/zq pA8kVx+gIHPAoNVo2Dsb/UM4TX3yNr2Tk3cNxdTntHfw189IsdN/kX3MzFjL22CtvIbw nwGbnLhSP2BVapXM8R0zTmy3+2hfP4WdzEkueDu6jbTwQbyoACYpH7i2TgrGWty8qg34 ofr9pDn7u2xX53BjIOhDx1cuk43AqGDxJe8xylSKX5Yp1Nr3WN8zQInGwSeHC/6ByVad N7qpMkibSElF69kfngaU0FllB7CaIpslgzvRYZ35ifkgdGACQwaLhPxyUzuDNE5+F74k n28w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=T5GGfkXwUPJHJrdonFgk41gj12DxobWlG6Stz8L03rE=; fh=1yPyNoqLtC8Ir3LptaxaC2g8QXUGDst0C06uqdPGcEo=; b=EEqgZzRSlSaKM24Og7MMDSiBKkBQzMUI6BDtSNFO3B8OPjmORMtEW1xkCl2MeERKjX wZPzzGAPuXLH+Hy1UgZMXRrb341JubNhqzk3249ISbUkifoE7VYl+ySUDM3l0aSb+G/V F/v2gvi0STlopcT0276Cu6iMwlGVUOLE7iMpwZV0lDHdsbtUB65C/Rnymt13OJRB/VY0 z+3+P9CglgurASIp+tH0wNwrLPtBl6Fd9bxKQAfCBbpLDWGqVhmCQoUOFpd0WLLGoemG F7lFwN4EBNnN6n3+bi/RXrS6NPmdElurGWbXuBndGm/7mwEHeqKcNdhkeia1k9zvBjlZ VtBg==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790288601; x=1790893401; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=T5GGfkXwUPJHJrdonFgk41gj12DxobWlG6Stz8L03rE=; b=chVxE3UugUhxkiHAZpg42cbmxAxofVkJ2nddPkrFiCX77pyhYqkg7K6rhvaioom5G9 65ccZjgYuzxL0AfkvmXFQ3buY6OqbIugCH+ah2tTxUM5zKf4ApEhoXji/GtNk49YzEQh UtbJj8gKqMDCFnxJ55CeXUfDBTW5u1GTVJZcTTLx6K0vFd/s7unnM2TWXs/lyjJTaMGD TFhNZ/YDofYq9hQVnNkJcuVwXaIHqE3wAzuxD7M62zE9I65yJUY8YRXQqGmpqjJE+UwK AhNNxnK0Q1U4xJGJsg7RzAR66bnhkeQP1z5PZScHc7YHHH7XRd5Sw7XTgxk/7mBd+Zt2 x9ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790288601; x=1790893401; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=T5GGfkXwUPJHJrdonFgk41gj12DxobWlG6Stz8L03rE=; b=fO7Zrc8vVjK/et54lcsTL3PxhmU5+EtznSLe875dpVt7xrBm6stpV9YfO959P/R7GX SY4CFOmmTrNFYDkZHGp25wvvZ3A1pFm9CwFmPxR5iAlIUDPegNZ5FJvASdGBpO5+4a9j sXFUav1e8j6/Qx1ylKYnRP/72E1Txl5BsZaVoxEwZYoQRt3P10gcNAgJF+W7eYzWtFTr qL81KMqg/jyIJ6o6ihN+k4lm21447LN/R35B0hQFlLf8uzyKXbCBlrBhytdCfrrbLE9b 1VugcUq4moA050h5gUlWe5pbU/fYTgkrQbEWuwsYxMuBOftkv/Eq4Pr030x3/tMIMsZD RAag== X-Forwarded-Encrypted: i=1; AKwUvBzFqMCHAe676EWD7hY/g2j9TpjXb9pCui2qriFEvUqJF1G92uoYq9Z7EtIzOeyh0/ouVEKM7KDCGuY=@lists.xenproject.org X-Gm-Message-State: AFuF++nrQLDFcy4v75+hTt89ARngHj/bO7Zv6sboI5W3Hk8D2IY8yPkO YzYHSmtN4IuPFUxxPSrkuw5BaIR2/JHx6Rd+n6Z2xEq/SeCIuMisE7jtrSVpT+p/mr6lp0tevKQ KICgA3YewCJQ82NXJ8VMSag98eSKDb2U= X-Gm-Gg: AYBFou31+f1h5264RmWaKLWH++driA0ZLtRHIrKreQGdHcf07ETLYQloHMckI472ph/ uKEpXJNnHwc+Pux/QiHlOaJIkUS+d+3h+9Na9P57yt0N8g4TC0CEsp5CIGW4ipPJ7l6+OlZArb6 TQfaDa0wFhv6n2LekbE8Ly9X9s94cjjr0FZ1fjlUJ7Q+TqM0VEqyJFsNPQlUhD5FScFavJQ6IKI 7fQ7MBtJAP00kJhCALjpFd4dONX1EbBGmLv7ZVeK++OPcqOPlV6PByns69WRCf2abnE9vNum5Np ebp9VfLbepXp1vj/Joo+dbIjpnCeOs2mfA9MGFtiD8YlfMQVIwVFUQaCcDFfuTIW X-Received: by 2002:ac2:4c52:0:b0:5b8:c21e:28e8 with SMTP id 2adb3069b0e04-5b8e6e2f6dfmr61763e87.19.1790288600525; Thu, 24 Sep 2026 15:23:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mykola Kvach Date: Fri, 25 Sep 2026 01:23:08 +0300 X-Gm-Features: AclHuK8NELuGClVZqs8LAX9vYPSxCPMUkmdBDf7GeNp2JA_w6QhryTLBxCp5gow Message-ID: Subject: Re: [PATCH v12 02/13] xen/arm: gic-v2: Implement GIC suspend/resume functions To: Bertrand Marquis Cc: Mykola Kvach , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Luca Fancellu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c1860d/1790288601-D795A87B-0FD882C6/0/0 X-purgate-type: clean X-purgate-size: 4118 Hi Bertrand, Thank you for the review. On Wed, Sep 23, 2026 at 6:28=E2=80=AFPM Bertrand Marquis wrote: > > Hi Mykola, > > Sorry for the delay to review this serie. > > > On 27 Aug 2026, at 16:31, Mykola Kvach wrote: > > > > From: Mirela Simonovic > > > > System suspend may lead to a state where GIC would be powered down. > > Therefore, Xen should save/restore the context of GIC on suspend/resume= . > > > > Note that the context consists of states of registers which are > > controlled by the hypervisor. Other GIC registers which are accessible > > by guests are saved/restored on context switch. > > > > Transient physical SGI pending state (GICD_CPENDSGIRn/GICD_SPENDSGIRn) > > is intentionally excluded. CPU-interface active-priority state is also > > not restored across suspend/resume. Xen reaches the final suspend path > > at a quiescent point, so there is no active-priority execution context > > to replay after resume. Enforce this with a runtime check after > > disabling the CPU interface: if any implemented GICC_APRn word is still > > non-zero, restore GICC_CTLR and abort suspend with -EBUSY. > > You mention SGI pending state but you do not say what would happen for PP= I/SPI > pending state, and the patch does not look at or save/restore GICD_ISPEND= R. > > Can you clarify what is expected for those? This patch was originally based on the Linux GICv2 suspend/resume code, which also does not save PPI/SPI pending state. The comment above gic_dist_restore() explains that level interrupts still asserted after resume will be handled, while edge events during suspend need to be handled by the platform-specific wakeup mechanism. Saving GICD_ISPENDR would preserve the pending state at the time of each read. However, an interrupt could become pending after that read and before the GIC loses power. Saving pending state alone therefore does not cover the whole suspend transition. The assumption here is that device drivers have stopped normal I/O and quiesced non-wakeup interrupt sources before Xen suspends the GIC. Earlier events must already have been handled, or their state must be preserved outside the GIC. Only configured wakeup sources are expected to generate new events at this point. We rely on the platform wakeup mechanism throughout suspend entry and sleep. If the GIC loses power, this mechanism must capture wakeup events outside the GIC and keep them observable after resume. Not saving pending state depends on these assumptions. The race after a register read does not, by itself, justify losing an event that is already pending. --- While checking the pending-state question, I also noticed a related issue with disabling the Distributor during suspend entry. My earlier reasoning relied on the Distributor being powered down during system suspend. Not every platform is required to follow BSA. PSCI requires us to save the state that could be lost. Section 6.8 explicitly discusses Distributor power-down as a feature of some systems. This does not require Xen to disable its interrupt group before calling SYSTEM_SUSPEND. The GICv2 pseudocode in section 3.7.2 shows that irq_wake and fiq_wake depend on the Distributor group enables, but not on the CPU interface group enables. Clearing the group enable in GICD_CTLR can therefore block that group's wakeup path on a platform that uses these signals. I therefore propose leaving the Distributor group enabled during suspend entry, while still saving its configuration in case it loses power. The platform would handle any further shutdown and the required wakeup configuration. The Distributor would still be disabled while restoring its registers on resume. Linux also leaves the GICv2 CPU interface enabled before the PSCI call. Our early gicv2_cpu_disable() is another difference: it can hide that group's interrupts from TF-A's early ISR_EL1 check. I propose leaving that shutdown to firmware as well. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Thu Sep 24 22:45:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 22:45:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433134.1653952 (Exim 4.92) (envelope-from ) id 1x9sBt-0007PD-LC; Thu, 24 Sep 2026 22:45:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433134.1653952; Thu, 24 Sep 2026 22:45:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9sBt-0007P6-Gp; Thu, 24 Sep 2026 22:45:21 +0000 Received: by outflank-mailman (input) for mailman id 1433134; Thu, 24 Sep 2026 22:45:19 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9sBr-0007P0-LU for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:45:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9sBl-00B1xH-VI for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 00:45:18 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5a7c1-e002-0a2a0a5209dd-0a2a4509cd48-34 for ; Fri, 25 Sep 2026 00:45:13 +0200 Received: from [52.101.69.143] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5a7f9-be1a-0a2a45090019-3465458faff5-3 for ; Fri, 25 Sep 2026 00:45:13 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS8PR03MB7585.eurprd03.prod.outlook.com (2603:10a6:20b:34a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 22:45:12 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 22:45:11 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W1/ts9r+I1ihrBPr8mgW3lTAec6v9ovQTOjCHq7YtbdVVA73FHoobp+/Ol1Du7nyLJc+4anBkoDDeaiJpwNA40WGwsmDu7AOpHHfwhDBYxU2veLkOa6LboBLYbb+8bWKC7dd9KAcI8KCU1DOoyEDHNHRcteuC5kCGDt5J0TXcpfBhoMcch82O7mXkGvJD1De+oWxTvacttcbL91BAhmkgVN+dbe9IZEXxRWMoMGRt2vmc2GXuW1mLqLzGLShE1H1fYJeLZXDc7kwie1j8V548csn440yQZKdBdObAjhi7np8QlwyqSxa95g/Aj2u0mS4XrdoimuoBAeFfIO9cRC6sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cxkIYplUMAx3k6PdnftzQLJ2p5om4DNTocWlyGYQx6E=; b=i02L5hWZ6EY6HgGEy8e2tZyKNMY/yJjdxJQt3jAxzBjT4CrWNDphfIkOZeLD3F51HBwLoByxBx7GihHs6AkiU0t0PiYi721CrOXM0h6xen6n53zNBebHtUn0m8Z3H7c9s2qoXmpaaW8zF4cuiSd/XOsywbhP9wEPmsBkP8YvJpbdoqqlZzvLkINM895HN4gusOUZJcAuitSZgjDiwZwfJx2mYkOYSoE1vl9UWKdVYNHjo2O5AOzkY4ffPI8M6BkqpRZCAC58ZHbBu/HOknKkvjWg3PXi1FTl+9CQl3nZKb88ZbA2vdBGLyxdjtbIeK/D6L6disEHs1xZ6QxFNaWXWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cxkIYplUMAx3k6PdnftzQLJ2p5om4DNTocWlyGYQx6E=; b=mAXHf2t/7LqHmHsPwy/AMyjFKoU6pFFFSR5eBk8WR4UdUZcadhKuu5UnmC7mBxLToQAA6Mwj9eN/ru6+sLSt+nnPnL9WBPuPmLZeDFWFhXfteSpi1MrhVNFB3TPkpRUb1Mtj4cFRgEekXeAIz9B+beCt7RhJjosM3dDAEbVxEsaqASQwCAQqnaOk+3+7RooRX4IsReeauD15vJkVkFOktJkoa4Z9AvCUsHiIMkEfVtW+vI8j+ZXVkn+t41BvAzPKoeHiQ0CB3aCGcH7PpuOgB7BwKXgkGVuQ8KnY4h4ohkP1SZgkoTxLa2TwNJMYcQm8AbxGDHe9B0KmX0ZMPaKhMg== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5] xen/arm: derive GIC CPU interface ID fields from the vGIC Thread-Topic: [PATCH v5] xen/arm: derive GIC CPU interface ID fields from the vGIC Thread-Index: AQHdTGflNHaw2bFG60qtE8E+9DIq7Q== Date: Thu, 24 Sep 2026 22:45:11 +0000 Message-ID: <87o6dm1d6x.fsf@epam.com> References: <4f24dd8cd9fc76e8c3f93bca44bb58056cbcc51a.1790147101.git.mykola_kvach@epam.com> In-Reply-To: <4f24dd8cd9fc76e8c3f93bca44bb58056cbcc51a.1790147101.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Fri, 25 Sep 2026 00:01:29 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS8PR03MB7585:EE_ x-ms-office365-filtering-correlation-id: d465b5ca-c8ca-44cc-efab-08df1a8d7e15 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|42112799006|10067099003|5023799004|56012099006|11063799006|6133799003|38070700021|18002099003|22082099003; x-microsoft-antispam-message-info: ve6F7/jyRXzfaEmqoWm1rDTTk0wuXNr24JA4Wp7Q1jSBUEcWkAAWVNwP9NFA5986qZyOiAH6Vn5fzNPRBQ9WxhR+9mfTcjB/gv/D3IP+HB7VfKDwO3FUul7nmt0CalGt86LGMG1FzEr6aajL54lV8cIk9cO+o0UyjU/Qm+ygfchGf1wklbAli30gaODhnXyXGIeRqZK+xEnTOhoGOgSKJT606Av34jyqhsYs9oyv9gZCWGOGnwbHU+OPdYy4Xc+I1YHoAcRJWIecyK3KtRfFimAvAxXG004dE4+L5IVMk65yFogZuUAtplgXsQCC+Z2sC5fzcb0T+O1Oe7oW5T/X9GseDu5DMOn69kknskSlwpmfTsTnnYIxBYgvd/r7/6qIjfK8IOyfUzG2V5oMgtJsFhUoc1T/hw2krmU0ibkoPto52hGRrkpyIK8prtA60FY2VwyiwBgjL0sQ7mXstYkR8qfCFtPa4MFezF8A4Vg4v3xafN28wmr/ycoCTM2n5bAyn+H/mivSGIIVlG/HVT4yb8Bc/CnAONVjbIQnj6cKnzUqazuKWp94XObaHKo0EHDk+PxmwvL+D2sY9G3HkUbOvWf2j9X+BCj9fplDNfstPLxW0MMRisCFHYVrUFB6LoN9Aqdxz7c+hhmQigK+zilSeUBd3LXTiqCZg0EFppaQC3g= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(42112799006)(10067099003)(5023799004)(56012099006)(11063799006)(6133799003)(38070700021)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?1an/1QaO8dMZE45xm3pKEU/RUmu7oF601MofDGZL+XhJnsaawYCAKsfAB7?= =?iso-8859-1?Q?uG/fWSazqDNBi5nFRaBRZgIVF3IgqQRiC5pwIklfPgxNIaeNmVDumU7C7g?= =?iso-8859-1?Q?73ye0vvDbaunMhc+15H9cq6aIjgaPmE2aGPxDQwcdIQf/PPBNCup5oUQ2A?= =?iso-8859-1?Q?UcfzfvOJM/ZFRxUS0K7BA2WTIi3ATLly6zHvbTbKWxOfgEboOjyMotFBv/?= =?iso-8859-1?Q?SSBIWns8iqPHxjKWyUWUuRivvKlVJuUf0WFJSs+R26C6/rqvWBkkepdkDt?= =?iso-8859-1?Q?IM9ixKv+kA2oyWMdsrjlgBVJQv7KbeXtr7o/9bJhIclljML6mvHifODTso?= =?iso-8859-1?Q?1OmgnEAAY3Woemo1O9wW1bQyCPJNUCoZp0BWnWQ7drPmLm7D9QlGBcmSRU?= =?iso-8859-1?Q?lx98CisNQOexCLs/tLdPDHw5VZYZvqBzUrCHjnHukDOGipE5f9iBU5eOqS?= =?iso-8859-1?Q?yJoBDdFEulxYhWOluXUKaZ+aI1d3B3NmXe8nk5sCpVbw9WOKovuNParwqj?= =?iso-8859-1?Q?4Ff+PV53uMUqysTItW3tnJghz/XuTnTpC/65igMmfgEH9ojV+6YllJ2hdA?= =?iso-8859-1?Q?HCjPDzsG49qCNN1MCmwUatGsQxBpAz9f7+4ZO+wz5r7RBCXkzUkZ74WE05?= =?iso-8859-1?Q?ZalgybkC4TbjpTZHxW5Siaul4/BXF9Y61ppUjEq6GlJI/cmifm+7/uiQgb?= =?iso-8859-1?Q?OQ1kecmGZMdOSge8RL8m/NO91bhVFRTKsKysA35u7x5/GcH6j5hX4Q/aHY?= =?iso-8859-1?Q?61diXGVpnX6xqMt2UaBczhJWSEdYpbgOvwqG2kLrASH1WSyRhP2eT7pXQ1?= =?iso-8859-1?Q?M5Ke1UqeVm+IqQ2id6PRaXkNhSDxYgwX/lCA2wq9wk6fgI89HhxTl4Xvl/?= =?iso-8859-1?Q?X2Y6psoqHJR7zFNjmHSSj8gf+8I9I4qURAOeqmfmuk6sCrthlD5jaatF4k?= =?iso-8859-1?Q?7m9oOwglNU0HC0cd3NfP5KMG8EBywoCgooEJaQRshKktG7ArCAigTClPo8?= =?iso-8859-1?Q?RQ1OCoR9nTzwcqdOH7z3v99wdQeoEybbso2rhU9gJd1h+eVRUy9zv6Cbyv?= =?iso-8859-1?Q?aSuaOhPPkWMidqH3fKKHU/SQiznnpTLJLJeOZ454o3a5+UiGRJPyXUED98?= =?iso-8859-1?Q?Odz1Jio+i7p/tOAnum4ugkUsiGhvqesLVAZCbT7nNpUDf0DE5wFkMb/uEP?= =?iso-8859-1?Q?Dwr3U8EFCrZopzwdKxCrZodcb1/bt9FfozlVbALe7NKAE8gGudcPtVV1nS?= =?iso-8859-1?Q?d31YbLwUP7ci+Mu3hislKRx4idM3yPvbdOpucLUovIcH1fNJntNRvfpPUr?= =?iso-8859-1?Q?zVXr/2bKjywDTKCLp4UeNBPIPhiLAxI5c7Ze8QK7ShOIgChhwn0zQlqjFH?= =?iso-8859-1?Q?pcxWLHW1X7pVCrwoIyNLXQe4//VSBbNfrBwTjRdPbShPMhgJgloUEOu/zX?= =?iso-8859-1?Q?JhJX9gluGnj0InGhcdrEvID5B4H9ualtF+YoDHylaM0rSMZq5gwVKnMi4b?= =?iso-8859-1?Q?mL5i+GEcrpa+px7T5tIuXPI0flxBcoy/TQOsCmAodJI16gXbLJC0MKiLzW?= =?iso-8859-1?Q?hVrRt98GGrusbsaQd4K3n2E9TfzoXv+ZAaf1SvpA0i50+3tUdeAxQvIBvz?= =?iso-8859-1?Q?1cfwG7CpZAHdZqXLwuoA4Gx5k4ZtouC0aN5GjhFfzTfocXzqb79KXS98N4?= =?iso-8859-1?Q?TGXuS3gQ7aIqfpL+65FO6f1G1ws7N2DzYlngQE5KchFeUFrQoxBvc/IKOH?= =?iso-8859-1?Q?UIpg0bm0i+d1F3uaaieUOTl9FgBdgOGa6vYYCT5HKNnBUkzkSbdjEKOfNb?= =?iso-8859-1?Q?cjilCwQdo9GYeSQBI5CjyVj7CUyX+H8=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d465b5ca-c8ca-44cc-efab-08df1a8d7e15 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2026 22:45:11.7504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jG9Lql+fsiyOWE0ff/Jnhw4m7suFPOMSVw0QSRwClFz9Ns0VE1E3n/YguiXbizxjOEcB0ca5g6P5BDtCUw6tWdJCzj79zsjJCfJFKl7VDEc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7585 X-purgate-ID: tlsNG-bad1c0/1790289913-BFAD0034-761D6A59/0/0 X-purgate-type: clean X-purgate-size: 8588 Hi Mykola, Mykola Kvach writes: > Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo, > which is initialized from the sanitized host CPU feature state. This > does not necessarily match the virtual interrupt controller configured > for a domain. > > A vGICv2 domain can therefore observe a nonzero GIC field when the host > supports the GIC system register interface, even though Xen disables that > interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can > observe encoding 0b0011, although Xen exposes only its vGICv3 model. > > Derive the fields from the domain's vGIC version instead. Expose 0b0000 > for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the > ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through > CP15 in AArch32 state. Leave the alias unchanged when AArch32 is > unavailable. > > Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64") > Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers") > Signed-off-by: Mykola Kvach > Reviewed-by: Michal Orzel > --- > Changes in v5: > - Fold the vGIC version mapping into the shared ID register helper. > - Use the vreg_ and VREG_ prefixes for the helper and field width. > - Cosmetic changes after review > > Changes in v4: > - Explain why ID_PFR1_EL1 is left unchanged without AArch32 EL0 support. > - Move all ID_PFR1_*_SHIFT definitions to the common asm/sysregs.h and > remove the unused cpregs.h includes from the ARM64 files. > - Return explicit unsigned GIC field values to avoid MISRA C Rule 10.3. > > Changes in v3: > - Add direct dependencies for the shared ID register helpers. > - Move ID_PFR1_GIC_SHIFT to the common CP15 register header. > - Apply cosmetic fixes from review. > > Changes in v2: > - Share the GIC ID field helpers between the AArch64 and AArch32 paths. > - Parenthesize the individual ASSERT conditions. > - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable. > - Target master instead of the 4.22 release. > > v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783= 675708.git.mykola._5Fkvach@epam.com/ > --- > xen/arch/arm/arm64/vsysreg.c | 21 ++++++++++++++++++++- > xen/arch/arm/include/asm/arm64/sysregs.h | 9 --------- > xen/arch/arm/include/asm/sysregs.h | 9 +++++++++ > xen/arch/arm/include/asm/vreg.h | 20 ++++++++++++++++++++ > xen/arch/arm/vcpreg.c | 12 +++++++++++- > 5 files changed, 60 insertions(+), 11 deletions(-) > > diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c > index 66f4f23bb3..d8f380ccb7 100644 > --- a/xen/arch/arm/arm64/vsysreg.c > +++ b/xen/arch/arm/arm64/vsysreg.c > @@ -299,7 +299,22 @@ void do_sysreg(struct cpu_user_regs *regs, > * to identify the processor features > */ > GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0) > - GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1) > + case HSR_SYSREG_ID_PFR1_EL1: > + { > + register_t guest_reg_value =3D domain_cpuinfo.pfr32.bits[1]; > + > + /* > + * Preserve the sanitized ID_PFR1_EL1 value when AArch32 EL0 > + * is not supported, as for the other AArch32 ID registers. > + */ > + if ( cpu_feature64_has_el0_32(&domain_cpuinfo) ) > + guest_reg_value =3D vreg_id_reg_set_gic_field(guest_reg_valu= e, > + ID_PFR1_GIC_SHIF= T, > + v->domain); > + > + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, > + guest_reg_value); > + } > GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2) > =20 > case HSR_SYSREG_ID_DFR0_EL1: > @@ -362,6 +377,10 @@ void do_sysreg(struct cpu_user_regs *regs, > guest_reg_value |=3D (sysval << ID_AA64PFR0_SVE_SHIFT) & mas= k; > } > =20 > + guest_reg_value =3D vreg_id_reg_set_gic_field(guest_reg_value, > + ID_AA64PFR0_GIC_SHIF= T, > + v->domain); > + > return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, > guest_reg_value); > } > diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/incl= ude/asm/arm64/sysregs.h > index f3c11d871e..f6ece8f972 100644 > --- a/xen/arch/arm/include/asm/arm64/sysregs.h > +++ b/xen/arch/arm/include/asm/arm64/sysregs.h > @@ -438,15 +438,6 @@ > #define MVFR1_FPDNAN_SHIFT 4 > #define MVFR1_FPFTZ_SHIFT 0 > =20 > -#define ID_PFR1_GIC_SHIFT 28 > -#define ID_PFR1_VIRT_FRAC_SHIFT 24 > -#define ID_PFR1_SEC_FRAC_SHIFT 20 > -#define ID_PFR1_GENTIMER_SHIFT 16 > -#define ID_PFR1_VIRTUALIZATION_SHIFT 12 > -#define ID_PFR1_MPROGMOD_SHIFT 8 > -#define ID_PFR1_SECURITY_SHIFT 4 > -#define ID_PFR1_PROGMOD_SHIFT 0 > - > #define MVFR2_FPMISC_SHIFT 4 > #define MVFR2_SIMDMISC_SHIFT 0 > =20 > diff --git a/xen/arch/arm/include/asm/sysregs.h b/xen/arch/arm/include/as= m/sysregs.h > index f6af987ef5..8dcf82a694 100644 > --- a/xen/arch/arm/include/asm/sysregs.h > +++ b/xen/arch/arm/include/asm/sysregs.h > @@ -9,6 +9,15 @@ > # error "unknown ARM variant" > #endif > =20 > +#define ID_PFR1_GIC_SHIFT 28 > +#define ID_PFR1_VIRT_FRAC_SHIFT 24 > +#define ID_PFR1_SEC_FRAC_SHIFT 20 > +#define ID_PFR1_GENTIMER_SHIFT 16 > +#define ID_PFR1_VIRTUALIZATION_SHIFT 12 > +#define ID_PFR1_MPROGMOD_SHIFT 8 > +#define ID_PFR1_SECURITY_SHIFT 4 > +#define ID_PFR1_PROGMOD_SHIFT 0 > + > #ifndef __ASSEMBLER__ > =20 > #include > diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/v= reg.h > index 387ce76e7e..a85fefcc3e 100644 > --- a/xen/arch/arm/include/asm/vreg.h > +++ b/xen/arch/arm/include/asm/vreg.h > @@ -4,11 +4,31 @@ > #ifndef __ASM_ARM_VREG__ > #define __ASM_ARM_VREG__ > =20 > +#include > +#include > +#include > + > +#include > + > typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r, > bool read); > typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r, > bool read); > =20 > +#define VREG_ID_REG_GIC_WIDTH 4 Should this go into sysregs.h? Something like ID_AArchx_PFR_GIC_SHIFT? I am open to alternatives in naming= . > + > +static inline register_t vreg_id_reg_set_gic_field(register_t val, > + unsigned int shift, > + const struct domain *= d) > +{ > + register_t mask =3D GENMASK(shift + VREG_ID_REG_GIC_WIDTH - 1, shift= ); > + enum gic_version vgic_ver =3D d->arch.vgic.version; > + > + ASSERT((vgic_ver =3D=3D GIC_V2) || (vgic_ver =3D=3D GIC_V3)); > + > + return (val & ~mask) | ((vgic_ver =3D=3D GIC_V3 ? 1U : 0U) << shift)= ; Probably better to use constants? Something like ID_AArchx_PFR_GIC_V3 and ID_AArchx_PFR_GIC_NO_CPU_INTF. > +} > + > static inline bool vreg_emulate_cp32(struct cpu_user_regs *regs, union h= sr hsr, > vreg_reg_fn_t fn) > { > diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c > index 3c315be9fd..15ccde71da 100644 > --- a/xen/arch/arm/vcpreg.c > +++ b/xen/arch/arm/vcpreg.c > @@ -316,7 +316,17 @@ void do_cp15_32(struct cpu_user_regs *regs, const un= ion hsr hsr) > * to identify the processor features > */ > GENERATE_TID3_INFO(ID_PFR0, pfr32, 0) > - GENERATE_TID3_INFO(ID_PFR1, pfr32, 1) > + case HSR_CPREG32(ID_PFR1): > + { > + register_t guest_reg_value =3D domain_cpuinfo.pfr32.bits[1]; > + > + guest_reg_value =3D vreg_id_reg_set_gic_field(guest_reg_value, > + ID_PFR1_GIC_SHIFT, > + v->domain); > + > + return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1, > + guest_reg_value); > + } > GENERATE_TID3_INFO(ID_PFR2, pfr32, 2) > =20 > case HSR_CPREG32(ID_DFR0): --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Thu Sep 24 22:48:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 22:48:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433140.1653960 (Exim 4.92) (envelope-from ) id 1x9sFE-00084X-3r; Thu, 24 Sep 2026 22:48:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433140.1653960; Thu, 24 Sep 2026 22:48:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9sFE-00084Q-0A; Thu, 24 Sep 2026 22:48:48 +0000 Received: by outflank-mailman (input) for mailman id 1433140; Thu, 24 Sep 2026 22:48:46 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9sFC-00084K-LL for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:48:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9sFB-00B2KS-Ut for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 00:48:45 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5a80c-bab6-0a2a0a5309dd-0a2a4509b660-48 for ; Fri, 25 Sep 2026 00:48:45 +0200 Received: from [40.107.130.104] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5a8cd-be1a-0a2a45090019-286b8268754f-3 for ; Fri, 25 Sep 2026 00:48:45 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by AS8PR03MB7585.eurprd03.prod.outlook.com (2603:10a6:20b:34a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 22:48:41 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 22:48:41 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=P+M+Q3bQMKJpbPypgNg9FHuGkBt/rWxhhvVhecPYaOPAQyIKkIiw1Yb2DSOKYxYrvDHTxfWap6LNjUt1bSwJiMUGxou7tcOgQr0OaO1ftxgnDtMA7i0OsUrHp37FLK3pIAeualykt5mcTMuziBapmMmxxAP7G0zXpyZGke4o6LcKkjW2+Y2bmmNbMZ9u76tUgbkGa2XOk5qkFc1VddDYxliZa3tuqFyWimeOqirAjKUDIUsXJJW61pBwecvpfyjZaX7Xhc8cTTvlk3B8hUI/09UGVnCSLjNDVmOuVewcd+76G8JWD/cprOX5W/NGYfoN/F6HHQrvH2QfsHWC5oxS1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VeUp7Wi6wcAtU37QGNRs8t5yutaUO6GvLIt5JZ7ErkE=; b=RQIIuQjzwyoQsJB/Q3nEkPErOjNATkb23kAkSWtkUj/Bu65otm2o3I1TijqjEBGqR7afrcpMla0UrwsMJxkyDYW94okROVrl976I7GWIR9kKIfbnPgY6mjwCmw+//TknOjCLmyfmC4Hfi/ptVr03rywITHWfnKbg1BgegYXIkWzw30Zd0yztK77KXhtt7HL8Ytef5cWG5jdji31BsRxihppKa8+CDkshgGt60+kSy02IQEKZZujATkBzvQnlCVnGgjit/wFmkKI9KhTYcDs0+nTUN4KXrMKADJph6k+3BSJefjb/L3DnMu92qLFFAwbyJd8NULJkZHVMwOJuIt25nQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VeUp7Wi6wcAtU37QGNRs8t5yutaUO6GvLIt5JZ7ErkE=; b=SRdWSKSG664xkPwkpUh9XCLgwgJrym6lNd38GIegjc5LJ4h/Oe/21fkbvgXoz+df9WXIDq3nnxusucz5VDMi3NfFB27mvbNyqqcHS2Ptc+tMgHCCUeUG9B1t6knNnFbg8e8elimF4JoSucygVSj+mFfdY+I7eVSU/CCDlrH0xdYNLZRBsSNdWM1CKL80jBMYAZy4sgf7hYMpLFwhGfFud9nCcwDeO+Xq7u2Sb/A98YOxIPIABSgsGKzU3+llHmJXrIRw5hFX228AZ2U35sS2ZfPtZ8Kk40LRr7Dt1JK+GWtusASOP3LHn+zZF297OrH1u5JG9Bs1jiz/v4gjYHRfVw== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 2/4] xen/arm: make is_espi() a pure range predicate Thread-Topic: [PATCH v5 2/4] xen/arm: make is_espi() a pure range predicate Thread-Index: AQHdTGdtuoJ+YRti9EqfLG1rI3nQEw== Date: Thu, 24 Sep 2026 22:48:41 +0000 Message-ID: <87fqyy1d13.fsf@epam.com> References: <8aa55bb41ec944bd249a77959e7702e001a8329d.1790160605.git.mykola_kvach@epam.com> In-Reply-To: <8aa55bb41ec944bd249a77959e7702e001a8329d.1790160605.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Thu, 24 Sep 2026 23:57:54 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|AS8PR03MB7585:EE_ x-ms-office365-filtering-correlation-id: 41ecfdf5-9e6f-4d53-6cb5-08df1a8dfadb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|42112799006|10067099003|56012099006|11063799006|4143699003|38070700021|18002099003|22082099003; x-microsoft-antispam-message-info: TtDWeVyNal0NW1eWi/cc3adkye7fVAXqTrJ5vYrcxSKLz8qJWNfAVhEOb/GzvvLI24aFI3DcK0DaTkdbTn7XcfOQyVA6cB+UuZrKnGlbb82pFNbA++kkcrd4VQrJAW5ED0oIxRDlpHzeVs5ZmqEUG++A84oj6OsRisY431P97CdmFhJXI/iPl9pd0D9vFzRi5vGkOZywju/Jof2r5vxe68pTsU2WxegLoHyoOBkB8KUQt2MERuQfbt0DNoWfL7FxM5On3Q/ng/tfiyZ8cna415n+zo4feJmvGeqHMffO/kxv7Rfpns+Xgmr2QJOyIYWaHn/i+OYm/+ZB7KWFN6vCkJWsWksNAqQwVGET07A/Xw3dR4bvNlUWfU1mfveXQ4B1iQAnCYKyGxyp+MKgj4eA9qlsRvXX1f5B+G2jjwif68wINPWOC1abCIRI7o7adQ+U1WqyYUOog2Aqlu6wcOWRFcj0JtAAYJXKzYljSL3H5YvuIUlUqxdf5kEYnBX7q/a837c3hy/ZP5uohw3o9TKZz8jxbz8aDhRJhkkGrOIzEN1/folTmo0woWxyRK/DCPtTfL7ZASf8hnOQtgRNoQkAkuF5yivTb5qLhFbCIvacJvCKMwOWLEAF7eRAjCbJ1pyxsNwyn3MhR2nAHd9/Uph1JlF+KUowfPTUZgLduogsO5UujiS3iH74Q9rpnps0lSgjSE6uLCQRGcimiwyWEyP2Acb72h6kCNNohsglQpMyZRc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(42112799006)(10067099003)(56012099006)(11063799006)(4143699003)(38070700021)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?iTur7EmhhZY0qfwUGhj1/kwzBkTR9k1/QbwZXTNdWi/AA7fzu1JOgPH5O+?= =?iso-8859-1?Q?Hc/dxISt4RsL46VcN9Ldhix9lFws99dWrVM9twH+DIg19cQfe7fJD0U7Dv?= =?iso-8859-1?Q?MPqKY7qSLIb9oOh4zOiZ2ShB8hCE17xjD5yX8m0hvxELhHHMV/dgzwfK+R?= =?iso-8859-1?Q?x0HXQlA8X6dJeBfHmDmWBXUb3YQr/Xh2neYS+4FGS52Qgnusr0bl/h3nEj?= =?iso-8859-1?Q?l3XfgzDfFh2j8I7Ho4n4qZXjNSEGEFd/2SoTSOjuxglH8HsT+f2N/d1Irs?= =?iso-8859-1?Q?dlatNodKhBskWSA3jLtzE3jmfm26tVjQExS83ik/5oH4phvfQyfyfI1aXY?= =?iso-8859-1?Q?6NzRY1xHJ37of79tBC5wj5nX2xcZxnKzMYq9YNm5yp7zCdM0aDUCFMfWfj?= =?iso-8859-1?Q?LuykEmNa2vYiUA1z3sIO+xxP7lR2KwIcSBGBpmxB0DMlvBTK5qFqN6Zrls?= =?iso-8859-1?Q?ti7zLkDyA0KEYiOBMWB5ekBsd/fanf2cPPhfJGH44fwGV9TrToU/0AmELe?= =?iso-8859-1?Q?OHMLkWpwlBv/LX6nt94tAG7GmOUzzpWzV56mwhRkIbxc6aADRjh7/W0qiZ?= =?iso-8859-1?Q?oduAZAHo23GGejPO4BKwyCsVR12E/+hiUG0OcBkFfNnew9W0KkR+OIBSDC?= =?iso-8859-1?Q?C+YmY3SbvUBDTvPyhRclAgbxQVPQE9forfk+rRXQu6jerW6YoBqz7dENr4?= =?iso-8859-1?Q?ZW00Op7uTKEbNbjlNDNejtzOYRUSFayt9qbTc+GdvhWr0kGAouUhf/NydD?= =?iso-8859-1?Q?3KS0V9/Dlp6J3IBy4eALOtlhH3FBZKVoxyz//ZS+TUZMBCDCbkr5crzOQ9?= =?iso-8859-1?Q?Z+vbK2SXD2TLzXBNU+AfdJBkKK7vkwekXBHldXIFaELfVUgSkfWxp2MJCL?= =?iso-8859-1?Q?FROTleZFesYxN7jZMRAkiBtScAizj8NjOzAiUzpe7bilnjrlgR1NVRu4l3?= =?iso-8859-1?Q?UrRcjqeZ7aC3WXJYFQHSDG0iqGosD0uD8Wd7vm+r/Cr24rTWws4f6Xdw80?= =?iso-8859-1?Q?WvFiAYIQ/TnkL7Kaj8gTGBZCbEEyJ8B5zJdSyS2xN84LE2m8+udgMnRIlX?= =?iso-8859-1?Q?jthmswlqLFVjs/VDbPxd/O2vBq5jkpC/eB7ToAwfQXFl5pHFvoP9uLtL7x?= =?iso-8859-1?Q?mZOdfgvPy3xVHRriMRYpzhR+gNDgPyvvVtfMWDoXyxOxmQrf0WvLbBIKHP?= =?iso-8859-1?Q?WLltxdMQDkH2E0fpBJ04moy1E8xXIvBufCKWYfvoKAYx3YK/SSHRRurfBM?= =?iso-8859-1?Q?CkXnF5hl35iwa1EGPgl7Iqm8uh8iqKJfr7AlvskMBN+LQxE3lO0o+NZD2d?= =?iso-8859-1?Q?y923l0TVPerxl07FeFBNcAHHJ4ui4GyRtu4mnzfjO6TkJ4CdkMc4tuVnwk?= =?iso-8859-1?Q?hshk/Y4EAdA0BZ3vKrA0Zyez2Pf7jkfYXW73eXZjQ7JSuYWEaCYpOIyfKo?= =?iso-8859-1?Q?FI0kys+1wSZZspUtt2nWJ2T9l9VtNbprJWHQz0VmPTaCYfhRFQpq29+AVr?= =?iso-8859-1?Q?4rI7R4jNCUhA093J8jaMptyZFR8qcJJyyAh114RjnnPjEQFDyv7n8pso1V?= =?iso-8859-1?Q?UK6ZrTaUoIggJoAUe6hXOTxLUWVvo6c91WcOoA8mXc0DYx5Yd5joWPx0MU?= =?iso-8859-1?Q?x/JQFHqEziiD3A8FUqh0MUCR7pm0d+UZjeK4Mzs4+PuIvUf4oSsFrgonmR?= =?iso-8859-1?Q?EU+C36I8DAzfYoI40/fQmtDw/iMClSfRkct5A0cQkk9MNQDacA9FEEJUrw?= =?iso-8859-1?Q?BzsuZRdCgROPTB6v4KX6PNnKrGBTt3uDTK6nw2NZ3ig5MGgTT3RzkDiD+C?= =?iso-8859-1?Q?NJ19DqbZcrTk9eMjhBi17LD7WJJFETI=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41ecfdf5-9e6f-4d53-6cb5-08df1a8dfadb X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2026 22:48:41.1188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U/9T+8jGOpITAsYtoQKKFnqw23Zg3tmWDixEz8aNj58uMyUQeUS2jiLiExAEzk9KlAl5Cz5gL5wjJ0USFLali/cOihgH7BzLrVIj0E31N0c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7585 X-purgate-ID: tlsNG-bad1c0/1790290125-BF6D2034-F6AC4382/0/0 X-purgate-type: clean X-purgate-size: 5810 Hi Mykola, Mykola Kvach writes: > is_espi() currently changes its result according to CONFIG_GICV3_ESPI. > Without eSPI support, it returns false, and its assertion fails if > an eSPI INTID is passed. Callers therefore use it both to identify > eSPIs and to exclude eSPI handling when support is disabled. > > Make is_espi() report only whether an INTID is in the architectural > eSPI range. Check for eSPI support at the call sites. > > Use BUG_ON() if the GIC reports an eSPI without compiled-in support, > matching the handling of unsupported LPIs. Treat virtual eSPI lookup > without support as unreachable, with a NULL return from the > espi_to_pending() stub. > > Signed-off-by: Mykola Kvach Reviewed-by: Volodymyr Babchuk > --- > Changes in v5: > - Explain why an eSPI cannot be handled without compiled-in support. > - Make both espi_to_pending() helpers static inline and constify d. > - Add ASSERT_UNREACHABLE() to the espi_to_pending() stub. > - Preserve the unmapped LPI comment and clarify that an eSPI lookup > without support must not occur. > > Changes in v4: > - Clarify the existing is_espi() behavior in the commit message. > - Drop the unrelated blank-line removal in vgic.c. > - Use BUG_ON() if the GIC reports an eSPI without eSPI support. > - Drop the redundant CONFIG_GICV3_ESPI check in IRQ dispatch. > - Return NULL for virtual eSPI lookup when eSPI support is disabled. > > Changes in v3: > - New preparatory cleanup requested during review. > --- > xen/arch/arm/gic.c | 6 ++++++ > xen/arch/arm/include/asm/irq.h | 11 ----------- > xen/arch/arm/vgic.c | 30 ++++++++++++++++++------------ > 3 files changed, 24 insertions(+), 23 deletions(-) > > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index 078049e741..cdae6afb07 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -348,6 +348,12 @@ void gic_interrupt(struct cpu_user_regs *regs, int i= s_fiq) > /* Reading IRQ will ACK it */ > irq =3D gic_hw_ops->read_irq(); > =20 > + /* > + * Without CONFIG_GICV3_ESPI, there is no IRQ descriptor or > + * pending_irq storage for eSPIs, so we cannot handle them. > + */ > + BUG_ON(!IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(irq)); > + > if ( likely(irq >=3D GIC_SGI_STATIC_MAX && irq < 1020) || is_esp= i(irq) ) > { > isb(); > diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/ir= q.h > index 09788dbfeb..c29f3d04a3 100644 > --- a/xen/arch/arm/include/asm/irq.h > +++ b/xen/arch/arm/include/asm/irq.h > @@ -66,18 +66,7 @@ static inline bool is_lpi(unsigned int irq) > =20 > static inline bool is_espi(unsigned int irq) > { > -#ifdef CONFIG_GICV3_ESPI > return irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID; > -#else > - /* > - * The function should not be called for eSPIs when CONFIG_GICV3_ESP= I is > - * disabled. Returning false allows the compiler to optimize the cod= e > - * when the config is disabled, while the assert ensures that out-of= -range > - * array resources are not accessed. > - */ > - ASSERT(!(irq >=3D ESPI_BASE_INTID && irq <=3D ESPI_MAX_INTID)); > - return false; > -#endif > } > =20 > static inline unsigned int espi_intid_to_idx(unsigned int intid) > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > index e5aca17dcb..0ba13e18da 100644 > --- a/xen/arch/arm/vgic.c > +++ b/xen/arch/arm/vgic.c > @@ -62,6 +62,14 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank= (struct vcpu *v, > return &v->domain->arch.vgic.ext_shared_irqs[EXT_RANK_NUM2IDX(rank)]= ; > } > =20 > +static inline struct pending_irq *espi_to_pending(const struct domain *d= , > + unsigned int irq) > +{ > + unsigned int idx =3D espi_intid_to_idx(irq) + d->arch.vgic.nr_spis; > + > + return &d->arch.vgic.pending_irqs[idx]; > +} > + > #else > static inline bool is_valid_espi_rank(struct domain *d, unsigned int ran= k) > { > @@ -78,6 +86,13 @@ static inline struct vgic_irq_rank *vgic_get_espi_rank= (struct vcpu *v, > ASSERT_UNREACHABLE(); > return NULL; > } > + > +static inline struct pending_irq *espi_to_pending(const struct domain *d= , > + unsigned int irq) > +{ > + ASSERT_UNREACHABLE(); > + return NULL; > +} > #endif > =20 > static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, > @@ -698,6 +713,7 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enu= m gic_sgi_mode irqmode, > * interrupt. > * This can return NULL if called for an LPI which has been unmapped > * meanwhile. > + * This must not be called for an eSPI when CONFIG_GICV3_ESPI is disable= d. > */ > struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq) > { > @@ -715,22 +731,12 @@ struct pending_irq *irq_to_pending(struct vcpu *v, = unsigned int irq) > =20 > struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq) > { > - unsigned int idx; > - > ASSERT(irq >=3D NR_LOCAL_IRQS); > =20 > if ( is_espi(irq) ) > - { > - unsigned int nr_spis =3D d->arch.vgic.nr_spis; > + return espi_to_pending(d, irq); > =20 > - idx =3D espi_intid_to_idx(irq) + nr_spis; > - } > - else > - { > - idx =3D irq - NR_LOCAL_IRQS; > - } > - > - return &d->arch.vgic.pending_irqs[idx]; > + return &d->arch.vgic.pending_irqs[irq - NR_LOCAL_IRQS]; > } > =20 > void vgic_clear_pending_irqs(struct vcpu *v) --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Thu Sep 24 22:56:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 22:56:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433160.1653970 (Exim 4.92) (envelope-from ) id 1x9sMA-0001HQ-UD; Thu, 24 Sep 2026 22:55:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433160.1653970; Thu, 24 Sep 2026 22:55:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9sMA-0001HI-QV; Thu, 24 Sep 2026 22:55:58 +0000 Received: by outflank-mailman (input) for mailman id 1433160; Thu, 24 Sep 2026 22:55:57 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9sM9-0001HC-Im for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 22:55:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9sM8-00DpDO-CD for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 00:55:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5aa44-8faa-0a2a0a5109dd-0a2a450697ca-20 for ; Fri, 25 Sep 2026 00:55:56 +0200 Received: from [52.101.69.132] (helo=AM0PR83CU005.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5aa7c-195a-0a2a45060019-34654584990f-3 for ; Fri, 25 Sep 2026 00:55:56 +0200 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com (2603:10a6:803:113::29) by DU5PR03MB10302.eurprd03.prod.outlook.com (2603:10a6:10:516::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Thu, 24 Sep 2026 22:55:53 +0000 Received: from VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48]) by VE1PR03MB6078.eurprd03.prod.outlook.com ([fe80::4722:b91:9b24:ee48%3]) with mapi id 15.21.0451.014; Thu, 24 Sep 2026 22:55:53 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hSzIHLS6QVqLQRmIRIppM6kfov/aSOB+xeoXDBC7UaYxrEtLydtRZEXcmJitBm7rcdbmBv9sPkxwuLr4Z+J8BPbZdV7RJyuXlvy52ugfDkUFfuc7drDBoFxAu9KPCoHATTZ27cwCgkBWLMQAwS5/TJTFz2gyjh1A8L+p/4kor+WjWvODImMWnJb0RvXmrVkJvXXNoigNZ3n6Ah/17wyW412VhG0MQpnNfYmLROXkxB3iNnhz9evRZ/dPuE8QUZjyUaiSoxN7JMOgB/BhihF4n9S1nLsyj5V8dfoUwA9NAo3h9tiSauZh3XDVXrw61+sCXH0I1S+yscMWSAuJesnW3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4NXdfsFy7WUPX36tY0/mB+5XsUobklrPPlsiV5ayEJo=; b=r0tpbR8SyQKmS/SQyHsYt7MiycHQjV9RPIfAEhLB/ZW0x8isu+2f0Dc+Zj3Vtzsjwb7f7L7i7MYBXnQtGVJh5K4pZZZimAIwHZAvv/rDDD7RLTXbzB87a/xcw40BFicZFzbkjMBZ+JsYz5vj9FZfbEm7offb/hJAlHPAPGMigO6CwX3cbUAMV2xMjLryxawWm6LJ+/UT0gSTfzJYoYmq3xOIP1oBoHZQC+V1D8cmP6MzlXGkKNL2ZxdpsJornXrfYCgSBDCkKr2AtEiD7rUdqT/CHKfkz95Nyt6lx/JZzKmIfd/5PqBnjOulgyhf2BEHCTnsT8zaAArkRdGCNcnd7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4NXdfsFy7WUPX36tY0/mB+5XsUobklrPPlsiV5ayEJo=; b=sBiw5355T8qecBt/FhRdqcqiLUzN4WN3rOzCltRoZQ2lTKcr20/sNS4552HNNYRJIAM5je8RJntIJFKbajXoLDlq4PKrpdjQZ1RSZZPG2331YERfXr5d+GetWnLj7Jp2baPm+hzWrNvuf86wTQEgguR/YA7P8KdxYQm83TlPMfwKd569WZK4Ofmla9iGXvdZP+fpRGwD5jqAmJxnvdFQyrjTZo5nFywmoWIsMtcumVXoRKqEiPL9+d6JJQSrWikOKYtFHAeu13X1nnttTa0S1XijLA8Kj3IQol1mD4xK9ivxvP2du/DH6B/4AlMKrVcO9Lxiqyic6kyAh3FDRqTKxg== From: Volodymyr Babchuk To: Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v5 4/4] xen/arm: vgic: free eSPIs using the bitmap index Thread-Topic: [PATCH v5 4/4] xen/arm: vgic: free eSPIs using the bitmap index Thread-Index: AQHdTGdvGfT1E9oBQkCUIpVOvCgdbA== Date: Thu, 24 Sep 2026 22:55:53 +0000 Message-ID: <877bka1cp3.fsf@epam.com> References: <8c61cf31b69377737d1f688bded43d123ac55d00.1790160605.git.mykola_kvach@epam.com> In-Reply-To: <8c61cf31b69377737d1f688bded43d123ac55d00.1790160605.git.mykola_kvach@epam.com> (Mykola Kvach's message of "Thu, 24 Sep 2026 23:57:56 +0300") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.14.3; emacs 30.2 authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VE1PR03MB6078:EE_|DU5PR03MB10302:EE_ x-ms-office365-filtering-correlation-id: 9fef860d-dd31-4cf5-daf4-08df1a8efc8d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|23010399003|366016|42112799006|10067099003|56012099006|11063799006|4143699003|6133799003|38070700021|18002099003|22082099003; x-microsoft-antispam-message-info: e9+kLtoVR4w6SkD9pL4NM1l4lhyNpVWr9ab1IM4hC+jNVh+Z1oUbZZ/WWFgmUFEX2y7vxUkrBTR3S2t3l7s8WvsT7S0b+j/ouBzrDn1OS8PSlKjnI2ihs9p1SClPP6o2JnVT5hMoVC3n5ga0S/n3aOlWvpflKW3kWhM7/uZhxHwRqn5ER7ILnbkIR3EYFUn9hjEkFmHVENmQsd3gjgx7EcYsJh7slMIXft/jy+4lpxJGEFIE9O8pmJ2crajdddeCskAVbUmaMcoX+BA3mXAsFNpVfyRw+gX+sidSRZHAk6hlJFcC08ygoa0Hzm4IbrZnG1yPyCG7pa4T1whIvKRVU/Y+QgZLbWNp73VXbR9mfF8Yv1jl1WpyHELoOeY5zyFBdTTqyl7bvfSW9UvJYHa8Q8psNRHw4InnlhEh2Z6EXEe0XmB7mlIk9KA0gwlqzn3bSsLiE/ZClEljRWjw0HGoBZhP55wZHmoZFhKNsrnrsAne/4CiBz2NP64LC5iBSupvsbSJcFfecIernDta8Piy2dW8ZXxqubQckOoTQ2wzxR5aP70Rr00Rdu345X5Uev83fm7rpMZ1rYNhB7gGeYnYGLrLRe3pejJx58ApD/OALL5yYxcbCesgqMz09Th2KlgSGlKvsDXM9epItL5P12GZ8k9ykxXObuezVtlPCzVzb2Re1h+EIfAot9ZTpCPE0iF9VQm352TjH8oVbVowyjf790M/YMkWJzHhHFskd4AWiNw= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR03MB6078.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(42112799006)(10067099003)(56012099006)(11063799006)(4143699003)(6133799003)(38070700021)(18002099003)(22082099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?DAlDUkjrmh0hP0FLNdU0ECrqVmO5BdGamKbouzeDdQzreEb0aqezjieoqs?= =?iso-8859-1?Q?3TihdpZxVuP1qrJ45qUC2XvaG3zxjYawlCLqfjoCMUZxwC8sWxsh6YhiY2?= =?iso-8859-1?Q?cBaIrcO7e97EmQP+0AUCz8KnNPTJDTmm6lHNBAsfgDWV2Ob+qXzHq2ljd3?= =?iso-8859-1?Q?OFRHU3SahA8N+rob0kN+BZZzgDyGUN1zN89DjOBOfxWrq3rNRsEw19WD/Z?= =?iso-8859-1?Q?/4As++OdyvttlvvILwk/nd3rSNlrTtNDano+gymSGRJOYayXfqjHa4ffoL?= =?iso-8859-1?Q?Ef3FZf8k5tv52AaXEznL9Yx99yPQ6KsXYicSb1OKD148kMZwH69VFlWaLV?= =?iso-8859-1?Q?Y0XoF7vYVQLfoWV62ITKuLJtwVtT/YDA3JhIy8/hMvYPjmsjLk7w9bT1hI?= =?iso-8859-1?Q?SF4QFBazemludcbvCe2mrUrwiPHVkttxJEK1A/11drqrQ+UenjszrniFcq?= =?iso-8859-1?Q?HyR9AFJAbioiRz8LQnj4yyUcXtFl/3HzRUobjU7gvI9IjGhM9rUW57iKhq?= =?iso-8859-1?Q?dfQk2Q2P8KG/kBHfkOuZ4ymVisSDAs9iIFOsX2N9sCDinsOVessEKP9Iob?= =?iso-8859-1?Q?1/K9yoObwzPYA08azJv++2YfrfM2SBu/pa5RcPBSpmjDT9BKM51lhvoQvb?= =?iso-8859-1?Q?VqHEiF0kRMApB8Y3YlPQZA4LOObBPc2QHqu043zrGUCkcN76zaadJrQZ5Q?= =?iso-8859-1?Q?1GB85hOwZ9LMApNNedbitI/KGG8cHBUIvinsVxqESTUCPsApWpIE6RSF1J?= =?iso-8859-1?Q?lnltn8TZwcfHQjqckhi600PGmODtNaDsIrEDXBaUNUm8Fw4FSM5EgdduBD?= =?iso-8859-1?Q?WT0b51tIeinh8HRijPMraASTlhMJgtxFKseFRLpa3FBxu/mJaykcsu8d3l?= =?iso-8859-1?Q?paRpwYEnwoSr18QjJqxOzAKTV0BGmjrCB9yhNqex6kG4bsItCGGHASWuAR?= =?iso-8859-1?Q?PRxVPgCWhg2+cnmp6+f4Txh4IJM2eAy+LEh3rOp4V/Z05kSeydUirPTeUv?= =?iso-8859-1?Q?6f7nOyNxYFE1e8tMv4X+UWLGtkMQOcRePRd8mcatXmf3C5axWbADMi9vyZ?= =?iso-8859-1?Q?lqmPhN9BNJk0wgz8R6ingWpcEBJ63rl5q8+7MCjWX/LJjPQI6F/SQ5jFAb?= =?iso-8859-1?Q?E4Rdl3wMjgbVoMQrI+SsVpMGRNTExhLLJnbdPgOt4bsgCDsgLw8gM+Aa67?= =?iso-8859-1?Q?+q9/st5xPMRPbmNLfWSr1GVPM2g9h+vnQLjrKRvfA97XgRtXTT9iGzXisR?= =?iso-8859-1?Q?CYBVT3eGUJQsNmKc0oUdMAEB9vT2Vkn6gso6clRCCGFwk+EbTm+Ap4HZN8?= =?iso-8859-1?Q?0oAJdt1YnxrGlQjbXX+SUovIdMxAU4lJNO6193jrpBDZBmnBQSSeBnnVrC?= =?iso-8859-1?Q?qGde0v+Qq8YQNh3Xnb5Ot1epLBTl0jXgUgYg+Lfh96eBiXaVqOA5cv87iB?= =?iso-8859-1?Q?gDrSYPm82nE3knsB18ErCkVjv7AxiGksyjA+bntmzo8OyurysinmD3jr/E?= =?iso-8859-1?Q?A5hwcRmuQs2ndxaDD/a2qBbv+aYTygQWzozrp3XjB8TvoM/qJz6WCHydKu?= =?iso-8859-1?Q?ficja6S4uuUjwvXyjbCSEWGtjQLByY1HNluS003zK0a53oI2ADVYcgS/bb?= =?iso-8859-1?Q?Q0qv42p4/ZewuHdYD25vpADIBiRdjAJyg93yjQxp00zM3z/1bJ/1xDlBhO?= =?iso-8859-1?Q?M+4LfFDEXziXTR7t/1cQ/OQWJsOnWDypnQeo7Xat3o+pgXufG+hdVgn4fF?= =?iso-8859-1?Q?x5JitCoujNT3TAq2NygaoAkDgeFrHioaMJXneo3OzSco4wHtaldkDHcbIl?= =?iso-8859-1?Q?H3rAHmpgK0LHecbmTbG5Pine9AGBZJM=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VE1PR03MB6078.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9fef860d-dd31-4cf5-daf4-08df1a8efc8d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2026 22:55:53.4313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OrV94xfIdFA5Q61vUb5bJngQsbf6BzDPVlOacEj/yVlYuuTNYBAH1EeepG0+NdcfMvtsUXUhujknEn/u8XE6cKicraR7h4iQE3cVIz9q+Uk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10302 X-purgate-ID: tlsNG-16d1c6/1790290556-F440377B-AF5C30B9/0/0 X-purgate-type: clean X-purgate-size: 5350 Hi Mykola, Mykola Kvach writes: > The allocated_irqs bitmap in the existing vGIC implementation stores eSPI > allocation bits immediately after the regular vIRQ bits. > vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap inde= x, > but vgic_free_virq() used the raw INTID. > > Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bi= t. > This writes beyond allocated_irqs and leaves the intended eSPI bit set. > Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind= , > and during vPL011 teardown. > > Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reservin= g > and freeing vIRQs. Use vgic_is_valid_line() for the validity checks when > reserving and freeing vIRQs in both vGIC implementations. > > Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended= SPIs") > Signed-off-by: Mykola Kvach > Reviewed-by: Michal Orzel > --- > Changes in v5: > - Add the vgic_is_valid_line() guard to vgic_free_virq() in the new > vGIC implementation and use the same helper in vgic_reserve_virq(). > > Changes in v4: > - Document the compressed bitmap layout with an ASCII diagram above the > conversion helpers and refer to struct vgic_dist for the full layout. > > Changes in v3: > - Adapt virq_to_idx() to the configuration-neutral is_espi() helper. > > Changes in v2: > - Call is_espi() without a configuration guard. > --- > xen/arch/arm/vgic.c | 42 +++++++++++++++++++++++++++++----------- > xen/arch/arm/vgic/vgic.c | 5 ++++- > 2 files changed, 35 insertions(+), 12 deletions(-) > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > index 0ba13e18da..acded6a40f 100644 > --- a/xen/arch/arm/vgic.c > +++ b/xen/arch/arm/vgic.c > @@ -25,6 +25,21 @@ > #include > =20 > =20 > +/* > + * The allocated_irqs bitmap is compressed: eSPI bits immediately follow > + * regular IRQ bits, skipping the gap in the INTID space. > + * > + * +-----------+-----------+-------------------+-------------------+ > + * | SGIs | PPIs | SPIs | eSPIs | > + * +-----------+-----------+-------------------+-------------------+ > + * 0 16 32 vgic_num_irqs(d) > + * > + * INTID ESPI_BASE_INTID maps to bitmap index vgic_num_irqs(d). > + * The following idx_to_virq() and virq_to_idx() convert between INTIDs > + * and bitmap indexes. > + * > + * See also the allocated_irqs comment in struct vgic_dist. > + */ > static inline unsigned int idx_to_virq(struct domain *d, unsigned int id= x) > { > if ( idx >=3D vgic_num_irqs(d) ) > @@ -33,6 +48,16 @@ static inline unsigned int idx_to_virq(struct domain *= d, unsigned int idx) > return idx; > } > =20 > +static inline unsigned int virq_to_idx(struct domain *d, unsigned int vi= rq) > +{ > + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(virq)); > + > + if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(virq) ) > + return espi_intid_to_idx(virq) + vgic_num_irqs(d); > + > + return virq; > +} > + > bool vgic_is_valid_line(struct domain *d, unsigned int virq) > { > #ifdef CONFIG_GICV3_ESPI > @@ -854,19 +879,11 @@ bool vgic_emulate(struct cpu_user_regs *regs, union= hsr hsr) > =20 > bool vgic_reserve_virq(struct domain *d, unsigned int virq) > { > - unsigned int idx =3D virq; > - > if ( !vgic_is_valid_line(d, virq) ) > return false; > =20 > - if ( is_espi(virq) ) > - { > - unsigned int num_regular_irqs =3D vgic_num_irqs(d); > - > - idx =3D espi_intid_to_idx(virq) + num_regular_irqs; > - } > - > - return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs); > + return !test_and_set_bit(virq_to_idx(d, virq), > + d->arch.vgic.allocated_irqs); > } > =20 > int vgic_allocate_virq(struct domain *d, bool spi) > @@ -903,7 +920,10 @@ int vgic_allocate_virq(struct domain *d, bool spi) > =20 > void vgic_free_virq(struct domain *d, unsigned int virq) > { > - clear_bit(virq, d->arch.vgic.allocated_irqs); > + if ( !vgic_is_valid_line(d, virq) ) > + return; I don't think that silently failing is a good idea. It needs an ASSERT() at least. > + > + clear_bit(virq_to_idx(d, virq), d->arch.vgic.allocated_irqs); > } > =20 > unsigned int vgic_max_vcpus(unsigned int domctl_vgic_version) > diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c > index ba029b8a3b..84212bbefe 100644 > --- a/xen/arch/arm/vgic/vgic.c > +++ b/xen/arch/arm/vgic/vgic.c > @@ -712,7 +712,7 @@ bool vgic_evtchn_irq_pending(struct vcpu *v) > =20 > bool vgic_reserve_virq(struct domain *d, unsigned int virq) > { > - if ( virq >=3D vgic_num_irqs(d) ) > + if ( !vgic_is_valid_line(d, virq) ) > return false; > =20 > return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs); > @@ -756,6 +756,9 @@ int vgic_allocate_virq(struct domain *d, bool spi) > =20 > void vgic_free_virq(struct domain *d, unsigned int virq) > { > + if ( !vgic_is_valid_line(d, virq) ) > + return; > + > clear_bit(virq, d->arch.vgic.allocated_irqs); > } --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Thu Sep 24 23:22:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 24 Sep 2026 23:22:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433169.1653980 (Exim 4.92) (envelope-from ) id 1x9slz-0005wp-3K; Thu, 24 Sep 2026 23:22:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433169.1653980; Thu, 24 Sep 2026 23:22:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9sly-0005wi-Va; Thu, 24 Sep 2026 23:22:38 +0000 Received: by outflank-mailman (input) for mailman id 1433169; Thu, 24 Sep 2026 23:22:37 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9slx-0005wa-QT for xen-devel@lists.xenproject.org; Thu, 24 Sep 2026 23:22:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9slw-000vrm-HF for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 01:22:36 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5b089-2eae-0a2a0a5409dd-0a2a4504ab0c-16 for ; Fri, 25 Sep 2026 01:22:36 +0200 Received: from [74.125.229.205] (helo=mail-lf2-f13.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5b0bc-b57f-0a2a45040019-4a7de5cdddd3-3 for ; Fri, 25 Sep 2026 01:22:36 +0200 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b8e6ec4dc0so122531e87.2 for ; Thu, 24 Sep 2026 16:22:36 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790292156; cv=none; d=google.com; s=arc-20260327; b=CQY3rvAfqLEmkStyqSeYWVic9qUZbqrOYCcjs9hGSIiKG2/HW1JqQXZmHGKUJqTeq2 rzVenNP4OmTyCc4LEppbHP8l0FMAcW8zMepxSTLyj7spRM7lmc6EzBbnChyDafsmXrl0 1rPhSfEk8krhjfV8G92qZAWeKv2w1hukV5A2i9BP90h3a+ADBBfCrqY6hplltP1Pr+ex lVfNr0N9H+GhJp7tmEbjuoGTm6TzXlizeu56RhpdLFxhBOXtaMEyKZaPpKsflIDWHMkY stDzmEO8hPiX4wAgewj1jDON0QwnaCXakgI9H30KerPRPb9Aj2H1DAasNhGa2GxjT9A3 2YCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=wTpbY3cPkJZfs70nxAC+hwTt+X0fXJ5NaVXkEloTFzk=; fh=0mnl6dKJ1iafBcu/Ao9u89lhPK5T+/Xj8TDjMOiG+nk=; b=F48qPWTW4Fw3qOgKAEcF5OZczqPLyHRiWRs0tBvAZ1Wni7IvAAuzJqARCyG/Y0u9yA EwOPGHuwZh0HZwPfaKJoic5XX0bdBpsiTuWUoaQ0R8MCK6J5u66+eT8hkX3x5T5ozyRU 1b2yVRzqwqDI7WXfzqGt1yIvJe1qGUp7AOCqz3F+Neaqx53Xa5u5pr1np/QtCK5oe66l 6PdKm/TktGIeueAttZvDUwFMnQBJhRed0IFYRgo6kq5Pllo0Jv3FCyoXtNl5+PmONTI8 FRR41guh2sokVkauAQFbNJQ/0f/Q2iLx5hDxcUaEI3+B4UQqEOvs7Gv5Uj6K3zwTApRl 4jDA==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790292156; x=1790896956; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=wTpbY3cPkJZfs70nxAC+hwTt+X0fXJ5NaVXkEloTFzk=; b=S73DFXtRM2jNvUT87XjpvzHuNpylKoOpbdkS/QHnmL5OjTd9xyfX24nmWFv0xKsDDD cBoO6i5oJLMPFdR6T3yYdUcHXB9qf5OVAiphe3dzBdbyaNPIyxJkp/gZfownbPnyRZTQ XbWGJVFusJEhcFV4NzT6KTnb6L3mI4gDl01cAYH9gZmK1VEJdwlBD/0n7Dj11V0lZp7m hoXqJbHXseM05jy7M+SXA0Huf4VkHSUPgyjjk68hFTw41ye3sBXoVGaPxBOP0J7Pbdcp VZkQgW95xsmKjvmfMUM1o+GEvF96q57lN1OP4y2DV0BM+Aw/c5sXrUDqfS+3ZUuEEWIu kp+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790292156; x=1790896956; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wTpbY3cPkJZfs70nxAC+hwTt+X0fXJ5NaVXkEloTFzk=; b=U+vy2Pe6+E/7g9Gz2wXfDlXVofqf77os32zIDNlSEFH8mjKg9XtCKyv6LHAjAM3mrX nBiTKQQCcmouOvJeXa34s292ubEVSTPXA8YU5EAE/beA6gdQ9sWnPwUSJZ960PcPQZLQ 3ZU835LRxyyPb94A4VAQmpgViz7zOsCx6HEHqud+kZqa4SFj11BxeVRBRPWuuhMmyTBv 1G3f0UnW6U4MOVhO/0Lmd3csE54H6+kXH3bRqZ70xMjEuSLS8/4V3CekbGrifZnJ3C87 rgGaYmlzFR7xmmLoxRQk7NiHLnbAWSn7Vb2fQg5582Y25yTXoGS9oHSHuSsbM6iHJ0Lo 8IVQ== X-Forwarded-Encrypted: i=1; AKwUvBxzMNyElbC/oVSRvth6i52vFSV7dUoG6YkbusU95QH+YP5+nRCV12a7NpuSEgPPQY9d5l3csJsgpIQ=@lists.xenproject.org X-Gm-Message-State: AFuF++lnHY4Ne/T2hmbvR/Ti04YC26x8ik4Fsb68EkeN1KPGRq3LTJnQ Bfh8swojkrSqxjkQmkVdXZ2H7F6zaHi6h8rG1gsSZS/v2YwLv34hO/cGo2RQIX0Wcbfl79A4yKb s1xBNrpWB/+M3QuwopCgXoCO+9TSB7KM= X-Gm-Gg: AYBFou3MNXn7UbmPRMVWdNfhT+XGAd1zy9pWqxaJ5g743I0UYK5nrRb2zdY62SQ/HQH eHov/2Cc1gUtWnLOUl9UaQc9ypVLRMsl5Dj7Q+24UGBqjG8SuP+n56d0iksG8fHfn2J2RKfUoZP dGYuFI8Xhcekql/fqaPsY4ELFWhQGFKmZ5kpOXIcv93Mf7d5IxvvK8R2egPtgxm+XT2D8qev1AC XYgWutqmlnSvK9mvMSvfYWSeMGEPVwhsNe8pritwl+Of3BwP7Popcb0txTeYZ1WepMc5OGcyj1N aMSLt7DpNCvIRk6l8wzrxaLQ1/AUfkFF/yLUofiZgHlI//e10kZhGw== X-Received: by 2002:ac2:4304:0:b0:5ae:b7ca:33ec with SMTP id 2adb3069b0e04-5b8df09bd0amr987494e87.9.1790292155526; Thu, 24 Sep 2026 16:22:35 -0700 (PDT) MIME-Version: 1.0 References: <54a655ad51d994b46dff43e67c969a31772cec4b.1787838455.git.mykola_kvach@epam.com> <427F337F-4D3C-4DEE-9978-5B1AD3AB23D5@arm.com> In-Reply-To: <427F337F-4D3C-4DEE-9978-5B1AD3AB23D5@arm.com> From: Mykola Kvach Date: Fri, 25 Sep 2026 02:22:24 +0300 X-Gm-Features: AclHuK_lHHH6mri1YnQg0j2dw-bGqw1E02spCDzRJGb1L0IeFagr7eA7krbyV1w Message-ID: Subject: Re: [PATCH v12 03/13] xen/arm: gic-v3: tolerate retained redistributor LPI state across CPU_OFF To: Bertrand Marquis Cc: Mykola Kvach , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Luca Fancellu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ebf023/1790292156-532CCB50-43BFEF17/0/0 X-purgate-type: clean X-purgate-size: 9669 Hi Bertrand, Thank you for the review. On Wed, Sep 23, 2026 at 6:36=E2=80=AFPM Bertrand Marquis wrote: > > Hi Mykola, > > > On 27 Aug 2026, at 16:31, Mykola Kvach wrote: > > > > PSCI does not guarantee that a GICv3 redistributor is powered down acro= ss > > CPU_OFF -> CPU_ON. > > > > DEN0022F.b says CPU_OFF powers down the calling core (5.5) and CPU_ON > > brings the core back with a defined initial CPU state (5.6, 6.4). > > However, PSCI leaves interrupt migration and GIC re-initialization to t= he > > supervisory software/firmware stack: the caller must migrate interrupts > > away before CPU_OFF (5.5.2), and the execution context that is lost in = a > > powerdown state must be saved and restored by software (6.8). PSCI also > > calls out GIC management explicitly in 6.8, including retargeting SPIs, > > preventing PPIs/SGIs from targeting a powered down CPU, and reinitializ= ing > > the CPU interface after CPU_ON. > > > > This matches the GIC architecture. IHI0069H.b Chapter 11.1 requires the= PE > > and CPU interface to share a power domain, but explicitly allows the > > associated redistributor, distributor, and ITS to remain powered while = the > > PE and CPU interface are off. All other GIC power-management behavior i= s > > IMPLEMENTATION DEFINED. DEN0050D Chapter 4.2, "Generic Interrupt > > Controller (GIC)", says the GICv3 redistributor may live either in the = AP > > core power domain or in a relatively always-on parent domain. So after > > CPU_OFF -> CPU_ON a secondary CPU can legitimately come back to a live > > redistributor with GICR_CTLR.EnableLPIs still set. > > > > Handle that case in the LPI setup path instead of assuming a fully rese= t > > redistributor. > > > > The LPI path needs special care because the GIC spec makes redistributo= r > > LPI state sticky and partially implementation defined. IHI0069H.b 5.1.1 > > and 5.1.2 say that changing GICR_PROPBASER or GICR_PENDBASER while > > GICR_CTLR.EnableLPIs =3D=3D 1 is UNPREDICTABLE. After clearing EnableLP= Is, > > software must wait for GICR_CTLR.RWP =3D=3D 0 before touching the pendi= ng > > table. The architecture also permits implementations where, once > > EnableLPIs has been set, clearing it again is not guaranteed to work. > > Where an ITS is present, the spec strongly recommends moving LPIs to > > another redistributor before clearing EnableLPIs. > > > > Because of that, treat a retained EnableLPIs state as valid when the > > redistributor still points at Xen's expected PROPBASER/PENDBASER tables= . > > Only try to clear EnableLPIs when the retained configuration does not > > match Xen's state, and wait for RWP before reprogramming the tables. > > > > This is also consistent with platform firmware reality: PSCI and the GI= C > > architecture allow platform-specific redistributor power handling, and = not > > all platform firmware implementations force a full redistributor power-= off > > through implementation-defined controls during CPU_OFF. Xen therefore n= eeds > > to tolerate retained redistributor state on secondary CPU bring-up. > > > > Keep gicv3_populate_rdist() resident as well, because gicv3_cpu_init() > > reuses it on secondary CPU bring-up after init. > > > > Tested using Xen's non-boot CPU disable/enable path on Arm > > FVP_Base_RevC-2xAEMvA, both with and without: > > -C gic_distributor.allow-LPIEN-clear=3D1 > > -C gic_distributor.GICR-clear-enable-supported=3D1 > > and on Orange Pi 5. > > > > Signed-off-by: Mykola Kvach > > Reviewed-by: Luca Fancellu > > --- > > Changes in v10: > > - Drop unrelated gicv3_populate_rdist() printk() format cleanups to kee= p > > the patch focused on retained redistributor LPI state. > > > > Changes in v9: > > - move gicv3_do_wait_for_rwp prototype from its related header to gic.h > > - drop __init from gicv3_populate_rdist(), which is reused on secondary > > CPU bring-up after boot > > - changed print format for smp_processor_id in gicv3_populate_rdist fun= c > > - cosmetic changes > > --- > > xen/arch/arm/gic-v3-lpi.c | 77 +++++++++++++++++++++++++++++++++- > > xen/arch/arm/gic-v3.c | 15 ++++--- > > xen/arch/arm/include/asm/gic.h | 4 ++ > > 3 files changed, 90 insertions(+), 6 deletions(-) > > > > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > > index 9ee338edc2..847da26ff7 100644 > > --- a/xen/arch/arm/gic-v3-lpi.c > > +++ b/xen/arch/arm/gic-v3-lpi.c > > @@ -81,6 +81,13 @@ static DEFINE_PER_CPU(struct lpi_redist_data, lpi_re= dist); > > #define MAX_NR_HOST_LPIS (lpi_data.max_host_lpi_ids - LPI_OFFSET) > > #define HOST_LPIS_PER_PAGE (PAGE_SIZE / sizeof(union host_lpi)) > > > > +#define GICR_PROPBASER_XEN_MASK GENMASK_ULL(51, 12) > > +/* > > + * For retained redistributor state, match the pending table by addres= s only. > > + * Attribute bits such as PTZ may not read back with the programmed va= lue. > > + */ > > +#define GICR_PENDBASER_XEN_MASK GENMASK_ULL(51, 16) > > + > > static union host_lpi *gic_get_host_lpi(uint32_t plpi) > > { > > union host_lpi *block; > > @@ -296,6 +303,60 @@ static int gicv3_lpi_set_pendtable(void __iomem *r= dist_base) > > return 0; > > } > > > > +static uint64_t gicv3_lpi_expected_proptable(void) > > +{ > > + return virt_to_maddr(lpi_data.lpi_property); > > +} > > + > > +static uint64_t gicv3_lpi_expected_pendtable(void) > > +{ > > + return virt_to_maddr(this_cpu(lpi_redist).pending_table); > > +} > > + > > +static bool gicv3_lpi_tables_match(void __iomem *rdist_base) > > +{ > > + uint64_t propbase, pendbase; > > + > > + if ( !lpi_data.lpi_property || !this_cpu(lpi_redist).pending_table= ) > > + return false; > > + > > + propbase =3D readq_relaxed(rdist_base + GICR_PROPBASER); > > + pendbase =3D readq_relaxed(rdist_base + GICR_PENDBASER); > > + > > + return ((propbase & GICR_PROPBASER_XEN_MASK) =3D=3D > > + (gicv3_lpi_expected_proptable() & GICR_PROPBASER_XEN_MASK)= ) && > > + ((pendbase & GICR_PENDBASER_XEN_MASK) =3D=3D > > + (gicv3_lpi_expected_pendtable() & GICR_PENDBASER_XEN_MASK)= ); > > +} > > + > > +static int gicv3_lpi_disable_lpis(void __iomem *rdist_base) > > +{ > > + uint32_t reg =3D readl_relaxed(rdist_base + GICR_CTLR); > > + int ret; > > + > > + if ( !(reg & GICR_CTLR_ENABLE_LPIS) ) > > + return 0; > > + > > + writel_relaxed(reg & ~GICR_CTLR_ENABLE_LPIS, rdist_base + GICR_CTL= R); > > + > > + /* > > + * The spec only guarantees programmability when we have observed = the bit > > + * cleared. Where clearing is supported, RWP must reach 0 before t= ouching > > + * PROPBASER/PENDBASER again. > > + */ > > + wmb(); > > + > > + ret =3D gicv3_do_wait_for_rwp(rdist_base, GICR_CTLR_RWP); > > + if ( ret ) > > + return ret; > > + > > + reg =3D readl_relaxed(rdist_base + GICR_CTLR); > > + if ( reg & GICR_CTLR_ENABLE_LPIS ) > > + return -EBUSY; > > + > > + return 0; > > +} > > + > > /* > > * Tell a redistributor about the (shared) property table, allocating o= ne > > * if not already done. > > @@ -374,7 +435,21 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base= ) > > /* Make sure LPIs are disabled before setting up the tables. */ > > reg =3D readl_relaxed(rdist_base + GICR_CTLR); > > if ( reg & GICR_CTLR_ENABLE_LPIS ) > > - return -EBUSY; > > + { > > + if ( gicv3_lpi_tables_match(rdist_base) ) > > + return -EBUSY; > > I am wondering if there is a corner case when a CPU is unplugged and then > plugged back in. free_percpu_area() eventually frees the per-CPU area > containing lpi_redist.pending_table, but not the table itself. On the nex= t > cpu_up(), gicv3_lpi_allocate_pendtable() allocates a new table, and I can= not > find where the old one is freed. > > If the redistributor kept EnableLPIs=3D1 and GICR_PENDBASER pointing to t= he > old table, wouldn't gicv3_lpi_tables_match() fail? > > What will happen if EnableLPIs cannot be cleared ? (i think this is somet= hing > possible in the hardware). The sequence you describe would need to be handled when adding CPU hotplug support on Arm. There is currently no runtime caller for such an offline/online cycle outside system suspend/resume. During system suspend, the common code preserves the per-CPU area. The following GICv3 suspend/resume patch also skips pending-table allocation on resume, so the existing table and pointer are reused. The pending-table lifetime across normal CPU hotplug should be handled by the CPU hotplug series. --- While checking CPU bring-up failures during resume, I found a separate issue in the common cleanup code. Both CPU_UP_CANCELED and CPU_RESUME_FAILED can call free_percpu_area() for the same CPU during resume. The release metadata, including the rcu_head, is itself stored in that CPU's per-CPU area. If the first release has completed, another call would access invalid per-CPU state. Otherwise, it can queue the same rcu_head again. The timer and CPU-pool callbacks on CPU_RESUME_FAILED also still need the per-CPU area. On x86, park_offline_cpus prevents this particular release path. I plan to address this in a separate preparatory patch in this series, keeping the per-CPU area available until the final CPU_RESUME_FAILED cleanup and releasing it only once. Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Fri Sep 25 00:04:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 00:04:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433207.1653988 (Exim 4.92) (envelope-from ) id 1x9tPx-0004HE-Vd; Fri, 25 Sep 2026 00:03:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433207.1653988; Fri, 25 Sep 2026 00:03:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9tPx-0004H7-So; Fri, 25 Sep 2026 00:03:57 +0000 Received: by outflank-mailman (input) for mailman id 1433207; Fri, 25 Sep 2026 00:03:56 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9tPv-0004H1-MS for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 00:03:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9tPu-006gpl-RV for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 02:03:54 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5ba3d-8faa-0a2a0a5109dd-0a2a4502b700-30 for ; Fri, 25 Sep 2026 02:03:54 +0200 Received: from [74.125.229.205] (helo=mail-lf2-f13.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5ba6a-6ca4-0a2a45020019-4a7de5cd8c2d-3 for ; Fri, 25 Sep 2026 02:03:54 +0200 Received: by mail-lf2-f13.google.com with SMTP id 2adb3069b0e04-5b8b402f4e3so435974e87.2 for ; Thu, 24 Sep 2026 17:03:54 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version" ARC-Seal: i=1; a=rsa-sha256; t=1790294634; cv=none; d=google.com; s=arc-20260327; b=Rwz7jEHUlNgwyXOyjNjjWxK0IAPHryfB80CKmaeEZJnN3bhn6AiX/4VAAeDnJZH3vy cJvtwDlcuOt2dPFXJe+6KuSyHTyZL987cG0BRd2EWLq7BhrIcrvtyzK5RIv5NkOpHnar 46fgsOXZpf7/mnWOuBQA9VWvycISUQXnx5KffyFyBon6ABaC+xkF8g06VMHVyiXIZNH2 k/9BoAb5UCm8ge6dcdClGf+ZOneqGrSCGiQ9b+pc4zlsDbq44YpADg+Ds6tRTzALqE23 EklKzloe6JM1MFOUrJCconPoW83U7HIVweiay0wXWMHA62mI/cECxhhiLouWRdUV4nq1 St/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LAtR1MU7pBboArztGT2RTnp5s5hhpc9quEKm+QDeBo8=; fh=VVygVqEKqxbSkkpG2KWHkBBqFKK3JTiOtCO4AzPSZ7s=; b=UcsLRsbJ1Gimfbvb2AA7aKscdajhkGQwU6yFlj1/X6vyA7IR8lLGShm8VFz5nztxKT KNfLWCnRE9HWBcE/rXjaLfqwaNnbYAl3z7yqBT79Cm2DG3wTwInARLvfVBWufx64LS6H kSdlm/Me6yipnkStLCXPqEkplbPeHtaB/77Xo1QfT0sKG2cMwhbYGBVYkWFoX57UBF9i U5XqEm2rkyhq7PjNux9oGTs2Jyf25tGTEpk1RMurVArZ+369euR5Yf29+D20rkFf7pNC oCoC/+NuamDIF+uhhG8uFUGG7Oz4OdBT7qxh8lca/FKvMLgHH/V376GeVF9tHBwkpR+Y G61Q==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790294634; x=1790899434; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=LAtR1MU7pBboArztGT2RTnp5s5hhpc9quEKm+QDeBo8=; b=Rt/J/0UcLgGbxCjXb0totUinJQvGld30wnoEIS6qC6R0zgayyF39xj4ZcXJr1QJyug N3f47N+V/K+8HqEt+Ew+nEylrl62B70XdSBIEtw2kJvuP5INi+QeNKlotIpaLLvreFl3 CMn3jEQV6zfFAs1H3bF6TypjvkyB4eAxJDebjliuGokUlR2vVuJWPnhQK59xQJ11f1I8 jPWFtpBtvVCh6hfzRDALx3BvdVXrKkgtk7kWYis7ge/De9BRmHB2qUdBWCfSdgSesqas YLzs56oWWTCyjDWDj1HUB7APck28xG9a2w59YFtIm3YyjdWlS9DRaZywIU2ayyoQuvgz NAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790294634; x=1790899434; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LAtR1MU7pBboArztGT2RTnp5s5hhpc9quEKm+QDeBo8=; b=tFRWEmazzIwuOv57Ao24WV8dscGKik2tYTer3PhTdkVFtaP3j/ORfZXLZDCG0It4NH mq/bXV/8LCGxt+I6Hb9wuccA6V/daKqYgDD+NpfZZRDNWcKZvr7x53maFK0EYicPPuCc T7e3SAzHFyaJnh2skxyIEITI1SoPQ8We+Kaz1fWkn4t/CJlrK390gPIDRiE/SKP316gu DWqydVz8TRt6C0knlQxonJoi8NnIrR+0Jwl/TWSH3n5BnAlL6MEfyPd6pIn0Xu9Eucg4 zotgdmASLmFpn174iuDu0j8y3nsR1njzIg5dkhdOsEASToybM9Qw0EYFYJAEAus3T7pe altg== X-Forwarded-Encrypted: i=1; AKwUvBzMQaq/9oURn+JiDRzqXkbz6+bIu2YyIAAlA8UOUlxqYr8AuIYAs92h7/eo2FvkN0GqXX4PoVwuHy0=@lists.xenproject.org X-Gm-Message-State: AFuF++kBnPCQb+p1s3GsJ6ikEpGx0ANzKZnAqtF1FwODMHiCHo42oAAf Fw9n0f+79g5OGo7xGnFScRPL2/8hJA7eAtoF1LIap5Nij9u0zowEjy1MZQhYckEp/ox01K9O7mp qa0ZqBI0lGjsApYyJlWqFtQeb/dysFO8= X-Gm-Gg: AYBFou1OblPgjH8ELcHf4vT+7fa0d3hA0G6ccgB3Pwy66tnNhiF+EOiA5zYcz0hUeeF oUpE/cNoZxSXK2AjS54zUclk3LXoSVHZyeid8aha9XTt7X+uLoRt0W+CVkQ8tUuEe7mUsBPCG7o /jjL5rLXzqdnVj0kdZqc+UhYq8F9GY0RMkZ6kGSVBu3oJc2gCtrzqgS4dVPHvQ5WhafwknRbLBg rgO172++pNoUYVMz1pt0dRHlQ+AlAa0K9n9o3IW71ruItrd1BIsljT3zl4Sv1CmG5pwhROxbZ38 RDq/hKHVWpwOvkvVsnC8oGQooXhKRKoYlAbFN5hEMynIQQL3SgWaBw== X-Received: by 2002:a05:6512:3f22:b0:5b6:7fa:e96b with SMTP id 2adb3069b0e04-5b8df06b2c0mr1295904e87.14.1790294633838; Thu, 24 Sep 2026 17:03:53 -0700 (PDT) MIME-Version: 1.0 References: <1f311886ad3162f59749210c7dce26f9d089d010.1787838455.git.mykola_kvach@epam.com> In-Reply-To: From: Mykola Kvach Date: Fri, 25 Sep 2026 03:03:42 +0300 X-Gm-Features: AclHuK-PiGzB3vwsrjjkOXLvqVETll3LrDDm_gOSzIxnRtvgH9ry2XIbZIuLHR8 Message-ID: Subject: Re: [PATCH v12 04/13] xen/arm: gic-v3: Implement GICv3 suspend/resume functions To: Bertrand Marquis Cc: Mykola Kvach , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Luca Fancellu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1790294634-678BC2AC-578E348F/0/0 X-purgate-type: clean X-purgate-size: 20833 Hi Bertrand, Thank you for the review. On Wed, Sep 23, 2026 at 6:58=E2=80=AFPM Bertrand Marquis wrote: > > Hi Mykola, > > > On 27 Aug 2026, at 16:31, Mykola Kvach wrote: > > > > System suspend may lead to a state where GIC would be powered down. > > Therefore, Xen should save/restore the context of GIC on suspend/resume= . > > > > Note that the context consists of states of registers which are > > controlled by the hypervisor. Other GIC registers which are accessible > > by guests are saved/restored on context switch. > > > > Before continuing suspend, also verify that the physical CPU interface > > has no Group 1 active-priority state left. Use ICC_CTLR_EL1.PRIbits to > > decide which ICC_AP1R_EL1 registers are implemented, so Xen does not > > read an unimplemented AP1R register. > > > > Signed-off-by: Mykola Kvach > > Reviewed-by: Luca Fancellu > > --- > > Changes in V10: > > - abort suspend when the physical Group 1 active-priority state is stil= l > > present, deriving accessible ICC_AP1R_EL1 registers from > > ICC_CTLR_EL1.PRIbits; > > - re-enable the redistributor before restoring CPU and virtual interfac= e > > state on the suspend abort path; > > - panic if the redistributor cannot be re-enabled on the suspend abort = path; > > - avoid saving/restoring reserved GICD_IPRIORITYR and GICD_IROUTER entr= ies > > for a partially populated last SPI block; > > - disable Distributor group forwarding while preserving affinity routin= g > > state before restoring Distributor configuration; > > - disable SPI/eSPI forwarding and wait for RWP before restoring > > GICD_ICFGR.Int_config. > > > > Changes in V9: > > - fix the suspend-context comment typo and split dist_ctx declarations; > > - restore ICC_IGRPEN1_EL1 on the suspend error path; > > - re-initialize GICD_IGROUPRnE during resume; > > - restore GICD_IROUTER only after re-enabling ARE_NS during resume. > > > > Changes in V8: > > - use right rdist base for prop/pend baser and ctrl > > > > Changes in V7: > > - restore LPI regs on resume > > - add timeout during redist disabling > > - squash with suspend/resume handling for GICv3 eSPI registers > > - drop ITS guard paths so suspend/resume always runs; switch missing ct= x > > allocation to panic > > - trim TODO comments; narrow redistributor storage to PPI icfgr > > - keep distributor context allocation even without ITS; adjust resume > > to use GENMASK(31, 0) for clearing enables > > - drop storage of the SGI configuration register, as SGIs are always > > edge-triggered > > --- > > xen/arch/arm/gic-v3-lpi.c | 3 + > > xen/arch/arm/gic-v3.c | 458 ++++++++++++++++++++++- > > xen/arch/arm/include/asm/arm64/sysregs.h | 5 + > > xen/arch/arm/include/asm/gic_v3_defs.h | 3 + > > 4 files changed, 466 insertions(+), 3 deletions(-) > > > > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c > > index 847da26ff7..a63c8c4979 100644 > > --- a/xen/arch/arm/gic-v3-lpi.c > > +++ b/xen/arch/arm/gic-v3-lpi.c > > @@ -467,6 +467,9 @@ static int cpu_callback(struct notifier_block *nfb,= unsigned long action, > > switch ( action ) > > { > > case CPU_UP_PREPARE: > > + if ( system_state =3D=3D SYS_STATE_resume ) > > + break; > > + > > rc =3D gicv3_lpi_allocate_pendtable(cpu); > > if ( rc ) > > printk(XENLOG_ERR "Unable to allocate the pendtable for CPU= %lu\n", > > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > > index b16888ad84..038bf41142 100644 > > --- a/xen/arch/arm/gic-v3.c > > +++ b/xen/arch/arm/gic-v3.c > > @@ -1078,12 +1078,12 @@ out: > > return res; > > } > > > > -static void gicv3_hyp_disable(void) > > +static void gicv3_hyp_enable(bool enable) > > { > > register_t hcr; > > > > hcr =3D READ_SYSREG(ICH_HCR_EL2); > > - hcr &=3D ~GICH_HCR_EN; > > + hcr =3D enable ? (hcr | GICH_HCR_EN) : (hcr & ~GICH_HCR_EN); > > WRITE_SYSREG(hcr, ICH_HCR_EL2); > > isb(); > > } > > @@ -1190,7 +1190,7 @@ static void gicv3_disable_interface(void) > > spin_lock(&gicv3.lock); > > > > gicv3_cpu_disable(); > > - gicv3_hyp_disable(); > > + gicv3_hyp_enable(false); > > > > spin_unlock(&gicv3.lock); > > } > > @@ -1926,6 +1926,450 @@ static bool gic_dist_supports_lpis(void) > > return (readl_relaxed(GICD + GICD_TYPER) & GICD_TYPE_LPIS); > > } > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + > > +/* This struct represents a block of 32 IRQs */ > > +struct dist_irq_block { > > + uint32_t icfgr[2]; > > + uint32_t ipriorityr[8]; > > + uint64_t irouter[32]; > > + uint32_t isactiver; > > + uint32_t isenabler; > > +}; > > + > > +struct redist_ctx { > > + uint32_t ctlr; > > + uint32_t icfgr; /* only PPIs stored */ > > Can you capitalize first comment letter ? > s/only/Only/ > > > + uint32_t igroupr; > > + uint32_t ipriorityr[8]; > > + uint32_t isactiver; > > + uint32_t isenabler; > > + > > + uint64_t pendbase; > > + uint64_t propbase; > > +}; > > + > > +/* GICv3 registers to be saved/restored on system suspend/resume */ > > +struct gicv3_ctx { > > + struct dist_ctx { > > + uint32_t ctlr; > > + struct dist_irq_block *irqs; > > + struct dist_irq_block *espi_irqs; > > + } dist; > > + > > + /* have only one rdist structure for last running CPU during suspe= nd */ > > Same here > s/have/Have/ > > > + struct redist_ctx rdist; > > + > > + struct cpu_ctx { > > + uint32_t ctlr; > > + uint32_t pmr; > > + uint32_t bpr; > > + uint32_t sre_el2; > > + uint32_t grpen; > > + } cpu; > > +}; > > + > > +static struct gicv3_ctx gicv3_ctx; > > + > > +static void __init gicv3_alloc_context(void) > > +{ > > + uint32_t blocks =3D DIV_ROUND_UP(gicv3_info.nr_lines, 32); > > + > > + /* The spec allows for systems without any SPIs */ > > + if ( blocks > 1 ) > > + { > > + gicv3_ctx.dist.irqs =3D xzalloc_array(struct dist_irq_block, b= locks - 1); > > + if ( !gicv3_ctx.dist.irqs ) > > + panic("Failed to allocate memory for GICv3 suspend context= \n"); > > + } > > + > > +#ifdef CONFIG_GICV3_ESPI > > + if ( !gic_number_espis() ) > > + return; > > + > > + blocks =3D gic_number_espis() / 32; > > + gicv3_ctx.dist.espi_irqs =3D xzalloc_array(struct dist_irq_block, = blocks); > > + if ( !gicv3_ctx.dist.espi_irqs ) > > + panic("Failed to allocate memory for GICv3 eSPI suspend contex= t\n"); > > +#endif > > +} > > + > > +static int gicv3_disable_redist(void) > > +{ > > + void __iomem *waker =3D GICD_RDIST_BASE + GICR_WAKER; > > + s_time_t deadline; > > + > > + /* > > + * Avoid infinite loop if Non-secure does not have access to GICR_= WAKER. > > + * See Arm IHI 0069H.b, 12.11.42 GICR_WAKER: > > + * When GICD_CTLR.DS =3D=3D 0 and an access is Non-secure acce= sses to this > > + * register are RAZ/WI. > > + */ > > + if ( !(readl_relaxed(GICD + GICD_CTLR) & GICD_CTLR_DS) ) > > + return 0; > > + > > + deadline =3D NOW() + MILLISECS(1000); > > + > > + writel_relaxed(readl_relaxed(waker) | GICR_WAKER_ProcessorSleep, w= aker); > > + while ( (readl_relaxed(waker) & GICR_WAKER_ChildrenAsleep) =3D=3D = 0 ) > > + { > > + if ( NOW() > deadline ) > > + { > > + printk("GICv3: Timeout waiting for redistributor to sleep\= n"); > > + return -ETIMEDOUT; > > + } > > + cpu_relax(); > > + udelay(10); > > + } > > + > > + return 0; > > +} > > + > > +#define GET_SPI_REG_OFFSET(name, is_espi) \ > > + ((is_espi) ? GICD_##name##nE : GICD_##name) > > + > > +static void gicv3_store_spi_irq_block(struct dist_irq_block *irqs, > > + unsigned int i, unsigned int nr_= irqs, > > + bool is_espi) > > +{ > > + void __iomem *base; > > + unsigned int irq, nr_priority_regs; > > + > > + ASSERT(nr_irqs && nr_irqs <=3D 32); > > + nr_priority_regs =3D DIV_ROUND_UP(nr_irqs, 4); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(ICFGR, is_espi) + i * sizeof(ir= qs->icfgr); > > + irqs->icfgr[0] =3D readl_relaxed(base); > > + irqs->icfgr[1] =3D readl_relaxed(base + 4); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(IPRIORITYR, is_espi); > > + base +=3D i * sizeof(irqs->ipriorityr); > > + for ( irq =3D 0; irq < nr_priority_regs; irq++ ) > > + irqs->ipriorityr[irq] =3D readl_relaxed(base + 4 * irq); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(IROUTER, is_espi); > > + base +=3D i * sizeof(irqs->irouter); > > + for ( irq =3D 0; irq < nr_irqs; irq++ ) > > + irqs->irouter[irq] =3D readq_relaxed_non_atomic(base + 8 * irq= ); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(ISACTIVER, is_espi); > > + base +=3D i * sizeof(irqs->isactiver); > > + irqs->isactiver =3D readl_relaxed(base); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(ISENABLER, is_espi); > > + base +=3D i * sizeof(irqs->isenabler); > > + irqs->isenabler =3D readl_relaxed(base); > > +} > > + > > +static void gicv3_restore_spi_irq_config(struct dist_irq_block *irqs, > > + unsigned int i, unsigned int = nr_irqs, > > + bool is_espi) > > +{ > > + void __iomem *base; > > + unsigned int irq, nr_priority_regs; > > + > > + ASSERT(nr_irqs && nr_irqs <=3D 32); > > + nr_priority_regs =3D DIV_ROUND_UP(nr_irqs, 4); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(ICFGR, is_espi) + i * sizeof(ir= qs->icfgr); > > + writel_relaxed(irqs->icfgr[0], base); > > + writel_relaxed(irqs->icfgr[1], base + 4); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(IPRIORITYR, is_espi); > > + base +=3D i * sizeof(irqs->ipriorityr); > > + for ( irq =3D 0; irq < nr_priority_regs; irq++ ) > > + writel_relaxed(irqs->ipriorityr[irq], base + 4 * irq); > > +} > > + > > +static void gicv3_restore_spi_irq_routing(struct dist_irq_block *irqs, > > + unsigned int i, unsigned int= nr_irqs, > > + bool is_espi) > > +{ > > + void __iomem *base; > > + unsigned int irq; > > + > > + ASSERT(nr_irqs && nr_irqs <=3D 32); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(IROUTER, is_espi); > > + base +=3D i * sizeof(irqs->irouter); > > + for ( irq =3D 0; irq < nr_irqs; irq++ ) > > + writeq_relaxed_non_atomic(irqs->irouter[irq], base + 8 * irq); > > +} > > + > > +static void gicv3_disable_spi_irq_block(unsigned int i, bool is_espi) > > +{ > > + void __iomem *base; > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(ICENABLER, is_espi) + i * 4; > > + writel_relaxed(GENMASK(31, 0), base); > > +} > > + > > +static void gicv3_restore_spi_irq_state(struct dist_irq_block *irqs, > > + unsigned int i, bool is_espi) > > +{ > > + void __iomem *base; > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(ISENABLER, is_espi); > > + base +=3D i * sizeof(irqs->isenabler); > > + writel_relaxed(irqs->isenabler, base); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(ICACTIVER, is_espi) + i * 4; > > + writel_relaxed(GENMASK(31, 0), base); > > + > > + base =3D GICD + GET_SPI_REG_OFFSET(ISACTIVER, is_espi); > > + base +=3D i * sizeof(irqs->isactiver); > > + writel_relaxed(irqs->isactiver, base); > > +} > > + > > +static int gicv3_check_ap1r(unsigned int n, register_t apr) > > +{ > > + if ( !apr ) > > + return 0; > > + > > + printk(XENLOG_ERR "GICv3: suspend aborted: ICC_AP1R%u_EL1=3D%#" > > + PRIregister"\n", n, apr); > > + > > + return -EBUSY; > > +} > > + > > +static int gicv3_check_active_priorities(register_t ctlr) > > +{ > > + unsigned int pribits =3D MASK_EXTR(ctlr, ICC_CTLR_EL1_PRIBITS_MASK= ) + 1; > > + int ret; > > + > > + /* > > + * Xen enables physical Group 1 interrupts through ICC_IGRPEN1_EL1= , > > + * so only the physical Group 1 active-priority registers are rele= vant > > + * here. Use ICC_CTLR_EL1.PRIbits for the physical CPU interface, = not > > + * ICH_VTR_EL2, which describes the virtual interface. ICC_AP1R1_E= L1 is > > + * only implemented with at least 6 physical priority bits, and > > + * ICC_AP1R2_EL1/ICC_AP1R3_EL1 with at least 7. > > + */ > > + switch ( pribits ) > > + { > > + case 8: > > + case 7: > > + ret =3D gicv3_check_ap1r(3, READ_SYSREG(ICC_AP1R3_EL1)); > > + if ( ret ) > > + return ret; > > + ret =3D gicv3_check_ap1r(2, READ_SYSREG(ICC_AP1R2_EL1)); > > + if ( ret ) > > + return ret; > > + /* Fall through */ > > + case 6: > > + ret =3D gicv3_check_ap1r(1, READ_SYSREG(ICC_AP1R1_EL1)); > > + if ( ret ) > > + return ret; > > + /* Fall through */ > > + default: > > + return gicv3_check_ap1r(0, READ_SYSREG(ICC_AP1R0_EL1)); > > + } > > +} > > + > > +static int gicv3_suspend(void) > > +{ > > + unsigned int i, nr_irqs; > > + void __iomem *base; > > + int ret; > > + struct redist_ctx *rdist =3D &gicv3_ctx.rdist; > > + > > + /* Save GICC configuration */ > > + gicv3_ctx.cpu.ctlr =3D READ_SYSREG(ICC_CTLR_EL1); > > + gicv3_ctx.cpu.pmr =3D READ_SYSREG(ICC_PMR_EL1); > > + gicv3_ctx.cpu.bpr =3D READ_SYSREG(ICC_BPR1_EL1); > > + gicv3_ctx.cpu.sre_el2 =3D READ_SYSREG(ICC_SRE_EL2); > > + gicv3_ctx.cpu.grpen =3D READ_SYSREG(ICC_IGRPEN1_EL1); > > + > > + gicv3_disable_interface(); > > + > > + ret =3D gicv3_check_active_priorities(gicv3_ctx.cpu.ctlr); > > + if ( ret ) > > + goto out_enable_iface; > > + > > + ret =3D gicv3_disable_redist(); > > + if ( ret ) > > + goto out_enable_iface; > > I am wondering about the timeout case here. > > gicv3_disable_redist() has set ProcessorSleep to 1, but returns while > ChildrenAsleep is still 0. > This new error path then calls gicv3_enable_redist(), which clears > ProcessorSleep. > > Could that happen before ChildrenAsleep reaches 1? > The GIC specification says that transition is UNPREDICTABLE. > How should we handle the timeout? Yes, ChildrenAsleep may still be 0 when the error path calls gicv3_enable_redist(). Clearing ProcessorSleep in that state is UNPREDICTABLE. I propose calling panic() if waiting for ChildrenAsleep to become 1 times out, before entering the rollback path. We cannot safely restore the CPU interface without completing the redistributor sleep/wake sequence. > > > + > > + /* Save GICR configuration */ > > + gicv3_redist_wait_for_rwp(); > > + > > + base =3D GICD_RDIST_BASE; > > + > > + rdist->ctlr =3D readl_relaxed(base + GICR_CTLR); > > + > > + rdist->propbase =3D readq_relaxed(base + GICR_PROPBASER); > > + rdist->pendbase =3D readq_relaxed(base + GICR_PENDBASER); > > + > > + base =3D GICD_RDIST_SGI_BASE; > > + > > + /* Save priority on PPI and SGI interrupts */ > > + for ( i =3D 0; i < NR_GIC_LOCAL_IRQS / 4; i++ ) > > + rdist->ipriorityr[i] =3D readl_relaxed(base + GICR_IPRIORITYR0= + 4 * i); > > + > > + rdist->isactiver =3D readl_relaxed(base + GICR_ISACTIVER0); > > + rdist->isenabler =3D readl_relaxed(base + GICR_ISENABLER0); > > + rdist->igroupr =3D readl_relaxed(base + GICR_IGROUPR0); > > + rdist->icfgr =3D readl_relaxed(base + GICR_ICFGR1); > > + > > + /* Save GICD configuration */ > > + gicv3_dist_wait_for_rwp(); > > + gicv3_ctx.dist.ctlr =3D readl_relaxed(GICD + GICD_CTLR); > > + > > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > > + { > > + nr_irqs =3D min(32U, gicv3_info.nr_lines - i * 32); > > + gicv3_store_spi_irq_block(gicv3_ctx.dist.irqs + i - 1, i, nr_i= rqs, > > + false); > > + } > > + > > +#ifdef CONFIG_GICV3_ESPI > > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > > + gicv3_store_spi_irq_block(gicv3_ctx.dist.espi_irqs + i, i, 32,= true); > > +#endif > > + > > + return 0; > > + > > + out_enable_iface: I also noticed that this label should be immediately before gicv3_hyp_enable(true). > > + if ( gicv3_enable_redist() ) > > + panic("GICv3: Failed to re-enable redistributor after suspend = abort\n"); > > + > > + gicv3_hyp_enable(true); > > + WRITE_SYSREG(gicv3_ctx.cpu.grpen, ICC_IGRPEN1_EL1); > > + isb(); > > + > > + return ret; > > +} > > + > > +static void gicv3_resume(void) > > +{ > > + int ret; > > + unsigned int i, nr_irqs; > > + uint32_t dist_ctlr; > > + void __iomem *base; > > + struct redist_ctx *rdist =3D &gicv3_ctx.rdist; > > + > > + dist_ctlr =3D gicv3_ctx.dist.ctlr & GICD_CTLR_ARE_NS; > > + > > + /* Disable group forwarding while preserving affinity routing stat= e. */ > > + writel_relaxed(dist_ctlr, GICD + GICD_CTLR); > > + gicv3_dist_wait_for_rwp(); > > + > > + /* > > + * IHI0069H.b 12.9.9 says changing GICD_ICFGR.Int_config > > + * while the interrupt is individually enabled is UNPREDICTABLE. > > + * Disable SPIs first; 4.7.1 defines GICD_ICENABLER, n > 0, > > + * as the per-SPI disable mechanism. > > + */ > > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > > + gicv3_disable_spi_irq_block(i, false); > > + > > +#ifdef CONFIG_GICV3_ESPI > > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > > + gicv3_disable_spi_irq_block(i, true); > > +#endif > > + > > + gicv3_dist_wait_for_rwp(); > > + > > + for ( i =3D NR_GIC_LOCAL_IRQS; i < gicv3_info.nr_lines; i +=3D 32 = ) > > + writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPR + (i / 32) = * 4); > > + > > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > > + { > > + nr_irqs =3D min(32U, gicv3_info.nr_lines - i * 32); > > + gicv3_restore_spi_irq_config(gicv3_ctx.dist.irqs + i - 1, i, n= r_irqs, > > + false); > > + } > > + > > +#ifdef CONFIG_GICV3_ESPI > > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > > + { > > + writel_relaxed(GENMASK(31, 0), GICD + GICD_IGROUPRnE + i * 4); > > + gicv3_restore_spi_irq_config(gicv3_ctx.dist.espi_irqs + i, i, = 32, > > + true); > > + } > > +#endif > > + > > + if ( dist_ctlr ) > > + { > > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ = ) > > + { > > + nr_irqs =3D min(32U, gicv3_info.nr_lines - i * 32); > > + gicv3_restore_spi_irq_routing(gicv3_ctx.dist.irqs + i - 1,= i, > > + nr_irqs, false); > > + } > > + > > +#ifdef CONFIG_GICV3_ESPI > > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > > + gicv3_restore_spi_irq_routing(gicv3_ctx.dist.espi_irqs + i= , i, > > + 32, true); > > +#endif > > + } > > + > > + for ( i =3D 1; i < DIV_ROUND_UP(gicv3_info.nr_lines, 32); i++ ) > > + gicv3_restore_spi_irq_state(gicv3_ctx.dist.irqs + i - 1, i, fa= lse); > > + > > +#ifdef CONFIG_GICV3_ESPI > > + for ( i =3D 0; i < gic_number_espis() / 32; i++ ) > > + gicv3_restore_spi_irq_state(gicv3_ctx.dist.espi_irqs + i, i, t= rue); > > +#endif > > + > > + writel_relaxed(gicv3_ctx.dist.ctlr, GICD + GICD_CTLR); > > + gicv3_dist_wait_for_rwp(); > > + > > + ret =3D gicv3_lpi_init_rdist(GICD_RDIST_BASE); > > + /* > > + * If LPIs are already enabled, assume firmware or the still-power= ed > > + * redistributor has valid PROPBASER/PENDBASER and skip reprogramm= ing. > > + * Return -EBUSY so callers can ignore this case. > > + */ > > + if ( ret && ret !=3D -ENODEV && ret !=3D -EBUSY ) > > + panic("GICv3: Failed to re-initialize LPIs during resume\n"); > > + else if ( ret =3D=3D -EBUSY ) /* extra checks, just to be sure */ > > Comment first letter capitalize: > s/extra/Extra/ I will also fix all the capitalization issues you pointed out. Thanks, Mykola From xen-devel-bounces@lists.xenproject.org Fri Sep 25 00:07:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 00:07:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433223.1653997 (Exim 4.92) (envelope-from ) id 1x9tTC-0004uX-DA; Fri, 25 Sep 2026 00:07:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433223.1653997; Fri, 25 Sep 2026 00:07:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9tTC-0004uQ-AP; Fri, 25 Sep 2026 00:07:18 +0000 Received: by outflank-mailman (input) for mailman id 1433223; Fri, 25 Sep 2026 00:07:17 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9tTA-0004uK-Jb for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 00:07:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9tT9-00FztK-R8 for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 02:07:15 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab5bb1e-bab6-0a2a0a5309dd-0a2a4506bb42-10 for ; Fri, 25 Sep 2026 02:07:15 +0200 Received: from [140.77.166.138] (helo=sonata.ens-lyon.org) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab5bb33-195a-0a2a45060019-8c4da68aea82-3 for ; Fri, 25 Sep 2026 02:07:15 +0200 Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id 27EA0A492E; Fri, 25 Sep 2026 02:07:15 +0200 (CEST) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vLshHm82DSb; Fri, 25 Sep 2026 02:07:15 +0200 (CEST) Received: from end (lfbn-bor-1-980-210.w90-120.abo.wanadoo.fr [90.120.173.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id A846BA4903; Fri, 25 Sep 2026 02:07:14 +0200 (CEST) Received: from samy by end with local (Exim 4.100) (envelope-from ) id 1x9tT8-000000003EC-0w3x; Fri, 25 Sep 2026 02:07:14 +0200 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To"; dkim=pass header.s=dkim header.d=ens-lyon.org header.i="@ens-lyon.org" header.h="Date:From:To:Cc:Subject:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1790294835; bh=awaxMZ8zu6tzPflq/tk9cDqyxOwFQ5beSXhynFvofl8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JX1isl/5xTfyv+JhuGR4ApG+fkK1bmXdrxkg/9m4DUomES2pt69rQgumKIGHhUobA pQakVYkMC+raqQ8TqiN2C+fy4N7UxJ87wnKg1GEhbLhARhXlqd7LApIsn0o5OwVeKW uDExQ7lbkBvXC1X/TOdDiGamTty5CqFSeeO/jvXwn3rD/W0f4iIhZ9BxXeZmiLRWXz C2zfZpBXtp2GCGsND3Qwmc/f7nViXnpEhGb/6knkAgklcEVhdzrTQVScA+E/iEkAYJ zCe0w+HckPmTb8XFNCkghh1H3aXhyapvVyXz7awZ10XcGzdHQJfqSsjHudcS/blsz4 h5Ycow/k4gwrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens-lyon.org; s=dkim; t=1790294835; bh=awaxMZ8zu6tzPflq/tk9cDqyxOwFQ5beSXhynFvofl8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JX1isl/5xTfyv+JhuGR4ApG+fkK1bmXdrxkg/9m4DUomES2pt69rQgumKIGHhUobA pQakVYkMC+raqQ8TqiN2C+fy4N7UxJ87wnKg1GEhbLhARhXlqd7LApIsn0o5OwVeKW uDExQ7lbkBvXC1X/TOdDiGamTty5CqFSeeO/jvXwn3rD/W0f4iIhZ9BxXeZmiLRWXz C2zfZpBXtp2GCGsND3Qwmc/f7nViXnpEhGb/6knkAgklcEVhdzrTQVScA+E/iEkAYJ zCe0w+HckPmTb8XFNCkghh1H3aXhyapvVyXz7awZ10XcGzdHQJfqSsjHudcS/blsz4 h5Ycow/k4gwrQ== Date: Fri, 25 Sep 2026 02:07:14 +0200 From: Samuel Thibault To: Juergen Gross Cc: xen-devel@lists.xenproject.org, Anthony PERARD Subject: Re: [PATCH v3 2/4] stubdom: remove pciutils Message-ID: Mail-Followup-To: Samuel Thibault , Juergen Gross , xen-devel@lists.xenproject.org, Anthony PERARD References: <20260922072711.385956-1-jgross@suse.com> <20260922072711.385956-3-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260922072711.385956-3-jgross@suse.com> Organization: I am not organized X-purgate-ID: tlsNG-16d1c6/1790294835-FD80D77B-79420842/0/0 X-purgate-type: clean X-purgate-size: 17777 Juergen Gross, le mar. 22 sept. 2026 09:27:09 +0200, a ecrit: > There is no user of libpci left in stubdoms. > > Remove libpci from the stubdom build system. > > Signed-off-by: Juergen Gross Acked-by: Samuel Thibault Thanks! > --- > V3: > - add comment regarding upstream pciutils (Samuel Thibault) > --- > config/Stubdom.mk.in | 3 - > stubdom/.gitignore | 1 - > stubdom/Makefile | 36 +---- > stubdom/configure | 21 --- > stubdom/configure.ac | 1 - > stubdom/libpci.config.h | 5 - > stubdom/libpci.config.mak | 7 - > stubdom/pciutils.patch | 298 -------------------------------------- > 8 files changed, 6 insertions(+), 366 deletions(-) > delete mode 100644 stubdom/libpci.config.h > delete mode 100644 stubdom/libpci.config.mak > delete mode 100644 stubdom/pciutils.patch > > diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in > index 0d70d03941..b90eaee75a 100644 > --- a/config/Stubdom.mk.in > +++ b/config/Stubdom.mk.in > @@ -14,9 +14,6 @@ STUBDOM_INSTALL := @STUBDOM_INSTALL@ > ZLIB_VERSION := @ZLIB_VERSION@ > ZLIB_URL := @ZLIB_URL@ > > -LIBPCI_VERSION := @LIBPCI_VERSION@ > -LIBPCI_URL := @LIBPCI_URL@ > - > NEWLIB_VERSION := @NEWLIB_VERSION@ > NEWLIB_URL := @NEWLIB_URL@ > > diff --git a/stubdom/.gitignore b/stubdom/.gitignore > index 08f2e9b432..8c6dc00f83 100644 > --- a/stubdom/.gitignore > +++ b/stubdom/.gitignore > @@ -23,7 +23,6 @@ > /mk-headers-* > /newlib-1.* > /newlib-x86* > -/pciutils-* > /pkg-config/* > /polarssl-* > /tpm_emulator-* > diff --git a/stubdom/Makefile b/stubdom/Makefile > index 40b6ececf1..254f8d2fc8 100644 > --- a/stubdom/Makefile > +++ b/stubdom/Makefile > @@ -122,33 +122,10 @@ $(ZLIB_STAMPFILE): zlib-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) > $(MAKE) DESTDIR= libz.a && \ > $(MAKE) DESTDIR= install ) > > -############## > -# Cross-libpci > -############## > - > -pciutils-$(LIBPCI_VERSION).tar.bz2: > - $(FETCHER) $@ $(LIBPCI_URL)/$@ > - > -pciutils-$(XEN_TARGET_ARCH): pciutils-$(LIBPCI_VERSION).tar.bz2 > - tar xjf $< > - mv pciutils-$(LIBPCI_VERSION) $@ > - patch -d $@ -p1 < pciutils.patch > - touch $@ > - > -LIBPCI_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libpci.a > -.PHONY: cross-libpci > -cross-libpci: $(LIBPCI_STAMPFILE) > -$(LIBPCI_STAMPFILE): pciutils-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE) $(ZLIB_STAMPFILE) > - ( cd $< && \ > - cp ../libpci.config.h lib/config.h && \ > - chmod u+w lib/config.h && \ > - echo '#define PCILIB_VERSION "$(LIBPCI_VERSION)"' >> lib/config.h && \ > - ln -sf ../../libpci.config.mak lib/config.mk && \ > - $(MAKE) DESTDIR= CC="$(CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -I$(call realpath,$(MINI_OS)/include)" lib/libpci.a && \ > - $(INSTALL_DATA) lib/libpci.a $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib/ && \ > - $(INSTALL_DIR) $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci && \ > - $(INSTALL_DATA) lib/config.h lib/header.h lib/pci.h lib/types.h $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include/pci/ \ > - ) > +####################################################################### > +# There used to be a slightly modified version of pciutils, this is now > +# available under https://github.com/pciutils/pciutils/pull/236 > +####################################################################### > > ###### > # lwIP > @@ -250,7 +227,7 @@ cross-tpmemu: $(TPMEMU_STAMPFILE) > ####### > > .PHONY: $(CROSS_ROOT) > -$(CROSS_ROOT): cross-newlib cross-zlib cross-libpci > +$(CROSS_ROOT): cross-newlib cross-zlib > > ####### > # libraries under tools/libs > @@ -477,7 +454,7 @@ clean: > crossclean: clean > rm -fr $(CROSS_ROOT) > rm -fr newlib-$(XEN_TARGET_ARCH) > - rm -fr zlib-$(XEN_TARGET_ARCH) pciutils-$(XEN_TARGET_ARCH) > + rm -fr zlib-$(XEN_TARGET_ARCH) > rm -fr libs-$(XEN_TARGET_ARCH) > rm -fr xenstore xenstorepvh > rm -fr gmp-$(XEN_TARGET_ARCH) > @@ -502,7 +479,6 @@ downloadclean: patchclean > rm -f zlib-$(ZLIB_VERSION).tar.gz > rm -f gmp-$(GMP_VERSION).tar.bz2 > rm -f tpm_emulator-$(TPMEMU_VERSION).tar.gz > - rm -f pciutils-$(LIBPCI_VERSION).tar.bz2 > rm -f lwip-$(LWIP_VERSION).tar.gz > rm -f polarssl-$(POLARSSL_VERSION)-gpl.tgz > > diff --git a/stubdom/configure b/stubdom/configure > index 689ff4d6ed..f3d63dceff 100755 > --- a/stubdom/configure > +++ b/stubdom/configure > @@ -634,8 +634,6 @@ LWIP_VERSION > LWIP_URL > NEWLIB_VERSION > NEWLIB_URL > -LIBPCI_VERSION > -LIBPCI_URL > ZLIB_VERSION > ZLIB_URL > INSTALL_DATA > @@ -725,7 +723,6 @@ LDFLAGS > LIBS > CPPFLAGS > ZLIB_URL > -LIBPCI_URL > NEWLIB_URL > LWIP_URL > GMP_URL > @@ -1376,7 +1373,6 @@ Some influential environment variables: > CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if > you have headers in a nonstandard directory > ZLIB_URL Download url for zlib > - LIBPCI_URL Download url for libpci > NEWLIB_URL Download url for newlib > LWIP_URL Download url for lwip > GMP_URL Download url for libgmp > @@ -4038,23 +4034,6 @@ ZLIB_VERSION="1.2.3" > > > > -if test "x$LIBPCI_URL" = "x" > -then : > - > - if test "x$extfiles" = "xy" > -then : > - LIBPCI_URL=\$\(XEN_EXTFILES_URL\) > -else $as_nop > - LIBPCI_URL="https://mirrors.edge.kernel.org/pub/software/utils/pciutils" > -fi > - > -fi > -LIBPCI_VERSION="2.2.9" > - > - > - > - > - > if test "x$NEWLIB_URL" = "x" > then : > > diff --git a/stubdom/configure.ac b/stubdom/configure.ac > index 6ff3ab0ee9..d3d2a840d3 100644 > --- a/stubdom/configure.ac > +++ b/stubdom/configure.ac > @@ -39,7 +39,6 @@ AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake]) > > # Stubdom libraries version and url setup > AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3]) > -AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], [https://mirrors.edge.kernel.org/pub/software/utils/pciutils]) > AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], [https://sourceware.org/ftp/newlib]) > AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], [https://download.savannah.gnu.org/releases/lwip]) > AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [https://gmplib.org/download/gmp/archive]) > diff --git a/stubdom/libpci.config.h b/stubdom/libpci.config.h > deleted file mode 100644 > index 28c2f6ab31..0000000000 > --- a/stubdom/libpci.config.h > +++ /dev/null > @@ -1,5 +0,0 @@ > -#define PCI_OS_MINIOS > -#define PCI_HAVE_STDINT_H > -#define PCI_PATH_IDS_DIR "." > -#define PCI_COMPRESSED_IDS > -#define PCI_IDS "pci.ids.gz" > diff --git a/stubdom/libpci.config.mak b/stubdom/libpci.config.mak > deleted file mode 100644 > index 5c8632cf07..0000000000 > --- a/stubdom/libpci.config.mak > +++ /dev/null > @@ -1,7 +0,0 @@ > -LIBZ=-lz > -LDLIBS+=$(LIBZ) > -PCI_OS_MINIOS=1 > -PCI_HAVE_STDINT_H=1 > -PCI_PATH_IDS_DIR=. > -PCI_COMPRESSED_IDS=1 > -PCI_IDS=pci.ids.gz > diff --git a/stubdom/pciutils.patch b/stubdom/pciutils.patch > deleted file mode 100644 > index 5ab84d6cce..0000000000 > --- a/stubdom/pciutils.patch > +++ /dev/null > @@ -1,298 +0,0 @@ > -diff -urN pciutils-2.2.9.orig/lib/access.c pciutils-2.2.9/lib/access.c > ---- pciutils-2.2.9.orig/lib/access.c 2007-02-06 11:59:43.000000000 +0000 > -+++ pciutils-2.2.9/lib/access.c 2008-06-30 19:07:09.713187000 +0100 > -@@ -57,6 +57,11 @@ > - #else > - NULL, > - #endif > -+#ifdef PCI_OS_MINIOS > -+ &pm_minios, > -+#else > -+ NULL, > -+#endif > - }; > - > - struct pci_access * > ---- pciutils-2.2.9.orig/lib/pci.h 2006-09-09 13:46:06.000000000 +0100 > -+++ pciutils-2.2.9/lib/pci.h 2008-06-30 18:56:15.350111000 +0100 > -@@ -33,6 +33,7 @@ > - PCI_ACCESS_NBSD_LIBPCI, /* NetBSD libpci */ > - PCI_ACCESS_OBSD_DEVICE, /* OpenBSD /dev/pci */ > - PCI_ACCESS_DUMP, /* Dump file (params: filename) */ > -+ PCI_ACCESS_MINIOS, /* MiniOS */ > - PCI_ACCESS_MAX > - }; > - > ---- pciutils-2.2.9.orig/lib/internal.h 2006-09-09 11:52:47.000000000 +0100 > -+++ pciutils-2.2.9/lib/internal.h 2008-07-01 10:46:24.968202000 +0100 > -@@ -37,4 +37,4 @@ > - > - extern struct pci_methods pm_intel_conf1, pm_intel_conf2, pm_linux_proc, > - pm_fbsd_device, pm_aix_device, pm_nbsd_libpci, pm_obsd_device, > -- pm_dump, pm_linux_sysfs; > -+ pm_dump, pm_linux_sysfs, pm_minios; > ---- pciutils-2.2.9.orig/lib/Makefile 2007-10-19 13:41:34.000000000 +0100 > -+++ pciutils-2.2.9/lib/Makefile 2008-07-01 12:13:14.400525000 +0100 > -@@ -46,6 +46,12 @@ > - PCILIB=libpciutils.a > - endif > - > -+ifdef PCI_OS_MINIOS > -+XEN_ROOT=$(CURDIR)/../../.. > -+include $(XEN_ROOT)/Config.mk > -+OBJS += minios.o > -+endif > -+ > - all: $(PCILIB) $(PCILIBPC) > - > - $(PCILIB): $(OBJS) > ---- pciutils-2.2.9.orig/lib/types.h 2009-07-14 18:18:59.000000000 +0200 > -+++ pciutils-2.2.9/lib/types.h 2009-07-14 18:19:16.000000000 +0200 > -@@ -20,10 +20,12 @@ typedef DWORD u32; > - typedef uint8_t u8; > - typedef uint16_t u16; > - typedef uint32_t u32; > -+typedef uint64_t u64; > - #else > - typedef u_int8_t u8; > - typedef u_int16_t u16; > - typedef u_int32_t u32; > -+typedef u_int64_t u64; > - #endif > - > - #ifdef PCI_HAVE_64BIT_ADDRESS > - > ---- pciutils-2.2.9.orig/lib/minios.c 1970-01-01 01:00:00.000000000 +0100 > -+++ pciutils-2.2.9/lib/minios.c 2008-07-01 12:31:40.554260000 +0100 > -@@ -0,0 +1,106 @@ > -+/* > -+ * The PCI Library -- MiniOS PCI frontend access > -+ * > -+ * Samuel Thibault , 2008 > -+ * > -+ * Can be freely distributed and used under the terms of the GNU GPL. > -+ */ > -+ > -+#include > -+#include > -+#include > -+#include "internal.h" > -+ > -+static int > -+minios_detect(struct pci_access *a) > -+{ > -+ return 1; > -+} > -+ > -+static void > -+minios_init(struct pci_access *a) > -+{ > -+} > -+ > -+static void > -+minios_cleanup(struct pci_access *a) > -+{ > -+ shutdown_pcifront(NULL); > -+} > -+ > -+static void > -+minios_scan(struct pci_access *a) > -+{ > -+ void func(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun) > -+ { > -+ struct pci_dev *d = pci_alloc_dev(a); > -+ > -+ d->domain = domain; > -+ d->bus = bus; > -+ d->dev = slot; > -+ d->func = fun; > -+ > -+ pci_link_dev(a, d); > -+ } > -+ > -+ pcifront_scan(NULL, func); > -+} > -+ > -+static int > -+minios_read(struct pci_dev *d, int pos, byte *buf, int len) > -+{ > -+ unsigned int val; > -+ switch (len) { > -+ case 1: > -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) > -+ return 0; > -+ * buf = val; > -+ return 1; > -+ case 2: > -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) > -+ return 0; > -+ *(u16 *) buf = cpu_to_le16((u16) val); > -+ return 1; > -+ case 4: > -+ if (pcifront_conf_read(NULL, d->domain, d->bus, d->dev, d->func, pos, len, &val)) > -+ return 0; > -+ *(u32 *) buf = cpu_to_le32((u32) val); > -+ return 1; > -+ default: > -+ return pci_generic_block_read(d, pos, buf, len); > -+ } > -+} > -+ > -+static int > -+minios_write(struct pci_dev *d, int pos, byte *buf, int len) > -+{ > -+ unsigned int val; > -+ switch (len) { > -+ case 1: > -+ val = * buf; > -+ break; > -+ case 2: > -+ val = le16_to_cpu(*(u16 *) buf); > -+ break; > -+ case 4: > -+ val = le32_to_cpu(*(u32 *) buf); > -+ break; > -+ default: > -+ return pci_generic_block_write(d, pos, buf, len); > -+ } > -+ return !pcifront_conf_write(NULL, d->domain, d->bus, d->dev, d->func, pos, len, val); > -+} > -+ > -+struct pci_methods pm_minios = { > -+ "MiniOS-device", > -+ NULL, /* config */ > -+ minios_detect, > -+ minios_init, > -+ minios_cleanup, > -+ minios_scan, > -+ pci_generic_fill_info, > -+ minios_read, > -+ minios_write, > -+ NULL, /* dev_init */ > -+ NULL /* dev_cleanup */ > -+}; > ---- pciutils-2.2.9/lib/generic.c 2007-02-06 12:00:05.000000000 +0000 > -+++ pciutils-2.2.9-mine/lib/generic.c 2008-07-01 19:13:52.289949000 +0100 > -@@ -74,6 +74,19 @@ > - pci_generic_scan_bus(a, busmap, 0); > - } > - > -+static u32 pci_size(u32 base, u32 maxbase, u32 mask) > -+{ > -+ u32 size = mask & maxbase; > -+ if (!size) > -+ return 0; > -+ size = (size & ~(size-1)) - 1; > -+ > -+ if (base == maxbase && ((base | size) & mask) != mask) > -+ return 0; > -+ > -+ return size + 1; > -+} > -+ > - int > - pci_generic_fill_info(struct pci_dev *d, int flags) > - { > -@@ -114,23 +127,61 @@ > - if (!x || x == (u32) ~0) > - continue; > - if ((x & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) > -- d->base_addr[i] = x; > -- else > -+ { > -+ d->base_addr[i] = x & PCI_BASE_ADDRESS_IO_MASK; > -+ if (flags & PCI_FILL_SIZES) > -+ { > -+ u32 size; > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); > -+ d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_IO_MASK); > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x); > -+ } > -+ } > -+ else > - { > - if ((x & PCI_BASE_ADDRESS_MEM_TYPE_MASK) != PCI_BASE_ADDRESS_MEM_TYPE_64) > -- d->base_addr[i] = x; > -+ { > -+ d->base_addr[i] = x & PCI_BASE_ADDRESS_MEM_MASK; > -+ if (flags & PCI_FILL_SIZES) > -+ { > -+ u32 size; > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); > -+ d->size[i] = pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4); > -+ d->size[i] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), PCI_BASE_ADDRESS_MEM_MASK); > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, x); > -+ } > -+ } > - else if (i >= cnt-1) > - a->warning("%04x:%02x:%02x.%d: Invalid 64-bit address seen for BAR %d.", d->domain, d->bus, d->dev, d->func, i); > - else > - { > - u32 y = pci_read_long(d, PCI_BASE_ADDRESS_0 + (++i)*4); > - #ifdef PCI_HAVE_64BIT_ADDRESS > -- d->base_addr[i-1] = x | (((pciaddr_t) y) << 32); > -+ d->base_addr[i-1] = (x | (((pciaddr_t) y) << 32)) & PCI_BASE_ADDRESS_MEM_MASK; > -+ if (flags & PCI_FILL_SIZES) > -+ { > -+ u32 size; > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0); > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, ~0); > -+ d->size[i-1] = pci_size(y, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4) | > -+ pci_read_long(d, PCI_BASE_ADDRESS_0 + i*4), 0xffffffff ); > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x); > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + i*4, y); > -+ } > - #else > - if (y) > - a->warning("%04x:%02x:%02x.%d 64-bit device address ignored.", d->domain, d->bus, d->dev, d->func); > - else > -- d->base_addr[i-1] = x; > -+ { > -+ d->base_addr[i-1] = x & PCI_BASE_ADDRESS_MEM_MASK; > -+ if (flags & PCI_FILL_SIZES) > -+ { > -+ u32 size; > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, ~0); > -+ d->size[i-1] = pci_size(x, pci_read_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4), PCI_BASE_ADDRESS_MEM_MASK); > -+ pci_write_long(d, PCI_BASE_ADDRESS_0 + (i-1)*4, x); > -+ } > -+ } > - #endif > - } > - } > -@@ -154,10 +205,19 @@ > - { > - u32 u = pci_read_long(d, reg); > - if (u != 0xffffffff) > -- d->rom_base_addr = u; > -+ { > -+ d->rom_base_addr = u; > -+ if (flags & PCI_FILL_SIZES) > -+ { > -+ u32 size; > -+ pci_write_long(d, reg, ~0); > -+ d->rom_size = pci_read_long(d, reg); > -+ pci_write_long(d, reg, u); > -+ } > -+ } > - } > - } > -- return flags & ~PCI_FILL_SIZES; > -+ return flags; > - } > - > - static int > -diff -uNpbE -uNpbEr pciutils-2.2.9.orig/lib/sysdep.h pciutils-2.2.9/lib/sysdep.h > ---- pciutils-2.2.9.orig/lib/sysdep.h 2007-02-06 12:00:18.000000000 +0000 > -+++ pciutils-2.2.9/lib/sysdep.h 2009-07-22 16:26:30.000000000 +0100 > -@@ -32,6 +32,10 @@ typedef u16 word; > - > - #else > - > -+#ifdef PCI_OS_MINIOS > -+#include > -+#endif > -+ > - #ifdef PCI_OS_LINUX > - #include > - #define BYTE_ORDER __BYTE_ORDER > -- > 2.55.0 > -- Samuel Moralité : le modem et le cablerouteur font comme les filles, ils papotent toute la journée. -+- RB in NPC : Et en plus, ils ne parlent que de bits -+- From xen-devel-bounces@lists.xenproject.org Fri Sep 25 06:44:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 06:44:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433420.1654006 (Exim 4.92) (envelope-from ) id 1x9zfW-0008Lq-63; Fri, 25 Sep 2026 06:44:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433420.1654006; Fri, 25 Sep 2026 06:44:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9zfW-0008Li-14; Fri, 25 Sep 2026 06:44:26 +0000 Received: by outflank-mailman (input) for mailman id 1433420; Fri, 25 Sep 2026 06:44:25 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9zfU-0008Lc-NL for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 06:44:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x9zfT-000uh3-9w for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 08:44:23 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab61834-e002-0a2a0a5209dd-0a2a4501e45c-42 for ; Fri, 25 Sep 2026 08:44:23 +0200 Received: from [103.168.172.154] (helo=fhigh-a3-smtp.messagingengine.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab61845-5984-0a2a45010019-67a8ac9aae17-3 for ; Fri, 25 Sep 2026 08:44:22 +0200 Received: from ams-compute-02.internal (ams-compute-02.internal [10.64.2.62]) by mailfhigh.phl.internal (Postfix) with ESMTP id 33DC71400150; Fri, 25 Sep 2026 02:44:20 -0400 (EDT) Received: from ams-imap-03 ([10.64.2.23]) by ams-compute-02.internal (MEProxy); Fri, 25 Sep 2026 02:44:20 -0400 Received: by mailuser.ams.internal (Postfix, from userid 501) id 7288232A0087; Fri, 25 Sep 2026 02:44:14 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=arndb.de header.i="@arndb.de" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To:Message-Id:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Transfer-Encoding:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-Id:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1790318659; x=1790405059; bh=NaZmI7t4xspdCcSwZ61TEkj8dOh5uZ/p24PV+ZMnDZw=; b= Nu0oj7UlIMonbzdFuiOnXEWPF2hJYzyzOAljnTNeALWZYE+crT5NlZVumdUphWuo RZfkszIAbYJ63RItV/vEeOiQ74DLVVtT9yETf+2AJF3Il3Eex3n0xgcWnaeuY6cY 6wAQ652I4qv5mzSSgasKwoKYU+wCzLh52vxBQtMU0A1NGLzTkU08uoOOv1YJHDNS ckaCEp+UHTtrcaBH6hQjxny3jF7C9TpRGj0uTrpkGWUCUr66kKW6kP3H8y7Ud+l1 gwVry7mP+a34dtogloyKtXCbn8Yshbn9oEBHJaRjbb4wzCv636+Ld2fSI4+wZHCL bp3lDOJZ7vw0Y/KnzuS3FQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1790318659; x= 1790405059; bh=NaZmI7t4xspdCcSwZ61TEkj8dOh5uZ/p24PV+ZMnDZw=; b=B gM0Gyvv3PiGDCIXQOHuxl6hJHi3qhgh7HkwPgl/OcTXEjOB3+UqitNM84mISi+iz +ycfiYljhdmWBwO0wKZRXBfXuBfOqTioznIm+HWkfsKX23zU2Sb00pQljzDUbuIr HkCvLt+gVhdFM5OfjBUcWNpyOT7+RVLygdng5266IoTu+8jNHrxCxDIzdsBEBvPw ++iA2YoJUtZuy7QvTTU1Uv+PgEFSueGgJvqQzKnpBprx9voPJ3rNvJQFKBk96l2m O0NqblZtGOUxFcZGNEIVKtIRSuIVTPDsCyZDqC1Ue/3ZAE0DCEy27p98K+Oq1l3t kwmxWfaZ1uuOee0Vrj96Q== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFwSDqkQ+iCgv9bfoZ7OnGDv2/E32uPE8Fd0Y8/G3hqdMfXKGBRJsqwYtMQUVYQrL 6rBdD5WBkmP95rwBjb56UCQmEFVpH1MQeNf2EH79A9tcFirxDEH49FPSDtgesI6qTlZLhS FyGt8jwZs6/BRCK8WQBtj8/8wSniM5z0sAeYIZUw6RfTL0VgIo3U3fygtLYZE95pxCSHFZ WepR8wEVKtPNAYRuRFUV+Y6YLWfdH1/Sqbu3qA9d12FobAwCl+aIFvcISyJveD7NAd69ne nat+mzAMqvQmRT39Um5yv7DBEV4FS8+RYnZbN6r0+WRL47rc70az+oyh1zU2Ychr2GGWJK u2fZydkW07nhk+soJMbSuvqR99kgSdHxX+7M/qJVrV5nxIlqC/RPoPvuKCMjyhYck5Mn+f AdFbaAQW7BZ/q/bJBeQ9EqwX0ccvLKpZIf0UH39rOJ8ygTbhJoyyJz7XCaowgaxqDiq2/t d7BY1jleB6/ow+3+ojRHL8gX24SKUACYZjIQrd7G0Brdt9XWe0nPXJMcfi9IIQWoiFdlP5 UsrXZxRyK7FVGTK3USyOhdqLn7j9uBACH1EQaZAZnz0Wxhmaz8p7Rx9+/rfD741yv1TZ5H xDqojH1YmlZuRqBLUIoKWOM7MzgbFiWpplx5yWj8NVeSv+K0ybsfoQUp/sgQ X-ME-Proxy: Feedback-ID: i56a14606:Fastmail X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: Am_z2EeL-WEB Date: Fri, 25 Sep 2026 08:43:54 +0200 From: "Arnd Bergmann" To: "Dan Carpenter" , oe-kbuild@lists.linux.dev Cc: "kernel test robot" , oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org, "Juergen Gross" , xen-devel@lists.xenproject.org, "Stefano Stabellini" , "Oleksandr Tyshchenko" Message-Id: <94cbe491-1b32-47ec-a9b5-bed69bc4d52c@app.fastmail.com> In-Reply-To: <202609241805.VsLzGPLn-lkp@intel.com> References: <202609241805.VsLzGPLn-lkp@intel.com> Subject: Re: drivers/xen/gntdev.c:817 gntdev_get_page() warn: mask and shift to zero: expr='(addr & ~(~((1 << 12) - 1))) >> 12' Content-Type: text/plain Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d62444/1790318663-1E465757-9313D126/0/0 X-purgate-type: clean X-purgate-size: 1059 On Thu, Sep 24, 2026, at 21:39, Dan Carpenter wrote: > 489 return -EFAULT; > 490 break; > 491 case 2: > 492 if (copy_from_user(&m, udata, sizeof(struct > privcmd_mmapbatch_v2))) > 493 return -EFAULT; > 494 /* Returns per-frame error code in m.err. */ > 495 if (!access_ok(m.err, m.num * (sizeof(*m.err)))) > ^^^^^^^^^^^^^^^^^^^^^^^ > These integer overflow bugs are from 2012, but I guess your patch > exposed > the arm32 build to the zero day bot. The bugs only affect 32bit > systems. Right, the randconfig came up with an ARMv6 Xen build, which was not possible before my patch. I'm sure this was reported for other configs before and just showed up as introduced by my patch here. This is clearly a bug but it does look harmless to me, as it only results in the userspace corrupting itself when passing invalid data. Arnd From xen-devel-bounces@lists.xenproject.org Fri Sep 25 07:43:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 07:43:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433450.1654014 (Exim 4.92) (envelope-from ) id 1xA0Zz-0000je-6S; Fri, 25 Sep 2026 07:42:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433450.1654014; Fri, 25 Sep 2026 07:42:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA0Zz-0000jX-3J; Fri, 25 Sep 2026 07:42:47 +0000 Received: by outflank-mailman (input) for mailman id 1433450; Fri, 25 Sep 2026 07:42:45 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA0Zx-0000jR-4M for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 07:42:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA0Zw-00C1CK-AC for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 09:42:44 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab625f0-e002-0a2a0a5209dd-0a2a4505b3c2-8 for ; Fri, 25 Sep 2026 09:42:44 +0200 Received: from [74.125.225.99] (helo=mail-wr2-f35.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab625f4-4cb1-0a2a45050019-4a7de163b555-3 for ; Fri, 25 Sep 2026 09:42:44 +0200 Received: by mail-wr2-f35.google.com with SMTP id ffacd0b85a97d-4888129c46eso71623f8f.1 for ; Fri, 25 Sep 2026 00:42:44 -0700 (PDT) Received: from localhost ([2c0f:3d00:6be:8900:ce5e:9212:ea4b:f30]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4887a355d96sm5487752f8f.17.2026.09.25.00.42.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Sep 2026 00:42:42 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="In-Reply-To:Content-Disposition:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790322164; x=1790926964; darn=lists.xenproject.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=zWr1PMB3Rc/UXhUDgKdBkp20G3Gj5KQDsYg0EGVPPQM=; b=Gq8KI+HJYmPyhA0AEhws913JPzo7un0XnnScprSSTRA4I7AUbW/4s6wNZNJzpBNwIS xcEDO5sHTLnRl5+N3SK9auf8kt9DZ30PdlqeXlTskKo1YPM3amj092f/MaUXEjA/QihL C9jQf1I2QLUmkOhObXermqnheTwOcc0t/JKoYr8xWtEPCAE9MG4E5B7O+dGgbMn1wKOE 5AkJ9dd02QoRC4KUfofYDbdsIJr1RLF+ge6Zj/lm1DqyeIOhLVMDoEqSYf3wL9Th0YIl QoVq7QRStfs+vKuLoCMPRE8FSILwuxltQpAlRq1Og/YzW3J/XtKKFRsoqJOsw4wGLkow yUxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790322164; x=1790926964; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zWr1PMB3Rc/UXhUDgKdBkp20G3Gj5KQDsYg0EGVPPQM=; b=geJFfk4JQtUibMzDqmhWKQutCvQ+3F6uaJ1t2V+XSaw42ISIU4tdnY25B25ky5bR4G 8FPPmu/YiucDocEKSxlrQj3uqu4NhSwqnkraaG/3QhHXeS6+6qv0zhO/jvj8Uz+YpYL3 7Pesbmi9+24gf8kqHqM/cN9ahmH8G+L3QJ5J+z0BPlTUPVb3WwZ2Egf+SeiDMaEJrvmn tIYkS4GWmgOccz/+PMoBjoPPxh7U8H9IVQakH+rxQDGJ8/UTTembVE/IT/DCEDxG8xeX PVCs3beRQtuH1ivgy0m6waOc33Iu/atjJTzOLLULsAN+Q2HYIjD0CCpBROcS+z/+SGup Jvjw== X-Forwarded-Encrypted: i=1; AKwUvBzE3wutvs2piQcDVbs974a1oJjwZKeaUVWC2eTU8vCobGyogWBOnlw43hYTtIbcTE+DtEn5mTHaQio=@lists.xenproject.org X-Gm-Message-State: AFuF++l6Z7UAnnXkfRb1dPgdVerxES6PPWeKu7HSMiaJCUrClOJtw7nv T/Y9KO54ln2uxX1CKEgGKiPKOgnq/RBfid2zoN0WaeT0ovOpFhR4ZQ1x X-Gm-Gg: AYBFou3lIfQiyK2h5NAMeCgtl/fkg4XN6DASqI7gBuMNLNoklvsqVITNuQqHfHXw8lE pHluCsJZ7MGwxq4gKodGMUvi/CPpGGEsYeUcYjhbU5a4HrQAu1d0hH5y7wbuRePZkpPOvuBFP14 g/lSMUhEhbFpLOsfKpnv33jWK8psTKvBhbqTfHB8xNKHl4DxnC7cuNYVwhHTgorYCOLwEzDZFWz KsxRJnKXs6r9Mju9HQSIo34QFsTQPw6GE671MLWaiDk70LP/TBNw17XXZHQkW3tDbRRpY6JToe3 y+LawZYaLOT+dfoOJ12dBgDOykYlT7lufllB+/jXgE64cq+LvNbvrElYrU4wL4tME/L3RZHgrYQ 5yid258w3a+Eq1/ejUPup6Uq8Usx7GCqs6zIigDVdT9dLHqFrtgTaXElAigKl0Bx2/E0YWoteUQ xaAC33lNXh2K3DDFWUq2Sb/jh3ypOhAZLepXFzBHPeGfNC2D9hmXfLEOlszZezZ27ll34= X-Received: by 2002:a05:6000:4103:b0:488:7496:15b5 with SMTP id ffacd0b85a97d-48874961605mr5882933f8f.47.1790322163538; Fri, 25 Sep 2026 00:42:43 -0700 (PDT) Date: Fri, 25 Sep 2026 10:42:38 +0300 From: Dan Carpenter To: Arnd Bergmann Cc: oe-kbuild@lists.linux.dev, kernel test robot , oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org, Juergen Gross , xen-devel@lists.xenproject.org, Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: drivers/xen/gntdev.c:817 gntdev_get_page() warn: mask and shift to zero: expr='(addr & ~(~((1 << 12) - 1))) >> 12' Message-ID: References: <202609241805.VsLzGPLn-lkp@intel.com> <94cbe491-1b32-47ec-a9b5-bed69bc4d52c@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94cbe491-1b32-47ec-a9b5-bed69bc4d52c@app.fastmail.com> X-purgate-ID: tlsNG-c201ff/1790322164-73CB82A1-939E235D/0/0 X-purgate-type: clean X-purgate-size: 1311 On Fri, Sep 25, 2026 at 08:43:54AM +0200, Arnd Bergmann wrote: > On Thu, Sep 24, 2026, at 21:39, Dan Carpenter wrote: > > > 489 return -EFAULT; > > 490 break; > > 491 case 2: > > 492 if (copy_from_user(&m, udata, sizeof(struct > > privcmd_mmapbatch_v2))) > > 493 return -EFAULT; > > 494 /* Returns per-frame error code in m.err. */ > > 495 if (!access_ok(m.err, m.num * (sizeof(*m.err)))) > > ^^^^^^^^^^^^^^^^^^^^^^^ > > These integer overflow bugs are from 2012, but I guess your patch > > exposed > > the arm32 build to the zero day bot. The bugs only affect 32bit > > systems. > > Right, the randconfig came up with an ARMv6 Xen build, which was not > possible before my patch. I'm sure this was reported for other configs > before and just showed up as introduced by my patch here. > > This is clearly a bug but it does look harmless to me, as it only > results in the userspace corrupting itself when passing invalid > data. In ancient times, these access_ok() overflows were a much bigger deal. Easy to solve with a size_mul(m.num, sizeof(*m.err)). regards, dan carpenter From xen-devel-bounces@lists.xenproject.org Fri Sep 25 08:30:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 08:30:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433494.1654023 (Exim 4.92) (envelope-from ) id 1xA1JS-0007ox-SD; Fri, 25 Sep 2026 08:29:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433494.1654023; Fri, 25 Sep 2026 08:29:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA1JS-0007oq-PD; Fri, 25 Sep 2026 08:29:46 +0000 Received: by outflank-mailman (input) for mailman id 1433494; Fri, 25 Sep 2026 08:29:45 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA1JR-0007ok-Eq for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 08:29:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA1JP-00F2Kr-Ay for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 10:29:43 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab630f2-bab6-0a2a0a5309dd-0a2a4506bbe8-6 for ; Fri, 25 Sep 2026 10:29:43 +0200 Received: from [40.93.196.47] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab630f2-195a-0a2a45060019-285dc42f2919-3 for ; Fri, 25 Sep 2026 10:29:39 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by MN7PR03MB283467.namprd03.prod.outlook.com (2603:10b6:208:5f7::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Fri, 25 Sep 2026 08:29:36 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0451.014; Fri, 25 Sep 2026 08:29:36 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tnJdv7+9z82vnDDlrc/+GjfsOrkPB+S+b73zGLp9pU3Qt9BM2Wiokx4i5aJR3XqX5DhkwqiduwPuWwgAtrEnwH3EnIXnqWSHoABqwQ5WsctXGx5eVi449VwFyft5D/XYYggNutzwh2Te3/eWvnT8DRMMgFBoe2PCAsth2hXhcBhXjCuasmjyJCsHKuC8Z2H9QH16QxzctCoypaxwbTpekO+TQdC5u5t1Vfj0yUyGP9oP1WTe5mb8PbM6qtRVnL8bvNPq2OODJK4Q/N2Ac3vQfSdJjHND9DvDijmSu99MAjKUDF+/CpxWFIIEarvpIPGE5Q76k0GZbpIo8Dy+ClHO+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hs+KudK1TELx7zWGyjdbH52iDjnTZ3b/b7KNxHZuInA=; b=uVnIOf6JF0cfO7Orp8lJ/nHXogy2z++zqtxpZO/AuLeNcq7lx4bGzgQAM88oz3m8U44orrOVDkWyKBy6Pr0WL1askM4uZQvEMv1Wlm7GfUSenaGd9Y+qeFPoXGaxqzKh5THrVRQXY0OMF1Xm6t3HLtZJpjUHb0yIuMexTx8CQoRV0EaA3KqEqxcuOkZHYLtjtfczMZd3nxLH/b3UtDE918UIv6jI7v/rZRdTQYgQxZ3KfxZfb1TiR0qkrxk2SkJxEYCF1fcKW6UgEzqSNSE9m1tTrG0JcxEkRzocgTFaKUZ1hWuwcyTQBsNlNubuSEmWT3RuVoblwqWccwiJyDP14w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hs+KudK1TELx7zWGyjdbH52iDjnTZ3b/b7KNxHZuInA=; b=J2zFesL1VA0tfWMJebJZyakUTCJ/wBxSSdaqN4qALoBPdvaiQwHWWlkHg8q1mCkbBUSPkKTq4E9TLDRnc34ox7lgSgoMKG+VHskp/FpkFdic5BNV3dW+sLP8ihvKxojjtWrGro2SeA/2MvgGp/4RzcfndBrHRHy+mRH0rssVf3w= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 25 Sep 2026 09:29:25 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/3] tools/libxl: Add support for Viridian stimer direct mode To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Juergen Gross References: <20260911091244.1165516-1-ross.lagerwall@citrix.com> <20260911091244.1165516-4-ross.lagerwall@citrix.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <20260911091244.1165516-4-ross.lagerwall@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0222.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:33a::10) To DS0PR03MB8272.namprd03.prod.outlook.com (2603:10b6:8:28f::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|MN7PR03MB283467:EE_ X-MS-Office365-Filtering-Correlation-Id: a51b1a7b-3e91-4e06-fb2f-08df1adf21b0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|23010399003|6133799003|10067099003|56012099006|4143699003|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: IRUvS7ENp7tuILXdq7X8Oy6grecr696SDU2ugsm5Cr4DeDCayxrN/aEGUmRFLIijmkv8b3T7s09Q8apL0wlxb/aEQDtAec0Wf8OzhLR9jzm2ZC0GZ4R15RNGAWcGXpP90h/5/DUjP91q3MLeexZoR6vYeS6GLkI+o3z/ulnw+7SmikUZ9WAP4KJYXAmJa9xcSDWNnut2q8yIdsJ+1pQKQbdCtZOzZJK+gjgRuEKf7UO7GhahKXumW28L4NwiQtntue9avrfU+9W+4/nI2lrl5HQ+/5Lf0ez0x1+ChJnJCwOqnibui4AAwx61r8RVKutCGM9MzXHhF0jQni2xOd1N429GBSrO+vQJEdwpkZRmp7+K5HBgz/nzDp+n4FuM17jwAL3nREV32+Evn8AV4uuk0+KSLXDqwkXLSYSymhK1SKB63fR31sE1Ll9Bn95Xw2hHgbFCn8WYVPGvQ8vqebLBHgYfL8aQwd0iXh/Ekbr6FPnc0T2w0cA7aqn0BNkcuwZRnwsmHK8ogqUV1ZqfgxfgHr5QVPX8uEXeEnxbm1id0R76cE/hgRZbbLPPuSy1bf6qW27BVZcsGsf0bNAJEb/dBbSd3t8fhEKqAb0lfPFbytv9bXh6KCM2hV4XKqnFPRLPSsiNqQh+jHuw1ftDqqoMyeesizgqopVKaK1acQa2fjQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(23010399003)(6133799003)(10067099003)(56012099006)(4143699003)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TkFVQTBKdS9FMUFGZVRGSUF1c1JmeHZmb24xdGo1clZiVzFrcWpER0dBeXNW?= =?utf-8?B?cVdTS2hZWnR1WnFqVEc3NDNmQ281SndLdnRFRVR5SVpmamVHTE5RMlo1Ym43?= =?utf-8?B?QXlQMTJtVmZlb1NHVFMxQ0F3MmxxUUNFOTE3NzhEQWQ3ajhHd2N0TFV3ZDBr?= =?utf-8?B?V2EzSnFrRXg1eTlSYkd2Sjl4aG1BK1Z1K1hnVmlyY2JnWGVnNWFmengxSlho?= =?utf-8?B?dmdZTEcxTlJ4KzUrejlCR0VEMWdaMWVQdFM5d0I0UnpoVFFKNGdTQlZVQndp?= =?utf-8?B?WFBoeFNUaEZ3eVV1Nm1pd3lIT3BWbGd6T3ZlOVNRaEwzU0IvRG1ZRlRDV2V5?= =?utf-8?B?RDBRNDdFM0xvcTJmRVBjak1vNFZYejNpcmd0NjNzVzMrT2U1bzA1R1pBdmFx?= =?utf-8?B?NHlVaDYvNVlZUktCcmIyRkwxYWhBTWgxUHJRS0tzZURwL01nYmZ5TFNGUXRy?= =?utf-8?B?OHBLdE9QdmhYTjRVNk55Skw5RTFrcVQySEtrM3pYbHQrczFwQUprWk1lMFp3?= =?utf-8?B?STBQa3JkV0Y0c0wwMDNqS2t1SGVxeDQ4QkFsQWdoSkdyQ0R5RDVrVlFJdHNk?= =?utf-8?B?TzhkVnVwQklrK1p5S0RZcE1TQnJCSWNzVnhqTDIyYmhTbXhIbWJHdmR5Q0k0?= =?utf-8?B?dEVVbTYxNlU1NTBkTEZYc05ZUFZYRFZKQmN3ZFQybWNLT0F6amFDM25OM3h5?= =?utf-8?B?ZVdUR3NrcjZIeC8yRTdQRVcwbi9SdGhyMjU0UHNHYnZVbERTRDdRaDhveHJH?= =?utf-8?B?cGdLMFBJc2VYSEdlRTUwMmF2dC9ERzN2bnZRWTM4dGs3S3N5MW9kWUpEbVNp?= =?utf-8?B?UFpSdm9sOU9POEkrTk8rcWVYQXVXQi9UUm5HbzhqdVdmKzAvSndRcVhWbDQ1?= =?utf-8?B?djlOZEZtQWJrOGhFa2V6WEhwZGRCcGk4bTE5MmtqLzYzTkR2UU9KZlE4a29B?= =?utf-8?B?RHhDcnFudk4vTjlaQkt6QzZsNCs3U1YzdHhuM2pGcWgxY25EQnpZM2lzUmIv?= =?utf-8?B?S0lrUDExVzRlaURpb3ZSNHBMYkx6NWJBdnJkeUtGK2VBc3BwcUF5TDlFM3Zn?= =?utf-8?B?WWU0Y2JQMkFKeG1idkkrenRYTWtDZVlucDBMdUpVOVo3UmVydXRkeVpGSnFL?= =?utf-8?B?UHlWdlpjUkk4eHFzMTYwK3NDeUl2am83YXZLSStzQVRvREFZQnk2RjRNTzRr?= =?utf-8?B?aU1LOWpDcXEwZjNOVWNyVi9pKzJiWkdKeVdqZGhOTFJXTmRWbFlUbFJJSFlo?= =?utf-8?B?ZndHVzVYTTNkNDBYcmlTSVJHVDB0MW5YMzE4TzBwUDJIZ0xjNFRiTUNTenRm?= =?utf-8?B?cTFTUjc2eDRGdVlwM041c0p6MHA5dWlXc2xZaDM1ZXQ2aE00UlUxejh1bUp5?= =?utf-8?B?aXRKVCtWZ1JMNng3NUNTeVN3WnJuOElmSE9zNFhmaHA5ZEtBcFpxUk5iQS82?= =?utf-8?B?aXlrQnhHY3FlTi92UjZQOXJDMmNncEt5VFp2WUg1S1R4ZUVXZVU0QXRYaE1X?= =?utf-8?B?N3RQRVQvTVJzZ3cxeFZPL2ZGUjFaYlhNdVhKUWF3L2xYRGFLRDhseVp2T3Fh?= =?utf-8?B?d0NscGsxbzBoMytVMTV4TzhGN3paSmlCOHdVWkN2T1pZbUgrdEtrU0h0WUp0?= =?utf-8?B?ZXo3MWovZ1R1UjYxUmZzdEo0TjhwbDlBU09xQUVBbnBzdXNaYzVxcjZhdk5U?= =?utf-8?B?Ukx2UnU3U051SE44Y0J4OXdkNWtONUdUeGc3dDFpbEI2a0xnUUJGREV2cTlx?= =?utf-8?B?N1lWaUVkU25wUTYrejMrWWtNd2x3dkRuaFdqZUkxWUhRWGgvTDhFSEZtaEpF?= =?utf-8?B?L1lpMWN3YkVCUzNnMHZQWUliVlRmU1YwZmVKRHJxNjhMYnVtT3E5ZFNZWHBG?= =?utf-8?B?TjlGcG1oeGQ2LzJxdkN4VitLYkR3THE4N2RHd3NBZVpITDk1L1RzeW5LM2lU?= =?utf-8?B?VHFyekZnYUlwYnR4YmZPZVFER2RuVERDc0dnZm9JcVdvMFJVZ1pQaFN0ejJW?= =?utf-8?B?SFV5UndTYWxtOEtsaG12S3NpK3lZZmEweGN1UVRWb1BTU1lkSGFuRm00MjBn?= =?utf-8?B?MHVmcUE1eDIzb3dtSmFMSVF2aThrdWxSZnlYK1ZQSERNdFIwamozV2RxU3la?= =?utf-8?B?OWRVOWZGUHhrTFE1bzRyQ2lMdXYyTmVtRUJiRmFSRHh0VDhaZURQM0ZkVjd2?= =?utf-8?B?UXYwSDNETVUvVm9ETmpXSFhjaUFIUk9jN0lpQ2orM3Nha0JKZk9mMmdYdVhD?= =?utf-8?B?a3A1M25RZ1c4SlkzZ0k5RTFBMnNObkxmTmZXUnFUZXcwZkdvc1lLZUlubVlh?= =?utf-8?B?Q3l6K0dTcXFsaDE0WXI1M1lPUVk4SFBZbXhpSGJzb2puRk51OHFkU3JBTUFO?= =?utf-8?Q?aXygV9Z/WECfYBS4=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a51b1a7b-3e91-4e06-fb2f-08df1adf21b0 X-MS-Exchange-CrossTenant-AuthSource: DS0PR03MB8272.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 08:29:35.9028 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vzDo+p9KucWsZB9OumjGQ8/98mE2o+EU4XFPTLxTvyqlVdMbkSVd8rTARZuAlWCOv3icT2m1su/e4IT6z15Qn9FeJy8V/n68hUJ2rSeI3CM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN7PR03MB283467 X-purgate-ID: tlsNG-16d1c6/1790324979-1F6C877B-59AB040D/0/0 X-purgate-type: clean X-purgate-size: 3051 On 9/11/26 10:12 AM, Ross Lagerwall wrote: > Add support to libxl for using the stimer enlightenments in direct mode. > > Signed-off-by: Ross Lagerwall > --- > > In v3: Fix typo in docs > > docs/man/xl.cfg.5.pod.in | 5 +++++ > tools/include/libxl.h | 6 ++++++ > tools/libs/light/libxl_types.idl | 1 + > tools/libs/light/libxl_x86.c | 5 +++++ > 4 files changed, 17 insertions(+) > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index d34951edb98d..30c401588fef 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -2496,6 +2496,11 @@ ticks and hence enabling this group will ensure that ticks will be > consistent with use of an enlightened time source (B or > B). > > +=item B > + > +This set is the same as the B set but additionally supports > +using synthetic timers in direct mode. > + > =item B > > This set incorporates use of a hypercall for interprocessor interrupts. > diff --git a/tools/include/libxl.h b/tools/include/libxl.h > index 7c098edab663..5475530a5002 100644 > --- a/tools/include/libxl.h > +++ b/tools/include/libxl.h > @@ -381,6 +381,12 @@ > */ > #define LIBXL_HAVE_VIRIDIAN_HCALL_IPI 1 > > +/* > + * LIBXL_HAVE_VIRIDIAN_STIMER_DIRECT indicates that the 'stimer_direct' value > + * is present in the viridian enlightenment enumeration. > + */ > +#define LIBXL_HAVE_VIRIDIAN_STIMER_DIRECT 1 > + > /* > * LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that > * libxl_domain_build_info has the u.hvm.acpi_laptop_slate field. > diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl > index a7893460f013..95075f04fe45 100644 > --- a/tools/libs/light/libxl_types.idl > +++ b/tools/libs/light/libxl_types.idl > @@ -260,6 +260,7 @@ libxl_viridian_enlightenment = Enumeration("viridian_enlightenment", [ > (10, "ex_processor_masks"), > (11, "no_vp_limit"), > (12, "cpu_hotplug"), > + (13, "stimer_direct"), > ]) > > libxl_hdtype = Enumeration("hdtype", [ > diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c > index 60d4e8661c93..9e8b48372d63 100644 > --- a/tools/libs/light/libxl_x86.c > +++ b/tools/libs/light/libxl_x86.c > @@ -389,6 +389,11 @@ static int hvm_set_viridian_features(libxl__gc *gc, uint32_t domid, > if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_CPU_HOTPLUG)) > mask |= HVMPV_cpu_hotplug; > > + if (libxl_bitmap_test(&enlightenments, > + LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER_DIRECT)) > + mask |= HVMPV_time_ref_count | HVMPV_synic | HVMPV_stimer | > + HVMPV_stimer_direct; > + > if (mask != 0 && > xc_hvm_param_set(CTX->xch, > domid, Ping. Note that the Xen side of this has already been committed. Thanks, Ross From xen-devel-bounces@lists.xenproject.org Fri Sep 25 09:13:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 09:13:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433535.1654032 (Exim 4.92) (envelope-from ) id 1xA1zq-0006mP-W7; Fri, 25 Sep 2026 09:13:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433535.1654032; Fri, 25 Sep 2026 09:13:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA1zq-0006mH-Sk; Fri, 25 Sep 2026 09:13:34 +0000 Received: by outflank-mailman (input) for mailman id 1433535; Fri, 25 Sep 2026 09:13:33 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA1zp-0006mB-58 for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 09:13:33 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA1zm-001NuL-Jr for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:13:30 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab63b2e-bab6-0a2a0a5309dd-0a2a45069658-20 for ; Fri, 25 Sep 2026 11:13:30 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab63b3a-195a-0a2a45060019-4a7de18ddfe2-3 for ; Fri, 25 Sep 2026 11:13:30 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49ccff31419so6216135e9.3 for ; Fri, 25 Sep 2026 02:13:30 -0700 (PDT) Received: from [192.168.1.109] ([88.230.46.165]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ff21c38a4sm18941345e9.2.2026.09.25.02.13.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Sep 2026 02:13:29 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790327610; x=1790932410; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=NXXdFDFau2Czj+WwbE2oq5QWYgBVXR49RaMBkVsNBCA=; b=JCbaPJmDiBN+rZ6P1I+QJWRppHkak3lzDpd0sFWEWGv3QKsrPx7E4z8MZVrnDFfHVw 8F4lNilQGmDrpO6SQz6XVaFPft2phVU20fv3leOdKjetLQ/yvs4fRwZOID9lLVKZkI0c h26mEx0zfI5DUW25zXjoUgD0hytCKY3AhqBE7u13rbUTfen7/VldVHtHAlMqqGkn6OHZ 48C1ahUO18s3bbcP96aDbxKBH6fNYoCX4c/AZ/2wRZfI9n1bhEb+CDRTE3OVL50Dq6FB UNMRR0tSw4SH9N33m4zHOPYLEIR9kz5JKNFefkkKt+pu/3KYcrDNRbbAx4DPUOHTVipV gmHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790327610; x=1790932410; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=NXXdFDFau2Czj+WwbE2oq5QWYgBVXR49RaMBkVsNBCA=; b=B8MLoRZ++2kLnVutinFAghV/zm06xUeiNDMDZbz22bLCzle5ATRegeBcOc7rQ3zyRL DK+n4mfuPzvfTm2pwMQUuIDtagZ/oKURaOwAFmPhiUKksEvUjIpVe0iwpnpY9k6F3ZfO Rol18rHytkpIaGcefSob7k95iyUUcJom1lhST6vcJXtY+mJIvlF0x6TuFD3wy7TpMheq u5ec3ep1pQ8ySRX0BiYXwAHB5CWDK/rTfbE7QqrqX6mzYSu7cNEUCkTKZ4GCUBaRxAbq MWrF5U+1Tp2eRmz1ynhAYupoZbFVj1a4sJx5X+OOhWnusMsdW9nuDKYbxP3lOYZM28gX cOqw== X-Forwarded-Encrypted: i=1; AKwUvBw1E8SZ1QwfkK5Hg2LDasWHg4wvCF/VRLrrBnbrqbc2he7Sts+Fcm9hQBpYcY1Kn6q0rDEEg6YrCDU=@lists.xenproject.org X-Gm-Message-State: AFuF++nWAwRpsjoZ+1DWiOHkJ3mLEz5es7V1Hi4OGAwqY1iQ7m6onNE+ lkmlUartgaNMNR+2v0iwhxTUYq4cX52iCGVxh90AUVlpPguaqAWPrqjw X-Gm-Gg: AYBFou3ye3NZP/Yc5T1RR/VJYTVVYeek6qXWhQ6AUa3XVzNeWQRKjQOS7gt8I179m48 FXWDA4HBzySecciTSkxiHMYLWL0tflMUWYPA7fkcAJxEloMNzmvDrZxSz+LxgKLvAG1DWpqiHCo 3XGgsUrFEYSRZpzyAratT/G1qO6VrSxltb5j397YVM4iHd0HSWlj5jOSzwx62iiFtsAa4KMlpmD w/CwX8X8d+3gsB1bPX91weCeo6F+nHwfkLveqfHotyUgAuwBTAgEABPXTuP3z2ObK28XSogfSQj rtFldtTI+9cQu0MgHwPFRCY/SafyrM1cIX2ejGNncWI+7pRLAG41ZOie9mW9JpmShFUvIPAHPoq +j0/5Mv77YuAYcIrt1i85P7slVsAozj16MLqWBCDO7mDQujBstuckqFjBZfT+yA22bvrrJ2N2gu LqtzPEg1PeKZPJWFY1J3N8MsBnwBsZ2MqCEQ99REl/JVHZB65LByDislRbKK3FPyz26lT/fwDl2 NiD X-Received: by 2002:a05:600c:46d1:b0:49c:cee0:f383 with SMTP id 5b1f17b1804b1-49fe7bab928mr75133995e9.16.1790327609844; Fri, 25 Sep 2026 02:13:29 -0700 (PDT) Message-ID: Date: Fri, 25 Sep 2026 12:13:23 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2.1 5/5] tools: expose admission control toggle via xl sched-rtds To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, anthony.perard@vates.tech References: <20260918080935.35498-6-frn1furkan10@gmail.com> <20260918104106.53530-1-frn1furkan10@gmail.com> Content-Language: en-US From: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-16d1c6/1790327610-F480577B-4E6587A0/0/0 X-purgate-type: clean X-purgate-size: 765 On 9/18/26 13:45, Jürgen Groß wrote: > On 18.09.26 12:41, Furkan Caliskan wrote: >> Wire the per-cpupool admission-control switch through libxl >> to xl sched-rtds, and document it. >> >> Add -s/--schedparam to list or set pool-wide RTDS scheduler >> parameters, and -a/--admission to enable or disable admission >> control for a cpupool ("-c pool -s -a 0/1"). >> >> Signed-off-by: Furkan Caliskan > > Reviewed-by: Juergen Gross > > > Juergen Hi Jan, Just noticed that patches 1-4 have been merged, but patch 5 (which already has a Reviewed-by from Juergen) doesn't seem to have made it in. Could you let me know if it needs anything further, or if it just got missed? Thanks, Furkan From xen-devel-bounces@lists.xenproject.org Fri Sep 25 09:21:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 09:21:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433547.1654042 (Exim 4.92) (envelope-from ) id 1xA27Q-00008d-P4; Fri, 25 Sep 2026 09:21:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433547.1654042; Fri, 25 Sep 2026 09:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA27Q-00008W-MX; Fri, 25 Sep 2026 09:21:24 +0000 Received: by outflank-mailman (input) for mailman id 1433547; Fri, 25 Sep 2026 09:21:23 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA27P-000079-95 for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 09:21:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA27O-00HFBh-ML for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:21:22 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab63d12-8faa-0a2a0a5109dd-0a2a450c9272-2 for ; Fri, 25 Sep 2026 11:21:22 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab63d11-f479-0a2a450c0019-a06583089efa-3 for ; Fri, 25 Sep 2026 11:21:22 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 3754E4717F7B; Fri, 25 Sep 2026 05:19:17 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Abdelkareem Abdelsaamad To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, Abdelkareem Abdelsaamad , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v5] x86/nSVM: Check injected event consistency Date: Fri, 25 Sep 2026 10:15:30 +0100 Message-ID: <216f0de990dd180c8336837e86bf5860e37b9c50.1790326132.git.abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1790328082-5113AA5B-6D65903D/0/0 X-purgate-type: clean X-purgate-size: 16003 On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has debugging complications, security and performance implications. The APM volume #2 15.20 (40332—Rev. 4.10—July 2026) states the two possibilities that VMRUN will immediately exit with VMEXIT_INVALID due to the injected event. These are • Reserved values of TYPE have been specified. • TYPE = 3 (exception) has been specified with a vector that does not correspond to an exception (this includes vector 2, which is an NMI, not an exception). Furthermore, reading through the APM shows that the exception vector validity can also depend on the guest mode, the CPU generation and the microarchitectural constraints. Some vectors are only valid starting with the specific CPU generation that introduced the corresponding feature, the guest mode or whether the guest opted-in for specific CPU capability. The Upstream KVM introduced a similar consistency check that reflects on this dependency with the commit 7e79f71bca5c ("KVM: nSVM: Add missing consistency check for EVENTINJ"). However, the KVM implementation did allow the Overflow (X86_EXC_OF) and the BOUND Range (X86_EXC_BR) vectors injection in 64-bit mode. According to the APM Volume #2 and Volume #3 (40332—Rev. 4.10—July 2026), injecting these exceptions while the guest is in 64-bit mode is invalid and triggers an immediate VMEXIT_INVALID. This architectural mismatch in the KVM implementation was reported here: https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/ To verify the hardware behaviour with the various vectors, A case-by-case testing on 64-bit mode Windows guest is performed. The hardware exception event is manually injected at the end of svm_vmexit_handler and the consequence is observed: - If VMEXIT_INVALID is triggered, the injection is invalid. - If a guest triple fault is triggered, the event passed the hardware checks and completed the event delivery. It is valid. Extend the VMCB validation to check for the VMCB event injection inconsistency. While at it, extend the svm_vmcb_isvalid usage to the non-nested VMEXIT_INVALID debugging. Clean up svm_vmcb_isvalid by dropping the unused `verbose` parameter and by correcting the misleading boolean return value to properly reflect the validation status. Signed-off-by: Abdelkareem Abdelsaamad --- Changes in v5: - Drop the rejection of injected events when the VALID bit is not set. The testing confirms no VMEXIT_INVALID is triggired in such case. - Reject the X86_EXC_BP (#BP) and the X86_EXC_OF (#OF) exception vectors when injected into SEV-ES guests to respect architectural constraints. - Reject X86_EXC_VC (#VC) event injection entirely, as testing confirms manual injection of the VMM Communication exception unconditionally triggers a VMEXIT_INVALID. - Separate X86_EXC_HV (#HV) into its own explicit case block with a dedicated architectural comment. - Extend the use of svm_vmcb_isvalid() to non-nested VMEXIT_INVALID debugging to improve error diagnostics, and clean up the internal logic of the function. - Promote the vmcb_injected_type and the vmcb_injected_vector to unsigned int type. - Add an inline comment explaining the purpose and architectural backing of the new vmcb_valid_event_inj_types_mask. Changes in v4: - Reject the injected events with the valid bit not set. - Fix the APM revision details. - Rename the is_valid_svm_vmcb_injected_exception_vector to the shorter is_valid_injected_exception_vector. - Address coding style comments regarding !! operator usage for boolean returns, concise debug messaging for reserved vectors, and blank lines between non-fall-through case blocks. - Drop the X86_EXC_HV from the permitted vectors. Changes in v3: - Restricted X86_EXC_OF (4) and X86_EXC_BR (5) vector injections to non-64-bit guests to prevent impossible guest-mode state injections per AMD APM Volumes 2 & 3. - Refactored exception vector validation from if-conditions to a switch statement to improve readability and extensibility. - Restricted X86_EXC_CP (21) vector injection to guests with enabled CET to prevent VMRUN failures on hardware without CET support. Changes in v2: - Remove the redundant SVM_EVENT_INJ_TYPE_MASK and SVM_EVENT_INJ_VEC_MASK constants. - Correct the Injected Event Type consistency check to disallow the injection of reserved type 1 events. --- Testing: - Using a locally developed XTF nested virt setup, I manually tested VMRUN instruction handling with a malformed VMCB: 1) Inject event with the type (7). The hypervisor logs show the message (XEN) [ 645.155609] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid Injected Event Type: 0x7. 2) Inject event with the exception value (3) and the vector value (2) for NMI. The hypervisor logs show the message (XEN) [ 645.157277] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid exception type: 0x3 vector: 0x2. 3) Inject event with the exception value (3) and the vector value (21) for the X86_EXC_CP (Control-Flow Protection). Without the changes included: On the Naples host, where the vector was not yet known to the hardware. VMRUN immediately triggers VMEXIT_INVALID. 4) To perform more detailed bare-metal testing, I set up a testing matrix using a XenServer Windows 10 64-bit VM and manually injected the various events according to the testing matrix below: ---------------------------------------------------------------------------------------------------------- | Exception Vector | AMD Naples | AMD Genoa | Testing Conditions | |--------------------------|-------------------------|--------------------------|--------------------------| | - X86_EXC_OF | VMEXIT_INVALID | VMEXIT_INVALID | - Verified that 64bit | | - X86_EXC_BR | | | mode is active before | | | | | injecting the event. | |--------------------------|-------------------------|--------------------------|--------------------------| | | | | - Verified that the | | | | | Genoa host does not have | | - X86_EXC_CP | Guest Triple fault | VMEXIT_INVALID | guest_cr[4] X86_CR4_CET | | | | | set and the VMCB does not| | | | | have CR4 X86_CR4_CET set | |--------------------------|-------------------------|--------------------------|--------------------------| | | | | - APM states only valid | | - X86_EXC_HV | VMEXIT_INVALID | VMEXIT_INVALID | to inject into VMSAs that| | | | | execute with Restricted | | | | | Injection. | |--------------------------|-------------------------|--------------------------|--------------------------| | - X86_EXC_DE | | | - Verified that hosts | | - X86_EXC_DB | | | do not have guest_cr[4] | | - X86_EXC_UD | | | X86_CR4_OSXMMEXCPT set | | - X86_EXC_BP | | | and the VMCB does not | | - X86_EXC_NM | | | have CR4 | | - X86_EXC_DF | | | X86_CR4_OSXMMEXCPT set | | - X86_EXC_TS | Guest Triple fault | Guest Triple fault | with the vector | | - X86_EXC_NP | | | X86_EXC_XM. | | - X86_EXC_SX | | | with the vector | | | | | X86_EXC_MC. | |--------------------------|-------------------------|--------------------------|--------------------------| | - X86_EXC_CSO | | | | | - X86_EXC_SPV | | | | | - X86_EXC_VE | VMEXIT_INVALID | VMEXIT_INVALID | | | - X86_EXC_VC | | | | ---------------------------------------------------------------------------------------------------------- - CI tests: https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2881691847 --- xen/arch/x86/hvm/svm/nestedsvm.c | 8 +-- xen/arch/x86/hvm/svm/svm.c | 1 + xen/arch/x86/hvm/svm/vmcb.c | 90 ++++++++++++++++++++++++++++++-- xen/arch/x86/hvm/svm/vmcb.h | 2 +- 4 files changed, 91 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 81579370b8..bb3511622d 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -595,15 +595,15 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) /* Cleanbits */ n2vmcb->cleanbits.raw = 0; - rc = svm_vmcb_isvalid(__func__, ns_vmcb, v, true); - if ( rc ) + rc = svm_vmcb_isvalid(__func__, ns_vmcb, v); + if ( !rc ) { gdprintk(XENLOG_ERR, "virtual vmcb invalid\n"); return NSVM_ERROR_VVMCB; } - rc = svm_vmcb_isvalid(__func__, n2vmcb, v, true); - if ( rc ) + rc = svm_vmcb_isvalid(__func__, n2vmcb, v); + if ( !rc ) { gdprintk(XENLOG_ERR, "n2vmcb invalid\n"); return NSVM_ERROR_VMENTRY; diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 71e48351f2..ebdeb95dbf 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2619,6 +2619,7 @@ void asmlinkage svm_vmexit_handler(void) if ( unlikely(exit_reason == VMEXIT_INVALID) ) { + svm_vmcb_isvalid(__func__, vmcb, v); gdprintk(XENLOG_ERR, "invalid VMCB state:\n"); svm_vmcb_dump(__func__, vmcb); domain_crash(v->domain); diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index a6f09672a7..50bec50fc5 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -327,20 +327,91 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) svm_dump_sel(" TR", &vmcb->tr); } +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, + uint8_t vmcb_injected_vector, const struct vcpu *v) +{ + switch ( vmcb_injected_vector ) + { + case X86_EXC_DE: + case X86_EXC_DB: + case X86_EXC_UD: + case X86_EXC_NM: + case X86_EXC_DF: + case X86_EXC_TS: + case X86_EXC_NP: + case X86_EXC_SS: + case X86_EXC_GP: + case X86_EXC_PF: + case X86_EXC_MF: + case X86_EXC_AC: + case X86_EXC_MC: + case X86_EXC_XM: + case X86_EXC_SX: + return true; + + /* + * Exception vectors 3 and 4 may not be injected into SEV-ES guests. + * If this is attempted, the VMRUN will fail with a VMEXIT_INVALID + * error code. + * See the APM Volume #2 15.35.8 (40332—Rev. 4.10—July 2026). + */ + case X86_EXC_BP: + return !vmcb_get_sev_es(vmcb); + + /* + * If the VMM attempts to inject an event that is impossible for the + * guest mode (e.g., a #BR exception when the guest is in 64-bit mode), + * the event injection will fail... VMRUN will immediately exit with + * VMEXIT_INVALID. + * See the APM Volume #2 15.20 (40332—Rev. 4.10—July 2026). + */ + case X86_EXC_OF: + return ( (!(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l) && + !vmcb_get_sev_es(vmcb) ); + + case X86_EXC_BR: + return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l; + + case X86_EXC_CP: + { + unsigned long guest_valid_cr4 = hvm_cr4_guest_valid_bits(v->domain); + return guest_valid_cr4 & X86_CR4_CET; + } + + /* + * X86_EXC_HV vector is reserved for SNP guests use. Only allowed to be + * injected into VMSAs that execute with Restricted Injection. + * See the APM Volume #2 15.36 (40332—Rev. 4.10—July 2026). + */ + case X86_EXC_HV: + default: + return false; + } +} + bool svm_vmcb_isvalid( - const char *from, const struct vmcb_struct *vmcb, const struct vcpu *v, - bool verbose) + const char *from, const struct vmcb_struct *vmcb, const struct vcpu *v) { - bool ret = false; /* ok */ + bool ret = true; /* ok */ unsigned long cr0 = vmcb_get_cr0(vmcb); unsigned long cr3 = vmcb_get_cr3(vmcb); unsigned long cr4 = vmcb_get_cr4(vmcb); unsigned long valid; uint64_t efer = vmcb_get_efer(vmcb); + unsigned int vmcb_injected_type = vmcb->event_inj.type; + unsigned int vmcb_injected_vector = vmcb->event_inj.vector; + /* + * Represent the nonreserved and accoridngly valid guest exception or + * interrupt type. + * See the APM Volume #2 15.20 (40332—Rev. 4.10—July 2026). + */ + unsigned long vmcb_valid_event_inj_types_mask = (1 << X86_ET_INTR) | + (1 << X86_ET_NMI) | + (1 << X86_ET_HW_EXC) | + (1 << X86_ET_SW_INT); #define PRINTF(fmt, args...) do { \ - if ( !verbose ) return true; \ - ret = true; \ + ret = false; \ printk(XENLOG_GUEST "%pv[%s]: " fmt, v, from, ## args); \ } while (0) @@ -399,6 +470,15 @@ bool svm_vmcb_isvalid( PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n", vmcb->event_inj.raw); + if ( !((1ul << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) ) + PRINTF("eventinj: Invalid Injected Event Type: %#x\n", + vmcb_injected_type); + + if ( (vmcb_injected_type == X86_ET_HW_EXC) && + !is_valid_injected_exception_vector(vmcb, vmcb_injected_vector, v) ) + PRINTF("eventinj: Invalid exception type: %#x vector: %#x\n", + vmcb_injected_type, vmcb_injected_vector); + #undef PRINTF return ret; } diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index 3760f71a86..78ace19b27 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -565,7 +565,7 @@ void svm_destroy_vmcb(struct vcpu *v); void setup_vmcb_dump(void); void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb); bool svm_vmcb_isvalid(const char *from, const struct vmcb_struct *vmcb, - const struct vcpu *v, bool verbose); + const struct vcpu *v); /* * VMCB accessor functions. -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 25 09:22:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 09:22:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433557.1654052 (Exim 4.92) (envelope-from ) id 1xA28Q-0000bj-2p; Fri, 25 Sep 2026 09:22:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433557.1654052; Fri, 25 Sep 2026 09:22:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA28P-0000bb-V2; Fri, 25 Sep 2026 09:22:25 +0000 Received: by outflank-mailman (input) for mailman id 1433557; Fri, 25 Sep 2026 09:22:24 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xA28N-0000bS-SY for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 09:22:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA28N-002HFj-4J for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:22:23 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab63d45-e002-0a2a0a5209dd-0a2a45078186-44 for ; Fri, 25 Sep 2026 11:22:22 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab63d4e-b4ea-0a2a45070019-b9ff1c23a851-3 for ; Fri, 25 Sep 2026 11:22:22 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d7df70c000072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 25 Sep 2026 09:22:19 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id AF777823F1; Fri, 25 Sep 2026 11:22:17 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=QHPOElREch3bYfWmG37dlv+FoSXbV4m95OGl/iOUKBM=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=UJy8hmDMML7yWjxReCBIXrlZB9/Zp6IfkXKUDwVArIaH/zfR8DFj3r3aNJOeT2eCK5taiT2Zz xcjQNTZ+pY2ZDH/dkA3C/GlZ1F1l5iY36Yg08ZhK10DG/zrmS4I6JO5pcF7QVDWX8uEYes5uAJv BcPXJJd9SgNgrHfRv1UWIlHpAp1I10afu3/07w6hfReGIEfeaBruuGjzENJxq/SdgjfFoQErSZ9 RSKstCCEdgHahtTE95yypVxiLDH/LrBvz/Zi/V7V+kMlSTeUVEJBCyi3wKdXPyYl9hooQ9a+jgj t840dUjDes5QrXcdMX0bt/jwKmDqVhg7MaoNQiL52/wg== X-Zone-Loop: c344f5f1c9bc4989ea0b965368847d4be65687a8b98a x-campaign-type: default x-transaction-id: f39eb999-6f23-4021-809f-dfcec5fc651c x-swg-uid: 01-cd384bd3-8b9e-4d0a-881c-4cdfd99bb011 X-Mailer: Sweego Message-ID: <1790328140.8631fc262581453bbf619ec5b2062170.1a0d7df70c000072c4@vates.tech> x-swg-bid: 1790328140.8631fc262581453bbf619ec5b2062170.1a0d7df70c000072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 37/39] xen/riscv: map IMSIC interrupt file for vCPUs From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Fri, 25 Sep 2026 11:22:11 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790328132; l=647; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=Z4dh3PTbP4Oxu2clZeoh3IcndyifA3q3L6A72ikO7VY=; b=kpKltQiNrVURi/5XqnGPz8wN1FLf8XIRWYCW+b89grT4DMJwYDV/snWdSIuYVdTwAFl3HEOSn wQKPH0YXgTtBnJt8tTkuRlGAZ5UdFb5wiU4TKX7OZydx1FVpOWMQCPe X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790328137926 X-purgate-ID: tlsNG-ef75cf/1790328142-3C411AE4-0F028921/10/73395122804 X-purgate-type: spam X-purgate-size: 647 On Thu, 27 Aug 2026 17:21:21 +0200, Oleksii Kurochko wrote: > A guest running in VS-mode expects its own IMSIC S-file at offset 0 of its > guest-physical IMSIC block. Physically, the guest-file (G-file) assigned to > this vCPU lives at a hart-relative offset given by guest_file_id (assigned > via the vGEIN allocator). Therefore, imsic_map_guest_file() uses stage-2 > translation to redirect the guest's fixed per-vCPU GPA page (offset 0) to > the specific physical guest-file page. > > [...] Reviewed-by: Baptiste Le Duc -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 25 09:22:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 09:22:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433558.1654060 (Exim 4.92) (envelope-from ) id 1xA28V-0000pz-7y; Fri, 25 Sep 2026 09:22:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433558.1654060; Fri, 25 Sep 2026 09:22:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA28V-0000ps-59; Fri, 25 Sep 2026 09:22:31 +0000 Received: by outflank-mailman (input) for mailman id 1433558; Fri, 25 Sep 2026 09:22:30 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xA28T-0000p7-Uk for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 09:22:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA28T-008DbT-BO for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:22:29 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab63d55-bab6-0a2a0a5309dd-0a2a450ad48a-4 for ; Fri, 25 Sep 2026 11:22:29 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab63d55-f2d2-0a2a450a0019-b9ff1c23a845-3 for ; Fri, 25 Sep 2026 11:22:29 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d7df725e00072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 25 Sep 2026 09:22:20 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id 9DD4881F57; Fri, 25 Sep 2026 11:22:19 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=yMkgpgjoPO5Zwne+U57iuasthQXgXPsJZONhP6yrplI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=J/Q0OyK0hm/EwCfqTOOS59m/o3A9NaMwsPxl3jv8j0j3Ba2MnQPqvSnOGxUGQd45jlSI6EfA4 Jjtx4xZ/nirzWa3C3ZBmRuxhubIQfVzwNs/6f2j3CPuHTVYE1xADQJS64S4yu4ChtH6CXdMJKEA fgVHTnvpQcINawAaUwQAODTuQQ3DzEnS5uPhcizOhz+aHIGvo3zHl9iypo5ao4sRBtLX7sVe4PG vFBMwxktW0xYbg64FyLagZMKP1M5MCxqYn8Z15d4NdUeXAT2Rn/uUSqGWDGnlQpS62GIXnY8tH/ u+SFwOqPt332wXuY3AWbv2vU427zQ3uZBoklo1v9DF1g== X-Zone-Loop: c956adb237c4396ec341af446ca9b513621539f8049b x-campaign-type: default x-transaction-id: c3b19550-973f-4d80-b0c6-5b32e5aa9db3 x-swg-uid: 01-10f32111-2741-4796-aa4a-980fafcd225b X-Mailer: Sweego Message-ID: <1790328140.8631fc262581453bbf619ec5b2062170.1a0d7df725e00072c4@vates.tech> x-swg-bid: 1790328140.8631fc262581453bbf619ec5b2062170.1a0d7df725e00072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu() From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: References: Date: Fri, 25 Sep 2026 11:22:11 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790328132; l=4790; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=RgdpzRTfxh87IHWx3Zc6PKiXzVKdXezeQqS5BeLk8Gc=; b=SoSho3XMk1U+ppWucrSnCeuPSk2MRZg1FgiXnQtWx9oY+wKFfcW0q6IEDunREEfjGLWuNEVFf 6fhx94CJ4vQBw/KnBvn/Mze5+8UHhjTxYmiDnMvtWUafb88wzYtMvzI X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790328139847 X-purgate-ID: tlsNG-4011c0/1790328149-53CD3CFC-A299344D/10/73395122804 X-purgate-type: spam X-purgate-size: 4790 > continue_new_vcpu() is the arch hook invoked the first time a freshly > created vCPU is scheduled. Implement both cases it has to cover: > - for the idle vCPU, switch to its own stack and jump to idle_loop(); > - for a guest vCPU, restore hstatus and enter the guest through the new > return_to_new_vcpu() path in entry.S, which loads sepc, passes the > hart id in a0 and the DTB address in a1 as expected by the RISC-V > boot protocol, sets sstatus.SPP and executes sret. > > Interrupts have to stay disabled across the restore. The trap entry > logic implicitly clears hstatus.SPV, so an interrupt taken between the > write of hstatus and sret would make sret return to HS-mode instead of > VS-mode, and restoring SPV afterwards is non-trivial. Instead interrupts > are simply kept off and sstatus.SPIE is set, so that SIE is restored from > SPIE once sret has been executed. Also, it follows what hardware will do > with real CPU which is also started with interrupts disabled. > > Introduce get_cpu_info() and reset_stack_and_jump() in asm/current.h, > needed by the above. get_cpu_info() is a macro rather than a static > inline because asm/current.h is pulled in by before > this_cpu() is defined and before completes struct vcpu. > > idle_loop() is added as a stub on purpose; its real implementation will > come separately later. > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index 2918196822..0782148b72 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -8,10 +8,13 @@ > #include > #include > > +#include > +#include > #include > #include > #include > #include > +#include > #include > #include > #include > @@ -140,9 +143,43 @@ static void vcpu_csr_init(struct vcpu *v) > v->arch.hie = MIP_SGEIP; > } > > +static void schedule_tail(struct vcpu *prev); > +static void noreturn idle_loop(void); > +void noreturn return_to_new_vcpu(void); > + > static void continue_new_vcpu(struct vcpu *prev) > { > - BUG_ON("unimplemented\n"); > + schedule_tail(prev); > + > + if ( is_idle_vcpu(current) ) > + reset_stack_and_jump(idle_loop); > + else > + { > + /* > + * During a context switch to a new vCPU, interrupts must be disabled > + * to guarantee that the vCPU's CSR state can be safely restored into > + * the hart without being clobbered by an interrupt trap. > + * > + * For example, when return_to_new_vcpu() finishes, it executes sret. > + * At that point, the hart checks hstatus.SPV=1 and sstatus.SPP=1 in > + * order to return from HS-mode into VS-mode. If an interrupt were to > + * arrive before sret, the trap entry logic would implicitly clear > + * hstatus.SPV to 0. Correctly restoring it afterwards is non-trivial, > + * and if left as 0, sret would incorrectly return to HS-mode instead > + * of VS-mode. > + * > + * To avoid this, interrupts are kept disabled during the restore. > + * Additionally, setting sstatus.SPIE=1 ensures that after sret is > + * executed (as sstatus.SIE will be loaded from SPIE), HS-mode will > + * continue to receive interrupts normally. > + */ > + local_irq_disable(); > + csr_set(CSR_SSTATUS, SSTATUS_SPIE); > + > + csr_write(CSR_HSTATUS, vcpu_guest_cpu_user_regs(current)->hstatus); > + > + reset_stack_and_jump(return_to_new_vcpu); > + } > } > > int arch_vcpu_create(struct vcpu *v) > @@ -551,3 +588,8 @@ static void __init __maybe_unused build_assertions(void) > */ > BUILD_BUG_ON(offsetof(struct cpu_info, guest_cpu_user_regs)); > } > + > +static void noreturn idle_loop(void) > +{ > + BUG_ON("unimplemented"); > +} > diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S > index 331446a238..bf1843dcea 100644 > --- a/xen/arch/riscv/entry.S > +++ b/xen/arch/riscv/entry.S > @@ -143,3 +143,26 @@ FUNC(__context_switch) > > ret > END(__context_switch) > + > +/* t0 is used as a temporary reg and is clobbered to oblivion */ > +FUNC(return_to_new_vcpu) > + /* Swap tp with sscratch */ > + csrrw tp, CSR_SSCRATCH, tp Why do we need a swap? After it, tp will be equal to zero, but we won't use it. Couldn't we do a basic csrw instead? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 25 09:25:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 09:25:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433586.1654068 (Exim 4.92) (envelope-from ) id 1xA2Ax-0001gk-P2; Fri, 25 Sep 2026 09:25:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433586.1654068; Fri, 25 Sep 2026 09:25:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA2Ax-0001gd-MM; Fri, 25 Sep 2026 09:25:03 +0000 Received: by outflank-mailman (input) for mailman id 1433586; Fri, 25 Sep 2026 09:25:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA2Aw-0001gH-LN for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 09:25:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA2Av-008EU5-EC for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:25:01 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab63de1-bab6-0a2a0a5309dd-0a2a4503895a-30 for ; Fri, 25 Sep 2026 11:25:01 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab63dec-fae8-0a2a45030019-4a7de18dc2ba-3 for ; Fri, 25 Sep 2026 11:25:00 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912e64ccso4430095e9.0 for ; Fri, 25 Sep 2026 02:25:00 -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 ffacd0b85a97d-4887a349fa1sm7895583f8f.8.2026.09.25.02.24.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Sep 2026 02:25:00 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790328300; x=1790933100; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=3z6ojXIO0zDL7LD8TnIZwg1SLz0VeRJlMP/I+aLZFxc=; b=KkKo1GAgU9F3dx0opD/33l4FZHwAo1n9bQwde0CxmIIclkMfwugbEcqJKEwfvZSCxG fkSfjPPAF06vomk/2mI4k99lWcVIk/fUhG8e1ds1w581LGHh14Xd/1gSUzrYDjJCnF+E trOqSphFp5jVSljDjO+KQ/LZQ6kd4736ztbXoPmr+OCsnGuvx7wMEiTEke5ND5h2VTB8 mCKfGmizek5w1YKmwGKHq8DInTQZHXr950q+FCKz5DDo3lnena78BZZ9DS0190m4YQS2 evLXe1+dHPurs8f95NxI9P4hI9vQ7IQSnKtfL8+VEOrvGcvKYNzjFFwUOa2qj2GemYQj w3EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790328300; x=1790933100; h=content-transfer-encoding:content-type: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:content-type; bh=3z6ojXIO0zDL7LD8TnIZwg1SLz0VeRJlMP/I+aLZFxc=; b=ATLhDahya6O9SD93zH6Z3MLhLek39ETPGDWQD98bSo2/Jz4o35g8I7R7P0bZhWjuLQ hn0BG5MILQIzSjVrDdal3xKrWDinsMjiK4u2hAoS1nOuptnzN19uoS4uIuT1rv16uzOC gABMGQSlsm3XP6oOg651CQ+fCFUJqRzTm84bN/Qdu1EnacEMzjO+0ggD5Ib/sXrDez5/ L37AukKdlLzVuT2nSIfIJ01mnTcKkLApkcEwoNFwsWE8uL4d/PpkRP4uHkLSFJmStwFj b2X8eEbGxMKLCY8X14Tq+ziS5VURjoAd8Tv4PxVWwCSx3IfEHbZrGPW2yMdTR+2GXkOg GVPw== X-Forwarded-Encrypted: i=1; AKwUvBx3Yv2hBxfqkfyxb+fj97jX4pO//6fKZcul40r5tjh6rENagT8yxI5Op3pBQ2YxKN7kUQfwy8GhzsQ=@lists.xenproject.org X-Gm-Message-State: AFuF++kbre1TrYHIKWGfSm4GvDviFPT3dOj8U3On2vJfUwC5JrQrpyQZ y54Tj3DFcEIzrNKYy0Kp5ZvLP64psWAjR3jweP8fKmEjchY1RiH9VhkEHt0KRsrtqA== X-Gm-Gg: AYBFou3IryNjYt6QSE/ZqOgPNJ7pjcgDn8+FDtjr0qDKZziKSzbbG/TPpsO4PfHmUIQ ywE6xTROkrcgW1NRFXYNUHd4R9jk2Wwg883lfelxAECZZdAgQo84m5Ck2nUy6yP/5UlpNcFmhAP d3Dl4qC3grZJv6lSGWUDos/yySXXXa24lffS3WTMQxBFEnt46rG3TMi/PDy5y3INvtKT9CmWczQ FX7N1drlRrsmKl9Hya9RvbyJI/Iv4L1zZtJ1bEamNuWiRUMajqkdo9jcaEkQlJodMCDh5HnBTOz m4xEQiNMtzI2jr6kawExaEjLR5v8UKRTmXi6b91jez7LzechpMqS4an1O1MOc+mpEX2o+Wby8jC IKeIvxvmug5wUqMAYW8l1i9VAGrlOyoLb7IY5l0tVPIH5PwC1boj+avAexdFUCGLLAJPn7BW585 5Yvio6TPCWvrE9YRc5u+GaK02MR5Fa26zec1qDjIe0CuiYweDp53xYxZ1iQ7Xtm/Ol8JYszf+HR j5AW2wCboO5vR53AYGT/NFN6dWgtF4oDrGJr6wRmoaJc6mAARZXD8zwXkNYSA== X-Received: by 2002:a05:600c:4e93:b0:49c:f89b:f82 with SMTP id 5b1f17b1804b1-49fe66d2d2fmr95436075e9.12.1790328300374; Fri, 25 Sep 2026 02:25:00 -0700 (PDT) Message-ID: <480139b0-faa4-4425-af4b-4d884b0d3112@suse.com> Date: Fri, 25 Sep 2026 11:24:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2.1 5/5] tools: expose admission control toggle via xl sched-rtds To: =?UTF-8?B?RnVya2FuIMOHYWzEscWfa2Fu?= Cc: andrew.cooper3@citrix.com, roger@xenproject.org, anthony.perard@vates.tech, =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel@lists.xenproject.org References: <20260918080935.35498-6-frn1furkan10@gmail.com> <20260918104106.53530-1-frn1furkan10@gmail.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: 8bit X-purgate-ID: tlsNG-33051d/1790328301-754844E9-A0139A7F/0/0 X-purgate-type: clean X-purgate-size: 843 On 25.09.2026 11:13, Furkan Çalışkan wrote: > On 9/18/26 13:45, Jürgen Groß wrote: >> On 18.09.26 12:41, Furkan Caliskan wrote: >>> Wire the per-cpupool admission-control switch through libxl >>> to xl sched-rtds, and document it. >>> >>> Add -s/--schedparam to list or set pool-wide RTDS scheduler >>> parameters, and -a/--admission to enable or disable admission >>> control for a cpupool ("-c pool -s -a 0/1"). >>> >>> Signed-off-by: Furkan Caliskan >> >> Reviewed-by: Juergen Gross > > Just noticed that patches 1-4 have been merged, but patch 5 > (which already has a Reviewed-by from Juergen) doesn't seem to have > made it in. Could you let me know if it needs anything further, > or if it just got missed? It's still waiting for a maintainer ack, afaict. Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 25 09:45:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 09:45:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433603.1654077 (Exim 4.92) (envelope-from ) id 1xA2UA-000563-8u; Fri, 25 Sep 2026 09:44:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433603.1654077; Fri, 25 Sep 2026 09:44:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA2UA-00055w-69; Fri, 25 Sep 2026 09:44:54 +0000 Received: by outflank-mailman (input) for mailman id 1433603; Fri, 25 Sep 2026 09:44:53 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA2U9-00055n-3X for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 09:44:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA2U7-00HJzP-TX for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:44:51 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab64289-e002-0a2a0a5209dd-0a2a450a912c-22 for ; Fri, 25 Sep 2026 11:44:51 +0200 Received: from [40.93.196.18] (helo=SA9PR02CU001.outbound.protection.outlook.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab64291-f2d2-0a2a450a0019-285dc412ca39-3 for ; Fri, 25 Sep 2026 11:44:50 +0200 Received: from SJ0PR13CA0037.namprd13.prod.outlook.com (2603:10b6:a03:2c2::12) by BY5PR12MB4131.namprd12.prod.outlook.com (2603:10b6:a03:212::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Fri, 25 Sep 2026 09:44:44 +0000 Received: from SJ5PEPF000001C8.namprd05.prod.outlook.com (2603:10b6:a03:2c2:cafe::32) by SJ0PR13CA0037.outlook.office365.com (2603:10b6:a03:2c2::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.14 via Frontend Transport; Fri, 25 Sep 2026 09:44:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001C8.mail.protection.outlook.com (10.167.242.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Fri, 25 Sep 2026 09:44:44 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 25 Sep 2026 04:44:43 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 25 Sep 2026 04:44:43 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Fri, 25 Sep 2026 04:44:40 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rEV3O3Z4zG3BnNnTK0KXmXjXb5n0vATjQrb20lrNPycXnGnAg1hdl7N9RTl+eJg3k1jTYVoPVM4qZZGoF8POlko2nkchz1htjkEhZYT1zpiIfgxoBxiEjWEUaIjygaRgGSgpwyWkb/zndAqbyiHKJrqw/utu86B2RpwQHlhpDBq5ghM82oPk1B2Jj1SyfnvE6EUHMMP+8iJyHHuK1NXiJtC7RBS2U0gocyMw3mg4/JCaPZCd0UHCjzHBp+YoM8kFmrj5RysZnTy88xkWyOHygGNxucbjm1jynb0euo0mbbGW1gloAqBl63GlW4RhETUNJQgMjdMyxn3bTkA/3URypA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i28OjEiM8mx+Q9SHXTUbKcboZg2drHrP221eBpOLvuo=; b=hdKmVdiP4nHPlFRObL6xG9Xbip8xvD51zgIIjiy6GttYMwEJu4p9TarY3gWPwyd7la2Po7wUBMp1ZPwg/MLoXqcxjvpeOFt5bA6MXdenjH2dwl3AqkLz6wtzqzUIbY/GwijjAUOAnQch1nKtdKVyRY8uuncHKSN/iy41bDJWJ5TNlw8wY/fNmM6qJjtuIcILDpHjK1IuaVjhsidr4A0yoqxUjCNJCrnX6oI9+ngydbAvcOKa/SlTiJOcveOJyikLhCWsGquZSIzZ6aBeVcHWzv6O44pjCLVDrbsoIa+0sfOch1PsStMHPIL4vmNEn8yGu+5iyZ53Su78dtkOKbMeIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i28OjEiM8mx+Q9SHXTUbKcboZg2drHrP221eBpOLvuo=; b=JPYDd5MqtXoce1Vi2lZ2ZOY38Fj7URL+J0Z+TJNGG0b1FAOLYEHSVE6Z+ssP5Om5jQ6reqq/33fWp8MSkmeO17mVxFnhRg1hzuQFWUYKiP2oKnr+Lvi/W5or5CcdvwdOCPPshqlnrY/2BfpDrtX1nYqS5sfr93BhR8ISJDRLnRU= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <1421f319-8e95-431f-9527-d492f8397cc2@amd.com> Date: Fri, 25 Sep 2026 11:44:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Consolidate linker script setup data To: Alejandro Vallejo , Jason Andryuk , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , Teddy Astie , Grygorii Strashko References: <20260923161935.24429-1-jason.andryuk@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001C8:EE_|BY5PR12MB4131:EE_ X-MS-Office365-Filtering-Correlation-Id: 787c5000-64ff-4429-197b-08df1ae9a11d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|7416014|36860700016|23010399003|22082099003|10067099003|56012099006|11063799006|18002099003|4143699003; X-Microsoft-Antispam-Message-Info: wfpUhWBNB6PG4Ac6WwOMwzKxP/c13Ys7I+KV1QkOQd/6gH9C62HSeWkm5E3ajTLUR4rXl/JaPm0tf7dO/oY5INHRt6ecInwJ+FHEuHTsA1GQjgcnX1HWdMHEI6oowLew9na9RTNQy85HZcrso0g8QCmWWsSEmVnr0Ipo/lENkWmRhz0u9uTXIE4C6GR87gJzXdeIyS9Myl2SCIQ/Ayz/xSF9JsRwSCArzcq6ygES29pFgpeqnvwj8LkSTLDm/y5+3MYIMjwrWcOc+5l22KKwp81Q2IS1Xdq2dHX046DDhZxhojrlmBk4c4ppooBAq6lGFg7462yItJp7n4jVfMjyNfqMGXYOlRGiyvNGiimzm77VgNgRcF8JOmJtko/jbNU3am7cfHGGlkSGkeqz1f9roSj2R5vzHeRBPuk6wWFzYAAsp+FnK7ojJRMAD2i241l90dNpRdjREDeDyU6S7g1yres2tnSYK4JeBmcdwvLNcJji3T7s/IL18yVgwTxS4a5MDHLKrk4uhoM/HANFxmBt//hxOThMqGCIhDqCu6Kz/bBsrGVvSRHO8F21Isz2ZFl2HN7vTO0QcLhHqw11uxAj3tvcqyelbV2X6V5Ehj7AnHEi42arAB+BCOO0tjDVG84BqjgdKUa3ImcyTXNdkRbuEKUtFTV8Y5GzgKpLYyjhYWlvYsBuclW/zn3rUvOsANPFuEyeSnj05wkNvgw3ucRxtg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(7416014)(36860700016)(23010399003)(22082099003)(10067099003)(56012099006)(11063799006)(18002099003)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 9NLNSlE3mGukb8nbsD6DekHydkF6eGSUazkuGibvvEGp5cuW4LaMu0TeuWW3LIUHVHIWq0nV/wOZ0E1O9g6g4j1042mie6FmvmvxqTrXpjdBZKyGAu+e5CuGS+vbXEq64XFf9qHeUxCuDPA/EL5y3+BakOaGKsLU8qrk/pCpw/1fKqxwB5bnBCm48KRT3XRfgwu4xbzQpL5WZYXabHUEnhxczJXMIThSb+QpYi3KnOvzE9fUcySx4OHScY6vGtVdqiSrkQMgF/6hw8txsehrIIXQGYDJrSwja5P15brI+qKMuuqd3QbFFm7khUNR4L5A8Xojrp4ztvJusRQCk3iRsPVstjVbH0oSP1xlqGbZbrr6Z+86PWnRhjb0YVEM8D9IrPyN+NHfps9RaFOAy/gAuaoqWe9z4D8QTka56msM7e/HF78C+lpHbeppNEaHXjoO X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 09:44:44.1349 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 787c5000-64ff-4429-197b-08df1ae9a11d X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001C8.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4131 X-purgate-ID: tlsNG-4011c0/1790329491-4B0D9CFC-352B4011/0/0 X-purgate-type: clean X-purgate-size: 566 On 24-Sep-26 17:58, Alejandro Vallejo wrote: > On Wed Sep 23, 2026 at 6:19 PM CEST, Jason Andryuk wrote: >> .init.setup, .initcallpresmp.init, and .initcall1.init are duplicated >> across architectures. Replace them with a common define, SETUP_DATA. >> >> Suggested-by: Grygorii Strashko >> Signed-off-by: Jason Andryuk >> Reviewed-by: Alejandro Vallejo >> Reviewed-by: Jan Beulich Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Sep 25 09:51:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 09:51:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433612.1654088 (Exim 4.92) (envelope-from ) id 1xA2aE-0006qn-UE; Fri, 25 Sep 2026 09:51:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433612.1654088; Fri, 25 Sep 2026 09:51:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA2aE-0006qg-QO; Fri, 25 Sep 2026 09:51:10 +0000 Received: by outflank-mailman (input) for mailman id 1433612; Fri, 25 Sep 2026 09:51:09 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA2aD-0006qZ-Ag for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 09:51:09 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA2aC-008ImR-KD for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:51:08 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab64409-e002-0a2a0a5209dd-0a2a450cd4f8-10 for ; Fri, 25 Sep 2026 11:51:08 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab64267-f479-0a2a450c0019-a06583089148-3 for ; Fri, 25 Sep 2026 11:44:07 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id C0B344718AAB; Fri, 25 Sep 2026 05:42:02 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Abdelkareem Abdelsaamad To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, Abdelkareem Abdelsaamad Subject: [PATCH v5] x86/nSVM: Check injected event consistency Date: Fri, 25 Sep 2026 10:38:17 +0100 Message-ID: <216f0de990dd180c8336837e86bf5860e37b9c50.1790326132.git.abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-d25034/1790329448-51936A5B-B1C49FD7/13/0 X-purgate-type: bulk X-purgate-size: 15017 On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has debugging complications, security and performance implications. The APM volume #2 15.20 (40332—Rev. 4.10—July 2026) states the two possibilities that VMRUN will immediately exit with VMEXIT_INVALID due to the injected event. These are • Reserved values of TYPE have been specified. • TYPE = 3 (exception) has been specified with a vector that does not correspond to an exception (this includes vector 2, which is an NMI, not an exception). Furthermore, reading through the APM shows that the exception vector validity can also depend on the guest mode, the CPU generation and the microarchitectural constraints. Some vectors are only valid starting with the specific CPU generation that introduced the corresponding feature, the guest mode or whether the guest opted-in for specific CPU capability. The Upstream KVM introduced a similar consistency check that reflects on this dependency with the commit 7e79f71bca5c ("KVM: nSVM: Add missing consistency check for EVENTINJ"). However, the KVM implementation did allow the Overflow (X86_EXC_OF) and the BOUND Range (X86_EXC_BR) vectors injection in 64-bit mode. According to the APM Volume #2 and Volume #3 (40332—Rev. 4.10—July 2026), injecting these exceptions while the guest is in 64-bit mode is invalid and triggers an immediate VMEXIT_INVALID. This architectural mismatch in the KVM implementation was reported here: https://lore.kernel.org/all/20260803225402.2324595-1-abdelkareem.abdelsaamad@citrix.com/ To verify the hardware behaviour with the various vectors, A case-by-case testing on 64-bit mode Windows guest is performed. The hardware exception event is manually injected at the end of svm_vmexit_handler and the consequence is observed: - If VMEXIT_INVALID is triggered, the injection is invalid. - If a guest triple fault is triggered, the event passed the hardware checks and completed the event delivery. It is valid. Extend the VMCB validation to check for the VMCB event injection inconsistency. While at it, extend the svm_vmcb_isvalid usage to the non-nested VMEXIT_INVALID debugging. Clean up svm_vmcb_isvalid by dropping the unused `verbose` parameter and by correcting the misleading boolean return value to properly reflect the validation status. Signed-off-by: Abdelkareem Abdelsaamad --- Changes in v5: - Drop the rejection of injected events when the VALID bit is not set. The testing confirms no VMEXIT_INVALID is triggired in such case. - Reject the X86_EXC_BP (#BP) and the X86_EXC_OF (#OF) exception vectors when injected into SEV-ES guests to respect architectural constraints. - Reject X86_EXC_VC (#VC) event injection entirely, as testing confirms manual injection of the VMM Communication exception unconditionally triggers a VMEXIT_INVALID. - Separate X86_EXC_HV (#HV) into its own explicit case block with a dedicated architectural comment. - Extend the use of svm_vmcb_isvalid() to non-nested VMEXIT_INVALID debugging to improve error diagnostics, and clean up the internal logic of the function. - Promote the vmcb_injected_type and the vmcb_injected_vector to unsigned int type. - Add an inline comment explaining the purpose and architectural backing of the new vmcb_valid_event_inj_types_mask. Changes in v4: - Reject the injected events with the valid bit not set. - Fix the APM revision details. - Rename the is_valid_svm_vmcb_injected_exception_vector to the shorter is_valid_injected_exception_vector. - Address coding style comments regarding !! operator usage for boolean returns, concise debug messaging for reserved vectors, and blank lines between non-fall-through case blocks. - Drop the X86_EXC_HV from the permitted vectors. Changes in v3: - Restricted X86_EXC_OF (4) and X86_EXC_BR (5) vector injections to non-64-bit guests to prevent impossible guest-mode state injections per AMD APM Volumes 2 & 3. - Refactored exception vector validation from if-conditions to a switch statement to improve readability and extensibility. - Restricted X86_EXC_CP (21) vector injection to guests with enabled CET to prevent VMRUN failures on hardware without CET support. Changes in v2: - Remove the redundant SVM_EVENT_INJ_TYPE_MASK and SVM_EVENT_INJ_VEC_MASK constants. - Correct the Injected Event Type consistency check to disallow the injection of reserved type 1 events. --- Testing: - Using a locally developed XTF nested virt setup, I manually tested VMRUN instruction handling with a malformed VMCB: 1) Inject event with the type (7). The hypervisor logs show the message (XEN) [ 645.155609] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid Injected Event Type: 0x7. 2) Inject event with the exception value (3) and the vector value (2) for NMI. The hypervisor logs show the message (XEN) [ 645.157277] d2v0[nsvm_vmcb_prepare4vmrun]: eventinj: Invalid exception type: 0x3 vector: 0x2. 3) Inject event with the exception value (3) and the vector value (21) for the X86_EXC_CP (Control-Flow Protection). Without the changes included: On the Naples host, where the vector was not yet known to the hardware. VMRUN immediately triggers VMEXIT_INVALID. 4) To perform more detailed bare-metal testing, I set up a testing matrix using a XenServer Windows 10 64-bit VM and manually injected the various events according to the testing matrix below: ----------------------------------------------------------------------------------- |Exception Vector| AMD Naples | AMD Genoa | Testing Conditions | |----------------|-------------------|------------------|--------------------------| | - X86_EXC_OF | VMEXIT_INVALID | VMEXIT_INVALID | - Verified that 64bit | | - X86_EXC_BR | | | mode is active before | | | | | injecting the event. | |----------------|-------------------|------------------|--------------------------| | | | | - Verified that the | | | | | Genoa host does not have | | - X86_EXC_CP | Guest Triple fault| VMEXIT_INVALID | guest_cr[4] X86_CR4_CET | | | | | set and the VMCB does not| | | | | have CR4 X86_CR4_CET set | |----------------|-------------------|------------------|--------------------------| | | | | - APM states only valid | | - X86_EXC_HV | VMEXIT_INVALID | VMEXIT_INVALID | to inject into VMSAs that| | | | | execute with Restricted | | | | | Injection. | |----------------|-------------------|------------------|--------------------------| | - X86_EXC_DE | | | - Verified that hosts | | - X86_EXC_DB | | | do not have guest_cr[4] | | - X86_EXC_UD | | | X86_CR4_OSXMMEXCPT set | | - X86_EXC_BP | | | and the VMCB does not | | - X86_EXC_NM | | | have CR4 | | - X86_EXC_DF | | | X86_CR4_OSXMMEXCPT set | | - X86_EXC_TS | Guest Triple fault|Guest Triple fault| with the vector | | - X86_EXC_NP | | | X86_EXC_XM. | | - X86_EXC_SX | | | with the vector | | | | | X86_EXC_MC. | |----------------|-------------------|------------------|--------------------------| | - X86_EXC_CSO | | | | | - X86_EXC_SPV | | | | | - X86_EXC_VE | VMEXIT_INVALID | VMEXIT_INVALID | | | - X86_EXC_VC | | | | ---------------------------------------------------------------------------------- - CI tests: https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2881691847 --- xen/arch/x86/hvm/svm/nestedsvm.c | 8 +-- xen/arch/x86/hvm/svm/svm.c | 1 + xen/arch/x86/hvm/svm/vmcb.c | 90 ++++++++++++++++++++++++++++++-- xen/arch/x86/hvm/svm/vmcb.h | 2 +- 4 files changed, 91 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c index 81579370b8..bb3511622d 100644 --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -595,15 +595,15 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct cpu_user_regs *regs) /* Cleanbits */ n2vmcb->cleanbits.raw = 0; - rc = svm_vmcb_isvalid(__func__, ns_vmcb, v, true); - if ( rc ) + rc = svm_vmcb_isvalid(__func__, ns_vmcb, v); + if ( !rc ) { gdprintk(XENLOG_ERR, "virtual vmcb invalid\n"); return NSVM_ERROR_VVMCB; } - rc = svm_vmcb_isvalid(__func__, n2vmcb, v, true); - if ( rc ) + rc = svm_vmcb_isvalid(__func__, n2vmcb, v); + if ( !rc ) { gdprintk(XENLOG_ERR, "n2vmcb invalid\n"); return NSVM_ERROR_VMENTRY; diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 71e48351f2..ebdeb95dbf 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2619,6 +2619,7 @@ void asmlinkage svm_vmexit_handler(void) if ( unlikely(exit_reason == VMEXIT_INVALID) ) { + svm_vmcb_isvalid(__func__, vmcb, v); gdprintk(XENLOG_ERR, "invalid VMCB state:\n"); svm_vmcb_dump(__func__, vmcb); domain_crash(v->domain); diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index a6f09672a7..50bec50fc5 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -327,20 +327,91 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb) svm_dump_sel(" TR", &vmcb->tr); } +static bool is_valid_injected_exception_vector(const struct vmcb_struct *vmcb, + uint8_t vmcb_injected_vector, const struct vcpu *v) +{ + switch ( vmcb_injected_vector ) + { + case X86_EXC_DE: + case X86_EXC_DB: + case X86_EXC_UD: + case X86_EXC_NM: + case X86_EXC_DF: + case X86_EXC_TS: + case X86_EXC_NP: + case X86_EXC_SS: + case X86_EXC_GP: + case X86_EXC_PF: + case X86_EXC_MF: + case X86_EXC_AC: + case X86_EXC_MC: + case X86_EXC_XM: + case X86_EXC_SX: + return true; + + /* + * Exception vectors 3 and 4 may not be injected into SEV-ES guests. + * If this is attempted, the VMRUN will fail with a VMEXIT_INVALID + * error code. + * See the APM Volume #2 15.35.8 (40332—Rev. 4.10—July 2026). + */ + case X86_EXC_BP: + return !vmcb_get_sev_es(vmcb); + + /* + * If the VMM attempts to inject an event that is impossible for the + * guest mode (e.g., a #BR exception when the guest is in 64-bit mode), + * the event injection will fail... VMRUN will immediately exit with + * VMEXIT_INVALID. + * See the APM Volume #2 15.20 (40332—Rev. 4.10—July 2026). + */ + case X86_EXC_OF: + return ( (!(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l) && + !vmcb_get_sev_es(vmcb) ); + + case X86_EXC_BR: + return !(vmcb_get_efer(vmcb) & EFER_LMA) || !vmcb->cs.l; + + case X86_EXC_CP: + { + unsigned long guest_valid_cr4 = hvm_cr4_guest_valid_bits(v->domain); + return guest_valid_cr4 & X86_CR4_CET; + } + + /* + * X86_EXC_HV vector is reserved for SNP guests use. Only allowed to be + * injected into VMSAs that execute with Restricted Injection. + * See the APM Volume #2 15.36 (40332—Rev. 4.10—July 2026). + */ + case X86_EXC_HV: + default: + return false; + } +} + bool svm_vmcb_isvalid( - const char *from, const struct vmcb_struct *vmcb, const struct vcpu *v, - bool verbose) + const char *from, const struct vmcb_struct *vmcb, const struct vcpu *v) { - bool ret = false; /* ok */ + bool ret = true; /* ok */ unsigned long cr0 = vmcb_get_cr0(vmcb); unsigned long cr3 = vmcb_get_cr3(vmcb); unsigned long cr4 = vmcb_get_cr4(vmcb); unsigned long valid; uint64_t efer = vmcb_get_efer(vmcb); + unsigned int vmcb_injected_type = vmcb->event_inj.type; + unsigned int vmcb_injected_vector = vmcb->event_inj.vector; + /* + * Represent the nonreserved and accoridngly valid guest exception or + * interrupt type. + * See the APM Volume #2 15.20 (40332—Rev. 4.10—July 2026). + */ + unsigned long vmcb_valid_event_inj_types_mask = (1 << X86_ET_INTR) | + (1 << X86_ET_NMI) | + (1 << X86_ET_HW_EXC) | + (1 << X86_ET_SW_INT); #define PRINTF(fmt, args...) do { \ - if ( !verbose ) return true; \ - ret = true; \ + ret = false; \ printk(XENLOG_GUEST "%pv[%s]: " fmt, v, from, ## args); \ } while (0) @@ -399,6 +470,15 @@ bool svm_vmcb_isvalid( PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n", vmcb->event_inj.raw); + if ( !((1ul << vmcb_injected_type) & vmcb_valid_event_inj_types_mask) ) + PRINTF("eventinj: Invalid Injected Event Type: %#x\n", + vmcb_injected_type); + + if ( (vmcb_injected_type == X86_ET_HW_EXC) && + !is_valid_injected_exception_vector(vmcb, vmcb_injected_vector, v) ) + PRINTF("eventinj: Invalid exception type: %#x vector: %#x\n", + vmcb_injected_type, vmcb_injected_vector); + #undef PRINTF return ret; } diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index 3760f71a86..78ace19b27 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -565,7 +565,7 @@ void svm_destroy_vmcb(struct vcpu *v); void setup_vmcb_dump(void); void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb); bool svm_vmcb_isvalid(const char *from, const struct vmcb_struct *vmcb, - const struct vcpu *v, bool verbose); + const struct vcpu *v); /* * VMCB accessor functions. -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Sep 25 10:10:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 10:10:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433660.1654096 (Exim 4.92) (envelope-from ) id 1xA2sZ-00021P-EW; Fri, 25 Sep 2026 10:10:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433660.1654096; Fri, 25 Sep 2026 10:10:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA2sZ-00021E-B8; Fri, 25 Sep 2026 10:10:07 +0000 Received: by outflank-mailman (input) for mailman id 1433660; Fri, 25 Sep 2026 10:10:06 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA2sY-0001v7-Ir for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 10:10:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA2sX-00HP2n-RS for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 12:10:05 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab64877-2eae-0a2a0a5409dd-0a2a4509ede4-10 for ; Fri, 25 Sep 2026 12:10:02 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab6487a-be1a-0a2a45090019-d155802aa8cf-3 for ; Fri, 25 Sep 2026 12:10:02 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4980fe6b3beso10339345e9.0 for ; Fri, 25 Sep 2026 03:10:02 -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 ffacd0b85a97d-4887a349fa1sm8436019f8f.8.2026.09.25.03.10.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Sep 2026 03:10:01 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790331002; x=1790935802; darn=lists.xenproject.org; h=content-transfer-encoding:content-type: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 :content-type; bh=/DwskbpTsUOApT6/J9HgR7S91QaDE9ndp8yl6w/+1JI=; b=R1WzkFNCWptBuKWAUhTeEx0h0wi9JlEmXGsJ0u31lO7tQj3CC/TxpFgPf5El7QZaEM EeXFQDY5j/oyfHY7giLizHfSwiuiF/3FA8OAEmSt3IcBKESPs0l016SeXYn4PfHBzjve Y4+tiLIanEBuJNPMs5dlX4SMsepHEywZe5Z8nsKGfqhAo2Kl0HizNx/tvD7v3A90S2qS bs6ELvqgCssEak+MILl+nNKm8uLT623CXc0wzwba4bOkU+KaN5jqgiYccyDHRG0loGA3 XXvMig4CPJvr5n+sB/HQ3edYs/kDbPeiFlzuMpS8NAmon1pBltXEt/esyVNnUfznEj/8 o58w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790331002; x=1790935802; h=content-transfer-encoding:content-type: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:content-type; bh=/DwskbpTsUOApT6/J9HgR7S91QaDE9ndp8yl6w/+1JI=; b=cHdS2Xb+EaEtuimeSVpfyoEM6vV2qut5t1OCeK32OY5u8eh3HXrje57FFOHSt+yQ/q kc8L218KybWKVyTvttwMlN1bPZrGchDksQvcXEnSRpavd3DI44yykBs6Tth9P/eZfyIS RahCF/4y34yzoDeuxjH2laahr+sJa/WhJr+DCK7pRbFLgfIK6Rdu33GShxaxwoIwqo0r nmGcSCF8RueImutkc505rCgcosLwcB+J7giyrykHSExV/peJglYDMGUIazy8xPSWpOTd s0Y63FOoKpbKTiRXpZ/nXs3yKg7K5HJgJePWPHReylFw2ddIkCrMqWiwsjOEyV0rtq86 Igqw== X-Forwarded-Encrypted: i=1; AKwUvBwGv6NyNWlxiAthPmVswwnrkNVqwjJ2YNIpfnJokkiepK2giKL/13Kc6KKX2CZJsc9r7Nw+n9nd9JA=@lists.xenproject.org X-Gm-Message-State: AFuF++kOu87QLIHl0nkty0/NPhDa6Aob+aNW7bYJpQcF+BIJ1PcYvTWw +FASlmY0DujcsFN9QodYwK1FGVU1OKkrMVR7sr8OZNolMrEglQNkrZVpZOG2DcvjKA== X-Gm-Gg: AYBFou0in6miWZ7aP9QsW7DnSxdWtKLJ3CYJdIOKgwKHjdvVS9t/M5mik16ZQ1z3Gzh EL7HC+Fk85qzNrLhoPKjBbWCITCbQxY6MTs5H3Z7TXq8ZIxPhG3knGEpUtzX4GX9Mm9ZMOb5TOz zosLTF3D8KjHMrWxsKwVytcnun5sfjQ46ynhSY4mqqZRi5ul7FxzVDrMzsm8crSTBQAX57/i/Zi 4PC+zqvnbyfD4Ql6/Kd2zjiOHbCUCEFcLBm4ZAJ9C8uZM/7p24CxifQxeWR1V9n8itOZWH1VCA4 V4ihXWpeaSdJcHfw1uxcMhWeH9lWNP/uL61b+tcZlhpkVy7KtFQw4HDDPkkhqcudNbC2PYcNY7x aPRS/7G3ilQn9YKAvK3mtRWT5OJ5Ic3g/kTQOGZ3tGjHYW7xFlig9QqGEn9q8I3nN/B5c5G+i0l ISj3U7S9k4VPaUNl0Mzz6QP19+1rw2ovqegzs07OHUqsphlEXrU07xy1nFYoMeQaj+slMcS0TIx 4aZk3f8EgxOUxP5pR/ZtK7hhu/dr8u3qctvFglE31rx77kATlr8VSt7wDQC27s= X-Received: by 2002:a05:600c:3656:b0:49d:28fc:d6a0 with SMTP id 5b1f17b1804b1-49fe670c76cmr71948715e9.18.1790331001862; Fri, 25 Sep 2026 03:10:01 -0700 (PDT) Message-ID: <70f930b2-31ba-4278-ab82-03a3c67d573c@suse.com> Date: Fri, 25 Sep 2026 12:10:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] x86/nSVM: Check injected event consistency To: Abdelkareem Abdelsaamad Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech, xen-devel@lists.xenproject.org References: <216f0de990dd180c8336837e86bf5860e37b9c50.1790326132.git.abdelkareem.abdelsaamad@citrix.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: <216f0de990dd180c8336837e86bf5860e37b9c50.1790326132.git.abdelkareem.abdelsaamad@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-bad1c0/1790331002-FD469034-9A091F58/0/0 X-purgate-type: clean X-purgate-size: 549 On 25.09.2026 11:38, Abdelkareem Abdelsaamad wrote: > On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has > debugging complications, security and performance implications. The APM > volume #2 15.20 (40332—Rev. 4.10—July 2026) states the two possibilities that > VMRUN will immediately exit with VMEXIT_INVALID due to the injected event. This is confusing: Another variant of this was sent a little under half an hour earlier. Simply going from size, the two also aren't identical. What's going on here? Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 25 10:25:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 10:25:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433682.1654104 (Exim 4.92) (envelope-from ) id 1xA37b-0004FW-MG; Fri, 25 Sep 2026 10:25:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433682.1654104; Fri, 25 Sep 2026 10:25:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA37b-0004FP-JW; Fri, 25 Sep 2026 10:25:39 +0000 Received: by outflank-mailman (input) for mailman id 1433682; Fri, 25 Sep 2026 10:25:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA37a-0004FJ-4h for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 10:25:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA37Z-008Qqe-EB for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 12:25:37 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab64bf4-bab6-0a2a0a5309dd-0a2a450ce7d0-40 for ; Fri, 25 Sep 2026 12:25:37 +0200 Received: from [74.125.228.98] (helo=mail-ed2-f34.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab64c21-f479-0a2a450c0019-4a7de462963c-3 for ; Fri, 25 Sep 2026 12:25:37 +0200 Received: by mail-ed2-f34.google.com with SMTP id 4fb4d7f45d1cf-6aae7b7fe22so1039004a12.2 for ; Fri, 25 Sep 2026 03:25:37 -0700 (PDT) Received: from ?IPV6:2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112? (2a00-12d0-af5d-ad01-5d3f-14e6-9bcb-5112.ip.tng.de. [2a00:12d0:af5d:ad01:5d3f:14e6:9bcb:5112]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6aae5dd78e1sm830540a12.18.2026.09.25.03.25.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Sep 2026 03:25:35 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Type:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1790331937; x=1790936737; darn=lists.xenproject.org; h=content-type: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:content-type; bh=ZWNYdM3K5LHNSvq4KmxGNNLfg/K9DprEEpObZs9aw3I=; b=ToEVOl8oMgyIAiid2cdyKGI1RU4aIAgnM5j6XqUHDX3Xjzq5K2ZpKYagO7QhitcU49 0S9UAE6ZsktYu0hcc7VMji4d7cV+RsMdOKthcihETLDRs5BC1yi5uLGEd9hrhDefJj+9 vffs9zjHtsLQ4l4cNpFCDKFf0YlretaSPHh1prycPLJIzorsmbBORJxme0mAU1AEVD1y EtsthtaAly1f4yhmJzDsRwjPgIn55W+G3sB5xaaIXZdc+8fvMJD5Qsom8ofNBWQ0WUBr 7iFfaJ9tKSmRNiVngO0EP7He4JmdYGRNoJgYj2RBF4qTeZf0I2udJvU8u1EFq50KXxGO Hf6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790331937; x=1790936737; h=content-type: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 :content-type; bh=ZWNYdM3K5LHNSvq4KmxGNNLfg/K9DprEEpObZs9aw3I=; b=x34bJNJxNzHAwNV6BZKc2sQwwXjE+IfLJkEVmAa6E88HGWf4WczYm6lchud9syw1Hn 374RwZv3NcqujWGCgAorQsO0UDyT5YMQKPt8Lg7Su0LuFW+hybr+QqqVyTKArL3Vsu3R fQ7BCuds3unQCUkIe1Rb90+vPVW3VLen3CCs/IRNKDkx0+AXVtwW3pEDIY2m9GL9YqpF KxQIuAvbSOD6/zbNl7/oW3m2UJGHrNtdT8RH2VdzNeqIT09aoUIjNCnyD0YNGI+YD2HP LP4+E+mloNqpmCXJZ2f4AcXA+I/Xw1WdHr8fem+3fKsnOIzWJJvbp3XRnAnIoYsjdPxh hBew== X-Forwarded-Encrypted: i=1; AKwUvBzjq8tME6tZMm2RAqxvdu7BdHNsvwhft4Mxnkfd/+7xrea1SQIJHnXoq+BrvNqxpbXhfVkxf9Uv2Zo=@lists.xenproject.org X-Gm-Message-State: AFuF++nSm5YbnS/5mmIo6grypnxtBJZFmsKbzXjm2aaiMvveU8re3oGB lSHrtSDUQppEy491fda1sgM00QQZPAGwxlmkMLPE4BeSVkLepW5iT14CsjaTiVhg/NE= X-Gm-Gg: AYBFou3I2uoVutYXtMhL7+YZaTMsdT8zGZywqsGrs5lmtg43ALq4G0jSPNNQUprLR0v kg419doQqrXwqU9Nw1PLhMOmZo7IGuvFWe7eSNcMoP4Pufv3kQxxMQoktPob8ptpNf30HPYQ+At 0OPNBTKDKB3rt7yOdDQlHAGT8L4j0G9Ukrx2cI2ey/u+4kc1KS3NvX8XxvV1biMsKGVcnbNTpIW mauinshrARNqDKoy5ubaqYlfUCXSkOfDwe/fCvmjpkvrqlBSWkFrgnT1dFu7aFCHDZJ0IUTRZIE RCGosLov4L4vs5f3OOsNFnYgaahVTv9SN6aaHUR5qbB2A+lP6VdF/u46PdllCy9zv3XRUIFjWVK ckAH7m/cPxRdjW9lSb2oRfmavy47x+IgYhYpUuLgLutdEPA7jtggQBme+Rn09gfZOlYRrDaDz5Y 3VekJbwk9mk9lJTWZxiHD6+Fy9jepwdTkdnksSqaPtc7VzlcvWEN3tGZlrWAtYMWUYn7E0NV1Sj vlSIjm+20G2UyD7W7LASLk1dOhSLdfMq2z+n55eTi92tzPmPMsM9mq9sU754v86JESf1HKEHKrk tqP8mEXH02Y+Pm81/lmWaE2Sj7c0v/3OyBE= X-Received: by 2002:a05:6402:3251:b0:6aa:a3bd:c6a1 with SMTP id 4fb4d7f45d1cf-6aae8f66ad6mr1177208a12.40.1790331936607; Fri, 25 Sep 2026 03:25:36 -0700 (PDT) Message-ID: Date: Fri, 25 Sep 2026 12:25:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 00/17] x86/msr: Inline rdmsr/wrmsr instructions To: Shreshth Srivastava , linux-kernel@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, llvm@lists.linux.dev Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, xin@zytor.com, nathan@kernel.org, ndesaulniers@google.com, jpoimboe@kernel.org, peterz@infradead.org, boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org References: <20260911084211.3149957-1-jgross@suse.com> <20260923193619.1408940-1-shreshth.srivastava@intel.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260923193619.1408940-1-shreshth.srivastava@intel.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FcahRLIPpkidr0MhRok6l1Ai" X-purgate-ID: tlsNG-d25034/1790331937-028DDA5B-F021E689/35/110847 X-purgate-type: clean X-purgate-size: 10662 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FcahRLIPpkidr0MhRok6l1Ai Content-Type: multipart/mixed; boundary="------------1vAieXh0bKe5ArCEjlp9QPsZ"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Shreshth Srivastava , linux-kernel@vger.kernel.org, x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, llvm@lists.linux.dev Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, xin@zytor.com, nathan@kernel.org, ndesaulniers@google.com, jpoimboe@kernel.org, peterz@infradead.org, boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH v5 00/17] x86/msr: Inline rdmsr/wrmsr instructions References: <20260911084211.3149957-1-jgross@suse.com> <20260923193619.1408940-1-shreshth.srivastava@intel.com> In-Reply-To: <20260923193619.1408940-1-shreshth.srivastava@intel.com> --------------1vAieXh0bKe5ArCEjlp9QPsZ Content-Type: multipart/mixed; boundary="------------Mkl0Q8jWZxLmkvShEj9On0ww" --------------Mkl0Q8jWZxLmkvShEj9On0ww Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjMuMDkuMjYgMjE6MzYsIFNocmVzaHRoIFNyaXZhc3RhdmEgd3JvdGU6DQo+IE9uIDEx LjA5LjI2IDEwOjQxLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gV2hlbiBidWlsZGluZyBh IGtlcm5lbCB3aXRoIENPTkZJR19QQVJBVklSVF9YWEwgdGhlIHBhcmF2aXJ0DQo+PiBpbmZy YXN0cnVjdHVyZSB3aWxsIGFsd2F5cyB1c2UgZnVuY3Rpb25zIGZvciByZWFkaW5nIG9yIHdy aXRpbmcgTVNScywNCj4+IGV2ZW4gd2hlbiBydW5uaW5nIG9uIGJhcmUgbWV0YWwuDQo+IA0K PiBIaSBKdWVyZ2VuLA0KPiANCj4gVGhpcyBkb2Vzbid0IGJ1aWxkIHdpdGggQ09ORklHX1BB UkFWSVJUX1hYTD15LiAxNi8xNyBhbmQgMTcvMTcgYXJlIHdoZXJlDQo+IGl0IGJyZWFrcywg YnV0IHRoZSBjYXVzZSBpcyB0aGUgLmJ5dGUgZmFsbGJhY2tzOiBBU01fV1JNU1JOU19JTU0g ZnJvbQ0KPiAwOC8xNyBhbmQgQVNNX1JETVNSX0lNTSBmcm9tIDEwLzE3IGRvbid0IGVuZCBp biBhIHNlcGFyYXRvciwgdW5saWtlIHRoZQ0KPiAuaW5zbiB2YXJpYW50cyBhYm92ZSB0aGVt Lg0KPiANCj4gICAgI2RlZmluZSBBU01fUkRNU1JfSU1NCQkJCVwNCj4gCSIgLmJ5dGUgMHhj NCwweGU3LDB4N2IsMHhmNiwweGMwOyAubG9uZyAlY1ttc3JdIg0KPiANCj4gVGhhdCB3b3Jr ZWQgd2hpbGUgdGhleSB3ZXJlIG9ubHkgZXZlciB0aGUgbGFzdCBhcmd1bWVudCBvZiBhbg0K PiBBTFRFUk5BVElWRSgpLCB3aGljaCBhcHBlbmRzIGl0cyBvd24gbmV3bGluZS4gMTYvMTcg Y29uY2F0ZW5hdGVzIHRoZW0NCj4gd2l0aCBBU01fQ0xSRVJSOg0KPiANCj4gCUFTTV9SRE1T Ul9JTU0gQVNNX0NMUkVSUiwgWDg2X0ZFQVRVUkVfTVNSX0lNTSwJXA0KPiANCj4gc28gdGhl IC5sb25nIG9wZXJhbmQgcnVucyBpbnRvIHRoZSB4b3IuIEZyb20NCj4gbWFrZSBhcmNoL3g4 Ni9rZXJuZWwvY3B1L2NvbW1vbi5zOg0KPiANCj4gCS5ieXRlIDB4YzQsMHhlNywweDdiLDB4 ZjYsMHhjMDsgLmxvbmcgMjY2eG9yICVyZHgsJXJkeA0KPiANCj4gICAgcGFyYXZpcnQtbXNy Lmg6MTY1OiBFcnJvcjoganVuayBhdCBlbmQgb2YgbGluZSwgZmlyc3QgdW5yZWNvZ25pemVk IGNoYXJhY3RlciBpcyBgeCcNCj4gDQo+IGNsYW5nIHJlcG9ydHMgImVycm9yOiB1bmV4cGVj dGVkIHRva2VuIiBpbiB0aGUgc2FtZSBwbGFjZS4gNzEgb2JqZWN0cw0KPiBmYWlsLCB0aGUg c2FtZSA3MSBlaXRoZXIgd2F5LCBubyB2bWxpbnV4Lg0KPiANCj4gbXNyLmggY2hvb3NlcyBi ZXR3ZWVuIHRoZSAuaW5zbiBmb3JtIGFuZCB0aGUgLmJ5dGUgZmFsbGJhY2sgd2l0aDoNCj4g DQo+IAkjaWYgZGVmaW5lZChDT05GSUdfQVNfSVNfR05VKSAmJiBDT05GSUdfQVNfVkVSU0lP TiA+PSAyNDEwMA0KPiANCj4gVHdvIGtpbmRzIG9mIHRvb2xjaGFpbiBlbmQgdXAgb24gdGhl IC5ieXRlIHNpZGUgb2YgdGhhdCB0ZXN0Og0KPiANCj4gICAgLSBHTlUgYXMgb2xkZXIgdGhh biAyLjQxLiBSSEVMIDkgYW5kIENlbnRPUyBTdHJlYW0gOSBzaGlwIDIuMzUsIGFuZA0KPiAg ICAgIERvY3VtZW50YXRpb24vcHJvY2Vzcy9jaGFuZ2VzLnJzdCBzZXRzIHRoZSBtaW5pbXVt IGF0IDIuMzAsIHNvIHRoaXMNCj4gICAgICBpcyBhIHN1cHBvcnRlZCBjb25maWd1cmF0aW9u IHJhdGhlciB0aGFuIGFuIG9sZCBvdXRsaWVyLg0KPiAgICAtIGNsYW5nLCBhbnkgdmVyc2lv bi4gQ09ORklHX0FTX0lTX0dOVSBpcyBuZXZlciBzZXQgZm9yIGNsYW5nLCBzbyB0aGUNCj4g ICAgICAmJiBzaG9ydC1jaXJjdWl0cyBhbmQgdGhlIHZlcnNpb24gY29tcGFyaXNvbiBpcyBu ZXZlciByZWFjaGVkLiBZb3VyDQo+ICAgICAgMDgvMTcgY29tbWVudCBhbHJlYWR5IG5vdGVz IHRoYXQgY2xhbmcgaGFzIG5vIC5pbnNuIHN1cHBvcnQuDQo+IA0KPiBnY2Mgd2l0aCBiaW51 dGlscyAyLjQxIG9yIG5ld2VyIHRha2VzIHRoZSAuaW5zbiBwYXRoLCB3aGVyZSBib3RoIG1h Y3Jvcw0KPiBkbyBlbmQgaW4gYSBzZXBhcmF0b3IsIGFuZCBpcyB1bmFmZmVjdGVkLg0KPiAN Cj4gUmVwcm9kdWNlZCBvbiB2Ny4zLXJjMiB3aXRoIHlvdXIgdjMgMDAvMTMsIHYyIDAvNSBh bmQgdjUgMDAvMTcgYXBwbGllZCBpbg0KPiB0aGF0IG9yZGVyLCB4ODZfNjQgZGVmY29uZmln IHBsdXMgSFlQRVJWSVNPUl9HVUVTVCwgUEFSQVZJUlQsIFhFTiBhbmQNCj4gWEVOX1BWLiBn Y2MgMTEuNS4wIHdpdGggR05VIGFzIDIuMzUuMiwgYW5kIGNsYW5nIDIxLjEuNy4NCj4gDQo+ IFRlcm1pbmF0aW5nIGJvdGggZmFsbGJhY2tzIGZpeGVzIGl0LCBhbmQgYm90aCB0b29sY2hh aW5zIHRoZW4gYnVpbGQNCj4gdm1saW51eCB3aXRoIG5vIGVycm9ycyBvciB3YXJuaW5nczoN Cj4gDQo+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tc3IuaCBiL2FyY2gv eDg2L2luY2x1ZGUvYXNtL21zci5oDQo+IGluZGV4IGViYTMyNWVjZmU0Yy4uNTI5YzEzNTUz YzYzIDEwMDY0NA0KPiAtLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tc3IuaA0KPiArKysg Yi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9tc3IuaA0KPiBAQCAtNzgsOSArNzgsOSBAQCBzdGF0 aWMgaW5saW5lIHZvaWQgZG9fdHJhY2VfcmRwbWModTMyIG1zciwgdTY0IHZhbCwgaW50IGZh aWxlZCkge30NCj4gICAgKiBmb3JtIE1TUiBhY2Nlc3MgaW5zdHJ1Y3Rpb25zIHJlZmVyZW5j ZSAlcmF4IGFzIHRoZSByZWdpc3RlciBvcGVyYW5kLg0KPiAgICAqLw0KPiAgICNkZWZpbmUg QVNNX1JETVNSX0lNTQkJCQlcDQo+IC0JIiAuYnl0ZSAweGM0LDB4ZTcsMHg3YiwweGY2LDB4 YzA7IC5sb25nICVjW21zcl0iDQo+ICsJIiAuYnl0ZSAweGM0LDB4ZTcsMHg3YiwweGY2LDB4 YzA7IC5sb25nICVjW21zcl1cblx0Ig0KPiAgICNkZWZpbmUgQVNNX1dSTVNSTlNfSU1NCQkJ CVwNCj4gLQkiIC5ieXRlIDB4YzQsMHhlNywweDdhLDB4ZjYsMHhjMDsgLmxvbmcgJWNbbXNy XSINCj4gKwkiIC5ieXRlIDB4YzQsMHhlNywweDdhLDB4ZjYsMHhjMDsgLmxvbmcgJWNbbXNy XVxuXHQiDQo+ICAgI2VuZGlmDQo+IA0KPiAgICNkZWZpbmUgUkRNU1JfQU5EX1NBVkVfUkVT VUxUCQkJXA0KPiANCj4gQVNNX1dSTVNSTlMgbmVlZHMgbm8gY2hhbmdlLCBfQVNNX0JZVEVT KCkgYWxyZWFkeSBlbWl0cyBhIHNlbWljb2xvbi4NCj4gDQo+IFRoZSBXUk1TUk5TIGxpbmUg YmVsb25ncyBpbiAwOC8xNyBhbmQgdGhlIFJETVNSIGxpbmUgaW4gMTAvMTcuDQoNClRoYW5r cywgd2lsbCBiZSBmaXhlZCBpbiBWNi4NCg0KDQpKdWVyZ2VuDQo= --------------Mkl0Q8jWZxLmkvShEj9On0ww Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------Mkl0Q8jWZxLmkvShEj9On0ww-- --------------1vAieXh0bKe5ArCEjlp9QPsZ-- --------------FcahRLIPpkidr0MhRok6l1Ai Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmq2TB4FAwAAAAAACgkQsN6d1ii/Ey91 vAf/VB+YAt/VPKDUyX+XUcDHENA9JuLl63VStLAndnBlPvr4goo4TbR55SP/Qw5MebGF5z9/QwTQ K/pEituZVgrW3mJueIxCaZ7XKdV1u9wnRnZsnvp08rdk8272iHSVOL+jtRpKzCJPlpSUt86d+nnm bEvk3ZvR0mz3ZmI9oJ/xFqQMOcZilP72lbGJ31q2ZPsiaG+AUa3lGF9uTIsxPurfiXZ3Xp7EJJFu zG84GsYboJta2BfMbomQc1hEgXd7sTDienp3bd66xNxIrGwyDuw5/WicTPgEZSqnl6f7eQSRu54G AKbTona4G4ZvUXLUd3ZffjeBXaAZ1fwMJxrGKDVODw== =TEAR -----END PGP SIGNATURE----- --------------FcahRLIPpkidr0MhRok6l1Ai-- From xen-devel-bounces@lists.xenproject.org Fri Sep 25 10:44:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 10:44:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433700.1654114 (Exim 4.92) (envelope-from ) id 1xA3Pm-0007cn-4g; Fri, 25 Sep 2026 10:44:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433700.1654114; Fri, 25 Sep 2026 10:44:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3Pm-0007cg-22; Fri, 25 Sep 2026 10:44:26 +0000 Received: by outflank-mailman (input) for mailman id 1433700; Fri, 25 Sep 2026 10:44:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3Pl-0007ca-6a for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 10:44:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA3Pk-009P5o-JT for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 12:44:24 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab65084-bab6-0a2a0a5309dd-0a2a4504dc1a-20 for ; Fri, 25 Sep 2026 12:44:24 +0200 Received: from [40.107.201.45] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab65086-b57f-0a2a45040019-286bc92dba69-3 for ; Fri, 25 Sep 2026 12:44:23 +0200 Received: from BN0PR08CA0009.namprd08.prod.outlook.com (2603:10b6:408:142::13) by CY8PR12MB7516.namprd12.prod.outlook.com (2603:10b6:930:94::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Fri, 25 Sep 2026 10:44:19 +0000 Received: from BN3PEPF00022BD8.namprd03.prod.outlook.com (2603:10b6:408:142:cafe::4e) by BN0PR08CA0009.outlook.office365.com (2603:10b6:408:142::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.18 via Frontend Transport; Fri, 25 Sep 2026 10:44:18 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF00022BD8.mail.protection.outlook.com (10.167.248.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Fri, 25 Sep 2026 10:44:18 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 25 Sep 2026 05:44:18 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Fri, 25 Sep 2026 05:44:16 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZDka137dJ31Nhwz/p+rbHlkV0xXTQZ0y+dv2A6pjyzXyCPEgc5le+9wLEM1/TNCPnD88LyZf4GXkSkJF+ZWwVDnq1uU8ko2P1QN0gfy4me7hsfAwxBZwRQAO9qa146Zg1tsl64l234i9dytRtP0kySUY2Ddt5jWqvC1SqJeFkvcsTq9rn9g+lrPG4vlCIi5anxc+iDozKp/qLq5i6iRzLFcEQ+BgD/FYtC+TNitz6Nqdpnws21H1Jh0OGIBEuMVvrzo2KsW7dI3P63M1LmXbiuxjXxDfafCi9F3ehoFTX5xZgnJM0N0cF3RGE1TyoiRz0DdfXADg2NcVpBvanAQSuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1FCVyw/sOgRirrmYGUQZZv/XQGrYeP2WbciVAyRYmcM=; b=fuLFFmWNXHATpgs3B4iGJxWw1GKJY8LIx0dWWA8AtoDIgOXvrhl8QtCGRa+aSot4P8r/iwUfuTlAYIuyDTNBohOpYZniJoh/S4fWYr3f5AFdbQkEdknVlhf/jV0YppHlqu47Yb9m7AZSkEQ97e5SlNeYFIZ5eFQYqv8ABMCY/4Ll1jIA3G3i/D1ANXymQzaaJ5ptcI0MR2hCtZEFtgH/aBN08udydDHSED+fy+J+rhrca+y5R+DyKqfeh4PP/UihFEQybt0dptl6k6/RNvjNeIc/cfeAhj7yftsy7JO+n9BHX/DzlxUIvUZaFqAgC0REB1JGKOWvCX9EcmAy1Wkt6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1FCVyw/sOgRirrmYGUQZZv/XQGrYeP2WbciVAyRYmcM=; b=SgHEBEws2pcRbQi1DYl+uMJAdxx39GoHds6cD0Fld4KJgpAimivH6aMjZfepPZn9Stnwq6o70TxmidKJJVqiYZdvB1zvcwnlXY1ggqj4zxPlLBjF30M9UrjzBG1NTVdk1wcYCQNdjKaNliKHKY7wC7XQpnb1r1Fe842bR9+fgyM= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: <27701081-7062-40bd-bfdd-aaeb3f1ea6e4@amd.com> Date: Fri, 25 Sep 2026 12:44:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] xen/arm: derive GIC CPU interface ID fields from the vGIC To: Volodymyr Babchuk , Mykola Kvach CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis References: <4f24dd8cd9fc76e8c3f93bca44bb58056cbcc51a.1790147101.git.mykola_kvach@epam.com> <87o6dm1d6x.fsf@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <87o6dm1d6x.fsf@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF00022BD8:EE_|CY8PR12MB7516:EE_ X-MS-Office365-Filtering-Correlation-Id: 16c2cd55-8f67-45cf-448a-08df1af1f3a3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|82310400026|1800799024|23010399003|10067099003|5023799004|56012099006|4143699003|11063799006|6133799003|260925021311599002|18002099003|22082099003|260925022911599002|260925021911599002; X-Microsoft-Antispam-Message-Info: ihpxjnZ00WhE+zhaK8bua70LvVDu89gTyQhfxCnWxnetVkfVtb+FgWa9BsJwYJ2cVa9ArqEuuHQxN3jbs+dhCFFkNZA0b+03zsx89ioeS0ex/aqRQN1NyusoEfyklbCpHettjvvx07K/U6OtRVoFoOhyTrpNU1ZggVHWbq+Dl6kV+tcYBLejHUrQIr5s0murJwSdXebgdpIkfNGE1nCdI9MwWlvgOKsta3sWiwWBSjElxik5EJKuV9Nb40G9m3kv5ck9U7DEzZrhDmZe5NpmY3wJ4+5P8qSqnw8w5pe9aAqrQ2z7IjpH7t0S7fmUR3HvejdUdonSr/daf3HMYbACG2UKCUUcWOg9ie9QDrh7Z+bgK3epIBlHQ0C0KNJDg32CCnBuVEpaLuBec4RdT4jaufrXngLg+7LRvve9bYukY4bPwEQndT8yuId77MUX5lEOG2BYWVXqPU8QwKDHjFnCuHmPTBthEVMuHep0WDqAjqKc6RdsOSV+BREI/hFu2CU+zHu9seTlAi1FBSQghoKGSzlQmiNTisvkID7L5R9qx1/GifaCP7QVi6UpU0hv0CK/akB1ZhyBsMmQkyrYz20N9bHIr4QMgjg/9Z1H0fC0OLq0Myw63tG1EuopQwlSA1nie5yCz5H6GckgcAF7Q8NAug== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700016)(82310400026)(1800799024)(23010399003)(10067099003)(5023799004)(56012099006)(4143699003)(11063799006)(6133799003)(260925021311599002)(18002099003)(22082099003)(260925022911599002)(260925021911599002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: s3wfqYC7WX99aKFMFpsIvCqj4FR52XxCQ35+pboIBCIb6wzRZVhw1FwnJ+a9Q5EnFI2bIyyPtEcP5mn4n4vUBjbH+3t2ng1DjtWQcg7QuSQeKfwE32Kn3drjaZuCVLDb/pC7j2hdBeWt9qP4fbdIGorIrYbVJCq8XGDYRxCHe0ayTLQtKnAxP24CRVjrz0dhrurOKF/KGhZJV72khaX4HSCmkTClRsoDpywRWio8h6h8XsRl7YdMhNbxnA6NvyqUL/EgUuHUWk55zeDGlgDoy81ydzKuNsmIxrUnb74HeqM/LgxktIRHASJ8KLy7Hs+Do3uGM9HO9A9BFxyQSmPY5yT9hds0/b1YUpsnfOeNZxj7qXQwunRWbpT8dN85DLpZDyseqowO+2TmvYrotsIYn9FsZPnwh9lALK0Wj4sVjvrZw/hJP36Brloj+98E7Ylx X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 10:44:18.6479 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 16c2cd55-8f67-45cf-448a-08df1af1f3a3 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF00022BD8.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7516 X-purgate-ID: tlsNG-ebf023/1790333064-C34C3B50-7FF49486/0/0 X-purgate-type: clean X-purgate-size: 8018 On 25-Sep-26 00:45, Volodymyr Babchuk wrote: > Hi Mykola, > > Mykola Kvach writes: > >> Xen exposes ID_AA64PFR0_EL1.GIC and ID_PFR1.GIC from domain_cpuinfo, >> which is initialized from the sanitized host CPU feature state. This >> does not necessarily match the virtual interrupt controller configured >> for a domain. >> >> A vGICv2 domain can therefore observe a nonzero GIC field when the host >> supports the GIC system register interface, even though Xen disables that >> interface for the domain. On a GICv4.1-capable host, a vGICv3 domain can >> observe encoding 0b0011, although Xen exposes only its vGICv3 model. >> >> Derive the fields from the domain's vGIC version instead. Expose 0b0000 >> for vGICv2 and 0b0001 for vGICv3. This covers ID_AA64PFR0_EL1 and the >> ID_PFR1_EL1 alias in AArch64 state, as well as ID_PFR1 accessed through >> CP15 in AArch32 state. Leave the alias unchanged when AArch32 is >> unavailable. >> >> Fixes: 07b9acea116e ("xen/arm: Add handler for ID registers on arm64") >> Fixes: 8f81064a07c6 ("xen/arm: Add handler for cp15 ID registers") >> Signed-off-by: Mykola Kvach >> Reviewed-by: Michal Orzel >> --- >> Changes in v5: >> - Fold the vGIC version mapping into the shared ID register helper. >> - Use the vreg_ and VREG_ prefixes for the helper and field width. >> - Cosmetic changes after review >> >> Changes in v4: >> - Explain why ID_PFR1_EL1 is left unchanged without AArch32 EL0 support. >> - Move all ID_PFR1_*_SHIFT definitions to the common asm/sysregs.h and >> remove the unused cpregs.h includes from the ARM64 files. >> - Return explicit unsigned GIC field values to avoid MISRA C Rule 10.3. >> >> Changes in v3: >> - Add direct dependencies for the shared ID register helpers. >> - Move ID_PFR1_GIC_SHIFT to the common CP15 register header. >> - Apply cosmetic fixes from review. >> >> Changes in v2: >> - Share the GIC ID field helpers between the AArch64 and AArch32 paths. >> - Parenthesize the individual ASSERT conditions. >> - Preserve ID_PFR1_EL1.GIC when AArch32 is unavailable. >> - Target master instead of the 4.22 release. >> >> v1: https://patchew.org/Xen/ba4f779d68c54efc80c4a566dca38ac2e6f9a073.1783675708.git.mykola._5Fkvach@epam.com/ >> --- >> xen/arch/arm/arm64/vsysreg.c | 21 ++++++++++++++++++++- >> xen/arch/arm/include/asm/arm64/sysregs.h | 9 --------- >> xen/arch/arm/include/asm/sysregs.h | 9 +++++++++ >> xen/arch/arm/include/asm/vreg.h | 20 ++++++++++++++++++++ >> xen/arch/arm/vcpreg.c | 12 +++++++++++- >> 5 files changed, 60 insertions(+), 11 deletions(-) >> >> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c >> index 66f4f23bb3..d8f380ccb7 100644 >> --- a/xen/arch/arm/arm64/vsysreg.c >> +++ b/xen/arch/arm/arm64/vsysreg.c >> @@ -299,7 +299,22 @@ void do_sysreg(struct cpu_user_regs *regs, >> * to identify the processor features >> */ >> GENERATE_TID3_INFO(ID_PFR0_EL1, pfr32, 0) >> - GENERATE_TID3_INFO(ID_PFR1_EL1, pfr32, 1) >> + case HSR_SYSREG_ID_PFR1_EL1: >> + { >> + register_t guest_reg_value = domain_cpuinfo.pfr32.bits[1]; >> + >> + /* >> + * Preserve the sanitized ID_PFR1_EL1 value when AArch32 EL0 >> + * is not supported, as for the other AArch32 ID registers. >> + */ >> + if ( cpu_feature64_has_el0_32(&domain_cpuinfo) ) >> + guest_reg_value = vreg_id_reg_set_gic_field(guest_reg_value, >> + ID_PFR1_GIC_SHIFT, >> + v->domain); >> + >> + return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, >> + guest_reg_value); >> + } >> GENERATE_TID3_INFO(ID_PFR2_EL1, pfr32, 2) >> >> case HSR_SYSREG_ID_DFR0_EL1: >> @@ -362,6 +377,10 @@ void do_sysreg(struct cpu_user_regs *regs, >> guest_reg_value |= (sysval << ID_AA64PFR0_SVE_SHIFT) & mask; >> } >> >> + guest_reg_value = vreg_id_reg_set_gic_field(guest_reg_value, >> + ID_AA64PFR0_GIC_SHIFT, >> + v->domain); >> + >> return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1, >> guest_reg_value); >> } >> diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h >> index f3c11d871e..f6ece8f972 100644 >> --- a/xen/arch/arm/include/asm/arm64/sysregs.h >> +++ b/xen/arch/arm/include/asm/arm64/sysregs.h >> @@ -438,15 +438,6 @@ >> #define MVFR1_FPDNAN_SHIFT 4 >> #define MVFR1_FPFTZ_SHIFT 0 >> >> -#define ID_PFR1_GIC_SHIFT 28 >> -#define ID_PFR1_VIRT_FRAC_SHIFT 24 >> -#define ID_PFR1_SEC_FRAC_SHIFT 20 >> -#define ID_PFR1_GENTIMER_SHIFT 16 >> -#define ID_PFR1_VIRTUALIZATION_SHIFT 12 >> -#define ID_PFR1_MPROGMOD_SHIFT 8 >> -#define ID_PFR1_SECURITY_SHIFT 4 >> -#define ID_PFR1_PROGMOD_SHIFT 0 >> - >> #define MVFR2_FPMISC_SHIFT 4 >> #define MVFR2_SIMDMISC_SHIFT 0 >> >> diff --git a/xen/arch/arm/include/asm/sysregs.h b/xen/arch/arm/include/asm/sysregs.h >> index f6af987ef5..8dcf82a694 100644 >> --- a/xen/arch/arm/include/asm/sysregs.h >> +++ b/xen/arch/arm/include/asm/sysregs.h >> @@ -9,6 +9,15 @@ >> # error "unknown ARM variant" >> #endif >> >> +#define ID_PFR1_GIC_SHIFT 28 >> +#define ID_PFR1_VIRT_FRAC_SHIFT 24 >> +#define ID_PFR1_SEC_FRAC_SHIFT 20 >> +#define ID_PFR1_GENTIMER_SHIFT 16 >> +#define ID_PFR1_VIRTUALIZATION_SHIFT 12 >> +#define ID_PFR1_MPROGMOD_SHIFT 8 >> +#define ID_PFR1_SECURITY_SHIFT 4 >> +#define ID_PFR1_PROGMOD_SHIFT 0 >> + >> #ifndef __ASSEMBLER__ >> >> #include >> diff --git a/xen/arch/arm/include/asm/vreg.h b/xen/arch/arm/include/asm/vreg.h >> index 387ce76e7e..a85fefcc3e 100644 >> --- a/xen/arch/arm/include/asm/vreg.h >> +++ b/xen/arch/arm/include/asm/vreg.h >> @@ -4,11 +4,31 @@ >> #ifndef __ASM_ARM_VREG__ >> #define __ASM_ARM_VREG__ >> >> +#include >> +#include >> +#include >> + >> +#include >> + >> typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r, >> bool read); >> typedef bool (*vreg_reg_fn_t)(struct cpu_user_regs *regs, register_t *r, >> bool read); >> >> +#define VREG_ID_REG_GIC_WIDTH 4 > > Should this go into sysregs.h? > > Something like ID_AArchx_PFR_GIC_SHIFT? I am open to alternatives in naming. I don't think that's necessary, given that we don't have any _WIDTH macros in there and other places hard code widths (e.g. SVE). Especially that we are now at v5 and we should avoid subjective NITs. > >> + >> +static inline register_t vreg_id_reg_set_gic_field(register_t val, >> + unsigned int shift, >> + const struct domain *d) >> +{ >> + register_t mask = GENMASK(shift + VREG_ID_REG_GIC_WIDTH - 1, shift); >> + enum gic_version vgic_ver = d->arch.vgic.version; >> + >> + ASSERT((vgic_ver == GIC_V2) || (vgic_ver == GIC_V3)); >> + >> + return (val & ~mask) | ((vgic_ver == GIC_V3 ? 1U : 0U) << shift); > > Probably better to use constants? > > Something like ID_AArchx_PFR_GIC_V3 and ID_AArchx_PFR_GIC_NO_CPU_INTF. This suggestion is valid. Please add in common sysregs.h: /* GIC field encodings, common to ID_PFR1{,_EL1} and ID_AA64PFR0_EL1 */ #define ID_PFR_GIC_NI 0x0 #define ID_PFR_GIC_V3 0x1 You can retain my Rb. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Sep 25 10:47:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 10:47:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433712.1654122 (Exim 4.92) (envelope-from ) id 1xA3SB-0008GU-KX; Fri, 25 Sep 2026 10:46:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433712.1654122; Fri, 25 Sep 2026 10:46:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3SB-0008GM-Hp; Fri, 25 Sep 2026 10:46:55 +0000 Received: by outflank-mailman (input) for mailman id 1433712; Fri, 25 Sep 2026 10:46:53 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3S9-0008G6-Db for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 10:46:53 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA3S8-00E8Ue-QW for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 12:46:52 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab65119-e002-0a2a0a5209dd-0a2a4509b8f4-4 for ; Fri, 25 Sep 2026 12:46:52 +0200 Received: from [40.107.130.118] (helo=MRWPR03CU001.outbound.protection.outlook.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab6511c-be1a-0a2a45090019-286b82769d70-3 for ; Fri, 25 Sep 2026 12:46:52 +0200 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com (2603:10a6:800:33d::10) by GV1PR03MB10583.eurprd03.prod.outlook.com (2603:10a6:150:209::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Fri, 25 Sep 2026 10:46:50 +0000 Received: from VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04]) by VI0PR03MB11419.eurprd03.prod.outlook.com ([fe80::6717:e4b8:c376:4a04%3]) with mapi id 15.21.0451.014; Fri, 25 Sep 2026 10:46:50 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Q/v43mklJ7vLS0P1T+TwVgaXzRTGn+yXcGPLkbWJiDHNvygr6tOfMMoYfyaeUqQmK+QAccDgZIXiy85R2SlNh+kiDJ8PFy3CN0QB/6I9AgHGYoC/RB4JdE07n5JAnqvpjkUTjUFv57niu/ZV4ONWfrTL/c/nSAKctcb4lIZYwVzmzjrCQT/Sx3UDtYD3qkbN4MbgPj4bPeKvYBVrscxcO2H88GpeAVsQaq3rpMYvEjFAOv+HH1ihCZeUw05UqdPJJN/pvDjeGplB2oA68MlaJOiaTqwWjF8Olh8uBtMwqAg6/96Y1DZnCxCFODExcrdrSTJzqBG9qvzPjlc2et2pkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NDPLqELqZp4MR/YjRg5dTtoiK8bKh2TfvwqQaLlTur8=; b=wKe0Tvdd7DShNSnuSxCqX6KlrIiR5gF18ohCMYfyS6NKBlRaOpY74n/BrtN2kv0ET4irmeE51DWZ2ZgCxNa1zazF+M5xgQb5P82av59WUGei0MC+0MJKjHa3fy4MZ0aELgPMxG8LSyKfXyMvg/pZZuEOxl90Q+ckddbJmYhztQPzegOc3Tfwbwdd11w8J2vi4U3Fa4/1sOPbg/jDZPqUwz1FXZqD2vrJ0eNLelp5oEpK/jkrMWtUfODIZkW13GZAAiIwSsYPYPnROmVf3eFIiAVm6thaHJCeP2c78ZwYQ0T/czzdCWgbIm7OUJD5O6OBnPXwi4NbxI4uQ2F1gg8GNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NDPLqELqZp4MR/YjRg5dTtoiK8bKh2TfvwqQaLlTur8=; b=PBu2x8eUES4aqu+VBs+C4fHHV/yWE5d3eDMOZJJe4c8qmrh2dSOwnxeJ8gLEzigYAh5c4MKQqGPrMNxxZNRrvlnDQc0f4pnQFyKv7ob3fVNsYV111KftW3EDxCTOoaXyi8luz50k5U4Cs4hAPgHa0U7tsg/urXeoVSmaBQzzvatT0ey6LomLLFiFI0bOA8PSxJDBzGe75KC5s+lDZJS47hlrM+3GHPgcfzS2faAQSDSxhxUT8l9DWbM37CHZtDHoQdDA+5460zrO1R1j1NLFaLE6zSQ2/bQbjtNLh2vABUpnCbtVAttHFxoqM/OBDodz6h0RtGsh6YTijCWiwHgNdQ== From: Oleksii Moisieiev To: Volodymyr Babchuk CC: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Grygorii Strashko Subject: Re: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v13 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHdSqBOtjSUOlH6/km+/eJYUhrZf7bfIRSA Date: Fri, 25 Sep 2026 10:46:49 +0000 Message-ID: <2d907f95-9f40-4e51-9d7a-274fd9a01b24@epam.com> References: <5c3ae163d21f619bf25c8757232a1a0867c3eb87.1790087968.git.oleksii_moisieiev@epam.com> <87pky43hm2.fsf@epam.com> <63f4841c-fb36-40c4-b96e-4a1aed95fbda@epam.com> <878q4r30wy.fsf@epam.com> <87zex61ofy.fsf@epam.com> In-Reply-To: <87zex61ofy.fsf@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI0PR03MB11419:EE_|GV1PR03MB10583:EE_ x-ms-office365-filtering-correlation-id: b3836a7d-1a2a-460a-7d5b-08df1af24dd2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|7416014|10067099003|56012099006|11063799006|4143699003|6133799003|3023799007|18002099003|22082099003|38070700021; x-microsoft-antispam-message-info: K+sWtFS7fWCSW31AFYhgU+BibxQ5+PYUM8Wn80tJGizmeMfDHWowgK7YZ1Q1S4SD0M0YSs5md+Jl6Tgl0wlt9HnDyqz5jzLhu9daWoUWQCjFoZF0CRNuNC3Zxj3Jm4OeIarwhUH5qLw8BQiRwxECj9/27J6l9H4k5cpJa+JNiqpA54ev10s0Jo+vccJWslqvPzd68+xBGfZbmZ7x54XLPrnMxpCjDItpCIslQtIuZt6e6+wNLLeptsOoqLItjsdrW99nXSBXCy66jDRkQ00M+suYBU7Xr7TJTvNbn8DY2JOly+e0G0FvIHl0JwDVCo4PTz4Rmx+UGB2EJNmxoggPq66ER52GXyNgj9s1jQILKY3b7nI5aG0bLQNzcUAJBEe4+8TqqArYBig3vfnrxkUQ0gqklvRp9FA1gHvsgHxE+6F6TCwvIsidAm+02eEasyym7p3XU1UJPRZAwI1lWxRNx9OTiCf/Y74pq/u7D7I5L+u9iCY+k/Cl9T/upKtVDPBmSseDG8i36J/YgdAb7sqnbXB8TnHTx3lHeQTKO4g+olx9Egmk4wp0Q2v2J2WORbvty1yeOVlLUBC+k8qOebQgHQCjoUPGnAk+OUnNww1E/ND7QcsG3QD46chl7SQmoLWyaOZwZzyZPHokLE9ACQeG9Uy6+8Zl5odtDSwkQbSLIncN3Zp/lnmpDwFe3lqonbf2XjJD4Dgmc5DbVcvvo18A2zbtHLC9PB2eouzxo4OcUhM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI0PR03MB11419.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(7416014)(10067099003)(56012099006)(11063799006)(4143699003)(6133799003)(3023799007)(18002099003)(22082099003)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bHlqRlRpcVVJRUp4OHpzRDdLdGVHV3RjdVBxbXRHRFZ5emJ6N3hRQW9POGx3?= =?utf-8?B?Zmh0eWIrSzdJSFBCMVJabWtDOXppUjZsTFJVWElIdDZMRzV3eWhra0MvajBt?= =?utf-8?B?ckVxUkNaR3RYeTJheG93andhVHFHRDlrZzdJbEpTVUFDbVV0U2dSQkxFNUg4?= =?utf-8?B?V3QvTE5HYkMxdnR0QjhiSjZYVnNnVVRKRTZIUk12ekx6UHBCdms2Nmcvaitr?= =?utf-8?B?VG1UVzg3OVo5clYrQTdJQ3RkQ3JvenVUTUpmdTJIZWZiQUlhU0EzZkwwUm1B?= =?utf-8?B?THRVVmtZVi9sKzRLdkZzVFNXWEhaUFJRYUlXaVZONTBXYXNQQ21vendlelBS?= =?utf-8?B?RG1CU2ZLRVF5cWx4NmhLUkwrdWlOZDdPa1pIOWFoZ09SQ0k5RE9wenZMcHdu?= =?utf-8?B?Ykt4dFVVVWlnS0U3V21ubDhMbkErRlFXU3lQd1dOSnp2TEgwb1JvQWwvOTJT?= =?utf-8?B?RjNhbXNLdktITi9TM1RUbTdPMlM1SkZlaHBFV1h3ZmI3bEhVYkdkSUkwU0Iw?= =?utf-8?B?S2VPOHFNSlk5eUlkbG95Ri9DVWs0N1MrQ0gxWHNldzNCOWp0YlNyUjlUVXJt?= =?utf-8?B?WDUvZW1kakNPbWR1eWplOEFmejJLN3ZCV28zR1J1VVRxWFlmYmFvWnExaGRP?= =?utf-8?B?VHZYRUgxZFRWdVVKRzBqdEx3bGlKSUNZQUdnNG9FRjh6RExCWElSYUErbUhu?= =?utf-8?B?WjlYOXFtRnM0TENuT1c3aUFQUUo4SlB4enVJdmJreCtBWnZXMGMvY0RvYUV1?= =?utf-8?B?aGJ2Z2NpK0NIOXlHWFhwRW1EMnJHV2IvVmtDTmxiOFpRdzYvRzJOczBReEpB?= =?utf-8?B?eUo4MlVWLy84OU9MKzh5TUYxaHBtcEVmaDJ3RlFFK1pLcXdnbm9scFVMTkpC?= =?utf-8?B?SGMwYXlGK25hZU0xMzZ3Vkx5UklyTkdybUhUaHNPVGJhS25XN2hIT01ieFc4?= =?utf-8?B?UktPRjBlbW1XOXB0STJ6RzNsTjdVUXBCdGtwSjl5c3FiZmFIUjQ5d3QxQjVr?= =?utf-8?B?eUhNYVhkSmx5a3BhSWJvMlNiVDhtRTE0QThqMDg0V2U5Y25iR0JETkpQYm1H?= =?utf-8?B?ZGt4UkxEY3RpL1IzQStZS1dicDBrdDI0dy9qbDFDNzZFVWd4TjQyUWVLdzFo?= =?utf-8?B?RlE0Z1VSM0JuOUgrWm5yei9wT25HV0tPR0tPZUM2bTRGa1EzcWFnNjRlUHlh?= =?utf-8?B?Wm5sdWFvZS9GcjNYbCszbS90S3cza2xHWCs1UmZhVHFlQytPR1lzeXdGbHgz?= =?utf-8?B?eUhrbytIemt4MCtodzZXeEtsdm5ZcHN1N2VENkdrb01sWjFETFU0d2d4Y28v?= =?utf-8?B?TE9TTlZrTTlpeVVIZnBjbFFQc0FVQjgzUCtISUMwQnNreE80bkpwS1JJZFpY?= =?utf-8?B?Z0dLTkVla0Z0Slo2akpuMUE0V3FvaU1vczlUNUxFa1B1TjBKd2g3cTJzdm9E?= =?utf-8?B?alh4MTNsVHc4QXYvU1p5SEthY3pTMG1pYmdBSzZudXZZYmFBL2lCbEpKam5y?= =?utf-8?B?R21yNG5QOGZDVFpwRnFvMlp4cWJLd21xTUxDZElnbVY3bzJMTmJ0Z3pFbGVS?= =?utf-8?B?RFdsWW9SV0JSck9MaE5lTWIrWDJ0UUxkaG9teC9XR0JVeVJKais2YmdwVkhW?= =?utf-8?B?SGRtZWxlc0JkZUptZTMzdU5VNmhoSmYweHM3RDJDNDUxQitNVllKSHUyeGRO?= =?utf-8?B?ZVAwYTRUVXZCbGtrTXNwL0NqSUlxbjNsMkpraFV0M3J6aWo5NzdESE5YSmRi?= =?utf-8?B?MVQ2cnEyVmxvYmowcytVRldYN0ZLSnhkL05YRUROU3VSSDgxRjFpRTE3RUJn?= =?utf-8?B?OGY5YUFuWXFMSXdLbyt2d3pQaTNiSFY3MmpEc1ZZcElCNC9KNjFjZTRqUVpC?= =?utf-8?B?TUM0bHVkODVzam8rQkxWNW9OTjVnd0dIWUU1b3haWXlUNzF3Z3lpaURvQTNq?= =?utf-8?B?YlA5ZSthTU95YTFLaFo4UHF1UXRNVmYzRmpFVjdwQTlLSHBsTG1JQzF0OFdn?= =?utf-8?B?MUh1UmpNcXUzMFJKcmJsemJQMXZwdndTMXBzOGx1cEtZUnVvdDgyKzhocEx6?= =?utf-8?B?MTFPVWFEcE5jYSsydWUyd3JMbDhXMGIxS1ZyUXRrb3FDOWJZSnZoWUpSZDFz?= =?utf-8?B?b2lEYjNUT1VNS3BUWHgrdUhuQVFlbzZUVkM4YjAzTDFqQUgrOGMxQXBiOWV1?= =?utf-8?B?MnZnSCtLaFpjQ1lkK0JIaitSZGxESWFPNEtXOGozYjFoT05wWEp5Y2NOMlUx?= =?utf-8?B?a2MrcHpGNVVqUmh3a0R5SGRiM3R4QnJXMkt4U05TeWNqdjRmWi9PZ3ZqZHB2?= =?utf-8?B?NzRKQVRIbHErdXk4WHpQaTV0RVpzd042TEZVSVgxa3lDaVViT1NXRXhwcnRv?= =?utf-8?Q?p5A87IKrZeibppXc=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI0PR03MB11419.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3836a7d-1a2a-460a-7d5b-08df1af24dd2 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2026 10:46:49.9327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PRVSFnS9GskC78+FNlEDJ4vHsBa5D8T5DitDRRVU8Q7fdDeiEQVfB6LwUO8Y7jDKwFhd+EDjIb5hPioFA/VvYe6j0PxCpqA4Y8CIR33pYRY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10583 X-purgate-ID: tlsNG-bad1c0/1790333212-FD86F034-7DF33B44/0/0 X-purgate-type: clean X-purgate-size: 23544 DQpPbiAyNC8wOS8yMDI2IDIxOjQyLCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4gSGkgT2xl a3NpaSwNCj4NCj4gT2xla3NpaSBNb2lzaWVpZXYgPE9sZWtzaWlfTW9pc2llaWV2QGVwYW0uY29t PiB3cml0ZXM6DQo+DQo+PiBPbiAyNC8wOS8yMDI2IDA0OjE1LCBWb2xvZHlteXIgQmFiY2h1ayB3 cm90ZToNCj4+PiBIaSBPbGVrc2lpLA0KPj4+DQo+Pj4gT2xla3NpaSBNb2lzaWVpZXYgPE9sZWtz aWlfTW9pc2llaWV2QGVwYW0uY29tPiB3cml0ZXM6DQo+Pj4NCj4+Pj4gT24gMjMvMDkvMjAyNiAw NDowMiwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+Pj4+PiBIaSBPbGVrc2lpLA0KPj4+Pj4N Cj4+Pj4+IE9sZWtzaWkgTW9pc2llaWV2IDxPbGVrc2lpX01vaXNpZWlldkBlcGFtLmNvbT4gd3Jp dGVzOg0KPj4+Pj4NCj4+Pj4+IFRoaXMgaXMgYSBncmVhdCBwaWVjZSBvZiBkb2N1bWVudGF0aW9u LiBJdCBpcyBsYXJnZXIgdGhhbiB0aGUgdGV4dCB5b3UNCj4+Pj4+IGFkZGVkIHRvIHRoZSAnZG9j JyBkaXJlY3RvcnkuIFNvIEkgYmVsaWV2ZSBpdCBpcyBiZXR0ZXIgdG8gcHV0IGludG8gYQ0KPj4+ Pj4gZGVzaWduIGRvY3VtZW50LCBzbyBpdCBpcyB3aWxsIG5vdCBiZSBsb3N0IGluIHRoZSBnaXQg Y29tbWl0IG1lc3NhZ2VzLg0KPj4+PiBIaSBWb2xvZHlteXIsDQo+Pj4+DQo+Pj4+IFRoYW5rIHlv dSBmb3IgYSBxdWljayByZXNwb25zZS4NCj4+Pj4NCj4+Pj4gSSd2ZSBqdXN0IHJlY2hla2VkIGRv Y3VtZW50IGluIHBhdGNoIDY6DQo+Pj4+IGRvY3MvaHlwZXJ2aXNvci1ndWlkZS9hcm0vZmlybXdh cmUvYXJtLXNjbWkucnN0IGFuZA0KPj4+Pg0KPj4+PiBjb21wYXJlZCBpdCB3aXRoIHRoZSBpbmZv cm1hdGlvbiBwcm92aWRlZCBpbiB0aGUgY29tbWl0IGRlc2NyaXB0aW9uLg0KPj4+Pg0KPj4+PiBB cyBJIGNhbiBzZWUgYWxsIGluZm9ybWF0aW9uIHByb3ZpZGVkIGluIHRoZSBkZXNjcmlwdGlvbiAo YWRkIHNjaGVtZXMNCj4+Pj4gYW5kIGR0cyBleGFtcGxlcyBhdCBsZWFzdCkNCj4+Pj4NCj4+Pj4g YXJlIHByZXNlbnQgaW4gdGhlIGRvY3VtZW50YXRpb24uIEFsc28gZG9jIGl0c2VsZiBpcyBtb3Jl IGRldGFpbGVkIHRoZW4NCj4+Pj4gdGhlIGNvbW1pdCBkZXNjcmlwdGlvbi4NCj4+Pj4NCj4+Pj4g TWF5YmUgSSBtaXNzZWQgc29tZXRoaW5nPw0KPj4+IEFoLCBzbyB5b3UgcHV0IHRoaXMgaW5mb3Jt YXRpb24gaW4gdGhlIGxhc3QgcGF0Y2ggaW4gdGhlIHNlcmllcy4gT2theSwNCj4+PiBzbyBJIG1p c3NlZCBpdC4NCj4+Pg0KPj4+Pj4+IFRoaXMgcGF0Y2ggaW50cm9kdWNlcyBTQ0kgZHJpdmVyIHRv IHN1cHBvcnQgZm9yIEFSTSBFTDMgVHJ1c3RlZCBGaXJtd2FyZS1BDQo+Pj4+Pj4gKFRGLUEpIHdo aWNoIHByb3ZpZGVzIFNDTUkgaW50ZXJmYWNlIHdpdGggbXVsdGktYWdlbnQgc3VwcG9ydCwgYXMg c2hvd24NCj4+Pj4+PiBiZWxvdy4NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+ICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4+Pj4+ICAgICAgfCBFTDMgVEYtQSBTQ01J ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4+Pj4+ICAgICAgKy0tLS0tLS0rLS0rLS0t LS0tLSstLSstLS0tLS0tKy0tKy0tLS0tLS0rKw0KPj4+Pj4+ICAgICAgfHNobWVtMSB8ICB8c2ht ZW0wIHwgIHxzaG1lbTIgfCAgfHNobWVtWCB8DQo+Pj4+Pj4gICAgICArLS0tLS0rLSsgICstLS0r LS0tKyAgKy0tKy0tLS0rICArLS0tKy0tLSsNCj4+Pj4+PiBzbWMtaWQxIHwgICAgICAgIHwgICAg ICAgICB8ICAgICAgICAgICB8DQo+Pj4+Pj4gYWdlbnQxICB8ICAgICAgICB8ICAgICAgICAgfCAg ICAgICAgICAgfA0KPj4+Pj4+ICAgICAgKy0tLS0tdi0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0t LS0tLSstLS0tKw0KPj4+Pj4+ICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAg ICAgIHwgICAgfA0KPj4+Pj4+ICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAg ICAgIHwgICAgfA0KPj4+Pj4+ICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0t LS0tLSstLS0tKw0KPj4+Pj4+ICAgICAgICAgICAgIHNtYy1pZDAgfCAgc21jLWlkMnwgICAgc21j LWlkWHwNCj4+Pj4+PiAgICAgICAgICAgICBhZ2VudDAgIHwgIGFnZW50MiB8ICAgIGFnZW50WCB8 DQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4+ Pj4+ICAgICAgICAgICAgICAgICstLS0tdi0tLSsgICstLXYtLS0tLSsgICstLXYtLS0tLSsNCj4+ Pj4+PiAgICAgICAgICAgICAgICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+ Pj4+Pj4gICAgICAgICAgICAgICAgfCBEb20wICAgfCAgfCBEb20xICAgfCAgfCBEb21YICAgfA0K Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgICAgICAgIHwgIHwgICAgICAgIHwgIHwgICAgICAgIHwN Cj4+Pj4+PiAgICAgICAgICAgICAgICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8 DQo+Pj4+Pj4gICAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgKy0tLS0tLS0tKyAgKy0tLS0tLS0t Kw0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIEVMMyBTQ01JIG11bHRpLWFnZW50IGZpcm13YXJlIGlzIGV4 cGVjdGVkIHRvIHByb3ZpZGUgU0NNSSBTTUMgc2hhcmVkDQo+Pj4+Pj4gbWVtb3J5IHRyYW5zcG9y dCBmb3IgZXZlcnkgQWdlbnQgaW4gdGhlIHN5c3RlbS4NCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBTQ01J IEFnZW50IHRyYW5zcG9ydCBjaGFubmVsIGRlZmluZWQgYnkgcGFpcjoNCj4+Pj4+PiAgICAgLSBz bWMtaWQ6IFNNQyBpZCB1c2VkIGZvciBEb29yYmVsbA0KPj4+Pj4+ICAgICAtIHNobWVtOiBzaGFy ZWQgbWVtb3J5IGZvciBtZXNzYWdlcyB0cmFuc2ZlciwgWGVuIHBhZ2UNCj4+Pj4+PiAgICAgYWxp Z25lZC4gU2hhcmVkIG1lbW9yeSBpcyBtYXBwZWQgd2l0aCB0aGUgZm9sbG93aW5nIGZsYWdzOg0K Pj4+Pj4+ICAgICBNVF9ERVZJQ0VfbkduUkUuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgZm9sbHdvaW5n IFNDTUkgQWdlbnRzIGFyZSBleHBlY3RlZCB0byBiZSBkZWZpbmVkIGJ5IFNDTUkgRlcgdG8gZW5h YmxlIFNDTUkNCj4+Pj4+PiBtdWx0aS1hZ2VudCBmdW5jdGlvbmFsaXR5IHVuZGVyIFhlbjoNCj4+ Pj4+PiAtIFhlbiBtYW5hZ2VtZW50IGFnZW50OiB0cnVzdGVkIGFnZW50cyB0aGF0IGFjY2Vzc2Vz IHRvIHRoZSBCYXNlIFByb3RvY29sDQo+Pj4+Pj4gY29tbWFuZHMgdG8gY29uZmlndXJlIGFnZW50 IHNwZWNpZmljIHBlcm1pc3Npb25zDQo+Pj4+Pj4gLSBPU1BNIFZNIGFnZW50czogbm9uLXRydXN0 ZWQgYWdlbnQsIG9uZSBmb3IgZWFjaCBHdWVzdCBkb21haW4gd2hpY2ggaXMNCj4+Pj4+PiAgICAg IGFsbG93ZWQgZGlyZWN0IEhXIGFjY2Vzcy4gQXQgbGVhc3Qgb25lIE9TUE0gVk0gYWdlbnQgaGFz IHRvIGJlIHByb3ZpZGVkDQo+Pj4+Pj4gICAgICBieSBGVyBpZiBIVyBpcyBoYW5kbGVkIG9ubHkg YnkgRG9tMCBvciBEcml2ZXIgRG9tYWluLg0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIEVMMyBTQ01JIEZX IGlzIGV4cGVjdGVkIHRvIGltcGxlbWVudCBmb2xsb3dpbmcgQmFzZSBwcm90b2NvbCBtZXNzYWdl czoNCj4+Pj4+PiAtIEJBU0VfRElTQ09WRVJfQUdFTlQgKG9wdGlvbmFsIGlmIGFnZW50X2lkIHdh cyBwcm92aWRlZCkNCj4+Pj4+PiAtIEJBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTiAob3B0 aW9uYWwpDQo+Pj4+Pj4gLSBCQVNFX1NFVF9ERVZJQ0VfUEVSTUlTU0lPTlMgKG9wdGlvbmFsKQ0K Pj4+Pj4+DQo+Pj4+Pj4gVGhlIFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIgaW1wbGVt ZW50cyBmb2xsb3dpbmcNCj4+Pj4+PiBmdW5jdGlvbmFsaXR5Og0KPj4+Pj4+IC0gVGhlIGRyaXZl ciBpcyBpbml0aWFsaXplZCBmcm9tIHRoZSBYZW4gU0NNSSBjb250YWluZXIgYGB4ZW5fc2NtaV9j b25maWdgYA0KPj4+Pj4+ICAgICAgKGNvbXBhdGlibGUgYGB4ZW4sc2NpYGApIHBsYWNlZCB1bmRl ciBgYC9jaG9zZW4veGVuYGAuIE9ubHkgdGhlDQo+Pj4+Pj4gICAgICBgYGFybSxzY21pLXNtY2Bg IG5vZGUgdGhhdCBpcyBhIGNoaWxkIG9mIHRoaXMgY29udGFpbmVyIHdpbGwgYmluZCB0byBYZW47 DQo+Pj4+Pj4gICAgICBvdGhlciBTQ01JIG5vZGVzIChmb3IgZXhhbXBsZSB1bmRlciBgYC9maXJt d2FyZWBgKSBhcmUgaWdub3JlZCB0byBhdm9pZA0KPj4+Pj4+ICAgICAgc3RlYWxpbmcgdGhlIGhv c3QgT1NQTSBpbnN0YW5jZS4NCj4+Pj4+Pg0KPj4+Pj4+IHNjbWlfc2htXzE6IHNyYW1ANDdmZjEw MDAgew0KPj4+Pj4+ICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsN Cj4+Pj4+PiAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEwMDA+Ow0K Pj4+Pj4+IH07DQo+Pj4+Pj4gc2NtaV94ZW46IHNjbWkgew0KPj4+Pj4+ICAgICAgICAgICAgY29t cGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4+Pj4+ICAgICAgICAgICAgYXJtLHNtYy1pZCA9 IDwweDgyMDAwMDAzPjsgPC0tLSBYZW4gbWFuYWdlbWVudCBhZ2VudCBzbWMtaWQNCj4+Pj4+PiAg ICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPCAxPjsNCj4+Pj4+PiAgICAgICAgICAgICNzaXpl LWNlbGxzID0gPCAwPjsNCj4+Pj4+PiAgICAgICAgICAgICNhY2Nlc3MtY29udHJvbGxlci1jZWxs cyA9IDwgMT47DQo+Pj4+Pj4gICAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMT47IDwtLS0g WGVuIG1hbmFnZW1lbnQgYWdlbnQgc2htZW0NCj4+Pj4+PiB9Ow0KPj4+Pj4+DQo+Pj4+Pj4gLSBU aGUgZHJpdmVyIG9idGFpbnMgWGVuIHNwZWNpZmljIFNDTUkgQWdlbnQncyBjb25maWd1cmF0aW9u IGZyb20gdGhlDQo+Pj4+Pj4gICAgICBIb3N0IERULCBwcm9iZXMgQWdlbnRzIGFuZCBidWlsZHMg U0NNSSBBZ2VudHMgbGlzdC4gVGhlIEFnZW50cw0KPj4+Pj4+ICAgICAgY29uZmlndXJhdGlvbiBp cyB0YWtlbiBmcm9tICJzY21pLXNlY29uZGFyeS1hZ2VudHMiIHByb3BlcnR5IHdoZXJlDQo+Pj4+ Pj4gICAgICBmaXJzdCBpdGVtIGlzICJhcm0sc21jLWlkIiwgc2Vjb25kIC0gImFybSxzY21pLXNo bWVtIiBwaGFuZGxlIGFuZA0KPj4+Pj4+ICAgICAgdGhpcmQgaXMgb3B0aW9uYWwgImFnZW50X2lk IjoNCj4+Pj4+Pg0KPj4+Pj4+IC8gew0KPj4+Pj4+ICAgICAgY2hvc2VuIHsNCj4+Pj4+PiAgICAg ICAgeGVuIHsNCj4+Pj4+PiAgICAgICAgICByYW5nZXM7DQo+Pj4+Pj4gICAgICAgICAgeGVuX3Nj bWlfY29uZmlnIHsNCj4+Pj4+PiAgICAgICAgICAgIGNvbXBhdGlibGUgPSAieGVuLHNjaSI7DQo+ Pj4+Pj4gICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwyPjsNCj4+Pj4+PiAgICAgICAgICAg ICNzaXplLWNlbGxzID0gPDI+Ow0KPj4+Pj4+ICAgICAgICAgICAgcmFuZ2VzOw0KPj4+Pj4+DQo+ Pj4+Pj4gCXNjbWktc2Vjb25kYXJ5LWFnZW50cyA9IDwNCj4+Pj4+PiAgICAgICAgICAgICAgMHg4 MjAwMDAwMiAmc2NtaV9zaG1fMCAwDQo+Pj4+Pj4gICAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNj bWlfc2htXzIgMg0KPj4+Pj4+ICAgICAgICAgICAgICAweDgyMDAwMDA1ICZzY21pX3NobV8zIDM+ OyA8LS0tIGZ1bmNfaWQsIHNobWVtLCBhZ2VudF9pZA0KPj4+Pj4+ICAgICAgICAgICAgI3NjbWkt c2Vjb25kYXJ5LWFnZW50cy1jZWxscyA9IDwzPjsNCj4+Pj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCB0 aGlzIGlzIHRoZSBjb3JyZWN0IHdheSBvZiB1c2luZyAtY2VsbHMgcHJvcGVydHkuDQo+Pj4+Pg0K Pj4+Pj4gVGhlc2UgcHJvcGVydGllcyBhcmUgdXNlZCBlaXRoZXIgdG8gcHJvdmlkZSBpbmZvcm1h dGlvbiBmb3IgKipjaGlsZCoqIG5vZGVzDQo+Pj4+PiAobGlrZSAjYWRkcmVzcy1jZWxscyBvciAj c2l6ZS1jZWxscykgb3IgdG8gcHJvdmlkZSBhIG51bWJlciBvZiBjZWxscyB0bw0KPj4+Pj4gZW5j b2RlIGEgc3BlY2lmaWVyIGZvciBhIGRvbWFpbiAobGlrZSAjaW50ZXJydXB0LWNlbGxzKS4NCj4+ Pj4+DQo+Pj4+PiBIZXJlIHlvdSBhcmUgZG9pbmcgbmVpdGhlciBvZiB0aGVzZS4gSSB0aGluayB0 aGUgcHJvcGVyIHdheSBpcyB0byBkZWZpbmUNCj4+Pj4+IHNlY29uZGFyeSBhZ2VudHMgYXMgY2hp bGRyZW46DQo+Pj4+Pg0KPj4+Pj4gYWdlbnRzIHsNCj4+Pj4+ICAgICAgICAgICAgI2FkZHJlc3Mt Y2VsbHMgPSAxOw0KPj4+Pj4gICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDA7DQo+Pj4+PiAgICAg ICAgICAgICBzY21pX2FnZW50XzI6IHNjbWlfYWdlbnRAMiB7DQo+Pj4+PiAgICAgICAgICAgICAg IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktYWdlbnQiOyAgLy8gQWN0dWFsbHksIEkgYW0gbm90IHN1 cmUgaWYNCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAvLyB3ZSBhbGxvd2VkIHRvIHVzZSAnYXJtJyBuYW1lc3BhY2UNCj4+Pj4+DQo+Pj4+PiAgICAg ICAgICAgICAgIHJlZyA9IDwyPjsgICAgICAgICAgICAgICAgICAgICAgLy8gQWdlbnQgaWQgZ29l cyBoZXJlDQo+Pj4+PiAgICAgICAgICAgICAgIHNobW1lbSA9ICZzY21pX3NobV8yOw0KPj4+Pj4g ICAgICAgICAgICAgICBhcm0sc21jLWlkID0gMHg4MjAwMDAwNDsNCj4+Pj4+ICAgICAgICAgICAg IH07DQo+Pj4+PiB9DQo+Pj4+Pg0KPj4+Pj4gV2l0aCB0aGlzIGFwcHJvYWNoIHlvdSBkb24ndCBu ZWVkICNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMgYXQgYWxsDQo+Pj4+PiBhbmQgdGhlIHdo b2xlIHN0cnVjdHVyZSBiZWNvbWVzIG1vcmUgZGV2aWNlLXRyZWUtaXNoLg0KPj4+PiBUaGFuayB5 b3UgZm9yIGxvb2tpbmcgYXQgdGhpcy4gSSBhZ3JlZSB0aGF0IHRoZSB0d28gY2FzZXMgeW91IGxp c3QgYXJlDQo+Pj4+IHRoZSBtb3N0IGNvbW1vbiBvbmVzLCBidXQgdGhleSBhcmUgbm90IHRoZSBv bmx5IHNhbmN0aW9uZWQgb25lczogdGhlcmUgaXMgYQ0KPj4+PiB0aGlyZCwgbG9uZy1zdGFuZGlu ZyBwYXR0ZXJuIHdoZXJlIGEgIiM8bmFtZT4tY2VsbHMiIHByb3BlcnR5IGluIGEgbm9kZQ0KPj4+ PiBkZWNsYXJlcyB0aGUgY2VsbCBzdHJpZGUgb2YgYSAqbm9uLXBoYW5kbGUgbGlzdCBwcm9wZXJ0 eSBpbiB0aGF0IHZlcnkgc2FtZQ0KPj4+PiBub2RlKi4gVGhhdCBpcyBleGFjdGx5IHdoYXQgIiNz Y21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMiIGRvZXMgZm9yDQo+Pj4+ICJzY21pLXNlY29uZGFy eS1hZ2VudHMiLiBTb21lIGV2aWRlbmNlIGZyb20gdGhlIERldmljZXRyZWUgU3BlY2lmaWNhdGlv biBhbmQNCj4+Pj4gZnJvbSBMaW51eDoNCj4+Pj4NCj4+Pj4gMSkgInJhbmdlcyIgYW5kICJpbnRl cnJ1cHQtbWFwIiBhcmUgcGFyc2VkIHdpdGggdGhlIGNlbGwgY291bnRzIG9mIHRoZSBub2RlDQo+ Pj4+ICAgIMKgIMKgdGhhdCBjYXJyaWVzIHRoZW0sIG5vdCBvZiBhIGNoaWxkIG9yIG9mIGEgcGhh bmRsZSB0YXJnZXQuDQo+Pj4+DQo+Pj4+ICAgIMKgIMKgZHRjIGVuZm9yY2VzIHRoaXMgaXRzZWxm Og0KPj4+Pg0KPj4+PiAgICDCoCDCoC0gc2NyaXB0cy9kdGMvY2hlY2tzLmM6Nzg1IGNoZWNrX3Jh bmdlc19mb3JtYXQoKSBjb21wdXRlcyB0aGUgZW50cnkNCj4+Pj4gbGVuZ3RoDQo+Pj4+ICAgIMKg IMKgIMKgYXMgKHBhcmVudCAjYWRkcmVzcy1jZWxscyArIHRoaXMgbm9kZSdzICNhZGRyZXNzLWNl bGxzICsgdGhpcyBub2RlJ3MNCj4+Pj4gICAgwqAgwqAgwqAjc2l6ZS1jZWxscykgYW5kIHZhbGlk YXRlcyB0aGUgbGVuZ3RoIG9mICJyYW5nZXMiIGluIHRoaXMgbm9kZQ0KPj4+PiBhZ2FpbnN0IGl0 Lg0KPj4+Pg0KPj4+PiAgICDCoCDCoC0gc2NyaXB0cy9kdGMvY2hlY2tzLmM6MTYwMSBjaGVja19p bnRlcnJ1cHRfbWFwKCk6DQo+Pj4+DQo+Pj4+ICAgIMKgIMKgIMKgIMKgIMKgY2VsbHNpemUgPSBu b2RlX2FkZHJfY2VsbHMobm9kZSk7DQo+Pj4+ICAgIMKgIMKgIMKgIMKgIMKgY2VsbHNpemUgKz0g cHJvcHZhbF9jZWxsKGdldF9wcm9wZXJ0eShub2RlLCAiI2ludGVycnVwdC1jZWxscyIpKTsNCj4+ Pj4NCj4+Pj4gICAgwqAgwqAgwqBpLmUuIHRoZSBzdHJpZGUgb2YgdGhlICJpbnRlcnJ1cHQtbWFw IiBlbnRyaWVzIGluIGEgbm9kZSBpcyB0YWtlbiBmcm9tDQo+Pj4+ICAgIMKgIMKgIMKgIiNhZGRy ZXNzLWNlbGxzIiBhbmQgIiNpbnRlcnJ1cHQtY2VsbHMiICpvZiB0aGF0IHNhbWUgbm9kZSouIExp bnV4DQo+Pj4+IGRvZXMNCj4+Pj4gICAgwqAgwqAgwqB0aGUgc2FtZSBpbiBkcml2ZXJzL29mL2ly cS5jLg0KPj4+Pg0KPj4+PiAgICDCoCDCoFNvICJhICMqLWNlbGxzIHByb3BlcnR5IGluIG5vZGUg WCBkZXNjcmliaW5nIHRoZSBsYXlvdXQgb2YgYSBwcm9wZXJ0eSBpbg0KPj4+PiAgICDCoCDCoG5v ZGUgWCIgaXMgbm90IGFuIGFidXNlIG9mIHRoZSBjb252ZW50aW9uLCBpdCBpcyBob3cgdHdvIG9m IHRoZSBjb3JlDQo+Pj4+ICAgIMKgIMKgRGV2aWNldHJlZSBTcGVjaWZpY2F0aW9uIHByb3BlcnRp ZXMgYXJlIGRlZmluZWQuDQo+Pj4+DQo+Pj4+IDIpIFRoZXJlIGlzIGEgcHJlY2VkZW50IHdob3Nl IHNoYXBlIGlzIGlkZW50aWNhbCB0byBvdXJzIC0gYSB2ZW5kb3IgcHJvcGVydHkNCj4+Pj4gICAg wqAgwqBob2xkaW5nIGEgbGlzdCwgcGx1cyBjZWxscyBwcm9wZXJ0aWVzIGluIHRoZSBzYW1lIG5v ZGUgdGhhdCBkZXNjcmliZQ0KPj4+PiBob3cgdG8NCj4+Pj4gICAgwqAgwqBkZWNvZGUgaXQ6DQo+ Pj4+DQo+Pj4+ICAgIMKgIMKgRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3RwbS9p Ym0sdnRwbS55YW1sOjM2DQo+Pj4+DQo+Pj4+ICAgIMKgIMKgIMKgIMKgaWJtLCNkbWEtYWRkcmVz cy1jZWxsczoNCj4+Pj4gICAgwqAgwqAgwqAgwqAgwqBkZXNjcmlwdGlvbjoNCj4+Pj4gICAgwqAg wqAgwqAgwqAgwqAgwqBudW1iZXIgb2YgY2VsbHMgdGhhdCBhcmUgdXNlZCB0byBlbmNvZGUgdGhl IHBoeXNpY2FsIGFkZHJlc3MNCj4+Pj4gZmllbGQNCj4+Pj4gICAgwqAgwqAgwqAgwqAgwqAgwqBv ZiBkbWEtd2luZG93IHByb3BlcnRpZXMNCj4+Pj4gICAgwqAgwqAgwqAgwqBpYm0sI2RtYS1zaXpl LWNlbGxzOg0KPj4+PiAgICDCoCDCoCDCoCDCoCDCoGRlc2NyaXB0aW9uOg0KPj4+PiAgICDCoCDC oCDCoCDCoCDCoCDCoG51bWJlciBvZiBjZWxscyB0aGF0IGFyZSB1c2VkIHRvIGVuY29kZSB0aGUg c2l6ZSBmaWVsZCBvZg0KPj4+PiAgICDCoCDCoCDCoCDCoCDCoCDCoGRtYS13aW5kb3cgcHJvcGVy dGllcw0KPj4+PiAgICDCoCDCoCDCoCDCoGlibSxteS1kbWEtd2luZG93Og0KPj4+PiAgICDCoCDC oCDCoCDCoCDCoGRlc2NyaXB0aW9uOiBETUEgd2luZG93IGFzc29jaWF0ZWQgd2l0aCB0aGlzIHZp cnR1YWwgSS9PIEFkYXB0ZXINCj4+Pj4NCj4+Pj4gICAgwqAgwqBhbmQgdGhlIGV4YW1wbGUgKHNh bWUgZmlsZSwgbGluZXMgOTYtOTgpOg0KPj4+Pg0KPj4+PiAgICDCoCDCoCDCoCDCoGlibSwjZG1h LWFkZHJlc3MtY2VsbHMgPSA8MHgyPjsNCj4+Pj4gICAgwqAgwqAgwqAgwqBpYm0sI2RtYS1zaXpl LWNlbGxzID0gPDB4Mj47DQo+Pj4+ICAgIMKgIMKgIMKgIMKgaWJtLG15LWRtYS13aW5kb3cgPSA8 MHgxMDAwMDAwMyAweDAgMHgwIDB4MCAweDEwMDAwMDAwPjsNCj4+Pj4NCj4+Pj4gICAgwqAgwqBC b3RoIGNlbGxzIHByb3BlcnRpZXMgYXJlICJyZXF1aXJlZCIuIFRoZSBwYXJzZXIgaXMNCj4+Pj4g ICAgwqAgwqBhcmNoL3Bvd2VycGMva2VybmVsL3Byb21fcGFyc2UuYzoxMSBvZl9wYXJzZV9kbWFf d2luZG93KCksIHdoaWNoIHJlYWRzDQo+Pj4+ICAgIMKgIMKgImlibSwjZG1hLWFkZHJlc3MtY2Vs bHMiIGFuZCAiaWJtLCNkbWEtc2l6ZS1jZWxscyIgZnJvbSB0aGUgc2FtZQ0KPj4+PiBub2RlICJk biINCj4+Pj4gICAgwqAgwqB0byB3YWxrICJpYm0sbXktZG1hLXdpbmRvdyIuIFRoZXJlIGlzIG5v IHBoYW5kbGUgYW5kIG5vIGNoaWxkIG5vZGUNCj4+Pj4gICAgwqAgwqBpbnZvbHZlZDsgdGhpcyBp cyBleGFjdGx5IHRoZSAic2VsZi1kZXNjcmliaW5nIGxpc3QgcHJvcGVydHkiIHBhdHRlcm4uDQo+ Pj4+DQo+Pj4+IDMpIEEgIiMqLWNlbGxzIiBwcm9wZXJ0eSBkb2VzIG5vdCBoYXZlIHRvIGRlc2Ny aWJlIGEgcGhhbmRsZSBzcGVjaWZpZXINCj4+Pj4gYXQgYWxsOg0KPj4+Pg0KPj4+PiAgICDCoCDC oC0gIiNwaW5jdHJsLWNlbGxzIiAoRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3Bp bmN0cmwvDQo+Pj4+ICAgIMKgIMKgIMKgcGluY3RybC1zaW5nbGUueWFtbDo1NSkgZ2l2ZXMgdGhl IG51bWJlciBvZiBjZWxscyBwZXIgZW50cnkgb2YgdGhlDQo+Pj4+IHBsYWluDQo+Pj4+ICAgIMKg IMKgIMKgInBpbmN0cmwtc2luZ2xlLHBpbnMiIHByb3BlcnR5OyBkcml2ZXJzL3BpbmN0cmwvZGV2 aWNldHJlZS5jOjI5Nw0KPj4+PiAgICDCoCDCoCDCoHBpbmN0cmxfZmluZF9jZWxsc19zaXplKCkg bG9va3MgaXQgdXAgaW4gdGhlIHBhcmVudC9ncmFuZHBhcmVudCBub2RlLg0KPj4+PiAgICDCoCDC oCDCoE5vIHBoYW5kbGUgc3BlY2lmaWVyIGlzIGludm9sdmVkLg0KPj4+Pg0KPj4+PiAgICDCoCDC oC0gIiNpbmRleC1jZWxscyINCj4+Pj4gKERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5n cy91c2IvZnNsLHVzYm1pc2MueWFtbDo1NikNCj4+Pj4gICAgwqAgwqAgwqBpcyBub3QgYSBzcGVj aWZpZXIgZm9yIGFueSBkb21haW4gZWl0aGVyLg0KPj4+Pg0KPj4+PiBTbyB0aGUgY29udmVudGlv biBpbiBwcmFjdGljZSBpcyAiYSAjPGZvbz4tY2VsbHMgcHJvcGVydHkgc3RhdGVzIGhvdw0KPj4+ PiBtYW55IGNlbGxzDQo+Pj4+IG9uZSA8Zm9vPiBlbnRyeSBvY2N1cGllcyIsIGFuZCB0aGUgZW50 cmllcyBtYXkgbGl2ZSBpbiBhIGNoaWxkIG5vZGUncw0KPj4+PiBwcm9wZXJ0eQ0KPj4+PiAoI2Fk ZHJlc3MtY2VsbHMpLCBpbiBhIGNvbnN1bWVyJ3MgcGhhbmRsZSBzcGVjaWZpZXIgKCNpbnRlcnJ1 cHQtY2VsbHMsDQo+Pj4+ICNjbG9jay1jZWxscyksIG9yIGluIGEgcHJvcGVydHkgb2YgdGhlIGRl Y2xhcmluZyBub2RlIGl0c2VsZiAocmFuZ2VzLA0KPj4+PiBpbnRlcnJ1cHQtbWFwLCBpYm0sbXkt ZG1hLXdpbmRvdykuIE91ciB1c2FnZSBmYWxscyBpbnRvIHRoZSB0aGlyZCBncm91cC4NCj4+Pj4N Cj4+Pj4gVGhpcyBicmluZyB1cyB0byB0aGUgZm9sbG93aW5nIGNvbmNsdXNpb24gdGhhdA0KPj4+ PiAjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzIHVzYWdlDQo+Pj4+IGRvZXNuJ3QgdGVjaG5p Y2FsbHkgYnJlYWsgdGhlIGRldmljZS10cmVlIGNvbnZlbnRpb24gd2l0aCAyIGV4Y2VwdGlvbnM6 DQo+Pj4+DQo+Pj4+IGEpIFZlbmRvciBwcmVmaXguIERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9i aW5kaW5ncy93cml0aW5nLWJpbmRpbmdzLnJzdDo2OA0KPj4+PiAgICDCoCDCoHNheXMgIkRPIHVz ZSBhIHZlbmRvciBwcmVmaXggb24gZGV2aWNlLXNwZWNpZmljIHByb3BlcnR5IG5hbWVzIiwgYW5k IGFsbA0KPj4+PiAgICDCoCDCoHRoZSBzYW1lLW5vZGUgcHJlY2VkZW50cyBhYm92ZSBhcmUgdmVu ZG9yLXByZWZpeGVkDQo+Pj4+ICgiaWJtLCNkbWEtYWRkcmVzcy1jZWxscyIpLg0KPj4+PiAgICDC oCDCoEJvdGggb2Ygb3VyIHByb3BlcnRpZXMgYXJlIFhlbi1zcGVjaWZpYyBhbmQgbGl2ZSB1bmRl ciAvY2hvc2VuL3hlbiwNCj4+Pj4gc28gaWYgd2UNCj4+Pj4gICAgwqAgwqBrZWVwIHRoZSBmbGF0 IGZvcm0gdGhleSBzaG91bGQgYmVjb21lICJ4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIiBhbmQN Cj4+Pj4gICAgwqAgwqAieGVuLCNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMiLg0KPj4+Pg0K Pj4+PiBiKSBFbnRyeSBsYXlvdXQuIEluIG91ciBsaXN0IHRoZSBwaGFuZGxlIGlzIHRoZSBzZWNv bmQgY2VsbA0KPj4+PiAgICDCoCDCoCg8c21jLWlkICZzaG1lbSBhZ2VudC1pZD4pLCB3aGljaCBw cmV2ZW50cyB0aGUgdXNlIG9mIHRoZSBzdGFuZGFyZA0KPj4+PiAgICDCoCDCoHBoYW5kbGUtYXJy YXkgaGVscGVycyAtIHRoZXkgYWxsIGV4cGVjdCB0aGUgcGhhbmRsZSBmaXJzdC4gSWYgd2UNCj4+ Pj4ga2VlcCB0aGUNCj4+Pj4gICAgwqAgwqBmbGF0IGZvcm0sIHJlb3JkZXJpbmcgdG8gPCZzaG1l bSBzbWMtaWQgYWdlbnQtaWQ+IHdvdWxkIGxldCB0aGUNCj4+Pj4gcHJvcGVydHkgYmUNCj4+Pj4g ICAgwqAgwqBwYXJzZWQgYXMgYW4gb3JkaW5hcnkgcGhhbmRsZS1hcnJheS4NCj4+Pj4NCj4+Pj4g QXMgZm9yIHlvdXIgcHJvcG9zYWw6IHRoZSBjaGlsZC1ub2RlIGZvcm0geW91IHN1Z2dlc3QgaXMg Y2VydGFpbmx5DQo+Pj4+IG1vcmUgaWRpb21hdGljLCBpdCBtYWtlcyB0aGUgYWdlbnQgaWQgYW4g YWRkcmVzc2FibGUgInJlZyIgYW5kIGl0DQo+Pj4+IHJlbW92ZXMgdGhlDQo+Pj4+IG9wdGlvbmFs IDItdnMtMy1jZWxscyB2YXJpYW50IGFsdG9nZXRoZXIuIE15IG9ubHkgcmVzZXJ2YXRpb25zIGFy ZSB0aGF0DQo+Pj4+IGl0IGdyb3dzDQo+Pj4+IHRoZSBYZW4gRFQgcGFyc2VyIChub2RlIGl0ZXJh dGlvbiBpbnN0ZWFkIG9mIGEgc2luZ2xlIHByb3BlcnR5IHdhbGspIGFuZA0KPj4+PiB0aGF0IHRo ZQ0KPj4+PiBjb21wYXRpYmxlIHN0cmluZyB3b3VsZCBuZWVkIGEgbmFtZXNwYWNlIHdlIG93biAo InhlbixzY21pLWFnZW50IiByYXRoZXINCj4+Pj4gdGhhbg0KPj4+PiAiYXJtLHNjbWktYWdlbnQi LCBhcyB5b3UgY29ycmVjdGx5IHN1c3BlY3RlZCkuDQo+Pj4+DQo+Pj4+IFNvIEkgZG8gbm90IHRo aW5rIHRoZSBjdXJyZW50IGZvcm0gaXMgaW52YWxpZCwgYnV0IEkgaGF2ZSBubyBvYmplY3Rpb24g dG8NCj4+Pj4gbW92aW5nIHRvIGNoaWxkIG5vZGVzIGlmIHlvdSBwcmVmZXIgaXQuIFBsZWFzZSBs ZXQgbWUga25vdyB3aGljaCB3YXkgeW91DQo+Pj4+IHdvdWxkDQo+Pj4+IGxpa2UgbWUgdG8gZ28g Zm9yIHYxNCBhbmQgSSB3aWxsIHJlc3BpbiBhY2NvcmRpbmdseS4NCj4+PiBZZXMsIEkgdGhpbmsg bW9yZSBpZGlvbWF0aWMgZm9ybWF0IGlzIGJldHRlci4gQWxzbywgeW91IG5lZWQgdG8gd3JpdGUg YQ0KPj4+IHBhcnNlciBvbmNlLCBidXQgdXNlcnMgd2lsbCB3cml0ZSBkZXZpY2UgdHJlZSBtb3Jl IG9mdGVuLg0KPj4+DQo+Pj4gVGhlIHNlY29uZCB0aGluZyB0aGF0IGJvdGhlcnMgbWUgaXMgdGhl IHNoYXJlZCBtZW1vcnkgbm9kZXMgaW5zaWRlIHRoZQ0KPj4+IHhlbl9zY21pX2NvbmZpZyBub2Rl LiBJIGJlbGlldmUgdGhleSBzaG91bGQgYmVsb25nIHRvIHJlc2VydmVkX21lbW9yeSwgbm8/DQo+ PiBEdXJpbmcgZGlzY3Vzc2lvbnMgb24gdGhlIHByZXZpb3VzIHZlcnNpb25zLCBpdCB3YXMgZGVj aWRlZCB0aGF0IHRoZQ0KPj4gbWFpbiBnb2FsIGlzIHRvIGxlYXZlIHRoZSBvcmlnaW5hbCBkZXZp Y2UtdHJlZSB1bnRvdWNoZWQgYW5kIHB1dCBhbGwNCj4+IFhlbi1yZWxhdGVkIGNvbnRlbnQgaW50 byB0aGUgeGVuIG5vZGUuIFRoYXQncyB3aHkgd2UgcHJlc2VydmUgdGhlDQo+PiBvcmlnaW5hbCBE VFMgc3RydWN0dXJlLCBzdWNoIGFzIHRoZSBzY21pX3NobV8wIGFuZCAvZmlybXdhcmUvc2NtaSBu b2Rlcy4NCj4+DQo+PiBBbHNvLCBpZiB5b3UgdGFrZSBhIGxvb2sgYXQgdGhlIGFybSxzY21pLnlh bWwgZmlsZSBpbiB0aGUgTGludXgga2VybmVsLA0KPj4gdGhlcmUgaXMgbm8gZXhwbGljaXQgcmVx dWlyZW1lbnQgcmVnYXJkaW5nIHRoZSBleGFjdCBwbGFjZW1lbnQgb2YgdGhlDQo+PiBzY21pLXNo bWVtIG5vZGUuIEFzIGNhbiBiZSBzZWVuLCBhcm0sc2NtaS1zaG1lbSBpcyBwcmVzZW50IGluIHRo ZQ0KPj4gcGF0dGVyblByb3BlcnRpZXMgb2Ygc3JhbS55YW1sLCBidXQgc29tZSBEVFMgZmlsZXMg cGxhY2UgaXQgaW50bw0KPj4gcmVzZXJ2ZWQtbWVtb3J5IGluc3RlYWQuDQo+Pg0KPj4gTXkgbWFp biBwb2ludCBpcyB0aGF0IHdlIGRvbid0IHRvdWNoIHRoZSBvcmlnaW5hbCBkZXZpY2UtdHJlZSDi gJQgd2UNCj4+IHNpbXBseSBhZGQgdGhlIHhlbiBub2RlIGFuZCBwdXQgYWxsIHRoZSByZXF1aXJl ZCBwcm9wZXJ0aWVzIGluc2lkZSBpdC4NCj4gT2theSwgYnV0IFhlbiBzaG91bGQga25vdyBhYm91 dCByZXNlcnZlZCBtZW1vcnksIHJpZ2h0PyBTbywgaXQgaXMgb25seQ0KPiBmYWlyIHRvIGhhdmUg c2hhcmVkIG1lbW9yeSBub2RlcyBpbiAvcmVzZXJ2ZWQtbWVtb3J5LyBhcyBkZXZpY2UgdHJlZQ0K PiBzcGVjIHN1Z2dlc3RzLg0KPj4gSWYgd2Ugd2VyZSB0byBwbGFjZSBzaG1lbSBpbnRvIHNyYW0g b3IgcmVzZXJ2ZWQtbWVtb3J5LCBpdCB3b3VsZCBnaXZlIHVzDQo+PiB0aGUgZm9sbG93aW5nIHN0 cnVjdHVyZToNCj4+DQo+PiAvIHsNCj4+DQo+PiAgIMKgIMKgIMKgeGVuIHsNCj4+DQo+PiAgIMKg IMKgIMKgIMKgIMKgPHNyYW18cmVzZXJ2ZWQtbWVtb3J5Pjogew0KPj4NCj4+ICAgwqAgwqAgwqAg wqAgwqAgwqAgwqBzY21pX3NobTAgLi4uDQo+Pg0KPj4gICDCoCDCoCDCoCDCoCDCoCDCoCAuLi4u DQo+Pg0KPj4gICDCoCDCoCDCoCDCoCDCoCDCoCBzY21pX3NobVggLi4uDQo+Pg0KPj4gICDCoCDC oCDCoCDCoCDCoH0NCj4+DQo+PiAgIMKgIMKgIMKgfQ0KPj4NCj4+IH0NCj4+DQo+PiBUaGlzIHdv dWxkbid0IHByb3ZpZGUgYW55IGJlbmVmaXQgYnV0IHdvdWxkIG92ZXJjb21wbGljYXRlIHRoZQ0K Pj4gZGV2aWNlLXRyZWUgc3RydWN0dXJlLiBXaGF0IGRvIHlvdSB0aGluaz8NCj4gV2VsbCwgdGhl cmUgaXMgYW5vdGhlciBhcmd1bWVudCB3aHkgSSB3YW50IHRvIG1vdmUgc2hhcmVkIG1lbW9yeSBu b2Rlcw0KPiBvdXQgb2YgeGVuX3NjbWlfY29uZmlnLiBJbiB0aGF0IGNhc2Ugd2UgY2FuIGhhdmUg bW9yZSBmbGF0DQo+IHN0cnVjdHVyZS4gU28sIGluc3RlYWQgb2YNCj4NCj4geGVuX3NjbWlfY29u ZmlnIHsNCj4gICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSAyOw0KPiAgICAgICAgICAjc2l6ZS1j ZWxscyA9IDI7DQo+DQo+ICAgICAgICAgIHNobTEge307DQo+ICAgICAgICAgIHNobTIge307DQo+ ICAgICAgICAgIHNobU4ge307DQo+DQo+ICAgICAgICAgIGFnZW50cyB7DQo+ICAgICAgICAgICAg ICAgICAgI2FkZHJlc3MtY2VsbHMgPSAxOw0KPiAgICAgICAgICAgICAgICAgICNzaXplLWNlbGxz ID0gMDsNCj4gICAgICAgICAgICAgICAgICBhZ2VudDEge307DQo+ICAgICAgICAgICAgICAgICAg YWdlbnQyIHt9Ow0KPiAgICAgICAgICB9DQo+IH0NCj4NCj4NCj4gd2UgY291bGQgaGF2ZQ0KPg0K PiB4ZW5fc2NtaV9jb25maWcgew0KPiAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDE7DQo+ICAg ICAgICAgICNzaXplLWNlbGxzID0gMDsNCj4NCj4gICAgICAgICAgYWdlbnQxIHt9Ow0KPiAgICAg ICAgICBhZ2VudDIge307DQo+IH0NCj4NCj4gd2hpY2ggaXMgbW9yZSBpZGlvbWF0aWMsIElNTy4N Cg0KDQpBaCwgbm93IEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50LiBYZW4gZGVmaW5pdGVseSBwYXJz ZXMgdGhlIA0KL3Jlc2VydmVkLW1lbW9yeSByZWdpb24sIGJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiBz Y21pX3NobSBzaG91bGQgYmUgcGFydCANCm9mIGl0KGFzIGl0IGlzIG5vdCByZXF1aXJlZCBieSB0 aGUgRFQgYmluZGluZ3MpLCBhbmQgdGhpcyBpcyBub3QgY29tbW9uIA0KcHJhY3RpY2UgZm9yIHZl bmRvciBEVHMuDQoNCkxldCdzIHNheSB3ZSBoYXZlIGEgYm9hcmQgdGhhdCBkZWxpdmVycyBmaXJt d2FyZSBzdXBwb3J0aW5nIDggYWdlbnRzLCANCnN0YXJ0aW5nIGZyb20gMHg0NDAwMDAgdXAgdW50 aWwgMHg0NDgwMDAsIGFsb25nIHdpdGggdGhlIGRldmljZS10cmVlIGZvciBpdC4NCg0KVGhlIGRl dmljZS10cmVlIGl0IHByb3ZpZGVzIGRvZXNuJ3QgcmVxdWlyZSBhbGwgYWdlbnRzIHRvIGJlIGRl ZmluZWQg4oCUIA0Kb25seSB0aGUgZmlyc3Qgb25lIOKAlCBidXQgdGhlIHJhbmdlIDB4NDQwMDAw IC0+IDB4NDQ5MDAwIHNob3VsZCBiZSANCnJlc2VydmVkLiBUaGF0J3Mgd2h5IHRoZSBEVCBzaG91 bGQgaGF2ZSB0aGUgZm9sbG93aW5nIGZvcm1hdDoNCg0KDQovIHsNCg0KIMKgIMKgIHJlc2VydmVk LW1lbW9yeSB7DQoNCiDCoCDCoCDCoCDCoCDCoG1lbW9yeUA0NDAwMDAgew0KDQogwqAgwqAgwqAg wqAgwqAgwqAgcmVnID0gPCAweDQ0MDAwMCAweDkwMDAgPjsNCg0KIMKgIMKgIMKgIMKgIH0NCg0K IMKgIMKgfQ0KDQogwqAgwqBzaG0wOiBzY21pX3NobUAweDQ0MDAwMCB7DQoNCiDCoCDCoH0NCg0K IMKgIMKgL2Zpcm13YXJlL3NjbWkgew0KDQogwqAgwqAgwqAgc2htPcKgIDwmc2htMD47DQoNCiDC oCB9DQoNCn0NCg0KQXMgY2FuIGJlIHNlZW4sIHRoZSBtZW1vcnkgaXMgYWxyZWFkeSByZXNlcnZl ZC4NCg0KTm93IGxldCdzIGFkZCBYZW4gdG8gdGhpcyBEVDoNCg0KLyB7DQoNCiDCoCDCoCByZXNl cnZlZC1tZW1vcnkgew0KDQogwqAgwqAgwqAgwqAgwqBtZW1vcnlANDQwMDAwIHsNCg0KIMKgIMKg IMKgIMKgIMKgIMKgIHJlZyA9IDwgMHg0NDAwMDAgMHg5MDAwID47DQoNCiDCoCDCoCDCoCDCoCB9 DQoNCiDCoCDCoH0NCg0KIMKgIMKgc2htMDogc2NtaV9zaG1AMHg0NDAwMDAgew0KDQogwqAgwqB9 DQoNCiDCoCDCoC9maXJtd2FyZS9zY21pIHsNCg0KIMKgIMKgIMKgIHNobT3CoCA8JnNobTA+Ow0K DQogwqAgfQ0KDQogwqAgL3hlbi94ZW5fc2NtaV9jb25maWcgew0KIMKgIMKgIMKgIMKgICNhZGRy ZXNzLWNlbGxzID0gMjsNCiDCoCDCoCDCoCDCoCAjc2l6ZS1jZWxscyA9IDI7DQoNCiDCoCDCoCDC oCDCoCBzaG0xIHt9Ow0KIMKgIMKgIMKgIMKgIHNobTIge307DQogwqAgwqAgwqAgwqAgc2htTiB7 fTsNCg0KIMKgIMKgIMKgIMKgIGFnZW50cyB7DQogwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgI2Fk ZHJlc3MtY2VsbHMgPSAxOw0KIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICNzaXplLWNlbGxzID0g MDsNCiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhZ2VudDEge307DQogwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgYWdlbnQyIHt9Ow0KIMKgIMKgIMKgIMKgIH0NCg0KfQ0KDQoNClNvLCBhcyBjYW4g YmUgc2VlbjoNCg0KLSBXZSBkb24ndCBtYWtlIGFueSBtb2RpZmljYXRpb25zIG9yIGJyZWFrIHRo ZSB2ZW5kb3IgRFQgZm9ybWF0LCBleGNlcHQgDQpmb3IgYWRkaW5nIHRoZSBzY21pIG5vZGUuDQot IFRoZSByZXNlcnZlZC1tZW1vcnkgbm9kZSBpcyBwYXJzZWQgYnkgWGVuLCBzbyBYZW4gaXMgYXdh cmUgb2YgdGhlIA0KcmVzZXJ2YXRpb25zLg0KDQotIEFsbCBzaG0gbm9kZXMgYXJlIHBsYWNlZCBp biB4ZW5fc2NtaV9jb25maWcuDQoNCg0KQmVzdCByZWdhcmRzLA0KT2xla3NpaQ== From xen-devel-bounces@lists.xenproject.org Fri Sep 25 10:59:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 10:59:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433757.1654133 (Exim 4.92) (envelope-from ) id 1xA3dw-0002KW-Nu; Fri, 25 Sep 2026 10:59:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433757.1654133; Fri, 25 Sep 2026 10:59:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3dw-0002KN-Kj; Fri, 25 Sep 2026 10:59:04 +0000 Received: by outflank-mailman (input) for mailman id 1433757; Fri, 25 Sep 2026 10:59:04 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3dw-0002KH-3a for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 10:59:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA3dv-008FSE-Gn for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 12:59:03 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab653f6-e002-0a2a0a5209dd-0a2a4507adfa-2 for ; Fri, 25 Sep 2026 12:59:03 +0200 Received: from [160.101.131.8] (helo=na1pdmzitismtp01.tibco.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab653f6-b4ea-0a2a45070019-a06583088a00-3 for ; Fri, 25 Sep 2026 12:59:03 +0200 Received: from fedora.eng.citrite.net (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTP id 4CA52472119F; Fri, 25 Sep 2026 06:56:58 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; none From: Abdelkareem Abdelsaamad To: jbeulich@suse.com, xen-devel@lists.xenproject.org Cc: andrew.cooper3@citrix.com, roger@xenproject.org, jason.andryuk@amd.com, teddy.astie@vates.tech Subject: Re: Re: [PATCH v5] x86/nSVM: Check injected event consistency Date: Fri, 25 Sep 2026 11:53:12 +0100 Message-ID: <20260925105315.3349139-1-abdelkareem.abdelsaamad@citrix.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <70f930b2-31ba-4278-ab82-03a3c67d573c@suse.com> References: <70f930b2-31ba-4278-ab82-03a3c67d573c@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-ID: tlsNG-ef75cf/1790333943-A76D2AE4-43ABE318/0/0 X-purgate-type: clean X-purgate-size: 850 On 25.09.2026 11:15, Jan Beulich wrote: >On 25.09.2026 11:38, Abdelkareem Abdelsaamad wrote: >> On the AMD platforms, allowing a VMRUN instruction with a malformed VMCB has >> debugging complications, security and performance implications. The APM >> volume #2 15.20 (40332—Rev. 4.10—July 2026) states the two possibilities that >> VMRUN will immediately exit with VMEXIT_INVALID due to the injected event. > >This is confusing: Another variant of this was sent a little under half an hour >earlier. Simply going from size, the two also aren't identical. What's going on >here? The difference is minor. It is a reformat of the testing matrix table in an attempt to better fit the xen-devel mailing list display. There is also a change in the git send-email configuration of Roger's mail. The former can be safely dropped." Jan From xen-devel-bounces@lists.xenproject.org Fri Sep 25 11:10:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 11:10:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433790.1654141 (Exim 4.92) (envelope-from ) id 1xA3oI-0004NW-JE; Fri, 25 Sep 2026 11:09:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433790.1654141; Fri, 25 Sep 2026 11:09:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3oI-0004NP-GA; Fri, 25 Sep 2026 11:09:46 +0000 Received: by outflank-mailman (input) for mailman id 1433790; Fri, 25 Sep 2026 11:09:45 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3oG-0004NJ-W1 for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:09:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA3oF-00EDxL-SD for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 13:09:43 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab65677-bab6-0a2a0a5309dd-0a2a4502e530-0 for ; Fri, 25 Sep 2026 13:09:43 +0200 Received: from [40.107.208.24] (helo=PH0PR06CU001.outbound.protection.outlook.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab65675-6ca4-0a2a45020019-286bd0188688-3 for ; Fri, 25 Sep 2026 13:09:43 +0200 Received: from BL1PR13CA0204.namprd13.prod.outlook.com (2603:10b6:208:2be::29) by SN7PR12MB7204.namprd12.prod.outlook.com (2603:10b6:806:2ab::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.16; Fri, 25 Sep 2026 11:09:21 +0000 Received: from BN7PEPF0000009F.namprd04.prod.outlook.com (2603:10b6:208:2be:cafe::4f) by BL1PR13CA0204.outlook.office365.com (2603:10b6:208:2be::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.360.6 via Frontend Transport; Fri, 25 Sep 2026 11:09:21 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN7PEPF0000009F.mail.protection.outlook.com (10.167.248.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Fri, 25 Sep 2026 11:09:20 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 25 Sep 2026 06:09:20 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Fri, 25 Sep 2026 06:09:18 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=au0cYxCTB0DtXDViWTg/g3tt/zslEwDDVIkneHkLuxqW7rFm0I1x2JioXm7VvTfRCQU8gyNSvdi+vgOLTo+z3q+x8OHQS2AlkhpGbDwONTchUrObULogL1fa4hFd44cdu7DcOE7KM6eGjbeLG++P2hZReRXAAXMNufnofiTRRR3H5Az148THjOR4jfY1jNEnvj/reMR0hgvTgEuBX+/7fWiahwv0Cn1420tiaS/YnBa+L/AdeUbgh3jFFTeEJtDFg49jI9c3kC0CY4+RwKAWi8YOPx4t4j7wk8OoOFKXl6vSdo7s1nbIH/4wa1de6seg03zExXfV18CM6MPVfg7RfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2G2r4FUZitfaVTvGk0aO2O1E4MLhPvpXdZhynQNit3A=; b=YHPfLGEz7yP5gKlV8hpRbqOWsF+vLUuTaVGNsp/uYXK1KHNe4bSeKjrmPxu8u+EefrQcLjltfVYBtDdhPm535/eFk9trrV02Iaxqe9O5emCCpXOocQa5fcamN6IRdG5Tv8AoE4/Gngp1IWISzrl9yvG9vHgiiXJaxSlOasUt1tQgeznpfgU+4O0r9PjAPlGaMkNqz5VyFF0TmRmXpjBRXVRBGnxcGSsIeeMRvvSYTX8oO+IiFw0ELk8S0aOx04oF4DGg2v6cu0FBu7iLAGl2xT1F8IvuGEiYwLS1ZknDXoTD53o93cypAx3VZfyH6CQaptRo8Ie9O7kF82BDNedCWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2G2r4FUZitfaVTvGk0aO2O1E4MLhPvpXdZhynQNit3A=; b=iDhgn04Z5CNn3IPb3dZ908OGI5N2QkqLyuyfBM8+lERKmGmHhHtx89BZuC6XmHgVyqWNZCtdTfh4w4/xuHb7Jn4qt24Q9ZplLpyNiJ+YhqjEG5NFHmNncPnfJNbCDXIes3s5jdIdC21GCDZWjGNCbfRrm02sOArevDD1VV5rxlY= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: <65fb22b1-49d4-4d2b-9726-69884bc70799@amd.com> Date: Fri, 25 Sep 2026 13:09:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/4] xen/arm: handle irq_set_type() failures To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jens Wiklander References: From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN7PEPF0000009F:EE_|SN7PR12MB7204:EE_ X-MS-Office365-Filtering-Correlation-Id: 562187a8-d856-47e3-092f-08df1af57318 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|23010399003|7416014|376014|82310400026|56012099006|6133799003|10067099003|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: ehJZ3eh5J4IH726ZIRLGBGqn4EJJ6ObmuFheN+gs2NqzuZAAnw9EPFxJf6wCC+06xBcsJAR0uUjH6DJsevXirALb84A4evb1rfdUpWEzE6gkapUSJyWZ+pjo3BtsSr0XLYkTUG/jBaYWwlhsW7fejhcpW9WGiWW8WAPpHt+qBH03ViC5mcUNZuW5rE0tbPLHO5HQ3b1XyTB9QBapfffT3SUP1s/efdtFpNyblAxSoZ9dnvWBi0uaGQ5sNR+0+T3XpDgWQa+p+q9P2eeLvhCegVilxGEgMruZ7tX+NdFKKvHok3DTMFDmCeV7koqM1SEb5nhIJQIf2+gnksByIolrki7ysP50VTDaO0Ut2nvL3JwVv2w/eiWpZQ3LDV9LeQpeVaV/U7qRu6aSVGVqQ3spgdQr6924Rx9EzH90E04Tg0Eg1LNaTXZcs4wN+HbWZBgLMULH7aHG1m5g20s+zeTO5woN5qJVhHuyVB8izmhSvwCJuKSArk8ELeSNrNJO7tQOpEPmG4o/G3WnL/0kjyIVwTgsZDEeRKI40ebGMCWDLmCMw3oqSaHi0UU5y4kL4ouTAgNUZrcQ1kwu3jwz6p/eb3TN3qJfHY6rbaHMoK3ZjYdz+bL/JPpVse9ILcoex5kBZRc/Nnl77BtVBpRaMcN/MF/RkzcJHzBOuQVD3zZuIA9ynS161rYDt8v6K7QBilO+/wOyauw28fVNV0KeELyZVg== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700016)(1800799024)(23010399003)(7416014)(376014)(82310400026)(56012099006)(6133799003)(10067099003)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: MXBIXAKsF1Vov/ekZbrwujJbYAClzZoJ2Y5sd90ObIJvdCeoDwD0HDGlTgnbIN61GxqkIFD/rFwd/iGMnUG5inBz+G5sMUIQSD7O89UZaBnFWrXbec0s0NFujrYIYJJ8BWcF62YysEfI2cNANFw1et9TYGL+JeOluzpv55SWFj7vkQh1FgJOoZPLqMfM24jSy1+Sta0Ly+UU4K/y+h4YRPZp2CAAVxHwFphiT2Wk8TvmeV1YGbaPZwmwjbHGKfCSBr9myn0hKXJtWLUqvvGEoKW9tdwo1x2BkiDQYb3etziZ66n66Ao4SROR/I/tzvm4+dHNiiAyQPCLGHeWnmx3q4KTj26XFaXVd/HD1ssTzj3k7m9Cl0pruxss/hjV/OqfiFzlkTmuT/3/tgOvpwXkmyrVZbkOZv0TxX9V01jEuZRY9cLrimPSAnQ94b0PaaR4 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 11:09:20.9727 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 562187a8-d856-47e3-092f-08df1af57318 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN7PEPF0000009F.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7204 X-purgate-ID: tlsNG-720697/1790334583-30DC12AC-ECDC1C95/0/0 X-purgate-type: clean X-purgate-size: 7775 On 24-Sep-26 22:57, Mykola Kvach wrote: > Several Arm firmware initialization paths discard irq_set_type()'s return > value, violating MISRA C Rule 17.7. If trigger configuration fails, > initialization continues with an IRQ that was not configured as requested. > > GTDT and MADT retain rejected timer and maintenance INTIDs. > check_timer_irq_cfg() and release_irq() later perform unconditional > descriptor lookups on those values. Xen has no backing descriptors for > INTIDs 1024 through 4095, so retaining one can cause an out-of-bounds > access. > > Check the return value in the GTDT, MADT, SPCR, and FF-A paths. Store timer > INTIDs only after successful trigger configuration, make GTDT parsing > failure fatal, and stop UART or notification setup when trigger > configuration fails. > > Signed-off-by: Mykola Kvach > Reviewed-by: Volodymyr Babchuk > Reviewed-by: Michal Orzel > --- > Changes in v3: > - Avoid partial state updates and simplify maintenance IRQ setup. > > Changes in v2: > - New patch. > --- > xen/arch/arm/gic-v2.c | 15 +++++++++------ > xen/arch/arm/gic-v3.c | 15 +++++++++------ > xen/arch/arm/tee/ffa_notif.c | 11 ++++++++++- > xen/arch/arm/time.c | 18 ++++++++++++++---- > xen/drivers/char/ns16550.c | 8 ++++++-- > xen/drivers/char/pl011.c | 4 +++- > 6 files changed, 51 insertions(+), 20 deletions(-) > > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c > index d05c574d88..87eda9d322 100644 > --- a/xen/arch/arm/gic-v2.c > +++ b/xen/arch/arm/gic-v2.c > @@ -1166,17 +1166,20 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header, > /* Read from APIC table and fill up the GIC variables */ > if ( cpu_base_assigned == 0 ) > { > + int rc; > + > + rc = irq_set_type(processor->vgic_interrupt, > + processor->flags & ACPI_MADT_VGIC_IRQ_MODE ? > + IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK); > + > + if ( rc ) > + return rc; > + > cbase = processor->base_address; > csize = SZ_8K; > hbase = processor->gich_base_address; > vbase = processor->gicv_base_address; > gicv2_info.maintenance_irq = processor->vgic_interrupt; > - > - if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE ) > - irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH); > - else > - irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK); > - > cpu_base_assigned = 1; > } > else > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > index acdac22953..b32a9b5009 100644 > --- a/xen/arch/arm/gic-v3.c > +++ b/xen/arch/arm/gic-v3.c > @@ -1743,15 +1743,18 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header, > /* Read from APIC table and fill up the GIC variables */ > if ( !cpu_base_assigned ) > { > + int rc; > + > + rc = irq_set_type(processor->vgic_interrupt, > + processor->flags & ACPI_MADT_VGIC_IRQ_MODE ? > + IRQ_TYPE_EDGE_BOTH : IRQ_TYPE_LEVEL_MASK); > + > + if ( rc ) > + return rc; > + > cbase = processor->base_address; > vbase = processor->gicv_base_address; > gicv3_info.maintenance_irq = processor->vgic_interrupt; > - > - if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE ) > - irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH); > - else > - irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK); > - > cpu_base_assigned = 1; > } > else > diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c > index 186e726412..d08d0a3366 100644 > --- a/xen/arch/arm/tee/ffa_notif.c > +++ b/xen/arch/arm/tee/ffa_notif.c > @@ -407,7 +407,16 @@ void ffa_notif_init(void) > irq = resp.a2; > notif_sri_irq = irq; > if ( irq >= NR_GIC_SGI ) > - irq_set_type(irq, IRQ_TYPE_EDGE_RISING); > + { > + ret = irq_set_type(irq, IRQ_TYPE_EDGE_RISING); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "ffa: irq_set_type irq %u failed: error %d\n", > + irq, ret); > + return; > + } > + } > ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL); > if ( ret ) > { > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c > index be54b87438..ccfb76e20f 100644 > --- a/xen/arch/arm/time.c > +++ b/xen/arch/arm/time.c > @@ -60,20 +60,27 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header) > { > u32 irq_type; > struct acpi_table_gtdt *gtdt; > + int rc; > > gtdt = container_of(header, struct acpi_table_gtdt, header); > > /* Initialize all the generic timer IRQ variable from GTDT table */ > irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el1_flags); > - irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); > + rc = irq_set_type(gtdt->non_secure_el1_interrupt, irq_type); > + if ( rc ) > + return rc; > timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt; > > irq_type = acpi_get_timer_irq_type(gtdt->virtual_timer_flags); > - irq_set_type(gtdt->virtual_timer_interrupt, irq_type); > + rc = irq_set_type(gtdt->virtual_timer_interrupt, irq_type); > + if ( rc ) > + return rc; > timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt; > > irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el2_flags); > - irq_set_type(gtdt->non_secure_el2_interrupt, irq_type); > + rc = irq_set_type(gtdt->non_secure_el2_interrupt, irq_type); > + if ( rc ) > + return rc; > timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt; > > return 0; > @@ -81,7 +88,10 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *header) > > static void __init preinit_acpi_xen_time(void) > { > - acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init); > + int rc = acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init); > + > + if ( rc ) > + panic("Timer: Failed to configure interrupts from GTDT: %d\n", rc); > } > #else > static void __init preinit_acpi_xen_time(void) { } > diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c > index 120ac09d23..eb608ab8b4 100644 > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -1928,6 +1928,7 @@ static int __init ns16550_acpi_uart_init(const void *data) > struct acpi_table_header *table; > struct acpi_table_spcr *spcr; > acpi_status status; > + int rc; > /* > * Same as the DT part. > * Only support one UART on ARM which happen to be ns16550_com[0]. > @@ -1959,6 +1960,11 @@ static int __init ns16550_acpi_uart_init(const void *data) > return -EINVAL; > } > > + /* The trigger/polarity information is not available in spcr. */ > + rc = irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH); > + if ( rc ) > + return rc; Thinking more about it, it's better for console to use polling mode than fail on IRQ setup. That's what we do for DT case in this driver. Something like: if ( irq_set_type(spcr->interrupt, IRQ_TYPE_LEVEL_HIGH) ) { printk(XENLOG_WARNING "ns16550: unable to configure IRQ %u, using polling\n", spcr->interrupt); irq = 0; } Same for pl011. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Sep 25 11:10:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 11:10:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433795.1654150 (Exim 4.92) (envelope-from ) id 1xA3or-0005mC-Qe; Fri, 25 Sep 2026 11:10:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433795.1654150; Fri, 25 Sep 2026 11:10:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3or-0005m5-NP; Fri, 25 Sep 2026 11:10:21 +0000 Received: by outflank-mailman (input) for mailman id 1433795; Fri, 25 Sep 2026 11:10:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3oq-0005lt-Ty for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:10:21 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA3oq-00HY2H-Au for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 13:10:20 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab6568d-e002-0a2a0a5209dd-0a2a450bc996-46 for ; Fri, 25 Sep 2026 13:10:19 +0200 Received: from [40.93.201.24] (helo=CY3PR05CU001.outbound.protection.outlook.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab6569a-b7e8-0a2a450b0019-285dc9182a3a-3 for ; Fri, 25 Sep 2026 13:10:19 +0200 Received: from SJ0PR13CA0138.namprd13.prod.outlook.com (2603:10b6:a03:2c6::23) by PH7PR12MB8054.namprd12.prod.outlook.com (2603:10b6:510:27f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Fri, 25 Sep 2026 11:10:12 +0000 Received: from BY1PEPF0002695C.namprd05.prod.outlook.com (2603:10b6:a03:2c6:cafe::a2) by SJ0PR13CA0138.outlook.office365.com (2603:10b6:a03:2c6::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.12 via Frontend Transport; Fri, 25 Sep 2026 11:10:12 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BY1PEPF0002695C.mail.protection.outlook.com (10.167.244.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Fri, 25 Sep 2026 11:10:12 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 25 Sep 2026 06:10:12 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 25 Sep 2026 06:10:11 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Fri, 25 Sep 2026 06:10:10 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LE8XpVq2WOW7Ac4kSJx4BBN6EaPaYs2TLm/k8KkkNvvsg9npqB46rSQsCIM5OtVYubMu0DjhmLPw9zPiH3cjtfJJa50rzOTIkL2zFN1BueTofVX3Vv1abzJKJWxAxiuIOtQ//pAT5P0oHYYVrQ53+/GUayGy9396WpYwsSM6kIkkGVoY6PMTbOY1S+FcdmWoKzob1quo/4jNko+kiF5ZoWIboJhDEBvhrUqbC8dBHszUNiYVz8GUOaLWN6f08cjHxbx61YltCz/GqcAwFPV5ZbHYaoX7EQDt5e9lwrQeVucjDwiU/w3CncjmlZ8hSvBXZdOvXo167UfbJwe8ta520w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aGXOMpwLctdufDOCI1Vsnq3V+JCTKt9lR9znunwWc7I=; b=NHNqk3WCG6umjxo59FRC7trTXSLetpSBdTtY6Q5ln8vMJQqwmuAzGW6EP0KsYt1iAeVHpATtmW3N5LxPG34l3DLkyam89FkyftiELSbKM/9U3dR44e/XD8Fz7UBW3vCU3UK3MZilakbHn6CpLWwjlLXUMx778v2nZ/CqEUBP0belrTH82W1RqoLKzb22qThaqYP82o+gcVM+nRIw9zO2//JdDgi0f01afl5gT0dMQCrwBefrJtQ1PoDmuATI9EPt/SHPIJbUKh5pxmxMHea7Gu0EJNGZOiz3aGu/cB599zRQ1zG+OvC7k00sx6DyYz2BtwkhhoAmwHkcy7/h/ZnZEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aGXOMpwLctdufDOCI1Vsnq3V+JCTKt9lR9znunwWc7I=; b=jr3mzGfLE3zddF46/vk6ZIvTJjQpFo2M30t/hHTMGBsrtlXNAujQj8J/nY6WyNI6Ts2e87hQOIVJ6+aveueuT4IzsjBVnb/tg6wTT2ov1fZgxdT2smugXKO+16x7M2isNyotmer+2Cc2uAdYIHgTni7iy06vY8z3sClebdRZxFI= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: <49d18767-5e1e-4307-9606-c476c42e6cf5@amd.com> Date: Fri, 25 Sep 2026 13:10:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/4] xen/arm: make is_espi() a pure range predicate To: Mykola Kvach , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" References: <8aa55bb41ec944bd249a77959e7702e001a8329d.1790160605.git.mykola_kvach@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <8aa55bb41ec944bd249a77959e7702e001a8329d.1790160605.git.mykola_kvach@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PEPF0002695C:EE_|PH7PR12MB8054:EE_ X-MS-Office365-Filtering-Correlation-Id: 66c8c314-0f9f-4789-2f80-08df1af591c9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|36860700016|376014|1800799024|82310400026|10067099003|56012099006|11063799006|22082099003|18002099003|4143699003; X-Microsoft-Antispam-Message-Info: hzpdoJKQfYpde9zkS+aHlrrq2q/YL1e24NoPK+MuJLShcn9l+gy6RUjQnnIaY7NnnwPisb6RPM6N9gmTzxcK2fS1CFYrN1UkF3Uv/EDrUuCfsSjxwIUwlyRo0LO20H1OxTr4cjNYOnWTyDex/fvWYYOZiZFMuBwZr3VBQ7iONQx5DSCDnmIg29XOI3ni2uB/OLF8TV2BGPHf3byOoSTrkFTo+ymKgFS5u3h9vJgT0TT7TSqjFPHfHq3qwHW5B9Eqii7N2btu4EfoixcFEkzj3JL2DRiMe/rMsSkhyjkL9jiACVoTK5xxjRhsFOXDt63vqh2J5B+YDSxpPOylNufBWbvMuhLEMhckXRAo6+sYp/s2OnWyOfJfLBCHG+6TGCfWLusN8/SB+qUuKbI1niyO3KbQ3LfFjFLKLMPNkAK//aoYlfY9w04kM8x1rLhW6J70KBG7gp/X+hYZ2VA+Ql8+z1uQJ1uqR0ml5iea7hTT0qZeYHieAk3Ta+W96a9Gl6oDyA6Lg4aIW8Jt8rhENwVApyDrRNvfvvMy6yO7K9fBTJvfLwHJPuLnlPwwhoJadJv/WzR26FGFnrl4IH77pzM1vXgfiVH1OBpgdDLQot9i07tvyvRFdRkxG6qQVOWSyuSjdjKJPnn3x7s/yiPoZ+EZ06daK0EUeeWn6Sj5B4UT8oaDdOzstaPkgh7OyFE3rGsQaiRW4l3GSDdtlDY6KCDWQA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(36860700016)(376014)(1800799024)(82310400026)(10067099003)(56012099006)(11063799006)(22082099003)(18002099003)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: pPVq6yOAwRJYlV0HGjrFB/ZOV8QEkbKp4P3uB6QawD0CVhMIrC3PcNbRCHnLRSLChE0PM7GyAho+nydcAiZniAM5Ly9dCcIOfFt9qoHSt20ZEOSisrElCCMPl/3TIjOI+jNM+GWf2LW5V+qEz78X+nX+Bt2/2RNrtNS8qwX1fmoykfxYrgcY9plBYgc5iLiF6pAlJbZgguUoPMdRtL0I0ZIDCGYmrRU7Z4WUxO9jQxiJQkj6fYXRXcrmjwfuWlYyLsvvEOqT1K+gf02K3FFJt9so57UwPZH1IsJupunJGtYMb4MOcepFMpeDtR4UeF+6nNoIg5cej28m0chrVcyzsh3Id/rd7ejeUfFPQV+FbxQhUL+/V7X34swDvMLTxW+qljswyRCcvFWn7rs8adezXDdn9TvR5tAvESWQq9fKncyAJGqdAvL/Z3P1EzT6My8V X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 11:10:12.3823 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 66c8c314-0f9f-4789-2f80-08df1af591c9 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BY1PEPF0002695C.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8054 X-purgate-ID: tlsNG-42698a/1790334619-184CB9EA-9D87CC12/0/0 X-purgate-type: clean X-purgate-size: 815 On 24-Sep-26 22:57, Mykola Kvach wrote: > is_espi() currently changes its result according to CONFIG_GICV3_ESPI. > Without eSPI support, it returns false, and its assertion fails if > an eSPI INTID is passed. Callers therefore use it both to identify > eSPIs and to exclude eSPI handling when support is disabled. > > Make is_espi() report only whether an INTID is in the architectural > eSPI range. Check for eSPI support at the call sites. > > Use BUG_ON() if the GIC reports an eSPI without compiled-in support, > matching the handling of unsupported LPIs. Treat virtual eSPI lookup > without support as unreachable, with a NULL return from the > espi_to_pending() stub. > > Signed-off-by: Mykola Kvach Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Sep 25 11:17:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 11:17:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433828.1654158 (Exim 4.92) (envelope-from ) id 1xA3vP-0006R7-EH; Fri, 25 Sep 2026 11:17:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433828.1654158; Fri, 25 Sep 2026 11:17:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3vP-0006R0-BW; Fri, 25 Sep 2026 11:17:07 +0000 Received: by outflank-mailman (input) for mailman id 1433828; Fri, 25 Sep 2026 11:17:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA3vO-0006Qs-9U for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:17:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA3vN-008J4l-Io for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 13:17:05 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab65826-e002-0a2a0a5209dd-0a2a4507ca88-26 for ; Fri, 25 Sep 2026 13:17:05 +0200 Received: from [40.107.200.30] (helo=CH5PR02CU005.outbound.protection.outlook.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab6582f-b4ea-0a2a45070019-286bc81ec5be-3 for ; Fri, 25 Sep 2026 13:17:04 +0200 Received: from PH7PR17CA0007.namprd17.prod.outlook.com (2603:10b6:510:324::18) by MW4PR12MB7190.namprd12.prod.outlook.com (2603:10b6:303:225::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Fri, 25 Sep 2026 11:16:57 +0000 Received: from SJ5PEPF00000203.namprd05.prod.outlook.com (2603:10b6:510:324:cafe::55) by PH7PR17CA0007.outlook.office365.com (2603:10b6:510:324::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.19 via Frontend Transport; Fri, 25 Sep 2026 11:16:57 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ5PEPF00000203.mail.protection.outlook.com (10.167.244.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Fri, 25 Sep 2026 11:16:56 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 25 Sep 2026 06:16:56 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.49; Fri, 25 Sep 2026 06:16:55 -0500 Received: from [192.168.31.141] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.49 via Frontend Transport; Fri, 25 Sep 2026 06:16:54 -0500 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HEt/WXf8HO7t9riEDXERtdfFB7QL8KdvGeQESBCR6txB/pik4wZbn802MkU4EMahhNXg3Eh/BpoFHh+p7GKc4jC48Zpsi2mq+bqyTY3P6dttwY7Ze8XgmBjLZnZVgtPPFkYcKi2+ZzK41LmRh5mspLiQ1tiSelO1+bSkuyQOT5NfIIqeDT63vYEa7QJzuICY4mUc6pSTjc1HlSxudfv3i53b5ztTduRz5vzBTmWbxyK9qcS2qRRyYtOLHoSQHUh+suaHj/zkWr60oaIgFmdGOOtHmvdhvbuDz83K9DY2Lkrza0luVB7Z+erfPaD+8HbtuB9R32SuwnCtcarSdAMHwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MtltmMtWWSnGRm6iaffboFNVp7fDDjazfKEdFjUABws=; b=DSwUno/d1zUWP7Yxf2YDmLJL92UQjsC/FXivvLa7m3FfgseYJNyUonpkbcHxEyHHQGG02HK13FJZ6FO75k23dg3CCTjsb0fodbvwJtTOMlXfyEWSHo+VbCK3t+7oBhJvEfRWnxrkN2KlnLKTSm1Ii4+CUNSOLXgMQRQP+rT6yJVXUnwfEQyPWrVaR4QJRQkpSevsoweRh/3Le17HkuLVOWXs3J8bBm/uLMIW2DhoDkcEq7JZYT3g30Og3m6JiWBP9EpVx+RwZAOF7Ikzg4SHycCch972Y7mmakBXRQTizhnaC7kee6vZq1ABtOcvN9AJcpigxyAj6kvRy1Wol54WvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MtltmMtWWSnGRm6iaffboFNVp7fDDjazfKEdFjUABws=; b=Y9j5z3iBTguyNDf4V+31RzqkbVSu3Lpt9r85TgWDxhMXLHmnyOw6qpYYIBF0nqoDnLi8opFY904u5ZTP2KHmEv5HsrO8sfjt9HgZTPY+0yfVq3upe6Ct8gWotnfo0bkChtYm7pOP+5V5J1WNo2UGWk+4d0rkBXBe6BxeOVpzbvw= X-MS-Exchange-Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Message-ID: <3d759f27-1381-4b75-b047-4d90a0f2b106@amd.com> Date: Fri, 25 Sep 2026 13:16:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 4/4] xen/arm: vgic: free eSPIs using the bitmap index To: Volodymyr Babchuk , Mykola Kvach CC: "xen-devel@lists.xenproject.org" , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" References: <8c61cf31b69377737d1f688bded43d123ac55d00.1790160605.git.mykola_kvach@epam.com> <877bka1cp3.fsf@epam.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <877bka1cp3.fsf@epam.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF00000203:EE_|MW4PR12MB7190:EE_ X-MS-Office365-Filtering-Correlation-Id: 22fca03f-2982-4d58-8fbf-08df1af682f1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|376014|36860700016|1800799024|82310400026|11063799006|6133799003|10067099003|56012099006|4143699003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: vQEAH60n5R3edHdjx3OnPDB2rcjreu4iCtyNe0zvKEV0Bn7QSkzajnexq49LlfnOD2W7iQmRO7Oaz71VYyNKy24djRlOSIUBXQ+Q3oQV4iIT+Q7MdKkaW+7+/+S9aqE5Io/1hOc+YMnAW3iTV4PaP0zWeraSDBzd5mUM6CaQOnXvazZiAivggSJGPJBiz2igaL7ZGrnd5nujXqzY7+S1SADiYMh4ccN8N1cdXNCdqu2qa1JUAEH643qWgFXacu76UrzohvDrfHtmxS7Q13GjMiopC8EA11JsU7PW7Bf//js/0Y3SrkZx4vcemsfSbY3QXBsehHKgKBbxyHxq6He8+BfQQcQoNK/8T7KzVPhUeOAsxy6eEANZv9X4QhXD7Fb5OT+e2llvkOR//L4yijYyPima4l5zaaIioN15JtnVIPlixG8V+97TdQhJfd9ltlYAst1Sy2Fey71VmAt/deVc9cvQCrngyzzrcpE4nCkOkLE4Tx+LbhLB/81gXRcnxAgqNcfz41Roahf6fzF69rgveeYxQH2o9im9+XIjHAy/6IOoBoOsY4OJm2s5OukIWRZ0m9czXvmK9FpsDCziudVG0yQN+F+YRYdYSozugJv4WJ+NvD2Lv1g2pVMaivRU1Ti32BE2vhu3VOg5f8XQF5t610xl1sMdXIZTnTxRGYajtbK4CF29gqn8+8G9OJziuGFGO8I7YiuLnB8YcvNb4nreyw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(23010399003)(376014)(36860700016)(1800799024)(82310400026)(11063799006)(6133799003)(10067099003)(56012099006)(4143699003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: T6Gwy21MAO7oJV/cNKfEvO0Hzh1fbmmIB7VAKFv/J0bPcaBfPeDa/+Ya/MqipzrczS4FpVo8LhwJlLVkWZLO3HYAhXqHEZgbzdNMjEJiP35gGGDVRgMZBZ8LSl4OO3LewSZleBRk19tPlCEDQaM3fX4i6PrZ7VVMuYGOPcTfeu7j4howTiAxEcZQtIPcusKiBZgQz1sp/KmeB9yA+K6NzbwDb3RlrMKhSDcsb/DLCljXjNXkgt1u90vvA6tbO6/vmwunGV8tUtuVPx/wYJcL5w3NCKZ75tQ3tmkOk4ZK/8ItaYigBZCbqZZ3Z1VKHHJjk1aeHtTrzouj898nkPSC3wP1fGJuVQaxRGhPiOvyq7NQsRDxk8Rv2REGNspm3PEoRwckWwZzRUlA4pX1YlGEZ3HutsZsQ3PYtHhepY+qAgMfAYPQNFUSTki93r9UiL18 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 11:16:56.9768 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 22fca03f-2982-4d58-8fbf-08df1af682f1 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF00000203.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7190 X-purgate-ID: tlsNG-ef75cf/1790335025-372DCAE4-052DC55E/0/0 X-purgate-type: clean X-purgate-size: 4778 On 25-Sep-26 00:55, Volodymyr Babchuk wrote: > Hi Mykola, > > Mykola Kvach writes: > >> The allocated_irqs bitmap in the existing vGIC implementation stores eSPI >> allocation bits immediately after the regular vIRQ bits. >> vgic_reserve_virq() converts an eSPI INTID to this compressed bitmap index, >> but vgic_free_virq() used the raw INTID. >> >> Freeing INTID 4096 therefore clears bit 4096 instead of the first eSPI bit. >> This writes beyond allocated_irqs and leaves the intended eSPI bit set. >> Valid eSPIs reach this path during DOMCTL bind failure cleanup and unbind, >> and during vPL011 teardown. >> >> Add virq_to_idx(), the inverse of idx_to_virq(), and use it when reserving >> and freeing vIRQs. Use vgic_is_valid_line() for the validity checks when >> reserving and freeing vIRQs in both vGIC implementations. >> >> Fixes: bdde400c6e1b ("xen/arm: vgic: add resource management for extended SPIs") >> Signed-off-by: Mykola Kvach >> Reviewed-by: Michal Orzel >> --- >> Changes in v5: >> - Add the vgic_is_valid_line() guard to vgic_free_virq() in the new >> vGIC implementation and use the same helper in vgic_reserve_virq(). >> >> Changes in v4: >> - Document the compressed bitmap layout with an ASCII diagram above the >> conversion helpers and refer to struct vgic_dist for the full layout. >> >> Changes in v3: >> - Adapt virq_to_idx() to the configuration-neutral is_espi() helper. >> >> Changes in v2: >> - Call is_espi() without a configuration guard. >> --- >> xen/arch/arm/vgic.c | 42 +++++++++++++++++++++++++++++----------- >> xen/arch/arm/vgic/vgic.c | 5 ++++- >> 2 files changed, 35 insertions(+), 12 deletions(-) >> >> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c >> index 0ba13e18da..acded6a40f 100644 >> --- a/xen/arch/arm/vgic.c >> +++ b/xen/arch/arm/vgic.c >> @@ -25,6 +25,21 @@ >> #include >> >> >> +/* >> + * The allocated_irqs bitmap is compressed: eSPI bits immediately follow >> + * regular IRQ bits, skipping the gap in the INTID space. >> + * >> + * +-----------+-----------+-------------------+-------------------+ >> + * | SGIs | PPIs | SPIs | eSPIs | >> + * +-----------+-----------+-------------------+-------------------+ >> + * 0 16 32 vgic_num_irqs(d) >> + * >> + * INTID ESPI_BASE_INTID maps to bitmap index vgic_num_irqs(d). >> + * The following idx_to_virq() and virq_to_idx() convert between INTIDs >> + * and bitmap indexes. >> + * >> + * See also the allocated_irqs comment in struct vgic_dist. >> + */ >> static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx) >> { >> if ( idx >= vgic_num_irqs(d) ) >> @@ -33,6 +48,16 @@ static inline unsigned int idx_to_virq(struct domain *d, unsigned int idx) >> return idx; >> } >> >> +static inline unsigned int virq_to_idx(struct domain *d, unsigned int virq) >> +{ >> + ASSERT(IS_ENABLED(CONFIG_GICV3_ESPI) || !is_espi(virq)); >> + >> + if ( IS_ENABLED(CONFIG_GICV3_ESPI) && is_espi(virq) ) >> + return espi_intid_to_idx(virq) + vgic_num_irqs(d); >> + >> + return virq; >> +} >> + >> bool vgic_is_valid_line(struct domain *d, unsigned int virq) >> { >> #ifdef CONFIG_GICV3_ESPI >> @@ -854,19 +879,11 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr) >> >> bool vgic_reserve_virq(struct domain *d, unsigned int virq) >> { >> - unsigned int idx = virq; >> - >> if ( !vgic_is_valid_line(d, virq) ) >> return false; >> >> - if ( is_espi(virq) ) >> - { >> - unsigned int num_regular_irqs = vgic_num_irqs(d); >> - >> - idx = espi_intid_to_idx(virq) + num_regular_irqs; >> - } >> - >> - return !test_and_set_bit(idx, d->arch.vgic.allocated_irqs); >> + return !test_and_set_bit(virq_to_idx(d, virq), >> + d->arch.vgic.allocated_irqs); >> } >> >> int vgic_allocate_virq(struct domain *d, bool spi) >> @@ -903,7 +920,10 @@ int vgic_allocate_virq(struct domain *d, bool spi) >> >> void vgic_free_virq(struct domain *d, unsigned int virq) >> { >> - clear_bit(virq, d->arch.vgic.allocated_irqs); >> + if ( !vgic_is_valid_line(d, virq) ) >> + return; > > I don't think that silently failing is a good idea. It needs an ASSERT() > at least. We cannot add ASSERT() here. Take a look at vpl011 init failure path on vgic_reserve_virq() that is taken to domain_vpl011_deinit(). If you specify nr_spis not enough to cover for UART IRQ, this can happen. I think I answered this question some time ago. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Sep 25 11:26:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 11:26:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433842.1654167 (Exim 4.92) (envelope-from ) id 1xA44X-0008ME-Aw; Fri, 25 Sep 2026 11:26:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433842.1654167; Fri, 25 Sep 2026 11:26:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA44X-0008M7-8B; Fri, 25 Sep 2026 11:26:33 +0000 Received: by outflank-mailman (input) for mailman id 1433842; Fri, 25 Sep 2026 11:26:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xA44W-0008M1-2N for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 11:26:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA44V-008dNH-C8 for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 13:26:31 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab65a67-2eae-0a2a0a5409dd-0a2a450c9852-0 for ; Fri, 25 Sep 2026 13:26:31 +0200 Received: from [74.125.225.141] (helo=mail-wm2-f13.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab65a67-f479-0a2a450c0019-4a7de18dd3dd-3 for ; Fri, 25 Sep 2026 13:26:31 +0200 Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49b912e4b11so3750695e9.3 for ; Fri, 25 Sep 2026 04:26:31 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ff43ad975sm42779005e9.13.2026.09.25.04.26.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Sep 2026 04:26:30 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790335591; x=1790940391; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+lWM5TekiSptjrmqp6G2diE6akLylv8aPFh+gjrRDJQ=; b=jSgcgio+SZ1HgZgQm19izQyqpGznlcGUlsV0s7/T3HOAw2LdT8RnrL4JmGDbfo1mwh HYurc3KY/ph8ifbvFhV7PYauvczgWMr24APcJOIwA56kVJY+xcgLrO8MoCr93nlCXpMT TuXt+5/2b6aLaUREl7dX/uRbNnYVlsg9/SciLsFZBocLIEGG24sgQk90pT4J4F1d9pPb h8Gpye6Y1VuE1EwgUyaIbp20RRUYuz3mwNLXFqpSuE9XsjPyOk6k4VxSWj7M1c98Ud+x W858iK6j/4A/TCE0e79qHDSmnm/mV3mQaLegc1b3LQTJv3utGo8gqZjxHtzHefpzVxwy uhbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790335591; x=1790940391; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=+lWM5TekiSptjrmqp6G2diE6akLylv8aPFh+gjrRDJQ=; b=FbquWIpwTxlPMC/Ne7ls8gDs8sRdphOhIMsH4/v3qwAWiktP4QBLpP68MhQsqn5Dx4 YHT9b3Vb6ip9XX8NA1fUt9LrPCejudqDYcKFBlVg/aEWpFnwM12KJKewNOXYAKw7j7Wd dUaQJ09ZZtfiYkl5lADSk3/IAhtVw+GuqUqRH6TsPQ3+73onIhIs+a2cubtjIa4PXWOV kzFY0la88V4v3goGmXCJ2RpPW5DgtpkBpQe/0Vd51eHN71m0IRqsJSy8nmcisc5xCaQW 1lzkOvrskuAPwKRpLOSOqGcPuYbsvMFbMu0KZymYc9CWJTwYkcAubh3Pp57PjxeXdp/G OmVA== X-Gm-Message-State: AFuF++nCPccj2GjoOAd7Skzu2GEQNeZRl95N1pHi5X/atQXGJUYPZJ21 Qxd4IiFe+5qxaSSZTxk9ISYBie3yoP/4alXu8wBUEoXbWUlnxP4kkc9r X-Gm-Gg: AYBFou0zpfsjMjAP929u6KkRBve1BN0MHcvgZ2YJXZh4EeVFN89j5vEzAS7ihFQGXU6 3+wRsmUmP8XB1M5XhBUZeNVzRdLeQjxa65/acYuuWzz3snfx5xkFjWWNW0CtZnAogWrQQVVxKi/ UucbZLPljPBZGVfWVYBR5eSGF8d+1Rgu0GNHSTpTqXqjPNrHQEwt8ORmUGdBMVO4txk+4aApGGm hLCV5ZS5tJdw+dxn2k6mvuL64fNI6/1JIKiwNO5YB5yKuaLxT35fB+Wk3hZ4OCUwa0261XeY5ti Xx2oUP1NOJeCsiavLc+W2Aq6DvMKZLnGzVBQzV+Ms/L35E3b+RDNrsUpeY3VPA28SZ+D9hbcGy/ E0FpyDCChszn7xYirtkpCr/bgPO0Xiot3yKpv1fZbEONg3yDMOMRP4QA4CO3vfkRwTLhT7Ao4ah wEvMoM7Cm/ymKqj5relwkTXEBJ+x/fMLCQXQg6cw60nqDUeTy9FuEdaxUHPZwIoB/w5AV4RZ+29 uEt8hl7B36uqbYc41OW6fuIS+MxWpxj0y8MsmIzvfC/gc92UfpuNIT96XEp4g== X-Received: by 2002:a05:600c:8b86:b0:49f:ce73:7a9 with SMTP id 5b1f17b1804b1-49fe6701ed1mr94454505e9.34.1790335590640; Fri, 25 Sep 2026 04:26:30 -0700 (PDT) Message-ID: <59d01129-b289-40dd-a07c-337e631f35e6@gmail.com> Date: Fri, 25 Sep 2026 13:26:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu() To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1790328140.8631fc262581453bbf619ec5b2062170.1a0d7df725e00072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790328140.8631fc262581453bbf619ec5b2062170.1a0d7df725e00072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-d25034/1790335591-76ADCA5B-BCCEF71B/10/73395122804 X-purgate-type: spam X-purgate-size: 1584 >> +static void noreturn idle_loop(void) >> +{ >> + BUG_ON("unimplemented"); >> +} >> diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S >> index 331446a238..bf1843dcea 100644 >> --- a/xen/arch/riscv/entry.S >> +++ b/xen/arch/riscv/entry.S >> @@ -143,3 +143,26 @@ FUNC(__context_switch) >> >> ret >> END(__context_switch) >> + >> +/* t0 is used as a temporary reg and is clobbered to oblivion */ >> +FUNC(return_to_new_vcpu) >> + /* Swap tp with sscratch */ >> + csrrw tp, CSR_SSCRATCH, tp > Why do we need a swap? After it, tp will be equal to zero, but we won't > use it. Couldn't we do a basic csrw instead? > SSCRATCH needs to hold pcpu_info while the guest runs and be 0 while Xen runs. The trap entry will then do csrrw tp, sscratch, tp, and the resulting tp says where the trap came from: - Non-zero: the trap came from the guest. tp now points to pcpu_info and the guest's tp is parked in SSCRATCH. - Zero: the trap came from Xen. Recover tp with csrr tp, sscratch and write SSCRATCH back to 0. On trap entry the swap really is needed. No register is free there, so one instruction has to save the guest's tp and load pcpu_info at once. But considering just the line you commented I think csrw could be enough. I will double-check during an introduction of this line in more appropriate patch. Considering that it can't be clear for now why it is needed I will move this part to the patch (which updates handle_trap() with guest trap support handling). Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 25 13:12:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 13:12:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433941.1654178 (Exim 4.92) (envelope-from ) id 1xA5ij-00082n-3B; Fri, 25 Sep 2026 13:12:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433941.1654178; Fri, 25 Sep 2026 13:12:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA5ii-00082f-VZ; Fri, 25 Sep 2026 13:12:08 +0000 Received: by outflank-mailman (input) for mailman id 1433941; Fri, 25 Sep 2026 13:12:08 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xA5ih-00082Z-Rt for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 13:12:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA5ih-008dsR-8a for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 15:12:07 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab67327-8faa-0a2a0a5109dd-0a2a4505cb5e-0 for ; Fri, 25 Sep 2026 15:12:07 +0200 Received: from [185.255.28.35] (helo=prod-mta-13-02.swg-srv.net) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab67326-4cb1-0a2a45050019-b9ff1c23937f-3 for ; Fri, 25 Sep 2026 15:12:07 +0200 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-02.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a0d8b1bfe100072c4.007 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 25 Sep 2026 13:12:02 +0000 Received: from [192.168.1.37] (lfbn-gre-1-371-96.w90-112.abo.wanadoo.fr [90.112.87.96]) (Authenticated sender: baptiste.le-duc) by mail2.vates.fr (Postfix) with ESMTPSA id AF5A981CD1; Fri, 25 Sep 2026 15:12:01 +0200 (CEST) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=w9eBIw9fJ6ESu8YTJFgjQ7jbXsbgaKYaXGed1VaQ7xA=; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references:feedback-id; b=baXy+O2gcvSC6mJvkHXU6KYV8cRgh3OXT//3T2NfYfkaJOL7ius0ujmx4ThUvcUaVOfLyN4ZE tWlQQ7lw0IeE6LOyaOEZcFLB7x5jkVupQoX/+Shy73a0AvkqaHShnCRhrXiGPOyXOoLeYGegswb Sw5ePYp7LK1hMoRPHt9mM74Kv+wMPJdufnd/33rtbE98rJFwBKX9SHdQOwOQa6Sj0Bh66mftWs2 2/aJBuMncNDhVuSlgb7yltS39cUGRKrrN4Xhh5aEnkNTDqR+uI+1/cJjIiE/m3ONU37pIrBbA4l 91T0cV3/FvKxhe4iGgLFK4myb/oWVOyxQlE6/SXDrx6Q== X-Zone-Loop: 1290357f7e27a7124f587660a1550ed236990954d75f x-campaign-type: default x-transaction-id: 178cb50c-5ad4-426c-9c49-53c00debe465 x-swg-uid: 01-4af9c8aa-e81f-439d-ac2a-5bc558c5aaed X-Mailer: Sweego Message-ID: <1790341922.8631fc262581453bbf619ec5b2062170.1a0d8b1bfe100072c4@vates.tech> x-swg-bid: 1790341922.8631fc262581453bbf619ec5b2062170.1a0d8b1bfe100072c4 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH v2 39/39] xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu From: Baptiste Le Duc To: Oleksii Kurochko Cc: xen-devel@lists.xenproject.org, Romain Caritey , Baptiste Le Duc , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini In-Reply-To: <4df9cf63943d0f371c8a25c6c9e84adbd3083a61.1787838835.git.oleksii.kurochko@gmail.com> References: <4df9cf63943d0f371c8a25c6c9e84adbd3083a61.1787838835.git.oleksii.kurochko@gmail.com> Date: Fri, 25 Sep 2026 15:11:54 +0200 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790341916; l=8963; i=baptiste.le-duc@vates.tech; s=20260810; h=from:subject:message-id; bh=363shaoP1PKMvVqQ4rcQQTRNgWRYhD5p1oIMkSS7WCI=; b=UaAnpPOqSofDyk83hPMUdy/pOiGXCLg5pIe5/qYKvDB6NybeDlFfjaIrxieVq6msIFq4GZPvA I/oVqXv4xwUCBT9du+owyA/W6XhV9JjrtNf9UYIzQPSnlKt03atDiEH X-Developer-Key: i=baptiste.le-duc@vates.tech; a=ed25519; pk=N+BbdvMXRzrCuX/ieh4RWodiAKcLNvI+KjflcZ0oXCo= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1790341921937 X-purgate-ID: tlsNG-c201ff/1790341927-F4EA12A1-570026C2/10/73395122804 X-purgate-type: spam X-purgate-size: 8963 > Introduce imsic_vsfile_attach() to initialize the AIA-related state needed > for a vCPU to have a working guest interrupt file. > > A guest (VS) interrupt file must be mapped to one of a pCPU's > hardware interrupt files (if they exist), so the pCPU a vCPU will actually > run on needs to be known first. arch_vcpu_create() is therefore not a > suitable place to call vcpu_aia_init(), since the pCPU assigned to a > vCPU can still change before it is first scheduled. To avoid > reassigning the VS interrupt file id and remapping it to a different > pCPU's hardware interrupt file, imsic_vsfile_attach() is called from a > later point in the scheduling path (e.g. continue_new_vcpu()). Since > it will end up being called from a non-__init context, it is not > itself marked __init. > > Introduce imsic_update_state() to update a vCPU's guest IMSIC state > (the guest interrupt file id and the pCPU whose hardware interrupt > file it is mapped to) as a single consistent unit. This state can be > read concurrently, e.g. by a future helper that checks whether a > vCPU has a pending IMSIC interrupt, though no such consumer exists > yet at this stage, so it is protected by a lock. I have difficulties to clearly understand the aim of this function. In fact, if we want to know if a vCPU has a pending interrupts, wouldn't be enough to check hgeip[guest_file_id]? In any case, why does updating vCPU's guest IMSIC state would be required? > > Signed-off-by: Oleksii Kurochko > > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index 0782148b72..15b6bfffa9 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -155,6 +155,8 @@ static void continue_new_vcpu(struct vcpu *prev) > reset_stack_and_jump(idle_loop); > else > { > + imsic_vsfile_attach(current); > + > /* > * During a context switch to a new vCPU, interrupts must be disabled > * to guarantee that the vCPU's CSR state can be safely restored into > diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c > index 374a21ace1..ad638d7485 100644 > --- a/xen/arch/riscv/imsic.c > +++ b/xen/arch/riscv/imsic.c > @@ -212,7 +212,14 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v) > > void imsic_update_state(struct vcpu *v, unsigned int guest_file_id) > { > - BUG_ON("unimplemented\n"); > + unsigned long flags; > + struct vimsic_state *vimsic_state = v->arch.vimsic_state; > + unsigned int cpu = guest_file_id ? v->processor : NR_CPUS; > + > + write_lock_irqsave(&vimsic_state->vsfile_lock, flags); > + vimsic_state->guest_file_id = guest_file_id; > + vimsic_state->vsfile_cpu = cpu; > + write_unlock_irqrestore(&vimsic_state->vsfile_lock, flags); > } > > void __init imsic_ids_local_delivery(bool enable) > @@ -640,6 +647,16 @@ struct imsic_vsfile_data { > struct imsic_mrif *mrif; > }; > > +/* > + * Number of 64-bit EIx groups needed to cover all the interrupt identities an > + * IMSIC interrupt file provides, which are 0 (never valid, but it still > + * occupies a bit) up to and including imsic_cfg.nr_ids. > + */ > +static unsigned int imsic_nr_eix(void) > +{ > + return DIV_ROUND_UP(imsic_cfg.nr_ids + 1, BITS_PER_TYPE(uint64_t)); > +} > + > /* > * Execute func() on the pCPU which owns the IMSIC interrupt file func() is > * going to work with. > @@ -1138,20 +1155,90 @@ static void cf_check imsic_vsfile_local_update(void *data) > csr_write(CSR_VSISELECT, old_vsiselect); > } > > +/* > + * Point the vCPU's HSTATUS.VGEIN at the guest interrupt file it has been > + * given. It is applied to the hart when the vCPU's context is restored. > + */ > +static void vcpu_set_vgein(struct vcpu *v, unsigned int vsfile_id) > +{ > + unsigned long hstatus = vcpu_guest_cpu_user_regs(v)->hstatus; > + > + hstatus &= ~HSTATUS_VGEIN; > + hstatus |= MASK_INSR(vsfile_id, HSTATUS_VGEIN); > + > + vcpu_guest_cpu_user_regs(v)->hstatus = hstatus; > +} > + > +/* > + * Take a h/w guest interrupt file of 'cpu' for the vCPU: zero the file out, > + * map it into the domain's G-stage at the vCPU's virtual IMSIC page and > + * record the new location in the per-vCPU IMSIC state. > + * > + * HSTATUS.VGEIN is deliberately left alone: the vCPU may be pointed at the > + * file only when the file already holds the vCPU's interrupt state, which in > + * the case of imsic_migrate_vcpu() happens only after the old file has been > + * moved to the new one. Thereby it is up to the caller to call > + * vcpu_set_vgein() at the right moment. Nit: would clarify the paragraph here: HSTATUS.VGEIN is deliberately left alone: it must only point at a file which already holds the vCPU's interrupt state. The file taken here is zeroed, so for imsic_migrate_vcpu() VGEIN can only be updated once the state of the old file has been copied into it. Thereby it is up to the caller to call vcpu_set_vgein() at the right moment. > + * > + * Returns the id of the taken interrupt file, or 0 if none could be taken, in > + * which case the domain is crashed. > + */ > +static unsigned int imsic_vsfile_acquire(struct vcpu *v, unsigned int cpu) > +{ > + struct imsic_vsfile_data vsfile_data = { .nr_eix = imsic_nr_eix() }; > + unsigned int vsfile_id; > + int rc; > + > + vsfile_id = vgein_assign(v); > + if ( !vsfile_id ) > + { > + /* > + * vgein_assign() returns 0 when no free h/w guest interrupt file is > + * available. s/w guest interrupt files aren't supported yet, so such > + * a vCPU can't be run. > + */ > + domain_crash(v->domain, > + "%pv: no free h/w guest interrupt file on CPU%u\n", > + v, cpu); > + return 0; > + } > + > + vsfile_data.hgei = vsfile_id; > + > + /* The file could still hold the state of its previous owner */ > + imsic_call_on_cpu(cpu, imsic_vsfile_local_clear, &vsfile_data); > + > + rc = imsic_map_guest_file(v, vsfile_id); > + if ( rc ) > + { > + vgein_release(v, vsfile_id, cpu); > + > + /* Can't continue w/o correctly mapped IMSIC interrupt file */ > + domain_crash(v->domain, > + "%pv: failed to map h/w guest interrupt file %u: %d\n", > + v, vsfile_id, rc); > + return 0; > + } > + > + imsic_update_state(v, vsfile_id); > + > + return vsfile_id; > +} > + > void imsic_migrate_vcpu(struct vcpu *v) > { > - unsigned int new_vsfile_hgei; > + unsigned int new_vsfile_id; > unsigned int new_vsfile_cpu; > - unsigned int nr_hw_eix = DIV_ROUND_UP(imsic_cfg.nr_ids + 1, > - BITS_PER_TYPE(uint64_t)); > - struct imsic_vsfile_data vsfile_data = { > - .nr_eix = nr_hw_eix, > - }; > + unsigned int nr_hw_eix = imsic_nr_eix(); > struct vimsic_state *imsic_state = v->arch.vimsic_state; > unsigned long flags; > unsigned int old_vsfile_id; > unsigned int old_vsfile_cpu; > struct imsic_mrif tmrif = { }; > + struct imsic_vsfile_data vsfile_data = { > + .nr_eix = nr_hw_eix, > + .mrif = &tmrif, > + }; > > /* > * The scheduler can mark a freshly created vCPU's unit as migrated and > @@ -1189,25 +1276,10 @@ void imsic_migrate_vcpu(struct vcpu *v) > */ > new_vsfile_cpu = v->processor; > > - new_vsfile_hgei = vgein_assign(v); > - > - /* We don't support SW interrupt files at the moment. */ > - BUG_ON(!new_vsfile_hgei); > - > - vsfile_data.hgei = new_vsfile_hgei; > - > - /* Zero-out new IMSIC VS-file */ > - imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_data); > - > - /* Update G-stage mapping for the new IMSIC VS-file */ > - if ( imsic_map_guest_file(v, new_vsfile_hgei) ) > - { > - domain_crash(v->domain, "Migration to hw interrupt file failed\n"); > - > + /* Zero-out, map and start to use the new IMSIC VS-file */ > + new_vsfile_id = imsic_vsfile_acquire(v, new_vsfile_cpu); > + if ( !new_vsfile_id ) > return; > - } > - > - imsic_update_state(v, new_vsfile_hgei); > > /* > * TODO: Modify the relevant translation tables at all IOMMUs so that MSIs > @@ -1245,7 +1317,7 @@ void imsic_migrate_vcpu(struct vcpu *v) > vgein_release(v, old_vsfile_id, old_vsfile_cpu); > > /* Restore register state in the new IMSIC VS-file */ > - vsfile_data.mrif = &tmrif; > + vsfile_data.hgei = new_vsfile_id; Isn't this already done by imsic_vsfile_acquire()? Couldn't we pass a &vsfile_data in their arg so it could fill it instead of allocating one in the stack? -- Baptiste Le Duc From xen-devel-bounces@lists.xenproject.org Fri Sep 25 13:58:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 13:58:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433983.1654186 (Exim 4.92) (envelope-from ) id 1xA6Rr-0006ZA-HZ; Fri, 25 Sep 2026 13:58:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433983.1654186; Fri, 25 Sep 2026 13:58:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA6Rr-0006Z3-Eo; Fri, 25 Sep 2026 13:58:47 +0000 Received: by outflank-mailman (input) for mailman id 1433983; Fri, 25 Sep 2026 13:58:46 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA6Rq-0006Yx-3R for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 13:58:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA6Rp-008m4T-Gg for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 15:58:45 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab67df0-bab6-0a2a0a5309dd-0a2a4503d7d8-36 for ; Fri, 25 Sep 2026 15:58:45 +0200 Received: from [52.101.53.55] (helo=BL0PR03CU003.outbound.protection.outlook.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab67e14-fae8-0a2a45030019-34653537fb1c-3 for ; Fri, 25 Sep 2026 15:58:45 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by CH4PR03MB7554.namprd03.prod.outlook.com (2603:10b6:610:246::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.19; Fri, 25 Sep 2026 13:58:42 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0451.014; Fri, 25 Sep 2026 13:58:42 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Am+Hxo1MbpaZph7aF/dmVb5/2GQVDZ+LsBpImJSD+BCY/0n0KHK2CU/xzH+RTxqBvLVkClVk0kciHytmJWHJt0/YZa2OTjGn46eIUvdOUGjW3TEjs/DVO4J2QtGT60H2j50wg7HF8E8aI31IF5QT/50KohLBBRxXN6eAlq1rRfuSmpYCre7MmdRCq8QLoUu917Q/xv6Vt+bJVUlCLmBcQPRxo+mHfoIUitfIgVT8EAiz0MlDAyS/5gpg10/cIia8OwcftQ1j/0bxACD3/XqRKB8OdAM9/KX30jkthujHtdntiJE0yqlQW4KAGqzD9SSaYGQ7rvpOlb5k+P+oKbGuFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=m5Jl5dai22U+/VZ8ekwNoaCGJzjDo+NHI0gO9/ichfY=; b=YCIREIvrNUKQVqleR7VcNvBvjDR/N7hVqL1nHQrL7wNtKQ9uTqfbA03KfGRDgGX6vXQoqZ1H9A7HjqtqNrvSlIB5NwG1DXn1lTbawmD2BxIAB5vvf7Avu+DU9MmEW25uAdqofu3nK7/CuwVw9NCkUgWVFWMnTVl/jSsLtLyxAjrdEZIuZwjm4AIhVn3k4QUxf/P9o5Vdg+HDDSWRmqb0dSHEI1isP1Jjg3A0RvOT7CD8hcR6Gq7mAWBbxuNdNjqZBptUdPEGN7OGMJQtNM0LO8mUNhe24WE1ssIWNSZJlCweD1cu0ollQ//6ctJ31Nlz+7CfIiAja0MP2PArj4mFHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m5Jl5dai22U+/VZ8ekwNoaCGJzjDo+NHI0gO9/ichfY=; b=jHgrX71mBRjm6Sa9975VRfMVhLwQwGtHHqkLRUY6PATbN+/IhdiCZV1V5+9l/sNBrl79mQz1/vIke0n5GMGDesBD5ecUIaSU3HhcNC5cU4TIaPugwqR+GVFQtuV4STLv3q69hMm0mjP2vFlZkGMHGyO+MWfsE6a5KHQ3dbETTk0= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <558c120b-03e8-4942-88a9-2ba6528d8122@citrix.com> Date: Fri, 25 Sep 2026 14:58:38 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/mkelf32: correct VA/PA of PT_NOTE / .note To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Barr Detwix References: <5654aeb7-7742-41c6-a382-e1afac9d3bb8@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <5654aeb7-7742-41c6-a382-e1afac9d3bb8@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0245.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a7::16) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|CH4PR03MB7554:EE_ X-MS-Office365-Filtering-Correlation-Id: 09061cde-5c1d-4e70-fe8a-08df1b0d1b93 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|23010399003|10067099003|11063799006|56012099006|6133799003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: A6LzfmOF7yGGQgoUcT03oLaysC2RJ365knxkArsVXNfaRz0WU18zZF8fEBF+UZAA0nznnmxWxgtcCni2J6OllwBQ9VdYmHogXe88w9nQU1LDybLKH17CyJvU2BGk/Bl7M0LHwMXLsgewJSngzO5bMVnZ+Mqx5LvnduWy85EqS/CkDZILsyzckcY93fIiGORGbqM3aSEjJGIQbrMvq4SM0tww+Egsan2SdYM7+1nlf2yk388uslUyQp7yD9yNFopotHo7QZhPBmOX6sMICK/Lmnv/w6NGhrC/qWzsp4gipAKSwSoKv/rJK1lKTrn3efHF8ycxhvu3pP5TR6nwhc4nup6Gk6ab9FMNsEvnJ97t3XEVGjfJwILRLGNs3Pb3Zw75IjtXc40jQD86eqF4E5eGY/EnfTNjIkqMw5+Bqm77qsF9zCJE6S7dd8dDDCqjiyztUwsiYSk0K4ghqWccrvVuLzKhYRqgHiu1gPs9k/hwoljhrbiUTwjh4filaeBPNVIi4XhvB2OgR0OT+r34+fPIiS0iQqJfP42eOIZNtraJxZW2MZPFphJRJm9oUXB4FHpQvh6REwl+WCRkonCcy/rVlDLaKpmP6+TGniMzzJMYJWXKOT5cOpwfZ8ODO8gSO744rSjyKp2r6HRAHomvN06fpgvOviJcUm6VwaF3n2zEGGc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(23010399003)(10067099003)(11063799006)(56012099006)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q1hMOUxITFV2aHZ5WW9WNDNsVlhib3d1NklvZGk3Q2JTckI3TE11eWlhSmZS?= =?utf-8?B?UjV3Q3ZqRnkrcmZybmRiYk9lMHFKRkVjM1hVbXhPN1ROclNrdGNveE9DQ1l6?= =?utf-8?B?WmxRbFNFUGJDNWJuWk1IOHpTZG5hK3g5WTZ6UjYxWFgvUmdKalBWbjZXbUdO?= =?utf-8?B?QVlVaE14cFNQd3N1M1ZkcVhhUFNzUVhaUHVxZW5TSlBvWlEzdjRCRWJic2xx?= =?utf-8?B?a3pDaXlzRjBBNzFjaVpYY3lvSndNYjhCVHEwWDFVQ0RtRitiZzdKQ3BpVnA4?= =?utf-8?B?bTVkeTA4cHNSdHFJdkpkSHgxd0JsdHJEVVczZUhxamxVb3IzMGNkcm0waDU5?= =?utf-8?B?NGNRVFlYalRtQlVqcnRwbWcxL1pjcktZNTI2dlpDTDhOaEtFckxBOHl3eVI0?= =?utf-8?B?UGh6UzAzeGJ6MFNzdWxud2kvSTlxVzk1YjdRZVRDSnh4YWpOZHJWVm5RT0dp?= =?utf-8?B?dmkydVJiL2k1Q1RwSnk5SHlLTWlsMHJiWHhFQkVIZG03aGRiQmJvMWR0Wklo?= =?utf-8?B?YXVSZmdFazNFU21VYzBNbTVIa1pPRjRpVEJ4TThZQnRjYWZkbnBQVlczTndY?= =?utf-8?B?U1E2d3RIM0pYSmV6MkcrQytZTXQ4Q00vZ1dxVnFiQkZyMUF0WENxWlNxb01L?= =?utf-8?B?aXhXc1J6Q0gxbFFzeElxSGtNb2RQN2xMeXluQzBTSWVoS1FmWFVJRkJxSFBk?= =?utf-8?B?OXlSMis2UTFIa093VnlwWThkemtvYURZVjNDRWNDMVV1dGE0OUI2SWxvZ3JN?= =?utf-8?B?Qlc2YTlFdXRsSm1uS0RyZ3ZLNnZ4L3dHeld1Q1RyR3lqTDZBckRNUVBSL3RW?= =?utf-8?B?S1ZLNUVHSlYrK2loeEFIbmh2YlBldnkwZ05XK3hveHNUOHhxLzdZNStiODNK?= =?utf-8?B?YkZlYzFCWGRzanlvMjhpRE0wSm9YRXZ6WGVSblQyN3FSNC9NdzJzU1E0SERO?= =?utf-8?B?OUQ4amt3akszRmc4U3ltQks5ak5kY3pCWVpYeW1LREQ3VFVSczlMNjFrV24w?= =?utf-8?B?eFFKcEJRVnM3N3VLTjF4VXRjMHgweUFHdDdjQkVSOFhtZGk2VjQ2QURDUEpQ?= =?utf-8?B?YkJXZlFHRVNvWWE5cG90TTkxbGs0SkNieE1mVlFLZWZTYkpnaDdBdmRaV3RH?= =?utf-8?B?ZWkrZkVZUVRsdTcvWXZaaHR0b1djMy9GSithOEE1czN0SEpBYXF2YzdNelVE?= =?utf-8?B?SGRqQ3hqZzUxZW1LRjNWcXAxSEUwbHlPZzc2dVNxdm5uZVcyUmVydGdJRk1W?= =?utf-8?B?ZWgzd0p6SWNyeXJYclo0d25tdXZPbnptVi85UFdEU2YvS083QXJELy9oRm9i?= =?utf-8?B?RnFhemtWTHVBZUFvMzNGZ0NWdVVxejN4c0VEMzg0OTJ3QUVUNTNmYWEyc21H?= =?utf-8?B?SFZzVmdSM0xPZjE0ekJwSVF4cUVmbGdUOTB0OTd0WDVzblJLUU5hRDY4WHlJ?= =?utf-8?B?MlFzeHc0S0hjUTYwQ0JJcTFPRnhvNExvWkhIK1lMajhUTlNCenVsVzYwcFRy?= =?utf-8?B?Nm5uY25XeW5iTkFZa29Ic3FmblVWNlZxNjhDU3BBV2lFaHVPQmFUZ3FIbXJ6?= =?utf-8?B?UDk1Z2tqbXVkQ0JNTnRRd1ZKbDMyVFNLY21odzNqRXM1SEwvWDBObDNNakhI?= =?utf-8?B?cGNIZ3lDcVV1UlRZNWtvRml2M2dtWkl6a05uUmFjWi9qdVREQTFQRjJUUWJ3?= =?utf-8?B?U3RKVWRzbVBXQ01kK0w5OTlkU2pyNlZaNDhEYjJQdU4yVkRzcGM1ZGdJY1pt?= =?utf-8?B?dnpOVDFIekhsaHIwN0NXSmhZR3dFbkhpWE4rTENmUDZMQjdkK3B3VStCRmUx?= =?utf-8?B?OWZNc3AxTEZqdWx2a1JVZmlXalY1YjdWSEtYalFzeDR4d3VWeS9Zam1vTzNr?= =?utf-8?B?eC9PNjRSOEV6N3hmWW9NNDFyVzV1Y3NVYXZ1dEE1RmdFVmtaK3JIR3Avd0Rq?= =?utf-8?B?YmlqQTBlQ0RTTnM1Wm1TRWFybS9KL0YxTUNvVllYSEEycytLYWZaekVrRHVQ?= =?utf-8?B?TXRrWStCY3B3N3BMNDNZeUNndEZhVzZoT2NWTkJKYkZrL2ZzVWk3MjJyZFJm?= =?utf-8?B?SklHYjg0aWE5UTZVaXltWmNmM0NGZGNYeHVoc0s3K3ErVnpJRUFEZG5haXhn?= =?utf-8?B?REo5MHh0Nzhpa3QydkpYa1FyVC9xVFkyUTY4VC9oTHkzSkpZUW4wWk9nVEph?= =?utf-8?B?S3hLcGhGcUV5WFMwTEJEbzhNVEkxWDRacHpFQkl6RjNucHR3aTdKM213WlYx?= =?utf-8?B?TkV4bHpEc1VOdXFRY0FodjM2Z3N3ZmthbnFvZ3ZrZFZSbFpQT2lzQzZxVFR2?= =?utf-8?B?ekVibGRkazFNS2d1MUhqYkhuQTB5MVI2U0RuNFd2YUxpZmNPT2hkeXFVT0dN?= =?utf-8?Q?mx80aAPmM1/iHIx0=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 09061cde-5c1d-4e70-fe8a-08df1b0d1b93 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 13:58:42.3037 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: O588fRZRr7vf3d3XdS2x02BTKpu43AopQ7ZiSPfhkcCkRzvlhlCM0rdXxLCk/s4o4K4zZZQeguttuwPAjgWfiNuMXhJulOuo9kKlIrBk3K8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7554 X-purgate-ID: tlsNG-33051d/1790344725-6FEC24E9-4900472C/0/0 X-purgate-type: clean X-purgate-size: 2263 On 9/21/26 11:18 AM, Jan Beulich wrote: > For the .p_paddr, .p_vaddr, and .sh_addr fields the image load base > (passed in by command line argument) also needs taking into account. It is > _not_ merely the delta between incoming PT_NOTE and PT_LOAD segments. (The > fields aren't really used anywhere, so this is largely a cosmetic issue; > static analysis tools may be affected, though.) > > Fixes: a353cab905af ("build_id: Provide ld-embedded build-ids") > Reported-by: Barr Detwix > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/boot/mkelf32.c > +++ b/xen/arch/x86/boot/mkelf32.c > @@ -362,7 +362,7 @@ int main(int argc, char **argv) > (void)lseek(infd, offset, SEEK_SET); > > note_sz = in64_phdr.p_memsz; > - note_base = in64_phdr.p_vaddr - note_base; > + note_base = in64_phdr.p_vaddr - note_base + loadbase; > > if ( in64_phdr.p_offset < offset || > in64_phdr.p_offset + in64_phdr.p_filesz > offset + dat_siz ) > The diff before/after shows the note section and program header addresses moving by 0x200000 as expected (with no other changes): @@ -24,7 +24,7 @@ [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00200000 000080 2df354 00 WAX 0 0 64 [ 2] .shstrtab STRTAB 00000000 2df474 000018 00 0 0 1 - [ 3] .note NOTE 002072b8 207338 000024 00 0 0 4 + [ 3] .note NOTE 004072b8 207338 000024 00 0 0 4 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), @@ -36,7 +36,7 @@ Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x00200000 0x00200000 0x2df354 0x400000 RWE 0x40 - NOTE 0x207338 0x002072b8 0x002072b8 0x00024 0x00024 R 0x4 + NOTE 0x207338 0x004072b8 0x004072b8 0x00024 0x00024 R 0x4 Section to Segment mapping: Segment Sections... Reviewed-by: Ross Lagerwall From xen-devel-bounces@lists.xenproject.org Fri Sep 25 14:05:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 14:05:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1433995.1654207 (Exim 4.92) (envelope-from ) id 1xA6YL-0008Sy-9z; Fri, 25 Sep 2026 14:05:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1433995.1654207; Fri, 25 Sep 2026 14:05:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA6YL-0008Sr-7B; Fri, 25 Sep 2026 14:05:29 +0000 Received: by outflank-mailman (input) for mailman id 1433995; Fri, 25 Sep 2026 14:05:27 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA6YJ-0008Sl-OC for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 14:05:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA6YJ-00Ejoh-4z for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 16:05:27 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab67f98-2eae-0a2a0a5409dd-0a2a4501b570-34 for ; Fri, 25 Sep 2026 16:05:27 +0200 Received: from [40.107.201.19] (helo=CH4PR04CU002.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab67fa3-5984-0a2a45010019-286bc913fe59-3 for ; Fri, 25 Sep 2026 16:05:26 +0200 Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA6PR03MB7566.namprd03.prod.outlook.com (2603:10b6:806:445::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Fri, 25 Sep 2026 14:05:20 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%7]) with mapi id 15.21.0451.014; Fri, 25 Sep 2026 14:05:20 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=slQyalvPXy074FvSOBcQqPcEp3gKd1ToUdiNgApIAdkJs/768McgFOvMEofDXzV54DB7/lJpIRy6II5CGbK2s79jeo3AbTvS0XvjEJ9A8YorO/tRu6FsrxhBrtdr+XcpIyhnQKTLp6kKv3xMLVnmRPvZea0+uQLtjXWV+P7znj3AhAWVIZko66yrJiPSKNTm/KkGm+m5nELY8OlxYrAJtoqHgP2oIMgSH1CFfx0lNvCCXVDv6iLvOjxQNpo0X+YJ1+R7+zMM01sgWZtFzJlR+n7a67FCcM+ST6Mj/5Xzjm+VNwFujDztfSkAYeU/KGR3n+Jw6V9L0ZuFjoEib6IpSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=x9cjY50GlJqRI6N1ZG5GlFtNoIlY8tNmqZe0hQJyUCs=; b=X2SHgKrZIDXRWhyaAu3oZncvK1omq/UWuSp31H0uAHYz9TCuqVkWYMizm3y+VbzgYRGrwACwCoerJilrj1m4pUkqzNfDqyyW1hd7dyqiAwnKdAkqMyC017S2ZamdkKwHwZvwmGgpNhFgdAwKMQ0979YXbBaT/RlXrZLYylIdScHyhGzCu9BSBraAYmMdZkXRq06xzFCCqJzx4TJsWFoVUUeYGjWszsbS3Wj55f+vgV/En6gf9vXQdj1TW6Doc6R7Ijwc1kDgu5V6LSiKmrxdJSbOYysTnHHeFSMjcJlKPm7NiyN/An/u52x5V2oFFJei/Box2gvPcnqs9bgUQp488A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x9cjY50GlJqRI6N1ZG5GlFtNoIlY8tNmqZe0hQJyUCs=; b=i6Uh5NamZr8LpB0Ko8zs5qZe954IzQz1bHJRPyHhXm+QsAB9yQ/cPON1JA/1VqV/Dksn+VOxglqYLy07K8bgZA/xoTzGU4bGwEg1ZHQfXUv4xkXah5l1J5r3jj25VubPjfD36zUuLF31A+h7IaRlvcJVoAYDMywzJ87xlqqPW9o= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 25 Sep 2026 15:05:17 +0100 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Barr Detwix Subject: Re: [PATCH] x86/mkelf32: correct VA/PA of PT_NOTE / .note To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <5654aeb7-7742-41c6-a382-e1afac9d3bb8@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <5654aeb7-7742-41c6-a382-e1afac9d3bb8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO6P123CA0028.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:313::20) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA6PR03MB7566:EE_ X-MS-Office365-Filtering-Correlation-Id: b8561c19-2455-4e8d-c5b5-08df1b0e08f8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|376014|11063799006|6133799003|10067099003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: DagVsBgaKesdVai3/MJf9xHWPq7rfKo6j2BPRDtmxWp7mdW8kIv2wK5wHc7bbP2UwoYWwM8eSU5/XqXzo2xQY4GISlgbpeZBmSS0CmVkH9ziMOfWEycmGBegLSiWB8rjR7xcnFu13BpF4+JD1/3m6ZpMRXHeeAqqoQTuBbUVFgR4BcS0u7Q3K2+4HlOeZwE8140g60kVzGSECI5ZmsCFfYfHR5QEzfEwQeD0xBqn4HSneNnvDywWbfDQZXvOC0yc+NhuF0EApfW2r99kGcQKW3/OzBg+PespgAwQBzR45OQJ0cJl9WMPu7u2qUgoTfTdLW1lg1ryj8j1bmMhCUvWg7mx0h83QTuXTgAv0T/5r76rA0D457RHNIicQSCO8KaNILcKjgDqNXowdOhIhKoh55HRLcQGuHC/xgM9m/nV8b0Nn+L32R+EmqQ6dTOf4sfX3sJgw7sUUxQCQzB4h/9vQnn6l6hD1I4yhs3hUgHemlsAkBHzDyIu5L9DpXBZ3/haPrwtRv75mJK9ea0z3XEegyYBQ6/oIhLVIrOHuvf0ceevs0N1QcEztN2aQ2xMM3RuSlhGHuXisCo8bbVeRy/zTPOQxHpwzpUn2Yda97ufbhpzU7LutSOr2jgXX7mNBj8vhkBcLbjqhp3Tr9tZBvf20+18cb6kvq9vA2rx6TERhGM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(11063799006)(6133799003)(10067099003)(56012099006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SDhyaURmM2V1MzY3TmhIVDRCS1p5M3VZZzhMRzhWQWpqTlFCckgzeEhoTlJJ?= =?utf-8?B?YlB1RlltYlUxUTV3aUkyd2thcWpkdHI0eXdhYmdHVkdWcGJZVjU0RFZraERs?= =?utf-8?B?VU9Vd2Q5dUNNTHZacTNBWE9OUXBtVVJqMW5XZkF6SmVoN3lkdkQ3djN6SU0w?= =?utf-8?B?dC9wbHloaCs1L0EwM000c1Z1OGhiS0VBWDY0dklZUDJ5eXl4RXpkWXJrVmJP?= =?utf-8?B?aisxVmdTaHM4RTJwdm81eFVhNllSbmgxNjNGOW9CbkxqbGFMcGxmdWs1b3Rp?= =?utf-8?B?eDVmcGhVQlBZck83em56OW4wVFFZWmZVczQyTTJLL0xteHIvLzgyejlOaGpR?= =?utf-8?B?VGhlbll0bWdsbWhGUm84TzVXZEp1L0VPK0JNNlhtV2thNlBqc2YyQVNvYkIw?= =?utf-8?B?VmhDc0FWVHZiZFltbG5kNWFrNkJ6SThBWnMrVXdYWEd1UElSZGk2V21Tdjcy?= =?utf-8?B?TGN1TUxWSzNtQ0hwaWRWQzMxUWxsOFdnbkJ6WjZFaFgwQ1FUNXFjbTluRDVC?= =?utf-8?B?Qm9pOWNBVDZ1Rzd0SXRERk1zc0RxV3VnWjY5UFNZdVF3QWdoRnhQanlEc1F2?= =?utf-8?B?eW5EOE5jYnBaTktmUXUyNGxRNWJrQnZKRndhRkFnSWdyUkNOUkZLMjdFVTVZ?= =?utf-8?B?QXhRWEJKSkVlQ2ZxRXFBcWp6VzZPaUd4L0QyeWpiWXRZQmN4Qzh1KzJtTi9O?= =?utf-8?B?VVhHTTYrYVE2SXY3ZDNpNnRZZ3ZmU0hpY0JDcVJydVl0M3VTb1RTWjFTWDFB?= =?utf-8?B?VXB5M3d4UVA5M2Z0eDJGUnJlUzlYTENRTUEwQWVObkQzb29KV3hHc0Myb3NR?= =?utf-8?B?MmJ4WWZMZEx4VGV0TkpUUmxKZ1F5TVM3eVllUjNRYm1xV2VTaFNPa3l1Qjlt?= =?utf-8?B?Q0VEZUVvOXhLUmRaMjhBTjkxRndJTVFPZlE3cEFnVDM0bzNXQ3hHaUNaTDJs?= =?utf-8?B?Z0VkeVpLV1VmQ3c1Q3FlNEZkRjVmVW40NnRWYXgzbWx0b3NIdUdYVFF1cEcv?= =?utf-8?B?Y2p5SkJiSk9qaW80VnpUSDYrSzVkSUpKVnNDSkRnYVFuaEZnMzd4VTdQU3dY?= =?utf-8?B?dkZob296aS9FZ0xDVmt0TVJUemZldUY5dFZnYkNlTEh6cUZZaXYwUGg5OWlO?= =?utf-8?B?M1pCUGduWTViK0YwQUdidkhzTFlOdzBLaDhUQ01wejhBelc3MmQvMmRoSmJK?= =?utf-8?B?TlVqVTBTTE1ZVW5jalBuSWJFZFR1aVBzM3hYWUVLRG4xWUZQcmROYlBTOU5O?= =?utf-8?B?QWdpK2hXU0U1aFBPdGgwbXZNWlRndjljbHUvMlJhVkwzM3Rvb2lCRFR0NFc5?= =?utf-8?B?V2hVTThWV3pKVzZxZ0ZWKzA0RzR1d3kxZWZJV0tpa2VwU2tWeEs1YldoM3hR?= =?utf-8?B?d09Ib1lpNnF1UzNDYzhMQnFNaUR2clBxb2kzdVhGTE0wQmdZSG5vTkxlTGta?= =?utf-8?B?cXNQaTJsa2FKT0NtK1RmejJ4M0FsQnVGTTJOOFhOeXlQSDdtWGE5VnNDL2RJ?= =?utf-8?B?ZXhOQXgvM0o4Q2k1UjNqZDFrQzZqbStuQi92aUxZdzc3RU13M2Nxb1FYd0oz?= =?utf-8?B?NGRmVHBPYTN6UzZMMnVyTWVTWm1JSjgzbG8yRG1tYVZIdTBvL2JINllQZXdp?= =?utf-8?B?ZFFoRVJKNDVTQmx1VlpkUTE0MHhhN0RpMEZKbVY1dHhJeExjNFNZNmNoUE12?= =?utf-8?B?M1dOT0xKU2NlZHZzV3hmVm14cVk1YkluS0lUOFBOTE9lbXZpb1N2MGJEQ1Nl?= =?utf-8?B?TnZHZUtIL0ovcHlMY1M2dFlONm9jT3NTc1ZNb0liYUhERSsvMUI1bEcyYXpR?= =?utf-8?B?Tmt3VXZVMWIwSzRQdnErWVNXZUJUV01jT1I4bFU5elJ1V3d2T2cvdUZOeXV1?= =?utf-8?B?RjFTbWpVMlNaU1R6blZNMnA4aDNySndRekp4OFVMNStWYmU0N3ZKQUtNeDBz?= =?utf-8?B?eDdKL0dtRTNMK09DSDlrSmN4elZESnFydDdiNE8xb0ZxNlhWbzJFQVd0Qkxv?= =?utf-8?B?dmszSXRFUFFqNk0xOG9YK1o3TnIzcklGaXlCSnlXUjE3Mk54R0VLOW56bXlN?= =?utf-8?B?ZDl0VUdvNjg5eXF2YUN3OW1CTUd6eVFHSm13Si9ud1ltbWxMTDl6S3JHeWdJ?= =?utf-8?B?TFdQU1pkek9KMi9IMTF2Y1lBM2NzR0dqOHJkRlNnMXdGZ21uWE5FS0xwVWdF?= =?utf-8?B?a3BGWmJ1QXlZU1ROWU9nVWNNVjIySStFTlA4MmovT0YvMmtEQkdFcXhyait4?= =?utf-8?B?VWVFZXB1QTdnUnkrM0ZNV2JjQ3ZmYXA2Qi9Td1NSVHdwU25Ic2h2cWN6OURO?= =?utf-8?B?dG92cXRpOVVsYms0eXFSSXFNYTI0MTI1WUpSbXlNbGUxbVJNbDJ5QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8561c19-2455-4e8d-c5b5-08df1b0e08f8 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 14:05:20.4696 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: oC5vksmSe4d22aF64vp4hF+gW4PidSRKPWFIa+4DZOEYFEq+Soblm5jKXhHFuQjUISK15TL4aL7lbxOnes4YOxUlwT0xDOmPpDvEtB1j9GI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7566 X-purgate-ID: tlsNG-d62444/1790345127-C4558757-FD6004EC/0/0 X-purgate-type: clean X-purgate-size: 629 On 21/09/2026 11:18 am, Jan Beulich wrote: > For the .p_paddr, .p_vaddr, and .sh_addr fields the image load base > (passed in by command line argument) also needs taking into account. It is > _not_ merely the delta between incoming PT_NOTE and PT_LOAD segments. (The > fields aren't really used anywhere, so this is largely a cosmetic issue; > static analysis tools may be affected, though.) > > Fixes: a353cab905af ("build_id: Provide ld-embedded build-ids") > Reported-by: Barr Detwix > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Sep 25 14:53:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 14:53:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1434048.1654224 (Exim 4.92) (envelope-from ) id 1xA7IV-0008Q7-23; Fri, 25 Sep 2026 14:53:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1434048.1654224; Fri, 25 Sep 2026 14:53:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA7IU-0008Q0-Un; Fri, 25 Sep 2026 14:53:10 +0000 Received: by outflank-mailman (input) for mailman id 1434048; Fri, 25 Sep 2026 14:53:10 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA7IU-0008Pu-FA for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 14:53:10 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1xA7IT-00HK5S-1q; Fri, 25 Sep 2026 14:53:09 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1xA7IU-00E3ET-01; Fri, 25 Sep 2026 14:53:09 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=cKgd+tI4dxOZUQqh15UU0xyjZst2EIx2YSicB8gJbcI=; b=fkpxkoQuIHR0ZC/Ac26cY3edIr tySKk0IMRh1ATvBFCcv8dfWykJZ4h3VuVJtlGv3hioGrJpISWVWf47kN0/MuA81JHAOe31V62Dajf qlRrkrOEfJI9mXRZcB1MlrIlJyjHfAr+iEI9nidhKW3x0DqPnf2IgAHJ7/827xbVtcWA=; Date: Fri, 25 Sep 2026 16:53:02 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Julian Vetter Subject: Re: [PATCH 2/6] x86/pass-through: no locking around pt_irq_{create,destroy}_bind() Message-ID: References: <92b0a72a-44df-424f-acbe-58d7167f1c4d@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Sep 24, 2026 at 11:57:19AM +0200, Jan Beulich wrote: > On 23.09.2026 12:37, Roger Pau Monné wrote: > > On Tue, Sep 08, 2026 at 03:01:51PM +0200, Jan Beulich wrote: > >> The questionable use of pcidevs_lock() there was discussed more than once. > >> It really is pointless: The functions synchronize primarily via the per- > >> domain event lock. They also may already be called with the global PCI > >> devices lock not held: See hvm/vmsi.c:vpci_msi_update(), > >> hvm/vmsi.c:vpci_msi_arch_update(), and hvm/vmsi.c:vpci_msi_disable(). > >> > >> Signed-off-by: Jan Beulich > >> > >> --- a/xen/arch/x86/domctl.c > >> +++ b/xen/arch/x86/domctl.c > >> @@ -636,10 +636,7 @@ long arch_do_domctl( > >> ret = -EPERM; > >> else if ( is_iommu_enabled(d) ) > >> { > >> - pcidevs_lock(); > >> ret = pt_irq_create_bind(d, bind); > >> - pcidevs_unlock(); > > > > pt_irq_create_bind() might call into msixtbl_pt_register() which > > requires either the pcidevs_lock() or the per-domain d->pci_lock lock > > to be taken, which I think is not the case in the context here? > > Hmm, indeed. Not having seen the assertion there trigger kind of worries > me a little. Do you agree that the change to vioapic_hwdom_map_gsi() can, > otoh, be left as is? Hm, I'm borderline on that one - I can't find a path where d->pci_lock will be needed for legacy PCI interrupt binding, yet at the same time I feel it would be better if the locking context is uniform across call sites. I guess I'm fine with the asymmetric locking context if that's your preference. Maybe worth a mention in a comment somewhere. > In turn I will then extend patch 3 to also tighten the assertions in > msixtbl_pt_{,un}register(), as each of them has only this one call site. > Would you mind indicating whether in doing so I may retain you A-b there? Please keep the A-b there. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Sep 25 15:34:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 15:34:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1434103.1654249 (Exim 4.92) (envelope-from ) id 1xA7w2-0006SR-9m; Fri, 25 Sep 2026 15:34:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1434103.1654249; Fri, 25 Sep 2026 15:34:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA7w2-0006SK-76; Fri, 25 Sep 2026 15:34:02 +0000 Received: by outflank-mailman (input) for mailman id 1434103; Fri, 25 Sep 2026 15:34:01 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1xA7w0-0006SE-RF for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 15:34:01 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA7vz-009I28-TG for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 17:33:59 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab6945f-2eae-0a2a0a5409dd-0a2a4506e79e-20 for ; Fri, 25 Sep 2026 17:33:59 +0200 Received: from [74.125.225.76] (helo=mail-wr2-f12.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab69467-195a-0a2a45060019-4a7de14cd7ae-3 for ; Fri, 25 Sep 2026 17:33:59 +0200 Received: by mail-wr2-f12.google.com with SMTP id ffacd0b85a97d-482f635552aso792727f8f.2 for ; Fri, 25 Sep 2026 08:33:59 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-71-234.play-internet.pl. [109.243.71.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4887a30bcdbsm8084341f8f.2.2026.09.25.08.33.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Sep 2026 08:33:58 -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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790350439; x=1790955239; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=rC0/FChRcP6WDbGZE0Y4ocaflYft5ulQPnAvFiX7l2Q=; b=n0yRXN0totprKiLdM0xhEoyqJqvDKThjQn4arlMymQOfaiXeBs17ilrbJ6/99ddZXT BYjqvegLmykn08ZN95LLxSa/8tSJVTUbsfg0dk8SgGj3DKMbVLE4dBaDoH1ZdkkU3jKr 2DwK0mJvyUAwYW225TDPQ58+s2R7/SGa73DNHXFYtdy3qZR+KrR1/oNFqkFFVPnDaeM2 kvF8H/WNjGcBOdmNrlITpDWrCapyMWUU6c25QvuAd8lpsd41jNYw6moz3S6nNjWvGtpr iy8y2uK9UvFyBYowGnUTaA6BBgOjdQxAAZbtY8an4HP28DZhcznutHA/k/sE1PT1yQDc /iKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790350439; x=1790955239; h=content-transfer-encoding:content-type:in-reply-to: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:content-type; bh=rC0/FChRcP6WDbGZE0Y4ocaflYft5ulQPnAvFiX7l2Q=; b=YIAiSqSO+aZDANYmgFdWdRvbks9OiW2+qnG7qDqY291GCi1cg+pN4x9cCibDFK6GD8 90NtMvsJZbcjU8AQfoiXTYIY1Kbq5j9YRdOgfsM/HA4zf1PylB03j8tGhu9nbrku5hXk PRqlvoNbSX9afgYBtmB31mRPB0IfChnE+gul8CUFa3+OkzWxjsy2AMVOvXokrdj7IDfW iVJ8gGz045qgZk7D2RB3oo5UfngMNQG6gzJ/RbMQ+k7i5p2Qpv1DUngOQFmxnJjOXD0R D/41gZs8pPpir0UsGFRQR3azl2zeDLLdMkDd/EgJdcUgASsPMh0oa0uzSkxdgeUAkGYO kKrQ== X-Gm-Message-State: AFuF++kkGjjLY/gJS3tkBKnltB9UnrZacKwBazX0pYu/tH5SGOyvn6i1 izyvQm3qqQpEB0sp9ZhMG1amf3I0fkAr45d4T8oAjys2b/yQ9wvPNss4 X-Gm-Gg: AYBFou09OTHecU2JfEmKaNLSaXuDDEYih3Keat0IxC76kLukmCL+ukPMCqqvwdOJCVW 2a0+T4VI96SU/QwbuCQwtPOReu/YEmgnJvjcU4IDt5Ph84/OXganFqIfTl/c91znXyamMhUAZGE 8jMlzy03PxGAqf1gmxg9EGoF239PPIL8HCohPbvkAsnPqV1qlju16o974rPAYJRsYneSnSSdsT6 pRZftagr7noK87lvDzeS5NNLJzid/qGl5LrTY/fFvmHXS9Dr5Ap1Uj97YcoNKAaOATLC3HAwFrL DYkExxJ0AW1XDKwHj1Q5F3CBUL8Vu51wqN+HPLr5T5nbwX5LEeNl6DwK0U8Jkt2iJYJJ3F3XVgL 7RDOnjnZ92KzSNZLhNzjOYx/p1OjwRUs7HJAE1zf5xN1a+DvDVogEZTkvqHL1ibvCmE5ZRxhx0s 9+5FfyjYq8bFnqnTaxlrlofASbwV3AzqHxUAw3yTkNHYHJbFkNzN+Zj/xmtSsqJVv2ENfPsOJmX vTCqAM0iqjWU+zt0lcouKHN1XZyORvRy5qIbRuZAZUwXW/ibw== X-Received: by 2002:a5d:5d08:0:b0:487:35c:6e6b with SMTP id ffacd0b85a97d-48872a5c2d7mr11484312f8f.12.1790350439174; Fri, 25 Sep 2026 08:33:59 -0700 (PDT) Message-ID: <8ca6e469-862f-4373-8dc0-0d3b01f89c8a@gmail.com> Date: Fri, 25 Sep 2026 17:33:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt To: Baptiste Le Duc Cc: xen-devel@lists.xenproject.org, Romain Caritey , Zheng Zhang , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini References: <1790259947.8631fc262581453bbf619ec5b2062170.1a0d3cee79600072c4@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1790259947.8631fc262581453bbf619ec5b2062170.1a0d3cee79600072c4@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-16d1c6/1790350439-1ECC577B-829624E6/10/73395122804 X-purgate-type: spam X-purgate-size: 3713 On 9/24/26 4:25 PM, Baptiste Le Duc wrote: >> While a vCPU is running, MSIs written to its h/w IMSIC guest interrupt >> file are delivered straight to VS-mode. Once the vCPU is descheduled >> nobody observes that file anymore, so a guest blocked on such an >> interrupt would stay blocked until some unrelated event happens to >> schedule it again. >> >> Let Xen observe the file in that window: on deschedule set the vCPU's >> bit in HGEIE, which turns an interrupt pending in its VS-file into an >> HS-level SGEI, and clear the bit again on schedule-in. HGEIP only >> reports a file number, so to get from it back to a vCPU keep an >> owners[] map per pCPU, filled by vgein_{assign,release} alongside the >> VGEIN bitmap, and kick the vCPU it points at. > Nit: I would reword the last sentence to make it more clear: > > HGEIP only reports an interrupt file number, so to find the vCPU to > kick, keep a per-pCPU owners[] array indexed by file number and > updated in vgein_assign()/vgein_release() together with the VGEIN > bitmap. > LGTM: I will apply your suggestion. >> >> +/* >> + * Start to observe the interrupt file from HS-mode, the same way >> + * imsic_ctxt_switch_from() does it for a vCPU which is switched out. >> + * >> + * The counterpart, clearing the bit of the interrupt file which is left >> + * behind, is done by imsic_vsfile_local_read_clear(), which already runs on >> + * the pCPU owning that file. >> + */ >> +static void cf_check imsic_local_hgeie_set(void *data) >> +{ >> + const struct imsic_vsfile_data *idata = data; >> + >> + csr_set(CSR_HGEIE, BIT(idata->hgei, UL)); >> +} >> + > Sorry I'm a bit lost here, are you doing that for vCPUs migration? > Because in your commit message you only mentioned scheduled-out case > which needs to have Xen observing the descheduled vCPU to re-scheduled > it, but no other case that would need to have interrupt file observed is > explained > Yes, this is for migration. A vCPU can be migrated while it isn't running: e.g. a blocked vCPU whose affinity is changed (it is moved by sched_unit_migrate_finish() and stays blocked on the new pCPU), or the vCPUs of a domain moved to another cpupool. Before the migration, imsic_ctxt_switch_from() armed the HGEIE bit of the vCPU's interrupt file on the old pCPU. That file is released as part of the migration (and imsic_vsfile_local_read_clear() clears its HGEIE bit), so afterwards nothing observes the vCPU's interrupts anymore: the vCPU isn't switched in on the new pCPU, so imsic_ctxt_switch_from() never arms HGEIE for the new file. A blocked vCPU waiting for an MSI could then stay blocked until some unrelated event wakes it up, possibly never. Hence imsic_local_hgeie_set() arms HGEIE for the new interrupt file on the new pCPU. As HGEIP reflects the current state of the file, this also covers an interrupt which was already pending in the old file and got carried over: it raises an SGEI as soon as the bit is set. For a vCPU which is about to run, this isn't needed, as imsic_ctxt_switch_to() clears the bit anyway. I'll describe this case in the commit message: ``` The same applies to a vCPU which is migrated to another pCPU while it isn't running. Its old interrupt file is released during the migration, and the vCPU isn't switched in on the new pCPU until something wakes it up, so nothing would observe the new interrupt file. Hence arm HGEIE for the new interrupt file on the new pCPU in imsic_migrate_vcpu(), and clear the bit of the old one in imsic_vsfile_local_read_clear(), which already runs on the pCPU owning it. ``` Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Sep 25 15:39:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 15:39:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1434116.1654258 (Exim 4.92) (envelope-from ) id 1xA80o-0007Cn-QM; Fri, 25 Sep 2026 15:38:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1434116.1654258; Fri, 25 Sep 2026 15:38:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA80o-0007Cg-NV; Fri, 25 Sep 2026 15:38:58 +0000 Received: by outflank-mailman (input) for mailman id 1434116; Fri, 25 Sep 2026 15:38:57 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA80m-0007Ca-RU for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 15:38:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA80m-000ccq-89 for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 17:38:56 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab6958a-bab6-0a2a0a5309dd-0a2a450384f8-6 for ; Fri, 25 Sep 2026 17:38:56 +0200 Received: from [195.135.223.131] (helo=smtp-out2.suse.de) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab6958f-fae8-0a2a45030019-c387df83d256-3 for ; Fri, 25 Sep 2026 17:38:55 +0200 Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4CEB51F786; Fri, 25 Sep 2026 15:38:47 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id DC0E113274; Fri, 25 Sep 2026 15:38:46 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 5C4DK4aVtmoPOgAAD6G6ig (envelope-from ); Fri, 25 Sep 2026 15:38:46 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt"; dkim=pass header.s=susede1 header.d=suse.com header.i="@suse.com" header.h="From:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Autocrypt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790350731; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Q7E+UxpSbSVKgIapvkQ6Zr4zHvBWYuY5FDhOnkjFOJw=; b=MkOKJdrYpbH20iat/Xwt07OOV6JJUWfoivW+A2sE9YajFmQBvCRt+KCwUloD8nLJnUXN+Y bbWkr+9k9YeaEQhHVbilGKIHV3SeP7l6yYz9JYEUCYLebfRYoi5sxSPKwy0w3Qy7txzJd0 +iBwt+P52hbl1/SLq/7NbqK9GdtQznQ= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=nBbbPTOb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1790350727; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Q7E+UxpSbSVKgIapvkQ6Zr4zHvBWYuY5FDhOnkjFOJw=; b=nBbbPTObp3gDQllql9JNDucUxkPV0bICklGMESfcvIvwv11p30wy9q0CSIOZ0675fNUiIC vt3vmxUHEtWKLNIAANblr/X0uDxHUaO6UjIaMTYlCcFv7VPLLTKawveb0N2L4WtD/gxSwl hSKLEysG1diwQZKIXqPN+k08G8OFuDM= Message-ID: <3a2f0678-f81a-47cd-a47b-af9b439cedb3@suse.com> Date: Fri, 25 Sep 2026 17:38:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/gntdev: prevent private mappings from becoming writable To: Abdifatah Suruur , xen-devel@lists.xenproject.org Cc: linux-kernel@vger.kernel.org References: <20260819084217.1577-1-suruurism@gmail.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260819084217.1577-1-suruurism@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------gD9bE6JzZy8Y0hi00bZF6K5L" X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 4CEB51F786 X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MX_GOOD(-0.01)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FREEMAIL_TO(0.00)[gmail.com,lists.xenproject.org]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_TRACE(0.00)[suse.com:+]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_BLOCKED(0.00)[suse.com:dkim]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:email,suse.com:mid] X-Spam-Flag: NO X-Spam-Score: -5.41 X-purgate-ID: tlsNG-33051d/1790350736-758824E9-EB3DC459/35/110847 X-purgate-type: clean X-purgate-size: 7015 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------gD9bE6JzZy8Y0hi00bZF6K5L Content-Type: multipart/mixed; boundary="------------gx0ezLrPrh60GfZgX60H2J7b"; protected-headers="v1" From: Juergen Gross To: Abdifatah Suruur , xen-devel@lists.xenproject.org Cc: linux-kernel@vger.kernel.org Message-ID: <3a2f0678-f81a-47cd-a47b-af9b439cedb3@suse.com> Subject: Re: [PATCH] xen/gntdev: prevent private mappings from becoming writable References: <20260819084217.1577-1-suruurism@gmail.com> In-Reply-To: <20260819084217.1577-1-suruurism@gmail.com> --------------gx0ezLrPrh60GfZgX60H2J7b Content-Type: multipart/mixed; boundary="------------eA0awQggEX202hh8SIARYAow" --------------eA0awQggEX202hh8SIARYAow Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTkuMDguMjYgMTA6NDIsIEFiZGlmYXRhaCBTdXJ1dXIgd3JvdGU6DQo+IGdudGRldl9t bWFwKCkgcmVqZWN0cyB3cml0YWJsZSBwcml2YXRlIChub24tc2hhcmVkKSBtYXBwaW5ncyBv ZiBmb3JlaWduDQo+IGdyYW50IHBhZ2VzLCBiZWNhdXNlIGEgcHJpdmF0ZSB3cml0YWJsZSBt YXBwaW5nIHRha2VzIHRoZSBDT1cgcGF0aCBvbg0KPiBwYWdlcyB0aGF0IGhhdmUgbm8gcHJv cGVyIHN0cnVjdC1wYWdlIGJhY2tpbmcuICBIb3dldmVyLCBWTV9NQVlXUklURSBpcw0KPiBs ZWZ0IHNldCwgc28gdXNlcnNwYWNlIGNhbiBtYXAgdGhlIGdyYW50IHJlYWQtb25seSBhbmQg dGhlbiB1cGdyYWRlIHRoZQ0KPiBtYXBwaW5nIHRvIHdyaXRhYmxlIHdpdGggbXByb3RlY3Qo KSwgaGl0dGluZyB0aGUgc2FtZSBDT1cgcGF0aCB0aGUNCj4gY2hlY2sgd2FzIHdyaXR0ZW4g dG8gcHJldmVudC4NCj4gDQo+IENsZWFyIFZNX01BWVdSSVRFIGZvciBwcml2YXRlIG1hcHBp bmdzLCBhcyBpOTE1IGRvZXMgZm9yIGl0cyByZWFkLW9ubHkNCj4gb2JqZWN0cyBhbmQgYXMg Zml4ZWQgaW4gZHJtL3ZjNCAoQ1ZFLTIwMjYtNjg0NDUpIGFuZCBkcm0vcGFudGhvcg0KPiAo Q1ZFLTIwMjQtNTMwNzEpIGFuZCBwdHA6IHZtY2xvY2sgKGNvbW1pdA0KPiBhNWVkYWRiYWU1 N2UyMjk4YTU2Y2Y3YTRlNzc0YTAyNzkwNWEzMzFmKS4NCj4gDQo+IEZpeGVzOiBhYjMxNTIz YzJmY2FjICgieGVuL2dudGRldjogYWxsb3cgdXNlcm1vZGUgdG8gbWFwIGdyYW50ZWQgcGFn ZXMiKQ0KPiBDYzogc3RhYmxlQHZnZXIua2VybmVsLm9yZw0KPiBTaWduZWQtb2ZmLWJ5OiBB YmRpZmF0YWggU3VydXVyIDxzdXJ1dXJpc21AZ21haWwuY29tPg0KDQpSZXZpZXdlZC1ieTog SnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg== --------------eA0awQggEX202hh8SIARYAow Content-Type: application/pgp-keys; name="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Disposition: attachment; filename="OpenPGP_0xB0DE9DD628BF132F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjri oyspZKOBycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2 kaV2KL9650I1SJvedYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i 1TXkH09XSSI8mEQ/ouNcMvIJNwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/B BLUVbDa4+gmzDC9ezlZkTZG2t14zWPvxXP3FAp2pkW0xqG7/377qptDmrk42GlSK N4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEBAAHNHEp1ZXJnZW4gR3Jvc3Mg PGpnQHBmdXBmLm5ldD7CwHkEEwECACMFAlOMcBYCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRCw3p3WKL8TL0KdB/93FcIZ3GCNwFU0u3EjNbNjmXBKDY4F UGNQH2lvWAUy+dnyThpwdtF/jQ6j9RwE8VP0+NXcYpGJDWlNb9/JmYqLiX2Q3Tye vpB0CA3dbBQp0OW0fgCetToGIQrg0MbD1C/sEOv8Mr4NAfbauXjZlvTj30H2jO0u +6WGM6nHwbh2l5O8ZiHkH32iaSTfN7Eu5RnNVUJbvoPHZ8SlM4KWm8rG+lIkGurq qu5gu8q8ZMKdsdGC4bBxdQKDKHEFExLJK/nRPFmAuGlId1E3fe10v5QL+qHI3EIP tyfE7i9Hz6rVwi7lWKgh7pe0ZvatAudZ+JNIlBKptb64FaiIOAWDCx1SzR9KdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+wsB5BBMBAgAjBQJTjHCvAhsDBwsJ CAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/Ey/HmQf/RtI7kv5A2PS4 RF7HoZhPVPogNVbC4YA6lW7DrWf0teC0RR3MzXfy6pJ+7KLgkqMlrAbN/8Dvjoz7 8X+5vhH/rDLa9BuZQlhFmvcGtCF8eR0T1v0nC/nuAFVGy+67q2DH8As3KPu0344T BDpAvr2uYM4tSqxK4DURx5INz4ZZ0WNFHcqsfvlGJALDeE0LhITTd9jLzdDad1pQ SToCnLl6SBJZjDOX9QQcyUigZFtCXFst4dlsvddrxyqT1f17+2cFSdu7+ynLmXBK 7abQ3rwJY8SbRO2iRulogc5vr/RLMMlscDAiDkaFQWLoqHHOdfO9rURssHNN8WkM nQfvUewRz80hSnVlcmdlbiBHcm9zcyA8amdyb3NzQG5vdmVsbC5jb20+wsB5BBMB AgAjBQJTjHDXAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQsN6d1ii/ Ey8PUQf/ehmgCI9jB9hlgexLvgOtf7PJnFOXgMLdBQgBlVPO3/D9R8LtF9DBAFPN hlrsfIG/SqICoRCqUcJ96Pn3P7UUinFG/I0ECGF4EvTE1jnDkfJZr6jrbjgyoZHi w/4BNwSTL9rWASyLgqlA8u1mf+c2yUwcGhgkRAd1gOwungxcwzwqgljf0N51N5Jf VRHRtyfwq/ge+YEkDGcTU6Y0sPOuj4Dyfm8fJzdfHNQsWq3PnczLVELStJNdapwP OoE+lotufe3AM2vAEYJ9rTz3Cki4JFUsgLkHFqGZarrPGi1eyQcXeluldO3m91NK /1xMI3/+8jbO0tsn1tqSEUGIJi7ox80eSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1 c2UuZGU+wsB5BBMBAgAjBQJTjHDrAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC F4AACgkQsN6d1ii/Ey+LhQf9GL45eU5vOowA2u5N3g3OZUEBmDHVVbqMtzwlmNC4 k9Kx39r5s2vcFl4tXqW7g9/ViXYuiDXb0RfUpZiIUW89siKrkzmQ5dM7wRqzgJpJ wK8Bn2MIxAKArekWpiCKvBOB/Cc+3EXE78XdlxLyOi/NrmSGRIov0karw2RzMNOu 5D+jLRZQd1Sv27AR+IP3I8U4aqnhLpwhK7MEy9oCILlgZ1QZe49kpcumcZKORmzB TNh30FVKK1EvmV2xAKDoaEOgQB4iFQLhJCdP1I5aSgM5IVFdn7v5YgEYuJYx37Io N1EblHI//x/e2AaIHpzK5h88NEawQsaNRpNSrcfbFmAg987ATQRTjHAWAQgAyzH6 AOODMBjgfWE9VeCgsrwH3exNAU32gLq2xvjpWnHIs98ndPUDpnoxWQugJ6MpMncr 0xSwFmHEgnSEjK/PAjppgmyc57BwKII3sV4on+gDVFJR6Y8ZRwgnBC5mVM6JjQ5x Dk8WRXljExRfUX9pNhdE5eBOZJrDRoLUmmjDtKzWaDhIg/+1Hzz93X4fCQkNVbVF LELU9bMaLPBG/x5q4iYZ2k2ex6d47YE1ZFdMm6YBYMOljGkZKwYde5ldM9mo45mm we0icXKLkpEdIXKTZeKDO+Hdv1aqFuAcccTg9RXDQjmwhC3yEmrmcfl0+rPghO0I v3OOImwTEe4co3c1mwARAQABwsBfBBgBAgAJBQJTjHAWAhsMAAoJELDendYovxMv Q/gH/1ha96vm4P/L+bQpJwrZ/dneZcmEwTbe8YFsw2V/Buv6Z4Mysln3nQK5ZadD 534CF7TDVft7fC4tU4PONxF5D+/tvgkPfDAfF77zy2AH1vJzQ1fOU8lYFpZXTXIH b+559UqvIB8AdgR3SAJGHHt4RKA0F7f5ipYBBrC6cyXJyyoprT10EMvU8VGiwXvT yJz3fjoYsdFzpWPlJEBRMedCot60g5dmbdrZ5DWClAr0yau47zpWj3enf1tLWaqc suylWsviuGjKGw7KHQd3bxALOknAp4dN3QwBYCKuZ7AddY9yjynVaD5X7nF9nO5B jR/i1DG86lem3iBDXzXsZDn8R3/CwO0EGAEIACAWIQSFEmdy6PYElKXQl/ew3p3W KL8TLwUCWt3w0AIbAgCBCRCw3p3WKL8TL3YgBBkWCAAdFiEEUy2wekH2OPMeOLge gFxhu0/YY74FAlrd8NAACgkQgFxhu0/YY75NiwD/fQf/RXpyv9ZX4n8UJrKDq422 bcwkujisT6jix2mOOwYBAKiip9+mAD6W5NPXdhk1XraECcIspcf2ff5kCAlG0DIN aTUH/RIwNWzXDG58yQoLdD/UPcFgi8GWtNUp0Fhc/GeBxGipXYnvuWxwS+Qs1Qay 7/Nbal/v4/eZZaWs8wl2VtrHTS96/IF6q2o0qMey0dq2AxnZbQIULiEndgR625EF RFg+IbO4ldSkB3trsF2ypYLij4ZObm2casLIP7iB8NKmQ5PndL8Y07TtiQ+Sb/wn g4GgV+BJoKdDWLPCAlCMilwbZ88Ijb+HF/aipc9hsqvW/hnXC2GajJSAY3Qs9Mib 4Hm91jzbAjmp7243pQ4bJMfYHemFFBRaoLC7ayqQjcsttN2ufINlqLFPZPR/i3IX kt+z4drzFUyEjLM1vVvIMjkUoJs=3D =3DeeAB -----END PGP PUBLIC KEY BLOCK----- --------------eA0awQggEX202hh8SIARYAow-- --------------gx0ezLrPrh60GfZgX60H2J7b-- --------------gD9bE6JzZy8Y0hi00bZF6K5L Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAmq2lYYFAwAAAAAACgkQsN6d1ii/Ey/U +wf+PIoLqIUl84NjR6o2F/4ariIjps5xrsLvpynPalwaaR6Yt5EiirO/m1+z41jI0E/BcDcmPSxS BQo91xWov9mB6HSk6XjEf1EyAIlBeLCp8EY7uGog+6cfuNUeYtbkQ4VRlKzi2jDxjEMhpXHbUiBJ GuTO6PRGIuLsHWjgENJNnSnwvFsYH8+SwVnxPmnrbo26ZjJ6l6EJnE57dNMxaTjZJuBnd9BRWcCn WdLQBZGCJtTTg+EMmsdK3fOom5iA2s2VBSJf1tlfeOShy0ZQKVgfWn5/QxmwtX0neyinXquqWBfB fZKS250tJNTQniIIdJdn9/Ui1SIcROS1aEUDIruUuA== =5oNC -----END PGP SIGNATURE----- --------------gD9bE6JzZy8Y0hi00bZF6K5L-- From xen-devel-bounces@lists.xenproject.org Fri Sep 25 15:57:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 25 Sep 2026 15:57:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1434145.1654266 (Exim 4.92) (envelope-from ) id 1xA8IH-0001qb-8z; Fri, 25 Sep 2026 15:57:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1434145.1654266; Fri, 25 Sep 2026 15:57:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA8IH-0001qU-69; Fri, 25 Sep 2026 15:57:01 +0000 Received: by outflank-mailman (input) for mailman id 1434145; Fri, 25 Sep 2026 15:56:59 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xA8IF-0001qO-2O for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 15:56:59 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xA8ID-000emf-Qs for xen-devel@lists.xenproject.org; Fri, 25 Sep 2026 17:56:57 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ab699ab-e002-0a2a0a5209dd-0a2a45018a5a-42 for ; Fri, 25 Sep 2026 17:56:57 +0200 Received: from [40.107.209.1] (helo=PH8PR06CU001.outbound.protection.outlook.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ab699c8-5984-0a2a45010019-286bd10187d0-3 for ; Fri, 25 Sep 2026 17:56:57 +0200 Received: from CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) by PH4PPFB4DF67D13.namprd03.prod.outlook.com (2603:10b6:518:1::613) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.18; Fri, 25 Sep 2026 15:56:54 +0000 Received: from CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096]) by CH8PR03MB8274.namprd03.prod.outlook.com ([fe80::ebe2:32c1:d2be:a096%4]) with mapi id 15.21.0451.014; Fri, 25 Sep 2026 15:56:54 +0000 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UASHT7UgrtbYFL5uO+8BZoWAx9su039kM1CE1c5fQM7dWIALL6PWAiq3KrMhwPU418OUFzEvJKke9ZFkX1bm7uPfvGGwoMRWd0HxDFw3M8FMZm/d0mj+/E57JlYzwQydB4BwCtTnCTvexXEPH/qj84R59Fm3qgZg33Mt0zKFQLE4JHlBZLmES2LXyWbrUJWd+O5V3mT8Yzwiwk5ejqL34TAN5TDQMKHuj78tIdnsqwuRNFNvzbuZ7Hl4qfQbuOOtH8a/wppmH60E18dNq63sKwQB3dPvvKcSrvlHCT3txr95cKPclApkuh/YglcY5faWoIk1OYDspX3mw5cH6ZSzTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IghoUeAQ6lR6+jW3M36ntpibzt/BdExoMnPGm953TLA=; b=yDDczON8YsJum4ciNoIGEx3A1q81RX/S1d1fDDK/xWZTJR57+R6EJ/vbNS/tQX0EvJ43ZsK8AHr4IFuOZ9+vj9IIQrRxH+CZDVi48NVQQM9oOiq+rvDXxMzPWkAGbeUhbG6Vjz3avRTnOOCvbP+d9mGaHpMsH8fRCY+iJS85+7iZ9sjBlI8jXjz9VCAVH35uBmgbjZUdYdzqQgaT2Zw9vaVTmCkM/8XZjQcLI1Nj4ffM4CsJ5l3FYXKYdRKLdNraYoHcZkVWbLqac2doHbAj3O2RnNamM2Wu/YDrRa/Ubft8rNCn6cV3iNjnlK1y3I6BbEKdD06x4DdHMTSQkhRqtA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IghoUeAQ6lR6+jW3M36ntpibzt/BdExoMnPGm953TLA=; b=k+x8qJA0nLBOO1BoneFyTlgOcpj3Hm9LxA0cGqgprwxxTMmavf97cXFiIiPmDcJ3CnbE2Y08iw4thxbWLyUx312jgiBM6erMI9oYeKMiMp9ck2WhhXpN5Jn4/g5MPwxXqjqCoqiypdbVRjamC7S5YmrOwOfFEcDxyo2Hq82VTWw= Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <525eb684-289d-45aa-91a3-b9edbc73c06a@citrix.com> Date: Fri, 25 Sep 2026 16:56:50 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] EFI: refine cfgfile buffer allocation To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Marek Marczykowski , Daniel Smith References: <7e332eec-5c5c-4c1b-aeeb-c65e046b1318@suse.com> Content-Language: en-US From: Ross Lagerwall In-Reply-To: <7e332eec-5c5c-4c1b-aeeb-c65e046b1318@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0203.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:318::17) To CH8PR03MB8274.namprd03.prod.outlook.com (2603:10b6:610:2ba::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8274:EE_|PH4PPFB4DF67D13:EE_ X-MS-Office365-Filtering-Correlation-Id: 3dd9b005-741c-47ae-b724-08df1b1d9e9c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|10067099003|56012099006|6133799003|11063799006|18002099003|22082099003|17002099007|5023799004; X-Microsoft-Antispam-Message-Info: ApbS5M++WhAHadUnUXj/GDQ50rEDOhbfNUCT3G1PrXT8EcQ6y6BHsFK0STzJ0ignlbxs9O4prXiXDTXw6DpP3j/KWhM/r5L8Xq36mQj4bU8OYTmA2dqsNBImrEZPk6IMUU1sEbSIDDphTVMHVGPQTECg6oRwxIIiHquZJ9eFsjBwiIbF77T4VqaISH88sLaMtI0EXSlieoeDBnUnnUPubq+RmHuMSHAWuPymt2YV4JD2UnZKeS8NxJM1Z/6FXx3bm03Nikz0POqryb8px2Z2tnWHeK0IspZsMSFGitZr2WYVgGIbJ5hF1eHjjsoK5oqLlPMMBD225cftH5Z9ZNI02Po/1dndVfPdxwMtJUtJGdBZ+HX1uw2lkIW+KG7tiesEKScWtxupoSvNkplHUFEpg26/EA1jkIP8DMfxYY5vQa0or5V3MMva1ebR+GGy7YfKBP9PsW9bl6K9Ye5gXwXxC6zyDKnN2cUSq+2gUmkmnQ7nH3iYVtQCcRxfY/xzsSqq431Y+mnceLDgMGliNhnWuDHwLsDe2xGbXMnrIj0VOK2sFDJNyKrC7cLYkdL4AxG6wTc5Vd2hnOZeqElWUKGSloaOHSnrVDqyThYQTVCt61odOxv6dk1BqJl7VqDWotEdYUd+8/u+G0IHtrbTQwXxrp1klk4rSoP2Gqfz5nnDwWE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8274.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(10067099003)(56012099006)(6133799003)(11063799006)(18002099003)(22082099003)(17002099007)(5023799004);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bzdyZ2l1cjByeFRZNmFpazBUUlBoZDJrOWdsZVkxTHE2alc1TzZ0aEN0ODhw?= =?utf-8?B?L05WaFdYbFQvRk04VHNuZDYwL0VWTWVIUnNTelhoRjBkVjFaajhaTkpOM1ha?= =?utf-8?B?SnhRa1JyVzJVQ3ZhRDJpNjIxN1daSXk0MllDRHdhUFJBRkpoZnYrZGl5Wlg1?= =?utf-8?B?MTNUbS90OUlzWGJkSkhmelpMbWE0cElDcFJIOGc2RXo4Wkd6ZWh3TDJnTUtI?= =?utf-8?B?eitqU2xPdG92ZFJ3L1I0cno4Rjdub2wwOXZNMjM2VHVhMitra0UwK042aXFM?= =?utf-8?B?ekp1Z2pMU2VvRks5NEhVQURHV1VJUjhZTEhNdEtXMGdKdEJOd3JVcFJuazRn?= =?utf-8?B?UzlUeTdRWjR4K2o3SHJzSk9wQkhOWkxVSnBaOWhUV1gvbXZ0YXN5WTI2QUxX?= =?utf-8?B?VWJkQm1Oc0haVzZUV0F2WENUbFQrVzEvaHI0NFFlZUVNYUxxRk9iNWhrQmxx?= =?utf-8?B?YXN0QmdFVGJqMHZxTGQwVjl2RUpETnRaMEFaUHZ4d3NvTVBUekZxUFdENGtT?= =?utf-8?B?YW5aY0Q3STI1SFlhTDJnNGVzZnprcGltVGcwSWlYc3Z2dUJFRU5KZkVZYzg0?= =?utf-8?B?LzZXWm4xcHlHMUpFdG9RTndRMGtkdTlPazBBZlpCSlRDK0wyY2laWWZ5UHNY?= =?utf-8?B?LzNtc1U1a0I3M20xYXAyTVhLRlBpU3NJeVVZQk5PYkNDemRsVkZ6M2dtQWtG?= =?utf-8?B?YWg3bGtSeU9ZNjZFVDNpSWdMbHdnK3RYTTVSK1lTbko2NHVJRkRGS2UwWU9T?= =?utf-8?B?NkpISzNuSXgvODBlbmpwV0M1T0llalQzWGRZY1dzUDJPYjJnOFI2M1lGdkY5?= =?utf-8?B?VVYyaytwZit3dzBrY3JOTlZ3V0xyTUI1UTRsNzFFZE9DU0ppcndGUThMZXJ0?= =?utf-8?B?WTVnVWczMzBIWkVDWXQwTGVuZ0M5WmtnUlVxTklPNDFjMFRKTFFYWHVGaEtE?= =?utf-8?B?VTNwTGhPcS90MS93MEY5c0VXUGh0NnIvUHY0R2x4ZmVJZzYxWG5jaGozMXlJ?= =?utf-8?B?K0Y1WHRtelJMUnZRQVp1YnRiV1laYVpsazRrdnFGenl2UWdvK0JNSU1FWXZ1?= =?utf-8?B?QS82WmNrMDIyZGZFSVFTdHg1ckFnNFh6eVM4eTBlN252V0JNd0lmS0plTVpG?= =?utf-8?B?d3lCdVFpK3djQU5HTlZHVWtETEdhdTZWeGtVeVBDV1dETTBaRDlIREZXdUN3?= =?utf-8?B?Z0FFWFRYTXdidEJVZTBWODcvd2hmQzFkV29QUURJMGhGZnAxaHRIdldQdG4x?= =?utf-8?B?Nk45bjFKQjRBU2tvbXJBdGdQOVJhMWhYTlVwK3dic2Jxc095MlJuLzdKSFo0?= =?utf-8?B?WEd5c2d2b0dWWUhTUzBSenE4Y0FlV1Q0Q0JyNitqOUxGMDhkb0xwS0xOSHNP?= =?utf-8?B?aWxKY3FlL0txRmpGWldXbm1BV1VqVXlvM3VNWWVwK0JIdjd3OTRuUTVDT3h6?= =?utf-8?B?dlV3R3VobStuNHZiVE1yT2YwbC85czhNb2RQOHBhaDF6SmVFMXB4YUFUQUM3?= =?utf-8?B?eG12WEUyZDFwRU1GUVJtaEVoQ2E3Y25jajRSUVNQL3JKTkJRUVNodU9OQ0tG?= =?utf-8?B?dk1IWFpwdlo3NjRNeXlwcDJ0SFZkSk81M1kxNkdsZGtjWHpWSFVsajhRMWF5?= =?utf-8?B?b056b0xPa1lIYVJJNGN1M05hNGJ5RjdRbm9JKzlDLzJXNGw5UFZOank5NkVu?= =?utf-8?B?aHR2L3luU1FZUE9pdW5qNzFVRDdEV1pya1FkMEdiMU42eE1Mem1Ed0hlNWFn?= =?utf-8?B?aUFwRnZ5ZFdKMVF4ckxTcUZoWkJza3UvL2lQS3NJbFFhTGRQVFE4dnI2a0hL?= =?utf-8?B?bGxJdjRETGFDQXRTRkhTbk9ZQXJ3dTNybzBNdkJRVWhhbCszZ3BuTjJOQUgz?= =?utf-8?B?Vk5UOG5NWlFXek1yeXhNWWRqK1NINWlnU3VoMHR6TTJ4eEtPajRTcVlXN2VC?= =?utf-8?B?THVnUndZbXJ6ZXhmR2ovem82SXpiNS9GcGt1aHVrL0NNUkFmMWRKQkJKeEI4?= =?utf-8?B?SjFuRi93ejR0R2pLeEE3N01tUmttcjRhbmRGT2JFcmRHditlWVhkZUlwajNy?= =?utf-8?B?dUpBVHd0UlpoNW1saXdVTjk4d0hrMzFyV0RsRFJ5eXExWGN0R2hxdXhhUEFM?= =?utf-8?B?MkFqMW9Vbmo0SkhMVjhsUUtCaXkyMU1GT2M4Z3h5R1JiWlZZK0p5Qno2NXBm?= =?utf-8?B?ZmhuYXV3VUszMVoycnM5OCtpZ3Nvc2VpM2xkMkEzRW5nV2VnaTBjeE04d29S?= =?utf-8?B?NjViSmpXUUh3b1BEK2U3M1NhTXk2M2thNGY2Y0l1YUN5L0xhbUt0UDN5ZkVh?= =?utf-8?B?LzdtWU90L3lSZHdKUkNSY3pza1p3NTZWNWlleHFLVHF3cGFKbXcvdnFudnF4?= =?utf-8?Q?Vr+1/HgGeB/pOxEo=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3dd9b005-741c-47ae-b724-08df1b1d9e9c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8274.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2026 15:56:54.0649 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UxsbBnYPU9IbL6QiPudHIRdKjt6Gxidn4l/el9faZ9rUNC75023zYccQzKTmYzDIqUQzEUvD1Ml0PujfN19guMN103tX/f92Ov5NPsSHNDM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH4PPFB4DF67D13 X-purgate-ID: tlsNG-d62444/1790351817-BD341757-C657129E/0/0 X-purgate-type: clean X-purgate-size: 1412 On 9/21/26 10:09 AM, Jan Beulich wrote: > Use of AllocateMaxAddress requires that the variable pointed to by the > last argument of ->AllocatePages() is initialized. For cfgfile buffers we > don't need AllocateMaxAddress though, at which point initialization of > "addr" also isn't necessary anymore. > > Mirror the lack of address constraint also to the main / central buffer > allocation in read_file(). > > Fixes: df75f77092c1 ("EFI: avoid OOB config file reads") > Assisted-by: Sashiko + Opus 5.0 > Reported-by: George Dunlap > Signed-off-by: Jan Beulich > > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -878,8 +878,13 @@ static bool __init read_file(EFI_FILE_HA > what = L"Allocation"; > file->addr = min(1UL << (32 + PAGE_SHIFT), > HYPERVISOR_VIRT_END - DIRECTMAP_VIRT_START); > - /* For config files allocate an extra byte to put a NUL there. */ > - ret = efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData, > + /* > + * For config files allocate an extra byte to put a NUL there. There's > + * also no constraint on addresses for them. > + */ > + ret = efi_bs->AllocatePages(file != &cfg ? AllocateMaxAddress > + : AllocateAnyPages, You could avoid the negation here, unless it was intentional? Ross